netdev - Re: [PATCH v2] net: fix sk_page_frag() recursion from memory reclaim

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]

Message-ID: <20191101171202.GP3622521@devbig004.ftw2.facebook.com>
Date:   Fri, 1 Nov 2019 10:12:02 -0700
From:   Tejun Heo <tj@...nel.org>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     Shakeel Butt <shakeelb@...gle.com>,
        Michal Hocko <mhocko@...nel.org>,
        "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
        Kernel Team <kernel-team@...com>,
        LKML <linux-kernel@...r.kernel.org>,
        Josef Bacik <josef@...icpanda.com>,
        Eric Dumazet <eric.dumazet@...il.com>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        Johannes Weiner <hannes@...xchg.org>,
        Linux MM <linux-mm@...ck.org>, Mel Gorman <mgorman@...e.de>
Subject: Re: [PATCH v2] net: fix sk_page_frag() recursion from memory reclaim

Hello,

On Thu, Oct 31, 2019 at 04:20:49PM -0700, Andrew Morton wrote:
> > > In [0], tcp_send_msg_locked() was using current->page_frag when it
> 
> "tcp_sendmsg_locked" and "current->task_frag".  Stuff like this makes
> review harder :(

lol, sorry about that.

> > > Fix it by adding gfpflags_normal_context() which tests sleepable &&
> > > !reclaim and use it to determine whether to use current->task_frag.
> > >
> 
> Dumb-but-obvious question.  Rather than putzing with allocation modes,
> is it not feasible to change the net layer to copy the current value of
> current->task_frag into a local then restore its value when it has
> finished being used?

It's being used as an allocation cache, so doing so would lead to the
same area getting allocated for two packets at the same time instead
overrunning the end of the cache.

Thanks.

-- 
tejun