mbox series

[00/58] networking: Convert timers to use timer_setup()

Message ID 1508200182-104605-1-git-send-email-keescook@chromium.org
Headers show
Series networking: Convert timers to use timer_setup() | expand

Message

Kees Cook Oct. 17, 2017, 12:28 a.m. UTC
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.

Thanks,

-Kees

Comments

Kalle Valo Oct. 17, 2017, 2:18 p.m. UTC | #1
+ linux-wireless

Hi Kees,

Kees Cook <keescook@chromium.org> writes:

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

So this also includes patches which I had queued for
wireless-drivers-next:

https://patchwork.kernel.org/patch/9986253/
https://patchwork.kernel.org/patch/9986245/

And looking at patchwork[1] I have even more timer_setup() related
patches from you. It would be really helpful if you could clearly
document to which tree you want the patches to be applied. I don't care
if it's net-next or wireless-drivers-next as long as it's not the both
(meaning that both Dave and me apply the same patch, which would be
bad). The thing is that I really do not have time to figure out for
every patch via which tree it's supposed to go.

For now I'll just drop all your timer_setup() related patches from my
queue and I'll assume Dave will take those. Ok?

[1] https://patchwork.kernel.org/project/linux-wireless/list/
Kees Cook Oct. 17, 2017, 7:47 p.m. UTC | #2
On Tue, Oct 17, 2017 at 7:18 AM, Kalle Valo <kvalo@codeaurora.org> wrote:
> + linux-wireless
>
> Hi Kees,
>
> Kees Cook <keescook@chromium.org> writes:
>
>> 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.
>
> So this also includes patches which I had queued for
> wireless-drivers-next:
>
> https://patchwork.kernel.org/patch/9986253/
> https://patchwork.kernel.org/patch/9986245/
>
> And looking at patchwork[1] I have even more timer_setup() related
> patches from you. It would be really helpful if you could clearly
> document to which tree you want the patches to be applied. I don't care

Hi! Sorry about that. It's been a bit tricky to juggle everything.

> if it's net-next or wireless-drivers-next as long as it's not the both
> (meaning that both Dave and me apply the same patch, which would be
> bad). The thing is that I really do not have time to figure out for
> every patch via which tree it's supposed to go.

Which split is preferred? I had been trying to separate wireless from
the rest of net (but missed some cases).

> For now I'll just drop all your timer_setup() related patches from my
> queue and I'll assume Dave will take those. Ok?
>
> [1] https://patchwork.kernel.org/project/linux-wireless/list/

I guess I'll wait to see what Dave says.

Thanks!

-Kees
Kalle Valo Oct. 18, 2017, 5:44 a.m. UTC | #3
Kees Cook <keescook@chromium.org> writes:

> On Tue, Oct 17, 2017 at 7:18 AM, Kalle Valo <kvalo@codeaurora.org> wrote:
>> + linux-wireless
>>
>> Hi Kees,
>>
>> Kees Cook <keescook@chromium.org> writes:
>>
>>> 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.
>>
>> So this also includes patches which I had queued for
>> wireless-drivers-next:
>>
>> https://patchwork.kernel.org/patch/9986253/
>> https://patchwork.kernel.org/patch/9986245/
>>
>> And looking at patchwork[1] I have even more timer_setup() related
>> patches from you. It would be really helpful if you could clearly
>> document to which tree you want the patches to be applied. I don't care
>
> Hi! Sorry about that. It's been a bit tricky to juggle everything.

Yeah, I understand.

>> if it's net-next or wireless-drivers-next as long as it's not the both
>> (meaning that both Dave and me apply the same patch, which would be
>> bad). The thing is that I really do not have time to figure out for
>> every patch via which tree it's supposed to go.
>
> Which split is preferred? I had been trying to separate wireless from
> the rest of net (but missed some cases).

So what we try to follow is that I apply all patches for
drivers/net/wireless to my wireless-drivers trees, with exception of
Johannes taking mac80211_hwsim.c patches to his mac80211 trees. And
Johannes of course takes all patches for net/wireless and net/mac80211.

So in general I prefer that I take all drivers/net/wireless patches and
make it obvious for Dave that he can ignore those patches (not mix
wireless-drivers and net patches into same set etc). But like I said,
it's ok to push API changes like these via Dave's net trees as well if
you want (and if Dave is ok with that). The chances of conflicts is low,
and if there are be any those would be easy to fix either by me or Dave.

>> For now I'll just drop all your timer_setup() related patches from my
>> queue and I'll assume Dave will take those. Ok?
>>
>> [1] https://patchwork.kernel.org/project/linux-wireless/list/
>
> I guess I'll wait to see what Dave says.

Ok, I don't drop the patches from my queue quite yet then.
David Miller Oct. 18, 2017, 11:42 a.m. UTC | #4
From: Kees Cook <keescook@chromium.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

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

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

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.

Thanks.
Kees Cook Oct. 18, 2017, 7:42 p.m. UTC | #5
On Wed, Oct 18, 2017 at 4:42 AM, David Miller <davem@davemloft.net> wrote:
> From: Kees Cook <keescook@chromium.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 Oct. 18, 2017, 7:45 p.m. UTC | #6
On Tue, Oct 17, 2017 at 10:44 PM, Kalle Valo <kvalo@codeaurora.org> wrote:
> Kees Cook <keescook@chromium.org> writes:
>> Which split is preferred? I had been trying to separate wireless from
>> the rest of net (but missed some cases).
>
> So what we try to follow is that I apply all patches for
> drivers/net/wireless to my wireless-drivers trees, with exception of
> Johannes taking mac80211_hwsim.c patches to his mac80211 trees. And
> Johannes of course takes all patches for net/wireless and net/mac80211.
>
> So in general I prefer that I take all drivers/net/wireless patches and
> make it obvious for Dave that he can ignore those patches (not mix
> wireless-drivers and net patches into same set etc). But like I said,
> it's ok to push API changes like these via Dave's net trees as well if
> you want (and if Dave is ok with that). The chances of conflicts is low,
> and if there are be any those would be easy to fix either by me or Dave.

Okay, great. That'll help. I'll wait for the dust to settle and rebase
against -next, and then I'll see what's outstanding and double-check
where they need to be sent (and I'll queue new conversions up
accordingly too).

>>> For now I'll just drop all your timer_setup() related patches from my
>>> queue and I'll assume Dave will take those. Ok?
>>>
>>> [1] https://patchwork.kernel.org/project/linux-wireless/list/
>>
>> I guess I'll wait to see what Dave says.
>
> Ok, I don't drop the patches from my queue quite yet then.

Alright, thanks very much!

-Kees