June 2020 - Linux-stable-mirror

[PATCH] nvme: validate cntlid's only for nvme >= 1.1.0

by Maximilian Heyne

Controller ID's (cntlid) for NVMe devices were introduced in version 1.1.0 of the specification. Controllers that follow the older 1.0.0 spec don't set this field so it doesn't make sense to validate it. On the contrary, when using SR-IOV this check breaks VFs as they are all part of the same NVMe subsystem. Signed-off-by: Maximilian Heyne <mheyne(a)amazon.de> Cc: <stable(a)vger.kernel.org> # 5.4+ --- drivers/nvme/host/core.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c index 28f4388c1337..c4a991acc949 100644 --- a/drivers/nvme/host/core.c +++ b/drivers/nvme/host/core.c @@ -2773,7 +2773,8 @@ static int nvme_init_subsystem(struct nvme_ctrl *ctrl, struct nvme_id_ctrl *id) put_device(&subsys->dev); subsys = found; - if (!nvme_validate_cntlid(subsys, ctrl, id)) { + if (ctrl->vs >= NVME_VS(1, 1, 0) && + !nvme_validate_cntlid(subsys, ctrl, id)) { ret = -EINVAL; goto out_put_subsystem; } @@ -2883,7 +2884,7 @@ int nvme_init_identify(struct nvme_ctrl *ctrl) goto out_free; } - if (!(ctrl->ops->flags & NVME_F_FABRICS)) + if (!(ctrl->ops->flags & NVME_F_FABRICS) && ctrl->vs >= NVME_VS(1, 1, 0)) ctrl->cntlid = le16_to_cpu(id->cntlid); if (!ctrl->identified) { -- 2.16.6 Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879

4 years, 6 months

3
4
0 0

[PATCH v4] btrfs: pass checksum type via BTRFS_IOC_FS_INFO ioctl

by Johannes Thumshirn

