Re: [PATCH 1/2] kobject: don't block for each kobject_uevent

2014-02-14 Thread Vladimir Davydov
On 02/13/2014 11:53 PM, Andrew Morton wrote: > On Sun, 9 Feb 2014 14:56:15 +0400 Vladimir Davydov > wrote: > >> Currently kobject_uevent has somewhat unpredictable semantics. The point >> is, since it may call a usermode helper and wait for it to execute >> (UMH_WAIT_EXEC), it is impossible to

Re: [PATCH 1/2] kobject: don't block for each kobject_uevent

2014-02-14 Thread Vladimir Davydov
On 02/13/2014 11:53 PM, Andrew Morton wrote: On Sun, 9 Feb 2014 14:56:15 +0400 Vladimir Davydov vdavy...@parallels.com wrote: Currently kobject_uevent has somewhat unpredictable semantics. The point is, since it may call a usermode helper and wait for it to execute (UMH_WAIT_EXEC), it is

Re: [PATCH 1/2] kobject: don't block for each kobject_uevent

2014-02-13 Thread Andrew Morton
On Sun, 9 Feb 2014 14:56:15 +0400 Vladimir Davydov wrote: > Currently kobject_uevent has somewhat unpredictable semantics. The point > is, since it may call a usermode helper and wait for it to execute > (UMH_WAIT_EXEC), it is impossible to say for sure what lock dependencies > it will

Re: [PATCH 1/2] kobject: don't block for each kobject_uevent

2014-02-13 Thread Andrew Morton
On Sun, 9 Feb 2014 14:56:15 +0400 Vladimir Davydov vdavy...@parallels.com wrote: Currently kobject_uevent has somewhat unpredictable semantics. The point is, since it may call a usermode helper and wait for it to execute (UMH_WAIT_EXEC), it is impossible to say for sure what lock dependencies

Re: [PATCH 1/2] kobject: don't block for each kobject_uevent

2014-02-11 Thread Vladimir Davydov
On 02/12/2014 03:03 AM, Andrew Morton wrote: > On Sun, 9 Feb 2014 14:56:15 +0400 Vladimir Davydov > wrote: > >> Currently kobject_uevent has somewhat unpredictable semantics. The point >> is, since it may call a usermode helper and wait for it to execute >> (UMH_WAIT_EXEC), it is impossible to

Re: [PATCH 1/2] kobject: don't block for each kobject_uevent

2014-02-11 Thread Andrew Morton
On Sun, 9 Feb 2014 14:56:15 +0400 Vladimir Davydov wrote: > Currently kobject_uevent has somewhat unpredictable semantics. The point > is, since it may call a usermode helper and wait for it to execute > (UMH_WAIT_EXEC), it is impossible to say for sure what lock dependencies > it will

Re: [PATCH 1/2] kobject: don't block for each kobject_uevent

2014-02-11 Thread Andrew Morton
On Sun, 9 Feb 2014 14:56:15 +0400 Vladimir Davydov vdavy...@parallels.com wrote: Currently kobject_uevent has somewhat unpredictable semantics. The point is, since it may call a usermode helper and wait for it to execute (UMH_WAIT_EXEC), it is impossible to say for sure what lock dependencies

Re: [PATCH 1/2] kobject: don't block for each kobject_uevent

2014-02-11 Thread Vladimir Davydov
On 02/12/2014 03:03 AM, Andrew Morton wrote: On Sun, 9 Feb 2014 14:56:15 +0400 Vladimir Davydov vdavy...@parallels.com wrote: Currently kobject_uevent has somewhat unpredictable semantics. The point is, since it may call a usermode helper and wait for it to execute (UMH_WAIT_EXEC), it is

[PATCH 1/2] kobject: don't block for each kobject_uevent

2014-02-09 Thread Vladimir Davydov
Currently kobject_uevent has somewhat unpredictable semantics. The point is, since it may call a usermode helper and wait for it to execute (UMH_WAIT_EXEC), it is impossible to say for sure what lock dependencies it will introduce for the caller - strictly speaking it depends on what fs the binary

[PATCH 1/2] kobject: don't block for each kobject_uevent

2014-02-09 Thread Vladimir Davydov
Currently kobject_uevent has somewhat unpredictable semantics. The point is, since it may call a usermode helper and wait for it to execute (UMH_WAIT_EXEC), it is impossible to say for sure what lock dependencies it will introduce for the caller - strictly speaking it depends on what fs the binary