Re: [PATCH] uas: replace WARN_ON_ONCE() with assert_spin_locked().

From: Greg KH
Date: Mon Aug 11 2014 - 18:54:19 EST


On Mon, Aug 11, 2014 at 11:56:17AM +0000, Sharma, Sanjeev wrote:
> Hi Greg,
>
> Please find my comment in line.

As it should, but where is it, your quoting is all messed up...

> -----Original Message-----
> From: Greg KH [mailto:gregkh@xxxxxxxxxxxxxxxxxxx]
> Sent: Monday, August 11, 2014 1:58 PM
> To: Sharma, Sanjeev
> Cc: hdegoede@xxxxxxxxxx; kraxel@xxxxxxxxxx; mdharm-usb@xxxxxxxxxxxxxxxxxx; linux-usb@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; linux-scsi@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH] uas: replace WARN_ON_ONCE() with assert_spin_locked().
>
> On Mon, Aug 11, 2014 at 01:29:26PM +0530, Sanjeev Sharma wrote:
> > spin_is_locked() always return false in uniprocessor configuration
>
> Really? On what processor type? I don't see that being the case on a few processors, but I didn't check them all, or I might be totally confused with all of the arch_spin_is_locked() definitions in the tree.
>
> specially in case of mips and powerpc but we can configure our kernel to uniprocessor configuration for specific processor and in that case we should be extra cautious. Please check spinlock_up.h

Shouldn't you just fix your .h file to not do this? x86 is not this
way, nor is ARM, right?

> > and therefore it
> > would be advise to repalce with assert_spin_locked().
>
> This implies that all uses of this function is wrong and should be replaced and removed, right?
>
> Yes and there are only few places in driver for which I am submitting patches which need to be change and at other places it has been already taken care. Please have an look into the
> Old discussion for more details.
>
> http://linux-kernel.2935.n7.nabble.com/Is-spin-is-locked-safe-to-use-with-BUG-ON-WARN-ON-td654800.html#a921802

Ok, just remove all the tests, it doesn't help anyone :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/