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

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:	Fri, 23 Sep 2011 15:04:40 -0700
From:	Greg KH <gregkh@...e.de>
To:	Jiri Slaby <jirislaby@...il.com>
Cc:	Jiri Slaby <jslaby@...e.cz>, Greg KH <greg@...ah.com>,
	Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@...esas.com>,
	linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org,
	Stephen Rothwell <sfr@...b.auug.org.au>
Subject: Re: [PATCH 1/4] TTY: serial, fix locking imbalance

On Fri, Sep 23, 2011 at 09:21:20PM +0200, Jiri Slaby wrote:
> On 09/23/2011 09:08 PM, Greg KH wrote:
> > On Fri, Sep 23, 2011 at 08:52:16PM +0200, Jiri Slaby wrote:
> >> On 09/23/2011 12:46 AM, Greg KH wrote:
> >>> On Wed, Aug 31, 2011 at 09:24:56PM +0200, Jiri Slaby wrote:
> >>>> 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 <jslaby@...e.cz>
> >>>> ---
> >>>> 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.

Users who base their work on mine care if I rebase.

And so do I, it's just one of those rules, "Greg will not rebase his
trees" that makes for better development.

And yes, sometimes it does cause minor problems like this, but overall,
it's much easier for everyone involved.

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

For the tty tree, I really doubt it, but I am not sure (rumor has it
that some people are basing on it, but that might just be rumor.)  For
my staging and USB trees, I can't rebase as I know I have users for
those trees.

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/