drivers/pci/pci.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
Commit cbc654d18d37 ("bitops: Add __attribute_const__ to generic
ffs()-family implementations") causes a compilation failure on ARM
footbridge_defconfig with gcc-8:
FIELD_PREP: value too large for the field
The error occurs in pcie_set_readrq() at:
v = FIELD_PREP(PCI_EXP_DEVCTL_READRQ, ffs(rq) - 8);
With __attribute_const__, gcc-8 now performs wrong compile-time
validation in FIELD_PREP and cannot guarantee that ffs(rq) - 8 will
always produce values that fit in the 3-bit PCI_EXP_DEVCTL_READRQ field.
Avoid FIELD_PREP entirely by using direct bit manipulation. Replace
FIELD_PREP(PCI_EXP_DEVCTL_READRQ, ffs(rq) - 8) with the equivalent
manual bit operations: ((ffs(rq) - 8) << 12) & PCI_EXP_DEVCTL_READRQ.
This bypasses the compile-time validation while maintaining identical
runtime behavior and functionality.
Fixes: cbc654d18d37 ("bitops: Add __attribute_const__ to generic ffs()-family implementations")
Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
Closes: https://lore.kernel.org/linux-pci/CA+G9fYuysVr6qT8bjF6f08WLyCJRG7aXAeSd2F7=zTaHHd7L+Q@mail.gmail.com/T/#u
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
---
drivers/pci/pci.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index e698278229f2..9f9607bd9f51 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -5893,7 +5893,8 @@ int pcie_set_readrq(struct pci_dev *dev, int rq)
rq = mps;
}
- v = FIELD_PREP(PCI_EXP_DEVCTL_READRQ, ffs(rq) - 8);
+ /* Ideally we would used FIELD_PREP() but this is a work around for gcc-8 */
+ v = ((ffs(rq) - 8) << 12) & PCI_EXP_DEVCTL_READRQ;
if (bridge->no_inc_mrrs) {
int max_mrrs = pcie_get_readrq(dev);
--
2.50.1
On Thu, 28 Aug 2025 12:12:37 +0200 Anders Roxell <anders.roxell@linaro.org> wrote: > Commit cbc654d18d37 ("bitops: Add __attribute_const__ to generic > ffs()-family implementations") causes a compilation failure on ARM > footbridge_defconfig with gcc-8: > > FIELD_PREP: value too large for the field > > The error occurs in pcie_set_readrq() at: > v = FIELD_PREP(PCI_EXP_DEVCTL_READRQ, ffs(rq) - 8); > > With __attribute_const__, gcc-8 now performs wrong compile-time > validation in FIELD_PREP and cannot guarantee that ffs(rq) - 8 will > always produce values that fit in the 3-bit PCI_EXP_DEVCTL_READRQ field. Which is actually quite correct - in principle pcie_get_mps() could return a small value. What is probably happening is that two copies of the FIELD_PREP() are being generated for ffs(rq) and ffs(mps). The latter might be (mps ? asm_fun(mps) + 1 : 0) leading to an extra copy for ffs(0) - which will cause the warning in FIELD_PREP. An alternate fix you be to move the validation of rq below the 'performance' clamp. David > > Avoid FIELD_PREP entirely by using direct bit manipulation. Replace > FIELD_PREP(PCI_EXP_DEVCTL_READRQ, ffs(rq) - 8) with the equivalent > manual bit operations: ((ffs(rq) - 8) << 12) & PCI_EXP_DEVCTL_READRQ. > > This bypasses the compile-time validation while maintaining identical > runtime behavior and functionality. > > Fixes: cbc654d18d37 ("bitops: Add __attribute_const__ to generic ffs()-family implementations") > Reported-by: Linux Kernel Functional Testing <lkft@linaro.org> > Closes: https://lore.kernel.org/linux-pci/CA+G9fYuysVr6qT8bjF6f08WLyCJRG7aXAeSd2F7=zTaHHd7L+Q@mail.gmail.com/T/#u > Signed-off-by: Anders Roxell <anders.roxell@linaro.org> > --- > drivers/pci/pci.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c > index e698278229f2..9f9607bd9f51 100644 > --- a/drivers/pci/pci.c > +++ b/drivers/pci/pci.c > @@ -5893,7 +5893,8 @@ int pcie_set_readrq(struct pci_dev *dev, int rq) > rq = mps; > } > > - v = FIELD_PREP(PCI_EXP_DEVCTL_READRQ, ffs(rq) - 8); > + /* Ideally we would used FIELD_PREP() but this is a work around for gcc-8 */ > + v = ((ffs(rq) - 8) << 12) & PCI_EXP_DEVCTL_READRQ; > > if (bridge->no_inc_mrrs) { > int max_mrrs = pcie_get_readrq(dev);
On Thu, Aug 28, 2025 at 12:12:37PM +0200, Anders Roxell wrote: > Commit cbc654d18d37 ("bitops: Add __attribute_const__ to generic > ffs()-family implementations") causes a compilation failure on ARM > footbridge_defconfig with gcc-8: > > FIELD_PREP: value too large for the field > > The error occurs in pcie_set_readrq() at: > v = FIELD_PREP(PCI_EXP_DEVCTL_READRQ, ffs(rq) - 8); > > With __attribute_const__, gcc-8 now performs wrong compile-time > validation in FIELD_PREP and cannot guarantee that ffs(rq) - 8 will > always produce values that fit in the 3-bit PCI_EXP_DEVCTL_READRQ field. Thanks for examining this! It seems rather alarming -- why did it work before? > Avoid FIELD_PREP entirely by using direct bit manipulation. Replace > FIELD_PREP(PCI_EXP_DEVCTL_READRQ, ffs(rq) - 8) with the equivalent > manual bit operations: ((ffs(rq) - 8) << 12) & PCI_EXP_DEVCTL_READRQ. > > This bypasses the compile-time validation while maintaining identical > runtime behavior and functionality. Did you dig into why this happened? It seems like a fragile situation, so I'm worried we'll see more of these pop up. > Fixes: cbc654d18d37 ("bitops: Add __attribute_const__ to generic ffs()-family implementations") > Reported-by: Linux Kernel Functional Testing <lkft@linaro.org> > Closes: https://lore.kernel.org/linux-pci/CA+G9fYuysVr6qT8bjF6f08WLyCJRG7aXAeSd2F7=zTaHHd7L+Q@mail.gmail.com/T/#u > Signed-off-by: Anders Roxell <anders.roxell@linaro.org> > --- > drivers/pci/pci.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c > index e698278229f2..9f9607bd9f51 100644 > --- a/drivers/pci/pci.c > +++ b/drivers/pci/pci.c > @@ -5893,7 +5893,8 @@ int pcie_set_readrq(struct pci_dev *dev, int rq) > rq = mps; > } > > - v = FIELD_PREP(PCI_EXP_DEVCTL_READRQ, ffs(rq) - 8); > + /* Ideally we would used FIELD_PREP() but this is a work around for gcc-8 */ > + v = ((ffs(rq) - 8) << 12) & PCI_EXP_DEVCTL_READRQ; > > if (bridge->no_inc_mrrs) { > int max_mrrs = pcie_get_readrq(dev); If you're sure this is okay, I'll take it with the series, but I feel like we should justify it better. :) -Kees -- Kees Cook
On Wed, Sep 03, 2025 at 09:29:40PM -0700, Kees Cook wrote: > Thanks for examining this! It seems rather alarming -- why did it > work before? I've proposed an alternative: https://lore.kernel.org/lkml/20250905052836.work.425-kees@kernel.org/ -- Kees Cook
© 2016 - 2025 Red Hat, Inc.