> On Sep 30, 2022, at 5:57 PM, Robert Elz <kre%munnari.OZ.AU@localhost> wrote: > > Date: Fri, 30 Sep 2022 16:34:20 -0400 > From: Christos Zoulas <christos%zoulas.com@localhost> > Message-ID: <232331AD-D501-4547-B730-03590C0C9935%zoulas.com@localhost> > > | How about handling exclose there? > > That would be possible, but why? We still need higher level code to > handle the locking, which can also handle cloexec -- the problem we > have now is simply that the relevant call is missing, I don't think adding > it will be hard, but it needs to be done by someone who understands the > locking requirements, and correct exit strategy in this case if an error > occurs (failing to successfully lock a newly created clone would seem to > be a very bizarre case, but still...) That is, I don't feel competent to > suggest the 3 or 4 lines that ought be added in do_open to fix this (for > just O_CLOEXEC it would be trivial there, as that cannot fail). > > Currently fd_affix (I mistakenly made it fp_affix in the last message...) > doesn't have a flags parameter, so to do it the way you suggest, we'd need > to alter its signature, bump to 9.99.101 (and I haven't yet gotten around > to making my kernel be 98.99.100 which I'm kind of planning to do ...) > and go alter all the calls everywhere, mostly just filling in an extra > arg with a 0. It does not need an extra flag (it looks in the file descriptor flags to find if it needs to set or not. In fact the first thing I thought was to add an assertion to make sure that the flags agrees with that is set in exclose, to find other cases where we forgot to call fd_set_exclose() before calling fd_affix(). It also does not need locking because the process can't access the descriptor before calling fd_affix. christos
Attachment:
signature.asc
Description: Message signed with OpenPGP