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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 18 Aug 2020 03:22:49 +0100 From: Al Viro <viro@...iv.linux.org.uk> To: "Eric W. Biederman" <ebiederm@...ssion.com> Cc: linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org, criu@...nvz.org, bpf@...r.kernel.org, Linus Torvalds <torvalds@...ux-foundation.org>, Christian Brauner <christian.brauner@...ntu.com>, Oleg Nesterov <oleg@...hat.com>, Cyrill Gorcunov <gorcunov@...il.com>, Jann Horn <jann@...jh.net>, Kees Cook <keescook@...omium.org>, Daniel P. Berrangé <berrange@...hat.com>, Jeff Layton <jlayton@...hat.com>, Miklos Szeredi <miklos@...redi.hu>, Matthew Wilcox <willy@...ian.org>, "J. Bruce Fields" <bfields@...ldses.org>, Matthew Wilcox <matthew@....cx>, Trond Myklebust <trond.myklebust@....uio.no>, Chris Wright <chrisw@...hat.com>, Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, Martin KaFai Lau <kafai@...com>, Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>, Andrii Nakryiko <andriin@...com>, John Fastabend <john.fastabend@...il.com>, KP Singh <kpsingh@...omium.org> Subject: Re: [PATCH 10/17] proc/fd: In proc_readfd_common use fnext_task On Mon, Aug 17, 2020 at 05:04:18PM -0500, Eric W. Biederman wrote: > When discussing[1] exec and posix file locks it was realized that none > of the callers of get_files_struct fundamentally needed to call > get_files_struct, and that by switching them to helper functions > instead it will both simplify their code and remove unnecessary > increments of files_struct.count. Those unnecessary increments can > result in exec unnecessarily unsharing files_struct which breaking > posix locks, and it can result in fget_light having to fallback to > fget reducing system performance. > > Using fnext_task simplifies proc_readfd_common, by moving the checking > for the maximum file descritor into the generic code, and by > remvoing the need for capturing and releasing a reference on > files_struct. Yecchhh... So you keep locking/unlocking the damn thing for each descriptor?
Powered by blists - more mailing lists