undefined reference to `ioctl_tty'

Jeffrey Walton noloader at gmail.com
Wed Mar 6 03:50:10 EST 2019


On Wed, Mar 6, 2019 at 3:36 AM <valdis.kletnieks at vt.edu> wrote:
>
> On Wed, 06 Mar 2019 01:58:41 -0500, Jeffrey Walton said:
>
> >        TIOCEXCL  void
> >               Put the terminal into exclusive mode.  No further open(2)
> >               operations on the terminal are permitted.  (They fail with
> >               EBUSY, except for a process with the CAP_SYS_ADMIN
> >               capability.)
>
> Note that this is still slightly racy - if two processes both try to do an open
> and an ioctl, this can happen:
>
> Process 1       open()
>                 Process 2 open()
> Process 1 ioctl(TIOEXCL)
>                 Process 2 ioctl()
>
> But at this point, the second process has already succeeded in opening the
> device, so "no further opens" doesn't save you.
>
> Usually, this sort of race would be really hard to hit, especially if the
> ioctl() happens right after the open() - except that many systems will use cron
> or similar to launch stuff "once per hour" or similar.  And they end up
> batching together two processes that each try to do this. Suddenly, it's a lot
> easier to hit that hole when cron launches two processes at 12:54:17 PM.....
>
> If there's one thing I've learned from almost 4 decades of sysadmin'ing on all
> sorts of systems, saying "Oh that timing hole is so tiny it won't ever get hit
> in production" guarantees that the Clock Gods will smite you for your hubris.

Yeah, the race seems to be the downside to ioctl and TIOEXCL.

It is too bad Linux does not honor O_EXCL for the device, or provide a
similar open flag like SOCK_NONBLOCK was added to avoid the race in
sockets. It would avoid a lot of problems.

Jeff



More information about the Kernelnewbies mailing list