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;
From:   John Ogness <john.ogness@linutronix.de>
To:     "Jiri Slaby (SUSE)" <jirislaby@kernel.org>,
        gregkh@linuxfoundation.org
Cc:     linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
        "Jiri Slaby (SUSE)" <jirislaby@kernel.org>,
        Vlastimil Babka <vbabka@suse.cz>,
        Thomas Gleixner <tglx@linutronix.de>,
        Petr Mladek <pmladek@suse.com>
Subject: Re: [PATCH] serial: 8250: drop lockdep annotation from
 serial8250_clear_IER()
In-Reply-To: <20230811064340.13400-1-jirislaby@kernel.org>
References: <20230811064340.13400-1-jirislaby@kernel.org>
Date:   Mon, 14 Aug 2023 08:21:32 +0206
Message-ID: <878rae175n.fsf@jogness.linutronix.de>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

On 2023-08-11, "Jiri Slaby (SUSE)" <jirislaby@kernel.org> wrote:
> The port lock is not always held when calling serial8250_clear_IER().
> When an oops is in progress, the lock is tried to be taken and when it
> is not, a warning is issued:

Yes, and that is a potential deadlock. The warning is correct.

> Therefore, remove the annotation as it doesn't hold for all invocations.

... because those invocations are broken by design.

> The other option would be to make the lockdep test conditional on
> 'oops_in_progress' or pass 'locked' from serial8250_console_write(). I
> don't think, that is worth it.

The proper thing to do is to fix the invocation. The upcoming atomic
console implementation for the 8250 does exactly that.

If this patch gets accepted (which it appears it will be), I will revert
it in my series implementing the 8250 atomic console.

John Ogness