linux-kernel - Re: [RFC PATCH 33/33] Add Xen virtual block device driver.

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:	Tue, 18 Jul 2006 13:57:18 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Arjan van de Ven <arjan@...radead.org>
CC:	Chris Wright <chrisw@...s-sol.org>, linux-kernel@...r.kernel.org,
	virtualization@...ts.osdl.org, xen-devel@...ts.xensource.com,
	Andi Kleen <ak@...e.de>, Andrew Morton <akpm@...l.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Zachary Amsden <zach@...are.com>,
	Ian Pratt <ian.pratt@...source.com>,
	Christian Limpach <Christian.Limpach@...cam.ac.uk>
Subject: Re: [RFC PATCH 33/33] Add Xen virtual block device driver.

Arjan van de Ven wrote:
> as first general comment, I think that some of the memory allocation
> GFP_ flags are possibly incorrect; I would expect several places to use
> GFP_NOIO rather than GFP_KERNEL, to avoid recursion/deadlocks
>
>   
>> +static void blkif_recover(struct blkfront_info *info)
>>
>> +	/* Stage 1: Make a safe copy of the shadow state. */
>> +	copy = kmalloc(sizeof(info->shadow), GFP_KERNEL | __GFP_NOFAIL);
>>     
>
> like here..
>
>   
> and __GFP_NOFAIL is usually horrid; is this because error recovery was
> an afterthought, or because it's physically impossible? In addition
> __GFP_NOFAIL in a block device driver is... an interesting way to add
> OOM deadlocks... have the VM guys looked into this yet?
>   

In this particular case, it's only used on the resume path, which I'm 
guessing would not lead to IO recursion.  There doesn't seem to be any 
particular reason for this to be NOFAIL though (but I haven't really 
analyzed it).

There don't appear to be any memory allocations on the IO path; they're 
all in setup code.

    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/