With the recent addition of filesystem checksum types other than CRC32c, it is not anymore hard-coded which checksum type a btrfs filesystem uses. Up to now there is no good way to read the filesystem checksum, apart from reading the filesystem UUID and then query sysfs for the checksum type. Add a new csum_type and csum_size fields to the BTRFS_IOC_FS_INFO ioctl command which usually is used to query filesystem features. Also add a flags member indicating that the kernel responded with a set csum_type and csum_size field. For compatibility reasons, only return the csum_type and csum_size if the BTRFS_FS_INFO_FLAG_CSUM_TYPE_SIZE flag was passed to the kernel. Also clear any unknown flags so we don't pass false positives to user-space newer than the kernel. To simplify further additions to the ioctl, also switch the padding to a u8 array. Pahole was used to verify the result of this switch: pahole -C btrfs_ioctl_fs_info_args fs/btrfs/btrfs.ko struct btrfs_ioctl_fs_info_args { __u64 max_id; /* 0 8 */ __u64 num_devices; /* 8 8 */ __u8 fsid[16]; /* 16 16 */ __u32 nodesize; /* 32 4 */ __u32 sectorsize; /* 36 4 */ __u32 clone_alignment; /* 40 4 */ __u32 flags; /* 44 4 */ __u16 csum_type; /* 48 2 */ __u16 csum_size; /* 50 2 */ __u8 reserved[972]; /* 52 972 */ /* size: 1024, cachelines: 16, members: 10 */ }; Fixes: 3951e7f050ac ("btrfs: add xxhash64 to checksumming algorithms") Fixes: 3831bf0094ab ("btrfs: add sha256 to checksumming algorithm") CC: stable(a)vger.kernel.org # 5.5+ Signed-off-by: Johannes Thumshirn <johannes.thumshirn(a)wdc.com> --- Changes to v3: * make flags in/out (David) * make csum return opt-in (Hans) Changes to v2: * add additional csum_size (David) * rename flag value to BTRFS_FS_INFO_FLAG_CSUM_TYPE_SIZE to reflect additional size Changes to v1: * add 'out' comment to be consistent (Hans) * remove le16_to_cpu() (kbuild robot) * switch padding to be all u8 (David) --- fs/btrfs/ioctl.c | 16 +++++++++++++--- include/uapi/linux/btrfs.h | 14 ++++++++++++-- 2 files changed, 25 insertions(+), 5 deletions(-) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index b3e4c632d80c..4d70b918f656 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -3198,11 +3198,15 @@ static long btrfs_ioctl_fs_info(struct btrfs_fs_info *fs_info, struct btrfs_ioctl_fs_info_args *fi_args; struct btrfs_device *device; struct btrfs_fs_devices *fs_devices = fs_info->fs_devices; + u32 inflags; int ret = 0; - fi_args = kzalloc(sizeof(*fi_args), GFP_KERNEL); - if (!fi_args) - return -ENOMEM; + fi_args = memdup_user(arg, sizeof(*fi_args)); + if (IS_ERR(fi_args)) + return PTR_ERR(fi_args); + + inflags = fi_args->flags; + fi_args->flags = 0; rcu_read_lock(); fi_args->num_devices = fs_devices->num_devices; @@ -3218,6 +3222,12 @@ static long btrfs_ioctl_fs_info(struct btrfs_fs_info *fs_info, fi_args->sectorsize = fs_info->sectorsize; fi_args->clone_alignment = fs_info->sectorsize; + if (inflags & BTRFS_FS_INFO_FLAG_CSUM_TYPE_SIZE) { + fi_args->csum_type = btrfs_super_csum_type(fs_info->super_copy); + fi_args->csum_size = btrfs_super_csum_size(fs_info->super_copy); + fi_args->flags |= BTRFS_FS_INFO_FLAG_CSUM_TYPE_SIZE; + } + if (copy_to_user(arg, fi_args, sizeof(*fi_args))) ret = -EFAULT; diff --git a/include/uapi/linux/btrfs.h b/include/uapi/linux/btrfs.h index e6b6cb0f8bc6..c130eaea416e 100644 --- a/include/uapi/linux/btrfs.h +++ b/include/uapi/linux/btrfs.h @@ -250,10 +250,20 @@ struct btrfs_ioctl_fs_info_args { __u32 nodesize; /* out */ __u32 sectorsize; /* out */ __u32 clone_alignment; /* out */ - __u32 reserved32; - __u64 reserved[122]; /* pad to 1k */ + __u32 flags; /* in/out */ + __u16 csum_type; /* out */ + __u16 csum_size; /* out */ + __u8 reserved[972]; /* pad to 1k */ }; +/* + * fs_info ioctl flags + * + * Used by: + * struct btrfs_ioctl_fs_info_args + */ +#define BTRFS_FS_INFO_FLAG_CSUM_TYPE_SIZE (1 << 0) + /* * feature flags * -- 2.26.2

4 years, 6 months

3
3
0 0

[tip: x86/urgent] x86/split_lock: Don't write MSR_TEST_CTRL on CPUs that aren't whitelisted

by tip-bot2 for Sean Christopherson

