Re: [PATCH 0/3 v3] mmu_notifier: Allow to manage CPU external TLBs
On Fri, Sep 12, 2014 at 12:19:37PM -0700, Andrew Morton wrote: > On Fri, 12 Sep 2014 20:47:39 +0200 Joerg Roedel wrote: > > > thanks for your review, I tried to answer your questions below. > > You'd be amazed how helpful that was ;) > > > Fair enough, I hope I clarified a few things with my explanations > > above. I will also update the description of the patch-set when I > > re-send. > > Sounds good, thanks. > > > How does HMM play into all of this? Would HMM make this patchset > obsolete, or could HMM be evolved to do so? HMM should be consider as distinc from this. The hardware TLB we are talking with this patchset can be flush by the CPU from inside an atomic context (ie while holding cpu page table spinlock for instance). HMM on the other hand deals with hardware that have there own page table ie they do not necessarily walk the cpu page table. Flushing the TLB for this kind of hardware means scheduling some job on the hardware and this can not be done from kernel atomic context as this job might take a long time to complete (imagine preempting thousand of threads on a gpu). Still HMM can be use in a mixed environement where the IOMMUv2 is use for memory that reside into system ram while HMM only handle memory that have been migrated to the device memory. So while HMM intend to provide more features than IOMMUv2 hardware allow, it does not intend to replace it. On contrary hope is that both can work at same time. Cheers, Jérôme > ___ > iommu mailing list > io...@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/iommu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Patch v9 0/3] DWC3 USB support for Qualcomm platform
These patches add basic support for USB3.0 controllers found on MSM platforms. USB3.0 core is based on Synopsys DesignWare SuperSpeed IP. This work was started by Ivan Ivanov and went through a number of iterations. I picked these patches up and did a little rework to get them working. Changes since v8: * Fixed minor comments from reviewers. Changes since v7: * Reworked phy driver to conform to the generic phy framework. * Collapsed HS and SS phy drivers into same source file. * Dropped regulators from the drivers. The only platform where we can utilize this driver has regulators on all the time. Will add regulators back in when they are required. * Added timeouts to the phy register accesses * Put in definitions for the phy specific registers and bitfields * Removed unnecessary workarounds. Changes since v6: * Renamed all MSM references to qcom, including file names * Removed direct TCSR manipulation. This done from new TCSR driver. * Added defines for register bits * XO clk is optional on some platforms. Corrected logic to handle this. * Ignore set_voltage failures. This allows us to support dummy regulators on platforms where there is no voltage control. * Reworked devicetree binding to remove TCSR reg resources Changes since v5: * devicetree bindings descriptions fixes * Fixed NULL pointer dereferences in dev_prink's * Removed extra space in "sleep " clock name Changes since v4: * Substitute references to "wc3" with just "dw" in USB PHY drivers and file names. This is to indicate that the PHY's are DesignWare, but not necessarily related to DWC3 IP core. Changes since v3: * Remove "_clk" suffix from clock names * Clarify required child node for qcom,dwc3 * Fix comments in functions headers * Use dbg instead err in drivers probe functions. Changes since v2: * Several improvements in devicetree bindings description * Disable regulators in glue layer if there is error during ioremap. Changes since first version: * Split devicetree bindings description file to separate patch * Address comments for device bindings description * Fix typo in 'gdsc' requlator name. Andy Gross (1): phy: Add Qualcomm DWC3 HS/SS PHY driver Ivan T. Ivanov (2): usb: dwc3: qcom: Add device tree binding usb: dwc3: Add Qualcomm DWC3 glue layer driver .../devicetree/bindings/phy/qcom-dwc3-usb-phy.txt | 39 ++ .../devicetree/bindings/usb/qcom,dwc3.txt | 66 +++ drivers/phy/Kconfig| 11 + drivers/phy/Makefile |1 + drivers/phy/phy-qcom-dwc3.c| 483 drivers/usb/dwc3/Kconfig |8 + drivers/usb/dwc3/Makefile |1 + drivers/usb/dwc3/dwc3-qcom.c | 131 ++ 8 files changed, 740 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/qcom-dwc3-usb-phy.txt create mode 100644 Documentation/devicetree/bindings/usb/qcom,dwc3.txt create mode 100644 drivers/phy/phy-qcom-dwc3.c create mode 100644 drivers/usb/dwc3/dwc3-qcom.c -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Patch v9 3/3] phy: Add Qualcomm DWC3 HS/SS PHY driver
This patch adds a new driver for the Qualcomm USB 3.0 PHY that exists on some Qualcomm platforms. This driver uses the generic PHY framework and will interact with the DWC3 controller. Signed-off-by: Andy Gross --- drivers/phy/Kconfig | 11 + drivers/phy/Makefile|1 + drivers/phy/phy-qcom-dwc3.c | 483 +++ 3 files changed, 495 insertions(+) create mode 100644 drivers/phy/phy-qcom-dwc3.c diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index 0dd7427..5d56161 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -230,4 +230,15 @@ config PHY_XGENE help This option enables support for APM X-Gene SoC multi-purpose PHY. +config PHY_QCOM_DWC3 + tristate "QCOM DWC3 USB PHY support" + depends on ARCH_QCOM + depends on HAS_IOMEM + depends on OF + select GENERIC_PHY + help + This option enables support for the Synopsis PHYs present inside the + Qualcomm USB3.0 DWC3 controller. This driver supports both HS and SS + PHY controllers. + endmenu diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile index 95c69ed..aa16f30 100644 --- a/drivers/phy/Makefile +++ b/drivers/phy/Makefile @@ -28,3 +28,4 @@ obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA) += phy-qcom-ipq806x-sata.o obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY) += phy-spear1310-miphy.o obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o obj-$(CONFIG_PHY_XGENE)+= phy-xgene.o +obj-$(CONFIG_PHY_QCOM_DWC3)+= phy-qcom-dwc3.o diff --git a/drivers/phy/phy-qcom-dwc3.c b/drivers/phy/phy-qcom-dwc3.c new file mode 100644 index 000..2c7b316 --- /dev/null +++ b/drivers/phy/phy-qcom-dwc3.c @@ -0,0 +1,483 @@ +/* Copyright (c) 2013-2014, Code Aurora Forum. All rights reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 and + * only version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +/** + * USB QSCRATCH Hardware registers + */ +#define QSCRATCH_GENERAL_CFG (0x08) +#define HSUSB_PHY_CTRL_REG (0x10) + +/* PHY_CTRL_REG */ +#define HSUSB_CTRL_DMSEHV_CLAMPBIT(24) +#define HSUSB_CTRL_USB2_SUSPENDBIT(23) +#define HSUSB_CTRL_UTMI_CLK_EN BIT(21) +#defineHSUSB_CTRL_UTMI_OTG_VBUS_VALID BIT(20) +#define HSUSB_CTRL_USE_CLKCORE BIT(18) +#define HSUSB_CTRL_DPSEHV_CLAMPBIT(17) +#define HSUSB_CTRL_COMMONONN BIT(11) +#define HSUSB_CTRL_ID_HV_CLAMP BIT(9) +#define HSUSB_CTRL_OTGSESSVLD_CLAMPBIT(8) +#define HSUSB_CTRL_CLAMP_ENBIT(7) +#define HSUSB_CTRL_RETENABLEN BIT(1) +#define HSUSB_CTRL_POR BIT(0) + +/* QSCRATCH_GENERAL_CFG */ +#define HSUSB_GCFG_XHCI_REVBIT(2) + +/** + * USB QSCRATCH Hardware registers + */ +#define SSUSB_PHY_CTRL_REG (0x00) +#define SSUSB_PHY_PARAM_CTRL_1 (0x04) +#define SSUSB_PHY_PARAM_CTRL_2 (0x08) +#define CR_PROTOCOL_DATA_IN_REG(0x0c) +#define CR_PROTOCOL_DATA_OUT_REG (0x10) +#define CR_PROTOCOL_CAP_ADDR_REG (0x14) +#define CR_PROTOCOL_CAP_DATA_REG (0x18) +#define CR_PROTOCOL_READ_REG (0x1c) +#define CR_PROTOCOL_WRITE_REG (0x20) + +/* PHY_CTRL_REG */ +#define SSUSB_CTRL_REF_USE_PAD BIT(28) +#define SSUSB_CTRL_TEST_POWERDOWN BIT(27) +#define SSUSB_CTRL_LANE0_PWR_PRESENT BIT(24) +#define SSUSB_CTRL_SS_PHY_EN BIT(8) +#define SSUSB_CTRL_SS_PHY_RESETBIT(7) + +/* SSPHY control registers */ +#define SSPHY_CTRL_RX_OVRD_IN_HI(lane) (0x1006 + 0x100 * lane) +#define SSPHY_CTRL_TX_OVRD_DRV_LO(lane)(0x1002 + 0x100 * lane) + +/* RX OVRD IN HI bits */ +#define RX_OVRD_IN_HI_RX_RESET_OVRDBIT(13) +#define RX_OVRD_IN_HI_RX_RX_RESET BIT(12) +#define RX_OVRD_IN_HI_RX_EQ_OVRD BIT(11) +#define RX_OVRD_IN_HI_RX_EQ_MASK 0x0700 +#define RX_OVRD_IN_HI_RX_EQ_SHIFT 8 +#define RX_OVRD_IN_HI_RX_EQ_EN_OVRDBIT(7) +#define RX_OVRD_IN_HI_RX_EQ_EN BIT(6) +#define RX_OVRD_IN_HI_RX_LOS_FILTER_OVRD BIT(5) +#define RX_OVRD_IN_HI_RX_LOS_FILTER_MASK 0x0018 +#define RX_OVRD_IN_HI_RX_RATE_OVRD BIT(2) +#define RX_OVRD_IN_HI_RX_RATE_MASK 0x0003 + +/* TX OVRD DRV LO register bits */ +#define TX_OVRD_DRV_LO_AMPLITUDE_MASK 0x007F +#define
[Patch v9 2/3] usb: dwc3: Add Qualcomm DWC3 glue layer driver
From: "Ivan T. Ivanov"
DWC3 glue layer is hardware layer around Synopsys DesignWare
USB3 core. Its purpose is to supply Synopsys IP with required
clocks, voltages and interface it with the rest of the SoC.
Signed-off-by: Ivan T. Ivanov
Signed-off-by: Andy Gross
---
drivers/usb/dwc3/Kconfig |8 +++
drivers/usb/dwc3/Makefile|1 +
drivers/usb/dwc3/dwc3-qcom.c | 131 ++
3 files changed, 140 insertions(+)
create mode 100644 drivers/usb/dwc3/dwc3-qcom.c
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 785510a..a816fe4 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -80,6 +80,14 @@ config USB_DWC3_KEYSTONE
Support of USB2/3 functionality in TI Keystone2 platforms.
Say 'Y' or 'M' here if you have one such device
+config USB_DWC3_QCOM
+ tristate "Qualcomm Platforms"
+ depends on ARCH_QCOM || COMPILE_TEST
+ default USB_DWC3
+ help
+ Recent Qualcomm SoCs ship with one DesignWare Core USB3 IP inside,
+ say 'Y' or 'M' if you have one such device.
+
comment "Debugging features"
config USB_DWC3_DEBUG
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index 10ac3e7..0da8e75 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -33,3 +33,4 @@ obj-$(CONFIG_USB_DWC3_OMAP) += dwc3-omap.o
obj-$(CONFIG_USB_DWC3_EXYNOS) += dwc3-exynos.o
obj-$(CONFIG_USB_DWC3_PCI) += dwc3-pci.o
obj-$(CONFIG_USB_DWC3_KEYSTONE)+= dwc3-keystone.o
+obj-$(CONFIG_USB_DWC3_QCOM)+= dwc3-qcom.o
diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
new file mode 100644
index 000..f255335
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-qcom.c
@@ -0,0 +1,131 @@
+/* Copyright (c) 2013-2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct dwc3_qcom {
+ struct device *dev;
+
+ struct clk *core_clk;
+ struct clk *iface_clk;
+ struct clk *sleep_clk;
+};
+
+static int dwc3_qcom_probe(struct platform_device *pdev)
+{
+ struct device_node *node = pdev->dev.of_node;
+ struct dwc3_qcom *qdwc;
+ int ret = 0;
+
+ qdwc = devm_kzalloc(>dev, sizeof(*qdwc), GFP_KERNEL);
+ if (!qdwc)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, qdwc);
+
+ qdwc->dev = >dev;
+
+ qdwc->core_clk = devm_clk_get(qdwc->dev, "core");
+ if (IS_ERR(qdwc->core_clk)) {
+ dev_err(qdwc->dev, "failed to get core clock\n");
+ return PTR_ERR(qdwc->core_clk);
+ }
+
+ qdwc->iface_clk = devm_clk_get(qdwc->dev, "iface");
+ if (IS_ERR(qdwc->iface_clk)) {
+ dev_dbg(qdwc->dev, "failed to get optional iface clock\n");
+ qdwc->iface_clk = NULL;
+ }
+
+ qdwc->sleep_clk = devm_clk_get(qdwc->dev, "sleep");
+ if (IS_ERR(qdwc->sleep_clk)) {
+ dev_dbg(qdwc->dev, "failed to get optional sleep clock\n");
+ qdwc->sleep_clk = NULL;
+ }
+
+ ret = clk_prepare_enable(qdwc->core_clk);
+ if (ret) {
+ dev_err(qdwc->dev, "failed to enable core clock\n");
+ goto err_core;
+ }
+
+ ret = clk_prepare_enable(qdwc->iface_clk);
+ if (ret) {
+ dev_err(qdwc->dev, "failed to enable optional iface clock\n");
+ goto err_iface;
+ }
+
+ ret = clk_prepare_enable(qdwc->sleep_clk);
+ if (ret) {
+ dev_err(qdwc->dev, "failed to enable optional sleep clock\n");
+ goto err_sleep;
+ }
+
+ ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
+ if (ret) {
+ dev_err(qdwc->dev, "failed to register core - %d\n", ret);
+ goto err_clks;
+ }
+
+ return 0;
+
+err_clks:
+ clk_disable_unprepare(qdwc->sleep_clk);
+err_sleep:
+ clk_disable_unprepare(qdwc->iface_clk);
+err_iface:
+ clk_disable_unprepare(qdwc->core_clk);
+err_core:
+ return ret;
+}
+
+static int dwc3_qcom_remove(struct platform_device *pdev)
+{
+ struct dwc3_qcom *qdwc = platform_get_drvdata(pdev);
+
+ of_platform_depopulate(>dev);
+
+ clk_disable_unprepare(qdwc->sleep_clk);
+ clk_disable_unprepare(qdwc->iface_clk);
+ clk_disable_unprepare(qdwc->core_clk);
+
+
Re: [PATCH 0/3 v3] mmu_notifier: Allow to manage CPU external TLBs
On Fri, 12 Sep 2014 15:21:01 -0400 Jerome Glisse wrote: > > > I think this sumup all motivation behind this patchset and also behind > > > my other patchset. As usual i am happy to discuss alternative way to do > > > things but i think that the path of least disruption from current code > > > is the one implemented by those patchset. > > > > "least disruption" is nice, but "good implementation" is better. In > > other words I'd prefer the more complex implementation if the end > > result is better. Depending on the magnitudes of "complex" and > > "better" :) Two years from now (which isn't very long), I don't think > > we'll regret having chosen the better implementation. > > > > Does this patchset make compromises to achieve low disruption? > > Well right now i think we are lacking proper userspace support with which > this code and the global new usecase can be stress tested allowing to gather > profiling information. > > I think as a first step we should take this least disruptive path and if > it proove to perform badly then we should work toward possibly more complex > design. Note that only complex design i can think of involve an overhaul of > how process memory management is done and probably linking cpu page table > update with the scheduler to try to hide cost of those update by scheduling > other thread meanwhile. OK. Often I'd resist merging a patchset when we're not sure it will be sufficient. But there are practical advantages to doing so and the present patchset is quite simple. So if we decide to remove it later on the impact will be small. If the patchset made userspace-visible changes then things would be different! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rcu] BUG: unable to handle kernel NULL pointer dereference at 000000da
On Fri, Sep 12, 2014 at 02:19:57PM -0500, Christoph Lameter wrote: > On Fri, 12 Sep 2014, Paul E. McKenney wrote: > > > So, I am not seeing this failure in my testing, but my best guess is > > that the problem is due to the fact that force_quiescent_state() is > > sometimes invoked with preemption enabled, which breaks __this_cpu_read() > > though perhaps with very low probability. The common-case call (from > > __call_rcu_core()) -does- have preemption disabled, in fact, it has > > interrupts disabled. > > How could __this_cpu_read() break in a way that would make a difference to > the code? There was no disabling/enabling of preemption before the patch > and there is nothing like that after the patch. If there was a race then > it still exists. The modification certainly cannot create a race. Excellent question. Yet Fengguang's tests show breakage. Fengguang, any possibility of a false positive here? Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rcu] BUG: unable to handle kernel NULL pointer dereference at 000000da
On Fri, 12 Sep 2014, Paul E. McKenney wrote: > So, I am not seeing this failure in my testing, but my best guess is > that the problem is due to the fact that force_quiescent_state() is > sometimes invoked with preemption enabled, which breaks __this_cpu_read() > though perhaps with very low probability. The common-case call (from > __call_rcu_core()) -does- have preemption disabled, in fact, it has > interrupts disabled. How could __this_cpu_read() break in a way that would make a difference to the code? There was no disabling/enabling of preemption before the patch and there is nothing like that after the patch. If there was a race then it still exists. The modification certainly cannot create a race. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR
On Thu, Sep 04, 2014 at 04:34:43PM -0700, Andy Lutomirski wrote: > On Thu, Sep 4, 2014 at 4:19 PM, Henrique de Moraes Holschuh > wrote: > > On Thu, 04 Sep 2014, H. Peter Anvin wrote: > >> On 09/04/2014 01:11 PM, Henrique de Moraes Holschuh wrote: > >> > I am worried of uncharted territory, here. I'd actually advocate for not > >> > enabling the upper four PAT entries on IA-32 at all, unless Windows 9X / > >> > XP > >> > is using them as well. Is this a real concern, or am I being overly > >> > cautious? > >> > >> It is extremely unlikely that we'd have PAT issues in 32-bit mode and > >> not in 64-bit mode on the same CPU. > > > > Sure, but is it really a good idea to enable this on the *old* non-64-bit > > capable processors (note: I don't mean x86-64 processors operating in 32-bit > > mode) ? > > > >> As far as I know, the current blacklist rule is very conservative due to > >> lack of testing more than anything else. > > > > I was told that much in 2009 when I asked why cpuid 0x6d8 was blacklisted > > from using PAT :-) > > At the very least, anyone who plugs an NV-DIMM into a 32-bit machine > is nuts, and not just because I'd be somewhat amazed if it even > physically fits into the slot. :) They do have PCIe to PCI adapters, so you _could_ do it :-) > > --Andy > > > > > -- > > "One disk to rule them all, One disk to find them. One disk to bring > > them all and in the darkness grind them. In the Land of Redmond > > where the shadows lie." -- The Silicon Valley Tarot > > Henrique Holschuh > > > > -- > Andy Lutomirski > AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] xen/blkback: unmap all persistent grants when frontend gets disconnected
On Mon, Sep 08, 2014 at 03:21:33PM +0200, Vitaly Kuznetsov wrote: > blkback does not unmap persistent grants when frontend goes to Closed > state (e.g. when blkfront module is being removed). This leads to the > following in guest's dmesg: > > [ 343.243825] xen:grant_table: WARNING: g.e. 0x445 still in use! > [ 343.243825] xen:grant_table: WARNING: g.e. 0x42a still in use! > ... > > When load module -> use device -> unload module sequence is performed > multiple times > it is possible to hit BUG() condition in blkfront module: > > [ 343.243825] kernel BUG at drivers/block/xen-blkfront.c:954! > [ 343.243825] invalid opcode: [#1] SMP > [ 343.243825] Modules linked in: xen_blkfront(-) ata_generic pata_acpi [last > unloaded: xen_blkfront] > ... > [ 343.243825] Call Trace: > [ 343.243825] [] ? unregister_xenbus_watch+0x16f/0x1e0 > [ 343.243825] [] blkfront_remove+0x3f/0x140 [xen_blkfront] > ... > [ 343.243825] RIP [] blkif_free+0x34e/0x360 [xen_blkfront] > [ 343.243825] RSP > > We don't need to keep these grants if we're disconnecting as frontend might > already > forgot about them. Solve the issue by moving xen_blkbk_free_caches() call from > xen_blkif_free() to xen_blkif_disconnect(). > > Now we can see the following: > [ 928.590893] xen:grant_table: WARNING: g.e. 0x587 still in use! > [ 928.591861] xen:grant_table: WARNING: g.e. 0x372 still in use! > ... > [ 929.592146] xen:grant_table: freeing g.e. 0x587 > [ 929.597174] xen:grant_table: freeing g.e. 0x372 > ... > > Backend does not keep persistent grants any more, reconnect works fine. Reviewed-by: Konrad Rzeszutek Wilk David, I usually combine the 'block' related patches in one branch and send them to Jens for the merge window. Want to do it the same way or do you want to alter the workflow? > > Signed-off-by: Vitaly Kuznetsov > --- > drivers/block/xen-blkback/xenbus.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/block/xen-blkback/xenbus.c > b/drivers/block/xen-blkback/xenbus.c > index 3a8b810..54f4089 100644 > --- a/drivers/block/xen-blkback/xenbus.c > +++ b/drivers/block/xen-blkback/xenbus.c > @@ -270,6 +270,9 @@ static int xen_blkif_disconnect(struct xen_blkif *blkif) > blkif->blk_rings.common.sring = NULL; > } > > + /* Remove all persistent grants and the cache of ballooned pages. */ > + xen_blkbk_free_caches(blkif); > + > return 0; > } > > @@ -281,9 +284,6 @@ static void xen_blkif_free(struct xen_blkif *blkif) > xen_blkif_disconnect(blkif); > xen_vbd_free(>vbd); > > - /* Remove all persistent grants and the cache of ballooned pages. */ > - xen_blkbk_free_caches(blkif); > - > /* Make sure everything is drained before shutting down */ > BUG_ON(blkif->persistent_gnt_c != 0); > BUG_ON(atomic_read(>persistent_gnt_in_use) != 0); > -- > 1.9.3 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 00/10] Intel MPX support
On Thu, 11 Sep 2014, Dave Hansen wrote: > On 09/11/2014 01:46 AM, Qiaowei Ren wrote: > > MPX kernel code, namely this patchset, has mainly the 2 responsibilities: > > provide handlers for bounds faults (#BR), and manage bounds memory. > > Qiaowei, We probably need to mention here what "bounds memory" is, and > why it has to be managed, and who is responsible for the different pieces. > > Who allocates the memory? > Who fills the memory? > When is it freed? > > Thomas, do you have any other suggestions for things you'd like to see > clarified? Yes, the most important question is WHY must the kernel handle the bound table memory allocation in the first place. The "documentation" patch completely fails to tell that. > +3. Tips > +=== > + > +1) Users are not allowed to create bounds tables and point the bounds > +directory at them in the userspace. In fact, it is not also necessary > +for users to create bounds tables in the userspace. This misses to explain why. I studied the manual carefully and I have no idea why you think this is a requirement. MPX can be handled completely from user space. See below before you answer. > +When #BR fault is produced due to invalid entry, bounds table will be > +created in kernel on demand and kernel will not transfer this fault to > +userspace. So usersapce can't receive #BR fault for invalid entry, and > +it is not also necessary for users to create bounds tables by themselves. > + > +Certainly users can allocate bounds tables and forcibly point the bounds > +directory at them through XSAVE instruction, and then set valid bit > +of bounds entry to have this entry valid. But we have no way to track > +the memory usage of these user-created bounds tables. In regard to this, > +this behaviour is outlawed here. So what's the point of declaring it outlawed? Nothing as far as I can see simply because you cannot enforce it. This is possible and people simply will do it. > +2) We will not support the case that multiple bounds directory entries > +are pointed at the same bounds table. > + > +Users can be allowed to take multiple bounds directory entries and point > +them at the same bounds table. See more information "Intel(R) Architecture > +Instruction Set Extensions Programming Reference" (9.3.4). > + > +If userspace did this, it will be possible for kernel to unmap an in-use > +bounds table since it does not recognize sharing. So this behavior is > +also outlawed here. Again, this is nothing you can enforce and just saying its outlawed does not prevent user space from doing it and then sending hard to decode bug reports where it complains about mappings silently vanishing under it. So all you can do here is to write up a rule set how well behaving user space is supposed to use this facility and the kernel side of it. Now back to the original question WHY: The only kind of "argument" you provided in the whole blurb is "if user space handles the allocation we have no way to track the memory usage of these tables". So if the only value of this whole allocation endavour is that we have a separate "name" entry in proc/$PID/maps then this definitely does not justify the mess it creates. You'd be better off with creating a syscall which allows putting a name tag on a anonymous mapping. Seriously, that would be handy for other purposes than MPX as well. But after staring into the manual and the code trainwreck for a day, I certainly know WHY you want to handle it in kernel space. If user space wants to handle it, it needs to preallocate all the Bound Table mappings simply because it cannot do so from the signal handler which gets invoked on the #BR 'Invalid BD entry'. mmap is not on the list of safe async handler functions and even if mmap would work it still requires locking or nasty tricks to keep track of the allocation state there. Preallocation is simply not feasible, because user space does not know about the requirements of libraries etc. So letting the kernel help out here is the right approach. All that information is completely missing in the "doc" and all over the patch series. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3 v3] mmu_notifier: Allow to manage CPU external TLBs
On Fri, Sep 12, 2014 at 12:10:36PM -0700, Andrew Morton wrote: > On Wed, 10 Sep 2014 20:02:12 -0400 Jerome Glisse wrote: > > > On Wed, Sep 10, 2014 at 03:01:25PM -0700, Andrew Morton wrote: > > > On Tue, 9 Sep 2014 17:43:51 +0200 Joerg Roedel wrote: > > > > > > > here is a patch-set to extend the mmu_notifiers in the Linux > > > > kernel to allow managing CPU external TLBs. Those TLBs may > > > > be implemented in IOMMUs or any other external device, e.g. > > > > ATS/PRI capable PCI devices. > > > > > > > > The problem with managing these TLBs are the semantics of > > > > the invalidate_range_start/end call-backs currently > > > > available. Currently the subsystem using mmu_notifiers has > > > > to guarantee that no new TLB entries are established between > > > > invalidate_range_start/end. Furthermore the > > > > invalidate_range_start() function is called when all pages > > > > are still mapped and invalidate_range_end() when the pages > > > > are unmapped an already freed. > > > > > > > > So both call-backs can't be used to safely flush any non-CPU > > > > TLB because _start() is called too early and _end() too > > > > late. > > > > > > There's a lot of missing information here. Why don't the existing > > > callbacks suit non-CPU TLBs? What is different about them? Please > > > update the changelog to contain all this context. > > > > So unlike KVM or any current user of the mmu_notifier api, any PCIE > > ATS/PASID capable hardware IOMMUv2 for AMD and forgot the marketing > > name for Intel (probably VTd) implementation walk the cpu page table > > on there own and have there own TLB cache. In fact not only the iommu > > can have a TLB cache but any single PCIE hardware can implement its > > own local TLB cache. > > > > So if we flush the IOMMU and device TLB inside the range_start callback > > there is a chance that the hw will just rewalk the cpu page table and > > repopulate its TLB before the CPU page table is actually updated. > > > > Now if we shoot down the TLB inside the range_end callback, then we > > are too late ie the CPU page table is already populated with new entry > > and all the TLB in the IOMMU an in device might be pointing to the old > > pages. > > > > So the aim of this callback is to happen right after the CPU page table > > is updated but before the old page is freed or recycled. > > You had me up to here. What is "the old page"? pagetable page, I > assume? upper, middle, lower, all the above? Why does the callback > function need to get at that page? No old page is not a page from the cpu page table directory free but a page that use to belong to the process ie a page that was backing an address range of the process we are interested in. The kernel flush the cpu tlb and then free those pages before calling the mmu_notifier end callback (for good reasons). So we want to flush the hardware TLB (whish is distinc from CPU TLB) before any of the page that use to be valid page backing address range of the process are freed or recycle. Sorry for the confusion my wording caused. > > > > Also too skimpy. I *think* this is a variant of the problem in the > > > preceding paragraph. We get a fault storm (which is problem 2) and > > > sometimes the faulting device gives up (which is problem 1). > > > > > > Or something. Please de-fog all of this. > > > > > > > Does above explanation help understand the issue ? Given that on each > > device page fault an IRQ is trigger (well the way the hw works is bit > > more complex than that). > > It helps. Please understand that my main aim here is not to ask > specific questions. I seek to demonstrate the level of detail which I > believe should be in the changelog so that others can effectively > understand and review this patchset, and to understand this code in the > future. Totaly agree and i am rooting for better commit message in other kernel component, since i am reviewing more patches in distinct component i now clearly see the value of good and exhaustive commit message. > > So it would be good if you were to update the changelog to answer these > questions. It would be better if it were also to answer similar > questions which I didn't think to ask! > > > > > Furthermore the _start()/end() notifiers only catch the > > > > moment when page mappings are released, but not page-table > > > > pages. But this is necessary for managing external TLBs when > > > > the page-table is shared with the CPU. > > > > > > How come? > > > > As explained above end() might happens after page that were previously > > mapped are free or recycled. > > Again, some explanation of why the driver wishes to inspect the > pagetable pages would be useful. > > > > > > > > To solve this situation I wrote a patch-set to introduce a > > > > new notifier call-back: mmu_notifer_invalidate_range(). This > > > > notifier lifts the strict requirements that no new > > > > references are taken in the range between _start() and > > > >
Re: [PATCH 0/3 v3] mmu_notifier: Allow to manage CPU external TLBs
On Fri, 12 Sep 2014 20:47:39 +0200 Joerg Roedel wrote: > thanks for your review, I tried to answer your questions below. You'd be amazed how helpful that was ;) > Fair enough, I hope I clarified a few things with my explanations > above. I will also update the description of the patch-set when I > re-send. Sounds good, thanks. How does HMM play into all of this? Would HMM make this patchset obsolete, or could HMM be evolved to do so? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] Block updates for 3.17-rc
Hi Linus, A small collection of fixes for the current rc series. It contains: - Two small blk-mq patches from Rob Elliott, cleaning up error case at init time. - A fix from Ming Lei, fixing SG merging for blk-mq where QUEUE_FLAG_SG_NO_MERGE is the default. - A dev_t minor lifetime fix from Keith, fixing an issue where a minor might be reused before all references to it were gone. - Fix from Alan Stern where an unbalanced queue bypass caused SCSI some headaches when it does a series of add/del on devices without fully registrering the queue. - A fix from me for improving the scaling of tag depth in blk-mq if we are short on memory. Please pull! git://git.kernel.dk/linux-block.git for-linus for you to fetch changes up to a516440542afcb9647f88d12c35640baf02d07ea: blk-mq: scale depth and rq map appropriate if low on memory (2014-09-10 09:02:03 -0600) Alan Stern (1): Block: fix unbalanced bypass-disable in blk_register_queue Jens Axboe (1): blk-mq: scale depth and rq map appropriate if low on memory Keith Busch (1): block: Fix dev_t minor allocation lifetime Ming Lei (1): blk-merge: fix blk_recount_segments Robert Elliott (2): blk-mq: pass along blk_mq_alloc_tag_set return values blk-mq: cleanup after blk_mq_init_rq_map failures block/blk-merge.c | 17 +--- block/blk-mq.c| 91 +++ block/blk-sysfs.c | 6 ++- block/genhd.c | 24 ++- block/partition-generic.c | 2 +- drivers/block/mtip32xx/mtip32xx.c | 1 - drivers/block/null_blk.c | 29 + 7 files changed, 123 insertions(+), 47 deletions(-) -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/5] Initial support for XPowers AXP288 PMIC
On Thu, Sep 11, 2014 at 04:15:52PM -0700, Jacob Pan wrote: > XPowers AXP288 is a customized PMIC found on some Intel Baytrail-CR platforms. > It comes with sub-functions such as USB charging, fuel gauge, ADC, and many > LDO > and BUCK channels. > > By extending the existing AXP20x driver, this patchset adds basic support > for AXP288 PMIC with GPADC as one MFD cell device driver. It also adds hooks > for ACPI opregion handler driver which can be used to handle ACPI requests. > > Currently, the PMIC driver in this patchset does not support platform data > enumeration. But when ACPI _DSD and unified device properties become > available, > cell devices with platform data will be added. > > This patch does not use intel_soc_pmic core for i2c and regmap handling in > that > axp288 shares similar programming interface with other Xpower PMICs supported > in > axp20x.c. Therefore, extending axp20x.c to include axp288 makes more sense. > > Changes > v3: - put all file rename changes in 1/5 The variables renaming are still not in 1/5 -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH V3 3/3] Support Xen pv-domains using PAT
On Fri, Sep 12, 2014 at 12:35:12PM +0200, Juergen Gross wrote:
> With the dynamical mapping between cache modes and pgprot values it is
> now possible to use all cache modes via the Xen hypervisor PAT settings
> in a pv domain.
>
> All to be done is to read the PAT configuration MSR and set up the
> translation tables accordingly.
>
> Signed-off-by: Juergen Gross
> Reviewed-by: David Vrabel
Reviewed-by: Konrad Rzeszutek Wilk
> ---
> arch/x86/xen/enlighten.c | 25 +++--
> arch/x86/xen/mmu.c | 48
> ++--
> arch/x86/xen/xen-ops.h | 1 -
> 3 files changed, 9 insertions(+), 65 deletions(-)
Oh yeah! That is nice to see :-)
>
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index c0cb11f..75ac572 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -1100,12 +1100,6 @@ static int xen_write_msr_safe(unsigned int msr,
> unsigned low, unsigned high)
> /* Fast syscall setup is all done in hypercalls, so
> these are all ignored. Stub them out here to stop
> Xen console noise. */
> - break;
> -
> - case MSR_IA32_CR_PAT:
> - if (smp_processor_id() == 0)
> - xen_set_pat(((u64)high << 32) | low);
> - break;
>
> default:
> ret = native_write_msr_safe(msr, low, high);
> @@ -1554,10 +1548,6 @@ asmlinkage __visible void __init xen_start_kernel(void)
>
> /* Prevent unwanted bits from being set in PTEs. */
> __supported_pte_mask &= ~_PAGE_GLOBAL;
> -#if 0
> - if (!xen_initial_domain())
> -#endif
> - __supported_pte_mask &= ~(_PAGE_PWT | _PAGE_PCD);
>
> __supported_pte_mask |= _PAGE_IOMAP;
>
> @@ -1613,14 +1603,6 @@ asmlinkage __visible void __init xen_start_kernel(void)
>*/
> acpi_numa = -1;
> #endif
> -#ifdef CONFIG_X86_PAT
> - /*
> - * For right now disable the PAT. We should remove this once
> - * git commit 8eaffa67b43e99ae581622c5133e20b0f48bcef1
> - * (xen/pat: Disable PAT support for now) is reverted.
> - */
> - pat_enabled = 0;
> -#endif
> /* Don't do the full vcpu_info placement stuff until we have a
> possible map and a non-dummy shared_info. */
> per_cpu(xen_vcpu, 0) = _shared_info->vcpu_info[0];
> @@ -1634,6 +1616,13 @@ asmlinkage __visible void __init xen_start_kernel(void)
> /* Allocate and initialize top and mid mfn levels for p2m structure */
> xen_build_mfn_list_list();
>
> + /*
> + * Modify the cache mode translation tables to match Xen's PAT
> + * configuration.
> + */
> +
> + pat_init_cache_modes();
> +
> /* keep using Xen gdt for now; no urgent need to change it */
>
> #ifdef CONFIG_X86_32
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index e8a1201..70702e9 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -434,13 +434,7 @@ static pteval_t iomap_pte(pteval_t val)
> __visible pteval_t xen_pte_val(pte_t pte)
> {
> pteval_t pteval = pte.pte;
> -#if 0
> - /* If this is a WC pte, convert back from Xen WC to Linux WC */
> - if ((pteval & (_PAGE_PAT | _PAGE_PCD | _PAGE_PWT)) == _PAGE_PAT) {
> - WARN_ON(!pat_enabled);
> - pteval = (pteval & ~_PAGE_PAT) | _PAGE_PWT;
> - }
> -#endif
> +
> if (xen_initial_domain() && (pteval & _PAGE_IOMAP))
> return pteval;
>
> @@ -454,48 +448,10 @@ __visible pgdval_t xen_pgd_val(pgd_t pgd)
> }
> PV_CALLEE_SAVE_REGS_THUNK(xen_pgd_val);
>
> -/*
> - * Xen's PAT setup is part of its ABI, though I assume entries 6 & 7
> - * are reserved for now, to correspond to the Intel-reserved PAT
> - * types.
> - *
> - * We expect Linux's PAT set as follows:
> - *
> - * Idx PTE flagsLinuxXenDefault
> - * 0 WB WB WB
> - * 1PWT WC WT WT
> - * 2PCD UC- UC-UC-
> - * 3PCD PWT UC UC UC
> - * 4PAT WB WC WB
> - * 5PAT PWT WC WP WT
> - * 6PAT PCD UC- rsvUC-
> - * 7PAT PCD PWT UC rsvUC
> - */
> -
> -void xen_set_pat(u64 pat)
> -{
> - /* We expect Linux to use a PAT setting of
> - * UC UC- WC WB (ignoring the PAT flag) */
> - WARN_ON(pat != 0x0007010600070106ull);
> -}
> -
> __visible pte_t xen_make_pte(pteval_t pte)
> {
> phys_addr_t addr = (pte & PTE_PFN_MASK);
> -#if 0
> - /* If Linux is trying to set a WC pte, then map to the Xen WC.
> - * If _PAGE_PAT is set, then it probably means it is really
> - * _PAGE_PSE, so avoid fiddling with the PAT mapping and hope
> - * things work out OK...
> - *
> - * (We should never see kernel mappings with _PAGE_PSE set,
> - * but we could see hugetlbfs mappings, I think.).
> - */
> - if (pat_enabled
Re: [PATCH V3 1/3] x86: Make page cache mode a real type
On Fri, Sep 12, 2014 at 12:35:10PM +0200, Juergen Gross wrote:
> At the moment there are a lot of places that handle setting or getting
> the page cache mode by treating the pgprot bits equal to the cache mode.
> This is only true because there are a lot of assumptions about the setup
> of the PAT MSR. Otherwise the cache type needs to get translated into
> pgprot bits and vice versa.
>
> This patch tries to prepare for that by introducing a seperate type
> for the cache mode and adding functions to translate between those and
> pgprot values.
>
> To avoid too much performance penalty the translation between cache mode
> and pgprot values is done via tables which contain the relevant
> information. Write-back cache mode is hard-wired to be 0, all other
> modes are configurable via those tables. For large pages there are
> translation functions as the PAT bit is located at different positions
> in the ptes of 4k and large pages.
>
> Signed-off-by: Stefan Bader
> Signed-off-by: Juergen Gross
> Reviewed-by: Toshi Kani
Reviewed-by: Konrad Rzeszutek Wilk
with some comments below.
> ---
> arch/x86/include/asm/cacheflush.h | 38 +
> arch/x86/include/asm/fb.h | 6 +-
> arch/x86/include/asm/io.h | 2 +-
> arch/x86/include/asm/pat.h| 6 +-
> arch/x86/include/asm/pgtable.h| 19 ++---
> arch/x86/include/asm/pgtable_types.h | 92 +-
> arch/x86/mm/dump_pagetables.c | 24 +++---
> arch/x86/mm/init.c| 29 +++
> arch/x86/mm/init_64.c | 9 ++-
> arch/x86/mm/iomap_32.c| 15 ++--
> arch/x86/mm/ioremap.c | 63 ---
> arch/x86/mm/pageattr.c| 84
> arch/x86/mm/pat.c | 126
> +++---
> arch/x86/mm/pat_internal.h| 22 +++---
> arch/x86/mm/pat_rbtree.c | 8 +-
> arch/x86/pci/i386.c | 4 +-
> drivers/video/fbdev/gbefb.c | 3 +-
> drivers/video/fbdev/vermilion/vermilion.c | 6 +-
> 18 files changed, 344 insertions(+), 212 deletions(-)
>
> diff --git a/arch/x86/include/asm/cacheflush.h
> b/arch/x86/include/asm/cacheflush.h
> index 9863ee3..157644b 100644
> --- a/arch/x86/include/asm/cacheflush.h
> +++ b/arch/x86/include/asm/cacheflush.h
> @@ -9,10 +9,10 @@
> /*
> * X86 PAT uses page flags WC and Uncached together to keep track of
> * memory type of pages that have backing page struct. X86 PAT supports 3
> - * different memory types, _PAGE_CACHE_WB, _PAGE_CACHE_WC and
> - * _PAGE_CACHE_UC_MINUS and fourth state where page's memory type has not
> + * different memory types, _PAGE_CACHE_MODE_WB, _PAGE_CACHE_MODE_WC and
> + * _PAGE_CACHE_MODE_UC_MINUS and fourth state where page's memory type has
> not
> * been changed from its default (value of -1 used to denote this).
> - * Note we do not support _PAGE_CACHE_UC here.
> + * Note we do not support _PAGE_CACHE_MODE_UC here.
> */
>
> #define _PGMT_DEFAULT0
> @@ -22,36 +22,40 @@
> #define _PGMT_MASK (1UL << PG_uncached | 1UL << PG_arch_1)
> #define _PGMT_CLEAR_MASK (~_PGMT_MASK)
>
> -static inline unsigned long get_page_memtype(struct page *pg)
> +static inline enum page_cache_mode get_page_memtype(struct page *pg)
> {
> unsigned long pg_flags = pg->flags & _PGMT_MASK;
>
> if (pg_flags == _PGMT_DEFAULT)
> return -1;
> else if (pg_flags == _PGMT_WC)
> - return _PAGE_CACHE_WC;
> + return _PAGE_CACHE_MODE_WC;
> else if (pg_flags == _PGMT_UC_MINUS)
> - return _PAGE_CACHE_UC_MINUS;
> + return _PAGE_CACHE_MODE_UC_MINUS;
> else
> - return _PAGE_CACHE_WB;
> + return _PAGE_CACHE_MODE_WB;
> }
>
> -static inline void set_page_memtype(struct page *pg, unsigned long memtype)
> +static inline void set_page_memtype(struct page *pg,
> + enum page_cache_mode memtype)
> {
> - unsigned long memtype_flags = _PGMT_DEFAULT;
> + unsigned long memtype_flags;
> unsigned long old_flags;
> unsigned long new_flags;
>
> switch (memtype) {
> - case _PAGE_CACHE_WC:
> + case _PAGE_CACHE_MODE_WC:
> memtype_flags = _PGMT_WC;
> break;
> - case _PAGE_CACHE_UC_MINUS:
> + case _PAGE_CACHE_MODE_UC_MINUS:
> memtype_flags = _PGMT_UC_MINUS;
> break;
> - case _PAGE_CACHE_WB:
> + case _PAGE_CACHE_MODE_WB:
> memtype_flags = _PGMT_WB;
> break;
> + default:
> + memtype_flags = _PGMT_DEFAULT;
> + break;
> }
>
> do {
> @@ -60,8 +64,14 @@ static inline void set_page_memtype(struct page *pg,
> unsigned long memtype)
> } while (cmpxchg(>flags, old_flags,
Re: [PATCH 3/9] locktorture: Support mutexes
On Fri, Sep 12, 2014 at 11:56:31AM -0700, Davidlohr Bueso wrote:
> On Fri, 2014-09-12 at 11:02 -0700, Paul E. McKenney wrote:
> > On Thu, Sep 11, 2014 at 08:40:18PM -0700, Davidlohr Bueso wrote:
> > > +static void torture_mutex_delay(struct torture_random_state *trsp)
> > > +{
> > > + const unsigned long longdelay_ms = 100;
> > > +
> > > + /* We want a long delay occasionally to force massive contention. */
> > > + if (!(torture_random(trsp) %
> > > + (nrealwriters_stress * 2000 * longdelay_ms)))
> > > + mdelay(longdelay_ms * 5);
> >
> > So let's see... We wait 500 milliseconds about once per 200,000 operations
> > per writer. So if we have 5 writers, we wait 500 milliseconds per million
> > operations. So each writer will do about 200,000 operations, then there
> > will be a half-second gap. But each short operation holds the lock for
> > 20 milliseconds, which takes several hours to work through the million
> > operations.
> >
> > So it looks to me like you are in massive contention state either way,
> > at least until the next stutter interval shows up.
> >
> > Is that the intent? Or am I missing something here?
>
> Ah, nice description. Yes, I am aiming for constant massive contention
> (should have mentioned this, sorry). I believe it stresses the more
> interesting parts of mutexes -- and rwsems, for that matter. If you
> think it's excessive, we could decrease the the large wait and/or
> increase the short one. I used the factor of the delay by the default
> stutter value -- we could also make it always equal.
Don't get me wrong -- I am all for massive contention testing. It is
just that from what I can see, you aren't getting any real additional
benefit out of the 500-millisecond wait. Having even as few as (say)
three tasks each repeatedly acquiring the lock and blocking for 20
milliseconds ("else" clause below) will give you maximal contention.
I cannot see how occasionally blocking for 500 milliseconds can do much
of anything to increase the contention level.
Now if the common case was to acquire and then immediately release the
lock, I could see how throwing in the occasional delay would be very
useful. But for exclusive locks, a few tens of microseconds delay would
probably suffice to give you a maximal contention event. Yes, you do
have a one-jiffy delay in the lock_torture_writer() loop, but it happens
only one loop out of one million -- and if that is what you are worried
about, a two-jiffy delay in the critical section would -guarantee- you
a maximal contention event in most cases.
So my concern is that the large values you have are mostly slowing down
the test and thus reducing its intensity. But again, I could easily be
missing something here.
> > > + else
> > > + mdelay(longdelay_ms / 5);
> > > +#ifdef CONFIG_PREEMPT
> > > + if (!(torture_random(trsp) % (nrealwriters_stress * 2)))
> > > + preempt_schedule(); /* Allow test to be preempted. */
> > > +#endif
> > > +}
> > > +
> > > +static void torture_mutex_unlock(void) __releases(torture_mutex)
> > > +{
> > > + mutex_unlock(_mutex);
> > > +}
> > > +
> > > +static struct lock_torture_ops mutex_lock_ops = {
> > > + .writelock = torture_mutex_lock,
> > > + .write_delay= torture_mutex_delay,
> > > + .writeunlock= torture_mutex_unlock,
> > > + .name = "mutex_lock"
> > > +};
> > > +
> > > /*
> > > * Lock torture writer kthread. Repeatedly acquires and releases
> > > * the lock, checking for duplicate acquisitions.
> > > @@ -352,7 +389,7 @@ static int __init lock_torture_init(void)
> > > int i;
> > > int firsterr = 0;
> > > static struct lock_torture_ops *torture_ops[] = {
> > > - _busted_ops, _lock_ops, _lock_irq_ops,
> > > + _busted_ops, _lock_ops, _lock_irq_ops,
> > > _lock_ops,
> > > };
> > >
> > > if (!torture_init_begin(torture_type, verbose, _runnable))
> > > --
> >
> > And I queued the following patch to catch up the scripting.
>
> Thanks! Completely overlooked the scripting bits. I'll keep it in mind
> in the future.
No problem, and I look forward to also seeing the scripting pieces in
the future. ;-)
Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [REGRESSION] i2c-acpi: Fix NULL Pointer dereference
Am Freitag, 12. September 2014, 21:09:47 schrieb Peter Huewe: > If adapter->dev.parent == NULL there is a NULL pointer dereference in > acpi_i2c_install_space_handler and acpi_i2c_remove_space_handler. > > This is present since introduction of this code: > 366047515c6e "i2c: rework kernel config I2C_ACPI" or even > da3c6647ee08 "I2C/ACPI: Clean up I2C ACPI code and Add CONFIG_I2C_ACPI" > > The adapter->dev.parent == NULL case is valid for the i2c_stub, > so loading i2c_stub with ACPI_I2C_OPREGION enabled results in an oops. > This is also valid at least for i2c_tiny_usb and i2c_robotfuzz_osif. > > Fix by checking whether it is null before calling ACPI_HANDLE. > > Signed-off-by: Peter Huewe > --- Patch against current i2c/master. For those who care - here's the oops: # modprobe i2c_stub chip_addr=0x20 # dmesg [ 39.315090] i2c-stub: Virtual chip at 0x20 [ 39.315149] BUG: unable to handle kernel NULL pointer dereference at 0240 [ 39.317716] IP: [] acpi_i2c_install_space_handler+0x16/0xb2 [ 39.320261] PGD 40db4b067 PUD 40d2bf067 PMD 0 [ 39.322848] Oops: [#1] PREEMPT SMP [ 39.325360] Modules linked in: i2c_stub(+) w83627ehf hwmon_vid ipv6 usbhid snd_hda_codec_hdmi x86_pkg_temp_thermal snd_hda_codec_realtek coretemp snd_hda_codec_generic kvm_intel kvm crc32_pclmul ghash_clmulni_intel snd_hda_intel snd_hda_controller pcspkr snd_hda_codec i2c_i801 snd_hwdep snd_pcm snd_timer snd battery tpm_tis tpm [ 39.330770] CPU: 0 PID: 2783 Comm: modprobe Not tainted 3.17.0-rc4-00131-gd030671 #151 [ 39.333451] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Z77 Pro4, BIOS P1.70 01/17/2013 [ 39.336153] task: 88040e4bd7d0 ti: 88040e60c000 task.ti: 88040e60c000 [ 39.338876] RIP: 0010:[] [] acpi_i2c_install_space_handler+0x16/0xb2 [ 39.341657] RSP: 0018:88040e60fca8 EFLAGS: 00010296 [ 39.344421] RAX: RBX: c099db30 RCX: 88040d8def40 [ 39.347193] RDX: ffed RSI: 8800bff975e0 RDI: c099db30 [ 39.349965] RBP: 88040e60fcc8 R08: 8800bff975e0 R09: 8800bff975e0 [ 39.352742] R10: c099db78 R11: 88040b51c028 R12: c099db78 [ 39.355510] R13: c099db30 R14: R15: c099ded0 [ 39.358275] FS: 7f638fd52700() GS:88041f20() knlGS: [ 39.361008] CS: 0010 DS: ES: CR0: 80050033 [ 39.363681] CR2: 0240 CR3: 00040dbba000 CR4: 001407f0 [ 39.366332] Stack: [ 39.368924] 88040d8def40 c099db30 c099db78 [ 39.371576] 88040e60fcf8 8248e2ee c099db30 0001 [ 39.374216] 82782250 88040e60fd28 8248e424 [ 39.376840] Call Trace: [ 39.379424] [] i2c_register_adapter+0x1bc/0x299 [ 39.382044] [] i2c_add_adapter+0x59/0x60 [ 39.384650] [] i2c_stub_init+0x1b6/0x1d4 [i2c_stub] [ 39.387277] [] ? 0xc09a [ 39.389896] [] ? 0xc09a [ 39.392504] [] do_one_initcall+0xea/0x184 [ 39.395128] [] ? vfree+0x74/0x7b [ 39.397763] [] load_module+0x1b0f/0x1e11 [ 39.397768] [] ? module_unload_free+0xd2/0xd2 [ 39.397773] [] SyS_finit_module+0x56/0x6c [ 39.397779] [] tracesys+0xdd/0xe2 [ 39.397822] Code: 48 c7 c6 37 37 70 82 31 c0 e8 56 66 f5 ff 48 83 c4 18 5b 5d c3 55 ba ed ff ff ff 48 89 e5 41 55 49 89 fd 41 54 53 51 48 8b 47 48 <48> 8b 80 40 02 00 00 48 85 c0 0f 84 82 00 00 00 4c 8b 60 08 4d [ 39.397827] RIP [] acpi_i2c_install_space_handler+0x16/0xb2 [ 39.397828] RSP [ 39.397829] CR2: 0240 [ 39.397863] ---[ end trace 9f55e6ce67fb ]--- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3 v3] mmu_notifier: Allow to manage CPU external TLBs
On Wed, 10 Sep 2014 20:02:12 -0400 Jerome Glisse wrote: > On Wed, Sep 10, 2014 at 03:01:25PM -0700, Andrew Morton wrote: > > On Tue, 9 Sep 2014 17:43:51 +0200 Joerg Roedel wrote: > > > > > here is a patch-set to extend the mmu_notifiers in the Linux > > > kernel to allow managing CPU external TLBs. Those TLBs may > > > be implemented in IOMMUs or any other external device, e.g. > > > ATS/PRI capable PCI devices. > > > > > > The problem with managing these TLBs are the semantics of > > > the invalidate_range_start/end call-backs currently > > > available. Currently the subsystem using mmu_notifiers has > > > to guarantee that no new TLB entries are established between > > > invalidate_range_start/end. Furthermore the > > > invalidate_range_start() function is called when all pages > > > are still mapped and invalidate_range_end() when the pages > > > are unmapped an already freed. > > > > > > So both call-backs can't be used to safely flush any non-CPU > > > TLB because _start() is called too early and _end() too > > > late. > > > > There's a lot of missing information here. Why don't the existing > > callbacks suit non-CPU TLBs? What is different about them? Please > > update the changelog to contain all this context. > > So unlike KVM or any current user of the mmu_notifier api, any PCIE > ATS/PASID capable hardware IOMMUv2 for AMD and forgot the marketing > name for Intel (probably VTd) implementation walk the cpu page table > on there own and have there own TLB cache. In fact not only the iommu > can have a TLB cache but any single PCIE hardware can implement its > own local TLB cache. > > So if we flush the IOMMU and device TLB inside the range_start callback > there is a chance that the hw will just rewalk the cpu page table and > repopulate its TLB before the CPU page table is actually updated. > > Now if we shoot down the TLB inside the range_end callback, then we > are too late ie the CPU page table is already populated with new entry > and all the TLB in the IOMMU an in device might be pointing to the old > pages. > > So the aim of this callback is to happen right after the CPU page table > is updated but before the old page is freed or recycled. You had me up to here. What is "the old page"? pagetable page, I assume? upper, middle, lower, all the above? Why does the callback function need to get at that page? > > Also too skimpy. I *think* this is a variant of the problem in the > > preceding paragraph. We get a fault storm (which is problem 2) and > > sometimes the faulting device gives up (which is problem 1). > > > > Or something. Please de-fog all of this. > > > > Does above explanation help understand the issue ? Given that on each > device page fault an IRQ is trigger (well the way the hw works is bit > more complex than that). It helps. Please understand that my main aim here is not to ask specific questions. I seek to demonstrate the level of detail which I believe should be in the changelog so that others can effectively understand and review this patchset, and to understand this code in the future. So it would be good if you were to update the changelog to answer these questions. It would be better if it were also to answer similar questions which I didn't think to ask! > > > Furthermore the _start()/end() notifiers only catch the > > > moment when page mappings are released, but not page-table > > > pages. But this is necessary for managing external TLBs when > > > the page-table is shared with the CPU. > > > > How come? > > As explained above end() might happens after page that were previously > mapped are free or recycled. Again, some explanation of why the driver wishes to inspect the pagetable pages would be useful. > > > > > To solve this situation I wrote a patch-set to introduce a > > > new notifier call-back: mmu_notifer_invalidate_range(). This > > > notifier lifts the strict requirements that no new > > > references are taken in the range between _start() and > > > _end(). When the subsystem can't guarantee that any new > > > references are taken is has to provide the > > > invalidate_range() call-back to clear any new references in > > > there. > > > > > > It is called between invalidate_range_start() and _end() > > > every time the VMM has to wipe out any references to a > > > couple of pages. This are usually the places where the CPU > > > TLBs are flushed too and where its important that this > > > happens before invalidate_range_end() is called. > > > > > > Any comments and review appreciated! > > > > The patchset looks decent, although I find it had to review because I > > just wasn't provided with enough of the thinking that went into it. I > > have enough info to look at the C code, but not enough info to identify > > and evaluate alternative implementation approaches, to identify > > possible future extensions, etc. > > > > The patchset does appear to add significant additional overhead to hot > > code paths when
[PATCH] [REGRESSION] i2c-acpi: Fix NULL Pointer dereference
If adapter->dev.parent == NULL there is a NULL pointer dereference in
acpi_i2c_install_space_handler and acpi_i2c_remove_space_handler.
This is present since introduction of this code:
366047515c6e "i2c: rework kernel config I2C_ACPI" or even
da3c6647ee08 "I2C/ACPI: Clean up I2C ACPI code and Add CONFIG_I2C_ACPI"
The adapter->dev.parent == NULL case is valid for the i2c_stub,
so loading i2c_stub with ACPI_I2C_OPREGION enabled results in an oops.
This is also valid at least for i2c_tiny_usb and i2c_robotfuzz_osif.
Fix by checking whether it is null before calling ACPI_HANDLE.
Signed-off-by: Peter Huewe
---
drivers/i2c/i2c-acpi.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/i2c-acpi.c b/drivers/i2c/i2c-acpi.c
index 0dbc18c..c456b17 100644
--- a/drivers/i2c/i2c-acpi.c
+++ b/drivers/i2c/i2c-acpi.c
@@ -308,10 +308,15 @@ acpi_i2c_space_handler(u32 function,
acpi_physical_address command,
int acpi_i2c_install_space_handler(struct i2c_adapter *adapter)
{
- acpi_handle handle = ACPI_HANDLE(adapter->dev.parent);
+ acpi_handle handle;
struct acpi_i2c_handler_data *data;
acpi_status status;
+ if (!adapter->dev.parent)
+ return -ENODEV;
+
+ handle = ACPI_HANDLE(adapter->dev.parent);
+
if (!handle)
return -ENODEV;
@@ -344,10 +349,15 @@ int acpi_i2c_install_space_handler(struct i2c_adapter
*adapter)
void acpi_i2c_remove_space_handler(struct i2c_adapter *adapter)
{
- acpi_handle handle = ACPI_HANDLE(adapter->dev.parent);
+ acpi_handle handle;
struct acpi_i2c_handler_data *data;
acpi_status status;
+ if (!adapter->dev.parent)
+ return;
+
+ handle = ACPI_HANDLE(adapter->dev.parent);
+
if (!handle)
return;
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/9] KEYS: Improve asymmetric key and PKCS#7 handling
Here are some patches to improve the matching of asymmetric keys and to improve the handling of PKCS#7 certificates: (1) Provide a method to preparse the data supplied for matching a key. This permits they key type to extract out the bits it needs for matching once only. Further, the type of search (direct lookup or iterative) can be set and the function used to actually check the match can be set by preparse rather than being hard coded for the type. (2) Improves asymmetric keys identification. Keys derived from X.509 certs now get labelled with IDs derived from their issuer and certificate number (required to match PKCS#7) and from their SKID and subject (required to match X.509). IDs are now binary and match criterion preparsing is provided so that criteria can be turned into binary blobs to make matching faster. (3) Improves PKCS#7 message handling to permit PKCS#7 messages without X.509 cert lists to be matched to trusted keys, thereby allowing minimally sized PKCS#7 certs to be used. (4) Improves PKCS#7 message handling to better handle certificate chains that are broken due to unsupported crypto that can otherwise by used to intersect a trust keyring. They can be found here also: http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-pkcs7 David --- David Howells (9): Provide a binary to hex conversion function KEYS: Preparse match data KEYS: Remove key_type::def_lookup_type KEYS: Remove key_type::match in favour of overriding default by match_preparse KEYS: Make the key matching functions return bool KEYS: Implement binary asymmetric key ID handling KEYS: Overhaul key identification when searching for asymmetric keys PKCS#7: Better handling of unsupported crypto PKCS#7: Handle PKCS#7 messages that contain no X.509 certs crypto/asymmetric_keys/asymmetric_keys.h |8 + crypto/asymmetric_keys/asymmetric_type.c | 213 + crypto/asymmetric_keys/pkcs7_key_type.c |2 crypto/asymmetric_keys/pkcs7_parser.c | 38 - crypto/asymmetric_keys/pkcs7_parser.h |7 - crypto/asymmetric_keys/pkcs7_trust.c | 72 +++--- crypto/asymmetric_keys/pkcs7_verify.c | 105 ++ crypto/asymmetric_keys/x509_cert_parser.c | 55 --- crypto/asymmetric_keys/x509_parser.h |6 + crypto/asymmetric_keys/x509_public_key.c | 102 -- fs/cifs/cifs_spnego.c |1 fs/cifs/cifsacl.c |1 fs/nfs/idmap.c|2 include/crypto/public_key.h |5 - include/keys/asymmetric-type.h| 38 + include/keys/user-type.h |1 include/linux/kernel.h|1 include/linux/key-type.h | 34 - lib/hexdump.c | 18 ++ net/ceph/crypto.c |1 net/dns_resolver/dns_key.c| 18 ++ net/rxrpc/ar-key.c|2 security/keys/big_key.c |2 security/keys/encrypted-keys/encrypted.c |1 security/keys/internal.h | 10 + security/keys/key.c |2 security/keys/keyring.c | 59 +--- security/keys/proc.c |8 + security/keys/process_keys.c | 13 +- security/keys/request_key.c | 21 ++- security/keys/request_key_auth.c |6 - security/keys/trusted.c |1 security/keys/user_defined.c | 14 -- 33 files changed, 584 insertions(+), 283 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 07/10] x86, mpx: decode MPX instruction to get bound violation information
On 09/12/2014 10:52 AM, Thomas Gleixner wrote: > > Well, I did not see the trainwreck which tried to use the generic > decoder, but as I explained in the other mail, there is no reason not > to use it and I can't see any complexity in retrieving the data beyond > calling insn_get_length(insn); > Looking at how complex the state machine ended up being, it probably was the wrong direction. It is safe to copy_from_user() 15 bytes, decode what we get (which may be less than 15 bytes) and then verify with insn_get_length() that what we decoded is actually what we copied if the copy_from_user() length is < 15. My intent was to explore a state machine limited to the restricted "mib" encodings that are valid for BNDSTX and BNDLDX only, but in the end it really doesn't make enough difference that it is worth messing with, I don't think. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/9] KEYS: Remove key_type::def_lookup_type
Remove key_type::def_lookup_type as it's no longer used. The information now
defaults to KEYRING_SEARCH_LOOKUP_DIRECT but may be overridden by
type->match_preparse().
Signed-off-by: David Howells
---
crypto/asymmetric_keys/asymmetric_type.c |1 -
crypto/asymmetric_keys/pkcs7_key_type.c |1 -
include/linux/key-type.h |3 ---
security/keys/big_key.c |1 -
security/keys/user_defined.c |2 --
5 files changed, 8 deletions(-)
diff --git a/crypto/asymmetric_keys/asymmetric_type.c
b/crypto/asymmetric_keys/asymmetric_type.c
index f666b4e8d256..9d78ad7754d9 100644
--- a/crypto/asymmetric_keys/asymmetric_type.c
+++ b/crypto/asymmetric_keys/asymmetric_type.c
@@ -228,7 +228,6 @@ struct key_type key_type_asymmetric = {
.match_free = asymmetric_key_match_free,
.destroy= asymmetric_key_destroy,
.describe = asymmetric_key_describe,
- .def_lookup_type = KEYRING_SEARCH_LOOKUP_ITERATE,
};
EXPORT_SYMBOL_GPL(key_type_asymmetric);
diff --git a/crypto/asymmetric_keys/pkcs7_key_type.c
b/crypto/asymmetric_keys/pkcs7_key_type.c
index 3de5fb011de0..d1faa1df1dec 100644
--- a/crypto/asymmetric_keys/pkcs7_key_type.c
+++ b/crypto/asymmetric_keys/pkcs7_key_type.c
@@ -72,7 +72,6 @@ error:
*/
static struct key_type key_type_pkcs7 = {
.name = "pkcs7_test",
- .def_lookup_type= KEYRING_SEARCH_LOOKUP_DIRECT,
.preparse = pkcs7_preparse,
.free_preparse = user_free_preparse,
.instantiate= generic_key_instantiate,
diff --git a/include/linux/key-type.h b/include/linux/key-type.h
index 8aba688a451a..bf93ea609273 100644
--- a/include/linux/key-type.h
+++ b/include/linux/key-type.h
@@ -81,9 +81,6 @@ struct key_type {
*/
size_t def_datalen;
- /* Default key search algorithm. */
- unsigned def_lookup_type;
-
/* vet a description */
int (*vet_description)(const char *description);
diff --git a/security/keys/big_key.c b/security/keys/big_key.c
index c2f91a0cf889..4045c13a761a 100644
--- a/security/keys/big_key.c
+++ b/security/keys/big_key.c
@@ -33,7 +33,6 @@ MODULE_LICENSE("GPL");
*/
struct key_type key_type_big_key = {
.name = "big_key",
- .def_lookup_type= KEYRING_SEARCH_LOOKUP_DIRECT,
.preparse = big_key_preparse,
.free_preparse = big_key_free_preparse,
.instantiate= generic_key_instantiate,
diff --git a/security/keys/user_defined.c b/security/keys/user_defined.c
index ec8a56063b02..cd7e726e8646 100644
--- a/security/keys/user_defined.c
+++ b/security/keys/user_defined.c
@@ -26,7 +26,6 @@ static int logon_vet_description(const char *desc);
*/
struct key_type key_type_user = {
.name = "user",
- .def_lookup_type= KEYRING_SEARCH_LOOKUP_DIRECT,
.preparse = user_preparse,
.free_preparse = user_free_preparse,
.instantiate= generic_key_instantiate,
@@ -48,7 +47,6 @@ EXPORT_SYMBOL_GPL(key_type_user);
*/
struct key_type key_type_logon = {
.name = "logon",
- .def_lookup_type= KEYRING_SEARCH_LOOKUP_DIRECT,
.preparse = user_preparse,
.free_preparse = user_free_preparse,
.instantiate= generic_key_instantiate,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/9] KEYS: Preparse match data
Preparse the match data. This provides several advantages:
(1) The preparser can reject invalid criteria up front.
(2) The preparser can convert the criteria to binary data if necessary (the
asymmetric key type really wants to do binary comparison of the key IDs).
(3) The preparser can set the type of search to be performed. This means
that it's not then a one-off setting in the key type.
(4) The preparser can set an appropriate comparator function.
Signed-off-by: David Howells
---
crypto/asymmetric_keys/asymmetric_type.c | 31 ++-
include/keys/user-type.h |4 ++
include/linux/key-type.h | 31 +--
net/dns_resolver/dns_key.c |5 ++-
security/keys/internal.h |8 ++---
security/keys/keyring.c | 49 ++
security/keys/proc.c |8 ++---
security/keys/process_keys.c | 13
security/keys/request_key.c | 21 ++---
security/keys/request_key_auth.c |6 ++--
security/keys/user_defined.c |4 +-
11 files changed, 129 insertions(+), 51 deletions(-)
diff --git a/crypto/asymmetric_keys/asymmetric_type.c
b/crypto/asymmetric_keys/asymmetric_type.c
index eb8cd46961a5..f666b4e8d256 100644
--- a/crypto/asymmetric_keys/asymmetric_type.c
+++ b/crypto/asymmetric_keys/asymmetric_type.c
@@ -59,9 +59,11 @@ EXPORT_SYMBOL_GPL(asymmetric_keyid_match);
* "id:" - request a key matching the ID
* ":" - request a key of a subtype
*/
-static int asymmetric_key_match(const struct key *key, const void *description)
+static int asymmetric_key_match(const struct key *key,
+ const struct key_match_data *match_data)
{
const struct asymmetric_key_subtype *subtype =
asymmetric_key_subtype(key);
+ const char *description = match_data->raw_data;
const char *spec = description;
const char *id;
ptrdiff_t speclen;
@@ -94,6 +96,31 @@ static int asymmetric_key_match(const struct key *key, const
void *description)
}
/*
+ * Preparse the match criterion. If we don't set lookup_type and cmp,
+ * the default will be an exact match on the key description.
+ *
+ * There are some specifiers for matching key IDs rather than by the key
+ * description:
+ *
+ * "id:" - request a key by any available ID
+ *
+ * These have to be searched by iteration rather than by direct lookup because
+ * the key is hashed according to its description.
+ */
+static int asymmetric_key_match_preparse(struct key_match_data *match_data)
+{
+ match_data->lookup_type = KEYRING_SEARCH_LOOKUP_ITERATE;
+ return 0;
+}
+
+/*
+ * Free the preparsed the match criterion.
+ */
+static void asymmetric_key_match_free(struct key_match_data *match_data)
+{
+}
+
+/*
* Describe the asymmetric key
*/
static void asymmetric_key_describe(const struct key *key, struct seq_file *m)
@@ -196,7 +223,9 @@ struct key_type key_type_asymmetric = {
.preparse = asymmetric_key_preparse,
.free_preparse = asymmetric_key_free_preparse,
.instantiate= generic_key_instantiate,
+ .match_preparse = asymmetric_key_match_preparse,
.match = asymmetric_key_match,
+ .match_free = asymmetric_key_match_free,
.destroy= asymmetric_key_destroy,
.describe = asymmetric_key_describe,
.def_lookup_type = KEYRING_SEARCH_LOOKUP_ITERATE,
diff --git a/include/keys/user-type.h b/include/keys/user-type.h
index 3ab1873a4bfa..66d92af30e7c 100644
--- a/include/keys/user-type.h
+++ b/include/keys/user-type.h
@@ -36,11 +36,13 @@ extern struct key_type key_type_user;
extern struct key_type key_type_logon;
struct key_preparsed_payload;
+struct key_match_data;
extern int user_preparse(struct key_preparsed_payload *prep);
extern void user_free_preparse(struct key_preparsed_payload *prep);
extern int user_update(struct key *key, struct key_preparsed_payload *prep);
-extern int user_match(const struct key *key, const void *criterion);
+extern int user_match(const struct key *key,
+ const struct key_match_data *match_data);
extern void user_revoke(struct key *key);
extern void user_destroy(struct key *key);
extern void user_describe(const struct key *user, struct seq_file *m);
diff --git a/include/linux/key-type.h b/include/linux/key-type.h
index 44792ee649de..8aba688a451a 100644
--- a/include/linux/key-type.h
+++ b/include/linux/key-type.h
@@ -53,6 +53,22 @@ typedef int (*request_key_actor_t)(struct key_construction
*key,
const char *op, void *aux);
/*
+ * Preparsed matching criterion.
+ */
+struct key_match_data {
+ /* Comparison function, defaults to type->match, but can be replaced by
+* type->match_preparse(). */
+ int (*cmp)(const struct key *key,
+ const
[PATCH 6/9] KEYS: Implement binary asymmetric key ID handling
Implement the first step in using binary key IDs for asymmetric keys rather
than hex string keys.
The previously added match data preparsing will be able to convert hex
criterion strings into binary which can then be compared more rapidly.
Further, we actually want more then one ID string per public key. The problem
is that X.509 certs refer to other X.509 certs by matching Issuer + AuthKeyId
to Subject + SubjKeyId, but PKCS#7 messages match against X.509 Issuer +
SerialNumber.
This patch just provides facilities for a later patch to make use of.
Signed-off-by: David Howells
---
crypto/asymmetric_keys/asymmetric_keys.h |4 +
crypto/asymmetric_keys/asymmetric_type.c | 82 ++
include/keys/asymmetric-type.h | 38 ++
3 files changed, 124 insertions(+)
diff --git a/crypto/asymmetric_keys/asymmetric_keys.h
b/crypto/asymmetric_keys/asymmetric_keys.h
index a63c551c6557..917be6b985e7 100644
--- a/crypto/asymmetric_keys/asymmetric_keys.h
+++ b/crypto/asymmetric_keys/asymmetric_keys.h
@@ -10,6 +10,10 @@
*/
int asymmetric_keyid_match(const char *kid, const char *id);
+extern bool asymmetric_match_key_ids(const struct asymmetric_key_ids *kids,
+const struct asymmetric_key_id *match_id);
+
+extern struct asymmetric_key_id *asymmetric_key_hex_to_key_id(const char *id);
static inline const char *asymmetric_key_id(const struct key *key)
{
diff --git a/crypto/asymmetric_keys/asymmetric_type.c
b/crypto/asymmetric_keys/asymmetric_type.c
index 7755f918e8d9..3bc71b4e1eed 100644
--- a/crypto/asymmetric_keys/asymmetric_type.c
+++ b/crypto/asymmetric_keys/asymmetric_type.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include "asymmetric_keys.h"
MODULE_LICENSE("GPL");
@@ -23,6 +24,87 @@ static LIST_HEAD(asymmetric_key_parsers);
static DECLARE_RWSEM(asymmetric_key_parsers_sem);
/*
+ * Construct an asymmetric key ID from two binary blobs.
+ */
+struct asymmetric_key_id *asymmetric_key_generate_id(const void *val_1,
+size_t len_1,
+const void *val_2,
+size_t len_2)
+{
+ struct asymmetric_key_id *kid;
+
+ kid = kmalloc(sizeof(struct asymmetric_key_id) + len_1 + 4 + len_2,
+ GFP_KERNEL);
+ if (!kid)
+ return ERR_PTR(-ENOMEM);
+ kid->len = len_1 + 4 + len_2;
+ memcpy(kid->data, val_1, len_1);
+ kid->data[len_1 + 0] = 0xff;
+ kid->data[len_1 + 1] = 0xff;
+ kid->data[len_1 + 2] = 0xff;
+ kid->data[len_1 + 3] = 0xff;
+ memcpy(kid->data + len_1 + 4, val_2, len_2);
+ return kid;
+}
+
+/*
+ * Return true if two asymmetric keys are the same.
+ */
+bool asymmetric_key_id_same(const struct asymmetric_key_id *kid1,
+ const struct asymmetric_key_id *kid2)
+{
+ if (!kid1 || !kid2)
+ return false;
+ if (kid1->len != kid2->len)
+ return false;
+ return memcmp(kid1->data, kid2->data, kid1->len) == 0;
+}
+
+/*
+ * Match asymmetric key id with partial match
+ * @id: key id to match in a form "id:"
+ */
+bool asymmetric_match_key_ids(const struct asymmetric_key_ids *kids,
+ const struct asymmetric_key_id *match_id)
+{
+ if (!kids || !match_id)
+ return false;
+ if (asymmetric_key_id_same(kids->id[0], match_id))
+ return true;
+ if (asymmetric_key_id_same(kids->id[1], match_id))
+ return true;
+ return false;
+}
+EXPORT_SYMBOL_GPL(asymmetric_match_key_ids);
+
+/**
+ * Convert a hex string into a key ID.
+ */
+struct asymmetric_key_id *asymmetric_key_hex_to_key_id(const char *id)
+{
+ struct asymmetric_key_id *match_id;
+ const char *p;
+ ptrdiff_t hexlen;
+
+ if (!*id)
+ return ERR_PTR(-EINVAL);
+ for (p = id; *p; p++)
+ if (!isxdigit(*p))
+ return ERR_PTR(-EINVAL);
+ hexlen = p - id;
+ if (hexlen & 1)
+ return ERR_PTR(-EINVAL);
+
+ match_id = kmalloc(sizeof(struct asymmetric_key_id) + hexlen / 2,
+ GFP_KERNEL);
+ if (!match_id)
+ return ERR_PTR(-ENOMEM);
+ match_id->len = hexlen / 2;
+ hex2bin(match_id->data, id, hexlen / 2);
+ return match_id;
+}
+
+/*
* Match asymmetric key id with partial match
* @id:key id to match in a form "id:"
*/
diff --git a/include/keys/asymmetric-type.h b/include/keys/asymmetric-type.h
index 7dd473496180..044ab0d3aa45 100644
--- a/include/keys/asymmetric-type.h
+++ b/include/keys/asymmetric-type.h
@@ -19,6 +19,44 @@
extern struct key_type key_type_asymmetric;
/*
+ * Identifiers for an asymmetric key ID. We have three ways of looking up a
+ * key derived from an X.509
[PATCH 9/9] PKCS#7: Handle PKCS#7 messages that contain no X.509 certs
The X.509 certificate list in a PKCS#7 message is optional. To save space, we
can omit the inclusion of any X.509 certificates if we are sure that we can
look the relevant public key up by the serial number and issuer given in a
signed info block.
This also supports use of a signed info block for which we don't have a
matching X.509 cert giving in a populated certificate list.
Signed-off-by: David Howells
---
crypto/asymmetric_keys/pkcs7_trust.c | 48 +
crypto/asymmetric_keys/pkcs7_verify.c | 16 ---
2 files changed, 47 insertions(+), 17 deletions(-)
diff --git a/crypto/asymmetric_keys/pkcs7_trust.c
b/crypto/asymmetric_keys/pkcs7_trust.c
index 8b634ae746e6..926df53ebb7c 100644
--- a/crypto/asymmetric_keys/pkcs7_trust.c
+++ b/crypto/asymmetric_keys/pkcs7_trust.c
@@ -55,13 +55,16 @@ static int pkcs7_validate_trust_one(struct pkcs7_message
*pkcs7,
* keys.
*/
key = x509_request_asymmetric_key(trust_keyring, x509->id);
- if (!IS_ERR(key))
+ if (!IS_ERR(key)) {
/* One of the X.509 certificates in the PKCS#7 message
* is apparently the same as one we already trust.
* Verify that the trusted variant can also validate
* the signature on the descendant.
*/
+ pr_devel("sinfo %u: Cert %u as key %x\n",
+sinfo->index, x509->index, key_serial(key));
goto matched;
+ }
if (key == ERR_PTR(-ENOMEM))
return -ENOMEM;
@@ -81,15 +84,34 @@ static int pkcs7_validate_trust_one(struct pkcs7_message
*pkcs7,
/* No match - see if the root certificate has a signer amongst the
* trusted keys.
*/
- if (!last || !last->issuer || !last->authority) {
- kleave(" = -ENOKEY [no backref]");
- return -ENOKEY;
+ if (last && last->authority) {
+ key = x509_request_asymmetric_key(trust_keyring,
last->authority);
+ if (!IS_ERR(key)) {
+ x509 = last;
+ pr_devel("sinfo %u: Root cert %u signer is key %x\n",
+sinfo->index, x509->index, key_serial(key));
+ goto matched;
+ }
+ if (PTR_ERR(key) != -ENOKEY)
+ return PTR_ERR(key);
}
- key = x509_request_asymmetric_key(trust_keyring, last->authority);
- if (IS_ERR(key))
- return PTR_ERR(key) == -ENOMEM ? -ENOMEM : -ENOKEY;
- x509 = last;
+ /* As a last resort, see if we have a trusted public key that matches
+* the signed info directly.
+*/
+ key = x509_request_asymmetric_key(trust_keyring,
+ sinfo->signing_cert_id);
+ if (!IS_ERR(key)) {
+ pr_devel("sinfo %u: Direct signer is key %x\n",
+sinfo->index, key_serial(key));
+ x509 = NULL;
+ goto matched;
+ }
+ if (PTR_ERR(key) != -ENOKEY)
+ return PTR_ERR(key);
+
+ kleave(" = -ENOKEY [no backref]");
+ return -ENOKEY;
matched:
ret = verify_signature(key, sig);
@@ -103,10 +125,12 @@ matched:
}
verified:
- x509->verified = true;
- for (p = sinfo->signer; p != x509; p = p->signer) {
- p->verified = true;
- p->trusted = trusted;
+ if (x509) {
+ x509->verified = true;
+ for (p = sinfo->signer; p != x509; p = p->signer) {
+ p->verified = true;
+ p->trusted = trusted;
+ }
}
sinfo->trusted = trusted;
kleave(" = 0");
diff --git a/crypto/asymmetric_keys/pkcs7_verify.c
b/crypto/asymmetric_keys/pkcs7_verify.c
index 73a75a5a0b98..b3059f2ad0f7 100644
--- a/crypto/asymmetric_keys/pkcs7_verify.c
+++ b/crypto/asymmetric_keys/pkcs7_verify.c
@@ -154,10 +154,13 @@ static int pkcs7_find_key(struct pkcs7_message *pkcs7,
return 0;
}
- pr_warn("Sig %u: Issuing X.509 cert not found (#%*ph)\n",
- sinfo->index,
- sinfo->signing_cert_id->len, sinfo->signing_cert_id->data);
- return -ENOKEY;
+ /* The relevant X.509 cert isn't found here, but it might be found in
+* the trust keyring.
+*/
+ pr_debug("Sig %u: Issuing X.509 cert not found (#%*phN)\n",
+sinfo->index,
+sinfo->signing_cert_id->len, sinfo->signing_cert_id->data);
+ return 0;
}
/*
@@ -277,11 +280,14 @@ static int pkcs7_verify_one(struct pkcs7_message *pkcs7,
if (ret < 0)
return ret;
- /* Find the key for the signature */
+ /* Find the key for the
[PATCH 8/9] PKCS#7: Better handling of unsupported crypto
Provide better handling of unsupported crypto when verifying a PKCS#7 message.
If we can't bridge the gap between a pair of X.509 certs or between a signed
info block and an X.509 cert because it involves some crypto we don't support,
that's not necessarily the end of the world as there may be other ways points
at which we can intersect with a ring of trusted keys.
Instead, only produce ENOPKG immediately if all the signed info blocks in a
PKCS#7 message require unsupported crypto to bridge to the first X.509 cert.
Otherwise, we defer the generation of ENOPKG until we get ENOKEY during trust
validation.
Signed-off-by: David Howells
---
crypto/asymmetric_keys/pkcs7_parser.h|2 +
crypto/asymmetric_keys/pkcs7_trust.c | 20 +++-
crypto/asymmetric_keys/pkcs7_verify.c| 49 --
crypto/asymmetric_keys/x509_parser.h |1 +
crypto/asymmetric_keys/x509_public_key.c | 13 +++-
5 files changed, 70 insertions(+), 15 deletions(-)
diff --git a/crypto/asymmetric_keys/pkcs7_parser.h
b/crypto/asymmetric_keys/pkcs7_parser.h
index 91949f92bc72..d38ae26c24a7 100644
--- a/crypto/asymmetric_keys/pkcs7_parser.h
+++ b/crypto/asymmetric_keys/pkcs7_parser.h
@@ -23,6 +23,7 @@ struct pkcs7_signed_info {
struct x509_certificate *signer; /* Signing certificate (in msg->certs)
*/
unsigned index;
bool trusted;
+ bool unsupported_crypto;/* T if not usable due to missing
crypto */
/* Message digest - the digest of the Content Data (or NULL) */
const void *msgdigest;
@@ -49,6 +50,7 @@ struct pkcs7_message {
struct x509_certificate *certs; /* Certificate list */
struct x509_certificate *crl; /* Revocation list */
struct pkcs7_signed_info *signed_infos;
+ bool unsupported_crypto;/* T if some part of the chains had
missing crypto */
/* Content Data (or NULL) */
enum OIDdata_type; /* Type of Data */
diff --git a/crypto/asymmetric_keys/pkcs7_trust.c
b/crypto/asymmetric_keys/pkcs7_trust.c
index 09197e50fa82..8b634ae746e6 100644
--- a/crypto/asymmetric_keys/pkcs7_trust.c
+++ b/crypto/asymmetric_keys/pkcs7_trust.c
@@ -35,6 +35,11 @@ static int pkcs7_validate_trust_one(struct pkcs7_message
*pkcs7,
kenter(",%u,", sinfo->index);
+ if (sinfo->unsupported_crypto) {
+ kleave(" = -ENOPKG [cached]");
+ return -ENOPKG;
+ }
+
for (x509 = sinfo->signer; x509; x509 = x509->signer) {
if (x509->seen) {
if (x509->verified) {
@@ -139,7 +144,8 @@ int pkcs7_validate_trust(struct pkcs7_message *pkcs7,
{
struct pkcs7_signed_info *sinfo;
struct x509_certificate *p;
- int cached_ret = 0, ret;
+ int cached_ret = pkcs7->unsupported_crypto ? -ENOPKG : -ENOKEY;
+ int ret;
for (p = pkcs7->certs; p; p = p->next)
p->seen = false;
@@ -147,16 +153,12 @@ int pkcs7_validate_trust(struct pkcs7_message *pkcs7,
for (sinfo = pkcs7->signed_infos; sinfo; sinfo = sinfo->next) {
ret = pkcs7_validate_trust_one(pkcs7, sinfo, trust_keyring);
if (ret < 0) {
- if (ret == -ENOPKG) {
- cached_ret = -ENOPKG;
- } else if (ret == -ENOKEY) {
- if (cached_ret == 0)
- cached_ret = -ENOKEY;
- } else {
- return ret;
- }
+ if (ret == -ENOPKG || ret == -ENOKEY)
+ continue;
+ return ret;
}
*_trusted |= sinfo->trusted;
+ cached_ret = 0;
}
return cached_ret;
diff --git a/crypto/asymmetric_keys/pkcs7_verify.c
b/crypto/asymmetric_keys/pkcs7_verify.c
index 57e90fa17f2b..73a75a5a0b98 100644
--- a/crypto/asymmetric_keys/pkcs7_verify.c
+++ b/crypto/asymmetric_keys/pkcs7_verify.c
@@ -181,7 +181,7 @@ static int pkcs7_verify_sig_chain(struct pkcs7_message
*pkcs7,
x509->seen = true;
ret = x509_get_sig_params(x509);
if (ret < 0)
- return ret;
+ goto maybe_missing_crypto_in_x509;
pr_debug("- issuer %s\n", x509->issuer);
if (x509->authority)
@@ -203,7 +203,7 @@ static int pkcs7_verify_sig_chain(struct pkcs7_message
*pkcs7,
ret = x509_check_signature(x509->pub, x509);
if (ret < 0)
- return ret;
+ goto maybe_missing_crypto_in_x509;
x509->signer = x509;
pr_debug("- self-signed\n");
return 0;
@@ -245,6 +245,19 @@ static int pkcs7_verify_sig_chain(struct pkcs7_message
[PATCH 5/9] KEYS: Make the key matching functions return bool
Make the key matching functions pointed to by key_match_data::cmp return bool
rather than int.
Signed-off-by: David Howells
---
crypto/asymmetric_keys/asymmetric_type.c |4 ++--
include/linux/key-type.h | 10 ++
net/dns_resolver/dns_key.c |4 ++--
security/keys/internal.h |8
security/keys/keyring.c |4 ++--
security/keys/process_keys.c |4 ++--
6 files changed, 18 insertions(+), 16 deletions(-)
diff --git a/crypto/asymmetric_keys/asymmetric_type.c
b/crypto/asymmetric_keys/asymmetric_type.c
index 7c0498968975..7755f918e8d9 100644
--- a/crypto/asymmetric_keys/asymmetric_type.c
+++ b/crypto/asymmetric_keys/asymmetric_type.c
@@ -59,8 +59,8 @@ EXPORT_SYMBOL_GPL(asymmetric_keyid_match);
* "id:" - request a key matching the ID
* ":" - request a key of a subtype
*/
-static int asymmetric_key_cmp(const struct key *key,
- const struct key_match_data *match_data)
+static bool asymmetric_key_cmp(const struct key *key,
+ const struct key_match_data *match_data)
{
const struct asymmetric_key_subtype *subtype =
asymmetric_key_subtype(key);
const char *description = match_data->raw_data;
diff --git a/include/linux/key-type.h b/include/linux/key-type.h
index c14816bd3b44..ff9f1d394235 100644
--- a/include/linux/key-type.h
+++ b/include/linux/key-type.h
@@ -56,10 +56,12 @@ typedef int (*request_key_actor_t)(struct key_construction
*key,
* Preparsed matching criterion.
*/
struct key_match_data {
- /* Comparison function, defaults to type->match, but can be replaced by
-* type->match_preparse(). */
- int (*cmp)(const struct key *key,
- const struct key_match_data *match_data);
+ /* Comparison function, defaults to exact description match, but can be
+* overridden by type->match_preparse(). Should return true if a match
+* is found and false if not.
+*/
+ bool (*cmp)(const struct key *key,
+ const struct key_match_data *match_data);
const void *raw_data; /* Raw match data */
void*preparsed; /* For ->match_preparse() to stash
stuff */
diff --git a/net/dns_resolver/dns_key.c b/net/dns_resolver/dns_key.c
index a07b9ba7e0b7..31cd4fd75486 100644
--- a/net/dns_resolver/dns_key.c
+++ b/net/dns_resolver/dns_key.c
@@ -176,8 +176,8 @@ static void dns_resolver_free_preparse(struct
key_preparsed_payload *prep)
* The domain name may be a simple name or an absolute domain name (which
* should end with a period). The domain name is case-independent.
*/
-static int dns_resolver_cmp(const struct key *key,
- const struct key_match_data *match_data)
+static bool dns_resolver_cmp(const struct key *key,
+const struct key_match_data *match_data)
{
int slen, dlen, ret = 0;
const char *src = key->description, *dsp = match_data->raw_data;
diff --git a/security/keys/internal.h b/security/keys/internal.h
index 4ef315325b9d..7a1299af41c3 100644
--- a/security/keys/internal.h
+++ b/security/keys/internal.h
@@ -128,8 +128,8 @@ struct keyring_search_context {
struct timespec now;
};
-extern int key_default_cmp(const struct key *key,
- const struct key_match_data *match_data);
+extern bool key_default_cmp(const struct key *key,
+ const struct key_match_data *match_data);
extern key_ref_t keyring_search_aux(key_ref_t keyring_ref,
struct keyring_search_context *ctx);
@@ -151,8 +151,8 @@ extern struct key *request_key_and_link(struct key_type
*type,
struct key *dest_keyring,
unsigned long flags);
-extern int lookup_user_key_possessed(const struct key *key,
-const struct key_match_data *match_data);
+extern bool lookup_user_key_possessed(const struct key *key,
+ const struct key_match_data *match_data);
extern key_ref_t lookup_user_key(key_serial_t id, unsigned long flags,
key_perm_t perm);
#define KEY_LOOKUP_CREATE 0x01
diff --git a/security/keys/keyring.c b/security/keys/keyring.c
index d8ce7db1db78..e43f0e8faa3e 100644
--- a/security/keys/keyring.c
+++ b/security/keys/keyring.c
@@ -513,8 +513,8 @@ EXPORT_SYMBOL(keyring_alloc);
/*
* By default, we keys found by getting an exact match on their descriptions.
*/
-int key_default_cmp(const struct key *key,
- const struct key_match_data *match_data)
+bool key_default_cmp(const struct key *key,
+const struct key_match_data *match_data)
{
return strcmp(key->description, match_data->raw_data) == 0;
}
diff --git
[PATCH 4/9] KEYS: Remove key_type::match in favour of overriding default by match_preparse
A previous patch added a ->match_preparse() method to the key type. This is
allowed to override the function called by the iteration algorithm.
Therefore, we can just set a default that simply checks for an exact match of
the key description with the original criterion data and allow match_preparse
to override it as needed.
The key_type::match op is then redundant and can be removed, as can the
user_match() function.
Signed-off-by: David Howells
---
crypto/asymmetric_keys/asymmetric_type.c |6 +++---
crypto/asymmetric_keys/pkcs7_key_type.c |1 -
fs/cifs/cifs_spnego.c|1 -
fs/cifs/cifsacl.c|1 -
fs/nfs/idmap.c |2 --
include/keys/user-type.h |3 ---
include/linux/key-type.h |4
net/ceph/crypto.c|1 -
net/dns_resolver/dns_key.c | 17 +
net/rxrpc/ar-key.c |2 --
security/keys/big_key.c |1 -
security/keys/encrypted-keys/encrypted.c |1 -
security/keys/internal.h |2 ++
security/keys/key.c |2 +-
security/keys/keyring.c | 12 ++--
security/keys/request_key.c |2 +-
security/keys/request_key_auth.c |2 +-
security/keys/trusted.c |1 -
security/keys/user_defined.c | 12
19 files changed, 31 insertions(+), 42 deletions(-)
diff --git a/crypto/asymmetric_keys/asymmetric_type.c
b/crypto/asymmetric_keys/asymmetric_type.c
index 9d78ad7754d9..7c0498968975 100644
--- a/crypto/asymmetric_keys/asymmetric_type.c
+++ b/crypto/asymmetric_keys/asymmetric_type.c
@@ -59,8 +59,8 @@ EXPORT_SYMBOL_GPL(asymmetric_keyid_match);
* "id:" - request a key matching the ID
* ":" - request a key of a subtype
*/
-static int asymmetric_key_match(const struct key *key,
- const struct key_match_data *match_data)
+static int asymmetric_key_cmp(const struct key *key,
+ const struct key_match_data *match_data)
{
const struct asymmetric_key_subtype *subtype =
asymmetric_key_subtype(key);
const char *description = match_data->raw_data;
@@ -110,6 +110,7 @@ static int asymmetric_key_match(const struct key *key,
static int asymmetric_key_match_preparse(struct key_match_data *match_data)
{
match_data->lookup_type = KEYRING_SEARCH_LOOKUP_ITERATE;
+ match_data->cmp = asymmetric_key_cmp;
return 0;
}
@@ -224,7 +225,6 @@ struct key_type key_type_asymmetric = {
.free_preparse = asymmetric_key_free_preparse,
.instantiate= generic_key_instantiate,
.match_preparse = asymmetric_key_match_preparse,
- .match = asymmetric_key_match,
.match_free = asymmetric_key_match_free,
.destroy= asymmetric_key_destroy,
.describe = asymmetric_key_describe,
diff --git a/crypto/asymmetric_keys/pkcs7_key_type.c
b/crypto/asymmetric_keys/pkcs7_key_type.c
index d1faa1df1dec..751f8fd7335d 100644
--- a/crypto/asymmetric_keys/pkcs7_key_type.c
+++ b/crypto/asymmetric_keys/pkcs7_key_type.c
@@ -75,7 +75,6 @@ static struct key_type key_type_pkcs7 = {
.preparse = pkcs7_preparse,
.free_preparse = user_free_preparse,
.instantiate= generic_key_instantiate,
- .match = user_match,
.revoke = user_revoke,
.destroy= user_destroy,
.describe = user_describe,
diff --git a/fs/cifs/cifs_spnego.c b/fs/cifs/cifs_spnego.c
index a3e932547617..f4cf200b3c76 100644
--- a/fs/cifs/cifs_spnego.c
+++ b/fs/cifs/cifs_spnego.c
@@ -62,7 +62,6 @@ cifs_spnego_key_destroy(struct key *key)
struct key_type cifs_spnego_key_type = {
.name = "cifs.spnego",
.instantiate= cifs_spnego_key_instantiate,
- .match = user_match,
.destroy= cifs_spnego_key_destroy,
.describe = user_describe,
};
diff --git a/fs/cifs/cifsacl.c b/fs/cifs/cifsacl.c
index 7ff866dbb89e..6d00c419cbae 100644
--- a/fs/cifs/cifsacl.c
+++ b/fs/cifs/cifsacl.c
@@ -84,7 +84,6 @@ static struct key_type cifs_idmap_key_type = {
.instantiate = cifs_idmap_key_instantiate,
.destroy = cifs_idmap_key_destroy,
.describe= user_describe,
- .match = user_match,
};
static char *
diff --git a/fs/nfs/idmap.c b/fs/nfs/idmap.c
index 7dd55b745c4d..2f5db844c172 100644
--- a/fs/nfs/idmap.c
+++ b/fs/nfs/idmap.c
@@ -177,7 +177,6 @@ static struct key_type key_type_id_resolver = {
.preparse = user_preparse,
.free_preparse = user_free_preparse,
.instantiate= generic_key_instantiate,
- .match = user_match,
.revoke = user_revoke,
.destroy=
[PATCH 7/9] KEYS: Overhaul key identification when searching for asymmetric keys
Make use of the new match string preparsing to overhaul key identification
when searching for asymmetric keys. The following changes are made:
(1) Use the previously created asymmetric_key_id struct to hold the following
key IDs derived from the X.509 certificate or PKCS#7 message:
id: serial number + issuer
skid: subjKeyId + subject
authority: authKeyId + issuer
(2) Replace the hex fingerprint attached to key->type_data[1] with an
asymmetric_key_ids struct containing the id and the skid (if present).
(3) Make the asymmetric_type match data preparse select one of two searches:
(a) An iterative search for the key ID given if prefixed with "id:". The
prefix is expected to be followed by a hex string giving the ID to
search for. The criterion key ID is checked against all key IDs
recorded on the key.
(b) A direct search if the key ID is not prefixed with "id:". This will
look for an exact match on the key description.
(4) Make x509_request_asymmetric_key() take a key ID. This is then converted
into "id:" and passed into keyring_search() where match preparsing
will turn it back into a binary ID.
(5) X.509 certificate verification then takes the authority key ID and looks
up a key that matches it to find the public key for the certificate
signature.
(6) PKCS#7 certificate verification then takes the id key ID and looks up a
key that matches it to find the public key for the signed information
block signature.
Additional changes:
(1) Multiple subjKeyId and authKeyId values on an X.509 certificate cause the
cert to be rejected with -EBADMSG.
(2) The 'fingerprint' ID is gone. This was primarily intended to convey PGP
public key fingerprints. If PGP is supported in future, this should
generate a key ID that carries the fingerprint.
(3) Th ca_keyid= kernel command line option is now converted to a key ID and
used to match the authority key ID. Possibly this should only match the
actual authKeyId part and not the issuer as well.
Signed-off-by: David Howells
---
crypto/asymmetric_keys/asymmetric_keys.h |4 -
crypto/asymmetric_keys/asymmetric_type.c | 133 -
crypto/asymmetric_keys/pkcs7_parser.c | 38 ++--
crypto/asymmetric_keys/pkcs7_parser.h |5 -
crypto/asymmetric_keys/pkcs7_trust.c |6 -
crypto/asymmetric_keys/pkcs7_verify.c | 44 --
crypto/asymmetric_keys/x509_cert_parser.c | 55 +++-
crypto/asymmetric_keys/x509_parser.h |5 +
crypto/asymmetric_keys/x509_public_key.c | 89 +++
include/crypto/public_key.h |5 +
10 files changed, 198 insertions(+), 186 deletions(-)
diff --git a/crypto/asymmetric_keys/asymmetric_keys.h
b/crypto/asymmetric_keys/asymmetric_keys.h
index 917be6b985e7..fd21ac28e0a0 100644
--- a/crypto/asymmetric_keys/asymmetric_keys.h
+++ b/crypto/asymmetric_keys/asymmetric_keys.h
@@ -9,13 +9,13 @@
* 2 of the Licence, or (at your option) any later version.
*/
-int asymmetric_keyid_match(const char *kid, const char *id);
extern bool asymmetric_match_key_ids(const struct asymmetric_key_ids *kids,
const struct asymmetric_key_id *match_id);
extern struct asymmetric_key_id *asymmetric_key_hex_to_key_id(const char *id);
-static inline const char *asymmetric_key_id(const struct key *key)
+static inline
+const struct asymmetric_key_ids *asymmetric_key_ids(const struct key *key)
{
return key->type_data.p[1];
}
diff --git a/crypto/asymmetric_keys/asymmetric_type.c
b/crypto/asymmetric_keys/asymmetric_type.c
index 3bc71b4e1eed..6f16f647d21b 100644
--- a/crypto/asymmetric_keys/asymmetric_type.c
+++ b/crypto/asymmetric_keys/asymmetric_type.c
@@ -105,76 +105,15 @@ struct asymmetric_key_id
*asymmetric_key_hex_to_key_id(const char *id)
}
/*
- * Match asymmetric key id with partial match
- * @id:key id to match in a form "id:"
- */
-int asymmetric_keyid_match(const char *kid, const char *id)
-{
- size_t idlen, kidlen;
-
- if (!kid || !id)
- return 0;
-
- /* make it possible to use id as in the request: "id:" */
- if (strncmp(id, "id:", 3) == 0)
- id += 3;
-
- /* Anything after here requires a partial match on the ID string */
- idlen = strlen(id);
- kidlen = strlen(kid);
- if (idlen > kidlen)
- return 0;
-
- kid += kidlen - idlen;
- if (strcasecmp(id, kid) != 0)
- return 0;
-
- return 1;
-}
-EXPORT_SYMBOL_GPL(asymmetric_keyid_match);
-
-/*
- * Match asymmetric keys on (part of) their name
- * We have some shorthand methods for matching keys. We allow:
- *
- * ""- request a key by description
- * "id:" - request a key matching the ID
- * ":" - request a key of a subtype
+ * Match asymmetric keys by
[PATCH 1/9] Provide a binary to hex conversion function
Provide a function to convert a buffer of binary data into an unterminated
ascii hex string representation of that data.
Signed-off-by: David Howells
---
include/linux/kernel.h |1 +
lib/hexdump.c | 18 ++
2 files changed, 19 insertions(+)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 95624bed87ef..7c0ad8e38510 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -496,6 +496,7 @@ static inline char *hex_byte_pack_upper(char *buf, u8 byte)
extern int hex_to_bin(char ch);
extern int __must_check hex2bin(u8 *dst, const char *src, size_t count);
+extern char *bin2hex(char *dst, const void *src, size_t count);
bool mac_pton(const char *s, u8 *mac);
diff --git a/lib/hexdump.c b/lib/hexdump.c
index 8499c810909a..6daf254dddfa 100644
--- a/lib/hexdump.c
+++ b/lib/hexdump.c
@@ -59,6 +59,24 @@ int hex2bin(u8 *dst, const char *src, size_t count)
EXPORT_SYMBOL(hex2bin);
/**
+ * bin2hex - convert binary data to an ascii hexadecimal string
+ * @dst: ascii hexadecimal result
+ * @src: binary data
+ * @count: binary data length
+ */
+char *bin2hex(char *dst, const void *src, size_t count)
+{
+ while (count--) {
+ unsigned char ch = *(const unsigned char *)src;
+ *dst++ = hex_asc[ch >> 4];
+ *dst++ = hex_asc[ch & 0xf];
+ src++;
+ }
+ return dst;
+}
+EXPORT_SYMBOL(bin2hex);
+
+/**
* hex_dump_to_buffer - convert a blob of data to "hex ASCII" in memory
* @buf: data blob to dump
* @len: number of bytes in the @buf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 2/3] x86: Enable PAT to use cache mode translation tables
On Fri, Sep 12, 2014 at 12:35:11PM +0200, Juergen Gross wrote:
> Update the translation tables from cache mode to pgprot values
> according to the PAT settings. This enables changing the cache
> attributes of a PAT index in just one place without having to change
> at the users side.
>
> With this change it is possible to use the same kernel with different
> PAT configurations, e.g. supporting Xen.
>
> Signed-off-by: Juergen Gross
> Reviewed-by: Toshi Kani
Reviewed-by: Konrad Rzeszutek Wilk
> ---
> arch/x86/include/asm/pat.h | 1 +
> arch/x86/include/asm/pgtable_types.h | 4 +++
> arch/x86/mm/init.c | 8 ++
> arch/x86/mm/mm_internal.h| 2 ++
> arch/x86/mm/pat.c| 55
> ++--
> 5 files changed, 68 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/include/asm/pat.h b/arch/x86/include/asm/pat.h
> index 150407a..91bc4ba 100644
> --- a/arch/x86/include/asm/pat.h
> +++ b/arch/x86/include/asm/pat.h
> @@ -11,6 +11,7 @@ static const int pat_enabled;
> #endif
>
> extern void pat_init(void);
> +void pat_init_cache_modes(void);
>
> extern int reserve_memtype(u64 start, u64 end,
> enum page_cache_mode req_pcm, enum page_cache_mode *ret_pcm);
> diff --git a/arch/x86/include/asm/pgtable_types.h
> b/arch/x86/include/asm/pgtable_types.h
> index 0d38511..bd2f50f 100644
> --- a/arch/x86/include/asm/pgtable_types.h
> +++ b/arch/x86/include/asm/pgtable_types.h
> @@ -338,6 +338,10 @@ extern uint8_t __pte2cachemode_tbl[8];
> cb) >> (_PAGE_BIT_PAT - 2)) & 4) | \
>(((cb) >> (_PAGE_BIT_PCD - 1)) & 2) | \
>(((cb) >> _PAGE_BIT_PWT) & 1))
> +#define __cm_idx2pte(i) \
> + i) & 4) << (_PAGE_BIT_PAT - 2)) | \
> + (((i) & 2) << (_PAGE_BIT_PCD - 1)) | \
> + (((i) & 1) << _PAGE_BIT_PWT))
>
> static inline unsigned long cachemode2protval(enum page_cache_mode pcm)
> {
> diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
> index a9776ba..82b41d5 100644
> --- a/arch/x86/mm/init.c
> +++ b/arch/x86/mm/init.c
> @@ -716,3 +716,11 @@ void __init zone_sizes_init(void)
> free_area_init_nodes(max_zone_pfns);
> }
>
> +void update_cache_mode_entry(unsigned entry, enum page_cache_mode cache)
> +{
> + /* entry 0 MUST be WB (hardwired to speed up translations) */
> + BUG_ON(!entry && cache != _PAGE_CACHE_MODE_WB);
> +
> + __cachemode2pte_tbl[cache] = __cm_idx2pte(entry);
> + __pte2cachemode_tbl[entry] = cache;
> +}
> diff --git a/arch/x86/mm/mm_internal.h b/arch/x86/mm/mm_internal.h
> index 6b563a1..62474ba 100644
> --- a/arch/x86/mm/mm_internal.h
> +++ b/arch/x86/mm/mm_internal.h
> @@ -16,4 +16,6 @@ void zone_sizes_init(void);
>
> extern int after_bootmem;
>
> +void update_cache_mode_entry(unsigned entry, enum page_cache_mode cache);
> +
> #endif /* __X86_MM_INTERNAL_H */
> diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
> index ef75f3f..ff31851 100644
> --- a/arch/x86/mm/pat.c
> +++ b/arch/x86/mm/pat.c
> @@ -31,6 +31,7 @@
> #include
>
> #include "pat_internal.h"
> +#include "mm_internal.h"
>
> #ifdef CONFIG_X86_PAT
> int __read_mostly pat_enabled = 1;
> @@ -75,6 +76,57 @@ enum {
> PAT_UC_MINUS = 7, /* UC, but can be overriden by MTRR */
> };
>
> +/*
> + * Update the cache mode to pgprot translation tables according to PAT
> + * configuration.
> + * Using lower indices is preferred, so we start with highest index.
> + */
> +void pat_init_cache_modes(void)
> +{
> + int i;
> + enum page_cache_mode cache;
> + char pat_msg[33];
> + char *cache_mode;
> + u64 pat;
> +
> + rdmsrl(MSR_IA32_CR_PAT, pat);
> + pat_msg[32] = 0;
> + for (i = 7; i >= 0; i--) {
> + switch ((pat >> (i * 8)) & 7) {
> + case PAT_UC:
> + cache = _PAGE_CACHE_MODE_UC;
> + cache_mode = "UC ";
> + break;
> + case PAT_WC:
> + cache = _PAGE_CACHE_MODE_WC;
> + cache_mode = "WC ";
> + break;
> + case PAT_WT:
> + cache = _PAGE_CACHE_MODE_WT;
> + cache_mode = "WT ";
> + break;
> + case PAT_WP:
> + cache = _PAGE_CACHE_MODE_WP;
> + cache_mode = "WP ";
> + break;
> + case PAT_WB:
> + cache = _PAGE_CACHE_MODE_WB;
> + cache_mode = "WB ";
> + break;
> + case PAT_UC_MINUS:
> + cache = _PAGE_CACHE_MODE_UC_MINUS;
> + cache_mode = "UC- ";
> + break;
> + default:
> + cache = _PAGE_CACHE_MODE_WB;
> + cache_mode = "WB ";
> + }
> +
Re: [PATCH v8 3/3] phy: Add Qualcomm DWC3 HS/SS PHY driver
Yay nitpicks!
On 09/12/14 10:29, Andy Gross wrote:
> +
> +struct qcom_dwc3_usb_phy {
> + void __iomem*base;
> + struct device *dev;
> + struct phy *phy;
Align with other members?
>
> +
> +static int wait_for_latch(void __iomem *addr)
> +{
> + u32 retry = 10;
Why not just int?
> +
> + while (true) {
> + if (!readl(addr))
> + break;
> +
> + if (--retry == 0)
> + return -ETIMEDOUT;
> +
> + usleep_range(10, 20);
> + }
> +
> + return 0;
> +}
[...]
> +
> +static int qcom_dwc3_ss_phy_init(struct qcom_dwc3_usb_phy *phy_dwc3)
> +{
> + u32 data = 0;
> +
Unnecessary initialization.
>
>
> +
> +static struct phy_ops qcom_dwc3_phy_ops = {
Can this be const?
> + .init = qcom_dwc3_phy_init,
> + .exit = qcom_dwc3_phy_exit,
> + .power_on = qcom_dwc3_phy_power_on,
> + .power_off = qcom_dwc3_phy_power_off,
> + .owner = THIS_MODULE,
> +};
> +
[...]
> +
> +static int qcom_dwc3_phy_probe(struct platform_device *pdev)
> +{
> + struct qcom_dwc3_usb_phy*phy_dwc3;
> + struct phy_provider *phy_provider;
> + struct resource *res;
> + const struct of_device_id *match;
> +
> +
Weird two newlines here.
> + phy_dwc3 = devm_kzalloc(>dev, sizeof(*phy_dwc3), GFP_KERNEL);
> + if (!phy_dwc3)
> + return -ENOMEM;
> +
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/9] torture: Address race in module cleanup
On Fri, Sep 12, 2014 at 11:28:36AM -0700, Davidlohr Bueso wrote: > On Fri, 2014-09-12 at 11:04 -0700, Paul E. McKenney wrote: > > On Thu, Sep 11, 2014 at 08:40:21PM -0700, Davidlohr Bueso wrote: > > > When performing module cleanups by calling torture_cleanup() the > > > 'torture_type' string in nullified However, callers are not necessarily > > > done, and might still need to reference the variable. This impacts > > > both rcutorture and locktorture, causing printing things like: > > > > > > [ 94.226618] (null)-torture: Stopping lock_torture_writer task > > > [ 94.226624] (null)-torture: Stopping lock_torture_stats task > > > > > > Thus delay this operation until the very end of the cleanup process. > > > The consequence (which shouldn't matter for this kid of program) is, > > > of course, that we delay the window between rmmod and modprobing, > > > for instance in module_torture_begin(). > > > > > > Signed-off-by: Davidlohr Bueso > > > > Good catch! I had just been ignoring the (null), and my scripting > > doesn't care, but it is better to have it taken care of. > > In addition, for locktorture this issue can cause not only null but the > printing the wrong cleanup string when a new module is loaded with a > different torture_type. That would be even more annoying. ;-) Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rcu] BUG: unable to handle kernel NULL pointer dereference at 000000da
On Mon, Sep 01, 2014 at 04:44:04PM +0800, Fengguang Wu wrote: > Greetings, > > 0day kernel testing robot got the below dmesg and the first bad commit is > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master > commit d860d40327dde251d508a234fa00bd0d90fbb656 > Author: Shan Wei > AuthorDate: Thu Jun 19 14:12:44 2014 -0700 > Commit: Paul E. McKenney > CommitDate: Wed Jul 9 09:15:21 2014 -0700 Hearing nothing from Shan or Pranith... So, I am not seeing this failure in my testing, but my best guess is that the problem is due to the fact that force_quiescent_state() is sometimes invoked with preemption enabled, which breaks __this_cpu_read() though perhaps with very low probability. The common-case call (from __call_rcu_core()) -does- have preemption disabled, in fact, it has interrupts disabled. So unless I hear otherwise, I will simply revert this commit. Thanx, Paul > rcu: Use __this_cpu_read() instead of per_cpu_ptr() > > The __this_cpu_read() function produces better code than does > per_cpu_ptr() on both ARM and x86. For example, gcc (Ubuntu/Linaro > 4.7.3-12ubuntu1) 4.7.3 produces the following: > > ARMv7 per_cpu_ptr(): > > force_quiescent_state: > movr3, sp@, > bicr1, r3, #8128@ tmp171,, > ldrr2, .L98@ tmp169, > bicr1, r1, #63@ tmp170, tmp171, > ldrr3, [r0, #220]@ __ptr, rsp_6(D)->rda > ldrr1, [r1, #20]@ D.35903_68->cpu, D.35903_68->cpu > movr6, r0@ rsp, rsp > ldrr2, [r2, r1, asl #2]@ tmp173, __per_cpu_offset > addr3, r3, r2@ tmp175, __ptr, tmp173 > ldrr5, [r3, #12]@ rnp_old, D.29162_13->mynode > > ARMv7 __this_cpu_read(): > > force_quiescent_state: > ldrr3, [r0, #220]@ rsp_7(D)->rda, rsp_7(D)->rda > movr6, r0@ rsp, rsp > addr3, r3, #12@ __ptr, rsp_7(D)->rda, > ldrr5, [r2, r3]@ rnp_old, *D.29176_13 > > Using gcc 4.8.2: > > x86_64 per_cpu_ptr(): > > movl %gs:cpu_number,%edx# cpu_number, pscr_ret__ > movslq%edx, %rdx# pscr_ret__, pscr_ret__ > movq__per_cpu_offset(,%rdx,8), %rdx# __per_cpu_offset, tmp93 > movq%rdi, %r13# rsp, rsp > movq1000(%rdi), %rax# rsp_9(D)->rda, __ptr > movq24(%rdx,%rax), %r12# _15->mynode, rnp_old > > x86_64 __this_cpu_read(): > > movq%rdi, %r13# rsp, rsp > movq1000(%rdi), %rax# rsp_9(D)->rda, rsp_9(D)->rda > movq %gs:24(%rax),%r12# _10->mynode, rnp_old > > Because this change produces significant benefits for these two very > diverse architectures, this commit makes this change. > > Signed-off-by: Shan Wei > Acked-by: Christoph Lameter > Signed-off-by: Pranith Kumar > Signed-off-by: Paul E. McKenney > Reviewed-by: Josh Triplett > Reviewed-by: Lai Jiangshan > > +---++++ > | | bc1dce514e > | d860d40327 | 9687fd9101 | > +---++++ > | boot_successes| 60 > | 0 | 0 | > | boot_failures | 0 > | 20 | 586| > | BUG:unable_to_handle_kernel_NULL_pointer_dereference | 0 > | 20 || > | Oops | 0 > | 20 | 586| > | EIP_is_at_update_curr | 0 > | 20 || > | Kernel_panic-not_syncing:Fatal_exception | 0 > | 20 | 586| > | backtrace:register_tracer | 0 > | 20 | 586| > | backtrace:init_branch_tracer | 0 > | 20 | 586| > | backtrace:kernel_init_freeable| 0 > | 20 | 586| > | WARNING:at_kernel/trace/ring_buffer.c:rb_reserve_next_event() | 0 > | 0 | 10 | > | BUG:spinlock_bad_magic_on_CPU | 0 > | 0 | 586| > | BUG:unable_to_handle_kernel_paging_request| 0 > | 0 | 586| > | EIP_is_at_spin_dump | 0 > | 0 | 586| > | backtrace:init_irqsoff_tracer | 0 > | 0 | 10 | >
Re: [PATCH 0/8] nohz: Fix nohz kick irq work on tick v2
On Fri, Sep 12, 2014 at 08:05:49PM +0200, Frederic Weisbecker wrote: > > Acked-by: Peter Zijlstra (Intel) > > Intel? :-) Wow. Yeah, moved about a month ago :-) > Note, I fear I'll have to turn the static_cpu_has into cpu_has. The > alternatives code which initialize all static_cpu_has() things > is called from check_bugs() in start_kernel() which is way after > IRQs are enabled for the 1st time. irq_work_tick() has many opportunities > to run in between. Ah well. It was worth a try I suppose. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] clocksource: arch_timer: Allow the device tree to specify the physical timer
On 09/12/14 05:14, Marc Zyngier wrote:
> Hi Christopher,
>
> On 12/09/14 12:43, Christopher Covington wrote:
>> Hi Marc,
>>
>> On 09/11/2014 01:43 PM, Marc Zyngier wrote:
>>> On 11/09/14 18:29, Doug Anderson wrote:
>>>
I did this in the past (again, see Sonny's thread), but didn't
consider myself knowledgeable to know if that was truly a good test:
asm volatile("mrc p15, 0, %0, c1, c1, 0" : "=r" (val));
pr_info("DOUG: val is %#010x", val);
val |= (1 << 2);
asm volatile("mcr p15, 0, %0, c1, c1, 0" : : "r" (val));
val = 0x;
asm volatile("mrc p15, 0, %0, c1, c1, 0" : "=r" (val));
pr_info("DOUG: val is %#010x", val);
The idea being that if you can make modifications to the SCR register
(and see your changes take effect) then you must be in secure mode.
In my case the first printout was 0x0 and the second was 0x4.
>>> The main issue is when you're *not* in secure mode. It is likely that
>>> this will explode badly. This is why I suggested something that is set
>>> by the bootloader (after all. it knows which mode it is booted in), and
>>> that the timer driver can use when the CPU comes up.
>> What exactly does "exploding badly" look like? Causing and undefined
>> instruction exception? That's just a branch with a mode switch. Any reason
>> the
>> code couldn't deal with that or even use that to its advantage?
> We surely can handle the UNDEF and do something there. We just can't do
> it the way Doug described it above.
>
>
I suggested doing that for something else a while ago and Will and Dave
we're not thrilled[1]. The suggestion back then was to use DT to
indicate what mode the kernel is running in.
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-June/105321.html
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] leds: trigger: gpio: make ledtrig-gpio useable with GPIO drivers requiring threaded irqs
On Fri, Sep 12, 2014 at 12:09 AM, Lothar Waßmann wrote: > Hi, > > Bryan Wu wrote: >> On Tue, Sep 9, 2014 at 12:40 AM, Lothar Waßmann >> wrote: >> > When trying to use the LED GPIO trigger with e.g. the PCA953x GPIO >> > driver, request_irq() fails with -EINVAL, because the GPIO driver >> > requires a nested interrupt handler. >> > >> > Use request_any_context_irq() to be able to use any GPIO driver as LED >> > trigger. >> > >> >> Hmmm, what about use request_thread_irq() and put the gpio_trig_work() >> in as the thread_func. >> >> Felipe, can you take a look at this? >> >> Also in the first patch: >> Actually in gpio_trig_irq(), it said: >> /* just schedule_work since gpio_get_value can sleep */ >> schedule_work(_data->work); >> >> Then that means we need to call gpio_get_value_can_sleep() in the >> gpio_trig_work() instead of gpio_get_value(), right? >> > That's exactly what my first patch does! > Yeah, exactly. I'm just curious about the comment here. -Bryan > > Lothar Waßmann > -- > ___ > > Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen > Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10 > Geschäftsführer: Matthias Kaussen > Handelsregistereintrag: Amtsgericht Aachen, HRB 4996 > > www.karo-electronics.de | i...@karo-electronics.de > ___ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 3/3] phy: Add Qualcomm DWC3 HS/SS PHY driver
On Fri, Sep 12, 2014 at 12:50:23PM -0500, Josh Cartwright wrote:
> Hey Andy-
>
> Mostly cosmetic things below:
>
> On Fri, Sep 12, 2014 at 12:29:46PM -0500, Andy Gross wrote:
> > This patch adds a new driver for the Qualcomm USB 3.0 PHY that exists on
> > some
> > Qualcomm platforms. This driver uses the generic PHY framework and will
> > interact with the DWC3 controller.
> >
> > Signed-off-by: Andy Gross
> > ---
> > drivers/phy/Kconfig | 11 +
> > drivers/phy/Makefile|1 +
> > drivers/phy/phy-qcom-dwc3.c | 500
> > +++
> > 3 files changed, 512 insertions(+)
> > create mode 100644 drivers/phy/phy-qcom-dwc3.c
> >
> > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> > index 0dd7427..5d56161 100644
> > --- a/drivers/phy/Kconfig
> > +++ b/drivers/phy/Kconfig
> > @@ -230,4 +230,15 @@ config PHY_XGENE
> > help
> > This option enables support for APM X-Gene SoC multi-purpose PHY.
> >
> > +config PHY_QCOM_DWC3
> > + tristate "QCOM DWC3 USB PHY support"
> > + depends on ARCH_QCOM
> > + depends on HAS_IOMEM
> > + depends on OF
> > + select GENERIC_PHY
> > + help
> > + This option enables support for the Synopsis PHYs present inside the
> > + Qualcomm USB3.0 DWC3 controller. This driver supports both HS and SS
> > + PHY controllers.
> > +
> > endmenu
> > diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> > index 95c69ed..aa16f30 100644
> > --- a/drivers/phy/Makefile
> > +++ b/drivers/phy/Makefile
> > @@ -28,3 +28,4 @@ obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA) +=
> > phy-qcom-ipq806x-sata.o
> > obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY) += phy-spear1310-miphy.o
> > obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o
> > obj-$(CONFIG_PHY_XGENE)+= phy-xgene.o
> > +obj-$(CONFIG_PHY_QCOM_DWC3)+= phy-qcom-dwc3.o
> > diff --git a/drivers/phy/phy-qcom-dwc3.c b/drivers/phy/phy-qcom-dwc3.c
> > new file mode 100644
> > index 000..05b8e1d
> > --- /dev/null
> > +++ b/drivers/phy/phy-qcom-dwc3.c
> [..]
> > +/* TX OVRD DRV LO register bits */
> > +#define TX_OVRD_DRV_LO_AMPLITUDE_MASK 0x007F
> > +#define TX_OVRD_DRV_LO_PREEMPH_MASK0x3F80
> > +#define TX_OVRD_DRV_LO_PREEMPH_SHIFT 7
> > +#define TX_OVRD_DRV_LO_EN BIT(14)
> > +
> > +struct qcom_dwc3_usb_phy;
>
> Do you need this?
No, this was a set of interim changes that should have been squashed.
Incidently, this was used when I had a separate ops table for the phys.
> > +
> > +enum qcom_dwc3_phy_id {
> > + QCOM_DWC3_PHY_UTMI = 0,
> > + QCOM_DWC3_PHY_PIPE,
> > + QCOM_DWC3_PHYS_NUM,
> > +};
> > +
> > +struct qcom_dwc3_usb_phy {
> > + void __iomem*base;
> > + struct device *dev;
> > + struct phy *phy;
> > + enum qcom_dwc3_phy_id index;
> > +
> > + struct clk *xo_clk;
> > + struct clk *ref_clk;
> > +};
> > +
> > +/**
> > + * Write register and read back masked value to confirm it is written
> > + *
> > + * @base - QCOM DWC3 PHY base virtual address.
> > + * @offset - register offset.
> > + * @mask - register bitmask specifying what should be updated
> > + * @val - value to write.
> > + */
> > +static inline void qcom_dwc3_phy_write_readback(
> > + struct qcom_dwc3_usb_phy *phy_dwc3, u32 offset,
> > + const u32 mask, u32 val)
> > +{
> > + u32 write_val, tmp = readl(phy_dwc3->base + offset);
> > +
> > + tmp &= ~mask; /* retain other bits */
> > + write_val = tmp | val;
> > +
> > + writel(write_val, phy_dwc3->base + offset);
> > +
> > + /* Read back to see if val was written */
> > + tmp = readl(phy_dwc3->base + offset);
> > + tmp &= mask;/* clear other bits */
> > +
> > + if (tmp != val)
> > + dev_err(phy_dwc3->dev, "write: %x to QSCRATCH: %x FAILED\n",
> > + val, offset);
> > +}
> > +
> > +static int wait_for_latch(void __iomem *addr)
> > +{
> > + u32 retry = 10;
> > +
> > + while (true) {
> > + if (!readl(addr))
> > + break;
> > +
> > + if (--retry == 0)
> > + return -ETIMEDOUT;
> > +
> > + usleep_range(10, 20);
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +/**
> > + * Write SSPHY register
> > + *
> > + * @base - QCOM DWC3 PHY base virtual address.
> > + * @addr - SSPHY address to write.
> > + * @val - value to write.
> > + */
> > +static int qcom_dwc3_ss_write_phycreg(void __iomem *base, u32 addr, u32
> > val)
> > +{
> > + writel(addr, base + CR_PROTOCOL_DATA_IN_REG);
> > + writel(0x1, base + CR_PROTOCOL_CAP_ADDR_REG);
> > +
> > + if (wait_for_latch(base + CR_PROTOCOL_CAP_ADDR_REG))
> > + return 1;
>
> I'm not too familiar with the GENERIC_PHY infrastructure, does it
> understand that '1' is an error case? I'm wondering if you should
> instead propogate the -ETIMEDOUT up.
Actually, yeah I need to return something < 0. Let me respin to fix
Re: [PATCH 3/9] locktorture: Support mutexes
On Fri, 2014-09-12 at 11:02 -0700, Paul E. McKenney wrote:
> On Thu, Sep 11, 2014 at 08:40:18PM -0700, Davidlohr Bueso wrote:
> > +static void torture_mutex_delay(struct torture_random_state *trsp)
> > +{
> > + const unsigned long longdelay_ms = 100;
> > +
> > + /* We want a long delay occasionally to force massive contention. */
> > + if (!(torture_random(trsp) %
> > + (nrealwriters_stress * 2000 * longdelay_ms)))
> > + mdelay(longdelay_ms * 5);
>
> So let's see... We wait 500 milliseconds about once per 200,000 operations
> per writer. So if we have 5 writers, we wait 500 milliseconds per million
> operations. So each writer will do about 200,000 operations, then there
> will be a half-second gap. But each short operation holds the lock for
> 20 milliseconds, which takes several hours to work through the million
> operations.
>
> So it looks to me like you are in massive contention state either way,
> at least until the next stutter interval shows up.
>
> Is that the intent? Or am I missing something here?
Ah, nice description. Yes, I am aiming for constant massive contention
(should have mentioned this, sorry). I believe it stresses the more
interesting parts of mutexes -- and rwsems, for that matter. If you
think it's excessive, we could decrease the the large wait and/or
increase the short one. I used the factor of the delay by the default
stutter value -- we could also make it always equal.
> > + else
> > + mdelay(longdelay_ms / 5);
> > +#ifdef CONFIG_PREEMPT
> > + if (!(torture_random(trsp) % (nrealwriters_stress * 2)))
> > + preempt_schedule(); /* Allow test to be preempted. */
> > +#endif
> > +}
> > +
> > +static void torture_mutex_unlock(void) __releases(torture_mutex)
> > +{
> > + mutex_unlock(_mutex);
> > +}
> > +
> > +static struct lock_torture_ops mutex_lock_ops = {
> > + .writelock = torture_mutex_lock,
> > + .write_delay= torture_mutex_delay,
> > + .writeunlock= torture_mutex_unlock,
> > + .name = "mutex_lock"
> > +};
> > +
> > /*
> > * Lock torture writer kthread. Repeatedly acquires and releases
> > * the lock, checking for duplicate acquisitions.
> > @@ -352,7 +389,7 @@ static int __init lock_torture_init(void)
> > int i;
> > int firsterr = 0;
> > static struct lock_torture_ops *torture_ops[] = {
> > - _busted_ops, _lock_ops, _lock_irq_ops,
> > + _busted_ops, _lock_ops, _lock_irq_ops,
> > _lock_ops,
> > };
> >
> > if (!torture_init_begin(torture_type, verbose, _runnable))
> > --
>
> And I queued the following patch to catch up the scripting.
Thanks! Completely overlooked the scripting bits. I'll keep it in mind
in the future.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 2/3] usb: dwc3: Add Qualcomm DWC3 glue layer driver
On Fri, Sep 12, 2014 at 12:47:04PM -0500, Felipe Balbi wrote:
> Hi,
>
> On Fri, Sep 12, 2014 at 12:29:45PM -0500, Andy Gross wrote:
> > From: "Ivan T. Ivanov"
> >
> > DWC3 glue layer is hardware layer around Synopsys DesignWare
> > USB3 core. Its purpose is to supply Synopsys IP with required
> > clocks, voltages and interface it with the rest of the SoC.
> >
> > Signed-off-by: Ivan T. Ivanov
> > Signed-off-by: Andy Gross
> > ---
> > drivers/usb/dwc3/Kconfig |9 +++
> > drivers/usb/dwc3/Makefile|1 +
> > drivers/usb/dwc3/dwc3-qcom.c | 133
> > ++
> > 3 files changed, 143 insertions(+)
> > create mode 100644 drivers/usb/dwc3/dwc3-qcom.c
> >
> > diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
> > index 785510a..e9f258e 100644
> > --- a/drivers/usb/dwc3/Kconfig
> > +++ b/drivers/usb/dwc3/Kconfig
> > @@ -80,6 +80,15 @@ config USB_DWC3_KEYSTONE
> > Support of USB2/3 functionality in TI Keystone2 platforms.
> > Say 'Y' or 'M' here if you have one such device
> >
> > +config USB_DWC3_QCOM
> > + tristate "Qualcomm Platforms"
> > + depends on ARCH_QCOM || COMPILE_TEST
> > + default USB_DWC3
> > + select PHY_QCOM_DWC3
>
> I would rather steer away from selecting the PHY as it prevents having
> PHYs as modules. Also, this will add a Kconfig warning for selecting a
> symbol that doesn't exist (yet).
True. The one downside is people having to fish around to find the phy config
option.
>
> If it's all the same with you, I can clean this up when applying.
>
Thats fine.
> > diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
> > new file mode 100644
> > index 000..2067c04
> > --- /dev/null
> > +++ b/drivers/usb/dwc3/dwc3-qcom.c
> > @@ -0,0 +1,133 @@
> > +/* Copyright (c) 2013-2014, The Linux Foundation. All rights reserved.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 and
> > + * only version 2 as published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
>
> doesn't look like you need regulator/consumer.h and usb/phy.h. I can
> clean it up when applying.
Ack, interim changes that should have been removed. you can do that or I can
respin no big deal.
>
> > +struct dwc3_qcom {
> > + struct device *dev;
> > +
> > + struct clk *core_clk;
> > + struct clk *iface_clk;
> > + struct clk *sleep_clk;
> > +};
> > +
> > +static int dwc3_qcom_probe(struct platform_device *pdev)
> > +{
> > + struct device_node *node = pdev->dev.of_node;
> > + struct dwc3_qcom *qdwc;
> > + int ret = 0;
> > +
> > + qdwc = devm_kzalloc(>dev, sizeof(*qdwc), GFP_KERNEL);
> > + if (!qdwc)
> > + return -ENOMEM;
> > +
> > + platform_set_drvdata(pdev, qdwc);
> > +
> > + qdwc->dev = >dev;
> > +
> > + qdwc->core_clk = devm_clk_get(qdwc->dev, "core");
> > + if (IS_ERR(qdwc->core_clk)) {
> > + dev_dbg(qdwc->dev, "failed to get core clock\n");
>
> this one would be a dev_err() since core can't work without its clock. I
> can fix when applying.
Right. That's fine.
>
> --
> balbi
--
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 00/13] PCI: Device configuration cleanup
On Fri, Sep 12, 2014 at 11:02 AM, Bjorn Helgaas wrote: > > Finally, it tweaks several _HPP/_HPX things where we do things not > required by the spec and I haven't seen any other good reason for them: Looks ok to me, although, as always, resource management changes just makes me worry that things worked "by mistake" before. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC 1/2] lib: string: Remove duplicated function
Hello, On Fri, Sep 12, 2014 at 11:01:17AM +0200, Rasmus Villemoes wrote: > On Fri, Sep 12 2014, Andrew Morton wrote: > > > On Wed, 27 Aug 2014 09:36:01 +0200 Rasmus Villemoes > > wrote: > >> strncasecmp is the POSIX name for this functionality. So rename the > >> non-broken function to the standard name. To minimize the impact on > >> the rest of the kernel (and since both are exported to modules), make > >> strnicmp a wrapper for strncasecmp. Maybe it's a good idea to convert all existing users of strnicmp() strncasecmp() and then mark the strnicmp() wrapper as __deprecated for later removal? > > I guess it's safe to assume that nobody was depending on the > > strncasecmp() bug. > > Hm, I thought so as well, but decided to double check. I found one minor > issue; maybe Tejun can tell if my analysis is correct. > > In drivers/ata/libata-core.c, ata_parse_force_one(), it is not > immediately clear to me that val cannot end up being the empty > string. With the buggy strncasecmp, the continue branch is always > followed (since fp->name is not empty); however, with strncasecmp with > the correct semantics, the empty string is obviously a prefix of every > fp->name. So even though the comment says that "1.5" is an ok > abbreviation of "1.5Gbps", I don't think the intention was to allow "" > to be an abbreviation of everything. Anyway, the worst that can happen > seems to be that "ambigious value" [sic] becomes the *reason instead > of "unknown value". Sounds right to me and it shouldn't matter at all. > > Yes, please prepare the strnicmp()->strncasecmp() patches and let's get > > them merged up. After a kernel release or two we can zap the > > back-compat wrapper. Ooh, somebody already suggested the same. :) Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3 v3] mmu_notifier: Allow to manage CPU external TLBs
Hi Andrew, thanks for your review, I tried to answer your questions below. On Wed, Sep 10, 2014 at 03:01:25PM -0700, Andrew Morton wrote: > On Tue, 9 Sep 2014 17:43:51 +0200 Joerg Roedel wrote: > > So both call-backs can't be used to safely flush any non-CPU > > TLB because _start() is called too early and _end() too > > late. > > There's a lot of missing information here. Why don't the existing > callbacks suit non-CPU TLBs? What is different about them? Please > update the changelog to contain all this context. The existing call-backs are called too early or too late. Specifically, invalidate_range_start() is called when all pages are still mapped and invalidate_range_end() when all pages are unmapped and potentially freed. This is fine when the users of the mmu_notifiers manage their own SoftTLB, like KVM does. When the TLB is managed in software it is easy to wipe out entries for a given range and prevent new entries to be established until invalidate_range_end is called. But when the user of mmu_notifiers has to manage a hardware TLB it can still wipe out TLB entries in invalidate_range_start, but it can't make sure that no new TLB entries in the given range are established between invalidate_range_start and invalidate_range_end. [ Actually the current AMD IOMMUv2 code tries to do that with setting the setting an empty page-table for the non-CPU TLB, but this causes address translation errors which end up in device failures. ] But to avoid silent data corruption the TLB entries need to be flushed out of the non-CPU hardware TLB when the pages are unmapped (at this point in time no _new_ TLB entries can be established in the non-CPU TLB) but not yet freed (as the non-CPU TLB may still have _existing_ entries pointing to the pages about to be freed). So to fix this problem we need to catch the moment when the Linux VMM flushes remote TLBs (as a non-CPU TLB is not very different in its flushing requirements from any other remote CPU TLB), as this is the point in time when the pages are unmapped but _not_ yet freed. The mmu_notifier_invalidate_range() function aims to catch that moment. > > In the AMD IOMMUv2 driver this is currently implemented by > > assigning an empty page-table to the external device between > > _start() and _end(). But as tests have shown this doesn't > > work as external devices don't re-fault infinitly but enter > > a failure state after some time. > > More missing info. Why are these faults occurring? Is there some > device activity which is trying to fault in pages, but the CPU is > executing code between _start() and _end() so the driver must refuse to > instantiate a page to satisfy the fault? That's just a guess, and I > shouldn't be guessing. Please update the changelog to fully describe > the dynamic activity which is causing this. The device (usually a GPU) runs some process (for example a compute job) that directly accesses a Linux process address space. Any access to a process address space can cause a page-fault, whether the access comes from the CPU or a remote device. When the page-fault comes from a compute job running on a GPU, is is reported to Linux by an IOMMU interrupt. The current implementation of invalidate_range_start/end assigns an empty page-table, which causes many page-faults from the GPU process, resulting in an interrupt storm for the IOMMU. The fault handler doesn't handle the fault if an invalidate_range_start/end pair is active, but just reports back SUCESS to the device to let it refault the page then (refaulting is the same strategy KVM implements). But existing GPUs that make use of this feature don't refault indefinitly, after a certain number of faults for the same address the device enters a failure state and needs to be resetted.L > > Next problem with this solution is that it causes an > > interrupt storm for IO page faults to be handled when an > > empty page-table is assigned. > > Also too skimpy. I *think* this is a variant of the problem in the > preceding paragraph. We get a fault storm (which is problem 2) and > sometimes the faulting device gives up (which is problem 1). > > Or something. Please de-fog all of this. Right, I will update the description to be more clear. > > Furthermore the _start()/end() notifiers only catch the > > moment when page mappings are released, but not page-table > > pages. But this is necessary for managing external TLBs when > > the page-table is shared with the CPU. > > How come? As mmu_notifiers are not used for managing TLBs that share the same page-table as the CPU uses, there was not need to catch the page-table freeing events, so it is not available yet. > > Any comments and review appreciated! > > The patchset looks decent, although I find it had to review because I > just wasn't provided with enough of the thinking that went into it. I > have enough info to look at the C code, but not enough info to identify > and evaluate
Re: [PATCH 01/11 v6] coresight: add CoreSight core layer framework
Further to Greg's comments...
On Thu, Sep 11, 2014 at 09:49:08AM -0600, mathieu.poir...@linaro.org wrote:
> +int coresight_enable(struct coresight_device *csdev)
> +{
> + int ret = 0;
> + LIST_HEAD(path);
> +
> + WARN_ON(IS_ERR_OR_NULL(csdev));
Please don't do this kind of checking, it just makes stuff a lot more
noisy than it needs to be, and it doesn't give any value what so ever.
I've seen code where it seems the coding style required that quite
literally every function does extensive checking of function arguments,
and every function returns a status. This does nothing to stop bugs.
In fact, it makes things a /lot/ worse because there is then soo much
junk in every function that you can't read what the function is doing
anymore. Imagine memset() validating its arguments and returning a
status value... I kid not.
The point here is that if a NULL pointer is passed to this function,
the above WARN_ON gets triggered, and we get a backtrace. We then
continue on, take the semaphore, and then dereference the NULL pointer
causing another backtrace. So the WARN_ON was utterly pointless.
Just reference the pointer and don't bother with these silly checks.
> +
> + down(_semaphore);
What is your reason for using a semaphore rather than a mutex?
...
> +/**
> + * coresight_timeout - loop until a bit has changed to a specific state.
> + * @addr: base address of the area of interest.
> + * @offset: address of a register, starting from @addr.
> + * @position: the position of the bit of interest.
> + * @value: the value the bit should have.
> + *
> + * Returns as soon as the bit has taken the desired state or TIMEOU_US has
Typo?
> + * elapsed, which ever happens first.
> + */
> +
> +void coresight_timeout(void __iomem *addr, u32 offset, int position, int
> value)
> +{
> + int i;
> + u32 val;
> +
> + for (i = TIMEOUT_US; i > 0; i--) {
> + val = __raw_readl(addr + offset);
> + /* waiting on the bit to go from 0 to 1 */
> + if (value) {
> + if (val & BIT(position))
> + return;
> + /* waiting on the bit to go from 1 to 0 */
> + } else {
> + if (!(val & BIT(position)))
> + return;
> + }
> +
> + /* The specification doesn't say how long we are expected
> + * to wait.
> + */
/*
* The kernel commeting style for multi-line comments is
* like this. Note the line opening the comment has no
* comment text.
*/
> + udelay(1);
So the duration is arbitary.
> + }
> +
> + WARN(1,
> + "coresight: timeout observed when proving at offset %#x\n",
> + offset);
This is also buggy. On the last loop iteration, we delay 1us, decrement
i, and then test for it being greater than zero. If it isn't, print
this message and do a backtrace (why is a backtrace useful here?)
The important point here is that we waited for 1us, and /didn't/ test
for success before claiming timeout. That makes the final 1us wait
entirely useless.
> diff --git a/drivers/coresight/of_coresight.c
> b/drivers/coresight/of_coresight.c
> new file mode 100644
> index 000..c780b4b
> --- /dev/null
> +++ b/drivers/coresight/of_coresight.c
> @@ -0,0 +1,201 @@
...
> +struct coresight_platform_data *of_get_coresight_platform_data(
> + struct device *dev, struct device_node *node)
> +{
> + int id, i = 0, ret = 0;
> + struct device_node *cpu;
> + struct coresight_platform_data *pdata;
> + struct of_endpoint endpoint, rendpoint;
> + struct device_node *ep = NULL;
> + struct device_node *rparent = NULL;
> + struct device_node *rport = NULL;
> +
> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata)
> + return ERR_PTR(-ENOMEM);
So, what are the rules for calling this function? What is the expected
lifetime of this pdata structure in relation to 'dev' ?
You do realise that when a driver unbinds from 'dev', this allocation
will be freed. If you hold on to the pointer and dereference it, you
could be accessing memory allocated for other purposes at that point.
> diff --git a/include/linux/coresight.h b/include/linux/coresight.h
> new file mode 100644
> index 000..5b22287
> --- /dev/null
> +++ b/include/linux/coresight.h
> @@ -0,0 +1,275 @@
...
> +/**
> + * @name:name of the entry to appear under the component's
> + debugfs sub-directory.
> + * @mode:what operation can be performed on the entry.
> + * @ops: specific manipulation to be done using this entry.
> + */
Wrong commenting style. Please read Documentation/kernel-doc-nano-HOWTO.txt
for information how to document structures.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
To
Re: [PATCH v8 08/10] x86, mpx: add prctl commands PR_MPX_REGISTER, PR_MPX_UNREGISTER
On Fri, 12 Sep 2014, Thomas Gleixner wrote: > On Fri, 12 Sep 2014, Dave Hansen wrote: > The proper solution to this problem is: > > do_bounds() > bd_addr = get_bd_addr_from_xsave(); > bd_entry = bndstatus & ADDR_MASK: Just for clarification. You CANNOT avoid the xsave here because it's the only way to access BNDSTATUS according to the manual. "The BNDCFGU and BNDSTATUS registers are accessible only with XSAVE/XRSTOR family of instructions" So there is no point to cache BNDCFGU as you get it anyway when you need to retrieve the invalid BD entry. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3 v3] mmu_notifier: Allow to manage CPU external TLBs
On Wed, Sep 10, 2014 at 08:02:12PM -0400, Jerome Glisse wrote: > On Wed, Sep 10, 2014 at 03:01:25PM -0700, Andrew Morton wrote: > > On Tue, 9 Sep 2014 17:43:51 +0200 Joerg Roedel wrote: > > > > > here is a patch-set to extend the mmu_notifiers in the Linux > > > kernel to allow managing CPU external TLBs. Those TLBs may > > > be implemented in IOMMUs or any other external device, e.g. > > > ATS/PRI capable PCI devices. > > > > > > The problem with managing these TLBs are the semantics of > > > the invalidate_range_start/end call-backs currently > > > available. Currently the subsystem using mmu_notifiers has > > > to guarantee that no new TLB entries are established between > > > invalidate_range_start/end. Furthermore the > > > invalidate_range_start() function is called when all pages > > > are still mapped and invalidate_range_end() when the pages > > > are unmapped an already freed. > > > > > > So both call-backs can't be used to safely flush any non-CPU > > > TLB because _start() is called too early and _end() too > > > late. > > > > There's a lot of missing information here. Why don't the existing > > callbacks suit non-CPU TLBs? What is different about them? Please > > update the changelog to contain all this context. > > So unlike KVM or any current user of the mmu_notifier api, any PCIE > ATS/PASID capable hardware IOMMUv2 for AMD and forgot the marketing > name for Intel (probably VTd) implementation walk the cpu page table > on there own and have there own TLB cache. In fact not only the iommu > can have a TLB cache but any single PCIE hardware can implement its > own local TLB cache. > > So if we flush the IOMMU and device TLB inside the range_start callback > there is a chance that the hw will just rewalk the cpu page table and > repopulate its TLB before the CPU page table is actually updated. > > Now if we shoot down the TLB inside the range_end callback, then we > are too late ie the CPU page table is already populated with new entry > and all the TLB in the IOMMU an in device might be pointing to the old > pages. > > So the aim of this callback is to happen right after the CPU page table > is updated but before the old page is freed or recycled. Note that it > is also safe for COW and other transition from like read only to read > and write or the other way around. > > > > > > In the AMD IOMMUv2 driver this is currently implemented by > > > assigning an empty page-table to the external device between > > > _start() and _end(). But as tests have shown this doesn't > > > work as external devices don't re-fault infinitly but enter > > > a failure state after some time. > > > > More missing info. Why are these faults occurring? Is there some > > device activity which is trying to fault in pages, but the CPU is > > executing code between _start() and _end() so the driver must refuse to > > instantiate a page to satisfy the fault? That's just a guess, and I > > shouldn't be guessing. Please update the changelog to fully describe > > the dynamic activity which is causing this. > > The hack that was use prior to this patch was to point the IOMMU to an > empty page table (a zero page) inside the range_start() callback and > shoot down the TLB but this meant that the device might enter inside a > storm of page fault. GPU can have thousand of threads and because during > invalidation the empty page table is use they all starts triggering page > fault even if they were not trying to access the range being invalidated. > It turns out that when this happens current hw like AMD GPU actually stop > working after a while ie the hw stumble because there is too much fault > going on. > > > > > > Next problem with this solution is that it causes an > > > interrupt storm for IO page faults to be handled when an > > > empty page-table is assigned. > > > > Also too skimpy. I *think* this is a variant of the problem in the > > preceding paragraph. We get a fault storm (which is problem 2) and > > sometimes the faulting device gives up (which is problem 1). > > > > Or something. Please de-fog all of this. > > > > Does above explanation help understand the issue ? Given that on each > device page fault an IRQ is trigger (well the way the hw works is bit > more complex than that). > > > > Furthermore the _start()/end() notifiers only catch the > > > moment when page mappings are released, but not page-table > > > pages. But this is necessary for managing external TLBs when > > > the page-table is shared with the CPU. > > > > How come? > > As explained above end() might happens after page that were previously > mapped are free or recycled. > > > > > > To solve this situation I wrote a patch-set to introduce a > > > new notifier call-back: mmu_notifer_invalidate_range(). This > > > notifier lifts the strict requirements that no new > > > references are taken in the range between _start() and > > > _end(). When the subsystem can't guarantee that any new > > > references are taken is
Re: [PATCH V2] MIPS: bugfix of coherentio variable default setup
Hello.
On 9/8/2014 10:10 PM, Leonid Yegoshin wrote:
Patch commit b6d92b4a6bdb880b39789c677b952c53a437028d
Just commit.
MIPS: Add option to disable software I/O coherency.
It's enough to just cite the summary in parens after SHA1 ID.
Some MIPS controllers have hardware I/O coherency. This patch
detects those and turns off software coherency. A new kernel
command line option also allows the user to manually turn
software coherency on or off.
in fact enforces L2 cache flushes even on systems with IOCU.
The default value of coherentio is 0 and is not changed even with IOCU.
It is a serious performance problem because it destroys all IOCU performance
advantages.
It is fixed by setting coherentio to tri-state with default value as (-1) and
setup a final value during platform coherency setup.
Signed-off-by: Leonid Yegoshin
---
V2: Missed signature added
---
arch/mips/include/asm/mach-generic/dma-coherence.h |7 ++-
arch/mips/mm/c-r4k.c |2 +-
arch/mips/mm/dma-default.c |2 +-
arch/mips/mti-malta/malta-setup.c |8 ++--
arch/mips/pci/pci-alchemy.c|2 +-
5 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/arch/mips/include/asm/mach-generic/dma-coherence.h
b/arch/mips/include/asm/mach-generic/dma-coherence.h
index 7629c35..b4563df 100644
--- a/arch/mips/include/asm/mach-generic/dma-coherence.h
+++ b/arch/mips/include/asm/mach-generic/dma-coherence.h
@@ -49,7 +49,12 @@ static inline int plat_dma_supported(struct device *dev, u64
mask)
static inline int plat_device_is_coherent(struct device *dev)
{
- return coherentio;
+#ifdef CONFIG_DMA_COHERENT
+ return 1;
+#else
+ return (coherentio > 0);
*return* never needs parens around the value.
+#endif
+
}
#ifdef CONFIG_SWIOTLB
diff --git a/arch/mips/mti-malta/malta-setup.c
b/arch/mips/mti-malta/malta-setup.c
index db7c9e5..48039fd 100644
--- a/arch/mips/mti-malta/malta-setup.c
+++ b/arch/mips/mti-malta/malta-setup.c
@@ -147,13 +147,17 @@ static void __init plat_setup_iocoherency(void)
if (plat_enable_iocoherency()) {
if (coherentio == 0)
pr_info("Hardware DMA cache coherency disabled\n");
- else
+ else {
+ coherentio = 1;
You now need the parens around another arm of the *if* statement too. Such
is the kernel style. :-)
pr_info("Hardware DMA cache coherency enabled\n");
+ }
} else {
if (coherentio == 1)
pr_info("Hardware DMA cache coherency unsupported, but
enabled from command line!\n");
- else
+ else {
+ coherentio = 0;
Likewise.
pr_info("Software DMA cache coherency enabled\n");
+ }
}
#else
if (!plat_enable_iocoherency())
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] ASoC: fsl_ssi: refine ipg clock usage in this module
On Fri, Sep 12, 2014 at 06:35:15PM +0800, Shengjiu Wang wrote: > Check if ipg clock is in clock-names property, then we can move the > ipg clock enable and disable operation to startup and shutdown, that > is only enable ipg clock when ssi is working and keep clock is disabled > when ssi is in idle. > But when the checking is failed, remain the clock control as before. > > Signed-off-by: Shengjiu Wang The patch looks fine to me. I tested the has_ipg_clk_name == true case, and it works fine. As long as there's no further objection, I can give an Acked-by. (I think Timur and Markus may like to have a test as well.) Thank you Nicolin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] pstore-ram: Allow optional mapping with pgprot_noncached
On some ARMs at least the memory can be mapped pgprot_noncached()
and still be working for atomic operations. As pointed out by
Colin Cross , in some cases you do want to use
pgprot_noncached() if the SoC supports it to see a debug printk
just before a write hanging the system.
On ARMs, the atomic operations on strongly ordered memory are
implementation defined. So let's provide an optional kernel parameter
for configuring noncached memory, and use pgprot_writecombine() by
default.
Cc: Arnd Bergmann
Cc: Rob Herring
Cc: Randy Dunlap
Cc: Anton Vorontsov
Cc: Colin Cross
Cc: Kees Cook
Cc: Olof Johansson
Cc: Tony Luck
Cc: Russell King
Signed-off-by: Tony Lindgren
---
Documentation/ramoops.txt | 12 ++--
fs/pstore/ram.c| 13 +++--
fs/pstore/ram_core.c | 31 ++-
include/linux/pstore_ram.h | 4 +++-
4 files changed, 46 insertions(+), 14 deletions(-)
diff --git a/Documentation/ramoops.txt b/Documentation/ramoops.txt
index 69b3cac..2dab135 100644
--- a/Documentation/ramoops.txt
+++ b/Documentation/ramoops.txt
@@ -14,11 +14,18 @@ survive after a restart.
1. Ramoops concepts
-Ramoops uses a predefined memory area to store the dump. The start and size of
-the memory area are set using two variables:
+Ramoops uses a predefined memory area to store the dump. The start and size
+and type of the memory area are set using three variables:
* "mem_address" for the start
* "mem_size" for the size. The memory size will be rounded down to a
power of two.
+ * "mem_cached" to specifiy if the memory is cached or not.
+
+Note disabling "mem_cached" may not be supported on all architectures as
+pstore depends on atomic operations. At least on ARM, clearing "mem_cached"
+will cause the memory to be mapped strongly ordered. And atomic operations
+on strongly ordered memory are implementation defined, and won't work on
+many ARMs such as omap.
The memory area is divided into "record_size" chunks (also rounded down to
power of two) and each oops/panic writes a "record_size" chunk of
@@ -55,6 +62,7 @@ Setting the ramoops parameters can be done in 2 different
manners:
static struct ramoops_platform_data ramoops_data = {
.mem_size = <...>,
.mem_address= <...>,
+.mem_cached = <...>,
.record_size= <...>,
.dump_oops = <...>,
.ecc= <...>,
diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index 3b57443..53ddcb2 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -61,6 +61,11 @@ module_param(mem_size, ulong, 0400);
MODULE_PARM_DESC(mem_size,
"size of reserved RAM used to store oops/panic logs");
+static unsigned int mem_cached = 1;
+module_param(mem_cached, uint, 0600);
+MODULE_PARM_DESC(mem_cached,
+ "set to 1 to use cached memory, 0 to use uncached (default 1)");
+
static int dump_oops = 1;
module_param(dump_oops, int, 0600);
MODULE_PARM_DESC(dump_oops,
@@ -79,6 +84,7 @@ struct ramoops_context {
struct persistent_ram_zone *fprz;
phys_addr_t phys_addr;
unsigned long size;
+ unsigned int cached;
size_t record_size;
size_t console_size;
size_t ftrace_size;
@@ -358,7 +364,8 @@ static int ramoops_init_przs(struct device *dev, struct
ramoops_context *cxt,
size_t sz = cxt->record_size;
cxt->przs[i] = persistent_ram_new(*paddr, sz, 0,
- >ecc_info);
+ >ecc_info,
+ cxt->cached);
if (IS_ERR(cxt->przs[i])) {
err = PTR_ERR(cxt->przs[i]);
dev_err(dev, "failed to request mem region
(0x%zx@0x%llx): %d\n",
@@ -388,7 +395,7 @@ static int ramoops_init_prz(struct device *dev, struct
ramoops_context *cxt,
return -ENOMEM;
}
- *prz = persistent_ram_new(*paddr, sz, sig, >ecc_info);
+ *prz = persistent_ram_new(*paddr, sz, sig, >ecc_info, cxt->cached);
if (IS_ERR(*prz)) {
int err = PTR_ERR(*prz);
@@ -435,6 +442,7 @@ static int ramoops_probe(struct platform_device *pdev)
cxt->size = pdata->mem_size;
cxt->phys_addr = pdata->mem_address;
+ cxt->cached = pdata->mem_cached;
cxt->record_size = pdata->record_size;
cxt->console_size = pdata->console_size;
cxt->ftrace_size = pdata->ftrace_size;
@@ -564,6 +572,7 @@ static void ramoops_register_dummy(void)
dummy_data->mem_size = mem_size;
dummy_data->mem_address = mem_address;
+ dummy_data->mem_cached = 1;
dummy_data->record_size = record_size;
dummy_data->console_size = ramoops_console_size;
dummy_data->ftrace_size = ramoops_ftrace_size;
diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c
index
[PATCH 1/2] pstore-ram: Fix hangs by using write-combine mappings
From: Rob Herring
Currently trying to use pstore on at least ARMs can hang as we're
mapping the peristent RAM with pgprot_noncached().
On ARMs, pgprot_noncached() will actually make the memory strongly
ordered, and as the atomic operations pstore uses are implementation
defined for strongly ordered memory, they may not work. So basically
atomic operations have undefined behavior on ARM for device or strongly
ordered memory types.
Let's fix the issue by using write-combine variants for mappings. This
corresponds to normal, non-cacheable memory on ARM. For many other
architectures, this change does not change the mapping type as by
default we have:
#define pgprot_writecombine pgprot_noncached
The reason why pgprot_noncached() was originaly used for pstore
is because Colin Cross had observed lost
debug prints right before a device hanging write operation on some
systems. For the platforms supporting pgprot_noncached(), we can
add a an optional configuration option to support that. But let's
get pstore working first before adding new features.
Cc: Arnd Bergmann
Cc: Anton Vorontsov
Cc: Colin Cross
Cc: Kees Cook
Cc: Olof Johansson
Cc: Tony Luck
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Rob Herring
[t...@atomide.com: updated description]
Signed-off-by: Tony Lindgren
---
fs/pstore/ram_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c
index 9d7b9a8..24f94b0 100644
--- a/fs/pstore/ram_core.c
+++ b/fs/pstore/ram_core.c
@@ -392,7 +392,7 @@ static void *persistent_ram_vmap(phys_addr_t start, size_t
size)
page_start = start - offset_in_page(start);
page_count = DIV_ROUND_UP(size + offset_in_page(start), PAGE_SIZE);
- prot = pgprot_noncached(PAGE_KERNEL);
+ prot = pgprot_writecombine(PAGE_KERNEL);
pages = kmalloc_array(page_count, sizeof(struct page *), GFP_KERNEL);
if (!pages) {
@@ -422,7 +422,7 @@ static void *persistent_ram_iomap(phys_addr_t start, size_t
size)
buffer_start_add = buffer_start_add_locked;
buffer_size_add = buffer_size_add_locked;
- return ioremap(start, size);
+ return ioremap_wc(start, size);
}
static int persistent_ram_buffer_map(phys_addr_t start, phys_addr_t size,
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/9] torture: Address race in module cleanup
On Fri, 2014-09-12 at 11:04 -0700, Paul E. McKenney wrote: > On Thu, Sep 11, 2014 at 08:40:21PM -0700, Davidlohr Bueso wrote: > > When performing module cleanups by calling torture_cleanup() the > > 'torture_type' string in nullified However, callers are not necessarily > > done, and might still need to reference the variable. This impacts > > both rcutorture and locktorture, causing printing things like: > > > > [ 94.226618] (null)-torture: Stopping lock_torture_writer task > > [ 94.226624] (null)-torture: Stopping lock_torture_stats task > > > > Thus delay this operation until the very end of the cleanup process. > > The consequence (which shouldn't matter for this kid of program) is, > > of course, that we delay the window between rmmod and modprobing, > > for instance in module_torture_begin(). > > > > Signed-off-by: Davidlohr Bueso > > Good catch! I had just been ignoring the (null), and my scripting > doesn't care, but it is better to have it taken care of. In addition, for locktorture this issue can cause not only null but the printing the wrong cleanup string when a new module is loaded with a different torture_type. Thanks, Davidlohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] char/misc driver fixes for 3.17-rc5
The following changes since commit 69e273c0b0a3c337a521d083374c918dc52c666f: Linux 3.17-rc3 (2014-08-31 18:23:04 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/ tags/char-misc-3.17-rc5 for you to fetch changes up to 3f0d97d97f2b539cf9ac746be4ec097259e6a8d0: Lattice ECP3 FPGA: Check firmware pointer (2014-09-08 14:38:14 -0700) Char/Misc driver fix for 3.17-rc5 Here is one misc driver fix for 3.17-rc5. It resolves a kernel oops that can happen in the lattice FPGA driver if the firmware isn't present on the system. It's been in the linux-next tree for a while now. Signed-off-by: Greg Kroah-Hartman Jean-Michel Hautbois (1): Lattice ECP3 FPGA: Check firmware pointer drivers/misc/lattice-ecp3-config.c | 5 + 1 file changed, 5 insertions(+) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: unisys: uislib: uislib.c: sparse warning of context imbalance
Sudip Mukherjee wrote: > fixed sparse warning : context imbalance in 'destroy_device' > unexpected unlock > this patch will generate warning from checkpatch for > lines over 80 character , but since those are user-visible strings > so it was not modified. > > Signed-off-by: Sudip Mukherjee I tested this patch and it looks good also. Thanks! :) -- Ben Tested-by: Benjamin Romer Acked-by: Benjamin Romer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] Staging driver fixes for 3.17-rc5
The following changes since commit 69e273c0b0a3c337a521d083374c918dc52c666f: Linux 3.17-rc3 (2014-08-31 18:23:04 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/ tags/staging-3.17-rc5 for you to fetch changes up to 3ea411c56ef58a1827cf06fdcdeb14fa9265be09: android: fix reference leak in sync_fence_create (2014-09-08 13:42:00 -0700) Staging driver fixes for 3.17-rc5 Here are 3 tiny staging driver fixes for 3.17-rc5. Two are fixes for the imx-drm driver, resolving issues that have been reported. The other is a memory leak fix for the Android sync driver, due to changes that went into 3.17-rc1. All have been in linux-next for a while. Signed-off-by: Greg Kroah-Hartman Maarten Lankhorst (1): android: fix reference leak in sync_fence_create Russell King (2): imx-drm: ipuv3-plane: fix ipu_plane_dpms() imx-drm: imx-ldb: fix NULL pointer in imx_ldb_unbind() drivers/staging/android/sync.c| 1 - drivers/staging/imx-drm/imx-ldb.c | 3 +++ drivers/staging/imx-drm/ipuv3-plane.c | 3 ++- 3 files changed, 5 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] TTY/Serial patches for 3.17-rc5
The following changes since commit 69e273c0b0a3c337a521d083374c918dc52c666f: Linux 3.17-rc3 (2014-08-31 18:23:04 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/ tags/tty-3.17-rc5 for you to fetch changes up to 6731af573ac28de2297002992f38caa760e3dadf: tty: xuartps: Fix tx_emtpy() callback (2014-09-08 16:33:56 -0700) TTY/Serial fixes for 3.17-rc5 Here are 3 patches for 3.17-rc5. Two serial driver fixes that resolve some reported issues, and one new device id. All have been in linux-next just fine. Signed-off-by: Greg Kroah-Hartman Alan Cox (1): serial: 8250_dw: Add ACPI ID for Intel Braswell Lars-Peter Clausen (1): tty: xuartps: Fix tx_emtpy() callback Richard Genoud (1): tty/serial: at91: BUG: disable interrupts when !UART_ENABLE_MS() drivers/tty/serial/8250/8250_dw.c | 1 + drivers/tty/serial/atmel_serial.c | 43 +- drivers/tty/serial/xilinx_uartps.c | 2 +- 3 files changed, 44 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] USB driver fixes for 3.17-rc5
The following changes since commit 69e273c0b0a3c337a521d083374c918dc52c666f:
Linux 3.17-rc3 (2014-08-31 18:23:04 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/
tags/usb-3.17-rc5
for you to fetch changes up to e2c60989dc7e9c6fd28d234f70501a8c93c726aa:
Merge tag 'fixes-for-v3.17-rc4' of
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus
(2014-09-11 15:08:14 -0700)
USB fixes for 3.17-rc5
Here are some USB and PHY fixes for 3.17-rc5.
Nothing major here, just a number of tiny fixes for reported issues, and
some new device ids as well.
All have been tested in linux-next.
Signed-off-by: Greg Kroah-Hartman
Al Cooper (1):
usb: xhci: Fix OOPS in xhci error handling code
Alan Stern (1):
USB: document the 'u' flag for usb-storage quirks parameter
Bin Liu (1):
usb: musb: cppi41: fix not transmitting zero length packet issue
Bjørn Mork (2):
USB: sierra: avoid CDC class functions on "68A3" devices
USB: sierra: add 1199:68AA device ID
Felipe Balbi (5):
usb: dwc3: core: fix order of PM runtime calls
usb: dwc3: core: fix ordering for PHY suspend
usb: dwc3: omap: fix ordering for runtime pm calls
usb: dwc3: fix TRB completion when multiple TRBs are started
usb: host: xhci: fix compliance mode workaround
Greg Kroah-Hartman (4):
Merge tag 'for-3.17-rc' of git://git.kernel.org/.../kishon/linux-phy into
usb-linus
Merge tag 'fixes-for-v3.17-rc3' of git://git.kernel.org/.../balbi/usb
into usb-linus
Merge tag 'usb-serial-3.17-rc4' of
git://git.kernel.org/.../johan/usb-serial into usb-linus
Merge tag 'fixes-for-v3.17-rc4' of git://git.kernel.org/.../balbi/usb
into usb-linus
Hans de Goede (2):
uas: Disable uas on ASM1051 devices
uas: Add missing le16_to_cpu calls to asm1051 / asm1053 usb-id check
Ivan T. Ivanov (2):
usb: chipidea: msm: Use USB PHY API to control PHY state
usb: chipidea: msm: Initialize PHY on reset event
Joe Lawrence (1):
usb: hub: take hub->hdev reference when processing from eventlist
Johan Hovold (3):
USB: zte_ev: fix removed PIDs
USB: ftdi_sio: add support for NOVITUS Bono E thermal printer
USB: zte_ev: fix removed PIDs
Kamil Debski (3):
MAINTAINERS: add entry for the Samsung USB2 PHY driver
usb: dwc2/gadget: fix phy disable sequence
usb: dwc2/gadget: fix phy initialization sequence
Lee Jones (1):
phy: miphy365x: Select GENERIC_PHY instead of depending on it
Marek Szyprowski (3):
usb: dwc2/gadget: break infinite loop in endpoint disable code
usb: dwc2/gadget: do not call disconnect method in pullup
usb: dwc2/gadget: delay enabling irq once hardware is configured properly
Mark (1):
storage: Add single-LUN quirk for Jaz USB Adapter
Mathias Nyman (2):
xhci: Fix null pointer dereference if xhci initialization fails
xhci: fix oops when xhci resumes from hibernate with hw lpm capable
devices
Peter Chen (2):
usb: phy: mxs: add imx6sx support
doc: dt: mxs-phy: add compatible string for imx6sx-usbphy
Piotr Król (1):
usb: usbip: fix usbip.h path in userspace tool
Rasmus Villemoes (1):
usb: gadget: fusb300_udc.h: Fix typo in include guard
Ricardo Ribalda Delgado (1):
usb: gadget: net2280: Fix invalid handling of Reset irq
Robert Baldyga (2):
usb: gadget: f_fs: fix the redundant ep files problem
usb: dwc2/gadget: avoid disabling ep0
Sjoerd Simons (1):
phy: exynos5-usbdrd: Add MODULE_DEVICE_TABLE entry
Taylor Braun-Jones (1):
USB: ftdi_sio: Add support for GE Healthcare Nemo Tracker device
Thierry Reding (1):
usb: phy: tegra: Avoid use of sizeof(void)
Thomas Pugliese (1):
uwb: init beacon cache entry before registering uwb device
Tony Lindgren (2):
usb: phy: twl4030-usb: Fix regressions to runtime PM on omaps
usb: phy: twl4030-usb: Fix lost interrupts after ID pin goes down
Yoshihiro Shimoda (4):
usb: renesas_usbhs: fix the behavior of some usbhs_pkt_handle
usb: renesas_usbhs: protect mod->irq_{bemp,brdy}sts by spin lock
usb: renesas_usbhs: fix the condition of is_done in usbhsf_dma_push_done
usb: renesas_usbhs: fix the usb_pkt_pop()
Zhuang Jin Can (1):
usb: dwc3: gadget: Fix desc NULL pointer in dwc3_gadget_ep_queue()
Documentation/devicetree/bindings/usb/mxs-phy.txt | 1 +
Documentation/kernel-parameters.txt | 1 +
MAINTAINERS | 13 +++
drivers/phy/Kconfig | 2 +-
drivers/phy/phy-exynos5-usbdrd.c | 1 +
drivers/phy/phy-twl4030-usb.c | 121 +-
drivers/usb/chipidea/ci_hdrc_msm.c| 7 +-
Re: [PATCH 01/11 v6] coresight: add CoreSight core layer framework
On Fri, Sep 12, 2014 at 11:41:44AM -0600, Mathieu Poirier wrote:
> Good morning and thanks for the review. Pls see comments below.
>
> Mathieu
>
> On 11 September 2014 14:33, Greg KH wrote:
> > Some first impressions in glancing at the code, not a complete review at
> > all:
> >
> > On Thu, Sep 11, 2014 at 09:49:08AM -0600, mathieu.poir...@linaro.org wrote:
> >> --- /dev/null
> >> +++ b/drivers/coresight/coresight.c
> >> @@ -0,0 +1,663 @@
> >> +/* Copyright (c) 2012, The Linux Foundation. All rights reserved.
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify
> >> + * it under the terms of the GNU General Public License version 2 and
> >> + * only version 2 as published by the Free Software Foundation.
> >> + *
> >> + * This program is distributed in the hope that it will be useful,
> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> >> + * GNU General Public License for more details.
> >> + */
> >> +
> >> +#define pr_fmt(fmt) "coresight: " fmt
> >
> > MODULE_NAME ?
>
> Is this what you had in mind?
>
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
Sorry, yes, that's much better and "portable".
But as you are using the driver model, the odds of you ever using a pr_*
call is all but none, so why do you even need this?
>
> >
> >> +
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +
> >> +#include "coresight-priv.h"
> >> +
> >> +struct dentry *cs_debugfs_parent = NULL;
> >> +
> >> +static LIST_HEAD(coresight_orph_conns);
> >> +static LIST_HEAD(coresight_devs);
> >
> > You are a struct device, you don't need a separate list, why not just
> > iterate over your bus list of devices?
>
> Because coresight devices are not powered on the bus. As such, every
> time we iterate over the bus we'd need to setup the clock for the
> device, power up its domain (if necessary) and lookup the device ID.
> Isn't better to simply keep a list of the devices that were found at
> boot time and use that whenever we want to make configuration changes?
You have that list already, as part of the bus list in the driver core.
I'm not asking you to "power up" anything, just use the data structures
the kernel already provides for you.
> With regards to @coresight_orph_conns, on top of the above problem
> we'd also have to add a flag in the @coresight_device structure to
> indicate that a device has been connected to the topology or not. To
> me using a list is much cleaner.
A single flag is "cleaner" than a whole separate list, not to mention
simpler to understand :)
> >> +/**
> >> + * @id: unique ID of the component.
> >> + * @conns: list of connections associated to this component.
> >> + * @type:as defined by @coresight_dev_type.
> >> + * @subtype: as defined by @coresight_dev_subtype.
> >> + * @ops: generic operations for this component, as defined
> >> + by @coresight_ops.
> >> + * @de: handle on a component's debugfs entry.
> >> + * @dev: The device entity associated to this component.
> >> + * @kref:keeping count on component references.
> >> + * @dev_link:link of current component into list of all components
> >> + discovered in the system.
> >> + * @path_link: link of current component into the path being
> >> enabled.
> >> + * @owner: typically "THIS_MODULE".
> >> + * @enable: 'true' if component is currently part of an active path.
> >> + * @activated: 'true' only if a _sink_ has been activated. A sink
> >> can be
> >> + activated but not yet enabled. Enabling for a _sink_
> >> + happens when a source has been selected for that it.
> >> + */
> >> +struct coresight_device {
> >> + int id;
> >
> > Why not use the device name instead?
>
> With regards to memory footprint it is better to keep a single "int"
> as ID (which is the their memory map start address) than the full
> string associated with the device name. Let's take a funnel for
> example that has up to 8 input port. To build a path between source
> and sink we need to keep information about device that are connected
> to each port. At this time we use the component's ID, i.e 4 byte. If
> we were to use device names, ex "2004.funnel_cluster0", we are
> using 24 byte and that, 8 times.
>
> Moreover using device names would also mean that we have to used
> @stcmp everytime we want do lookups. To me using a single integer to
> identify coresight components is a much better solution.
Don't try to optimize for something that isn't an issue at all. You
aren't searching for devices based on id in any time-critical section,
and you already have the device id string, so you aren't saving any
memory, but the
Re: [PATCH 1/4] usb: hub: convert khubd into workqueue
On Fri, Sep 12, 2014 at 02:21:05PM +0200, Petr Mladek wrote: > There is no need to have separate kthread for handling USB hub events. > It is more elegant to use the workqueue framework. > > The workqueue is allocated as unbound, cpu intensive, and freezable. I'd just go with WQ_FREEZABLE. As a general rule of thumb, please only use attributes which are strictly necessary. If the default behavior turns out to be not so good for typical wq usages (and AFAICS khubd seems fairly typical), we should be changing the default behavior. Each usage deviating complicates the long-term prospect. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 8/9] locktorture: Support rwsems
On Thu, Sep 11, 2014 at 09:41:30PM -0700, Davidlohr Bueso wrote:
> We can easily do so with our new reader lock support. Just an arbitrary
> design default: readers have higher (5x) critical region latencies than
> writers: 50 ms and 10 ms, respectively.
Except in the massive contention case, where the writers get longer
delays than the readers, correct?
I again am guessing that you are relying on stutter intervals to allow
the locks to be in any state other than massively contended.
And patch to add this to the default set run by the scripts below.
> Signed-off-by: Davidlohr Bueso
> ---
> Documentation/locking/locktorture.txt | 2 ++
> kernel/locking/locktorture.c | 68
> ++-
> 2 files changed, 69 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/locking/locktorture.txt
> b/Documentation/locking/locktorture.txt
> index 1bdeb71..f7d99e2 100644
> --- a/Documentation/locking/locktorture.txt
> +++ b/Documentation/locking/locktorture.txt
> @@ -47,6 +47,8 @@ torture_type Type of lock to torture. By default,
> only spinlocks will
>
>o "mutex_lock": mutex_lock() and mutex_unlock() pairs.
>
> + o "rwsem_lock": read/write down() and up() semaphore pairs.
> +
> torture_runnable Start locktorture at module init. By default it will begin
> once the module is loaded.
>
> diff --git a/kernel/locking/locktorture.c b/kernel/locking/locktorture.c
> index c1073d7..8480118 100644
> --- a/kernel/locking/locktorture.c
> +++ b/kernel/locking/locktorture.c
> @@ -265,6 +265,71 @@ static struct lock_torture_ops mutex_lock_ops = {
> .name = "mutex_lock"
> };
>
> +static DECLARE_RWSEM(torture_rwsem);
> +static int torture_rwsem_down_write(void) __acquires(torture_rwsem)
> +{
> + down_write(_rwsem);
> + return 0;
> +}
> +
> +static void torture_rwsem_write_delay(struct torture_random_state *trsp)
> +{
> + const unsigned long longdelay_ms = 100;
> +
> + /* We want a long delay occasionally to force massive contention. */
> + if (!(torture_random(trsp) %
> + (nrealwriters_stress * 2000 * longdelay_ms)))
> + mdelay(longdelay_ms * 10);
> + else
> + mdelay(longdelay_ms / 10);
> +#ifdef CONFIG_PREEMPT
> + if (!(torture_random(trsp) % (nrealwriters_stress * 2)))
> + preempt_schedule(); /* Allow test to be preempted. */
> +#endif
> +}
> +
> +static void torture_rwsem_up_write(void) __releases(torture_rwsem)
> +{
> + up_write(_rwsem);
> +}
> +
> +static int torture_rwsem_down_read(void) __acquires(torture_rwsem)
> +{
> + down_read(_rwsem);
> + return 0;
> +}
> +
> +static void torture_rwsem_read_delay(struct torture_random_state *trsp)
> +{
> + const unsigned long longdelay_ms = 100;
> +
> + /* We want a long delay occasionally to force massive contention. */
> + if (!(torture_random(trsp) %
> + (nrealwriters_stress * 2000 * longdelay_ms)))
> + mdelay(longdelay_ms * 2);
> + else
> + mdelay(longdelay_ms / 2);
> +#ifdef CONFIG_PREEMPT
> + if (!(torture_random(trsp) % (nrealreaders_stress * 2)))
> + preempt_schedule(); /* Allow test to be preempted. */
> +#endif
> +}
> +
> +static void torture_rwsem_up_read(void) __releases(torture_rwsem)
> +{
> + up_read(_rwsem);
> +}
> +
> +static struct lock_torture_ops rwsem_lock_ops = {
> + .writelock = torture_rwsem_down_write,
> + .write_delay= torture_rwsem_write_delay,
> + .writeunlock= torture_rwsem_up_write,
> + .readlock = torture_rwsem_down_read,
> + .read_delay = torture_rwsem_read_delay,
> + .readunlock = torture_rwsem_up_read,
> + .name = "rwsem_lock"
> +};
> +
> /*
> * Lock torture writer kthread. Repeatedly acquires and releases
> * the lock, checking for duplicate acquisitions.
> @@ -467,7 +532,8 @@ static int __init lock_torture_init(void)
> int i, j;
> int firsterr = 0;
> static struct lock_torture_ops *torture_ops[] = {
> - _busted_ops, _lock_ops, _lock_irq_ops,
> _lock_ops,
> + _busted_ops, _lock_ops, _lock_irq_ops,
> + _lock_ops, _lock_ops,
> };
>
> if (!torture_init_begin(torture_type, verbose, _runnable))
> --
> 1.8.4.5
locktorture: Add test scenario for rwsem_lock
Signed-off-by: Paul E. McKenney
diff --git a/tools/testing/selftests/rcutorture/configs/lock/CFLIST
b/tools/testing/selftests/rcutorture/configs/lock/CFLIST
index 901bafde4588..6108137da770 100644
--- a/tools/testing/selftests/rcutorture/configs/lock/CFLIST
+++ b/tools/testing/selftests/rcutorture/configs/lock/CFLIST
@@ -1,2 +1,3 @@
LOCK01
LOCK02
+LOCK03
diff --git a/tools/testing/selftests/rcutorture/configs/lock/LOCK03
b/tools/testing/selftests/rcutorture/configs/lock/LOCK03
new file mode 100644
[PATCH v1 07/13] ACPI / hotplug / PCI: Remove pci_configure_slot() usage
We now configure each PCI device as it is enumerated, in pci_device_add(),
so remove the configuration done in acpiphp.
That configuration, in pci_configure_device(), does not include the
MPS/MRRS configuration done by pcie_bus_configure_settings(), so keep
that here.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/hotplug/acpiphp_glue.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/pci/hotplug/acpiphp_glue.c
b/drivers/pci/hotplug/acpiphp_glue.c
index 70741c8c46a0..a6f8e0ba0bfe 100644
--- a/drivers/pci/hotplug/acpiphp_glue.c
+++ b/drivers/pci/hotplug/acpiphp_glue.c
@@ -61,7 +61,6 @@ static DEFINE_MUTEX(bridge_mutex);
static int acpiphp_hotplug_notify(struct acpi_device *adev, u32 type);
static void acpiphp_post_dock_fixup(struct acpi_device *adev);
static void acpiphp_sanitize_bus(struct pci_bus *bus);
-static void acpiphp_set_hpp_values(struct pci_bus *bus);
static void hotplug_event(u32 type, struct acpiphp_context *context);
static void free_bridge(struct kref *kref);
@@ -510,7 +509,7 @@ static void enable_slot(struct acpiphp_slot *slot)
__pci_bus_assign_resources(bus, _list, NULL);
acpiphp_sanitize_bus(bus);
- acpiphp_set_hpp_values(bus);
+ pcie_bus_configure_settings(bus);
acpiphp_set_acpi_region(slot);
list_for_each_entry(dev, >devices, bus_list) {
@@ -702,14 +701,6 @@ static void acpiphp_check_bridge(struct acpiphp_bridge
*bridge)
}
}
-static void acpiphp_set_hpp_values(struct pci_bus *bus)
-{
- struct pci_dev *dev;
-
- list_for_each_entry(dev, >devices, bus_list)
- pci_configure_slot(dev);
-}
-
/*
* Remove devices for which we could not assign resources, call
* arch specific code to fix-up the bus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 12/13] PCI: Preserve MPS and MRRS when applying _HPX settings
Linux manages MPS and MRRS settings to keep them consistent across the PCIe fabric. BIOS doesn't participate in Linux scheme, so ignore that part of any _HPX settings it supplies. Signed-off-by: Bjorn Helgaas --- drivers/pci/probe.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 1ff2105ba401..cb411fbb6435 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -1301,6 +1301,16 @@ static void program_hpp_type2(struct pci_dev *dev, struct hpp_type2 *hpp) return; } + /* +* Don't allow _HPX to change MPS or MRRS settings. We manage +* those to make sure they're consistent with the rest of the +* platform. +*/ + hpp->pci_exp_devctl_and |= PCI_EXP_DEVCTL_PAYLOAD | + PCI_EXP_DEVCTL_READRQ; + hpp->pci_exp_devctl_or &= ~(PCI_EXP_DEVCTL_PAYLOAD | + PCI_EXP_DEVCTL_READRQ); + /* Initialize Device Control Register */ pcie_capability_clear_and_set_word(dev, PCI_EXP_DEVCTL, ~hpp->pci_exp_devctl_and, hpp->pci_exp_devctl_or); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 10/13] PCI: Preserve BIOS PCI_COMMAND_SERR and PCI_COMMAND_PARITY settings
Do not clear PCI_COMMAND_SERR or PCI_COMMAND_PARITY based on _HPP. The
spec (ACPI rev 5.0, sec 6.2.7) says that when "Enable SERR" is set to 1,
we should enable SERR in the command register. It says nothing about
*disabling* SERR or PERR; in fact, the example in 6.2.7.1 says we should
leave PERR alone unless "Enable PERR" is 1.
For hot-added devices, this probably doesn't matter because they power up
with these bits cleared. But in addition to hot-plugged devices, the spec
allows the platform to use _HPP for "configuration of PCI devices not
configured by the BIOS at system boot," and it may make a difference for
devices present at boot.
This change means that if BIOS enables SERR or PERR on a device, and it
supplies _HPP or _HPX with the SERR or PERR bits *cleared*, we will leave
SERR or PERR reporting enabled on that device instead of disabling it.
See also 40abb96c51bb ("pciehp: Fix programming hotplug parameters"), where
this code was first added.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/probe.c |8
1 file changed, 8 deletions(-)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 003d112a783d..a16b3472b70d 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1264,12 +1264,8 @@ static void program_hpp_type0(struct pci_dev *dev,
struct hpp_type0 *hpp)
pci_read_config_word(dev, PCI_COMMAND, _cmd);
if (hpp->enable_serr)
pci_cmd |= PCI_COMMAND_SERR;
- else
- pci_cmd &= ~PCI_COMMAND_SERR;
if (hpp->enable_perr)
pci_cmd |= PCI_COMMAND_PARITY;
- else
- pci_cmd &= ~PCI_COMMAND_PARITY;
pci_write_config_word(dev, PCI_COMMAND, pci_cmd);
/* Program bridge control value */
@@ -1279,12 +1275,8 @@ static void program_hpp_type0(struct pci_dev *dev,
struct hpp_type0 *hpp)
pci_read_config_word(dev, PCI_BRIDGE_CONTROL, _bctl);
if (hpp->enable_serr)
pci_bctl |= PCI_BRIDGE_CTL_SERR;
- else
- pci_bctl &= ~PCI_BRIDGE_CTL_SERR;
if (hpp->enable_perr)
pci_bctl |= PCI_BRIDGE_CTL_PARITY;
- else
- pci_bctl &= ~PCI_BRIDGE_CTL_PARITY;
pci_write_config_word(dev, PCI_BRIDGE_CONTROL, pci_bctl);
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/8] nohz: Fix nohz kick irq work on tick v2
On Thu, Sep 11, 2014 at 10:28:12AM +0200, Peter Zijlstra wrote: > On Wed, Sep 10, 2014 at 11:33:20PM +0200, Frederic Weisbecker wrote: > > > Frederic Weisbecker (7): > > nohz: Move nohz full init call to tick init > > irq_work: Force raised irq work to run on irq work interrupt > > x86: Tell irq work about self IPI support > > arm: Tell irq work about self IPI support > > arm64: Tell irq work about self IPI support > > nohz: Consolidate nohz full init code > > nohz: nohz full depends on irq work self IPI support > > > > Peter Zijlstra (1): > > irq_work: Introduce arch_irq_work_has_interrupt() > > Looks ok to me. > > Acked-by: Peter Zijlstra (Intel) Intel? :-) Wow. Thanks a lot! Note, I fear I'll have to turn the static_cpu_has into cpu_has. The alternatives code which initialize all static_cpu_has() things is called from check_bugs() in start_kernel() which is way after IRQs are enabled for the 1st time. irq_work_tick() has many opportunities to run in between. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/9] torture: Address race in module cleanup
On Thu, Sep 11, 2014 at 08:40:21PM -0700, Davidlohr Bueso wrote:
> When performing module cleanups by calling torture_cleanup() the
> 'torture_type' string in nullified However, callers are not necessarily
> done, and might still need to reference the variable. This impacts
> both rcutorture and locktorture, causing printing things like:
>
> [ 94.226618] (null)-torture: Stopping lock_torture_writer task
> [ 94.226624] (null)-torture: Stopping lock_torture_stats task
>
> Thus delay this operation until the very end of the cleanup process.
> The consequence (which shouldn't matter for this kid of program) is,
> of course, that we delay the window between rmmod and modprobing,
> for instance in module_torture_begin().
>
> Signed-off-by: Davidlohr Bueso
Good catch! I had just been ignoring the (null), and my scripting
doesn't care, but it is better to have it taken care of.
Thanx, Paul
> ---
> include/linux/torture.h | 3 ++-
> kernel/locking/locktorture.c | 3 ++-
> kernel/rcu/rcutorture.c | 3 ++-
> kernel/torture.c | 16 +---
> 4 files changed, 19 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/torture.h b/include/linux/torture.h
> index 5ca58fc..301b628 100644
> --- a/include/linux/torture.h
> +++ b/include/linux/torture.h
> @@ -77,7 +77,8 @@ int torture_stutter_init(int s);
> /* Initialization and cleanup. */
> bool torture_init_begin(char *ttype, bool v, int *runnable);
> void torture_init_end(void);
> -bool torture_cleanup(void);
> +bool torture_cleanup_begin(void);
> +void torture_cleanup_end(void);
> bool torture_must_stop(void);
> bool torture_must_stop_irq(void);
> void torture_kthread_stopping(char *title);
> diff --git a/kernel/locking/locktorture.c b/kernel/locking/locktorture.c
> index de703a7..988267c 100644
> --- a/kernel/locking/locktorture.c
> +++ b/kernel/locking/locktorture.c
> @@ -361,7 +361,7 @@ static void lock_torture_cleanup(void)
> {
> int i;
>
> - if (torture_cleanup())
> + if (torture_cleanup_begin())
> return;
>
> if (writer_tasks) {
> @@ -384,6 +384,7 @@ static void lock_torture_cleanup(void)
> else
> lock_torture_print_module_parms(cur_ops,
> "End of test: SUCCESS");
> + torture_cleanup_end();
> }
>
> static int __init lock_torture_init(void)
> diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
> index 948a769..57a2792 100644
> --- a/kernel/rcu/rcutorture.c
> +++ b/kernel/rcu/rcutorture.c
> @@ -1418,7 +1418,7 @@ rcu_torture_cleanup(void)
> int i;
>
> rcutorture_record_test_transition();
> - if (torture_cleanup()) {
> + if (torture_cleanup_begin()) {
> if (cur_ops->cb_barrier != NULL)
> cur_ops->cb_barrier();
> return;
> @@ -1468,6 +1468,7 @@ rcu_torture_cleanup(void)
> "End of test: RCU_HOTPLUG");
> else
> rcu_torture_print_module_parms(cur_ops, "End of test: SUCCESS");
> + torture_cleanup_end();
> }
>
> #ifdef CONFIG_DEBUG_OBJECTS_RCU_HEAD
> diff --git a/kernel/torture.c b/kernel/torture.c
> index d600af2..07a5c3d 100644
> --- a/kernel/torture.c
> +++ b/kernel/torture.c
> @@ -635,8 +635,13 @@ EXPORT_SYMBOL_GPL(torture_init_end);
> *
> * This must be called before the caller starts shutting down its own
> * kthreads.
> + *
> + * Both torture_cleanup_begin() and torture_cleanup_end() must be paired,
> + * in order to correctly perform the cleanup. They are separated because
> + * threads can still need to reference the torture_type type, thus nullify
> + * only after completing all other relevant calls.
> */
> -bool torture_cleanup(void)
> +bool torture_cleanup_begin(void)
> {
> mutex_lock(_mutex);
> if (ACCESS_ONCE(fullstop) == FULLSTOP_SHUTDOWN) {
> @@ -651,12 +656,17 @@ bool torture_cleanup(void)
> torture_shuffle_cleanup();
> torture_stutter_cleanup();
> torture_onoff_cleanup();
> + return false;
> +}
> +EXPORT_SYMBOL_GPL(torture_cleanup_begin);
> +
> +void torture_cleanup_end(void)
> +{
> mutex_lock(_mutex);
> torture_type = NULL;
> mutex_unlock(_mutex);
> - return false;
> }
> -EXPORT_SYMBOL_GPL(torture_cleanup);
> +EXPORT_SYMBOL_GPL(torture_cleanup_end);
>
> /*
> * Is it time for the current torture test to stop?
> --
> 1.8.4.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 08/13] PCI: Remove unused pci_configure_slot()
All pci_configure_slot() uses have been removed, so remove the definition
as well.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/probe.c | 27 ---
include/linux/pci_hotplug.h |2 --
2 files changed, 29 deletions(-)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 93d2b41163fa..4b3b29bc7a82 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1358,33 +1358,6 @@ static void program_hpp_type2(struct pci_dev *dev,
struct hpp_type2 *hpp)
*/
}
-void pci_configure_slot(struct pci_dev *dev)
-{
- struct pci_dev *cdev;
- struct hotplug_params hpp;
-
- if (!(dev->hdr_type == PCI_HEADER_TYPE_NORMAL ||
- (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE &&
- (dev->class >> 8) == PCI_CLASS_BRIDGE_PCI)))
- return;
-
- pcie_bus_configure_settings(dev->bus);
-
- memset(, 0, sizeof(hpp));
- pci_get_hp_params(dev, );
-
- program_hpp_type2(dev, hpp.t2);
- program_hpp_type1(dev, hpp.t1);
- program_hpp_type0(dev, hpp.t0);
-
- if (dev->subordinate) {
- list_for_each_entry(cdev, >subordinate->devices,
- bus_list)
- pci_configure_slot(cdev);
- }
-}
-EXPORT_SYMBOL_GPL(pci_configure_slot);
-
static void pci_configure_device(struct pci_dev *dev)
{
struct hotplug_params hpp;
diff --git a/include/linux/pci_hotplug.h b/include/linux/pci_hotplug.h
index 5f2e559af6b0..2706ee9a4327 100644
--- a/include/linux/pci_hotplug.h
+++ b/include/linux/pci_hotplug.h
@@ -187,6 +187,4 @@ static inline int pci_get_hp_params(struct pci_dev *dev,
return -ENODEV;
}
#endif
-
-void pci_configure_slot(struct pci_dev *dev);
#endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 11/13] PCI: Apply _HPP settings to all hot-added PCI devices
We currently apply _HPP settings only to:
- non-bridge devices, and
- PCI-to-PCI bridges
i.e., we do not apply them to PCI-to-ISA bridges and the like. It has been
that way since _HPP support was added by 40abb96c51bb ("pciehp: Fix
programming hotplug parameters"), but I don't think there's any reason to
exclude these other bridges.
Apply _HPP settings to hot-added PCI devices of any type.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/probe.c |5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index a16b3472b70d..1ff2105ba401 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1351,11 +1351,6 @@ static void pci_configure_device(struct pci_dev *dev)
if (system_state == SYSTEM_BOOTING)
return;
- if (!(dev->hdr_type == PCI_HEADER_TYPE_NORMAL ||
- (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE &&
- (dev->class >> 8) == PCI_CLASS_BRIDGE_PCI)))
- return;
-
memset(, 0, sizeof(hpp));
ret = pci_get_hp_params(dev, );
if (ret)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/9] locktorture: Add infrastructure for torturing read locks
On Fri, 2014-09-12 at 09:06 -0700, Paul E. McKenney wrote: > On Thu, Sep 11, 2014 at 09:40:41PM -0700, Davidlohr Bueso wrote: > > In addition, introduce a new nreaders_stress module parameter. The > > default number of readers will be the same number of writers threads. > > Writer threads are interleaved with readers. Documentation is updated, > > respectively. > > Nice!!! > > Conditional fairness checks in the future? (As in verifying that if > the rwlock in question claims some degree of fairness, trying to break > that guarantee, and contrariwise, if the lock is unfair, making sure > to avoid starvation during the test?) Yep, there are all sorts of interesting things we can measure in rw runs. In this set I'm only trying to establish a minimum infrastructure. Future work will be pretty trivial (at least code wise) to implement once this sort of thing is in. > And one nit below. [...] > C initialization does this already, no need to add the NULL initializers. Sure, I always tend to be explicit when initializing. I guess you won't like the context initialization in patch 9/9. Thanks, Davidlohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 13/13] PCI: Configure *all* devices, not just hot-added ones
There's not really a good way to determine whether firmware has already configured a device with _HPP/_HPX settings. On legacy systems, the BIOS has probably configured everything, but on UEFI systems it is not required to do so. Per the PCI Firmware Specification, rev 3.1, sec 3.5, if PCI_COMMAND_IO or PCI_COMMAND_MEMORY is set, we can assume firmware has set the corresponding BARs and maybe we can assume it has configured the rest of the device. And if a bridge has PCI_COMMAND_PARITY or PCI_COMMAND_SERR set, we can assume firmware has configured the bridge. But we can't tell much about devices without BARs. I think it should be safe to apply _HPP and _HPX settings anyway, even if firmware has already configured the device, so configure everything we find. Signed-off-by: Bjorn Helgaas --- drivers/pci/probe.c |3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index cb411fbb6435..290c657da0b9 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -1358,9 +1358,6 @@ static void pci_configure_device(struct pci_dev *dev) struct hotplug_params hpp; int ret; - if (system_state == SYSTEM_BOOTING) - return; - memset(, 0, sizeof(hpp)); ret = pci_get_hp_params(dev, ); if (ret) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 09/13] PCI: Apply _HPP settings to PCIe devices as well as PCI and PCI-X
The ACPI _HPP method was defined before PCIe existed, so its documentation
only mentions PCI. The _HPX Type 0 setting record is essentially identical
to _HPP, but the spec (ACPI rev 5.0, sec 6.2.8.1) says it should be applied
to PCI, PCI-X, and PCIe devices, with settings being ignored if they are
not applicable.
Some platforms with both conventional PCI and PCIe devices provide only
_HPP (not _HPX), so treat _HPP the same way as an _HPX Type 0 record and
apply it to PCIe devices as well as PCI and PCI-X.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/probe.c |9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 4b3b29bc7a82..003d112a783d 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1249,15 +1249,8 @@ static void program_hpp_type0(struct pci_dev *dev,
struct hpp_type0 *hpp)
{
u16 pci_cmd, pci_bctl;
- if (!hpp) {
- /*
-* Perhaps we *should* use default settings for PCIe, but
-* pciehp didn't, so we won't either.
-*/
- if (pci_is_pcie(dev))
- return;
+ if (!hpp)
hpp = _default_type0;
- }
if (hpp->revision > 1) {
dev_warn(>dev,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 06/13] PCI: shpchp: Remove pci_configure_slot() usage
We now configure each PCI device as it is enumerated, in pci_device_add(),
so remove the configuration done in shpchp.
That configuration, in pci_configure_device(), does not include the
MPS/MRRS configuration done by pcie_bus_configure_settings(), so keep
that here.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/hotplug/shpchp_pci.c |8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/pci/hotplug/shpchp_pci.c b/drivers/pci/hotplug/shpchp_pci.c
index 469454e0cc48..f8cd3a27e351 100644
--- a/drivers/pci/hotplug/shpchp_pci.c
+++ b/drivers/pci/hotplug/shpchp_pci.c
@@ -69,13 +69,7 @@ int shpchp_configure_device(struct slot *p_slot)
}
pci_assign_unassigned_bridge_resources(bridge);
-
- list_for_each_entry(dev, >devices, bus_list) {
- if (PCI_SLOT(dev->devfn) != p_slot->device)
- continue;
- pci_configure_slot(dev);
- }
-
+ pcie_bus_configure_settings(parent);
pci_bus_add_devices(parent);
out:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 01/13] PCI: Remove "no hotplug settings from platform" warning
We print way too many messages like this:
pci :00:00.0: no hotplug settings from platform
pci :00:00.0: using default PCI settings
This usually happens when the platform doesn't supply an ACPI _HPP method,
but the method is optional, so there's no point in warning about it.
Not only are the messages useless, but we call pci_configure_slot() far too
many times, so they're repeated many times. I'll fix the overuse of
pci_configure_slot() too, but that will wait until the next merge window.
For now, just remove both log messages.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=84391
Signed-off-by: Bjorn Helgaas
---
drivers/pci/hotplug/pcihp_slot.c |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/pci/hotplug/pcihp_slot.c b/drivers/pci/hotplug/pcihp_slot.c
index e246a10a0d2c..3e36ec8d708a 100644
--- a/drivers/pci/hotplug/pcihp_slot.c
+++ b/drivers/pci/hotplug/pcihp_slot.c
@@ -46,7 +46,6 @@ static void program_hpp_type0(struct pci_dev *dev, struct
hpp_type0 *hpp)
*/
if (pci_is_pcie(dev))
return;
- dev_info(>dev, "using default PCI settings\n");
hpp = _default_type0;
}
@@ -153,7 +152,6 @@ void pci_configure_slot(struct pci_dev *dev)
{
struct pci_dev *cdev;
struct hotplug_params hpp;
- int ret;
if (!(dev->hdr_type == PCI_HEADER_TYPE_NORMAL ||
(dev->hdr_type == PCI_HEADER_TYPE_BRIDGE &&
@@ -163,9 +161,7 @@ void pci_configure_slot(struct pci_dev *dev)
pcie_bus_configure_settings(dev->bus);
memset(, 0, sizeof(hpp));
- ret = pci_get_hp_params(dev, );
- if (ret)
- dev_warn(>dev, "no hotplug settings from platform\n");
+ pci_get_hp_params(dev, );
program_hpp_type2(dev, hpp.t2);
program_hpp_type1(dev, hpp.t1);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 02/13] PCI: Move pci_configure_slot() to drivers/pci/probe.c
Move pci_configure_slot() and related functions from
drivers/pci/hotplug/pcihp_slot to drivers/pci/probe.c.
This is to prepare for doing device configuration during the normal
enumeration process instead of just after hot-add.
No functional change.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/hotplug/Makefile |2
drivers/pci/hotplug/pcihp_slot.c | 176 --
drivers/pci/probe.c | 148
3 files changed, 149 insertions(+), 177 deletions(-)
delete mode 100644 drivers/pci/hotplug/pcihp_slot.c
diff --git a/drivers/pci/hotplug/Makefile b/drivers/pci/hotplug/Makefile
index 3e6532b945c1..4a9aa08b08f1 100644
--- a/drivers/pci/hotplug/Makefile
+++ b/drivers/pci/hotplug/Makefile
@@ -24,7 +24,7 @@ obj-$(CONFIG_HOTPLUG_PCI_S390)+=
s390_pci_hpc.o
obj-$(CONFIG_HOTPLUG_PCI_ACPI_IBM) += acpiphp_ibm.o
-pci_hotplug-objs := pci_hotplug_core.o pcihp_slot.o
+pci_hotplug-objs := pci_hotplug_core.o
ifdef CONFIG_HOTPLUG_PCI_CPCI
pci_hotplug-objs += cpci_hotplug_core.o \
diff --git a/drivers/pci/hotplug/pcihp_slot.c b/drivers/pci/hotplug/pcihp_slot.c
deleted file mode 100644
index 3e36ec8d708a..
--- a/drivers/pci/hotplug/pcihp_slot.c
+++ /dev/null
@@ -1,176 +0,0 @@
-/*
- * Copyright (C) 1995,2001 Compaq Computer Corporation
- * Copyright (C) 2001 Greg Kroah-Hartman (g...@kroah.com)
- * Copyright (C) 2001 IBM Corp.
- * Copyright (C) 2003-2004 Intel Corporation
- * (c) Copyright 2009 Hewlett-Packard Development Company, L.P.
- *
- * All rights reserved.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or (at
- * your option) any later version.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or
- * NON INFRINGEMENT. See the GNU General Public License for more
- * details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
- */
-
-#include
-#include
-#include
-
-static struct hpp_type0 pci_default_type0 = {
- .revision = 1,
- .cache_line_size = 8,
- .latency_timer = 0x40,
- .enable_serr = 0,
- .enable_perr = 0,
-};
-
-static void program_hpp_type0(struct pci_dev *dev, struct hpp_type0 *hpp)
-{
- u16 pci_cmd, pci_bctl;
-
- if (!hpp) {
- /*
-* Perhaps we *should* use default settings for PCIe, but
-* pciehp didn't, so we won't either.
-*/
- if (pci_is_pcie(dev))
- return;
- hpp = _default_type0;
- }
-
- if (hpp->revision > 1) {
- dev_warn(>dev,
-"PCI settings rev %d not supported; using defaults\n",
-hpp->revision);
- hpp = _default_type0;
- }
-
- pci_write_config_byte(dev, PCI_CACHE_LINE_SIZE, hpp->cache_line_size);
- pci_write_config_byte(dev, PCI_LATENCY_TIMER, hpp->latency_timer);
- pci_read_config_word(dev, PCI_COMMAND, _cmd);
- if (hpp->enable_serr)
- pci_cmd |= PCI_COMMAND_SERR;
- else
- pci_cmd &= ~PCI_COMMAND_SERR;
- if (hpp->enable_perr)
- pci_cmd |= PCI_COMMAND_PARITY;
- else
- pci_cmd &= ~PCI_COMMAND_PARITY;
- pci_write_config_word(dev, PCI_COMMAND, pci_cmd);
-
- /* Program bridge control value */
- if ((dev->class >> 8) == PCI_CLASS_BRIDGE_PCI) {
- pci_write_config_byte(dev, PCI_SEC_LATENCY_TIMER,
- hpp->latency_timer);
- pci_read_config_word(dev, PCI_BRIDGE_CONTROL, _bctl);
- if (hpp->enable_serr)
- pci_bctl |= PCI_BRIDGE_CTL_SERR;
- else
- pci_bctl &= ~PCI_BRIDGE_CTL_SERR;
- if (hpp->enable_perr)
- pci_bctl |= PCI_BRIDGE_CTL_PARITY;
- else
- pci_bctl &= ~PCI_BRIDGE_CTL_PARITY;
- pci_write_config_word(dev, PCI_BRIDGE_CONTROL, pci_bctl);
- }
-}
-
-static void program_hpp_type1(struct pci_dev *dev, struct hpp_type1 *hpp)
-{
- if (hpp)
- dev_warn(>dev, "PCI-X settings not supported\n");
-}
-
-static void program_hpp_type2(struct pci_dev *dev, struct hpp_type2 *hpp)
-{
- int pos;
- u32 reg32;
-
- if (!hpp)
- return;
-
- if (hpp->revision > 1) {
- dev_warn(>dev, "PCIe settings rev %d not supported\n",
-
[PATCH v1 05/13] PCI: pciehp: Remove pci_configure_slot() usage
We now configure each PCI device as it is enumerated, in pci_device_add(), so remove the configuration done in pciehp. That configuration, in pci_configure_device(), does not include the MPS/MRRS configuration done by pcie_bus_configure_settings(), so keep that here. Signed-off-by: Bjorn Helgaas --- drivers/pci/hotplug/pciehp_pci.c |5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/pci/hotplug/pciehp_pci.c b/drivers/pci/hotplug/pciehp_pci.c index b66812703415..9e69403be632 100644 --- a/drivers/pci/hotplug/pciehp_pci.c +++ b/drivers/pci/hotplug/pciehp_pci.c @@ -65,10 +65,7 @@ int pciehp_configure_device(struct slot *p_slot) pci_hp_add_bridge(dev); pci_assign_unassigned_bridge_resources(bridge); - - list_for_each_entry(dev, >devices, bus_list) - pci_configure_slot(dev); - + pcie_bus_configure_settings(parent); pci_bus_add_devices(parent); out: -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 00/13] PCI: Device configuration cleanup
The motivation for this is to fix Linus' complaint about too many _HPP messages (https://bugzilla.kernel.org/show_bug.cgi?id=84391): pci :00:00.0: no hotplug settings from platform pci :00:00.0: using default PCI settings The first patch drops the messages and I intend it for v3.17. The rest are candidates for v3.18. But the excessive *number* of messages is an indication that we're calling pci_configure_slot() way too many times to begin with. The reason this happens is because: - acpiphp supports many slots on a single bus - on a Bus Check, we call acpiphp_check_bridge() to check each slot for changes - acpiphp_check_bridge() calls enable_slot() for every valid device it finds on a bus - enable_slot() calls pci_configure_slot() for every device on the bus The typical result is that we find a bunch of devices on bus 00, and each time we find one, we configure every device on bus 00. I think the best way to fix this is to move device configuration out of the hotplug drivers and into the PCI core. That way we can do it once when the device is enumerated and added. This series adds a pci_configure_device() function that does the configuration (similar to the existing pci_configure_slot()), and calls it from pci_device_add(), where we already call pci_init_capabilities() to initialize MSI, power management, ARI, etc. Then it drops the existing pci_configure_slot() calls (this requires keeping the pcie_bus_configure_settings() MPS and MRRS configuration that was done by pci_configure_slot() but is not done by pci_configure_device(), since it's not a simple per-device thing). Finally, it tweaks several _HPP/_HPX things where we do things not required by the spec and I haven't seen any other good reason for them: - We don't apply _HPP to PCIe devices, and I think we should - We clear SERR and PERR bits, and the spec says we shouldn't - We don't apply _HPP to certain bridge types (PCI-ISA, etc), and I don't see a reason to avoid them - We fiddle MPS and MRRS settings based on _HPX, even though Linux should control these - We only configure hot-added devices, but I think we should configure things present at boot the same way I know some of these might be controversial, so I split them all into separate patches and we can debate and drop them if necessary. --- Bjorn Helgaas (13): PCI: Remove "no hotplug settings from platform" warning PCI: Move pci_configure_slot() to drivers/pci/probe.c PCI: Add pci_configure_device() during enumeration PCI: pciehp: Configure hot-added display devices PCI: pciehp: Remove pci_configure_slot() usage PCI: shpchp: Remove pci_configure_slot() usage ACPI / hotplug / PCI: Remove pci_configure_slot() usage PCI: Remove unused pci_configure_slot() PCI: Apply _HPP settings to PCIe devices as well as PCI and PCI-X PCI: Preserve BIOS PCI_COMMAND_SERR and PCI_COMMAND_PARITY settings PCI: Apply _HPP settings to all hot-added PCI devices PCI: Preserve MPS and MRRS when applying _HPX settings PCI: Configure *all* devices, not just hot-added ones drivers/pci/hotplug/Makefile |2 drivers/pci/hotplug/acpiphp_glue.c | 11 -- drivers/pci/hotplug/pciehp_pci.c |9 -- drivers/pci/hotplug/pcihp_slot.c | 180 drivers/pci/hotplug/shpchp_pci.c |8 -- drivers/pci/probe.c| 134 +++ include/linux/pci_hotplug.h|2 7 files changed, 138 insertions(+), 208 deletions(-) delete mode 100644 drivers/pci/hotplug/pcihp_slot.c -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 04/13] PCI: pciehp: Configure hot-added display devices
We configure cache line size and other settings of hot-added devices, e.g.,
based on ACPI _HPP or _HPX methods. Previously we skipped this
configuration for display devices, but there is no spec requirement for
that.
Remove the check so we configure display devices the same way we configure
other devices.
See also ac81860ea073 ("PCI: hotplug: pciehp: Removed check for hotplug of
display devices").
Signed-off-by: Bjorn Helgaas
---
drivers/pci/hotplug/pciehp_pci.c |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/pci/hotplug/pciehp_pci.c b/drivers/pci/hotplug/pciehp_pci.c
index 5f871f4c4af1..b66812703415 100644
--- a/drivers/pci/hotplug/pciehp_pci.c
+++ b/drivers/pci/hotplug/pciehp_pci.c
@@ -66,12 +66,8 @@ int pciehp_configure_device(struct slot *p_slot)
pci_assign_unassigned_bridge_resources(bridge);
- list_for_each_entry(dev, >devices, bus_list) {
- if ((dev->class >> 16) == PCI_BASE_CLASS_DISPLAY)
- continue;
-
+ list_for_each_entry(dev, >devices, bus_list)
pci_configure_slot(dev);
- }
pci_bus_add_devices(parent);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/9] locktorture: Support mutexes
On Thu, Sep 11, 2014 at 08:40:18PM -0700, Davidlohr Bueso wrote:
> Add a "mutex_lock" torture test. The main difference with the already
> existing spinlock tests is that the latency of the critical region
> is much larger. We randomly delay for (arbitrarily) either 500 ms or,
> otherwise, 25 ms. While this can considerably reduce the amount of
> writes compared to non blocking locks, if run long enough it can have
> the same torturous effect. Furthermore it is more representative of
> mutex hold times and can stress better things like thrashing.
>
> Signed-off-by: Davidlohr Bueso
One question and one follow-up patch below.
Thanx, Paul
> ---
> Documentation/locking/locktorture.txt | 2 ++
> kernel/locking/locktorture.c | 41
> +--
> 2 files changed, 41 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/locking/locktorture.txt
> b/Documentation/locking/locktorture.txt
> index c0ab969..6b1e7ca 100644
> --- a/Documentation/locking/locktorture.txt
> +++ b/Documentation/locking/locktorture.txt
> @@ -40,6 +40,8 @@ torture_type Type of lock to torture. By default,
> only spinlocks will
>o "spin_lock_irq": spin_lock_irq() and spin_unlock_irq()
> pairs.
>
> + o "mutex_lock": mutex_lock() and mutex_unlock() pairs.
> +
> torture_runnable Start locktorture at module init. By default it will begin
> once the module is loaded.
>
> diff --git a/kernel/locking/locktorture.c b/kernel/locking/locktorture.c
> index 8c770b2..414ba45 100644
> --- a/kernel/locking/locktorture.c
> +++ b/kernel/locking/locktorture.c
> @@ -27,6 +27,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -66,7 +67,7 @@ torture_param(bool, verbose, true,
> static char *torture_type = "spin_lock";
> module_param(torture_type, charp, 0444);
> MODULE_PARM_DESC(torture_type,
> - "Type of lock to torture (spin_lock, spin_lock_irq, ...)");
> + "Type of lock to torture (spin_lock, spin_lock_irq,
> mutex_lock, ...)");
>
> static atomic_t n_lock_torture_errors;
>
> @@ -206,6 +207,42 @@ static struct lock_torture_ops spin_lock_irq_ops = {
> .name = "spin_lock_irq"
> };
>
> +static DEFINE_MUTEX(torture_mutex);
> +
> +static int torture_mutex_lock(void) __acquires(torture_mutex)
> +{
> + mutex_lock(_mutex);
> + return 0;
> +}
> +
> +static void torture_mutex_delay(struct torture_random_state *trsp)
> +{
> + const unsigned long longdelay_ms = 100;
> +
> + /* We want a long delay occasionally to force massive contention. */
> + if (!(torture_random(trsp) %
> + (nrealwriters_stress * 2000 * longdelay_ms)))
> + mdelay(longdelay_ms * 5);
So let's see... We wait 500 milliseconds about once per 200,000 operations
per writer. So if we have 5 writers, we wait 500 milliseconds per million
operations. So each writer will do about 200,000 operations, then there
will be a half-second gap. But each short operation holds the lock for
20 milliseconds, which takes several hours to work through the million
operations.
So it looks to me like you are in massive contention state either way,
at least until the next stutter interval shows up.
Is that the intent? Or am I missing something here?
> + else
> + mdelay(longdelay_ms / 5);
> +#ifdef CONFIG_PREEMPT
> + if (!(torture_random(trsp) % (nrealwriters_stress * 2)))
> + preempt_schedule(); /* Allow test to be preempted. */
> +#endif
> +}
> +
> +static void torture_mutex_unlock(void) __releases(torture_mutex)
> +{
> + mutex_unlock(_mutex);
> +}
> +
> +static struct lock_torture_ops mutex_lock_ops = {
> + .writelock = torture_mutex_lock,
> + .write_delay= torture_mutex_delay,
> + .writeunlock= torture_mutex_unlock,
> + .name = "mutex_lock"
> +};
> +
> /*
> * Lock torture writer kthread. Repeatedly acquires and releases
> * the lock, checking for duplicate acquisitions.
> @@ -352,7 +389,7 @@ static int __init lock_torture_init(void)
> int i;
> int firsterr = 0;
> static struct lock_torture_ops *torture_ops[] = {
> - _busted_ops, _lock_ops, _lock_irq_ops,
> + _busted_ops, _lock_ops, _lock_irq_ops,
> _lock_ops,
> };
>
> if (!torture_init_begin(torture_type, verbose, _runnable))
> --
And I queued the following patch to catch up the scripting.
locktorture: Add test scenario for mutex_lock
Signed-off-by: Paul E. McKenney
diff --git a/tools/testing/selftests/rcutorture/configs/lock/CFLIST
b/tools/testing/selftests/rcutorture/configs/lock/CFLIST
index a061b22d1892..901bafde4588 100644
--- a/tools/testing/selftests/rcutorture/configs/lock/CFLIST
+++
[PATCH v1 03/13] PCI: Add pci_configure_device() during enumeration
Some platforms can tell the OS how to configure PCI devices, e.g., how to
set cache line size, error reporting enables, etc. ACPI defines _HPP and
_HPX methods for this purpose.
This configuration was previously done by some of the hotplug drivers using
pci_configure_slot(). But not all hotplug drivers did this, and per the
spec (ACPI rev 5.0, sec 6.2.7), we can also do it for "devices not
configured by the BIOS at system boot."
Move this configuration into the PCI core by adding pci_configure_device()
and calling it from pci_device_add(), so we do this for all devices as we
enumerate them.
This is based on pci_configure_slot(), which is used by hotplug drivers.
I omitted:
- pcie_bus_configure_settings() because it configures MPS and MRRS, which
requires global knowledge of the fabric and must be done later, and
- configuration of subordinate devices; that will happen when we call
pci_device_add() for those devices.
Because pci_configure_slot() was only done by hotplug drivers, this initial
version of pci_configure_device() only configures hot-added devices,
ignoring anything added during boot.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/probe.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 5d0cc646817a..93d2b41163fa 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1384,6 +1384,30 @@ void pci_configure_slot(struct pci_dev *dev)
}
}
EXPORT_SYMBOL_GPL(pci_configure_slot);
+
+static void pci_configure_device(struct pci_dev *dev)
+{
+ struct hotplug_params hpp;
+ int ret;
+
+ if (system_state == SYSTEM_BOOTING)
+ return;
+
+ if (!(dev->hdr_type == PCI_HEADER_TYPE_NORMAL ||
+ (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE &&
+ (dev->class >> 8) == PCI_CLASS_BRIDGE_PCI)))
+ return;
+
+ memset(, 0, sizeof(hpp));
+ ret = pci_get_hp_params(dev, );
+ if (ret)
+ return;
+
+ program_hpp_type2(dev, hpp.t2);
+ program_hpp_type1(dev, hpp.t1);
+ program_hpp_type0(dev, hpp.t0);
+}
+
static void pci_release_capabilities(struct pci_dev *dev)
{
pci_vpd_release(dev);
@@ -1521,6 +1545,8 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus
*bus)
{
int ret;
+ pci_configure_device(dev);
+
device_initialize(>dev);
dev->dev.release = pci_release_dev;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 3/3] phy: Add Qualcomm DWC3 HS/SS PHY driver
Hey Andy-
Mostly cosmetic things below:
On Fri, Sep 12, 2014 at 12:29:46PM -0500, Andy Gross wrote:
> This patch adds a new driver for the Qualcomm USB 3.0 PHY that exists on some
> Qualcomm platforms. This driver uses the generic PHY framework and will
> interact with the DWC3 controller.
>
> Signed-off-by: Andy Gross
> ---
> drivers/phy/Kconfig | 11 +
> drivers/phy/Makefile|1 +
> drivers/phy/phy-qcom-dwc3.c | 500
> +++
> 3 files changed, 512 insertions(+)
> create mode 100644 drivers/phy/phy-qcom-dwc3.c
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 0dd7427..5d56161 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -230,4 +230,15 @@ config PHY_XGENE
> help
> This option enables support for APM X-Gene SoC multi-purpose PHY.
>
> +config PHY_QCOM_DWC3
> + tristate "QCOM DWC3 USB PHY support"
> + depends on ARCH_QCOM
> + depends on HAS_IOMEM
> + depends on OF
> + select GENERIC_PHY
> + help
> + This option enables support for the Synopsis PHYs present inside the
> + Qualcomm USB3.0 DWC3 controller. This driver supports both HS and SS
> + PHY controllers.
> +
> endmenu
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 95c69ed..aa16f30 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -28,3 +28,4 @@ obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA) +=
> phy-qcom-ipq806x-sata.o
> obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY) += phy-spear1310-miphy.o
> obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o
> obj-$(CONFIG_PHY_XGENE) += phy-xgene.o
> +obj-$(CONFIG_PHY_QCOM_DWC3) += phy-qcom-dwc3.o
> diff --git a/drivers/phy/phy-qcom-dwc3.c b/drivers/phy/phy-qcom-dwc3.c
> new file mode 100644
> index 000..05b8e1d
> --- /dev/null
> +++ b/drivers/phy/phy-qcom-dwc3.c
[..]
> +/* TX OVRD DRV LO register bits */
> +#define TX_OVRD_DRV_LO_AMPLITUDE_MASK0x007F
> +#define TX_OVRD_DRV_LO_PREEMPH_MASK 0x3F80
> +#define TX_OVRD_DRV_LO_PREEMPH_SHIFT 7
> +#define TX_OVRD_DRV_LO_ENBIT(14)
> +
> +struct qcom_dwc3_usb_phy;
Do you need this?
> +
> +enum qcom_dwc3_phy_id {
> + QCOM_DWC3_PHY_UTMI = 0,
> + QCOM_DWC3_PHY_PIPE,
> + QCOM_DWC3_PHYS_NUM,
> +};
> +
> +struct qcom_dwc3_usb_phy {
> + void __iomem*base;
> + struct device *dev;
> + struct phy *phy;
> + enum qcom_dwc3_phy_id index;
> +
> + struct clk *xo_clk;
> + struct clk *ref_clk;
> +};
> +
> +/**
> + * Write register and read back masked value to confirm it is written
> + *
> + * @base - QCOM DWC3 PHY base virtual address.
> + * @offset - register offset.
> + * @mask - register bitmask specifying what should be updated
> + * @val - value to write.
> + */
> +static inline void qcom_dwc3_phy_write_readback(
> + struct qcom_dwc3_usb_phy *phy_dwc3, u32 offset,
> + const u32 mask, u32 val)
> +{
> + u32 write_val, tmp = readl(phy_dwc3->base + offset);
> +
> + tmp &= ~mask; /* retain other bits */
> + write_val = tmp | val;
> +
> + writel(write_val, phy_dwc3->base + offset);
> +
> + /* Read back to see if val was written */
> + tmp = readl(phy_dwc3->base + offset);
> + tmp &= mask;/* clear other bits */
> +
> + if (tmp != val)
> + dev_err(phy_dwc3->dev, "write: %x to QSCRATCH: %x FAILED\n",
> + val, offset);
> +}
> +
> +static int wait_for_latch(void __iomem *addr)
> +{
> + u32 retry = 10;
> +
> + while (true) {
> + if (!readl(addr))
> + break;
> +
> + if (--retry == 0)
> + return -ETIMEDOUT;
> +
> + usleep_range(10, 20);
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * Write SSPHY register
> + *
> + * @base - QCOM DWC3 PHY base virtual address.
> + * @addr - SSPHY address to write.
> + * @val - value to write.
> + */
> +static int qcom_dwc3_ss_write_phycreg(void __iomem *base, u32 addr, u32 val)
> +{
> + writel(addr, base + CR_PROTOCOL_DATA_IN_REG);
> + writel(0x1, base + CR_PROTOCOL_CAP_ADDR_REG);
> +
> + if (wait_for_latch(base + CR_PROTOCOL_CAP_ADDR_REG))
> + return 1;
I'm not too familiar with the GENERIC_PHY infrastructure, does it
understand that '1' is an error case? I'm wondering if you should
instead propogate the -ETIMEDOUT up.
> +
> + writel(val, base + CR_PROTOCOL_DATA_IN_REG);
> + writel(0x1, base + CR_PROTOCOL_CAP_DATA_REG);
> +
> + if (wait_for_latch(base + CR_PROTOCOL_CAP_DATA_REG))
> + return 1;
> +
> + writel(0x1, base + CR_PROTOCOL_WRITE_REG);
> +
> + if (wait_for_latch(base + CR_PROTOCOL_WRITE_REG))
> + return 1;
> +
> + return 0;
> +}
> +
[..]
> +
> +static struct phy_ops qcom_dwc3_phy_ops = {
> + .init = qcom_dwc3_phy_init,
> + .exit =
Re: [PATCH RFC] memcg: revert kmem.tcp accounting
Hello, guys. On Fri, Sep 12, 2014 at 07:18:09PM +0200, Michal Hocko wrote: > On Fri 12-09-14 19:26:58, Vladimir Davydov wrote: > > memory.kmem.tcp.limit_in_bytes works as the system-wide tcp_mem sysctl, > > but per memory cgroup. While the existence of the latter is justified > > (it prevents the system from becoming unusable due to uncontrolled tcp > > buffers growth) the reason why we need such a knob in containers isn't > > clear to me. > > Parallels was the primary driver for this change. I haven't heard of > anybody using the feature other than Parallels. I also remember there > was a strong push for this feature before it was merged besides there > were some complains at the time. I do not remember details (and I am > one half way gone for the weekend now) so I do not have pointers to > discussions. > > I would love to get rid of the code and I am pretty sure that networking > people would love this go even more. I didn't plan to provide kmem.tcp.* > knobs for the cgroups v2 interface but getting rid of it altogether > sounds even better. I am just not sure whether some additional users > grown over time. > Nevertheless I am really curious. What has changed that Parallels is not > interested in kmem.tcp anymore? So, I'd love to see this happen too but I don't think we can do this. People use published interface. The usages might be utterly one-off and mental but let's please not underestimate the sometimes senseless creativity found in the wild. We simply can't remove a bunch of control knobs like this. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ACPI / platform / LPSS: disable async suspend/resume of LPSS devices
On 2014/9/10 15:50, Mika Westerberg wrote:
> On Tue, Sep 09, 2014 at 01:36:48PM +0800, Fu, Zhonghui wrote:
>> >From 6deb00230f5df68da3ca7490402a0c537bf386bb Mon Sep 17 00:00:00 2001
>> From: Fu Zhonghui
>> Date: Tue, 9 Sep 2014 13:02:25 +0800
>> Subject: [PATCH] ACPI / platform / LPSS: disable async suspend/resume of
>> LPSS devices
>>
>> LPSS devices must suspend/resume in fixed order. Or some LPSS devices
>> will hang during the transition to ACPI_STATE_D0 state.
> In addition to the comment from Rafael, I would like to have more
> details here why we must suspend/resume the LPSS devices in certain
> order.
Sorry for late response.
After the patch "ACPI / platform / LPSS: Enable async suspend/resume of LPSS
devices(commit ID: 8ce62f85a81f57e86bc120ab690facc612223188)" was merged into
upstream kernel, some LPSS devices(UART, I2C) frequently hang during resume.
So, my patch is actually reverting that patch.
>
>> Signed-off-by: Li Aubrey
>> Signed-off-by: Fu Zhonghui
>> ---
>> drivers/acpi/acpi_lpss.c |2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
>> index fddc1e8..54e5c97 100644
>> --- a/drivers/acpi/acpi_lpss.c
>> +++ b/drivers/acpi/acpi_lpss.c
>> @@ -419,7 +419,7 @@ static int acpi_lpss_create_device(struct acpi_device
>> *adev,
>> adev->driver_data = pdata;
>> pdev = acpi_create_platform_device(adev);
>> if (!IS_ERR_OR_NULL(pdev)) {
>> -device_enable_async_suspend(>dev);
>> +device_disable_async_suspend(>dev);
>> return 1;
>> }
>>
>> -- 1.7.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/4] arm64, thunder: Add initial dts for Cavium Thunder SoC
From: Radha Mohan Chintakuntla
Add initial device tree nodes for Cavium Thunder SoCs with support of
48 cores and gicv3. The dtsi file requires further changes, esp. for
pci, gicv3-its and smmu. This changes will be added later together
with the device drivers.
Signed-off-by: Radha Mohan Chintakuntla
Signed-off-by: Robert Richter
---
arch/arm64/boot/dts/Makefile | 2 +
arch/arm64/boot/dts/thunder-88xx.dts | 67 ++
arch/arm64/boot/dts/thunder-88xx.dtsi | 401 ++
3 files changed, 470 insertions(+)
create mode 100644 arch/arm64/boot/dts/thunder-88xx.dts
create mode 100644 arch/arm64/boot/dts/thunder-88xx.dtsi
diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index c52bdb051f66..c2e8e4661a90 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -1,6 +1,8 @@
dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb
dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb
+dtb-y += thunder-88xx.dtb
+
targets += dtbs
targets += $(dtb-y)
diff --git a/arch/arm64/boot/dts/thunder-88xx.dts
b/arch/arm64/boot/dts/thunder-88xx.dts
new file mode 100644
index ..800ba65991f7
--- /dev/null
+++ b/arch/arm64/boot/dts/thunder-88xx.dts
@@ -0,0 +1,67 @@
+/*
+ * Cavium Thunder DTS file - Thunder board description
+ *
+ * Copyright (C) 2014, Cavium Inc.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this library; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+/include/ "thunder-88xx.dtsi"
+
+/ {
+ model = "Cavium ThunderX CN88XX board";
+ compatible = "cavium,thunder-88xx";
+
+ aliases {
+ serial0 =
+ serial1 =
+ };
+
+ memory@ {
+ device_type = "memory";
+ reg = <0x0 0x 0x0 0x8000>;
+ };
+};
diff --git a/arch/arm64/boot/dts/thunder-88xx.dtsi
b/arch/arm64/boot/dts/thunder-88xx.dtsi
new file mode 100644
index ..d8c0bdc51882
--- /dev/null
+++ b/arch/arm64/boot/dts/thunder-88xx.dtsi
@@ -0,0 +1,401 @@
+/*
+ * Cavium Thunder DTS file - Thunder SoC description
+ *
+ * Copyright (C) 2014, Cavium Inc.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ *
Re: [PATCH v8 07/10] x86, mpx: decode MPX instruction to get bound violation information
On Thu, 11 Sep 2014, H. Peter Anvin wrote: > On 09/11/2014 03:32 PM, Dave Hansen wrote: > > On 09/11/2014 03:18 PM, Thomas Gleixner wrote: > >> On Thu, 11 Sep 2014, Qiaowei Ren wrote: > >>> This patch sets bound violation fields of siginfo struct in #BR > >>> exception handler by decoding the user instruction and constructing > >>> the faulting pointer. > >>> > >>> This patch does't use the generic decoder, and implements a limited > >>> special-purpose decoder to decode MPX instructions, simply because the > >>> generic decoder is very heavyweight not just in terms of performance > >>> but in terms of interface -- because it has to. > >> > >> And why is that an argument to add another special purpose decoder? > > > > Peter asked for it to be done this way specifically: > > > > https://lkml.org/lkml/2014/6/19/411 > > > > Specifically because marshaling the data in and out of the generic > decoder was more complex than a special-purpose decoder. Well, I did not see the trainwreck which tried to use the generic decoder, but as I explained in the other mail, there is no reason not to use it and I can't see any complexity in retrieving the data beyond calling insn_get_length(insn); Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 3/3] phy: Add Qualcomm DWC3 HS/SS PHY driver
Hi, On Fri, Sep 12, 2014 at 12:29:46PM -0500, Andy Gross wrote: > This patch adds a new driver for the Qualcomm USB 3.0 PHY that exists on some > Qualcomm platforms. This driver uses the generic PHY framework and will > interact with the DWC3 controller. > > Signed-off-by: Andy Gross Kishon, this looks good to my eyes. It has no direct dependency with dwc3 glue layer. Can you still grab this for v3.18 merge window ? Reviewed-by: Felipe Balbi Acked-by: Felipe Balbi cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH] ACPI / platform / LPSS: disable async suspend/resume of LPSS devices
hi, Rafael
Sorry for late response.
Yes,Only removing the "enable" line is sufficient. I have verified this, and
made a new patch as follows.
Thanks,
Zhonghui
>From 3c89c22c5b35ddbdcadecd391f2521a15ffc2f4f Mon Sep 17 00:00:00 2001
From: Fu Zhonghui
Date: Sat, 13 Sep 2014 01:26:04 +0800
Subject: [PATCH] ACPI / platform / LPSS: disable async suspend/resume of LPSS
devices
LPSS devices must suspend/resume in fixed order. Or some LPSS devices
will hang during the transition to ACPI_STATE_D0 state.
Signed-off-by: Li Aubrey
Signed-off-by: Fu Zhonghui
---
drivers/acpi/acpi_lpss.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index fddc1e8..b0ea767 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -419,7 +419,6 @@ static int acpi_lpss_create_device(struct acpi_device *adev,
adev->driver_data = pdata;
pdev = acpi_create_platform_device(adev);
if (!IS_ERR_OR_NULL(pdev)) {
- device_enable_async_suspend(>dev);
return 1;
}
-- 1.7.1
On 2014/9/9 21:17, Rafael J. Wysocki wrote:
> On Tuesday, September 09, 2014 01:36:48 PM Fu, Zhonghui wrote:
>> From 6deb00230f5df68da3ca7490402a0c537bf386bb Mon Sep 17 00:00:00 2001
>> From: Fu Zhonghui
>> Date: Tue, 9 Sep 2014 13:02:25 +0800
>> Subject: [PATCH] ACPI / platform / LPSS: disable async suspend/resume of
>> LPSS devices
>>
>> LPSS devices must suspend/resume in fixed order. Or some LPSS devices
>> will hang during the transition to ACPI_STATE_D0 state.
>>
>> Signed-off-by: Li Aubrey
>> Signed-off-by: Fu Zhonghui
>> ---
>> drivers/acpi/acpi_lpss.c |2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
>> index fddc1e8..54e5c97 100644
>> --- a/drivers/acpi/acpi_lpss.c
>> +++ b/drivers/acpi/acpi_lpss.c
>> @@ -419,7 +419,7 @@ static int acpi_lpss_create_device(struct acpi_device
>> *adev,
>> adev->driver_data = pdata;
>> pdev = acpi_create_platform_device(adev);
>> if (!IS_ERR_OR_NULL(pdev)) {
>> -device_enable_async_suspend(>dev);
>> +device_disable_async_suspend(>dev);
> Removing the "enable" line should be sufficient for that. Isn't it?
>
>> return 1;
>> }
>>
>> -- 1.7.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 4/4] arm64, defconfig: Enable Cavium Thunder SoC in defconfig
From: Robert Richter This patch enables Thunder SoCs in the arm64 defconfig. This is esp. useful to add Thunder platforms to automated builds based on arm64 defconfig. Signed-off-by: Robert Richter --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index d92ef3c54161..9cd37de9aa8d 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -32,6 +32,7 @@ CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_BLK_DEV_BSG is not set # CONFIG_IOSCHED_DEADLINE is not set +CONFIG_ARCH_THUNDER=y CONFIG_ARCH_VEXPRESS=y CONFIG_ARCH_XGENE=y CONFIG_SMP=y -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] i2c-designware: Intel BayTrail PMIC I2C bus support
This patch implements an I2C bus sharing mechanism between the host and platform
hardware on select Intel BayTrail SoC platforms using the XPower AXP288 PMIC.
On these platforms access to the PMIC must be shared with platform hardware. The
hardware unit assumes full control of the I2C bus and the host must request
access through a special semaphore. Hardware control of the bus also makes it
necessary to disable runtime pm to avoid interfering with hardware transactions.
Signed-off-by: David E. Box
---
drivers/i2c/busses/Kconfig | 10 +++
drivers/i2c/busses/Makefile | 1 +
drivers/i2c/busses/i2c-designware-core.h| 14
drivers/i2c/busses/i2c-designware-platdrv.c | 78 +++--
drivers/i2c/busses/i2c-shared-controller.c | 101
5 files changed, 200 insertions(+), 4 deletions(-)
create mode 100644 drivers/i2c/busses/i2c-shared-controller.c
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 2ac87fa..672ef23 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -441,6 +441,16 @@ config I2C_DESIGNWARE_PCI
This driver can also be built as a module. If so, the module
will be called i2c-designware-pci.
+config I2C_SHARED_CONTROLLER
+ tristate "Intel Baytrail PMIC shared I2C bus support"
+ depends on ACPI
+ select IOSF_MBI
+ select I2C_DESIGNWARE_CORE
+ help
+ This driver enables shared access to the PMIC I2C bus on select Intel
+ BayTrail platforms using the XPower AXP288 PMIC. This driver is
+ required for host access to the PMIC on these platforms.
+
config I2C_EFM32
tristate "EFM32 I2C controller"
depends on ARCH_EFM32 || COMPILE_TEST
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 49bf07e..33d62d1 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_I2C_DESIGNWARE_CORE) += i2c-designware-core.o
obj-$(CONFIG_I2C_DESIGNWARE_PLATFORM) += i2c-designware-platform.o
i2c-designware-platform-objs := i2c-designware-platdrv.o
obj-$(CONFIG_I2C_DESIGNWARE_PCI) += i2c-designware-pci.o
+obj-$(CONFIG_I2C_SHARED_CONTROLLER)+= i2c-shared-controller.o
i2c-designware-pci-objs := i2c-designware-pcidrv.o
obj-$(CONFIG_I2C_EFM32)+= i2c-efm32.o
obj-$(CONFIG_I2C_EG20T)+= i2c-eg20t.o
diff --git a/drivers/i2c/busses/i2c-designware-core.h
b/drivers/i2c/busses/i2c-designware-core.h
index d66b6cb..a2b72f4 100644
--- a/drivers/i2c/busses/i2c-designware-core.h
+++ b/drivers/i2c/busses/i2c-designware-core.h
@@ -65,6 +65,10 @@
* @ss_lcnt: standard speed LCNT value
* @fs_hcnt: fast speed HCNT value
* @fs_lcnt: fast speed LCNT value
+ * @shared_host: if host must share access to adapter with other
+ * firmware/hardware units
+ * @acquire_ownership: function to acquire exclusive use of the controller
+ * @release_ownership: function to release exclusive use of the controller
*
* HCNT and LCNT parameters can be used if the platform knows more accurate
* values than the one computed based only on the input clock frequency.
@@ -105,6 +109,11 @@ struct dw_i2c_dev {
u16 ss_lcnt;
u16 fs_hcnt;
u16 fs_lcnt;
+#if IS_ENABLED(CONFIG_I2C_SHARED_CONTROLLER)
+ int shared_host;
+ int (*acquire_ownership)(struct device *dev);
+ int (*release_ownership)(struct device *dev);
+#endif
};
#define ACCESS_SWAP0x0001
@@ -123,3 +132,8 @@ extern void i2c_dw_disable(struct dw_i2c_dev *dev);
extern void i2c_dw_clear_int(struct dw_i2c_dev *dev);
extern void i2c_dw_disable_int(struct dw_i2c_dev *dev);
extern u32 i2c_dw_read_comp_param(struct dw_i2c_dev *dev);
+
+#if IS_ENABLED(CONFIG_I2C_SHARED_CONTROLLER)
+extern int i2c_acquire_ownership(struct device *dev);
+extern int i2c_release_ownership(struct device *dev);
+#endif
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
b/drivers/i2c/busses/i2c-designware-platdrv.c
index f9b1dec..f86c285 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -52,6 +52,32 @@ static u32 i2c_dw_get_clk_rate_khz(struct dw_i2c_dev *dev)
return clk_get_rate(dev->clk)/1000;
}
+#if IS_ENABLED(CONFIG_I2C_SHARED_CONTROLLER)
+int i2c_shared_controller_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[],
+ int num)
+{
+ struct dw_i2c_dev *dev = i2c_get_adapdata(adap);
+ int err;
+
+ if (dev->shared_host) {
+ err = dev->acquire_ownership(dev->dev);
+ if (!err) {
+ err = i2c_dw_xfer(adap, msgs, num);
+ dev->release_ownership(dev->dev);
+ } else
+ dev_WARN(dev->dev, "couldnt acquire ownership\n");
Re: [PATCH 1/9] locktorture: Rename locktorture_runnable parameter
On Fri, Sep 12, 2014 at 10:40:26AM -0700, Paul E. McKenney wrote:
[ . . . ]
> locktorture: Make torture scripting account for new _runnable name
>
> Signed-off-by: Paul E. McKenney
>
> diff --git a/tools/testing/selftests/rcutorture/configs/lock/ver_functions.sh
> b/tools/testing/selftests/rcutorture/configs/lock/ver_functions.sh
> index 9746ea1cd6c7..252aae618984 100644
> --- a/tools/testing/selftests/rcutorture/configs/lock/ver_functions.sh
> +++ b/tools/testing/selftests/rcutorture/configs/lock/ver_functions.sh
> @@ -38,6 +38,6 @@ per_version_boot_params () {
> echo $1 `locktorture_param_onoff "$1" "$2"` \
> locktorture.stat_interval=15 \
> locktorture.shutdown_secs=$3 \
> - locktorture.locktorture_runnable=1 \
> + locktorture.torture_runnable=1 \
> locktorture.verbose=1
> }
And I apparently forgot to document locktorture's kernel parameters...
Thanx, Paul
locktorture: Document boot/module parameters
Signed-off-by: Paul E. McKenney
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index c8b6beb3edda..c04fb60f4cb3 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1704,6 +1704,49 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
lockd.nlm_udpport=M [NFS] Assign UDP port.
Format:
+ locktorture.nreaders_stress= [KNL]
+ Set the number of locking read-acquisition kthreads.
+ Defaults to being automatically set based on the
+ number of online CPUs.
+
+ locktorture.nwriters_stress= [KNL]
+ Set the number of locking write-acquisition kthreads.
+
+ locktorture.onoff_holdoff= [KNL]
+ Set time (s) after boot for CPU-hotplug testing.
+
+ locktorture.onoff_interval= [KNL]
+ Set time (s) between CPU-hotplug operations, or
+ zero to disable CPU-hotplug testing.
+
+ locktorture.shuffle_interval= [KNL]
+ Set task-shuffle interval (jiffies). Shuffling
+ tasks allows some CPUs to go into dyntick-idle
+ mode during the locktorture test.
+
+ locktorture.shutdown_secs= [KNL]
+ Set time (s) after boot system shutdown. This
+ is useful for hands-off automated testing.
+
+ locktorture.stat_interval= [KNL]
+ Time (s) between statistics printk()s.
+
+ locktorture.stutter= [KNL]
+ Time (s) to stutter testing, for example,
+ specifying five seconds causes the test to run for
+ five seconds, wait for five seconds, and so on.
+ This tests the locking primitive's ability to
+ transition abruptly to and from idle.
+
+ locktorture.torture_runnable= [BOOT]
+ Start locktorture running at boot time.
+
+ locktorture.torture_type= [KNL]
+ Specify the locking implementation to test.
+
+ locktorture.verbose= [KNL]
+ Enable additional printk() statements.
+
logibm.irq= [HW,MOUSE] Logitech Bus Mouse Driver
Format:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/4] arm64, thunder: Document devicetree bindings for Cavium Thunder SoC
From: Radha Mohan Chintakuntla This patch adds documentation for the devicetree bindings used by the DT files of Cavium Thunder SoC platforms. Signed-off-by: Radha Mohan Chintakuntla Signed-off-by: Robert Richter --- Documentation/devicetree/bindings/arm/cavium-thunder.txt | 10 ++ Documentation/devicetree/bindings/arm/cpus.txt | 1 + 2 files changed, 11 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/cavium-thunder.txt diff --git a/Documentation/devicetree/bindings/arm/cavium-thunder.txt b/Documentation/devicetree/bindings/arm/cavium-thunder.txt new file mode 100644 index ..6f63a5866902 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/cavium-thunder.txt @@ -0,0 +1,10 @@ +Cavium Thunder platform device tree bindings + + +Boards with Cavium's Thunder SoC shall have following properties. + +Root Node +- +Required root node properties: + + - compatible = "cavium,thunder-88xx"; diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt index 298e2f6b33c6..578796a2cfa9 100644 --- a/Documentation/devicetree/bindings/arm/cpus.txt +++ b/Documentation/devicetree/bindings/arm/cpus.txt @@ -166,6 +166,7 @@ nodes to be present and contain the properties described below. "arm,cortex-r5" "arm,cortex-r7" "brcm,brahma-b15" + "cavium,thunder" "faraday,fa526" "intel,sa110" "intel,sa1100" -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/4] arm64, thunder: Add Kconfig option for Cavium Thunder SoC Family
From: Radha Mohan Chintakuntla This introduces ARCH_THUNDER to enable soc specific drivers and dtb files. Signed-off-by: Radha Mohan Chintakuntla Signed-off-by: Robert Richter --- arch/arm64/Kconfig | 5 + arch/arm64/boot/dts/Makefile | 3 +-- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 67fca2ea81a7..ff9179ba63fb 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -134,6 +134,11 @@ source "kernel/Kconfig.freezer" menu "Platform selection" +config ARCH_THUNDER + bool "Cavium Inc. Thunder SoC Family" + help + This enables support for Cavium's Thunder Family of SoCs. + config ARCH_VEXPRESS bool "ARMv8 software model (Versatile Express)" select ARCH_REQUIRE_GPIOLIB diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile index c2e8e4661a90..f8001a62029c 100644 --- a/arch/arm64/boot/dts/Makefile +++ b/arch/arm64/boot/dts/Makefile @@ -1,8 +1,7 @@ +dtb-$(CONFIG_ARCH_THUNDER) += thunder-88xx.dtb dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb -dtb-y += thunder-88xx.dtb - targets += dtbs targets += $(dtb-y) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/4] arm64, thunder: Enable Cavium Thunder SoC Family
From: Robert Richter This initial patches enable Cavium Thunder SoC Family. The patches add devicetree and Kconfig support and then add Thunder to the defconfig. The Thunder system needs more enablement patches for subsystems and devices, this includes network, ahci, gicv3/gicv3-its, pci, smmu, kvm. We will send separate patch sets for these. All of them base on this initial patches. I sent a separate patch set independently that introduces support for dts vendor subdirs. After both patch sets have been applied I will send a patch in addition that moves the dts file into a subdirectory. I sent another separate patch that sets NR_CPUS to 64 per default. The first patch introduces dts files without having a Kconfig option for the soc (ARCH_THUNDER). However, this is introduced in patch 3 and added to defconfig in patch 4 as this is my preferred solution. If there is still resistance having an ARCH_THUNDER option, just drop them. Patches are available here: git://git.kernel.org/pub/scm/linux/kernel/git/rric/linux.git thunder/init v3 changes: * removed setting NR_CPUS for Thunder, I sent a separate patch that increases this to 64 cpus per default * reordered patches, dts files changes are know first using dtb-y instead of ARCH_THUNDER option * moved soc nodes to thunder-88xx.dtsi v2 changes: * rebased to 3.17 * placed commas between 32-bit portions of 64 bit addresses * removed #address-cells and size-cells in gic node * get rid of the clocks node * changed to gpl/x11 dual license * removed memreserve * moved gic to bus node Radha Mohan Chintakuntla (3): arm64, thunder: Add initial dts for Cavium Thunder SoC arm64, thunder: Document devicetree bindings for Cavium Thunder SoC arm64, thunder: Add Kconfig option for Cavium Thunder SoC Family Robert Richter (1): arm64, defconfig: Enable Cavium Thunder SoC in defconfig .../devicetree/bindings/arm/cavium-thunder.txt | 10 + Documentation/devicetree/bindings/arm/cpus.txt | 1 + arch/arm64/Kconfig | 5 + arch/arm64/boot/dts/Makefile | 1 + arch/arm64/boot/dts/thunder-88xx.dts | 67 arch/arm64/boot/dts/thunder-88xx.dtsi | 401 + arch/arm64/configs/defconfig | 1 + 7 files changed, 486 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/cavium-thunder.txt create mode 100644 arch/arm64/boot/dts/thunder-88xx.dts create mode 100644 arch/arm64/boot/dts/thunder-88xx.dtsi -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 07/10] x86, mpx: decode MPX instruction to get bound violation information
On Fri, 12 Sep 2014, H. Peter Anvin wrote: > The correct limit is 15 bytes, not anything else, so this is a bug in > the existing decoder. A sequence of bytes longer than 15 bytes will Fine. Lets fix it there. > #UD, regardless of being "otherwise valid". > Keep in mind the instruction may not be aligned, and you could fit an > instruction plus a jump and still overrun a page in 15 bytes. Fair enough. OTOH, I doubt that a text mapping will end exactly at that jump after the MPX instruction. So that's simple to fix. Kill the hardcoded limit in lib/insn.c and let the callsites hand in a lenght argument. So you can still use it for MPX and avoid 200 lines of blindly copied and slightly different decoder code. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 2/3] usb: dwc3: Add Qualcomm DWC3 glue layer driver
Hi,
On Fri, Sep 12, 2014 at 12:29:45PM -0500, Andy Gross wrote:
> From: "Ivan T. Ivanov"
>
> DWC3 glue layer is hardware layer around Synopsys DesignWare
> USB3 core. Its purpose is to supply Synopsys IP with required
> clocks, voltages and interface it with the rest of the SoC.
>
> Signed-off-by: Ivan T. Ivanov
> Signed-off-by: Andy Gross
> ---
> drivers/usb/dwc3/Kconfig |9 +++
> drivers/usb/dwc3/Makefile|1 +
> drivers/usb/dwc3/dwc3-qcom.c | 133
> ++
> 3 files changed, 143 insertions(+)
> create mode 100644 drivers/usb/dwc3/dwc3-qcom.c
>
> diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
> index 785510a..e9f258e 100644
> --- a/drivers/usb/dwc3/Kconfig
> +++ b/drivers/usb/dwc3/Kconfig
> @@ -80,6 +80,15 @@ config USB_DWC3_KEYSTONE
> Support of USB2/3 functionality in TI Keystone2 platforms.
> Say 'Y' or 'M' here if you have one such device
>
> +config USB_DWC3_QCOM
> + tristate "Qualcomm Platforms"
> + depends on ARCH_QCOM || COMPILE_TEST
> + default USB_DWC3
> + select PHY_QCOM_DWC3
I would rather steer away from selecting the PHY as it prevents having
PHYs as modules. Also, this will add a Kconfig warning for selecting a
symbol that doesn't exist (yet).
If it's all the same with you, I can clean this up when applying.
> diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
> new file mode 100644
> index 000..2067c04
> --- /dev/null
> +++ b/drivers/usb/dwc3/dwc3-qcom.c
> @@ -0,0 +1,133 @@
> +/* Copyright (c) 2013-2014, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
doesn't look like you need regulator/consumer.h and usb/phy.h. I can
clean it up when applying.
> +struct dwc3_qcom {
> + struct device *dev;
> +
> + struct clk *core_clk;
> + struct clk *iface_clk;
> + struct clk *sleep_clk;
> +};
> +
> +static int dwc3_qcom_probe(struct platform_device *pdev)
> +{
> + struct device_node *node = pdev->dev.of_node;
> + struct dwc3_qcom *qdwc;
> + int ret = 0;
> +
> + qdwc = devm_kzalloc(>dev, sizeof(*qdwc), GFP_KERNEL);
> + if (!qdwc)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, qdwc);
> +
> + qdwc->dev = >dev;
> +
> + qdwc->core_clk = devm_clk_get(qdwc->dev, "core");
> + if (IS_ERR(qdwc->core_clk)) {
> + dev_dbg(qdwc->dev, "failed to get core clock\n");
this one would be a dev_err() since core can't work without its clock. I
can fix when applying.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v8 08/10] x86, mpx: add prctl commands PR_MPX_REGISTER, PR_MPX_UNREGISTER
On Fri, 12 Sep 2014, Dave Hansen wrote: > On 09/12/2014 01:11 AM, Thomas Gleixner wrote: > > So what you are saying is, that if user space sets the pointer to NULL > > via the unregister prctl, kernel can safely ignore vmas which have the > > VM_MPX flag set. I really can't follow that logic. > > > > mmap_mpx(); > > prctl(enable mpx); > > do lots of crap which uses mpx; > > prctl(disable mpx); > > > > So after that point the previous use of MPX is irrelevant, just > > because we set a pointer to NULL? Does it just look like crap because > > I do not get the big picture how all of this is supposed to work? > > The prctl(register) is meant to be a signal from userspace to the kernel > to say, "I would like your help in managing these bounds tables". > prctl(unregister) is the opposite, meaning "I don't want your help any > more". Fine, but that's a totally different story. I can see the usefulness of this, but then it's a complete misnomer. It should be: prctl(EN/DISABLE_MPX_BT_MANAGEMENT) So this wants to be a boolean value and not some random user space address collected at some random point and then ignored until you do the magic cleanup. See the other reply. > If userspace uses MPX, it does not necessarily want the kernel to do > bounds table management all the time (or ever in some cases). Without > the prctl(), the kernel has no way of distinguishing what userspace wants. Fine with me, but it needs to be done proper. And proper means: ON/OFF The kernel has to handle the information for which context it allocated stuff and then tear it down when the context goes away. Relying on a user space address sampled at some random prctl point is just stupid. > > And then you need another bunch of logic in the prctl(disable mpx) > > path to cleanup the mess instead of just setting a random pointer to > > NULL. > > The bounds tables potentially represent a *lot* of state. If userspace > wants to temporarily turn off the kernel's MPX bounds table management, > it does not necessarily want that state destroyed. On the other hand, > if userspace feels the need to go destroying all the state, it is free > to do so and does not need any help to do so from the kernel. Fine with me, but the above still stands. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/11 v6] coresight: add CoreSight core layer framework
Good morning and thanks for the review. Pls see comments below.
Mathieu
On 11 September 2014 14:33, Greg KH wrote:
> Some first impressions in glancing at the code, not a complete review at
> all:
>
> On Thu, Sep 11, 2014 at 09:49:08AM -0600, mathieu.poir...@linaro.org wrote:
>> --- /dev/null
>> +++ b/drivers/coresight/coresight.c
>> @@ -0,0 +1,663 @@
>> +/* Copyright (c) 2012, The Linux Foundation. All rights reserved.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 and
>> + * only version 2 as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#define pr_fmt(fmt) "coresight: " fmt
>
> MODULE_NAME ?
Is this what you had in mind?
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include "coresight-priv.h"
>> +
>> +struct dentry *cs_debugfs_parent = NULL;
>> +
>> +static LIST_HEAD(coresight_orph_conns);
>> +static LIST_HEAD(coresight_devs);
>
> You are a struct device, you don't need a separate list, why not just
> iterate over your bus list of devices?
Because coresight devices are not powered on the bus. As such, every
time we iterate over the bus we'd need to setup the clock for the
device, power up its domain (if necessary) and lookup the device ID.
Isn't better to simply keep a list of the devices that were found at
boot time and use that whenever we want to make configuration changes?
With regards to @coresight_orph_conns, on top of the above problem
we'd also have to add a flag in the @coresight_device structure to
indicate that a device has been connected to the topology or not. To
me using a list is much cleaner.
>
>> +/**
>> + * @id: unique ID of the component.
>> + * @conns: list of connections associated to this component.
>> + * @type:as defined by @coresight_dev_type.
>> + * @subtype: as defined by @coresight_dev_subtype.
>> + * @ops: generic operations for this component, as defined
>> + by @coresight_ops.
>> + * @de: handle on a component's debugfs entry.
>> + * @dev: The device entity associated to this component.
>> + * @kref:keeping count on component references.
>> + * @dev_link:link of current component into list of all components
>> + discovered in the system.
>> + * @path_link: link of current component into the path being enabled.
>> + * @owner: typically "THIS_MODULE".
>> + * @enable: 'true' if component is currently part of an active path.
>> + * @activated: 'true' only if a _sink_ has been activated. A sink
>> can be
>> + activated but not yet enabled. Enabling for a _sink_
>> + happens when a source has been selected for that it.
>> + */
>> +struct coresight_device {
>> + int id;
>
> Why not use the device name instead?
With regards to memory footprint it is better to keep a single "int"
as ID (which is the their memory map start address) than the full
string associated with the device name. Let's take a funnel for
example that has up to 8 input port. To build a path between source
and sink we need to keep information about device that are connected
to each port. At this time we use the component's ID, i.e 4 byte. If
we were to use device names, ex "2004.funnel_cluster0", we are
using 24 byte and that, 8 times.
Moreover using device names would also mean that we have to used
@stcmp everytime we want do lookups. To me using a single integer to
identify coresight components is a much better solution.
>
>> + struct coresight_connection *conns;
>> + int nr_conns;
>> + enum coresight_dev_type type;
>> + struct coresight_dev_subtype subtype;
>> + const struct coresight_ops *ops;
>> + struct dentry *de;
>
> All devices have a dentry? in debugfs? isn't that overkill?
All devices along a "path" can require specific configuration, which
can only be made by a user. Exposing the registers via debugfs seemed
like the most plausible solution.
>
>> + struct device dev;
>> + struct kref kref;
>
> You CAN NOT have two reference counts in the same structure, that's a
> huge design mistake. Stick with one reference count, otherwise they are
> guaranteed to get out of sync and bad things will happen.
In this case the additional @kref is for accounting of components
within the coresight framework only. When the amba framework calls
the driver's _probe() routine the kref count is already equal to '2'
(as expected), even if no
Re: [Patch v3 1/2] kaslr: check if kernel location is changed
On Fri, Sep 12, 2014 at 8:33 AM, Vivek Goyal wrote:
> On Fri, Sep 12, 2014 at 11:22:44PM +0800, Baoquan He wrote:
>> Function handle_relocations() is used to do the relocations handling
>> for i686 and kaslr of x86_64. For 32 bit the relocation handling is
>> mandotary to perform. For x86_64 only when kaslr is enabled and a
>> random kernel location is chosen successfully the relocation handling
>> shound be done. However previous implementation only compared the
>> kernel loading address and LOAD_PHYSICAL_ADDR where kernel were
>> compiled to run at. This would casue system to be exceptional in
>> few conditions like when delta between load address and compiled
>> address is bigger than what 32bit signed relocations can handle.
>> Also there will be limitations that delta can't be too big otherwise
>> kernel text virtual addresses will overflow in module address space.
>>
>> So in this patch check if kernel location is changed after
>> choose_kernel_location() when x86_64. If and only if in x86_64
>> and kernel location is changed, we say a kaslr random kernel
>> location is chosen, then the relocation handling is needed.
>>
>> Signed-off-by: Baoquan He
>
> I think this patch should make kexec and kdump working with kaslr
> enabled (CONFIG_RANDOMIZE_BASE=y).
>
> In case of kdump, we will need to pass "nokaslr" to make sure kernel
> does not move from kexec chosen address.
>
> In case of kexec, I think it should be ok to not pass "nokaslr". This
> case is no different than any other bootloader.
>
> Hence.
> Acked-by: Vivek Goyal
Yup, I think this looks fine to me too. Thanks for getting this fixed!
And as Vivek mentioned later, I think this should probably go into
-stable as well.
Acked-by: Kees Cook
Cc: sta...@vger.kernel.org
-Kees
>
> Thomas D.,
>
> You had reported kexec issues with CONFIG_RANDOMIZE_BASE=y. Does this
> patch resolve the issue for you?
>
> Thanks
> Vivek
>
>> ---
>> arch/x86/boot/compressed/misc.c | 26 ++
>> 1 file changed, 22 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/x86/boot/compressed/misc.c
>> b/arch/x86/boot/compressed/misc.c
>> index 57ab74d..3bb2a17 100644
>> --- a/arch/x86/boot/compressed/misc.c
>> +++ b/arch/x86/boot/compressed/misc.c
>> @@ -230,8 +230,9 @@ static void error(char *x)
>> asm("hlt");
>> }
>>
>> -#if CONFIG_X86_NEED_RELOCS
>> -static void handle_relocations(void *output, unsigned long output_len)
>> +#ifdef CONFIG_X86_NEED_RELOCS
>> +static void handle_relocations(void *output_orig, void *output,
>> +unsigned long output_len)
>> {
>> int *reloc;
>> unsigned long delta, map, ptr;
>> @@ -239,6 +240,20 @@ static void handle_relocations(void *output, unsigned
>> long output_len)
>> unsigned long max_addr = min_addr + output_len;
>>
>> /*
>> + * 32bit always requires relocations to be performed. For x86_64,
>> + * relocations need to be performed only if kaslr has chosen a
>> + * different load address then kernel was originally loaded at.
>> + *
>> + * If we are here, either kaslr is not configured in or kaslr is
>> disabled
>> + * or kaslr has chosen not to change the load location of kernel. Don't
>> + * perform any relocations.
>> + */
>> +#if CONFIG_X86_64
>> + if (output_orig == output)
>> + return;
>> +#endif
>> +
>> + /*
>>* Calculate the delta between where vmlinux was linked to load
>>* and where it was actually loaded.
>>*/
>> @@ -299,7 +314,8 @@ static void handle_relocations(void *output, unsigned
>> long output_len)
>> #endif
>> }
>> #else
>> -static inline void handle_relocations(void *output, unsigned long
>> output_len)
>> +static inline void handle_relocations(void *output_orig, void *output,
>> + unsigned long output_len)
>> { }
>> #endif
>>
>> @@ -360,6 +376,8 @@ asmlinkage __visible void *decompress_kernel(void
>> *rmode, memptr heap,
>> unsigned char *output,
>> unsigned long output_len)
>> {
>> + unsigned char *output_orig = output;
>> +
>> real_mode = rmode;
>>
>> sanitize_boot_params(real_mode);
>> @@ -402,7 +420,7 @@ asmlinkage __visible void *decompress_kernel(void
>> *rmode, memptr heap,
>> debug_putstr("\nDecompressing Linux... ");
>> decompress(input_data, input_len, NULL, NULL, output, NULL, error);
>> parse_elf(output);
>> - handle_relocations(output, output_len);
>> + handle_relocations(output_orig, output, output_len);
>> debug_putstr("done.\nBooting the kernel.\n");
>> return output;
>> }
>> --
>> 1.8.5.3
>>
--
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH arm64-next] net: bpf: arm64: address randomize and write protect JIT code
On 09/12/2014 07:21 PM, Catalin Marinas wrote: ... We don't have a brk instruction for arm32 but we have guaranteed undefined space. Have a look at the kgdb support for example (or grep for register_undef_hook under arch/arm) to get an idea. Will do, thanks! Last but not least ;), if I would resend it today, would you queue it for later on, or do you want to handle it differently? You can send it now, it will be pushed upstream at the right time. Just did, thanks a lot for your help! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/9] locktorture: Rename locktorture_runnable parameter
On Thu, Sep 11, 2014 at 08:40:16PM -0700, Davidlohr Bueso wrote:
> ... to just 'torture_runnable'. It follows other variable naming
> and is shorter.
>
> Signed-off-by: Davidlohr Bueso
Looks good -- and please see below for the corresponding change to the
locktorture scripting. (Which I have queued separately after this change.)
> ---
> kernel/locking/locktorture.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/locking/locktorture.c b/kernel/locking/locktorture.c
> index 0955b88..8c770b2 100644
> --- a/kernel/locking/locktorture.c
> +++ b/kernel/locking/locktorture.c
> @@ -87,9 +87,9 @@ static struct lock_writer_stress_stats *lwsa;
> #else
> #define LOCKTORTURE_RUNNABLE_INIT 0
> #endif
> -int locktorture_runnable = LOCKTORTURE_RUNNABLE_INIT;
> -module_param(locktorture_runnable, int, 0444);
> -MODULE_PARM_DESC(locktorture_runnable, "Start locktorture at module init");
> +int torture_runnable = LOCKTORTURE_RUNNABLE_INIT;
> +module_param(torture_runnable, int, 0444);
> +MODULE_PARM_DESC(torture_runnable, "Start locktorture at module init");
>
> /* Forward reference. */
> static void lock_torture_cleanup(void);
> @@ -355,7 +355,7 @@ static int __init lock_torture_init(void)
> _busted_ops, _lock_ops, _lock_irq_ops,
> };
>
> - if (!torture_init_begin(torture_type, verbose, _runnable))
> + if (!torture_init_begin(torture_type, verbose, _runnable))
> return -EBUSY;
>
> /* Process args and tell the world that the torturer is on the job. */
> --
> 1.8.4.5
locktorture: Make torture scripting account for new _runnable name
Signed-off-by: Paul E. McKenney
diff --git a/tools/testing/selftests/rcutorture/configs/lock/ver_functions.sh
b/tools/testing/selftests/rcutorture/configs/lock/ver_functions.sh
index 9746ea1cd6c7..252aae618984 100644
--- a/tools/testing/selftests/rcutorture/configs/lock/ver_functions.sh
+++ b/tools/testing/selftests/rcutorture/configs/lock/ver_functions.sh
@@ -38,6 +38,6 @@ per_version_boot_params () {
echo $1 `locktorture_param_onoff "$1" "$2"` \
locktorture.stat_interval=15 \
locktorture.shutdown_secs=$3 \
- locktorture.locktorture_runnable=1 \
+ locktorture.torture_runnable=1 \
locktorture.verbose=1
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Sep 12
On 09/12/14 00:38, Stephen Rothwell wrote: > Hi all, > > Changes since 20140911: > - > > 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/ ). No patch tarball? -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 2/2] perf: Marker software event and ioctl
On 9/12/14, 4:48 AM, Pawel Moll wrote: This patch adds a PERF_COUNT_SW_MARKER event type, which can be requested by user and a PERF_EVENT_IOC_MARKER ioctl command which will inject an event of said type into the perf buffer. The ioctl can take a zero-terminated string argument, similar to tracing_marker in ftrace, which will be kept in the "raw" field of the sample. The main use case for this is synchronisation of performance data generated in user space with the perf stream coming from the kernel. For example, the marker can be inserted by a JIT engine after it generated portion of the code, but before the code is executed for the first time, allowing the post-processor to pick the correct debugging information. Other example is a system profiling tool taking data from other sources than just perf, which generates a marker at the beginning at at the end of the session (also possibly periodically during the session) to synchronise kernel timestamps with clock values obtained in userspace (gtod or raw_monotonic). Seems really similar to what I proposed in the past: https://lkml.org/lkml/2011/2/27/159 Which was rejected. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
