linux-kernel - RE: [PATCH] fs.h: introduce functions to get/set file->private

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:	Wed, 18 Aug 2010 11:48:37 -0500
From:	H Hartley Sweeten <hartleys@...ionengravers.com>
To:	Joe Perches <joe@...ches.com>, Sam Ravnborg <sam@...nborg.org>
CC:	Christoph Hellwig <hch@...radead.org>, Ted Ts'o <tytso@....edu>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	"matthew@....cx" <matthew@....cx>
Subject: RE: [PATCH] fs.h: introduce functions to get/set file->private_data

On Tuesday, August 17, 2010 6:32 PM, Joe Perches wrote:
> On Tue, 2010-08-17 at 19:58 +0200, Sam Ravnborg wrote:
>> It takes minimum effort to create and test, and if you can
>> get ack from Ted and/or Christoph there is a good chance Linus
>> would take it right before/after -rc1.
>> 
>> You obviously need to convince him that the patch has
>> seen decent build testing.
>
> private_data is the only non f_ prefixed member in
> struct file, so while there is perhaps a tiny value
> in this patch, I'm not in a hurry to push it.
>
> After a few corrections, Documentation/, comment and
> printk updates, a few macros that spatch didn't update,
> etc, the diff that converts struct file member
> private_data to f_private_data is now:
>
> $ git diff --shortstat ..da5cabf80e2433131bf0ed8993abc0f7ea618c73
>  511 files changed, 2638 insertions(+), 2639 deletions(-)
>
> Does either Ted or Christoph want to see it?
>
> Harley?  You want it?

Uh... No... ;-)

> It's still ~850BKB and probably shouldn't be posted to
> the ML as it's mostly mechanical.

I would like to see it merged just to ease grepping but if no one else
sees any benefit doing it I can live with it.

FWIW, the only reason for bringing this up in the first place was I was
trying to find all the places that have unnecessary casts when using
the private_data.  Stuff like:

	struct my_struct *my_data = (struct my_struct *)file->private_data;

Maybe it would be simpler to use spatch to just fix those?

> Compiles x86 allyesconfig, defconfig

Regards,
Hartley