From: Andi Kleen <andi@firstfloor.org>
To: James.Bottomley@HansenPartnership.com, linux-scsi@vger.kernel.org
Subject: [PATCH] Don't use unnecessary GFP_ATOMIC in sg.c v2
Date: Mon, 25 Feb 2008 10:09:48 +0100 [thread overview]
Message-ID: <20080225090948.GA5843@basil.nowhere.org> (raw)
Don't use unnecessary GFP_ATOMIC in sg.c v2
[Update for the previous version of the patch]
sg.c uses GFP_ATOMIC for a lot of allocations where it isn't necessary.
There are no locks hold and I don't see any other reasons why GFP_ATOMIC
should be needed here. So remove them.
Depends on the earlier GFP_DMA patchkit, but only because it happens
to patch the same places (no real functional dependency)
Tested by burning a CD on a kernel with all lock/sleep/etc. debugging enabled.
v2: Actually always use GFP_KERNEL instead of 0 (which is equivalent to
GFP_ATOMIC). Retested.
Signed-off-by: Andi Kleen <ak@suse.de>
---
drivers/scsi/sg.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
Index: linux/drivers/scsi/sg.c
===================================================================
--- linux.orig/drivers/scsi/sg.c
+++ linux/drivers/scsi/sg.c
@@ -745,7 +745,7 @@ sg_common_write(Sg_fd * sfp, Sg_request
if (scsi_execute_async(sdp->device, cmnd, hp->cmd_len, data_dir, srp->data.buffer,
hp->dxfer_len, srp->data.k_use_sg, timeout,
SG_DEFAULT_RETRIES, srp, sg_cmd_done,
- GFP_ATOMIC)) {
+ GFP_KERNEL)) {
SCSI_LOG_TIMEOUT(1, printk("sg_common_write: scsi_execute_async failed\n"));
/*
* most likely out of mem, but could also be a bad map
@@ -1654,7 +1654,7 @@ static int
sg_build_sgat(Sg_scatter_hold * schp, const Sg_fd * sfp, int tablesize)
{
int sg_bufflen = tablesize * sizeof(struct scatterlist);
- gfp_t gfp_flags = GFP_ATOMIC | __GFP_NOWARN;
+ gfp_t gfp_flags = GFP_KERNEL | __GFP_NOWARN;
schp->buffer = kzalloc(sg_bufflen, gfp_flags);
if (!schp->buffer)
@@ -1694,7 +1694,7 @@ st_map_user_pages(struct scatterlist *sg
if (count == 0)
return 0;
- if ((pages = kmalloc(max_pages * sizeof(*pages), GFP_ATOMIC)) == NULL)
+ if ((pages = kmalloc(max_pages * sizeof(*pages), GFP_KERNEL)) == NULL)
return -ENOMEM;
/* Try to fault in all of the necessary pages */
@@ -2323,7 +2323,7 @@ sg_add_sfp(Sg_device * sdp, int dev)
unsigned long iflags;
int bufflen;
- sfp = kzalloc(sizeof(*sfp), GFP_ATOMIC | __GFP_NOWARN);
+ sfp = kzalloc(sizeof(*sfp), GFP_KERNEL|__GFP_NOWARN);
if (!sfp)
return NULL;
@@ -2452,7 +2452,7 @@ sg_page_malloc(int rqSz, int *retSzp)
if ((rqSz <= 0) || (NULL == retSzp))
return resp;
- page_mask = GFP_ATOMIC | __GFP_COMP | __GFP_NOWARN;
+ page_mask = GFP_KERNEL | __GFP_COMP | __GFP_NOWARN;
for (order = 0, a_size = PAGE_SIZE; a_size < rqSz;
order++, a_size <<= 1) ;
next reply other threads:[~2008-02-25 9:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-25 9:09 Andi Kleen [this message]
2008-02-25 13:21 ` [PATCH] Don't use unnecessary GFP_ATOMIC in sg.c v2 Douglas Gilbert
2008-02-25 14:33 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080225090948.GA5843@basil.nowhere.org \
--to=andi@firstfloor.org \
--cc=James.Bottomley@HansenPartnership.com \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox