linux-kernel - Re: [Xen-devel] [PATCH v2 0/4] xen: prefer xenbus_scanf() over xenbus

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] [day] [month] [year] [list]

Message-ID: <20160708155446.GA29604@char.us.oracle.com>
Date:	Fri, 8 Jul 2016 11:54:46 -0400
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	David Vrabel <david.vrabel@...rix.com>
Cc:	Jan Beulich <JBeulich@...e.com>, boris.ostrovsky@...cle.com,
	Juergen Gross <JGross@...e.com>,
	xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org
Subject: Re: [Xen-devel] [PATCH v2 0/4] xen: prefer xenbus_scanf() over
 xenbus_gather()

On Fri, Jul 08, 2016 at 04:41:20PM +0100, David Vrabel wrote:
> On 08/07/16 15:17, Konrad Rzeszutek Wilk wrote:
> > On Fri, Jul 08, 2016 at 06:21:52AM -0600, Jan Beulich wrote:
> >> For single items being collected this should be preferred as being more
> >> typesafe (as the compiler can check format string and to-be-written-to
> >> variable match) and more efficient (requiring one less parameter to be
> >> passed).
> >>
> >> 1: xenbus: prefer xenbus_scanf() over xenbus_gather()
> >> 2: xen-blkback: prefer xenbus_scanf() over xenbus_gather()
> >> 3: xen-blkfront: prefer xenbus_scanf() over xenbus_gather()
> >> 4: xen-netback: prefer xenbus_scanf() over xenbus_gather()
> >>
> >> Signed-off-by: Jan Beulich <jbeulich@...e.com>
> >> ---
> >> v2: Avoid commit messages to continue from subjects. Group into a series.
> > 
> > To confuse this, Roger and I are the block sub-maintainers, which
> > when we are happy, I send to Jens, while the rest go through Boris,David, and Juergen.
> > 
> > Anyhow, I've already committed and tested for regressions these:
> > 79ef83a xen-blkback: constify instance of "struct attribute_group"
> > 5e4d659 xen-blkfront: prefer xenbus_scanf() over xenbus_gather()
> > e9d1ebe xen-blkback: prefer xenbus_scanf() over xenbus_gather()
> > 5b3b1db xen-blkback: really don't leak mode property
> 
> If they're tree wide largely mechanical changes to Xen-related APIs I
> prefer that they go via the Xen tree all together.
> 
> This saves the submitter chasing the individual subsystem maintainers.

Sure, but from a stricly SubmittingPatches point of view it would
fall on your to get the Acks from the other maintainers.

Either way, I am OK with those blkback and blkfront going through
your tree, albeit one will conflict with Jens 'for-4.8/drivers'.

> 
> David