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]
Message-ID: <20171208103931.GG628@jagdpanzerIV>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