lkml.org 
[lkml]   [2018]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: [GIT PULL] f2fs update for 4.18-rc1
    Date
    Argh, you used my Outlook email address, so you get top-posting 😉

    The radix tree does rely on constructors still. One of the things on my todo list is to verify whether it actually makes sense to do that or not. It may continue to make sense; the radix tree node is 576 bytes (9 cache lines) and the normal usage of a freshly allocated radix tree node will touch only one or two cachelines. Radix tree nodes naturally come back to the cache zeroed, so there's no cache pollution when destroying them either.

    We didn't send that patch upstream; instead we said that anybody who specifies __GFP_ZERO on a slab with constructors is crazy and fixed it with commits abc1be13fd113ddef5e2d807a466286b864caed3 and 128227e7fe4087b60f1bd31f762e61237eb23790

    I don't really understand why Jaegeuk is changing f2fs now when we've just fixed the core kernel to make what he's doing perfectly legal.

    > -----Original Message-----
    > From: Linus Torvalds <torvalds@linux-foundation.org>
    > Sent: Monday, June 11, 2018 1:28 PM
    > To: Jaegeuk Kim <jaegeuk@kernel.org>; Matthew Wilcox
    > <mawilcox@microsoft.com>
    > Cc: Linux F2FS DEV, Mailing List <linux-f2fs-devel@lists.sourceforge.net>; Linux
    > Kernel Mailing List <linux-kernel@vger.kernel.org>
    > Subject: Re: [GIT PULL] f2fs update for 4.18-rc1
    >
    > On Mon, Jun 11, 2018 at 9:52 AM Jaegeuk Kim <jaegeuk@kernel.org> wrote:
    > >
    > > In order to avoid old MM bug [1], we decided not to use __GFP_ZERO
    > > for the mapping for node and meta page caches.
    > >
    > > [1]
    > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org
    > %2Flkml%2F2018%2F4%2F8%2F661&data=02%7C01%7Cmawilcox%40microso
    > ft.com%7Ce69c1f9a8d6a44bda36e08d5cfc0b1a5%7C72f988bf86f141af91ab2d
    > 7cd011db47%7C1%7C0%7C636643348874608385&sdata=xbAg0cOMxyrY4NY
    > ysTj1X0DPTdxwT24oYu1cxO45nkQ%3D&reserved=0
    >
    > Hmm. The patch there looks correct, and anybody who relies on slab
    > constructors is crazy.
    >
    > That email from April says it should go into stable, but it never even
    > went upstream..
    >
    > Adding Willy to the cc, for comments, since he's been active there and
    > is probably the maintainer even if the MAINTAINERS file doesn't say
    > so..
    >
    > Willy?
    >
    > Linus
    \
     
     \ /
      Last update: 2018-06-11 20:22    [W:3.466 / U:0.088 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site