Messages in this thread | | | Date | Mon, 30 Apr 2007 05:52:59 -0400 (EDT) | From | "Robert P. J. Day" <> | Subject | Re: can a kmalloc be both GFP_ATOMIC and GFP_KERNEL at the same time? |
| |
On Mon, 30 Apr 2007, Jan Engelhardt wrote:
> > On Apr 30 2007 04:46, Robert P. J. Day wrote: > >> > > >> > i'd always assumed that the type flags of GFP_ATOMIC and GFP_KERNEL > >> > were mutually exclusive when it came to calling kmalloc(), at least > >> > based on everything i'd read. so i'm not sure how to interpret the > >> > following: > >> > > >> > drivers/scsi/aic7xxx_old.c: aic_dev = kmalloc(sizeof(struct aic_dev_data), GFP_ATOMIC | GFP_KERNEL); > >> > drivers/message/i2o/device.c: resblk = kmalloc(buflen + 8, GFP_KERNEL | GFP_ATOMIC); > >> > > >> > clarification? > >> > >> GFP_ATOMIC implies that the memory comes from the zones which > >> GFP_KERNEL also uses. So the above usage of GFP_KERNEL is redundant > >> and should be removed. > > > >hang on ... based on an email i just got, is that reference to > >GFP_KERNEL "redundant" or "conflicting"? big difference there. and > >is the proper fix to remove "GFP_KERNEL" in both cases? > > include/linux/gfp.h: > #define GFP_ATOMIC (__GFP_HIGH) > #define GFP_KERNEL (__GFP_WAIT | __GFP_IO | __GFP_FS) > > So combining GFP_ATOMIC with GFP_KERNEL gives you > "allow io, allow fs, allow waiting, and use emergency pools when it's getting > tight" > which to me looks like a valid, but probably unwanted combination.
... snip ...
at this point, maybe i'll just leave this in the hands of those who know far more about it than i do. but, while we're here, are there any *other* combinations that wouldn't make any sense? might as well check for those in my cleanup script as well.
rday
p.s. as a suggestion that borders on overkill, one could always add a configuration debugging option that, when set, compiles code into kmalloc() that does a sanity check on its type flag arguments.
-- ======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page ======================================================================== - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |