Re: [PATCH] misc/pvpanic: resolve compile errors for arch=um
On Tue, Nov 27, 2018 at 03:47:28PM +0800, peng.h...@zte.com.cn wrote: > >> >On Fri, Nov 16, 2018 at 07:13:26PM +0800, Peng Hao wrote: > >> >> Resolve compile error for arch=um > >> >> pvpanic.c:(.text+0xb6): undefined reference to `devm_ioremap_resource' > >> >> > >> >> Signed-off-by: Peng Hao > >> >> --- > >> >> drivers/misc/Kconfig | 2 +- > >> >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> >What commit is this fixing? What broke and when did it break? > >> kbuildtestrobot reports this compile error for arch=um. > >> here is content: > >> " head: 24438e46268c721e14c5c888386af85c9e1c5db1 > >> commit: 77703e0b0326a1fb06b5cb5b468a633472c5a8e9 [10/26] misc/pvpanic : > >> break dependency on ACPI > > > >Ah, it is breaking because of your patch, not a patch in the kernel > >today. So please integrate this patch into your latest patch series > >when you redo your patches. > > > The series of patches has merged into "char-misc-next" > (https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/log/?h=char-misc-next), > Do I need to re-send the entire series of patches ? Ah, I didn't realize that. Ok, let me go dig this back up and add it to my tree, sorry for the noise... greg k-h
Re: [PATCH] misc/pvpanic: resolve compile errors for arch=um
On Tue, Nov 27, 2018 at 03:47:28PM +0800, peng.h...@zte.com.cn wrote: > >> >On Fri, Nov 16, 2018 at 07:13:26PM +0800, Peng Hao wrote: > >> >> Resolve compile error for arch=um > >> >> pvpanic.c:(.text+0xb6): undefined reference to `devm_ioremap_resource' > >> >> > >> >> Signed-off-by: Peng Hao > >> >> --- > >> >> drivers/misc/Kconfig | 2 +- > >> >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> >What commit is this fixing? What broke and when did it break? > >> kbuildtestrobot reports this compile error for arch=um. > >> here is content: > >> " head: 24438e46268c721e14c5c888386af85c9e1c5db1 > >> commit: 77703e0b0326a1fb06b5cb5b468a633472c5a8e9 [10/26] misc/pvpanic : > >> break dependency on ACPI > > > >Ah, it is breaking because of your patch, not a patch in the kernel > >today. So please integrate this patch into your latest patch series > >when you redo your patches. > > > The series of patches has merged into "char-misc-next" > (https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/log/?h=char-misc-next), > Do I need to re-send the entire series of patches ? Ah, I didn't realize that. Ok, let me go dig this back up and add it to my tree, sorry for the noise... greg k-h
Re: [PATCH] staging: rtl8188eu: Fix off-by-one in core/rtw_mlme_ext.c
On Tue, Nov 27, 2018 at 07:29:07AM +, Yang Xiao wrote: > From: Young_X Please use your "full" name like you did in your from: line of your email > > The error at line 3267 was the result of an off-by-one error in > a for loop in line 3253. > If condition in line 3254 never satisfies, then the value of > pstat->aid is NUM_STA+1. This will lead to out-of-bound access > in line 3267. Why is this indented? No need for that. Can you fix that up and resend? thanks, greg k-h
Re: [PATCH V2] mm: Replace all open encodings for NUMA_NO_NODE
Anshuman Khandual writes: > At present there are multiple places where invalid node number is encoded > as -1. Even though implicitly understood it is always better to have macros > in there. Replace these open encodings for an invalid node number with the > global macro NUMA_NO_NODE. This helps remove NUMA related assumptions like > 'invalid node' from various places redirecting them to a common definition. > > Signed-off-by: Anshuman Khandual > --- > Changes in V2: > > - Added inclusion of 'numa.h' header at various places per Andrew > - Updated 'dev_to_node' to use NUMA_NO_NODE instead per Vinod > > Changes in V1: (https://lkml.org/lkml/2018/11/23/485) > > - Dropped OCFS2 changes per Joseph > - Dropped media/video drivers changes per Hans > > RFC - https://patchwork.kernel.org/patch/10678035/ > > Build tested this with multiple cross compiler options like alpha, sparc, > arm64, x86, powerpc, powerpc64le etc with their default config which might > not have compiled tested all driver related changes. I will appreciate > folks giving this a test in their respective build environment. > > All these places for replacement were found by running the following grep > patterns on the entire kernel code. Please let me know if this might have > missed some instances. This might also have replaced some false positives. > I will appreciate suggestions, inputs and review. > > 1. git grep "nid == -1" > 2. git grep "node == -1" > 3. git grep "nid = -1" > 4. git grep "node = -1" > > arch/alpha/include/asm/topology.h | 3 ++- > arch/ia64/kernel/numa.c | 2 +- > arch/ia64/mm/discontig.c | 6 +++--- > arch/ia64/sn/kernel/io_common.c | 3 ++- > arch/powerpc/include/asm/pci-bridge.h | 3 ++- > arch/powerpc/kernel/paca.c| 3 ++- > arch/powerpc/kernel/pci-common.c | 3 ++- > arch/powerpc/mm/numa.c| 14 +++--- > arch/powerpc/platforms/powernv/memtrace.c | 5 +++-- These powerpc changes all look fine. Acked-by: Michael Ellerman cheers
Re: [PATCH] staging: rtl8188eu: Fix off-by-one in core/rtw_mlme_ext.c
On Tue, Nov 27, 2018 at 07:29:07AM +, Yang Xiao wrote: > From: Young_X Please use your "full" name like you did in your from: line of your email > > The error at line 3267 was the result of an off-by-one error in > a for loop in line 3253. > If condition in line 3254 never satisfies, then the value of > pstat->aid is NUM_STA+1. This will lead to out-of-bound access > in line 3267. Why is this indented? No need for that. Can you fix that up and resend? thanks, greg k-h
Re: [PATCH V2] mm: Replace all open encodings for NUMA_NO_NODE
Anshuman Khandual writes: > At present there are multiple places where invalid node number is encoded > as -1. Even though implicitly understood it is always better to have macros > in there. Replace these open encodings for an invalid node number with the > global macro NUMA_NO_NODE. This helps remove NUMA related assumptions like > 'invalid node' from various places redirecting them to a common definition. > > Signed-off-by: Anshuman Khandual > --- > Changes in V2: > > - Added inclusion of 'numa.h' header at various places per Andrew > - Updated 'dev_to_node' to use NUMA_NO_NODE instead per Vinod > > Changes in V1: (https://lkml.org/lkml/2018/11/23/485) > > - Dropped OCFS2 changes per Joseph > - Dropped media/video drivers changes per Hans > > RFC - https://patchwork.kernel.org/patch/10678035/ > > Build tested this with multiple cross compiler options like alpha, sparc, > arm64, x86, powerpc, powerpc64le etc with their default config which might > not have compiled tested all driver related changes. I will appreciate > folks giving this a test in their respective build environment. > > All these places for replacement were found by running the following grep > patterns on the entire kernel code. Please let me know if this might have > missed some instances. This might also have replaced some false positives. > I will appreciate suggestions, inputs and review. > > 1. git grep "nid == -1" > 2. git grep "node == -1" > 3. git grep "nid = -1" > 4. git grep "node = -1" > > arch/alpha/include/asm/topology.h | 3 ++- > arch/ia64/kernel/numa.c | 2 +- > arch/ia64/mm/discontig.c | 6 +++--- > arch/ia64/sn/kernel/io_common.c | 3 ++- > arch/powerpc/include/asm/pci-bridge.h | 3 ++- > arch/powerpc/kernel/paca.c| 3 ++- > arch/powerpc/kernel/pci-common.c | 3 ++- > arch/powerpc/mm/numa.c| 14 +++--- > arch/powerpc/platforms/powernv/memtrace.c | 5 +++-- These powerpc changes all look fine. Acked-by: Michael Ellerman cheers
Re: [PATCH anybus v4 1/7] fieldbus_dev: add Fieldbus Device subsystem.
On Wed, Nov 21, 2018 at 10:07:03AM -0500, thesve...@gmail.com wrote:
> +static struct attribute *fieldbus_attrs[] = {
> + _attr_enabled.attr,
> + _attr_card_name.attr,
> + _attr_fieldbus_id.attr,
> + _attr_read_area_size.attr,
> + _attr_write_area_size.attr,
> + _attr_online.attr,
> + _attr_fieldbus_type.attr,
> + NULL,
> +};
> +
> +static umode_t fieldbus_is_visible(struct kobject *kobj, struct attribute
> *attr,
> + int n)
> +{
> + struct device *dev = container_of(kobj, struct device, kobj);
> + struct fieldbus_dev *fb = dev_get_drvdata(dev);
> + umode_t mode = attr->mode;
> +
> + if (attr == _attr_enabled.attr) {
> + mode = 0;
> + if (fb->enable_get)
> + mode |= 0444;
> + if (fb->simple_enable_set)
> + mode |= 0200;
> + }
> +
> + return mode;
> +}
> +
> +static const struct attribute_group fieldbus_group = {
> + .attrs = fieldbus_attrs,
> + .is_visible = fieldbus_is_visible,
> +};
> +__ATTRIBUTE_GROUPS(fieldbus);
Why not just use ATTRIBUTE_GROUPS()?
> +static int __fieldbus_dev_register(struct fieldbus_dev *fb)
> +{
> + dev_t devno;
> + int err;
> +
> + if (!fb)
> + return -EINVAL;
> + if (!fb->read_area || !fb->write_area || !fb->fieldbus_id_get)
> + return -EINVAL;
> + fb->id = ida_simple_get(_ida, 0, MAX_FIELDBUSES, GFP_KERNEL);
> + if (fb->id < 0)
> + return fb->id;
> + devno = MKDEV(MAJOR(fieldbus_devt), fb->id);
> + init_waitqueue_head(>dc_wq);
> + cdev_init(>cdev, _fops);
> + err = cdev_add(>cdev, devno, 1);
> + if (err) {
> + pr_err("fieldbus_dev%d unable to add device %d:%d\n",
> + fb->id, MAJOR(fieldbus_devt), fb->id);
> + goto err_cdev;
> + }
Why do you have a static cdev?
> + fb->dev = device_create(_class, fb->parent, devno, fb,
> + "fieldbus_dev%d", fb->id);
> + if (IS_ERR(fb->dev)) {
> + err = PTR_ERR(fb->dev);
> + goto err_dev_create;
> + }
> + fb->online_sd = sysfs_get_dirent(fb->dev->kobj.sd, "online");
Ick, what? Why? Why are you messing around with a raw sysfs attribute?
Also, you are creating sysfs files and you are not documenting any of
them in Documentation/ABI/ which is not allowed. Please add that to
this patch for the next round.
thanks,
greg k-h
Re: [PATCH anybus v4 1/7] fieldbus_dev: add Fieldbus Device subsystem.
On Wed, Nov 21, 2018 at 10:07:03AM -0500, thesve...@gmail.com wrote:
> +static struct attribute *fieldbus_attrs[] = {
> + _attr_enabled.attr,
> + _attr_card_name.attr,
> + _attr_fieldbus_id.attr,
> + _attr_read_area_size.attr,
> + _attr_write_area_size.attr,
> + _attr_online.attr,
> + _attr_fieldbus_type.attr,
> + NULL,
> +};
> +
> +static umode_t fieldbus_is_visible(struct kobject *kobj, struct attribute
> *attr,
> + int n)
> +{
> + struct device *dev = container_of(kobj, struct device, kobj);
> + struct fieldbus_dev *fb = dev_get_drvdata(dev);
> + umode_t mode = attr->mode;
> +
> + if (attr == _attr_enabled.attr) {
> + mode = 0;
> + if (fb->enable_get)
> + mode |= 0444;
> + if (fb->simple_enable_set)
> + mode |= 0200;
> + }
> +
> + return mode;
> +}
> +
> +static const struct attribute_group fieldbus_group = {
> + .attrs = fieldbus_attrs,
> + .is_visible = fieldbus_is_visible,
> +};
> +__ATTRIBUTE_GROUPS(fieldbus);
Why not just use ATTRIBUTE_GROUPS()?
> +static int __fieldbus_dev_register(struct fieldbus_dev *fb)
> +{
> + dev_t devno;
> + int err;
> +
> + if (!fb)
> + return -EINVAL;
> + if (!fb->read_area || !fb->write_area || !fb->fieldbus_id_get)
> + return -EINVAL;
> + fb->id = ida_simple_get(_ida, 0, MAX_FIELDBUSES, GFP_KERNEL);
> + if (fb->id < 0)
> + return fb->id;
> + devno = MKDEV(MAJOR(fieldbus_devt), fb->id);
> + init_waitqueue_head(>dc_wq);
> + cdev_init(>cdev, _fops);
> + err = cdev_add(>cdev, devno, 1);
> + if (err) {
> + pr_err("fieldbus_dev%d unable to add device %d:%d\n",
> + fb->id, MAJOR(fieldbus_devt), fb->id);
> + goto err_cdev;
> + }
Why do you have a static cdev?
> + fb->dev = device_create(_class, fb->parent, devno, fb,
> + "fieldbus_dev%d", fb->id);
> + if (IS_ERR(fb->dev)) {
> + err = PTR_ERR(fb->dev);
> + goto err_dev_create;
> + }
> + fb->online_sd = sysfs_get_dirent(fb->dev->kobj.sd, "online");
Ick, what? Why? Why are you messing around with a raw sysfs attribute?
Also, you are creating sysfs files and you are not documenting any of
them in Documentation/ABI/ which is not allowed. Please add that to
this patch for the next round.
thanks,
greg k-h
Re: [PATCH 2/2] gpio: mt7621: pass mediatek_gpio_bank_probe() failure up the stack
Nicholas Mc Guire 於 2018年11月21日 週三 上午10:13寫道：
>
> The error cases of mediatek_gpio_bank_probe() would go unnoticed (except
> for the dev_err() messages). The probe function should return an error
> if one of the banks failed to initialize properly.
>
> Signed-off-by: Nicholas Mc Guire
> Fixes: 4ba9c3afda41 ("gpio: mt7621: Add a driver for MT7621")
> ---
>
> Patch was compile tested with: omega2p_defconfig, SOC_MT7621=y,
> GPIOLIB=y, GPIO_MT7621=y
>
> Patch is against 4.20-rc3 (localversion-next is next-20181121)
>
> drivers/gpio/gpio-mt7621.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpio/gpio-mt7621.c b/drivers/gpio/gpio-mt7621.c
> index 1ec95bc..68fca8b 100644
> --- a/drivers/gpio/gpio-mt7621.c
> +++ b/drivers/gpio/gpio-mt7621.c
> @@ -297,6 +297,7 @@ mediatek_gpio_probe(struct platform_device *pdev)
> struct device_node *np = dev->of_node;
> struct mtk *mtk;
> int i;
> + int ret;
>
> mtk = devm_kzalloc(dev, sizeof(*mtk), GFP_KERNEL);
> if (!mtk)
> @@ -311,8 +312,11 @@ mediatek_gpio_probe(struct platform_device *pdev)
> platform_set_drvdata(pdev, mtk);
> mediatek_gpio_irq_chip.name = dev_name(dev);
>
> - for (i = 0; i < MTK_BANK_CNT; i++)
> - mediatek_gpio_bank_probe(dev, np, i);
> + for (i = 0; i < MTK_BANK_CNT; i++) {
> + ret = mediatek_gpio_bank_probe(dev, np, i);
> + if (!ret)
it should be if (ret < 0) ?
> + return ret;
> + }
>
> return 0;
> }
> --
> 2.1.4
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH 2/2] gpio: mt7621: pass mediatek_gpio_bank_probe() failure up the stack
Nicholas Mc Guire 於 2018年11月21日 週三 上午10:13寫道：
>
> The error cases of mediatek_gpio_bank_probe() would go unnoticed (except
> for the dev_err() messages). The probe function should return an error
> if one of the banks failed to initialize properly.
>
> Signed-off-by: Nicholas Mc Guire
> Fixes: 4ba9c3afda41 ("gpio: mt7621: Add a driver for MT7621")
> ---
>
> Patch was compile tested with: omega2p_defconfig, SOC_MT7621=y,
> GPIOLIB=y, GPIO_MT7621=y
>
> Patch is against 4.20-rc3 (localversion-next is next-20181121)
>
> drivers/gpio/gpio-mt7621.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpio/gpio-mt7621.c b/drivers/gpio/gpio-mt7621.c
> index 1ec95bc..68fca8b 100644
> --- a/drivers/gpio/gpio-mt7621.c
> +++ b/drivers/gpio/gpio-mt7621.c
> @@ -297,6 +297,7 @@ mediatek_gpio_probe(struct platform_device *pdev)
> struct device_node *np = dev->of_node;
> struct mtk *mtk;
> int i;
> + int ret;
>
> mtk = devm_kzalloc(dev, sizeof(*mtk), GFP_KERNEL);
> if (!mtk)
> @@ -311,8 +312,11 @@ mediatek_gpio_probe(struct platform_device *pdev)
> platform_set_drvdata(pdev, mtk);
> mediatek_gpio_irq_chip.name = dev_name(dev);
>
> - for (i = 0; i < MTK_BANK_CNT; i++)
> - mediatek_gpio_bank_probe(dev, np, i);
> + for (i = 0; i < MTK_BANK_CNT; i++) {
> + ret = mediatek_gpio_bank_probe(dev, np, i);
> + if (!ret)
it should be if (ret < 0) ?
> + return ret;
> + }
>
> return 0;
> }
> --
> 2.1.4
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH anybus v4 1/7] fieldbus_dev: add Fieldbus Device subsystem.
On Wed, Nov 21, 2018 at 10:07:03AM -0500, thesve...@gmail.com wrote: > Fieldbus device (client) adapters allow data exchange with a PLC aka. > "Fieldbus Controller" over a fieldbus (Profinet, FLNet, etc.) > > They are typically used when a Linux device wants to expose itself > as an actuator, motor, console light, switch, etc. over the fieldbus. > > This framework is designed to provide a generic interface to Fieldbus > Devices from both the Linux Kernel and the userspace. > > Signed-off-by: Sven Van Asbroeck Your "From:" line does not match this address or name at all, which means no one can apply this :( Please fix for your next round of patches. thanks, greg k-h
[PATCH V2] can: flexcan: implement can Runtime PM
From: Aisheng Dong
Flexcan will be disabled during suspend if no wakeup function required and
enabled after resume accordingly. During this period, we could explicitly
disable clocks.
Implement Runtime PM which will:
1) Keep device in suspend state (clocks disabled) if it's not openned.
2) Make Power Domain framework be able to shutdown the corresponding power
domain of this device.
Signed-off-by: Aisheng Dong
Signed-off-by: Joakim Zhang
---
ChangeLog:
V1->V2:
*rebased on patch "can: flexcan: add self wakeup support".
*add check when to do flexcan_clks_disable/enable() during
Runtime PM.
---
drivers/net/can/flexcan.c | 119 --
1 file changed, 77 insertions(+), 42 deletions(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index d12b2f7d2834..130a2cb04827 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
@@ -277,6 +278,7 @@ struct flexcan_priv {
u32 reg_imask1_default;
u32 reg_imask2_default;
+ struct device *dev;
struct clk *clk_ipg;
struct clk *clk_per;
const struct flexcan_devtype_data *devtype_data;
@@ -444,6 +446,27 @@ static inline void flexcan_error_irq_disable(const struct
flexcan_priv *priv)
priv->write(reg_ctrl, >ctrl);
}
+static int flexcan_clks_enable(const struct flexcan_priv *priv)
+{
+ int err;
+
+ err = clk_prepare_enable(priv->clk_ipg);
+ if (err)
+ return err;
+
+ err = clk_prepare_enable(priv->clk_per);
+ if (err)
+ clk_disable_unprepare(priv->clk_ipg);
+
+ return err;
+}
+
+static void flexcan_clks_disable(const struct flexcan_priv *priv)
+{
+ clk_disable_unprepare(priv->clk_ipg);
+ clk_disable_unprepare(priv->clk_per);
+}
+
static inline int flexcan_transceiver_enable(const struct flexcan_priv *priv)
{
if (!priv->reg_xceiver)
@@ -570,19 +593,11 @@ static int flexcan_get_berr_counter(const struct
net_device *dev,
const struct flexcan_priv *priv = netdev_priv(dev);
int err;
- err = clk_prepare_enable(priv->clk_ipg);
- if (err)
- return err;
-
- err = clk_prepare_enable(priv->clk_per);
- if (err)
- goto out_disable_ipg;
+ pm_runtime_get_sync(priv->dev);
err = __flexcan_get_berr_counter(dev, bec);
- clk_disable_unprepare(priv->clk_per);
- out_disable_ipg:
- clk_disable_unprepare(priv->clk_ipg);
+ pm_runtime_put(priv->dev);
return err;
}
@@ -1215,17 +1230,13 @@ static int flexcan_open(struct net_device *dev)
struct flexcan_priv *priv = netdev_priv(dev);
int err;
- err = clk_prepare_enable(priv->clk_ipg);
+ err = pm_runtime_get_sync(priv->dev);
if (err)
return err;
- err = clk_prepare_enable(priv->clk_per);
- if (err)
- goto out_disable_ipg;
-
err = open_candev(dev);
if (err)
- goto out_disable_per;
+ goto out_pm_runtime;
err = request_irq(dev->irq, flexcan_irq, IRQF_SHARED, dev->name, dev);
if (err)
@@ -1288,10 +1299,8 @@ static int flexcan_open(struct net_device *dev)
free_irq(dev->irq, dev);
out_close:
close_candev(dev);
- out_disable_per:
- clk_disable_unprepare(priv->clk_per);
- out_disable_ipg:
- clk_disable_unprepare(priv->clk_ipg);
+ out_pm_runtime:
+ pm_runtime_put(priv->dev);
return err;
}
@@ -1306,11 +1315,11 @@ static int flexcan_close(struct net_device *dev)
can_rx_offload_del(>offload);
free_irq(dev->irq, dev);
- clk_disable_unprepare(priv->clk_per);
- clk_disable_unprepare(priv->clk_ipg);
close_candev(dev);
+ pm_runtime_put(priv->dev);
+
can_led_event(dev, CAN_LED_EVENT_STOP);
return 0;
@@ -1349,18 +1358,10 @@ static int register_flexcandev(struct net_device *dev)
struct flexcan_regs __iomem *regs = priv->regs;
u32 reg, err;
- err = clk_prepare_enable(priv->clk_ipg);
- if (err)
- return err;
-
- err = clk_prepare_enable(priv->clk_per);
- if (err)
- goto out_disable_ipg;
-
/* select "bus clock", chip must be disabled */
err = flexcan_chip_disable(priv);
if (err)
- goto out_disable_per;
+ return err;
reg = priv->read(>ctrl);
reg |= FLEXCAN_CTRL_CLK_SRC;
priv->write(reg, >ctrl);
@@ -1389,13 +1390,8 @@ static int register_flexcandev(struct net_device *dev)
err = register_candev(dev);
- /* disable core and turn off clocks */
out_chip_disable:
flexcan_chip_disable(priv);
- out_disable_per:
- clk_disable_unprepare(priv->clk_per);
- out_disable_ipg:
- clk_disable_unprepare(priv->clk_ipg);
Re: [PATCH anybus v4 1/7] fieldbus_dev: add Fieldbus Device subsystem.
On Wed, Nov 21, 2018 at 10:07:03AM -0500, thesve...@gmail.com wrote: > Fieldbus device (client) adapters allow data exchange with a PLC aka. > "Fieldbus Controller" over a fieldbus (Profinet, FLNet, etc.) > > They are typically used when a Linux device wants to expose itself > as an actuator, motor, console light, switch, etc. over the fieldbus. > > This framework is designed to provide a generic interface to Fieldbus > Devices from both the Linux Kernel and the userspace. > > Signed-off-by: Sven Van Asbroeck Your "From:" line does not match this address or name at all, which means no one can apply this :( Please fix for your next round of patches. thanks, greg k-h
[PATCH V2] can: flexcan: implement can Runtime PM
From: Aisheng Dong
Flexcan will be disabled during suspend if no wakeup function required and
enabled after resume accordingly. During this period, we could explicitly
disable clocks.
Implement Runtime PM which will:
1) Keep device in suspend state (clocks disabled) if it's not openned.
2) Make Power Domain framework be able to shutdown the corresponding power
domain of this device.
Signed-off-by: Aisheng Dong
Signed-off-by: Joakim Zhang
---
ChangeLog:
V1->V2:
*rebased on patch "can: flexcan: add self wakeup support".
*add check when to do flexcan_clks_disable/enable() during
Runtime PM.
---
drivers/net/can/flexcan.c | 119 --
1 file changed, 77 insertions(+), 42 deletions(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index d12b2f7d2834..130a2cb04827 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
@@ -277,6 +278,7 @@ struct flexcan_priv {
u32 reg_imask1_default;
u32 reg_imask2_default;
+ struct device *dev;
struct clk *clk_ipg;
struct clk *clk_per;
const struct flexcan_devtype_data *devtype_data;
@@ -444,6 +446,27 @@ static inline void flexcan_error_irq_disable(const struct
flexcan_priv *priv)
priv->write(reg_ctrl, >ctrl);
}
+static int flexcan_clks_enable(const struct flexcan_priv *priv)
+{
+ int err;
+
+ err = clk_prepare_enable(priv->clk_ipg);
+ if (err)
+ return err;
+
+ err = clk_prepare_enable(priv->clk_per);
+ if (err)
+ clk_disable_unprepare(priv->clk_ipg);
+
+ return err;
+}
+
+static void flexcan_clks_disable(const struct flexcan_priv *priv)
+{
+ clk_disable_unprepare(priv->clk_ipg);
+ clk_disable_unprepare(priv->clk_per);
+}
+
static inline int flexcan_transceiver_enable(const struct flexcan_priv *priv)
{
if (!priv->reg_xceiver)
@@ -570,19 +593,11 @@ static int flexcan_get_berr_counter(const struct
net_device *dev,
const struct flexcan_priv *priv = netdev_priv(dev);
int err;
- err = clk_prepare_enable(priv->clk_ipg);
- if (err)
- return err;
-
- err = clk_prepare_enable(priv->clk_per);
- if (err)
- goto out_disable_ipg;
+ pm_runtime_get_sync(priv->dev);
err = __flexcan_get_berr_counter(dev, bec);
- clk_disable_unprepare(priv->clk_per);
- out_disable_ipg:
- clk_disable_unprepare(priv->clk_ipg);
+ pm_runtime_put(priv->dev);
return err;
}
@@ -1215,17 +1230,13 @@ static int flexcan_open(struct net_device *dev)
struct flexcan_priv *priv = netdev_priv(dev);
int err;
- err = clk_prepare_enable(priv->clk_ipg);
+ err = pm_runtime_get_sync(priv->dev);
if (err)
return err;
- err = clk_prepare_enable(priv->clk_per);
- if (err)
- goto out_disable_ipg;
-
err = open_candev(dev);
if (err)
- goto out_disable_per;
+ goto out_pm_runtime;
err = request_irq(dev->irq, flexcan_irq, IRQF_SHARED, dev->name, dev);
if (err)
@@ -1288,10 +1299,8 @@ static int flexcan_open(struct net_device *dev)
free_irq(dev->irq, dev);
out_close:
close_candev(dev);
- out_disable_per:
- clk_disable_unprepare(priv->clk_per);
- out_disable_ipg:
- clk_disable_unprepare(priv->clk_ipg);
+ out_pm_runtime:
+ pm_runtime_put(priv->dev);
return err;
}
@@ -1306,11 +1315,11 @@ static int flexcan_close(struct net_device *dev)
can_rx_offload_del(>offload);
free_irq(dev->irq, dev);
- clk_disable_unprepare(priv->clk_per);
- clk_disable_unprepare(priv->clk_ipg);
close_candev(dev);
+ pm_runtime_put(priv->dev);
+
can_led_event(dev, CAN_LED_EVENT_STOP);
return 0;
@@ -1349,18 +1358,10 @@ static int register_flexcandev(struct net_device *dev)
struct flexcan_regs __iomem *regs = priv->regs;
u32 reg, err;
- err = clk_prepare_enable(priv->clk_ipg);
- if (err)
- return err;
-
- err = clk_prepare_enable(priv->clk_per);
- if (err)
- goto out_disable_ipg;
-
/* select "bus clock", chip must be disabled */
err = flexcan_chip_disable(priv);
if (err)
- goto out_disable_per;
+ return err;
reg = priv->read(>ctrl);
reg |= FLEXCAN_CTRL_CLK_SRC;
priv->write(reg, >ctrl);
@@ -1389,13 +1390,8 @@ static int register_flexcandev(struct net_device *dev)
err = register_candev(dev);
- /* disable core and turn off clocks */
out_chip_disable:
flexcan_chip_disable(priv);
- out_disable_per:
- clk_disable_unprepare(priv->clk_per);
- out_disable_ipg:
- clk_disable_unprepare(priv->clk_ipg);
Re: [PATCH anybus v4 1/7] fieldbus_dev: add Fieldbus Device subsystem.
On Wed, Nov 21, 2018 at 10:07:03AM -0500, thesve...@gmail.com wrote:
> Fieldbus device (client) adapters allow data exchange with a PLC aka.
> "Fieldbus Controller" over a fieldbus (Profinet, FLNet, etc.)
>
> They are typically used when a Linux device wants to expose itself
> as an actuator, motor, console light, switch, etc. over the fieldbus.
>
> This framework is designed to provide a generic interface to Fieldbus
> Devices from both the Linux Kernel and the userspace.
>
> Signed-off-by: Sven Van Asbroeck
License nit:
> --- /dev/null
> +++ b/drivers/fieldbus/dev_core.c
> @@ -0,0 +1,355 @@
> +// SPDX-License-Identifier: GPL-2.0
That's great, but then you write:
> +MODULE_LICENSE("GPL");
Which means "GPLv2+". So this MODULE_LICENSE() should be "GPL v2",
right?
thanks,
greg k-h
Re: [PATCH] xen/x86: add diagnostic printout to xen_mc_flush() in case of error
On 26/11/2018 21:11, Boris Ostrovsky wrote:
> On 11/23/18 11:24 AM, Juergen Gross wrote:
>> Failure of an element of a Xen multicall is signalled via a WARN()
>> only unless the kernel is compiled with MC_DEBUG. It is impossible to
>
> s/unless/if
>
>
>> know which element failed and why it did so.
>>
>> Change that by printing the related information even without MC_DEBUG,
>> even if maybe in some limited form (e.g. without information which
>> caller produced the failing element).
>>
>> Move the printing out of the switch statement in order to have the
>> same information for a single call.
>>
>> Signed-off-by: Juergen Gross
>> ---
>> arch/x86/xen/multicalls.c | 35 ---
>> 1 file changed, 20 insertions(+), 15 deletions(-)
>>
>> diff --git a/arch/x86/xen/multicalls.c b/arch/x86/xen/multicalls.c
>> index 2bce7958ce8b..0766a08bdf45 100644
>> --- a/arch/x86/xen/multicalls.c
>> +++ b/arch/x86/xen/multicalls.c
>> @@ -69,6 +69,11 @@ void xen_mc_flush(void)
>>
>> trace_xen_mc_flush(b->mcidx, b->argidx, b->cbidx);
>>
>> +#if MC_DEBUG
>> +memcpy(b->debug, b->entries,
>> + b->mcidx * sizeof(struct multicall_entry));
>> +#endif
>> +
>> switch (b->mcidx) {
>> case 0:
>> /* no-op */
>> @@ -87,32 +92,34 @@ void xen_mc_flush(void)
>> break;
>>
>> default:
>> -#if MC_DEBUG
>> -memcpy(b->debug, b->entries,
>> - b->mcidx * sizeof(struct multicall_entry));
>> -#endif
>> -
>> if (HYPERVISOR_multicall(b->entries, b->mcidx) != 0)
>> BUG();
>> for (i = 0; i < b->mcidx; i++)
>> if (b->entries[i].result < 0)
>> ret++;
>> +}
>>
>> +if (WARN_ON(ret)) {
>> +pr_err("%d of %d multicall(s) failed: cpu %d\n",
>> + ret, b->mcidx, smp_processor_id());
>> +for (i = 0; i < b->mcidx; i++) {
>> +if (b->entries[i].result < 0) {
>> #if MC_DEBUG
>> -if (ret) {
>> -printk(KERN_ERR "%d multicall(s) failed: cpu %d\n",
>> - ret, smp_processor_id());
>> -dump_stack();
>> -for (i = 0; i < b->mcidx; i++) {
>> -printk(KERN_DEBUG " call %2d/%d: op=%lu
>> arg=[%lx] result=%ld\t%pF\n",
>> - i+1, b->mcidx,
>> +pr_err(" call %2d: op=%lu arg=[%lx]
>> result=%ld\t%pF\n",
>> + i + 1,
>> b->debug[i].op,
>> b->debug[i].args[0],
>> b->entries[i].result,
>> b->caller[i]);
>> +#else
>> +pr_err(" call %2d: op=%lu arg=[%lx]
>> result=%ld\n",
>> + i + 1,
>> + b->entries[i].op,
>> + b->entries[i].args[0],
>> + b->entries[i].result);
>> +#endif
>
> Doesn't (non-debug) hypervisor corrupt op and args?
No. Only debug hypervisor does so.
See my patch (and rather lengthy discussion) on xen-devel:
https://lists.xen.org/archives/html/xen-devel/2018-11/msg02714.html
>
> (Also, we don't really need to print anything when b->entries[i].result
> == 0)
Right. Did you miss the:
+ if (b->entries[i].result < 0) {
above?
Juergen
Re: [PATCH anybus v4 1/7] fieldbus_dev: add Fieldbus Device subsystem.
On Wed, Nov 21, 2018 at 10:07:03AM -0500, thesve...@gmail.com wrote:
> Fieldbus device (client) adapters allow data exchange with a PLC aka.
> "Fieldbus Controller" over a fieldbus (Profinet, FLNet, etc.)
>
> They are typically used when a Linux device wants to expose itself
> as an actuator, motor, console light, switch, etc. over the fieldbus.
>
> This framework is designed to provide a generic interface to Fieldbus
> Devices from both the Linux Kernel and the userspace.
>
> Signed-off-by: Sven Van Asbroeck
License nit:
> --- /dev/null
> +++ b/drivers/fieldbus/dev_core.c
> @@ -0,0 +1,355 @@
> +// SPDX-License-Identifier: GPL-2.0
That's great, but then you write:
> +MODULE_LICENSE("GPL");
Which means "GPLv2+". So this MODULE_LICENSE() should be "GPL v2",
right?
thanks,
greg k-h
Re: [PATCH] xen/x86: add diagnostic printout to xen_mc_flush() in case of error
On 26/11/2018 21:11, Boris Ostrovsky wrote:
> On 11/23/18 11:24 AM, Juergen Gross wrote:
>> Failure of an element of a Xen multicall is signalled via a WARN()
>> only unless the kernel is compiled with MC_DEBUG. It is impossible to
>
> s/unless/if
>
>
>> know which element failed and why it did so.
>>
>> Change that by printing the related information even without MC_DEBUG,
>> even if maybe in some limited form (e.g. without information which
>> caller produced the failing element).
>>
>> Move the printing out of the switch statement in order to have the
>> same information for a single call.
>>
>> Signed-off-by: Juergen Gross
>> ---
>> arch/x86/xen/multicalls.c | 35 ---
>> 1 file changed, 20 insertions(+), 15 deletions(-)
>>
>> diff --git a/arch/x86/xen/multicalls.c b/arch/x86/xen/multicalls.c
>> index 2bce7958ce8b..0766a08bdf45 100644
>> --- a/arch/x86/xen/multicalls.c
>> +++ b/arch/x86/xen/multicalls.c
>> @@ -69,6 +69,11 @@ void xen_mc_flush(void)
>>
>> trace_xen_mc_flush(b->mcidx, b->argidx, b->cbidx);
>>
>> +#if MC_DEBUG
>> +memcpy(b->debug, b->entries,
>> + b->mcidx * sizeof(struct multicall_entry));
>> +#endif
>> +
>> switch (b->mcidx) {
>> case 0:
>> /* no-op */
>> @@ -87,32 +92,34 @@ void xen_mc_flush(void)
>> break;
>>
>> default:
>> -#if MC_DEBUG
>> -memcpy(b->debug, b->entries,
>> - b->mcidx * sizeof(struct multicall_entry));
>> -#endif
>> -
>> if (HYPERVISOR_multicall(b->entries, b->mcidx) != 0)
>> BUG();
>> for (i = 0; i < b->mcidx; i++)
>> if (b->entries[i].result < 0)
>> ret++;
>> +}
>>
>> +if (WARN_ON(ret)) {
>> +pr_err("%d of %d multicall(s) failed: cpu %d\n",
>> + ret, b->mcidx, smp_processor_id());
>> +for (i = 0; i < b->mcidx; i++) {
>> +if (b->entries[i].result < 0) {
>> #if MC_DEBUG
>> -if (ret) {
>> -printk(KERN_ERR "%d multicall(s) failed: cpu %d\n",
>> - ret, smp_processor_id());
>> -dump_stack();
>> -for (i = 0; i < b->mcidx; i++) {
>> -printk(KERN_DEBUG " call %2d/%d: op=%lu
>> arg=[%lx] result=%ld\t%pF\n",
>> - i+1, b->mcidx,
>> +pr_err(" call %2d: op=%lu arg=[%lx]
>> result=%ld\t%pF\n",
>> + i + 1,
>> b->debug[i].op,
>> b->debug[i].args[0],
>> b->entries[i].result,
>> b->caller[i]);
>> +#else
>> +pr_err(" call %2d: op=%lu arg=[%lx]
>> result=%ld\n",
>> + i + 1,
>> + b->entries[i].op,
>> + b->entries[i].args[0],
>> + b->entries[i].result);
>> +#endif
>
> Doesn't (non-debug) hypervisor corrupt op and args?
No. Only debug hypervisor does so.
See my patch (and rather lengthy discussion) on xen-devel:
https://lists.xen.org/archives/html/xen-devel/2018-11/msg02714.html
>
> (Also, we don't really need to print anything when b->entries[i].result
> == 0)
Right. Did you miss the:
+ if (b->entries[i].result < 0) {
above?
Juergen
[PATCH] mtd: nand: Fix memory allocation in nanddev_bbt_init()
Fix the size of the buffer allocated to store the in-memory BBT.
This bug was previously hidden by a different bug, that was fixed in
d098093ba06e.
Fixes: 9c3736a3de21 ("mtd: nand: Add core infrastructure to deal with NAND
devices")
Cc:
Signed-off-by: Frieder Schrempf
---
drivers/mtd/nand/bbt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/bbt.c b/drivers/mtd/nand/bbt.c
index 56cde38..c12497f 100644
--- a/drivers/mtd/nand/bbt.c
+++ b/drivers/mtd/nand/bbt.c
@@ -27,7 +27,8 @@ int nanddev_bbt_init(struct nand_device *nand)
unsigned int nwords = DIV_ROUND_UP(nblocks * bits_per_block,
BITS_PER_LONG);
- nand->bbt.cache = kzalloc(nwords, GFP_KERNEL);
+ nand->bbt.cache = kzalloc(nwords * (BITS_PER_LONG / BITS_PER_BYTE),
+ GFP_KERNEL);
if (!nand->bbt.cache)
return -ENOMEM;
--
2.7.4
[PATCH] mtd: nand: Fix memory allocation in nanddev_bbt_init()
Fix the size of the buffer allocated to store the in-memory BBT.
This bug was previously hidden by a different bug, that was fixed in
d098093ba06e.
Fixes: 9c3736a3de21 ("mtd: nand: Add core infrastructure to deal with NAND
devices")
Cc:
Signed-off-by: Frieder Schrempf
---
drivers/mtd/nand/bbt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/bbt.c b/drivers/mtd/nand/bbt.c
index 56cde38..c12497f 100644
--- a/drivers/mtd/nand/bbt.c
+++ b/drivers/mtd/nand/bbt.c
@@ -27,7 +27,8 @@ int nanddev_bbt_init(struct nand_device *nand)
unsigned int nwords = DIV_ROUND_UP(nblocks * bits_per_block,
BITS_PER_LONG);
- nand->bbt.cache = kzalloc(nwords, GFP_KERNEL);
+ nand->bbt.cache = kzalloc(nwords * (BITS_PER_LONG / BITS_PER_BYTE),
+ GFP_KERNEL);
if (!nand->bbt.cache)
return -ENOMEM;
--
2.7.4
Re: possible deadlock in ovl_write_iter
On Tue, Nov 27, 2018 at 9:06 AM syzbot
wrote:
>
> syzbot has found a reproducer for the following crash on:
>
> HEAD commit:6f8b52ba442c Merge tag 'hwmon-for-v4.20-rc5' of git://git...
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=120f390540
> kernel config: https://syzkaller.appspot.com/x/.config?x=c94f9f0c0363db4b
> dashboard link: https://syzkaller.appspot.com/bug?extid=695726bc473f9c36a4b6
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10cad22540
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1381309340
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+695726bc473f9c36a...@syzkaller.appspotmail.com
>
> overlayfs: filesystem on './file0' not supported as upperdir
>
> ==
> WARNING: possible circular locking dependency detected
> 4.20.0-rc4+ #351 Not tainted
> --
> syz-executor338/5996 is trying to acquire lock:
> b59bb66d (_i_mutex_key[depth]){+.+.}, at: inode_lock
> include/linux/fs.h:757 [inline]
> b59bb66d (_i_mutex_key[depth]){+.+.}, at:
> ovl_write_iter+0x151/0xd10 fs/overlayfs/file.c:231
>
> but task is already holding lock:
> e0274330 (>mutex/1){+.+.}, at: pipe_lock_nested fs/pipe.c:62
> [inline]
> e0274330 (>mutex/1){+.+.}, at: pipe_lock+0x6e/0x80
> fs/pipe.c:70
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
>
> -> #2 (>mutex/1){+.+.}:
> __mutex_lock_common kernel/locking/mutex.c:925 [inline]
> __mutex_lock+0x166/0x16f0 kernel/locking/mutex.c:1072
> mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1087
> pipe_lock_nested fs/pipe.c:62 [inline]
> pipe_lock+0x6e/0x80 fs/pipe.c:70
> iter_file_splice_write+0x27d/0x1050 fs/splice.c:700
> do_splice_from fs/splice.c:851 [inline]
> do_splice+0x64a/0x1430 fs/splice.c:1147
> __do_sys_splice fs/splice.c:1414 [inline]
> __se_sys_splice fs/splice.c:1394 [inline]
> __x64_sys_splice+0x2c1/0x330 fs/splice.c:1394
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> -> #1 (sb_writers#3){.+.+}:
> percpu_down_read_preempt_disable include/linux/percpu-rwsem.h:36
> [inline]
> percpu_down_read include/linux/percpu-rwsem.h:59 [inline]
> __sb_start_write+0x214/0x370 fs/super.c:1387
> sb_start_write include/linux/fs.h:1597 [inline]
> mnt_want_write+0x3f/0xc0 fs/namespace.c:360
> ovl_want_write+0x76/0xa0 fs/overlayfs/util.c:24
> ovl_setattr+0x10b/0xaf0 fs/overlayfs/inode.c:30
> notify_change+0xbde/0x1110 fs/attr.c:334
> do_truncate+0x1bd/0x2d0 fs/open.c:63
> handle_truncate fs/namei.c:3008 [inline]
> do_last fs/namei.c:3424 [inline]
> path_openat+0x375f/0x5150 fs/namei.c:3534
> do_filp_open+0x255/0x380 fs/namei.c:3564
> do_sys_open+0x568/0x700 fs/open.c:1063
> __do_sys_openat fs/open.c:1090 [inline]
> __se_sys_openat fs/open.c:1084 [inline]
> __x64_sys_openat+0x9d/0x100 fs/open.c:1084
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> -> #0 (_i_mutex_key[depth]){+.+.}:
> lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844
> down_write+0x8a/0x130 kernel/locking/rwsem.c:70
> inode_lock include/linux/fs.h:757 [inline]
> ovl_write_iter+0x151/0xd10 fs/overlayfs/file.c:231
> call_write_iter include/linux/fs.h:1857 [inline]
> new_sync_write fs/read_write.c:474 [inline]
> __vfs_write+0x6b8/0x9f0 fs/read_write.c:487
> __kernel_write+0x10c/0x370 fs/read_write.c:506
> write_pipe_buf+0x180/0x240 fs/splice.c:797
> splice_from_pipe_feed fs/splice.c:503 [inline]
> __splice_from_pipe+0x38b/0x7c0 fs/splice.c:627
> splice_from_pipe+0x1ec/0x340 fs/splice.c:662
> default_file_splice_write+0x3c/0x90 fs/splice.c:809
> do_splice_from fs/splice.c:851 [inline]
> do_splice+0x64a/0x1430 fs/splice.c:1147
> __do_sys_splice fs/splice.c:1414 [inline]
> __se_sys_splice fs/splice.c:1394 [inline]
> __x64_sys_splice+0x2c1/0x330 fs/splice.c:1394
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> other info that might help us debug this:
>
> Chain exists of:
>_i_mutex_key[depth] --> sb_writers#3 --> >mutex/1
>
> Possible unsafe locking scenario:
>
> CPU0CPU1
>
>lock(>mutex/1);
> lock(sb_writers#3);
> lock(>mutex/1);
>
Re: possible deadlock in ovl_write_iter
On Tue, Nov 27, 2018 at 9:06 AM syzbot
wrote:
>
> syzbot has found a reproducer for the following crash on:
>
> HEAD commit:6f8b52ba442c Merge tag 'hwmon-for-v4.20-rc5' of git://git...
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=120f390540
> kernel config: https://syzkaller.appspot.com/x/.config?x=c94f9f0c0363db4b
> dashboard link: https://syzkaller.appspot.com/bug?extid=695726bc473f9c36a4b6
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10cad22540
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1381309340
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+695726bc473f9c36a...@syzkaller.appspotmail.com
>
> overlayfs: filesystem on './file0' not supported as upperdir
>
> ==
> WARNING: possible circular locking dependency detected
> 4.20.0-rc4+ #351 Not tainted
> --
> syz-executor338/5996 is trying to acquire lock:
> b59bb66d (_i_mutex_key[depth]){+.+.}, at: inode_lock
> include/linux/fs.h:757 [inline]
> b59bb66d (_i_mutex_key[depth]){+.+.}, at:
> ovl_write_iter+0x151/0xd10 fs/overlayfs/file.c:231
>
> but task is already holding lock:
> e0274330 (>mutex/1){+.+.}, at: pipe_lock_nested fs/pipe.c:62
> [inline]
> e0274330 (>mutex/1){+.+.}, at: pipe_lock+0x6e/0x80
> fs/pipe.c:70
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
>
> -> #2 (>mutex/1){+.+.}:
> __mutex_lock_common kernel/locking/mutex.c:925 [inline]
> __mutex_lock+0x166/0x16f0 kernel/locking/mutex.c:1072
> mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1087
> pipe_lock_nested fs/pipe.c:62 [inline]
> pipe_lock+0x6e/0x80 fs/pipe.c:70
> iter_file_splice_write+0x27d/0x1050 fs/splice.c:700
> do_splice_from fs/splice.c:851 [inline]
> do_splice+0x64a/0x1430 fs/splice.c:1147
> __do_sys_splice fs/splice.c:1414 [inline]
> __se_sys_splice fs/splice.c:1394 [inline]
> __x64_sys_splice+0x2c1/0x330 fs/splice.c:1394
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> -> #1 (sb_writers#3){.+.+}:
> percpu_down_read_preempt_disable include/linux/percpu-rwsem.h:36
> [inline]
> percpu_down_read include/linux/percpu-rwsem.h:59 [inline]
> __sb_start_write+0x214/0x370 fs/super.c:1387
> sb_start_write include/linux/fs.h:1597 [inline]
> mnt_want_write+0x3f/0xc0 fs/namespace.c:360
> ovl_want_write+0x76/0xa0 fs/overlayfs/util.c:24
> ovl_setattr+0x10b/0xaf0 fs/overlayfs/inode.c:30
> notify_change+0xbde/0x1110 fs/attr.c:334
> do_truncate+0x1bd/0x2d0 fs/open.c:63
> handle_truncate fs/namei.c:3008 [inline]
> do_last fs/namei.c:3424 [inline]
> path_openat+0x375f/0x5150 fs/namei.c:3534
> do_filp_open+0x255/0x380 fs/namei.c:3564
> do_sys_open+0x568/0x700 fs/open.c:1063
> __do_sys_openat fs/open.c:1090 [inline]
> __se_sys_openat fs/open.c:1084 [inline]
> __x64_sys_openat+0x9d/0x100 fs/open.c:1084
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> -> #0 (_i_mutex_key[depth]){+.+.}:
> lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844
> down_write+0x8a/0x130 kernel/locking/rwsem.c:70
> inode_lock include/linux/fs.h:757 [inline]
> ovl_write_iter+0x151/0xd10 fs/overlayfs/file.c:231
> call_write_iter include/linux/fs.h:1857 [inline]
> new_sync_write fs/read_write.c:474 [inline]
> __vfs_write+0x6b8/0x9f0 fs/read_write.c:487
> __kernel_write+0x10c/0x370 fs/read_write.c:506
> write_pipe_buf+0x180/0x240 fs/splice.c:797
> splice_from_pipe_feed fs/splice.c:503 [inline]
> __splice_from_pipe+0x38b/0x7c0 fs/splice.c:627
> splice_from_pipe+0x1ec/0x340 fs/splice.c:662
> default_file_splice_write+0x3c/0x90 fs/splice.c:809
> do_splice_from fs/splice.c:851 [inline]
> do_splice+0x64a/0x1430 fs/splice.c:1147
> __do_sys_splice fs/splice.c:1414 [inline]
> __se_sys_splice fs/splice.c:1394 [inline]
> __x64_sys_splice+0x2c1/0x330 fs/splice.c:1394
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> other info that might help us debug this:
>
> Chain exists of:
>_i_mutex_key[depth] --> sb_writers#3 --> >mutex/1
>
> Possible unsafe locking scenario:
>
> CPU0CPU1
>
>lock(>mutex/1);
> lock(sb_writers#3);
> lock(>mutex/1);
>
Re: [PATCH 2/2] misc: hx8837: add a HiMax HX8837 display controller driver
On Mon, Nov 12, 2018 at 03:39:29AM +0100, Lubomir Rintel wrote: > HiMax HX8837 is a display controller used on OLPC platforms. It controls > backlight and is able to capture and freeze a frame when the LCD controller > (and the rest of the plaform) is powered off. > > This driver is based on the same code as drivers/staging/olpc_dcon. > I modernized it to use managed GPIO, device-tree bindings, sysfs attribtue > groups, essentially fixing the staging driver's TODO. You are creating custom sysfs files, with no Documentation/ABI/ update for us to know what those files are or how they are used :( Why do you need custom sysfs files in the first place? Isn't there already an api for this type of device in the kernel? thanks, greg k-h
Re: [PATCH 2/2] misc: hx8837: add a HiMax HX8837 display controller driver
On Mon, Nov 12, 2018 at 03:39:29AM +0100, Lubomir Rintel wrote: > HiMax HX8837 is a display controller used on OLPC platforms. It controls > backlight and is able to capture and freeze a frame when the LCD controller > (and the rest of the plaform) is powered off. > > This driver is based on the same code as drivers/staging/olpc_dcon. > I modernized it to use managed GPIO, device-tree bindings, sysfs attribtue > groups, essentially fixing the staging driver's TODO. You are creating custom sysfs files, with no Documentation/ABI/ update for us to know what those files are or how they are used :( Why do you need custom sysfs files in the first place? Isn't there already an api for this type of device in the kernel? thanks, greg k-h
Re: [PATCH] s390: Remove obsolete bust_spinlock() implementation
On Fri, 23 Nov 2018 08:02:12 +0100
Heiko Carstens wrote:
> On Fri, Nov 23, 2018 at 11:17:48AM +0900, Sergey Senozhatsky wrote:
> > On (11/22/18 15:15), Petr Mladek wrote:
> > > The commit cefc8be82403cf ("Consolidate bust_spinlocks()") kept
> > > the s390-specific implementation because of the absence of CONFIG_VT.
> > > In fact, the only difference was calling console_unblank() instead of
> > > unblank_screen().
> > >
> > > The common implementation in lib/bust_spinlocks.c started to call
> > > unblank_screen() explicitly since the commit b61312d353da187
> > > ("oops handling: ensure that any oops is flushed to the mtdoops
> > > console").
> > >
> > > As a result, the custom implementation is not longer necessary.
> > > And we could get all the other improvements of the common
> > > implementation for free.
> >
> > I believe I sent a similar patch several weeks ago and it's
> > in s390 patch queue as of now, waiting for the next merge
> > window.
> >
> > lkml.kernel.org/r/20181025081108.GB26561@osiris
>
> Yes, it will be added soon to the features branch of the
> s390/linux.git repository on kernel.org and then hit linux-next.
The patch is now queued for the next merge window.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
Re: [PATCH] s390: Remove obsolete bust_spinlock() implementation
On Fri, 23 Nov 2018 08:02:12 +0100
Heiko Carstens wrote:
> On Fri, Nov 23, 2018 at 11:17:48AM +0900, Sergey Senozhatsky wrote:
> > On (11/22/18 15:15), Petr Mladek wrote:
> > > The commit cefc8be82403cf ("Consolidate bust_spinlocks()") kept
> > > the s390-specific implementation because of the absence of CONFIG_VT.
> > > In fact, the only difference was calling console_unblank() instead of
> > > unblank_screen().
> > >
> > > The common implementation in lib/bust_spinlocks.c started to call
> > > unblank_screen() explicitly since the commit b61312d353da187
> > > ("oops handling: ensure that any oops is flushed to the mtdoops
> > > console").
> > >
> > > As a result, the custom implementation is not longer necessary.
> > > And we could get all the other improvements of the common
> > > implementation for free.
> >
> > I believe I sent a similar patch several weeks ago and it's
> > in s390 patch queue as of now, waiting for the next merge
> > window.
> >
> > lkml.kernel.org/r/20181025081108.GB26561@osiris
>
> Yes, it will be added soon to the features branch of the
> s390/linux.git repository on kernel.org and then hit linux-next.
The patch is now queued for the next merge window.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
Re: [PATCH 3/3] s390/mm: fix mis-accounting of pgtable_bytes
On Wed, Oct 31, 2018 at 01:36:23PM +0300, Kirill A. Shutemov wrote:
> On Wed, Oct 31, 2018 at 11:09:44AM +0100, Heiko Carstens wrote:
> > On Wed, Oct 31, 2018 at 07:31:49AM +0100, Martin Schwidefsky wrote:
> > > Thanks for testing. Unfortunately Heiko reported another issue yesterday
> > > with the patch applied. This time the other way around:
> > >
> > > BUG: non-zero pgtables_bytes on freeing mm: -16384
> > >
> > > I am trying to understand how this can happen. For now I would like to
> > > keep the patch on hold in case they need another change.
> >
> > FWIW, Kirill: is there a reason why this "BUG:" output is done with
> > pr_alert() and not with VM_BUG_ON() or one of the WARN*() variants?
> >
> > That would to get more information with DEBUG_VM and / or
> > panic_on_warn=1 set. At least for automated testing it would be nice
> > to have such triggers.
>
> Stack trace is not helpful there. It will always show the exit path which
> is useless.
So, even with the updated version of these patches I can flood dmesg
and the console with
BUG: non-zero pgtables_bytes on freeing mm: 16384
messages with this complex reproducer on s390:
echo "void main(void) {}" | gcc -m31 -xc -o compat - && ./compat
Besides that this needs to be fixed, I'd really like to see this
changed to either a printk_once() or a WARN_ON_ONCE() within
check_mm() so that an arbitrary user cannot flood the console.
E.g. something like the below. If there aren't any objections, I will
provide a proper patch with changelog, etc.
diff --git a/kernel/fork.c b/kernel/fork.c
index 07cddff89c7b..d7aeec03c57f 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -647,8 +647,8 @@ static void check_mm(struct mm_struct *mm)
}
if (mm_pgtables_bytes(mm))
- pr_alert("BUG: non-zero pgtables_bytes on freeing mm: %ld\n",
- mm_pgtables_bytes(mm));
+ printk_once(KERN_ALERT "BUG: non-zero pgtables_bytes on freeing
mm: %ld\n",
+ mm_pgtables_bytes(mm));
#if defined(CONFIG_TRANSPARENT_HUGEPAGE) && !USE_SPLIT_PMD_PTLOCKS
VM_BUG_ON_MM(mm->pmd_huge_pte, mm);
Re: [PATCH 3/3] s390/mm: fix mis-accounting of pgtable_bytes
On Wed, Oct 31, 2018 at 01:36:23PM +0300, Kirill A. Shutemov wrote:
> On Wed, Oct 31, 2018 at 11:09:44AM +0100, Heiko Carstens wrote:
> > On Wed, Oct 31, 2018 at 07:31:49AM +0100, Martin Schwidefsky wrote:
> > > Thanks for testing. Unfortunately Heiko reported another issue yesterday
> > > with the patch applied. This time the other way around:
> > >
> > > BUG: non-zero pgtables_bytes on freeing mm: -16384
> > >
> > > I am trying to understand how this can happen. For now I would like to
> > > keep the patch on hold in case they need another change.
> >
> > FWIW, Kirill: is there a reason why this "BUG:" output is done with
> > pr_alert() and not with VM_BUG_ON() or one of the WARN*() variants?
> >
> > That would to get more information with DEBUG_VM and / or
> > panic_on_warn=1 set. At least for automated testing it would be nice
> > to have such triggers.
>
> Stack trace is not helpful there. It will always show the exit path which
> is useless.
So, even with the updated version of these patches I can flood dmesg
and the console with
BUG: non-zero pgtables_bytes on freeing mm: 16384
messages with this complex reproducer on s390:
echo "void main(void) {}" | gcc -m31 -xc -o compat - && ./compat
Besides that this needs to be fixed, I'd really like to see this
changed to either a printk_once() or a WARN_ON_ONCE() within
check_mm() so that an arbitrary user cannot flood the console.
E.g. something like the below. If there aren't any objections, I will
provide a proper patch with changelog, etc.
diff --git a/kernel/fork.c b/kernel/fork.c
index 07cddff89c7b..d7aeec03c57f 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -647,8 +647,8 @@ static void check_mm(struct mm_struct *mm)
}
if (mm_pgtables_bytes(mm))
- pr_alert("BUG: non-zero pgtables_bytes on freeing mm: %ld\n",
- mm_pgtables_bytes(mm));
+ printk_once(KERN_ALERT "BUG: non-zero pgtables_bytes on freeing
mm: %ld\n",
+ mm_pgtables_bytes(mm));
#if defined(CONFIG_TRANSPARENT_HUGEPAGE) && !USE_SPLIT_PMD_PTLOCKS
VM_BUG_ON_MM(mm->pmd_huge_pte, mm);
Re: [patch 20/24] x86/speculation: Split out TIF update
On Tue, 27 Nov 2018, Thomas Gleixner wrote: > That's racy and does not prevent the situation because the TIF flags are > updated befor the UPDATE bit is set. > So __speculation_ctrl_update() might see the new bits, but not > TIF_SPEC_UPDATE. Hm, right, scratch that. We'd need to do that before updating TIF_SPEC_IB in task_update_spec_tif(), but that has the opposite ordering issue. Thanks, -- Jiri Kosina SUSE Labs
Re: [patch 20/24] x86/speculation: Split out TIF update
On Tue, 27 Nov 2018, Thomas Gleixner wrote: > That's racy and does not prevent the situation because the TIF flags are > updated befor the UPDATE bit is set. > So __speculation_ctrl_update() might see the new bits, but not > TIF_SPEC_UPDATE. Hm, right, scratch that. We'd need to do that before updating TIF_SPEC_IB in task_update_spec_tif(), but that has the opposite ordering issue. Thanks, -- Jiri Kosina SUSE Labs
Re: [PATCH] misc/pvpanic: resolve compile errors for arch=um
On Tue, Nov 27, 2018 at 08:27:03AM +0800, peng.h...@zte.com.cn wrote: > >On Fri, Nov 16, 2018 at 07:13:26PM +0800, Peng Hao wrote: > >> Resolve compile error for arch=um > >> pvpanic.c:(.text+0xb6): undefined reference to `devm_ioremap_resource' > >> > >> Signed-off-by: Peng Hao > >> --- > >> drivers/misc/Kconfig | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > > >What commit is this fixing? What broke and when did it break? > kbuildtestrobot reports this compile error for arch=um. > here is content: > " head: 24438e46268c721e14c5c888386af85c9e1c5db1 > commit: 77703e0b0326a1fb06b5cb5b468a633472c5a8e9 [10/26] misc/pvpanic : break > dependency on ACPI Ah, it is breaking because of your patch, not a patch in the kernel today. So please integrate this patch into your latest patch series when you redo your patches. thanks, greg k-h
Re: [PATCH] misc/pvpanic: resolve compile errors for arch=um
On Tue, Nov 27, 2018 at 08:27:03AM +0800, peng.h...@zte.com.cn wrote: > >On Fri, Nov 16, 2018 at 07:13:26PM +0800, Peng Hao wrote: > >> Resolve compile error for arch=um > >> pvpanic.c:(.text+0xb6): undefined reference to `devm_ioremap_resource' > >> > >> Signed-off-by: Peng Hao > >> --- > >> drivers/misc/Kconfig | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > > >What commit is this fixing? What broke and when did it break? > kbuildtestrobot reports this compile error for arch=um. > here is content: > " head: 24438e46268c721e14c5c888386af85c9e1c5db1 > commit: 77703e0b0326a1fb06b5cb5b468a633472c5a8e9 [10/26] misc/pvpanic : break > dependency on ACPI Ah, it is breaking because of your patch, not a patch in the kernel today. So please integrate this patch into your latest patch series when you redo your patches. thanks, greg k-h
Re: [PATCH] iio: st_sensors: Fix the sleep time for sampling
Jonathan Cameron 於 2018年11月25日 週日 下午9:23寫道： > > On Wed, 21 Nov 2018 13:13:40 +0800 > Jian-Hong Pan wrote: > > > Denis CIOCCA 於 2018年11月20日 週二 上午3:05寫道： > > > > > > Hi Jian, > > > > > > Not clear to me why should be + instead of *. > > > > > > ODR is expressed in Hz, so (1/Hz) = period in seconds (1 sample sampling > > > time) [s] > > > 1000 * (1/Hz) = period in milliseconds (1 sample sampling time) [ms] > > > n * 1000 * (1/Hz) = n times period in milliseconds (n times sample > > > sampling time) [ms] > > > > > > In your case you assume bootime is in milliseconds. > > > > Yes, I assume that according to the original comment. > > > > >Maybe we can change the comment and use 'number of samples ...'. > > > > Making the meaning more clear is better. > > > > However, does the bootime of the measurement need as the long time to > > be enabled? > > If the sampling rate is 1Hz and n is 2, then they will do msleep with > > 2000 ms for each st_sensors_read_info_raw. > > Superficially that seems correct as we need to be sure that a reading > has occurred. If you want it to be quicker than the ODR should be set > faster so that the reading shows up reasonably quickly. At 1Hz and > you want to drop 2 samples, it will indeed take 2 seconds. Now, I understand with the description. Thank you. Jian-Hong Pan > > > -Original Message- > > > From: linux-iio-ow...@vger.kernel.org > > > On Behalf Of Jian-Hong Pan > > > Sent: Sunday, November 18, 2018 10:12 PM > > > To: Jonathan Cameron ; Hartmut Knaack > > > ; Lars-Peter Clausen ; Peter > > > Meerwald-Stadler ; Dominique Martinet > > > > > > Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; > > > li...@endlessm.com; Jian-Hong Pan > > > Subject: [PATCH] iio: st_sensors: Fix the sleep time for sampling > > > > > > According to the description of st_sensor_settings and st_sensor_data > > > structures' comments: > > > - bootime: samples to discard when sensor passing from power-down to > > > power-up. > > > - odr: Output data rate of the sensor [Hz]. > > > > > > The sleep time should be > > > sdata->sensor_settings->bootime + 1000 / sdata->odr ms. > > > > > > Signed-off-by: Jian-Hong Pan > > > --- > > > drivers/iio/common/st_sensors/st_sensors_core.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/iio/common/st_sensors/st_sensors_core.c > > > b/drivers/iio/common/st_sensors/st_sensors_core.c > > > index 26fbd1bd9413..6b87ea657a92 100644 > > > --- a/drivers/iio/common/st_sensors/st_sensors_core.c > > > +++ b/drivers/iio/common/st_sensors/st_sensors_core.c > > > @@ -594,7 +594,7 @@ int st_sensors_read_info_raw(struct iio_dev > > > *indio_dev, > > > if (err < 0) > > > goto out; > > > > > > - msleep((sdata->sensor_settings->bootime * 1000) / > > > sdata->odr); > > > + msleep(sdata->sensor_settings->bootime + 1000 / > > > sdata->odr); > > > err = st_sensors_read_axis_data(indio_dev, ch, val); > > > if (err < 0) > > > goto out; > > > -- > > > 2.11.0 > > > >
Re: [PATCH] iio: st_sensors: Fix the sleep time for sampling
Jonathan Cameron 於 2018年11月25日 週日 下午9:23寫道： > > On Wed, 21 Nov 2018 13:13:40 +0800 > Jian-Hong Pan wrote: > > > Denis CIOCCA 於 2018年11月20日 週二 上午3:05寫道： > > > > > > Hi Jian, > > > > > > Not clear to me why should be + instead of *. > > > > > > ODR is expressed in Hz, so (1/Hz) = period in seconds (1 sample sampling > > > time) [s] > > > 1000 * (1/Hz) = period in milliseconds (1 sample sampling time) [ms] > > > n * 1000 * (1/Hz) = n times period in milliseconds (n times sample > > > sampling time) [ms] > > > > > > In your case you assume bootime is in milliseconds. > > > > Yes, I assume that according to the original comment. > > > > >Maybe we can change the comment and use 'number of samples ...'. > > > > Making the meaning more clear is better. > > > > However, does the bootime of the measurement need as the long time to > > be enabled? > > If the sampling rate is 1Hz and n is 2, then they will do msleep with > > 2000 ms for each st_sensors_read_info_raw. > > Superficially that seems correct as we need to be sure that a reading > has occurred. If you want it to be quicker than the ODR should be set > faster so that the reading shows up reasonably quickly. At 1Hz and > you want to drop 2 samples, it will indeed take 2 seconds. Now, I understand with the description. Thank you. Jian-Hong Pan > > > -Original Message- > > > From: linux-iio-ow...@vger.kernel.org > > > On Behalf Of Jian-Hong Pan > > > Sent: Sunday, November 18, 2018 10:12 PM > > > To: Jonathan Cameron ; Hartmut Knaack > > > ; Lars-Peter Clausen ; Peter > > > Meerwald-Stadler ; Dominique Martinet > > > > > > Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; > > > li...@endlessm.com; Jian-Hong Pan > > > Subject: [PATCH] iio: st_sensors: Fix the sleep time for sampling > > > > > > According to the description of st_sensor_settings and st_sensor_data > > > structures' comments: > > > - bootime: samples to discard when sensor passing from power-down to > > > power-up. > > > - odr: Output data rate of the sensor [Hz]. > > > > > > The sleep time should be > > > sdata->sensor_settings->bootime + 1000 / sdata->odr ms. > > > > > > Signed-off-by: Jian-Hong Pan > > > --- > > > drivers/iio/common/st_sensors/st_sensors_core.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/iio/common/st_sensors/st_sensors_core.c > > > b/drivers/iio/common/st_sensors/st_sensors_core.c > > > index 26fbd1bd9413..6b87ea657a92 100644 > > > --- a/drivers/iio/common/st_sensors/st_sensors_core.c > > > +++ b/drivers/iio/common/st_sensors/st_sensors_core.c > > > @@ -594,7 +594,7 @@ int st_sensors_read_info_raw(struct iio_dev > > > *indio_dev, > > > if (err < 0) > > > goto out; > > > > > > - msleep((sdata->sensor_settings->bootime * 1000) / > > > sdata->odr); > > > + msleep(sdata->sensor_settings->bootime + 1000 / > > > sdata->odr); > > > err = st_sensors_read_axis_data(indio_dev, ch, val); > > > if (err < 0) > > > goto out; > > > -- > > > 2.11.0 > > > >
Re: [PATCH 1/2] gpio: mt7621: report failure of devm_kasprintf()
Nicholas Mc Guire 於 2018年11月21日 週三 上午10:13寫道：
>
> kasprintf() may return NULL on failure of internal allocation thus the
> assigned label is not safe if not explicitly checked. On error
> mediatek_gpio_bank_probe() returns negative values so -ENOMEM in the
> (unlikely) failure case should be fine here.
>
> Signed-off-by: Nicholas Mc Guire
Acked-by: Sean Wang
> Fixes: 4ba9c3afda41 ("gpio: mt7621: Add a driver for MT7621")
> ---
>
> V2: The dev_err() for the unlikely case of the devm_kasprintf()
> failing was removed on request from Bartosz Golaszewski
>
>
> Problem located with experimental coccinelle script
>
> Patch was compile tested with: omega2p_defconfig, SOC_MT7621=y,
> GPIOLIB=y, GPIO_MT7621=y
>
> Patch is against 4.20-rc3 (localversion-next is next-20181121)
>
> drivers/gpio/gpio-mt7621.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpio/gpio-mt7621.c b/drivers/gpio/gpio-mt7621.c
> index d72af6f..1ec95bc 100644
> --- a/drivers/gpio/gpio-mt7621.c
> +++ b/drivers/gpio/gpio-mt7621.c
> @@ -244,6 +244,8 @@ mediatek_gpio_bank_probe(struct device *dev,
> rg->chip.of_xlate = mediatek_gpio_xlate;
> rg->chip.label = devm_kasprintf(dev, GFP_KERNEL, "%s-bank%d",
> dev_name(dev), bank);
> + if (!rg->chip.label)
> + return -ENOMEM;
>
> ret = devm_gpiochip_add_data(dev, >chip, mtk);
> if (ret < 0) {
> --
> 2.1.4
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH 1/2] gpio: mt7621: report failure of devm_kasprintf()
Nicholas Mc Guire 於 2018年11月21日 週三 上午10:13寫道：
>
> kasprintf() may return NULL on failure of internal allocation thus the
> assigned label is not safe if not explicitly checked. On error
> mediatek_gpio_bank_probe() returns negative values so -ENOMEM in the
> (unlikely) failure case should be fine here.
>
> Signed-off-by: Nicholas Mc Guire
Acked-by: Sean Wang
> Fixes: 4ba9c3afda41 ("gpio: mt7621: Add a driver for MT7621")
> ---
>
> V2: The dev_err() for the unlikely case of the devm_kasprintf()
> failing was removed on request from Bartosz Golaszewski
>
>
> Problem located with experimental coccinelle script
>
> Patch was compile tested with: omega2p_defconfig, SOC_MT7621=y,
> GPIOLIB=y, GPIO_MT7621=y
>
> Patch is against 4.20-rc3 (localversion-next is next-20181121)
>
> drivers/gpio/gpio-mt7621.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpio/gpio-mt7621.c b/drivers/gpio/gpio-mt7621.c
> index d72af6f..1ec95bc 100644
> --- a/drivers/gpio/gpio-mt7621.c
> +++ b/drivers/gpio/gpio-mt7621.c
> @@ -244,6 +244,8 @@ mediatek_gpio_bank_probe(struct device *dev,
> rg->chip.of_xlate = mediatek_gpio_xlate;
> rg->chip.label = devm_kasprintf(dev, GFP_KERNEL, "%s-bank%d",
> dev_name(dev), bank);
> + if (!rg->chip.label)
> + return -ENOMEM;
>
> ret = devm_gpiochip_add_data(dev, >chip, mtk);
> if (ret < 0) {
> --
> 2.1.4
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH] x86/resctrl: Fix rdt_last_cmd_printf() usage and typos within
On Mon, 26 Nov 2018, Reinette Chatre wrote: > Use rdt_last_cmd_puts() instead of rdt_last_cmd_printf() when printing a > simple string. While doing so fix two typos that were recently > introduced into two of these simple strings. You're explaing what the patch is doing, but not why printf() is wrong. Thanks, tglx
Re: [PATCH] x86/resctrl: Fix rdt_last_cmd_printf() usage and typos within
On Mon, 26 Nov 2018, Reinette Chatre wrote: > Use rdt_last_cmd_puts() instead of rdt_last_cmd_printf() when printing a > simple string. While doing so fix two typos that were recently > introduced into two of these simple strings. You're explaing what the patch is doing, but not why printf() is wrong. Thanks, tglx
Re: [patch 20/24] x86/speculation: Split out TIF update
On Tue, 27 Nov 2018, Jiri Kosina wrote:
> On Mon, 26 Nov 2018, Thomas Gleixner wrote:
>
> How about the minimalistic aproach below? (only compile tested so far,
> applies on top of your latest WIP.x86/pti branch). The downside of course
> is wasting another TIF bit.
We need to waste another TIF bit in any case.
>*
>* This can only happen for SECCOMP mitigation. For PRCTL it's
>* always the current task.
> + *
> + * If we are updating non-current task, set a flag for it to always
> + * perform the MSR sync on a first context switch, to make sure
> + * the TIF_SPEC_IB above is not out of sync with the MSR value during
> + * task's runtime.
>*/
> if (tsk == current && update)
> speculation_ctrl_update_current();
> + else
> + set_tsk_thread_flag(tsk, TIF_SPEC_UPDATE);
> +
> }
>
> static int ssb_prctl_set(struct task_struct *task, unsigned long ctrl)
> diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> index 3f5e351bdd37..78208234e63e 100644
> --- a/arch/x86/kernel/process.c
> +++ b/arch/x86/kernel/process.c
> @@ -449,8 +449,20 @@ static __always_inline void
> __speculation_ctrl_update(unsigned long tifp,
>* otherwise avoid the MSR write.
>*/
> if (IS_ENABLED(CONFIG_SMP) &&
> - static_branch_unlikely(_to_cond_stibp))
> + static_branch_unlikely(_to_cond_stibp)) {
> updmsr |= !!(tif_diff & _TIF_SPEC_IB);
> + /*
> + * We need to update the MSR if remote task did set
> + * TIF_SPEC_UPDATE on us, and therefore MSR value and
> + * the TIF_SPEC_IB values might be out of sync.
> + *
> + * This can only happen if seccomp task has updated
> + * one of its remote threads.
> + */
> + if (IS_ENABLED(CONFIG_SECCOMP) && !updmsr &&
> + (tifn & TIF_SPEC_UPDATE))
> + updmsr = true;
> + }
>
> if (updmsr)
> spec_ctrl_update_msr(tifn);
> @@ -496,6 +508,8 @@ void __switch_to_xtra(struct task_struct *prev_p, struct
> task_struct *next_p)
> set_cpuid_faulting(!!(tifn & _TIF_NOCPUID));
>
> __speculation_ctrl_update(tifp, tifn);
> + if (IS_ENABLED(CONFIG_SECCOMP))
> + clear_tsk_thread_flag(next_p, TIF_SPEC_UPDATE);
That's racy and does not prevent the situation because the TIF flags are
updated befor the UPDATE bit is set. So __speculation_ctrl_update() might
see the new bits, but not TIF_SPEC_UPDATE. You really need shadow storage
to avoid that.
Thanks,
tglx
[PATCH v2] panic: Add options to print system info when panic happens
Kernel panic issues are always painful to debug, partially
because it's not easy to get enough information of the
context when panic happens.
And we have ramoops and kdump for that, while this commit
tries to provide a easier way to show the system info by adding
a cmdline parameter, referring some idea from sysrq handler.
Signed-off-by: Feng Tang
Cc: Thomas Gleixner
Cc: John Stultz
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Steven Rostedt
---
Changelog:
v2:
- change text "dump/DUMP" to "print/PRINT" which
is more accurate, suggested by Andrew Morton
- add code to print ftrace buffer
Documentation/admin-guide/kernel-parameters.txt | 8 +++
kernel/panic.c | 28 +
2 files changed, 36 insertions(+)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 19f4423..80c819a 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3081,6 +3081,14 @@
timeout < 0: reboot immediately
Format:
+ panic_print=Bitmask for printing system info when panic happens.
+ User can chose combination of the following bits:
+ bit 0: print all tasks info
+ bit 1: print system memory info
+ bit 2: print timer info
+ bit 3: print locks info if CONFIG_LOCKDEP is on
+ bit 4: print ftrace buffer
+
panic_on_warn panic() instead of WARN(). Useful to cause kdump
on a WARN().
diff --git a/kernel/panic.c b/kernel/panic.c
index f6d549a..fb6ccd1 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -45,6 +45,13 @@ int panic_on_warn __read_mostly;
int panic_timeout = CONFIG_PANIC_TIMEOUT;
EXPORT_SYMBOL_GPL(panic_timeout);
+#define PANIC_PRINT_TASK_INFO 0x0001
+#define PANIC_PRINT_MEM_INFO 0x0002
+#define PANIC_PRINT_TIMER_INFO 0x0004
+#define PANIC_PRINT_LOCK_INFO 0x0008
+#define PANIC_PRINT_FTRACE_INFO0x0010
+static unsigned long panic_print;
+
ATOMIC_NOTIFIER_HEAD(panic_notifier_list);
EXPORT_SYMBOL(panic_notifier_list);
@@ -124,6 +131,24 @@ void nmi_panic(struct pt_regs *regs, const char *msg)
}
EXPORT_SYMBOL(nmi_panic);
+static void panic_print_sys_info(void)
+{
+ if (panic_print & PANIC_PRINT_TASK_INFO)
+ show_state();
+
+ if (panic_print & PANIC_PRINT_MEM_INFO)
+ show_mem(0, NULL);
+
+ if (panic_print & PANIC_PRINT_TIMER_INFO)
+ sysrq_timer_list_show();
+
+ if (panic_print & PANIC_PRINT_LOCK_INFO)
+ debug_show_all_locks();
+
+ if (panic_print & PANIC_PRINT_FTRACE_INFO)
+ ftrace_dump(DUMP_ALL);
+}
+
/**
* panic - halt the system
* @fmt: The text string to print
@@ -250,6 +275,8 @@ void panic(const char *fmt, ...)
debug_locks_off();
console_flush_on_panic();
+ panic_print_sys_info();
+
if (!panic_blink)
panic_blink = no_blink;
@@ -654,6 +681,7 @@ void refcount_error_report(struct pt_regs *regs, const char
*err)
#endif
core_param(panic, panic_timeout, int, 0644);
+core_param(panic_print, panic_print, ulong, 0644);
core_param(pause_on_oops, pause_on_oops, int, 0644);
core_param(panic_on_warn, panic_on_warn, int, 0644);
core_param(crash_kexec_post_notifiers, crash_kexec_post_notifiers, bool, 0644);
--
2.7.4
[PATCH] cgroup: remove unused member "cgrp_ancestor_id_storage" in struct cgroup_root
"cgrp_ancestor_id_storage" is not used, so let's clean it up.
Signed-off-by: Peng Wang
---
include/linux/cgroup-defs.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/include/linux/cgroup-defs.h b/include/linux/cgroup-defs.h
index 5e1694fe035b..639a96576ef3 100644
--- a/include/linux/cgroup-defs.h
+++ b/include/linux/cgroup-defs.h
@@ -467,9 +467,6 @@ struct cgroup_root {
/* The root cgroup. Root is destroyed on its release. */
struct cgroup cgrp;
- /* for cgrp->ancestor_ids[0] */
- int cgrp_ancestor_id_storage;
-
/* Number of cgroups in the hierarchy, used only for /proc/cgroups */
atomic_t nr_cgrps;
--
2.19.1
Re: [patch 20/24] x86/speculation: Split out TIF update
On Tue, 27 Nov 2018, Jiri Kosina wrote:
> On Mon, 26 Nov 2018, Thomas Gleixner wrote:
>
> How about the minimalistic aproach below? (only compile tested so far,
> applies on top of your latest WIP.x86/pti branch). The downside of course
> is wasting another TIF bit.
We need to waste another TIF bit in any case.
>*
>* This can only happen for SECCOMP mitigation. For PRCTL it's
>* always the current task.
> + *
> + * If we are updating non-current task, set a flag for it to always
> + * perform the MSR sync on a first context switch, to make sure
> + * the TIF_SPEC_IB above is not out of sync with the MSR value during
> + * task's runtime.
>*/
> if (tsk == current && update)
> speculation_ctrl_update_current();
> + else
> + set_tsk_thread_flag(tsk, TIF_SPEC_UPDATE);
> +
> }
>
> static int ssb_prctl_set(struct task_struct *task, unsigned long ctrl)
> diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> index 3f5e351bdd37..78208234e63e 100644
> --- a/arch/x86/kernel/process.c
> +++ b/arch/x86/kernel/process.c
> @@ -449,8 +449,20 @@ static __always_inline void
> __speculation_ctrl_update(unsigned long tifp,
>* otherwise avoid the MSR write.
>*/
> if (IS_ENABLED(CONFIG_SMP) &&
> - static_branch_unlikely(_to_cond_stibp))
> + static_branch_unlikely(_to_cond_stibp)) {
> updmsr |= !!(tif_diff & _TIF_SPEC_IB);
> + /*
> + * We need to update the MSR if remote task did set
> + * TIF_SPEC_UPDATE on us, and therefore MSR value and
> + * the TIF_SPEC_IB values might be out of sync.
> + *
> + * This can only happen if seccomp task has updated
> + * one of its remote threads.
> + */
> + if (IS_ENABLED(CONFIG_SECCOMP) && !updmsr &&
> + (tifn & TIF_SPEC_UPDATE))
> + updmsr = true;
> + }
>
> if (updmsr)
> spec_ctrl_update_msr(tifn);
> @@ -496,6 +508,8 @@ void __switch_to_xtra(struct task_struct *prev_p, struct
> task_struct *next_p)
> set_cpuid_faulting(!!(tifn & _TIF_NOCPUID));
>
> __speculation_ctrl_update(tifp, tifn);
> + if (IS_ENABLED(CONFIG_SECCOMP))
> + clear_tsk_thread_flag(next_p, TIF_SPEC_UPDATE);
That's racy and does not prevent the situation because the TIF flags are
updated befor the UPDATE bit is set. So __speculation_ctrl_update() might
see the new bits, but not TIF_SPEC_UPDATE. You really need shadow storage
to avoid that.
Thanks,
tglx
[PATCH v2] panic: Add options to print system info when panic happens
Kernel panic issues are always painful to debug, partially
because it's not easy to get enough information of the
context when panic happens.
And we have ramoops and kdump for that, while this commit
tries to provide a easier way to show the system info by adding
a cmdline parameter, referring some idea from sysrq handler.
Signed-off-by: Feng Tang
Cc: Thomas Gleixner
Cc: John Stultz
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Steven Rostedt
---
Changelog:
v2:
- change text "dump/DUMP" to "print/PRINT" which
is more accurate, suggested by Andrew Morton
- add code to print ftrace buffer
Documentation/admin-guide/kernel-parameters.txt | 8 +++
kernel/panic.c | 28 +
2 files changed, 36 insertions(+)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 19f4423..80c819a 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3081,6 +3081,14 @@
timeout < 0: reboot immediately
Format:
+ panic_print=Bitmask for printing system info when panic happens.
+ User can chose combination of the following bits:
+ bit 0: print all tasks info
+ bit 1: print system memory info
+ bit 2: print timer info
+ bit 3: print locks info if CONFIG_LOCKDEP is on
+ bit 4: print ftrace buffer
+
panic_on_warn panic() instead of WARN(). Useful to cause kdump
on a WARN().
diff --git a/kernel/panic.c b/kernel/panic.c
index f6d549a..fb6ccd1 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -45,6 +45,13 @@ int panic_on_warn __read_mostly;
int panic_timeout = CONFIG_PANIC_TIMEOUT;
EXPORT_SYMBOL_GPL(panic_timeout);
+#define PANIC_PRINT_TASK_INFO 0x0001
+#define PANIC_PRINT_MEM_INFO 0x0002
+#define PANIC_PRINT_TIMER_INFO 0x0004
+#define PANIC_PRINT_LOCK_INFO 0x0008
+#define PANIC_PRINT_FTRACE_INFO0x0010
+static unsigned long panic_print;
+
ATOMIC_NOTIFIER_HEAD(panic_notifier_list);
EXPORT_SYMBOL(panic_notifier_list);
@@ -124,6 +131,24 @@ void nmi_panic(struct pt_regs *regs, const char *msg)
}
EXPORT_SYMBOL(nmi_panic);
+static void panic_print_sys_info(void)
+{
+ if (panic_print & PANIC_PRINT_TASK_INFO)
+ show_state();
+
+ if (panic_print & PANIC_PRINT_MEM_INFO)
+ show_mem(0, NULL);
+
+ if (panic_print & PANIC_PRINT_TIMER_INFO)
+ sysrq_timer_list_show();
+
+ if (panic_print & PANIC_PRINT_LOCK_INFO)
+ debug_show_all_locks();
+
+ if (panic_print & PANIC_PRINT_FTRACE_INFO)
+ ftrace_dump(DUMP_ALL);
+}
+
/**
* panic - halt the system
* @fmt: The text string to print
@@ -250,6 +275,8 @@ void panic(const char *fmt, ...)
debug_locks_off();
console_flush_on_panic();
+ panic_print_sys_info();
+
if (!panic_blink)
panic_blink = no_blink;
@@ -654,6 +681,7 @@ void refcount_error_report(struct pt_regs *regs, const char
*err)
#endif
core_param(panic, panic_timeout, int, 0644);
+core_param(panic_print, panic_print, ulong, 0644);
core_param(pause_on_oops, pause_on_oops, int, 0644);
core_param(panic_on_warn, panic_on_warn, int, 0644);
core_param(crash_kexec_post_notifiers, crash_kexec_post_notifiers, bool, 0644);
--
2.7.4
[PATCH] cgroup: remove unused member "cgrp_ancestor_id_storage" in struct cgroup_root
"cgrp_ancestor_id_storage" is not used, so let's clean it up.
Signed-off-by: Peng Wang
---
include/linux/cgroup-defs.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/include/linux/cgroup-defs.h b/include/linux/cgroup-defs.h
index 5e1694fe035b..639a96576ef3 100644
--- a/include/linux/cgroup-defs.h
+++ b/include/linux/cgroup-defs.h
@@ -467,9 +467,6 @@ struct cgroup_root {
/* The root cgroup. Root is destroyed on its release. */
struct cgroup cgrp;
- /* for cgrp->ancestor_ids[0] */
- int cgrp_ancestor_id_storage;
-
/* Number of cgroups in the hierarchy, used only for /proc/cgroups */
atomic_t nr_cgrps;
--
2.19.1
Re: possible deadlock in ovl_write_iter
syzbot has found a reproducer for the following crash on:
HEAD commit:6f8b52ba442c Merge tag 'hwmon-for-v4.20-rc5' of git://git...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=120f390540
kernel config: https://syzkaller.appspot.com/x/.config?x=c94f9f0c0363db4b
dashboard link: https://syzkaller.appspot.com/bug?extid=695726bc473f9c36a4b6
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10cad22540
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1381309340
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+695726bc473f9c36a...@syzkaller.appspotmail.com
overlayfs: filesystem on './file0' not supported as upperdir
==
WARNING: possible circular locking dependency detected
4.20.0-rc4+ #351 Not tainted
--
syz-executor338/5996 is trying to acquire lock:
b59bb66d (_i_mutex_key[depth]){+.+.}, at: inode_lock
include/linux/fs.h:757 [inline]
b59bb66d (_i_mutex_key[depth]){+.+.}, at:
ovl_write_iter+0x151/0xd10 fs/overlayfs/file.c:231
but task is already holding lock:
e0274330 (>mutex/1){+.+.}, at: pipe_lock_nested fs/pipe.c:62
[inline]
e0274330 (>mutex/1){+.+.}, at: pipe_lock+0x6e/0x80
fs/pipe.c:70
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (>mutex/1){+.+.}:
__mutex_lock_common kernel/locking/mutex.c:925 [inline]
__mutex_lock+0x166/0x16f0 kernel/locking/mutex.c:1072
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1087
pipe_lock_nested fs/pipe.c:62 [inline]
pipe_lock+0x6e/0x80 fs/pipe.c:70
iter_file_splice_write+0x27d/0x1050 fs/splice.c:700
do_splice_from fs/splice.c:851 [inline]
do_splice+0x64a/0x1430 fs/splice.c:1147
__do_sys_splice fs/splice.c:1414 [inline]
__se_sys_splice fs/splice.c:1394 [inline]
__x64_sys_splice+0x2c1/0x330 fs/splice.c:1394
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
-> #1 (sb_writers#3){.+.+}:
percpu_down_read_preempt_disable include/linux/percpu-rwsem.h:36
[inline]
percpu_down_read include/linux/percpu-rwsem.h:59 [inline]
__sb_start_write+0x214/0x370 fs/super.c:1387
sb_start_write include/linux/fs.h:1597 [inline]
mnt_want_write+0x3f/0xc0 fs/namespace.c:360
ovl_want_write+0x76/0xa0 fs/overlayfs/util.c:24
ovl_setattr+0x10b/0xaf0 fs/overlayfs/inode.c:30
notify_change+0xbde/0x1110 fs/attr.c:334
do_truncate+0x1bd/0x2d0 fs/open.c:63
handle_truncate fs/namei.c:3008 [inline]
do_last fs/namei.c:3424 [inline]
path_openat+0x375f/0x5150 fs/namei.c:3534
do_filp_open+0x255/0x380 fs/namei.c:3564
do_sys_open+0x568/0x700 fs/open.c:1063
__do_sys_openat fs/open.c:1090 [inline]
__se_sys_openat fs/open.c:1084 [inline]
__x64_sys_openat+0x9d/0x100 fs/open.c:1084
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
-> #0 (_i_mutex_key[depth]){+.+.}:
lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844
down_write+0x8a/0x130 kernel/locking/rwsem.c:70
inode_lock include/linux/fs.h:757 [inline]
ovl_write_iter+0x151/0xd10 fs/overlayfs/file.c:231
call_write_iter include/linux/fs.h:1857 [inline]
new_sync_write fs/read_write.c:474 [inline]
__vfs_write+0x6b8/0x9f0 fs/read_write.c:487
__kernel_write+0x10c/0x370 fs/read_write.c:506
write_pipe_buf+0x180/0x240 fs/splice.c:797
splice_from_pipe_feed fs/splice.c:503 [inline]
__splice_from_pipe+0x38b/0x7c0 fs/splice.c:627
splice_from_pipe+0x1ec/0x340 fs/splice.c:662
default_file_splice_write+0x3c/0x90 fs/splice.c:809
do_splice_from fs/splice.c:851 [inline]
do_splice+0x64a/0x1430 fs/splice.c:1147
__do_sys_splice fs/splice.c:1414 [inline]
__se_sys_splice fs/splice.c:1394 [inline]
__x64_sys_splice+0x2c1/0x330 fs/splice.c:1394
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
other info that might help us debug this:
Chain exists of:
_i_mutex_key[depth] --> sb_writers#3 --> >mutex/1
Possible unsafe locking scenario:
CPU0CPU1
lock(>mutex/1);
lock(sb_writers#3);
lock(>mutex/1);
lock(_i_mutex_key[depth]);
*** DEADLOCK ***
2 locks held by syz-executor338/5996:
#0: 024e7b73 (sb_writers#8){.+.+}, at: file_start_write
include/linux/fs.h:2810 [inline]
#0: 024e7b73 (sb_writers#8){.+.+}, at: do_splice+0xd2e/0x1430
fs/splice.c:1146
#1: e0274330
Re: possible deadlock in ovl_write_iter
syzbot has found a reproducer for the following crash on:
HEAD commit:6f8b52ba442c Merge tag 'hwmon-for-v4.20-rc5' of git://git...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=120f390540
kernel config: https://syzkaller.appspot.com/x/.config?x=c94f9f0c0363db4b
dashboard link: https://syzkaller.appspot.com/bug?extid=695726bc473f9c36a4b6
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10cad22540
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1381309340
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+695726bc473f9c36a...@syzkaller.appspotmail.com
overlayfs: filesystem on './file0' not supported as upperdir
==
WARNING: possible circular locking dependency detected
4.20.0-rc4+ #351 Not tainted
--
syz-executor338/5996 is trying to acquire lock:
b59bb66d (_i_mutex_key[depth]){+.+.}, at: inode_lock
include/linux/fs.h:757 [inline]
b59bb66d (_i_mutex_key[depth]){+.+.}, at:
ovl_write_iter+0x151/0xd10 fs/overlayfs/file.c:231
but task is already holding lock:
e0274330 (>mutex/1){+.+.}, at: pipe_lock_nested fs/pipe.c:62
[inline]
e0274330 (>mutex/1){+.+.}, at: pipe_lock+0x6e/0x80
fs/pipe.c:70
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (>mutex/1){+.+.}:
__mutex_lock_common kernel/locking/mutex.c:925 [inline]
__mutex_lock+0x166/0x16f0 kernel/locking/mutex.c:1072
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1087
pipe_lock_nested fs/pipe.c:62 [inline]
pipe_lock+0x6e/0x80 fs/pipe.c:70
iter_file_splice_write+0x27d/0x1050 fs/splice.c:700
do_splice_from fs/splice.c:851 [inline]
do_splice+0x64a/0x1430 fs/splice.c:1147
__do_sys_splice fs/splice.c:1414 [inline]
__se_sys_splice fs/splice.c:1394 [inline]
__x64_sys_splice+0x2c1/0x330 fs/splice.c:1394
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
-> #1 (sb_writers#3){.+.+}:
percpu_down_read_preempt_disable include/linux/percpu-rwsem.h:36
[inline]
percpu_down_read include/linux/percpu-rwsem.h:59 [inline]
__sb_start_write+0x214/0x370 fs/super.c:1387
sb_start_write include/linux/fs.h:1597 [inline]
mnt_want_write+0x3f/0xc0 fs/namespace.c:360
ovl_want_write+0x76/0xa0 fs/overlayfs/util.c:24
ovl_setattr+0x10b/0xaf0 fs/overlayfs/inode.c:30
notify_change+0xbde/0x1110 fs/attr.c:334
do_truncate+0x1bd/0x2d0 fs/open.c:63
handle_truncate fs/namei.c:3008 [inline]
do_last fs/namei.c:3424 [inline]
path_openat+0x375f/0x5150 fs/namei.c:3534
do_filp_open+0x255/0x380 fs/namei.c:3564
do_sys_open+0x568/0x700 fs/open.c:1063
__do_sys_openat fs/open.c:1090 [inline]
__se_sys_openat fs/open.c:1084 [inline]
__x64_sys_openat+0x9d/0x100 fs/open.c:1084
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
-> #0 (_i_mutex_key[depth]){+.+.}:
lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844
down_write+0x8a/0x130 kernel/locking/rwsem.c:70
inode_lock include/linux/fs.h:757 [inline]
ovl_write_iter+0x151/0xd10 fs/overlayfs/file.c:231
call_write_iter include/linux/fs.h:1857 [inline]
new_sync_write fs/read_write.c:474 [inline]
__vfs_write+0x6b8/0x9f0 fs/read_write.c:487
__kernel_write+0x10c/0x370 fs/read_write.c:506
write_pipe_buf+0x180/0x240 fs/splice.c:797
splice_from_pipe_feed fs/splice.c:503 [inline]
__splice_from_pipe+0x38b/0x7c0 fs/splice.c:627
splice_from_pipe+0x1ec/0x340 fs/splice.c:662
default_file_splice_write+0x3c/0x90 fs/splice.c:809
do_splice_from fs/splice.c:851 [inline]
do_splice+0x64a/0x1430 fs/splice.c:1147
__do_sys_splice fs/splice.c:1414 [inline]
__se_sys_splice fs/splice.c:1394 [inline]
__x64_sys_splice+0x2c1/0x330 fs/splice.c:1394
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
other info that might help us debug this:
Chain exists of:
_i_mutex_key[depth] --> sb_writers#3 --> >mutex/1
Possible unsafe locking scenario:
CPU0CPU1
lock(>mutex/1);
lock(sb_writers#3);
lock(>mutex/1);
lock(_i_mutex_key[depth]);
*** DEADLOCK ***
2 locks held by syz-executor338/5996:
#0: 024e7b73 (sb_writers#8){.+.+}, at: file_start_write
include/linux/fs.h:2810 [inline]
#0: 024e7b73 (sb_writers#8){.+.+}, at: do_splice+0xd2e/0x1430
fs/splice.c:1146
#1: e0274330
Re: [patch 20/24] x86/speculation: Split out TIF update
On Mon, 26 Nov 2018, Thomas Gleixner wrote:
> > Looks like seccomp thread can be running on a remote CPU when its
> > TIF_SPEC_IB flag gets updated.
> >
> > I wonder if this will cause STIBP to be always off in this scenario, when
> > two tasks with SPEC_IB flags running on a remote CPU have STIBP bit always
> > *off* in SPEC MSR.
> >
> > Let's say we have tasks A and B running on a remote CPU:
> >
> > task A: SPEC_IB flag is on
> >
> > task B: SPEC_IB flag is off but is currently running on remote CPU, SPEC
> > MSR's STIBP bit is off
> >
> > Now arch_seccomp_spec_mitigation is called, setting SPEC_IB flag on task B.
> > SPEC MSR becomes out of sync with running task B's SPEC_IB flag.
> >
> >
> > Task B context switches to task A. Because both tasks have SPEC_IB flag
> > set and the flag status is unchanged, SPEC MSR's STIBP bit is not
> > updated. SPEC MSR STIBP bit remains off if tasks A and B are the only
> > tasks running on the CPU.
> >
> > There is an equivalent scenario where the SPEC MSR's STIBP bit remains on
> > even though both running task A and B's SPEC_IB flags are turned off.
> >
> > Wonder if I may be missing something so the above scenario is not of
> > concern?
>
> The above is real.
Agreed.
> The question is whether we need to worry about it.
Well, update of seccomp filters (and therefore updating of the flags)
might happen at any time, long after the seccomp process has been started,
so it might be pretty spread across cores by that time. So I think it
indeed is a real scenario, although probably even harder for explicitly
target by an attacker.
> If so, then the right thing to do is to leave thread_info.flags alone
> and flip the bits in a shadow storage, e.g. thread_info.spec_flags and
> after updating that set something like TIF_SPEC_UPDATE and evaluate that
> bit on context switch and if set update the TIF flags. Too tired to code
> that now, but it's straight forward. I'll look at it on wednesday if
> nobody beats me to it.
Hm, the we'd have to implement the same split for things like checking of
the work masks etc. (because we'd have to be checking in both places),
right? That doesn't look particularly nice.
How about the minimalistic aproach below? (only compile tested so far,
applies on top of your latest WIP.x86/pti branch). The downside of course
is wasting another TIF bit.
Thanks.
From: Jiri Kosina
Subject: [PATCH] x86/speculation: Always properly update SPEC_CTRL MSR for
remote seccomp tasks
If seccomp task is setting (*) TIF_SPEC_IB of a task running on remote CPU, the
value of TIF_SPEC_IB becomes out-of-sync with the actual MSR value on that CPU.
This becomes a problem when such task then context switches to another task
that has TIF_SPEC_IB set, as in such case the value of SPEC_CTRL MSR is not
updated and the next task starts running with stale value of SPEC_CTRL,
potentially unprotected by STIBP.
Fix that by always unconditionally updating the MSR in case that
- next task's TIF_SPEC_IB has been remotely set by its another seccomp thread,
and
- TIF_SPEC_IB value of next is equal to the one of prev, and therefore
we are guaranteed to be in a situation where MSR update would be lost
(*) symmetrical situation happens with clearing of the flag
Reported-by: Tim Chen
Signed-off-by: Jiri Kosina
---
arch/x86/include/asm/thread_info.h | 4 +++-
arch/x86/kernel/cpu/bugs.c | 8
arch/x86/kernel/process.c | 16 +++-
3 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/thread_info.h
b/arch/x86/include/asm/thread_info.h
index 6d201699c651..278f9036ca45 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -84,6 +84,7 @@ struct thread_info {
#define TIF_SYSCALL_AUDIT 7 /* syscall auditing active */
#define TIF_SECCOMP8 /* secure computing */
#define TIF_SPEC_IB9 /* Indirect branch speculation
mitigation */
+#define TIF_SPEC_UPDATE10 /* SPEC_CTRL MSR sync needed on
CTXSW */
#define TIF_USER_RETURN_NOTIFY 11 /* notify kernel of userspace return */
#define TIF_UPROBE 12 /* breakpointed or singlestepping */
#define TIF_PATCH_PENDING 13 /* pending live patching update */
@@ -112,6 +113,7 @@ struct thread_info {
#define _TIF_SYSCALL_AUDIT (1 << TIF_SYSCALL_AUDIT)
#define _TIF_SECCOMP (1 << TIF_SECCOMP)
#define _TIF_SPEC_IB (1 << TIF_SPEC_IB)
+#define _TIF_SPEC_UPDATE (1 << TIF_SPEC_UPDATE)
#define _TIF_USER_RETURN_NOTIFY(1 << TIF_USER_RETURN_NOTIFY)
#define _TIF_UPROBE(1 << TIF_UPROBE)
#define _TIF_PATCH_PENDING (1 << TIF_PATCH_PENDING)
@@ -155,7 +157,7 @@ struct thread_info {
* Avoid calls to __switch_to_xtra() on UP as STIBP is not evaluated.
*/
#ifdef CONFIG_SMP
-# define _TIF_WORK_CTXSW (_TIF_WORK_CTXSW_BASE | _TIF_SPEC_IB)
+# define _TIF_WORK_CTXSW
Re: [patch 20/24] x86/speculation: Split out TIF update
On Mon, 26 Nov 2018, Thomas Gleixner wrote:
> > Looks like seccomp thread can be running on a remote CPU when its
> > TIF_SPEC_IB flag gets updated.
> >
> > I wonder if this will cause STIBP to be always off in this scenario, when
> > two tasks with SPEC_IB flags running on a remote CPU have STIBP bit always
> > *off* in SPEC MSR.
> >
> > Let's say we have tasks A and B running on a remote CPU:
> >
> > task A: SPEC_IB flag is on
> >
> > task B: SPEC_IB flag is off but is currently running on remote CPU, SPEC
> > MSR's STIBP bit is off
> >
> > Now arch_seccomp_spec_mitigation is called, setting SPEC_IB flag on task B.
> > SPEC MSR becomes out of sync with running task B's SPEC_IB flag.
> >
> >
> > Task B context switches to task A. Because both tasks have SPEC_IB flag
> > set and the flag status is unchanged, SPEC MSR's STIBP bit is not
> > updated. SPEC MSR STIBP bit remains off if tasks A and B are the only
> > tasks running on the CPU.
> >
> > There is an equivalent scenario where the SPEC MSR's STIBP bit remains on
> > even though both running task A and B's SPEC_IB flags are turned off.
> >
> > Wonder if I may be missing something so the above scenario is not of
> > concern?
>
> The above is real.
Agreed.
> The question is whether we need to worry about it.
Well, update of seccomp filters (and therefore updating of the flags)
might happen at any time, long after the seccomp process has been started,
so it might be pretty spread across cores by that time. So I think it
indeed is a real scenario, although probably even harder for explicitly
target by an attacker.
> If so, then the right thing to do is to leave thread_info.flags alone
> and flip the bits in a shadow storage, e.g. thread_info.spec_flags and
> after updating that set something like TIF_SPEC_UPDATE and evaluate that
> bit on context switch and if set update the TIF flags. Too tired to code
> that now, but it's straight forward. I'll look at it on wednesday if
> nobody beats me to it.
Hm, the we'd have to implement the same split for things like checking of
the work masks etc. (because we'd have to be checking in both places),
right? That doesn't look particularly nice.
How about the minimalistic aproach below? (only compile tested so far,
applies on top of your latest WIP.x86/pti branch). The downside of course
is wasting another TIF bit.
Thanks.
From: Jiri Kosina
Subject: [PATCH] x86/speculation: Always properly update SPEC_CTRL MSR for
remote seccomp tasks
If seccomp task is setting (*) TIF_SPEC_IB of a task running on remote CPU, the
value of TIF_SPEC_IB becomes out-of-sync with the actual MSR value on that CPU.
This becomes a problem when such task then context switches to another task
that has TIF_SPEC_IB set, as in such case the value of SPEC_CTRL MSR is not
updated and the next task starts running with stale value of SPEC_CTRL,
potentially unprotected by STIBP.
Fix that by always unconditionally updating the MSR in case that
- next task's TIF_SPEC_IB has been remotely set by its another seccomp thread,
and
- TIF_SPEC_IB value of next is equal to the one of prev, and therefore
we are guaranteed to be in a situation where MSR update would be lost
(*) symmetrical situation happens with clearing of the flag
Reported-by: Tim Chen
Signed-off-by: Jiri Kosina
---
arch/x86/include/asm/thread_info.h | 4 +++-
arch/x86/kernel/cpu/bugs.c | 8
arch/x86/kernel/process.c | 16 +++-
3 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/thread_info.h
b/arch/x86/include/asm/thread_info.h
index 6d201699c651..278f9036ca45 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -84,6 +84,7 @@ struct thread_info {
#define TIF_SYSCALL_AUDIT 7 /* syscall auditing active */
#define TIF_SECCOMP8 /* secure computing */
#define TIF_SPEC_IB9 /* Indirect branch speculation
mitigation */
+#define TIF_SPEC_UPDATE10 /* SPEC_CTRL MSR sync needed on
CTXSW */
#define TIF_USER_RETURN_NOTIFY 11 /* notify kernel of userspace return */
#define TIF_UPROBE 12 /* breakpointed or singlestepping */
#define TIF_PATCH_PENDING 13 /* pending live patching update */
@@ -112,6 +113,7 @@ struct thread_info {
#define _TIF_SYSCALL_AUDIT (1 << TIF_SYSCALL_AUDIT)
#define _TIF_SECCOMP (1 << TIF_SECCOMP)
#define _TIF_SPEC_IB (1 << TIF_SPEC_IB)
+#define _TIF_SPEC_UPDATE (1 << TIF_SPEC_UPDATE)
#define _TIF_USER_RETURN_NOTIFY(1 << TIF_USER_RETURN_NOTIFY)
#define _TIF_UPROBE(1 << TIF_UPROBE)
#define _TIF_PATCH_PENDING (1 << TIF_PATCH_PENDING)
@@ -155,7 +157,7 @@ struct thread_info {
* Avoid calls to __switch_to_xtra() on UP as STIBP is not evaluated.
*/
#ifdef CONFIG_SMP
-# define _TIF_WORK_CTXSW (_TIF_WORK_CTXSW_BASE | _TIF_SPEC_IB)
+# define _TIF_WORK_CTXSW
Re: [PATCH v2 3/3] Bluetooth: hci_qca: Fix frame reassembly errors for wcn3990
Hi Matthias,
On 2018-11-27 05:57, Matthias Kaehlcke wrote:
On Mon, Nov 26, 2018 at 04:09:50PM -0800, Matthias Kaehlcke wrote:
On Thu, Nov 22, 2018 at 05:45:12PM +0530, Balakrishna Godavarthi
wrote:
> During initalization of wcn3990, we observed UART is reading some
> stray bytes on the Rx line. This is logging Frame reassembly errors
> on the serial console. This could be because of tristate of Tx line
> of wcn3990 during boot up.
>
> [ 176.929612] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed
(-84)
> [ 176.945734] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed
(-84)
> [ 176.953298] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed
(-84)
> [ 177.010660] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed
(-84)
> [ 177.067633] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed
(-84)
>
> Now we enable a flag during bootup to stop executing proto receive
> function and clear it back once the initialization is done.
>
> Signed-off-by: Balakrishna Godavarthi
> Tested-by: Matthias Kaehlcke
> ---
> v2:
> * Updated commit text & comments.
> v1:
> * initial patch
> ---
> drivers/bluetooth/hci_qca.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> index ed905ea1c58a..2f3d9e16ba5a 100644
> --- a/drivers/bluetooth/hci_qca.c
> +++ b/drivers/bluetooth/hci_qca.c
> @@ -56,6 +56,7 @@
>
> /* Controller states */
> #define STATE_IN_BAND_SLEEP_ENABLED 1
> +#define STATE_DISCARD_RX 2
>
> #define IBS_WAKE_RETRANS_TIMEOUT_MS 100
> #define IBS_TX_IDLE_TIMEOUT_MS2000
> @@ -511,6 +512,7 @@ static int qca_open(struct hci_uart *hu)
>} else {
>hu->init_speed = qcadev->init_speed;
>hu->oper_speed = qcadev->oper_speed;
> + set_bit(STATE_DISCARD_RX, >flags);
>ret = qca_power_setup(hu, true);
>if (ret) {
>destroy_workqueue(qca->workqueue);
> @@ -903,6 +905,13 @@ static int qca_recv(struct hci_uart *hu, const void
*data, int count)
>if (!test_bit(HCI_UART_REGISTERED, >flags))
>return -EUNATCH;
>
> + /* We discard Rx data received while device is in booting
> + * stage, This is because of BT chip Tx line is in tristate.
> + * Due to this we read some garbage data on UART Rx.
> + */
> + if (test_bit(STATE_DISCARD_RX, >flags))
> + return 0;
> +
>qca->rx_skb = h4_recv_buf(hu->hdev, qca->rx_skb, data, count,
> qca_recv_pkts, ARRAY_SIZE(qca_recv_pkts));
>if (IS_ERR(qca->rx_skb)) {
> @@ -1193,6 +1202,7 @@ static int qca_setup(struct hci_uart *hu)
>if (ret)
>return ret;
>
> + clear_bit(STATE_DISCARD_RX, >flags);
>ret = qca_read_soc_version(hdev, _ver);
>if (ret)
>return ret;
> @@ -1269,6 +1279,14 @@ static const struct qca_vreg_data qca_soc_data = {
>
> static void qca_power_shutdown(struct hci_uart *hu)
> {
> + struct qca_data *qca = hu->priv;
> +
> + /* From this point we go into power off state,
> + * disable IBS and discard all the queued data.
> + */
> + clear_bit(STATE_IN_BAND_SLEEP_ENABLED, >flags);
Is IBS actually related to the frame reassembly errors or is this
addressing a different issue? In 100 iteratios of 'hciconfig up/down'
without clearing the flag I didn't observe any frame reassembly
errors.
Looks like this addresses the "Bluetooth: Received HCI_IBS_SLEEP_IND
in rx state 0" messages that are seen when the interface is brought up
on a system with firmware binaries (with IBS support?). Please spin
this out into a separate patch.
[Bala]: "Bluetooth: Received HCI_IBS_SLEEP_IND in rx state 0 is an
different issue.
i suspect that is due to mismatch of ibs timers over flow value
between wcn3990 & HOST.
clearing ibs is required, to stop ibs state machine while we do
hci close
this is intern help in resolving the frame reassembly errors
during close (in rare case observed)
anyways will send this a separate patch.
Thanks
Matthias
--
Regards
Balakrishna.
Re: [PATCH v2 3/3] Bluetooth: hci_qca: Fix frame reassembly errors for wcn3990
Hi Matthias,
On 2018-11-27 05:57, Matthias Kaehlcke wrote:
On Mon, Nov 26, 2018 at 04:09:50PM -0800, Matthias Kaehlcke wrote:
On Thu, Nov 22, 2018 at 05:45:12PM +0530, Balakrishna Godavarthi
wrote:
> During initalization of wcn3990, we observed UART is reading some
> stray bytes on the Rx line. This is logging Frame reassembly errors
> on the serial console. This could be because of tristate of Tx line
> of wcn3990 during boot up.
>
> [ 176.929612] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed
(-84)
> [ 176.945734] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed
(-84)
> [ 176.953298] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed
(-84)
> [ 177.010660] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed
(-84)
> [ 177.067633] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed
(-84)
>
> Now we enable a flag during bootup to stop executing proto receive
> function and clear it back once the initialization is done.
>
> Signed-off-by: Balakrishna Godavarthi
> Tested-by: Matthias Kaehlcke
> ---
> v2:
> * Updated commit text & comments.
> v1:
> * initial patch
> ---
> drivers/bluetooth/hci_qca.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> index ed905ea1c58a..2f3d9e16ba5a 100644
> --- a/drivers/bluetooth/hci_qca.c
> +++ b/drivers/bluetooth/hci_qca.c
> @@ -56,6 +56,7 @@
>
> /* Controller states */
> #define STATE_IN_BAND_SLEEP_ENABLED 1
> +#define STATE_DISCARD_RX 2
>
> #define IBS_WAKE_RETRANS_TIMEOUT_MS 100
> #define IBS_TX_IDLE_TIMEOUT_MS2000
> @@ -511,6 +512,7 @@ static int qca_open(struct hci_uart *hu)
>} else {
>hu->init_speed = qcadev->init_speed;
>hu->oper_speed = qcadev->oper_speed;
> + set_bit(STATE_DISCARD_RX, >flags);
>ret = qca_power_setup(hu, true);
>if (ret) {
>destroy_workqueue(qca->workqueue);
> @@ -903,6 +905,13 @@ static int qca_recv(struct hci_uart *hu, const void
*data, int count)
>if (!test_bit(HCI_UART_REGISTERED, >flags))
>return -EUNATCH;
>
> + /* We discard Rx data received while device is in booting
> + * stage, This is because of BT chip Tx line is in tristate.
> + * Due to this we read some garbage data on UART Rx.
> + */
> + if (test_bit(STATE_DISCARD_RX, >flags))
> + return 0;
> +
>qca->rx_skb = h4_recv_buf(hu->hdev, qca->rx_skb, data, count,
> qca_recv_pkts, ARRAY_SIZE(qca_recv_pkts));
>if (IS_ERR(qca->rx_skb)) {
> @@ -1193,6 +1202,7 @@ static int qca_setup(struct hci_uart *hu)
>if (ret)
>return ret;
>
> + clear_bit(STATE_DISCARD_RX, >flags);
>ret = qca_read_soc_version(hdev, _ver);
>if (ret)
>return ret;
> @@ -1269,6 +1279,14 @@ static const struct qca_vreg_data qca_soc_data = {
>
> static void qca_power_shutdown(struct hci_uart *hu)
> {
> + struct qca_data *qca = hu->priv;
> +
> + /* From this point we go into power off state,
> + * disable IBS and discard all the queued data.
> + */
> + clear_bit(STATE_IN_BAND_SLEEP_ENABLED, >flags);
Is IBS actually related to the frame reassembly errors or is this
addressing a different issue? In 100 iteratios of 'hciconfig up/down'
without clearing the flag I didn't observe any frame reassembly
errors.
Looks like this addresses the "Bluetooth: Received HCI_IBS_SLEEP_IND
in rx state 0" messages that are seen when the interface is brought up
on a system with firmware binaries (with IBS support?). Please spin
this out into a separate patch.
[Bala]: "Bluetooth: Received HCI_IBS_SLEEP_IND in rx state 0 is an
different issue.
i suspect that is due to mismatch of ibs timers over flow value
between wcn3990 & HOST.
clearing ibs is required, to stop ibs state machine while we do
hci close
this is intern help in resolving the frame reassembly errors
during close (in rare case observed)
anyways will send this a separate patch.
Thanks
Matthias
--
Regards
Balakrishna.
Re: [PATCH 2/7] node: Add heterogenous memory performance
On Wed, Nov 14, 2018 at 2:53 PM Keith Busch wrote: > > Heterogeneous memory systems provide memory nodes with latency > and bandwidth performance attributes that are different from other > nodes. Create an interface for the kernel to register these attributes > under the node that provides the memory. If the system provides this > information, applications can query the node attributes when deciding > which node to request memory. > > When multiple memory initiators exist, accessing the same memory target > from each may not perform the same as the other. The highest performing > initiator to a given target is considered to be a local initiator for > that target. The kernel provides performance attributes only for the > local initiators. > > The memory's compute node should be symlinked in sysfs as one of the > node's initiators. > > The following example shows the new sysfs hierarchy for a node exporting > performance attributes: > > # tree /sys/devices/system/node/nodeY/initiator_access > /sys/devices/system/node/nodeY/initiator_access > |-- read_bandwidth > |-- read_latency > |-- write_bandwidth > `-- write_latency With the expectation that there will be nodes that are initiator-only, target-only, or both I think this interface should indicate that. The 1:1 "local" designation of HMAT should not be directly encoded in the interface, it's just a shortcut for finding at least one initiator in the set that can realize the advertised performance. At least if the interface can enumerate the set of initiators then it becomes clear whether sysfs can answer a performance enumeration question or if the application needs to consult an interface with specific knowledge of a given initiator-target pairing. It seems a precursor to these patches is arranges for offline node devices to be created for the ACPI proximity domains that are offline-by default for reserved memory ranges.
Re: [PATCH 2/7] node: Add heterogenous memory performance
On Wed, Nov 14, 2018 at 2:53 PM Keith Busch wrote: > > Heterogeneous memory systems provide memory nodes with latency > and bandwidth performance attributes that are different from other > nodes. Create an interface for the kernel to register these attributes > under the node that provides the memory. If the system provides this > information, applications can query the node attributes when deciding > which node to request memory. > > When multiple memory initiators exist, accessing the same memory target > from each may not perform the same as the other. The highest performing > initiator to a given target is considered to be a local initiator for > that target. The kernel provides performance attributes only for the > local initiators. > > The memory's compute node should be symlinked in sysfs as one of the > node's initiators. > > The following example shows the new sysfs hierarchy for a node exporting > performance attributes: > > # tree /sys/devices/system/node/nodeY/initiator_access > /sys/devices/system/node/nodeY/initiator_access > |-- read_bandwidth > |-- read_latency > |-- write_bandwidth > `-- write_latency With the expectation that there will be nodes that are initiator-only, target-only, or both I think this interface should indicate that. The 1:1 "local" designation of HMAT should not be directly encoded in the interface, it's just a shortcut for finding at least one initiator in the set that can realize the advertised performance. At least if the interface can enumerate the set of initiators then it becomes clear whether sysfs can answer a performance enumeration question or if the application needs to consult an interface with specific knowledge of a given initiator-target pairing. It seems a precursor to these patches is arranges for offline node devices to be created for the ACPI proximity domains that are offline-by default for reserved memory ranges.
Re: [PATCH] arm64: dts: sdm845: Add videocc node
Quoting Doug Anderson (2018-11-26 16:35:50)
> Hi,
>
> On Mon, Nov 5, 2018 at 2:35 AM Taniya Das wrote:
> >
> > This adds the video clock controller node to sdm845 based on the examples
> > in the bindings.
> >
> > Signed-off-by: Taniya Das
> > ---
> > arch/arm64/boot/dts/qcom/sdm845.dtsi | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > index b72bdb0..91a281b 100644
> > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > @@ -8,6 +8,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -1256,6 +1257,13 @@
> > #power-domain-cells = <1>;
> > };
> >
> > + videocc: clock-controller@ab0 {
> > + compatible = "qcom,sdm845-videocc";
> > + reg = <0xab0 0x1>;
> > + #clock-cells = <1>;
> > + #power-domain-cells = <1>;
>
> Any reason not to include "#reset-cells = <1>;" here? The bindings
> list it as optional but I see no reason why we should leave it off.
> The file "include/dt-bindings/clock/qcom,videocc-sdm845.h" seems to
> include some #defines for resets. Even though the driver doesn't seem
> like it supports it yet, it still should be fine to list it here.
We should update the binding to make it a required property. It doesn't
make any sense why that property would be optional given that the
hardware either has support for resets or it doesn't.
Re: [PATCH] arm64: dts: sdm845: Add videocc node
Quoting Doug Anderson (2018-11-26 16:35:50)
> Hi,
>
> On Mon, Nov 5, 2018 at 2:35 AM Taniya Das wrote:
> >
> > This adds the video clock controller node to sdm845 based on the examples
> > in the bindings.
> >
> > Signed-off-by: Taniya Das
> > ---
> > arch/arm64/boot/dts/qcom/sdm845.dtsi | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > index b72bdb0..91a281b 100644
> > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > @@ -8,6 +8,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -1256,6 +1257,13 @@
> > #power-domain-cells = <1>;
> > };
> >
> > + videocc: clock-controller@ab0 {
> > + compatible = "qcom,sdm845-videocc";
> > + reg = <0xab0 0x1>;
> > + #clock-cells = <1>;
> > + #power-domain-cells = <1>;
>
> Any reason not to include "#reset-cells = <1>;" here? The bindings
> list it as optional but I see no reason why we should leave it off.
> The file "include/dt-bindings/clock/qcom,videocc-sdm845.h" seems to
> include some #defines for resets. Even though the driver doesn't seem
> like it supports it yet, it still should be fine to list it here.
We should update the binding to make it a required property. It doesn't
make any sense why that property would be optional given that the
hardware either has support for resets or it doesn't.
[no subject]
-- Good day, I am Mrs Ulrica Mica from Hungary but based in the United Kindom, i am hospitalized in London suffering from Acute Cancer.i want to sign a Donation of $6,800,000 Usd on orphans in your area,can you handle it?, because of the confidentiality of the subject, Please contact me back directly on this my email (ulrica.mi...@aol.com), I have sent this proposal several times without receiving any response from you, Your responds on my private email address will determined how serious you are. I am making this donation because my doctor have issued to me that the rate of the cancer that i have just some days to live. There i decided to donate all that i have to the orphans. Mrs Ulrica Mica London. United Kingdom
[no subject]
-- Good day, I am Mrs Ulrica Mica from Hungary but based in the United Kindom, i am hospitalized in London suffering from Acute Cancer.i want to sign a Donation of $6,800,000 Usd on orphans in your area,can you handle it?, because of the confidentiality of the subject, Please contact me back directly on this my email (ulrica.mi...@aol.com), I have sent this proposal several times without receiving any response from you, Your responds on my private email address will determined how serious you are. I am making this donation because my doctor have issued to me that the rate of the cancer that i have just some days to live. There i decided to donate all that i have to the orphans. Mrs Ulrica Mica London. United Kingdom
[PATCH v2] clk: qcom: Move to menuconfig and reduce lines
We duplicate the 'depends on' in almost every Kconfig here, and it's getting out of hand now that we have tens of options for various SoC drivers here. Let's clean it up a little by making a menuconfig for a submenu and adding an if wrapper around the driver section. Cc: Bjorn Andersson Cc: Taniya Das Signed-off-by: Stephen Boyd --- Changes from v1: * Don't remove full depends on lines when they have something else drivers/clk/qcom/Kconfig | 43 +--- 1 file changed, 9 insertions(+), 34 deletions(-) diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig index a611531df115..cf1dec367192 100644 --- a/drivers/clk/qcom/Kconfig +++ b/drivers/clk/qcom/Kconfig @@ -9,16 +9,17 @@ config QCOM_GDSC config QCOM_RPMCC bool -config COMMON_CLK_QCOM +menuconfig COMMON_CLK_QCOM tristate "Support for Qualcomm's clock controllers" depends on OF depends on ARCH_QCOM || COMPILE_TEST select REGMAP_MMIO select RESET_CONTROLLER +if COMMON_CLK_QCOM + config QCOM_A53PLL tristate "MSM8916 A53 PLL" - depends on COMMON_CLK_QCOM default ARCH_QCOM help Support for the A53 PLL on MSM8916 devices. It provides @@ -28,7 +29,6 @@ config QCOM_A53PLL config QCOM_CLK_APCS_MSM8916 tristate "MSM8916 APCS Clock Controller" - depends on COMMON_CLK_QCOM depends on QCOM_APCS_IPC || COMPILE_TEST default ARCH_QCOM help @@ -39,7 +39,7 @@ config QCOM_CLK_APCS_MSM8916 config QCOM_CLK_RPM tristate "RPM based Clock Controller" - depends on COMMON_CLK_QCOM && MFD_QCOM_RPM + depends on MFD_QCOM_RPM select QCOM_RPMCC help The RPM (Resource Power Manager) is a dedicated hardware engine for @@ -52,7 +52,7 @@ config QCOM_CLK_RPM config QCOM_CLK_SMD_RPM tristate "RPM over SMD based Clock Controller" - depends on COMMON_CLK_QCOM && QCOM_SMD_RPM + depends on QCOM_SMD_RPM select QCOM_RPMCC help The RPM (Resource Power Manager) is a dedicated hardware engine for @@ -65,7 +65,7 @@ config QCOM_CLK_SMD_RPM config QCOM_CLK_RPMH tristate "RPMh Clock Driver" - depends on COMMON_CLK_QCOM && QCOM_RPMH + depends on QCOM_RPMH help RPMh manages shared resources on some Qualcomm Technologies, Inc. SoCs. It accepts requests from other hardware subsystems via RSC. @@ -75,7 +75,6 @@ config QCOM_CLK_RPMH config APQ_GCC_8084 tristate "APQ8084 Global Clock Controller" select QCOM_GDSC - depends on COMMON_CLK_QCOM help Support for the global clock controller on apq8084 devices. Say Y if you want to use peripheral devices such as UART, SPI, @@ -85,7 +84,6 @@ config APQ_MMCC_8084 tristate "APQ8084 Multimedia Clock Controller" select APQ_GCC_8084 select QCOM_GDSC - depends on COMMON_CLK_QCOM help Support for the multimedia clock controller on apq8084 devices. Say Y if you want to support multimedia devices such as display, @@ -93,7 +91,6 @@ config APQ_MMCC_8084 config IPQ_GCC_4019 tristate "IPQ4019 Global Clock Controller" - depends on COMMON_CLK_QCOM help Support for the global clock controller on ipq4019 devices. Say Y if you want to use peripheral devices such as UART, SPI, @@ -101,7 +98,6 @@ config IPQ_GCC_4019 config IPQ_GCC_806X tristate "IPQ806x Global Clock Controller" - depends on COMMON_CLK_QCOM help Support for the global clock controller on ipq806x devices. Say Y if you want to use peripheral devices such as UART, SPI, @@ -110,7 +106,6 @@ config IPQ_GCC_806X config IPQ_LCC_806X tristate "IPQ806x LPASS Clock Controller" select IPQ_GCC_806X - depends on COMMON_CLK_QCOM help Support for the LPASS clock controller on ipq806x devices. Say Y if you want to use audio devices such as i2s, pcm, @@ -118,7 +113,6 @@ config IPQ_LCC_806X config IPQ_GCC_8074 tristate "IPQ8074 Global Clock Controller" - depends on COMMON_CLK_QCOM help Support for global clock controller on ipq8074 devices. Say Y if you want to use peripheral devices such as UART, SPI, @@ -127,7 +121,6 @@ config IPQ_GCC_8074 config MSM_GCC_8660 tristate "MSM8660 Global Clock Controller" - depends on COMMON_CLK_QCOM help Support for the global clock controller on msm8660 devices. Say Y if you want to use peripheral devices such as UART, SPI, @@ -136,7 +129,6 @@ config MSM_GCC_8660 config MSM_GCC_8916 tristate "MSM8916 Global Clock Controller" select QCOM_GDSC - depends on COMMON_CLK_QCOM help Support for the global clock controller on msm8916 devices. Say Y if you want to use devices such as UART, SPI i2c, USB, @@
[PATCH v2] clk: qcom: Move to menuconfig and reduce lines
We duplicate the 'depends on' in almost every Kconfig here, and it's getting out of hand now that we have tens of options for various SoC drivers here. Let's clean it up a little by making a menuconfig for a submenu and adding an if wrapper around the driver section. Cc: Bjorn Andersson Cc: Taniya Das Signed-off-by: Stephen Boyd --- Changes from v1: * Don't remove full depends on lines when they have something else drivers/clk/qcom/Kconfig | 43 +--- 1 file changed, 9 insertions(+), 34 deletions(-) diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig index a611531df115..cf1dec367192 100644 --- a/drivers/clk/qcom/Kconfig +++ b/drivers/clk/qcom/Kconfig @@ -9,16 +9,17 @@ config QCOM_GDSC config QCOM_RPMCC bool -config COMMON_CLK_QCOM +menuconfig COMMON_CLK_QCOM tristate "Support for Qualcomm's clock controllers" depends on OF depends on ARCH_QCOM || COMPILE_TEST select REGMAP_MMIO select RESET_CONTROLLER +if COMMON_CLK_QCOM + config QCOM_A53PLL tristate "MSM8916 A53 PLL" - depends on COMMON_CLK_QCOM default ARCH_QCOM help Support for the A53 PLL on MSM8916 devices. It provides @@ -28,7 +29,6 @@ config QCOM_A53PLL config QCOM_CLK_APCS_MSM8916 tristate "MSM8916 APCS Clock Controller" - depends on COMMON_CLK_QCOM depends on QCOM_APCS_IPC || COMPILE_TEST default ARCH_QCOM help @@ -39,7 +39,7 @@ config QCOM_CLK_APCS_MSM8916 config QCOM_CLK_RPM tristate "RPM based Clock Controller" - depends on COMMON_CLK_QCOM && MFD_QCOM_RPM + depends on MFD_QCOM_RPM select QCOM_RPMCC help The RPM (Resource Power Manager) is a dedicated hardware engine for @@ -52,7 +52,7 @@ config QCOM_CLK_RPM config QCOM_CLK_SMD_RPM tristate "RPM over SMD based Clock Controller" - depends on COMMON_CLK_QCOM && QCOM_SMD_RPM + depends on QCOM_SMD_RPM select QCOM_RPMCC help The RPM (Resource Power Manager) is a dedicated hardware engine for @@ -65,7 +65,7 @@ config QCOM_CLK_SMD_RPM config QCOM_CLK_RPMH tristate "RPMh Clock Driver" - depends on COMMON_CLK_QCOM && QCOM_RPMH + depends on QCOM_RPMH help RPMh manages shared resources on some Qualcomm Technologies, Inc. SoCs. It accepts requests from other hardware subsystems via RSC. @@ -75,7 +75,6 @@ config QCOM_CLK_RPMH config APQ_GCC_8084 tristate "APQ8084 Global Clock Controller" select QCOM_GDSC - depends on COMMON_CLK_QCOM help Support for the global clock controller on apq8084 devices. Say Y if you want to use peripheral devices such as UART, SPI, @@ -85,7 +84,6 @@ config APQ_MMCC_8084 tristate "APQ8084 Multimedia Clock Controller" select APQ_GCC_8084 select QCOM_GDSC - depends on COMMON_CLK_QCOM help Support for the multimedia clock controller on apq8084 devices. Say Y if you want to support multimedia devices such as display, @@ -93,7 +91,6 @@ config APQ_MMCC_8084 config IPQ_GCC_4019 tristate "IPQ4019 Global Clock Controller" - depends on COMMON_CLK_QCOM help Support for the global clock controller on ipq4019 devices. Say Y if you want to use peripheral devices such as UART, SPI, @@ -101,7 +98,6 @@ config IPQ_GCC_4019 config IPQ_GCC_806X tristate "IPQ806x Global Clock Controller" - depends on COMMON_CLK_QCOM help Support for the global clock controller on ipq806x devices. Say Y if you want to use peripheral devices such as UART, SPI, @@ -110,7 +106,6 @@ config IPQ_GCC_806X config IPQ_LCC_806X tristate "IPQ806x LPASS Clock Controller" select IPQ_GCC_806X - depends on COMMON_CLK_QCOM help Support for the LPASS clock controller on ipq806x devices. Say Y if you want to use audio devices such as i2s, pcm, @@ -118,7 +113,6 @@ config IPQ_LCC_806X config IPQ_GCC_8074 tristate "IPQ8074 Global Clock Controller" - depends on COMMON_CLK_QCOM help Support for global clock controller on ipq8074 devices. Say Y if you want to use peripheral devices such as UART, SPI, @@ -127,7 +121,6 @@ config IPQ_GCC_8074 config MSM_GCC_8660 tristate "MSM8660 Global Clock Controller" - depends on COMMON_CLK_QCOM help Support for the global clock controller on msm8660 devices. Say Y if you want to use peripheral devices such as UART, SPI, @@ -136,7 +129,6 @@ config MSM_GCC_8660 config MSM_GCC_8916 tristate "MSM8916 Global Clock Controller" select QCOM_GDSC - depends on COMMON_CLK_QCOM help Support for the global clock controller on msm8916 devices. Say Y if you want to use devices such as UART, SPI i2c, USB, @@
Re: [PATCH v2 2/3] Bluetooth: hci_qca: Deassert RTS while baudrate change command
Hi Matthias,
On 2018-11-27 01:12, Matthias Kaehlcke wrote:
On Thu, Nov 22, 2018 at 05:45:11PM +0530, Balakrishna Godavarthi wrote:
This patch will help to stop frame reassembly errors while changing
the baudrate. This is because host send a change baudrate request
command to the chip with 115200 bps, Whereas chip will change their
UART clocks to the enable for new baudrate and sends the response
for the change request command with newer baudrate, On host side
we are still operating in 115200 bps which results of reading garbage
data. Here we are pulling RTS line, so that chip we will wait to send
data
to host until host change its baudrate.
Thanks for updating the commit message and provide more details!
Signed-off-by: Balakrishna Godavarthi
Tested-by: Matthias Kaehlcke
---
v2:
* updated commit text and comments.
v1:
* initial patch
---
drivers/bluetooth/hci_qca.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index f5dd323c1967..ed905ea1c58a 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -963,7 +963,6 @@ static int qca_set_baudrate(struct hci_dev *hdev,
uint8_t baudrate)
struct hci_uart *hu = hci_get_drvdata(hdev);
struct qca_data *qca = hu->priv;
struct sk_buff *skb;
- struct qca_serdev *qcadev;
u8 cmd[] = { 0x01, 0x48, 0xFC, 0x01, 0x00 };
if (baudrate > QCA_BAUDRATE_320)
@@ -977,13 +976,6 @@ static int qca_set_baudrate(struct hci_dev *hdev,
uint8_t baudrate)
return -ENOMEM;
}
- /* Disabling hardware flow control is mandatory while
-* sending change baudrate request to wcn3990 SoC.
-*/
- qcadev = serdev_device_get_drvdata(hu->serdev);
- if (qcadev->btsoc_type == QCA_WCN3990)
- hci_uart_set_flow_control(hu, true);
-
/* Assign commands to change baudrate and packet type. */
skb_put_data(skb, cmd, sizeof(cmd));
hci_skb_pkt_type(skb) = HCI_COMMAND_PKT;
@@ -999,9 +991,6 @@ static int qca_set_baudrate(struct hci_dev *hdev,
uint8_t baudrate)
schedule_timeout(msecs_to_jiffies(BAUDRATE_SETTLE_TIMEOUT_MS));
set_current_state(TASK_RUNNING);
- if (qcadev->btsoc_type == QCA_WCN3990)
- hci_uart_set_flow_control(hu, false);
-
return 0;
}
@@ -1086,6 +1075,7 @@ static int qca_check_speeds(struct hci_uart *hu)
static int qca_set_speed(struct hci_uart *hu, enum qca_speed_type
speed_type)
{
unsigned int speed, qca_baudrate;
+ struct qca_serdev *qcadev;
int ret;
if (speed_type == QCA_INIT_SPEED) {
@@ -1097,6 +1087,14 @@ static int qca_set_speed(struct hci_uart *hu,
enum qca_speed_type speed_type)
if (!speed)
return 0;
+ /* Deassert RTS while changing the baudrate of chip and host.
+* This will stop chip to transmit it response with an newer
+* baudrate until we change the baudarte.
nit: baudrate
re-nit (to consider if you respin anyway): 'This prevents the chip
from transmitting its response with the new baudrate while the host
port is still operating at the old speed'?
(I'm not a native English speaker, probably there is still room for
improvement ;-)
[Bala]: will update.
Reviewed-by: Matthias Kaehlcke
--
Regards
Balakrishna.
Re: [PATCH v2 2/3] Bluetooth: hci_qca: Deassert RTS while baudrate change command
Hi Matthias,
On 2018-11-27 01:12, Matthias Kaehlcke wrote:
On Thu, Nov 22, 2018 at 05:45:11PM +0530, Balakrishna Godavarthi wrote:
This patch will help to stop frame reassembly errors while changing
the baudrate. This is because host send a change baudrate request
command to the chip with 115200 bps, Whereas chip will change their
UART clocks to the enable for new baudrate and sends the response
for the change request command with newer baudrate, On host side
we are still operating in 115200 bps which results of reading garbage
data. Here we are pulling RTS line, so that chip we will wait to send
data
to host until host change its baudrate.
Thanks for updating the commit message and provide more details!
Signed-off-by: Balakrishna Godavarthi
Tested-by: Matthias Kaehlcke
---
v2:
* updated commit text and comments.
v1:
* initial patch
---
drivers/bluetooth/hci_qca.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index f5dd323c1967..ed905ea1c58a 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -963,7 +963,6 @@ static int qca_set_baudrate(struct hci_dev *hdev,
uint8_t baudrate)
struct hci_uart *hu = hci_get_drvdata(hdev);
struct qca_data *qca = hu->priv;
struct sk_buff *skb;
- struct qca_serdev *qcadev;
u8 cmd[] = { 0x01, 0x48, 0xFC, 0x01, 0x00 };
if (baudrate > QCA_BAUDRATE_320)
@@ -977,13 +976,6 @@ static int qca_set_baudrate(struct hci_dev *hdev,
uint8_t baudrate)
return -ENOMEM;
}
- /* Disabling hardware flow control is mandatory while
-* sending change baudrate request to wcn3990 SoC.
-*/
- qcadev = serdev_device_get_drvdata(hu->serdev);
- if (qcadev->btsoc_type == QCA_WCN3990)
- hci_uart_set_flow_control(hu, true);
-
/* Assign commands to change baudrate and packet type. */
skb_put_data(skb, cmd, sizeof(cmd));
hci_skb_pkt_type(skb) = HCI_COMMAND_PKT;
@@ -999,9 +991,6 @@ static int qca_set_baudrate(struct hci_dev *hdev,
uint8_t baudrate)
schedule_timeout(msecs_to_jiffies(BAUDRATE_SETTLE_TIMEOUT_MS));
set_current_state(TASK_RUNNING);
- if (qcadev->btsoc_type == QCA_WCN3990)
- hci_uart_set_flow_control(hu, false);
-
return 0;
}
@@ -1086,6 +1075,7 @@ static int qca_check_speeds(struct hci_uart *hu)
static int qca_set_speed(struct hci_uart *hu, enum qca_speed_type
speed_type)
{
unsigned int speed, qca_baudrate;
+ struct qca_serdev *qcadev;
int ret;
if (speed_type == QCA_INIT_SPEED) {
@@ -1097,6 +1087,14 @@ static int qca_set_speed(struct hci_uart *hu,
enum qca_speed_type speed_type)
if (!speed)
return 0;
+ /* Deassert RTS while changing the baudrate of chip and host.
+* This will stop chip to transmit it response with an newer
+* baudrate until we change the baudarte.
nit: baudrate
re-nit (to consider if you respin anyway): 'This prevents the chip
from transmitting its response with the new baudrate while the host
port is still operating at the old speed'?
(I'm not a native English speaker, probably there is still room for
improvement ;-)
[Bala]: will update.
Reviewed-by: Matthias Kaehlcke
--
Regards
Balakrishna.
Re: [PATCH] ptrace: take into account saved_sigmask in PTRACE_{GET,SET}SIGMASK
On Thu, Nov 22, 2018 at 12:47:52PM +0100, Oleg Nesterov wrote:
> On 11/19, Andrei Vagin wrote:
> >
> > case PTRACE_SETSIGMASK: {
> > sigset_t new_set;
> > @@ -962,6 +971,8 @@ int ptrace_request(struct task_struct *child, long
> > request,
> > child->blocked = new_set;
> > spin_unlock_irq(>sighand->siglock);
> >
> > + clear_tsk_restore_sigmask(child);
> > +
>
> I am not sure I understand this change...
>
> I forgot everything I knew about criu, but iiuc PTRACE_SETSIGMASK is used
> at "restore" time, doesn't this mean that TIF_RESTORE_SIGMASK/restore_sigmask
> can not be set?
PTRACE_SETSIGMASK isn't used on restore. On restore, criu generates
sigframe and calls sigreturn to restore registers, fpu state, sigmask
and resume a process. When the kernel constructs a signal frame, it
calls sigmask_to_save() to get a process signal mask. With this patch,
PTRACE_GETSIGMASK returns the same signal mask what is returned by
sigmask_to_save().
In CRIU, we don't need to set TIF_RESTORE_SIGMASK, because all processes
are dumped when they are in user-space.
>
> IOW, could you please explain how PTRACE_SETSIGMASK should be used, and why
> it doesn't do something like
>
CRIU uses PTRACE_SETSIGMASK when it injects a parasite code into a
target process. In this case, we have to be sure that when the process
is resumed by PTRACE_CONT, it will not start handling signals and
executing signal handlers.
> if (test_tsk_restore_sigmask(child))
> child->saved_sigmask = new_set;
> else
> child->blocked = new_set;
>
> which looks symmetrical to PTRACE_GETSIGMASK?
If we set child->saved_sigmask, the child can start handling signals
which are not set in child->blocked.
>
> Oleg.
>
Re: [PATCH] ptrace: take into account saved_sigmask in PTRACE_{GET,SET}SIGMASK
On Thu, Nov 22, 2018 at 12:47:52PM +0100, Oleg Nesterov wrote:
> On 11/19, Andrei Vagin wrote:
> >
> > case PTRACE_SETSIGMASK: {
> > sigset_t new_set;
> > @@ -962,6 +971,8 @@ int ptrace_request(struct task_struct *child, long
> > request,
> > child->blocked = new_set;
> > spin_unlock_irq(>sighand->siglock);
> >
> > + clear_tsk_restore_sigmask(child);
> > +
>
> I am not sure I understand this change...
>
> I forgot everything I knew about criu, but iiuc PTRACE_SETSIGMASK is used
> at "restore" time, doesn't this mean that TIF_RESTORE_SIGMASK/restore_sigmask
> can not be set?
PTRACE_SETSIGMASK isn't used on restore. On restore, criu generates
sigframe and calls sigreturn to restore registers, fpu state, sigmask
and resume a process. When the kernel constructs a signal frame, it
calls sigmask_to_save() to get a process signal mask. With this patch,
PTRACE_GETSIGMASK returns the same signal mask what is returned by
sigmask_to_save().
In CRIU, we don't need to set TIF_RESTORE_SIGMASK, because all processes
are dumped when they are in user-space.
>
> IOW, could you please explain how PTRACE_SETSIGMASK should be used, and why
> it doesn't do something like
>
CRIU uses PTRACE_SETSIGMASK when it injects a parasite code into a
target process. In this case, we have to be sure that when the process
is resumed by PTRACE_CONT, it will not start handling signals and
executing signal handlers.
> if (test_tsk_restore_sigmask(child))
> child->saved_sigmask = new_set;
> else
> child->blocked = new_set;
>
> which looks symmetrical to PTRACE_GETSIGMASK?
If we set child->saved_sigmask, the child can start handling signals
which are not set in child->blocked.
>
> Oleg.
>
RE: [PATCH] ARM64: dts: imx: add i.MX8QXP thermal support
Forgot to mentioned: This patch is based on "[V4,3/5] arm64: dts: imx: add
imx8qxp support", https://patchwork.kernel.org/patch/10677311/
Best Regards!
Anson Huang
> -Original Message-
> From: Anson Huang
> Sent: 2018年11月27日 14:19
> To: robh...@kernel.org; mark.rutl...@arm.com; Aisheng DONG
> ; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org; shawn...@kernel.org
> Cc: dl-linux-imx
> Subject: [PATCH] ARM64: dts: imx: add i.MX8QXP thermal support
>
> Add i.MX8QXP CPU thermal zone support.
>
> Signed-off-by: Anson Huang
> ---
> arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 27
> +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> index da99b6f..9155d45 100644
> --- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> @@ -9,6 +9,7 @@
> #include #include
> #include
> +#include
>
> #include "imx8-ca35.dtsi"
>
> @@ -85,6 +86,32 @@
> };
> };
>
> + tsens: thermal-sensor {
> + compatible = "nxp,imx8qxp-sc-thermal";
> + tsens-num = <1>;
> + #thermal-sensor-cells = <1>;
> + };
> +
> + thermal_zones: thermal-zones {
> + cpu-thermal0 {
> + polling-delay-passive = <250>;
> + polling-delay = <2000>;
> + thermal-sensors = < 355>;
> + trips {
> + cpu_alert0: trip0 {
> + temperature = <107000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> + cpu_crit0: trip1 {
> + temperature = <127000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> + };
> + };
> +
> adma_subsys: bus@5900 {
> compatible = "simple-bus";
> #address-cells = <1>;
> --
> 2.7.4
RE: [PATCH] ARM64: dts: imx: add i.MX8QXP thermal support
Forgot to mentioned: This patch is based on "[V4,3/5] arm64: dts: imx: add
imx8qxp support", https://patchwork.kernel.org/patch/10677311/
Best Regards!
Anson Huang
> -Original Message-
> From: Anson Huang
> Sent: 2018年11月27日 14:19
> To: robh...@kernel.org; mark.rutl...@arm.com; Aisheng DONG
> ; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org; shawn...@kernel.org
> Cc: dl-linux-imx
> Subject: [PATCH] ARM64: dts: imx: add i.MX8QXP thermal support
>
> Add i.MX8QXP CPU thermal zone support.
>
> Signed-off-by: Anson Huang
> ---
> arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 27
> +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> index da99b6f..9155d45 100644
> --- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> @@ -9,6 +9,7 @@
> #include #include
> #include
> +#include
>
> #include "imx8-ca35.dtsi"
>
> @@ -85,6 +86,32 @@
> };
> };
>
> + tsens: thermal-sensor {
> + compatible = "nxp,imx8qxp-sc-thermal";
> + tsens-num = <1>;
> + #thermal-sensor-cells = <1>;
> + };
> +
> + thermal_zones: thermal-zones {
> + cpu-thermal0 {
> + polling-delay-passive = <250>;
> + polling-delay = <2000>;
> + thermal-sensors = < 355>;
> + trips {
> + cpu_alert0: trip0 {
> + temperature = <107000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> + cpu_crit0: trip1 {
> + temperature = <127000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> + };
> + };
> +
> adma_subsys: bus@5900 {
> compatible = "simple-bus";
> #address-cells = <1>;
> --
> 2.7.4
Re: [PATCH 3/4] Drivers: hv: vmbus: Add hooks for per-CPU IRQ
On Mon, Nov 26, 2018 at 08:56:50PM +, Michael Kelley wrote: > From: Greg KH Monday, November 26, 2018 11:57 AM > > > > > You created "null" hooks that do nothing, for no one in this patch > > > > series, why? > > > > > > > > > > hv_enable_vmbus_irq() and hv_disable_vmbus_irq() have non-null > > > implementations in the ARM64 code in patch 2 of this series. The > > > implementations are in the new file arch/arm64/hyperv/mshyperv.c. > > > Or am I misunderstanding your point? > > > > So you use a hook in an earlier patch and then add it in a later one? > > > > Shouldn't you do it the other way around? As it is, the earlier patch > > should not work properly, right? > > The earlier patch implements the hook on the ARM64 side but it is > unused -- it's not called. The later patch then calls it. Wouldn't the > other way around be backwards? Ah, it wasn't obvious that the previous patch added it at all, why not just make that addition part of this patch? > The general approach is for patches 1 and 2 of the series to provide > all the new code under arch/arm64 to enable Hyper-V. But the code > won't get called (or even built) with just these two patches because > CONFIG_HYPERV can't be selected. Patch 3 is separate because it > applies to architecture independent code and arch/x86 code -- I thought > there might be value in keeping the ARM64 and x86 patches distinct. > Patch 4 applies to architecture independent code, and enables the > ARM64 code in patches 1 and 2 to be compiled and run when > CONFIG_HYPERV is selected. > > If combining some of the patches in the series is a better approach, I'm > good with that. Ok, that makes more sense, if it is easier to get the ARM people to review this, that's fine. Doesn't seem like anyone did that yet :( sorry for the noise, greg k-h
Re: [PATCH 3/4] Drivers: hv: vmbus: Add hooks for per-CPU IRQ
On Mon, Nov 26, 2018 at 08:56:50PM +, Michael Kelley wrote: > From: Greg KH Monday, November 26, 2018 11:57 AM > > > > > You created "null" hooks that do nothing, for no one in this patch > > > > series, why? > > > > > > > > > > hv_enable_vmbus_irq() and hv_disable_vmbus_irq() have non-null > > > implementations in the ARM64 code in patch 2 of this series. The > > > implementations are in the new file arch/arm64/hyperv/mshyperv.c. > > > Or am I misunderstanding your point? > > > > So you use a hook in an earlier patch and then add it in a later one? > > > > Shouldn't you do it the other way around? As it is, the earlier patch > > should not work properly, right? > > The earlier patch implements the hook on the ARM64 side but it is > unused -- it's not called. The later patch then calls it. Wouldn't the > other way around be backwards? Ah, it wasn't obvious that the previous patch added it at all, why not just make that addition part of this patch? > The general approach is for patches 1 and 2 of the series to provide > all the new code under arch/arm64 to enable Hyper-V. But the code > won't get called (or even built) with just these two patches because > CONFIG_HYPERV can't be selected. Patch 3 is separate because it > applies to architecture independent code and arch/x86 code -- I thought > there might be value in keeping the ARM64 and x86 patches distinct. > Patch 4 applies to architecture independent code, and enables the > ARM64 code in patches 1 and 2 to be compiled and run when > CONFIG_HYPERV is selected. > > If combining some of the patches in the series is a better approach, I'm > good with that. Ok, that makes more sense, if it is easier to get the ARM people to review this, that's fine. Doesn't seem like anyone did that yet :( sorry for the noise, greg k-h
[PATCH] ARM64: dts: imx: add i.MX8QXP thermal support
Add i.MX8QXP CPU thermal zone support.
Signed-off-by: Anson Huang
---
arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index da99b6f..9155d45 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include "imx8-ca35.dtsi"
@@ -85,6 +86,32 @@
};
};
+ tsens: thermal-sensor {
+ compatible = "nxp,imx8qxp-sc-thermal";
+ tsens-num = <1>;
+ #thermal-sensor-cells = <1>;
+ };
+
+ thermal_zones: thermal-zones {
+ cpu-thermal0 {
+ polling-delay-passive = <250>;
+ polling-delay = <2000>;
+ thermal-sensors = < 355>;
+ trips {
+ cpu_alert0: trip0 {
+ temperature = <107000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+ cpu_crit0: trip1 {
+ temperature = <127000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ };
+ };
+
adma_subsys: bus@5900 {
compatible = "simple-bus";
#address-cells = <1>;
--
2.7.4
[PATCH] ARM64: dts: imx: add i.MX8QXP thermal support
Add i.MX8QXP CPU thermal zone support.
Signed-off-by: Anson Huang
---
arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index da99b6f..9155d45 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include "imx8-ca35.dtsi"
@@ -85,6 +86,32 @@
};
};
+ tsens: thermal-sensor {
+ compatible = "nxp,imx8qxp-sc-thermal";
+ tsens-num = <1>;
+ #thermal-sensor-cells = <1>;
+ };
+
+ thermal_zones: thermal-zones {
+ cpu-thermal0 {
+ polling-delay-passive = <250>;
+ polling-delay = <2000>;
+ thermal-sensors = < 355>;
+ trips {
+ cpu_alert0: trip0 {
+ temperature = <107000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+ cpu_crit0: trip1 {
+ temperature = <127000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ };
+ };
+
adma_subsys: bus@5900 {
compatible = "simple-bus";
#address-cells = <1>;
--
2.7.4
[PATCH] defconfig: arm64: add i.MX system controller thermal support
This patch enables CONFIG_IMX_SC_THERMAL by default. Signed-off-by: Anson Huang --- This patch is based on https://patchwork.kernel.org/patch/10677315/ arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index d3aa3f7..6d224f7 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -376,6 +376,7 @@ CONFIG_SENSORS_RASPBERRYPI_HWMON=m CONFIG_THERMAL_GOV_POWER_ALLOCATOR=y CONFIG_CPU_THERMAL=y CONFIG_THERMAL_EMULATION=y +CONFIG_IMX_SC_THERMAL=y CONFIG_ROCKCHIP_THERMAL=m CONFIG_RCAR_GEN3_THERMAL=y CONFIG_ARMADA_THERMAL=y -- 2.7.4
[PATCH] defconfig: arm64: add i.MX system controller thermal support
This patch enables CONFIG_IMX_SC_THERMAL by default. Signed-off-by: Anson Huang --- This patch is based on https://patchwork.kernel.org/patch/10677315/ arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index d3aa3f7..6d224f7 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -376,6 +376,7 @@ CONFIG_SENSORS_RASPBERRYPI_HWMON=m CONFIG_THERMAL_GOV_POWER_ALLOCATOR=y CONFIG_CPU_THERMAL=y CONFIG_THERMAL_EMULATION=y +CONFIG_IMX_SC_THERMAL=y CONFIG_ROCKCHIP_THERMAL=m CONFIG_RCAR_GEN3_THERMAL=y CONFIG_ARMADA_THERMAL=y -- 2.7.4
Re: KASAN: use-after-free Read in kvm_write_guest_offset_cached
On Tue, 27 Nov 2018 at 12:51, syzbot wrote: > > Hello, Is there beauty C codes? Regards, Wanpeng Li > > syzbot found the following crash on: > > HEAD commit:442b8cea2477 Add linux-next specific files for 20181109 > git tree: linux-next > console output: https://syzkaller.appspot.com/x/log.txt?x=174d326d40 > kernel config: https://syzkaller.appspot.com/x/.config?x=2f72bdb11df9fbe8 > dashboard link: https://syzkaller.appspot.com/bug?extid=ff40b9bc4835ea83211c > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14f5df7b40 > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+ff40b9bc4835ea832...@syzkaller.appspotmail.com > > == > BUG: KASAN: use-after-free in mark_page_dirty_in_slot > arch/x86/kvm/../../../virt/kvm/kvm_main.c:2056 [inline] > BUG: KASAN: use-after-free in kvm_write_guest_offset_cached+0x693/0x6b0 > arch/x86/kvm/../../../virt/kvm/kvm_main.c:1988 > Read of size 8 at addr 8801b9363778 by task syz-executor1/30438 > > CPU: 1 PID: 30438 Comm: syz-executor1 Not tainted 4.20.0-rc1-next-20181109+ > #110 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:77 [inline] > dump_stack+0x244/0x39d lib/dump_stack.c:113 > print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256 > kasan_report_error mm/kasan/report.c:354 [inline] > kasan_report.cold.8+0x242/0x309 mm/kasan/report.c:412 > __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433 > mark_page_dirty_in_slot arch/x86/kvm/../../../virt/kvm/kvm_main.c:2056 > [inline] > kvm_write_guest_offset_cached+0x693/0x6b0 > arch/x86/kvm/../../../virt/kvm/kvm_main.c:1988 > kvm_steal_time_set_preempted arch/x86/kvm/x86.c:3241 [inline] > kvm_arch_vcpu_put+0x365/0x420 arch/x86/kvm/x86.c:3268 > kvm_sched_out+0x91/0xb0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3993 > __fire_sched_out_preempt_notifiers kernel/sched/core.c:2503 [inline] > fire_sched_out_preempt_notifiers kernel/sched/core.c:2511 [inline] > prepare_task_switch kernel/sched/core.c:2617 [inline] > context_switch kernel/sched/core.c:2796 [inline] > __schedule+0x11ca/0x21d0 kernel/sched/core.c:3472 > preempt_schedule_irq+0xb9/0x140 kernel/sched/core.c:3699 > retint_kernel+0x1b/0x2d > RIP: 0010:search_memslots include/linux/kvm_host.h:955 [inline] > RIP: 0010:__gfn_to_memslot include/linux/kvm_host.h:976 [inline] > RIP: 0010:__kvm_gfn_to_hva_cache_init+0x2ed/0xd10 > arch/x86/kvm/../../../virt/kvm/kvm_main.c:1935 > Code: 3c 02 00 0f 85 0d 0a 00 00 4d 03 6c 24 08 48 89 df 4c 89 ee e8 04 16 > 78 00 4c 39 eb 0f 82 6e 01 00 00 45 31 ed e8 43 15 78 00 <44> 89 fe 44 89 > ef e8 c8 15 78 00 45 39 fd 0f 8d cf 00 00 00 e8 2a > RSP: 0018:8801cbfee970 EFLAGS: 0293 ORIG_RAX: ff13 > RAX: 8801b9a4c280 RBX: RCX: 8107942f > RDX: RSI: 8107936d RDI: 0006 > RBP: 8801cbfeeb60 R08: 8801b9a4c280 R09: ed00342bb209 > R10: ed00342bb209 R11: 8801a15d904b R12: 0017 > R13: 0017 R14: 0016 R15: 0017 > kvm_gfn_to_hva_cache_init+0x15a/0x340 > arch/x86/kvm/../../../virt/kvm/kvm_main.c:1963 > kvm_set_msr_common+0x1a0c/0x2670 arch/x86/kvm/x86.c:2549 > vmx_set_msr+0x759/0x1f90 arch/x86/kvm/vmx.c:4360 > kvm_set_msr+0x18a/0x370 arch/x86/kvm/x86.c:1324 > do_set_msr+0x10d/0x1a0 arch/x86/kvm/x86.c:1353 > __msr_io arch/x86/kvm/x86.c:2905 [inline] > msr_io+0x222/0x380 arch/x86/kvm/x86.c:2941 > kvm_arch_vcpu_ioctl+0x961/0x3b00 arch/x86/kvm/x86.c:3956 > kvm_vcpu_ioctl+0x278/0x1150 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2748 > vfs_ioctl fs/ioctl.c:46 [inline] > file_ioctl fs/ioctl.c:509 [inline] > do_vfs_ioctl+0x1de/0x1790 fs/ioctl.c:696 > ksys_ioctl+0xa9/0xd0 fs/ioctl.c:713 > __do_sys_ioctl fs/ioctl.c:720 [inline] > __se_sys_ioctl fs/ioctl.c:718 [inline] > __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718 > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > RIP: 0033:0x457569 > Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff > ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 > RSP: 002b:7fc292e62c78 EFLAGS: 0246 ORIG_RAX: 0010 > RAX: ffda RBX: 0003 RCX: 00457569 > RDX: 2280 RSI: 4008ae89 RDI: 0005 > RBP: 0072c040 R08: R09: > R10: R11: 0246 R12: 7fc292e636d4 > R13: 004bff9d R14: 004d0970 R15: > > Allocated by task 30427: > save_stack+0x43/0xd0 mm/kasan/kasan.c:448 > set_track mm/kasan/kasan.c:460
Re: KASAN: use-after-free Read in kvm_write_guest_offset_cached
On Tue, 27 Nov 2018 at 12:51, syzbot wrote: > > Hello, Is there beauty C codes? Regards, Wanpeng Li > > syzbot found the following crash on: > > HEAD commit:442b8cea2477 Add linux-next specific files for 20181109 > git tree: linux-next > console output: https://syzkaller.appspot.com/x/log.txt?x=174d326d40 > kernel config: https://syzkaller.appspot.com/x/.config?x=2f72bdb11df9fbe8 > dashboard link: https://syzkaller.appspot.com/bug?extid=ff40b9bc4835ea83211c > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14f5df7b40 > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+ff40b9bc4835ea832...@syzkaller.appspotmail.com > > == > BUG: KASAN: use-after-free in mark_page_dirty_in_slot > arch/x86/kvm/../../../virt/kvm/kvm_main.c:2056 [inline] > BUG: KASAN: use-after-free in kvm_write_guest_offset_cached+0x693/0x6b0 > arch/x86/kvm/../../../virt/kvm/kvm_main.c:1988 > Read of size 8 at addr 8801b9363778 by task syz-executor1/30438 > > CPU: 1 PID: 30438 Comm: syz-executor1 Not tainted 4.20.0-rc1-next-20181109+ > #110 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:77 [inline] > dump_stack+0x244/0x39d lib/dump_stack.c:113 > print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256 > kasan_report_error mm/kasan/report.c:354 [inline] > kasan_report.cold.8+0x242/0x309 mm/kasan/report.c:412 > __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433 > mark_page_dirty_in_slot arch/x86/kvm/../../../virt/kvm/kvm_main.c:2056 > [inline] > kvm_write_guest_offset_cached+0x693/0x6b0 > arch/x86/kvm/../../../virt/kvm/kvm_main.c:1988 > kvm_steal_time_set_preempted arch/x86/kvm/x86.c:3241 [inline] > kvm_arch_vcpu_put+0x365/0x420 arch/x86/kvm/x86.c:3268 > kvm_sched_out+0x91/0xb0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3993 > __fire_sched_out_preempt_notifiers kernel/sched/core.c:2503 [inline] > fire_sched_out_preempt_notifiers kernel/sched/core.c:2511 [inline] > prepare_task_switch kernel/sched/core.c:2617 [inline] > context_switch kernel/sched/core.c:2796 [inline] > __schedule+0x11ca/0x21d0 kernel/sched/core.c:3472 > preempt_schedule_irq+0xb9/0x140 kernel/sched/core.c:3699 > retint_kernel+0x1b/0x2d > RIP: 0010:search_memslots include/linux/kvm_host.h:955 [inline] > RIP: 0010:__gfn_to_memslot include/linux/kvm_host.h:976 [inline] > RIP: 0010:__kvm_gfn_to_hva_cache_init+0x2ed/0xd10 > arch/x86/kvm/../../../virt/kvm/kvm_main.c:1935 > Code: 3c 02 00 0f 85 0d 0a 00 00 4d 03 6c 24 08 48 89 df 4c 89 ee e8 04 16 > 78 00 4c 39 eb 0f 82 6e 01 00 00 45 31 ed e8 43 15 78 00 <44> 89 fe 44 89 > ef e8 c8 15 78 00 45 39 fd 0f 8d cf 00 00 00 e8 2a > RSP: 0018:8801cbfee970 EFLAGS: 0293 ORIG_RAX: ff13 > RAX: 8801b9a4c280 RBX: RCX: 8107942f > RDX: RSI: 8107936d RDI: 0006 > RBP: 8801cbfeeb60 R08: 8801b9a4c280 R09: ed00342bb209 > R10: ed00342bb209 R11: 8801a15d904b R12: 0017 > R13: 0017 R14: 0016 R15: 0017 > kvm_gfn_to_hva_cache_init+0x15a/0x340 > arch/x86/kvm/../../../virt/kvm/kvm_main.c:1963 > kvm_set_msr_common+0x1a0c/0x2670 arch/x86/kvm/x86.c:2549 > vmx_set_msr+0x759/0x1f90 arch/x86/kvm/vmx.c:4360 > kvm_set_msr+0x18a/0x370 arch/x86/kvm/x86.c:1324 > do_set_msr+0x10d/0x1a0 arch/x86/kvm/x86.c:1353 > __msr_io arch/x86/kvm/x86.c:2905 [inline] > msr_io+0x222/0x380 arch/x86/kvm/x86.c:2941 > kvm_arch_vcpu_ioctl+0x961/0x3b00 arch/x86/kvm/x86.c:3956 > kvm_vcpu_ioctl+0x278/0x1150 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2748 > vfs_ioctl fs/ioctl.c:46 [inline] > file_ioctl fs/ioctl.c:509 [inline] > do_vfs_ioctl+0x1de/0x1790 fs/ioctl.c:696 > ksys_ioctl+0xa9/0xd0 fs/ioctl.c:713 > __do_sys_ioctl fs/ioctl.c:720 [inline] > __se_sys_ioctl fs/ioctl.c:718 [inline] > __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718 > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > RIP: 0033:0x457569 > Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff > ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 > RSP: 002b:7fc292e62c78 EFLAGS: 0246 ORIG_RAX: 0010 > RAX: ffda RBX: 0003 RCX: 00457569 > RDX: 2280 RSI: 4008ae89 RDI: 0005 > RBP: 0072c040 R08: R09: > R10: R11: 0246 R12: 7fc292e636d4 > R13: 004bff9d R14: 004d0970 R15: > > Allocated by task 30427: > save_stack+0x43/0xd0 mm/kasan/kasan.c:448 > set_track mm/kasan/kasan.c:460
Re: [PATCH] watchdog: core: suppress "watchdog did not stop" message
On 11/26/18, 5:31 PM, "Jerry Hoemann" wrote: > Tao, > > If you're on a system running systemd, the default behavior is to > enable the watchdog during shutdown. This guards against shutdown hanging. > So this message will be routinely printed out during orderly shutdown. Thank you Jerry for the comments. I actually use a separate daemon process to kick the watchdog on my BMC system. The daemon monitors temperature sensors and other system states and kicks watchdog periodically: if the daemon gets stuck or exits, then the machine needs to reboot even if kernel/systemd is fine. Perhaps I need to look for a better/official way to manage the watchdog device.. BTW, I will be travelling abroad in the new few days and may not be able to reply emails timely. Thank you again for jumping in. Best regards, Tao Ren
Re: [PATCH] watchdog: core: suppress "watchdog did not stop" message
On 11/26/18, 5:31 PM, "Jerry Hoemann" wrote: > Tao, > > If you're on a system running systemd, the default behavior is to > enable the watchdog during shutdown. This guards against shutdown hanging. > So this message will be routinely printed out during orderly shutdown. Thank you Jerry for the comments. I actually use a separate daemon process to kick the watchdog on my BMC system. The daemon monitors temperature sensors and other system states and kicks watchdog periodically: if the daemon gets stuck or exits, then the machine needs to reboot even if kernel/systemd is fine. Perhaps I need to look for a better/official way to manage the watchdog device.. BTW, I will be travelling abroad in the new few days and may not be able to reply emails timely. Thank you again for jumping in. Best regards, Tao Ren
Re: [PATCH v2 11/11] soc: mediatek: Add MT8183 scpsys support
On Tue, Nov 27, 2018 at 11:43 AM Weiyi Lu wrote:
>
> Add scpsys driver for MT8183
>
> Signed-off-by: Weiyi Lu
> ---
> drivers/soc/mediatek/mtk-scpsys.c | 227 +-
> 1 file changed, 226 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/mediatek/mtk-scpsys.c
> b/drivers/soc/mediatek/mtk-scpsys.c
> index 80be2e05e4e0..aac76c45a681 100644
> --- a/drivers/soc/mediatek/mtk-scpsys.c
> +++ b/drivers/soc/mediatek/mtk-scpsys.c
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
>
> #define MTK_POLL_DELAY_US 10
> #define MTK_POLL_TIMEOUT(jiffies_to_usecs(HZ))
> @@ -397,7 +398,6 @@ static int scpsys_power_on(struct generic_pm_domain
> *genpd)
> if (ret < 0)
> goto err_pwr_ack;
>
> -
Oh, this belongs in patch [04/11].
> val &= ~PWR_CLK_DIS_BIT;
> writel(val, ctl_addr);
>
> @@ -1179,6 +1179,217 @@ static const struct scp_subdomain
> scp_subdomain_mt8173[] = {
> {MT8173_POWER_DOMAIN_MFG_2D, MT8173_POWER_DOMAIN_MFG},
> };
>
> +/*
> + * MT8183 power domain support
> + */
> +
> +static const struct scp_domain_data scp_domain_data_mt8183[] = {
> + [MT8183_POWER_DOMAIN_AUDIO] = {
> + .name = "audio",
> + .sta_mask = PWR_STATUS_AUDIO,
> + .ctl_offs = 0x0314,
> + .sram_pdn_bits = GENMASK(11, 8),
> + .sram_pdn_ack_bits = GENMASK(15, 12),
> + .basic_clk_name = {"audio", "audio1", "audio2"},
> + },
> + [MT8183_POWER_DOMAIN_CONN] = {
> + .name = "conn",
> + .sta_mask = PWR_STATUS_CONN,
> + .ctl_offs = 0x032c,
> + .sram_pdn_bits = 0,
> + .sram_pdn_ack_bits = 0,
> + .bp_table = {
> + BUS_PROT(IFR_TYPE, 0x2a0, 0x2a4, 0, 0x228,
> + BIT(13) | BIT(14), BIT(13) | BIT(14)),
> + },
> + },
> + [MT8183_POWER_DOMAIN_MFG_ASYNC] = {
> + .name = "mfg_async",
> + .sta_mask = PWR_STATUS_MFG_ASYNC,
> + .ctl_offs = 0x0334,
> + .sram_pdn_bits = 0,
> + .sram_pdn_ack_bits = 0,
> + .basic_clk_name = {"mfg"},
> + },
> + [MT8183_POWER_DOMAIN_MFG] = {
> + .name = "mfg",
> + .sta_mask = PWR_STATUS_MFG,
> + .ctl_offs = 0x0338,
> + .sram_pdn_bits = GENMASK(8, 8),
> + .sram_pdn_ack_bits = GENMASK(12, 12),
> + },
> + [MT8183_POWER_DOMAIN_MFG_CORE0] = {
> + .name = "mfg_core0",
> + .sta_mask = BIT(7),
> + .ctl_offs = 0x034c,
> + .sram_pdn_bits = GENMASK(8, 8),
> + .sram_pdn_ack_bits = GENMASK(12, 12),
> + },
> + [MT8183_POWER_DOMAIN_MFG_CORE1] = {
> + .name = "mfg_core1",
> + .sta_mask = BIT(20),
> + .ctl_offs = 0x0310,
> + .sram_pdn_bits = GENMASK(8, 8),
> + .sram_pdn_ack_bits = GENMASK(12, 12),
> + },
> + [MT8183_POWER_DOMAIN_MFG_2D] = {
> + .name = "mfg_2d",
> + .sta_mask = PWR_STATUS_MFG_2D,
> + .ctl_offs = 0x0348,
> + .sram_pdn_bits = GENMASK(8, 8),
> + .sram_pdn_ack_bits = GENMASK(12, 12),
> + .bp_table = {
> + BUS_PROT(IFR_TYPE, 0x2a8, 0x2ac, 0, 0x258,
> + BIT(19) | BIT(20) | BIT(21),
> + BIT(19) | BIT(20) | BIT(21)),
> + BUS_PROT(IFR_TYPE, 0x2a0, 0x2a4, 0, 0x228,
> + BIT(21) | BIT(22), BIT(21) | BIT(22)),
> + },
> + },
> + [MT8183_POWER_DOMAIN_DISP] = {
> + .name = "disp",
> + .sta_mask = PWR_STATUS_DISP,
> + .ctl_offs = 0x030c,
> + .sram_pdn_bits = GENMASK(8, 8),
> + .sram_pdn_ack_bits = GENMASK(12, 12),
> + .basic_clk_name = {"mm"},
> + .subsys_clk_prefix = "mm",
> + .bp_table = {
> + BUS_PROT(IFR_TYPE, 0x2a8, 0x2ac, 0, 0x258,
> + BIT(16) | BIT(17), BIT(16) | BIT(17)),
> + BUS_PROT(IFR_TYPE, 0x2a0, 0x2a4, 0, 0x228,
> + BIT(10) | BIT(11), BIT(10) | BIT(11)),
> + BUS_PROT(SMI_TYPE, 0x3c4, 0x3c8, 0, 0x3c0,
> + GENMASK(7, 0), GENMASK(7, 0)),
> + },
> + },
> + [MT8183_POWER_DOMAIN_CAM] = {
> + .name = "cam",
> + .sta_mask = BIT(25),
> + .ctl_offs = 0x0344,
> + .sram_pdn_bits = GENMASK(9, 8),
> + .sram_pdn_ack_bits = GENMASK(13, 12),
> + .basic_clk_name = {"cam"},
> + .subsys_clk_prefix = "cam",
> + .bp_table
Re: [PATCH v2 11/11] soc: mediatek: Add MT8183 scpsys support
On Tue, Nov 27, 2018 at 11:43 AM Weiyi Lu wrote:
>
> Add scpsys driver for MT8183
>
> Signed-off-by: Weiyi Lu
> ---
> drivers/soc/mediatek/mtk-scpsys.c | 227 +-
> 1 file changed, 226 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/mediatek/mtk-scpsys.c
> b/drivers/soc/mediatek/mtk-scpsys.c
> index 80be2e05e4e0..aac76c45a681 100644
> --- a/drivers/soc/mediatek/mtk-scpsys.c
> +++ b/drivers/soc/mediatek/mtk-scpsys.c
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
>
> #define MTK_POLL_DELAY_US 10
> #define MTK_POLL_TIMEOUT(jiffies_to_usecs(HZ))
> @@ -397,7 +398,6 @@ static int scpsys_power_on(struct generic_pm_domain
> *genpd)
> if (ret < 0)
> goto err_pwr_ack;
>
> -
Oh, this belongs in patch [04/11].
> val &= ~PWR_CLK_DIS_BIT;
> writel(val, ctl_addr);
>
> @@ -1179,6 +1179,217 @@ static const struct scp_subdomain
> scp_subdomain_mt8173[] = {
> {MT8173_POWER_DOMAIN_MFG_2D, MT8173_POWER_DOMAIN_MFG},
> };
>
> +/*
> + * MT8183 power domain support
> + */
> +
> +static const struct scp_domain_data scp_domain_data_mt8183[] = {
> + [MT8183_POWER_DOMAIN_AUDIO] = {
> + .name = "audio",
> + .sta_mask = PWR_STATUS_AUDIO,
> + .ctl_offs = 0x0314,
> + .sram_pdn_bits = GENMASK(11, 8),
> + .sram_pdn_ack_bits = GENMASK(15, 12),
> + .basic_clk_name = {"audio", "audio1", "audio2"},
> + },
> + [MT8183_POWER_DOMAIN_CONN] = {
> + .name = "conn",
> + .sta_mask = PWR_STATUS_CONN,
> + .ctl_offs = 0x032c,
> + .sram_pdn_bits = 0,
> + .sram_pdn_ack_bits = 0,
> + .bp_table = {
> + BUS_PROT(IFR_TYPE, 0x2a0, 0x2a4, 0, 0x228,
> + BIT(13) | BIT(14), BIT(13) | BIT(14)),
> + },
> + },
> + [MT8183_POWER_DOMAIN_MFG_ASYNC] = {
> + .name = "mfg_async",
> + .sta_mask = PWR_STATUS_MFG_ASYNC,
> + .ctl_offs = 0x0334,
> + .sram_pdn_bits = 0,
> + .sram_pdn_ack_bits = 0,
> + .basic_clk_name = {"mfg"},
> + },
> + [MT8183_POWER_DOMAIN_MFG] = {
> + .name = "mfg",
> + .sta_mask = PWR_STATUS_MFG,
> + .ctl_offs = 0x0338,
> + .sram_pdn_bits = GENMASK(8, 8),
> + .sram_pdn_ack_bits = GENMASK(12, 12),
> + },
> + [MT8183_POWER_DOMAIN_MFG_CORE0] = {
> + .name = "mfg_core0",
> + .sta_mask = BIT(7),
> + .ctl_offs = 0x034c,
> + .sram_pdn_bits = GENMASK(8, 8),
> + .sram_pdn_ack_bits = GENMASK(12, 12),
> + },
> + [MT8183_POWER_DOMAIN_MFG_CORE1] = {
> + .name = "mfg_core1",
> + .sta_mask = BIT(20),
> + .ctl_offs = 0x0310,
> + .sram_pdn_bits = GENMASK(8, 8),
> + .sram_pdn_ack_bits = GENMASK(12, 12),
> + },
> + [MT8183_POWER_DOMAIN_MFG_2D] = {
> + .name = "mfg_2d",
> + .sta_mask = PWR_STATUS_MFG_2D,
> + .ctl_offs = 0x0348,
> + .sram_pdn_bits = GENMASK(8, 8),
> + .sram_pdn_ack_bits = GENMASK(12, 12),
> + .bp_table = {
> + BUS_PROT(IFR_TYPE, 0x2a8, 0x2ac, 0, 0x258,
> + BIT(19) | BIT(20) | BIT(21),
> + BIT(19) | BIT(20) | BIT(21)),
> + BUS_PROT(IFR_TYPE, 0x2a0, 0x2a4, 0, 0x228,
> + BIT(21) | BIT(22), BIT(21) | BIT(22)),
> + },
> + },
> + [MT8183_POWER_DOMAIN_DISP] = {
> + .name = "disp",
> + .sta_mask = PWR_STATUS_DISP,
> + .ctl_offs = 0x030c,
> + .sram_pdn_bits = GENMASK(8, 8),
> + .sram_pdn_ack_bits = GENMASK(12, 12),
> + .basic_clk_name = {"mm"},
> + .subsys_clk_prefix = "mm",
> + .bp_table = {
> + BUS_PROT(IFR_TYPE, 0x2a8, 0x2ac, 0, 0x258,
> + BIT(16) | BIT(17), BIT(16) | BIT(17)),
> + BUS_PROT(IFR_TYPE, 0x2a0, 0x2a4, 0, 0x228,
> + BIT(10) | BIT(11), BIT(10) | BIT(11)),
> + BUS_PROT(SMI_TYPE, 0x3c4, 0x3c8, 0, 0x3c0,
> + GENMASK(7, 0), GENMASK(7, 0)),
> + },
> + },
> + [MT8183_POWER_DOMAIN_CAM] = {
> + .name = "cam",
> + .sta_mask = BIT(25),
> + .ctl_offs = 0x0344,
> + .sram_pdn_bits = GENMASK(9, 8),
> + .sram_pdn_ack_bits = GENMASK(13, 12),
> + .basic_clk_name = {"cam"},
> + .subsys_clk_prefix = "cam",
> + .bp_table
[PATCH 2/2] dt-bindings: thermal: add binding doc for i.MX system controller thermal driver
NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as
system controller, the system controller is in charge of system
power, clock and thermal sensors etc. management, Linux kernel
has to communicate with system controller via MU (message unit)
IPC to get temperature from thermal sensors, this patch adds
binding doc for i.MX system controller thermal driver.
Signed-off-by: Anson Huang
---
.../devicetree/bindings/thermal/imx-sc-thermal.txt | 33 ++
1 file changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/thermal/imx-sc-thermal.txt
diff --git a/Documentation/devicetree/bindings/thermal/imx-sc-thermal.txt
b/Documentation/devicetree/bindings/thermal/imx-sc-thermal.txt
new file mode 100644
index 000..2f5b0a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/imx-sc-thermal.txt
@@ -0,0 +1,33 @@
+* Temperature Monitor (TEMPMON) on NXP i.MX SoCs with System Controller
+
+Required properties:
+- compatible : Must be "nxp,imx8qxp-sc-thermal";
+- tsens-num : Total number of thermal sensors supported;
+- #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description.
+
+Example:
+tsens: thermal-sensor {
+ compatible = "nxp,imx8qxp-sc-thermal";
+ tsens-num = <1>;
+ #thermal-sensor-cells = <1>;
+};
+
+thermal_zones: thermal-zones {
+ cpu-thermal0 {
+ polling-delay-passive = <250>;
+ polling-delay = <2000>;
+ thermal-sensors = < 355>;
+ trips {
+ cpu_alert0: trip0 {
+ temperature = <107000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+ cpu_crit0: trip1 {
+ temperature = <127000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ };
+};
--
2.7.4
[PATCH 1/2] thermal: imx_sc: add i.MX system controller thermal support
i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
inside, the system controller is in charge of controlling power,
clock and thermal sensors etc..
This patch adds i.MX system controller thermal driver support,
Linux kernel has to communicate with system controller via MU
(message unit) IPC to get each thermal sensor's temperature,
it supports multiple sensors which are passed from device tree,
please see the binding doc for details.
Signed-off-by: Anson Huang
---
drivers/thermal/Kconfig | 11 ++
drivers/thermal/Makefile | 1 +
drivers/thermal/imx_sc_thermal.c | 221 +++
3 files changed, 233 insertions(+)
create mode 100644 drivers/thermal/imx_sc_thermal.c
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 0e69edc..84e850c 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -222,6 +222,17 @@ config IMX_THERMAL
cpufreq is used as the cooling device to throttle CPUs when the
passive trip is crossed.
+config IMX_SC_THERMAL
+ tristate "Temperature sensor driver for NXP i.MX SoCs with System
Controller"
+ depends on ARCH_MXC || COMPILE_TEST
+ depends on OF
+ help
+ Support for Temperature Monitor (TEMPMON) found on NXP i.MX SoCs with
+ system controller inside, Linux kernel has to communicate with system
+ controller via MU (message unit) IPC to get temperature from thermal
+ sensor. It supports one critical trip point and one
+ passive trip point for each thermal sensor.
+
config MAX77620_THERMAL
tristate "Temperature sensor driver for Maxim MAX77620 PMIC"
depends on MFD_MAX77620
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 610344e..1b13f6a 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_DB8500_THERMAL) += db8500_thermal.o
obj-$(CONFIG_ARMADA_THERMAL) += armada_thermal.o
obj-$(CONFIG_TANGO_THERMAL)+= tango_thermal.o
obj-$(CONFIG_IMX_THERMAL) += imx_thermal.o
+obj-$(CONFIG_IMX_SC_THERMAL) += imx_sc_thermal.o
obj-$(CONFIG_MAX77620_THERMAL) += max77620_thermal.o
obj-$(CONFIG_QORIQ_THERMAL)+= qoriq_thermal.o
obj-$(CONFIG_DA9062_THERMAL) += da9062-thermal.o
diff --git a/drivers/thermal/imx_sc_thermal.c b/drivers/thermal/imx_sc_thermal.c
new file mode 100644
index 000..2b34ce2
--- /dev/null
+++ b/drivers/thermal/imx_sc_thermal.c
@@ -0,0 +1,221 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2018 NXP.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "thermal_core.h"
+
+#define IMX_SC_MISC_FUNC_GET_TEMP 13
+#define IMX_SC_C_TEMP 0
+
+struct imx_sc_ipc *thermal_ipc_handle;
+
+struct imx_sc_sensor {
+ struct thermal_zone_device *tzd;
+ unsigned int resource_id;
+};
+
+struct imx_sc_thermal_data {
+ struct imx_sc_sensor *sensor;
+};
+
+struct imx_sc_msg_req_misc_get_temp {
+ struct imx_sc_rpc_msg hdr;
+ u16 resource_id;
+ u8 type;
+} __packed;
+
+struct imx_sc_msg_resp_misc_get_temp {
+ struct imx_sc_rpc_msg hdr;
+ u16 celsius;
+ u8 tenths;
+} __packed;
+
+static int imx_sc_thermal_get_temp(void *data, int *temp)
+{
+ struct imx_sc_msg_resp_misc_get_temp *resp;
+ struct imx_sc_msg_req_misc_get_temp msg;
+ struct imx_sc_rpc_msg *hdr =
+ struct imx_sc_sensor *sensor = data;
+ int ret;
+
+ msg.resource_id = sensor->resource_id;
+ msg.type = IMX_SC_C_TEMP;
+
+ hdr->ver = IMX_SC_RPC_VERSION;
+ hdr->svc = IMX_SC_RPC_SVC_MISC;
+ hdr->func = IMX_SC_MISC_FUNC_GET_TEMP;
+ hdr->size = 2;
+
+ ret = imx_scu_call_rpc(thermal_ipc_handle, , true);
+ if (ret) {
+ pr_err("read temp sensor %d failed, ret %d\n",
+ sensor->resource_id, ret);
+ return ret;
+ }
+
+ resp = (struct imx_sc_msg_resp_misc_get_temp *)
+ *temp = resp->celsius * 1000 + resp->tenths * 100;
+
+ return 0;
+}
+
+static const struct thermal_zone_of_device_ops imx_sc_thermal_ops = {
+ .get_temp = imx_sc_thermal_get_temp,
+};
+
+static int imx_sc_thermal_register_sensor(struct platform_device *pdev,
+ struct imx_sc_sensor *sensor)
+{
+ struct thermal_zone_device *tzd;
+
+ tzd = devm_thermal_zone_of_sensor_register(>dev,
+ sensor->resource_id,
+ sensor,
+ _sc_thermal_ops);
+ if (IS_ERR(tzd)) {
+ dev_err(>dev, "failed to register sensor: %d\n",
+
[PATCH 2/2] dt-bindings: thermal: add binding doc for i.MX system controller thermal driver
NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as
system controller, the system controller is in charge of system
power, clock and thermal sensors etc. management, Linux kernel
has to communicate with system controller via MU (message unit)
IPC to get temperature from thermal sensors, this patch adds
binding doc for i.MX system controller thermal driver.
Signed-off-by: Anson Huang
---
.../devicetree/bindings/thermal/imx-sc-thermal.txt | 33 ++
1 file changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/thermal/imx-sc-thermal.txt
diff --git a/Documentation/devicetree/bindings/thermal/imx-sc-thermal.txt
b/Documentation/devicetree/bindings/thermal/imx-sc-thermal.txt
new file mode 100644
index 000..2f5b0a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/imx-sc-thermal.txt
@@ -0,0 +1,33 @@
+* Temperature Monitor (TEMPMON) on NXP i.MX SoCs with System Controller
+
+Required properties:
+- compatible : Must be "nxp,imx8qxp-sc-thermal";
+- tsens-num : Total number of thermal sensors supported;
+- #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description.
+
+Example:
+tsens: thermal-sensor {
+ compatible = "nxp,imx8qxp-sc-thermal";
+ tsens-num = <1>;
+ #thermal-sensor-cells = <1>;
+};
+
+thermal_zones: thermal-zones {
+ cpu-thermal0 {
+ polling-delay-passive = <250>;
+ polling-delay = <2000>;
+ thermal-sensors = < 355>;
+ trips {
+ cpu_alert0: trip0 {
+ temperature = <107000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+ cpu_crit0: trip1 {
+ temperature = <127000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ };
+};
--
2.7.4
[PATCH 1/2] thermal: imx_sc: add i.MX system controller thermal support
i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
inside, the system controller is in charge of controlling power,
clock and thermal sensors etc..
This patch adds i.MX system controller thermal driver support,
Linux kernel has to communicate with system controller via MU
(message unit) IPC to get each thermal sensor's temperature,
it supports multiple sensors which are passed from device tree,
please see the binding doc for details.
Signed-off-by: Anson Huang
---
drivers/thermal/Kconfig | 11 ++
drivers/thermal/Makefile | 1 +
drivers/thermal/imx_sc_thermal.c | 221 +++
3 files changed, 233 insertions(+)
create mode 100644 drivers/thermal/imx_sc_thermal.c
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 0e69edc..84e850c 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -222,6 +222,17 @@ config IMX_THERMAL
cpufreq is used as the cooling device to throttle CPUs when the
passive trip is crossed.
+config IMX_SC_THERMAL
+ tristate "Temperature sensor driver for NXP i.MX SoCs with System
Controller"
+ depends on ARCH_MXC || COMPILE_TEST
+ depends on OF
+ help
+ Support for Temperature Monitor (TEMPMON) found on NXP i.MX SoCs with
+ system controller inside, Linux kernel has to communicate with system
+ controller via MU (message unit) IPC to get temperature from thermal
+ sensor. It supports one critical trip point and one
+ passive trip point for each thermal sensor.
+
config MAX77620_THERMAL
tristate "Temperature sensor driver for Maxim MAX77620 PMIC"
depends on MFD_MAX77620
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 610344e..1b13f6a 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_DB8500_THERMAL) += db8500_thermal.o
obj-$(CONFIG_ARMADA_THERMAL) += armada_thermal.o
obj-$(CONFIG_TANGO_THERMAL)+= tango_thermal.o
obj-$(CONFIG_IMX_THERMAL) += imx_thermal.o
+obj-$(CONFIG_IMX_SC_THERMAL) += imx_sc_thermal.o
obj-$(CONFIG_MAX77620_THERMAL) += max77620_thermal.o
obj-$(CONFIG_QORIQ_THERMAL)+= qoriq_thermal.o
obj-$(CONFIG_DA9062_THERMAL) += da9062-thermal.o
diff --git a/drivers/thermal/imx_sc_thermal.c b/drivers/thermal/imx_sc_thermal.c
new file mode 100644
index 000..2b34ce2
--- /dev/null
+++ b/drivers/thermal/imx_sc_thermal.c
@@ -0,0 +1,221 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2018 NXP.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "thermal_core.h"
+
+#define IMX_SC_MISC_FUNC_GET_TEMP 13
+#define IMX_SC_C_TEMP 0
+
+struct imx_sc_ipc *thermal_ipc_handle;
+
+struct imx_sc_sensor {
+ struct thermal_zone_device *tzd;
+ unsigned int resource_id;
+};
+
+struct imx_sc_thermal_data {
+ struct imx_sc_sensor *sensor;
+};
+
+struct imx_sc_msg_req_misc_get_temp {
+ struct imx_sc_rpc_msg hdr;
+ u16 resource_id;
+ u8 type;
+} __packed;
+
+struct imx_sc_msg_resp_misc_get_temp {
+ struct imx_sc_rpc_msg hdr;
+ u16 celsius;
+ u8 tenths;
+} __packed;
+
+static int imx_sc_thermal_get_temp(void *data, int *temp)
+{
+ struct imx_sc_msg_resp_misc_get_temp *resp;
+ struct imx_sc_msg_req_misc_get_temp msg;
+ struct imx_sc_rpc_msg *hdr =
+ struct imx_sc_sensor *sensor = data;
+ int ret;
+
+ msg.resource_id = sensor->resource_id;
+ msg.type = IMX_SC_C_TEMP;
+
+ hdr->ver = IMX_SC_RPC_VERSION;
+ hdr->svc = IMX_SC_RPC_SVC_MISC;
+ hdr->func = IMX_SC_MISC_FUNC_GET_TEMP;
+ hdr->size = 2;
+
+ ret = imx_scu_call_rpc(thermal_ipc_handle, , true);
+ if (ret) {
+ pr_err("read temp sensor %d failed, ret %d\n",
+ sensor->resource_id, ret);
+ return ret;
+ }
+
+ resp = (struct imx_sc_msg_resp_misc_get_temp *)
+ *temp = resp->celsius * 1000 + resp->tenths * 100;
+
+ return 0;
+}
+
+static const struct thermal_zone_of_device_ops imx_sc_thermal_ops = {
+ .get_temp = imx_sc_thermal_get_temp,
+};
+
+static int imx_sc_thermal_register_sensor(struct platform_device *pdev,
+ struct imx_sc_sensor *sensor)
+{
+ struct thermal_zone_device *tzd;
+
+ tzd = devm_thermal_zone_of_sensor_register(>dev,
+ sensor->resource_id,
+ sensor,
+ _sc_thermal_ops);
+ if (IS_ERR(tzd)) {
+ dev_err(>dev, "failed to register sensor: %d\n",
+
Re: [PATCH v2 04/11] soc: mediatek: add new flow for mtcmos power.
On Tue, Nov 27, 2018 at 11:43 AM Weiyi Lu wrote:
>
> From: Owen Chen
>
> Both MT8183 & MT6765 add more bus protect node than previous project,
> therefore we add two more register for setup bus protect, which reside
> at INFRA_CFG & SMI_COMMON.
>
> With the following change
> 1. bus protect need not only infracfg but smi_common registers involved
>to setup. Therefore we add a set/clr APIs with more customize arguments.
>
> The second change is that we also add subsys CG control flow before/after
> the bus protect/sram control, due to bus protect need SMI bus relative CGs
> enable to feed-back its ack, and some master's sram control need CG enable
> to on/off its resource sequentially.
>
> With the following change
> 1. turn on subsys CG before sram pwron and release bus protect.
> 2. turn off subsys CG after the process of set bus protect/receive
>ack/disable sram.
>
> The last change is for some power domains like vpu_core on MT8183 whose
> sram need to do clock and internal isolation while power on/off sram.
> We add a flag "sram_iso_ctrl" in scp_domain_data to judge if we need to
> do the extra sram isolation control or not.
>
> Signed-off-by: Owen Chen
> Signed-off-by: Mars Cheng
> Signed-off-by: Weiyi Lu
> ---
> drivers/soc/mediatek/Makefile | 2 +-
> drivers/soc/mediatek/mtk-scpsys-ext.c | 99 +++
> drivers/soc/mediatek/mtk-scpsys.c | 379 +++-
> include/linux/soc/mediatek/scpsys-ext.h | 39 +++
> 4 files changed, 448 insertions(+), 71 deletions(-)
> create mode 100644 drivers/soc/mediatek/mtk-scpsys-ext.c
> create mode 100644 include/linux/soc/mediatek/scpsys-ext.h
>
> diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
> index 12998b08819e..9dc6670c19cb 100644
> --- a/drivers/soc/mediatek/Makefile
> +++ b/drivers/soc/mediatek/Makefile
> @@ -1,3 +1,3 @@
> -obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
> +obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o mtk-scpsys-ext.o
> obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
> obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
> diff --git a/drivers/soc/mediatek/mtk-scpsys-ext.c
> b/drivers/soc/mediatek/mtk-scpsys-ext.c
> new file mode 100644
> index ..54df42db2a8f
> --- /dev/null
> +++ b/drivers/soc/mediatek/mtk-scpsys-ext.c
> @@ -0,0 +1,99 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018 MediaTek Inc.
> + * Author: Owen Chen
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define MTK_POLL_DELAY_US 10
> +#define MTK_POLL_TIMEOUT(jiffies_to_usecs(HZ))
> +
> +static int set_bus_protection(struct regmap *map, u32 mask, u32 ack_mask,
> + u32 reg_set, u32 reg_sta, u32 reg_en)
> +{
> + u32 val;
> +
> + if (reg_set)
> + regmap_write(map, reg_set, mask);
> + else
> + regmap_update_bits(map, reg_en, mask, mask);
> +
> + return regmap_read_poll_timeout(map, reg_sta,
> + val, (val & ack_mask) == ack_mask,
> + MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
> +}
> +
> +static int clear_bus_protection(struct regmap *map, u32 mask, u32 ack_mask,
> + u32 reg_clr, u32 reg_sta, u32 reg_en)
> +{
> + u32 val;
> +
> + if (reg_clr)
> + regmap_write(map, reg_clr, mask);
> + else
> + regmap_update_bits(map, reg_en, mask, 0);
> +
> + return regmap_read_poll_timeout(map, reg_sta,
> + val, !(val & ack_mask),
> + MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
> +}
> +
> +int mtk_scpsys_ext_set_bus_protection(const struct bus_prot *bp_table,
> + struct regmap *infracfg, struct regmap *smi_common)
> +{
> + int i;
> +
> + for (i = 0; i < MAX_STEPS && bp_table[i].mask; i++) {
> + struct regmap *map;
> + int ret;
> +
> + if (bp_table[i].type == IFR_TYPE)
> + map = infracfg;
> + else if (bp_table[i].type == SMI_TYPE)
> + map = smi_common;
> + else
> + return -EINVAL;
> +
> + ret = set_bus_protection(map,
> + bp_table[i].mask, bp_table[i].mask,
> + bp_table[i].set_ofs, bp_table[i].sta_ofs,
> + bp_table[i].en_ofs);
> +
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +int mtk_scpsys_ext_clear_bus_protection(const struct bus_prot *bp_table,
> + struct regmap *infracfg, struct regmap *smi_common)
> +{
> + int i;
> +
> + for (i = MAX_STEPS - 1; i >= 0; i--) {
> + struct regmap *map;
> + int ret;
> +
> + if (bp_table[i].type == IFR_TYPE)
> + map = infracfg;
> + else if (bp_table[i].type == SMI_TYPE)
> + map = smi_common;
Re: [PATCH v2 04/11] soc: mediatek: add new flow for mtcmos power.
On Tue, Nov 27, 2018 at 11:43 AM Weiyi Lu wrote:
>
> From: Owen Chen
>
> Both MT8183 & MT6765 add more bus protect node than previous project,
> therefore we add two more register for setup bus protect, which reside
> at INFRA_CFG & SMI_COMMON.
>
> With the following change
> 1. bus protect need not only infracfg but smi_common registers involved
>to setup. Therefore we add a set/clr APIs with more customize arguments.
>
> The second change is that we also add subsys CG control flow before/after
> the bus protect/sram control, due to bus protect need SMI bus relative CGs
> enable to feed-back its ack, and some master's sram control need CG enable
> to on/off its resource sequentially.
>
> With the following change
> 1. turn on subsys CG before sram pwron and release bus protect.
> 2. turn off subsys CG after the process of set bus protect/receive
>ack/disable sram.
>
> The last change is for some power domains like vpu_core on MT8183 whose
> sram need to do clock and internal isolation while power on/off sram.
> We add a flag "sram_iso_ctrl" in scp_domain_data to judge if we need to
> do the extra sram isolation control or not.
>
> Signed-off-by: Owen Chen
> Signed-off-by: Mars Cheng
> Signed-off-by: Weiyi Lu
> ---
> drivers/soc/mediatek/Makefile | 2 +-
> drivers/soc/mediatek/mtk-scpsys-ext.c | 99 +++
> drivers/soc/mediatek/mtk-scpsys.c | 379 +++-
> include/linux/soc/mediatek/scpsys-ext.h | 39 +++
> 4 files changed, 448 insertions(+), 71 deletions(-)
> create mode 100644 drivers/soc/mediatek/mtk-scpsys-ext.c
> create mode 100644 include/linux/soc/mediatek/scpsys-ext.h
>
> diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
> index 12998b08819e..9dc6670c19cb 100644
> --- a/drivers/soc/mediatek/Makefile
> +++ b/drivers/soc/mediatek/Makefile
> @@ -1,3 +1,3 @@
> -obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
> +obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o mtk-scpsys-ext.o
> obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
> obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
> diff --git a/drivers/soc/mediatek/mtk-scpsys-ext.c
> b/drivers/soc/mediatek/mtk-scpsys-ext.c
> new file mode 100644
> index ..54df42db2a8f
> --- /dev/null
> +++ b/drivers/soc/mediatek/mtk-scpsys-ext.c
> @@ -0,0 +1,99 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018 MediaTek Inc.
> + * Author: Owen Chen
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define MTK_POLL_DELAY_US 10
> +#define MTK_POLL_TIMEOUT(jiffies_to_usecs(HZ))
> +
> +static int set_bus_protection(struct regmap *map, u32 mask, u32 ack_mask,
> + u32 reg_set, u32 reg_sta, u32 reg_en)
> +{
> + u32 val;
> +
> + if (reg_set)
> + regmap_write(map, reg_set, mask);
> + else
> + regmap_update_bits(map, reg_en, mask, mask);
> +
> + return regmap_read_poll_timeout(map, reg_sta,
> + val, (val & ack_mask) == ack_mask,
> + MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
> +}
> +
> +static int clear_bus_protection(struct regmap *map, u32 mask, u32 ack_mask,
> + u32 reg_clr, u32 reg_sta, u32 reg_en)
> +{
> + u32 val;
> +
> + if (reg_clr)
> + regmap_write(map, reg_clr, mask);
> + else
> + regmap_update_bits(map, reg_en, mask, 0);
> +
> + return regmap_read_poll_timeout(map, reg_sta,
> + val, !(val & ack_mask),
> + MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
> +}
> +
> +int mtk_scpsys_ext_set_bus_protection(const struct bus_prot *bp_table,
> + struct regmap *infracfg, struct regmap *smi_common)
> +{
> + int i;
> +
> + for (i = 0; i < MAX_STEPS && bp_table[i].mask; i++) {
> + struct regmap *map;
> + int ret;
> +
> + if (bp_table[i].type == IFR_TYPE)
> + map = infracfg;
> + else if (bp_table[i].type == SMI_TYPE)
> + map = smi_common;
> + else
> + return -EINVAL;
> +
> + ret = set_bus_protection(map,
> + bp_table[i].mask, bp_table[i].mask,
> + bp_table[i].set_ofs, bp_table[i].sta_ofs,
> + bp_table[i].en_ofs);
> +
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +int mtk_scpsys_ext_clear_bus_protection(const struct bus_prot *bp_table,
> + struct regmap *infracfg, struct regmap *smi_common)
> +{
> + int i;
> +
> + for (i = MAX_STEPS - 1; i >= 0; i--) {
> + struct regmap *map;
> + int ret;
> +
> + if (bp_table[i].type == IFR_TYPE)
> + map = infracfg;
> + else if (bp_table[i].type == SMI_TYPE)
> + map = smi_common;
[PATCH v3 7/7] zram: writeback throttle
On small memory system, there are lots of write IO so if we use
flash device as swap, there would be serious flash wearout.
To overcome the problem, system developers need to design write
limitation strategy to guarantee flash health for entire product life.
This patch creates a new konb "writeback_limit" on zram. With that,
if current writeback IO count(/sys/block/zramX/io_stat) excceds
the limitation, zram stops further writeback until admin can reset
the limit.
Signed-off-by: Minchan Kim
---
Documentation/ABI/testing/sysfs-block-zram | 9 +
Documentation/blockdev/zram.txt| 2 +
drivers/block/zram/zram_drv.c | 47 +-
drivers/block/zram/zram_drv.h | 2 +
4 files changed, 59 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-block-zram
b/Documentation/ABI/testing/sysfs-block-zram
index 65fc33b2f53b..9d2339a485c8 100644
--- a/Documentation/ABI/testing/sysfs-block-zram
+++ b/Documentation/ABI/testing/sysfs-block-zram
@@ -121,3 +121,12 @@ Contact: Minchan Kim
The bd_stat file is read-only and represents backing device's
statistics (bd_count, bd_reads, bd_writes) in a format
similar to block layer statistics file format.
+
+What: /sys/block/zram/writeback_limit
+Date: November 2018
+Contact: Minchan Kim
+Description:
+ The writeback_limit file is read-write and specifies the maximum
+ amount of writeback ZRAM can do. The limit could be changed
+ in run time and "0" means disable the limit.
+ No limit is the initial state.
diff --git a/Documentation/blockdev/zram.txt b/Documentation/blockdev/zram.txt
index 906df97527a7..64b61925e475 100644
--- a/Documentation/blockdev/zram.txt
+++ b/Documentation/blockdev/zram.txt
@@ -164,6 +164,8 @@ reset WOtrigger device reset
mem_used_max WOreset the `mem_used_max' counter (see later)
mem_limit WOspecifies the maximum amount of memory ZRAM can use
to store the compressed data
+writeback_limit WOspecifies the maximum amount of write IO zram can
+ write out to backing device as 4KB unit
max_comp_streams RWthe number of possible concurrent compress operations
comp_algorithmRWshow and change the compression algorithm
compact WOtrigger memory compaction
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 67168a6ecca6..58b025c5c83e 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -330,6 +330,40 @@ static ssize_t idle_store(struct device *dev,
}
#ifdef CONFIG_ZRAM_WRITEBACK
+
+static ssize_t writeback_limit_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t len)
+{
+ struct zram *zram = dev_to_zram(dev);
+ u64 val;
+ ssize_t ret = -EINVAL;
+
+ if (kstrtoull(buf, 10, ))
+ return ret;
+
+ down_read(>init_lock);
+ atomic64_set(>stats.bd_wb_limit, val);
+ if (val == 0 || val > atomic64_read(>stats.bd_writes))
+ zram->stop_writeback = false;
+ up_read(>init_lock);
+ ret = len;
+
+ return ret;
+}
+
+static ssize_t writeback_limit_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ u64 val;
+ struct zram *zram = dev_to_zram(dev);
+
+ down_read(>init_lock);
+ val = atomic64_read(>stats.bd_wb_limit);
+ up_read(>init_lock);
+
+ return scnprintf(buf, PAGE_SIZE, "%llu\n", val);
+}
+
static void reset_bdev(struct zram *zram)
{
struct block_device *bdev;
@@ -571,6 +605,7 @@ static ssize_t writeback_store(struct device *dev,
char mode_buf[8];
unsigned long mode = -1UL;
unsigned long blk_idx = 0;
+ u64 wb_count, wb_limit;
sz = strscpy(mode_buf, buf, sizeof(mode_buf));
if (sz <= 0)
@@ -612,6 +647,11 @@ static ssize_t writeback_store(struct device *dev,
bvec.bv_len = PAGE_SIZE;
bvec.bv_offset = 0;
+ if (zram->stop_writeback) {
+ ret = -EIO;
+ break;
+ }
+
if (!blk_idx) {
blk_idx = alloc_block_bdev(zram);
if (!blk_idx) {
@@ -670,7 +710,7 @@ static ssize_t writeback_store(struct device *dev,
continue;
}
- atomic64_inc(>stats.bd_writes);
+ wb_count = atomic64_inc_return(>stats.bd_writes);
/*
* We released zram_slot_lock so need to check if the slot was
* changed. If there is freeing for the slot, we can catch it
@@ -694,6 +734,9 @@ static ssize_t writeback_store(struct device *dev,
zram_set_element(zram, index, blk_idx);
[PATCH v3 7/7] zram: writeback throttle
On small memory system, there are lots of write IO so if we use
flash device as swap, there would be serious flash wearout.
To overcome the problem, system developers need to design write
limitation strategy to guarantee flash health for entire product life.
This patch creates a new konb "writeback_limit" on zram. With that,
if current writeback IO count(/sys/block/zramX/io_stat) excceds
the limitation, zram stops further writeback until admin can reset
the limit.
Signed-off-by: Minchan Kim
---
Documentation/ABI/testing/sysfs-block-zram | 9 +
Documentation/blockdev/zram.txt| 2 +
drivers/block/zram/zram_drv.c | 47 +-
drivers/block/zram/zram_drv.h | 2 +
4 files changed, 59 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-block-zram
b/Documentation/ABI/testing/sysfs-block-zram
index 65fc33b2f53b..9d2339a485c8 100644
--- a/Documentation/ABI/testing/sysfs-block-zram
+++ b/Documentation/ABI/testing/sysfs-block-zram
@@ -121,3 +121,12 @@ Contact: Minchan Kim
The bd_stat file is read-only and represents backing device's
statistics (bd_count, bd_reads, bd_writes) in a format
similar to block layer statistics file format.
+
+What: /sys/block/zram/writeback_limit
+Date: November 2018
+Contact: Minchan Kim
+Description:
+ The writeback_limit file is read-write and specifies the maximum
+ amount of writeback ZRAM can do. The limit could be changed
+ in run time and "0" means disable the limit.
+ No limit is the initial state.
diff --git a/Documentation/blockdev/zram.txt b/Documentation/blockdev/zram.txt
index 906df97527a7..64b61925e475 100644
--- a/Documentation/blockdev/zram.txt
+++ b/Documentation/blockdev/zram.txt
@@ -164,6 +164,8 @@ reset WOtrigger device reset
mem_used_max WOreset the `mem_used_max' counter (see later)
mem_limit WOspecifies the maximum amount of memory ZRAM can use
to store the compressed data
+writeback_limit WOspecifies the maximum amount of write IO zram can
+ write out to backing device as 4KB unit
max_comp_streams RWthe number of possible concurrent compress operations
comp_algorithmRWshow and change the compression algorithm
compact WOtrigger memory compaction
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 67168a6ecca6..58b025c5c83e 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -330,6 +330,40 @@ static ssize_t idle_store(struct device *dev,
}
#ifdef CONFIG_ZRAM_WRITEBACK
+
+static ssize_t writeback_limit_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t len)
+{
+ struct zram *zram = dev_to_zram(dev);
+ u64 val;
+ ssize_t ret = -EINVAL;
+
+ if (kstrtoull(buf, 10, ))
+ return ret;
+
+ down_read(>init_lock);
+ atomic64_set(>stats.bd_wb_limit, val);
+ if (val == 0 || val > atomic64_read(>stats.bd_writes))
+ zram->stop_writeback = false;
+ up_read(>init_lock);
+ ret = len;
+
+ return ret;
+}
+
+static ssize_t writeback_limit_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ u64 val;
+ struct zram *zram = dev_to_zram(dev);
+
+ down_read(>init_lock);
+ val = atomic64_read(>stats.bd_wb_limit);
+ up_read(>init_lock);
+
+ return scnprintf(buf, PAGE_SIZE, "%llu\n", val);
+}
+
static void reset_bdev(struct zram *zram)
{
struct block_device *bdev;
@@ -571,6 +605,7 @@ static ssize_t writeback_store(struct device *dev,
char mode_buf[8];
unsigned long mode = -1UL;
unsigned long blk_idx = 0;
+ u64 wb_count, wb_limit;
sz = strscpy(mode_buf, buf, sizeof(mode_buf));
if (sz <= 0)
@@ -612,6 +647,11 @@ static ssize_t writeback_store(struct device *dev,
bvec.bv_len = PAGE_SIZE;
bvec.bv_offset = 0;
+ if (zram->stop_writeback) {
+ ret = -EIO;
+ break;
+ }
+
if (!blk_idx) {
blk_idx = alloc_block_bdev(zram);
if (!blk_idx) {
@@ -670,7 +710,7 @@ static ssize_t writeback_store(struct device *dev,
continue;
}
- atomic64_inc(>stats.bd_writes);
+ wb_count = atomic64_inc_return(>stats.bd_writes);
/*
* We released zram_slot_lock so need to check if the slot was
* changed. If there is freeing for the slot, we can catch it
@@ -694,6 +734,9 @@ static ssize_t writeback_store(struct device *dev,
zram_set_element(zram, index, blk_idx);
[PATCH v3 3/7] zram: refactoring flags and writeback stuff
This patch does renaming some variables and restructuring
some codes for better redability in writeback and zs_free_page.
Signed-off-by: Minchan Kim
---
drivers/block/zram/zram_drv.c | 105 +-
drivers/block/zram/zram_drv.h | 8 +--
2 files changed, 44 insertions(+), 69 deletions(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index d1459cc1159f..4457d0395bfb 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -55,17 +55,17 @@ static void zram_free_page(struct zram *zram, size_t index);
static int zram_slot_trylock(struct zram *zram, u32 index)
{
- return bit_spin_trylock(ZRAM_LOCK, >table[index].value);
+ return bit_spin_trylock(ZRAM_LOCK, >table[index].flags);
}
static void zram_slot_lock(struct zram *zram, u32 index)
{
- bit_spin_lock(ZRAM_LOCK, >table[index].value);
+ bit_spin_lock(ZRAM_LOCK, >table[index].flags);
}
static void zram_slot_unlock(struct zram *zram, u32 index)
{
- bit_spin_unlock(ZRAM_LOCK, >table[index].value);
+ bit_spin_unlock(ZRAM_LOCK, >table[index].flags);
}
static inline bool init_done(struct zram *zram)
@@ -76,7 +76,7 @@ static inline bool init_done(struct zram *zram)
static inline bool zram_allocated(struct zram *zram, u32 index)
{
- return (zram->table[index].value >> (ZRAM_FLAG_SHIFT + 1)) ||
+ return (zram->table[index].flags >> (ZRAM_FLAG_SHIFT + 1)) ||
zram->table[index].handle;
}
@@ -99,19 +99,19 @@ static void zram_set_handle(struct zram *zram, u32 index,
unsigned long handle)
static bool zram_test_flag(struct zram *zram, u32 index,
enum zram_pageflags flag)
{
- return zram->table[index].value & BIT(flag);
+ return zram->table[index].flags & BIT(flag);
}
static void zram_set_flag(struct zram *zram, u32 index,
enum zram_pageflags flag)
{
- zram->table[index].value |= BIT(flag);
+ zram->table[index].flags |= BIT(flag);
}
static void zram_clear_flag(struct zram *zram, u32 index,
enum zram_pageflags flag)
{
- zram->table[index].value &= ~BIT(flag);
+ zram->table[index].flags &= ~BIT(flag);
}
static inline void zram_set_element(struct zram *zram, u32 index,
@@ -127,15 +127,15 @@ static unsigned long zram_get_element(struct zram *zram,
u32 index)
static size_t zram_get_obj_size(struct zram *zram, u32 index)
{
- return zram->table[index].value & (BIT(ZRAM_FLAG_SHIFT) - 1);
+ return zram->table[index].flags & (BIT(ZRAM_FLAG_SHIFT) - 1);
}
static void zram_set_obj_size(struct zram *zram,
u32 index, size_t size)
{
- unsigned long flags = zram->table[index].value >> ZRAM_FLAG_SHIFT;
+ unsigned long flags = zram->table[index].flags >> ZRAM_FLAG_SHIFT;
- zram->table[index].value = (flags << ZRAM_FLAG_SHIFT) | size;
+ zram->table[index].flags = (flags << ZRAM_FLAG_SHIFT) | size;
}
#if PAGE_SIZE != 4096
@@ -282,16 +282,11 @@ static ssize_t mem_used_max_store(struct device *dev,
}
#ifdef CONFIG_ZRAM_WRITEBACK
-static bool zram_wb_enabled(struct zram *zram)
-{
- return zram->backing_dev;
-}
-
static void reset_bdev(struct zram *zram)
{
struct block_device *bdev;
- if (!zram_wb_enabled(zram))
+ if (!zram->backing_dev)
return;
bdev = zram->bdev;
@@ -318,7 +313,7 @@ static ssize_t backing_dev_show(struct device *dev,
ssize_t ret;
down_read(>init_lock);
- if (!zram_wb_enabled(zram)) {
+ if (!zram->backing_dev) {
memcpy(buf, "none\n", 5);
up_read(>init_lock);
return 5;
@@ -447,7 +442,7 @@ static ssize_t backing_dev_store(struct device *dev,
return err;
}
-static unsigned long get_entry_bdev(struct zram *zram)
+static unsigned long alloc_block_bdev(struct zram *zram)
{
unsigned long blk_idx = 1;
retry:
@@ -462,11 +457,11 @@ static unsigned long get_entry_bdev(struct zram *zram)
return blk_idx;
}
-static void put_entry_bdev(struct zram *zram, unsigned long entry)
+static void free_block_bdev(struct zram *zram, unsigned long blk_idx)
{
int was_set;
- was_set = test_and_clear_bit(entry, zram->bitmap);
+ was_set = test_and_clear_bit(blk_idx, zram->bitmap);
WARN_ON_ONCE(!was_set);
}
@@ -579,7 +574,7 @@ static int write_to_bdev(struct zram *zram, struct bio_vec
*bvec,
if (!bio)
return -ENOMEM;
- entry = get_entry_bdev(zram);
+ entry = alloc_block_bdev(zram);
if (!entry) {
bio_put(bio);
return -ENOSPC;
@@ -590,7 +585,7 @@ static int write_to_bdev(struct zram *zram, struct bio_vec
*bvec,
if (!bio_add_page(bio, bvec->bv_page, bvec->bv_len,
bvec->bv_offset)) {
[PATCH v3 6/7] zram: add bd_stat statistics
bd_stat represents things happened in backing device. Currently,
it supports bd_counts, bd_reads and bd_writes which are helpful
to understand wearout of flash and memory saving.
Signed-off-by: Minchan Kim
---
Documentation/ABI/testing/sysfs-block-zram | 8 ++
Documentation/blockdev/zram.txt| 11
drivers/block/zram/zram_drv.c | 29 ++
drivers/block/zram/zram_drv.h | 5
4 files changed, 53 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-block-zram
b/Documentation/ABI/testing/sysfs-block-zram
index d1f80b077885..65fc33b2f53b 100644
--- a/Documentation/ABI/testing/sysfs-block-zram
+++ b/Documentation/ABI/testing/sysfs-block-zram
@@ -113,3 +113,11 @@ Contact: Minchan Kim
Description:
The writeback file is write-only and trigger idle and/or
huge page writeback to backing device.
+
+What: /sys/block/zram/bd_stat
+Date: November 2018
+Contact: Minchan Kim
+Description:
+ The bd_stat file is read-only and represents backing device's
+ statistics (bd_count, bd_reads, bd_writes) in a format
+ similar to block layer statistics file format.
diff --git a/Documentation/blockdev/zram.txt b/Documentation/blockdev/zram.txt
index 806cdaabac83..906df97527a7 100644
--- a/Documentation/blockdev/zram.txt
+++ b/Documentation/blockdev/zram.txt
@@ -221,6 +221,17 @@ The stat file represents device's mm statistics. It
consists of a single
pages_compacted the number of pages freed during compaction
huge_pages the number of incompressible pages
+File /sys/block/zram/bd_stat
+
+The stat file represents device's backing device statistics. It consists of
+a single line of text and contains the following stats separated by whitespace:
+ bd_count size of data written in backing device.
+ Unit: 4K bytes
+ bd_reads the number of reads from backing device
+ Unit: 4K bytes
+ bd_writes the number of writes to backing device
+ Unit: 4K bytes
+
9) Deactivate:
swapoff /dev/zram0
umount /dev/zram1
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 6b5a886c8f32..67168a6ecca6 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -502,6 +502,7 @@ static unsigned long alloc_block_bdev(struct zram *zram)
if (test_and_set_bit(blk_idx, zram->bitmap))
goto retry;
+ atomic64_inc(>stats.bd_count);
return blk_idx;
}
@@ -511,6 +512,7 @@ static void free_block_bdev(struct zram *zram, unsigned
long blk_idx)
was_set = test_and_clear_bit(blk_idx, zram->bitmap);
WARN_ON_ONCE(!was_set);
+ atomic64_dec(>stats.bd_count);
}
static void zram_page_end_io(struct bio *bio)
@@ -668,6 +670,7 @@ static ssize_t writeback_store(struct device *dev,
continue;
}
+ atomic64_inc(>stats.bd_writes);
/*
* We released zram_slot_lock so need to check if the slot was
* changed. If there is freeing for the slot, we can catch it
@@ -757,6 +760,7 @@ static int read_from_bdev_sync(struct zram *zram, struct
bio_vec *bvec,
static int read_from_bdev(struct zram *zram, struct bio_vec *bvec,
unsigned long entry, struct bio *parent, bool sync)
{
+ atomic64_inc(>stats.bd_reads);
if (sync)
return read_from_bdev_sync(zram, bvec, entry, parent);
else
@@ -1013,6 +1017,25 @@ static ssize_t mm_stat_show(struct device *dev,
return ret;
}
+#ifdef CONFIG_ZRAM_WRITEBACK
+static ssize_t bd_stat_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct zram *zram = dev_to_zram(dev);
+ ssize_t ret;
+
+ down_read(>init_lock);
+ ret = scnprintf(buf, PAGE_SIZE,
+ "%8llu %8llu %8llu\n",
+ (u64)atomic64_read(>stats.bd_count),
+ (u64)atomic64_read(>stats.bd_reads),
+ (u64)atomic64_read(>stats.bd_writes));
+ up_read(>init_lock);
+
+ return ret;
+}
+#endif
+
static ssize_t debug_stat_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -1033,6 +1056,9 @@ static ssize_t debug_stat_show(struct device *dev,
static DEVICE_ATTR_RO(io_stat);
static DEVICE_ATTR_RO(mm_stat);
+#ifdef CONFIG_ZRAM_WRITEBACK
+static DEVICE_ATTR_RO(bd_stat);
+#endif
static DEVICE_ATTR_RO(debug_stat);
static void zram_meta_free(struct zram *zram, u64 disksize)
@@ -1759,6 +1785,9 @@ static struct attribute *zram_disk_attrs[] = {
#endif
_attr_io_stat.attr,
_attr_mm_stat.attr,
+#ifdef CONFIG_ZRAM_WRITEBACK
+ _attr_bd_stat.attr,
+#endif
_attr_debug_stat.attr,
NULL,
};
diff --git a/drivers/block/zram/zram_drv.h
[PATCH v3 5/7] zram: support idle/huge page writeback
This patch supports new feature "zram idle/huge page writeback".
On zram-swap usecase, zram has usually many idle/huge swap pages.
It's pointless to keep in memory(ie, zram).
To solve the problem, this feature introduces idle/huge page
writeback to backing device so the goal is to save more memory
space on embedded system.
Normal sequence to use idle/huge page writeback feature is as follows,
while (1) {
# mark allocated zram slot to idle
echo all > /sys/block/zram0/idle
# leave system working for several hours
# Unless there is no access for some blocks on zram,
# they are still IDLE marked pages.
echo "idle" > /sys/block/zram0/writeback
or/and
echo "huge" > /sys/block/zram0/writeback
# write the IDLE or/and huge marked slot into backing device
# and free the memory.
}
By per discussion:
https://lore.kernel.org/lkml/20181122065926.GG3441@jagdpanzerIV/T/#u,
This patch removes direct incommpressibe page writeback feature
(d2afd25114f4, zram: write incompressible pages to backing device)
so we could regard it as regression because incompressible pages
doesn't go to backing storage automatically. Instead, usre should
do it via "echo huge" > /sys/block/zram/writeback" manually.
If we hear some regression, we could restore the function.
Reviewed-by: Joey Pabalinas
Signed-off-by: Minchan Kim
---
Documentation/ABI/testing/sysfs-block-zram | 7 +
Documentation/blockdev/zram.txt| 28 ++-
drivers/block/zram/Kconfig | 5 +-
drivers/block/zram/zram_drv.c | 247 +++--
drivers/block/zram/zram_drv.h | 1 +
5 files changed, 209 insertions(+), 79 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-block-zram
b/Documentation/ABI/testing/sysfs-block-zram
index 04c9a5980bc7..d1f80b077885 100644
--- a/Documentation/ABI/testing/sysfs-block-zram
+++ b/Documentation/ABI/testing/sysfs-block-zram
@@ -106,3 +106,10 @@ Contact: Minchan Kim
idle file is write-only and mark zram slot as idle.
If system has mounted debugfs, user can see which slots
are idle via /sys/kernel/debug/zram/zram/block_state
+
+What: /sys/block/zram/writeback
+Date: November 2018
+Contact: Minchan Kim
+Description:
+ The writeback file is write-only and trigger idle and/or
+ huge page writeback to backing device.
diff --git a/Documentation/blockdev/zram.txt b/Documentation/blockdev/zram.txt
index f3bcd716d8a9..806cdaabac83 100644
--- a/Documentation/blockdev/zram.txt
+++ b/Documentation/blockdev/zram.txt
@@ -238,11 +238,31 @@ The stat file represents device's mm statistics. It
consists of a single
= writeback
-With incompressible pages, there is no memory saving with zram.
-Instead, with CONFIG_ZRAM_WRITEBACK, zram can write incompressible page
+With CONFIG_ZRAM_WRITEBACK, zram can write idle/incompressible page
to backing storage rather than keeping it in memory.
-User should set up backing device via /sys/block/zramX/backing_dev
-before disksize setting.
+To use the feature, admin should set up backing device via
+
+ "echo /dev/sda5 > /sys/block/zramX/backing_dev"
+
+before disksize setting. It supports only partition at this moment.
+If admin want to use incompressible page writeback, they could do via
+
+ "echo huge > /sys/block/zramX/write"
+
+To use idle page writeback, first, user need to declare zram pages
+as idle.
+
+ "echo all > /sys/block/zramX/idle"
+
+From now on, any pages on zram are idle pages. The idle mark
+will be removed until someone request access of the block.
+IOW, unless there is access request, those pages are still idle pages.
+
+Admin can request writeback of those idle pages at right timing via
+
+ "echo idle > /sys/block/zramX/writeback"
+
+With the command, zram writeback idle pages from memory to the storage.
= memory tracking
diff --git a/drivers/block/zram/Kconfig b/drivers/block/zram/Kconfig
index fcd055457364..1ffc64770643 100644
--- a/drivers/block/zram/Kconfig
+++ b/drivers/block/zram/Kconfig
@@ -15,7 +15,7 @@ config ZRAM
See Documentation/blockdev/zram.txt for more information.
config ZRAM_WRITEBACK
- bool "Write back incompressible page to backing device"
+ bool "Write back incompressible or idle page to backing device"
depends on ZRAM
help
With incompressible page, there is no memory saving to keep it
@@ -23,6 +23,9 @@ config ZRAM_WRITEBACK
For this feature, admin should set up backing device via
/sys/block/zramX/backing_dev.
+With /sys/block/zramX/{idle,writeback}, application could ask
+idle page's writeback to the backing device to save in memory.
+
See Documentation/blockdev/zram.txt for more information.
config ZRAM_MEMORY_TRACKING
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
[PATCH v3 2/7] zram: fix double free backing device
If blkdev_get fails, we shouldn't do blkdev_put. Otherwise,
kernel emits below log. This patch fixes it.
[ 31.073006] WARNING: CPU: 0 PID: 1893 at fs/block_dev.c:1828
blkdev_put+0x105/0x120
[ 31.075104] Modules linked in:
[ 31.075898] CPU: 0 PID: 1893 Comm: swapoff Not tainted 4.19.0+ #453
[ 31.077484] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-1 04/01/2014
[ 31.079589] RIP: 0010:blkdev_put+0x105/0x120
[ 31.080606] Code: 48 c7 80 a0 00 00 00 00 00 00 00 48 c7 c7 40 e7 40 96 e8
6e 47 73 00 48 8b bb e0 00 00 00 e9 2c ff ff ff 0f 0b e9 75 ff ff ff <0f> 0b e9
5a ff ff ff 48 c7 80 a0 00 00 00 00 00 00 00 eb 87 0f 1f
[ 31.085080] RSP: 0018:b409005c7ed0 EFLAGS: 00010297
[ 31.086383] RAX: 9779fe5a8040 RBX: 9779fbc17300 RCX: b9fc37a4
[ 31.088105] RDX: 0001 RSI: RDI: 9640e740
[ 31.089850] RBP: 9779fbc17318 R08: 95499a89 R09: 0004
[ 31.091201] R10: b409005c7e50 R11: 7a9ef6088ff4d4a1 R12: 0083
[ 31.092276] R13: 9779fe607b98 R14: R15: 9779fe607a38
[ 31.093355] FS: 7fc118d9b840() GS:9779fc60()
knlGS:
[ 31.094582] CS: 0010 DS: ES: CR0: 80050033
[ 31.095541] CR2: 7fc11894b8dc CR3: 339f6001 CR4: 00160ef0
[ 31.096781] Call Trace:
[ 31.097212] __x64_sys_swapoff+0x46d/0x490
[ 31.097914] do_syscall_64+0x5a/0x190
[ 31.098550] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 31.099402] RIP: 0033:0x7fc11843ec27
[ 31.100013] Code: 73 01 c3 48 8b 0d 71 62 2c 00 f7 d8 64 89 01 48 83 c8 ff
c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 a8 00 00 00 0f 05 <48> 3d 01
f0 ff ff 73 01 c3 48 8b 0d 41 62 2c 00 f7 d8 64 89 01 48
[ 31.103149] RSP: 002b:7ffdf69be648 EFLAGS: 0206 ORIG_RAX:
00a8
[ 31.104425] RAX: ffda RBX: 011d98c0 RCX: 7fc11843ec27
[ 31.105627] RDX: 0001 RSI: 0001 RDI: 011d98c0
[ 31.106847] RBP: 0001 R08: 7ffdf69be690 R09: 0001
[ 31.108038] R10: 02b1 R11: 0206 R12: 0001
[ 31.109231] R13: R14: R15:
[ 31.110433] irq event stamp: 4466
[ 31.111001] hardirqs last enabled at (4465): []
__free_pages_ok+0x1e3/0x490
[ 31.112437] hardirqs last disabled at (4466): []
trace_hardirqs_off_thunk+0x1a/0x1c
[ 31.113973] softirqs last enabled at (3420): []
__do_softirq+0x333/0x446
[ 31.115364] softirqs last disabled at (3407): []
irq_exit+0xd1/0xe0
Cc: sta...@vger.kernel.org # 4.14+
Signed-off-by: Minchan Kim
---
drivers/block/zram/zram_drv.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 21a7046958a3..d1459cc1159f 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -387,8 +387,10 @@ static ssize_t backing_dev_store(struct device *dev,
bdev = bdgrab(I_BDEV(inode));
err = blkdev_get(bdev, FMODE_READ | FMODE_WRITE | FMODE_EXCL, zram);
- if (err < 0)
+ if (err < 0) {
+ bdev = NULL;
goto out;
+ }
nr_pages = i_size_read(inode) >> PAGE_SHIFT;
bitmap_sz = BITS_TO_LONGS(nr_pages) * sizeof(long);
--
2.20.0.rc0.387.gc7a69e6b6c-goog
[PATCH v3 4/7] zram: introduce ZRAM_IDLE flag
To support idle page writeback with upcoming patches, this patch
introduces a new ZRAM_IDLE flag.
Userspace can mark zram slots as "idle" via
"echo all > /sys/block/zramX/idle"
which marks every allocated zram slot as ZRAM_IDLE.
User could see it by /sys/kernel/debug/zram/zram0/block_state.
30075.033841 ...i
30163.806904 s..i
30263.806919 ..hi
Once there is IO for the slot, the mark will be disappeared.
30075.033841 ...
30163.806904 s..i
30263.806919 ..hi
Therefore, 300th block is idle zpage. With this feature,
user can how many zram has idle pages which are waste of memory.
Signed-off-by: Minchan Kim
---
Documentation/ABI/testing/sysfs-block-zram | 8 +++
Documentation/blockdev/zram.txt| 10 ++--
drivers/block/zram/zram_drv.c | 57 --
drivers/block/zram/zram_drv.h | 1 +
4 files changed, 69 insertions(+), 7 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-block-zram
b/Documentation/ABI/testing/sysfs-block-zram
index c1513c756af1..04c9a5980bc7 100644
--- a/Documentation/ABI/testing/sysfs-block-zram
+++ b/Documentation/ABI/testing/sysfs-block-zram
@@ -98,3 +98,11 @@ Contact: Minchan Kim
The backing_dev file is read-write and set up backing
device for zram to write incompressible pages.
For using, user should enable CONFIG_ZRAM_WRITEBACK.
+
+What: /sys/block/zram/idle
+Date: November 2018
+Contact: Minchan Kim
+Description:
+ idle file is write-only and mark zram slot as idle.
+ If system has mounted debugfs, user can see which slots
+ are idle via /sys/kernel/debug/zram/zram/block_state
diff --git a/Documentation/blockdev/zram.txt b/Documentation/blockdev/zram.txt
index 3c1b5ab54bc0..f3bcd716d8a9 100644
--- a/Documentation/blockdev/zram.txt
+++ b/Documentation/blockdev/zram.txt
@@ -169,6 +169,7 @@ comp_algorithmRWshow and change the compression
algorithm
compact WOtrigger memory compaction
debug_statROthis file is used for zram debugging purposes
backing_dev RWset up backend storage for zram to write out
+idle WOmark allocated slot as idle
User space is advised to use the following files to read the device statistics.
@@ -251,16 +252,17 @@ pages of the process with*pagemap.
If you enable the feature, you could see block state via
/sys/kernel/debug/zram/zram0/block_state". The output is as follows,
- 30075.033841 .wh
- 30163.806904 s..
- 30263.806919 ..h
+ 30075.033841 .wh.
+ 30163.806904 s...
+ 30263.806919 ..hi
First column is zram's block index.
Second column is access time since the system was booted
Third column is state of the block.
(s: same page
w: written page to backing store
-h: huge page)
+h: huge page
+i: idle page)
First line of above example says 300th block is accessed at 75.033841sec
and the block's state is huge so it is written back to the backing
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 4457d0395bfb..180613b478a6 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -281,6 +281,47 @@ static ssize_t mem_used_max_store(struct device *dev,
return len;
}
+static ssize_t idle_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t len)
+{
+ struct zram *zram = dev_to_zram(dev);
+ unsigned long nr_pages = zram->disksize >> PAGE_SHIFT;
+ int index;
+ char mode_buf[8];
+ ssize_t sz;
+
+ sz = strscpy(mode_buf, buf, sizeof(mode_buf));
+ if (sz <= 0)
+ return -EINVAL;
+
+ /* ignore trailing new line */
+ if (mode_buf[sz - 1] == '\n')
+ mode_buf[sz - 1] = 0x00;
+
+ if (strcmp(mode_buf, "all"))
+ return -EINVAL;
+
+ down_read(>init_lock);
+ if (!init_done(zram)) {
+ up_read(>init_lock);
+ return -EINVAL;
+ }
+
+ for (index = 0; index < nr_pages; index++) {
+ zram_slot_lock(zram, index);
+ if (!zram_allocated(zram, index))
+ goto next;
+
+ zram_set_flag(zram, index, ZRAM_IDLE);
+next:
+ zram_slot_unlock(zram, index);
+ }
+
+ up_read(>init_lock);
+
+ return len;
+}
+
#ifdef CONFIG_ZRAM_WRITEBACK
static void reset_bdev(struct zram *zram)
{
@@ -638,6 +679,7 @@ static void zram_debugfs_destroy(void)
static void zram_accessed(struct zram *zram, u32 index)
{
+ zram_clear_flag(zram, index, ZRAM_IDLE);
zram->table[index].ac_time = ktime_get_boottime();
}
@@ -670,12 +712,13 @@ static ssize_t read_block_state(struct file *file, char
__user *buf,
ts =
[PATCH v3 1/7] zram: fix lockdep warning of free block handling
[ 254.519728]
[ 254.520311] WARNING: inconsistent lock state
[ 254.520898] 4.19.0+ #390 Not tainted
[ 254.521387]
[ 254.521732] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[ 254.521732] zram_verify/2095 [HC0[0]:SC1[1]:HE1:SE0] takes:
[ 254.521732] b1828693 (&(>bitmap_lock)->rlock){+.?.}, at:
put_entry_bdev+0x1e/0x50
[ 254.521732] {SOFTIRQ-ON-W} state was registered at:
[ 254.521732] _raw_spin_lock+0x2c/0x40
[ 254.521732] zram_make_request+0x755/0xdc9
[ 254.521732] generic_make_request+0x373/0x6a0
[ 254.521732] submit_bio+0x6c/0x140
[ 254.521732] __swap_writepage+0x3a8/0x480
[ 254.521732] shrink_page_list+0x1102/0x1a60
[ 254.521732] shrink_inactive_list+0x21b/0x3f0
[ 254.521732] shrink_node_memcg.constprop.99+0x4f8/0x7e0
[ 254.521732] shrink_node+0x7d/0x2f0
[ 254.521732] do_try_to_free_pages+0xe0/0x300
[ 254.521732] try_to_free_pages+0x116/0x2b0
[ 254.521732] __alloc_pages_slowpath+0x3f4/0xf80
[ 254.521732] __alloc_pages_nodemask+0x2a2/0x2f0
[ 254.521732] __handle_mm_fault+0x42e/0xb50
[ 254.521732] handle_mm_fault+0x55/0xb0
[ 254.521732] __do_page_fault+0x235/0x4b0
[ 254.521732] page_fault+0x1e/0x30
[ 254.521732] irq event stamp: 228412
[ 254.521732] hardirqs last enabled at (228412): []
__slab_free+0x3e6/0x600
[ 254.521732] hardirqs last disabled at (228411): []
__slab_free+0x1c5/0x600
[ 254.521732] softirqs last enabled at (228396): []
__do_softirq+0x31e/0x427
[ 254.521732] softirqs last disabled at (228403): []
irq_exit+0xd1/0xe0
[ 254.521732]
[ 254.521732] other info that might help us debug this:
[ 254.521732] Possible unsafe locking scenario:
[ 254.521732]
[ 254.521732]CPU0
[ 254.521732]
[ 254.521732] lock(&(>bitmap_lock)->rlock);
[ 254.521732]
[ 254.521732] lock(&(>bitmap_lock)->rlock);
[ 254.521732]
[ 254.521732] *** DEADLOCK ***
[ 254.521732]
[ 254.521732] no locks held by zram_verify/2095.
[ 254.521732]
[ 254.521732] stack backtrace:
[ 254.521732] CPU: 5 PID: 2095 Comm: zram_verify Not tainted 4.19.0+ #390
[ 254.521732] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-1 04/01/2014
[ 254.521732] Call Trace:
[ 254.521732]
[ 254.521732] dump_stack+0x67/0x9b
[ 254.521732] print_usage_bug+0x1bd/0x1d3
[ 254.521732] mark_lock+0x4aa/0x540
[ 254.521732] ? check_usage_backwards+0x160/0x160
[ 254.521732] __lock_acquire+0x51d/0x1300
[ 254.521732] ? free_debug_processing+0x24e/0x400
[ 254.521732] ? bio_endio+0x6d/0x1a0
[ 254.521732] ? lockdep_hardirqs_on+0x9b/0x180
[ 254.521732] ? lock_acquire+0x90/0x180
[ 254.521732] lock_acquire+0x90/0x180
[ 254.521732] ? put_entry_bdev+0x1e/0x50
[ 254.521732] _raw_spin_lock+0x2c/0x40
[ 254.521732] ? put_entry_bdev+0x1e/0x50
[ 254.521732] put_entry_bdev+0x1e/0x50
[ 254.521732] zram_free_page+0xf6/0x110
[ 254.521732] zram_slot_free_notify+0x42/0xa0
[ 254.521732] end_swap_bio_read+0x5b/0x170
[ 254.521732] blk_update_request+0x8f/0x340
[ 254.521732] scsi_end_request+0x2c/0x1e0
[ 254.521732] scsi_io_completion+0x98/0x650
[ 254.521732] blk_done_softirq+0x9e/0xd0
[ 254.521732] __do_softirq+0xcc/0x427
[ 254.521732] irq_exit+0xd1/0xe0
[ 254.521732] do_IRQ+0x93/0x120
[ 254.521732] common_interrupt+0xf/0xf
[ 254.521732]
With writeback feature, zram_slot_free_notify could be called
in softirq context by end_swap_bio_read. However, bitmap_lock
is not aware of that so lockdep yell out. Thanks.
get_entry_bdev
spin_lock(bitmap->lock);
irq
softirq
end_swap_bio_read
zram_slot_free_notify
zram_slot_lock <-- deadlock prone
zram_free_page
put_entry_bdev
spin_lock(bitmap->lock); <-- deadlock prone
With akpm's suggestion(i.e. bitmap operation is already atomic),
we could remove bitmap lock. It might fail to find a empty slot
if serious contention happens. However, it's not severe problem
because huge page writeback has already possiblity to fail if there
is severe memory pressure. Worst case is just keeping
the incompressible in memory, not storage.
The other problem is zram_slot_lock in zram_slot_slot_free_notify.
To make it safe is this patch introduces zram_slot_trylock where
zram_slot_free_notify uses it. Although it's rare to be contented,
this patch adds new debug stat "miss_free" to keep monitoring
how often it happens.
Signed-off-by: Minchan Kim
---
drivers/block/zram/zram_drv.c | 38 +++
drivers/block/zram/zram_drv.h | 2 +-
2 files changed, 22 insertions(+), 18 deletions(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 4879595200e1..21a7046958a3 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -53,6 +53,11 @@ static size_t huge_class_size;
static void zram_free_page(struct zram *zram, size_t index);
+static int zram_slot_trylock(struct zram *zram, u32 index)
+{
+ return
[PATCH v3 2/7] zram: fix double free backing device
If blkdev_get fails, we shouldn't do blkdev_put. Otherwise,
kernel emits below log. This patch fixes it.
[ 31.073006] WARNING: CPU: 0 PID: 1893 at fs/block_dev.c:1828
blkdev_put+0x105/0x120
[ 31.075104] Modules linked in:
[ 31.075898] CPU: 0 PID: 1893 Comm: swapoff Not tainted 4.19.0+ #453
[ 31.077484] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-1 04/01/2014
[ 31.079589] RIP: 0010:blkdev_put+0x105/0x120
[ 31.080606] Code: 48 c7 80 a0 00 00 00 00 00 00 00 48 c7 c7 40 e7 40 96 e8
6e 47 73 00 48 8b bb e0 00 00 00 e9 2c ff ff ff 0f 0b e9 75 ff ff ff <0f> 0b e9
5a ff ff ff 48 c7 80 a0 00 00 00 00 00 00 00 eb 87 0f 1f
[ 31.085080] RSP: 0018:b409005c7ed0 EFLAGS: 00010297
[ 31.086383] RAX: 9779fe5a8040 RBX: 9779fbc17300 RCX: b9fc37a4
[ 31.088105] RDX: 0001 RSI: RDI: 9640e740
[ 31.089850] RBP: 9779fbc17318 R08: 95499a89 R09: 0004
[ 31.091201] R10: b409005c7e50 R11: 7a9ef6088ff4d4a1 R12: 0083
[ 31.092276] R13: 9779fe607b98 R14: R15: 9779fe607a38
[ 31.093355] FS: 7fc118d9b840() GS:9779fc60()
knlGS:
[ 31.094582] CS: 0010 DS: ES: CR0: 80050033
[ 31.095541] CR2: 7fc11894b8dc CR3: 339f6001 CR4: 00160ef0
[ 31.096781] Call Trace:
[ 31.097212] __x64_sys_swapoff+0x46d/0x490
[ 31.097914] do_syscall_64+0x5a/0x190
[ 31.098550] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 31.099402] RIP: 0033:0x7fc11843ec27
[ 31.100013] Code: 73 01 c3 48 8b 0d 71 62 2c 00 f7 d8 64 89 01 48 83 c8 ff
c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 a8 00 00 00 0f 05 <48> 3d 01
f0 ff ff 73 01 c3 48 8b 0d 41 62 2c 00 f7 d8 64 89 01 48
[ 31.103149] RSP: 002b:7ffdf69be648 EFLAGS: 0206 ORIG_RAX:
00a8
[ 31.104425] RAX: ffda RBX: 011d98c0 RCX: 7fc11843ec27
[ 31.105627] RDX: 0001 RSI: 0001 RDI: 011d98c0
[ 31.106847] RBP: 0001 R08: 7ffdf69be690 R09: 0001
[ 31.108038] R10: 02b1 R11: 0206 R12: 0001
[ 31.109231] R13: R14: R15:
[ 31.110433] irq event stamp: 4466
[ 31.111001] hardirqs last enabled at (4465): []
__free_pages_ok+0x1e3/0x490
[ 31.112437] hardirqs last disabled at (4466): []
trace_hardirqs_off_thunk+0x1a/0x1c
[ 31.113973] softirqs last enabled at (3420): []
__do_softirq+0x333/0x446
[ 31.115364] softirqs last disabled at (3407): []
irq_exit+0xd1/0xe0
Cc: sta...@vger.kernel.org # 4.14+
Signed-off-by: Minchan Kim
---
drivers/block/zram/zram_drv.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 21a7046958a3..d1459cc1159f 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -387,8 +387,10 @@ static ssize_t backing_dev_store(struct device *dev,
bdev = bdgrab(I_BDEV(inode));
err = blkdev_get(bdev, FMODE_READ | FMODE_WRITE | FMODE_EXCL, zram);
- if (err < 0)
+ if (err < 0) {
+ bdev = NULL;
goto out;
+ }
nr_pages = i_size_read(inode) >> PAGE_SHIFT;
bitmap_sz = BITS_TO_LONGS(nr_pages) * sizeof(long);
--
2.20.0.rc0.387.gc7a69e6b6c-goog
[PATCH v3 4/7] zram: introduce ZRAM_IDLE flag
To support idle page writeback with upcoming patches, this patch
introduces a new ZRAM_IDLE flag.
Userspace can mark zram slots as "idle" via
"echo all > /sys/block/zramX/idle"
which marks every allocated zram slot as ZRAM_IDLE.
User could see it by /sys/kernel/debug/zram/zram0/block_state.
30075.033841 ...i
30163.806904 s..i
30263.806919 ..hi
Once there is IO for the slot, the mark will be disappeared.
30075.033841 ...
30163.806904 s..i
30263.806919 ..hi
Therefore, 300th block is idle zpage. With this feature,
user can how many zram has idle pages which are waste of memory.
Signed-off-by: Minchan Kim
---
Documentation/ABI/testing/sysfs-block-zram | 8 +++
Documentation/blockdev/zram.txt| 10 ++--
drivers/block/zram/zram_drv.c | 57 --
drivers/block/zram/zram_drv.h | 1 +
4 files changed, 69 insertions(+), 7 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-block-zram
b/Documentation/ABI/testing/sysfs-block-zram
index c1513c756af1..04c9a5980bc7 100644
--- a/Documentation/ABI/testing/sysfs-block-zram
+++ b/Documentation/ABI/testing/sysfs-block-zram
@@ -98,3 +98,11 @@ Contact: Minchan Kim
The backing_dev file is read-write and set up backing
device for zram to write incompressible pages.
For using, user should enable CONFIG_ZRAM_WRITEBACK.
+
+What: /sys/block/zram/idle
+Date: November 2018
+Contact: Minchan Kim
+Description:
+ idle file is write-only and mark zram slot as idle.
+ If system has mounted debugfs, user can see which slots
+ are idle via /sys/kernel/debug/zram/zram/block_state
diff --git a/Documentation/blockdev/zram.txt b/Documentation/blockdev/zram.txt
index 3c1b5ab54bc0..f3bcd716d8a9 100644
--- a/Documentation/blockdev/zram.txt
+++ b/Documentation/blockdev/zram.txt
@@ -169,6 +169,7 @@ comp_algorithmRWshow and change the compression
algorithm
compact WOtrigger memory compaction
debug_statROthis file is used for zram debugging purposes
backing_dev RWset up backend storage for zram to write out
+idle WOmark allocated slot as idle
User space is advised to use the following files to read the device statistics.
@@ -251,16 +252,17 @@ pages of the process with*pagemap.
If you enable the feature, you could see block state via
/sys/kernel/debug/zram/zram0/block_state". The output is as follows,
- 30075.033841 .wh
- 30163.806904 s..
- 30263.806919 ..h
+ 30075.033841 .wh.
+ 30163.806904 s...
+ 30263.806919 ..hi
First column is zram's block index.
Second column is access time since the system was booted
Third column is state of the block.
(s: same page
w: written page to backing store
-h: huge page)
+h: huge page
+i: idle page)
First line of above example says 300th block is accessed at 75.033841sec
and the block's state is huge so it is written back to the backing
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 4457d0395bfb..180613b478a6 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -281,6 +281,47 @@ static ssize_t mem_used_max_store(struct device *dev,
return len;
}
+static ssize_t idle_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t len)
+{
+ struct zram *zram = dev_to_zram(dev);
+ unsigned long nr_pages = zram->disksize >> PAGE_SHIFT;
+ int index;
+ char mode_buf[8];
+ ssize_t sz;
+
+ sz = strscpy(mode_buf, buf, sizeof(mode_buf));
+ if (sz <= 0)
+ return -EINVAL;
+
+ /* ignore trailing new line */
+ if (mode_buf[sz - 1] == '\n')
+ mode_buf[sz - 1] = 0x00;
+
+ if (strcmp(mode_buf, "all"))
+ return -EINVAL;
+
+ down_read(>init_lock);
+ if (!init_done(zram)) {
+ up_read(>init_lock);
+ return -EINVAL;
+ }
+
+ for (index = 0; index < nr_pages; index++) {
+ zram_slot_lock(zram, index);
+ if (!zram_allocated(zram, index))
+ goto next;
+
+ zram_set_flag(zram, index, ZRAM_IDLE);
+next:
+ zram_slot_unlock(zram, index);
+ }
+
+ up_read(>init_lock);
+
+ return len;
+}
+
#ifdef CONFIG_ZRAM_WRITEBACK
static void reset_bdev(struct zram *zram)
{
@@ -638,6 +679,7 @@ static void zram_debugfs_destroy(void)
static void zram_accessed(struct zram *zram, u32 index)
{
+ zram_clear_flag(zram, index, ZRAM_IDLE);
zram->table[index].ac_time = ktime_get_boottime();
}
@@ -670,12 +712,13 @@ static ssize_t read_block_state(struct file *file, char
__user *buf,
ts =
[PATCH v3 1/7] zram: fix lockdep warning of free block handling
[ 254.519728]
[ 254.520311] WARNING: inconsistent lock state
[ 254.520898] 4.19.0+ #390 Not tainted
[ 254.521387]
[ 254.521732] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[ 254.521732] zram_verify/2095 [HC0[0]:SC1[1]:HE1:SE0] takes:
[ 254.521732] b1828693 (&(>bitmap_lock)->rlock){+.?.}, at:
put_entry_bdev+0x1e/0x50
[ 254.521732] {SOFTIRQ-ON-W} state was registered at:
[ 254.521732] _raw_spin_lock+0x2c/0x40
[ 254.521732] zram_make_request+0x755/0xdc9
[ 254.521732] generic_make_request+0x373/0x6a0
[ 254.521732] submit_bio+0x6c/0x140
[ 254.521732] __swap_writepage+0x3a8/0x480
[ 254.521732] shrink_page_list+0x1102/0x1a60
[ 254.521732] shrink_inactive_list+0x21b/0x3f0
[ 254.521732] shrink_node_memcg.constprop.99+0x4f8/0x7e0
[ 254.521732] shrink_node+0x7d/0x2f0
[ 254.521732] do_try_to_free_pages+0xe0/0x300
[ 254.521732] try_to_free_pages+0x116/0x2b0
[ 254.521732] __alloc_pages_slowpath+0x3f4/0xf80
[ 254.521732] __alloc_pages_nodemask+0x2a2/0x2f0
[ 254.521732] __handle_mm_fault+0x42e/0xb50
[ 254.521732] handle_mm_fault+0x55/0xb0
[ 254.521732] __do_page_fault+0x235/0x4b0
[ 254.521732] page_fault+0x1e/0x30
[ 254.521732] irq event stamp: 228412
[ 254.521732] hardirqs last enabled at (228412): []
__slab_free+0x3e6/0x600
[ 254.521732] hardirqs last disabled at (228411): []
__slab_free+0x1c5/0x600
[ 254.521732] softirqs last enabled at (228396): []
__do_softirq+0x31e/0x427
[ 254.521732] softirqs last disabled at (228403): []
irq_exit+0xd1/0xe0
[ 254.521732]
[ 254.521732] other info that might help us debug this:
[ 254.521732] Possible unsafe locking scenario:
[ 254.521732]
[ 254.521732]CPU0
[ 254.521732]
[ 254.521732] lock(&(>bitmap_lock)->rlock);
[ 254.521732]
[ 254.521732] lock(&(>bitmap_lock)->rlock);
[ 254.521732]
[ 254.521732] *** DEADLOCK ***
[ 254.521732]
[ 254.521732] no locks held by zram_verify/2095.
[ 254.521732]
[ 254.521732] stack backtrace:
[ 254.521732] CPU: 5 PID: 2095 Comm: zram_verify Not tainted 4.19.0+ #390
[ 254.521732] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-1 04/01/2014
[ 254.521732] Call Trace:
[ 254.521732]
[ 254.521732] dump_stack+0x67/0x9b
[ 254.521732] print_usage_bug+0x1bd/0x1d3
[ 254.521732] mark_lock+0x4aa/0x540
[ 254.521732] ? check_usage_backwards+0x160/0x160
[ 254.521732] __lock_acquire+0x51d/0x1300
[ 254.521732] ? free_debug_processing+0x24e/0x400
[ 254.521732] ? bio_endio+0x6d/0x1a0
[ 254.521732] ? lockdep_hardirqs_on+0x9b/0x180
[ 254.521732] ? lock_acquire+0x90/0x180
[ 254.521732] lock_acquire+0x90/0x180
[ 254.521732] ? put_entry_bdev+0x1e/0x50
[ 254.521732] _raw_spin_lock+0x2c/0x40
[ 254.521732] ? put_entry_bdev+0x1e/0x50
[ 254.521732] put_entry_bdev+0x1e/0x50
[ 254.521732] zram_free_page+0xf6/0x110
[ 254.521732] zram_slot_free_notify+0x42/0xa0
[ 254.521732] end_swap_bio_read+0x5b/0x170
[ 254.521732] blk_update_request+0x8f/0x340
[ 254.521732] scsi_end_request+0x2c/0x1e0
[ 254.521732] scsi_io_completion+0x98/0x650
[ 254.521732] blk_done_softirq+0x9e/0xd0
[ 254.521732] __do_softirq+0xcc/0x427
[ 254.521732] irq_exit+0xd1/0xe0
[ 254.521732] do_IRQ+0x93/0x120
[ 254.521732] common_interrupt+0xf/0xf
[ 254.521732]
With writeback feature, zram_slot_free_notify could be called
in softirq context by end_swap_bio_read. However, bitmap_lock
is not aware of that so lockdep yell out. Thanks.
get_entry_bdev
spin_lock(bitmap->lock);
irq
softirq
end_swap_bio_read
zram_slot_free_notify
zram_slot_lock <-- deadlock prone
zram_free_page
put_entry_bdev
spin_lock(bitmap->lock); <-- deadlock prone
With akpm's suggestion(i.e. bitmap operation is already atomic),
we could remove bitmap lock. It might fail to find a empty slot
if serious contention happens. However, it's not severe problem
because huge page writeback has already possiblity to fail if there
is severe memory pressure. Worst case is just keeping
the incompressible in memory, not storage.
The other problem is zram_slot_lock in zram_slot_slot_free_notify.
To make it safe is this patch introduces zram_slot_trylock where
zram_slot_free_notify uses it. Although it's rare to be contented,
this patch adds new debug stat "miss_free" to keep monitoring
how often it happens.
Signed-off-by: Minchan Kim
---
drivers/block/zram/zram_drv.c | 38 +++
drivers/block/zram/zram_drv.h | 2 +-
2 files changed, 22 insertions(+), 18 deletions(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 4879595200e1..21a7046958a3 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -53,6 +53,11 @@ static size_t huge_class_size;
static void zram_free_page(struct zram *zram, size_t index);
+static int zram_slot_trylock(struct zram *zram, u32 index)
+{
+ return
[PATCH v3 3/7] zram: refactoring flags and writeback stuff
This patch does renaming some variables and restructuring
some codes for better redability in writeback and zs_free_page.
Signed-off-by: Minchan Kim
---
drivers/block/zram/zram_drv.c | 105 +-
drivers/block/zram/zram_drv.h | 8 +--
2 files changed, 44 insertions(+), 69 deletions(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index d1459cc1159f..4457d0395bfb 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -55,17 +55,17 @@ static void zram_free_page(struct zram *zram, size_t index);
static int zram_slot_trylock(struct zram *zram, u32 index)
{
- return bit_spin_trylock(ZRAM_LOCK, >table[index].value);
+ return bit_spin_trylock(ZRAM_LOCK, >table[index].flags);
}
static void zram_slot_lock(struct zram *zram, u32 index)
{
- bit_spin_lock(ZRAM_LOCK, >table[index].value);
+ bit_spin_lock(ZRAM_LOCK, >table[index].flags);
}
static void zram_slot_unlock(struct zram *zram, u32 index)
{
- bit_spin_unlock(ZRAM_LOCK, >table[index].value);
+ bit_spin_unlock(ZRAM_LOCK, >table[index].flags);
}
static inline bool init_done(struct zram *zram)
@@ -76,7 +76,7 @@ static inline bool init_done(struct zram *zram)
static inline bool zram_allocated(struct zram *zram, u32 index)
{
- return (zram->table[index].value >> (ZRAM_FLAG_SHIFT + 1)) ||
+ return (zram->table[index].flags >> (ZRAM_FLAG_SHIFT + 1)) ||
zram->table[index].handle;
}
@@ -99,19 +99,19 @@ static void zram_set_handle(struct zram *zram, u32 index,
unsigned long handle)
static bool zram_test_flag(struct zram *zram, u32 index,
enum zram_pageflags flag)
{
- return zram->table[index].value & BIT(flag);
+ return zram->table[index].flags & BIT(flag);
}
static void zram_set_flag(struct zram *zram, u32 index,
enum zram_pageflags flag)
{
- zram->table[index].value |= BIT(flag);
+ zram->table[index].flags |= BIT(flag);
}
static void zram_clear_flag(struct zram *zram, u32 index,
enum zram_pageflags flag)
{
- zram->table[index].value &= ~BIT(flag);
+ zram->table[index].flags &= ~BIT(flag);
}
static inline void zram_set_element(struct zram *zram, u32 index,
@@ -127,15 +127,15 @@ static unsigned long zram_get_element(struct zram *zram,
u32 index)
static size_t zram_get_obj_size(struct zram *zram, u32 index)
{
- return zram->table[index].value & (BIT(ZRAM_FLAG_SHIFT) - 1);
+ return zram->table[index].flags & (BIT(ZRAM_FLAG_SHIFT) - 1);
}
static void zram_set_obj_size(struct zram *zram,
u32 index, size_t size)
{
- unsigned long flags = zram->table[index].value >> ZRAM_FLAG_SHIFT;
+ unsigned long flags = zram->table[index].flags >> ZRAM_FLAG_SHIFT;
- zram->table[index].value = (flags << ZRAM_FLAG_SHIFT) | size;
+ zram->table[index].flags = (flags << ZRAM_FLAG_SHIFT) | size;
}
#if PAGE_SIZE != 4096
@@ -282,16 +282,11 @@ static ssize_t mem_used_max_store(struct device *dev,
}
#ifdef CONFIG_ZRAM_WRITEBACK
-static bool zram_wb_enabled(struct zram *zram)
-{
- return zram->backing_dev;
-}
-
static void reset_bdev(struct zram *zram)
{
struct block_device *bdev;
- if (!zram_wb_enabled(zram))
+ if (!zram->backing_dev)
return;
bdev = zram->bdev;
@@ -318,7 +313,7 @@ static ssize_t backing_dev_show(struct device *dev,
ssize_t ret;
down_read(>init_lock);
- if (!zram_wb_enabled(zram)) {
+ if (!zram->backing_dev) {
memcpy(buf, "none\n", 5);
up_read(>init_lock);
return 5;
@@ -447,7 +442,7 @@ static ssize_t backing_dev_store(struct device *dev,
return err;
}
-static unsigned long get_entry_bdev(struct zram *zram)
+static unsigned long alloc_block_bdev(struct zram *zram)
{
unsigned long blk_idx = 1;
retry:
@@ -462,11 +457,11 @@ static unsigned long get_entry_bdev(struct zram *zram)
return blk_idx;
}
-static void put_entry_bdev(struct zram *zram, unsigned long entry)
+static void free_block_bdev(struct zram *zram, unsigned long blk_idx)
{
int was_set;
- was_set = test_and_clear_bit(entry, zram->bitmap);
+ was_set = test_and_clear_bit(blk_idx, zram->bitmap);
WARN_ON_ONCE(!was_set);
}
@@ -579,7 +574,7 @@ static int write_to_bdev(struct zram *zram, struct bio_vec
*bvec,
if (!bio)
return -ENOMEM;
- entry = get_entry_bdev(zram);
+ entry = alloc_block_bdev(zram);
if (!entry) {
bio_put(bio);
return -ENOSPC;
@@ -590,7 +585,7 @@ static int write_to_bdev(struct zram *zram, struct bio_vec
*bvec,
if (!bio_add_page(bio, bvec->bv_page, bvec->bv_len,
bvec->bv_offset)) {
[PATCH v3 6/7] zram: add bd_stat statistics
bd_stat represents things happened in backing device. Currently,
it supports bd_counts, bd_reads and bd_writes which are helpful
to understand wearout of flash and memory saving.
Signed-off-by: Minchan Kim
---
Documentation/ABI/testing/sysfs-block-zram | 8 ++
Documentation/blockdev/zram.txt| 11
drivers/block/zram/zram_drv.c | 29 ++
drivers/block/zram/zram_drv.h | 5
4 files changed, 53 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-block-zram
b/Documentation/ABI/testing/sysfs-block-zram
index d1f80b077885..65fc33b2f53b 100644
--- a/Documentation/ABI/testing/sysfs-block-zram
+++ b/Documentation/ABI/testing/sysfs-block-zram
@@ -113,3 +113,11 @@ Contact: Minchan Kim
Description:
The writeback file is write-only and trigger idle and/or
huge page writeback to backing device.
+
+What: /sys/block/zram/bd_stat
+Date: November 2018
+Contact: Minchan Kim
+Description:
+ The bd_stat file is read-only and represents backing device's
+ statistics (bd_count, bd_reads, bd_writes) in a format
+ similar to block layer statistics file format.
diff --git a/Documentation/blockdev/zram.txt b/Documentation/blockdev/zram.txt
index 806cdaabac83..906df97527a7 100644
--- a/Documentation/blockdev/zram.txt
+++ b/Documentation/blockdev/zram.txt
@@ -221,6 +221,17 @@ The stat file represents device's mm statistics. It
consists of a single
pages_compacted the number of pages freed during compaction
huge_pages the number of incompressible pages
+File /sys/block/zram/bd_stat
+
+The stat file represents device's backing device statistics. It consists of
+a single line of text and contains the following stats separated by whitespace:
+ bd_count size of data written in backing device.
+ Unit: 4K bytes
+ bd_reads the number of reads from backing device
+ Unit: 4K bytes
+ bd_writes the number of writes to backing device
+ Unit: 4K bytes
+
9) Deactivate:
swapoff /dev/zram0
umount /dev/zram1
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 6b5a886c8f32..67168a6ecca6 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -502,6 +502,7 @@ static unsigned long alloc_block_bdev(struct zram *zram)
if (test_and_set_bit(blk_idx, zram->bitmap))
goto retry;
+ atomic64_inc(>stats.bd_count);
return blk_idx;
}
@@ -511,6 +512,7 @@ static void free_block_bdev(struct zram *zram, unsigned
long blk_idx)
was_set = test_and_clear_bit(blk_idx, zram->bitmap);
WARN_ON_ONCE(!was_set);
+ atomic64_dec(>stats.bd_count);
}
static void zram_page_end_io(struct bio *bio)
@@ -668,6 +670,7 @@ static ssize_t writeback_store(struct device *dev,
continue;
}
+ atomic64_inc(>stats.bd_writes);
/*
* We released zram_slot_lock so need to check if the slot was
* changed. If there is freeing for the slot, we can catch it
@@ -757,6 +760,7 @@ static int read_from_bdev_sync(struct zram *zram, struct
bio_vec *bvec,
static int read_from_bdev(struct zram *zram, struct bio_vec *bvec,
unsigned long entry, struct bio *parent, bool sync)
{
+ atomic64_inc(>stats.bd_reads);
if (sync)
return read_from_bdev_sync(zram, bvec, entry, parent);
else
@@ -1013,6 +1017,25 @@ static ssize_t mm_stat_show(struct device *dev,
return ret;
}
+#ifdef CONFIG_ZRAM_WRITEBACK
+static ssize_t bd_stat_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct zram *zram = dev_to_zram(dev);
+ ssize_t ret;
+
+ down_read(>init_lock);
+ ret = scnprintf(buf, PAGE_SIZE,
+ "%8llu %8llu %8llu\n",
+ (u64)atomic64_read(>stats.bd_count),
+ (u64)atomic64_read(>stats.bd_reads),
+ (u64)atomic64_read(>stats.bd_writes));
+ up_read(>init_lock);
+
+ return ret;
+}
+#endif
+
static ssize_t debug_stat_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -1033,6 +1056,9 @@ static ssize_t debug_stat_show(struct device *dev,
static DEVICE_ATTR_RO(io_stat);
static DEVICE_ATTR_RO(mm_stat);
+#ifdef CONFIG_ZRAM_WRITEBACK
+static DEVICE_ATTR_RO(bd_stat);
+#endif
static DEVICE_ATTR_RO(debug_stat);
static void zram_meta_free(struct zram *zram, u64 disksize)
@@ -1759,6 +1785,9 @@ static struct attribute *zram_disk_attrs[] = {
#endif
_attr_io_stat.attr,
_attr_mm_stat.attr,
+#ifdef CONFIG_ZRAM_WRITEBACK
+ _attr_bd_stat.attr,
+#endif
_attr_debug_stat.attr,
NULL,
};
diff --git a/drivers/block/zram/zram_drv.h
[PATCH v3 5/7] zram: support idle/huge page writeback
This patch supports new feature "zram idle/huge page writeback".
On zram-swap usecase, zram has usually many idle/huge swap pages.
It's pointless to keep in memory(ie, zram).
To solve the problem, this feature introduces idle/huge page
writeback to backing device so the goal is to save more memory
space on embedded system.
Normal sequence to use idle/huge page writeback feature is as follows,
while (1) {
# mark allocated zram slot to idle
echo all > /sys/block/zram0/idle
# leave system working for several hours
# Unless there is no access for some blocks on zram,
# they are still IDLE marked pages.
echo "idle" > /sys/block/zram0/writeback
or/and
echo "huge" > /sys/block/zram0/writeback
# write the IDLE or/and huge marked slot into backing device
# and free the memory.
}
By per discussion:
https://lore.kernel.org/lkml/20181122065926.GG3441@jagdpanzerIV/T/#u,
This patch removes direct incommpressibe page writeback feature
(d2afd25114f4, zram: write incompressible pages to backing device)
so we could regard it as regression because incompressible pages
doesn't go to backing storage automatically. Instead, usre should
do it via "echo huge" > /sys/block/zram/writeback" manually.
If we hear some regression, we could restore the function.
Reviewed-by: Joey Pabalinas
Signed-off-by: Minchan Kim
---
Documentation/ABI/testing/sysfs-block-zram | 7 +
Documentation/blockdev/zram.txt| 28 ++-
drivers/block/zram/Kconfig | 5 +-
drivers/block/zram/zram_drv.c | 247 +++--
drivers/block/zram/zram_drv.h | 1 +
5 files changed, 209 insertions(+), 79 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-block-zram
b/Documentation/ABI/testing/sysfs-block-zram
index 04c9a5980bc7..d1f80b077885 100644
--- a/Documentation/ABI/testing/sysfs-block-zram
+++ b/Documentation/ABI/testing/sysfs-block-zram
@@ -106,3 +106,10 @@ Contact: Minchan Kim
idle file is write-only and mark zram slot as idle.
If system has mounted debugfs, user can see which slots
are idle via /sys/kernel/debug/zram/zram/block_state
+
+What: /sys/block/zram/writeback
+Date: November 2018
+Contact: Minchan Kim
+Description:
+ The writeback file is write-only and trigger idle and/or
+ huge page writeback to backing device.
diff --git a/Documentation/blockdev/zram.txt b/Documentation/blockdev/zram.txt
index f3bcd716d8a9..806cdaabac83 100644
--- a/Documentation/blockdev/zram.txt
+++ b/Documentation/blockdev/zram.txt
@@ -238,11 +238,31 @@ The stat file represents device's mm statistics. It
consists of a single
= writeback
-With incompressible pages, there is no memory saving with zram.
-Instead, with CONFIG_ZRAM_WRITEBACK, zram can write incompressible page
+With CONFIG_ZRAM_WRITEBACK, zram can write idle/incompressible page
to backing storage rather than keeping it in memory.
-User should set up backing device via /sys/block/zramX/backing_dev
-before disksize setting.
+To use the feature, admin should set up backing device via
+
+ "echo /dev/sda5 > /sys/block/zramX/backing_dev"
+
+before disksize setting. It supports only partition at this moment.
+If admin want to use incompressible page writeback, they could do via
+
+ "echo huge > /sys/block/zramX/write"
+
+To use idle page writeback, first, user need to declare zram pages
+as idle.
+
+ "echo all > /sys/block/zramX/idle"
+
+From now on, any pages on zram are idle pages. The idle mark
+will be removed until someone request access of the block.
+IOW, unless there is access request, those pages are still idle pages.
+
+Admin can request writeback of those idle pages at right timing via
+
+ "echo idle > /sys/block/zramX/writeback"
+
+With the command, zram writeback idle pages from memory to the storage.
= memory tracking
diff --git a/drivers/block/zram/Kconfig b/drivers/block/zram/Kconfig
index fcd055457364..1ffc64770643 100644
--- a/drivers/block/zram/Kconfig
+++ b/drivers/block/zram/Kconfig
@@ -15,7 +15,7 @@ config ZRAM
See Documentation/blockdev/zram.txt for more information.
config ZRAM_WRITEBACK
- bool "Write back incompressible page to backing device"
+ bool "Write back incompressible or idle page to backing device"
depends on ZRAM
help
With incompressible page, there is no memory saving to keep it
@@ -23,6 +23,9 @@ config ZRAM_WRITEBACK
For this feature, admin should set up backing device via
/sys/block/zramX/backing_dev.
+With /sys/block/zramX/{idle,writeback}, application could ask
+idle page's writeback to the backing device to save in memory.
+
See Documentation/blockdev/zram.txt for more information.
config ZRAM_MEMORY_TRACKING
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
[PATCH v3 0/7] zram idle page writeback
Inherently, swap device has many idle pages which are rare touched since it was allocated. It is never problem if we use storage device as swap. However, it's just waste for zram-swap. This patchset supports zram idle page writeback feature. * Admin can define what is idle page "no access since X time ago" * Admin can define when zram should writeback them * Admin can define when zram should stop writeback to prevent wearout Detail is on each patch's description. Below first two patches are -stable material so it could go first separately with others in this series. zram: fix lockdep warning of free block handling zram: fix double free backing device * from v2 - use strscpy instead of strlcpy - Joey Pabalinas - remove irqlock for bitmap op - akpm - don't use page as stat unit - akpm * from v1 - add fix dobule free backing device - minchan - change writeback/idle interface - minchan - remove direct incompressible page writeback - sergey Minchan Kim (7): zram: fix lockdep warning of free block handling zram: fix double free backing device zram: refactoring flags and writeback stuff zram: introduce ZRAM_IDLE flag zram: support idle/huge page writeback zram: add bd_stat statistics zram: writeback throttle Documentation/ABI/testing/sysfs-block-zram | 32 ++ Documentation/blockdev/zram.txt| 51 ++- drivers/block/zram/Kconfig | 5 +- drivers/block/zram/zram_drv.c | 501 +++-- drivers/block/zram/zram_drv.h | 19 +- 5 files changed, 446 insertions(+), 162 deletions(-) -- 2.20.0.rc0.387.gc7a69e6b6c-goog
[PATCH v3 0/7] zram idle page writeback
Inherently, swap device has many idle pages which are rare touched since it was allocated. It is never problem if we use storage device as swap. However, it's just waste for zram-swap. This patchset supports zram idle page writeback feature. * Admin can define what is idle page "no access since X time ago" * Admin can define when zram should writeback them * Admin can define when zram should stop writeback to prevent wearout Detail is on each patch's description. Below first two patches are -stable material so it could go first separately with others in this series. zram: fix lockdep warning of free block handling zram: fix double free backing device * from v2 - use strscpy instead of strlcpy - Joey Pabalinas - remove irqlock for bitmap op - akpm - don't use page as stat unit - akpm * from v1 - add fix dobule free backing device - minchan - change writeback/idle interface - minchan - remove direct incompressible page writeback - sergey Minchan Kim (7): zram: fix lockdep warning of free block handling zram: fix double free backing device zram: refactoring flags and writeback stuff zram: introduce ZRAM_IDLE flag zram: support idle/huge page writeback zram: add bd_stat statistics zram: writeback throttle Documentation/ABI/testing/sysfs-block-zram | 32 ++ Documentation/blockdev/zram.txt| 51 ++- drivers/block/zram/Kconfig | 5 +- drivers/block/zram/zram_drv.c | 501 +++-- drivers/block/zram/zram_drv.h | 19 +- 5 files changed, 446 insertions(+), 162 deletions(-) -- 2.20.0.rc0.387.gc7a69e6b6c-goog
Re: [snd_hda_intel] snd_hda_intel causes high CPU lockup and system instability if mic disabled in BIOS on Lenovo P50
On Mon, 26 Nov 2018, Takashi Iwai wrote: On Mon, 26 Nov 2018 00:17:15 +0100, Alexander Kappner wrote: My Lenovo P50 laptop has a BIOS option to disable the microphone. When this option gets chosen, the snd_hda_intel driver causes high CPU load on a single kworker thread, spinning on "process_unsol_events", and system instability. This behavior occurs from the time that the snd_hda_intel module is loaded, irrespective of whether anything is attempting to access the mic. The sound output still works. When in this state, the module cannot be removed cleanly; attempting to remove it (even without rmmod -f) triggers an oops. I have attached two exemplary dmesg outputs. Strangely enough, the exact location of the oops varies, but further up the call chain, I always see process_unsol_events. When the mic is not disabled in the BIOS, the module works stable, regardless whether or not the mic is muted in ALSA. I wasn't able to pinpoint the root cause. Any pointers on where to start? Much appreciated. Could you load snd-hda-intel driver with probe_only=1 option, and give alsa-info.sh output (run it with --no-upload option)? This should leave only the codec probing without configuring, so we can see the codec widget contents and check the emulator. thanks, Takashi Hi Takashi, thank you for looking into this. Please see quoted below the output of alsa-info.sh (after "modprobe snd_hda_intel probe_only=1"). Best regards upload=true=true= !! !!ALSA Information Script v 0.4.64 !! !!Script ran on: Tue Nov 27 05:25:14 UTC 2018 !!Linux Distribution !!-- Debian GNU/Linux 8 \n \l PRETTY_NAME="Debian GNU/Linux 8 (jessie)" NAME="Debian GNU/Linux" ID=debian HOME_URL="http://www.debian.org/; SUPPORT_URL="http://www.debian.org/support; BUG_REPORT_URL="https://bugs.debian.org/; !!DMI Information !!--- Manufacturer: LENOVO Product Name: 20ENCTO1WW Product Version: ThinkPad P50 Firmware Version: N1EET62W (1.35 ) Board Vendor: LENOVO Board Name:20ENCTO1WW !!ACPI Device Status Information !!--- /sys/bus/acpi/devices/ACPI0003:00/status 15 /sys/bus/acpi/devices/LEN0068:00/status 15 /sys/bus/acpi/devices/LNXPOWER:00/status 1 /sys/bus/acpi/devices/LNXPOWER:01/status 1 /sys/bus/acpi/devices/LNXPOWER:02/status 1 /sys/bus/acpi/devices/LNXPOWER:03/status 1 /sys/bus/acpi/devices/LNXVIDEO:00/status 15 /sys/bus/acpi/devices/PNP0103:00/status 15 /sys/bus/acpi/devices/PNP0C0A:00/status 31 /sys/bus/acpi/devices/PNP0C0F:00/status 9 /sys/bus/acpi/devices/PNP0C0F:01/status 9 /sys/bus/acpi/devices/PNP0C0F:02/status 9 /sys/bus/acpi/devices/PNP0C0F:03/status 9 /sys/bus/acpi/devices/PNP0C0F:04/status 9 /sys/bus/acpi/devices/PNP0C0F:05/status 9 /sys/bus/acpi/devices/PNP0C0F:06/status 9 /sys/bus/acpi/devices/PNP0C0F:07/status 9 /sys/bus/acpi/devices/device:3e/status 15 !!Kernel Information !!-- Kernel release:4.19.0-rc4 Operating System: GNU/Linux Architecture: x86_64 Processor: unknown SMP Enabled: Yes !!ALSA Version !! Driver version: k4.19.0-rc4 Library version:1.0.28 Utilities version: 1.0.28 !!Loaded ALSA modules !!--- !!Sound Servers on this system !! Pulseaudio: Installed - Yes (/usr/bin/pulseaudio) Running - No !!Soundcards recognised by ALSA !!- 0 [PCH]: HDA-Intel - HDA Intel PCH HDA Intel PCH at 0xc494 irq 151 1 [NVidia ]: HDA-Intel - HDA NVidia HDA NVidia at 0xc300 irq 17 !!PCI Soundcards installed in the system !!-- 00:1f.3 Audio device: Intel Corporation Device a170 (rev 31) 01:00.1 Audio device: NVIDIA Corporation Device 0fbc (rev a1) !!Advanced information - PCI Vendor/Device/Subsystem ID's !!--- 00:1f.3 0403: 8086:a170 (rev 31) Subsystem: 17aa:222e -- 01:00.1 0403: 10de:0fbc (rev a1) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- !!Modprobe options (Sound related) !! snd_pcsp: index=-2 snd_usb_audio: index=-2 snd_atiixp_modem: index=-2 snd_intel8x0m: index=-2 snd_via82xx_modem: index=-2 !!Loaded sound module options !!--- !!HDA-Intel Codec information !!--- --startcollapse-- Codec: Realtek ID 298 Address: 0 AFG Function Id: 0x1 (unsol 1) Vendor Id: 0x10ec0298 Subsystem Id: 0x17aa222e Revision Id: 0x100103 No Modem Function Group found Default PCM: rates [0x60]: 44100 48000 bits [0xe]: 16 20 24 formats [0x1]: PCM Default Amp-In caps: N/A
Re: [snd_hda_intel] snd_hda_intel causes high CPU lockup and system instability if mic disabled in BIOS on Lenovo P50
On Mon, 26 Nov 2018, Takashi Iwai wrote: On Mon, 26 Nov 2018 00:17:15 +0100, Alexander Kappner wrote: My Lenovo P50 laptop has a BIOS option to disable the microphone. When this option gets chosen, the snd_hda_intel driver causes high CPU load on a single kworker thread, spinning on "process_unsol_events", and system instability. This behavior occurs from the time that the snd_hda_intel module is loaded, irrespective of whether anything is attempting to access the mic. The sound output still works. When in this state, the module cannot be removed cleanly; attempting to remove it (even without rmmod -f) triggers an oops. I have attached two exemplary dmesg outputs. Strangely enough, the exact location of the oops varies, but further up the call chain, I always see process_unsol_events. When the mic is not disabled in the BIOS, the module works stable, regardless whether or not the mic is muted in ALSA. I wasn't able to pinpoint the root cause. Any pointers on where to start? Much appreciated. Could you load snd-hda-intel driver with probe_only=1 option, and give alsa-info.sh output (run it with --no-upload option)? This should leave only the codec probing without configuring, so we can see the codec widget contents and check the emulator. thanks, Takashi Hi Takashi, thank you for looking into this. Please see quoted below the output of alsa-info.sh (after "modprobe snd_hda_intel probe_only=1"). Best regards upload=true=true= !! !!ALSA Information Script v 0.4.64 !! !!Script ran on: Tue Nov 27 05:25:14 UTC 2018 !!Linux Distribution !!-- Debian GNU/Linux 8 \n \l PRETTY_NAME="Debian GNU/Linux 8 (jessie)" NAME="Debian GNU/Linux" ID=debian HOME_URL="http://www.debian.org/; SUPPORT_URL="http://www.debian.org/support; BUG_REPORT_URL="https://bugs.debian.org/; !!DMI Information !!--- Manufacturer: LENOVO Product Name: 20ENCTO1WW Product Version: ThinkPad P50 Firmware Version: N1EET62W (1.35 ) Board Vendor: LENOVO Board Name:20ENCTO1WW !!ACPI Device Status Information !!--- /sys/bus/acpi/devices/ACPI0003:00/status 15 /sys/bus/acpi/devices/LEN0068:00/status 15 /sys/bus/acpi/devices/LNXPOWER:00/status 1 /sys/bus/acpi/devices/LNXPOWER:01/status 1 /sys/bus/acpi/devices/LNXPOWER:02/status 1 /sys/bus/acpi/devices/LNXPOWER:03/status 1 /sys/bus/acpi/devices/LNXVIDEO:00/status 15 /sys/bus/acpi/devices/PNP0103:00/status 15 /sys/bus/acpi/devices/PNP0C0A:00/status 31 /sys/bus/acpi/devices/PNP0C0F:00/status 9 /sys/bus/acpi/devices/PNP0C0F:01/status 9 /sys/bus/acpi/devices/PNP0C0F:02/status 9 /sys/bus/acpi/devices/PNP0C0F:03/status 9 /sys/bus/acpi/devices/PNP0C0F:04/status 9 /sys/bus/acpi/devices/PNP0C0F:05/status 9 /sys/bus/acpi/devices/PNP0C0F:06/status 9 /sys/bus/acpi/devices/PNP0C0F:07/status 9 /sys/bus/acpi/devices/device:3e/status 15 !!Kernel Information !!-- Kernel release:4.19.0-rc4 Operating System: GNU/Linux Architecture: x86_64 Processor: unknown SMP Enabled: Yes !!ALSA Version !! Driver version: k4.19.0-rc4 Library version:1.0.28 Utilities version: 1.0.28 !!Loaded ALSA modules !!--- !!Sound Servers on this system !! Pulseaudio: Installed - Yes (/usr/bin/pulseaudio) Running - No !!Soundcards recognised by ALSA !!- 0 [PCH]: HDA-Intel - HDA Intel PCH HDA Intel PCH at 0xc494 irq 151 1 [NVidia ]: HDA-Intel - HDA NVidia HDA NVidia at 0xc300 irq 17 !!PCI Soundcards installed in the system !!-- 00:1f.3 Audio device: Intel Corporation Device a170 (rev 31) 01:00.1 Audio device: NVIDIA Corporation Device 0fbc (rev a1) !!Advanced information - PCI Vendor/Device/Subsystem ID's !!--- 00:1f.3 0403: 8086:a170 (rev 31) Subsystem: 17aa:222e -- 01:00.1 0403: 10de:0fbc (rev a1) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- !!Modprobe options (Sound related) !! snd_pcsp: index=-2 snd_usb_audio: index=-2 snd_atiixp_modem: index=-2 snd_intel8x0m: index=-2 snd_via82xx_modem: index=-2 !!Loaded sound module options !!--- !!HDA-Intel Codec information !!--- --startcollapse-- Codec: Realtek ID 298 Address: 0 AFG Function Id: 0x1 (unsol 1) Vendor Id: 0x10ec0298 Subsystem Id: 0x17aa222e Revision Id: 0x100103 No Modem Function Group found Default PCM: rates [0x60]: 44100 48000 bits [0xe]: 16 20 24 formats [0x1]: PCM Default Amp-In caps: N/A