The following commit has been merged into the x86/urgent branch of tip: Commit-ID: 009bce1df0bb5eb970b9eb98d963861f7fe353c7 Gitweb: https://git.kernel.org/tip/009bce1df0bb5eb970b9eb98d963861f7fe353c7 Author: Sean Christopherson <sean.j.christopherson(a)intel.com> AuthorDate: Fri, 05 Jun 2020 12:26:05 -07:00 Committer: Thomas Gleixner <tglx(a)linutronix.de> CommitterDate: Tue, 30 Jun 2020 14:09:31 +02:00 x86/split_lock: Don't write MSR_TEST_CTRL on CPUs that aren't whitelisted Choo! Choo! All aboard the Split Lock Express, with direct service to Wreckage! Skip split_lock_verify_msr() if the CPU isn't whitelisted as a possible SLD-enabled CPU model to avoid writing MSR_TEST_CTRL. MSR_TEST_CTRL exists, and is writable, on many generations of CPUs. Writing the MSR, even with '0', can result in bizarre, undocumented behavior. This fixes a crash on Haswell when resuming from suspend with a live KVM guest. Because APs use the standard SMP boot flow for resume, they will go through split_lock_init() and the subsequent RDMSR/WRMSR sequence, which runs even when sld_state==sld_off to ensure SLD is disabled. On Haswell (at least, my Haswell), writing MSR_TEST_CTRL with '0' will succeed and _may_ take the SMT _sibling_ out of VMX root mode. When KVM has an active guest, KVM performs VMXON as part of CPU onlining (see kvm_starting_cpu()). Because SMP boot is serialized, the resulting flow is effectively: on_each_ap_cpu() { WRMSR(MSR_TEST_CTRL, 0) VMXON } As a result, the WRMSR can disable VMX on a different CPU that has already done VMXON. This ultimately results in a #UD on VMPTRLD when KVM regains control and attempt run its vCPUs. The above voodoo was confirmed by reworking KVM's VMXON flow to write MSR_TEST_CTRL prior to VMXON, and to serialize the sequence as above. Further verification of the insanity was done by redoing VMXON on all APs after the initial WRMSR->VMXON sequence. The additional VMXON, which should VM-Fail, occasionally succeeded, and also eliminated the unexpected #UD on VMPTRLD. The damage done by writing MSR_TEST_CTRL doesn't appear to be limited to VMX, e.g. after suspend with an active KVM guest, subsequent reboots almost always hang (even when fudging VMXON), a #UD on a random Jcc was observed, suspend/resume stability is qualitatively poor, and so on and so forth. kernel BUG at arch/x86/kvm/x86.c:386! CPU: 1 PID: 2592 Comm: CPU 6/KVM Tainted: G D Hardware name: ASUS Q87M-E/Q87M-E, BIOS 1102 03/03/2014 RIP: 0010:kvm_spurious_fault+0xf/0x20 Call Trace: vmx_vcpu_load_vmcs+0x1fb/0x2b0 vmx_vcpu_load+0x3e/0x160 kvm_arch_vcpu_load+0x48/0x260 finish_task_switch+0x140/0x260 __schedule+0x460/0x720 _cond_resched+0x2d/0x40 kvm_arch_vcpu_ioctl_run+0x82e/0x1ca0 kvm_vcpu_ioctl+0x363/0x5c0 ksys_ioctl+0x88/0xa0 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x4c/0x170 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: dbaba47085b0c ("x86/split_lock: Rework the initialization flow of split lock detection") Signed-off-by: Sean Christopherson <sean.j.christopherson(a)intel.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Link: https://lkml.kernel.org/r/20200605192605.7439-1-sean.j.christopherson@intel… --- arch/x86/kernel/cpu/intel.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c index c25a67a..0ab48f1 100644 --- a/arch/x86/kernel/cpu/intel.c +++ b/arch/x86/kernel/cpu/intel.c @@ -50,6 +50,13 @@ static enum split_lock_detect_state sld_state __ro_after_init = sld_off; static u64 msr_test_ctrl_cache __ro_after_init; /* + * With a name like MSR_TEST_CTL it should go without saying, but don't touch + * MSR_TEST_CTL unless the CPU is one of the whitelisted models. Writing it + * on CPUs that do not support SLD can cause fireworks, even when writing '0'. + */ +static bool cpu_model_supports_sld __ro_after_init; + +/* * Processors which have self-snooping capability can handle conflicting * memory type across CPUs by snooping its own cache. However, there exists * CPU models in which having conflicting memory types still leads to @@ -1071,7 +1078,8 @@ static void sld_update_msr(bool on) static void split_lock_init(void) { - split_lock_verify_msr(sld_state != sld_off); + if (cpu_model_supports_sld) + split_lock_verify_msr(sld_state != sld_off); } static void split_lock_warn(unsigned long ip) @@ -1177,5 +1185,6 @@ void __init cpu_set_core_cap_bits(struct cpuinfo_x86 *c) return; } + cpu_model_supports_sld = true; split_lock_setup(); }

4 years, 6 months

1
0
0 0

[PATCH 08/10] mfd: atmel-smc: Silence comparison of unsigned expression < 0 is always false warning (W=1)

by Lee Jones

