On Mon, Aug 17, 2015 at 9:14 PM, Bjorn Helgaas wrote:
> On Mon, Jul 27, 2015 at 04:29:50PM -0700, Yinghai Lu wrote:
>> It will not hold lock, so we could use it in other functions that
>> hold the resource lock already.
>
> What's the benefit of this patch? Does it fix something? Does it add
On Mon, Aug 17, 2015 at 9:14 PM, Bjorn Helgaas bhelg...@google.com wrote:
On Mon, Jul 27, 2015 at 04:29:50PM -0700, Yinghai Lu wrote:
It will not hold lock, so we could use it in other functions that
hold the resource lock already.
What's the benefit of this patch? Does it fix something?
On Mon, Jul 27, 2015 at 04:29:50PM -0700, Yinghai Lu wrote:
> It will not hold lock, so we could use it in other functions that
> hold the resource lock already.
What's the benefit of this patch? Does it fix something? Does it add some
functionality we need?
>
> -v2: according to Linus, using
On Mon, Jul 27, 2015 at 04:29:50PM -0700, Yinghai Lu wrote:
It will not hold lock, so we could use it in other functions that
hold the resource lock already.
What's the benefit of this patch? Does it fix something? Does it add some
functionality we need?
-v2: according to Linus, using bool
It will not hold lock, so we could use it in other functions that
hold the resource lock already.
-v2: according to Linus, using "bool lock" as parameter
aka "conditionally take lock" is *wrong*.
Signed-off-by: Yinghai Lu
Acked-by: Linus Torvalds
---
kernel/resource.c | 70
It will not hold lock, so we could use it in other functions that
hold the resource lock already.
-v2: according to Linus, using bool lock as parameter
aka conditionally take lock is *wrong*.
Signed-off-by: Yinghai Lu ying...@kernel.org
Acked-by: Linus Torvalds torva...@linux-foundation.org
6 matches
Mail list logo
