LinuxLists.cc - mmotm 2009-06-30-12-50 uploaded

[permalink] [raw]

Subject: Re: mmotm 2009-06-30-12-50 uploaded

On Tue, 30 Jun 2009 12:51:30 PDT, [email protected] said:
> The mm-of-the-moment snapshot 2009-06-30-12-50 has been uploaded to

This dies with quilt 0.44, thusly:

Applying patch procfs-provide-stack-information-for-threads-v08.patch
can't find file to patch at input line 20
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|From: Stefani Seibold <[email protected]>
|
|A patch to give a better overview of the userland application stack usage,
|especially for embedded linux.
|
|Currently you are only able to dump the main process/thread stack usage
|which is showed in /proc/pid/status by the "VmStk" Value. But you get no
|information about the consumed stack memory of the the threads.
|
|There is an enhancement in the /proc/<pid>/{task/*,}/*maps and which marks
|the vm mapping where the thread stack pointer reside with "[thread stack
|xxxxxxxx]". xxxxxxxx is the maximum size of stack. This is a value
|information, because libpthread doesn't set the start of the stack to the
|top of the mapped area, depending of the pthread usage.
|
|A sample output of /proc/<pid>/task/<tid>/maps looks like:
|
|08048000-08049000 r-xp 00000000 03:00 8312 /opt/z
|08049000-0804a000 rw-p 00001000 03:00 8312 /opt/z
--------------------------
No file to patch. Skipping patch.
patch: **** /tmp/poPjWncl : No such file or directory
Patch procfs-provide-stack-information-for-threads-v08.patch does not apply (enforce with -f)

Yowza. Not sure what makes it think there's an issue at line 20, looks to
*me* like the actual patch starts on line 77.

Attachments:

(No filename) (226.00 B)

2009-06-30 20:20:26

by Randy Dunlap

[permalink] [raw]

Subject: Re: mmotm 2009-06-30-12-50 uploaded

[email protected] wrote:
> On Tue, 30 Jun 2009 12:51:30 PDT, [email protected] said:
>> The mm-of-the-moment snapshot 2009-06-30-12-50 has been uploaded to
>
> This dies with quilt 0.44, thusly:
>
> Applying patch procfs-provide-stack-information-for-threads-v08.patch
> can't find file to patch at input line 20
> Perhaps you used the wrong -p or --strip option?
> The text leading up to this was:
> --------------------------
> |From: Stefani Seibold <[email protected]>
> |
> |A patch to give a better overview of the userland application stack usage,
> |especially for embedded linux.
> |
> |Currently you are only able to dump the main process/thread stack usage
> |which is showed in /proc/pid/status by the "VmStk" Value. But you get no
> |information about the consumed stack memory of the the threads.
> |
> |There is an enhancement in the /proc/<pid>/{task/*,}/*maps and which marks
> |the vm mapping where the thread stack pointer reside with "[thread stack
> |xxxxxxxx]". xxxxxxxx is the maximum size of stack. This is a value
> |information, because libpthread doesn't set the start of the stack to the
> |top of the mapped area, depending of the pthread usage.
> |
> |A sample output of /proc/<pid>/task/<tid>/maps looks like:
> |
> |08048000-08049000 r-xp 00000000 03:00 8312 /opt/z
> |08049000-0804a000 rw-p 00001000 03:00 8312 /opt/z
> --------------------------
> No file to patch. Skipping patch.
> patch: **** /tmp/poPjWncl : No such file or directory
> Patch procfs-provide-stack-information-for-threads-v08.patch does not apply (enforce with -f)
>
> Yowza. Not sure what makes it think there's an issue at line 20, looks to
> *me* like the actual patch starts on line 77.

patch version problem? I'm not seeing an error there.

Applying patch procfs-provide-stack-information-for-threads-v08.patch
patching file Documentation/filesystems/proc.txt
patching file fs/exec.c
Hunk #1 succeeded at 1340 ([33moffset -4 lines[00m).
patching file fs/proc/array.c
patching file fs/proc/task_mmu.c
patching file include/linux/sched.h
Hunk #1 succeeded at 1486 ([33moffset 26 lines[00m).
patching file kernel/fork.c
Hunk #1 succeeded at 1094 ([33moffset -1 lines[00m).

> patch --version
patch 2.5.9

--
~Randy
LPC 2009, Sept. 23-25, Portland, Oregon
http://linuxplumbersconf.org/2009/

2009-06-30 20:27:26

[permalink] [raw]

Subject: Re: mmotm 2009-06-30-12-50 uploaded

On Tue, 30 Jun 2009 16:15:52 EDT, [email protected] said:
>
> Yowza. Not sure what makes it think there's an issue at line 20, looks to
> *me* like the actual patch starts on line 77.

>From the patch:

A sample output of /proc/<pid>/task/<tid>/maps looks like:

08048000-08049000 r-xp 00000000 03:00 8312 /opt/z
08049000-0804a000 rw-p 00001000 03:00 8312 /opt/z
0804a000-0806b000 rw-p 00000000 00:00 0 [heap]
a7d12000-a7d13000 ---p 00000000 00:00 0
a7d13000-a7f13000 rw-p 00000000 00:00 0 [thread stack: 001ff4b4]
a7f13000-a7f14000 ---p 00000000 00:00 0

The line with '[heap]' gives it the indigestion - deleting that line and
we get:

% quilt push procfs-provide-stack-information-for-threads-v08.patch
Applying patch procfs-provide-stack-information-for-threads-v08.patch
patching file Documentation/filesystems/proc.txt
patching file fs/exec.c
Hunk #1 succeeded at 1340 (offset -4 lines).
patching file fs/proc/array.c
patching file fs/proc/task_mmu.c
patching file include/linux/sched.h
Hunk #1 succeeded at 1486 (offset 26 lines).
patching file kernel/fork.c
Hunk #1 succeeded at 1094 (offset -1 lines).

Now at patch procfs-provide-stack-information-for-threads-v08.patch

Not sure why that line did it. Repeated truncate-and-try shows that if the
line contained just the 4 chars '0804', it applied fine, but '0804a' dies.

<Cue twilight zone theme>,

Attachments:

(No filename) (226.00 B)

2009-06-30 20:36:29

[permalink] [raw]

Subject: Re: mmotm 2009-06-30-12-50 uploaded

On Tue, 30 Jun 2009 13:19:48 -0700
Randy Dunlap <[email protected]> wrote:

> [email protected] wrote:

(I wasn't cc'ed?)

> > On Tue, 30 Jun 2009 12:51:30 PDT, [email protected] said:
> >> The mm-of-the-moment snapshot 2009-06-30-12-50 has been uploaded to
> >
> > This dies with quilt 0.44, thusly:
> >
> > Applying patch procfs-provide-stack-information-for-threads-v08.patch
> > can't find file to patch at input line 20
> > Perhaps you used the wrong -p or --strip option?
> > The text leading up to this was:
> > --------------------------
> > |From: Stefani Seibold <[email protected]>
> > |
> > |A patch to give a better overview of the userland application stack usage,
> > |especially for embedded linux.
> > |
> > |Currently you are only able to dump the main process/thread stack usage
> > |which is showed in /proc/pid/status by the "VmStk" Value. But you get no
> > |information about the consumed stack memory of the the threads.
> > |
> > |There is an enhancement in the /proc/<pid>/{task/*,}/*maps and which marks
> > |the vm mapping where the thread stack pointer reside with "[thread stack
> > |xxxxxxxx]". xxxxxxxx is the maximum size of stack. This is a value
> > |information, because libpthread doesn't set the start of the stack to the
> > |top of the mapped area, depending of the pthread usage.
> > |
> > |A sample output of /proc/<pid>/task/<tid>/maps looks like:
> > |
> > |08048000-08049000 r-xp 00000000 03:00 8312 /opt/z
> > |08049000-0804a000 rw-p 00001000 03:00 8312 /opt/z

The next line is:

a7d12000-a7d13000 ---p 00000000 00:00 0

And I bet stupid patch(1) saw that "---" and decided that it was the
start of a diff.

Try adding `-u' to the patch(1) command?

I use something like

patch -u -f -p1 --fuzz=1 -s

2009-06-30 20:38:48

[permalink] [raw]

Subject: Re: mmotm 2009-06-30-12-50 uploaded

On Tue, 30 Jun 2009 16:27:01 -0400
[email protected] wrote:

> Not sure why that line did it. Repeated truncate-and-try shows that if the
> line contained just the 4 chars '0804', it applied fine, but '0804a' dies.

That's patch(1) thinking it's a regular diff:

akpm:/usr/src/25> diff Makefile Makefile~linux-next
4c4
< EXTRAVERSION = -rc1-mm1
---
> EXTRAVERSION = -rc1
142a143,144
> TOPDIR := $(srctree)
> # FIXME - TOPDIR is obsolete, use srctree/objtree
149c151
< export srctree objtree VPATH
---
> export srctree objtree VPATH TOPDIR
328c330
< LDFLAGS_MODULE = -T $(srctree)/scripts/module-common.lds
---
> LDFLAGS_MODULE =
345,346c347
< -Werror-implicit-function-declaration \
< -Wno-format-security
---
> -Werror-implicit-function-declaration

So the "0804a" means "at line 804, start appending stuff", or something
like that.

Use -u.

2009-06-30 20:39:59

by Randy Dunlap

[permalink] [raw]

Subject: Re: mmotm 2009-06-30-12-50 uploaded

Andrew Morton wrote:
> On Tue, 30 Jun 2009 13:19:48 -0700
> Randy Dunlap <[email protected]> wrote:
>
>> [email protected] wrote:
>
> (I wasn't cc'ed?)

mm-commits but not you... (from Valdis)

>>> On Tue, 30 Jun 2009 12:51:30 PDT, [email protected] said:
>>>> The mm-of-the-moment snapshot 2009-06-30-12-50 has been uploaded to
>>> This dies with quilt 0.44, thusly:
>>>
>>> Applying patch procfs-provide-stack-information-for-threads-v08.patch
>>> can't find file to patch at input line 20
>>> Perhaps you used the wrong -p or --strip option?
>>> The text leading up to this was:
>>> --------------------------
>>> |From: Stefani Seibold <[email protected]>
>>> |
>>> |A patch to give a better overview of the userland application stack usage,
>>> |especially for embedded linux.
>>> |
>>> |Currently you are only able to dump the main process/thread stack usage
>>> |which is showed in /proc/pid/status by the "VmStk" Value. But you get no
>>> |information about the consumed stack memory of the the threads.
>>> |
>>> |There is an enhancement in the /proc/<pid>/{task/*,}/*maps and which marks
>>> |the vm mapping where the thread stack pointer reside with "[thread stack
>>> |xxxxxxxx]". xxxxxxxx is the maximum size of stack. This is a value
>>> |information, because libpthread doesn't set the start of the stack to the
>>> |top of the mapped area, depending of the pthread usage.
>>> |
>>> |A sample output of /proc/<pid>/task/<tid>/maps looks like:
>>> |
>>> |08048000-08049000 r-xp 00000000 03:00 8312 /opt/z
>>> |08049000-0804a000 rw-p 00001000 03:00 8312 /opt/z
>
> The next line is:
>
> a7d12000-a7d13000 ---p 00000000 00:00 0
>
> And I bet stupid patch(1) saw that "---" and decided that it was the
> start of a diff.
>
> Try adding `-u' to the patch(1) command?
>
> I use something like
>
> patch -u -f -p1 --fuzz=1 -s

Yes, my .quiltrc file contains -u for QUILT_PATCH_OPTS.

--
~Randy
LPC 2009, Sept. 23-25, Portland, Oregon
http://linuxplumbersconf.org/2009/

2009-06-30 21:49:55

by Randy Dunlap

[permalink] [raw]

Subject: [PATCH mmotm] hwmon: fix lis3-spi for CONFIG_PM=n

From: Randy Dunlap <[email protected]>

Fix build error when CONFIG_PM=n:

The suspend & resume function names are incorrect for the
PM=n case.

Signed-off-by: Randy Dunlap <[email protected]>
---
drivers/hwmon/lis3lv02d_spi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- mmotm-2009-0630-1250.orig/drivers/hwmon/lis3lv02d_spi.c
+++ mmotm-2009-0630-1250/drivers/hwmon/lis3lv02d_spi.c
@@ -108,8 +108,8 @@ static int lis3lv02d_spi_resume(struct s
}

#else
-#define lis3_spi_suspend NULL
-#define lis3_spi_resume NULL
+#define lis3lv02d_spi_suspend NULL
+#define lis3lv02d_spi_resume NULL
#endif

static struct spi_driver lis302dl_spi_driver = {

---
~Randy
LPC 2009, Sept. 23-25, Portland, Oregon
http://linuxplumbersconf.org/2009/

2009-07-01 09:22:07

by KOSAKI Motohiro

[permalink] [raw]

Subject: Re: mmotm 2009-06-30-12-50 uploaded

just dumb question.

> So the "0804a" means "at line 804, start appending stuff", or something
> like that.
>
> Use -u.

afaik, 99% quilt user use -u. so, Why quilt don't turn on -u by default?

2009-07-02 15:14:39

[permalink] [raw]

Subject: Re: mmotm 2009-06-30-12-50 uploaded

On Tue, 30 Jun 2009 13:38:16 PDT, Andrew Morton said:
> On Tue, 30 Jun 2009 16:27:01 -0400
> [email protected] wrote:
>
> > Not sure why that line did it. Repeated truncate-and-try shows that if the
> > line contained just the 4 chars '0804', it applied fine, but '0804a' dies.
>
> That's patch(1) thinking it's a regular diff:
>
> akpm:/usr/src/25> diff Makefile Makefile~linux-next
> 4c4
...
> So the "0804a" means "at line 804, start appending stuff", or something
> like that.
>
> Use -u.

Yep, that was it, thanks. Added to .quiltrc.

Attachments:

(No filename) (226.00 B)

2009-07-02 19:16:43

[permalink] [raw]

Subject: Re: mmotm 2009-06-30-12-50 uploaded

On Tue, 30 Jun 2009 12:51:30 PDT, [email protected] said:
> The mm-of-the-moment snapshot 2009-06-30-12-50 has been uploaded to
>
> http://userweb.kernel.org/~akpm/mmotm/

This whinges at me during early startup:

[ 0.654180] ACPI: Video Device [VID] (multi-head: yes rom: no post: no)
[ 0.655101] ACPI: SSDT 000000007fe82138 00244 (v01 PmRef Cpu0Ist 00003000 INTL 20050624)
[ 0.655547] power_supply AC: prop ONLINE=1
[ 0.655984] ACPI: SSDT 000000007fe81eed 001C6 (v01 PmRef Cpu0Cst 00003001 INTL 20050624)
[ 0.657061] ------------[ cut here ]------------
[ 0.657296] WARNING: at kernel/lockdep.c:2143 trace_hardirqs_on_caller+0xc7/0x145()
[ 0.657664] Hardware name: Latitude D820
[ 0.657933] Modules linked in:
[ 0.658056] Pid: 0, comm: swapper Not tainted 2.6.31-rc1-mmotm0630 #1
[ 0.658056] Call Trace:
[ 0.658056] <IRQ> [<ffffffff8103ef3d>] warn_slowpath_common+0x77/0x8f
[ 0.658056] [<ffffffff8120a76a>] ? acpi_processor_get_throttling_fadt+0x81/0x8c
[ 0.658056] [<ffffffff8103ef64>] warn_slowpath_null+0xf/0x11
[ 0.658056] [<ffffffff81065ba9>] trace_hardirqs_on_caller+0xc7/0x145
[ 0.658056] [<ffffffff81065c34>] trace_hardirqs_on+0xd/0xf
[ 0.658056] [<ffffffff8120a76a>] acpi_processor_get_throttling_fadt+0x81/0x8c
[ 0.658056] [<ffffffff8120a3c4>] get_throttling+0x18/0x1f
[ 0.658056] [<ffffffff8106dbbf>] generic_smp_call_function_single_interrupt+0x73/0x95
[ 0.658056] [<ffffffff8101e9bf>] smp_call_function_single_interrupt+0x13/0x23
[ 0.658056] [<ffffffff8100c093>] call_function_single_interrupt+0x13/0x20
[ 0.658056] <EOI> [<ffffffff81012a52>] ? mwait_idle+0x7a/0x95
[ 0.658056] [<ffffffff81012a49>] ? mwait_idle+0x71/0x95
[ 0.658056] [<ffffffff814a8d49>] ? atomic_notifier_call_chain+0xf/0x11
[ 0.658056] [<ffffffff8100a4aa>] ? enter_idle+0x20/0x22
[ 0.658056] [<ffffffff8100a521>] ? cpu_idle+0x75/0xfd
[ 0.658056] [<ffffffff8148bc41>] ? rest_init+0x75/0x77
[ 0.658056] [<ffffffff81801c53>] ? start_kernel+0x36e/0x379
[ 0.658056] [<ffffffff8180129c>] ? x86_64_start_reservations+0xac/0xb0
[ 0.658056] [<ffffffff81801384>] ? x86_64_start_kernel+0xe4/0xeb
[ 0.658056] ---[ end trace a7919e7f17c0a725 ]---
[ 0.803166] ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
[ 0.814078] processor LNXCPU:00: registered as cooling_device0
[ 0.825244] ACPI: Processor [CPU0] (supports 8 throttling states)

Attachments:

(No filename) (226.00 B)

2009-07-02 19:48:41

[permalink] [raw]

Subject: Re: mmotm 2009-06-30-12-50 uploaded

On Thu, 02 Jul 2009 15:16:03 -0400
[email protected] wrote:

> On Tue, 30 Jun 2009 12:51:30 PDT, [email protected] said:
> > The mm-of-the-moment snapshot 2009-06-30-12-50 has been uploaded to
> >
> > http://userweb.kernel.org/~akpm/mmotm/
>
> This whinges at me during early startup:
>
> [ 0.654180] ACPI: Video Device [VID] (multi-head: yes rom: no post: no)
> [ 0.655101] ACPI: SSDT 000000007fe82138 00244 (v01 PmRef Cpu0Ist 00003000 INTL 20050624)
> [ 0.655547] power_supply AC: prop ONLINE=1
> [ 0.655984] ACPI: SSDT 000000007fe81eed 001C6 (v01 PmRef Cpu0Cst 00003001 INTL 20050624)
> [ 0.657061] ------------[ cut here ]------------
> [ 0.657296] WARNING: at kernel/lockdep.c:2143 trace_hardirqs_on_caller+0xc7/0x145()
> [ 0.657664] Hardware name: Latitude D820
> [ 0.657933] Modules linked in:
> [ 0.658056] Pid: 0, comm: swapper Not tainted 2.6.31-rc1-mmotm0630 #1
> [ 0.658056] Call Trace:
> [ 0.658056] <IRQ> [<ffffffff8103ef3d>] warn_slowpath_common+0x77/0x8f
> [ 0.658056] [<ffffffff8120a76a>] ? acpi_processor_get_throttling_fadt+0x81/0x8c
> [ 0.658056] [<ffffffff8103ef64>] warn_slowpath_null+0xf/0x11
> [ 0.658056] [<ffffffff81065ba9>] trace_hardirqs_on_caller+0xc7/0x145
> [ 0.658056] [<ffffffff81065c34>] trace_hardirqs_on+0xd/0xf
> [ 0.658056] [<ffffffff8120a76a>] acpi_processor_get_throttling_fadt+0x81/0x8c
> [ 0.658056] [<ffffffff8120a3c4>] get_throttling+0x18/0x1f
> [ 0.658056] [<ffffffff8106dbbf>] generic_smp_call_function_single_interrupt+0x73/0x95
> [ 0.658056] [<ffffffff8101e9bf>] smp_call_function_single_interrupt+0x13/0x23
> [ 0.658056] [<ffffffff8100c093>] call_function_single_interrupt+0x13/0x20
> [ 0.658056] <EOI> [<ffffffff81012a52>] ? mwait_idle+0x7a/0x95
> [ 0.658056] [<ffffffff81012a49>] ? mwait_idle+0x71/0x95
> [ 0.658056] [<ffffffff814a8d49>] ? atomic_notifier_call_chain+0xf/0x11
> [ 0.658056] [<ffffffff8100a4aa>] ? enter_idle+0x20/0x22
> [ 0.658056] [<ffffffff8100a521>] ? cpu_idle+0x75/0xfd
> [ 0.658056] [<ffffffff8148bc41>] ? rest_init+0x75/0x77
> [ 0.658056] [<ffffffff81801c53>] ? start_kernel+0x36e/0x379
> [ 0.658056] [<ffffffff8180129c>] ? x86_64_start_reservations+0xac/0xb0
> [ 0.658056] [<ffffffff81801384>] ? x86_64_start_kernel+0xe4/0xeb
> [ 0.658056] ---[ end trace a7919e7f17c0a725 ]---
> [ 0.803166] ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
> [ 0.814078] processor LNXCPU:00: registered as cooling_device0
> [ 0.825244] ACPI: Processor [CPU0] (supports 8 throttling states)

apart from having a crappy title, linux-next's

: commit f29876421ec11f7d66f3d982219ef3af9bcccf32
: Author: Rusty Russell <[email protected]>
: AuthorDate: Wed Jul 1 12:37:19 2009 +1000
: Commit: Stephen Rothwell <[email protected]>
: CommitDate: Wed Jul 1 12:37:19 2009 +1000
:
: misc:work_on_cpu-acpi
:

causes get_throttling() to newly be called from an IPI, and lockdep doesn't
like irq-disabled interrupt handlers doing local_irq_enable().

If we rely upon these functions only ever being called from
smp_call_function_single(), and if smp_call_function_single() is
correctly implemented, we should be able to do this:

--- a/drivers/acpi/processor_throttling.c~a
+++ a/drivers/acpi/processor_throttling.c
@@ -616,6 +616,8 @@ static int acpi_processor_get_throttling
u32 duty_mask = 0;
u32 duty_value = 0;

+ WARN_ON_ONCE(!irqs_disabled());
+
if (!pr)
return -EINVAL;

@@ -628,8 +630,6 @@ static int acpi_processor_get_throttling

duty_mask <<= pr->throttling.duty_offset;

- local_irq_disable();
-
value = inl(pr->throttling.address);

/*
@@ -646,8 +646,6 @@ static int acpi_processor_get_throttling

pr->throttling.state = state;

- local_irq_enable();
-
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
"Throttling state is T%d (%d%% throttling applied)\n",
state, pr->throttling.states[state].performance));
@@ -919,6 +917,8 @@ static int acpi_processor_set_throttling
u32 duty_mask = 0;
u32 duty_value = 0;

+ WARN_ON_ONCE(!irqs_disabled());
+
if (!pr)
return -EINVAL;

@@ -948,8 +948,6 @@ static int acpi_processor_set_throttling
duty_mask = ~duty_mask;
}

- local_irq_disable();
-
/*
* Disable throttling by writing a 0 to bit 4. Note that we must
* turn it off before you can change the duty_value.
@@ -975,8 +973,6 @@ static int acpi_processor_set_throttling

pr->throttling.state = state;

- local_irq_enable();
-
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
"Throttling state set to T%d (%d%%)\n", state,
(pr->throttling.states[state].performance ? pr->
_

2009-07-02 20:27:43

[permalink] [raw]

Subject: Re: mmotm 2009-06-30-12-50 uploaded

On Thu, 02 Jul 2009 12:47:26 PDT, Andrew Morton said:

> apart from having a crappy title, linux-next's
>
> : commit f29876421ec11f7d66f3d982219ef3af9bcccf32
> : Author: Rusty Russell <[email protected]>
> : AuthorDate: Wed Jul 1 12:37:19 2009 +1000
> : Commit: Stephen Rothwell <[email protected]>
> : CommitDate: Wed Jul 1 12:37:19 2009 +1000
> :
> : misc:work_on_cpu-acpi
> :
>
> causes get_throttling() to newly be called from an IPI, and lockdep doesn't
> like irq-disabled interrupt handlers doing local_irq_enable().
>
>
> If we rely upon these functions only ever being called from
> smp_call_function_single(), and if smp_call_function_single() is
> correctly implemented, we should be able to do this:

I'll take a leap of faith on the "correctly implemented" part. However,
I admit I'm probably going to wait till Len or somebody agrees on the
"only calledf from function_single()" part being correct before test-driving
the patch...

Attachments:

(No filename) (226.00 B)

2009-07-03 01:52:37

[permalink] [raw]

Subject: mmotm 2009-06-30-12-50 dies during early boot

On Tue, 30 Jun 2009 12:51:30 PDT, [email protected] said:
> The mm-of-the-moment snapshot 2009-06-30-12-50 has been uploaded to
>
> http://userweb.kernel.org/~akpm/mmotm/

(Would have gotten this out the door earlier, but I got confused about what
that 'G' in the 'Tainted' meant, and put off reporting till I could reproduce
it without the NVidia driver. Turns out it was untainted except for the
warning I already reported...)

Dies fairly early during boot, somewhere in the first few lines of rc.sysinit.

It *looks* like it dies in this call:

wake_up_interruptible(&current->real_parent->signal->wait_chldexit);

in selinux_bprm_committed_creds(). Not sure which part of that is the duff
pointer, though...

[ 16.829082] hub 1-2:1.0: hub_suspend
[ 16.848165] usb 1-2: unlink qh256-0001/ffff88007e053140 start 1 [1/0 us]
[ 16.867813] usb 1-2: usb auto-suspend
[ 17.827106] cat used greatest stack depth: 4280 bytes left
[ 17.846392] Oops: 0000 [#1] PREEMPT SMP
[ 17.847007] last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda2/dev
[ 17.847007] CPU 0
[ 17.847007] Modules linked in:
[ 17.847007] Pid: 887, comm: mount Tainted: G W 2.6.31-rc1-mmotm0630 #1 Latitude D820
[ 17.847007] RIP: 0010:[<ffffffff81040873>] [<ffffffff81040873>] child_wait_callback+0x3d/0x5f
[ 17.847007] RSP: 0018:ffff88007f051c28 EFLAGS: 00010046
[ 17.847007] RAX: 000000000000000e RBX: 0000000000000001 RCX: 0000000000000000
[ 17.847007] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff88007eb9bf20
[ 17.847007] RBP: ffff88007f051c28 R08: 0000000000000000 R09: 0000000000000001
[ 17.847007] R10: ffff88007f051c68 R11: ffff88007f051c68 R12: 0000000000000001
[ 17.847007] R13: ffff88007f9965e0 R14: 0000000000000000 R15: 0000000000000000
[ 17.847007] FS: 00007fa8f6c646f0(0000) GS:ffff880002121000(0000) knlGS:0000000000000000
[ 17.847007] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 17.847007] CR2: 0000000000000270 CR3: 000000007fb3f000 CR4: 00000000000006f0
[ 17.847007] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 17.847007] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 17.847007] Process mount (pid: 887, threadinfo ffff88007f050000, task ffff88007eb96a80)
[ 17.847007] Stack:
[ 17.847007] ffff88007f051c78 ffffffff8102df4a 0000000000000000 ffff88007f9965f8
[ 17.847007] <0> ffff88007f051c78 ffff88007f9965c8 0000000000000282 ffff88007e3acbc0
[ 17.847007] <0> ffff88007f051f58 00007fd172b0faf0 ffff88007f051cb8 ffffffff810305d8
[ 17.847007] Call Trace:
[ 17.847007] [<ffffffff8102df4a>] __wake_up_common+0x49/0x7f
[ 17.847007] [<ffffffff810305d8>] __wake_up+0x34/0x48
[ 17.847007] [<ffffffff81176a19>] selinux_bprm_committed_creds+0x11d/0x132
[ 17.847007] [<ffffffff8105be4d>] ? commit_creds+0x1d5/0x1df
[ 17.847007] [<ffffffff8116dc46>] security_bprm_committed_creds+0x11/0x13
[ 17.847007] [<ffffffff810d5420>] install_exec_creds+0x30/0x35
[ 17.847007] [<ffffffff81110de5>] load_elf_binary+0x10d1/0x1990
[ 17.847007] [<ffffffff814a8bc0>] ? sub_preempt_count+0x35/0x48
[ 17.847007] [<ffffffff810d5101>] search_binary_handler+0xbd/0x2cc
[ 17.847007] [<ffffffff8110fd14>] ? load_elf_binary+0x0/0x1990
[ 17.847007] [<ffffffff810d69e8>] do_execve+0x26e/0x3c2
[ 17.847007] [<ffffffff81009b15>] sys_execve+0x5b/0x78
[ 17.847007] [<ffffffff8100b7ca>] stub_execve+0x6a/0xc0
[ 17.847007] Code: 81 00 03 00 00 eb 14 89 c0 48 6b c0 18 48 03 81 c0 02 00 00 48 8b 80 00 03 00 00 48 3b 47 e0 75 21 8b 47 dc 41 89 c0 41 c1 e8 1f <83> b9 70 02 00 00 11 41 0f 95 c1 45 38 c1 74 0b a9 00 00 00 40
[ 17.847007] RIP [<ffffffff81040873>] child_wait_callback+0x3d/0x5f
[ 17.847007] RSP <ffff88007f051c28>
[ 17.847007] CR2: 0000000000000270
[ 17.847007] ---[ end trace a7919e7f17c0a727 ]---
[ 17.847007] note: mount[887] exited with preempt_count 2
[ 27.655913] usb 1-8.3: khubd timed out on ep0in len=0/64
[ 27.655958] BUG: scheduling while atomic: mount/887/0x10000003
[ 27.655960] INFO: lockdep is turned off.
[ 27.655962] Modules linked in:
[ 27.655965] Pid: 887, comm: mount Tainted: G D W 2.6.31-rc1-mmotm0630 #1
[ 27.655967] Call Trace:
[ 27.655973] [<ffffffff81065361>] ? __debug_show_held_locks+0x1b/0x24
[ 27.655978] [<ffffffff81034afb>] __schedule_bug+0x6d/0x72
[ 27.655982] [<ffffffff814a339e>] schedule+0xf0/0x934
[ 27.655987] [<ffffffff810e73ef>] ? mntput_no_expire+0x24/0x145
[ 27.655991] [<ffffffff810cb61d>] ? __cache_free+0x45/0xf1
[ 27.655996] [<ffffffff81035abf>] __cond_resched+0x24/0x39
[ 27.655999] [<ffffffff814a3dad>] _cond_resched+0x2d/0x38
[ 27.656017] [<ffffffff81040ca0>] put_files_struct+0x6c/0xbe
[ 27.656020] [<ffffffff81040d38>] exit_files+0x46/0x4f
[ 27.656024] [<ffffffff81042a58>] do_exit+0x3a6/0x97d
[ 27.656028] [<ffffffff814a732e>] oops_end+0x89/0x8e
[ 27.656032] [<ffffffff81025a6c>] no_context+0x1f1/0x200
[ 27.656036] [<ffffffff81025c21>] __bad_area_nosemaphore+0x1a6/0x1ef
[ 27.656040] [<ffffffff81065b01>] ? trace_hardirqs_on_caller+0x1f/0x145
[ 27.656044] [<ffffffff81064e9f>] ? trace_hardirqs_off_caller+0x1f/0xa2
[ 27.656047] [<ffffffff81064f2f>] ? trace_hardirqs_off+0xd/0xf
[ 27.656051] [<ffffffff81064e9f>] ? trace_hardirqs_off_caller+0x1f/0xa2
[ 27.656055] [<ffffffff81034117>] ? get_parent_ip+0x11/0x41
[ 27.656058] [<ffffffff81025c78>] bad_area_nosemaphore+0xe/0x10
[ 27.656062] [<ffffffff814a8913>] do_page_fault+0x204/0x47c
[ 27.656066] [<ffffffff814a5739>] ? trace_hardirqs_off_thunk+0x3a/0x3c
[ 27.656070] [<ffffffff814a674f>] page_fault+0x1f/0x30
[ 27.656074] [<ffffffff81040873>] ? child_wait_callback+0x3d/0x5f
[ 27.656079] [<ffffffff811bca7e>] ? _raw_spin_lock+0xe3/0x196
[ 27.656083] [<ffffffff8102df4a>] __wake_up_common+0x49/0x7f
[ 27.656087] [<ffffffff810305d8>] __wake_up+0x34/0x48
[ 27.656091] [<ffffffff81176a19>] selinux_bprm_committed_creds+0x11d/0x132
[ 27.656095] [<ffffffff8105be4d>] ? commit_creds+0x1d5/0x1df
[ 27.656098] [<ffffffff8116dc46>] security_bprm_committed_creds+0x11/0x13
[ 27.656102] [<ffffffff810d5420>] install_exec_creds+0x30/0x35
[ 27.656106] [<ffffffff81110de5>] load_elf_binary+0x10d1/0x1990
[ 27.656111] [<ffffffff814a8bc0>] ? sub_preempt_count+0x35/0x48
[ 27.656114] [<ffffffff810d5101>] search_binary_handler+0xbd/0x2cc
[ 27.656118] [<ffffffff8110fd14>] ? load_elf_binary+0x0/0x1990
[ 27.656122] [<ffffffff810d69e8>] do_execve+0x26e/0x3c2
[ 27.656126] [<ffffffff81009b15>] sys_execve+0x5b/0x78
[ 27.656130] [<ffffffff8100b7ca>] stub_execve+0x6a/0xc0
[ 27.656157] mount used greatest stack depth: 3920 bytes left

Attachments:

(No filename) (226.00 B)

2009-07-03 02:21:18

[permalink] [raw]

Subject: Re: mmotm 2009-06-30-12-50 dies during early boot

On Thu, 02 Jul 2009 21:52:28 -0400 [email protected] wrote:

> On Tue, 30 Jun 2009 12:51:30 PDT, [email protected] said:
> > The mm-of-the-moment snapshot 2009-06-30-12-50 has been uploaded to
> >
> > http://userweb.kernel.org/~akpm/mmotm/
>
> (Would have gotten this out the door earlier, but I got confused about what
> that 'G' in the 'Tainted' meant, and put off reporting till I could reproduce
> it without the NVidia driver. Turns out it was untainted except for the
> warning I already reported...)
>
> Dies fairly early during boot, somewhere in the first few lines of rc.sysinit.
>
> It *looks* like it dies in this call:
>
> wake_up_interruptible(&current->real_parent->signal->wait_chldexit);
>
> in selinux_bprm_committed_creds(). Not sure which part of that is the duff
> pointer, though...
>
> [ 16.829082] hub 1-2:1.0: hub_suspend
> [ 16.848165] usb 1-2: unlink qh256-0001/ffff88007e053140 start 1 [1/0 us]
> [ 16.867813] usb 1-2: usb auto-suspend
> [ 17.827106] cat used greatest stack depth: 4280 bytes left
> [ 17.846392] Oops: 0000 [#1] PREEMPT SMP
> [ 17.847007] last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda2/dev
> [ 17.847007] CPU 0
> [ 17.847007] Modules linked in:
> [ 17.847007] Pid: 887, comm: mount Tainted: G W 2.6.31-rc1-mmotm0630 #1 Latitude D820
> [ 17.847007] RIP: 0010:[<ffffffff81040873>] [<ffffffff81040873>] child_wait_callback+0x3d/0x5f
> [ 17.847007] RSP: 0018:ffff88007f051c28 EFLAGS: 00010046
> [ 17.847007] RAX: 000000000000000e RBX: 0000000000000001 RCX: 0000000000000000
> [ 17.847007] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff88007eb9bf20
> [ 17.847007] RBP: ffff88007f051c28 R08: 0000000000000000 R09: 0000000000000001
> [ 17.847007] R10: ffff88007f051c68 R11: ffff88007f051c68 R12: 0000000000000001
> [ 17.847007] R13: ffff88007f9965e0 R14: 0000000000000000 R15: 0000000000000000
> [ 17.847007] FS: 00007fa8f6c646f0(0000) GS:ffff880002121000(0000) knlGS:0000000000000000
> [ 17.847007] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 17.847007] CR2: 0000000000000270 CR3: 000000007fb3f000 CR4: 00000000000006f0
> [ 17.847007] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 17.847007] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 17.847007] Process mount (pid: 887, threadinfo ffff88007f050000, task ffff88007eb96a80)
> [ 17.847007] Stack:
> [ 17.847007] ffff88007f051c78 ffffffff8102df4a 0000000000000000 ffff88007f9965f8
> [ 17.847007] <0> ffff88007f051c78 ffff88007f9965c8 0000000000000282 ffff88007e3acbc0
> [ 17.847007] <0> ffff88007f051f58 00007fd172b0faf0 ffff88007f051cb8 ffffffff810305d8
> [ 17.847007] Call Trace:
> [ 17.847007] [<ffffffff8102df4a>] __wake_up_common+0x49/0x7f
> [ 17.847007] [<ffffffff810305d8>] __wake_up+0x34/0x48
> [ 17.847007] [<ffffffff81176a19>] selinux_bprm_committed_creds+0x11d/0x132
> [ 17.847007] [<ffffffff8105be4d>] ? commit_creds+0x1d5/0x1df
> [ 17.847007] [<ffffffff8116dc46>] security_bprm_committed_creds+0x11/0x13
> [ 17.847007] [<ffffffff810d5420>] install_exec_creds+0x30/0x35
> [ 17.847007] [<ffffffff81110de5>] load_elf_binary+0x10d1/0x1990
> [ 17.847007] [<ffffffff814a8bc0>] ? sub_preempt_count+0x35/0x48
> [ 17.847007] [<ffffffff810d5101>] search_binary_handler+0xbd/0x2cc
> [ 17.847007] [<ffffffff8110fd14>] ? load_elf_binary+0x0/0x1990
> [ 17.847007] [<ffffffff810d69e8>] do_execve+0x26e/0x3c2
> [ 17.847007] [<ffffffff81009b15>] sys_execve+0x5b/0x78
> [ 17.847007] [<ffffffff8100b7ca>] stub_execve+0x6a/0xc0
> [ 17.847007] Code: 81 00 03 00 00 eb 14 89 c0 48 6b c0 18 48 03 81 c0 02 00 00 48 8b 80 00 03 00 00 48 3b 47 e0 75 21 8b 47 dc 41 89 c0 41 c1 e8 1f <83> b9 70 02 00 00 11 41 0f 95 c1 45 38 c1 74 0b a9 00 00 00 40
> [ 17.847007] RIP [<ffffffff81040873>] child_wait_callback+0x3d/0x5f
> [ 17.847007] RSP <ffff88007f051c28>
> [ 17.847007] CR2: 0000000000000270
> [ 17.847007] ---[ end trace a7919e7f17c0a727 ]---

Well I'm not seeing any significant changes to security/selinux/hooks.c
in ages. Perhaps this was a result of some Oleg changes, or some
credentials changes elsewhere.

Something's gone wrong with your oops output - it did't actually tell
us why it oopsed. Perhaps because we've screwed up the printk facility
levels in there and at your loglevel some messages are being
suppressed.

Anyway, scripts/decodecode says

[ 17.847007] Code: 81 00 03 00 00 eb 14 89 c0 48 6b c0 18 48 03 81 c0 02 00 00 48 8b 80 00 03 00 00 48 3b 47 e0 75 21 8b 47 dc 41 89 c0 41 c1 e8 1f <83> b9 70 02 00 00 11 41 0f 95 c1 45 38 c1 74 0b a9 00 00 00 40
All code
========
0: 81 00 03 00 00 eb addl $0xeb000003,(%rax)
6: 14 89 adc $0x89,%al
8: c0 48 6b c0 rorb $0xc0,0x6b(%rax)
c: 18 48 03 sbb %cl,0x3(%rax)
f: 81 c0 02 00 00 48 add $0x48000002,%eax
15: 8b 80 00 03 00 00 mov 0x300(%rax),%eax
1b: 48 3b 47 e0 cmp -0x20(%rdi),%rax
1f: 75 21 jne 0x42
21: 8b 47 dc mov -0x24(%rdi),%eax
24: 41 89 c0 mov %eax,%r8d
27: 41 c1 e8 1f shr $0x1f,%r8d
2b:* 83 b9 70 02 00 00 11 cmpl $0x11,0x270(%rcx) <-- trapping instruction
32: 41 0f 95 c1 setne %r9b
36: 45 38 c1 cmp %r8b,%r9b
39: 74 0b je 0x46
3b: a9 00 00 00 40 test $0x40000000,%eax

Code starting with the faulting instruction
===========================================
0: 83 b9 70 02 00 00 11 cmpl $0x11,0x270(%rcx)
7: 41 0f 95 c1 setne %r9b
b: 45 38 c1 cmp %r8b,%r9b
e: 74 0b je 0x1b
10: a9 00 00 00 40 test $0x40000000,%eax

and your %rcx is zero, so it's a null-pointer deref.

Let me see if I can do another mmotm - perhaps we magically fixed it.

2009-07-03 08:24:19

[permalink] [raw]

Subject: Re: mmotm 2009-06-30-12-50 dies during early boot

On 07/02, Andrew Morton wrote:
>
> On Thu, 02 Jul 2009 21:52:28 -0400 [email protected] wrote:
>
> > On Tue, 30 Jun 2009 12:51:30 PDT, [email protected] said:
> > > The mm-of-the-moment snapshot 2009-06-30-12-50 has been uploaded to
> > >
> > > http://userweb.kernel.org/~akpm/mmotm/
> >
> > (Would have gotten this out the door earlier, but I got confused about what
> > that 'G' in the 'Tainted' meant, and put off reporting till I could reproduce
> > it without the NVidia driver. Turns out it was untainted except for the
> > warning I already reported...)
> >
> > Dies fairly early during boot, somewhere in the first few lines of rc.sysinit.
> >
> > It *looks* like it dies in this call:
> >
> > wake_up_interruptible(&current->real_parent->signal->wait_chldexit);

Thanks! I'll send the patch soon.

selinux_commited_creds() should use __wake_up_parent(), it should not play
with ->wait_cldexit directly.

I wanted to fix this before, but __wake_up_parent() was not exported.
And now I forgot to do this when added child_wait_callback().

My fault.

Oleg.

2009-07-03 09:26:46

[permalink] [raw]

Subject: [PATCH] selinux_bprm_committed_creds: use __wake_up_parent()

(depends on ptrace-__ptrace_detach-do-__wake_up_parent-if-we-reap-the-tracee.patch
which exports __wake_up_parent)

Spotted by [email protected].

selinux_bprm_committed_creds() should not play with ->wait_chldexit, now
that __wake_up_parent() is exported change the code to use this helper.

Signed-off-by: Oleg Nesterov <[email protected]>

--- WAIT/security/selinux/hooks.c~SEL_WAKE_PARENT 2009-06-16 17:01:42.000000000 +0200
+++ WAIT/security/selinux/hooks.c 2009-07-03 11:15:08.000000000 +0200
@@ -2404,7 +2404,7 @@ static void selinux_bprm_committed_creds
/* Wake up the parent if it is waiting so that it can recheck
* wait permission to the new task SID. */
read_lock(&tasklist_lock);
- wake_up_interruptible(&current->real_parent->signal->wait_chldexit);
+ __wake_up_parent(current, current->real_parent);
read_unlock(&tasklist_lock);
}

