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;
Date:   Tue, 8 Dec 2020 11:46:51 -0400
From:   Jason Gunthorpe <jgg@nvidia.com>
To:     "Ahmed S. Darwish" <a.darwish@linutronix.de>
CC:     Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        "Paul E. McKenney" <paulmck@kernel.org>,
        Steven Rostedt <rostedt@goodmis.org>,
        Jonathan Corbet <corbet@lwn.net>,
        John Hubbard <jhubbard@nvidia.com>,
        LKML <linux-kernel@vger.kernel.org>,
        "Sebastian A. Siewior" <bigeasy@linutronix.de>
Subject: Re: [PATCH -tip v1 3/3] seqlock: kernel-doc: Specify when preemption
 is automatically altered
Message-ID: <20201208154651.GN552508@nvidia.com>
References: <20201206162143.14387-1-a.darwish@linutronix.de>
 <20201206162143.14387-4-a.darwish@linutronix.de>
 <20201207204316.GF552508@nvidia.com> <X8+OS/K0+9ibIEGz@lx-t490>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <X8+OS/K0+9ibIEGz@lx-t490>
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from mlx.ziepe.ca (142.162.115.133) by MN2PR12CA0018.namprd12.prod.outlook.com (2603:10b6:208:a8::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12 via Frontend Transport; Tue, 8 Dec 2020 15:46:52 +0000
Received: from jgg by mlx with local (Exim 4.94)        (envelope-from <jgg@nvidia.com>)        id 1kmfCV-007wQJ-3Z; Tue, 08 Dec 2020 11:46:51 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1;
        t=1607442414; bh=kB0E+4KI/ryyAooQ9G7OLFeq1gC6efMUMVPhm6bzZwY=;
        h=ARC-Seal:ARC-Message-Signature:ARC-Authentication-Results:Date:
         From:To:CC:Subject:Message-ID:References:Content-Type:
         Content-Disposition:In-Reply-To:X-ClientProxiedBy:MIME-Version:
         X-MS-Exchange-MessageSentRepresentingType;
        b=C0DZmHS39Ekkdw3HN0WbyxsTt47hiFUezl98OfKBnS5VOvLmPjzD2tbhUEuVVCHX6
         1jMAwBuegpiS13fM12PLxxTpVimewj1sk6q45EiTP/+lT86Co8Lt98aalEuIJfBPTA
         Dxwh8eYVWq7aJJM7pJ2sMY4Sgg7FyPdtJUT1wlv/EkkjDwNga7yzz1BZx0WwzTeZxL
         YjAtiJt/sMbRZPdYHF2DrKVEypV2JoVSp/E8rKkMPHU3G5pqrbrB8e2Gul4DO4Uucx
         2WBErXsdCYTalNyfv7bPcNevoC4VBA9CafjwpTbMpZozd11sefFkjHTh0QJWoJAGnW
         iNTtBDQmFpM9A==
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Dec 08, 2020 at 03:31:39PM +0100, Ahmed S. Darwish wrote:
> Hi Jason,
> 
> On Mon, Dec 07, 2020 at 04:43:16PM -0400, Jason Gunthorpe wrote:
> ...
> >
> > The thing that was confusing is if it was appropriate to use a
> > seqcount in case where write side preemption was not disabled - which
> > is safe only if the read side doesn't spin.
> >
> 
> No, that's not correct.

Well, that is where I started from.. seqcount in normal pre-emption
disabled cases was well understood, I needed a no-pre-emption disable
case.

> For developers who're advanced enough to know the difference, they don't
> need the kernel-doc anyway. And that's why I've kindly asked to add the
> following to your mm/ patch (which you did, thanks):

That is probably over stating things quite a lot. If there are valid
locking patterns then I think we should document them, otherwise
people simply do something crazy and get it wrong.

It was not entirely easy to figure out why preemption disable is
necessary here, though in hindsight it is obvious..

Jason