lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 9 Jul 2017 18:04:17 +0300
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Okash Khawaja <okash.khawaja@...il.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>,
        Samuel Thibault <samuel.thibault@...-lyon.org>,
        Alan Cox <gnomes@...rguk.ukuu.org.uk>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        William Hubbs <w.d.hubbs@...il.com>,
        Chris Brannon <chris@...-brannons.com>,
        Kirk Reiser <kirk@...sers.ca>, speakup@...ux-speakup.org,
        devel@...verdev.osuosl.org
Subject: Re: [patch 1/3] tty: resolve tty contention between kernel and user space

On Sun, Jul 9, 2017 at 2:41 PM, Okash Khawaja <okash.khawaja@...il.com> wrote:

> +struct tty_struct *tty_kopen(dev_t device)
> +{
> +       struct tty_struct *tty;
> +       struct tty_driver *driver = NULL;
> +       int index = -1;
> +
> +       mutex_lock(&tty_mutex);
> +       driver = tty_lookup_driver(device, NULL, &index);
> +       if (IS_ERR(driver)) {

> +               mutex_unlock(&tty_mutex);
> +               return ERR_CAST(driver);

Hmm... perhaps

tty = ERR_CAST(driver);
goto out_unlock;

See below for further details.

> +       }
> +
> +       /* check whether we're reopening an existing tty */
> +       tty = tty_driver_lookup_tty(driver, NULL, index);
> +       if (IS_ERR(tty))
> +               goto out;
> +
> +       if (tty) {
> +               /* drop kref from tty_driver_lookup_tty() */
> +               tty_kref_put(tty);
> +               tty = ERR_PTR(-EBUSY);
> +       } else { /* tty_init_dev returns tty with the tty_lock held */
> +               tty = tty_init_dev(driver, index);
> +               set_bit(TTY_KOPENED, &tty->flags);
> +       }

> +out:

out_unlock: ?

> +       mutex_unlock(&tty_mutex);
> +       tty_driver_kref_put(driver);

I'm not sure I understand locking model here:

Above
1. take mutex
2. take reference

Here:
1. give mutex back
2. give reference back

I think we usually see symmetrical  calls, i.e.

1. give reference back
2. give mutex back

So, what did I miss?

> +       return tty;
> +}



-- 
With Best Regards,
Andy Shevchenko

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