linux-kernel - Re: [PATCH] sched/autogroup: move sched.h include

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:   Fri, 8 Dec 2017 19:39:31 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:     Petr Mladek <pmladek@...e.com>
Cc:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Martin Schwidefsky <schwidefsky@...ibm.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        LKML <linux-kernel@...r.kernel.org>, linux-pm@...r.kernel.org,
        linux-pci@...r.kernel.org, linux-mm@...ck.org,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Subject: Re: [PATCH] sched/autogroup: move sched.h include

Hi,

On (12/08/17 09:57), Petr Mladek wrote:
> On Fri 2017-12-08 17:24:22, Sergey Senozhatsky wrote:
> > Move local "sched.h" include to the bottom. sched.h defines
> > several macros that are getting redefined in ARCH-specific
> > code, for instance, finish_arch_post_lock_switch() and
> > prepare_arch_switch(), so we need ARCH-specific definitions
> > to come in first.
> 
> This patch is needed to fix compilation error [1] caused by a patchset
> that deprecates %pf/%pF printk modifiers[2].
> 
> IMHO, we should make sure that this fix goes into Linus' tree
> before the printk-related patchset. What is the best practice,
> please?

as long as sched pull request goes before printk pull request we
are fine. but I see your point.

> I see two reasonable possibilities. Either sched people could
> push this for-4.15-rcX. Or I could put it into printk.git for-4.16
> in the right order.

agreed.

> What do you think?

either way is fine with me. we can have it in print.git (no objections
from my side) or in sched tree and just make sure that sched pull request
has "bigger priority", or it can go to Linus's tree as a potential fix
(I'd prefer the last option, I think).

	-ss