- Linux-stable-mirror - lists.linaro.org

[PATCH 1/2] btrfs: scrub: Don't use inode pages for device replace

by Qu Wenruo

[BUG] Btrfs can easily create compressed extent without checksum (even though it shouldn't), and if we then try to replace device containing such extent, the result device will contain all the uncompressed data instead of the compressed one. Test case already submitted to fstests: https://patchwork.kernel.org/patch/10442353/ [CAUSE] When handling compressed extent without checksum, device replace will goes into copy_nocow_pages() function. In that function, btrfs will get all inodes referring to this data extents and then use find_or_create_page() to get pages direct from that inode. The problem here is, pages directly from inode are always uncompressed. And for compressed data extent, they mismatch with on-disk data. Thus this leads to corrupted data extent written to replace device. [FIX] In this patch, we could just avoid the "optimization" branch, and let unified scrub_pages() to handle it. Although scrub_pages() won't bother reusing page cache, thus it will be a little slower, but it does the correct csum checking (skipped in this case) and won't cause such data corruption cause by "optimization". Please note that, this patch will just avoid the copy_nocow_pages(), while still leave related functions here, to make it small enough for a late merge window. Full functions removal will happen later. Fixes: Fixes: ff023aac3119 ("Btrfs: add code to scrub to copy read data to another disk") Cc: stable(a)vger.kernel.org Reported-by: James Harvey <jamespharvey20(a)gmail.com> Signed-off-by: Qu Wenruo <wqu(a)suse.com> --- changlog: v1: Split the RFC ver.B patch into 2 patches, the smaller fix will be easier to get merged for late merge window. --- fs/btrfs/scrub.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c index 52b39a0924e9..79e154575366 100644 --- a/fs/btrfs/scrub.c +++ b/fs/btrfs/scrub.c @@ -2799,7 +2799,16 @@ static int scrub_extent(struct scrub_ctx *sctx, struct map_lookup *map, have_csum = scrub_find_csum(sctx, logical, csum); if (have_csum == 0) ++sctx->stat.no_csum; - if (sctx->is_dev_replace && !have_csum) { + + /* + * For replace on nodatasum extent, don't use + * copy_nocow_pages() routine which will copy pages + * from inode to disk. It could cause deadly corruption + * for compressed extent. + * NOTE: copy_nocow_pages() and all its children will + * be removed later. + */ + if (0 && sctx->is_dev_replace && !have_csum) { ret = copy_nocow_pages(sctx, logical, l, mirror_num, physical_for_dev_replace); -- 2.17.1

7 years, 1 month

1
0
0 0

[PATCH V5] scsi: hpsa: disable device during shutdown

by Sinan Kaya

'Commit cc27b735ad3a ("PCI/portdrv: Turn off PCIe services during shutdown")' has been added to kernel to shutdown pending PCIe port service interrupts during reboot so that a newly started kexec kernel wouldn't observe pending interrupts. pcie_port_device_remove() is disabling the root port and switches by calling pci_disable_device() after all PCIe service drivers are shutdown. This has been found to cause crashes on HP DL360 Gen9 machines during reboot due to hpsa driver not clearing the bus master bit during the shutdown procedure by calling pci_disable_device(). Disable device as part of the shutdown sequence. Signed-off-by: Sinan Kaya <okaya(a)codeaurora.org> Link: https://bugzilla.kernel.org/show_bug.cgi?id=199779 Fixes: cc27b735ad3a ("PCI/portdrv: Turn off PCIe services during shutdown") Cc: stable(a)vger.kernel.org Reported-by: Ryan Finnie <ryan(a)finnie.org> Tested-by: Don Brace <don.brace(a)microsemi.com> Acked-by: Don Brace <don.brace(a)microsemi.com> --- drivers/scsi/hpsa.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c index 3a9eca1..b92f86a 100644 --- a/drivers/scsi/hpsa.c +++ b/drivers/scsi/hpsa.c @@ -8869,7 +8869,7 @@ static void hpsa_disable_rld_caching(struct ctlr_info *h) kfree(options); } -static void hpsa_shutdown(struct pci_dev *pdev) +static void __hpsa_shutdown(struct pci_dev *pdev) { struct ctlr_info *h; @@ -8884,6 +8884,12 @@ static void hpsa_shutdown(struct pci_dev *pdev) hpsa_disable_interrupt_mode(h); /* pci_init 2 */ } +static void hpsa_shutdown(struct pci_dev *pdev) +{ + __hpsa_shutdown(pdev); + pci_disable_device(pdev); +} + static void hpsa_free_device_info(struct ctlr_info *h) { int i; @@ -8927,7 +8933,7 @@ static void hpsa_remove_one(struct pci_dev *pdev) scsi_remove_host(h->scsi_host); /* init_one 8 */ /* includes hpsa_free_irqs - init_one 4 */ /* includes hpsa_disable_interrupt_mode - pci_init 2 */ - hpsa_shutdown(pdev); + __hpsa_shutdown(pdev); hpsa_free_device_info(h); /* scan */ -- 2.7.4

7 years, 1 month

2
1
0 0

[PATCH 4/8] Drivers: hv: vmbus: Fix the offer_in_progress in vmbus_process_offer()

by kys＠linuxonhyperv.com

From: Dexuan Cui <decui(a)microsoft.com> I didn't really hit a real bug, but just happened to spot the bug: we have decreased the counter at the beginning of vmbus_process_offer(), so we mustn't decrease it again. Fixes: 6f3d791f3006 ("Drivers: hv: vmbus: Fix rescind handling issues") Signed-off-by: Dexuan Cui <decui(a)microsoft.com> Cc: stable(a)vger.kernel.org Cc: Stephen Hemminger <sthemmin(a)microsoft.com> Cc: K. Y. Srinivasan <kys(a)microsoft.com> Cc: Stable <stable(a)vger.kernel.org> # 4.14 and above Signed-off-by: K. Y. Srinivasan <kys(a)microsoft.com> --- drivers/hv/channel_mgmt.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c index ecc2bd275a73..f3b551a50653 100644 --- a/drivers/hv/channel_mgmt.c +++ b/drivers/hv/channel_mgmt.c @@ -527,10 +527,8 @@ static void vmbus_process_offer(struct vmbus_channel *newchannel) struct hv_device *dev = newchannel->primary_channel->device_obj; - if (vmbus_add_channel_kobj(dev, newchannel)) { - atomic_dec(&vmbus_connection.offer_in_progress); + if (vmbus_add_channel_kobj(dev, newchannel)) goto err_free_chan; - } if (channel->sc_creation_callback != NULL) channel->sc_creation_callback(newchannel); -- 2.17.1

7 years, 1 month

1
0
0 0

[Patch net v2] netdev-FAQ: clarify DaveM's position for stable backports

by Cong Wang

Per discussion with David at netconf 2018, let's clarify DaveM's position of handling stable backports in netdev-FAQ. This is important for people relying on upstream -stable releases. Cc: stable(a)vger.kernel.org Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com> --- Documentation/networking/netdev-FAQ.txt | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/Documentation/networking/netdev-FAQ.txt b/Documentation/networking/netdev-FAQ.txt index 2a3278d5cf35..fa951b820b25 100644 --- a/Documentation/networking/netdev-FAQ.txt +++ b/Documentation/networking/netdev-FAQ.txt @@ -179,6 +179,15 @@ A: No. See above answer. In short, if you think it really belongs in dash marker line as described in Documentation/process/submitting-patches.rst to temporarily embed that information into the patch that you send. +Q: Are all networking bug fixes backported to all stable releases? + +A: Due to capacity, Dave could only take care of the backports for the last + 2 stable releases. For earlier stable releases, each stable branch maintainer + is supposed to take care of them. If you find any patch is missing from an + earlier stable branch, please notify stable(a)vger.kernel.org with either a + commit ID or a formal patch backported, and CC Dave and other relevant + networking developers. + Q: Someone said that the comment style and coding convention is different for the networking content. Is this true? -- 2.13.0

7 years, 1 month

2
1
0 0

[PATCH v3 2/2] tpm: self test failure should not cause suspend to fail

by Jarkko Sakkinen

From: Chris Chiu <chiu(a)endlessm.com> commit 0803d7befa15cab5717d667a97a66214d2a4c083 upstream The Acer Acer Veriton X4110G has a TPM device detected as: tpm_tis 00:0b: 1.2 TPM (device-id 0xFE, rev-id 71) After the first S3 suspend, the following error appears during resume: tpm tpm0: A TPM error(38) occurred continue selftest Any following S3 suspend attempts will now fail with this error: tpm tpm0: Error (38) sending savestate before suspend PM: Device 00:0b failed to suspend: error 38 Error 38 is TPM_ERR_INVALID_POSTINIT which means the TPM is not in the correct state. This indicates that the platform BIOS is not sending the usual TPM_Startup command during S3 resume. >From this point onwards, all TPM commands will fail. The same issue was previously reported on Foxconn 6150BK8MC and Sony Vaio TX3. The platform behaviour seems broken here, but we should not break suspend/resume because of this. When the unexpected TPM state is encountered, set a flag to skip the affected TPM_SaveState command on later suspends. Cc: stable(a)vger.kernel.org Signed-off-by: Chris Chiu <chiu(a)endlessm.com> Signed-off-by: Daniel Drake <drake(a)endlessm.com> Link: http://lkml.kernel.org/r/CAB4CAwfSCvj1cudi+MWaB5g2Z67d9DwY1o475YOZD64ma23Ui… Link: https://lkml.org/lkml/2011/3/28/192 Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591031 Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> --- drivers/char/tpm/tpm-interface.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c index 247dd2b6504a..be0547115d34 100644 --- a/drivers/char/tpm/tpm-interface.c +++ b/drivers/char/tpm/tpm-interface.c @@ -787,6 +787,10 @@ int tpm_do_selftest(struct tpm_chip *chip) loops = jiffies_to_msecs(duration) / delay_msec; rc = tpm_continue_selftest(chip); + if (rc == TPM_ERR_INVALID_POSTINIT) { + chip->flags |= TPM_CHIP_FLAG_ALWAYS_POWERED; + dev_info(&chip->dev, "TPM not ready (%d)\n", rc); + } /* This may fail if there was no TPM driver during a suspend/resume * cycle; some may return 10 (BAD_ORDINAL), others 28 (FAILEDSELFTEST) */ -- 2.17.0

7 years, 1 month

1
0
0 0

[Patch net-next] netdev-FAQ: clarify DaveM's position for stable backports

by Cong Wang

Per discussion with David at netconf 2018, let's clarify DaveM's position of handling stable backports in netdev-FAQ. This is important for people relying on upstream -stable releases. Cc: stable(a)vger.kernel.org Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com> --- Documentation/networking/netdev-FAQ.txt | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/Documentation/networking/netdev-FAQ.txt b/Documentation/networking/netdev-FAQ.txt index 2a3278d5cf35..6dde6686c870 100644 --- a/Documentation/networking/netdev-FAQ.txt +++ b/Documentation/networking/netdev-FAQ.txt @@ -179,6 +179,15 @@ A: No. See above answer. In short, if you think it really belongs in dash marker line as described in Documentation/process/submitting-patches.rst to temporarily embed that information into the patch that you send. +Q: Are all networking bug fixes backported to all stable releases? + +A: Due to capacity, Dave could only take care of the backports for the last + 3 stable releases. For earlier stable releases, each stable branch maintainer + is supposed to take care of them. If you find any patch is missing from an + earlier stable branch, please notify stable(a)vger.kernel.org with either a + commit ID or a formal patch backported, and CC Dave and other relevant + networking developers. + Q: Someone said that the comment style and coding convention is different for the networking content. Is this true? -- 2.13.0

7 years, 1 month

3
3
0 0

[git:media_tree/master] media: uvcvideo: Prevent setting unavailable flags

by Mauro Carvalho Chehab

This is an automatic generated email to let you know that the following patch were queued: Subject: media: uvcvideo: Prevent setting unavailable flags Author: Kieran Bingham <kieran.bingham(a)ideasonboard.com> Date: Wed Mar 21 11:43:08 2018 -0400 The addition of an extra operation to use the GET_INFO command overwrites all existing flags from the uvc_ctrls table. This includes setting all controls as supporting GET_MIN, GET_MAX, GET_RES, and GET_DEF regardless of whether they do or not. Move the initialisation of these control capabilities directly to the uvc_ctrl_fill_xu_info() call where they were originally located in that use case, and ensure that the new functionality in uvc_ctrl_get_flags() will only set flags based on their reported capability from the GET_INFO call. Fixes: 859086ae3636 ("media: uvcvideo: Apply flags from device to actual properties") Cc: stable(a)vger.kernel.org Signed-off-by: Kieran Bingham <kieran.bingham(a)ideasonboard.com> Tested-by: Guennadi Liakhovetski <guennadi.liakhovetski(a)intel.com> Signed-off-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung(a)kernel.org> drivers/media/usb/uvc/uvc_ctrl.c | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) --- diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c index 102594ec3e97..a36b4fb949fa 100644 --- a/drivers/media/usb/uvc/uvc_ctrl.c +++ b/drivers/media/usb/uvc/uvc_ctrl.c @@ -1607,14 +1607,12 @@ static int uvc_ctrl_get_flags(struct uvc_device *dev, ret = uvc_query_ctrl(dev, UVC_GET_INFO, ctrl->entity->id, dev->intfnum, info->selector, data, 1); if (!ret) - info->flags = UVC_CTRL_FLAG_GET_MIN | UVC_CTRL_FLAG_GET_MAX - | UVC_CTRL_FLAG_GET_RES | UVC_CTRL_FLAG_GET_DEF - | (data[0] & UVC_CONTROL_CAP_GET ? - UVC_CTRL_FLAG_GET_CUR : 0) - | (data[0] & UVC_CONTROL_CAP_SET ? - UVC_CTRL_FLAG_SET_CUR : 0) - | (data[0] & UVC_CONTROL_CAP_AUTOUPDATE ? - UVC_CTRL_FLAG_AUTO_UPDATE : 0); + info->flags |= (data[0] & UVC_CONTROL_CAP_GET ? + UVC_CTRL_FLAG_GET_CUR : 0) + | (data[0] & UVC_CONTROL_CAP_SET ? + UVC_CTRL_FLAG_SET_CUR : 0) + | (data[0] & UVC_CONTROL_CAP_AUTOUPDATE ? + UVC_CTRL_FLAG_AUTO_UPDATE : 0); kfree(data); return ret; @@ -1689,6 +1687,9 @@ static int uvc_ctrl_fill_xu_info(struct uvc_device *dev, info->size = le16_to_cpup((__le16 *)data); + info->flags = UVC_CTRL_FLAG_GET_MIN | UVC_CTRL_FLAG_GET_MAX + | UVC_CTRL_FLAG_GET_RES | UVC_CTRL_FLAG_GET_DEF; + ret = uvc_ctrl_get_flags(dev, ctrl, info); if (ret < 0) { uvc_trace(UVC_TRACE_CONTROL,

7 years, 1 month

1
0
0 0

[PATCH] kconfig: Avoid format overflow warning from GCC 8.1

by Nathan Chancellor

In file included from scripts/kconfig/zconf.tab.c:2485: scripts/kconfig/confdata.c: In function ‘conf_write’: scripts/kconfig/confdata.c:773:22: warning: ‘%s’ directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=] sprintf(newname, "%s%s", dirname, basename); ^~ scripts/kconfig/confdata.c:773:19: note: assuming directive output of 7 bytes sprintf(newname, "%s%s", dirname, basename); ^~~~~~ scripts/kconfig/confdata.c:773:2: note: ‘sprintf’ output 1 or more bytes (assuming 4104) into a destination of size 4097 sprintf(newname, "%s%s", dirname, basename); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ scripts/kconfig/confdata.c:776:23: warning: ‘.tmpconfig.’ directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=] sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid()); ^~~~~~~~~~~ scripts/kconfig/confdata.c:776:3: note: ‘sprintf’ output between 13 and 4119 bytes into a destination of size 4097 sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid()); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Increase the size of tmpname and newname to make GCC happy. Cc: stable(a)vger.kernel.org Signed-off-by: Nathan Chancellor <natechancellor(a)gmail.com> --- scripts/kconfig/confdata.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c index 5f87ad561b08..39e20974f4a3 100644 --- a/scripts/kconfig/confdata.c +++ b/scripts/kconfig/confdata.c @@ -720,7 +720,7 @@ int conf_write(const char *name) struct menu *menu; const char *basename; const char *str; - char dirname[PATH_MAX+1], tmpname[PATH_MAX+1], newname[PATH_MAX+1]; + char dirname[PATH_MAX+1], tmpname[PATH_MAX+22], newname[PATH_MAX+8]; char *env; dirname[0] = 0; -- 2.17.1

7 years, 1 month

2
1
0 0

Re: [patch 2/8] genirq/generic_pending: Do not lose pending affinity update

by Dou Liyang

Hi Thomas, At 06/04/2018 11:33 PM, Thomas Gleixner wrote: > The generic pending interrupt mechanism moves interrupts from the interrupt > handler on the original target CPU to the new destination CPU. This is > required for x86 and ia64 due to the way the interrupt delivery and > acknowledge works if the interrupts are not remapped. > > However that update can fail for various reasons. Some of them are valid > reasons to discard the pending update, but the case, when the previous move > has not been fully cleaned up is not a legit reason to fail. > > Check the return value of irq_do_set_affinity() for -EBUSY, which indicates > a pending cleanup, and rearm the pending move in the irq dexcriptor so it's s/dexcriptor/descriptor > tried again when the next interrupt arrives. > > Fixes: 996c591227d9 ("x86/irq: Plug vector cleanup race") > Signed-off-by: Thomas Gleixner<tglx(a)linutronix.de> > Cc:stable@vger.kernel.org > --- > kernel/irq/migration.c | 24 ++++++++++++++++++------ > 1 file changed, 18 insertions(+), 6 deletions(-) > > --- a/kernel/irq/migration.c > +++ b/kernel/irq/migration.c > @@ -38,17 +38,18 @@ bool irq_fixup_move_pending(struct irq_d > void irq_move_masked_irq(struct irq_data *idata) > { > struct irq_desc *desc = irq_data_to_desc(idata); > - struct irq_chip *chip = desc->irq_data.chip; > + struct irq_data *data = &desc->irq_data; > + struct irq_chip *chip = data->chip; > > - if (likely(!irqd_is_setaffinity_pending(&desc->irq_data))) > + if (likely(!irqd_is_setaffinity_pending(data))) > return; > > - irqd_clr_move_pending(&desc->irq_data); > + irqd_clr_move_pending(data); > > /* > * Paranoia: cpu-local interrupts shouldn't be calling in here anyway. > */ > - if (irqd_is_per_cpu(&desc->irq_data)) { > + if (irqd_is_per_cpu(data)) { > WARN_ON(1); > return; > } > @@ -73,9 +74,20 @@ void irq_move_masked_irq(struct irq_data > * For correct operation this depends on the caller > * masking the irqs. > */ > - if (cpumask_any_and(desc->pending_mask, cpu_online_mask) < nr_cpu_ids) > - irq_do_set_affinity(&desc->irq_data, desc->pending_mask, false); > + if (cpumask_any_and(desc->pending_mask, cpu_online_mask) < nr_cpu_ids) { > + int ret; > > + ret = irq_do_set_affinity(data, desc->pending_mask, false); > + /* > + * If the there is a cleanup pending in the underlying s/If the there is/If there is/ Thanks, dou

7 years, 1 month

1
0
0 0

Re: [PATCH 4.9 00/29] 4.9.106-stable review

by Mark Brown

On Mon, Jun 04, 2018 at 04:13:06PM -0700, Kevin Hilman wrote: > > defconfig > > synquacer-acpi: 1 failed lab > This is a newly added board, and hasn't ever passed on v4.9 yet. > @Matt Hart: Is this board expected to work as far bask as v4.9? or > should we blacklist it? Should be blacklisted.

7 years, 1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror