September 2020 - Linux-stable-mirror

❌ FAIL: Test report for kernel 5.8.10 (stable-queue)

by CKI Project

Hello, We ran automated tests on a recent commit from this kernel tree: Kernel repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Commit: 64d351e12747 - loop: Set correct device size when using LOOP_CONFIGURE The results of these automated tests are provided below. Overall result: FAILED (see details below) Merge: OK Compile: FAILED All kernel binaries, config files, and logs are available for download here: https://arr-cki-prod-datawarehouse-public.s3.amazonaws.com/index.html?prefi… We attempted to compile the kernel for multiple architectures, but the compile failed on one or more architectures: ppc64le: FAILED (see build-ppc64le.log.xz attachment) We hope that these logs can help you find the problem quickly. For the full detail on our testing procedures, please scroll to the bottom of this message. Please reply to this email if you have any questions about the tests that we ran or if you have any suggestions on how to make future tests more effective. ,-. ,-. ( C ) ( K ) Continuous `-',-.`-' Kernel ( I ) Integration `-' ______________________________________________________________________________ Compile testing --------------- We compiled the kernel for 4 architectures: aarch64: make options: make -j30 INSTALL_MOD_STRIP=1 targz-pkg ppc64le: make options: make -j30 INSTALL_MOD_STRIP=1 targz-pkg s390x: make options: make -j30 INSTALL_MOD_STRIP=1 targz-pkg x86_64: make options: make -j30 INSTALL_MOD_STRIP=1 targz-pkg

4 years

2
1
0 0

