Please be careful to add the appropriate cc's.
On Mon, 30 Apr 2007 04:37:22 -0400 (EDT) "Robert P. J. Day" <[email protected]> wrote:
>
> Remove the apparently redundant GFP_KERNEL type flag in the call to
> kmalloc().
>
> Signed-off-by: Robert P. J. Day <[email protected]>
>
> ---
>
> diff --git a/drivers/scsi/aic7xxx_old.c b/drivers/scsi/aic7xxx_old.c
> index a988d5a..765ded0 100644
> --- a/drivers/scsi/aic7xxx_old.c
> +++ b/drivers/scsi/aic7xxx_old.c
> @@ -6581,7 +6581,7 @@ aic7xxx_slave_alloc(struct scsi_device *SDptr)
> struct aic7xxx_host *p = (struct aic7xxx_host *)SDptr->host->hostdata;
> struct aic_dev_data *aic_dev;
>
> - aic_dev = kmalloc(sizeof(struct aic_dev_data), GFP_ATOMIC | GFP_KERNEL);
> + aic_dev = kmalloc(sizeof(struct aic_dev_data), GFP_ATOMIC);
No, this converts the allocation from a robust one which can sleep into a
flakey one which cannot.
If we want to just clean this code up, we should switch to
GFP_KERNEL|__GFP_HIGH
and add a comment explaining why we're turning on __GFP_HIGH (pointlessly,
I suspect).
However I suspect what the code really meant to do was to use just
GFP_KERNEL. It's been that way since
commit 5c9342ceb292ac5c619db6eef4ef427a64bcd436
Author: torvalds <torvalds>
Date: Thu Nov 7 04:54:32 2002 +0000
Merge bk://linux-scsi.bkbits.net/scsi-dledford
into home.transmeta.com:/home/torvalds/v2.5/linux
2002/11/06 16:40:20-05:00 dledford
aic7xxx_old: multiple updates and fixes, driver ported to scsi
mid-layer new error handling scheme
On Fri, 4 May 2007, Andrew Morton wrote:
>
> Please be careful to add the appropriate cc's.
>
> On Mon, 30 Apr 2007 04:37:22 -0400 (EDT) "Robert P. J. Day" <[email protected]> wrote:
>
> >
> > Remove the apparently redundant GFP_KERNEL type flag in the call to
> > kmalloc().
> >
> > Signed-off-by: Robert P. J. Day <[email protected]>
> >
> > ---
> >
> > diff --git a/drivers/scsi/aic7xxx_old.c b/drivers/scsi/aic7xxx_old.c
> > index a988d5a..765ded0 100644
> > --- a/drivers/scsi/aic7xxx_old.c
> > +++ b/drivers/scsi/aic7xxx_old.c
> > @@ -6581,7 +6581,7 @@ aic7xxx_slave_alloc(struct scsi_device *SDptr)
> > struct aic7xxx_host *p = (struct aic7xxx_host *)SDptr->host->hostdata;
> > struct aic_dev_data *aic_dev;
> >
> > - aic_dev = kmalloc(sizeof(struct aic_dev_data), GFP_ATOMIC | GFP_KERNEL);
> > + aic_dev = kmalloc(sizeof(struct aic_dev_data), GFP_ATOMIC);
>
> No, this converts the allocation from a robust one which can sleep into a
> flakey one which cannot.
... snip ...
at this point, i'd be happier to leave the appropriate patches in the
hands of those who have a better handle on this. as i posted earlier,
there's only two examples of this in the entire tree:
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);
it's all yours.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
On 5/4/07, Andrew Morton <[email protected]> wrote:
> [...]
> >
> > - aic_dev = kmalloc(sizeof(struct aic_dev_data), GFP_ATOMIC | GFP_KERNEL);
> > + aic_dev = kmalloc(sizeof(struct aic_dev_data), GFP_ATOMIC);
>
> No, this converts the allocation from a robust one which can sleep into a
> flakey one which cannot.
>
> If we want to just clean this code up, we should switch to
>
> GFP_KERNEL|__GFP_HIGH
>
> and add a comment explaining why we're turning on __GFP_HIGH (pointlessly,
> I suspect).
>
> However I suspect what the code really meant to do was to use just
> GFP_KERNEL.
Yes.
A recap from http://lkml.org/lkml/2007/4/28/160 ...
> > 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.
and:
> As a matter of style, the author there could've written (GFP_KERNEL |
> __GFP_HIGH) instead, but I'm not sure how much sense that makes
> because once we specify GFP_KERNEL, we essentially bring out the heavy
> weaponry to *make* some free space for ourselves if it isn't there
> already (and we're prepared to sleep when all that happens) -- so
> where's the need left to scavenge into emergency pools anymore?
> __GFP_HIGH only makes sense for poor atomic contexts for whom sleeping
> (when we try_to_free other pages to satisfy our allocation request) is
> not an option, which is precisely how things are presently.
>
> [...]
> 1. If you're in_atomic() context, that GFP_KERNEL is a BUG and *must*
> be removed.
>
> 2. If not, that GFP_ATOMIC is redundant / nonsensical and *can* be removed.
It _was_ established towards the end of that thread that neither of the two
cases are atomic contexts. And it would still make sense to remove the redundant
__GFP_HIGH, as we don't want to unnecessarily deplete the emergency
reserve pool for normal GFP_KERNEL cases thus making ENOMEM on some future
kmalloc(GFP_ATOMIC) more likely. I'll send out the patches.