June 2018 - Linux-stable-mirror

[PATCH] MIPS: implement smp_cond_load_acquire() for Loongson-3

by Huacai Chen

After commit 7f56b58a92aaf2c ("locking/mcs: Use smp_cond_load_acquire() in MCS spin loop") Loongson-3 fails to boot. This is because Loongson-3 has SFB (Store Fill Buffer) and READ_ONCE() may get an old value in a tight loop. So in smp_cond_load_acquire() we need a __smp_mb() after every READ_ONCE(). This patch introduce a Loongson-specific smp_cond_load_acquire(). And it should be backported to as early as linux-4.5, in which release the smp_cond_acquire() is introduced. Cc: stable(a)vger.kernel.org Signed-off-by: Huacai Chen <chenhc(a)lemote.com> --- arch/mips/include/asm/barrier.h | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/arch/mips/include/asm/barrier.h b/arch/mips/include/asm/barrier.h index a5eb1bb..4ea384d 100644 --- a/arch/mips/include/asm/barrier.h +++ b/arch/mips/include/asm/barrier.h @@ -222,6 +222,23 @@ #define __smp_mb__before_atomic() __smp_mb__before_llsc() #define __smp_mb__after_atomic() smp_llsc_mb() +#ifdef CONFIG_CPU_LOONGSON3 +/* Loongson-3 need a __smp_mb() after READ_ONCE() here */ +#define smp_cond_load_acquire(ptr, cond_expr) \ +({ \ + typeof(ptr) __PTR = (ptr); \ + typeof(*ptr) VAL; \ + for (;;) { \ + VAL = READ_ONCE(*__PTR); \ + __smp_mb(); \ + if (cond_expr) \ + break; \ + cpu_relax(); \ + } \ + VAL; \ +}) +#endif /* CONFIG_CPU_LOONGSON3 */ + #include <asm-generic/barrier.h> #endif /* __ASM_BARRIER_H */ -- 2.7.0

6 years, 7 months

5
8
0 0

[PATCH v2 1/2] net: ethernet: fix suspend/resume in davinci_emac

by Bartosz Golaszewski