2009-07-03 09:40:28

by James Morris

[permalink] [raw]

Subject: Re: [PATCH] selinux_bprm_committed_creds: use __wake_up_parent()

On Fri, 3 Jul 2009, Oleg Nesterov wrote:

> (depends on ptrace-__ptrace_detach-do-__wake_up_parent-if-we-reap-the-tracee.patch
> which exports __wake_up_parent)
>
> Spotted by [email protected].
>
> selinux_bprm_committed_creds() should not play with ->wait_chldexit, now
> that __wake_up_parent() is exported change the code to use this helper.
>
> Signed-off-by: Oleg Nesterov <[email protected]>

Acked-by: James Morris <[email protected]>

>
> --- WAIT/security/selinux/hooks.c~SEL_WAKE_PARENT 2009-06-16 17:01:42.000000000 +0200
> +++ WAIT/security/selinux/hooks.c 2009-07-03 11:15:08.000000000 +0200
> @@ -2404,7 +2404,7 @@ static void selinux_bprm_committed_creds
> /* Wake up the parent if it is waiting so that it can recheck
> * wait permission to the new task SID. */
> read_lock(&tasklist_lock);
> - wake_up_interruptible(&current->real_parent->signal->wait_chldexit);
> + __wake_up_parent(current, current->real_parent);
> read_unlock(&tasklist_lock);
> }
>
>

