netdev - Re: [PATCH RFC] spinlock: split out debugging check from spin_lock

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-next>] [day] [month] [year] [list]

Message-ID: <20130423134443.GB5564@hmsreliant.think-freely.org>
Date:	Tue, 23 Apr 2013 09:44:43 -0400
From:	Neil Horman <nhorman@...driver.com>
To:	Bart Van Assche <bart.vanassche@...il.com>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH RFC] spinlock: split out debugging check from
 spin_lock_mutex

On Tue, Apr 23, 2013 at 06:38:19AM -0700, Bart Van Assche wrote:
> On Tue, Apr 23, 2013 at 6:23 AM, Neil Horman <nhorman@...driver.com> wrote:
> 
> > Copy that.  I can propose this change based on my own testing, or wait for
> > you
> > to get back.  Do you have a preference?
> >
> 
> It will take until next week before I can run more tests. It depends on
> whether a fix can wait that long ?
> 
> Bart.
Dave, how do you feel about it?  I'm comfortable with the wait queue change I've
proposed, but I've not received any reports of actual netpoll deadlocks (i.e.
the mutex solution is reporting a warning, but no actual problems).  So I think
its safe to wait a bit longer, unless you just want this squared away now.

FWIw, I think theres still some discussion to be had about the possibility of
converting mutexes to use spin_lock_irqsave internally, thereby making
mutex_trylock irq safe, but I think we can deal with that independently of this
issue.

Regards
Neil

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html