From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linuxfoundation.org ([140.211.169.12]:35556 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750962AbeCSHh3 (ORCPT ); Mon, 19 Mar 2018 03:37:29 -0400 Date: Mon, 19 Mar 2018 08:37:28 +0100 From: Greg KH To: Ard Biesheuvel Cc: stable Subject: Re: [PATCH] irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis Message-ID: <20180319073728.GC4530@kroah.com> References: <20180319072726.4273-1-ard.biesheuvel@linaro.org> <20180319073707.GB4530@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180319073707.GB4530@kroah.com> Sender: stable-owner@vger.kernel.org List-ID: On Mon, Mar 19, 2018 at 08:37:07AM +0100, Greg KH wrote: > On Mon, Mar 19, 2018 at 03:28:40PM +0800, Ard Biesheuvel wrote: > > On 19 March 2018 at 15:27, Ard Biesheuvel wrote: > > > Commit 4f2c7583e33e upstream. > > > > > > When struct its_device instances are created, the nr_ites member > > > will be set to a power of 2 that equals or exceeds the requested > > > number of MSIs passed to the msi_prepare() callback. At the same > > > time, the LPI map is allocated to be some multiple of 32 in size, > > > where the allocated size may be less than the requested size > > > depending on whether a contiguous range of sufficient size is > > > available in the global LPI bitmap. > > > > > > This may result in the situation where the nr_ites < nr_lpis, and > > > since nr_ites is what we program into the hardware when we map the > > > device, the additional LPIs will be non-functional. > > > > > > For bog standard hardware, this does not really matter. However, > > > in cases where ITS device IDs are shared between different PCIe > > > devices, we may end up allocating these additional LPIs without > > > taking into account that they don't actually work. > > > > > > So let's make nr_ites at least 32. This ensures that all allocated > > > LPIs are 'live', and that its_alloc_device_irq() will fail when > > > attempts are made to allocate MSIs beyond what was allocated in > > > the first place. > > > > > > Signed-off-by: Ard Biesheuvel > > > [maz: updated comment] > > > Signed-off-by: Marc Zyngier > > > [ardb: trivial tweak of unrelated context] > > > Signed-off-by: Ard Biesheuvel > > > --- > > > > Please apply to v4.9 > > What about 4.14.y and 4.15.y? Why only add it to one really old tree, > you don't want people updating to a newer kernel and have a regression, > right? Ah, now I see your other email, sorry, nevermind...