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:	Thu, 5 Mar 2015 10:09:59 +0300
From:	Ilya Dryomov <idryomov@...il.com>
To:	Mike Christie <mchristi@...hat.com>
Cc:	Mel Gorman <mgorman@...e.de>, 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 Thu, Mar 5, 2015 at 7:13 AM, Mike Christie <mchristi@...hat.com> wrote:
> On 03/04/2015 10:03 PM, Mike Christie wrote:
>> 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?
>>
>
> Oh yeah, maybe I misunderstood you. Were you just saying we should not
> be using it for the configuration we are hitting the problem on?

NFS seems to be a bit of special case: its SOCK_MEMALLOC is set only
for swap sockets and it's a filesystem.  Mel's patch sets SOCK_MEMALLOC
on all nbd sockets unconditionally, but AFAICT there was a distinct
effort to make loopback nbd work (commit 48cf6061b302, "NBD: allow nbd
to be used locally").  I suspect it's currently broken in the same way.

Thanks,

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