From: John Harrison <John.C.Harrison(a)Intel.com>
Direction from hardware is that stolen memory should never be used for
ring buffer allocations on platforms with LLC. There are too many
caching pitfalls due to the way stolen memory accesses are routed. So
it is safest to just not use it.
Signed-off-by: John Harrison <John.C.Harrison(a)Intel.com>
Fixes: c58b735fc762 ("drm/i915: Allocate rings from stolen")
Cc: Chris Wilson <chris(a)chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com>
Cc: Jani Nikula <jani.nikula(a)linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin(a)linux.intel.com>
Cc: intel-gfx(a)lists.freedesktop.org
Cc: <stable(a)vger.kernel.org> # v4.9+
---
drivers/gpu/drm/i915/gt/intel_ring.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ring.c b/drivers/gpu/drm/i915/gt/intel_ring.c
index 15ec64d881c44..fb1d2595392ed 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring.c
@@ -116,7 +116,7 @@ static struct i915_vma *create_ring_vma(struct i915_ggtt *ggtt, int size)
obj = i915_gem_object_create_lmem(i915, size, I915_BO_ALLOC_VOLATILE |
I915_BO_ALLOC_PM_VOLATILE);
- if (IS_ERR(obj) && i915_ggtt_has_aperture(ggtt))
+ if (IS_ERR(obj) && i915_ggtt_has_aperture(ggtt) && !HAS_LLC(i915))
obj = i915_gem_object_create_stolen(i915, size);
if (IS_ERR(obj))
obj = i915_gem_object_create_internal(i915, size);
--
2.39.1
Hi Greg,
I noticed that gcc 4.6 is also the requirement for kernel 5.4:
https://www.kernel.org/doc/html/v5.4/process/changes.html
So anyone who compiles 5.4 with gcc4.6 should also run into the problem.
Best regards,
Michael
-----Ursprüngliche Nachricht-----
Von: Michael Nies
Gesendet: Donnerstag, 9. Februar 2023 08:30
An: 'Greg KH' <gregkh(a)linuxfoundation.org>
Cc: 'stable(a)vger.kernel.org' <stable(a)vger.kernel.org>
Betreff: AW: Kernel Bug 217013
Hi Greg,
thanks for your answer.
We do not use kernel 4.19 at the moment.
On the systems itself we have only gcc 4.4.5 - so requirements for kernel 4.19 are not matched and we stay on 4.14.
But if anyone else should try to compile 4.19 with gcc 4.6 - they should run into the same problem because of "_Alignof".
On my side it is planned to compile kernel 4.19 with gcc 4.7 or higher - so we should not have problems with "_Alignof" in the future.
Best regards,
Michael
-----Ursprüngliche Nachricht-----
Von: Greg KH <mailto:gregkh@linuxfoundation.org>
Gesendet: Donnerstag, 9. Februar 2023 08:10
An: Michael Nies <mailto:michael.nies@netclusive.com>
Cc: 'stable(a)vger.kernel.org' <mailto:stable@vger.kernel.org>
Betreff: Re: Kernel Bug 217013
On Thu, Feb 09, 2023 at 06:54:51AM +0000, Michael Nies wrote:
> Hello,
>
> could you please have a look at Kernel Bug 217013 that was reported by me yesterday?
> https://bugzilla.kernel.org/show_bug.cgi?id=217013
>
> Greg wrote that I should write a Mail to this address.
Thanks for the email, and the bug report, I'll work on this later today.
Do you also see the same problem with the 4.19.y kernel tree? Or are you not using that one too, or with a newer compiler?
thanks,
greg k-h
Greg,
These two patches have been (correctly) auto selected to 5.15.y
along with the two dependency patches tagged with:
Stable-dep-of: b306e90ffabd ("ovl: remove privs in ovl_copyfile()")
9636e70ee2d3 ("ovl: use ovl_copy_{real,upper}attr() wrappers")
a54843833caf ("ovl: store lower path in ovl_inode")
It wasn't wrong to apply those patches with the two dependencies
to 5.15.y, but it is not as easy to do for 5.10.y, so here is a
very simple backport of the two fixes to 5.10.y, i.e.:
replaced ovl_copyattr(X) with ovl_copyattr(ovl_inode_real(X), X).
Note that the language "This fixes some failure in fstests..."
in commit message means that those fixes are not enough for the
tests to pass. Additional backports from v6.2 are needed for the
tests to pass and I am collaborating those backports with Leah,
so they will hit 5.15.y first before posting them for 5.10.y.
Never the less, these overlayfs fixes are important security
fixes, so they should be applied to LTS kernel even before
all the cases in the fstests are fixed.
Thanks,
Amir.
Amir Goldstein (2):
ovl: remove privs in ovl_copyfile()
ovl: remove privs in ovl_fallocate()
fs/overlayfs/file.c | 28 +++++++++++++++++++++++++---
1 file changed, 25 insertions(+), 3 deletions(-)
--
2.34.1
BugLink: https://bugs.launchpad.net/bugs/2007581
Commit 5467801f1fcb ("gpio: Restrict usage of GPIO chip irq members
before initialization") attempted to fix a race condition that lead to a
NULL pointer, but in the process caused a regression for _AEI/_EVT
declared GPIOs.
This manifests in messages showing deferred probing while trying to
allocate IRQs like so:
amd_gpio AMDI0030:00: Failed to translate GPIO pin 0x0000 to IRQ, err -517
amd_gpio AMDI0030:00: Failed to translate GPIO pin 0x002C to IRQ, err -517
amd_gpio AMDI0030:00: Failed to translate GPIO pin 0x003D to IRQ, err -517
[ .. more of the same .. ]
The code for walking _AEI doesn't handle deferred probing and so this
leads to non-functional GPIO interrupts.
Fix this issue by moving the call to `acpi_gpiochip_request_interrupts`
to occur after gc->irc.initialized is set.
Fixes: 5467801f1fcb ("gpio: Restrict usage of GPIO chip irq members before initialization")
Link: https://lore.kernel.org/linux-gpio/BL1PR12MB51577A77F000A008AA694675E2EF9@B…
Link: https://bugzilla.suse.com/show_bug.cgi?id=1198697
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215850
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1979
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1976
Reported-by: Mario Limonciello <mario.limonciello(a)amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello(a)amd.com>
Reviewed-by: Shreeya Patel <shreeya.patel(a)collabora.com>
Tested-By: Samuel Čavoj <samuel(a)cavoj.net>
Tested-By: lukeluk498(a)gmail.com Link:
Reviewed-by: Andy Shevchenko <andy.shevchenko(a)gmail.com>
Acked-by: Linus Walleij <linus.walleij(a)linaro.org>
Reviewed-and-tested-by: Takashi Iwai <tiwai(a)suse.de>
Cc: Shreeya Patel <shreeya.patel(a)collabora.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
(backported from commit 06fb4ecfeac7e00d6704fa5ed19299f2fefb3cc9)
Signed-off-by: Asmaa Mnebhi <asmaa(a)nvidia.com>
---
drivers/gpio/gpiolib.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index e4d47e00c392..049cdfc975b3 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -2329,8 +2329,6 @@ static int gpiochip_add_irqchip(struct gpio_chip *gpiochip,
gpiochip_set_irq_hooks(gpiochip);
- acpi_gpiochip_request_interrupts(gpiochip);
-
/*
* Using barrier() here to prevent compiler from reordering
* gc->irq.initialized before initialization of above
@@ -2340,6 +2338,8 @@ static int gpiochip_add_irqchip(struct gpio_chip *gpiochip,
gpiochip->irq.initialized = true;
+ acpi_gpiochip_request_interrupts(gpiochip);
+
return 0;
}
--
2.30.1
A number of Cezanne systems report IRQ1 as a wakeup source when it's not actually
a wakeup. This can cause problems for certain ACPI events. The following fix
went upstream that fixed it:
commit 8e60615e8932 ("platform/x86/amd: pmc: Disable IRQ1 wakeup for RN/CZN")
It was reported that this fix actually helped here with older kernels too:
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1921#note_1770257
So backport this fix to 5.15.y as well.
This backport is dependent upon being able to read the SMU version which
happened in a different commit. So backport that commit and follow up fixes
as well.
v1->v2:
* Split into multiple commits
* Catch some fixes for reading SMU version too
Hans de Goede (1):
platform/x86: amd-pmc: Fix compilation when CONFIG_DEBUGFS is disabled
Mario Limonciello (2):
platform/x86: amd-pmc: Correct usage of SMU version
platform/x86/amd: pmc: Disable IRQ1 wakeup for RN/CZN
Sanket Goswami (1):
platform/x86: amd-pmc: Export Idlemask values based on the APU
drivers/platform/x86/amd-pmc.c | 116 +++++++++++++++++++++++++++++++++
1 file changed, 116 insertions(+)
--
2.34.1
No upstream commit exists: the problem addressed here is that
'commit 75309018a24d ("s390: add support for TIF_NOTIFY_SIGNAL")'
was backported to 5.10. This commit is broken, but nobody noticed
upstream, since shortly after s390 converted to generic entry with
'commit 75309018a24d ("s390: add support for TIF_NOTIFY_SIGNAL")', which
implicitly fixed the problem outlined below.
Thread flag is set to TIF_NOTIFY_SIGNAL for io_uring work. The io work
user or syscall calls do_signal when either one of the TIF_SIGPENDING or
TIF_NOTIFY_SIGNAL flag is set. However, do_signal does consider only
TIF_SIGPENDING signal and ignores TIF_NOTIFY_SIGNAL condition. This
means get_signal is never invoked for TIF_NOTIFY_SIGNAL and hence the
flag is not cleared, which results in an endless do_signal loop.
Reference: 'commit 788d0824269b ("io_uring: import 5.15-stable io_uring")'
Fixes: 75309018a24d ("s390: add support for TIF_NOTIFY_SIGNAL")
Cc: stable(a)vger.kernel.org # 5.10.162
Acked-by: Heiko Carstens <hca(a)linux.ibm.com>
Acked-by: Sven Schnelle <svens(a)linux.ibm.com>
Signed-off-by: Sumanth Korikkar <sumanthk(a)linux.ibm.com>
---
arch/s390/kernel/signal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/s390/kernel/signal.c b/arch/s390/kernel/signal.c
index b27b6c1f058d..9e900a8977bd 100644
--- a/arch/s390/kernel/signal.c
+++ b/arch/s390/kernel/signal.c
@@ -472,7 +472,7 @@ void do_signal(struct pt_regs *regs)
current->thread.system_call =
test_pt_regs_flag(regs, PIF_SYSCALL) ? regs->int_code : 0;
- if (test_thread_flag(TIF_SIGPENDING) && get_signal(&ksig)) {
+ if (get_signal(&ksig)) {
/* Whee! Actually deliver the signal. */
if (current->thread.system_call) {
regs->int_code = current->thread.system_call;
--
2.37.2