Re: [PATCH v11 26/26] s390: doc: detailed specifications for AP virtualization
On 27.09.2018 00:42, Alex Williamson wrote: > On Tue, 25 Sep 2018 19:16:41 -0400 > Tony Krowiak wrote: > >> From: Tony Krowiak >> >> This patch provides documentation describing the AP architecture and >> design concepts behind the virtualization of AP devices. It also >> includes an example of how to configure AP devices for exclusive >> use of KVM guests. >> >> Signed-off-by: Tony Krowiak >> Reviewed-by: Halil Pasic >> --- >> Documentation/s390/vfio-ap.txt | 782 + >> MAINTAINERS| 1 + >> 2 files changed, 783 insertions(+) >> create mode 100644 Documentation/s390/vfio-ap.txt > ... >> +Example: >> +=== >> +Let's now provide an example to illustrate how KVM guests may be given >> +access to AP facilities. For this example, we will show how to configure >> +three guests such that executing the lszcrypt command on the guests would >> +look like this: >> + >> +Guest1 >> +-- >> +CARD.DOMAIN TYPE MODE >> +-- >> +05 CEX5C CCA-Coproc >> +05.0004 CEX5C CCA-Coproc >> +05.00ab CEX5C CCA-Coproc >> +06 CEX5A Accelerator >> +06.0004 CEX5A Accelerator >> +06.00ab CEX5C CCA-Coproc >> + >> +Guest2 >> +-- >> +CARD.DOMAIN TYPE MODE >> +-- >> +05 CEX5A Accelerator >> +05.0047 CEX5A Accelerator >> +05.00ff CEX5A Accelerator (5,4), (5,171), (6,4), (6,171), > ^^^ > Seems like an unfinished thought here. > >> + >> +Guest2 >> +-- >> +CARD.DOMAIN TYPE MODE >> +-- >> +06 CEX5A Accelerator >> +06.0047 CEX5A Accelerator >> +06.00ff CEX5A Accelerator >> + >> +These are the steps: >> + >> +1. Install the vfio_ap module on the linux host. The dependency chain for >> the >> + vfio_ap module is: >> + * iommu >> + * s390 >> + * zcrypt >> + * vfio >> + * vfio_mdev >> + * vfio_mdev_device >> + * KVM >> + >> + To build the vfio_ap module, the kernel build must be configured with the >> + following Kconfig elements selected: >> + * IOMMU_SUPPORT >> + * S390 >> + * ZCRYPT >> + * S390_AP_IOMMU >> + * VFIO >> + * VFIO_MDEV >> + * VFIO_MDEV_DEVICE >> + * KVM >> + >> + If using make menuconfig select the following to build the vfio_ap >> module: >> + -> Device Drivers >> + -> IOMMU Hardware Support >> + select S390 AP IOMMU Support >> + -> VFIO Non-Privileged userspace driver framework >> + -> Mediated device driver frramework >> +-> VFIO driver for Mediated devices >> + -> I/O subsystem >> + -> VFIO support for AP devices >> + >> +2. Secure the AP queues to be used by the three guests so that the host can >> not >> + access them. To secure them, there are two sysfs files that specify >> + bitmasks marking a subset of the APQN range as 'usable by the default AP >> + queue device drivers' or 'not usable by the default device drivers' and >> thus >> + available for use by the vfio_ap device driver'. The sysfs files >> containing >> + the sysfs locations of the masks are: >> + >> + /sys/bus/ap/apmask >> + /sys/bus/ap/aqmask >> + >> + The 'apmask' is a 256-bit mask that identifies a set of AP adapter IDs >> + (APID). Each bit in the mask, from most significant to least significant >> bit, >> + corresponds to an APID from 0-255. If a bit is set, the APID is marked as >> + usable only by the default AP queue device drivers; otherwise, the APID >> is >> + usable by the vfio_ap device driver. >> + >> + The 'aqmask' is a 256-bit mask that identifies a set of AP queue indexes >> + (APQI). Each bit in the mask, from most significant to least significant >> bit, >> + corresponds to an APQI from 0-255. If a bit is set, the APQI is marked as >> + usable only by the default AP queue device drivers; otherwise, the APQI >> is >> + usable by the vfio_ap device driver. >> + >> + The APQN of each AP queue device assigned to the linux host is checked >> by the >> + AP bus against the set of APQNs derived from the cross product of APIDs >> + and APQIs marked as usable only by the default AP queue device drivers. >> If a >> + match is detected, only the default AP queue device drivers will be >> probed; >> + otherwise, the vfio_ap device driver will be probed. >> + >> + By default, the two masks are set to reserve all APQNs for use by the >> default >> + AP queue device drivers. There are two ways the default masks can be >> changed: >> + >> + 1. The masks can be changed at boot time with the kernel command line >> + like this: >> + >> + ap.apmask=0x ap.aqmask=0x40 >> + >> + This would give these two pools: >> + >> +default drivers pool:adapter 0-15, domain 1 >> +alternate drivers pool: adapter 16-255, domains 2-255 > What happened to domain 0? I'm also a little confused by the bit
Re: [PATCH v2] gpiolib: Show correct direction from the beginning
Quoting Ricardo Ribalda Delgado (2018-09-21 03:36:04) > Current code assumes that the direction is input if direction_input > function is set. > This might not be the case on GPIOs with programmable direction. > > Signed-off-by: Ricardo Ribalda Delgado > --- Looks OK to me visually. I haven't tested it because I don't have access to the locked down hardware anymore. Reviewed-by: Stephen Boyd
Re: [PATCH v2, RESEND 0/3] tpm: retrieve digest size of unknown algorithms from TPM
On 9/26/2018 8:03 PM, Mimi Zohar wrote: On Wed, 2018-09-26 at 10:40 -0400, Mimi Zohar wrote: On Mon, 2018-09-17 at 11:38 +0200, Roberto Sassu wrote: Resending to maintainer with correct mailing lists in CC. The TPM driver currently relies on the crypto subsystem to determine the digest size of supported TPM algorithms. In the future, TPM vendors might implement new algorithms in their chips, and those algorithms might not be supported by the crypto subsystem. Usually, vendors provide patches for the new hardware, and likely the crypto subsystem will be updated before the new algorithm is introduced. However, old kernels might be updated later, after patches are included in the mainline kernel. This would leave the opportunity for attackers to misuse PCRs, as PCR banks with an unknown algorithm are not extended. This patch set provides a long term solution for this issue. If a TPM algorithm is not known by the crypto subsystem, the TPM driver retrieves the digest size from the TPM with a PCR read. All the PCR banks are extended, even if the algorithm is not yet supported by the crypto subsystem. Other than checking the digest size before copying the pcrread buffer, the patches look good. Please add my Ack on all 3 patches. (New address) Acked-by: Mimi Zohar I've reviewed, and am currently running with these patches. Even if the IMA changes were in a separate patch, we wouldn't be able to break up the patch set anyway. Jarkko, I'd appreciate your carrying the entire patch set. Roberto, a similar change needs to be made for tpm_pcr_extend. Are you planning on posting those changes as well? Yes, I was planning to send the patch after this patch set is accepted. Roberto
Re: [PATCH v4 1/2] Bluetooth: Add device_get_bd_address()
On Wed, Sep 26, 2018 at 05:48:09PM -0700, Matthias Kaehlcke wrote: > Provide an API for Bluetooth drivers to retrieve the Bluetooth Device > address (BD_ADDR) for a device. If the firmware node of the device > has a property 'local-bd-address' the BD address is read from this > property. > > Signed-off-by: Matthias Kaehlcke > Reviewed-by: Andy Shevchenko > Reviewed-by: Sakari Ailus > --- > Changes in v4: > - move code from driver/base/property.c to net/bluetooth/lib.c > - undo move of bdaddr_t declaration > - merge fwnode_get_bd_address() into device_get_bd_address(). as of now > the function is not needed, it can be created later if necessary > - minor improvements suggested by Sakari > - updated commit message > - added 'Reviewed-by: Sakari Ailus ' tag > > Changes in v3: > - move definition of bdaddr_t to types.h to avoid include of > bluetooth.h from property.h > - add stubs for the new functions > > Changes in v2: > - use bdaddr_t instead of byte pointer + len > - use EXPORT_SYMBOL_GPL for the new functions instead of EXPORT_SYMBOL > - put new functions inside #if IS_ENABLED(CONFIG_BT) > - some new line juggling in property.h > - added 'Reviewed-by: Andy Shevchenko ' tag > --- > include/net/bluetooth/bluetooth.h | 2 ++ > net/bluetooth/lib.c | 34 +++ Yeah, this seems like a better place for this stuff indeed. Thanks! -- Sakari Ailus sakari.ai...@linux.intel.com
Re: [PATCH v2] dt-bindings: input: pwm-vibrator: correct pwms in example
Hi,
On Wed, Sep 26, 2018 at 08:48:58PM -0400, Brian Masney wrote:
> In the example for the pwm-vibrator bindings, pwm8 is the direction pin,
> and pwm9 is the enable pin. The pwms on the vibrator node has these two
> values swapped so this patch corrects it.
>
> Signed-off-by: Brian Masney
> ---
>
> Changes since v1:
> - Swapped the pwms values instead of the pwm-names values since enable
> is required and direction is optional. Based on feedback from
> Rob Herring.
>
> Documentation/devicetree/bindings/input/pwm-vibrator.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/input/pwm-vibrator.txt
> b/Documentation/devicetree/bindings/input/pwm-vibrator.txt
> index 09145d18491d..88c775a3fe21 100644
> --- a/Documentation/devicetree/bindings/input/pwm-vibrator.txt
> +++ b/Documentation/devicetree/bindings/input/pwm-vibrator.txt
> @@ -58,8 +58,8 @@ Example from Motorola Droid 4:
>
> vibrator {
> compatible = "pwm-vibrator";
> - pwms = <&pwm8 0 10 0>,
> -<&pwm9 0 10 0>;
> + pwms = <&pwm9 0 10 0>,
> + <&pwm8 0 10 0>;
> pwm-names = "enable", "direction";
> direction-duty-cycle-ns = <10>;
> };
Reviewed-by: Sebastian Reichel
-- Sebastian
signature.asc
Description: PGP signature
[PATCH v24 2/2] soc: mediatek: Add Mediatek CMDQ helper
Add Mediatek CMDQ helper to create CMDQ packet and assemble GCE op code.
Signed-off-by: Houlong Wei
Signed-off-by: HS Liao
---
drivers/soc/mediatek/Kconfig | 12 ++
drivers/soc/mediatek/Makefile |1 +
drivers/soc/mediatek/mtk-cmdq-helper.c | 292
include/linux/soc/mediatek/mtk-cmdq.h | 133 +++
4 files changed, 438 insertions(+)
create mode 100644 drivers/soc/mediatek/mtk-cmdq-helper.c
create mode 100644 include/linux/soc/mediatek/mtk-cmdq.h
diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index a7d0667..17bd759 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -4,6 +4,18 @@
menu "MediaTek SoC drivers"
depends on ARCH_MEDIATEK || COMPILE_TEST
+config MTK_CMDQ
+ tristate "MediaTek CMDQ Support"
+ depends on ARCH_MEDIATEK || COMPILE_TEST
+ select MAILBOX
+ select MTK_CMDQ_MBOX
+ select MTK_INFRACFG
+ help
+ Say yes here to add support for the MediaTek Command Queue (CMDQ)
+ driver. The CMDQ is used to help read/write registers with critical
+ time limitation, such as updating display configuration during the
+ vblank.
+
config MTK_INFRACFG
bool "MediaTek INFRACFG Support"
select REGMAP
diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
index 12998b0..64ce5ee 100644
--- a/drivers/soc/mediatek/Makefile
+++ b/drivers/soc/mediatek/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o
obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc/mediatek/mtk-cmdq-helper.c
new file mode 100644
index 000..3482dd7
--- /dev/null
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -0,0 +1,292 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (c) 2018 MediaTek Inc.
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define CMDQ_ARG_A_WRITE_MASK 0x
+#define CMDQ_WRITE_ENABLE_MASK BIT(0)
+#define CMDQ_EOC_IRQ_ENBIT(0)
+#define CMDQ_EOC_CMD ((u64)((CMDQ_CODE_EOC << CMDQ_OP_CODE_SHIFT)) \
+ << 32 | CMDQ_EOC_IRQ_EN)
+
+static void cmdq_client_timeout(struct timer_list *t)
+{
+ struct cmdq_client *client = from_timer(client, t, timer);
+
+ dev_err(client->client.dev, "cmdq timeout!\n");
+}
+
+struct cmdq_client *cmdq_mbox_create(struct device *dev, int index, u32
timeout)
+{
+ struct cmdq_client *client;
+
+ client = kzalloc(sizeof(*client), GFP_KERNEL);
+ if (!client)
+ return (struct cmdq_client *)-ENOMEM;
+
+ client->timeout_ms = timeout;
+ if (timeout != CMDQ_NO_TIMEOUT) {
+ spin_lock_init(&client->lock);
+ timer_setup(&client->timer, cmdq_client_timeout, 0);
+ }
+ client->pkt_cnt = 0;
+ client->client.dev = dev;
+ client->client.tx_block = false;
+ client->chan = mbox_request_channel(&client->client, index);
+
+ if (IS_ERR(client->chan)) {
+ long err;
+
+ dev_err(dev, "failed to request channel\n");
+ err = PTR_ERR(client->chan);
+ kfree(client);
+
+ return ERR_PTR(err);
+ }
+
+ return client;
+}
+EXPORT_SYMBOL(cmdq_mbox_create);
+
+void cmdq_mbox_destroy(struct cmdq_client *client)
+{
+ if (client->timeout_ms != CMDQ_NO_TIMEOUT) {
+ spin_lock(&client->lock);
+ del_timer_sync(&client->timer);
+ spin_unlock(&client->lock);
+ }
+ mbox_free_channel(client->chan);
+ kfree(client);
+}
+EXPORT_SYMBOL(cmdq_mbox_destroy);
+
+struct cmdq_pkt *cmdq_pkt_create(struct cmdq_client *client, size_t size)
+{
+ struct cmdq_pkt *pkt;
+ struct device *dev;
+ dma_addr_t dma_addr;
+
+ pkt = kzalloc(sizeof(*pkt), GFP_KERNEL);
+ if (!pkt)
+ return ERR_PTR(-ENOMEM);
+ pkt->va_base = kzalloc(size, GFP_KERNEL);
+ if (!pkt->va_base) {
+ kfree(pkt);
+ return ERR_PTR(-ENOMEM);
+ }
+ pkt->buf_size = size;
+ pkt->cl = (void *)client;
+
+ dev = client->chan->mbox->dev;
+ dma_addr = dma_map_single(dev, pkt->va_base, pkt->buf_size,
+ DMA_TO_DEVICE);
+ if (dma_mapping_error(dev, dma_addr)) {
+ dev_err(dev, "dma map failed, size=%u\n", (u32)(u64)size);
+ kfree(pkt->va_base);
+ kfree(pkt);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ pkt->pa_base = dma_addr;
+
+ return pkt;
+}
+EXPORT_SYMBOL(cmdq_pkt_create);
+
+void cmdq_pkt_destroy(struct cmdq_pkt *pkt)
+{
+ struct cmdq_client *client = (struct cmdq_client *)pkt->cl;
+
+ dma_unmap_single(client->chan->mbox->dev, pkt->pa_base,
[PATCH v24 1/2] arm64: dts: mt8173: Add GCE node
This patch adds the device node of the GCE hardware for CMDQ module.
Signed-off-by: Houlong Wei
Signed-off-by: HS Liao
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index abd2f15..412ffd4 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include "mt8173-pinfunc.h"
/ {
@@ -521,6 +522,15 @@
status = "disabled";
};
+ gce: mailbox@10212000 {
+ compatible = "mediatek,mt8173-gce";
+ reg = <0 0x10212000 0 0x1000>;
+ interrupts = ;
+ clocks = <&infracfg CLK_INFRA_GCE>;
+ clock-names = "gce";
+ #mbox-cells = <3>;
+ };
+
mipi_tx0: mipi-dphy@10215000 {
compatible = "mediatek,mt8173-mipi-tx";
reg = <0 0x10215000 0 0x1000>;
--
1.7.9.5
Re: [PATCH v3 2/2] spi: Introduce new driver for Qualcomm QuadSPI controller
Quoting Ryan Case (2018-09-26 13:52:04) > From: Girish Mahadevan > > New driver for Qualcomm QuadSPI(QSPI) controller that is used to > communicate with slaves such flash memory devices. The QSPI controller s/such/such as/? > can operate in 2 or 4 wire mode but only supports SPI Mode 0. The > controller can also operate in Single or Dual data rate modes. > > Signed-off-by: Girish Mahadevan > Signed-off-by: Ryan Case > --- > diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile > index 876f8690fc47..f997c49255a6 100644 > --- a/drivers/spi/Makefile > +++ b/drivers/spi/Makefile > @@ -112,3 +112,4 @@ obj-$(CONFIG_SPI_ZYNQMP_GQSPI) += > spi-zynqmp-gqspi.o > # SPI slave protocol handlers > obj-$(CONFIG_SPI_SLAVE_TIME) += spi-slave-time.o > obj-$(CONFIG_SPI_SLAVE_SYSTEM_CONTROL) += spi-slave-system-control.o > +obj-$(CONFIG_SPI_QCOM_QSPI)+= spi-qcom-qspi.o Move this to alphabetical in the SPI master controller list of this file please. > diff --git a/drivers/spi/spi-qcom-qspi.c b/drivers/spi/spi-qcom-qspi.c > new file mode 100644 > index ..0ad2ef003068 > --- /dev/null > +++ b/drivers/spi/spi-qcom-qspi.c > @@ -0,0 +1,598 @@ > +// SPDX-License-Identifier: GPL-2.0 > +// Copyright (c) 2017-2018, The Linux foundation. All rights reserved. > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > + > +#define AHB_MIN_HZ 960UL Is this used? > +#define QSPI_NUM_CS2 > +#define QSPI_BYTES_PER_WORD4 > +#define MSTR_CONFIG0x > +#define AHB_MASTER_CFG 0x0004 > +#define MSTR_INT_EN0x000C > +#define MSTR_INT_STATUS0x0010 > +#define PIO_XFER_CTRL 0x0014 > +#define PIO_XFER_CFG 0x0018 > +#define PIO_XFER_STATUS0x001c > +#define PIO_DATAOUT_1B 0x0020 > +#define PIO_DATAOUT_4B 0x0024 > +#define RD_FIFO_CFG0x0028 > +#define RD_FIFO_STATUS 0x002c > +#define RD_FIFO_RESET 0x0030 > +#define CUR_MEM_ADDR 0x0048 > +#define HW_VERSION 0x004c > +#define RD_FIFO0x0050 > +#define SAMPLING_CLK_CFG 0x0090 > +#define SAMPLING_CLK_STATUS0x0094 > + > +/* Macros to help set/get fields in MSTR_CONFIG register */ > +#defineFULL_CYCLE_MODE BIT(3) > +#defineFB_CLK_EN BIT(4) > +#definePIN_HOLDN BIT(6) > +#definePIN_WPN BIT(7) > +#defineDMA_ENABLE BIT(8) > +#defineBIG_ENDIAN_MODE BIT(9) > +#defineSPI_MODE_MSK0xc00 > +#defineSPI_MODE_SHFT 10 > +#defineCHIP_SELECT_NUM BIT(12) > +#defineSBL_EN BIT(13) > +#defineLPA_BASE_MSK0x3c000 > +#defineLPA_BASE_SHFT 14 > +#defineTX_DATA_DELAY_MSK 0xc > +#defineTX_DATA_DELAY_SHFT 18 > +#defineTX_CLK_DELAY_MSK0x30 > +#defineTX_CLK_DELAY_SHFT 20 > +#defineTX_CS_N_DELAY_MSK 0xc0 > +#defineTX_CS_N_DELAY_SHFT 22 > +#defineTX_DATA_OE_DELAY_MSK0x300 > +#defineTX_DATA_OE_DELAY_SHFT 24 > + > +/* Macros to help set/get fields in AHB_MSTR_CFG register */ > +#defineHMEM_TYPE_START_MID_TRANS_MSK 0x7 > +#defineHMEM_TYPE_START_MID_TRANS_SHFT 0 > +#defineHMEM_TYPE_LAST_TRANS_MSK0x38 > +#defineHMEM_TYPE_LAST_TRANS_SHFT 3 > +#defineUSE_HMEMTYPE_LAST_ON_DESC_OR_CHAIN_MSK 0xc0 > +#defineUSE_HMEMTYPE_LAST_ON_DESC_OR_CHAIN_SHFT 6 > +#defineHMEMTYPE_READ_TRANS_MSK 0x700 > +#defineHMEMTYPE_READ_TRANS_SHFT8 > +#defineHSHARED BIT(11) > +#defineHINNERSHAREDBIT(12) > + > +/* Macros to help set/get fields in MSTR_INT_EN/MSTR_INT_STATUS registers */ > +#defineRESP_FIFO_UNDERRUN BIT(0) > +#defineRESP_FIFO_NOT_EMPTY BIT(1) > +#defineRESP_FIFO_RDY BIT(2) > +#defineHRESP_FROM_NOC_ERR BIT(3) > +#defineWR_FIFO_EMPTY BIT(9) > +#defineWR_FIFO_FULLBIT(10) > +#defineWR_FIFO_OVERRUN BIT(11) > +#defineTRANSACTION_DONEBIT(16) > +#define QSPI_ERR_IRQS (RESP_FIFO_UNDERRUN | HRESP_FROM_NOC_ERR | \ > +WR_FIFO_OVERRUN) > +#defineQSPI_ALL_IRQS (QSPI_ERR_IRQS | RESP_FIFO_RDY | \ > +WR_FIFO_EMPTY | WR_FIFO_FULL | \ > +TRANSACTION_DONE) > + > +/* Macros to help set/get fields in RD_FIFO_CONFIG register */ > +#defineCONTINUOUS_MODE BIT(0) > + > +/* Macros to help set/get fields in
[PATCH v24 0/2] MediaTek MT8173 CMDQ support
Hi, This is Mediatek MT8173 Command Queue(CMDQ) driver. The CMDQ is used to help write registers with critical time limitation, such as updating display configuration during the vblank. It controls Global Command Engine (GCE) hardware to achieve this requirement. Changes since v23: -rebase on v4.19-rc1 -revise return value of cmdq_mbox_create() -revise cmdq_pkt_create() -add MODULE_LICENSE() for mtk-cmdq-helper.c -adjust functions order in mtk-cmdq.h Changes since v22: -remove properties 'timeout' and 'thread-num' from device tree -move timer from CMDQ driver to CMDQ helper -move dma unmap from CMDQ driver to CMDQ helper -config thread number in CMDQ match table -remove reallocate mechanism and let client specify the cmdq buffer size -let client specify the timeout time Changes since v21: -rebase on v4.18-rc1 -remove subsys code and event id definition from mtk-cmdq-helper.c -add mt8173-gce.h to define the subsys code and envent id Changes since v20: -rebase on v4.15-rc1 -move dma_map_single outside of spinlock Changes since v19: -rebase to v4.10-rc2 Houlong Wei (2): arm64: dts: mt8173: Add GCE node soc: mediatek: Add Mediatek CMDQ helper arch/arm64/boot/dts/mediatek/mt8173.dtsi | 10 + drivers/soc/mediatek/Kconfig | 12 ++ drivers/soc/mediatek/Makefile|1 + drivers/soc/mediatek/mtk-cmdq-helper.c | 292 ++ include/linux/soc/mediatek/mtk-cmdq.h| 133 ++ 5 files changed, 448 insertions(+) create mode 100644 drivers/soc/mediatek/mtk-cmdq-helper.c create mode 100644 include/linux/soc/mediatek/mtk-cmdq.h -- 1.7.9.5
Re: [PATCH v2 2/4] power: supply: core: Introduce properties to present the battery OCV table
Hi, On Thu, Sep 27, 2018 at 09:10:05AM +0800, Baolin Wang wrote: > On 26 September 2018 at 21:51, Sebastian Reichel wrote: > > Looks good to me. Technically this can result in existing users of > > power_supply_get_battery_info leaking memory, if they have an OCV > > table in DT. > > Fortunately existing users did not have an OCV table. Right. I was just talking about potential memory leak, if the DT file of these boards has the OCV table defined. I don't think that this will be a problem in real life. > Moreover once this patch merged, I will send patches to add > power_supply_put_battery_info() for existing users of battery > info. Thanks. -- Sebastian signature.asc Description: PGP signature
Re: possible deadlock in path_openat
On Thu, Sep 27, 2018 at 8:05 AM, Amir Goldstein wrote: > So this is interesting... if there is a file in overlayfs lower layer with > the f_op read = seq_read then &p->lock in the chain above could be > takes after ovl locks and that is in reveres order to the order of locks > in execve on an overlayfs file. > > On the one hand, it is possible (not sure if desirable) to use filesystems > with seq_file like debugfs as overlay lower fs, but on the other hand, > it is not possible to copy up a debugfs file with its original content > because (at least for most files I looked) the inode size is reported as 0. > > Also, from v4.19-rc1, with stacked f_op, ovl_read_iter() calls > vfs_iter_read(), > so overlayfs is no longer tolerant to underlying files that implement f_op > read > (and not read_iter), thus, it is no longer possible to read lower debugfs > files. > > That said, if there are files in lower layer that user seq_read f_op and have > non zero inode size, the deadlock reported above might be possible. > > Miklos, > > What do you recon we should do? > Blacklist debugfs just like procfs was blacklisted from fs stacking? > Improve the heuristics of ovl_dentry_weird() to cover debugfs and friends? I think that's the best plan. There doesn't seem to be any sense in supporting debugfs and similar weirdness as lower layer, so the best course of action would be to deny at the earilest possible point in time. Thanks, Miklos
[PATCH v2] NTB: switchtec_ntb: Update switchtec documentation with pre-requisites for NTB
Update switchtec documentation 1.add pre-requisites for NTB driver 2.misc updates change NTB hardware driver name to ntb_hw_switchtec update the description of 2 partitions limit add reference to Linux Documentation/ntb.txt add use of term 'Command ID' add use of term 'Command Return Value' add a missing ')' Signed-off-by: Kelvin Cao Signed-off-by: Wesley Yung Signed-off-by: Wesley Sheng --- Documentation/switchtec.txt | 30 ++ 1 file changed, 20 insertions(+), 10 deletions(-) diff --git a/Documentation/switchtec.txt b/Documentation/switchtec.txt index f788264..40e839d 100644 --- a/Documentation/switchtec.txt +++ b/Documentation/switchtec.txt @@ -23,7 +23,7 @@ The primary means of communicating with the Switchtec management firmware is through the Memory-mapped Remote Procedure Call (MRPC) interface. Commands are submitted to the interface with a 4-byte command identifier and up to 1KB of command specific data. The firmware will -respond with a 4 bytes return code and up to 1KB of command specific +respond with a 4-byte return code and up to 1KB of command specific data. The interface only processes a single command at a time. @@ -36,8 +36,8 @@ device: /dev/switchtec#, one for each management endpoint in the system. The char device has the following semantics: * A write must consist of at least 4 bytes and no more than 1028 bytes. - The first four bytes will be interpreted as the command to run and - the remainder will be used as the input data. A write will send the + The first 4 bytes will be interpreted as the Command ID and the + remainder will be used as the input data. A write will send the command to the firmware to begin processing. * Each write must be followed by exactly one read. Any double write will @@ -45,9 +45,9 @@ The char device has the following semantics: produce an error. * A read will block until the firmware completes the command and return - the four bytes of status plus up to 1024 bytes of output data. (The - length will be specified by the size parameter of the read call -- - reading less than 4 bytes will produce an error. + the 4-byte Command Return Value plus up to 1024 bytes of output + data. (The length will be specified by the size parameter of the read + call -- reading less than 4 bytes will produce an error.) * The poll call will also be supported for userspace applications that need to do other things while waiting for the command to complete. @@ -83,10 +83,20 @@ The following IOCTLs are also supported by the device: Non-Transparent Bridge (NTB) Driver === -An NTB driver is provided for the switchtec hardware in switchtec_ntb. -Currently, it only supports switches configured with exactly 2 -partitions. It also requires the following configuration settings: +An NTB hardware driver is provided for the Switchtec hardware in +ntb_hw_switchtec. Currently, it only supports switches configured with +exactly 2 NT partitions and zero or more non-NT partitions. It also +requires the following configuration settings: -* Both partitions must be able to access each other's GAS spaces. +* Both NT partitions must be able to access each other's GAS spaces. Thus, the bits in the GAS Access Vector under Management Settings must be set to support this. +* Kernel configuration MUST include support for NTB (CONFIG_NTB needs + to be set) + +NT EP BAR 2 will be dynamically configured as a Direct Window, and the +configuration file does not need to configure it explicitly. + +Please refer to Documentation/ntb.txt in Linux source tree for an +overall understanding of the Linux NTB stack. ntb_hw_switchtec works as +an NTB Hardware Driver in this stack.
Re: [PATCH v2 1/7] drivers: dio: Avoids building driver if CONFIG_DIO is disabled
Am Donnerstag, 27. September 2018, 03:39:56 CEST schrieb Leonardo Brás: > Avoids building driver if 'make drivers/dio/' is called and > CONFIG_DIO is disabled. > > Signed-off-by: Leonardo Brás > --- > drivers/dio/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/dio/Makefile b/drivers/dio/Makefile > index ae92d17083f2..f5cffe232448 100644 > --- a/drivers/dio/Makefile > +++ b/drivers/dio/Makefile > @@ -2,4 +2,4 @@ > # Makefile for the linux kernel. > # > > -obj-y := dio.o dio-driver.o dio-sysfs.o > +obj-$(CONFIG_DIO) := dio.o dio-driver.o dio-sysfs.o > \ No newline at end of file ^^ One more. signature.asc Description: This is a digitally signed message part.
Re: [PATCH v2 6/7] drivers: oprofile: Avoids building driver from direct make command
Am Donnerstag, 27. September 2018, 03:41:38 CEST schrieb Leonardo Brás: > Creates new Makefile to avoid building driver if > 'make drivers/oprofile/' is called directly. > > This driver is usually built from arch/$ARCH and seems to have > no meaning building alone. > > Signed-off-by: Leonardo Brás > --- > drivers/oprofile/Makefile | 2 ++ > 1 file changed, 2 insertions(+) > create mode 100644 drivers/oprofile/Makefile > > diff --git a/drivers/oprofile/Makefile b/drivers/oprofile/Makefile > new file mode 100644 > index ..acaed2ad6eee > --- /dev/null > +++ b/drivers/oprofile/Makefile > @@ -0,0 +1,2 @@ > +#Does nothing, since the source is called from arch/$ARCH/ tree. > + Now there is a blank line where it does not need to be. Eike signature.asc Description: This is a digitally signed message part.
Re: [PATCHv4 4/6] ARM: dts: exynos: Add CD and WP pins to Odroid XU3/XU4 SD card
On Thu, 27 Sep 2018 at 05:45, Anand Moon wrote: > > Hi Krzysztof, > On Thu, 27 Sep 2018 at 00:36, Krzysztof Kozlowski wrote: > > > > On Sat, Sep 22, 2018 at 07:52:36AM +, Anand Moon wrote: > > > Add the card-detect and write-protect GPIO pins for OdroidXU3/XU4 > > > SD card by adding pinctrl setting for wp-gpio pin and set it to > > > active low. > > > > > > This also removes debug messages: > > > dwmmc_exynos 1222.mmc: No GPIO consumer cd found > > > dwmmc_exynos 1222.mmc: No GPIO consumer wp found > > > > > > Suggested-by: Krzysztof Kozlowski > > > Signed-off-by: Anand Moon > > > --- > > > Fix the commit message and squash it with cd-gpios and wp-gpio > > > patches into single patch as suggested by Krzysztof. > > > > As Marek pointed to my Odroid XU patch, there is no point of adding > > cd-gpios and wp-gpios properties. > > > > Adding pin configuration for wp pin is also not needed. Reset values are > > working properly. However there might be meaning of adding it just in > > case - if bootloader decided to touch it... > > > > Best regards, > > Krzysztof > > > > Do I need to send the all the patches again or just resend this as per > your patch for Odroid XU. > with dropping the cd-gpios and wp-gpios changes. I am fine with both (resend all or only this). Best regards, Krzysztof
[PATCH v3 2/2] locking/pvqspinlock, hv: Enable PV qspinlock for Hyper-V
Follow PV spinlock mechanism to implement the callback functions
to allow the CPU idling and kicking operations on Hyper-V.
Cc: "K. Y. Srinivasan"
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Cc: Thomas Gleixner
Cc: Michael Kelley (EOSG)
Signed-off-by: Yi Sun
---
v2->v3:
- use "Hyper-V: " as the message prefix
(suggested by Michael Kelley)
- remove unnecessary header files
(suggested by Michael Kelley)
- remove unnecessary check in 'hv_qlock_wait'
(suggested by Michael Kelley)
- fix compilation error on different platforms
(suggested by Thomas Gleixner)
---
Documentation/admin-guide/kernel-parameters.txt | 5 ++
arch/x86/hyperv/Makefile| 4 ++
arch/x86/hyperv/hv_spinlock.c | 76 +
arch/x86/include/asm/mshyperv.h | 1 +
arch/x86/kernel/cpu/mshyperv.c | 14 +
5 files changed, 100 insertions(+)
create mode 100644 arch/x86/hyperv/hv_spinlock.c
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 92eb1f4..0fc8448 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1385,6 +1385,11 @@
hvc_iucv_allow= [S390] Comma-separated list of z/VM user IDs.
If specified, z/VM IUCV HVC accepts connections
from listed z/VM user IDs only.
+
+ hv_nopvspin [X86,HYPER_V]
+ Disables the ticketlock slowpath using HYPER-V PV
+ optimizations.
+
keep_bootcon[KNL]
Do not unregister boot console at start. This is only
useful for debugging when something happens in the
window
diff --git a/arch/x86/hyperv/Makefile b/arch/x86/hyperv/Makefile
index b21ee65..1c11f94 100644
--- a/arch/x86/hyperv/Makefile
+++ b/arch/x86/hyperv/Makefile
@@ -1,2 +1,6 @@
obj-y := hv_init.o mmu.o nested.o
obj-$(CONFIG_X86_64) += hv_apic.o
+
+ifdef CONFIG_X86_64
+obj-$(CONFIG_PARAVIRT_SPINLOCKS) += hv_spinlock.o
+endif
diff --git a/arch/x86/hyperv/hv_spinlock.c b/arch/x86/hyperv/hv_spinlock.c
new file mode 100644
index 000..e8fe997
--- /dev/null
+++ b/arch/x86/hyperv/hv_spinlock.c
@@ -0,0 +1,76 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * Hyper-V specific spinlock code.
+ *
+ * Copyright (C) 2018, Intel, Inc.
+ *
+ * Author : Yi Sun
+ */
+
+#define pr_fmt(fmt) "Hyper-V: " fmt
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+static bool __initdata hv_pvspin = true;
+
+static void hv_qlock_kick(int cpu)
+{
+ apic->send_IPI(cpu, X86_PLATFORM_IPI_VECTOR);
+}
+
+static void hv_qlock_wait(u8 *byte, u8 val)
+{
+ unsigned long msr_val;
+
+ if (READ_ONCE(*byte) != val)
+ return;
+
+ /*
+* Read HV_X64_MSR_GUEST_IDLE MSR can trigger the guest's
+* transition to the idle power state which can be exited
+* by an IPI even if IF flag is disabled.
+*/
+ rdmsrl(HV_X64_MSR_GUEST_IDLE, msr_val);
+}
+
+/*
+ * Hyper-V does not support this so far.
+ */
+bool hv_vcpu_is_preempted(int vcpu)
+{
+ return false;
+}
+PV_CALLEE_SAVE_REGS_THUNK(hv_vcpu_is_preempted);
+
+void __init hv_init_spinlocks(void)
+{
+ if (!hv_pvspin ||
+ !apic ||
+ !(ms_hyperv.hints & HV_X64_CLUSTER_IPI_RECOMMENDED) ||
+ !(ms_hyperv.features & HV_X64_MSR_GUEST_IDLE_AVAILABLE)) {
+ pr_info("PV spinlocks disabled\n");
+ return;
+ }
+ pr_info("PV spinlocks enabled\n");
+
+ __pv_init_lock_hash();
+ pv_lock_ops.queued_spin_lock_slowpath = __pv_queued_spin_lock_slowpath;
+ pv_lock_ops.queued_spin_unlock =
PV_CALLEE_SAVE(__pv_queued_spin_unlock);
+ pv_lock_ops.wait = hv_qlock_wait;
+ pv_lock_ops.kick = hv_qlock_kick;
+ pv_lock_ops.vcpu_is_preempted = PV_CALLEE_SAVE(hv_vcpu_is_preempted);
+}
+
+static __init int hv_parse_nopvspin(char *arg)
+{
+ hv_pvspin = false;
+ return 0;
+}
+early_param("hv_nopvspin", hv_parse_nopvspin);
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index f377044..759cfd2 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -351,6 +351,7 @@ static inline int cpumask_to_vpset(struct hv_vpset *vpset,
#ifdef CONFIG_X86_64
void hv_apic_init(void);
+void __init hv_init_spinlocks(void);
#else
static inline void hv_apic_init(void) {}
#endif
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index ad12733..a5cc219 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -199,6 +199,16 @@ static unsigned long hv_get_tsc_khz(void)
return freq / 1000;
}
+#if defined(CONFIG_SMP) && IS_ENABLED(CONFIG_HYPERV)
+static void __init hv_smp_prepare_boot_cpu(void)
+
[PATCH v3 1/2] X86/Hyper-V: Add Guest IDLE MSR support
Hyper-V may expose a HV_X64_MSR_GUEST_IDLE MSR. We can read HYPERV_CPUID_FEATURES eax to check it. Read this MSR can trigger the guest's transition to the idle power state which can be exited by an IPI even if IF flag is disabled. Cc: "K. Y. Srinivasan" Cc: Haiyang Zhang Cc: Stephen Hemminger Reviewed-by: Michael Kelley Signed-off-by: Yi Sun --- arch/x86/include/asm/hyperv-tlfs.h | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/x86/include/asm/hyperv-tlfs.h b/arch/x86/include/asm/hyperv-tlfs.h index 00e01d2..4139f76 100644 --- a/arch/x86/include/asm/hyperv-tlfs.h +++ b/arch/x86/include/asm/hyperv-tlfs.h @@ -38,6 +38,8 @@ #define HV_MSR_TIME_REF_COUNT_AVAILABLE(1 << 1) /* Partition reference TSC MSR is available */ #define HV_MSR_REFERENCE_TSC_AVAILABLE (1 << 9) +/* Partition Guest IDLE MSR is available */ +#define HV_X64_MSR_GUEST_IDLE_AVAILABLE(1 << 10) /* A partition's reference time stamp counter (TSC) page */ #define HV_X64_MSR_REFERENCE_TSC 0x4021 @@ -246,6 +248,9 @@ #define HV_X64_MSR_STIMER3_CONFIG 0x40B6 #define HV_X64_MSR_STIMER3_COUNT 0x40B7 +/* Hyper-V guest idle MSR */ +#define HV_X64_MSR_GUEST_IDLE 0x40F0 + /* Hyper-V guest crash notification MSR's */ #define HV_X64_MSR_CRASH_P00x4100 #define HV_X64_MSR_CRASH_P10x4101 -- 1.9.1
[PATCH v3 0/2] Enable PV qspinlock for Hyper-V
v2->v3: - use "Hyper-V: " as the message prefix - remove unnecessary header files - remove unnecessary check in 'hv_qlock_wait' - fix compilation error on different platforms v1->v2: - compile hv_spinlock.c only when CONFIG_PARAVIRT_SPINLOCKS enabled - merge v1 patch 2/3 to single patch - remove part of the boilerplate in hv_spinlock.c - declare hv_pvspin as __initdata - remove spin_wait_info and hv_notify_long_spin_wait because SpinWaitInfo is a standalone feature. - add comments for reading HV_X64_MSR_GUEST_IDLE - replace pr_warn to pr_info - use pr_fmt instead of the 'hv:' prefix - register callback function for smp_ops.smp_prepare_boot_cpu to initialize hyper-v spinlock This patch adds the necessary Hyper-V specific code to allow PV qspinlock work on Hyper-V. In wait callback function, read HV_X64_MSR_GUEST_IDLE MSR to trigger the guest's transition to the idle power state which can be exited by an IPI even if IF flag is disabled. In kick callback function, just send platform IPI to make waiting vcpu exit idle state. In vcpu_is_preempted callback function, return false directly because Hyper-V does not provide such interface so far. Cc: "K. Y. Srinivasan" Cc: Haiyang Zhang Cc: Stephen Hemminger Cc: Jonathan Corbet Cc: Thomas Gleixner Cc: Michael Kelley (EOSG) Yi Sun (2): X86/Hyper-V: Add Guest IDLE MSR support locking/pvqspinlock, hv: Enable PV qspinlock for Hyper-V Documentation/admin-guide/kernel-parameters.txt | 5 ++ arch/x86/hyperv/Makefile| 4 ++ arch/x86/hyperv/hv_spinlock.c | 76 + arch/x86/include/asm/hyperv-tlfs.h | 5 ++ arch/x86/include/asm/mshyperv.h | 1 + arch/x86/kernel/cpu/mshyperv.c | 14 + 6 files changed, 105 insertions(+) create mode 100644 arch/x86/hyperv/hv_spinlock.c -- 1.9.1
Re: possible deadlock in path_openat
On Wed, Sep 26, 2018 at 7:33 AM Miklos Szeredi wrote:
>
> [Cc linux-unionfs]
>
> On Wed, Sep 26, 2018 at 1:44 AM, syzbot
> wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:2dd68cc7fd8c Merge gitolite.kernel.org:/pub/scm/linux/kern..
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=111a60e640
> > kernel config: https://syzkaller.appspot.com/x/.config?x=22a62640793a83c9
> > dashboard link: https://syzkaller.appspot.com/bug?extid=a55ccfc8a853d3cff213
> > compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> >
> > Unfortunately, I don't have any reproducer for this crash yet.
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+a55ccfc8a853d3cff...@syzkaller.appspotmail.com
> >
> > ntfs: (device loop1): ntfs_fill_super(): Unable to determine device size.
> > team0 (unregistering): Port device team_slave_1 removed
> > kobject: 'team_slave_1' (1c55f79f): kobject_uevent_env
> >
> > ==
> > WARNING: possible circular locking dependency detected
> > kobject: 'team_slave_1' (1c55f79f): kobject_uevent_env:
> > uevent_suppress caused the event to drop!
> > 4.19.0-rc5+ #253 Not tainted
> > --
> > syz-executor1/545 is trying to acquire lock:
> > b04209e4 (&ovl_i_mutex_dir_key[depth]){}, at: inode_lock_shared
> > include/linux/fs.h:748 [inline]
> > b04209e4 (&ovl_i_mutex_dir_key[depth]){}, at: do_last
> > fs/namei.c:3323 [inline]
> > b04209e4 (&ovl_i_mutex_dir_key[depth]){}, at:
> > path_openat+0x250d/0x5160 fs/namei.c:3534
> > kobject: 'rx-0' (ca3546e9): kobject_cleanup, parent 4d034f96
> >
> > but task is already holding lock:
> > 44500cca (&sig->cred_guard_mutex){+.+.}, at:
> > prepare_bprm_creds+0x53/0x120 fs/exec.c:1404
> >
> > which lock already depends on the new lock.
> >
> >
> > the existing dependency chain (in reverse order) is:
> >
> > -> #3 (&sig->cred_guard_mutex){+.+.}:
> >__mutex_lock_common kernel/locking/mutex.c:925 [inline]
> >__mutex_lock+0x166/0x1700 kernel/locking/mutex.c:1072
> > kobject: 'rx-0' (ca3546e9): auto cleanup 'remove' event
> >mutex_lock_killable_nested+0x16/0x20 kernel/locking/mutex.c:1102
> >lock_trace+0x4c/0xe0 fs/proc/base.c:384
> >proc_pid_stack+0x196/0x3b0 fs/proc/base.c:420
> >proc_single_show+0x101/0x190 fs/proc/base.c:723
> >seq_read+0x4af/0x1150 fs/seq_file.c:229
> >do_loop_readv_writev fs/read_write.c:700 [inline]
> >do_iter_read+0x4a3/0x650 fs/read_write.c:924
> > kobject: 'rx-0' (ca3546e9): kobject_uevent_env
> >vfs_readv+0x175/0x1c0 fs/read_write.c:986
> >do_preadv+0x1cc/0x280 fs/read_write.c:1070
> >__do_sys_preadv fs/read_write.c:1120 [inline]
> >__se_sys_preadv fs/read_write.c:1115 [inline]
> >__x64_sys_preadv+0x9a/0xf0 fs/read_write.c:1115
> >do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> > kobject: 'rx-0' (ca3546e9): kobject_uevent_env: uevent_suppress
> > caused the event to drop!
> >entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >
> > -> #2 (&p->lock){+.+.}:
> >__mutex_lock_common kernel/locking/mutex.c:925 [inline]
> >__mutex_lock+0x166/0x1700 kernel/locking/mutex.c:1072
> >mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1087
> >seq_read+0x71/0x1150 fs/seq_file.c:161
> >do_loop_readv_writev fs/read_write.c:700 [inline]
> >do_iter_read+0x4a3/0x650 fs/read_write.c:924
> >vfs_readv+0x175/0x1c0 fs/read_write.c:986
> > kobject: 'rx-0' (ca3546e9): auto cleanup kobject_del
> >kernel_readv fs/splice.c:362 [inline]
> >default_file_splice_read+0x53c/0xb20 fs/splice.c:417
> >do_splice_to+0x12e/0x190 fs/splice.c:881
> >splice_direct_to_actor+0x270/0x8f0 fs/splice.c:953
> >do_splice_direct+0x2d4/0x420 fs/splice.c:1062
> >do_sendfile+0x62a/0xe20 fs/read_write.c:1440
> >__do_sys_sendfile64 fs/read_write.c:1495 [inline]
> >__se_sys_sendfile64 fs/read_write.c:1487 [inline]
> >__x64_sys_sendfile64+0x15d/0x250 fs/read_write.c:1487
> >do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> > kobject: 'rx-0' (ca3546e9): calling ktype release
> >entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >
> > -> #1 (sb_writers#5){.+.+}:
> >percpu_down_read_preempt_disable include/linux/percpu-rwsem.h:36
> > [inline]
> >percpu_down_read include/linux/percpu-rwsem.h:59 [inline]
> >__sb_start_write+0x214/0x370 fs/super.c:1387
> >sb_start_write include/linux/fs.h:1566 [inline]
> >mnt_want_write+0x3f/0xc0 fs/namespace.c:360
> >ovl_want_write+0x76/0xa0 fs/overlayfs/util.c:24
> > kobject: 'rx-0': free name
> >ovl_create_obj
[PATCH 1/12 v2] switchtec: Remove immediate status check after submit a MRPC command
After submit a Firmware Download (Download sub-command) MRPC command, Switchtec firmware refuses to response any management EP's BAR access until current flash programming finished. During this time, a READ TLP to the gas area in the BAR of the management EP will complete with significant delay like more than 10ms. It's a Switchtec firmware limitation that READ requests cannot get prompt service during firmware download. The delayed completion of READ TLP would be a problem on some system which is sensitive to READ timeout. Current driver check status immediately after submit a MRPC command, which triggers READ TLP to the gas area in the BAR of the management EP. Also, other processes or functions, like NTB, would also trigger READ TLP by accessing the GAS. To avoid this, the immediate check of status is removed in this patch, and driver delays the status check to the occurrence of MSIx or MRPC timeout. In the meantime, user must not initiate any gas access during a firmware download. Also, any process that issues MRPC command will be affected by the delay in this patch. However, this is only a software workaround to the READ issue in firmware download. A complete fix of this should happen in firmware. Note: For NTB function, the memory window access is handled by Switchtec hardware. So it's not affected by this firmware limitation. But the other GAS access which is handled by Switchtec firmware is are affected by this firmware limitation. Signed-off-by: Kelvin Cao Signed-off-by: Wesley Sheng --- drivers/pci/switch/switchtec.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c index 4591f15..b759228 100644 --- a/drivers/pci/switch/switchtec.c +++ b/drivers/pci/switch/switchtec.c @@ -142,10 +142,6 @@ static void mrpc_cmd_submit(struct switchtec_dev *stdev) stuser->data, stuser->data_len); iowrite32(stuser->cmd, &stdev->mmio_mrpc->cmd); - stuser->status = ioread32(&stdev->mmio_mrpc->status); - if (stuser->status != SWITCHTEC_MRPC_STATUS_INPROGRESS) - mrpc_complete_cmd(stdev); - schedule_delayed_work(&stdev->mrpc_timeout, msecs_to_jiffies(500)); } -- 2.7.4
(sin asunto)
-- Good Day, I, Mavis Wanczyk donates $ 5 Million Dollars to you, from part of my Powerball Jackpot Lottery of $ 758 Million Dollars, respond with your details for claims. I await your earliest response and God Bless you. Good luck, Mavis Wanczyk.
Re: [PATCH] Raise maximum number of memory controllers
On Tue, Sep 25, 2018 at 09:34:49AM -0500, Justin Ernst wrote: > We observe an oops in the skx_edac module during boot. > Examining /var/log/messages: > [ 3401.985757] EDAC MC0: Giving out device to module skx_edac controller > Skylake Socket#0 IMC#0 > [ 3401.985887] EDAC MC1: Giving out device to module skx_edac controller > Skylake Socket#0 IMC#1 > [ 3401.986014] EDAC MC2: Giving out device to module skx_edac controller > Skylake Socket#1 IMC#0 > ... > [ 3401.987318] EDAC MC13: Giving out device to module skx_edac controller > Skylake Socket#0 IMC#1 > [ 3401.987435] EDAC MC14: Giving out device to module skx_edac controller > Skylake Socket#1 IMC#0 > [ 3401.987556] EDAC MC15: Giving out device to module skx_edac controller > Skylake Socket#1 IMC#1 > [ 3401.987579] Too many memory controllers: 16 > [ 3402.042614] EDAC MC: Removed device 0 for skx_edac Skylake Socket#0 IMC#0 > > We observe there are two memory controllers per socket, with a limit of 16. > Raise the maximum number of memory controllers from 16 to 2 * MAX_NUMNODES > (1024). > > Cc: Borislav Petkov > Cc: Mauro Carvalho Chehab > Cc: linux-e...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Acked-by: Russ Anderson > Signed-off-by: Justin Ernst > --- > include/linux/edac.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Applied, thanks. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
[PATCH] use STORE_LOCKED instead of STORE macro
merge sysfs_writeback_running attr and sysfs_writeback_percent attr together
with other attrs of cached_dev.
Signed-off-by: Dongbo Cao
---
drivers/md/bcache/sysfs.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/md/bcache/sysfs.c b/drivers/md/bcache/sysfs.c
index 26f035a0..14fc9104 100644
--- a/drivers/md/bcache/sysfs.c
+++ b/drivers/md/bcache/sysfs.c
@@ -245,7 +245,7 @@ SHOW(__bch_cached_dev)
}
SHOW_LOCKED(bch_cached_dev)
-STORE(__cached_dev)
+STORE(__bch_cached_dev)
{
struct cached_dev *dc = container_of(kobj, struct cached_dev,
disk.kobj);
@@ -373,17 +373,6 @@ STORE(__cached_dev)
if (attr == &sysfs_stop)
bcache_device_stop(&dc->disk);
- return size;
-}
-
-STORE(bch_cached_dev)
-{
- struct cached_dev *dc = container_of(kobj, struct cached_dev,
-disk.kobj);
-
- mutex_lock(&bch_register_lock);
- size = __cached_dev_store(kobj, attr, buf, size);
-
if (attr == &sysfs_writeback_running)
bch_writeback_queue(dc);
@@ -392,9 +381,9 @@ STORE(bch_cached_dev)
schedule_delayed_work(&dc->writeback_rate_update,
dc->writeback_rate_update_seconds * HZ);
- mutex_unlock(&bch_register_lock);
return size;
}
+STORE_LOCKED(bch_cached_dev)
static struct attribute *bch_cached_dev_files[] = {
&sysfs_attach,
--
2.17.1
linux-next: Tree for Sep 27
Hi all, Changes since 20180926: Dropped trees: xarray, ida (temporarily) The pci tree lost its build failure. Non-merge commits (relative to Linus' tree): 6252 6435 files changed, 294737 insertions(+), 131625 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 288 trees (counting Linus' and 66 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (c307aaf3eb47 Merge tag 'iommu-fixes-v4.19-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu) Merging fixes/master (72358c0b59b7 linux-next: build warnings from the build of Linus' tree) Merging kbuild-current/fixes (ef8c4ed9db80 kbuild: allow to use GCC toolchain not in Clang search path) Merging arc-current/for-curr (40660f1fcee8 ARC: build: Don't set CROSS_COMPILE in arch's Makefile) Merging arm-current/fixes (afc9f65e01cd ARM: 8781/1: Fix Thumb-2 syscall return for binutils 2.29+) Merging arm64-fixes/for-next/fixes (031e6e6b4e12 arm64: hugetlb: Avoid unnecessary clearing in huge_ptep_set_access_flags) Merging m68k-current/for-linus (0986b16ab49b m68k/mac: Use correct PMU response format) Merging powerpc-fixes/fixes (2483ef056f6e powerpc/numa: Use associativity if VPHN hcall is successful) Merging sparc/master (df2def49c57b Merge tag 'acpi-4.19-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (3f32d0be6c16 tipc: lock wakeup & inputq at tipc_link_reset()) Merging bpf/master (3f32d0be6c16 tipc: lock wakeup & inputq at tipc_link_reset()) Merging ipsec/master (32bf94fb5c2e xfrm: validate template mode) Merging netfilter/master (346fa83d1093 netfilter: conntrack: get rid of double sizeof) Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging wireless-drivers/master (2823c8716c68 b43: fix DMA error related regression with proprietary firmware) Merging mac80211/master (28ef8b49a338 mac80211_hwsim: do not omit multicast announce of first added radio) Merging rdma-fixes/for-rc (5c5702e259dc RDMA/core: Set right entry state before releasing reference) Merging sound-current/for-linus (b3a5402cbceb ALSA: hda: Fix the audio-component completion timeout) Merging sound-asoc-fixes/for-linus (6c96a58bb15b Merge branch 'asoc-4.19' into asoc-linus) Merging regmap-fixes/for-linus (7876320f8880 Linux 4.19-rc4) Merging regulator-fixes/for-linus (3564951ca82b Merge branch 'regulator-4.19' into regulator-linus) Merging spi-fixes/for-linus (1f6b3b2c1ff4 Merge branch 'spi-4.19' into spi-linus) Merging pci-current/for-linus (f188b99f0b2d ACPI / hotplug / PCI: Don't scan for non-hotplug bridges if slot is not bridge) Merging driver-core.current/driver-core-linus (7876320f8880 Linux 4.19-rc4) Merging tty.current/tty-linus (7e620984b625 serial: imx: restore handshaking irq for imx1) Merging usb.current/usb-linus (3e3b81965cbf usb: typec: mux: Take care of driver module reference counting) Merging usb-gadget-fixes/fixes (d9707490077b usb: dwc2: Fix call location of dwc2_check_core_endianness) Merging usb-serial-fixes/usb-linus (f5fad711c06e USB: serial: simple: add Motorola Tetra MTP65
Re: [PATCH V5 06/30] csky: Cache and TLB routines
On Tue, Sep 25, 2018 at 09:24:07AM +0200, Peter Zijlstra wrote:
> On Mon, Sep 24, 2018 at 10:36:22PM +0800, Guo Ren wrote:
> > diff --git a/arch/csky/abiv1/inc/abi/cacheflush.h
> > b/arch/csky/abiv1/inc/abi/cacheflush.h
> > new file mode 100644
> > index 000..f0de49c
> > --- /dev/null
> > +++ b/arch/csky/abiv1/inc/abi/cacheflush.h
> > @@ -0,0 +1,43 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
> > +
> > +#ifndef __ABI_CSKY_CACHEFLUSH_H
> > +#define __ABI_CSKY_CACHEFLUSH_H
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +#define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 1
> > +extern void flush_dcache_page(struct page *);
> > +
> > +#define flush_cache_mm(mm) cache_wbinv_all()
> > +#define flush_cache_page(vma,page,pfn) cache_wbinv_all()
> > +#define flush_cache_dup_mm(mm) cache_wbinv_all()
> > +
> > +#define flush_cache_range(mm,start,end)cache_wbinv_range(start, end)
> ^^^ should be vma
Yes, I'll change it to:
#define flush_cache_range(mm,start,end) cache_wbinv_all()
I'll improve it later after test.
>
> > +#endif /* __ABI_CSKY_CACHEFLUSH_H */
>
>
> > diff --git a/arch/csky/abiv1/inc/abi/tlb.h b/arch/csky/abiv1/inc/abi/tlb.h
> > new file mode 100644
> > index 000..6d461f3
> > --- /dev/null
> > +++ b/arch/csky/abiv1/inc/abi/tlb.h
> > @@ -0,0 +1,12 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
> > +
> > +#ifndef __ABI_CSKY_TLB_H
> > +#define __ABI_CSKY_TLB_H
> > +
> > +#define tlb_start_vma(tlb, vma) \
> > + do { \
> > + if (!tlb->fullmm) \
> > + cache_wbinv_all(); \
> > + } while (0)
> > +#endif /* __ABI_CSKY_TLB_H */
>
> That should be:
>
> if (!tlb->fullmm)
> flush_cache_range(vma, vma->vm_start, vma->vm_end);
>
> Because as per the whole abiv1 vs abiv2, you don't need write back
> invalidation for v2 at all, also, you only need to invalidate the vma
> range, no reason to shoot everything down.
>
> Also, I'll be shortly removing this:
>
> https://lkml.kernel.org/r/20180913092812.071989...@infradead.org
Ok, I'll follow the rules.
>
> > diff --git a/arch/csky/abiv2/inc/abi/cacheflush.h
> > b/arch/csky/abiv2/inc/abi/cacheflush.h
> > new file mode 100644
> > index 000..756beb7
> > --- /dev/null
> > +++ b/arch/csky/abiv2/inc/abi/cacheflush.h
> > @@ -0,0 +1,40 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +#ifndef __ABI_CSKY_CACHEFLUSH_H
> > +#define __ABI_CSKY_CACHEFLUSH_H
> > +
> > +/* Keep includes the same across arches. */
> > +#include
> > +
> > +/*
> > + * The cache doesn't need to be flushed when TLB entries change when
> > + * the cache is mapped to physical memory, not virtual memory
> > + */
> > +#define flush_cache_all() do { } while (0)
> > +#define flush_cache_mm(mm) do { } while (0)
> > +#define flush_cache_dup_mm(mm) do { } while (0)
> > +#define flush_cache_range(vma, start, end) do { } while (0)
> ^^^ like here..
#define flush_cache_range(vma, start, end) \
do { \
if (vma->vm_flags & VM_EXEC) \
icache_inv_all(); \
}
Hmm ?
I'll improve it later after test.
Best Regards
Guo Ren
Re: [PATCH v3 1/2] dt-bindings: spi: Qualcomm Quad SPI(QSPI) documentation
Quoting Ryan Case (2018-09-26 13:52:03) > From: Girish Mahadevan > > Bindings for Qualcomm Quad SPI used on SoCs such as sdm845. > > Signed-off-by: Girish Mahadevan > Signed-off-by: Ryan Case > --- Reviewed-by: Stephen Boyd
RE: [PATCH v2] PM / devfreq: Stop the governor before device_unregister()
> From: Vincent Donnefort > > device_release() is freeing the resources before calling the device > specific release callback which is, in the case of devfreq, stopping > the governor. > > It is a problem as some governors are using the device resources. e.g. > simpleondemand which is using the devfreq deferrable monitoring work. If it > is not stopped before the resources are freed, it might lead to a use after > free. > > Signed-off-by: Vincent Donnefort > Reviewed-by: John Einar Reitan > Reviewed-by: Chanwoo Choi Acked-by: MyungJoo Ham Cheers, MyungJoo
Re: [PATCH v2 06/21] platform: goldfish: pipe: Add DMA support to goldfish pipe
On Wed, Sep 26, 2018 at 04:02:19PM -0700, r...@google.com wrote: > From: Roman Kiryanov > > Goldfish DMA is an extension to the pipe device and is designed > to facilitate high-speed RAM->RAM transfers from guest to host. > > See uapi/linux/goldfish/goldfish_dma.h for more details. > > Signed-off-by: Roman Kiryanov > Signed-off-by: Lingfeng Yang > --- > Changes in v2: > - Got sign-off from Lingfeng Yang. > - Removed the license boilerplate from goldfish_dma.h. > - Rebased. I don't understand this series. Please start over with 01/XX as your other patches were all merged. And I still think you need a better justification for this, given the many other ways the kernel already has for this feature... thanks, greg k-h
Re: [PATCH v2 4/4] power: supply: Add Spreadtrum SC27XX fuel gauge unit driver
On 26 September 2018 at 23:30, Sebastian Reichel wrote:
> Hi,
>
> On Wed, Sep 26, 2018 at 10:59:14AM +0800, Baolin Wang wrote:
>> This patch adds the Spreadtrum SC27XX serial PMICs fuel gauge support,
>> which is used to calculate the battery capacity.
>>
>> Original-by: Yuanjiang Yu
>> Signed-off-by: Baolin Wang
>> ---
>> Changes from v1:
>> - Use battery standard properties to get internal resistance and ocv table.
>> - Change devm_gpiod_get_optional() to devm_gpiod_get().
>> - Add power_supply_changed() when detecting battery present change.
>> - Return micro volts for sc27xx_fgu_get_vbat_ocv().
>> ---
>> drivers/power/supply/Kconfig |7 +
>> drivers/power/supply/Makefile|1 +
>> drivers/power/supply/sc27xx_fuel_gauge.c | 691
>> ++
>> 3 files changed, 699 insertions(+)
>> create mode 100644 drivers/power/supply/sc27xx_fuel_gauge.c
>>
>> diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
>> index f27cf07..917f4b7 100644
>> --- a/drivers/power/supply/Kconfig
>> +++ b/drivers/power/supply/Kconfig
>> @@ -652,4 +652,11 @@ config CHARGER_SC2731
>>Say Y here to enable support for battery charging with SC2731
>>PMIC chips.
>>
>> +config FUEL_GAUGE_SC27XX
>> + tristate "Spreadtrum SC27XX fuel gauge driver"
>> + depends on MFD_SC27XX_PMIC || COMPILE_TEST
>> + help
>> + Say Y here to enable support for fuel gauge with SC27XX
>> + PMIC chips.
>> +
>> endif # POWER_SUPPLY
>> diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile
>> index 767105b..b731c2a 100644
>> --- a/drivers/power/supply/Makefile
>> +++ b/drivers/power/supply/Makefile
>> @@ -86,3 +86,4 @@ obj-$(CONFIG_AXP288_FUEL_GAUGE) += axp288_fuel_gauge.o
>> obj-$(CONFIG_AXP288_CHARGER) += axp288_charger.o
>> obj-$(CONFIG_CHARGER_CROS_USBPD) += cros_usbpd-charger.o
>> obj-$(CONFIG_CHARGER_SC2731) += sc2731_charger.o
>> +obj-$(CONFIG_FUEL_GAUGE_SC27XX) += sc27xx_fuel_gauge.o
>> diff --git a/drivers/power/supply/sc27xx_fuel_gauge.c
>> b/drivers/power/supply/sc27xx_fuel_gauge.c
>> new file mode 100644
>> index 000..d3422cf
>> --- /dev/null
>> +++ b/drivers/power/supply/sc27xx_fuel_gauge.c
>> @@ -0,0 +1,691 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +// Copyright (C) 2018 Spreadtrum Communications Inc.
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +/* PMIC global control registers definition */
>> +#define SC27XX_MODULE_EN00xc08
>> +#define SC27XX_CLK_EN0 0xc18
>> +#define SC27XX_FGU_ENBIT(7)
>> +#define SC27XX_FGU_RTC_ENBIT(6)
>> +
>> +/* FGU registers definition */
>> +#define SC27XX_FGU_START 0x0
>> +#define SC27XX_FGU_CONFIG0x4
>> +#define SC27XX_FGU_ADC_CONFIG0x8
>> +#define SC27XX_FGU_STATUS0xc
>> +#define SC27XX_FGU_INT_EN0x10
>> +#define SC27XX_FGU_INT_CLR 0x14
>> +#define SC27XX_FGU_INT_STS 0x1c
>> +#define SC27XX_FGU_VOLTAGE 0x20
>> +#define SC27XX_FGU_OCV 0x24
>> +#define SC27XX_FGU_POCV 0x28
>> +#define SC27XX_FGU_CURRENT 0x2c
>> +#define SC27XX_FGU_CLBCNT_SETH 0x50
>> +#define SC27XX_FGU_CLBCNT_SETL 0x54
>> +#define SC27XX_FGU_CLBCNT_VALH 0x68
>> +#define SC27XX_FGU_CLBCNT_VALL 0x6c
>> +#define SC27XX_FGU_CLBCNT_QMAXL 0x74
>> +
>> +#define SC27XX_WRITE_SELCLB_EN BIT(0)
>> +#define SC27XX_FGU_CLBCNT_MASK GENMASK(15, 0)
>> +#define SC27XX_FGU_CLBCNT_SHIFT 16
>> +
>> +#define SC27XX_FGU_1000MV_ADC686
>> +#define SC27XX_FGU_1000MA_ADC1372
>> +#define SC27XX_FGU_CUR_BASIC_ADC 8192
>> +#define SC27XX_FGU_SAMPLE_HZ 2
>> +
>> +/*
>> + * struct sc27xx_fgu_data: describe the FGU device
>> + * @regmap: regmap for register access
>> + * @dev: platform device
>> + * @battery: battery power supply
>> + * @base: the base offset for the controller
>> + * @lock: protect the structure
>> + * @gpiod: GPIO for battery detection
>> + * @channel: IIO channel to get battery temperature
>> + * @internal_resist: the battery internal resistance in mOhm
>> + * @total_cap: the total capacity of the battery in mAh
>> + * @init_cap: the initial capacity of the battery in mAh
>> + * @init_clbcnt: the initial coulomb counter
>> + * @max_volt: the maximum constant input voltage in millivolt
>> + * @table_len: the capacity table length
>> + * @cap_table: capacity table with corresponding ocv
>> + */
>> +struct sc27xx_fgu_data {
>> + struct regmap *regmap;
>> + struct device *dev;
>> + struct power_supply *battery;
>> + u32 base;
>> + struct mutex lock;
>> + struct gpio_desc *gpiod;
>> + struct iio_channel *channel;
>> + bool ba
Re: [PATCH] staging: rtl8723bs: Mark ACPI table declaration as used
On Wed, Sep 26, 2018 at 04:20:55PM -0700, Nathan Chancellor wrote:
> Clang emits the following warning:
>
> drivers/staging/rtl8723bs/os_dep/sdio_intf.c:25:36: warning: variable
> 'acpi_ids' is not needed and will not be emitted
> [-Wunneeded-internal-declaration]
> static const struct acpi_device_id acpi_ids[] = {
>^
> 1 warning generated.
>
> Mark acpi_ids with the attribute __used, which makes it clear to Clang
> that we don't want this warning while not inhibiting Clang's dead code
> elimination from removing the unreferenced internal symbol when moving
> the data to the globally available symbol with MODULE_DEVICE_TABLE.
>
> $ nm -S drivers/staging/rtl8723bs/os_dep/sdio_intf.o | grep acpi
> 0040 R __mod_acpi__acpi_ids_device_table
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/169
> Suggested-by: Nick Desaulniers
> Signed-off-by: Nathan Chancellor
> ---
> drivers/staging/rtl8723bs/os_dep/sdio_intf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
> b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
> index 6d02904de63f..7c03b69b8ed3 100644
> --- a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
> +++ b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
> @@ -22,7 +22,7 @@ static const struct sdio_device_id sdio_ids[] =
> { SDIO_DEVICE(0x024c, 0xb723), },
> { /* end: all zeroes */ },
> };
> -static const struct acpi_device_id acpi_ids[] = {
> +static const struct acpi_device_id acpi_ids[] __used = {
Can't we put __used somewhere in the MODULE_DEVICE_TABLE() macro so we
don't have to go adding it to all individual entries?
thanks,
greg k-h
[PATCH v3] IB/rxe: Remove unnecessary enum values
Clang warns when an emumerated type is implicitly converted to another.
drivers/infiniband/sw/rxe/rxe.c:106:27: warning: implicit conversion
from enumeration type 'enum rxe_device_param' to different enumeration
type 'enum ib_atomic_cap' [-Wenum-conversion]
rxe->attr.atomic_cap= RXE_ATOMIC_CAP;
~ ^~
drivers/infiniband/sw/rxe/rxe.c:131:22: warning: implicit conversion
from enumeration type 'enum rxe_port_param' to different enumeration
type 'enum ib_port_state' [-Wenum-conversion]
port->attr.state= RXE_PORT_STATE;
~ ^~
drivers/infiniband/sw/rxe/rxe.c:132:24: warning: implicit conversion
from enumeration type 'enum rxe_port_param' to different enumeration
type 'enum ib_mtu' [-Wenum-conversion]
port->attr.max_mtu = RXE_PORT_MAX_MTU;
~ ^~~~
drivers/infiniband/sw/rxe/rxe.c:133:27: warning: implicit conversion
from enumeration type 'enum rxe_port_param' to different enumeration
type 'enum ib_mtu' [-Wenum-conversion]
port->attr.active_mtu = RXE_PORT_ACTIVE_MTU;
~ ^~~
drivers/infiniband/sw/rxe/rxe.c:151:24: warning: implicit conversion
from enumeration type 'enum rxe_port_param' to different enumeration
type 'enum ib_mtu' [-Wenum-conversion]
ib_mtu_enum_to_int(RXE_PORT_ACTIVE_MTU);
~~ ^~~
5 warnings generated.
Use the appropriate values from the expected enumerated type so no
conversion needs to happen then remove the unneeded definitions.
Reported-by: Nick Desaulniers
Signed-off-by: Nathan Chancellor
---
v1 -> v2:
* Don't cast, just use the expecting enumerated value directly, per
Jason's request
v2 -> v3:
* Convert two spots from RXE_PORT_MAX_MTU to IB_MTU_4096 then remove
value definitions.
drivers/infiniband/sw/rxe/rxe.c | 13 ++---
drivers/infiniband/sw/rxe/rxe_loc.h | 2 +-
drivers/infiniband/sw/rxe/rxe_param.h | 4
3 files changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/infiniband/sw/rxe/rxe.c b/drivers/infiniband/sw/rxe/rxe.c
index 10999fa69281..383e65c7bbc0 100644
--- a/drivers/infiniband/sw/rxe/rxe.c
+++ b/drivers/infiniband/sw/rxe/rxe.c
@@ -103,7 +103,7 @@ static void rxe_init_device_param(struct rxe_dev *rxe)
rxe->attr.max_res_rd_atom = RXE_MAX_RES_RD_ATOM;
rxe->attr.max_qp_init_rd_atom = RXE_MAX_QP_INIT_RD_ATOM;
rxe->attr.max_ee_init_rd_atom = RXE_MAX_EE_INIT_RD_ATOM;
- rxe->attr.atomic_cap= RXE_ATOMIC_CAP;
+ rxe->attr.atomic_cap= IB_ATOMIC_HCA;
rxe->attr.max_ee= RXE_MAX_EE;
rxe->attr.max_rdd = RXE_MAX_RDD;
rxe->attr.max_mw= RXE_MAX_MW;
@@ -128,9 +128,9 @@ static void rxe_init_device_param(struct rxe_dev *rxe)
/* initialize port attributes */
static int rxe_init_port_param(struct rxe_port *port)
{
- port->attr.state= RXE_PORT_STATE;
- port->attr.max_mtu = RXE_PORT_MAX_MTU;
- port->attr.active_mtu = RXE_PORT_ACTIVE_MTU;
+ port->attr.state= IB_PORT_DOWN;
+ port->attr.max_mtu = IB_MTU_4096;
+ port->attr.active_mtu = IB_MTU_256;
port->attr.gid_tbl_len = RXE_PORT_GID_TBL_LEN;
port->attr.port_cap_flags = RXE_PORT_PORT_CAP_FLAGS;
port->attr.max_msg_sz = RXE_PORT_MAX_MSG_SZ;
@@ -147,8 +147,7 @@ static int rxe_init_port_param(struct rxe_port *port)
port->attr.active_width = RXE_PORT_ACTIVE_WIDTH;
port->attr.active_speed = RXE_PORT_ACTIVE_SPEED;
port->attr.phys_state = RXE_PORT_PHYS_STATE;
- port->mtu_cap =
- ib_mtu_enum_to_int(RXE_PORT_ACTIVE_MTU);
+ port->mtu_cap = ib_mtu_enum_to_int(IB_MTU_256);
port->subnet_prefix = cpu_to_be64(RXE_PORT_SUBNET_PREFIX);
return 0;
@@ -300,7 +299,7 @@ void rxe_set_mtu(struct rxe_dev *rxe, unsigned int ndev_mtu)
mtu = eth_mtu_int_to_enum(ndev_mtu);
/* Make sure that new MTU in range */
- mtu = mtu ? min_t(enum ib_mtu, mtu, RXE_PORT_MAX_MTU) : IB_MTU_256;
+ mtu = mtu ? min_t(enum ib_mtu, mtu, IB_MTU_4096) : IB_MTU_256;
port->attr.active_mtu = mtu;
port->mtu_cap = ib_mtu_enum_to_int(mtu);
diff --git a/drivers/infiniband/sw/rxe/rxe_loc.h
b/drivers/infiniband/sw/rxe/rxe_loc.h
index 8e305422adbb..afd53f57a62b 100644
--- a/drivers/infiniband/sw/rxe/rxe_loc.h
+++ b/drivers/infiniband/sw/rxe/rxe_loc.h
@@ -195,7 +195,7 @@ static inline int qp_mtu(struct rxe_qp *qp)
[PATCH linux-next 10/10] ASoC: rsnd: Add kctrl to configure dai's busif
From: Jiada Wang
ssi0, ssi1, ssi2, ssi3, ssi4 and ssi9 have busif0 to busif7,
currently only busif0 is used by all ssi.
But tdm split and tdm ex-split mode, which require busif1 to
busif7.
This patch adds kctrl in ssi for dai-link, to make it possible
to configure the busif used by each dai-link.
Also adds rsnd_dma_addr_update() interface to make it possible
to update dma data address when there is change in condition
of dai connection.
Signed-off-by: Jiada Wang
---
sound/soc/sh/rcar/dma.c | 32
sound/soc/sh/rcar/rsnd.h | 2 ++
sound/soc/sh/rcar/ssi.c | 31 ++-
3 files changed, 64 insertions(+), 1 deletion(-)
diff --git a/sound/soc/sh/rcar/dma.c b/sound/soc/sh/rcar/dma.c
index 6d1947515dc8..8c284fd73fc1 100644
--- a/sound/soc/sh/rcar/dma.c
+++ b/sound/soc/sh/rcar/dma.c
@@ -792,6 +792,38 @@ int rsnd_dma_attach(struct rsnd_dai_stream *io, struct
rsnd_mod *mod,
return rsnd_dai_connect(*dma_mod, io, (*dma_mod)->type);
}
+void rsnd_dma_addr_update(struct rsnd_dai_stream *io,
+ struct rsnd_mod *mod,
+ struct rsnd_mod *dma_mod)
+{
+ struct rsnd_mod *mod_from = NULL;
+ struct rsnd_mod *mod_to = NULL;
+ struct rsnd_priv *priv = rsnd_io_to_priv(io);
+ struct rsnd_dma_ctrl *dmac = rsnd_priv_to_dmac(priv);
+ struct device *dev = rsnd_priv_to_dev(priv);
+ int is_play = rsnd_io_is_play(io);
+ struct rsnd_dma *dma = rsnd_mod_to_dma(dma_mod);
+
+ if (!dmac)
+ return;
+
+ rsnd_dma_of_path(mod, io, is_play, &mod_from, &mod_to);
+
+ dma->src_addr = rsnd_dma_addr(io, mod_from, is_play, 1);
+ dma->dst_addr = rsnd_dma_addr(io, mod_to, is_play, 0);
+
+ if (mod_from && mod_to) {
+ struct rsnd_dmapp *dmapp = rsnd_dma_to_dmapp(dma);
+
+ dmapp->chcr = rsnd_dmapp_get_chcr(io, mod_from, mod_to) |
+ PDMACHCR_DE;
+ }
+
+ dev_dbg(dev, "%s[%d] %pad -> %pad\n",
+ rsnd_mod_name(mod), rsnd_mod_id(mod),
+ &dma->src_addr, &dma->dst_addr);
+}
+
int rsnd_dma_probe(struct rsnd_priv *priv)
{
struct platform_device *pdev = rsnd_priv_to_pdev(priv);
diff --git a/sound/soc/sh/rcar/rsnd.h b/sound/soc/sh/rcar/rsnd.h
index 59b6d89d8edc..6c16d8403f7a 100644
--- a/sound/soc/sh/rcar/rsnd.h
+++ b/sound/soc/sh/rcar/rsnd.h
@@ -233,6 +233,8 @@ u32 rsnd_get_busif_shift(struct rsnd_dai_stream *io, struct
rsnd_mod *mod);
*/
int rsnd_dma_attach(struct rsnd_dai_stream *io,
struct rsnd_mod *mod, struct rsnd_mod **dma_mod);
+void rsnd_dma_addr_update(struct rsnd_dai_stream *io,
+ struct rsnd_mod *mod, struct rsnd_mod *dma_mod);
int rsnd_dma_probe(struct rsnd_priv *priv);
struct dma_chan *rsnd_dma_request_channel(struct device_node *of_node,
struct rsnd_mod *mod, char *name);
diff --git a/sound/soc/sh/rcar/ssi.c b/sound/soc/sh/rcar/ssi.c
index 4ac4b5b75ae2..b469db238697 100644
--- a/sound/soc/sh/rcar/ssi.c
+++ b/sound/soc/sh/rcar/ssi.c
@@ -160,6 +160,15 @@ int rsnd_ssi_get_busif(struct rsnd_dai_stream *io)
return io->busif->val;
}
+static void rsnd_ssi_set_busif(struct rsnd_dai_stream *io,
+ struct rsnd_mod *mod)
+{
+ if (!rsnd_ssi_use_busif(io))
+ return;
+
+ rsnd_dma_addr_update(io, mod, io->dma);
+}
+
static void rsnd_ssi_status_clear(struct rsnd_mod *mod)
{
rsnd_mod_write(mod, SSISR, 0);
@@ -718,6 +727,10 @@ static int rsnd_ssi_pcm_new(struct rsnd_mod *mod,
struct rsnd_dai_stream *io,
struct snd_soc_pcm_runtime *rtd)
{
+ int is_play = rsnd_io_is_play(io);
+ int id = rsnd_mod_id(mod);
+ int ret = 0;
+
/*
* rsnd_rdai_is_clk_master() will be enabled after set_fmt,
* and, pcm_new will be called after it.
@@ -725,7 +738,23 @@ static int rsnd_ssi_pcm_new(struct rsnd_mod *mod,
*/
rsnd_ssi_parent_attach(mod, io);
- return 0;
+ if (!rsnd_ssi_use_busif(io))
+ return 0;
+
+ if (rsnd_ssi_is_multi_slave(mod, io))
+ return 0;
+
+ /* SSI5 to SSI8 only have one BUSIF */
+ if (id <= 4 || id == 9)
+ ret = rsnd_kctrl_new_s(mod, io, rtd,
+ is_play ?
+ "SSI Out BUSIF" :
+ "SSI In BUSIF",
+ rsnd_kctrl_accept_anytime,
+ rsnd_ssi_set_busif,
+ io->busif, 7);
+
+ return ret;
}
static int rsnd_ssi_common_probe(struct rsnd_mod *mod,
--
2.17.0
[PATCH linux-next 09/10] ASoC: rsnd: add busif property to dai stream
From: Jiada Wang
SSI may use different busif for data transfer, this patch
adds busif property to each dai stream, to indicate the
busif used by playback/capture stream.
Signed-off-by: Jiada Wang
---
sound/soc/sh/rcar/core.c | 16 +++-
sound/soc/sh/rcar/rsnd.h | 3 +++
sound/soc/sh/rcar/ssi.c | 5 -
3 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/sound/soc/sh/rcar/core.c b/sound/soc/sh/rcar/core.c
index 40d7dc4f7839..aee3132c72b9 100644
--- a/sound/soc/sh/rcar/core.c
+++ b/sound/soc/sh/rcar/core.c
@@ -560,6 +560,14 @@ struct rsnd_dai *rsnd_rdai_get(struct rsnd_priv *priv, int
id)
return priv->rdai + id;
}
+struct rsnd_kctrl_cfg_s *rsnd_busif_get(struct rsnd_priv *priv, int id)
+{
+ if ((id < 0) || (id >= 2 * rsnd_rdai_nr(priv)))
+ return NULL;
+
+ return priv->busif + id;
+}
+
static struct snd_soc_dai_driver
*rsnd_daidrv_get(struct rsnd_priv *priv, int id)
{
@@ -1045,6 +1053,9 @@ static void __rsnd_dai_probe(struct rsnd_priv *priv,
io_playback = &rdai->playback;
io_capture = &rdai->capture;
+ io_playback->busif = rsnd_busif_get(priv, dai_i);
+ io_capture->busif = rsnd_busif_get(priv, rsnd_rdai_nr(priv) + dai_i);
+
snprintf(rdai->name, RSND_DAI_NAME_SIZE, "rsnd-dai.%d", dai_i);
rdai->priv = priv;
@@ -1108,6 +1119,7 @@ static int rsnd_dai_probe(struct rsnd_priv *priv)
struct snd_soc_dai_driver *rdrv;
struct device *dev = rsnd_priv_to_dev(priv);
struct rsnd_dai *rdai;
+ struct rsnd_kctrl_cfg_s *busif;
int nr;
int is_graph;
int dai_i;
@@ -1123,12 +1135,14 @@ static int rsnd_dai_probe(struct rsnd_priv *priv)
rdrv = devm_kcalloc(dev, nr, sizeof(*rdrv), GFP_KERNEL);
rdai = devm_kcalloc(dev, nr, sizeof(*rdai), GFP_KERNEL);
- if (!rdrv || !rdai)
+ busif = devm_kcalloc(dev, 2 * nr, sizeof(*busif), GFP_KERNEL);
+ if (!rdrv || !rdai || !busif)
return -ENOMEM;
priv->rdai_nr = nr;
priv->daidrv= rdrv;
priv->rdai = rdai;
+ priv->busif = busif;
/*
* parse all dai
diff --git a/sound/soc/sh/rcar/rsnd.h b/sound/soc/sh/rcar/rsnd.h
index 4464d1d0a042..59b6d89d8edc 100644
--- a/sound/soc/sh/rcar/rsnd.h
+++ b/sound/soc/sh/rcar/rsnd.h
@@ -456,6 +456,7 @@ struct rsnd_dai_stream {
struct rsnd_mod *dma;
struct rsnd_dai *rdai;
struct device *dmac_dev; /* for IPMMU */
+ struct rsnd_kctrl_cfg_s *busif;
u32 parent_ssi_status;
};
#define rsnd_io_to_mod(io, i) ((i) < RSND_MOD_MAX ? (io)->mod[(i)] : NULL)
@@ -629,6 +630,8 @@ struct rsnd_priv {
*/
struct snd_soc_dai_driver *daidrv;
struct rsnd_dai *rdai;
+ struct rsnd_kctrl_cfg_s *busif;
+
int rdai_nr;
};
diff --git a/sound/soc/sh/rcar/ssi.c b/sound/soc/sh/rcar/ssi.c
index 75a3d15084c2..4ac4b5b75ae2 100644
--- a/sound/soc/sh/rcar/ssi.c
+++ b/sound/soc/sh/rcar/ssi.c
@@ -154,7 +154,10 @@ int rsnd_ssi_use_busif(struct rsnd_dai_stream *io)
int rsnd_ssi_get_busif(struct rsnd_dai_stream *io)
{
- return 0; /* BUSIF0 only for now */
+ if (!rsnd_ssi_use_busif(io))
+ return 0;
+
+ return io->busif->val;
}
static void rsnd_ssi_status_clear(struct rsnd_mod *mod)
--
2.17.0
[PATCH linux-next 08/10] arm64: r8a77965: change to use extended audio dmac register
From: Jiada Wang
Basic audio dmac register only supports busif from 0 to 3,
in order to use busif4 ~ busif7, extended audio dmac register
need to be used.
Signed-off-by: Jiada Wang
---
arch/arm64/boot/dts/renesas/r8a77965.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index fd00010a5ed7..6c0d5053a81c 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -1405,7 +1405,7 @@
<0 0xec5a 0 0x100>, /* ADG */
<0 0xec54 0 0x1000>, /* SSIU */
<0 0xec541000 0 0x280>, /* SSI */
- <0 0xec74 0 0x200>; /* Audio DMAC peri
peri*/
+ <0 0xec76 0 0x200>; /* Audio DMAC peri
peri*/
/* placeholder */
rcar_sound,dvc {
--
2.17.0
[PATCH linux-next 07/10] arm64: r8a774a1: change to use extended audio dmac register
From: Jiada Wang Basic audio dmac register only supports busif from 0 to 3, in order to use busif4 ~ busif7, extended audio dmac register need to be used. Signed-off-by: Jiada Wang --- arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi index c9aad3e3b1b0..c3e0f2151176 100644 --- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi +++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi @@ -1120,7 +1120,7 @@ <0 0xec5a 0 0x100>, /* ADG */ <0 0xec54 0 0x1000>, /* SSIU */ <0 0xec541000 0 0x280>, /* SSI */ - <0 0xec74 0 0x200>; /* Audio DMAC peri peri*/ + <0 0xec76 0 0x200>; /* Audio DMAC peri peri*/ reg-names = "scu", "adg", "ssiu", "ssi", "audmapp"; clocks = <&cpg CPG_MOD 1005>, -- 2.17.0
[PATCH linux-next 05/10] arm64: r8a7795: change to use extended audio dmac register
From: Jiada Wang Basic audio dmac register only supports busif from 0 to 3, in order to use busif4 ~ busif7, extended audio dmac register need to be used. Signed-off-by: Jiada Wang --- arch/arm64/boot/dts/renesas/r8a7795.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi index 0a66bda7124f..32d191102a81 100644 --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi @@ -1796,7 +1796,7 @@ <0 0xec5a 0 0x100>, /* ADG */ <0 0xec54 0 0x1000>, /* SSIU */ <0 0xec541000 0 0x280>, /* SSI */ - <0 0xec74 0 0x200>; /* Audio DMAC peri peri*/ + <0 0xec76 0 0x200>; /* Audio DMAC peri peri*/ reg-names = "scu", "adg", "ssiu", "ssi", "audmapp"; clocks = <&cpg CPG_MOD 1005>, -- 2.17.0
[RESEND PATCH] ARM: prevent tracing IPI_CPU_BACKTRACE
From: Arnd Bergmann
When function tracing for IPIs is enabled, we get a warning for an
overflow of the ipi_types array with the IPI_CPU_BACKTRACE type
as triggered by raise_nmi():
arch/arm/kernel/smp.c: In function 'raise_nmi':
arch/arm/kernel/smp.c:489:2: error: array subscript is above array bounds
[-Werror=array-bounds]
trace_ipi_raise(target, ipi_types[ipinr]);
This is a correct warning as we actually overflow the array here.
This patch raise_nmi() to call __smp_cross_call() instead of
smp_cross_call(), to avoid calling into ftrace. For clarification,
I'm also adding a two new code comments describing how this one
is special.
The warning appears to have shown up after patch e7273ff49acf
("ARM: 8488/1: Make IPI_CPU_BACKTRACE a "non-secure" SGI"), which
changed the number assignment from '15' to '8', but as far as I can
tell has existed since the IPI tracepoints were first introduced.
If we decide to backport this patch to stable kernels, we probably
need to backport e7273ff49acf as well.
Resubmiting this patch is because that I found coverity is complaining
the issue this patch fixed, and also I got the traces like below:
"ipi_raise: target_mask=0001 (machine_suspend)" which actually was
the TPS of suspend_resume[1] rather than ipi_raise.
[1]
https://elixir.bootlin.com/linux/latest/source/kernel/power/suspend.c#L80
Signed-off-by: Arnd Bergmann
Fixes: e7273ff49acf ("ARM: 8488/1: Make IPI_CPU_BACKTRACE a "non-secure" SGI")
Fixes: 365ec7b17327 ("ARM: add IPI tracepoints") # v3.17
Signed-off-by: Chunyan Zhang
---
arch/arm/include/asm/hardirq.h | 1 +
arch/arm/kernel/smp.c | 6 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/hardirq.h b/arch/arm/include/asm/hardirq.h
index cba23ea..7a88f16 100644
--- a/arch/arm/include/asm/hardirq.h
+++ b/arch/arm/include/asm/hardirq.h
@@ -6,6 +6,7 @@
#include
#include
+/* number of IPIS _not_ including IPI_CPU_BACKTRACE */
#define NR_IPI 7
typedef struct {
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 0978282..123be77 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -75,6 +75,10 @@ enum ipi_msg_type {
IPI_CPU_STOP,
IPI_IRQ_WORK,
IPI_COMPLETION,
+ /*
+* CPU_BACKTRACE is special and not included in NR_IPI
+* or tracable with trace_ipi_*
+*/
IPI_CPU_BACKTRACE,
/*
* SGI8-15 can be reserved by secure firmware, and thus may
@@ -755,7 +759,7 @@ core_initcall(register_cpufreq_notifier);
static void raise_nmi(cpumask_t *mask)
{
- smp_cross_call(mask, IPI_CPU_BACKTRACE);
+ _smp_cross_call(mask, IPI_CPU_BACKTRACE);
}
void arch_trigger_cpumask_backtrace(const cpumask_t *mask, bool exclude_self)
--
2.7.4
[PATCH linux-next 06/10] arm64: r8a7796: change to use extended audio dmac register
From: Jiada Wang Basic audio dmac register only supports busif from 0 to 3, in order to use busif4 ~ busif7, extended audio dmac register need to be used. Signed-off-by: Jiada Wang --- arch/arm64/boot/dts/renesas/r8a7796.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi index e9b05d997c4e..827a704154cd 100644 --- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi +++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi @@ -1670,7 +1670,7 @@ <0 0xec5a 0 0x100>, /* ADG */ <0 0xec54 0 0x1000>, /* SSIU */ <0 0xec541000 0 0x280>, /* SSI */ - <0 0xec74 0 0x200>; /* Audio DMAC peri peri*/ + <0 0xec76 0 0x200>; /* Audio DMAC peri peri*/ reg-names = "scu", "adg", "ssiu", "ssi", "audmapp"; clocks = <&cpg CPG_MOD 1005>, -- 2.17.0
Re: [PATCH V5 17/30] csky: Misc headers
On Tue, Sep 25, 2018 at 12:45:41PM +0200, Peter Zijlstra wrote:
> On Tue, Sep 25, 2018 at 12:08:03PM +0200, Andrea Parri wrote:
> > Hi Guo,
> >
> > > +/*
> > > + * set_bit - Atomically set a bit in memory
> > > + * @nr: the bit to set
> > > + * @addr: the address to start counting from
> > > + *
> > > + * This function is atomic and may not be reordered. See __set_bit()
> > > + * if you do not require the atomic guarantees.
> > > + *
> > > + * Note: there are no guarantees that this function will not be reordered
> > > + * on non x86 architectures, so if you are writing portable code,
> > > + * make sure not to rely on its reordering guarantees.
> > > + *
> > > + * Note that @nr may be almost arbitrarily large; this function is not
> > > + * restricted to acting on a single-word quantity.
> > > + */
> > > +static inline void set_bit(int nr, volatile unsigned long *addr)
> > > +{
> > > + unsigned long mask = BIT_MASK(nr);
> > > + unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
> > > + unsigned long tmp;
> > > +
> > > + /* *p |= mask; */
> > > + smp_mb();
> > > + asm volatile (
> > > + "1: ldex.w %0, (%2)\n"
> > > + " or32%0, %0, %1 \n"
> > > + " stex.w %0, (%2)\n"
> > > + " bez %0, 1b \n"
> > > + : "=&r"(tmp)
> > > + : "r"(mask), "r"(p)
> > > + : "memory");
> > > + smp_mb();
> > > +}
> > > +
> > > +/**
> > > + * clear_bit - Clears a bit in memory
> > > + * @nr: Bit to clear
> > > + * @addr: Address to start counting from
> > > + *
> > > + * clear_bit() is atomic and may not be reordered. However, it does
> > > + * not contain a memory barrier, so if it is used for locking purposes,
> > > + * you should call smp_mb__before_atomic() and/or smp_mb__after_atomic()
> > > + * in order to ensure changes are visible on other processors.
> > > + */
> > > +static inline void clear_bit(int nr, volatile unsigned long *addr)
> > > +{
> > > + unsigned long mask = BIT_MASK(nr);
> > > + unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
> > > + unsigned long tmp;
> > > +
> > > + /* *p &= ~mask; */
> > > + mask = ~mask;
> > > + smp_mb();
> > > + asm volatile (
> > > + "1: ldex.w %0, (%2)\n"
> > > + " and32 %0, %0, %1 \n"
> > > + " stex.w %0, (%2)\n"
> > > + " bez %0, 1b \n"
> > > + : "=&r"(tmp)
> > > + : "r"(mask), "r"(p)
> > > + : "memory");
> > > + smp_mb();
> > > +}
> > > +
> > > +/**
> > > + * change_bit - Toggle a bit in memory
> > > + * @nr: Bit to change
> > > + * @addr: Address to start counting from
> > > + *
> > > + * change_bit() is atomic and may not be reordered. It may be
> > > + * reordered on other architectures than x86.
> > > + * Note that @nr may be almost arbitrarily large; this function is not
> > > + * restricted to acting on a single-word quantity.
> > > + */
> > > +static inline void change_bit(int nr, volatile unsigned long *addr)
> > > +{
> > > + unsigned long mask = BIT_MASK(nr);
> > > + unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
> > > + unsigned long tmp;
> > > +
> > > + /* *p ^= mask; */
> > > + smp_mb();
> > > + asm volatile (
> > > + "1: ldex.w %0, (%2)\n"
> > > + " xor32 %0, %0, %1 \n"
> > > + " stex.w %0, (%2)\n"
> > > + " bez %0, 1b \n"
> > > + : "=&r"(tmp)
> > > + : "r"(mask), "r"(p)
> > > + : "memory");
> > > + smp_mb();
> > > +}
> >
> > The {set,clear,change}_bit() operations don't have to be ordered: you
> > might want to remove the above smp_mb()s (and adjust the comments).
I confused it with cmpxchg, seems cmpxchg need smp_mb() before&after.
See: https://lkml.org/lkml/2018/7/6/383
> Better yet, you can entirely delete all that and use
> asm-generic/bitops/atomic.h instead.
Yes, approve. Seems I only need care about asm/atomic.h, it's good for
me.
Best Regards
Guo Ren
Re: [PATCH v2] IB/rxe: Avoid implicit enum conversions in rxe_init functions
On Wed, Sep 26, 2018 at 10:01:57PM -0700, Nathan Chancellor wrote:
> Clang warns when an emumerated type is implicitly converted to another.
>
> drivers/infiniband/sw/rxe/rxe.c:106:27: warning: implicit conversion
> from enumeration type 'enum rxe_device_param' to different enumeration
> type 'enum ib_atomic_cap' [-Wenum-conversion]
> rxe->attr.atomic_cap= RXE_ATOMIC_CAP;
> ~ ^~
> drivers/infiniband/sw/rxe/rxe.c:131:22: warning: implicit conversion
> from enumeration type 'enum rxe_port_param' to different enumeration
> type 'enum ib_port_state' [-Wenum-conversion]
> port->attr.state= RXE_PORT_STATE;
> ~ ^~
> drivers/infiniband/sw/rxe/rxe.c:132:24: warning: implicit conversion
> from enumeration type 'enum rxe_port_param' to different enumeration
> type 'enum ib_mtu' [-Wenum-conversion]
> port->attr.max_mtu = RXE_PORT_MAX_MTU;
> ~ ^~~~
> drivers/infiniband/sw/rxe/rxe.c:133:27: warning: implicit conversion
> from enumeration type 'enum rxe_port_param' to different enumeration
> type 'enum ib_mtu' [-Wenum-conversion]
> port->attr.active_mtu = RXE_PORT_ACTIVE_MTU;
> ~ ^~~
> drivers/infiniband/sw/rxe/rxe.c:151:24: warning: implicit conversion
> from enumeration type 'enum rxe_port_param' to different enumeration
> type 'enum ib_mtu' [-Wenum-conversion]
> ib_mtu_enum_to_int(RXE_PORT_ACTIVE_MTU);
> ~~ ^~~
> 5 warnings generated.
>
> Use the appropriate values from the expected enumerated type so no
> conversion needs to happen.
>
> Reported-by: Nick Desaulniers
> Signed-off-by: Nathan Chancellor
>
> v1 -> v2:
>
> * Don't cast, just use the expecting enumerated value directly, per
> Jason's request
>
> drivers/infiniband/sw/rxe/rxe.c | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/infiniband/sw/rxe/rxe.c b/drivers/infiniband/sw/rxe/rxe.c
> index 10999fa69281..2f4e57886b89 100644
> +++ b/drivers/infiniband/sw/rxe/rxe.c
> @@ -103,7 +103,7 @@ static void rxe_init_device_param(struct rxe_dev *rxe)
> rxe->attr.max_res_rd_atom = RXE_MAX_RES_RD_ATOM;
> rxe->attr.max_qp_init_rd_atom = RXE_MAX_QP_INIT_RD_ATOM;
> rxe->attr.max_ee_init_rd_atom = RXE_MAX_EE_INIT_RD_ATOM;
> - rxe->attr.atomic_cap= RXE_ATOMIC_CAP;
> + rxe->attr.atomic_cap= IB_ATOMIC_HCA;
> rxe->attr.max_ee= RXE_MAX_EE;
> rxe->attr.max_rdd = RXE_MAX_RDD;
> rxe->attr.max_mw= RXE_MAX_MW;
> @@ -128,9 +128,9 @@ static void rxe_init_device_param(struct rxe_dev *rxe)
> /* initialize port attributes */
> static int rxe_init_port_param(struct rxe_port *port)
> {
> - port->attr.state= RXE_PORT_STATE;
> - port->attr.max_mtu = RXE_PORT_MAX_MTU;
> - port->attr.active_mtu = RXE_PORT_ACTIVE_MTU;
> + port->attr.state= IB_PORT_DOWN;
> + port->attr.max_mtu = IB_MTU_4096;
> + port->attr.active_mtu = IB_MTU_256;
> port->attr.gid_tbl_len = RXE_PORT_GID_TBL_LEN;
> port->attr.port_cap_flags = RXE_PORT_PORT_CAP_FLAGS;
> port->attr.max_msg_sz = RXE_PORT_MAX_MSG_SZ;
> @@ -147,8 +147,7 @@ static int rxe_init_port_param(struct rxe_port *port)
> port->attr.active_width = RXE_PORT_ACTIVE_WIDTH;
> port->attr.active_speed = RXE_PORT_ACTIVE_SPEED;
> port->attr.phys_state = RXE_PORT_PHYS_STATE;
> - port->mtu_cap =
> - ib_mtu_enum_to_int(RXE_PORT_ACTIVE_MTU);
> + port->mtu_cap = ib_mtu_enum_to_int(IB_MTU_256);
> port->subnet_prefix = cpu_to_be64(RXE_PORT_SUBNET_PREFIX);
>
> return 0;
These are the only place some of these values are used, so declaration
should be eliminated as well.
Jason
[PATCH linux-next 02/10] arm64: r8a7795: add dma request number for busif1 ~ busif7
From: Jiada Wang
This patch adds dma request number for busif1 ~ busif7
Signed-off-by: Jiada Wang
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 130 ---
1 file changed, 113 insertions(+), 17 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index b5f2273caca4..0a66bda7124f 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -1923,53 +1923,149 @@
rcar_sound,ssi {
ssi0: ssi-0 {
interrupts = ;
- dmas = <&audma0 0x01>, <&audma1 0x02>,
<&audma0 0x15>, <&audma1 0x16>;
- dma-names = "rx", "tx", "rxu", "txu";
+ dmas = <&audma0 0x01>, <&audma1 0x02>,
+ <&audma0 0x15>, <&audma1 0x16>,
+ <&audma0 0x35>, <&audma1 0x36>,
+ <&audma0 0x37>, <&audma1 0x38>,
+ <&audma0 0x47>, <&audma1 0x48>,
+ <&audma0 0x3f>, <&audma1 0x40>,
+ <&audma0 0x43>, <&audma1 0x44>,
+ <&audma0 0x4f>, <&audma1 0x50>,
+ <&audma0 0x53>, <&audma1 0x54>;
+ dma-names = "rx", "tx",
+ "rxu0", "txu0",
+ "rxu1", "txu1",
+ "rxu2", "txu2",
+ "rxu3", "txu3",
+ "rxu4", "txu4",
+ "rxu5", "txu5",
+ "rxu6", "txu6",
+ "rxu7", "txu7";
};
ssi1: ssi-1 {
-interrupts = ;
- dmas = <&audma0 0x03>, <&audma1 0x04>,
<&audma0 0x49>, <&audma1 0x4a>;
- dma-names = "rx", "tx", "rxu", "txu";
+ interrupts = ;
+ dmas = <&audma0 0x03>, <&audma1 0x04>,
+ <&audma0 0x49>, <&audma1 0x4a>,
+ <&audma0 0x4b>, <&audma1 0x4c>,
+ <&audma0 0x57>, <&audma1 0x58>,
+ <&audma0 0x59>, <&audma1 0x5a>,
+ <&audma0 0x5f>, <&audma1 0x60>,
+ <&audma0 0xc3>, <&audma1 0xc4>,
+ <&audma0 0xc7>, <&audma1 0xc8>,
+ <&audma0 0xcb>, <&audma1 0xcc>;
+ dma-names = "rx", "tx",
+ "rxu0", "txu0",
+ "rxu1", "txu1",
+ "rxu2", "txu2",
+ "rxu3", "txu3",
+ "rxu4", "txu4",
+ "rxu5", "txu5",
+ "rxu6", "txu6",
+ "rxu7", "txu7";
};
ssi2: ssi-2 {
interrupts = ;
- dmas = <&audma0 0x05>, <&audma1 0x06>,
<&audma0 0x63>, <&audma1 0x64>;
- dma-names = "rx", "tx", "rxu", "txu";
+ dmas = <&audma0 0x05>, <&audma1 0x06>,
+ <&audma0 0x63>, <&audma1 0x64>,
+ <&audma0 0x67>, <&audma1 0x68>,
+ <&audma0 0x6b>, <&audma1 0x6c>,
+ <&audma0 0x6d>, <&audma1 0x6e>,
+ <&audma0 0xcf>, <&audma1 0xce>,
+ <&audma0 0xeb>, <&audma1 0xec>,
+ <&audma0 0xed>, <&audma1 0xee>,
+ <&audma0 0xef>, <&audma1 0xf0>;
+ dma-names = "rx", "tx",
+ "rxu0"
[PATCH linux-next 04/10] arm64: r8a774a1: add dma request number for busif1 ~ busif7
From: Jiada Wang
This patch adds dma request number for busif1 ~ busif7
Signed-off-by: Jiada Wang
---
arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 137 ++
1 file changed, 117 insertions(+), 20 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
index 012cbb64246e..c9aad3e3b1b0 100644
--- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
@@ -1247,55 +1247,152 @@
rcar_sound,ssi {
ssi0: ssi-0 {
interrupts = ;
- dmas = <&audma0 0x01>, <&audma1 0x02>,
<&audma0 0x15>, <&audma1 0x16>;
- dma-names = "rx", "tx", "rxu", "txu";
+ dmas = <&audma0 0x01>, <&audma1 0x02>,
+ <&audma0 0x15>, <&audma1 0x16>,
+ <&audma0 0x35>, <&audma1 0x36>,
+ <&audma0 0x37>, <&audma1 0x38>,
+ <&audma0 0x47>, <&audma1 0x48>,
+ <&audma0 0x3f>, <&audma1 0x40>,
+ <&audma0 0x43>, <&audma1 0x44>,
+ <&audma0 0x4f>, <&audma1 0x50>,
+ <&audma0 0x53>, <&audma1 0x54>;
+ dma-names = "rx", "tx",
+ "rxu0", "txu0",
+ "rxu1", "txu1",
+ "rxu2", "txu2",
+ "rxu3", "txu3",
+ "rxu4", "txu4",
+ "rxu5", "txu5",
+ "rxu6", "txu6",
+ "rxu7", "txu7";
};
ssi1: ssi-1 {
interrupts = ;
- dmas = <&audma0 0x03>, <&audma1 0x04>,
<&audma0 0x49>, <&audma1 0x4a>;
- dma-names = "rx", "tx", "rxu", "txu";
+ dmas = <&audma0 0x03>, <&audma1 0x04>,
+ <&audma0 0x49>, <&audma1 0x4a>,
+ <&audma0 0x4b>, <&audma1 0x4c>,
+ <&audma0 0x57>, <&audma1 0x58>,
+ <&audma0 0x59>, <&audma1 0x5a>,
+ <&audma0 0x5f>, <&audma1 0x60>,
+ <&audma0 0xc3>, <&audma1 0xc4>,
+ <&audma0 0xc7>, <&audma1 0xc8>,
+ <&audma0 0xcb>, <&audma1 0xcc>;
+ dma-names = "rx", "tx",
+ "rxu0", "txu0",
+ "rxu1", "txu1",
+ "rxu2", "txu2",
+ "rxu3", "txu3",
+ "rxu4", "txu4",
+ "rxu5", "txu5",
+ "rxu6", "txu6",
+ "rxu7", "txu7";
};
ssi2: ssi-2 {
interrupts = ;
- dmas = <&audma0 0x05>, <&audma1 0x06>,
<&audma0 0x63>, <&audma1 0x64>;
- dma-names = "rx", "tx", "rxu", "txu";
+ dmas = <&audma0 0x05>, <&audma1 0x06>,
+ <&audma0 0x63>, <&audma1 0x64>,
+ <&audma0 0x67>, <&audma1 0x68>,
+ <&audma0 0x6b>, <&audma1 0x6c>,
+ <&audma0 0x6d>, <&audma1 0x6e>,
+ <&audma0 0xcf>, <&audma1 0xce>,
+ <&audma0 0xeb>, <&audma1 0xec>,
+ <&audma0 0xed>, <&audma1 0xee>,
+ <&audma0 0xef>, <&audma1 0xf0>;
+ dma-names = "rx", "tx",
+ "rxu0", "txu0",
+
[PATCH v13 2/2] leds: sc27xx: Add pattern_set/clear interfaces for LED controller
This patch implements the 'pattern_set'and 'pattern_clear'
interfaces to support SC27XX LED breathing mode.
Signed-off-by: Baolin Wang
Acked-by: Pavel Machek
---
Changes from v12:
- None.
Changes from v11:
- None.
Changes from v10:
- Add duration alignment function suggested by Jacek.
- Add acked tag from Pavel.
Changes from v9:
- Optimize the ABI documentation file.
- Update the brightness value in hardware pattern mode.
Changes from v8:
- Optimize the ABI documentation file.
Changes from v7:
- Add its own ABI documentation file.
Changes from v6:
- None.
Changes from v5:
- None.
Changes from v4:
- None.
Changes from v3:
- None.
Changes from v2:
- None.
Changes from v1:
- Remove pattern_get interface.
---
.../ABI/testing/sysfs-class-led-driver-sc27xx | 22
drivers/leds/leds-sc27xx-bltc.c| 121
2 files changed, 143 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-class-led-driver-sc27xx
diff --git a/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx
b/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx
new file mode 100644
index 000..45b1e60
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx
@@ -0,0 +1,22 @@
+What: /sys/class/leds//hw_pattern
+Date: September 2018
+KernelVersion: 4.20
+Description:
+ Specify a hardware pattern for the SC27XX LED. For the SC27XX
+ LED controller, it only supports 4 stages to make a single
+ hardware pattern, which is used to configure the rise time,
+ high time, fall time and low time for the breathing mode.
+
+ For the breathing mode, the SC27XX LED only expects one
brightness
+ for the high stage. To be compatible with the hardware pattern
+ format, we should set brightness as 0 for rise stage, fall
+ stage and low stage.
+
+ Min stage duration: 125 ms
+ Max stage duration: 31875 ms
+
+ Since the stage duration step is 125 ms, the duration should be
+ a multiplier of 125, like 125ms, 250ms, 375ms, 500ms ...
31875ms.
+
+ Thus the format of the hardware pattern values should be:
+ "0 rise_duration brightness high_duration 0 fall_duration 0
low_duration".
diff --git a/drivers/leds/leds-sc27xx-bltc.c b/drivers/leds/leds-sc27xx-bltc.c
index 9d9b7aa..fecf27f 100644
--- a/drivers/leds/leds-sc27xx-bltc.c
+++ b/drivers/leds/leds-sc27xx-bltc.c
@@ -32,8 +32,18 @@
#define SC27XX_DUTY_MASK GENMASK(15, 0)
#define SC27XX_MOD_MASKGENMASK(7, 0)
+#define SC27XX_CURVE_SHIFT 8
+#define SC27XX_CURVE_L_MASKGENMASK(7, 0)
+#define SC27XX_CURVE_H_MASKGENMASK(15, 8)
+
#define SC27XX_LEDS_OFFSET 0x10
#define SC27XX_LEDS_MAX3
+#define SC27XX_LEDS_PATTERN_CNT4
+/* Stage duration step, in milliseconds */
+#define SC27XX_LEDS_STEP 125
+/* Minimum and maximum duration, in milliseconds */
+#define SC27XX_DELTA_T_MIN SC27XX_LEDS_STEP
+#define SC27XX_DELTA_T_MAX (SC27XX_LEDS_STEP * 255)
struct sc27xx_led {
char name[LED_MAX_NAME_SIZE];
@@ -122,6 +132,113 @@ static int sc27xx_led_set(struct led_classdev *ldev, enum
led_brightness value)
return err;
}
+static void sc27xx_led_clamp_align_delta_t(u32 *delta_t)
+{
+ u32 v, offset, t = *delta_t;
+
+ v = t + SC27XX_LEDS_STEP / 2;
+ v = clamp_t(u32, v, SC27XX_DELTA_T_MIN, SC27XX_DELTA_T_MAX);
+ offset = v - SC27XX_DELTA_T_MIN;
+ offset = SC27XX_LEDS_STEP * (offset / SC27XX_LEDS_STEP);
+
+ *delta_t = SC27XX_DELTA_T_MIN + offset;
+}
+
+static int sc27xx_led_pattern_clear(struct led_classdev *ldev)
+{
+ struct sc27xx_led *leds = to_sc27xx_led(ldev);
+ struct regmap *regmap = leds->priv->regmap;
+ u32 base = sc27xx_led_get_offset(leds);
+ u32 ctrl_base = leds->priv->base + SC27XX_LEDS_CTRL;
+ u8 ctrl_shift = SC27XX_CTRL_SHIFT * leds->line;
+ int err;
+
+ mutex_lock(&leds->priv->lock);
+
+ /* Reset the rise, high, fall and low time to zero. */
+ regmap_write(regmap, base + SC27XX_LEDS_CURVE0, 0);
+ regmap_write(regmap, base + SC27XX_LEDS_CURVE1, 0);
+
+ err = regmap_update_bits(regmap, ctrl_base,
+ (SC27XX_LED_RUN | SC27XX_LED_TYPE) << ctrl_shift, 0);
+
+ ldev->brightness = LED_OFF;
+
+ mutex_unlock(&leds->priv->lock);
+
+ return err;
+}
+
+static int sc27xx_led_pattern_set(struct led_classdev *ldev,
+ struct led_pattern *pattern,
+ u32 len, int repeat)
+{
+ struct sc27xx_led *leds = to_sc27xx_led(ldev);
+ u32 base = sc27xx_led_get_offset(leds);
+ u32 ctrl_base = leds->priv->base + SC27XX_LEDS_CTRL;
+ u8 ctrl_shift = SC27XX_CTRL_SHIFT * leds->line;
+ struct regmap *regmap = leds->priv-
[PATCH v13 1/2] leds: core: Introduce LED pattern trigger
This patch adds one new led trigger that LED device can configure the software or hardware pattern and trigger it. Consumers can write 'pattern' file to enable the software pattern which alters the brightness for the specified duration with one software timer. Moreover consumers can write 'hw_pattern' file to enable the hardware pattern for some LED controllers which can autonomously control brightness over time, according to some preprogrammed hardware patterns. Signed-off-by: Raphael Teysseyre Signed-off-by: Baolin Wang --- Changes from v12: - Add gradual dimming support for software pattern. Changes from v11: - Change -1 means repeat indefinitely. Changes from v10: - Change 'int' to 'u32' for delta_t field. Changes from v9: - None. Changes from v8: - None. Changes from v7: - Move the SC27XX hardware patterns description into its own ABI file. Changes from v6: - Improve commit message. - Optimize the description of the hw_pattern file. - Simplify some logics. Changes from v5: - Add one 'hw_pattern' file for hardware patterns. Changes from v4: - Change the repeat file to return the originally written number. - Improve comments. - Fix some build warnings. Changes from v3: - Reset pattern number to 0 if user provides incorrect pattern string. - Support one pattern. Changes from v2: - Remove hardware_pattern boolen. - Chnage the pattern string format. Changes from v1: - Use ATTRIBUTE_GROUPS() to define attributes. - Introduce hardware_pattern flag to determine if software pattern or hardware pattern. - Re-implement pattern_trig_store_pattern() function. - Remove pattern_get() interface. - Improve comments. - Other small optimization. --- .../ABI/testing/sysfs-class-led-trigger-pattern| 74 drivers/leds/trigger/Kconfig |7 + drivers/leds/trigger/Makefile |1 + drivers/leds/trigger/ledtrig-pattern.c | 406 include/linux/leds.h | 15 + 5 files changed, 503 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-led-trigger-pattern create mode 100644 drivers/leds/trigger/ledtrig-pattern.c diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern new file mode 100644 index 000..e84d42a --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern @@ -0,0 +1,74 @@ +What: /sys/class/leds//pattern +Date: September 2018 +KernelVersion: 4.20 +Description: + Specify a software pattern for the LED, that supports altering + the brightness for the specified duration with one software + timer. It can do gradual dimming and constant brightness. + + The pattern is given by a series of tuples, of brightness and + duration (ms). The LED is expected to traverse the series and + each brightness value for the specified duration. Duration of + 0 means brightness should immediately change to new value. + + 1. The gradual dimming format of the software pattern values + should be: + "brightness_1 duration_1 brightness_2 duration_2 brightness_3 + duration_3 ...". For example: + + echo 0 1000 255 2000 > pattern + + It will make the LED go gradually from zero-intensity to max (255) + intensity in 1000 milliseconds, then back to zero intensity in 2000 + milliseconds: + + LED brightness + ^ + 255-| / \/ \/ + | /\ /\ / + | / \ / \ / + |/ \ / \ / + 0-| / \/ \/ + +---0123456> time (s) + + 2. To make the LED go instantly from one brigntess value to another, + we should use use zero-time lengths. So the format should be: + "brightness_1 duration_1 brightness_1 0 brightness_2 duration_2 + brightness_2 0 ...". For example: + + echo 0 1000 0 0 255 2000 255 0 > pattern + + It will make the LED stay off for one second, then stay at max brightness + for two seconds: + + LED brightness + ^ + 255-|+-++-+ + || || | + || || | + || || | + 0-| -+ ++ + + +---0123456> time (s) + +What: /sys/class/leds//hw_pattern +Date: September 201
[PATCH linux-next 03/10] arm64: r8a7796: add dma request number for busif1 ~ busif7
From: Jiada Wang
This patch adds dma request number for busif1 ~ busif7
Signed-off-by: Jiada Wang
---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 136 +++
1 file changed, 116 insertions(+), 20 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 1ec6aaa520c1..e9b05d997c4e 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -1797,53 +1797,149 @@
rcar_sound,ssi {
ssi0: ssi-0 {
interrupts = ;
- dmas = <&audma0 0x01>, <&audma1 0x02>,
<&audma0 0x15>, <&audma1 0x16>;
- dma-names = "rx", "tx", "rxu", "txu";
+ dmas = <&audma0 0x01>, <&audma1 0x02>,
+ <&audma0 0x15>, <&audma1 0x16>,
+ <&audma0 0x35>, <&audma1 0x36>,
+ <&audma0 0x37>, <&audma1 0x38>,
+ <&audma0 0x47>, <&audma1 0x48>,
+ <&audma0 0x3f>, <&audma1 0x40>,
+ <&audma0 0x43>, <&audma1 0x44>,
+ <&audma0 0x4f>, <&audma1 0x50>,
+ <&audma0 0x53>, <&audma1 0x54>;
+ dma-names = "rx", "tx",
+ "rxu0", "txu0",
+ "rxu1", "txu1",
+ "rxu2", "txu2",
+ "rxu3", "txu3",
+ "rxu4", "txu4",
+ "rxu5", "txu5",
+ "rxu6", "txu6",
+ "rxu7", "txu7";
};
ssi1: ssi-1 {
interrupts = ;
- dmas = <&audma0 0x03>, <&audma1 0x04>,
<&audma0 0x49>, <&audma1 0x4a>;
- dma-names = "rx", "tx", "rxu", "txu";
+ dmas = <&audma0 0x03>, <&audma1 0x04>,
+ <&audma0 0x49>, <&audma1 0x4a>,
+ <&audma0 0x4b>, <&audma1 0x4c>,
+ <&audma0 0x57>, <&audma1 0x58>,
+ <&audma0 0x59>, <&audma1 0x5a>,
+ <&audma0 0x5f>, <&audma1 0x60>,
+ <&audma0 0xc3>, <&audma1 0xc4>,
+ <&audma0 0xc7>, <&audma1 0xc8>,
+ <&audma0 0xcb>, <&audma1 0xcc>;
+ dma-names = "rx", "tx",
+ "rxu0", "txu0",
+ "rxu1", "txu1",
+ "rxu2", "txu2",
+ "rxu3", "txu3",
+ "rxu4", "txu4",
+ "rxu5", "txu5",
+ "rxu6", "txu6",
+ "rxu7", "txu7";
};
ssi2: ssi-2 {
interrupts = ;
- dmas = <&audma0 0x05>, <&audma1 0x06>,
<&audma0 0x63>, <&audma1 0x64>;
- dma-names = "rx", "tx", "rxu", "txu";
+ dmas = <&audma0 0x05>, <&audma1 0x06>,
+ <&audma0 0x63>, <&audma1 0x64>,
+ <&audma0 0x67>, <&audma1 0x68>,
+ <&audma0 0x6b>, <&audma1 0x6c>,
+ <&audma0 0x6d>, <&audma1 0x6e>,
+ <&audma0 0xcf>, <&audma1 0xce>,
+ <&audma0 0xeb>, <&audma1 0xec>,
+ <&audma0 0xed>, <&audma1 0xee>,
+ <&audma0 0xef>, <&audma1 0xf0>;
+ dma-names = "rx", "tx",
+ "rxu0", "txu0",
+
[PATCH linux-next 00/10] ASoC: rsnd: support to set different busif
From: Jiada Wang Rcar audio DMA/SSIU already support to use different BUSIF to transfer data, but busif is fixed at 0. This patch set adds kctrl interface "SSI Out/In BUSIF", which enables to configure busif for each dai-stream used in transfer. device tree files are updated to use extended audio dmac register, and add dma request number for busif1 ~ busif7 Jiada Wang (10): ASoC: rsnd: ssi: Request dedicated dma channels for busif1 to 7 arm64: r8a7795: add dma request number for busif1 ~ busif7 arm64: r8a7796: add dma request number for busif1 ~ busif7 arm64: r8a774a1: add dma request number for busif1 ~ busif7 arm64: r8a7795: change to use extended audio dmac register arm64: r8a7796: change to use extended audio dmac register arm64: r8a774a1: change to use extended audio dmac register arm64: r8a77965: change to use extended audio dmac register ASoC: rsnd: add busif property to dai stream ASoC: rsnd: Add kctrl to configure dai's busif arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 139 ++ arch/arm64/boot/dts/renesas/r8a7795.dtsi | 132 +--- arch/arm64/boot/dts/renesas/r8a7796.dtsi | 138 + arch/arm64/boot/dts/renesas/r8a77965.dtsi | 2 +- sound/soc/sh/rcar/core.c | 16 ++- sound/soc/sh/rcar/dma.c | 32 + sound/soc/sh/rcar/rsnd.h | 5 + sound/soc/sh/rcar/ssi.c | 56 +++-- 8 files changed, 451 insertions(+), 69 deletions(-) -- 2.17.0
[PATCH linux-next 01/10] ASoC: rsnd: ssi: Request dedicated dma channels for busif1 to 7
From: Jiada Wang
Currently ssi driver only request dma channel for SSI_0,
which is used to transfer data to/from busif0.
But since busif1 to busif7 also maybe used, dedicated dma channels
are request for data transfer between these busif.
Signed-off-by: Jiada Wang
---
sound/soc/sh/rcar/ssi.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/sound/soc/sh/rcar/ssi.c b/sound/soc/sh/rcar/ssi.c
index 3adcc4f778f7..75a3d15084c2 100644
--- a/sound/soc/sh/rcar/ssi.c
+++ b/sound/soc/sh/rcar/ssi.c
@@ -76,6 +76,8 @@
#define SSI_NAME "ssi"
+#define SSI_DMA_NAME_SIZE 10
+
struct rsnd_ssi {
struct rsnd_mod mod;
@@ -938,12 +940,20 @@ static struct dma_chan *rsnd_ssi_dma_req(struct
rsnd_dai_stream *io,
{
struct rsnd_priv *priv = rsnd_mod_to_priv(mod);
int is_play = rsnd_io_is_play(io);
- char *name;
+ int busif = rsnd_ssi_get_busif(io);
+ char name[SSI_DMA_NAME_SIZE];
- if (rsnd_ssi_use_busif(io))
- name = is_play ? "rxu" : "txu";
- else
- name = is_play ? "rx" : "tx";
+ if (rsnd_ssi_use_busif(io)) {
+ if (is_play)
+ snprintf(name, SSI_DMA_NAME_SIZE, "rxu%d", busif);
+ else
+ snprintf(name, SSI_DMA_NAME_SIZE, "txu%d", busif);
+ } else {
+ if (is_play)
+ snprintf(name, SSI_DMA_NAME_SIZE, "rx");
+ else
+ snprintf(name, SSI_DMA_NAME_SIZE, "tx");
+ }
return rsnd_dma_request_channel(rsnd_ssi_of_node(priv),
mod, name);
--
2.17.0
[PATCH v2] IB/rxe: Avoid implicit enum conversions in rxe_init functions
Clang warns when an emumerated type is implicitly converted to another.
drivers/infiniband/sw/rxe/rxe.c:106:27: warning: implicit conversion
from enumeration type 'enum rxe_device_param' to different enumeration
type 'enum ib_atomic_cap' [-Wenum-conversion]
rxe->attr.atomic_cap= RXE_ATOMIC_CAP;
~ ^~
drivers/infiniband/sw/rxe/rxe.c:131:22: warning: implicit conversion
from enumeration type 'enum rxe_port_param' to different enumeration
type 'enum ib_port_state' [-Wenum-conversion]
port->attr.state= RXE_PORT_STATE;
~ ^~
drivers/infiniband/sw/rxe/rxe.c:132:24: warning: implicit conversion
from enumeration type 'enum rxe_port_param' to different enumeration
type 'enum ib_mtu' [-Wenum-conversion]
port->attr.max_mtu = RXE_PORT_MAX_MTU;
~ ^~~~
drivers/infiniband/sw/rxe/rxe.c:133:27: warning: implicit conversion
from enumeration type 'enum rxe_port_param' to different enumeration
type 'enum ib_mtu' [-Wenum-conversion]
port->attr.active_mtu = RXE_PORT_ACTIVE_MTU;
~ ^~~
drivers/infiniband/sw/rxe/rxe.c:151:24: warning: implicit conversion
from enumeration type 'enum rxe_port_param' to different enumeration
type 'enum ib_mtu' [-Wenum-conversion]
ib_mtu_enum_to_int(RXE_PORT_ACTIVE_MTU);
~~ ^~~
5 warnings generated.
Use the appropriate values from the expected enumerated type so no
conversion needs to happen.
Reported-by: Nick Desaulniers
Signed-off-by: Nathan Chancellor
---
v1 -> v2:
* Don't cast, just use the expecting enumerated value directly, per
Jason's request
drivers/infiniband/sw/rxe/rxe.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/infiniband/sw/rxe/rxe.c b/drivers/infiniband/sw/rxe/rxe.c
index 10999fa69281..2f4e57886b89 100644
--- a/drivers/infiniband/sw/rxe/rxe.c
+++ b/drivers/infiniband/sw/rxe/rxe.c
@@ -103,7 +103,7 @@ static void rxe_init_device_param(struct rxe_dev *rxe)
rxe->attr.max_res_rd_atom = RXE_MAX_RES_RD_ATOM;
rxe->attr.max_qp_init_rd_atom = RXE_MAX_QP_INIT_RD_ATOM;
rxe->attr.max_ee_init_rd_atom = RXE_MAX_EE_INIT_RD_ATOM;
- rxe->attr.atomic_cap= RXE_ATOMIC_CAP;
+ rxe->attr.atomic_cap= IB_ATOMIC_HCA;
rxe->attr.max_ee= RXE_MAX_EE;
rxe->attr.max_rdd = RXE_MAX_RDD;
rxe->attr.max_mw= RXE_MAX_MW;
@@ -128,9 +128,9 @@ static void rxe_init_device_param(struct rxe_dev *rxe)
/* initialize port attributes */
static int rxe_init_port_param(struct rxe_port *port)
{
- port->attr.state= RXE_PORT_STATE;
- port->attr.max_mtu = RXE_PORT_MAX_MTU;
- port->attr.active_mtu = RXE_PORT_ACTIVE_MTU;
+ port->attr.state= IB_PORT_DOWN;
+ port->attr.max_mtu = IB_MTU_4096;
+ port->attr.active_mtu = IB_MTU_256;
port->attr.gid_tbl_len = RXE_PORT_GID_TBL_LEN;
port->attr.port_cap_flags = RXE_PORT_PORT_CAP_FLAGS;
port->attr.max_msg_sz = RXE_PORT_MAX_MSG_SZ;
@@ -147,8 +147,7 @@ static int rxe_init_port_param(struct rxe_port *port)
port->attr.active_width = RXE_PORT_ACTIVE_WIDTH;
port->attr.active_speed = RXE_PORT_ACTIVE_SPEED;
port->attr.phys_state = RXE_PORT_PHYS_STATE;
- port->mtu_cap =
- ib_mtu_enum_to_int(RXE_PORT_ACTIVE_MTU);
+ port->mtu_cap = ib_mtu_enum_to_int(IB_MTU_256);
port->subnet_prefix = cpu_to_be64(RXE_PORT_SUBNET_PREFIX);
return 0;
--
2.19.0
[PATCH] arm64: dts: k3-am65-wakeup: Fix wakeup_uart reg address
cbass_wakeup interconnect which is the parent of wakeup_uart node
defines address-cells=1 and size-cells=1, therefore fix up reg property
of wakeup_uart node accordingly. Otherwise, this UART instance fails to
probe if enabled.
Fixes: 4201af2544b3 ("arm64: dts: ti: am654: Add uart nodes")
Signed-off-by: Vignesh R
---
Based on next-20180926
arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
b/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
index ee56959f4af8..c617393ea767 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
@@ -44,7 +44,7 @@
wkup_uart0: serial@4230 {
compatible = "ti,am654-uart";
- reg = <0x00 0x4230 0x00 0x100>;
+ reg = <0x4230 0x100>;
reg-shift = <2>;
reg-io-width = <4>;
interrupts = ;
--
2.19.0
[PATCH v7 06/39] component: alloc component_match without any comp to match
If all the components associated to a component master is not added
to the component framework due to the HW capability or Kconfig
selection, component_match will be NULL at
component_master_add_with_match().
To avoid this, component_match_alloc() is added to the framework,
to allcoate the struct component_match with zero associated components.
Hence component master can be added with a component_match with zero
associated components.
This helps the component master bind call to get triggered,
even if no component is registered for that particular master.
This is meant for big PCI device drivers where small/optional
features are external components, and based on usecases different
combination of components are build as entire driver.
In such PCI device driver Load, if we use the component master for
waiting for few components(features) availability, only if they are
supported by the underlying HW, then we need to allocate memory for
component_match using the API introduced in this change before
the call to component_master_add_with_match.
v2:
No Change.
Signed-off-by: Ramalingam C
Suggested-by: Daniel Vetter
Cc: Greg Kroah-Hartman
Cc: Kate Stewart
Cc: Thomas Gleixner
Cc: Philippe Ombredanne
Cc: linux-kernel@vger.kernel.org
---
drivers/base/component.c | 30 ++
include/linux/component.h | 2 ++
2 files changed, 32 insertions(+)
diff --git a/drivers/base/component.c b/drivers/base/component.c
index 8946dfee4768..007fb738263a 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -312,6 +312,36 @@ static int component_match_realloc(struct device *dev,
}
/*
+ * Allocate the match without any component_match_array elements.
+ *
+ * This function is useful when the component master might end up
+ * registering itself without any matching components.
+ */
+void component_match_alloc(struct device *master,
+ struct component_match **matchptr)
+{
+ struct component_match *match = *matchptr;
+
+ if (IS_ERR(match))
+ return;
+
+ if (match)
+ return;
+
+ match = devres_alloc(devm_component_match_release,
+sizeof(*match), GFP_KERNEL);
+ if (!match) {
+ *matchptr = ERR_PTR(-ENOMEM);
+ return;
+ }
+
+ devres_add(master, match);
+
+ *matchptr = match;
+}
+EXPORT_SYMBOL(component_match_alloc);
+
+/*
* Add a component to be matched, with a release function.
*
* The match array is first created or extended if necessary.
diff --git a/include/linux/component.h b/include/linux/component.h
index e71fbbbc74e2..3f6b420a58f8 100644
--- a/include/linux/component.h
+++ b/include/linux/component.h
@@ -37,6 +37,8 @@ void component_match_add_release(struct device *master,
struct component_match **matchptr,
void (*release)(struct device *, void *),
int (*compare)(struct device *, void *), void *compare_data);
+void component_match_alloc(struct device *master,
+ struct component_match **matchptr);
static inline void component_match_add(struct device *master,
struct component_match **matchptr,
--
2.7.4
Re: [PATCH] csky: fixups after bootmem removal
On Wed, Sep 26, 2018 at 02:27:45PM +0300, Mike Rapoport wrote:
> Hi,
>
> The below patch fixes the bootmem leftovers in csky. It is based on the
> current mmots and csky build there fails because of undefined reference to
> dma_direct_ops:
>
> MODPOST vmlinux.o
> kernel/dma/mapping.o: In function `dmam_alloc_attrs':
> kernel/dma/mapping.c:143: undefined reference to `dma_direct_ops'
> kernel/dma/mapping.o: In function `dmam_declare_coherent_memory':
> kernel/dma/mapping.c:184: undefined reference to `dma_direct_ops'
> mm/dmapool.o: In function `dma_free_attrs':
> include/linux/dma-mapping.h:558: undefined reference to `dma_direct_ops'
>
> I've blindly added "select DMA_DIRECT_OPS" to arch/csky/Kconfig and it
> fixed the build, but I really have no idea if this the right thing to do...
You are almost right, the issue is come from the patch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=bc3ec75de5452db59b683487867ba562b950708a
we need:
- select DMA_NONCOHERENT_OPS
+ select DMA_DIRECT_OPS
I'll fixup it in my repo.
> From 63c3b24e661e6cad88f0432dd460d35a16741871 Mon Sep 17 00:00:00 2001
> From: Mike Rapoport
> Date: Wed, 26 Sep 2018 13:40:13 +0300
> Subject: [PATCH] csky: fixups after bootmem removal
>
> The bootmem removal patchest didn't take into account csky architecture and
> it still had bootmem leftovers. Remove them now.
>
> Signed-off-by: Mike Rapoport
> ---
> arch/csky/Kconfig| 1 -
> arch/csky/kernel/setup.c | 1 -
> arch/csky/mm/highmem.c | 4 ++--
> arch/csky/mm/init.c | 3 +--
> 4 files changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/arch/csky/Kconfig b/arch/csky/Kconfig
> index fb2a0ae..fc25ea6 100644
> --- a/arch/csky/Kconfig
> +++ b/arch/csky/Kconfig
> @@ -35,7 +35,6 @@ config CSKY
> select HAVE_C_RECORDMCOUNT
> select HAVE_DMA_API_DEBUG
> select HAVE_DMA_CONTIGUOUS
> - select HAVE_MEMBLOCK
> select MAY_HAVE_SPARSE_IRQ
> select MODULES_USE_ELF_RELA if MODULES
> select OF
> diff --git a/arch/csky/kernel/setup.c b/arch/csky/kernel/setup.c
> index 27f9e10..bee4d26 100644
> --- a/arch/csky/kernel/setup.c
> +++ b/arch/csky/kernel/setup.c
> @@ -3,7 +3,6 @@
>
> #include
> #include
> -#include
> #include
> #include
> #include
> diff --git a/arch/csky/mm/highmem.c b/arch/csky/mm/highmem.c
> index 149921a..5b90501 100644
> --- a/arch/csky/mm/highmem.c
> +++ b/arch/csky/mm/highmem.c
> @@ -4,7 +4,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
> #include
> @@ -138,7 +138,7 @@ static void __init fixrange_init (unsigned long start,
> unsigned long end,
> pmd = (pmd_t *)pud;
> for (; (k < PTRS_PER_PMD) && (vaddr != end); pmd++,
> k++) {
> if (pmd_none(*pmd)) {
> - pte = (pte_t *)
> alloc_bootmem_low_pages(PAGE_SIZE);
> + pte = (pte_t *)
> memblock_alloc_low(PAGE_SIZE, PAGE_SIZE);
> set_pmd(pmd, __pmd(__pa(pte)));
> BUG_ON(pte != pte_offset_kernel(pmd,
> 0));
> }
> diff --git a/arch/csky/mm/init.c b/arch/csky/mm/init.c
> index fd2791b..46c5aaa 100644
> --- a/arch/csky/mm/init.c
> +++ b/arch/csky/mm/init.c
> @@ -14,7 +14,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -44,7 +43,7 @@ void __init mem_init(void)
> #endif
> high_memory = (void *) __va(max_low_pfn << PAGE_SHIFT);
>
> - free_all_bootmem();
> + memblock_free_all();
>
> #ifdef CONFIG_HIGHMEM
> for (tmp = highstart_pfn; tmp < highend_pfn; tmp++) {
The patch looks good for me.
Thx
Guo Ren
Re: [PATCH] Raise maximum number of memory controllers
On Wed, Sep 26, 2018 at 04:02:57PM -0700, Luck, Tony wrote: > We don't have stats, nor control of power on a per memory controller > or per dimm basis. So all these files are just noise. Yeah, and also, looking at your previous mail, stuff like: /sys/bus/mc6/devices/dimm0 /sys/bus/mc4/devices/dimm0 doesn't make any sense: why is mc* directly under bus? It should be under ...bus/edac/mc/... We'll have to clean it up carefully, when there's time. > But ... we are at -rc5. Not sure that we'll figure out, write, test & debug > the proper solution in the next 3-4 weeks. So perhaps we should apply > > -#define EDAC_MAX_MCS 16 > +#define EDAC_MAX_MCS 64 > > as a temporary band-aid to get HPE's 32-socket machine running while > we work on the proper fix? Yeah, after sleeping on it I see it the same way - band-aid it now and clean it up properly later. Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH] IB/mlx4: Avoid implicit enumerated type conversion
On Wed, Sep 26, 2018 at 06:08:03PM -0700, Nathan Chancellor wrote:
> On Mon, Sep 24, 2018 at 08:37:22PM -0600, Jason Gunthorpe wrote:
> > On Mon, Sep 24, 2018 at 03:29:38PM -0700, Nick Desaulniers wrote:
> > > On Mon, Sep 24, 2018 at 3:27 PM Nathan Chancellor
> > > wrote:
> > > >
> > > > On Mon, Sep 24, 2018 at 03:24:36PM -0700, Nick Desaulniers wrote:
> > > > > On Mon, Sep 24, 2018 at 12:57 PM Nathan Chancellor
> > > > > wrote:
> > > > > >
> > > > > > Clang warns when one enumerated type is implicitly converted to
> > > > > > another.
> > > > > >
> > > > > > drivers/infiniband/hw/mlx4/mad.c:1811:41: warning: implicit
> > > > > > conversion
> > > > > > from enumeration type 'enum mlx4_ib_qp_flags' to different
> > > > > > enumeration
> > > > > > type 'enum ib_qp_create_flags' [-Wenum-conversion]
> > > > > > qp_init_attr.init_attr.create_flags =
> > > > > > MLX4_IB_SRIOV_TUNNEL_QP;
> > > > > > ~
> > > > > > ^~~
> > > > > >
> > > > > > drivers/infiniband/hw/mlx4/mad.c:1819:41: warning: implicit
> > > > > > conversion
> > > > > > from enumeration type 'enum mlx4_ib_qp_flags' to different
> > > > > > enumeration
> > > > > > type 'enum ib_qp_create_flags' [-Wenum-conversion]
> > > > > > qp_init_attr.init_attr.create_flags =
> > > > > > MLX4_IB_SRIOV_SQP;
> > > > > > ~
> > > > > > ^
> > > > > >
> > > > > > The type mlx4_ib_qp_flags explicitly provides supplemental values
> > > > > > to the
> > > > > > type ib_qp_create_flags. Make that clear to Clang by changing the
> > > > > > create_flags type to u32.
> > > > > >
> > > > > > Reported-by: Nick Desaulniers
> > > > > > Signed-off-by: Nathan Chancellor
> > > > > > include/rdma/ib_verbs.h | 2 +-
> > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
> > > > > > index e463d3007a35..f6f4d9e3c8ed 100644
> > > > > > +++ b/include/rdma/ib_verbs.h
> > > > > > @@ -1149,7 +1149,7 @@ struct ib_qp_init_attr {
> > > > > > struct ib_qp_capcap;
> > > > > > enum ib_sig_typesq_sig_type;
> > > > > > enum ib_qp_type qp_type;
> > > > > > - enum ib_qp_create_flags create_flags;
> > > > > > + u32 create_flags;
> > > > >
> > > > > I think it might be better to just have explicit casts at the
> > > > > assignment. What do the maintainers think?
> > > > >
> > > >
> > > > That's fine with me, I tend to explicitly cast if it is only one
> > > > location but it certainly makes sense in this case as well. I'll
> > > > wait for the maintainers to weigh in before sending a v2.
> > >
> > > Yeah, I mean my opinion on this might seem arbitrary, but based on the
> > > pattern and the comment in ib_qp_create_flags, those enum values are
> > > reserved to be "subclassed" in a sense, so they should always be in
> > > sync or this code will have bigger problems.
> >
> > One should not use an 'enum' type name for bitfield storage, as once
> > you start or'ing things together the values no longer fall on the
> > enum. Some compilers and tools even give warnings in this case, ie
> >
> >enum x foo = X_A | X_B;
> >
> > Is an assignment from 'int' to an 'enum x' with an implicit cast.
> >
> > For this reason, usually bitfield enum declarations should be
> > anonymous.
> >
> > Jason
>
> Hi Jason,
>
> I apologize for not understanding but how should I adjust my patch so
> that it is acceptable? Do you want the explicit casts like Nick
> suggested?
No, I think your original patch is fine, I was waiting to see if you
or Nick disagreed with my assessment on bitfields..
Jason
Re: [PATCH V3 10/13] x86/hyper-v: Add HvFlushGuestAddressList hypercall support
On 9/27/2018 12:16 PM, Michael Kelley (EOSG) wrote: > From: Tianyu Lan Sent: Wednesday, September 26, 2018 8:50 PM >> >> Hyper-V provides HvFlushGuestAddressList() hypercall to flush EPT tlb >> with specified ranges. This patch is to add the hypercall support. >> >> Signed-off-by: Lan Tianyu >> > > Looks good! > > Reviewed-by: Michael Kelley > Thanks.
RE: [PATCH V3 10/13] x86/hyper-v: Add HvFlushGuestAddressList hypercall support
From: Tianyu Lan Sent: Wednesday, September 26, 2018 8:50 PM > > Hyper-V provides HvFlushGuestAddressList() hypercall to flush EPT tlb > with specified ranges. This patch is to add the hypercall support. > > Signed-off-by: Lan Tianyu > Looks good! Reviewed-by: Michael Kelley
Re: [PATCH] torture-test modules: Remove unnecessary "ret" variables
On Tue, Sep 25, 2018 at 02:47:08PM -0500, Pierce Griffiths wrote:
> Paul,
> The #ifdef cannot be replaced, as this would break the build for
> CONFIG_HOTPLUG_CPU=n builds. There are assignments and references to two
> global variables, a struct, and a function that are declared/defined in
> a large "#ifdef CONFIG_HOTPLUG_CPU" block which ends directly above
> torture_onoff_init(). IS_ENABLED() would cause these references to be
> present at compile time, but not their declarations or definitions,
> which would certainly cause a compilation error.
Good point, and thank you! I have queued the original patch with a
minor edit to the Subject line. It will make it to my -rcu tree once
I find a decent internet connection.
Thanx, Paul
> On Sat, Sep 22, 2018 at 02:26:30PM -0700, Paul E. McKenney wrote:
> > On Fri, Sep 21, 2018 at 08:21:31PM -0500, Pierce Griffiths wrote:
> > > Remove return variables (declared as "ret") in cases where,
> > > depending on whether a condition evaluates as true, the result of a
> > > function call can be immediately returned instead of storing the result in
> > > the return variable. When the condition evaluates as false, the constant
> > > initially stored in the return variable at declaration is returned
> > > instead.
> > >
> > > Signed-off-by: Pierce Griffiths
> >
> > Not bad, as it does safe a couple of lines. Is it possible to save
> > a few more by using "if (!IS_ENABLED(CONFIG_HOTPLUG_CPU))" instead
> > of the #ifdef? Or does that end up breaking the build for either
> > CONFIG_HOTPLUG_CPU=y or CONFIG_HOTPLUG_CPU=n builds?
> >
> > Thanx, Paul
> >
> > > ---
> > > kernel/torture.c | 22 --
> > > 1 file changed, 8 insertions(+), 14 deletions(-)
> > >
> > > diff --git a/kernel/torture.c b/kernel/torture.c
> > > index 1ac24a826589..f4cec6db7f3c 100644
> > > --- a/kernel/torture.c
> > > +++ b/kernel/torture.c
> > > @@ -233,16 +233,15 @@ torture_onoff(void *arg)
> > > */
> > > int torture_onoff_init(long ooholdoff, long oointerval)
> > > {
> > > - int ret = 0;
> > > -
> > > #ifdef CONFIG_HOTPLUG_CPU
> > > onoff_holdoff = ooholdoff;
> > > onoff_interval = oointerval;
> > > if (onoff_interval <= 0)
> > > return 0;
> > > - ret = torture_create_kthread(torture_onoff, NULL, onoff_task);
> > > -#endif /* #ifdef CONFIG_HOTPLUG_CPU */
> > > - return ret;
> > > + return torture_create_kthread(torture_onoff, NULL, onoff_task);
> > > +#else /* #ifdef CONFIG_HOTPLUG_CPU */
> > > + return 0;
> > > +#endif /* #else #ifdef CONFIG_HOTPLUG_CPU */
> > > }
> > > EXPORT_SYMBOL_GPL(torture_onoff_init);
> > >
> > > @@ -513,15 +512,13 @@ static int torture_shutdown(void *arg)
> > > */
> > > int torture_shutdown_init(int ssecs, void (*cleanup)(void))
> > > {
> > > - int ret = 0;
> > > -
> > > torture_shutdown_hook = cleanup;
> > > if (ssecs > 0) {
> > > shutdown_time = ktime_add(ktime_get(), ktime_set(ssecs, 0));
> > > - ret = torture_create_kthread(torture_shutdown, NULL,
> > > + return torture_create_kthread(torture_shutdown, NULL,
> > >shutdown_task);
> > > }
> > > - return ret;
> > > + return 0;
> > > }
> > > EXPORT_SYMBOL_GPL(torture_shutdown_init);
> > >
> > > @@ -619,13 +616,10 @@ static int torture_stutter(void *arg)
> > > /*
> > > * Initialize and kick off the torture_stutter kthread.
> > > */
> > > -int torture_stutter_init(int s)
> > > +int torture_stutter_init(const int s)
> > > {
> > > - int ret;
> > > -
> > > stutter = s;
> > > - ret = torture_create_kthread(torture_stutter, NULL, stutter_task);
> > > - return ret;
> > > + return torture_create_kthread(torture_stutter, NULL, stutter_task);
> > > }
> > > EXPORT_SYMBOL_GPL(torture_stutter_init);
> > >
> > > --
> > > 2.19.0
> > >
> >
>
Re: possible deadlock in ovl_write_iter
[CC: fsdevel]
On Thu, Sep 27, 2018 at 6:48 AM Amir Goldstein wrote:
>
> On Wed, Sep 26, 2018 at 11:44 PM syzbot
> wrote:
> >
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:a38523185b40 erge tag 'libnvdimm-fixes-4.19-rc6' of git://..
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=178f63fa40
> > kernel config: https://syzkaller.appspot.com/x/.config?x=dfb440e26f0a6f6f
> > dashboard link: https://syzkaller.appspot.com/bug?extid=695726bc473f9c36a4b6
> > compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> >
> > Unfortunately, I don't have any reproducer for this crash yet.
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+695726bc473f9c36a...@syzkaller.appspotmail.com
> >
> > Process accounting resumed
> >
> > ==
> > WARNING: possible circular locking dependency detected
> > 4.19.0-rc5+ #32 Not tainted
> > --
> > overlayfs: option "workdir=./file1\" is useless in a non-upper mount, ignore
> > syz-executor1/7265 is trying to acquire lock:
> > fec87ddb (&ovl_i_mutex_key[depth]){+.+.}, at: inode_lock
> > include/linux/fs.h:738 [inline]
> > fec87ddb (&ovl_i_mutex_key[depth]){+.+.}, at:
> > ovl_write_iter+0x151/0xb00 fs/overlayfs/file.c:231
> >
> > but task is already holding lock:
> > 998db2f0 (&acct->lock#2){+.+.}, at: acct_get kernel/acct.c:161
> > [inline]
> > 998db2f0 (&acct->lock#2){+.+.}, at: slow_acct_process
> > kernel/acct.c:577 [inline]
> > 998db2f0 (&acct->lock#2){+.+.}, at: acct_process+0x48b/0x875
> > kernel/acct.c:605
> >
> > which lock already depends on the new lock.
> >
> >
> > the existing dependency chain (in reverse order) is:
> >
> > -> #2 (&acct->lock#2){+.+.}:
> > overlayfs: at least 2 lowerdir are needed while upperdir nonexistent
> > __mutex_lock_common kernel/locking/mutex.c:925 [inline]
> > __mutex_lock+0x166/0x1700 kernel/locking/mutex.c:1072
> > kobject: 'kvm' (bb4f2ec2): kobject_uevent_env
> > mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1087
> > acct_pin_kill+0x26/0x100 kernel/acct.c:173
> > pin_kill+0x29d/0xab0 fs/fs_pin.c:50
> > kobject: 'kvm' (bb4f2ec2): fill_kobj_path: path
> > = '/devices/virtual/misc/kvm'
> > acct_on+0x64a/0x8c0 kernel/acct.c:254
> > __do_sys_acct kernel/acct.c:286 [inline]
> > __se_sys_acct kernel/acct.c:273 [inline]
> > __x64_sys_acct+0xc2/0x1f0 kernel/acct.c:273
> > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >
> > -> #1 (sb_writers#3){.+.+}:
> > percpu_down_read_preempt_disable include/linux/percpu-rwsem.h:36
> > [inline]
> > percpu_down_read include/linux/percpu-rwsem.h:59 [inline]
> > __sb_start_write+0x214/0x370 fs/super.c:1387
> > sb_start_write include/linux/fs.h:1566 [inline]
> > mnt_want_write+0x3f/0xc0 fs/namespace.c:360
> > ovl_want_write+0x76/0xa0 fs/overlayfs/util.c:24
> > ovl_setattr+0x10b/0xaf0 fs/overlayfs/inode.c:30
> > notify_change+0xbde/0x1110 fs/attr.c:334
> > do_truncate+0x1bd/0x2d0 fs/open.c:63
> > handle_truncate fs/namei.c:3008 [inline]
> > do_last fs/namei.c:3424 [inline]
> > path_openat+0x3762/0x5160 fs/namei.c:3534
> > do_filp_open+0x255/0x380 fs/namei.c:3564
> > kobject: 'loop4' (88f052bf): kobject_uevent_env
> > do_sys_open+0x568/0x700 fs/open.c:1063
> > ksys_open include/linux/syscalls.h:1276 [inline]
> > __do_sys_creat fs/open.c:1121 [inline]
> > __se_sys_creat fs/open.c:1119 [inline]
> > __x64_sys_creat+0x61/0x80 fs/open.c:1119
> > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> > kobject: 'loop4' (88f052bf): fill_kobj_path: path
> > = '/devices/virtual/block/loop4'
> > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >
> > -> #0
> > kobject: 'kvm' (bb4f2ec2): kobject_uevent_env
> > (&ovl_i_mutex_key[depth]){+.+.}:
> > lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3900
> > down_write+0x8a/0x130 kernel/locking/rwsem.c:70
> > inode_lock include/linux/fs.h:738 [inline]
> > ovl_write_iter+0x151/0xb00 fs/overlayfs/file.c:231
> > kobject: 'kvm' (bb4f2ec2): fill_kobj_path: path
> > = '/devices/virtual/misc/kvm'
> > call_write_iter include/linux/fs.h:1808 [inline]
> > new_sync_write fs/read_write.c:474 [inline]
> > __vfs_write+0x6b8/0x9f0 fs/read_write.c:487
> > __kernel_write+0x10c/0x370 fs/read_write.c:506
> > do_acct_process+0x1144/0x1660 kernel/acct.c:520
> > slow_acct_process kernel/acct.c:579 [inline]
> > acct_process+0x6b1/0x875 kernel/acct.c:605
> > do_exit+0x1aaf/0x2610 kernel/exit.c:85
[PATCH V3 2/13] KVM/MMU: Add tlb flush with range helper function
This patch is to add wrapper functions for tlb_remote_flush_with_range
callback.
Signed-off-by: Lan Tianyu
---
Change since V2:
Fix comment in the kvm_flush_remote_tlbs_with_range()
---
arch/x86/kvm/mmu.c | 48
1 file changed, 48 insertions(+)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index c67f09086378..18cac661a41a 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -253,6 +253,54 @@ static void mmu_spte_set(u64 *sptep, u64 spte);
static union kvm_mmu_page_role
kvm_mmu_calc_root_page_role(struct kvm_vcpu *vcpu);
+
+static inline bool kvm_available_flush_tlb_with_range(void)
+{
+ return kvm_x86_ops->tlb_remote_flush_with_range;
+}
+
+static void kvm_flush_remote_tlbs_with_range(struct kvm *kvm,
+ struct kvm_tlb_range *range)
+{
+ int ret = -ENOTSUPP;
+
+ if (range && kvm_x86_ops->tlb_remote_flush_with_range) {
+ /*
+* Read tlbs_dirty before flushing tlbs in order
+* to track dirty tlbs during flushing.
+*/
+ long dirty_count = smp_load_acquire(&kvm->tlbs_dirty);
+
+ ret = kvm_x86_ops->tlb_remote_flush_with_range(kvm, range);
+ cmpxchg(&kvm->tlbs_dirty, dirty_count, 0);
+ }
+
+ if (ret)
+ kvm_flush_remote_tlbs(kvm);
+}
+
+static void kvm_flush_remote_tlbs_with_list(struct kvm *kvm,
+ struct list_head *flush_list)
+{
+ struct kvm_tlb_range range;
+
+ range.flush_list = flush_list;
+
+ kvm_flush_remote_tlbs_with_range(kvm, &range);
+}
+
+static void kvm_flush_remote_tlbs_with_address(struct kvm *kvm,
+ u64 start_gfn, u64 pages)
+{
+ struct kvm_tlb_range range;
+
+ range.start_gfn = start_gfn;
+ range.pages = pages;
+ range.flush_list = NULL;
+
+ kvm_flush_remote_tlbs_with_range(kvm, &range);
+}
+
void kvm_mmu_set_mmio_spte_mask(u64 mmio_mask, u64 mmio_value)
{
BUG_ON((mmio_mask & mmio_value) != mmio_value);
--
2.14.4
[PATCH V3 4/13] KVM/MMU: Flush tlb directly in the kvm_handle_hva_range()
This patch is to flush tlb directly in the kvm_handle_hva_range()
when range flush is available.
Signed-off-by: Lan Tianyu
---
arch/x86/kvm/mmu.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index d10d8423e8d6..877edae0401f 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1888,6 +1888,13 @@ static int kvm_handle_hva_range(struct kvm *kvm,
&iterator)
ret |= handler(kvm, iterator.rmap, memslot,
iterator.gfn, iterator.level,
data);
+
+ if (ret && kvm_available_flush_tlb_with_range()) {
+ kvm_flush_remote_tlbs_with_address(kvm,
+ gfn_start,
+ gfn_end - gfn_start);
+ ret = 0;
+ }
}
}
--
2.14.4
[PATCH V3 7/13] KVM: Add flush_link and parent_pte in the struct kvm_mmu_page
PV EPT tlb flush function will accept a list of flush ranges and
use struct kvm_mmu_page as the list entry.
Signed-off-by: Lan Tianyu
---
arch/x86/include/asm/kvm_host.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index a6b77978502e..c96bc4cbe4b7 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -279,6 +279,7 @@ struct kvm_rmap_head {
struct kvm_mmu_page {
struct list_head link;
+ struct list_head flush_link;
struct hlist_node hash_link;
/*
--
2.14.4
[PATCH V3 13/13] KVM/VMX: Add hv tlb range flush support
This patch is to register tlb_remote_flush_with_range callback with
hv tlb range flush interface.
Signed-off-by: Lan Tianyu
---
Change since v1:
Pass flush range with new hyper-v tlb flush struct rather
than KVM tlb flush struct.
---
arch/x86/kvm/vmx.c | 58 +++---
1 file changed, 51 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 2869c3e78168..70e1f916bfc9 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1555,7 +1555,43 @@ static void check_ept_pointer_match(struct kvm *kvm)
to_kvm_vmx(kvm)->ept_pointers_match = EPT_POINTERS_MATCH;
}
-static int vmx_hv_remote_flush_tlb(struct kvm *kvm)
+int kvm_parse_flush_list_func(union hv_gpa_page_range gpa_list[],
+ int offset, struct list_head *flush_list,
+ int (*fill_flush_list)(union hv_gpa_page_range gpa_list[],
+ int offset, u64 start_gfn, u64 end_gfn))
+{
+ struct kvm_mmu_page *sp;
+
+ list_for_each_entry(sp, flush_list,
+ flush_link) {
+ offset = fill_flush_list(gpa_list, offset,
+ sp->gfn, KVM_PAGES_PER_HPAGE(sp->role.level));
+ }
+
+ return offset;
+}
+
+static inline int __hv_remote_flush_tlb_with_range(struct kvm *kvm,
+ struct kvm_vcpu *vcpu, struct kvm_tlb_range *range)
+{
+ u64 ept_pointer = to_vmx(vcpu)->ept_pointer;
+ struct hyperv_tlb_range flush_range;
+
+ if (range) {
+ flush_range.start_gfn = range->start_gfn;
+ flush_range.pages = range->pages;
+ flush_range.flush_list = range->flush_list;
+ flush_range.parse_flush_list_func = kvm_parse_flush_list_func;
+
+ return hyperv_flush_guest_mapping_range(ept_pointer,
+ &flush_range);
+ } else {
+ return hyperv_flush_guest_mapping(ept_pointer);
+ }
+}
+
+static int hv_remote_flush_tlb_with_range(struct kvm *kvm,
+ struct kvm_tlb_range *range)
{
struct kvm_vcpu *vcpu;
int ret = -ENOTSUPP, i;
@@ -1567,16 +1603,21 @@ static int vmx_hv_remote_flush_tlb(struct kvm *kvm)
if (to_kvm_vmx(kvm)->ept_pointers_match != EPT_POINTERS_MATCH) {
kvm_for_each_vcpu(i, vcpu, kvm)
- ret |= hyperv_flush_guest_mapping(
- to_vmx(kvm_get_vcpu(kvm, i))->ept_pointer);
+ ret |= __hv_remote_flush_tlb_with_range(
+ kvm, vcpu, range);
} else {
- ret = hyperv_flush_guest_mapping(
- to_vmx(kvm_get_vcpu(kvm, 0))->ept_pointer);
+ ret = __hv_remote_flush_tlb_with_range(kvm,
+ kvm_get_vcpu(kvm, 0), range);
}
spin_unlock(&to_kvm_vmx(kvm)->ept_pointer_lock);
return ret;
}
+
+static int hv_remote_flush_tlb(struct kvm *kvm)
+{
+ return hv_remote_flush_tlb_with_range(kvm, NULL);
+}
#else /* !IS_ENABLED(CONFIG_HYPERV) */
static inline void evmcs_write64(unsigned long field, u64 value) {}
static inline void evmcs_write32(unsigned long field, u32 value) {}
@@ -7918,8 +7959,11 @@ static __init int hardware_setup(void)
#if IS_ENABLED(CONFIG_HYPERV)
if (ms_hyperv.nested_features & HV_X64_NESTED_GUEST_MAPPING_FLUSH
- && enable_ept)
- kvm_x86_ops->tlb_remote_flush = vmx_hv_remote_flush_tlb;
+ && enable_ept) {
+ kvm_x86_ops->tlb_remote_flush = hv_remote_flush_tlb;
+ kvm_x86_ops->tlb_remote_flush_with_range =
+ hv_remote_flush_tlb_with_range;
+ }
#endif
if (!cpu_has_vmx_ple()) {
--
2.14.4
[PATCH V3 8/13] KVM: Add spte's point in the struct kvm_mmu_page
It's necessary to check whether mmu page is last or large page when add
mmu page into flush list. "spte" is needed for such check and so add
spte point in the struct kvm_mmu_page.
Signed-off-by: Lan Tianyu
---
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/kvm/mmu.c | 5 +
arch/x86/kvm/paging_tmpl.h | 2 ++
3 files changed, 8 insertions(+)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index c96bc4cbe4b7..d42d96e637b5 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -296,6 +296,7 @@ struct kvm_mmu_page {
int root_count; /* Currently serving as active root */
unsigned int unsync_children;
struct kvm_rmap_head parent_ptes; /* rmap pointers to parent sptes */
+ u64 *sptep;
/* The page is obsolete if mmu_valid_gen != kvm->arch.mmu_valid_gen. */
unsigned long mmu_valid_gen;
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 7c508c4bd204..a1cbbc852271 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -3162,6 +3162,7 @@ static int __direct_map(struct kvm_vcpu *vcpu, int write,
int map_writable,
pseudo_gfn = base_addr >> PAGE_SHIFT;
sp = kvm_mmu_get_page(vcpu, pseudo_gfn, iterator.addr,
iterator.level - 1, 1, ACC_ALL);
+ sp->sptep = iterator.sptep;
link_shadow_page(vcpu, iterator.sptep, sp);
}
@@ -3599,6 +3600,7 @@ static int mmu_alloc_direct_roots(struct kvm_vcpu *vcpu)
sp = kvm_mmu_get_page(vcpu, 0, 0,
vcpu->arch.mmu.shadow_root_level, 1, ACC_ALL);
++sp->root_count;
+ sp->sptep = NULL;
spin_unlock(&vcpu->kvm->mmu_lock);
vcpu->arch.mmu.root_hpa = __pa(sp->spt);
} else if (vcpu->arch.mmu.shadow_root_level == PT32E_ROOT_LEVEL) {
@@ -3615,6 +3617,7 @@ static int mmu_alloc_direct_roots(struct kvm_vcpu *vcpu)
i << 30, PT32_ROOT_LEVEL, 1, ACC_ALL);
root = __pa(sp->spt);
++sp->root_count;
+ sp->sptep = NULL;
spin_unlock(&vcpu->kvm->mmu_lock);
vcpu->arch.mmu.pae_root[i] = root | PT_PRESENT_MASK;
}
@@ -3655,6 +3658,7 @@ static int mmu_alloc_shadow_roots(struct kvm_vcpu *vcpu)
vcpu->arch.mmu.shadow_root_level, 0, ACC_ALL);
root = __pa(sp->spt);
++sp->root_count;
+ sp->sptep = NULL;
spin_unlock(&vcpu->kvm->mmu_lock);
vcpu->arch.mmu.root_hpa = root;
return 0;
@@ -3692,6 +3696,7 @@ static int mmu_alloc_shadow_roots(struct kvm_vcpu *vcpu)
0, ACC_ALL);
root = __pa(sp->spt);
++sp->root_count;
+ sp->sptep = NULL;
spin_unlock(&vcpu->kvm->mmu_lock);
vcpu->arch.mmu.pae_root[i] = root | pm_mask;
diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
index 708a5e44861a..5cbaf7c4a729 100644
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -632,6 +632,7 @@ static int FNAME(fetch)(struct kvm_vcpu *vcpu, gva_t addr,
table_gfn = gw->table_gfn[it.level - 2];
sp = kvm_mmu_get_page(vcpu, table_gfn, addr, it.level-1,
false, access);
+ sp->sptep = it.sptep;
}
/*
@@ -662,6 +663,7 @@ static int FNAME(fetch)(struct kvm_vcpu *vcpu, gva_t addr,
sp = kvm_mmu_get_page(vcpu, direct_gfn, addr, it.level-1,
true, direct_access);
+ sp->sptep = it.sptep;
link_shadow_page(vcpu, it.sptep, sp);
}
--
2.14.4
[PATCH V3 11/13] x86/Hyper-v: Add trace in the hyperv_nested_flush_guest_mapping_range()
This patch is to trace log in the hyperv_nested_flush_
guest_mapping_range().
Signed-off-by: Lan Tianyu
---
arch/x86/hyperv/nested.c| 1 +
arch/x86/include/asm/trace/hyperv.h | 14 ++
2 files changed, 15 insertions(+)
diff --git a/arch/x86/hyperv/nested.c b/arch/x86/hyperv/nested.c
index a6fdfec63c7d..4850c74508f3 100644
--- a/arch/x86/hyperv/nested.c
+++ b/arch/x86/hyperv/nested.c
@@ -135,6 +135,7 @@ int hyperv_flush_guest_mapping_range(u64 as, struct
hyperv_tlb_range *range)
else
ret = status;
fault:
+ trace_hyperv_nested_flush_guest_mapping_range(as, ret);
return ret;
}
EXPORT_SYMBOL_GPL(hyperv_flush_guest_mapping_range);
diff --git a/arch/x86/include/asm/trace/hyperv.h
b/arch/x86/include/asm/trace/hyperv.h
index 2e6245a023ef..ace464f09681 100644
--- a/arch/x86/include/asm/trace/hyperv.h
+++ b/arch/x86/include/asm/trace/hyperv.h
@@ -42,6 +42,20 @@ TRACE_EVENT(hyperv_nested_flush_guest_mapping,
TP_printk("address space %llx ret %d", __entry->as, __entry->ret)
);
+TRACE_EVENT(hyperv_nested_flush_guest_mapping_range,
+ TP_PROTO(u64 as, int ret),
+ TP_ARGS(as, ret),
+
+ TP_STRUCT__entry(
+ __field(u64, as)
+ __field(int, ret)
+ ),
+ TP_fast_assign(__entry->as = as;
+ __entry->ret = ret;
+ ),
+ TP_printk("address space %llx ret %d", __entry->as, __entry->ret)
+ );
+
TRACE_EVENT(hyperv_send_ipi_mask,
TP_PROTO(const struct cpumask *cpus,
int vector),
--
2.14.4
[PATCH V3 9/13] KVM/MMU: Replace tlb flush function with range list flush function
This patch is to use range list flush function in the
mmu_sync_children(), kvm_mmu_commit_zap_page() and
FNAME(sync_page)().
Signed-off-by: Lan Tianyu
---
arch/x86/kvm/mmu.c | 26 +++---
arch/x86/kvm/paging_tmpl.h | 5 -
2 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index a1cbbc852271..5f3a69425142 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1092,6 +1092,13 @@ static void update_gfn_disallow_lpage_count(struct
kvm_memory_slot *slot,
}
}
+static void kvm_mmu_queue_flush_request(struct kvm_mmu_page *sp,
+ struct list_head *flush_list)
+{
+ if (sp->sptep && is_last_spte(*sp->sptep, sp->role.level))
+ list_add(&sp->flush_link, flush_list);
+}
+
void kvm_mmu_gfn_disallow_lpage(struct kvm_memory_slot *slot, gfn_t gfn)
{
update_gfn_disallow_lpage_count(slot, gfn, 1);
@@ -2369,12 +2376,16 @@ static void mmu_sync_children(struct kvm_vcpu *vcpu,
while (mmu_unsync_walk(parent, &pages)) {
bool protected = false;
+ LIST_HEAD(flush_list);
- for_each_sp(pages, sp, parents, i)
+ for_each_sp(pages, sp, parents, i) {
protected |= rmap_write_protect(vcpu, sp->gfn);
+ kvm_mmu_queue_flush_request(sp, &flush_list);
+ }
if (protected) {
- kvm_flush_remote_tlbs(vcpu->kvm);
+ kvm_flush_remote_tlbs_with_list(vcpu->kvm,
+ &flush_list);
flush = false;
}
@@ -2710,6 +2721,7 @@ static void kvm_mmu_commit_zap_page(struct kvm *kvm,
struct list_head *invalid_list)
{
struct kvm_mmu_page *sp, *nsp;
+ LIST_HEAD(flush_list);
if (list_empty(invalid_list))
return;
@@ -2723,7 +2735,15 @@ static void kvm_mmu_commit_zap_page(struct kvm *kvm,
* In addition, kvm_flush_remote_tlbs waits for all vcpus to exit
* guest mode and/or lockless shadow page table walks.
*/
- kvm_flush_remote_tlbs(kvm);
+ if (kvm_available_flush_tlb_with_range()) {
+ list_for_each_entry(sp, invalid_list, link)
+ kvm_mmu_queue_flush_request(sp, &flush_list);
+
+ if (!list_empty(&flush_list))
+ kvm_flush_remote_tlbs_with_list(kvm, &flush_list);
+ } else {
+ kvm_flush_remote_tlbs(kvm);
+ }
list_for_each_entry_safe(sp, nsp, invalid_list, link) {
WARN_ON(!sp->role.invalid || sp->root_count);
diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
index 5cbaf7c4a729..a5f967e81429 100644
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -972,6 +972,7 @@ static int FNAME(sync_page)(struct kvm_vcpu *vcpu, struct
kvm_mmu_page *sp)
bool host_writable;
gpa_t first_pte_gpa;
int set_spte_ret = 0;
+ LIST_HEAD(flush_list);
/* direct kvm_mmu_page can not be unsync. */
BUG_ON(sp->role.direct);
@@ -1032,10 +1033,12 @@ static int FNAME(sync_page)(struct kvm_vcpu *vcpu,
struct kvm_mmu_page *sp)
pte_access, PT_PAGE_TABLE_LEVEL,
gfn, spte_to_pfn(sp->spt[i]),
true, false, host_writable);
+ if (set_spte_ret && kvm_available_flush_tlb_with_range())
+ kvm_mmu_queue_flush_request(sp, &flush_list);
}
if (set_spte_ret & SET_SPTE_NEED_REMOTE_TLB_FLUSH)
- kvm_flush_remote_tlbs(vcpu->kvm);
+ kvm_flush_remote_tlbs_with_list(vcpu->kvm, &flush_list);
return nr_present;
}
--
2.14.4
[PATCH V3 12/13] KVM/VMX: Change hv flush logic when ept tables are mismatched.
If ept table pointers are mismatched, flushing tlb for each vcpus via
hv flush interface still helps to reduce vmexits which are triggered
by IPI and INEPT emulation.
Signed-off-by: Lan Tianyu
---
arch/x86/kvm/vmx.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 533a327372c8..2869c3e78168 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1557,7 +1557,8 @@ static void check_ept_pointer_match(struct kvm *kvm)
static int vmx_hv_remote_flush_tlb(struct kvm *kvm)
{
- int ret;
+ struct kvm_vcpu *vcpu;
+ int ret = -ENOTSUPP, i;
spin_lock(&to_kvm_vmx(kvm)->ept_pointer_lock);
@@ -1565,14 +1566,14 @@ static int vmx_hv_remote_flush_tlb(struct kvm *kvm)
check_ept_pointer_match(kvm);
if (to_kvm_vmx(kvm)->ept_pointers_match != EPT_POINTERS_MATCH) {
- ret = -ENOTSUPP;
- goto out;
+ kvm_for_each_vcpu(i, vcpu, kvm)
+ ret |= hyperv_flush_guest_mapping(
+ to_vmx(kvm_get_vcpu(kvm, i))->ept_pointer);
+ } else {
+ ret = hyperv_flush_guest_mapping(
+ to_vmx(kvm_get_vcpu(kvm, 0))->ept_pointer);
}
- ret = hyperv_flush_guest_mapping(
- to_vmx(kvm_get_vcpu(kvm, 0))->ept_pointer);
-
-out:
spin_unlock(&to_kvm_vmx(kvm)->ept_pointer_lock);
return ret;
}
--
2.14.4
[PATCH V3 10/13] x86/hyper-v: Add HvFlushGuestAddressList hypercall support
Hyper-V provides HvFlushGuestAddressList() hypercall to flush EPT tlb
with specified ranges. This patch is to add the hypercall support.
Signed-off-by: Lan Tianyu
---
Change since v2:
Fix some coding style issues
- Move HV_MAX_FLUSH_PAGES and HV_MAX_FLUSH_REP_COUNT to
hyperv-tlfs.h.
- Calculate HV_MAX_FLUSH_REP_COUNT in the macro definition
- Use HV_MAX_FLUSH_REP_COUNT to define length of gpa_list in
struct hv_guest_mapping_flush_list.
Change since v1:
Add hyperv tlb flush struct to avoid use kvm tlb flush struct
in the hyperv file.
---
arch/x86/hyperv/nested.c | 84 ++
arch/x86/include/asm/hyperv-tlfs.h | 32 +++
arch/x86/include/asm/mshyperv.h| 16
3 files changed, 132 insertions(+)
diff --git a/arch/x86/hyperv/nested.c b/arch/x86/hyperv/nested.c
index b8e60cc50461..a6fdfec63c7d 100644
--- a/arch/x86/hyperv/nested.c
+++ b/arch/x86/hyperv/nested.c
@@ -7,6 +7,7 @@
*
* Author : Lan Tianyu
*/
+#define pr_fmt(fmt) "Hyper-V: " fmt
#include
@@ -54,3 +55,86 @@ int hyperv_flush_guest_mapping(u64 as)
return ret;
}
EXPORT_SYMBOL_GPL(hyperv_flush_guest_mapping);
+
+static int fill_flush_list(union hv_gpa_page_range gpa_list[],
+ int offset, u64 start_gfn, u64 pages)
+{
+ int gpa_n = offset;
+ u64 cur = start_gfn;
+ u64 additional_pages;
+
+ do {
+ /*
+* If flush requests exceed max flush count, go back to
+* flush tlbs without range.
+*/
+ if (gpa_n >= HV_MAX_FLUSH_REP_COUNT)
+ return -ENOSPC;
+
+ additional_pages = min_t(u64, pages, HV_MAX_FLUSH_PAGES) - 1;
+
+ gpa_list[gpa_n].page.additional_pages = additional_pages;
+ gpa_list[gpa_n].page.largepage = false;
+ gpa_list[gpa_n].page.basepfn = cur;
+
+ pages -= additional_pages + 1;
+ cur += additional_pages + 1;
+ gpa_n++;
+ } while (pages > 0);
+
+ return gpa_n;
+}
+
+int hyperv_flush_guest_mapping_range(u64 as, struct hyperv_tlb_range *range)
+{
+ struct hv_guest_mapping_flush_list **flush_pcpu;
+ struct hv_guest_mapping_flush_list *flush;
+ u64 status = 0;
+ unsigned long flags;
+ int ret = -ENOTSUPP;
+ int gpa_n = 0;
+
+ if (!hv_hypercall_pg)
+ goto fault;
+
+ local_irq_save(flags);
+
+ flush_pcpu = (struct hv_guest_mapping_flush_list **)
+ this_cpu_ptr(hyperv_pcpu_input_arg);
+
+ flush = *flush_pcpu;
+ if (unlikely(!flush)) {
+ local_irq_restore(flags);
+ goto fault;
+ }
+
+ flush->address_space = as;
+ flush->flags = 0;
+
+ if (!range->flush_list)
+ gpa_n = fill_flush_list(flush->gpa_list, gpa_n,
+ range->start_gfn, range->pages);
+ else if (range->parse_flush_list_func)
+ gpa_n = range->parse_flush_list_func(flush->gpa_list, gpa_n,
+ range->flush_list, fill_flush_list);
+ else
+ gpa_n = -1;
+
+ if (gpa_n < 0) {
+ local_irq_restore(flags);
+ goto fault;
+ }
+
+ status = hv_do_rep_hypercall(HVCALL_FLUSH_GUEST_PHYSICAL_ADDRESS_LIST,
+gpa_n, 0, flush, NULL);
+
+ local_irq_restore(flags);
+
+ if (!(status & HV_HYPERCALL_RESULT_MASK))
+ ret = 0;
+ else
+ ret = status;
+fault:
+ return ret;
+}
+EXPORT_SYMBOL_GPL(hyperv_flush_guest_mapping_range);
diff --git a/arch/x86/include/asm/hyperv-tlfs.h
b/arch/x86/include/asm/hyperv-tlfs.h
index e977b6b3a538..e38743328dfc 100644
--- a/arch/x86/include/asm/hyperv-tlfs.h
+++ b/arch/x86/include/asm/hyperv-tlfs.h
@@ -10,6 +10,7 @@
#define _ASM_X86_HYPERV_TLFS_H
#include
+#include
/*
* The below CPUID leaves are present if VersionAndFeatures.HypervisorPresent
@@ -353,6 +354,7 @@ struct hv_tsc_emulation_status {
#define HVCALL_POST_MESSAGE0x005c
#define HVCALL_SIGNAL_EVENT0x005d
#define HVCALL_FLUSH_GUEST_PHYSICAL_ADDRESS_SPACE 0x00af
+#define HVCALL_FLUSH_GUEST_PHYSICAL_ADDRESS_LIST 0x00b0
#define HV_X64_MSR_VP_ASSIST_PAGE_ENABLE 0x0001
#define HV_X64_MSR_VP_ASSIST_PAGE_ADDRESS_SHIFT12
@@ -750,6 +752,36 @@ struct hv_guest_mapping_flush {
u64 flags;
};
+/*
+ * HV_MAX_FLUSH_PAGES = "additional_pages" + 1. It's limited
+ * by the bitwidth of "additional_pages" in union hv_gpa_page_range.
+ */
+#define HV_MAX_FLUSH_PAGES (2048)
+
+/* HvFlushGuestPhysicalAddressList hypercall */
+union hv_gpa_page_range {
+ u64 address_space;
+ struct {
+ u64 additional_pages:11;
+ u64 largepage:1;
+ u64 basepfn:52;
+ } page;
+
[PATCH V3 3/13] KVM: Replace old tlb flush function with new one to flush a specified range.
This patch is to replace kvm_flush_remote_tlbs() with kvm_flush_
remote_tlbs_with_address() in some functions without logic change.
Signed-off-by: Lan Tianyu
---
arch/x86/kvm/mmu.c | 33 ++---
arch/x86/kvm/paging_tmpl.h | 3 ++-
2 files changed, 24 insertions(+), 12 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 18cac661a41a..d10d8423e8d6 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1482,8 +1482,12 @@ static bool __drop_large_spte(struct kvm *kvm, u64
*sptep)
static void drop_large_spte(struct kvm_vcpu *vcpu, u64 *sptep)
{
- if (__drop_large_spte(vcpu->kvm, sptep))
- kvm_flush_remote_tlbs(vcpu->kvm);
+ if (__drop_large_spte(vcpu->kvm, sptep)) {
+ struct kvm_mmu_page *sp = page_header(__pa(sptep));
+
+ kvm_flush_remote_tlbs_with_address(vcpu->kvm, sp->gfn,
+ KVM_PAGES_PER_HPAGE(sp->role.level));
+ }
}
/*
@@ -1770,7 +1774,7 @@ static int kvm_set_pte_rmapp(struct kvm *kvm, struct
kvm_rmap_head *rmap_head,
}
if (need_flush)
- kvm_flush_remote_tlbs(kvm);
+ kvm_flush_remote_tlbs_with_address(kvm, gfn, 1);
return 0;
}
@@ -1951,7 +1955,8 @@ static void rmap_recycle(struct kvm_vcpu *vcpu, u64
*spte, gfn_t gfn)
rmap_head = gfn_to_rmap(vcpu->kvm, gfn, sp);
kvm_unmap_rmapp(vcpu->kvm, rmap_head, NULL, gfn, sp->role.level, 0);
- kvm_flush_remote_tlbs(vcpu->kvm);
+ kvm_flush_remote_tlbs_with_address(vcpu->kvm, sp->gfn,
+ KVM_PAGES_PER_HPAGE(sp->role.level));
}
int kvm_age_hva(struct kvm *kvm, unsigned long start, unsigned long end)
@@ -2467,7 +2472,7 @@ static struct kvm_mmu_page *kvm_mmu_get_page(struct
kvm_vcpu *vcpu,
account_shadowed(vcpu->kvm, sp);
if (level == PT_PAGE_TABLE_LEVEL &&
rmap_write_protect(vcpu, gfn))
- kvm_flush_remote_tlbs(vcpu->kvm);
+ kvm_flush_remote_tlbs_with_address(vcpu->kvm, gfn, 1);
if (level > PT_PAGE_TABLE_LEVEL && need_sync)
flush |= kvm_sync_pages(vcpu, gfn, &invalid_list);
@@ -2587,7 +2592,7 @@ static void validate_direct_spte(struct kvm_vcpu *vcpu,
u64 *sptep,
return;
drop_parent_pte(child, sptep);
- kvm_flush_remote_tlbs(vcpu->kvm);
+ kvm_flush_remote_tlbs_with_address(vcpu->kvm, child->gfn, 1);
}
}
@@ -3011,8 +3016,10 @@ static int mmu_set_spte(struct kvm_vcpu *vcpu, u64
*sptep, unsigned pte_access,
ret = RET_PF_EMULATE;
kvm_make_request(KVM_REQ_TLB_FLUSH, vcpu);
}
+
if (set_spte_ret & SET_SPTE_NEED_REMOTE_TLB_FLUSH || flush)
- kvm_flush_remote_tlbs(vcpu->kvm);
+ kvm_flush_remote_tlbs_with_address(vcpu->kvm, gfn,
+ KVM_PAGES_PER_HPAGE(level));
if (unlikely(is_mmio_spte(*sptep)))
ret = RET_PF_EMULATE;
@@ -5621,7 +5628,8 @@ void kvm_mmu_slot_remove_write_access(struct kvm *kvm,
* on PT_WRITABLE_MASK anymore.
*/
if (flush)
- kvm_flush_remote_tlbs(kvm);
+ kvm_flush_remote_tlbs_with_address(kvm, memslot->base_gfn,
+ memslot->npages);
}
static bool kvm_mmu_zap_collapsible_spte(struct kvm *kvm,
@@ -5685,7 +5693,8 @@ void kvm_mmu_slot_leaf_clear_dirty(struct kvm *kvm,
* dirty_bitmap.
*/
if (flush)
- kvm_flush_remote_tlbs(kvm);
+ kvm_flush_remote_tlbs_with_address(kvm, memslot->base_gfn,
+ memslot->npages);
}
EXPORT_SYMBOL_GPL(kvm_mmu_slot_leaf_clear_dirty);
@@ -5703,7 +5712,8 @@ void kvm_mmu_slot_largepage_remove_write_access(struct
kvm *kvm,
lockdep_assert_held(&kvm->slots_lock);
if (flush)
- kvm_flush_remote_tlbs(kvm);
+ kvm_flush_remote_tlbs_with_address(kvm, memslot->base_gfn,
+ memslot->npages);
}
EXPORT_SYMBOL_GPL(kvm_mmu_slot_largepage_remove_write_access);
@@ -5720,7 +5730,8 @@ void kvm_mmu_slot_set_dirty(struct kvm *kvm,
/* see kvm_mmu_slot_leaf_clear_dirty */
if (flush)
- kvm_flush_remote_tlbs(kvm);
+ kvm_flush_remote_tlbs_with_address(kvm, memslot->base_gfn,
+ memslot->npages);
}
EXPORT_SYMBOL_GPL(kvm_mmu_slot_set_dirty);
diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
index 14ffd973df54..708a5e44861a 100644
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -893,7 +893,8 @@ static void FNAME(invlpg)(struct kvm_vcpu *vcpu, gva_t gva,
hpa_t root_hpa)
pte_gpa += (sptep - sp->spt) * sizeof(pt_element_t);
if (mmu_page_zap_pte(vcpu->kvm,
[PATCH V3 1/13] KVM: Add tlb_remote_flush_with_range callback in kvm_x86_ops
Add flush range call back in the kvm_x86_ops and platform can use it
to register its associated function. The parameter "kvm_tlb_range"
accepts a single range and flush list which contains a list of ranges.
Signed-off-by: Lan Tianyu
---
Change since v1:
Change "end_gfn" to "pages" to aviod confusion as to whether
"end_gfn" is inclusive or exlusive.
---
arch/x86/include/asm/kvm_host.h | 8
1 file changed, 8 insertions(+)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 8e90488c3d56..a6b77978502e 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -402,6 +402,12 @@ struct kvm_mmu {
u64 pdptrs[4]; /* pae */
};
+struct kvm_tlb_range {
+ u64 start_gfn;
+ u64 pages;
+ struct list_head *flush_list;
+};
+
enum pmc_type {
KVM_PMC_GP = 0,
KVM_PMC_FIXED,
@@ -991,6 +997,8 @@ struct kvm_x86_ops {
void (*tlb_flush)(struct kvm_vcpu *vcpu, bool invalidate_gpa);
int (*tlb_remote_flush)(struct kvm *kvm);
+ int (*tlb_remote_flush_with_range)(struct kvm *kvm,
+ struct kvm_tlb_range *range);
/*
* Flush any TLB entries associated with the given GVA.
--
2.14.4
[PATCH V3 5/13] KVM/MMU: Flush tlb directly in the kvm_zap_gfn_range()
Originally, flush tlb is done by slot_handle_level_range(). This patch
is to flush tlb directly in the kvm_zap_gfn_range() when range
flush is available.
Signed-off-by: Lan Tianyu
---
arch/x86/kvm/mmu.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 877edae0401f..f24101ef763e 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -5578,6 +5578,7 @@ void kvm_zap_gfn_range(struct kvm *kvm, gfn_t gfn_start,
gfn_t gfn_end)
{
struct kvm_memslots *slots;
struct kvm_memory_slot *memslot;
+ bool flush = false;
int i;
spin_lock(&kvm->mmu_lock);
@@ -5585,18 +5586,27 @@ void kvm_zap_gfn_range(struct kvm *kvm, gfn_t
gfn_start, gfn_t gfn_end)
slots = __kvm_memslots(kvm, i);
kvm_for_each_memslot(memslot, slots) {
gfn_t start, end;
+ bool flush_tlb = true;
start = max(gfn_start, memslot->base_gfn);
end = min(gfn_end, memslot->base_gfn + memslot->npages);
if (start >= end)
continue;
- slot_handle_level_range(kvm, memslot, kvm_zap_rmapp,
- PT_PAGE_TABLE_LEVEL,
PT_MAX_HUGEPAGE_LEVEL,
- start, end - 1, true);
+ if (kvm_available_flush_tlb_with_range())
+ flush_tlb = false;
+
+ flush = slot_handle_level_range(kvm, memslot,
+ kvm_zap_rmapp, PT_PAGE_TABLE_LEVEL,
+ PT_MAX_HUGEPAGE_LEVEL, start,
+ end - 1, flush_tlb);
}
}
+ if (flush && kvm_available_flush_tlb_with_range())
+ kvm_flush_remote_tlbs_with_address(kvm, gfn_start,
+ gfn_end - gfn_start + 1);
+
spin_unlock(&kvm->mmu_lock);
}
--
2.14.4
[PATCH V3 00/13] x86/KVM/Hyper-v: Add HV ept tlb range flush hypercall support in KVM
For nested memory virtualization, Hyper-v doesn't set write-protect L1 hypervisor EPT page directory and page table node to track changes while it relies on guest to tell it changes via HvFlushGuestAddressLlist hypercall. HvFlushGuestAddressLlist hypercall provides a way to flush EPT page table with ranges which are specified by L1 hypervisor. If L1 hypervisor uses INVEPT or HvFlushGuestAddressSpace hypercall to flush EPT tlb, Hyper-V will invalidate associated EPT shadow page table and sync L1's EPT table when next EPT page fault is triggered. HvFlushGuestAddressLlist hypercall helps to avoid such redundant EPT page fault and synchronization of shadow page table. Change since v2: 1) Fix comment in the kvm_flush_remote_tlbs_with_range() 2) Move HV_MAX_FLUSH_PAGES and HV_MAX_FLUSH_REP_COUNT to hyperv-tlfs.h. 3) Calculate HV_MAX_FLUSH_REP_COUNT in the macro definition 4) Use HV_MAX_FLUSH_REP_COUNT to define length of gpa_list in struct hv_guest_mapping_flush_list. Change since v1: 1) Convert "end_gfn" of struct kvm_tlb_range to "pages" in order to avoid confusion as to whether "end_gfn" is inclusive or exlusive. 2) Add hyperv tlb range struct and replace kvm tlb range struct with new struct in order to avoid using kvm struct in the hyperv code directly. Lan Tianyu (13): KVM: Add tlb_remote_flush_with_range callback in kvm_x86_ops KVM/MMU: Add tlb flush with range helper function KVM: Replace old tlb flush function with new one to flush a specified range. KVM/MMU: Flush tlb directly in the kvm_handle_hva_range() KVM/MMU: Flush tlb directly in the kvm_zap_gfn_range() KVM/MMU: Flush tlb directly in kvm_mmu_zap_collapsible_spte() KVM: Add flush_link and parent_pte in the struct kvm_mmu_page KVM: Add spte's point in the struct kvm_mmu_page KVM/MMU: Replace tlb flush function with range list flush function x86/hyper-v: Add HvFlushGuestAddressList hypercall support x86/Hyper-v: Add trace in the hyperv_nested_flush_guest_mapping_range() KVM/VMX: Change hv flush logic when ept tables are mismatched. KVM/VMX: Add hv tlb range flush support arch/x86/hyperv/nested.c| 85 + arch/x86/include/asm/hyperv-tlfs.h | 32 arch/x86/include/asm/kvm_host.h | 10 +++ arch/x86/include/asm/mshyperv.h | 16 arch/x86/include/asm/trace/hyperv.h | 14 arch/x86/kvm/mmu.c | 143 +++- arch/x86/kvm/paging_tmpl.h | 10 ++- arch/x86/kvm/vmx.c | 65 +--- 8 files changed, 345 insertions(+), 30 deletions(-) -- 2.14.4
[PATCH V3 6/13] KVM/MMU: Flush tlb directly in kvm_mmu_zap_collapsible_spte()
kvm_mmu_zap_collapsible_spte() returns flush request to the
slot_handle_leaf() and the latter does flush on demand. When
range flush is available, make kvm_mmu_zap_collapsible_spte()
to flush tlb with range directly to avoid returning range back
to slot_handle_leaf().
Signed-off-by: Lan Tianyu
---
arch/x86/kvm/mmu.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index f24101ef763e..7c508c4bd204 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -5674,7 +5674,13 @@ static bool kvm_mmu_zap_collapsible_spte(struct kvm *kvm,
!kvm_is_reserved_pfn(pfn) &&
PageTransCompoundMap(pfn_to_page(pfn))) {
drop_spte(kvm, sptep);
- need_tlb_flush = 1;
+
+ if (kvm_available_flush_tlb_with_range())
+ kvm_flush_remote_tlbs_with_address(kvm, sp->gfn,
+ KVM_PAGES_PER_HPAGE(sp->role.level));
+ else
+ need_tlb_flush = 1;
+
goto restart;
}
}
--
2.14.4
Re: possible deadlock in ovl_write_iter
On Wed, Sep 26, 2018 at 11:44 PM syzbot
wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:a38523185b40 erge tag 'libnvdimm-fixes-4.19-rc6' of git://..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=178f63fa40
> kernel config: https://syzkaller.appspot.com/x/.config?x=dfb440e26f0a6f6f
> dashboard link: https://syzkaller.appspot.com/bug?extid=695726bc473f9c36a4b6
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+695726bc473f9c36a...@syzkaller.appspotmail.com
>
> Process accounting resumed
>
> ==
> WARNING: possible circular locking dependency detected
> 4.19.0-rc5+ #32 Not tainted
> --
> overlayfs: option "workdir=./file1\" is useless in a non-upper mount, ignore
> syz-executor1/7265 is trying to acquire lock:
> fec87ddb (&ovl_i_mutex_key[depth]){+.+.}, at: inode_lock
> include/linux/fs.h:738 [inline]
> fec87ddb (&ovl_i_mutex_key[depth]){+.+.}, at:
> ovl_write_iter+0x151/0xb00 fs/overlayfs/file.c:231
>
> but task is already holding lock:
> 998db2f0 (&acct->lock#2){+.+.}, at: acct_get kernel/acct.c:161
> [inline]
> 998db2f0 (&acct->lock#2){+.+.}, at: slow_acct_process
> kernel/acct.c:577 [inline]
> 998db2f0 (&acct->lock#2){+.+.}, at: acct_process+0x48b/0x875
> kernel/acct.c:605
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
>
> -> #2 (&acct->lock#2){+.+.}:
> overlayfs: at least 2 lowerdir are needed while upperdir nonexistent
> __mutex_lock_common kernel/locking/mutex.c:925 [inline]
> __mutex_lock+0x166/0x1700 kernel/locking/mutex.c:1072
> kobject: 'kvm' (bb4f2ec2): kobject_uevent_env
> mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1087
> acct_pin_kill+0x26/0x100 kernel/acct.c:173
> pin_kill+0x29d/0xab0 fs/fs_pin.c:50
> kobject: 'kvm' (bb4f2ec2): fill_kobj_path: path
> = '/devices/virtual/misc/kvm'
> acct_on+0x64a/0x8c0 kernel/acct.c:254
> __do_sys_acct kernel/acct.c:286 [inline]
> __se_sys_acct kernel/acct.c:273 [inline]
> __x64_sys_acct+0xc2/0x1f0 kernel/acct.c:273
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> -> #1 (sb_writers#3){.+.+}:
> percpu_down_read_preempt_disable include/linux/percpu-rwsem.h:36
> [inline]
> percpu_down_read include/linux/percpu-rwsem.h:59 [inline]
> __sb_start_write+0x214/0x370 fs/super.c:1387
> sb_start_write include/linux/fs.h:1566 [inline]
> mnt_want_write+0x3f/0xc0 fs/namespace.c:360
> ovl_want_write+0x76/0xa0 fs/overlayfs/util.c:24
> ovl_setattr+0x10b/0xaf0 fs/overlayfs/inode.c:30
> notify_change+0xbde/0x1110 fs/attr.c:334
> do_truncate+0x1bd/0x2d0 fs/open.c:63
> handle_truncate fs/namei.c:3008 [inline]
> do_last fs/namei.c:3424 [inline]
> path_openat+0x3762/0x5160 fs/namei.c:3534
> do_filp_open+0x255/0x380 fs/namei.c:3564
> kobject: 'loop4' (88f052bf): kobject_uevent_env
> do_sys_open+0x568/0x700 fs/open.c:1063
> ksys_open include/linux/syscalls.h:1276 [inline]
> __do_sys_creat fs/open.c:1121 [inline]
> __se_sys_creat fs/open.c:1119 [inline]
> __x64_sys_creat+0x61/0x80 fs/open.c:1119
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> kobject: 'loop4' (88f052bf): fill_kobj_path: path
> = '/devices/virtual/block/loop4'
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> -> #0
> kobject: 'kvm' (bb4f2ec2): kobject_uevent_env
> (&ovl_i_mutex_key[depth]){+.+.}:
> lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3900
> down_write+0x8a/0x130 kernel/locking/rwsem.c:70
> inode_lock include/linux/fs.h:738 [inline]
> ovl_write_iter+0x151/0xb00 fs/overlayfs/file.c:231
> kobject: 'kvm' (bb4f2ec2): fill_kobj_path: path
> = '/devices/virtual/misc/kvm'
> call_write_iter include/linux/fs.h:1808 [inline]
> new_sync_write fs/read_write.c:474 [inline]
> __vfs_write+0x6b8/0x9f0 fs/read_write.c:487
> __kernel_write+0x10c/0x370 fs/read_write.c:506
> do_acct_process+0x1144/0x1660 kernel/acct.c:520
> slow_acct_process kernel/acct.c:579 [inline]
> acct_process+0x6b1/0x875 kernel/acct.c:605
> do_exit+0x1aaf/0x2610 kernel/exit.c:857
> do_group_exit+0x177/0x440 kernel/exit.c:970
> get_signal+0x8b0/0x1980 kernel/signal.c:2513
> do_signal+0x9c/0x21e0 arch/x86/kernel/signal.c:816
> exit_to_usermode_loop+0x2e5/0x380 arch/x86/entry/common.c:162
> prepare_exit_to_usermode arc
Re: [PATCHv4 4/6] ARM: dts: exynos: Add CD and WP pins to Odroid XU3/XU4 SD card
Hi Krzysztof, On Thu, 27 Sep 2018 at 00:36, Krzysztof Kozlowski wrote: > > On Sat, Sep 22, 2018 at 07:52:36AM +, Anand Moon wrote: > > Add the card-detect and write-protect GPIO pins for OdroidXU3/XU4 > > SD card by adding pinctrl setting for wp-gpio pin and set it to > > active low. > > > > This also removes debug messages: > > dwmmc_exynos 1222.mmc: No GPIO consumer cd found > > dwmmc_exynos 1222.mmc: No GPIO consumer wp found > > > > Suggested-by: Krzysztof Kozlowski > > Signed-off-by: Anand Moon > > --- > > Fix the commit message and squash it with cd-gpios and wp-gpio > > patches into single patch as suggested by Krzysztof. > > As Marek pointed to my Odroid XU patch, there is no point of adding > cd-gpios and wp-gpios properties. > > Adding pin configuration for wp pin is also not needed. Reset values are > working properly. However there might be meaning of adding it just in > case - if bootloader decided to touch it... > > Best regards, > Krzysztof > Do I need to send the all the patches again or just resend this as per your patch for Odroid XU. with dropping the cd-gpios and wp-gpios changes. Best Regards -Anand
[PATCH] mfd: cros_ec: Avoid unneeded internal declaration warning
Clang warns:
drivers/mfd/cros_ec_dev.c:509:40: warning: variable 'cros_ec_id' is not
needed and will not be emitted [-Wunneeded-internal-declaration]
static const struct platform_device_id cros_ec_id[] = {
^
1 warning generated.
Avoid this warning by adding it to the cros_ec_dev_driver definition
under the id_table member like all other platform drivers.
Signed-off-by: Nathan Chancellor
---
I looked at several drivers with platform_device_id defintions and I
didn't really find any where the definition wasn't then added to the
platform_driver so I'm not sure if this was just missed in commit
afbf8ec7c4f9 ("platform/chrome: cros_ec_dev - Add a platform
device ID table") or if it was an intentional omission. I'm not super
familiar with the inner workings of platform devices.
Should this commit be undesirable, the warning can be silenced with the
__used attribute but this seemed like a more proper first commit.
drivers/mfd/cros_ec_dev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
index 999dac752bcc..8f9d6964173e 100644
--- a/drivers/mfd/cros_ec_dev.c
+++ b/drivers/mfd/cros_ec_dev.c
@@ -546,6 +546,7 @@ static struct platform_driver cros_ec_dev_driver = {
.name = DRV_NAME,
.pm = &cros_ec_dev_pm_ops,
},
+ .id_table = cros_ec_id,
.probe = ec_device_probe,
.remove = ec_device_remove,
.shutdown = ec_device_shutdown,
--
2.19.0
Re: [PATCH v2 1/2] ARM: dt-bindings: Add vendor prefix for Facebook
On Thu, 27 Sep 2018 at 03:01, Rob Herring wrote: > > On Wed, 19 Sep 2018 09:47:10 -0700, Vijay Khemka wrote: > > Initial introduction of Facebook TiogaPass family equipped with > > Aspeed 2500 BMC SoC. TiogaPass is a x86 server development kit > > with a ASPEED ast2500 BMC manufactured by Facebook. > > > > This adds an entry of Facebook in Documentation for vendor prefix > > > > Signed-off-by: Vijay Khemka > > --- > > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > > 1 file changed, 1 insertion(+) > > > > Reviewed-by: Rob Herring Rob, can you take this through the dt tree? I've already merged Vijay's device tree through the arm soc tree, and don't plan on sending another pull req for 4.20 at this stage. Cheers, Joel
Re: [PATCH i2c-next v3 2/3] i2c: aspeed: Add 'aspeed,timeout' DT property reading code
On Thu, 27 Sep 2018 at 01:58, Jae Hyun Yoo wrote:
>
> This commit adds reading code of the 'aspeed,timeout' DT property
> to set 'timeout' value in adapter configuration. This value still
> case be configured through an I2C_TIMEOUT ioctl on cdev too.
>
> Signed-off-by: Jae Hyun Yoo
> ---
> drivers/i2c/busses/i2c-aspeed.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c
> index 8dc9161ced38..0d934ce0c028 100644
> --- a/drivers/i2c/busses/i2c-aspeed.c
> +++ b/drivers/i2c/busses/i2c-aspeed.c
> @@ -115,6 +115,9 @@
> /* 0x18 : I2CD Slave Device Address Register */
> #define ASPEED_I2CD_DEV_ADDR_MASK GENMASK(6, 0)
>
> +/* Timeout */
> +#define ASPEED_I2C_BUS_TIMEOUT_US_DEFAULT (5 * 1000 * 1000)
The 5 seconds time out is way too long. On a system that doesn't have
functional i2c, this holds up boot for a long time as most i2c client
drivers try to initialise their device and fail. I realise you're not
changing the value, but we should pick a better default. 1 second?
Half a second?
> +
> enum aspeed_i2c_master_state {
> ASPEED_I2C_MASTER_INACTIVE,
> ASPEED_I2C_MASTER_START,
> @@ -885,6 +888,7 @@ static int aspeed_i2c_probe_bus(struct platform_device
> *pdev)
> struct clk *parent_clk;
> struct resource *res;
> int irq, ret;
> + u32 timeout_us;
>
> bus = devm_kzalloc(&pdev->dev, sizeof(*bus), GFP_KERNEL);
> if (!bus)
> @@ -918,6 +922,11 @@ static int aspeed_i2c_probe_bus(struct platform_device
> *pdev)
> bus->bus_frequency = 10;
> }
>
> + ret = of_property_read_u32(pdev->dev.of_node, "aspeed,timeout",
> + &timeout_us);
Can we make this binding generic? It's not specific to aspeed's
hardware. Getting the value could even part of the i2c core.
I read the previous thread with Wolfram. I think this would still fit
with what Wolfram suggested, but please forgive my jetlagged brain if
I've missed something.
Cheers,
Joel
> + if (ret)
> + timeout_us = ASPEED_I2C_BUS_TIMEOUT_US_DEFAULT;
> +
> match = of_match_node(aspeed_i2c_bus_of_table, pdev->dev.of_node);
> if (!match)
> bus->get_clk_reg_val = aspeed_i2c_24xx_get_clk_reg_val;
> @@ -930,7 +939,7 @@ static int aspeed_i2c_probe_bus(struct platform_device
> *pdev)
> init_completion(&bus->cmd_complete);
> bus->adap.owner = THIS_MODULE;
> bus->adap.retries = 0;
> - bus->adap.timeout = 5 * HZ;
> + bus->adap.timeout = usecs_to_jiffies(timeout_us);
> bus->adap.algo = &aspeed_i2c_algo;
> bus->adap.dev.parent = &pdev->dev;
> bus->adap.dev.of_node = pdev->dev.of_node;
> --
> 2.19.0
>
Re: perf segmentation fault from NULL dereference
> Please me let me know if a valid issue so we can get a fix in. If it crashes it must be a valid issue of course. But I'm not sure about your bisect. Hard to see how my patch could cause this. Sometimes bisects go wrong. You verified by just reverting the patch? First thing I would also try is to run with valgrind or ASan and see if it reports anything. -Andi
[PATCH] thermal: qoriq: add multiple sensors support
From: Yuantian Tang
There is only one sensor supported in current driver.
Multiple sensors are existing on Layscape socs. To support them,
covert this driver to support multiple sensors.
Signed-off-by: Tang Yuantian
---
drivers/thermal/qoriq_thermal.c | 117 +++
1 files changed, 70 insertions(+), 47 deletions(-)
diff --git a/drivers/thermal/qoriq_thermal.c b/drivers/thermal/qoriq_thermal.c
index c866cc1..7c1e88a 100644
--- a/drivers/thermal/qoriq_thermal.c
+++ b/drivers/thermal/qoriq_thermal.c
@@ -69,14 +69,21 @@ struct qoriq_tmu_regs {
u32 ttr3cr; /* Temperature Range 3 Control Register */
};
+struct qoriq_tmu_data;
+
/*
* Thermal zone data
*/
+struct qoriq_sensor {
+ struct thermal_zone_device *tzd;
+ struct qoriq_tmu_data *qdata;
+ int id;
+};
+
struct qoriq_tmu_data {
- struct thermal_zone_device *tz;
struct qoriq_tmu_regs __iomem *regs;
- int sensor_id;
bool little_endian;
+ struct qoriq_sensor *sensor[SITES_MAX];
};
static void tmu_write(struct qoriq_tmu_data *p, u32 val, void __iomem *addr)
@@ -97,48 +104,83 @@ static u32 tmu_read(struct qoriq_tmu_data *p, void __iomem
*addr)
static int tmu_get_temp(void *p, int *temp)
{
+ struct qoriq_sensor *qsensor = p;
+ struct qoriq_tmu_data *qdata = qsensor->qdata;
u32 val;
- struct qoriq_tmu_data *data = p;
- val = tmu_read(data, &data->regs->site[data->sensor_id].tritsr);
+ val = tmu_read(qdata, &qdata->regs->site[qsensor->id].tritsr);
*temp = (val & 0xff) * 1000;
return 0;
}
-static int qoriq_tmu_get_sensor_id(void)
+static const struct thermal_zone_of_device_ops tmu_tz_ops = {
+ .get_temp = tmu_get_temp,
+};
+
+static int qoriq_tmu_register_tmu_zone(struct platform_device *pdev)
{
- int ret, id;
+ struct qoriq_tmu_data *qdata = platform_get_drvdata(pdev);
struct of_phandle_args sensor_specs;
struct device_node *np, *sensor_np;
+ int ret, id, sites = 0;
np = of_find_node_by_name(NULL, "thermal-zones");
if (!np)
return -ENODEV;
- sensor_np = of_get_next_child(np, NULL);
- ret = of_parse_phandle_with_args(sensor_np, "thermal-sensors",
- "#thermal-sensor-cells",
- 0, &sensor_specs);
- if (ret) {
+ for_each_available_child_of_node(np, sensor_np) {
+ ret = of_parse_phandle_with_args(sensor_np, "thermal-sensors",
+ "#thermal-sensor-cells",
+ 0, &sensor_specs);
+ if (ret) {
+ of_node_put(np);
+ of_node_put(sensor_np);
+ return ret;
+ }
+
+ if (sensor_specs.args_count >= 1) {
+ id = sensor_specs.args[0];
+ WARN(sensor_specs.args_count > 1,
+ "%s: too many cells in sensor specifier
%d\n",
+ sensor_specs.np->name,
+ sensor_specs.args_count);
+ } else {
+ id = 0;
+ }
+
of_node_put(np);
of_node_put(sensor_np);
- return ret;
- }
- if (sensor_specs.args_count >= 1) {
- id = sensor_specs.args[0];
- WARN(sensor_specs.args_count > 1,
- "%s: too many cells in sensor specifier %d\n",
- sensor_specs.np->name, sensor_specs.args_count);
- } else {
- id = 0;
+ if (id > SITES_MAX)
+ return -EINVAL;
+
+ qdata->sensor[id] = devm_kzalloc(&pdev->dev,
+ sizeof(struct qoriq_sensor), GFP_KERNEL);
+ if (!qdata->sensor[id])
+ return -ENOMEM;
+
+ qdata->sensor[id]->id = id;
+ qdata->sensor[id]->qdata = qdata;
+
+ qdata->sensor[id]->tzd = devm_thermal_zone_of_sensor_register(
+ &pdev->dev, id, qdata->sensor[id], &tmu_tz_ops);
+
+ if (IS_ERR(qdata->sensor[id]->tzd)) {
+ ret = PTR_ERR(qdata->sensor[id]->tzd);
+ dev_err(&pdev->dev,
+ "Failed to register thermal zone device.\n");
+ return -ENODEV;
+ }
+
+ sites |= 0x1 << (15 - id);
}
- of_node_put(np);
- of_node_put(sensor_np);
+ /* Enable monitoring */
+ if (sites != 0)
+ tmu_write(qdata, sites | TMR_ME | TMR_ALPF, &qdata->regs->tmr);
- return id;
+ return 0;
}
static int qoriq_tmu_calibration(struct platform_device *pdev)
@@ -188,16
Re: [PATCHv2] misc: genwqe: remove duplicated include and order header files alphabetically in card_utils.c
On 2018/9/26 11:05, zhong jiang wrote: > dma-mapping.h and delay.h have included twice. It is unnecessary. Meanwhile, > Arrange header files in alphabetical sequence to improve readability. > > Signed-off-by: zhong jiang > --- > drivers/misc/genwqe/card_utils.c | 22 ++ > 1 file changed, 10 insertions(+), 12 deletions(-) > > diff --git a/drivers/misc/genwqe/card_utils.c > b/drivers/misc/genwqe/card_utils.c > index 8679e0b..994e8fa 100644 > --- a/drivers/misc/genwqe/card_utils.c > +++ b/drivers/misc/genwqe/card_utils.c > @@ -22,26 +22,24 @@ > * Miscelanous functionality used in the other GenWQE driver parts. > */ > > -#include > +#include > +#include > +#include > #include > -#include > -#include > -#include > -#include > #include > #include > -#include > -#include > -#include > -#include > +#include > #include > +#include > +#include > #include > -#include > -#include > +#include > +#include > +#include > > -#include "genwqe_driver.h" > #include "card_base.h" > #include "card_ddcb.h" > +#include "genwqe_driver.h" > > /** > * __genwqe_writeq() - Write 64-bit register Please igore the patch. I will repost . Thanks, Sincerely, zhong jiang
RE: [PATCH] PM / devfreq: remove redundant null pointer check before kfree
> kfree has taken the null pointer into account. hence it is safe > to remove the redundant null pointer check before kfree. > > Signed-off-by: zhong jiang Acked-by: MyungJoo Ham > --- > drivers/devfreq/devfreq.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c > index 4c49bb1..c37021d 100644 > --- a/drivers/devfreq/devfreq.c > +++ b/drivers/devfreq/devfreq.c > @@ -675,8 +675,7 @@ struct devfreq *devfreq_add_device(struct device *dev, > device_unregister(&devfreq->dev); > devfreq = NULL; > err_dev: > - if (devfreq) > - kfree(devfreq); > + kfree(devfreq); > err_out: > return ERR_PTR(err); > } > -- > 1.7.12.4 -- MyungJoo Ham (함명주), Ph.D. Autonomous Machine Lab., AI Center, Samsung Research. Cell: +82-10-6714-2858
Re: Leaking Path in XFS's ioctl interface(missing LSM check)
On Wed, Sep 26, 2018 at 09:23:03AM -0400, Stephen Smalley wrote: > On 09/25/2018 09:33 PM, Dave Chinner wrote: > >On Tue, Sep 25, 2018 at 08:51:50PM -0400, TongZhang wrote: > >>Hi, > >> > >>I'm bringing up this issue again to let of LSM developers know the > >>situation, and would like to know your thoughts. > >>Several weeks ago I sent an email to the security list to discuss the issue > >>where > >>XFS's ioctl interface can do things like vfs_readlink without asking LSM's > >>permission, which we think is kind of weird and this kind of operation > >>should be > >>audited by LSM. > > > >These aren't user interfaces. They are filesystem maintenance and > >extension interfaces. They are intended for low level filesystem > >utilities that require complete, unrestricted access to the > >underlying filesystem via holding CAP_SYSADMIN in the initns. > > > >i.e. they are used to perform filesystem maintenance and extension > >operations that need to be completely invisible to users from > >userspace. e.g. online file defragmentation (xfs_fsr), data > >migration (e.g. HSM products), efficient backup of data (xfsdump), > >metadata and data scrubbing, online repair, etc. > > > >IOWs, I really don't think these interfaces are something the LSMs > >should be trying to intercept or audit, because they are essentially > >internal filesystem interfaces used by trusted code and not general > >user application facing APIs. > > If they are interfaces exposed to userspace, then they should be > mediated via LSM. We only omit the LSM hook when the usage is > purely kernel-internal. /me points to the mass of diverse management ioctls across the kernel that aren't mediated by LSM hooks. > Security modules are often used to limit > even "trusted" applications to least privilege and protect them from > untrustworthy inputs, moving from binary trust notions to only > trusting them for what they must be trusted to do. CAP_SYS_ADMIN > doesn't necessarily indicate that they are trusted to override any > given MAC policy restrictions. Applications that are tightly integrated into the filesystem to extend it's functionality effectively operate in the same trust space as the kernel filesystem implementation itself. i.e. they interact with the filesystem at levels below the DAC/MAC checks that are performed on user filesystem accesses, and perform manipluation of the on-disk filesystem structure that is invisible to users accessing the filesystem. As such, there are very few trusted applications have "massive data loss" as a potential failure mode if an inappropriately configured LSM is loaded into the kernel. Breaking a HSM application's access to the filesystem unexpectedly because someone didn't set up a new security policy correctly brings a whole new level of risk to administrating sites that mix non-trivial storage solutions with LSM-based security. > Wondering why we don't perform the security_inode_readlink() call > inside of vfs_readlink() currently. The general pattern is that we > do perform security_inode_*() calls inside the other vfs_*() > helpers, so vfs_readlink() is an exception currently. Pretty sure that was done to mitigate the risk of breaking existing userspace applications using the handle interfaces to read links. Cheers, Dave. -- Dave Chinner da...@fromorbit.com
Re: [PATCH] proc: restrict kernel stack dumps to root
On Wed, Sep 26, 2018 at 6:19 PM, Jann Horn wrote:
> On Thu, Sep 13, 2018 at 4:39 PM Kees Cook wrote:
>> On Thu, Sep 13, 2018 at 4:55 AM, Jann Horn wrote:
>> > On Thu, Sep 13, 2018 at 12:28 AM Kees Cook wrote:
>> >>
>> >> On Wed, Sep 12, 2018 at 8:29 AM, Jann Horn wrote:
>> >> > +linux-api, I guess
>> >> >
>> >> > On Tue, Sep 11, 2018 at 8:39 PM Jann Horn wrote:
>> >> >>
>> >> >> Restrict the ability to inspect kernel stacks of arbitrary tasks to
>> >> >> root
>> >> >> in order to prevent a local attacker from exploiting racy stack
>> >> >> unwinding
>> >> >> to leak kernel task stack contents.
>> >> >> See the added comment for a longer rationale.
>> >> >>
>> >> >> There don't seem to be any users of this userspace API that can't
>> >> >> gracefully bail out if reading from the file fails. Therefore, I
>> >> >> believe
>> >> >> that this change is unlikely to break things.
>> >> >> In the case that this patch does end up needing a revert, the next-best
>> >> >> solution might be to fake a single-entry stack based on wchan.
>> >> >>
>> >> >> Fixes: 2ec220e27f50 ("proc: add /proc/*/stack")
>> >> >> Cc: sta...@vger.kernel.org
>> >> >> Signed-off-by: Jann Horn
>> >> >> ---
>> >> >> fs/proc/base.c | 14 ++
>> >> >> 1 file changed, 14 insertions(+)
>> >> >>
>> >> >> diff --git a/fs/proc/base.c b/fs/proc/base.c
>> >> >> index ccf86f16d9f0..7e9f07bf260d 100644
>> >> >> --- a/fs/proc/base.c
>> >> >> +++ b/fs/proc/base.c
>> >> >> @@ -407,6 +407,20 @@ static int proc_pid_stack(struct seq_file *m,
>> >> >> struct pid_namespace *ns,
>> >> >> unsigned long *entries;
>> >> >> int err;
>> >> >>
>> >> >> + /*
>> >> >> +* The ability to racily run the kernel stack unwinder on a
>> >> >> running task
>> >> >> +* and then observe the unwinder output is scary; while it is
>> >> >> useful for
>> >> >> +* debugging kernel issues, it can also allow an attacker to
>> >> >> leak kernel
>> >> >> +* stack contents.
>> >> >> +* Doing this in a manner that is at least safe from races
>> >> >> would require
>> >> >> +* some work to ensure that the remote task can not be
>> >> >> scheduled; and
>> >> >> +* even then, this would still expose the unwinder as local
>> >> >> attack
>> >> >> +* surface.
>> >> >> +* Therefore, this interface is restricted to root.
>> >> >> +*/
>> >> >> + if (!file_ns_capable(m->file, &init_user_ns, CAP_SYS_ADMIN))
>> >> >> + return -EACCES;
>> >>
>> >> In the past, we've avoided hard errors like this in favor of just
>> >> censoring the output. Do we want to be more cautious here? (i.e.
>> >> return 0 or a fuller seq_printf(m, "[<0>] privileged\n"); return 0;)
>> >
>> > In my mind, this is different because it's a place where we don't have
>> > to selectively censor output while preserving parts of it, and it's a
>> > place where, as Laura said, it's useful to make lack of privileges
>> > clearly visible because that informs users that they may have to retry
>> > with more privileges.
>> >
>> > Of course, if you have an example of software that actually breaks due
>> > to this, I'll change it. But I looked at the three things in Debian
>> > codesearch that seem to use it, and from what I can tell, they all
>> > bail out cleanly when the read fails.
>>
>> I prefer -EACCESS too, but I thought I'd mention the alternative. So, I
>> guess:
>>
>> Reviewed-by: Kees Cook
>
> What do I need to do to get this merged? Oh, I think I misread
> MAINTAINERS - Alexey Dobriyan is not a maintainer, just a reviewer. So
> I guess this has to go via Andrew Morton? Should I resend the patch
> with Andrew in the recipient list?
Yeah, traditionally Andrew has taken /proc patches.
-Kees
--
Kees Cook
Pixel Security
Re: [PATCH 2/2] iio: magnetometer: Add driver support for PNI RM3100
On 26/09/2018 4:09 PM, Song Qiang wrote:
On Wed, Sep 26, 2018 at 10:30:34AM +0800, Phil Reid wrote:
On 26/09/2018 9:49 AM, Song Qiang wrote:
On Tue, Sep 25, 2018 at 10:36:54PM +0800, Phil Reid wrote:
On 25/09/2018 9:30 PM, Jonathan Cameron wrote:
+static irqreturn_t rm3100_trigger_handler(int irq, void *p)
+{
+ struct iio_poll_func *pf = p;
+ struct iio_dev *indio_dev = pf->indio_dev;
+ struct rm3100_data *data = iio_priv(indio_dev);
+ struct regmap *regmap = data->regmap;
+ u8 buffer[9];
+ int ret;
+ int i;
+
+ mutex_lock(&data->lock);
+ ret = rm3100_wait_measurement(data);
+ if (ret < 0) {
+ mutex_unlock(&data->lock);
+ goto done;
+ }
+
+ ret = regmap_bulk_read(regmap, RM3100_REG_MX2, buffer, sizeof(buffer));
+ mutex_unlock(&data->lock);
+ if (ret < 0)
+ goto done;
+
+ /* Convert XXXYYYZZZxxx to XXXxYYYxZZZx. x for padding. */
+ for (i = 0; i < 3; i++)
+ memcpy(data->buffer + i * 4, buffer + i * 3, 3);
Firstly X doesn't need copying.
Secondly the copy of Y actually overwrites the value of Z
XXXYYYZZZxxx
XXXxYYYZZxxx
XXXxYYYxYZZx
I think...
+
+ iio_push_to_buffers_with_timestamp(indio_dev, data->buffer,
+ iio_get_time_ns(indio_dev));
memcpy target is a different buffer so should be ok.
But that raises the question of does it need to be?
'buffer' could be 12 bytes long and just shuffle Z then Y.
Do the unused bytes need to be zeroed? or does libiio mask them anyway?
--
Regards
Phil Reid
Hi Phil,
This is interesting, last patch I submitted uses three transactions and
shuffles X, Y and Z respectively. You said it should be better to use one
transactions, I thought it makes point, and one transaction may reduce
IO pressure of the i2c bus. :)
And that's not necessary for unused bytes to be zero. I'm not familiar
with libiio, actually just been studying it, can't say anything about
it.
yours,
Song Qiang
G'day Song,
yes the one transaction suggestion was to reduce pressure on the bus.
I think also with 3 calls you can up up with other devices taking over
the i2c / spi bus in between.
We've got a devkit for this part, but haven't got to wiring it up to our system
as yet.
We're looking at using the i2c interface which could push things at max
samplerate, so yes I'm
keen to see bus pressure reduced as much as possible.
I was thinking something like the following:
u8 buffer[12];
regmap_bulk_read(regmap, RM3100_REG_MX2, buffer, 9);
buffer[10] = buffer[8]; // or memcpy or some other fancy shuffle code.
buffer[9] = buffer[7];
buffer[8] = buffer[6];
buffer[6] = buffer[5];
buffer[5] = buffer[4];
buffer[4] = buffer[3];
iio_push_to_buffers_with_timestamp(indio_dev, buffer,
iio_get_time_ns(indio_dev));
but I'm unsure if this would be needed:
buffer[7] = 0
buffer[3] = 0
What you've got does the job I think.
I haven't dug into the datasheet in great detail, and my iio knownledge is
limited.
Are you sure the RM3100_CHANNEL scantype endianness is IIO_LE.
rm3100_read_mag looks to be doing big endian conversion and the datasheet
agrees with that.
--
Regards
Phil Reid
Hi Phil,
You're absolutely right!
This should be big endian, I think I probably just want something there
when I was writing this code, planned to change it later, but apparently
I've forgotten it...
AFAIK, filling places we do not need with 0 is not needed, we just
extract valid data from valid bit field(24 here).
Both one transaction and three transactions way have their point, but
this is a OS, probably the spiltted one is better, I need some real
thinking about this...
The one transaction is better.
Reduces i2c traffic by 6 bytes and ensure the measurements are tightly
coupled in time for the 3 axis.
I could have use the same buffer to read from the sensor and send it to
userspace like this:
int i = 0;
ret = regmap_bulk_read(regmap, RM3100_REG_MX2, 9);
if(ret)
...
/* Convert XXXYYYZZZxxx to XXXxYYYxZZZx. */
for (i = 0; i < 2; i++)
memcpy(buffer + (2 - i) * 4, buffer + (2 - i) * 3), 3);
This code snippet will use the same buffer, actually that's what I was
using the first time. Jonathan must thinks so, from what he commented,
he assumed I was using the same buffer, also what you want.
But I changed this due to Peter's comment, maybe not a big deal, he
suggests to use sizeof(buffer), this makes me use an additional size 9
buffer. I thought this doesn't matter too much, just some additional
space from the stack, but now I think maybe less memory using would be
better...
After all, this length 9 seems like never shouldn't be changed...
yes that does the job.
--
Regards
Phil Reid
Re: [PATCH v23 4/4] soc: mediatek: Add Mediatek CMDQ helper
On Wed, 2018-09-26 at 23:53 +0800, Matthias Brugger wrote:
>
> On 25/07/2018 03:26, Houlong Wei wrote:
> > Add Mediatek CMDQ helper to create CMDQ packet and assemble GCE op code.
> >
> > Signed-off-by: Houlong Wei
> > Signed-off-by: HS Liao
> > ---
> > drivers/soc/mediatek/Kconfig | 12 ++
> > drivers/soc/mediatek/Makefile |1 +
> > drivers/soc/mediatek/mtk-cmdq-helper.c | 291
> >
> > include/linux/soc/mediatek/mtk-cmdq.h | 135 +++
> > 4 files changed, 439 insertions(+)
> > create mode 100644 drivers/soc/mediatek/mtk-cmdq-helper.c
> > create mode 100644 include/linux/soc/mediatek/mtk-cmdq.h
[...]
> > +
> > +struct cmdq_client *cmdq_mbox_create(struct device *dev, int index, u32
> > timeout)
> > +{
> > + struct cmdq_client *client;
> > +
> > + client = kzalloc(sizeof(*client), GFP_KERNEL);
> > + if (!client)
> > + return (struct cmdq_client *)-ENOMEM;
> > +
> > + client->timeout_ms = timeout;
> > + if (timeout != CMDQ_NO_TIMEOUT) {
> > + spin_lock_init(&client->lock);
> > + timer_setup(&client->timer, cmdq_client_timeout, 0);
> > + }
> > + client->pkt_cnt = 0;
> > + client->client.dev = dev;
> > + client->client.tx_block = false;
> > + client->chan = mbox_request_channel(&client->client, index);
> > +
> > + if (IS_ERR(client->chan)) {
> > + long err = 0;
> > +
> > + dev_err(dev, "failed to request channel\n");
> > + err = PTR_ERR(client->chan);
> > + kfree(client);
> > +
> > + return (struct cmdq_client *)err;
>
> Can't we use
> return ERR_PTR(err);
> here?
Sure, will fix it.
>
> > + }
> > +
> > + return client;
> > +}
> > +EXPORT_SYMBOL(cmdq_mbox_create);
> > +
> > +void cmdq_mbox_destroy(struct cmdq_client *client)
> > +{
> > + if (client->timeout_ms != CMDQ_NO_TIMEOUT) {
> > + spin_lock(&client->lock);
> > + del_timer_sync(&client->timer);
> > + spin_unlock(&client->lock);
> > + }
> > + mbox_free_channel(client->chan);
> > + kfree(client);
> > +}
> > +EXPORT_SYMBOL(cmdq_mbox_destroy);
> > +
> > +int cmdq_pkt_create(struct cmdq_client *client, struct cmdq_pkt **pkt_ptr,
> > + size_t size)
>
> I suppose you are not returning the allocated cmdq_pkt to avoid checks for
> IS_ERR() logic in the consumer of this API. Am I correct?
> Do we really need a pointer to a pointer here? Can't we just use a struct
> cmdq_pkt *pkt as argument? That would make things easier.
Do you mean we change the argument 'struct cmdq_pkt **pkt_ptr' to
'struct cmdq_pkt *pkt', and the consumer allocate a struct cmdq_pkt
*pkt, then pass pkt as argument of this API?
If yes, the consumer still need to check the return value of this API.
For the current implementation, the consumer doesn't need check
IS_ERR(*pkt_ptr) if the return value equals to 0.
Since the consumer has to check the return value of this API once, to
make it simpler, I shall change the prototype to
'struct cmdq_pkt *cmdq_pkt_create(struct cmdq_client *client, size_t
size)' and change its implementation.
>
> > +{
> > + struct cmdq_pkt *pkt;
> > + struct device *dev;
> > + dma_addr_t dma_addr;
> > +
> > + pkt = kzalloc(sizeof(*pkt), GFP_KERNEL);
> > + if (!pkt)
> > + return -ENOMEM;
> > + pkt->va_base = kzalloc(size, GFP_KERNEL);
> > + if (!pkt->va_base) {
> > + kfree(pkt);
> > + return -ENOMEM;
> > + }
> > + pkt->buf_size = size;
> > + pkt->cl = (void *)client;
> > +
> > + dev = client->chan->mbox->dev;
> > + dma_addr = dma_map_single(dev, pkt->va_base, pkt->buf_size,
> > + DMA_TO_DEVICE);
> > + if (dma_mapping_error(dev, dma_addr)) {
> > + dev_err(dev, "dma map failed, size=%u\n", (u32)(u64)size);
> > + kfree(pkt->va_base);
> > + kfree(pkt);
> > + return -ENOMEM;
> > + }
> > +
> > + pkt->pa_base = dma_addr;
> > + *pkt_ptr = pkt;
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(cmdq_pkt_create);
> > +
> > +void cmdq_pkt_destroy(struct cmdq_pkt *pkt)
> > +{
> > + struct cmdq_client *client = (struct cmdq_client *)pkt->cl;
> > +
> > + dma_unmap_single(client->chan->mbox->dev, pkt->pa_base, pkt->buf_size,
> > +DMA_TO_DEVICE);
> > + kfree(pkt->va_base);
> > + kfree(pkt);
> > +}
> > +EXPORT_SYMBOL(cmdq_pkt_destroy);
> > +
> > +static int cmdq_pkt_append_command(struct cmdq_pkt *pkt, enum cmdq_code
> > code,
> > + u32 arg_a, u32 arg_b)
> > +{
> > + u64 *cmd_ptr;
> > +
> > + if (unlikely(pkt->cmd_buf_size + CMDQ_INST_SIZE > pkt->buf_size)) {
> > + pkt->cmd_buf_size += CMDQ_INST_SIZE;
>
> Why do we update the cmd_buf_size here?
Because in developing phase of consumer driver, the consumer has to know
the real command buffer size after adding command failure. Then the
consumer will increase the size and run the cmdq flow (cmdq_pkt_create,
cmdq_pkt_w
Re: Bug: getcwd: cannot access parent directories
Ping :) On 21 September 2018 at 18:16, Roel Van de Paar wrote: > > [1.] One line summary of the problem: > > "cd: error retrieving current directory: getcwd: cannot access parent > directories: No such file or directory" on move of directories to > another volume > > [2.] Full description of the problem/report: > > Example output (testcase below): > > /tmp/1/2$ cd .. > cd: error retrieving current directory: getcwd: cannot access parent > directories: No such file or directory > /tmp/1/2/..$ cd .. > cd: error retrieving current directory: getcwd: cannot access parent > directories: No such file or directory > /tmp/1/2/../..$ cd .. > cd: error retrieving current directory: getcwd: cannot access parent > directories: No such file or directory > /tmp/1/2/../../..$ cd .. > cd: error retrieving current directory: getcwd: cannot access parent > directories: No such file or directory > /tmp/1/2/../../../..$ cd .. > cd: error retrieving current directory: getcwd: cannot access parent > directories: No such file or directory > /tmp/1/2/../../../../..$ cd .. > cd: error retrieving current directory: getcwd: cannot access parent > directories: No such file or directory > /tmp/1/2/../../../../../..$ cd .. > /tmp$ > > - The number of ".." required is not correct > - The number of ".." matches the number of subdirs (see below) > > [4.] Kernel information > > Tested on latest updates of: > * Ubuntu Xenial > * Ubuntu Bionic > * Centos 7 > > [7.] A small shell script or example program which triggers the > problem (if possible) > > In session 1 > cd /tmp > mkdir -p 1/2 > cd 1/2 > > In session 2 (another terminal session) > cd /tmp > mkdir -p 3/4/5/6/7 > mv 1 3/4/5/6/7 > mv 3 /dev/shm # where /dev/shm is some other disk. /dev/shm > reproduction works too. If the disk is the same, the issue will not > show. > > Back to session 1 > cd .. # fail > cd .. # fail > cd .. # fail > cd .. # fail > cd .. # fail > cd .. # fail > cd .. # works, but to completely incorrect directory given the > many 'cd ..'``` > > The problem is made more clear here by using 3/4/5/6/7 but you can > also just use a single subdir to see it Roel Van de Paar, Technical Director - Quality Assurance, Percona
Re: [PATCH] split if-condition code in bch_cache_set_alloc
On 9/26/18 5:00 PM, Dongbo Cao wrote:
rebase my local code and commit it again.
Signed-off-by: Dongbo Cao
Hi Dongbo,
The above commit log does not explain why you make this change (it might
belong to changelog). Could you please to make it to be more informative ?
Thanks.
Coly Li
---
drivers/md/bcache/super.c | 114 +++---
1 file changed, 93 insertions(+), 21 deletions(-)
diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
index a2cc354c..03099c4c 100644
--- a/drivers/md/bcache/super.c
+++ b/drivers/md/bcache/super.c
@@ -1691,10 +1691,13 @@ void bch_cache_set_unregister(struct cache_set *c)
struct cache_set *bch_cache_set_alloc(struct cache_sb *sb)
{
int iter_size;
- struct cache_set *c = kzalloc(sizeof(struct cache_set), GFP_KERNEL);
+ const char *err = NULL;
- if (!c)
- return NULL;
+ struct cache_set *c = kzalloc(sizeof(struct cache_set), GFP_KERNEL);
+ if (!c) {
+ err = "cache_set alloc failed";
+ goto err_cache_set_alloc;
+ }
__module_get(THIS_MODULE);
closure_init(&c->cl, NULL);
@@ -1750,22 +1753,65 @@ struct cache_set *bch_cache_set_alloc(struct cache_sb
*sb)
iter_size = (sb->bucket_size / sb->block_size + 1) *
sizeof(struct btree_iter_set);
- if (!(c->devices = kcalloc(c->nr_uuids, sizeof(void *), GFP_KERNEL)) ||
- mempool_init_slab_pool(&c->search, 32, bch_search_cache) ||
- mempool_init_kmalloc_pool(&c->bio_meta, 2,
- sizeof(struct bbio) + sizeof(struct bio_vec) *
- bucket_pages(c)) ||
- mempool_init_kmalloc_pool(&c->fill_iter, 1, iter_size) ||
- bioset_init(&c->bio_split, 4, offsetof(struct bbio, bio),
- BIOSET_NEED_BVECS|BIOSET_NEED_RESCUER) ||
- !(c->uuids = alloc_bucket_pages(GFP_KERNEL, c)) ||
- !(c->moving_gc_wq = alloc_workqueue("bcache_gc",
- WQ_MEM_RECLAIM, 0)) ||
- bch_journal_alloc(c) ||
- bch_btree_cache_alloc(c) ||
- bch_open_buckets_alloc(c) ||
- bch_bset_sort_state_init(&c->sort, ilog2(c->btree_pages)))
- goto err;
+ c->devices = kcalloc(c->nr_uuids, sizeof(void *), GFP_KERNEL);
+ if (!c->devices) {
+ err = "c->devices alloc failed";
+ goto err_devices_alloc;
+ }
+
+ if (mempool_init_slab_pool(&c->search, 32, bch_search_cache)) {
+ err = "c->search alloc failed";
+ goto err_search_alloc;
+ }
+
+ if (mempool_init_kmalloc_pool(&c->bio_meta, 2, sizeof(struct bbio)
+ + sizeof(struct bio_vec) * bucket_pages(c))) {
+ err = "c->bio_meta alloc failed";
+ goto err_bio_meta_alloc;
+ }
+
+ if (mempool_init_kmalloc_pool(&c->fill_iter, 1, iter_size)) {
+ err = "c->fill_iter alloc failed";
+ goto err_fill_iter_alloc;
+ }
+
+ if (bioset_init(&c->bio_split, 4, offsetof(struct bbio, bio),
+ BIOSET_NEED_BVECS|BIOSET_NEED_RESCUER)) {
+ err = "c->bio_split init failed";
+ goto err_bio_split_init;
+ }
+
+ c->uuids = alloc_bucket_pages(GFP_KERNEL, c);
+ if (!c->uuids) {
+ err = "c->uuids alloc failed";
+ goto err_uuids_alloc;
+ }
+
+ c->moving_gc_wq = alloc_workqueue("bcache_gc", WQ_MEM_RECLAIM, 0);
+ if (!c->moving_gc_wq) {
+ err = "c->moving_gc_wq alloc failed";
+ goto err_moving_gc_wq_alloc;
+ }
+
+ if (bch_journal_alloc(c)) {
+ err = "bch_journal_alloc failed";
+ goto err_bch_journal_alloc;
+ }
+
+ if (bch_btree_cache_alloc(c)) {
+ err = "bch_btree_cache_alloc failed";
+ goto err_bch_btree_cache_alloc;
+ }
+
+ if (bch_open_buckets_alloc(c)) {
+ err = "bch_open_buckets_alloc failed";
+ goto err_bch_open_buckets_alloc;
+ }
+
+ if (bch_bset_sort_state_init(&c->sort, ilog2(c->btree_pages))) {
+ err = "bch_bset_sort_state_init failed";
+ goto err_bch_bset_sort_state_init;
+ }
c->congested_read_threshold_us = 2000;
c->congested_write_threshold_us = 2;
@@ -1773,8 +1819,34 @@ struct cache_set *bch_cache_set_alloc(struct cache_sb
*sb)
WARN_ON(test_and_clear_bit(CACHE_SET_IO_DISABLE, &c->flags));
return c;
-err:
- bch_cache_set_unregister(c);
+
+err_bch_bset_sort_state_init:
+ bch_open_buckets_free(c);
+err_bch_open_buckets_alloc:
+ bch_btree_cache_free(c);
+err_bch_btree_cache_alloc:
+ bch_journal_free(c);
+err_bch_journal_alloc:
+ destroy_workqueue(c->moving_gc_wq);
+err_moving_gc_wq_alloc:
+
[PATCH v2 7/7] drivers: hwtracing: Adds Makefile to enable building from directory.
Adds Makefile to enable building the driver using 'make drivers/hwtracing/'. Changes drivers/Makefile to call the new Makefile directly. It enables user building this driver without building the whole drivers/ subtree. Signed-off-by: Leonardo Brás --- drivers/Makefile | 4 +--- drivers/hwtracing/Makefile | 3 +++ 2 files changed, 4 insertions(+), 3 deletions(-) create mode 100644 drivers/hwtracing/Makefile diff --git a/drivers/Makefile b/drivers/Makefile index 578f469f72fb..a237be6b602f 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -174,9 +174,7 @@ obj-$(CONFIG_MCB) += mcb/ obj-$(CONFIG_PERF_EVENTS) += perf/ obj-$(CONFIG_RAS) += ras/ obj-$(CONFIG_THUNDERBOLT) += thunderbolt/ -obj-$(CONFIG_CORESIGHT)+= hwtracing/coresight/ -obj-y += hwtracing/intel_th/ -obj-$(CONFIG_STM) += hwtracing/stm/ +obj-y += hwtracing/ obj-$(CONFIG_ANDROID) += android/ obj-$(CONFIG_NVMEM)+= nvmem/ obj-$(CONFIG_FPGA) += fpga/ diff --git a/drivers/hwtracing/Makefile b/drivers/hwtracing/Makefile new file mode 100644 index ..fe5773caec49 --- /dev/null +++ b/drivers/hwtracing/Makefile @@ -0,0 +1,3 @@ +obj-$(CONFIG_CORESIGHT)+= coresight/ +obj-y += intel_th/ +obj-$(CONFIG_STM) += stm/ -- 2.19.0
[PATCH v2 6/7] drivers: oprofile: Avoids building driver from direct make command
Creates new Makefile to avoid building driver if 'make drivers/oprofile/' is called directly. This driver is usually built from arch/$ARCH and seems to have no meaning building alone. Signed-off-by: Leonardo Brás --- drivers/oprofile/Makefile | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 drivers/oprofile/Makefile diff --git a/drivers/oprofile/Makefile b/drivers/oprofile/Makefile new file mode 100644 index ..acaed2ad6eee --- /dev/null +++ b/drivers/oprofile/Makefile @@ -0,0 +1,2 @@ +#Does nothing, since the source is called from arch/$ARCH/ tree. + -- 2.19.0
[PATCH v2 5/7] drivers: s390: Avoids building drivers if ARCH is not s390.
Avoids building s390 drivers if 'make drivers/s390/' is called but ARCH is not s390. Signed-off-by: Leonardo Brás --- drivers/s390/Makefile | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/s390/Makefile b/drivers/s390/Makefile index a863b0462b43..0575f02dba45 100644 --- a/drivers/s390/Makefile +++ b/drivers/s390/Makefile @@ -3,7 +3,7 @@ # Makefile for the S/390 specific device drivers # -obj-y += cio/ block/ char/ crypto/ net/ scsi/ virtio/ - -drivers-y += drivers/s390/built-in.a - +ifeq ($(ARCH),s390) + obj-y += cio/ block/ char/ crypto/ net/ scsi/ virtio/ + drivers-y += drivers/s390/built-in.a +endif -- 2.19.0
[PATCH v2 4/7] drivers: zorro: Avoids building proc.o if CONFIG_ZORRO is disabled
Avoids building proc.o if 'make drivers/zorro/' is called and CONFIG_ZORRO is disabled, even if CONFIG_PROC_FS is enabled. Signed-off-by: Leonardo Brás --- drivers/zorro/Makefile | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/zorro/Makefile b/drivers/zorro/Makefile index b360ac4ea846..d580f9f08e0a 100644 --- a/drivers/zorro/Makefile +++ b/drivers/zorro/Makefile @@ -3,9 +3,10 @@ # Makefile for the Zorro bus specific drivers. # -obj-$(CONFIG_ZORRO)+= zorro.o zorro-driver.o zorro-sysfs.o -obj-$(CONFIG_PROC_FS) += proc.o -obj-$(CONFIG_ZORRO_NAMES) += names.o +obj-$(CONFIG_ZORRO):= zorro_all.o +zorro_all-y+= zorro.o zorro-driver.o zorro-sysfs.o +zorro_all-$(CONFIG_ZORRO_NAMES) += names.o +zorro_all-$(CONFIG_PROC_FS)+= proc.o hostprogs-y:= gen-devlist -- 2.19.0
[PATCH v2 3/7] drivers: parisc: Avoids building driver if CONFIG_PARISC is disabled
Avoids building driver if 'make drivers/parisc/' is called and CONFIG_PARISC is disabled. Signed-off-by: Leonardo Brás --- drivers/parisc/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/parisc/Makefile b/drivers/parisc/Makefile index 3cd5e6cb8478..80049d763aa0 100644 --- a/drivers/parisc/Makefile +++ b/drivers/parisc/Makefile @@ -24,5 +24,5 @@ obj-$(CONFIG_EISA)+= eisa.o eisa_enumerator.o eisa_eeprom.o obj-$(CONFIG_SUPERIO) += superio.o obj-$(CONFIG_CHASSIS_LCD_LED) += led.o obj-$(CONFIG_PDC_STABLE) += pdc_stable.o -obj-y += power.o +obj-$(CONFIG_PARISC) += power.o -- 2.19.0
Re: [PATCH] mmc: add quirk for O2 Micro dev 0x8620 rev 0x01
On Thu, Sep 27, 2018 at 01:48:58AM +0200, Ulf Hansson wrote: > On 23 September 2018 at 22:39, Yu Zhao wrote: > > This device reports SDHCI_CLOCK_INT_STABLE even though it's not > > ready to take SDHCI_CLOCK_CARD_EN. The symptom is that reading > > SDHCI_CLOCK_CONTROL after enabling the clock shows absence of the > > bit from the register (e.g. expecting 0xfa07 = 0xfa03 | > > SDHCI_CLOCK_CARD_EN but only observed the first operand). > > > > mmc1: Timeout waiting for hardware cmd interrupt. > > mmc1: sdhci: SDHCI REGISTER DUMP === > > mmc1: sdhci: Sys addr: 0x | Version: 0x0603 > > mmc1: sdhci: Blk size: 0x | Blk cnt: 0x > > mmc1: sdhci: Argument: 0x | Trn mode: 0x > > mmc1: sdhci: Present: 0x01ff0001 | Host ctl: 0x0001 > > mmc1: sdhci: Power: 0x000f | Blk gap: 0x > > mmc1: sdhci: Wake-up: 0x | Clock:0xfa03 > > mmc1: sdhci: Timeout: 0x | Int stat: 0x > > mmc1: sdhci: Int enab: 0x00ff0083 | Sig enab: 0x00ff0083 > > mmc1: sdhci: AC12 err: 0x | Slot int: 0x > > mmc1: sdhci: Caps: 0x25fcc8bf | Caps_1: 0x2077 > > mmc1: sdhci: Cmd: 0x | Max curr: 0x005800c8 > > mmc1: sdhci: Resp[0]: 0x | Resp[1]: 0x > > mmc1: sdhci: Resp[2]: 0x | Resp[3]: 0x > > mmc1: sdhci: Host ctl2: 0x0008 > > mmc1: sdhci: ADMA Err: 0x | ADMA Ptr: 0x > > mmc1: sdhci: > > > > The problem happens during wakeup from S3. Adding a delay quirk > > after power up reliably fixes the problem. > > > > Signed-off-by: Yu Zhao > > Applied for next, thanks! > > Kind regards > Uffe > > > --- > > drivers/mmc/host/sdhci-pci-o2micro.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/mmc/host/sdhci-pci-o2micro.c > > b/drivers/mmc/host/sdhci-pci-o2micro.c > > index 77e9bc4aaee9..3e5ecf7ce101 100644 > > --- a/drivers/mmc/host/sdhci-pci-o2micro.c > > +++ b/drivers/mmc/host/sdhci-pci-o2micro.c > > @@ -490,6 +490,8 @@ int sdhci_pci_o2_probe(struct sdhci_pci_chip *chip) > > pci_write_config_byte(chip->pdev, O2_SD_LOCK_WP, scratch); > > break; > > case PCI_DEVICE_ID_O2_SEABIRD0: > > + if (chip->pdev->revision == 0x01) > > + chip->quirks |= SDHCI_QUIRK_DELAY_AFTER_POWER; Hi Uffe, I apologize for the missing /* fall through */ here. Could you please add it in case it causes any static checker problem? Or I can send a v2. Thank you.
[PATCH v2 2/7] drivers: nubus: Avoids building driver if CONFIG_NUBUS is disabled
Avoids building driver if 'make drivers/nubus/' is called and CONFIG_NUBUS is disabled. Avoids building proc.o if CONFIG_PROC_FS is enabled but CONFIG_NUBUS is disabled. Signed-off-by: Leonardo Brás --- drivers/nubus/Makefile | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/nubus/Makefile b/drivers/nubus/Makefile index 6d063cde39d1..1daa51217e95 100644 --- a/drivers/nubus/Makefile +++ b/drivers/nubus/Makefile @@ -2,6 +2,7 @@ # Makefile for the nubus specific drivers. # -obj-y := nubus.o bus.o +obj-$(CONFIG_NUBUS) := nubus_all.o +nubus_all-y += bus.o nubus.o -obj-$(CONFIG_PROC_FS) += proc.o +nubus_all-$(CONFIG_PROC_FS) += proc.o -- 2.19.0
[PATCH v2 1/7] drivers: dio: Avoids building driver if CONFIG_DIO is disabled
Avoids building driver if 'make drivers/dio/' is called and CONFIG_DIO is disabled. Signed-off-by: Leonardo Brás --- drivers/dio/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dio/Makefile b/drivers/dio/Makefile index ae92d17083f2..f5cffe232448 100644 --- a/drivers/dio/Makefile +++ b/drivers/dio/Makefile @@ -2,4 +2,4 @@ # Makefile for the linux kernel. # -obj-y := dio.o dio-driver.o dio-sysfs.o +obj-$(CONFIG_DIO) := dio.o dio-driver.o dio-sysfs.o \ No newline at end of file -- 2.19.0
[PATCH v2 0/7] Remove errors building drivers/DRIVERNAME
Special thanks for the feedback from: - Finn Thain (I fixed the build problem) - Geert Uytterhoeven (The cross compilers were very useful) - Rolf Eike Beer (Was unintentional, thanks for noticing) This Patchset changes some driver's Makefile to allow them building using the command 'make drivers/DRIVERNAME', if compatible. The changed drivers would return error if the above command was run on them, after an x86 allyesconfig. The main reason of this patchset is to allow building lists of drivers looking for warnings and errors to be fixed. I see this change as a new feature, not a bugfix. I understand the default bahavior may be building with a simple 'make', but I believe adding this new possibility will not be harmful. My main objective is to allow developers with low processing power to do changes in the kernel and look bugs using free services like GiltabCI, before submitting to community. If there is any interest helping/using this, I have a prototype in: https://gitlab.com/LeoBras/linux-next Leonardo Brás (7): drivers: dio: Avoids building driver if CONFIG_DIO is disabled drivers: nubus: Avoids building driver if CONFIG_NUBUS is disabled drivers: parisc: Avoids building driver if CONFIG_PARISC is disabled drivers: zorro: Avoids building proc.o if CONFIG_ZORRO is disabled drivers: s390: Avoids building drivers if ARCH is not s390. drivers: oprofile: Avoids building driver from direct make command drivers: hwtracing: Adds Makefile to enable building from directory. drivers/Makefile | 4 +--- drivers/dio/Makefile | 2 +- drivers/hwtracing/Makefile | 3 +++ drivers/nubus/Makefile | 5 +++-- drivers/oprofile/Makefile | 2 ++ drivers/parisc/Makefile| 2 +- drivers/s390/Makefile | 8 drivers/zorro/Makefile | 7 --- 8 files changed, 19 insertions(+), 14 deletions(-) create mode 100644 drivers/hwtracing/Makefile create mode 100644 drivers/oprofile/Makefile -- 2.19.0
Re: Leaking Path in XFS's ioctl interface(missing LSM check)
On Wed, Sep 26, 2018 at 07:24:26PM +0100, Alan Cox wrote: > On Wed, 26 Sep 2018 11:33:29 +1000 > Dave Chinner wrote: > > > On Tue, Sep 25, 2018 at 08:51:50PM -0400, TongZhang wrote: > > > Hi, > > > > > > I'm bringing up this issue again to let of LSM developers know the > > > situation, and would like to know your thoughts. > > > Several weeks ago I sent an email to the security list to discuss the > > > issue where > > > XFS's ioctl interface can do things like vfs_readlink without asking LSM's > > > permission, which we think is kind of weird and this kind of operation > > > should be > > > audited by LSM. > > > > These aren't user interfaces. They are filesystem maintenance and > > extension interfaces. They are intended for low level filesystem > > utilities that require complete, unrestricted access to the > > underlying filesystem via holding CAP_SYSADMIN in the initns. > > CAP_SYS_ADMIN is meaningless in an environment using a strong LSM set up. Sure, but there are so many CAP_SYS_ADMIN-only ioctls in the kernel that have no LSM coverage that this is not an isolated problem that people setting up such systems have to deal with. the LSM hooks are already complex enough without adding hundreds more hooks to control individual ioctl behaviour for every filesystem, device, etc. Unless you are going to add LSM hooks to all ioctls, I don't see much point in singling out one set of ioctls in a way that will break existing configurations. It's just a knee jerk reaction (like ariport security) because it doesn't meaningfully address the problem of all the other management ioctls in the kernel being completely unconstrainted by LSMs. > CAP_SYS_ADMIN is also a bit weird because low level access usually > implies you can bypass access controls so you should also check > CAP_SYS_DAC ? Do you mean CAP_DAC_READ_SEARCH as per the newer handle syscalls? But that only allows bypassing directory search operations, so maybe you mean CAP_DAC_OVERRIDE? Regardless, this horse bolted long before those syscalls were introduced. The time to address this issue was when XFS was merged into linux all those years ago, back when the apps that run in highly secure restricted environments that use these interfaces were being ported to linux. We can't change this now without breaking userspace Cheers, Dave. -- Dave Chinner da...@fromorbit.com
Re: [PATCH v2] of: __of_update_property_sysfs only call __of_sysfs_remove_bin_file if of_node_is_attached
On 09/26/18 14:05, Rob Herring wrote: > On Thu, Sep 13, 2018 at 03:21:27PM +, Andre Kalb wrote: >> Hi Rob, >> >> I have used an other hardware to check the patch. I hope it doesn’t matter. >> I added few lines at the untitest.c. All existing unittest use an attached >> sysfs, therefore the bug isn't detectable. > > Okay, can you resend both patches in one series rather than pasted in > here. > > Rob I don't understand the need for the patch to __of_update_property_sysfs() in the context of the current mainline Linux kernel. As far as I know, there are no callers of of_update_property() against a tree that is detached. As such, the patch is adding complexity without adding any functionality. -Frank
Re: [PATCH -V5 RESEND 03/21] swap: Support PMD swap mapping in swap_duplicate()
Daniel Jordan writes:
> On Wed, Sep 26, 2018 at 08:55:59PM +0800, Huang, Ying wrote:
>> Daniel Jordan writes:
>> > On Tue, Sep 25, 2018 at 03:13:30PM +0800, Huang Ying wrote:
>> >> /*
>> >> * Increase reference count of swap entry by 1.
>> >> - * Returns 0 for success, or -ENOMEM if a swap_count_continuation is
>> >> required
>> >> - * but could not be atomically allocated. Returns 0, just as if it
>> >> succeeded,
>> >> - * if __swap_duplicate() fails for another reason (-EINVAL or -ENOENT),
>> >> which
>> >> - * might occur if a page table entry has got corrupted.
>> >> + *
>> >> + * Return error code in following case.
>> >> + * - success -> 0
>> >> + * - swap_count_continuation is required but could not be atomically
>> >> allocated.
>> >> + * *entry is used to return swap entry to call
>> >> add_swap_count_continuation().
>> >> + *
>> >> -> ENOMEM
>> >> + * - otherwise same as __swap_duplicate()
>> >> */
>> >> -int swap_duplicate(swp_entry_t entry)
>> >> +int swap_duplicate(swp_entry_t *entry, int entry_size)
>> >> {
>> >> int err = 0;
>> >>
>> >> - while (!err && __swap_duplicate(entry, 1) == -ENOMEM)
>> >> - err = add_swap_count_continuation(entry, GFP_ATOMIC);
>> >> + while (!err &&
>> >> +(err = __swap_duplicate(entry, entry_size, 1)) == -ENOMEM)
>> >> + err = add_swap_count_continuation(*entry, GFP_ATOMIC);
>> >> return err;
>> >
>> > Now we're returning any error we get from __swap_duplicate, apparently to
>> > accommodate ENOTDIR later in the series, which is a change from the
>> > behavior
>> > introduced in 570a335b8e22 ("swap_info: swap count continuations"). This
>> > might
>> > belong in a separate patch given its potential for side effects.
>>
>> I have checked all the calls of the function and found there will be no
>> bad effect. Do you have any side effect?
>
> Before I was just being vaguely concerned about any unintended side effects,
> but looking again, yes I do.
>
> Now when swap_duplicate returns an error in copy_one_pte, copy_one_pte returns
> a (potentially nonzero) entry.val, which copy_pte_range interprets
> unconditionally as 'try adding a swap count continuation.' Not what we want
> for returns other than -ENOMEM.
Thanks for pointing this out! Before the change in the patchset, the
behavior is,
Something wrong is detected in swap_duplicate(), but the error is
ignored. Then copy_one_pte() will think everything is OK, so that it
can proceed to call set_pte_at(). The system will be in inconsistent
state and some data may be polluted!
But this doesn't cause any problem in practical. Per my understanding,
because if other part of the kernel works correctly, it's impossible for
swap_duplicate() return any error except -ENOMEM before the change in
this patchset. But the error may be possible during development, and it
may serve as some kind of document too. So I suggest to add
VM_BUG_ON(error != -ENOMEM);
in swap_duplicate(). What do you think about that?
> So it might make sense to have a separate patch that changes swap_duplicate's
> return and makes callers handle it.
Thanks for your help to take a deep look at this. I want to try to fix
all potential problems firstly, because the number of the caller is
quite limited. Do you agree?
Best Regards,
Huang, Ying
Re: [PATCH] proc: restrict kernel stack dumps to root
On Thu, Sep 13, 2018 at 4:39 PM Kees Cook wrote:
> On Thu, Sep 13, 2018 at 4:55 AM, Jann Horn wrote:
> > On Thu, Sep 13, 2018 at 12:28 AM Kees Cook wrote:
> >>
> >> On Wed, Sep 12, 2018 at 8:29 AM, Jann Horn wrote:
> >> > +linux-api, I guess
> >> >
> >> > On Tue, Sep 11, 2018 at 8:39 PM Jann Horn wrote:
> >> >>
> >> >> Restrict the ability to inspect kernel stacks of arbitrary tasks to root
> >> >> in order to prevent a local attacker from exploiting racy stack
> >> >> unwinding
> >> >> to leak kernel task stack contents.
> >> >> See the added comment for a longer rationale.
> >> >>
> >> >> There don't seem to be any users of this userspace API that can't
> >> >> gracefully bail out if reading from the file fails. Therefore, I believe
> >> >> that this change is unlikely to break things.
> >> >> In the case that this patch does end up needing a revert, the next-best
> >> >> solution might be to fake a single-entry stack based on wchan.
> >> >>
> >> >> Fixes: 2ec220e27f50 ("proc: add /proc/*/stack")
> >> >> Cc: sta...@vger.kernel.org
> >> >> Signed-off-by: Jann Horn
> >> >> ---
> >> >> fs/proc/base.c | 14 ++
> >> >> 1 file changed, 14 insertions(+)
> >> >>
> >> >> diff --git a/fs/proc/base.c b/fs/proc/base.c
> >> >> index ccf86f16d9f0..7e9f07bf260d 100644
> >> >> --- a/fs/proc/base.c
> >> >> +++ b/fs/proc/base.c
> >> >> @@ -407,6 +407,20 @@ static int proc_pid_stack(struct seq_file *m,
> >> >> struct pid_namespace *ns,
> >> >> unsigned long *entries;
> >> >> int err;
> >> >>
> >> >> + /*
> >> >> +* The ability to racily run the kernel stack unwinder on a
> >> >> running task
> >> >> +* and then observe the unwinder output is scary; while it is
> >> >> useful for
> >> >> +* debugging kernel issues, it can also allow an attacker to
> >> >> leak kernel
> >> >> +* stack contents.
> >> >> +* Doing this in a manner that is at least safe from races
> >> >> would require
> >> >> +* some work to ensure that the remote task can not be
> >> >> scheduled; and
> >> >> +* even then, this would still expose the unwinder as local
> >> >> attack
> >> >> +* surface.
> >> >> +* Therefore, this interface is restricted to root.
> >> >> +*/
> >> >> + if (!file_ns_capable(m->file, &init_user_ns, CAP_SYS_ADMIN))
> >> >> + return -EACCES;
> >>
> >> In the past, we've avoided hard errors like this in favor of just
> >> censoring the output. Do we want to be more cautious here? (i.e.
> >> return 0 or a fuller seq_printf(m, "[<0>] privileged\n"); return 0;)
> >
> > In my mind, this is different because it's a place where we don't have
> > to selectively censor output while preserving parts of it, and it's a
> > place where, as Laura said, it's useful to make lack of privileges
> > clearly visible because that informs users that they may have to retry
> > with more privileges.
> >
> > Of course, if you have an example of software that actually breaks due
> > to this, I'll change it. But I looked at the three things in Debian
> > codesearch that seem to use it, and from what I can tell, they all
> > bail out cleanly when the read fails.
>
> I prefer -EACCESS too, but I thought I'd mention the alternative. So, I guess:
>
> Reviewed-by: Kees Cook
What do I need to do to get this merged? Oh, I think I misread
MAINTAINERS - Alexey Dobriyan is not a maintainer, just a reviewer. So
I guess this has to go via Andrew Morton? Should I resend the patch
with Andrew in the recipient list?
Re: [PATCH] sched/fair: vruntime should normalize when switching from fair
On Thu, 27 Sep 2018 at 06:38, Dietmar Eggemann wrote: > > Hi, > > On 09/26/2018 11:50 AM, Wanpeng Li wrote: > > Hi Dietmar, > > On Tue, 28 Aug 2018 at 22:55, Dietmar Eggemann > > wrote: > >> > >> On 08/27/2018 12:14 PM, Peter Zijlstra wrote: > >>> On Fri, Aug 24, 2018 at 02:24:48PM -0700, Steve Muckle wrote: > On 08/24/2018 02:47 AM, Peter Zijlstra wrote: > >>> On 08/17/2018 11:27 AM, Steve Muckle wrote: > > [...] > > - later, when the prio is deboosted and the task is moved back > to the fair class, the fair rq's min_vruntime is added to > the task's vruntime, even though it wasn't subtracted earlier. > > > > Could you point out when the fair rq's min_vruntime is added to the > > task's vruntime in your *later* scenario? attach_task_cfs_rq will not > > do that the same reason as detach_task_cfs_rq. fair task's > > sched_remote_wakeup is false which results in vruntime will not be > > renormalized in enqueue_entity. > > The cfs_rq->min_vruntime is still added to the se->vruntime in > enqueue_task_fair(). I understand what your patch done, On your CPU4: scheduler_ipi() -> sched_ttwu_pending() -> ttwu_do_activate()=> p->sched_remote_wakeup should be false, so ENQUEUE_WAKEUP is set, ENQUEUE_MIGRATED is not -> ttwu_activate() -> activate_task() -> enqueue_task() -> enqueue_task_fair() -> enqueue_entity() bool renorm = !(flags & ENQUEUE_WAKEUP) || (flags & ENQUEUE_MIGRATE) so renorm is false in enqueue_entity(), why you mentioned that the cfs_rq->min_vruntime is still added to the se->vruntime in enqueue_task_fair()? Regards, Wanpeng Li
