linux-kernel - Re: [PATCH V4 00/12] blktrace: output cgroup info

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: <c6fb1aba-f836-bac1-bd7c-572b1bcb1ae8@kernel.dk>
Date:   Wed, 28 Jun 2017 14:57:38 -0600
From:   Jens Axboe <axboe@...nel.dk>
To:     Tejun Heo <tj@...nel.org>, Jens Axboe <axboe@...nel.dk>,
        gregkh@...uxfoundation.org
Cc:     Shaohua Li <shli@...nel.org>, linux-kernel@...r.kernel.org,
        linux-block@...r.kernel.org, hch@....de, rostedt@...dmis.org,
        lizefan@...wei.com, Kernel-team@...com, Shaohua Li <shli@...com>
Subject: Re: [PATCH V4 00/12] blktrace: output cgroup info

On 06/28/2017 12:11 PM, Tejun Heo wrote:
> Hello,
> 
> On Wed, Jun 28, 2017 at 10:54:28AM -0600, Jens Axboe wrote:
>>>> Series looks fine to me. I don't know how you want to split or funnel it,
>>>> since it touches multiple different parts. Would it make sense to split this
>>>> series into two - one for the kernfs changes, and then a subsequent block
>>>> series that depend on that?
>>>
>>> What's the best practice to do this without building errors? Ask Tejun
>>> to merge the first 7 patches first?
>>
>> Yes, and then resend the block patches, just noting that dependency. Then
>> we can funnel them in like that.
> 
> I wonder whether it'd be a lot easier to route the whole series
> through one tree, most likely block.  Greg, would that be okay with
> you?  Alternatively, we can route the whole thing through driver tree
> if Jens is okay with that.

Personally I don't care that much, but the risk of conflicts is much
higher on the block side, than on the kernfs side. So might be the
path of less resistance to pull it through the block tree. And I'd be
happy to do that, if the sign offs on the kernfs side are sufficient.

-- 
Jens Axboe