linux-kernel - Re: [PATCH 04/40] staging/lustre/llite: Access to released file trigs a restore

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, 15 Nov 2013 13:09:44 +0900
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Peng Tao <bergwolf@...il.com>
Cc:	linux-kernel@...r.kernel.org,
	JC Lafoucriere <jacques-charles.lafoucriere@....fr>,
	Andreas Dilger <andreas.dilger@...el.com>
Subject: Re: [PATCH 04/40] staging/lustre/llite: Access to released file
 trigs a restore

On Fri, Nov 15, 2013 at 12:13:06AM +0800, Peng Tao wrote:
> From: JC Lafoucriere <jacques-charles.lafoucriere@....fr>
> 
> When a client accesses data in a released file,
> or truncate it, client must trig a restore request.
> During this restore, the client must not glimpse and
> must use size from MDT. To bring the "restore is running"
> information on the client we add a new t_state bit field
> to mdt_info which will be used to carry transient file state.
> To memorise this information in the inode we add a new flag
> LLIF_FILE_RESTORING.

This patch also does other things not mentioned here (coding style
cleanups), which isn't allowed in a single patch (only do one thing per
patch, and never not document what you are doing...)

It also adds checkpatch warnings, which I will not accept in patches at
all here.  People are spending a lot of time cleaning up the coding
style issues, please NEVER add new ones, that just causes more work to
be needed to be done, and for people to have to go back and reclean
files they have already cleaned up.

So, sorry, I have to stop here at this series.  I've applied the first 3
to the opw-next branch of staging.git so they can live somewhere until
3.13-rc1 is out.

I know you spent a lot of time making these 120 patches to send me, but
that too is crazy.  You shouldn't wait that long to get feedback and
send patches to me at all.  Please send them in smaller series, with
less time between patch submissions.

So, care to just send me 10 patches or so now, which I can review and
accept if good, and we can sync up and continue from there?

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/