All of lore.kernel.org
 help / color / mirror / Atom feed
From: hle@owl.eu.com (Hugo Lefeuvre)
To: kernelnewbies@lists.kernelnewbies.org
Subject: develoment workflow: how to avoid duplicate work ?
Date: Mon, 4 Jun 2018 18:31:31 -0400	[thread overview]
Message-ID: <20180604223131.GA1981@hle-laptop.local> (raw)
In-Reply-To: <12368.1528128607@turing-police.cc.vt.edu>

> > > The vfs documentation states: release() is "called when the last
> > > reference to an open file is closed".
> > > 
> > > Let's say we have a program with threads T1 and T2.
> > > 
> > > - T1 calls ioctl on a file descriptor FD.
> > > - (on another processor) T2 closes FD.
> > > 
> > > Since the last reference to FD was closed by T2, release is called.
> 
> That's subtly wrong.  T2 releases its reference to the file descriptor.
>
> > > But while release is being called, the ioctl call from T1 may still
> > > be running, right ?
> 
> Remember that ioctl needs an open FD as well - so the ioctl() grabs its own
> reference, and then *that* reference to the file descriptor stays in place at
> least until the ioctl() return.  At *that* point, the reference count goes to
> zero and the file is actually closed.

Well, my assumption was that T1 and T2 would share the exact same file
descriptor. For example, a main thread T0 would call open() to get the
file descriptor, and then spawn T1 and T2 which would both use this
common FD.

Let's say:

- main thread T0 calls open() and gets FD 3
- T0 spawns T1 and T2
- T1 calls ioctl(3, ...) or read(3, ...)/write(3, ...)
- (on another processor) T2 calls close(3)

Do you mean that the ioctl/read/write call increments the reference
count in this case ? It would mean that these syscalls aren't really
using passed FD but instead create duplicates to make sure the open
file description won't be freed during their execution, right ?

Cheers,
 hugo

-- 
             Hugo Lefeuvre (hle)    |    www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180604/88175342/attachment.sig>

  reply	other threads:[~2018-06-04 22:31 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-29  3:07 develoment workflow: how to avoid duplicate work ? Hugo Lefeuvre
2018-05-29  3:32 ` valdis.kletnieks at vt.edu
2018-05-30  2:56   ` Hugo Lefeuvre
2018-05-30 15:03     ` valdis.kletnieks at vt.edu
2018-05-31  1:44       ` Hugo Lefeuvre
2018-06-03 19:23         ` Valentin Vidic
2018-06-03 22:25           ` Hugo Lefeuvre
2018-06-04  3:33             ` Valentin Vidic
     [not found]               ` <20180604062743.GB19954@osadl.at>
2018-06-04  9:31                 ` Valentin Vidic
2018-06-04 12:36                   ` Hugo Lefeuvre
2018-06-04 16:10               ` valdis.kletnieks at vt.edu
2018-06-04 22:31                 ` Hugo Lefeuvre [this message]
2018-06-05  5:55                   ` valdis.kletnieks at vt.edu
2018-06-05 14:20                     ` Hugo Lefeuvre
2018-06-05 14:33                       ` valdis.kletnieks at vt.edu
2018-06-05 17:47                         ` Valentin Vidic
2018-06-06  1:48                           ` Hugo Lefeuvre
2018-05-29  5:50 ` Greg KH
2018-05-30  3:08   ` Hugo Lefeuvre

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=20180604223131.GA1981@hle-laptop.local \
    --to=hle@owl.eu.com \
    --cc=kernelnewbies@lists.kernelnewbies.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.