Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 26 Jun 2023 12:48:31 +0200
From:   Peter Zijlstra <peterz@infradead.org>
To:     Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc:     Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
        linux-mm@kvack.org, linux-kernel@vger.kernel.org,
        "Luis Claudio R. Goncalves" <lgoncalv@redhat.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Boqun Feng <boqun.feng@gmail.com>,
        Ingo Molnar <mingo@redhat.com>,
        John Ogness <john.ogness@linutronix.de>,
        Mel Gorman <mgorman@techsingularity.net>,
        Michal Hocko <mhocko@suse.com>, Petr Mladek <pmladek@suse.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Waiman Long <longman@redhat.com>, Will Deacon <will@kernel.org>
Subject: Re: [PATCH v2 1/2] seqlock: Do the lockdep annotation before locking
 in do_write_seqcount_begin_nested()
Message-ID: <20230626104831.GT4253@hirez.programming.kicks-ass.net>
References: <20230623171232.892937-1-bigeasy@linutronix.de>
 <20230623171232.892937-2-bigeasy@linutronix.de>
 <d9b7c170-ed0d-5d37-e099-20d233115943@I-love.SAKURA.ne.jp>
 <20230626081254.XmorFrhs@linutronix.de>
 <0a0c768c-227d-c0cd-1b91-5a884d161c1b@I-love.SAKURA.ne.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0a0c768c-227d-c0cd-1b91-5a884d161c1b@I-love.SAKURA.ne.jp>
Precedence: bulk

On Mon, Jun 26, 2023 at 06:25:56PM +0900, Tetsuo Handa wrote:
> On 2023/06/26 17:12, Sebastian Andrzej Siewior wrote:
> > On 2023-06-24 15:54:12 [+0900], Tetsuo Handa wrote:
> >> Why not to do the same on the end side?
> >>
> >>  static inline void do_write_seqcount_end(seqcount_t *s)
> >>  {
> >> - 	seqcount_release(&s->dep_map, _RET_IP_);
> >>  	do_raw_write_seqcount_end(s);
> >> +	seqcount_release(&s->dep_map, _RET_IP_);
> >>  }
> > 
> > I don't have a compelling argument for doing it. It is probably better
> > to release the lock from lockdep's point of view and then really release
> > it (so it can't be acquired before it is released).
> 
> We must do it because this is a source of possible printk() deadlock.
> Otherwise, I will nack on PATCH 2/2.

Don't be like that... just hate on prink like the rest of us. In fact,
i've been patching out the actual printk code for years because its
unusable garbage.

Will this actually still be a problem once all the fancy printk stuff
lands? That shouldn't do synchronous prints except to 'atomic' consoles
by default IIRC.