linux-kernel - Re: [PATCH v5 26/44] tty: Add read-recursive, writer-prioritized rw semaphore

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]

Message-ID: <20130318235815.GA5320@kroah.com>
Date:	Mon, 18 Mar 2013 16:58:15 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Peter Hurley <peter@...leysoftware.com>
Cc:	Jiri Slaby <jslaby@...e.cz>, Sasha Levin <levinsasha928@...il.com>,
	Dave Jones <davej@...hat.com>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	Shawn Guo <shawn.guo@...aro.org>, linux-kernel@...r.kernel.org,
	linux-serial@...r.kernel.org
Subject: Re: [PATCH v5 26/44] tty: Add read-recursive, writer-prioritized rw
 semaphore

On Mon, Mar 11, 2013 at 04:44:46PM -0400, Peter Hurley wrote:
> The semantics of a rw semaphore are almost ideally suited
> for tty line discipline lifetime management;  multiple active
> threads obtain "references" (read locks) while performing i/o
> to prevent the loss or change of the current line discipline
> (write lock).
> 
> Unfortunately, the existing rw_semaphore is ill-suited in other
> ways;
> 1) obtaining a "reference" can be recursive, ie., a reference holder
>    may attempt to obtain another "reference". Recursive read locks
>    are not supported by rwsem.

Why does a ldisc need to obtain this recursively?

> 2) TIOCSETD ioctl (change line discipline) expects to return an
>    error if the line discipline cannot be exclusively locked within
>    5 secs. Lock wait timeouts are not supported by rwsem.

Don't we have some other lock that can timeout?

> 3) A tty hangup is expected to halt and scrap pending i/o, so
>    exclusive locking must be prioritized without precluding
>    existing reference holders from obtaining recursive read locks.
>    Writer priority is not supported by rwsem.

But how bad is it really if we have to wait a bit for that write lock to
get through all of the existing readers?  Either way, we are supposed to
be dropping i/o, so it shouldn't be a big deal, right?

> Add ld_semaphore which implements these requirements in a
> semantically and operationally similar way to rw_semaphore.

I _really_ don't want to add a new lock to the kernel, especially one
that is only used by one "driver".  You are going to have to convince
the current lock authors that this really is needed, before I can take
it, sorry.

What is wrong with the existing ldisc code that the creation of this
lock is needed?  Is our current code that broken?

Ok, it is the tty layer, so it probably is, but it's made it this far
for the past 20 years...

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/