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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 20 Nov 2020 18:31:41 +0100 From: Daniel Vetter <daniel.vetter@...ll.ch> To: Randy Dunlap <rdunlap@...radead.org> Cc: DRI Development <dri-devel@...ts.freedesktop.org>, Intel Graphics Development <intel-gfx@...ts.freedesktop.org>, Linux MM <linux-mm@...ck.org>, linux-xfs@...r.kernel.org, linux-fsdevel@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>, Vlastimil Babka <vbabka@...e.cz>, "Paul E . McKenney" <paulmck@...nel.org>, Christoph Lameter <cl@...ux.com>, Pekka Enberg <penberg@...nel.org>, David Rientjes <rientjes@...gle.com>, Joonsoo Kim <iamjoonsoo.kim@....com>, Andrew Morton <akpm@...ux-foundation.org>, Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...nel.org>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Sebastian Andrzej Siewior <bigeasy@...utronix.de>, Michel Lespinasse <walken@...gle.com>, Waiman Long <longman@...hat.com>, Thomas Gleixner <tglx@...utronix.de>, Dave Chinner <david@...morbit.com>, Qian Cai <cai@....pw>, "Matthew Wilcox (Oracle)" <willy@...radead.org>, Daniel Vetter <daniel.vetter@...el.com> Subject: Re: [PATCH 2/3] mm: Extract might_alloc() debug check On Fri, Nov 20, 2020 at 6:20 PM Randy Dunlap <rdunlap@...radead.org> wrote: > > Hi, > > On 11/20/20 1:54 AM, Daniel Vetter wrote: > > diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h > > index d5ece7a9a403..f94405d43fd1 100644 > > --- a/include/linux/sched/mm.h > > +++ b/include/linux/sched/mm.h > > @@ -180,6 +180,22 @@ static inline void fs_reclaim_acquire(gfp_t gfp_mask) { } > > static inline void fs_reclaim_release(gfp_t gfp_mask) { } > > #endif > > > > +/** > > + * might_alloc - Marks possible allocation sites > > Mark > > > + * @gfp_mask: gfp_t flags that would be use to allocate > > used > > > + * > > + * Similar to might_sleep() and other annotations this can be used in functions > > annotations, > > > + * that might allocate, but often dont. Compiles to nothing without > > don't. > > > + * CONFIG_LOCKDEP. Includes a conditional might_sleep() if @gfp allows blocking. > > ? might_sleep_if() if That's one if too many, I'll do the others for next round. Thanks for taking a look. -Daniel > > > + */ > > +static inline void might_alloc(gfp_t gfp_mask) > > +{ > > + fs_reclaim_acquire(gfp_mask); > > + fs_reclaim_release(gfp_mask); > > + > > + might_sleep_if(gfpflags_allow_blocking(gfp_mask)); > > +} > > > -- > ~Randy > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Powered by blists - more mailing lists