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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+a=Yy7npJ0ZPgDm9EF+goD3LSV80u98CsnOctLhmLakB8NCKQ@mail.gmail.com>
Date:	Fri, 15 Nov 2013 17:55:34 +0800
From:	Peng Tao <bergwolf@...il.com>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	Linux Kernel Mailing List <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:09 PM, Greg Kroah-Hartman
<gregkh@...uxfoundation.org> wrote:
> 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...)
>
I ported the original patch with as least modification as possible.
Guess I need to split this one (and the alike) so that it follows
upstream patch rules.

> 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.
>
sorry... I will be more careful about this.

> 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.
>
Thanks!

> 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?
>
OK. I will split the patchsets into smaller ones. Thanks for reviewing!

Thanks,
Tao
--
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/