| 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
| ||
|
Date: Sat, 31 Jan 2009 12:45:20 +0100 From: Joerg Roedel <joro@...tes.org> To: Robert Hancock <hancockr@...w.ca> Cc: Roger Larsson <roger.larsson@...atan.se>, linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>, Robert Love <rml@...h9.net>, Pavel Machek <pavel@....cz> Subject: Re: PROBLEM: in_atomic() misuse all over the place On Tue, Jan 27, 2009 at 06:12:00PM -0600, Robert Hancock wrote: > I would think that the code that's using it for this purpose should be > changed to do things differently, such as by changing the functions > using it to make their caller pass in the proper GFP mask. I don't think > it was ever intended to be used to select allocation behavior like this, > only for debug warning checks and such.. Getting rid of in_atomic() and > creating a in_atomic_warn() that just raises a warning if called > atomically, might be the best long-term solution. I also made the mistake of using in_atomic() wrong in one of my last patch sets. In my case this was pointed out by the reviewers. Is there some documentation in the kernel tree how and when in_atomic() is used right? If not I think its worth writing a little file that explains the important details about the correct use of in_atomic() :-) Joerg -- 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/
Powered by blists - more mailing lists