patch "usblp: fix race between disconnect() and read()" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usblp: fix race between disconnect() and read() to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 9cdabcb3ef8c24ca3a456e4db7b012befb688e73 Mon Sep 17 00:00:00 2001 From: Oliver Neukum <oneukum(a)suse.com> Date: Thu, 17 Sep 2020 12:34:27 +0200 Subject: usblp: fix race between disconnect() and read() read() needs to check whether the device has been disconnected before it tries to talk to the device. Signed-off-by: Oliver Neukum <oneukum(a)suse.com> Reported-by: syzbot+be5b5f86a162a6c281e6(a)syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20200917103427.15740-1-oneukum@suse.com Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/class/usblp.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/usb/class/usblp.c b/drivers/usb/class/usblp.c index 084c48c5848f..67cbd42421be 100644 --- a/drivers/usb/class/usblp.c +++ b/drivers/usb/class/usblp.c @@ -827,6 +827,11 @@ static ssize_t usblp_read(struct file *file, char __user *buffer, size_t len, lo if (rv < 0) return rv; + if (!usblp->present) { + count = -ENODEV; + goto done; + } + if ((avail = usblp->rstatus) < 0) { printk(KERN_ERR "usblp%d: error %d reading from printer\n", usblp->minor, (int)avail); -- 2.28.0

4 years

1
0
0 0

stable/linux-4.19.y baseline: 163 runs, 1 regressions (v4.19.146)

by kernelci.org bot

stable/linux-4.19.y baseline: 163 runs, 1 regressions (v4.19.146) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | results ---------+------+--------------+----------+----------------+-------- hsdk | arc | lab-baylibre | gcc-8 | hsdk_defconfig | 0/1 Details: https://kernelci.org/test/job/stable/branch/linux-4.19.y/kernel/v4.19.146/p… Test: baseline Tree: stable Branch: linux-4.19.y Describe: v4.19.146 URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git SHA: 015e94d0e37b6860e4354ce3cac56bd7c39c8992 Test Regressions ---------------- platform | arch | lab | compiler | defconfig | results ---------+------+--------------+----------+----------------+-------- hsdk | arc | lab-baylibre | gcc-8 | hsdk_defconfig | 0/1 Details: https://kernelci.org/test/plan/id/5f635ce8afa88a58aebf9dc8 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: hsdk_defconfig Compiler: gcc-8 (arc-elf32-gcc (ARCompact/ARCv2 ISA elf32 toolchain 2019.03-rc1) 8.3.1 20190225) Plain log: https://storage.kernelci.org//stable/linux-4.19.y/v4.19.146/arc/hsdk_defcon… HTML log: https://storage.kernelci.org//stable/linux-4.19.y/v4.19.146/arc/hsdk_defcon… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05/arc/baselin… * baseline.login: https://kernelci.org/test/case/id/5f635ce8afa88a58aebf9dc9 failing since 63 days (last pass: v4.19.124, first fail: v4.19.133)

4 years

1
0
0 0

Re: [PATCH] x86/smap: Fix the smap_save() asm

by Borislav Petkov

On Thu, Sep 17, 2020 at 02:25:50PM +0000, David Laight wrote: > I actually wonder if there is any code that really benefits from > the red-zone. The kernel has been without a red zone since 2002 at least: commit 47f16da277d10ef9494f3e9da2a9113bb22bcd75 Author: Andi Kleen <ak(a)muc.de> Date: Tue Feb 12 20:17:35 2002 -0800 [PATCH] x86_64 merge: arch + asm This adds the x86_64 arch and asm directories and a Documentation/x86_64. ... +CFLAGS += $(shell if $(CC) -mno-red-zone -S -o /dev/null -xc /dev/null >/dev/null 2>&1; then echo "-mno-red-zone"; fi ) Also, from the ABI doc: "A.2.2 Stack Layout The Linux kernel may align the end of the input argument area to a 8, instead of 16, byte boundary. It does not honor the red zone (see section 3.2.2) and therefore this area is not allowed to be used by kernel code. Kernel code should be compiled by GCC with the option -mno-red-zone." so forget the red zone. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette

4 years

2
1
0 0

[PATCH v3 01/14] rtc: rx8010: don't modify the global rtc ops

by Bartosz Golaszewski

From: Bartosz Golaszewski <bgolaszewski(a)baylibre.com> The way the driver is implemented is buggy for the (admittedly unlikely) use case where there are two RTCs with one having an interrupt configured and the second not. This is caused by the fact that we use a global rtc_class_ops struct which we modify depending on whether the irq number is present or not. Fix it by using two const ops structs with and without alarm operations. While at it: not being able to request a configured interrupt is an error so don't ignore it and bail out of probe(). Fixes: ed13d89b08e3 ("rtc: Add Epson RX8010SJ RTC driver") Cc: stable(a)vger.kernel.org Signed-off-by: Bartosz Golaszewski <bgolaszewski(a)baylibre.com> --- drivers/rtc/rtc-rx8010.c | 24 +++++++++++++++++------- 1 file changed, 17 insertions(+), 7 deletions(-) diff --git a/drivers/rtc/rtc-rx8010.c b/drivers/rtc/rtc-rx8010.c index fe010151ec8f..08c93d492494 100644 --- a/drivers/rtc/rtc-rx8010.c +++ b/drivers/rtc/rtc-rx8010.c @@ -407,16 +407,26 @@ static int rx8010_ioctl(struct device *dev, unsigned int cmd, unsigned long arg) } } -static struct rtc_class_ops rx8010_rtc_ops = { +static const struct rtc_class_ops rx8010_rtc_ops_default = { .read_time = rx8010_get_time, .set_time = rx8010_set_time, .ioctl = rx8010_ioctl, }; +static const struct rtc_class_ops rx8010_rtc_ops_alarm = { + .read_time = rx8010_get_time, + .set_time = rx8010_set_time, + .ioctl = rx8010_ioctl, + .read_alarm = rx8010_read_alarm, + .set_alarm = rx8010_set_alarm, + .alarm_irq_enable = rx8010_alarm_irq_enable, +}; + static int rx8010_probe(struct i2c_client *client, const struct i2c_device_id *id) { struct i2c_adapter *adapter = client->adapter; + const struct rtc_class_ops *rtc_ops; struct rx8010_data *rx8010; int err = 0; @@ -447,16 +457,16 @@ static int rx8010_probe(struct i2c_client *client, if (err) { dev_err(&client->dev, "unable to request IRQ\n"); - client->irq = 0; - } else { - rx8010_rtc_ops.read_alarm = rx8010_read_alarm; - rx8010_rtc_ops.set_alarm = rx8010_set_alarm; - rx8010_rtc_ops.alarm_irq_enable = rx8010_alarm_irq_enable; + return err; } + + rtc_ops = &rx8010_rtc_ops_alarm; + } else { + rtc_ops = &rx8010_rtc_ops_default; } rx8010->rtc = devm_rtc_device_register(&client->dev, client->name, - &rx8010_rtc_ops, THIS_MODULE); + rtc_ops, THIS_MODULE); if (IS_ERR(rx8010->rtc)) { dev_err(&client->dev, "unable to register the class device\n"); -- 2.26.1

4 years

3
2
0 0

[PATCH v4.19 v4.14 v4.9] rtc: rx8010: don't modify the global rtc ops

by Bartosz Golaszewski

From: Bartosz Golaszewski <bgolaszewski(a)baylibre.com> The way the driver is implemented is buggy for the (admittedly unlikely) use case where there are two RTCs with one having an interrupt configured and the second not. This is caused by the fact that we use a global rtc_class_ops struct which we modify depending on whether the irq number is present or not. Fix it by using two const ops structs with and without alarm operations. While at it: not being able to request a configured interrupt is an error so don't ignore it and bail out of probe(). Fixes: ed13d89b08e3 ("rtc: Add Epson RX8010SJ RTC driver") Signed-off-by: Bartosz Golaszewski <bgolaszewski(a)baylibre.com> Signed-off-by: Alexandre Belloni <alexandre.belloni(a)bootlin.com> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20200914154601.32245-2-brgl@bgdev.pl --- Hi! This is a backport that applies to the following stable branches: v4.19, v4.14, v4.9 drivers/rtc/rtc-rx8010.c | 24 +++++++++++++++++------- 1 file changed, 17 insertions(+), 7 deletions(-) diff --git a/drivers/rtc/rtc-rx8010.c b/drivers/rtc/rtc-rx8010.c index d08da371912c..93b1d8d9d2e9 100644 --- a/drivers/rtc/rtc-rx8010.c +++ b/drivers/rtc/rtc-rx8010.c @@ -423,16 +423,26 @@ static int rx8010_ioctl(struct device *dev, unsigned int cmd, unsigned long arg) } } -static struct rtc_class_ops rx8010_rtc_ops = { +static const struct rtc_class_ops rx8010_rtc_ops_default = { .read_time = rx8010_get_time, .set_time = rx8010_set_time, .ioctl = rx8010_ioctl, }; +static const struct rtc_class_ops rx8010_rtc_ops_alarm = { + .read_time = rx8010_get_time, + .set_time = rx8010_set_time, + .ioctl = rx8010_ioctl, + .read_alarm = rx8010_read_alarm, + .set_alarm = rx8010_set_alarm, + .alarm_irq_enable = rx8010_alarm_irq_enable, +}; + static int rx8010_probe(struct i2c_client *client, const struct i2c_device_id *id) { struct i2c_adapter *adapter = to_i2c_adapter(client->dev.parent); + const struct rtc_class_ops *rtc_ops; struct rx8010_data *rx8010; int err = 0; @@ -463,16 +473,16 @@ static int rx8010_probe(struct i2c_client *client, if (err) { dev_err(&client->dev, "unable to request IRQ\n"); - client->irq = 0; - } else { - rx8010_rtc_ops.read_alarm = rx8010_read_alarm; - rx8010_rtc_ops.set_alarm = rx8010_set_alarm; - rx8010_rtc_ops.alarm_irq_enable = rx8010_alarm_irq_enable; + return err; } + + rtc_ops = &rx8010_rtc_ops_alarm; + } else { + rtc_ops = &rx8010_rtc_ops_default; } rx8010->rtc = devm_rtc_device_register(&client->dev, client->name, - &rx8010_rtc_ops, THIS_MODULE); + rtc_ops, THIS_MODULE); if (IS_ERR(rx8010->rtc)) { dev_err(&client->dev, "unable to register the class device\n"); -- 2.26.1

4 years

1
0
0 0

IFC Fund Approved (IFC-060290_EC) 09-17-2020

by IFC

Congratulations! We are pleased to announce that your EMAIL ADDRESS has been selected to receive $ 1,500,000 under the IFC Global Development Funding Program due to the ongoing Coronavirus Pandemic. It was agreed and signed by the management team of the International Finance Corporation (IFC) and the Board of Directors of the World Bank Group and UBA Group. The reference number of your file is (IFC-060290_EC). All beneficiaries were selected through the IFC Global Random Integrated System, which has received more than 27 million e-mail addresses on the Internet. The lucky beneficiaries do not need to buy a ticket to participate in this IFC Global Development Funding program. Include your full details, such as your name and phone number: Age: Gender: Address and your file reference for processing and disbursing your IFC Global Development Fund. You are to receive your funding through a certified VISA ATM Card. With this VISA Card you can withdraw money from any part of the World without being disturbed or delay. Contact Mrs. Onari Duke with your code: IFC-060290_EC for more information. Card Issuing Bank: UBA Group Contact Name: Mrs. Onari Duke Email: onari.duke(a)bk.ru We hope to hear from you as soon as you receive payment for the IFC Global Development Fund. Further information on the IFC Global Development Funding Program can be found on our website: www.ifc.org Greetings, Mr. Philippe Le Houerou (Chairman of IFC) ********************************************************************************************************* NOTE: If you have received this message in your SPAM / BULK folder because your ISP has introduced restrictions, we (IFC Team) kindly ask you to handle it. ********************************************************************************************************

4 years

1
0
0 0

[PATCH v4] lib/string.c: implement stpcpy

by Nick Desaulniers

LLVM implemented a recent "libcall optimization" that lowers calls to `sprintf(dest, "%s", str)` where the return value is used to `stpcpy(dest, str) - dest`. This generally avoids the machinery involved in parsing format strings. `stpcpy` is just like `strcpy` except it returns the pointer to the new tail of `dest`. This optimization was introduced into clang-12. Implement this so that we don't observe linkage failures due to missing symbol definitions for `stpcpy`. Similar to last year's fire drill with: commit 5f074f3e192f ("lib/string.c: implement a basic bcmp") The kernel is somewhere between a "freestanding" environment (no full libc) and "hosted" environment (many symbols from libc exist with the same type, function signature, and semantics). As H. Peter Anvin notes, there's not really a great way to inform the compiler that you're targeting a freestanding environment but would like to opt-in to some libcall optimizations (see pr/47280 below), rather than opt-out. Arvind notes, -fno-builtin-* behaves slightly differently between GCC and Clang, and Clang is missing many __builtin_* definitions, which I consider a bug in Clang and am working on fixing. Masahiro summarizes the subtle distinction between compilers justly: To prevent transformation from foo() into bar(), there are two ways in Clang to do that; -fno-builtin-foo, and -fno-builtin-bar. There is only one in GCC; -fno-buitin-foo. (Any difference in that behavior in Clang is likely a bug from a missing __builtin_* definition.) Masahiro also notes: We want to disable optimization from foo() to bar(), but we may still benefit from the optimization from foo() into something else. If GCC implements the same transform, we would run into a problem because it is not -fno-builtin-bar, but -fno-builtin-foo that disables that optimization. In this regard, -fno-builtin-foo would be more future-proof than -fno-built-bar, but -fno-builtin-foo is still potentially overkill. We may want to prevent calls from foo() being optimized into calls to bar(), but we still may want other optimization on calls to foo(). It seems that compilers today don't quite provide the fine grain control over which libcall optimizations pseudo-freestanding environments would prefer. Finally, Kees notes that this interface is unsafe, so we should not encourage its use. As such, I've removed the declaration from any header, but it still needs to be exported to avoid linkage errors in modules. Reported-by: Sami Tolvanen <samitolvanen(a)google.com> Suggested-by: Andy Lavr <andy.lavr(a)gmail.com> Suggested-by: Arvind Sankar <nivedita(a)alum.mit.edu> Suggested-by: Joe Perches <joe(a)perches.com> Suggested-by: Kees Cook <keescook(a)chromium.org> Suggested-by: Masahiro Yamada <masahiroy(a)kernel.org> Suggested-by: Rasmus Villemoes <linux(a)rasmusvillemoes.dk> Signed-off-by: Nick Desaulniers <ndesaulniers(a)google.com> Tested-by: Nathan Chancellor <natechancellor(a)gmail.com> Reviewed-by: Kees Cook <keescook(a)chromium.org> Cc: stable(a)vger.kernel.org Link: https://bugs.llvm.org/show_bug.cgi?id=47162 Link: https://bugs.llvm.org/show_bug.cgi?id=47280 Link: https://github.com/ClangBuiltLinux/linux/issues/1126 Link: https://man7.org/linux/man-pages/man3/stpcpy.3.html Link: https://pubs.opengroup.org/onlinepubs/9699919799/functions/stpcpy.html Link: https://reviews.llvm.org/D85963 --- Changes V4: * Roll up Kees' comment fixup from https://lore.kernel.org/lkml/202009060302.4574D8D0E0@keescook/#t. * Keep Nathan's tested by tag. * Add Kees' reviewed by tag from https://lore.kernel.org/lkml/202009031446.3865FE82B@keescook/. Changes V3: * Drop Sami's Tested by tag; newer patch. * Add EXPORT_SYMBOL as per Andy. * Rewrite commit message, rewrote part of what Masahiro said to be generic in terms of foo() and bar(). * Prefer %NUL-terminated to NULL terminated. NUL is the ASCII character '\0', as per Arvind and Rasmus. Changes V2: * Added Sami's Tested by; though the patch changed implementation, the missing symbol at link time was the problem Sami was observing. * Fix __restrict -> __restrict__ typo as per Joe. * Drop note about restrict from commit message as per Arvind. * Fix NULL -> NUL as per Arvind; NUL is ASCII '\0'. TIL * Fix off by one error as per Arvind; I had another off by one error in my test program that was masking this. lib/string.c | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/lib/string.c b/lib/string.c index 6012c385fb31..b6b8847218b5 100644 --- a/lib/string.c +++ b/lib/string.c @@ -272,6 +272,30 @@ ssize_t strscpy_pad(char *dest, const char *src, size_t count) } EXPORT_SYMBOL(strscpy_pad); +/** + * stpcpy - copy a string from src to dest returning a pointer to the new end + * of dest, including src's %NUL-terminator. May overrun dest. + * @dest: pointer to end of string being copied into. Must be large enough + * to receive copy. + * @src: pointer to the beginning of string being copied from. Must not overlap + * dest. + * + * stpcpy differs from strcpy in a key way: the return value is a pointer + * to the new %NUL-terminating character in @dest. (For strcpy, the return + * value is a pointer to the start of @dest. This interface is considered + * unsafe as it doesn't perform bounds checking of the inputs. As such it's + * not recommended for usage. Instead, its definition is provided in case + * the compiler lowers other libcalls to stpcpy. + */ +char *stpcpy(char *__restrict__ dest, const char *__restrict__ src); +char *stpcpy(char *__restrict__ dest, const char *__restrict__ src) +{ + while ((*dest++ = *src++) != '\0') + /* nothing */; + return --dest; +} +EXPORT_SYMBOL(stpcpy); + #ifndef __HAVE_ARCH_STRCAT /** * strcat - Append one %NUL-terminated string to another -- 2.28.0.618.gf4bc123cb7-goog

4 years

4
7
0 0

[PATCH] s390/pkey: fix paes selftest failure with paes and pkey static build

by Harald Freudenberger

When both the paes and the pkey kernel module are statically build into the kernel, the paes cipher selftests run before the pkey kernel module is initialized. So a static variable set in the pkey init function and used in the pkey_clr2protkey function is not initialized when the paes cipher's selftests request to call pckmo for transforming a clear key value into a protected key. This patch moves the initial setup of the static variable into the function pck_clr2protkey. So it's possible, to use the function for transforming a clear to a protected key even before the pkey init function has been called and the paes selftests may run successful. Signed-off-by: Harald Freudenberger <freude(a)linux.ibm.com> Reported-by: Alexander Egorenkov <Alexander.Egorenkov(a)ibm.com> Cc: Stable <stable(a)vger.kernel.org> --- drivers/s390/crypto/pkey_api.c | 30 ++++++++++++++++-------------- 1 file changed, 16 insertions(+), 14 deletions(-) diff --git a/drivers/s390/crypto/pkey_api.c b/drivers/s390/crypto/pkey_api.c index 490917cd44d0..5f75c9dfe071 100644 --- a/drivers/s390/crypto/pkey_api.c +++ b/drivers/s390/crypto/pkey_api.c @@ -34,9 +34,6 @@ MODULE_DESCRIPTION("s390 protected key interface"); #define KEYBLOBBUFSIZE 8192 /* key buffer size used for internal processing */ #define MAXAPQNSINLIST 64 /* max 64 apqns within a apqn list */ -/* mask of available pckmo subfunctions, fetched once at module init */ -static cpacf_mask_t pckmo_functions; - /* * debug feature data and functions */ @@ -90,6 +87,9 @@ static int pkey_clr2protkey(u32 keytype, const struct pkey_clrkey *clrkey, struct pkey_protkey *protkey) { + /* mask of available pckmo subfunctions */ + static cpacf_mask_t pckmo_functions; + long fc; int keysize; u8 paramblock[64]; @@ -113,11 +113,13 @@ static int pkey_clr2protkey(u32 keytype, return -EINVAL; } - /* - * Check if the needed pckmo subfunction is available. - * These subfunctions can be enabled/disabled by customers - * in the LPAR profile or may even change on the fly. - */ + /* did we already check for PCKMO ? */ + if (!pckmo_functions.bytes[0]) { + /* no, so check now */ + if (!cpacf_query(CPACF_PCKMO, &pckmo_functions)) + return -ENODEV; + } + /* check for the pckmo subfunction we need now */ if (!cpacf_test_func(&pckmo_functions, fc)) { DEBUG_ERR("%s pckmo functions not available\n", __func__); return -ENODEV; @@ -1853,7 +1855,7 @@ static struct miscdevice pkey_dev = { */ static int __init pkey_init(void) { - cpacf_mask_t kmc_functions; + cpacf_mask_t func_mask; /* * The pckmo instruction should be available - even if we don't @@ -1861,15 +1863,15 @@ static int __init pkey_init(void) * is also the minimum level for the kmc instructions which * are able to work with protected keys. */ - if (!cpacf_query(CPACF_PCKMO, &pckmo_functions)) + if (!cpacf_query(CPACF_PCKMO, &func_mask)) return -ENODEV; /* check for kmc instructions available */ - if (!cpacf_query(CPACF_KMC, &kmc_functions)) + if (!cpacf_query(CPACF_KMC, &func_mask)) return -ENODEV; - if (!cpacf_test_func(&kmc_functions, CPACF_KMC_PAES_128) || - !cpacf_test_func(&kmc_functions, CPACF_KMC_PAES_192) || - !cpacf_test_func(&kmc_functions, CPACF_KMC_PAES_256)) + if (!cpacf_test_func(&func_mask, CPACF_KMC_PAES_128) || + !cpacf_test_func(&func_mask, CPACF_KMC_PAES_192) || + !cpacf_test_func(&func_mask, CPACF_KMC_PAES_256)) return -ENODEV; pkey_debug_init(); -- 2.17.1

4 years

3
3
0 0

[PATCH v2] drm/i915: Fix the race between the GEM close and debugfs

by Nikunj A. Dadhania

As we close GEM object and set file_priv to -EBADF which is protected by ctx->mutex, populating the GEM debugfs info is not protected and results in the crash shown below. Make sure to protect the access to file_priv using ctx->mutex to avoid race. BUG: unable to handle page fault for address: ffffffffffffffff RIP: 0010:i915_gem_object_info+0x26b/0x3eb Code: 89 44 24 48 48 89 44 24 40 48 89 44 24 38 48 89 44 24 30 48 89 44 24 28 48 89 44 24 20 49 8b 46 f0 48 89 44 24 20 49 8b 46 a0 <48> 8b 58 08 b9 0a 00 00 00 48 b8 aa aa aa aa aa aa aa aa 48 8d bc RSP: 0018:ffffac81c14cfc30 EFLAGS: 00010246 RAX: fffffffffffffff7 RBX: ffff95094429c218 RCX: ffff95096756c740 RDX: 0000000000000000 RSI: ffffffff919b93ee RDI: ffff95094429c218 RBP: ffffac81c14cfd58 R08: ffff9509746fab80 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: ffff9509753f8e80 R13: ffffac81c14cfc98 R14: ffff95094429c268 R15: ffffac81c14cfc88 FS: 00007a1bdcd52900(0000) GS:ffff950977e00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffff CR3: 000000026b4e0000 CR4: 0000000000340ef0 Call Trace: seq_read+0x162/0x3ca full_proxy_read+0x5b/0x8d __vfs_read+0x45/0x1b9 vfs_read+0xc9/0x15e ksys_read+0x7e/0xde do_syscall_64+0x54/0x7e entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7a1bdd34cf03 Signed-off-by: Nikunj A. Dadhania <nikunj.dadhania(a)linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/i915/i915_debugfs.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 784219962193..ea469168cd44 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -326,6 +326,7 @@ static void print_context_stats(struct seq_file *m, } i915_gem_context_unlock_engines(ctx); + mutex_lock(&ctx->mutex); if (!IS_ERR_OR_NULL(ctx->file_priv)) { struct file_stats stats = { .vm = rcu_access_pointer(ctx->vm), @@ -346,6 +347,7 @@ static void print_context_stats(struct seq_file *m, print_file_stats(m, name, stats); } + mutex_unlock(&ctx->mutex); spin_lock(&i915->gem.contexts.lock); list_safe_reset_next(ctx, cn, link); -- 2.17.1

4 years

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror September 2020