RE: [PATCH 1/3] PCI: designware: Configuration space should be specified in 'reg'
Hello Kishon,
> -Original Message-
> From: Kishon Vijay Abraham I [mailto:kis...@ti.com]
> Sent: Wednesday, June 25, 2014 11:27 PM
> To: devicet...@vger.kernel.org; linux-...@vger.kernel.org; linux-
> p...@vger.kernel.org; jg1@samsung.com; bhelg...@google.com; Mohit
> KUMAR DCG; linux-kernel@vger.kernel.org
> Cc: kis...@ti.com; grant.lik...@linaro.org; Jason Gunthorpe; Marek Vasut;
> Arnd Bergmann
> Subject: [PATCH 1/3] PCI: designware: Configuration space should be
> specified in 'reg'
>
> The configuration address space has so far been specified in *ranges*,
> however it should be specified in *reg* making it a platform MEM resource.
> Hence used 'platform_get_resource_*' API to get configuration address
> space in the designware driver.
>
> Cc: Jason Gunthorpe
> Cc: Bjorn Helgaas
> Cc: Mohit Kumar
> Cc: Jingoo Han
> Cc: Marek Vasut
> Cc: Arnd Bergmann
> Signed-off-by: Kishon Vijay Abraham I
> ---
> .../devicetree/bindings/pci/designware-pcie.txt|4
> drivers/pci/host/pcie-designware.c | 17 +++--
> 2 files changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt
> b/Documentation/devicetree/bindings/pci/designware-pcie.txt
> index d0d15ee..ed0d9b9 100644
> --- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
> @@ -2,6 +2,10 @@
>
> Required properties:
> - compatible: should contain "snps,dw-pcie" to identify the core.
> +- reg: Should contain the configuration address space.
> +- reg-names: Must be "config" for the PCIe configuration space.
> +(The old way of getting the configuration address space from "ranges"
> +is deprecated and should be avoided.)
> - #address-cells: set to <3>
> - #size-cells: set to <2>
> - device_type: set to "pci"
> diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-
> designware.c
> index 1eaf4df..0b7b455 100644
> --- a/drivers/pci/host/pcie-designware.c
> +++ b/drivers/pci/host/pcie-designware.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "pcie-designware.h"
> @@ -396,11 +397,23 @@ static const struct irq_domain_ops
> msi_domain_ops = { int __init dw_pcie_host_init(struct pcie_port *pp) {
> struct device_node *np = pp->dev->of_node;
> + struct platform_device *pdev = to_platform_device(pp->dev);
> struct of_pci_range range;
> struct of_pci_range_parser parser;
> + struct resource *cfg_res;
> u32 val;
> int i;
>
> + cfg_res = platform_get_resource_byname(pdev,
> IORESOURCE_MEM, "config");
> + if (cfg_res) {
> + pp->config.cfg0_size = resource_size(cfg_res)/2;
> + pp->config.cfg1_size = resource_size(cfg_res)/2;
> + pp->cfg0_base = cfg_res->start;
> + pp->cfg1_base = cfg_res->start + pp->config.cfg0_size;
> + } else {
> + dev_err(pp->dev, "missing *config* reg space\n");
- so this message will remind other platform to comply and specify
configuration space
in *reg* property.
> + }
> +
> if (of_pci_range_parser_init(, np)) {
> dev_err(pp->dev, "missing ranges property\n");
> return -EINVAL;
> @@ -433,6 +446,8 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
> of_pci_range_to_resource(, np, >cfg);
> pp->config.cfg0_size = resource_size(>cfg)/2;
> pp->config.cfg1_size = resource_size(>cfg)/2;
> + pp->cfg0_base = pp->cfg.start;
> + pp->cfg1_base = pp->cfg.start + pp-
> >config.cfg0_size;
> }
> }
>
> @@ -445,8 +460,6 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
> }
> }
>
> - pp->cfg0_base = pp->cfg.start;
> - pp->cfg1_base = pp->cfg.start + pp->config.cfg0_size;
> pp->mem_base = pp->mem.start;
>
> pp->va_cfg0_base = devm_ioremap(pp->dev, pp->cfg0_base,
Reviewed and Acked-by: Mohit Kumar
Regards
Mohit
> --
> 1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] scripts/checkpatch.pl: Only emit LONG_LINE for --strict
On Wed, Jun 25, 2014 at 10:29:30PM -0700, Joe Perches wrote: > On Wed, 2014-06-25 at 22:08 -0700, Josh Triplett wrote: > > > Now, arguably the four leading tabs on those lines suggest the need for > > some code refactoring; personally, I'd suggest changing DEEP_INDENTATION > > to flag 4+ tabs rather than 6+ tabs as it currently does. > > There are _way too many_ 4+ tab indents for that to > be sensible. Yeah, a quick grep confirmed that. On the other hand, if *already* flagging a long line, it makes sense to flag 4+ tabs as potentially excessive nesting. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] PCI: designware: use untranslated address while programming ATU
Hi Kishon,
Few things, if you can help me to understand:
On Wed, Jun 25, 2014 at 11:26 PM, Kishon Vijay Abraham I wrote:
> In DRA7, the cpu sees 32bit address, but the pcie controller can see only
> 28bit
> address. So whenever the cpu issues a read/write request, the 4 most
> significant bits are used by L3 to determine the target controller.
> For example, the cpu reserves 0x2000_ - 0x2FFF_ for PCIe controller
> but
> the PCIe controller will see only (0x000_ - 0xFFF_FFF). So for programming
> the outbound translation window the *base* should be programmed as 0x000_.
> Whenever we try to write to say 0x2000_, it will be translated to whatever
> we have programmed in the translation window with base as 0x000_.
>
> This is needed when the dt node is modelled something like below
> axi {
> compatible = "simple-bus";
> #size-cells = <1>;
> #address-cells = <1>;
> ranges = <0x00x2000 0x1000 // 28-bit bus
> 0x5100 0x5100 0x3000>;
> pcie@5100 {
> reg = <0x1000 0x2000>, <0x51002000 0x14c>, <0x5100
> 0x2000>;
> reg-names = "config", "ti_conf", "rc_dbics";
So for DRA7, config base which will be coming from reg property should
be 0x1000 and size 0x2000, no?
> #address-cells = <3>;
> #size-cells = <2>;
> ranges = <0x8100 0 0 0x03000 0 0x0001
range type 0x8100 tells that it is IO
> 0x8200 0 0x20013000 0x13000 0 0xffed000>;
range type 0x8100 tells that it is mem
> };
> };
>
> Here the CPU address for configuration space is 0x20013000 and the controller
> address for configuration space is 0x13000. The controller address should
be
If above understanding is correct then:
Aren't these addresses(0x20013000 and 0x13000) from mem space
instead of configuration space.
If yes, then how can you get two addresses (CPU and Controller address)
from reg property for configuration space?
~Pratyush
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/3] ARM: tegra: of: add GK20A device tree binding
Add the device tree binding documentation for the GK20A GPU used in
Tegra K1 SoCs.
Signed-off-by: Alexandre Courbot
Acked-by: Stephen Warren
---
.../devicetree/bindings/gpu/nvidia,gk20a.txt | 43 ++
1 file changed, 43 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
diff --git a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
b/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
new file mode 100644
index ..23bfe8e1f7cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
@@ -0,0 +1,43 @@
+NVIDIA GK20A Graphics Processing Unit
+
+Required properties:
+- compatible: "nvidia,-"
+ Currently recognized values:
+ - nvidia,tegra124-gk20a
+- reg: Physical base address and length of the controller's registers.
+ Must contain two entries:
+ - first entry for bar0
+ - second entry for bar1
+- interrupts: Must contain an entry for each entry in interrupt-names.
+ See ../interrupt-controller/interrupts.txt for details.
+- interrupt-names: Must include the following entries:
+ - stall
+ - nonstall
+- vdd-supply: regulator for supply voltage.
+- clocks: Must contain an entry for each entry in clock-names.
+ See ../clocks/clock-bindings.txt for details.
+- clock-names: Must include the following entries:
+ - gpu
+ - pwr
+- resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+- reset-names: Must include the following entries:
+ - gpu
+
+Example:
+
+ gpu@0,5700 {
+ compatible = "nvidia,gk20a";
+ reg = <0x0 0x5700 0x0 0x0100>,
+ <0x0 0x5800 0x0 0x0100>;
+ interrupts = ,
+;
+ interrupt-names = "stall", "nonstall";
+ vdd-supply = <_gpu>;
+ clocks = <_car TEGRA124_CLK_GPU>,
+<_car TEGRA124_CLK_PLL_P_OUT5>;
+ clock-names = "gpu", "pwr";
+ resets = <_car 184>;
+ reset-names = "gpu";
+ status = "disabled";
+ };
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/3] ARM: tegra: add GK20A GPU to Tegra124 DT
From: Thierry Reding
Add the GK20A device node to Tegra124's device tree.
Signed-off-by: Thierry Reding
Signed-off-by: Alexandre Courbot
---
arch/arm/boot/dts/tegra124.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
index d675186d8eba..cc9e7504c2da 100644
--- a/arch/arm/boot/dts/tegra124.dtsi
+++ b/arch/arm/boot/dts/tegra124.dtsi
@@ -102,6 +102,21 @@
(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
};
+ gpu@0,5700 {
+ compatible = "nvidia,gk20a";
+ reg = <0x0 0x5700 0x0 0x0100>,
+ <0x0 0x5800 0x0 0x0100>;
+ interrupts = ,
+;
+ interrupt-names = "stall", "nonstall";
+ clocks = <_car TEGRA124_CLK_GPU>,
+<_car TEGRA124_CLK_PLL_P_OUT5>;
+ clock-names = "gpu", "pwr";
+ resets = <_car 184>;
+ reset-names = "gpu";
+ status = "disabled";
+ };
+
timer@0,60005000 {
compatible = "nvidia,tegra124-timer", "nvidia,tegra20-timer";
reg = <0x0 0x60005000 0x0 0x400>;
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/3] drm/nouveau: support for probing platform devices
This series adds support for probing platform devices on Nouveau, as well as the DT bindings for GK20A. It doesn't enable the GPU yet on Tegra boards since a few extra things need to be supported before that. This version is mostly identical to v2 but fixes an important issue: the drvdata must be set to the drm_device for sysfs to work, so the platform device structure now includes the nouveau_device flattened into it to let us compute the address of one from the other. Since the platform device resources (clocks, regulators, ...) need to live longer than the nouveau_device, they are stored into their own structure which is allocated separately. Changes since v2: * Allocate the nouveau_device flattened into the nouveau_platform_device to be able to compute one from another easily, without having to ressort on the drvdata which is required to store the drm_device. * Only propose the platform driver if a supported arch (Tegra for now) is enabled. * Move structure definitions into their own header file as some subdevs (e.g. clocks) will need to use them. Changes since v1: * Moved the platform device driver to its own module. This allows it to be more self-contained and saves us the need to export too many functions from nouveau_drm and nouveau_platform. * Register the DRM device without using the platform helpers, which is made possible by drm_dev_set_unique(). This allows us to catch and register the DRM device during platform probe. * Fixed the clock names in the DT bindings. * Removed the patches enabling GK20A on Venice2 and Jetson TK1 as support is not complete yet. Alexandre Courbot (2): drm/nouveau: support for probing platform devices ARM: tegra: of: add GK20A device tree binding Thierry Reding (1): ARM: tegra: add GK20A GPU to Tegra124 DT .../devicetree/bindings/gpu/nvidia,gk20a.txt | 43 + arch/arm/boot/dts/tegra124.dtsi| 15 ++ drivers/gpu/drm/nouveau/Kconfig| 8 + drivers/gpu/drm/nouveau/Makefile | 3 + drivers/gpu/drm/nouveau/nouveau_drm.c | 53 -- drivers/gpu/drm/nouveau/nouveau_drm.h | 8 + drivers/gpu/drm/nouveau/nouveau_platform.c | 182 + drivers/gpu/drm/nouveau/nouveau_platform.h | 49 ++ 8 files changed, 347 insertions(+), 14 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt create mode 100644 drivers/gpu/drm/nouveau/nouveau_platform.c create mode 100644 drivers/gpu/drm/nouveau/nouveau_platform.h -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/3] drm/nouveau: support for probing platform devices
Add a platform driver for Nouveau devices declared using the device tree
or platform data. This driver currently supports GK20A on Tegra
platforms and is only compiled for these platforms if Nouveau is
enabled.
Nouveau will probe the chip type itself using the BOOT0 register, so all
this driver really needs to do is to make sure the module is powered and
its clocks active before calling nouveau_drm_platform_probe().
Heavily based on work done by Thierry Reding.
Signed-off-by: Thierry Reding
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/nouveau/Kconfig| 8 ++
drivers/gpu/drm/nouveau/Makefile | 3 +
drivers/gpu/drm/nouveau/nouveau_drm.c | 53 ++---
drivers/gpu/drm/nouveau/nouveau_drm.h | 8 ++
drivers/gpu/drm/nouveau/nouveau_platform.c | 182 +
drivers/gpu/drm/nouveau/nouveau_platform.h | 49
6 files changed, 289 insertions(+), 14 deletions(-)
create mode 100644 drivers/gpu/drm/nouveau/nouveau_platform.c
create mode 100644 drivers/gpu/drm/nouveau/nouveau_platform.h
diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig
index 637c29a33127..d4abaebfc35b 100644
--- a/drivers/gpu/drm/nouveau/Kconfig
+++ b/drivers/gpu/drm/nouveau/Kconfig
@@ -25,6 +25,14 @@ config DRM_NOUVEAU
help
Choose this option for open-source nVidia support.
+config NOUVEAU_PLATFORM_DRIVER
+ tristate "Nouveau (nVidia) integrated GPUs"
+ depends on DRM_NOUVEAU && ARCH_TEGRA
+ default y
+ help
+ Support for Nouveau platform driver, used for integrated GPUs as found
+ on NVIDIA Tegra K1.
+
config NOUVEAU_DEBUG
int "Maximum debug level"
depends on DRM_NOUVEAU
diff --git a/drivers/gpu/drm/nouveau/Makefile b/drivers/gpu/drm/nouveau/Makefile
index 8b307e143632..f55f0f34aef9 100644
--- a/drivers/gpu/drm/nouveau/Makefile
+++ b/drivers/gpu/drm/nouveau/Makefile
@@ -349,3 +349,6 @@ nouveau-$(CONFIG_DRM_NOUVEAU_BACKLIGHT) +=
nouveau_backlight.o
nouveau-$(CONFIG_DEBUG_FS) += nouveau_debugfs.o
obj-$(CONFIG_DRM_NOUVEAU)+= nouveau.o
+
+# platform driver
+obj-$(CONFIG_NOUVEAU_PLATFORM_DRIVER) += nouveau_platform.o
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index ddd83756b9a2..78295261c350 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -494,10 +494,9 @@ nouveau_drm_unload(struct drm_device *dev)
return 0;
}
-static void
-nouveau_drm_remove(struct pci_dev *pdev)
+void
+nouveau_drm_device_remove(struct drm_device *dev)
{
- struct drm_device *dev = pci_get_drvdata(pdev);
struct nouveau_drm *drm = nouveau_drm(dev);
struct nouveau_object *device;
@@ -508,6 +507,15 @@ nouveau_drm_remove(struct pci_dev *pdev)
nouveau_object_ref(NULL, );
nouveau_object_debug();
}
+EXPORT_SYMBOL(nouveau_drm_device_remove);
+
+static void
+nouveau_drm_remove(struct pci_dev *pdev)
+{
+ struct drm_device *dev = pci_get_drvdata(pdev);
+
+ nouveau_drm_device_remove(dev);
+}
static int
nouveau_do_suspend(struct drm_device *dev, bool runtime)
@@ -1003,24 +1011,41 @@ nouveau_drm_pci_driver = {
.driver.pm = _pm_ops,
};
-int nouveau_drm_platform_probe(struct platform_device *pdev)
+struct drm_device *
+nouveau_platform_device_create_(struct platform_device *pdev, int size,
+ void **pobject)
{
- struct nouveau_device *device;
- int ret;
+ struct drm_device *drm;
+ int err;
- ret = nouveau_device_create(pdev, NOUVEAU_BUS_PLATFORM,
+ err = nouveau_device_create_(pdev, NOUVEAU_BUS_PLATFORM,
nouveau_platform_name(pdev),
dev_name(>dev), nouveau_config,
- nouveau_debug, );
-
- ret = drm_platform_init(, pdev);
- if (ret) {
- nouveau_object_ref(NULL, (struct nouveau_object **));
- return ret;
+ nouveau_debug, size, pobject);
+ if (err)
+ return ERR_PTR(err);
+
+ drm = drm_dev_alloc(, >dev);
+ if (!drm) {
+ err = -ENOMEM;
+ goto err_free;
}
- return ret;
+ err = drm_dev_set_unique(drm, "%s", dev_name(>dev));
+ if (err < 0)
+ goto err_free;
+
+ drm->platformdev = pdev;
+ platform_set_drvdata(pdev, drm);
+
+ return drm;
+
+err_free:
+ nouveau_object_ref(NULL, (struct nouveau_object **)pobject);
+
+ return ERR_PTR(err);
}
+EXPORT_SYMBOL(nouveau_platform_device_create_);
static int __init
nouveau_drm_init(void)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.h
b/drivers/gpu/drm/nouveau/nouveau_drm.h
index 7efbafaf7c1d..dc342232182d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.h
@@ -39,6 +39,7 @@
#include
Re: [PATCH 00/13] AT91: PIT: Cleanups and move to drivers/clocksource
Hello Maxime, On 25/06/2014 15:06, Maxime Ripard wrote: > Hi everyone, > > This series cleans up the PIT driver in order for it to not depend on > anything in mach-at91 anymore, and in the end move it out of > mach-at91. > > Along the way, these patches also do a bit of cleanup. > > This has been tested on a G45-EK without DT and an Xplained with DT. Except for the 2 nitpicks in patch 9 and 13, this series looks good to me. I was a bit afraid to see code for non DT board support go into this new driver (or driver rework), but you managed to get rid of all global variables and non static functions thanks to the early device approach, and that's great! Thanks for your work. Boris > > Thanks, > Maxime > > Maxime Ripard (13): > AT91: PIT: Follow the general coding rules > AT91: generic.h: Add include safe guards > AT91: PIT: Use of_have_populated_dt instead of CONFIG_OF > AT91: PIT: Rework probe functions > AT91: dt: Remove init_time definitions > AT91: PIT: Use consistent exit path in probe > AT91: PIT: Use pr_fmt > AT91: PIT: use request_irq instead of setup_irq > AT91: PIT: (Almost) remove the global variables > AT91: soc: Add init_time callback > AT91: Convert the boards to the init_time callback > AT91: PIT: Convert to an early_platform_device > AT91: PIT: Move the driver to drivers/clocksource > > arch/arm/mach-at91/Kconfig | 3 - > arch/arm/mach-at91/Makefile | 1 - > arch/arm/mach-at91/at91sam9260.c| 34 +++- > arch/arm/mach-at91/at91sam9261.c| 34 +++- > arch/arm/mach-at91/at91sam9263.c| 34 +++- > arch/arm/mach-at91/at91sam926x_time.c | 294 -- > arch/arm/mach-at91/at91sam9g45.c| 35 +++- > arch/arm/mach-at91/at91sam9rl.c | 34 +++- > arch/arm/mach-at91/board-afeb-9260v1.c | 2 +- > arch/arm/mach-at91/board-cam60.c| 2 +- > arch/arm/mach-at91/board-cpu9krea.c | 2 +- > arch/arm/mach-at91/board-dt-sam9.c | 10 -- > arch/arm/mach-at91/board-dt-sama5.c | 9 - > arch/arm/mach-at91/board-flexibity.c| 2 +- > arch/arm/mach-at91/board-foxg20.c | 2 +- > arch/arm/mach-at91/board-gsia18s.c | 2 +- > arch/arm/mach-at91/board-pcontrol-g20.c | 2 +- > arch/arm/mach-at91/board-sam9-l9260.c | 2 +- > arch/arm/mach-at91/board-sam9260ek.c| 2 +- > arch/arm/mach-at91/board-sam9261ek.c| 4 +- > arch/arm/mach-at91/board-sam9263ek.c| 2 +- > arch/arm/mach-at91/board-sam9g20ek.c| 4 +- > arch/arm/mach-at91/board-sam9m10g45ek.c | 2 +- > arch/arm/mach-at91/board-sam9rlek.c | 2 +- > arch/arm/mach-at91/board-snapper9260.c | 2 +- > arch/arm/mach-at91/board-stamp9g20.c| 4 +- > arch/arm/mach-at91/generic.h| 8 +- > arch/arm/mach-at91/setup.c | 5 + > arch/arm/mach-at91/soc.h| 1 + > drivers/clocksource/Kconfig | 4 + > drivers/clocksource/Makefile| 1 + > drivers/clocksource/at91sam926x_time.c | 304 > > 32 files changed, 506 insertions(+), 343 deletions(-) > delete mode 100644 arch/arm/mach-at91/at91sam926x_time.c > create mode 100644 drivers/clocksource/at91sam926x_time.c > -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] scripts/checkpatch.pl: Only emit LONG_LINE for --strict
On Wed, 2014-06-25 at 22:08 -0700, Josh Triplett wrote: > Now, arguably the four leading tabs on those lines suggest the need for > some code refactoring; personally, I'd suggest changing DEEP_INDENTATION > to flag 4+ tabs rather than 6+ tabs as it currently does. There are _way too many_ 4+ tab indents for that to be sensible. > "trigraphs"? Do you mean ternaries? Yeah, Yup, those. > Yeah, that one makes sense: if you have a comment to the right of a long > line, and the comment is what's making it long, it's easy enough to move > the comment before the line. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/2] block: virtio-blk: support multi vq per virtio-blk
On Thu, Jun 26, 2014 at 1:05 PM, Jens Axboe wrote: > On 2014-06-25 20:08, Ming Lei wrote: >> >> Hi, >> >> These patches try to support multi virtual queues(multi-vq) in one >> virtio-blk device, and maps each virtual queue(vq) to blk-mq's >> hardware queue. >> >> With this approach, both scalability and performance on virtio-blk >> device can get improved. >> >> For verifying the improvement, I implements virtio-blk multi-vq over >> qemu's dataplane feature, and both handling host notification >> from each vq and processing host I/O are still kept in the per-device >> iothread context, the change is based on qemu v2.0.0 release, and >> can be accessed from below tree: >> >> git://kernel.ubuntu.com/ming/qemu.git #v2.0.0-virtblk-mq.1 >> >> For enabling the multi-vq feature, 'num_queues=N' need to be added into >> '-device virtio-blk-pci ...' of qemu command line, and suggest to pass >> 'vectors=N+1' to keep one MSI irq vector per each vq, and the feature >> depends on x-data-plane. >> >> Fio(libaio, randread, iodepth=64, bs=4K, jobs=N) is run inside VM to >> verify the improvement. >> >> I just create a small quadcore VM and run fio inside the VM, and >> num_queues of the virtio-blk device is set as 2, but looks the >> improvement is still obvious. >> >> 1), about scalability >> - without mutli-vq feature >> -- jobs=2, thoughput: 145K iops >> -- jobs=4, thoughput: 100K iops >> - with mutli-vq feature >> -- jobs=2, thoughput: 193K iops >> -- jobs=4, thoughput: 202K iops >> >> 2), about thoughput >> - without mutli-vq feature >> -- thoughput: 145K iops >> - with mutli-vq feature >> -- thoughput: 202K iops > > > Of these numbers, I think it's important to highlight that the 2 thread case > is 33% faster and the 2 -> 4 thread case scales linearly (100%) while the > pre-patch case sees negative scaling going from 2 -> 4 threads (-39%). This is because my qemu implementation on multi vq only uses single iothread to handle requests from all vqs, and the only iothread is already at full load now, that said on host side the same fio test(single job) results is ~200K iops too. > > I haven't run your patches yet, but from looking at the code, it looks good. > It's pretty straightforward. See feel free to add my reviewed-by. Thanks a lot. > > Rusty, do you want to ack this (and I'll slurp it up for 3.17) or take this > yourself? Or something else? That is great if this can be merged to 3.17. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 13/13] AT91: PIT: Move the driver to drivers/clocksource
On 25/06/2014 15:06, Maxime Ripard wrote:
> Now that we don't depend on anyting in the mach-at91 directory, we can just
> move the driver to where it belongs.
>
> Signed-off-by: Maxime Ripard
> ---
> arch/arm/mach-at91/Kconfig | 4
> arch/arm/mach-at91/Makefile| 1 -
> drivers/clocksource/Kconfig| 4
> drivers/clocksource/Makefile | 1 +
> {arch/arm/mach-at91 => drivers/clocksource}/at91sam926x_time.c | 0
> 5 files changed, 5 insertions(+), 5 deletions(-)
> rename {arch/arm/mach-at91 => drivers/clocksource}/at91sam926x_time.c (100%)
>
> diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
> index a64412a020d3..b10db0990999 100644
> --- a/arch/arm/mach-at91/Kconfig
> +++ b/arch/arm/mach-at91/Kconfig
> @@ -36,10 +36,6 @@ config AT91_SAM9G45_RESET
> bool
> default !ARCH_AT91X40
>
> -config AT91_SAM9_TIME
> - select CLKSRC_OF if OF
> - bool
> -
> config HAVE_AT91_SMD
> bool
>
> diff --git a/arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile
> index 78e9cec282f4..1a916ececbfd 100644
> --- a/arch/arm/mach-at91/Makefile
> +++ b/arch/arm/mach-at91/Makefile
> @@ -10,7 +10,6 @@ obj-:=
> obj-$(CONFIG_OLD_CLK_AT91) += clock.o
> obj-$(CONFIG_AT91_SAM9_ALT_RESET) += at91sam9_alt_reset.o
> obj-$(CONFIG_AT91_SAM9G45_RESET) += at91sam9g45_reset.o
> -obj-$(CONFIG_AT91_SAM9_TIME) += at91sam926x_time.o
> obj-$(CONFIG_SOC_AT91SAM9) += sam9_smc.o
>
> # CPU-specific support
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index 065131cbfcc0..cd8b73ddbef3 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -118,6 +118,10 @@ config CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
> help
>Use ARM global timer clock source as sched_clock
>
> +config AT91_SAM9_TIME
> + select CLKSRC_OF if OF
> + bool
> +
> config CLKSRC_METAG_GENERIC
> def_bool y if METAG
> help
> diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
> index 800b1303c236..3088928070f8 100644
> --- a/drivers/clocksource/Makefile
> +++ b/drivers/clocksource/Makefile
> @@ -1,5 +1,6 @@
> obj-$(CONFIG_CLKSRC_OF) += clksrc-of.o
> obj-$(CONFIG_ATMEL_TCB_CLKSRC) += tcb_clksrc.o
> +obj-$(CONFIG_AT91_SAM9_TIME) += at91sam926x_time.o
I would rename both Kconfig and source file name into ATMEL_PIT and
atmel_pit.c (or AT91_PIT and atmel_pit.c) to cleary show that this
driver add support for the PIT block.
> obj-$(CONFIG_X86_PM_TIMER) += acpi_pm.o
> obj-$(CONFIG_SCx200HR_TIMER) += scx200_hrt.o
> obj-$(CONFIG_CS5535_CLOCK_EVENT_SRC) += cs5535-clockevt.o
> diff --git a/arch/arm/mach-at91/at91sam926x_time.c
> b/drivers/clocksource/at91sam926x_time.c
> similarity index 100%
> rename from arch/arm/mach-at91/at91sam926x_time.c
> rename to drivers/clocksource/at91sam926x_time.c
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] USB: ehci-pci: USB host controller support for Intel Quark X1000
> > This patch is to enable USB host controller for Intel Quark X1000. Add >> pci quirks to adjust the packet buffer in/out threshold value, and > >ensure EHCI packet buffer i/o threshold value is reconfigured to half > > > What is the packet buffer in/out threshold value and why does it need to be > reconfigured to half? > I go through the hardware specification carefully again. The EHCI buffer packet depth can be 512 bytes, and the in/out threshold is programmable and can be programmed to 512 bytes (0x80 DWord) only when isochronous/interrupt transactions are not initiated by the host controller. The default threshold value for Quark X1000 is 0x20 DWord, so this patch try to program it as maximal as possible, and it is 0x7F Dword since the host controller initiates isochronous/interrupt transactions . I will update the description in PATCH v2. > > + val = readl(op_reg_base + EHCI_INSNREG01); > > + dev_printk(KERN_INFO, >dev, "INSNREG01 is 0x%08x\n", val); > > + > > + val = EHCI_INSNREG01_THRESH; > > + > > + writel(val, op_reg_base + EHCI_INSNREG01); > > + > > + val = readl(op_reg_base + EHCI_INSNREG01); > > + dev_printk(KERN_INFO, >dev, "INSNREG01 is 0x%08x\n", val); > > What good will these log messages do anybody? Is there any reason not to > make them debug messages? Or even leave them out entirely, since you > pretty much know beforehand what they're going to say? > These messages are not necessary, I will remove them. > > + > > + iounmap(base); > > + > > +} > > +EXPORT_SYMBOL_GPL(usb_set_qrk_bulk_thresh); > > None of this material belongs in pci-quirks.c. Please move it into > ehci-pci.c. > OK. I will move them to ehci-pci.c, since these two functions will not be called by other modules. > Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2 v2] i2c: exynos5: remove extra line and fix an assignment
This patch does the following in exynos5_i2c_message_start() function
1. Fixes an assignment
As, "i2c_auto_conf" is initialized to '0' at the beginning of the
function and HSI2C_READ_WRITE is defined as (1u << 16)
Using "|=" for the first assignment is more readable.
2. Removes an extra line
Signed-off-by: Naveen Krishna Chatradhi
---
Changes since v1:
Edited commit message for clarity
drivers/i2c/busses/i2c-exynos5.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-exynos5.c
index 0d1a7bc..4c2e6f3 100644
--- a/drivers/i2c/busses/i2c-exynos5.c
+++ b/drivers/i2c/busses/i2c-exynos5.c
@@ -525,7 +525,7 @@ static void exynos5_i2c_message_start(struct exynos5_i2c
*i2c, int stop)
if (i2c->msg->flags & I2C_M_RD) {
i2c_ctl |= HSI2C_RXCHON;
- i2c_auto_conf = HSI2C_READ_WRITE;
+ i2c_auto_conf |= HSI2C_READ_WRITE;
trig_lvl = (i2c->msg->len > i2c->variant->fifo_depth) ?
(i2c->variant->fifo_depth * 3 / 4) : i2c->msg->len;
@@ -548,7 +548,6 @@ static void exynos5_i2c_message_start(struct exynos5_i2c
*i2c, int stop)
writel(fifo_ctl, i2c->regs + HSI2C_FIFO_CTL);
writel(i2c_ctl, i2c->regs + HSI2C_CTL);
-
/*
* Enable interrupts before starting the transfer so that we don't
* miss any INT_I2C interrupts.
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2 v2] i2c: exynos5: remove an unnecessary read of FIFO_STATUS register
This patch removes an extra read of FIFO_STATUS register in the interrrupt
service routine. Which is read again before the actual use.
Signed-off-by: Naveen Krishna Chatradhi
---
Changes since v1:
None
drivers/i2c/busses/i2c-exynos5.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-exynos5.c
index 63d2292..0d1a7bc 100644
--- a/drivers/i2c/busses/i2c-exynos5.c
+++ b/drivers/i2c/busses/i2c-exynos5.c
@@ -405,7 +405,6 @@ static irqreturn_t exynos5_i2c_irq(int irqno, void *dev_id)
int_status = readl(i2c->regs + HSI2C_INT_STATUS);
writel(int_status, i2c->regs + HSI2C_INT_STATUS);
- fifo_status = readl(i2c->regs + HSI2C_FIFO_STATUS);
/* handle interrupt related to the transfer status */
if (int_status & HSI2C_INT_I2C) {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[mempolicy] 5507231dd04: -18.2% vm-scalability.migrate_mbps
Hi Naoya,
FYI, we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git am437x-starterkit
commit 5507231dd04d3d68796bafe83e6a20c985a0ef68 ("mempolicy: apply page table walker
on queue_pages_range()")
test case: ivb44/vm-scalability/300s-migrate
8c81f3eeb336567 5507231dd04d3d68796bafe83
--- -
347258 ~ 0% -18.2% 284195 ~ 0% TOTAL vm-scalability.migrate_mbps
0.00 +Inf% 0.94 ~ 7% TOTAL
perf-profile.cpu-cycles._raw_spin_lock.__walk_page_range.walk_page_range.queue_pages_range.migrate_to_node
11.49 ~ 1%-100.0% 0.00 ~ 0% TOTAL
perf-profile.cpu-cycles.vm_normal_page.queue_pages_range.migrate_to_node.do_migrate_pages.SYSC_migrate_pages
69.40 ~ 0%-100.0% 0.00 ~ 0% TOTAL
perf-profile.cpu-cycles.queue_pages_range.migrate_to_node.do_migrate_pages.SYSC_migrate_pages.sys_migrate_pages
3.68 ~ 3%-100.0% 0.00 ~ 0% TOTAL
perf-profile.cpu-cycles.vm_normal_page.migrate_to_node.do_migrate_pages.SYSC_migrate_pages.sys_migrate_pages
0.00 +Inf% 4.51 ~ 2% TOTAL
perf-profile.cpu-cycles.vm_normal_page.__walk_page_range.walk_page_range.queue_pages_range.migrate_to_node
0.00 +Inf% 8.36 ~ 1% TOTAL
perf-profile.cpu-cycles.__walk_page_range.walk_page_range.queue_pages_range.migrate_to_node.do_migrate_pages
1.17 ~ 4%-100.0% 0.00 ~ 0% TOTAL
perf-profile.cpu-cycles._raw_spin_lock.queue_pages_range.migrate_to_node.do_migrate_pages.SYSC_migrate_pages
0.00 +Inf% 9.30 ~ 2% TOTAL
perf-profile.cpu-cycles.vm_normal_page.queue_pages_pte.__walk_page_range.walk_page_range.queue_pages_range
0.00 +Inf% 63.92 ~ 1% TOTAL
perf-profile.cpu-cycles.queue_pages_pte.__walk_page_range.walk_page_range.queue_pages_range.migrate_to_node
61 ~32%+363.8%286 ~10% TOTAL
numa-vmstat.node0.nr_unevictable
257 ~30%+345.5% 1147 ~10% TOTAL
numa-meminfo.node0.Unevictable
1133 ~ 8%+129.0% 2596 ~ 0% TOTAL meminfo.Unevictable
282 ~ 8%+129.1%647 ~ 0% TOTAL proc-vmstat.nr_unevictable
93913 ~ 7% -49.8% 47172 ~ 3% TOTAL softirqs.RCU
113808 ~ 1% -45.4% 62087 ~ 0% TOTAL softirqs.SCHED
362197 ~ 0% -32.9% 243163 ~ 0% TOTAL cpuidle.C6-IVT.usage
1.49 ~ 3% -19.6% 1.20 ~ 4% TOTAL
perf-profile.cpu-cycles.intel_idle.cpuidle_enter_state.cpuidle_enter.cpu_startup_entry.start_secondary
743815 ~ 2% -20.3% 592628 ~ 6% TOTAL proc-vmstat.pgmigrate_fail
310 ~ 6% +16.6%362 ~ 8% TOTAL
numa-vmstat.node1.nr_unevictable
1243 ~ 6% +16.5% 1448 ~ 8% TOTAL
numa-meminfo.node1.Unevictable
1230 ~ 6% +16.6% 1434 ~ 8% TOTAL numa-meminfo.node1.Mlocked
307 ~ 6% +16.7%358 ~ 8% TOTAL numa-vmstat.node1.nr_mlock
3943910 ~ 0% -12.3%3459206 ~ 0% TOTAL proc-vmstat.pgfault
4402 ~ 3% -13.4% 3812 ~ 5% TOTAL
numa-meminfo.node1.KernelStack
15303 ~ 7% -17.5% 12621 ~ 9% TOTAL slabinfo.kmalloc-192.num_objs
15301 ~ 7% -17.5% 12621 ~ 9% TOTAL
slabinfo.kmalloc-192.active_objs
30438 ~ 0% +91.0% 58142 ~ 0% TOTAL
time.involuntary_context_switches
162 ~ 3% +81.9%296 ~ 0% TOTAL time.system_time
53 ~ 3% +81.1% 96 ~ 0% TOTAL
time.percent_of_cpu_this_job_got
2586283 ~ 0% -18.5%2107842 ~ 0% TOTAL time.minor_page_faults
48619 ~ 0% -18.1% 39800 ~ 0% TOTAL
time.voluntary_context_switches
2037 ~ 0% -17.7% 1677 ~ 0% TOTAL vmstat.system.in
2206 ~ 0% -4.7% 2101 ~ 0% TOTAL vmstat.system.cs
~ 1% -3.6%~ 1% TOTAL turbostat.Cor_W
~ 1% -2.2%~ 1% TOTAL turbostat.Pkg_W
2.17 ~ 0% -1.4% 2.14 ~ 0% TOTAL turbostat.%c0
Legend:
~XX%- stddev percent
[+-]XX% - change percent
time.system_time
300 O+O--O-O-O--O-O-O--O-O-O--O-O-O--O-O-O--O-O-O-+
| |
280 ++|
260 ++|
| |
240 ++|
| |
220 ++|
| |
200 ++|
180 ++
Re: [PATCH 09/13] AT91: PIT: (Almost) remove the global variables
Hello Maxime, On 25/06/2014 15:06, Maxime Ripard wrote: > The timer driver is using some global variables to define some variables it > has > to use in most of its functions, like the base address. > > Use some container_of calls to have a single dynamic (and local) variable to > hold this content. > > The only exception is in the !DT case, where the call chain to > at91sam926x_ioremap_pit and then at91sam926x_pit_init as init_time makes it > hard for the moment to pass the physical address of the timer. > > Signed-off-by: Maxime Ripard > --- > arch/arm/mach-at91/at91sam926x_time.c | 179 > -- > 1 file changed, 108 insertions(+), 71 deletions(-) > > diff --git a/arch/arm/mach-at91/at91sam926x_time.c > b/arch/arm/mach-at91/at91sam926x_time.c > index 9678ac391a81..f2c463567beb 100644 > --- a/arch/arm/mach-at91/at91sam926x_time.c > +++ b/arch/arm/mach-at91/at91sam926x_time.c > @@ -20,6 +20,7 @@ > #include > #include > #include > +#include > [...] > unsignedbits; > @@ -186,67 +195,95 @@ static void __init at91sam926x_pit_common_init(unsigned > int pit_irq) >* Use our actual MCK to figure out how many MCK/16 ticks per >* 1/HZ period (instead of a compile-time constant LATCH). >*/ > - pit_rate = clk_get_rate(mck) / 16; > - pit_cycle = (pit_rate + HZ/2) / HZ; > - WARN_ON(((pit_cycle - 1) & ~AT91_PIT_PIV) != 0); > + pit_rate = clk_get_rate(data->mck) / 16; > + data->cycle = (pit_rate + HZ/2) / HZ; You could use DIV_ROUND_CLOSEST here. Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] scripts/checkpatch.pl: Only emit LONG_LINE for --strict
On Wed, Jun 25, 2014 at 09:16:51PM -0700, Joe Perches wrote: > On Wed, 2014-06-25 at 20:44 -0700, Josh Triplett wrote: > > On Wed, Jun 25, 2014 at 07:33:03PM -0700, Joe Perches wrote: > > > On Wed, 2014-06-25 at 19:24 -0700, Josh Triplett wrote: > > > > On Wed, Jun 25, 2014 at 05:05:07PM -0700, Joe Perches wrote: > > > > > On Wed, 2014-06-25 at 08:46 -0700, Josh Triplett wrote: > > > > > > Regardless of the long-standing debate over line width, checkpatch > > > > > > should not warn about it by default. > > > > > > > > > > I'm not getting involved here. > > > > > I don't care much one way or another. > > > [] > > > > I'm not asking you to get involved in the Great Line Length Debate; > > > > that's why I didn't attempt to patch CodingStyle or similar. However, I > > > > think it makes sense for *checkpatch* to stop emitting this warning. > > > > > > I think checkpatch should encourage people to write code in > > > a style that matches CodingStyle as well as the predominant > > > styles used in the rest of the kernel. > > > > Not arguing with that, but in this particular case the warning seems > > counterproductive to that goal, especially compared to the > > DEEP_INDENTATION warning. More subjective or "to taste" issues tend > > to have lower severity in checkpatch. And CodingStyle *already* says > > "unless exceeding 80 columns significantly increases > > readability" > > Just some suggestions off the top of my head. > > If the goal is to reduce long line lengths, then maybe > more warnings or --strict tests for things like: The goal is to make code more readable; a length guideline can help with that, but a hard limit does more harm than good. And notably, we don't *have* a hard limit, we have a guideline; however, checkpatch routinely gets treated as a hard requirement rather than a guideline, and as such it should avoid tests that have a high false-positive rate, which LONG_LINE does. > long variable names: (pick a length) > > some_long_variable_name_with_a_color To avoid encouraging people to disemvowel their variables. I'd suggest flagging identifiers_with_too_many_words or IdentifiersWithTooManyWords instead. > consecutive dereferences where a temporary might be better: > > foo->bar[baz].member1 = 1; > foo->bar[baz].member2 = 2; That one seems better done with coccinelle, actually. > Multiple logical tests on a single line: > > foo > bar && baz < quz && etc... If any individual test takes up a significant number of columns, sure. > Arguments after column 80 > > 1 > 1 2 3 4 5 6 7 > 8 9 0 > 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890 > result = some_long_function(some_arg(arg1, arg2), another_arg(arg3, > arg4), 4); > > where a single argument of a short length before a > statement terminating ; may be ignored, but a longer > argument list may not. That one seems like one of the most common cases where the 80-column rule can result in less readable code. On the one hand, in the case above, something like this would usually (but not always) improve the code: result = some_long_function( some_arg(arg1, arg2), another_arg(arg1, arg2), 4); On the other hand, breaking within the arguments of some_arg or another_arg seems completely and utterly wrong, and breaking around a binary operator within the argument list would likewise make it painful to read. I've seen things like that in numerous patches. where a single expression that would only take ~100ish characters gets broken across half a dozen lines because it starts with a few tabs worth of indentation and has moderate-length (but completely reasonable) names: result = sensible_function_name( sensible_variable_name, something(smallish) + something_else, variable_name & ~SOME_BIT_NAME); That seems far more readable if written as result = sensible_function_name( sensible_variable_name, something(smallish) + something_else, variable_name & ~SOME_BIT_NAME); even though the last two lines extend past 80 characters. Now, arguably the four leading tabs on those lines suggest the need for some code refactoring; personally, I'd suggest changing DEEP_INDENTATION to flag 4+ tabs rather than 6+ tabs as it currently does. That would
Re: [PATCH v2 0/2] block: virtio-blk: support multi vq per virtio-blk
On 2014-06-25 20:08, Ming Lei wrote: Hi, These patches try to support multi virtual queues(multi-vq) in one virtio-blk device, and maps each virtual queue(vq) to blk-mq's hardware queue. With this approach, both scalability and performance on virtio-blk device can get improved. For verifying the improvement, I implements virtio-blk multi-vq over qemu's dataplane feature, and both handling host notification from each vq and processing host I/O are still kept in the per-device iothread context, the change is based on qemu v2.0.0 release, and can be accessed from below tree: git://kernel.ubuntu.com/ming/qemu.git #v2.0.0-virtblk-mq.1 For enabling the multi-vq feature, 'num_queues=N' need to be added into '-device virtio-blk-pci ...' of qemu command line, and suggest to pass 'vectors=N+1' to keep one MSI irq vector per each vq, and the feature depends on x-data-plane. Fio(libaio, randread, iodepth=64, bs=4K, jobs=N) is run inside VM to verify the improvement. I just create a small quadcore VM and run fio inside the VM, and num_queues of the virtio-blk device is set as 2, but looks the improvement is still obvious. 1), about scalability - without mutli-vq feature -- jobs=2, thoughput: 145K iops -- jobs=4, thoughput: 100K iops - with mutli-vq feature -- jobs=2, thoughput: 193K iops -- jobs=4, thoughput: 202K iops 2), about thoughput - without mutli-vq feature -- thoughput: 145K iops - with mutli-vq feature -- thoughput: 202K iops Of these numbers, I think it's important to highlight that the 2 thread case is 33% faster and the 2 -> 4 thread case scales linearly (100%) while the pre-patch case sees negative scaling going from 2 -> 4 threads (-39%). I haven't run your patches yet, but from looking at the code, it looks good. It's pretty straightforward. See feel free to add my reviewed-by. Rusty, do you want to ack this (and I'll slurp it up for 3.17) or take this yourself? Or something else? -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] i2c: exynos5: fix minor styling nits
Hello Sachin,
On 25 June 2014 16:19, Sachin Kamat wrote:
> Hi Naveen,
>
> On Wed, Jun 25, 2014 at 4:08 PM, Naveen Krishna Chatradhi
> wrote:
>> This patch removes an extra line and fixes a styling nit
>> in exynos5_i2c_message_start()
>>
>> Signed-off-by: Naveen Krishna Chatradhi
>> ---
>> drivers/i2c/busses/i2c-exynos5.c |3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-exynos5.c
>> b/drivers/i2c/busses/i2c-exynos5.c
>> index 0d1a7bc..4c2e6f3 100644
>> --- a/drivers/i2c/busses/i2c-exynos5.c
>> +++ b/drivers/i2c/busses/i2c-exynos5.c
>> @@ -525,7 +525,7 @@ static void exynos5_i2c_message_start(struct exynos5_i2c
>> *i2c, int stop)
>> if (i2c->msg->flags & I2C_M_RD) {
>> i2c_ctl |= HSI2C_RXCHON;
>>
>> - i2c_auto_conf = HSI2C_READ_WRITE;
>> + i2c_auto_conf |= HSI2C_READ_WRITE;
>
> This change looks more than just a styling nit. Please update the commit
> message
> accordingly.
Yea, change looks so.
But, This is not an going to change the way code works.
As, i2c_auto_conf is initialized to '0' at the beginning of the function
and HSI2C_READ_WRITE is defined as (1u << 16)
This being the 1st usage, I thought using "|=" is better way of assignment.
Will edit the commit message accordingly.
>
> --
> Regards,
> Sachin.
Thanks,
--
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: scsi-mq V2
On 2014-06-25 10:51, Christoph Hellwig wrote: This is the second post of the scsi-mq series. At this point the code is ready for merging and use by developers and early adopters. The core blk-mq code isn't that suitable for slow devices yet, mostly due to the lack of an I/O scheduler, but Jens is working on it. Similarly there is no dm-multipath support for drivers using blk-mq yet, but I'm working on it. It should also be noted that the code doesn't actually support multiple hardware queues or fine grained tuning of the blk-mq parameters yet. All these could be added fairly easily as soon as low-level drivers want to make use of them. The amount of chances to the existing code are fairly small, and mostly speedups or cleanups that also apply to the old path as well. Because of this I also haven't bothered to put it under a config option, just like the blk-mq core. The usage of blk-mq dramatically decreases CPU usage under all workloads going down from 100% CPU usage that the old setup can hit easily to usually less than 20% for maxing out storage subsystems with 512byte reads and writes, and it allows to easily archive millions of IOPS. Bart and Robert have helped with some very detailed measurements that they might be able to send in reply to this, although these usually involve significantly reworked low level drivers to avoid other bottle necks. One major objection to previous iterations of this code was the simple replacement of the host_lock with atomic counters for the host and busy counters. The host_lock avoidance on it's own already improves performance, and with the patch to avoid maintaining the per-target busy counter unless needed we now replace a lock round trip on the host_lock with just a single atomic increment in the submission path, and a single atomic decrement in completion path, which should provide benefits even for the oddest RISC architecture. Longer term I'd still love to get rid of these entirely and use the counters in blk-mq, but due to the difference in how they are maintained this doesn't seem feasible as long as we still need to support the legacy request code path. Changes from V1: - rebased on top of the core-for-3.17 branch, most notable the scsi logging changes - fixed handling of cmd_list to prevent crashes for some heavy workloads - fixed incorrect handling of !target->can_queue - avoid scheduling a workqueue on I/O completions when no queues are congested In addition to the patches in this thread there also is a git available at: git://git.infradead.org/users/hch/scsi.git scsi-mq.2 You can add my acked/reviewed-by to the series. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] scripts/checkpatch.pl: Only emit LONG_LINE for --strict
On Wed, Jun 25, 2014 at 11:59:59PM -0400, Greg KH wrote: > On Wed, Jun 25, 2014 at 07:24:49PM -0700, Josh Triplett wrote: > > On Wed, Jun 25, 2014 at 05:05:07PM -0700, Joe Perches wrote: > > > On Wed, 2014-06-25 at 08:46 -0700, Josh Triplett wrote: > > > > Regardless of the long-standing debate over line width, checkpatch > > > > should not warn about it by default. > > > > > > I'm not getting involved here. > > > > > > I don't care much one way or another. > > > > > > I did submit a patch where I ignored 80 > > > columns recently and I was told to try > > > again by the maintainer. > > > > I'm not asking you to get involved in the Great Line Length Debate; > > that's why I didn't attempt to patch CodingStyle or similar. However, I > > think it makes sense for *checkpatch* to stop emitting this warning. > > > > I'm hoping that Greg will chime in, as the maintainer of staging and the > > recipient of a huge number of checkpatch-motivated patches. > > I have no problem with the existing checkpatch.pl tool and it calling > out 80 columns as a problem that needs to be fixed. So I don't like > this patch at all. I'd like to stop seeing patches go by that produce heavily over-wrapped code that becomes less readable; it's far easier to fix checkpatch than to tell people to ignore its false positives. How would you feel about a patch that flagged long lines with a warning in patch mode, but not in file mode? - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] hwmon fixes for 3.16-rc3
Hi Linus, Please pull hwmon fixes for Linux 3.16-rc3 from signed tag: git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git hwmon-for-linus Thanks, Guenter -- The following changes since commit a497c3ba1d97fc69c1e78e7b96435ba8c2cb42ee: Linux 3.16-rc2 (2014-06-21 19:02:54 -1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git tags/hwmon-for-linus for you to fetch changes up to d26e0da783adbb94977f60dec9a035b427813b83: hwmon: (gpio-fan) Change name used in hwmon_device_register_with_groups (2014-06-25 15:16:09 -0700) Various minor fixes Axel Lin (1): hwmon: (w83l786ng) Report correct minimum fan speed Josef Gajdusek (1): hwmon: (emc1403) Fix missing 'select REGMAP_I2C' in Kconfig Julien D'Ascenzio (1): hwmon: (gpio-fan) Change name used in hwmon_device_register_with_groups Naveen Krishna Chatradhi (2): devicetree: bindings: Document murata vendor prefix hwmon: (ntc_thermistor) Use the manufacturer name properly .../devicetree/bindings/arm/samsung/exynos-adc.txt | 2 +- .../devicetree/bindings/hwmon/ntc_thermistor.txt | 20 ++-- .../devicetree/bindings/vendor-prefixes.txt | 1 + Documentation/hwmon/ntc_thermistor | 8 drivers/hwmon/Kconfig| 6 -- drivers/hwmon/gpio-fan.c | 2 +- drivers/hwmon/ntc_thermistor.c | 14 +- drivers/hwmon/w83l786ng.c| 2 +- 8 files changed, 39 insertions(+), 16 deletions(-) signature.asc Description: Digital signature
Re: [PATCH] scripts/checkpatch.pl: Only emit LONG_LINE for --strict
On Wed, 2014-06-25 at 20:44 -0700, Josh Triplett wrote: > On Wed, Jun 25, 2014 at 07:33:03PM -0700, Joe Perches wrote: > > On Wed, 2014-06-25 at 19:24 -0700, Josh Triplett wrote: > > > On Wed, Jun 25, 2014 at 05:05:07PM -0700, Joe Perches wrote: > > > > On Wed, 2014-06-25 at 08:46 -0700, Josh Triplett wrote: > > > > > Regardless of the long-standing debate over line width, checkpatch > > > > > should not warn about it by default. > > > > > > > > I'm not getting involved here. > > > > I don't care much one way or another. > > [] > > > I'm not asking you to get involved in the Great Line Length Debate; > > > that's why I didn't attempt to patch CodingStyle or similar. However, I > > > think it makes sense for *checkpatch* to stop emitting this warning. > > > > I think checkpatch should encourage people to write code in > > a style that matches CodingStyle as well as the predominant > > styles used in the rest of the kernel. > > Not arguing with that, but in this particular case the warning seems > counterproductive to that goal, especially compared to the > DEEP_INDENTATION warning. More subjective or "to taste" issues tend > to have lower severity in checkpatch. And CodingStyle *already* says > "unless exceeding 80 columns significantly increases > readability" Just some suggestions off the top of my head. If the goal is to reduce long line lengths, then maybe more warnings or --strict tests for things like: long variable names: (pick a length) some_long_variable_name_with_a_color consecutive dereferences where a temporary might be better: foo->bar[baz].member1 = 1; foo->bar[baz].member2 = 2; Multiple logical tests on a single line: foo > bar && baz < quz && etc... Arguments after column 80 1 1 2 3 4 5 6 7 8 9 0 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890 result = some_long_function(some_arg(arg1, arg2), another_arg(arg3, arg4), 4); where a single argument of a short length before a statement terminating ; may be ignored, but a longer argument list may not. Long trigraphs: should be on multiple lines Comments beyond 80 column No idea what's right. etc... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] mm: catch memory commitment underflow
On Thu, Jun 26, 2014 at 2:03 AM, Andrew Morton
wrote:
> On Wed, 25 Jun 2014 00:16:14 +0400 Konstantin Khlebnikov
> wrote:
>
>> This patch prints warning (if CONFIG_DEBUG_VM=y) when
>> memory commitment becomes too negative.
>>
>> ...
>>
>> --- a/mm/mmap.c
>> +++ b/mm/mmap.c
>> @@ -134,6 +134,12 @@ int __vm_enough_memory(struct mm_struct *mm, long
>> pages, int cap_sys_admin)
>> {
>> unsigned long free, allowed, reserve;
>>
>> +#ifdef CONFIG_DEBUG_VM
>> + WARN_ONCE(percpu_counter_read(_committed_as) <
>> + -(s64)vm_committed_as_batch * num_online_cpus(),
>> + "memory commitment underflow");
>> +#endif
>> +
>> vm_acct_memory(pages);
>
> The changelog doesn't describe the reasons for making the change.
>
> I assume this warning will detect the situation which the previous two
> patches just fixed?
Yep. Otherwise there is no way to validate these bugs, /proc/meminfo
hides negative values.
> Why not use VM_WARN_ON_ONCE()?
This patch is older than this macro.
Previously I've sent it in the last september and it was ignored. Now
I've found it again in my backlog.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT] Networking
1) Fix crash in ipvs tot_stats estimator, from Julian Anastasov. 2) Fix OOPS in nf_nat on netns removal, from Florian Westphal. 3) Really really really fix locking issues in slip and slcan tty write wakeups, from Tyler Hall. 4) Fix checksum offloading in fec driver, from Fugang Duan. 5) Off by one in BPF instruction limit test, from Kees Cook. 6) Need to clear all TSO capability flags when doing software TSO in tg3 driver, from Prashant Sreedharan. 7) Fix memory leak in vlan_reorder_header() error path, from Li RongQing. 8) Fix various bugs in xen-netfront and xen-netback multiqueue support, from David Vrabel and Wei Liu. 9) Fix deadlock in cxgb4 driver, from Li RongQing. 10) Prevent double free of no-cache DST entries, from Eric Dumazet. 11) Bad csum_start handling in skb_segment() leads to crashes when forwarding, from Tom Herbert. Please pull, thanks a lot! The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f: Linux 3.16-rc1 (2014-06-15 17:45:28 -1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master for you to fetch changes up to de843723f9b989178762196fb24dd050cbe20ca3: net: fix setting csum_start in skb_segment() (2014-06-25 20:45:54 -0700) Bjørn Mork (1): net: huawei_cdc_ncm: increase command buffer size Chin-Ran Lo (1): mwifiex: fix tx_info/rx_info overlap with PCIe dma_mapping Chris Metcalf (1): net: tile: fix unused variable warning Christian Riesch (1): ptp: In the testptp utility, use clock_adjtime from glibc when available Daniel Borkmann (2): net: sctp: propagate sysctl errors from proc_do* properly net: sctp: check proc_dointvec result in proc_sctp_do_auth Daniel Mack (3): net: phylib: add link_change_notify callback to phy device net: phy: at803x: use #defines for supported PHY ids net: phy: at803x: Add support for hardware reset Dave Jones (2): tcp: remove unnecessary tcp_sk assignment. hyperv: fix apparent cut-n-paste error in send path teardown David S. Miller (5): Merge git://git.kernel.org/.../pablo/nf Revert "net: return actual error on register_queue_kobjects" Merge branch 'for-davem' of git://git.kernel.org/.../linville/wireless Merge branch 'at803x' Merge branch 'xen-netfront' David Vrabel (2): xen-netfront: fix oops when disconnected from backend xen-netfront: recreate queues correctly when reconnecting Eric Dumazet (1): ipv4: fix dst race in sk_dst_get() Fengguang Wu (1): net: phy: at803x: fix coccinelle warnings Florian Westphal (2): netfilter: ctnetlink: fix refcnt leak in dying/unconfirmed list dumper netfilter: nf_nat: fix oops on netns removal Fugang Duan (1): net: fec: Don't clear IPV6 header checksum field when IP accelerator enable Jean Delvare (3): isdn: hisax: Merge Kconfig ifs isdn: hisax: Drop duplicate Kconfig entry ptp: ptp_pch depends on x86_32 Jie Liu (1): net: return actual error on register_queue_kobjects Johan Hedberg (9): Bluetooth: Fix incorrectly overriding conn->src_type Bluetooth: Fix check for connection encryption Bluetooth: Fix SSP acceptor just-works confirmation without MITM Bluetooth: Add clarifying comment for conn->auth_type Bluetooth: Fix setting correct authentication information for SMP STK Bluetooth: Fix indicating discovery state when canceling inquiry Bluetooth: Refactor discovery stopping into its own function Bluetooth: Reuse hci_stop_discovery function when cleaning up HCI state Bluetooth: Fix locking of hdev when calling into SMP code John W. Linville (2): Merge branch 'for-upstream' of git://git.kernel.org/.../bluetooth/bluetooth Merge branch 'master' of git://git.kernel.org/.../linville/wireless into for-davem Jukka Taimisto (1): Bluetooth: Fix deadlock in l2cap_conn_del() Julian Anastasov (1): ipvs: stop tot_stats estimator only under CONFIG_SYSCTL Kees Cook (1): net: filter: fix upper BPF instruction limit Ken-ichirou MATSUZAWA (1): netfilter: ctnetlink: add zone size to length Li RongQing (2): 8021q: fix a potential memory leak cxgb4: Not need to hold the adap_rcu_lock lock when read adap_rcu_list Marcin Kraglak (1): Bluetooth: Allow change security level on ATT_CID in slave role Maxime Ripard (1): net: allwinner: emac: Add missing free_irq Michael Braun (2): rt2800usb:fix efuse detection rt2800usb:fix hang during firmware load Mirko Lindner (1): skge: Added FS A8NE-FM to the list of 32bit DMA boards Mugunthan V N (1): drivers: net: cpsw: fix dual EMAC stall when connected to same switch Neal Cardwell (1): tcp: fix tcp_match_skb_to_sack() for unaligned SACK at end of an skb Neil Horman (1): vmxnet3: adjust ring
Re: [PATCH] scripts/checkpatch.pl: Only emit LONG_LINE for --strict
On Wed, Jun 25, 2014 at 07:24:49PM -0700, Josh Triplett wrote: > On Wed, Jun 25, 2014 at 05:05:07PM -0700, Joe Perches wrote: > > On Wed, 2014-06-25 at 08:46 -0700, Josh Triplett wrote: > > > Regardless of the long-standing debate over line width, checkpatch > > > should not warn about it by default. > > > > I'm not getting involved here. > > > > I don't care much one way or another. > > > > I did submit a patch where I ignored 80 > > columns recently and I was told to try > > again by the maintainer. > > I'm not asking you to get involved in the Great Line Length Debate; > that's why I didn't attempt to patch CodingStyle or similar. However, I > think it makes sense for *checkpatch* to stop emitting this warning. > > I'm hoping that Greg will chime in, as the maintainer of staging and the > recipient of a huge number of checkpatch-motivated patches. I have no problem with the existing checkpatch.pl tool and it calling out 80 columns as a problem that needs to be fixed. So I don't like this patch at all. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] shmem: update memory reservation on truncate
On Wed, 25 Jun 2014, Konstantin Khlebnikov wrote:
> Shared anonymous mapping created without MAP_NORESERVE holds memory
> reservation for whole range of shmem segment. Usually there is no way to
> change its size, but /proc//map_files/...
> (available if CONFIG_CHECKPOINT_RESTORE=y) allows to do that.
>
> This patch adjust memory reservation in shmem_setattr().
>
> Signed-off-by: Konstantin Khlebnikov
Acked-by: Hugh Dickins
Thank you, I knew nothing about this backdoor to shmem objects. Scary.
Was this really the only problem map_files access leads to? If you
did not do so already, please try to think through other possibilities.
I haven't begun, but perhaps it's not so bad. I guess the interaction
with mremap extension is benign - it's annoyed people in the past that
the underlying shmem object is not extended, but now here's a way that
it can be.
(I'll leave it to others comment on 3/3 if they wish.)
>
> ---
>
> exploit:
>
> #include
> #include
> #include
>
> int main(int argc, char **argv)
> {
> unsigned long addr;
> char path[100];
>
> /* charge 4KiB */
> addr = (unsigned long)mmap(NULL, 4096, PROT_READ|PROT_WRITE,
> MAP_SHARED|MAP_ANONYMOUS, -1, 0);
> sprintf(path, "/proc/self/map_files/%lx-%lx", addr, addr + 4096);
> truncate(path, 1 << 30);
> /* uncharge 1GiB */
> }
> ---
> mm/shmem.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/mm/shmem.c b/mm/shmem.c
> index 0aabcbd..a3c49d6 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -149,6 +149,19 @@ static inline void shmem_unacct_size(unsigned long
> flags, loff_t size)
> vm_unacct_memory(VM_ACCT(size));
> }
>
> +static inline int shmem_reacct_size(unsigned long flags,
> + loff_t oldsize, loff_t newsize)
> +{
> + if (!(flags & VM_NORESERVE)) {
> + if (VM_ACCT(newsize) > VM_ACCT(oldsize))
> + return security_vm_enough_memory_mm(current->mm,
> + VM_ACCT(newsize) - VM_ACCT(oldsize));
> + else if (VM_ACCT(newsize) < VM_ACCT(oldsize))
> + vm_unacct_memory(VM_ACCT(oldsize) - VM_ACCT(newsize));
> + }
> + return 0;
> +}
> +
> /*
> * ... whereas tmpfs objects are accounted incrementally as
> * pages are allocated, in order to allow huge sparse files.
> @@ -543,6 +556,10 @@ static int shmem_setattr(struct dentry *dentry, struct
> iattr *attr)
> loff_t newsize = attr->ia_size;
>
> if (newsize != oldsize) {
> + error = shmem_reacct_size(SHMEM_I(inode)->flags,
> + oldsize, newsize);
> + if (error)
> + return error;
> i_size_write(inode, newsize);
> inode->i_ctime = inode->i_mtime = CURRENT_TIME;
> }
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: fix setting csum_start in skb_segment()
From: Eric Dumazet
Date: Wed, 25 Jun 2014 12:51:01 -0700
> From: Tom Herbert
>
> Dave Jones reported that a crash is occurring in
...
> It looks like a likely culprit is that SKB_GSO_CB()->csum_start is
> not set correctly when doing non-scatter gather. We are using
> offset as opposed to doffset.
>
> Reported-by: Dave Jones
> Tested-by: Dave Jones
> Signed-off-by: Tom Herbert
> Signed-off-by: Eric Dumazet
> Fixes: 7e2b10c1e52ca ("net: Support for multiple checksums with gso")
Applied, thanks everyone.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] shmem: fix double uncharge in __shmem_file_setup()
On Wed, 25 Jun 2014, Konstantin Khlebnikov wrote: > If __shmem_file_setup() fails on struct file allocation it uncharges memory > commitment twice: first by shmem_unacct_size() and second time implicitly in > shmem_evict_inode() when it kills newly created inode. > This patch removes shmem_unacct_size() from error path if inode already here. > > Signed-off-by: Konstantin Khlebnikov Acked-by: Hugh Dickins Thank you for the patch, and thank you for your patience (or perhaps for your kindly concealed impatience): I realize that this (and the other two) have been languishing in the must-get-to-look-at-it-sometime end of my mailbox for nine months now - sorry. > --- > mm/shmem.c | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/mm/shmem.c b/mm/shmem.c > index 8f419cf..0aabcbd 100644 > --- a/mm/shmem.c > +++ b/mm/shmem.c > @@ -2895,16 +2895,16 @@ static struct file *__shmem_file_setup(const char > *name, loff_t size, > this.len = strlen(name); > this.hash = 0; /* will go */ > sb = shm_mnt->mnt_sb; > + path.mnt = mntget(shm_mnt); > path.dentry = d_alloc_pseudo(sb, ); > if (!path.dentry) > goto put_memory; > d_set_d_op(path.dentry, _ops); > - path.mnt = mntget(shm_mnt); > > res = ERR_PTR(-ENOSPC); > inode = shmem_get_inode(sb, NULL, S_IFREG | S_IRWXUGO, 0, flags); > if (!inode) > - goto put_dentry; > + goto put_memory; > > inode->i_flags |= i_flags; > d_instantiate(path.dentry, inode); > @@ -2912,19 +2912,19 @@ static struct file *__shmem_file_setup(const char > *name, loff_t size, > clear_nlink(inode); /* It is unlinked */ > res = ERR_PTR(ramfs_nommu_expand_for_mapping(inode, size)); > if (IS_ERR(res)) > - goto put_dentry; > + goto put_path; > > res = alloc_file(, FMODE_WRITE | FMODE_READ, > _file_operations); > if (IS_ERR(res)) > - goto put_dentry; > + goto put_path; > > return res; > > -put_dentry: > - path_put(); > put_memory: > shmem_unacct_size(flags, size); > +put_path: > + path_put(); > return res; > } > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] scripts/checkpatch.pl: Only emit LONG_LINE for --strict
On Wed, Jun 25, 2014 at 07:33:03PM -0700, Joe Perches wrote: > On Wed, 2014-06-25 at 19:24 -0700, Josh Triplett wrote: > > On Wed, Jun 25, 2014 at 05:05:07PM -0700, Joe Perches wrote: > > > On Wed, 2014-06-25 at 08:46 -0700, Josh Triplett wrote: > > > > Regardless of the long-standing debate over line width, checkpatch > > > > should not warn about it by default. > > > > > > I'm not getting involved here. > > > I don't care much one way or another. > [] > > I'm not asking you to get involved in the Great Line Length Debate; > > that's why I didn't attempt to patch CodingStyle or similar. However, I > > think it makes sense for *checkpatch* to stop emitting this warning. > > I think checkpatch should encourage people to write code in > a style that matches CodingStyle as well as the predominant > styles used in the rest of the kernel. Not arguing with that, but in this particular case the warning seems counterproductive to that goal, especially compared to the DEEP_INDENTATION warning. More subjective or "to taste" issues tend to have lower severity in checkpatch. And CodingStyle *already* says "unless exceeding 80 columns significantly increases readability" - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] video: hyperv: hyperv_fb: refresh the VM screen by force on VM panic
On Tue, Jun 24, 2014 at 09:44:14PM +, Dexuan Cui wrote: > >On Tue, Jun 24, 2014 at 08:29:17AM +0800, Dexuan Cui wrote: > >> Currently the VSC has no chance to notify the VSP of the dirty rectangle > >> on VM > >> panic because the notification work is done in a workqueue, and in panic() > >> the > >> kernel typically ends up in an infinite loop, and a typical kernel config > >> has > >> CONFIG_PREEMPT_VOLUNTARY=y and CONFIG_PREEMPT is not set, so a context > >> switch > >> can't happen in panic() and the workqueue won't have a chance to run. As a > >> result, the VM Connection window can't refresh until it's closed and we > >> re-connect to the VM. > >> > >> We can register a handler on panic_notifier_list: the handler can notify > >> the VSC and switch the framebuffer driver to a "synchronous mode", meaning > >> the VSC flushes any future framebuffer change to the VSP immediately. > >> > >> MS-TFS: 157532 > > > What is this line for? > > Hi Greg, > This line is for our internal bug repository. > We have an automated system to correlate bugs with fixes so that our test > team knows when a bug fix has been accepted upstream and they need to > write a new test case for it. > > The MS-TFS line has appeared in the commit description for a while if you > search for it in 'git log' of linux-next. > > Please let us know if you have further comments. Please don't add marker lines like this that provide no relevancy to anyone else. I don't allow gerrit ids for the same reason. If you want to refer to a public bug tracker, that's great, otherwise, don't include it. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-sunxi] Re: [PATCH v3 5/6] clk: sunxi: Add A23 clocks support
On Thu, Jun 26, 2014 at 4:20 AM, Maxime Ripard
wrote:
> On Tue, Jun 24, 2014 at 05:59:39PM +0800, Chen-Yu Tsai wrote:
>> The clock control unit on the A23 is similar to the one found on the A31.
>>
>> The AHB1, APB1, APB2 gates on the A23 are almost identical to the ones
>> on the A31, but some outputs are missing.
>>
>> The main CPU PLL (PLL1) however is like that on older Allwinner SoCs,
>> such as the A10 or A20, but the N factor starts from 1 instead of 0.
>>
>> This patch adds support for PLL1 and all the basic clock muxes and gates.
>>
>> Signed-off-by: Chen-Yu Tsai
>> ---
>> Documentation/devicetree/bindings/clock/sunxi.txt | 5 ++
>> drivers/clk/sunxi/clk-sunxi.c | 103
>> ++
>> 2 files changed, 108 insertions(+)
>>
>> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
>> index 6fe9492..d4832a7 100644
>> --- a/drivers/clk/sunxi/clk-sunxi.c
>> +++ b/drivers/clk/sunxi/clk-sunxi.c
[...]
>> @@ -673,6 +739,25 @@ static const struct div_data sun4i_axi_data __initconst
>> = {
>> .width = 2,
>> };
>>
>> +static const struct clk_div_table sun8i_a23_axi_table[] __initconst = {
>> + { .val = 0, .div = 1 },
>> + { .val = 1, .div = 2 },
>> + { .val = 2, .div = 3 },
>> + { .val = 3, .div = 4 },
>> + { .val = 4, .div = 4 },
>> + { .val = 5, .div = 4 },
>> + { .val = 6, .div = 4 },
>> + { .val = 7, .div = 4 },
>> + { } /* sentinel */
>> +};
>> +
>> +static const struct div_data sun8i_a23_axi_data __initconst = {
>> + .shift = 0,
>> + .pow= 0,
>
> These are the default value.
I am aware. This is consistent with all the other div_data
instances, which have all fields set regardless of default
values.
>> + .width = 3,
>> + .table = sun8i_a23_axi_table,
>> +};
>> +
>> static const struct div_data sun4i_ahb_data __initconst = {
>> .shift = 4,
>> .pow= 1,
[...]
> Looks fine otherwise,
>
> Acked-by: Maxime Ripard
If you're ok with being consistent, I'll add your acked-by
without changing it. Otherwise I'll remove the fields with
default values.
Thanks!
ChenYu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] sched: Fix compiler warnings
On 06/25/2014 05:59 PM, Stephen Rothwell wrote:
Hi Guenter,
[I know I'm a bit late to this, but ...]
On Tue, 24 Jun 2014 18:05:29 -0700 Guenter Roeck wrote:
diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
index 9d85318..e35d880 100644
--- a/arch/arm/kernel/topology.c
+++ b/arch/arm/kernel/topology.c
@@ -275,7 +275,7 @@ void store_cpu_topology(unsigned int cpuid)
cpu_topology[cpuid].socket_id, mpidr);
}
-static inline const int cpu_corepower_flags(void)
+static inline int cpu_corepower_flags(void)
{
return SD_SHARE_PKG_RESOURCES | SD_SHARE_POWERDOMAIN;
}
The only reference to this function is to take its address, so "inline"
is useless, right?
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 306f4f0..0376b05 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -872,21 +872,21 @@ enum cpu_idle_type {
#define SD_NUMA 0x4000 /* cross-node balancing */
#ifdef CONFIG_SCHED_SMT
-static inline const int cpu_smt_flags(void)
+static inline int cpu_smt_flags(void)
{
return SD_SHARE_CPUCAPACITY | SD_SHARE_PKG_RESOURCES;
}
#endif
#ifdef CONFIG_SCHED_MC
-static inline const int cpu_core_flags(void)
+static inline int cpu_core_flags(void)
{
return SD_SHARE_PKG_RESOURCES;
}
#endif
#ifdef CONFIG_NUMA
-static inline const int cpu_numa_flags(void)
+static inline int cpu_numa_flags(void)
{
return SD_NUMA;
}
The same is true of those three, but then they would have to be moved
into a .c file and replaced with prototypes ...
Personally I wasn't sure why it had to be functions instead of defines,
but who knows. Anyway, seems others are not happy with my proposed fix
either, and everyone seems to suggest a different solution, so I guess
it won't go anywhere.
I "solved" my immediate problem of getting a polluted build log by
filtering the warnings out, so I don't really care too much anymore ;-).
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420
On Thu, Jun 26, 2014 at 4:51 AM, Kevin Hilman wrote: > Doug Anderson writes: > >> Tushar, >> >> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera wrote: >>> Currently CLK_FOUT_EPLL was set as one of the parents of AUDSS mux. >>> As per the user manual, it should be CLK_MAU_EPLL. >>> >>> The problem surfaced when the bootloader in Peach-pit board set >>> the EPLL clock as the parent of AUDSS mux. While booting the kernel, >>> we used to get a system hang during late boot if CLK_MAU_EPLL was >>> disabled. >>> >>> Signed-off-by: Tushar Behera >>> Signed-off-by: Shaik Ameer Basha >>> Reported-by: Kevin Hilman >>> --- >>> arch/arm/boot/dts/exynos5420.dtsi |2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> I've tested this myself now as well. >> >> Tested-by: Doug Anderson > > For me, this patch alone (on top of -next) doesn't solve the boot hang. > I still need clk_ignore_unused for a successful boot. > > So, this patch might be correct, but it doesn't prevent a boot hang > using a chain-loaded nv_uboot on peach-pi. There's still another clock > being disabled that causes a hang. > > Kevin Kevin, Can you please check if adding patch 1/3 alongwith patch 2/3 fixes the issue for you? Also can you please confirm that setting CLK_IGNORE_UNUSED flag CLK_MAU_EPLL alone fixes the issue, without any need for clk_ignore_unused in u-boot bootargs? -- Tushar Behera -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Stricter module param and sysfs permission checks
Gobinda Charan Maji gmail.com> writes: > > Hi All, > > As per the newly added restriction (User perms >= group perms >= other > perms) is concerned, there is an inconsistency in the permission. Say for > example, permission value is "0432". Here User has only READ permission > whereas Group has both WRITE and EXECUTE permission and Other has WRITE > permission. I think it is not good to give Group and Other at least WRITE > permission whereas User itself has no WRITE permission. > > May be, it's better to check those three permissions bit wise rather than as > a whole. Please rethink about my point and let me know your opinion. > > Thanks, > Gobinda > > Hi All, I could not get any response yet. Hi Rusty, Please at least give me a reply even if my concept seems to be incorrect to you. Thanks in advance, Gobinda -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/6] clk: sunxi: fixes, cleanups and A23 basic clocks
On Thu, Jun 26, 2014 at 4:14 AM, Maxime Ripard wrote: > On Tue, Jun 24, 2014 at 05:59:34PM +0800, Chen-Yu Tsai wrote: >> Hi everyone, >> >> This is a followup series to my A23 bare-minimum bringup series [1], >> which adds basic clock support for the A23 SoC. It is one of many >> split up from the original A23 series [2]. Yet to come are more >> clocks, reset controllers, pinctrl, prcm, and mmc. >> >> The first patch fixes the reworked clock protection code merged in >> 3.16-rc1, which unintentionally made clock gates unprotectable. >> >> The second patch moves the remaining "ahb_sdram" clock to the >> protected clock list, now that it works. >> >> The third patch adds support for factor clocks that have an N factor >> not starting from 0. This is found on some PLLs in A31/A23. >> >> The fourth patch adds table-based dividers for div clocks, as some >> clocks, such as apb0 divider on sun4/5/7i, apb1 on sun6/8i and axi >> on sun8i. >> >> The fifth patch adds support for the basic clocks in the A23, just >> PLL1 for cpus, and the system bus clocks and gates. >> >> The last patch adds the DT nodes for the newly added clocks. >> >> Patch 1 should be merged for 3.16, while the rest should go in 3.17. > > Why should it go in for 3.16? Is there any user for it yet? Yes. Your patch efb3184 clk: sun6i: Protect SDRAM gating bit from the series that added the new clock protection code. This adds "ahb1_sdram" to the list. Now, on my sun8i tablet, disabling "ahb1_sdram" doesn't seem to affect the system. So I'm not sure what this clock actually does. ChenYu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB_MUSB_DA8XX with g_multi.ko
On Wed, Jun 25, 2014 at 11:52 AM, Jon Ringle wrote: > On Wed, Jun 25, 2014 at 11:35 AM, Andrzej Pietrasiewicz > wrote: >> W dniu 25.06.2014 17:13, Jon Ringle pisze: >> >>> In commit 787f5627bec80094db487bfcb401e9744f181aed >>> usb: musb: make davinci and da8xx glues depend on BROKEN >>> >>> USB_MUSB_DA8XX was marked as BROKEN >>> >>> A few months ago, we updated the linux kernel on our AM1808 SoC based >>> embedded board from Linux 2.6.33 to the latest long term 3.12. >>> >>> I am interested in having the USB gadget support on my board, so I >>> removed BROKEN on USB_MUSB_DA8XX. I found that when I modprobe >>> g_ether, g_serial, and g_mass_storage (by themselves), they all appear >>> to work as expected, but if I try to use g_multi to have a composite >>> device supporting all three simultaneously, I run into failure during >>> initialization. >>> >> >> >> >> >>> From this I can see that it's failing on the following call in fsg_bind(): >>> >>> ep = usb_ep_autoconfig(gadget, _fs_bulk_in_desc); >>> >> >> Just a random guess (I don't know your hardware): how many bulk, >> iso and interrupt endpoints does your hardware provide? Perhaps you >> just run out of endpoints? > > Perhaps... From the documentation it appears that I can have 4 > simultaneous RX/TX endpoints... Is this not enough? I now see that each function seems to require 2 endpoints, so with 4 endpoints available, I can only have two functions with this hardware. I tested this successfully with g_adm_ms.ko having both serial and mass storage working. The only thing I needed to do was to remove the BROKEN dependency on USB_MUSB_DA8XX. Is there anything else I would have to do besides just removing BROKEN to get this accepted back into the kernel source tree? Jon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] scripts/checkpatch.pl: Only emit LONG_LINE for --strict
On Wed, 2014-06-25 at 19:24 -0700, Josh Triplett wrote: > On Wed, Jun 25, 2014 at 05:05:07PM -0700, Joe Perches wrote: > > On Wed, 2014-06-25 at 08:46 -0700, Josh Triplett wrote: > > > Regardless of the long-standing debate over line width, checkpatch > > > should not warn about it by default. > > > > I'm not getting involved here. > > I don't care much one way or another. [] > I'm not asking you to get involved in the Great Line Length Debate; > that's why I didn't attempt to patch CodingStyle or similar. However, I > think it makes sense for *checkpatch* to stop emitting this warning. I think checkpatch should encourage people to write code in a style that matches CodingStyle as well as the predominant styles used in the rest of the kernel. > I'm hoping that Greg will chime in, as the maintainer of staging and the > recipient of a huge number of checkpatch-motivated patches. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ARM: firmware: Introduce suspend and resume operations
On 06/26/2014 01:18 AM, Tomasz Figa wrote: This patch extends the firmware_ops structure with two new callbacks: .suspend() and .resume(). The former is intended to ask the firmware to save all its volatile state and suspend the system, without returning back to the kernel in between. The latter is to be called early by very low level platform suspend code after waking up to restore low level hardware state, which can't be restored in non-secure mode. While at it, outdated version of the structure is removed from the documentation and replaced with a reference to the header file. Acked-by: Alexandre Courbot -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] autofs4 - fix false positive compile error
On Wed, 2014-06-25 at 13:06 -0700, Andrew Morton wrote: > On Wed, 25 Jun 2014 20:49:39 +0800 Ian Kent wrote: > > > On strict build environments we can see: > > > > fs/autofs4/inode.c: In function 'autofs4_fill_super': > > fs/autofs4/inode.c:312: error: 'pgrp' may be used uninitialized in this > > function > > make[2]: *** [fs/autofs4/inode.o] Error 1 > > make[1]: *** [fs/autofs4] Error 2 > > make: *** [fs] Error 2 > > make: *** Waiting for unfinished jobs > > > > This is due to the use of pgrp_set being used to indicate pgrp has > > has been set rather than initializing pgrp itself. > > > > Yes, that code seems to be explicitly designed to trigger a gcc warning ;) > > What is a "strict build environment"? Someone's using -Werror for the > entire kernel? That must make for a miserable life. Yes, TBH I was a bit surprised myself. It resulted from a RHEL-6.6 patch submission. I didn't notice it and ended up missing an internal (RedHat) patch submission deadline as my original interest in these was the result of an upstream discussion and I stupidly relied on my upstream testing. It might just be that our internal up and coming file system tree is specifically more fussy but never the less I got caught out. Ian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] scripts/checkpatch.pl: Only emit LONG_LINE for --strict
On Wed, Jun 25, 2014 at 05:05:07PM -0700, Joe Perches wrote: > On Wed, 2014-06-25 at 08:46 -0700, Josh Triplett wrote: > > Regardless of the long-standing debate over line width, checkpatch > > should not warn about it by default. > > I'm not getting involved here. > > I don't care much one way or another. > > I did submit a patch where I ignored 80 > columns recently and I was told to try > again by the maintainer. I'm not asking you to get involved in the Great Line Length Debate; that's why I didn't attempt to patch CodingStyle or similar. However, I think it makes sense for *checkpatch* to stop emitting this warning. I'm hoping that Greg will chime in, as the maintainer of staging and the recipient of a huge number of checkpatch-motivated patches. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] /proc/stat vs. failed order-4 allocation
On Wed, 2014-06-25 at 08:15 +0200, Heiko Carstens wrote: > On Tue, Jun 24, 2014 at 04:52:22PM -0700, David Rientjes wrote: > > On Mon, 23 Jun 2014, Andrew Morton wrote: > > > On Sat, 21 Jun 2014 11:10:58 +0200 Heiko Carstens > > > wrote: > > > > On Wed, Jun 18, 2014 at 02:29:31PM -0700, Andrew Morton wrote: > > > > > I'm unclear on how urgent these fixes are. I semi-randomly tagged > > > > > them > > > > > for 3.16 with a -stable backport, but that could be changed? > > > > > > > > I assume tagged for 3.16 means you intend to get it merged before 3.16 > > > > gets released? > > > > If so, then that would be fine with me. > > > > > > um, actually, no, sorry, I meant merge for 3.17-rc1 with a -stable > > > backport. > > > > > > We can do 3.16 of course, but for what reasons? > > > > Heiko's patches should also fix > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1319244 as reported > > by Stefan Bader. I've pinged them to determine if there is any other > > issues with -mm. > > The other distribution where this has been seen was RHEL7 (on s390). > > FWIW, I thought there was a 'rule' that patches with a -stable tag shouldn't > stay in -next for a couple of rc releases. But then again that probably was > just a discussion somewhere. > Anyway, if neither Stefan or Ian speak up I'm fine with post 3.16 as well. > It's very much up to Andrew, of course. I would like to see this go in sooner rather than later, if possible, due to the potential RHEL-7 disruption it can cause. More so now the above shows we can see this on other architectures and higher speced machines. Looking at the patches it appears there's no change from the original semantics. So the potential for regression is fairly low now since Heiko's patches are much simpler than the original proposal and are much more straight forward to review, so much so that they make sense even to me! Ian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rcu] e552592e038: +39.2% vm-scalability.throughput, +19.7% turbostat.Pkg_W
On Thu, Jun 26, 2014 at 09:42:19AM +0800, Fengguang Wu wrote:
> Hi Paul,
>
> We noticed the below changes on
>
> git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
> urgent.2014.06.21a
> commit e552592e0383bc72e35eb21a9fabd84ad873cff1 ("rcu: Reduce overhead of
> cond_resched() checks for RCU")
This one is also obsolete, but the good news is that the replacement
commit 4a81e8328d37 (Reduce overhead of cond_resched() checks for RCU)
is quite similar, so here is hoping for similar results from it.
Thanx, Paul
> Test case: brickland3/vm-scalability/300s-anon-w-seq-mt-64G
>
> v3.16-rc1 e552592e0383bc72e35eb21a9
> --- -
> 89766370 ~ 6% +39.2% 1.25e+08 ~ 9% TOTAL vm-scalability.throughput
> 1.317e+09 ~ 8% -45.2% 7.21e+08 ~10% TOTAL cpuidle.C6-IVT-4S.time
> 9 ~ 6% +58.8% 15 ~ 5% TOTAL vmstat.procs.r
> 12.27 ~14% +44.7% 17.74 ~12% TOTAL turbostat.%c1
> 20538 ~ 4% -21.3% 16155 ~ 4% TOTAL cpuidle.C6-IVT-4S.usage
> 77.66 ~ 2% -15.0% 65.98 ~ 5% TOTAL turbostat.%c6
>260 ~ 2% -16.4%217 ~ 4% TOTAL vmstat.memory.buff
> 51920 ~ 7% -14.3% 44489 ~ 5% TOTAL
> numa-meminfo.node0.PageTables
> 53822 ~ 5% -15.6% 45404 ~ 6% TOTAL
> proc-vmstat.nr_page_table_pages
> 215196 ~ 5% -15.7% 181409 ~ 6% TOTAL meminfo.PageTables
> 52182 ~ 4% -15.2% 44271 ~ 6% TOTAL
> proc-vmstat.nr_anon_transparent_hugepages
> 12881 ~ 7% -13.4% 11150 ~ 5% TOTAL
> numa-vmstat.node0.nr_page_table_pages
> 1.068e+08 ~ 4% -15.2% 90492587 ~ 6% TOTAL meminfo.AnonHugePages
> 26983682 ~ 4% -14.5% 23071571 ~ 6% TOTAL proc-vmstat.nr_anon_pages
> 1.079e+08 ~ 4% -14.5% 92289854 ~ 6% TOTAL meminfo.AnonPages
> 1.083e+08 ~ 4% -14.2% 92897630 ~ 6% TOTAL meminfo.Active(anon)
> 1.084e+08 ~ 4% -14.2% 92970821 ~ 6% TOTAL meminfo.Active
> 27067517 ~ 4% -14.2% 23232055 ~ 6% TOTAL proc-vmstat.nr_active_anon
> 52565 ~ 3% -12.0% 46273 ~ 3% TOTAL proc-vmstat.nr_shmem
> 52499 ~ 3% -12.0% 46215 ~ 3% TOTAL proc-vmstat.nr_inactive_anon
> 214447 ~ 3% -10.5% 191862 ~ 2% TOTAL meminfo.Shmem
> 214197 ~ 3% -10.5% 191636 ~ 2% TOTAL meminfo.Inactive(anon)
> 2779 ~13% -53.5% 1291 ~19% TOTAL
> time.involuntary_context_switches
> 1156 ~ 8% +82.3% 2108 ~ 9% TOTAL
> time.percent_of_cpu_this_job_got
> 11.58 ~10% -44.4% 6.45 ~ 9% TOTAL time.elapsed_time
> 1008 ~ 5% +79.5% 1810 ~ 7% TOTAL
> time.voluntary_context_switches
> 9.23 ~ 8% +72.8% 15.95 ~ 8% TOTAL turbostat.%c0
> 12679 ~ 8% +70.8% 21659 ~ 9% TOTAL vmstat.system.in
>145 ~ 7% +60.6%234 ~ 8% TOTAL vmstat.io.bo
> 3721 ~ 7% +35.2% 5029 ~ 8% TOTAL vmstat.system.cs
>~ 1% +26.7%~ 5% TOTAL turbostat.Cor_W
>~ 2% +21.2%~ 3% TOTAL turbostat.RAM_W
>~ 1% +19.7%~ 4% TOTAL turbostat.Pkg_W
>
>
> All test cases:
>
> v3.16-rc1 e552592e0383bc72e35eb21a9
> --- -
> 89766370 ~ 6% +39.2% 1.25e+08 ~ 9%
> brickland3/vm-scalability/300s-anon-w-seq-mt-64G
> 89766370 ~ 6% +39.2% 1.25e+08 ~ 9% TOTAL vm-scalability.throughput
>
> v3.16-rc1 e552592e0383bc72e35eb21a9
> --- -
> 0.36 ~ 1% -9.8% 0.32 ~ 2% lkp-nex05/will-it-scale/open1
> 0.36 ~ 1% -9.8% 0.32 ~ 2% TOTAL will-it-scale.scalability
>
> v3.16-rc1 e552592e0383bc72e35eb21a9
> --- -
> 466616 ~ 1% -2.6% 454267 ~ 1% lkp-nex05/will-it-scale/open1
> 511556 ~ 0% -1.3% 504762 ~ 0% lkp-snb01/will-it-scale/signal1
> 978172 ~ 0% -2.0% 959029 ~ 0% TOTAL
> will-it-scale.per_process_ops
>
> v3.16-rc1 e552592e0383bc72e35eb21a9
> --- -
>1381706 ~ 1% +2.3%1413190 ~ 0% lkp-snb01/will-it-scale/futex2
> 299558 ~ 0% -1.8% 294312 ~ 0% lkp-snb01/will-it-scale/signal1
>1681264 ~ 1% +1.6%1707503 ~ 0% TOTAL will-it-scale.per_thread_ops
>
> v3.16-rc1 e552592e0383bc72e35eb21a9
> --- -
> 84771 ~ 2%+575.2% 572390 ~ 1% lkp-nex05/will-it-scale/open1
> 84771 ~ 2%+575.2% 572390 ~ 1% TOTAL
> slabinfo.kmalloc-256.active_objs
>
> v3.16-rc1 e552592e0383bc72e35eb21a9
> --- -
> 2656 ~ 2%+573.8% 17896 ~ 1% lkp-nex05/will-it-scale/open1
> 2656 ~ 2%+573.8% 17896 ~ 1% TOTAL
> slabinfo.kmalloc-256.num_slabs
>
> v3.16-rc1
Re: [rcu] 0acd7c39a85: +11.0% will-it-scale.scalability
On Thu, Jun 26, 2014 at 09:56:16AM +0800, Fengguang Wu wrote:
> Hi Paul,
>
> FYI, we are pleased to notice big performance gains in some
> will-it-scale test cases:
Unfortunately, this one is also obsoleted by commit 4a81e8328d37 (Reduce
overhead of cond_resched() checks for RCU). Hopefully that commit also
shows similar performance gains. ;-)
Thanx, Paul
> git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
> rcu_cond_resched.2014.06.20c
> commit 0acd7c39a85836d90451b6c278c5cfdd21c055f3 ("rcu: Add
> RCU_COND_RESCHED_QS for large systems")
>
> acf426994c75e38 0acd7c39a85836d90451b6c27
> --- -
> 0.30 ~ 2% +14.3% 0.34 ~ 3% lkp-sbx04/will-it-scale/open1
> 0.34 ~ 3% +8.1% 0.37 ~ 1% nhm4/will-it-scale/read1
> 0.64 ~ 3% +11.0% 0.71 ~ 2% TOTAL will-it-scale.scalability
>
> acf426994c75e38 0acd7c39a85836d90451b6c27
> --- -
> 592828 ~ 1% +3.8% 615531 ~ 1% lkp-sbx04/will-it-scale/open1
> 592828 ~ 1% +3.8% 615531 ~ 1% TOTAL
> will-it-scale.per_process_ops
>
> acf426994c75e38 0acd7c39a85836d90451b6c27
> --- -
> 1689 ~ 0%+498.1% 10107 ~ 2% lkp-sbx04/will-it-scale/unlink2
> 1689 ~ 0%+498.1% 10107 ~ 2% TOTAL slabinfo.dentry.active_slabs
>
> acf426994c75e38 0acd7c39a85836d90451b6c27
> --- -
> 72052 ~ 0%+489.8% 424930 ~ 2% lkp-sbx04/will-it-scale/unlink2
> 72052 ~ 0%+489.8% 424930 ~ 2% TOTAL slabinfo.Acpi-State.num_objs
>
> acf426994c75e38 0acd7c39a85836d90451b6c27
> --- -
> 71629 ~ 0%+492.6% 424494 ~ 2% lkp-sbx04/will-it-scale/unlink2
> 71629 ~ 0%+492.6% 424494 ~ 2% TOTAL
> slabinfo.Acpi-State.active_objs
>
> acf426994c75e38 0acd7c39a85836d90451b6c27
> --- -
> 1689 ~ 0%+498.1% 10107 ~ 2% lkp-sbx04/will-it-scale/unlink2
> 1689 ~ 0%+498.1% 10107 ~ 2% TOTAL slabinfo.dentry.num_slabs
>
> acf426994c75e38 0acd7c39a85836d90451b6c27
> --- -
> 1412 ~ 0%+490.0% 8331 ~ 2% lkp-sbx04/will-it-scale/unlink2
> 1412 ~ 0%+490.0% 8331 ~ 2% TOTAL
> slabinfo.Acpi-State.active_slabs
>
> acf426994c75e38 0acd7c39a85836d90451b6c27
> --- -
> 70980 ~ 0%+498.1% 424517 ~ 2% lkp-sbx04/will-it-scale/unlink2
> 70980 ~ 0%+498.1% 424517 ~ 2% TOTAL slabinfo.dentry.num_objs
>
> acf426994c75e38 0acd7c39a85836d90451b6c27
> --- -
> 70444 ~ 0%+502.0% 424054 ~ 2% lkp-sbx04/will-it-scale/unlink2
> 70444 ~ 0%+502.0% 424054 ~ 2% TOTAL slabinfo.dentry.active_objs
>
> acf426994c75e38 0acd7c39a85836d90451b6c27
> --- -
>472 ~ 0% +1557.0% 7827 ~ 2% lkp-sbx04/will-it-scale/unlink2
>472 ~ 0% +1557.0% 7827 ~ 2% TOTAL
> slabinfo.shmem_inode_cache.num_slabs
>
> acf426994c75e38 0acd7c39a85836d90451b6c27
> --- -
>472 ~ 0% +1557.0% 7827 ~ 2% lkp-sbx04/will-it-scale/unlink2
>472 ~ 0% +1557.0% 7827 ~ 2% TOTAL
> slabinfo.shmem_inode_cache.active_slabs
>
> acf426994c75e38 0acd7c39a85836d90451b6c27
> --- -
> 22697 ~ 0% +1555.5% 375756 ~ 2% lkp-sbx04/will-it-scale/unlink2
> 22697 ~ 0% +1555.5% 375756 ~ 2% TOTAL
> slabinfo.shmem_inode_cache.num_objs
>
> acf426994c75e38 0acd7c39a85836d90451b6c27
> --- -
> 22297 ~ 0% +1584.0% 375494 ~ 2% lkp-sbx04/will-it-scale/unlink2
> 22297 ~ 0% +1584.0% 375494 ~ 2% TOTAL
> slabinfo.shmem_inode_cache.active_objs
>
> acf426994c75e38 0acd7c39a85836d90451b6c27
> --- -
> 1412 ~ 0%+490.0% 8331 ~ 2% lkp-sbx04/will-it-scale/unlink2
> 1412 ~ 0%+490.0% 8331 ~ 2% TOTAL
> slabinfo.Acpi-State.num_slabs
>
> acf426994c75e38 0acd7c39a85836d90451b6c27
> --- -
> 230182 ~ 2%+214.7% 724407 ~ 1% lkp-sbx04/will-it-scale/open1
> 29926 ~ 1% +1179.6% 382938 ~ 2% lkp-sbx04/will-it-scale/unlink2
> 260108 ~ 2%+325.7%1107345 ~ 1% TOTAL
> slabinfo.kmalloc-256.active_objs
>
> acf426994c75e38 0acd7c39a85836d90451b6c27
> --- -
> 3605 ~ 2%+214.1% 11325 ~ 1% lkp-sbx04/will-it-scale/open1
>478 ~ 1% +1153.4% 5991 ~ 2% lkp-sbx04/will-it-scale/unlink2
> 4083 ~ 2%+324.1% 17316 ~ 1% TOTAL
>
rtl_nic firmware error in 3.16
Hi, I'm getting 15 lines of the following in -rc2 /bin/sh: firmware/rtl_nic/rtl8168e-3.fw.gen.S: No such file or directory followed by firmware/Makefile:185: recipe for target 'firmware/rtl_nic/rtl8168e-3.fw.gen.S' failed make[1]: *** [firmware/rtl_nic/rtl8168e-3.fw.gen.S] Error 1 I've now tried bisecting this twice, from v3.15 to v3.16-rc2 but each time the only bad version was v3.16-rc2 itself which is clearly not true. The relevant part of my .config is probably in here: # # Generic Driver Options # CONFIG_UEVENT_HELPER=y CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y # CONFIG_STANDALONE is not set CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y # CONFIG_FIRMWARE_IN_KERNEL is not set CONFIG_EXTRA_FIRMWARE="radeon/R600_rlc.bin radeon/RS780_pfp.bin radeon/RS780_me.bin rtl_nic/rtl8168e-3.fw" CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware" CONFIG_FW_LOADER_USER_HELPER=y # CONFIG_DEBUG_DRIVER is not set # CONFIG_DEBUG_DEVRES is not set # CONFIG_SYS_HYPERVISOR is not set # CONFIG_GENERIC_CPU_DEVICES is not set CONFIG_GENERIC_CPU_AUTOPROBE=y CONFIG_DMA_SHARED_BUFFER=y and the external firmware is in /lib/firmware : ken@ac4tv ~ $ls -l /lib/firmware/rtl_nic/ total 4 -rw-r--r-- 1 root root 2804 Feb 18 18:03 rtl8168e-3.fw So I assume something is erroneously trying to recreate it. For the second run, I tried using 'make clean' on each build, and then after a while I changed to 'make mrproper'. Perhaps I should have used 'mrproper' from the start (never needed it before, and it does normally slow things down when you approach the guilty commit). I have now pulled the -rc1 tarball and confirmed that the problem is present there, but this is doing my head in, so I thought I would ask if anyone else is hitting this ? ĸen -- Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rcu] 34577530114: +247.4% qperf.tcp.bw, -3.3% turbostat.Pkg_W
On Thu, Jun 26, 2014 at 10:00:11AM +0800, Fengguang Wu wrote:
> Hi Paul,
>
> We are pleased to notice huge throughput increases in the qperf/iperf
> tests, together with noticeable reduce of power consumption!
This one was identified by your testing efforts, so thank you for giving
me the hints needed to make this change! Looks like some negatives to
go with the positives, though eyeballing it looks mostly positive.
Just out of curiosity, what hardware configuration is this running on?
I am guessing a largish number of CPUs.
Thanx, Paul
> git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/dev
> commit 34577530114e9b1de10f3aa9665bb28c8ce585ba ("rcu: Bind grace-period
> kthreads to non-NO_HZ_FULL CPUs")
>
> 221031cb1b33258 34577530114e9b1de10f3aa96
> --- -
> 8.23e+08 ~ 6%+247.4% 2.859e+09 ~ 0% bens/qperf/600s
> 8.23e+08 ~ 6%+247.4% 2.859e+09 ~ 0% TOTAL qperf.tcp.bw
>
> 221031cb1b33258 34577530114e9b1de10f3aa96
> --- -
> 7.065e+09 ~ 3%+210.0% 2.19e+10 ~ 8% bens/iperf/300s-tcp
> 7.065e+09 ~ 3%+210.0% 2.19e+10 ~ 8% TOTAL iperf.tcp.sender.bps
>
> 221031cb1b33258 34577530114e9b1de10f3aa96
> --- -
> 7.065e+09 ~ 3%+210.0% 2.19e+10 ~ 8% bens/iperf/300s-tcp
> 7.065e+09 ~ 3%+210.0% 2.19e+10 ~ 8% TOTAL iperf.tcp.receiver.bps
>
> 221031cb1b33258 34577530114e9b1de10f3aa96
> --- -
> 7.718e+08 ~ 3%+177.8% 2.144e+09 ~ 1% bens/qperf/600s
> 7.718e+08 ~ 3%+177.8% 2.144e+09 ~ 1% TOTAL qperf.udp.recv_bw
>
> 221031cb1b33258 34577530114e9b1de10f3aa96
> --- -
> 7.745e+08 ~ 3%+177.0% 2.145e+09 ~ 1% bens/qperf/600s
> 7.745e+08 ~ 3%+177.0% 2.145e+09 ~ 1% TOTAL qperf.udp.send_bw
>
> 221031cb1b33258 34577530114e9b1de10f3aa96
> --- -
> 1.65e+09 ~ 1% +4.3% 1.721e+09 ~ 0% bens/qperf/600s
> 1.65e+09 ~ 1% +4.3% 1.721e+09 ~ 0% TOTAL qperf.sctp.bw
>
> 221031cb1b33258 34577530114e9b1de10f3aa96
> --- -
> 13579 ~ 1% -2.3% 13264 ~ 1% bens/qperf/600s
> 13579 ~ 1% -2.3% 13264 ~ 1% TOTAL qperf.sctp.latency
>
> 221031cb1b33258 34577530114e9b1de10f3aa96
> --- -
> 8545 ~ 0% +1.9% 8705 ~ 0% bens/qperf/600s
> 8545 ~ 0% +1.9% 8705 ~ 0% TOTAL qperf.udp.latency
>
> 221031cb1b33258 34577530114e9b1de10f3aa96
> --- -
> 12770 ~ 0% -1.0% 12637 ~ 0% ivb43/netperf/300s-25%-TCP_CRR
> 12770 ~ 0% -1.0% 12637 ~ 0% TOTAL netperf.Throughput_tps
>
> 221031cb1b33258 34577530114e9b1de10f3aa96
> --- -
> 1015 ~ 2% -92.1% 80 ~24% ivb43/netperf/300s-25%-TCP_CRR
> 1015 ~ 2% -92.1% 80 ~24% TOTAL cpuidle.POLL.usage
>
> 221031cb1b33258 34577530114e9b1de10f3aa96
> --- -
> 104620 ~31% -83.2% 17544 ~11% ivb43/netperf/300s-25%-TCP_CRR
> 104620 ~31% -83.2% 17544 ~11% TOTAL numa-vmstat.node1.numa_other
>
> 221031cb1b33258 34577530114e9b1de10f3aa96
> --- -
> 0.12 ~ 7% -73.3% 0.03 ~12% ivb43/netperf/300s-25%-TCP_CRR
> 0.12 ~ 7% -73.3% 0.03 ~12% TOTAL turbostat.%c3
>
> 221031cb1b33258 34577530114e9b1de10f3aa96
> --- -
> 53226067 ~ 3% -78.2% 11579930 ~14% ivb43/netperf/300s-25%-TCP_CRR
>3327687 ~28% +86.6%6208767 ~42% ivb44/pigz/25%-128K
> 56553754 ~ 4% -68.5% 17788697 ~24% TOTAL cpuidle.C1E-IVT.time
>
> 221031cb1b33258 34577530114e9b1de10f3aa96
> --- -
> 878601 ~ 3% -75.2% 217607 ~12% ivb43/netperf/300s-25%-TCP_CRR
> 9282 ~27% +99.2% 18495 ~49% ivb44/pigz/25%-128K
> 887884 ~ 4% -73.4% 236102 ~15% TOTAL cpuidle.C1E-IVT.usage
>
> 221031cb1b33258 34577530114e9b1de10f3aa96
> --- -
> 28174239 ~ 6% -61.0% 10981001 ~ 8% ivb43/netperf/300s-25%-TCP_CRR
> 28174239 ~ 6% -61.0% 10981001 ~ 8% TOTAL cpuidle.C3-IVT.time
>
> 221031cb1b33258 34577530114e9b1de10f3aa96
> --- -
>237 ~20%+141.1%572 ~ 9% xbm/pigz/25%-512K
>237 ~20%+141.1%572 ~ 9% TOTAL cpuidle.C3-SNB.usage
>
> 221031cb1b33258 34577530114e9b1de10f3aa96
> --- -
>8192746 ~ 3%+202.8% 24806641 ~ 7% bens/iperf/300s-tcp
> 15458478 ~ 1% +69.2% 26148854 ~ 0% bens/qperf/600s
> 23651225 ~ 2%+115.4% 50955496 ~
Re: [PATCH] net: fix setting csum_start in skb_segment()
On Wed, Jun 25, 2014 at 12:51 PM, Eric Dumazet wrote:
> From: Tom Herbert
>
> Dave Jones reported that a crash is occurring in
>
> csum_partial
> tcp_gso_segment
> inet_gso_segment
> ? update_dl_migration
> skb_mac_gso_segment
> __skb_gso_segment
> dev_hard_start_xmit
> sch_direct_xmit
> __dev_queue_xmit
> ? dev_hard_start_xmit
> dev_queue_xmit
> ip_finish_output
> ? ip_output
> ip_output
> ip_forward_finish
> ip_forward
> ip_rcv_finish
> ip_rcv
> __netif_receive_skb_core
> ? __netif_receive_skb_core
> ? trace_hardirqs_on
> __netif_receive_skb
> netif_receive_skb_internal
> napi_gro_complete
> ? napi_gro_complete
> dev_gro_receive
> ? dev_gro_receive
> napi_gro_receive
>
> It looks like a likely culprit is that SKB_GSO_CB()->csum_start is
> not set correctly when doing non-scatter gather. We are using
> offset as opposed to doffset.
>
Acked-by: Tom Herbert
> Reported-by: Dave Jones
> Tested-by: Dave Jones
> Signed-off-by: Tom Herbert
> Signed-off-by: Eric Dumazet
> Fixes: 7e2b10c1e52ca ("net: Support for multiple checksums with gso")
> ---
> net/core/skbuff.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 9cd5344fad73..c1a33033cbe2 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -2993,7 +2993,7 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb,
> skb_put(nskb,
> len),
> len, 0);
> SKB_GSO_CB(nskb)->csum_start =
> - skb_headroom(nskb) + offset;
> + skb_headroom(nskb) + doffset;
> continue;
> }
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs/mbcache.c: replacing __builtin_log2() with ilog2()
On Wed, Jun 25, 2014 at 12:24:49AM +0100, Maciej W. Rozycki wrote: > On Fri, 30 May 2014, T Makphaibulchoke wrote: > > > Fixing compiler error with some gcc version(s) that do not > > support __builtin_log2(). Replacing __builtin_log2() with > > ilog2(). > > > > Signed-off-by: T. Makphaibulchoke > > Reviewed-by: Maciej W. Rozycki Thanks, applied. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] block: virtio-blk: support multi virt queues per virtio-blk device
Firstly this patch supports more than one virtual queues for virtio-blk
device.
Secondly this patch maps the virtual queue to blk-mq's hardware queue.
With this approach, both scalability and performance can be improved.
Signed-off-by: Ming Lei
---
drivers/block/virtio_blk.c | 109
1 file changed, 89 insertions(+), 20 deletions(-)
diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index f63d358..b0a49a0 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -21,11 +21,14 @@ static DEFINE_IDA(vd_index_ida);
static struct workqueue_struct *virtblk_wq;
+struct virtio_blk_vq {
+ struct virtqueue *vq;
+ spinlock_t lock;
+} cacheline_aligned_in_smp;
+
struct virtio_blk
{
struct virtio_device *vdev;
- struct virtqueue *vq;
- spinlock_t vq_lock;
/* The disk structure for the kernel. */
struct gendisk *disk;
@@ -47,6 +50,10 @@ struct virtio_blk
/* Ida index - used to track minor number allocations. */
int index;
+
+ /* num of vqs */
+ int num_vqs;
+ struct virtio_blk_vq *vqs;
};
struct virtblk_req
@@ -133,14 +140,15 @@ static void virtblk_done(struct virtqueue *vq)
{
struct virtio_blk *vblk = vq->vdev->priv;
bool req_done = false;
+ int qid = vq->index;
struct virtblk_req *vbr;
unsigned long flags;
unsigned int len;
- spin_lock_irqsave(>vq_lock, flags);
+ spin_lock_irqsave(>vqs[qid].lock, flags);
do {
virtqueue_disable_cb(vq);
- while ((vbr = virtqueue_get_buf(vblk->vq, )) != NULL) {
+ while ((vbr = virtqueue_get_buf(vblk->vqs[qid].vq, )) !=
NULL) {
blk_mq_complete_request(vbr->req);
req_done = true;
}
@@ -151,7 +159,7 @@ static void virtblk_done(struct virtqueue *vq)
/* In case queue is stopped waiting for more buffers. */
if (req_done)
blk_mq_start_stopped_hw_queues(vblk->disk->queue, true);
- spin_unlock_irqrestore(>vq_lock, flags);
+ spin_unlock_irqrestore(>vqs[qid].lock, flags);
}
static int virtio_queue_rq(struct blk_mq_hw_ctx *hctx, struct request *req)
@@ -160,6 +168,7 @@ static int virtio_queue_rq(struct blk_mq_hw_ctx *hctx,
struct request *req)
struct virtblk_req *vbr = blk_mq_rq_to_pdu(req);
unsigned long flags;
unsigned int num;
+ int qid = hctx->queue_num;
const bool last = (req->cmd_flags & REQ_END) != 0;
int err;
bool notify = false;
@@ -202,12 +211,12 @@ static int virtio_queue_rq(struct blk_mq_hw_ctx *hctx,
struct request *req)
vbr->out_hdr.type |= VIRTIO_BLK_T_IN;
}
- spin_lock_irqsave(>vq_lock, flags);
- err = __virtblk_add_req(vblk->vq, vbr, vbr->sg, num);
+ spin_lock_irqsave(>vqs[qid].lock, flags);
+ err = __virtblk_add_req(vblk->vqs[qid].vq, vbr, vbr->sg, num);
if (err) {
- virtqueue_kick(vblk->vq);
+ virtqueue_kick(vblk->vqs[qid].vq);
blk_mq_stop_hw_queue(hctx);
- spin_unlock_irqrestore(>vq_lock, flags);
+ spin_unlock_irqrestore(>vqs[qid].lock, flags);
/* Out of mem doesn't actually happen, since we fall back
* to direct descriptors */
if (err == -ENOMEM || err == -ENOSPC)
@@ -215,12 +224,12 @@ static int virtio_queue_rq(struct blk_mq_hw_ctx *hctx,
struct request *req)
return BLK_MQ_RQ_QUEUE_ERROR;
}
- if (last && virtqueue_kick_prepare(vblk->vq))
+ if (last && virtqueue_kick_prepare(vblk->vqs[qid].vq))
notify = true;
- spin_unlock_irqrestore(>vq_lock, flags);
+ spin_unlock_irqrestore(>vqs[qid].lock, flags);
if (notify)
- virtqueue_notify(vblk->vq);
+ virtqueue_notify(vblk->vqs[qid].vq);
return BLK_MQ_RQ_QUEUE_OK;
}
@@ -377,12 +386,71 @@ static void virtblk_config_changed(struct virtio_device
*vdev)
static int init_vq(struct virtio_blk *vblk)
{
int err = 0;
+ int i;
+ vq_callback_t **callbacks;
+ const char **names;
+ char *name_array;
+ struct virtqueue **vqs;
+ unsigned short num_vqs;
+ struct virtio_device *vdev = vblk->vdev;
- /* We expect one virtqueue, for output. */
- vblk->vq = virtio_find_single_vq(vblk->vdev, virtblk_done, "requests");
- if (IS_ERR(vblk->vq))
- err = PTR_ERR(vblk->vq);
+ err = virtio_cread_feature(vdev, VIRTIO_BLK_F_MQ,
+ struct virtio_blk_config, num_queues,
+ _vqs);
+ if (err)
+ num_vqs = 1;
+
+ vblk->vqs = kmalloc(sizeof(*vblk->vqs) * num_vqs, GFP_KERNEL);
+ if (!vblk->vqs) {
+ err = -ENOMEM;
+
[PATCH v2 1/2] include/uapi/linux/virtio_blk.h: introduce feature of VIRTIO_BLK_F_MQ
Current virtio-blk spec only supports one virtual queue for transfering
data between VM and host, and inside VM all kinds of operations on
the virtual queue needs to hold one lock, so cause below problems:
- bad scalability
- bad throughput
This patch requests to introduce feature of VIRTIO_BLK_F_MQ
so that more than one virtual queues can be used to virtio-blk
device, then above problems can be solved or eased.
Signed-off-by: Ming Lei
---
include/uapi/linux/virtio_blk.h |5 +
1 file changed, 5 insertions(+)
diff --git a/include/uapi/linux/virtio_blk.h b/include/uapi/linux/virtio_blk.h
index 6d8e61c..9ad67b2 100644
--- a/include/uapi/linux/virtio_blk.h
+++ b/include/uapi/linux/virtio_blk.h
@@ -40,6 +40,7 @@
#define VIRTIO_BLK_F_WCE 9 /* Writeback mode enabled after reset */
#define VIRTIO_BLK_F_TOPOLOGY 10 /* Topology information is available */
#define VIRTIO_BLK_F_CONFIG_WCE11 /* Writeback mode available in
config */
+#define VIRTIO_BLK_F_MQ12 /* support more than one vq */
#ifndef __KERNEL__
/* Old (deprecated) name for VIRTIO_BLK_F_WCE. */
@@ -77,6 +78,10 @@ struct virtio_blk_config {
/* writeback mode (if VIRTIO_BLK_F_CONFIG_WCE) */
__u8 wce;
+ __u8 unused;
+
+ /* number of vqs, only available when VIRTIO_BLK_F_MQ is set */
+ __u16 num_queues;
} __attribute__((packed));
/*
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/2] block: virtio-blk: support multi vq per virtio-blk
Hi, These patches try to support multi virtual queues(multi-vq) in one virtio-blk device, and maps each virtual queue(vq) to blk-mq's hardware queue. With this approach, both scalability and performance on virtio-blk device can get improved. For verifying the improvement, I implements virtio-blk multi-vq over qemu's dataplane feature, and both handling host notification from each vq and processing host I/O are still kept in the per-device iothread context, the change is based on qemu v2.0.0 release, and can be accessed from below tree: git://kernel.ubuntu.com/ming/qemu.git #v2.0.0-virtblk-mq.1 For enabling the multi-vq feature, 'num_queues=N' need to be added into '-device virtio-blk-pci ...' of qemu command line, and suggest to pass 'vectors=N+1' to keep one MSI irq vector per each vq, and the feature depends on x-data-plane. Fio(libaio, randread, iodepth=64, bs=4K, jobs=N) is run inside VM to verify the improvement. I just create a small quadcore VM and run fio inside the VM, and num_queues of the virtio-blk device is set as 2, but looks the improvement is still obvious. 1), about scalability - without mutli-vq feature -- jobs=2, thoughput: 145K iops -- jobs=4, thoughput: 100K iops - with mutli-vq feature -- jobs=2, thoughput: 193K iops -- jobs=4, thoughput: 202K iops 2), about thoughput - without mutli-vq feature -- thoughput: 145K iops - with mutli-vq feature -- thoughput: 202K iops So in my test, even for a quad-core VM, if the virtqueue number is increased from 1 to 2, both scalability and performance can get improved a lot. TODO: - adjust vq's irq smp_affinity according to blk-mq hw queue's cpumask V2: (suggestions from Michael and Dave Chinner) - allocate virtqueues' pointers dynamically - make sure the per-queue spinlock isn't kept in same cache line - make each queue's name different V1: - remove RFC since no one objects - add '__u8 unused' for pending as suggested by Rusty - use virtio_cread_feature() directly, suggested by Rusty Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: wlan-ng/hfa384x_usb.c: add blank line after declarations
On Thu, 2014-06-26 at 09:55 +0800, Cheng-Wei Lee wrote:
> This patch fixes the following checkpatch.pl issues in hfa384x_usb.c:
> WARNING: Missing a blank line after declarations
This time you've got the right subject, and right type of content,
but unfortunately, the content is wrapped and can't be applied.
Please read Documentation/email-clients.txt
and resubmit.
> diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c
> b/drivers/staging/wlan-ng/hfa384x_usb.c
> index 98343ff7..07cee56 100644
> --- a/drivers/staging/wlan-ng/hfa384x_usb.c
> +++ b/drivers/staging/wlan-ng/hfa384x_usb.c
> @@ -3705,6 +3705,7 @@ static void hfa384x_usbout_callback(struct urb *urb)
> case -EPIPE:
> {
> hfa384x_t *hw = wlandev->priv;
> +
> netdev_warn(hw->wlandev->netdev,
> "%s tx pipe stalled:
> requesting reset\n",
> wlandev->netdev->name);
> --
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kthread: Fix the race condition when kthread is parked
On Wed, Jun 25, 2014 at 10:00:22PM -0400, Steven Rostedt wrote:
> On Thu, Jun 26, 2014 at 02:43:56AM +0200, Thomas Gleixner wrote:
> >
> > Subject: kthread: Plug park/ unplug race
> > From: Thomas Gleixner
> > Date: Thu, 26 Jun 2014 01:24:36 +0200
> >
> > The kthread park/unpark logic has the following issue:
> >
> > Task CPU 0CPU 1
> >
> > T1 unplug cpu1
> >kthread_park(T2)
> >set_bit(KTHREAD_SHOULD_PARK);
> > wait_for_completion()
> > T2 parkme(X)
>
> But with your patch, isn't it possible for T1 to call thread_unpark here?
Let me answer that No, it can't.
I missed the wait_for_completion() above, which will prevent this from
happening.
Nevermind, I'll go work on something less brain intensive.
-- Steve
>
> Then looking at the code I see this turn of events:
>
> if (test_bit(KTHREAD_IS_PER_CPU, >flags))
> __kthread_bind(k, kthread->cpu, TASK_PARKED);
>
> Which in __kthread_bind() (state == TASK_PARKED)
>
> if (!wait_task_inactive(p, state)) {
> WARN_ON(1);
> return;
> }
>
> Where wait_task_inactive() does:
>
> while (task_running(rq, p)) {
> if (match_state && unlikely(p->state != match_state))
> return 0;
>
> As match_state is non zero and p->state != match_state because it hasn't been
> set yet. The wait_task_inactive() returns zero, and then we hit the WARN_ON()
> in __kthread_bind().
>
> -- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[block] BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
Tejun,
In commit 09571194a9846177bea3afd18458312546112702 ("block, blk-mq:
draining can't be skipped even if bypass_depth was non-zero")
+--+++
| | f5372ab3d2 |
09571194a9 |
+--+++
| boot_successes | 25 | 19
|
| early-boot-hang | 1 |
|
| boot_failures| 0 | 6
|
| BUG:kernel_test_crashed | 0 | 1
|
| BUG:unable_to_handle_kernel_NULL_pointer_dereference | 0 | 5
|
| Oops | 0 | 5
|
| RIP:blk_throtl_drain | 0 | 5
|
| kernel_BUG_at_arch/x86/mm/pageattr.c | 0 | 5
|
| invalid_opcode | 0 | 5
|
| RIP:change_page_attr_set_clr | 0 | 5
|
| Kernel_panic-not_syncing:Fatal_exception | 0 | 5
|
| backtrace:scsi_debug_exit| 0 | 5
|
| backtrace:SyS_delete_module | 0 | 5
|
+--+++
[ 5703.793032] sda: unknown partition table
[ 5703.798102] sd 2:0:0:0: [sda] Attached SCSI disk
[ 5706.076059] sd 2:0:0:0: [sda] Synchronizing SCSI cache
[ 5706.078586] BUG: unable to handle kernel NULL pointer dereference at
0028
[ 5706.079351] IP: [] blk_throtl_drain+0x30/0x150
[ 5706.079351] PGD 0
[ 5706.079351] Oops: [#1] SMP
[ 5706.079351] Modules linked in: sd_mod scsi_debug(-) crct10dif_generic
crc_t10dif crct10dif_common loop dm_mod fuse sg sr_mod cdrom ata_generic
pata_acpi parport_pc parport snd_pcm floppy cirrus syscopyarea sysfillrect
sysimgblt ttm drm_kms_helper snd_timer snd soundcore drm pcspkr ata_piix libata
i2c_piix4
[ 5706.079351] CPU: 3 PID: 22026 Comm: rmmod Not tainted
3.16.0-rc1-wl-00737-g114249b #1
[ 5706.079351] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 5706.079351] task: 8801155f1d80 ti: 880100e9c000 task.ti:
880100e9c000
[ 5706.079351] RIP: 0010:[] []
blk_throtl_drain+0x30/0x150
[ 5706.079351] RSP: 0018:880100e9fb60 EFLAGS: 00010046
[ 5706.079351] RAX: RBX: 88007f8b2eb0 RCX: 8800974c77a0
[ 5706.079351] RDX: RSI: RDI:
[ 5706.079351] RBP: 880100e9fb78 R08: R09: 0046
[ 5706.079351] R10: 880100e9fb78 R11: R12: 88007f8b2eb0
[ 5706.079351] R13: 8800863ef300 R14: 88007f8b3508 R15: 88008a3c2120
[ 5706.079351] FS: 7fac6a962700() GS:88011fd8()
knlGS:
[ 5706.079351] CS: 0010 DS: ES: CR0: 8005003b
[ 5706.079351] CR2: 0028 CR3: 000110261000 CR4: 06e0
[ 5706.079351] Stack:
[ 5706.079351] 88007f8b2eb0 88007f8b3518
880100e9fb88
[ 5706.079351] 813cabee 880100e9fbb8 813afcec
88007f8b2eb0
[ 5706.079351] 81cf8760 88007f8b2eb0 88008a3c2000
880100e9fbd0
[ 5706.079351] Call Trace:
[ 5706.079351] [] blkcg_drain_queue+0xe/0x10
[ 5706.079351] [] __blk_drain_queue+0x7c/0x180
[ 5706.079351] [] blk_queue_bypass_start+0x8e/0xd0
[ 5706.079351] [] blkcg_deactivate_policy+0x38/0x140
[ 5706.079351] [] blk_throtl_exit+0x34/0x50
[ 5706.079351] [] blkcg_exit_queue+0x48/0x70
[ 5706.079351] [] blk_release_queue+0x26/0x100
[ 5706.079351] [] kobject_cleanup+0x77/0x1b0
[ 5706.079351] [] kobject_put+0x28/0x60
[ 5706.079351] [] blk_put_queue+0x15/0x20
[ 5706.079351] []
scsi_device_dev_release_usercontext+0xbb/0x120
[ 5706.079351] [] execute_in_process_context+0x67/0x70
[ 5706.079351] [] scsi_device_dev_release+0x1c/0x20
[ 5706.079351] [] device_release+0x32/0xa0
[ 5706.079351] [] kobject_cleanup+0x77/0x1b0
[ 5706.079351] [] kobject_put+0x28/0x60
[ 5706.079351] [] put_device+0x17/0x20
[ 5706.079351] [] __scsi_remove_device+0xa9/0xe0
[ 5706.079351] [] scsi_forget_host+0x64/0x70
[ 5706.079351] [] scsi_remove_host+0x77/0x120
[ 5706.079351] [] sdebug_driver_remove+0x29/0x90 [scsi_debug]
[ 5706.079351] [] __device_release_driver+0x7f/0xf0
[ 5706.079351] [] device_release_driver+0x23/0x30
[ 5706.079351] [] bus_remove_device+0x108/0x180
[ 5706.079351] [] device_del+0x129/0x1c0
[ 5706.079351] [] device_unregister+0x1e/0x60
[ 5706.079351] [] sdebug_remove_adapter+0x4c/0x70
[scsi_debug]
[ 5706.079351] [] scsi_debug_exit+0x19/0xaec [scsi_debug]
[ 5706.079351] [] SyS_delete_module+0x12e/0x1c0
[ 5706.079351]
[rcu] 34577530114: +247.4% qperf.tcp.bw, -3.3% turbostat.Pkg_W
Hi Paul,
We are pleased to notice huge throughput increases in the qperf/iperf
tests, together with noticeable reduce of power consumption!
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/dev
commit 34577530114e9b1de10f3aa9665bb28c8ce585ba ("rcu: Bind grace-period
kthreads to non-NO_HZ_FULL CPUs")
221031cb1b33258 34577530114e9b1de10f3aa96
--- -
8.23e+08 ~ 6%+247.4% 2.859e+09 ~ 0% bens/qperf/600s
8.23e+08 ~ 6%+247.4% 2.859e+09 ~ 0% TOTAL qperf.tcp.bw
221031cb1b33258 34577530114e9b1de10f3aa96
--- -
7.065e+09 ~ 3%+210.0% 2.19e+10 ~ 8% bens/iperf/300s-tcp
7.065e+09 ~ 3%+210.0% 2.19e+10 ~ 8% TOTAL iperf.tcp.sender.bps
221031cb1b33258 34577530114e9b1de10f3aa96
--- -
7.065e+09 ~ 3%+210.0% 2.19e+10 ~ 8% bens/iperf/300s-tcp
7.065e+09 ~ 3%+210.0% 2.19e+10 ~ 8% TOTAL iperf.tcp.receiver.bps
221031cb1b33258 34577530114e9b1de10f3aa96
--- -
7.718e+08 ~ 3%+177.8% 2.144e+09 ~ 1% bens/qperf/600s
7.718e+08 ~ 3%+177.8% 2.144e+09 ~ 1% TOTAL qperf.udp.recv_bw
221031cb1b33258 34577530114e9b1de10f3aa96
--- -
7.745e+08 ~ 3%+177.0% 2.145e+09 ~ 1% bens/qperf/600s
7.745e+08 ~ 3%+177.0% 2.145e+09 ~ 1% TOTAL qperf.udp.send_bw
221031cb1b33258 34577530114e9b1de10f3aa96
--- -
1.65e+09 ~ 1% +4.3% 1.721e+09 ~ 0% bens/qperf/600s
1.65e+09 ~ 1% +4.3% 1.721e+09 ~ 0% TOTAL qperf.sctp.bw
221031cb1b33258 34577530114e9b1de10f3aa96
--- -
13579 ~ 1% -2.3% 13264 ~ 1% bens/qperf/600s
13579 ~ 1% -2.3% 13264 ~ 1% TOTAL qperf.sctp.latency
221031cb1b33258 34577530114e9b1de10f3aa96
--- -
8545 ~ 0% +1.9% 8705 ~ 0% bens/qperf/600s
8545 ~ 0% +1.9% 8705 ~ 0% TOTAL qperf.udp.latency
221031cb1b33258 34577530114e9b1de10f3aa96
--- -
12770 ~ 0% -1.0% 12637 ~ 0% ivb43/netperf/300s-25%-TCP_CRR
12770 ~ 0% -1.0% 12637 ~ 0% TOTAL netperf.Throughput_tps
221031cb1b33258 34577530114e9b1de10f3aa96
--- -
1015 ~ 2% -92.1% 80 ~24% ivb43/netperf/300s-25%-TCP_CRR
1015 ~ 2% -92.1% 80 ~24% TOTAL cpuidle.POLL.usage
221031cb1b33258 34577530114e9b1de10f3aa96
--- -
104620 ~31% -83.2% 17544 ~11% ivb43/netperf/300s-25%-TCP_CRR
104620 ~31% -83.2% 17544 ~11% TOTAL numa-vmstat.node1.numa_other
221031cb1b33258 34577530114e9b1de10f3aa96
--- -
0.12 ~ 7% -73.3% 0.03 ~12% ivb43/netperf/300s-25%-TCP_CRR
0.12 ~ 7% -73.3% 0.03 ~12% TOTAL turbostat.%c3
221031cb1b33258 34577530114e9b1de10f3aa96
--- -
53226067 ~ 3% -78.2% 11579930 ~14% ivb43/netperf/300s-25%-TCP_CRR
3327687 ~28% +86.6%6208767 ~42% ivb44/pigz/25%-128K
56553754 ~ 4% -68.5% 17788697 ~24% TOTAL cpuidle.C1E-IVT.time
221031cb1b33258 34577530114e9b1de10f3aa96
--- -
878601 ~ 3% -75.2% 217607 ~12% ivb43/netperf/300s-25%-TCP_CRR
9282 ~27% +99.2% 18495 ~49% ivb44/pigz/25%-128K
887884 ~ 4% -73.4% 236102 ~15% TOTAL cpuidle.C1E-IVT.usage
221031cb1b33258 34577530114e9b1de10f3aa96
--- -
28174239 ~ 6% -61.0% 10981001 ~ 8% ivb43/netperf/300s-25%-TCP_CRR
28174239 ~ 6% -61.0% 10981001 ~ 8% TOTAL cpuidle.C3-IVT.time
221031cb1b33258 34577530114e9b1de10f3aa96
--- -
237 ~20%+141.1%572 ~ 9% xbm/pigz/25%-512K
237 ~20%+141.1%572 ~ 9% TOTAL cpuidle.C3-SNB.usage
221031cb1b33258 34577530114e9b1de10f3aa96
--- -
8192746 ~ 3%+202.8% 24806641 ~ 7% bens/iperf/300s-tcp
15458478 ~ 1% +69.2% 26148854 ~ 0% bens/qperf/600s
23651225 ~ 2%+115.4% 50955496 ~ 4% TOTAL proc-vmstat.numa_hit
221031cb1b33258 34577530114e9b1de10f3aa96
--- -
8192746 ~ 3%+202.8% 24806641 ~ 7% bens/iperf/300s-tcp
15458478 ~ 1% +69.2% 26148854 ~ 0% bens/qperf/600s
23651225 ~ 2%+115.4% 50955496 ~ 4% TOTAL proc-vmstat.numa_local
221031cb1b33258 34577530114e9b1de10f3aa96
--- -
63502648 ~ 3%+209.1% 1.963e+08 ~ 8% bens/iperf/300s-tcp
2.191e+08 ~ 1% +55.9% 3.416e+08 ~ 0% bens/qperf/600s
2.826e+08 ~ 2% +90.3% 5.379e+08 ~ 3% TOTAL proc-vmstat.pgfree
221031cb1b33258
Re: [PATCH] kthread: Fix the race condition when kthread is parked
On Thu, Jun 26, 2014 at 02:43:56AM +0200, Thomas Gleixner wrote:
>
> Subject: kthread: Plug park/ unplug race
> From: Thomas Gleixner
> Date: Thu, 26 Jun 2014 01:24:36 +0200
>
> The kthread park/unpark logic has the following issue:
>
> Task CPU 0 CPU 1
>
> T1 unplug cpu1
>kthread_park(T2)
>set_bit(KTHREAD_SHOULD_PARK);
> wait_for_completion()
> T2parkme(X)
But with your patch, isn't it possible for T1 to call thread_unpark here?
Then looking at the code I see this turn of events:
if (test_bit(KTHREAD_IS_PER_CPU, >flags))
__kthread_bind(k, kthread->cpu, TASK_PARKED);
Which in __kthread_bind() (state == TASK_PARKED)
if (!wait_task_inactive(p, state)) {
WARN_ON(1);
return;
}
Where wait_task_inactive() does:
while (task_running(rq, p)) {
if (match_state && unlikely(p->state != match_state))
return 0;
As match_state is non zero and p->state != match_state because it hasn't been
set yet. The wait_task_inactive() returns zero, and then we hit the WARN_ON()
in __kthread_bind().
-- Steve
> __set_current_state(TASK_PARKED);
> while (test_bit(KTHREAD_SHOULD_PARK))
> {
> if
> (!test_and_set_bit(KTHREAD_IS_PARKED))
> complete();
> schedule();
> T1 plug cpu1
>
> --> premature wakeup of T2, i.e. before unpark, so T2 gets scheduled on
> CPU 0
>
> T2__set_current_state(TASK_PARKED);
>
> --> Preemption by the plug thread
>
> T1 thread_unpark(T2)
> clear_bit(KTHREAD_SHOULD_PARK);
>
> --> Preemption by the softirq thread which breaks out of the
> while(test_bit(KTHREAD_SHOULD_PARK)) loop because
> KTHREAD_SHOULD_PARK is not longer set.
>
> T2 }
> clear_bit(KTHREAD_IS_PARKED);
>
> --> Now T2 happily continues to run on CPU0 which rightfully causes
> the BUG_ON(T2->cpu != smp_processor_id()) to trigger.
>
> T1
> __kthread_bind(T2)
>
> --> Too late
>
> Reorder the logic so that the unplug code binds the thread to the
> target cpu before clearing the KTHREAD_SHOULD_PARK bit.
>
> Reported-by: Subbaraman Narayanamurthy
> Signed-off-by: Thomas Gleixner
> Cc: sta...@vger.kernel.org
>
> ---
> kernel/kthread.c | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> Index: linux/kernel/kthread.c
> ===
> --- linux.orig/kernel/kthread.c
> +++ linux/kernel/kthread.c
> @@ -382,6 +382,15 @@ struct task_struct *kthread_create_on_cp
>
> static void __kthread_unpark(struct task_struct *k, struct kthread *kthread)
> {
> + /*
> + * Rebind the thread to the target cpu first if it is a per
> + * cpu thread unconditionally because it must be bound to the
> + * target cpu before it can observe the KTHREAD_SHOULD_PARK
> + * bit cleared.
> + */
> + if (test_bit(KTHREAD_IS_PER_CPU, >flags))
> + __kthread_bind(k, kthread->cpu, TASK_PARKED);
> +
> clear_bit(KTHREAD_SHOULD_PARK, >flags);
> /*
>* We clear the IS_PARKED bit here as we don't wait
> @@ -389,11 +398,8 @@ static void __kthread_unpark(struct task
>* park before that happens we'd see the IS_PARKED bit
>* which might be about to be cleared.
>*/
> - if (test_and_clear_bit(KTHREAD_IS_PARKED, >flags)) {
> - if (test_bit(KTHREAD_IS_PER_CPU, >flags))
> - __kthread_bind(k, kthread->cpu, TASK_PARKED);
> + if (test_and_clear_bit(KTHREAD_IS_PARKED, >flags))
> wake_up_state(k, TASK_PARKED);
> - }
> }
>
> /**
>
>
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[rcu] 0acd7c39a85: +11.0% will-it-scale.scalability
Hi Paul,
FYI, we are pleased to notice big performance gains in some
will-it-scale test cases:
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
rcu_cond_resched.2014.06.20c
commit 0acd7c39a85836d90451b6c278c5cfdd21c055f3 ("rcu: Add RCU_COND_RESCHED_QS
for large systems")
acf426994c75e38 0acd7c39a85836d90451b6c27
--- -
0.30 ~ 2% +14.3% 0.34 ~ 3% lkp-sbx04/will-it-scale/open1
0.34 ~ 3% +8.1% 0.37 ~ 1% nhm4/will-it-scale/read1
0.64 ~ 3% +11.0% 0.71 ~ 2% TOTAL will-it-scale.scalability
acf426994c75e38 0acd7c39a85836d90451b6c27
--- -
592828 ~ 1% +3.8% 615531 ~ 1% lkp-sbx04/will-it-scale/open1
592828 ~ 1% +3.8% 615531 ~ 1% TOTAL will-it-scale.per_process_ops
acf426994c75e38 0acd7c39a85836d90451b6c27
--- -
1689 ~ 0%+498.1% 10107 ~ 2% lkp-sbx04/will-it-scale/unlink2
1689 ~ 0%+498.1% 10107 ~ 2% TOTAL slabinfo.dentry.active_slabs
acf426994c75e38 0acd7c39a85836d90451b6c27
--- -
72052 ~ 0%+489.8% 424930 ~ 2% lkp-sbx04/will-it-scale/unlink2
72052 ~ 0%+489.8% 424930 ~ 2% TOTAL slabinfo.Acpi-State.num_objs
acf426994c75e38 0acd7c39a85836d90451b6c27
--- -
71629 ~ 0%+492.6% 424494 ~ 2% lkp-sbx04/will-it-scale/unlink2
71629 ~ 0%+492.6% 424494 ~ 2% TOTAL
slabinfo.Acpi-State.active_objs
acf426994c75e38 0acd7c39a85836d90451b6c27
--- -
1689 ~ 0%+498.1% 10107 ~ 2% lkp-sbx04/will-it-scale/unlink2
1689 ~ 0%+498.1% 10107 ~ 2% TOTAL slabinfo.dentry.num_slabs
acf426994c75e38 0acd7c39a85836d90451b6c27
--- -
1412 ~ 0%+490.0% 8331 ~ 2% lkp-sbx04/will-it-scale/unlink2
1412 ~ 0%+490.0% 8331 ~ 2% TOTAL
slabinfo.Acpi-State.active_slabs
acf426994c75e38 0acd7c39a85836d90451b6c27
--- -
70980 ~ 0%+498.1% 424517 ~ 2% lkp-sbx04/will-it-scale/unlink2
70980 ~ 0%+498.1% 424517 ~ 2% TOTAL slabinfo.dentry.num_objs
acf426994c75e38 0acd7c39a85836d90451b6c27
--- -
70444 ~ 0%+502.0% 424054 ~ 2% lkp-sbx04/will-it-scale/unlink2
70444 ~ 0%+502.0% 424054 ~ 2% TOTAL slabinfo.dentry.active_objs
acf426994c75e38 0acd7c39a85836d90451b6c27
--- -
472 ~ 0% +1557.0% 7827 ~ 2% lkp-sbx04/will-it-scale/unlink2
472 ~ 0% +1557.0% 7827 ~ 2% TOTAL
slabinfo.shmem_inode_cache.num_slabs
acf426994c75e38 0acd7c39a85836d90451b6c27
--- -
472 ~ 0% +1557.0% 7827 ~ 2% lkp-sbx04/will-it-scale/unlink2
472 ~ 0% +1557.0% 7827 ~ 2% TOTAL
slabinfo.shmem_inode_cache.active_slabs
acf426994c75e38 0acd7c39a85836d90451b6c27
--- -
22697 ~ 0% +1555.5% 375756 ~ 2% lkp-sbx04/will-it-scale/unlink2
22697 ~ 0% +1555.5% 375756 ~ 2% TOTAL
slabinfo.shmem_inode_cache.num_objs
acf426994c75e38 0acd7c39a85836d90451b6c27
--- -
22297 ~ 0% +1584.0% 375494 ~ 2% lkp-sbx04/will-it-scale/unlink2
22297 ~ 0% +1584.0% 375494 ~ 2% TOTAL
slabinfo.shmem_inode_cache.active_objs
acf426994c75e38 0acd7c39a85836d90451b6c27
--- -
1412 ~ 0%+490.0% 8331 ~ 2% lkp-sbx04/will-it-scale/unlink2
1412 ~ 0%+490.0% 8331 ~ 2% TOTAL slabinfo.Acpi-State.num_slabs
acf426994c75e38 0acd7c39a85836d90451b6c27
--- -
230182 ~ 2%+214.7% 724407 ~ 1% lkp-sbx04/will-it-scale/open1
29926 ~ 1% +1179.6% 382938 ~ 2% lkp-sbx04/will-it-scale/unlink2
260108 ~ 2%+325.7%1107345 ~ 1% TOTAL
slabinfo.kmalloc-256.active_objs
acf426994c75e38 0acd7c39a85836d90451b6c27
--- -
3605 ~ 2%+214.1% 11325 ~ 1% lkp-sbx04/will-it-scale/open1
478 ~ 1% +1153.4% 5991 ~ 2% lkp-sbx04/will-it-scale/unlink2
4083 ~ 2%+324.1% 17316 ~ 1% TOTAL slabinfo.kmalloc-256.num_slabs
acf426994c75e38 0acd7c39a85836d90451b6c27
--- -
3605 ~ 2%+214.1% 11325 ~ 1% lkp-sbx04/will-it-scale/open1
478 ~ 1% +1153.4% 5991 ~ 2% lkp-sbx04/will-it-scale/unlink2
4083 ~ 2%+324.1% 17316 ~ 1% TOTAL
slabinfo.kmalloc-256.active_slabs
acf426994c75e38 0acd7c39a85836d90451b6c27
--- -
230776 ~ 2%+214.1% 724862 ~ 1% lkp-sbx04/will-it-scale/open1
30619 ~ 1%
[PATCH] staging: wlan-ng/hfa384x_usb.c: add blank line after declarations
This patch fixes the following checkpatch.pl issues in hfa384x_usb.c:
WARNING: Missing a blank line after declarations
Signed-off-by: Quentin Lee
---
drivers/staging/wlan-ng/hfa384x_usb.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c
b/drivers/staging/wlan-ng/hfa384x_usb.c
index 98343ff7..07cee56 100644
--- a/drivers/staging/wlan-ng/hfa384x_usb.c
+++ b/drivers/staging/wlan-ng/hfa384x_usb.c
@@ -3705,6 +3705,7 @@ static void hfa384x_usbout_callback(struct urb *urb)
case -EPIPE:
{
hfa384x_t *hw = wlandev->priv;
+
netdev_warn(hw->wlandev->netdev,
"%s tx pipe stalled:
requesting reset\n",
wlandev->netdev->name);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] cpufreq: cpu0: Extend support beyond CPU0
On 26 June 2014 00:32, Stephen Boyd wrote:
> It should be easy enough to read the clocks property from DT for all the
> CPU nodes and check to see if they're the same?
Not everybody has clocks supported in DT and I am not sure if it will
even work for the current users as well..
But yeah, that's one way of finding it out.
> I don't think we need an affected-cpus property.
There was some work going around to fix bindings for CPUs that share
resources, for the bigger task of making "cpufreq work well with
scheduler". And we can use them probably.
> Also I'd like to see current DTs specifying the
> same data (clocks, regulators, opps) for each CPU node even if they all
> share the same clock, regulator, and opp. It seems that the cpu0 binding
> just wanted to save some space in the DT by consolidating them all under
> one node, but that seems misguided. Case in point, now that we have
> configurations that need more than one clock per cluster the code is
> complicated and the binding is not uniform.
Hmm, probably you are right. But again we may not have nodes for
these in DT for few users of cpufreq-cpu0 and we need to investigate
for that.
>> diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
> This patch would be less noisy and easier to review if we used local
> variables in this function for cpu_req, voltage_tolerance, and cpu_clk.
> Can we do that please?
Hmm, yeah will try to make it less noisy.
>> -static int cpu0_cpufreq_probe(struct platform_device *pdev)
>> -{
>> + struct cpufreq_frequency_table *freq_table;
>> + struct private_data *priv;
>> struct device_node *np;
>> - int ret;
>> + char name[] = "cpuX";
>> + int ret, cpu = policy->cpu;
>>
>> - cpu_dev = get_cpu_device(0);
>> - if (!cpu_dev) {
>> - pr_err("failed to get cpu0 device\n");
>> - return -ENODEV;
>> + priv = kzalloc(sizeof(*priv), GFP_KERNEL);
>> + if (!priv) {
>> + pr_err("%s: Memory allocation failed\n", __func__);
>
> Useless allocation error message.
Why so useless? You meant we should mention 'priv' here?
Will do.
>> + return -ENOMEM;
>> }
>>
>> - np = of_node_get(cpu_dev->of_node);
>> - if (!np) {
>> - pr_err("failed to find cpu0 node\n");
>> - return -ENOENT;
>> - }
>> + /* Below calls can't fail from here */
>> + priv->cpu_dev = get_cpu_device(cpu);
>> + np = of_node_get(priv->cpu_dev->of_node);
>>
>> - cpu_reg = regulator_get_optional(cpu_dev, "cpu0");
>> - if (IS_ERR(cpu_reg)) {
>> - /*
>> - * If cpu0 regulator supply node is present, but regulator is
>> - * not yet registered, we should try defering probe.
>> - */
>> - if (PTR_ERR(cpu_reg) == -EPROBE_DEFER) {
>> - dev_err(cpu_dev, "cpu0 regulator not ready, retry\n");
>> - ret = -EPROBE_DEFER;
>> - goto out_put_node;
>> - }
>> - pr_warn("failed to get cpu0 regulator: %ld\n",
>> - PTR_ERR(cpu_reg));
>> + policy->clk = clk_get(priv->cpu_dev, NULL);
>> + if (IS_ERR(policy->clk)) {
>> + ret = PTR_ERR(policy->clk);
>> + pr_err("%s: failed to get cpu%d clock: %d\n", __func__, cpu,
>> +ret);
>> + goto out_put_node;
>> }
>
> This won't work all the time. We need probe defer to work for the clocks
> because sometimes CPU clocks are registered after this driver probes. In
> my case this is always true unless I play games with initcall levels.
> The same is true for regulators.
Okay..
>> - cpu_clk = clk_get(cpu_dev, NULL);
>> - if (IS_ERR(cpu_clk)) {
>> - ret = PTR_ERR(cpu_clk);
>> - pr_err("failed to get cpu0 clock: %d\n", ret);
>> - goto out_put_reg;
>> + ret = of_init_opp_table(priv->cpu_dev);
>> + if (ret) {
>> + pr_err("%s: failed to init OPP table for cpu%d: %d\n",
>> __func__,
>> +cpu, ret);
>> + goto out_put_clk;
>> }
>>
>> - ret = of_init_opp_table(cpu_dev);
>> + ret = dev_pm_opp_init_cpufreq_table(priv->cpu_dev, _table);
>> if (ret) {
>> - pr_err("failed to init OPP table: %d\n", ret);
>> + pr_err("%s: failed to init cpufreq table for cpu%d: %d\n",
>> +__func__, cpu, ret);
>> goto out_put_clk;
>> }
>>
>> - ret = dev_pm_opp_init_cpufreq_table(cpu_dev, _table);
>> + ret = cpufreq_table_validate_and_show(policy, freq_table);
>> if (ret) {
>> - pr_err("failed to init cpufreq table: %d\n", ret);
>> - goto out_put_clk;
>> + pr_err("%s: invalid frequency table for cpu%d: %d\n", __func__,
>> +cpu, ret);
>> + goto out_put_reg;
>> }
>>
>> - of_property_read_u32(np, "voltage-tolerance",
Re: [PATCH 2/2] staging: wlan-ng/hfa384x_usb.c: remove return statements for void function
Hi Joe,
Thanks for your kindly reply.
I'll submit patch again.
Many thanks,
Quentin
2014-06-26 8:09 GMT+08:00, Joe Perches :
> On Wed, 2014-06-25 at 23:35 +0800, Cheng-Wei Lee wrote:
>> This patch fixes the following checkpatch.pl issues in hfa384x_usb.c:
>> WARNING: Missing a blank line after declarations
>
> Still has a mismatch between subject and code
>
>> diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c
> []
>> @@ -3533,7 +3533,7 @@ static void hfa384x_usbin_rx(wlandevice_t
>> *wlandev, struct sk_buff *skb)
>> }
>>
>> done:
>> -return;
>> +pr_debug("hfa384x_usbin_rx: done\n");
>
> I suggest you just leave the return,
>
> Any checkpatch suggestion this was needed was a false
> positive that should be resolved by this patch:
>
> http://article.gmane.org/gmane.linux.kernel/1728891
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[rcu] e552592e038: +39.2% vm-scalability.throughput, +19.7% turbostat.Pkg_W
Hi Paul,
We noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
urgent.2014.06.21a
commit e552592e0383bc72e35eb21a9fabd84ad873cff1 ("rcu: Reduce overhead of
cond_resched() checks for RCU")
Test case: brickland3/vm-scalability/300s-anon-w-seq-mt-64G
v3.16-rc1 e552592e0383bc72e35eb21a9
--- -
89766370 ~ 6% +39.2% 1.25e+08 ~ 9% TOTAL vm-scalability.throughput
1.317e+09 ~ 8% -45.2% 7.21e+08 ~10% TOTAL cpuidle.C6-IVT-4S.time
9 ~ 6% +58.8% 15 ~ 5% TOTAL vmstat.procs.r
12.27 ~14% +44.7% 17.74 ~12% TOTAL turbostat.%c1
20538 ~ 4% -21.3% 16155 ~ 4% TOTAL cpuidle.C6-IVT-4S.usage
77.66 ~ 2% -15.0% 65.98 ~ 5% TOTAL turbostat.%c6
260 ~ 2% -16.4%217 ~ 4% TOTAL vmstat.memory.buff
51920 ~ 7% -14.3% 44489 ~ 5% TOTAL numa-meminfo.node0.PageTables
53822 ~ 5% -15.6% 45404 ~ 6% TOTAL
proc-vmstat.nr_page_table_pages
215196 ~ 5% -15.7% 181409 ~ 6% TOTAL meminfo.PageTables
52182 ~ 4% -15.2% 44271 ~ 6% TOTAL
proc-vmstat.nr_anon_transparent_hugepages
12881 ~ 7% -13.4% 11150 ~ 5% TOTAL
numa-vmstat.node0.nr_page_table_pages
1.068e+08 ~ 4% -15.2% 90492587 ~ 6% TOTAL meminfo.AnonHugePages
26983682 ~ 4% -14.5% 23071571 ~ 6% TOTAL proc-vmstat.nr_anon_pages
1.079e+08 ~ 4% -14.5% 92289854 ~ 6% TOTAL meminfo.AnonPages
1.083e+08 ~ 4% -14.2% 92897630 ~ 6% TOTAL meminfo.Active(anon)
1.084e+08 ~ 4% -14.2% 92970821 ~ 6% TOTAL meminfo.Active
27067517 ~ 4% -14.2% 23232055 ~ 6% TOTAL proc-vmstat.nr_active_anon
52565 ~ 3% -12.0% 46273 ~ 3% TOTAL proc-vmstat.nr_shmem
52499 ~ 3% -12.0% 46215 ~ 3% TOTAL proc-vmstat.nr_inactive_anon
214447 ~ 3% -10.5% 191862 ~ 2% TOTAL meminfo.Shmem
214197 ~ 3% -10.5% 191636 ~ 2% TOTAL meminfo.Inactive(anon)
2779 ~13% -53.5% 1291 ~19% TOTAL
time.involuntary_context_switches
1156 ~ 8% +82.3% 2108 ~ 9% TOTAL
time.percent_of_cpu_this_job_got
11.58 ~10% -44.4% 6.45 ~ 9% TOTAL time.elapsed_time
1008 ~ 5% +79.5% 1810 ~ 7% TOTAL
time.voluntary_context_switches
9.23 ~ 8% +72.8% 15.95 ~ 8% TOTAL turbostat.%c0
12679 ~ 8% +70.8% 21659 ~ 9% TOTAL vmstat.system.in
145 ~ 7% +60.6%234 ~ 8% TOTAL vmstat.io.bo
3721 ~ 7% +35.2% 5029 ~ 8% TOTAL vmstat.system.cs
~ 1% +26.7%~ 5% TOTAL turbostat.Cor_W
~ 2% +21.2%~ 3% TOTAL turbostat.RAM_W
~ 1% +19.7%~ 4% TOTAL turbostat.Pkg_W
All test cases:
v3.16-rc1 e552592e0383bc72e35eb21a9
--- -
89766370 ~ 6% +39.2% 1.25e+08 ~ 9%
brickland3/vm-scalability/300s-anon-w-seq-mt-64G
89766370 ~ 6% +39.2% 1.25e+08 ~ 9% TOTAL vm-scalability.throughput
v3.16-rc1 e552592e0383bc72e35eb21a9
--- -
0.36 ~ 1% -9.8% 0.32 ~ 2% lkp-nex05/will-it-scale/open1
0.36 ~ 1% -9.8% 0.32 ~ 2% TOTAL will-it-scale.scalability
v3.16-rc1 e552592e0383bc72e35eb21a9
--- -
466616 ~ 1% -2.6% 454267 ~ 1% lkp-nex05/will-it-scale/open1
511556 ~ 0% -1.3% 504762 ~ 0% lkp-snb01/will-it-scale/signal1
978172 ~ 0% -2.0% 959029 ~ 0% TOTAL will-it-scale.per_process_ops
v3.16-rc1 e552592e0383bc72e35eb21a9
--- -
1381706 ~ 1% +2.3%1413190 ~ 0% lkp-snb01/will-it-scale/futex2
299558 ~ 0% -1.8% 294312 ~ 0% lkp-snb01/will-it-scale/signal1
1681264 ~ 1% +1.6%1707503 ~ 0% TOTAL will-it-scale.per_thread_ops
v3.16-rc1 e552592e0383bc72e35eb21a9
--- -
84771 ~ 2%+575.2% 572390 ~ 1% lkp-nex05/will-it-scale/open1
84771 ~ 2%+575.2% 572390 ~ 1% TOTAL
slabinfo.kmalloc-256.active_objs
v3.16-rc1 e552592e0383bc72e35eb21a9
--- -
2656 ~ 2%+573.8% 17896 ~ 1% lkp-nex05/will-it-scale/open1
2656 ~ 2%+573.8% 17896 ~ 1% TOTAL slabinfo.kmalloc-256.num_slabs
v3.16-rc1 e552592e0383bc72e35eb21a9
--- -
85011 ~ 2%+573.7% 572697 ~ 1% lkp-nex05/will-it-scale/open1
85011 ~ 2%+573.7% 572697 ~ 1% TOTAL slabinfo.kmalloc-256.num_objs
v3.16-rc1 e552592e0383bc72e35eb21a9
--- -
2656 ~ 2%+573.8% 17896 ~ 1% lkp-nex05/will-it-scale/open1
2656 ~ 2%+573.8% 17896 ~ 1% TOTAL
slabinfo.kmalloc-256.active_slabs
v3.16-rc1 e552592e0383bc72e35eb21a9
---
Re: [PATCH V7 1/6] power: reset: Add generic SYSCON register mapped reset
On Thu, Jun 26, 2014 at 7:03 AM, Feng Kan wrote:
> Add a generic SYSCON register mapped reset mechanism.
>
> Signed-off-by: Feng Kan
> ---
> drivers/power/reset/Kconfig | 6 +++
> drivers/power/reset/Makefile| 1 +
> drivers/power/reset/syscon-reboot.c | 91
> +
> 3 files changed, 98 insertions(+)
> create mode 100644 drivers/power/reset/syscon-reboot.c
>
> diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
> index bdcf517..7035236 100644
> --- a/drivers/power/reset/Kconfig
> +++ b/drivers/power/reset/Kconfig
> @@ -80,3 +80,9 @@ config POWER_RESET_KEYSTONE
> help
> Reboot support for the KEYSTONE SoCs.
>
> +config POWER_RESET_SYSCON
> + bool "Generic SYSCON regmap reset driver"
> + depends on ARCH_XGENE
If this is supposed to be generic, why are you depending on
a certain platform?
ChenYu
> + depends on POWER_RESET && MFD_SYSCON
> + help
> + Reboot support for generic SYSCON mapped register reset.
> diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
> index dde2e8b..b1b5ab3 100644
> --- a/drivers/power/reset/Makefile
> +++ b/drivers/power/reset/Makefile
> @@ -8,3 +8,4 @@ obj-$(CONFIG_POWER_RESET_SUN6I) += sun6i-reboot.o
> obj-$(CONFIG_POWER_RESET_VEXPRESS) += vexpress-poweroff.o
> obj-$(CONFIG_POWER_RESET_XGENE) += xgene-reboot.o
> obj-$(CONFIG_POWER_RESET_KEYSTONE) += keystone-reset.o
> +obj-$(CONFIG_POWER_RESET_SYSCON) += syscon-reboot.o
> diff --git a/drivers/power/reset/syscon-reboot.c
> b/drivers/power/reset/syscon-reboot.c
> new file mode 100644
> index 000..9c15ba5
> --- /dev/null
> +++ b/drivers/power/reset/syscon-reboot.c
> @@ -0,0 +1,91 @@
> +/*
> + * Generic Syscon Reboot Driver
> + *
> + * Copyright (c) 2013, Applied Micro Circuits Corporation
> + * Author: Feng Kan
> + *
> + * 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.
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct syscon_reboot_context {
> + struct regmap *map;
> + u32 offset;
> + u32 mask;
> +};
> +
> +static struct syscon_reboot_context *syscon_reboot_ctx;
> +
> +static void syscon_restart(enum reboot_mode reboot_mode, const char *cmd)
> +{
> + struct syscon_reboot_context *ctx = syscon_reboot_ctx;
> + unsigned long timeout;
> +
> + /* Issue the reboot */
> + if (ctx->map)
> + regmap_write(ctx->map, ctx->offset, ctx->mask);
> +
> + timeout = jiffies + HZ;
> + while (time_before(jiffies, timeout))
> + cpu_relax();
> +
> + pr_emerg("Unable to restart system\n");
> +}
> +
> +static int syscon_reboot_probe(struct platform_device *pdev)
> +{
> + struct syscon_reboot_context *ctx;
> + struct device *dev = >dev;
> +
> + ctx = devm_kzalloc(>dev, sizeof(*ctx), GFP_KERNEL);
> + if (!ctx) {
> + dev_err(>dev, "out of memory for context\n");
> + return -ENOMEM;
> + }
> +
> + ctx->map = syscon_regmap_lookup_by_phandle(dev->of_node, "regmap");
> + if (IS_ERR(ctx->map))
> + return PTR_ERR(ctx->map);
> +
> + if (of_property_read_u32(pdev->dev.of_node, "offset", >offset))
> + return -EINVAL;
> +
> + if (of_property_read_u32(pdev->dev.of_node, "mask", >mask))
> + return -EINVAL;
> +
> + arm_pm_restart = syscon_restart;
> + syscon_reboot_ctx = ctx;
> +
> + return 0;
> +}
> +
> +static struct of_device_id syscon_reboot_of_match[] = {
> + { .compatible = "syscon-reboot" },
> + {}
> +};
> +
> +static struct platform_driver syscon_reboot_driver = {
> + .probe = syscon_reboot_probe,
> + .driver = {
> + .name = "syscon-reboot",
> + .of_match_table = syscon_reboot_of_match,
> + },
> +};
> +module_platform_driver(syscon_reboot_driver);
> --
> 1.9.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] USB: ehci-pci: USB host controller support for Intel Quark X1000
> > > > OK, I will change ' usb_is_intel_qrk ' to ' usb_is_intel_quark'. > > Or even usb_is_intel_quark_x1000() ? > OK, I will change the function name as your suggestion to make it more specific. > David > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] FS/JBD:replace count*size kmalloc by kmalloc_array
On Wed, Jun 25, 2014 at 08:49:06PM +0200, Fabian Frederick wrote: > kmalloc_array manages count*sizeof overflow. Except in these call sites, overflow is impossible. kmalloc_array() is useful when count is coming from an unvalidated source. But in this case, the count is either a fixed, hard-coded value (256), or the size of n*count is *guaranteed* to be less than the page size. So this just adds some extra code which is pointless (assuming the compiler isn't smart enough to optimize it out). - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] USB: ehci-pci: USB host controller support for Intel Quark X1000
> > This patch is to enable USB host controller for Intel Quark X1000. Add
> > pci quirks to adjust the packet buffer in/out threshold value, and
> > ensure EHCI packet buffer i/o threshold value is reconfigured to half.
>
> Please add more detailed description. For example, why is it necessary to
> reconfigure the threshold value?
>
This patch try to reconfigure the threshold value as maximal (0x7F DWord) as
possible since the default value is just 0x20 DWord, and I will update the
description.
> >
> > +
> > +#define EHCI_INSNREG01 0x84
> > +#define EHCI_INSNREG01_THRESH 0x007F007F /* Threshold value */
>
> What does this magic number mean?
> Would you make it more readable?
0x84 is the register offset, and the high word of '0x007F007F' is the out
threshold and the low word is the in threshold. I will use some micros to make
it more readable to avoid magic number in PATCH v2.
> > +void usb_set_qrk_bulk_thresh(struct pci_dev *pdev) {
> > + void __iomem *base, *op_reg_base;
> > + u8 cap_length;
> > + u32 val;
> > +
> > + if (!mmio_resource_enabled(pdev, 0))
> > + return;
> > +
> > + base = pci_ioremap_bar(pdev, 0);
> > + if (base == NULL)
> > + return;
> > +
> > + cap_length = readb(base);
> > + op_reg_base = base + cap_length;
> > +
> > + val = readl(op_reg_base + EHCI_INSNREG01);
> > + dev_printk(KERN_INFO, >dev, "INSNREG01 is 0x%08x\n", val);
> > +
> > + val = EHCI_INSNREG01_THRESH;
> > +
> > + writel(val, op_reg_base + EHCI_INSNREG01);
> > +
> > + val = readl(op_reg_base + EHCI_INSNREG01);
> > + dev_printk(KERN_INFO, >dev, "INSNREG01 is 0x%08x\n", val);
>
> As Alan Stern said, These INFO message are noisy.
> DEBUG level looks better.
These messages are not necessary, I will remove them.
> Best regards,
> Jingoo Han
>
> > +
> > --
> > 1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] zram: revalidate disk after capacity change
Alexander reported mkswap on /dev/zram0 is failed if other process
is opening the block device file.
Step is as follows,
0. Reset the unused zram device.
1. Use a program that opens /dev/zram0 with O_RDWR and sleeps
until killed.
2. While that program sleeps, echo the correct value to
/sys/block/zram0/disksize.
3. Verify (e.g. in /proc/partitions) that the disk size is applied
correctly. It is.
4. While that program still sleeps, attempt to mkswap /dev/zram0.
This fails: mkswap: error: swap area needs to be at least 40 KiB
When I investigated, the size get by ioctl(fd, BLKGETSIZE64, xxx)
on mkswap to get a size of blockdev was zero although zram0 has
right size by 2.
The reason is zram didn't revalidate disk after changing capacity
so that size of blockdev's inode is not uptodate until all of file
is close.
This patch should fix the BUG.
Cc: sta...@vger.kernel.org
Reported-and-Tested-by: Alexander E. Patrakov
Signed-off-by: Minchan Kim
---
drivers/block/zram/zram_drv.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 48eccb3..089e72c 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -622,8 +622,10 @@ static void zram_reset_device(struct zram *zram, bool
reset_capacity)
memset(>stats, 0, sizeof(zram->stats));
zram->disksize = 0;
- if (reset_capacity)
+ if (reset_capacity) {
set_capacity(zram->disk, 0);
+ revalidate_disk(zram->disk);
+ }
up_write(>init_lock);
}
@@ -664,6 +666,7 @@ static ssize_t disksize_store(struct device *dev,
zram->comp = comp;
zram->disksize = disksize;
set_capacity(zram->disk, zram->disksize >> SECTOR_SHIFT);
+ revalidate_disk(zram->disk);
up_write(>init_lock);
return len;
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] driver core: platform: add device binding path 'driver_override'
On Mon, 2 Jun 2014 21:28:42 -0700 Greg KH wrote: > On Mon, Jun 02, 2014 at 07:42:58PM -0500, Kim Phillips wrote: > > You are the platform driver core maintainer: can you apply this to > > your driver-core tree now? > > Yes, I will after this merge window ends, it's too late for 3.16-rc1 > with the window opening up a week early, sorry. How about now? fwiw, I just checked: it still applies cleanly. Thanks, Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] mm/mempolicy: fix sleeping function called from invalid context
On 06/25/2014 09:43 PM, Tejun Heo wrote: > On Wed, Jun 25, 2014 at 09:57:18AM +0800, Gu Zheng wrote: >> When runing with the kernel(3.15-rc7+), the follow bug occurs: >> [ 9969.258987] BUG: sleeping function called from invalid context at >> kernel/locking/mutex.c:586 >> [ 9969.359906] in_atomic(): 1, irqs_disabled(): 0, pid: 160655, name: python >> [ 9969.441175] INFO: lockdep is turned off. >> [ 9969.488184] CPU: 26 PID: 160655 Comm: python Tainted: G A >> 3.15.0-rc7+ #85 >> [ 9969.581032] Hardware name: FUJITSU-SV PRIMEQUEST 1800E/SB, BIOS >> PRIMEQUEST 1000 Series BIOS Version 1.39 11/16/2012 >> [ 9969.706052] 81a20e60 8803e941fbd0 8162f523 >> 8803e941fd18 >> [ 9969.795323] 8803e941fbe0 8109995a 8803e941fc58 >> 81633e6c >> [ 9969.884710] 811ba5dc 880405c6b480 88041fdd90a0 >> 2000 >> [ 9969.974071] Call Trace: >> [ 9970.003403] [] dump_stack+0x4d/0x66 >> [ 9970.065074] [] __might_sleep+0xfa/0x130 >> [ 9970.130743] [] mutex_lock_nested+0x3c/0x4f0 >> [ 9970.200638] [] ? kmem_cache_alloc+0x1bc/0x210 >> [ 9970.272610] [] cpuset_mems_allowed+0x27/0x140 >> [ 9970.344584] [] ? __mpol_dup+0x63/0x150 >> [ 9970.409282] [] __mpol_dup+0xe5/0x150 >> [ 9970.471897] [] ? __mpol_dup+0x63/0x150 >> [ 9970.536585] [] ? copy_process.part.23+0x606/0x1d40 >> [ 9970.613763] [] ? trace_hardirqs_on+0xd/0x10 >> [ 9970.683660] [] ? monotonic_to_bootbased+0x2f/0x50 >> [ 9970.759795] [] copy_process.part.23+0x670/0x1d40 >> [ 9970.834885] [] do_fork+0xd8/0x380 >> [ 9970.894375] [] ? __audit_syscall_entry+0x9c/0xf0 >> [ 9970.969470] [] SyS_clone+0x16/0x20 >> [ 9971.030011] [] stub_clone+0x69/0x90 >> [ 9971.091573] [] ? system_call_fastpath+0x16/0x1b >> >> The cause is that cpuset_mems_allowed() try to take >> mutex_lock(_mutex) >> under the rcu_read_lock(which was hold in __mpol_dup()). And in >> cpuset_mems_allowed(), >> the access to cpuset is under rcu_read_lock, so in __mpol_dup, we can reduce >> the >> rcu_read_lock protection region to protect the access to cpuset only in >> current_cpuset_is_being_rebound(). So that we can avoid this bug. >> This patch is a temporary solution that just addresses the bug mentioned >> above, >> can not fix the long-standing issue about cpuset.mems rebinding on fork(): >> " >> When the forker's task_struct is duplicated (which includes ->mems_allowed) >> and it races with an update to cpuset_being_rebound in >> update_tasks_nodemask() >> then the task's mems_allowed doesn't get updated. And the child task's >> mems_allowed can be wrong if the cpuset's nodemask changes before the >> child has been added to the cgroup's tasklist. >> " >> >> Signed-off-by: Gu Zheng >> Cc: stable > > Applied to cgroup/for-3.16-fixes w/ minor updates to patch subject and > description. Please format the text to 80 columns. The error > messages are fine but it's usually nicer to remove the timestamps. Got it, and thanks for your reminder and suggestion. Best regards, Gu > > Thanks. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2 v2] ARM: KVM: user_mem_abort: support stage 2 MMIO page mapping
From: Kim Phillips
A userspace process can map device MMIO memory via VFIO or /dev/mem,
e.g., for platform device passthrough support in QEMU.
During early development, we found the PAGE_S2 memory type being used
for MMIO mappings. This patch corrects that by using the more strongly
ordered memory type for device MMIO mappings: PAGE_S2_DEVICE.
Signed-off-by: Kim Phillips
Acked-by: Christoffer Dall
---
Hi, here's a v2, upon request:
- rebased onto today's mainline ToT
- mmu.o-build tested only (ToT build doesn't complete)
- made commit text less terse
- added Christoffer's ack
Cheers,
Kim
arch/arm/kvm/mmu.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 16f8049..69af021 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -748,6 +748,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
phys_addr_t fault_ipa,
struct kvm_mmu_memory_cache *memcache = >arch.mmu_page_cache;
struct vm_area_struct *vma;
pfn_t pfn;
+ pgprot_t mem_type = PAGE_S2;
write_fault = kvm_is_write_fault(kvm_vcpu_get_hsr(vcpu));
if (fault_status == FSC_PERM && !write_fault) {
@@ -798,6 +799,9 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
phys_addr_t fault_ipa,
if (is_error_pfn(pfn))
return -EFAULT;
+ if (kvm_is_mmio_pfn(pfn))
+ mem_type = PAGE_S2_DEVICE;
+
spin_lock(>mmu_lock);
if (mmu_notifier_retry(kvm, mmu_seq))
goto out_unlock;
@@ -805,7 +809,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
phys_addr_t fault_ipa,
hugetlb = transparent_hugepage_adjust(, _ipa);
if (hugetlb) {
- pmd_t new_pmd = pfn_pmd(pfn, PAGE_S2);
+ pmd_t new_pmd = pfn_pmd(pfn, mem_type);
new_pmd = pmd_mkhuge(new_pmd);
if (writable) {
kvm_set_s2pmd_writable(_pmd);
@@ -814,13 +818,14 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
phys_addr_t fault_ipa,
coherent_cache_guest_page(vcpu, hva & PMD_MASK, PMD_SIZE);
ret = stage2_set_pmd_huge(kvm, memcache, fault_ipa, _pmd);
} else {
- pte_t new_pte = pfn_pte(pfn, PAGE_S2);
+ pte_t new_pte = pfn_pte(pfn, mem_type);
if (writable) {
kvm_set_s2pte_writable(_pte);
kvm_set_pfn_dirty(pfn);
}
coherent_cache_guest_page(vcpu, hva, PAGE_SIZE);
- ret = stage2_set_pte(kvm, memcache, fault_ipa, _pte, false);
+ ret = stage2_set_pte(kvm, memcache, fault_ipa, _pte,
+mem_type == PAGE_S2_DEVICE);
}
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sysctl: Add a feature to drop caches selectively
On Wed, Jun 25, 2014 at 10:25:05AM +0200, Thomas Knauth wrote: > On Wed, Jun 25, 2014 at 8:25 AM, Artem Bityutskiy wrote: > > Plus some explanations WRT why proc-based interface and what would be > > the alternatives, what if tomorrow we want to extend the functionality > > and drop caches only for certain file range, is this only for regular > > files or also for directories, why posix_fadvice(DONTNEED) is not > > sufficient. > > I suggested the idea originally. Let me address each of your questions in > turn: > > Why a selective drop? To have a middle ground between echo 2 > > drop_caches and echo 3 > drop_caches. When is this interesting? My > particular use case was benchmarking. I wanted to repeatedly measure > the timing when things were read from disk. Dropping everything from > the cache, also drops useful things, not just the few files your > benchmark intends to measure. We're not likely to ever extend the drop_caches functionality. This is brought up semi-regularly by people that have some slightly narrower use-case for dropping caches. Your particular use case can be handled by directing your benchmark at a filesystem mount point and unmounting the filesystem in between benchmark runs. There is no ned to adding kernel functionality for somethign that can be so easily acheived by other means, especially in benchmark environments where *everything* is tightly controlled. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 2/2] irqchip: gic: preserve gic V2 bypass bits in cpu ctrl register
On Wed, 25 Jun 2014, Feng Kan wrote: > This change is made to preserve the GIC v2 bypass bits in the > GIC_CPU_CTRL register (also known as the GICC_CTLR register in spec). > This code will preserve all bits configured by the bootloader regarding > v2 bypass group bits. In the X-Gene platform, the bypass functionality > is not used and bypass bits should not be changed by the kernel gic > code as it could lead to incorrect behavior. > > Signed-off-by: Vinayak Kale > Signed-off-by: Feng Kan Who wrote the patch? According to the SOB chain it's Vinayak, but your patch is missing the: From: Vinayak Kale before the actual changelog starts. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -next] enic: Make dummy rfs functions inline to fix !CONFIG_RFS_ACCEL build
From: Geert Uytterhoeven
Date: Wed, 25 Jun 2014 10:31:09 +0200
> If CONFIG_RFS_ACCEL=n:
>
> drivers/net/ethernet/cisco/enic/enic_main.c: In function 'enic_open':
> drivers/net/ethernet/cisco/enic/enic_main.c:1603:2: error: implicit
> declaration of function 'enic_rfs_flw_tbl_init'
> [-Werror=implicit-function-declaration]
> drivers/net/ethernet/cisco/enic/enic_main.c: In function 'enic_stop':
> drivers/net/ethernet/cisco/enic/enic_main.c:1630:2: error: implicit
> declaration of function 'enic_rfs_flw_tbl_free'
> [-Werror=implicit-function-declaration]
>
> Introduced in commit a145df23ef32c7b933875f334ba28791ee75766e ("enic: Add
> Accelerated RFS support").
>
> Dummy functions are provided, but their prototypes are missing, causing the
> build failure. Provide dummy static inline functions instead to fix this.
>
> Signed-off-by: Geert Uytterhoeven
Applied, thanks Geert.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] sched: Fix compiler warnings
Hi Guenter,
[I know I'm a bit late to this, but ...]
On Tue, 24 Jun 2014 18:05:29 -0700 Guenter Roeck wrote:
>
> diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
> index 9d85318..e35d880 100644
> --- a/arch/arm/kernel/topology.c
> +++ b/arch/arm/kernel/topology.c
> @@ -275,7 +275,7 @@ void store_cpu_topology(unsigned int cpuid)
> cpu_topology[cpuid].socket_id, mpidr);
> }
>
> -static inline const int cpu_corepower_flags(void)
> +static inline int cpu_corepower_flags(void)
> {
> return SD_SHARE_PKG_RESOURCES | SD_SHARE_POWERDOMAIN;
> }
The only reference to this function is to take its address, so "inline"
is useless, right?
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 306f4f0..0376b05 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -872,21 +872,21 @@ enum cpu_idle_type {
> #define SD_NUMA 0x4000 /* cross-node balancing */
>
> #ifdef CONFIG_SCHED_SMT
> -static inline const int cpu_smt_flags(void)
> +static inline int cpu_smt_flags(void)
> {
> return SD_SHARE_CPUCAPACITY | SD_SHARE_PKG_RESOURCES;
> }
> #endif
>
> #ifdef CONFIG_SCHED_MC
> -static inline const int cpu_core_flags(void)
> +static inline int cpu_core_flags(void)
> {
> return SD_SHARE_PKG_RESOURCES;
> }
> #endif
>
> #ifdef CONFIG_NUMA
> -static inline const int cpu_numa_flags(void)
> +static inline int cpu_numa_flags(void)
> {
> return SD_NUMA;
> }
The same is true of those three, but then they would have to be moved
into a .c file and replaced with prototypes ...
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
[PATCH] video: hyperv: hyperv_fb: refresh the VM screen by force on VM panic
Currently the VSC has no chance to notify the VSP of the dirty rectangle on VM
panic because the notification work is done in a workqueue, and in panic() the
kernel typically ends up in an infinite loop, and a typical kernel config has
CONFIG_PREEMPT_VOLUNTARY=y and CONFIG_PREEMPT is not set, so a context switch
can't happen in panic() and the workqueue won't have a chance to run. As a
result, the VM Connection window can't refresh until it's closed and we
re-connect to the VM.
We can register a handler on panic_notifier_list: the handler can notify
the VSC and switch the framebuffer driver to a "synchronous mode", meaning
the VSC flushes any future framebuffer change to the VSP immediately.
MS-TFS: 157532
Signed-off-by: Dexuan Cui
Reviewed-by: Haiyang Zhang
---
drivers/video/fbdev/hyperv_fb.c | 58 ++---
1 file changed, 55 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index e23392e..291d171 100644
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev/hyperv_fb.c
@@ -226,11 +226,16 @@ struct hvfb_par {
u8 recv_buf[MAX_VMBUS_PKT_SIZE];
};
+static struct fb_info *hvfb_info;
+
static uint screen_width = HVFB_WIDTH;
static uint screen_height = HVFB_HEIGHT;
static uint screen_depth;
static uint screen_fb_size;
+/* If true, the VSC notifies the VSP on every framebuffer change */
+static bool synchronous_fb;
+
/* Send message to Hyper-V host */
static inline int synthvid_send(struct hv_device *hdev,
struct synthvid_msg *msg)
@@ -532,6 +537,20 @@ static void hvfb_update_work(struct work_struct *w)
schedule_delayed_work(>dwork, HVFB_UPDATE_DELAY);
}
+static int hvfb_on_panic(struct notifier_block *nb,
+ unsigned long e, void *p)
+{
+ if (hvfb_info)
+ synthvid_update(hvfb_info);
+
+ synchronous_fb = true;
+
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block hvfb_panic_nb = {
+ .notifier_call = hvfb_on_panic,
+};
/* Framebuffer operation handlers */
@@ -582,14 +601,41 @@ static int hvfb_blank(int blank, struct fb_info *info)
return 1; /* get fb_blank to set the colormap to all black */
}
+static void hvfb_cfb_fillrect(struct fb_info *p,
+ const struct fb_fillrect *rect)
+{
+ cfb_fillrect(p, rect);
+
+ if (unlikely(synchronous_fb))
+ synthvid_update(p);
+}
+
+static void hvfb_cfb_copyarea(struct fb_info *p,
+ const struct fb_copyarea *area)
+{
+ cfb_copyarea(p, area);
+
+ if (unlikely(synchronous_fb))
+ synthvid_update(p);
+}
+
+static void hvfb_cfb_imageblit(struct fb_info *p,
+ const struct fb_image *image)
+{
+ cfb_imageblit(p, image);
+
+ if (unlikely(synchronous_fb))
+ synthvid_update(p);
+}
+
static struct fb_ops hvfb_ops = {
.owner = THIS_MODULE,
.fb_check_var = hvfb_check_var,
.fb_set_par = hvfb_set_par,
.fb_setcolreg = hvfb_setcolreg,
- .fb_fillrect = cfb_fillrect,
- .fb_copyarea = cfb_copyarea,
- .fb_imageblit = cfb_imageblit,
+ .fb_fillrect = hvfb_cfb_fillrect,
+ .fb_copyarea = hvfb_cfb_copyarea,
+ .fb_imageblit = hvfb_cfb_imageblit,
.fb_blank = hvfb_blank,
};
@@ -801,6 +847,9 @@ static int hvfb_probe(struct hv_device *hdev,
par->fb_ready = true;
+ hvfb_info = info;
+ atomic_notifier_chain_register(_notifier_list, _panic_nb);
+
return 0;
error:
@@ -820,6 +869,9 @@ static int hvfb_remove(struct hv_device *hdev)
struct fb_info *info = hv_get_drvdata(hdev);
struct hvfb_par *par = info->par;
+ atomic_notifier_chain_unregister(_notifier_list, _panic_nb);
+ hvfb_info = NULL;
+
par->update = false;
par->fb_ready = false;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH_v4 0/2] arm64: Add seccomp support
On 06/25/2014 11:53 PM, Mark Salter wrote: What is the current status of this patch series? Is it on track for 3.17? I assume not as I saw no comments on this so far. But I will re-post a new version soon or later due to recent changes on seccomp. -Takahiro AKASHI On Sat, 2014-03-15 at 14:50 +0900, AKASHI Takahiro wrote: (Please apply this patch after my ftrace patch and audit patch in order to avoid some conflict on arm64/Kconfig.) This patch enables secure computing (system call filtering) on arm64. System calls can be allowed or denied by loaded bpf-style rules. Architecture specific part is to run secure_computing() on syscall entry and check the result. See [2/2] Prerequisites are: * "arm64: make a single hook to syscall_trace() for all syscall features" patch * "arm64: split syscall_trace() into separate functions for enter/exit" patch * "arm64: Add audit support" patch * "arm64: is_compat_task is defined both in asm/compat.h and linux/compat.h" patch This code is tested on ARMv8 fast model using libseccomp v2.1.1 with modifications for arm64 and verified by its "live" tests, 20, 21 and 24. Changes v3 -> v4: * removed the following patch and moved it to "arm64: prerequisites for audit and ftrace" patchset since it is required for audit and ftrace in case of !COMPAT, too. "arm64: is_compat_task is defined both in asm/compat.h and linux/compat.h" Changes v2 -> v3: * removed unnecessary 'type cast' operations [2/3] * check for a return value (-1) of secure_computing() explicitly [2/3] * aligned with the patch, "arm64: split syscall_trace() into separate functions for enter/exit" [2/3] * changed default of CONFIG_SECCOMP to n [2/3] Changes v1 -> v2: * added generic seccomp.h for arm64 to utilize it [1,2/3] * changed syscall_trace() to return more meaningful value (-EPERM) on seccomp failure case [2/3] * aligned with the change in "arm64: make a single hook to syscall_trace() for all syscall features" v2 [2/3] * removed is_compat_task() definition from compat.h [3/3] AKASHI Takahiro (2): asm-generic: Add generic seccomp.h for secure computing mode 1 arm64: Add seccomp support arch/arm64/Kconfig | 14 ++ arch/arm64/include/asm/seccomp.h | 25 + arch/arm64/include/asm/unistd.h | 3 +++ arch/arm64/kernel/entry.S| 4 arch/arm64/kernel/ptrace.c | 6 ++ include/asm-generic/seccomp.h| 28 6 files changed, 80 insertions(+) create mode 100644 arch/arm64/include/asm/seccomp.h create mode 100644 include/asm-generic/seccomp.h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Should Pstore(ramoops) records customized information?
On 2014/6/25 21:08, Liu hua wrote:
于 2014/6/25 8:41, Zhang, Yanmin 写道:
On 2014/6/20 18:47, Liu hua wrote:
On 2014/6/20 7:42, Luck, Tony wrote:
BTW, I note that "extern struct pstore_info *psinfo" locates in
fs/pstore/internal.h. So users out of directory "fs/pstore/" can not use pstore
to
record messages. We do not want other kernel users to use pstore, right? And
can we
break this?
Yes we can make some interface visible to the rest of the kernel ... probably
not the raw "*psinfo" though. Perhaps the pstore_alloc_ring_buffer() and
pstore_write_ring_buffer() functions should be the ones exported to the
rest of the kernel.
ditoo.. Since other backends like efi and erst may can not privide such ring
buffer.
So pstore_alloc_ring_buffer should be a funciton pointer of pstore_info struct.
Yes - that allows less capable backend like ERST and efivars to not provide the
service. Since it becomes internal, you can drop the "pstore_" prefix. E.g.
something like:
int pstore_alloc_ring_buffer(char *name, int size)
{
return psinfo->alloc_ring_buffer(name, size);
}
EXPORT_SYMBOL_GPL(pstore_alloc_ring_buffer);
... and you have to find/make some global header for the "extern" declaration.
I will make these RFC patch series according to our discussion. Thanks you very
to
valuable advice.
Sorry for seeing your email late.We already worked out some patches to
restructure
pstore. Would you like to try patchset
http://article.gmane.org/gmane.linux.kernel/1697680/?
We have more patches available to add some flags to disable/enable specific
zones.
That's great! I have tried your patches. BTW, Your patches do not work on ARM
platform,
before I changed linker scripts;
Initially, we just implemented it on x86. It's easy to extend it to ARM. Mostly
change the arm
vmlinux.lds.S to add the sections. Pls. also change setup_arch to allocate
memory blocks for
pstore.
In the patchset, there is an example patch, including reserve memory and zone
examples.
Pls. reference it.
And can we use this method in modules(I failed to do that)?
It's a good question. There are many approaches to support modules.
1) Define the zone in built-in files and export it.Then, you can use it in
module.
2) Define the zone and new tracer functions in built-in files and export
the tracer functions.
After a quick glance and try, I think my idea is a little different from yours.
I will reply you
later.
Pls. Share your opinions. We are improving pstore to make it easier to be used.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next] pktgen: Fill the payload optionally with a pattern
From: Zoltan Kiss Date: Tue, 24 Jun 2014 21:40:15 +0100 > Introduces a new flag called PATTERN, which puts a non-periodic, predicatble > pattern into the payload. This was useful to reproduce an otherwise > intermittent > bug in xen-netback [1], where checksum checking doesn't help. > The pattern is a repetition of " %lu", a series of increasing numbers divided > by > space. The value of the number is the size of the preceding payload area. E.g. > " 1 3 5"..." 1000 1005 1010" > If the pattern is used, every frag will have its own page, unlike before, so > it > needs more memory. > > [1] 5837574: xen-netback: Fix grant ref resolution in RX path > > Signed-off-by: Zoltan Kiss You are changing the page allocation strategy regardless of the pattern setting, this is undesirable. It may be significantly faster to use the same page for all the frags, and this is absolutely critical for pktgen usage where every nanosecond of performance counts. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [trivial PATCH net-next] mac_pton: Use bool not int return
From: Joe Perches Date: Tue, 24 Jun 2014 11:20:48 -0700 > Use bool instead of int as the return type. > > All uses are tested with !. > > Signed-off-by: Joe Perches Applied, thanks Joe. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next 3/3 RFC] pktgen: Allow sending TCP packets
From: Cong Wang Date: Wed, 25 Jun 2014 17:41:47 -0700 > On Wed, Jun 25, 2014 at 1:42 PM, Zoltan Kiss wrote: >> This is a prototype patch to enable sending TCP packets with pktgen. The >> original motivation is to test TCP GSO with xen-netback/netfront, but I'm not >> sure about how the checksum should be set up, and also someone should verify >> the >> GSO settings I'm using. >> > > What's the point of sending TCP packets since you don't establish a TCP > connection? I guess they want to test checksumming and aggregation, things like that. The other side is of course going to spew reset packets back at the pktgen machine. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kthread: Fix the race condition when kthread is parked
On Wed, 25 Jun 2014, Subbaraman Narayanamurthy wrote:
> While stressing the CPU hotplug path, sometimes we hit a problem
> as shown below.
>
> [57056.416774] [ cut here ]
> [57056.489232] ksoftirqd/1 (14): undefined instruction: pc=c01931e8
> [57056.489245] Code: e594a000 eb085236 e15a 0a00 (e7f001f2)
> [57056.489259] [ cut here ]
> [57056.492840] kernel BUG at kernel/kernel/smpboot.c:134!
> [57056.513236] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
> [57056.519055] Modules linked in: wlan(O) mhi(O)
> [57056.523394] CPU: 0 PID: 14 Comm: ksoftirqd/1 Tainted: GW O
> 3.10.0-g3677c61-8-g180c060 #1
> [57056.532595] task: f0c8b000 ti: f0e78000 task.ti: f0e78000
> [57056.537991] PC is at smpboot_thread_fn+0x124/0x218
> [57056.542750] LR is at smpboot_thread_fn+0x11c/0x218
> [57056.547528] pc : []lr : [] psr: 200f0013
> [57056.547528] sp : f0e79f30 ip : fp :
> [57056.558983] r10: 0001 r9 : r8 : f0e78000
> [57056.564192] r7 : 0001 r6 : c1195758 r5 : f0e78000 r4 : f0e5fd00
> [57056.570701] r3 : 0001 r2 : f0e79f20 r1 : r0 :
>
> This issue was always seen in the context of "ksoftirqd". It seems to
> be happening because of a potential race condition in __kthread_parkme
> where just after completing the parked completion, before the
> ksoftirqd task has been scheduled again, it can go into running state.
This explanation does not make any sense. You completely fail to
explain the details of the race. And your patch does not make any
sense either, because the real issue is this:
Task CPU 0CPU 1
T1 unplug cpu1
kthread_park(T2)
set_bit(KTHREAD_SHOULD_PARK);
wait_for_completion()
T2 parkme(X)
__set_current_state(TASK_PARKED);
while (test_bit(KTHREAD_SHOULD_PARK))
{
if
(!test_and_set_bit(KTHREAD_IS_PARKED))
complete();
schedule();
T1 plug cpu1
--> premature wakeup of T2, i.e. before unpark, so T2 gets scheduled on
CPU 0
T2__set_current_state(TASK_PARKED);
--> Preemption by the plug thread
T1 thread_unpark(T2)
clear_bit(KTHREAD_SHOULD_PARK);
--> Preemption by the softirq thread which breaks out of the
while(test_bit(KTHREAD_SHOULD_PARK)) loop because
KTHREAD_SHOULD_PARK is not longer set.
T2 }
clear_bit(KTHREAD_IS_PARKED);
--> Now T2 happily continues to run on CPU0 which rightfully casues
the BUG to trigger.
T1
__kthread_bind(T2)
--> Too late
So the real issue is that the park/unpark code is not able to handle
the premature wakeup of T2 and that needs to be fixed.
Your changelog says:
> It seems to be happening because of a potential race condition in
Potential is wrong to begin with. A race condition is either real and
explainable or it does not exist.
> __kthread_parkme where just after completing the parked completion,
> before the ksoftirqd task has been scheduled again, it can go into
> running state.
What exactly has this to do with state RUNNING or PARKED?
Nothing, the task state is completely irrelevant as the real issue
is the task->*PARK flags state.
So what is your patch solving here ?
You put a wait for task->state == TASK_PARKED after the
wait_for_completion. What does it solve? Actually nothing. It just
changes the propability of that issue. Go and apply it between any
step of the above and figure out what it solves. Nothing, really.
Now just as an extra thought experiment assume that you have only
two cpus and T1 is a SCHED_FIFO task and T2 is SCHED_OTHER
Please do not misunderstand me, but "fixing" races without proper
understanding them is plain wrong. Providing a vague changelog which
does neither explain what the issue is and why the fix works is even
more wrong.
The next time you hit something like this, please take the time and
sit down, get out the old fashioned piece of paper and a pencil and
draw the picture so you can actually understand what the root cause of
the observed issue is before sending out halfarsed duct tape fixes
which just paper over the root cause. If you cannot figure it out,
send a proper bug report.
Thanks,
tglx
-->
Subject: kthread: Plug park/ unplug race
From: Thomas Gleixner
Date: Thu, 26 Jun 2014 01:24:36 +0200
The kthread park/unpark logic has the following issue:
Task CPU 0CPU 1
T1 unplug cpu1
kthread_park(T2)
set_bit(KTHREAD_SHOULD_PARK);
wait_for_completion()
T2 parkme(X)
__set_current_state(TASK_PARKED);
while
Re: [PATCH net-next 3/3 RFC] pktgen: Allow sending TCP packets
On Wed, Jun 25, 2014 at 1:42 PM, Zoltan Kiss wrote: > This is a prototype patch to enable sending TCP packets with pktgen. The > original motivation is to test TCP GSO with xen-netback/netfront, but I'm not > sure about how the checksum should be set up, and also someone should verify > the > GSO settings I'm using. > What's the point of sending TCP packets since you don't establish a TCP connection? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] adfs: Add __printf verification, fix format/argument mismatches
Might as well do the right thing.
Signed-off-by: Joe Perches
---
fs/adfs/adfs.h | 1 +
fs/adfs/dir.c | 2 +-
fs/adfs/dir_fplus.c | 5 ++---
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/adfs/adfs.h b/fs/adfs/adfs.h
index c770337..24575d9 100644
--- a/fs/adfs/adfs.h
+++ b/fs/adfs/adfs.h
@@ -153,6 +153,7 @@ extern int adfs_map_lookup(struct super_block *sb, unsigned
int frag_id, unsigne
extern unsigned int adfs_map_free(struct super_block *sb);
/* Misc */
+__printf(3, 4)
void __adfs_error(struct super_block *sb, const char *function,
const char *fmt, ...);
#define adfs_error(sb, fmt...) __adfs_error(sb, __func__, fmt)
diff --git a/fs/adfs/dir.c b/fs/adfs/dir.c
index 0d138c0..51c279a 100644
--- a/fs/adfs/dir.c
+++ b/fs/adfs/dir.c
@@ -138,7 +138,7 @@ adfs_dir_lookup_byname(struct inode *inode, struct qstr
*name, struct object_inf
goto out;
if (ADFS_I(inode)->parent_id != dir.parent_id) {
- adfs_error(sb, "parent directory changed under me! (%lx but got
%lx)\n",
+ adfs_error(sb, "parent directory changed under me! (%lx but got
%x)\n",
ADFS_I(inode)->parent_id, dir.parent_id);
ret = -EIO;
goto free_out;
diff --git a/fs/adfs/dir_fplus.c b/fs/adfs/dir_fplus.c
index 7673c1f..ee255c0 100644
--- a/fs/adfs/dir_fplus.c
+++ b/fs/adfs/dir_fplus.c
@@ -79,9 +79,8 @@ adfs_fplus_read(struct super_block *sb, unsigned int id,
unsigned int sz, struct
dir->bh_fplus[blk] = sb_bread(sb, block);
if (!dir->bh_fplus[blk]) {
- adfs_error(sb, "dir object %X failed read for"
- " offset %d, mapped block %X",
- id, blk, block);
+ adfs_error(sb, "dir object %x failed read for offset
%d, mapped block %lX",
+ id, blk, block);
goto out;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] rch/score/include/uapi/asm/ptrace.h: Add prefix 'SCORE_' for related macros
On Thu, Jun 26, 2014 at 12:05:33AM +, Wu Yu-Chen wrote: > As I said, these macros are useless currently. I don’t think users will use > these macros since the kernel doesn’t respond these macros. However, you are > welcome to provide your idea > Just drop them entirely. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] scsi: bnx2i: bnx2i_iscsi.c: Cleaning up variable is set more than once
2014-06-25 19:13 GMT+02:00 Eddie Wai : > On Wed, 2014-06-25 at 16:26 +0200, Maurizio Lombardi wrote: >> Hi, >> >> On 06/25/2014 04:04 PM, Rickard Strandqvist wrote: >> > A struct member variable is set to different values without having used in >> > between. >> > >> > This was found using a static code analysis program called cppcheck >> > >> > Signed-off-by: Rickard Strandqvist >> > --- >> > drivers/scsi/bnx2i/bnx2i_iscsi.c |1 - >> > 1 file changed, 1 deletion(-) >> > >> > diff --git a/drivers/scsi/bnx2i/bnx2i_iscsi.c >> > b/drivers/scsi/bnx2i/bnx2i_iscsi.c >> > index 166543f..fdf7bc3 100644 >> > --- a/drivers/scsi/bnx2i/bnx2i_iscsi.c >> > +++ b/drivers/scsi/bnx2i/bnx2i_iscsi.c >> > @@ -1643,7 +1643,6 @@ static void bnx2i_conn_get_stats(struct >> > iscsi_cls_conn *cls_conn, >> > stats->r2t_pdus = conn->r2t_pdus_cnt; >> > stats->tmfcmd_pdus = conn->tmfcmd_pdus_cnt; >> > stats->tmfrsp_pdus = conn->tmfrsp_pdus_cnt; >> > - stats->custom_length = 3; >> > strcpy(stats->custom[2].desc, "eh_abort_cnt"); >> > stats->custom[2].value = conn->eh_abort_cnt; >> > stats->digest_err = 0; >> > >> >> Eddie, >> >> The code modifies the content of stats->custom[2], so shouldn't >> custom_length be set to 3? >> Why is it set to zero at the end of this function? > Nice find. This is literally a day1 bug. Yes, I agree that the > custom_length should be left at 3. Otherwise, the nlmsg replied back to > the application would not have the custom message. Thanks. >> >> Regards, >> Maurizio Lombardi > > Hi, and thank you! If it's not obvious, I do all my fixes without changing the previous intent. But obviously it is not always right, rather it is one of main reasons to fix this type of error :) But I'll make a new patch then, with = 3 ? Kind regards Rickard Strandqvist -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 8/9] ARM: kernel: add support for cpu cache information
On 06/25/14 10:30, Sudeep Holla wrote:
> +
> +/*
> + * Which cache CCSIDR represents depends on CSSELR value
> + * Make sure no one else changes CSSELR during this
> + * smp_call_function_single prevents preemption for us
> + */
Where's the smp_call_function_single() or preemption disable happening?
> +static inline u32 get_ccsidr(u32 csselr)
> +{
> + u32 ccsidr;
> +
> + /* Put value into CSSELR */
> + asm volatile ("mcr p15, 2, %0, c0, c0, 0" : : "r" (csselr));
> + isb();
> + /* Read result out of CCSIDR */
> + asm volatile ("mrc p15, 1, %0, c0, c0, 0" : "=r" (ccsidr));
> +
> + return ccsidr;
> +}
> +
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: export NR_SHMEM via sysinfo(2) / si_meminfo() interfaces
> I agree that reporting the amount of shared pages in that historically fashion > might not be interesting for userspace tools resorting to sysinfo(2), > nowadays. > > OTOH, our documentation implies we do return shared memory there, and FWIW, > considering the other places we do export the "shared memory" concept to > userspace nowadays, we are suggesting it's the amount of tmpfs/shmem, and not > the > amount of shared mapped pages it historiacally represented once. What is > really > confusing is having a field that supposedely/expectedely would return the > amount > of shmem to userspace queries, but instead returns a hard-coded zero (0). > > I could easily find out that there were some user complaint/confusion on this > semantic inconsistency in the past, as in: > https://groups.google.com/forum/#!topic/comp.os.linux.development.system/ogWVn6XdvGA > > or in: > http://marc.info/?l=net-snmp-cvs=132148788500667 > > which suggests users seem to always have understood it as being shmem/tmpfs > usage, as the /proc/meminfo field "MemShared" was tied direclty to > sysinfo.sharedram. Historically we reported shared memory that way, and > when it wasn't accurately meaning that anymore a 0 was hardcoded there to > potentially not break compatibility with older tools (older than 2.4). > In 2.6 we got rid of meminfo's "MemShared" until 2009, when you sort of > re-introduced it re-branded as Shmem. IMO, we should leverage what we > have in kernel now and take this change to make the exposed data consistent > across the interfaces that export it today -- sysinfo(2) & /proc/meminfo. > > This is not a hard requirement, though, but rather a simple maintenance > nitpick from code review. Ok, ack then. But please update a patch description and repost w/ ccing linux-...@vger.kernel.org. Someone might have a specific concern about a compatibility. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] staging: wlan-ng/hfa384x_usb.c: remove return statements for void function
On Wed, 2014-06-25 at 23:35 +0800, Cheng-Wei Lee wrote:
> This patch fixes the following checkpatch.pl issues in hfa384x_usb.c:
> WARNING: Missing a blank line after declarations
Still has a mismatch between subject and code
> diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c
[]
> @@ -3533,7 +3533,7 @@ static void hfa384x_usbin_rx(wlandevice_t
> *wlandev, struct sk_buff *skb)
> }
>
> done:
> - return;
> + pr_debug("hfa384x_usbin_rx: done\n");
I suggest you just leave the return,
Any checkpatch suggestion this was needed was a false
positive that should be resolved by this patch:
http://article.gmane.org/gmane.linux.kernel/1728891
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT 0/3] cxgb4: use request_firmware_nowait()
On Wed, Jun 25, 2014 at 2:51 PM, Luis R. Rodriguez wrote: > I'll go ahead and test this on the other > distribution you mentioned you had issues, curious what could trigger a > timeout > failure there that would be distribution specific. I've tested this on SLE12 and see no issues as well. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 6/9] usb: xhci: Add NVIDIA Tegra XHCI host-controller driver
On Wed, Jun 25, 2014 at 3:37 PM, Stephen Warren wrote:
> On 06/18/2014 12:16 AM, Andrew Bresticker wrote:
>> Add support for the on-chip XHCI host controller present on Tegra SoCs.
>>
>> The driver is currently very basic: it loads the controller with its
>> firmware, starts the controller, and is able to service messages sent
>> by the controller's firmware. The hardware supports device mode as
>> well as runtime power-gating, but support for these is not yet
>> implemented here.
>>
>> Based on work by:
>> Ajay Gupta
>> Bharath Yadav
>
>> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
>
>> +config USB_XHCI_TEGRA
>> + tristate "NVIDIA Tegra XHCI support"
>> + depends on ARCH_TEGRA
>> + select PINCTRL_TEGRA_XUSB
>> + select TEGRA_XUSB_MBOX
>> + select FW_LOADER
>
> I think at least some of those should be depends. In particular, the
> mbox driver patch said:
>
> +config TEGRA_XUSB_MBOX
> + bool "NVIDIA Tegra XUSB mailbox support"
>
> which means the option is user-selectable. Either MBOX should be
> invisible and selected here, or it should be visible with USB_XHCI_TEGRA
> depending on it.
Annoyingly, TEGRA_XUSB_MBOX isn't selectable unless MAILBOX is
selected, so I think I will make USB_XHCI_TEGRA depend on
TEGRA_XUSB_MBOX.
>> diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c
>
>> +#define TEGRA_XHCI_UTMI_PHYS 3
>> +#define TEGRA_XHCI_HSIC_PHYS 2
>> +#define TEGRA_XHCI_USB3_PHYS 2
>> +#define TEGRA_XHCI_MAX_PHYS (TEGRA_XHCI_UTMI_PHYS + TEGRA_XHCI_HSIC_PHYS + \
>> + TEGRA_XHCI_USB3_PHYS)
>
> Do those numbers need to be synchronized with the XUSB padctrl driver at
> all?
Oops, yeah, these probably belong in a header somewhere.
>> +static u32 csb_readl(struct tegra_xhci_hcd *tegra, u32 addr)
>> +{
>> + u32 page, offset;
>> +
>> + page = CSB_PAGE_SELECT(addr);
>> + offset = CSB_PAGE_OFFSET(addr);
>> + fpci_writel(tegra, page, XUSB_CFG_ARU_C11_CSBRANGE);
>> + return fpci_readl(tegra, XUSB_CFG_CSB_BASE_ADDR + offset);
>> +}
>
> I assume some higher level has the required locking or single-threading
> so that the keyhole register accesses don't get interleaved?
Yes, we only touch these in the firmware loading path which is single-threaded.
>> +static void tegra_xhci_cfg(struct tegra_xhci_hcd *tegra)
>> +{
>> + u32 reg;
>> +
>> + reg = ipfs_readl(tegra, IPFS_XUSB_HOST_CONFIGURATION_0);
>> + reg |= IPFS_EN_FPCI;
>> + ipfs_writel(tegra, reg, IPFS_XUSB_HOST_CONFIGURATION_0);
>> + udelay(10);
>> +
>> + /* Program Bar0 Space */
>> + reg = fpci_readl(tegra, XUSB_CFG_4);
>> + reg |= tegra->hcd->rsrc_start;
>
> Don't you need to mask out the original value here? I guess whatever is
> being written is probably always the same, but it seems scary to assume
> that a bootloader, or previous version of a module during development,
> didn't write something unexpected there. Perhaps if the HW module's
> reset is pulsed we don't need to worry though.
Hmm, so I left this part mostly identical to what the downstream
kernels do, but the more I look at it the more it looks wrong. The
TRM says that BASE_ADDRESS is XUSB_CFG_4[31:15] and the rest are flags
(which we avoid over-writing because the base address is 64K aligned),
but we just slam the physical address of the host in there. I'll get
some clarification on what exactly needs to be programmed into this
register.
>> +static int tegra_xhci_load_firmware(struct tegra_xhci_hcd *tegra)
>> +{
>> + struct device *dev = tegra->dev;
>> + struct tegra_xhci_fw_cfgtbl *cfg_tbl;
>> + u64 fw_base;
>> + u32 val;
>> + time_t fw_time;
>> + struct tm fw_tm;
>> +
>> + if (csb_readl(tegra, XUSB_CSB_MP_ILOAD_BASE_LO) != 0) {
>> + dev_info(dev, "Firmware already loaded, Falcon state 0x%x\n",
>> + csb_readl(tegra, XUSB_FALC_CPUCTL));
>> + return 0;
>> + }
>> +
>> + cfg_tbl = (struct tegra_xhci_fw_cfgtbl *)tegra->fw_data;
>
> Are there endianness or CPU word size (e.g. ARMv8) issues here; this is
> casting the content of a data file to a CPU data structure.
I don't think there are word-size issues, but I suppose there could be
endianness issues.
>> +static int tegra_xhci_set_ss_clk(struct tegra_xhci_hcd *tegra,
>> + unsigned long rate)
>
>> + switch (rate) {
>> + case TEGRA_XHCI_SS_CLK_HIGH_SPEED:
>> + /* Reparent to PLLU_480M. Set div first to avoid overclocking
>> */
>> + old_parent_rate = clk_get_rate(clk_get_parent(clk));
>> + new_parent_rate = clk_get_rate(tegra->pll_u_480m);
>> + div = new_parent_rate / rate;
>> + ret = clk_set_rate(clk, old_parent_rate / div);
>> + if (ret)
>> + return ret;
>> + ret = clk_set_parent(clk, tegra->pll_u_480m);
>> + if (ret)
>> + return ret;
>
> Don't
Re: [PATCH] scripts/checkpatch.pl: Only emit LONG_LINE for --strict
On Wed, 2014-06-25 at 08:46 -0700, Josh Triplett wrote: > Regardless of the long-standing debate over line width, checkpatch > should not warn about it by default. I'm not getting involved here. I don't care much one way or another. I did submit a patch where I ignored 80 columns recently and I was told to try again by the maintainer. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] Prepare for in-kernel VFIO DMA operations acceleration
On 06/26/2014 07:12 AM, Alexander Graf wrote: > > On 06.06.14 02:20, Alexey Kardashevskiy wrote: >> On 06/05/2014 09:57 PM, Alexander Graf wrote: >>> On 05.06.14 09:25, Alexey Kardashevskiy wrote: This reserves 2 capability numbers. This implements an extended version of KVM_CREATE_SPAPR_TCE_64 ioctl. Please advise how to proceed with these patches as I suspect that first two should go via Paolo's tree while the last one via Alex Graf's tree (correct?). >>> They would just go via my tree, but only be actually allocated (read: >>> mergable to qemu) when they hit Paolo's tree. >>> >>> In fact, I don't think it makes sense to split them off at all. >> >> So? Are these patches going anywhere? Thanks. > > So? Are you going to address the comments? Sorry, I cannot find here anything to fix. Ben asked some questions, I answered and there were no objections. What do I miss this time?... -- Alexey -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2] pcnet32: Neaten and remove unnecessary OOM messages
Make the code flow a little better for 80 columns.
Use a consistent style for the RX and TX rings allocation.
Use BIT macro.
Use a temporary unsigned int entries for (1<
Acked-by: Don Fry
---
V2: Use pcnet32 as patch prefix, amd is too generic
Still depends on patch 1/22: pci-dma-compat: Add pci_zalloc_consistent helper
drivers/net/ethernet/amd/pcnet32.c | 43 --
1 file changed, 18 insertions(+), 25 deletions(-)
diff --git a/drivers/net/ethernet/amd/pcnet32.c
b/drivers/net/ethernet/amd/pcnet32.c
index 8099fdc..4a8fdc4 100644
--- a/drivers/net/ethernet/amd/pcnet32.c
+++ b/drivers/net/ethernet/amd/pcnet32.c
@@ -481,36 +481,32 @@ static void pcnet32_realloc_tx_ring(struct net_device
*dev,
dma_addr_t *new_dma_addr_list;
struct pcnet32_tx_head *new_tx_ring;
struct sk_buff **new_skb_list;
+ unsigned int entries = BIT(size);
pcnet32_purge_tx_ring(dev);
- new_tx_ring = pci_zalloc_consistent(lp->pci_dev,
- sizeof(struct pcnet32_tx_head) *
- (1 << size),
- _ring_dma_addr);
- if (new_tx_ring == NULL) {
- netif_err(lp, drv, dev, "Consistent memory allocation
failed\n");
+ new_tx_ring =
+ pci_zalloc_consistent(lp->pci_dev,
+ sizeof(struct pcnet32_tx_head) * entries,
+ _ring_dma_addr);
+ if (new_tx_ring == NULL)
return;
- }
- new_dma_addr_list = kcalloc(1 << size, sizeof(dma_addr_t),
- GFP_ATOMIC);
+ new_dma_addr_list = kcalloc(entries, sizeof(dma_addr_t), GFP_ATOMIC);
if (!new_dma_addr_list)
goto free_new_tx_ring;
- new_skb_list = kcalloc(1 << size, sizeof(struct sk_buff *),
- GFP_ATOMIC);
+ new_skb_list = kcalloc(entries, sizeof(struct sk_buff *), GFP_ATOMIC);
if (!new_skb_list)
goto free_new_lists;
kfree(lp->tx_skbuff);
kfree(lp->tx_dma_addr);
pci_free_consistent(lp->pci_dev,
- sizeof(struct pcnet32_tx_head) *
- lp->tx_ring_size, lp->tx_ring,
- lp->tx_ring_dma_addr);
+ sizeof(struct pcnet32_tx_head) * lp->tx_ring_size,
+ lp->tx_ring, lp->tx_ring_dma_addr);
- lp->tx_ring_size = (1 << size);
+ lp->tx_ring_size = entries;
lp->tx_mod_mask = lp->tx_ring_size - 1;
lp->tx_len_bits = (size << 12);
lp->tx_ring = new_tx_ring;
@@ -523,8 +519,7 @@ free_new_lists:
kfree(new_dma_addr_list);
free_new_tx_ring:
pci_free_consistent(lp->pci_dev,
- sizeof(struct pcnet32_tx_head) *
- (1 << size),
+ sizeof(struct pcnet32_tx_head) * entries,
new_tx_ring,
new_ring_dma_addr);
}
@@ -548,16 +543,14 @@ static void pcnet32_realloc_rx_ring(struct net_device
*dev,
struct pcnet32_rx_head *new_rx_ring;
struct sk_buff **new_skb_list;
int new, overlap;
- unsigned int entries = 1 << size;
+ unsigned int entries = BIT(size);
- new_rx_ring = pci_zalloc_consistent(lp->pci_dev,
- sizeof(struct pcnet32_rx_head) *
- entries,
- _ring_dma_addr);
- if (new_rx_ring == NULL) {
- netif_err(lp, drv, dev, "Consistent memory allocation
failed\n");
+ new_rx_ring =
+ pci_zalloc_consistent(lp->pci_dev,
+ sizeof(struct pcnet32_rx_head) * entries,
+ _ring_dma_addr);
+ if (new_rx_ring == NULL)
return;
- }
new_dma_addr_list = kcalloc(entries, sizeof(dma_addr_t), GFP_ATOMIC);
if (!new_dma_addr_list)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 08/22] pcnet32: Use pci_zalloc_consistent
Remove the now unnecessary memset too.
Signed-off-by: Joe Perches
Acked-by: Don Fry
---
On Mon, 2014-06-23 at 12:15 -0700, Joe Perches wrote:
> On Mon, 2014-06-23 at 11:02 -0700, Don Fry wrote:
> > This causes the line length to be greater than 80 characters causing
> > checkpatch to complain.
V3: Use better patch prefix pcnet32, amd is too generic
V2: Don Fry is an 80 column neatnik.
Please remember this depends on patch 1/22 being applied
before this patch can be successfully applied.
drivers/net/ethernet/amd/pcnet32.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/amd/pcnet32.c
b/drivers/net/ethernet/amd/pcnet32.c
index e7cc917..8099fdc 100644
--- a/drivers/net/ethernet/amd/pcnet32.c
+++ b/drivers/net/ethernet/amd/pcnet32.c
@@ -484,15 +484,14 @@ static void pcnet32_realloc_tx_ring(struct net_device
*dev,
pcnet32_purge_tx_ring(dev);
- new_tx_ring = pci_alloc_consistent(lp->pci_dev,
- sizeof(struct pcnet32_tx_head) *
- (1 << size),
- _ring_dma_addr);
+ new_tx_ring = pci_zalloc_consistent(lp->pci_dev,
+ sizeof(struct pcnet32_tx_head) *
+ (1 << size),
+ _ring_dma_addr);
if (new_tx_ring == NULL) {
netif_err(lp, drv, dev, "Consistent memory allocation
failed\n");
return;
}
- memset(new_tx_ring, 0, sizeof(struct pcnet32_tx_head) * (1 << size));
new_dma_addr_list = kcalloc(1 << size, sizeof(dma_addr_t),
GFP_ATOMIC);
@@ -551,15 +550,14 @@ static void pcnet32_realloc_rx_ring(struct net_device
*dev,
int new, overlap;
unsigned int entries = 1 << size;
- new_rx_ring = pci_alloc_consistent(lp->pci_dev,
- sizeof(struct pcnet32_rx_head) *
- entries,
- _ring_dma_addr);
+ new_rx_ring = pci_zalloc_consistent(lp->pci_dev,
+ sizeof(struct pcnet32_rx_head) *
+ entries,
+ _ring_dma_addr);
if (new_rx_ring == NULL) {
netif_err(lp, drv, dev, "Consistent memory allocation
failed\n");
return;
}
- memset(new_rx_ring, 0, sizeof(struct pcnet32_rx_head) * entries);
new_dma_addr_list = kcalloc(entries, sizeof(dma_addr_t), GFP_ATOMIC);
if (!new_dma_addr_list)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
mmotm 2014-06-25-16-44 uploaded
The mm-of-the-moment snapshot 2014-06-25-16-44 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You will need quilt to apply these patches to the latest Linus release (3.x or 3.x-rcY). The series file is in broken-out.tar.gz and is duplicated in http://ozlabs.org/~akpm/mmotm/series The file broken-out.tar.gz contains two datestamp files: .DATE and .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, followed by the base kernel version against which this patch series is to be applied. This tree is partially included in linux-next. To see which patches are included in linux-next, consult the `series' file. Only the patches within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in linux-next. A git tree which contains the memory management portion of this tree is maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git by Michal Hocko. It contains the patches which are between the "#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series file, http://www.ozlabs.org/~akpm/mmotm/series. A full copy of the full kernel tree with the linux-next and mmotm patches already applied is available through git within an hour of the mmotm release. Individual mmotm releases are tagged. The master branch always points to the latest release, so it's constantly rebasing. http://git.cmpxchg.org/?p=linux-mmotm.git;a=summary To develop on top of mmotm git: $ git remote add mmotm git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git $ git remote update mmotm $ git checkout -b topic mmotm/master $ git send-email mmotm/master.. [...] To rebase a branch with older patches to a new mmotm release: $ git remote update mmotm $ git rebase --onto mmotm/master topic The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second) contains daily snapshots of the -mm tree. It is updated more frequently than mmotm, and is untested. A git copy of this tree is available at http://git.cmpxchg.org/?p=linux-mmots.git;a=summary and use of this tree is similar to http://git.cmpxchg.org/?p=linux-mmotm.git, described above. This mmotm tree contains the following patches against 3.16-rc2: (patches marked "*" will be included in linux-next) origin.patch i-need-old-gcc.patch arch-alpha-kernel-systblss-remove-debug-check.patch maintainers-akpm-maintenance.patch checkpatch-check-git-commit-descriptions.patch * mm-page_alloc-fix-cma-area-initialisation-when-pageblock-max_order.patch * slub-fix-off-by-one-in-number-of-slab-tests.patch * autofs4-fix-false-positive-compile-error.patch * tools-cpu-hotplug-fix-unexpected-operator-error.patch * tools-memory-hotplug-fix-unexpected-operator-error.patch * proc-stat-convert-to-single_open_size.patch * fs-seq_file-fallback-to-vmalloc-allocation.patch * x86mem-hotplug-pass-sync_global_pgds-a-correct-argument-in-remove_pagetable.patch * x86mem-hotplug-modify-pgd-entry-when-removing-memory.patch * kernel-auditfilterc-replace-countsize-kmalloc-by-kcalloc.patch * fs-cifs-remove-obsolete-__constant.patch * fs-cifs-filec-replace-countsize-kzalloc-by-kcalloc.patch * fs-cifs-smb2filec-replace-countsize-kzalloc-by-kcalloc.patch * kernel-posix-timersc-code-clean-up.patch * kernel-posix-timersc-code-clean-up-checkpatch-fixes.patch * input-route-kbd-leds-through-the-generic-leds-layer.patch * input-route-kbd-leds-through-the-generic-leds-layer-fix.patch * remove-cpu_subtype_sh7764.patch * fs-squashfs-file_directc-replace-countsize-kmalloc-by-kmalloc_array.patch * fs-squashfs-superc-logging-clean-up.patch * drivers-net-irda-donauboe-convert-to-module_pci_driver.patch * fs-ext4-fsyncc-generic_file_fsync-call-based-on-barrier-flag.patch * ocfs2-correctly-check-the-return-value-of-ocfs2_search_extent_list.patch * ocfs2-remove-convertion-of-total_backoff-in-dlm_join_domain.patch * ocfs2-do-not-write-error-flag-to-user-structure-we-cannot-copy-from-to.patch * ocfs2-free-inode-when-i_count-becomes-zero.patch * ocfs2-free-inode-when-i_count-becomes-zero-checkpatch-fixes.patch * ocfs2-o2net-dont-shutdown-connection-when-idle-timeout.patch * ocfs2-o2net-set-tcp-user-timeout-to-max-value.patch * ocfs2-quorum-add-a-log-for-node-not-fenced.patch * ocfs2-call-ocfs2_journal_access_di-before-ocfs2_journal_dirty-in-ocfs2_write_end_nolock.patch * fs-ocfs2-slot_mapc-replace-countsize-kzalloc-by-kcalloc.patch * maintainers-update-ibm-serveraid-raid-info.patch * bio-modify-__bio_add_page-to-accept-pages-that-dont-start-a-new-segment.patch * block-restore-proc-partitions-to-not-display-non-partitionable-removable-devices.patch * kernel-watchdogc-convert-printk-pr_warning-to-pr_foo.patch mm.patch * mm-slabc-add-__init-to-init_lock_keys.patch * slab-common-add-functions-for-kmem_cache_node-access.patch *
[PATCH V2] checkpatch: Add test for blank lines after function/struct/union/enum declarations
Add a --strict test asking for a blank line after
function/struct/union/enum declarations.
Allow exceptions for several attributes and macro uses.
Signed-off-by: Joe Perches
---
V2: Fix a problem with patch context lines by checking
the line after the closing brace is an insertion.
scripts/checkpatch.pl | 16
1 file changed, 16 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 538105a..d56ad2a 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2291,6 +2291,22 @@ sub process {
"networking block comments put the trailing */ on
a separate line\n" . $herecurr);
}
+# check for missing blank lines after struct/union declarations
+# with exceptions for various attributes and macros
+ if ($prevline =~ /^[\+ ]};?\s*$/ &&
+ $line =~ /^\+/ &&
+ !($line =~ /^\+\s*$/ ||
+ $line =~ /^\+\s*EXPORT_SYMBOL/ ||
+ $line =~ /^\+\s*MODULE_/i ||
+ $line =~ /^\+\s*\#\s*(?:end|elif|else)/ ||
+ $line =~ /^\+[a-z_]*init/ ||
+ $line =~ /^\+\s*(?:static\s+)?[A-Z_]*ATTR/ ||
+ $line =~ /^\+\s*DECLARE/ ||
+ $line =~ /^\+\s*__setup/)) {
+ CHK("LINE_SPACING",
+ "Please use a blank line after
function/struct/union/enum declarations\n" . $hereprev);
+ }
+
# check for missing blank lines after declarations
if ($sline =~ /^\+\s+\S/ && #Not at char 1
# actual declarations
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] mm: page_alloc: Reduce cost of dirty zone balancing
On Wed, 25 Jun 2014 08:58:48 +0100 Mel Gorman wrote:
> @@ -325,7 +321,14 @@ static unsigned long zone_dirty_limit(struct zone *zone)
> */
> bool zone_dirty_ok(struct zone *zone)
> {
> - unsigned long limit = zone_dirty_limit(zone);
> + unsigned long limit = zone->dirty_limit_cached;
> + struct task_struct *tsk = current;
> +
> + if (tsk->flags & PF_LESS_THROTTLE || rt_task(tsk)) {
> + limit = zone_dirty_limit(zone);
> + zone->dirty_limit_cached = limit;
> + limit += limit / 4;
> + }
Could we get a comment in here explaining what we're doing and why
PF_LESS_THROTTLE and rt_task control whether we do it?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] amd: Neaten and remove unnecessary OOM messages
From: Joe Perches Date: Mon, 23 Jun 2014 14:36:35 -0700 > Make the code flow a little better for 80 columns. > > Use a consistent style for the RX and TX rings allocation. > Use BIT macro. > Use a temporary unsiged int entries for (1< Remove the OOM messages as they duplicate the generic > OOM and dump_stack() provided by the memory subsystem. > Reflow allocs to 80 columns. > > Signed-off-by: Joe Perches Please repost with adjusted subject prefix (amd --> pcnet32), thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/6] mm: vmscan: Do not reclaim from lower zones if they are balanced
On Wed, 25 Jun 2014 08:58:46 +0100 Mel Gorman wrote: > Historically kswapd scanned from DMA->Movable in the opposite direction > to the page allocator to avoid allocating behind kswapd direction of > progress. The fair zone allocation policy altered this in a non-obvious > manner. > > Traditionally, the page allocator prefers to use the highest eligible zone > until the watermark is depleted, woke kswapd and moved onto the next zone. > kswapd scans zones in the opposite direction so the scanning lists on > 64-bit look like this; > > ... > > Note that this patch makes a large performance difference for lower > numbers of threads and brings performance closer to 3.0 figures. It was > also tested against xfs and there are similar gains although I don't have > 3.0 figures to compare against. There are still regressions for higher > number of threads but this is related to changes in the CFQ IO scheduler. > Why did this patch make a difference to sequential read performance? IOW, by what means was/is reclaim interfering with sequential reads? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: allwinner: emac: Add missing free_irq
From: Maxime Ripard Date: Mon, 23 Jun 2014 22:49:40 +0200 > If the mdio probe function fails in emac_open, the interrupt we just requested > isn't freed. If emac_open is called again, for example because we try to set > up > the interface again, the kernel will oops because the interrupt wasn't > properly > released. > > Signed-off-by: Maxime Ripard > Cc: # 3.11+ Applied, thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 4/9] pinctrl: tegra-xusb: Add USB PHY support
On Wed, Jun 25, 2014 at 3:12 PM, Stephen Warren wrote:
> On 06/18/2014 12:16 AM, Andrew Bresticker wrote:
>> In addition to the PCIe and SATA PHYs, the XUSB pad controller also
>> supports 3 UTMI, 2 HSIC, and 2 USB3 PHYs. Each USB3 PHY uses a single
>> PCIe or SATA lane and is mapped to one of the three UTMI ports.
>>
>
>> diff --git a/drivers/pinctrl/pinctrl-tegra-xusb.c
>> b/drivers/pinctrl/pinctrl-tegra-xusb.c
>
>> @@ -372,6 +720,193 @@ static int tegra_xusb_padctl_pinconf_group_set(struct
>> pinctrl_dev *pinctrl,
>> padctl_writel(padctl, regval, lane->offset);
>> break;
>>
>> + case TEGRA_XUSB_PADCTL_USB3_PORT_NUM:
>> + if (value >= TEGRA_XUSB_PADCTL_USB3_PORTS) {
>> + dev_err(padctl->dev, "Invalid USB3 port:
>> %lu\n",
>> + value);
>> + return -EINVAL;
>> + }
>> + if (!is_pcie_sata_lane(group)) {
>> + dev_err(padctl->dev,
>> + "USB3 port not applicable for pin
>> %d\n",
>> + group);
>> + return -EINVAL;
>> + }
>> + padctl->usb3_ports[value].lane = group;
>> + break;
>
> It feels odd to use pinctrl for a SW-only purpose. In other words, that
> chunk of code isn't writing the pinconf data to HW, but rather some
> internal variable.
Well the mapping of lanes to USB3 ports is a hardware property and we
do use it when programming the hardware later to choose which set of
lane registers to program given a USB3 port, but it's true that it's
not some value we program into HW directly.
> Perhaps it would make more sense for the DT binding to represent this
> data directly in a custom property that's parsed at probe() time. That
> way, pinctrl only touches "real" HW stuff.
I'm on the fence about this. If you or others feel strongly about
this then I can make it a separate DT property and move it out of the
pinctrl properties.
>> +static int usb3_phy_power_on(struct phy *phy)
>> +{
>> + struct tegra_xusb_padctl *padctl = phy_get_drvdata(phy);
>> + int port = usb3_phy_to_port(phy);
>> + int lane = padctl->usb3_ports[port].lane;
>> + u32 value, offset;
>> +
>> + value = padctl_readl(padctl, XUSB_PADCTL_IOPHY_USB3_PADX_CTL2(port));
>> + value &= ~((XUSB_PADCTL_IOPHY_USB3_PAD_CTL2_RX_WANDER_MASK <<
>> + XUSB_PADCTL_IOPHY_USB3_PAD_CTL2_RX_WANDER_SHIFT) |
>> +(XUSB_PADCTL_IOPHY_USB3_PAD_CTL2_RX_EQ_MASK <<
>> + XUSB_PADCTL_IOPHY_USB3_PAD_CTL2_RX_EQ_SHIFT) |
>> +(XUSB_PADCTL_IOPHY_USB3_PAD_CTL2_CDR_CNTL_MASK <<
>> + XUSB_PADCTL_IOPHY_USB3_PAD_CTL2_CDR_CNTL_SHIFT));
>
> Hmm. So there is a lot of "PHY" stuff here after all.
>
> However, the PHYs implemented here appear to implement very low-level
> I/O pad code, whereas the PHYs we have for our USB 2.0 controller are
> somewhat higher-level; they're more USB-oriented than just IO pad
> oriented. Do you know which level of abstraction a Linux PHY object is
> supposed to be? I could never get an answer when I asked before.
The only other PHY driver I've worked with (Exynos USB2/3 PHYs) also
mainly only did low-level pad control stuff, but looking at a couple
of other USB PHYs (MSM, MV), there appear to be others that have
higher-level USB stuff in the PHY driver. Perhaps Kishon or Felipe
could offer us some guidance?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
