linux-kernel - Re: [ANNOUNCE] 4.4.229-rt200

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: <20200709093151.o6ea5lqc753pxdr7@linutronix.de>
Date:   Thu, 9 Jul 2020 11:31:51 +0200
From:   Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:     Daniel Wagner <dwagner@...e.de>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        linux-rt-users <linux-rt-users@...r.kernel.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Carsten Emde <C.Emde@...dl.org>,
        John Kacur <jkacur@...hat.com>,
        Tom Zanussi <tom.zanussi@...ux.intel.com>,
        Clark Williams <williams@...hat.com>,
        Pavel Machek <pavel@...x.de>
Subject: Re: [ANNOUNCE] 4.4.229-rt200

On 2020-07-08 18:44:02 [-0000], Daniel Wagner wrote:
> I'm pleased to announce the 4.4.229-rt200 stable release.
> 
> This release is just an update to the new stable 4.4.215 version.

Your template is off here.

> Note: This update required dealing with a conflict in net/core/dev.c, where
> devnet_rename_seq was moved from a seqence count to an RWSEM and renamed
> to devnet_rename_sem. If you encounter runtime issues that show tracebacks
> in net/core/dev.c, please let me know.
>
> Patch "net: Add a mutex around devnet_rename_seq" dropped in favour of
> 602c47fbf46b ("net: core: device_rename: Use rwsem instead of a seqcount")

Yes, this was the intention of the exercise :)
 
> Known issues:
> 
>   sigwaittest with hackbench as workload is able to trigger a crash on x86_64,
>   the same as reported for the v4.4.220-rt196 release. The crash seems to
>   be triggered by a BPF program. IIRC, BPF was never supported in v4.4-rt
>   and I just forgot to disable in my configuration.

In v5.4.3-rt1 there is
    fe18e9e08e25d ("BPF: Disable on PREEMPT_RT")

so maybe backport this across the stable kernels. Fixing it is a way
larger queue. If the intention is to keep it disabled it could be
enforced via Kconfig so it is not enabled by accident (or by using
oldconfig on a distro config which has it enabled).

> Enjoy!
> Daniel

Sebastian