linux-kernel - [GIT PULL] fixes for v5.8-rc4

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-next>] [day] [month] [year] [list]

Message-Id: <20200702204732.1114343-1-christian.brauner@ubuntu.com>
Date:   Thu,  2 Jul 2020 22:47:33 +0200
From:   Christian Brauner <christian.brauner@...ntu.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: [GIT PULL] fixes for v5.8-rc4

Hey Linus,

/* Summary */
This contains an annotation patch for a data race in copy_process() reported by
KCSAN when reading and writing nr_threads. The data race is intentional and
benign. This is obvious from the comment above the relevant code and based on
general consensus when discussing this issue. So simply using data_race() to
annotate this as an intentional race seems the best option.

A few comments on this since doing a grep data_race() reveals that currently
only kernel/rcu/* is making use of this new annotation and this seems to be the
first annotation in core kernel: when this was first sent to me I was obviously
aware of the existence of KCSAN but not whether we had established a consenus
around annotating places in the (core) kernel where we currently have benign
data races that KCSAN complains about. I don't know whether we have reached a
consensus in general yet or we're just doing this subsystem specific. We had a
bit of a back and forth on this topic related to this patch here. Most people
argued that because this is an intentional and benign data race that we should
simply annotate it. Now, we're obviously doing this for the sake of KCSAN and
given that KCSAN is now upstream and starting to report data races I guess
doing this is sensible. The linux-next tree contains various mm/* patches that
push in the same direction of annotating benign data races. So it seems going
forward we'll just funnel such patches upstream where they make sense.

/* Testing */
All patches have seen exposure in linux-next and are based on v5.8-rc1.

/* Conflicts */
At the time of creating this pr no merge conflicts were reported.
Fyi, I applied this patch right on top of the previous fixes before -rc2 was
out and hence didn't rebase my fixes tree on top of -rc3 because of that.

The following changes since commit 86f56395feb2b106b125c47e72192e37da5dd088:

  tests: test for setns() EINVAL regression (2020-06-17 00:48:54 +0200)

are available in the Git repository at:

  git@...olite.kernel.org:pub/scm/linux/kernel/git/brauner/linux tags/for-linus-2020-07-02

for you to fetch changes up to c17d1a3a8ee4dac7539d5c976b45d9300f6f10bc:

  fork: annotate data race in copy_process() (2020-06-26 01:05:29 +0200)

Please consider pulling these changes from the signed for-linus-2020-07-02 tag.

Thanks!
Christian

----------------------------------------------------------------
for-linus-2020-07-02

----------------------------------------------------------------
Weilong Chen (1):
      fork: annotate data race in copy_process()

 kernel/fork.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)