netdev - Re: [PATCH 3/8] net/socket: sock_map_fd

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]

Message-Id: <20150309.235605.1023100303494694986.davem@davemloft.net>
Date:	Mon, 09 Mar 2015 23:56:05 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	zenczykowski@...il.com
Cc:	maze@...gle.com, edumazet@...gle.com, tytso@....edu,
	netdev@...r.kernel.org
Subject: Re: [PATCH 3/8] net/socket: sock_map_fd - reverse allocation order

From: Maciej Żenczykowski <zenczykowski@...il.com>
Date: Mon,  9 Mar 2015 14:19:58 -0700

> From: Maciej Żenczykowski <maze@...gle.com>
> 
> Signed-off-by: Maciej Żenczykowski <maze@...gle.com>

The ordering of these operations was carefully choosen over the years
such that we prioritize "easy" things to allocate and recover from,
before harder things.

And allocating and releasing an 'fd' is much cheaper to deal with than
a socket file object.

And as has been shown in the accept() case, you're even changing user
visible semantics.

If you really want to reduce the amount of locking, create __*()
interfaces that assume the files lock is held already, and take
them around a batch of related operations.

By adding the file argument to the fs interfaces you making the caller
become a contortionist in order to fit into the interfaces
requirements.  Just let the callers do what they already do, which we
already know is correct and properly prioritized ordering wise, and
control the locking at a higher level.
--
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