--
James Morris
<[email protected]>

2009-07-03 10:13:58

[permalink] [raw]

Subject: Re: [PATCH] selinux_bprm_committed_creds: use __wake_up_parent()

On Fri, 03 Jul 2009 11:23:11 +0200, Oleg Nesterov said:
> (depends on ptrace-__ptrace_detach-do-__wake_up_parent-if-we-reap-the-tracee.patch
> which exports __wake_up_parent)
>
> Spotted by [email protected].
>
> selinux_bprm_committed_creds() should not play with ->wait_chldexit, now
> that __wake_up_parent() is exported change the code to use this helper.
>
> Signed-off-by: Oleg Nesterov <[email protected]>
>
> --- WAIT/security/selinux/hooks.c~SEL_WAKE_PARENT 2009-06-16 17:01:42.000000000 +0200
> +++ WAIT/security/selinux/hooks.c 2009-07-03 11:15:08.000000000 +0200

Oleg: Thanks muchly - I applied the patch, reverted the mm/vmscan.c patch that
was giving others trouble, and 31-rc1-mmotm0702 is up and running

Feel free to stick a

Tested-By: Valdis Kletnieks <[email protected]>

on it as it goes upstream...

Attachments:

(No filename) (226.00 B)

2009-07-03 10:16:41