GENMASK and it's callees conduct checking to ensure the passed parameters are valid. One of those checks is for '< 0'. So if an unsigned value is passed, in an invalid comparison takes place. Judging from the current code, it looks as though 'unsigned int' is the correct type to use, so simply cast these small values with no chance of being false negative to signed int for comparison/error checking purposes. Squashes the following W=1 warnings: In file included from /home/lee/projects/linux/kernel/include/linux/bits.h:23, from /home/lee/projects/linux/kernel/include/linux/bitops.h:5, from /home/lee/projects/linux/kernel/include/linux/kernel.h:12, from /home/lee/projects/linux/kernel/include/linux/mfd/syscon/atmel-smc.h:14, from /home/lee/projects/linux/kernel/drivers/mfd/atmel-smc.c:11: /home/lee/projects/linux/kernel/drivers/mfd/atmel-smc.c: In function ‘atmel_smc_cs_encode_ncycles’: /home/lee/projects/linux/kernel/include/linux/bits.h:26:28: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits] 26 | __builtin_constant_p((l) > (h)), (l) > (h), 0))) | ^ /home/lee/projects/linux/kernel/include/linux/build_bug.h:16:62: note: in definition of macro ‘BUILD_BUG_ON_ZERO’ 16 | #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); }))) | ^ /home/lee/projects/linux/kernel/include/linux/bits.h:39:3: note: in expansion of macro ‘GENMASK_INPUT_CHECK’ 39 | (GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l)) | ^~~~~~~~~~~~~~~~~~~ /home/lee/projects/linux/kernel/drivers/mfd/atmel-smc.c:49:25: note: in expansion of macro ‘GENMASK’ 49 | unsigned int lsbmask = GENMASK(msbpos - 1, 0); | ^~~~~~~ /home/lee/projects/linux/kernel/include/linux/bits.h:26:40: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits] 26 | __builtin_constant_p((l) > (h)), (l) > (h), 0))) | ^ /home/lee/projects/linux/kernel/include/linux/build_bug.h:16:62: note: in definition of macro ‘BUILD_BUG_ON_ZERO’ 16 | #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); }))) | ^ /home/lee/projects/linux/kernel/include/linux/bits.h:39:3: note: in expansion of macro ‘GENMASK_INPUT_CHECK’ 39 | (GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l)) | ^~~~~~~~~~~~~~~~~~~ Cc: <stable(a)vger.kernel.org> Cc: Nicolas Ferre <nicolas.ferre(a)microchip.com> Cc: Alexandre Belloni <alexandre.belloni(a)bootlin.com> Cc: Ludovic Desroches <ludovic.desroches(a)microchip.com> Cc: Boris Brezillon <boris.brezillon(a)free-electrons.com> Signed-off-by: Lee Jones <lee.jones(a)linaro.org> --- drivers/mfd/atmel-smc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mfd/atmel-smc.c b/drivers/mfd/atmel-smc.c index 1fa2ec950e7df..17bbe9d1fa740 100644 --- a/drivers/mfd/atmel-smc.c +++ b/drivers/mfd/atmel-smc.c @@ -46,8 +46,8 @@ static int atmel_smc_cs_encode_ncycles(unsigned int ncycles, unsigned int msbfactor, unsigned int *encodedval) { - unsigned int lsbmask = GENMASK(msbpos - 1, 0); - unsigned int msbmask = GENMASK(msbwidth - 1, 0); + unsigned int lsbmask = GENMASK((int)msbpos - 1, 0); + unsigned int msbmask = GENMASK((int)msbwidth - 1, 0); unsigned int msb, lsb; int ret = 0; -- 2.25.1

4 years, 6 months

2
2
0 0

[PATCH v2 05/10] drm/ingenic: Fix incorrect assumption about plane->index

by Paul Cercueil

plane->index is NOT the index of the color plane in a YUV frame. Actually, a YUV frame is represented by a single drm_plane, even though it contains three Y, U, V planes. Cc: stable(a)vger.kernel.org # v5.3 Fixes: 90b86fcc47b4 ("DRM: Add KMS driver for the Ingenic JZ47xx SoCs") Signed-off-by: Paul Cercueil <paul(a)crapouillou.net> --- Notes: v2: No change drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c index a15f9a1940c6..924c8daf071a 100644 --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c @@ -386,7 +386,7 @@ static void ingenic_drm_plane_atomic_update(struct drm_plane *plane, addr = drm_fb_cma_get_gem_addr(state->fb, state, 0); width = state->src_w >> 16; height = state->src_h >> 16; - cpp = state->fb->format->cpp[plane->index]; + cpp = state->fb->format->cpp[0]; priv->dma_hwdesc->addr = addr; priv->dma_hwdesc->cmd = width * height * cpp / 4; -- 2.27.0

