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, 29 Nov 2014 23:21:11 +0800 From: Jiang Liu <jiang.liu@...ux.intel.com> To: Borislav Petkov <bp@...en8.de> CC: linux-tip-commits@...r.kernel.org, matthias.bgg@...il.com, tony.luck@...el.com, tglx@...utronix.de, benh@...nel.crashing.org, linux-kernel@...r.kernel.org, hpa@...or.com, grant.likely@...aro.org, wangyijing@...wei.com, marc.zyngier@....com, bhelgaas@...gle.com, yingjoe.chen@...iatek.com, mingo@...nel.org Subject: Re: [tip:irq/irqdomain] irqdomain: Introduce helper function irq_domain_add_hierarchy() On 2014/11/29 22:56, Borislav Petkov wrote: > On Sat, Nov 29, 2014 at 10:29:33PM +0800, Jiang Liu wrote: >> Thanks for reporting and fixing this. How about using GFP_ATOMIC >> here? > > Well, I don't see the need to use GFP_ATOMIC if we absolutely don't have > to. And in this case lockdep is, AFAICT, correct in saying that we still > can do allocations with interrupts disabled, only not go down into fs > and do all kinds of lock grabbing operations like page reclaim, writeout > or whatever it is being done nowadays there. > > Yeah, this is also some old "no-no" in my memory which says that we > should almost never use GFP_ATOMIC if it can be helped. Thanks for the info about GFP_ATOMIC, originally I have an impression that we should use GFP_ATOMIC when interrupt is disabled:( > > OTOH, I wonder if this code would rather need to hand down explicit gfp > flags in case it should be able to do GFP_ATOMIC operations at some > point... > > Thanks. > -- 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