<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers, branch v5.4.86</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>rtc: ep93xx: Fix NULL pointer dereference in ep93xx_rtc_read_time</title>
<updated>2020-12-30T10:51:47+00:00</updated>
<author>
<name>Nikita Shubin</name>
<email>nikita.shubin@maquefel.me</email>
</author>
<published>2020-12-01T09:55:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=33afcf723a0e655d35a60afe451bba47c9045ed3'/>
<id>33afcf723a0e655d35a60afe451bba47c9045ed3</id>
<content type='text'>
commit 00c33482bb6110bce8110daa351f9b3baf4df7dc upstream.

Mismatch in probe platform_set_drvdata set's and method's that call
dev_get_platdata will result in "Unable to handle kernel NULL pointer
dereference", let's use according method for getting driver data after
platform_set_drvdata.

8&lt;--- cut here ---
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = (ptrval)
[00000000] *pgd=00000000
Internal error: Oops: 5 [#1] ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 5.9.10-00003-g723e101e0037-dirty #4
Hardware name: Technologic Systems TS-72xx SBC
PC is at ep93xx_rtc_read_time+0xc/0x2c
LR is at __rtc_read_time+0x4c/0x8c
[...]
[&lt;c02b01c8&gt;] (ep93xx_rtc_read_time) from [&lt;c02ac38c&gt;] (__rtc_read_time+0x4c/0x8c)
[&lt;c02ac38c&gt;] (__rtc_read_time) from [&lt;c02ac3f8&gt;] (rtc_read_time+0x2c/0x4c)
[&lt;c02ac3f8&gt;] (rtc_read_time) from [&lt;c02acc54&gt;] (__rtc_read_alarm+0x28/0x358)
[&lt;c02acc54&gt;] (__rtc_read_alarm) from [&lt;c02abd80&gt;] (__rtc_register_device+0x124/0x2ec)
[&lt;c02abd80&gt;] (__rtc_register_device) from [&lt;c02b028c&gt;] (ep93xx_rtc_probe+0xa4/0xac)
[&lt;c02b028c&gt;] (ep93xx_rtc_probe) from [&lt;c026424c&gt;] (platform_drv_probe+0x24/0x5c)
[&lt;c026424c&gt;] (platform_drv_probe) from [&lt;c0262918&gt;] (really_probe+0x218/0x374)
[&lt;c0262918&gt;] (really_probe) from [&lt;c0262da0&gt;] (device_driver_attach+0x44/0x60)
[&lt;c0262da0&gt;] (device_driver_attach) from [&lt;c0262e70&gt;] (__driver_attach+0xb4/0xc0)
[&lt;c0262e70&gt;] (__driver_attach) from [&lt;c0260d44&gt;] (bus_for_each_dev+0x68/0xac)
[&lt;c0260d44&gt;] (bus_for_each_dev) from [&lt;c026223c&gt;] (driver_attach+0x18/0x24)
[&lt;c026223c&gt;] (driver_attach) from [&lt;c0261dd8&gt;] (bus_add_driver+0x150/0x1b4)
[&lt;c0261dd8&gt;] (bus_add_driver) from [&lt;c026342c&gt;] (driver_register+0xb0/0xf4)
[&lt;c026342c&gt;] (driver_register) from [&lt;c0264210&gt;] (__platform_driver_register+0x30/0x48)
[&lt;c0264210&gt;] (__platform_driver_register) from [&lt;c04cb9ac&gt;] (ep93xx_rtc_driver_init+0x10/0x1c)
[&lt;c04cb9ac&gt;] (ep93xx_rtc_driver_init) from [&lt;c000973c&gt;] (do_one_initcall+0x7c/0x1c0)
[&lt;c000973c&gt;] (do_one_initcall) from [&lt;c04b9ecc&gt;] (kernel_init_freeable+0x168/0x1ac)
[&lt;c04b9ecc&gt;] (kernel_init_freeable) from [&lt;c03b2228&gt;] (kernel_init+0x8/0xf4)
[&lt;c03b2228&gt;] (kernel_init) from [&lt;c00082c0&gt;] (ret_from_fork+0x14/0x34)
Exception stack(0xc441dfb0 to 0xc441dff8)
dfa0:                                     00000000 00000000 00000000 00000000
dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
dfe0: 00000000 00000000 00000000 00000000 00000013 00000000
Code: e12fff1e e92d4010 e590303c e1a02001 (e5933000)
---[ end trace c914d6030eaa95c8 ]---

Fixes: b809d192eb98 ("rtc: ep93xx: stop setting platform_data")
Signed-off-by: Nikita Shubin &lt;nikita.shubin@maquefel.me&gt;
Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20201201095507.10317-1-nikita.shubin@maquefel.me
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 00c33482bb6110bce8110daa351f9b3baf4df7dc upstream.

Mismatch in probe platform_set_drvdata set's and method's that call
dev_get_platdata will result in "Unable to handle kernel NULL pointer
dereference", let's use according method for getting driver data after
platform_set_drvdata.

8&lt;--- cut here ---
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = (ptrval)
[00000000] *pgd=00000000
Internal error: Oops: 5 [#1] ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 5.9.10-00003-g723e101e0037-dirty #4
Hardware name: Technologic Systems TS-72xx SBC
PC is at ep93xx_rtc_read_time+0xc/0x2c
LR is at __rtc_read_time+0x4c/0x8c
[...]
[&lt;c02b01c8&gt;] (ep93xx_rtc_read_time) from [&lt;c02ac38c&gt;] (__rtc_read_time+0x4c/0x8c)
[&lt;c02ac38c&gt;] (__rtc_read_time) from [&lt;c02ac3f8&gt;] (rtc_read_time+0x2c/0x4c)
[&lt;c02ac3f8&gt;] (rtc_read_time) from [&lt;c02acc54&gt;] (__rtc_read_alarm+0x28/0x358)
[&lt;c02acc54&gt;] (__rtc_read_alarm) from [&lt;c02abd80&gt;] (__rtc_register_device+0x124/0x2ec)
[&lt;c02abd80&gt;] (__rtc_register_device) from [&lt;c02b028c&gt;] (ep93xx_rtc_probe+0xa4/0xac)
[&lt;c02b028c&gt;] (ep93xx_rtc_probe) from [&lt;c026424c&gt;] (platform_drv_probe+0x24/0x5c)
[&lt;c026424c&gt;] (platform_drv_probe) from [&lt;c0262918&gt;] (really_probe+0x218/0x374)
[&lt;c0262918&gt;] (really_probe) from [&lt;c0262da0&gt;] (device_driver_attach+0x44/0x60)
[&lt;c0262da0&gt;] (device_driver_attach) from [&lt;c0262e70&gt;] (__driver_attach+0xb4/0xc0)
[&lt;c0262e70&gt;] (__driver_attach) from [&lt;c0260d44&gt;] (bus_for_each_dev+0x68/0xac)
[&lt;c0260d44&gt;] (bus_for_each_dev) from [&lt;c026223c&gt;] (driver_attach+0x18/0x24)
[&lt;c026223c&gt;] (driver_attach) from [&lt;c0261dd8&gt;] (bus_add_driver+0x150/0x1b4)
[&lt;c0261dd8&gt;] (bus_add_driver) from [&lt;c026342c&gt;] (driver_register+0xb0/0xf4)
[&lt;c026342c&gt;] (driver_register) from [&lt;c0264210&gt;] (__platform_driver_register+0x30/0x48)
[&lt;c0264210&gt;] (__platform_driver_register) from [&lt;c04cb9ac&gt;] (ep93xx_rtc_driver_init+0x10/0x1c)
[&lt;c04cb9ac&gt;] (ep93xx_rtc_driver_init) from [&lt;c000973c&gt;] (do_one_initcall+0x7c/0x1c0)
[&lt;c000973c&gt;] (do_one_initcall) from [&lt;c04b9ecc&gt;] (kernel_init_freeable+0x168/0x1ac)
[&lt;c04b9ecc&gt;] (kernel_init_freeable) from [&lt;c03b2228&gt;] (kernel_init+0x8/0xf4)
[&lt;c03b2228&gt;] (kernel_init) from [&lt;c00082c0&gt;] (ret_from_fork+0x14/0x34)
Exception stack(0xc441dfb0 to 0xc441dff8)
dfa0:                                     00000000 00000000 00000000 00000000
dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
dfe0: 00000000 00000000 00000000 00000000 00000013 00000000
Code: e12fff1e e92d4010 e590303c e1a02001 (e5933000)
---[ end trace c914d6030eaa95c8 ]---

Fixes: b809d192eb98 ("rtc: ep93xx: stop setting platform_data")
Signed-off-by: Nikita Shubin &lt;nikita.shubin@maquefel.me&gt;
Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20201201095507.10317-1-nikita.shubin@maquefel.me
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>regulator: axp20x: Fix DLDO2 voltage control register mask for AXP22x</title>
<updated>2020-12-30T10:51:47+00:00</updated>
<author>
<name>DingHua Ma</name>
<email>dinghua.ma.sz@gmail.com</email>
</author>
<published>2020-12-01T00:10:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7e0f7a293608443b41ad768d5a4042d955a89e44'/>
<id>7e0f7a293608443b41ad768d5a4042d955a89e44</id>
<content type='text'>
commit 291de1d102fafef0798cdad9666cd4f8da7da7cc upstream.

When I use the axp20x chip to power my SDIO device on the 5.4 kernel,
the output voltage of DLDO2 is wrong. After comparing the register
manual and source code of the chip, I found that the mask bit of the
driver register of the port was wrong. I fixed this error by modifying
the mask register of the source code. This error seems to be a copy
error of the macro when writing the code. Now the voltage output of
the DLDO2 port of axp20x is correct. My development environment is
Allwinner A40I of arm architecture, and the kernel version is 5.4.

Signed-off-by: DingHua Ma &lt;dinghua.ma.sz@gmail.com&gt;
Reviewed-by: Chen-Yu Tsai &lt;wens@csie.org&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Fixes: db4a555f7c4c ("regulator: axp20x: use defines for masks")
Link: https://lore.kernel.org/r/20201201001000.22302-1-dinghua.ma.sz@gmail.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 291de1d102fafef0798cdad9666cd4f8da7da7cc upstream.

When I use the axp20x chip to power my SDIO device on the 5.4 kernel,
the output voltage of DLDO2 is wrong. After comparing the register
manual and source code of the chip, I found that the mask bit of the
driver register of the port was wrong. I fixed this error by modifying
the mask register of the source code. This error seems to be a copy
error of the macro when writing the code. Now the voltage output of
the DLDO2 port of axp20x is correct. My development environment is
Allwinner A40I of arm architecture, and the kernel version is 5.4.

Signed-off-by: DingHua Ma &lt;dinghua.ma.sz@gmail.com&gt;
Reviewed-by: Chen-Yu Tsai &lt;wens@csie.org&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Fixes: db4a555f7c4c ("regulator: axp20x: use defines for masks")
Link: https://lore.kernel.org/r/20201201001000.22302-1-dinghua.ma.sz@gmail.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: Fix pci_slot_release() NULL pointer dereference</title>
<updated>2020-12-30T10:51:47+00:00</updated>
<author>
<name>Jubin Zhong</name>
<email>zhongjubin@huawei.com</email>
</author>
<published>2020-12-02T02:33:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=be23b04074b1957fd1d5b90a164483f56a310116'/>
<id>be23b04074b1957fd1d5b90a164483f56a310116</id>
<content type='text'>
commit 4684709bf81a2d98152ed6b610e3d5c403f9bced upstream.

If kobject_init_and_add() fails, pci_slot_release() is called to delete
slot-&gt;list from parent-&gt;slots.  But slot-&gt;list hasn't been initialized
yet, so we dereference a NULL pointer:

  Unable to handle kernel NULL pointer dereference at virtual address
00000000
  ...
  CPU: 10 PID: 1 Comm: swapper/0 Not tainted 4.4.240 #197
  task: ffffeb398a45ef10 task.stack: ffffeb398a470000
  PC is at __list_del_entry_valid+0x5c/0xb0
  LR is at pci_slot_release+0x84/0xe4
  ...
  __list_del_entry_valid+0x5c/0xb0
  pci_slot_release+0x84/0xe4
  kobject_put+0x184/0x1c4
  pci_create_slot+0x17c/0x1b4
  __pci_hp_initialize+0x68/0xa4
  pciehp_probe+0x1a4/0x2fc
  pcie_port_probe_service+0x58/0x84
  driver_probe_device+0x320/0x470

Initialize slot-&gt;list before calling kobject_init_and_add() to avoid this.

Fixes: 8a94644b440e ("PCI: Fix pci_create_slot() reference count leak")
Link: https://lore.kernel.org/r/1606876422-117457-1-git-send-email-zhongjubin@huawei.com
Signed-off-by: Jubin Zhong &lt;zhongjubin@huawei.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Cc: stable@vger.kernel.org	# v5.9+
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 4684709bf81a2d98152ed6b610e3d5c403f9bced upstream.

If kobject_init_and_add() fails, pci_slot_release() is called to delete
slot-&gt;list from parent-&gt;slots.  But slot-&gt;list hasn't been initialized
yet, so we dereference a NULL pointer:

  Unable to handle kernel NULL pointer dereference at virtual address
00000000
  ...
  CPU: 10 PID: 1 Comm: swapper/0 Not tainted 4.4.240 #197
  task: ffffeb398a45ef10 task.stack: ffffeb398a470000
  PC is at __list_del_entry_valid+0x5c/0xb0
  LR is at pci_slot_release+0x84/0xe4
  ...
  __list_del_entry_valid+0x5c/0xb0
  pci_slot_release+0x84/0xe4
  kobject_put+0x184/0x1c4
  pci_create_slot+0x17c/0x1b4
  __pci_hp_initialize+0x68/0xa4
  pciehp_probe+0x1a4/0x2fc
  pcie_port_probe_service+0x58/0x84
  driver_probe_device+0x320/0x470

Initialize slot-&gt;list before calling kobject_init_and_add() to avoid this.

Fixes: 8a94644b440e ("PCI: Fix pci_create_slot() reference count leak")
Link: https://lore.kernel.org/r/1606876422-117457-1-git-send-email-zhongjubin@huawei.com
Signed-off-by: Jubin Zhong &lt;zhongjubin@huawei.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Cc: stable@vger.kernel.org	# v5.9+
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>platform/x86: intel-vbtn: Allow switch events on Acer Switch Alpha 12</title>
<updated>2020-12-30T10:51:47+00:00</updated>
<author>
<name>Carlos Garnacho</name>
<email>carlosg@gnome.org</email>
</author>
<published>2020-12-01T13:57:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b1f9419d5e6c02163950d302f0c37055bfd7190a'/>
<id>b1f9419d5e6c02163950d302f0c37055bfd7190a</id>
<content type='text'>
commit fe6000990394639ed374cb76c313be3640714f47 upstream.

This 2-in-1 model (Product name: Switch SA5-271) features a SW_TABLET_MODE
that works as it would be expected, both when detaching the keyboard and
when folding it behind the tablet body.

It used to work until the introduction of the allow list at
commit 8169bd3e6e193 ("platform/x86: intel-vbtn: Switch to an allow-list
for SW_TABLET_MODE reporting"). Add this model to it, so that the Virtual
Buttons device announces the EV_SW features again.

Fixes: 8169bd3e6e193 ("platform/x86: intel-vbtn: Switch to an allow-list for SW_TABLET_MODE reporting")
Cc: stable@vger.kernel.org
Signed-off-by: Carlos Garnacho &lt;carlosg@gnome.org&gt;
Link: https://lore.kernel.org/r/20201201135727.212917-1-carlosg@gnome.org
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit fe6000990394639ed374cb76c313be3640714f47 upstream.

This 2-in-1 model (Product name: Switch SA5-271) features a SW_TABLET_MODE
that works as it would be expected, both when detaching the keyboard and
when folding it behind the tablet body.

It used to work until the introduction of the allow list at
commit 8169bd3e6e193 ("platform/x86: intel-vbtn: Switch to an allow-list
for SW_TABLET_MODE reporting"). Add this model to it, so that the Virtual
Buttons device announces the EV_SW features again.

Fixes: 8169bd3e6e193 ("platform/x86: intel-vbtn: Switch to an allow-list for SW_TABLET_MODE reporting")
Cc: stable@vger.kernel.org
Signed-off-by: Carlos Garnacho &lt;carlosg@gnome.org&gt;
Link: https://lore.kernel.org/r/20201201135727.212917-1-carlosg@gnome.org
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>libnvdimm/namespace: Fix reaping of invalidated block-window-namespace labels</title>
<updated>2020-12-30T10:51:47+00:00</updated>
<author>
<name>Dan Williams</name>
<email>dan.j.williams@intel.com</email>
</author>
<published>2020-11-20T16:50:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c16b5849352cd1c15bf9511ecb91407aebcc04b6'/>
<id>c16b5849352cd1c15bf9511ecb91407aebcc04b6</id>
<content type='text'>
commit 2dd2a1740ee19cd2636d247276cf27bfa434b0e2 upstream.

A recent change to ndctl to attempt to reconfigure namespaces in place
uncovered a label accounting problem in block-window-type namespaces.
The ndctl "create.sh" test is able to trigger this signature:

 WARNING: CPU: 34 PID: 9167 at drivers/nvdimm/label.c:1100 __blk_label_update+0x9a3/0xbc0 [libnvdimm]
 [..]
 RIP: 0010:__blk_label_update+0x9a3/0xbc0 [libnvdimm]
 [..]
 Call Trace:
  uuid_store+0x21b/0x2f0 [libnvdimm]
  kernfs_fop_write+0xcf/0x1c0
  vfs_write+0xcc/0x380
  ksys_write+0x68/0xe0

When allocated capacity for a namespace is renamed (new UUID) the labels
with the old UUID need to be deleted. The ndctl behavior to always
destroy namespaces on reconfiguration hid this problem.

The immediate impact of this bug is limited since block-window-type
namespaces only seem to exist in the specification and not in any
shipping products. However, the label handling code is being reused for
other technologies like CXL region labels, so there is a benefit to
making sure both vertical labels sets (block-window) and horizontal
label sets (pmem) have a functional reference implementation in
libnvdimm.

Fixes: c4703ce11c23 ("libnvdimm/namespace: Fix label tracking error")
Cc: &lt;stable@vger.kernel.org&gt;
Cc: Vishal Verma &lt;vishal.l.verma@intel.com&gt;
Cc: Dave Jiang &lt;dave.jiang@intel.com&gt;
Cc: Ira Weiny &lt;ira.weiny@intel.com&gt;
Signed-off-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2dd2a1740ee19cd2636d247276cf27bfa434b0e2 upstream.

A recent change to ndctl to attempt to reconfigure namespaces in place
uncovered a label accounting problem in block-window-type namespaces.
The ndctl "create.sh" test is able to trigger this signature:

 WARNING: CPU: 34 PID: 9167 at drivers/nvdimm/label.c:1100 __blk_label_update+0x9a3/0xbc0 [libnvdimm]
 [..]
 RIP: 0010:__blk_label_update+0x9a3/0xbc0 [libnvdimm]
 [..]
 Call Trace:
  uuid_store+0x21b/0x2f0 [libnvdimm]
  kernfs_fop_write+0xcf/0x1c0
  vfs_write+0xcc/0x380
  ksys_write+0x68/0xe0

When allocated capacity for a namespace is renamed (new UUID) the labels
with the old UUID need to be deleted. The ndctl behavior to always
destroy namespaces on reconfiguration hid this problem.

The immediate impact of this bug is limited since block-window-type
namespaces only seem to exist in the specification and not in any
shipping products. However, the label handling code is being reused for
other technologies like CXL region labels, so there is a benefit to
making sure both vertical labels sets (block-window) and horizontal
label sets (pmem) have a functional reference implementation in
libnvdimm.

Fixes: c4703ce11c23 ("libnvdimm/namespace: Fix label tracking error")
Cc: &lt;stable@vger.kernel.org&gt;
Cc: Vishal Verma &lt;vishal.l.verma@intel.com&gt;
Cc: Dave Jiang &lt;dave.jiang@intel.com&gt;
Cc: Ira Weiny &lt;ira.weiny@intel.com&gt;
Signed-off-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>xenbus/xenbus_backend: Disallow pending watch messages</title>
<updated>2020-12-30T10:51:47+00:00</updated>
<author>
<name>SeongJae Park</name>
<email>sjpark@amazon.de</email>
</author>
<published>2020-12-14T09:08:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=68d139a974157b1c18dc97102bfb3e2a04a494c4'/>
<id>68d139a974157b1c18dc97102bfb3e2a04a494c4</id>
<content type='text'>
commit 9996bd494794a2fe393e97e7a982388c6249aa76 upstream.

'xenbus_backend' watches 'state' of devices, which is writable by
guests.  Hence, if guests intensively updates it, dom0 will have lots of
pending events that exhausting memory of dom0.  In other words, guests
can trigger dom0 memory pressure.  This is known as XSA-349.  However,
the watch callback of it, 'frontend_changed()', reads only 'state', so
doesn't need to have the pending events.

To avoid the problem, this commit disallows pending watch messages for
'xenbus_backend' using the 'will_handle()' watch callback.

This is part of XSA-349

Cc: stable@vger.kernel.org
Signed-off-by: SeongJae Park &lt;sjpark@amazon.de&gt;
Reported-by: Michael Kurth &lt;mku@amazon.de&gt;
Reported-by: Pawel Wieczorkiewicz &lt;wipawel@amazon.de&gt;
Reviewed-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 9996bd494794a2fe393e97e7a982388c6249aa76 upstream.

'xenbus_backend' watches 'state' of devices, which is writable by
guests.  Hence, if guests intensively updates it, dom0 will have lots of
pending events that exhausting memory of dom0.  In other words, guests
can trigger dom0 memory pressure.  This is known as XSA-349.  However,
the watch callback of it, 'frontend_changed()', reads only 'state', so
doesn't need to have the pending events.

To avoid the problem, this commit disallows pending watch messages for
'xenbus_backend' using the 'will_handle()' watch callback.

This is part of XSA-349

Cc: stable@vger.kernel.org
Signed-off-by: SeongJae Park &lt;sjpark@amazon.de&gt;
Reported-by: Michael Kurth &lt;mku@amazon.de&gt;
Reported-by: Pawel Wieczorkiewicz &lt;wipawel@amazon.de&gt;
Reviewed-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>xen/xenbus: Count pending messages for each watch</title>
<updated>2020-12-30T10:51:47+00:00</updated>
<author>
<name>SeongJae Park</name>
<email>sjpark@amazon.de</email>
</author>
<published>2020-12-14T09:07:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d3eaea062b515d5e18aee2aba7191dc80a207068'/>
<id>d3eaea062b515d5e18aee2aba7191dc80a207068</id>
<content type='text'>
commit 3dc86ca6b4c8cfcba9da7996189d1b5a358a94fc upstream.

This commit adds a counter of pending messages for each watch in the
struct.  It is used to skip unnecessary pending messages lookup in
'unregister_xenbus_watch()'.  It could also be used in 'will_handle'
callback.

This is part of XSA-349

Cc: stable@vger.kernel.org
Signed-off-by: SeongJae Park &lt;sjpark@amazon.de&gt;
Reported-by: Michael Kurth &lt;mku@amazon.de&gt;
Reported-by: Pawel Wieczorkiewicz &lt;wipawel@amazon.de&gt;
Reviewed-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 3dc86ca6b4c8cfcba9da7996189d1b5a358a94fc upstream.

This commit adds a counter of pending messages for each watch in the
struct.  It is used to skip unnecessary pending messages lookup in
'unregister_xenbus_watch()'.  It could also be used in 'will_handle'
callback.

This is part of XSA-349

Cc: stable@vger.kernel.org
Signed-off-by: SeongJae Park &lt;sjpark@amazon.de&gt;
Reported-by: Michael Kurth &lt;mku@amazon.de&gt;
Reported-by: Pawel Wieczorkiewicz &lt;wipawel@amazon.de&gt;
Reviewed-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>xen/xenbus/xen_bus_type: Support will_handle watch callback</title>
<updated>2020-12-30T10:51:46+00:00</updated>
<author>
<name>SeongJae Park</name>
<email>sjpark@amazon.de</email>
</author>
<published>2020-12-14T09:05:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c45b0a8d2a68dae5c5b5723a4c9aaa32fb125c2d'/>
<id>c45b0a8d2a68dae5c5b5723a4c9aaa32fb125c2d</id>
<content type='text'>
commit be987200fbaceaef340872841d4f7af2c5ee8dc3 upstream.

This commit adds support of the 'will_handle' watch callback for
'xen_bus_type' users.

This is part of XSA-349

Cc: stable@vger.kernel.org
Signed-off-by: SeongJae Park &lt;sjpark@amazon.de&gt;
Reported-by: Michael Kurth &lt;mku@amazon.de&gt;
Reported-by: Pawel Wieczorkiewicz &lt;wipawel@amazon.de&gt;
Reviewed-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit be987200fbaceaef340872841d4f7af2c5ee8dc3 upstream.

This commit adds support of the 'will_handle' watch callback for
'xen_bus_type' users.

This is part of XSA-349

Cc: stable@vger.kernel.org
Signed-off-by: SeongJae Park &lt;sjpark@amazon.de&gt;
Reported-by: Michael Kurth &lt;mku@amazon.de&gt;
Reported-by: Pawel Wieczorkiewicz &lt;wipawel@amazon.de&gt;
Reviewed-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>xen/xenbus: Add 'will_handle' callback support in xenbus_watch_path()</title>
<updated>2020-12-30T10:51:46+00:00</updated>
<author>
<name>SeongJae Park</name>
<email>sjpark@amazon.de</email>
</author>
<published>2020-12-14T09:04:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7da6db982e53e620f4761b9f98f24d1cc9d6f3dd'/>
<id>7da6db982e53e620f4761b9f98f24d1cc9d6f3dd</id>
<content type='text'>
commit 2e85d32b1c865bec703ce0c962221a5e955c52c2 upstream.

Some code does not directly make 'xenbus_watch' object and call
'register_xenbus_watch()' but use 'xenbus_watch_path()' instead.  This
commit adds support of 'will_handle' callback in the
'xenbus_watch_path()' and it's wrapper, 'xenbus_watch_pathfmt()'.

This is part of XSA-349

Cc: stable@vger.kernel.org
Signed-off-by: SeongJae Park &lt;sjpark@amazon.de&gt;
Reported-by: Michael Kurth &lt;mku@amazon.de&gt;
Reported-by: Pawel Wieczorkiewicz &lt;wipawel@amazon.de&gt;
Reviewed-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2e85d32b1c865bec703ce0c962221a5e955c52c2 upstream.

Some code does not directly make 'xenbus_watch' object and call
'register_xenbus_watch()' but use 'xenbus_watch_path()' instead.  This
commit adds support of 'will_handle' callback in the
'xenbus_watch_path()' and it's wrapper, 'xenbus_watch_pathfmt()'.

This is part of XSA-349

Cc: stable@vger.kernel.org
Signed-off-by: SeongJae Park &lt;sjpark@amazon.de&gt;
Reported-by: Michael Kurth &lt;mku@amazon.de&gt;
Reported-by: Pawel Wieczorkiewicz &lt;wipawel@amazon.de&gt;
Reviewed-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>xen/xenbus: Allow watches discard events before queueing</title>
<updated>2020-12-30T10:51:46+00:00</updated>
<author>
<name>SeongJae Park</name>
<email>sjpark@amazon.de</email>
</author>
<published>2020-12-14T09:02:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=eac0c12e329d489ff36e85fed5ce2a8606e3124d'/>
<id>eac0c12e329d489ff36e85fed5ce2a8606e3124d</id>
<content type='text'>
commit fed1755b118147721f2c87b37b9d66e62c39b668 upstream.

If handling logics of watch events are slower than the events enqueue
logic and the events can be created from the guests, the guests could
trigger memory pressure by intensively inducing the events, because it
will create a huge number of pending events that exhausting the memory.

Fortunately, some watch events could be ignored, depending on its
handler callback.  For example, if the callback has interest in only one
single path, the watch wouldn't want multiple pending events.  Or, some
watches could ignore events to same path.

To let such watches to volutarily help avoiding the memory pressure
situation, this commit introduces new watch callback, 'will_handle'.  If
it is not NULL, it will be called for each new event just before
enqueuing it.  Then, if the callback returns false, the event will be
discarded.  No watch is using the callback for now, though.

This is part of XSA-349

Cc: stable@vger.kernel.org
Signed-off-by: SeongJae Park &lt;sjpark@amazon.de&gt;
Reported-by: Michael Kurth &lt;mku@amazon.de&gt;
Reported-by: Pawel Wieczorkiewicz &lt;wipawel@amazon.de&gt;
Reviewed-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit fed1755b118147721f2c87b37b9d66e62c39b668 upstream.

If handling logics of watch events are slower than the events enqueue
logic and the events can be created from the guests, the guests could
trigger memory pressure by intensively inducing the events, because it
will create a huge number of pending events that exhausting the memory.

Fortunately, some watch events could be ignored, depending on its
handler callback.  For example, if the callback has interest in only one
single path, the watch wouldn't want multiple pending events.  Or, some
watches could ignore events to same path.

To let such watches to volutarily help avoiding the memory pressure
situation, this commit introduces new watch callback, 'will_handle'.  If
it is not NULL, it will be called for each new event just before
enqueuing it.  Then, if the callback returns false, the event will be
discarded.  No watch is using the callback for now, though.

This is part of XSA-349

Cc: stable@vger.kernel.org
Signed-off-by: SeongJae Park &lt;sjpark@amazon.de&gt;
Reported-by: Michael Kurth &lt;mku@amazon.de&gt;
Reported-by: Pawel Wieczorkiewicz &lt;wipawel@amazon.de&gt;
Reviewed-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
