[PATCH] coredump: binfmt_elf{,_fdpic}.c: don't abuse GFP_ATOMIC

[PATCH] coredump: binfmt_elf{,_fdpic}.c: don't abuse GFP_ATOMIC

[Oleg Nesterov]

kmalloc(GFP_ATOMIC) was needed because it was called under tasklist_lock.
The code was changed to use rcu_read_lock(), we can use GFP_KERNEL.

Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>

 binfmt_elf.c       |    4 ++--
 binfmt_elf_fdpic.c |    2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

--- 26-rc2/fs/binfmt_elf.c~NO_ATOMIC	2008-05-18 15:43:59.000000000 +0400
+++ 26-rc2/fs/binfmt_elf.c	2008-06-01 20:47:08.000000000 +0400
@@ -1524,7 +1524,7 @@ static int fill_note_info(struct elfhdr 
 		if (p->mm == dump_task->mm) {
 			t = kzalloc(offsetof(struct elf_thread_core_info,
 					     notes[info->thread_notes]),
-				    GFP_ATOMIC);
+				    GFP_KERNEL);
 			if (unlikely(!t)) {
 				rcu_read_unlock();
 				return 0;
@@ -1726,7 +1726,7 @@ static int fill_note_info(struct elfhdr 
 		rcu_read_lock();
 		do_each_thread(g, p)
 			if (current->mm == p->mm && current != p) {
-				ets = kzalloc(sizeof(*ets), GFP_ATOMIC);
+				ets = kzalloc(sizeof(*ets), GFP_KERNEL);
 				if (!ets) {
 					rcu_read_unlock();
 					return 0;
--- 26-rc2/fs/binfmt_elf_fdpic.c~NO_ATOMIC	2008-05-18 15:43:59.000000000 +0400
+++ 26-rc2/fs/binfmt_elf_fdpic.c	2008-06-01 20:47:20.000000000 +0400
@@ -1626,7 +1626,7 @@ static int elf_fdpic_core_dump(long sign
 		rcu_read_lock();
 		do_each_thread(g,p)
 			if (current->mm == p->mm && current != p) {
-				tmp = kzalloc(sizeof(*tmp), GFP_ATOMIC);
+				tmp = kzalloc(sizeof(*tmp), GFP_KERNEL);
 				if (!tmp) {
 					rcu_read_unlock();
 					goto cleanup;

Re: [PATCH] coredump: binfmt_elf{,_fdpic}.c: don't abuse GFP_ATOMIC

[Oleg Nesterov]

On 06/01, Peter Zijlstra wrote:
>
> On Sun, 2008-06-01 at 20:55 +0400, Oleg Nesterov wrote:
> > kmalloc(GFP_ATOMIC) was needed because it was called under tasklist_lock.
> > The code was changed to use rcu_read_lock(), we can use GFP_KERNEL.
> 
> Classic RCU - still frequently used - disables preemption and thus does
> not allow us to use __GFP_WAIT.

Ah, I'm stupid, thanks!

please ignore this patch.

Oleg.

Re: [PATCH] coredump: binfmt_elf{,_fdpic}.c: don't abuse GFP_ATOMIC

[Peter Zijlstra]

On Sun, 2008-06-01 at 20:55 +0400, Oleg Nesterov wrote:
> kmalloc(GFP_ATOMIC) was needed because it was called under tasklist_lock.
> The code was changed to use rcu_read_lock(), we can use GFP_KERNEL.

Classic RCU - still frequently used - disables preemption and thus does
not allow us to use __GFP_WAIT.

> Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
> 
>  binfmt_elf.c       |    4 ++--
>  binfmt_elf_fdpic.c |    2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> --- 26-rc2/fs/binfmt_elf.c~NO_ATOMIC	2008-05-18 15:43:59.000000000 +0400
> +++ 26-rc2/fs/binfmt_elf.c	2008-06-01 20:47:08.000000000 +0400
> @@ -1524,7 +1524,7 @@ static int fill_note_info(struct elfhdr 
>  		if (p->mm == dump_task->mm) {
>  			t = kzalloc(offsetof(struct elf_thread_core_info,
>  					     notes[info->thread_notes]),
> -				    GFP_ATOMIC);
> +				    GFP_KERNEL);
>  			if (unlikely(!t)) {
>  				rcu_read_unlock();
>  				return 0;
> @@ -1726,7 +1726,7 @@ static int fill_note_info(struct elfhdr 
>  		rcu_read_lock();
>  		do_each_thread(g, p)
>  			if (current->mm == p->mm && current != p) {
> -				ets = kzalloc(sizeof(*ets), GFP_ATOMIC);
> +				ets = kzalloc(sizeof(*ets), GFP_KERNEL);
>  				if (!ets) {
>  					rcu_read_unlock();
>  					return 0;
> --- 26-rc2/fs/binfmt_elf_fdpic.c~NO_ATOMIC	2008-05-18 15:43:59.000000000 +0400
> +++ 26-rc2/fs/binfmt_elf_fdpic.c	2008-06-01 20:47:20.000000000 +0400
> @@ -1626,7 +1626,7 @@ static int elf_fdpic_core_dump(long sign
>  		rcu_read_lock();
>  		do_each_thread(g,p)
>  			if (current->mm == p->mm && current != p) {
> -				tmp = kzalloc(sizeof(*tmp), GFP_ATOMIC);
> +				tmp = kzalloc(sizeof(*tmp), GFP_KERNEL);
>  				if (!tmp) {
>  					rcu_read_unlock();
>  					goto cleanup;
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/