[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.1007021605410.13662@hs20-bc2-1.build.redhat.com>
Date: Fri, 2 Jul 2010 16:08:09 -0400 (EDT)
From: Mikulas Patocka <mpatocka@...hat.com>
To: Mike Snitzer <snitzer@...hat.com>
cc: dm-devel@...hat.com, Alasdair G Kergon <agk@...hat.com>,
linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org
Subject: GFP_KERNEL in ext4 (was: [PATCH 4/4] Support discard if at least
one underlying device supports it)
> ---
> include/linux/blkdev.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux-2.6.35-rc3-fast/include/linux/blkdev.h
> ===================================================================
> --- linux-2.6.35-rc3-fast.orig/include/linux/blkdev.h 2010-07-02 21:59:21.000000000 +0200
> +++ linux-2.6.35-rc3-fast/include/linux/blkdev.h 2010-07-02 21:59:37.000000000 +0200
> @@ -1021,7 +1021,7 @@ static inline int sb_issue_discard(struc
> block <<= (sb->s_blocksize_bits - 9);
> nr_blocks <<= (sb->s_blocksize_bits - 9);
> return blkdev_issue_discard(sb->s_bdev, block, nr_blocks, GFP_KERNEL,
> BLKDEV_IFL_WAIT | BLKDEV_IFL_BARRIER);
> }
>
> extern int blk_verify_command(unsigned char *cmd, fmode_t has_write_perm);
>
A note for ext4 developers: is that GFP_KERNEL safe? Can't it recurse back
to ext4 and attempt to flush more data?
I'm not familiar enough with ext4 to declare that it is/isn't a bug, but
it looks suspicious.
Mikulas
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists