June 2021 - Linux-stable-mirror

[PATCH] i2c: i801: Ensure that SMBHSTSTS_INUSE_STS is cleared when leaving i801_access

by Heiner Kallweit

As explained in [0] currently we may leave SMBHSTSTS_INUSE_STS set, thus potentially breaking ACPI/BIOS usage of the SMBUS device. Seems patch [0] needs a little bit more of review effort, therefore I'd suggest to apply a part of it as quick win. Just clearing SMBHSTSTS_INUSE_STS when leaving i801_access() should fix the referenced issue and leaves more time for discussing a more sophisticated locking handling. [0] https://www.spinics.net/lists/linux-i2c/msg51558.html Fixes: 01590f361e94 ("i2c: i801: Instantiate SPD EEPROMs automatically") Suggested-by: Hector Martin <marcan(a)marcan.st> Signed-off-by: Heiner Kallweit <hkallweit1(a)gmail.com> --- drivers/i2c/busses/i2c-i801.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c index c7d96cf5e..ab3470e77 100644 --- a/drivers/i2c/busses/i2c-i801.c +++ b/drivers/i2c/busses/i2c-i801.c @@ -948,6 +948,9 @@ static s32 i801_access(struct i2c_adapter *adap, u16 addr, } out: + /* Unlock the SMBus device for use by BIOS/ACPI */ + outb_p(SMBHSTSTS_INUSE_STS, SMBHSTSTS(priv)); + pm_runtime_mark_last_busy(&priv->pci_dev->dev); pm_runtime_put_autosuspend(&priv->pci_dev->dev); mutex_unlock(&priv->acpi_lock); -- 2.31.1

3 years, 9 months

2
1
0 0

[PATCH] ACPI: EC: Look for ECDT EC after calling acpi_load_tables()

by Laurențiu Păncescu

commit b1c0330823fe upstream. Backport of ACPI fix for #199981 for linux-4.9.y, tested on an Asus EeePC 1005PE running Debian Buster. Some systems have had functional issues since commit 5a8361f7ecce (ACPICA: Integrate package handling with module-level code) that, among other things, changed the initial values of the acpi_gbl_group_module_level_code and acpi_gbl_parse_table_as_term_list global flags in ACPICA which implicitly caused acpi_ec_ecdt_probe() to be called before acpi_load_tables() on the vast majority of platforms. Namely, before commit 5a8361f7ecce, acpi_load_tables() was called from acpi_early_init() if acpi_gbl_parse_table_as_term_list was FALSE and acpi_gbl_group_module_level_code was TRUE, which almost always was the case as FALSE and TRUE were their initial values, respectively. The acpi_gbl_parse_table_as_term_list value would be changed to TRUE for a couple of platforms in acpi_quirks_dmi_table[], but it remained FALSE in the vast majority of cases. After commit 5a8361f7ecce, the initial values of the two flags have been reversed, so in effect acpi_load_tables() has not been called from acpi_early_init() any more. That, in turn, affects acpi_ec_ecdt_probe() which is invoked before acpi_load_tables() now and it is not possible to evaluate the _REG method for the EC address space handler installed by it. That effectively causes the EC address space to be inaccessible to AML on platforms with an ECDT matching the EC device definition in the DSDT and functional problems ensue in there. Because the default behavior before commit 5a8361f7ecce was to call acpi_ec_ecdt_probe() after acpi_load_tables(), it should be safe to do that again. Moreover, the EC address space handler installed by acpi_ec_ecdt_probe() is only needed for AML to be able to access the EC address space and the only AML that can run during acpi_load_tables() is module-level code which only is allowed to access address spaces with default handlers (memory, I/O and PCI config space). For this reason, move the acpi_ec_ecdt_probe() invocation back to acpi_bus_init(), from where it was taken away by commit d737f333b211 (ACPI: probe ECDT before loading AML tables regardless of module-level code flag), and put it after the invocation of acpi_load_tables() to restore the original code ordering from before commit 5a8361f7ecce. Fixes: 5a8361f7ecce ("ACPICA: Integrate package handling with module-level code") Link: https://bugzilla.kernel.org/show_bug.cgi?id=199981 Reported-by: step-ali <sunmooon15(a)gmail.com> Reported-by: Charles Stanhope <charles.stanhope(a)gmail.com> Tested-by: Charles Stanhope <charles.stanhope(a)gmail.com> Reported-by: Paulo Nascimento <paulo.ulusu(a)googlemail.com> Reported-by: David Purton <dcpurton(a)marshwiggle.net> Reported-by: Adam Harvey <adam(a)adamharvey.name> Reported-by: Zhang Rui <rui.zhang(a)intel.com> Tested-by: Zhang Rui <rui.zhang(a)intel.com> Tested-by: Jean-Marc Lenoir <archlinux(a)jihemel.com> Tested-by: Laurentiu Pancescu <laurentiu(a)laurentiupancescu.com> Signed-off-by: Laurentiu Pancescu <laurentiu(a)laurentiupancescu.com> --- drivers/acpi/bus.c | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c index 92a146861086..cc88571c2cac 100644 --- a/drivers/acpi/bus.c +++ b/drivers/acpi/bus.c @@ -1133,17 +1133,6 @@ static int __init acpi_bus_init(void) acpi_os_initialize1(); - /* - * ACPI 2.0 requires the EC driver to be loaded and work before - * the EC device is found in the namespace (i.e. before - * acpi_load_tables() is called). - * - * This is accomplished by looking for the ECDT table, and getting - * the EC parameters out of that. - */ - status = acpi_ec_ecdt_probe(); - /* Ignore result. Not having an ECDT is not fatal. */ - if (acpi_gbl_execute_tables_as_methods || !acpi_gbl_group_module_level_code) { status = acpi_load_tables(); @@ -1154,6 +1143,18 @@ static int __init acpi_bus_init(void) } } + /* + * ACPI 2.0 requires the EC driver to be loaded and work before the EC + * device is found in the namespace. + * + * This is accomplished by looking for the ECDT table and getting the EC + * parameters out of that. + * + * Do that before calling acpi_initialize_objects() which may trigger EC + * address space accesses. + */ + acpi_ec_ecdt_probe(); + status = acpi_enable_subsystem(ACPI_NO_ACPI_ENABLE); if (ACPI_FAILURE(status)) { printk(KERN_ERR PREFIX -- 2.20.1

3 years, 9 months

2
1
0 0

[PATCH RESEND v3] writeback: fix obtain a reference to a freeing memcg css

by Muchun Song

The caller of wb_get_create() should pin the memcg, because wb_get_create() relies on this guarantee. The rcu read lock only can guarantee that the memcg css returned by css_from_id() cannot be released, but the reference of the memcg can be zero. rcu_read_lock() memcg_css = css_from_id() wb_get_create(memcg_css) cgwb_create(memcg_css) // css_get can change the ref counter from 0 back to 1 css_get(memcg_css) rcu_read_unlock() Fix it by holding a reference to the css before calling wb_get_create(). This is not a problem I encountered in the real world. Just the result of a code review. Fixes: 682aa8e1a6a1 ("writeback: implement unlocked_inode_to_wb transaction and use it for stat updates") Signed-off-by: Muchun Song <songmuchun(a)bytedance.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Acked-by: Tejun Heo <tj(a)kernel.org> Cc: <stable(a)vger.kernel.org> --- Since this patch has not been merged to the linux-next tree, just resend it. Changelog in v3: 1. Do not change GFP_ATOMIC. 2. Update commit log. Thanks for Michal's review and suggestions. Changelog in v2: 1. Replace GFP_ATOMIC with GFP_NOIO suggested by Matthew. fs/fs-writeback.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c index 3ac002561327..dedde99da40d 100644 --- a/fs/fs-writeback.c +++ b/fs/fs-writeback.c @@ -506,9 +506,14 @@ static void inode_switch_wbs(struct inode *inode, int new_wb_id) /* find and pin the new wb */ rcu_read_lock(); memcg_css = css_from_id(new_wb_id, &memory_cgrp_subsys); - if (memcg_css) - isw->new_wb = wb_get_create(bdi, memcg_css, GFP_ATOMIC); + if (memcg_css && !css_tryget(memcg_css)) + memcg_css = NULL; rcu_read_unlock(); + if (!memcg_css) + goto out_free; + + isw->new_wb = wb_get_create(bdi, memcg_css, GFP_ATOMIC); + css_put(memcg_css); if (!isw->new_wb) goto out_free; -- 2.11.0

3 years, 9 months

1
0
0 0

[patch V2 05/14] x86/fpu: Limit xstate copy size in xstateregs_set()

by Thomas Gleixner

If the count argument is larger than the xstate size, this will happily copy beyond the end of xstate. Fixes: 91c3dba7dbc1 ("x86/fpu/xstate: Fix PTRACE frames for XSAVES") Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org --- arch/x86/kernel/fpu/regset.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/kernel/fpu/regset.c +++ b/arch/x86/kernel/fpu/regset.c @@ -117,7 +117,7 @@ int xstateregs_set(struct task_struct *t /* * A whole standard-format XSAVE buffer is needed: */ - if ((pos != 0) || (count < fpu_user_xstate_size)) + if (pos != 0 || count != fpu_user_xstate_size) return -EFAULT; xsave = &fpu->state.xsave;

3 years, 9 months

1
0
0 0

[patch V2 03/14] x86/fpu: Invalidate FPU state after a failed XRSTOR from a user buffer

by Thomas Gleixner

From: Andy Lutomirski <luto(a)kernel.org> Both Intel and AMD consider it to be architecturally valid for XRSTOR to fail with #PF but nonetheless change the register state. The actual conditions under which this might occur are unclear [1], but it seems plausible that this might be triggered if one sibling thread unmaps a page and invalidates the shared TLB while another sibling thread is executing XRSTOR on the page in question. __fpu__restore_sig() can execute XRSTOR while the hardware registers are preserved on behalf of a different victim task (using the fpu_fpregs_owner_ctx mechanism), and, in theory, XRSTOR could fail but modify the registers. If this happens, then there is a window in which __fpu__restore_sig() could schedule out and the victim task could schedule back in without reloading its own FPU registers. This would result in part of the FPU state that __fpu__restore_sig() was attempting to load leaking into the victim task's user-visible state. Invalidate preserved FPU registers on XRSTOR failure to prevent this situation from corrupting any state. [1] Frequent readers of the errata lists might imagine "complex microarchitectural conditions" Fixes: 1d731e731c4c ("x86/fpu: Add a fastpath to __fpu__restore_sig()") Signed-off-by: Andy Lutomirski <luto(a)kernel.org> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org --- V2: Amend changelog - Borislav --- arch/x86/kernel/fpu/signal.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) --- a/arch/x86/kernel/fpu/signal.c +++ b/arch/x86/kernel/fpu/signal.c @@ -369,6 +369,27 @@ static int __fpu__restore_sig(void __use fpregs_unlock(); return 0; } + + if (test_thread_flag(TIF_NEED_FPU_LOAD)) { + /* + * The FPU registers do not belong to current, and + * we just did an FPU restore operation, restricted + * to the user portion of the register file, and + * failed. In the event that the ucode was + * unfriendly and modified the registers at all, we + * need to make sure that we aren't corrupting an + * innocent non-current task's registers. + */ + __cpu_invalidate_fpregs_state(); + } else { + /* + * As above, we may have just clobbered current's + * user FPU state. We will either successfully + * load it or clear it below, so no action is + * required here. + */ + } + fpregs_unlock(); } else { /*

3 years, 9 months

1
0
0 0

[PATCH v2] media: uvcvideo: Fix pixel format change for Elgato Cam Link 4K

by Benjamin Drung

The Elgato Cam Link 4K HDMI video capture card reports to support three different pixel formats, where the first format depends on the connected HDMI device. ``` $ v4l2-ctl -d /dev/video0 --list-formats-ext ioctl: VIDIOC_ENUM_FMT Type: Video Capture [0]: 'NV12' (Y/CbCr 4:2:0) Size: Discrete 3840x2160 Interval: Discrete 0.033s (29.970 fps) [1]: 'NV12' (Y/CbCr 4:2:0) Size: Discrete 3840x2160 Interval: Discrete 0.033s (29.970 fps) [2]: 'YU12' (Planar YUV 4:2:0) Size: Discrete 3840x2160 Interval: Discrete 0.033s (29.970 fps) ``` Changing the pixel format to anything besides the first pixel format does not work: ``` $ v4l2-ctl -d /dev/video0 --try-fmt-video pixelformat=YU12 Format Video Capture: Width/Height : 3840/2160 Pixel Format : 'NV12' (Y/CbCr 4:2:0) Field : None Bytes per Line : 3840 Size Image : 12441600 Colorspace : sRGB Transfer Function : Rec. 709 YCbCr/HSV Encoding: Rec. 709 Quantization : Default (maps to Limited Range) Flags : ``` User space applications like VLC might show an error message on the terminal in that case: ``` libv4l2: error set_fmt gave us a different result than try_fmt! ``` Depending on the error handling of the user space applications, they might display a distorted video, because they use the wrong pixel format for decoding the stream. The Elgato Cam Link 4K responds to the USB video probe VS_PROBE_CONTROL/VS_COMMIT_CONTROL with a malformed data structure: The second byte contains bFormatIndex (instead of being the second byte of bmHint). The first byte is always zero. The third byte is always 1. The firmware bug was reported to Elgato on 2020-12-01 and it was forwarded by the support team to the developers as feature request. There is no firmware update available since then. The latest firmware for Elgato Cam Link 4K as of 2021-03-23 has MCU 20.02.19 and FPGA 67. Therefore add a quirk to correct the malformed data structure. The quirk was successfully tested with VLC, OBS, and Chromium using different pixel formats (YUYV, NV12, YU12), resolutions (3840x2160, 1920x1080), and frame rates (29.970 and 59.940 fps). Cc: stable(a)vger.kernel.org Signed-off-by: Benjamin Drung <bdrung(a)posteo.de> --- I am sending this patch a fourth time since I got no response and the last resend is over a month ago. This time I am including Linus Torvalds in the hope to get it reviewed. drivers/media/usb/uvc/uvc_driver.c | 13 +++++++++++++ drivers/media/usb/uvc/uvc_video.c | 21 +++++++++++++++++++++ drivers/media/usb/uvc/uvcvideo.h | 1 + 3 files changed, 35 insertions(+) diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c index 9a791d8ef200..6ce58950d78b 100644 --- a/drivers/media/usb/uvc/uvc_driver.c +++ b/drivers/media/usb/uvc/uvc_driver.c @@ -3164,6 +3164,19 @@ static const struct usb_device_id uvc_ids[] = { .bInterfaceSubClass = 1, .bInterfaceProtocol = 0, .driver_info = UVC_INFO_META(V4L2_META_FMT_D4XX) }, + /* + * Elgato Cam Link 4K + * Latest firmware as of 2021-03-23 needs this quirk. + * MCU: 20.02.19, FPGA: 67 + */ + { .match_flags = USB_DEVICE_ID_MATCH_DEVICE + | USB_DEVICE_ID_MATCH_INT_INFO, + .idVendor = 0x0fd9, + .idProduct = 0x0066, + .bInterfaceClass = USB_CLASS_VIDEO, + .bInterfaceSubClass = 1, + .bInterfaceProtocol = 0, + .driver_info = UVC_INFO_QUIRK(UVC_QUIRK_FIX_FORMAT_INDEX) }, /* Generic USB Video Class */ { USB_INTERFACE_INFO(USB_CLASS_VIDEO, 1, UVC_PC_PROTOCOL_UNDEFINED) }, { USB_INTERFACE_INFO(USB_CLASS_VIDEO, 1, UVC_PC_PROTOCOL_15) }, diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c index a777b389a66e..910d22233d74 100644 --- a/drivers/media/usb/uvc/uvc_video.c +++ b/drivers/media/usb/uvc/uvc_video.c @@ -131,6 +131,27 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming *stream, struct uvc_frame *frame = NULL; unsigned int i; + /* + * The response of the Elgato Cam Link 4K is incorrect: The second byte + * contains bFormatIndex (instead of being the second byte of bmHint). + * The first byte is always zero. The third byte is always 1. + * + * The UVC 1.5 class specification defines the first five bits in the + * bmHint bitfield. The remaining bits are reserved and should be zero. + * Therefore a valid bmHint will be less than 32. + */ + if (stream->dev->quirks & UVC_QUIRK_FIX_FORMAT_INDEX && ctrl->bmHint > 255) { + __u8 corrected_format_index; + + corrected_format_index = ctrl->bmHint >> 8; + uvc_dbg(stream->dev, CONTROL, + "Correct USB video probe response from {bmHint: 0x%04x, bFormatIndex: 0x%02x} to {bmHint: 0x%04x, bFormatIndex: 0x%02x}.\n", + ctrl->bmHint, ctrl->bFormatIndex, + ctrl->bFormatIndex, corrected_format_index); + ctrl->bmHint = ctrl->bFormatIndex; + ctrl->bFormatIndex = corrected_format_index; + } + for (i = 0; i < stream->nformats; ++i) { if (stream->format[i].index == ctrl->bFormatIndex) { format = &stream->format[i]; diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h index cce5e38133cd..cbb4ef61a64d 100644 --- a/drivers/media/usb/uvc/uvcvideo.h +++ b/drivers/media/usb/uvc/uvcvideo.h @@ -209,6 +209,7 @@ #define UVC_QUIRK_RESTORE_CTRLS_ON_INIT 0x00000400 #define UVC_QUIRK_FORCE_Y8 0x00000800 #define UVC_QUIRK_FORCE_BPP 0x00001000 +#define UVC_QUIRK_FIX_FORMAT_INDEX 0x00002000 /* Format flags */ #define UVC_FMT_FLAG_COMPRESSED 0x00000001 -- 2.27.0

3 years, 9 months

2
9
0 0

[PATCH] ALSA: firewire-lib: fix the context to call snd_pcm_stop_xrun()

by Takashi Sakamoto

In the workqueue to queue wake-up event, isochronous context is not processed, thus it's useless to check context for the workqueue to switch status of runtime for PCM substream to XRUN. On the other hand, in software IRQ context of 1394 OHCI, it's needed. This commit fixes the bug introduced when tasklet was replaced with workqueue. Cc: <stable(a)vger.kernel.org> Fixes: 2b3d2987d800 ("ALSA: firewire: Replace tasklet with work") Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- sound/firewire/amdtp-stream.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/firewire/amdtp-stream.c b/sound/firewire/amdtp-stream.c index 945597ffacc2..19c343c53585 100644 --- a/sound/firewire/amdtp-stream.c +++ b/sound/firewire/amdtp-stream.c @@ -1032,7 +1032,7 @@ static void generate_pkt_descs(struct amdtp_stream *s, const __be32 *ctx_header, static inline void cancel_stream(struct amdtp_stream *s) { s->packet_index = -1; - if (current_work() == &s->period_work) + if (in_interrupt()) amdtp_stream_pcm_abort(s); WRITE_ONCE(s->pcm_buffer_pointer, SNDRV_PCM_POS_XRUN); } -- 2.27.0

3 years, 9 months

2
1
0 0

[PATCH] fscrypt: fix derivation of SipHash keys on big endian CPUs

by Eric Biggers

From: Eric Biggers <ebiggers(a)google.com> Typically, the cryptographic APIs that fscrypt uses take keys as byte arrays, which avoids endianness issues. However, siphash_key_t is an exception. It is defined as 'u64 key[2];', i.e. the 128-bit key is expected to be given directly as two 64-bit words in CPU endianness. fscrypt_derive_dirhash_key() forgot to take this into account. Therefore, the SipHash keys used to index encrypted+casefolded directories differ on big endian vs. little endian platforms. This makes such directories non-portable between these platforms. Fix this by always using the little endian order. This is a breaking change for big endian platforms, but this should be fine in practice since the encrypt+casefold support isn't known to actually be used on any big endian platforms yet. Fixes: aa408f835d02 ("fscrypt: derive dirhash key for casefolded directories") Cc: <stable(a)vger.kernel.org> # v5.6+ Signed-off-by: Eric Biggers <ebiggers(a)google.com> --- fs/crypto/keysetup.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/fs/crypto/keysetup.c b/fs/crypto/keysetup.c index 261293fb7097..4d98377c07a7 100644 --- a/fs/crypto/keysetup.c +++ b/fs/crypto/keysetup.c @@ -221,6 +221,16 @@ int fscrypt_derive_dirhash_key(struct fscrypt_info *ci, sizeof(ci->ci_dirhash_key)); if (err) return err; + + /* + * The SipHash APIs expect the key as a pair of 64-bit words, not as a + * byte array. Make sure to use a consistent endianness. + */ + BUILD_BUG_ON(sizeof(ci->ci_dirhash_key) != 16); + BUILD_BUG_ON(ARRAY_SIZE(ci->ci_dirhash_key.key) != 2); + le64_to_cpus(&ci->ci_dirhash_key.key[0]); + le64_to_cpus(&ci->ci_dirhash_key.key[1]); + ci->ci_dirhash_key_initialized = true; return 0; } -- 2.32.0.rc0.204.g9fa02ecfa5-goog

3 years, 9 months

1
1
0 0

[PATCH] fscrypt: don't ignore minor_hash when hash is 0

by Eric Biggers

From: Eric Biggers <ebiggers(a)google.com> When initializing a no-key name, fscrypt_fname_disk_to_usr() sets the minor_hash to 0 if the (major) hash is 0. This doesn't make sense because 0 is a valid hash code, so we shouldn't ignore the filesystem-provided minor_hash in that case. Fix this by removing the special case for 'hash == 0'. This is an old bug that appears to have originated when the encryption code in ext4 and f2fs was moved into fs/crypto/. The original ext4 and f2fs code passed the hash by pointer instead of by value. So 'if (hash)' actually made sense then, as it was checking whether a pointer was NULL. But now the hashes are passed by value, and filesystems just pass 0 for any hashes they don't have. There is no need to handle this any differently from the hashes actually being 0. It is difficult to reproduce this bug, as it only made a difference in the case where a filename's 32-bit major hash happened to be 0. However, it probably had the largest chance of causing problems on ubifs, since ubifs uses minor_hash to do lookups of no-key names, in addition to using it as a readdir cookie. ext4 only uses minor_hash as a readdir cookie, and f2fs doesn't use minor_hash at all. Fixes: 0b81d0779072 ("fs crypto: move per-file encryption from f2fs tree to fs/crypto") Cc: <stable(a)vger.kernel.org> # v4.6+ Signed-off-by: Eric Biggers <ebiggers(a)google.com> --- fs/crypto/fname.c | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/fs/crypto/fname.c b/fs/crypto/fname.c index 6ca7d16593ff..d00455440d08 100644 --- a/fs/crypto/fname.c +++ b/fs/crypto/fname.c @@ -344,13 +344,9 @@ int fscrypt_fname_disk_to_usr(const struct inode *inode, offsetof(struct fscrypt_nokey_name, sha256)); BUILD_BUG_ON(BASE64_CHARS(FSCRYPT_NOKEY_NAME_MAX) > NAME_MAX); - if (hash) { - nokey_name.dirhash[0] = hash; - nokey_name.dirhash[1] = minor_hash; - } else { - nokey_name.dirhash[0] = 0; - nokey_name.dirhash[1] = 0; - } + nokey_name.dirhash[0] = hash; + nokey_name.dirhash[1] = minor_hash; + if (iname->len <= sizeof(nokey_name.bytes)) { memcpy(nokey_name.bytes, iname->name, iname->len); size = offsetof(struct fscrypt_nokey_name, bytes[iname->len]); base-commit: c4681547bcce777daf576925a966ffa824edd09d -- 2.32.0.rc0.204.g9fa02ecfa5-goog

3 years, 9 months

1
1
0 0

stable-rc/queue/4.14 baseline: 150 runs, 2 regressions (v4.14.235-1-gf40a5f239352)

by kernelci.org bot

stable-rc/queue/4.14 baseline: 150 runs, 2 regressions (v4.14.235-1-gf40a5f239352) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions ----------------+-------+--------------+----------+-----------+------------ fsl-ls2088a-rdb | arm64 | lab-nxp | gcc-8 | defconfig | 1 meson-gxm-q200 | arm64 | lab-baylibre | gcc-8 | defconfig | 1 Details: https://kernelci.org/test/job/stable-rc/branch/queue%2F4.14/kernel/v4.14.23… Test: baseline Tree: stable-rc Branch: queue/4.14 Describe: v4.14.235-1-gf40a5f239352 URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: f40a5f2393522ea484a6dc2525e0ce676b9ed7cf Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions ----------------+-------+--------------+----------+-----------+------------ fsl-ls2088a-rdb | arm64 | lab-nxp | gcc-8 | defconfig | 1 Details: https://kernelci.org/test/plan/id/60bac85f5aac9aae140c0e01 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-8 (aarch64-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.235-1-gf40a5f23935… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.235-1-gf40a5f23935… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-5-g2f114cc7… * baseline.login: https://kernelci.org/test/case/id/60bac85f5aac9aae140c0e02 new failure (last pass: v4.14.234-84-gd2294bde5706) platform | arch | lab | compiler | defconfig | regressions ----------------+-------+--------------+----------+-----------+------------ meson-gxm-q200 | arm64 | lab-baylibre | gcc-8 | defconfig | 1 Details: https://kernelci.org/test/plan/id/60bad20720eb0c595b0c0e11 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-8 (aarch64-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.235-1-gf40a5f23935… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.235-1-gf40a5f23935… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-5-g2f114cc7… * baseline.login: https://kernelci.org/test/case/id/60bad20720eb0c595b0c0e12 failing since 95 days (last pass: v4.14.222-11-g13b8482a0f700, first fail: v4.14.222-120-gdc8887cba23e)

3 years, 9 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2021