[PATCH] drivers/net/wan/lapbether: Fixed the value of hard_header_len
When transmitting data from upper layers or from AF_PACKET sockets, this driver will first remove a pseudo header of 1 byte, then the lapb module will prepend the LAPB header of 2 or 3 bytes, then this driver will prepend a length field of 2 bytes, then the underlying Ethernet device will prepend its own header. So, the header length required should be: -1 + 3 + 2 + "the header length needed by the underlying device". This patch fixes kernel panic when this driver is used with AF_PACKET SOCK_DGRAM sockets. Signed-off-by: Xie He --- drivers/net/wan/lapbether.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/wan/lapbether.c b/drivers/net/wan/lapbether.c index e30d91a38cfb..3b5ed0928a4c 100644 --- a/drivers/net/wan/lapbether.c +++ b/drivers/net/wan/lapbether.c @@ -303,7 +303,6 @@ static void lapbeth_setup(struct net_device *dev) dev->netdev_ops = _netdev_ops; dev->needs_free_netdev = true; dev->type= ARPHRD_X25; - dev->hard_header_len = 3; dev->mtu = 1000; dev->addr_len= 0; } @@ -324,6 +323,8 @@ static int lapbeth_new_device(struct net_device *dev) if (!ndev) goto out; + ndev->hard_header_len = -1 + 3 + 2 + dev->hard_header_len; + lapbeth = netdev_priv(ndev); lapbeth->axdev = ndev; -- 2.25.1
[git pull] sysctl fix
More regression fixes in sysctl changes this cycle... The following changes since commit b3a9e3b9622ae10064826dccb4f7a52bd88c7407: Linux 5.8-rc1 (2020-06-14 12:45:04 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git fixes for you to fetch changes up to d4d80e69927ab5da67026c1c94e23c305dbc799e: Call sysctl_head_finish on error (2020-07-03 14:10:46 -0400) Matthew Wilcox (Oracle) (1): Call sysctl_head_finish on error fs/proc/proc_sysctl.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
[PATCH] dts: hi3660: Add support for basic usb gadget on Hikey960
This patch adds basic core dwc3, usb phy and rt1711h nodes for
usb support on Hikey960.
This does not enable the mux/hub functionality on the board, so
the USB-A host ports will not function, but does allow the USB-C
port to function in gadget mode (unfortunately not in host, as
the hub/mux functionality is needed to enable vbus output to
power devices in host mode).
This is based on an old patch originally by Yu Chen.
Cc: Yu Chen
Cc: Chunfeng Yun
Cc: Wei Xu
Cc: Binghui Wang
Cc: YongQin Liu
Cc: Rob Herring
Cc: Matthias Brugger
Cc: Mark Rutland
Cc: linux-arm-ker...@lists.infradead.org
Cc: devicet...@vger.kernel.org
Signed-off-by: John Stultz
---
.../boot/dts/hisilicon/hi3660-hikey960.dts| 72 +++
arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 34 +
2 files changed, 106 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
index e035cf195b19..ff392a47562c 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
/ {
model = "HiKey960";
@@ -526,6 +527,48 @@
{
status = "okay";
+ rt1711h: rt1711h@4e {
+ compatible = "richtek,rt1711h";
+ reg = <0x4e>;
+ status = "ok";
+ interrupt-parent = <>;
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_cfg_func>;
+
+ usb_con: connector {
+ compatible = "usb-c-connector";
+ label = "USB-C";
+ data-role = "dual";
+ power-role = "dual";
+ try-power-role = "sink";
+ source-pdos = ;
+ sink-pdos = ;
+ op-sink-microwatt = <1000>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@1 {
+ reg = <1>;
+ usb_con_ss: endpoint {
+ remote-endpoint = <_ss>;
+ };
+ };
+ };
+ };
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rt1711h_ep: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <_role_switch>;
+ };
+ };
+ };
+
adv7533: adv7533@39 {
status = "ok";
compatible = "adi,adv7533";
@@ -612,3 +655,32 @@
interrupts = <3 IRQ_TYPE_EDGE_RISING>;
};
};
+
+ { /* USB */
+ dr_mode = "otg";
+ maximum-speed = "super-speed";
+ phy_type = "utmi";
+ snps,dis-del-phy-power-chg-quirk;
+ snps,lfps_filter_quirk;
+ snps,dis_u2_susphy_quirk;
+ snps,dis_u3_susphy_quirk;
+ snps,tx_de_emphasis_quirk;
+ snps,tx_de_emphasis = <1>;
+ snps,dis_enblslpm_quirk;
+ snps,gctl-reset-quirk;
+ usb-role-switch;
+ role-switch-default-mode = "host";
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ dwc3_role_switch: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <_ep>;
+ };
+
+ dwc3_ss: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <_con_ss>;
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index c39b78989ff9..d25aac5e0bf8 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -1152,6 +1152,40 @@
};
};
};
+
+ usb3_otg_bc: usb3_otg_bc@ff20 {
+ compatible = "syscon", "simple-mfd";
+ reg = <0x0 0xff20 0x0 0x1000>;
+
+ usb_phy: usb-phy {
+ compatible = "hisilicon,hi3660-usb-phy";
+ #phy-cells = <0>;
+ hisilicon,pericrg-syscon = <_ctrl>;
+ hisilicon,pctrl-syscon = <>;
+ hisilicon,eye-diagram-param = <0x22466e4>;
+ };
+ };
+
+ dwc3: dwc3@ff10 {
+ compatible = "snps,dwc3";
+ reg = <0x0 0xff10 0x0 0x10>;
+
+ clocks = <_ctrl HI3660_CLK_ABB_USB>,
+
Re: [PATCH] phy: samsung: Use readl_poll_timeout function
hi Krzysztof,
On Fri, 3 Jul 2020 at 22:13, Krzysztof Kozlowski wrote:
>
> On Fri, Jul 03, 2020 at 01:20:12PM +, Anand Moon wrote:
> > User readl_poll_timeout function instead of open
> > coded handling in crport_handshake function.
> >
> > Signed-off-by: Anand Moon
> > ---
> > drivers/phy/samsung/phy-exynos5-usbdrd.c | 37 +---
> > 1 file changed, 13 insertions(+), 24 deletions(-)
> >
> > diff --git a/drivers/phy/samsung/phy-exynos5-usbdrd.c
> > b/drivers/phy/samsung/phy-exynos5-usbdrd.c
> > index e510732afb8b..83274c5e3820 100644
> > --- a/drivers/phy/samsung/phy-exynos5-usbdrd.c
> > +++ b/drivers/phy/samsung/phy-exynos5-usbdrd.c
> > @@ -16,6 +16,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -556,40 +557,28 @@ static int exynos5_usbdrd_phy_power_off(struct phy
> > *phy)
> > static int crport_handshake(struct exynos5_usbdrd_phy *phy_drd,
> > u32 val, u32 cmd)
> > {
> > - u32 usec = 100;
> > + u32 timeout_us = 1000, sleep_us = 10;
> > unsigned int result;
>
> You silently (without mentioning in commit msg and explaining why)
> changed both the sleep time and total timeout.
>
Ok I will stick with the original default value.
timeout_us = 100, sleep_us = 1;
> Nope, please explain why you chosen such values and change them in
> separate patch..
I choose these values following Alim Akhtar's UFS PHY patches.
>
> > + int err;
> >
> > writel(val | cmd, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
> >
> > - do {
> > - result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
> > - if (result & PHYREG1_CR_ACK)
> > - break;
> > -
> > - udelay(1);
> > - } while (usec-- > 0);
> > -
> > - if (!usec) {
> > - dev_err(phy_drd->dev,
> > - "CRPORT handshake timeout1 (0x%08x)\n", val);
> > + err = readl_poll_timeout(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1,
> > + result, (result & PHYREG1_CR_ACK), sleep_us,
> > timeout_us);
> > + if (err) {
> > + dev_err(phy_drd->dev, "CRPORT handshake timeout1 (0x%08x)\n",
> > val);
> > return -ETIME;
> > }
> >
> > - usec = 100;
> > + timeout_us = 1000;
> > + sleep_us = 10;
>
> The same.
>
> Best regards,
> Krzysztof
>
Best regards,
-Anand
[PATCH] ASoC: amd: fix Kconfig warning for Renoir
From: Randy Dunlap
SND_SOC_DMIC depends on GPIOLIB so this driver should also depend on
GPIOLIB to make kconfig happy.
WARNING: unmet direct dependencies detected for SND_SOC_DMIC
Depends on [n]: SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && GPIOLIB [=n]
Selected by [y]:
- SND_SOC_AMD_RENOIR_MACH [=y] && SOUND [=y] && !UML && SND [=y] && SND_SOC
[=y] && SND_SOC_AMD_RENOIR [=y]
Fixes: 1d3776669323 ("ASoC: amd: enable build for RN machine driver")
Signed-off-by: Randy Dunlap
Cc: Vijendar Mukunda
Cc: Mark Brown
---
Found in mmotm.
There are no object file build errors. I suppose that gpiolib stubs
take care of that. Maybe some other patch would be more appropriate.
sound/soc/amd/Kconfig |1 +
1 file changed, 1 insertion(+)
--- mmotm-2020-0703-1503.orig/sound/soc/amd/Kconfig
+++ mmotm-2020-0703-1503/sound/soc/amd/Kconfig
@@ -47,5 +47,6 @@ config SND_SOC_AMD_RENOIR_MACH
tristate "AMD Renoir support for DMIC"
select SND_SOC_DMIC
depends on SND_SOC_AMD_RENOIR
+ depends on GPIOLIB
help
This option enables machine driver for DMIC
Re: [PATCH] tpm: Define TPM2_SPACE_BUFFER_SIZE to replace the use of PAGE_SIZE
On Thu, Jul 02, 2020 at 04:55:44PM -0700, Jerry Snitselaar wrote:
> On Fri Jul 03 20, Jarkko Sakkinen wrote:
> > The size of the buffers for storing context's and sessions can vary from
> > arch to arch as PAGE_SIZE can be anything between 4 kB and 256 kB (the
> > maximum for PPC64). Define a fixed buffer size set to 16 kB. This should be
> > enough for most use with three handles (that is how many we allow at the
> > moment). Parametrize the buffer size while doing this, so that it is easier
> > to revisit this later on if required.
> >
> > Reported-by: Stefan Berger
> > Cc: sta...@vger.kernel.org
> > Fixes: 745b361e989a ("tpm: infrastructure for TPM spaces")
> > Signed-off-by: Jarkko Sakkinen
>
> Reviewed-by: Jerry Snitselaar
Thank you.
Now only needs tested-by from Stefan.
/Jarkko
[PATCH 17/17] Documentation/driver-api: xillybus: drop doubled word
Drop the doubled word "the". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Eli Billauer --- Documentation/driver-api/xillybus.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/driver-api/xillybus.rst +++ linux-next-20200701/Documentation/driver-api/xillybus.rst @@ -273,7 +273,7 @@ buffer is full, the FPGA informs the hos XILLYMSG_OPCODE_RELEASEBUF message channel 0 and sending an interrupt if necessary). The host responds by making the data available for reading through the character device. When all data has been read, the host writes on the -the FPGA's buffer control register, allowing the buffer's overwriting. Flow +FPGA's buffer control register, allowing the buffer's overwriting. Flow control mechanisms exist on both sides to prevent underflows and overflows. This is not good enough for creating a TCP/IP-like stream: If the data flow
[PATCH 12/17] Documentation/driver-api: ntb: drop doubled word
Drop the doubled word "with". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Jon Mason Cc: Dave Jiang Cc: Allen Hubbe Cc: linux-...@googlegroups.com --- Documentation/driver-api/ntb.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/driver-api/ntb.rst +++ linux-next-20200701/Documentation/driver-api/ntb.rst @@ -9,7 +9,7 @@ registers and memory translation windows scratchpad and message registers. Scratchpad registers are read-and-writable registers that are accessible from either side of the device, so that peers can exchange a small amount of information at a fixed address. Message registers can -be utilized for the same purpose. Additionally they are provided with with +be utilized for the same purpose. Additionally they are provided with special status bits to make sure the information isn't rewritten by another peer. Doorbell registers provide a way for peers to send interrupt events. Memory windows allow translated read and write access to the peer memory.
[PATCH 09/17] Documentation/driver-api: media/dtv-frontend: drop doubled word
Drop the doubled word "errors". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Mauro Carvalho Chehab Cc: linux-me...@vger.kernel.org --- Documentation/driver-api/media/dtv-frontend.rst |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- linux-next-20200701.orig/Documentation/driver-api/media/dtv-frontend.rst +++ linux-next-20200701/Documentation/driver-api/media/dtv-frontend.rst @@ -244,7 +244,7 @@ Carrier Signal to Noise ratio (:ref:`DTV Having it available after inner FEC is more common. Bit counts post-FEC (:ref:`DTV-STAT-POST-ERROR-BIT-COUNT` and :ref:`DTV-STAT-POST-TOTAL-BIT-COUNT`) - - Those counters measure the number of bits and bit errors errors after + - Those counters measure the number of bits and bit errors after the forward error correction (FEC) on the inner coding block (after Viterbi, LDPC or other inner code). @@ -253,7 +253,7 @@ Bit counts post-FEC (:ref:`DTV-STAT-POST see :c:type:`fe_status`). Bit counts pre-FEC (:ref:`DTV-STAT-PRE-ERROR-BIT-COUNT` and :ref:`DTV-STAT-PRE-TOTAL-BIT-COUNT`) - - Those counters measure the number of bits and bit errors errors before + - Those counters measure the number of bits and bit errors before the forward error correction (FEC) on the inner coding block (before Viterbi, LDPC or other inner code). @@ -263,7 +263,7 @@ Bit counts pre-FEC (:ref:`DTV-STAT-PRE-E after ``FE_HAS_VITERBI``, see :c:type:`fe_status`). Block counts (:ref:`DTV-STAT-ERROR-BLOCK-COUNT` and :ref:`DTV-STAT-TOTAL-BLOCK-COUNT`) - - Those counters measure the number of blocks and block errors errors after + - Those counters measure the number of blocks and block errors after the forward error correction (FEC) on the inner coding block (before Viterbi, LDPC or other inner code).
[PATCH 15/17] Documentation/driver-api: usb/URB: drop doubled word
Drop the doubled word "also". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Greg Kroah-Hartman Cc: linux-...@vger.kernel.org --- Documentation/driver-api/usb/URB.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/driver-api/usb/URB.rst +++ linux-next-20200701/Documentation/driver-api/usb/URB.rst @@ -240,7 +240,7 @@ How to do isochronous (ISO) transfers? == Besides the fields present on a bulk transfer, for ISO, you also -also have to set ``urb->interval`` to say how often to make transfers; it's +have to set ``urb->interval`` to say how often to make transfers; it's often one per frame (which is once every microframe for highspeed devices). The actual interval used will be a power of two that's no bigger than what you specify. You can use the :c:func:`usb_fill_int_urb` macro to fill
[PATCH 14/17] Documentation/driver-api: uio-howto: drop doubled word
Drop the doubled word "you". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Greg Kroah-Hartman --- Documentation/driver-api/uio-howto.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/driver-api/uio-howto.rst +++ linux-next-20200701/Documentation/driver-api/uio-howto.rst @@ -274,7 +274,7 @@ fields of ``struct uio_mem``: region, it will show up in the corresponding sysfs node. - ``int memtype``: Required if the mapping is used. Set this to - ``UIO_MEM_PHYS`` if you you have physical memory on your card to be + ``UIO_MEM_PHYS`` if you have physical memory on your card to be mapped. Use ``UIO_MEM_LOGICAL`` for logical memory (e.g. allocated with :c:func:`__get_free_pages()` but not kmalloc()). There's also ``UIO_MEM_VIRTUAL`` for virtual memory.
[PATCH 16/17] Documentation/driver-api: media/v4l2-controls: drop doubled words
Drop the doubled words "type" and "the". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Mauro Carvalho Chehab Cc: linux-me...@vger.kernel.org --- Documentation/driver-api/media/v4l2-controls.rst |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- linux-next-20200701.orig/Documentation/driver-api/media/v4l2-controls.rst +++ linux-next-20200701/Documentation/driver-api/media/v4l2-controls.rst @@ -335,7 +335,7 @@ current and new values: union v4l2_ctrl_ptr p_new; union v4l2_ctrl_ptr p_cur; -If the control has a simple s32 type type, then: +If the control has a simple s32 type, then: .. code-block:: c @@ -349,7 +349,7 @@ Within the control ops you can freely us themselves. The p_char pointers point to character buffers of length ctrl->maximum + 1, and are always 0-terminated. -Unless the control is marked volatile the p_cur field points to the the +Unless the control is marked volatile the p_cur field points to the current cached control value. When you create a new control this value is made identical to the default value. After calling v4l2_ctrl_handler_setup() this value is passed to the hardware. It is generally a good idea to call this
[PATCH 07/17] Documentation/driver-api: iio/buffers: drop doubled word
Drop the doubled word "struct".
Signed-off-by: Randy Dunlap
Cc: Jonathan Corbet
Cc: linux-...@vger.kernel.org
Cc: William Breathitt Gray
Cc: linux-...@vger.kernel.org
---
Documentation/driver-api/iio/buffers.rst |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20200701.orig/Documentation/driver-api/iio/buffers.rst
+++ linux-next-20200701/Documentation/driver-api/iio/buffers.rst
@@ -88,7 +88,7 @@ fields in iio_chan_spec definition::
The driver implementing the accelerometer described above will have the
following channel definition::
- struct struct iio_chan_spec accel_channels[] = {
+ struct iio_chan_spec accel_channels[] = {
{
.type = IIO_ACCEL,
.modified = 1,
[PATCH 13/17] Documentation/driver-api: nvdimm: drop doubled word
Drop the doubled word "to". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Dan Williams Cc: Vishal Verma Cc: Dave Jiang Cc: Ira Weiny Cc: linux-nvd...@lists.01.org --- Documentation/driver-api/nvdimm/nvdimm.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/driver-api/nvdimm/nvdimm.rst +++ linux-next-20200701/Documentation/driver-api/nvdimm/nvdimm.rst @@ -73,7 +73,7 @@ DAX: process address space. DSM: - Device Specific Method: ACPI method to to control specific + Device Specific Method: ACPI method to control specific device - in this case the firmware. DCR:
[PATCH 10/17] Documentation/driver-api: media/v4l2-dev: drop doubled word
Drop the doubled word "device". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Mauro Carvalho Chehab Cc: linux-me...@vger.kernel.org --- Documentation/driver-api/media/v4l2-dev.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/driver-api/media/v4l2-dev.rst +++ linux-next-20200701/Documentation/driver-api/media/v4l2-dev.rst @@ -212,7 +212,7 @@ types exist: == == The last argument gives you a certain amount of control over the device -device node number used (i.e. the X in ``videoX``). Normally you will pass -1 +node number used (i.e. the X in ``videoX``). Normally you will pass -1 to let the v4l2 framework pick the first free number. But sometimes users want to select a specific node number. It is common that drivers allow the user to select a specific device node number through a driver module
[PATCH 11/17] Documentation/driver-api: driver-model/platform: drop doubled word
Drop the doubled word "that". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Greg Kroah-Hartman --- Documentation/driver-api/driver-model/platform.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/driver-api/driver-model/platform.rst +++ linux-next-20200701/Documentation/driver-api/driver-model/platform.rst @@ -108,7 +108,7 @@ field to hold additional information. Embedded systems frequently need one or more clocks for platform devices, which are normally kept off until they're actively needed (to save power). -System setup also associates those clocks with the device, so that that +System setup also associates those clocks with the device, so that calls to clk_get(>dev, clock_name) return them as needed.
[PATCH 04/17] Documentation/driver-api: firmware/direct-fs-lookup: drop doubled word
Drop the doubled word "firmware". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Luis Chamberlain Cc: Greg Kroah-Hartman --- Documentation/driver-api/firmware/direct-fs-lookup.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/driver-api/firmware/direct-fs-lookup.rst +++ linux-next-20200701/Documentation/driver-api/firmware/direct-fs-lookup.rst @@ -24,7 +24,7 @@ available. Stuffing the firmware into in however note that using initrd does not suffice to address the same race. There are circumstances that justify not wanting to include firmware into -initramfs, such as dealing with large firmware firmware files for the +initramfs, such as dealing with large firmware files for the remote-proc subsystem. For such cases using a userspace fallback mechanism is currently the only viable solution as only userspace can know for sure when the real rootfs is ready and mounted.
[PATCH 08/17] Documentation/driver-api: media/cec-core: drop doubled word
Drop the doubled word "the". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Mauro Carvalho Chehab Cc: linux-me...@vger.kernel.org --- Documentation/driver-api/media/cec-core.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/driver-api/media/cec-core.rst +++ linux-next-20200701/Documentation/driver-api/media/cec-core.rst @@ -341,7 +341,7 @@ So this must work: $ cat einj.txt >error-inj The first callback is called when this file is read and it should show the -the current error injection state: +current error injection state: .. c:function:: int (*error_inj_show)(struct cec_adapter *adap, struct seq_file *sf);
[PATCH 02/17] Documentation/driver-api: firmware/built-in-fw: drop doubled word
Drop the doubled word "for". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Luis Chamberlain Cc: Greg Kroah-Hartman --- Documentation/driver-api/firmware/built-in-fw.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/driver-api/firmware/built-in-fw.rst +++ linux-next-20200701/Documentation/driver-api/firmware/built-in-fw.rst @@ -28,6 +28,6 @@ able to make use of built-in firmware: * Some firmware files may be really large in size. The remote-proc subsystem is an example subsystem which deals with these sorts of firmware * The firmware may need to be scraped out from some device specific location - dynamically, an example is calibration data for for some WiFi chipsets. This + dynamically, an example is calibration data for some WiFi chipsets. This calibration data can be unique per sold device.
[PATCH 06/17] Documentation/driver-api: generic-counter: drop doubled word
Drop the doubled word "the". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: William Breathitt Gray Cc: linux-...@vger.kernel.org --- Documentation/driver-api/generic-counter.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/driver-api/generic-counter.rst +++ linux-next-20200701/Documentation/driver-api/generic-counter.rst @@ -262,7 +262,7 @@ the system. Counter Counts may be allocated via counter_count structures, and respective Counter Signal associations (Synapses) made via counter_synapse structures. Associated counter_synapse structures are -stored as an array and set to the the synapses array member of the +stored as an array and set to the synapses array member of the respective counter_count structure. These counter_count structures are set to the counts array member of an allocated counter_device structure before the Counter is registered to the system.
[PATCH 05/17] Documentation/driver-api: firmware/request_firmware: drop doubled word
Drop the doubled word "call".
Signed-off-by: Randy Dunlap
Cc: Jonathan Corbet
Cc: linux-...@vger.kernel.org
Cc: Luis Chamberlain
Cc: Greg Kroah-Hartman
---
Documentation/driver-api/firmware/request_firmware.rst |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
---
linux-next-20200701.orig/Documentation/driver-api/firmware/request_firmware.rst
+++ linux-next-20200701/Documentation/driver-api/firmware/request_firmware.rst
@@ -76,5 +76,5 @@ firmware. For example if you used reques
the driver has the firmware image accessible in fw_entry->{data,size}.
If something went wrong request_firmware() returns non-zero and fw_entry
is set to NULL. Once your driver is done with processing the firmware it
-can call call release_firmware(fw_entry) to release the firmware image
+can call release_firmware(fw_entry) to release the firmware image
and any related resource.
[PATCH 03/17] Documentation/driver-api: firmware/firmware_cache: drop doubled word
Drop the doubled word "if". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Luis Chamberlain Cc: Greg Kroah-Hartman --- Documentation/driver-api/firmware/firmware_cache.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/driver-api/firmware/firmware_cache.rst +++ linux-next-20200701/Documentation/driver-api/firmware/firmware_cache.rst @@ -27,7 +27,7 @@ Some implementation details about the fi uses all synchronous call except :c:func:`request_firmware_into_buf`. * If an asynchronous call is used the firmware cache is only set up for a - device if if the second argument (uevent) to request_firmware_nowait() is + device if the second argument (uevent) to request_firmware_nowait() is true. When uevent is true it requests that a kobject uevent be sent to userspace for the firmware request through the sysfs fallback mechanism if the firmware file is not found.
[PATCH 00/17] Documentation/driver-api: eliminate duplicated words
Remove occurrences of duplicated words in Documentation/driver-api/. Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Vinod Koul Cc: dmaeng...@vger.kernel.org Cc: Luis Chamberlain Cc: Greg Kroah-Hartman Cc: William Breathitt Gray Cc: linux-...@vger.kernel.org Cc: Mauro Carvalho Chehab Cc: linux-me...@vger.kernel.org Cc: Jon Mason Cc: Dave Jiang Cc: Allen Hubbe Cc: linux-...@googlegroups.com Cc: Dan Williams Cc: Vishal Verma Cc: Dave Jiang Cc: Ira Weiny Cc: linux-nvd...@lists.01.org Cc: linux-...@vger.kernel.org Cc: Eli Billauer Documentation/driver-api/dmaengine/provider.rst|2 +- Documentation/driver-api/driver-model/platform.rst |2 +- Documentation/driver-api/firmware/built-in-fw.rst |2 +- Documentation/driver-api/firmware/direct-fs-lookup.rst |2 +- Documentation/driver-api/firmware/firmware_cache.rst |2 +- Documentation/driver-api/firmware/request_firmware.rst |2 +- Documentation/driver-api/generic-counter.rst |2 +- Documentation/driver-api/iio/buffers.rst |2 +- Documentation/driver-api/media/cec-core.rst|2 +- Documentation/driver-api/media/dtv-frontend.rst|6 +++--- Documentation/driver-api/media/v4l2-controls.rst |4 ++-- Documentation/driver-api/media/v4l2-dev.rst|2 +- Documentation/driver-api/ntb.rst |2 +- Documentation/driver-api/nvdimm/nvdimm.rst |2 +- Documentation/driver-api/uio-howto.rst |2 +- Documentation/driver-api/usb/URB.rst |2 +- Documentation/driver-api/xillybus.rst |2 +- 17 files changed, 20 insertions(+), 20 deletions(-)
[PATCH 01/17] Documentation/driver-api: dmaengine/provider: drop doubled word
Drop the doubled word "has". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Vinod Koul Cc: dmaeng...@vger.kernel.org --- Documentation/driver-api/dmaengine/provider.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/driver-api/dmaengine/provider.rst +++ linux-next-20200701/Documentation/driver-api/dmaengine/provider.rst @@ -507,7 +507,7 @@ dma_cookie_t DMA_CTRL_ACK - If clear, the descriptor cannot be reused by provider until the - client acknowledges receipt, i.e. has has a chance to establish any + client acknowledges receipt, i.e. has a chance to establish any dependency chains - This can be acked by invoking async_tx_ack()
[GIT PULL] CIFS/SMB3 Fixes
Please pull the following changes since commit 9ebcfadb0610322ac537dd7aa5d9cbc2b2894c68: Linux 5.8-rc3 (2020-06-28 15:00:24 -0700) are available in the Git repository at: git://git.samba.org/sfrench/cifs-2.6.git tags/5.8-rc3-smb3-fixes for you to fetch changes up to 19e888678bac8c82206eb915eaf72741b2a2615c: cifs: prevent truncation from long to int in wait_for_free_credits (2020-07-01 20:01:26 -0500) 8 cifs/smb3 fixes, most for when specifying the multiuser mount flag, 5 of the fixes for stable. Regression test results: http://smb3-test-rhel-75.southcentralus.cloudapp.azure.com/#/builders/2/builds/364 Paul Aurich (6): cifs: Display local UID details for SMB sessions in DebugData SMB3: Honor 'seal' flag for multiuser mounts SMB3: Honor persistent/resilient handle flags for multiuser mounts SMB3: Honor lease disabling for multiuser mounts SMB3: Honor 'handletimeout' flag for multiuser mounts SMB3: Honor 'posix' flag for multiuser mounts Ronnie Sahlberg (1): cifs: prevent truncation from long to int in wait_for_free_credits Zhang Xiaoxu (1): cifs: Fix the target file was deleted when rename failed. fs/cifs/cifs_debug.c | 6 +- fs/cifs/connect.c| 10 ++ fs/cifs/inode.c | 10 -- fs/cifs/transport.c | 2 +- 4 files changed, 20 insertions(+), 8 deletions(-) -- Thanks, Steve
[PATCH V1 5/5] riscv: Add uprobes supported
From: Guo Ren
This patch adds support for uprobes on riscv architecture.
Just like kprobe, it support single-step and simulate instructions.
Signed-off-by: Guo Ren
Cc: Patrick Stählin
Cc: Masami Hiramatsu
Cc: Palmer Dabbelt
Cc: Björn Töpel
---
arch/riscv/Kconfig | 3 +
arch/riscv/include/asm/processor.h | 1 +
arch/riscv/include/asm/thread_info.h | 4 +-
arch/riscv/include/asm/uprobes.h | 40
arch/riscv/kernel/probes/Makefile| 1 +
arch/riscv/kernel/probes/uprobes.c | 186 +++
arch/riscv/kernel/signal.c | 3 +
arch/riscv/kernel/traps.c| 10 ++
arch/riscv/mm/fault.c| 7 ++
9 files changed, 254 insertions(+), 1 deletion(-)
create mode 100644 arch/riscv/include/asm/uprobes.h
create mode 100644 arch/riscv/kernel/probes/uprobes.c
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index a295f0b..f927a91 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -146,6 +146,9 @@ config ARCH_WANT_GENERAL_HUGETLB
config ARCH_SUPPORTS_DEBUG_PAGEALLOC
def_bool y
+config ARCH_SUPPORTS_UPROBES
+ def_bool y
+
config SYS_SUPPORTS_HUGETLBFS
depends on MMU
def_bool y
diff --git a/arch/riscv/include/asm/processor.h
b/arch/riscv/include/asm/processor.h
index bdddcd5..3a24003 100644
--- a/arch/riscv/include/asm/processor.h
+++ b/arch/riscv/include/asm/processor.h
@@ -34,6 +34,7 @@ struct thread_struct {
unsigned long sp; /* Kernel mode stack */
unsigned long s[12];/* s[0]: frame pointer */
struct __riscv_d_ext_state fstate;
+ unsigned long bad_cause;
};
#define INIT_THREAD { \
diff --git a/arch/riscv/include/asm/thread_info.h
b/arch/riscv/include/asm/thread_info.h
index 1dd12a0..b3a7eb6 100644
--- a/arch/riscv/include/asm/thread_info.h
+++ b/arch/riscv/include/asm/thread_info.h
@@ -76,6 +76,7 @@ struct thread_info {
#define TIF_SYSCALL_TRACEPOINT 6 /* syscall tracepoint instrumentation
*/
#define TIF_SYSCALL_AUDIT 7 /* syscall auditing */
#define TIF_SECCOMP8 /* syscall secure computing */
+#define TIF_UPROBE 9 /* uprobe breakpoint or singlestep */
#define _TIF_SYSCALL_TRACE (1 << TIF_SYSCALL_TRACE)
#define _TIF_NOTIFY_RESUME (1 << TIF_NOTIFY_RESUME)
@@ -84,9 +85,10 @@ struct thread_info {
#define _TIF_SYSCALL_TRACEPOINT(1 << TIF_SYSCALL_TRACEPOINT)
#define _TIF_SYSCALL_AUDIT (1 << TIF_SYSCALL_AUDIT)
#define _TIF_SECCOMP (1 << TIF_SECCOMP)
+#define _TIF_UPROBE(1 << TIF_UPROBE)
#define _TIF_WORK_MASK \
- (_TIF_NOTIFY_RESUME | _TIF_SIGPENDING | _TIF_NEED_RESCHED)
+ (_TIF_NOTIFY_RESUME | _TIF_SIGPENDING | _TIF_NEED_RESCHED | _TIF_UPROBE)
#define _TIF_SYSCALL_WORK \
(_TIF_SYSCALL_TRACE | _TIF_SYSCALL_TRACEPOINT | _TIF_SYSCALL_AUDIT | \
diff --git a/arch/riscv/include/asm/uprobes.h b/arch/riscv/include/asm/uprobes.h
new file mode 100644
index ..f2183e0
--- /dev/null
+++ b/arch/riscv/include/asm/uprobes.h
@@ -0,0 +1,40 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef _ASM_RISCV_UPROBES_H
+#define _ASM_RISCV_UPROBES_H
+
+#include
+#include
+#include
+
+#define MAX_UINSN_BYTES8
+
+#ifdef CONFIG_RISCV_ISA_C
+#define UPROBE_SWBP_INSN __BUG_INSN_16
+#define UPROBE_SWBP_INSN_SIZE 2
+#else
+#define UPROBE_SWBP_INSN __BUG_INSN_32
+#define UPROBE_SWBP_INSN_SIZE 4
+#endif
+#define UPROBE_XOL_SLOT_BYTES MAX_UINSN_BYTES
+
+typedef u32 uprobe_opcode_t;
+
+struct arch_uprobe_task {
+ unsigned long saved_cause;
+};
+
+struct arch_uprobe {
+ union {
+ u8 insn[MAX_UINSN_BYTES];
+ u8 ixol[MAX_UINSN_BYTES];
+ };
+ struct arch_probe_insn api;
+ unsigned long insn_size;
+ bool simulate;
+};
+
+bool uprobe_breakpoint_handler(struct pt_regs *regs);
+bool uprobe_single_step_handler(struct pt_regs *regs);
+
+#endif /* _ASM_RISCV_UPROBES_H */
diff --git a/arch/riscv/kernel/probes/Makefile
b/arch/riscv/kernel/probes/Makefile
index 8a39507..cb62991 100644
--- a/arch/riscv/kernel/probes/Makefile
+++ b/arch/riscv/kernel/probes/Makefile
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_KPROBES) += kprobes.o decode-insn.o simulate-insn.o
obj-$(CONFIG_KPROBES) += kprobes_trampoline.o
+obj-$(CONFIG_UPROBES) += uprobes.o decode-insn.o simulate-insn.o
CFLAGS_REMOVE_simulate-insn.o = $(CC_FLAGS_FTRACE)
diff --git a/arch/riscv/kernel/probes/uprobes.c
b/arch/riscv/kernel/probes/uprobes.c
new file mode 100644
index ..7a057b5
--- /dev/null
+++ b/arch/riscv/kernel/probes/uprobes.c
@@ -0,0 +1,186 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include
+#include
+#include
+
+#include "decode-insn.h"
+
+#define UPROBE_TRAP_NR UINT_MAX
+
+bool is_swbp_insn(uprobe_opcode_t *insn)
+{
+#ifdef CONFIG_RISCV_ISA_C
+ return
[PATCH V1 4/5] riscv: Add kprobes supported
From: Guo Ren
This patch enables "kprobe & kretprobe" to work with ftrace
interface. It utilized software breakpoint as single-step
mechanism.
Some instructions which can't be single-step executed must be
simulated in kernel execution slot, such as: branch, jal, auipc,
la ...
Some instructions should be rejected for probing and we use a
blacklist to filter, such as: ecall, ebreak, ...
We use ebreak & c.ebreak to replace origin instruction and the
kprobe handler prepares an executable memory slot for out-of-line
execution with a copy of the original instruction being probed.
In execution slot we add ebreak behind original instruction to
simulate a single-setp mechanism.
The patch is based on packi's work [1] and csky's work [2].
- The kprobes_trampoline.S is all from packi's patch
- The single-step mechanism is new designed for riscv without hw
single-step trap
- The simulation codes are from csky
- Frankly, all codes refer to other archs' implementation
[1] https://lore.kernel.org/linux-riscv/20181113195804.22825-1...@packi.ch/
[2]
https://lore.kernel.org/linux-csky/20200403044150.20562-9-guo...@kernel.org/
Signed-off-by: Guo Ren
Co-Developed-by: Patrick Stählin
Cc: Patrick Stählin
Cc: Masami Hiramatsu
Cc: Palmer Dabbelt
Cc: Björn Töpel
---
arch/riscv/Kconfig| 2 +
arch/riscv/include/asm/kprobes.h | 40 +++
arch/riscv/include/asm/probes.h | 24 ++
arch/riscv/kernel/Makefile| 1 +
arch/riscv/kernel/probes/Makefile | 4 +
arch/riscv/kernel/probes/decode-insn.c| 48 +++
arch/riscv/kernel/probes/decode-insn.h| 18 +
arch/riscv/kernel/probes/kprobes.c| 471 ++
arch/riscv/kernel/probes/kprobes_trampoline.S | 93 +
arch/riscv/kernel/probes/simulate-insn.c | 85 +
arch/riscv/kernel/probes/simulate-insn.h | 47 +++
arch/riscv/kernel/traps.c | 9 +
arch/riscv/mm/fault.c | 4 +
13 files changed, 846 insertions(+)
create mode 100644 arch/riscv/include/asm/probes.h
create mode 100644 arch/riscv/kernel/probes/Makefile
create mode 100644 arch/riscv/kernel/probes/decode-insn.c
create mode 100644 arch/riscv/kernel/probes/decode-insn.h
create mode 100644 arch/riscv/kernel/probes/kprobes.c
create mode 100644 arch/riscv/kernel/probes/kprobes_trampoline.S
create mode 100644 arch/riscv/kernel/probes/simulate-insn.c
create mode 100644 arch/riscv/kernel/probes/simulate-insn.h
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 58d6f66..a295f0b 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -57,6 +57,8 @@ config RISCV
select HAVE_EBPF_JIT if MMU
select HAVE_FUTEX_CMPXCHG if FUTEX
select HAVE_GENERIC_VDSO if MMU && 64BIT
+ select HAVE_KPROBES
+ select HAVE_KRETPROBES
select HAVE_PCI
select HAVE_PERF_EVENTS
select HAVE_PERF_REGS
diff --git a/arch/riscv/include/asm/kprobes.h b/arch/riscv/include/asm/kprobes.h
index 56a98ea3..4647d38 100644
--- a/arch/riscv/include/asm/kprobes.h
+++ b/arch/riscv/include/asm/kprobes.h
@@ -11,4 +11,44 @@
#include
+#ifdef CONFIG_KPROBES
+#include
+#include
+#include
+
+#define __ARCH_WANT_KPROBES_INSN_SLOT
+#define MAX_INSN_SIZE 2
+
+#define flush_insn_slot(p) do { } while (0)
+#define kretprobe_blacklist_size 0
+
+#include
+
+struct prev_kprobe {
+ struct kprobe *kp;
+ unsigned int status;
+};
+
+/* Single step context for kprobe */
+struct kprobe_step_ctx {
+ unsigned long ss_pending;
+ unsigned long match_addr;
+};
+
+/* per-cpu kprobe control block */
+struct kprobe_ctlblk {
+ unsigned int kprobe_status;
+ unsigned long saved_status;
+ struct prev_kprobe prev_kprobe;
+ struct kprobe_step_ctx ss_ctx;
+};
+
+void arch_remove_kprobe(struct kprobe *p);
+int kprobe_fault_handler(struct pt_regs *regs, unsigned int trapnr);
+bool kprobe_breakpoint_handler(struct pt_regs *regs);
+bool kprobe_single_step_handler(struct pt_regs *regs);
+void kretprobe_trampoline(void);
+void __kprobes *trampoline_probe_handler(struct pt_regs *regs);
+
+#endif /* CONFIG_KPROBES */
#endif /* _ASM_RISCV_KPROBES_H */
diff --git a/arch/riscv/include/asm/probes.h b/arch/riscv/include/asm/probes.h
new file mode 100644
index ..a787e6d
--- /dev/null
+++ b/arch/riscv/include/asm/probes.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _ASM_RISCV_PROBES_H
+#define _ASM_RISCV_PROBES_H
+
+typedef u32 probe_opcode_t;
+typedef bool (probes_handler_t) (u32 opcode, unsigned long addr, struct
pt_regs *);
+
+/* architecture specific copy of original instruction */
+struct arch_probe_insn {
+ probe_opcode_t *insn;
+ probes_handler_t *handler;
+ /* restore address after simulation */
+ unsigned long restore;
+};
+
+#ifdef CONFIG_KPROBES
+typedef u32 kprobe_opcode_t;
+struct
[PATCH V1 1/5] riscv: Fixup __vdso_gettimeofday broke dynamic ftrace
From: Guo Ren
For linux-5.8-rc1, enable ftrace of riscv will cause boot panic:
[2.388980] Run /sbin/init as init process
[2.529938] init[39]: unhandled signal 4 code 0x1 at 0x003ff449e000
[2.531078] CPU: 0 PID: 39 Comm: init Not tainted 5.8.0-rc1-dirty #13
[2.532719] epc: 003ff449e000 ra : 003ff449e954 sp : 003fffedb900
[2.534005] gp : 000e8528 tp : 003ff449d800 t0 :
001e
[2.534965] t1 : 000a t2 : 003fffedb89e s0 :
003fffedb920
[2.536279] s1 : 003fffedb940 a0 : 003ff43d4b2c a1 :
[2.537334] a2 : 0001 a3 : a4 :
fbad8000
[2.538466] a5 : 003ff449e93a a6 : a7 :
[2.539511] s2 : s3 : 003ff448412c s4 :
0010
[2.541260] s5 : 0016 s6 : 000d0a30 s7 :
003fffedba70
[2.542152] s8 : s9 : s10:
003fffedb960
[2.543335] s11: t3 : t4 :
003fffedb8a0
[2.544471] t5 : t6 :
[2.545730] status: 4020 badaddr: 464c457f cause:
0002
[2.549867] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0004
[2.551267] CPU: 0 PID: 1 Comm: init Not tainted 5.8.0-rc1-dirty #13
[2.552061] Call Trace:
[2.552626] [] walk_stackframe+0x0/0xc4
[2.553486] [] show_stack+0x40/0x4c
[2.553995] [] dump_stack+0x7a/0x98
[2.554615] [] panic+0x114/0x2f4
[2.555395] [] do_exit+0x89c/0x8c2
[2.555949] [] do_group_exit+0x3a/0x90
[2.556715] [] get_signal+0xe2/0x6e6
[2.557388] [] do_notify_resume+0x6a/0x37a
[2.558089] [] ret_from_exception+0x0/0xc
"ra:0x3ff449e954" is the return address of "call _mcount" in the
prologue of __vdso_gettimeofday(). Without proper relocate, pc jmp
to 0x003ff449e000 (vdso map base) with a illegal instruction
trap.
The solution comes from arch/arm64/kernel/vdso/Makefile:
CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_FTRACE) -Os $(CC_FLAGS_SCS)
- CC_FLAGS_SCS is ShadowCallStack feature in Clang and only
implemented for arm64, no use for riscv.
The bug comes from the following commit:
ad5d1122b82f ("riscv: use vDSO common flow to reduce the latency of the
time-related functions")
Signed-off-by: Guo Ren
Cc: Vincent Chen
Cc: Atish Patra
Cc: Palmer Dabbelt
Cc: Alan Kao
Cc: Greentime Hu
---
arch/riscv/kernel/vdso/Makefile | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/riscv/kernel/vdso/Makefile b/arch/riscv/kernel/vdso/Makefile
index 38ba55b..3079935 100644
--- a/arch/riscv/kernel/vdso/Makefile
+++ b/arch/riscv/kernel/vdso/Makefile
@@ -27,6 +27,9 @@ obj-vdso := $(addprefix $(obj)/, $(obj-vdso))
obj-y += vdso.o vdso-syms.o
CPPFLAGS_vdso.lds += -P -C -U$(ARCH)
+# Disable -pg to prevent insert call site
+CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_FTRACE) -Os
+
# Disable gcov profiling for VDSO code
GCOV_PROFILE := n
--
2.7.4
[PATCH V1 2/5] RISC-V: Implement ptrace regs and stack API
From: Patrick Stählin
Needed for kprobes support. Copied and adapted from arm64 code.
Guo Ren fixup pt_regs type for linux-5.8-rc1.
Signed-off-by: Patrick Stählin
Signed-off-by: Guo Ren
---
arch/riscv/Kconfig | 1 +
arch/riscv/include/asm/ptrace.h | 29
arch/riscv/kernel/ptrace.c | 99 +
3 files changed, 129 insertions(+)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 128192e..58d6f66 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -76,6 +76,7 @@ config RISCV
select SPARSE_IRQ
select SYSCTL_EXCEPTION_TRACE
select THREAD_INFO_IN_TASK
+ select HAVE_REGS_AND_STACK_ACCESS_API
config ARCH_MMAP_RND_BITS_MIN
default 18 if 64BIT
diff --git a/arch/riscv/include/asm/ptrace.h b/arch/riscv/include/asm/ptrace.h
index ee49f80..23372bb 100644
--- a/arch/riscv/include/asm/ptrace.h
+++ b/arch/riscv/include/asm/ptrace.h
@@ -8,6 +8,7 @@
#include
#include
+#include
#ifndef __ASSEMBLY__
@@ -60,6 +61,7 @@ struct pt_regs {
#define user_mode(regs) (((regs)->status & SR_PP) == 0)
+#define MAX_REG_OFFSET offsetof(struct pt_regs, orig_a0)
/* Helpers for working with the instruction pointer */
static inline unsigned long instruction_pointer(struct pt_regs *regs)
@@ -85,6 +87,12 @@ static inline void user_stack_pointer_set(struct pt_regs
*regs,
regs->sp = val;
}
+/* Valid only for Kernel mode traps. */
+static inline unsigned long kernel_stack_pointer(struct pt_regs *regs)
+{
+ return regs->sp;
+}
+
/* Helpers for working with the frame pointer */
static inline unsigned long frame_pointer(struct pt_regs *regs)
{
@@ -101,6 +109,27 @@ static inline unsigned long regs_return_value(struct
pt_regs *regs)
return regs->a0;
}
+extern int regs_query_register_offset(const char *name);
+extern unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs,
+ unsigned int n);
+
+/**
+ * regs_get_register() - get register value from its offset
+ * @regs: pt_regs from which register value is gotten
+ * @offset:offset of the register.
+ *
+ * regs_get_register returns the value of a register whose offset from @regs.
+ * The @offset is the offset of the register in struct pt_regs.
+ * If @offset is bigger than MAX_REG_OFFSET, this returns 0.
+ */
+static inline unsigned long regs_get_register(struct pt_regs *regs,
+ unsigned int offset)
+{
+ if (unlikely(offset > MAX_REG_OFFSET))
+ return 0;
+
+ return *(unsigned long *)((unsigned long)regs + offset);
+}
#endif /* __ASSEMBLY__ */
#endif /* _ASM_RISCV_PTRACE_H */
diff --git a/arch/riscv/kernel/ptrace.c b/arch/riscv/kernel/ptrace.c
index 444dc7b..a11c692 100644
--- a/arch/riscv/kernel/ptrace.c
+++ b/arch/riscv/kernel/ptrace.c
@@ -125,6 +125,105 @@ const struct user_regset_view
*task_user_regset_view(struct task_struct *task)
return _user_native_view;
}
+struct pt_regs_offset {
+ const char *name;
+ int offset;
+};
+
+#define REG_OFFSET_NAME(r) {.name = #r, .offset = offsetof(struct pt_regs, r)}
+#define REG_OFFSET_END {.name = NULL, .offset = 0}
+
+static const struct pt_regs_offset regoffset_table[] = {
+ REG_OFFSET_NAME(epc),
+ REG_OFFSET_NAME(ra),
+ REG_OFFSET_NAME(sp),
+ REG_OFFSET_NAME(gp),
+ REG_OFFSET_NAME(tp),
+ REG_OFFSET_NAME(t0),
+ REG_OFFSET_NAME(t1),
+ REG_OFFSET_NAME(t2),
+ REG_OFFSET_NAME(s0),
+ REG_OFFSET_NAME(s1),
+ REG_OFFSET_NAME(a0),
+ REG_OFFSET_NAME(a1),
+ REG_OFFSET_NAME(a2),
+ REG_OFFSET_NAME(a3),
+ REG_OFFSET_NAME(a4),
+ REG_OFFSET_NAME(a5),
+ REG_OFFSET_NAME(a6),
+ REG_OFFSET_NAME(a7),
+ REG_OFFSET_NAME(s2),
+ REG_OFFSET_NAME(s3),
+ REG_OFFSET_NAME(s4),
+ REG_OFFSET_NAME(s5),
+ REG_OFFSET_NAME(s6),
+ REG_OFFSET_NAME(s7),
+ REG_OFFSET_NAME(s8),
+ REG_OFFSET_NAME(s9),
+ REG_OFFSET_NAME(s10),
+ REG_OFFSET_NAME(s11),
+ REG_OFFSET_NAME(t3),
+ REG_OFFSET_NAME(t4),
+ REG_OFFSET_NAME(t5),
+ REG_OFFSET_NAME(t6),
+ REG_OFFSET_NAME(status),
+ REG_OFFSET_NAME(badaddr),
+ REG_OFFSET_NAME(cause),
+ REG_OFFSET_NAME(orig_a0),
+ REG_OFFSET_END,
+};
+
+/**
+ * regs_query_register_offset() - query register offset from its name
+ * @name: the name of a register
+ *
+ * regs_query_register_offset() returns the offset of a register in struct
+ * pt_regs from its name. If the name is invalid, this returns -EINVAL;
+ */
+int regs_query_register_offset(const char *name)
+{
+ const struct pt_regs_offset *roff;
+
+ for (roff = regoffset_table; roff->name != NULL; roff++)
+ if (!strcmp(roff->name, name))
+ return roff->offset;
+ return -EINVAL;
+}
+
+/**
+ * regs_within_kernel_stack()
[PATCH V1 3/5] riscv: Fixup compile error BUILD_BUG_ON failed
From: Guo Ren
Unfortunately, the current code couldn't be compiled:
CC arch/riscv/kernel/patch.o
In file included from ./include/linux/kernel.h:11,
from ./include/linux/list.h:9,
from ./include/linux/preempt.h:11,
from ./include/linux/spinlock.h:51,
from arch/riscv/kernel/patch.c:6:
In function ‘fix_to_virt’,
inlined from ‘patch_map’ at arch/riscv/kernel/patch.c:37:17:
./include/linux/compiler.h:392:38: error: call to ‘__compiletime_assert_205’
declared with attribute error: BUILD_BUG_ON failed: idx >=
__end_of_fixed_addresses
_compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
^
./include/linux/compiler.h:373:4: note: in definition of macro
‘__compiletime_assert’
prefix ## suffix();\
^~
./include/linux/compiler.h:392:2: note: in expansion of macro
‘_compiletime_assert’
_compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
^~~
./include/linux/build_bug.h:39:37: note: in expansion of macro
‘compiletime_assert’
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~
./include/linux/build_bug.h:50:2: note: in expansion of macro ‘BUILD_BUG_ON_MSG’
BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
^~~~
./include/asm-generic/fixmap.h:32:2: note: in expansion of macro ‘BUILD_BUG_ON’
BUILD_BUG_ON(idx >= __end_of_fixed_addresses);
^~~~
Because fix_to_virt(, idx) needs a const value, not a dynamic variable of
reg-a0 or BUILD_BUG_ON failed with "idx >= __end_of_fixed_addresses".
Signed-off-by: Guo Ren
Reviewed-by: Masami Hiramatsu
Cc: Zong Li
---
Changelog V2:
- Use __always_inline as same as fix_to_virt
- Use const "const unsigned int" for 2th param
Signed-off-by: Guo Ren
---
arch/riscv/kernel/patch.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/riscv/kernel/patch.c b/arch/riscv/kernel/patch.c
index d4a64df..3179a4e 100644
--- a/arch/riscv/kernel/patch.c
+++ b/arch/riscv/kernel/patch.c
@@ -20,7 +20,12 @@ struct patch_insn {
};
#ifdef CONFIG_MMU
-static void *patch_map(void *addr, int fixmap)
+/*
+ * The fix_to_virt(, idx) needs a const value (not a dynamic variable of
+ * reg-a0) or BUILD_BUG_ON failed with "idx >= __end_of_fixed_addresses".
+ * So use '__always_inline' and 'const unsigned int fixmap' here.
+ */
+static __always_inline void *patch_map(void *addr, const unsigned int fixmap)
{
uintptr_t uintaddr = (uintptr_t) addr;
struct page *page;
@@ -37,7 +42,6 @@ static void *patch_map(void *addr, int fixmap)
return (void *)set_fixmap_offset(fixmap, page_to_phys(page) +
(uintaddr & ~PAGE_MASK));
}
-NOKPROBE_SYMBOL(patch_map);
static void patch_unmap(int fixmap)
{
--
2.7.4
[PATCH V1 0/5] riscv: Add k/uprobe supported
From: Guo Ren The patchset includes kprobe/uprobe support and some related fixups. Patrick provides HAVE_REGS_AND_STACK_ACCESS_API support and some kprobe's code. The framework of k/uprobe is from csky but also refers to other arches'. There is no single step exception in riscv ISA, so utilize ebreak to simulate. Some pc related instructions couldn't be executed out of line and some system/fence instructions couldn't be a trace site at all. So we give out a reject list and simulate list in decode-insn.c. You could use uprobe to test simulate code like this: echo 'p:enter_current_state_one /hello:0x6e4 a0=%a0 a1=%a1' >> /sys/kernel/debug/tracing/uprobe_events echo 1 > /sys/kernel/debug/tracing/events/uprobes/enable /hello ^C cat /sys/kernel/debug/tracing/trace tracer: nop entries-in-buffer/entries-written: 1/1 #P:1 _-=> irqs-off / _=> need-resched | / _---=> hardirq/softirq || / _--=> preempt-depth ||| / delay TASK-PID CPU# TIMESTAMP FUNCTION | | | | | hello-94[000] d...55.404242: enter_current_state_one: (0x106e4) a0=0x1 a1=0x3fffa8ada8 Be care /hello:0x6e4 is the file offset in elf and it relate to 0x106e4 in memory and hello is your target elf program. Try kprobe like this: echo 'p:myprobe _do_fork dfd=%a0 filename=%a1 flags=%a2 mode=+4($stack)' > /sys/kernel/debug/tracing/kprobe_events echo 'r:myretprobe _do_fork $retval' >> /sys/kernel/debug/tracing/kprobe_event echo 1 >/sys/kernel/debug/tracing/events/kprobes/enable cat /sys/kernel/debug/tracing/trace tracer: nop entries-in-buffer/entries-written: 2/2 #P:1 _-=> irqs-off / _=> need-resched | / _---=> hardirq/softirq || / _--=> preempt-depth ||| / delay TASK-PID CPU# TIMESTAMP FUNCTION | | | | | sh-92[000] .n.. 131.804230: myprobe: (_do_fork+0x0/0x2e6) dfd=0xffe03929fdf8 filename=0x0 flags=0x101000 mode=0x120ffe0 sh-92[000] d... 131.806607: myretprobe: (__do_sys_clone+0x70/0x82 <- _do_fork) arg1=0x5f cat /sys/kernel/debug/tracing/trace Guo Ren (4): riscv: Fixup __vdso_gettimeofday broke dynamic ftrace riscv: Fixup compile error BUILD_BUG_ON failed riscv: Add kprobes supported riscv: Add uprobes supported Patrick Stählin (1): RISC-V: Implement ptrace regs and stack API arch/riscv/Kconfig| 6 + arch/riscv/include/asm/kprobes.h | 40 +++ arch/riscv/include/asm/probes.h | 24 ++ arch/riscv/include/asm/processor.h| 1 + arch/riscv/include/asm/ptrace.h | 29 ++ arch/riscv/include/asm/thread_info.h | 4 +- arch/riscv/include/asm/uprobes.h | 40 +++ arch/riscv/kernel/Makefile| 1 + arch/riscv/kernel/patch.c | 8 +- arch/riscv/kernel/probes/Makefile | 5 + arch/riscv/kernel/probes/decode-insn.c| 48 +++ arch/riscv/kernel/probes/decode-insn.h| 18 + arch/riscv/kernel/probes/kprobes.c| 471 ++ arch/riscv/kernel/probes/kprobes_trampoline.S | 93 + arch/riscv/kernel/probes/simulate-insn.c | 85 + arch/riscv/kernel/probes/simulate-insn.h | 47 +++ arch/riscv/kernel/probes/uprobes.c| 186 ++ arch/riscv/kernel/ptrace.c| 99 ++ arch/riscv/kernel/signal.c| 3 + arch/riscv/kernel/traps.c | 19 ++ arch/riscv/kernel/vdso/Makefile | 3 + arch/riscv/mm/fault.c | 11 + 22 files changed, 1238 insertions(+), 3 deletions(-) create mode 100644 arch/riscv/include/asm/probes.h create mode 100644 arch/riscv/include/asm/uprobes.h create mode 100644 arch/riscv/kernel/probes/Makefile create mode 100644 arch/riscv/kernel/probes/decode-insn.c create mode 100644 arch/riscv/kernel/probes/decode-insn.h create mode 100644 arch/riscv/kernel/probes/kprobes.c create mode 100644 arch/riscv/kernel/probes/kprobes_trampoline.S create mode 100644 arch/riscv/kernel/probes/simulate-insn.c create mode 100644 arch/riscv/kernel/probes/simulate-insn.h create mode 100644 arch/riscv/kernel/probes/uprobes.c -- 2.7.4
Re: [PATCH v33 11/21] x86/sgx: Linux Enclave Driver
On Wed, Jul 01, 2020 at 08:59:02PM -0700, Sean Christopherson wrote:
> On Thu, Jun 18, 2020 at 01:08:33AM +0300, Jarkko Sakkinen wrote:
> > +static int sgx_validate_secs(const struct sgx_secs *secs,
> > +unsigned long ssaframesize)
> > +{
> > + if (secs->size < (2 * PAGE_SIZE) || !is_power_of_2(secs->size))
> > + return -EINVAL;
> > +
> > + if (secs->base & (secs->size - 1))
> > + return -EINVAL;
> > +
> > + if (secs->miscselect & sgx_misc_reserved_mask ||
> > + secs->attributes & sgx_attributes_reserved_mask ||
> > + secs->xfrm & sgx_xfrm_reserved_mask)
> > + return -EINVAL;
> > +
> > + if (secs->attributes & SGX_ATTR_MODE64BIT) {
> > + if (secs->size > sgx_encl_size_max_64)
> > + return -EINVAL;
> > + } else if (secs->size > sgx_encl_size_max_32)
> > + return -EINVAL;
>
> These should be >=, not >, the SDM uses one of those fancy ≥ ligatures.
>
> Internal versions use more obvious pseudocode, e.g.:
>
> if ((DS:TMP_SECS.ATTRIBUTES.MODE64BIT = 1) AND
> (DS:TMP_SECS.SIZE AND (~((1 << CPUID.18.0:EDX[15:8]) – 1)))
> {
> #GP(0);
Updated as:
static int sgx_validate_secs(const struct sgx_secs *secs)
{
u64 max_size = (secs->attributes & SGX_ATTR_MODE64BIT) ?
sgx_encl_size_max_64 : sgx_encl_size_max_32;
if (secs->size < (2 * PAGE_SIZE) || !is_power_of_2(secs->size))
return -EINVAL;
if (secs->base & (secs->size - 1))
return -EINVAL;
if (secs->miscselect & sgx_misc_reserved_mask ||
secs->attributes & sgx_attributes_reserved_mask ||
secs->xfrm & sgx_xfrm_reserved_mask)
return -EINVAL;
if (secs->size >= max_size)
return -EINVAL;
/Jarkko
Re: [PATCH 13/13] Documentation/admin-guide: xfs: drop doubled word
On Fri, Jul 03, 2020 at 08:20:20PM -0700, Randy Dunlap wrote: > Drop the doubled word "for". > > Signed-off-by: Randy Dunlap > Cc: Jonathan Corbet > Cc: linux-...@vger.kernel.org > Cc: Darrick J. Wong > Cc: linux-...@vger.kernel.org Looks good to me, Reviewed-by: Darrick J. Wong --D > --- > Documentation/admin-guide/xfs.rst |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- linux-next-20200701.orig/Documentation/admin-guide/xfs.rst > +++ linux-next-20200701/Documentation/admin-guide/xfs.rst > @@ -133,7 +133,7 @@ When mounting an XFS filesystem, the fol > logbsize must be an integer multiple of the log > stripe unit configured at **mkfs(8)** time. > > - The default value for for version 1 logs is 32768, while the > + The default value for version 1 logs is 32768, while the > default value for version 2 logs is MAX(32768, log_sunit). > >logdev=device and rtdev=device
[PATCH 03/13] Documentation/admin-guide: dm-integrity: drop doubled words
Drop the doubled words "on" and "the". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: dm-de...@redhat.com --- Documentation/admin-guide/device-mapper/dm-integrity.rst |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- linux-next-20200701.orig/Documentation/admin-guide/device-mapper/dm-integrity.rst +++ linux-next-20200701/Documentation/admin-guide/device-mapper/dm-integrity.rst @@ -45,7 +45,7 @@ To use the target for the first time: will format the device 3. unload the dm-integrity target 4. read the "provided_data_sectors" value from the superblock -5. load the dm-integrity target with the the target size +5. load the dm-integrity target with the target size "provided_data_sectors" 6. if you want to use dm-integrity with dm-crypt, load the dm-crypt target with the size "provided_data_sectors" @@ -99,7 +99,7 @@ interleave_sectors:number the superblock is used. meta_device:device - Don't interleave the data and metadata on on device. Use a + Don't interleave the data and metadata on the device. Use a separate device for metadata. buffer_sectors:number
[PATCH 13/13] Documentation/admin-guide: xfs: drop doubled word
Drop the doubled word "for". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Darrick J. Wong Cc: linux-...@vger.kernel.org --- Documentation/admin-guide/xfs.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/admin-guide/xfs.rst +++ linux-next-20200701/Documentation/admin-guide/xfs.rst @@ -133,7 +133,7 @@ When mounting an XFS filesystem, the fol logbsize must be an integer multiple of the log stripe unit configured at **mkfs(8)** time. - The default value for for version 1 logs is 32768, while the + The default value for version 1 logs is 32768, while the default value for version 2 logs is MAX(32768, log_sunit). logdev=device and rtdev=device
[PATCH 10/13] Documentation/admin-guide: intel-speed-select: drop doubled words
Drop the doubled words "that" and "and". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Srinivas Pandruvada Cc: platform-driver-...@vger.kernel.org --- Documentation/admin-guide/pm/intel-speed-select.rst |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- linux-next-20200701.orig/Documentation/admin-guide/pm/intel-speed-select.rst +++ linux-next-20200701/Documentation/admin-guide/pm/intel-speed-select.rst @@ -114,7 +114,7 @@ base performance profile (which is perfo Lock/Unlock status ~~ -Even if there are multiple performance profiles, it is possible that that they +Even if there are multiple performance profiles, it is possible that they are locked. If they are locked, users cannot issue a command to change the performance state. It is possible that there is a BIOS setup to unlock or check with your system vendor. @@ -883,7 +883,7 @@ To enable Intel(R) SST-TF, execute:: enable:success In this case, the option "-a" is optional. If set, it enables Intel(R) SST-TF -feature and also sets the CPUs to high and and low priority using Intel Speed +feature and also sets the CPUs to high and low priority using Intel Speed Select Technology Core Power (Intel(R) SST-CP) features. The CPU numbers passed with "-c" arguments are marked as high priority, including its siblings.
[PATCH 04/13] Documentation/admin-guide: media/building: drop doubled words
Drop some doubled words. Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Mauro Carvalho Chehab Cc: linux-me...@vger.kernel.org --- Documentation/admin-guide/media/building.rst |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- linux-next-20200701.orig/Documentation/admin-guide/media/building.rst +++ linux-next-20200701/Documentation/admin-guide/media/building.rst @@ -90,7 +90,7 @@ built as modules. Those GPU-specific drivers are selected via the ``Graphics support`` menu, under ``Device Drivers``. - When a GPU driver supports supports HDMI CEC, it will automatically + When a GPU driver supports HDMI CEC, it will automatically enable the CEC core support at the media subsystem. Media dependencies @@ -244,7 +244,7 @@ functionality. If you have an hybrid card, you may need to enable both ``Analog TV`` and ``Digital TV`` at the menu. -When using this option, the defaults for the the media support core +When using this option, the defaults for the media support core functionality are usually good enough to provide the basic functionality for the driver. Yet, you could manually enable some desired extra (optional) functionality using the settings under each of the following
[PATCH 07/13] Documentation/admin-guide: pnfs-scsi-server: drop doubled word
Drop the doubled word "with". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Trond Myklebust Cc: Anna Schumaker Cc: linux-...@vger.kernel.org --- Documentation/admin-guide/nfs/pnfs-scsi-server.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/admin-guide/nfs/pnfs-scsi-server.rst +++ linux-next-20200701/Documentation/admin-guide/nfs/pnfs-scsi-server.rst @@ -9,7 +9,7 @@ which in addition to handling all the me also hands out layouts to the clients so that they can directly access the underlying SCSI LUNs that are shared with the client. -To use pNFS SCSI layouts with with the Linux NFS server, the exported file +To use pNFS SCSI layouts with the Linux NFS server, the exported file system needs to support the pNFS SCSI layouts (currently just XFS), and the file system must sit on a SCSI LUN that is accessible to the clients in addition to the MDS. As of now the file system needs to sit directly on the
[PATCH 11/13] Documentation/admin-guide: sysctl/kernel: drop doubled word
Drop the doubled word "set". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org --- Documentation/admin-guide/sysctl/kernel.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/admin-guide/sysctl/kernel.rst +++ linux-next-20200701/Documentation/admin-guide/sysctl/kernel.rst @@ -235,7 +235,7 @@ This toggle indicates whether unprivileg from using ``dmesg(8)`` to view messages from the kernel's log buffer. When ``dmesg_restrict`` is set to 0 there are no restrictions. -When ``dmesg_restrict`` is set set to 1, users must have +When ``dmesg_restrict`` is set to 1, users must have ``CAP_SYSLOG`` to use ``dmesg(8)``. The kernel config option ``CONFIG_SECURITY_DMESG_RESTRICT`` sets the
[PATCH 12/13] Documentation/admin-guide: tainted-kernels: drop doubled word
Drop the doubled word "the".
Signed-off-by: Randy Dunlap
Cc: Jonathan Corbet
Cc: linux-...@vger.kernel.org
---
Documentation/admin-guide/tainted-kernels.rst |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20200701.orig/Documentation/admin-guide/tainted-kernels.rst
+++ linux-next-20200701/Documentation/admin-guide/tainted-kernels.rst
@@ -61,7 +61,7 @@ this on the machine that had the stateme
* Proprietary module was loaded (#0)
* Kernel issued warning (#9)
* Externally-built ('out-of-tree') module was loaded (#12)
- See Documentation/admin-guide/tainted-kernels.rst in the the Linux
kernel or
+ See Documentation/admin-guide/tainted-kernels.rst in the Linux kernel or
https://www.kernel.org/doc/html/latest/admin-guide/tainted-kernels.html for
a more details explanation of the various taint flags.
Raw taint value as int/string: 4609/'PW O '
[PATCH 09/13] Documentation/admin-guide: intel_pstate: drop doubled word
Drop the doubled word "to". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Srinivas Pandruvada Cc: Len Brown Cc: linux...@vger.kernel.org --- Documentation/admin-guide/pm/intel_pstate.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/admin-guide/pm/intel_pstate.rst +++ linux-next-20200701/Documentation/admin-guide/pm/intel_pstate.rst @@ -708,7 +708,7 @@ core (for the policies with other scalin The ``ftrace`` interface can be used for low-level diagnostics of ``intel_pstate``. For example, to check how often the function to set a -P-state is called, the ``ftrace`` filter can be set to to +P-state is called, the ``ftrace`` filter can be set to :c:func:`intel_pstate_set_pstate`:: # cd /sys/kernel/debug/tracing/
[PATCH 06/13] Documentation/admin-guide: pnfs-block-server: drop doubled word
Drop the doubled word "with". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Trond Myklebust Cc: Anna Schumaker Cc: linux-...@vger.kernel.org --- Documentation/admin-guide/nfs/pnfs-block-server.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/admin-guide/nfs/pnfs-block-server.rst +++ linux-next-20200701/Documentation/admin-guide/nfs/pnfs-block-server.rst @@ -8,7 +8,7 @@ to handling all the metadata access to t to the clients to directly access the underlying block devices that are shared with the client. -To use pNFS block layouts with with the Linux NFS server the exported file +To use pNFS block layouts with the Linux NFS server the exported file system needs to support the pNFS block layouts (currently just XFS), and the file system must sit on shared storage (typically iSCSI) that is accessible to the clients in addition to the MDS. As of now the file system needs to
[PATCH 08/13] Documentation/admin-guide: arm-ccn: drop doubled word
Drop the doubled word "as".
Signed-off-by: Randy Dunlap
Cc: Jonathan Corbet
Cc: linux-...@vger.kernel.org
---
Documentation/admin-guide/perf/arm-ccn.rst |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20200701.orig/Documentation/admin-guide/perf/arm-ccn.rst
+++ linux-next-20200701/Documentation/admin-guide/perf/arm-ccn.rst
@@ -27,7 +27,7 @@ Crosspoint PMU events require "xp" (inde
and "vc" (virtual channel ID).
Crosspoint watchpoint-based events (special "event" value 0xfe)
-require "xp" and "vc" as as above plus "port" (device port index),
+require "xp" and "vc" as above plus "port" (device port index),
"dir" (transmit/receive direction), comparator values ("cmp_l"
and "cmp_h") and "mask", being index of the comparator mask.
[PATCH 05/13] Documentation/admin-guide: mm/ksm: drop doubled word
Drop the doubled word "the". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Andrew Morton Cc: linux...@kvack.org --- Documentation/admin-guide/mm/ksm.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/admin-guide/mm/ksm.rst +++ linux-next-20200701/Documentation/admin-guide/mm/ksm.rst @@ -52,7 +52,7 @@ with EAGAIN, but more probably arousing If KSM is not configured into the running kernel, madvise MADV_MERGEABLE and MADV_UNMERGEABLE simply fail with EINVAL. If the running kernel was built with CONFIG_KSM=y, those calls will normally succeed: even if the -the KSM daemon is not currently running, MADV_MERGEABLE still registers +KSM daemon is not currently running, MADV_MERGEABLE still registers the range for whenever the KSM daemon is started; even if the range cannot contain any pages which KSM could actually merge; even if MADV_UNMERGEABLE is applied to a range which was never MADV_MERGEABLE.
[PATCH 02/13] Documentation/admin-guide: cgroup-v1/rdma: drop doubled word
Drop the doubled word "echo". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: cgro...@vger.kernel.org --- Documentation/admin-guide/cgroup-v1/rdma.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/admin-guide/cgroup-v1/rdma.rst +++ linux-next-20200701/Documentation/admin-guide/cgroup-v1/rdma.rst @@ -114,4 +114,4 @@ Following resources can be accounted by (d) Delete resource limit:: - echo echo mlx4_0 hca_handle=max hca_object=max > /sys/fs/cgroup/rdma/1/rdma.max + echo mlx4_0 hca_handle=max hca_object=max > /sys/fs/cgroup/rdma/1/rdma.max
[PATCH 00/13] Documentation/admin-guide: eliminate duplicated words
Remove duplicated words from Documentation/admin-guide/ files. Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: cgro...@vger.kernel.org Cc: dm-de...@redhat.com Cc: Mauro Carvalho Chehab Cc: linux-me...@vger.kernel.org Cc: Andrew Morton Cc: linux...@kvack.org Cc: Trond Myklebust Cc: Anna Schumaker Cc: linux-...@vger.kernel.org Cc: Srinivas Pandruvada Cc: Len Brown Cc: linux...@vger.kernel.org Cc: platform-driver-...@vger.kernel.org Cc: Darrick J. Wong Cc: linux-...@vger.kernel.org Documentation/admin-guide/cgroup-v1/rdma.rst |2 +- Documentation/admin-guide/cgroup-v2.rst |2 +- Documentation/admin-guide/device-mapper/dm-integrity.rst |4 ++-- Documentation/admin-guide/media/building.rst |4 ++-- Documentation/admin-guide/mm/ksm.rst |2 +- Documentation/admin-guide/nfs/pnfs-block-server.rst |2 +- Documentation/admin-guide/nfs/pnfs-scsi-server.rst |2 +- Documentation/admin-guide/perf/arm-ccn.rst |2 +- Documentation/admin-guide/pm/intel-speed-select.rst |4 ++-- Documentation/admin-guide/pm/intel_pstate.rst|2 +- Documentation/admin-guide/sysctl/kernel.rst |2 +- Documentation/admin-guide/tainted-kernels.rst|2 +- Documentation/admin-guide/xfs.rst|2 +- 13 files changed, 16 insertions(+), 16 deletions(-)
[PATCH 01/13] Documentation/admin-guide: cgroup-v2: drop doubled word
Drop the doubled word "of". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: cgro...@vger.kernel.org --- Documentation/admin-guide/cgroup-v2.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/admin-guide/cgroup-v2.rst +++ linux-next-20200701/Documentation/admin-guide/cgroup-v2.rst @@ -2047,7 +2047,7 @@ RDMA The "rdma" controller regulates the distribution and accounting of -of RDMA resources. +RDMA resources. RDMA Interface Files
Re: objtool clac/stac handling change..
On Fri, Jul 3, 2020 at 7:30 PM Al Viro wrote: > > Lovely... So basically this is the rare place where we might use those > insns on userland addresses? Honestly, I think the code you quote is just confused. First off, we have special "is this page fault due to a prefetch" logic in the x86 page fault handler anyway. Second, we probably shouldn't have those prefetches there in the first place. Sp I think the nasty code is likely just pointless and legacy. It may exists simply because that case was the first time somebody noticed the prefetch errata and it triggered in kernel mode. Who knows.. I'd be inclined to remove all the prefetching code from that csum thing entirely. Most good CPU's do better prefetch pattern detection in hardware than we can do in software. Linus
Re: mmotm 2020-07-03-15-03 uploaded (drivers/soc/qcom/qcom-geni-se.c)
On 7/3/20 3:04 PM, a...@linux-foundation.org wrote: > The mm-of-the-moment snapshot 2020-07-03-15-03 has been uploaded to > >http://www.ozlabs.org/~akpm/mmotm/ > > mmotm-readme.txt says > > README for mm-of-the-moment: > > http://www.ozlabs.org/~akpm/mmotm/ > > This is a snapshot of my -mm patch queue. Uploaded at random hopefully > more than once a week. > This patch from 2020-June-29 is (still) needed to fix some build errors in drivers/soc/qcom/qcom-geni-se.c: https://lore.kernel.org/lkml/ce0d7561-ff93-d267-b57a-6505014c7...@infradead.org/ The patch provides a stub for of_get_next_parent(). -- ~Randy
Re: [PATCH 09/16] initrd: remove the BLKFLSBUF call in handle_initrd
On July 3, 2020 5:18:48 PM PDT, antlists wrote:
>On 03/07/2020 04:40, H. Peter Anvin wrote:
>> On 2020-06-15 05:53, Christoph Hellwig wrote:
>>> BLKFLSBUF used to be overloaded for the ramdisk driver to free the
>whole
>>> ramdisk, which was completely different behavior compared to all
>other
>>> drivers. But this magic overload got removed in commit ff26956875c2
>>> ("brd: remove support for BLKFLSBUF"), so this call is entirely
>>> pointless now.
>>>
>>> Signed-off-by: Christoph Hellwig
>>
>> Does *anyone* use initrd as opposed to initramfs anymore? It would
>seem
>> like a good candidate for deprecation/removal.
>>
>Reading the gentoo mailing list, it seems there's a fair few people who
>
>don't use initramfs. I get the impression they don't use initrd either,
>
>though.
>
>I don't know too much about booting without an initramfs - I switched
>ages ago - so what is possible and what they're actually doing, I don't
>
>know.
>
>Cheers,
>Wol
Not using any init userspace at all is an entirely different issue.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: objtool clac/stac handling change..
On Fri, Jul 03, 2020 at 06:54:15PM -0700, Linus Torvalds wrote: > "Software Prefetches May Report A Page Fault > > Description Software prefetch instructions are defined to ignore > page faults. Under highly specific and detailed internal > circumstances, a prefetch instruction may report a page fault if both > of the following conditions are true: > >• The target address of the prefetch would cause a page fault if > the address was accessed by an actual memory load or store instruction > under the current privilege mode; > >• The prefetch instruction is followed in execution-order by an > actual or speculative byte-sized memory access of the same > modify-intent to the same address. PREFETCH and PREFETCHNTA/0/1/2 have > the same modify-intent as a memory load access. > > PREFETCHW has the same modify-intent as a memory store access. The > page fault exception error code bits for the faulting prefetch will be > identical to that for a bytesized memory access of the same-modify > intent to the same address. Note that some misaligned accesses can be > broken up by the processor into multiple accesses where at least one > of the accesses is a byte-sized access. If the target address of the > subsequent memory access of the same modify-intent is aligned and not > byte-sized, this errata does not occur and no workaround is needed. > > Potential Effect on System An unexpected page fault may occur > infrequently on a prefetch instruction." Lovely... So basically this is the rare place where we might use those insns on userland addresses?
Re: objtool clac/stac handling change..
On Sat, Jul 04, 2020 at 01:49:59AM +0100, Al Viro wrote:
> On Fri, Jul 03, 2020 at 10:02:37PM +0100, Al Viro wrote:
>
> > PS: I'm still going through the _ASM_EXTABLE... users on x86, so there
> > might be more fun. Will post when I'm done...
>
> Lovely... Not directly related to that, but... WTF?
>
> arch/x86/lib/csum-copy_64.S:
>
> /*
> * No _ASM_EXTABLE_UA; this is used for intentional prefetch on a
> * potentially unmapped kernel address.
> */
> .macro ignore L=.Lignore
> 30:
> _ASM_EXTABLE(30b, \L)
> .endm
>
> ...
> ignore 2f
> prefetcht0 5*64(%rdi)
> 2:
>
> (and no other users of 'ignore' anywhere). How could prefetcht0 possibly
> raise an exception? Intel manual says that the only exception is #UD if
> LOCK PREFETCHT0 is encountered; not here, obviously. AMD manual simply
> says "no exceptions". Confused...
>
> Incidentally, in the same file:
> SYM_FUNC_START(csum_partial_copy_generic)
> cmpl$3*64, %edx
> jle .Lignore
>
> .Lignore:
>
>
> And it had been that way since "[PATCH] Intel x86-64 support merge" back
> in 2004, where we had
> @@ -59,15 +59,6 @@ csum_partial_copy_generic:
> cmpl $3*64,%edx
> jle .Lignore
>
> - ignore
> - prefetch (%rdi)
> - ignore
> - prefetch 1*64(%rdi)
> - ignore
> - prefetchw (%rsi)
> - ignore
> - prefetchw 1*64(%rsi)
> -
> .Lignore:
>
> @@ -115,7 +106,7 @@ csum_partial_copy_generic:
> movq 56(%rdi),%r13
>
> ignore 2f
> - prefetch 5*64(%rdi)
> + prefetcht0 5*64(%rdi)
> 2:
> adcq %rbx,%rax
> adcq %r8,%rax
>
> What's going on in there? According to AMD manual, prefetch and prefetchw
> can raise an exception (#UD), if
> PREFETCH/PREFETCHW are not supported, as
>indicated by ECX bit 8 of CPUID function
>8000_0001h
> Long Mode is not supported, as indicated by EDX
>bit 29 of CPUID function 8000_0001h
> The 3DNow! instructions are not supported, as
>indicated by EDX bit 31 of CPUID function
>8000_0001h.
> so these at least used to make some sense, but why leave that thing at
> the place where old prefetch became prefetcht0 and what is that comment
> in front of 'ignore' definition about? Exceptions there had never
> been about unmapped addresses - that would make no sense for prefetch.
>
> What am I missing here?
BTW, looking at csum_and_copy_{to,from}_user() callers (all 3 of them,
all in lib/iov_iter.c) we have this:
1) len is never 0
2) sum (initial value of csum) is always 0
3) failure (reported via *err_ptr) is always treateds as "discard
the entire iovec segment (and possibly the entire iovec)". Exact value
put into *err_ptr doesn't matter (it's only compared to 0) and in case of
error the return value is ignored.
Now, using ~0U instead of 0 for initial sum would yield an equivalent csum
(comparable modulo 2^16-1) *AND* never yield 0 (recall how csum addition works).
IOW, we could simply return 0 to indicate an error. Which gives much saner
calling conventions:
__wsum csum_and_copy_from_user(const void __user *src, void *dst, int len)
copying the damn thing and returning 0 on error or a non-zero value comparable
to csum of the data modulo 2^16-1 on success. Same for csum_and_copy_to_user()
(modulo const and __user being on the other argument).
For x86 it simplifies the instances (both the inline wrappers and asm parts);
I hadn't checked the other architectures yet, but it looks like that should
be doable for all architectures. And it does simplify the callers...
Re: objtool clac/stac handling change..
On Fri, Jul 3, 2020 at 5:50 PM Al Viro wrote: > > How could prefetcht0 possibly > raise an exception? Intel manual says that the only exception is #UD if > LOCK PREFETCHT0 is encountered; not here, obviously. AMD manual simply > says "no exceptions". Confused... Several CPU bugs in this area. I think they may all have been AMD. But we've definitely had "prefetch causes page faults" errata. Google for it. One pdf (AMD errata) I found had this: "Software Prefetches May Report A Page Fault Description Software prefetch instructions are defined to ignore page faults. Under highly specific and detailed internal circumstances, a prefetch instruction may report a page fault if both of the following conditions are true: • The target address of the prefetch would cause a page fault if the address was accessed by an actual memory load or store instruction under the current privilege mode; • The prefetch instruction is followed in execution-order by an actual or speculative byte-sized memory access of the same modify-intent to the same address. PREFETCH and PREFETCHNTA/0/1/2 have the same modify-intent as a memory load access. PREFETCHW has the same modify-intent as a memory store access. The page fault exception error code bits for the faulting prefetch will be identical to that for a bytesized memory access of the same-modify intent to the same address. Note that some misaligned accesses can be broken up by the processor into multiple accesses where at least one of the accesses is a byte-sized access. If the target address of the subsequent memory access of the same modify-intent is aligned and not byte-sized, this errata does not occur and no workaround is needed. Potential Effect on System An unexpected page fault may occur infrequently on a prefetch instruction." So sadly the architecture manuals do not reflect reality. That said, software prefetch instructions very seldom actually work. They are only useful if you have one _very_ specific load and run one one _very_ specific micrcoarchiecture. Ir's almost always a mistake to have them in the first place. Linus
Re: [PATCH v33 11/21] x86/sgx: Linux Enclave Driver
On Mon, Jun 29, 2020 at 08:27:19AM -0700, Sean Christopherson wrote:
> On Sat, Jun 27, 2020 at 07:43:35PM +0200, Borislav Petkov wrote:
> > On Thu, Jun 18, 2020 at 01:08:33AM +0300, Jarkko Sakkinen wrote:
> > > +static int sgx_encl_init(struct sgx_encl *encl, struct sgx_sigstruct
> > > *sigstruct,
> > > + void *token)
> > > +{
> > > + u64 mrsigner[4];
> > > + int ret;
> > > + int i;
> > > + int j;
> > > +
> > > + /* Check that the required attributes have been authorized. */
> > > + if (encl->secs_attributes & ~encl->allowed_attributes)
> > > + return -EACCES;
> > > +
> > > + ret = sgx_get_key_hash(sigstruct->modulus, mrsigner);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + mutex_lock(>lock);
> > > +
> > > + if (atomic_read(>flags) & SGX_ENCL_INITIALIZED) {
> > > + ret = -EFAULT;
> > > + goto err_out;
> > > + }
> >
> > That test should be the first thing this function or its caller does.
>
> Hmm, I was going to say that SGX_ENCL_INITIALIZED can't be checked until
> encl->lock is held, but that's not true for this path as mutual exclusion
> is provided by the SGX_ENCL_IOCTL flag. So yeah, this can be checked at
> the same time as SGX_ENCL_CREATED in sgx_ioc_enclave_init().
>
> > > + for (i = 0; i < SGX_EINIT_SLEEP_COUNT; i++) {
> > > + for (j = 0; j < SGX_EINIT_SPIN_COUNT; j++) {
> >
> > Ew, what's that double-loop for?
> >
> > It tries to init an enclave a bunch of times. Why does it need to init
> > more than once?
>
> ENCLS[EINIT] is interruptible because it has such a high latency, e.g. 50k+
> cycles on success. If an IRQ/NMI/SMI becomes pending, EINIT may fail with
> SGX_UNMASKED_EVENT so that the event can be serviced.
>
> The idea behind the double loop is to try EINIT in a tight loop, then back
> off and sleep for a while before retrying that tight inner loop.
>
> > > + ret = sgx_einit(sigstruct, token, encl->secs.epc_page,
> > > + mrsigner);
> > > + if (ret == SGX_UNMASKED_EVENT)
> > > + continue;
> > > + else
> > > + break;
> > > + }
> > > +
> > > + if (ret != SGX_UNMASKED_EVENT)
> > > + break;
> > > +
> > > + msleep_interruptible(SGX_EINIT_SLEEP_TIME);
> > > +
> > > + if (signal_pending(current)) {
> > > + ret = -ERESTARTSYS;
> > > + goto err_out;
> > > + }
> > > + }
> > > +
> > > + if (ret & ENCLS_FAULT_FLAG) {
> > > + if (encls_failed(ret))
> > > + ENCLS_WARN(ret, "EINIT");
> > > +
> > > + sgx_encl_destroy(encl);
> > > + ret = -EFAULT;
> > > + } else if (ret) {
> > > + pr_debug("EINIT returned %d\n", ret);
> > > + ret = -EPERM;
> > > + } else {
> > > + atomic_or(SGX_ENCL_INITIALIZED, >flags);
> > > + }
> > > +
> > > +err_out:
> > > + mutex_unlock(>lock);
> > > + return ret;
> > > +}
> > > +
> > > +/**
> > > + * sgx_ioc_enclave_init - handler for %SGX_IOC_ENCLAVE_INIT
> > > + *
> > > + * @filep: open file to /dev/sgx
> >
> > @encl: pointer to an enclave instance (via ioctl() file pointer)
> >
> > > + * @arg: userspace pointer to a struct sgx_enclave_init instance
> > > + *
> > > + * Flush any outstanding enqueued EADD operations and perform EINIT. The
> > > + * Launch Enclave Public Key Hash MSRs are rewritten as necessary to
> > > match
> > > + * the enclave's MRSIGNER, which is caculated from the provided
> > > sigstruct.
> > > + *
> > > + * Return:
> > > + * 0 on success,
> > > + * SGX error code on EINIT failure,
> > > + * -errno otherwise
> > > + */
> > > +static long sgx_ioc_enclave_init(struct sgx_encl *encl, void __user *arg)
> > > +{
> > > + struct sgx_sigstruct *sigstruct;
> > > + struct sgx_enclave_init einit;
> > > + struct page *initp_page;
> > > + void *token;
> > > + int ret;
> > > +
> > > + if (!(atomic_read(>flags) & SGX_ENCL_CREATED))
> >
> > Might just as well check the other flags: doing EINIT on an already
> > initialized enclave - SGX_ENCL_INITIALIZED - is perhaps a nono or
> > similarly on a SGX_ENCL_DEAD enclave.
> >
> > And you could do similar sanity checks in the other ioctl functions.
>
> Ya, as above, SGX_ENCL_INITIALIZED can be checked here.
>
> SGX_ENCL_DEAD is actually already checked in in the top level sgx_ioctl(),
> i.e. the check in sgx_encl_add_page() can technically be flat out dropped.
>
> I say "technically" because I'm a bit torn over SGX_ENCL_DEAD; encl->lock
> must be held to SGX_ENCL_DEAD (the page fault and reclaim flows rely on
> this), but as it stands today only ioctl() paths (guarded by SGX_ENCL_IOCTL)
> and sgx_release() (makes the ioctls() unreachable) set SGX_ENCL_DEAD.
>
> So it's safe to check SGX_ENCL_DEAD from ioctl() context without holding
> encl->lock, at least in the current code base, but it feels weird/sketchy.
>
> In the end I don't think I have a strong
Re: [PATCH v33 11/21] x86/sgx: Linux Enclave Driver
On Sat, Jun 27, 2020 at 07:43:35PM +0200, Borislav Petkov wrote:
> On Thu, Jun 18, 2020 at 01:08:33AM +0300, Jarkko Sakkinen wrote:
> > +static int sgx_encl_init(struct sgx_encl *encl, struct sgx_sigstruct
> > *sigstruct,
> > +void *token)
> > +{
> > + u64 mrsigner[4];
> > + int ret;
> > + int i;
> > + int j;
> > +
> > + /* Check that the required attributes have been authorized. */
> > + if (encl->secs_attributes & ~encl->allowed_attributes)
> > + return -EACCES;
> > +
> > + ret = sgx_get_key_hash(sigstruct->modulus, mrsigner);
> > + if (ret)
> > + return ret;
> > +
> > + mutex_lock(>lock);
> > +
> > + if (atomic_read(>flags) & SGX_ENCL_INITIALIZED) {
> > + ret = -EFAULT;
> > + goto err_out;
> > + }
>
> That test should be the first thing this function or its caller does.
Fixed.
>
> > + for (i = 0; i < SGX_EINIT_SLEEP_COUNT; i++) {
> > + for (j = 0; j < SGX_EINIT_SPIN_COUNT; j++) {
>
> Ew, what's that double-loop for?
>
> It tries to init an enclave a bunch of times. Why does it need to init
> more than once?
>From SDM:
"Periodically, EINIT polls for certain asynchronous events. If such an
event is detected, it completes with failure code (ZF=1 and RAX =
SGX_UNMASKED_EVENT), and RIP is incremented to point to the next
instruction. These events includes external interrupts, non-maskable
interrupts, system-management interrupts, machine checks, INIT signals,
and the VMX-preemption timer. EINIT does not fail if the pending event
is inhibited (e.g., external interrupts could be inhibited due to
blocking by MOV SS blocking or by STI)."
Not exactly sure though why this must be polled inside the kernel though.
>
> > + ret = sgx_einit(sigstruct, token, encl->secs.epc_page,
> > + mrsigner);
> > + if (ret == SGX_UNMASKED_EVENT)
> > + continue;
> > + else
> > + break;
> > + }
> > +
> > + if (ret != SGX_UNMASKED_EVENT)
> > + break;
> > +
> > + msleep_interruptible(SGX_EINIT_SLEEP_TIME);
> > +
> > + if (signal_pending(current)) {
> > + ret = -ERESTARTSYS;
> > + goto err_out;
> > + }
> > + }
> > +
> > + if (ret & ENCLS_FAULT_FLAG) {
> > + if (encls_failed(ret))
> > + ENCLS_WARN(ret, "EINIT");
> > +
> > + sgx_encl_destroy(encl);
> > + ret = -EFAULT;
> > + } else if (ret) {
> > + pr_debug("EINIT returned %d\n", ret);
> > + ret = -EPERM;
> > + } else {
> > + atomic_or(SGX_ENCL_INITIALIZED, >flags);
> > + }
> > +
> > +err_out:
> > + mutex_unlock(>lock);
> > + return ret;
> > +}
> > +
> > +/**
> > + * sgx_ioc_enclave_init - handler for %SGX_IOC_ENCLAVE_INIT
> > + *
> > + * @filep: open file to /dev/sgx
>
> @encl: pointer to an enclave instance (via ioctl() file pointer)
>
> > + * @arg: userspace pointer to a struct sgx_enclave_init instance
> > + *
> > + * Flush any outstanding enqueued EADD operations and perform EINIT. The
> > + * Launch Enclave Public Key Hash MSRs are rewritten as necessary to match
> > + * the enclave's MRSIGNER, which is caculated from the provided sigstruct.
> > + *
> > + * Return:
> > + * 0 on success,
> > + * SGX error code on EINIT failure,
> > + * -errno otherwise
> > + */
> > +static long sgx_ioc_enclave_init(struct sgx_encl *encl, void __user *arg)
> > +{
> > + struct sgx_sigstruct *sigstruct;
> > + struct sgx_enclave_init einit;
> > + struct page *initp_page;
> > + void *token;
> > + int ret;
> > +
> > + if (!(atomic_read(>flags) & SGX_ENCL_CREATED))
>
> Might just as well check the other flags: doing EINIT on an already
> initialized enclave - SGX_ENCL_INITIALIZED - is perhaps a nono or
> similarly on a SGX_ENCL_DEAD enclave.
>
> And you could do similar sanity checks in the other ioctl functions.
Agreed (see my earlier response, let's continue this discussion there).
/Jarkko
[tip:master] BUILD SUCCESS a282cddefe90c4b21ef2c22a76a7c3ebd3ec6b86
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git master branch HEAD: a282cddefe90c4b21ef2c22a76a7c3ebd3ec6b86 Merge branch 'WIP.core/headers' elapsed time: 2145m configs tested: 102 configs skipped: 5 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm allyesconfig arm allmodconfig arm allnoconfig arm64allyesconfig arm64 defconfig arm64allmodconfig arm64 allnoconfig arm pxa3xx_defconfig arm imx_v6_v7_defconfig powerpc ppc6xx_defconfig mips ath25_defconfig ia64 allyesconfig arm efm32_defconfig sh alldefconfig powerpcmvme5100_defconfig mips rb532_defconfig xtensa iss_defconfig h8300 defconfig mips maltasmvp_eva_defconfig ia64generic_defconfig microblazenommu_defconfig s390 allnoconfig pariscgeneric-64bit_defconfig mipsjmr3927_defconfig mips decstation_r4k_defconfig i386 allnoconfig i386 allyesconfig i386defconfig i386 debian-10.3 ia64 allmodconfig ia64defconfig ia64 allnoconfig m68k allmodconfig m68k allnoconfig m68k sun3_defconfig m68kdefconfig m68k allyesconfig nios2 defconfig nios2allyesconfig openriscdefconfig c6x allyesconfig c6x allnoconfig openrisc allyesconfig nds32 defconfig nds32 allnoconfig csky allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig h8300allmodconfig xtensa defconfig arc defconfig arc allyesconfig sh allmodconfig shallnoconfig microblazeallnoconfig mips allyesconfig mips allnoconfig mips allmodconfig pariscallnoconfig parisc defconfig parisc allyesconfig parisc allmodconfig powerpc defconfig powerpc allyesconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a002-20200701 i386 randconfig-a001-20200701 i386 randconfig-a006-20200701 i386 randconfig-a005-20200701 i386 randconfig-a004-20200701 i386 randconfig-a003-20200701 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig s390 allyesconfig s390 allmodconfig s390defconfig sparcallyesconfig sparc defconfig sparc64 defconfig sparc64 allnoconfig sparc64 allyesconfig sparc64 allmodconfig um allmodconfig umallnoconfig um defconfig um allyesconfig x86_64 rhel-7.6 x86_64rhel-7.6-kselftests x86_64 rhel-8.3 x86_64 kexec x86_64 rhel x86_64 rhel-7.2-clear x86_64lkp x86_64
[tip:auto-latest] BUILD SUCCESS 7e44a91e0445a854af5d34ca0f5baceccd518e73
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git auto-latest branch HEAD: 7e44a91e0445a854af5d34ca0f5baceccd518e73 Merge branch 'core/urgent' elapsed time: 2132m configs tested: 106 configs skipped: 6 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm allyesconfig arm allmodconfig arm allnoconfig arm64allyesconfig arm64 defconfig arm64allmodconfig arm64 allnoconfig arm pxa3xx_defconfig arm imx_v6_v7_defconfig powerpc ppc6xx_defconfig mips ath25_defconfig ia64 allyesconfig arm efm32_defconfig sh alldefconfig powerpcmvme5100_defconfig mips rb532_defconfig xtensa iss_defconfig h8300 defconfig powerpc mpc885_ads_defconfig arm milbeaut_m10v_defconfig shdreamcast_defconfig openriscor1ksim_defconfig mips maltasmvp_eva_defconfig ia64generic_defconfig s390 allnoconfig microblazenommu_defconfig pariscgeneric-64bit_defconfig mipsjmr3927_defconfig mips decstation_r4k_defconfig i386 allnoconfig i386 allyesconfig i386defconfig i386 debian-10.3 ia64 allmodconfig ia64defconfig ia64 allnoconfig m68k allmodconfig m68k allnoconfig m68k sun3_defconfig m68kdefconfig m68k allyesconfig nios2 defconfig nios2allyesconfig openriscdefconfig c6x allyesconfig c6x allnoconfig openrisc allyesconfig nds32 defconfig nds32 allnoconfig csky allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig h8300allmodconfig xtensa defconfig arc defconfig arc allyesconfig sh allmodconfig shallnoconfig microblazeallnoconfig mips allyesconfig mips allnoconfig mips allmodconfig pariscallnoconfig parisc defconfig parisc allyesconfig parisc allmodconfig powerpc defconfig powerpc allyesconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a002-20200701 i386 randconfig-a001-20200701 i386 randconfig-a006-20200701 i386 randconfig-a005-20200701 i386 randconfig-a004-20200701 i386 randconfig-a003-20200701 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig s390 allyesconfig s390 allmodconfig s390defconfig sparcallyesconfig sparc defconfig sparc64 defconfig sparc64 allnoconfig sparc64 allyesconfig sparc64 allmodconfig um allmodconfig umallnoconfig um defconfig um allyesconfig x86_64 rhel-7.6 x86_64rhel-7.6-kselftests x86_64 rhel-8.3 x86_64
[tip:sched/urgent] BUILD SUCCESS e21cf43406a190adfcc4bfe592768066fb3aaa9b
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git sched/urgent branch HEAD: e21cf43406a190adfcc4bfe592768066fb3aaa9b sched/cfs: change initial value of runnable_avg elapsed time: 7808m configs tested: 133 configs skipped: 11 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm allyesconfig arm allmodconfig arm allnoconfig arm64allyesconfig arm64 defconfig arm64allmodconfig arm64 allnoconfig pariscgeneric-64bit_defconfig armrealview_defconfig m68k amcore_defconfig h8300alldefconfig arm pxa3xx_defconfig arm imx_v6_v7_defconfig powerpc ppc6xx_defconfig mips ath25_defconfig ia64 allyesconfig mips mtx1_defconfig arm orion5x_defconfig mipsbcm63xx_defconfig arm efm32_defconfig sh alldefconfig powerpcmvme5100_defconfig mips rb532_defconfig xtensa iss_defconfig h8300 defconfig arm lubbock_defconfig m68k bvme6000_defconfig microblaze defconfig mips cobalt_defconfig sh se7721_defconfig sh rts7751r2d1_defconfig arm viper_defconfig powerpc ppc44x_defconfig mips maltasmvp_eva_defconfig ia64generic_defconfig s390 allnoconfig microblazenommu_defconfig arm versatile_defconfig shsh7785lcr_defconfig mips sb1250_swarm_defconfig mipsjmr3927_defconfig mips decstation_r4k_defconfig c6x defconfig arm nhk8815_defconfig i386 allnoconfig i386 allyesconfig i386defconfig i386 debian-10.3 ia64 allmodconfig ia64defconfig ia64 allnoconfig m68k allmodconfig m68k allnoconfig m68k sun3_defconfig m68kdefconfig m68k allyesconfig nios2 defconfig nios2allyesconfig openriscdefconfig c6x allyesconfig c6x allnoconfig openrisc allyesconfig nds32 defconfig nds32 allnoconfig csky allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig h8300allmodconfig xtensa defconfig arc defconfig arc allyesconfig sh allmodconfig shallnoconfig microblazeallnoconfig mips allyesconfig mips allnoconfig mips allmodconfig pariscallnoconfig parisc defconfig parisc allyesconfig parisc allmodconfig powerpc defconfig powerpc allyesconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a006-20200629 i386 randconfig-a002-20200629 i386 randconfig-a003-20200629 i386 randconfig-a001-20200629 i386 randconfig-a005-20200629 i386 randconfig-a004-20200629 i386 randconfig-a002-20200701 i386 randconfig-a001-20200701 i386 randconfig-a006-20200701 i386 randconfig-a005-20200701 i386
Re: [PATCH v6 03/10] iommu/mediatek: Use a u32 flags to describe different HW features
On Fri, 2020-07-03 at 12:41 +0800, Chao Hao wrote:
> Given the fact that we are adding more and more plat_data bool values,
> it would make sense to use a u32 flags register and add the appropriate
> macro definitions to set and check for a flag present.
> No functional change.
>
> Cc: Yong Wu
> Suggested-by: Matthias Brugger
> Signed-off-by: Chao Hao
> Reviewed-by: Matthias Brugger
> ---
> drivers/iommu/mtk_iommu.c | 28 +---
> drivers/iommu/mtk_iommu.h | 7 +--
> 2 files changed, 18 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 88d3df5b91c2..40ca564d97af 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -100,6 +100,15 @@
> #define MTK_M4U_TO_LARB(id) (((id) >> 5) & 0xf)
> #define MTK_M4U_TO_PORT(id) ((id) & 0x1f)
>
> +#define HAS_4GB_MODE BIT(0)
> +/* HW will use the EMI clock if there isn't the "bclk". */
> +#define HAS_BCLK BIT(1)
> +#define HAS_VLD_PA_RNG BIT(2)
> +#define RESET_AXIBIT(3)
> +
> +#define MTK_IOMMU_HAS_FLAG(pdata, _x) \
> + pdata)->flags) & (_x)) == (_x))
> +
> struct mtk_iommu_domain {
> struct io_pgtable_cfg cfg;
> struct io_pgtable_ops *iop;
> @@ -563,7 +572,8 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data
> *data)
>upper_32_bits(data->protect_base);
> writel_relaxed(regval, data->base + REG_MMU_IVRP_PADDR);
>
> - if (data->enable_4GB && data->plat_data->has_vld_pa_rng) {
> + if (data->enable_4GB &&
> + MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_VLD_PA_RNG)) {
> /*
>* If 4GB mode is enabled, the validate PA range is from
>* 0x1__ to 0x1__. here record bit[32:30].
> @@ -573,7 +583,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data
> *data)
> }
> writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
>
> - if (data->plat_data->reset_axi) {
> + if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
> /* The register is called STANDARD_AXI_MODE in this case */
> writel_relaxed(0, data->base + REG_MMU_MISC_CTRL);
> }
> @@ -618,7 +628,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
>
> /* Whether the current dram is over 4GB */
> data->enable_4GB = !!(max_pfn > (BIT_ULL(32) >> PAGE_SHIFT));
> - if (!data->plat_data->has_4gb_mode)
> + if (!MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_4GB_MODE))
> data->enable_4GB = false;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> @@ -631,7 +641,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
> if (data->irq < 0)
> return data->irq;
>
> - if (data->plat_data->has_bclk) {
> + if (MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_BCLK)) {
> data->bclk = devm_clk_get(dev, "bclk");
> if (IS_ERR(data->bclk))
> return PTR_ERR(data->bclk);
> @@ -763,23 +773,19 @@ static const struct dev_pm_ops mtk_iommu_pm_ops = {
>
> static const struct mtk_iommu_plat_data mt2712_data = {
> .m4u_plat = M4U_MT2712,
> - .has_4gb_mode = true,
> - .has_bclk = true,
> - .has_vld_pa_rng = true,
> + .flags= HAS_4GB_MODE | HAS_BCLK | HAS_VLD_PA_RNG,
> .larbid_remap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
> };
>
> static const struct mtk_iommu_plat_data mt8173_data = {
> .m4u_plat = M4U_MT8173,
> - .has_4gb_mode = true,
> - .has_bclk = true,
> - .reset_axi= true,
> + .flags= HAS_4GB_MODE | HAS_BCLK | RESET_AXI,
> .larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
> };
>
> static const struct mtk_iommu_plat_data mt8183_data = {
> .m4u_plat = M4U_MT8183,
> - .reset_axi= true,
> + .flags= RESET_AXI,
> .larbid_remap = {0, 4, 5, 6, 7, 2, 3, 1},
> };
>
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index 7212e6fcf982..5225a9170aaa 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -39,12 +39,7 @@ enum mtk_iommu_plat {
>
> struct mtk_iommu_plat_data {
> enum mtk_iommu_plat m4u_plat;
> - boolhas_4gb_mode;
> -
> - /* HW will use the EMI clock if there isn't the "bclk". */
> - boolhas_bclk;
> - boolhas_vld_pa_rng;
> - boolreset_axi;
> + u32 flags;
How about using bit field instead? eg
u32 has_bclk:1;
In this way, we don't need to change code.
Joe.C
Re: [PATCH v3 3/3] printk: use the lockless ringbuffer
在 2020年07月02日 21:31, Petr Mladek 写道: > On Thu 2020-07-02 17:43:22, lijiang wrote: >> 在 2020年07月02日 17:02, John Ogness 写道: >>> On 2020-07-02, lijiang wrote: About the VMCOREINFO part, I made some tests based on the kernel patch v3, the makedumpfile and crash-utility can work as expected with your patch(userspace patch), but, unfortunately, the vmcore-dmesg(kexec-tools) can't correctly read the printk ring buffer information, and get the following error: "Missing the log_buf symbol" The kexec-tools(vmcore-dmesg) should also have a similar patch, just like in the makedumpfile and crash-utility. >>> >>> Yes, a patch for this is needed (as well as for any other related >>> software floating around the internet). >>> >>> I have no RFC patches for vmcore-dmesg. Looking at the code, I think it >>> would be quite straight forward to port the makedumpfile patch. I will >> >> Yes, it should be a similar patch. >> >>> try to make some time for this. >>> >> That would be nice. Thank you, John Ogness. >> >>> I do not want to patch any other software for this. I think with 3 >>> examples (crash, makedumpfile, vmcore-dmesg), others should be able to >> >> It's good enough to have the patch for the makedumpfile, crash and >> vmcore-dmesg, >> which can ensure the kdump(userspace) work well. > > I agree that this three are the most important ones and should be > enough. > > Thanks a lot for working on it and testing it. > My pleasure. I will test the vmcore-dmesg later. Thanks. Lianbo > Best Regards, > Petr >
Re: [PATCH 1/2] spi: Add the SPI daisy chain support.
Hi Adrian,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on spi/for-next]
[also build test WARNING on v5.8-rc3 next-20200703]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Adrian-Fiergolski/spi-Add-the-SPI-daisy-chain-support/20200703-221615
base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
config: parisc-allyesconfig (attached as .config)
compiler: hppa-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=parisc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/spi/spi-daisy_chain.c:232:6: warning: no previous prototype for
>> 'spi_daisy_chain_clean' [-Wmissing-prototypes]
232 | void spi_daisy_chain_clean(struct list_head *daisy_chain_devs)
| ^
vim +/spi_daisy_chain_clean +232 drivers/spi/spi-daisy_chain.c
231
> 232 void spi_daisy_chain_clean(struct list_head *daisy_chain_devs)
233 {
234 struct spi_device *spi_dev;
235 struct spi_daisy_chain_device *spi_chain_dev;
236
237 list_for_each_entry(spi_chain_dev, daisy_chain_devs, devices) {
238 spi_dev = spi_chain_dev->spi;
239 spi_dev_put(spi_dev);
240 kfree(spi_chain_dev->no_operation.tx_buf);
241 kfree(spi_chain_dev);
242 }
243 list_del(daisy_chain_devs);
244 kfree(daisy_chain_devs);
245 }
246
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[tip:x86/urgent] BUILD SUCCESS cced0b24bb545bfe74fea96de84adc23c0146b05
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/urgent branch HEAD: cced0b24bb545bfe74fea96de84adc23c0146b05 selftests/x86: Consolidate and fix get/set_eflags() helpers elapsed time: 3860m configs tested: 127 configs skipped: 6 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm allyesconfig arm allmodconfig arm allnoconfig arm64allyesconfig arm64 defconfig arm64allmodconfig arm64 allnoconfig arm pxa3xx_defconfig arm imx_v6_v7_defconfig powerpc ppc6xx_defconfig mips ath25_defconfig ia64 allyesconfig arm efm32_defconfig sh alldefconfig powerpcmvme5100_defconfig mips rb532_defconfig xtensa iss_defconfig h8300 defconfig arm lubbock_defconfig m68k bvme6000_defconfig microblaze defconfig arm orion5x_defconfig mips cobalt_defconfig sh se7721_defconfig mips rm200_defconfig mipsmaltaup_defconfig arm assabet_defconfig arm badge4_defconfig h8300h8300h-sim_defconfig mips maltasmvp_eva_defconfig ia64generic_defconfig s390 allnoconfig microblazenommu_defconfig arm ebsa110_defconfig riscvalldefconfig arm netwinder_defconfig armmagician_defconfig pariscgeneric-64bit_defconfig mipsjmr3927_defconfig mips decstation_r4k_defconfig alphaalldefconfig arc haps_hs_defconfig powerpcgamecube_defconfig arm tegra_defconfig i386 allnoconfig i386 allyesconfig i386defconfig i386 debian-10.3 ia64 allmodconfig ia64defconfig ia64 allnoconfig m68k allmodconfig m68k allnoconfig m68k sun3_defconfig m68kdefconfig m68k allyesconfig nds32 defconfig nds32 allnoconfig csky allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig h8300allmodconfig xtensa defconfig nios2 defconfig nios2allyesconfig openriscdefconfig c6x allyesconfig c6x allnoconfig openrisc allyesconfig arc defconfig arc allyesconfig sh allmodconfig shallnoconfig microblazeallnoconfig mips allyesconfig mips allnoconfig mips allmodconfig pariscallnoconfig parisc defconfig parisc allyesconfig parisc allmodconfig powerpc defconfig powerpc allyesconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a002-20200701 i386 randconfig-a001-20200701 i386 randconfig-a006-20200701 i386 randconfig-a005-20200701 i386 randconfig-a004-20200701 i386 randconfig-a003-20200701 i386 randconfig-a011-20200701 i386 randconfig-a015-20200701 i386 randconfig-a014-20200701 i386 randconfig-a016-20200701 i386
KASAN: out-of-bounds Read in csd_lock_record
Hello, syzbot found the following crash on: HEAD commit:9e50b94b Add linux-next specific files for 20200703 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=1766709710 kernel config: https://syzkaller.appspot.com/x/.config?x=f99cc0faa1476ed6 dashboard link: https://syzkaller.appspot.com/bug?extid=98af0465c818c8b093e9 compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16def93710 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1324dc8310 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+98af0465c818c8b09...@syzkaller.appspotmail.com == BUG: KASAN: out-of-bounds in csd_lock_record+0xcb/0xe0 kernel/smp.c:118 Read of size 8 at addr c90001677830 by task syz-executor014/30713 CPU: 0 PID: 30713 Comm: syz-executor014 Not tainted 5.8.0-rc3-next-20200703-syzkaller #0 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+0x18f/0x20d lib/dump_stack.c:118 print_address_description.constprop.0.cold+0x5/0x436 mm/kasan/report.c:383 __kasan_report mm/kasan/report.c:513 [inline] kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530 csd_lock_record+0xcb/0xe0 kernel/smp.c:118 flush_smp_call_function_queue+0x285/0x730 kernel/smp.c:391 __sysvec_call_function_single+0x98/0x490 arch/x86/kernel/smp.c:248 asm_call_on_stack+0xf/0x20 arch/x86/entry/entry_64.S:706 __run_on_irqstack arch/x86/include/asm/irq_stack.h:22 [inline] run_on_irqstack_cond arch/x86/include/asm/irq_stack.h:48 [inline] sysvec_call_function_single+0xe0/0x120 arch/x86/kernel/smp.c:243 asm_sysvec_call_function_single+0x12/0x20 arch/x86/include/asm/idtentry.h:604 RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:765 [inline] RIP: 0010:qlink_free mm/kasan/quarantine.c:151 [inline] RIP: 0010:qlist_free_all+0xfc/0x140 mm/kasan/quarantine.c:167 Code: 50 08 48 8d 4a ff 83 e2 01 48 0f 45 c1 4c 8b 70 18 e9 40 ff ff ff e8 c3 27 c6 ff 48 83 3d eb 55 01 08 00 74 36 4c 89 ff 57 9d <0f> 1f 44 00 00 4d 85 e4 75 9e 49 c7 45 08 00 00 00 00 49 c7 45 00 RSP: 0018:c90005537ad8 EFLAGS: 0282 RAX: 0c29 RBX: 888090e0da80 RCX: RDX: RSI: RDI: 0282 RBP: R08: R09: R10: 0001 R11: R12: 8880a2fa9780 R13: c90005537b10 R14: 8880aa00fc00 R15: 0282 quarantine_reduce+0x17e/0x200 mm/kasan/quarantine.c:260 __kasan_kmalloc.constprop.0+0x9e/0xd0 mm/kasan/common.c:475 slab_post_alloc_hook mm/slab.h:535 [inline] slab_alloc mm/slab.c:3316 [inline] kmem_cache_alloc+0x148/0x550 mm/slab.c:3486 __d_alloc+0x2a/0x920 fs/dcache.c:1709 d_alloc_pseudo+0x19/0x70 fs/dcache.c:1838 alloc_file_pseudo+0xc6/0x250 fs/file_table.c:226 anon_inode_getfile fs/anon_inodes.c:91 [inline] anon_inode_getfile+0xc8/0x1f0 fs/anon_inodes.c:74 anon_inode_getfd+0x4c/0xa0 fs/anon_inodes.c:136 bpf_map_new_fd kernel/bpf/syscall.c:686 [inline] bpf_map_new_fd kernel/bpf/syscall.c:678 [inline] map_create kernel/bpf/syscall.c:872 [inline] __do_sys_bpf+0xe6d/0x4b10 kernel/bpf/syscall.c:4094 do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:367 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x447e79 Code: Bad RIP value. RSP: 002b:7f0e1d49fdb8 EFLAGS: 0246 ORIG_RAX: 0141 RAX: ffda RBX: 006e39e8 RCX: 00447e79 RDX: 003c RSI: 2000 RDI: RBP: 006e39e0 R08: R09: R10: R11: 0246 R12: 006e39ec R13: 7fff7cf05b0f R14: 7f0e1d4a09c0 R15: Memory state around the buggy address: c90001677700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c90001677780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >c90001677800: f1 f1 f1 f1 00 00 00 00 f3 f3 f3 f3 00 00 00 00 ^ c90001677880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c90001677900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 == --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: objtool clac/stac handling change..
On Fri, Jul 03, 2020 at 10:02:37PM +0100, Al Viro wrote: > PS: I'm still going through the _ASM_EXTABLE... users on x86, so there > might be more fun. Will post when I'm done... Lovely... Not directly related to that, but... WTF? arch/x86/lib/csum-copy_64.S: /* * No _ASM_EXTABLE_UA; this is used for intentional prefetch on a * potentially unmapped kernel address. */ .macro ignore L=.Lignore 30: _ASM_EXTABLE(30b, \L) .endm ... ignore 2f prefetcht0 5*64(%rdi) 2: (and no other users of 'ignore' anywhere). How could prefetcht0 possibly raise an exception? Intel manual says that the only exception is #UD if LOCK PREFETCHT0 is encountered; not here, obviously. AMD manual simply says "no exceptions". Confused... Incidentally, in the same file: SYM_FUNC_START(csum_partial_copy_generic) cmpl$3*64, %edx jle .Lignore .Lignore: And it had been that way since "[PATCH] Intel x86-64 support merge" back in 2004, where we had @@ -59,15 +59,6 @@ csum_partial_copy_generic: cmpl $3*64,%edx jle .Lignore - ignore - prefetch (%rdi) - ignore - prefetch 1*64(%rdi) - ignore - prefetchw (%rsi) - ignore - prefetchw 1*64(%rsi) - .Lignore: @@ -115,7 +106,7 @@ csum_partial_copy_generic: movq 56(%rdi),%r13 ignore 2f - prefetch 5*64(%rdi) + prefetcht0 5*64(%rdi) 2: adcq %rbx,%rax adcq %r8,%rax What's going on in there? According to AMD manual, prefetch and prefetchw can raise an exception (#UD), if PREFETCH/PREFETCHW are not supported, as indicated by ECX bit 8 of CPUID function 8000_0001h Long Mode is not supported, as indicated by EDX bit 29 of CPUID function 8000_0001h The 3DNow! instructions are not supported, as indicated by EDX bit 31 of CPUID function 8000_0001h. so these at least used to make some sense, but why leave that thing at the place where old prefetch became prefetcht0 and what is that comment in front of 'ignore' definition about? Exceptions there had never been about unmapped addresses - that would make no sense for prefetch. What am I missing here?
Re: KASAN: stack-out-of-bounds Read in csd_lock_record
syzbot has found a reproducer for the following crash on: HEAD commit:9e50b94b Add linux-next specific files for 20200703 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=1224dc8310 kernel config: https://syzkaller.appspot.com/x/.config?x=f99cc0faa1476ed6 dashboard link: https://syzkaller.appspot.com/bug?extid=0f719294463916a3fc0e compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=170442d510 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=162ef66d10 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+0f719294463916a3f...@syzkaller.appspotmail.com == BUG: KASAN: stack-out-of-bounds in csd_lock_record+0xd2/0xe0 kernel/smp.c:119 Read of size 8 at addr c900016d75f8 by task swapper/1/0 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.8.0-rc3-next-20200703-syzkaller #0 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+0x18f/0x20d lib/dump_stack.c:118 print_address_description.constprop.0.cold+0x5/0x436 mm/kasan/report.c:383 __kasan_report mm/kasan/report.c:513 [inline] kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530 csd_lock_record+0xd2/0xe0 kernel/smp.c:119 flush_smp_call_function_queue+0x285/0x730 kernel/smp.c:391 __sysvec_call_function_single+0x98/0x490 arch/x86/kernel/smp.c:248 asm_call_on_stack+0xf/0x20 arch/x86/entry/entry_64.S:706 __run_on_irqstack arch/x86/include/asm/irq_stack.h:22 [inline] run_on_irqstack_cond arch/x86/include/asm/irq_stack.h:48 [inline] sysvec_call_function_single+0xe0/0x120 arch/x86/kernel/smp.c:243 asm_sysvec_call_function_single+0x12/0x20 arch/x86/include/asm/idtentry.h:604 RIP: 0010:native_safe_halt+0xe/0x10 arch/x86/include/asm/irqflags.h:61 Code: ff 4c 89 ef e8 33 30 c7 f9 e9 8e fe ff ff 48 89 df e8 26 30 c7 f9 eb 8a cc cc cc cc e9 07 00 00 00 0f 00 2d 14 4b 5c 00 fb f4 90 e9 07 00 00 00 0f 00 2d 04 4b 5c 00 f4 c3 cc cc 55 53 e8 c9 RSP: 0018:c9d3fd18 EFLAGS: 0293 RAX: RBX: RCX: RDX: 8880a95f0340 RSI: 87ec78c8 RDI: 87ec789e RBP: 88821af4d864 R08: R09: R10: 0001 R11: R12: 88821af4d864 R13: 1920001a7fad R14: 88821af4d865 R15: 0001 arch_safe_halt arch/x86/include/asm/paravirt.h:150 [inline] acpi_safe_halt+0x8d/0x110 drivers/acpi/processor_idle.c:111 acpi_idle_do_entry+0x15c/0x1b0 drivers/acpi/processor_idle.c:525 acpi_idle_enter+0x3f9/0xab0 drivers/acpi/processor_idle.c:651 cpuidle_enter_state+0xff/0x960 drivers/cpuidle/cpuidle.c:235 cpuidle_enter+0x4a/0xa0 drivers/cpuidle/cpuidle.c:346 call_cpuidle kernel/sched/idle.c:126 [inline] cpuidle_idle_call kernel/sched/idle.c:214 [inline] do_idle+0x431/0x6d0 kernel/sched/idle.c:276 cpu_startup_entry+0x14/0x20 kernel/sched/idle.c:372 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243 Memory state around the buggy address: c900016d7480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c900016d7500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >c900016d7580: 00 00 00 00 f1 f1 f1 f1 00 00 00 00 f3 f3 f3 f3 ^ c900016d7600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c900016d7680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ==
[PATCH v3] HID: logitech-hidpp: add support for Logitech G533 headset
Changelog:
v2:
- changed charging status parsing to account for invalid states
v3:
- rebased against Linux v5.7
- changed variable naming in hidpp20_adc_map_status_voltage
to camel case
- corrected comment styling in hidpp_battery_get_property
- dropped usage of test_bit macro in hidpp20_adc_map_status_voltage
to avoid using `long` type
- added bit flag definitions in hidpp20_adc_map_status_voltage
Signed-off-by: Kamil Domański
---
drivers/hid/hid-logitech-hidpp.c | 197 ++-
1 file changed, 196 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 094f4f1b6555..2e2842aec05b 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -29,6 +29,7 @@
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Benjamin Tissoires ");
+MODULE_AUTHOR("Kamil Domański ");
MODULE_AUTHOR("Nestor Lopez Casado ");
static bool disable_raw_mode;
@@ -92,6 +93,7 @@ MODULE_PARM_DESC(disable_tap_to_click,
#define HIDPP_CAPABILITY_BATTERY_MILEAGE BIT(2)
#define HIDPP_CAPABILITY_BATTERY_LEVEL_STATUS BIT(3)
#define HIDPP_CAPABILITY_BATTERY_VOLTAGE BIT(4)
+#define HIDPP_CAPABILITY_ADC_MEASUREMENT BIT(5)
/*
* There are two hidpp protocols in use, the first version hidpp10 is known
@@ -141,6 +143,7 @@ struct hidpp_battery {
u8 feature_index;
u8 solar_feature_index;
u8 voltage_feature_index;
+ u8 adc_measurement_feature_index;
struct power_supply_desc desc;
struct power_supply *ps;
char name[64];
@@ -215,6 +218,7 @@ struct hidpp_device {
#define HIDPP_ERROR_INVALID_PARAM_VALUE0x0b
#define HIDPP_ERROR_WRONG_PIN_CODE 0x0c
/* HID++ 2.0 error codes */
+#define HIDPP20_ERROR_DISCONNECTED 0x05
#define HIDPP20_ERROR 0xff
static void hidpp_connect_event(struct hidpp_device *hidpp_dev);
@@ -1378,6 +1382,179 @@ static int hidpp20_battery_voltage_event(struct
hidpp_device *hidpp,
return 0;
}
+/* --
*/
+/* 0x1F20: Analog-digital converter measurement
*/
+/* --
*/
+
+#define HIDPP_PAGE_ADC_MEASUREMENT 0x1F20
+
+#define CMD_ADC_MEASUREMENT_GET_VOLTAGE 0x01
+
+#define FLAG_ADC_MAP_STATUS_CONNECTED 0x01
+#define FLAG_ADC_MAP_STATUS_CHARGING 0x02
+#define FLAG_ADC_MAP_STATUS_CHARGING_COMPLETE 0x04
+#define FLAG_ADC_MAP_STATUS_CHARGING_FAULT0x08
+
+/**
+ * hidpp20_adc_map_status_voltage() - convert HID++ code to power supply status
+ * @hidpp: HID++ device struct.
+ * @data: ADC report data.
+ * @voltage: Pointer to variable where the ADC voltage shall be written.
+ *
+ * This function decodes the ADC voltage and charge status
+ * of the device's battery.
+ *
+ * Return: Returns the power supply charge status code.
+ */
+static int hidpp20_adc_map_status_voltage(struct hidpp_device *hidpp,
+ u8 data[3], int *voltage)
+{
+ u8 flags = data[2];
+ *voltage = get_unaligned_be16(data);
+
+ if (!(flags & FLAG_ADC_MAP_STATUS_CONNECTED))
+ return POWER_SUPPLY_STATUS_UNKNOWN;
+
+ if (flags & FLAG_ADC_MAP_STATUS_CHARGING) {
+ if (flags & FLAG_ADC_MAP_STATUS_CHARGING_FAULT)
+ return POWER_SUPPLY_STATUS_NOT_CHARGING;
+
+ if (flags & FLAG_ADC_MAP_STATUS_CHARGING_COMPLETE)
+ return POWER_SUPPLY_STATUS_FULL;
+
+ return POWER_SUPPLY_STATUS_CHARGING;
+ }
+
+ return POWER_SUPPLY_STATUS_DISCHARGING;
+}
+
+/**
+ * hidpp20_get_adc_measurement() - retrieve ADC mesurement feature info
+ * @hidpp: HID++ device struct.
+ * @feature_index: The device's feature index for ADC measurement.
+ * @status: Pointer to variable where the charge status shall be written.
+ * @voltage: Pointer to variable where the ADC voltage shall be written.
+ *
+ * This function retrieves the ADC voltage and charge status
+ * of the device's battery.
+ *
+ * Return: Returns 0 on success.
+ */
+static int hidpp20_get_adc_measurement(struct hidpp_device *hidpp,
+u8 feature_index,
+int *status, int *voltage)
+{
+ struct hidpp_report response;
+ int ret;
+ u8 *params = (u8 *)response.fap.params;
+
+ ret = hidpp_send_fap_command_sync(hidpp, feature_index,
+ CMD_ADC_MEASUREMENT_GET_VOLTAGE,
+ NULL, 0, );
+
+ /* The dongle cannot reach a device. */
+ if (ret == HIDPP20_ERROR_DISCONNECTED) {
+ *status = POWER_SUPPLY_STATUS_UNKNOWN;
+ *voltage = 0;
+ return 0;
+ }
+
+ if (ret > 0) {
+
Re: [PATCH v2] arm64/module: Optimize module load time by optimizing PLT counting
On Thu, Jul 2, 2020 at 8:30 AM Ard Biesheuvel wrote:
>
> On Tue, 23 Jun 2020 at 03:27, Saravana Kannan wrote:
> >
> > When loading a module, module_frob_arch_sections() tries to figure out
> > the number of PLTs that'll be needed to handle all the RELAs. While
> > doing this, it tries to dedupe PLT allocations for multiple
> > R_AARCH64_CALL26 relocations to the same symbol. It does the same for
> > R_AARCH64_JUMP26 relocations.
> >
> > To make checks for duplicates easier/faster, it sorts the relocation
> > list by type, symbol and addend. That way, to check for a duplicate
> > relocation, it just needs to compare with the previous entry.
> >
> > However, sorting the entire relocation array is unnecessary and
> > expensive (O(n log n)) because there are a lot of other relocation types
> > that don't need deduping or can't be deduped.
> >
> > So this commit partitions the array into entries that need deduping and
> > those that don't. And then sorts just the part that needs deduping. And
> > when CONFIG_RANDOMIZE_BASE is disabled, the sorting is skipped entirely
> > because PLTs are not allocated for R_AARCH64_CALL26 and R_AARCH64_JUMP26
> > if it's disabled.
> >
> > This gives significant reduction in module load time for modules with
> > large number of relocations with no measurable impact on modules with a
> > small number of relocations. In my test setup with CONFIG_RANDOMIZE_BASE
> > enabled, these were the results for a few downstream modules:
> >
> > Module Size (MB)
> > wlan14
> > video codec 3.8
> > drm 1.8
> > IPA 2.5
> > audio 1.2
> > gpu 1.8
> >
> > Without this patch:
> > Module Number of entries sortedModule load time (ms)
> > wlan243739 283
> > video codec 74029 138
> > drm 53837 67
> > IPA 42800 90
> > audio 21326 27
> > gpu 20967 32
> >
> > Total time to load all these module: 637 ms
> >
> > With this patch:
> > Module Number of entries sortedModule load time (ms)
> > wlan22454 61
> > video codec 10150 47
> > drm 13014 40
> > IPA 809763
> > audio 460616
> > gpu 652720
> >
> > Total time to load all these modules: 247
> >
> > Time saved during boot for just these 6 modules: 390 ms
> >
> > Cc: Ard Biesheuvel
>
> [I am no longer at Linaro so please don't use my @linaro.org address]
Hmm... I'm pretty sure I got this using the get_maintainers script.
Maybe update the MAINTAINERS file if you haven't already (I didn't
check)?
But if I ever manually add in your email, I'll keep this in mind.
> > Signed-off-by: Saravana Kannan
> > ---
> >
> > v1 -> v2:
> > - Provided more details in the commit text
> > - Pulled in Will's comments on the coding style
> > - Pulled in Ard's suggestion about skipping jumps with the same section
> > index (parts of Will's suggested code)
> >
> > arch/arm64/kernel/module-plts.c | 46 ++---
> > 1 file changed, 43 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/module-plts.c
> > b/arch/arm64/kernel/module-plts.c
> > index 65b08a74aec6..0ce3a28e3347 100644
> > --- a/arch/arm64/kernel/module-plts.c
> > +++ b/arch/arm64/kernel/module-plts.c
> > @@ -253,6 +253,40 @@ static unsigned int count_plts(Elf64_Sym *syms,
> > Elf64_Rela *rela, int num,
> > return ret;
> > }
> >
> > +static bool branch_rela_needs_plt(Elf64_Sym *syms, Elf64_Rela *rela,
> > + Elf64_Word dstidx)
> > +{
> > +
> > + Elf64_Sym *s = syms + ELF64_R_SYM(rela->r_info);
> > +
> > + if (s->st_shndx == dstidx)
> > + return false;
> > +
> > + return ELF64_R_TYPE(rela->r_info) == R_AARCH64_JUMP26 ||
> > + ELF64_R_TYPE(rela->r_info) == R_AARCH64_CALL26;
> > +}
> > +
> > +/* Group branch PLT relas at the front end of the array. */
> > +static int partition_branch_plt_relas(Elf64_Sym *syms, Elf64_Rela *rela,
> > + int numrels, Elf64_Word dstidx)
> > +{
> > + int i = 0, j = numrels - 1;
> > +
> > + if (!IS_ENABLED(CONFIG_RANDOMIZE_BASE))
> > + return 0;
> > +
> > + while (i < j) {
> > + if (branch_rela_needs_plt(syms, [i], dstidx))
> > + i++;
> > + else if (branch_rela_needs_plt(syms, [j], dstidx))
> > + swap(rela[i], rela[j]);
>
> Nit: would be slightly better to put
>
> swap(rela[i++], rela[j]);
>
> here so the next iteration of the loop will not call
> branch_rela_needs_plt() on rela[i]
[PATCH v3] HID: logitech-hidpp: add support for Logitech G533 headset
Changelog:
v2:
- changed charging status parsing to account for invalid states
v3:
- rebased against Linux v5.7
- changed variable naming in hidpp20_adc_map_status_voltage
to camel case
- corrected comment styling in hidpp_battery_get_property
- dropped usage of test_bit macro in hidpp20_adc_map_status_voltage
to avoid using `long` type
- added bit flag definitions in hidpp20_adc_map_status_voltage
Signed-off-by: Kamil Domański
---
drivers/hid/hid-logitech-hidpp.c | 197 ++-
1 file changed, 196 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 094f4f1b6555..2e2842aec05b 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -29,6 +29,7 @@
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Benjamin Tissoires ");
+MODULE_AUTHOR("Kamil Domański ");
MODULE_AUTHOR("Nestor Lopez Casado ");
static bool disable_raw_mode;
@@ -92,6 +93,7 @@ MODULE_PARM_DESC(disable_tap_to_click,
#define HIDPP_CAPABILITY_BATTERY_MILEAGE BIT(2)
#define HIDPP_CAPABILITY_BATTERY_LEVEL_STATUS BIT(3)
#define HIDPP_CAPABILITY_BATTERY_VOLTAGE BIT(4)
+#define HIDPP_CAPABILITY_ADC_MEASUREMENT BIT(5)
/*
* There are two hidpp protocols in use, the first version hidpp10 is known
@@ -141,6 +143,7 @@ struct hidpp_battery {
u8 feature_index;
u8 solar_feature_index;
u8 voltage_feature_index;
+ u8 adc_measurement_feature_index;
struct power_supply_desc desc;
struct power_supply *ps;
char name[64];
@@ -215,6 +218,7 @@ struct hidpp_device {
#define HIDPP_ERROR_INVALID_PARAM_VALUE0x0b
#define HIDPP_ERROR_WRONG_PIN_CODE 0x0c
/* HID++ 2.0 error codes */
+#define HIDPP20_ERROR_DISCONNECTED 0x05
#define HIDPP20_ERROR 0xff
static void hidpp_connect_event(struct hidpp_device *hidpp_dev);
@@ -1378,6 +1382,179 @@ static int hidpp20_battery_voltage_event(struct
hidpp_device *hidpp,
return 0;
}
+/* --
*/
+/* 0x1F20: Analog-digital converter measurement
*/
+/* --
*/
+
+#define HIDPP_PAGE_ADC_MEASUREMENT 0x1F20
+
+#define CMD_ADC_MEASUREMENT_GET_VOLTAGE 0x01
+
+#define FLAG_ADC_MAP_STATUS_CONNECTED 0x01
+#define FLAG_ADC_MAP_STATUS_CHARGING 0x02
+#define FLAG_ADC_MAP_STATUS_CHARGING_COMPLETE 0x04
+#define FLAG_ADC_MAP_STATUS_CHARGING_FAULT0x08
+
+/**
+ * hidpp20_adc_map_status_voltage() - convert HID++ code to power supply status
+ * @hidpp: HID++ device struct.
+ * @data: ADC report data.
+ * @voltage: Pointer to variable where the ADC voltage shall be written.
+ *
+ * This function decodes the ADC voltage and charge status
+ * of the device's battery.
+ *
+ * Return: Returns the power supply charge status code.
+ */
+static int hidpp20_adc_map_status_voltage(struct hidpp_device *hidpp,
+ u8 data[3], int *voltage)
+{
+ u8 flags = data[2];
+ *voltage = get_unaligned_be16(data);
+
+ if (!(flags & FLAG_ADC_MAP_STATUS_CONNECTED))
+ return POWER_SUPPLY_STATUS_UNKNOWN;
+
+ if (flags & FLAG_ADC_MAP_STATUS_CHARGING) {
+ if (flags & FLAG_ADC_MAP_STATUS_CHARGING_FAULT)
+ return POWER_SUPPLY_STATUS_NOT_CHARGING;
+
+ if (flags & FLAG_ADC_MAP_STATUS_CHARGING_COMPLETE)
+ return POWER_SUPPLY_STATUS_FULL;
+
+ return POWER_SUPPLY_STATUS_CHARGING;
+ }
+
+ return POWER_SUPPLY_STATUS_DISCHARGING;
+}
+
+/**
+ * hidpp20_get_adc_measurement() - retrieve ADC mesurement feature info
+ * @hidpp: HID++ device struct.
+ * @feature_index: The device's feature index for ADC measurement.
+ * @status: Pointer to variable where the charge status shall be written.
+ * @voltage: Pointer to variable where the ADC voltage shall be written.
+ *
+ * This function retrieves the ADC voltage and charge status
+ * of the device's battery.
+ *
+ * Return: Returns 0 on success.
+ */
+static int hidpp20_get_adc_measurement(struct hidpp_device *hidpp,
+u8 feature_index,
+int *status, int *voltage)
+{
+ struct hidpp_report response;
+ int ret;
+ u8 *params = (u8 *)response.fap.params;
+
+ ret = hidpp_send_fap_command_sync(hidpp, feature_index,
+ CMD_ADC_MEASUREMENT_GET_VOLTAGE,
+ NULL, 0, );
+
+ /* The dongle cannot reach a device. */
+ if (ret == HIDPP20_ERROR_DISCONNECTED) {
+ *status = POWER_SUPPLY_STATUS_UNKNOWN;
+ *voltage = 0;
+ return 0;
+ }
+
+ if (ret > 0) {
+
drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1513:13: sparse: sparse: incorrect type in assignment (different address spaces)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 0c7d7d1fada70420851b63f2e2669cb4976a303b commit: 00d36494dee9e5020250e9bb5afd54362795847e staging: vc04_services: Replace VCHIQ_STATUS_T enum typedef with enum vchiq_status date: 8 months ago config: x86_64-randconfig-s021-20200704 (attached as .config) compiler: gcc-9 (Debian 9.3.0-14) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.2-3-gfa153962-dirty git checkout 00d36494dee9e5020250e9bb5afd54362795847e # save the attached .config to linux build tree make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1244:60: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct vchiq_header *header @@ got void [noderef] *[addressable] msgbuf @@ drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1244:60: sparse: expected struct vchiq_header *header drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1244:60: sparse: got void [noderef] *[addressable] msgbuf >> drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1513:13: >> sparse: sparse: incorrect type in assignment (different address spaces) @@ >> expected int enum vchiq_status ( *__pu_val )( ... ) @@ got void >> [noderef] * @@ drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1513:13: sparse: expected int enum vchiq_status ( *__pu_val )( ... ) drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1513:13: sparse: got void [noderef] * drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1515:13: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void *__pu_val @@ got void [noderef] * @@ drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1515:13: sparse: expected void *__pu_val drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1515:13: sparse: got void [noderef] * drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1641:13: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void *__pu_val @@ got void [noderef] * @@ drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1641:13: sparse: expected void *__pu_val drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1641:13: sparse: got void [noderef] * drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1643:13: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void *__pu_val @@ got void [noderef] * @@ drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1643:13: sparse: expected void *__pu_val drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1643:13: sparse: got void [noderef] * drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1718:13: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct vchiq_completion_data *__pu_val @@ got void [noderef] * @@ drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1718:13: sparse: expected struct vchiq_completion_data *__pu_val drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1718:13: sparse: got void [noderef] * drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1721:13: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void **__pu_val @@ got void [noderef] * @@ drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1721:13: sparse: expected void **__pu_val drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1721:13: sparse: got void [noderef] * drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1768:13: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct vchiq_completion_data *__pu_val @@ got struct vchiq_completion_data [noderef] *[assigned] completion @@ drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1768:13: sparse: expected struct vchiq_completion_data *__pu_val drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1768:13: sparse: got struct vchiq_completion_data [noderef] *[assigned] completion drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1798:59: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void [noderef] *uptr @@ got struct vchiq_header *[addressable] header @@ drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1798:59: sparse: expected void [noderef] *uptr
Re: [PATCH 4/7] Documentation: networking: dsa: drop doubled word
On Fri, Jul 03, 2020 at 03:41:12PM -0700, Randy Dunlap wrote: > Drop the doubled word "in". > > Signed-off-by: Randy Dunlap > Cc: Jonathan Corbet > Cc: linux-...@vger.kernel.org > Cc: "David S. Miller" > Cc: Jakub Kicinski > Cc: net...@vger.kernel.org > Cc: Andrew Lunn > Cc: Vivien Didelot > Cc: Florian Fainelli Reviewed-by: Andrew Lunn Andrew
Re: [PATCH v2] HID: logitech-hidpp: add support for Logitech G533 headset
Hi Filipe, >> +bool isConnected; >> +bool isCharging; >> +bool chargingComplete; >> +bool chargingFault; > > From my initial comments: > >> We use snake case. Will be fixed in v3. >> + >> +long flags = (long) data[2]; > >> Use u8 instead. Why are we even using a variable for this? > > My main point here is that long means different things in different > architectures, and we only want one byte so I would go for u8. I used long, because the test_bit macro accepts long and the similar function for voltage reading already used long too. That will be changed in v3 - see next paragraph. >> + >> +*voltage = get_unaligned_be16(data); >> +isConnected = test_bit(0, ); >> +isCharging = test_bit(1, ); >> +chargingComplete = test_bit(2, ); >> +chargingFault = test_bit(3, ); > >> I don't think this is needed, just do it in the ifs directly. >> >> Here I would add a #define for each bit: >> >> #define FLAG_ADC_MAP_STATUS_CONNECTED 0 >> ... >> if (data[2] & FLAG_ADC_MAP_STATUS_CONNECTED) Yeah, I it will do exactly that for v3, which allows to drop the flag variables and avoid using a long. > Same thing here. We should see if the device supports the DJ protocol > and add it in hid-logitech-dj instead. It doesn't seem to be a DJ device. The DJ driver just detects the extra interfaces and skips directly to hid_hw_start. Regards, Kamil
Re: [PATCH] perf evsel: Don't set sample_regs_intr/sample_regs_user for dummy event
Hi Jiri,
On 7/3/2020 7:00 PM, Jiri Olsa wrote:
On Fri, Jul 03, 2020 at 08:42:15AM +0800, Jin Yao wrote:
Since commit 0a892c1c9472 ("perf record: Add dummy event during system wide
synthesis"),
a dummy event is added to capture mmaps.
But if we run perf-record as,
# perf record -e cycles:p -IXMM0 -a -- sleep 1
Error:
dummy:HG: PMU Hardware doesn't support sampling/overflow-interrupts. Try
'perf stat'
The issue is, if we enable the extended regs (-IXMM0), but the
pmu->capabilities is not set with PERF_PMU_CAP_EXTENDED_REGS, the kernel
will return -EOPNOTSUPP error.
See following code pieces.
/* in kernel/events/core.c */
static int perf_try_init_event(struct pmu *pmu, struct perf_event *event)
{
if (!(pmu->capabilities & PERF_PMU_CAP_EXTENDED_REGS) &&
has_extended_regs(event))
ret = -EOPNOTSUPP;
}
For software dummy event, the PMU should be not set with
PERF_PMU_CAP_EXTENDED_REGS. But unfortunately in current code, the dummy
event has possibility to be set with PERF_REG_EXTENDED_MASK bit.
In evsel__config, /* tools/perf/util/evsel.c */
if (opts->sample_intr_regs) {
attr->sample_regs_intr = opts->sample_intr_regs;
}
If we use -IXMM0, the attr>sample_regs_intr will be set with
PERF_REG_EXTENDED_MASK bit.
It doesn't make sense to set attr->sample_regs_intr for a
software dummy event.
This patch adds dummy event checking before setting
attr->sample_regs_intr.
After:
# ./perf record -e cycles:p -IXMM0 -a -- sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.413 MB perf.data (45 samples) ]
LGTM, Adrian (cc-ed) just added another check to the same place,
but it looks like both of them should be there:
https://lore.kernel.org/lkml/20200630133935.11150-2-adrian.hun...@intel.com/
jirka
Thanks Jiri! Yes, it looks like both of checks should be added here.
So do I post v2 (just rebase) once Adrian's patch gets merged?
Thanks
Jin Yao
Fixes: 0a892c1c9472 ("perf record: Add dummy event during system wide
synthesis")
Signed-off-by: Jin Yao
---
tools/perf/util/evsel.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 96e5171dce41..df3315543e86 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1020,12 +1020,12 @@ void evsel__config(struct evsel *evsel, struct
record_opts *opts,
if (callchain && callchain->enabled && !evsel->no_aux_samples)
evsel__config_callchain(evsel, opts, callchain);
- if (opts->sample_intr_regs) {
+ if (opts->sample_intr_regs && !is_dummy_event(evsel)) {
attr->sample_regs_intr = opts->sample_intr_regs;
evsel__set_sample_bit(evsel, REGS_INTR);
}
- if (opts->sample_user_regs) {
+ if (opts->sample_user_regs && !is_dummy_event(evsel)) {
attr->sample_regs_user |= opts->sample_user_regs;
evsel__set_sample_bit(evsel, REGS_USER);
}
--
2.17.1
Re: [GIT PULL] hwmon fixes for v5.8-rc4
The pull request you sent on Fri, 3 Jul 2020 15:03:36 -0700: > git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git > hwmon-for-v5.8-rc4 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/6f216714a6906d6d5d0654313d9f9a47613bb473 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH 09/16] initrd: remove the BLKFLSBUF call in handle_initrd
On 03/07/2020 04:40, H. Peter Anvin wrote:
On 2020-06-15 05:53, Christoph Hellwig wrote:
BLKFLSBUF used to be overloaded for the ramdisk driver to free the whole
ramdisk, which was completely different behavior compared to all other
drivers. But this magic overload got removed in commit ff26956875c2
("brd: remove support for BLKFLSBUF"), so this call is entirely
pointless now.
Signed-off-by: Christoph Hellwig
Does *anyone* use initrd as opposed to initramfs anymore? It would seem
like a good candidate for deprecation/removal.
Reading the gentoo mailing list, it seems there's a fair few people who
don't use initramfs. I get the impression they don't use initrd either,
though.
I don't know too much about booting without an initramfs - I switched
ages ago - so what is possible and what they're actually doing, I don't
know.
Cheers,
Wol
Re: [PATCH v3 00/34] iommu: Move iommu_group setup to IOMMU core code
On Tue, Jun 30, 2020 at 08:40:28PM -0400, Qian Cai wrote:
> On Wed, Apr 29, 2020 at 03:36:38PM +0200, Joerg Roedel wrote:
> > Hi,
> >
> > here is the third version of this patch-set. Older versions can be found
> > here:
> >
> > v1: https://lore.kernel.org/lkml/20200407183742.4344-1-j...@8bytes.org/
> > (Has some more introductory text)
> >
> > v2: https://lore.kernel.org/lkml/20200414131542.25608-1-j...@8bytes.org/
> >
> > Changes v2 -> v3:
> >
> > * Rebased v5.7-rc3
> >
> > * Added a missing iommu_group_put() as reported by Lu Baolu.
> >
> > * Added a patch to consolidate more initialization work in
> > __iommu_probe_device(), fixing a bug where no 'struct
> > device_iommu' was allocated in the hotplug path.
> >
> > There is also a git-branch available with these patches applied:
> >
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/joro/linux.git/log/?h=iommu-probe-device-v3
> >
> > Please review. If there are no objections I plan to put these patches
> > into the IOMMU tree early next week.
>
> Looks like this patchset introduced an use-after-free on arm-smmu-v3.
>
> Reproduced using mlx5,
>
> # echo 1 > /sys/class/net/enp11s0f1np1/device/sriov_numvfs
> # echo 0 > /sys/class/net/enp11s0f1np1/device/sriov_numvfs
>
> The .config,
> https://github.com/cailca/linux-mm/blob/master/arm64.config
>
> Looking at the free stack,
>
> iommu_release_device->iommu_group_remove_device
>
> was introduced in 07/34 ("iommu: Add probe_device() and release_device()
> call-backs").
FYI, I have just sent a patch to fix this,
https://lore.kernel.org/linux-iommu/20200704001003.2303-1-...@lca.pw/
>
> [ 9426.724641][ T3356] pci :0b:01.2: Removing from iommu group 3
> [ 9426.731347][ T3356]
> ==
> [ 9426.739263][ T3356] BUG: KASAN: use-after-free in
> __lock_acquire+0x3458/0x4440
> __lock_acquire at kernel/locking/lockdep.c:4250
> [ 9426.746477][ T3356] Read of size 8 at addr 0089df1a6f68 by task
> bash/3356
> [ 9426.753601][ T3356]
> [ 9426.755782][ T3356] CPU: 5 PID: 3356 Comm: bash Not tainted
> 5.8.0-rc3-next-20200630 #2
> [ 9426.763687][ T3356] Hardware name: HPE Apollo 70
> /C01_APACHE_MB , BIOS L50_5.13_1.11 06/18/2019
> [ 9426.774111][ T3356] Call trace:
> [ 9426.777245][ T3356] dump_backtrace+0x0/0x398
> [ 9426.781593][ T3356] show_stack+0x14/0x20
> [ 9426.785596][ T3356] dump_stack+0x140/0x1b8
> [ 9426.789772][ T3356] print_address_description.isra.12+0x54/0x4a8
> [ 9426.795855][ T3356] kasan_report+0x134/0x1b8
> [ 9426.800203][ T3356] __asan_report_load8_noabort+0x2c/0x50
> [ 9426.805679][ T3356] __lock_acquire+0x3458/0x4440
> [ 9426.810373][ T3356] lock_acquire+0x204/0xf10
> [ 9426.814722][ T3356] _raw_spin_lock_irqsave+0xf8/0x180
> [ 9426.819853][ T3356] arm_smmu_detach_dev+0xd8/0x4a0
> arm_smmu_detach_dev at drivers/iommu/arm-smmu-v3.c:2776
> [ 9426.824721][ T3356] arm_smmu_release_device+0xb4/0x1c8
> arm_smmu_disable_pasid at drivers/iommu/arm-smmu-v3.c:2754
> (inlined by) arm_smmu_release_device at drivers/iommu/arm-smmu-v3.c:3000
> [ 9426.829937][ T3356] iommu_release_device+0xc0/0x178
> iommu_release_device at drivers/iommu/iommu.c:302
> [ 9426.834892][ T3356] iommu_bus_notifier+0x118/0x160
> [ 9426.839762][ T3356] notifier_call_chain+0xa4/0x128
> [ 9426.844630][ T3356] __blocking_notifier_call_chain+0x70/0xa8
> [ 9426.850367][ T3356] blocking_notifier_call_chain+0x14/0x20
> [ 9426.855929][ T3356] device_del+0x618/0xa00
> [ 9426.860105][ T3356] pci_remove_bus_device+0x108/0x2d8
> [ 9426.865233][ T3356] pci_stop_and_remove_bus_device+0x1c/0x28
> [ 9426.870972][ T3356] pci_iov_remove_virtfn+0x228/0x368
> [ 9426.876100][ T3356] sriov_disable+0x8c/0x348
> [ 9426.880447][ T3356] pci_disable_sriov+0x5c/0x70
> [ 9426.885117][ T3356] mlx5_core_sriov_configure+0xd8/0x260 [mlx5_core]
> [ 9426.891549][ T3356] sriov_numvfs_store+0x240/0x318
> [ 9426.896417][ T3356] dev_attr_store+0x38/0x68
> [ 9426.900766][ T3356] sysfs_kf_write+0xdc/0x128
> [ 9426.905200][ T3356] kernfs_fop_write+0x23c/0x448
> [ 9426.909897][ T3356] __vfs_write+0x54/0xe8
> [ 9426.913984][ T3356] vfs_write+0x124/0x3f0
> [ 9426.918070][ T3356] ksys_write+0xe8/0x1b8
> [ 9426.922157][ T3356] __arm64_sys_write+0x68/0x98
> [ 9426.926766][ T3356] do_el0_svc+0x124/0x220
> [ 9426.930941][ T3356] el0_sync_handler+0x260/0x408
> [ 9426.935634][ T3356] el0_sync+0x140/0x180
> [ 9426.939633][ T3356]
> [ 9426.941810][ T3356] Allocated by task 3356:
> [ 9426.945985][ T3356] save_stack+0x24/0x50
> [ 9426.949986][ T3356] __kasan_kmalloc.isra.13+0xc4/0xe0
> [ 9426.955114][ T3356] kasan_kmalloc+0xc/0x18
> [ 9426.959288][ T3356] kmem_cache_alloc_trace+0x1ec/0x318
> [ 9426.964503][ T3356] arm_smmu_domain_alloc+0x54/0x148
> [ 9426.969545][ T3356] iommu_group_alloc_default_domain+0xc0/0x440
> [ 9426.975541][ T3356] iommu_probe_device+0x1c0/0x308
> [ 9426.980409][ T3356]
Re: [PATCH v33 11/21] x86/sgx: Linux Enclave Driver
On Fri, Jun 26, 2020 at 05:34:00PM +0200, Borislav Petkov wrote:
> On Thu, Jun 18, 2020 at 01:08:33AM +0300, Jarkko Sakkinen wrote:
>
> ...
>
> This could use some commenting along the lines of:
>
> "— If the enclave developer requires measurement of the page as a
> proof for the content, use EEXTEND to add a measurement for 256 bytes of
> the page. Repeat this operation until the entire page is measured."
>
> At least this text from the SDM maps to the 256 bytes below. Otherwise
> it is magic.
Copied with pride:
/*
* If the caller requires measurement of the page as a proof for the content,
* use EEXTEND to add a measurement for 256 bytes of the page. Repeat this
* operation until the entire page is measured."
*/
> > +static int sgx_encl_add_page(struct sgx_encl *encl, unsigned long src,
> > +unsigned long offset, unsigned long length,
> > +struct sgx_secinfo *secinfo, unsigned long flags)
> > +{
> > + struct sgx_encl_page *encl_page;
> > + struct sgx_epc_page *epc_page;
> > + int ret;
> > +
> > + encl_page = sgx_encl_page_alloc(encl, offset, secinfo->flags);
> > + if (IS_ERR(encl_page))
> > + return PTR_ERR(encl_page);
> > +
> > + epc_page = __sgx_alloc_epc_page();
> > + if (IS_ERR(epc_page)) {
> > + kfree(encl_page);
> > + return PTR_ERR(epc_page);
> > + }
> > +
> > + if (atomic_read(>flags) &
> > + (SGX_ENCL_INITIALIZED | SGX_ENCL_DEAD)) {
> > + ret = -EFAULT;
> > + goto err_out_free;
> > + }
>
> You can do this first thing when you enter the function so that
> you don't have to allocate needlessly in the error case, when
> SGX_ENCL_INITIALIZED | SGX_ENCL_DEAD is set.
Updated version:
static int sgx_encl_add_page(struct sgx_encl *encl, unsigned long src,
unsigned long offset, unsigned long length,
struct sgx_secinfo *secinfo, unsigned long flags)
{
struct sgx_encl_page *encl_page;
struct sgx_epc_page *epc_page;
struct sgx_va_page *va_page;
int ret;
if (atomic_read(>flags) & SGX_ENCL_INITIALIZED)
return -EFAULT;
SGX_ENCL_DEAD check is unnecessary altogether as this flag cannot be
possibly be unset inside ioctl. 'sgx_release()' will set it which is
the release callback for the enclave file.
'sgx_ioctl()' also unnecessarily has this check I just noticed (and
removed).
> "uninitialized"?
>
> Where is the test for SGX_ENCL_INITIALIZED and erroring out otherwise?
>
> I.e., what happens if you add pages to an initialized enclave?
Because of historical reasons it is in sgx_encl_add_page(). Then we
allowed ioctl's operate on enclave concurrently. Today we enforce
sequential operation on a single enclave with SGX_ENCL_IOCTL flag
because that is the only sane way to use the construction operations.
Therefore the check can be moved to sgx_ioc_encl_add_pages() if you
request so but first I have one remark to discuss.
I noticed that sometimes wrong state flags turn into -EINVAL and
sometimes into -EFAULT (like in the previous case). I'd suggest
that when the ioctl is blocked based encl->flags and only on that,
the ioctl would return -ENOIOCTLCMD in both cases, i.e. this
command is not available.
That would give much better aids for debugging user space code.
>
> > + * measurement with the contents of the page. The address range of pages
> > must
> > + * be contiguous.
>
> Must? Who is enforcing this? I'm trying to find where...
Unfortunately I cannot recall what I meant when I wrote that. I removed
that sentence. I'm not sure what I meant exactly when I used 'contiguous'
here.
> > The SECINFO and measurement mask are applied to all pages.
> > + *
> > + * A SECINFO for a TCS is required to always contain zero permissions
> > because
> > + * CPU silently zeros them. Allowing anything else would cause a mismatch
> > in
> > + * the measurement.
> > + *
> > + * mmap()'s protection bits are capped by the page permissions. For each
> > page
> > + * address, the maximum protection bits are computed with the following
> > + * heuristics:
> > + *
> > + * 1. A regular page: PROT_R, PROT_W and PROT_X match the SECINFO
> > permissions.
> > + * 2. A TCS page: PROT_R | PROT_W.
> > + *
> > + * mmap() is not allowed to surpass the minimum of the maximum protection
> > bits
> > + * within the given address range.
> > + *
> > + * If ENCLS opcode fails, that effectively means that EPC has been
> > invalidated.
> > + * When this happens the enclave is destroyed and -EIO is returned to the
> > + * caller.
> > + *
> > + * Return:
> > + * 0 on success,
> > + * -EACCES if an executable source page is located in a noexec partition,
> > + * -EIO if either ENCLS[EADD] or ENCLS[EEXTEND] fails
> > + * -errno otherwise
> > + */
> > +static long sgx_ioc_enclave_add_pages(struct sgx_encl *encl, void __user
> > *arg)
> > +{
> > + struct sgx_enclave_add_pages addp;
> >
Re: [PATCH 00/11] Documentation: userspace-api/media: eliminate duplicated words
On Fri, Jul 03, 2020 at 04:55:25PM -0700, Randy Dunlap wrote: > Drop all doubled words in Documenation/userspace-api/media/ files. Reviewed-by: Matthew Wilcox (Oracle) (for the series)
Re: [PATCH] [net/ipv6] Remove redundant null check in ah_mt6
Hi Gaurav, On Wed, Jun 24, 2020 at 10:36:25PM -0400, Gaurav Singh wrote: > ah cannot be NULL since its already checked above after > assignment and is being dereferenced before in pr(). > Remove the redundant null check. Could you collapse all your patches into one? They look like the same logic change (patch description is the same in the four patches in the series). Please, prepend netfilter: to your patch subject, I suggest the following subject for the collapsed patch. netfilter: ip6tables: Remove redundant null checks Thanks.
Re: [PATCH v3 13/16] exit: Factor thread_group_exited out of pidfd_poll
On Fri, Jul 03, 2020 at 04:37:47PM -0500, Eric W. Biederman wrote: > > > The rest all looks good to me. Tested with and without bpf_preload patches. > > Feel free to create a frozen branch with this set. > > Can I have your Tested-by and Acked-by? For the set: Acked-by: Alexei Starovoitov Tested-by: Alexei Starovoitov
Re: [PATCH net] net: qed: prevent buffer overflow when collecting debug data
From: David Miller
Date: Fri, 03 Jul 2020 12:59:33 -0700 (PDT)
> From: Alexander Lobakin
> Date: Fri, 3 Jul 2020 12:02:58 +0300
>
> > When generating debug dump, driver firstly collects all data in binary
> > form, and then performs per-feature formatting to human-readable if it
> > is supported.
> > The size of the new formatted data is often larger than the raw's. This
> > becomes critical when user requests dump via ethtool (-d/-w), as output
> > buffer size is strictly determined (by ethtool_ops::get_regs_len() etc),
> > as it may lead to out-of-bounds writes and memory corruption.
> >
> > To not go past initial lengths, add a flag to return original,
> > non-formatted debug data, and set it in such cases. Also set data type
> > in regdump headers, so userland parsers could handle it.
> >
> > Fixes: c965db444629 ("qed: Add support for debug data collection")
> > Signed-off-by: Alexander Lobakin
> > Signed-off-by: Igor Russkikh
>
> This is now how ethtool register dumps work.
>
> It does not provide "human readable" versions of register data. Instead
> it is supposed to be purely raw data and then userland utilities interpret
> that data and can make it human readable based upon the driver name and
> reg dump version.
>
> Please fix your ethtool -d implementation to comply with this.
This is exactly what this patch does: forces driver to dump raw binary
data. Current mainline version tries to perform formatting before passing
data up to ethtool infra.
> Thank you.
Thanks,
Al
[PATCH 08/11] Documentation: userspace-api/media: v4l/selection-api-config: drop doubled word
Drop the doubled word "in". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Mauro Carvalho Chehab Cc: linux-me...@vger.kernel.org --- Documentation/userspace-api/media/v4l/selection-api-configuration.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/userspace-api/media/v4l/selection-api-configuration.rst +++ linux-next-20200701/Documentation/userspace-api/media/v4l/selection-api-configuration.rst @@ -101,7 +101,7 @@ specified using :ref:`VIDIOC_S_FMT
[PATCH 06/11] Documentation: userspace-api/media: dvb/video: drop doubled word
Drop the doubled word "and". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Mauro Carvalho Chehab Cc: linux-me...@vger.kernel.org --- Documentation/userspace-api/media/dvb/video.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/userspace-api/media/dvb/video.rst +++ linux-next-20200701/Documentation/userspace-api/media/dvb/video.rst @@ -15,7 +15,7 @@ Digital TV Video Device The Digital TV video device controls the MPEG2 video decoder of the Digital TV hardware. It can be accessed through **/dev/dvb/adapter0/video0**. Data -types and and ioctl definitions can be accessed by including +types and ioctl definitions can be accessed by including **linux/dvb/video.h** in your application. Note that the Digital TV video device only controls decoding of the MPEG video
[PATCH 10/11] Documentation: userspace-api/media: v4l/vidioc-g-output: drop doubled word
Drop the doubled word "standard.". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Mauro Carvalho Chehab Cc: linux-me...@vger.kernel.org --- Documentation/userspace-api/media/v4l/vidioc-g-output.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/userspace-api/media/v4l/vidioc-g-output.rst +++ linux-next-20200701/Documentation/userspace-api/media/v4l/vidioc-g-output.rst @@ -53,7 +53,7 @@ To select a video output applications st output in an integer and call the :ref:`VIDIOC_S_OUTPUT ` ioctl with a pointer to this integer. Side effects are possible. For example outputs may support different video standards, so the driver may implicitly -switch the current standard. standard. Because of these possible side +switch the current standard. Because of these possible side effects applications must select an output before querying or negotiating any other parameters.
[PATCH 05/11] Documentation: userspace-api/media: dvb/net: drop doubled word
Drop the doubled word "and". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Mauro Carvalho Chehab Cc: linux-me...@vger.kernel.org --- Documentation/userspace-api/media/dvb/net.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/userspace-api/media/dvb/net.rst +++ linux-next-20200701/Documentation/userspace-api/media/dvb/net.rst @@ -30,7 +30,7 @@ types that are present on the transport virtual ``dvb?_?`` network interfaces, and will be controlled/routed via the standard ip tools (like ip, route, netstat, ifconfig, etc). -Data types and and ioctl definitions are defined via ``linux/dvb/net.h`` +Data types and ioctl definitions are defined via ``linux/dvb/net.h`` header.
[PATCH 07/11] Documentation: userspace-api/media: dvb/audio: drop doubled word
Drop the doubled word "Any". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Mauro Carvalho Chehab Cc: linux-me...@vger.kernel.org --- Documentation/userspace-api/media/v4l/buffer.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/userspace-api/media/v4l/buffer.rst +++ linux-next-20200701/Documentation/userspace-api/media/v4l/buffer.rst @@ -615,7 +615,7 @@ Buffer Flags :ref:`VIDIOC_DQBUF ` ioctl is called. Due to hardware limitations, the last buffer may be empty. In this case the driver will set the ``bytesused`` field to 0, regardless of - the format. Any Any subsequent call to the + the format. Any subsequent call to the :ref:`VIDIOC_DQBUF ` ioctl will not block anymore, but return an ``EPIPE`` error code. * .. _`V4L2-BUF-FLAG-REQUEST-FD`:
[PATCH 11/11] Documentation: userspace-api/media: v4l/vidioc-qbuf: drop doubled word
Drop the doubled word "the". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Mauro Carvalho Chehab Cc: linux-me...@vger.kernel.org --- Documentation/userspace-api/media/v4l/vidioc-qbuf.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/userspace-api/media/v4l/vidioc-qbuf.rst +++ linux-next-20200701/Documentation/userspace-api/media/v4l/vidioc-qbuf.rst @@ -171,7 +171,7 @@ EINVAL The buffer ``type`` is not supported, or the ``index`` is out of bounds, or no buffers have been allocated yet, or the ``userptr`` or ``length`` are invalid, or the ``V4L2_BUF_FLAG_REQUEST_FD`` flag was -set but the the given ``request_fd`` was invalid, or ``m.fd`` was +set but the given ``request_fd`` was invalid, or ``m.fd`` was an invalid DMABUF file descriptor. EIO
[PATCH 09/11] Documentation: userspace-api/media: v4l/vidioc-g-ext-ctrls: drop doubled word
Drop the doubled word "controls". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Mauro Carvalho Chehab Cc: linux-me...@vger.kernel.org --- Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst +++ linux-next-20200701/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst @@ -61,7 +61,7 @@ by the ``controls`` fields. To get the current value of a set of controls applications initialize the ``id``, ``size`` and ``reserved2`` fields of each struct :c:type:`v4l2_ext_control` and call the -:ref:`VIDIOC_G_EXT_CTRLS ` ioctl. String controls controls must also set the +:ref:`VIDIOC_G_EXT_CTRLS ` ioctl. String controls must also set the ``string`` field. Controls of compound types (``V4L2_CTRL_FLAG_HAS_PAYLOAD`` is set) must set the ``ptr`` field.
[PATCH 04/11] Documentation: userspace-api/media: dvb/dmx-qbuf: drop doubled word
Drop the doubled word "the". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Mauro Carvalho Chehab Cc: linux-me...@vger.kernel.org --- Documentation/userspace-api/media/dvb/dmx-qbuf.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/userspace-api/media/dvb/dmx-qbuf.rst +++ linux-next-20200701/Documentation/userspace-api/media/dvb/dmx-qbuf.rst @@ -57,7 +57,7 @@ by a :ref:`DMX_QUERYBUF` ioctl will do a When ``DMX_QBUF`` is called with a pointer to this structure, it locks the memory pages of the buffer in physical memory, so they cannot be swapped out to disk. Buffers remain locked until dequeued, until the -the device is closed. +device is closed. Applications call the ``DMX_DQBUF`` ioctl to dequeue a filled (capturing) buffer from the driver's outgoing queue.
[PATCH 02/11] Documentation: userspace-api/media: dvb/ca: drop doubled word
Drop the doubled word "and". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Mauro Carvalho Chehab Cc: linux-me...@vger.kernel.org --- Documentation/userspace-api/media/dvb/ca.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/userspace-api/media/dvb/ca.rst +++ linux-next-20200701/Documentation/userspace-api/media/dvb/ca.rst @@ -14,7 +14,7 @@ Digital TV CA Device The Digital TV CA device controls the conditional access hardware. It -can be accessed through ``/dev/dvb/adapter?/ca?``. Data types and and ioctl +can be accessed through ``/dev/dvb/adapter?/ca?``. Data types and ioctl definitions can be accessed by including ``linux/dvb/ca.h`` in your application.
[PATCH 01/11] Documentation: userspace-api/media: dvb/audio: drop doubled word
Drop the doubled word "and". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Mauro Carvalho Chehab Cc: linux-me...@vger.kernel.org --- Documentation/userspace-api/media/dvb/audio.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/userspace-api/media/dvb/audio.rst +++ linux-next-20200701/Documentation/userspace-api/media/dvb/audio.rst @@ -15,7 +15,7 @@ Digital TV Audio Device The Digital TV audio device controls the MPEG2 audio decoder of the Digital TV hardware. It can be accessed through ``/dev/dvb/adapter?/audio?``. Data -types and and ioctl definitions can be accessed by including +types and ioctl definitions can be accessed by including ``linux/dvb/audio.h`` in your application. Please note that some Digital TV cards don’t have their own MPEG decoder, which
[PATCH 00/11] Documentation: userspace-api/media: eliminate duplicated words
Drop all doubled words in Documenation/userspace-api/media/ files. Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Mauro Carvalho Chehab Cc: linux-me...@vger.kernel.org Documentation/userspace-api/media/dvb/audio.rst |2 +- Documentation/userspace-api/media/dvb/ca.rst |2 +- Documentation/userspace-api/media/dvb/demux.rst |2 +- Documentation/userspace-api/media/dvb/dmx-qbuf.rst|2 +- Documentation/userspace-api/media/dvb/net.rst |2 +- Documentation/userspace-api/media/dvb/video.rst |2 +- Documentation/userspace-api/media/v4l/buffer.rst |2 +- Documentation/userspace-api/media/v4l/selection-api-configuration.rst |2 +- Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst |2 +- Documentation/userspace-api/media/v4l/vidioc-g-output.rst |2 +- Documentation/userspace-api/media/v4l/vidioc-qbuf.rst |2 +- 11 files changed, 11 insertions(+), 11 deletions(-)
[PATCH 03/11] Documentation: userspace-api/media: dvb/demux: drop doubled word
Drop the doubled word "and". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Mauro Carvalho Chehab Cc: linux-me...@vger.kernel.org --- Documentation/userspace-api/media/dvb/demux.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200701.orig/Documentation/userspace-api/media/dvb/demux.rst +++ linux-next-20200701/Documentation/userspace-api/media/dvb/demux.rst @@ -18,7 +18,7 @@ digital TV. If the driver and hardware s implemented at the hardware. Otherwise, the Kernel provides a software emulation. -It can be accessed through ``/dev/adapter?/demux?``. Data types and and +It can be accessed through ``/dev/adapter?/demux?``. Data types and ioctl definitions can be accessed by including ``linux/dvb/dmx.h`` in your application.
My Greetings
My Dear My Name is Mrs. Anna H. Bruun, from Norway. I know that this message will be a surprise to you. Firstly, I am married to Mr. Patrick Bruun, A gold merchant who owns a small gold Mine in Burkina Faso; He died of Cardiovascular Disease in mid-March 2011. During his life time he deposited the sum of € 8.5 Million Euro) Eight million, Five hundred thousand Euros in a bank in Ouagadougou the capital city of Burkina Faso. The deposited money was from the sale of the shares, death benefits payment and entitlements of my deceased husband by his company. I am sending this message to you praying that it will reach you in good health, since I am not in good health condition in which I sleep every night without knowing if I may be alive to see the next day. I am suffering from long time cancer and presently i am partially suffering from a stroke illness which has become almost impossible for me to move around. I am married to my late husband for over 4 years before he died and is unfortunately that we don't have a child, my doctor confided in me that i have less chance to live. Having known my health condition, I decided to contact you to claim the fund since I don't have any relation I grew up from the orphanage home, I have decided to donate what I have to you for the support of helping Motherless babies/Less privileged/Widows' because I am dying and diagnosed of cancer for about 2 years ago. I have been touched by God Almighty to donate from what I have inherited from my late husband to you for good work of God Almighty. I have asked Almighty God to forgive me and believe he has, because He is a Merciful God I will be going in for an operation surgery soon This is the reason i need your services to stand as my next of kin or an executor to claim the funds for charity purposes. If this money remains unclaimed after my death, the bank executives or the government will take the money as unclaimed fund and maybe use it for selfish and worthless ventures, I need a very honest person who can claim this money and use it for Charity works, for orphanages, widows and also build schools for less privilege that will be named after my late husband and my name; I need your urgent answer to know if you will be able to execute this project, and I will give you more Information on how the fund will be transferred to your bank account. Thanks Mrs. Anna H.
Re: [PATCH net-next v2 0/7] Add devlink-health support for devlink ports
On Fri, 3 Jul 2020 06:27:31 +0300 Moshe Shemesh wrote: > Implement support for devlink health reporters on per-port basis. First > part in the series prepares common functions parts for health reporter > implementation. Second introduces required API to devlink-health and > mlx5e ones demonstrate its usage and effectively implement the feature > for mlx5 driver. > The per-port reporter functionality is achieved by adding a list of > devlink_health_reporters to devlink_port struct in a manner similar to > existing device infrastructure. This is the only major difference and > it makes possible to fully reuse device reporters operations. > The effect will be seen in conjunction with iproute2 additions and > will affect all devlink health commands. User can distinguish between > device and port reporters by looking at a devlink handle. Port reporters > have a port index at the end of the address and such addresses can be > provided as a parameter in every place where devlink-health accepted it. > These can be obtained from devlink port show command. > For example: > $ devlink health show > pci/:00:0a.0: > reporter fw > state healthy error 0 recover 0 auto_dump true > pci/:00:0a.0/1: > reporter tx > state healthy error 0 recover 0 grace_period 500 auto_recover true > auto_dump true > $ devlink health set pci/:00:0a.0/1 reporter tx grace_period 1000 \ > auto_recover false auto_dump false > $ devlink health show pci/:00:0a.0/1 reporter tx > pci/:00:0a.0/1: > reporter tx > state healthy error 0 recover 0 grace_period 1000 auto_recover flase > auto_dump false What's the motivation, though? This patch series achieves nothing that couldn't be previously achieved. Is there no concern of uAPI breakage with moving the existing health reporters in patch 7?
drivers/dma/at_hdmac.c:941:15: sparse: sparse: incorrect type in assignment (different address spaces)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 0c7d7d1fada70420851b63f2e2669cb4976a303b
commit: 670d0a4b10704667765f7d18f7592993d02783aa sparse: use identifiers to
define address spaces
date: 2 weeks ago
config: arm-randconfig-s031-20200703 (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-3-gfa153962-dirty
git checkout 670d0a4b10704667765f7d18f7592993d02783aa
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=arm
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
>> drivers/dma/at_hdmac.c:941:15: sparse: sparse: incorrect type in assignment
>> (different address spaces) @@ expected void [noderef] __iomem *vaddr @@
>>got void * @@
>> drivers/dma/at_hdmac.c:941:15: sparse: expected void [noderef] __iomem
>> *vaddr
drivers/dma/at_hdmac.c:941:15: sparse: got void *
>> drivers/dma/at_hdmac.c:947:11: sparse: sparse: cast removes address space
>> '__iomem' of expression
>> drivers/dma/at_hdmac.c:957:28: sparse: sparse: incorrect type in assignment
>> (different address spaces) @@ expected int *memset_vaddr @@ got void
>> [noderef] __iomem *vaddr @@
drivers/dma/at_hdmac.c:957:28: sparse: expected int *memset_vaddr
>> drivers/dma/at_hdmac.c:957:28: sparse: got void [noderef] __iomem *vaddr
>> drivers/dma/at_hdmac.c:971:43: sparse: sparse: incorrect type in argument 2
>> (different address spaces) @@ expected void *vaddr @@ got void
>> [noderef] __iomem *vaddr @@
drivers/dma/at_hdmac.c:971:43: sparse: expected void *vaddr
drivers/dma/at_hdmac.c:971:43: sparse: got void [noderef] __iomem *vaddr
drivers/dma/at_hdmac.c:999:15: sparse: sparse: incorrect type in assignment
(different address spaces) @@ expected void [noderef] __iomem *vaddr @@
got void * @@
drivers/dma/at_hdmac.c:999:15: sparse: expected void [noderef] __iomem
*vaddr
drivers/dma/at_hdmac.c:999:15: sparse: got void *
drivers/dma/at_hdmac.c:1005:11: sparse: sparse: cast removes address space
'__iomem' of expression
drivers/dma/at_hdmac.c:1034:28: sparse: sparse: incorrect type in assignment
(different address spaces) @@ expected int *memset_vaddr @@ got void
[noderef] __iomem *vaddr @@
drivers/dma/at_hdmac.c:1034:28: sparse: expected int *memset_vaddr
drivers/dma/at_hdmac.c:1034:28: sparse: got void [noderef] __iomem *vaddr
vim +941 drivers/dma/at_hdmac.c
ce2a673d66b2ca Maxime Ripard 2015-10-22 909
4d112426c3446d Maxime Ripard 2015-08-24 910 /**
4d112426c3446d Maxime Ripard 2015-08-24 911 * atc_prep_dma_memset - prepare
a memcpy operation
4d112426c3446d Maxime Ripard 2015-08-24 912 * @chan: the channel to prepare
operation on
4d112426c3446d Maxime Ripard 2015-08-24 913 * @dest: operation virtual
destination address
4d112426c3446d Maxime Ripard 2015-08-24 914 * @value: value to set memory
buffer to
4d112426c3446d Maxime Ripard 2015-08-24 915 * @len: operation length
4d112426c3446d Maxime Ripard 2015-08-24 916 * @flags: tx descriptor status
flags
4d112426c3446d Maxime Ripard 2015-08-24 917 */
4d112426c3446d Maxime Ripard 2015-08-24 918 static struct
dma_async_tx_descriptor *
4d112426c3446d Maxime Ripard 2015-08-24 919 atc_prep_dma_memset(struct
dma_chan *chan, dma_addr_t dest, int value,
4d112426c3446d Maxime Ripard 2015-08-24 920size_t len,
unsigned long flags)
4d112426c3446d Maxime Ripard 2015-08-24 921 {
4d112426c3446d Maxime Ripard 2015-08-24 922struct at_dma *atdma
= to_at_dma(chan->device);
ce2a673d66b2ca Maxime Ripard 2015-10-22 923struct at_desc *desc;
ce2a673d66b2ca Maxime Ripard 2015-10-22 924void __iomem*vaddr;
ce2a673d66b2ca Maxime Ripard 2015-10-22 925dma_addr_t paddr;
4d112426c3446d Maxime Ripard 2015-08-24 926
2c5d7407e01272 Arnd Bergmann 2015-11-12 927dev_vdbg(chan2dev(chan), "%s:
d%pad v0x%x l0x%zx f0x%lx\n", __func__,
2c5d7407e01272 Arnd Bergmann 2015-11-12 928, value, len,
flags);
4d112426c3446d Maxime Ripard 2015-08-24 929
4d112426c3446d Maxime Ripard 2015-08-24 930if (unlikely(!len)) {
4d112426c3446d Maxime Ripard 2015-08-24 931dev_dbg(chan2dev(chan),
"%s: length is zero!\n", __func__);
4d112426c3446d Maxime Ripard 2015-08-24 932return NULL;
4d112426c3446d Maxime Ripard 2015-08-24 933}
4d112426c3446d Maxime Ripard
KASAN: stack-out-of-bounds Read in csd_lock_record
Hello, syzbot found the following crash on: HEAD commit:9e50b94b Add linux-next specific files for 20200703 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=1024b40510 kernel config: https://syzkaller.appspot.com/x/.config?x=f99cc0faa1476ed6 dashboard link: https://syzkaller.appspot.com/bug?extid=0f719294463916a3fc0e compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16dc490f10 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+0f719294463916a3f...@syzkaller.appspotmail.com == BUG: KASAN: stack-out-of-bounds in csd_lock_record+0xcb/0xe0 kernel/smp.c:118 Read of size 8 at addr c90001727710 by task syz-executor.0/10721 CPU: 1 PID: 10721 Comm: syz-executor.0 Not tainted 5.8.0-rc3-next-20200703-syzkaller #0 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+0x18f/0x20d lib/dump_stack.c:118 print_address_description.constprop.0.cold+0x5/0x436 mm/kasan/report.c:383 __kasan_report mm/kasan/report.c:513 [inline] kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530 csd_lock_record+0xcb/0xe0 kernel/smp.c:118 flush_smp_call_function_queue+0x285/0x730 kernel/smp.c:391 __sysvec_call_function_single+0x98/0x490 arch/x86/kernel/smp.c:248 asm_call_on_stack+0xf/0x20 arch/x86/entry/entry_64.S:706 __run_on_irqstack arch/x86/include/asm/irq_stack.h:22 [inline] run_on_irqstack_cond arch/x86/include/asm/irq_stack.h:48 [inline] sysvec_call_function_single+0xe0/0x120 arch/x86/kernel/smp.c:243 asm_sysvec_call_function_single+0x12/0x20 arch/x86/include/asm/idtentry.h:604 RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:765 [inline] RIP: 0010:__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:160 [inline] RIP: 0010:_raw_spin_unlock_irqrestore+0x8c/0xe0 kernel/locking/spinlock.c:191 Code: 48 c7 c0 00 ff b4 89 48 ba 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00 75 37 48 83 3d 9b 74 c8 01 00 74 22 48 89 df 57 9d <0f> 1f 44 00 00 bf 01 00 00 00 e8 95 fb 62 f9 65 8b 05 fe 73 15 78 RSP: 0018:c900016e7558 EFLAGS: 0282 RAX: 11369fe0 RBX: 0282 RCX: RDX: dc00 RSI: RDI: 0282 RBP: 8cb02508 R08: R09: R10: 0001 R11: R12: 119604a0 R13: R14: dead0100 R15: dc00 __debug_check_no_obj_freed lib/debugobjects.c:977 [inline] debug_check_no_obj_freed+0x20c/0x41c lib/debugobjects.c:998 free_pages_prepare mm/page_alloc.c:1219 [inline] __free_pages_ok+0x20b/0xc90 mm/page_alloc.c:1471 release_pages+0x5ec/0x17a0 mm/swap.c:880 tlb_batch_pages_flush mm/mmu_gather.c:49 [inline] tlb_flush_mmu_free mm/mmu_gather.c:242 [inline] tlb_flush_mmu+0xe9/0x6b0 mm/mmu_gather.c:249 zap_pte_range mm/memory.c:1155 [inline] zap_pmd_range mm/memory.c:1193 [inline] zap_pud_range mm/memory.c:1222 [inline] zap_p4d_range mm/memory.c:1243 [inline] unmap_page_range+0x1e22/0x2b20 mm/memory.c:1264 unmap_single_vma+0x198/0x300 mm/memory.c:1309 unmap_vmas+0x16f/0x2f0 mm/memory.c:1341 exit_mmap+0x2b1/0x530 mm/mmap.c:3165 __mmput+0x122/0x470 kernel/fork.c:1075 mmput+0x53/0x60 kernel/fork.c:1096 exit_mm kernel/exit.c:483 [inline] do_exit+0xa8f/0x2a40 kernel/exit.c:793 do_group_exit+0x125/0x310 kernel/exit.c:904 get_signal+0x40b/0x1ee0 kernel/signal.c:2743 do_signal+0x82/0x2520 arch/x86/kernel/signal.c:810 exit_to_usermode_loop arch/x86/entry/common.c:218 [inline] __prepare_exit_to_usermode+0x156/0x1f0 arch/x86/entry/common.c:252 do_syscall_64+0x6c/0xe0 arch/x86/entry/common.c:376 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x45cb29 Code: Bad RIP value. RSP: 002b:7fb154b96cf8 EFLAGS: 0246 ORIG_RAX: 00ca RAX: 0001 RBX: 0078bf08 RCX: 0045cb29 RDX: 000f4240 RSI: 0081 RDI: 0078bf0c RBP: 0078bf00 R08: R09: R10: R11: 0246 R12: 0078bf0c R13: 7ffd3933f26f R14: 7fb154b979c0 R15: 0078bf0c Memory state around the buggy address: c90001727600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c90001727680: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 >c90001727700: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 ^ c90001727780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c90001727800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 == --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com
kernel BUG at net/rxrpc/recvmsg.c:LINE!
Hello, syzbot found the following crash on: HEAD commit:aab20039 Add linux-next specific files for 20200701 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=17a00a5b10 kernel config: https://syzkaller.appspot.com/x/.config?x=739f6fbf326049f4 dashboard link: https://syzkaller.appspot.com/bug?extid=b54969381df354936d96 compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17ee0fe510 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12ea774b10 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+b54969381df354936...@syzkaller.appspotmail.com [ cut here ] kernel BUG at net/rxrpc/recvmsg.c:605! invalid opcode: [#1] PREEMPT SMP KASAN CPU: 0 PID: 6856 Comm: syz-executor134 Not tainted 5.8.0-rc3-next-20200701-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:rxrpc_recvmsg+0x18ab/0x1a03 net/rxrpc/recvmsg.c:605 Code: 89 e7 e8 58 39 6b fa e9 eb fc ff ff e8 4e 39 6b fa e9 33 ef ff ff 48 8b 7c 24 10 e8 3f 39 6b fa e9 dc ee ff ff e8 35 a4 2b fa <0f> 0b 48 8b 7c 24 10 e8 29 39 6b fa e9 76 ee ff ff 48 89 ef e8 0c RSP: 0018:c90001637858 EFLAGS: 00010293 RAX: RBX: 8880a182c278 RCX: 874835d7 RDX: 888096f4c000 RSI: 8748473b RDI: 0001 RBP: 888096ffe740 R08: R09: 8880a182c327 R10: R11: R12: 0001 R13: 8880a182c080 R14: R15: 8880a182c320 FS: 7f23bbcf5700() GS:8880ae60() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 006da0f0 CR3: 9ec2f000 CR4: 001506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: sock_recvmsg_nosec net/socket.c:886 [inline] sock_recvmsg net/socket.c:904 [inline] sock_recvmsg net/socket.c:900 [inline] sys_recvmsg+0x2c4/0x640 net/socket.c:2575 ___sys_recvmsg+0x127/0x200 net/socket.c:2617 do_recvmmsg+0x24d/0x6d0 net/socket.c:2715 __sys_recvmmsg net/socket.c:2794 [inline] __do_sys_recvmmsg net/socket.c:2817 [inline] __se_sys_recvmmsg net/socket.c:2810 [inline] __x64_sys_recvmmsg+0x20b/0x260 net/socket.c:2810 do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:359 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x446899 Code: Bad RIP value. RSP: 002b:7f23bbcf4d98 EFLAGS: 0246 ORIG_RAX: 012b RAX: ffda RBX: 006dbc38 RCX: 00446899 RDX: 0001 RSI: 2100 RDI: 0003 RBP: 006dbc30 R08: R09: R10: R11: 0246 R12: 006dbc3c R13: 0007 R14: 00010110 R15: 0018 Modules linked in: ---[ end trace abf499f6a2f7b5ae ]--- RIP: 0010:rxrpc_recvmsg+0x18ab/0x1a03 net/rxrpc/recvmsg.c:605 Code: 89 e7 e8 58 39 6b fa e9 eb fc ff ff e8 4e 39 6b fa e9 33 ef ff ff 48 8b 7c 24 10 e8 3f 39 6b fa e9 dc ee ff ff e8 35 a4 2b fa <0f> 0b 48 8b 7c 24 10 e8 29 39 6b fa e9 76 ee ff ff 48 89 ef e8 0c RSP: 0018:c90001637858 EFLAGS: 00010293 RAX: RBX: 8880a182c278 RCX: 874835d7 RDX: 888096f4c000 RSI: 8748473b RDI: 0001 RBP: 888096ffe740 R08: R09: 8880a182c327 R10: R11: R12: 0001 R13: 8880a182c080 R14: R15: 8880a182c320 FS: 7f23bbcf5700() GS:8880ae60() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 006da0f0 CR3: 9ec2f000 CR4: 001506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: [PATCH 1/2] spi: Add the SPI daisy chain support.
Hi Adrian,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on spi/for-next]
[also build test WARNING on v5.8-rc3 next-20200703]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Adrian-Fiergolski/spi-Add-the-SPI-daisy-chain-support/20200703-221615
base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
config: x86_64-allyesconfig (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project
ca464639a1c9dd3944eb055ffd2796e8c2e7639f)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/spi/spi-daisy_chain.c:232:6: warning: no previous prototype for
>> function 'spi_daisy_chain_clean' [-Wmissing-prototypes]
void spi_daisy_chain_clean(struct list_head *daisy_chain_devs)
^
drivers/spi/spi-daisy_chain.c:232:1: note: declare 'static' if the function
is not intended to be used outside of this translation unit
void spi_daisy_chain_clean(struct list_head *daisy_chain_devs)
^
static
1 warning generated.
vim +/spi_daisy_chain_clean +232 drivers/spi/spi-daisy_chain.c
231
> 232 void spi_daisy_chain_clean(struct list_head *daisy_chain_devs)
233 {
234 struct spi_device *spi_dev;
235 struct spi_daisy_chain_device *spi_chain_dev;
236
237 list_for_each_entry(spi_chain_dev, daisy_chain_devs, devices) {
238 spi_dev = spi_chain_dev->spi;
239 spi_dev_put(spi_dev);
240 kfree(spi_chain_dev->no_operation.tx_buf);
241 kfree(spi_chain_dev);
242 }
243 list_del(daisy_chain_devs);
244 kfree(daisy_chain_devs);
245 }
246
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
WARNING in rxrpc_recvmsg
Hello, syzbot found the following crash on: HEAD commit:cd77006e Merge tag 'hyperv-fixes-signed' of git://git.kern.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=134c490f10 kernel config: https://syzkaller.appspot.com/x/.config?x=7be693511b29b338 dashboard link: https://syzkaller.appspot.com/bug?extid=1a68d5c4e74edea44294 compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1176e39b10 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=144c9e6d10 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+1a68d5c4e74edea44...@syzkaller.appspotmail.com [ cut here ] DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 0 PID: 11007 at kernel/locking/mutex.c:1415 mutex_trylock+0x220/0x2c0 kernel/locking/mutex.c:1415 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 11007 Comm: syz-executor947 Not tainted 5.8.0-rc3-syzkaller #0 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+0x18f/0x20d lib/dump_stack.c:118 panic+0x2e3/0x75c kernel/panic.c:231 __warn.cold+0x20/0x45 kernel/panic.c:600 report_bug+0x1bd/0x210 lib/bug.c:198 handle_bug+0x38/0x90 arch/x86/kernel/traps.c:235 exc_invalid_op+0x13/0x40 arch/x86/kernel/traps.c:255 asm_exc_invalid_op+0x12/0x20 arch/x86/include/asm/idtentry.h:563 RIP: 0010:mutex_trylock+0x220/0x2c0 kernel/locking/mutex.c:1415 Code: 08 84 d2 0f 85 99 00 00 00 8b 3d cb 07 c8 02 85 ff 0f 85 6a fe ff ff 48 c7 c6 60 9c 4b 88 48 c7 c7 20 9a 4b 88 e8 82 77 5e f9 <0f> 0b e9 50 fe ff ff ff 74 24 38 48 8d 7b 68 45 31 c9 31 c9 41 b8 RSP: 0018:c90008757818 EFLAGS: 00010282 RAX: RBX: 888093a14378 RCX: RDX: 8880924b61c0 RSI: 815d4f47 RDI: f520010eaef5 RBP: 888093a14000 R08: R09: 89bb5ba3 R10: 059f R11: 0001 R12: 8c90d1a0 R13: 888093a14340 R14: R15: 888093a14538 rxrpc_recvmsg+0x695/0x1a03 net/rxrpc/recvmsg.c:593 sock_recvmsg_nosec net/socket.c:886 [inline] sock_recvmsg net/socket.c:904 [inline] sock_recvmsg net/socket.c:900 [inline] sys_recvmsg+0x2c4/0x640 net/socket.c:2575 ___sys_recvmsg+0x127/0x200 net/socket.c:2617 do_recvmmsg+0x24d/0x6d0 net/socket.c:2715 __sys_recvmmsg net/socket.c:2794 [inline] __do_sys_recvmmsg net/socket.c:2817 [inline] __se_sys_recvmmsg net/socket.c:2810 [inline] __x64_sys_recvmmsg+0x20b/0x260 net/socket.c:2810 do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:359 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x447b79 Code: Bad RIP value. RSP: 002b:7fdf4e75dce8 EFLAGS: 0246 ORIG_RAX: 012b RAX: ffda RBX: 006dcc48 RCX: 00447b79 RDX: 0001 RSI: 2100 RDI: 0004 RBP: 006dcc40 R08: R09: R10: R11: 0246 R12: 006dcc4c R13: 7ffc658e40ef R14: 7fdf4e75e9c0 R15: 20c49ba5e353f7cf Kernel Offset: disabled Rebooting in 86400 seconds.. --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: [PATCH v33 11/21] x86/sgx: Linux Enclave Driver
On Fri, Jun 26, 2020 at 04:20:19PM +0200, Borislav Petkov wrote: > On Fri, Jun 26, 2020 at 07:16:27AM -0700, Sean Christopherson wrote: > > That being said, I agree that it would be safer to move > > sgx_calc_ssaframesize() > > inside sgx_validate_secs() and only compute encl_size after the secs is > > validated. > Changed as if (!secs->ssa_frame_size) return -EINVAL; if (sgx_calc_ssa_frame_size(secs->miscselect, secs->xfrm) > secs->ssa_frame_size) return -EINVAL; /Jarkko