From: Bartosz Golaszewski <bgolaszewski(a)baylibre.com> This patch reverts commit 3243ff2a05ec ("net: ethernet: davinci_emac: Deduplicate bus_find_device() by name matching") and adds a comment which should stop anyone from reintroducing the same "fix" in the future. We can't use bus_find_device_by_name() here because the device name is not guaranteed to be 'davinci_mdio'. On some systems it can be 'davinci_mdio.0' so we need to use strncmp() against the first part of the string to correctly match it. Fixes: 3243ff2a05ec ("net: ethernet: davinci_emac: Deduplicate bus_find_device() by name matching") Cc: stable(a)vger.kernel.org Signed-off-by: Bartosz Golaszewski <bgolaszewski(a)baylibre.com> Acked-by: Lukas Wunner <lukas(a)wunner.de> --- drivers/net/ethernet/ti/davinci_emac.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c index 06d7c9e4dcda..a1a6445b5a7e 100644 --- a/drivers/net/ethernet/ti/davinci_emac.c +++ b/drivers/net/ethernet/ti/davinci_emac.c @@ -1385,6 +1385,11 @@ static int emac_devioctl(struct net_device *ndev, struct ifreq *ifrq, int cmd) return -EOPNOTSUPP; } +static int match_first_device(struct device *dev, void *data) +{ + return !strncmp(dev_name(dev), "davinci_mdio", 12); +} + /** * emac_dev_open - EMAC device open * @ndev: The DaVinci EMAC network adapter @@ -1484,8 +1489,14 @@ static int emac_dev_open(struct net_device *ndev) /* use the first phy on the bus if pdata did not give us a phy id */ if (!phydev && !priv->phy_id) { - phy = bus_find_device_by_name(&mdio_bus_type, NULL, - "davinci_mdio"); + /* NOTE: we can't use bus_find_device_by_name() here because + * the device name is not guaranteed to be 'davinci_mdio'. On + * some systems it can be 'davinci_mdio.0' so we need to use + * strncmp() against the first part of the string to correctly + * match it. + */ + phy = bus_find_device(&mdio_bus_type, NULL, NULL, + match_first_device); if (phy) { priv->phy_id = dev_name(phy); if (!priv->phy_id || !*priv->phy_id) -- 2.17.1

6 years, 7 months

1
0
0 0

[PATCH 1/3] net: ethernet: fix suspend/resume in davinci_emac

by Bartosz Golaszewski

From: Bartosz Golaszewski <bgolaszewski(a)baylibre.com> This patch reverts commit 3243ff2a05ec ("net: ethernet: davinci_emac: Deduplicate bus_find_device() by name matching") and adds a comment which should stop anyone from reintroducing the same "fix" in the future. We can't use bus_find_device_by_name() here because the device name is not guaranteed to be 'davinci_mdio'. On some systems it can be 'davinci_mdio.0' so we need to use strncmp() against the first part of the string to correctly match it. Fixes: 3243ff2a05ec ("net: ethernet: davinci_emac: Deduplicate bus_find_device() by name matching") Cc: stable(a)vger.kernel.org Signed-off-by: Bartosz Golaszewski <bgolaszewski(a)baylibre.com> --- drivers/net/ethernet/ti/davinci_emac.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c index 06d7c9e4dcda..a1a6445b5a7e 100644 --- a/drivers/net/ethernet/ti/davinci_emac.c +++ b/drivers/net/ethernet/ti/davinci_emac.c @@ -1385,6 +1385,11 @@ static int emac_devioctl(struct net_device *ndev, struct ifreq *ifrq, int cmd) return -EOPNOTSUPP; } +static int match_first_device(struct device *dev, void *data) +{ + return !strncmp(dev_name(dev), "davinci_mdio", 12); +} + /** * emac_dev_open - EMAC device open * @ndev: The DaVinci EMAC network adapter @@ -1484,8 +1489,14 @@ static int emac_dev_open(struct net_device *ndev) /* use the first phy on the bus if pdata did not give us a phy id */ if (!phydev && !priv->phy_id) { - phy = bus_find_device_by_name(&mdio_bus_type, NULL, - "davinci_mdio"); + /* NOTE: we can't use bus_find_device_by_name() here because + * the device name is not guaranteed to be 'davinci_mdio'. On + * some systems it can be 'davinci_mdio.0' so we need to use + * strncmp() against the first part of the string to correctly + * match it. + */ + phy = bus_find_device(&mdio_bus_type, NULL, NULL, + match_first_device); if (phy) { priv->phy_id = dev_name(phy); if (!priv->phy_id || !*priv->phy_id) -- 2.17.1

6 years, 7 months

3
3
0 0

[PATCH v4 06/15] mtd: rawnand: qcom: wait for desc completion in all BAM channels

by Abhishek Sahu

The BAM has 3 channels - tx, rx and command. command channel is used for register read/writes, tx channel for data writes and rx channel for data reads. Currently, the driver assumes the transfer completion once it gets all the command descriptors completed. Sometimes, there is race condition between data channel (tx/rx) and command channel completion. In these cases, the data present in buffer is not valid during small window between command descriptor completion and data descriptor completion. This patch generates NAND transfer completion when both (Data and Command) DMA channels have completed all its DMA descriptors. It assigns completion callback in last DMA descriptors of that channel and wait for completion. Fixes: 8d6b6d7e135e ("mtd: nand: qcom: support for command descriptor formation") Cc: stable(a)vger.kernel.org Acked-by: Miquel Raynal <miquel.raynal(a)bootlin.com> Signed-off-by: Abhishek Sahu <absahu(a)codeaurora.org> --- * Changes from v3: 1. NONE * Changes from v2: 1. Changed commit message and comments slightly 2. Renamed wait_second_completion from first_chan_done and set it before submit desc 3. Mark for stable tree * Changes from v1: NONE drivers/mtd/nand/raw/qcom_nandc.c | 53 ++++++++++++++++++++++++++++++++++++++- 1 file changed, 52 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/nand/raw/qcom_nandc.c b/drivers/mtd/nand/raw/qcom_nandc.c index 2375780..fc20149 100644 --- a/drivers/mtd/nand/raw/qcom_nandc.c +++ b/drivers/mtd/nand/raw/qcom_nandc.c @@ -213,6 +213,8 @@ #define QPIC_PER_CW_CMD_SGL 32 #define QPIC_PER_CW_DATA_SGL 8 +#define QPIC_NAND_COMPLETION_TIMEOUT msecs_to_jiffies(2000) + /* * Flags used in DMA descriptor preparation helper functions * (i.e. read_reg_dma/write_reg_dma/read_data_dma/write_data_dma) @@ -245,6 +247,11 @@ * @tx_sgl_start - start index in data sgl for tx. * @rx_sgl_pos - current index in data sgl for rx. * @rx_sgl_start - start index in data sgl for rx. + * @wait_second_completion - wait for second DMA desc completion before making + * the NAND transfer completion. + * @txn_done - completion for NAND transfer. + * @last_data_desc - last DMA desc in data channel (tx/rx). + * @last_cmd_desc - last DMA desc in command channel. */ struct bam_transaction { struct bam_cmd_element *bam_ce; @@ -258,6 +265,10 @@ struct bam_transaction { u32 tx_sgl_start; u32 rx_sgl_pos; u32 rx_sgl_start; + bool wait_second_completion; + struct completion txn_done; + struct dma_async_tx_descriptor *last_data_desc; + struct dma_async_tx_descriptor *last_cmd_desc; }; /* @@ -504,6 +515,8 @@ static void free_bam_transaction(struct qcom_nand_controller *nandc) bam_txn->data_sgl = bam_txn_buf; + init_completion(&bam_txn->txn_done); + return bam_txn; } @@ -523,11 +536,33 @@ static void clear_bam_transaction(struct qcom_nand_controller *nandc) bam_txn->tx_sgl_start = 0; bam_txn->rx_sgl_pos = 0; bam_txn->rx_sgl_start = 0; + bam_txn->last_data_desc = NULL; + bam_txn->wait_second_completion = false; sg_init_table(bam_txn->cmd_sgl, nandc->max_cwperpage * QPIC_PER_CW_CMD_SGL); sg_init_table(bam_txn->data_sgl, nandc->max_cwperpage * QPIC_PER_CW_DATA_SGL); + + reinit_completion(&bam_txn->txn_done); +} + +/* Callback for DMA descriptor completion */ +static void qpic_bam_dma_done(void *data) +{ + struct bam_transaction *bam_txn = data; + + /* + * In case of data transfer with NAND, 2 callbacks will be generated. + * One for command channel and another one for data channel. + * If current transaction has data descriptors + * (i.e. wait_second_completion is true), then set this to false + * and wait for second DMA descriptor completion. + */ + if (bam_txn->wait_second_completion) + bam_txn->wait_second_completion = false; + else + complete(&bam_txn->txn_done); } static inline struct qcom_nand_host *to_qcom_nand_host(struct nand_chip *chip) @@ -756,6 +791,12 @@ static int prepare_bam_async_desc(struct qcom_nand_controller *nandc, desc->dma_desc = dma_desc; + /* update last data/command descriptor */ + if (chan == nandc->cmd_chan) + bam_txn->last_cmd_desc = dma_desc; + else + bam_txn->last_data_desc = dma_desc; + list_add_tail(&desc->node, &nandc->desc_list); return 0; @@ -1273,10 +1314,20 @@ static int submit_descs(struct qcom_nand_controller *nandc) cookie = dmaengine_submit(desc->dma_desc); if (nandc->props->is_bam) { + bam_txn->last_cmd_desc->callback = qpic_bam_dma_done; + bam_txn->last_cmd_desc->callback_param = bam_txn; + if (bam_txn->last_data_desc) { + bam_txn->last_data_desc->callback = qpic_bam_dma_done; + bam_txn->last_data_desc->callback_param = bam_txn; + bam_txn->wait_second_completion = true; + } + dma_async_issue_pending(nandc->tx_chan); dma_async_issue_pending(nandc->rx_chan); + dma_async_issue_pending(nandc->cmd_chan); - if (dma_sync_wait(nandc->cmd_chan, cookie) != DMA_COMPLETE) + if (!wait_for_completion_timeout(&bam_txn->txn_done, + QPIC_NAND_COMPLETION_TIMEOUT)) return -ETIMEDOUT; } else { if (dma_sync_wait(nandc->chan, cookie) != DMA_COMPLETE) -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

6 years, 7 months

1
0
0 0

[PATCH] printk/nmi: Prevent deadlock when serializing NMI backtraces

by Petr Mladek

The commit 719f6a7040f1bdaf96fcc ("printk: Use the main logbuf in NMI when logbuf_lock is available") tried to detect when logbuf_lock was taken on another CPU. Then it looked safe to wait for the lock even in NMI. It would be safe if other locks were not involved. Ironically the same commit introduced an ABBA deadlock scenario. It added a spin lock into nmi_cpu_backtrace() to serialize logs from different CPUs. The effect is that also the NMI handlers are serialized. As a result, logbuf_lock might be blocked by NMI on another CPU: CPU0 CPU1 CPU2 printk() vprintk_emit() spin_lock(&logbuf_lock) trigger_all_cpu_backtrace() raise() nmi_enter() printk_nmi_enter() if (this_cpu_read(printk_context) & PRINTK_SAFE_CONTEXT_MASK) // false else // looks safe to use printk_deferred() this_cpu_or(printk_context, PRINTK_NMI_DEFERRED_CONTEXT_MASK); nmi_cpu_backtrace() arch_spin_lock(&lock); show_regs() nmi_enter() nmi_cpu_backtrace() arch_spin_lock(&lock); printk() vprintk_func() vprintk_deferred() vprintk_emit() spin_lock(&logbuf_lock) DEADLOCK: between &logbuf_lock from vprintk_emit() and &lock from nmi_cpu_backtrace(). CPU0 CPU1 lock(logbuf_lock) lock(lock) lock(lock) lock(logbuf_lock) I have found this problem when stress testing trigger_all_cpu_backtrace() and the system frozen. Note that lockdep is not able to detect these dependencies because there is no support for NMI context. Let's stay on the safe side and always use printk_safe buffers when logbuf_lock is taken when entering NMI. Fixes: 719f6a7040f1bdaf96fcc ("printk: Use the main logbuf in NMI when logbuf_lock is available") Cc: 4.13+ <stable(a)vger.kernel.org> # v4.13+ Signed-off-by: Petr Mladek <pmladek(a)suse.com> --- kernel/printk/printk_safe.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/kernel/printk/printk_safe.c b/kernel/printk/printk_safe.c index 449d67edfa4b..a2ebd749c053 100644 --- a/kernel/printk/printk_safe.c +++ b/kernel/printk/printk_safe.c @@ -310,15 +310,12 @@ void printk_nmi_enter(void) { /* * The size of the extra per-CPU buffer is limited. Use it only when - * the main one is locked. If this CPU is not in the safe context, - * the lock must be taken on another CPU and we could wait for it. + * the main one is locked. */ - if ((this_cpu_read(printk_context) & PRINTK_SAFE_CONTEXT_MASK) && - raw_spin_is_locked(&logbuf_lock)) { + if (raw_spin_is_locked(&logbuf_lock)) this_cpu_or(printk_context, PRINTK_NMI_CONTEXT_MASK); - } else { + else this_cpu_or(printk_context, PRINTK_NMI_DEFERRED_CONTEXT_MASK); - } } void printk_nmi_exit(void) -- 2.13.6

6 years, 7 months

4
21
0 0

Re: [PATCH 3.18 00/21] 3.18.113-stable review

by Greg Kroah-Hartman

On Tue, Jun 12, 2018 at 03:08:12PM -0700, kernelci.org bot wrote: > stable-rc/linux-3.18.y boot: 52 boots: 28 failed, 18 passed with 1 offline, 5 conflicts (v3.18.112-22-gb0582263e3c9) > > Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-3.18.y/kernel/v3.1… > Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-3.18.y/kernel/v3.18.112-2… > > Tree: stable-rc > Branch: linux-3.18.y > Git Describe: v3.18.112-22-gb0582263e3c9 > Git Commit: b0582263e3c9810fd887ca92d19cb9ff30a4d9f6 > Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > Tested: 24 unique boards, 12 SoC families, 13 builds out of 183 > > Boot Regressions Detected: > > arm: > > bcm2835_defconfig: > bcm2835-rpi-b: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > > davinci_all_defconfig: > dm365evm,legacy: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > > exynos_defconfig: > exynos5800-peach-pi: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > > imx_v6_v7_defconfig: > imx6dl-wandboard_dual: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > imx6dl-wandboard_solo: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > imx6q-wandboard: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > > multi_v7_defconfig: > am335x-boneblack: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > armada-xp-openblocks-ax3-4: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > exynos5800-peach-pi: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > imx6dl-wandboard_dual: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > imx6dl-wandboard_solo: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > imx6q-wandboard: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > omap3-beagle: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > omap3-beagle-xm: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > omap4-panda: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > sun4i-a10-cubieboard: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > sun7i-a20-cubietruck: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > tegra124-jetson-tk1: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > tegra20-iris-512: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > tegra30-beaver: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > zynq-zc702: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > > mvebu_v7_defconfig: > armada-xp-openblocks-ax3-4: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > > omap2plus_defconfig: > am335x-boneblack: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > omap3-beagle: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > omap3-beagle-xm: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > omap3-beagle-xm,legacy: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > omap4-panda: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > > sama5_defconfig: > at91-sama5d4ek: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > > sunxi_defconfig: > sun4i-a10-cubieboard: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > sun7i-a20-cubietruck: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > > tegra_defconfig: > tegra124-jetson-tk1: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > tegra20-iris-512: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > tegra30-beaver: > lab-baylibre-seattle: new failure (last pass: v3.18.112) That is a lot of new failures, did the whole lab fail, or is this really a problem in v3.18.112 here? thanks, greg k-h

6 years, 7 months

3
4
0 0

[PATCH v3] target: fix truncated PR-in ReadKeys response

by David Disseldorp

SPC5r17 states that the contents of the ADDITIONAL LENGTH field are not altered based on the allocation length, so always calculate and pack the full key list length even if the list itself is truncated. According to Maged: Yes it fixes the "Storage Spaces Persistent Reservation" test in the Windows 2016 Server Failover Cluster validation suites when having many connections that result in more than 8 registrations. I tested your patch on 4.17 with iblock. This behaviour can be tested using the libiscsi PrinReadKeys.Truncate test. Cc: stable(a)vger.kernel.org Signed-off-by: David Disseldorp <ddiss(a)suse.de> Reviewed-by: Mike Christie <mchristi(a)redhat.com> Tested-by: Maged Mokhtar <mmokhtar(a)petasan.org> Reviewed-by: Christoph Hellwig <hch(a)lst.de> --- Changes since v2: * drop unnecessary braces * add Christoph's Reviewed-by Changes since v1: * CC stable * mention Maged's Windows PR test fix comment in commit message * add Reviewed-by and Tested-by tags drivers/target/target_core_pr.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/drivers/target/target_core_pr.c b/drivers/target/target_core_pr.c index 01ac306131c1..10db5656fd5d 100644 --- a/drivers/target/target_core_pr.c +++ b/drivers/target/target_core_pr.c @@ -3727,11 +3727,16 @@ core_scsi3_pri_read_keys(struct se_cmd *cmd) * Check for overflow of 8byte PRI READ_KEYS payload and * next reservation key list descriptor. */ - if ((add_len + 8) > (cmd->data_length - 8)) - break; - - put_unaligned_be64(pr_reg->pr_res_key, &buf[off]); - off += 8; + if (off + 8 <= cmd->data_length) { + put_unaligned_be64(pr_reg->pr_res_key, &buf[off]); + off += 8; + } + /* + * SPC5r17: 6.16.2 READ KEYS service action + * The ADDITIONAL LENGTH field indicates the number of bytes in + * the Reservation key list. The contents of the ADDITIONAL + * LENGTH field are not altered based on the allocation length + */ add_len += 8; } spin_unlock(&dev->t10_pr.registration_lock); -- 2.13.7

6 years, 7 months

2
1
0 0

[PATCH] scsi: sd: Optimal I/O size should be a multiple of physical block size

by Martin K. Petersen

It was reported that some devices report an OPTIMAL TRANSFER LENGTH of 0xFFFF blocks. That looks bogus, especially for a device with a 4096-byte physical block size. Ignore OPTIMAL TRANSFER LENGTH if it is not a multiple of the device's reported physical block size. Cc: <stable(a)vger.kernel.org> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199759 Reported-by: Christoph Anton Mitterer <calestyo(a)scientia.net> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> --- Before: NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME sda 0 4096 33553920 4096 512 0 mq-deadline 256 128 32M After: NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME sda 0 4096 0 4096 512 0 mq-deadline 256 4096 32M --- drivers/scsi/sd.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index 9421d9877730..2d19eed3dfbc 100644 --- a/drivers/scsi/sd.c +++ b/drivers/scsi/sd.c @@ -3067,7 +3067,7 @@ static int sd_revalidate_disk(struct gendisk *disk) struct request_queue *q = sdkp->disk->queue; sector_t old_capacity = sdkp->capacity; unsigned char *buffer; - unsigned int dev_max, rw_max; + unsigned int dev_max, rw_max, opt_xfer_bytes; SCSI_LOG_HLQUEUE(3, sd_printk(KERN_INFO, sdkp, "sd_revalidate_disk\n")); @@ -3126,13 +3126,16 @@ static int sd_revalidate_disk(struct gendisk *disk) /* * Determine the device's preferred I/O size for reads and writes - * unless the reported value is unreasonably small, large, or - * garbage. + * unless the reported value is unreasonably small, large, not a + * multiple of the physical block size, or simply garbage. */ + opt_xfer_bytes = logical_to_bytes(sdp, sdkp->opt_xfer_blocks); + if (sdkp->opt_xfer_blocks && sdkp->opt_xfer_blocks <= dev_max && sdkp->opt_xfer_blocks <= SD_DEF_XFER_BLOCKS && - logical_to_bytes(sdp, sdkp->opt_xfer_blocks) >= PAGE_SIZE) { + opt_xfer_bytes >= PAGE_SIZE && + (opt_xfer_bytes & (sdkp->physical_block_size - 1)) != 0) { q->limits.io_opt = logical_to_bytes(sdp, sdkp->opt_xfer_blocks); rw_max = logical_to_sectors(sdp, sdkp->opt_xfer_blocks); } else -- 2.17.1

6 years, 7 months

1
1
0 0

[PATCH v3 4/7] vmw_balloon: fix VMCI use when balloon built into kernel

by Nadav Amit

Currently, when all modules, including VMCI and VMware balloon are built into the kernel, the initialization of the balloon happens before the VMCI is probed. As a result, the balloon fails to initialize the VMCI doorbell, which it uses to get asynchronous requests for balloon size changes. The problem can be seen in the logs, in the form of the following message: "vmw_balloon: failed to initialize vmci doorbell" The driver would work correctly but slightly less efficiently, probing for requests periodically. This patch changes the balloon to be initialized using late_initcall() instead of module_init() to address this issue. It does not address a situation in which VMCI is built as a module and the balloon is built into the kernel. Fixes: 48e3d668b790 ("VMware balloon: Enable notification via VMCI") Cc: stable(a)vger.kernel.org Reviewed-by: Xavier Deguillard <xdeguillard(a)vmware.com> Signed-off-by: Nadav Amit <namit(a)vmware.com> --- drivers/misc/vmw_balloon.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/misc/vmw_balloon.c b/drivers/misc/vmw_balloon.c index a7df4c24a28d..e7cfc85f6961 100644 --- a/drivers/misc/vmw_balloon.c +++ b/drivers/misc/vmw_balloon.c @@ -1297,7 +1297,14 @@ static int __init vmballoon_init(void) return 0; } -module_init(vmballoon_init); + +/* + * Using late_initcall() instead of module_init() allows the balloon to use the + * VMCI doorbell even when the balloon is built into the kernel. Otherwise the + * VMCI is probed only after the balloon is initialized. If the balloon is used + * as a module, late_initcall() is equivalent to module_init(). + */ +late_initcall(vmballoon_init); static void __exit vmballoon_exit(void) { -- 2.17.0

6 years, 7 months

1
0
0 0

[PATCH v3 3/7] vmw_balloon: VMCI_DOORBELL_SET does not check status

by Nadav Amit

When vmballoon_vmci_init() sets a doorbell using VMCI_DOORBELL_SET, for some reason it does not consider the status and looks at the result. However, the hypervisor does not update the result - it updates the status. This might cause VMCI doorbell not to be enabled, resulting in degraded performance. Fixes: 48e3d668b790 ("VMware balloon: Enable notification via VMCI") Cc: stable(a)vger.kernel.org Reviewed-by: Xavier Deguillard <xdeguillard(a)vmware.com> Signed-off-by: Nadav Amit <namit(a)vmware.com> --- drivers/misc/vmw_balloon.c | 37 +++++++++++++++++++------------------ 1 file changed, 19 insertions(+), 18 deletions(-) diff --git a/drivers/misc/vmw_balloon.c b/drivers/misc/vmw_balloon.c index 60ab83d3d0ef..a7df4c24a28d 100644 --- a/drivers/misc/vmw_balloon.c +++ b/drivers/misc/vmw_balloon.c @@ -1036,29 +1036,30 @@ static void vmballoon_vmci_cleanup(struct vmballoon *b) */ static int vmballoon_vmci_init(struct vmballoon *b) { - int error = 0; + unsigned long error, dummy; - if ((b->capabilities & VMW_BALLOON_SIGNALLED_WAKEUP_CMD) != 0) { - error = vmci_doorbell_create(&b->vmci_doorbell, - VMCI_FLAG_DELAYED_CB, - VMCI_PRIVILEGE_FLAG_RESTRICTED, - vmballoon_doorbell, b); - - if (error == VMCI_SUCCESS) { - VMWARE_BALLOON_CMD(VMCI_DOORBELL_SET, - b->vmci_doorbell.context, - b->vmci_doorbell.resource, error); - STATS_INC(b->stats.doorbell_set); - } - } + if ((b->capabilities & VMW_BALLOON_SIGNALLED_WAKEUP_CMD) == 0) + return 0; - if (error != 0) { - vmballoon_vmci_cleanup(b); + error = vmci_doorbell_create(&b->vmci_doorbell, VMCI_FLAG_DELAYED_CB, + VMCI_PRIVILEGE_FLAG_RESTRICTED, + vmballoon_doorbell, b); - return -EIO; - } + if (error != VMCI_SUCCESS) + goto fail; + + error = VMWARE_BALLOON_CMD(VMCI_DOORBELL_SET, b->vmci_doorbell.context, + b->vmci_doorbell.resource, dummy); + + STATS_INC(b->stats.doorbell_set); + + if (error != VMW_BALLOON_SUCCESS) + goto fail; return 0; +fail: + vmballoon_vmci_cleanup(b); + return -EIO; } /* -- 2.17.0

6 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2018