lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