On Mon, Mar 19, 2018 at 03:47:27PM +0800, Ard Biesheuvel wrote: > On 19 March 2018 at 15:37, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > 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 <ard.biesheuvel@xxxxxxxxxx> 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 <ard.biesheuvel@xxxxxxxxxx> > >> > > [maz: updated comment] > >> > > Signed-off-by: Marc Zyngier <marc.zyngier@xxxxxxx> > >> > > [ardb: trivial tweak of unrelated context] > >> > > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> > >> > > --- > >> > > >> > 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... > > No worries. > > Actually, this version applies cleanly to v4.4 as well, so could you > please add it there as well? Now queued up everywhere, thanks. greg k-h