[PATCH Resend 2/2] Mohit Kumar has moved
From: Pratyush Anand Mohit's email-id doesn't exist anymore as he has left the company. Replace ST's id with mohit.kumar.dh...@gmail.com. Cc: Mohit Kumar Signed-off-by: Pratyush Anand --- .mailmap | 1 + drivers/pci/host/pcie-spear13xx.c | 2 +- drivers/phy/phy-spear1310-miphy.c | 2 +- drivers/phy/phy-spear1340-miphy.c | 2 +- 4 files changed, 4 insertions(+), 3 deletions(-) diff --git a/.mailmap b/.mailmap index 145eaa9f7d71..bcc72d093eca 100644 --- a/.mailmap +++ b/.mailmap @@ -84,6 +84,7 @@ Mayuresh Janorkar Michael Buesch Michel Dänzer Mitesh shah +Mohit Kumar Morten Welinder Morten Welinder Morten Welinder diff --git a/drivers/pci/host/pcie-spear13xx.c b/drivers/pci/host/pcie-spear13xx.c index f086cdd23aff..fb0b3e9b7e0a 100644 --- a/drivers/pci/host/pcie-spear13xx.c +++ b/drivers/pci/host/pcie-spear13xx.c @@ -5,7 +5,7 @@ * * Copyright (C) 2010-2014 ST Microelectronics * Pratyush Anand - * Mohit Kumar + * Mohit Kumar * * This file is licensed under the terms of the GNU General Public * License version 2. This program is licensed "as is" without any diff --git a/drivers/phy/phy-spear1310-miphy.c b/drivers/phy/phy-spear1310-miphy.c index 85d3e11e6769..45d0005b2203 100644 --- a/drivers/phy/phy-spear1310-miphy.c +++ b/drivers/phy/phy-spear1310-miphy.c @@ -3,7 +3,7 @@ * * Copyright (C) 2014 ST Microelectronics * Pratyush Anand - * Mohit Kumar + * Mohit Kumar * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as diff --git a/drivers/phy/phy-spear1340-miphy.c b/drivers/phy/phy-spear1340-miphy.c index 2f98ebaa6ba9..494240da4a39 100644 --- a/drivers/phy/phy-spear1340-miphy.c +++ b/drivers/phy/phy-spear1340-miphy.c @@ -3,7 +3,7 @@ * * Copyright (C) 2014 ST Microelectronics * Pratyush Anand - * Mohit Kumar + * Mohit Kumar * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH Resend 1/2] Pratyush Anand has moved
From: Pratyush Anand pratyush.an...@st.com email-id doesn't exist anymore as I have left the company. Replace ST's id with pratyush.an...@gmail.com. Signed-off-by: Pratyush Anand --- .mailmap | 1 + Documentation/ABI/testing/configfs-spear-pcie-gadget | 2 +- Documentation/ABI/testing/sysfs-bus-usb-lvstest | 12 ++-- Documentation/misc-devices/spear-pcie-gadget.txt | 2 +- drivers/misc/spear13xx_pcie_gadget.c | 2 +- drivers/pci/host/pcie-spear13xx.c| 4 ++-- drivers/phy/phy-spear1310-miphy.c| 4 ++-- drivers/phy/phy-spear1340-miphy.c| 4 ++-- drivers/usb/misc/lvstest.c | 2 +- 9 files changed, 17 insertions(+), 16 deletions(-) diff --git a/.mailmap b/.mailmap index 6287004040e7..145eaa9f7d71 100644 --- a/.mailmap +++ b/.mailmap @@ -95,6 +95,7 @@ Patrick Mochel Peter A Jonsson Peter Oruba Peter Oruba +Pratyush Anand Praveen BP Rajesh Shah Ralf Baechle diff --git a/Documentation/ABI/testing/configfs-spear-pcie-gadget b/Documentation/ABI/testing/configfs-spear-pcie-gadget index 875988146a63..840c324ef34d 100644 --- a/Documentation/ABI/testing/configfs-spear-pcie-gadget +++ b/Documentation/ABI/testing/configfs-spear-pcie-gadget @@ -1,7 +1,7 @@ What: /config/pcie-gadget Date: Feb 2011 KernelVersion: 2.6.37 -Contact: Pratyush Anand +Contact: Pratyush Anand Description: Interface is used to configure selected dual mode PCIe controller diff --git a/Documentation/ABI/testing/sysfs-bus-usb-lvstest b/Documentation/ABI/testing/sysfs-bus-usb-lvstest index aae68fc2d842..5151290cf8e7 100644 --- a/Documentation/ABI/testing/sysfs-bus-usb-lvstest +++ b/Documentation/ABI/testing/sysfs-bus-usb-lvstest @@ -4,14 +4,14 @@ driver is bound with root hub device. What: /sys/bus/usb/devices/.../get_dev_desc Date: March 2014 -Contact: Pratyush Anand +Contact: Pratyush Anand Description: Write to this node to issue "Get Device Descriptor" for Link Layer Validation device. It is needed for TD.7.06. What: /sys/bus/usb/devices/.../u1_timeout Date: March 2014 -Contact: Pratyush Anand +Contact: Pratyush Anand Description: Set "U1 timeout" for the downstream port where Link Layer Validation device is connected. Timeout value must be between 0 @@ -19,7 +19,7 @@ Description: What: /sys/bus/usb/devices/.../u2_timeout Date: March 2014 -Contact: Pratyush Anand +Contact: Pratyush Anand Description: Set "U2 timeout" for the downstream port where Link Layer Validation device is connected. Timeout value must be between 0 @@ -27,21 +27,21 @@ Description: What: /sys/bus/usb/devices/.../hot_reset Date: March 2014 -Contact: Pratyush Anand +Contact: Pratyush Anand Description: Write to this node to issue "Reset" for Link Layer Validation device. It is needed for TD.7.29, TD.7.31, TD.7.34 and TD.7.35. What: /sys/bus/usb/devices/.../u3_entry Date: March 2014 -Contact: Pratyush Anand +Contact: Pratyush Anand Description: Write to this node to issue "U3 entry" for Link Layer Validation device. It is needed for TD.7.35 and TD.7.36. What: /sys/bus/usb/devices/.../u3_exit Date: March 2014 -Contact: Pratyush Anand +Contact: Pratyush Anand Description: Write to this node to issue "U3 exit" for Link Layer Validation device. It is needed for TD.7.36. diff --git a/Documentation/misc-devices/spear-pcie-gadget.txt b/Documentation/misc-devices/spear-pcie-gadget.txt index 02c13ef5e908..89b88dee4143 100644 --- a/Documentation/misc-devices/spear-pcie-gadget.txt +++ b/Documentation/misc-devices/spear-pcie-gadget.txt @@ -2,7 +2,7 @@ Spear PCIe Gadget Driver: Author = -Pratyush Anand (pratyush.an...@st.com) +Pratyush Anand (pratyush.an...@gmail.com) Location diff --git a/drivers/misc/spear13xx_pcie_gadget.c b/drivers/misc/spear13xx_pcie_gadget.c index fe3ad0ca9a3e..b8374cdaf9c9 100644 --- a/drivers/misc/spear13xx_pcie_gadget.c +++ b/drivers/misc/spear13xx_pcie_gadget.c @@ -2,7 +2,7 @@ * drivers/misc/spear13xx_pcie_gadget.c * * Copyright (C) 2010 ST Microelectronics - * Pratyush Anand + * Pratyush Anand * * This file is licensed under the terms of the GNU General Public * License version 2. This program is licensed "as is" without any diff --git a/drivers/pci/host/pcie-spear13xx.c b/drivers/pci/host/pcie-spear13xx.c index 020d78890719..f086cdd23aff 100644 --- a/drivers/pci/host/pcie-spear13xx.c +++ b/drivers/pci/host/pcie-spear13xx.c @@ -4,7 +4,7 @@ * SPEAr13xx PCIe Glue Layer Source
Re: [PATCH v2 0/8] clk: Minor cleanups
On 04/28, Krzysztof Kozlowski wrote: > Hi, > > > Changes since v1 > > 1. Rebase on next-20150427 and Sascha Hauer's: >clk: make strings in parent name arrays const [1] > 2. Add patch "clk: tegra: Fix inconsistent indenting". > > > Description and dependencies > > Small cleanups for different clock drivers. > > The first three patches are independent. > > Rest of the patches (these related to constifying parent names, > including the change for MIPS) depend on the "clk: make strings in > parent name arrays const" from Sascha Hauer [1]. > > > Tested on Arndale Octa (Exynos5420) and Trats2 (Exynos4412). Other > drivers (and MIPS related) only compile tested plus some static > checkers. > > > [1] http://www.spinics.net/lists/arm-kernel/msg413763.html > > Best regards, > Krzysztof > > Krzysztof Kozlowski (8): > clk: rockchip: Staticize file-scope declarations > clk: exynos: Staticize file-scope declarations > clk: tegra: Fix inconsistent indenting > clk: tegra: Fix duplicate const for parent names > clk: cdce706: Constify parent names in clock init data > clk: sirf: Constify parent names in clock init data > clk: ls1x: Fix duplicate const for parent names > MIPS: Alchemy: Remove unneeded cast removing const Applied 1,2,5,6,7 to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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] extcon: Remove the optional name of extcon device
This patch removes the optional name of extcon device. Instead,
extcon_dev_register() set the device name as 'extcon[number]' naming pattern.
- /sys/class/extcon/[hardcoded device name] -> /sys/class/extcon/extcon[number]
Cc: MyungJoo Ham
Cc: Charles Keepax
Cc: Graeme Gregory
Cc: Kishon Vijay Abraham I
Cc: Krzysztof Kozlowski
Cc: Jaewon Kim
Signed-off-by: Chanwoo Choi
---
This patch has the dependency on patch[1].
[1] https://lkml.org/lkml/2015/4/27/258
- [PATCH 1/4] extcon: Modify the device name as extcon[X] for sysfs
drivers/extcon/extcon-adc-jack.c | 1 -
drivers/extcon/extcon-gpio.c | 1 -
drivers/extcon/extcon-max14577.c | 2 --
drivers/extcon/extcon-max77693.c | 1 -
drivers/extcon/extcon-max8997.c | 1 -
drivers/extcon/extcon-palmas.c | 1 -
drivers/extcon/extcon-rt8973a.c | 1 -
drivers/extcon/extcon-sm5502.c | 1 -
8 files changed, 9 deletions(-)
diff --git a/drivers/extcon/extcon-adc-jack.c b/drivers/extcon/extcon-adc-jack.c
index 768eaed..5bf08ec 100644
--- a/drivers/extcon/extcon-adc-jack.c
+++ b/drivers/extcon/extcon-adc-jack.c
@@ -110,7 +110,6 @@ static int adc_jack_probe(struct platform_device *pdev)
dev_err(>dev, "failed to allocate extcon device\n");
return -ENOMEM;
}
- data->edev->name = pdata->name;
if (!pdata->adc_conditions ||
!pdata->adc_conditions[0].state) {
diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
index 7af33fc..355459a 100644
--- a/drivers/extcon/extcon-gpio.c
+++ b/drivers/extcon/extcon-gpio.c
@@ -104,7 +104,6 @@ static int gpio_extcon_probe(struct platform_device *pdev)
dev_err(>dev, "failed to allocate extcon device\n");
return -ENOMEM;
}
- extcon_data->edev->name = pdata->name;
extcon_data->gpio = pdata->gpio;
extcon_data->gpio_active_low = pdata->gpio_active_low;
diff --git a/drivers/extcon/extcon-max14577.c b/drivers/extcon/extcon-max14577.c
index 6d5febe..ad8f8dd 100644
--- a/drivers/extcon/extcon-max14577.c
+++ b/drivers/extcon/extcon-max14577.c
@@ -729,8 +729,6 @@ static int max14577_muic_probe(struct platform_device *pdev)
return -ENOMEM;
}
- info->edev->name = dev_name(>dev);
-
ret = devm_extcon_dev_register(>dev, info->edev);
if (ret) {
dev_err(>dev, "failed to register extcon device\n");
diff --git a/drivers/extcon/extcon-max77693.c b/drivers/extcon/extcon-max77693.c
index a4fe7fd..c274249 100644
--- a/drivers/extcon/extcon-max77693.c
+++ b/drivers/extcon/extcon-max77693.c
@@ -1158,7 +1158,6 @@ static int max77693_muic_probe(struct platform_device
*pdev)
dev_err(>dev, "failed to allocate memory for extcon\n");
return -ENOMEM;
}
- info->edev->name = DEV_NAME;
ret = devm_extcon_dev_register(>dev, info->edev);
if (ret) {
diff --git a/drivers/extcon/extcon-max8997.c b/drivers/extcon/extcon-max8997.c
index da269a1..33613c4 100644
--- a/drivers/extcon/extcon-max8997.c
+++ b/drivers/extcon/extcon-max8997.c
@@ -696,7 +696,6 @@ static int max8997_muic_probe(struct platform_device *pdev)
ret = -ENOMEM;
goto err_irq;
}
- info->edev->name = DEV_NAME;
ret = devm_extcon_dev_register(>dev, info->edev);
if (ret) {
diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
index 11c6757..9c8943d 100644
--- a/drivers/extcon/extcon-palmas.c
+++ b/drivers/extcon/extcon-palmas.c
@@ -193,7 +193,6 @@ static int palmas_usb_probe(struct platform_device *pdev)
dev_err(>dev, "failed to allocate extcon device\n");
return -ENOMEM;
}
- palmas_usb->edev->name = kstrdup(node->name, GFP_KERNEL);
palmas_usb->edev->mutually_exclusive = mutually_exclusive;
status = devm_extcon_dev_register(>dev, palmas_usb->edev);
diff --git a/drivers/extcon/extcon-rt8973a.c b/drivers/extcon/extcon-rt8973a.c
index 8c2194f..04447f3 100644
--- a/drivers/extcon/extcon-rt8973a.c
+++ b/drivers/extcon/extcon-rt8973a.c
@@ -631,7 +631,6 @@ static int rt8973a_muic_i2c_probe(struct i2c_client *i2c,
dev_err(info->dev, "failed to allocate memory for extcon\n");
return -ENOMEM;
}
- info->edev->name = np->name;
/* Register extcon device */
ret = devm_extcon_dev_register(info->dev, info->edev);
diff --git a/drivers/extcon/extcon-sm5502.c b/drivers/extcon/extcon-sm5502.c
index 2f93cf3..6f1d11f 100644
--- a/drivers/extcon/extcon-sm5502.c
+++ b/drivers/extcon/extcon-sm5502.c
@@ -623,7 +623,6 @@ static int sm5022_muic_i2c_probe(struct i2c_client *i2c,
dev_err(info->dev, "failed to allocate memory for extcon\n");
return -ENOMEM;
}
- info->edev->name = np->name;
/* Register extcon device */
ret = devm_extcon_dev_register(info->dev, info->edev);
--
Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver
On Tue, May 05, 2015 at 11:23:05PM +0200, Gabriele Mazzotta wrote: > On Thursday 30 April 2015 09:44:29 Pali Rohár wrote: > > On Thursday 30 April 2015 14:06:27 Alex Hung wrote: > > > Method ABRT is to be used by driver to disable BIOS handling of radio > > > button. So the changes in behaviours observed by Gabriele is expected. > > > I have seen other systems behave the same way. > > > > > > > Right, that after that ARBT call operating system get full control over > > radio devices and ACPI/BIOS will not automatically enable/disable them. > > I think this is OK. > > > > But for that we need also support for manually enable/disable radio > > devices and code for this support is missing. Or do DELLABCE/RBTN acpi > > devices somehow support enabling/disabling it via system/kernel request? > > > > > I do also see firmware only sends Notify(RBTN, 0x80) and no hard block > > > whether ABRT(1) is called or not. Thus keycode are the only option on > > > those machines. > > > > > > > Key is ok, but we *must* have ability to hard block it via some > > ACPI/WMI/BIOS/FW/etc... call. Otherwise ARBT(1) is no go as users should > > be able to enable/disable their radio devices (bluetooth for powersave) > > Does it really matter in the end? As I understand it, radio devices are > off either way. As a point of reference for consideration, we recently dropped the Thinkpad hardware mute button because it seriously complicated everything in what appears to be a similar sort of situation. By eliminating the hardware mute and relying purely on software mute, we were able to provide a much more consistently functional driver. Also note that this driver provided a "software_mute" module parameter to allow the user to control this. I believe this provides some relevant precedent for your consideration. I don't want to add parameters casually, but it could be one is warranted here. -- Darren Hart Intel Open Source Technology Center -- 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] clk: s3c2410: Constify platform_device_id
On 05/02, Krzysztof Kozlowski wrote: > The platform_device_id is not modified by the driver and core uses it as > const. > > Signed-off-by: Krzysztof Kozlowski > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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] clk: s3c2410: Staticize local symbols
On 05/02, Krzysztof Kozlowski wrote: > Staticize symbols not exported and not used outside of file. > > Signed-off-by: Krzysztof Kozlowski Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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] percpu_counter: batch size aware __percpu_counter_compare()
On Wed, May 06, 2015 at 03:43:10PM +1000, Dave Chinner wrote: > On Tue, May 05, 2015 at 09:36:36PM -0700, Christoph Hellwig wrote: > > This looks reasonable, but I miss Ccs to the authors of the > > percpu_counter code and linux-kernel. > > linux-kernel was cc'd. > > > On Wed, May 06, 2015 at 08:01:38AM +1000, Dave Chinner wrote: > > > From: Dave Chinner > > > > > > From: Dave Chinner > > > > And this looks wrong, too :) > > That looks like a change of tool behaviour. I just upgraded guilt; > the old version stripped "from" lines in patch descriptions from the > git commit log as goes into the author field of the commit. The new > version does not appear to strip the from lines, and so when > git-send-email formats it, it puts a from line in the message, and > then the commit message has one too. Ok, so I remembered it the wrong way around, but it is a tool bug: $ guilt patchbomb -s d480578..cd83c77 cd83c773 xfs: inode counter needs to use __percpu_counter_compare 1e41b5ad percpu_counter: batch size aware __percpu_counter_compare() Are these what you want to send? [Y/n] Note the use of "-s". from the man page: -s Don't add additional repository committer sign-offs to the patch. This allows the sign-off chain to be fully expressed in the commit messages and not changed by the act of sending a patchbomb. It would appear that the "-s" option is not working properly. I'll fix that before sending the next round of patches 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 v12] clk: Add common clock support for Mediatek MT8135 and MT8173
On 04/23, Sascha Hauer wrote: > The following changes since commit 39a8804455fb23f09157341d3ba7db6d7ae6ee76: > > Linux 4.0 (2015-04-12 15:12:50 -0700) > > are available in the git repository at: > > git://git.pengutronix.de/git/sha/linux-2.6.git tags/v4.0-clk-mediatek-v12 > > for you to fetch changes up to e0ebeaa8a3f4a762cb9c2780170445aad15915d1: > > dt-bindings: ARM: Mediatek: Document devicetree bindings for clock/reset > controllers (2015-04-23 10:22:34 +0200) > > > This patchset contains the initial common clock support for Mediatek SoCs. > Mediatek SoC's clock architecture comprises of various PLLs, dividers, muxes > and clock gates. Applied to clk-next. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/6] dt-bindings: ARM: Mediatek: Document devicetree bindings for clock/reset controllers
On 05/04, Sascha Hauer wrote:
> On Thu, Apr 30, 2015 at 06:20:39PM -0700, Stephen Boyd wrote:
> > On 04/23, Sascha Hauer wrote:
> > > +The available clocks are defined in dt-bindings/clock/mt*-clk.h.
> > > +
> > > +Example:
> > > +
> > > +apmixedsys: apmixedsys@10209000 {
> >
> > apmixedsys: clock-controller@10209000 {
> >
> > would be more standard. The same comment applies throughout this
> > patch. Otherwise it looks good to me.
>
> For apmixed this I agree, but the others are also reset controllers, so
> I'm not sure if clock-controller is appropriate. Personally I don't care
> much, I'll change to whatever you like.
I've already applied the patch, so if you like you can send a
follow up. Perhaps power-controller is more appropriate? I'm not
too worried about it though.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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] clk: add newline character after dumping all clocks
On 05/01, Felipe Balbi wrote: > clk_dump() will dump data about all clocks in JSON > format, but it misses a newline character at the > end of the JSON string. This patch adds that missing > newline character. > > Signed-off-by: Felipe Balbi Applied to clk-next with s/seq_printf/seq_puts/ -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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] Mohit's email-id doesn't exist anymore as he has left the company. Replace ST's id with mohit.kumar.dh...@gmail.com.
From: Pratyush Anand Cc: Mohit Kumar Signed-off-by: Pratyush Anand --- .mailmap | 1 + drivers/pci/host/pcie-spear13xx.c | 2 +- drivers/phy/phy-spear1310-miphy.c | 2 +- drivers/phy/phy-spear1340-miphy.c | 2 +- 4 files changed, 4 insertions(+), 3 deletions(-) diff --git a/.mailmap b/.mailmap index 145eaa9f7d71..bcc72d093eca 100644 --- a/.mailmap +++ b/.mailmap @@ -84,6 +84,7 @@ Mayuresh Janorkar Michael Buesch Michel Dänzer Mitesh shah +Mohit Kumar Morten Welinder Morten Welinder Morten Welinder diff --git a/drivers/pci/host/pcie-spear13xx.c b/drivers/pci/host/pcie-spear13xx.c index f086cdd23aff..fb0b3e9b7e0a 100644 --- a/drivers/pci/host/pcie-spear13xx.c +++ b/drivers/pci/host/pcie-spear13xx.c @@ -5,7 +5,7 @@ * * Copyright (C) 2010-2014 ST Microelectronics * Pratyush Anand - * Mohit Kumar + * Mohit Kumar * * This file is licensed under the terms of the GNU General Public * License version 2. This program is licensed "as is" without any diff --git a/drivers/phy/phy-spear1310-miphy.c b/drivers/phy/phy-spear1310-miphy.c index 85d3e11e6769..45d0005b2203 100644 --- a/drivers/phy/phy-spear1310-miphy.c +++ b/drivers/phy/phy-spear1310-miphy.c @@ -3,7 +3,7 @@ * * Copyright (C) 2014 ST Microelectronics * Pratyush Anand - * Mohit Kumar + * Mohit Kumar * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as diff --git a/drivers/phy/phy-spear1340-miphy.c b/drivers/phy/phy-spear1340-miphy.c index 2f98ebaa6ba9..494240da4a39 100644 --- a/drivers/phy/phy-spear1340-miphy.c +++ b/drivers/phy/phy-spear1340-miphy.c @@ -3,7 +3,7 @@ * * Copyright (C) 2014 ST Microelectronics * Pratyush Anand - * Mohit Kumar + * Mohit Kumar * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] pratyush.an...@st.com email-id doesn't exist anymore as I have left the company. Replace ST's id with pratyush.an...@gmail.com.
From: Pratyush Anand Signed-off-by: Pratyush Anand --- .mailmap | 1 + Documentation/ABI/testing/configfs-spear-pcie-gadget | 2 +- Documentation/ABI/testing/sysfs-bus-usb-lvstest | 12 ++-- Documentation/misc-devices/spear-pcie-gadget.txt | 2 +- drivers/misc/spear13xx_pcie_gadget.c | 2 +- drivers/pci/host/pcie-spear13xx.c| 4 ++-- drivers/phy/phy-spear1310-miphy.c| 4 ++-- drivers/phy/phy-spear1340-miphy.c| 4 ++-- drivers/usb/misc/lvstest.c | 2 +- 9 files changed, 17 insertions(+), 16 deletions(-) diff --git a/.mailmap b/.mailmap index 6287004040e7..145eaa9f7d71 100644 --- a/.mailmap +++ b/.mailmap @@ -95,6 +95,7 @@ Patrick Mochel Peter A Jonsson Peter Oruba Peter Oruba +Pratyush Anand Praveen BP Rajesh Shah Ralf Baechle diff --git a/Documentation/ABI/testing/configfs-spear-pcie-gadget b/Documentation/ABI/testing/configfs-spear-pcie-gadget index 875988146a63..840c324ef34d 100644 --- a/Documentation/ABI/testing/configfs-spear-pcie-gadget +++ b/Documentation/ABI/testing/configfs-spear-pcie-gadget @@ -1,7 +1,7 @@ What: /config/pcie-gadget Date: Feb 2011 KernelVersion: 2.6.37 -Contact: Pratyush Anand +Contact: Pratyush Anand Description: Interface is used to configure selected dual mode PCIe controller diff --git a/Documentation/ABI/testing/sysfs-bus-usb-lvstest b/Documentation/ABI/testing/sysfs-bus-usb-lvstest index aae68fc2d842..5151290cf8e7 100644 --- a/Documentation/ABI/testing/sysfs-bus-usb-lvstest +++ b/Documentation/ABI/testing/sysfs-bus-usb-lvstest @@ -4,14 +4,14 @@ driver is bound with root hub device. What: /sys/bus/usb/devices/.../get_dev_desc Date: March 2014 -Contact: Pratyush Anand +Contact: Pratyush Anand Description: Write to this node to issue "Get Device Descriptor" for Link Layer Validation device. It is needed for TD.7.06. What: /sys/bus/usb/devices/.../u1_timeout Date: March 2014 -Contact: Pratyush Anand +Contact: Pratyush Anand Description: Set "U1 timeout" for the downstream port where Link Layer Validation device is connected. Timeout value must be between 0 @@ -19,7 +19,7 @@ Description: What: /sys/bus/usb/devices/.../u2_timeout Date: March 2014 -Contact: Pratyush Anand +Contact: Pratyush Anand Description: Set "U2 timeout" for the downstream port where Link Layer Validation device is connected. Timeout value must be between 0 @@ -27,21 +27,21 @@ Description: What: /sys/bus/usb/devices/.../hot_reset Date: March 2014 -Contact: Pratyush Anand +Contact: Pratyush Anand Description: Write to this node to issue "Reset" for Link Layer Validation device. It is needed for TD.7.29, TD.7.31, TD.7.34 and TD.7.35. What: /sys/bus/usb/devices/.../u3_entry Date: March 2014 -Contact: Pratyush Anand +Contact: Pratyush Anand Description: Write to this node to issue "U3 entry" for Link Layer Validation device. It is needed for TD.7.35 and TD.7.36. What: /sys/bus/usb/devices/.../u3_exit Date: March 2014 -Contact: Pratyush Anand +Contact: Pratyush Anand Description: Write to this node to issue "U3 exit" for Link Layer Validation device. It is needed for TD.7.36. diff --git a/Documentation/misc-devices/spear-pcie-gadget.txt b/Documentation/misc-devices/spear-pcie-gadget.txt index 02c13ef5e908..89b88dee4143 100644 --- a/Documentation/misc-devices/spear-pcie-gadget.txt +++ b/Documentation/misc-devices/spear-pcie-gadget.txt @@ -2,7 +2,7 @@ Spear PCIe Gadget Driver: Author = -Pratyush Anand (pratyush.an...@st.com) +Pratyush Anand (pratyush.an...@gmail.com) Location diff --git a/drivers/misc/spear13xx_pcie_gadget.c b/drivers/misc/spear13xx_pcie_gadget.c index fe3ad0ca9a3e..b8374cdaf9c9 100644 --- a/drivers/misc/spear13xx_pcie_gadget.c +++ b/drivers/misc/spear13xx_pcie_gadget.c @@ -2,7 +2,7 @@ * drivers/misc/spear13xx_pcie_gadget.c * * Copyright (C) 2010 ST Microelectronics - * Pratyush Anand + * Pratyush Anand * * This file is licensed under the terms of the GNU General Public * License version 2. This program is licensed "as is" without any diff --git a/drivers/pci/host/pcie-spear13xx.c b/drivers/pci/host/pcie-spear13xx.c index 020d78890719..f086cdd23aff 100644 --- a/drivers/pci/host/pcie-spear13xx.c +++ b/drivers/pci/host/pcie-spear13xx.c @@ -4,7 +4,7 @@ * SPEAr13xx PCIe Glue Layer Source Code * * Copyright (C) 2010-2014 ST Microelectronics - * Pratyush Anand + * Pratyush Anand * Mohit Kumar * * This
Re: [RFC PATCH 00/14] ASoC: qcom: add support to apq8016 audio
On Sat, May 02, 2015 at 04:57:04PM -0700, Kenneth Westfield wrote: > On Thu, Apr 30, 2015 at 06:15:48PM +0100, Srinivas Kandagatla wrote: > > Hi All, > > > > This patchset adds apq8016 audio support into lpass driver. Existing > Lpass > > driver can not be used as-it-is for apq8016 as it contains code specific > to > > ipq806x. Also the driver only supports single i2s port, single dma > channel and > > single bitclk control. > > > > APQ8016 has 4 MI2S( Primary, Secondary, Tertiary, Quaternary) which can > be routed > > to internal wcd codec or external codecs. This routing is controlled by > 2 mux > > registers. > > > > This patch series firstly re-organizes the lpass driver such that the > SOC > > specific bits are moved away from the driver. And secondly the SOC > specifics > > are now passed as lpass variant data which would include various > register > > offsets, dma channel allocations and SOC specific clock handling. > > > > Finally the patchset add apq8016 lpass and machine driver. > > > > This patchset also has two trivial cleanup patches which are to do with > > redundant checks and removing unnecessary header files. > > > > All these patches are tested for HDMI audio via adv7533 bridge and > Analog audio > > on APQ8016-SBC and msm8916-mtp boards. I dont have access to ipq806x > boards to > > test these patches. > > > > This is very first version of the patches which was developed with very > > mimimal/no access to IP documentation. I would like to get your opinon > on the > > over all approch. > > > > > > Kenneth/Patrick, > > Could you please try these patches on storm board? > > I will test the patches and let you know by Wednesday. Also, I posted > some comments, but Patrick should be posting his comments separately > later next week. Srinivas, After applying the patches, audio playback is no longer functional on the storm board. Give me some time to debug this and I will get back to you. -- Kenneth Westfield Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- 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] xfs: inode counter needs to use __percpu_counter_compare
On Tue, May 05, 2015 at 09:38:07PM -0700, Christoph Hellwig wrote:
> > diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c
> > index 02f827f..900f8ce 100644
> > --- a/fs/xfs/xfs_mount.c
> > +++ b/fs/xfs/xfs_mount.c
> > @@ -1106,8 +1106,9 @@ xfs_mod_icount(
> > int64_t delta)
> > {
> > /* deltas are +/-64, hence the large batch size of 128. */
> > - __percpu_counter_add(>m_icount, delta, 128);
> > - if (percpu_counter_compare(>m_icount, 0) < 0) {
> > +#define _ICOUNT_BATCH 128
> > + __percpu_counter_add(>m_icount, delta, _ICOUNT_BATCH);
>
> Can you give XFS_ prefixes to the atch sizes and move them otuside the
> function? And fix up the instance in xfs_mod_fdblocks as well while
> you're at it.
Sure.
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: [alsa-devel] [RFC PATCH 03/14] ASoC: qcom: move ipq806x specific bits out of lpass driver.
On Tue, May 05, 2015 at 12:17:23AM -0700, Srinivas Kandagatla wrote:
> On 05/05/15 06:19, Kenneth Westfield wrote:
> >+enum lpaif_i2s_ports {
> >+ LPAIF_I2S_PORT_MIN = 0,
> >+
> >+ LPAIF_I2S_PORT_CODEC_SPK= 0,
> >+ LPAIF_I2S_PORT_CODEC_MIC= 1,
> >+ LPAIF_I2S_PORT_SEC_SPK = 2,
> >+ LPAIF_I2S_PORT_SEC_MIC = 3,
> >+ LPAIF_I2S_PORT_MI2S = 4,
> >+
> >+ LPAIF_I2S_PORT_MAX = 4,
> >+ LPAIF_I2S_PORT_NUM = 5,
> >+};
> >>>
> >>>These port mappings here...
> >>>
> >+enum lpaif_irq_ports {
> >+ LPAIF_IRQ_PORT_MIN = 0,
> >+
> >+ LPAIF_IRQ_PORT_HOST = 0,
> >+ LPAIF_IRQ_PORT_ADSP = 1,
> >+
> >+ LPAIF_IRQ_PORT_MAX = 2,
> >+ LPAIF_IRQ_PORT_NUM = 3,
> >+};
> >>>
> >>>...here...
> >>>
> >+enum lpaif_dma_channels {
> >+ LPAIF_RDMA_CHAN_MIN = 0,
> >+
> >+ LPAIF_RDMA_CHAN_MI2S= 0,
> >+ LPAIF_RDMA_CHAN_PCM0= 1,
> >+ LPAIF_RDMA_CHAN_PCM1= 2,
> >+
> >+ LPAIF_RDMA_CHAN_MAX = 4,
> >+ LPAIF_RDMA_CHAN_NUM = 5,
> >+};
> >>>
> >>>...and here can be SOC-specific. Should move them to the SOC-specific
> >>>files.
> >Expanding on this, the I2S port mappings for the APQ8016 should replace
> >the ones defined above with the constants you refer to in
> >dt-bindings/sound/apq8016.h:
> >MI2S_PRIMARY
> >MI2S_SECONDARY
> >etc.
> >
> >Maybe defining a corresponding ipq806x.h in the same directory, and
> >moving the above definitions there?
>
> As you pointed out i2s ports definitions can be moved to
> dt-bindings/soc/ipq806x.h but the channels can be directly defined
> in lpass-ipq806x.c as there would be no DT consumers for these
> defines
> anyway.
Moving the I2S ports to dt-bindings and the other definitions to their
SOC-specific source files works for me.
--
Kenneth Westfield
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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] percpu_counter: batch size aware __percpu_counter_compare()
On Tue, May 05, 2015 at 09:36:36PM -0700, Christoph Hellwig wrote: > This looks reasonable, but I miss Ccs to the authors of the > percpu_counter code and linux-kernel. linux-kernel was cc'd. > On Wed, May 06, 2015 at 08:01:38AM +1000, Dave Chinner wrote: > > From: Dave Chinner > > > > From: Dave Chinner > > And this looks wrong, too :) That looks like a change of tool behaviour. I just upgraded guilt; the old version stripped "from" lines in patch descriptions from the git commit log as goes into the author field of the commit. The new version does not appear to strip the from lines, and so when git-send-email formats it, it puts a from line in the message, and then the commit message has one too. Thanks for pointing it out. 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: question about RCU dynticks_nesting
On Tue, May 05, 2015 at 05:09:23PM -0400, Rik van Riel wrote: > On 05/05/2015 02:35 PM, Paul E. McKenney wrote: > > On Tue, May 05, 2015 at 03:00:26PM +0200, Peter Zijlstra wrote: > >> On Tue, May 05, 2015 at 05:34:46AM -0700, Paul E. McKenney wrote: > >>> On Tue, May 05, 2015 at 12:53:46PM +0200, Peter Zijlstra wrote: > On Mon, May 04, 2015 at 12:39:23PM -0700, Paul E. McKenney wrote: > > But in non-preemptible RCU, we have PREEMPT=n, so there is no preempt > > counter in production kernels. Even if there was, we have to sample > > this > > on other CPUs, so the overhead of preempt_disable() and preempt_enable() > > would be where kernel entry/exit is, so I expect that this would be a > > net loss in overall performance. > > We unconditionally have the preempt_count, its just not used much for > PREEMPT_COUNT=n kernels. > >>> > >>> We have the field, you mean? I might be missing something, but it still > >>> appears to me thta preempt_disable() does nothing for PREEMPT=n kernels. > >>> So what am I missing? > >> > >> There's another layer of accessors that can in fact manipulate the > >> preempt_count even for !PREEMPT_COUNT kernels. They are currently used > >> by things like pagefault_disable(). > > > > OK, fair enough. > > > > I am going to focus first on getting rid of (or at least greatly reducing) > > RCU's interrupt disabling on the user-kernel entry/exit paths, since > > that seems to be the biggest cost. > > Interrupts are already disabled on kernel-user and kernel-guest > switches. Paolo and I have patches to move a bunch of the calls > to user_enter, user_exit, guest_enter, and guest_exit to places > where interrupts are already disabled, so we do not need to > disable them again. > > With those in place, the vtime calculations are the largest > CPU user. I am working on those. OK, so I should stop worrying about making rcu_user_enter() and rcu_user_exit() operate with interrupts disabled, and instead think about the overhead of the operations themselves. Probably starting from Mike Galbraith's profile (thank you!) unless Rik has some reason to believe that it is nonrepresentative. Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [RFC PATCH 14/14] ASoC: qcom: document apq8016 machine driver bindings
On Tue, May 05, 2015 at 12:17:01AM -0700, Srinivas Kandagatla wrote:
> On 03/05/15 01:03, Kenneth Westfield wrote:
> >On Thu, Apr 30, 2015 at 06:18:26PM +0100, Srinivas Kandagatla wrote:
> >>This patch adds bindings for apq8016 machine driver.
> >>On APQ8016 4 MI2S can be configured to different sinks like internal
> >>codec/external codec, this connection is controlled via 2 iomux
> >>registers.
> >>
> >>+sound: sound {
> >>+ compatible = "qcom,apq8016-sndcard";
> >>+ reg = <0x07702000 0x4>, <0x07702004 0x4>;
> >>+ reg-names = "mic-iomux", "spkr-iomux";
> >>+ qcom,model = "DB410c";
> >>+
> >>+ /* I2S - Internal codec */
> >>+ internal-dai-link@0 {
> >>+ cpu { /* PRIMARY */
> >>+ sound-dai = < MI2S_PRIMARY>;
> >>+ };
> >>+ codec {
> >>+ sound-dai = <_codec 0>;
> >>+ };
> >>+ };
> >>+
> >>+ /* External Primary or External Secondary -ADV7533 HDMI */
> >>+ external-dai-link@0 {
> >>+ external;
> >>+ cpu { /* QUAT */
> >>+ sound-dai = < MI2S_QUATERNARY>;
> >>+ };
> >>+ codec {
> >>+ sound-dai = <_bridge 0>;
> >>+ };
> >>+ };
> >>+};
> >
> >OK, although I will need to double-check this with the spec, it seems
> >(from the patches) that there are 4 I2S ports, 2 of which are being
> >used. Usually, multi-channel audio is sent to the primary dai (which
> >is MI2S), which then gets sent to the other ports by HW. If that holds
> >true for this SOC, then the external cpu dai should be labelled I2S,
> >not MI2S. If not, then both should be labelled as I2S (and the DAI
> >channel constraints should be reduced to 1-2).
> >
> I have got very limited access to documentation, which obviously
> does not have any info related to channel capabilities. I was
> thinking that all the playback ports support multi-channel. I might
> be wrong though.
After checking the specs, the four playback DAIs are, in fact,
multi-channel. Therefore, MI2S_ is the correct prefix for them.
>
> >Looking at patch 12, the internal DAI is labelled Headset and the
> >external DAI is labelled HDMI.
> This naming is very specific to the SBC board.
>
> I will check the spec to see if the QUAT
> >I2S port can handle multi-channel.
> External HDMI bridge on the other side only supports 2-channels, but
> if you can re-check on the channel capabilities would be good.
Ah, ok. Then no need to worry about multi-channel playback. Just need
to ensure the codec drivers constrain the channels to mono/stereo.
--
Kenneth Westfield
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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 04/27] extcon: Allow compile test of GPIO consumers if !GPIOLIB
Hi Geert, On 05/06/2015 01:32 AM, Geert Uytterhoeven wrote: > The GPIO subsystem provides dummy GPIO consumer functions if GPIOLIB is > not enabled. Hence drivers that depend on GPIOLIB, but use GPIO consumer > functionality only, can still be compiled if GPIOLIB is not enabled. > > Relax the dependency on GPIOLIB if COMPILE_TEST is enabled, where > appropriate. > > If GPIOLIB=n and asm-generic/gpio.h is not used: > > drivers/extcon/extcon-usb-gpio.c: In function ‘usb_extcon_detect_cable’: > drivers/extcon/extcon-usb-gpio.c:63: error: implicit declaration of > function ‘gpiod_get_value_cansleep’ > drivers/extcon/extcon-usb-gpio.c: In function ‘usb_extcon_probe’: > drivers/extcon/extcon-usb-gpio.c:116: error: implicit declaration of > function ‘devm_gpiod_get’ > drivers/extcon/extcon-usb-gpio.c:116: warning: assignment makes pointer > from integer without a cast > drivers/extcon/extcon-usb-gpio.c:122: error: implicit declaration of > function ‘gpiod_set_debounce’ > drivers/extcon/extcon-usb-gpio.c:129: error: implicit declaration of > function ‘gpiod_to_irq’ > > Add the missing #include to fix this. > > Signed-off-by: Geert Uytterhoeven > Cc: MyungJoo Ham > Cc: Chanwoo Choi > --- > drivers/extcon/Kconfig | 4 ++-- > drivers/extcon/extcon-usb-gpio.c | 1 + > 2 files changed, 3 insertions(+), 2 deletions(-) Applied it on -next branch. Thanks, Chanwoo Choi -- 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: [alsa-devel] [RFC PATCH 03/14] ASoC: qcom: move ipq806x specific bits out of lpass driver.
On Tue, May 05, 2015 at 12:16:46AM -0700, Srinivas Kandagatla wrote:
> On 03/05/15 00:57, Kenneth Westfield wrote:
> >On Thu, Apr 30, 2015 at 06:16:53PM +0100, Srinivas Kandagatla wrote:
> >>This patch tries to make the lpass driver more generic by moving the
> >>ipq806x specific bits out of the cpu and platform driver, also allows
> the
> >>SOC specific drivers to add the correct register offsets.
> >>
> >>This patch also renames the register definition header file into more
> >>generic header file.
> >
> >>diff --git a/sound/soc/qcom/lpass-ipq806x.c
> b/sound/soc/qcom/lpass-ipq806x.c
> >>new file mode 100644
> >>index 000..8e9a427
> >>--- /dev/null
> >>+++ b/sound/soc/qcom/lpass-ipq806x.c
> >
> >>+static const struct of_device_id ipq806x_lpass_cpu_device_id[] = {
> >>+ { .compatible = "qcom,lpass-cpu", .data = _data },
> >>+ {}
> >>+};
> >>+MODULE_DEVICE_TABLE(of, ipq806x_lpass_cpu_device_id);
> >
> >Surround with #ifdef CONFIG_OF?
>
> I was more of thinking adding "depends OF" in Kconfig.
Works for me.
> Is there any possibility that the driver would support non-DT?
Not that I am aware of.
--
Kenneth Westfield
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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/
staging: lustre: lclient: lcommon_cl.c fixing coding style issues
This patch fixes the checkpatch.pl warning:
WARNING: else is not generally useful after a break or return
+ return result;
+ } else {
Signed-off-by: Ankit Garg
---
drivers/staging/lustre/lustre/lclient/lcommon_cl.c | 35 ++--
1 file changed, 17 insertions(+), 18 deletions(-)
diff --git a/drivers/staging/lustre/lustre/lclient/lcommon_cl.c
b/drivers/staging/lustre/lustre/lclient/lcommon_cl.c
index ab6cb41..1c96ede 100644
--- a/drivers/staging/lustre/lustre/lclient/lcommon_cl.c
+++ b/drivers/staging/lustre/lustre/lclient/lcommon_cl.c
@@ -836,25 +836,24 @@ int ccc_prep_size(const struct lu_env *env, struct
cl_object *obj,
*exceed = 1;
}
return result;
- } else {
- /*
-* region is within kms and, hence, within real file
-* size (A). We need to increase i_size to cover the
-* read region so that generic_file_read() will do its
-* job, but that doesn't mean the kms size is
-* _correct_, it is only the _minimum_ size. If
-* someone does a stat they will get the correct size
-* which will always be >= the kms value here.
-* b=11081
-*/
- if (cl_isize_read(inode) < kms) {
- cl_isize_write_nolock(inode, kms);
- CDEBUG(D_VFSTRACE,
- DFID" updating i_size %llu\n",
- PFID(lu_object_fid(>co_lu)),
- (__u64)cl_isize_read(inode));
+ }
+ /*
+* region is within kms and, hence, within real file
+* size (A). We need to increase i_size to cover the
+* read region so that generic_file_read() will do its
+* job, but that doesn't mean the kms size is
+* _correct_, it is only the _minimum_ size. If
+* someone does a stat they will get the correct size
+* which will always be >= the kms value here.
+* b=11081
+*/
+ if (cl_isize_read(inode) < kms) {
+ cl_isize_write_nolock(inode, kms);
+ CDEBUG(D_VFSTRACE,
+ DFID" updating i_size %llu\n",
+ PFID(lu_object_fid(>co_lu)),
+ (__u64)cl_isize_read(inode));
- }
}
}
ccc_object_size_unlock(obj);
--
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] Staging : wlan-ng: fix memcpy with ether_addr_copy in p80211conv.c
On Tue, May 05, 2015 at 04:25:31PM +0530, Abhishek Bist wrote: > This is a patch which fixes memcpy warning found by a checpatch.pl in > p80211conv.c > and replaces memcpy with ether_addr_copy. > --- you missed the the Signed-off-by: regards sudip -- 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: [PATCHv4 00/10] add on-demand device creation
On (05/04/15 21:38), Sergey Senozhatsky wrote:
> We currently don't support zram on-demand device creation. The only way
> to have N zram devices is to specify num_devices module parameter (default
> value 1). That means that if, for some reason, at some point, user wants
> to have N + 1 devies he/she must umount all the existing devices, unload
> the module, load the module passing num_devices equals to N + 1.
>
> This patchset introduces zram-control sysfs class, which has two sysfs
> attrs:
>
> - zram_add -- add a new zram device
> - zram_remove -- remove a specific (device_id) zram device
>
> Usage example:
> # add a new specific zram device
> cat /sys/class/zram-control/zram_add
> 1
>
> # remove a specific zram device
> echo 4 > /sys/class/zram-control/zram_remove
>
Andrew,
could you please drop the entire series from -mm? Minchan has reported a
problem (requires some investigation) and proposed several changes, f.e.
to rename zram confrol's sysfs nodes to zram_control/{hot_add, hot_remove}.
to drop:
zram-add-dynamic-device-add-remove-functionality.patch added to -mm tree
zram-close-race-by-open-overriding.patch added to -mm tree
zram-return-zram-device_id-from-zram_add.patch added to -mm tree
zram-trivial-correct-flag-operations-comment.patch added to -mm tree
zram-report-every-added-and-removed-device.patch added to -mm tree
zram-reorganize-code-layout.patch added to -mm tree
zram-remove-max_num_devices-limitation.patch added to -mm tree
zram-use-idr-instead-of-zram_devices-array.patch added to -mm tree
zram-add-compact-sysfs-entry-to-documentation.patch added to -mm tree
zram-cosmetic-zram_attr_ro-code-formatting-tweak.patch added to -mm tree
thank you.
-ss
> V4:
> -- add patch from Minchan to handle differently a deadlock suspected by
> lockdep
> -- use zram->claim in zram_remove()
>
> V3:
> -- rebase against 4.1
> -- review comments from Minchan were addressed
> -- no sysfs RO tricks anymore
>
> V2:
> -- quick rebase and cleanup in attempt to catch 4.1 merge window
>
>
> Minchan Kim (1):
> zram: close race by open overriding
>
> Sergey Senozhatsky (9):
> zram: add `compact` sysfs entry to documentation
> zram: cosmetic ZRAM_ATTR_RO code formatting tweak
> zram: use idr instead of `zram_devices' array
> zram: reorganize code layout
> zram: remove max_num_devices limitation
> zram: report every added and removed device
> zram: trivial: correct flag operations comment
> zram: return zram device_id from zram_add()
> zram: add dynamic device add/remove functionality
>
> Documentation/ABI/testing/sysfs-class-zram | 24 +
> Documentation/blockdev/zram.txt| 29 +-
> drivers/block/zram/zram_drv.c | 1002
>
> drivers/block/zram/zram_drv.h | 10 +-
> 4 files changed, 612 insertions(+), 453 deletions(-)
> create mode 100644 Documentation/ABI/testing/sysfs-class-zram
>
> --
> 2.4.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 2/9][v3]usb:fsl:otg: Add support to add/remove usb host driver
> -Original Message- > From: Alan Stern [mailto:st...@rowland.harvard.edu] > Sent: Wednesday, May 06, 2015 1:00 AM > To: Mehresh Ramneek-B31383 > Cc: Kernel development list; Felipe Balbi; USB list; > gre...@linuxfoundation.org > Subject: Re: [PATCH 2/9][v3]usb:fsl:otg: Add support to add/remove usb > host driver > > On Tue, 5 May 2015, Ramneek Mehresh wrote: > > > Add workqueue to add/remove host driver (outside interrupt context) > > upon each id change > > > > Signed-off-by: Ramneek Mehresh > > --- > > Changes for v3: > > - use overrides for ehci_fsl_overrides > > - remove struct ehci_hcd from ehci_fsl > > - move ehci_fsl to ehci-fsl.h > > This patch changes at least three separate things: > > It adds the workqueue stuff. > > It replaces ehci_fsl_hc_driver with ehci_fsl_overrides. > > It adds new fields into the overrides structure. > understood > A patch should do only one thing. It certainly shouldn't make three separate, > major changes! > > Also, I'm not going to let you add new fields into the ehci_driver_overrides > structure. If you really need to override other routines, copy the approach > used by ehci-tegra.c. > Understood...but I would appreciate if you could please explain the harm in doing so > 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/
Re: [PATCH 01/12] net: axienet: Support for RGMII
Hi David, On 05/06/2015 01:35 AM, David Miller wrote: > > Series applied to net-next. Thanks. > > Next time, you should give an initial "[PATCH 00/nn] " posting > describing overall at a high level what the series is doing. > > That way I can use that information in the commit message of > a merge commit for your series, and also have one posting I > can reply to in order to give high level feedback or to simply > say I applied everything. Will do. Thanks, Michal -- 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] remove
Ok, here is the Kbuild fix: --- >From 273950b87bde0fa05944b60f3ed05c3b3c0f6601 Mon Sep 17 00:00:00 2001 From: Christoph Hellwig Date: Wed, 6 May 2015 07:17:09 +0200 Subject: remove scatterlist.h generation from arch Kbuild files Signed-off-by: Christoph Hellwig Reported-by: Geert Uytterhoeven --- arch/alpha/include/asm/Kbuild | 1 - arch/arc/include/asm/Kbuild| 1 - arch/arm/include/asm/Kbuild| 1 - arch/arm64/include/asm/Kbuild | 1 - arch/avr32/include/asm/Kbuild | 1 - arch/blackfin/include/asm/Kbuild | 2 -- arch/c6x/include/asm/Kbuild| 1 - arch/cris/include/asm/Kbuild | 1 - arch/frv/include/asm/Kbuild| 1 - arch/hexagon/include/asm/Kbuild| 1 - arch/ia64/include/asm/Kbuild | 1 - arch/m32r/include/asm/Kbuild | 1 - arch/m68k/include/asm/Kbuild | 1 - arch/metag/include/asm/Kbuild | 1 - arch/microblaze/include/asm/Kbuild | 1 - arch/mips/include/asm/Kbuild | 1 - arch/mn10300/include/asm/Kbuild| 1 - arch/nios2/include/asm/Kbuild | 1 - arch/openrisc/include/asm/Kbuild | 1 - arch/parisc/include/asm/Kbuild | 1 - arch/powerpc/include/asm/Kbuild| 1 - arch/s390/include/asm/Kbuild | 1 - arch/score/include/asm/Kbuild | 1 - arch/sh/include/asm/Kbuild | 1 - arch/sparc/include/asm/Kbuild | 1 - arch/tile/include/asm/Kbuild | 1 - arch/um/include/asm/Kbuild | 2 -- arch/unicore32/include/asm/Kbuild | 1 - arch/x86/include/asm/Kbuild| 1 - arch/xtensa/include/asm/Kbuild | 1 - 30 files changed, 32 deletions(-) diff --git a/arch/alpha/include/asm/Kbuild b/arch/alpha/include/asm/Kbuild index 76aeb8f..cde23cd 100644 --- a/arch/alpha/include/asm/Kbuild +++ b/arch/alpha/include/asm/Kbuild @@ -6,6 +6,5 @@ generic-y += exec.h generic-y += irq_work.h generic-y += mcs_spinlock.h generic-y += preempt.h -generic-y += scatterlist.h generic-y += sections.h generic-y += trace_clock.h diff --git a/arch/arc/include/asm/Kbuild b/arch/arc/include/asm/Kbuild index be0c39e..769b312 100644 --- a/arch/arc/include/asm/Kbuild +++ b/arch/arc/include/asm/Kbuild @@ -33,7 +33,6 @@ generic-y += poll.h generic-y += posix_types.h generic-y += preempt.h generic-y += resource.h -generic-y += scatterlist.h generic-y += sembuf.h generic-y += shmbuf.h generic-y += siginfo.h diff --git a/arch/arm/include/asm/Kbuild b/arch/arm/include/asm/Kbuild index 3c4596d..83c5019 100644 --- a/arch/arm/include/asm/Kbuild +++ b/arch/arm/include/asm/Kbuild @@ -20,7 +20,6 @@ generic-y += poll.h generic-y += preempt.h generic-y += resource.h generic-y += rwsem.h -generic-y += scatterlist.h generic-y += seccomp.h generic-y += sections.h generic-y += segment.h diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild index 55103e5..b112a39 100644 --- a/arch/arm64/include/asm/Kbuild +++ b/arch/arm64/include/asm/Kbuild @@ -35,7 +35,6 @@ generic-y += poll.h generic-y += preempt.h generic-y += resource.h generic-y += rwsem.h -generic-y += scatterlist.h generic-y += sections.h generic-y += segment.h generic-y += sembuf.h diff --git a/arch/avr32/include/asm/Kbuild b/arch/avr32/include/asm/Kbuild index 528d70d..1d66afd 100644 --- a/arch/avr32/include/asm/Kbuild +++ b/arch/avr32/include/asm/Kbuild @@ -15,7 +15,6 @@ generic-y += mcs_spinlock.h generic-y += param.h generic-y += percpu.h generic-y += preempt.h -generic-y += scatterlist.h generic-y += sections.h generic-y += topology.h generic-y += trace_clock.h diff --git a/arch/blackfin/include/asm/Kbuild b/arch/blackfin/include/asm/Kbuild index 4bd3c3c..c24d1ba 100644 --- a/arch/blackfin/include/asm/Kbuild +++ b/arch/blackfin/include/asm/Kbuild @@ -28,8 +28,6 @@ generic-y += param.h generic-y += percpu.h generic-y += pgalloc.h generic-y += preempt.h -generic-y += resource.h -generic-y += scatterlist.h generic-y += sembuf.h generic-y += serial.h generic-y += setup.h diff --git a/arch/c6x/include/asm/Kbuild b/arch/c6x/include/asm/Kbuild index ae0a51f..7aeb322 100644 --- a/arch/c6x/include/asm/Kbuild +++ b/arch/c6x/include/asm/Kbuild @@ -38,7 +38,6 @@ generic-y += poll.h generic-y += posix_types.h generic-y += preempt.h generic-y += resource.h -generic-y += scatterlist.h generic-y += segment.h generic-y += sembuf.h generic-y += serial.h diff --git a/arch/cris/include/asm/Kbuild b/arch/cris/include/asm/Kbuild index 057e518..d294f6a 100644 --- a/arch/cris/include/asm/Kbuild +++ b/arch/cris/include/asm/Kbuild @@ -21,7 +21,6 @@ generic-y += mcs_spinlock.h generic-y += module.h generic-y += percpu.h generic-y += preempt.h -generic-y += scatterlist.h generic-y += sections.h generic-y += topology.h generic-y += trace_clock.h diff --git a/arch/frv/include/asm/Kbuild b/arch/frv/include/asm/Kbuild index e3f81b5..30edce3 100644 --- a/arch/frv/include/asm/Kbuild +++ b/arch/frv/include/asm/Kbuild @@ -5,5 +5,4 @@ generic-y += exec.h generic-y += irq_work.h generic-y += mcs_spinlock.h generic-y += preempt.h
Re: [PATCHv4 00/10] add on-demand device creation
Hi, On (05/06/15 14:01), Minchan Kim wrote: > Hello Sergey, > > On Mon, May 04, 2015 at 09:38:52PM +0900, Sergey Senozhatsky wrote: > > We currently don't support zram on-demand device creation. The only way > > to have N zram devices is to specify num_devices module parameter (default > > value 1). That means that if, for some reason, at some point, user wants > > to have N + 1 devies he/she must umount all the existing devices, unload > > the module, load the module passing num_devices equals to N + 1. > > > > This patchset introduces zram-control sysfs class, which has two sysfs > > attrs: > > > > - zram_add -- add a new zram device > > - zram_remove -- remove a specific (device_id) zram device > > > > Usage example: > > # add a new specific zram device > > cat /sys/class/zram-control/zram_add > > 1 > > > > # remove a specific zram device > > echo 4 > /sys/class/zram-control/zram_remove > > I just reported bug. Please handle it. a-ha... found it: http://lkml.iu.edu/hypermail/linux/kernel/1505.0/04389.html will take a look. thanks! > Other nits: > > 1) How about inserting a step to reset before zram_remove? > IOW, user should echo "1" > /sys/block/zram[0-9]*/reset before > echo zram_id > /sys/class/zram-control/zram_remove. > > Actually, I can't think any benefit other than consistency of > zram interface but you might have. well, I did this the way it is because there is no requirement to reset any devices before `rmmod zram' (which eventually removes all zram devices from the system), a set of umount-s is enough. so requiring both umount and reset before hot_remove seems to be a bit different. zram_remove() is called from both hot_remove and zram_exit()->destroy_devices() (which requires reset step anyway). so I'm not sure about this change. do you have any strong objections? > 2) How about using hot_add/hot_remove? > > /class/zram-control includes prefix zram meaning so I think > we don't need zram prefix of the knobs. Instead, let's add > *hot* which is more straightforward for representing *dynamic*. > > What do you think about it? ok. I can change it. I'll ask Andrew to drop the entire patch series and will resubmit once we settle it down. -ss -- 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] MAINTAINERS: Extend Samsung MFD drivers entry and add myself
Extend the entry for Samsung MFD drivers for PMIC devices (Power Management Integrated Circuit) with bindings documentation, clock (clk-s2mps11.c) and RTC drivers (rtc-s5m.c). These PMIC devices are used on many Exynos-based boards like Arndale Octa (S2MPS11), Gear 2 (S2MPS14). Add myself as a supporter for reviewing them. I am not the author of these drivers. However I have recently contributed to most of them and I have access to datasheets and hardware. Cc: Sangbeom Kim CC: Mike Turquette CC: Stephen Boyd CC: Alessandro Zummo CC: Alexandre Belloni CC: Lee Jones CC: Liam Girdwood CC: Mark Brown Signed-off-by: Krzysztof Kozlowski --- MAINTAINERS | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index e278814388f7..fc01dc9f96af 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8533,14 +8533,20 @@ L: linux-fb...@vger.kernel.org S: Maintained F: drivers/video/fbdev/s3c-fb.c -SAMSUNG MULTIFUNCTION DEVICE DRIVERS +SAMSUNG MULTIFUNCTION PMIC DEVICE DRIVERS M: Sangbeom Kim +M: Krzysztof Kozlowski L: linux-kernel@vger.kernel.org +L: linux-samsung-...@vger.kernel.org S: Supported F: drivers/mfd/sec*.c F: drivers/regulator/s2m*.c F: drivers/regulator/s5m*.c +F: drivers/clk/clk-s2mps11.c +F: drivers/rtc/rtc-s5m.c F: include/linux/mfd/samsung/ +F: Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt +F: Documentation/devicetree/bindings/mfd/s2mp*.txt SAMSUNG S5P/EXYNOS4 SOC SERIES CAMERA SUBSYSTEM DRIVERS M: Kyungmin Park -- 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: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.
Hi Peter, Am 05.05.2015 um 21:54 schrieb Peter Hurley : > Hi Neil, > > On 03/18/2015 01:58 AM, NeilBrown wrote: >> here is version 3 of support for tty-slaves. > > Is there a v4 of this that I missed? We did have a lengthy discussion about [PATCH 3/3] how to best (1) represent the slave device in the device tree but as far as I am concerned, I do not see that we have a consensus (2) and the device tree maintainers have no comments or clear guidelines so far. BR, Nikolaus (1) best with respect to maintainability, flexibility, common design patterns, compatibility and some other factors I don’t know the correct english words for (2) basically the slave can be described as a subnode like for I2C bus slaves or the slave device can reference the uart it is connected to like for GPIOs and regulators-- 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] x86, irq: Support CPU vector allocation policies
On 2015/5/6 3:25, Thomas Gleixner wrote:
> On Mon, 4 May 2015, Jiang Liu wrote:
>> +enum {
>> +/* Allocate CPU vectors from CPUs on device local node */
>> +X86_VECTOR_POL_NODE = 0x1,
>> +/* Allocate CPU vectors from all online CPUs */
>> +X86_VECTOR_POL_GLOBAL = 0x2,
>> +/* Allocate CPU vectors from caller specified CPUs */
>> +X86_VECTOR_POL_CALLER = 0x4,
>> +X86_VECTOR_POL_MIN = X86_VECTOR_POL_NODE,
>> +X86_VECTOR_POL_MAX = X86_VECTOR_POL_CALLER,
>> +}
>
>> +static unsigned int vector_alloc_policy = X86_VECTOR_POL_NODE |
>> + X86_VECTOR_POL_GLOBAL |
>> + X86_VECTOR_POL_CALLER;
>
>> +static int __init apic_parse_vector_policy(char *str)
>> +{
>> +if (!strncmp(str, "node", 4))
>> +vector_alloc_policy |= X86_VECTOR_POL_NODE;
>
> This does not make sense. X86_VECTOR_POL_NODE is already set.
>
>> +else if (!strncmp(str, "global", 6))
>> +vector_alloc_policy &= ~X86_VECTOR_POL_NODE;
>
> Why would one disable node aware allocation? We fall back to the
> global allocation anyway, if the node aware allocation fails.
>
> I'm completely missing the value of this command line option.
Hi Thomas,
You are right. Originally I want a method to disable the
per-node allocation policy. Think it twice, it seems unnecessary
at all. Enabling per-node allocation policy by default shouldn't
cause serious issues, and user may change irq affinity setting
if the default affinity isn't desired.
So we don't need the kernel parameter at all. Will update
the patch.
Thanks!
Gerry
>
> Thanks,
>
> tglx
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
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] block: loop: avoiding too many pending per work I/O
On Wed, May 6, 2015 at 11:14 AM, Ming Lei wrote: > On Wed, May 6, 2015 at 12:55 AM, Tejun Heo wrote: >> Hello, Ming. >> >> On Tue, May 05, 2015 at 10:46:10PM +0800, Ming Lei wrote: >>> On Tue, May 5, 2015 at 9:59 PM, Tejun Heo wrote: >>> > It's a bit weird to hard code this to 16 as this effectively becomes a >>> > hidden bottleneck for concurrency. For cases where 16 isn't a good >>> > value, hunting down what's going on can be painful as it's not visible >>> > anywhere. I still think the right knob to control concurrency is >>> > nr_requests for the loop device. You said that for linear IOs, it's >>> > better to have higher nr_requests than concurrency but can you >>> > elaborate why? >>> >>> I mean, in case of sequential IO, the IO may hit page cache a bit easier, >>> so handling the IO may be quite quick, then it is often more efficient to >>> handle them in one same context(such as, handle one by one from IO >>> queue) than from different contexts(scheduled from different worker >>> threads). And that can be made by setting a bigger nr_requests(queue_depth). >> >> Ah, so, it's about the queueing latency. Blocking the issuer from >> get_request side for the same level of concurrency would incur a lot >> longer latency before the next IO can be dispatched. The arbitrary 16 >> is still bothering but for now it's fine I guess, but we need to >> revisit the whole thing including WQ_HIGHPRI thing. Maybe it made >> sense when we had only one thread servicing all IOs but w/ high >> concurrency I don't think it's a good idea. > > Yes, I was thinking about it too, but concurrency can improve > random I/O throughput a lot in my tests. Thinking of it further, the problem becomes very similar with 'Non-blocking buffered file read operations'[1] which was discussed last year. If the read IO can be predicted as buffered I/O, we handle it in single thread, otherwise handle it concurrently, and this approach should be more efficient if possible, I think. But I still prefer to dio/aio approach because double cache can be avoided, which is a big win in my previous tests. [1], https://lwn.net/Articles/612483/ 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/
[PATCH v3 3/3] f2fs: support FALLOC_FL_ZERO_RANGE
Now, FALLOC_FL_ZERO_RANGE flag in ->fallocate is supported in ext4/xfs.
In commit, the semantics of this flag is descripted as following:"
1) Make sure that both offset and len are block size aligned.
2) Update the i_size of inode by len bytes.
3) Compute the file's logical block number against offset. If the computed
block number is not the starting block of the extent, split the extent
such that the block number is the starting block of the extent.
4) Shift all the extents which are lying between
[offset, last allocated extent] towards right by len bytes. This step
will make a hole of len bytes at offset."
This patch implements fallocate's FALLOC_FL_ZERO_RANGE for f2fs.
Signed-off-by: Chao Yu
---
v2:
* rebase to last git repository of f2fs (20150430)
v3:
* rebase to last git repository of f2fs (20150506)
fs/f2fs/file.c | 106 -
1 file changed, 105 insertions(+), 1 deletion(-)
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index dbddc79..7293746 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -891,6 +891,108 @@ static int f2fs_collapse_range(struct inode *inode,
loff_t offset, loff_t len)
return ret;
}
+static int f2fs_zero_range(struct inode *inode, loff_t offset, loff_t len,
+ int mode)
+{
+ struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
+ struct address_space *mapping = inode->i_mapping;
+ pgoff_t index, pg_start, pg_end;
+ loff_t new_size = i_size_read(inode);
+ loff_t off_start, off_end;
+ int ret = 0;
+
+ if (!S_ISREG(inode->i_mode))
+ return -EINVAL;
+
+ ret = inode_newsize_ok(inode, (len + offset));
+ if (ret)
+ return ret;
+
+ f2fs_balance_fs(sbi);
+
+ if (f2fs_has_inline_data(inode)) {
+ ret = f2fs_convert_inline_inode(inode);
+ if (ret)
+ return ret;
+ }
+
+ ret = filemap_write_and_wait_range(mapping, offset, offset + len - 1);
+ if (ret)
+ return ret;
+
+ truncate_pagecache_range(inode, offset, offset + len - 1);
+
+ pg_start = ((unsigned long long) offset) >> PAGE_CACHE_SHIFT;
+ pg_end = ((unsigned long long) offset + len) >> PAGE_CACHE_SHIFT;
+
+ off_start = offset & (PAGE_CACHE_SIZE - 1);
+ off_end = (offset + len) & (PAGE_CACHE_SIZE - 1);
+
+ if (pg_start == pg_end) {
+ fill_zero(inode, pg_start, off_start, off_end - off_start);
+ if (offset + len > new_size)
+ new_size = offset + len;
+ new_size = max_t(loff_t, new_size, offset + len);
+ } else {
+ if (off_start) {
+ fill_zero(inode, pg_start++, off_start,
+ PAGE_CACHE_SIZE - off_start);
+ new_size = max_t(loff_t, new_size,
+ pg_start << PAGE_CACHE_SHIFT);
+ }
+
+ for (index = pg_start; index < pg_end; index++) {
+ struct dnode_of_data dn;
+ struct page *ipage;
+
+ f2fs_lock_op(sbi);
+
+ ipage = get_node_page(sbi, inode->i_ino);
+ if (IS_ERR(ipage)) {
+ ret = PTR_ERR(ipage);
+ f2fs_unlock_op(sbi);
+ goto out;
+ }
+
+ set_new_dnode(, inode, ipage, NULL, 0);
+ ret = f2fs_reserve_block(, index);
+ if (ret) {
+ f2fs_unlock_op(sbi);
+ goto out;
+ }
+
+ if (dn.data_blkaddr != NEW_ADDR) {
+ invalidate_blocks(sbi, dn.data_blkaddr);
+
+ dn.data_blkaddr = NEW_ADDR;
+ set_data_blkaddr();
+
+ dn.data_blkaddr = NULL_ADDR;
+ f2fs_update_extent_cache();
+ }
+ f2fs_put_dnode();
+ f2fs_unlock_op(sbi);
+
+ new_size = max_t(loff_t, new_size,
+ (index + 1) << PAGE_CACHE_SHIFT);
+ }
+
+ if (off_end) {
+ fill_zero(inode, pg_end, 0, off_end);
+ new_size = max_t(loff_t, new_size, offset + len);
+ }
+ }
+
+out:
+ if (!(mode & FALLOC_FL_KEEP_SIZE) && i_size_read(inode) < new_size) {
+ i_size_write(inode, new_size);
+ mark_inode_dirty(inode);
+ update_inode_page(inode);
+ }
+
+ return ret;
+}
+
static int expand_inode_data(struct inode *inode, loff_t offset,
[PATCH v3 2/3] f2fs: support FALLOC_FL_COLLAPSE_RANGE
Now, FALLOC_FL_COLLAPSE_RANGE flag in ->fallocate is supported in ext4/xfs.
In commit, the semantics of this flag is descripted as following:"
1) It collapses the range lying between offset and length by removing any
data blocks which are present in this range and than updates all the
logical offsets of extents beyond "offset + len" to nullify the hole
created by removing blocks. In short, it does not leave a hole.
2) It should be used exclusively. No other fallocate flag in combination.
3) Offset and length supplied to fallocate should be fs block size aligned
in case of xfs and ext4.
4) Collaspe range does not work beyond i_size."
This patch implements fallocate's FALLOC_FL_COLLAPSE_RANGE for f2fs.
Signed-off-by: Chao Yu
---
v2:
* rebase to last git repository of f2fs (20150430)
* remove replace_block() introduction.
v3:
* rebase to last git repository of f2fs (20150506)
* fix to pass right parameter to f2fs_replace_block().
fs/f2fs/file.c | 135 +++--
1 file changed, 132 insertions(+), 3 deletions(-)
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index cb002c0..dbddc79 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -765,6 +765,132 @@ static int punch_hole(struct inode *inode, loff_t offset,
loff_t len)
return ret;
}
+static int f2fs_do_collapse(struct inode *inode, pgoff_t start, pgoff_t end)
+{
+ struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
+ struct dnode_of_data dn;
+ pgoff_t nrpages = (i_size_read(inode) + PAGE_SIZE - 1) / PAGE_SIZE;
+ int ret = 0;
+
+ f2fs_lock_op(sbi);
+
+ for (; end < nrpages; start++, end++) {
+ block_t new_addr, old_addr;
+
+ set_new_dnode(, inode, NULL, NULL, 0);
+ ret = get_dnode_of_data(, end, LOOKUP_NODE_RA);
+ if (ret && ret != -ENOENT) {
+ goto out;
+ } else if (ret == -ENOENT) {
+ new_addr = NULL_ADDR;
+ } else {
+ new_addr = dn.data_blkaddr;
+ truncate_data_blocks_range(, 1);
+ f2fs_put_dnode();
+ }
+
+ if (new_addr == NULL_ADDR) {
+ set_new_dnode(, inode, NULL, NULL, 0);
+ ret = get_dnode_of_data(, start, LOOKUP_NODE_RA);
+ if (ret && ret != -ENOENT)
+ goto out;
+ else if (ret == -ENOENT)
+ continue;
+
+ if (dn.data_blkaddr == NULL_ADDR) {
+ f2fs_put_dnode();
+ continue;
+ } else {
+ truncate_data_blocks_range(, 1);
+ }
+
+ f2fs_put_dnode();
+ } else {
+ struct page *ipage;
+
+ ipage = get_node_page(sbi, inode->i_ino);
+ if (IS_ERR(ipage)) {
+ ret = PTR_ERR(ipage);
+ goto out;
+ }
+
+ set_new_dnode(, inode, ipage, NULL, 0);
+ ret = f2fs_reserve_block(, start);
+ if (ret)
+ goto out;
+
+ old_addr = dn.data_blkaddr;
+ if (old_addr != NEW_ADDR && new_addr == NEW_ADDR) {
+ dn.data_blkaddr = NULL_ADDR;
+ f2fs_update_extent_cache();
+ invalidate_blocks(sbi, old_addr);
+
+ dn.data_blkaddr = new_addr;
+ set_data_blkaddr();
+ } else if (new_addr != NEW_ADDR) {
+ struct node_info ni;
+ struct f2fs_summary sum;
+
+ get_node_info(sbi, dn.nid, );
+ set_summary(, dn.nid, dn.ofs_in_node,
+ ni.version);
+
+ f2fs_replace_block(sbi, , old_addr,
+ new_addr, true);
+
+ dn.data_blkaddr = new_addr;
+ set_data_blkaddr();
+ f2fs_update_extent_cache();
+ }
+
+ f2fs_put_dnode();
+ }
+ }
+ ret = 0;
+out:
+ f2fs_unlock_op(sbi);
+ return ret;
+}
+
+static int f2fs_collapse_range(struct inode *inode, loff_t offset, loff_t len)
+{
+ pgoff_t pg_start, pg_end;
+ loff_t new_size;
+ int ret;
+
+ if (!S_ISREG(inode->i_mode))
+ return -EINVAL;
+
+ if (offset + len >= i_size_read(inode))
+
[PATCH v3 1/3] f2fs: introduce f2fs_replace_block() for reuse
Introduce a generic function replace_block base on recover_data_page,
and export it. So with it we can operate file's meta data which is in
CP/SSA area when we invoke fallocate with FALLOC_FL_COLLAPSE_RANGE
flag.
Signed-off-by: Chao Yu
---
v3:
* rename replace_block() to f2fs_replace_block() for readability.
* fix incorrect usage of @recover_curseg in f2fs_replace_block().
* recover old next blkaddr of current segment for fcollapse.
fs/f2fs/f2fs.h | 4 ++--
fs/f2fs/recovery.c | 2 +-
fs/f2fs/segment.c | 31 ---
3 files changed, 27 insertions(+), 10 deletions(-)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 5fff184..160945f 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1638,8 +1638,8 @@ void write_meta_page(struct f2fs_sb_info *, struct page
*);
void write_node_page(unsigned int, struct f2fs_io_info *);
void write_data_page(struct dnode_of_data *, struct f2fs_io_info *);
void rewrite_data_page(struct f2fs_io_info *);
-void recover_data_page(struct f2fs_sb_info *, struct page *,
- struct f2fs_summary *, block_t, block_t);
+void f2fs_replace_block(struct f2fs_sb_info *, struct f2fs_summary *,
+ block_t, block_t, bool);
void allocate_data_block(struct f2fs_sb_info *, struct page *,
block_t, block_t *, struct f2fs_summary *, int);
void f2fs_wait_on_page_writeback(struct page *, enum page_type);
diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
index b80d9d4..f77a1be 100644
--- a/fs/f2fs/recovery.c
+++ b/fs/f2fs/recovery.c
@@ -412,7 +412,7 @@ static int do_recover_data(struct f2fs_sb_info *sbi, struct
inode *inode,
set_summary(, dn.nid, dn.ofs_in_node, ni.version);
/* write dummy data page */
- recover_data_page(sbi, NULL, , src, dest);
+ f2fs_replace_block(sbi, , src, dest, false);
dn.data_blkaddr = dest;
set_data_blkaddr();
f2fs_update_extent_cache();
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 667bbf2..bdf487a 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -1279,32 +1279,41 @@ void rewrite_data_page(struct f2fs_io_info *fio)
f2fs_submit_page_mbio(fio);
}
-void recover_data_page(struct f2fs_sb_info *sbi,
- struct page *page, struct f2fs_summary *sum,
- block_t old_blkaddr, block_t new_blkaddr)
+void f2fs_replace_block(struct f2fs_sb_info *sbi, struct f2fs_summary *sum,
+ block_t old_blkaddr, block_t new_blkaddr,
+ bool recover_curseg)
{
struct sit_info *sit_i = SIT_I(sbi);
struct curseg_info *curseg;
unsigned int segno, old_cursegno;
struct seg_entry *se;
int type;
+ unsigned short old_blkoff;
segno = GET_SEGNO(sbi, new_blkaddr);
se = get_seg_entry(sbi, segno);
type = se->type;
- if (se->valid_blocks == 0 && !IS_CURSEG(sbi, segno)) {
- if (old_blkaddr == NULL_ADDR)
- type = CURSEG_COLD_DATA;
- else
+ if (!recover_curseg) {
+ /* for recovery flow */
+ if (se->valid_blocks == 0 && !IS_CURSEG(sbi, segno)) {
+ if (old_blkaddr == NULL_ADDR)
+ type = CURSEG_COLD_DATA;
+ else
+ type = CURSEG_WARM_DATA;
+ }
+ } else {
+ if (!IS_CURSEG(sbi, segno))
type = CURSEG_WARM_DATA;
}
+
curseg = CURSEG_I(sbi, type);
mutex_lock(>curseg_mutex);
mutex_lock(_i->sentry_lock);
old_cursegno = curseg->segno;
+ old_blkoff = curseg->next_blkoff;
/* change the current segment */
if (segno != curseg->segno) {
@@ -1318,6 +1327,14 @@ void recover_data_page(struct f2fs_sb_info *sbi,
refresh_sit_entry(sbi, old_blkaddr, new_blkaddr);
locate_dirty_segment(sbi, old_cursegno);
+ if (recover_curseg) {
+ if (old_cursegno != curseg->segno) {
+ curseg->next_segno = old_cursegno;
+ change_curseg(sbi, type, true);
+ }
+ curseg->next_blkoff = old_blkoff;
+ }
+
mutex_unlock(_i->sentry_lock);
mutex_unlock(>curseg_mutex);
}
--
2.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 1/3] f2fs: introduce replace_block() for reuse
Hi Jaegeuk,
Sorry for the delay.
> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Friday, May 01, 2015 2:04 AM
> To: Chao Yu
> Cc: Changman Lee; linux-f2fs-de...@lists.sourceforge.net;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v2 1/3] f2fs: introduce replace_block() for reuse
>
> Hi Chao,
>
> On Thu, Apr 30, 2015 at 06:11:35PM +0800, Chao Yu wrote:
> > Introduce a generic function replace_block base on recover_data_page,
> > and export it. So wit it we can operate file's meta data which is in
> > CP/SSA area when we invoke fallocate with FALLOC_FL_COLLAPSE_RANGE flag.
> >
> > Signed-off-by: Chao Yu
> > ---
> > fs/f2fs/f2fs.h | 4 ++--
> > fs/f2fs/recovery.c | 2 +-
> > fs/f2fs/segment.c | 33 ++---
> > 3 files changed, 29 insertions(+), 10 deletions(-)
> >
> > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> > index 8be6cab..7ab06e8 100644
> > --- a/fs/f2fs/f2fs.h
> > +++ b/fs/f2fs/f2fs.h
> > @@ -1560,8 +1560,8 @@ void write_node_page(struct f2fs_sb_info *, struct
> > page *,
> > void write_data_page(struct page *, struct dnode_of_data *,
> > struct f2fs_io_info *);
> > void rewrite_data_page(struct page *, struct f2fs_io_info *);
> > -void recover_data_page(struct f2fs_sb_info *, struct page *,
> > - struct f2fs_summary *, block_t, block_t);
> > +void replace_block(struct f2fs_sb_info *, struct f2fs_summary *,
> > + block_t, block_t, bool);
> > void allocate_data_block(struct f2fs_sb_info *, struct page *,
> > block_t, block_t *, struct f2fs_summary *, int);
> > void f2fs_wait_on_page_writeback(struct page *, enum page_type);
> > diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
> > index b80d9d4..703ab2f 100644
> > --- a/fs/f2fs/recovery.c
> > +++ b/fs/f2fs/recovery.c
> > @@ -412,7 +412,7 @@ static int do_recover_data(struct f2fs_sb_info *sbi,
> > struct inode *inode,
> > set_summary(, dn.nid, dn.ofs_in_node, ni.version);
> >
> > /* write dummy data page */
> > - recover_data_page(sbi, NULL, , src, dest);
> > + replace_block(sbi, , src, dest, true);
>
> It's a little bit confusing.
> The recover_data_page wants not to recover curseg, right?
>
> So, does it need to call replace_block(.., false);
You're right, my mistake. The following code in this patch should be wrong,
let me fix it as you suggested. Thank you for the review!
Regards,
>
> > dn.data_blkaddr = dest;
> > set_data_blkaddr();
> > f2fs_update_extent_cache();
> > diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> > index f939660..3db92fe 100644
> > --- a/fs/f2fs/segment.c
> > +++ b/fs/f2fs/segment.c
> > @@ -1258,26 +1258,34 @@ void rewrite_data_page(struct page *page, struct
> > f2fs_io_info *fio)
> > f2fs_submit_page_mbio(F2FS_P_SB(page), page, fio);
> > }
> >
> > -void recover_data_page(struct f2fs_sb_info *sbi,
> > - struct page *page, struct f2fs_summary *sum,
> > - block_t old_blkaddr, block_t new_blkaddr)
> > +void replace_block(struct f2fs_sb_info *sbi, struct f2fs_summary *sum,
>
> How about f2fs_replace_block()?
>
> > + block_t old_blkaddr, block_t new_blkaddr,
> > + bool recover_curseg)
> > {
> > struct sit_info *sit_i = SIT_I(sbi);
> > struct curseg_info *curseg;
> > unsigned int segno, old_cursegno;
> > struct seg_entry *se;
> > int type;
> > + unsigned short old_blkoff;
> >
> > segno = GET_SEGNO(sbi, new_blkaddr);
> > se = get_seg_entry(sbi, segno);
> > type = se->type;
> >
> > - if (se->valid_blocks == 0 && !IS_CURSEG(sbi, segno)) {
> > - if (old_blkaddr == NULL_ADDR)
> > - type = CURSEG_COLD_DATA;
> > - else
> > + if (recover_curseg) {
>
> if (!recover_curseg) { ?
>
> > + /* for recovery flow */
> > + if (se->valid_blocks == 0 && !IS_CURSEG(sbi, segno)) {
> > + if (old_blkaddr == NULL_ADDR)
> > + type = CURSEG_COLD_DATA;
> > + else
> > + type = CURSEG_WARM_DATA;
> > + }
> > + } else {
> > + if (!IS_CURSEG(sbi, segno))
> > type = CURSEG_WARM_DATA;
> > }
> > +
> > curseg = CURSEG_I(sbi, type);
> >
> > mutex_lock(>curseg_mutex);
> > @@ -1289,6 +1297,10 @@ void recover_data_page(struct f2fs_sb_info *sbi,
> > if (segno != curseg->segno) {
> > curseg->next_segno = segno;
> > change_curseg(sbi, type, true);
> > + recover_curseg = true;
>
> ^ Why ?
>
> > + } else {
>
> } else if {recover_curseg) {
>
> > + old_blkoff = curseg->next_blkoff;
> > + recover_curseg = false;
Re: [PATCHv4 00/10] add on-demand device creation
Hello Sergey, On Mon, May 04, 2015 at 09:38:52PM +0900, Sergey Senozhatsky wrote: > We currently don't support zram on-demand device creation. The only way > to have N zram devices is to specify num_devices module parameter (default > value 1). That means that if, for some reason, at some point, user wants > to have N + 1 devies he/she must umount all the existing devices, unload > the module, load the module passing num_devices equals to N + 1. > > This patchset introduces zram-control sysfs class, which has two sysfs > attrs: > > - zram_add -- add a new zram device > - zram_remove -- remove a specific (device_id) zram device > > Usage example: > # add a new specific zram device > cat /sys/class/zram-control/zram_add > 1 > > # remove a specific zram device > echo 4 > /sys/class/zram-control/zram_remove I just reported bug. Please handle it. Other nits: 1) How about inserting a step to reset before zram_remove? IOW, user should echo "1" > /sys/block/zram[0-9]*/reset before echo zram_id > /sys/class/zram-control/zram_remove. Actually, I can't think any benefit other than consistency of zram interface but you might have. 2) How about using hot_add/hot_remove? /class/zram-control includes prefix zram meaning so I think we don't need zram prefix of the knobs. Instead, let's add *hot* which is more straightforward for representing *dynamic*. What do you think about it? -- Kind regards, Minchan 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: [RFC PATCH 00/22] perf tools: introduce 'perf bpf' command to load eBPF programs.
On 2015/5/6 12:56, Alexei Starovoitov wrote:
> On 5/5/15 9:46 PM, Wang Nan wrote:
>> Hi Alexei Starovoitov,
>>
>> Have you ever read this mail?
>
> please don't top post.
>
all makes sense and your use case fits quite well into existing
bpf+kprobe model. I'm not sure why you're calling a 'problem'.
A problem of how to display that call stack from perf?
I would say it fits better as a sample than a trace.
If you dump it as a trace, it won't easy to decipher, whereas if you
treat it a sampling event, perf record/report facility will pick it up and
display nicely. Meaning that one sample == lock_page/unlock_page
latency > N. Then existing sample_callchain flag should work.
>>>
>>> Quite well. Do we have an eBPF function like
>>>
>>> static int (*bpf_perf_sample)(const char *fmt, int fmt_size, ...) =
>>> BPF_FUNC_perf_sample
>>>
>>> so we can use it in the program probed in the body of __unlock_page() like
>>> that:
>>>
>>> ...
>>> if (latency > 0.5s)
>>> bpf_perf_sample("page=%p, latency=%d", sizeof(...), page, latency);
>
> No need for extra helper. There is already return value from
> the program for this purpose.
> From kernel/trace/bpf_trace.c:
> * Return: BPF programs always return an integer which is interpreted by
> * kprobe handler as:
> * 0 - return from kprobe (event is filtered out)
> * 1 - store kprobe event into ring buffer
>
> in your case the program attached to unlock_page() can return 1
> when it needs to store this event into ring buffer, so that perf can
> process it. If I'm not mistaken, the sample_callchain flag cannot be
> applied to kprobe events, but that's a general program (not
> related to bpf) and can be addressed as such.
>
That's great! Thanks to your response!
--
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 151/208] x86/fpu: Introduce cpu_has_xfeatures(xfeatures_mask, feature_name)
* Yu, Fenghua wrote:
> > From: Ingo Molnar [mailto:mingo.kernel@gmail.com] On Behalf Of Ingo
> > Molnar
> > Sent: Tuesday, May 05, 2015 10:51 AM
> > To: linux-kernel@vger.kernel.org
> > Cc: Andy Lutomirski; Borislav Petkov; Dave Hansen; Yu, Fenghua; H. Peter
> > Anvin; Linus Torvalds; Oleg Nesterov; Thomas Gleixner
> > Subject: [PATCH 151/208] x86/fpu: Introduce
> > cpu_has_xfeatures(xfeatures_mask, feature_name)
> >
> > A lot of FPU using driver code is querying complex CPU features to be able
> > to
> > figure out whether a given set of xstate features is supported by the CPU or
> > not.
> >
> > Introduce a simplified API function that can be used on any CPU type to get
> > this information. Also add an error string return pointer, so that the
> > driver
> > can print a meaningful error message with a standardized feature name.
> >
> > Also mark xfeatures_mask as __read_only.
> >
> > Cc: Andy Lutomirski
> > Cc: Borislav Petkov
> > Cc: Dave Hansen
> > Cc: Fenghua Yu
> > Cc: H. Peter Anvin
> > Cc: Linus Torvalds
> > Cc: Oleg Nesterov
> > Cc: Thomas Gleixner
> > Signed-off-by: Ingo Molnar
> > ---
> > arch/x86/include/asm/fpu/api.h | 9 +
> > arch/x86/kernel/fpu/xstate.c | 53
> > -
> > 2 files changed, 61 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/include/asm/fpu/api.h
> > b/arch/x86/include/asm/fpu/api.h index 62035cc1d961..1429a7c736db
> > 100644
> > --- a/arch/x86/include/asm/fpu/api.h
> > +++ b/arch/x86/include/asm/fpu/api.h
> > @@ -36,4 +36,13 @@ extern bool irq_fpu_usable(void); extern int
> > irq_ts_save(void); extern void irq_ts_restore(int TS_state);
> >
> > +/*
> > + * Query the presence of one or more xfeatures. Works on any legacy CPU
> > as well.
> > + *
> > + * If 'feature_name' is set then put a human-readable description of
> > + * the feature there as well - this can be used to print error (or
> > +success)
> > + * messages.
> > + */
> > +extern int cpu_has_xfeatures(u64 xfeatures_mask, const char
> > +**feature_name);
> > +
> > #endif /* _ASM_X86_FPU_API_H */
> > diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
> > index f549e2a44336..2e52f01f4931 100644
> > --- a/arch/x86/kernel/fpu/xstate.c
> > +++ b/arch/x86/kernel/fpu/xstate.c
> > @@ -11,10 +11,23 @@
> > #include
> > #include
> >
> > +static const char *xfeature_names[] =
> > +{
> > + "x87 floating point registers" ,
> > + "SSE registers" ,
> > + "AVX registers" ,
> > + "MPX bounds registers" ,
> > + "MPX CSR" ,
> > + "AVX-512 opmask",
> > + "AVX-512 Hi256" ,
> > + "AVX-512 ZMM_Hi256" ,
> > + "unknown xstate feature",
> > +};
> > +
> > /*
> > * Mask of xstate features supported by the CPU and the kernel:
> > */
> > -u64 xfeatures_mask;
> > +u64 xfeatures_mask __read_mostly;
> >
> > /*
> > * Represents init state for the supported extended state.
> > @@ -29,6 +42,44 @@ static unsigned int
> > xstate_comp_offsets[sizeof(xfeatures_mask)*8];
> > static unsigned int xfeatures_nr;
> >
> > /*
> > + * Return whether the system supports a given xfeature.
> > + *
> > + * Also return the name of the (most advanced) feature that the caller
> > requested:
> > + */
> > +int cpu_has_xfeatures(u64 xfeatures_needed, const char **feature_name)
> > +{
> > + u64 xfeatures_missing = xfeatures_needed & ~xfeatures_mask;
> > +
> > + if (unlikely(feature_name)) {
> > + long xfeature_idx, max_idx;
> > + u64 xfeatures_print;
> > + /*
> > +* So we use FLS here to be able to print the most advanced
> > +* feature that was requested but is missing. So if a driver
> > +* asks about "XSTATE_SSE | XSTATE_YMM" we'll print the
> > +* missing AVX feature - this is the most informative message
> > +* to users:
> > +*/
> > + if (xfeatures_missing)
> > + xfeatures_print = xfeatures_missing;
>
> If the feature is missing (xfeatures_missing!=0), the xfeature_name
> will point to the next feature name with the higher idx in
> xfeatures_mask. Is that supposed to be?
Yes, so this is a reporting detail. The intention here is the
following: when a driver requests multiple features to be present, for
example:
if (!cpu_has_xfeatures(XSTATE_SSE | XSTATE_YMM, NULL)) {
then it makes sense to report the highest feature bit, not the first
one we find to not exist. Why? Because in the above example, on an old
CPU we could miss on XSTATE_SSE already, and report that to the user -
which creates the incorrect assumption that the minimum requirement is
for SSE. The user then tries the same driver on a more modern system,
which has SSE but not YMM, and gets a shifting goal post.
So I wanted to report the most modern feature that is missing, to
avoid such kind of
Re: [PATCH 2/2] adm8211: fix the possible pci cache line sizes inside switch-case
Okash Khawaja writes: > The PCI cache line size value was being compared against decimal values > prefixed with 0x. > > Fixed the literals to use the correct hex values. > > > Signed-off-by: Okash Khawaja [...] > @@ -1101,10 +1101,10 @@ static void adm8211_hw_init(struct ieee80211_hw *dev) > case 0x8: > reg |= (0x1 << 14); > break; > - case 0x16: > + case 0x10: > reg |= (0x2 << 14); > break; > - case 0x32: > + case 0x20: > reg |= (0x3 << 14); > break; > default: Did you test this? How certain can we be that this doesn't break anything? -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 00/22] perf tools: introduce 'perf bpf' command to load eBPF programs.
On 5/5/15 9:46 PM, Wang Nan wrote:
Hi Alexei Starovoitov,
Have you ever read this mail?
please don't top post.
all makes sense and your use case fits quite well into existing
bpf+kprobe model. I'm not sure why you're calling a 'problem'.
A problem of how to display that call stack from perf?
I would say it fits better as a sample than a trace.
If you dump it as a trace, it won't easy to decipher, whereas if you
treat it a sampling event, perf record/report facility will pick it up and
display nicely. Meaning that one sample == lock_page/unlock_page
latency > N. Then existing sample_callchain flag should work.
Quite well. Do we have an eBPF function like
static int (*bpf_perf_sample)(const char *fmt, int fmt_size, ...) =
BPF_FUNC_perf_sample
so we can use it in the program probed in the body of __unlock_page() like that:
...
if (latency > 0.5s)
bpf_perf_sample("page=%p, latency=%d", sizeof(...), page, latency);
No need for extra helper. There is already return value from
the program for this purpose.
From kernel/trace/bpf_trace.c:
* Return: BPF programs always return an integer which is interpreted by
* kprobe handler as:
* 0 - return from kprobe (event is filtered out)
* 1 - store kprobe event into ring buffer
in your case the program attached to unlock_page() can return 1
when it needs to store this event into ring buffer, so that perf can
process it. If I'm not mistaken, the sample_callchain flag cannot be
applied to kprobe events, but that's a general program (not
related to bpf) and can be addressed as such.
--
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 201/208] x86/fpu: Clean up xstate feature reservation
* Dave Hansen wrote:
> On 05/05/2015 10:58 AM, Ingo Molnar wrote:
> > struct xregs_state {
> > struct fxregs_state i387;
> > struct xstate_headerheader;
> > - struct ymmh_struct ymmh;
> > - struct lwp_struct lwp;
> > - struct bndreg bndreg[4];
> > - struct bndcsr bndcsr;
> > - /* New processor state extensions will go here. */
> > + u8 __reserved[XSTATE_RESERVE];
> > } __attribute__ ((packed, aligned (64)));
>
> Just to reiterate. The size of 'XSTATE_RESERVE' is completely
> unknown at compile time. [...]
Yes, see my previous mail.
> [...] It's wrong in the existing kernel, but we should fix it up
> instead of mucking with it like this.
I'm not mucking with it, I'm slowly migrating it towards a dynamic
model that doesn't suck - see my other mails.
Thanks,
Ingo
--
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 207/208] x86/fpu: Add FPU performance measurement subsystem
* Andy Lutomirski wrote: > On May 5, 2015 11:30 PM, "Ingo Molnar" wrote: > > > > Add a short FPU performance suite that runs once during bootup. > > > > It can be enabled via CONFIG_X86_DEBUG_FPU_PERFORMANCE=y. > > Neat! > > Can you change "cycles" to "TSC ticks"? They're not quite the same thing. Yeah, with constant TSC we have the magic TSC frequency that is used by RDTSC. I'm torn: 'TSC ticks' will mean very little to most people reading that output. We could convert it to nsecs with a little bit of calibration - but that makes it depend on small differences in CPU model frequencies, while the (cached) cycle costs are typically constant per microarchitecture. I suspect we could snatch a performance counter temporarily, to get the real cycles count, and maybe even add a uops column. Most of this needs to run in kernel space, so it's not a tooling project. I also wanted to add cache-cold numbers which are very interesting as well, just awfully hard to measure in a stable fashion. For cache-cold numbers the natural unit would be memory bus cycles. Thanks, Ingo -- 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: [Celinux-dev] Invitation and RFC: Linux Plumbers Device Tree track proposed
On Mon, May 04, 2015 at 06:20:35PM -0500, Rob Herring wrote: > On Fri, May 1, 2015 at 4:22 PM, Rob Landley wrote: > > On 04/11/2015 02:20 PM, Rowand, Frank wrote: > >> In recent years there have been proposed tools to aid in the creation of > >> valid > >> device trees and in debugging device tree issues. An example of this is > >> the > >> various approaches proposed (with source code provided) to validate device > >> tree > >> source against valid bindings. As of today, device tree related tools, > >> techniques, and debugging infrastructure have not progressed very far. I > >> have > >> submitted a device tree related proposal for the Linux Plumbers 2015 > >> conference > >> to spur action and innovation in such tools, techniques, and debugging > >> infrastructure. > >> > >> The current title of the track is "Device Tree Tools, Validation, and > >> Troubleshooting". The proposal is located at > >> > >> > >> http://wiki.linuxplumbersconf.org/2015:device_tree_tools_validation_and_trouble_shooting > > > > Want I want to do is: > > > > 1) Download an archive of device tree files describing a bunch of > > boards. (Both dts and corresponding dtb files, with maybe a .txt telling > > me about the board and the -append line qemu needs to give it any > > board-specific kernel command line stuff like "console=myserialport".) > > The dts half is here[1]. It is a kernel repository automatically > stripped of everything but dts files. > > > 2) Feed one of the dtb files to qemu to instantiate a bunch of devices. > > I'd like this too. The QEMU maintainers don't really agree. I think > the ARM virt platform is the wrong way around with QEMU generating the > DT. There was a patch series to allow sysbus devices to be created on > the command line like you can with PCI. This would have allowed a > front end script to generate a QEMU command line from a DT. I'm not > sure if it ever got in. I suggested something like this several years ago to Anthony Liguori who didn't much like it. However qemu has changed a fair bit since then, so it might be worth revisiting. It's a big job though - lots of integration work with qemu's configuration core. In particular allowing this without breaking migrations or the various qapis is not straightforward. > It would lower the bar to adding new platforms to just writing models > for blocks perhaps. I'm not sure there's enough interest. The number > of ARM platforms supported in QEMU is much less than the kernel. I havea presentation proposal for KVM Forum covering some ideas which could be at least first steps towards doing this. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson pgpL6z_QYvE4r.pgp Description: PGP signature
Re: + zram-add-dynamic-device-add-remove-functionality.patch added to -mm tree
ram5: detected capacity change from 0 to 20971520 [ 98.507491] zram: Added device: zram6 [ 98.508370] zram6: detected capacity change from 0 to 20971520 [ 98.518639] zram: Added device: zram7 [ 98.519697] zram7: detected capacity change from 0 to 20971520 [ 98.522650] zram: Added device: zram8 [ 98.523507] zram8: detected capacity change from 0 to 20971520 [ 98.525985] zram: Added device: zram9 [ 98.527046] zram9: detected capacity change from 0 to 20971520 [ 98.531154] zram: Added device: zram10 [ 98.532390] zram10: detected capacity change from 0 to 20971520 [ 98.535335] zram: Added device: zram11 [ 98.536179] zram11: detected capacity change from 0 to 20971520 [ 98.538633] zram: Added device: zram12 [ 98.539812] zram12: detected capacity change from 0 to 20971520 [ 98.545105] zram: Added device: zram13 [ 98.546696] zram13: detected capacity change from 0 to 20971520 [ 98.550453] zram: Added device: zram14 [ 98.551394] zram14: detected capacity change from 0 to 20971520 [ 98.556193] zram: Added device: zram15 [ 98.557564] zram15: detected capacity change from 0 to 20971520 [ 98.561741] zram: Added device: zram16 [ 98.562799] zram16: detected capacity change from 0 to 20971520 [ 98.565537] zram: Added device: zram17 [ 98.566344] zram17: detected capacity change from 0 to 20971520 [ 98.569192] zram: Added device: zram18 [ 98.570437] zram18: detected capacity change from 0 to 20971520 [ 98.573588] zram: Added device: zram19 [ 98.574826] zram19: detected capacity change from 0 to 20971520 [ 98.578450] zram: Added device: zram20 [ 98.579623] zram20: detected capacity change from 0 to 20971520 [ 98.582528] zram: Added device: zram21 [ 98.584440] zram21: detected capacity change from 0 to 20971520 [ 98.587922] zram: Added device: zram22 [ 98.589239] zram22: detected capacity change from 0 to 20971520 [ 98.593854] zram: Added device: zram23 [ 98.595130] zram23: detected capacity change from 0 to 20971520 [ 98.598610] zram: Added device: zram24 [ 98.599953] zram24: detected capacity change from 0 to 20971520 [ 98.603456] zram: Added device: zram25 [ 98.604706] zram25: detected capacity change from 0 to 20971520 [ 98.631424] zram: Removed device: zram11 [ 98.639214] zram: Removed device: zram14 [ 98.647116] zram: Removed device: zram15 [ 98.756017] zram: Removed device: zram2 [ 98.757087] [ cut here ] [ 98.758349] WARNING: CPU: 5 PID: 2952 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x68/0x80() [ 98.760065] sysfs: cannot create duplicate filename '/devices/virtual/bdi/252:2' [ 98.761061] Modules linked in: [ 98.761530] CPU: 5 PID: 2952 Comm: cat Not tainted 4.1.0-rc2-next-20150505+ #1260 [ 98.762682] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 [ 98.764140] 88005d40f948 88005d40f948 8163d8d8 [ 98.765614] 88005d40f998 88005d40f988 8105f02a [ 98.766815] 8800653c2000 88007f526210 88004b3aa1c8 880065799360 [ 98.768980] Call Trace: [ 98.769643] [] dump_stack+0x4c/0x65 [ 98.770431] [] warn_slowpath_common+0x8a/0xc0 [ 98.771353] [] warn_slowpath_fmt+0x46/0x50 [ 98.772220] [] ? warn_slowpath_fmt+0x5/0x50 [ 98.773099] [] sysfs_warn_dup+0x68/0x80 [ 98.773903] [] ? sysfs_warn_dup+0x5/0x80 [ 98.774750] [] sysfs_create_dir_ns+0x8e/0xa0 [ 98.775794] [] ? sysfs_create_dir_ns+0x5/0xa0 [ 98.776672] [] kobject_add_internal+0xa5/0x2f0 [ 98.37] [] ? __mutex_unlock_slowpath+0xb3/0x180 [ 98.778765] [] kobject_add+0x60/0xb0 [ 98.779598] [] ? get_device_parent+0x5/0x200 [ 98.780430] [] device_add+0x102/0x5b0 [ 98.780956] [] ? device_add+0x5/0x5b0 [ 98.781513] [] device_create_groups_vargs+0xd8/0x100 [ 98.782119] [] ? device_create_vargs+0x5/0x20 [ 98.782851] [] device_create_vargs+0x1c/0x20 [ 98.783464] [] bdi_register+0x67/0x2a0 [ 98.784081] [] ? bdi_register_dev+0x5/0x30 [ 98.784609] [] bdi_register_dev+0x27/0x30 [ 98.785139] [] add_disk+0x1b9/0x4e0 [ 98.785844] [] ? snprintf+0x34/0x40 [ 98.786353] [] zram_add+0x1ec/0x2f0 [ 98.786833] [] zram_add_show+0x22/0x60 [ 98.787344] [] class_attr_show+0x1b/0x30 [ 98.787848] [] sysfs_kf_seq_show+0xcf/0x1d0 [ 98.788374] [] kernfs_seq_show+0x26/0x30 [ 98.70] [] seq_read+0xf5/0x3a0 [ 98.789338] [] ? kernfs_vma_page_mkwrite+0xa0/0xa0 [ 98.789917] [] kernfs_fop_read+0x125/0x180 [ 98.790483] [] __vfs_read+0x28/0xe0 [ 98.790959] [] ? __vfs_read+0x5/0xe0 [ 98.791476] [] ? __vfs_read+0x5/0xe0 [ 98.791952] [] vfs_read+0x86/0x140 [ 98.792418] [] ? __fdget_pos+0x17/0x50 [ 98.792908] [] SyS_read+0x49/0xb0 [ 98.793360] [] system_call_fastpath+0x12/0x6f [ 98.793903] ---[ end trace e1035d8c51ec986c ]--- [ 98.794358] [ cut here ] [ 98.794783] WARNING: CPU: 5 PID: 2952 at lib/kobject.c:240 kobject_add_internal+0x284/0x2f0()
Re: [RFC PATCH 00/22] perf tools: introduce 'perf bpf' command to load eBPF programs.
Hi Alexei Starovoitov,
Have you ever read this mail?
I'm very intrerested in triggering perf sample in BPF code.
You said it is not a problem. Could you please give me some
further information?
Thank you.
On 2015/5/5 14:14, Wang Nan wrote:
> On 2015/5/5 13:49, Alexei Starovoitov wrote:
>> On 5/4/15 9:41 PM, Wang Nan wrote:
>>>
>>> That's great. Could you please append the description of 'llvm -s' into
>>> your README
>>> or comments? It has cost me a lot of time for dumping eBPF instructions so
>>> I decide to
>>> add it into perf...
>>
>> sure. it's just -filetype=asm flag to llc instead of -filetype=obj.
>> Eventually it will work as normal 'clang -S file.c' when few more
>> llvm commits are accepted upstream.
>>
> My collage He Kuang is working on variable accessing. Probing inside
> function body
> and accessing its local variable will be supported like this:
>
>SEC("config") char _prog_config[] = "prog: func_name:1234
> vara=localvara"
>int prog(struct pt_regs *ctx, unsigned long vara) {
> // vara is the value of localvara of function func_name
>}
that would be great. I'm not sure though how you can achieve that
without changing C front-end ?
>>>
>>> It's not very difficult. He is trying to generate the loader of vara
>>> as prologue, then paste the prologue and the main eBPF program together.
>>> From the viewpoint of kernel bpf verifier, there is only one param (ctx);
>>> the
>>> prologue program fetches the value of vara then put it into a propoer
>>> register,
>>> then main program work.
>>
>> got it. I think that's much cleaner than what I was proposing.
>> The only question is then:
>> char _prog_config[] = "prog: func_name:1234 vara=localvara"
>> should actually be something like "... r2=localvara", right?
>> since prologue would need to assign into r2.
>> Otherwise I don't see where you find out about 'vara' inside
>> compiled bpf code.
>>
>
> I think the calling convention could teach us which var should go to which
> register. In the case of
>
> SEC("config") char _prog_config[] = "prog: func_name:1234 vara=localvara
> varb=globalvarb";
> int prog(struct pt_regs *ctx, unsigned long vara, unsigned long varb) { ... }
>
> llvm should compile 'prog' according to calling convention. The body of that
> program should assume vara in r2 and varb in r3. The prologue also puts the
> vars into
> r2 and r3 according to calling convention. Therefore, after paste them
> together, the final
> program should run properly. There is no need to describe register number
> explicitly.
> What do you think?
>
>
>> Would be nice if this can be done without debug info.
>> Like in tracex2_kern.c I have:
>> SEC("kprobe/sys_write")
>> int bpf_prog(struct pt_regs *ctx)
>> {
>> long wr_size = ctx->dx; /* arg3 */
>>
>> with your prolog generator the above can be rewritten as:
>> SEC("kprobe/sys_write")
>> int bpf_prog(struct pt_regs *unused, int fd, char *buf, size_t wr_size)
>> {
>> /* use wr_size */
>>
>> that will improve ease of use a lot.
>>
>
> It is possible if probing on the entry of a function. However, when probing on
> function body, there still need a way to pass variable list required by the
> program to perf to let it generate correct prologue. We'd like to implement
> the generic one (list vars in config string) first, then make function
> parameters accessing as a syntax sugar.
>
>>> Another possible solution is to change the protocol between kprobe and eBPF
>>> program, makes kprobes calls fetchers and passes them to eBPF program as
>>> a second param (group all varx together).
>>> A prologue may still need in this case to load each param into correct
>>> register.
>>
>> you mean grouping varx together in some other struct and embedding it
>> together with pt_regs into new container struct?
>> doable, but your first approach is quite clean already. why bother.
>>
>
> The second approach makes us reuse the fetchers code which are already in
> kernel. Further more, if new type of fetchers are appear (for example, fetcher
> of PMU counter), we support it automatically.
>
>>> Could you please consider the following problem?
>>>
>>> We find there are serval __lock_page() calls last very long time. We are
>>> going
>>> to find corresponding __unlock_page() so we can know what blocks them. We
>>> want to
>>> insert eBPF programs before io_schedule() in __lock_page(), and also add
>>> eBPF program
>>> on the entry of __unlock_page(), so we can compute the interval between
>>> page locking and
>>> unlocking. If time is longer than a threshold, let __unlock_page() trigger
>>> a perf sampling
>>> so we get its call stack. In this case, eBPF program acts as a trace filter.
>>
>> all makes sense and your use case fits quite well into existing
>> bpf+kprobe model. I'm not sure why you're calling a 'problem'.
>> A problem of how to display that call stack from perf?
>> I would say it fits better as a
Re: [PATCH 1/2] percpu_counter: batch size aware __percpu_counter_compare()
On Tue, May 05, 2015 at 09:36:36PM -0700, Christoph Hellwig wrote: > This looks reasonable, but I miss Ccs to the authors of the > percpu_counter code and linux-kernel. Ok, saw it on lkml. Guess I need more coffee, sorry.. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/6] perf bpf: Probing with local variable
On 2015/5/6 12:10, Alexei Starovoitov wrote:
> On 5/5/15 8:58 PM, Wang Nan wrote:
>>> Two high level comments:
>>> - can you collapse SEC("config") with SEC("func_name") ?
>>> It seems that "func_name" is only used as reference inside "config".
>>> I understand that you're proposing one "config" section where multiple
>>> descriptions are strcat together, but why? Something like:
>>> SEC("kprobe/generic_perform_write+122(file->f_mapping->a_ops, bytes,
>>> offset)")
>>> int func(...) { ... }
>>> should be enough and more concise.
>>>
>>
>> Is it possible to use such a long section name? I introduce 'config' section
>
> yes. of course. I don't know what is the limit, but it's definitely
> above 512 characters. It can contains spaces and special chars too.
>
Good. Let's get rid of config section.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build warning after merge of the clk tree
On 05/06, Stephen Rothwell wrote:
> Hi all,
>
> After merging the clk tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> drivers/clk/clk.c:2231:13: warning: 'clk_is_orphan' defined but not used
> [-Wunused-function]
> static bool clk_is_orphan(const struct clk *clk)
> ^
>
> Introduced by commit ece3ffbe1b7b ("clk: prevent orphan clocks from
> being used").
>
> CONFIG_OF is not set for this build ...
Thanks for the report. kbuild robot also reported this problem
the other day. We came up with a way to not have this function at
all though so this problem should go away tomorrow.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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] xfs: inode counter needs to use __percpu_counter_compare
> diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c
> index 02f827f..900f8ce 100644
> --- a/fs/xfs/xfs_mount.c
> +++ b/fs/xfs/xfs_mount.c
> @@ -1106,8 +1106,9 @@ xfs_mod_icount(
> int64_t delta)
> {
> /* deltas are +/-64, hence the large batch size of 128. */
> - __percpu_counter_add(>m_icount, delta, 128);
> - if (percpu_counter_compare(>m_icount, 0) < 0) {
> +#define _ICOUNT_BATCH128
> + __percpu_counter_add(>m_icount, delta, _ICOUNT_BATCH);
Can you give XFS_ prefixes to the atch sizes and move them otuside the
function? And fix up the instance in xfs_mod_fdblocks as well while
you're at it.
Otherwise looks fine.
--
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/
[tip:perf/urgent] perf probe: Fix segfault if passed with ''.
Commit-ID: e59d29e88f7b7e3d1231202b0203d0af6f15a440
Gitweb: http://git.kernel.org/tip/e59d29e88f7b7e3d1231202b0203d0af6f15a440
Author: Wang Nan
AuthorDate: Tue, 28 Apr 2015 08:46:09 +
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 5 May 2015 12:26:52 -0300
perf probe: Fix segfault if passed with ''.
Since parse_perf_probe_point() deals with a user passed argument, we
should not assume it to be a valid string.
Without this patch, if pass '' to perf probe, a segfault raises:
$ perf probe -a ''
Segmentation fault
This patch checks argument of parse_perf_probe_point() before
string processing.
After this patch:
$ perf probe -a ''
usage: perf probe [] 'PROBEDEF' ['PROBEDEF' ...]
or: perf probe [] --add 'PROBEDEF' [--add 'PROBEDEF' ...]
...
Signed-off-by: Wang Nan
Acked-by: Masami Hiramatsu
Tested-by: Arnaldo Carvalho de Melo
Cc: David Ahern
Cc: Jiri Olsa
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Zefan Li
Link:
http://lkml.kernel.org/r/1430210769-94177-1-git-send-email-wangn...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/probe-event.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index d8bb616..d05b77c 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -1084,6 +1084,8 @@ static int parse_perf_probe_point(char *arg, struct
perf_probe_event *pev)
*
* TODO:Group name support
*/
+ if (!arg)
+ return -EINVAL;
ptr = strpbrk(arg, ";=@+%");
if (ptr && *ptr == '=') { /* Event 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/
[tip:perf/urgent] perf report: Fix -T/ --threads option to work again
Commit-ID: e944ec2ca00fb0170ba9d7f2aeec32c22dc0d4ec
Gitweb: http://git.kernel.org/tip/e944ec2ca00fb0170ba9d7f2aeec32c22dc0d4ec
Author: Namhyung Kim
AuthorDate: Wed, 29 Apr 2015 21:08:48 +0900
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 1 May 2015 10:13:30 -0300
perf report: Fix -T/--threads option to work again
The commit 512ae1bd6acb ("perf tools: Consolidate management of default
sort orders") changed default value of the 'sort_order' variable to NULL
indicating that users don't set any sort keys on the command line.
However it missed to update a check in perf_evlist__tty_browse_hists()
so that 'perf report -T' cannot show the per-thread values after the
normal output. This patch fixes it to work again.
Note that the -T option only works on --stdio and neither --sort nor
--parent option was given.
Signed-off-by: Namhyung Kim
Cc: Andi Kleen
Cc: David Ahern
Cc: Jiri Olsa
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1430309328-28317-1-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-report.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 476cdf7..b63aeda 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -329,7 +329,7 @@ static int perf_evlist__tty_browse_hists(struct perf_evlist
*evlist,
fprintf(stdout, "\n\n");
}
- if (sort_order == default_sort_order &&
+ if (sort_order == NULL &&
parent_pattern == default_parent_pattern) {
fprintf(stdout, "#\n# (%s)\n#\n", help);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] percpu_counter: batch size aware __percpu_counter_compare()
This looks reasonable, but I miss Ccs to the authors of the percpu_counter code and linux-kernel. On Wed, May 06, 2015 at 08:01:38AM +1000, Dave Chinner wrote: > From: Dave Chinner > > From: Dave Chinner And this looks wrong, too :) -- 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] splice: sendfile() at once fails for big files
On Tue, May 05, 2015 at 08:41:05PM -0700, Linus Torvalds wrote: > Jens, ping? > > The test results should make this a no-brainer, but I hate how random > these flag ops. Not Jens here, but: (a) the patch looks correct, we do want to set the more flag if there is more data (b) I think the AF_ALG model is totally broken if it relies on that for data integrity purposes. -- 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/
linux-next: Tree for May 6
Hi all, Changes since 20150505: *crickets* Non-merge commits (relative to Linus' tree): 1948 2013 files changed, 98027 insertions(+), 40252 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 214 trees (counting Linus' and 30 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (d9cee5d4f66e Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6) Merging fixes/master (b94d525e58dc Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging kbuild-current/rc-fixes (c517d838eb7d Linux 4.0-rc1) Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify) Merging arm-current/fixes (3b8786ff7a1b ARM: 8352/1: perf: Fix the pmu node name in warning message) Merging m68k-current/for-linus (b24f670b7f5b m68k/mac: Fix out-of-bounds array index in OSS IRQ source initialization) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-merge-mpe/fixes (0aab3747091d powerpc/powernv: Restore non-volatile CRs after nap) Merging powerpc-merge/merge (c517d838eb7d Linux 4.0-rc1) Merging sparc/master (acc455cffa75 sparc64: Setup sysfs to mark LDOM sockets, cores and threads correctly) Merging net/master (31ccd0e66d41 tcp_westwood: fix tcp_westwood_info()) Merging ipsec/master (bdddbf6996c0 xfrm: fix a race in xfrm_state_lookup_byspi) Merging sound-current/for-linus (2c674fac5b16 ALSA: hda/realtek - Add ALC298 alias name for Dell) Merging pci-current/for-linus (5ebe6afaf005 Linux 4.1-rc2) Merging wireless-drivers/master (f67382186489 ath9k: fix per-packet tx power configuration) Merging driver-core.current/driver-core-linus (b787f68c36d4 Linux 4.1-rc1) Merging tty.current/tty-linus (96a5d18bc133 serial: 8250_pci: Add support for 16 port Exar boards) Merging usb.current/usb-linus (0d3bba0287d4 cdc-acm: prevent infinite loop when parsing CDC headers.) Merging usb-gadget-fixes/fixes (c94e289f195e usb: gadget: remove incorrect __init/__exit annotations) Merging usb-serial-fixes/usb-linus (82ee3aeb9295 USB: visor: Match I330 phone more precisely) Merging staging.current/staging-linus (b787f68c36d4 Linux 4.1-rc1) Merging char-misc.current/char-misc-linus (f26443a8ab76 Merge tag 'extcon-fixes-for-4.1-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon into char-misc-linus) Merging input-current/for-linus (48853389f206 Merge branch 'next' into for-linus) Merging crypto-current/master (f440c4ee3e53 hwrng: bcm63xx - Fix driver compilation) Merging ide/master (d681f1166919 ide: remove deprecated use of pci api) Merging devicetree-current/devicetree/merge (41d9489319f2 drivers/of: Add empty ranges quirk for PA-Semi) Merging rr-fixes/fixes (f47689345931 lguest: update help text.) Merging vfio-fixes/for-linus (db7d4d7f4021 vfio: Fix runaway interruptible timeout) Merging kselftest-fixes/fixes (b787f68c36d4 Linux 4.1-rc1) Merging drm-intel-fixes/for-linux-next-fixes (3916e3fd8102 drm/i915: Add missing MacBook Pro models with dual channel LVDS) Merging asm-generic/master (643165c8bbc8 Merge tag 'uaccess_for_upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost into asm-generic) Merging arc/for-next (b787f68c36d4 Linux 4.1-rc1) Merging arm/for-next (3b8786ff7a1b ARM: 8352/1: perf: Fix the pmu node name in warning message) Merging arm-perf/for-next/perf (b787f68c36d4 Linux 4.1-rc1) Merg
[PATCH v3 2/7] block: loop: don't hold lo_ctl_mutex in lo_open
The lo_ctl_mutex is held for running all ioctl handlers, and
in some ioctl handlers, ioctl_by_bdev(BLKRRPART) is called for
rereading partitions, which requires bd_mutex.
So it is easy to cause failure because trylock(bd_mutex) may
fail inside blkdev_reread_part(), and follows the lock context:
blkid or other application:
->open()
->mutex_lock(bd_mutex)
->lo_open()
->mutex_lock(lo_ctl_mutex)
losetup(set fd ioctl):
->mutex_lock(lo_ctl_mutex)
->ioctl_by_bdev(BLKRRPART)
->trylock(bd_mutex)
This patch trys to eliminate the ABBA lock dependency by removing
lo_ctl_mutext in lo_open() with the following approach:
1) make lo_refcnt as atomic_t and avoid acquiring lo_ctl_mutex in lo_open():
- for open vs. add/del loop, no any problem because of loop_index_mutex
- freeze request queue during clr_fd, so I/O can't come until
clearing fd is completed, like the effect of holding lo_ctl_mutex
in lo_open
- both open() and release() have been serialized by bd_mutex already
2) don't hold lo_ctl_mutex for decreasing/checking lo_refcnt in
lo_release(), then lo_ctl_mutex is only required for the last release.
Reviewed-by: Christoph Hellwig
Tested-by: Jarod Wilson
Acked-by: Jarod Wilson
Signed-off-by: Ming Lei
---
drivers/block/loop.c | 21 -
drivers/block/loop.h | 2 +-
2 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 1bee523..b3e294e 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -831,7 +831,7 @@ static int loop_clr_fd(struct loop_device *lo)
* /do something like mkfs/losetup -d causing the losetup -d
* command to fail with EBUSY.
*/
- if (lo->lo_refcnt > 1) {
+ if (atomic_read(>lo_refcnt) > 1) {
lo->lo_flags |= LO_FLAGS_AUTOCLEAR;
mutex_unlock(>lo_ctl_mutex);
return 0;
@@ -840,6 +840,9 @@ static int loop_clr_fd(struct loop_device *lo)
if (filp == NULL)
return -EINVAL;
+ /* freeze request queue during the transition */
+ blk_mq_freeze_queue(lo->lo_queue);
+
spin_lock_irq(>lo_lock);
lo->lo_state = Lo_rundown;
lo->lo_backing_file = NULL;
@@ -871,6 +874,8 @@ static int loop_clr_fd(struct loop_device *lo)
lo->lo_state = Lo_unbound;
/* This is safe: open() is still holding a reference. */
module_put(THIS_MODULE);
+ blk_mq_unfreeze_queue(lo->lo_queue);
+
if (lo->lo_flags & LO_FLAGS_PARTSCAN && bdev)
ioctl_by_bdev(bdev, BLKRRPART, 0);
lo->lo_flags = 0;
@@ -1330,9 +1335,7 @@ static int lo_open(struct block_device *bdev, fmode_t
mode)
goto out;
}
- mutex_lock(>lo_ctl_mutex);
- lo->lo_refcnt++;
- mutex_unlock(>lo_ctl_mutex);
+ atomic_inc(>lo_refcnt);
out:
mutex_unlock(_index_mutex);
return err;
@@ -1343,11 +1346,10 @@ static void lo_release(struct gendisk *disk, fmode_t
mode)
struct loop_device *lo = disk->private_data;
int err;
- mutex_lock(>lo_ctl_mutex);
-
- if (--lo->lo_refcnt)
- goto out;
+ if (atomic_dec_return(>lo_refcnt))
+ return;
+ mutex_lock(>lo_ctl_mutex);
if (lo->lo_flags & LO_FLAGS_AUTOCLEAR) {
/*
* In autoclear mode, stop the loop thread
@@ -1601,6 +1603,7 @@ static int loop_add(struct loop_device **l, int i)
disk->flags |= GENHD_FL_NO_PART_SCAN;
disk->flags |= GENHD_FL_EXT_DEVT;
mutex_init(>lo_ctl_mutex);
+ atomic_set(>lo_refcnt, 0);
lo->lo_number = i;
spin_lock_init(>lo_lock);
disk->major = LOOP_MAJOR;
@@ -1718,7 +1721,7 @@ static long loop_control_ioctl(struct file *file,
unsigned int cmd,
mutex_unlock(>lo_ctl_mutex);
break;
}
- if (lo->lo_refcnt > 0) {
+ if (atomic_read(>lo_refcnt) > 0) {
ret = -EBUSY;
mutex_unlock(>lo_ctl_mutex);
break;
diff --git a/drivers/block/loop.h b/drivers/block/loop.h
index 49564ed..25e8997 100644
--- a/drivers/block/loop.h
+++ b/drivers/block/loop.h
@@ -28,7 +28,7 @@ struct loop_func_table;
struct loop_device {
int lo_number;
- int lo_refcnt;
+ atomic_tlo_refcnt;
loff_t lo_offset;
loff_t lo_sizelimit;
int lo_flags;
--
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/
[PATCH v3 5/7] block: dasd_genhd: convert to blkdev_reread_part
Also remove the obsolete comment.
Reviewed-by: Christoph Hellwig
Tested-by: Jarod Wilson
Acked-by: Jarod Wilson
Acked-by: Sebastian Ott
Signed-off-by: Ming Lei
---
drivers/s390/block/dasd_genhd.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/s390/block/dasd_genhd.c b/drivers/s390/block/dasd_genhd.c
index 90f39f7..2af4619 100644
--- a/drivers/s390/block/dasd_genhd.c
+++ b/drivers/s390/block/dasd_genhd.c
@@ -116,14 +116,11 @@ int dasd_scan_partitions(struct dasd_block *block)
rc);
return -ENODEV;
}
- /*
-* See fs/partition/check.c:register_disk,rescan_partitions
-* Can't call rescan_partitions directly. Use ioctl.
-*/
- rc = ioctl_by_bdev(bdev, BLKRRPART, 0);
+
+ rc = blkdev_reread_part(bdev);
while (rc == -EBUSY && retry > 0) {
schedule();
- rc = ioctl_by_bdev(bdev, BLKRRPART, 0);
+ rc = blkdev_reread_part(bdev);
retry--;
DBF_DEV_EVENT(DBF_ERR, block->base,
"scan partitions error, retry %d rc %d",
--
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/
[PATCH v3 6/7] block: replace trylock with mutex_lock in blkdev_reread_part()
The only possible problem of using mutex_lock() instead of trylock
is about deadlock.
If there aren't any locks held before calling blkdev_reread_part(),
deadlock can't be caused by this conversion.
If there are locks held before calling blkdev_reread_part(),
and if these locks arn't required in open, close handler and I/O
path, deadlock shouldn't be caused too.
Both user space's ioctl(BLKRRPART) and md_setup_drive() from
init/do_mounts_md.c belongs to the 1st case, so the conversion is safe
for the two cases.
For loop, the previous patches in this pathset has fixed the ABBA lock
dependency, so the conversion is OK.
For nbd, tx_lock is held when calling the function:
- both open and release won't hold the lock
- when blkdev_reread_part() is run, I/O thread has been stopped
already, so tx_lock won't be acquired in I/O path at that time.
- so the conversion won't cause deadlock for nbd
For dasd, both dasd_open(), dasd_release() and request function don't
acquire any mutex/semphone, so the conversion should be safe.
Reviewed-by: Christoph Hellwig
Tested-by: Jarod Wilson
Acked-by: Jarod Wilson
Signed-off-by: Ming Lei
---
block/ioctl.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/block/ioctl.c b/block/ioctl.c
index 203cb4a..8061eba 100644
--- a/block/ioctl.c
+++ b/block/ioctl.c
@@ -174,13 +174,18 @@ EXPORT_SYMBOL(__blkdev_reread_part);
* This is an exported API for the block driver, and will
* try to acquire bd_mutex. If bd_mutex has been held already
* in current context, please call __blkdev_reread_part().
+ *
+ * Make sure the held locks in current context aren't required
+ * in open()/close() handler and I/O path for avoiding ABBA deadlock:
+ * - bd_mutex is held before calling block driver's open/close
+ * handler
+ * - reading partition table may submit I/O to the block device
*/
int blkdev_reread_part(struct block_device *bdev)
{
int res;
- if (!mutex_trylock(>bd_mutex))
- return -EBUSY;
+ mutex_lock(>bd_mutex);
res = __blkdev_reread_part(bdev);
mutex_unlock(>bd_mutex);
--
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/
[PATCH v3 7/7] s390/block/dasd: remove obsolete while -EBUSY loop
From: Jarod Wilson
With the mutex_trylock bit gone from blkdev_reread_part(), the retry logic
in dasd_scan_partitions() shouldn't be necessary.
CC: Christoph Hellwig
CC: Jens Axboe
CC: Tejun Heo
CC: Alexander Viro
CC: Markus Pargmann
CC: Stefan Weinhuber
CC: Stefan Haberland
CC: Sebastian Ott
CC: Fabian Frederick
CC: Ming Lei
CC: David Herrmann
CC: Andrew Morton
CC: Peter Zijlstra
CC: nbd-gene...@lists.sourceforge.net
CC: linux-s...@vger.kernel.org
Reviewed-by: Christoph Hellwig
Acked-by: Sebastian Ott
Signed-off-by: Ming Lei
Signed-off-by: Jarod Wilson
---
drivers/s390/block/dasd_genhd.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/s390/block/dasd_genhd.c b/drivers/s390/block/dasd_genhd.c
index 2af4619..ef1d9fb 100644
--- a/drivers/s390/block/dasd_genhd.c
+++ b/drivers/s390/block/dasd_genhd.c
@@ -99,9 +99,8 @@ void dasd_gendisk_free(struct dasd_block *block)
int dasd_scan_partitions(struct dasd_block *block)
{
struct block_device *bdev;
- int retry, rc;
+ int rc;
- retry = 5;
bdev = bdget_disk(block->gdp, 0);
if (!bdev) {
DBF_DEV_EVENT(DBF_ERR, block->base, "%s",
@@ -118,14 +117,9 @@ int dasd_scan_partitions(struct dasd_block *block)
}
rc = blkdev_reread_part(bdev);
- while (rc == -EBUSY && retry > 0) {
- schedule();
- rc = blkdev_reread_part(bdev);
- retry--;
+ if (rc)
DBF_DEV_EVENT(DBF_ERR, block->base,
- "scan partitions error, retry %d rc %d",
- retry, rc);
- }
+ "scan partitions error, rc %d", rc);
/*
* Since the matching blkdev_put call to the blkdev_get in
--
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/
[PATCH v3 3/7] block: loop: fix another reread part failure
loop_clr_fd() can be run piggyback with lo_release(), and
under this situation, reread partition may always fail because
bd_mutex has been held already.
This patch detects the situation by the reference count, and
call __blkdev_reread_part() to avoid acquiring the lock again.
In the meantime, this patch switches to new kernel APIs
of blkdev_reread_part() and __blkdev_reread_part().
Reviewed-by: Christoph Hellwig
Tested-by: Jarod Wilson
Acked-by: Jarod Wilson
Signed-off-by: Jarod Wilson
Signed-off-by: Ming Lei
---
drivers/block/loop.c | 30 ++
1 file changed, 26 insertions(+), 4 deletions(-)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index b3e294e..2b99e34 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -474,6 +474,28 @@ static int loop_flush(struct loop_device *lo)
return loop_switch(lo, NULL);
}
+static void loop_reread_partitions(struct loop_device *lo,
+ struct block_device *bdev)
+{
+ int rc;
+
+ /*
+* bd_mutex has been held already in release path, so don't
+* acquire it if this function is called in such case.
+*
+* If the reread partition isn't from release path, lo_refcnt
+* must be at least one and it can only become zero when the
+* current holder is released.
+*/
+ if (!atomic_read(>lo_refcnt))
+ rc = __blkdev_reread_part(bdev);
+ else
+ rc = blkdev_reread_part(bdev);
+ if (rc)
+ pr_warn("%s: partition scan of loop%d (%s) failed (rc=%d)\n",
+ __func__, lo->lo_number, lo->lo_file_name, rc);
+}
+
/*
* loop_change_fd switched the backing store of a loopback device to
* a new file. This is useful for operating system installers to free up
@@ -522,7 +544,7 @@ static int loop_change_fd(struct loop_device *lo, struct
block_device *bdev,
fput(old_file);
if (lo->lo_flags & LO_FLAGS_PARTSCAN)
- ioctl_by_bdev(bdev, BLKRRPART, 0);
+ loop_reread_partitions(lo, bdev);
return 0;
out_putf:
@@ -759,7 +781,7 @@ static int loop_set_fd(struct loop_device *lo, fmode_t mode,
if (part_shift)
lo->lo_flags |= LO_FLAGS_PARTSCAN;
if (lo->lo_flags & LO_FLAGS_PARTSCAN)
- ioctl_by_bdev(bdev, BLKRRPART, 0);
+ loop_reread_partitions(lo, bdev);
/* Grab the block_device to prevent its destruction after we
* put /dev/loopXX inode. Later in loop_clr_fd() we bdput(bdev).
@@ -877,7 +899,7 @@ static int loop_clr_fd(struct loop_device *lo)
blk_mq_unfreeze_queue(lo->lo_queue);
if (lo->lo_flags & LO_FLAGS_PARTSCAN && bdev)
- ioctl_by_bdev(bdev, BLKRRPART, 0);
+ loop_reread_partitions(lo, bdev);
lo->lo_flags = 0;
if (!part_shift)
lo->lo_disk->flags |= GENHD_FL_NO_PART_SCAN;
@@ -954,7 +976,7 @@ loop_set_status(struct loop_device *lo, const struct
loop_info64 *info)
!(lo->lo_flags & LO_FLAGS_PARTSCAN)) {
lo->lo_flags |= LO_FLAGS_PARTSCAN;
lo->lo_disk->flags &= ~GENHD_FL_NO_PART_SCAN;
- ioctl_by_bdev(lo->lo_device, BLKRRPART, 0);
+ loop_reread_partitions(lo, lo->lo_device);
}
lo->lo_encrypt_key_size = info->lo_encrypt_key_size;
--
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/
[PATCH v3 4/7] block: nbd: convert to blkdev_reread_part()
Reviewed-by: Christoph Hellwig Tested-by: Jarod Wilson Acked-by: Jarod Wilson Signed-off-by: Ming Lei --- drivers/block/nbd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c index 39e5f7f..50d7f87 100644 --- a/drivers/block/nbd.c +++ b/drivers/block/nbd.c @@ -713,7 +713,7 @@ static int __nbd_ioctl(struct block_device *bdev, struct nbd_device *nbd, bdev->bd_inode->i_size = 0; set_capacity(nbd->disk, 0); if (max_part > 0) - ioctl_by_bdev(bdev, BLKRRPART, 0); + blkdev_reread_part(bdev); if (nbd->disconnect) /* user requested, ignore socket errors */ return 0; return nbd->harderror; -- 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/
[PATCH v3 0/7] block: reread partitions changes and fix for loop
Hi Guys, Recently there are several reports about loop partition scanning failure[1][2]. For loop, the root cause is one ABBA and one AA lock dependency issue, and the two are fixed by patch 2 and patch 3 each. Another reason is from the trylock in blkdev_reread_part(), which may cause partition scanning failure too sometimes when another task is holding the bd_mutex. In the discussion[1], both Tejun and Christoph suggests to replace the trylock with mutex_lock in blkdev_reread_part(), also Christoph suggests to export blkdev_reread_part. Following the discussion, this patchset exports blkdev_reread_part(), and introduces __blkdev_reread_part() for fixing loop's AA lock issue. Then ioctl_by_bdev(BLKRRPART) in loop, nbd and dasd is replaced with blkdev_reread_part(). In the last patch, trylock in blkdev_reread_part() is replaced with mutex_lock, and some analysis is provided about the conversion. V3: - fix lock unbalance in loop (2/7) - add reviewed-by from Christoph - run xfstest over loop and it passed - enable lockdep for verifying lock changes, and no warning with some common tests over loop block V2: - only print debug message in case of error (7/7) - add tested-by, acked-by V1: - introduce __blkdev_reread_part(), and use lockdep_assert_held()(1/7) - replace lo_open_mutex with atomic reference count, plus freezing queue(2/7) - add comment about detecting release path(3/7) - remove dead code in dasd(7/7) block/ioctl.c | 37 - drivers/block/loop.c| 51 ++- drivers/block/loop.h| 2 +- drivers/block/nbd.c | 2 +- drivers/s390/block/dasd_genhd.c | 19 +-- include/linux/fs.h | 3 +++ 6 files changed, 80 insertions(+), 34 deletions(-) [1], https://lkml.org/lkml/2015/1/26/137 [2], https://lkml.org/lkml/2015/3/31/888 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/
[PATCH v3 1/7] block: export blkdev_reread_part() and __blkdev_reread_part()
From: Jarod Wilson
This patch exports blkdev_reread_part() for block drivers, also
introduce __blkdev_reread_part().
For some drivers, such as loop, reread of partitions can be run
from the release path, and bd_mutex may already be held prior to
calling ioctl_by_bdev(bdev, BLKRRPART, 0), so introduce
__blkdev_reread_part for use in such cases.
CC: Christoph Hellwig
CC: Jens Axboe
CC: Tejun Heo
CC: Alexander Viro
CC: Markus Pargmann
CC: Stefan Weinhuber
CC: Stefan Haberland
CC: Sebastian Ott
CC: Fabian Frederick
CC: Ming Lei
CC: David Herrmann
CC: Andrew Morton
CC: Peter Zijlstra
CC: nbd-gene...@lists.sourceforge.net
CC: linux-s...@vger.kernel.org
Reviewed-by: Christoph Hellwig
Signed-off-by: Jarod Wilson
Signed-off-by: Ming Lei
---
block/ioctl.c | 28 +---
include/linux/fs.h | 3 +++
2 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/block/ioctl.c b/block/ioctl.c
index 7d8befd..203cb4a 100644
--- a/block/ioctl.c
+++ b/block/ioctl.c
@@ -150,21 +150,43 @@ static int blkpg_ioctl(struct block_device *bdev, struct
blkpg_ioctl_arg __user
}
}
-static int blkdev_reread_part(struct block_device *bdev)
+/*
+ * This is an exported API for the block driver, and will not
+ * acquire bd_mutex. This API should be used in case that
+ * caller has held bd_mutex already.
+ */
+int __blkdev_reread_part(struct block_device *bdev)
{
struct gendisk *disk = bdev->bd_disk;
- int res;
if (!disk_part_scan_enabled(disk) || bdev != bdev->bd_contains)
return -EINVAL;
if (!capable(CAP_SYS_ADMIN))
return -EACCES;
+
+ lockdep_assert_held(>bd_mutex);
+
+ return rescan_partitions(disk, bdev);
+}
+EXPORT_SYMBOL(__blkdev_reread_part);
+
+/*
+ * This is an exported API for the block driver, and will
+ * try to acquire bd_mutex. If bd_mutex has been held already
+ * in current context, please call __blkdev_reread_part().
+ */
+int blkdev_reread_part(struct block_device *bdev)
+{
+ int res;
+
if (!mutex_trylock(>bd_mutex))
return -EBUSY;
- res = rescan_partitions(disk, bdev);
+ res = __blkdev_reread_part(bdev);
mutex_unlock(>bd_mutex);
+
return res;
}
+EXPORT_SYMBOL(blkdev_reread_part);
static int blk_ioctl_discard(struct block_device *bdev, uint64_t start,
uint64_t len, int secure)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 35ec87e..1ef6390 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2279,6 +2279,9 @@ extern struct block_device *blkdev_get_by_path(const char
*path, fmode_t mode,
extern struct block_device *blkdev_get_by_dev(dev_t dev, fmode_t mode,
void *holder);
extern void blkdev_put(struct block_device *bdev, fmode_t mode);
+extern int __blkdev_reread_part(struct block_device *bdev);
+extern int blkdev_reread_part(struct block_device *bdev);
+
#ifdef CONFIG_SYSFS
extern int bd_link_disk_holder(struct block_device *bdev, struct gendisk
*disk);
extern void bd_unlink_disk_holder(struct block_device *bdev,
--
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 198/208] x86/fpu: Document the various fpregs state formats
* Dave Hansen wrote:
> On 05/05/2015 10:58 AM, Ingo Molnar wrote:
> > +/*
> > + * This is our most modern FPU state format, as saved by the XSAVE
> > + * and restored by the XRSTOR instructions.
> > + *
> > + * It consists of a legacy fxregs portion, an xstate header and
> > + * subsequent fixed size areas as defined by the xstate header.
> > + * Not all CPUs support all the extensions.
> > + */
> > struct xregs_state {
> > struct fxregs_state i387;
> > struct xstate_headerheader;
> > @@ -150,6 +169,13 @@ struct xregs_state {
> > /* New processor state extensions will go here. */
> > } __attribute__ ((packed, aligned (64)));
>
> Fenghua has a "fix" for this, but I think this misses a pretty big point.
>
> This structure includes only the "legacy" state, followed by the header.
> The remainder of the layout here is enumerated in CPUID leaves and can
> not be laid out in a structure because we do not know what it looks like
> until we run CPUID.
>
> There is logically a variable length array at the end of this
> sucker.
Yes, exactly, that is where we want to go, and this direction is what
I tried to cover with this bit of the series:
struct xregs_state {
struct fxregs_state i387;
struct xstate_headerheader;
u8 __reserved[XSTATE_RESERVE];
} __attribute__ ((packed, aligned (64)));
Note how it's now opaque after the xstate header, because there's no
guarantee of what's in that area.
The only 'fixed' aspect of the xstates is the feature bit enumeration:
enum xfeature_bit {
XSTATE_BIT_FP,
XSTATE_BIT_SSE,
XSTATE_BIT_YMM,
XSTATE_BIT_BNDREGS,
XSTATE_BIT_BNDCSR,
XSTATE_BIT_OPMASK,
XSTATE_BIT_ZMM_Hi256,
XSTATE_BIT_Hi16_ZMM,
XFEATURES_NR_MAX,
Plus with point #4 of the announcement I wanted to signal that I think
we should allocate the variable part dynamically:
4)
task->thread.fpu->state got embedded again, as
task->thread.fpu.state. This eliminated a lot of awkward late
dynamic memory allocation of FPU state and the problematic handling
of failures.
Note that while the allocation is static right now, this is a WIP
interim state: we can still do dynamic allocation of FPU state, by
moving the FPU state last in task_struct and then allocating
task_struct accordingly.
I.e. we can put the variable size state array at the end of
task_struct, make task_struct size per boot variable and still have
essentially a single static allocation for all fundamental task state.
But I first wanted to see people test this series - it's ambitious
enough as-is already!
Thanks,
Ingo
--
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: [V2 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency
On 5/5/15 22:13, Hanjun Guo wrote:
On 2015年05月05日 23:12, Suravee Suthikulpanit wrote:
This patch implements support for ACPI _CCA object, which is
introduced in
ACPIv5.1, can be used for specifying device DMA coherency attribute.
The parsing logic traverses device namespace to parse coherency
information, and stores it in acpi_device_flags. Then uses it to call
arch_setup_dma_ops() when creating each device enumerated in DSDT
during ACPI scan.
This patch also introduces acpi_dma_is_coherent(), which provides
an interface for device drivers to check the coherency information
similarly to the of_dma_is_coherent().
Signed-off-by: Mark Salter
Signed-off-by: Suravee Suthikulpanit
---
NOTE:
* Since there seem to be conflict opinions regarding how
architecture should handle _CCA=0. So, I am proposing the
CONFIG_ARCH_SUPPORT_CCA_ZERO, which can be specified by
for each architecture to define behavior of the ACPI
scanning code when _CCA=0. Let me know if this is acceptable.
drivers/acpi/Kconfig | 6 +
drivers/acpi/acpi_platform.c | 4 ++-
drivers/acpi/scan.c | 62
include/acpi/acpi_bus.h | 11 +++-
include/linux/acpi.h | 5
5 files changed, 86 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index ab2cbb5..dd386e9 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -54,6 +54,12 @@ config ACPI_GENERIC_GSI
config ACPI_SYSTEM_POWER_STATES_SUPPORT
bool
+config ACPI_MUST_HAVE_CCA
+bool
+
+config ACPI_SUPPORT_CCA_ZERO
+bool
+
config ACPI_SLEEP
bool
depends on SUSPEND || HIBERNATION
diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
index 4bf7559..a6feca4 100644
--- a/drivers/acpi/acpi_platform.c
+++ b/drivers/acpi/acpi_platform.c
@@ -108,9 +108,11 @@ struct platform_device
*acpi_create_platform_device(struct acpi_device *adev)
if (IS_ERR(pdev))
dev_err(>dev, "platform device creation failed: %ld\n",
PTR_ERR(pdev));
-else
+else {
+acpi_setup_device_dma(adev, >dev);
dev_dbg(>dev, "created platform device %s\n",
dev_name(>dev));
+}
kfree(resources);
return pdev;
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 849b699..ac33b29 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
@@ -2137,6 +2138,66 @@ void acpi_free_pnp_ids(struct acpi_device_pnp
*pnp)
kfree(pnp->unique_id);
}
+void acpi_setup_device_dma(struct acpi_device *adev, struct device *dev)
I aasume adev->dev in struct *adev is the same as struct device *dev
passed here, so
+{
+int coherent = acpi_dma_is_coherent(adev);
+
+/**
+ * Currently, we only support DMA for devices that _CCA=1
+ * since this seems to be the case on most ACPI platforms.
+ *
+ * For the case when _CCA=0 (i.e. is_coherent=0 && cca_seen=1),
+ * we would rely on arch-specific cache maintenance for
+ * non-coherence DMA operations if architecture enables
+ * CONFIG_ACPI_SUPPORT_CCA_ZERO.
+ *
+ * For the case when _CCA is missing but platform requires it
+ * (i.e. is_coherent=0 && cca_seen=0), we do not call
+ * arch_setup_dma_ops() and fallback to arch-specific default
+ * handling.
+ */
+if (adev->flags.cca_seen) {
+if (!coherent && !IS_ENABLED(CONFIG_ACPI_SUPPORT_CCA_ZERO))
+return;
+arch_setup_dma_ops(dev, 0, 0, NULL, coherent);
how about using >dev here, and just pass struct acpi_device *adev
for this function?
Actually, I was using arch_setup_device_dma() in multiple places, and
adev->dev is not necessary the same as *dev. However, I am refactoring
this function in V3. Anyways, thanks for reviewing.
Suravee
--
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: [V2 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency
[RESEND]
On 5/5/15 15:36, Rafael J. Wysocki wrote:
On Tuesday, May 05, 2015 10:12:05 AM Suravee Suthikulpanit wrote:
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index ab2cbb5..dd386e9 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -54,6 +54,12 @@ config ACPI_GENERIC_GSI
config ACPI_SYSTEM_POWER_STATES_SUPPORT
bool
+config ACPI_MUST_HAVE_CCA
ACPI_CCA_REQUIRED maybe?
Sure.
+ bool
+
+config ACPI_SUPPORT_CCA_ZERO
I guess this means "we support devices that can DMA, but are not coherent".
right?
Yes, basically when _CCA=0.
+ bool
+
config ACPI_SLEEP
bool
depends on SUSPEND || HIBERNATION
diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
index 4bf7559..a6feca4 100644
--- a/drivers/acpi/acpi_platform.c
+++ b/drivers/acpi/acpi_platform.c
@@ -108,9 +108,11 @@ struct platform_device *acpi_create_platform_device(struct
acpi_device *adev)
if (IS_ERR(pdev))
dev_err(>dev, "platform device creation failed: %ld\n",
PTR_ERR(pdev));
- else
+ else {
Please add braces to both branches when making such changes (as per
CodingStyle).
OK.
+ acpi_setup_device_dma(adev, >dev);
Why do we need to do that here (for the second time)?
Because we are calling:
acpi_create_platform_device()
|--> platform_device_register_device_full()
|-->platform_device_alloc()
This creates platform_device, which allocate a new platform_device->dev.
This is not the same as the original acpi_device->dev that was created
during acpi_add_single_object(). So, we have to set up the device
coherency again.
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 849b699..ac33b29 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
@@ -2137,6 +2138,66 @@ void acpi_free_pnp_ids(struct acpi_device_pnp *pnp)
kfree(pnp->unique_id);
}
+void acpi_setup_device_dma(struct acpi_device *adev, struct device *dev)
+{
+ int coherent = acpi_dma_is_coherent(adev);
+
+ /**
+* Currently, we only support DMA for devices that _CCA=1
+* since this seems to be the case on most ACPI platforms.
+*
+* For the case when _CCA=0 (i.e. is_coherent=0 && cca_seen=1),
+* we would rely on arch-specific cache maintenance for
+* non-coherence DMA operations if architecture enables
+* CONFIG_ACPI_SUPPORT_CCA_ZERO.
+*
+* For the case when _CCA is missing but platform requires it
+* (i.e. is_coherent=0 && cca_seen=0), we do not call
+* arch_setup_dma_ops() and fallback to arch-specific default
+* handling.
+*/
+ if (adev->flags.cca_seen) {
+ if (!coherent && !IS_ENABLED(CONFIG_ACPI_SUPPORT_CCA_ZERO))
+ return;
+ arch_setup_dma_ops(dev, 0, 0, NULL, coherent);
Oh dear.
I made a mistake here. This logic should also call arch_setup_dma_ops()
when cca_seen=0 and coherent=1 (e.g. when _CCA is not required and
default to coherent when it is missing). The current logic doesn't do that.
What about
if (adev->flags.cca_seen && (coherent ||
IS_ENABLED(CONFIG_ACPI_SUPPORT_CCA_ZERO)))
arch_setup_dma_ops(dev, 0, 0, NULL, coherent);
What about:
if (coherent ||
(adev->flags.cca_seen &&
IS_ENABLED(CONFIG_ACPI_SUPPORT_CCA_ZERO))
arch_setup_dma_ops(dev, 0, 0, NULL, coherent);
I wonder how this is going to affect x86/ia64 too?
This should not affect x86 since arch_setup_dma_ops() is currently not
implement for x86, and default to NOP (see include/linux/dma-mapping.h).
Also, on x86, _CCA is not required and default to 1 if missing.
Thanks,
Suravee
--
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: [Question] How does perf still record the stack of a specified pid even when that process is interrupted and CPU is scheduled to other process
On 2015/5/6 5:53, Rabin Vincent wrote: > On Sat, Apr 25, 2015 at 09:53:57AM -0600, David Ahern wrote: >> On 4/25/15 8:05 AM, Yunlong Song wrote: >>> But this only shows the system call like strace, but we want the call >>> stack of kernel functions in fact. >>> >> We haven't added the callchain option yet; on the to-do list. >> >> perf trace record -g -- iozone ... >> perf trace -i perf.data -s >> --> summary of system calls, max/min/average times >> >> perf trace -i perf.data --duration 10.0 -T >> --> note the timestamp where the write took a "long" time >> >> perf script >> --> search down to *around* the time of interest; you want the syscall >> entry; timestamp is for exit > > Now if I understood the use case right, what Yulong Song wants to know > is what the iozone process is doing in the kernel (i.e. the stacktrace of why > exactly it goes to sleep / what it's waiting for) during these > sys_writes which take a long time. > > The commands above will identify the sys_write which takes time but only > provide the stacktrace at the entry and exit of the syscall, but this do > not show why the process blocked or what it did inside the system call. > > So a way to get what is required for the use case would be to make the > following changes to the above sequence: > > (1) include the sched:* events when perf trace record is run > > (2) around the time of interest, look at the kernel stack st the sched:switch > events between the entry and the exit. This will show what the process > was > waiting for when it when it blocked. The stacktraces at the > stat_runtime events in the process may also be useful to understand what > was going on. > > Example: > > $ perf trace record -g -e sched:* -- dd if=/dev/zero of=/x bs=10M count=100 > conv=fsync > $ perf trace -i perf.data -s > > dd (147), 364 events, 94.3%, 0.000 msec > >syscallcalls min avg max stddev >--- - - - -- >write 63 266.019 316.896 963.413 4.69% >... > > $ perf trace -i perf.data --duration 960 -T > 91916.354 (963.413 ms): dd/147 write(arg0: 1, arg1: 139729327423488, arg2: > 10485760, arg3: 582, arg4: 100, arg5: 72340172838076673) = 10485760 > > $ perf script > ... > > dd 147 [002]90.952941: raw_syscalls:sys_enter: NR 1 (1, 7f1544ed, > a0, 246, 64, 101010101010101) > 211a00 syscall_trace_enter_phase2 ([kernel.kallsyms]) > 7d79c3 tracesys_phase2 ([kernel.kallsyms]) > ed20 [unknown] (/lib/libpthread-2.16.so) > > (... trimmed everything except the longest block: ...) > > dd 147 [002]91.204723: sched:sched_switch: prev_comm=dd prev_pid=147 > prev_prio=120 prev_state=D ==> next_comm=swapper/2 next_pid=0 next_prio=120 > 7d1121 __schedule ([kernel.kallsyms]) > 7d1817 schedule ([kernel.kallsyms]) > 4578a5 jbd2_log_wait_commit ([kernel.kallsyms]) > 4546ff jbd2_log_do_checkpoint ([kernel.kallsyms]) > 45489f __jbd2_log_wait_for_space ([kernel.kallsyms]) > 44c2d8 start_this_handle ([kernel.kallsyms]) > 44c7b6 jbd2__journal_start ([kernel.kallsyms]) > 42fc3b __ext4_journal_start_sb ([kernel.kallsyms]) > 4012e9 ext4_write_begin ([kernel.kallsyms]) > 33795f generic_perform_write ([kernel.kallsyms]) > 338b68 __generic_file_write_iter ([kernel.kallsyms]) > 3f4371 ext4_file_write_iter ([kernel.kallsyms]) > 381ae1 __vfs_write ([kernel.kallsyms]) > 381f07 vfs_write ([kernel.kallsyms]) > 3825dd sys_write ([kernel.kallsyms]) > 7d7a1a tracesys_phase2 ([kernel.kallsyms]) > ed20 [unknown] (/lib/libpthread-2.16.so) > > swapper 0 [002]91.875573: sched:sched_wakeup: comm=dd pid=147 > prio=120 success=1 target_cpu=002 > > . > Good, it's clearer with "sched:*" event. -- Thanks, Yunlong Song -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/2] arm64: perf: Fix callchain parse error with kernel tracepoint events
On 2015/5/6 1:00, Will Deacon wrote:
On Sat, May 02, 2015 at 06:58:17AM +0100, Hou Pengyang wrote:
For ARM64, when tracing with tracepoint events, the IP and pstate are set
to 0, preventing the perf code parsing the callchain and resolving the
symbols correctly.
./perf record -e sched:sched_switch -g --call-graph dwarf ls
[ perf record: Captured and wrote 0.146 MB perf.data ]
./perf report -f
Samples: 194 of event 'sched:sched_switch', Event count (approx.): 194
Children SelfCommand Shared Object Symbol
100.00% 100.00% ls [unknown] [.]
The fix is to implement perf_arch_fetch_caller_regs for ARM64, which fills
several necessary registers used for callchain unwinding, including pc,sp,
fp and spsr .
With this patch, callchain can be parsed correctly as follows:
..
+2.63% 0.00% ls [kernel.kallsyms] [k] vfs_symlink
+2.63% 0.00% ls [kernel.kallsyms] [k] follow_down
+2.63% 0.00% ls [kernel.kallsyms] [k] pfkey_get
+2.63% 0.00% ls [kernel.kallsyms] [k] do_execveat_common.isra.33
-2.63% 0.00% ls [kernel.kallsyms] [k] pfkey_send_policy_notify
pfkey_send_policy_notify
pfkey_get
v9fs_vfs_rename
page_follow_link_light
link_path_walk
el0_svc_naked
...
Signed-off-by: Hou Pengyang
---
arch/arm64/include/asm/perf_event.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/include/asm/perf_event.h
b/arch/arm64/include/asm/perf_event.h
index d26d1d5..cc92021 100644
--- a/arch/arm64/include/asm/perf_event.h
+++ b/arch/arm64/include/asm/perf_event.h
@@ -24,4 +24,11 @@ extern unsigned long perf_misc_flags(struct pt_regs *regs);
#define perf_misc_flags(regs) perf_misc_flags(regs)
#endif
+#define perf_arch_fetch_caller_regs(regs, __ip) { \
+ (regs)->ARM_pc = (__ip);\
+ (regs)->ARM_fp = (unsigned long) __builtin_frame_address(0); \
+ (regs)->ARM_sp = current_stack_pointer; \
+ (regs)->ARM_cpsr = PSR_MODE_EL1h;\
+}
This can't possibly compile, therefore you can't possibly have tested it.
I am so sorry. I did test the patch, but on mainline 4.0 +
David long's patches for ARM64 kprobe which are not included in
mainline now. In David's patches, there are macros like ARM_pc, ARM_fp,
ARM_sp and ARM_cpsr, my patch incorrectly used these macros which
results in such compile errors if applied to 4.0 directly:
error: 'struct pt_regs' has no member named 'ARM_pc'
error: 'struct pt_regs' has no member named 'ARM_fp'
error: 'struct pt_regs' has no member named 'ARM_sp'
error: 'struct pt_regs' has no member named 'ARM_cpsr'
I will fix the code and do more test.
Please fix the code and actually check that you're getting sensible
callchains before sending a new version of the patch.
Thanks,
Will
.
--
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 200/208] x86/fpu/xstate: Don't assume the first zero xfeatures zero bit means the end
* Yu, Fenghua wrote: > > From: Ingo Molnar [mailto:mingo.kernel@gmail.com] On Behalf Of Ingo > > Molnar > > Sent: Tuesday, May 05, 2015 10:58 AM > > To: linux-kernel@vger.kernel.org > > Cc: Andy Lutomirski; Borislav Petkov; Dave Hansen; Yu, Fenghua; H. Peter > > Anvin; Linus Torvalds; Oleg Nesterov; Thomas Gleixner > > Subject: [PATCH 200/208] x86/fpu/xstate: Don't assume the first zero > > xfeatures zero bit means the end > > > > The current xstate code in setup_xstate_features() assumes that the first > > zero bit means the end of xfeatures - but that is not so, the SDM clearly > > states that an arbitrary set of xfeatures might be enabled - and it is also > > clear > > from the description of the compaction feature that holes are possible: > > A previous patch in lkml has (exactly) the same fix: > http://lists-archives.com/linux-kernel/28292115-x86-xsave-c-fix-xstate-offsets-and-sizes-enumeration.html Ok, and that series has some more bits as well - will merge. Thanks, Ingo -- 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 7/7] ACPI / processor: Introduce invalid_phys_cpuid()
On 2015年05月05日 19:25, Sudeep Holla wrote:
On 05/05/15 03:46, Hanjun Guo wrote:
Introduce invalid_phys_cpuid() to identify cpu with invalid
physical ID, then used it as replacement of the direct comparisons
with PHYS_CPUID_INVALID.
Signed-off-by: Hanjun Guo
---
drivers/acpi/acpi_processor.c | 4 ++--
drivers/acpi/processor_core.c | 4 ++--
include/linux/acpi.h | 5 +
3 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/acpi_processor.c
b/drivers/acpi/acpi_processor.c
index 62c846b..92a5f73 100644
--- a/drivers/acpi/acpi_processor.c
[...]
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 913b49f..cc82ff3 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -163,6 +163,11 @@ static inline bool invalid_logical_cpuid(u32 cpuid)
return (int)cpuid < 0;
}
+static inline bool invalid_phys_cpuid(phys_cpuid_t phys_id)
+{
+return (int)phys_id < 0;
Should this be phys_id == PHYS_CPUID_INVALID ? else I don't see why we
need to even define PHYS_CPUID_INVALID
Oh, we need PHYS_CPUID_INVALID because we defined
+#ifndef PHYS_CPUID_INVALID
+typedef u32 phys_cpuid_t;
+#define PHYS_CPUID_INVALID (phys_cpuid_t)(-1)
+#endif
in the common head file linux/acpi.h, as it is needed
for phys_cpuid_t for ARM64. this is already discussed
here:
https://lkml.org/lkml/2015/3/30/311
Thanks
Hanjun
--
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 207/208] x86/fpu: Add FPU performance measurement subsystem
* Dave Hansen wrote: > On 05/05/2015 10:58 AM, Ingo Molnar wrote: > > x86/fpu: Cost of: XSAVE insn : 104 cycles > > x86/fpu: Cost of: XRSTOR insn :80 cycles > > Isn't there going to be pretty huge variability here depending on > how much state you are xsave/xrstor'ing and if the init/modified > optimizations are in play? Hopefully there's such variability! :) I thought to add measurements for that as well: - to see the costs of this instruction family when various xstate components are in 'init state' or not - maybe even measure whether it can optimize based on whether things got changed since the last save (which the SDM kind of alludes to but which I doubt the hw does)? This initial version only measures trivial init state save/restore cost. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/6] perf bpf: Probing with local variable
On 5/5/15 8:58 PM, Wang Nan wrote:
Two high level comments:
- can you collapse SEC("config") with SEC("func_name") ?
It seems that "func_name" is only used as reference inside "config".
I understand that you're proposing one "config" section where multiple
descriptions are strcat together, but why? Something like:
SEC("kprobe/generic_perform_write+122(file->f_mapping->a_ops, bytes, offset)")
int func(...) { ... }
should be enough and more concise.
Is it possible to use such a long section name? I introduce 'config' section
yes. of course. I don't know what is the limit, but it's definitely
above 512 characters. It can contains spaces and special chars too.
since it contains C strings so I can put things to it freely. By using macro
trick,
we can still use not very complex code to describe probing position like this:
#define PROBE(name, config) \
SEC("config") char name##_config[] = #name config ; \
SEC(#name)
PROBE(generic_perform_write, "kprobe: +122(file->f_mapping->a_ops, bytes,
offset)")
that's even more obscure :( why hide it behind macros?
I think single 'SEC' macro is already not very clean, but I couldn't
come up with better alternative. Elf sections are free that why I used
them in samples/bpf/ examples, but let's not overuse them.
--
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: [Question] How does perf still record the stack of a specified pid even when that process is interrupted and CPU is scheduled to other process
On 2015/4/25 23:53, David Ahern wrote: > On 4/25/15 8:05 AM, Yunlong Song wrote: >> On 2015/4/24 21:58, David Ahern wrote: >>> On 4/24/15 7:31 AM, Yunlong Song wrote: Now we are profiling the performance of ext4 and f2fs on an eMMC card with iozone, we find a case that ext4 is better than f2fs in random write under the test of "iozone -s 262144 -r 64 -i 0 -i 2". We want to analyze the I/O delay of the two file systems. We have got a conclusion that 1% of sys_write takes up 60% time of the overall sys_write (262144/64=4096). We want to find out the call stack during this specific 1% sys_write. Our idea is to record the stack in a certain time period and since the specific 1% case takes up 60% time, the total number of records of its stack should also takes up 60% of the total records, then we can recognize those stacks and figure out what the I/O stack of f2fs is doing in the 1% case. >>> >>> And to address this specific profiling problem have you tried: >>> >>> perf trace record -- iozone ... >>> perf trace -i perf.data -S >>> >>> >>> >>> >> >> But this only shows the system call like strace, but we want the call stack >> of kernel functions >> in fact. >> > > We haven't added the callchain option yet; on the to-do list. > > perf trace record -g -- iozone ... > perf trace -i perf.data -s > --> summary of system calls, max/min/average times > > perf trace -i perf.data --duration 10.0 -T > --> note the timestamp where the write took a "long" time > > perf script > --> search down to *around* the time of interest; you want the syscall entry; > timestamp is for exit > > . > Hi, David, It's almost what we want, we are eager to see it can work as a callchain option, since it's really a useful tool in analyzing latency of I/O performance in production case. -- Thanks, Yunlong Song -- 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/
linux-next: build warnings after merge of the staging tree
Hi Greg,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) produced these warnings:
drivers/staging/lustre/lustre/llite/file.c: In function
'll_iocontrol_unregister':
drivers/staging/lustre/lustre/llite/file.c:3249:17: warning: unused variable
'size' [-Wunused-variable]
unsigned int size = tmp->iocd_size;
^
drivers/staging/lustre/lustre/llite/llite_lib.c: In function 'll_fill_super':
drivers/staging/lustre/lustre/llite/llite_lib.c:912:12: warning: unused
variable 'instlen' [-Wunused-variable]
const int instlen = sizeof(cfg->cfg_instance) * 2 + 2;
^
Introduced by commit 97903a26fcfc ("staging: lustre: llite: drop uses
of OBD free functions").
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpjFbNBtYPW1.pgp
Description: OpenPGP digital signature
linux-next: build warning after merge of the clk tree
Hi all,
After merging the clk tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
drivers/clk/clk.c:2231:13: warning: 'clk_is_orphan' defined but not used
[-Wunused-function]
static bool clk_is_orphan(const struct clk *clk)
^
Introduced by commit ece3ffbe1b7b ("clk: prevent orphan clocks from
being used").
CONFIG_OF is not set for this build ...
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp2RFVV5FHul.pgp
Description: OpenPGP digital signature
Re: [RFC PATCH 0/6] perf bpf: Probing with local variable
On 2015/5/6 6:31, Alexei Starovoitov wrote:
> On 5/5/15 3:10 AM, He Kuang wrote:
>> This patch set is based on https://lkml.org/lkml/2015/4/30/264
>>
>> By using bpf 'config' section like this:
>>
>>char _config2[] SEC("config") =
>> "generic_perform_write=generic_perform_write+122 file->f_mapping->a_ops
>> bytes offset";
>>SEC("generic_perform_write")
>>int NODE_generic_perform_write (struct pt_regs *ctx, void *a_ops, void
>> *bytes, void* offset) {
>>char fmt[] = "NODE_generic_perform_write, a_ops=%p, bytes=%p,
>> offset=%p\n";
>>bpf_trace_printk(fmt, sizeof(fmt), a_ops, bytes, offset);
>>return 1;
>>}
>>
>> In this example, 'bytes' and 'offset' are local variables, a_ops is in
>> the structure field of file parameter, and we probe in the body of the
>> generic_perform_write() function.
>>
>> Perf can fetch and convert all the arguments and then we translate them
>> into bpf bytecode as a prologue before calling bpf body functions. In
>> the prologue, we fetch arguments from bpf context register and place
>> them according to bpf calling conventions so the body function can
>> access them as formal parameters.
>
> great idea! Like it a lot.
> Looking at current implementation I think the limit is <=3 arguments,
> which I think is perfectly fine for now. Just worth mentioning in
> the doc.
>
> Two high level comments:
> - can you collapse SEC("config") with SEC("func_name") ?
> It seems that "func_name" is only used as reference inside "config".
> I understand that you're proposing one "config" section where multiple
> descriptions are strcat together, but why? Something like:
> SEC("kprobe/generic_perform_write+122(file->f_mapping->a_ops, bytes, offset)")
> int func(...) { ... }
> should be enough and more concise.
>
Is it possible to use such a long section name? I introduce 'config' section
since it contains C strings so I can put things to it freely. By using macro
trick,
we can still use not very complex code to describe probing position like this:
#define PROBE(name, config) \
SEC("config") char name##_config[] = #name config ; \
SEC(#name)
PROBE(generic_perform_write, "kprobe: +122(file->f_mapping->a_ops, bytes,
offset)")
--
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/
[RFC] kernel random segmentation fault?
Hi all:
I meet a kernel problem about the random segmentation fault(x86_64). In my
testcase, the size of local variables exceeds 20MB.
when run the testcase, it will cause segmentation fault(because the default
stack size limit is 8192KB).
when I increase the stack size limit to 1024000KB(ulimit -s 1024000), the
testcase will pass.
But when I run the testcase 100 times, it will cause random segmentation fault.
Maybe the commit fee7e49d45149fba60156f5b59014f764d3e3728 "mm: propagate error
from stack expansion even for guard page"
cause this problems, when I revert it, the testcase will not cause random
segmentation fault problem.
Can anyone give some ideas about this problem?
Best Regards
Wang Long
Test Environment #
# uname -a
Linux ivybridge 4.1.0-rc2+ #3 SMP PREEMPT Wed May 6 10:46:57 CST 2015 x86_64
x86_64 x86_64 GNU/Linux
The Testcase
#include
#include
#include
#define KB *1024
#define MB *(1024*1024)
#define GB *(1024*1024*1024)
int main(int argc, char** argv)
{
int ret;
struct rlimit rlim;
rlim.rlim_cur=20 MB;
rlim.rlim_max=20 MB;
ret = setrlimit(RLIMIT_AS, );
if ( 0 > ret)
{
perror("setrlimit failed");
exit(1);
}
printf("setrlimit success\n");
char tmp[20 MB];
int i = 0;
for (i = 0; i < 20 MB; i++)
{
tmp[i]=1;
}
printf("test success\n");
exit(1);
}
# My config
--
1.8.3.4
.
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 4.1.0-rc2 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10
-fcall-saved-r11"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_DOMAIN=y
CONFIG_GENERIC_MSI_IRQ=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y
#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ_FULL is not set
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y
#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
#
# RCU Subsystem
#
CONFIG_PREEMPT_RCU=y
CONFIG_SRCU=y
# CONFIG_TASKS_RCU is not set
CONFIG_RCU_STALL_COMMON=y
# CONFIG_RCU_USER_QS is not set
CONFIG_RCU_FANOUT=64
Re: question about RCU dynticks_nesting
On Wed, 2015-05-06 at 03:49 +0200, Mike Galbraith wrote: > On Mon, 2015-05-04 at 22:54 -0700, Paul E. McKenney wrote: > > > You have RCU_FAST_NO_HZ=y, correct? Could you please try measuring with > > RCU_FAST_NO_HZ=n? > > FWIW, the syscall numbers I posted were RCU_FAST_NO_HZ=n. (I didn't > profile to see where costs lie though) (did that) 1 * stat() on isolated cpu NO_HZ_FULL offinactive housekeepernohz_full real0m14.266s 0m14.367s0m20.427s 0m27.921s user0m1.756s 0m1.553s 0m1.976s 0m10.447s sys 0m12.508s 0m12.769s0m18.400s 0m17.464s (real) 1.000 1.0071.431 1.957 inactive housekeeper nohz_full -- 7.61% [.] __xstat64 11.12% [k] context_tracking_exit 7.41% [k] context_tracking_exit 7.04% [k] system_call6.18% [k] context_tracking_enter 6.02% [k] native_sched_clock 6.96% [k] copy_user_enhanced_fast_string 5.18% [.] __xstat64 4.69% [k] rcu_eqs_enter_common.isra.37 6.57% [k] path_init 4.89% [k] system_call 4.35% [k] _raw_spin_lock 5.92% [k] system_call_after_swapgs 4.84% [k] copy_user_enhanced_fast_string 4.30% [k] context_tracking_enter 5.44% [k] lockref_put_return 4.46% [k] path_init 4.25% [k] kmem_cache_alloc 4.69% [k] link_path_walk 4.30% [k] system_call_after_swapgs 4.14% [.] __xstat64 4.47% [k] lockref_get_not_dead 4.12% [k] kmem_cache_free 3.89% [k] rcu_eqs_exit_common.isra.38 4.46% [k] kmem_cache_free3.78% [k] link_path_walk 3.50% [k] system_call 4.20% [k] kmem_cache_alloc 3.62% [k] lockref_put_return 3.48% [k] copy_user_enhanced_fast_string 4.09% [k] cp_new_stat3.43% [k] kmem_cache_alloc 3.02% [k] system_call_after_swapgs 3.38% [k] vfs_getattr_nosec 2.95% [k] lockref_get_not_dead 2.97% [k] kmem_cache_free 2.82% [k] vfs_fstatat2.87% [k] cp_new_stat 2.88% [k] lockref_put_return 2.60% [k] user_path_at_empty 2.62% [k] syscall_trace_leave2.61% [k] link_path_walk 2.47% [k] path_lookupat 1.91% [k] vfs_getattr_nosec 2.58% [k] path_init 2.14% [k] strncpy_from_user 1.89% [k] syscall_trace_enter_phase1 2.15% [k] lockref_get_not_dead 2.11% [k] getname_flags 1.77% [k] path_lookupat 2.04% [k] cp_new_stat 2.10% [k] generic_fillattr 1.67% [k] complete_walk 1.89% [k] generic_fillattr 2.05% [.] main 1.65% [k] vfs_fstatat 1.67% [k] syscall_trace_leave 1.89% [k] complete_walk 1.56% [k] generic_fillattr 1.59% [k] vfs_getattr_nosec 1.73% [k] generic_permission 1.55% [k] user_path_at_empty 1.49% [k] get_vtime_delta 1.50% [k] system_call_fastpath 1.54% [k] strncpy_from_user 1.32% [k] user_path_at_empty 1.37% [k] legitimize_mnt 1.53% [k] getname_flags 1.30% [k] syscall_trace_enter_phase1 1.30% [k] dput 1.46% [k] legitimize_mnt 1.21% [k] rcu_eqs_exit 1.26% [k] putname1.34% [.] main 1.21% [k] vfs_fstatat 1.19% [k] path_put 1.32% [k] int_with_check 1.18% [k] path_lookupat 1.18% [k] filename_lookup1.28% [k] generic_permission 1.15% [k] getname_flags 1.01% [k] SYSC_newstat 1.16% [k] int_very_careful 1.03% [k] strncpy_from_user 0.96% [k] mntput_no_expire 1.04% [k] putname 1.01% [k] account_system_time 0.79% [k] path_cleanup 0.94% [k] dput 1.00% [k] complete_walk 0.79% [k] mntput 0.91% [k] context_tracking_user_exit 0.99% [k]
Re: [PATCH v2] splice: sendfile() at once fails for big files
Jens, ping?
The test results should make this a no-brainer, but I hate how random
these flag ops.
Linus
On Mon, Apr 27, 2015 at 12:01 AM, Herbert Xu
wrote:
> Christophe Leroy wrote:
>> Using sendfile with below small program to get MD5 sums of some files,
>> it appear that big files (over 64kbytes with 4k pages system) get a
>> wrong MD5 sum while small files get the correct sum.
>> This program uses sendfile() to send a file to an AF_ALG socket
>> for hashing.
>
> Jens, any comments on this patch?
>
>> /* md5sum2.c */
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>>
>> int main(int argc, char **argv)
>> {
>>int sk = socket(AF_ALG, SOCK_SEQPACKET, 0);
>>struct stat st;
>>struct sockaddr_alg sa = {
>>.salg_family = AF_ALG,
>>.salg_type = "hash",
>>.salg_name = "md5",
>>};
>>int n;
>>
>>bind(sk, (struct sockaddr*), sizeof(sa));
>>
>>for (n = 1; n < argc; n++) {
>>int size;
>>int offset = 0;
>>char buf[4096];
>>int fd;
>>int sko;
>>int i;
>>
>>fd = open(argv[n], O_RDONLY);
>>sko = accept(sk, NULL, 0);
>>fstat(fd, );
>>size = st.st_size;
>>sendfile(sko, fd, , size);
>>size = read(sko, buf, sizeof(buf));
>>for (i = 0; i < size; i++)
>>printf("%2.2x", buf[i]);
>>printf(" %s\n", argv[n]);
>>close(fd);
>>close(sko);
>>}
>>exit(0);
>> }
>>
>> Test below is done using official linux patch files. First result is
>> with a software based md5sum. Second result is with the program above.
>>
>> root@vgoip:~# ls -l patch-3.6.*
>> -rw-r--r--1 root root 64011 Aug 24 12:01 patch-3.6.2.gz
>> -rw-r--r--1 root root 94131 Aug 24 12:01 patch-3.6.3.gz
>>
>> root@vgoip:~# md5sum patch-3.6.*
>> b3ffb9848196846f31b2ff133d2d6443 patch-3.6.2.gz
>> c5e8f687878457db77cb7158c38a7e43 patch-3.6.3.gz
>>
>> root@vgoip:~# ./md5sum2 patch-3.6.*
>> b3ffb9848196846f31b2ff133d2d6443 patch-3.6.2.gz
>> 5fd77b24e68bb24dcc72d6e57c64790e patch-3.6.3.gz
>>
>>
>> After investivation, it appears that sendfile() sends the files by blocks
>> of 64kbytes (16 times PAGE_SIZE). The problem is that at the end of each
>> block, the SPLICE_F_MORE flag is missing, therefore the hashing operation
>> is reset as if it was the end of the file.
>>
>> This patch adds SPLICE_F_MORE to the flags when more data is pending.
>>
>> With the patch applied, we get the correct sums:
>>
>> root@vgoip:~# md5sum patch-3.6.*
>> b3ffb9848196846f31b2ff133d2d6443 patch-3.6.2.gz
>> c5e8f687878457db77cb7158c38a7e43 patch-3.6.3.gz
>>
>> root@vgoip:~# ./md5sum2 patch-3.6.*
>> b3ffb9848196846f31b2ff133d2d6443 patch-3.6.2.gz
>> c5e8f687878457db77cb7158c38a7e43 patch-3.6.3.gz
>>
>> Signed-off-by: Christophe Leroy
>> ---
>> v2: no change, only new commit text
>>
>> fs/splice.c | 7 ++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/fs/splice.c b/fs/splice.c
>> index 476024b..fe61723 100644
>> --- a/fs/splice.c
>> +++ b/fs/splice.c
>> @@ -1161,7 +1161,7 @@ ssize_t splice_direct_to_actor(struct file *in, struct
>> splice_desc *sd,
>>long ret, bytes;
>>umode_t i_mode;
>>size_t len;
>> - int i, flags;
>> + int i, flags, more;
>>
>>/*
>> * We require the input being a regular file, as we don't want to
>> @@ -1204,6 +1204,7 @@ ssize_t splice_direct_to_actor(struct file *in, struct
>> splice_desc *sd,
>> * Don't block on output, we have to drain the direct pipe.
>> */
>>sd->flags &= ~SPLICE_F_NONBLOCK;
>> + more = sd->flags & SPLICE_F_MORE;
>>
>>while (len) {
>>size_t read_len;
>> @@ -1216,6 +1217,10 @@ ssize_t splice_direct_to_actor(struct file *in,
>> struct splice_desc *sd,
>>read_len = ret;
>>sd->total_len = read_len;
>>
>> + if (read_len < len)
>> + sd->flags |= SPLICE_F_MORE;
>> + else if (!more)
>> + sd->flags &= ~SPLICE_F_MORE;
>>/*
>> * NOTE: nonblocking mode only applies to the input. We
>> * must not do the output in nonblocking mode as then we
>
> Thanks,
> --
> Email: Herbert Xu
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> --
> 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
Re: [PATCH 0/13] Parallel struct page initialisation v4
On 05/05/2015 11:01 AM, Waiman Long wrote:
On 05/05/2015 10:31 AM, Mel Gorman wrote:
On Tue, May 05, 2015 at 09:55:52AM -0400, Waiman Long wrote:
On 05/05/2015 06:45 AM, Mel Gorman wrote:
On Mon, May 04, 2015 at 02:30:46PM -0700, Andrew Morton wrote:
Before the patch, the boot time from elilo prompt to ssh login
was 694s.
After the patch, the boot up time was 346s, a saving of 348s
(about 50%).
Having to guesstimate the amount of memory which is needed for a
successful boot will be painful. Any number we choose will be wrong
99% of the time.
If the kswapd threads have started, all we need to do is to wait:
take
a little nap in the allocator's page==NULL slowpath.
I'm not seeing any reason why we can't start kswapd much earlier -
right at the start of do_basic_setup()?
It doesn't even have to be kswapd, it just should be a thread
pinned to
a done. The difficulty is that dealing with the system hashes means
the
initialisation has to happen before vfs_caches_init_early() when
there is
no scheduler. Those allocations could be delayed further but then
there is
the possibility that the allocations would not be contiguous and
they'd
have to rely on CMA to make the attempt. That potentially alters the
performance of the large system hashes at run time.
We can scale the amount initialised with memory sizes relatively easy.
This boots on the same 1TB machine I was testing before but that is
hardly a surprise.
---8<---
mm: meminit: Take into account that large system caches scale
linearly with memory
Waiman Long reported a 24TB machine triggered an OOM as parallel
memory
initialisation deferred too much memory for initialisation. The likely
consumer of this memory was large system hashes that scale with memory
size. This patch initialises at least 2G per node but scales the
amount
initialised for larger systems.
Signed-off-by: Mel Gorman
---
mm/page_alloc.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 598f78d6544c..f7cc6c9fb909 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -266,15 +266,16 @@ static inline bool
early_page_nid_uninitialised(unsigned long pfn, int nid)
*/
static inline bool update_defer_init(pg_data_t *pgdat,
unsigned long pfn, unsigned long zone_end,
+unsigned long max_initialise,
unsigned long *nr_initialised)
{
/* Always populate low zones for address-contrained
allocations */
if (zone_end< pgdat_end_pfn(pgdat))
return true;
-/* Initialise at least 2G of the highest zone */
+/* Initialise at least the requested amount in the highest
zone */
(*nr_initialised)++;
-if (*nr_initialised> (2UL<< (30 - PAGE_SHIFT))&&
+if ((*nr_initialised> max_initialise)&&
(pfn& (PAGES_PER_SECTION - 1)) == 0) {
pgdat->first_deferred_pfn = pfn;
return false;
@@ -299,6 +300,7 @@ static inline bool
early_page_nid_uninitialised(unsigned long pfn, int nid)
static inline bool update_defer_init(pg_data_t *pgdat,
unsigned long pfn, unsigned long zone_end,
+unsigned long max_initialise,
unsigned long *nr_initialised)
{
return true;
@@ -4457,11 +4459,19 @@ void __meminit memmap_init_zone(unsigned
long size, int nid, unsigned long zone,
unsigned long end_pfn = start_pfn + size;
unsigned long pfn;
struct zone *z;
+unsigned long max_initialise;
unsigned long nr_initialised = 0;
if (highest_memmap_pfn< end_pfn - 1)
highest_memmap_pfn = end_pfn - 1;
+/*
+ * Initialise at least 2G of a node but also take into account
that
+ * two large system hashes that can take up an 8th of memory.
+ */
+max_initialise = min(2UL<< (30 - PAGE_SHIFT),
+(pgdat->node_spanned_pages>> 3));
+
I think you may be pre-allocating too much memory here. On the 24-TB
machine, the size of the dentry and inode hash tables were 16G each.
So the ratio is about is about 32G/24T = 0.13%. I think a shift
factor of (>> 8) which is about 0.39% should be more than enough.
I was taking the most pessimistic value possible to match where those
hashes currently get allocated from so that the locality does not change
after the series is applied. Can you try both (>> 3) and (>> 8) and
see
do both work and if so, what the timing is?
Sure. I will try both and get you the results, hopefully by tomorrow
at the latest.
With the modified patch, both (>>3) and (>>8) worked without any
problem. The bootup times are:
1. Unpatch 4.0 kernel - 694s
2. Patch kernel with 4G/node - 346s
3. Patch kernel with (>>3) - 389s
4. Patch kernel with (>>8) - 353s
Cheers,
Longman
--
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
Re: [rtc-linux] [PATCH v3 3/3] MAINTAINERS: add Mediatek RTC driver
Hi Alexandre, On Tue, 2015-05-05 at 22:03 +0200, Alexandre Belloni wrote: > Hi, > > On 28/04/2015 at 15:35:56 +0800, Eddie Huang wrote : > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 2e5bbc0..eb80610 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -1223,6 +1223,13 @@ W: http://www.digriz.org.uk/ts78xx/kernel > > S: Maintained > > F: arch/arm/mach-orion5x/ts78xx-* > > > > +ARM/Mediatek RTC DRIVER > > +M: Eddie Huang > > +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) > > +L: linux-media...@lists.infradead.org (moderated for non-subscribers) > > +S: Maintained > > +F: drivers/rtc/rtc-mt* > > I feel like this is a bit broad. Unless you want to really maintain > rtc-mt* which I guess may not be only Mediatek in the future, I would > use the full filename here. You will probably remember to update it if > you add more, that may not be the case for other developers. > Yes, you are right, the rtc-mt* is too broad, use full filename is a better choice right now. Eddie -- 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 206/208] x86/fpu: Add CONFIG_X86_DEBUG_FPU=y FPU debugging code
* Borislav Petkov wrote:
> On Tue, May 05, 2015 at 07:58:30PM +0200, Ingo Molnar wrote:
> > There are various internal FPU state debugging checks that never
> > trigger in practice, but which are useful for FPU code development.
> >
> > Separate these out into CONFIG_X86_DEBUG_FPU=y, and also add a
> > couple of new ones.
> >
> > The size difference is about 0.5K of code on defconfig:
> >
> >textdata bss filename
> >150289062578816 1638400 vmlinux
> >150294302578816 1638400 vmlinux
> >
> > ( Keep this enabled by default until the new FPU code is debugged. )
> >
> > Cc: Andy Lutomirski
> > Cc: Borislav Petkov
> > Cc: Dave Hansen
> > Cc: Fenghua Yu
> > Cc: H. Peter Anvin
> > Cc: Linus Torvalds
> > Cc: Oleg Nesterov
> > Cc: Thomas Gleixner
> > Signed-off-by: Ingo Molnar
>
> ...
>
> > diff --git a/arch/x86/include/asm/fpu/internal.h
> > b/arch/x86/include/asm/fpu/internal.h
> > index a4c1b7dbf70e..d2a281bd5f45 100644
> > --- a/arch/x86/include/asm/fpu/internal.h
> > +++ b/arch/x86/include/asm/fpu/internal.h
> > @@ -59,6 +59,15 @@ extern void fpu__clear(struct fpu *fpu);
> > extern void fpu__init_check_bugs(void);
> > extern void fpu__resume_cpu(void);
> >
> > +/*
> > + * Debugging facility:
> > + */
> > +#ifdef CONFIG_X86_DEBUG_FPU
> > +# define WARN_ON_FPU(x) WARN_ON_ONCE(x)
> > +#else
> > +# define WARN_ON_FPU(x) ({ 0; })
>
> Shouldn't this be called FPU_WARN_ON() ?
So I wanted this to match the 'usual' WARN*() APIs in appearance, with
only at the end a small signal that this is conditional on FPU
debugging enabled. In terms of code, we should think of them as
WARN_ON()s. Slapping FPU_ in front of them distracts from that IMHO.
No strong feelings though.
Thanks,
Ingo
--
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 03/12] crypto: qat - address recursive dependency when fw signing is enabled
On Tue, May 05, 2015 at 05:44:21PM -0700, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" > > We're going to add firmware module signing support, but when we do > this we end up with the following recursive dependency. Fix this by > just depending on FW_LOADER, which is typically always enabled > anyway. > > mcgrof@ergon ~/linux-next (git::master)$ make allnoconfig > scripts/kconfig/conf --allnoconfig Kconfig > crypto/Kconfig:15:error: recursive dependency detected! > crypto/Kconfig:15: symbol CRYPTO is selected by SYSDATA_SIG > init/Kconfig:1880: symbol SYSDATA_SIG is selected by FIRMWARE_SIG > drivers/base/Kconfig:88:symbol FIRMWARE_SIG depends on FW_LOADER > drivers/base/Kconfig:80:symbol FW_LOADER is selected by CRYPTO_DEV_QAT > drivers/crypto/qat/Kconfig:1: symbol CRYPTO_DEV_QAT is selected by > CRYPTO_DEV_QAT_DH895xCC > drivers/crypto/qat/Kconfig:13: symbol CRYPTO_DEV_QAT_DH895xCC depends on > CRYPTO This doesn't look like a real cycle to me so perhaps we can fix kbuild to understand this? Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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: [rtc-linux] [PATCH v3 2/3] rtc: mediatek: Add MT6397 RTC driver
Hi Joe and Alexandre,
On Tue, 2015-05-05 at 23:01 +0200, Alexandre Belloni wrote:
> On 05/05/2015 at 13:44:21 -0700, Joe Perches wrote :
> > I suggest moving the time_after() test into the loop,
> > use break; and remove the exit label too.
> >
> > Maybe something like:
> >
> > while (1) {
> > ret = regmap_read(rtc->regmap, rtc->addr_base + RTC_BBPU,
> > );
> > if (ret < 0)
> > break;
> > if (!(data & RTC_BBPU_CBUSY))
> > break;
> > if (time_after(jiffies, timeout)) {
> > ret = -ETIMEDOUT;
> > break;
> > }
> > cpu_relax();
> > }
> >
> > return ret;
>
> That certainly looks more readable.
>
Thanks correct me that I put wrong paramters in time_after, and give me
good example. I will adopt your suggestion in next round.
Eddie
--
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.19 000/177] 3.19.7-stable review
On 05/05/2015 03:10 PM, Greg Kroah-Hartman wrote: On Sat, May 02, 2015 at 09:00:22PM +0200, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.19.7 release. There are 177 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Mon May 4 18:59:31 UTC 2015. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.19.7-rc1.gz and the diffstat can be found below. -rc2 is out now that should work properly: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.19.7-rc2.gz Build results: total: 125 pass: 125 fail: 0 Qemu test results: total: 30 pass: 30 fail: 0 Details are available at http://server.roeck-us.net:8010/builders. 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 3.10 00/65] 3.10.77-stable review
On 05/05/2015 03:05 PM, Greg Kroah-Hartman wrote: On Sat, May 02, 2015 at 09:03:30PM +0200, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.10.77 release. There are 65 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Mon May 4 19:00:04 UTC 2015. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.77-rc1.gz and the diffstat can be found below. Ok, due to all of the issues in the -rc1 release, there's a -rc2 out now that hopefully will boot for people now :) kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.77-rc2.gz Build results: total: 127 pass: 126 fail: 1 Failed builds: s390:allmodconfig Qemu test results: total: 27 pass: 27 fail: 0 Results are as expected. s390:allmodconfig fails because s390 does not support HAVE_GENERIC_HARDIRQS in v3.10, and that would be too difficult to fix (at least for me). Details are available at http://server.roeck-us.net:8010/builders. 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/
[tip:perf/core] perf tools: Use getconf to determine number of online CPUs
Commit-ID: 762abdc0c6c013425958cd9f5105f4e32268d434 Gitweb: http://git.kernel.org/tip/762abdc0c6c013425958cd9f5105f4e32268d434 Author: Will Deacon AuthorDate: Thu, 23 Apr 2015 15:00:16 +0100 Committer: Arnaldo Carvalho de Melo CommitDate: Mon, 4 May 2015 12:43:40 -0300 perf tools: Use getconf to determine number of online CPUs Parsing /proc/cpuinfo is a fiddly, arch-dependent business and a recent change to get it working for Sparc broke arm and arm64 platforms. Use sysconf to determine the number of online CPUs only parsing /proc/cpuinfo when sysconf is not available. Signed-off-by: Will Deacon Acked-by: Jiri Olsa Tested-by: Arnaldo Carvalho de Melo Cc: David Ahern Cc: Mark Rutland Cc: Namhyung Kim Link: http://lkml.kernel.org/r/20150423140454.gj1...@arm.com [ Made it fall back to parsing /proc when getconf not found ] Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/Makefile b/tools/perf/Makefile index c699dc3..d31a7bb 100644 --- a/tools/perf/Makefile +++ b/tools/perf/Makefile @@ -24,7 +24,7 @@ unexport MAKEFLAGS # (To override it, run 'make JOBS=1' and similar.) # ifeq ($(JOBS),) - JOBS := $(shell egrep -c '^processor|^CPU' /proc/cpuinfo 2>/dev/null) + JOBS := $(shell (getconf _NPROCESSORS_ONLN || egrep -c '^processor|^CPU[0-9]' /proc/cpuinfo) 2>/dev/null) ifeq ($(JOBS),0) JOBS := 1 endif -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf probe ppc: Enable matching against dot symbols automatically
Commit-ID: 031b84c407c3153ffbcb4f8f832edf48af988719
Gitweb: http://git.kernel.org/tip/031b84c407c3153ffbcb4f8f832edf48af988719
Author: Naveen N. Rao
AuthorDate: Tue, 28 Apr 2015 17:35:37 +0530
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 4 May 2015 12:43:44 -0300
perf probe ppc: Enable matching against dot symbols automatically
Allow perf probe to work on ppc ABIv1 without the need to specify the
leading dot '.' for functions. 'perf probe do_fork' works with this
patch.
We do this by changing how symbol name comparison works on ppc ABIv1 -
we simply ignore and skip over the initial dot, if one exists, during
symbol name comparison.
Signed-off-by: Naveen N. Rao
Reviewed-by: Srikar Dronamraju
Cc: Ananth N Mavinakayanahalli
Cc: Masami Hiramatsu
Cc: Michael Ellerman
Cc: Sukadev Bhattiprolu
Cc: linuxppc-...@lists.ozlabs.org
Link:
http://lkml.kernel.org/r/652a8f3bfa919bd02a1836a128370eaed59b4a34.1430217967.git.naveen.n@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/arch/powerpc/util/sym-handling.c | 13 +
tools/perf/util/map.c | 5 +
tools/perf/util/map.h | 3 ++-
tools/perf/util/symbol.c| 4 ++--
4 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/tools/perf/arch/powerpc/util/sym-handling.c
b/tools/perf/arch/powerpc/util/sym-handling.c
index 5522a40..2de2cc4 100644
--- a/tools/perf/arch/powerpc/util/sym-handling.c
+++ b/tools/perf/arch/powerpc/util/sym-handling.c
@@ -8,6 +8,7 @@
#include "debug.h"
#include "symbol.h"
+#include "map.h"
#ifdef HAVE_LIBELF_SUPPORT
bool elf__needs_adjust_symbols(GElf_Ehdr ehdr)
@@ -36,4 +37,16 @@ int arch__choose_best_symbol(struct symbol *syma,
return SYMBOL_A;
}
+
+/* Allow matching against dot variants */
+int arch__compare_symbol_names(const char *namea, const char *nameb)
+{
+ /* Skip over initial dot */
+ if (*namea == '.')
+ namea++;
+ if (*nameb == '.')
+ nameb++;
+
+ return strcmp(namea, nameb);
+}
#endif
diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index a14f08f..cd0e335 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -292,6 +292,11 @@ int map__load(struct map *map, symbol_filter_t filter)
return 0;
}
+int __weak arch__compare_symbol_names(const char *namea, const char *nameb)
+{
+ return strcmp(namea, nameb);
+}
+
struct symbol *map__find_symbol(struct map *map, u64 addr,
symbol_filter_t filter)
{
diff --git a/tools/perf/util/map.h b/tools/perf/util/map.h
index ec19c59..4e0c729 100644
--- a/tools/perf/util/map.h
+++ b/tools/perf/util/map.h
@@ -124,7 +124,7 @@ struct thread;
*/
#define __map__for_each_symbol_by_name(map, sym_name, pos, filter) \
for (pos = map__find_symbol_by_name(map, sym_name, filter); \
-pos && strcmp(pos->name, sym_name) == 0; \
+pos && arch__compare_symbol_names(pos->name, sym_name) == 0;
\
pos = symbol__next_by_name(pos))
#define map__for_each_symbol_by_name(map, sym_name, pos) \
@@ -132,6 +132,7 @@ struct thread;
typedef int (*symbol_filter_t)(struct map *map, struct symbol *sym);
+int arch__compare_symbol_names(const char *namea, const char *nameb);
void map__init(struct map *map, enum map_type type,
u64 start, u64 end, u64 pgoff, struct dso *dso);
struct map *map__new(struct machine *machine, u64 start, u64 len,
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index f805757..45ba48a 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -411,7 +411,7 @@ static struct symbol *symbols__find_by_name(struct rb_root
*symbols,
int cmp;
s = rb_entry(n, struct symbol_name_rb_node, rb_node);
- cmp = strcmp(name, s->sym.name);
+ cmp = arch__compare_symbol_names(name, s->sym.name);
if (cmp < 0)
n = n->rb_left;
@@ -429,7 +429,7 @@ static struct symbol *symbols__find_by_name(struct rb_root
*symbols,
struct symbol_name_rb_node *tmp;
tmp = rb_entry(n, struct symbol_name_rb_node, rb_node);
- if (strcmp(tmp->sym.name, s->sym.name))
+ if (arch__compare_symbol_names(tmp->sym.name, s->sym.name))
break;
s = tmp;
--
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/
[LKP] [mm] c1c2ee950be: PANIC: early exception 06 rip 10:ffffffff811de134 error 0 cr2 ffff880005728000
FYI, we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
commit c1c2ee950beab73909ab0dbeb75a235e174d5301 ("mm: meminit: reduce number of
times pageblocks are set during struct page init")
+--+++
| | 8abe0b240f | c1c2ee950b |
+--+++
| boot_successes | 22 | 0 |
| early-boot-hang | 1 ||
| boot_failures| 0 | 10 |
| BUG:kernel_boot_hang | 0 | 10 |
+--+++
[0.00] On node 0 totalpages: 92030
[0.00] DMA zone: 64 pages used for memmap
[0.00] DMA zone: 21 pages reserved
[0.00] DMA zone: 3998 pages, LIFO batch:0
[0.00] DMA32 zone: 1376 pages used for memmap
[0.00] DMA32 zone: 88032 pages, LIFO batch:15
[0.00] page:ea04 count:0 mapcount:1 mapping:
(null) index:0x0
[0.00] flags: 0x0()
[0.00] page dumped because: VM_BUG_ON_PAGE(!zone_spans_pfn(zone, pfn))
PANIC: early exception 06 rip 10:811de134 error 0 cr2 880005728000
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.1.0-rc1-00171-gc1c2ee9
#1
[0.00] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.7.5-20140531_083030-gandalf 04/01/2014
[0.00] ea04 82ed7c80 8235d9a5
03f8
[0.00] 0010 82ed7d68 840261b0
[0.00] 047b 0001
0006
[0.00] Call Trace:
[0.00] [] dump_stack+0xa0/0xd5
[0.00] [] early_idt_handler+0x90/0xb7
[0.00] [] ? up+0x55/0x61
[0.00] [] ? set_pfnblock_flags_mask+0x9a/0x100
[0.00] [] ? set_pfnblock_flags_mask+0x93/0x100
[0.00] [] set_pageblock_migratetype+0x52/0x5b
[0.00] [] memmap_init_zone+0xf8/0x168
[0.00] [] free_area_init_node+0x47e/0x4e5
[0.00] [] free_area_init_nodes+0x30e/0x35e
[0.00] [] zone_sizes_init+0x57/0x60
[0.00] [] paging_init+0x4a/0x53
[0.00] [] setup_arch+0x10e9/0x126a
[0.00] [] ? vprintk_default+0x24/0x2d
[0.00] [] ? early_idt_handlers+0x120/0x120
[0.00] [] start_kernel+0x141/0x7c3
[0.00] [] ? early_idt_handlers+0x120/0x120
[0.00] [] x86_64_start_reservations+0x46/0x4f
[0.00] [] x86_64_start_kernel+0x1d7/0x1ed
[0.00] RIP 0x0
Thanks,
Ying Huang
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.1.0-rc1 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
CONFIG_KERNEL_LZMA=y
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
# CONFIG_USELIB is not set
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
# CONFIG_AUDITSYSCALL is not set
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
[tip:perf/core] perf probe ppc64le: Prefer symbol table lookup over DWARF
Commit-ID: d5c2e2c17ae1d630ddbceb53a264f24cc99703a4
Gitweb: http://git.kernel.org/tip/d5c2e2c17ae1d630ddbceb53a264f24cc99703a4
Author: Naveen N. Rao
AuthorDate: Tue, 28 Apr 2015 17:35:39 +0530
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 4 May 2015 12:43:46 -0300
perf probe ppc64le: Prefer symbol table lookup over DWARF
Use symbol table lookups by default if DWARF is not necessary, since
powerpc ABIv2 encodes local entry points in the symbol table and the
function entry address in DWARF may not be appropriate for kprobes, as
described here:
https://sourceware.org/bugzilla/show_bug.cgi?id=17638
"The DWARF address ranges deliberately include the *whole* function,
both global and local entry points."
...
"If you want to set probes on a local entry point, you should look up
the symbol in the main symbol table (not DWARF), and check the st_other
bits; they will indicate whether the function has a local entry point,
and what its offset from the global entry point is. Note that GDB does
the same when setting a breakpoint on a function entry."
Signed-off-by: Naveen N. Rao
Reviewed-by: Srikar Dronamraju
Cc: Ananth N Mavinakayanahalli
Cc: Masami Hiramatsu
Cc: Michael Ellerman
Cc: Sukadev Bhattiprolu
Cc: linuxppc-...@lists.ozlabs.org
Link:
http://lkml.kernel.org/r/88a10e22f4aaba2aef812824ca4b10d7beeea012.1430217967.git.naveen.n@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/arch/powerpc/util/sym-handling.c | 8
tools/perf/util/probe-event.c | 8
tools/perf/util/probe-event.h | 1 +
3 files changed, 17 insertions(+)
diff --git a/tools/perf/arch/powerpc/util/sym-handling.c
b/tools/perf/arch/powerpc/util/sym-handling.c
index 012a0f8..a170060 100644
--- a/tools/perf/arch/powerpc/util/sym-handling.c
+++ b/tools/perf/arch/powerpc/util/sym-handling.c
@@ -9,6 +9,7 @@
#include "debug.h"
#include "symbol.h"
#include "map.h"
+#include "probe-event.h"
#ifdef HAVE_LIBELF_SUPPORT
bool elf__needs_adjust_symbols(GElf_Ehdr ehdr)
@@ -57,3 +58,10 @@ int arch__compare_symbol_names(const char *namea, const char
*nameb)
return strcmp(namea, nameb);
}
#endif
+
+#if defined(_CALL_ELF) && _CALL_ELF == 2
+bool arch__prefers_symtab(void)
+{
+ return true;
+}
+#endif
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 291bf23..4dfb412 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -2567,6 +2567,8 @@ err_out:
goto out;
}
+bool __weak arch__prefers_symtab(void) { return false; }
+
static int convert_to_probe_trace_events(struct perf_probe_event *pev,
struct probe_trace_event **tevs,
int max_tevs, const char *target)
@@ -2582,6 +2584,12 @@ static int convert_to_probe_trace_events(struct
perf_probe_event *pev,
}
}
+ if (arch__prefers_symtab() && !perf_probe_event_need_dwarf(pev)) {
+ ret = find_probe_trace_events_from_map(pev, tevs, max_tevs,
target);
+ if (ret > 0)
+ return ret; /* Found in symbol table */
+ }
+
/* Convert perf_probe_event with debuginfo */
ret = try_to_find_probe_trace_events(pev, tevs, max_tevs, target);
if (ret != 0)
diff --git a/tools/perf/util/probe-event.h b/tools/perf/util/probe-event.h
index d6b7834..52bca4b 100644
--- a/tools/perf/util/probe-event.h
+++ b/tools/perf/util/probe-event.h
@@ -135,6 +135,7 @@ extern int show_available_vars(struct perf_probe_event
*pevs, int npevs,
struct strfilter *filter, bool externs);
extern int show_available_funcs(const char *module, struct strfilter *filter,
bool user);
+bool arch__prefers_symtab(void);
/* Maximum index number of event-name postfix */
#define MAX_EVENT_INDEX1024
--
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/
[tip:perf/core] perf probe ppc64le: Fix ppc64 ABIv2 symbol decoding
Commit-ID: c50fc0a43e33a6c3257c5cbb954cd747d7b9a680
Gitweb: http://git.kernel.org/tip/c50fc0a43e33a6c3257c5cbb954cd747d7b9a680
Author: Ananth N Mavinakayanahalli
AuthorDate: Tue, 28 Apr 2015 17:35:38 +0530
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 4 May 2015 12:43:45 -0300
perf probe ppc64le: Fix ppc64 ABIv2 symbol decoding
ppc64 ELF ABIv2 has a Global Entry Point (GEP) and a Local Entry Point
(LEP). For purposes of probing, we need the LEP - the offset to which is
encoded in st_other.
Signed-off-by: Ananth N Mavinakayanahalli
Reviewed-by: Srikar Dronamraju
Cc: Masami Hiramatsu
Cc: Michael Ellerman
Cc: Sukadev Bhattiprolu
Cc: linuxppc-...@lists.ozlabs.org
Link:
http://lkml.kernel.org/r/ab9cc5e2b9de4cbaaf50f6ef2346a6a81100bad1.1430217967.git.naveen.n@linux.vnet.ibm.com
Signed-off-by: Naveen N. Rao
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/arch/powerpc/util/sym-handling.c | 7 +++
tools/perf/util/symbol-elf.c| 4
tools/perf/util/symbol.h| 1 +
3 files changed, 12 insertions(+)
diff --git a/tools/perf/arch/powerpc/util/sym-handling.c
b/tools/perf/arch/powerpc/util/sym-handling.c
index 2de2cc4..012a0f8 100644
--- a/tools/perf/arch/powerpc/util/sym-handling.c
+++ b/tools/perf/arch/powerpc/util/sym-handling.c
@@ -17,6 +17,13 @@ bool elf__needs_adjust_symbols(GElf_Ehdr ehdr)
ehdr.e_type == ET_REL ||
ehdr.e_type == ET_DYN;
}
+
+#if defined(_CALL_ELF) && _CALL_ELF == 2
+void arch__elf_sym_adjust(GElf_Sym *sym)
+{
+ sym->st_value += PPC64_LOCAL_ENTRY_OFFSET(sym->st_other);
+}
+#endif
#endif
#if !defined(_CALL_ELF) || _CALL_ELF != 2
diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 54347ba..d99b442 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -775,6 +775,8 @@ static bool want_demangle(bool is_kernel_sym)
return is_kernel_sym ? symbol_conf.demangle_kernel :
symbol_conf.demangle;
}
+void __weak arch__elf_sym_adjust(GElf_Sym *sym __maybe_unused) { }
+
int dso__load_sym(struct dso *dso, struct map *map,
struct symsrc *syms_ss, struct symsrc *runtime_ss,
symbol_filter_t filter, int kmodule)
@@ -939,6 +941,8 @@ int dso__load_sym(struct dso *dso, struct map *map,
(sym.st_value & 1))
--sym.st_value;
+ arch__elf_sym_adjust();
+
if (dso->kernel || kmodule) {
char dso_name[PATH_MAX];
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index bd50ba0..9096529 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -305,6 +305,7 @@ int setup_intlist(struct intlist **list, const char
*list_str,
#ifdef HAVE_LIBELF_SUPPORT
bool elf__needs_adjust_symbols(GElf_Ehdr ehdr);
+void arch__elf_sym_adjust(GElf_Sym *sym);
#endif
#define SYMBOL_A 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 054/208] x86/fpu: Get rid of PF_USED_MATH usage, convert it to fpu->fpstate_active
* Andy Lutomirski wrote:
> > diff --git a/arch/x86/include/asm/fpu/types.h
> > b/arch/x86/include/asm/fpu/types.h
> > index efb520dcf38e..f6317d9aa808 100644
> > --- a/arch/x86/include/asm/fpu/types.h
> > +++ b/arch/x86/include/asm/fpu/types.h
> > @@ -137,6 +137,12 @@ struct fpu {
> > * deal with bursty apps that only use the FPU for a short time:
> > */
> > unsigned char counter;
> > + /*
> > +* This flag indicates whether this context is fpstate_active: if
> > the task is
> > +* not running then we can restore from this context, if the task
> > +* is running then we should save into this context.
> > +*/
> > + unsigned char fpstate_active;
>
> I don't understand. What does it mean if !fpstate_active?
Yeah, so this was just the 'simple' migration patch from PF_USED_FPU
to ->fpstate_active.
At the end of the series those fields get more love and a more
detailed explanation:
/*
* @fpstate_active:
*
* This flag indicates whether this context is active: if the task
* is not running then we can restore from this context, if the task
* is running then we should save into this context.
*/
unsigned char fpstate_active;
and its interaction with fpregs_active is explained as well:
/*
* @fpregs_active:
*
* This flag determines whether a given context is actively
* loaded into the FPU's registers and that those registers
* represent the task's current FPU state.
*
* Note the interaction with fpstate_active:
*
* # task does not use the FPU:
* fpstate_active == 0
*
* # task uses the FPU and regs are active:
* fpstate_active == 1 && fpregs_active == 1
*
* # the regs are inactive but still match fpstate:
* fpstate_active == 1 && fpregs_active == 0 && fpregs_owner == fpu
*
* The third state is what we use for the lazy restore optimization
* on lazy-switching CPUs.
*/
unsigned char fpregs_active;
Basically the 'fpstate' is the in-memory FPU state, and if it's
active, it means it can be copied to (saved to) and copied from
(restored from). Whether this fpstate is the currently representative
FPU state depends on the other state flag(s), as described.
Maybe I should have broken out the fourth state as well:
* # the fpstate holds all of a task's FPU state:
* fpstate_active == 1 && fpregs_active == 0 && fpregs_owner != fpu
?
active/inactive was one idiom that I felt worked pretty well - but I
considered others as well:
- dirty/clean (didn't work so well and too MM-ish)
- valid/invalid (likewise)
- used/unused (yuck)
Note:
There's a fifth valid state as well, but I did not want
to complicate the description even more: kernel_user_begin()/end()
users create this state with its own private in_kernel_fpu flag, in
that they use FPU registers but don't touch these (user-)flags.
kernel_user_begin()/end() is atomic and (beyond zapping pending lazy
restore state in fpu_fpregs_owner_ctx) it restores the FPU to the
previous state so it's pretty orthogonal as far as the other states
are concerned.
Note2:
I also considered renaming kernel_fpu_begin()/end() to the new
nomenclature, but it has a good name and I did not want too much
churn with a well-established API, which also mirrors
user_fpu_begin() conceptually. I also couldn't find a better name:
maybe fpu__kernel_save()/restore(), but that felt a bit strained.
Does this make things clearer? I can work on it some more if I got it
wrong or if the text is confusing somewhere, this is crucial IMHO.
Instead of binary states we could also unify them into a single state
variable - didn't find any really convincing naming concept for that
though, mostly because I think those states are fundamentally
separate, just interrelated.
Thanks,
Ingo
--
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/
[tip:perf/core] perf tools: Move TUI-specific fields out of map_symbol
Commit-ID: 3698dab1c849c7e1cd440df4fca24baa1973d53b
Gitweb: http://git.kernel.org/tip/3698dab1c849c7e1cd440df4fca24baa1973d53b
Author: Namhyung Kim
AuthorDate: Tue, 5 May 2015 23:55:46 +0900
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 5 May 2015 18:13:24 -0300
perf tools: Move TUI-specific fields out of map_symbol
The has_children and unfolded fields don't belong to the struct
map_symbol since they're used by the TUI only. Move those fields out of
map_symbol since the struct is also used by other places.
This will also help to compact the sizeof struct hist_entry.
Signed-off-by: Namhyung Kim
Cc: David Ahern
Cc: Jiri Olsa
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1429687101-4360-11-git-send-email-namhy...@kernel.org
Link:
http://lkml.kernel.org/r/1430837746-5439-1-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/ui/browsers/hists.c | 79 +-
tools/perf/util/callchain.h| 4 +++
tools/perf/util/hist.c | 2 +-
tools/perf/util/sort.h | 2 ++
tools/perf/util/symbol.h | 2 --
5 files changed, 54 insertions(+), 35 deletions(-)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 8733d57..f981cb8 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -63,7 +63,7 @@ static int hist_browser__get_folding(struct hist_browser
*browser)
struct hist_entry *he =
rb_entry(nd, struct hist_entry, rb_node);
- if (he->ms.unfolded)
+ if (he->unfolded)
unfolded_rows += he->nr_rows;
}
return unfolded_rows;
@@ -139,24 +139,19 @@ static char tree__folded_sign(bool unfolded)
return unfolded ? '-' : '+';
}
-static char map_symbol__folded(const struct map_symbol *ms)
-{
- return ms->has_children ? tree__folded_sign(ms->unfolded) : ' ';
-}
-
static char hist_entry__folded(const struct hist_entry *he)
{
- return map_symbol__folded(>ms);
+ return he->has_children ? tree__folded_sign(he->unfolded) : ' ';
}
static char callchain_list__folded(const struct callchain_list *cl)
{
- return map_symbol__folded(>ms);
+ return cl->has_children ? tree__folded_sign(cl->unfolded) : ' ';
}
-static void map_symbol__set_folding(struct map_symbol *ms, bool unfold)
+static void callchain_list__set_folding(struct callchain_list *cl, bool unfold)
{
- ms->unfolded = unfold ? ms->has_children : false;
+ cl->unfolded = unfold ? cl->has_children : false;
}
static int callchain_node__count_rows_rb_tree(struct callchain_node *node)
@@ -192,7 +187,7 @@ static int callchain_node__count_rows(struct callchain_node
*node)
list_for_each_entry(chain, >val, list) {
++n;
- unfolded = chain->ms.unfolded;
+ unfolded = chain->unfolded;
}
if (unfolded)
@@ -214,15 +209,27 @@ static int callchain__count_rows(struct rb_root *chain)
return n;
}
-static bool map_symbol__toggle_fold(struct map_symbol *ms)
+static bool hist_entry__toggle_fold(struct hist_entry *he)
{
- if (!ms)
+ if (!he)
return false;
- if (!ms->has_children)
+ if (!he->has_children)
return false;
- ms->unfolded = !ms->unfolded;
+ he->unfolded = !he->unfolded;
+ return true;
+}
+
+static bool callchain_list__toggle_fold(struct callchain_list *cl)
+{
+ if (!cl)
+ return false;
+
+ if (!cl->has_children)
+ return false;
+
+ cl->unfolded = !cl->unfolded;
return true;
}
@@ -238,10 +245,10 @@ static void
callchain_node__init_have_children_rb_tree(struct callchain_node *no
list_for_each_entry(chain, >val, list) {
if (first) {
first = false;
- chain->ms.has_children = chain->list.next !=
>val ||
+ chain->has_children = chain->list.next !=
>val ||
!RB_EMPTY_ROOT(>rb_root);
} else
- chain->ms.has_children = chain->list.next ==
>val &&
+ chain->has_children = chain->list.next ==
>val &&
!RB_EMPTY_ROOT(>rb_root);
}
@@ -255,11 +262,11 @@ static void callchain_node__init_have_children(struct
callchain_node *node,
struct callchain_list *chain;
chain = list_entry(node->val.next, struct callchain_list, list);
- chain->ms.has_children = has_sibling;
+ chain->has_children = has_sibling;
if (!list_empty(>val)) {
chain = list_entry(node->val.prev, struct callchain_list, list);
- chain->ms.has_children =
[tip:perf/core] perf hists browser: Simplify zooming code using pstack_peek()
Commit-ID: 6422184b087ff4355951d72e0bb320f52e107185
Gitweb: http://git.kernel.org/tip/6422184b087ff4355951d72e0bb320f52e107185
Author: Namhyung Kim
AuthorDate: Fri, 24 Apr 2015 10:15:33 +0900
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 5 May 2015 18:13:23 -0300
perf hists browser: Simplify zooming code using pstack_peek()
Now LEFT key press action can just use do_zoom_dso/thread() code to get
out of the current filter.
Signed-off-by: Namhyung Kim
Acked-by: Jiri Olsa
Cc: David Ahern
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1429838133-14001-2-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/ui/browsers/hists.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 9bd7b38..8733d57 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -1860,19 +1860,17 @@ static int perf_evsel__hists_browse(struct perf_evsel
*evsel, int nr_events,
goto out_free_stack;
continue;
}
- top = pstack__pop(browser->pstack);
+ top = pstack__peek(browser->pstack);
if (top == >hists->dso_filter) {
- perf_hpp__set_elide(HISTC_DSO, false);
- browser->hists->dso_filter = NULL;
- hists__filter_by_dso(browser->hists);
- }
- if (top == >hists->thread_filter) {
- perf_hpp__set_elide(HISTC_THREAD, false);
- thread__zput(browser->hists->thread_filter);
- hists__filter_by_thread(browser->hists);
+ /*
+* No need to set actions->dso here since
+* it's just to remove the current filter.
+* Ditto for thread below.
+*/
+ do_zoom_dso(browser, actions);
}
- ui_helpline__pop();
- hist_browser__reset(browser);
+ if (top == >hists->thread_filter)
+ do_zoom_thread(browser, actions);
continue;
}
case K_ESC:
--
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: Issue in PI boosting code in __sched_setscheduler
On Wed, 6 May 2015 05:14:18 +0200 Ronny Meeus wrote: > Thanks for looking into this. > > It looks to me that real-time priority threads are not used in many > systems because we discovered already several issues, both in the > kernel and glibc while we are using Linux only recently. > Do you have a view on this? > View on what? Anyway, did you see the patch Thomas sent out? Subject: [PATCH V2] sched: Handle priority boosted tasks proper in setscheduler() It solves this current issue. -- 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/
[tip:perf/core] perf tools: Introduce pstack_peek()
Commit-ID: c8539e3fc630067020814657636b45095edfb5bb
Gitweb: http://git.kernel.org/tip/c8539e3fc630067020814657636b45095edfb5bb
Author: Namhyung Kim
AuthorDate: Fri, 24 Apr 2015 10:15:32 +0900
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 5 May 2015 18:13:22 -0300
perf tools: Introduce pstack_peek()
The pstack_peek() is to get the topmost entry without removing it.
Signed-off-by: Namhyung Kim
Acked-by: Jiri Olsa
Cc: David Ahern
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1429838133-14001-1-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/pstack.c | 7 +++
tools/perf/util/pstack.h | 1 +
2 files changed, 8 insertions(+)
diff --git a/tools/perf/util/pstack.c b/tools/perf/util/pstack.c
index a126e6c..b234a6e 100644
--- a/tools/perf/util/pstack.c
+++ b/tools/perf/util/pstack.c
@@ -74,3 +74,10 @@ void *pstack__pop(struct pstack *pstack)
pstack->entries[pstack->top] = NULL;
return ret;
}
+
+void *pstack__peek(struct pstack *pstack)
+{
+ if (pstack->top == 0)
+ return NULL;
+ return pstack->entries[pstack->top - 1];
+}
diff --git a/tools/perf/util/pstack.h b/tools/perf/util/pstack.h
index c3cb658..ded7f2e 100644
--- a/tools/perf/util/pstack.h
+++ b/tools/perf/util/pstack.h
@@ -10,5 +10,6 @@ bool pstack__empty(const struct pstack *pstack);
void pstack__remove(struct pstack *pstack, void *key);
void pstack__push(struct pstack *pstack, void *key);
void *pstack__pop(struct pstack *pstack);
+void *pstack__peek(struct pstack *pstack);
#endif /* _PERF_PSTACK_ */
--
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/
[tip:perf/core] perf kmem: Show warning when trying to run stat without record
Commit-ID: a923e2c4b14f99f70692f82ee7bd63717604b738
Gitweb: http://git.kernel.org/tip/a923e2c4b14f99f70692f82ee7bd63717604b738
Author: Namhyung Kim
AuthorDate: Tue, 5 May 2015 23:52:52 +0900
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 5 May 2015 18:13:08 -0300
perf kmem: Show warning when trying to run stat without record
Sometimes one can mistakenly run 'perf kmem stat' without running 'perf
kmem record' before or with a different configuration like recording
--slab and stat --page. Show a warning message like the one below to
inform the user:
# perf kmem stat --page --caller
No page allocation events found. Have you run 'perf kmem record --page'?
Signed-off-by: Namhyung Kim
Acked-by: Pekka Enberg
Cc: David Ahern
Cc: Jiri Olsa
Cc: Joonsoo Kim
Cc: Minchan Kim
Cc: Peter Zijlstra
Cc: linux...@kvack.org
Link:
http://lkml.kernel.org/r/1430837572-31395-1-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-kmem.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/tools/perf/builtin-kmem.c b/tools/perf/builtin-kmem.c
index 828b728..e628bf1 100644
--- a/tools/perf/builtin-kmem.c
+++ b/tools/perf/builtin-kmem.c
@@ -1882,6 +1882,7 @@ int cmd_kmem(int argc, const char **argv, const char
*prefix __maybe_unused)
};
struct perf_session *session;
int ret = -1;
+ const char errmsg[] = "No %s allocation events found. Have you run
'perf kmem record --%s'?\n";
perf_config(kmem_config, NULL);
argc = parse_options_subcommand(argc, argv, kmem_options,
@@ -1908,11 +1909,21 @@ int cmd_kmem(int argc, const char **argv, const char
*prefix __maybe_unused)
if (session == NULL)
return -1;
+ if (kmem_slab) {
+ if (!perf_evlist__find_tracepoint_by_name(session->evlist,
+ "kmem:kmalloc")) {
+ pr_err(errmsg, "slab", "slab");
+ return -1;
+ }
+ }
+
if (kmem_page) {
- struct perf_evsel *evsel = perf_evlist__first(session->evlist);
+ struct perf_evsel *evsel;
- if (evsel == NULL || evsel->tp_format == NULL) {
- pr_err("invalid event found.. aborting\n");
+ evsel = perf_evlist__find_tracepoint_by_name(session->evlist,
+
"kmem:mm_page_alloc");
+ if (evsel == NULL) {
+ pr_err(errmsg, "page", "page");
return -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/
[tip:perf/core] perf hists browser: Save perf_session_env in the hist_browser
Commit-ID: b1a9ceef724341ce05b125d39abf9cfc7059b949
Gitweb: http://git.kernel.org/tip/b1a9ceef724341ce05b125d39abf9cfc7059b949
Author: Namhyung Kim
AuthorDate: Wed, 22 Apr 2015 16:18:17 +0900
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 5 May 2015 18:13:17 -0300
perf hists browser: Save perf_session_env in the hist_browser
The perf_session_env is to save system informantion at the recording
time to be refered in the hist browser. So it'd be better to keep in
the struct hist_browser. This is a preparation to later change.
Signed-off-by: Namhyung Kim
Acked-by: Jiri Olsa
Cc: David Ahern
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1429687101-4360-7-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/ui/browsers/hists.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 26d5548..45704d6 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -27,6 +27,7 @@ struct hist_browser {
struct map_symbol *selection;
struct hist_browser_timer *hbt;
struct pstack *pstack;
+ struct perf_session_env *env;
int print_seq;
bool show_dso;
bool show_headers;
@@ -1198,7 +1199,8 @@ static int hist_browser__dump(struct hist_browser
*browser)
}
static struct hist_browser *hist_browser__new(struct hists *hists,
- struct hist_browser_timer *hbt)
+ struct hist_browser_timer *hbt,
+ struct perf_session_env *env)
{
struct hist_browser *browser = zalloc(sizeof(*browser));
@@ -1210,6 +1212,7 @@ static struct hist_browser *hist_browser__new(struct
hists *hists,
browser->b.use_navkeypressed = true;
browser->show_headers = symbol_conf.show_hist_headers;
browser->hbt = hbt;
+ browser->env = env;
}
return browser;
@@ -1425,7 +1428,7 @@ static int perf_evsel__hists_browse(struct perf_evsel
*evsel, int nr_events,
struct perf_session_env *env)
{
struct hists *hists = evsel__hists(evsel);
- struct hist_browser *browser = hist_browser__new(hists, hbt);
+ struct hist_browser *browser = hist_browser__new(hists, hbt, env);
struct branch_info *bi;
#define MAX_OPTIONS 16
char *options[MAX_OPTIONS];
--
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/
[tip:perf/core] perf hists browser: Split popup menu actions - part 2
Commit-ID: ea7cd59233097984850adc0e4119644f089be734
Gitweb: http://git.kernel.org/tip/ea7cd59233097984850adc0e4119644f089be734
Author: Namhyung Kim
AuthorDate: Wed, 22 Apr 2015 16:18:19 +0900
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 5 May 2015 18:13:20 -0300
perf hists browser: Split popup menu actions - part 2
Currently perf_evsel__hists_browse() function spins on a huge loop and
handles many key actions. Since it's hard to read and modify, let's
split it out into small helper functions.
The add_XXX_opt() functions are to register popup menu item on the
selected entry. When it adds an item, it also saves related data into
struct popup_action and returns 1 so that it can increase the number of
items (nr_options).
With this change, we can simplify the code just to call selected
callback function without considering various conditions. A callback
function named do_XXX is called with saved data when the item is
selected by user.
No functional change intended.
Signed-off-by: Namhyung Kim
Acked-by: Jiri Olsa
Cc: David Ahern
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1429687101-4360-9-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/ui/browsers/hists.c | 354 +
1 file changed, 214 insertions(+), 140 deletions(-)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 7d88a1c..9bd7b38 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -1402,8 +1402,16 @@ close_file_and_continue:
return ret;
}
+struct popup_action {
+ struct thread *thread;
+ struct dso *dso;
+ struct map_symbol ms;
+
+ int (*fn)(struct hist_browser *browser, struct popup_action *act);
+};
+
static int
-do_annotate(struct hist_browser *browser, struct map_symbol *ms)
+do_annotate(struct hist_browser *browser, struct popup_action *act)
{
struct perf_evsel *evsel;
struct annotation *notes;
@@ -1413,12 +1421,12 @@ do_annotate(struct hist_browser *browser, struct
map_symbol *ms)
if (!objdump_path && perf_session_env__lookup_objdump(browser->env))
return 0;
- notes = symbol__annotation(ms->sym);
+ notes = symbol__annotation(act->ms.sym);
if (!notes->src)
return 0;
evsel = hists_to_evsel(browser->hists);
- err = map_symbol__tui_annotate(ms, evsel, browser->hbt);
+ err = map_symbol__tui_annotate(>ms, evsel, browser->hbt);
he = hist_browser__selected_entry(browser);
/*
* offer option to annotate the other branch source or target
@@ -1434,8 +1442,27 @@ do_annotate(struct hist_browser *browser, struct
map_symbol *ms)
}
static int
-do_zoom_thread(struct hist_browser *browser, struct thread *thread)
+add_annotate_opt(struct hist_browser *browser __maybe_unused,
+struct popup_action *act, char **optstr,
+struct map *map, struct symbol *sym)
{
+ if (sym == NULL || map->dso->annotate_warned)
+ return 0;
+
+ if (asprintf(optstr, "Annotate %s", sym->name) < 0)
+ return 0;
+
+ act->ms.map = map;
+ act->ms.sym = sym;
+ act->fn = do_annotate;
+ return 1;
+}
+
+static int
+do_zoom_thread(struct hist_browser *browser, struct popup_action *act)
+{
+ struct thread *thread = act->thread;
+
if (browser->hists->thread_filter) {
pstack__remove(browser->pstack, >hists->thread_filter);
perf_hpp__set_elide(HISTC_THREAD, false);
@@ -1456,8 +1483,28 @@ do_zoom_thread(struct hist_browser *browser, struct
thread *thread)
}
static int
-do_zoom_dso(struct hist_browser *browser, struct dso *dso)
+add_thread_opt(struct hist_browser *browser, struct popup_action *act,
+ char **optstr, struct thread *thread)
+{
+ if (thread == NULL)
+ return 0;
+
+ if (asprintf(optstr, "Zoom %s %s(%d) thread",
+browser->hists->thread_filter ? "out of" : "into",
+thread->comm_set ? thread__comm_str(thread) : "",
+thread->tid) < 0)
+ return 0;
+
+ act->thread = thread;
+ act->fn = do_zoom_thread;
+ return 1;
+}
+
+static int
+do_zoom_dso(struct hist_browser *browser, struct popup_action *act)
{
+ struct dso *dso = act->dso;
+
if (browser->hists->dso_filter) {
pstack__remove(browser->pstack, >hists->dso_filter);
perf_hpp__set_elide(HISTC_DSO, false);
@@ -1479,25 +1526,58 @@ do_zoom_dso(struct hist_browser *browser, struct dso
*dso)
}
static int
-do_browse_map(struct hist_browser *browser __maybe_unused, struct map *map)
+add_dso_opt(struct hist_browser *browser, struct popup_action *act,
+ char **optstr, struct dso *dso)
{
- map__browse(map);
+ if (dso == NULL)
+
[tip:perf/core] perf hists browser: Split popup menu actions
Commit-ID: bc7cad429bcdda6f112525c17db9577a1be4c8aa
Gitweb: http://git.kernel.org/tip/bc7cad429bcdda6f112525c17db9577a1be4c8aa
Author: Namhyung Kim
AuthorDate: Wed, 22 Apr 2015 16:18:18 +0900
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 5 May 2015 18:13:19 -0300
perf hists browser: Split popup menu actions
Currently perf_evsel__hists_browse() function spins on a huge loop and
handles many key actions. Since it's hard to read and modify, let's
split it out into small helper functions.
This patch introduces do_XXX() functions which corresponds to each goto
label. This way we can call such functions both from key press actions
and popup menu actions.
No functional change intended.
Signed-off-by: Namhyung Kim
Acked-by: Jiri Olsa
Cc: David Ahern
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1429687101-4360-8-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/ui/browsers/hists.c | 242 ++---
1 file changed, 156 insertions(+), 86 deletions(-)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 45704d6..7d88a1c 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -1402,6 +1402,120 @@ close_file_and_continue:
return ret;
}
+static int
+do_annotate(struct hist_browser *browser, struct map_symbol *ms)
+{
+ struct perf_evsel *evsel;
+ struct annotation *notes;
+ struct hist_entry *he;
+ int err;
+
+ if (!objdump_path && perf_session_env__lookup_objdump(browser->env))
+ return 0;
+
+ notes = symbol__annotation(ms->sym);
+ if (!notes->src)
+ return 0;
+
+ evsel = hists_to_evsel(browser->hists);
+ err = map_symbol__tui_annotate(ms, evsel, browser->hbt);
+ he = hist_browser__selected_entry(browser);
+ /*
+* offer option to annotate the other branch source or target
+* (if they exists) when returning from annotate
+*/
+ if ((err == 'q' || err == CTRL('c')) && he->branch_info)
+ return 1;
+
+ ui_browser__update_nr_entries(>b, browser->hists->nr_entries);
+ if (err)
+ ui_browser__handle_resize(>b);
+ return 0;
+}
+
+static int
+do_zoom_thread(struct hist_browser *browser, struct thread *thread)
+{
+ if (browser->hists->thread_filter) {
+ pstack__remove(browser->pstack, >hists->thread_filter);
+ perf_hpp__set_elide(HISTC_THREAD, false);
+ thread__zput(browser->hists->thread_filter);
+ ui_helpline__pop();
+ } else {
+ ui_helpline__fpush("To zoom out press <- or -> + \"Zoom out of
%s(%d) thread\"",
+ thread->comm_set ? thread__comm_str(thread)
: "",
+ thread->tid);
+ browser->hists->thread_filter = thread__get(thread);
+ perf_hpp__set_elide(HISTC_THREAD, false);
+ pstack__push(browser->pstack, >hists->thread_filter);
+ }
+
+ hists__filter_by_thread(browser->hists);
+ hist_browser__reset(browser);
+ return 0;
+}
+
+static int
+do_zoom_dso(struct hist_browser *browser, struct dso *dso)
+{
+ if (browser->hists->dso_filter) {
+ pstack__remove(browser->pstack, >hists->dso_filter);
+ perf_hpp__set_elide(HISTC_DSO, false);
+ browser->hists->dso_filter = NULL;
+ ui_helpline__pop();
+ } else {
+ if (dso == NULL)
+ return 0;
+ ui_helpline__fpush("To zoom out press <- or -> + \"Zoom out of
%s DSO\"",
+ dso->kernel ? "the Kernel" :
dso->short_name);
+ browser->hists->dso_filter = dso;
+ perf_hpp__set_elide(HISTC_DSO, true);
+ pstack__push(browser->pstack, >hists->dso_filter);
+ }
+
+ hists__filter_by_dso(browser->hists);
+ hist_browser__reset(browser);
+ return 0;
+}
+
+static int
+do_browse_map(struct hist_browser *browser __maybe_unused, struct map *map)
+{
+ map__browse(map);
+ return 0;
+}
+
+static int
+do_run_script(struct hist_browser *browser __maybe_unused,
+ struct thread *thread, struct symbol *sym)
+{
+ char script_opt[64];
+ memset(script_opt, 0, sizeof(script_opt));
+
+ if (thread) {
+ scnprintf(script_opt, sizeof(script_opt), " -c %s ",
+ thread__comm_str(thread));
+ } else if (sym) {
+ scnprintf(script_opt, sizeof(script_opt), " -S %s ",
+ sym->name);
+ }
+
+ script_browse(script_opt);
+ return 0;
+}
+
+static int
+do_switch_data(struct hist_browser *browser __maybe_unused, int key)
+{
+ if (switch_data_file()) {
+ ui__warning("Won't switch the data files due to\n"
+
