linux-kernel - Re: [PATCH v3 4/4] futex: Avoid taking hb lock if nothing to wakeup

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: <20131220102742.GA22187@gmail.com>
Date:	Fri, 20 Dec 2013 11:27:42 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Joe Perches <joe@...ches.com>, Davidlohr Bueso <davidlohr@...com>,
	linux-kernel@...r.kernel.org, mingo@...hat.com,
	dvhart@...ux.intel.com, tglx@...utronix.de,
	paulmck@...ux.vnet.ibm.com, efault@....de, jeffm@...e.com,
	torvalds@...ux-foundation.org, jason.low2@...com,
	Waiman.Long@...com, tom.vaden@...com, scott.norton@...com,
	aswin@...com
Subject: Re: [PATCH v3 4/4] futex: Avoid taking hb lock if nothing to wakeup


* Peter Zijlstra <peterz@...radead.org> wrote:

> On Thu, Dec 19, 2013 at 02:35:17PM -0800, Joe Perches wrote:
> > On Thu, 2013-12-19 at 20:42 +0100, Ingo Molnar wrote:
> > > * Davidlohr Bueso <davidlohr@...com> wrote:
> > > 
> > > > On Thu, 2013-12-19 at 20:25 +0100, Ingo Molnar wrote:
> > > > > * Davidlohr Bueso <davidlohr@...com> wrote:
> > > > > 
> > > > > > Signed-off-by: Davidlohr Bueso <davidlohr@...com>
> > > > > > Signed-off-by: Waiman Long <Waiman.Long@...com>
> > > > > > Signed-off-by: Jason Low <jason.low2@...com>
> > > > > 
> > > > > So, that's not a valid SOB sequence either, the person 
> > > > > sending me a patch should be the last person in the SOB 
> > > > > chain
> > > > 
> > > > Which is why I had it like that in the original version.
> > > 
> > > The problem with that order was that the first person should be 
> > > the primary author and in the 'From' tag.
> > > 
> > > A SOB chain is intended to depict the true propagation/route of 
> > > a patch, from author, through maintainers who handle and forward 
> > > it, to the maintainer who applies it to a Git tree. The patch 
> > > starts up with a single SOB (the primary author's) and every 
> > > 'hop' after that adds a SOB to the tail of the existing SOB 
> > > chain.
> > 
> > Multiple "Signed-off-by:"s are also used when there are multiple 
> > authors of a single patch.
> 
> Abused; which is exactly what we're saying is not correct.
> 
> While doing so we've also found people abusing SoB where Reviewed-by 
> was meant and other 'creative' use.

Yes, so I used to allow and author such signoff sequences years ago, 
but eventually Linus noticed the weirdness and asked me not to do it.

There's so many ways to credit people for contributions:

  - Reviewed-by, Acked-by tags carry credits

  - The changelog can mention someone specifically

  - I sometimes add the "Originally-by:" special tag, if an original
    patch was turned into a real patch by someone else.

  - If there's truly serious contribution then the code itself can
    carry a credit as well.

  - In a clean workflow authorship is naturally expressed through
    being the author of individual patches, and we want to encourage
    people to use clean workflows.

Having clean SOB sequences is also really useful: for example LWN.net 
is trying to keep track of the route of patches, and having 'creative' 
uses for signoffs adds unnecessary noise.

So there's no strong technical justification to pollute the SOB 
sequence with contibution/courtesy Signed-off-by lines, while there's 
good technological reasons to keep it a clean route.

I don't think Linus is buerocratically checking every single SOB 
sequence but statistically if you do too many messy signoffs someone 
eventually notices.

So I'm enforcing clean signoff sequences for the subsystems I maintain 
and patches I apply to Git - I might miss some, and it's not the end 
of the world since it has no functional side effects. Other 
maintainers might be more permissive.

It might make sense to clarify Documentation/SubmittingPatches 
accordingly.

Thanks,

	Ingo
--
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/