[PATCH] splice: use mapping_gfp_mask - Kernel

This is a discussion on [PATCH] splice: use mapping_gfp_mask - Kernel ; The loop block driver is careful to mask __GFP_IO|__GFP_FS out of its mapping_gfp_mask, to avoid hangs under memory pressure. But nowadays it uses splice, usually going through __generic_file_splice_read. That must use mapping_gfp_mask instead of GFP_KERNEL to avoid those hangs. Signed-off-by: ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: [PATCH] splice: use mapping_gfp_mask

  1. [PATCH] splice: use mapping_gfp_mask

    The loop block driver is careful to mask __GFP_IO|__GFP_FS out of its
    mapping_gfp_mask, to avoid hangs under memory pressure. But nowadays
    it uses splice, usually going through __generic_file_splice_read. That
    must use mapping_gfp_mask instead of GFP_KERNEL to avoid those hangs.

    Signed-off-by: Hugh Dickins
    ---
    Ought to go into 2.6.25. For 2.6.23 and 2.6.24 stable? Well, I've
    not actually seen this hang on any of these, though presumably it's
    lurking there. Where I did see it, and test the fix, was 2.6.25-rc5-mm1:
    whose SLUB had a disturbing predilection (since corrected) for order-4
    allocations, even when allocating radix tree nodes.

    fs/splice.c | 2 +-
    1 file changed, 1 insertion(+), 1 deletion(-)

    --- 2.6.25-rc8/fs/splice.c 2008-03-05 10:47:40.000000000 +0000
    +++ linux/fs/splice.c 2008-04-01 22:28:41.000000000 +0100
    @@ -320,7 +320,7 @@ __generic_file_splice_read(struct file *
    break;

    error = add_to_page_cache_lru(page, mapping, index,
    - GFP_KERNEL);
    + mapping_gfp_mask(mapping));
    if (unlikely(error)) {
    page_cache_release(page);
    if (error == -EEXIST)
    --
    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/

  2. Re: [PATCH] splice: use mapping_gfp_mask

    On Thu, Apr 03 2008, Hugh Dickins wrote:
    > The loop block driver is careful to mask __GFP_IO|__GFP_FS out of its
    > mapping_gfp_mask, to avoid hangs under memory pressure. But nowadays
    > it uses splice, usually going through __generic_file_splice_read. That
    > must use mapping_gfp_mask instead of GFP_KERNEL to avoid those hangs.
    >
    > Signed-off-by: Hugh Dickins
    > ---
    > Ought to go into 2.6.25. For 2.6.23 and 2.6.24 stable? Well, I've
    > not actually seen this hang on any of these, though presumably it's
    > lurking there. Where I did see it, and test the fix, was 2.6.25-rc5-mm1:
    > whose SLUB had a disturbing predilection (since corrected) for order-4
    > allocations, even when allocating radix tree nodes.

    Thanks Hugh, definitely correct! I see it's already merged, so all is
    well.

    --
    Jens Axboe

    --
    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/

  3. Re: [PATCH] splice: use mapping_gfp_mask

    hi all!

    this patch for 2.6.22.y ?

    if i good see, the __generic_file_splice_read bring out to 2.6.22 ..

    http://repo.or.cz/w/linux-2.6.22.y-op-patches.git
    http://repo.or.cz/w/linux-2.6.22.y-op.git

    On 4/4/08, Jens Axboe wrote:
    > On Thu, Apr 03 2008, Hugh Dickins wrote:
    > > The loop block driver is careful to mask __GFP_IO|__GFP_FS out of its
    > > mapping_gfp_mask, to avoid hangs under memory pressure. But nowadays
    > > it uses splice, usually going through __generic_file_splice_read. That
    > > must use mapping_gfp_mask instead of GFP_KERNEL to avoid those hangs.
    > >
    > > Signed-off-by: Hugh Dickins
    > > ---
    > > Ought to go into 2.6.25. For 2.6.23 and 2.6.24 stable? Well, I've
    > > not actually seen this hang on any of these, though presumably it's
    > > lurking there. Where I did see it, and test the fix, was 2.6.25-rc5-mm1:
    > > whose SLUB had a disturbing predilection (since corrected) for order-4
    > > allocations, even when allocating radix tree nodes.
    >
    > Thanks Hugh, definitely correct! I see it's already merged, so all is
    > well.
    >
    > --
    > Jens Axboe
    >
    > --
    > 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/
    >


    --
    Thanks,
    Oliver
    --
    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/

  4. Re: [PATCH] splice: use mapping_gfp_mask

    On Fri, Apr 04 2008, Oliver Pinter wrote:
    > hi all!
    >
    > this patch for 2.6.22.y ?
    >
    > if i good see, the __generic_file_splice_read bring out to 2.6.22 ..
    >
    > http://repo.or.cz/w/linux-2.6.22.y-op-patches.git
    > http://repo.or.cz/w/linux-2.6.22.y-op.git

    Loop isn't affected before 2.6.23, so while it doesn't hurt to put it
    into 2.6.22, there's not much point either. 2.6.23 and 24 need the
    patch.


    >
    > On 4/4/08, Jens Axboe wrote:
    > > On Thu, Apr 03 2008, Hugh Dickins wrote:
    > > > The loop block driver is careful to mask __GFP_IO|__GFP_FS out of its
    > > > mapping_gfp_mask, to avoid hangs under memory pressure. But nowadays
    > > > it uses splice, usually going through __generic_file_splice_read. That
    > > > must use mapping_gfp_mask instead of GFP_KERNEL to avoid those hangs.
    > > >
    > > > Signed-off-by: Hugh Dickins
    > > > ---
    > > > Ought to go into 2.6.25. For 2.6.23 and 2.6.24 stable? Well, I've
    > > > not actually seen this hang on any of these, though presumably it's
    > > > lurking there. Where I did see it, and test the fix, was 2.6.25-rc5-mm1:
    > > > whose SLUB had a disturbing predilection (since corrected) for order-4
    > > > allocations, even when allocating radix tree nodes.
    > >
    > > Thanks Hugh, definitely correct! I see it's already merged, so all is
    > > well.
    > >
    > > --
    > > Jens Axboe
    > >
    > > --
    > > 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/
    > >
    >
    >
    > --
    > Thanks,
    > Oliver

    --
    Jens Axboe

    --
    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/
+ Reply to Thread
« Re: sata io freeze, 2.6.18 and also 2.6.24 | probably XFS regression 2.6.24.x to 2.6.25-rc7-git5, XFS very unstable »