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:   Sun, 2 Oct 2022 17:30:20 +0200
From:   Greg KH <gregkh@linuxfoundation.org>
To:     Rishabh Bhatnagar <risbhat@amazon.com>
Cc:     stable@vger.kernel.org, sashal@kernel.org, tglx@linutronix.de,
        mingo@redhat.com, linux-kernel@vger.kernel.org, benh@amazon.com,
        mbacco@amazon.com
Subject: Re: [PATCH 0/6] IRQ handling patches backport to 4.14 stable
Message-ID: <YzmujBxtwUxHexem@kroah.com>
References: <20220929210651.12308-1-risbhat@amazon.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220929210651.12308-1-risbhat@amazon.com>
Precedence: bulk

On Thu, Sep 29, 2022 at 09:06:45PM +0000, Rishabh Bhatnagar wrote:
> This patch series backports a bunch of patches related IRQ handling
> with respect to freeing the irq line while IRQ is in flight at CPU
> or at the hardware level.
> Recently we saw this issue in serial 8250 driver where the IRQ was being
> freed while the irq was in flight or not yet delivered to the CPU. As a
> result the irqchip was going into a wedged state and IRQ was not getting
> delivered to the cpu. These patches helped fixed the issue in 4.14
> kernel.

Why is the serial driver freeing an irq while the system is running?
Ah, this could happen on a tty hangup, right?

> Let us know if more patches need backporting.

What hardware platform were these patches tested on to verify they work
properly?  And why can't they move to 4.19 or newer if they really need
this fix?  What's preventing that?

As Amazon doesn't seem to be testing 4.14.y -rc releases, I find it odd
that you all did this backport.  Is this a kernel that you all care
about?

thanks,

greg k-h