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] [day] [month] [year] [list]
Message-ID: <YjS0n6OetpxNGiDL@bombadil.infradead.org>
Date:   Fri, 18 Mar 2022 09:34:39 -0700
From:   Luis Chamberlain <mcgrof@...nel.org>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     Baisong Zhong <zhongbaisong@...wei.com>,
        Zhen Ni <nizhen@...ontech.com>,
        Stephen Rothwell <sfr@...b.auug.org.au>, mingo@...hat.com,
        peterz@...radead.org, juri.lelli@...hat.com,
        vincent.guittot@...aro.org, dietmar.eggemann@....com,
        rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de,
        bristot@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH -next] sched/rt: fix build error when CONFIG_SYSCTL is
 disable

On Fri, Mar 18, 2022 at 08:50:50AM +0100, Ingo Molnar wrote:
> 
> I believe these build errors are caused by new commits in the sysctl-next 
> tree that change scheduler code:
> 
>   4925401d06dc sched: Move rr_timeslice sysctls to rt.c
>   5f6e55c2485c sched: Move rt_period/runtime sysctls to rt.c
> 
> In particular I don't see any Cc: to scheduler folks in these two commits - 
> and I'd have preferred to pick these up into the scheduler tree, to avoid 
> the merge conflicts and the build failure regressions...

Sorry about that, Peter was Cc'd on the patches and he did provide
feedback on the first set. During that review I also had suggested that
since it seemed that during the new kernel development cycle the next
target was sched for sysctl moves out of kernel/sysctl.c *but* that since
Andrew had merged these during the last kernel release I had suggested
to Peter that perhaps these should just go through his tree [0]. No
was no replies to that thread.

I had provided feedack for Zhen Ni's 2nd series of his patches and I
also had suggested for him to use 0day to avoid build issues. By his
3rd spin it was already on my radar that more syctls changes were being
posted outside of sched and so I asked for feedback from Andrew / Peter
about using instead a dedicated tree to collect sysctl changes to avoid
possible merge conflicts [1]. The only replies came from Andrew agreeing
to a syctl-next tree to help to avoid merge conflicts [2]. By v3 then,
through feedback by Andrew and no replies by Peter I decided to take this
via sysctl-next and let these get baked / tested through linux-next and
0day.

Let me know if you'd like me to drop these patches and rebase my tree,
or if you'd like to proceed some other way.

[0] https://lkml.kernel.org/r/YgaprpOvUYlrNvdH@bombadil.infradead.org               
[1] https://lkml.kernel.org/r/Yg3+bAQKVX+Dj317@bombadil.infradead.org               
[2] https://lkml.kernel.org/r/Yg/jxFqiuyR/xB2s@bombadil.infradead.org               

  Luis

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