linux-kernel - Re: [PATCH v2 2/4] time: make getboottime64 aware of time namespace

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: <87h7qzp1nh.fsf@nanos.tec.linutronix.de>
Date:   Mon, 12 Oct 2020 23:36:34 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     "J. Bruce Fields" <bfields@...ldses.org>
Cc:     Christian Brauner <christian.brauner@...ntu.com>,
        Michael Weiß 
        <michael.weiss@...ec.fraunhofer.de>,
        Andrei Vagin <avagin@...il.com>,
        Dmitry Safonov <0x7f454c46@...il.com>,
        linux-kernel@...r.kernel.org, Chuck Lever <chuck.lever@...cle.com>,
        Trond Myklebust <trond.myklebust@...merspace.com>,
        Anna Schumaker <anna.schumaker@...app.com>,
        Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH v2 2/4] time: make getboottime64 aware of time namespace

On Mon, Oct 12 2020 at 17:13, J. Bruce Fields wrote:
> On Fri, Oct 09, 2020 at 10:08:15PM +0200, Thomas Gleixner wrote:
>> You wish. That's clearly wrong because that code is not guaranteed to
>> always run in a context which belongs to the root time namespace.
>
> Argh, right, thanks.
>
>> AFAICT, this stuff can run in softirq context which is context stealing
>> and the interrupted task can belong to a different time name space.
>
> Some of it runs in the context of a process doing IO to proc, some from
> kthreads.  So, anyway, yes, it's not consistent in the way we'd need.

Yes, that'll do it. If the process is in a time namespace then it's
definitely incorrect vs. the kthread which is in the root namespace.

>> You'd obviously need to fixup CACHE_NEW_EXPIRY and the other place which
>> add's '1' to the expiry value and some janitoring of function names and
>> variable types, but no real big surgery AFAICT.
>
> I'll give it a shot.
>
> Thanks so much for taking a careful look at this.

Welcome. I was just looking at the use case. The code and especially
Arnds comment were odd enogh to make me look deeper. Such constructs are
usually showing shortcomings of the core interfaces. Seventh sense which
I gained over the past decades. :)

Thanks,

        tglx