linux-kernel - Re: [PATCH] ata: fix sleep-while-holding-spinlock in sata

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20080521081644.3944cc46@infradead.org>
Date:	Wed, 21 May 2008 08:16:44 -0700
From:	Arjan van de Ven <arjan@...radead.org>
To:	Robert Hancock <hancockr@...w.ca>
Cc:	linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ata: fix sleep-while-holding-spinlock in sata_nv

On Wed, 21 May 2008 08:31:26 -0600
Robert Hancock <hancockr@...w.ca> wrote:

> rjan van de Ven wrote:
> >> I'm not certain this is safe to do it quite this way. It would be
> >> better to keep that spinlock held so that no operations could be in
> >> progress on either port while these operations are happening.
> > 
> > blk_bounce_limit can sleep. that's just a fact of life ;(
> 
> Now it can, for no reason. Under the conditions it was used before,
> it never could.

"never" is.. a dangerous assumption. It depends on the details of what
GFP_DMA exactly means and how the exact zoning in the system is set up.
All of that is undergoing flux (Andi Kleen has been hacking on that for
example)

But yes, on the existing VM layout on a 32 bit X86 system it wouldn't
sleep if you set the mask to exactly 32 bit (except for the bug)

> > the condition under which it sleeps might be slightly buggy on your
> > exact x86 machine... but that doesn't mean that that is guaranteed
> > to be so forever going forward.... it's still a sleeping function.
> 
> More than slightly buggy, I think.. It seems like it is going to be 
> bouncing block layer accesses to devices with 32-bit DMA masks
> through the 16MB ZONE_DMA. If that's what's actually going on, I'm
> surprised there haven't been more regression reports. The fact that
> the function now sleeps when it didn't before is the least of the
> problems here..

you're absolutely right that the current implementation has a bug.
But the sleepy-ness part isn't really part of that bug. When we get
pools to fill for other masks we'll need to sleep as well. Heck,
it's not unthinkable that swiotlb on 64 bit will go do the same...

--
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/