by David Howells

[permalink] [raw]

Subject: Re: [PATCH] selinux_bprm_committed_creds: use __wake_up_parent()

Oleg Nesterov <[email protected]> wrote:

> (depends on ptrace-__ptrace_detach-do-__wake_up_parent-if-we-reap-the-tracee.patch
> which exports __wake_up_parent)
>
> Spotted by [email protected].

You probably want to add this as a 'Reported-by' tag.

> selinux_bprm_committed_creds() should not play with ->wait_chldexit, now
> that __wake_up_parent() is exported change the code to use this helper.
>
> Signed-off-by: Oleg Nesterov <[email protected]>

Acked-by: David Howells <[email protected]>

2009-07-03 10:26:48

[permalink] [raw]

Subject: Re: mmotm 2009-06-30-12-50 uploaded

On Thu, 02 Jul 2009 12:47:26 PDT, Andrew Morton said:
> On Thu, 02 Jul 2009 15:16:03 -0400
> [email protected] wrote:

> > [ 0.657296] WARNING: at kernel/lockdep.c:2143 trace_hardirqs_on_caller+0xc7/0x145()

> If we rely upon these functions only ever being called from
> smp_call_function_single(), and if smp_call_function_single() is
> correctly implemented, we should be able to do this:
>
> --- a/drivers/acpi/processor_throttling.c~a
> +++ a/drivers/acpi/processor_throttling.c

