From: Al Viro <viro@ZenIV.linux.org.uk>
To: Gustavo Padovan <gustavo@padovan.org>
Cc: linux-media@vger.kernel.org, Hans Verkuil <hverkuil@xs4all.nl>,
Mauro Carvalho Chehab <mchehab@osg.samsung.com>,
Shuah Khan <shuahkh@osg.samsung.com>,
linux-kernel@vger.kernel.org,
Gustavo Padovan <gustavo.padovan@collabora.com>,
linux-fsdevel@vger.kernel.org,
Riley Andrews <riandrews@android.com>
Subject: Re: [PATCH v3 14/15] fs/files: export close_fd() symbol
Date: Thu, 7 Sep 2017 23:03:25 +0100 [thread overview]
Message-ID: <20170907220325.GY5426@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20170907212245.GA19307@jade>
On Thu, Sep 07, 2017 at 06:22:45PM -0300, Gustavo Padovan wrote:
> Sorry for my lack of knowledge here and thank you for the explanation,
> things are a lot clear to me. For some reasons I were trying to delay
> the sharing of the fd to a event later. I can delay the install of it
> but that my require __fd_install() to be available and exportedi as it
> may happen in a thread, but I believe you wouldn't be okay with that either,
> is that so?
Only if it has been given a reference to descriptor table to start with.
Which reference should've been acquired by the target process itself.
Why bother, anyway? You need to handle the case when the stream has
ended just after you'd copied the value to userland; at that point you
obviously can't go hunting for all references to struct file in question,
so you have to guaratee that methods will start giving an error from
that point on. What's the problem with just leaving it installed?
Both userland and kernel must cope with that sort of thing anyway, so
what does removing it from descriptor table and not reporting it buy
you? AFAICS, it's an extra layer of complexity for no good reason -
you are not getting it offset by simplifications anywhere else...
next prev parent reply other threads:[~2017-09-07 22:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20170907184226.27482-1-gustavo@padovan.org>
2017-09-07 18:42 ` [PATCH v3 14/15] fs/files: export close_fd() symbol Gustavo Padovan
2017-09-07 18:51 ` Eric Biggers
2017-09-07 20:36 ` Al Viro
2017-09-07 21:22 ` Gustavo Padovan
2017-09-07 22:03 ` Al Viro [this message]
2017-09-07 22:09 ` Hans Verkuil
2017-09-07 22:18 ` Gustavo Padovan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170907220325.GY5426@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=gustavo.padovan@collabora.com \
--cc=gustavo@padovan.org \
--cc=hverkuil@xs4all.nl \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@osg.samsung.com \
--cc=riandrews@android.com \
--cc=shuahkh@osg.samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).