Thread (23 messages) 23 messages, 7 authors, 2011-09-27

Re: [PATCH 1/4] TTY: serial, fix locking imbalance

From: Jiri Slaby <hidden>
Date: 2011-09-23 19:21:26
Also in: lkml

On 09/23/2011 09:08 PM, Greg KH wrote:
On Fri, Sep 23, 2011 at 08:52:16PM +0200, Jiri Slaby wrote:
quoted
On 09/23/2011 12:46 AM, Greg KH wrote:
quoted
On Wed, Aug 31, 2011 at 09:24:56PM +0200, Jiri Slaby wrote:
quoted
Commit "TTY: serial, move locking in uart_close" moved the lock, but
omitted to update branches which unlock the lock. Now they try to
unlock the lock without holding it.

Signed-off-by: Jiri Slaby <redacted>
---
If possible, please, merge this into the patch mentioned above (it's
not upstream yet).
I can't do that,
Hmm, but what is the reason for that? I mean, why do you prefer a kernel
with broken history with respect to bisection? Per definition -next
doesn't mind rebases in subtrees. Or is this already in tty-linus branch
(I cannot check now, obviously)?
Because it is in my tree and I can't rebase it as others depend on it
(linux-next and others.)
linux-next doesn't mind if you rebase. That's exactly what it is for. To
test commits collected from #for-next branches and alter them if needed.
It merges whatever is in the current branch no matter what was there
some days ago.

But if there are more trees depending on the tree, then OK, I will live
with that ;).

thanks,
-- 
js
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help