That does seem to have scared the warning into hiding - I'm not seeing it
anymore in -mmotm0702. Thanks.

Attachments:

(No filename) (226.00 B)

2009-07-03 10:49:50

[permalink] [raw]

Subject: Re: [PATCH] selinux_bprm_committed_creds: use __wake_up_parent()

On 07/03, [email protected] wrote:
>
> Feel free to stick a
>
> Tested-By: Valdis Kletnieks <[email protected]>

Yes, thanks a lot Valdis!

Oleg.

2009-07-03 16:11:53

[permalink] [raw]

Subject: Re: [PATCH] selinux_bprm_committed_creds: use __wake_up_parent()

On Fri, 3 Jul 2009 11:23:11 +0200 Oleg Nesterov <[email protected]> wrote:

> (depends on ptrace-__ptrace_detach-do-__wake_up_parent-if-we-reap-the-tracee.patch
> which exports __wake_up_parent)
>
> Spotted by [email protected].
>
> selinux_bprm_committed_creds() should not play with ->wait_chldexit, now
> that __wake_up_parent() is exported change the code to use this helper.

That's a bit vague. Why shouldn't it play with wait_chldexit? What
changed to make that wrong?

Is this a -mm fix? If so, which -mm patch introduced the problem?

If not, how come the crash isn't being reported in mainline?

Confused.

> Signed-off-by: Oleg Nesterov <[email protected]>
>
> --- WAIT/security/selinux/hooks.c~SEL_WAKE_PARENT 2009-06-16 17:01:42.000000000 +0200
> +++ WAIT/security/selinux/hooks.c 2009-07-03 11:15:08.000000000 +0200
> @@ -2404,7 +2404,7 @@ static void selinux_bprm_committed_creds
> /* Wake up the parent if it is waiting so that it can recheck
> * wait permission to the new task SID. */
> read_lock(&tasklist_lock);
> - wake_up_interruptible(&current->real_parent->signal->wait_chldexit);
> + __wake_up_parent(current, current->real_parent);
> read_unlock(&tasklist_lock);
> }
>

2009-07-04 08:18:20