4 years, 6 months

2
1
0 0

[PATCH] KVM: x86: bit 8 of non-leaf PDPEs is not reserved

by Paolo Bonzini

Bit 8 would be the "global" bit, which does not quite make sense for non-leaf page table entries. Intel ignores it; AMD ignores it in PDEs and PDPEs, but reserves it in PML4Es. Probably, earlier versions of the AMD manual documented it as reserved in PDPEs as well, and that behavior made it into KVM as well as kvm-unit-tests; fix it. Cc: stable(a)vger.kernel.org Reported-by: Nadav Amit <namit(a)vmware.com> Fixes: a0c0feb57992 ("KVM: x86: reserve bit 8 of non-leaf PDPEs and PML4Es in 64-bit mode on AMD", 2014-09-03) Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> --- arch/x86/kvm/mmu/mmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index 76817d13c86e..6d6a0ae7800c 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -4449,7 +4449,7 @@ __reset_rsvds_bits_mask(struct kvm_vcpu *vcpu, nonleaf_bit8_rsvd | rsvd_bits(7, 7) | rsvd_bits(maxphyaddr, 51); rsvd_check->rsvd_bits_mask[0][2] = exb_bit_rsvd | - nonleaf_bit8_rsvd | gbpages_bit_rsvd | + gbpages_bit_rsvd | rsvd_bits(maxphyaddr, 51); rsvd_check->rsvd_bits_mask[0][1] = exb_bit_rsvd | rsvd_bits(maxphyaddr, 51); -- 2.26.2

4 years, 6 months

1
0
0 0

[tip: irq/urgent] irqchip/gic: Atomically update affinity

by tip-bot2 for Marc Zyngier

The following commit has been merged into the irq/urgent branch of tip: Commit-ID: 005c34ae4b44f085120d7f371121ec7ded677761 Gitweb: https://git.kernel.org/tip/005c34ae4b44f085120d7f371121ec7ded677761 Author: Marc Zyngier <maz(a)kernel.org> AuthorDate: Sun, 21 Jun 2020 14:43:15 +01:00 Committer: Marc Zyngier <maz(a)kernel.org> CommitterDate: Sun, 21 Jun 2020 15:24:46 +01:00 irqchip/gic: Atomically update affinity The GIC driver uses a RMW sequence to update the affinity, and relies on the gic_lock_irqsave/gic_unlock_irqrestore sequences to update it atomically. But these sequences only expand into anything meaningful if the BL_SWITCHER option is selected, which almost never happens. It also turns out that using a RMW and locks is just as silly, as the GIC distributor supports byte accesses for the GICD_TARGETRn registers, which when used make the update atomic by definition. Drop the terminally broken code and replace it by a byte write. Fixes: 04c8b0f82c7d ("irqchip/gic: Make locking a BL_SWITCHER only feature") Cc: stable(a)vger.kernel.org Signed-off-by: Marc Zyngier <maz(a)kernel.org> --- drivers/irqchip/irq-gic.c | 14 +++----------- 1 file changed, 3 insertions(+), 11 deletions(-) diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c index 00de05a..c17fabd 100644 --- a/drivers/irqchip/irq-gic.c +++ b/drivers/irqchip/irq-gic.c @@ -329,10 +329,8 @@ static int gic_irq_set_vcpu_affinity(struct irq_data *d, void *vcpu) static int gic_set_affinity(struct irq_data *d, const struct cpumask *mask_val, bool force) { - void __iomem *reg = gic_dist_base(d) + GIC_DIST_TARGET + (gic_irq(d) & ~3); - unsigned int cpu, shift = (gic_irq(d) % 4) * 8; - u32 val, mask, bit; - unsigned long flags; + void __iomem *reg = gic_dist_base(d) + GIC_DIST_TARGET + gic_irq(d); + unsigned int cpu; if (!force) cpu = cpumask_any_and(mask_val, cpu_online_mask); @@ -342,13 +340,7 @@ static int gic_set_affinity(struct irq_data *d, const struct cpumask *mask_val, if (cpu >= NR_GIC_CPU_IF || cpu >= nr_cpu_ids) return -EINVAL; - gic_lock_irqsave(flags); - mask = 0xff << shift; - bit = gic_cpu_map[cpu] << shift; - val = readl_relaxed(reg) & ~mask; - writel_relaxed(val | bit, reg); - gic_unlock_irqrestore(flags); - + writeb_relaxed(gic_cpu_map[cpu], reg); irq_data_update_effective_affinity(d, cpumask_of(cpu)); return IRQ_SET_MASK_OK_DONE;

4 years, 6 months

1
0
0 0

[PATCH v3] btrfs: pass checksum type via BTRFS_IOC_FS_INFO ioctl

by Johannes Thumshirn

With the recent addition of filesystem checksum types other than CRC32c, it is not anymore hard-coded which checksum type a btrfs filesystem uses. Up to now there is no good way to read the filesystem checksum, apart from reading the filesystem UUID and then query sysfs for the checksum type. Add a new csum_type field to the BTRFS_IOC_FS_INFO ioctl command which usually is used to query filesystem features. Also add a flags member indicating that the kernel responded with a set csum_type field. To simplify further additions to the ioctl, also switch the padding to a u8 array. Pahole was used to verify the result of this switch: pahole -C btrfs_ioctl_fs_info_args fs/btrfs/btrfs.ko struct btrfs_ioctl_fs_info_args { __u64 max_id; /* 0 8 */ __u64 num_devices; /* 8 8 */ __u8 fsid[16]; /* 16 16 */ __u32 nodesize; /* 32 4 */ __u32 sectorsize; /* 36 4 */ __u32 clone_alignment; /* 40 4 */ __u32 flags; /* 44 4 */ __u16 csum_type; /* 48 2 */ __u16 csum_size; /* 50 2 */ __u8 reserved[972]; /* 52 972 */ /* size: 1024, cachelines: 16, members: 10 */ }; Fixes: 3951e7f050ac ("btrfs: add xxhash64 to checksumming algorithms") Fixes: 3831bf0094ab ("btrfs: add sha256 to checksumming algorithm") Cc: stable(a)vger.kernel.org Signed-off-by: Johannes Thumshirn <johannes.thumshirn(a)wdc.com> --- Changes to v2: * add additional csum_size (David) * rename flag value to BTRFS_FS_INFO_FLAG_CSUM_TYPE_SIZE to reflect additional size Changes to v1: * add 'out' comment to be consistent (Hans) * remove le16_to_cpu() (kbuild robot) * switch padding to be all u8 (David) --- fs/btrfs/ioctl.c | 3 +++ include/uapi/linux/btrfs.h | 14 ++++++++++++-- 2 files changed, 15 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index b3e4c632d80c..cfedcdf446c3 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -3217,6 +3217,9 @@ static long btrfs_ioctl_fs_info(struct btrfs_fs_info *fs_info, fi_args->nodesize = fs_info->nodesize; fi_args->sectorsize = fs_info->sectorsize; fi_args->clone_alignment = fs_info->sectorsize; + fi_args->csum_type = btrfs_super_csum_type(fs_info->super_copy); + fi_args->csum_size = btrfs_super_csum_size(fs_info->super_copy); + fi_args->flags |= BTRFS_FS_INFO_FLAG_CSUM_TYPE_SIZE; if (copy_to_user(arg, fi_args, sizeof(*fi_args))) ret = -EFAULT; diff --git a/include/uapi/linux/btrfs.h b/include/uapi/linux/btrfs.h index e6b6cb0f8bc6..2de3ef3c5c71 100644 --- a/include/uapi/linux/btrfs.h +++ b/include/uapi/linux/btrfs.h @@ -250,10 +250,20 @@ struct btrfs_ioctl_fs_info_args { __u32 nodesize; /* out */ __u32 sectorsize; /* out */ __u32 clone_alignment; /* out */ - __u32 reserved32; - __u64 reserved[122]; /* pad to 1k */ + __u32 flags; /* out */ + __u16 csum_type; /* out */ + __u16 csum_size; /* out */ + __u8 reserved[972]; /* pad to 1k */ }; +/* + * fs_info ioctl flags + * + * Used by: + * struct btrfs_ioctl_fs_info_args + */ +#define BTRFS_FS_INFO_FLAG_CSUM_TYPE_SIZE (1 << 0) + /* * feature flags * -- 2.26.2

4 years, 6 months

4
6
0 0

External kmod build failed on KASAN-enabled kernel

by richard clark

Hi, The same kmod source code can be built on KASAN-disabled kernel (5.7.0), but after enable it with CONFIG_KASAN=y, the kmod can't build on the new installed KASAN-enabled kernel with below error message, seems no relevant answers for this issue with google: root@build-ws:/home/mm/slab# make make -C /lib/modules/5.7.0/build M=/home/mm/slab modules make[1]: Entering directory '/home/linux-5.7' CC [M] /home/mm/slab/tap_slab.o MODPOST 1 modules ERROR: modpost: "__asan_register_globals" [/home/mm/slab/tap_slab.ko] undefined! ERROR: modpost: "__asan_unregister_globals" [/home/mm/slab/tap_slab.ko] undefined! ERROR: modpost: "__asan_load8_noabort" [/home/mm/slab/tap_slab.ko] undefined! scripts/Makefile.modpost:94: recipe for target '__modpost' failed make[2]: *** [__modpost] Error 1 Makefile:1642: recipe for target 'modules' failed make[1]: *** [modules] Error 2 make[1]: Leaving directory '/home/linux-5.7' Makefile:6: recipe for target 'default' failed make: *** [default] Error 2 === Regards, Richard

4 years, 6 months

1
0
0 0

Re: Upstream fixes not merged in 5.4.y

by Greg KH

On Mon, Jun 29, 2020 at 04:28:05PM +0200, SeongJae Park wrote: > Hello, > > > With my little script, I found below commits in the mainline tree are more than > 1 week old and fixing commits that back-ported in v5.4..v5.4.49, but not merged > in the stable/linux-5.4.y tree. Are those need to be merged in but missed or > dealyed? > > 9210c075cef2 ("nvme-pci: avoid race between nvme_reap_pending_cqes() and nvme_poll()") > 9fecd13202f5 ("btrfs: fix a block group ref counter leak after failure to remove block group") > 9d964e1b82d8 ("fix a braino in "sparc32: fix register window handling in genregs32_[gs]et()"") > 8ab3a3812aa9 ("drm/i915/gt: Incrementally check for rewinding") > 6e2f83884c09 ("bnxt_en: Fix AER reset logic on 57500 chips.") > efb94790852a ("drm/panel-simple: fix connector type for LogicPD Type28 Display") > ff58bbc7b970 ("ALSA: usb-audio: Fix potential use-after-free of streams") > ff58bbc7b970 ("ALSA: usb-audio: Fix potential use-after-free of streams") > 8dbe4c5d5e40 ("net: dsa: bcm_sf2: Fix node reference count") > ca8826095e4d ("selftests/net: report etf errors correctly") > 5a8d7f126c97 ("of: of_mdio: Correct loop scanning logic") > d35d3660e065 ("binder: fix null deref of proc->context") > > The script found several more commits but I exclude those here, because those > seems not applicable on 5.4.y or fixing trivial problems only. If I'm not > following a proper process for this kind of reports, please let me know. For commits that only have a "Fixes:" tag, and not a "cc: stable..." tag, wait a few weeks, or a month, for us to catch up with them. We usually get to them eventually, but it takes us a while as we have lots more to deal with by developers and maintainers that are properly tagging patches for this type of thing. Some of the above commits are queued up already, but not all of them. I'll take a look at the list after this next round of patches go out, and will let you know. And yes, we do want this type of list, it's greatly appreciated. thanks, greg k-h

4 years, 6 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2020