November 2019 - Linux-stable-mirror

please apply mbox files for CONFIG_UNWINDER_FRAME_POINTER clang support

by Nick Desaulniers

Greg, Sasha, Please apply the following mbox files to 5.3, 4.19, and 4.14 respectively. They enable CONFIG_UNWINDER_FRAME_POINTER support for 32b ARM kernels when compiled with Clang. This is upstream commit 6dc5fd93b2f1ef75d5e50fced8cb193811f25f22. It's a clean cherry-pick to 5.3. A slight nudge was needed for 4.19 and 4.14 since the config name was changed in upstream commit f9b58e8c7d03. A further nudge was needed for 4.14 since a4353898980c and 469cb7376c06 don't exist there. We're looking to use these in Android. Trusting the better judgement of the stable maintainers, we're happy to carry these in the Android common kernel trees, alternatively, but I think these are pretty low risk to take. Link: https://github.com/ClangBuiltLinux/linux/issues/35 -- Thanks, ~Nick Desaulniers

4 years, 5 months

2
2
0 0

[PATCH] drm/i915: Update bug URL to point at gitlab issues

by Chris Wilson

We are moving our issue tracking over from bugs.fd.o to gitlab.fd.o, so update the user instructions accordingly. Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Martin Peres <martin.peres(a)linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Cc: Jani Nikula <jani.nikula(a)intel.com> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/i915/i915_gpu_error.c | 2 +- drivers/gpu/drm/i915/i915_utils.c | 3 +-- drivers/gpu/drm/i915/i915_utils.h | 2 ++ 3 files changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c b/drivers/gpu/drm/i915/i915_gpu_error.c index 2b30a45fa25c..1cf53fd4fe66 100644 --- a/drivers/gpu/drm/i915/i915_gpu_error.c +++ b/drivers/gpu/drm/i915/i915_gpu_error.c @@ -1817,7 +1817,7 @@ void i915_capture_error_state(struct drm_i915_private *i915, if (!xchg(&warned, true) && ktime_get_real_seconds() - DRIVER_TIMESTAMP < DAY_AS_SECONDS(180)) { pr_info("GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace.\n"); - pr_info("Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel\n"); + pr_info("Please file a _new_ bug report on " FDO_BUG_URL "\n"); pr_info("drm/i915 developers can then reassign to the right component if it's not a kernel issue.\n"); pr_info("The GPU crash dump is required to analyze GPU hangs, so please always attach it.\n"); pr_info("GPU crash dump saved to /sys/class/drm/card%d/error\n", diff --git a/drivers/gpu/drm/i915/i915_utils.c b/drivers/gpu/drm/i915/i915_utils.c index c47261ae86ea..9b68b21becf1 100644 --- a/drivers/gpu/drm/i915/i915_utils.c +++ b/drivers/gpu/drm/i915/i915_utils.c @@ -8,8 +8,7 @@ #include "i915_drv.h" #include "i915_utils.h" -#define FDO_BUG_URL "https://bugs.freedesktop.org/enter_bug.cgi?product=DRI" -#define FDO_BUG_MSG "Please file a bug at " FDO_BUG_URL " against DRM/Intel " \ +#define FDO_BUG_MSG "Please file a bug at " FDO_BUG_URL \ "providing the dmesg log by booting with drm.debug=0xf" void diff --git a/drivers/gpu/drm/i915/i915_utils.h b/drivers/gpu/drm/i915/i915_utils.h index 04139ba1191e..13674b016092 100644 --- a/drivers/gpu/drm/i915/i915_utils.h +++ b/drivers/gpu/drm/i915/i915_utils.h @@ -34,6 +34,8 @@ struct drm_i915_private; struct timer_list; +#define FDO_BUG_URL "https://gitlab.freedesktop.org/drm/intel/issues/new?" + #undef WARN_ON /* Many gcc seem to no see through this and fall over :( */ #if 0 -- 2.24.0

4 years, 5 months

3
5
0 0

[PATCH 8/8] drm/panfrost: Make sure the shrinker does not reclaim referenced BOs

by Boris Brezillon

Userspace might tag a BO purgeable while it's still referenced by GPU jobs. We need to make sure the shrinker does not purge such BOs until all jobs referencing it are finished. Fixes: 013b65101315 ("drm/panfrost: Add madvise and shrinker support") Cc: <stable(a)vger.kernel.org> Signed-off-by: Boris Brezillon <boris.brezillon(a)collabora.com> --- drivers/gpu/drm/panfrost/panfrost_drv.c | 1 + drivers/gpu/drm/panfrost/panfrost_gem.h | 6 ++++++ drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c | 2 ++ drivers/gpu/drm/panfrost/panfrost_job.c | 7 ++++++- 4 files changed, 15 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c b/drivers/gpu/drm/panfrost/panfrost_drv.c index b406b5243b40..297c0e7304d2 100644 --- a/drivers/gpu/drm/panfrost/panfrost_drv.c +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c @@ -166,6 +166,7 @@ panfrost_lookup_bos(struct drm_device *dev, break; } + atomic_inc(&bo->gpu_usecount); job->mappings[i] = mapping; } diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.h b/drivers/gpu/drm/panfrost/panfrost_gem.h index ca1bc9019600..b3517ff9630c 100644 --- a/drivers/gpu/drm/panfrost/panfrost_gem.h +++ b/drivers/gpu/drm/panfrost/panfrost_gem.h @@ -30,6 +30,12 @@ struct panfrost_gem_object { struct mutex lock; } mappings; + /* + * Count the number of jobs referencing this BO so we don't let the + * shrinker reclaim this object prematurely. + */ + atomic_t gpu_usecount; + bool noexec :1; bool is_heap :1; }; diff --git a/drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c b/drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c index b36df326c860..288e46c40673 100644 --- a/drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c +++ b/drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c @@ -41,6 +41,8 @@ static bool panfrost_gem_purge(struct drm_gem_object *obj) struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj); struct panfrost_gem_object *bo = to_panfrost_bo(obj); + if (atomic_read(&bo->gpu_usecount)) + return false; if (!mutex_trylock(&shmem->pages_lock)) return false; diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c b/drivers/gpu/drm/panfrost/panfrost_job.c index c85d45be3b5e..2b12aa87ff32 100644 --- a/drivers/gpu/drm/panfrost/panfrost_job.c +++ b/drivers/gpu/drm/panfrost/panfrost_job.c @@ -270,8 +270,13 @@ static void panfrost_job_cleanup(struct kref *ref) dma_fence_put(job->render_done_fence); if (job->mappings) { - for (i = 0; i < job->bo_count; i++) + for (i = 0; i < job->bo_count; i++) { + if (!job->mappings[i]) + break; + + atomic_dec(&job->mappings[i]->obj->gpu_usecount); panfrost_gem_mapping_put(job->mappings[i]); + } kvfree(job->mappings); } -- 2.23.0

4 years, 5 months

3
5
0 0

[PATCH] ext4: Fix ext4_empty_dir() for directories with holes

by Jan Kara

Function ext4_empty_dir() doesn't correctly handle directories with holes and crashes on bh->b_data dereference when bh is NULL. Reorganize the loop to use 'offset' variable all the times instead of comparing pointers to current direntry with bh->b_data pointer. Also add more strict checking of '.' and '..' directory entries to avoid entering loop in possibly invalid state on corrupted filesystems. References: CVE-2019-19037 CC: stable(a)vger.kernel.org Fixes: 4e19d6b65fb4 ("ext4: allow directory holes") Signed-off-by: Jan Kara <jack(a)suse.cz> --- fs/ext4/namei.c | 32 ++++++++++++++++++-------------- 1 file changed, 18 insertions(+), 14 deletions(-) diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c index a427d2031a8d..91083eb9c203 100644 --- a/fs/ext4/namei.c +++ b/fs/ext4/namei.c @@ -2808,7 +2808,7 @@ bool ext4_empty_dir(struct inode *inode) { unsigned int offset; struct buffer_head *bh; - struct ext4_dir_entry_2 *de, *de1; + struct ext4_dir_entry_2 *de; struct super_block *sb; if (ext4_has_inline_data(inode)) { @@ -2833,19 +2833,25 @@ bool ext4_empty_dir(struct inode *inode) return true; de = (struct ext4_dir_entry_2 *) bh->b_data; - de1 = ext4_next_entry(de, sb->s_blocksize); - if (le32_to_cpu(de->inode) != inode->i_ino || - le32_to_cpu(de1->inode) == 0 || - strcmp(".", de->name) || strcmp("..", de1->name)) { - ext4_warning_inode(inode, "directory missing '.' and/or '..'"); + if (ext4_check_dir_entry(inode, NULL, de, bh, bh->b_data, bh->b_size, + 0) || + le32_to_cpu(de->inode) != inode->i_ino || strcmp(".", de->name)) { + ext4_warning_inode(inode, "directory missing '.'"); + brelse(bh); + return true; + } + offset = ext4_rec_len_from_disk(de->rec_len, sb->s_blocksize); + de = ext4_next_entry(de, sb->s_blocksize); + if (ext4_check_dir_entry(inode, NULL, de, bh, bh->b_data, bh->b_size, + offset) || + le32_to_cpu(de->inode) == 0 || strcmp("..", de->name)) { + ext4_warning_inode(inode, "directory missing '..'"); brelse(bh); return true; } - offset = ext4_rec_len_from_disk(de->rec_len, sb->s_blocksize) + - ext4_rec_len_from_disk(de1->rec_len, sb->s_blocksize); - de = ext4_next_entry(de1, sb->s_blocksize); + offset += ext4_rec_len_from_disk(de->rec_len, sb->s_blocksize); while (offset < inode->i_size) { - if ((void *) de >= (void *) (bh->b_data+sb->s_blocksize)) { + if (!(offset & (sb->s_blocksize - 1))) { unsigned int lblock; brelse(bh); lblock = offset >> EXT4_BLOCK_SIZE_BITS(sb); @@ -2856,12 +2862,11 @@ bool ext4_empty_dir(struct inode *inode) } if (IS_ERR(bh)) return true; - de = (struct ext4_dir_entry_2 *) bh->b_data; } + de = (struct ext4_dir_entry_2 *) bh->b_data + + (offset & (sb->s_blocksize - 1)); if (ext4_check_dir_entry(inode, NULL, de, bh, bh->b_data, bh->b_size, offset)) { - de = (struct ext4_dir_entry_2 *)(bh->b_data + - sb->s_blocksize); offset = (offset | (sb->s_blocksize - 1)) + 1; continue; } @@ -2870,7 +2875,6 @@ bool ext4_empty_dir(struct inode *inode) return false; } offset += ext4_rec_len_from_disk(de->rec_len, sb->s_blocksize); - de = ext4_next_entry(de, sb->s_blocksize); } brelse(bh); return true; -- 2.16.4

4 years, 5 months

3
5
0 0

[PATCH 6/8] drm/panfrost: Make sure imported/exported BOs are never purged

by Boris Brezillon

We don't want imported/exported BOs to be purges, as those are shared with other processes that might still use them. We should also refuse to export a BO if it's been marked purgeable or has already been purged. Fixes: 013b65101315 ("drm/panfrost: Add madvise and shrinker support") Cc: <stable(a)vger.kernel.org> Signed-off-by: Boris Brezillon <boris.brezillon(a)collabora.com> --- drivers/gpu/drm/panfrost/panfrost_drv.c | 19 ++++++++++++++++- drivers/gpu/drm/panfrost/panfrost_gem.c | 27 +++++++++++++++++++++++++ 2 files changed, 45 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c b/drivers/gpu/drm/panfrost/panfrost_drv.c index 1c67ac434e10..751df975534f 100644 --- a/drivers/gpu/drm/panfrost/panfrost_drv.c +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c @@ -343,6 +343,7 @@ static int panfrost_ioctl_madvise(struct drm_device *dev, void *data, struct drm_panfrost_madvise *args = data; struct panfrost_device *pfdev = dev->dev_private; struct drm_gem_object *gem_obj; + int ret; gem_obj = drm_gem_object_lookup(file_priv, args->handle); if (!gem_obj) { @@ -350,6 +351,19 @@ static int panfrost_ioctl_madvise(struct drm_device *dev, void *data, return -ENOENT; } + /* + * We don't want to mark exported/imported BOs as purgeable: we're not + * the only owner in that case. + */ + mutex_lock(&dev->object_name_lock); + if (gem_obj->dma_buf) + ret = -EINVAL; + else + ret = 0; + + if (ret) + goto out_unlock_object_name; + mutex_lock(&pfdev->shrinker_lock); args->retained = drm_gem_shmem_madvise(gem_obj, args->madv); @@ -364,8 +378,11 @@ static int panfrost_ioctl_madvise(struct drm_device *dev, void *data, } mutex_unlock(&pfdev->shrinker_lock); +out_unlock_object_name: + mutex_unlock(&dev->object_name_lock); + drm_gem_object_put_unlocked(gem_obj); - return 0; + return ret; } int panfrost_unstable_ioctl_check(void) diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c b/drivers/gpu/drm/panfrost/panfrost_gem.c index 92a95210a899..31d6417dd21c 100644 --- a/drivers/gpu/drm/panfrost/panfrost_gem.c +++ b/drivers/gpu/drm/panfrost/panfrost_gem.c @@ -99,6 +99,32 @@ void panfrost_gem_close(struct drm_gem_object *obj, struct drm_file *file_priv) spin_unlock(&priv->mm_lock); } +static struct dma_buf * +panfrost_gem_export(struct drm_gem_object *obj, int flags) +{ + struct panfrost_gem_object *bo = to_panfrost_bo(obj); + int ret; + + /* + * We must make sure the BO has not been marked purgeable/purged before + * adding the mapping. + * Note that we don't need to protect this test with a lock because + * &drm_gem_object_funcs.export() is called with + * &drm_device.object_lock held, and panfrost_ioctl_madvise() takes + * this lock before calling drm_gem_shmem_madvise() (the function that + * modifies bo->base.madv). + */ + if (bo->base.madv == PANFROST_MADV_WILLNEED) + ret = -EINVAL; + else + ret = 0; + + if (ret) + return ERR_PTR(ret); + + return drm_gem_prime_export(obj, flags); +} + static int panfrost_gem_pin(struct drm_gem_object *obj) { if (to_panfrost_bo(obj)->is_heap) @@ -112,6 +138,7 @@ static const struct drm_gem_object_funcs panfrost_gem_funcs = { .open = panfrost_gem_open, .close = panfrost_gem_close, .print_info = drm_gem_shmem_print_info, + .export = panfrost_gem_export, .pin = panfrost_gem_pin, .unpin = drm_gem_shmem_unpin, .get_sg_table = drm_gem_shmem_get_sg_table, -- 2.23.0

4 years, 5 months

3
7
0 0

[PATCH for-4.19-stable] ath10k: restore QCA9880-AR1A (v1) detection

by Christian Lamparter

commit f8914a14623a79b73f72b2b1ee4cd9b2cb91b735 upstream --- >From f8914a14623a79b73f72b2b1ee4cd9b2cb91b735 Mon Sep 17 00:00:00 2001 From: Christian Lamparter <chunkeey(a)gmail.com> Date: Mon, 25 Mar 2019 13:50:19 +0100 Subject: [PATCH for-4.19-stable] ath10k: restore QCA9880-AR1A (v1) detection To: linux-wireless(a)vger.kernel.org, ath10k(a)lists.infradead.org Cc: Kalle Valo <kvalo(a)codeaurora.org> This patch restores the old behavior that read the chip_id on the QCA988x before resetting the chip. This needs to be done in this order since the unsupported QCA988x AR1A chips fall off the bus when resetted. Otherwise the next MMIO Op after the reset causes a BUS ERROR and panic. Cc: stable(a)vger.kernel.org # 4.19 Fixes: 1a7fecb766c8 ("ath10k: reset chip before reading chip_id in probe") Signed-off-by: Christian Lamparter <chunkeey(a)gmail.com> --- drivers/net/wireless/ath/ath10k/pci.c | 36 +++++++++++++++++++-------- 1 file changed, 25 insertions(+), 11 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c --- a/drivers/net/wireless/ath/ath10k/pci.c 2019-09-08 00:07:21.374565470 +0200 +++ b/drivers/net/wireless/ath/ath10k/pci.c 2019-09-08 00:17:15.365912133 +0200 @@ -3483,7 +3483,7 @@ static int ath10k_pci_probe(struct pci_d struct ath10k_pci *ar_pci; enum ath10k_hw_rev hw_rev; u32 chip_id; - bool pci_ps; + bool pci_ps, is_qca988x = false; int (*pci_soft_reset)(struct ath10k *ar); int (*pci_hard_reset)(struct ath10k *ar); u32 (*targ_cpu_to_ce_addr)(struct ath10k *ar, u32 addr); @@ -3493,6 +3493,7 @@ static int ath10k_pci_probe(struct pci_d case QCA988X_2_0_DEVICE_ID: hw_rev = ATH10K_HW_QCA988X; pci_ps = false; + is_qca988x = true; pci_soft_reset = ath10k_pci_warm_reset; pci_hard_reset = ath10k_pci_qca988x_chip_reset; targ_cpu_to_ce_addr = ath10k_pci_qca988x_targ_cpu_to_ce_addr; @@ -3612,6 +3613,19 @@ static int ath10k_pci_probe(struct pci_d goto err_deinit_irq; } + /* Read CHIP_ID before reset to catch QCA9880-AR1A v1 devices that + * fall off the bus during chip_reset. These chips have the same pci + * device id as the QCA9880 BR4A or 2R4E. So that's why the check. + */ + if (is_qca988x) { + chip_id = ath10k_pci_soc_read32(ar, SOC_CHIP_ID_ADDRESS); + if (chip_id != 0xffffffff) { + if (!ath10k_pci_chip_is_supported(pdev->device, + chip_id)) + goto err_unsupported; + } + } + ret = ath10k_pci_chip_reset(ar); if (ret) { ath10k_err(ar, "failed to reset chip: %d\n", ret); @@ -3624,11 +3638,8 @@ static int ath10k_pci_probe(struct pci_d goto err_free_irq; } - if (!ath10k_pci_chip_is_supported(pdev->device, chip_id)) { - ath10k_err(ar, "device %04x with chip_id %08x isn't supported\n", - pdev->device, chip_id); - goto err_free_irq; - } + if (!ath10k_pci_chip_is_supported(pdev->device, chip_id)) + goto err_unsupported; ret = ath10k_core_register(ar, chip_id); if (ret) { @@ -3638,6 +3649,10 @@ static int ath10k_pci_probe(struct pci_d return 0; +err_unsupported: + ath10k_err(ar, "device %04x with chip_id %08x isn't supported\n", + pdev->device, bus_params.chip_id); + err_free_irq: ath10k_pci_free_irq(ar); ath10k_pci_rx_retry_sync(ar);

4 years, 5 months

3
5
0 0

Re: [PATCH] regulator: Defer init completion for a while after late_initcall

by Torsten Duwe

Hi all, On Wed, 4 Sep 2019 13:42:50 +0100 Mark Brown <broonie(a)kernel.org> wrote: [...] > with Arm laptops coming on the market it's becoming more of an issue so > let's do something about it. For the record: I try to run a stock distribution kernel (lots of modules) on an Olimex Teres-I. The PMIC driver is of course a module. > In the absence of any better idea just defer the powering off for 30s > after late_initcall(), this is obviously a hack but it should mask the > issue for now and it's no more arbitrary than late_initcall() itself. > Ideally we'd have some heuristics to detect if we're on an affected > system and tune or skip the delay appropriately, and there may be some > need for a command line option to be added. Am I the only one having problems with this change? I get [ 11.917136] anx6345 0-0038: 0-0038 supply dvdd12-supply not found, using dummy regulator [ 11.917174] axp20x-rsb sunxi-rsb-3a3: AXP20x variant AXP803 found Despite being loaded as a very early module, PMIC init ^^^ only starts now. [ 11.928664] hub 1-0:1.0: 1 port detected [ 11.943230] anx6345 0-0038: 0-0038 supply dvdd25-supply not found, using dummy regulator So far, so bad, but lucky me has an U-Boot which already enabled the display along with the relevant voltages in the proper sequence. [ 11.981316] [drm] Found ANX6345 (ver. 170) eDP Transmitter But much later on [ 38.248573] dcdc4: disabling [ 38.268493] vcc-pd: disabling [ 38.288446] vdd-edp: disabling screen goes dark and stays dark. Use count of the regulators is 0. I guess this is because the driver code had been returned the dummy instead? It's a mobile device so in principle there is nothing wrong with powering down unused circuitry, and always-on is not an option. Am I correct to perceive this solution as not 100% mature yet? The anx6345 driver in particular needs to do a little "voltage dance" with specific timing on the real regulators should the device come up really unpowered, so IMHO it's probably neccessary to return EPROBE_DEFER at least in this particular case and prepare the driver for it? Or what would be the real solution in this case? Torsten

4 years, 5 months

2
7
0 0

[PATCH v2 1/2] iio: imu: inv_mpu6050: fix temperature reporting using bad unit

by Jean-Baptiste Maneyrol

Temperature should be reported in milli-degrees, not degrees. Fix scale and offset values to use the correct unit. Fixes: 1615fe41a195 ("iio: imu: mpu6050: Fix FIFO layout for ICM20602") Cc: stable(a)vger.kernel.org Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol(a)invensense.com> --- drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 23 +++++++++++----------- drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h | 16 +++++++++++---- 2 files changed, 24 insertions(+), 15 deletions(-) diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c index 23c0557891a0..268240644adf 100644 --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c @@ -117,6 +117,7 @@ static const struct inv_mpu6050_hw hw_info[] = { .reg = &reg_set_6050, .config = &chip_config_6050, .fifo_size = 1024, + .temp = {INV_MPU6050_TEMP_OFFSET, INV_MPU6050_TEMP_SCALE}, }, { .whoami = INV_MPU6500_WHOAMI_VALUE, @@ -124,6 +125,7 @@ static const struct inv_mpu6050_hw hw_info[] = { .reg = &reg_set_6500, .config = &chip_config_6050, .fifo_size = 512, + .temp = {INV_MPU6500_TEMP_OFFSET, INV_MPU6500_TEMP_SCALE}, }, { .whoami = INV_MPU6515_WHOAMI_VALUE, @@ -131,6 +133,7 @@ static const struct inv_mpu6050_hw hw_info[] = { .reg = &reg_set_6500, .config = &chip_config_6050, .fifo_size = 512, + .temp = {INV_MPU6500_TEMP_OFFSET, INV_MPU6500_TEMP_SCALE}, }, { .whoami = INV_MPU6000_WHOAMI_VALUE, @@ -138,6 +141,7 @@ static const struct inv_mpu6050_hw hw_info[] = { .reg = &reg_set_6050, .config = &chip_config_6050, .fifo_size = 1024, + .temp = {INV_MPU6050_TEMP_OFFSET, INV_MPU6050_TEMP_SCALE}, }, { .whoami = INV_MPU9150_WHOAMI_VALUE, @@ -145,6 +149,7 @@ static const struct inv_mpu6050_hw hw_info[] = { .reg = &reg_set_6050, .config = &chip_config_6050, .fifo_size = 1024, + .temp = {INV_MPU6050_TEMP_OFFSET, INV_MPU6050_TEMP_SCALE}, }, { .whoami = INV_MPU9250_WHOAMI_VALUE, @@ -152,6 +157,7 @@ static const struct inv_mpu6050_hw hw_info[] = { .reg = &reg_set_6500, .config = &chip_config_6050, .fifo_size = 512, + .temp = {INV_MPU6500_TEMP_OFFSET, INV_MPU6500_TEMP_SCALE}, }, { .whoami = INV_MPU9255_WHOAMI_VALUE, @@ -159,6 +165,7 @@ static const struct inv_mpu6050_hw hw_info[] = { .reg = &reg_set_6500, .config = &chip_config_6050, .fifo_size = 512, + .temp = {INV_MPU6500_TEMP_OFFSET, INV_MPU6500_TEMP_SCALE}, }, { .whoami = INV_ICM20608_WHOAMI_VALUE, @@ -166,6 +173,7 @@ static const struct inv_mpu6050_hw hw_info[] = { .reg = &reg_set_6500, .config = &chip_config_6050, .fifo_size = 512, + .temp = {INV_ICM20608_TEMP_OFFSET, INV_ICM20608_TEMP_SCALE}, }, { .whoami = INV_ICM20602_WHOAMI_VALUE, @@ -173,6 +181,7 @@ static const struct inv_mpu6050_hw hw_info[] = { .reg = &reg_set_icm20602, .config = &chip_config_6050, .fifo_size = 1008, + .temp = {INV_ICM20608_TEMP_OFFSET, INV_ICM20608_TEMP_SCALE}, }, }; @@ -481,12 +490,8 @@ inv_mpu6050_read_raw(struct iio_dev *indio_dev, return IIO_VAL_INT_PLUS_MICRO; case IIO_TEMP: - *val = 0; - if (st->chip_type == INV_ICM20602) - *val2 = INV_ICM20602_TEMP_SCALE; - else - *val2 = INV_MPU6050_TEMP_SCALE; - + *val = st->hw->temp.scale / 1000000; + *val2 = st->hw->temp.scale % 1000000; return IIO_VAL_INT_PLUS_MICRO; case IIO_MAGN: return inv_mpu_magn_get_scale(st, chan, val, val2); @@ -496,11 +501,7 @@ inv_mpu6050_read_raw(struct iio_dev *indio_dev, case IIO_CHAN_INFO_OFFSET: switch (chan->type) { case IIO_TEMP: - if (st->chip_type == INV_ICM20602) - *val = INV_ICM20602_TEMP_OFFSET; - else - *val = INV_MPU6050_TEMP_OFFSET; - + *val = st->hw->temp.offset; return IIO_VAL_INT; default: return -EINVAL; diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h b/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h index f1fb7b6bdab1..b096e010d4ee 100644 --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h @@ -107,6 +107,7 @@ struct inv_mpu6050_chip_config { * @reg: register map of the chip. * @config: configuration of the chip. * @fifo_size: size of the FIFO in bytes. + * @temp: offset and scale to apply to raw temperature. */ struct inv_mpu6050_hw { u8 whoami; @@ -114,6 +115,10 @@ struct inv_mpu6050_hw { const struct inv_mpu6050_reg_map *reg; const struct inv_mpu6050_chip_config *config; size_t fifo_size; + struct { + int offset; + int scale; + } temp; }; /* @@ -279,16 +284,19 @@ struct inv_mpu6050_state { #define INV_MPU6050_REG_UP_TIME_MIN 5000 #define INV_MPU6050_REG_UP_TIME_MAX 10000 -#define INV_MPU6050_TEMP_OFFSET 12421 -#define INV_MPU6050_TEMP_SCALE 2941 +#define INV_MPU6050_TEMP_OFFSET 12420 +#define INV_MPU6050_TEMP_SCALE 2941176 #define INV_MPU6050_MAX_GYRO_FS_PARAM 3 #define INV_MPU6050_MAX_ACCL_FS_PARAM 3 #define INV_MPU6050_THREE_AXIS 3 #define INV_MPU6050_GYRO_CONFIG_FSR_SHIFT 3 #define INV_MPU6050_ACCL_CONFIG_FSR_SHIFT 3 -#define INV_ICM20602_TEMP_OFFSET 8170 -#define INV_ICM20602_TEMP_SCALE 3060 +#define INV_MPU6500_TEMP_OFFSET 7011 +#define INV_MPU6500_TEMP_SCALE 2995178 + +#define INV_ICM20608_TEMP_OFFSET 8170 +#define INV_ICM20608_TEMP_SCALE 3059976 /* 6 + 6 + 7 (for MPU9x50) = 19 round up to 24 and plus 8 */ #define INV_MPU6050_OUTPUT_DATA_SIZE 32 -- 2.17.1

4 years, 5 months

2
1
0 0

+ mm-memcg-slab-wait-for-root-kmem_cache-refcnt-killing-on-root-kmem_cache-destruction.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm: memcg/slab: wait for !root kmem_cache refcnt killing on root kmem_cache destruction has been added to the -mm tree. Its filename is mm-memcg-slab-wait-for-root-kmem_cache-refcnt-killing-on-root-kmem_cache-destruction.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-memcg-slab-wait-for-root-kmem_c… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-memcg-slab-wait-for-root-kmem_c… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Roman Gushchin <guro(a)fb.com> Subject: mm: memcg/slab: wait for !root kmem_cache refcnt killing on root kmem_cache destruction Christian reported a warning like the following obtained during running some KVM-related tests on s390: WARNING: CPU: 8 PID: 208 at lib/percpu-refcount.c:108 percpu_ref_exit+0x50/0x58 Modules linked in: kvm(-) xt_CHECKSUM xt_MASQUERADE bonding xt_tcpudp ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack ip6table_na> CPU: 8 PID: 208 Comm: kworker/8:1 Not tainted 5.2.0+ #66 Hardware name: IBM 2964 NC9 712 (LPAR) Workqueue: events sysfs_slab_remove_workfn Krnl PSW : 0704e00180000000 0000001529746850 (percpu_ref_exit+0x50/0x58) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 00000000ffff8808 0000001529746740 000003f4e30e8e18 0036008100000000 0000001f00000000 0035008100000000 0000001fb3573ab8 0000000000000000 0000001fbdb6de00 0000000000000000 0000001529f01328 0000001fb3573b00 0000001fbb27e000 0000001fbdb69300 000003e009263d00 000003e009263cd0 Krnl Code: 0000001529746842: f0a0000407fe srp 4(11,%r0),2046,0 0000001529746848: 47000700 bc 0,1792 #000000152974684c: a7f40001 brc 15,152974684e >0000001529746850: a7f4fff2 brc 15,1529746834 0000001529746854: 0707 bcr 0,%r7 0000001529746856: 0707 bcr 0,%r7 0000001529746858: eb8ff0580024 stmg %r8,%r15,88(%r15) 000000152974685e: a738ffff lhi %r3,-1 Call Trace: ([<000003e009263d00>] 0x3e009263d00) [<00000015293252ea>] slab_kmem_cache_release+0x3a/0x70 [<0000001529b04882>] kobject_put+0xaa/0xe8 [<000000152918cf28>] process_one_work+0x1e8/0x428 [<000000152918d1b0>] worker_thread+0x48/0x460 [<00000015291942c6>] kthread+0x126/0x160 [<0000001529b22344>] ret_from_fork+0x28/0x30 [<0000001529b2234c>] kernel_thread_starter+0x0/0x10 Last Breaking-Event-Address: [<000000152974684c>] percpu_ref_exit+0x4c/0x58 ---[ end trace b035e7da5788eb09 ]--- The problem occurs because kmem_cache_destroy() is called immediately after deleting of a memcg, so it races with the memcg kmem_cache deactivation. flush_memcg_workqueue() at the beginning of kmem_cache_destroy() is supposed to guarantee that all deactivation processes are finished, but failed to do so. It waits for an rcu grace period, after which all children kmem_caches should be deactivated. During the deactivation percpu_ref_kill() is called for non root kmem_cache refcounters, but it requires yet another rcu grace period to finish the transition to the atomic (dead) state. So in a rare case when not all children kmem_caches are destroyed at the moment when the root kmem_cache is about to be gone, we need to wait another rcu grace period before destroying the root kmem_cache. This issue can be triggered only with dynamically created kmem_caches which are used with memcg accounting. In this case per-memcg child kmem_caches are created. They are deactivated from the cgroup removing path. If the destruction of the root kmem_cache is racing with the removal of the cgroup (both are quite complicated multi-stage processes), the described issue can occur. The only known way to trigger it in the real life, is to unload some kernel module which creates a dedicated kmem_cache, used from different memory cgroups with GFP_ACCOUNT flag. If the unloading happens immediately after calling rmdir on the corresponding cgroup, there is some chance to trigger the issue. Link: http://lkml.kernel.org/r/20191129025011.3076017-1-guro@fb.com Fixes: f0a3a24b532d ("mm: memcg/slab: rework non-root kmem_cache lifecycle management") Signed-off-by: Roman Gushchin <guro(a)fb.com> Reported-by: Christian Borntraeger <borntraeger(a)de.ibm.com> Tested-by: Christian Borntraeger <borntraeger(a)de.ibm.com> Reviewed-by: Shakeel Butt <shakeelb(a)google.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/slab_common.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) --- a/mm/slab_common.c~mm-memcg-slab-wait-for-root-kmem_cache-refcnt-killing-on-root-kmem_cache-destruction +++ a/mm/slab_common.c @@ -904,6 +904,18 @@ static void flush_memcg_workqueue(struct * previous workitems on workqueue are processed. */ flush_workqueue(memcg_kmem_cache_wq); + + /* + * If we're racing with children kmem_cache deactivation, it might + * take another rcu grace period to complete their destruction. + * At this moment the corresponding percpu_ref_kill() call should be + * done, but it might take another rcu grace period to complete + * switching to the atomic mode. + * Please, note that we check without grabbing the slab_mutex. It's safe + * because at this moment the children list can't grow. + */ + if (!list_empty(&s->memcg_params.children)) + rcu_barrier(); } #else static inline int shutdown_memcg_caches(struct kmem_cache *s) _ Patches currently in -mm which might be from guro(a)fb.com are mm-memcg-slab-wait-for-root-kmem_cache-refcnt-killing-on-root-kmem_cache-destruction.patch

4 years, 5 months

1
0
0 0

[PATCH v2] taskstats: fix data-race

by Christian Brauner

When assiging and testing taskstats in taskstats_exit() there's a race when writing and reading sig->stats when a thread-group with more than one thread exits: cpu0: thread catches fatal signal and whole thread-group gets taken down do_exit() do_group_exit() taskstats_exit() taskstats_tgid_alloc() The tasks reads sig->stats holding sighand lock seeing garbage. cpu1: task calls exit_group() do_exit() do_group_exit() taskstats_exit() taskstats_tgid_alloc() The task takes sighand lock and assigns new stats to sig->stats. Fix this by using READ_ONCE() and smp_store_release(). Reported-by: syzbot+c5d03165a1bd1dead0c1(a)syzkaller.appspotmail.com Fixes: 34ec12349c8a ("taskstats: cleanup ->signal->stats allocation") Cc: stable(a)vger.kernel.org Signed-off-by: Christian Brauner <christian.brauner(a)ubuntu.com> Reviewed-by: Dmitry Vyukov <dvyukov(a)google.com> Link: https://lore.kernel.org/r/20191006235216.7483-1-christian.brauner@ubuntu.com --- /* v1 */ Link: https://lore.kernel.org/r/20191005112806.13960-1-christian.brauner@ubuntu.c… /* v2 */ - Dmitry Vyukov <dvyukov(a)google.com>, Marco Elver <elver(a)google.com>: - fix the original double-checked locking using memory barriers /* v3 */ - Andrea Parri <parri.andrea(a)gmail.com>: - document memory barriers to make checkpatch happy --- kernel/taskstats.c | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-) diff --git a/kernel/taskstats.c b/kernel/taskstats.c index 13a0f2e6ebc2..978d7931fb65 100644 --- a/kernel/taskstats.c +++ b/kernel/taskstats.c @@ -554,24 +554,27 @@ static int taskstats_user_cmd(struct sk_buff *skb, struct genl_info *info) static struct taskstats *taskstats_tgid_alloc(struct task_struct *tsk) { struct signal_struct *sig = tsk->signal; - struct taskstats *stats; + struct taskstats *stats_new, *stats; - if (sig->stats || thread_group_empty(tsk)) - goto ret; + /* Pairs with smp_store_release() below. */ + stats = READ_ONCE(sig->stats); + if (stats || thread_group_empty(tsk)) + return stats; /* No problem if kmem_cache_zalloc() fails */ - stats = kmem_cache_zalloc(taskstats_cache, GFP_KERNEL); + stats_new = kmem_cache_zalloc(taskstats_cache, GFP_KERNEL); spin_lock_irq(&tsk->sighand->siglock); if (!sig->stats) { - sig->stats = stats; - stats = NULL; + /* Pairs with READ_ONCE() above. */ + smp_store_release(&sig->stats, stats_new); + stats_new = NULL; } spin_unlock_irq(&tsk->sighand->siglock); - if (stats) - kmem_cache_free(taskstats_cache, stats); -ret: + if (stats_new) + kmem_cache_free(taskstats_cache, stats_new); + return sig->stats; } -- 2.23.0

4 years, 5 months

6
40
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror November 2019