linux-kernel - Re: [stable] [2.6.24 PATCH 02/25] dm io:ctl use constant struct size

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: <20071113222242.GB6132@kroah.com>
Date:	Tue, 13 Nov 2007 14:22:42 -0800
From:	Greg KH <greg@...ah.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	dm-devel@...hat.com, linux-kernel@...r.kernel.org,
	Milan Broz <mbroz@...hat.com>,
	Guido Guenther <agx@...xcpu.org>,
	Kevin Corry <kevcorry@...ibm.com>, stable@...nel.org
Subject: Re: [stable] [2.6.24 PATCH 02/25] dm io:ctl use constant struct
	size

On Mon, Oct 15, 2007 at 09:34:09AM +0200, Arnd Bergmann wrote:
> On Monday 15 October 2007, Alasdair G Kergon wrote:
> > The underlying ABI is not changing, I hope - the trailing padding in the
> > struct should not affect the processing of the data by dm, and I see no
> > reason to continue maintaining the fiction that the 32-bit and 64-bit
> > ioctls are in some way incompatible with each other when they aren't
> > AFAIK.
> 
> It's a corner case of some sort, as DM uses ioctl numbers differently
> from most subsystems by splitting to code from the size argument
> during processing. Your change is certainly not an _incompatible_
> change to the ABI, but 32 bit binaries compiled against the new
> headers will use different ioctl numbers from those built against
> older headers.
> 
> This may break other code that expects a specific number, even
> if your handler does not care. The old compat code handles both
> variants (no variable size arguments), but /usr/bin/strace may have
> encoded only one set of numbers AFAICT.
> 
> > And yes, a follow-up patch can clean up our use of the compatibility
> > mechanism, going a little bit further than the patch you attached, I
> > hope.
> 
> Ok, sounds good. I don't think it's the kind of patch that should go
> into stable backports though.

Ok, I've not added this patch (2/25) to the queue at all.  If this is
incorrect, please let me know.

thanks,

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/