linux-kernel - Re: [PATCH] generic ipi function calls: wait on alloc failure fallback

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]

Message-ID: <487D1E1E.9060609@goop.org>
Date:	Tue, 15 Jul 2008 15:01:02 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Jens Axboe <jens.axboe@...cle.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] generic ipi function calls: wait on alloc failure	fallback

Ingo Molnar wrote:
> * Jeremy Fitzhardinge <jeremy@...p.org> wrote:
>
>   
>> When a GFP_ATOMIC allocation fails, it falls back to allocating the 
>> data on the stack and converting it to a waiting call.
>>
>> Make sure we actually wait in this case.
>>     
>
> cool, thanks!
>
> does this explain the xen64 weirdnesses you've been seeing?
>   

No, but I haven't seen it lately.  I think the other RCU fixes may have 
helped.  But it's all a bit of a worry: I didn't have a good theory 
about what was going wrong, the RCU patches didn't look like they'd fix 
the symptoms I was seeing.

I've seen it with 32 and 64-bit Xen, but there's nothing about the 
problem which makes me think it's really Xen specific.  If it were, I'd 
expect to see failures all over the place, rather than in just in this 
one specific place.

I'm concerned there's a lurking bug, particularly if it's a generic race 
or something that happens to be triggered when running under Xen because 
of the timing changes.  I've tried reproducing it in a hvm Xen domain 
(so it's running the normal x86 kernel fully virtualized, but with the 
Xen scheduler, etc).  I didn't see a problem, but it isn't a very 
convincing test one way or the other.

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