Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1617551

Re: [Nbd] [PATCH 3/4] treewide: convert PF_MEMALLOC manipulations to new helpers

Show all headers | View raw

On Wed, Apr 05, 2017 at 01:30:31PM +0200, Michal Hocko wrote:
> On Wed 05-04-17 09:46:59, Vlastimil Babka wrote:
> > We now have memalloc_noreclaim_{save,restore} helpers for robust setting and
> > clearing of PF_MEMALLOC. Let's convert the code which was using the generic
> > tsk_restore_flags(). No functional change.
> 
> It would be really great to revisit why those places outside of the mm
> proper really need this flag. I know this is a painful exercise but I
> wouldn't be surprised if there were abusers there.
[...]
> > ---
> >  drivers/block/nbd.c      | 7 ++++---
> >  drivers/scsi/iscsi_tcp.c | 7 ++++---
> >  net/core/dev.c           | 7 ++++---
> >  net/core/sock.c          | 7 ++++---
> >  4 files changed, 16 insertions(+), 12 deletions(-)

These were all done to make swapping over network safe. The idea is that
if a socket has SOCK_MEMALLOC set, incoming packets for that socket can
access PFMEMALLOC reserves (whereas other sockets cannot); this all in
the hope that one packe destined to that socket will contain the TCP ACK
that confirms the swapout was successful and we can now release RAM
pages for other processes.

I don't know whether they need the PF_MEMALLOC flag specifically (not a
kernel hacker), but they do need to interact with it at any rate.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[PATCH 0/4] more robust PF_MEMALLOC handling Vlastimil Babka <vbabka@suse.cz> - 2017-04-05 09:50 +0200
  [PATCH 3/4] treewide: convert PF_MEMALLOC manipulations to new helpers Vlastimil Babka <vbabka@suse.cz> - 2017-04-05 09:50 +0200
    Re: [PATCH 3/4] treewide: convert PF_MEMALLOC manipulations to new  helpers Michal Hocko <mhocko@kernel.org> - 2017-04-05 13:40 +0200
      Re: [Nbd] [PATCH 3/4] treewide: convert PF_MEMALLOC manipulations to  new helpers Wouter Verhelst <w@uter.be> - 2017-04-06 09:00 +0200
        Re: [Nbd] [PATCH 3/4] treewide: convert PF_MEMALLOC manipulations to  new helpers Mel Gorman <mgorman@techsingularity.net> - 2017-04-06 13:30 +0200
  [PATCH 1/4] mm: prevent potential recursive reclaim due to clearing PF_MEMALLOC Vlastimil Babka <vbabka@suse.cz> - 2017-04-05 09:50 +0200
    Re: [PATCH 1/4] mm: prevent potential recursive reclaim due to  clearing PF_MEMALLOC Michal Hocko <mhocko@kernel.org> - 2017-04-05 13:30 +0200
    Re: [PATCH 1/4] mm: prevent potential recursive reclaim due to clearing PF_MEMALLOC "Hillf Danton" <hillf.zj@alibaba-inc.com> - 2017-04-07 09:40 +0200
    Re: [PATCH 1/4] mm: prevent potential recursive reclaim due to  clearing PF_MEMALLOC Vlastimil Babka <vbabka@suse.cz> - 2017-04-07 11:30 +0200
  [PATCH 4/4] mtd: nand: nandsim: convert to memalloc_noreclaim_*() Vlastimil Babka <vbabka@suse.cz> - 2017-04-05 09:50 +0200
    Re: [PATCH 4/4] mtd: nand: nandsim: convert to memalloc_noreclaim_*() Vlastimil Babka <vbabka@suse.cz> - 2017-04-05 13:40 +0200
      Re: [PATCH 4/4] mtd: nand: nandsim: convert to memalloc_noreclaim_*() Michal Hocko <mhocko@kernel.org> - 2017-04-05 14:20 +0200
      Re: [PATCH 4/4] mtd: nand: nandsim: convert to memalloc_noreclaim_*() Adrian Hunter <adrian.hunter@intel.com> - 2017-04-06 08:50 +0200
        Re: [PATCH 4/4] mtd: nand: nandsim: convert to memalloc_noreclaim_*() Michal Hocko <mhocko@kernel.org> - 2017-04-06 09:30 +0200
    Re: [PATCH 4/4] mtd: nand: nandsim: convert to memalloc_noreclaim_*() Michal Hocko <mhocko@kernel.org> - 2017-04-05 13:40 +0200
      Re: [PATCH 4/4] mtd: nand: nandsim: convert to memalloc_noreclaim_*() Richard Weinberger <richard@nod.at> - 2017-04-05 13:40 +0200

csiph-web