Re: [PATCH v5 5/6] MCS Lock: Restructure the MCS lock defines and locking code into its own file
On Tue, Sep 24, 2013 at 03:22:46PM -0700, Tim Chen wrote: > We will need the MCS lock code for doing optimistic spinning for rwsem. > Extracting the MCS code from mutex.c and put into its own file allow us > to reuse this code easily for rwsem. > > Signed-off-by: Tim Chen > Signed-off-by: Davidlohr Bueso > --- > kernel/mutex.c | 58 ++- > 1 files changed, 7 insertions(+), 51 deletions(-) Wasn't this patch supposed to add include/linux/mcslock.h ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 7/7] ARM: shmobile: ape6evm-reference: enable DMA for the MMC interface
On Fri, Aug 02, 2013 at 04:50:42PM +0200, Guennadi Liakhovetski wrote: > This patch adds DMA slave bindings for the two required DMA channels > for MMCIF0 to ape6evm-reference. > > Signed-off-by: Guennadi Liakhovetski Does this patch depend on any of the other paches in this series? > --- > arch/arm/boot/dts/r8a73a4-ape6evm-reference.dts |3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/boot/dts/r8a73a4-ape6evm-reference.dts > b/arch/arm/boot/dts/r8a73a4-ape6evm-reference.dts > index 6797fac..631086a 100644 > --- a/arch/arm/boot/dts/r8a73a4-ape6evm-reference.dts > +++ b/arch/arm/boot/dts/r8a73a4-ape6evm-reference.dts > @@ -112,6 +112,9 @@ > vmmc-supply = <_mmc0>; > bus-width = <8>; > non-removable; > + dmas = < 0xd1 > + 0xd2>; > + dma-names = "tx", "rx"; > pinctrl-names = "default"; > pinctrl-0 = <_pins>; > status = "okay"; > -- > 1.7.2.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: [RFC PATCH] freezer: allow killing of frozen tasks
On Tue, Aug 20, 2013 at 9:41 PM, Rafael J. Wysocki wrote: > On Tuesday, August 20, 2013 08:27:27 AM Tejun Heo wrote: >> On Tue, Aug 20, 2013 at 02:34:14PM +0200, Rafael J. Wysocki wrote: >> > On Tuesday, August 20, 2013 08:22:00 AM Tejun Heo wrote: >> > > On Tue, Aug 20, 2013 at 02:30:18PM +0200, Rafael J. Wysocki wrote: >> > > > > So, I don't think we can simply turn TASK_UNITERRUPTIBLE to >> > > > > TASK_KILLABLE at this point. We really need to strictly define where >> > > > > a task can freeze before being able to do anything like this. >> > > > >> > > > But we could do that for user space tasks I suppose? >> > > >> > > Even for userland tasks, we don't know where the task is stuck at. I >> > > think there are enough freeze points in the kernel which are in the >> > > middle of something which can be used by userland tasks excuting some >> > > syscall. We need to collect all those sites into well defined trap >> > > points before doing this. >> > >> > OK, thanks! >> >> I scanned through try_to_freeze() users and it seems like we don't >> have that many which can be hit by userland tasks. I think it should >> be doable to audit all the users, remove the ones which can be invoked >> by userland and make try_to_freeze() whine loudly if it's running off >> a userland task except from well-defined spots. > > Which might be worth doing anyway to be sure we know what's going on. > >> Anyways, we need to ensure that userland task doesn't get stuck deep in the >> kernel before allowing this. > > Agreed. Are there any update? we need this feature to kill frozen app easily. Don't need to thaw app to kill. Thank you, Kyungmin Park -- 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 v5 6/7] ARM: shmobile: r8a73a4: add a DT node and a clock alias for the DMAC
On Fri, Aug 02, 2013 at 04:50:41PM +0200, Guennadi Liakhovetski wrote:
> Add a DT node for the only system DMAC instance on r8a73a4. The RT DMAC
> can be added later under the same multiplexer, because they can serve the
> same slaves and use the same MID-RID values. Configuration data is
> supplied to the driver, using a compatibility match string.
>
> Signed-off-by: Guennadi Liakhovetski
> ---
> arch/arm/boot/dts/r8a73a4.dtsi | 43
>
> arch/arm/mach-shmobile/clock-r8a73a4.c |1 +
> 2 files changed, 44 insertions(+), 0 deletions(-)
Other than patch 5 of this series, which adds the relevant clock,
does this patch depend on any other patches in this series?
>
> diff --git a/arch/arm/boot/dts/r8a73a4.dtsi b/arch/arm/boot/dts/r8a73a4.dtsi
> index e344b10..3c9c7f2 100644
> --- a/arch/arm/boot/dts/r8a73a4.dtsi
> +++ b/arch/arm/boot/dts/r8a73a4.dtsi
> @@ -78,6 +78,49 @@
> <0 56 4>, <0 57 4>;
> };
>
> + dmac: dma-multiplexer@0 {
> + compatible = "renesas,shdma-mux";
> + #dma-cells = <1>;
> + dma-channels = <20>;
> + dma-requests = <256>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + dma0: dma-controller@e6700020 {
> + compatible = "renesas,shdma-r8a73a4";
> + reg = <0 0xe6700020 0 0x89e0>;
> + interrupt-parent = <>;
> + interrupts = <0 220 4
> + 0 200 4
> + 0 201 4
> + 0 202 4
> + 0 203 4
> + 0 204 4
> + 0 205 4
> + 0 206 4
> + 0 207 4
> + 0 208 4
> + 0 209 4
> + 0 210 4
> + 0 211 4
> + 0 212 4
> + 0 213 4
> + 0 214 4
> + 0 215 4
> + 0 216 4
> + 0 217 4
> + 0 218 4
> + 0 219 4>;
> + interrupt-names = "error",
> + "ch0", "ch1", "ch2", "ch3",
> + "ch4", "ch5", "ch6", "ch7",
> + "ch8", "ch9", "ch10", "ch11",
> + "ch12", "ch13", "ch14", "ch15",
> + "ch16", "ch17", "ch18", "ch19";
> + };
> + };
> +
> thermal@e61f {
> compatible = "renesas,rcar-thermal";
> reg = <0 0xe61f 0 0x14>, <0 0xe61f0100 0 0x38>,
> diff --git a/arch/arm/mach-shmobile/clock-r8a73a4.c
> b/arch/arm/mach-shmobile/clock-r8a73a4.c
> index 357b9bc..74841ed 100644
> --- a/arch/arm/mach-shmobile/clock-r8a73a4.c
> +++ b/arch/arm/mach-shmobile/clock-r8a73a4.c
> @@ -580,6 +580,7 @@ static struct clk_lookup lookups[] = {
> CLKDEV_DEV_ID("sh-sci.4", _clks[MSTP216]),
> CLKDEV_DEV_ID("sh-sci.5", _clks[MSTP217]),
> CLKDEV_DEV_ID("sh-dma-engine.0", _clks[MSTP218]),
> + CLKDEV_DEV_ID("e6700020.dma-controller", _clks[MSTP218]),
> CLKDEV_DEV_ID("rcar_thermal", _clks[MSTP522]),
> CLKDEV_DEV_ID("e652.i2c", _clks[MSTP300]),
> CLKDEV_DEV_ID("sh_mmcif.1", _clks[MSTP305]),
> --
> 1.7.2.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 v5 5/7] ARM: shmobile: r8a73a4: add a DMAC platform device and clock for it
On Fri, Aug 02, 2013 at 04:50:40PM +0200, Guennadi Liakhovetski wrote:
> Add a DMAC platform device and clock definitions for it on r8a73a4.
>
> Signed-off-by: Guennadi Liakhovetski
> ---
>
> Depends on "DMA: shdma: support the new CHCLR register layout"
> https://lkml.org/lkml/2013/7/10/146
That change seems to be present upstream.
Does this patch depend on any of the other patches
in this series?
>
> arch/arm/mach-shmobile/clock-r8a73a4.c|4 +-
> arch/arm/mach-shmobile/include/mach/r8a73a4.h |9 +++
> arch/arm/mach-shmobile/setup-r8a73a4.c| 91
> +
> 3 files changed, 103 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-shmobile/clock-r8a73a4.c
> b/arch/arm/mach-shmobile/clock-r8a73a4.c
> index 8ea5ef6..357b9bc 100644
> --- a/arch/arm/mach-shmobile/clock-r8a73a4.c
> +++ b/arch/arm/mach-shmobile/clock-r8a73a4.c
> @@ -504,7 +504,7 @@ static struct clk div6_clks[DIV6_NR] = {
>
> /* MSTP */
> enum {
> - MSTP217, MSTP216, MSTP207, MSTP206, MSTP204, MSTP203,
> + MSTP218, MSTP217, MSTP216, MSTP207, MSTP206, MSTP204, MSTP203,
> MSTP329, MSTP323, MSTP318, MSTP317, MSTP316,
> MSTP315, MSTP314, MSTP313, MSTP312, MSTP305, MSTP300,
> MSTP411, MSTP410, MSTP409,
> @@ -519,6 +519,7 @@ static struct clk mstp_clks[MSTP_NR] = {
> [MSTP207] = SH_CLK_MSTP32(_clks[DIV6_MP], SMSTPCR2, 7, 0), /*
> SCIFB1 */
> [MSTP216] = SH_CLK_MSTP32(_clks[DIV6_MP], SMSTPCR2, 16, 0), /*
> SCIFB2 */
> [MSTP217] = SH_CLK_MSTP32(_clks[DIV6_MP], SMSTPCR2, 17, 0), /*
> SCIFB3 */
> + [MSTP218] = SH_CLK_MSTP32(_clks[DIV4_HP], SMSTPCR2, 18, 0), /*
> DMAC */
> [MSTP300] = SH_CLK_MSTP32(_clks[DIV4_HP], SMSTPCR3, 0, 0), /*
> IIC2 */
> [MSTP305] = SH_CLK_MSTP32(_clks[DIV6_MMC1],SMSTPCR3, 5, 0), /*
> MMCIF1 */
> [MSTP312] = SH_CLK_MSTP32(_clks[DIV6_SDHI2],SMSTPCR3, 12, 0), /*
> SDHI2 */
> @@ -578,6 +579,7 @@ static struct clk_lookup lookups[] = {
> CLKDEV_DEV_ID("sh-sci.3", _clks[MSTP207]),
> CLKDEV_DEV_ID("sh-sci.4", _clks[MSTP216]),
> CLKDEV_DEV_ID("sh-sci.5", _clks[MSTP217]),
> + CLKDEV_DEV_ID("sh-dma-engine.0", _clks[MSTP218]),
> CLKDEV_DEV_ID("rcar_thermal", _clks[MSTP522]),
> CLKDEV_DEV_ID("e652.i2c", _clks[MSTP300]),
> CLKDEV_DEV_ID("sh_mmcif.1", _clks[MSTP305]),
> diff --git a/arch/arm/mach-shmobile/include/mach/r8a73a4.h
> b/arch/arm/mach-shmobile/include/mach/r8a73a4.h
> index f3a9b70..3a0ea48 100644
> --- a/arch/arm/mach-shmobile/include/mach/r8a73a4.h
> +++ b/arch/arm/mach-shmobile/include/mach/r8a73a4.h
> @@ -1,6 +1,15 @@
> #ifndef __ASM_R8A73A4_H__
> #define __ASM_R8A73A4_H__
>
> +/* DMA slave IDs */
> +enum {
> + SHDMA_SLAVE_INVALID,
> + SHDMA_SLAVE_MMCIF0_TX,
> + SHDMA_SLAVE_MMCIF0_RX,
> + SHDMA_SLAVE_MMCIF1_TX,
> + SHDMA_SLAVE_MMCIF1_RX,
> +};
> +
> void r8a73a4_add_standard_devices(void);
> void r8a73a4_add_dt_devices(void);
> void r8a73a4_clock_init(void);
> diff --git a/arch/arm/mach-shmobile/setup-r8a73a4.c
> b/arch/arm/mach-shmobile/setup-r8a73a4.c
> index 2ee45d5..ec77059 100644
> --- a/arch/arm/mach-shmobile/setup-r8a73a4.c
> +++ b/arch/arm/mach-shmobile/setup-r8a73a4.c
> @@ -22,8 +22,10 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -199,12 +201,101 @@ void __init r8a73a4_add_dt_devices(void)
> r8a7790_register_cmt(10);
> }
>
> +/* DMA */
> +static const struct sh_dmae_slave_config dma_slaves[] = {
> + {
> + .slave_id = SHDMA_SLAVE_MMCIF0_TX,
> + .addr = 0xee200034,
> + .chcr = CHCR_TX(XMIT_SZ_32BIT),
> + .mid_rid= 0xd1,
> + }, {
> + .slave_id = SHDMA_SLAVE_MMCIF0_RX,
> + .addr = 0xee200034,
> + .chcr = CHCR_RX(XMIT_SZ_32BIT),
> + .mid_rid= 0xd2,
> + }, {
> + .slave_id = SHDMA_SLAVE_MMCIF1_TX,
> + .addr = 0xee220034,
> + .chcr = CHCR_TX(XMIT_SZ_32BIT),
> + .mid_rid= 0xe1,
> + }, {
> + .slave_id = SHDMA_SLAVE_MMCIF1_RX,
> + .addr = 0xee220034,
> + .chcr = CHCR_RX(XMIT_SZ_32BIT),
> + .mid_rid= 0xe2,
> + },
> +};
> +
> +#define DMAE_CHANNEL(a, b) \
> + { \
> + .offset = (a) - 0x20, \
> + .dmars = (a) - 0x20 + 0x40,\
> + .chclr_bit = (b), \
> + .chclr_offset = 0x80 - 0x20, \
> + }
> +
> +static const struct sh_dmae_channel dma_channels[] = {
> + DMAE_CHANNEL(0x8000, 0),
> + DMAE_CHANNEL(0x8080, 1),
> + DMAE_CHANNEL(0x8100, 2),
> + DMAE_CHANNEL(0x8180, 3),
> +
Re: [PATCH] oom: avoid killing init if it assume the oom killed thread's mm
On 09/25/2013 10:34 AM, David Rientjes wrote: On Mon, 23 Sep 2013, Ming Liu wrote: After selecting a task to kill, the oom killer iterates all processes and kills all other user threads that share the same mm_struct in different thread groups. But in some extreme cases, the selected task happens to be a vfork child of init process sharing the same mm_struct with it, which causes kernel panic on init getting killed. This panic is observed in a busybox shell that busybox itself is init, with a kthread keeps consuming memories. We shouldn't be selecting a process where mm == init_mm in the first place, so this wouldn't fix the issue entirely. But if we add a control point for "mm == init_mm" in the first place(ie. in oom_unkillable_task), that would forbid the processes sharing mm with init to be selected, is that reasonable? Actually my fix is just to protect init process to be killed for its vfork child being selected and I think it's the only place where there is the risk. If my understanding is wrong, pls correct me. Thanks, Ming Liu -- 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] EFI: Runtime services virtual mapping
On Tue, Sep 24, 2013 at 05:12:26PM -0700, H. Peter Anvin wrote:
> I am starting to think that we really should explicitly pass along the
> EFI mappings to the secondary kernel. This will also help if we have to
> change the algorithm in a future kernel.
That would be the most flexible solution, sure.
> The most logical way to do this is to define a new setup_data type and
> pass the entire set of physical-to-virtual mappings that way.
>
> For example:
>
> struct efi_mapping {
> u64 va; /* Virtual start address */
> u64 pa; /* Physical start address */
> u64 len;/* Length in bytes */
> u64 type; /* Mapping type */
> u64 reserved[3];/* Reserved, must be zero */
> };
>
> Adding some reserved fields seems like a prudent precaution;
... and making checking they're zeroed out initially so that I can use
them in the future, if needed :)
> the map shouldn't be all that large anyway.
Yeah, let me look at it in more detail when I get back - it shouldn't be
that hard to do.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/10] ARM: shmobile: Initialize PWM backlight enable_gpio field
On Mon, Sep 23, 2013 at 11:41:03PM +0200, Thierry Reding wrote:
> The GPIO API defines 0 as being a valid GPIO number, so this field needs
> to be initialized explicitly.
>
> Signed-off-by: Thierry Reding
> ---
> arch/arm/mach-shmobile/board-armadillo800eva.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c
> b/arch/arm/mach-shmobile/board-armadillo800eva.c
> index 7f8f607..6ccb854 100644
> --- a/arch/arm/mach-shmobile/board-armadillo800eva.c
> +++ b/arch/arm/mach-shmobile/board-armadillo800eva.c
> @@ -423,6 +423,7 @@ static struct platform_pwm_backlight_data
> pwm_backlight_data = {
> .max_brightness = 255,
> .dft_brightness = 255,
> .pwm_period_ns = 3, /* 30kHz */
> + .enable_gpio = -1,
> };
>
> static struct platform_device pwm_backlight_device = {
Acked-by: Simon Horman
--
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: [PATCHv6 02/16] drivers: thermal: introduce device tree parser
On 09/24/2013 11:50 PM, Eduardo Valentin wrote: Zhang, I appreciate your interest. I am replying a couple of your comments. Please also check my answers to Mark's queries on other email thread. When I replied to Mark yesterday, I missed your mail replying him already. I should check that mail and reply it for further concerns. On 24-09-2013 04:11, Hongbo Zhang wrote: On 09/23/2013 06:40 PM, Mark Rutland wrote: Hi Eduardo, Apologies for having taken so long to get back you on this. I have several comments on the binding and the way it's parsed. On Wed, Sep 18, 2013 at 10:35:36PM +0100, Eduardo Valentin wrote: This patch introduces a device tree bindings for describing the hardware thermal behavior and limits. Also a parser to read and interpret the data and feed it in the thermal framework is presented. This patch introduces a thermal data parser for device tree. The parsed data is used to build thermal zones and thermal binding parameters. The output data can then be used to deploy thermal policies. This patch adds also documentation regarding this API and how to define tree nodes to use this infrastructure. Note that, in order to be able to have control on the sensor registration on the DT thermal zone, it was required to allow changing the thermal zone .get_temp callback. For this reason, this patch also removes the 'const' modifier from the .ops field of thermal zone devices. Cc: Zhang Rui Cc: linux...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin --- .../devicetree/bindings/thermal/thermal.txt| 498 + drivers/thermal/Kconfig| 13 + drivers/thermal/Makefile | 1 + drivers/thermal/of-thermal.c | 775 + drivers/thermal/thermal_core.c | 9 +- drivers/thermal/thermal_core.h | 9 + include/dt-bindings/thermal/thermal.h | 27 + include/linux/thermal.h| 28 +- 8 files changed, 1357 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt create mode 100644 drivers/thermal/of-thermal.c create mode 100644 include/dt-bindings/thermal/thermal.h --- Hello all, Thanks Joe Perches for the effort of reviewing this code, I really appreciate it. Here is a version with a refactored init function without leaks in the failure patch. I also added a couple of comments to better understand the intention of that function. Besides, when there are no memory available, the function rolls back what ever thermal zones have been added. Thanks, Eduardo diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt new file mode 100644 index 000..6664533 --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/thermal.txt @@ -0,0 +1,498 @@ +* Thermal Framework Device Tree descriptor + +Generic binding to provide a way of defining hardware thermal +structure using device tree. A thermal structure includes thermal +zones and their components, such as trip points, polling intervals, +sensors and cooling devices binding descriptors. + +The target of device tree thermal descriptors is to describe only +the hardware thermal aspects, not how the system must control or which +algorithm or policy must be taken in place. + +There are five types of nodes involved to describe thermal bindings: +- sensors: used to describe the device source of temperature sensing; +- cooling devices: used to describe devices source of power dissipation control; +- trip points: used to describe points in temperature domain defined to +make the system aware of hardware limits; +- cooling attachments: used to describe links between trip points and +cooling devices; I think "attachments" sounds a bit odd, though I don't have a better naming suggestion. "map" or "mapping" is better? Well, yeah, that could work. :) +- thermal zones: used to describe thermal data within the hardware; + +It follows a description of each type of these device tree nodes. + +* Sensor devices + +Sensor devices are nodes providing temperature sensing capabilities on thermal +zones. Typical devices are I2C ADC converters and bandgaps. Theses are nodes +providing temperature data to thermal zones. Temperature sensor devices may +control one or more internal sensors. + +Required property: +- #sensor-cells: Used to provide sensor device specific information + while referring to it. Must be at least 1, in order + to identify uniquely the sensor instances within + the IC. See thermal zone binding for more details + on how consumers refer to sensor devices. I don't see why this needs to be at least one cell -- if an IC only has one temperature sensor it should be fine for this to be zero and have no
Re: [PATCH 00/10] pwm-backlight: Add GPIO and power supply support
On Tue, Sep 24, 2013 at 11:00:24AM +0200, Thierry Reding wrote: > On Tue, Sep 24, 2013 at 05:14:46PM +0900, Simon Horman wrote: > > [ Cc: Olof Johansson, Kevin Hilman and Arnd Bergman: arm-soc maintainers ] > > > > On Mon, Sep 23, 2013 at 11:40:57PM +0200, Thierry Reding wrote: > > > This series adds the ability to specify a GPIO and a power supply to > > > enable a backlight. > > > > > > Patch 1 refactors the power on and power off sequences into separate > > > functions in preparation for subsequent patches. > > > > > > Patch 2 adds an optional GPIO to enable a backlight. This patch only > > > includes the field within the platform data so that it can be properly > > > setup before actually being put to use. > > > > > > Patches 3 to 7 convert all users of the pwm-backlight driver to use the > > > new field. For most of them, this just initializes the field to -1, > > > marking the field as unused. > > > > > > Patch 8 uses the new field within the pwm-backlight driver and at the > > > same time allows it to be parsed from device tree. > > > > > > Patch 9 implements support for an optional power supply. This relies on > > > the regulator core to return a dummy regulator when no supply has been > > > otherwise setup so the driver doesn't have to handle that specially nor > > > require all users to be updated. > > > > > > Patch 10 adds a way to keep a backlight turned off at boot. This is > > > useful when hooking up a backlight with a subsystem such as DRM which > > > has more explicit semantics as to when a backlight should be turned on. > > > > > > Due to the dependencies within the series, I propose to take all these > > > patches through the PWM tree, so I'll need acks from OMAP, PXA, Samsung, > > > shmobile and Unicore32 maintainers. > > > > I received some feedback regarding shmobile conflicts when > > arm-soc was merged between v3.11 and v3.12-rc1. With this > > in mind I now have a strong preference for changes inside > > arch/arm/mach-shmobile/ to be taken through my renesas > > tree and thus more importantly through arm-soc if possible. > > I understand. Unfortunately the nature of patche series such as this is > that they require the whole series to be applied atomically (or at least > in a very specific order). So the patch that uses the new enable_gpio > field can only be applied after all previous patches. The only > reasonable way to ensure that is to take all of the patches through one > tree. Furthermore this patch is tiny (it adds a single line) and touches > code that's unlikely to be modified by anyone else. > > But if it makes you more comfortable, I could provide a stable branch > that contains this series for you to merge into the shmobile tree. That > should enable you to handle all conflict resolution prior to submitting > to arm-soc. After some further thought I have reasoned that: 1. It is only a one line change on the shmobile side 2. It is to a file that is not seeing much chainge and in a block of code that is seeing even less change. And thus the chance of a conflict is small. With this in mind I will ack the shmobile patch. -- 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: manual merge of the ipsec-next tree with the net-next tree
On Wed, Sep 25, 2013 at 09:59:19AM +1000, Stephen Rothwell wrote:
> Hi Steffen,
>
> On Tue, 24 Sep 2013 12:25:05 +0200 Steffen Klassert
> wrote:
> >
> > On Tue, Sep 24, 2013 at 12:16:29PM +1000, Stephen Rothwell wrote:
> > >
> > > Today's linux-next merge of the ipsec-next tree got a conflict in
> > > include/net/xfrm.h between commit d511337a1eda ("xfrm.h: Remove extern
> > > from function prototypes") from the net-next tree and commit aba826958830
> > > ("{ipv4,xfrm}: Introduce xfrm_tunnel_notifier for xfrm tunnel mode
> > > callback") from the ipsec-next tree.
> >
> > Thanks for the information, I'll do a rebase of the ipsec-next
> > tree tomorrow.
>
> Did you miss the end of the next paragraph: "no action is required"?
> Dave can fix this up (like I did) when he merges your tree into his.
>
I applied this patch shortly before the merge window opened, it is a left
over from the last develpoment cycle. I already rebased my tree onto
net-next in the past if that happened, even if there were no merge
conflicts. I did that just to see if everything still works. But I
could also do a test merge to see if everything still works and ask
to pull without a rebase then if this is the prefered way. Would make
my life easier :)
--
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/
Regression caused by commit 4bdc33ed ("NFSDv4.2: Add NFS v4.2 support to the NFS server")
Hi all,
My embedded development box fails to NFS-boot with NFS server which uses recent
kernel.
Using git bisect, I found it is caused by commit 4bdc33ed ("NFSDv4.2: Add NFS
v4.2 support to the NFS server").
1. dmesg (NFS boot failure case)
...
[2.040893] ADDRCONF(NETDEV_UP): eth0: link is not ready
[2.046207] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control:
RX
[2.053570] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[3.055023] IP-Config: Guessing netmask 255.255.0.0
[3.059979] IP-Config: Gateway not on directly connected network.
[3.066330] Looking up port of RPC 13/2 on 165.213.88.249
[3.074001] Looking up port of RPC 15/1 on 165.213.88.249
[3.122878] VFS: Unable to mount root fs via NFS, trying floppy.
[3.129134] VFS: Cannot open root device "nfs" or unknown-block(2,0)
[3.135478] Please append a correct "root=" boot option; here are the
available partitions:
[3.143831] 1f003072 mtdblock0 (driver?)
[3.148798] 1f01 64 mtdblock1 (driver?)
[3.153758] 1f02 64 mtdblock2 (driver?)
[3.158719] 1f03 64 mtdblock3 (driver?)
[3.163682] 1f04 64 mtdblock4 (driver?)
[3.168644] 1f05 64 mtdblock5 (driver?)
[3.173607] 1f06 64 mtdblock6 (driver?)
[3.178568] 0800 488386584 sda driver: sd
[3.183099] 0801 506016 sda1
[3.186927] 0802 4008217 sda2
[3.190755] 0803 483869767 sda3
[3.194584] b300 1880064 mmcblk0 driver: mmcblk
[3.199802] b3014096 mmcblk0p1
[3.204063] b302 102400 mmcblk0p2
[3.208330] b3034096 mmcblk0p3
[3.212594] b304 1 mmcblk0p4
[3.216855] b3052048 mmcblk0p5
[3.221116] b3062048 mmcblk0p6
[3.225382] b3072048 mmcblk0p7
[3.229644] b3084096 mmcblk0p8
[3.233906] b309 12288 mmcblk0p9
[3.238176] b30a 16384 mmcblk0p10
[3.242524] b30b 142336 mmcblk0p11
[3.246869] b30c 1572864 mmcblk0p12
[3.251219] b320 12288 mmcblk0gp1 (driver?)
[3.256272] b310 12288 mmcblk0gp0 (driver?)
[3.261320] Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(2,0)
[3.269566] Pid: 1, comm: swapper Not tainted 2.6.35 #1
[3.274776] Call Trace:
[3.277232] [<80d0db5b>] ? printk+0x1e/0x20
[3.281492] [<80d0dad1>] panic+0x65/0xd1
[3.285495] [<80eb9ce3>] mount_block_root+0x125/0x1be
[3.290631] [<809d1f6d>] ? sys_mknod+0x2d/0x30
[3.295156] [<80eb9f6d>] mount_root+0xd0/0xf2
[3.299591] [<80eba0d9>] prepare_namespace+0x14a/0x184
[3.304803] [<809c44f6>] ? sys_access+0x26/0x30
[3.309411] [<80eb9a4e>] kernel_init+0x25e/0x26e
[3.314105] [<80eb97f0>] ? kernel_init+0x0/0x26e
[3.318800] [<80903242>] kernel_thread_helper+0x6/0x10
2. Client (my embedded box) configuration
It's kernel 2.6.35 based, and has following NFS kernel configs.
# grep NFS .config
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
# CONFIG_NFS_V4_1 is not set
CONFIG_ROOT_NFS=y
# CONFIG_NFSD is not set
CONFIG_NFS_ACL_SUPPORT=y
CONFIG_NFS_COMMON=y
3. Server (NFSD) configuration
Fedora 19 + latest linus git kernel 3.12.0-rc2+ (commit 22356f44, mm: Place
preemption point in do_mlockall() loop)
4. workaround
Reverting the commit 4bdc33ed resolves my issue, NFS boot is working then.
I've done git bisect, but lost the resulting bisect log due to sudden power
loss :(.
Best regards,
Jongman Heo
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH 3/4] ARM: shmobile: r8a7790: add CPUFreq clock support
On Mon, Sep 09, 2013 at 06:03:55PM +0200, Guennadi Liakhovetski wrote:
> Add support for the Z clock on r8a7790, driving the four SoC's CA15 cores,
> and its parent - PLL0. This is required for CPUFreq support on this SoC.
>
> Signed-off-by: Guennadi Liakhovetski
Magnus, I think this needs a review from you.
> ---
> arch/arm/mach-shmobile/Kconfig |2 +
> arch/arm/mach-shmobile/clock-r8a7790.c | 150
>
> 2 files changed, 152 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
> index 1f94c31..b9422f2 100644
> --- a/arch/arm/mach-shmobile/Kconfig
> +++ b/arch/arm/mach-shmobile/Kconfig
> @@ -100,6 +100,8 @@ config ARCH_R8A7790
> select CPU_V7
> select SH_CLK_CPG
> select RENESAS_IRQC
> + select ARCH_HAS_CPUFREQ
> + select ARCH_HAS_OPP
>
> config ARCH_EMEV2
> bool "Emma Mobile EV2"
> diff --git a/arch/arm/mach-shmobile/clock-r8a7790.c
> b/arch/arm/mach-shmobile/clock-r8a7790.c
> index 8e5e90b..3ef043e 100644
> --- a/arch/arm/mach-shmobile/clock-r8a7790.c
> +++ b/arch/arm/mach-shmobile/clock-r8a7790.c
> @@ -54,9 +54,12 @@
> #define SMSTPCR8 0xe6150990
> #define SMSTPCR9 0xe6150994
>
> +#define FRQCRB 0xE6150004
> #define SDCKCR 0xE6150074
> #define SD2CKCR 0xE6150078
> #define SD3CKCR 0xE615007C
> +#define FRQCRC 0xE61500E0
> +#define PLLECR 0xE61500D0
> #define MMC0CKCR 0xE6150240
> #define MMC1CKCR 0xE6150244
> #define SSPCKCR 0xE6150248
> @@ -85,6 +88,7 @@ static struct clk main_clk = {
> * clock ratio of these clock will be updated
> * on r8a7790_clock_init()
> */
> +SH_FIXED_RATIO_CLK_SET(pll0_clk, main_clk, 1, 1);
> SH_FIXED_RATIO_CLK_SET(pll1_clk, main_clk, 1, 1);
> SH_FIXED_RATIO_CLK_SET(pll3_clk, main_clk, 1, 1);
> SH_FIXED_RATIO_CLK_SET(lb_clk, pll1_clk, 1, 1);
> @@ -113,15 +117,155 @@ SH_FIXED_RATIO_CLK_SET(zb3d2_clk,
> pll3_clk, 1, 8);
> SH_FIXED_RATIO_CLK_SET(ddr_clk, pll3_clk, 1, 8);
> SH_FIXED_RATIO_CLK_SET(mp_clk, pll1_div2_clk, 1, 15);
>
> +/* Locking not needed yet, only one clock is using FRQCR[BC] divisors so far
> */
> +static atomic_t frqcr_lock;
> +#define CPG_MAP(o) ((o) - CPG_BASE + cpg_mapping.base)
> +
> +/* Several clocks need to access FRQCRB, have to lock */
> +static bool frqcr_kick_check(struct clk *clk)
> +{
> + return !(ioread32(CPG_MAP(FRQCRB)) & BIT(31));
> +}
> +
> +static int frqcr_kick_do(struct clk *clk)
> +{
> + int i;
> +
> + /* set KICK bit in FRQCRB to update hardware setting, check success */
> + iowrite32(ioread32(CPG_MAP(FRQCRB)) | BIT(31), CPG_MAP(FRQCRB));
> + for (i = 1000; i; i--)
> + if (ioread32(CPG_MAP(FRQCRB)) & BIT(31))
> + cpu_relax();
> + else
> + return 0;
> +
> + return -ETIMEDOUT;
> +}
> +
> +static int zclk_set_rate(struct clk *clk, unsigned long rate)
> +{
> + void __iomem *frqcrc;
> + int ret;
> + unsigned long step, p_rate;
> + u32 val;
> +
> + if (!clk->parent || !__clk_get(clk->parent))
> + return -ENODEV;
> +
> + if (!atomic_inc_and_test(_lock) || !frqcr_kick_check(clk)) {
> + ret = -EBUSY;
> + goto done;
> + }
> +
> + /*
> + * Users are supposed to first call clk_set_rate() only with
> + * clk_round_rate() results. So, we don't fix wrong rates here, but
> + * guard against them anyway
> + */
> +
> + p_rate = clk_get_rate(clk->parent);
> + if (rate == p_rate) {
> + val = 0;
> + } else {
> + step = DIV_ROUND_CLOSEST(p_rate, 32);
> +
> + if (rate > p_rate || rate < step) {
> + ret = -EINVAL;
> + goto done;
> + }
> +
> + val = 32 - rate / step;
> + }
> +
> + frqcrc = clk->mapped_reg + (FRQCRC - (u32)clk->enable_reg);
> +
> + iowrite32((ioread32(frqcrc) & ~(clk->div_mask << clk->enable_bit)) |
> + (val << clk->enable_bit), frqcrc);
> +
> + ret = frqcr_kick_do(clk);
> +
> +done:
> + atomic_dec(_lock);
> + __clk_put(clk->parent);
> + return ret;
> +}
> +
> +static long zclk_round_rate(struct clk *clk, unsigned long rate)
> +{
> + /*
> + * theoretical rate = parent rate * multiplier / 32,
> + * where 1 <= multiplier <= 32. Therefore we should do
> + * multiplier = rate * 32 / parent rate
> + * rounded rate = parent rate * multiplier / 32.
> + * However, multiplication before division won't fit in 32 bits, so
> + * we sacrifice some precision by first dividing and then multiplying.
> + * To find the nearest divisor we calculate both and pick up the best
> + * one.
Re: [PATCH 1/4] pinctrl: sh-pfc: r8a7790: add pin definitions for the I2C3 interface
On Mon, Sep 23, 2013 at 10:50:07AM +0200, Linus Walleij wrote:
> On Tue, Sep 17, 2013 at 7:10 PM, Guennadi Liakhovetski
> wrote:
> > On Tue, 17 Sep 2013, Linus Walleij wrote:
>
> >> > +/* R8A7790 has 6 banks with 32 GPIOs in each = 192 GPIOs */
> >> > +#define ROW_GROUP_A(r) ('Z' - 'A' + 1 + (r))
> >> > +#define PIN_NUMBER(r, c) (((r) - 'A') * 16 + (c) + 200)
> >> > +#define PIN_A_NUMBER(r, c) PIN_NUMBER(ROW_GROUP_A(r), c)
> >>
> >> You add these #defines but do not use them.
> >
> > ehm, actually I do:
>
> Argh I was just wrong, forget about this.
>
> Woudl really like Laurent's ACK on this before I apply it though.
Laurent, ping.
--
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 Sep 25
Hi all, Heads up: I will be having a 3 week break leading up to the kernel summit. This means that next-20130927 (next Friday) will be the last linux-next release until next-20131028 (or maybe 29). I presume that Linus will be up to v3.12-rc7 by then and -rc7 is often the last before a release ... Please plan accordingly. Changes since 20130924: The drm-intel tree gained a conflict against the drm-intel-fixes tree. The block tree gained a conflict against Linus' tree. The akpm-current tree gained a conflict against the cgroup tree. 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" as mentioned in the FAQ on the wiki (see below). 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. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 214 trees (counting Linus' and 30 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. 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. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (e288e93 Merge branch 'bcache' (bcache fixes from Kent Overstreet)) Merging fixes/master (fa8218d Merge tag 'regmap-v3.11-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap) Merging kbuild-current/rc-fixes (ad81f05 Linux 3.11-rc1) Merging arc-current/for-curr (272b98c Linux 3.12-rc1) Merging arm-current/fixes (40190c8 ARM: 7837/3: fix Thumb-2 bug in AES assembler code) Merging m68k-current/for-linus (21e884b m68k/m68knommu: Implement __get_user_unaligned/__put_user_unaligned()) Merging metag-fixes/fixes (3b2f64d Linux 3.11-rc2) Merging powerpc-merge/merge (363edbe powerpc: Default arch idle could cede processor on pseries) Merging sparc/master (4de9ad9 Merge git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile) Merging net/master (2811eba ipv6: udp packets following an UFO enqueued packet need also be handled by UFO) Merging ipsec/master (33fce60 xfrm: Guard IPsec anti replay window against replay bitmap) Merging sound-current/for-linus (4028b6c ALSA: compress: Fix compress device unregister.) Merging pci-current/for-linus (4a10c2a Linux 3.12-rc2) Merging wireless/master (b75ff5e Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging driver-core.current/driver-core-linus (272b98c Linux 3.12-rc1) Merging tty.current/tty-linus (93a8d41 n_tty: Fix EOF push index when termios changes) Merging usb.current/usb-linus (4a10c2a Linux 3.12-rc2) Merging staging.current/staging-linus (6174081 Merge tag 'iio-fixes-for-3.12a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus) Merging char-misc.current/char-misc-linus (272b98c Linux 3.12-rc1) Merging input-current/for-linus (2f0d260 Input: i8042 - i8042_flush fix for a full 8042 buffer) Merging md-current/for-linus (f94c0b6 md/raid5: fix interaction of 'replace' and 'recovery'.) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (26052f9 crypto: crct10dif - Add fallback for broken initrds) Merging ide/master (64110c1 ide: sgiioc4: Staticize ioc4_ide_attach_one()) Merging dwmw2/master (5950f08 pcmcia: remove RPX board stuff) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging devicetree-current/devicetree/merge (cf9e236 of/irq: init struct resource to 0 in of_irq_to_resource()) Merging rr-fixes/fixes (6c2580c Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kern
[git pull] Please pull powerpc.git merge branch
Hi Linus ! Here are a few things for -rc2, this time it's all written by me so it can only be perfect right ? :) So we have the fix to call irq_enter/exit on the irq stack we've been discussing, plus a cleanup on top to remove an unused (and broken) stack limit tracking feature (well, make it 32-bit only in fact where it is used and works properly). Then we have two things that I wrote over the last couple of days and made the executive decision to include just because I can (and I'm sure you won't object right ?). They fix a couple of annoying and long standing "issues": - We had separate zImages for when booting via Open Firmware vs. booting via a flat device-tree, while it's trivial to make one that deals with both - We wasted a ton of cycles spinning secondary CPUs uselessly at boot instead of starting them when needed on pseries, thus contributing significantly to global warming. Cheers, Ben. The following changes since commit 4a10c2ac2f368583138b774ca41fac4207911983: Linux 3.12-rc2 (2013-09-23 15:41:09 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge for you to fetch changes up to dbe78b40118636f2d5d276144239dd4bfd5f04f9: powerpc/pseries: Do not start secondaries in Open Firmware (2013-09-25 14:19:00 +1000) Benjamin Herrenschmidt (4): powerpc/irq: Run softirqs off the top of the irq stack powerpc: Remove ksp_limit on ppc64 powerpc/zImage: make the "OF" wrapper support ePAPR boot powerpc/pseries: Do not start secondaries in Open Firmware arch/powerpc/boot/Makefile | 4 +- arch/powerpc/boot/epapr-wrapper.c| 9 arch/powerpc/boot/epapr.c| 4 +- arch/powerpc/boot/of.c | 16 +- arch/powerpc/boot/wrapper| 9 ++-- arch/powerpc/include/asm/irq.h | 4 +- arch/powerpc/include/asm/processor.h | 4 +- arch/powerpc/kernel/asm-offsets.c| 3 +- arch/powerpc/kernel/irq.c| 100 +++ arch/powerpc/kernel/misc_32.S| 25 +++-- arch/powerpc/kernel/misc_64.S| 10 ++-- arch/powerpc/kernel/process.c| 3 +- arch/powerpc/kernel/prom_init.c | 21 arch/powerpc/lib/sstep.c | 3 +- arch/powerpc/platforms/pseries/smp.c | 26 + 15 files changed, 147 insertions(+), 94 deletions(-) create mode 100644 arch/powerpc/boot/epapr-wrapper.c -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: General placement of platform drivers and header files
Hi, On Tue, Sep 24, 2013 at 8:33 PM, Feng Kan wrote: > Hi all: > > I have some drivers like Queue Manager and co-processor driver that > are used by other > drivers like Ethernet. Would it be appropriate to locate these drivers > under one folder under > drivers/misc/arch_name/xxx. drivers/misc is almost always the wrong answer to where to add a driver. It would help to also know how the devices interact to answer the question of best location. Are the drivers for the coprocessor and for the queue manager mostly a pass-through for some operations (and some shared allocation of resources), i.e. more of a library, or is it a full-fledged driver that will service interrupts, etc? > My other question is on common header files (belonging to Queue > Manager) but is sourced > by Ethernet, where should those reside. Should they go under > linux/include/misc/arch_name > or directly sourced using the ../../../misc/arch_name/headerfile method. This depends somewhat on where the driver ends up, but somewhere under include/linux is likely the right place for the in-kernel interface header files. -Olof -- 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] SDT markers listing by perf
(2013/09/15 20:28), Hemant wrote:
> Hi Masami,
Hi, and sorry for replying so late. I missed this in my mailbox.
> On 09/04/2013 01:31 PM, Masami Hiramatsu wrote:
>> (2013/09/04 15:42), Namhyung Kim wrote:
>>> On Tue, 03 Sep 2013 13:06:55 +0530, Hemant Kumar wrote:
>>>
>>> [SNIP]
>>>
diff --git a/tools/perf/builtin-probe.c b/tools/perf/builtin-probe.c
index e8a66f9..3d8dcdf 100644
--- a/tools/perf/builtin-probe.c
+++ b/tools/perf/builtin-probe.c
@@ -55,6 +55,7 @@ static struct {
bool show_funcs;
bool mod_events;
bool uprobes;
+ bool sdt;
int nevents;
struct perf_probe_event events[MAX_PROBES];
struct strlist *dellist;
@@ -325,6 +326,8 @@ int cmd_probe(int argc, const char **argv, const char
*prefix __maybe_unused)
opt_set_filter),
OPT_CALLBACK('x', "exec", NULL, "executable|path",
"target executable name or path", opt_set_target),
+ OPT_BOOLEAN('S', "sdt", ,
+ "Show and probe on the SDT markers"),
>>> You need to add it to Documentation/perf-probe.txt too. In addition if
>>> the --sdt option is only able to work with libelf, it should be wrapped
>>> into the #ifdef LIBELF_SUPPORT pair.
>>>
>>> And I'm not sure that it's a good idea to have two behavior on a single
>>> option (S) - show and probe (add). Maybe it can be separated into two
>>> or the S option can be used as a flag with existing --list and --add
>>> option?
>>>
>> Good catch! :)
>> No, that is really bad idea. All probes must be added by "--add" action.
>> So we need a new probe syntax for specifying sdt marker.
>>
>> How about the below syntax?
>>
>> [EVENT=]%PROVIDER:MARKER [ARG ...]
>>
>> Of course, this will require to list up all markers with "%" prefix for
>> continuity.
>>
>> And since --list option is to list up all existing(defined) probe events,
>> I think --markers (as like as --funcs) is better for listing it up.
>>
>> Thank you!
>>
>
> I have one doubt here. Why do we need [ARG ...] in the syntax you
> specified? I believe these args are to fetched from the sdt notes'
> section of the elf of the executable/library. Or am I taking this in a
> wrong way and this suggested syntax is actually for the uprobe_events
> file in the tracing directory?
Hm, indeed. Since all the arguments of the marker is defined in sdt notes,
we actually don't need to specify each of them. However, other probe syntax
has those arguments. I'd like to keep the same syntax style in the
same command (action) for avoiding confusion.
I recommend this way; at the first step, we just find the marker address from
sdt. And next, we will make the argument available. And eventually,
it is better to introduce "$args" meta argument to fetch all the arguments
of the marker.
At this point, we can do
perf probe %foo:bar $args
to trace full information from the marker foo:bar.
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.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] kernel/groups.c: consider about NULL for 'group_info' in all related extern functions
On 09/25/2013 09:47 AM, Chen Gang wrote: > On 09/25/2013 09:14 AM, Tejun Heo wrote: >> On Wed, Sep 25, 2013 at 09:06:52AM +0800, Chen Gang wrote: >>> OK, I see, the 'root cause' is: "you are not the related maintainer >>> either", so it is really necessary for me to spend additional time >>> resource on it :-(. >> >> Yeah, at least partly. That and the fact that I'm not too willing to >> dig into the code without further evidence. It isn't anything strange >> to ask tho and I'm likely to do that even for subsystems that I know >> intimately if the subject code has been stable / stale for years and >> the analysis doesn't seem immediately convincing. And, if my >> experience is anything to go by, it's not too unlikely that you might >> hit something which doesn't agree with your current assumptions while >> trying to actually trigger the problem. >> >> Thanks. >> > Excuse me, I have to do some urgent internal things within my company, so the test and confirmation may be delayed (I will try to finish test within this month: 2013-09-30). > Excuse me, my English is not quite well, I do not quite understand what > you said (but it seems what you said is reasonable, and not need reply). > > > Thanks. > -- Chen Gang -- 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: [ 00/40] 3.4.63-stable review
On 09/24/2013 05:11 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.4.63 release. There are 40 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 Fri Sep 27 00:09:16 UTC 2013. 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.4.63-rc1.gz and the diffstat can be found below. Build test results: total: 103 pass: 89 skipped: 10 fail: 4 qemu: microblaze, mips, mips64, ppc, sh, sparc, x86, x86_64 pass. arm, sparc64 skipped Same results as with 3.4.62. --- The summary e-mail for 3.0.97 is not (or not yet) on lkml, so I'll provide the results here. Build test results: total: 98 pass: 71 skipped: 16 fail: 11 qemu: ppc, sh, sparc, x86, x86_64 passed arm, microblaze, mips, mips64, sparc64 skipped Same results as with 3.0.96. I forgot to mention that qemu:sparc and qemu:sparc64 are new tests for all versions. 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 v2 0/5] mm: migrate zbud pages
On Tue, Sep 24, 2013 at 5:20 PM, Krzysztof Kozlowski
wrote:
> Hi,
>
> On pon, 2013-09-23 at 17:07 -0500, Seth Jennings wrote:
>> On Tue, Sep 17, 2013 at 02:59:24PM +0800, Bob Liu wrote:
>> > Mel mentioned several problems about zswap/zbud in thread "[PATCH v6
>> > 0/5] zram/zsmalloc promotion".
>> >
>> > Like "it's clunky as hell and the layering between zswap and zbud is
>> > twisty" and "I think I brought up its stalling behaviour during review
>> > when it was being merged. It would have been preferable if writeback
>> > could be initiated in batches and then waited on at the very least..
>> > It's worse that it uses _swap_writepage directly instead of going
>> > through a writepage ops. It would have been better if zbud pages
>> > existed on the LRU and written back with an address space ops and
>> > properly handled asynchonous writeback."
>> >
>> > So I think it would be better if we can address those issues at first
>> > and it would be easier to address these issues before adding more new
>> > features. Welcome any ideas.
>>
>> I just had an idea this afternoon to potentially kill both these birds with
>> one
>> stone: Replace the rbtree in zswap with an address_space.
>>
>> Each swap type would have its own page_tree to organize the compressed
>> objects
>> by type and offset (radix tree is more suited for this anyway) and a_ops that
>> could be called by shrink_page_list() (writepage) or the migration code
>> (migratepage).
>>
>> Then zbud pages could be put on the normal LRU list, maybe at the beginning
>> of
>> the inactive LRU so they would live for another cycle through the list, then
>> be
>> reclaimed in the normal way with the mapping->a_ops->writepage() pointing to
>> a
>> zswap_writepage() function that would decompress the pages and call
>> __swap_writepage() on them.
>
> How exactly the address space can be used here? Do you want to point to
> zbud pages in address_space.page_tree? If yes then which index should be
> used?
>
I didn't get the point neither. I think introduce address_space is enough.
1. zbud.c:
static struct address_space_operations zbud_aops = {
.writepage= zswap_write_page,
};
struct address_space zbud_space = {
.a_ops = _aops,
};
zbud_alloc() {
zbud_page = alloc_page();
zbud_page->mapping = (struct address_space *)_space;
set_page_private(page, (unsigned long)pool);
lru_add_anon(zbud_page);
}
2. zswap.c
static int zswap_writepage(struct page *page, struct writeback_control *wbc)
{
handle = encode_handle(page_address(page), FIRST));
zswap_writeback_entry(pool, handle);
handle = encode_handle(page_address(page), LAST));
zswap_writeback_entry(pool, handle);
}
Of course it may need lots of work for core MM subsystem can maintain
zbud pages.
But in this way, we can get rid of the clunky reclaiming layer and
integrate zswap closely with core MM subsystem which knows better how
many zbud pages can be used and when should trigger the zbud pages
reclaim.
--
Regards,
--Bob
--
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 v4 4/4] Documentation: add LP3943 DT bindings and document
Bindings for LP3943 MFD, GPIO and PWM controller are added.
Cc: devicet...@vger.kernel.org
Cc: Lee Jones
Cc: Linus Walleij
Cc: Samuel Ortiz
Cc: Thierry Reding
Signed-off-by: Milo Kim
---
.../devicetree/bindings/gpio/gpio-lp3943.txt | 37 +
Documentation/devicetree/bindings/mfd/lp3943.txt | 33 +++
.../devicetree/bindings/pwm/pwm-lp3943.txt | 58
3 files changed, 128 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-lp3943.txt
create mode 100644 Documentation/devicetree/bindings/mfd/lp3943.txt
create mode 100644 Documentation/devicetree/bindings/pwm/pwm-lp3943.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-lp3943.txt
b/Documentation/devicetree/bindings/gpio/gpio-lp3943.txt
new file mode 100644
index 000..80fcb7d
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-lp3943.txt
@@ -0,0 +1,37 @@
+TI/National Semiconductor LP3943 GPIO controller
+
+Required properties:
+ - compatible: "ti,lp3943-gpio"
+ - gpio-controller: Marks the device node as a GPIO controller.
+ - #gpio-cells: Should be 2. See gpio.txt in this directory for a
+ description of the cells format.
+
+Example:
+Simple LED controls with LP3943 GPIO controller
+
+ {
+ lp3943@60 {
+ compatible = "ti,lp3943";
+ reg = <0x60>;
+
+ gpioex: gpio {
+ compatible = "ti,lp3943-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
+};
+
+leds {
+ compatible = "gpio-leds";
+ indicator1 {
+ label = "indi1";
+ gpios = < 9 GPIO_ACTIVE_LOW>;
+ };
+
+ indicator2 {
+ label = "indi2";
+ gpios = < 10 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+};
diff --git a/Documentation/devicetree/bindings/mfd/lp3943.txt
b/Documentation/devicetree/bindings/mfd/lp3943.txt
new file mode 100644
index 000..e8591d6
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/lp3943.txt
@@ -0,0 +1,33 @@
+TI/National Semiconductor LP3943 MFD driver
+
+Required properties:
+ - compatible: "ti,lp3943"
+ - reg: I2C slave address. From 0x60 to 0x67.
+
+LP3943 consists of two sub-devices, lp3943-gpio and lp3943-pwm.
+
+For the LP3943 GPIO properties please refer to:
+Documentation/devicetree/bindings/gpio/gpio-lp3943.txt
+
+For the LP3943 PWM properties please refer to:
+Documentation/devicetree/bindings/pwm/pwm-lp3943.txt
+
+Example:
+
+lp3943@60 {
+ compatible = "ti,lp3943";
+ reg = <0x60>;
+
+ gpioex: gpio {
+ compatible = "ti,lp3943-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ pwm3943: pwm {
+ compatible = "ti,lp3943-pwm";
+ #pwm-cells = <2>;
+ ti,pwm0 = <8 9 10>;
+ ti,pwm1 = <15>;
+ };
+};
diff --git a/Documentation/devicetree/bindings/pwm/pwm-lp3943.txt
b/Documentation/devicetree/bindings/pwm/pwm-lp3943.txt
new file mode 100644
index 000..7bd9d3b
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-lp3943.txt
@@ -0,0 +1,58 @@
+TI/National Semiconductor LP3943 PWM controller
+
+Required properties:
+ - compatible: "ti,lp3943-pwm"
+ - #pwm-cells: Should be 2. See pwm.txt in this directory for a
+description of the cells format.
+Note that this hardware limits the period length to the
+range 6250~160.
+ - ti,pwm0 or ti,pwm1: Output pin number(s) for PWM channel 0 or 1.
+0 = output 0
+1 = output 1
+.
+.
+15 = output 15
+
+Example:
+PWM 0 is for RGB LED brightness control
+PWM 1 is for brightness control of LP8557 backlight device
+
+ {
+ lp3943@60 {
+ compatible = "ti,lp3943";
+ reg = <0x60>;
+
+ /*
+* PWM 0 : output 8, 9 and 10
+* PWM 1 : output 15
+*/
+ pwm3943: pwm {
+ compatible = "ti,lp3943-pwm";
+ #pwm-cells = <2>;
+ ti,pwm0 = <8 9 10>;
+ ti,pwm1 = <15>;
+ };
+ };
+
+};
+
+/* LEDs control with PWM 0 of LP3943 */
+pwmleds {
+ compatible = "pwm-leds";
+ rgb {
+ label = "indi::rgb";
+ pwms = < 0 1>;
+ max-brightness = <255>;
+ };
+};
+
+ {
+ /* Backlight control with PWM 1 of LP3943 */
+ backlight@2c {
+ compatible = "ti,lp8557";
+ reg = <0x2c>;
+
+ pwms = < 1 1>;
+ pwm-names = "lp8557";
+ };
+};
--
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
[PATCH v4 2/4] gpio: add LP3943 I2C GPIO expander driver
This is one of LP3943 MFD driver.
LP3943 is configurable as a GPIO expander, up to 16 GPIOs.
* Application note: how to configure LP3943 as a GPIO expander
http://www.ti.com/lit/an/snva287a/snva287a.pdf
* Supported GPIO controller operations
request, free, direction_input, direction_output, get and set
* GPIO direction register not supported
LP3943 doesn't have the GPIO direction register. It only provides input and
output status registers.
So, private data for the direction should be handled manually.
This variable is updated whenever the direction is changed and
used in 'get' operation.
* Pin assignment
A driver data, 'pin_used' is checked when a GPIO is requested.
If the GPIO is already assigned, then returns as failure.
If the GPIO is available, 'pin_used' is set.
When the GPIO is not used anymore, then it is cleared.
It is defined as unsigned long type for atomic bit operation APIs,
but only LSB 16bits are used because LP3943 has 16 outputs.
Signed-off-by: Milo Kim
Reviewed-by: Linus Walleij
---
* Patch v4
No update, same as v3
* Patch v3
Use inline function instead of macro(), to_lp3943_gpio().
Add 'lp3943_gpio_set_mode()' and use it in lp3943_gpio_direction_input() and
lp3943_gpio_set().
Few code cosmetic applied - indentations.
* Patch v2
Use bitops macros for bit manipulations.
Support device tree structure for the GPIO controller.
Add request() and free() for the pin assignment.
drivers/gpio/Kconfig |8 ++
drivers/gpio/Makefile |1 +
drivers/gpio/gpio-lp3943.c | 242
3 files changed, 251 insertions(+)
create mode 100644 drivers/gpio/gpio-lp3943.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 349b161..60fb6e7 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -360,6 +360,14 @@ config GPIO_ARIZONA
help
Support for GPIOs on Wolfson Arizona class devices.
+config GPIO_LP3943
+ tristate "TI/National Semiconductor LP3943 GPIO expander"
+ depends on MFD_LP3943
+ help
+ GPIO driver for LP3943 MFD.
+ LP3943 can be used as a GPIO expander which provides up to 16 GPIOs.
+ Open drain outputs are required for this usage.
+
config GPIO_MAX7300
tristate "Maxim MAX7300 GPIO expander"
depends on I2C
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 97438bf..d1e2836 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_GPIO_JANZ_TTL) += gpio-janz-ttl.o
obj-$(CONFIG_GPIO_KEMPLD) += gpio-kempld.o
obj-$(CONFIG_ARCH_KS8695) += gpio-ks8695.o
obj-$(CONFIG_GPIO_LANGWELL)+= gpio-langwell.o
+obj-$(CONFIG_GPIO_LP3943) += gpio-lp3943.o
obj-$(CONFIG_ARCH_LPC32XX) += gpio-lpc32xx.o
obj-$(CONFIG_GPIO_LYNXPOINT) += gpio-lynxpoint.o
obj-$(CONFIG_GPIO_MAX730X) += gpio-max730x.o
diff --git a/drivers/gpio/gpio-lp3943.c b/drivers/gpio/gpio-lp3943.c
new file mode 100644
index 000..7b8db88
--- /dev/null
+++ b/drivers/gpio/gpio-lp3943.c
@@ -0,0 +1,242 @@
+/*
+ * TI/National Semiconductor LP3943 GPIO driver
+ *
+ * Copyright 2013 Texas Instruments
+ *
+ * Author: Milo Kim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+enum lp3943_gpios {
+ LP3943_GPIO1,
+ LP3943_GPIO2,
+ LP3943_GPIO3,
+ LP3943_GPIO4,
+ LP3943_GPIO5,
+ LP3943_GPIO6,
+ LP3943_GPIO7,
+ LP3943_GPIO8,
+ LP3943_GPIO9,
+ LP3943_GPIO10,
+ LP3943_GPIO11,
+ LP3943_GPIO12,
+ LP3943_GPIO13,
+ LP3943_GPIO14,
+ LP3943_GPIO15,
+ LP3943_GPIO16,
+ LP3943_MAX_GPIO,
+};
+
+struct lp3943_gpio {
+ struct gpio_chip chip;
+ struct lp3943 *lp3943;
+ u16 input_mask; /* 1 = GPIO is input direction, 0 = output */
+};
+
+static inline struct lp3943_gpio *to_lp3943_gpio(struct gpio_chip *_chip)
+{
+ return container_of(_chip, struct lp3943_gpio, chip);
+}
+
+static int lp3943_gpio_request(struct gpio_chip *chip, unsigned offset)
+{
+ struct lp3943_gpio *lp3943_gpio = to_lp3943_gpio(chip);
+ struct lp3943 *lp3943 = lp3943_gpio->lp3943;
+
+ /* Return an error if the pin is already assigned */
+ if (test_and_set_bit(offset, >pin_used))
+ return -EBUSY;
+
+ return 0;
+}
+
+static void lp3943_gpio_free(struct gpio_chip *chip, unsigned offset)
+{
+ struct lp3943_gpio *lp3943_gpio = to_lp3943_gpio(chip);
+ struct lp3943 *lp3943 = lp3943_gpio->lp3943;
+
+ clear_bit(offset, >pin_used);
+}
+
+static int lp3943_gpio_set_mode(struct lp3943_gpio *lp3943_gpio, u8 offset,
+ u8 val)
+{
+ struct lp3943 *lp3943 =
[PATCH v4 3/4] pwm: add LP3943 PWM driver
This is the other of the LP3943 MFD driver.
LP3943 can be used as a PWM generator, up to 2 channels.
* Two PWM generators supported
* Supported PWM operations
request, free, config, enable and disable
* Pin assignment
A driver data, 'pin_used' is checked when a PWM is requested.
If the output pin is already assigned, then returns as failure.
If the pin is available, 'pin_used' is set.
When the PWM is not used anymore, then it is cleared.
It is defined as unsigned long type for atomic bit operation APIs,
but only LSB 16bits are used because LP3943 has 16 outputs.
Cc: Thierry Reding
Signed-off-by: Milo Kim
---
* Patch v4
No update, same as v3.
* Patch v3
Manual polarity not supported any more.
Add encapsulation functions for accessing internal data structure.
Use pwm_set_chip_data() and pwm_get_chip_data().
And other code fixes based on Thierry's feedback.
drivers/pwm/Kconfig | 10 ++
drivers/pwm/Makefile |1 +
drivers/pwm/pwm-lp3943.c | 314 ++
3 files changed, 325 insertions(+)
create mode 100644 drivers/pwm/pwm-lp3943.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 75840b5..9cf38bc 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -81,6 +81,16 @@ config PWM_JZ4740
To compile this driver as a module, choose M here: the module
will be called pwm-jz4740.
+config PWM_LP3943
+ tristate "TI/National Semiconductor LP3943 PWM support"
+ depends on MFD_LP3943
+ help
+ Generic PWM framework driver for LP3943 which supports two PWM
+ channels.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-lp3943.
+
config PWM_LPC32XX
tristate "LPC32XX PWM support"
depends on ARCH_LPC32XX
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 77a8c18..db8e349 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_PWM_ATMEL_TCB) += pwm-atmel-tcb.o
obj-$(CONFIG_PWM_BFIN) += pwm-bfin.o
obj-$(CONFIG_PWM_IMX) += pwm-imx.o
obj-$(CONFIG_PWM_JZ4740) += pwm-jz4740.o
+obj-$(CONFIG_PWM_LP3943) += pwm-lp3943.o
obj-$(CONFIG_PWM_LPC32XX) += pwm-lpc32xx.o
obj-$(CONFIG_PWM_MXS) += pwm-mxs.o
obj-$(CONFIG_PWM_PCA9685) += pwm-pca9685.o
diff --git a/drivers/pwm/pwm-lp3943.c b/drivers/pwm/pwm-lp3943.c
new file mode 100644
index 000..8a843a0
--- /dev/null
+++ b/drivers/pwm/pwm-lp3943.c
@@ -0,0 +1,314 @@
+/*
+ * TI/National Semiconductor LP3943 PWM driver
+ *
+ * Copyright 2013 Texas Instruments
+ *
+ * Author: Milo Kim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define LP3943_MAX_DUTY255
+#define LP3943_MIN_PERIOD 6250
+#define LP3943_MAX_PERIOD 160
+
+struct lp3943_pwm {
+ struct pwm_chip chip;
+ struct lp3943 *lp3943;
+ struct lp3943_platform_data *pdata;
+};
+
+static inline struct lp3943_pwm *to_lp3943_pwm(struct pwm_chip *_chip)
+{
+ return container_of(_chip, struct lp3943_pwm, chip);
+}
+
+static struct lp3943_pwm_map *
+lp3943_pwm_request_map(struct lp3943_pwm *lp3943_pwm, int hwpwm)
+{
+ struct lp3943_platform_data *pdata = lp3943_pwm->pdata;
+ struct lp3943 *lp3943 = lp3943_pwm->lp3943;
+ struct lp3943_pwm_map *pwm_map;
+ int i, offset;
+
+ pwm_map = kzalloc(sizeof(*pwm_map), GFP_KERNEL);
+ if (!pwm_map)
+ return ERR_PTR(-ENOMEM);
+
+ pwm_map->output = pdata->pwms[hwpwm]->output;
+ pwm_map->num_outputs = pdata->pwms[hwpwm]->num_outputs;
+
+ for (i = 0; i < pwm_map->num_outputs; i++) {
+ offset = pwm_map->output[i];
+
+ /* Return an error if the pin is already assigned */
+ if (test_and_set_bit(offset, >pin_used))
+ return ERR_PTR(-EBUSY);
+ }
+
+ return pwm_map;
+}
+
+static int lp3943_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ struct lp3943_pwm *lp3943_pwm = to_lp3943_pwm(chip);
+ struct lp3943_pwm_map *pwm_map;
+
+ pwm_map = lp3943_pwm_request_map(lp3943_pwm, pwm->hwpwm);
+ if (IS_ERR(pwm_map))
+ return PTR_ERR(pwm_map);
+
+ return pwm_set_chip_data(pwm, pwm_map);
+}
+
+static void lp3943_pwm_free_map(struct lp3943_pwm *lp3943_pwm,
+ struct lp3943_pwm_map *pwm_map)
+{
+ struct lp3943 *lp3943 = lp3943_pwm->lp3943;
+ int i, offset;
+
+ for (i = 0; i < pwm_map->num_outputs; i++) {
+ offset = pwm_map->output[i];
+ clear_bit(offset, >pin_used);
+ }
+
+ kfree(pwm_map);
+}
+
+static void
[PATCH v4 0/4] LP3943 MFD driver for a GPIO expander and a PWM generator
LP3943 is an integrated device capable of driving 16 output channels. It can be used for GPIO expander and PWM generators. LP3493 registers are controlled via the I2C interface. This patch-set consists of four parts - MFD, GPIO, PWM and documents. Update from v3 to v4: Move the driver description from the documentation to the MFD driver file. Milo Kim (4): mfd: add LP3943 MFD driver gpio: add LP3943 I2C GPIO expander driver pwm: add LP3943 PWM driver Documentation: add LP3943 DT bindings and document .../devicetree/bindings/gpio/gpio-lp3943.txt | 37 +++ Documentation/devicetree/bindings/mfd/lp3943.txt | 33 ++ .../devicetree/bindings/pwm/pwm-lp3943.txt | 58 drivers/gpio/Kconfig |8 + drivers/gpio/Makefile |1 + drivers/gpio/gpio-lp3943.c | 242 +++ drivers/mfd/Kconfig| 11 + drivers/mfd/Makefile |1 + drivers/mfd/lp3943.c | 167 +++ drivers/pwm/Kconfig| 10 + drivers/pwm/Makefile |1 + drivers/pwm/pwm-lp3943.c | 314 include/linux/mfd/lp3943.h | 114 +++ 13 files changed, 997 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-lp3943.txt create mode 100644 Documentation/devicetree/bindings/mfd/lp3943.txt create mode 100644 Documentation/devicetree/bindings/pwm/pwm-lp3943.txt create mode 100644 drivers/gpio/gpio-lp3943.c create mode 100644 drivers/mfd/lp3943.c create mode 100644 drivers/pwm/pwm-lp3943.c create mode 100644 include/linux/mfd/lp3943.h -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 1/4] mfd: add LP3943 MFD driver
LP3943 has 16 output pins which can be used as GPIO expander and PWM generator. * Regmap I2C interface for R/W LP3943 registers * Atomic operations for output pin assignment The driver should check whether requested pin is available or not. If the pin is already used, pin request returns as a failure. A driver data, 'pin_used' is checked when gpio_request() and pwm_request() are called. If the pin is available, then pin_used is set. And it is cleared when gpio_free() and pwm_free(). * Device tree support Compatible strings for GPIO and PWM driver. LP3943 platform data is PWM related, so parsing the device tree is implemented in the PWM driver. Signed-off-by: Milo Kim Acked-by: Lee Jones --- * Patch v4 Driver description was moved from the documentation in patch v3. * Patch v3 Now, output pin number is exactly matched with enum value of ' lp3943_pwm_output'. Use dev_get_platdata() helper function in probe(). Use module_i2c_driver() for initcall. * Patch v2 Handle atomic operations for output pin assignment. drivers/mfd/Kconfig| 11 drivers/mfd/Makefile |1 + drivers/mfd/lp3943.c | 148 include/linux/mfd/lp3943.h | 114 ++ 4 files changed, 274 insertions(+) create mode 100644 drivers/mfd/lp3943.c create mode 100644 include/linux/mfd/lp3943.h diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index e0e46f5..7058358 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -715,6 +715,17 @@ config MFD_DM355EVM_MSP boards. MSP430 firmware manages resets and power sequencing, inputs from buttons and the IR remote, LEDs, an RTC, and more. +config MFD_LP3943 + tristate "TI/National Semiconductor LP3943 MFD Driver" + depends on I2C + select MFD_CORE + select REGMAP_I2C + help + Support for the TI/National Semiconductor LP3943. + This driver consists of GPIO and PWM drivers. + With these functionalities, it can be used for LED string control or + general usage such like a GPIO controller and a PWM controller. + drivers/mfd/Kconfig| 11 +++ drivers/mfd/Makefile |1 + drivers/mfd/lp3943.c | 167 include/linux/mfd/lp3943.h | 114 ++ 4 files changed, 293 insertions(+) create mode 100644 drivers/mfd/lp3943.c create mode 100644 include/linux/mfd/lp3943.h diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index e0e46f5..7058358 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -715,6 +715,17 @@ config MFD_DM355EVM_MSP boards. MSP430 firmware manages resets and power sequencing, inputs from buttons and the IR remote, LEDs, an RTC, and more. +config MFD_LP3943 + tristate "TI/National Semiconductor LP3943 MFD Driver" + depends on I2C + select MFD_CORE + select REGMAP_I2C + help + Support for the TI/National Semiconductor LP3943. + This driver consists of GPIO and PWM drivers. + With these functionalities, it can be used for LED string control or + general usage such like a GPIO controller and a PWM controller. + config MFD_LP8788 bool "TI LP8788 Power Management Unit Driver" depends on I2C=y && GENERIC_HARDIRQS diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index 15b905c..a6d2b22 100644 --- a/drivers/mfd/Makefile +++ b/drivers/mfd/Makefile @@ -102,6 +102,7 @@ obj-$(CONFIG_PMIC_DA9052) += da9052-core.o obj-$(CONFIG_MFD_DA9052_SPI) += da9052-spi.o obj-$(CONFIG_MFD_DA9052_I2C) += da9052-i2c.o +obj-$(CONFIG_MFD_LP3943) += lp3943.o obj-$(CONFIG_MFD_LP8788) += lp8788.o lp8788-irq.o da9055-objs:= da9055-core.o da9055-i2c.o diff --git a/drivers/mfd/lp3943.c b/drivers/mfd/lp3943.c new file mode 100644 index 000..e322268 --- /dev/null +++ b/drivers/mfd/lp3943.c @@ -0,0 +1,167 @@ +/* + * TI/National Semiconductor LP3943 MFD Core Driver + * + * Copyright 2013 Texas Instruments + * + * Author: Milo Kim + * + * 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 + * published by the Free Software Foundation. + * + * Driver structure: + * LP3943 is an integrated device capable of driving 16 output channels. + * It can be used for a GPIO expander and PWM generators. + * + * LED controlGeneral usage for a device + * ___ + * + * LP3943 MFD GPIO expanderleds-gpioeg) HW enable pin + * | + * --- PWM generatorleds-pwm eg) PWM input + * + * Internal two PWM channels are used for LED dimming effect. + * And each output pin can be used as a GPIO as well. + * The LED
Re: [ 000/110] 3.10.13-stable review
On 09/24/2013 05:13 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.10.13 release. There are 110 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 Fri Sep 27 00:12:23 UTC 2013. 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.13-rc1.gz and the diffstat can be found below. Build test results: total: 110 pass: 110 Same as with 3.10.12. qemu: arm, microblaze, mips, mips64, ppc, sparc, sparc64, x86, x86_64 pass. sh passes with warning (same as with 3.10.12). 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/
[PATCH] tile: include: asm: use 'long long' instead of 'u64' for atomic64_t and its related functions
atomic* value is signed value, and atomic* functions need also process
signed value (parameter value, and return value), so use 'long long'
instead of 'u64'.
After replacement, it will also fix a bug for atomic64_add_negative():
"u64 is never less than 0".
The modifications are:
in vim, use "1,% s/\/long long/g" command.
remove redundant '__aligned(8)' and a type case '(u64 *)'.
be sure of 80 (and macro '\') columns limitation after replacement.
Signed-off-by: Chen Gang
---
arch/tile/include/asm/atomic.h|5 +++--
arch/tile/include/asm/atomic_32.h | 27 +++
arch/tile/include/asm/cmpxchg.h | 28 +---
arch/tile/lib/atomic_32.c |8
4 files changed, 39 insertions(+), 29 deletions(-)
diff --git a/arch/tile/include/asm/atomic.h b/arch/tile/include/asm/atomic.h
index d385eaa..7097984 100644
--- a/arch/tile/include/asm/atomic.h
+++ b/arch/tile/include/asm/atomic.h
@@ -166,7 +166,7 @@ static inline int atomic_cmpxchg(atomic_t *v, int o, int n)
*
* Atomically sets @v to @i and returns old @v
*/
-static inline u64 atomic64_xchg(atomic64_t *v, u64 n)
+static inline long long atomic64_xchg(atomic64_t *v, long long n)
{
return xchg64(>counter, n);
}
@@ -180,7 +180,8 @@ static inline u64 atomic64_xchg(atomic64_t *v, u64 n)
* Atomically checks if @v holds @o and replaces it with @n if so.
* Returns the old value at @v.
*/
-static inline u64 atomic64_cmpxchg(atomic64_t *v, u64 o, u64 n)
+static inline long long atomic64_cmpxchg(atomic64_t *v, long long o,
+ long long n)
{
return cmpxchg64(>counter, o, n);
}
diff --git a/arch/tile/include/asm/atomic_32.h
b/arch/tile/include/asm/atomic_32.h
index 0d0395b..0b613f9 100644
--- a/arch/tile/include/asm/atomic_32.h
+++ b/arch/tile/include/asm/atomic_32.h
@@ -80,7 +80,7 @@ static inline void atomic_set(atomic_t *v, int n)
/* A 64bit atomic type */
typedef struct {
- u64 __aligned(8) counter;
+ long long counter;
} atomic64_t;
#define ATOMIC64_INIT(val) { (val) }
@@ -91,14 +91,14 @@ typedef struct {
*
* Atomically reads the value of @v.
*/
-static inline u64 atomic64_read(const atomic64_t *v)
+static inline long long atomic64_read(const atomic64_t *v)
{
/*
* Requires an atomic op to read both 32-bit parts consistently.
* Casting away const is safe since the atomic support routines
* do not write to memory if the value has not been modified.
*/
- return _atomic64_xchg_add((u64 *)>counter, 0);
+ return _atomic64_xchg_add(>counter, 0);
}
/**
@@ -108,7 +108,7 @@ static inline u64 atomic64_read(const atomic64_t *v)
*
* Atomically adds @i to @v.
*/
-static inline void atomic64_add(u64 i, atomic64_t *v)
+static inline void atomic64_add(long long i, atomic64_t *v)
{
_atomic64_xchg_add(>counter, i);
}
@@ -120,7 +120,7 @@ static inline void atomic64_add(u64 i, atomic64_t *v)
*
* Atomically adds @i to @v and returns @i + @v
*/
-static inline u64 atomic64_add_return(u64 i, atomic64_t *v)
+static inline long long atomic64_add_return(long long i, atomic64_t *v)
{
smp_mb(); /* barrier for proper semantics */
return _atomic64_xchg_add(>counter, i) + i;
@@ -135,7 +135,8 @@ static inline u64 atomic64_add_return(u64 i, atomic64_t *v)
* Atomically adds @a to @v, so long as @v was not already @u.
* Returns non-zero if @v was not @u, and zero otherwise.
*/
-static inline u64 atomic64_add_unless(atomic64_t *v, u64 a, u64 u)
+static inline long long atomic64_add_unless(atomic64_t *v, long long a,
+ long long u)
{
smp_mb(); /* barrier for proper semantics */
return _atomic64_xchg_add_unless(>counter, a, u) != u;
@@ -151,7 +152,7 @@ static inline u64 atomic64_add_unless(atomic64_t *v, u64 a,
u64 u)
* atomic64_set() can't be just a raw store, since it would be lost if it
* fell between the load and store of one of the other atomic ops.
*/
-static inline void atomic64_set(atomic64_t *v, u64 n)
+static inline void atomic64_set(atomic64_t *v, long long n)
{
_atomic64_xchg(>counter, n);
}
@@ -236,11 +237,13 @@ extern struct __get_user
__atomic_xchg_add_unless(volatile int *p,
extern struct __get_user __atomic_or(volatile int *p, int *lock, int n);
extern struct __get_user __atomic_andn(volatile int *p, int *lock, int n);
extern struct __get_user __atomic_xor(volatile int *p, int *lock, int n);
-extern u64 __atomic64_cmpxchg(volatile u64 *p, int *lock, u64 o, u64 n);
-extern u64 __atomic64_xchg(volatile u64 *p, int *lock, u64 n);
-extern u64 __atomic64_xchg_add(volatile u64 *p, int *lock, u64 n);
-extern u64 __atomic64_xchg_add_unless(volatile u64 *p,
- int *lock, u64 o, u64 n);
+extern long long __atomic64_cmpxchg(volatile long long *p, int *lock,
+ long long o, long
[PATCH 1/2] mmc:sdhci-pci:Add O2Micor/BayHubTect PCI SD Host
From: "peter.guo"
Apply SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 for some SD Host Controller.
Apply SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC for some SD Host Controller.
Add O2Micro/BayHubTech SD Host Controller specified Init.
Signed-off-by: peter.guo
---
drivers/mmc/host/sdhci-pci.c | 129 ++
1 file changed, 129 insertions(+)
diff --git a/drivers/mmc/host/sdhci-pci.c b/drivers/mmc/host/sdhci-pci.c
index d7d6bc8..cf6070f 100644
--- a/drivers/mmc/host/sdhci-pci.c
+++ b/drivers/mmc/host/sdhci-pci.c
@@ -364,11 +364,49 @@ static const struct sdhci_pci_fixes sdhci_intel_byt_sd = {
#define O2_SD_ADMA10xE2
#define O2_SD_ADMA20xE7
#define O2_SD_INF_MOD 0xF1
+#defineO2_SD_PLL_SETTING 0x304
+#defineO2_SD_CLK_SETTING 0x328
+#defineO2_SD_UHS1_CAP_SETTING 0x33C
+#defineO2_SD_VENDOR_SETTING 0x110
+
+/* O2Micro SD Host Devices PCI IDs */
+#define PCI_DEVICE_ID_O2_8520 0x8520
+#definePCI_DEVICE_ID_O2_8420 0x8420
+#definePCI_DEVICE_ID_O2_8421 0x8421
+#definePCI_DEVICE_ID_O2_8620 0x8620
+#definePCI_DEVICE_ID_O2_8621 0x8621
+
+static int o2_probe_slot(struct sdhci_pci_slot *slot)
+{
+ struct sdhci_pci_chip *chip;
+ struct sdhci_host *host;
+ u32 reg;
+
+ chip = slot->chip;
+ host = slot->host;
+ switch (chip->pdev->device) {
+ case PCI_DEVICE_ID_O2_8420:
+ case PCI_DEVICE_ID_O2_8421:
+ case PCI_DEVICE_ID_O2_8520:
+ case PCI_DEVICE_ID_O2_8620:
+ case PCI_DEVICE_ID_O2_8621:
+ reg = sdhci_readl(host, O2_SD_VENDOR_SETTING);
+ if (reg & 0x1)
+ host->quirks |= SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12;
+
+ break;
+ default:
+ break;
+ }
+
+ return 0;
+}
static int o2_probe(struct sdhci_pci_chip *chip)
{
int ret;
u8 scratch;
+ u32 scratch_32;
switch (chip->pdev->device) {
case PCI_DEVICE_ID_O2_8220:
@@ -419,6 +457,59 @@ static int o2_probe(struct sdhci_pci_chip *chip)
return ret;
scratch |= 0x80;
pci_write_config_byte(chip->pdev, O2_SD_LOCK_WP, scratch);
+ break;
+
+ case PCI_DEVICE_ID_O2_8420:
+ case PCI_DEVICE_ID_O2_8421:
+ case PCI_DEVICE_ID_O2_8520:
+ case PCI_DEVICE_ID_O2_8620:
+ case PCI_DEVICE_ID_O2_8621:
+ /* UnLock WP */
+ ret = pci_read_config_byte(chip->pdev, O2_SD_LOCK_WP, );
+ if (ret)
+ return ret;
+ scratch &= 0x7f;
+ pci_write_config_byte(chip->pdev, O2_SD_LOCK_WP, scratch);
+
+ ret = pci_read_config_dword(chip->pdev,
+ O2_SD_PLL_SETTING, _32);
+ if (ret)
+ return ret;
+ /* Set timeout CLK */
+ ret = pci_read_config_dword(chip->pdev,
+ O2_SD_CLK_SETTING, _32);
+ if (ret)
+ return ret;
+ scratch_32 |= 0x07E0;
+ pci_write_config_dword(chip->pdev,
+ O2_SD_CLK_SETTING, scratch_32);
+
+ ret = pci_read_config_dword(chip->pdev,
+ O2_SD_CLKREQ, _32);
+ if (ret)
+ return ret;
+ scratch_32 |= 0x3;
+ pci_write_config_dword(chip->pdev, O2_SD_CLKREQ, scratch_32);
+ if (chip->pdev->device == PCI_DEVICE_ID_O2_8520) {
+
+ ret = pci_read_config_dword(chip->pdev,
+ O2_SD_UHS1_CAP_SETTING, _32);
+ if (ret)
+ return ret;
+ scratch_32 |= (1 << 21);
+ pci_write_config_dword(chip->pdev,
+ O2_SD_UHS1_CAP_SETTING, scratch_32);
+ }
+
+ /* Lock WP */
+ ret = pci_read_config_byte(chip->pdev,
+ O2_SD_LOCK_WP, );
+ if (ret)
+ return ret;
+ scratch |= 0x80;
+ pci_write_config_byte(chip->pdev, O2_SD_LOCK_WP, scratch);
+
+ break;
}
return 0;
@@ -615,6 +706,8 @@ static int jmicron_resume(struct sdhci_pci_chip *chip)
static const struct sdhci_pci_fixes sdhci_o2 = {
.probe = o2_probe,
+ .quirks = SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC,
+ .probe_slot = o2_probe_slot,
};
static const struct sdhci_pci_fixes sdhci_jmicron = {
@@ -979,6 +1072,42 @@ static const struct pci_device_id pci_ids[] = {
.driver_data= (kernel_ulong_t)_o2,
},
+ {
+ .vendor = PCI_VENDOR_ID_O2,
+
Re: [PATCH tip/core/rcu 01/11] mm: Place preemption point in do_mlockall() loop
On Tue, 24 Sep 2013 18:29:11 -0700 "Paul E. McKenney" wrote: > --- a/mm/mlock.c > +++ b/mm/mlock.c > @@ -736,6 +736,7 @@ static int do_mlockall(int flags) > > /* Ignore errors */ > mlock_fixup(vma, , vma->vm_start, vma->vm_end, newflags); > + cond_resched(); > } > out: > return 0; Might need one in munlock_vma_pages_range() as well - it's a matter of finding the right test case. This will be neverending :( -- 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: [ 000/117] 3.11.2-stable review
On 09/24/2013 05:17 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.11.2 release. There are 117 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 Fri Sep 27 00:16:31 UTC 2013. 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.11.2-rc1.gz and the diffstat can be found below. Build test results: total: 110 pass: 108 skipped: 2 fail: 0 3.11.1 had one failure (xtensa:allmodconfig) which has been fixed. qemu: arm, microblaze, mips, mips64, ppc, sparc, sparc64, x86, x86_64 pass. sh passed with warning (same as with 3.11.1). 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 tip/core/rcu 0/6] Idle entry/exit changes for 3.13
On Tue, Sep 24, 2013 at 06:49:55PM -0700, Paul E. McKenney wrote: > Hello! > > This series updates RCU's idle entry/exit processing: > > 1.Remove redundant code from rcu_cleanup_after_idle(). > > 2.Throttle rcu_try_advance_all_cbs() execution to avoid kbuild > slowdowns. > > 3.Throttle non-lazy-callback-induced invoke_rcu_core() invocations. > > 4.Add primitive to determine whether it is safe to enter an RCU > read-side critical section. > > 5.Upgrade EXPORT_SYMBOL() to EXPORT_SYMBOL_GPL(). > > 6.Change rcu_is_cpu_idle() function to __rcu_is_watching() for > naming consistency. For all six: Reviewed-by: Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the akpm-current tree with the cgroup tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in
mm/memcontrol.c between commit b86278359484 ("memcg: stop using css id")
from the cgroup tree and commit 4c34cae8f277 ("revert "memcg: get rid of
soft-limit tree infrastructure"") from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc mm/memcontrol.c
index 65a46ef,7dda769..000
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@@ -5979,6 -6196,9 +6209,8 @@@ static void __mem_cgroup_free(struct me
int node;
size_t size = memcg_size();
+ mem_cgroup_remove_from_trees(memcg);
- free_css_id(_cgroup_subsys, >css);
+
for_each_node(node)
free_mem_cgroup_per_zone_info(memcg, node);
pgpdl1juIgLaf.pgp
Description: PGP signature
Re: [PATCH tip/core/rcu 0/3] Documentation updates for 3.13
On Tue, Sep 24, 2013 at 06:16:57PM -0700, Paul E. McKenney wrote: > Hello! > > This series provides a few documentation updates: > > 1.Update stall-warning documentation to catch up with recent updates. > > 2.Add a reference to the new vmstat-avoidance patch to the > file describing how to quiet per-CPU kthreads. > > 3.Fix a typo in Documentation/RCU/checklist.txt, courtesy of > Michael Opdenacker. I replied to 3 with a comment; for 1 and 2: Reviewed-by: Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/rcu 3/3] rcu: Fix occurrence of "the the" in checklist.txt
On Tue, Sep 24, 2013 at 06:17:23PM -0700, Paul E. McKenney wrote: > From: Michael Opdenacker > > Signed-off-by: Michael Opdenacker > Signed-off-by: Paul E. McKenney > --- See comment below. > Documentation/RCU/checklist.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt > index 7703ec7..ad6cba4 100644 > --- a/Documentation/RCU/checklist.txt > +++ b/Documentation/RCU/checklist.txt > @@ -203,7 +203,7 @@ over a rather long period of time, but improvements are > always welcome! > the corresponding readers must disable preemption, possibly > by calling rcu_read_lock_sched() and rcu_read_unlock_sched(). > If the updater uses synchronize_srcu() or call_srcu(), > - the the corresponding readers must use srcu_read_lock() and > + the corresponding readers must use srcu_read_lock() and I think this may have actually been a typo for "then", as in "If the updater uses ..., then the corresponding readers must use ...". > srcu_read_unlock(), and with the same srcu_struct. The rules for > the expedited primitives are the same as for their non-expedited > counterparts. Mixing things up will result in confusion and > -- > 1.8.1.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/
General placement of platform drivers and header files
Hi all: I have some drivers like Queue Manager and co-processor driver that are used by other drivers like Ethernet. Would it be appropriate to locate these drivers under one folder under drivers/misc/arch_name/xxx. My other question is on common header files (belonging to Queue Manager) but is sourced by Ethernet, where should those reside. Should they go under linux/include/misc/arch_name or directly sourced using the ../../../misc/arch_name/headerfile method. -- Feng Kan | Engineer Ph: 408.543.8382 Em: f...@apm.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 v5 00/10] VFS hot tracking
On Tue, Sep 24, 2013 at 8:20 AM, Al Viro wrote: > On Tue, Sep 17, 2013 at 06:17:45AM +0800, zwu.ker...@gmail.com wrote: >> From: Zhi Yong Wu >> >> The patchset is trying to introduce hot tracking function in >> VFS layer, which will keep track of real disk I/O in memory. >> By it, you will easily know more details about disk I/O, and >> then detect where disk I/O hot spots are. Also, specific FS >> can take use of it to do accurate defragment, and hot relocation >> support, etc. >> >> Now it's time to send out its V5 for external review, and >> any comments or ideas are appreciated, thanks. > > FWIW, the most fundamental problem I see with this is that the data > you are collecting is very sensitive to VM pressure details. The > hotspots wrt accesses (i.e. the stuff accessed all the time) will > not generate a lot of IO - they'll just sit in cache and look > very cold for your code. The stuff that is accessed very rarely > will also look cold. The hot ones will be those that get in and > out of cache often; IOW, the ones that are borderline - a bit less > memory pressure and they would've stayed in cache. I would expect > that to vary very much from run to run, which would make its use > for decisions like SSD vs. HD rather dubious... Are you suggesting to collect the hot info when the data is accessed while in cache? Of course, i will do the perf testings in some scenarios where VFS hot tracking is taking effect. > > Do you have that data collected on some real tasks under varying > memory pressure conditions? How stable the results are? Can you say what some real tasks are with more details? What kind of tests are you suggesting? and what results are you expecting to see? > > Another question: do you have perf profiles for system with that > stuff enabled, on boxen with many CPUs? You are using a lot of No, i will try to do it, and let you know its result. > spinlocks there; how much contention and cacheline ping-pong are > you getting on root->t_lock, for example? Ditto for cacheline > ping-pong on root->hot_cnt, while we are at it... Sorry, What kind of tests are you suggesting? and what results are you expecting to see? You know, i am one newbie for VFS, can you say with more details? how to do this test? > > Comments re code: > > * don't export the stuff until it's used by a module. And as > a general policy, please, do not use EXPORT_SYMBOL_GPL in fs/*. > Either don't export at all, or pick a sane API that would not > expose the guts of your code (== wouldn't require you to look > at the users to decide what will and will not break on changes > in your code) and export that. As far as I'm concerned, > all variants of EXPORT_SYMBOL are greatly overused and > EXPORT_SYMBOL_GPL is an exercise in masturbation... OK, i will make appropriate change based on your comments, thanks. > > * hot_inode_item_lookup() is a couple of functions smashed together; > split it, please, and lose the "alloc" argument. Do you mean that it should be split into two functions "alloc" function and "lookup" function? > > * hot_inode_item_unlink() is used when the last link is killed > by unlink(2), but not when it's killed by successful rename(2). > Why? Since we are using inode for collecting the hot info, rename(2) doesn't destroy that information as inodeis kept the same. > > * what happens when one opens a file, unlinks it and starts doing > IO? hot_freqs_update() will be called, re-creating the inode item > unlink has killed... Since the file won't be opened and used anymore by anybody else we don't bother about it. But i will improve it based on your comments. hot_freqs_update() will directly return and not re-create the inode item when this file has been unlinked. > > * for pity sake, use inlines - the same hot_freqs_update() on a filesystem > that doesn't have this stuff enabled will *still* branch pretty far > out of line, only to return after checking that ->s_hot_root is NULL. > Incidentally, we still have about twenty spare bits in inode flags; > use one (S_TEMP_COLLECTED, or something like that) instead of that > check. Checking it is considerably cheaper than checking ->i_sb->s_hot_root. OK, will use inline and bits flag in the next post, thanks. > > * hot_bit_shift() is bloody annoying. Why does true mean "up", false - > "down" and why is it easier to memorize that than just use explicit << > and >>? OK, will make appropriate changed based on your comments, thanks. > > * file->f_dentry->d_inode is spelled file_inode(file), TYVM (so does > file->f_path.dentry->d_inode, actually). Ditto. > > * #ifdef __KERNEL__ in include/linux/* is wrong; use include/uapi/linux/* > for the bits userland needs to see. Ditto. > > * checks for ->i_nlink belong under ->i_mutex. As it is, two unlink(2) > killing two last links to the same file can very well _both_ call > hot_inode_item_unlink(), with obvious unpleasant results. Ditto. -- Regards, Zhi Yong Wu -- To unsubscribe from this list: send the line
[PATCH 2/2] mmc: sdhci: Fix CMD12 and Tuning issues
From: "peter.guo"
- Change tuning_loop_counter check from not zero to less than zero
in function sdhci_execute_tuning; Becasue some host may need 40 times tuning,
but orginal code only think tuning times <= 39 is successfull.
- When Host Capability Reg (0x40) bit[43:40] is zero, retuning timer should be
disabled.
But Original code still start the timer.
Signed-off-by: peter.guo
---
drivers/mmc/host/sdhci.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 7a7fb4f..69413e4 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1050,6 +1050,13 @@ static void sdhci_send_command(struct sdhci_host *host,
struct mmc_command *cmd)
if (cmd->data || cmd->opcode == MMC_SEND_TUNING_BLOCK ||
cmd->opcode == MMC_SEND_TUNING_BLOCK_HS200)
flags |= SDHCI_CMD_DATA;
+ /*
+* According to SD Host Spec
+* Command Register offset 0xE bit[7:6] is command type
+* And Cmd12 should use Abort Type
+*/
+ if (cmd->opcode == MMC_STOP_TRANSMISSION)
+ flags |= SDHCI_CMD_ABORTCMD;
sdhci_writew(host, SDHCI_MAKE_CMD(cmd->opcode, flags), SDHCI_COMMAND);
}
@@ -1978,7 +1985,7 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, u32
opcode)
* The Host Driver has exhausted the maximum number of loops allowed,
* so use fixed sampling frequency.
*/
- if (!tuning_loop_counter || !timeout) {
+ if ((tuning_loop_counter < 0) || (!timeout)) {
ctrl &= ~SDHCI_CTRL_TUNED_CLK;
sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
} else {
@@ -2007,7 +2014,8 @@ out:
} else {
host->flags &= ~SDHCI_NEEDS_RETUNING;
/* Reload the new initial value for timer */
- if (host->tuning_mode == SDHCI_TUNING_MODE_1)
+ if ((host->tuning_mode == SDHCI_TUNING_MODE_1) &&
+ (host->tuning_count))
mod_timer(>tuning_timer, jiffies +
host->tuning_count * HZ);
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] mmc:sdhci-pci:Add O2Micor/BayHubTect PCI SD Host
From: "peter.guo"
Add O2Micor/BayHubTect SD Host Controller PCI Devices IDs in pci_ids.h.
Apply SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 for some SD Host Controller.
Apply SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC for some SD Host Controller.
Add O2Micro/BayHubTech SD Host Controller specified Init.
Signed-off-by: peter.guo
---
drivers/mmc/host/sdhci-pci.c | 122 ++
include/linux/pci_ids.h |5 ++
2 files changed, 127 insertions(+)
diff --git a/drivers/mmc/host/sdhci-pci.c b/drivers/mmc/host/sdhci-pci.c
index d7d6bc8..2387b3e 100644
--- a/drivers/mmc/host/sdhci-pci.c
+++ b/drivers/mmc/host/sdhci-pci.c
@@ -364,11 +364,42 @@ static const struct sdhci_pci_fixes sdhci_intel_byt_sd = {
#define O2_SD_ADMA10xE2
#define O2_SD_ADMA20xE7
#define O2_SD_INF_MOD 0xF1
+#defineO2_SD_PLL_SETTING 0x304
+#defineO2_SD_CLK_SETTING 0x328
+#defineO2_SD_UHS1_CAP_SETTING 0x33C
+#defineO2_SD_VENDOR_SETTING 0x110
+
+static int o2_probe_slot(struct sdhci_pci_slot *slot)
+{
+ struct sdhci_pci_chip *chip;
+ struct sdhci_host *host;
+ u32 reg;
+
+ chip = slot->chip;
+ host = slot->host;
+ switch (chip->pdev->device) {
+ case PCI_DEVICE_ID_O2_8420:
+ case PCI_DEVICE_ID_O2_8421:
+ case PCI_DEVICE_ID_O2_8520:
+ case PCI_DEVICE_ID_O2_8620:
+ case PCI_DEVICE_ID_O2_8621:
+ reg = sdhci_readl(host, O2_SD_VENDOR_SETTING);
+ if (reg & 0x1)
+ host->quirks |= SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12;
+
+ break;
+ default:
+ break;
+ }
+
+ return 0;
+}
static int o2_probe(struct sdhci_pci_chip *chip)
{
int ret;
u8 scratch;
+ u32 scratch_32;
switch (chip->pdev->device) {
case PCI_DEVICE_ID_O2_8220:
@@ -419,6 +450,59 @@ static int o2_probe(struct sdhci_pci_chip *chip)
return ret;
scratch |= 0x80;
pci_write_config_byte(chip->pdev, O2_SD_LOCK_WP, scratch);
+ break;
+
+ case PCI_DEVICE_ID_O2_8420:
+ case PCI_DEVICE_ID_O2_8421:
+ case PCI_DEVICE_ID_O2_8520:
+ case PCI_DEVICE_ID_O2_8620:
+ case PCI_DEVICE_ID_O2_8621:
+ /* UnLock WP */
+ ret = pci_read_config_byte(chip->pdev, O2_SD_LOCK_WP, );
+ if (ret)
+ return ret;
+ scratch &= 0x7f;
+ pci_write_config_byte(chip->pdev, O2_SD_LOCK_WP, scratch);
+
+ ret = pci_read_config_dword(chip->pdev,
+ O2_SD_PLL_SETTING, _32);
+ if (ret)
+ return ret;
+ /* Set timeout CLK */
+ ret = pci_read_config_dword(chip->pdev,
+ O2_SD_CLK_SETTING, _32);
+ if (ret)
+ return ret;
+ scratch_32 |= 0x07E0;
+ pci_write_config_dword(chip->pdev,
+ O2_SD_CLK_SETTING, scratch_32);
+
+ ret = pci_read_config_dword(chip->pdev,
+ O2_SD_CLKREQ, _32);
+ if (ret)
+ return ret;
+ scratch_32 |= 0x3;
+ pci_write_config_dword(chip->pdev, O2_SD_CLKREQ, scratch_32);
+ if (chip->pdev->device == PCI_DEVICE_ID_O2_8520) {
+
+ ret = pci_read_config_dword(chip->pdev,
+ O2_SD_UHS1_CAP_SETTING, _32);
+ if (ret)
+ return ret;
+ scratch_32 |= (1 << 21);
+ pci_write_config_dword(chip->pdev,
+ O2_SD_UHS1_CAP_SETTING, scratch_32);
+ }
+
+ /* Lock WP */
+ ret = pci_read_config_byte(chip->pdev,
+ O2_SD_LOCK_WP, );
+ if (ret)
+ return ret;
+ scratch |= 0x80;
+ pci_write_config_byte(chip->pdev, O2_SD_LOCK_WP, scratch);
+
+ break;
}
return 0;
@@ -615,6 +699,8 @@ static int jmicron_resume(struct sdhci_pci_chip *chip)
static const struct sdhci_pci_fixes sdhci_o2 = {
.probe = o2_probe,
+ .quirks = SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC,
+ .probe_slot = o2_probe_slot,
};
static const struct sdhci_pci_fixes sdhci_jmicron = {
@@ -979,6 +1065,42 @@ static const struct pci_device_id pci_ids[] = {
.driver_data= (kernel_ulong_t)_o2,
},
+ {
+ .vendor = PCI_VENDOR_ID_O2,
+ .device = PCI_DEVICE_ID_O2_8520,
+ .subvendor = PCI_ANY_ID,
+ .subdevice = PCI_ANY_ID,
+ .driver_data=
Re: [PATCH v5 0/6] rwsem: performance optimizations
On Tue, 2013-09-24 at 15:22 -0700, Tim Chen wrote: > We have incorporated various suggestions from Ingo for version 5 of this > patchset > and will like to have it merged if there are no objections. > > In this patchset, we introduce two categories of optimizations to read > write semaphore. The first four patches from Alex Shi reduce cache bouncing > of the > sem->count field by doing a pre-read of the sem->count and avoid cmpxchg > if possible. > > The last two patches introduce similar optimistic spinning logic as > the mutex code for the writer lock acquisition of rwsem. Right. We address the general 'mutexes out perform writer-rwsems' situations that has been seen in more than one case. Users now need not worry about performance issues when choosing between these two locking mechanisms. Thanks, Davidlohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] mmc:sdhci-pci:Add O2Micor/BayHubTect PCI SD Host
On Wed, Sep 25, 2013 at 03:20:07AM +, Peter Guo wrote: > --- a/include/linux/pci_ids.h > +++ b/include/linux/pci_ids.h > @@ -1700,6 +1700,11 @@ > #define PCI_DEVICE_ID_O2_82210x8221 > #define PCI_DEVICE_ID_O2_83200x8320 > #define PCI_DEVICE_ID_O2_83210x8321 > +#define PCI_DEVICE_ID_O2_85200x8520 > +#define PCI_DEVICE_ID_O2_8420 0x8420 > +#define PCI_DEVICE_ID_O2_8421 0x8421 > +#define PCI_DEVICE_ID_O2_8620 0x8620 > +#define PCI_DEVICE_ID_O2_8621 0x8621 Please read the top of this file for why you shouldn't be adding new device ids to it. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch V3] drivers: power: Add support for bq24735 charger
Hi,
> + if (gpio_is_valid(charger->pdata->status_gpio)) {
> + ret = devm_gpio_request(>dev,
> + charger->pdata->status_gpio,
> + name);
> + if (ret)
> + dev_err(>dev, "Failed GPIO request: %d\n",
> ret);
This should include GPIO number also to show error with more verbosity.
Regards
Manish Badarkhe
--
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 v4] PWM: atmel-pwm: add PWM controller driver
Add Atmel PWM controller driver based on PWM framework.
This is the basic function implementation of Atmel PWM controller.
It can work with PWM based led and backlight.
Signed-off-by: Bo Shen
---
Changes in v4:
- check the return value of clk_prepare()
- change channel register size as constant
Changes in v3:
- change compatible string from "atmel,sama5-pwm" to "atmel,sama5d3-pwm"
- Add PWM led example in binding documentation
- Using micro replace hard code
Changes in v2:
- Address the comments from Thierry Reding
.../devicetree/bindings/pwm/atmel-pwm.txt | 41 +++
drivers/pwm/Kconfig|9 +
drivers/pwm/Makefile |1 +
drivers/pwm/pwm-atmel.c| 350
4 files changed, 401 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/atmel-pwm.txt
create mode 100644 drivers/pwm/pwm-atmel.c
diff --git a/Documentation/devicetree/bindings/pwm/atmel-pwm.txt
b/Documentation/devicetree/bindings/pwm/atmel-pwm.txt
new file mode 100644
index 000..1c1a5fa
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/atmel-pwm.txt
@@ -0,0 +1,41 @@
+Atmel PWM controller
+
+Required properties:
+ - compatible: should be one of:
+- "atmel,at91sam9rl-pwm"
+- "atmel,sama5d3-pwm"
+ - reg: physical base address and length of the controller's registers
+ - #pwm-cells: Should be 3. See pwm.txt in this directory for a
+description of the cells format
+
+Example:
+
+ pwm0: pwm@f8034000 {
+ compatible = "atmel,at91sam9rl-pwm";
+ reg = <0xf8034000 0x400>;
+ #pwm-cells = <3>;
+ };
+
+The following the pwm led based example:
+
+ pwm0: pwm@f8034000 {
+ compatible = "atmel,at91sam9rl-pwm";
+ reg = <0xf8034000 0x400>;
+ #pwm-cells = <3>;
+ };
+
+ pwdleds {
+ compatible = "pwm-leds";
+
+ d1 {
+ label = "d1";
+ pwms = < 3 5000 0>
+ max-brightness = <255>;
+ };
+
+ d2 {
+ label = "d2";
+ pwms = < 1 5000 1>
+ max-brightness = <255>;
+ };
+ };
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 75840b5..54237b9 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -41,6 +41,15 @@ config PWM_AB8500
To compile this driver as a module, choose M here: the module
will be called pwm-ab8500.
+config PWM_ATMEL
+ tristate "Atmel PWM support"
+ depends on ARCH_AT91
+ help
+ Generic PWM framework driver for Atmel SoC.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-atmel.
+
config PWM_ATMEL_TCB
tristate "Atmel TC Block PWM support"
depends on ATMEL_TCLIB && OF
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 77a8c18..5b193f8 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -1,6 +1,7 @@
obj-$(CONFIG_PWM) += core.o
obj-$(CONFIG_PWM_SYSFS)+= sysfs.o
obj-$(CONFIG_PWM_AB8500) += pwm-ab8500.o
+obj-$(CONFIG_PWM_ATMEL)+= pwm-atmel.o
obj-$(CONFIG_PWM_ATMEL_TCB)+= pwm-atmel-tcb.o
obj-$(CONFIG_PWM_BFIN) += pwm-bfin.o
obj-$(CONFIG_PWM_IMX) += pwm-imx.o
diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
new file mode 100644
index 000..6af7a50
--- /dev/null
+++ b/drivers/pwm/pwm-atmel.c
@@ -0,0 +1,350 @@
+/*
+ * Driver for Atmel Pulse Width Modulation Controller
+ *
+ * Copyright (C) 2013 Atmel Corporation
+ * Bo Shen
+ *
+ * Licensed under GPLv2.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* The following is global registers for PWM controller */
+#define PWM_ENA0x04
+#define PWM_DIS0x08
+#define PWM_SR 0x0C
+/* bit field in SR */
+#define PWM_SR_ALL_CH_ON 0x0F
+
+/* The following register is PWM channel related registers */
+#define PWM_CH_REG_OFFSET 0x200
+#define PWM_CH_REG_SIZE0x20
+
+#define PWM_CMR0x0
+/* bit field in CMR */
+#define PWM_CMR_CPOL (1 << 9)
+#define PWM_CMR_UPD_CDTY (1 << 10)
+
+/* The following registers for PWM v1 */
+#define PWMv1_CDTY 0x04
+#define PWMv1_CPRD 0x08
+#define PWMv1_CUPD 0x10
+
+/* The following registers for PWM v2 */
+#define PWMv2_CDTY 0x04
+#define PWMv2_CDTYUPD 0x08
+#define PWMv2_CPRD 0x0C
+#define PWMv2_CPRDUPD 0x10
+
+/* max value for duty and period */
+/*
+ * Although the duty and period register is 32 bit,
+ * however only the LSB 16 bits are significant.
+ */
+#define PWM_MAX_DTY
Re: [patch] mm, mempolicy: make mpol_to_str robust and always succeed
On Tue, Sep 24, 2013 at 08:18:16PM -0700, David Rientjes wrote:
> On Tue, 24 Sep 2013, Dave Jones wrote:
>
> > > case MPOL_BIND:
> > > - /* Fall through */
> > > case MPOL_INTERLEAVE:
> > > nodes = pol->v.nodes;
> > > break;
> >
> > Any reason not to leave this ?
> >
> > "missing break" is the 2nd most common thing that coverity picks up.
> > Most of them are false positives like the above, but the lack of
> > annotations
> > in our source makes it time-consuming to pick through them all to find the
> > real bugs.
> >
>
> Check out things like drivers/mfd/wm5110-tables.c that do things like
>
> switch (reg) {
> case ARIZONA_SOFTWARE_RESET:
> case ARIZONA_DEVICE_REVISION:
> case ARIZONA_CTRL_IF_SPI_CFG_1:
> case ARIZONA_CTRL_IF_I2C1_CFG_1:
> case ARIZONA_CTRL_IF_I2C2_CFG_1:
> case ARIZONA_CTRL_IF_I2C1_CFG_2:
> case ARIZONA_CTRL_IF_I2C2_CFG_2:
> ...
>
> and that file has over 1,000 case statements. Having a
yikes, at first I thought that was output from a code generator.
> /* fall through */
>
> for all of them would be pretty annoying.
agreed, but with that example, it seems pretty obvious (to me at least)
that the lack of break's is intentional. Where it gets trickier to
make quick judgment calls is cases like the one I mentioned above,
where there are only a few cases, and there's real code involved in
some but not all cases.
> I don't remember any coding style rule about this (in fact
> Documentation/CodingStyle has examples of case statements without such a
> comment), I think it's just personal preference so I'll leave it to Andrew
> and what he prefers.
>
> (And if he prefers the /* fall through */ then we should ask that it be
> added to checkpatch.pl since it warns about a million other things and not
> this.)
The question of course is how much gain there is in doing anything at all here.
So far, I've only seen false positives from that checker, but there are hundreds
of them to pick through, so who knows what's further down the pile.
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] mm, mempolicy: make mpol_to_str robust and always succeed
On Tue, 24 Sep 2013, Dave Jones wrote:
> >case MPOL_BIND:
> > - /* Fall through */
> >case MPOL_INTERLEAVE:
> >nodes = pol->v.nodes;
> >break;
>
> Any reason not to leave this ?
>
> "missing break" is the 2nd most common thing that coverity picks up.
> Most of them are false positives like the above, but the lack of annotations
> in our source makes it time-consuming to pick through them all to find the
> real bugs.
>
Check out things like drivers/mfd/wm5110-tables.c that do things like
switch (reg) {
case ARIZONA_SOFTWARE_RESET:
case ARIZONA_DEVICE_REVISION:
case ARIZONA_CTRL_IF_SPI_CFG_1:
case ARIZONA_CTRL_IF_I2C1_CFG_1:
case ARIZONA_CTRL_IF_I2C2_CFG_1:
case ARIZONA_CTRL_IF_I2C1_CFG_2:
case ARIZONA_CTRL_IF_I2C2_CFG_2:
...
and that file has over 1,000 case statements. Having a
/* fall through */
for all of them would be pretty annoying.
I don't remember any coding style rule about this (in fact
Documentation/CodingStyle has examples of case statements without such a
comment), I think it's just personal preference so I'll leave it to Andrew
and what he prefers.
(And if he prefers the /* fall through */ then we should ask that it be
added to checkpatch.pl since it warns about a million other things and not
this.)
--
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: Fwd: linux-next: Tree for Jul 1 [ drm-intel-next: Several call-traces ]
On Mon, Sep 23, 2013 at 12:14 AM, Michael S. Tsirkin wrote: > On Mon, Aug 26, 2013 at 04:05:11PM +0300, Michael S. Tsirkin wrote: >> On Wed, Aug 21, 2013 at 11:22:58AM +0200, Sedat Dilek wrote: >> > [ Re: [Intel-gfx] i915 producing warnings with kernel 3.11-rc5 ] >> > >> > Hi, >> > >> > saw your posting in [1]... can you try the patches below? >> > Not sure if they apply. >> > Did you try v3.11-rc6(+)... or drm-intel-nightly? >> > >> > Regards, >> > - Sedat - >> > >> > [1] http://lists.freedesktop.org/archives/intel-gfx/2013-August/032154.html >> >> Same thing observed with v3.11-rc7. > > I still see this with 3.11. > Following this message, my VGA monitor goes blank and > shows an error suggesting a wrong resolution or frequency are set. > Anyone? Daniel, Jesse? still ongoing I think. Dave. -- 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: [GIT PULL] Devicetree fixes for 3.12
On Tue, Sep 24, 2013 at 7:53 PM, Rob Herring wrote: > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git Hmm. Did you mean for me to pull the "devicetree-fixes" tag? If so, please say so very explicitly. I don't want to have to search for these things.. IOW, if that's what you meant, that line should have said git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git tags/devicetree-fixes instead. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the block tree with Linus' tree
Hi Jens,
Today's linux-next merge of the block tree got a conflict in
drivers/md/bcache/request.c between commit c0f04d88e46d ("bcache: Fix
flushes in writeback mode") from Linus' tree and commit 53027147e43c
("bcache: Prune struct btree_op") and dd879364df83 ("bcache: Break up struct
search") from the block tree.
I fixed it up (I wasn't sure, but I used the version from Linus' tree -
see below) and can carry the fix as necessary (no action is required).
There were several other patches that affect this area that were commited
directly to Linus' tree today ...
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/md/bcache/request.c
index 71eb233,231b108..000
--- a/drivers/md/bcache/request.c
+++ b/drivers/md/bcache/request.c
@@@ -979,68 -1059,52 +1059,55 @@@ static void cached_dev_write(struct cac
if (should_writeback(dc, s->orig_bio,
cache_mode(dc, bio),
-s->op.skip)) {
- s->op.skip = false;
- s->writeback = true;
+s->iop.bypass)) {
+ s->iop.bypass = false;
+ s->iop.writeback = true;
}
- if (s->op.skip)
- goto skip;
-
- trace_bcache_write(s->orig_bio, s->writeback, s->op.skip);
+ if (s->iop.bypass) {
+ s->iop.bio = s->orig_bio;
+ bio_get(s->iop.bio);
- if (!s->writeback) {
- s->op.cache_bio = bio_clone_bioset(bio, GFP_NOIO,
- dc->disk.bio_split);
-
- closure_bio_submit(bio, cl, s->d);
- } else {
+ if (!(bio->bi_rw & REQ_DISCARD) ||
+ blk_queue_discard(bdev_get_queue(dc->bdev)))
+ closure_bio_submit(bio, cl, s->d);
+ } else if (s->iop.writeback) {
bch_writeback_add(dc);
- if (s->iop.flush_journal) {
+ if (bio->bi_rw & REQ_FLUSH) {
/* Also need to send a flush to the backing device */
- s->iop.bio = bio_clone_bioset(bio, GFP_NOIO,
-dc->disk.bio_split);
+ struct bio *flush = bio_alloc_bioset(0, GFP_NOIO,
+
dc->disk.bio_split);
- bio->bi_size = 0;
- bio->bi_vcnt = 0;
- closure_bio_submit(bio, cl, s->d);
+ flush->bi_rw= WRITE_FLUSH;
+ flush->bi_bdev = bio->bi_bdev;
+ flush->bi_end_io = request_endio;
+ flush->bi_private = cl;
+
+ closure_bio_submit(flush, cl, s->d);
} else {
- s->op.cache_bio = bio;
+ s->iop.bio = bio;
}
- }
- out:
- closure_call(>op.cl, bch_insert_data, NULL, cl);
- continue_at(cl, cached_dev_write_complete, NULL);
- skip:
- s->op.skip = true;
- s->op.cache_bio = s->orig_bio;
- bio_get(s->op.cache_bio);
+ } else {
+ s->iop.bio = bio_clone_bioset(bio, GFP_NOIO,
+ dc->disk.bio_split);
- if ((bio->bi_rw & REQ_DISCARD) &&
- !blk_queue_discard(bdev_get_queue(dc->bdev)))
- goto out;
+ closure_bio_submit(bio, cl, s->d);
+ }
- closure_bio_submit(bio, cl, s->d);
- goto out;
+ closure_call(>iop.cl, bch_data_insert, NULL, cl);
+ continue_at(cl, cached_dev_write_complete, NULL);
}
- static void request_nodata(struct cached_dev *dc, struct search *s)
+ static void cached_dev_nodata(struct closure *cl)
{
- struct closure *cl = >cl;
+ struct search *s = container_of(cl, struct search, cl);
struct bio *bio = >bio.bio;
- if (bio->bi_rw & REQ_DISCARD) {
- request_write(dc, s);
- return;
- }
-
- if (s->op.flush_journal)
- bch_journal_meta(s->op.c, cl);
+ if (s->iop.flush_journal)
+ bch_journal_meta(s->iop.c, cl);
+ /* If it's a flush, we send the flush to the backing device too */
closure_bio_submit(bio, cl, s->d);
continue_at(cl, cached_dev_bio_complete, NULL);
pgpsjR8J06F_7.pgp
Description: PGP signature
Re: [patch] mm, mempolicy: make mpol_to_str robust and always succeed
On Tue, Sep 24, 2013 at 07:58:22PM -0700, David Rientjes wrote: > case MPOL_BIND: > -/* Fall through */ > case MPOL_INTERLEAVE: > nodes = pol->v.nodes; > break; Any reason not to leave this ? "missing break" is the 2nd most common thing that coverity picks up. Most of them are false positives like the above, but the lack of annotations in our source makes it time-consuming to pick through them all to find the real bugs. Dave -- 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] blktrace: fix race with open trace files and directory removal
There's a bug in the blktrace client where it will stop and tear down
all of the tracing instances for devices it's opened whether it
successfully completed the setup or not.
By starting multiple blktrace processes on the same device, it's possible
to permanently disable blktrace on that device. The cause is that when
the first blktrace process to exit tears down the directory structure,
the trace files are still held open. Debugfs removes the dentries for the
open files just fine but the relay implementation doesn't remove the
dentries until all of the references to the file are dropped. This means
that if there are open files when debugfs_remove is called for the device
directory, the directory is not empty and can't be removed. Since the
shutdown of the blktrace structure xchg's the structure out, there's no
way to clean up the directory and any new blktrace processes will fail
to start because it can't create the directory.
This patch adds a kref to blk_trace so that we can release it after the
initial reference as well as all of the references accumulated by the
relay files are dropped.
I have a fix for the blktrace client to avoid the situation on older
kernels as well.
Signed-off-by: Jeff Mahoney
---
include/linux/blktrace_api.h |2 ++
kernel/trace/blktrace.c | 37 +
2 files changed, 35 insertions(+), 4 deletions(-)
--- a/include/linux/blktrace_api.h 2013-09-24 22:39:53.342710250 -0400
+++ b/include/linux/blktrace_api.h 2013-09-24 22:55:11.376936518 -0400
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
#include
#if defined(CONFIG_BLK_DEV_IO_TRACE)
@@ -24,6 +25,7 @@ struct blk_trace {
struct dentry *dropped_file;
struct dentry *msg_file;
atomic_t dropped;
+ struct kref kref;
};
extern int blk_trace_ioctl(struct block_device *, unsigned, char __user *);
--- a/kernel/trace/blktrace.c 2013-09-24 22:39:53.342710250 -0400
+++ b/kernel/trace/blktrace.c 2013-09-24 22:55:39.004572055 -0400
@@ -278,17 +278,33 @@ record_it:
static struct dentry *blk_tree_root;
static DEFINE_MUTEX(blk_tree_mutex);
-static void blk_trace_free(struct blk_trace *bt)
+static void blk_trace_release(struct kref *kref)
{
+ struct blk_trace *bt = container_of(kref, struct blk_trace, kref);
debugfs_remove(bt->msg_file);
debugfs_remove(bt->dropped_file);
- relay_close(bt->rchan);
debugfs_remove(bt->dir);
free_percpu(bt->sequence);
free_percpu(bt->msg_data);
kfree(bt);
}
+static void blk_trace_free(struct blk_trace *bt)
+{
+ /*
+* The directory can't be removed until it's empty.
+* The debugfs files created directly can be removed while
+* they're open. The debugfs files created by relay won't
+* be removed until they've been released. This drops our
+* references to the files but the directory (and the rest
+* of the blk_trace structure) won't be cleaned up until
+* all of the relay files are closed by the user.
+*/
+ relay_close(bt->rchan);
+ bt->rchan = NULL;
+ kref_put(>kref, blk_trace_release);
+}
+
static void blk_trace_cleanup(struct blk_trace *bt)
{
blk_trace_free(bt);
@@ -381,8 +397,10 @@ static int blk_subbuf_start_callback(str
static int blk_remove_buf_file_callback(struct dentry *dentry)
{
+ struct blk_trace *bt = dentry->d_parent->d_inode->i_private;
debugfs_remove(dentry);
+ kref_put(>kref, blk_trace_release);
return 0;
}
@@ -392,8 +410,15 @@ static struct dentry *blk_create_buf_fil
struct rchan_buf *buf,
int *is_global)
{
- return debugfs_create_file(filename, mode, parent, buf,
- _file_operations);
+ struct blk_trace *bt = parent->d_inode->i_private;
+ struct dentry *dentry;
+
+ dentry = debugfs_create_file(filename, mode, parent, buf,
+_file_operations);
+ if (dentry)
+ kref_get(>kref);
+
+ return dentry;
}
static struct rchan_callbacks blk_relay_callbacks = {
@@ -448,6 +473,8 @@ int do_blk_trace_setup(struct request_qu
if (!bt)
return -ENOMEM;
+ kref_init(>kref);
+
ret = -ENOMEM;
bt->sequence = alloc_percpu(unsigned long);
if (!bt->sequence)
@@ -474,6 +501,8 @@ int do_blk_trace_setup(struct request_qu
if (!dir)
goto err;
+ dir->d_inode->i_private = bt;
+
bt->dir = dir;
bt->dev = dev;
atomic_set(>dropped, 0);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] driver core : Fix use after free of dev->parent in device_shutdown
On Tue, Sep 24, 2013 at 6:14 PM, Ming Lei wrote: > It is better to save one line by below: > > parent = get_device(dev->parent); > Done. > > Reviewed-by: Ming Lei Thank you! -- Benson Leung Software Engineer, Chrom* OS ble...@chromium.org -- 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] ipc/sem.c: fix update sem_otime when calling sem_op in semaphore initialization
Hi Manfred
IIUC after reivewing your patch and src code, does it seem
sem_otime lost the chance to be updated when calling
semctl_main/semctl_setval?
In old codes, even whendo_smart_update(sma, NULL, 0, 0, ),
the otime can be updated after several conditions checking.
On Tue, 24 Sep 2013 23:09:33 +0200 from manf...@colorfullife.com wrote:
> On 09/22/2013 05:14 PM, Jia He wrote:
>> Hi Manfred
>>
>> On Sun, 22 Sep 2013 12:42:05 +0200 from manf...@colorfullife.com wrote:
>>> Hi all,
>>>
>>> On 09/22/2013 10:26 AM, Mike Galbraith wrote:
On Sun, 2013-09-22 at 10:17 +0200, Mike Galbraith wrote:
> On Sun, 2013-09-22 at 10:11 +0800, Jia He wrote:
>> In commit 0a2b9d4c,the update of semaphore's sem_otime(last semop time)
>> was removed because he wanted to move setting sem->sem_otime to one
>> place. But after that, the initial semop() will not set the otime
>> because its sem_op value is 0(in semtimedop,will not change
>> otime if alter == 1).
>>
>> the error case:
>> process_a(server) process_b(client)
>> semget()
>> semctl(SETVAL)
>> semop()
>> semget()
>> setctl(IP_STAT)
>> for(;;) { <--not successful here
>> check until sem_otime > 0
>> }
>>> Good catch:
>>> Since commit 0a2b9d4c, wait-for-zero semops do not update sem_otime anymore.
>>>
>>> Let's reverse that part of my commit and move the update of sem_otime back
>>> into perform_atomic_semop().
>>>
>>> Jia: If perform_atomic_semop() updates sem_otime, then the update in
>>> do_smart_update() is not necessary anymore.
>>> Thus the whole logic with passing arround "semop_completed" can be removed,
>>> too.
>>> Are you interested in writing that patch?
>>>
>> Not all perform_atomic_semop() can cover the points of do_smart_update()
>> after I move the parts of updating otime.
>> Eg. in semctl_setval/exit_sem/etc.That is, it seems I need to write some
>> other codes to update sem_otime outside perform_atomic_semop(). That
>> still violate your original goal---let one function do all the update otime
>> things.
> No. The original goal was an optimization:
> The common case is one semop that increases a semaphore value - and that
> allows another semop that is sleeping to proceed.
> Before, this caused two get_seconds() calls.
> The current (buggy) code avoids the 2nd call.
>
>> IMO, what if just remove the condition alter in sys_semtimedop:
>> -if (alter && error == 0)
>> + if (error == 0)
>> do_smart_update(sma, sops, nsops, 1, );
>> In old codes, it would set the otime even when sem_op == 0
> do_smart_update() can be expensive - thus it shouldn't be called if we didn't
> change anything.
>
> Attached is a proposed patch - fully untested. It is intended to be applied
> on top of Jia's patch.
>
> _If_ the performance degradation is too large, then the alternative would be
> to set sem_otime directly in semtimedop() for successfull non-alter
> operations.
>
> --
> Manfred
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] driver core : Fix use after free of dev->parent in device_shutdown
The put_device(dev) at the bottom of the loop of device_shutdown
may result in the dev being cleaned up. In device_create_release,
the dev is kfreed.
However, device_shutdown attempts to use the dev pointer again after
put_device by referring to dev->parent.
Copy the parent pointer instead to avoid this condition.
This bug was found on Chromium OS's chromeos-3.8, which is based on v3.8.11.
See bug report : https://code.google.com/p/chromium/issues/detail?id=297842
This can easily be reproduced when shutting down with
hidraw devices that report battery condition.
Two examples are the HP Bluetooth Mouse X4000b and the Apple Magic Mouse.
For example, with the magic mouse :
The dev in question is "hidraw0"
dev->parent is "magicmouse"
In the course of the shutdown for this device, the input event cleanup calls
a put on hidraw0, decrementing its reference count.
When we finally get to put_device(dev) in device_shutdown, kobject_cleanup
is called and device_create_release does kfree(dev).
dev->parent is no longer valid, and we may crash in
put_device(dev->parent).
This change should be applied on any kernel with this change :
d1c6c030fcec6f860d9bb6c632a3ebe62e28440b
Cc: sta...@vger.kernel.org
Signed-off-by: Benson Leung
Reviewed-by: Ming Lei
---
v2 : Saved a few lines as suggested by Ming Lei.
v1 : Initial
---
drivers/base/core.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index c7cfadc..34abf4d 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -2017,7 +2017,7 @@ EXPORT_SYMBOL_GPL(device_move);
*/
void device_shutdown(void)
{
- struct device *dev;
+ struct device *dev, *parent;
spin_lock(_kset->list_lock);
/*
@@ -2034,7 +2034,7 @@ void device_shutdown(void)
* prevent it from being freed because parent's
* lock is to be held
*/
- get_device(dev->parent);
+ parent = get_device(dev->parent);
get_device(dev);
/*
* Make sure the device is off the kset list, in the
@@ -2044,8 +2044,8 @@ void device_shutdown(void)
spin_unlock(_kset->list_lock);
/* hold lock to avoid race with probe/release */
- if (dev->parent)
- device_lock(dev->parent);
+ if (parent)
+ device_lock(parent);
device_lock(dev);
/* Don't allow any more runtime suspends */
@@ -2063,11 +2063,11 @@ void device_shutdown(void)
}
device_unlock(dev);
- if (dev->parent)
- device_unlock(dev->parent);
+ if (parent)
+ device_unlock(parent);
put_device(dev);
- put_device(dev->parent);
+ put_device(parent);
spin_lock(_kset->list_lock);
}
--
1.8.4
--
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] mm, mempolicy: make mpol_to_str robust and always succeed
mpol_to_str() should not fail. Currently, it either fails because the
string buffer is too small or because a string hasn't been defined for a
mempolicy mode.
If a new mempolicy mode is introduced and no string is defined for it,
just warn and return "unknown".
If the buffer is too small, just truncate the string and return, the same
behavior as snprintf().
This also fixes a bug where there was no NULL-byte termination when doing
*p++ = '=' and *p++ ':' and maxlen has been reached.
Signed-off-by: David Rientjes
---
fs/proc/task_mmu.c| 14 ++---
include/linux/mempolicy.h | 5 ++---
mm/mempolicy.c| 52 +++
3 files changed, 24 insertions(+), 47 deletions(-)
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -1385,8 +1385,8 @@ static int show_numa_map(struct seq_file *m, void *v, int
is_pid)
struct mm_struct *mm = vma->vm_mm;
struct mm_walk walk = {};
struct mempolicy *pol;
- int n;
- char buffer[50];
+ char buffer[64];
+ int nid;
if (!mm)
return 0;
@@ -1402,10 +1402,8 @@ static int show_numa_map(struct seq_file *m, void *v,
int is_pid)
walk.mm = mm;
pol = get_vma_policy(task, vma, vma->vm_start);
- n = mpol_to_str(buffer, sizeof(buffer), pol);
+ mpol_to_str(buffer, sizeof(buffer), pol);
mpol_cond_put(pol);
- if (n < 0)
- return n;
seq_printf(m, "%08lx %s", vma->vm_start, buffer);
@@ -1458,9 +1456,9 @@ static int show_numa_map(struct seq_file *m, void *v, int
is_pid)
if (md->writeback)
seq_printf(m, " writeback=%lu", md->writeback);
- for_each_node_state(n, N_MEMORY)
- if (md->node[n])
- seq_printf(m, " N%d=%lu", n, md->node[n]);
+ for_each_node_state(nid, N_MEMORY)
+ if (md->node[nid])
+ seq_printf(m, " N%d=%lu", nid, md->node[nid]);
out:
seq_putc(m, '\n');
diff --git a/include/linux/mempolicy.h b/include/linux/mempolicy.h
--- a/include/linux/mempolicy.h
+++ b/include/linux/mempolicy.h
@@ -168,7 +168,7 @@ int do_migrate_pages(struct mm_struct *mm, const nodemask_t
*from,
extern int mpol_parse_str(char *str, struct mempolicy **mpol);
#endif
-extern int mpol_to_str(char *buffer, int maxlen, struct mempolicy *pol);
+extern void mpol_to_str(char *buffer, int maxlen, struct mempolicy *pol);
/* Check if a vma is migratable */
static inline int vma_migratable(struct vm_area_struct *vma)
@@ -306,9 +306,8 @@ static inline int mpol_parse_str(char *str, struct
mempolicy **mpol)
}
#endif
-static inline int mpol_to_str(char *buffer, int maxlen, struct mempolicy *pol)
+static inline void mpol_to_str(char *buffer, int maxlen, struct mempolicy *pol)
{
- return 0;
}
static inline int mpol_misplaced(struct page *page, struct vm_area_struct *vma,
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -2840,62 +2840,45 @@ out:
* @maxlen: length of @buffer
* @pol: pointer to mempolicy to be formatted
*
- * Convert a mempolicy into a string.
- * Returns the number of characters in buffer (if positive)
- * or an error (negative)
+ * Convert @pol into a string. If @buffer is too short, truncate the string.
+ * Recommend a @maxlen of at least 32 for the longest mode, "interleave", the
+ * longest flag, "relative", and to display at least a few node ids.
*/
-int mpol_to_str(char *buffer, int maxlen, struct mempolicy *pol)
+void mpol_to_str(char *buffer, int maxlen, struct mempolicy *pol)
{
char *p = buffer;
- int l;
- nodemask_t nodes;
- unsigned short mode;
- unsigned short flags = pol ? pol->flags : 0;
-
- /*
-* Sanity check: room for longest mode, flag and some nodes
-*/
- VM_BUG_ON(maxlen < strlen("interleave") + strlen("relative") + 16);
+ nodemask_t nodes = NODE_MASK_NONE;
+ unsigned short mode = MPOL_DEFAULT;
+ unsigned short flags = 0;
- if (!pol || pol == _policy)
- mode = MPOL_DEFAULT;
- else
+ if (pol && pol != _policy) {
mode = pol->mode;
+ flags = pol->flags;
+ }
switch (mode) {
case MPOL_DEFAULT:
- nodes_clear(nodes);
break;
-
case MPOL_PREFERRED:
- nodes_clear(nodes);
if (flags & MPOL_F_LOCAL)
mode = MPOL_LOCAL;
else
node_set(pol->v.preferred_node, nodes);
break;
-
case MPOL_BIND:
- /* Fall through */
case MPOL_INTERLEAVE:
nodes = pol->v.nodes;
break;
-
default:
- return -EINVAL;
+ WARN_ON_ONCE(1);
+ snprintf(p, maxlen, "unknown");
+
Re: [PATCH tip/core/rcu 08/11] rcu: Micro-optimize rcu_cpu_has_callbacks()
Thank you for your whole work, firstly :-).
And your suggestion about testing (in our discussion) is also valuable
to me.
I need start LTP in q4. After referenced your suggestion, my first step
for using/learning LTP is not mainly for finding kernel issues, but for
testing kernel (to improve my kernel testing efficiency).
When I want to find issues by reading code, I will consider about LTP
too (I will try to find issues which can be tested by LTP).
On 09/25/2013 09:29 AM, Paul E. McKenney wrote:
> From: "Paul E. McKenney"
>
> The for_each_rcu_flavor() loop unconditionally scans all flavors, even
> when the first flavor might have some non-lazy callbacks. Once the
> loop has seen a non-lazy callback, further passes through the loop
> cannot change the state. This is not a huge problem, given that there
> can be at most three RCU flavors (RCU-bh, RCU-preempt, and RCU-sched),
> but this code is on the path to idle, so speeding it up even a small
> amount would have some benefit.
>
> This commit therefore does two things:
>
> 1.Rearranges the order of the list of RCU flavors in order to
> place the most active flavor first in the list. The most active
> RCU flavor is RCU-preempt, or, if there is no RCU-preempt,
> RCU-sched.
>
> 2.Reworks the for_each_rcu_flavor() to exit early when the first
> non-lazy callback is seen, or, in the case where the caller
> does not care about non-lazy callbacks (RCU_FAST_NO_HZ=n),
> when the first callback is seen.
>
> Reported-by: Chen Gang
> Signed-off-by: Paul E. McKenney
> ---
> kernel/rcutree.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/rcutree.c b/kernel/rcutree.c
> index e6f2e8f..49464ad 100644
> --- a/kernel/rcutree.c
> +++ b/kernel/rcutree.c
> @@ -2727,10 +2727,13 @@ static int rcu_cpu_has_callbacks(int cpu, bool
> *all_lazy)
>
> for_each_rcu_flavor(rsp) {
> rdp = per_cpu_ptr(rsp->rda, cpu);
> - if (rdp->qlen != rdp->qlen_lazy)
> + if (!rdp->nxtlist)
> + continue;
> + hc = true;
> + if (rdp->qlen != rdp->qlen_lazy || !all_lazy) {
> al = false;
> - if (rdp->nxtlist)
> - hc = true;
> + break;
> + }
> }
> if (all_lazy)
> *all_lazy = al;
> @@ -3297,8 +3300,8 @@ void __init rcu_init(void)
>
> rcu_bootup_announce();
> rcu_init_geometry();
> - rcu_init_one(_sched_state, _sched_data);
> rcu_init_one(_bh_state, _bh_data);
> + rcu_init_one(_sched_state, _sched_data);
> __rcu_init_preempt();
> open_softirq(RCU_SOFTIRQ, rcu_process_callbacks);
>
>
--
Chen Gang
--
Chen Gang
--
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 1/1] f2fs: don't GC or take an fs_lock from f2fs_initxattrs()
On 09/25/2013 04:49 AM, Russ Knize wrote:
> From: Russ Knize
>
> f2fs_initxattrs() is called internally from within F2FS and should
> not call functions that are used by VFS handlers. This avoids
> certain deadlocks:
>
> - vfs_create()
> - f2fs_create() <-- takes an fs_lock
> - f2fs_add_link()
>- __f2fs_add_link()
> - init_inode_metadata()
> - f2fs_init_security()
> - security_inode_init_security()
>- f2fs_initxattrs()
> - f2fs_setxattr() <-- also takes an fs_lock
>
> If the caller happens to grab the same fs_lock from the pool in both
> places, they will deadlock. There are also deadlocks involving
> multiple threads and mutexes:
>
> - f2fs_write_begin()
> - f2fs_balance_fs() <-- takes gc_mutex
> - f2fs_gc()
>- write_checkpoint()
> - block_operations()
> - mutex_lock_all() <-- blocks trying to grab all fs_locks
>
> - f2fs_mkdir() <-- takes an fs_lock
> - __f2fs_add_link()
> - f2fs_init_security()
>- security_inode_init_security()
> - f2fs_initxattrs()
> - f2fs_setxattr()
> - f2fs_balance_fs() <-- blocks trying to take gc_mutex
>
> Signed-off-by: Russ Knize
This solution is more thorough.
Reviewed-by: Gu Zheng
> ---
> fs/f2fs/xattr.c | 35 +--
> 1 file changed, 25 insertions(+), 10 deletions(-)
>
> diff --git a/fs/f2fs/xattr.c b/fs/f2fs/xattr.c
> index 1ac8a5f..3d900ea 100644
> --- a/fs/f2fs/xattr.c
> +++ b/fs/f2fs/xattr.c
> @@ -154,6 +154,9 @@ static int f2fs_xattr_advise_set(struct dentry *dentry,
> const char *name,
> }
>
> #ifdef CONFIG_F2FS_FS_SECURITY
> +static int __f2fs_setxattr(struct inode *inode, int name_index,
> + const char *name, const void *value, size_t value_len,
> + struct page *ipage);
> static int f2fs_initxattrs(struct inode *inode, const struct xattr
> *xattr_array,
> void *page)
> {
> @@ -161,7 +164,7 @@ static int f2fs_initxattrs(struct inode *inode, const
> struct xattr *xattr_array,
> int err = 0;
>
> for (xattr = xattr_array; xattr->name != NULL; xattr++) {
> - err = f2fs_setxattr(inode, F2FS_XATTR_INDEX_SECURITY,
> + err = __f2fs_setxattr(inode, F2FS_XATTR_INDEX_SECURITY,
> xattr->name, xattr->value,
> xattr->value_len, (struct page *)page);
> if (err < 0)
> @@ -469,16 +472,15 @@ cleanup:
> return error;
> }
>
> -int f2fs_setxattr(struct inode *inode, int name_index, const char *name,
> - const void *value, size_t value_len, struct page *ipage)
> +static int __f2fs_setxattr(struct inode *inode, int name_index,
> + const char *name, const void *value, size_t value_len,
> + struct page *ipage)
> {
> - struct f2fs_sb_info *sbi = F2FS_SB(inode->i_sb);
> struct f2fs_inode_info *fi = F2FS_I(inode);
> struct f2fs_xattr_entry *here, *last;
> void *base_addr;
> int found, newsize;
> size_t name_len;
> - int ilock;
> __u32 new_hsize;
> int error = -ENOMEM;
>
> @@ -493,10 +495,6 @@ int f2fs_setxattr(struct inode *inode, int name_index,
> const char *name,
> if (name_len > F2FS_NAME_LEN || value_len > MAX_VALUE_LEN(inode))
> return -ERANGE;
>
> - f2fs_balance_fs(sbi);
> -
> - ilock = mutex_lock_op(sbi);
> -
> base_addr = read_all_xattrs(inode, ipage);
> if (!base_addr)
> goto exit;
> @@ -578,7 +576,24 @@ int f2fs_setxattr(struct inode *inode, int name_index,
> const char *name,
> else
> update_inode_page(inode);
> exit:
> - mutex_unlock_op(sbi, ilock);
> kzfree(base_addr);
> return error;
> }
> +
> +int f2fs_setxattr(struct inode *inode, int name_index, const char *name,
> + const void *value, size_t value_len, struct page *ipage)
> +{
> + struct f2fs_sb_info *sbi = F2FS_SB(inode->i_sb);
> + int ilock;
> + int err;
> +
> + f2fs_balance_fs(sbi);
> +
> + ilock = mutex_lock_op(sbi);
> +
> + err = __f2fs_setxattr(inode, name_index, name, value, value_len, ipage);
> +
> + mutex_unlock_op(sbi, ilock);
> +
> + return err;
> +}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] Devicetree fixes for 3.12
Hi Linus,
Please pull these 3 DT fixes for 3.12.
Rob
The following changes since commit 4a10c2ac2f368583138b774ca41fac4207911983:
Linux 3.12-rc2 (2013-09-23 15:41:09 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
for you to fetch changes up to 53126a2f679382f3eac370a012290f19c672f088:
dts: Fix misspelling of Synopsys (2013-09-24 21:13:38 -0500)
DeviceTree fixes for 3.12
Clean-up to fix some warnings for !OF builds and spelling fixes in docs
- Clean-up openrisc prom.h
- Fix warnings caused by of_irq.h ifdefs
- Spelling fix for Synopsys
Dinh Nguyen (1):
dts: Fix misspelling of Synopsys
Rob Herring (2):
openrisc: clean-up prom.h
of: clean-up ifdefs in of_irq.h
.../devicetree/bindings/mmc/exynos-dw-mshc.txt | 10 ++---
.../devicetree/bindings/mmc/rockchip-dw-mshc.txt | 10 ++---
.../{synopsis-dw-mshc.txt => synopsys-dw-mshc.txt} | 8 ++--
.../devicetree/bindings/pci/designware-pcie.txt| 2 +-
arch/openrisc/include/asm/prom.h | 44
--
include/linux/of_irq.h | 20 --
6 files changed, 23 insertions(+), 71 deletions(-)
rename Documentation/devicetree/bindings/mmc/{synopsis-dw-mshc.txt =>
synopsys-dw-mshc.txt} (93%)
--
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] EFI: Runtime services virtual mapping
On 09/24/13 at 05:12pm, H. Peter Anvin wrote:
> On 09/24/2013 07:56 AM, Borislav Petkov wrote:
> > On Tue, September 24, 2013 2:45 pm, Dave Young wrote:
> >> Think again about this, how about 1:1 map them from a base address
> >> like -64G phy_addr -> (-64G + phy_addr), in this way we can avoid
> >> depending on the previous region size.
> >
> > Right, how we layout the regions is arbitrary as long as we start at
> > the same VA and use the same regions, in the same order and of the same
> > size...
> >
> >> For the zero region problem, we can resolve it as a standalone
> >> problem.
> >
> > ... however, we still need to understand why it fails mapping the boot
> > services region as some implementations apparently do call boot services
> > even after ExitBootServices(). IOW, we need that region mapped in the
> > kexec'ed kernel too.
> >
>
> I am starting to think that we really should explicitly pass along the
> EFI mappings to the secondary kernel. This will also help if we have to
> change the algorithm in a future kernel.
The 0 size mem region is still a problem even we pass the previous mapping
to 2nd kernel. So will be be enough to 1:1 map on high address and leave the
firmware provided memmap not touched, use a copy of memmap in kernel?
>
> The most logical way to do this is to define a new setup_data type and
> pass the entire set of physical-to-virtual mappings that way.
>
> For example:
>
> struct efi_mapping {
> u64 va; /* Virtual start address */
> u64 pa; /* Physical start address */
> u64 len;/* Length in bytes */
> u64 type; /* Mapping type */
> u64 reserved[3];/* Reserved, must be zero */
> };
>
> Adding some reserved fields seems like a prudent precaution; the map
> shouldn't be all that large anyway.
>
> -hpa
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Resend with ACK][PATCH] mm/arch: use NUMA_NODE
On Mon, 23 Sep 2013, Jianguo Wu wrote: > Use more appropriate NUMA_NO_NODE instead of -1 in all archs' module_alloc() > > Signed-off-by: Jianguo Wu > Acked-by: Ralf Baechle Acked-by: David Rientjes -- 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] oom: avoid killing init if it assume the oom killed thread's mm
On Mon, 23 Sep 2013, Ming Liu wrote: > After selecting a task to kill, the oom killer iterates all processes and > kills all other user threads that share the same mm_struct in different > thread groups. > > But in some extreme cases, the selected task happens to be a vfork child > of init process sharing the same mm_struct with it, which causes kernel > panic on init getting killed. This panic is observed in a busybox shell > that busybox itself is init, with a kthread keeps consuming memories. > We shouldn't be selecting a process where mm == init_mm in the first place, so this wouldn't fix the issue entirely. -- 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] EFI: Runtime services virtual mapping
On 09/24/13 at 04:56pm, Borislav Petkov wrote: > On Tue, September 24, 2013 2:45 pm, Dave Young wrote: > > Think again about this, how about 1:1 map them from a base address > > like -64G phy_addr -> (-64G + phy_addr), in this way we can avoid > > depending on the previous region size. > > Right, how we layout the regions is arbitrary as long as we start at > the same VA and use the same regions, in the same order and of the same > size... > > > For the zero region problem, we can resolve it as a standalone > > problem. > > ... however, we still need to understand why it fails mapping the boot > services region as some implementations apparently do call boot services > even after ExitBootServices(). IOW, we need that region mapped in the > kexec'ed kernel too. In 1st kernel, the memmap is provided by firmware and unchanged before we do the mapping, later efi_reserve_boot_services() try to reserve the mem range, but failed due to conflict with other region (why?), then the memmap item size is set to 0 (why?). In 2nd kernel, we use same memmap from firmware, but the boot service ranges size have been set to 0, thus efi mapping code will mapping runtime regions to different va from 1st kernel. -- Thanks Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 0/6] perf: New conditional branch filter
On Mon, 2013-09-23 at 14:45 +0530, Anshuman Khandual wrote: > On 09/21/2013 12:25 PM, Stephane Eranian wrote: > > On Tue, Sep 10, 2013 at 4:06 AM, Michael Ellerman > > wrote: > >> > > >> > On Fri, 2013-08-30 at 09:54 +0530, Anshuman Khandual wrote: > >>> > > This patchset is the re-spin of the original branch stack > >>> > > sampling > >>> > > patchset which introduced new PERF_SAMPLE_BRANCH_COND filter. This > >>> > > patchset > >>> > > also enables SW based branch filtering support for PPC64 platforms > >>> > > which have > >>> > > branch stack sampling support. With this new enablement, the branch > >>> > > filter support > >>> > > for PPC64 platforms have been extended to include all these > >>> > > combinations discussed > >>> > > below with a sample test application program. > >> > > >> > ... > >> > > >>> > > Mixed filters > >>> > > - > >>> > > (6) perf record -e branch-misses:u -j any_call,any_ret ./cprog > >>> > > Error: > >>> > > The perf.data file has no samples! > >>> > > > >>> > > NOTE: As expected. The HW filters all the branches which are calls > >>> > > and SW tries to find return > >>> > > branches in that given set. Both the filters are mutually exclussive, > >>> > > so obviously no samples > >>> > > found in the end profile. > >> > > >> > The semantics of multiple filters is not clear to me. It could be an OR, > >> > or an AND. You have implemented AND, does that match existing behaviour > >> > on x86 for example? > > > > The semantic on the API is OR. AND does not make sense: CALL & RETURN? > > On x86, the HW filter is an OR (default: ALL, set bit to disable a > > type). I suspect > > it is similar on PPC. > > Given the situation as explained here, which semantic would be better for > single > HW and multiple SW filters. Accordingly validate_instruction() function will > have > to be re-implemented. But I believe OR-ing the SW filters will be preferable. > > (1) (HW_FILTER_1) && (SW_FILTER_1) && (SW_FILTER_2) > or > (2) (HW_FILTER_1) && (SW_FILTER_1 || SW_FILTER_2) > > Please let me know your inputs and suggestions on this. Thank you. You need to implement the correct semantics, regardless of how the hardware happens to work. That means if multiple filters are specified you need to do all the filtering in software. cheers -- 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: new binutils needed for arm in 3.12-rc1
On Tue, 24 Sep 2013, Rob Landley wrote: > On 09/24/2013 04:48:00 PM, Russell King - ARM Linux wrote: > > Now, if you feel strongly about this, we _could_ introduce a > > CONFIG_OLD_BINUTILS and give everyone their cake - but it will be > > fragile. Not everyone will remember to get that right, because they'll > > be using the later binutils. Also, we already have an excessive number > > of potential breakage-inducing options and we certainly don't need > > another. > > I'm doing the regression testing either way, on several different > architectures. (Although I tend to to only really do a thorough job quarterly > when a new kernel comes out and it's time to make it work.) So I'm going to be > doing something locally like this anyway, and if a CONFIG_OLD_BINUTILS is > acceptable I might as well push it upstream. If you are convinced you have no choice but to stick to old binutils, I'd strongly suggest you make your binutils compatible with newer instruction syntax instead of making the kernel more complex. This is more in line with being future proof rather than stuck into the past. It could be as simple as making gas accept an extra argument for instructions like dsb and just ignoring it. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] TTY: hvc_dcc: probe for a JTAG connection before registering
From: Rob Herring
Enabling the ARM DCC console and using without a JTAG connection will
simply hang the system. Since distros like to turn on all options, this
is a reoccurring problem to debug. We can do better by checking if
anything is attached and handling characters. There is no way to probe
this, so send a newline and check that it is handled.
Cc: Paolo Pisati
Cc: Tim Gardner
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Signed-off-by: Rob Herring
---
v2: use time_is_after_jiffies
drivers/tty/hvc/hvc_dcc.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/tty/hvc/hvc_dcc.c b/drivers/tty/hvc/hvc_dcc.c
index 44fbeba..3502a7b 100644
--- a/drivers/tty/hvc/hvc_dcc.c
+++ b/drivers/tty/hvc/hvc_dcc.c
@@ -86,6 +86,21 @@ static int hvc_dcc_get_chars(uint32_t vt, char *buf, int
count)
return i;
}
+static bool hvc_dcc_check(void)
+{
+ unsigned long time = jiffies + (HZ / 10);
+
+ /* Write a test character to check if it is handled */
+ __dcc_putchar('\n');
+
+ while (time_is_after_jiffies(time)) {
+ if (!(__dcc_getstatus() & DCC_STATUS_TX))
+ return true;
+ }
+
+ return false;
+}
+
static const struct hv_ops hvc_dcc_get_put_ops = {
.get_chars = hvc_dcc_get_chars,
.put_chars = hvc_dcc_put_chars,
@@ -93,6 +108,9 @@ static const struct hv_ops hvc_dcc_get_put_ops = {
static int __init hvc_dcc_console_init(void)
{
+ if (!hvc_dcc_check())
+ return -ENODEV;
+
hvc_instantiate(0, 0, _dcc_get_put_ops);
return 0;
}
@@ -100,6 +118,9 @@ console_initcall(hvc_dcc_console_init);
static int __init hvc_dcc_init(void)
{
+ if (!hvc_dcc_check())
+ return -ENODEV;
+
hvc_alloc(0, 0, _dcc_get_put_ops, 128);
return 0;
}
--
1.8.1.2
--
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: manual merge of the drm-intel tree with the drm-intel-fixes tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_display.c between commit 67c72a122541
("drm/i915: preserve pipe A quirk in i9xx_set_pipeconf") from the
drm-intel-fixes tree and commit cf532bb25592 ("drm/i915: Move double wide
mode handling into pipe_config") from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/intel_display.c
index e5822e7,d12d563..000
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@@ -4775,21 -4881,8 +4881,12 @@@ static void i9xx_set_pipeconf(struct in
pipeconf = 0;
+ if (dev_priv->quirks & QUIRK_PIPEA_FORCE &&
+ I915_READ(PIPECONF(intel_crtc->pipe)) & PIPECONF_ENABLE)
+ pipeconf |= PIPECONF_ENABLE;
+
- if (intel_crtc->pipe == 0 && INTEL_INFO(dev)->gen < 4) {
- /* Enable pixel doubling when the dot clock is > 90% of the
(display)
-* core speed.
-*
-* XXX: No double-wide on 915GM pipe B. Is that the only reason
for the
-* pipe == 0 check?
-*/
- if (intel_crtc->config.requested_mode.clock >
- dev_priv->display.get_display_clock_speed(dev) * 9 / 10)
- pipeconf |= PIPECONF_DOUBLE_WIDE;
- }
+ if (intel_crtc->config.double_wide)
+ pipeconf |= PIPECONF_DOUBLE_WIDE;
/* only g4x and later have fancy bpc/dither controls */
if (IS_G4X(dev) || IS_VALLEYVIEW(dev)) {
pgpVlIxmzeCvO.pgp
Description: PGP signature
[PATCH tip/core/rcu 1/6] rcu: Remove redundant code from rcu_cleanup_after_idle()
From: "Paul E. McKenney"
The rcu_try_advance_all_cbs() function returns a bool saying whether or
not there are callbacks ready to invoke, but rcu_cleanup_after_idle()
rechecks this regardless. This commit therefore uses the value returned
by rcu_try_advance_all_cbs() instead of making rcu_cleanup_after_idle()
do this recheck.
Reported-by: Tibor Billes
Signed-off-by: Paul E. McKenney
Tested-by: Tibor Billes
---
kernel/rcutree_plugin.h | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
index 130c97b..18d9c91 100644
--- a/kernel/rcutree_plugin.h
+++ b/kernel/rcutree_plugin.h
@@ -1768,17 +1768,11 @@ static void rcu_prepare_for_idle(int cpu)
*/
static void rcu_cleanup_after_idle(int cpu)
{
- struct rcu_data *rdp;
- struct rcu_state *rsp;
if (rcu_is_nocb_cpu(cpu))
return;
- rcu_try_advance_all_cbs();
- for_each_rcu_flavor(rsp) {
- rdp = per_cpu_ptr(rsp->rda, cpu);
- if (cpu_has_callbacks_ready_to_invoke(rdp))
- invoke_rcu_core();
- }
+ if (rcu_try_advance_all_cbs())
+ invoke_rcu_core();
}
/*
--
1.8.1.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH tip/core/rcu 3/6] rcu: Throttle invoke_rcu_core() invocations due to non-lazy callbacks
From: "Paul E. McKenney"
If a non-lazy callback arrives on a CPU that has previously gone idle
with no non-lazy callbacks, invoke_rcu_core() forces the RCU core to
run. However, it does not update the conditions, which could result
in several closely spaced invocations of the RCU core, which in turn
could result in an excessively high context-switch rate and resulting
high overhead.
This commit therefore updates the ->all_lazy and ->nonlazy_posted_snap
fields to prevent closely spaced invocations.
Reported-by: Tibor Billes
Signed-off-by: Paul E. McKenney
Tested-by: Tibor Billes
---
kernel/rcutree_plugin.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
index d81e385..2c15d7c 100644
--- a/kernel/rcutree_plugin.h
+++ b/kernel/rcutree_plugin.h
@@ -1745,6 +1745,8 @@ static void rcu_prepare_for_idle(int cpu)
*/
if (rdtp->all_lazy &&
rdtp->nonlazy_posted != rdtp->nonlazy_posted_snap) {
+ rdtp->all_lazy = false;
+ rdtp->nonlazy_posted_snap = rdtp->nonlazy_posted;
invoke_rcu_core();
return;
}
--
1.8.1.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH tip/core/rcu 2/6] rcu: Throttle rcu_try_advance_all_cbs() execution
From: "Paul E. McKenney"
The rcu_try_advance_all_cbs() function is invoked on each attempted
entry to and every exit from idle. If this function determines that
there are callbacks ready to invoke, the caller will invoke the RCU
core, which in turn will result in a pair of context switches. If a
CPU enters and exits idle extremely frequently, this can result in
an excessive number of context switches and high CPU overhead.
This commit therefore causes rcu_try_advance_all_cbs() to throttle
itself, refusing to do work more than once per jiffy.
Reported-by: Tibor Billes
Signed-off-by: Paul E. McKenney
Tested-by: Tibor Billes
---
kernel/rcutree.h| 2 ++
kernel/rcutree_plugin.h | 12 +---
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/kernel/rcutree.h b/kernel/rcutree.h
index 5f97eab..52be957 100644
--- a/kernel/rcutree.h
+++ b/kernel/rcutree.h
@@ -104,6 +104,8 @@ struct rcu_dynticks {
/* idle-period nonlazy_posted snapshot. */
unsigned long last_accelerate;
/* Last jiffy CBs were accelerated. */
+ unsigned long last_advance_all;
+ /* Last jiffy CBs were all advanced. */
int tick_nohz_enabled_snap; /* Previously seen value from sysfs. */
#endif /* #ifdef CONFIG_RCU_FAST_NO_HZ */
};
diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
index 18d9c91..d81e385 100644
--- a/kernel/rcutree_plugin.h
+++ b/kernel/rcutree_plugin.h
@@ -1630,17 +1630,23 @@ module_param(rcu_idle_lazy_gp_delay, int, 0644);
extern int tick_nohz_enabled;
/*
- * Try to advance callbacks for all flavors of RCU on the current CPU.
- * Afterwards, if there are any callbacks ready for immediate invocation,
- * return true.
+ * Try to advance callbacks for all flavors of RCU on the current CPU, but
+ * only if it has been awhile since the last time we did so. Afterwards,
+ * if there are any callbacks ready for immediate invocation, return true.
*/
static bool rcu_try_advance_all_cbs(void)
{
bool cbs_ready = false;
struct rcu_data *rdp;
+ struct rcu_dynticks *rdtp = this_cpu_ptr(_dynticks);
struct rcu_node *rnp;
struct rcu_state *rsp;
+ /* Exit early if we advanced recently. */
+ if (jiffies == rdtp->last_advance_all)
+ return 0;
+ rdtp->last_advance_all = jiffies;
+
for_each_rcu_flavor(rsp) {
rdp = this_cpu_ptr(rsp->rda);
rnp = rdp->mynode;
--
1.8.1.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH tip/core/rcu 4/6] rcu: Is it safe to enter an RCU read-side critical section?
From: "Paul E. McKenney"
There is currently no way for kernel code to determine whether it
is safe to enter an RCU read-side critical section, in other words,
whether or not RCU is paying attention to the currently running CPU.
Given the large and increasing quantity of code shared by the idle loop
and non-idle code, the this shortcoming is becoming increasingly painful.
This commit therefore adds __rcu_is_watching(), which returns true if
it is safe to enter an RCU read-side critical section on the currently
running CPU. This function is quite fast, using only a __this_cpu_read().
However, the caller must disable preemption.
Reported-by: Steven Rostedt
Signed-off-by: Paul E. McKenney
---
include/linux/rcupdate.h | 8
include/linux/rcutiny.h | 9 +
include/linux/rcutree.h | 2 ++
kernel/rcutiny.c | 4 ++--
kernel/rcutree.c | 13 +
5 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index f1f1bc3..a53a21a 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -261,6 +261,10 @@ static inline void rcu_user_hooks_switch(struct
task_struct *prev,
rcu_irq_exit(); \
} while (0)
+#if defined(CONFIG_DEBUG_LOCK_ALLOC) || defined(CONFIG_RCU_TRACE) ||
defined(CONFIG_SMP)
+extern int rcu_is_cpu_idle(void);
+#endif /* #if defined(CONFIG_DEBUG_LOCK_ALLOC) || defined(CONFIG_RCU_TRACE) ||
defined(CONFIG_SMP) */
+
/*
* Infrastructure to implement the synchronize_() primitives in
* TREE_RCU and rcu_barrier_() primitives in TINY_RCU.
@@ -297,10 +301,6 @@ static inline void destroy_rcu_head_on_stack(struct
rcu_head *head)
}
#endif /* #else !CONFIG_DEBUG_OBJECTS_RCU_HEAD */
-#if defined(CONFIG_DEBUG_LOCK_ALLOC) || defined(CONFIG_SMP)
-extern int rcu_is_cpu_idle(void);
-#endif /* #if defined(CONFIG_DEBUG_LOCK_ALLOC) || defined(CONFIG_SMP) */
-
#if defined(CONFIG_HOTPLUG_CPU) && defined(CONFIG_PROVE_RCU)
bool rcu_lockdep_current_cpu_online(void);
#else /* #if defined(CONFIG_HOTPLUG_CPU) && defined(CONFIG_PROVE_RCU) */
diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h
index e31005e..bee6659 100644
--- a/include/linux/rcutiny.h
+++ b/include/linux/rcutiny.h
@@ -132,4 +132,13 @@ static inline void rcu_scheduler_starting(void)
}
#endif /* #else #ifdef CONFIG_DEBUG_LOCK_ALLOC */
+#ifdef CONFIG_RCU_TRACE
+
+static inline bool __rcu_is_watching(void)
+{
+ return !rcu_is_cpu_idle();
+}
+
+#endif /* #ifdef CONFIG_RCU_TRACE */
+
#endif /* __LINUX_RCUTINY_H */
diff --git a/include/linux/rcutree.h b/include/linux/rcutree.h
index 226169d..293613d 100644
--- a/include/linux/rcutree.h
+++ b/include/linux/rcutree.h
@@ -90,4 +90,6 @@ extern void exit_rcu(void);
extern void rcu_scheduler_starting(void);
extern int rcu_scheduler_active __read_mostly;
+extern bool __rcu_is_watching(void);
+
#endif /* __LINUX_RCUTREE_H */
diff --git a/kernel/rcutiny.c b/kernel/rcutiny.c
index 9ed6075..b4bc618 100644
--- a/kernel/rcutiny.c
+++ b/kernel/rcutiny.c
@@ -174,7 +174,7 @@ void rcu_irq_enter(void)
}
EXPORT_SYMBOL_GPL(rcu_irq_enter);
-#ifdef CONFIG_DEBUG_LOCK_ALLOC
+#if defined(CONFIG_DEBUG_LOCK_ALLOC) || defined(CONFIG_RCU_TRACE)
/*
* Test whether RCU thinks that the current CPU is idle.
@@ -185,7 +185,7 @@ int rcu_is_cpu_idle(void)
}
EXPORT_SYMBOL(rcu_is_cpu_idle);
-#endif /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
+#endif /* defined(CONFIG_DEBUG_LOCK_ALLOC) || defined(CONFIG_RCU_TRACE) */
/*
* Test whether the current CPU was interrupted from idle. Nested
diff --git a/kernel/rcutree.c b/kernel/rcutree.c
index 32618b3..910d868 100644
--- a/kernel/rcutree.c
+++ b/kernel/rcutree.c
@@ -671,6 +671,19 @@ int rcu_is_cpu_idle(void)
}
EXPORT_SYMBOL(rcu_is_cpu_idle);
+/**
+ * __rcu_is_watching - are RCU read-side critical sections safe?
+ *
+ * Return true if RCU is watching the running CPU, which means that
+ * this CPU can safely enter RCU read-side critical sections. Unlike
+ * rcu_is_cpu_idle(), the caller of __rcu_is_watching() must have at
+ * least disabled preemption.
+ */
+bool __rcu_is_watching(void)
+{
+ return !!(atomic_read(this_cpu_ptr(_dynticks.dynticks)) & 0x1);
+}
+
#if defined(CONFIG_PROVE_RCU) && defined(CONFIG_HOTPLUG_CPU)
/*
--
1.8.1.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH tip/core/rcu 5/6] rcu: Change EXPORT_SYMBOL() to EXPORT_SYMBOL_GPL()
From: "Paul E. McKenney" Commit e6b80a3b (rcu: Detect illegal rcu dereference in extended quiescent state) exported the pre-existing rcu_is_cpu_idle() function using EXPORT_SYMBOL(). However, this is inconsistent with the remaining exports from RCU, which are all EXPORT_SYMBOL_GPL(). The current state of affairs means that a non-GPL module could use rcu_is_cpu_idle(), but in a CONFIG_TREE_PREEMPT_RCU=y kernel would be unable to invoke rcu_read_lock() and rcu_read_unlock(). This commit therefore makes rcu_is_cpu_idle()'s export be consistent with the rest of RCU, namely EXPORT_SYMBOL_GPL(). Signed-off-by: Paul E. McKenney Cc: Frederic Weisbecker --- kernel/rcutree.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/rcutree.c b/kernel/rcutree.c index 910d868..1b123e1 100644 --- a/kernel/rcutree.c +++ b/kernel/rcutree.c @@ -669,7 +669,7 @@ int rcu_is_cpu_idle(void) preempt_enable(); return ret; } -EXPORT_SYMBOL(rcu_is_cpu_idle); +EXPORT_SYMBOL_GPL(rcu_is_cpu_idle); /** * __rcu_is_watching - are RCU read-side critical sections safe? -- 1.8.1.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH tip/core/rcu 6/6] rcu: Consistent rcu_is_watching() naming
From: "Paul E. McKenney"
The old rcu_is_cpu_idle() function is just __rcu_is_watching() with
preemption disabled. This commit therefore renames rcu_is_cpu_idle()
to rcu_is_watching.
Signed-off-by: Paul E. McKenney
---
include/linux/rcupdate.h | 18 +-
include/linux/rcutiny.h | 16
include/linux/rcutree.h | 2 +-
kernel/lockdep.c | 4 ++--
kernel/rcupdate.c| 2 +-
kernel/rcutiny.c | 6 +++---
kernel/rcutree.c | 36 ++--
7 files changed, 46 insertions(+), 38 deletions(-)
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index a53a21a..39cbb88 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -262,7 +262,7 @@ static inline void rcu_user_hooks_switch(struct task_struct
*prev,
} while (0)
#if defined(CONFIG_DEBUG_LOCK_ALLOC) || defined(CONFIG_RCU_TRACE) ||
defined(CONFIG_SMP)
-extern int rcu_is_cpu_idle(void);
+extern bool __rcu_is_watching(void);
#endif /* #if defined(CONFIG_DEBUG_LOCK_ALLOC) || defined(CONFIG_RCU_TRACE) ||
defined(CONFIG_SMP) */
/*
@@ -351,7 +351,7 @@ static inline int rcu_read_lock_held(void)
{
if (!debug_lockdep_rcu_enabled())
return 1;
- if (rcu_is_cpu_idle())
+ if (!rcu_is_watching())
return 0;
if (!rcu_lockdep_current_cpu_online())
return 0;
@@ -402,7 +402,7 @@ static inline int rcu_read_lock_sched_held(void)
if (!debug_lockdep_rcu_enabled())
return 1;
- if (rcu_is_cpu_idle())
+ if (!rcu_is_watching())
return 0;
if (!rcu_lockdep_current_cpu_online())
return 0;
@@ -771,7 +771,7 @@ static inline void rcu_read_lock(void)
__rcu_read_lock();
__acquire(RCU);
rcu_lock_acquire(_lock_map);
- rcu_lockdep_assert(!rcu_is_cpu_idle(),
+ rcu_lockdep_assert(rcu_is_watching(),
"rcu_read_lock() used illegally while idle");
}
@@ -792,7 +792,7 @@ static inline void rcu_read_lock(void)
*/
static inline void rcu_read_unlock(void)
{
- rcu_lockdep_assert(!rcu_is_cpu_idle(),
+ rcu_lockdep_assert(rcu_is_watching(),
"rcu_read_unlock() used illegally while idle");
rcu_lock_release(_lock_map);
__release(RCU);
@@ -821,7 +821,7 @@ static inline void rcu_read_lock_bh(void)
local_bh_disable();
__acquire(RCU_BH);
rcu_lock_acquire(_bh_lock_map);
- rcu_lockdep_assert(!rcu_is_cpu_idle(),
+ rcu_lockdep_assert(rcu_is_watching(),
"rcu_read_lock_bh() used illegally while idle");
}
@@ -832,7 +832,7 @@ static inline void rcu_read_lock_bh(void)
*/
static inline void rcu_read_unlock_bh(void)
{
- rcu_lockdep_assert(!rcu_is_cpu_idle(),
+ rcu_lockdep_assert(rcu_is_watching(),
"rcu_read_unlock_bh() used illegally while idle");
rcu_lock_release(_bh_lock_map);
__release(RCU_BH);
@@ -857,7 +857,7 @@ static inline void rcu_read_lock_sched(void)
preempt_disable();
__acquire(RCU_SCHED);
rcu_lock_acquire(_sched_lock_map);
- rcu_lockdep_assert(!rcu_is_cpu_idle(),
+ rcu_lockdep_assert(rcu_is_watching(),
"rcu_read_lock_sched() used illegally while idle");
}
@@ -875,7 +875,7 @@ static inline notrace void rcu_read_lock_sched_notrace(void)
*/
static inline void rcu_read_unlock_sched(void)
{
- rcu_lockdep_assert(!rcu_is_cpu_idle(),
+ rcu_lockdep_assert(rcu_is_watching(),
"rcu_read_unlock_sched() used illegally while idle");
rcu_lock_release(_sched_lock_map);
__release(RCU_SCHED);
diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h
index bee6659..09ebcbe 100644
--- a/include/linux/rcutiny.h
+++ b/include/linux/rcutiny.h
@@ -132,13 +132,21 @@ static inline void rcu_scheduler_starting(void)
}
#endif /* #else #ifdef CONFIG_DEBUG_LOCK_ALLOC */
-#ifdef CONFIG_RCU_TRACE
+#if defined(CONFIG_DEBUG_LOCK_ALLOC) || defined(CONFIG_RCU_TRACE)
-static inline bool __rcu_is_watching(void)
+static inline bool rcu_is_watching(void)
{
- return !rcu_is_cpu_idle();
+ return __rcu_is_watching();
}
-#endif /* #ifdef CONFIG_RCU_TRACE */
+#else /* defined(CONFIG_DEBUG_LOCK_ALLOC) || defined(CONFIG_RCU_TRACE) */
+
+static inline bool rcu_is_watching(void)
+{
+ return true;
+}
+
+
+#endif /* #else defined(CONFIG_DEBUG_LOCK_ALLOC) || defined(CONFIG_RCU_TRACE)
*/
#endif /* __LINUX_RCUTINY_H */
diff --git a/include/linux/rcutree.h b/include/linux/rcutree.h
index 293613d..4b9c815 100644
--- a/include/linux/rcutree.h
+++ b/include/linux/rcutree.h
@@ -90,6 +90,6 @@ extern void exit_rcu(void);
extern void rcu_scheduler_starting(void);
extern int rcu_scheduler_active __read_mostly;
-extern bool __rcu_is_watching(void);
+extern bool rcu_is_watching(void);
[PATCH tip/core/rcu 0/6] Idle entry/exit changes for 3.13
Hello! This series updates RCU's idle entry/exit processing: 1. Remove redundant code from rcu_cleanup_after_idle(). 2. Throttle rcu_try_advance_all_cbs() execution to avoid kbuild slowdowns. 3. Throttle non-lazy-callback-induced invoke_rcu_core() invocations. 4. Add primitive to determine whether it is safe to enter an RCU read-side critical section. 5. Upgrade EXPORT_SYMBOL() to EXPORT_SYMBOL_GPL(). 6. Change rcu_is_cpu_idle() function to __rcu_is_watching() for naming consistency. Thanx, Paul b/include/linux/rcupdate.h | 26 +++--- b/include/linux/rcutiny.h | 25 ++ b/include/linux/rcutree.h |4 ++- b/kernel/lockdep.c |4 +-- b/kernel/rcupdate.c|2 - b/kernel/rcutiny.c | 10 b/kernel/rcutree.c | 51 - b/kernel/rcutree.h |2 + b/kernel/rcutree_plugin.h | 24 +++-- 9 files changed, 92 insertions(+), 56 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel/groups.c: consider about NULL for 'group_info' in all related extern functions
On 09/25/2013 09:14 AM, Tejun Heo wrote: > On Wed, Sep 25, 2013 at 09:06:52AM +0800, Chen Gang wrote: >> OK, I see, the 'root cause' is: "you are not the related maintainer >> either", so it is really necessary for me to spend additional time >> resource on it :-(. > > Yeah, at least partly. That and the fact that I'm not too willing to > dig into the code without further evidence. It isn't anything strange > to ask tho and I'm likely to do that even for subsystems that I know > intimately if the subject code has been stable / stale for years and > the analysis doesn't seem immediately convincing. And, if my > experience is anything to go by, it's not too unlikely that you might > hit something which doesn't agree with your current assumptions while > trying to actually trigger the problem. > > Thanks. > Excuse me, my English is not quite well, I do not quite understand what you said (but it seems what you said is reasonable, and not need reply). Thanks. -- Chen Gang -- 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/
[ 05/28] ARM: PCI: versatile: Fix SMAP register offsets
3.0-stable review patch. If anyone has any objections, please let me know. -- From: Peter Maydell commit 99f2b130370b904ca5300079243fdbcafa2c708b upstream. The SMAP register offsets in the versatile PCI controller code were all off by four. (This didn't have any observable bad effects because on this board PHYS_OFFSET is zero, and (a) writing zero to the flags register at offset 0x10 has no effect and (b) the reset value of the SMAP register is zero anyway, so failing to write SMAP2 didn't matter.) Signed-off-by: Peter Maydell Reviewed-by: Linus Walleij Signed-off-by: Kevin Hilman Signed-off-by: Greg Kroah-Hartman --- arch/arm/mach-versatile/pci.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/arch/arm/mach-versatile/pci.c +++ b/arch/arm/mach-versatile/pci.c @@ -43,9 +43,9 @@ #define PCI_IMAP0 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x0) #define PCI_IMAP1 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x4) #define PCI_IMAP2 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x8) -#define PCI_SMAP0 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x10) -#define PCI_SMAP1 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x14) -#define PCI_SMAP2 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x18) +#define PCI_SMAP0 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x14) +#define PCI_SMAP1 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x18) +#define PCI_SMAP2 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x1c) #define PCI_SELFID __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0xc) #define DEVICE_ID_OFFSET 0x00 -- 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/
[ 00/28] 3.0.97-stable review
This is the start of the stable review cycle for the 3.0.97 release. There are 28 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 Fri Sep 27 00:05:34 UTC 2013. 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.0.97-rc1.gz and the diffstat can be found below. thanks, greg k-h - Pseudo-Shortlog of commits: Greg Kroah-Hartman Linux 3.0.97-rc1 Anand Avati fuse: invalidate inode attributes on xattr modification Maxim Patlasov fuse: postpone end_page_writeback() in fuse_writepage_locked() Sergei Shtylyov mmc: tmio_mmc_dma: fix PIO fallback on SDHI Jan Kara isofs: Refuse RW mount of the filesystem instead of making it RO Libin mm/huge_memory.c: fix potential NULL pointer dereference Greg Thelen memcg: fix multiple large threshold notifications Jie Liu ocfs2: fix the end cluster offset of FIEMAP Kees Cook HID: check for NULL field when setting values Kees Cook HID: ntrig: validate feature report details Kees Cook HID: validate HID report id size Kees Cook HID: pantherlord: validate output report details Felix Fietkau ath9k: avoid accessing MRC registers on single-chain devices Felix Fietkau ath9k: always clear ps filter bit on new assoc Takashi Iwai ALSA: hda - Add Toshiba Satellite C870 to MSI blacklist Mike Dyer ASoC: wm8960: Fix PLL register writes Tejun Heo rculist: list_first_or_null_rcu() should use list_entry_rcu() Hans de Goede usb: config->desc.bLength may not exceed amount of data returned by the device Oliver Neukum USB: cdc-wdm: fix race between interrupt handler and tasklet Johan Hovold USB: mos7720: fix big-endian control requests Dan Carpenter USB: mos7720: use GFP_ATOMIC under spinlock Dan Carpenter staging: comedi: dt282x: dt282x_ai_insn_read() always fails Jeff Layton cifs: ensure that srv_mutex is held when dealing with ssocket pointer Shawn Nematbakhsh usb: xhci: Disable runtime PM suspend for quirky controllers Peter Maydell ARM: PCI: versatile: Fix SMAP register offsets Roger Pau Monne xen-gnt: prevent adding duplicate gnt callbacks Anton Blanchard powerpc: Handle unaligned ldbrx/stdbrx Herbert Xu crypto: api - Fix race condition in larval lookup Alan Stern SCSI: sd: Fix potential out-of-bounds access - Diffstat: Makefile| 4 ++-- arch/arm/mach-versatile/pci.c | 6 +++--- arch/powerpc/kernel/align.c | 10 ++ crypto/api.c| 7 ++- drivers/hid/hid-core.c | 19 ++- drivers/hid/hid-ntrig.c | 3 ++- drivers/hid/hid-pl.c| 10 -- drivers/mmc/host/tmio_mmc_dma.c | 4 ++-- drivers/net/wireless/ath/ath9k/ar9003_phy.c | 4 drivers/net/wireless/ath/ath9k/xmit.c | 1 + drivers/scsi/sd.c | 11 +++ drivers/staging/comedi/drivers/dt282x.c | 3 ++- drivers/usb/class/cdc-wdm.c | 13 + drivers/usb/core/config.c | 3 ++- drivers/usb/host/xhci.c | 22 ++ drivers/usb/serial/mos7720.c| 6 +++--- drivers/xen/grant-table.c | 13 +++-- fs/cifs/connect.c | 2 ++ fs/fuse/dir.c | 4 fs/fuse/file.c | 3 ++- fs/isofs/inode.c| 16 +--- fs/ocfs2/extent_map.c | 1 - include/linux/hid.h | 4 +++- include/linux/rculist.h | 5 +++-- mm/huge_memory.c| 2 ++ mm/memcontrol.c | 8 +++- sound/pci/hda/hda_intel.c | 1 + sound/soc/codecs/wm8960.c | 6 +++--- 28 files changed, 136 insertions(+), 55 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 03/28] powerpc: Handle unaligned ldbrx/stdbrx
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Anton Blanchard
commit 230aef7a6a23b6166bd4003bfff5af23c9bd381f upstream.
Normally when we haven't implemented an alignment handler for
a load or store instruction the process will be terminated.
The alignment handler uses the DSISR (or a pseudo one) to locate
the right handler. Unfortunately ldbrx and stdbrx overlap lfs and
stfs so we incorrectly think ldbrx is an lfs and stdbrx is an
stfs.
This bug is particularly nasty - instead of terminating the
process we apply an incorrect fixup and continue on.
With more and more overlapping instructions we should stop
creating a pseudo DSISR and index using the instruction directly,
but for now add a special case to catch ldbrx/stdbrx.
Signed-off-by: Anton Blanchard
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Greg Kroah-Hartman
---
arch/powerpc/kernel/align.c | 10 ++
1 file changed, 10 insertions(+)
--- a/arch/powerpc/kernel/align.c
+++ b/arch/powerpc/kernel/align.c
@@ -764,6 +764,16 @@ int fix_alignment(struct pt_regs *regs)
nb = aligninfo[instr].len;
flags = aligninfo[instr].flags;
+ /* ldbrx/stdbrx overlap lfs/stfs in the DSISR unfortunately */
+ if (IS_XFORM(instruction) && ((instruction >> 1) & 0x3ff) == 532) {
+ nb = 8;
+ flags = LD+SW;
+ } else if (IS_XFORM(instruction) &&
+ ((instruction >> 1) & 0x3ff) == 660) {
+ nb = 8;
+ flags = ST+SW;
+ }
+
/* Byteswap little endian loads and stores */
swiz = 0;
if (regs->msr & MSR_LE) {
--
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/
[ 02/28] crypto: api - Fix race condition in larval lookup
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Herbert Xu
commit 77dbd7a95e4a4f15264c333a9e9ab97ee27dc2aa upstream.
crypto_larval_lookup should only return a larval if it created one.
Any larval created by another entity must be processed through
crypto_larval_wait before being returned.
Otherwise this will lead to a larval being killed twice, which
will most likely lead to a crash.
Reported-by: Kees Cook
Tested-by: Kees Cook
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman
---
crypto/api.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/crypto/api.c
+++ b/crypto/api.c
@@ -40,6 +40,8 @@ static inline struct crypto_alg *crypto_
return alg;
}
+static struct crypto_alg *crypto_larval_wait(struct crypto_alg *alg);
+
struct crypto_alg *crypto_mod_get(struct crypto_alg *alg)
{
return try_module_get(alg->cra_module) ? crypto_alg_get(alg) : NULL;
@@ -150,8 +152,11 @@ static struct crypto_alg *crypto_larval_
}
up_write(_alg_sem);
- if (alg != >alg)
+ if (alg != >alg) {
kfree(larval);
+ if (crypto_is_larval(alg))
+ alg = crypto_larval_wait(alg);
+ }
return alg;
}
--
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/
[ 17/28] ath9k: avoid accessing MRC registers on single-chain devices
3.0-stable review patch. If anyone has any objections, please let me know. -- From: Felix Fietkau commit a1c781bb20ac1e03280e420abd47a99eb8bbdd3b upstream. They are not implemented, and accessing them might trigger errors Signed-off-by: Felix Fietkau Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman --- drivers/net/wireless/ath/ath9k/ar9003_phy.c |4 1 file changed, 4 insertions(+) --- a/drivers/net/wireless/ath/ath9k/ar9003_phy.c +++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c @@ -1005,6 +1005,10 @@ static bool ar9003_hw_ani_control(struct * is_on == 0 means MRC CCK is OFF (more noise imm) */ bool is_on = param ? 1 : 0; + + if (ah->caps.rx_chainmask == 1) + break; + REG_RMW_FIELD(ah, AR_PHY_MRC_CCK_CTRL, AR_PHY_MRC_CCK_ENABLE, is_on); REG_RMW_FIELD(ah, AR_PHY_MRC_CCK_CTRL, -- 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/
[ 16/28] ath9k: always clear ps filter bit on new assoc
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Felix Fietkau
commit 026d5b07c03458f9c0ccd19c3850564a5409c325 upstream.
Otherwise in some cases, EAPOL frames might be filtered during the
initial handshake, causing delays and assoc failures.
Signed-off-by: Felix Fietkau
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/wireless/ath/ath9k/xmit.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2433,6 +2433,7 @@ void ath_tx_node_init(struct ath_softc *
for (acno = 0, ac = >ac[acno];
acno < WME_NUM_AC; acno++, ac++) {
ac->sched= false;
+ ac->clear_ps_filter = true;
ac->txq = sc->tx.txq_map[acno];
INIT_LIST_HEAD(>tid_q);
}
--
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/
[ 04/28] xen-gnt: prevent adding duplicate gnt callbacks
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Roger Pau Monne
commit 5f338d9001094a56cf87bd8a280b4e7ff953bb59 upstream.
With the current implementation, the callback in the tail of the list
can be added twice, because the check done in
gnttab_request_free_callback is bogus, callback->next can be NULL if
it is the last callback in the list. If we add the same callback twice
we end up with an infinite loop, were callback == callback->next.
Replace this check with a proper one that iterates over the list to
see if the callback has already been added.
Signed-off-by: Roger Pau Monné
Cc: Konrad Rzeszutek Wilk
Cc: David Vrabel
Signed-off-by: Konrad Rzeszutek Wilk
Acked-by: Matt Wilson
Reviewed-by: David Vrabel
Signed-off-by: Greg Kroah-Hartman
---
drivers/xen/grant-table.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -355,9 +355,18 @@ void gnttab_request_free_callback(struct
void (*fn)(void *), void *arg, u16 count)
{
unsigned long flags;
+ struct gnttab_free_callback *cb;
+
spin_lock_irqsave(_list_lock, flags);
- if (callback->next)
- goto out;
+
+ /* Check if the callback is already on the list */
+ cb = gnttab_free_callback_list;
+ while (cb) {
+ if (cb == callback)
+ goto out;
+ cb = cb->next;
+ }
+
callback->fn = fn;
callback->arg = arg;
callback->count = count;
--
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 tip/core/rcu 10/10] sched, rcu: Make RCU use resched_cpu()
From: Peter Zijlstra
We're going to deprecate and remove set_need_resched() for it will do
the wrong thing. Make an exception for RCU and allow it to use
resched_cpu() which will do the right thing.
Signed-off-by: Peter Zijlstra
Signed-off-by: Paul E. McKenney
---
kernel/rcutree.c| 15 ++-
kernel/sched/core.c | 10 ++
2 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/kernel/rcutree.c b/kernel/rcutree.c
index 54dd6d0..bd170f5 100644
--- a/kernel/rcutree.c
+++ b/kernel/rcutree.c
@@ -898,6 +898,12 @@ static void print_other_cpu_stall(struct rcu_state *rsp)
force_quiescent_state(rsp); /* Kick them all. */
}
+/*
+ * This function really isn't for public consumption, but RCU is special in
+ * that context switches can allow the state machine to make progress.
+ */
+extern void resched_cpu(int cpu);
+
static void print_cpu_stall(struct rcu_state *rsp)
{
int cpu;
@@ -927,7 +933,14 @@ static void print_cpu_stall(struct rcu_state *rsp)
3 * rcu_jiffies_till_stall_check() + 3;
raw_spin_unlock_irqrestore(>lock, flags);
- set_need_resched(); /* kick ourselves to get things going. */
+ /*
+* Attempt to revive the RCU machinery by forcing a context switch.
+*
+* A context switch would normally allow the RCU state machine to make
+* progress and it could be we're stuck in kernel space without context
+* switches for an entirely unreasonable amount of time.
+*/
+ resched_cpu(smp_processor_id());
}
static void check_cpu_stall(struct rcu_state *rsp, struct rcu_data *rdp)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 5ac63c9..bd37fcc 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -513,12 +513,11 @@ static inline void init_hrtick(void)
* might also involve a cross-CPU call to trigger the scheduler on
* the target CPU.
*/
-#ifdef CONFIG_SMP
void resched_task(struct task_struct *p)
{
int cpu;
- assert_raw_spin_locked(_rq(p)->lock);
+ lockdep_assert_held(_rq(p)->lock);
if (test_tsk_need_resched(p))
return;
@@ -546,6 +545,7 @@ void resched_cpu(int cpu)
raw_spin_unlock_irqrestore(>lock, flags);
}
+#ifdef CONFIG_SMP
#ifdef CONFIG_NO_HZ_COMMON
/*
* In the semi idle case, use the nearest busy cpu for migrating timers
@@ -693,12 +693,6 @@ void sched_avg_update(struct rq *rq)
}
}
-#else /* !CONFIG_SMP */
-void resched_task(struct task_struct *p)
-{
- assert_raw_spin_locked(_rq(p)->lock);
- set_tsk_need_resched(p);
-}
#endif /* CONFIG_SMP */
#if defined(CONFIG_RT_GROUP_SCHED) || (defined(CONFIG_FAIR_GROUP_SCHED) && \
--
1.8.1.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/
[ 15/28] ALSA: hda - Add Toshiba Satellite C870 to MSI blacklist
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Takashi Iwai
commit 83f72151352791836a1b9c1542614cc9bf71ac61 upstream.
Toshiba Satellite C870 shows interrupt problems occasionally when
certain mixer controls like "Mic Switch" is toggled. This seems
worked around by not using MSI.
Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=833585
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
---
sound/pci/hda/hda_intel.c |1 +
1 file changed, 1 insertion(+)
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2461,6 +2461,7 @@ static struct snd_pci_quirk msi_black_li
SND_PCI_QUIRK(0x1043, 0x81f2, "ASUS", 0), /* Athlon64 X2 + nvidia */
SND_PCI_QUIRK(0x1043, 0x81f6, "ASUS", 0), /* nvidia */
SND_PCI_QUIRK(0x1043, 0x822d, "ASUS", 0), /* Athlon64 X2 + nvidia MCP55
*/
+ SND_PCI_QUIRK(0x1179, 0xfb44, "Toshiba Satellite C870", 0), /* AMD
Hudson */
SND_PCI_QUIRK(0x1849, 0x0888, "ASRock", 0), /* Athlon64 X2 + nvidia */
SND_PCI_QUIRK(0xa0a0, 0x0575, "Aopen MZ915-M", 0), /* ICH6 */
{}
--
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 tip/core/rcu 08/10] rcu: Track rcu_nocb_kthread()'s sleeping and awakening
From: "Paul E. McKenney"
This commit adds event traces to track all of rcu_nocb_kthread()'s
blocking and awakening.
Signed-off-by: Paul E. McKenney
---
include/trace/events/rcu.h | 4
kernel/rcutree_plugin.h| 15 ++-
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/include/trace/events/rcu.h b/include/trace/events/rcu.h
index 4301cd9..a087d82 100644
--- a/include/trace/events/rcu.h
+++ b/include/trace/events/rcu.h
@@ -183,8 +183,12 @@ TRACE_EVENT(rcu_grace_period_init,
* "WakeOvf": Wake rcuo kthread, CB list is huge.
* "WakeNot": Don't wake rcuo kthread.
* "WakeNotPoll": Don't wake rcuo kthread because it is polling.
+ * "Poll": Start of new polling cycle for rcu_nocb_poll.
+ * "Sleep": Sleep waiting for CBs for !rcu_nocb_poll.
* "WokeEmpty": rcuo kthread woke to find empty list.
* "WokeNonEmpty": rcuo kthread woke to find non-empty list.
+ * "WaitQueue": Enqueue partially done, timed wait for it to complete.
+ * "WokeQueue": Partial enqueue now complete.
*/
TRACE_EVENT(rcu_nocb_wake,
diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
index 24b01b6..21205b1 100644
--- a/kernel/rcutree_plugin.h
+++ b/kernel/rcutree_plugin.h
@@ -2230,6 +2230,7 @@ static void rcu_nocb_wait_gp(struct rcu_data *rdp)
static int rcu_nocb_kthread(void *arg)
{
int c, cl;
+ bool firsttime = 1;
struct rcu_head *list;
struct rcu_head *next;
struct rcu_head **tail;
@@ -2238,8 +2239,15 @@ static int rcu_nocb_kthread(void *arg)
/* Each pass through this loop invokes one batch of callbacks */
for (;;) {
/* If not polling, wait for next batch of callbacks. */
- if (!rcu_nocb_poll)
+ if (!rcu_nocb_poll) {
+ trace_rcu_nocb_wake(rdp->rsp->name, rdp->cpu,
+ TPS("Sleep"));
wait_event_interruptible(rdp->nocb_wq, rdp->nocb_head);
+ } else if (firsttime) {
+ firsttime = 0;
+ trace_rcu_nocb_wake(rdp->rsp->name, rdp->cpu,
+ TPS("Poll"));
+ }
list = ACCESS_ONCE(rdp->nocb_head);
if (!list) {
if (!rcu_nocb_poll)
@@ -2249,6 +2257,7 @@ static int rcu_nocb_kthread(void *arg)
flush_signals(current);
continue;
}
+ firsttime = 1;
trace_rcu_nocb_wake(rdp->rsp->name, rdp->cpu,
TPS("WokeNonEmpty"));
@@ -2271,7 +2280,11 @@ static int rcu_nocb_kthread(void *arg)
next = list->next;
/* Wait for enqueuing to complete, if needed. */
while (next == NULL && >next != tail) {
+ trace_rcu_nocb_wake(rdp->rsp->name, rdp->cpu,
+ TPS("WaitQueue"));
schedule_timeout_interruptible(1);
+ trace_rcu_nocb_wake(rdp->rsp->name, rdp->cpu,
+ TPS("WokeQueue"));
next = list->next;
}
debug_rcu_head_unqueue(list);
--
1.8.1.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH tip/core/rcu 03/10] rcu: Flag lockless access to ->gp_flags with ACCESS_ONCE()
From: "Paul E. McKenney"
This commit applies ACCESS_ONCE() to an outside-of-lock access to
->gp_flags. Although it is hard to imagine any sane compiler messing
this particular case up, the documentation benefits are substantial.
Plus the definition of "sane compiler" grows ever looser.
Signed-off-by: Paul E. McKenney
---
kernel/rcutree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/rcutree.c b/kernel/rcutree.c
index 62b67b7..6d028fd 100644
--- a/kernel/rcutree.c
+++ b/kernel/rcutree.c
@@ -1481,7 +1481,7 @@ static int __noreturn rcu_gp_kthread(void *arg)
/* Handle grace-period start. */
for (;;) {
wait_event_interruptible(rsp->gp_wq,
-rsp->gp_flags &
+ACCESS_ONCE(rsp->gp_flags) &
RCU_GP_FLAG_INIT);
if (rcu_gp_init(rsp))
break;
--
1.8.1.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH tip/core/rcu 09/10] rcu: Avoid sparse warnings in rcu_nocb_wake trace event
From: "Paul E. McKenney"
The event-tracing macros do not like bool tracing arguments, so this
commit makes them be of type char. This change has the knock-on effect
of making it illegal to pass a pointer into one of these arguments, so
also change rcutiny's first call to trace_rcu_batch_end() to convert
from pointer to boolean, prefixing with "!!".
Reported-by: kbuild test robot
Signed-off-by: Paul E. McKenney
---
include/trace/events/rcu.h | 10 +-
kernel/rcutiny.c | 2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/trace/events/rcu.h b/include/trace/events/rcu.h
index a087d82..aca3822 100644
--- a/include/trace/events/rcu.h
+++ b/include/trace/events/rcu.h
@@ -591,17 +591,17 @@ TRACE_EVENT(rcu_invoke_kfree_callback,
TRACE_EVENT(rcu_batch_end,
TP_PROTO(const char *rcuname, int callbacks_invoked,
-bool cb, bool nr, bool iit, bool risk),
+char cb, char nr, char iit, char risk),
TP_ARGS(rcuname, callbacks_invoked, cb, nr, iit, risk),
TP_STRUCT__entry(
__field(const char *, rcuname)
__field(int, callbacks_invoked)
- __field(bool, cb)
- __field(bool, nr)
- __field(bool, iit)
- __field(bool, risk)
+ __field(char, cb)
+ __field(char, nr)
+ __field(char, iit)
+ __field(char, risk)
),
TP_fast_assign(
diff --git a/kernel/rcutiny.c b/kernel/rcutiny.c
index 9ed6075..80b6e27 100644
--- a/kernel/rcutiny.c
+++ b/kernel/rcutiny.c
@@ -273,7 +273,7 @@ static void __rcu_process_callbacks(struct rcu_ctrlblk *rcp)
if (>rcucblist == rcp->donetail) {
RCU_TRACE(trace_rcu_batch_start(rcp->name, 0, 0, -1));
RCU_TRACE(trace_rcu_batch_end(rcp->name, 0,
- ACCESS_ONCE(rcp->rcucblist),
+ !!ACCESS_ONCE(rcp->rcucblist),
need_resched(),
is_idle_task(current),
false));
--
1.8.1.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH tip/core/rcu 07/10] rcu: Distinguish between NOCB and non-NOCB rcu_callback trace events
From: "Paul E. McKenney" One way to distinguish between NOCB and non-NOCB rcu_callback trace events is that the former always print zero for the lazy and non-lazy queue lengths. Unfortunately, this also means that we cannot see the NOCB queue lengths. This commit therefore accesses the NOCB queue lengths, but negates them. NOCB rcu_callback trace events should therefore have negative queue lengths. Signed-off-by: Paul E. McKenney [ paulmck: Match operand size per kbuild test robot's advice. ] --- kernel/rcutree_plugin.h | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h index f4ed24b..24b01b6 100644 --- a/kernel/rcutree_plugin.h +++ b/kernel/rcutree_plugin.h @@ -2147,10 +2147,12 @@ static bool __call_rcu_nocb(struct rcu_data *rdp, struct rcu_head *rhp, if (__is_kfree_rcu_offset((unsigned long)rhp->func)) trace_rcu_kfree_callback(rdp->rsp->name, rhp, (unsigned long)rhp->func, -rdp->qlen_lazy, rdp->qlen); + -atomic_long_read(>nocb_q_count_lazy), +-atomic_long_read(>nocb_q_count)); else trace_rcu_callback(rdp->rsp->name, rhp, - rdp->qlen_lazy, rdp->qlen); + -atomic_long_read(>nocb_q_count_lazy), + -atomic_long_read(>nocb_q_count)); return 1; } -- 1.8.1.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH tip/core/rcu 05/10] rcu: Add tracing of normal (non-NOCB) grace-period requests
From: "Paul E. McKenney"
This commit adds tracing to the normal grace-period request points.
These are rcu_gp_cleanup(), which checks for the need for another
grace period at the end of the previous grace period, and
rcu_start_gp_advanced(), which restarts RCU's state machine after
an idle period. These trace events are intended to help track down
bugs where RCU remains idle despite there being work for it to do.
Reported-by: Clark Williams
Signed-off-by: Paul E. McKenney
---
include/trace/events/rcu.h | 1 +
kernel/rcutree.c | 8 +++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/include/trace/events/rcu.h b/include/trace/events/rcu.h
index 60077e1..98466c6 100644
--- a/include/trace/events/rcu.h
+++ b/include/trace/events/rcu.h
@@ -45,6 +45,7 @@ TRACE_EVENT(rcu_utilization,
*
* "AccReadyCB": CPU acclerates new callbacks to RCU_NEXT_READY_TAIL.
* "AccWaitCB": CPU accelerates new callbacks to RCU_WAIT_TAIL.
+ * "newreq": Request a new grace period.
* "start": Start a grace period.
* "cpustart": CPU first notices a grace-period start.
* "cpuqs": CPU passes through a quiescent state.
diff --git a/kernel/rcutree.c b/kernel/rcutree.c
index 78d3715..54dd6d0 100644
--- a/kernel/rcutree.c
+++ b/kernel/rcutree.c
@@ -1459,8 +1459,12 @@ static void rcu_gp_cleanup(struct rcu_state *rsp)
rsp->fqs_state = RCU_GP_IDLE;
rdp = this_cpu_ptr(rsp->rda);
rcu_advance_cbs(rsp, rnp, rdp); /* Reduce false positives below. */
- if (cpu_needs_another_gp(rsp, rdp))
+ if (cpu_needs_another_gp(rsp, rdp)) {
rsp->gp_flags = 1;
+ trace_rcu_grace_period(rsp->name,
+ ACCESS_ONCE(rsp->gpnum),
+ TPS("newreq"));
+ }
raw_spin_unlock_irq(>lock);
}
@@ -1584,6 +1588,8 @@ rcu_start_gp_advanced(struct rcu_state *rsp, struct
rcu_node *rnp,
return;
}
rsp->gp_flags = RCU_GP_FLAG_INIT;
+ trace_rcu_grace_period(rsp->name, ACCESS_ONCE(rsp->gpnum),
+ TPS("newreq"));
/*
* We can't do wakeups while holding the rnp->lock, as that
--
1.8.1.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH tip/core/rcu 01/10] rcu: Improve grace-period start logic
From: "Paul E. McKenney"
This commit improves grace-period start logic by checking ->gp_flags
under the lock and by issuing a warning if a grace period is already
in progress.
Signed-off-by: Paul E. McKenney
---
kernel/rcutree.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/kernel/rcutree.c b/kernel/rcutree.c
index 32618b3..d679a52 100644
--- a/kernel/rcutree.c
+++ b/kernel/rcutree.c
@@ -1297,7 +1297,7 @@ static void note_gp_changes(struct rcu_state *rsp, struct
rcu_data *rdp)
}
/*
- * Initialize a new grace period.
+ * Initialize a new grace period. Return 0 if no grace period required.
*/
static int rcu_gp_init(struct rcu_state *rsp)
{
@@ -1306,10 +1306,18 @@ static int rcu_gp_init(struct rcu_state *rsp)
rcu_bind_gp_kthread();
raw_spin_lock_irq(>lock);
+ if (rsp->gp_flags == 0) {
+ /* Spurious wakeup, tell caller to go back to sleep. */
+ raw_spin_unlock_irq(>lock);
+ return 0;
+ }
rsp->gp_flags = 0; /* Clear all flags: New grace period. */
- if (rcu_gp_in_progress(rsp)) {
- /* Grace period already in progress, don't start another. */
+ if (WARN_ON_ONCE(rcu_gp_in_progress(rsp))) {
+ /*
+* Grace period already in progress, don't start another.
+* Not supposed to be able to happen.
+*/
raw_spin_unlock_irq(>lock);
return 0;
}
@@ -1474,8 +1482,7 @@ static int __noreturn rcu_gp_kthread(void *arg)
wait_event_interruptible(rsp->gp_wq,
rsp->gp_flags &
RCU_GP_FLAG_INIT);
- if ((rsp->gp_flags & RCU_GP_FLAG_INIT) &&
- rcu_gp_init(rsp))
+ if (rcu_gp_init(rsp))
break;
cond_resched();
flush_signals(current);
--
1.8.1.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH tip/core/rcu 04/10] rcu: Add tracing to rcu_gp_kthread()
From: "Paul E. McKenney"
This commit adds tracing to the rcu_gp_kthread() function in order to
help trace down hangs potentially involving this kthread.
Reported-by: Clark Williams
Reported-by: Carsten Emde
Signed-off-by: Paul E. McKenney
---
include/trace/events/rcu.h | 28 +++-
kernel/rcutree.c | 18 ++
2 files changed, 37 insertions(+), 9 deletions(-)
diff --git a/include/trace/events/rcu.h b/include/trace/events/rcu.h
index ee2376c..60077e1 100644
--- a/include/trace/events/rcu.h
+++ b/include/trace/events/rcu.h
@@ -39,15 +39,25 @@ TRACE_EVENT(rcu_utilization,
#if defined(CONFIG_TREE_RCU) || defined(CONFIG_TREE_PREEMPT_RCU)
/*
- * Tracepoint for grace-period events: starting and ending a grace
- * period ("start" and "end", respectively), a CPU noting the start
- * of a new grace period or the end of an old grace period ("cpustart"
- * and "cpuend", respectively), a CPU passing through a quiescent
- * state ("cpuqs"), a CPU coming online or going offline ("cpuonl"
- * and "cpuofl", respectively), a CPU being kicked for being too
- * long in dyntick-idle mode ("kick"), a CPU accelerating its new
- * callbacks to RCU_NEXT_READY_TAIL ("AccReadyCB"), and a CPU
- * accelerating its new callbacks to RCU_WAIT_TAIL ("AccWaitCB").
+ * Tracepoint for grace-period events. Takes a string identifying the
+ * RCU flavor, the grace-period number, and a string identifying the
+ * grace-period-related event as follows:
+ *
+ * "AccReadyCB": CPU acclerates new callbacks to RCU_NEXT_READY_TAIL.
+ * "AccWaitCB": CPU accelerates new callbacks to RCU_WAIT_TAIL.
+ * "start": Start a grace period.
+ * "cpustart": CPU first notices a grace-period start.
+ * "cpuqs": CPU passes through a quiescent state.
+ * "cpuonl": CPU comes online.
+ * "cpuofl": CPU goes offline.
+ * "reqwait": GP kthread sleeps waiting for grace-period request.
+ * "reqwaitsig": GP kthread awakened by signal from reqwait state.
+ * "fqswait": GP kthread waiting until time to force quiescent states.
+ * "fqsstart": GP kthread starts forcing quiescent states.
+ * "fqsend": GP kthread done forcing quiescent states.
+ * "fqswaitsig": GP kthread awakened by signal from fqswait state.
+ * "end": End a grace period.
+ * "cpuend": CPU first notices a grace-period end.
*/
TRACE_EVENT(rcu_grace_period,
diff --git a/kernel/rcutree.c b/kernel/rcutree.c
index 6d028fd..78d3715 100644
--- a/kernel/rcutree.c
+++ b/kernel/rcutree.c
@@ -1480,6 +1480,9 @@ static int __noreturn rcu_gp_kthread(void *arg)
/* Handle grace-period start. */
for (;;) {
+ trace_rcu_grace_period(rsp->name,
+ ACCESS_ONCE(rsp->gpnum),
+ TPS("reqwait"));
wait_event_interruptible(rsp->gp_wq,
ACCESS_ONCE(rsp->gp_flags) &
RCU_GP_FLAG_INIT);
@@ -1487,6 +1490,9 @@ static int __noreturn rcu_gp_kthread(void *arg)
break;
cond_resched();
flush_signals(current);
+ trace_rcu_grace_period(rsp->name,
+ ACCESS_ONCE(rsp->gpnum),
+ TPS("reqwaitsig"));
}
/* Handle quiescent-state forcing. */
@@ -1500,6 +1506,9 @@ static int __noreturn rcu_gp_kthread(void *arg)
for (;;) {
if (!ret)
rsp->jiffies_force_qs = jiffies + j;
+ trace_rcu_grace_period(rsp->name,
+ ACCESS_ONCE(rsp->gpnum),
+ TPS("fqswait"));
ret = wait_event_interruptible_timeout(rsp->gp_wq,
((gf = ACCESS_ONCE(rsp->gp_flags)) &
RCU_GP_FLAG_FQS) ||
@@ -1513,12 +1522,21 @@ static int __noreturn rcu_gp_kthread(void *arg)
/* If time for quiescent-state forcing, do it. */
if (ULONG_CMP_GE(jiffies, rsp->jiffies_force_qs) ||
(gf & RCU_GP_FLAG_FQS)) {
+ trace_rcu_grace_period(rsp->name,
+ ACCESS_ONCE(rsp->gpnum),
+ TPS("fqsstart"));
fqs_state = rcu_gp_fqs(rsp, fqs_state);
+ trace_rcu_grace_period(rsp->name,
+ ACCESS_ONCE(rsp->gpnum),
+ TPS("fqsend"));
cond_resched();
[PATCH tip/core/rcu 02/10] rcu: Prevent spurious-wakeup DoS attack on rcu_gp_kthread()
From: "Paul E. McKenney"
Spurious wakeups in the force-quiescent-state loop in rcu_gp_kthread()
cause the timeout to be recalculated, which would prevent rcu_gp_fqs()
from ever being called. This would in turn would prevent the grace period
from ever ending for as long as there was at least one CPU in an extended
quiescent state that had not yet passed through a quiescent state.
This commit therefore avoids recalculating the timeout unless the
previous pass's call to wait_event_interruptible_timeout() actually
did time out, thus preventing the above scenario.
Signed-off-by: Paul E. McKenney
---
kernel/rcutree.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/kernel/rcutree.c b/kernel/rcutree.c
index d679a52..62b67b7 100644
--- a/kernel/rcutree.c
+++ b/kernel/rcutree.c
@@ -1470,6 +1470,7 @@ static void rcu_gp_cleanup(struct rcu_state *rsp)
static int __noreturn rcu_gp_kthread(void *arg)
{
int fqs_state;
+ int gf;
unsigned long j;
int ret;
struct rcu_state *rsp = arg;
@@ -1495,10 +1496,13 @@ static int __noreturn rcu_gp_kthread(void *arg)
j = HZ;
jiffies_till_first_fqs = HZ;
}
+ ret = 0;
for (;;) {
- rsp->jiffies_force_qs = jiffies + j;
+ if (!ret)
+ rsp->jiffies_force_qs = jiffies + j;
ret = wait_event_interruptible_timeout(rsp->gp_wq,
- (rsp->gp_flags & RCU_GP_FLAG_FQS) ||
+ ((gf = ACCESS_ONCE(rsp->gp_flags)) &
+RCU_GP_FLAG_FQS) ||
(!ACCESS_ONCE(rnp->qsmask) &&
!rcu_preempt_blocked_readers_cgp(rnp)),
j);
@@ -1507,7 +1511,8 @@ static int __noreturn rcu_gp_kthread(void *arg)
!rcu_preempt_blocked_readers_cgp(rnp))
break;
/* If time for quiescent-state forcing, do it. */
- if (ret == 0 || (rsp->gp_flags & RCU_GP_FLAG_FQS)) {
+ if (ULONG_CMP_GE(jiffies, rsp->jiffies_force_qs) ||
+ (gf & RCU_GP_FLAG_FQS)) {
fqs_state = rcu_gp_fqs(rsp, fqs_state);
cond_resched();
} else {
--
1.8.1.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH tip/core/rcu 0/10] Grace-period-related changes for 3.13
Hello! This series contains updates to RCU's grace-period processsing, mostly to improve debuggability of RCU itself. 1. Add consistency checks to the grace-period initialization logic. 2. Prevent spurious-wakeup DoS attack on rcu_gp_kthread. 3. Flag lockless accesses to ->gp_flags with ACCESS_ONCE(). 4-6.Add event tracing to various aspects of RCU grace period processing. 7. Distinguish between NOCB and non-NOCB rcu_callback trace events. 8. Add event tracing to track rcu_nocb_kthread() sleeping and awakening. 9. Avoid sparse warnings in rcu_nocb_wake trace event. 10. Make RCU use resched_cpu() instead of the current set_need_resched(), courtesy of Peter Zijlstra. Thanx, Paul b/include/trace/events/rcu.h | 80 +++ b/kernel/rcutiny.c |2 - b/kernel/rcutree.c | 71 -- b/kernel/rcutree_plugin.h| 35 -- b/kernel/sched/core.c| 10 + 5 files changed, 160 insertions(+), 38 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 28/28] fuse: invalidate inode attributes on xattr modification
3.0-stable review patch. If anyone has any objections, please let me know. -- From: Anand Avati commit d331a415aef98717393dda0be69b7947da08eba3 upstream. Calls like setxattr and removexattr result in updation of ctime. Therefore invalidate inode attributes to force a refresh. Signed-off-by: Anand Avati Reviewed-by: Brian Foster Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman --- fs/fuse/dir.c |4 1 file changed, 4 insertions(+) --- a/fs/fuse/dir.c +++ b/fs/fuse/dir.c @@ -1439,6 +1439,8 @@ static int fuse_setxattr(struct dentry * fc->no_setxattr = 1; err = -EOPNOTSUPP; } + if (!err) + fuse_invalidate_attr(inode); return err; } @@ -1568,6 +1570,8 @@ static int fuse_removexattr(struct dentr fc->no_removexattr = 1; err = -EOPNOTSUPP; } + if (!err) + fuse_invalidate_attr(inode); return err; } -- 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 tip/core/rcu 06/10] rcu: Add tracing for rcuo no-CBs CPU wakeup handshake
From: "Paul E. McKenney"
Lost wakeups from call_rcu() to the rcuo kthreads can result in hangs
that are difficult to diagnose. This commit therefore adds tracing to
help pin down the cause of these hangs.
Reported-by: Clark Williams
Reported-by: Carsten Emde
Signed-off-by: Paul E. McKenney
[ paulmck: Add const per kbuild test robot's advice. ]
---
include/trace/events/rcu.h | 37 +
kernel/rcutree_plugin.h| 14 +-
2 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/include/trace/events/rcu.h b/include/trace/events/rcu.h
index 98466c6..4301cd9 100644
--- a/include/trace/events/rcu.h
+++ b/include/trace/events/rcu.h
@@ -172,6 +172,42 @@ TRACE_EVENT(rcu_grace_period_init,
);
/*
+ * Tracepoint for RCU no-CBs CPU callback handoffs. This event is intended
+ * to assist debugging of these handoffs.
+ *
+ * The first argument is the name of the RCU flavor, and the second is
+ * the number of the offloaded CPU are extracted. The third and final
+ * argument is a string as follows:
+ *
+ * "WakeEmpty": Wake rcuo kthread, first CB to empty list.
+ * "WakeOvf": Wake rcuo kthread, CB list is huge.
+ * "WakeNot": Don't wake rcuo kthread.
+ * "WakeNotPoll": Don't wake rcuo kthread because it is polling.
+ * "WokeEmpty": rcuo kthread woke to find empty list.
+ * "WokeNonEmpty": rcuo kthread woke to find non-empty list.
+ */
+TRACE_EVENT(rcu_nocb_wake,
+
+ TP_PROTO(const char *rcuname, int cpu, const char *reason),
+
+ TP_ARGS(rcuname, cpu, reason),
+
+ TP_STRUCT__entry(
+ __field(const char *, rcuname)
+ __field(int, cpu)
+ __field(const char *, reason)
+ ),
+
+ TP_fast_assign(
+ __entry->rcuname = rcuname;
+ __entry->cpu = cpu;
+ __entry->reason = reason;
+ ),
+
+ TP_printk("%s %d %s", __entry->rcuname, __entry->cpu, __entry->reason)
+);
+
+/*
* Tracepoint for tasks blocking within preemptible-RCU read-side
* critical sections. Track the type of RCU (which one day might
* include SRCU), the grace-period number that the task is blocking
@@ -667,6 +703,7 @@ TRACE_EVENT(rcu_barrier,
#define trace_rcu_future_grace_period(rcuname, gpnum, completed, c, \
level, grplo, grphi, event) \
do { } while (0)
+#define trace_rcu_nocb_wake(rcuname, cpu, reason) do { } while (0)
#define trace_rcu_preempt_task(rcuname, pid, gpnum) do { } while (0)
#define trace_rcu_unlock_preempted_task(rcuname, gpnum, pid) do { } while (0)
#define trace_rcu_quiescent_state_report(rcuname, gpnum, mask, qsmask, level, \
diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
index 130c97b..f4ed24b 100644
--- a/kernel/rcutree_plugin.h
+++ b/kernel/rcutree_plugin.h
@@ -2108,15 +2108,22 @@ static void __call_rcu_nocb_enqueue(struct rcu_data
*rdp,
/* If we are not being polled and there is a kthread, awaken it ... */
t = ACCESS_ONCE(rdp->nocb_kthread);
- if (rcu_nocb_poll | !t)
+ if (rcu_nocb_poll | !t) {
+ trace_rcu_nocb_wake(rdp->rsp->name, rdp->cpu,
+ TPS("WakeNotPoll"));
return;
+ }
len = atomic_long_read(>nocb_q_count);
if (old_rhpp == >nocb_head) {
wake_up(>nocb_wq); /* ... only if queue was empty ... */
rdp->qlen_last_fqs_check = 0;
+ trace_rcu_nocb_wake(rdp->rsp->name, rdp->cpu, TPS("WakeEmpty"));
} else if (len > rdp->qlen_last_fqs_check + qhimark) {
wake_up_process(t); /* ... or if many callbacks queued. */
rdp->qlen_last_fqs_check = LONG_MAX / 2;
+ trace_rcu_nocb_wake(rdp->rsp->name, rdp->cpu, TPS("WakeOvf"));
+ } else {
+ trace_rcu_nocb_wake(rdp->rsp->name, rdp->cpu, TPS("WakeNot"));
}
return;
}
@@ -2233,10 +2240,15 @@ static int rcu_nocb_kthread(void *arg)
wait_event_interruptible(rdp->nocb_wq, rdp->nocb_head);
list = ACCESS_ONCE(rdp->nocb_head);
if (!list) {
+ if (!rcu_nocb_poll)
+ trace_rcu_nocb_wake(rdp->rsp->name, rdp->cpu,
+ TPS("WokeEmpty"));
schedule_timeout_interruptible(1);
flush_signals(current);
continue;
}
+ trace_rcu_nocb_wake(rdp->rsp->name, rdp->cpu,
+ TPS("WokeNonEmpty"));
/*
* Extract queued callbacks, update counts, and wait
--
1.8.1.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
[ 27/28] fuse: postpone end_page_writeback() in fuse_writepage_locked()
3.0-stable review patch. If anyone has any objections, please let me know. -- From: Maxim Patlasov commit 4a4ac4eba1010ef9a804569058ab29e3450c0315 upstream. The patch fixes a race between ftruncate(2), mmap-ed write and write(2): 1) An user makes a page dirty via mmap-ed write. 2) The user performs shrinking truncate(2) intended to purge the page. 3) Before fuse_do_setattr calls truncate_pagecache, the page goes to writeback. fuse_writepage_locked fills FUSE_WRITE request and releases the original page by end_page_writeback. 4) fuse_do_setattr() completes and successfully returns. Since now, i_mutex is free. 5) Ordinary write(2) extends i_size back to cover the page. Note that fuse_send_write_pages do wait for fuse writeback, but for another page->index. 6) fuse_writepage_locked proceeds by queueing FUSE_WRITE request. fuse_send_writepage is supposed to crop inarg->size of the request, but it doesn't because i_size has already been extended back. Moving end_page_writeback to the end of fuse_writepage_locked fixes the race because now the fact that truncate_pagecache is successfully returned infers that fuse_writepage_locked has already called end_page_writeback. And this, in turn, infers that fuse_flush_writepages has already called fuse_send_writepage, and the latter used valid (shrunk) i_size. write(2) could not extend it because of i_mutex held by ftruncate(2). Signed-off-by: Maxim Patlasov Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman --- fs/fuse/file.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/fs/fuse/file.c +++ b/fs/fuse/file.c @@ -1298,7 +1298,6 @@ static int fuse_writepage_locked(struct inc_bdi_stat(mapping->backing_dev_info, BDI_WRITEBACK); inc_zone_page_state(tmp_page, NR_WRITEBACK_TEMP); - end_page_writeback(page); spin_lock(>lock); list_add(>writepages_entry, >writepages); @@ -1306,6 +1305,8 @@ static int fuse_writepage_locked(struct fuse_flush_writepages(inode); spin_unlock(>lock); + end_page_writeback(page); + return 0; err_free: -- 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/
[ 06/28] usb: xhci: Disable runtime PM suspend for quirky controllers
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Shawn Nematbakhsh
commit c8476fb855434c733099079063990e5bfa7ecad6 upstream.
If a USB controller with XHCI_RESET_ON_RESUME goes to runtime suspend,
a reset will be performed upon runtime resume. Any previously suspended
devices attached to the controller will be re-enumerated at this time.
This will cause problems, for example, if an open system call on the
device triggered the resume (the open call will fail).
Note that this change is only relevant when persist_enabled is not set
for USB devices.
This patch should be backported to kernels as old as 3.0, that
contain the commit c877b3b2ad5cb9d4fe523c5496185cc328ff3ae9 "xhci: Add
reset on resume quirk for asrock p67 host".
Signed-off-by: Shawn Nematbakhsh
Signed-off-by: Sarah Sharp
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/host/xhci.c | 22 ++
1 file changed, 22 insertions(+)
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -2713,10 +2713,21 @@ void xhci_free_dev(struct usb_hcd *hcd,
{
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct xhci_virt_device *virt_dev;
+ struct device *dev = hcd->self.controller;
unsigned long flags;
u32 state;
int i, ret;
+#ifndef CONFIG_USB_DEFAULT_PERSIST
+ /*
+* We called pm_runtime_get_noresume when the device was attached.
+* Decrement the counter here to allow controller to runtime suspend
+* if no devices remain.
+*/
+ if (xhci->quirks & XHCI_RESET_ON_RESUME)
+ pm_runtime_put_noidle(dev);
+#endif
+
ret = xhci_check_args(hcd, udev, NULL, 0, true, __func__);
/* If the host is halted due to driver unload, we still need to free the
* device.
@@ -2783,6 +2794,7 @@ static int xhci_reserve_host_control_ep_
int xhci_alloc_dev(struct usb_hcd *hcd, struct usb_device *udev)
{
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+ struct device *dev = hcd->self.controller;
unsigned long flags;
int timeleft;
int ret;
@@ -2835,6 +2847,16 @@ int xhci_alloc_dev(struct usb_hcd *hcd,
goto disable_slot;
}
udev->slot_id = xhci->slot_id;
+
+#ifndef CONFIG_USB_DEFAULT_PERSIST
+ /*
+* If resetting upon resume, we can't put the controller into runtime
+* suspend if there is a device attached.
+*/
+ if (xhci->quirks & XHCI_RESET_ON_RESUME)
+ pm_runtime_get_noresume(dev);
+#endif
+
/* Is this a LS or FS device under a HS hub? */
/* Hub or peripherial? */
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/
[ 24/28] mm/huge_memory.c: fix potential NULL pointer dereference
3.0-stable review patch. If anyone has any objections, please let me know. -- From: Libin commit a8f531ebc33052642b4bd7b812eedf397108ce64 upstream. In collapse_huge_page() there is a race window between releasing the mmap_sem read lock and taking the mmap_sem write lock, so find_vma() may return NULL. So check the return value to avoid NULL pointer dereference. collapse_huge_page khugepaged_alloc_page up_read(>mmap_sem) down_write(>mmap_sem) vma = find_vma(mm, address) Signed-off-by: Libin Acked-by: Kirill A. Shutemov Reviewed-by: Wanpeng Li Reviewed-by: Michal Hocko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- mm/huge_memory.c |2 ++ 1 file changed, 2 insertions(+) --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -1838,6 +1838,8 @@ static void collapse_huge_page(struct mm goto out; vma = find_vma(mm, address); + if (!vma) + goto out; hstart = (vma->vm_start + ~HPAGE_PMD_MASK) & HPAGE_PMD_MASK; hend = vma->vm_end & HPAGE_PMD_MASK; if (address < hstart || address + HPAGE_PMD_SIZE > hend) -- 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/
[ 08/28] staging: comedi: dt282x: dt282x_ai_insn_read() always fails
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Dan Carpenter
commit 2c4283ca7cdcc6605859c836fc536fcd83a4525f upstream.
In dt282x_ai_insn_read() we call this macro like:
wait_for(!mux_busy(), comedi_error(dev, "timeout\n"); return -ETIME;);
Because the if statement doesn't have curly braces it means we always
return -ETIME and the function never succeeds.
Signed-off-by: Dan Carpenter
Acked-by: Ian Abbott
Signed-off-by: Greg Kroah-Hartman
---
drivers/staging/comedi/drivers/dt282x.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/staging/comedi/drivers/dt282x.c
+++ b/drivers/staging/comedi/drivers/dt282x.c
@@ -406,8 +406,9 @@ struct dt282x_private {
} \
udelay(5); \
} \
- if (_i) \
+ if (_i) { \
b \
+ } \
} while (0)
static int dt282x_attach(struct comedi_device *dev,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 06/40] xhci-plat: Dont enable legacy PCI interrupts.
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Sarah Sharp
commit 52fb61250a7a132b0cfb9f4a1060a1f3c49e5a25 upstream.
The xHCI platform driver calls into usb_add_hcd to register the irq for
its platform device. It does not want the xHCI generic driver to
register an interrupt for it at all. The original code did that by
setting the XHCI_BROKEN_MSI quirk, which tells the xHCI driver to not
enable MSI or MSI-X for a PCI host.
Unfortunately, if CONFIG_PCI is enabled, and CONFIG_USB_DW3 is enabled,
the xHCI generic driver will attempt to register a legacy PCI interrupt
for the xHCI platform device in xhci_try_enable_msi(). This will result
in a bogus irq being registered, since the underlying device is a
platform_device, not a pci_device, and thus the pci_device->irq pointer
will be bogus.
Add a new quirk, XHCI_PLAT, so that the xHCI generic driver can
distinguish between a PCI device that can't handle MSI or MSI-X, and a
platform device that should not have its interrupts touched at all.
This quirk may be useful in the future, in case other corner cases like
this arise.
This patch should be backported to kernels as old as 3.9, that
contain the commit 00eed9c814cb8f281be6f0f5d8f45025dc0a97eb "USB: xhci:
correctly enable interrupts".
Signed-off-by: Sarah Sharp
Reported-by: Yu Y Wang
Tested-by: Yu Y Wang
Reviewed-by: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/host/xhci-plat.c |2 +-
drivers/usb/host/xhci.c |7 ++-
drivers/usb/host/xhci.h |1 +
3 files changed, 8 insertions(+), 2 deletions(-)
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -24,7 +24,7 @@ static void xhci_plat_quirks(struct devi
* here that the generic code does not try to make a pci_dev from our
* dev struct in order to setup MSI
*/
- xhci->quirks |= XHCI_BROKEN_MSI;
+ xhci->quirks |= XHCI_PLAT;
}
/* called during probe() after chip reset completes */
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -342,9 +342,14 @@ static void xhci_msix_sync_irqs(struct x
static int xhci_try_enable_msi(struct usb_hcd *hcd)
{
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
- struct pci_dev *pdev = to_pci_dev(xhci_to_hcd(xhci)->self.controller);
+ struct pci_dev *pdev;
int ret;
+ /* The xhci platform device has set up IRQs through usb_add_hcd. */
+ if (xhci->quirks & XHCI_PLAT)
+ return 0;
+
+ pdev = to_pci_dev(xhci_to_hcd(xhci)->self.controller);
/*
* Some Fresco Logic host controllers advertise MSI, but fail to
* generate interrupts. Don't even try to enable MSI.
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1508,6 +1508,7 @@ struct xhci_hcd {
#define XHCI_SPURIOUS_REBOOT (1 << 13)
#define XHCI_COMP_MODE_QUIRK (1 << 14)
#define XHCI_AVOID_BEI (1 << 15)
+#define XHCI_PLAT (1 << 16)
unsigned intnum_active_eps;
unsigned intlimit_active_eps;
/* There are two roothubs to keep track of bus suspend info for */
--
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: Copy on write hard links?
On Tue, Sep 24, 2013 at 08:36:56PM +0200, Thomas Meyer wrote: > Is there such a thing? In mainline, AFAIK no. The vserver patchset, on the other hand, adds a new xattr, iunlink, that copies the whole file when needed. That works on most filesystems. That's quite a hack, though, and I think you'd be better off using btrfs which does cow transparently at a lower level than hardlinks. -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- 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/
[ 07/40] usb: xhci: Disable runtime PM suspend for quirky controllers
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Shawn Nematbakhsh
commit c8476fb855434c733099079063990e5bfa7ecad6 upstream.
If a USB controller with XHCI_RESET_ON_RESUME goes to runtime suspend,
a reset will be performed upon runtime resume. Any previously suspended
devices attached to the controller will be re-enumerated at this time.
This will cause problems, for example, if an open system call on the
device triggered the resume (the open call will fail).
Note that this change is only relevant when persist_enabled is not set
for USB devices.
This patch should be backported to kernels as old as 3.0, that
contain the commit c877b3b2ad5cb9d4fe523c5496185cc328ff3ae9 "xhci: Add
reset on resume quirk for asrock p67 host".
Signed-off-by: Shawn Nematbakhsh
Signed-off-by: Sarah Sharp
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/host/xhci.c | 22 ++
1 file changed, 22 insertions(+)
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3501,10 +3501,21 @@ void xhci_free_dev(struct usb_hcd *hcd,
{
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct xhci_virt_device *virt_dev;
+ struct device *dev = hcd->self.controller;
unsigned long flags;
u32 state;
int i, ret;
+#ifndef CONFIG_USB_DEFAULT_PERSIST
+ /*
+* We called pm_runtime_get_noresume when the device was attached.
+* Decrement the counter here to allow controller to runtime suspend
+* if no devices remain.
+*/
+ if (xhci->quirks & XHCI_RESET_ON_RESUME)
+ pm_runtime_put_noidle(dev);
+#endif
+
ret = xhci_check_args(hcd, udev, NULL, 0, true, __func__);
/* If the host is halted due to driver unload, we still need to free the
* device.
@@ -3576,6 +3587,7 @@ static int xhci_reserve_host_control_ep_
int xhci_alloc_dev(struct usb_hcd *hcd, struct usb_device *udev)
{
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+ struct device *dev = hcd->self.controller;
unsigned long flags;
int timeleft;
int ret;
@@ -3628,6 +3640,16 @@ int xhci_alloc_dev(struct usb_hcd *hcd,
goto disable_slot;
}
udev->slot_id = xhci->slot_id;
+
+#ifndef CONFIG_USB_DEFAULT_PERSIST
+ /*
+* If resetting upon resume, we can't put the controller into runtime
+* suspend if there is a device attached.
+*/
+ if (xhci->quirks & XHCI_RESET_ON_RESUME)
+ pm_runtime_get_noresume(dev);
+#endif
+
/* Is this a LS or FS device under a HS hub? */
/* Hub or peripherial? */
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/
