Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Thomas Gleixner <tglx@linutronix.de>
To:     "J. Bruce Fields" <bfields@fieldses.org>
Cc:     Christian Brauner <christian.brauner@ubuntu.com>,
        Michael =?utf-8?Q?We?= =?utf-8?Q?i=C3=9F?= 
        <michael.weiss@aisec.fraunhofer.de>,
        Andrei Vagin <avagin@gmail.com>,
        Dmitry Safonov <0x7f454c46@gmail.com>,
        linux-kernel@vger.kernel.org, Chuck Lever <chuck.lever@oracle.com>,
        Trond Myklebust <trond.myklebust@hammerspace.com>,
        Anna Schumaker <anna.schumaker@netapp.com>,
        Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH v2 2/4] time: make getboottime64 aware of time namespace
In-Reply-To: <20201012211308.GH26571@fieldses.org>
References: <20201008053944.32718-1-michael.weiss@aisec.fraunhofer.de> <20201008053944.32718-3-michael.weiss@aisec.fraunhofer.de> <20201009132815.5afulu5poh5ti57m@wittgenstein> <20201009135554.GE15719@fieldses.org> <878scfrwls.fsf@nanos.tec.linutronix.de> <20201012211308.GH26571@fieldses.org>
Date:   Mon, 12 Oct 2020 23:36:34 +0200
Message-ID: <87h7qzp1nh.fsf@nanos.tec.linutronix.de>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

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