[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240510-duzen-uhrmacher-141c9331f1bf@brauner>
Date: Fri, 10 May 2024 12:55:07 +0200
From: Christian Brauner <brauner@...nel.org>
To: Daniel Vetter <daniel@...ll.ch>
Cc: Christian König <ckoenig.leichtzumerken@...il.com>,
Linus Torvalds <torvalds@...ux-foundation.org>, Al Viro <viro@...iv.linux.org.uk>, keescook@...omium.org,
axboe@...nel.dk, christian.koenig@....com, dri-devel@...ts.freedesktop.org,
io-uring@...r.kernel.org, jack@...e.cz, laura@...bott.name, linaro-mm-sig@...ts.linaro.org,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
minhquangbui99@...il.com, sumit.semwal@...aro.org,
syzbot+045b454ab35fd82a35fb@...kaller.appspotmail.com, syzkaller-bugs@...glegroups.com
Subject: Re: [Linaro-mm-sig] Re: [PATCH] epoll: try to be a _bit_ better
about file lifetimes
> For the uapi issue you describe below my take would be that we should just
> try, and hope that everyone's been dutifully using O_CLOEXEC. But maybe
> I'm biased from the gpu world, where we've been hammering it in that
> "O_CLOEXEC or bust" mantra since well over a decade. Really the only valid
Oh, we're very much on the same page. All new file descriptor types that
I've added over the years are O_CLOEXEC by default. IOW, you need to
remove O_CLOEXEC explicitly (see pidfd as an example). And imho, any new
fd type that's added should just be O_CLOEXEC by default.
Powered by blists - more mailing lists