[PATCH] change lock model in aio_put_req

[PATCH] change lock model in aio_put_req

[mihailov ivan]

Why used spin_lock/unlock_irq instead of
spin_lock_irqsave/spin_unlock_irqrestore?
__aio_put_req it's interrupt safe call but why aio_put_req not?

simply if I'll do some kind of this code:

spin_lock_irqsave(&lock, flags);
--some functions 1--
aio_put_req(aiocb);
--some functions 2--
spin_unlock_irqrestore(&lock, flags);

On aio_put_req we unlock all interrupts...
And after that 'some functions 2' unsafe now.

Or this call work as designed?
If not I have smally patchset for that.


--- /usr/src/linux/fs/aio.c	2011-07-22 02:17:23.000000000 +0000
+++ aio.c	2012-06-07 01:12:33.737299121 +0000
@@ -581,10 +581,10 @@
 int aio_put_req(struct kiocb *req)
 {
 	struct kioctx *ctx = req->ki_ctx;
-	int ret;
-	spin_lock_irq(&ctx->ctx_lock);
+	int ret, flags;
+	spin_lock_irqsave(&ctx->ctx_lock, flags);
 	ret = __aio_put_req(ctx, req);
-	spin_unlock_irq(&ctx->ctx_lock);
+	spin_unlock_irqrestore(&ctx->ctx_lock, flags);
 	return ret;
 }
 EXPORT_SYMBOL(aio_put_req);

Re: [PATCH] change lock model in aio_put_req

[Jeff Moyer]

mihailov ivan <mihailov.iaa@gmail.com> writes:

> Why used spin_lock/unlock_irq instead of
> spin_lock_irqsave/spin_unlock_irqrestore?

Because the function is never called from interrupt context.

> __aio_put_req it's interrupt safe call but why aio_put_req not?

__aio_put_req is called with the ctx lock already taken.  This (the __
routine being called with the lock held) is a fairly common convention
in the kernel.

Nack.  Your patch doesn't fix anything.

Cheers,
Jeff

Re: [PATCH] change lock model in aio_put_req

[mihailov ivan]

2012/6/7 Jeff Moyer <jmoyer@redhat.com>:
> mihailov ivan <mihailov.iaa@gmail.com> writes:
>
>> Why used spin_lock/unlock_irq instead of
>> spin_lock_irqsave/spin_unlock_irqrestore?
>
> Because the function is never called from interrupt context.
>
>> __aio_put_req it's interrupt safe call but why aio_put_req not?
>
> __aio_put_req is called with the ctx lock already taken.  This (the __
> routine being called with the lock held) is a fairly common convention
> in the kernel.
>
> Nack.  Your patch doesn't fix anything.

Yes, my patch doesn't fix anything but it's allows this call inside of
interrupt context.
And curios why it can't be possible inside of interrupt context? From
side - never changed,
only we will can execute this call in interrupt context.
I understood what is works as designed but don't understood why we
can't imporve this call,
it's 'fairly convention in the kernel'?

Re: [PATCH] change lock model in aio_put_req

[Jeff Moyer]

mihailov ivan <mihailov.iaa@gmail.com> writes:

> 2012/6/7 Jeff Moyer <jmoyer@redhat.com>:
>> mihailov ivan <mihailov.iaa@gmail.com> writes:
>>
>>> Why used spin_lock/unlock_irq instead of
>>> spin_lock_irqsave/spin_unlock_irqrestore?
>>
>> Because the function is never called from interrupt context.
>>
>>> __aio_put_req it's interrupt safe call but why aio_put_req not?
>>
>> __aio_put_req is called with the ctx lock already taken.  This (the __
>> routine being called with the lock held) is a fairly common convention
>> in the kernel.
>>
>> Nack.  Your patch doesn't fix anything.
>
> Yes, my patch doesn't fix anything but it's allows this call inside of
> interrupt context.

But it doesn't need to be called from interrupt context, so there's
really no point in changing it.

> And curios why it can't be possible inside of interrupt context?

If ever a caller needs the functionality, we can change it.

> From side - never changed, only we will can execute this call in
> interrupt context.  I understood what is works as designed but don't
> understood why we can't imporve this call, it's 'fairly convention in
> the kernel'?

Changing this is simply not an improvement, it's just a change with no
benefit.  There's really no point.

Now, are you going to tell me that you want to call this function from
interrupt context in some third party driver?  What's the real
motivation for this patch?

Cheers,
Jeff

Re: [PATCH] change lock model in aio_put_req

[mihailov ivan]

>> From side - never changed, only we will can execute this call in
>> interrupt context.  I understood what is works as designed but don't
>> understood why we can't imporve this call, it's 'fairly convention in
>> the kernel'?
>
> Changing this is simply not an improvement, it's just a change with no
> benefit.  There's really no point.
>
okay, got it.

> Now, are you going to tell me that you want to call this function from
> interrupt context in some third party driver?  What's the real
> motivation for this patch?
You are right, I'm supporting drivers which are calling this function
from interrupt context.
And I'm trying to find proper way to fix it.
It is clear that this patch is pointless in general case and
I'll try to avoid using this call from interrupt context.
Thanks for your help and patience.