[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <x4962b2aoic.fsf@segfault.boston.devel.redhat.com>
Date: Thu, 07 Jun 2012 15:52:11 -0400
From: Jeff Moyer <jmoyer@...hat.com>
To: mihailov ivan <mihailov.iaa@...il.com>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH] change lock model in aio_put_req
mihailov ivan <mihailov.iaa@...il.com> writes:
> 2012/6/7 Jeff Moyer <jmoyer@...hat.com>:
>> mihailov ivan <mihailov.iaa@...il.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists