netdev - Re: SOCK_MEMALLOC vs loopback

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] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 04 Mar 2015 22:03:51 -0600
From:	Mike Christie <mchristi@...hat.com>
To:	Mel Gorman <mgorman@...e.de>, Ilya Dryomov <idryomov@...il.com>
CC:	ceph-devel@...r.kernel.org, Eric Dumazet <edumazet@...gle.com>,
	Sage Weil <sage@...hat.com>, NeilBrown <neilb@...e.de>,
	netdev@...r.kernel.org
Subject: Re: SOCK_MEMALLOC vs loopback

On 03/04/2015 02:04 PM, Mel Gorman wrote:
> On Wed, Mar 04, 2015 at 09:38:48PM +0300, Ilya Dryomov wrote:
>> Hello,
>>
>> A short while ago Mike added a patch to libceph to set SOCK_MEMALLOC on
>> libceph sockets and PF_MEMALLOC around send/receive paths (commit
>> 89baaa570ab0, "libceph: use memalloc flags for net IO").  rbd is much
>> like nbd and is succeptible to all the same memory allocation
>> deadlocks, so it seemed like a step in the right direction.
>>
> 
> The contract for SOCK_MEMALLOC is that it would only be used for temporary
> allocations that were necessary for the system to make forward progress. In
> the case of swap-over-NFS, it would only be used for transmitting
> buffers that were necessary to write data to swap when there were no

Are upper layers like NFS/iSCSI/NBD/RBD supposed to know or track when
there are no other options (for example if a GFP_ATOMIC allocation
fails, then set the flags and retry the operation), or are they supposed
to be able to set the flags, send IO and let the network layer handle it?

> other options. If that contract is not met then using it can deadlock the
> system. It's the same for PF_MEMALLOC -- activating that is a recipe for
> deadlock due to memory exhaustion.

For rbd and iscsi's SOCK_MEMALLOC/PF_MEMALLOC use, I copied what you did
for nbd in commit 7f338fe4540b1d0600b02314c7d885fd358e9eca which always
sets those flags and seems to rely on the network layer to do the right
thing. Are they all incorrect?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html