linux-kernel - Re: [GIT PULL] KVM changes for Linux 6.14

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: <CAHk-=who0D=MKDijLTAtVZ=x8RMSQZg4reHiprgQKxDHsTGeUQ@mail.gmail.com>
Date: Wed, 5 Feb 2025 08:12:42 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Christian Brauner <brauner@...nel.org>
Cc: Paolo Bonzini <pbonzini@...hat.com>, Oleg Nesterov <oleg@...hat.com>, 
	"Michael S. Tsirkin" <mst@...hat.com>, "Eric W. Biederman" <ebiederm@...ssion.com>, linux-kernel@...r.kernel.org, 
	kvm@...r.kernel.org
Subject: Re: [GIT PULL] KVM changes for Linux 6.14

On Wed, 5 Feb 2025 at 03:49, Christian Brauner <brauner@...nel.org> wrote:
>
>
> Btw, checking whether single-threaded this can be simplified.
> It should be sufficient to do:
>
> stat("/proc/self/task", &st);
> if ((st->st_nlink - 2) == 1)
>         // single threaded
>
> since procfs adds the number of tasks to st_nlink

I'd be careful about depending on st_nlink on strange filesystems,
particularly for directories. And /proc is stranger than most.

So the above may happen to work, but I'm not convinced it always has
had that st_nlink thing. We do it because some tools do end up looking
at n_link to prune recursive directory traversal.

But *most* such tools also know that st_nlink < 2 is special and might
mean "don't know" (because not all filesystems actually count
directory links the way traditional Unix filesystems do).

So relying on /proc acting "normal" seems fragile.

              Linus