linux-kernel - Re: [PATCH 00/58] networking: Convert timers to use timer

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 Oct 2017 12:42:16 -0700
From:   Kees Cook <keescook@...omium.org>
To:     David Miller <davem@...emloft.net>
Cc:     Network Development <netdev@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 00/58] networking: Convert timers to use timer_setup()

On Wed, Oct 18, 2017 at 4:42 AM, David Miller <davem@...emloft.net> wrote:
> From: Kees Cook <keescook@...omium.org>
> Date: Mon, 16 Oct 2017 17:28:44 -0700
>
>> This is the current set of outstanding networking patches to perform
>> conversions to the new timer interface (rebased to -next). This is not
>> all expected conversions, but it contains everything needed in networking
>> to eliminate init_timer(), and all the non-standard setup_*_timer() uses.
>
> I've applied this except:
>
> 1) the IRDA stuff, it's staging and needs to go via Greg KH

Ah yes, thanks. I didn't update the Subject when I followed the path
change into staging. I'll redirect this to Greg.

> 2) the MPC ATM didn't apply at all to net-next

Okay, I will respin it again and collect more conversions before
sending the next batch.

> Such a huge patch series like this is a huge burdon upon
> a subsystem maintainer.

Agreed, and I'm very thankful you've made time to dig through this
pile. I've tried to minimize the number of separate patches, since
many cases can be mechanically updated with Coccinelle (which we'll do
at the tail end of this conversion).

> Split this kind of stuff up into manageable chunks next time,
> maybe a dozen patches at a time.  Do not submit multiple
> series at once to get around this size limit.  Submit one
> at a time, wait for it to get applied, and then after that
> you can submit the next one.

Okay, I'll limit postings to a dozen. I think I'll need to maintain
separate trees for each subsystem's batches. I've been splitting them
up manually out of one single giant tree, which has been ... insane.

Thanks again!

-Kees

-- 
Kees Cook
Pixel Security