Re: [patch 00/38] 2.6.24-stable review
Hi stable-team,
Could you please include the attached patch [1] to the next stable release.
The patch fixes the otherwise unusable bluetooth uart on pxa25x . The patch is
written by Russell King [1] who also gave his OK for stable inclusion [2].
The patch is also available as commit a0dd005d1d9f4c3beab52086f3844ef9342d1e67
to Linus' tree.
Thanks,
Uli
[1] http://marc.info/?l=linux-arm-kernel=120298366510315
[2] http://marc.info/?l=linux-arm-kernel=120384388411097
diff --git a/arch/arm/mach-pxa/clock.c b/arch/arm/mach-pxa/clock.c
index 83ef5ec..df5ae27 100644
--- a/arch/arm/mach-pxa/clock.c
+++ b/arch/arm/mach-pxa/clock.c
@@ -23,18 +23,27 @@ static LIST_HEAD(clocks);
static DEFINE_MUTEX(clocks_mutex);
static DEFINE_SPINLOCK(clocks_lock);
+static struct clk *clk_lookup(struct device *dev, const char *id)
+{
+ struct clk *p;
+
+ list_for_each_entry(p, , node)
+ if (strcmp(id, p->name) == 0 && p->dev == dev)
+ return p;
+
+ return NULL;
+}
+
struct clk *clk_get(struct device *dev, const char *id)
{
struct clk *p, *clk = ERR_PTR(-ENOENT);
mutex_lock(_mutex);
- list_for_each_entry(p, , node) {
- if (strcmp(id, p->name) == 0 &&
- (p->dev == NULL || p->dev == dev)) {
- clk = p;
- break;
- }
- }
+ p = clk_lookup(dev, id);
+ if (!p)
+ p = clk_lookup(NULL, id);
+ if (p)
+ clk = p;
mutex_unlock(_mutex);
return clk;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/38] 2.6.24-stable review
Hi stable-team,
Could you please include the attached patch [1] to the next stable release.
The patch fixes the otherwise unusable bluetooth uart on pxa25x . The patch is
written by Russell King [1] who also gave his OK for stable inclusion [2].
The patch is also available as commit a0dd005d1d9f4c3beab52086f3844ef9342d1e67
to Linus' tree.
Thanks,
Uli
[1] http://marc.info/?l=linux-arm-kernelm=120298366510315
[2] http://marc.info/?l=linux-arm-kernelm=120384388411097
diff --git a/arch/arm/mach-pxa/clock.c b/arch/arm/mach-pxa/clock.c
index 83ef5ec..df5ae27 100644
--- a/arch/arm/mach-pxa/clock.c
+++ b/arch/arm/mach-pxa/clock.c
@@ -23,18 +23,27 @@ static LIST_HEAD(clocks);
static DEFINE_MUTEX(clocks_mutex);
static DEFINE_SPINLOCK(clocks_lock);
+static struct clk *clk_lookup(struct device *dev, const char *id)
+{
+ struct clk *p;
+
+ list_for_each_entry(p, clocks, node)
+ if (strcmp(id, p-name) == 0 p-dev == dev)
+ return p;
+
+ return NULL;
+}
+
struct clk *clk_get(struct device *dev, const char *id)
{
struct clk *p, *clk = ERR_PTR(-ENOENT);
mutex_lock(clocks_mutex);
- list_for_each_entry(p, clocks, node) {
- if (strcmp(id, p-name) == 0
- (p-dev == NULL || p-dev == dev)) {
- clk = p;
- break;
- }
- }
+ p = clk_lookup(dev, id);
+ if (!p)
+ p = clk_lookup(NULL, id);
+ if (p)
+ clk = p;
mutex_unlock(clocks_mutex);
return clk;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: ramdisk
On Tuesday, 4. September 2007, linux-os (Dick Johnson) wrote: > On Mon, 3 Sep 2007, Xu Yang wrote: > > Hi everyone, > > > > I want to use ramdisk to boot my filesystem, as I can't use NFS and > > harddisk. > > > > I have load the ramdisk into the ram memory (start address :0x400) > > > > and in the boot options I specified : root =dev/ram0 initrd=0x400 > > Since you don't know what the default directory is, perhaps > root should be /dev/ram0. Also, make sure you actually create > those device nodes in /dev > Hey Dick, where exactly (on which file system) is Xu supposed to create the device nodes? ;-) Xu's problem is, he can't mount his _root_ filesystem in the first place. Therefore I doubt it'd help to have some device nodes somewhere ... Xu, all answers to your posting commented on your kernel command line. The command line you quoted contains "root =dev/ram0". You probably meant to write "root=/dev/ram0". To not waste our time, please clarify if this was a typo before asking further questions. regards, Uli -- --- ROAD ...the handyPC Company - - - ) ) ) Uli Luckas Software Development ROAD GmbH Bennigsenstr. 14 | 12159 Berlin | Germany fon: +49 (30) 230069 - 64 | fax: +49 (30) 230069 - 69 url: www.road.de Amtsgericht Charlottenburg: HRB 96688 B Managing directors: Hans-Peter Constien, Hubertus von Streit - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ramdisk
On Tuesday, 4. September 2007, linux-os (Dick Johnson) wrote: On Mon, 3 Sep 2007, Xu Yang wrote: Hi everyone, I want to use ramdisk to boot my filesystem, as I can't use NFS and harddisk. I have load the ramdisk into the ram memory (start address :0x400) and in the boot options I specified : root =dev/ram0 initrd=0x400 Since you don't know what the default directory is, perhaps root should be /dev/ram0. Also, make sure you actually create those device nodes in /dev Hey Dick, where exactly (on which file system) is Xu supposed to create the device nodes? ;-) Xu's problem is, he can't mount his _root_ filesystem in the first place. Therefore I doubt it'd help to have some device nodes somewhere ... Xu, all answers to your posting commented on your kernel command line. The command line you quoted contains root =dev/ram0. You probably meant to write root=/dev/ram0. To not waste our time, please clarify if this was a typo before asking further questions. regards, Uli -- --- ROAD ...the handyPC Company - - - ) ) ) Uli Luckas Software Development ROAD GmbH Bennigsenstr. 14 | 12159 Berlin | Germany fon: +49 (30) 230069 - 64 | fax: +49 (30) 230069 - 69 url: www.road.de Amtsgericht Charlottenburg: HRB 96688 B Managing directors: Hans-Peter Constien, Hubertus von Streit - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: parse_tag_ramdisk
On Thursday, 30. August 2007, Xu Yang wrote: > Hi Uli, > > > thanks for your reply. > > just have a question, where is the tag list, how can i modify this? > If you don't know where the list is created, how do you now that it contains a ramdisk tag? There is a chance, that the kernel does not even get a ram disk tag at all. This would also explain, why it is not parsed ;-) The tag list is supplied by your bootloader. How the bootloader creates the list and how to change the order depends on your bootloader. You probably have to read (and patch) it's source code. regards, Uli -- --- ROAD ...the handyPC Company - - - ) ) ) Uli Luckas Software Development ROAD GmbH Bennigsenstr. 14 | 12159 Berlin | Germany fon: +49 (30) 230069 - 64 | fax: +49 (30) 230069 - 69 url: www.road.de Amtsgericht Charlottenburg: HRB 96688 B Managing directors: Hans-Peter Constien, Hubertus von Streit - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: parse_tag_ramdisk
On Thursday, 30. August 2007, Xu Yang wrote: > Hi guys, > > > I found that in the function parse_tag_ramdisk , the setup_ramdisk is > called. is it true that in the setup_ramdisk the location ot the > initrd is specified? > > it seems that in my case the parse_tag_ramdisk is never accessed. what > might cause this? > Hi Xu, I didn't get down to completely debugging this problem. But for no obvious reason, parsing seems to ends after it hits a command line tag. Try putting the command line tag last in the tag list and see if that helps. Regards Uli -- --- ROAD ...the handyPC Company - - - ) ) ) Uli Luckas Software Development ROAD GmbH Bennigsenstr. 14 | 12159 Berlin | Germany fon: +49 (30) 230069 - 64 | fax: +49 (30) 230069 - 69 url: www.road.de Amtsgericht Charlottenburg: HRB 96688 B Managing directors: Hans-Peter Constien, Hubertus von Streit - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: parse_tag_ramdisk
On Thursday, 30. August 2007, Xu Yang wrote: Hi guys, I found that in the function parse_tag_ramdisk , the setup_ramdisk is called. is it true that in the setup_ramdisk the location ot the initrd is specified? it seems that in my case the parse_tag_ramdisk is never accessed. what might cause this? Hi Xu, I didn't get down to completely debugging this problem. But for no obvious reason, parsing seems to ends after it hits a command line tag. Try putting the command line tag last in the tag list and see if that helps. Regards Uli -- --- ROAD ...the handyPC Company - - - ) ) ) Uli Luckas Software Development ROAD GmbH Bennigsenstr. 14 | 12159 Berlin | Germany fon: +49 (30) 230069 - 64 | fax: +49 (30) 230069 - 69 url: www.road.de Amtsgericht Charlottenburg: HRB 96688 B Managing directors: Hans-Peter Constien, Hubertus von Streit - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: parse_tag_ramdisk
On Thursday, 30. August 2007, Xu Yang wrote: Hi Uli, thanks for your reply. just have a question, where is the tag list, how can i modify this? If you don't know where the list is created, how do you now that it contains a ramdisk tag? There is a chance, that the kernel does not even get a ram disk tag at all. This would also explain, why it is not parsed ;-) The tag list is supplied by your bootloader. How the bootloader creates the list and how to change the order depends on your bootloader. You probably have to read (and patch) it's source code. regards, Uli -- --- ROAD ...the handyPC Company - - - ) ) ) Uli Luckas Software Development ROAD GmbH Bennigsenstr. 14 | 12159 Berlin | Germany fon: +49 (30) 230069 - 64 | fax: +49 (30) 230069 - 69 url: www.road.de Amtsgericht Charlottenburg: HRB 96688 B Managing directors: Hans-Peter Constien, Hubertus von Streit - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/68] 0 -> NULL, for arch/blackfin
On Friday, 27. July 2007, Bryan Wu wrote: > On Fri, 2007-07-27 at 11:44 +0200, Yoann Padioleau wrote: > > When comparing a pointer, it's clearer to compare it to NULL than to 0. > > > > Here is an excerpt of the semantic patch: > > > > @@ > > expression *E; > > @@ > > > > E == > > - 0 > > + NULL > > > > @@ > > expression *E; > > @@ > > > > E != > > - 0 > > + NULL > > > > Signed-off-by: Yoann Padioleau <[EMAIL PROTECTED]> > > Cc: [EMAIL PROTECTED] > > Cc: [EMAIL PROTECTED] > > Cc: [EMAIL PROTECTED] > > --- > > > > traps.c |2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/arch/blackfin/kernel/traps.c b/arch/blackfin/kernel/traps.c > > index 3909f5b..691c66d 100644 > > --- a/arch/blackfin/kernel/traps.c > > +++ b/arch/blackfin/kernel/traps.c > > @@ -546,7 +546,7 @@ void dump_bfin_regs(struct pt_regs *fp, > > } > > > > printk(KERN_EMERG "return address: [0x%p]; contents of:", retaddr); > > - if (retaddr != 0 && retaddr <= (void *)physical_mem_end > > + if (retaddr != NULL && retaddr <= (void *)physical_mem_end > > #if L1_CODE_LENGTH != 0 > > /* FIXME: Copy the code out of L1 Instruction SRAM through dma > >memcpy. */ > > Why not just use " if (!E)" instead of " if (E != NULL)"? > more readable? > Or even "if (E)" Uli -- --- ROAD ...the handyPC Company - - - ) ) ) Uli Luckas Software Development ROAD GmbH Bennigsenstr. 14 | 12159 Berlin | Germany fon: +49 (30) 230069 - 64 | fax: +49 (30) 230069 - 69 url: www.road.de Amtsgericht Charlottenburg: HRB 96688 B Managing directors: Hans-Peter Constien, Hubertus von Streit - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/68] 0 - NULL, for arch/blackfin
On Friday, 27. July 2007, Bryan Wu wrote: On Fri, 2007-07-27 at 11:44 +0200, Yoann Padioleau wrote: When comparing a pointer, it's clearer to compare it to NULL than to 0. Here is an excerpt of the semantic patch: @@ expression *E; @@ E == - 0 + NULL @@ expression *E; @@ E != - 0 + NULL Signed-off-by: Yoann Padioleau [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] --- traps.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/blackfin/kernel/traps.c b/arch/blackfin/kernel/traps.c index 3909f5b..691c66d 100644 --- a/arch/blackfin/kernel/traps.c +++ b/arch/blackfin/kernel/traps.c @@ -546,7 +546,7 @@ void dump_bfin_regs(struct pt_regs *fp, } printk(KERN_EMERG return address: [0x%p]; contents of:, retaddr); - if (retaddr != 0 retaddr = (void *)physical_mem_end + if (retaddr != NULL retaddr = (void *)physical_mem_end #if L1_CODE_LENGTH != 0 /* FIXME: Copy the code out of L1 Instruction SRAM through dma memcpy. */ Why not just use if (!E) instead of if (E != NULL)? more readable? Or even if (E) Uli -- --- ROAD ...the handyPC Company - - - ) ) ) Uli Luckas Software Development ROAD GmbH Bennigsenstr. 14 | 12159 Berlin | Germany fon: +49 (30) 230069 - 64 | fax: +49 (30) 230069 - 69 url: www.road.de Amtsgericht Charlottenburg: HRB 96688 B Managing directors: Hans-Peter Constien, Hubertus von Streit - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21.5 june 30th to july 1st date hang?
On Tuesday, 3. July 2007, Chuck Ebbert wrote: > On 07/03/2007 03:28 PM, Chris Friesen wrote: > > Arne Georg Gleditsch wrote: > >> An interesting exercise might be to > >> code up a small program to call adjtimex with timex.status |= STA_INS, > >> to see if this can trigger the problem. > > > > Setting the date to just before midnight June 30 UTC and then running > > the following as root triggered the crash on a modified 2.6.10. Anyone > > see anything wrong with the code below, or is this a valid indication of > > a bug in the leap second code? > > Fixed: > http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=comm >itdiff;h=746976a301ac9c9aa10d7d42454f8d6cdad8ff2b > Hi Chris, does that qualify for inclusion into 2.6.21.6? regards, Uli -- --- ROAD ...the handyPC Company - - - ) ) ) Uli Luckas Software Development ROAD GmbH Bennigsenstr. 14 | 12159 Berlin | Germany fon: +49 (30) 230069 - 64 | fax: +49 (30) 230069 - 69 url: www.road.de Amtsgericht Charlottenburg: HRB 96688 B Managing directors: Hans-Peter Constien, Hubertus von Streit - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21.5 june 30th to july 1st date hang?
On Tuesday, 3. July 2007, Chuck Ebbert wrote: On 07/03/2007 03:28 PM, Chris Friesen wrote: Arne Georg Gleditsch wrote: An interesting exercise might be to code up a small program to call adjtimex with timex.status |= STA_INS, to see if this can trigger the problem. Setting the date to just before midnight June 30 UTC and then running the following as root triggered the crash on a modified 2.6.10. Anyone see anything wrong with the code below, or is this a valid indication of a bug in the leap second code? Fixed: http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=comm itdiff;h=746976a301ac9c9aa10d7d42454f8d6cdad8ff2b Hi Chris, does that qualify for inclusion into 2.6.21.6? regards, Uli -- --- ROAD ...the handyPC Company - - - ) ) ) Uli Luckas Software Development ROAD GmbH Bennigsenstr. 14 | 12159 Berlin | Germany fon: +49 (30) 230069 - 64 | fax: +49 (30) 230069 - 69 url: www.road.de Amtsgericht Charlottenburg: HRB 96688 B Managing directors: Hans-Peter Constien, Hubertus von Streit - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21.5 june 30th to july 1st date hang?
On Tuesday, 3. July 2007, Fortier,Vincent [Montreal] wrote: > Hi all, > > All my servers and workstations running a 2.6.21.5 kernel hanged exactly > when the date shift from june 30th to july 1st. > Same thing here on two machines with plain vanilla 2.6.21.(3/4), on debian testing & debian unstable. regards, Uli -- --- ROAD ...the handyPC Company - - - ) ) ) Uli Luckas Software Development ROAD GmbH Bennigsenstr. 14 | 12159 Berlin | Germany fon: +49 (30) 230069 - 64 | fax: +49 (30) 230069 - 69 url: www.road.de Amtsgericht Charlottenburg: HRB 96688 B Managing directors: Hans-Peter Constien, Hubertus von Streit - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21.5 june 30th to july 1st date hang?
On Tuesday, 3. July 2007, Fortier,Vincent [Montreal] wrote: Hi all, All my servers and workstations running a 2.6.21.5 kernel hanged exactly when the date shift from june 30th to july 1st. Same thing here on two machines with plain vanilla 2.6.21.(3/4), on debian testing debian unstable. regards, Uli -- --- ROAD ...the handyPC Company - - - ) ) ) Uli Luckas Software Development ROAD GmbH Bennigsenstr. 14 | 12159 Berlin | Germany fon: +49 (30) 230069 - 64 | fax: +49 (30) 230069 - 69 url: www.road.de Amtsgericht Charlottenburg: HRB 96688 B Managing directors: Hans-Peter Constien, Hubertus von Streit - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Mounting MMC card
On Friday, 29. June 2007, Midhun Agnihotram wrote: > Hi All, > > > Let's try something a lot less complex than mounting. Try running: > > dd if=/dev/mmcblk0 of=/dev/null count=100 > > Here goes the output(error). > > / # dd if=/dev/mmcblk0 of=/dev/null count=100 > dd: can't open '/dev/mmcblk0': No such device or address > > The /dev is has the following: > > / # ls -l /dev | grep mmc > brwxrwxrwx1 00254, 0 Jun 26 2007 mmcblk0 > brwxrwxrwx1 00254, 1 Jun 26 2007 mmcblk0p0 > brwxrwxrwx1 00254, 2 Jun 26 2007 mmcblk0p1 > brwxrwxrwx1 00254, 3 Jun 26 2007 mmcblk0p2 > brwxrwxrwx1 00254, 4 Jun 26 2007 mmcblk0p3 > If I remember correctly, mmc devices did not have fixed majors/minors allocated until recently. Either get a recent kernel or use some kind of hotplug (udev) scripts to create your device nodes with dynamically allocated major/minors. Regards Uli -- --- ROAD ...the handyPC Company - - - ) ) ) Uli Luckas Software Development ROAD GmbH Bennigsenstr. 14 | 12159 Berlin | Germany fon: +49 (30) 230069 - 64 | fax: +49 (30) 230069 - 69 url: www.road.de Amtsgericht Charlottenburg: HRB 96688 B Managing directors: Hans-Peter Constien, Hubertus von Streit - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Mounting MMC card
On Friday, 29. June 2007, Midhun Agnihotram wrote: Hi All, Let's try something a lot less complex than mounting. Try running: dd if=/dev/mmcblk0 of=/dev/null count=100 Here goes the output(error). / # dd if=/dev/mmcblk0 of=/dev/null count=100 dd: can't open '/dev/mmcblk0': No such device or address The /dev is has the following: / # ls -l /dev | grep mmc brwxrwxrwx1 00254, 0 Jun 26 2007 mmcblk0 brwxrwxrwx1 00254, 1 Jun 26 2007 mmcblk0p0 brwxrwxrwx1 00254, 2 Jun 26 2007 mmcblk0p1 brwxrwxrwx1 00254, 3 Jun 26 2007 mmcblk0p2 brwxrwxrwx1 00254, 4 Jun 26 2007 mmcblk0p3 If I remember correctly, mmc devices did not have fixed majors/minors allocated until recently. Either get a recent kernel or use some kind of hotplug (udev) scripts to create your device nodes with dynamically allocated major/minors. Regards Uli -- --- ROAD ...the handyPC Company - - - ) ) ) Uli Luckas Software Development ROAD GmbH Bennigsenstr. 14 | 12159 Berlin | Germany fon: +49 (30) 230069 - 64 | fax: +49 (30) 230069 - 69 url: www.road.de Amtsgericht Charlottenburg: HRB 96688 B Managing directors: Hans-Peter Constien, Hubertus von Streit - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm] PM: Prevent frozen user mode helpers from failing the freezing of tasks (rev. 2)
On Monday, 25. June 2007, Rafael J. Wysocki wrote:
> [I hope the ACKs still apply.]
>
Mine does
> +static void helper_lock(void)
> +{
> + atomic_inc(_helpers);
> + smp_mb__after_atomic_inc();
> +}
> +
> +static void helper_unlock(void)
> +{
> + if (atomic_dec_and_test(_helpers))
> + wake_up(_helpers_waitq);
> +}
> +
> +static void register_pm_notifier_callback(void)
> +{
> + pm_notifier(usermodehelper_pm_callback, 0);
> +}
> +#else /* CONFIG_PM */
> +static inline void helper_lock(void) {}
> +static inline void helper_unlock(void) {}
> +static inline void register_pm_notifier_callback(void) {}
>
Sorry for not realising this before, but I think, we should also inline the
actual implementations of helper_lock, helper_unlock and
register_pm_notifier_callback
Regards
Uli
--
--- ROAD ...the handyPC Company - - - ) ) )
Uli Luckas
Software Development
ROAD GmbH
Bennigsenstr. 14 | 12159 Berlin | Germany
fon: +49 (30) 230069 - 64 | fax: +49 (30) 230069 - 69
url: www.road.de
Amtsgericht Charlottenburg: HRB 96688 B
Managing directors: Hans-Peter Constien, Hubertus von Streit
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm] PM: Prevent frozen user mode helpers from failing the freezing of tasks (rev. 2)
On Monday, 25. June 2007, Rafael J. Wysocki wrote:
[I hope the ACKs still apply.]
Mine does
+static void helper_lock(void)
+{
+ atomic_inc(running_helpers);
+ smp_mb__after_atomic_inc();
+}
+
+static void helper_unlock(void)
+{
+ if (atomic_dec_and_test(running_helpers))
+ wake_up(running_helpers_waitq);
+}
+
+static void register_pm_notifier_callback(void)
+{
+ pm_notifier(usermodehelper_pm_callback, 0);
+}
+#else /* CONFIG_PM */
+static inline void helper_lock(void) {}
+static inline void helper_unlock(void) {}
+static inline void register_pm_notifier_callback(void) {}
Sorry for not realising this before, but I think, we should also inline the
actual implementations of helper_lock, helper_unlock and
register_pm_notifier_callback
Regards
Uli
--
--- ROAD ...the handyPC Company - - - ) ) )
Uli Luckas
Software Development
ROAD GmbH
Bennigsenstr. 14 | 12159 Berlin | Germany
fon: +49 (30) 230069 - 64 | fax: +49 (30) 230069 - 69
url: www.road.de
Amtsgericht Charlottenburg: HRB 96688 B
Managing directors: Hans-Peter Constien, Hubertus von Streit
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH -mm] PM: Prevent frozen user mode helpers from failing the freezing of tasks
On Monday, 18. June 2007, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki <[EMAIL PROTECTED]> > > At present, if a user mode helper is running while > usermodehelper_pm_callback() is executed, the helper may be frozen and the > completion in > call_usermodehelper_exec() won't be completed until user space processes > are thawed. As a result, the freezing of kernel threads may fail, which is > not desirable. > > Prevent this from happening by introducing a counter of running user mode > helpers and allowing usermodehelper_pm_callback() to succeed for > action = PM_HIBERNATION_PREPARE or action = PM_SUSPEND_PREPARE only if > there are no helpers running. [Namely, usermodehelper_pm_callback() waits > for at most RUNNING_HELPERS_TIMEOUT for the number of running helpers to > become zero and fails if that doesn't happen.] > > Special thanks to Uli Luckas <[EMAIL PROTECTED]> for reviewing the previous > versions of this patch and for very useful comments. > Acked-by: Uli Luckas <[EMAIL PROTECTED]> Regards, Uli -- --- ROAD ...the handyPC Company - - - ) ) ) Uli Luckas Software Development ROAD GmbH Bennigsenstr. 14 | 12159 Berlin | Germany fon: +49 (30) 230069 - 64 | fax: +49 (30) 230069 - 69 url: www.road.de Amtsgericht Charlottenburg: HRB 96688 B Managing directors: Hans-Peter Constien, Hubertus von Streit - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH -mm] PM: Prevent frozen user mode helpers from failing the freezing of tasks
On Monday, 18. June 2007, Rafael J. Wysocki wrote: From: Rafael J. Wysocki [EMAIL PROTECTED] At present, if a user mode helper is running while usermodehelper_pm_callback() is executed, the helper may be frozen and the completion in call_usermodehelper_exec() won't be completed until user space processes are thawed. As a result, the freezing of kernel threads may fail, which is not desirable. Prevent this from happening by introducing a counter of running user mode helpers and allowing usermodehelper_pm_callback() to succeed for action = PM_HIBERNATION_PREPARE or action = PM_SUSPEND_PREPARE only if there are no helpers running. [Namely, usermodehelper_pm_callback() waits for at most RUNNING_HELPERS_TIMEOUT for the number of running helpers to become zero and fails if that doesn't happen.] Special thanks to Uli Luckas [EMAIL PROTECTED] for reviewing the previous versions of this patch and for very useful comments. Acked-by: Uli Luckas [EMAIL PROTECTED] Regards, Uli -- --- ROAD ...the handyPC Company - - - ) ) ) Uli Luckas Software Development ROAD GmbH Bennigsenstr. 14 | 12159 Berlin | Germany fon: +49 (30) 230069 - 64 | fax: +49 (30) 230069 - 69 url: www.road.de Amtsgericht Charlottenburg: HRB 96688 B Managing directors: Hans-Peter Constien, Hubertus von Streit - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm 2/2] PM: Disable usermode helper before hibernation and suspend
On Monday, 18. June 2007, you wrote: > On Monday, 18 June 2007 12:51, Uli Luckas wrote: > > On Sunday, 17. June 2007, you wrote: > > > On Friday, 15 June 2007 23:36, Rafael J. Wysocki wrote: > > > > On Friday, 15 June 2007 15:08, Uli Luckas wrote: > > > > > On Monday, 4. June 2007, Rafael J. Wysocki wrote: > > > > > > From: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > > > > > > > > > Use a hibernation and suspend notifier to disable the user mode > > > > > > helper before a hibernation/suspend and enable it after the > > > > > > operation. > > > > > > > > > > Hi Rafael, > > > > > I have a couple of questions, regarding this patch ... > > > > > > > > > > 2) how does your patch prevent wait_for_completion() to hang > > > > > during freezing if usermodehelper_pm_callback is called _after_ the > > > > > above check? > > > > > > > > It doesn't. Once the helper is running, we can't distinguish it from > > > > any other user land process. > > > > > > > > Still, it narrows the window quite a bit. > > > > > > Okay, I think we can help it a bit. Please tell me what you think of > > > the following patch (on top of 2.6.22-rc4-mm2). > > > > Hi Rafael, > > Thanks for your work. I haven't found the time to actually test your > > patch but in general it looks like a valid aproach. > > I think there is one problem though. You need to have your wait queue > > woken up when you update (atomic_dec) running_helpers. Otherwise you end > > up always waiting the full RUNNING_HELPERS_TIMEOUT. > > Yeah, right. I tend to forget about obvious things. :-( > Great. As far as I can see, this patch should now fix the situation except under heavy load where it would abort the attempted suspend. I can live with that and it is a whole lot better than it was before - Thanks. > Besides, I think that the _pm_callback need not be compiled if CONFIG_PM is > unset. > Should work but is probably beneath what you intended to do. I'll comment further down... > If you can, please have a look at the next version of the patch > (appended). > One more topic to keep in mind for the future. None of the callers of call_usermode_helper* expect a return value of EBUSY nor do they handle it correctly. If auto loading of a module for example fails, a permanent error is usually assumed and no retry attempts are made. > Greetings, > Rafael > > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> > --- > kernel/kmod.c | 76 > ++ 1 file changed, > 66 insertions(+), 10 deletions(-) > > Index: linux-2.6.22-rc4-mm2/kernel/kmod.c > === > --- linux-2.6.22-rc4-mm2.orig/kernel/kmod.c > +++ linux-2.6.22-rc4-mm2/kernel/kmod.c > @@ -41,14 +41,6 @@ extern int max_threads; > > static struct workqueue_struct *khelper_wq; > > -/* > - * If set, both call_usermodehelper_keys() and call_usermodehelper_pipe() > exit - * immediately returning -EBUSY. Used for preventing user land > processes from - * being created after the user land has been frozen during > a system-wide - * hibernation or suspend operation. > - */ > -static int usermodehelper_disabled; > - > #ifdef CONFIG_KMOD > > /* > @@ -275,6 +267,30 @@ static void __call_usermodehelper(struct > } > } > > +#ifdef CONFIG_PM > +/* > + * If set and if call_usermodehelper_exec() is supposed to wait, it will > exit + * immediately returning -EBUSY (used for preventing user land > processes from + * being created after the user land has been frozen during > a system-wide + * hibernation or suspend operation). > + */ > +static int usermodehelper_disabled; > + > +/* Number of helpers running */ > +static atomic_t running_helpers = ATOMIC_INIT(0); > + > +/* > + * Wait queue head used by usermodehelper_pm_callback() to wait for all > running + * helpers to finish. > + */ > +static DECLARE_WAIT_QUEUE_HEAD(running_helpers_waitq); > + > +/* > + * Time to wait for running_helpers to become zero before the setting of > + * usermodehelper_disabled in usermodehelper_pm_callback() fails > + */ > +#define RUNNING_HELPERS_TIMEOUT (5 * HZ) > + > static int usermodehelper_pm_callback(struct notifier_block *nfb, > unsigned long action, > void *ignored) > @@ -283,7 +299,15 @@ static int usermodehelper_pm_callback(st > ca
Re: [PATCH -mm 2/2] PM: Disable usermode helper before hibernation and suspend
On Sunday, 17. June 2007, you wrote:
> On Friday, 15 June 2007 23:36, Rafael J. Wysocki wrote:
> > On Friday, 15 June 2007 15:08, Uli Luckas wrote:
> > > On Monday, 4. June 2007, Rafael J. Wysocki wrote:
> > > > From: Rafael J. Wysocki <[EMAIL PROTECTED]>
> > > >
> > > > Use a hibernation and suspend notifier to disable the user mode
> > > > helper before a hibernation/suspend and enable it after the
> > > > operation.
> > >
> > > Hi Rafael,
> > > I have a couple of questions, regarding this patch ...
> > > 2) how does your patch prevent wait_for_completion() to hang
> > > during freezing if usermodehelper_pm_callback is called _after_ the
> > > above check?
> >
> > It doesn't. Once the helper is running, we can't distinguish it from any
> > other user land process.
> >
> > Still, it narrows the window quite a bit.
>
> Okay, I think we can help it a bit. Please tell me what you think of the
> following patch (on top of 2.6.22-rc4-mm2).
>
Hi Rafael,
Thanks for your work. I haven't found the time to actually test your patch but
in general it looks like a valid aproach.
I think there is one problem though. You need to have your wait queue woken up
when you update (atomic_dec) running_helpers. Otherwise you end up always
waiting the full RUNNING_HELPERS_TIMEOUT.
> Index: linux-2.6.22-rc4-mm2/kernel/kmod.c
> ===
> --- linux-2.6.22-rc4-mm2.orig/kernel/kmod.c
> +++ linux-2.6.22-rc4-mm2/kernel/kmod.c
> @@ -49,6 +49,15 @@ static struct workqueue_struct *khelper_
> */
> static int usermodehelper_disabled;
>
> +/* Number of helpers running */
> +static atomic_t running_helpers = ATOMIC_INIT(0);
> +
> +/*
> + * Time to wait for running_helpers to become zero before the setting of
> + * usermodehelper_disabled in usermodehelper_pm_callback() fails
> + */
> +#define RUNNING_HELPERS_TIMEOUT (5 * HZ)
> +
> #ifdef CONFIG_KMOD
>
> /*
> @@ -279,11 +288,20 @@ static int usermodehelper_pm_callback(st
> unsigned long action,
> void *ignored)
> {
> + DECLARE_WAIT_QUEUE_HEAD_ONSTACK(waiting);
> +
> switch (action) {
> case PM_HIBERNATION_PREPARE:
> case PM_SUSPEND_PREPARE:
> usermodehelper_disabled = 1;
> - return NOTIFY_OK;
> + wait_event_timeout(waiting, atomic_read(_helpers) == 0,
> + RUNNING_HELPERS_TIMEOUT);
> + if (atomic_read(_helpers) == 0) {
> + return NOTIFY_OK;
> + } else {
> + usermodehelper_disabled = 0;
> + return NOTIFY_BAD;
> + }
> case PM_POST_HIBERNATION:
> case PM_POST_SUSPEND:
> usermodehelper_disabled = 0;
> @@ -397,12 +415,13 @@ int call_usermodehelper_exec(struct subp
> DECLARE_COMPLETION_ONSTACK(done);
> int retval;
>
> + atomic_inc(_helpers);
> if (sub_info->path[0] == '\0') {
> retval = 0;
> goto out;
> }
>
> - if (!khelper_wq || usermodehelper_disabled) {
> + if (!khelper_wq || (wait != UMH_NO_WAIT && usermodehelper_disabled)) {
> retval = -EBUSY;
> goto out;
> }
> @@ -418,6 +437,7 @@ int call_usermodehelper_exec(struct subp
>
>out:
> call_usermodehelper_freeinfo(sub_info);
> + atomic_dec(_helpers);
> return retval;
> }
> EXPORT_SYMBOL(call_usermodehelper_exec);
--
--- ROAD ...the handyPC Company - - - ) ) )
Uli Luckas
Software Development
ROAD GmbH
Bennigsenstr. 14 | 12159 Berlin | Germany
fon: +49 (30) 230069 - 64 | fax: +49 (30) 230069 - 69
url: www.road.de
Amtsgericht Charlottenburg: HRB 96688 B
Managing directors: Hans-Peter Constien, Hubertus von Streit
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm 2/2] PM: Disable usermode helper before hibernation and suspend
On Sunday, 17. June 2007, you wrote:
On Friday, 15 June 2007 23:36, Rafael J. Wysocki wrote:
On Friday, 15 June 2007 15:08, Uli Luckas wrote:
On Monday, 4. June 2007, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
Use a hibernation and suspend notifier to disable the user mode
helper before a hibernation/suspend and enable it after the
operation.
Hi Rafael,
I have a couple of questions, regarding this patch ...
2) how does your patch prevent wait_for_completion(done) to hang
during freezing if usermodehelper_pm_callback is called _after_ the
above check?
It doesn't. Once the helper is running, we can't distinguish it from any
other user land process.
Still, it narrows the window quite a bit.
Okay, I think we can help it a bit. Please tell me what you think of the
following patch (on top of 2.6.22-rc4-mm2).
Hi Rafael,
Thanks for your work. I haven't found the time to actually test your patch but
in general it looks like a valid aproach.
I think there is one problem though. You need to have your wait queue woken up
when you update (atomic_dec) running_helpers. Otherwise you end up always
waiting the full RUNNING_HELPERS_TIMEOUT.
Index: linux-2.6.22-rc4-mm2/kernel/kmod.c
===
--- linux-2.6.22-rc4-mm2.orig/kernel/kmod.c
+++ linux-2.6.22-rc4-mm2/kernel/kmod.c
@@ -49,6 +49,15 @@ static struct workqueue_struct *khelper_
*/
static int usermodehelper_disabled;
+/* Number of helpers running */
+static atomic_t running_helpers = ATOMIC_INIT(0);
+
+/*
+ * Time to wait for running_helpers to become zero before the setting of
+ * usermodehelper_disabled in usermodehelper_pm_callback() fails
+ */
+#define RUNNING_HELPERS_TIMEOUT (5 * HZ)
+
#ifdef CONFIG_KMOD
/*
@@ -279,11 +288,20 @@ static int usermodehelper_pm_callback(st
unsigned long action,
void *ignored)
{
+ DECLARE_WAIT_QUEUE_HEAD_ONSTACK(waiting);
+
switch (action) {
case PM_HIBERNATION_PREPARE:
case PM_SUSPEND_PREPARE:
usermodehelper_disabled = 1;
- return NOTIFY_OK;
+ wait_event_timeout(waiting, atomic_read(running_helpers) == 0,
+ RUNNING_HELPERS_TIMEOUT);
+ if (atomic_read(running_helpers) == 0) {
+ return NOTIFY_OK;
+ } else {
+ usermodehelper_disabled = 0;
+ return NOTIFY_BAD;
+ }
case PM_POST_HIBERNATION:
case PM_POST_SUSPEND:
usermodehelper_disabled = 0;
@@ -397,12 +415,13 @@ int call_usermodehelper_exec(struct subp
DECLARE_COMPLETION_ONSTACK(done);
int retval;
+ atomic_inc(running_helpers);
if (sub_info-path[0] == '\0') {
retval = 0;
goto out;
}
- if (!khelper_wq || usermodehelper_disabled) {
+ if (!khelper_wq || (wait != UMH_NO_WAIT usermodehelper_disabled)) {
retval = -EBUSY;
goto out;
}
@@ -418,6 +437,7 @@ int call_usermodehelper_exec(struct subp
out:
call_usermodehelper_freeinfo(sub_info);
+ atomic_dec(running_helpers);
return retval;
}
EXPORT_SYMBOL(call_usermodehelper_exec);
--
--- ROAD ...the handyPC Company - - - ) ) )
Uli Luckas
Software Development
ROAD GmbH
Bennigsenstr. 14 | 12159 Berlin | Germany
fon: +49 (30) 230069 - 64 | fax: +49 (30) 230069 - 69
url: www.road.de
Amtsgericht Charlottenburg: HRB 96688 B
Managing directors: Hans-Peter Constien, Hubertus von Streit
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm 2/2] PM: Disable usermode helper before hibernation and suspend
On Monday, 18. June 2007, you wrote:
On Monday, 18 June 2007 12:51, Uli Luckas wrote:
On Sunday, 17. June 2007, you wrote:
On Friday, 15 June 2007 23:36, Rafael J. Wysocki wrote:
On Friday, 15 June 2007 15:08, Uli Luckas wrote:
On Monday, 4. June 2007, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
Use a hibernation and suspend notifier to disable the user mode
helper before a hibernation/suspend and enable it after the
operation.
Hi Rafael,
I have a couple of questions, regarding this patch ...
2) how does your patch prevent wait_for_completion(done) to hang
during freezing if usermodehelper_pm_callback is called _after_ the
above check?
It doesn't. Once the helper is running, we can't distinguish it from
any other user land process.
Still, it narrows the window quite a bit.
Okay, I think we can help it a bit. Please tell me what you think of
the following patch (on top of 2.6.22-rc4-mm2).
Hi Rafael,
Thanks for your work. I haven't found the time to actually test your
patch but in general it looks like a valid aproach.
I think there is one problem though. You need to have your wait queue
woken up when you update (atomic_dec) running_helpers. Otherwise you end
up always waiting the full RUNNING_HELPERS_TIMEOUT.
Yeah, right. I tend to forget about obvious things. :-(
Great. As far as I can see, this patch should now fix the situation except
under heavy load where it would abort the attempted suspend. I can live with
that and it is a whole lot better than it was before - Thanks.
Besides, I think that the _pm_callback need not be compiled if CONFIG_PM is
unset.
Should work but is probably beneath what you intended to do. I'll comment
further down...
If you can, please have a look at the next version of the patch
(appended).
One more topic to keep in mind for the future. None of the callers of
call_usermode_helper* expect a return value of EBUSY nor do they handle it
correctly. If auto loading of a module for example fails, a permanent error
is usually assumed and no retry attempts are made.
Greetings,
Rafael
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
kernel/kmod.c | 76
++ 1 file changed,
66 insertions(+), 10 deletions(-)
Index: linux-2.6.22-rc4-mm2/kernel/kmod.c
===
--- linux-2.6.22-rc4-mm2.orig/kernel/kmod.c
+++ linux-2.6.22-rc4-mm2/kernel/kmod.c
@@ -41,14 +41,6 @@ extern int max_threads;
static struct workqueue_struct *khelper_wq;
-/*
- * If set, both call_usermodehelper_keys() and call_usermodehelper_pipe()
exit - * immediately returning -EBUSY. Used for preventing user land
processes from - * being created after the user land has been frozen during
a system-wide - * hibernation or suspend operation.
- */
-static int usermodehelper_disabled;
-
#ifdef CONFIG_KMOD
/*
@@ -275,6 +267,30 @@ static void __call_usermodehelper(struct
}
}
+#ifdef CONFIG_PM
+/*
+ * If set and if call_usermodehelper_exec() is supposed to wait, it will
exit + * immediately returning -EBUSY (used for preventing user land
processes from + * being created after the user land has been frozen during
a system-wide + * hibernation or suspend operation).
+ */
+static int usermodehelper_disabled;
+
+/* Number of helpers running */
+static atomic_t running_helpers = ATOMIC_INIT(0);
+
+/*
+ * Wait queue head used by usermodehelper_pm_callback() to wait for all
running + * helpers to finish.
+ */
+static DECLARE_WAIT_QUEUE_HEAD(running_helpers_waitq);
+
+/*
+ * Time to wait for running_helpers to become zero before the setting of
+ * usermodehelper_disabled in usermodehelper_pm_callback() fails
+ */
+#define RUNNING_HELPERS_TIMEOUT (5 * HZ)
+
static int usermodehelper_pm_callback(struct notifier_block *nfb,
unsigned long action,
void *ignored)
@@ -283,7 +299,15 @@ static int usermodehelper_pm_callback(st
case PM_HIBERNATION_PREPARE:
case PM_SUSPEND_PREPARE:
usermodehelper_disabled = 1;
- return NOTIFY_OK;
+ wait_event_timeout(running_helpers_waitq,
+ atomic_read(running_helpers) == 0,
+ RUNNING_HELPERS_TIMEOUT);
+ if (atomic_read(running_helpers) == 0) {
+ return NOTIFY_OK;
+ } else {
+ usermodehelper_disabled = 0;
+ return NOTIFY_BAD;
+ }
case PM_POST_HIBERNATION:
case PM_POST_SUSPEND:
usermodehelper_disabled = 0;
@@ -293,6 +317,36 @@ static int usermodehelper_pm_callback(st
return NOTIFY_DONE;
}
+static void new_helper(void
Re: [PATCH -mm 2/2] PM: Disable usermode helper before hibernation and suspend
On Monday, 4. June 2007, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki <[EMAIL PROTECTED]> > > Use a hibernation and suspend notifier to disable the user mode helper > before a hibernation/suspend and enable it after the operation. > Hi Rafael, I have a couple of questions, regarding this patch ... > - if (!khelper_wq) > + if (!khelper_wq || usermodehelper_disabled) > return -EBUSY; 1) how about not returning -EBUSY here, if (wait == UMH_NO_WAIT)? 2) how does your patch prevent wait_for_completion() to hang during freezing if usermodehelper_pm_callback is called _after_ the above check? Regards Uli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm 2/2] PM: Disable usermode helper before hibernation and suspend
On Monday, 4. June 2007, Rafael J. Wysocki wrote: From: Rafael J. Wysocki [EMAIL PROTECTED] Use a hibernation and suspend notifier to disable the user mode helper before a hibernation/suspend and enable it after the operation. Hi Rafael, I have a couple of questions, regarding this patch ... - if (!khelper_wq) + if (!khelper_wq || usermodehelper_disabled) return -EBUSY; 1) how about not returning -EBUSY here, if (wait == UMH_NO_WAIT)? 2) how does your patch prevent wait_for_completion(done) to hang during freezing if usermodehelper_pm_callback is called _after_ the above check? Regards Uli - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
