[PATCH v6 09/14] mmc: sdhci-xenon: Add support to PHYs of Marvell Xenon SDHC
From: Hu Ziji Marvell Xenon eMMC/SD/SDIO Host Controller contains PHY. Multiple types of PHYs are supported. Add support to multiple types of PHYs init and configuration. Add register definitions of PHYs. Xenon PHY cannot fit in kernel common PHY framework. Xenon SDHC PHY register is a part of Xenon SDHC register set. Besides, MMC initialization has to call several PHY functions to complete timing setting. Those PHY setting functions have to access SDHC registers and know current MMC setting, such as bus width, clock frequency and speed mode. As a result, implement Xenon PHY in MMC host directory. Signed-off-by: Hu Ziji Signed-off-by: Gregory CLEMENT --- drivers/mmc/host/Makefile | 2 +- drivers/mmc/host/sdhci-xenon-phy.c | 751 ++- drivers/mmc/host/sdhci-xenon.c | 3 +- drivers/mmc/host/sdhci-xenon.h | 37 +- 4 files changed, 791 insertions(+), 2 deletions(-) create mode 100644 drivers/mmc/host/sdhci-xenon-phy.c diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile index b0a2ab4b256e..893b48db5513 100644 --- a/drivers/mmc/host/Makefile +++ b/drivers/mmc/host/Makefile @@ -84,4 +84,4 @@ ifeq ($(CONFIG_CB710_DEBUG),y) endif obj-$(CONFIG_MMC_SDHCI_XENON) += sdhci-xenon-driver.o -sdhci-xenon-driver-y += sdhci-xenon.o +sdhci-xenon-driver-y += sdhci-xenon.o sdhci-xenon-phy.o diff --git a/drivers/mmc/host/sdhci-xenon-phy.c b/drivers/mmc/host/sdhci-xenon-phy.c new file mode 100644 index ..c26ba3a180a0 --- /dev/null +++ b/drivers/mmc/host/sdhci-xenon-phy.c @@ -0,0 +1,751 @@ +/* + * PHY support for Xenon SDHC + * + * Copyright (C) 2016 Marvell, All Rights Reserved. + * + * Author: Hu Ziji + * Date: 2016-8-24 + * + * 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 version 2. + */ + +#include +#include +#include + +#include "sdhci-pltfm.h" +#include "sdhci-xenon.h" + +/* Register base for eMMC PHY 5.0 Version */ +#define XENON_EMMC_5_0_PHY_REG_BASE0x0160 +/* Register base for eMMC PHY 5.1 Version */ +#define XENON_EMMC_PHY_REG_BASE0x0170 + +#define XENON_EMMC_PHY_TIMING_ADJUST XENON_EMMC_PHY_REG_BASE +#define XENON_EMMC_5_0_PHY_TIMING_ADJUST XENON_EMMC_5_0_PHY_REG_BASE +#define XENON_TIMING_ADJUST_SLOW_MODE BIT(29) +#define XENON_TIMING_ADJUST_SDIO_MODE BIT(28) +#define XENON_OUTPUT_QSN_PHASE_SELECT BIT(17) +#define XENON_SAMPL_INV_QSP_PHASE_SELECT BIT(18) +#define XENON_SAMPL_INV_QSP_PHASE_SELECT_SHIFT 18 +#define XENON_PHY_INITIALIZAIONBIT(31) +#define XENON_WAIT_CYCLE_BEFORE_USING_MASK 0xF +#define XENON_WAIT_CYCLE_BEFORE_USING_SHIFT12 +#define XENON_FC_SYNC_EN_DURATION_MASK 0xF +#define XENON_FC_SYNC_EN_DURATION_SHIFT8 +#define XENON_FC_SYNC_RST_EN_DURATION_MASK 0xF +#define XENON_FC_SYNC_RST_EN_DURATION_SHIFT4 +#define XENON_FC_SYNC_RST_DURATION_MASK0xF +#define XENON_FC_SYNC_RST_DURATION_SHIFT 0 + +#define XENON_EMMC_PHY_FUNC_CONTROL(XENON_EMMC_PHY_REG_BASE + 0x4) +#define XENON_EMMC_5_0_PHY_FUNC_CONTROL\ + (XENON_EMMC_5_0_PHY_REG_BASE + 0x4) +#define XENON_ASYNC_DDRMODE_MASK BIT(23) +#define XENON_ASYNC_DDRMODE_SHIFT 23 +#define XENON_CMD_DDR_MODE BIT(16) +#define XENON_DQ_DDR_MODE_SHIFT8 +#define XENON_DQ_DDR_MODE_MASK 0xFF +#define XENON_DQ_ASYNC_MODEBIT(4) + +#define XENON_EMMC_PHY_PAD_CONTROL (XENON_EMMC_PHY_REG_BASE + 0x8) +#define XENON_EMMC_5_0_PHY_PAD_CONTROL \ + (XENON_EMMC_5_0_PHY_REG_BASE + 0x8) +#define XENON_REC_EN_SHIFT 24 +#define XENON_REC_EN_MASK 0xF +#define XENON_FC_DQ_RECEN BIT(24) +#define XENON_FC_CMD_RECEN BIT(25) +#define XENON_FC_QSP_RECEN BIT(26) +#define XENON_FC_QSN_RECEN BIT(27) +#define XENON_OEN_QSN BIT(28) +#define XENON_AUTO_RECEN_CTRL BIT(30) +#define XENON_FC_ALL_CMOS_RECEIVER 0xF000 + +#define XENON_EMMC5_FC_QSP_PD BIT(18) +#define XENON_EMMC5_FC_QSP_PU BIT(22) +#define XENON_EMMC5_FC_CMD_PD BIT(17) +#define XENON_EMMC5_FC_CMD_PU BIT(21) +#define XENON_EMMC5_FC_DQ_PD BIT(16) +#define XENON_EMMC5_FC_DQ_PU BIT(20) + +#define XENON_EMMC_PHY_PAD_CONTROL1(XENON_EMMC_PHY_REG_BASE + 0xC) +#define XENON_EMMC5_1_FC_QSP_PDBIT(9) +#define XENON_EMMC5_1_FC_QSP_PUBIT(25) +#define XENON_EMMC5_1_FC_CMD_PDBIT(8) +#define XENON_EMMC5_1_FC_CMD_PU
Re: Regression in next with use printk_safe buffers in printk
* Sergey Senozhatsky [170214 08:58]:
> On (02/14/17 17:18), Peter Zijlstra wrote:
> > On Wed, Feb 15, 2017 at 01:01:40AM +0900, Sergey Senozhatsky wrote:
> > >
> > > but I'm a bit confused by rt_b->rt_runtime_lock in this unsafe lock
> > > scenario (so it's not ABBA, but ABAD)
> > >
> > > > lock(hrtimer_bases.lock);
> > > >lock(&rt_b->rt_runtime_lock);
> > > >lock(hrtimer_bases.lock);
> > > > lock(tk_core);
> > > >
> > > >
> > > > Chain exists of:
> > > >
> > > > tk_core --> &rt_b->rt_runtime_lock --> hrtimer_bases.lock
> > >
> > >
> > > I'm lacking some knowledge here, sorry. where does the tk_core -->
> > > &rt_b->rt_runtime_lock
> > > come from?
> >
> > rt_b->rt_runtime_lock is one of the scheduler locks, since we do
> > printk() under tk_core, which does semaphore muck, which then includes
> > the entire scheduler chain of locks.
>
> thanks, Peter.
>
> that crossed my mind, but I kinda assumed that we do printk() from
> under tk_core using sched fair, and rt_runtime_lock is from sched rt.
>
>
> so something like below, perhaps. would be helpful if Tony can test it.
>
> (I'll send out this patch 'in a proper way' tomorrow, after some sleep,
> it's 2am here).
>
> 8<
>
> From e1755b0bf7f8a0be5fdf4dd7303bf4cd150d9d20 Mon Sep 17 00:00:00 2001
> From: Sergey Senozhatsky
> Date: Wed, 15 Feb 2017 01:42:18 +0900
> Subject: [PATCH] time/timekeeping_debug: use printk_deferred()
>
> Do not call printk() from tk_debug_account_sleep_time(), because
> tk_debug_account_sleep_time() is called under tk_core seq lock.
> It's not safe to call printk() under tk_core, because console_sem
> invokes scheduled (via wake_up_process()->activate_task()), which,
> in turn, can call timekeeping code again, for instance, via
> get_time()->ktime_get(). This may result in infinite loop on
> tk_core.
>
> Signed-off-by: Sergey Senozhatsky
Thanks yeah this fixes the issue for me:
Tested-by: Tony Lindgren
> ---
> kernel/time/timekeeping_debug.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/time/timekeeping_debug.c b/kernel/time/timekeeping_debug.c
> index ca9fb800336b..b8f7146c3538 100644
> --- a/kernel/time/timekeeping_debug.c
> +++ b/kernel/time/timekeeping_debug.c
> @@ -75,7 +75,8 @@ void tk_debug_account_sleep_time(struct timespec64 *t)
> int bin = min(fls(t->tv_sec), NUM_BINS-1);
>
> sleep_time_bin[bin]++;
> - pr_info("Suspended for %lld.%03lu seconds\n", (s64)t->tv_sec,
> + printk_deferred(KERN_INFO "Suspended for %lld.%03lu seconds\n",
> + (s64)t->tv_sec,
> t->tv_nsec / NSEC_PER_MSEC);
> }
>
> --
> 2.11.1
>
[PATCH v6 10/14] mmc: sdhci-xenon: Add SoC PHY PAD voltage control
From: Hu Ziji
Some SoCs have PHY PAD outside Xenon IP.
PHY PAD voltage should match signalling voltage in use.
Add generic SoC PHY PAD voltage control interface.
Implement Aramda-3700 SoC PHY PAD voltage control.
Signed-off-by: Hu Ziji
Tested-by: Russell King
Signed-off-by: Gregory CLEMENT
---
drivers/mmc/host/sdhci-xenon-phy.c | 116 +-
drivers/mmc/host/sdhci-xenon.c | 2 +-
drivers/mmc/host/sdhci-xenon.h | 2 +-
3 files changed, 119 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci-xenon-phy.c
b/drivers/mmc/host/sdhci-xenon-phy.c
index c26ba3a180a0..c3b7e9a21f6b 100644
--- a/drivers/mmc/host/sdhci-xenon-phy.c
+++ b/drivers/mmc/host/sdhci-xenon-phy.c
@@ -143,6 +143,27 @@ enum phy_type_enum {
NR_PHY_TYPES
};
+enum soc_pad_ctrl_type {
+ SOC_PAD_SD,
+ SOC_PAD_FIXED_1_8V,
+};
+
+struct soc_pad_ctrl_table {
+ const char *soc;
+ void (*set_soc_pad)(struct sdhci_host *host,
+ unsigned char signal_voltage);
+};
+
+struct soc_pad_ctrl {
+ /* Register address of SoC PHY PAD ctrl */
+ void __iomem*reg;
+ /* SoC PHY PAD ctrl type */
+ enum soc_pad_ctrl_type pad_type;
+ /* SoC specific operation to set SoC PHY PAD */
+ void (*set_soc_pad)(struct sdhci_host *host,
+ unsigned char signal_voltage);
+};
+
static struct xenon_emmc_phy_regs xenon_emmc_5_0_phy_regs = {
.timing_adj = XENON_EMMC_5_0_PHY_TIMING_ADJUST,
.func_ctrl = XENON_EMMC_5_0_PHY_FUNC_CONTROL,
@@ -176,6 +197,8 @@ struct emmc_phy_params {
u8 nr_tun_times;
/* Divider for calculating Tuning Step */
u8 tun_step_divider;
+
+ struct soc_pad_ctrl pad_ctrl;
};
static int alloc_emmc_phy(struct sdhci_xenon_priv *priv)
@@ -252,6 +275,45 @@ static int emmc_phy_init(struct sdhci_host *host)
return 0;
}
+#define ARMADA_3700_SOC_PAD_1_8V 0x1
+#define ARMADA_3700_SOC_PAD_3_3V 0x0
+
+static void armada_3700_soc_pad_voltage_set(struct sdhci_host *host,
+ unsigned char signal_voltage)
+{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
+ struct emmc_phy_params *params = priv->phy_params;
+
+ if (params->pad_ctrl.pad_type == SOC_PAD_FIXED_1_8V) {
+ writel(ARMADA_3700_SOC_PAD_1_8V, params->pad_ctrl.reg);
+ } else if (params->pad_ctrl.pad_type == SOC_PAD_SD) {
+ if (signal_voltage == MMC_SIGNAL_VOLTAGE_180)
+ writel(ARMADA_3700_SOC_PAD_1_8V, params->pad_ctrl.reg);
+ else if (signal_voltage == MMC_SIGNAL_VOLTAGE_330)
+ writel(ARMADA_3700_SOC_PAD_3_3V, params->pad_ctrl.reg);
+ }
+}
+
+/*
+ * Set SoC PHY voltage PAD control register,
+ * according to the operation voltage on PAD.
+ * The detailed operation depends on SoC implementation.
+ */
+static void emmc_phy_set_soc_pad(struct sdhci_host *host,
+unsigned char signal_voltage)
+{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
+ struct emmc_phy_params *params = priv->phy_params;
+
+ if (!params->pad_ctrl.reg)
+ return;
+
+ if (params->pad_ctrl.set_soc_pad)
+ params->pad_ctrl.set_soc_pad(host, signal_voltage);
+}
+
/*
* Enable eMMC PHY HW DLL
* DLL should be enabled and stable before HS200/SDR104 tuning,
@@ -584,6 +646,51 @@ static void emmc_phy_set(struct sdhci_host *host,
dev_dbg(mmc_dev(host->mmc), "eMMC PHY setting completes\n");
}
+static int get_dt_pad_ctrl_data(struct sdhci_host *host,
+ struct device_node *np,
+ struct emmc_phy_params *params)
+{
+ int ret = 0;
+ const char *name;
+ struct resource iomem;
+
+ if (of_device_is_compatible(np, "marvell,armada-3700-sdhci"))
+ params->pad_ctrl.set_soc_pad = armada_3700_soc_pad_voltage_set;
+ else
+ return 0;
+
+ if (of_address_to_resource(np, 1, &iomem)) {
+ dev_err(mmc_dev(host->mmc), "Unable to find SoC PAD ctrl
register address for %s\n",
+ np->name);
+ return -EINVAL;
+ }
+
+ params->pad_ctrl.reg = devm_ioremap_resource(mmc_dev(host->mmc),
+&iomem);
+ if (IS_ERR(params->pad_ctrl.reg)) {
+ dev_err(mmc_dev(host->mmc), "Unable to get SoC PHY PAD ctrl
register for %s\n",
+ np->name);
+ return PTR_ERR(params->pad_ctrl.reg);
+ }
+
+ ret = of_property_read_string(np, "marvell,pad-type", &name);
+ if (ret) {
+ dev_err(mmc_dev(host->mmc), "Unable to determine SoC PHY PAD
[PATCH v6 07/14] dt: bindings: Add bindings for Marvell Xenon SD Host Controller
From: Hu Ziji
Marvell Xenon SDHC can support eMMC/SD/SDIO.
Add Xenon-specific properties.
Also add properties for Xenon PHY setting.
Signed-off-by: Hu Ziji
Signed-off-by: Gregory CLEMENT
---
Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt | 172 +++-
1 file changed, 172 insertions(+)
create mode 100644
Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
diff --git a/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
new file mode 100644
index ..eabee8b64db6
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
@@ -0,0 +1,172 @@
+Marvell Xenon SDHCI Controller device tree bindings
+This file documents differences between the core mmc properties
+described by mmc.txt and the properties used by the Xenon implementation.
+
+Multiple SDHCs might be put into a single Xenon IP, to save size and cost.
+Each SDHC is independent and owns independent resources, such as register sets,
+clock and PHY.
+Each SDHC should have an independent device tree node.
+
+Required Properties:
+- compatible: should be one of the following
+ - "marvell,armada-3700-sdhci": For controllers on Armada-3700 SoC.
+ Must provide a second register area and marvell,pad-type.
+ - "marvell,armada-ap806-sdhci": For controllers on Armada AP806.
+ - "marvell,armada-cp110-sdhci": For controllers on Armada CP110.
+
+- clocks:
+ Array of clocks required for SDHC.
+ Require at least input clock for Xenon IP core.
+
+- clock-names:
+ Array of names corresponding to clocks property.
+ The input clock for Xenon IP core should be named as "core".
+
+- reg:
+ * For "marvell,armada-3700-sdhci", two register areas.
+The first one for Xenon IP register. The second one for the Armada 3700 SoC
+PHY PAD Voltage Control register.
+Please follow the examples with compatible "marvell,armada-3700-sdhci"
+in below.
+Please also check property marvell,pad-type in below.
+
+ * For other compatible strings, one register area for Xenon IP.
+
+Optional Properties:
+- marvell,xenon-sdhc-id:
+ Indicate the corresponding bit index of current SDHC in
+ SDHC System Operation Control Register Bit[7:0].
+ Set/clear the corresponding bit to enable/disable current SDHC.
+ If Xenon IP contains only one SDHC, this property is optional.
+
+- marvell,xenon-phy-type:
+ Xenon support multiple types of PHYs.
+ To select eMMC 5.1 PHY, set:
+ marvell,xenon-phy-type = "emmc 5.1 phy"
+ eMMC 5.1 PHY is the default choice if this property is not provided.
+ To select eMMC 5.0 PHY, set:
+ marvell,xenon-phy-type = "emmc 5.0 phy"
+
+ All those types of PHYs can support eMMC, SD and SDIO.
+ Please note that this property only presents the type of PHY.
+ It doesn't stand for the entire SDHC type or property.
+ For example, "emmc 5.1 phy" doesn't mean that this Xenon SDHC only
+ supports eMMC 5.1.
+
+- marvell,xenon-phy-znr:
+ Set PHY ZNR value.
+ Only available for eMMC PHY.
+ Valid range = [0:0x1F].
+ ZNR is set as 0xF by default if this property is not provided.
+
+- marvell,xenon-phy-zpr:
+ Set PHY ZPR value.
+ Only available for eMMC PHY.
+ Valid range = [0:0x1F].
+ ZPR is set as 0xF by default if this property is not provided.
+
+- marvell,xenon-phy-nr-success-tun:
+ Set the number of required consecutive successful sampling points
+ used to identify a valid sampling window, in tuning process.
+ Valid range = [1:7].
+ Set as 0x4 by default if this property is not provided.
+
+- marvell,xenon-phy-tun-step-divider:
+ Set the divider for calculating TUN_STEP.
+ Set as 64 by default if this property is not provided.
+
+- marvell,xenon-phy-slow-mode:
+ If this property is selected, transfers will bypass PHY.
+ Only available when bus frequency lower than 55MHz in SDR mode.
+ Disabled by default. Please only try this property if timing issues
+ always occur with PHY enabled in eMMC HS SDR, SD SDR12, SD SDR25,
+ SD Default Speed and HS mode and eMMC legacy speed mode.
+
+- marvell,xenon-tun-count:
+ Xenon SDHC SoC usually doesn't provide re-tuning counter in
+ Capabilities Register 3 Bit[11:8].
+ This property provides the re-tuning counter.
+ If this property is not set, default re-tuning counter will
+ be set as 0x9 in driver.
+
+- marvell,pad-type:
+ Type of Armada 3700 SoC PHY PAD Voltage Controller register.
+ Only valid when "marvell,armada-3700-sdhci" is selected.
+ Two types: "sd" and "fixed-1-8v".
+ If "sd" is selected, SoC PHY PAD is set as 3.3V at the beginning and is
+ switched to 1.8V when later in higher speed mode.
+ If "fixed-1-8v" is selected, SoC PHY PAD is fixed 1.8V, such as for eMMC.
+ Please follow the examples with compatible "marvell,armada-3700-sdhci"
+ in below.
+
+Example:
+- For eMMC:
+
+ sdhci@aa {
+ compatible = "marvell,armada-ap806-sdhci";
+ reg = <0xaa 0x1000>;
+ interrupts =
+
[PATCH v6 00/14] mmc: Add support to Marvell Xenon SD Host Controller
Hello, This the sixth version of the series adding support for the SDHCI Xenon controller. It can be currently found on the Armada 37xx and the Armada 7K/8K but will be also used in more Marvell SoC (and not only the mvebu ones actually). Most of the following changes had been discussed on the mailing list, except the new compatible string. It occurred that the xenon controller was integrated in a different way in the AP806 and the CP110 which both are part of the Armada 7K/8K SoCs. For example the Xenon controller in CP110 doesn't not support HS200. v5->v6: - Add a generic "mmc-card" parse in core layer. - Fix the spelling issues in Xenon dt binding doc and drivers. - Remove descriptions to common mmc properties from Xenon dt binding doc. - Split compatible string "marvell,armada-8k-sdhci" into "marvell,armada-ap806-sdhci" and "marvell,armada-cp110-sdhci". - Also updates the example in Xenon dt binding doc. - Remove unnecessary dependency on MMC_SDHCI from Xenon entry in Kconfig. - Move Xenon specific dt parse into a separate function. - Adjust warnings and condition check in Xenon PHY setting, to remove fragile hs200->hs400/hs400->hs200 sequence check function. - Enable PHY Slow Mode in MMC_TIMING_LEGACY timing if PHY Slow Mode is required in dts. - Add a patch allowing dts backwards compatible for the clock v4->v5: - Remove the patch to export sdhci_execute_tuning(). It is already exported in v4.10. - Introduce a patch adding a missing clock for the sdhci controller present on the CP master for A7K/A8K. There is no build dependency but obviously this patch is need to use the sdhci controller present on the CP part. - Adjust Xenon return setup, to avoid being overwritten by sdhci_add_host(). - Change Xenon register definition prefix to "XENON_". - Fix typos in Xenon driver and dt-binding docs. - Change compatible string "marvell,armada-7000-sdhci" to "marvell,armada-8k-sdhci". Actually the Armada 7K SoCs are a subset of the Armada 8K SoCs. Moreover, the use of the '000' is not consistent with all the other compatible string already used for the Armada 7K/8K family. - Added the Tested-by from Russell King on an Armada 8K based board. v3 -> v4: For this version a few change have been done: - fixes 2 bug reported by kbuild-bot - remove extra of_node_put() - convert 0 in false for function returning boolean - add a device tree node for the sdhci controller present on the CP master for A7K/A8K. It also led to rename the sdhci0 node on AP to ap_sdhci0 to make a distinction with the one present on CP master. v2 -> v3 I think that now most (if not all) the remarks had been taking into account since the second version. According to Ziji Hu, here are the following changes: " Changes in V3: Adjust and improve Xenon DT bindings. Move some caps setting from driver into DT. Use mmc-card sub-node to represent eMMC type. Remove PHY Sampling Fixed Delay Line scan in lower speed mode. Improve Xenon probe and ->init_card() functions. Export sdhci_enable_sdio_irq() and implement own SDIO IRQ control. Split PHY patch into two smaller patches. Temporarily remove AXI clock before its implementation is improved." Besides this changes I also - Removed the sdhci-xenon-phy.h and moved its content in the shc-xenon-phy.c file. - Fixed the tuning-count usage - Managed the error case for clk_prepare_enable For the record the change from v1 was: " Changes in V2: rebase on v4.9-rc2. Re-write Xenon bindings. Ajust Xenon DT property naming. Add a new DT property to indicate eMMC card type, instead of using variable card_candidate. Clear quirks SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 in Xenon platform data Add support to HS400 retuning." Thanks, Gregory Gregory CLEMENT (4): clk: apn806: Turn the eMMC clock as optional for dts backwards compatible arm64: dts: marvell: add eMMC support for Armada 37xx arm64: dts: marvell: add sdhci support for Armada 7K/8K arm64: configs: enable SDHCI driver for Xenon Hu Ziji (9): mmc: core: Add mmc-card dt sub-node parse in core layer mmc: sdhci: Export sdhci_set_ios() from sdhci.c mmc: sdhci: Export sdhci_start_signal_voltage_switch() in sdhci.c mmc: sdhci: Export sdhci_enable_sdio_irq() from sdhci.c dt: bindings: Add bindings for Marvell Xenon SD Host Controller mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality mmc: sdhci-xenon: Add support to PHYs of Marvell Xenon SDHC mmc: sdhci-xenon: Add SoC PHY PAD voltage control MAINTAINERS: add entry for Marvell Xenon MMC Host Controller drivers Konstantin Porotchkin (1): clk: apn806: Add eMMC clock to system controller driver Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt | 172 +- MAINTAINERS | 7 +- arch/arm64/boot/dts/marvell/armada-3720-db.dts| 16 +- arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 11 +- arch/arm64/boot/dts/marvell/
[PATCH v6 06/14] mmc: sdhci: Export sdhci_enable_sdio_irq() from sdhci.c
From: Hu Ziji
Export sdhci_enable_sdio_irq() from sdhci.c.
Thus vendor SDHC driver can implement its specific SDIO irq
control.
Signed-off-by: Hu Ziji
Signed-off-by: Gregory CLEMENT
---
drivers/mmc/host/sdhci.c | 3 ++-
drivers/mmc/host/sdhci.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index d2338dc362f4..9a4fda81ff81 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1824,7 +1824,7 @@ static void sdhci_enable_sdio_irq_nolock(struct
sdhci_host *host, int enable)
}
}
-static void sdhci_enable_sdio_irq(struct mmc_host *mmc, int enable)
+void sdhci_enable_sdio_irq(struct mmc_host *mmc, int enable)
{
struct sdhci_host *host = mmc_priv(mmc);
unsigned long flags;
@@ -1838,6 +1838,7 @@ static void sdhci_enable_sdio_irq(struct mmc_host *mmc,
int enable)
sdhci_enable_sdio_irq_nolock(host, enable);
spin_unlock_irqrestore(&host->lock, flags);
}
+EXPORT_SYMBOL_GPL(sdhci_enable_sdio_irq);
int sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
struct mmc_ios *ios)
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index e4a07543a12b..609783364941 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -694,6 +694,7 @@ int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode);
void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios);
int sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
struct mmc_ios *ios);
+void sdhci_enable_sdio_irq(struct mmc_host *mmc, int enable);
#ifdef CONFIG_PM
extern int sdhci_suspend_host(struct sdhci_host *host);
--
git-series 0.9.1
[PATCH v6 05/14] mmc: sdhci: Export sdhci_start_signal_voltage_switch() in sdhci.c
From: Hu Ziji
Export sdhci_start_signal_voltage_switch() from sdhci.c.
Thus vendor sdhci driver can implement its own signal voltage
switch routine.
Signed-off-by: Hu Ziji
Signed-off-by: Gregory CLEMENT
---
drivers/mmc/host/sdhci.c | 5 +++--
drivers/mmc/host/sdhci.h | 2 ++
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 0e9ed0fadff9..d2338dc362f4 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1839,8 +1839,8 @@ static void sdhci_enable_sdio_irq(struct mmc_host *mmc,
int enable)
spin_unlock_irqrestore(&host->lock, flags);
}
-static int sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
-struct mmc_ios *ios)
+int sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
+ struct mmc_ios *ios)
{
struct sdhci_host *host = mmc_priv(mmc);
u16 ctrl;
@@ -1932,6 +1932,7 @@ static int sdhci_start_signal_voltage_switch(struct
mmc_host *mmc,
return 0;
}
}
+EXPORT_SYMBOL_GPL(sdhci_start_signal_voltage_switch);
static int sdhci_card_busy(struct mmc_host *mmc)
{
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 3563c0c384ca..e4a07543a12b 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -692,6 +692,8 @@ void sdhci_reset(struct sdhci_host *host, u8 mask);
void sdhci_set_uhs_signaling(struct sdhci_host *host, unsigned timing);
int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode);
void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios);
+int sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
+ struct mmc_ios *ios);
#ifdef CONFIG_PM
extern int sdhci_suspend_host(struct sdhci_host *host);
--
git-series 0.9.1
Re: [PATCH v2] drm/amd/dc: resource: fix semicolon.cocci warnings (fwd)
Thanks for these fixes. I'll merge them.
Reviewed-by: Harry Wentland
Harry
On 2017-02-14 04:47 AM, Christian König wrote:
Am 14.02.2017 um 07:21 schrieb Julia Lawall:
Remove unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
CC: Harry Wentland
Signed-off-by: Julia Lawall
Signed-off-by: Fengguang Wu
Acked-by: Christian König for this one as
well as the other similar patches.
Thanks for letting us know about those typos.
Regards,
Christian.
---
v2: make subject line unique
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-4.9
head: 79d2de1bcb650296adff1cb08bfbf1501a6e6e14
commit: bad4c165a6986a131cdd1455507ba3857baaa561 [201/657]
drm/amd/dc: Add
dc display driver
dc_resource.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c
@@ -135,7 +135,7 @@ static void update_num_audio(
break;
default:
DC_ERR("DC: unexpected audio fuse!\n");
-};
+}
}
bool resource_construct(
Re: [PATCH net-next v1] bpf: Remove redundant ifdef
From: "Wangnan (F)"
Date: Mon, 13 Feb 2017 09:53:49 +0800
>
>
> On 2017/2/12 3:37, Mickaël Salaün wrote:
>> Remove a useless ifdef __NR_bpf as requested by Wang Nan.
>>
>> Inline one-line static functions as it was in the bpf_sys.h file.
>>
>> Signed-off-by: Mickaël Salaün
>> Cc: Alexei Starovoitov
>> Cc: Daniel Borkmann
>> Cc: David S. Miller
>> Cc: Wang Nan
>> Link:
>> https://lkml.kernel.org/r/828ab1ff-4dcf-53ff-c97b-074adb895...@huawei.com
>> ---
>> tools/lib/bpf/bpf.c | 12 +++-
>> 1 file changed, 3 insertions(+), 9 deletions(-)
>>
>> diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
>> index 50e04cc5..2de9c386989a 100644
>> --- a/tools/lib/bpf/bpf.c
>> +++ b/tools/lib/bpf/bpf.c
>> @@ -42,21 +42,15 @@
>> # endif
>> #endif
>> -static __u64 ptr_to_u64(const void *ptr)
>> +static inline __u64 ptr_to_u64(const void *ptr)
>> {
>> return (__u64) (unsigned long) ptr;
>> }
>> -static int sys_bpf(enum bpf_cmd cmd, union bpf_attr *attr,
>> - unsigned int size)
>> +static inline int sys_bpf(enum bpf_cmd cmd, union bpf_attr *attr,
>> + unsigned int size)
>> {
>> -#ifdef __NR_bpf
>> return syscall(__NR_bpf, cmd, attr, size);
>> -#else
>> -fprintf(stderr, "No bpf syscall, kernel headers too old?\n");
>> -errno = ENOSYS;
>> -return -1;
>> -#endif
>> }
>> int bpf_create_map(enum bpf_map_type map_type, int key_size,
>
> Acked-by: Wang Nan
>
> However, it is better to merge this patch with commit
> 702498a1426bc95b6f49f9c5fba616110cbd3947.
I don't know where this commit ID is. Since this patch is targetting
net-next I would expect a commit ID with not context to be in that
tree. Please always specify where the commit ID you mention is.
Futhermore, commits in net-next are permanent so it is not possible
afterwards to "merge this patch with commit X".
Re: [PATCH] drm/amd/dc: hw_sequencer: fix semicolon.cocci warnings
Reviewed-by: Harry Wentland
Harry
On 2017-02-14 01:19 AM, Julia Lawall wrote:
Remove unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
CC: Harry Wentland
Signed-off-by: Julia Lawall
Signed-off-by: Fengguang Wu
---
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-4.9
head: 79d2de1bcb650296adff1cb08bfbf1501a6e6e14
commit: bad4c165a6986a131cdd1455507ba3857baaa561 [201/657] drm/amd/dc: Add
dc display driver
dce110_hw_sequencer.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/amd/amdgpu/../display/dc/dce110/dce110_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/amdgpu/../display/dc/dce110/dce110_hw_sequencer.c
@@ -1643,7 +1643,7 @@ static void init_hw(struct core_dc *dc)
true);
}
- dce_clock_gating_power_up(dc->hwseq, false);;
+ dce_clock_gating_power_up(dc->hwseq, false);
/***/
for (i = 0; i < dc->link_count; i++) {
Re: [PATCH] drm/amd/dc: fix semicolon.cocci warnings
Reviewed-by: Harry Wentland Harry On 2017-02-14 01:13 AM, Julia Lawall wrote: Remove unneeded semicolons. Generated by: scripts/coccinelle/misc/semicolon.cocci CC: Harry Wentland Signed-off-by: Julia Lawall Signed-off-by: Fengguang Wu --- tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-4.9 head: 79d2de1bcb650296adff1cb08bfbf1501a6e6e14 commit: bad4c165a6986a131cdd1455507ba3857baaa561 [201/657] drm/amd/dc: Add dc display driver amdgpu_dm_types.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) --- a/drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_types.c +++ b/drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_types.c @@ -890,11 +890,11 @@ static void copy_crtc_timing_for_drm_dis dst_mode->crtc_hsync_end = src_mode->crtc_hsync_end; dst_mode->crtc_htotal = src_mode->crtc_htotal; dst_mode->crtc_hskew = src_mode->crtc_hskew; - dst_mode->crtc_vblank_start = src_mode->crtc_vblank_start;; - dst_mode->crtc_vblank_end = src_mode->crtc_vblank_end;; - dst_mode->crtc_vsync_start = src_mode->crtc_vsync_start;; - dst_mode->crtc_vsync_end = src_mode->crtc_vsync_end;; - dst_mode->crtc_vtotal = src_mode->crtc_vtotal;; + dst_mode->crtc_vblank_start = src_mode->crtc_vblank_start; + dst_mode->crtc_vblank_end = src_mode->crtc_vblank_end; + dst_mode->crtc_vsync_start = src_mode->crtc_vsync_start; + dst_mode->crtc_vsync_end = src_mode->crtc_vsync_end; + dst_mode->crtc_vtotal = src_mode->crtc_vtotal; } static void decide_crtc_timing_for_drm_display_mode(
[PATCH] crypto: cavium: fix Kconfig dependencies
The driver fails to build if MSI support is disabled: In file included from /git/arm-soc/drivers/crypto/cavium/cpt/cptpf_main.c:18:0: drivers/crypto/cavium/cpt/cptpf.h:57:20: error: array type has incomplete element type 'struct msix_entry' struct msix_entry msix_entries[CPT_PF_MSIX_VECTORS]; ^~~~ drivers/crypto/cavium/cpt/cptpf_main.c: In function 'cpt_enable_msix': drivers/crypto/cavium/cpt/cptpf_main.c:344:8: error: implicit declaration of function 'pci_enable_msix';did you mean 'cpt_enable_msix'? [-Werror=implicit-function-declaration] On the other hand, it doesn't seem to have any build dependency on ARCH_THUNDER, so let's allow compile-testing to catch this kind of problem more easily. The 64-bit dependency is needed for the use of readq/writeq. Signed-off-by: Arnd Bergmann --- drivers/crypto/cavium/cpt/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/crypto/cavium/cpt/Kconfig b/drivers/crypto/cavium/cpt/Kconfig index 247f1cbbefc1..cbd51b1aa046 100644 --- a/drivers/crypto/cavium/cpt/Kconfig +++ b/drivers/crypto/cavium/cpt/Kconfig @@ -7,7 +7,8 @@ config CRYPTO_DEV_CPT config CAVIUM_CPT tristate "Cavium Cryptographic Accelerator driver" - depends on ARCH_THUNDER + depends on ARCH_THUNDER || COMPILE_TEST + depends on PCI_MSI && 64BIT select CRYPTO_DEV_CPT help Support for Cavium CPT block found in octeon-tx series of -- 2.9.0
[PATCH] xfs: fix len comparison in xfs_extent_busy_trim
The length is now passed by reference, so the assertion has to be updated
to match the other changes, as pointed out by this W=1 warning:
fs/xfs/xfs_extent_busy.c: In function 'xfs_extent_busy_trim':
fs/xfs/xfs_extent_busy.c:356:13: error: ordered comparison of pointer with
integer zero [-Werror=extra]
Fixes: ebf55872616c ("xfs: improve handling of busy extents in the low-level
allocator")
Signed-off-by: Arnd Bergmann
---
fs/xfs/xfs_extent_busy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/xfs/xfs_extent_busy.c b/fs/xfs/xfs_extent_busy.c
index ab062610234e..77760dbf0242 100644
--- a/fs/xfs/xfs_extent_busy.c
+++ b/fs/xfs/xfs_extent_busy.c
@@ -353,7 +353,7 @@ xfs_extent_busy_trim(
struct rb_node *rbp;
boolret = false;
- ASSERT(len > 0);
+ ASSERT(*len > 0);
spin_lock(&args->pag->pagb_lock);
restart:
--
2.9.0
Re: [PATCH] drm/amd/dc: fix semicolon.cocci warnings
Reviewed-by: Harry Wentland
Harry
On 2017-02-14 01:14 AM, Julia Lawall wrote:
Remove unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
CC: Harry Wentland
Signed-off-by: Julia Lawall
Signed-off-by: Fengguang Wu
---
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-4.9
head: 79d2de1bcb650296adff1cb08bfbf1501a6e6e14
commit: bad4c165a6986a131cdd1455507ba3857baaa561 [201/657] drm/amd/dc: Add
dc display driver
dc_resource.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c
@@ -135,7 +135,7 @@ static void update_num_audio(
break;
default:
DC_ERR("DC: unexpected audio fuse!\n");
- };
+ }
}
bool resource_construct(
Re: [PATCH] crypto: cavium: fix Kconfig dependencies
On 02/14/2017 09:07 AM, Arnd Bergmann wrote: The driver fails to build if MSI support is disabled: In file included from /git/arm-soc/drivers/crypto/cavium/cpt/cptpf_main.c:18:0: drivers/crypto/cavium/cpt/cptpf.h:57:20: error: array type has incomplete element type 'struct msix_entry' struct msix_entry msix_entries[CPT_PF_MSIX_VECTORS]; ^~~~ drivers/crypto/cavium/cpt/cptpf_main.c: In function 'cpt_enable_msix': drivers/crypto/cavium/cpt/cptpf_main.c:344:8: error: implicit declaration of function 'pci_enable_msix';did you mean 'cpt_enable_msix'? [-Werror=implicit-function-declaration] On the other hand, it doesn't seem to have any build dependency on ARCH_THUNDER, so let's allow compile-testing to catch this kind of problem more easily. The 64-bit dependency is needed for the use of readq/writeq. Signed-off-by: Arnd Bergmann --- drivers/crypto/cavium/cpt/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/crypto/cavium/cpt/Kconfig b/drivers/crypto/cavium/cpt/Kconfig index 247f1cbbefc1..cbd51b1aa046 100644 --- a/drivers/crypto/cavium/cpt/Kconfig +++ b/drivers/crypto/cavium/cpt/Kconfig @@ -7,7 +7,8 @@ config CRYPTO_DEV_CPT config CAVIUM_CPT tristate "Cavium Cryptographic Accelerator driver" - depends on ARCH_THUNDER + depends on ARCH_THUNDER || COMPILE_TEST + depends on PCI_MSI && 64BIT Perhaps we should select PCI and PCI_MSI instead. These systems cannot function without those. select CRYPTO_DEV_CPT help Support for Cavium CPT block found in octeon-tx series of
Re: [PATCH 3/6] x86/cpu: proc - remove "wp" status line in cpuinfo
On Tue, Feb 14, 2017 at 05:47:08PM +0100, Mathias Krause wrote: > That's the reason I haven't folded this change into patch 2. I had > similar doubts but it's not documented in Documentation/ and kinda > useless to test anyway -- what would a "wp : no" tell one? Not that - the missing wp-line in there might puzzle some idiotic userspace script. And then it is our fault all over again that we broke the world. But I'm just playing the devil's advocate here. Realistically, it is very likely that no one would care. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH] staging: vt6656: Alignment match open parenthesis
On Mon, Feb 13, 2017 at 04:01:13AM +0530, Arushi Singhal wrote: > Fix checkpatch issues: "CHECK: Alignment should match open parenthesis" > > Signed-off-by: Arushi Singhal > --- > drivers/staging/vt6656/firmware.c | 34 +- > drivers/staging/vt6656/key.h | 2 +- > drivers/staging/vt6656/rf.c | 12 ++-- > drivers/staging/vt6656/usbpipe.c | 12 ++-- > drivers/staging/vt6656/wcmd.c | 2 +- > 5 files changed, 31 insertions(+), 31 deletions(-) You sent two different patches that do different things, yet you have the same exact subject line. Please fix up and resend both of them with unique subjects. thanks, greg k-h
Re: [PATCH] Staging: wlan-ng: Fixed code style issue:
On Mon, Feb 13, 2017 at 09:20:05AM -0500, Bo YU wrote: > Statements should start on a tabstop > > Signed-off-by: YU Bo > --- > drivers/staging/wlan-ng/prism2mgmt.c |3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) Patch does not apply to my tree :(
Re: [PATCHv6 1/3] staging: wlan-ng: move logical continuations at the end of line
On Mon, Feb 13, 2017 at 09:25:49AM -0500, Maksymilian Piechota wrote:
> move logical continuations at the end of line
>
> Signed-off-by: Maksymilian Piechota
> ---
> drivers/staging/wlan-ng/prism2mgmt.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/wlan-ng/prism2mgmt.c
> b/drivers/staging/wlan-ng/prism2mgmt.c
> index 16fb2d3..64a9ebc 100644
> --- a/drivers/staging/wlan-ng/prism2mgmt.c
> +++ b/drivers/staging/wlan-ng/prism2mgmt.c
> @@ -1308,9 +1308,8 @@ int prism2mgmt_wlansniff(struct wlandevice *wlandev,
> void *msgp)
> hw->sniffhdr = 0;
> wlandev->netdev->type = ARPHRD_IEEE80211_PRISM;
> } else
> - if ((msg->wlanheader.status ==
> - P80211ENUM_msgitem_status_data_ok)
> - && (msg->wlanheader.data == P80211ENUM_truth_true)) {
> + if ((msg->wlanheader.status ==
> P80211ENUM_msgitem_status_data_ok) &&
> + (msg->wlanheader.data == P80211ENUM_truth_true)) {
> hw->sniffhdr = 1;
> wlandev->netdev->type = ARPHRD_IEEE80211_PRISM;
> } else {
This patch has checkpatch.pl errors. Please always use checkpatch so
you don't get emails from grumpy maintainers telling you to fix the
checkpatch errors :)
Please fix up and resend the whole series.
thanks,
greg k-h
Re: [PATCH]staging: fbtft: Fix sparse warnings about endianness
On Tue, Feb 14, 2017 at 04:53:10PM +0800, maomao xu wrote: > Fixed sparse warnings about endianness. E.g.: > > warning: incorrect type in assignment (different base types) Why are these lines indented? > Signed-off-by: maomao xu > > diff --git a/drivers/staging/fbtft/fbtft-io.c > b/drivers/staging/fbtft/fbtft-io.c > index d868405..ffb9a3b 100644 > --- a/drivers/staging/fbtft/fbtft-io.c > +++ b/drivers/staging/fbtft/fbtft-io.c > @@ -71,7 +71,7 @@ int fbtft_write_spi_emulate_9(struct fbtft_par *par, void > *buf, size_t len) > src++; > } > tmp |= ((*src & 0x0100) ? 1 : 0); > - *(u64 *)dst = cpu_to_be64(tmp); > + *(__be64 *)dst = cpu_to_be64(tmp); Really? That seems very odd. I need a maintainer's ack for this before I can take it... thanks, greg k-h
Re: [PATCH 1/2] perf/x86/intel/pt: Fail event scheduling on conflict with VMX
Peter Zijlstra writes: > On Tue, Feb 14, 2017 at 06:17:30PM +0200, Alexander Shishkin wrote: >> This is called by pmu::add(), which checks hw.state afterwards and if it >> finds HES_STOPPED, it returns an error, which event_sched_in() captures >> and keeps the event in INACTIVE state. Should I add a comment about it? > > Egads... so what if ->add() succeeds but we then hit this on > ->stop()/->start() due to throttle or period adjust? It will hang there with hw.state==PERF_HES_STOPPED till the next sched_out. But that will be the case anyway if VMXON kicks in while PT is running. > Now I suppose PT will never normally hit either of those, but you can do > IOC_PERIOD on it, just for giggles. True. Should we worry? > Yes, this very much needs a comment... Also, should not this then live > in ->add() in the first place? The output_stop() stuff in the mmap_close path relies on perf_aux_output_end() being in ->stop(), let me think if there's more. Regards, -- Alex
Status February 14, 2017
- Finally some progress on sparc shared context efforts. Turns out that the mondo timeout issue I spent a large amount of time chasing was a HW/FW issue with the non-production system I was using in the lab. Sigh! Some good things did come from this: - I learned new debug techniques - I fixed up the reference counting code because in it's preliminary state it should not have caused any issues, but I was not sure. I have now been able to pass some initial stress/stability testing with a UEK4 jenkins based kernel. Do note that this kernel also contains changes by Nitin Guputa and Bob Picco to change the way huge pages are handled. These are the changes which are going upstream and will eventually replace the scheme developed for UEK2 that was forward ported to UEK4. - A new issue with huge page reservations was brought up. A task's memory policy is not taken into account when reservations are made. However, when pages are allocated to satisfy faults the policy is used. Therefore, it is possible that a reservation will succeed and an allocation at fault time will fail. To be honest, I do not know the original intention of this code. It is not well documented and the original authors are no longer active in this area. I have become the default owner/maintainer of this stuff because nobody else wants to touch it. :) So, I need to at least come up with proposal on how to proceed. - After hugetlbfs support was added to userfaultfd, the qemu project took notece. They are using userfaultfd for postcopy live migration. They discovered the performance advantage of using huge pages. However, when adding hugetlbfs support I added minimal functionality as this originally came from an Oracle DM request. As a result, the current code only does copies for private mappings. Note that the DB does not do copies at all. The code really should support shared mappings as well. Actually, some (Andrea) may consider this a bug. This should not be too complicated, but the userfault code seems to present lots of 'corner cases'. Plans - Hand off a build of sparc shared context kernel for preliminary testing. Since this is early prototype code, I hope expectations are not too high. - Make changes necessary for hugetlbfs userfaultfd copy to shared mappings. - Come up with proposal/ideas for huge page reservation and memory policy interaction. Out of Office - US Holiday, February 20 - Vacation, March 13 - 17 - LSF/MM, March 20 - 22 -- Mike Kravetz
Re: [PATCH v2 01/25] Staging: rtl8192u: r819xU_phy.c - style fix
On Mon, Feb 13, 2017 at 06:39:06PM +1300, Derek Robson wrote: > Fixed style of block comments > Found using checkpatch > > Signed-off-by: Derek Robson > --- > drivers/staging/rtl8192u/r819xU_phy.c | 41 > +++ > 1 file changed, 27 insertions(+), 14 deletions(-) This patch is already in my tree. Please rebase your series against my latest tree and resend only the ones that I need to apply. thanks, greg k-h
Re: [PATCH v3 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP
On 02/13/2017 12:03 PM, Paul Durrant wrote:
> Recently a new dm_op[1] hypercall was added to Xen to provide a mechanism
> for restricting device emulators (such as QEMU) to a limited set of
> hypervisor operations, and being able to audit those operations in the
> kernel of the domain in which they run.
>
> This patch adds IOCTL_PRIVCMD_DM_OP as gateway for __HYPERVISOR_dm_op.
>
> NOTE: There is no requirement for user-space code to bounce data through
> locked memory buffers (as with IOCTL_PRIVCMD_HYPERCALL) since
> privcmd has enough information to lock the original buffers
> directly.
>
> [1] http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=524a98c2
>
> Signed-off-by: Paul Durrant
Stefano,
Are you OK with ARM changes?
-boris
> ---
> Cc: Boris Ostrovsky
> Cc: Juergen Gross
>
> v3:
> - Add module parameters for max number of dm_op buffers and max buffer
> size
> - Fix arm build
> - Fix commit comment to reflect re-worked patch
>
> v2:
> - Lock the user pages rather than bouncing through kernel memory
> ---
> arch/arm/xen/enlighten.c | 1 +
> arch/arm/xen/hypercall.S | 1 +
> arch/arm64/xen/hypercall.S | 1 +
> arch/x86/include/asm/xen/hypercall.h | 7 ++
> drivers/xen/privcmd.c| 139
> +++
> include/uapi/xen/privcmd.h | 13
> include/xen/arm/hypercall.h | 1 +
> include/xen/interface/hvm/dm_op.h| 32
> include/xen/interface/xen.h | 1 +
> 9 files changed, 196 insertions(+)
> create mode 100644 include/xen/interface/hvm/dm_op.h
>
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 11d9f28..81e3217 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -457,4 +457,5 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
> EXPORT_SYMBOL_GPL(HYPERVISOR_platform_op);
> EXPORT_SYMBOL_GPL(HYPERVISOR_multicall);
> EXPORT_SYMBOL_GPL(HYPERVISOR_vm_assist);
> +EXPORT_SYMBOL_GPL(HYPERVISOR_dm_op);
> EXPORT_SYMBOL_GPL(privcmd_call);
> diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
> index a648dfc..b0b80c0 100644
> --- a/arch/arm/xen/hypercall.S
> +++ b/arch/arm/xen/hypercall.S
> @@ -92,6 +92,7 @@ HYPERCALL1(tmem_op);
> HYPERCALL1(platform_op_raw);
> HYPERCALL2(multicall);
> HYPERCALL2(vm_assist);
> +HYPERCALL3(dm_op);
>
> ENTRY(privcmd_call)
> stmdb sp!, {r4}
> diff --git a/arch/arm64/xen/hypercall.S b/arch/arm64/xen/hypercall.S
> index 947830a..401ceb7 100644
> --- a/arch/arm64/xen/hypercall.S
> +++ b/arch/arm64/xen/hypercall.S
> @@ -84,6 +84,7 @@ HYPERCALL1(tmem_op);
> HYPERCALL1(platform_op_raw);
> HYPERCALL2(multicall);
> HYPERCALL2(vm_assist);
> +HYPERCALL3(dm_op);
>
> ENTRY(privcmd_call)
> mov x16, x0
> diff --git a/arch/x86/include/asm/xen/hypercall.h
> b/arch/x86/include/asm/xen/hypercall.h
> index a12a047..f6d20f6 100644
> --- a/arch/x86/include/asm/xen/hypercall.h
> +++ b/arch/x86/include/asm/xen/hypercall.h
> @@ -472,6 +472,13 @@ HYPERVISOR_xenpmu_op(unsigned int op, void *arg)
> return _hypercall2(int, xenpmu_op, op, arg);
> }
>
> +static inline int
> +HYPERVISOR_dm_op(
> + domid_t dom, unsigned int nr_bufs, void *bufs)
> +{
> + return _hypercall3(int, dm_op, dom, nr_bufs, bufs);
> +}
> +
> static inline void
> MULTI_fpu_taskswitch(struct multicall_entry *mcl, int set)
> {
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index 5e5c7ae..a33f17e 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -22,6 +22,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -32,6 +33,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -43,6 +45,17 @@ MODULE_LICENSE("GPL");
>
> #define PRIV_VMA_LOCKED ((void *)1)
>
> +unsigned int privcmd_dm_op_max_num = 16;
> +module_param_named(dm_op_max_nr_bufs, privcmd_dm_op_max_num, uint, 0644);
> +MODULE_PARM_DESC(dm_op_max_nr_bufs,
> + "Maximum number of buffers per dm_op hypercall");
> +
> +unsigned int privcmd_dm_op_buf_max_size = XEN_PAGE_SIZE;
> +module_param_named(dm_op_buf_max_size, privcmd_dm_op_buf_max_size, uint,
> +0644);
> +MODULE_PARM_DESC(dm_op_buf_max_size,
> + "Maximum size of a dm_op hypercall buffer");
> +
> static int privcmd_vma_range_is_mapped(
> struct vm_area_struct *vma,
> unsigned long addr,
> @@ -548,6 +561,128 @@ static long privcmd_ioctl_mmap_batch(void __user
> *udata, int version)
> goto out;
> }
>
> +static int lock_pages(
> + struct privcmd_dm_op_buf kbufs[], unsigned int num,
> + struct page *pages[], unsigned int nr_pages)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < num; i++) {
> + unsigned int requested;
> + int pinned;
> +
> + requested = DIV_ROUND_UP(
> + offset_in_page(kbufs[i].uptr) + kbufs[
Re: [PATCH 01/15] staging: rtl8192u: fixing white space issue
On Tue, Feb 14, 2017 at 02:33:34AM +0530, simran singhal wrote: > Fix the following checkpatch.pl error and warnings: > WARNING: please, no space before tabs > > Signed-off-by: simran singhal > --- > drivers/staging/rtl8192u/ieee80211/rtl819x_TS.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) You said this is a 15 patch patch series, yet I only received 9 of them. Please fix and resend all of them, properly threaded (hint, git send-email will do this for you automatically, or you can do it by hand with a good email client like mutt), so that I know I get them all and can review and apply them. thanks, greg k-h
Re: [PATCH V2 2/2] sched/deadline: Throttle a constrained deadline task activated after the deadline
On 02/14/2017 04:54 PM, Tommaso Cucinotta wrote: > On 13/02/2017 20:05, Daniel Bristot de Oliveira wrote: >> To avoid this problem, in the activation of a constrained deadline >> task after the deadline but before the next period, throttle the >> task and set the replenishing timer to the begin of the next period, >> unless it is boosted. > > my only comment is that, by throttling on (dl < wakeuptime < period), we > force the app to sync its activation time with the kernel, and the cbs > doesn't self-sync anymore with the app own periodicity, which is what > normally happens with dl=period. With dl=period, we loose the cbs > self-sync and we force the app to sync with the kernel periodic timer > only if we use explicitly yield(), but now this becomes also implicit > just if we set dl >> attr.sched_policy = SCHED_DEADLINE; >> attr.sched_runtime = 2 * 1000 * 1000;/* 2 ms */ >> attr.sched_deadline = 2 * 1000 * 1000;/* 2 ms */ >> attr.sched_period = 2 * 1000 * 1000 * 1000;/* 2 s */ > ... >> On my box, this reproducer uses almost 50% of the CPU time, which is >> obviously wrong for a task with 2/2000 reservation. > > just a note here: in this example of runtime=deadline=2ms, shall we rely > on a utilization-based test, then we should assume the task is taking 100%. > More precise tests for EDF with deadline 1998ms/2000ms free space, instead. Yeah, it is taking 100% for runtime/deadline. But the admission is runtime/period, so it will pass. The idea of runtime=deadline is to avoid the task being throttled. If the task is throttle we would not be able to demonstrate this bug. Anyway, we can set runtime = (0.95 * deadline), it will also reproduce the problem, as long as the task is put to sleep before being throttled. Thanks! -- Daniel
Re: [PATCH] usb: musb: add code comment for clarification
On Fri, Feb 10, 2017 at 06:57:41PM -0600, Gustavo A. R. Silva wrote:
> Add code comment to make it clear that the fall-through is intentional.
> Read the link for more details: https://lkml.org/lkml/2017/2/9/292
>
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/usb/musb/musb_core.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
> index 892088f..1aec986 100644
> --- a/drivers/usb/musb/musb_core.c
> +++ b/drivers/usb/musb/musb_core.c
> @@ -1869,6 +1869,7 @@ static void musb_pm_runtime_check_session(struct musb
> *musb)
>
> return;
> }
> + /* fall through */
> case MUSB_QUIRK_A_DISCONNECT_19:
> if (musb->quirk_retries--) {
> musb_dbg(musb,
The tabs are all gone from this patch, and it's line-wrapped, making it
impossible to be applied :(
Can you please fix this and resend?
thanks,
greg k-h
Re: v4.9, 4.4-final: 28 bioset threads on small notebook, 36 threads on cellphone
On Thu, Feb 09 2017 at 4:25pm -0500, Kent Overstreet wrote: > On Wed, Feb 08, 2017 at 11:34:07AM -0500, Mike Snitzer wrote: > > On Tue, Feb 07 2017 at 11:58pm -0500, > > Kent Overstreet wrote: > > > > > On Tue, Feb 07, 2017 at 09:39:11PM +0100, Pavel Machek wrote: > > > > On Mon 2017-02-06 17:49:06, Kent Overstreet wrote: > > > > > On Mon, Feb 06, 2017 at 04:47:24PM -0900, Kent Overstreet wrote: > > > > > > On Mon, Feb 06, 2017 at 01:53:09PM +0100, Pavel Machek wrote: > > > > > > > Still there on v4.9, 36 threads on nokia n900 cellphone. > > > > > > > > > > > > > > So.. what needs to be done there? > > > > > > > > > > > But, I just got an idea for how to handle this that might be > > > > > > halfway sane, maybe > > > > > > I'll try and come up with a patch... > > > > > > > > > > Ok, here's such a patch, only lightly tested: > > > > > > > > I guess it would be nice for me to test it... but what it is against? > > > > I tried after v4.10-rc5 and linux-next, but got rejects in both cases. > > > > > > Sorry, I forgot I had a few other patches in my branch that touch > > > mempool/biosets code. > > > > > > Also, after thinking about it more and looking at the relevant code, I'm > > > pretty > > > sure we don't need rescuer threads for block devices that just split bios > > > - i.e. > > > most of them, so I changed my patch to do that. > > > > > > Tested it by ripping out the current->bio_list checks/workarounds from the > > > bcache code, appears to work: > > > > Feedback on this patch below, but first: > > > > There are deeper issues with the current->bio_list and rescue workqueues > > than thread counts. > > > > I cannot help but feel like you (and Jens) are repeatedly ignoring the > > issue that has been raised numerous times, most recently: > > https://www.redhat.com/archives/dm-devel/2017-February/msg00059.html > > > > FYI, this test (albeit ugly) can be used to check if the dm-snapshot > > deadlock is fixed: > > https://www.redhat.com/archives/dm-devel/2017-January/msg00064.html > > > > This situation is the unfortunate pathological worst case for what > > happens when changes are merged and nobody wants to own fixing the > > unforseen implications/regressions. Like everyone else in a position > > of Linux maintenance I've tried to stay away from owning the > > responsibility of a fix -- it isn't working. Ok, I'll stop bitching > > now.. I do bear responsibility for not digging in myself. We're all > > busy and this issue is "hard". > > Mike, it's not my job to debug DM code for you or sift through your bug > reports. > I don't read dm-devel, and I don't know why you think I that's my job. > > If there's something you think the block layer should be doing differently, > post > patches - or at the very least, explain what you'd like to be done, with > words. > Don't get pissy because I'm not sifting through your bug reports. > > Hell, I'm not getting paid to work on kernel code at all right now, and you > trying to rope me into fixing device mapper sure makes me want to work on the > block layer more. > > DM developers have a long history of working siloed off from the rest of the > block layer, building up their own crazy infrastructure (remember the old bio > splitting code?) and going to extreme lengths to avoid having to work on or > improve the core block layer infrastructure. It's ridiculous. That is bullshit. I try to help block core where/when I can (did so with discards and limits stacking, other fixes here and there). Your take on what DM code is and how it evolved is way off base. But that is to be expected from you. Not going to waste time laboring over correcting you. > You know what would be nice? What'd really make my day is if just once I got a > thank you or a bit of appreciation from DM developers for the bvec > iterators/bio > splitting work I did that cleaned up a _lot_ of crazy hairy messes. Or getting > rid of merge_bvec_fn, or trying to come up with a better solution for > deadlocks > due to running under generic_make_request() now. I do appreciate the immutable biovec work you did. Helped speed up bio cloning quite nicely. But you've always been hostile to DM. You'll fabricate any excuse to never touch or care about it. Repeatedly noted. But this is a block core bug/regression. Not DM. If you think I'm going to thank you for blindly breaking shit, and refusing to care when you're made aware of it, then you're out of your mind. Save your predictably hostile response. It'll get marked as spam anyway.
Re: [PATCH v2 0/3] x86/vdso: Add Hyper-V TSC page clocksource support
On Tue, Feb 14, 2017 at 7:50 AM, Vitaly Kuznetsov wrote: > Thomas Gleixner writes: > >> On Tue, 14 Feb 2017, Vitaly Kuznetsov wrote: >> >>> Hi, >>> >>> while we're still waiting for a definitive ACK from Microsoft that the >>> algorithm is good for SMP case (as we can't prevent the code in vdso from >>> migrating between CPUs) I'd like to send v2 with some modifications to keep >>> the discussion going. >> >> Migration is irrelevant. The TSC page is guest global so updates will >> happen on some (random) host CPU and therefor you need the usual barriers >> like we have them in our seqcounts unless an access to the sequence will >> trap into the host, which would defeat the whole purpose of the TSC page. >> > > KY Srinivasan writes: > >> I checked with the folks on the Hyper-V side and they have confirmed that we >> need to >> add memory barriers in the guest code to ensure the various reads from the >> TSC page are >> correctly ordered - especially, the initial read of the sequence counter >> must have acquire >> semantics. We should ensure that other reads from the TSC page are completed >> before the >> second read of the sequence counter. I am working with the Windows team to >> correctly >> reflect this algorithm in the Hyper-V specification. > > > Thank you, > > do I get it right that combining the above I only need to replace > virt_rmb() barriers with plain rmb() to get 'lfence' in hv_read_tsc_page > (PATCH 2)? As members of struct ms_hyperv_tsc_page are volatile we don't > need READ_ONCE(), compilers are not allowed to merge accesses. The > resulting code looks good to me: No, on multiple counts, unfortunately. 1. LFENCE is basically useless except for IO and for (Intel only) rdtsc_ordered(). AFAIK there is literally no scenario under which LFENCE is useful for access to normal memory. 2. The problem here has little to do with barriers. You're doing: read seq; read var1; read var2; read tsc; read seq again; If the hypervisor updates things between reading var1 and var2 or between reading var2 and tsc, you aren't guaranteed to notice unless something fancy is going on regardless of barriers. Similarly, if the hypervisor starts updating, then you start and finish the whole function, and then the hypervisor finishes, what guarantees you notice? This really needs a spec from the hypervisor folks as to what's going on. KVM does this horrible thing in which it sometimes freezes all vCPUs when updating, for better or for worse. Mostly for worse. If MS does the same thing, they should document it. 3. You need rdtsc_ordered(). Plain RDTSC is not ordered wrt other memory access, and it can observably screw up as a result. Also, Linux tries to avoid volatile variables, so please use READ_ONCE(). > > (gdb) disassemble read_hv_clock_tsc > Dump of assembler code for function read_hv_clock_tsc: >0x8102ca60 <+0>: callq 0x816c7500 <__fentry__> >0x8102ca65 <+5>: mov0xf67974(%rip),%rcx# > 0x81f943e0 >0x8102ca6c <+12>:jmp0x8102ca87 > >0x8102ca6e <+14>:lfence >0x8102ca71 <+17>:mov0x8(%rcx),%r9 >0x8102ca75 <+21>:mov0x10(%rcx),%r8 >0x8102ca79 <+25>:nop >0x8102ca7a <+26>:nop >0x8102ca7b <+27>:nop >0x8102ca7c <+28>:rdtsc >0x8102ca7e <+30>:lfence >0x8102ca81 <+33>:mov(%rcx),%edi >0x8102ca83 <+35>:cmp%edi,%esi >0x8102ca85 <+37>:je 0x8102caa3 > >0x8102ca87 <+39>:mov(%rcx),%esi >0x8102ca89 <+41>:test %esi,%esi >0x8102ca8b <+43>:jne0x8102ca6e > >0x8102ca8d <+45>:push %rbp >0x8102ca8e <+46>:mov$0x4020,%edi >0x8102ca93 <+51>:mov%rsp,%rbp >0x8102ca96 <+54>:and$0xfff0,%rsp >0x8102ca9a <+58>:callq *0x81c36330 >0x8102caa1 <+65>:leaveq >0x8102caa2 <+66>:retq >0x8102caa3 <+67>:shl$0x20,%rdx >0x8102caa7 <+71>:or %rdx,%rax >0x8102caaa <+74>:mul%r9 >0x8102caad <+77>:mov%rdx,%rax >0x8102cab0 <+80>:add%r8,%rax >0x8102cab3 <+83>:cmp$0x,%rax >0x8102cab7 <+87>:je 0x8102ca8d > >0x8102cab9 <+89>:repz retq > End of assembler dump. > > -- > Vitaly -- Andy Lutomirski AMA Capital Management, LLC
Re: [PATCH] oom_reaper: switch to struct list_head for reap queue
On 02/15, Aleksa Sarai wrote: > > >This is an extra pointer to task_struct and more lines of code to > >accomplish the same thing. Why would we want to do that? > > I don't think it's more "actual" lines of code (I think the wrapping is > inflating the line number count), I too think it doesn't make sense to blow task_struct and the generated code. And to me this patch doesn't make the source code more clean. > but switching it means that it's more in > line with other queues in the kernel (it took me a bit to figure out what > was going on with oom_reaper_list beforehand). perhaps you can turn oom_reaper_list into llist_head then. This will also allow to remove oom_reaper_lock. Not sure this makes sense too. Oleg.
Re: [PATCH v4 1/3] x86: Introduce a new constant KERNEL_MAPPING_SIZE
On Thu, Feb 02, 2017 at 08:54:35PM +0800, Baoquan He wrote: > In x86, KERNEL_IMAGE_SIZE is used to limit the size of kernel image in > running space, but also represents the size of kernel image mapping area. > This looks good when kernel virtual address is invariable inside 512M > area and kernel image size is not bigger than 512M. > > Along with the adding of kaslr, in x86_64 the area of kernel mapping is > extended up another 512M. It becomes improper to let KERNEL_IMAGE_SIZE > alone still play two roles now. > > So introduce a new constant KERNEL_MAPPING_SIZE to represent the size of > kernel mapping area. Let KERNEL_IMAGE_SIZE be as its name is saying. In > x86_32 though kernel image size is the same as kernel mapping size, for > generic handling in kaslr.c KERNEL_MAPPING_SIZE is also introduced. > > In this patch, just add KERNEL_MAPPING_SIZE and replace KERNEL_IMAGE_SIZE > with it in the relevant places. No functional change. > > Signed-off-by: Baoquan He > --- > arch/x86/boot/compressed/kaslr.c| 10 +- > arch/x86/include/asm/page_32_types.h| 6 ++ > arch/x86/include/asm/page_64_types.h| 12 +--- > arch/x86/include/asm/pgtable_64_types.h | 2 +- > arch/x86/kernel/head64.c| 4 ++-- > arch/x86/kernel/head_64.S | 2 +- > arch/x86/kernel/machine_kexec_64.c | 2 +- > arch/x86/mm/init_64.c | 2 +- > arch/x86/mm/physaddr.c | 6 +++--- > 9 files changed, 29 insertions(+), 17 deletions(-) ... > diff --git a/arch/x86/include/asm/page_64_types.h > b/arch/x86/include/asm/page_64_types.h > index 9215e05..24c9098 100644 > --- a/arch/x86/include/asm/page_64_types.h > +++ b/arch/x86/include/asm/page_64_types.h > @@ -50,16 +50,22 @@ > #define __VIRTUAL_MASK_SHIFT 47 > > /* > - * Kernel image size is limited to 1GiB due to the fixmap living in the > + * Kernel image size is limited to 512 MB. The kernel code+data+bss This is not what it said there before. With your change you have: - 0 . . . - 512 - KERNEL_IMAGE_SIZE . . . - 1024 - KERNEL_MAPPING_SIZE and KERNEL_IMAGE_SIZE is not limited to 512Mb but it is "Use 512Mib by default". And we do enforce that in various places like in the linker script assertions but there's some headroom open in the upper 512Mib if needed. KERNEL_MAPPING_SIZE OTOH is the one limited to 1G due to the fixmap L2 PGT... > + * must not be bigger than that. > + */ > +#define KERNEL_IMAGE_SIZE(512 * 1024 * 1024) > + > +/* > + * Kernel mapping size is limited to 1GiB due to the fixmap living in the > * next 1GiB (see level2_kernel_pgt in arch/x86/kernel/head_64.S). Use > * 512MiB by default, leaving 1.5GiB for modules once the page tables > * are fully set up. If kernel ASLR is configured, it can extend the > * kernel page table mapping, reducing the size of the modules area. > */ > #if defined(CONFIG_RANDOMIZE_BASE) > -#define KERNEL_IMAGE_SIZE(1024 * 1024 * 1024) > +#define KERNEL_MAPPING_SIZE (1024 * 1024 * 1024) > #else > -#define KERNEL_IMAGE_SIZE(512 * 1024 * 1024) > +#define KERNEL_MAPPING_SIZE (512 * 1024 * 1024) > #endif ... and since you're adding that define now, fixup the comments in this patch too, to explain what they mean. Also, I'd like for the text to say that both defines are dependent in the sense that IMAGE_SIZE <= MAPPING_SIZE so that people know what's going on and which is which. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --
Re: [1/3] ath10k: remove ath10k_vif_to_arvif()
Amadeusz Sławiński wrote: > it adds unnecessary level of indirection, while we just access structure > field > > Signed-off-by: Amadeusz Sławiński 3 patches applied to ath-next branch of ath.git, thanks. 56ac13bfc703 ath10k: remove ath10k_vif_to_arvif() 182f1e5a626e ath10k: use size_t for len variables 6d2191135637 ath10k: fix comment -- https://patchwork.kernel.org/patch/9551559/ Documentation about submitting wireless patches and checking status from patchwork: https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v3 5/9] fput: Don't reinvent the wheel but use existing llist API
On 02/14, Byungchul Park wrote:
>
> Although llist provides proper APIs, they are not used. Make them used.
Reviewed-by: Oleg Nesterov
> Signed-off-by: Byungchul Park
> ---
> fs/file_table.c | 12 +---
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/fs/file_table.c b/fs/file_table.c
> index 6d982b5..3209da2 100644
> --- a/fs/file_table.c
> +++ b/fs/file_table.c
> @@ -231,12 +231,10 @@ static void __fput(struct file *file)
> static void delayed_fput(struct work_struct *unused)
> {
> struct llist_node *node = llist_del_all(&delayed_fput_list);
> - struct llist_node *next;
> + struct file *f, *t;
>
> - for (; node; node = next) {
> - next = llist_next(node);
> - __fput(llist_entry(node, struct file, f_u.fu_llist));
> - }
> + llist_for_each_entry_safe(f, t, node, f_u.fu_llist)
> + __fput(f);
> }
>
> static void fput(struct callback_head *work)
> @@ -310,7 +308,7 @@ void put_filp(struct file *file)
> }
>
> void __init files_init(void)
> -{
> +{
> filp_cachep = kmem_cache_create("filp", sizeof(struct file), 0,
> SLAB_HWCACHE_ALIGN | SLAB_PANIC, NULL);
> percpu_counter_init(&nr_files, 0, GFP_KERNEL);
> @@ -329,4 +327,4 @@ void __init files_maxfiles_init(void)
> n = ((totalram_pages - memreserve) * (PAGE_SIZE / 1024)) / 10;
>
> files_stat.max_files = max_t(unsigned long, n, NR_FILE);
> -}
> +}
> --
> 1.9.1
>
[PATCH 1/1] crypto: brcm - Avoid double free in ahash_finup()
In Broadcom SPU driver, in case where incremental hash
is done in software in ahash_finup(), tmpbuf was freed
twice.
Reported-by: Dan Carpenter
Signed-off-by: Rob Rice
---
drivers/crypto/bcm/cipher.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/crypto/bcm/cipher.c b/drivers/crypto/bcm/cipher.c
index a654a01..cc0d5b9 100644
--- a/drivers/crypto/bcm/cipher.c
+++ b/drivers/crypto/bcm/cipher.c
@@ -2331,7 +2331,6 @@ static int ahash_finup(struct ahash_request *req)
/* Call synchronous update */
ret = crypto_shash_finup(ctx->shash, tmpbuf, req->nbytes,
req->result);
- kfree(tmpbuf);
} else {
/* Otherwise call the internal function which uses SPU hw */
return __ahash_finup(req);
--
2.1.0
Re: [PATCH 01/15] staging: rtl8192u: fixing white space issue
While resending them ...do I have to mention v2. On Tue, Feb 14, 2017 at 10:54 PM, Greg KH wrote: > On Tue, Feb 14, 2017 at 02:33:34AM +0530, simran singhal wrote: >> Fix the following checkpatch.pl error and warnings: >> WARNING: please, no space before tabs >> >> Signed-off-by: simran singhal >> --- >> drivers/staging/rtl8192u/ieee80211/rtl819x_TS.h | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) > > You said this is a 15 patch patch series, yet I only received 9 of them. > > Please fix and resend all of them, properly threaded (hint, git > send-email will do this for you automatically, or you can do it by hand > with a good email client like mutt), so that I know I get them all and > can review and apply them. > > thanks, > > greg k-h
Re: [PATCH 2/2] perf/x86/intel/pt: Fail event creation if VMX operation is on
Em Tue, Feb 14, 2017 at 03:24:16PM +0200, Alexander Shishkin escreveu:
> On systems where PT does not coexist with VMX, users get confused when
> PT turns up with no data because they forgot they're running a kvm
> session at the same time.
>
> This patch adds a preemptive check for any active VMX operations that
> will fail event creation. This does not provide any guarantees or
> protection against racing with a kvm starting in parallel, but is
> intended to serve as a hint for the user. If VMXON happens after an
> event had been created, the event will still produce an empty trace.
>
> Signed-off-by: Alexander Shishkin
> Reported-by: Andi Kleen
Yeah, I saw that as well, and Andi told me about this limitation, so,
for quite a while now, everytime I need to test PT on the only machine I
have with it, I have to stop my kvm sessions :-\
Thanks for working on this!
- Arnaldo
> ---
> arch/x86/events/intel/pt.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/x86/events/intel/pt.c b/arch/x86/events/intel/pt.c
> index 9372fa4549..b1490a879c 100644
> --- a/arch/x86/events/intel/pt.c
> +++ b/arch/x86/events/intel/pt.c
> @@ -1444,6 +1444,20 @@ static void pt_event_destroy(struct perf_event *event)
>
> static int pt_event_init(struct perf_event *event)
> {
> + int cpu, vmx_on = 0;
> +
> + get_online_cpus();
> + for_each_online_cpu(cpu) {
> + struct pt *pt = per_cpu_ptr(&pt_ctx, cpu);
> +
> + if (READ_ONCE(pt->vmx_on))
> + vmx_on++;
> + }
> + put_online_cpus();
> +
> + if (vmx_on)
> + return -EBUSY;
> +
> if (event->attr.type != pt_pmu.pmu.type)
> return -ENOENT;
>
> --
> 2.11.0
Re: [PATCH 1/2] dt-bindings: arm-ccn: Add bindings info for CCN-502 compatible string
On Fri, Feb 10, 2017 at 12:42:47PM -0800, Velibor Markovski wrote: > Add CCN-502 to the list of supported devices by ARM CCN PMU driver. > > Signed-off-by: Velibor Markovski Acked-by: Mark Rutland I assume Pawel will take this along with the driver patch. Thanks, Mark. > --- > Documentation/devicetree/bindings/arm/ccn.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/arm/ccn.txt > b/Documentation/devicetree/bindings/arm/ccn.txt > index b100d38..2980145 100644 > --- a/Documentation/devicetree/bindings/arm/ccn.txt > +++ b/Documentation/devicetree/bindings/arm/ccn.txt > @@ -3,6 +3,7 @@ > Required properties: > > - compatible: (standard compatible string) should be one of: > + "arm,ccn-502" > "arm,ccn-504" > "arm,ccn-508" > > -- > 1.9.1 >
[PATCH v3 0/6] genirq/gpio: Add driver for ThunderX and OCTEON-TX SoCs
Per the Subject: Add driver for ThunderX and OCTEON-TX SoCs
This GPIO hardware looks like a PCIe device, with the interrupt signal
from each GPIO line being routed to a dedicated MSI-X. This interrupt
routing requires that we add some custom processing to the beginning
of the MSI-X irqdomain hierarchy.
Changes from v2:
- in 4/6: Added Rob Harring's Acked-by
- Added three patches to genirq/irqdomain to support interrupt code
in the driver.
- Rewrite irq code in driver to use irqdomain hierarchy.
- Other naming and style changes as recommended by Linus Walleij.
Changes from v1:
- in 1/3: Addressed Rob Harring's comments.
- in 2/3: Trivial cleanups found in internal review + add some
comments.
David Daney (6):
genirq: Export more irq_chip_*_parent() functions.
genirq: Add handle_fasteoi_{level,edge}_irq flow handlers.
irqdomain: Add irq_domain_{push,pop}_irq() functions.
dt-bindings: gpio: Add binding documentation for gpio-thunderx
gpio: Add gpio driver support for ThunderX and OCTEON-TX
MAINTAINERS: Add entry for THUNDERX GPIO Driver.
.../devicetree/bindings/gpio/gpio-thunderx.txt | 27 ++
MAINTAINERS| 5 +
drivers/gpio/Kconfig | 7 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-thunderx.c | 490 +
include/linux/irq.h| 2 +
include/linux/irqdomain.h | 3 +
kernel/irq/chip.c | 105 +
kernel/irq/irqdomain.c | 137 ++
9 files changed, 777 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-thunderx.txt
create mode 100644 drivers/gpio/gpio-thunderx.c
--
1.8.3.1
[PATCH v3 4/6] dt-bindings: gpio: Add binding documentation for gpio-thunderx
Signed-off-by: David Daney
Acked-by: Rob Herring
---
.../devicetree/bindings/gpio/gpio-thunderx.txt | 27 ++
1 file changed, 27 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-thunderx.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-thunderx.txt
b/Documentation/devicetree/bindings/gpio/gpio-thunderx.txt
new file mode 100644
index 000..3f883ae
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-thunderx.txt
@@ -0,0 +1,27 @@
+Cavium ThunderX/OCTEON-TX GPIO controller bindings
+
+Required Properties:
+- reg: The controller bus address.
+- gpio-controller: Marks the device node as a GPIO controller.
+- #gpio-cells: Must be 2.
+ - First cell is the GPIO pin number relative to the controller.
+ - Second cell is a standard generic flag bitfield as described in gpio.txt.
+
+Optional Properties:
+- compatible: "cavium,thunder-8890-gpio", unused as PCI driver binding is used.
+- interrupt-controller: Marks the device node as an interrupt controller.
+- #interrupt-cells: Must be present and have value of 2 if
+"interrupt-controller" is present.
+ - First cell is the GPIO pin number relative to the controller.
+ - Second cell is triggering flags as defined in interrupts.txt.
+
+Example:
+
+gpio_6_0: gpio@6,0 {
+ compatible = "cavium,thunder-8890-gpio";
+ reg = <0x3000 0 0 0 0>; /* DEVFN = 0x30 (6:0) */
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+};
--
1.8.3.1
[PATCH] mfd: altr-a10sr: Add Arria10 SR sysfs attributes
From: Thor Thayer
Add the Altera Arria10 DevKit sysfs attributes to the
MFD device. Update copyright and email.
Signed-off-by: Thor Thayer
---
drivers/mfd/altera-a10sr.c | 98 --
1 file changed, 95 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/altera-a10sr.c b/drivers/mfd/altera-a10sr.c
index 06e1f7f..8c51818 100644
--- a/drivers/mfd/altera-a10sr.c
+++ b/drivers/mfd/altera-a10sr.c
@@ -1,9 +1,9 @@
/*
* Altera Arria10 DevKit System Resource MFD Driver
*
- * Author: Thor Thayer
+ * Author: Thor Thayer
*
- * Copyright Intel Corporation (C) 2014-2016. All Rights Reserved
+ * Copyright Intel Corporation (C) 2014-2017. All Rights Reserved
*
* This program is free software; you can redistribute it and/or modify it
* under the terms and conditions of the GNU General Public License,
@@ -35,6 +35,89 @@
},
};
+/* Add sysfs interface for MAX5 System Resource Controller */
+static unsigned int a10sr_reg_addr;
+static ssize_t a10sr_reg_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ return sprintf(buf, "0x%02x\n", a10sr_reg_addr);
+}
+
+static ssize_t a10sr_reg_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ int ret = kstrtouint(buf, 0, &a10sr_reg_addr);
+
+ if (ret || (a10sr_reg_addr < 0) ||
+ (a10sr_reg_addr > ALTR_A10SR_PMBUS_REG)) {
+ a10sr_reg_addr = 0;
+ dev_err(dev, "Invalid register address\n");
+ return -EINVAL;
+ }
+ return (ssize_t)count;
+}
+
+static ssize_t a10sr_val_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ int ret;
+ unsigned int val;
+ struct altr_a10sr *a10sr_regs = dev_get_drvdata(dev);
+
+ ret = regmap_read(a10sr_regs->regmap, a10sr_reg_addr, &val);
+ if (ret < 0) {
+ dev_err(dev, "Failed to read 0x%x\n", a10sr_reg_addr);
+ return -EIO;
+ }
+
+ return sprintf(buf, "0x%02x\n", val);
+}
+
+static ssize_t a10sr_val_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ int ret;
+ unsigned int val;
+ struct altr_a10sr *a10sr_regs = dev_get_drvdata(dev);
+
+ ret = kstrtouint(buf, 0, &val);
+ if (ret)
+ return ret;
+
+ ret = regmap_write(a10sr_regs->regmap, a10sr_reg_addr, val);
+ if (ret) {
+ dev_err(dev, "Failed to write value 0x%02x to address 0x%x",
+ val, a10sr_reg_addr);
+ return -EIO;
+ }
+ return count;
+}
+
+static ssize_t a10sr_version(struct device *dev,
+struct device_attribute *devattr, char *buf)
+{
+ a10sr_reg_addr = ALTR_A10SR_VERSION_READ;
+ return a10sr_val_show(dev, devattr, buf);
+}
+
+/* Define FS entries */
+static DEVICE_ATTR(max5_version, 0444, a10sr_version, NULL);
+static DEVICE_ATTR(max5_address, 0644, a10sr_reg_show, a10sr_reg_store);
+static DEVICE_ATTR(max5_value, 0644, a10sr_val_show, a10sr_val_store);
+
+static struct attribute *altr_a10sr_attr[] = {
+ &dev_attr_max5_version.attr,
+ &dev_attr_max5_address.attr,
+ &dev_attr_max5_value.attr,
+ NULL
+};
+
+static const struct attribute_group a10sr_attr_group = {
+ .attrs = altr_a10sr_attr,
+};
+
static bool altr_a10sr_reg_readable(struct device *dev, unsigned int reg)
{
switch (reg) {
@@ -141,13 +224,22 @@ static int altr_a10sr_spi_probe(struct spi_device *spi)
return ret;
}
+ /* Add the A10SR Registers to the device's sysfs */
+ ret = sysfs_create_group(&a10sr->dev->kobj, &a10sr_attr_group);
+ if (ret) {
+ dev_err(&spi->dev, "unable to create sysfs attributes\n");
+ return ret;
+ }
+
ret = devm_mfd_add_devices(a10sr->dev, PLATFORM_DEVID_AUTO,
altr_a10sr_subdev_info,
ARRAY_SIZE(altr_a10sr_subdev_info),
NULL, 0, NULL);
- if (ret)
+ if (ret) {
dev_err(a10sr->dev, "Failed to register sub-devices: %d\n",
ret);
+ sysfs_remove_group(&a10sr->dev->kobj, &a10sr_attr_group);
+ }
return ret;
}
--
1.9.1
Re: [PATCH 1/6] x86: drop unneded members of struct cpuinfo_x86
Hi Boris,
On Tue, Feb 14, 2017 at 5:17 PM, Borislav Petkov wrote:
> On Sun, Feb 12, 2017 at 10:12:07PM +0100, Mathias Krause wrote:
>> Those member serve no purpose -- not even fill padding for alignment or
>> such. So just get rid of them.
>
> Well, almost. You need the wp_works_ok removal patch too, otherwise you
> have the 3 bytes hole below.
That's because you removed a char in commit 93a829e8e2c292f1
("x86, cpu: Convert FDIV bug detection), without compensating with padding ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH] staging: fwserial: replace 'a' with '(a)' to avoid precedence issues
Macro argument 'a' may be better as '(a)' to avoid precedence issues as
reported by checkpatch.pl
Signed-off-by: Arushi Singhal
---
drivers/staging/fwserial/fwserial.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/fwserial/fwserial.c
b/drivers/staging/fwserial/fwserial.c
index 41a49c8194e5..bdfc0a8c7af3 100644
--- a/drivers/staging/fwserial/fwserial.c
+++ b/drivers/staging/fwserial/fwserial.c
@@ -98,7 +98,7 @@ struct fwtty_transaction {
};
};
-#define to_device(a, b)(a->b)
+#define to_device((a), b) (a->b)
#define fwtty_err(p, fmt, ...) \
dev_err(to_device(p, device), fmt, ##__VA_ARGS__)
#define fwtty_info(p, fmt, ...)
\
--
2.11.0
Re: [PATCH v4 1/1] DM: inplace compressed DM target (fwd)
On Tue, Feb 14, 2017 at 07:09:04AM +0100, Julia Lawall wrote:
> On line 1759, since ret is unsigned it will not be less than 0.
Thanks fixed it. Infact noticed that dm_icomp_io_range_compress() had missed a
case where
it was supposed to return error; a negative number. Fixed that aswell.
RP
>
> julia
>
> -- Forwarded message --
> Date: Tue, 14 Feb 2017 09:00:39 +0800
> From: kbuild test robot
> To: kbu...@01.org
> Cc: Julia Lawall
> Subject: Re: [PATCH v4 1/1] DM: inplace compressed DM target
>
> CC: kbuild-...@01.org
> In-Reply-To: <1487018545-5061-2-git-send-email-linux...@us.ibm.com>
>
> Hi Ram,
>
> [auto build test WARNING on dm/for-next]
> [also build test WARNING on v4.10-rc8 next-20170213]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Ram-Pai/DM-inplace-compressed-DM-target/20170214-055727
> base:
> https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git
> for-next
> :: branch date: 3 hours ago
> :: commit date: 3 hours ago
>
> >> drivers/md/dm-inplace-compress.c:1759:5-8: WARNING: Unsigned expression
> >> compared with zero: ret < 0
>
> git remote add linux-review https://github.com/0day-ci/linux
> git remote update linux-review
> git checkout e7924efaaba5efdcd28f32efbb949ed1153c932c
> vim +1759 drivers/md/dm-inplace-compress.c
>
> e7924efa Ram Pai 2017-02-13 1743 * @io : io range
> e7924efa Ram Pai 2017-02-13 1744 * @sector_start : the sector on backing
> storage to which the
> e7924efa Ram Pai 2017-02-13 1745 * compressed data needs to be written.
> e7924efa Ram Pai 2017-02-13 1746 * @meta_start: the page index of the bits
> corresponding to
> e7924efa Ram Pai 2017-02-13 1747 * @meta_end : start and end blocks.
> e7924efa Ram Pai 2017-02-13 1748 */
> e7924efa Ram Pai 2017-02-13 1749 static int dm_icomp_compress_write(struct
> dm_icomp_io_range *io,
> e7924efa Ram Pai 2017-02-13 1750 sector_t sector_start, u64
> *meta_start, u64 *meta_end)
> e7924efa Ram Pai 2017-02-13 1751 {
> e7924efa Ram Pai 2017-02-13 1752 struct dm_icomp_req *req = io->req;
> e7924efa Ram Pai 2017-02-13 1753 sector_t count =
> DMCP_BYTES_TO_SECTOR(io->decomp_len);
> e7924efa Ram Pai 2017-02-13 1754 unsigned int comp_len, ret;
> e7924efa Ram Pai 2017-02-13 1755 u64 page_index;
> e7924efa Ram Pai 2017-02-13 1756
> e7924efa Ram Pai 2017-02-13 1757 /* comp_data must be able to
> accommadate a larger compress buffer */
> e7924efa Ram Pai 2017-02-13 1758 ret =
> dm_icomp_io_range_compress(req->info, io, &comp_len);
> e7924efa Ram Pai 2017-02-13 @1759 if (ret < 0) {
> e7924efa Ram Pai 2017-02-13 1760 req->result = -EIO;
> e7924efa Ram Pai 2017-02-13 1761 return -EIO;
> e7924efa Ram Pai 2017-02-13 1762 }
> e7924efa Ram Pai 2017-02-13 1763 WARN_ON(comp_len > io->comp_len);
> e7924efa Ram Pai 2017-02-13 1764
> e7924efa Ram Pai 2017-02-13 1765 dm_icomp_get_req(req);
> e7924efa Ram Pai 2017-02-13 1766
> e7924efa Ram Pai 2017-02-13 1767 io->io_req.bi_op = REQ_OP_WRITE;
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
Ram Pai
[PATCH v3 6/6] MAINTAINERS: Add entry for THUNDERX GPIO Driver.
Signed-off-by: David Daney --- MAINTAINERS | 5 + 1 file changed, 5 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 107c10e..9238cd0 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10904,6 +10904,11 @@ M: Andreas Noever S: Maintained F: drivers/thunderbolt/ +THUNDERX GPIO DRIVER +M: David Daney +S: Maintained +F: drivers/gpio/gpio-thunderx.c + TI BQ27XXX POWER SUPPLY DRIVER R: Andrew F. Davis F: include/linux/power/bq27xxx_battery.h -- 1.8.3.1
[PATCH v3 1/6] genirq: Export more irq_chip_*_parent() functions.
Many of the family of functions including irq_chip_mask_parent(), irq_chip_unmask_parent() are exported, but not all. Add EXPORT_SYMBOL_GPL to irq_chip_enable_parent, irq_chip_disable_parent and irq_chip_set_affinity_parent, so they likewise are usable from modules. Signed-off-by: David Daney --- kernel/irq/chip.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c index be3c34e..73ea90b 100644 --- a/kernel/irq/chip.c +++ b/kernel/irq/chip.c @@ -993,6 +993,7 @@ void irq_chip_enable_parent(struct irq_data *data) else data->chip->irq_unmask(data); } +EXPORT_SYMBOL_GPL(irq_chip_enable_parent); /** * irq_chip_disable_parent - Disable the parent interrupt (defaults to mask if @@ -1007,6 +1008,7 @@ void irq_chip_disable_parent(struct irq_data *data) else data->chip->irq_mask(data); } +EXPORT_SYMBOL_GPL(irq_chip_disable_parent); /** * irq_chip_ack_parent - Acknowledge the parent interrupt @@ -1069,6 +1071,7 @@ int irq_chip_set_affinity_parent(struct irq_data *data, return -ENOSYS; } +EXPORT_SYMBOL_GPL(irq_chip_set_affinity_parent); /** * irq_chip_set_type_parent - Set IRQ type on the parent interrupt -- 1.8.3.1
[PATCH v3 2/6] genirq: Add handle_fasteoi_{level,edge}_irq flow handlers.
Follow-on patch for gpio-thunderx uses a irqdomain hierarchy which
requires slightly different flow handlers, add them to chip.c which
contains most of the other flow handlers.
Signed-off-by: David Daney
---
include/linux/irq.h | 2 ++
kernel/irq/chip.c | 102
2 files changed, 104 insertions(+)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 39e3254..545b770 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -518,6 +518,8 @@ static inline int irq_set_parent(int irq, int parent_irq)
extern int irq_chip_pm_get(struct irq_data *data);
extern int irq_chip_pm_put(struct irq_data *data);
#ifdef CONFIG_IRQ_DOMAIN_HIERARCHY
+extern void handle_fasteoi_edge_irq(struct irq_desc *desc);
+extern void handle_fasteoi_level_irq(struct irq_desc *desc);
extern void irq_chip_enable_parent(struct irq_data *data);
extern void irq_chip_disable_parent(struct irq_data *data);
extern void irq_chip_ack_parent(struct irq_data *data);
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 73ea90b..213105d 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -981,6 +981,108 @@ void irq_cpu_offline(void)
#ifdef CONFIG_IRQ_DOMAIN_HIERARCHY
/**
+ * handle_fasteoi_edge_irq - irq handler for edge hierarchy
+ * stacked on transparent controllers
+ *
+ * @desc: the interrupt description structure for this irq
+ *
+ * Like handle_fasteoi_irq(), but for use with hierarchy where
+ * the irq_chip also needs to have its ->irq_ack() function
+ * called.
+ */
+void handle_fasteoi_edge_irq(struct irq_desc *desc)
+{
+ struct irq_chip *chip = desc->irq_data.chip;
+
+ raw_spin_lock(&desc->lock);
+
+ if (!irq_may_run(desc))
+ goto out;
+
+ desc->istate &= ~(IRQS_REPLAY | IRQS_WAITING);
+
+ /*
+* If its disabled or no action available
+* then mask it and get out of here:
+*/
+ if (unlikely(!desc->action || irqd_irq_disabled(&desc->irq_data))) {
+ desc->istate |= IRQS_PENDING;
+ mask_irq(desc);
+ goto out;
+ }
+
+ kstat_incr_irqs_this_cpu(desc);
+ if (desc->istate & IRQS_ONESHOT)
+ mask_irq(desc);
+
+ /* Start handling the irq */
+ desc->irq_data.chip->irq_ack(&desc->irq_data);
+
+ preflow_handler(desc);
+ handle_irq_event(desc);
+
+ cond_unmask_eoi_irq(desc, chip);
+
+ raw_spin_unlock(&desc->lock);
+ return;
+out:
+ if (!(chip->flags & IRQCHIP_EOI_IF_HANDLED))
+ chip->irq_eoi(&desc->irq_data);
+ raw_spin_unlock(&desc->lock);
+}
+EXPORT_SYMBOL_GPL(handle_fasteoi_edge_irq);
+
+/**
+ * handle_fasteoi_level_irq - irq handler for level hierarchy
+ * stacked on transparent controllers
+ *
+ * @desc: the interrupt description structure for this irq
+ *
+ * Like handle_fasteoi_irq(), but for use with hierarchy where
+ * the irq_chip also needs to have its ->irq_mask_ack() function
+ * called.
+ */
+void handle_fasteoi_level_irq(struct irq_desc *desc)
+{
+ struct irq_chip *chip = desc->irq_data.chip;
+
+ raw_spin_lock(&desc->lock);
+ mask_ack_irq(desc);
+
+ if (!irq_may_run(desc))
+ goto out;
+
+ desc->istate &= ~(IRQS_REPLAY | IRQS_WAITING);
+
+ /*
+* If its disabled or no action available
+* then mask it and get out of here:
+*/
+ if (unlikely(!desc->action || irqd_irq_disabled(&desc->irq_data))) {
+ desc->istate |= IRQS_PENDING;
+ mask_irq(desc);
+ goto out;
+ }
+
+ kstat_incr_irqs_this_cpu(desc);
+ if (desc->istate & IRQS_ONESHOT)
+ mask_irq(desc);
+
+ preflow_handler(desc);
+ handle_irq_event(desc);
+
+ cond_unmask_eoi_irq(desc, chip);
+
+ raw_spin_unlock(&desc->lock);
+ return;
+out:
+ if (!(chip->flags & IRQCHIP_EOI_IF_HANDLED))
+ chip->irq_eoi(&desc->irq_data);
+ raw_spin_unlock(&desc->lock);
+}
+EXPORT_SYMBOL_GPL(handle_fasteoi_level_irq);
+
+/**
* irq_chip_enable_parent - Enable the parent interrupt (defaults to unmask if
* NULL)
* @data: Pointer to interrupt specific data
--
1.8.3.1
[PATCH v3 3/6] irqdomain: Add irq_domain_{push,pop}_irq() functions.
For an already existing irqdomain hierarchy, as might be obtained via
a call to pci_enable_msix(), a PCI driver wishing to add an additional
irqdomain to the hierarchy needs to be able to insert the irqdomain to
that already initialized hierarchy. Calling
irq_domain_create_hierarchy() allows the new irqdomain to be created,
but no existing code allows for initializing the associated irq_data.
Add a couple of helper functions (irq_domain_push_irq()
irq_domain_pop_irq()) to initialize the irq_data for the new
irqdomain.
Signed-off-by: David Daney
---
include/linux/irqdomain.h | 3 +
kernel/irq/irqdomain.c| 137 ++
2 files changed, 140 insertions(+)
diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index ffb8460..d8e60d1 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -418,6 +418,9 @@ extern void irq_domain_free_irqs_common(struct irq_domain
*domain,
extern void irq_domain_free_irqs_top(struct irq_domain *domain,
unsigned int virq, unsigned int nr_irqs);
+extern int irq_domain_push_irq(struct irq_domain *domain, int virq, void *arg);
+extern int irq_domain_pop_irq(struct irq_domain *domain, int virq);
+
extern int irq_domain_alloc_irqs_parent(struct irq_domain *domain,
unsigned int irq_base,
unsigned int nr_irqs, void *arg);
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index b59e676..5266251 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -1279,6 +1279,143 @@ int __irq_domain_alloc_irqs(struct irq_domain *domain,
int irq_base,
return ret;
}
+/* The irq_data was moved, fix the revmap to refer to the new location */
+static void irq_domain_fix_revmap(struct irq_data *d)
+{
+ void **slot;
+
+ if (d->hwirq < d->domain->revmap_size)
+ return; /* Not using radix tree. */
+
+ /* Fix up the revmap. */
+ mutex_lock(&revmap_trees_mutex);
+ slot = radix_tree_lookup_slot(&d->domain->revmap_tree, d->hwirq);
+ if (slot)
+ radix_tree_replace_slot(&d->domain->revmap_tree, slot, d);
+ mutex_unlock(&revmap_trees_mutex);
+}
+
+/**
+ * irq_domain_push_irq() - Push a domain in to the top of a hierarchy.
+ * @domain:Domain to push.
+ * @virq: Irq to push the domain in to.
+ * @arg: Passed to the irq_domain_ops alloc() function.
+ *
+ * For an already existing irqdomain hierarchy, as might be obtained
+ * via a call to pci_enable_msix(), add an additional domain to the
+ * head of the processing chain.
+ */
+int irq_domain_push_irq(struct irq_domain *domain, int virq, void *arg)
+{
+ struct irq_data *child_irq_data;
+ struct irq_data *root_irq_data = irq_get_irq_data(virq);
+
+ if (domain == NULL)
+ return -EINVAL;
+
+ if (WARN_ON(!domain->ops->alloc))
+ return -ENOSYS;
+
+ if (!root_irq_data)
+ return -EINVAL;
+
+ child_irq_data = kzalloc_node(sizeof(*child_irq_data), GFP_KERNEL,
+ irq_data_get_node(root_irq_data));
+ if (!child_irq_data)
+ return -ENOMEM;
+
+ mutex_lock(&irq_domain_mutex);
+
+ /* Copy the original irq_data. */
+ *child_irq_data = *root_irq_data;
+
+ irq_domain_fix_revmap(child_irq_data);
+
+ /*
+* Overwrite the root_irq_data, which is embedded in struct
+* irq_desc, with values for this domain.
+*/
+ root_irq_data->parent_data = child_irq_data;
+ root_irq_data->domain = domain;
+ root_irq_data->mask = 0;
+ root_irq_data->hwirq = 0;
+ root_irq_data->chip = NULL;
+ root_irq_data->chip_data = NULL;
+ domain->ops->alloc(domain, virq, 1, arg);
+
+ if (root_irq_data->hwirq < domain->revmap_size) {
+ domain->linear_revmap[root_irq_data->hwirq] = virq;
+ } else {
+ mutex_lock(&revmap_trees_mutex);
+ radix_tree_insert(&domain->revmap_tree,
+ root_irq_data->hwirq, root_irq_data);
+ mutex_unlock(&revmap_trees_mutex);
+ }
+
+ mutex_unlock(&irq_domain_mutex);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(irq_domain_push_irq);
+
+/**
+ * irq_domain_pop_irq() - Remove a domain from the top of a hierarchy.
+ * @domain:Domain to remove.
+ * @virq: Irq to remove the domain from.
+ *
+ * Undo the effects of a call to irq_domain_push_irq().
+ */
+int irq_domain_pop_irq(struct irq_domain *domain, int virq)
+{
+ struct irq_data *root_irq_data = irq_get_irq_data(virq);
+ struct irq_data *child_irq_data;
+ struct irq_data *tmp_irq_data;
+
+ if (domain == NULL)
+ return -EINVAL;
+
+ if (!root_irq_data)
+ return -EINVAL;
+
+ tmp_irq_data = irq_domain_get_irq_data(domain, virq);
+
+
[PATCH v3 5/6] gpio: Add gpio driver support for ThunderX and OCTEON-TX
Cavium ThunderX and OCTEON-TX are arm64 based SoCs. Add driver for
the on-chip GPIO pins.
Signed-off-by: David Daney
---
drivers/gpio/Kconfig | 7 +
drivers/gpio/Makefile| 1 +
drivers/gpio/gpio-thunderx.c | 490 +++
3 files changed, 498 insertions(+)
create mode 100644 drivers/gpio/gpio-thunderx.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index d5d3654..cd55c050 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -421,6 +421,13 @@ config GPIO_TS4800
help
This driver support TS-4800 FPGA GPIO controllers.
+config GPIO_THUNDERX
+ tristate "Cavium ThunderX/OCTEON-TX GPIO"
+ depends on ARCH_THUNDER || (64BIT && COMPILE_TEST)
+ help
+ Say yes here to support the on-chip GPIO lines on the ThunderX
+ and OCTEON-TX families of SoCs.
+
config GPIO_TZ1090
bool "Toumaz Xenif TZ1090 GPIO support"
depends on SOC_TZ1090
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index a7676b8..c62bc72 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -108,6 +108,7 @@ obj-$(CONFIG_GPIO_SYSCON) += gpio-syscon.o
obj-$(CONFIG_GPIO_TB10X) += gpio-tb10x.o
obj-$(CONFIG_GPIO_TC3589X) += gpio-tc3589x.o
obj-$(CONFIG_GPIO_TEGRA) += gpio-tegra.o
+obj-$(CONFIG_GPIO_THUNDERX)+= gpio-thunderx.o
obj-$(CONFIG_GPIO_TIMBERDALE) += gpio-timberdale.o
obj-$(CONFIG_GPIO_PALMAS) += gpio-palmas.o
obj-$(CONFIG_GPIO_TPIC2810)+= gpio-tpic2810.o
diff --git a/drivers/gpio/gpio-thunderx.c b/drivers/gpio/gpio-thunderx.c
new file mode 100644
index 000..6afebc9
--- /dev/null
+++ b/drivers/gpio/gpio-thunderx.c
@@ -0,0 +1,490 @@
+/*
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 2016, 2017 Cavium Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+#define GPIO_RX_DAT0x0
+#define GPIO_TX_SET0x8
+#define GPIO_TX_CLR0x10
+#define GPIO_CONST 0x90
+#define GPIO_CONST_GPIOS_MASK 0xff
+#define GPIO_BIT_CFG 0x400
+#define GPIO_BIT_CFG_TX_OEBIT(0)
+#define GPIO_BIT_CFG_PIN_XOR BIT(1)
+#define GPIO_BIT_CFG_INT_EN BIT(2)
+#define GPIO_BIT_CFG_INT_TYPE BIT(3)
+#define GPIO_BIT_CFG_FIL_CNT_SHIFT4
+#define GPIO_BIT_CFG_FIL_SEL_SHIFT8
+#define GPIO_BIT_CFG_TX_ODBIT(12)
+#define GPIO_BIT_CFG_PIN_SEL_MASK GENMASK(25, 16)
+#define GPIO_INTR 0x800
+#define GPIO_INTR_INTRBIT(0)
+#define GPIO_INTR_INTR_W1SBIT(1)
+#define GPIO_INTR_ENA_W1C BIT(2)
+#define GPIO_INTR_ENA_W1S BIT(3)
+#define GPIO_2ND_BANK 0x1400
+
+#define GLITCH_FILTER_400NS ((4ull << GPIO_BIT_CFG_FIL_SEL_SHIFT) | \
+(9ull << GPIO_BIT_CFG_FIL_CNT_SHIFT))
+
+struct thunderx_gpio;
+
+struct thunderx_line {
+ struct thunderx_gpio*txgpio;
+ unsigned intline;
+};
+
+struct thunderx_gpio {
+ struct gpio_chipchip;
+ u8 __iomem *register_base;
+ struct irq_domain *irqd;
+ struct msix_entry *msix_entries; /* per line MSI-X */
+ struct thunderx_line*line_entries; /* per line irq info */
+ raw_spinlock_t lock;
+ unsigned long invert_mask[2];
+ unsigned long od_mask[2];
+ int base_msi;
+};
+
+static unsigned int bit_cfg_reg(unsigned int line)
+{
+ return 8 * line + GPIO_BIT_CFG;
+}
+
+static unsigned int intr_reg(unsigned int line)
+{
+ return 8 * line + GPIO_INTR;
+}
+
+/*
+ * Check (and WARN) that the pin is available for GPIO. We will not
+ * allow modification of the state of non-GPIO pins from this driver.
+ */
+static bool thunderx_gpio_is_gpio(struct thunderx_gpio *txgpio,
+ unsigned int line)
+{
+ u64 bit_cfg = readq(txgpio->register_base + bit_cfg_reg(line));
+ bool rv = (bit_cfg & GPIO_BIT_CFG_PIN_SEL_MASK) == 0;
+
+ WARN_RATELIMIT(!rv, "Pin %d not available for GPIO\n", line);
+
+ return rv;
+}
+
+static int thunderx_gpio_dir_in(struct gpio_chip *chip, unsigned int line)
+{
+ struct thunderx_gpio *txgpio = gpiochip_get_data(chip);
+
+ if (!thunderx_gpio_is_gpio(txgpio, line))
+ return -EIO;
+
+ raw_spin_lock(&txgpio->lock);
+ clear_bit(line, txgpio->invert_mask);
+ clear_bit(line, txgpio->od_mask);
+ writeq(GLITCH_FILTER_400NS, txgpio->register_base + bit_cfg_reg(line));
+ raw_spin_unlock(&txgpio->lock);
+ return 0;
+}
+
+static void thunderx_gpio_set(struct gpio_chip *chip, unsigned int line,
+ int value)
+{
+ struct thunderx_gpio *txgpio = gpiochip_get_data(chip);
+ int bank
Re: v4.10-rc8 (-rc6) boot regression on Intel desktop, does not boot after cold boots, boots after reboot
Hi!
> > > > Hmm. I moved keyboard between USB ports, and now 4.10-rc6 no longer
> > > > boots. v4.6 works ok. Let me try with keyboard unplugged... no, I
> > > > could not get it to work. I believe v4.9 and some v4.10-rc's worked,
> > > > but I'll have to double check.
> > >
> > > But all the kernel versions worked when the keyboard was plugged into
> > > its original USB port?
> >
> > Aha. So it looks difference is probably in "where is keyboard plugged
> > in" but in "reboot" vs. "cold boot". I did not do a cold boot in quite
> > a while :-(.
> >
> > Booting to grub, then hitting ctrl-alt-del is enough to make it work. Ouch.
> >
> > It happens with current Linus' tree.
>
> v4.10-rc6-feb3 : broken
> v4.9 : ok
> (v4.6 : ok)
Hmm. It hangs during PCI fixups, and it hangs in v4.10-rc8, too.
With debug patch below, I get
...1d.7: PCI fixup... pass 2
...1d.7: PCI fixup... pass 3
...1d.7: PCI fixup... pass 3 done
...followed by hang. So yes, it looks USB related.
(Sometimes it hangs with some kind backtrace involving secondary CPU
startup, unfortunately useful info is off screen at that point).
Any ideas?
Pavel
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 1800bef..060ad79 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3510,6 +3510,8 @@ void pci_fixup_device(enum pci_fixup_pass pass, struct
pci_dev *dev)
{
struct pci_fixup *start, *end;
+ dev_info(&dev->dev, "PCI fixup device %p, pass %d\n", dev, pass);
+
switch (pass) {
case pci_fixup_early:
start = __start_pci_fixups_early;
@@ -3558,6 +3560,7 @@ void pci_fixup_device(enum pci_fixup_pass pass, struct
pci_dev *dev)
return;
}
pci_do_fixups(dev, start, end);
+ dev_info(&dev->dev, "PCI fixup device %p, pass %d, done\n", dev, pass);
}
EXPORT_SYMBOL(pci_fixup_device);
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH V2] audit: log module name on init_module
On Monday, February 13, 2017 4:20:55 PM EST Paul Moore wrote:
> On Sat, Feb 4, 2017 at 1:10 PM, Richard Guy Briggs wrote:
> > This adds a new auxiliary record MODULE_INIT to the SYSCALL event.
> >
> > We get finit_module for free since it made most sense to hook this in to
> > load_module().
> >
> > https://github.com/linux-audit/audit-kernel/issues/7
> > https://github.com/linux-audit/audit-kernel/wiki/RFE-Module-load-record-fo
> > rmat
> Correction for the record:
>
> *
> https://github.com/linux-audit/audit-kernel/wiki/RFE-Module-Load-Record-For
> mat
>
> [NOTE: don't resend please, I'll fix this when merging]
OK. Support was added to user space for this record. While doing this, I
wondered if we also get this auxiliary record when unloading a module?
Thanks,
-Steve
> > Signed-off-by: Richard Guy Briggs
> > ---
> >
> > include/linux/audit.h | 12
> > include/uapi/linux/audit.h |1 +
> > kernel/audit.h |3 +++
> > kernel/auditsc.c | 14 ++
> > kernel/module.c|5 -
> > 5 files changed, 34 insertions(+), 1 deletions(-)
>
> This patch looks fine to me, and due to lack of comments I'm going to
> assume that Jessica is okay with the kernel/module.c portions of this
> patch. Normally this would be too close to the merge window, but this
> patch is trivial and since it is new functionality it is unlikely to
> cause any regressions so I'm going to merge it into audit/next now.
>
> > diff --git a/include/linux/audit.h b/include/linux/audit.h
> > index 2be99b2..aba3a26 100644
> > --- a/include/linux/audit.h
> > +++ b/include/linux/audit.h
> > @@ -360,6 +360,7 @@ extern int __audit_log_bprm_fcaps(struct linux_binprm
> > *bprm,>
> > const struct cred *old);
> >
> > extern void __audit_log_capset(const struct cred *new, const struct cred
> > *old); extern void __audit_mmap_fd(int fd, int flags);
> >
> > +extern void __audit_log_kern_module(char *name);
> >
> > static inline void audit_ipc_obj(struct kern_ipc_perm *ipcp)
> > {
> >
> > @@ -450,6 +451,12 @@ static inline void audit_mmap_fd(int fd, int flags)
> >
> > __audit_mmap_fd(fd, flags);
> >
> > }
> >
> > +static inline void audit_log_kern_module(char *name)
> > +{
> > + if (!audit_dummy_context())
> > + __audit_log_kern_module(name);
> > +}
> > +
> >
> > extern int audit_n_rules;
> > extern int audit_signals;
> > #else /* CONFIG_AUDITSYSCALL */
> >
> > @@ -561,6 +568,11 @@ static inline void audit_log_capset(const struct cred
> > *new,>
> > { }
> > static inline void audit_mmap_fd(int fd, int flags)
> > { }
> >
> > +
> > +static inline void audit_log_kern_module(char *name)
> > +{
> > +}
> > +
> >
> > static inline void audit_ptrace(struct task_struct *t)
> > { }
> > #define audit_n_rules 0
> >
> > diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
> > index 3f24110..3c02bb2 100644
> > --- a/include/uapi/linux/audit.h
> > +++ b/include/uapi/linux/audit.h
> > @@ -111,6 +111,7 @@
> >
> > #define AUDIT_PROCTITLE1327/* Proctitle emit event */
> > #define AUDIT_FEATURE_CHANGE 1328/* audit log listing feature
> > changes */ #define AUDIT_REPLACE 1329/* Replace auditd if
> > this packet unanswerd */>
> > +#define AUDIT_KERN_MODULE 1330/* Kernel Module events */
> >
> > #define AUDIT_AVC 1400/* SE Linux avc denial or grant */
> > #define AUDIT_SELINUX_ERR 1401/* Internal SE Linux Errors */
> >
> > diff --git a/kernel/audit.h b/kernel/audit.h
> > index 431444c..144b7eb 100644
> > --- a/kernel/audit.h
> > +++ b/kernel/audit.h
> > @@ -199,6 +199,9 @@ struct audit_context {
> >
> > struct {
> >
> > int argc;
> >
> > } execve;
> >
> > + struct {
> > + char*name;
> > + } module;
> >
> > };
> > int fds[2];
> > struct audit_proctitle proctitle;
> >
> > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > index bb5f504..bde3aac 100644
> > --- a/kernel/auditsc.c
> > +++ b/kernel/auditsc.c
> > @@ -1268,6 +1268,11 @@ static void show_special(struct audit_context
> > *context, int *call_panic)>
> > case AUDIT_EXECVE: {
> >
> > audit_log_execve_info(context, &ab);
> > break; }
> >
> > + case AUDIT_KERN_MODULE:
> > + audit_log_format(ab, "name=");
> > + audit_log_untrustedstring(ab, context->module.name);
> > + kfree(context->module.name);
> > + break;
> >
> > }
> > audit_log_end(ab);
> >
> > }
> >
> > @@ -2368,6 +2373,15 @@ void __audit_mmap_fd(int fd, int flags)
> >
> > context->type = AUDIT_MMAP;
> >
> > }
> >
> > +void __audit_log_kern_mo
[PATCH] f2fs: fix multiple f2fs_add_link() calls having same name
VFS uses f2fs_lookup() to decide f2fs_add_link() call during file creation.
But, if there is a race condition, f2fs_add_link() can be called multiple
times, resulting in multiple dentries with a same name. This patches fixes
it by adding __f2fs_find_entry() in f2fs_add_link() path.
Cc:
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/dir.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index 827c5daef4fc..bc7c48839bec 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -643,14 +643,24 @@ int __f2fs_add_link(struct inode *dir, const struct qstr
*name,
struct inode *inode, nid_t ino, umode_t mode)
{
struct fscrypt_name fname;
+ struct page *page;
+ struct f2fs_dir_entry *de;
int err;
err = fscrypt_setup_filename(dir, name, 0, &fname);
if (err)
return err;
- err = __f2fs_do_add_link(dir, &fname, inode, ino, mode);
-
+ de = __f2fs_find_entry(dir, &fname, &page);
+ if (de) {
+ f2fs_dentry_kunmap(dir, page);
+ f2fs_put_page(page, 0);
+ err = -EEXIST;
+ } else if (!IS_ERR(page)) {
+ err = __f2fs_do_add_link(dir, &fname, inode, ino, mode);
+ } else {
+ err = PTR_ERR(page);
+ }
fscrypt_free_filename(&fname);
return err;
}
--
2.11.0
Re: [PATCH v4 net-next 0/8] sunvnet driver updates
From: Shannon Nelson Date: Mon, 13 Feb 2017 10:56:56 -0800 > The sunvnet ldom virtual network driver was due for some updates and > a bugfix or two. These patches address a few items left over from > last year's make-over. > > v2: > - changed memory barrier fix to use smp_wmb > - put NETIF_F_SG back into the advertised ldmvsw hw_features > > v3: > - the sunvnet_common module doesn't need module_init or _exit > > v4: > - dropped the statistics patch > - fixed up "default" tag for SUNVNET_COMMON Series applied, thanks.
Re: [PATCH 3/4] ptp: use is_visible method to hide unused attributes
Hi Richard,
On Tue, Feb 14, 2017 at 09:42:26AM +0100, Richard Cochran wrote:
> On Mon, Feb 13, 2017 at 07:51:07PM -0800, Dmitry Torokhov wrote:
> > Instead of creating selected attributes after the device is created (and
> > after userspace potentially seen uevent), lets use attribute group
> > is_visible() method to control which attributes are shown. This will allow
> > us to create all attributes (except "pins" group, which will be taken care
> > of later) before userspace gets notified about new ptp class device.
>
> At first glance, this patch and the next look like nice improvements.
> I don't futz around with sysfs code very often, and so may I ask how
> or whether you tested it?
I used the hack below.
Thanks.
--
Dmitry
PTP Test
Signed-off-by: Dmitry Torokhov
---
drivers/net/ethernet/intel/e1000e/ptp.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/ptp.c
b/drivers/net/ethernet/intel/e1000e/ptp.c
index 34cc3be0df8e..3b4c0d3e4093 100644
--- a/drivers/net/ethernet/intel/e1000e/ptp.c
+++ b/drivers/net/ethernet/intel/e1000e/ptp.c
@@ -260,18 +260,27 @@ static void e1000e_systim_overflow_work(struct
work_struct *work)
E1000_SYSTIM_OVERFLOW_PERIOD);
}
+static struct ptp_pin_desc e1000e_ptp_pin_config[1] = {
+ {
+ .name = "TestPin1",
+ .index = 0,
+ .func = PTP_PF_NONE,
+ }
+};
+
static const struct ptp_clock_info e1000e_ptp_clock_info = {
.owner = THIS_MODULE,
.n_alarm= 0,
.n_ext_ts = 0,
- .n_per_out = 0,
- .n_pins = 0,
+ .n_per_out = 1,
+ .n_pins = 1,
.pps= 0,
.adjfreq= e1000e_phc_adjfreq,
.adjtime= e1000e_phc_adjtime,
.gettime64 = e1000e_phc_gettime,
.settime64 = e1000e_phc_settime,
.enable = e1000e_phc_enable,
+ .pin_config = e1000e_ptp_pin_config,
};
/**
Re: [PATCH] staging: fwserial: replace 'a' with '(a)' to avoid precedence issues
On Tue, Feb 14, 2017 at 11:26:20PM +0530, Arushi Singhal wrote:
> Macro argument 'a' may be better as '(a)' to avoid precedence issues as
> reported by checkpatch.pl
>
> Signed-off-by: Arushi Singhal
> ---
> drivers/staging/fwserial/fwserial.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/fwserial/fwserial.c
> b/drivers/staging/fwserial/fwserial.c
> index 41a49c8194e5..bdfc0a8c7af3 100644
> --- a/drivers/staging/fwserial/fwserial.c
> +++ b/drivers/staging/fwserial/fwserial.c
> @@ -98,7 +98,7 @@ struct fwtty_transaction {
> };
> };
>
> -#define to_device(a, b) (a->b)
> +#define to_device((a), b)(a->b)
Really? Why do we even have this macro at all? Can it just be removed?
thanks,
greg k-h
[PATCH 1/2] staging: vt6656: Alignment should match open parenthesis
Fix checkpatch issues: "CHECK: Alignment should match open parenthesis"
Signed-off-by: Arushi Singhal
---
drivers/staging/vt6656/firmware.c | 34 +-
drivers/staging/vt6656/key.h | 2 +-
drivers/staging/vt6656/rf.c | 12 ++--
drivers/staging/vt6656/usbpipe.c | 12 ++--
drivers/staging/vt6656/wcmd.c | 2 +-
5 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/drivers/staging/vt6656/firmware.c
b/drivers/staging/vt6656/firmware.c
index 1b48f9c86f63..282f665aacfa 100644
--- a/drivers/staging/vt6656/firmware.c
+++ b/drivers/staging/vt6656/firmware.c
@@ -64,11 +64,11 @@ int vnt_download_firmware(struct vnt_private *priv)
memcpy(buffer, fw->data + ii, length);
status = vnt_control_out(priv,
- 0,
- 0x1200+ii,
- 0x,
- length,
- buffer);
+0,
+0x1200+ii,
+0x,
+length,
+buffer);
dev_dbg(dev, "Download firmware...%d %zu\n", ii, fw->size);
@@ -94,11 +94,11 @@ int vnt_firmware_branch_to_sram(struct vnt_private *priv)
dev_dbg(&priv->usb->dev, ">Branch to Sram\n");
status = vnt_control_out(priv,
- 1,
- 0x1200,
- 0x,
- 0,
- NULL);
+1,
+0x1200,
+0x,
+0,
+NULL);
return status == STATUS_SUCCESS;
}
@@ -107,14 +107,14 @@ int vnt_check_firmware_version(struct vnt_private *priv)
int status;
status = vnt_control_in(priv,
- MESSAGE_TYPE_READ,
- 0,
- MESSAGE_REQUEST_VERSION,
- 2,
- (u8 *)&priv->firmware_version);
+ MESSAGE_TYPE_READ,
+ 0,
+ MESSAGE_REQUEST_VERSION,
+ 2,
+ (u8 *)&priv->firmware_version);
dev_dbg(&priv->usb->dev, "Firmware Version [%04x]\n",
- priv->firmware_version);
+ priv->firmware_version);
if (status != STATUS_SUCCESS) {
dev_dbg(&priv->usb->dev, "Firmware Invalid.\n");
@@ -126,7 +126,7 @@ int vnt_check_firmware_version(struct vnt_private *priv)
}
dev_dbg(&priv->usb->dev, "Firmware Version [%04x]\n",
- priv->firmware_version);
+ priv->firmware_version);
if (priv->firmware_version < FIRMWARE_VERSION) {
/* branch to loader for download new firmware */
diff --git a/drivers/staging/vt6656/key.h b/drivers/staging/vt6656/key.h
index 7861faf5138f..7be423004386 100644
--- a/drivers/staging/vt6656/key.h
+++ b/drivers/staging/vt6656/key.h
@@ -46,6 +46,6 @@
int vnt_key_init_table(struct vnt_private *);
int vnt_set_keys(struct ieee80211_hw *hw, struct ieee80211_sta *sta,
- struct ieee80211_vif *vif, struct ieee80211_key_conf *key);
+ struct ieee80211_vif *vif, struct ieee80211_key_conf *key);
#endif /* __KEY_H__ */
diff --git a/drivers/staging/vt6656/rf.c b/drivers/staging/vt6656/rf.c
index 6101a35582b6..068c1c89f653 100644
--- a/drivers/staging/vt6656/rf.c
+++ b/drivers/staging/vt6656/rf.c
@@ -771,7 +771,7 @@ int vnt_rf_set_txpower(struct vnt_private *priv, u8 power,
u32 rate)
ret &= vnt_rf_write_embedded(priv, 0x015C0800);
} else {
dev_dbg(&priv->usb->dev,
- " vnt_rf_set_txpower> 11G mode\n");
+ " vnt_rf_set_txpower> 11G mode\n");
power_setting = ((0x3f - power) << 20) | (0x7 << 8);
@@ -876,7 +876,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr1, length1);
vnt_control_out(priv, MESSAGE_TYPE_WRITE, 0,
- MESSAGE_REQUEST_RF_INIT, length1, array);
+ MESSAGE_REQUEST_RF_INIT, length1, array);
/* Channel Table 0 */
value = 0;
@@ -889,7 +889,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr2, length);
Re: [PATCH 01/15] staging: rtl8192u: fixing white space issue
On Tue, Feb 14, 2017 at 11:16:59PM +0530, SIMRAN SINGHAL wrote: > While resending them ...do I have to mention v2. Of course, why wouldn't you? :) thanks, greg k-h
Re: [PATCH v2 04/10] mm, page_alloc: count movable pages when stealing from pageblock
On Fri, Feb 10, 2017 at 06:23:37PM +0100, Vlastimil Babka wrote:
> When stealing pages from pageblock of a different migratetype, we count how
> many free pages were stolen, and change the pageblock's migratetype if more
> than half of the pageblock was free. This might be too conservative, as there
> might be other pages that are not free, but were allocated with the same
> migratetype as our allocation requested.
>
> While we cannot determine the migratetype of allocated pages precisely (at
> least without the page_owner functionality enabled), we can count pages that
> compaction would try to isolate for migration - those are either on LRU or
> __PageMovable(). The rest can be assumed to be MIGRATE_RECLAIMABLE or
> MIGRATE_UNMOVABLE, which we cannot easily distinguish. This counting can be
> done as part of free page stealing with little additional overhead.
>
> The page stealing code is changed so that it considers free pages plus pages
> of the "good" migratetype for the decision whether to change pageblock's
> migratetype.
>
> The result should be more accurate migratetype of pageblocks wrt the actual
> pages in the pageblocks, when stealing from semi-occupied pageblocks. This
> should help the efficiency of page grouping by mobility.
>
> Signed-off-by: Vlastimil Babka
That makes sense to me. I have just one nit about the patch:
> @@ -1981,10 +1994,29 @@ static void steal_suitable_fallback(struct zone
> *zone, struct page *page,
> return;
> }
>
> - pages = move_freepages_block(zone, page, start_type);
> + free_pages = move_freepages_block(zone, page, start_type,
> + &good_pages);
> + /*
> + * good_pages is now the number of movable pages, but if we
> + * want UNMOVABLE or RECLAIMABLE allocation, it's more tricky
> + */
> + if (start_type != MIGRATE_MOVABLE) {
> + /*
> + * If we are falling back to MIGRATE_MOVABLE pageblock,
> + * treat all non-movable pages as good. If it's UNMOVABLE
> + * falling back to RECLAIMABLE or vice versa, be conservative
> + * as we can't distinguish the exact migratetype.
> + */
> + old_block_type = get_pageblock_migratetype(page);
> + if (old_block_type == MIGRATE_MOVABLE)
> + good_pages = pageblock_nr_pages
> + - free_pages - good_pages;
This line had me scratch my head for a while, and I think it's mostly
because of the variable naming and the way the comments are phrased.
Could you use a variable called movable_pages to pass to and be filled
in by move_freepages_block?
And instead of good_pages something like starttype_pages or
alike_pages or st_pages or mt_pages or something, to indicate the
number of pages that are comparable to the allocation's migratetype?
> - /* Claim the whole block if over half of it is free */
> - if (pages >= (1 << (pageblock_order-1)) ||
> + /* Claim the whole block if over half of it is free or good type */
> + if (free_pages + good_pages >= (1 << (pageblock_order-1)) ||
> page_group_by_mobility_disabled)
> set_pageblock_migratetype(page, start_type);
This would then read
if (free_pages + alike_pages ...)
which I think would be more descriptive.
The comment leading the entire section following move_freepages_block
could then say something like "If a sufficient number of pages in the
block are either free or of comparable migratability as our
allocation, claim the whole block." Followed by the caveats of how we
determine this migratibility.
Or maybe even the function. The comment above the function seems out
of date after this patch.
Re: [PATCH V2] audit: log module name on init_module
On 2017-02-14 13:02, Steve Grubb wrote:
> On Monday, February 13, 2017 4:20:55 PM EST Paul Moore wrote:
> > On Sat, Feb 4, 2017 at 1:10 PM, Richard Guy Briggs wrote:
> > > This adds a new auxiliary record MODULE_INIT to the SYSCALL event.
> > >
> > > We get finit_module for free since it made most sense to hook this in to
> > > load_module().
> > >
> > > https://github.com/linux-audit/audit-kernel/issues/7
> > > https://github.com/linux-audit/audit-kernel/wiki/RFE-Module-load-record-fo
> > > rmat
> > Correction for the record:
> >
> > *
> > https://github.com/linux-audit/audit-kernel/wiki/RFE-Module-Load-Record-For
> > mat
> >
> > [NOTE: don't resend please, I'll fix this when merging]
>
> OK. Support was added to user space for this record. While doing this, I
> wondered if we also get this auxiliary record when unloading a module?
I thought of that at the time, which influenced the design and wording.
It is not supported yet, but that should be easier to add.
> -Steve
>
> > > Signed-off-by: Richard Guy Briggs
> > > ---
> > >
> > > include/linux/audit.h | 12
> > > include/uapi/linux/audit.h |1 +
> > > kernel/audit.h |3 +++
> > > kernel/auditsc.c | 14 ++
> > > kernel/module.c|5 -
> > > 5 files changed, 34 insertions(+), 1 deletions(-)
> >
> > This patch looks fine to me, and due to lack of comments I'm going to
> > assume that Jessica is okay with the kernel/module.c portions of this
> > patch. Normally this would be too close to the merge window, but this
> > patch is trivial and since it is new functionality it is unlikely to
> > cause any regressions so I'm going to merge it into audit/next now.
> >
> > > diff --git a/include/linux/audit.h b/include/linux/audit.h
> > > index 2be99b2..aba3a26 100644
> > > --- a/include/linux/audit.h
> > > +++ b/include/linux/audit.h
> > > @@ -360,6 +360,7 @@ extern int __audit_log_bprm_fcaps(struct linux_binprm
> > > *bprm,>
> > > const struct cred *old);
> > >
> > > extern void __audit_log_capset(const struct cred *new, const struct cred
> > > *old); extern void __audit_mmap_fd(int fd, int flags);
> > >
> > > +extern void __audit_log_kern_module(char *name);
> > >
> > > static inline void audit_ipc_obj(struct kern_ipc_perm *ipcp)
> > > {
> > >
> > > @@ -450,6 +451,12 @@ static inline void audit_mmap_fd(int fd, int flags)
> > >
> > > __audit_mmap_fd(fd, flags);
> > >
> > > }
> > >
> > > +static inline void audit_log_kern_module(char *name)
> > > +{
> > > + if (!audit_dummy_context())
> > > + __audit_log_kern_module(name);
> > > +}
> > > +
> > >
> > > extern int audit_n_rules;
> > > extern int audit_signals;
> > > #else /* CONFIG_AUDITSYSCALL */
> > >
> > > @@ -561,6 +568,11 @@ static inline void audit_log_capset(const struct cred
> > > *new,>
> > > { }
> > > static inline void audit_mmap_fd(int fd, int flags)
> > > { }
> > >
> > > +
> > > +static inline void audit_log_kern_module(char *name)
> > > +{
> > > +}
> > > +
> > >
> > > static inline void audit_ptrace(struct task_struct *t)
> > > { }
> > > #define audit_n_rules 0
> > >
> > > diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
> > > index 3f24110..3c02bb2 100644
> > > --- a/include/uapi/linux/audit.h
> > > +++ b/include/uapi/linux/audit.h
> > > @@ -111,6 +111,7 @@
> > >
> > > #define AUDIT_PROCTITLE1327/* Proctitle emit event */
> > > #define AUDIT_FEATURE_CHANGE 1328/* audit log listing feature
> > > changes */ #define AUDIT_REPLACE 1329/* Replace auditd if
> > > this packet unanswerd */>
> > > +#define AUDIT_KERN_MODULE 1330/* Kernel Module events */
> > >
> > > #define AUDIT_AVC 1400/* SE Linux avc denial or grant */
> > > #define AUDIT_SELINUX_ERR 1401/* Internal SE Linux Errors */
> > >
> > > diff --git a/kernel/audit.h b/kernel/audit.h
> > > index 431444c..144b7eb 100644
> > > --- a/kernel/audit.h
> > > +++ b/kernel/audit.h
> > > @@ -199,6 +199,9 @@ struct audit_context {
> > >
> > > struct {
> > >
> > > int argc;
> > >
> > > } execve;
> > >
> > > + struct {
> > > + char*name;
> > > + } module;
> > >
> > > };
> > > int fds[2];
> > > struct audit_proctitle proctitle;
> > >
> > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > > index bb5f504..bde3aac 100644
> > > --- a/kernel/auditsc.c
> > > +++ b/kernel/auditsc.c
> > > @@ -1268,6 +1268,11 @@ static void show_special(struct audit_context
> > > *context, int *call_panic)>
> > > case AUDIT_EXECVE: {
> > >
> > > audit_log_execve_info(context, &ab);
> > > break; }
> > >
> > > + case AUDIT_KERN_MOD
Re: [PATCH] usb: musb: add code comment for clarification
Quoting Greg KH :
On Fri, Feb 10, 2017 at 06:57:41PM -0600, Gustavo A. R. Silva wrote:
Add code comment to make it clear that the fall-through is intentional.
Read the link for more details: https://lkml.org/lkml/2017/2/9/292
Signed-off-by: Gustavo A. R. Silva
---
drivers/usb/musb/musb_core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 892088f..1aec986 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1869,6 +1869,7 @@ static void musb_pm_runtime_check_session(struct musb
*musb)
return;
}
+ /* fall through */
case MUSB_QUIRK_A_DISCONNECT_19:
if (musb->quirk_retries--) {
musb_dbg(musb,
The tabs are all gone from this patch, and it's line-wrapped, making it
impossible to be applied :(
Can you please fix this and resend?
OK. I'll send it shortly.
Thanks
--
Gustavo A. R. Silva
Re: [PATCH v2 05/10] mm, compaction: change migrate_async_suitable() to suitable_migration_source()
On Fri, Feb 10, 2017 at 06:23:38PM +0100, Vlastimil Babka wrote: > Preparation for making the decisions more complex and depending on > compact_control flags. No functional change. > > Signed-off-by: Vlastimil Babka Acked-by: Johannes Weiner
Re: [PATCH] ARM: mvebu: add support for the Linksys WRT1900ACS (Shelby)
Hi Ralph, Imre, On Tue, Feb 14, 2017 at 09:59:17AM +0100, Ralph Sennhauser wrote: > The Linksys WRT1900ACS (Shelby) is another Armada 385 based router in > the Linksys WRT AC Series which got released in October 2015. > > The file armada-385-linksys-shelby.dts is taken from OpenWrt as-is and > originally authored by Imre Kaloz. > > URL: http://tinyurl.com/j8lz83a Could you please change this to: https://github.com/openwrt/openwrt/blob/8466384db1154a107b86bf3ca10b166a21bd81d0/target/linux/mvebu/files/arch/arm/boot/dts/armada-385-linksys-shelby.dts Or, say 'imported from https://github.com/openwrt/openwrt commit 8466384db115 "mvebu: add support for 4.1 and switch over"' or something similar? Other than that, Acked-by: Jason Cooper thx, Jason.
Re: [PATCH 3/4] ptp: use is_visible method to hide unused attributes
On Tue, Feb 14, 2017 at 10:07:47AM -0800, Dmitry Torokhov wrote: > > At first glance, this patch and the next look like nice improvements. > > I don't futz around with sysfs code very often, and so may I ask how > > or whether you tested it? > > I used the hack below. OK, thats fine. I'll be sure and test this here with my i210 which has real pins. Thanks, Richard
Re: [PATCH 3/6] x86/cpu: proc - remove "wp" status line in cpuinfo
On 02/12/17 13:12, Mathias Krause wrote:
> As of commit a5c2a893dbd4 ("x86, 386 removal: Remove
> CONFIG_X86_WP_WORKS_OK") the kernel won't boot if CR0.WP isn't working
> correctly. This makes a process reading this file always see "wp : yes"
> here -- otherwise there would be no process to begin with ;)
>
> As this status line in /proc/cpuinfo serves no purpose for quite some
> time now, get rid of it.
>
> Cc: Borislav Petkov
> Cc: H. Peter Anvin
> Signed-off-by: Mathias Krause
> ---
> arch/x86/kernel/cpu/proc.c |6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/proc.c b/arch/x86/kernel/cpu/proc.c
> index 6df621ae62a7..c6c5217a7980 100644
> --- a/arch/x86/kernel/cpu/proc.c
> +++ b/arch/x86/kernel/cpu/proc.c
> @@ -30,8 +30,7 @@ static void show_cpuinfo_misc(struct seq_file *m, struct
> cpuinfo_x86 *c)
> "coma_bug\t: %s\n"
> "fpu\t\t: %s\n"
> "fpu_exception\t: %s\n"
> -"cpuid level\t: %d\n"
> -"wp\t\t: yes\n",
> +"cpuid level\t: %d\n",
> static_cpu_has_bug(X86_BUG_FDIV) ? "yes" : "no",
> static_cpu_has_bug(X86_BUG_F00F) ? "yes" : "no",
> static_cpu_has_bug(X86_BUG_COMA) ? "yes" : "no",
> @@ -45,8 +44,7 @@ static void show_cpuinfo_misc(struct seq_file *m, struct
> cpuinfo_x86 *c)
> seq_printf(m,
> "fpu\t\t: yes\n"
> "fpu_exception\t: yes\n"
> -"cpuid level\t: %d\n"
> -"wp\t\t: yes\n",
> +"cpuid level\t: %d\n",
> c->cpuid_level);
> }
> #endif
>
Potential userspace breakage, which is why the line was left in the
first place despite its value now being hard-coded. Removing it will
save a whopping 9 bytes of kernel rodata; this is a very small price to
pay for guaranteeing continued compatibility.
Nacked-by: H. Peter Anvin
Re: [PATCH v2 06/10] mm, compaction: add migratetype to compact_control
On Fri, Feb 10, 2017 at 06:23:39PM +0100, Vlastimil Babka wrote: > Preparation patch. We are going to need migratetype at lower layers than > compact_zone() and compact_finished(). > > Signed-off-by: Vlastimil Babka Acked-by: Johannes Weiner
Re: [PATCH 1/2] spi: imx: dynamic burst length adjust for PIO mode
On Wed, Feb 08, 2017 at 03:20:27PM +0900, Jiada Wang wrote:
This looks basically fine, a couple of fairly minor things here:
> + for (i = 0; i < transfer->len / 4; i++) {
> + u8 temp;
> +
> + temp = *(buf + i * 4);
> + *(buf + i * 4) = *(buf + i * 4 + 3);
> + *(buf + i * 4 + 3) = temp;
Should this be using one of the cpu_to_ functions? It's a bit unclear
what the goal is here and if it'll work if the kernel is big endian
(which people do do with i.MX systems IIRC).
> + if (spi_imx->bpw_w == 1)
> + spi_imx_buf_rx_u8(spi_imx);
> + else if (spi_imx->bpw_w == 2)
> + spi_imx_buf_rx_u16(spi_imx);
switch statement please.
> + if (spi_imx->dynamic_burst) {
> + spi_imx->count_index =
> + spi_imx->count > MX51_ECSPI_CTRL_MAX_BURST ?
> + spi_imx->count % MX51_ECSPI_CTRL_MAX_BURST :
> + spi_imx->count % sizeof(u32);
Just write a normal if statement please, it's easier to read.
signature.asc
Description: PGP signature
[PATCH v2] usb: musb: add code comment for clarification
Add code comment to make it clear that the fall-through is intentional.
Read the link for more details: https://lkml.org/lkml/2017/2/9/292
Addresses-Coverity-ID: 1397608
Signed-off-by: Gustavo A. R. Silva
---
Changes in v2:
Fix tabs and line-wrapping in previous patch.
drivers/usb/musb/musb_core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 892088f..d8bae6c 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1869,6 +1869,7 @@ static void musb_pm_runtime_check_session(struct musb
*musb)
return;
}
+ /* fall through */
case MUSB_QUIRK_A_DISCONNECT_19:
if (musb->quirk_retries--) {
musb_dbg(musb,
--
2.5.0
Re: [PATCH 1/6] x86: drop unneded members of struct cpuinfo_x86
On Tue, Feb 14, 2017 at 06:56:22PM +0100, Geert Uytterhoeven wrote: > That's because No, what Mathias said. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
[PATCH v2 1/4] ptp: do not explicitly set drvdata in ptp_clock_register()
We do not need explicitly call dev_set_drvdata(), as it is done for us by device_create(). Acked-by: Richard Cochran Signed-off-by: Dmitry Torokhov --- drivers/ptp/ptp_clock.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/ptp/ptp_clock.c b/drivers/ptp/ptp_clock.c index 9c13381b6966..b4e5e8022c29 100644 --- a/drivers/ptp/ptp_clock.c +++ b/drivers/ptp/ptp_clock.c @@ -227,8 +227,6 @@ struct ptp_clock *ptp_clock_register(struct ptp_clock_info *info, if (IS_ERR(ptp->dev)) goto no_device; - dev_set_drvdata(ptp->dev, ptp); - err = ptp_populate_sysfs(ptp); if (err) goto no_sysfs; -- 2.11.0.483.g087da7b7c-goog
[PATCH v2 0/4] PTP attribute handling cleanup
PTP core was creating some attributes, such as "period" and "fifo", and the entire "pins" attribute group, after creating class deevice, which creates a race for userspace: uevent may arrive before all attributes are created. This series of patches switches PTP to use is_visible() to control visibility of attributes in a group, and device_create_with_groups() to ensure that attributes are created before we notify userspace of a new device. v2: - added Richard's acked-by to patch #1 - removed use of kmalloc_array in favor of kcalloc in patch #2 at Richard's request - added a cover letter v1: - initial patch set Dmitry Torokhov (4): ptp: do not explicitly set drvdata in ptp_clock_register() ptp: use kcalloc when allocating arrays ptp: use is_visible method to hide unused attributes ptp: create "pins" together with the rest of attributes drivers/ptp/ptp_clock.c | 22 +++--- drivers/ptp/ptp_private.h | 7 +- drivers/ptp/ptp_sysfs.c | 167 ++ 3 files changed, 80 insertions(+), 116 deletions(-) Thanks. -- Dmitry
[PATCH v2 3/4] ptp: use is_visible method to hide unused attributes
Instead of creating selected attributes after the device is created (and
after userspace potentially seen uevent), lets use attribute group
is_visible() method to control which attributes are shown. This will allow
us to create all attributes (except "pins" group, which will be taken care
of later) before userspace gets notified about new ptp class device.
Signed-off-by: Dmitry Torokhov
---
drivers/ptp/ptp_sysfs.c | 125 +---
1 file changed, 55 insertions(+), 70 deletions(-)
diff --git a/drivers/ptp/ptp_sysfs.c b/drivers/ptp/ptp_sysfs.c
index 27cd46ab5e32..426e42c51df4 100644
--- a/drivers/ptp/ptp_sysfs.c
+++ b/drivers/ptp/ptp_sysfs.c
@@ -46,27 +46,6 @@ PTP_SHOW_INT(n_periodic_outputs, n_per_out);
PTP_SHOW_INT(n_programmable_pins, n_pins);
PTP_SHOW_INT(pps_available, pps);
-static struct attribute *ptp_attrs[] = {
- &dev_attr_clock_name.attr,
- &dev_attr_max_adjustment.attr,
- &dev_attr_n_alarms.attr,
- &dev_attr_n_external_timestamps.attr,
- &dev_attr_n_periodic_outputs.attr,
- &dev_attr_n_programmable_pins.attr,
- &dev_attr_pps_available.attr,
- NULL,
-};
-
-static const struct attribute_group ptp_group = {
- .attrs = ptp_attrs,
-};
-
-const struct attribute_group *ptp_groups[] = {
- &ptp_group,
- NULL,
-};
-
-
static ssize_t extts_enable_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
@@ -91,6 +70,7 @@ static ssize_t extts_enable_store(struct device *dev,
out:
return err;
}
+static DEVICE_ATTR(extts_enable, 0220, NULL, extts_enable_store);
static ssize_t extts_fifo_show(struct device *dev,
struct device_attribute *attr, char *page)
@@ -124,6 +104,7 @@ static ssize_t extts_fifo_show(struct device *dev,
mutex_unlock(&ptp->tsevq_mux);
return cnt;
}
+static DEVICE_ATTR(fifo, 0444, extts_fifo_show, NULL);
static ssize_t period_store(struct device *dev,
struct device_attribute *attr,
@@ -151,6 +132,7 @@ static ssize_t period_store(struct device *dev,
out:
return err;
}
+static DEVICE_ATTR(period, 0220, NULL, period_store);
static ssize_t pps_enable_store(struct device *dev,
struct device_attribute *attr,
@@ -177,6 +159,57 @@ static ssize_t pps_enable_store(struct device *dev,
out:
return err;
}
+static DEVICE_ATTR(pps_enable, 0220, NULL, pps_enable_store);
+
+static struct attribute *ptp_attrs[] = {
+ &dev_attr_clock_name.attr,
+
+ &dev_attr_max_adjustment.attr,
+ &dev_attr_n_alarms.attr,
+ &dev_attr_n_external_timestamps.attr,
+ &dev_attr_n_periodic_outputs.attr,
+ &dev_attr_n_programmable_pins.attr,
+ &dev_attr_pps_available.attr,
+
+ &dev_attr_extts_enable.attr,
+ &dev_attr_fifo.attr,
+ &dev_attr_period.attr,
+ &dev_attr_pps_enable.attr,
+ NULL
+};
+
+static umode_t ptp_is_attribute_visible(struct kobject *kobj,
+ struct attribute *attr, int n)
+{
+ struct device *dev = kobj_to_dev(kobj);
+ struct ptp_clock *ptp = dev_get_drvdata(dev);
+ struct ptp_clock_info *info = ptp->info;
+ umode_t mode = attr->mode;
+
+ if (attr == &dev_attr_extts_enable.attr ||
+ attr == &dev_attr_fifo.attr) {
+ if (!info->n_ext_ts)
+ mode = 0;
+ } else if (attr == &dev_attr_period.attr) {
+ if (!info->n_per_out)
+ mode = 0;
+ } else if (attr == &dev_attr_pps_enable.attr) {
+ if (!info->pps)
+ mode = 0;
+ }
+
+ return mode;
+}
+
+static const struct attribute_group ptp_group = {
+ .is_visible = ptp_is_attribute_visible,
+ .attrs = ptp_attrs,
+};
+
+const struct attribute_group *ptp_groups[] = {
+ &ptp_group,
+ NULL
+};
static int ptp_pin_name2index(struct ptp_clock *ptp, const char *name)
{
@@ -235,26 +268,11 @@ static ssize_t ptp_pin_store(struct device *dev, struct
device_attribute *attr,
return count;
}
-static DEVICE_ATTR(extts_enable, 0220, NULL, extts_enable_store);
-static DEVICE_ATTR(fifo, 0444, extts_fifo_show, NULL);
-static DEVICE_ATTR(period, 0220, NULL, period_store);
-static DEVICE_ATTR(pps_enable, 0220, NULL, pps_enable_store);
-
int ptp_cleanup_sysfs(struct ptp_clock *ptp)
{
struct device *dev = ptp->dev;
struct ptp_clock_info *info = ptp->info;
- if (info->n_ext_ts) {
- device_remove_file(dev, &dev_attr_extts_enable);
- device_remove_file(dev, &dev_attr_fifo);
- }
- if (info->n_per_out)
- device_remove_file(dev, &dev_attr_period);
-
- if (info->pps)
- device_remove_file(dev, &dev_attr_pps_enable);
-
[PATCH v2 2/4] ptp: use kcalloc when allocating arrays
kcalloc is more semantically correct when allocating arrays of objects, and overflow-safe. Signed-off-by: Dmitry Torokhov --- drivers/ptp/ptp_sysfs.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/ptp/ptp_sysfs.c b/drivers/ptp/ptp_sysfs.c index 53d43954a974..27cd46ab5e32 100644 --- a/drivers/ptp/ptp_sysfs.c +++ b/drivers/ptp/ptp_sysfs.c @@ -269,13 +269,12 @@ static int ptp_populate_pins(struct ptp_clock *ptp) struct ptp_clock_info *info = ptp->info; int err = -ENOMEM, i, n_pins = info->n_pins; - ptp->pin_dev_attr = kzalloc(n_pins * sizeof(*ptp->pin_dev_attr), + ptp->pin_dev_attr = kcalloc(n_pins, sizeof(*ptp->pin_dev_attr), GFP_KERNEL); if (!ptp->pin_dev_attr) goto no_dev_attr; - ptp->pin_attr = kzalloc((1 + n_pins) * sizeof(struct attribute *), - GFP_KERNEL); + ptp->pin_attr = kcalloc(1 + n_pins, sizeof(*ptp->pin_attr), GFP_KERNEL); if (!ptp->pin_attr) goto no_pin_attr; -- 2.11.0.483.g087da7b7c-goog
perf pmu: clang points out: address of array 'alias->unit' will always evaluate to 'true'
util/pmu.c:948:28: error: address of array 'alias->unit' will always evaluate to 'true' [-Werror,-Wpointer-bool-conversion] if ((info->unit && alias->unit) || ~~ ~~~^~~~ util/pmu.c:953:13: error: address of array 'alias->unit' will always evaluate to 'true' [-Werror,-Wpointer-bool-conversion] if (alias->unit) ~~ ~~~^~~~ 2 errors generated. So, is this test about having something on that alias->unit array? I.e. should this suffice? [acme@jouet linux]$ cat clang.patch diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c index 82a654dec666..49bfee0e3d9e 100644 --- a/tools/perf/util/pmu.c +++ b/tools/perf/util/pmu.c @@ -945,12 +945,12 @@ static int check_info_data(struct perf_pmu_alias *alias, * define unit, scale and snapshot, fail * if there's more than one. */ - if ((info->unit && alias->unit) || + if ((info->unit && alias->unit[0]) || (info->scale && alias->scale) || (info->snapshot && alias->snapshot)) return -EINVAL; - if (alias->unit) + if (alias->unit[0]) info->unit = alias->unit; if (alias->scale) [acme@jouet linux]$
Re: [PATCH v2] usb: musb: add code comment for clarification
On Tue, Feb 14, 2017 at 12:20:39PM -0600, Gustavo A. R. Silva wrote: > Add code comment to make it clear that the fall-through is intentional. > Read the link for more details: https://lkml.org/lkml/2017/2/9/292 > > Addresses-Coverity-ID: 1397608 > Signed-off-by: Gustavo A. R. Silva > --- > Changes in v2: > Fix tabs and line-wrapping in previous patch. Thanks for this. Bin, I've applied this to my tree so it makes it into 4.11-rc1. greg k-h
Re: [PATCH] crypto: cavium: fix Kconfig dependencies
On 02/14/17 09:09, David Daney wrote: > On 02/14/2017 09:07 AM, Arnd Bergmann wrote: >> The driver fails to build if MSI support is disabled: >> >> In file included from >> /git/arm-soc/drivers/crypto/cavium/cpt/cptpf_main.c:18:0: >> drivers/crypto/cavium/cpt/cptpf.h:57:20: error: array type has incomplete >> element type 'struct msix_entry' >> struct msix_entry msix_entries[CPT_PF_MSIX_VECTORS]; >> ^~~~ >> drivers/crypto/cavium/cpt/cptpf_main.c: In function 'cpt_enable_msix': >> drivers/crypto/cavium/cpt/cptpf_main.c:344:8: error: implicit declaration of >> function 'pci_enable_msix';did you mean 'cpt_enable_msix'? >> [-Werror=implicit-function-declaration] >> >> On the other hand, it doesn't seem to have any build dependency on >> ARCH_THUNDER, >> so let's allow compile-testing to catch this kind of problem more easily. >> The 64-bit dependency is needed for the use of readq/writeq. >> >> Signed-off-by: Arnd Bergmann >> --- >> drivers/crypto/cavium/cpt/Kconfig | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/crypto/cavium/cpt/Kconfig >> b/drivers/crypto/cavium/cpt/Kconfig >> index 247f1cbbefc1..cbd51b1aa046 100644 >> --- a/drivers/crypto/cavium/cpt/Kconfig >> +++ b/drivers/crypto/cavium/cpt/Kconfig >> @@ -7,7 +7,8 @@ config CRYPTO_DEV_CPT >> >> config CAVIUM_CPT >> tristate "Cavium Cryptographic Accelerator driver" >> -depends on ARCH_THUNDER >> +depends on ARCH_THUNDER || COMPILE_TEST >> +depends on PCI_MSI && 64BIT > > > Perhaps we should select PCI and PCI_MSI instead. > > These systems cannot function without those. Then the "depends" (and hence the patch) is correct. A driver should not enable all of PCI if it is disabled for some other reason. >> select CRYPTO_DEV_CPT >> help >>Support for Cavium CPT block found in octeon-tx series of >> > -- ~Randy
Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE
>> >> So that is useful information that should have been in the Changelog. >> >> OK, can you respin this patch with adjusted Changelog and taking Mike's >> feedback? >> > Yes, i will prepare a patch accordingly, no problem. > >> >> Also, I worry about the effects of this on !PREEMPT kernels, the first >> hunk (which explicitly states is about latency) should be under >> CONFIG_PREEMPT to match the similar case we already have in >> detach_tasks(). >> >> But your second hunk, which ignores the actual load of tasks in favour >> of just moving _something_ already, is utterly dangerous if not coupled >> with these two other conditions, so arguably that too should be under >> CONFIG_PREEMPT. >> > I see your point. Will round both with CONFIG_PREEMPT. > I have upload a new patch, please find it here: https://lkml.org/lkml/2017/2/14/334 -- Uladzislau Rezki
Re: Regression in next with use printk_safe buffers in printk
On Wed, Feb 15, 2017 at 01:56:45AM +0900, Sergey Senozhatsky wrote: > that crossed my mind, but I kinda assumed that we do printk() from > under tk_core using sched fair, and rt_runtime_lock is from sched rt. That's all true; lockdep doesn't care :-) All it knows is that at some point those locks nest.
Re: [PATCH] crypto: cavium: fix Kconfig dependencies
On 02/14/2017 10:26 AM, Randy Dunlap wrote: On 02/14/17 09:09, David Daney wrote: On 02/14/2017 09:07 AM, Arnd Bergmann wrote: The driver fails to build if MSI support is disabled: In file included from /git/arm-soc/drivers/crypto/cavium/cpt/cptpf_main.c:18:0: drivers/crypto/cavium/cpt/cptpf.h:57:20: error: array type has incomplete element type 'struct msix_entry' struct msix_entry msix_entries[CPT_PF_MSIX_VECTORS]; ^~~~ drivers/crypto/cavium/cpt/cptpf_main.c: In function 'cpt_enable_msix': drivers/crypto/cavium/cpt/cptpf_main.c:344:8: error: implicit declaration of function 'pci_enable_msix';did you mean 'cpt_enable_msix'? [-Werror=implicit-function-declaration] On the other hand, it doesn't seem to have any build dependency on ARCH_THUNDER, so let's allow compile-testing to catch this kind of problem more easily. The 64-bit dependency is needed for the use of readq/writeq. Signed-off-by: Arnd Bergmann --- drivers/crypto/cavium/cpt/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/crypto/cavium/cpt/Kconfig b/drivers/crypto/cavium/cpt/Kconfig index 247f1cbbefc1..cbd51b1aa046 100644 --- a/drivers/crypto/cavium/cpt/Kconfig +++ b/drivers/crypto/cavium/cpt/Kconfig @@ -7,7 +7,8 @@ config CRYPTO_DEV_CPT config CAVIUM_CPT tristate "Cavium Cryptographic Accelerator driver" -depends on ARCH_THUNDER +depends on ARCH_THUNDER || COMPILE_TEST +depends on PCI_MSI && 64BIT Perhaps we should select PCI and PCI_MSI instead. These systems cannot function without those. Then the "depends" (and hence the patch) is correct. A driver should not enable all of PCI if it is disabled for some other reason. I see your point. In that case, this patch: Acked-by: David Daney select CRYPTO_DEV_CPT help Support for Cavium CPT block found in octeon-tx series of
Re: [PATCH 3/6] x86/cpu: proc - remove "wp" status line in cpuinfo
On Tue, Feb 14, 2017 at 10:13:22AM -0800, H. Peter Anvin wrote: > Potential userspace breakage, which is why the line was left in the We could keep the string in /proc/cpuinfo for compatibility but kill the cpuinfo_x86 members. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH 1/2] perf/x86/intel/pt: Fail event scheduling on conflict with VMX
On Tue, Feb 14, 2017 at 07:21:34PM +0200, Alexander Shishkin wrote: > Peter Zijlstra writes: > > > On Tue, Feb 14, 2017 at 06:17:30PM +0200, Alexander Shishkin wrote: > >> This is called by pmu::add(), which checks hw.state afterwards and if it > >> finds HES_STOPPED, it returns an error, which event_sched_in() captures > >> and keeps the event in INACTIVE state. Should I add a comment about it? > > > > Egads... so what if ->add() succeeds but we then hit this on > > ->stop()/->start() due to throttle or period adjust? > > It will hang there with hw.state==PERF_HES_STOPPED till the next > sched_out. But that will be the case anyway if VMXON kicks in while PT > is running. Right, so I question the whole 'lets not schedule PT when VMX' premise, it leads to inconsistencies all over. How about we treat it like ->add() succeeded and VMX simply results in no output. Esp. when you then emit 'fake' data into/from a vmlaunch/vmresume instruction.
Re: [PATCH V2] audit: log module name on init_module
On Tue, Feb 14, 2017 at 1:11 PM, Richard Guy Briggs wrote: > On 2017-02-14 13:02, Steve Grubb wrote: >> On Monday, February 13, 2017 4:20:55 PM EST Paul Moore wrote: >> > On Sat, Feb 4, 2017 at 1:10 PM, Richard Guy Briggs wrote: >> > > This adds a new auxiliary record MODULE_INIT to the SYSCALL event. >> > > >> > > We get finit_module for free since it made most sense to hook this in to >> > > load_module(). >> > > >> > > https://github.com/linux-audit/audit-kernel/issues/7 >> > > https://github.com/linux-audit/audit-kernel/wiki/RFE-Module-load-record-fo >> > > rmat >> > Correction for the record: >> > >> > * >> > https://github.com/linux-audit/audit-kernel/wiki/RFE-Module-Load-Record-For >> > mat >> > >> > [NOTE: don't resend please, I'll fix this when merging] >> >> OK. Support was added to user space for this record. While doing this, I >> wondered if we also get this auxiliary record when unloading a module? > > I thought of that at the time, which influenced the design and wording. > It is not supported yet, but that should be easier to add. As a reminder, this is currently in audit/next and will be going up to Linus next week during the merge window, if you want to change this record in some backwards incompatible way, e.g. putting a field before "name", you've got until the end of this week to figure that out. -- paul moore www.paul-moore.com
Re: [PATCH v3 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP
On Tue, 14 Feb 2017, Boris Ostrovsky wrote:
> On 02/13/2017 12:03 PM, Paul Durrant wrote:
> > Recently a new dm_op[1] hypercall was added to Xen to provide a mechanism
> > for restricting device emulators (such as QEMU) to a limited set of
> > hypervisor operations, and being able to audit those operations in the
> > kernel of the domain in which they run.
> >
> > This patch adds IOCTL_PRIVCMD_DM_OP as gateway for __HYPERVISOR_dm_op.
> >
> > NOTE: There is no requirement for user-space code to bounce data through
> > locked memory buffers (as with IOCTL_PRIVCMD_HYPERCALL) since
> > privcmd has enough information to lock the original buffers
> > directly.
> >
> > [1] http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=524a98c2
> >
> > Signed-off-by: Paul Durrant
>
>
> Stefano,
>
> Are you OK with ARM changes?
Yes:
Acked-by: Stefano Stabellini
Thanks for CC'ing me, I missed the patch.
>
>
> > ---
> > Cc: Boris Ostrovsky
> > Cc: Juergen Gross
> >
> > v3:
> > - Add module parameters for max number of dm_op buffers and max buffer
> > size
> > - Fix arm build
> > - Fix commit comment to reflect re-worked patch
> >
> > v2:
> > - Lock the user pages rather than bouncing through kernel memory
> > ---
> > arch/arm/xen/enlighten.c | 1 +
> > arch/arm/xen/hypercall.S | 1 +
> > arch/arm64/xen/hypercall.S | 1 +
> > arch/x86/include/asm/xen/hypercall.h | 7 ++
> > drivers/xen/privcmd.c| 139
> > +++
> > include/uapi/xen/privcmd.h | 13
> > include/xen/arm/hypercall.h | 1 +
> > include/xen/interface/hvm/dm_op.h| 32
> > include/xen/interface/xen.h | 1 +
> > 9 files changed, 196 insertions(+)
> > create mode 100644 include/xen/interface/hvm/dm_op.h
> >
> > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> > index 11d9f28..81e3217 100644
> > --- a/arch/arm/xen/enlighten.c
> > +++ b/arch/arm/xen/enlighten.c
> > @@ -457,4 +457,5 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
> > EXPORT_SYMBOL_GPL(HYPERVISOR_platform_op);
> > EXPORT_SYMBOL_GPL(HYPERVISOR_multicall);
> > EXPORT_SYMBOL_GPL(HYPERVISOR_vm_assist);
> > +EXPORT_SYMBOL_GPL(HYPERVISOR_dm_op);
> > EXPORT_SYMBOL_GPL(privcmd_call);
> > diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
> > index a648dfc..b0b80c0 100644
> > --- a/arch/arm/xen/hypercall.S
> > +++ b/arch/arm/xen/hypercall.S
> > @@ -92,6 +92,7 @@ HYPERCALL1(tmem_op);
> > HYPERCALL1(platform_op_raw);
> > HYPERCALL2(multicall);
> > HYPERCALL2(vm_assist);
> > +HYPERCALL3(dm_op);
> >
> > ENTRY(privcmd_call)
> > stmdb sp!, {r4}
> > diff --git a/arch/arm64/xen/hypercall.S b/arch/arm64/xen/hypercall.S
> > index 947830a..401ceb7 100644
> > --- a/arch/arm64/xen/hypercall.S
> > +++ b/arch/arm64/xen/hypercall.S
> > @@ -84,6 +84,7 @@ HYPERCALL1(tmem_op);
> > HYPERCALL1(platform_op_raw);
> > HYPERCALL2(multicall);
> > HYPERCALL2(vm_assist);
> > +HYPERCALL3(dm_op);
> >
> > ENTRY(privcmd_call)
> > mov x16, x0
> > diff --git a/arch/x86/include/asm/xen/hypercall.h
> > b/arch/x86/include/asm/xen/hypercall.h
> > index a12a047..f6d20f6 100644
> > --- a/arch/x86/include/asm/xen/hypercall.h
> > +++ b/arch/x86/include/asm/xen/hypercall.h
> > @@ -472,6 +472,13 @@ HYPERVISOR_xenpmu_op(unsigned int op, void *arg)
> > return _hypercall2(int, xenpmu_op, op, arg);
> > }
> >
> > +static inline int
> > +HYPERVISOR_dm_op(
> > + domid_t dom, unsigned int nr_bufs, void *bufs)
> > +{
> > + return _hypercall3(int, dm_op, dom, nr_bufs, bufs);
> > +}
> > +
> > static inline void
> > MULTI_fpu_taskswitch(struct multicall_entry *mcl, int set)
> > {
> > diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> > index 5e5c7ae..a33f17e 100644
> > --- a/drivers/xen/privcmd.c
> > +++ b/drivers/xen/privcmd.c
> > @@ -22,6 +22,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> > #include
> > @@ -32,6 +33,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -43,6 +45,17 @@ MODULE_LICENSE("GPL");
> >
> > #define PRIV_VMA_LOCKED ((void *)1)
> >
> > +unsigned int privcmd_dm_op_max_num = 16;
> > +module_param_named(dm_op_max_nr_bufs, privcmd_dm_op_max_num, uint, 0644);
> > +MODULE_PARM_DESC(dm_op_max_nr_bufs,
> > +"Maximum number of buffers per dm_op hypercall");
> > +
> > +unsigned int privcmd_dm_op_buf_max_size = XEN_PAGE_SIZE;
> > +module_param_named(dm_op_buf_max_size, privcmd_dm_op_buf_max_size, uint,
> > + 0644);
> > +MODULE_PARM_DESC(dm_op_buf_max_size,
> > +"Maximum size of a dm_op hypercall buffer");
> > +
> > static int privcmd_vma_range_is_mapped(
> > struct vm_area_struct *vma,
> > unsigned long addr,
> > @@ -548,6 +561,128 @@ static long privcmd_ioctl_mmap_batch(void __user
> > *udata, int version)
> > goto out;
> > }
[PATCHv5 1/5] x86/mm: introduce arch_rnd() to compute 32/64 mmap rnd
To fix 32-bit mmap() syscall returning pointer higher than 4Gb in
64-bit binaries, two mmap bases will be used: one for mapping with
32-bit syscalls and another for 64-bit syscall.
To correctly place those two bases, introduce arch_rnd() function,
which will return the random factor independently of mmap_is_ia32().
Suggested-by: Thomas Gleixner
Signed-off-by: Dmitry Safonov
---
arch/x86/mm/mmap.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/arch/x86/mm/mmap.c b/arch/x86/mm/mmap.c
index d2dc0438d654..9f3ac019e51c 100644
--- a/arch/x86/mm/mmap.c
+++ b/arch/x86/mm/mmap.c
@@ -54,6 +54,14 @@ static unsigned long stack_maxrandom_size(void)
#define MIN_GAP (128*1024*1024UL + stack_maxrandom_size())
#define MAX_GAP (TASK_SIZE/6*5)
+#ifdef CONFIG_64BIT
+# define mmap32_rnd_bits mmap_rnd_compat_bits
+# define mmap64_rnd_bits mmap_rnd_bits
+#else
+# define mmap32_rnd_bits mmap_rnd_bits
+# define mmap64_rnd_bits mmap_rnd_bits
+#endif
+
static int mmap_is_legacy(void)
{
if (current->personality & ADDR_COMPAT_LAYOUT)
@@ -65,20 +73,14 @@ static int mmap_is_legacy(void)
return sysctl_legacy_va_layout;
}
-unsigned long arch_mmap_rnd(void)
+static unsigned long arch_rnd(unsigned int rndbits)
{
- unsigned long rnd;
-
- if (mmap_is_ia32())
-#ifdef CONFIG_COMPAT
- rnd = get_random_long() & ((1UL << mmap_rnd_compat_bits) - 1);
-#else
- rnd = get_random_long() & ((1UL << mmap_rnd_bits) - 1);
-#endif
- else
- rnd = get_random_long() & ((1UL << mmap_rnd_bits) - 1);
+ return (get_random_long() & ((1UL << rndbits) - 1)) << PAGE_SHIFT;
+}
- return rnd << PAGE_SHIFT;
+unsigned long arch_mmap_rnd(void)
+{
+ return arch_rnd(mmap_is_ia32() ? mmap32_rnd_bits : mmap64_rnd_bits);
}
static unsigned long mmap_base(unsigned long rnd)
--
2.11.1
[PATCHv5 3/5] x86/mm: introduce mmap_compat_base for 32-bit mmap()
mmap() uses base address, from which it starts to look for a free space
for allocation. At this moment there is one mm->mmap_base, which is
calculated during exec(). The address depends on task's size, set rlimit
for stack, ASLR randomization. As task size and number of random bits
differ between 64 and 32 bit applications, calculated mmap_base will
be valid only for the same bitness.
That means e.g., that calculated mmap_base for ELF64 lies upper than
4Gb, which results in bug that 32-bit mmap() syscall will start to
search for a free address over 32-bit address space and returns only
lower 4-bytes of allocated mapping.
As 64-bit applications can do 32-bit syscalls and vice-versa, we need
to correctly chose mmap_base address for syscalls of different bitness.
For this purpose introduce mmap_compat_base and mmap_compat_legacy_base,
use them accordingly in top-down and bottom-up allocations in 32-bit
syscalls, use existed bases mmap_base and mmap_legacy_base for 64-bit
syscalls.
That means that each application on x86_64 will have now two bases
(or four if count legacy bases also) which are calculated on application
exec(). I guess we can relax the calculation of bases until first mmap()
call, but don't think it's worth.
Signed-off-by: Dmitry Safonov
---
arch/Kconfig | 7 +++
arch/x86/Kconfig | 1 +
arch/x86/include/asm/elf.h | 3 +++
arch/x86/kernel/sys_x86_64.c | 23 +++
arch/x86/mm/mmap.c | 41 -
include/linux/mm_types.h | 5 +
6 files changed, 63 insertions(+), 17 deletions(-)
diff --git a/arch/Kconfig b/arch/Kconfig
index 99839c23d453..cfb2fbf3f21c 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -671,6 +671,13 @@ config ARCH_MMAP_RND_COMPAT_BITS
This value can be changed after boot using the
/proc/sys/vm/mmap_rnd_compat_bits tunable
+config HAVE_ARCH_COMPAT_MMAP_BASES
+ bool
+ help
+ This allows 64bit applications to invoke 32-bit mmap() syscall
+ and vice-versa 32-bit applications to call 64-bit mmap().
+ Required for applications doing different bitness syscalls.
+
config HAVE_COPY_THREAD_TLS
bool
help
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index e487493bbd47..b3acb836567a 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -102,6 +102,7 @@ config X86
select HAVE_ARCH_KMEMCHECK
select HAVE_ARCH_MMAP_RND_BITS if MMU
select HAVE_ARCH_MMAP_RND_COMPAT_BITS if MMU && COMPAT
+ select HAVE_ARCH_COMPAT_MMAP_BASES if MMU && COMPAT
select HAVE_ARCH_SECCOMP_FILTER
select HAVE_ARCH_TRACEHOOK
select HAVE_ARCH_TRANSPARENT_HUGEPAGE
diff --git a/arch/x86/include/asm/elf.h b/arch/x86/include/asm/elf.h
index 8aedc2a4d48c..eb9171f172d9 100644
--- a/arch/x86/include/asm/elf.h
+++ b/arch/x86/include/asm/elf.h
@@ -294,6 +294,9 @@ static inline int mmap_is_ia32(void)
test_thread_flag(TIF_ADDR32));
}
+extern unsigned long tasksize_32bit(void);
+extern unsigned long tasksize_64bit(void);
+
#ifdef CONFIG_X86_32
#define __STACK_RND_MASK(is32bit) (0x7ff)
diff --git a/arch/x86/kernel/sys_x86_64.c b/arch/x86/kernel/sys_x86_64.c
index a55ed63b9f91..16b43dbe78b1 100644
--- a/arch/x86/kernel/sys_x86_64.c
+++ b/arch/x86/kernel/sys_x86_64.c
@@ -16,6 +16,8 @@
#include
#include
+#include
+#include
#include
#include
@@ -97,6 +99,18 @@ SYSCALL_DEFINE6(mmap, unsigned long, addr, unsigned long,
len,
return error;
}
+static unsigned long get_mmap_base(int is_legacy)
+{
+ struct mm_struct *mm = current->mm;
+
+#ifdef CONFIG_HAVE_ARCH_COMPAT_MMAP_BASES
+ if (in_compat_syscall())
+ return is_legacy ? mm->mmap_compat_legacy_base
+: mm->mmap_compat_base;
+#endif
+ return is_legacy ? mm->mmap_legacy_base : mm->mmap_base;
+}
+
static void find_start_end(unsigned long flags, unsigned long *begin,
unsigned long *end)
{
@@ -113,10 +127,11 @@ static void find_start_end(unsigned long flags, unsigned
long *begin,
if (current->flags & PF_RANDOMIZE) {
*begin = randomize_page(*begin, 0x0200);
}
- } else {
- *begin = current->mm->mmap_legacy_base;
- *end = TASK_SIZE;
+ return;
}
+
+ *begin = get_mmap_base(1);
+ *end= in_compat_syscall() ? tasksize_32bit() : tasksize_64bit();
}
unsigned long
@@ -190,7 +205,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const
unsigned long addr0,
info.flags = VM_UNMAPPED_AREA_TOPDOWN;
info.length = len;
info.low_limit = PAGE_SIZE;
- info.high_limit = mm->mmap_base;
+ info.high_limit = get_mmap_base(0);
info.align_mask = 0;
info.align_offset = pgoff << PAGE_SHIFT;
if (filp) {
diff --git a/arch/x86/mm/mmap.c b/ar
[PATCHv5 5/5] selftests/x86: add test for 32-bit mmap() return addr
This test calls 32-bit mmap() through int 0x80 and checks /proc/self/maps
for allocated VMA's address - it should be downer than 4 Gb. Just
accessing allocated with mmap pointer will not work, as we could have
some VMA placed on the same address as lower 4 bytes of the new mapping.
As allocation is top-down by default (unless legacy personality was set),
we can expect that mmap() will allocate memory over 4Gb if mmap_base
has been computed not correctly.
On failure it prints:
[NOTE] Allocated mmap 0x6f36a000, sized 0x40
[NOTE] New mapping appeared: 0x7f936f36a000
[FAIL] Found VMA [0x7f936f36a000, 0x7f936f76a000] in maps file, that was
allocated with compat syscall
Cc: Shuah Khan
Cc: linux-kselft...@vger.kernel.org
Signed-off-by: Dmitry Safonov
---
tools/testing/selftests/x86/Makefile | 2 +-
tools/testing/selftests/x86/test_compat_mmap.c | 208 +
2 files changed, 209 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/x86/test_compat_mmap.c
diff --git a/tools/testing/selftests/x86/Makefile
b/tools/testing/selftests/x86/Makefile
index 8c1cb423cfe6..9c3e746a6064 100644
--- a/tools/testing/selftests/x86/Makefile
+++ b/tools/testing/selftests/x86/Makefile
@@ -10,7 +10,7 @@ TARGETS_C_BOTHBITS := single_step_syscall sysret_ss_attrs
syscall_nt ptrace_sysc
TARGETS_C_32BIT_ONLY := entry_from_vm86 syscall_arg_fault test_syscall_vdso
unwind_vdso \
test_FCMOV test_FCOMI test_FISTTP \
vdso_restorer
-TARGETS_C_64BIT_ONLY := fsgsbase
+TARGETS_C_64BIT_ONLY := fsgsbase test_compat_mmap
TARGETS_C_32BIT_ALL := $(TARGETS_C_BOTHBITS) $(TARGETS_C_32BIT_ONLY)
TARGETS_C_64BIT_ALL := $(TARGETS_C_BOTHBITS) $(TARGETS_C_64BIT_ONLY)
diff --git a/tools/testing/selftests/x86/test_compat_mmap.c
b/tools/testing/selftests/x86/test_compat_mmap.c
new file mode 100644
index ..245d9407653e
--- /dev/null
+++ b/tools/testing/selftests/x86/test_compat_mmap.c
@@ -0,0 +1,208 @@
+/*
+ * Check that compat 32-bit mmap() returns address < 4Gb on 64-bit.
+ *
+ * Copyright (c) 2017 Dmitry Safonov (Virtuozzo)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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
+
+#define PAGE_SIZE 4096
+#define MMAP_SIZE (PAGE_SIZE*1024)
+#define MAX_VMAS 50
+#define BUF_SIZE 1024
+
+#ifndef __NR32_mmap2
+#define __NR32_mmap2 192
+#endif
+
+struct syscall_args32 {
+ uint32_t nr, arg0, arg1, arg2, arg3, arg4, arg5;
+};
+
+static void do_full_int80(struct syscall_args32 *args)
+{
+ asm volatile ("int $0x80"
+ : "+a" (args->nr),
+ "+b" (args->arg0), "+c" (args->arg1), "+d" (args->arg2),
+ "+S" (args->arg3), "+D" (args->arg4),
+ "+rbp" (args->arg5)
+ : : "r8", "r9", "r10", "r11");
+}
+
+void *mmap2(void *addr, size_t len, int prot, int flags,
+ int fildes, off_t off)
+{
+ struct syscall_args32 s;
+
+ s.nr= __NR32_mmap2;
+ s.arg0 = (uint32_t)(uintptr_t)addr;
+ s.arg1 = (uint32_t)len;
+ s.arg2 = prot;
+ s.arg3 = flags;
+ s.arg4 = fildes;
+ s.arg5 = (uint32_t)off;
+
+ do_full_int80(&s);
+
+ return (void *)(uintptr_t)s.nr;
+}
+
+struct vm_area {
+ unsigned long start;
+ unsigned long end;
+};
+
+static struct vm_area vmas_before_mmap[MAX_VMAS];
+static struct vm_area vmas_after_mmap[MAX_VMAS];
+
+static char buf[BUF_SIZE];
+
+int parse_maps(struct vm_area *vmas)
+{
+ FILE *maps;
+ int i;
+
+ maps = fopen("/proc/self/maps", "r");
+ if (maps == NULL) {
+ printf("[ERROR]\tFailed to open maps file: %m\n");
+ return -1;
+ }
+
+ for (i = 0; i < MAX_VMAS; i++) {
+ struct vm_area *v = &vmas[i];
+ char *end;
+
+ if (fgets(buf, BUF_SIZE, maps) == NULL)
+ break;
+
+ v->start = strtoul(buf, &end, 16);
+ v->end = strtoul(end + 1, NULL, 16);
+ //printf("[NOTE]\tVMA: [%#lx, %#lx]\n", v->start, v->end);
+ }
+
+ if (i == MAX_VMAS) {
+ printf("[ERROR]\tNumber of VMAs is bigger than reserved array's
size\n");
+ return -1;
+ }
+
+ if (fclose(maps)) {
+ printf("[ERROR]\tFailed to close maps file: %m\n");
+ return -1;
+ }
+ return 0;
+}
+
+int compare_vmas(struct vm_area *vmax, struct vm_area *vmay)
+{
+ if (vmax-
[PATCHv5 0/5] Fix compatible mmap() return pointer over 4Gb
There are a couple of fixes related to x86 mmap():
o 1-2 are just preparation to introduce new mmap bases
o 3 fixes 32-bit syscall returning address over 4Gb in applications,
launched from 64-bit binaries. This is done by introducing new bases:
mmap_compat_base and mmap_compat_legacy_base.
Those bases are separated from 64-bit ones, which allows to use
mmap base according to bitness of the syscall.
Which makes the behavior of 32-bit syscalls the same independently
of launched binary's bitness (the same for 64-bit syscalls).
It also makes possible to allocate with 64-bit mmap() address higher
than 4Gb in compat ELFs - that may be used when 4Gb is not enough or
with MAP_FIXED for hiding that mapping from 32-bit address space.
o 4 fixes behavior of MAP_32BIT - at this moment it's related
to the bitness of executed binary, not of the syscall.
o 5 is a selftest to check that 32-bit mmap() does return 32-bit
pointer.
Changes since v4 (Thomas's review):
- rewrote changelogs (so they should be readable by humans also)
- made code simpler (fighting to ifdef horror, etc)
Changes since v3:
- fixed usage of 64-bit random mask for 32-bit mm->mmap_compat_base,
during introducing mmap_compat{_legacy,}_base
Changes since v2:
- don't distinguish native and compat tasks by TIF_ADDR32,
introduced mmap_compat{_legacy,}_base which allows to treat them
the same
- fixed kbuild errors
Changes since v1:
- Recalculate mmap_base instead of using max possible virtual address
for compat/native syscall. That will make policy for allocation the
same in 32-bit binaries and in 32-bit syscalls in 64-bit binaries.
I need this because sys_mmap() in restored 32-bit process shouldn't
hit the stack area.
- Fixed mmap() with MAP_32BIT flag in the same usecases
- used in_compat_syscall() helper rather TS_COMPAT check (Andy noticed)
- introduced find_top() helper as suggested by Andy to simplify code
- fixed test error-handeling: it checked the result of sys_mmap() with
MMAP_FAILED, which is not correct, as it calls raw syscall - now
checks return value to be aligned to PAGE_SIZE.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: x...@kernel.org
Cc: linux...@kvack.org
Cc: Cyrill Gorcunov
Dmitry Safonov (5):
x86/mm: introduce arch_rnd() to compute 32/64 mmap rnd
x86/mm: add task_size parameter to mmap_base()
x86/mm: introduce mmap_compat_base for 32-bit mmap()
x86/mm: check in_compat_syscall() instead TIF_ADDR32 for
mmap(MAP_32BIT)
selftests/x86: add test for 32-bit mmap() return addr
arch/Kconfig | 7 +
arch/x86/Kconfig | 1 +
arch/x86/include/asm/elf.h | 27 ++--
arch/x86/include/asm/processor.h | 4 +-
arch/x86/kernel/sys_x86_64.c | 27 +++-
arch/x86/mm/mmap.c | 109 -
include/linux/mm_types.h | 5 +
tools/testing/selftests/x86/Makefile | 2 +-
tools/testing/selftests/x86/test_compat_mmap.c | 208 +
9 files changed, 332 insertions(+), 58 deletions(-)
create mode 100644 tools/testing/selftests/x86/test_compat_mmap.c
--
2.11.1
[PATCHv5 2/5] x86/mm: add task_size parameter to mmap_base()
To correctly handle 32-bit and 64-bit mmap() syscalls, we need different
mmap bases to start allocation from. So, introduce mmap_legacy_base()
helper and change mmap_base() to return base address according to
specified task size.
It'll prepare the mmap base computing code for splitting mmap_base
on two bases: for 64-bit syscall and for 32-bit syscalls.
Signed-off-by: Dmitry Safonov
---
arch/x86/include/asm/elf.h | 24 ++-
arch/x86/include/asm/processor.h | 4 +++-
arch/x86/mm/mmap.c | 50 +---
3 files changed, 48 insertions(+), 30 deletions(-)
diff --git a/arch/x86/include/asm/elf.h b/arch/x86/include/asm/elf.h
index e7f155c3045e..8aedc2a4d48c 100644
--- a/arch/x86/include/asm/elf.h
+++ b/arch/x86/include/asm/elf.h
@@ -284,8 +284,19 @@ do {
\
} \
} while (0)
+/*
+ * True on X86_32 or when emulating IA32 on X86_64
+ */
+static inline int mmap_is_ia32(void)
+{
+ return IS_ENABLED(CONFIG_X86_32) ||
+ (IS_ENABLED(CONFIG_COMPAT) &&
+ test_thread_flag(TIF_ADDR32));
+}
+
#ifdef CONFIG_X86_32
+#define __STACK_RND_MASK(is32bit) (0x7ff)
#define STACK_RND_MASK (0x7ff)
#define ARCH_DLINFOARCH_DLINFO_IA32
@@ -295,7 +306,8 @@ do {
\
#else /* CONFIG_X86_32 */
/* 1GB for 64bit, 8MB for 32bit */
-#define STACK_RND_MASK (test_thread_flag(TIF_ADDR32) ? 0x7ff : 0x3f)
+#define __STACK_RND_MASK(is32bit) ((is32bit) ? 0x7ff : 0x3f)
+#define STACK_RND_MASK __STACK_RND_MASK(mmap_is_ia32())
#define ARCH_DLINFO\
do { \
@@ -339,16 +351,6 @@ extern int compat_arch_setup_additional_pages(struct
linux_binprm *bprm,
int uses_interp);
#define compat_arch_setup_additional_pages compat_arch_setup_additional_pages
-/*
- * True on X86_32 or when emulating IA32 on X86_64
- */
-static inline int mmap_is_ia32(void)
-{
- return IS_ENABLED(CONFIG_X86_32) ||
- (IS_ENABLED(CONFIG_COMPAT) &&
- test_thread_flag(TIF_ADDR32));
-}
-
/* Do not change the values. See get_align_mask() */
enum align_flags {
ALIGN_VA_32 = BIT(0),
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index e6cfe7ba2d65..491f5a05a133 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -787,6 +787,7 @@ static inline void spin_lock_prefetch(const void *x)
/*
* User space process size: 3GB (default).
*/
+#define IA32_PAGE_OFFSET PAGE_OFFSET
#define TASK_SIZE PAGE_OFFSET
#define TASK_SIZE_MAX TASK_SIZE
#define STACK_TOP TASK_SIZE
@@ -863,7 +864,8 @@ extern void start_thread(struct pt_regs *regs, unsigned
long new_ip,
* This decides where the kernel will search for a free chunk of vm
* space during mmap's.
*/
-#define TASK_UNMAPPED_BASE (PAGE_ALIGN(TASK_SIZE / 3))
+#define __TASK_UNMAPPED_BASE(task_size)(PAGE_ALIGN(task_size / 3))
+#define TASK_UNMAPPED_BASE __TASK_UNMAPPED_BASE(TASK_SIZE)
#define KSTK_EIP(task) (task_pt_regs(task)->ip)
diff --git a/arch/x86/mm/mmap.c b/arch/x86/mm/mmap.c
index 9f3ac019e51c..88ef0c1b0e51 100644
--- a/arch/x86/mm/mmap.c
+++ b/arch/x86/mm/mmap.c
@@ -35,25 +35,23 @@ struct va_alignment __read_mostly va_align = {
.flags = -1,
};
-static unsigned long stack_maxrandom_size(void)
+static inline unsigned long tasksize_32bit(void)
+{
+ return IA32_PAGE_OFFSET;
+}
+
+static unsigned long stack_maxrandom_size(unsigned long task_size)
{
unsigned long max = 0;
if ((current->flags & PF_RANDOMIZE) &&
!(current->personality & ADDR_NO_RANDOMIZE)) {
- max = ((-1UL) & STACK_RND_MASK) << PAGE_SHIFT;
+ max = (-1UL) & __STACK_RND_MASK(task_size == tasksize_32bit());
+ max <<= PAGE_SHIFT;
}
return max;
}
-/*
- * Top of mmap area (just below the process stack).
- *
- * Leave an at least ~128 MB hole with possible stack randomization.
- */
-#define MIN_GAP (128*1024*1024UL + stack_maxrandom_size())
-#define MAX_GAP (TASK_SIZE/6*5)
-
#ifdef CONFIG_64BIT
# define mmap32_rnd_bits mmap_rnd_compat_bits
# define mmap64_rnd_bits mmap_rnd_bits
@@ -62,6 +60,8 @@ static unsigned long stack_maxrandom_size(void)
# define mmap64_rnd_bits mmap_rnd_bits
#endif
+#define SIZE_128M(128 * 1024 * 1024UL)
+
static int mmap_is_legacy(void)
{
if (current->personality & ADDR_COMPAT_LAYOUT)
@@ -83,16 +83,30 @@ unsigned long arch_mmap_rnd(void)
return arch_rnd(mmap_is_ia32() ? mmap32_rnd_bits : mmap64_rnd_bits);
}
-static unsigned long m
[PATCHv5 4/5] x86/mm: check in_compat_syscall() instead TIF_ADDR32 for mmap(MAP_32BIT)
Result of mmap() calls with MAP_32BIT flag at this moment depends
on thread flag TIF_ADDR32, which is set during exec() for 32-bit apps.
It's broken as the behavior of mmap() shouldn't depend on exec-ed
application's bitness. Instead, it should check the bitness of mmap()
syscall.
How it worked before:
o for 32-bit compatible binaries it is completely ignored. Which was
fine when there were one mmap_base, computed for 32-bit syscalls.
After introducing mmap_compat_base 64-bit syscalls do use computed
for 64-bit syscalls mmap_base, which means that we can allocate 64-bit
address with 64-bit syscall in application launched from 32-bit
compatible binary. And ignoring this flag is not expected behavior.
o for 64-bit ELFs it forces legacy bottom-up allocations and 1Gb address
space restriction for allocations: [0x4000, 0x8000) - look at
find_start_end(). Which means that it was wrongly handled for 32-bit
syscalls - they don't need nor this restriction nor legacy mmap
(as we try to keep 32-bit syscalls behavior the same independently of
native/compat mode of ELF being executed).
Changed mmap() behavior for MAP_32BIT flag the way that for 32-bit
syscalls it will be always ignored and for 64-bit syscalls it'll
always return 32-bit pointer restricted with 1Gb adress space,
independently of the binary's bitness of executed application.
Signed-off-by: Dmitry Safonov
---
arch/x86/kernel/sys_x86_64.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/sys_x86_64.c b/arch/x86/kernel/sys_x86_64.c
index 16b43dbe78b1..cc8eaba10104 100644
--- a/arch/x86/kernel/sys_x86_64.c
+++ b/arch/x86/kernel/sys_x86_64.c
@@ -114,7 +114,7 @@ static unsigned long get_mmap_base(int is_legacy)
static void find_start_end(unsigned long flags, unsigned long *begin,
unsigned long *end)
{
- if (!test_thread_flag(TIF_ADDR32) && (flags & MAP_32BIT)) {
+ if (!in_compat_syscall() && (flags & MAP_32BIT)) {
/* This is usually used needed to map code in small
model, so it needs to be in the first 31bit. Limit
it to that. This means we need to move the
@@ -190,7 +190,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const
unsigned long addr0,
return addr;
/* for MAP_32BIT mappings we force the legacy mmap base */
- if (!test_thread_flag(TIF_ADDR32) && (flags & MAP_32BIT))
+ if (!in_compat_syscall() && (flags & MAP_32BIT))
goto bottomup;
/* requesting a specific address */
--
2.11.1
[PATCH v2 4/4] ptp: create "pins" together with the rest of attributes
Let's switch to using device_create_with_groups(), which will allow us to
create "pins" attribute group together with the rest of ptp device
attributes, and before userspace gets notified about ptp device creation.
Signed-off-by: Dmitry Torokhov
---
drivers/ptp/ptp_clock.c | 20 +++-
drivers/ptp/ptp_private.h | 7 ---
drivers/ptp/ptp_sysfs.c | 39 +--
3 files changed, 24 insertions(+), 42 deletions(-)
diff --git a/drivers/ptp/ptp_clock.c b/drivers/ptp/ptp_clock.c
index b4e5e8022c29..e8142803a1a7 100644
--- a/drivers/ptp/ptp_clock.c
+++ b/drivers/ptp/ptp_clock.c
@@ -221,16 +221,17 @@ struct ptp_clock *ptp_clock_register(struct
ptp_clock_info *info,
mutex_init(&ptp->pincfg_mux);
init_waitqueue_head(&ptp->tsev_wq);
+ err = ptp_populate_pin_groups(ptp);
+ if (err)
+ goto no_pin_groups;
+
/* Create a new device in our class. */
- ptp->dev = device_create(ptp_class, parent, ptp->devid, ptp,
-"ptp%d", ptp->index);
+ ptp->dev = device_create_with_groups(ptp_class, parent, ptp->devid,
+ptp, ptp->pin_attr_groups,
+"ptp%d", ptp->index);
if (IS_ERR(ptp->dev))
goto no_device;
- err = ptp_populate_sysfs(ptp);
- if (err)
- goto no_sysfs;
-
/* Register a new PPS source. */
if (info->pps) {
struct pps_source_info pps;
@@ -258,10 +259,10 @@ struct ptp_clock *ptp_clock_register(struct
ptp_clock_info *info,
if (ptp->pps_source)
pps_unregister_source(ptp->pps_source);
no_pps:
- ptp_cleanup_sysfs(ptp);
-no_sysfs:
device_destroy(ptp_class, ptp->devid);
no_device:
+ ptp_cleanup_pin_groups(ptp);
+no_pin_groups:
mutex_destroy(&ptp->tsevq_mux);
mutex_destroy(&ptp->pincfg_mux);
ida_simple_remove(&ptp_clocks_map, index);
@@ -280,8 +281,9 @@ int ptp_clock_unregister(struct ptp_clock *ptp)
/* Release the clock's resources. */
if (ptp->pps_source)
pps_unregister_source(ptp->pps_source);
- ptp_cleanup_sysfs(ptp);
+
device_destroy(ptp_class, ptp->devid);
+ ptp_cleanup_pin_groups(ptp);
posix_clock_unregister(&ptp->clock);
return 0;
diff --git a/drivers/ptp/ptp_private.h b/drivers/ptp/ptp_private.h
index 9c5d41421b65..d95888974d0c 100644
--- a/drivers/ptp/ptp_private.h
+++ b/drivers/ptp/ptp_private.h
@@ -54,6 +54,8 @@ struct ptp_clock {
struct device_attribute *pin_dev_attr;
struct attribute **pin_attr;
struct attribute_group pin_attr_group;
+ /* 1st entry is a pointer to the real group, 2nd is NULL terminator */
+ const struct attribute_group *pin_attr_groups[2];
};
/*
@@ -94,8 +96,7 @@ uint ptp_poll(struct posix_clock *pc,
extern const struct attribute_group *ptp_groups[];
-int ptp_cleanup_sysfs(struct ptp_clock *ptp);
-
-int ptp_populate_sysfs(struct ptp_clock *ptp);
+int ptp_populate_pin_groups(struct ptp_clock *ptp);
+void ptp_cleanup_pin_groups(struct ptp_clock *ptp);
#endif
diff --git a/drivers/ptp/ptp_sysfs.c b/drivers/ptp/ptp_sysfs.c
index 426e42c51df4..48401dfcd999 100644
--- a/drivers/ptp/ptp_sysfs.c
+++ b/drivers/ptp/ptp_sysfs.c
@@ -268,25 +268,14 @@ static ssize_t ptp_pin_store(struct device *dev, struct
device_attribute *attr,
return count;
}
-int ptp_cleanup_sysfs(struct ptp_clock *ptp)
+int ptp_populate_pin_groups(struct ptp_clock *ptp)
{
- struct device *dev = ptp->dev;
- struct ptp_clock_info *info = ptp->info;
-
- if (info->n_pins) {
- sysfs_remove_group(&dev->kobj, &ptp->pin_attr_group);
- kfree(ptp->pin_attr);
- kfree(ptp->pin_dev_attr);
- }
- return 0;
-}
-
-static int ptp_populate_pins(struct ptp_clock *ptp)
-{
- struct device *dev = ptp->dev;
struct ptp_clock_info *info = ptp->info;
int err = -ENOMEM, i, n_pins = info->n_pins;
+ if (!n_pins)
+ return 0;
+
ptp->pin_dev_attr = kcalloc(n_pins, sizeof(*ptp->pin_dev_attr),
GFP_KERNEL);
if (!ptp->pin_dev_attr)
@@ -309,28 +298,18 @@ static int ptp_populate_pins(struct ptp_clock *ptp)
ptp->pin_attr_group.name = "pins";
ptp->pin_attr_group.attrs = ptp->pin_attr;
- err = sysfs_create_group(&dev->kobj, &ptp->pin_attr_group);
- if (err)
- goto no_group;
+ ptp->pin_attr_groups[0] = &ptp->pin_attr_group;
+
return 0;
-no_group:
- kfree(ptp->pin_attr);
no_pin_attr:
kfree(ptp->pin_dev_attr);
no_dev_attr:
return err;
}
-int ptp_populate_sysfs(struct ptp_clock *ptp)
+void ptp_cleanup_pin_groups(struct ptp_clock *ptp)
{
- struct ptp_clock_info *info = ptp->info;
- int err;
-
- if (info->n_pins
Re: [PATCH V2] audit: log module name on init_module
On Tuesday, February 14, 2017 1:38:36 PM EST Paul Moore wrote: > On Tue, Feb 14, 2017 at 1:11 PM, Richard Guy Briggs wrote: > > On 2017-02-14 13:02, Steve Grubb wrote: > >> On Monday, February 13, 2017 4:20:55 PM EST Paul Moore wrote: > >> > On Sat, Feb 4, 2017 at 1:10 PM, Richard Guy Briggs wrote: > >> > > This adds a new auxiliary record MODULE_INIT to the SYSCALL event. > >> > > > >> > > We get finit_module for free since it made most sense to hook this in > >> > > to > >> > > load_module(). > >> > > > >> > > https://github.com/linux-audit/audit-kernel/issues/7 > >> > > https://github.com/linux-audit/audit-kernel/wiki/RFE-Module-load-reco > >> > > rd-fo > >> > > rmat > >> > > >> > Correction for the record: > >> > > >> > * > >> > https://github.com/linux-audit/audit-kernel/wiki/RFE-Module-Load-Record > >> > -For > >> > mat > >> > > >> > [NOTE: don't resend please, I'll fix this when merging] > >> > >> OK. Support was added to user space for this record. While doing this, I > >> wondered if we also get this auxiliary record when unloading a module? > > > > I thought of that at the time, which influenced the design and wording. > > It is not supported yet, but that should be easier to add. > > As a reminder, this is currently in audit/next and will be going up to > Linus next week during the merge window, if you want to change this > record in some backwards incompatible way, e.g. putting a field before > "name", you've got until the end of this week to figure that out. This isn't necessary. The syscall used denotes the meaning of the action. -Steve
Re: [PATCH] ACPI, APEI: Fix BERT resources conflict with ACPI NVS area
On 2/13/2017 7:01 PM, Huang, Ying wrote: From: Huang Ying It was reported that some firmware will use ACPI NVS area for BERT address range. This will cause resources conflict because the ACPI NVS area is marked as busy already. Fix this via excluding ACPI NVS area when requesting IO resources for BERT. Reported-and-tested-by: Hans Kristian Rosbach Signed-off-by: "Huang, Ying" Tested-by: Tyler Baicar -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH 1/6] x86: drop unneded members of struct cpuinfo_x86
On 02/14/17 09:56, Geert Uytterhoeven wrote:
>>
>> Well, almost. You need the wp_works_ok removal patch too, otherwise you
>> have the 3 bytes hole below.
>
> That's because you removed a char in commit 93a829e8e2c292f1
> ("x86, cpu: Convert FDIV bug detection), without compensating with padding ;-)
>
Padding isn't a problem (other than efficiency) for a structure which is
strictly internal to the kernel as opposed to an ABI structure.
-hpa
Re: [PATCH v2] usb: musb: add code comment for clarification
On Tue, Feb 14, 2017 at 10:25:11AM -0800, Greg KH wrote: > On Tue, Feb 14, 2017 at 12:20:39PM -0600, Gustavo A. R. Silva wrote: > > Add code comment to make it clear that the fall-through is intentional. > > Read the link for more details: https://lkml.org/lkml/2017/2/9/292 > > > > Addresses-Coverity-ID: 1397608 > > Signed-off-by: Gustavo A. R. Silva > > --- > > Changes in v2: > > Fix tabs and line-wrapping in previous patch. > > Thanks for this. Bin, I've applied this to my tree so it makes it into > 4.11-rc1. Thanks Greg for take it to v4.11. Regards, -Bin.
Re: [PATCH]staging: fbtft: Fix sparse warnings about endianness
On Tue, Feb 14, 2017 at 09:18:25AM -0800, Greg KH wrote:
> On Tue, Feb 14, 2017 at 04:53:10PM +0800, maomao xu wrote:
> > Fixed sparse warnings about endianness. E.g.:
> >
> > warning: incorrect type in assignment (different base types)
>
> Why are these lines indented?
>
> > Signed-off-by: maomao xu
> >
> > diff --git a/drivers/staging/fbtft/fbtft-io.c
> > b/drivers/staging/fbtft/fbtft-io.c
> > index d868405..ffb9a3b 100644
> > --- a/drivers/staging/fbtft/fbtft-io.c
> > +++ b/drivers/staging/fbtft/fbtft-io.c
> > @@ -71,7 +71,7 @@ int fbtft_write_spi_emulate_9(struct fbtft_par *par, void
> > *buf, size_t len)
> > src++;
> > }
> > tmp |= ((*src & 0x0100) ? 1 : 0);
> > - *(u64 *)dst = cpu_to_be64(tmp);
> > + *(__be64 *)dst = cpu_to_be64(tmp);
>
> Really? That seems very odd. I need a maintainer's ack for this before
> I can take it...
If anything, I would turn the inner loop into
tmp = 0;
for (j = 0; j < 7; j++) {
tmp <<= 9;
tmp |= *src++ & 0x1ff;
}
tmp <<= 1;
there - the whole thing looks like an obfuscated "take an array of 9-bit
values, each stored in host-endian 16bit, repack them into octets".
Which architecture is that supposed to run on? Anything that doesn't like
unaligned stores won't be happy with that code...
Another interesting part is that we have size = len / 2 and verify that len
is a multiple of 8. I.e. that size is only guaranteed to be a multiple
of 4. Each pass through the outer loop consumes 8 16bit values and decrements
size by 8, so if len is e.g. 24 we'll end up accepting that, get size equal
to 12, pass through the outer loop twice and chew through 32 bytes of buf...
[PATCH 1/3] powerpc: kprobes: add support for KPROBES_ON_FTRACE
Allow kprobes to be placed on ftrace _mcount() call sites. This
optimization avoids the use of a trap, by riding on ftrace
infrastructure.
This depends on HAVE_DYNAMIC_FTRACE_WITH_REGS which depends on
MPROFILE_KERNEL, which is only currently enabled on powerpc64le with
newer toolchains.
Based on the x86 code by Masami.
Signed-off-by: Naveen N. Rao
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/kprobes.h | 10
arch/powerpc/kernel/Makefile | 3 ++
arch/powerpc/kernel/kprobes-ftrace.c | 100 +++
arch/powerpc/kernel/kprobes.c| 4 +-
arch/powerpc/kernel/optprobes.c | 3 ++
6 files changed, 120 insertions(+), 1 deletion(-)
create mode 100644 arch/powerpc/kernel/kprobes-ftrace.c
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 260dd6a371e0..78419919556d 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -101,6 +101,7 @@ config PPC
select HAVE_EFFICIENT_UNALIGNED_ACCESS if !(CPU_LITTLE_ENDIAN &&
POWER7_CPU)
select HAVE_KPROBES
select HAVE_OPTPROBES if PPC64
+ select HAVE_KPROBES_ON_FTRACE
select HAVE_ARCH_KGDB
select HAVE_KRETPROBES
select HAVE_ARCH_TRACEHOOK
diff --git a/arch/powerpc/include/asm/kprobes.h
b/arch/powerpc/include/asm/kprobes.h
index e7ada061aa12..3305a12286fa 100644
--- a/arch/powerpc/include/asm/kprobes.h
+++ b/arch/powerpc/include/asm/kprobes.h
@@ -153,6 +153,16 @@ extern int kprobe_exceptions_notify(struct notifier_block
*self,
extern int kprobe_fault_handler(struct pt_regs *regs, int trapnr);
extern int kprobe_handler(struct pt_regs *regs);
extern int kprobe_post_handler(struct pt_regs *regs);
+#ifdef CONFIG_KPROBES_ON_FTRACE
+extern int skip_singlestep(struct kprobe *p, struct pt_regs *regs,
+ struct kprobe_ctlblk *kcb);
+#else
+static inline int skip_singlestep(struct kprobe *p, struct pt_regs *regs,
+ struct kprobe_ctlblk *kcb)
+{
+ return 0;
+}
+#endif
#else
static inline int kprobe_handler(struct pt_regs *regs) { return 0; }
static inline int kprobe_post_handler(struct pt_regs *regs) { return 0; }
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index a048b37b9b27..88b21427ccc7 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -101,6 +101,7 @@ obj-$(CONFIG_BOOTX_TEXT)+= btext.o
obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_KPROBES) += kprobes.o
obj-$(CONFIG_OPTPROBES)+= optprobes.o optprobes_head.o
+obj-$(CONFIG_KPROBES_ON_FTRACE)+= kprobes-ftrace.o
obj-$(CONFIG_UPROBES) += uprobes.o
obj-$(CONFIG_PPC_UDBG_16550) += legacy_serial.o udbg_16550.o
obj-$(CONFIG_STACKTRACE) += stacktrace.o
@@ -154,6 +155,8 @@ GCOV_PROFILE_machine_kexec_32.o := n
UBSAN_SANITIZE_machine_kexec_32.o := n
GCOV_PROFILE_kprobes.o := n
UBSAN_SANITIZE_kprobes.o := n
+GCOV_PROFILE_kprobes-ftrace.o := n
+UBSAN_SANITIZE_kprobes-ftrace.o := n
UBSAN_SANITIZE_vdso.o := n
extra-$(CONFIG_PPC_FPU)+= fpu.o
diff --git a/arch/powerpc/kernel/kprobes-ftrace.c
b/arch/powerpc/kernel/kprobes-ftrace.c
new file mode 100644
index ..0377b3013723
--- /dev/null
+++ b/arch/powerpc/kernel/kprobes-ftrace.c
@@ -0,0 +1,100 @@
+/*
+ * Dynamic Ftrace based Kprobes Optimization
+ *
+ * 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. 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., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Copyright (C) Hitachi Ltd., 2012
+ * Copyright 2016 Naveen N. Rao
+ * IBM Corporation
+ */
+#include
+#include
+#include
+#include
+#include
+
+static nokprobe_inline
+int __skip_singlestep(struct kprobe *p, struct pt_regs *regs,
+ struct kprobe_ctlblk *kcb, unsigned long orig_nip)
+{
+ /*
+* Emulate singlestep (and also recover regs->nip)
+* as if there is a nop
+*/
+ regs->nip = (unsigned long)p->addr + MCOUNT_INSN_SIZE;
+ if (unlikely(p->post_handler)) {
+ kcb->kprobe_status = KPROBE_HIT_SSDONE;
+ p->post_handler(p, regs, 0);
+ }
+ __this_cpu_write(current_kprobe, NULL);
+ if (orig_nip)
+ regs->nip = orig_nip;
+ return 1;
+}
+
+int skip_singlestep(struct kprobe *p, struct pt_regs *regs,
+
[PATCH 3/3] powerpc: kprobes: prefer ftrace when probing function entry
KPROBES_ON_FTRACE avoids much of the overhead with regular kprobes as it
eliminates the need for a trap, as well as the need to emulate or
single-step instructions.
Though OPTPROBES provides us with similar performance, we have limited
optprobes trampoline slots. As such, when asked to probe at a function
entry, default to using the ftrace infrastructure.
With:
# cd /sys/kernel/debug/tracing
# echo 'p _do_fork' > kprobe_events
before patch:
# cat ../kprobes/list
c00daf08 k _do_fork+0x8[DISABLED]
c0044fc0 k kretprobe_trampoline+0x0[OPTIMIZED]
and after patch:
# cat ../kprobes/list
c00d074c k _do_fork+0xc[DISABLED][FTRACE]
c00412b0 k kretprobe_trampoline+0x0[OPTIMIZED]
Signed-off-by: Naveen N. Rao
---
arch/powerpc/include/asm/kprobes.h | 20
1 file changed, 20 insertions(+)
diff --git a/arch/powerpc/include/asm/kprobes.h
b/arch/powerpc/include/asm/kprobes.h
index 3305a12286fa..09e74edee625 100644
--- a/arch/powerpc/include/asm/kprobes.h
+++ b/arch/powerpc/include/asm/kprobes.h
@@ -60,12 +60,32 @@ extern kprobe_opcode_t optprobe_template_end[];
#ifdef PPC64_ELF_ABI_v2
/* PPC64 ABIv2 needs local entry point */
+#ifdef CONFIG_KPROBES_ON_FTRACE
+/*
+ * Per livepatch.h, ftrace location is always within the first 16 bytes
+ * of a function on powerpc with -mprofile-kernel.
+ */
+#define kprobe_lookup_name(name, addr, offset) \
+{ \
+ addr = (kprobe_opcode_t *)kallsyms_lookup_name(name); \
+ if (addr && !(offset)) {\
+ unsigned long faddr;\
+ faddr = ftrace_location_range((unsigned long)addr, \
+ (unsigned long)addr + 16);\
+ if (faddr) \
+ addr = (kprobe_opcode_t *)faddr;\
+ else\
+ addr = (kprobe_opcode_t *)ppc_function_entry(addr);
\
+ } \
+}
+#else
#define kprobe_lookup_name(name, addr, offset) \
{ \
addr = (kprobe_opcode_t *)kallsyms_lookup_name(name); \
if (addr && !(offset)) \
addr = (kprobe_opcode_t *)ppc_function_entry(addr); \
}
+#endif
#elif defined(PPC64_ELF_ABI_v1)
/*
* 64bit powerpc ABIv1 uses function descriptors:
--
2.11.0
[PATCH 2/3] powerpc: introduce a new helper to obtain function entry points
kprobe_lookup_name() is specific to the kprobe subsystem and may not
always return the function entry point (in a subsequent patch). For
looking up function entry points, introduce a separate helper and use
the same in optprobes.c
Signed-off-by: Naveen N. Rao
---
arch/powerpc/include/asm/code-patching.h | 37
arch/powerpc/kernel/optprobes.c | 4 ++--
2 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/code-patching.h
b/arch/powerpc/include/asm/code-patching.h
index 8ab937771068..3e994f404434 100644
--- a/arch/powerpc/include/asm/code-patching.h
+++ b/arch/powerpc/include/asm/code-patching.h
@@ -12,6 +12,8 @@
#include
#include
+#include
+#include
/* Flags for create_branch:
* "b" == create_branch(addr, target, 0);
@@ -99,6 +101,41 @@ static inline unsigned long ppc_global_function_entry(void
*func)
#endif
}
+/*
+ * Wrapper around kallsyms_lookup() to return function entry address:
+ * - For ABIv1, we lookup the dot variant.
+ * - For ABIv2, we return the local entry point.
+ */
+static inline unsigned long ppc_kallsyms_lookup_name(const char *name)
+{
+ unsigned long addr;
+#ifdef PPC64_ELF_ABI_v1
+ /* check for dot variant */
+ char dot_name[1 + KSYM_NAME_LEN];
+ bool dot_appended = false;
+ if (name[0] != '.') {
+ dot_name[0] = '.';
+ dot_name[1] = '\0';
+ strncat(dot_name, name, KSYM_NAME_LEN - 2);
+ dot_appended = true;
+ } else {
+ dot_name[0] = '\0';
+ strncat(dot_name, name, KSYM_NAME_LEN - 1);
+ }
+ addr = kallsyms_lookup_name(dot_name);
+ if (!addr && dot_appended)
+ /* Let's try the original non-dot symbol lookup */
+ addr = kallsyms_lookup_name(name);
+#elif defined(PPC64_ELF_ABI_v2)
+ addr = kallsyms_lookup_name(name);
+ if (addr)
+ addr = ppc_function_entry((void *)addr);
+#else
+ addr = kallsyms_lookup_name(name);
+#endif
+ return addr;
+}
+
#ifdef CONFIG_PPC64
/*
* Some instruction encodings commonly used in dynamic ftracing
diff --git a/arch/powerpc/kernel/optprobes.c b/arch/powerpc/kernel/optprobes.c
index a8f414a0b141..a2f6f28e5205 100644
--- a/arch/powerpc/kernel/optprobes.c
+++ b/arch/powerpc/kernel/optprobes.c
@@ -246,8 +246,8 @@ int arch_prepare_optimized_kprobe(struct optimized_kprobe
*op, struct kprobe *p)
/*
* 2. branch to optimized_callback() and emulate_step()
*/
- kprobe_lookup_name("optimized_callback", op_callback_addr, 0);
- kprobe_lookup_name("emulate_step", emulate_step_addr, 0);
+ op_callback_addr = (kprobe_opcode_t
*)ppc_kallsyms_lookup_name("optimized_callback");
+ emulate_step_addr = (kprobe_opcode_t
*)ppc_kallsyms_lookup_name("emulate_step");
if (!op_callback_addr || !emulate_step_addr) {
WARN(1, "kprobe_lookup_name() failed\n");
goto error;
--
2.11.0
Re: [PATCH] mips: audit and remove any unnecessary uses of module.h
[Re: [PATCH] mips: audit and remove any unnecessary uses of module.h] On 14/02/2017 (Tue 10:10) James Hogan wrote: > On Sat, Jan 28, 2017 at 09:05:57PM -0500, Paul Gortmaker wrote: > > Historically a lot of these existed because we did not have > > a distinction between what was modular code and what was providing > > support to modules via EXPORT_SYMBOL and friends. That changed > > when we forked out support for the latter into the export.h file. > > > > This means we should be able to reduce the usage of module.h > > in code that is obj-y Makefile or bool Kconfig. In the case of > > some code where it is modular, we can extend that to also include > > files that are building basic support functionality but not related > > to loading or registering the final module; such files also have > > no need whatsoever for module.h > > > > The advantage in removing such instances is that module.h itself > > sources about 15 other headers; adding significantly to what we feed > > cpp, and it can obscure what headers we are effectively using. > > > > Since module.h might have been the implicit source for init.h > > (for __init) and for export.h (for EXPORT_SYMBOL) we consider each > > instance for the presence of either and replace/add as needed. > > > > Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code. > > > > Build coverage of all the mips defconfigs revealed the module.h > > header was masking a couple of implicit include instances, so > > we add the appropriate headers there. > > > > Cc: David Daney > > Cc: John Crispin > > Cc: Ralf Baechle > > Cc: "Steven J. Hill" > > Cc: linux-m...@linux-mips.org > > Signed-off-by: Paul Gortmaker > > Applied (with a couple of tweaks to preserve existing sort order) Thanks -- were you hoping for xmas tree order (string length) or alphabetical sort? I'll make a mental note to check that for any future MIPS patches I have. P. -- > > Thanks > James > > > --- > > > > [I had this split along platform lines into 17 separate commits, but > > when I realized there were only 3 platform specific maintainers called > > out, I thought that was probably overkill. If the split version is > > desired, let me know. > > > > Also, this is against v4.10-rc5. The same patch against linux-next > > will have a trivial conflict in xway dma.c due to a spinlock.h > > addition there. ] > > > > arch/mips/alchemy/common/dbdma.c | 2 +- > > arch/mips/alchemy/common/dma.c | 2 +- > > arch/mips/alchemy/common/gpiolib.c | 1 - > > arch/mips/alchemy/common/prom.c| 1 - > > arch/mips/alchemy/common/usb.c | 2 +- > > arch/mips/alchemy/common/vss.c | 2 +- > > arch/mips/alchemy/devboards/bcsr.c | 3 ++- > > arch/mips/ar7/clock.c | 2 +- > > arch/mips/ar7/gpio.c | 3 ++- > > arch/mips/ar7/memory.c | 1 - > > arch/mips/ar7/platform.c | 1 - > > arch/mips/ar7/prom.c | 2 +- > > arch/mips/ath79/clock.c| 1 - > > arch/mips/ath79/common.c | 2 +- > > arch/mips/bcm63xx/clk.c| 3 ++- > > arch/mips/bcm63xx/cpu.c| 2 +- > > arch/mips/bcm63xx/cs.c | 3 ++- > > arch/mips/bcm63xx/gpio.c | 2 +- > > arch/mips/bcm63xx/irq.c| 1 - > > arch/mips/bcm63xx/reset.c | 3 ++- > > arch/mips/bcm63xx/timer.c | 3 ++- > > arch/mips/cavium-octeon/crypto/octeon-crypto.c | 2 +- > > arch/mips/cavium-octeon/executive/cvmx-bootmem.c | 2 +- > > arch/mips/cavium-octeon/executive/cvmx-helper-errata.c | 2 +- > > arch/mips/cavium-octeon/executive/cvmx-sysinfo.c | 2 +- > > arch/mips/cavium-octeon/smp.c | 3 ++- > > arch/mips/dec/prom/identify.c | 2 +- > > arch/mips/dec/setup.c | 2 +- > > arch/mips/dec/wbflush.c| 4 +--- > > arch/mips/jazz/jazzdma.c | 2 +- > > arch/mips/jz4740/gpio.c| 2 +- > > arch/mips/jz4740/prom.c| 1 - > > arch/mips/jz4740/timer.c | 3 ++- > > arch/mips/lantiq/xway/dma.c| 3 +-- > > arch/mips/lantiq/xway/gptu.c | 3 +-- > > arch/mips/lasat/at93c.c| 1 - > > arch/mips/lasat/sysctl.c | 1 - > > arch/mips/loongson64/common/cs5536/cs5536_mfgpt.c | 2 +- > > arch/mips/loongson64/common/env.c | 2 +
Re: [PATCH] seccomp: Only dump core when single-threaded
On Mon, Feb 13, 2017 at 10:37 PM, Andrei Vagin wrote:
> On Tue, Feb 07, 2017 at 03:18:51PM -0800, Kees Cook wrote:
>> The SECCOMP_RET_KILL filter return code has always killed the current
>> thread, not the entire process. Changing this as a side-effect of dumping
>> core isn't a safe thing to do (a few test suites have already flagged this
>> behavioral change). Instead, restore the RET_KILL semantics, but still
>> dump core when a RET_KILL delivers SIGSYS to a single-threaded process.
>>
>> Fixes: b25e67161c29 ("seccomp: dump core when using SECCOMP_RET_KILL")
>> Signed-off-by: Kees Cook
>
> All CRIU tests passed with this patch. Thanks!
>
> Acked-by: Andrei Vagin
Thanks for testing!
James, can you make sure this makes it into your -next tree for v4.11?
Thanks!
-Kees
>
>> ---
>> kernel/seccomp.c | 13 -
>> 1 file changed, 8 insertions(+), 5 deletions(-)
>>
>> diff --git a/kernel/seccomp.c b/kernel/seccomp.c
>> index f8f88ebcb3ba..e15185c28de5 100644
>> --- a/kernel/seccomp.c
>> +++ b/kernel/seccomp.c
>> @@ -643,11 +643,14 @@ static int __seccomp_filter(int this_syscall, const
>> struct seccomp_data *sd,
>> default: {
>> siginfo_t info;
>> audit_seccomp(this_syscall, SIGSYS, action);
>> - /* Show the original registers in the dump. */
>> - syscall_rollback(current, task_pt_regs(current));
>> - /* Trigger a manual coredump since do_exit skips it. */
>> - seccomp_init_siginfo(&info, this_syscall, data);
>> - do_coredump(&info);
>> + /* Dump core only if this is the last remaining thread. */
>> + if (get_nr_threads(current) == 1) {
>> + /* Show the original registers in the dump. */
>> + syscall_rollback(current, task_pt_regs(current));
>> + /* Trigger a manual coredump since do_exit skips it. */
>> + seccomp_init_siginfo(&info, this_syscall, data);
>> + do_coredump(&info);
>> + }
>> do_exit(SIGSYS);
>> }
>> }
>> --
>> 2.7.4
>>
>>
>> --
>> Kees Cook
>> Pixel Security
--
Kees Cook
Pixel Security
Re: [PATCH] xfs: fix len comparison in xfs_extent_busy_trim
Thanks Arnd, this looks good: Reviewed-by: Christoph Hellwig
make pdfdocs errors with 4.10-rc8
On a Fedora 25 system,
[...]
build succeeded, 32 warnings.
make PDFLATEX=xelatex LATEXOPTS="-interaction=batchmode" -C
Documentation/output/./latex;
xelatex -interaction=batchmode 'linux-user.tex'
This is XeTeX, Version 3.14159265-2.6-0.6 (TeX Live 2016)
(preloaded format=xelatex)
restricted \write18 enabled.
entering extended mode
Makefile:66: recipe for target 'linux-user.pdf' failed
Documentation/Makefile.sphinx:83: recipe for target 'pdfdocs' failed
Makefile:1450: recipe for target 'pdfdocs' failed
where Documentation/output/latex/linux-user.log contains
[jim@krebstar latex]$ grep '^!' linux-user.log | sort -u
! Extra }, or forgotten \endgroup.
! Missing } inserted.
and that happens often enough that Tex bails:
[jim@krebstar latex]$ tail -20 linux-user.log
[...]
! Extra }, or forgotten \endgroup.
}
l.14911 \hline\end{tabulary}
(That makes 100 errors; please try again.)
[...]
--
Jim
