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 sa
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 introduce
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 sa
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 introduce
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
5 matches
Mail list logo