Re: [patch 0/3] Re: tty contention resulting from tty_open_by_device export

On Tue, Jul 18, 2017 at 03:26:37PM +0300, Dan Carpenter wrote: > > + 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

Re: [patch 0/3] Re: tty contention resulting from tty_open_by_device export

> The patch is untested but I can work on this if that fits in with the > plans for tty. I think this is the right direction. Alan ___ devel mailing list de...@linuxdriverproject.org

Re: [patch 0/3] Re: tty contention resulting from tty_open_by_device export

On Tue, Jul 18, 2017 at 12:29:52PM +0100, Okash Khawaja wrote: > +struct tty_struct *tty_kopen(dev_t device) > +{ > + struct tty_struct *tty; > + struct tty_driver *driver = NULL; > + int index = -1; > + > + mutex_lock(_mutex); > + driver = tty_lookup_driver(device,

Re: [patch 0/3] Re: tty contention resulting from tty_open_by_device export

On Mon, Jul 17, 2017 at 11:04:38PM +0100, Alan Cox wrote: > > > Sure. I can fix the tty->count mismatch based on Alan's suggestion. However > > I don't understand why the exclusivity flag should belong to tty_port and > > not tty_struct. It will be good to know why. > > We are trying to move

Re: [patch 0/3] Re: tty contention resulting from tty_open_by_device export

> Sure. I can fix the tty->count mismatch based on Alan's suggestion. However I > don't understand why the exclusivity flag should belong to tty_port and not > tty_struct. It will be good to know why. We are trying to move all the flags that we can and structs into the tty_port, except any

Re: [patch 0/3] Re: tty contention resulting from tty_open_by_device export

> On 17 Jul 2017, at 13:31, Greg Kroah-Hartman > wrote: > >> On Thu, Jul 13, 2017 at 12:29:54PM +0100, Okash Khawaja wrote: >>> On Wed, Jul 12, 2017 at 07:20:28PM +0100, Alan Cox wrote: >>> When opening from kernel, we don't use file pointer. The count

Re: [patch 0/3] Re: tty contention resulting from tty_open_by_device export

On Thu, Jul 13, 2017 at 12:29:54PM +0100, Okash Khawaja wrote: > On Wed, Jul 12, 2017 at 07:20:28PM +0100, Alan Cox wrote: > > > > > When opening from kernel, we don't use file pointer. The count mismatch > > > is between tty->count and #fd's. So opening from kernel leads to #fd's > > > being

Re: [patch 0/3] Re: tty contention resulting from tty_open_by_device export

On Wed, Jul 12, 2017 at 07:20:28PM +0100, Alan Cox wrote: > > > When opening from kernel, we don't use file pointer. The count mismatch > > is between tty->count and #fd's. So opening from kernel leads to #fd's > > being less than tty->count. I thought this difference is relevant to > >

Re: [patch 0/3] Re: tty contention resulting from tty_open_by_device export

> When opening from kernel, we don't use file pointer. The count mismatch > is between tty->count and #fd's. So opening from kernel leads to #fd's > being less than tty->count. I thought this difference is relevant to > user-space opening of tty, and not to kernel opening of tty. Can you >

Re: [patch 0/3] Re: tty contention resulting from tty_open_by_device export

On Mon, Jul 10, 2017 at 01:33:07PM +0100, Okash Khawaja wrote: > > If the tty counts are being misreported then it would be better to fix > > the code to actually manage the counts properly. The core tty code is > > telling you that the tty is not in a valid state. While this is of > > itself a

Re: [patch 0/3] Re: tty contention resulting from tty_open_by_device export

On Mon, Jul 10, 2017 at 12:52:33PM +0100, Alan Cox wrote: > On Sun, 09 Jul 2017 12:41:53 +0100 > Okash Khawaja wrote: > > > On Sat, Jul 08, 2017 at 10:38:03AM +0200, Greg Kroah-Hartman wrote: > > > Overall, the idea looks sane to me. Keeping userspace from opening a > >

Re: [patch 0/3] Re: tty contention resulting from tty_open_by_device export

On Sun, 09 Jul 2017 12:41:53 +0100 Okash Khawaja wrote: > On Sat, Jul 08, 2017 at 10:38:03AM +0200, Greg Kroah-Hartman wrote: > > Overall, the idea looks sane to me. Keeping userspace from opening a > > tty that the kernel has opened internally makes sense, hopefully >

Re: [patch 0/3] Re: tty contention resulting from tty_open_by_device export

On Sun, Jul 09, 2017 at 12:41:53PM +0100, Okash Khawaja wrote: > On Sat, Jul 08, 2017 at 10:38:03AM +0200, Greg Kroah-Hartman wrote: > > Overall, the idea looks sane to me. Keeping userspace from opening a > > tty that the kernel has opened internally makes sense, hopefully > > userspace doesn't