Skip to contentSkip to conversation

staging: gasket: Create a memory allocation error handling path

PATCH Superseded Ioannis Valasakis 3 participants 6 messages Oct 31, 2018 Staging

v3 of 6 Superseded Latest is v6 →

lore
Share & tools
lore
#0 lore raw

PATCH v3 1/1 staging: gasket: Create a memory allocation error handling path

Create an error handling path for memory allocation. It avoids repeating the same assignments and returns the respective ENOMEM.

---
Changes in v3:
- Modified the label names so they free the right memory

 drivers/staging/gasket/gasket_interrupt.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/staging/gasket/gasket_interrupt.c +3 -3
index 23232ea8f4d9..b1ee9a70bdd8 100644
@@ -362,7 +362,7 @@ int gasket_interrupt_init(struct gasket_dev *gasket_dev, const char *name,
 						   sizeof(ulong),
 						   GFP_KERNEL);
 	if (!interrupt_data->interrupt_counts) {
-		goto err_free_data;
+		goto err_free_all;
 	}
 
 	switch (interrupt_data->type) {
@@ -397,11 +397,11 @@ int gasket_interrupt_init(struct gasket_dev *gasket_dev, const char *name,
 
 	return 0;
 
-err_free_msix:
+err_free_all:
 	kfree(interrupt_data->eventfd_ctxs);
 err_free_eventfd:
 	kfree(interrupt_data->msix_entries);
-err_free_data:
+err_free_msix:
 	kfree(interrupt_data);
 	return -ENOMEM;
 }
Signature · 1 line
2.19.1
#1 lore raw
Quoted 2 lines · Ioannis Valasakis

Create an error handling path for memory allocation. It avoids repeating the same assignments and returns the respective ENOMEM.

I think you are again making a patch based on your previous patch. You need to undo everything to get back to the state of Greg's tree.

julia

Quoted 47 lines

---
Changes in v3:
- Modified the label names so they free the right memory

 drivers/staging/gasket/gasket_interrupt.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/staging/gasket/gasket_interrupt.c +3 -4
index 23232ea8f4d9..b1ee9a70bdd8 100644
@@ -362,7 +362,7 @@ int gasket_interrupt_init(struct gasket_dev *gasket_dev, const char *name,
 						   sizeof(ulong),
 						   GFP_KERNEL);
 	if (!interrupt_data->interrupt_counts) {
-		goto err_free_data;
+		goto err_free_all;
 	}
 
 	switch (interrupt_data->type) {
@@ -397,11 +397,11 @@ int gasket_interrupt_init(struct gasket_dev *gasket_dev, const char *name,
 
 	return 0;
 
-err_free_msix:
+err_free_all:
 	kfree(interrupt_data->eventfd_ctxs);
 err_free_eventfd:
 	kfree(interrupt_data->msix_entries);
-err_free_data:
+err_free_msix:
 	kfree(interrupt_data);
 	return -ENOMEM;
 }
--

2.19.1

--
You received this message because you are subscribed to the Google Groups "outreachy-kernel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/d/msgid/outreachy-kernel/20181031205636.GA13583%40kvasir.local.
For more options, visit https://groups.google.com/d/optout.

#2 lore raw
Quoted 9 lines · Julia Lawall
Quoted 2 lines · Ioannis Valasakis

Create an error handling path for memory allocation. It avoids repeating the same assignments and returns the respective ENOMEM.

I think you are again making a patch based on your previous patch. You need to undo everything to get back to the state of Greg's tree.

An easy way to deal with the situation you're in now is to use git's interactive rebase. Interactive rebase lets you merge ("squash") two or more commits together, so you can merge all your commits on top of Greg's tree into a single commit.

To use that, try: "git rebase -i HEAD~5". The number "5" stands for the amount of commits to go back; if you have more than that feel free to change this number to a more appropriate one.

Once you've done that, you will see an editor window with lines in the form of:

	pick [commit hash] [commit subject]
	[...]

You can merge a commit with a previous commit by changing "pick" into "fixup", and then saving and closing the editor.

For example:

	pick 11111111 "my first commit"
	fixup 22222222 "my second commit"
	pick 33333333 "my third commit"

Using the above, git will merge the second commit into the first, and leave the third one as it is.

--
Thanks,
Sasha

#3 lore raw
Quoted 8 lines · Sasha Levin
Quoted 7 lines · Julia Lawall
Quoted 2 lines · Ioannis Valasakis

Create an error handling path for memory allocation. It avoids repeating the same assignments and returns the respective ENOMEM.

Quoted 7 lines
Quoted 2 lines

I think you are again making a patch based on your previous patch. You need to undo everything to get back to the state of Greg's tree.

An easy way to deal with the situation you're in now is to use git's interactive rebase. Interactive rebase lets you merge ("squash") two or more commits together, so you can merge all your commits on top of Greg's tree into a single commit.

Thank you Sasha for your helpful comment. I tried already with git's rebase option but that made it a bit complicated as apparently the source tree had many changes (even one of the memory allocations was totally removed!)

That's why I just removed my commits and did a fresh git checkout master && git pull. Apparently thousands of changes can happen at very specific times of the day :)

Is there an 'automatic way' to do often git pulls, so you are sure you are working on the latest source tree?

Best
Ioannis

Quoted 26 lines

To use that, try: "git rebase -i HEAD~5". The number "5" stands for the amount of commits to go back; if you have more than that feel free to change this number to a more appropriate one.

Once you've done that, you will see an editor window with lines in the form of:

	pick [commit hash] [commit subject]
	[...]

You can merge a commit with a previous commit by changing "pick" into "fixup", and then saving and closing the editor.

For example:

	pick 11111111 "my first commit"
	fixup 22222222 "my second commit"
	pick 33333333 "my third commit"

Using the above, git will merge the second commit into the first, and leave the third one as it is.

--
Thanks,
Sasha

#4 lore raw
Quoted 21 lines · Ioannis Valasakis
Quoted 8 lines · Sasha Levin
Quoted 7 lines · Julia Lawall
Quoted 2 lines · Ioannis Valasakis

Create an error handling path for memory allocation. It avoids repeating the same assignments and returns the respective ENOMEM.

Quoted 7 lines
Quoted 2 lines

I think you are again making a patch based on your previous patch. You need to undo everything to get back to the state of Greg's tree.

An easy way to deal with the situation you're in now is to use git's interactive rebase. Interactive rebase lets you merge ("squash") two or more commits together, so you can merge all your commits on top of Greg's tree into a single commit.

Thank you Sasha for your helpful comment. I tried already with git's rebase option but that made it a bit complicated as apparently the source tree had many changes (even one of the memory allocations was totally removed!)

Quoted 6 lines

That's why I just removed my commits and did a fresh git checkout master && git pull. Apparently thousands of changes can happen at very specific times of the day :)

Is there an 'automatic way' to do often git pulls, so you are sure you are working on the latest source tree?

Did you try 'git pull --rebase'? It will update the branch, but leave your commits on top.

--
Thanks,
Sasha

#5 lore raw
Quoted 26 lines · Sasha Levin
Quoted 25 lines · Ioannis Valasakis
Quoted 8 lines · Sasha Levin
Quoted 7 lines · Julia Lawall
Quoted 2 lines · Ioannis Valasakis

Create an error handling path for memory allocation. It avoids repeating the same assignments and returns the respective ENOMEM.

Quoted 7 lines
Quoted 2 lines

I think you are again making a patch based on your previous patch. You need to undo everything to get back to the state of Greg's tree.

An easy way to deal with the situation you're in now is to use git's interactive rebase. Interactive rebase lets you merge ("squash") two or more commits together, so you can merge all your commits on top of Greg's tree into a single commit.

Thank you Sasha for your helpful comment. I tried already with git's rebase option but that made it a bit complicated as apparently the source tree had many changes (even one of the memory allocations was totally removed!)

That's why I just removed my commits and did a fresh git checkout master && git pull. Apparently thousands of changes can happen at very specific times of the day :)

Quoted 6 lines
Quoted 2 lines

Is there an 'automatic way' to do often git pulls, so you are sure you are working on the latest source tree?

Did you try 'git pull --rebase'? It will update the branch, but leave your commits on top.

Oh that sounds like a great idea. I am going to add an alias for every git pull to do actually a pull --rebase :) thanks!

Quoted 3 lines

--
Thanks,
Sasha