linux-kernel - Re: [PATCH] SCSI: Remove redundant GFP

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 4 May 2007 18:38:37 +0530
From:	"Satyam Sharma" <satyam.sharma@...il.com>
To:	"Andrew Morton" <akpm@...ux-foundation.org>
Cc:	"Robert P. J. Day" <rpjday@...dspring.com>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	linux-scsi@...r.kernel.org,
	"James Bottomley" <James.Bottomley@...eleye.com>
Subject: Re: [PATCH] SCSI: Remove redundant GFP_KERNEL type flag in kmalloc().

On 5/4/07, Andrew Morton <akpm@...ux-foundation.org> 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.
-
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/