Re: [PATCH 1/2] mfd: ti_am335x_tscadc: Fix idle timeout value
On Tue, 10 Sep 2013, Matthias Kaehlcke wrote: > The old timeout value was based on the assumption that the minimum values are > used for the open and sample delay and no averaging is done. In fact the ADC > and touchscreen driver both use an open delay of 152 cycles and averaging over > 16 samples. This patch adjusts the timeout value accordingly > > Signed-off-by: Matthias Kaehlcke > --- > include/linux/mfd/ti_am335x_tscadc.h | 19 --- > 1 file changed, 12 insertions(+), 7 deletions(-) > > diff --git a/include/linux/mfd/ti_am335x_tscadc.h > b/include/linux/mfd/ti_am335x_tscadc.h > index db1791b..9e6a775 100644 > --- a/include/linux/mfd/ti_am335x_tscadc.h > +++ b/include/linux/mfd/ti_am335x_tscadc.h > @@ -126,13 +126,18 @@ > #define TOTAL_CHANNELS 8 > > /* > -* ADC runs at 3MHz, and it takes > -* 15 cycles to latch one data output. > -* Hence the idle time for ADC to > -* process one sample data would be > -* around 5 micro seconds. > -*/ > -#define IDLE_TIMEOUT 5 /* microsec */ > + * time in us for processing a single channel, calculated as follows: > + * > + * num cycles = open delay + (sample delay + conv time) * averaging > + * > + * num cycles: 152 + (1 + 13) * 16 = 376 > + * > + * clock frequency: 26MHz / 8 = 3.25MHz > + * clock period: 1 / 3.25MHz = 308ns > + * > + * processing time: 376 * 308ns = 116us > + */ > +#define IDLE_TIMEOUT 116 /* microsec */ Nice, clear explanation. I like it. Patch applied, thanks. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs
Am 10.09.2013 17:00, schrieb Joel Fernandes: I think your initial patch is much better than fixing up DT but then I may be missing other problems with your patch that Linus's patch addresses. The initial patch had the problem that it not only did introduce irq-mappings for only those gpios which are marked as IRQs, but it requested those gpios too and preconfigured them And that breaks every driver which uses gpios for IRQs. To summarize what happens if a driver uses a gpio as irq: gpio_request() // This works only if the gpio was not requested before gpio_direction_input() gpio_to_irq() // This needs an irq-mapping request_threaded_irq() So I would suggest multiple steps to change that: 1. Create a mapping for every gpio found in DT (or all gpios if no DT is used). I think that is what Linus patch does (sorry, I haven't really followed this thread and didn't look in deep at the patch). 2. Implement gpio_request_for_irq() This would just be a small macro for gpio_request(); gpio_direction_input() 3. Change all drivers which do use gpio_to_irq() to use gpio_request_for_irq() instead of gpio_request() and gpio_direction_input(). This will end up with a big series of more or less trivial patches (I count 677 occurences of gpio_to_irq) and might be splitted. 4. request gpios and set them to input when a gpio is marked as an IRQ in the DT and DT is used. Change gpio_rquest_for_irq() to a NOP if DT is used or leave it as it is for the none-dt case. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 27/38] iio: pressure-core: st: Give some indication if device probing was successful
On Tue, 10 Sep 2013, Jonathan Cameron wrote: > Lee Jones wrote: > >At the moment the driver is silent in some error cases and if > >successful. > >Prior to this patch there was no clear way to know if the driver > >succeeded > >or not without looking deep into sysfs. > > > >Signed-off-by: Lee Jones > >--- > > drivers/iio/pressure/st_pressure_core.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > >diff --git a/drivers/iio/pressure/st_pressure_core.c > >b/drivers/iio/pressure/st_pressure_core.c > >index 6ffd949..34b3fb1 100644 > >--- a/drivers/iio/pressure/st_pressure_core.c > >+++ b/drivers/iio/pressure/st_pressure_core.c > >@@ -280,6 +280,9 @@ int st_press_common_probe(struct iio_dev > >*indio_dev, > > if (err && irq > 0) > > goto st_press_device_register_error; > > > >+if (!err) > >+dev_info(&indio_dev->dev, "Successfully registered\n"); > >+ > Not keen. That to my mind is pointless noise. I think it needs to be somewhere. IIO provides no indication whether these chips are probed/registered/whathaveyou, or even if the subsystem is in use. One line per hardware component is not noise, IMO it's indicative of key functionality which is now available: Bootlog: iio iio: lsm303dlh_accel: Successfully registered iio iio: l3g4200d_gyro: Successfully registered iio iio: lps001wp_press: Successfully registered iio iio: lsm303dlhc_magn: Successfully registered > If this made sense then it would be in the driver core not here. Also fine. Just anything but silence/NULL reporting. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Cpufreq: Acquire read lock in the cpufreq_policy_restore() rather than write lock
From: Lan Tianyu In the cpufreq_policy_restore(), policy before system suspend is read from from percpu's cpufreq_cpu_data_fallback. It's read operation rather than write operation. So convert write lock to read lock Signed-off-by: Lan Tianyu --- drivers/cpufreq/cpufreq.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 81ceea6..b762f9b 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -912,11 +912,11 @@ static struct cpufreq_policy *cpufreq_policy_restore(unsigned int cpu) struct cpufreq_policy *policy; unsigned long flags; - write_lock_irqsave(&cpufreq_driver_lock, flags); + read_lock_irqsave(&cpufreq_driver_lock, flags); policy = per_cpu(cpufreq_cpu_data_fallback, cpu); - write_unlock_irqrestore(&cpufreq_driver_lock, flags); + read_unlock_irqrestore(&cpufreq_driver_lock, flags); return policy; } -- 1.8.4.rc0.1.g8f6a3e5.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs
Am 11.09.2013 09:05, schrieb Alexander Holler: Am 10.09.2013 17:00, schrieb Joel Fernandes: I think your initial patch is much better than fixing up DT but then I may be missing other problems with your patch that Linus's patch addresses. The initial patch had the problem that it not only did introduce irq-mappings for only those gpios which are marked as IRQs, but it requested those gpios too and preconfigured them And that breaks every driver which uses gpios for IRQs. To summarize what happens if a driver uses a gpio as irq: gpio_request() // This works only if the gpio was not requested before gpio_direction_input() gpio_to_irq() // This needs an irq-mapping request_threaded_irq() So I would suggest multiple steps to change that: 1. Create a mapping for every gpio found in DT (or all gpios if no DT is used). I think that is what Linus patch does (sorry, I haven't really followed this thread and didn't look in deep at the patch). 2. Implement gpio_request_for_irq() This would just be a small macro for gpio_request(); gpio_direction_input() 3. Change all drivers which do use gpio_to_irq() to use gpio_request_for_irq() instead of gpio_request() and gpio_direction_input(). This will end up with a big series of more or less trivial patches (I count 677 occurences of gpio_to_irq) and might be splitted. 4. request gpios and set them to input when a gpio is marked as an IRQ in the DT and DT is used. Change gpio_rquest_for_irq() to a NOP if DT is used or leave it as it is for the none-dt case. But I still see a possible problem with requesting a gpio (centralized) if it is marked as IRQ in DT: it does this always. I'm not sure, but there might be cases where this isn't wanted. Just that a GPIO is marked as IRQ in the DT for one driver, doesn't mean that this driver will be really used (and something else might use the GPIO instead). Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 27/38] iio: pressure-core: st: Give some indication if device probing was successful
On 09/11/2013 09:10 AM, Lee Jones wrote: On Tue, 10 Sep 2013, Jonathan Cameron wrote: Lee Jones wrote: At the moment the driver is silent in some error cases and if successful. Prior to this patch there was no clear way to know if the driver succeeded or not without looking deep into sysfs. Signed-off-by: Lee Jones --- drivers/iio/pressure/st_pressure_core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/iio/pressure/st_pressure_core.c b/drivers/iio/pressure/st_pressure_core.c index 6ffd949..34b3fb1 100644 --- a/drivers/iio/pressure/st_pressure_core.c +++ b/drivers/iio/pressure/st_pressure_core.c @@ -280,6 +280,9 @@ int st_press_common_probe(struct iio_dev *indio_dev, if (err && irq > 0) goto st_press_device_register_error; + if (!err) + dev_info(&indio_dev->dev, "Successfully registered\n"); + Not keen. That to my mind is pointless noise. I think it needs to be somewhere. IIO provides no indication whether these chips are probed/registered/whathaveyou, or even if the subsystem is in use. One line per hardware component is not noise, IMO it's indicative of key functionality which is now available: Bootlog: iio iio: lsm303dlh_accel: Successfully registered iio iio: l3g4200d_gyro: Successfully registered iio iio: lps001wp_press: Successfully registered iio iio: lsm303dlhc_magn: Successfully registered If this made sense then it would be in the driver core not here. Also fine. Just anything but silence/NULL reporting. Silence means everything is good, a message means there is an error. If every device that gets probed would spit out a message the log would be scrolling forever and you wouldn't be able to see the error messages. - Lars -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] xen-netback: fix possible format string flaw
On Tue, 2013-09-10 at 21:39 -0700, Kees Cook wrote: > This makes sure a format string cannot accidentally leak into the > kthread_run() call. > > Signed-off-by: Kees Cook Acked-by: Ian Campbell Thanks. Ian. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/38] ARM: ux500: CONFIG: Enable ST's IIO Accelerometer Sensors by default
On Tue, 10 Sep 2013, Olof Johansson wrote: > On Tue, Sep 10, 2013 at 8:35 AM, Lee Jones wrote: > > >> splitting this and the other config update into two patches? Really? > > > > I haven't split anything. I created the patches as I was > > enabling/testing the drivers, which was at completely different > > times. The only reason they're close together in the set is because I > > reorganised it and didn't think it was necessary to squash them > > together. > > In this case, squashing makes a lot of sense. No problem. That's all you had to say. I'll do it right away. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 26/38] iio: pressure-core: st: Clean-up probe() function
> > err = st_sensors_init_sensor(indio_dev, plat_data);
> > if (err < 0)
> >-goto st_press_common_probe_error;
> >+return err;
> >
> >-if (pdata->get_irq_data_ready(indio_dev) > 0) {
> >+if (irq > 0) {
> > err = st_press_allocate_ring(indio_dev);
> > if (err < 0)
> >-goto st_press_common_probe_error;
> >+return err;
> >
> > err = st_sensors_allocate_trigger(indio_dev,
> >-ST_PRESS_TRIGGER_OPS);
> >+ ST_PRESS_TRIGGER_OPS);
> > if (err < 0)
> > goto st_press_probe_trigger_error;
> > }
> >
> > err = iio_device_register(indio_dev);
> >-if (err)
>
> This bit of handling is confusing. I would much rather see the if IRQ at the
> goto. Here the first thought is why is it not an error if there is no IRQ!
I certainly see your point. But surely anyone would see after a second
or two that we're returning err and not 0 in this case, so the error
would still be returned, we're not ignoring it. Adding this extra
comparison saves several lines of code.
If you think it's 'too' confusing, I'll revert the change.
Or perhaps a comment:
/* Only deallocate_[trigger|ring] if they were allocated. */
or
/* Only deallocate_[trigger|ring] if we have an IRQ line. */
or
/* If no IRQ was specified, just return the error. */
> >+if (err && irq > 0)
> > goto st_press_device_register_error;
> >
> > return err;
> >
> > st_press_device_register_error:
> >-if (pdata->get_irq_data_ready(indio_dev) > 0)
> >-st_sensors_deallocate_trigger(indio_dev);
> >+st_sensors_deallocate_trigger(indio_dev);
> > st_press_probe_trigger_error:
> >-if (pdata->get_irq_data_ready(indio_dev) > 0)
> >-st_press_deallocate_ring(indio_dev);
> >-st_press_common_probe_error:
> >+st_press_deallocate_ring(indio_dev);
> >+
> > return err;
> > }
> > EXPORT_SYMBOL(st_press_common_probe);
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 27/38] iio: pressure-core: st: Give some indication if device probing was successful
On Wed, 11 Sep 2013, Lars-Peter Clausen wrote: > On 09/11/2013 09:10 AM, Lee Jones wrote: > >On Tue, 10 Sep 2013, Jonathan Cameron wrote: > >>Lee Jones wrote: > >>>At the moment the driver is silent in some error cases and if > >>>successful. > >>>Prior to this patch there was no clear way to know if the driver > >>>succeeded > >>>or not without looking deep into sysfs. > >>> > >>>Signed-off-by: Lee Jones > >>>--- > >>>drivers/iio/pressure/st_pressure_core.c | 3 +++ > >>>1 file changed, 3 insertions(+) > >>> > >>>diff --git a/drivers/iio/pressure/st_pressure_core.c > >>>b/drivers/iio/pressure/st_pressure_core.c > >>>index 6ffd949..34b3fb1 100644 > >>>--- a/drivers/iio/pressure/st_pressure_core.c > >>>+++ b/drivers/iio/pressure/st_pressure_core.c > >>>@@ -280,6 +280,9 @@ int st_press_common_probe(struct iio_dev > >>>*indio_dev, > >>> if (err && irq > 0) > >>> goto st_press_device_register_error; > >>> > >>>+ if (!err) > >>>+ dev_info(&indio_dev->dev, "Successfully registered\n"); > >>>+ > >>Not keen. That to my mind is pointless noise. > > > >I think it needs to be somewhere. IIO provides no indication whether > >these chips are probed/registered/whathaveyou, or even if the > >subsystem is in use. > > > >One line per hardware component is not noise, IMO it's indicative of > >key functionality which is now available: > > > >Bootlog: > > > >iio iio: lsm303dlh_accel: Successfully registered > >iio iio: l3g4200d_gyro: Successfully registered > >iio iio: lps001wp_press: Successfully registered > >iio iio: lsm303dlhc_magn: Successfully registered > > > > > >>If this made sense then it would be in the driver core not here. > > > >Also fine. Just anything but silence/NULL reporting. > > Silence means everything is good, a message means there is an error. > If every device that gets probed would spit out a message the log > would be scrolling forever and you wouldn't be able to see the error > messages. Only if you print out every regulator, clock, GPIO pin and things of this nature. Key hardware blocks such as; SD, Flash, USB, Eth, HDMI, Audio, UART, GPIO and I2C controllers and Sensors I think deserve a one line "I'm here and working" message. I'll not fight this for too long. This is based my experience as a user. I tried to look at the bootlog for the sensors I'd just enabled and there was nothing. Some of them had probed, some hadn't and there was no clear way to distinguish between them without digging into sysfs. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs
And another small update. ;) Am 11.09.2013 09:16, schrieb Alexander Holler: To summarize what happens if a driver uses a gpio as irq: gpio_request() // This works only if the gpio was not requested before gpio_direction_input() gpio_to_irq() // This needs an irq-mapping request_threaded_irq() So I would suggest multiple steps to change that: 1. Create a mapping for every gpio found in DT (or all gpios if no DT is used). I think that is what Linus patch does (sorry, I haven't really followed this thread and didn't look in deep at the patch). 2. Implement gpio_request_for_irq() This would just be a small macro for gpio_request(); gpio_direction_input() I would add gpio_to_irq() to that macro, so that it returns the irq number or zero if something failed. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs
Am 11.09.2013 09:30, schrieb Alexander Holler: And another small update. ;) Am 11.09.2013 09:16, schrieb Alexander Holler: To summarize what happens if a driver uses a gpio as irq: gpio_request() // This works only if the gpio was not requested before gpio_direction_input() gpio_to_irq() // This needs an irq-mapping request_threaded_irq() So I would suggest multiple steps to change that: 1. Create a mapping for every gpio found in DT (or all gpios if no DT is used). I think that is what Linus patch does (sorry, I haven't really followed this thread and didn't look in deep at the patch). 2. Implement gpio_request_for_irq() This would just be a small macro for gpio_request(); gpio_direction_input() I would add gpio_to_irq() to that macro, so that it returns the irq number or zero if something failed. Doing that, it would be easy to mark gpio_to_irq() as deprecated and driver authors would change automatically to use gpio_request_for_irq() (or gpio_request_as_irq() which might more correct english). So I would suggest just the two steps above, the first with the mapping and the second which introduces gpio_request_as_irq() and marks gpio_to_irq() as deprecated. Everthing else I would leave out for the future (so I wouldn't request gpios centrally). Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch -resend] cpqarray: info leak in ida_locked_ioctl()
The pciinfo struct has a two byte hole after ->dev_fn so stack information could be leaked to the user. This was assigned CVE-2013-2147. Signed-off-by: Dan Carpenter diff --git a/drivers/block/cpqarray.c b/drivers/block/cpqarray.c index 639d26b..2b94403 100644 --- a/drivers/block/cpqarray.c +++ b/drivers/block/cpqarray.c @@ -1193,6 +1193,7 @@ out_passthru: ida_pci_info_struct pciinfo; if (!arg) return -EINVAL; + memset(&pciinfo, 0, sizeof(pciinfo)); pciinfo.bus = host->pci_dev->bus->number; pciinfo.dev_fn = host->pci_dev->devfn; pciinfo.board_id = host->board_id; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch -resend] cciss: info leak in cciss_ioctl32_passthru()
The arg64 struct has a hole after ->buf_size which isn't cleared. Or if any of the calls to copy_from_user() fail then that would cause an information leak as well. This was assigned CVE-2013-2147. Signed-off-by: Dan Carpenter diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c index 6374dc1..34971aa 100644 --- a/drivers/block/cciss.c +++ b/drivers/block/cciss.c @@ -1189,6 +1189,7 @@ static int cciss_ioctl32_passthru(struct block_device *bdev, fmode_t mode, int err; u32 cp; + memset(&arg64, 0, sizeof(arg64)); err = 0; err |= copy_from_user(&arg64.LUN_info, &arg32->LUN_info, -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Introducing libgadget 0.0.1
On Wednesday 2013-09-04 19:25, Matt Porter wrote: >With the move to configfs for creation of arbitrary USB composite gadgets, >I found myself wanting a simple C library to configure and parse gadgets >in a system. It has no other dependencies other than libc itself. > >It can be found at: > > git://git.linaro.org/people/mporter/libgadget.git Hm but there is already a libgadget (and not just one) if you query a particular search engine entitled Google :} >$ mkdir /config >$ mount -t configfs none /config Do your tools support input of a different location? (systemd mounts configfs at /sys/kernel/config.) >$ gadget-acm-ecm >$ show-gadgets >ID 1d6b:0104 'g1' >[...] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [197/251] iwl4965: reset firmware after rfkill off
On Wed, Sep 11, 2013 at 12:30:24AM -0400, Steven Rostedt wrote: > 3.6.11.9-rc1 stable review patch. > If anyone has any objections, please let me know. > > -- > > From: Stanislaw Gruszka > > [ Upstream commit 788f7a56fce1bcb2067b62b851a086fca48a0056 ] This require follow up - upstream commit: commit b2fcc0aee58a3435566dd6d8501a0b32f28b Author: Stanislaw Gruszka Date: Wed Aug 21 10:18:19 2013 +0200 iwl4965: fix rfkill set state regression which seems to be missed on the set. Stanislaw -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] media: i2c: add driver for dual LED Flash, lm3560.
This patch includes the driver for the LM3560, dual LED Flash.
The LM3560 has two 1A constant current drivers for high current
white LEDs. It is controlled via an I2C compatible interface(up to 400kHz).
And each flash, torch brightness and enable/disable LED can be controlled
independantly. But flash timeout and operation mode are shared.
Signed-off-by: Daniel Jeong
---
drivers/media/i2c/Kconfig |9 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/lm3560.c | 716
include/media/lm3560.h | 103 +++
4 files changed, 829 insertions(+)
create mode 100644 drivers/media/i2c/lm3560.c
create mode 100644 include/media/lm3560.h
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index d18be19..75c8a03 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -621,6 +621,15 @@ config VIDEO_AS3645A
This is a driver for the AS3645A and LM3555 flash controllers. It has
build in control for flash, torch and indicator LEDs.
+config VIDEO_LM3560
+ tristate "LM3560 dual flash driver support"
+ depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
+ depends on MEDIA_CAMERA_SUPPORT
+ select REGMAP_I2C
+ ---help---
+ This is a driver for the lm3560 dual flash controllers. It controls
+ flash, torch LEDs.
+
comment "Video improvement chips"
config VIDEO_UPD64031A
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 9f462df..e03f177 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -70,6 +70,7 @@ obj-$(CONFIG_VIDEO_S5K4ECGX) += s5k4ecgx.o
obj-$(CONFIG_VIDEO_S5C73M3)+= s5c73m3/
obj-$(CONFIG_VIDEO_ADP1653)+= adp1653.o
obj-$(CONFIG_VIDEO_AS3645A)+= as3645a.o
+obj-$(CONFIG_VIDEO_LM3560) += lm3560.o
obj-$(CONFIG_VIDEO_SMIAPP_PLL) += smiapp-pll.o
obj-$(CONFIG_VIDEO_AK881X) += ak881x.o
obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o
diff --git a/drivers/media/i2c/lm3560.c b/drivers/media/i2c/lm3560.c
new file mode 100644
index 000..7721e2e
--- /dev/null
+++ b/drivers/media/i2c/lm3560.c
@@ -0,0 +1,716 @@
+/*
+ * drivers/media/i2c/lm3560.c
+ * General device driver for TI LM3560, Dual FLASH LED Driver
+ *
+ * Copyright (C) 2013 Texas Instruments
+ *
+ * Contact: Daniel Jeong
+ * LDD-MLP
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* registers definitions */
+#define REG_ENABLE 0x10
+#define REG_TORCH_BR 0xA0
+#define REG_FLASH_BR 0xB0
+#define REG_FLASH_TOUT 0xC0
+#define REG_FLAG 0xD0
+#define REG_CONFIG10xE0
+
+/* LED1 */
+#define LED1_ENABLE 0x08
+#define LED1_ENABLE_MASK 0x08
+#define FLASH1_BR_DATA(_br) (_br<<0)
+#define FLASH1_BR_MASK 0x0F
+#define TORCH1_BR_DATA(_br) (_br<<0)
+#define TORCH1_BR_MASK 0x07
+
+/* LED2 */
+#define LED2_ENABLE 0x10
+#define LED2_ENABLE_MASK 0x10
+#define FLASH2_BR_DATA(_br) (_br<<4)
+#define FLASH2_BR_MASK 0xF0
+#define TORCH2_BR_DATA(_br) (_br<<3)
+#define TORCH2_BR_MASK 0x38
+
+/* Configuration */
+#define ENABLE_MODE_MASK 0x03
+#define FLASH_TOUT_MASK 0x1F
+#define STROBE_EN_MASK 0x04
+#define STROBE_EN_DATA(_config) (_config<<2)
+#define PEAK_I_MASK 0x60
+
+/* Fault Mask */
+#define FAULT_TIMEOUT (1<<0)
+#define FAULT_OVERTEMP (1<<1)
+#define FAULT_SHORT_CIRCUIT (1<<2)
+
+#define to_lm3560_led_flash(sd, _id)\
+ container_of(sd, struct lm3560_flash, subdev_led##_id)
+
+enum led_enable {
+ MODE_SHDN = 0x0,
+ MODE_TORCH = 0x2,
+ MODE_FLASH = 0x3,
+};
+
+/* struct lm3560_flash
+ *
+ * @pdata: platform data
+ * @regmap: reg. map for i2c
+ * @power_lock: Protects power_count
+ * @power_count: Power reference count
+ * @led_mode: V4L2 LED mode
+ * @fault: falut data
+ * @ctrls_led#: V4L2 contols
+ * @subdev_led#: V4L2 subdev
+ */
+struct lm3560_flash {
+ struct lm3560_platform_data *pdata;
+ struct regmap *regmap;
+ struct mutex power_lock;
+ int power_count;
+
+ enum v4l2_flash_led_mode led_mode;
+ u8 fault;
+ /* LED1 */
+ struct v4l2_ctrl_handler ctrls_led1;
+ struct v4l2_subdev subdev_led1;
+ /* LED2 */
+ struct v4l2_ctrl_handler ctrls_led2;
+ struct v4l2_subdev subdev_led2;
+}
Re: [PATCH v8 0/7] cpufreq:boost: CPU Boost mode support
That is some important piece of information that might be useful for others and so cc'ing LKML and other lists.. On 11 September 2013 01:06, Rafael J. Wysocki wrote: > On Tuesday, September 10, 2013 02:16:03 PM Lukasz Majewski wrote: >> For my curiosity - what is the difference between bleeding-edge and >> linux-next branches at kernel_pm? > > linux-next are patches that I'm going to push to Linus in the future and that > have passed automated build testing. I still may drop one of them > occasionally > or add tags to commits and rebase the branch as a result, though. > > bleeding-edge is linux-next plus patches under automated build testing, but it > may contain some purely experimental stuff too. During a merge window, like > for example today, it also may contain material for the second next release > (like 3.13 at the moment). > > In addition to those, there are topic branches like pm-cpufreq, acpica etc. > that are only material either in the Linus' tree already or going to be pushed > to Linus going forward and I don't rebase them. > > So if you want a stable branch to work on top of, either use one of the topic > branches (but please note that they may be somewhat behind Linus sometimes), > or > ask me for one directly. > > Thanks, > Rafael > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] powerpc: Export cpu_to_chip_id() to fix build error
On 09/11/2013 03:33 AM, Benjamin Herrenschmidt wrote: On Mon, 2013-09-09 at 18:37 -0700, Guenter Roeck wrote: powerpc allmodconfig build fails with: ERROR: ".cpu_to_chip_id" [drivers/block/mtip32xx/mtip32xx.ko] undefined! The problem was introduced with commit 15863ff3b (powerpc: Make chip-id information available to userspace). Thanks, I'll send that to Linus asap. Verified on today's Linus tree. This issue is fixed. Thanks a lot. -Vasant Ben. Export the missing symbol. Cc: Vasant Hegde Cc: Shivaprasad G Bhat Signed-off-by: Guenter Roeck --- arch/powerpc/kernel/smp.c |1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c index 442d8e2..8e59abc 100644 --- a/arch/powerpc/kernel/smp.c +++ b/arch/powerpc/kernel/smp.c @@ -611,6 +611,7 @@ int cpu_to_chip_id(int cpu) of_node_put(np); return of_get_ibm_chip_id(np); } +EXPORT_SYMBOL(cpu_to_chip_id); /* Helper routines for cpu to core mapping */ int cpu_core_index_of_thread(int cpu) ___ Linuxppc-dev mailing list linuxppc-...@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/38] ARM: ux500: Remove PrimeCell IDs from Nomadik I2C DT nodes
On Tue, Sep 10, 2013 at 6:57 PM, Olof Johansson wrote: > I have a very weird experience with snowball right now. I noticed this > yesterday when I decided to look at why multi_v7_defconfig doesn't > boot on it: > > * u8500_defconfig doesn't boot as a DT kernel, since the machine ID is > still enabled. If I disable the machine ID, it doesn't boot. > * Same for multi_v7_defconfig, since that is only DT: It doesn't boot. Weird, yeah there is something wrong on Torvalds' HEAD, with earlyprint it says: Uncompressing Linux... done, booting the kernel. Error: unrecognized/unsupported processor variant (0x412fc091). This comes from arch/arm/kernel/head-common.S I'm trying to bisect and find out what is causing this... Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: "cpufreq: fix serialization issues with freq change notifiers" breaks cpufreq too
On 10 September 2013 22:37, Guennadi Liakhovetski wrote: > On Tue, 10 Sep 2013, Viresh Kumar wrote: >> Quite straight forward actually.. > > Apparently, not quite. I overlooked the situation where we return early from ->target() routines.. :( Please try attached patches, I will repost them later (once I am able to convince Rafael that these are really important :) ) -- viresh 0001-cpufreq-distinguish-drivers-that-do-asynchronous-not.patch Description: Binary data 0002-cpufreq-fix-notification-serialization-issues.patch Description: Binary data
Re: [PATCH 1/1] staging/speakup/kobjects.c: Code improvement.
On Tue, Sep 10, 2013 at 06:29:39PM -0700, Chris Brannon wrote: > Ok. I just sent up a patch to the driverdev list. I missed a few > of the Cc's that were on this thread, though. > Also, it will conflict with Raphael's cleanup. You're missing Raphael's CC in particular... Really, Raphael's patch arrived first. No one seems to have any objections to his patch. Normally apply it first and then apply this one. If we decide to push this one to -stable then we would redo it (in other words push the one you just sent). Of course, the merge window is open right now so nothing is going to be applied for a couple weeks. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Cpufreq: Acquire read lock in the cpufreq_policy_restore() rather than write lock
On 09/11/2013 12:35 PM, tianyu@intel.com wrote: > From: Lan Tianyu > > In the cpufreq_policy_restore(), policy before system suspend is read from > from percpu's cpufreq_cpu_data_fallback. It's read operation rather than > write operation. So convert write lock to read lock > > Signed-off-by: Lan Tianyu Reviewed-by: Srivatsa S. Bhat I noticed it too yesterday, while looking at something else. Thanks for fixing this! > --- > drivers/cpufreq/cpufreq.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c > index 81ceea6..b762f9b 100644 > --- a/drivers/cpufreq/cpufreq.c > +++ b/drivers/cpufreq/cpufreq.c > @@ -912,11 +912,11 @@ static struct cpufreq_policy > *cpufreq_policy_restore(unsigned int cpu) > struct cpufreq_policy *policy; > unsigned long flags; > > - write_lock_irqsave(&cpufreq_driver_lock, flags); > + read_lock_irqsave(&cpufreq_driver_lock, flags); > > policy = per_cpu(cpufreq_cpu_data_fallback, cpu); > > - write_unlock_irqrestore(&cpufreq_driver_lock, flags); > + read_unlock_irqrestore(&cpufreq_driver_lock, flags); > > return policy; > } > Regards, Srivatsa S. Bhat -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: "cpufreq: fix serialization issues with freq change notifiers" breaks cpufreq too
On Wed, 11 Sep 2013, Viresh Kumar wrote: > On 10 September 2013 22:37, Guennadi Liakhovetski > wrote: > > On Tue, 10 Sep 2013, Viresh Kumar wrote: > >> Quite straight forward actually.. > > > > Apparently, not quite. > > I overlooked the situation where we return early from ->target() routines.. :( > > Please try attached patches, I will repost them later (once I am able to > convince Rafael that these are really important :) ) I'd rather wait until Rafael is convinced, then we'll see. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/38] ARM: ux500: Remove PrimeCell IDs from Nomadik I2C DT nodes
On Tue, 10 Sep 2013, Olof Johansson wrote: > [pruning out the iio list/people] > > On Tue, Sep 10, 2013 at 8:30 AM, Lee Jones wrote: > >> On Tue, Sep 10, 2013 at 5:49 AM, Lee Jones wrote: > >> > Turns out that they're actually not required and the driver probes just > >> > fine without them. The ID is incorrect at the moment anyway. They > >> > actually > >> > currently specify the stn8815. > >> > > >> > Signed-off-by: Lee Jones > >> > >> How did you test this patch? What hardware did you boot it on and with > >> what config? > > > > Snowball, u8500_defconfig. > > > > Why? Don't you have the same result with yours? > > I have a very weird experience with snowball right now. I noticed this > yesterday when I decided to look at why multi_v7_defconfig doesn't > boot on it: > > * u8500_defconfig doesn't boot as a DT kernel, since the machine ID is > still enabled. If I disable the machine ID, it doesn't boot. > * Same for multi_v7_defconfig, since that is only DT: It doesn't boot. I'm not entirely sure what you mean by this, as I have Snowball booting as a Device Tree only platform: http://www.spinics.net/lists/kernel/msg1590759.html The Machine ID should be all F's for DT I think. > Unfortunately I can't get to my home network right now to double-check > boot logs to see if this has changed behavior recently, I'll have to > do that later today. It'd be interesting to hear if you have the same > experience w.r.t. DT on u8500_defconfig though. I just changed SNOWBALL's machine ID to and it still boots just fine with DT (ATAGs boot hangs). So what did you do? Can you send me a patch of what you did, so I might reproduce your build please? -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 1/5] xen: xensyms support
>>> On 10.09.13 at 17:31, Boris Ostrovsky wrote: > --- a/drivers/xen/Kconfig > +++ b/drivers/xen/Kconfig > @@ -242,4 +242,9 @@ config XEN_MCE_LOG > config XEN_HAVE_PVMMU > bool > > +config XEN_SYMS > + bool "Xen symbols" > + depends on XEN_DOM0 && XENFS && KALLSYMS > + default y Looking through the rest of the patch I can't see the dependency on KALLSYMS. Perhaps this should be used for the default setting instead of as a dependency? Jan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/38] ARM: ux500: Remove PrimeCell IDs from Nomadik I2C DT nodes
On Wed, 11 Sep 2013, Linus Walleij wrote: > On Tue, Sep 10, 2013 at 6:57 PM, Olof Johansson wrote: > > > I have a very weird experience with snowball right now. I noticed this > > yesterday when I decided to look at why multi_v7_defconfig doesn't > > boot on it: > > > > * u8500_defconfig doesn't boot as a DT kernel, since the machine ID is > > still enabled. If I disable the machine ID, it doesn't boot. > > * Same for multi_v7_defconfig, since that is only DT: It doesn't boot. > > Weird, yeah there is something wrong on Torvalds' HEAD, with > earlyprint it says: > > Uncompressing Linux... done, booting the kernel. > Error: unrecognized/unsupported processor variant (0x412fc091). > This comes from arch/arm/kernel/head-common.S > > I'm trying to bisect and find out what is causing this... Ah nice. Keep us informed of any progress. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ACPI / osl: implement acpi_os_sleep() with msleep()
Currently the acpi_os_sleep() is using the schedule_timeout_interruptible(),
which can be interrupted by signal, which causes the real sleep time is shorter.
According to the ACPI spec:
The Sleep term is used to implement long-term timing requirements.
Execution is delayed for at least the required number of milliseconds.
The sleeping time should be at least of the required number msecs, here
using msleep() to implement it.
Also if the real time is shorter, we meet the device POWER ON issue.
CC: lizhuangzhi
CC: Li Fei
Signed-off-by: liu chuansheng
---
drivers/acpi/osl.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index e5f416c..b1629b5 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -820,7 +820,7 @@ acpi_status acpi_os_remove_interrupt_handler(u32 irq,
acpi_osd_handler handler)
void acpi_os_sleep(u64 ms)
{
- schedule_timeout_interruptible(msecs_to_jiffies(ms));
+ msleep(ms);
}
void acpi_os_stall(u32 us)
--
1.7.0.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/
Re: [PATCH 2/7] sched: Add NEED_RESCHED to the preempt_count
On Tue, Sep 10, 2013 at 06:59:57PM -0700, Andy Lutomirski wrote: > On 09/10/2013 06:08 AM, Peter Zijlstra wrote: > > In order to combine the preemption and need_resched test we need to > > fold the need_resched information into the preempt_count value. > > > > We keep the existing TIF_NEED_RESCHED infrastructure in place but at 3 > > sites test it and fold its value into preempt_count; namely: > > > > - resched_task() when setting TIF_NEED_RESCHED on the current task > > - scheduler_ipi() when resched_task() sets TIF_NEED_RESCHED on a > >remote task it follows it up with a reschedule IPI > >and we can modify the cpu local preempt_count from > >there. > > - cpu_idle_loop() for when resched_task() found tsk_is_polling(). > > > It looks like the intel_idle code can get confused if TIF_NEED_RESCHED > is set but the preempt resched bit is not -- the need_resched call > between monitor and mwait won't notice TIF_NEED_RESCHED. > > Is this condition possible? Ah indeed, I'll have to go find all idle loops out there it seems. Now if only they were easy to spot :/ I was hoping the generic idle thing was good enough, apparently not quite. Thanks for spotting that. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[071/251] PM / Sleep: avoid autosleep in shutdown progress
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Liu ShuoX
[ Upstream commit e5248a111bf4048a9f3fab1a9c94c4630a10592a ]
Prevent automatic system suspend from happening during system
shutdown by making try_to_suspend() check system_state and return
immediately if it is not SYSTEM_RUNNING.
This prevents the following breakage from happening (scenario from
Zhang Yanmin):
Kernel starts shutdown and calls all device driver's shutdown
callback. When a driver's shutdown is called, the last wakelock is
released and suspend-to-ram starts. However, as some driver's shut
down callbacks already shut down devices and disabled runtime pm,
the suspend-to-ram calls driver's suspend callback without noticing
that device is already off and causes crash.
[rjw: Changelog]
Signed-off-by: Liu ShuoX
Cc: 3.5+
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Steven Rostedt
---
kernel/power/autosleep.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/power/autosleep.c b/kernel/power/autosleep.c
index ca304046..ab79ecb 100644
--- a/kernel/power/autosleep.c
+++ b/kernel/power/autosleep.c
@@ -32,7 +32,8 @@ static void try_to_suspend(struct work_struct *work)
mutex_lock(&autosleep_lock);
- if (!pm_save_wakeup_count(initial_count)) {
+ if (!pm_save_wakeup_count(initial_count) ||
+ system_state != SYSTEM_RUNNING) {
mutex_unlock(&autosleep_lock);
goto out;
}
--
1.7.10.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/
Re: [PATCH] [scsi] enclosure: remove all possible sysfs entries before add device
On 09/10/13 20:46, James Bottomley wrote: >> > During our test, multipath used, each LUN has 2 paths. when adding second >> > path enclousure did not check if will adding device's symlink existed or >> > no. > The description doesn't look helpful. The problem, presumably in a > remove/re-add test that the add event gets processed before the remove > event, which is why the link is still there? Attach my debug info to here: sd 7:0:27:0: [ses_intf_add]:cdev:8817e81fcba0,intf:a00c9400,sdev:8817e81fc800 sd 7:0:27:0: [ses_intf_add] call ses_match_to_enclosure(edev=8817e812c000,sdev=8817e81fc800), cdev=8817e81fcba0 sd 7:0:27:0: *** inq[6]: 48 sd 7:0:27:0: [sdq] 1172123568 512-byte logical blocks: (600 GB/558 GiB) sd 7:0:27:0: [sdq] Write Protect is off ADD: [enclosure_add_links]: kobj: target: , device ADD: [enclosure_add_links]: kobj: target: , name: enclosure_device:HDD10 [ses_enclosure_find_by_addr] call enclosure_add_device(edev=8817e812c000,i=4,efd->dev=8817e81fc938),cdev=8817e812ccd0 sd 7:0:27:0: [ses_intf_add] call ses_match_to_enclosure(edev=8817ebd18000,sdev=8817e81fc800), cdev=8817e81fcba0 sd 7:0:27:0: *** inq[6]: 48 sd 7:0:27:0: [sdq] Write cache: disabled, read cache: enabled, supports DPO and FUA [ses_enclosure_find_by_addr] call enclosure_add_device(edev=8817e812c000,i=4,efd->dev=8817e81fc938),cdev=8817e812ccd0 sd 7:0:27:0: Attached scsi generic sg17 type 0 sdq: sdq1 sdq2 scsi 6:0:27:0: SSP: handle(0x001c), sas_addr(0x5000c56bd15e), phy(2), device_name(0x5000c56bd15e) scsi 6:0:27:0: SSP: enclosure_logical_id(0x508002a3a510), slot(10) scsi 6:0:27:0: serial_number(000934E00P0S3SL00P0S) scsi 6:0:27:0: qdepth(254), tagged(1), simple(0), ordered(0), scsi_level(6), cmd_que(1) sd 6:0:27:0: [ses_intf_add]:cdev:8817e8304ba0,intf:a00c9400,sdev:8817e8304800 sd 6:0:27:0: [ses_intf_add] call ses_match_to_enclosure(edev=8817e0c5c000,sdev=8817e8304800), cdev=8817e8304ba0 sd 6:0:27:0: *** inq[6]: 48 sd 6:0:27:0: [sdac] 1172123568 512-byte logical blocks: (600 GB/558 GiB) sd 7:0:27:0: [sdq] Attached SCSI disk RM: [enclosure_remove_links]: kobj: name: [enclosure_device:HDD10] RM: [enclosure_remove_links]: kobj: device sd 6:0:27:0: [sdac] Write Protect is off ADD: [enclosure_add_links]: kobj: target: , device ADD: [enclosure_add_links]: kobj: target: , name: enclosure_device:HDD10 [ses_enclosure_find_by_addr] call enclosure_add_device(edev=8817e812c000,i=4,efd->dev=8817e8304938),cdev=8817e812ccd0 sd 6:0:27:0: [ses_intf_add] call ses_match_to_enclosure(edev=8817e4094000,sdev=8817e8304800), cdev=8817e8304ba0 sd 6:0:27:0: *** inq[6]: 48 RM: [enclosure_remove_links]: kobj: name: [enclosure_device:HDD10] RM: [enclosure_remove_links]: kobj: device ADD: [enclosure_add_links]: kobj: target: , device ADD: [enclosure_add_links]: kobj: target: , name: enclosure_device:HDD10 [ cut here ] WARNING: at fs/sysfs/dir.c:455 sysfs_add_one+0xbc/0xe0() Hardware name: SUN FIRE X4370 M2 SERVER sysfs: cannot create duplicate filename '/devices/pci:00/:00:03.0/:0d:00.0/host6/port-6:1/expander-6:1/port-6:1:14/end_device-6:1:14/target6:0:27/6:0:27:0/enclosure_device:HDD10' Modules linked in: oracleacfs(P)(U) oracleadvm(P)(U) oracleoks(P)(U) mptctl mptbase autofs4 hidp bluetooth rfkill lockd sunrpc bonding be2iscsi iscsi_boot_sysfs ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp bnx2i cnic uio ipv6 cxgb3i libcxgbi cxgb3 mdio libiscsi_tcp libiscsi scsi_transport_iscsi dm_round_robin dm_multipath video sbs sbshc acpi_pad acpi_memhotplug acpi_ipmi parport_pc lp parport ipmi_si ipmi_devintf ipmi_msghandler sg ses enclosure ixgbe e1000e hwmon igb snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc iTCO_wdt pcspkr i2c_i801 ioatdma ghes iTCO_vendor_support hed dca i2c_core i7core_edac edac_core dm_snapshot dm_zero dm_mirror dm_region_hash dm_log dm_mod usb_storage shpchp mpt2sas scsi_transport_sas raid_class ahci libahci sd_mod crc_t10dif raid1 ext3 jbd mbcache Pid: 23302, comm: kworker/u:2 Tainted: P 2.6.39-400.124.1.el5uek.bug17342873V2 #1 Call Trace: [] ? sysfs_add_one+0xbc/0xe0 [] warn_slowpath_common+0x90/0xc0 [] warn_slowpath_fmt+0x6e/0x70 [] ? strlcat+0x54/0x70 [] sysfs_add_one+0xbc/0xe0 [] sysfs_do_create_link+0x148/0x1d0 [] sysfs_create_link+0x13/0x20 [] enclosure_add_links+0xe7/0x110 [enclosure] [] ? kobject_release+0xd/0x10 [] ? kref_put+0x37/0x70 [] enclosure_add_device+0x93/0xa0 [enclosure] [] ses_enclosure_find_by_addr+0x76/0xc0 [ses] [] ? ses_get_fault+0x40/0x40 [ses] [] enclosure_for_each_device+0x63/0x90 [enclosure] [] ses_match_to_enclosure+0x11a/0x1d0 [ses] [] ses_intf_add+0x2c8/0x5c0 [ses] [] ? kobject_get+0x1a/0x30 [] ? add_tail+0x36/0x50 [] device_add+0x2d4/0x380
[PATCH net] tuntap: correctly handle error in tun_set_iff()
Commit c8d68e6be1c3b242f1c598595830890b65cea64a (tuntap: multiqueue support) only call free_netdev() on err in tun_set_iff(). This causes several issues: - memory of tun security were leaked - use after free since the flow gc timer was not deleted and the tfile were not detached This patch solves the above issues. Reported-by: Wannes Rombouts Cc: Michael S. Tsirkin Signed-off-by: Jason Wang --- The patch were also needed for stable 3.8+. --- drivers/net/tun.c |9 +++-- 1 files changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/net/tun.c b/drivers/net/tun.c index a639de8..e5fb5d3 100644 --- a/drivers/net/tun.c +++ b/drivers/net/tun.c @@ -1641,11 +1641,11 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr) INIT_LIST_HEAD(&tun->disabled); err = tun_attach(tun, file, false); if (err < 0) - goto err_free_dev; + goto err_free_flow; err = register_netdevice(tun->dev); if (err < 0) - goto err_free_dev; + goto err_detach; if (device_create_file(&tun->dev->dev, &dev_attr_tun_flags) || device_create_file(&tun->dev->dev, &dev_attr_owner) || @@ -1689,6 +1689,11 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr) strcpy(ifr->ifr_name, tun->dev->name); return 0; +err_detach: + tun_detach_all(dev); +err_free_flow: + tun_flow_uninit(tun); + security_tun_dev_free_security(tun->security); err_free_dev: free_netdev(dev); return err; -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "cpufreq: fix serialization issues with freq change notifiers" breaks cpufreq too
On 11 September 2013 01:16, Rafael J. Wysocki wrote:
> On Tuesday, September 10, 2013 08:44:18 PM Viresh Kumar wrote:
>> Now Second question, is this fine to have multiple PRECHANGE notfications
>> before any POSTCHANGE notification?
>>
>> Logically it looks obvious to me that these must be serialized..
>> Otherwise this is what we are broadcasting:
>> - We are changing for freq X, please prepare and let us know if you are
>> okay with it..
>> - Oh.. So sorry, we are changing to freq Y instead, please adjust
>> accordingly.
>>
>> - Yes we have changed to freq Y...
>> - Yes we have changed to freq X...
>>
>> This looks stupid, isn't it? I don't know how the drivers would behave when
>> they see such notifications and so got to this patch initially..
>
> Well, precisely, you don't know.
>
> Can you please look for specific problems and address those instead of trying
> to address potential issues that may or may not happen and may or may not
> really
> be issues even if they actually happen?
That looked like a straight forward issue/bug to me and so I haven't
gotten deep into it..
Scenario 1:
--
Notifiers are not serialized and suppose this is what happened
- PRECHANGE Notification for freq A (from cpuinfo_cur_freq)
- PRECHANGE Notification for freq B (from target())
- Freq changed by target() to B
- POSTCHANGE Notification for freq B
- POSTCHANGE Notification for freq A
Now the last POSTCHANGE Notification happened for freq A and
hardware is currently running at freq B :)
Where would we break then?: adjust_jiffies() in cpufreq.c,
cpufreq_callback() in arch/arm/kernel/smp.c (which is also adjusting
jiffies)..
Now, all loops_per_jiffy based stuff is broken.. Have I missed
something?
Similarly there are numerous places where we may break.. As we
have broken expectations of receivers of these notifications..
Scenario 2:
--
Governor is changing freq and has called __cpufreq_driver_target().
At the same time we are changing scaling_{min|max}_freq from
sysfs, which would eventually end up calling governors:
CPUFREQ_GOV_LIMITS notification, that will also call:
__cpufreq_driver_target()..
So, we eventually have two concurrent calls to ->target() and we
don't really know how hardware will behave in this case.. Most of
the implementations of ->target() routines just go and change
freq/voltage without checking if we are already in progress of doing
that (i.e. based on expectation that this call is not re entrant)..
Now anything can happen at hardware level, which I don't have
all insight of :(
> And broken patches that try to fix such things definitely don't help.
Yeah, that's my fault but I honestly try to produce bug-less patches..
But being a normal human being, there are always some chances
that my patches are eventually broken :)
> For now I'm reverting the commit in question and everything on top of it.
Its okay..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: "cpufreq: fix serialization issues with freq change notifiers" breaks cpufreq too
On 11 September 2013 13:45, Guennadi Liakhovetski wrote: > I'd rather wait until Rafael is convinced, then we'll see. Okay.. I have just sent a mail to Rafael about that, see if you are convinced with what I wrote :) -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] kconfig updates for v3.12-rc1
Hi Linus, this is the kconfig part of kbuild for v3.12-rc1: - post-3.11 search code fixes and micro-optimizations - CONFIG_MODULES is no longer a special case; this is needed to eventually fix the bug that using KCONFIG_ALLCONFIG breaks allmodconfig - long long is used to store hex and int values - make silentoldconfig no longer warns when a symbol changes from tristate to bool (it's a job for make oldconfig) - scripts/diffconfig updated to work with newer Pythons - scripts/config does not rely on GNU sed extensions Michal The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092: Linux 3.11-rc1 (2013-07-14 15:18:27 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild.git kconfig for you to fetch changes up to e062781397e5bebc6c1b8dd4bf466136e13ae4c5: kconfig: do not allow more than one symbol to have 'option modules' (2013-09-05 11:10:08 +0200) Clement Chauplannaz (1): scripts/config: use sed's POSIX interface Kees Cook (1): kconfig: switch to "long long" for sanity Michal Marek (1): Merge branch 'yem-kconfig-rc-fixes' of git://gitorious.org/linux-kconfig/linux-kconfig into kbuild/kconfig Mike Pagano (2): diffconfig: Gracefully exit if the default config files are not present diffconfig: Update script to support python versions 2.5 through 3.3 Yann E. MORIN (11): Documentation/kconfig: more concise and straightforward search explanation kconfig: avoid multiple calls to strlen kconfig/[mn]conf: shorten title in search-box kconfig: minor style fixes in symbol-search code kconfig: don't allocate n+1 elements in temporary array kconfig: simplify symbol-search code kconfig: silence warning when parsing auto.conf when a symbol has changed type modules: do not depend on kconfig to set 'modules' option to symbol MODULES kconfig: do not special-case 'MODULES' symbol kconfig: regenerate bison parser kconfig: do not allow more than one symbol to have 'option modules' Documentation/kbuild/kconfig-language.txt | 1 + Documentation/kbuild/kconfig.txt | 8 +- init/Kconfig | 1 + scripts/config| 44 ++- scripts/diffconfig| 33 +- scripts/kconfig/confdata.c| 11 +- scripts/kconfig/mconf.c | 4 +- scripts/kconfig/menu.c| 11 +- scripts/kconfig/nconf.c | 4 +- scripts/kconfig/symbol.c | 68 ++-- scripts/kconfig/zconf.tab.c_shipped | 562 -- scripts/kconfig/zconf.y | 11 +- 12 files changed, 413 insertions(+), 345 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: [146/251] zram: use zram->lock to protect zram_free_page() in swap free notify path
Steven Rostedt writes:
> 3.6.11.9-rc1 stable review patch.
> If anyone has any objections, please let me know.
This commit seems to cause regressions [1]. There's a fix for it with
commit a0c516cbfc7452c8cbd564525fef66d9f20b46d1 but it doesn't apply
cleanly (it probably requires several other commits to be
backported). Thus, I am reverting it from the 3.5 extended stable
kernel.
[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1215513
Cheers,
--
Luis
>
> --
>
> From: Jiang Liu
>
> [ Upstream commit 57ab048532c0d975538cebd4456491b5c34248f4 ]
>
> zram_slot_free_notify() is free-running without any protection from
> concurrent operations. So there are race conditions between
> zram_bvec_read()/zram_bvec_write() and zram_slot_free_notify(),
> and possible consequences include:
> 1) Trigger BUG_ON(!handle) on zram_bvec_write() side.
> 2) Access to freed pages on zram_bvec_read() side.
> 3) Break some fields (bad_compress, good_compress, pages_stored)
>in zram->stats if the swap layer makes concurrently call to
>zram_slot_free_notify().
>
> So enhance zram_slot_free_notify() to acquire writer lock on zram->lock
> before calling zram_free_page().
>
> Signed-off-by: Jiang Liu
> Cc: sta...@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman
> Signed-off-by: Steven Rostedt
> ---
> drivers/staging/zram/zram_drv.c |2 ++
> drivers/staging/zram/zram_drv.h |5 +++--
> 2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
> index 38a1b44..4322baf 100644
> --- a/drivers/staging/zram/zram_drv.c
> +++ b/drivers/staging/zram/zram_drv.c
> @@ -622,7 +622,9 @@ static void zram_slot_free_notify(struct block_device
> *bdev,
> struct zram *zram;
>
> zram = bdev->bd_disk->private_data;
> + down_write(&zram->lock);
> zram_free_page(zram, index);
> + up_write(&zram->lock);
> zram_stat64_inc(zram, &zram->stats.notify_free);
> }
>
> diff --git a/drivers/staging/zram/zram_drv.h b/drivers/staging/zram/zram_drv.h
> index 572c0b1..a6eb5d9 100644
> --- a/drivers/staging/zram/zram_drv.h
> +++ b/drivers/staging/zram/zram_drv.h
> @@ -92,8 +92,9 @@ struct zram {
> void *compress_buffer;
> struct table *table;
> spinlock_t stat64_lock; /* protect 64-bit stats */
> - struct rw_semaphore lock; /* protect compression buffers and table
> -* against concurrent read and writes */
> + struct rw_semaphore lock; /* protect compression buffers, table,
> +* 32bit stat counters against concurrent
> +* notifications, reads and writes */
> struct request_queue *queue;
> struct gendisk *disk;
> int init_done;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
On Wed, 11 Sep 2013, Aaron Lu wrote: > It is possible the i915 driver decides not to register a backlight > interface for the graphics card for some reason(memory allocation failed > or it knows the native control does not work on this card or whatever), > so I would prefer let i915 tell ACPI video that it has registered a > native backlight control interface as Jani has said. > > Then together with the video.use_native_backlight, we can register or > not register ACPI video backlight interface accordingly. Or rather, we > can simply not register ACPI video backlight interface for Win8 systems > as long as i915 indicates that it has native backlight control(if the > native control is broken, i915 should fix it or blacklist it so that > i915 will not indicate it has native backlight control and ACPI video > will continue to register its own). > > How does this sound? Sounds good to me. Before plunging forward, have you observed any difference between the boot modes? We have reports [1] that the backlight behaviour is different with UEFI vs. UEFI+CSM or legacy boot. So I'm wondering if the acpi_gbl_osi_data >= ACPI_OSI_WIN_8 check in patch 2/2 is the whole story. Further, if we tell the BIOS we're Windows 8 to use the tested BIOS code paths, what guarantees do we have of UEFI+CSM or legacy boots working? BR, Jani. [1] https://bugzilla.kernel.org/show_bug.cgi?id=47941#c96 -- Jani Nikula, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Cpufreq: Acquire read lock in the cpufreq_policy_restore() rather than write lock
On 11 September 2013 12:35, wrote: > From: Lan Tianyu > > In the cpufreq_policy_restore(), policy before system suspend is read from > from percpu's cpufreq_cpu_data_fallback. It's read operation rather than > write operation. So convert write lock to read lock > > Signed-off-by: Lan Tianyu > --- > drivers/cpufreq/cpufreq.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c > index 81ceea6..b762f9b 100644 > --- a/drivers/cpufreq/cpufreq.c > +++ b/drivers/cpufreq/cpufreq.c > @@ -912,11 +912,11 @@ static struct cpufreq_policy > *cpufreq_policy_restore(unsigned int cpu) > struct cpufreq_policy *policy; > unsigned long flags; > > - write_lock_irqsave(&cpufreq_driver_lock, flags); > + read_lock_irqsave(&cpufreq_driver_lock, flags); > > policy = per_cpu(cpufreq_cpu_data_fallback, cpu); > > - write_unlock_irqrestore(&cpufreq_driver_lock, flags); > + read_unlock_irqrestore(&cpufreq_driver_lock, flags); > > return policy; > } Acked-by: Viresh Kumar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
On Wed, 2013-09-11 at 11:45 +0300, Jani Nikula wrote: > Before plunging forward, have you observed any difference between the > boot modes? We have reports [1] that the backlight behaviour is > different with UEFI vs. UEFI+CSM or legacy boot. So I'm wondering if the > acpi_gbl_osi_data >= ACPI_OSI_WIN_8 check in patch 2/2 is the whole > story. > > Further, if we tell the BIOS we're Windows 8 to use the tested BIOS code > paths, what guarantees do we have of UEFI+CSM or legacy boots working? We have no evidence of Windows behaving differently based on the exposed firmware type. -- Matthew Garrett
[PATCH] ARM: S3C24XX: Fix configuration of gpio port sizes on S3C24XX.
Some GPIO line limits are incorrectly set which, for instance,
does not allow nRTS1 (GPH11) configuration on a S3C2416 chip.
Signed-off-by: José Miguel Gonçalves
---
arch/arm/mach-s3c24xx/include/mach/gpio.h | 10 +-
drivers/gpio/gpio-samsung.c |6 +++---
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-s3c24xx/include/mach/gpio.h
b/arch/arm/mach-s3c24xx/include/mach/gpio.h
index 1459156..a1435bc 100644
--- a/arch/arm/mach-s3c24xx/include/mach/gpio.h
+++ b/arch/arm/mach-s3c24xx/include/mach/gpio.h
@@ -31,17 +31,17 @@
* 2410 2412 2440 2443 2416
* 2442
*
- * A 23 22 25 16 25
- * B 11 11 11 11 9
- * C 16 15 16 16 16
+ * A 23 22 25 16 27
+ * B 11 11 11 11 11
+ * C 16 16 16 16 16
* D 16 16 16 16 16
* E 16 16 16 16 16
* F 88888
* G 16 16 16 16 8
- * H 11 11 915 15
+ * H 11 11 11 15 15
* J -- -- 13 16 --
* K -- -- -- -- 16
- * L -- -- -- 15 7
+ * L -- -- -- 15 14
* M -- -- -- 22
*/
diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
index 358a21c..29c428b 100644
--- a/drivers/gpio/gpio-samsung.c
+++ b/drivers/gpio/gpio-samsung.c
@@ -1053,7 +1053,7 @@ struct samsung_gpio_chip s3c24xx_gpios[] = {
.base = S3C2410_GPA(0),
.owner = THIS_MODULE,
.label = "GPIOA",
- .ngpio = 24,
+ .ngpio = 27,
.direction_input= s3c24xx_gpiolib_banka_input,
.direction_output = s3c24xx_gpiolib_banka_output,
},
@@ -1062,7 +1062,7 @@ struct samsung_gpio_chip s3c24xx_gpios[] = {
.base = S3C2410_GPB(0),
.owner = THIS_MODULE,
.label = "GPIOB",
- .ngpio = 16,
+ .ngpio = 11,
},
}, {
.chip = {
@@ -1107,7 +1107,7 @@ struct samsung_gpio_chip s3c24xx_gpios[] = {
.base = S3C2410_GPH(0),
.owner = THIS_MODULE,
.label = "GPIOH",
- .ngpio = 11,
+ .ngpio = 15,
},
},
/* GPIOS for the S3C2443 and later devices. */
--
1.7.10.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/
Re: [PATCH V3]hrtimer: Fix a performance regression by disable reprogramming in remove_hrtimer
On Mon, Sep 09, 2013 at 03:46:35PM +0200, Peter Zijlstra wrote:
> On Mon, Sep 09, 2013 at 03:30:44PM +0200, Peter Zijlstra wrote:
> > diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
> > index fa6964d..486c0ba 100644
> > --- a/drivers/idle/intel_idle.c
> > +++ b/drivers/idle/intel_idle.c
> > @@ -359,6 +359,14 @@ static int intel_idle(struct cpuidle_device *dev,
> > if (!(lapic_timer_reliable_states & (1 << (cstate
> > clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu);
> >
> > + current_thread_into()->status |= TS_POLLING;
> > +
> > + /*
> > +* Order against setting of TS_POLLING against the reading of
> > +* NEED_RESCHED, matched by resched_task().
> > +*/
> > + smp_mb();
> > +
> > if (!need_resched()) {
> >
> > __monitor((void *)¤t_thread_info()->flags, 0, 0);
> > @@ -367,6 +375,8 @@ static int intel_idle(struct cpuidle_device *dev,
> > __mwait(eax, ecx);
> > }
> >
> > + current_thread_into()->status &= ~TS_POLLING;
> > +
> > if (!(lapic_timer_reliable_states & (1 << (cstate
> > clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu);
>
> Hmm, arguably it would be better to set this from
> intel_idle_cpuidle_driver_init() and clear it whenever this goes away.
> Not sure how all that works, the cpuidle driver framework seems 'weird'.
OK, so I went over the idle stuff again, and we do set TS_POLLING like
stuff, it got hidden in current_{clr,set}_polling().
Still if that patch causes extra IPIs its bound to be broken in some
creative way.. I'll prod.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 3/5] mm: use mapcount for identifying zbud pages
Currently zbud pages do not have any flags set so it is not possible to
identify them during migration or compaction.
Implement PageZbud() by comparing page->_mapcount to -127 to distinguish
pages allocated by zbud. Just like PageBuddy() is implemented.
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Seth Jennings
---
include/linux/mm.h | 23 +++
mm/zbud.c |4
2 files changed, 27 insertions(+)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index f022460..b9ae6f2 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -440,6 +440,7 @@ static inline void init_page_count(struct page *page)
* efficiently by most CPU architectures.
*/
#define PAGE_BUDDY_MAPCOUNT_VALUE (-128)
+#define PAGE_ZBUD_MAPCOUNT_VALUE (-127)
static inline int PageBuddy(struct page *page)
{
@@ -458,6 +459,28 @@ static inline void __ClearPageBuddy(struct page *page)
atomic_set(&page->_mapcount, -1);
}
+#ifdef CONFIG_ZBUD
+static inline int PageZbud(struct page *page)
+{
+ return atomic_read(&page->_mapcount) == PAGE_ZBUD_MAPCOUNT_VALUE;
+}
+
+static inline void SetPageZbud(struct page *page)
+{
+ VM_BUG_ON(atomic_read(&page->_mapcount) != -1);
+ atomic_set(&page->_mapcount, PAGE_ZBUD_MAPCOUNT_VALUE);
+}
+
+static inline void ClearPageZbud(struct page *page)
+{
+ VM_BUG_ON(!PageZbud(page));
+ atomic_set(&page->_mapcount, -1);
+}
+#else
+PAGEFLAG_FALSE(Zbud)
+#endif
+
+
void put_page(struct page *page);
void put_pages_list(struct list_head *pages);
diff --git a/mm/zbud.c b/mm/zbud.c
index 1d5b26b..9be160c 100644
--- a/mm/zbud.c
+++ b/mm/zbud.c
@@ -197,7 +197,10 @@ static void get_zbud_page(struct zbud_header *zhdr)
static int put_zbud_page(struct zbud_header *zhdr)
{
struct page *page = virt_to_page(zhdr);
+ VM_BUG_ON(!PageZbud(page));
+
if (put_page_testzero(page)) {
+ ClearPageZbud(page);
free_hot_cold_page(page, 0);
return 1;
}
@@ -307,6 +310,7 @@ int zbud_alloc(struct zbud_pool *pool, int size, gfp_t gfp,
* don't increase the page count.
*/
zhdr = init_zbud_page(page);
+ SetPageZbud(page);
bud = FIRST;
found:
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/5] zbud: make freechunks a block local variable
Move freechunks variable in zbud_free() and zbud_alloc() to block-level
scope (from function scope).
Signed-off-by: Krzysztof Kozlowski
---
mm/zbud.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/mm/zbud.c b/mm/zbud.c
index 3f4be72..1d5b26b 100644
--- a/mm/zbud.c
+++ b/mm/zbud.c
@@ -267,7 +267,7 @@ void zbud_destroy_pool(struct zbud_pool *pool)
int zbud_alloc(struct zbud_pool *pool, int size, gfp_t gfp,
unsigned long *handle)
{
- int chunks, i, freechunks;
+ int chunks, i;
struct zbud_header *zhdr = NULL;
enum buddy bud;
struct page *page;
@@ -317,7 +317,7 @@ found:
if (zhdr->first_chunks == 0 || zhdr->last_chunks == 0) {
/* Add to unbuddied list */
- freechunks = num_free_chunks(zhdr);
+ int freechunks = num_free_chunks(zhdr);
list_add(&zhdr->buddy, &pool->unbuddied[freechunks]);
} else {
/* Add to buddied list */
@@ -349,7 +349,6 @@ found:
void zbud_free(struct zbud_pool *pool, unsigned long handle)
{
struct zbud_header *zhdr;
- int freechunks;
spin_lock(&pool->lock);
zhdr = handle_to_zbud_header(handle);
@@ -368,7 +367,7 @@ void zbud_free(struct zbud_pool *pool, unsigned long handle)
pool->pages_nr--;
} else {
/* Add to unbuddied list */
- freechunks = num_free_chunks(zhdr);
+ int freechunks = num_free_chunks(zhdr);
list_add(&zhdr->buddy, &pool->unbuddied[freechunks]);
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/5] mm: migrate zbud pages
Hi, Currently zbud pages are not movable and they cannot be allocated from CMA (Contiguous Memory Allocator) region. These patches add migration of zbud pages. The zbud migration code utilizes mapping so many exceptions to migrate code were added. This can be replaced for example with pin page control subsystem: http://article.gmane.org/gmane.linux.kernel.mm/105308 In such case the zbud migration code (zbud_migrate_page()) can be safely re-used. Patch "[PATCH 3/5] mm: use mapcount for identifying zbud pages" introduces PageZbud() function which identifies zbud pages by page->_mapcount. Dave Hansen proposed aliasing PG_zbud=PG_slab but in such case patch would be more intrusive. Any ideas for a better solution are welcome. Patch "[PATCH 4/5] mm: use indirect zbud handle and radix tree" changes zbud handle to support migration. Now the handle is an index in radix tree and zbud_map() maps it to a proper virtual address. This exposes race conditions, some of them are discussed already here: http://article.gmane.org/gmane.linux.kernel.mm/105988 Races are fixed by adding internal map count for each zbud handle. The map count is increased on each zbud_map() call. Some races between writeback and invalidate still exist. In such case a message can be seen in logs: zbud: error: could not lookup handle 13810 in tree Patches from discussion above may resolve this. I have considered using "pgoff_t offset" as handle but it prevented storing duplicate pages in zswap. This patch set is based on v3.11. Changes since v1: - 1. Rebased against v3.11. 2. Updated documentation of zbud_reclaim_page() to match usage of zbud page reference counters. 3. Split from patch 2/4 trivial change of scope of freechunks var to separate patch (3/5) (suggested by Seth Jennings). Changes and relation to patches "reclaiming zbud pages on migration and compaction": - This is continuation of my previous work: reclaiming zbud pages on migration and compaction. However current solution is completely different so I am not attaching previous changelog. Previous patches can be found here: * [RFC PATCH v2 0/4] mm: reclaim zbud pages on migration and compaction http://article.gmane.org/gmane.linux.kernel.mm/105153 * [RFC PATCH 0/4] mm: reclaim zbud pages on migration and compaction http://article.gmane.org/gmane.linux.kernel.mm/104801 One patch from previous work is re-used along with minor changes: "[PATCH 1/4] zbud: use page ref counter for zbud pages" * Add missing spin_unlock in zbud_reclaim_page(). * Decrease pool->pages_nr in zbud_free(), not when putting page. This also removes the need of holding lock while call to put_zbud_page(). Best regards, Krzysztof Kozlowski Krzysztof Kozlowski (5): zbud: use page ref counter for zbud pages zbud: make freechunks a block local variable mm: use mapcount for identifying zbud pages mm: use indirect zbud handle and radix tree mm: migrate zbud pages include/linux/mm.h | 23 ++ include/linux/zbud.h |3 +- mm/compaction.c |7 + mm/migrate.c | 17 +- mm/zbud.c| 573 -- mm/zswap.c | 28 ++- 6 files changed, 537 insertions(+), 114 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/5] mm: use indirect zbud handle and radix tree
Add radix tree to zbud pool and use indirect zbud handle as radix tree
index.
This allows migration of zbud pages while the handle used by zswap
remains untouched. Previously zbud handles were virtual addresses. This
imposed problem when page was migrated.
This change also exposes and fixes race condition between:
- zbud_reclaim_page() (called from zswap_frontswap_store())
and
- zbud_free() (called from zswap_frontswap_invalidate_page()).
This race was present already but additional locking and in-direct use
handle makes it frequent during high memory pressure.
Race typically looks like:
- thread 1: zbud_reclaim_page()
- thread 1: zswap_writeback_entry()
- zbud_map()
- thread 0: zswap_frontswap_invalidate_page()
- zbud_free()
- thread 1: read zswap_entry from memory or call zbud_unmap(), now on
invalid memory address
The zbud_reclaim_page() calls evict handler (zswap_writeback_entry())
without holding pool lock. The zswap_writeback_entry() reads
zswap_header from memory obtained from zbud_map() without holding
tree's lock. If invalidate happens during this time the zbud_free()
will remove handle from the tree.
The new map_count fields in zbud_header try to address this problem by
protecting handles from freeing.
Also the call to zbud_unmap() in zswap_writeback_entry() was moved
further - when the tree's lock could be obtained.
Signed-off-by: Krzysztof Kozlowski
---
include/linux/zbud.h |2 +-
mm/zbud.c| 313 +-
mm/zswap.c | 24 +++-
3 files changed, 280 insertions(+), 59 deletions(-)
diff --git a/include/linux/zbud.h b/include/linux/zbud.h
index 2571a5c..12d72df 100644
--- a/include/linux/zbud.h
+++ b/include/linux/zbud.h
@@ -16,7 +16,7 @@ int zbud_alloc(struct zbud_pool *pool, int size, gfp_t gfp,
void zbud_free(struct zbud_pool *pool, unsigned long handle);
int zbud_reclaim_page(struct zbud_pool *pool, unsigned int retries);
void *zbud_map(struct zbud_pool *pool, unsigned long handle);
-void zbud_unmap(struct zbud_pool *pool, unsigned long handle);
+int zbud_unmap(struct zbud_pool *pool, unsigned long handle);
u64 zbud_get_pool_size(struct zbud_pool *pool);
#endif /* _ZBUD_H_ */
diff --git a/mm/zbud.c b/mm/zbud.c
index 9be160c..795d56a 100644
--- a/mm/zbud.c
+++ b/mm/zbud.c
@@ -50,6 +50,7 @@
#include
#include
#include
+#include
#include
/*
@@ -69,6 +70,9 @@
#define NCHUNKS(PAGE_SIZE >> CHUNK_SHIFT)
#define ZHDR_SIZE_ALIGNED CHUNK_SIZE
+/* Empty handle, not yet allocated */
+#define HANDLE_EMPTY 0
+
/**
* struct zbud_pool - stores metadata for each zbud pool
* @lock: protects all pool fields and first|last_chunk fields of any
@@ -83,6 +87,10 @@
* @pages_nr: number of zbud pages in the pool.
* @ops: pointer to a structure of user defined operations specified at
* pool creation time.
+ * @page_tree: mapping handle->zbud_header for zbud_map and migration;
+ * many pools may exist so do not use the mapping->page_tree
+ * @last_handle: last handle calculated; used as starting point when searching
+ * for next handle in page_tree in zbud_alloc().
*
* This structure is allocated at pool creation time and maintains metadata
* pertaining to a particular zbud pool.
@@ -94,6 +102,8 @@ struct zbud_pool {
struct list_head lru;
u64 pages_nr;
struct zbud_ops *ops;
+ struct radix_tree_root page_tree;
+ unsigned long last_handle;
};
/*
@@ -103,12 +113,23 @@ struct zbud_pool {
* @lru: links the zbud page into the lru list in the pool
* @first_chunks: the size of the first buddy in chunks, 0 if free
* @last_chunks: the size of the last buddy in chunks, 0 if free
+ * @first_handle: handle to page stored in first buddy
+ * @last_handle: handle to page stored in last buddy
+ * @first_map_count: mapped count of page stored in first buddy
+ * @last_map_count:mapped count of page stored in last buddy
+ *
+ * When map count reaches zero the corresponding handle is removed
+ * from radix tree and cannot be used any longer.
*/
struct zbud_header {
struct list_head buddy;
struct list_head lru;
+ unsigned long first_handle;
+ unsigned long last_handle;
unsigned int first_chunks;
unsigned int last_chunks;
+ short int first_map_count;
+ short int last_map_count;
};
/*
@@ -135,38 +156,34 @@ static struct zbud_header *init_zbud_page(struct page
*page)
struct zbud_header *zhdr = page_address(page);
zhdr->first_chunks = 0;
zhdr->last_chunks = 0;
+ zhdr->first_handle = HANDLE_EMPTY;
+ zhdr->last_handle = HANDLE_EMPTY;
+ zhdr->first_map_count = 0;
+ zhdr->last_map_count = 0;
INIT_LIST_HEAD(&zhdr->buddy);
INIT_LIST_HEAD(&zhdr->lru);
return zhdr;
}
/*
- * Encodes the handle of a particular
[PATCH v2 1/5] zbud: use page ref counter for zbud pages
Use page reference counter for zbud pages. The ref counter replaces
zbud_header.under_reclaim flag and ensures that zbud page won't be freed
when zbud_free() is called during reclaim. It allows implementation of
additional reclaim paths.
The page count is incremented when:
- a handle is created and passed to zswap (in zbud_alloc()),
- user-supplied eviction callback is called (in zbud_reclaim_page()).
Signed-off-by: Krzysztof Kozlowski
Signed-off-by: Tomasz Stanislawski
Reviewed-by: Bob Liu
---
mm/zbud.c | 117 +
1 file changed, 64 insertions(+), 53 deletions(-)
diff --git a/mm/zbud.c b/mm/zbud.c
index ad1e781..3f4be72 100644
--- a/mm/zbud.c
+++ b/mm/zbud.c
@@ -109,7 +109,6 @@ struct zbud_header {
struct list_head lru;
unsigned int first_chunks;
unsigned int last_chunks;
- bool under_reclaim;
};
/*
@@ -138,16 +137,9 @@ static struct zbud_header *init_zbud_page(struct page
*page)
zhdr->last_chunks = 0;
INIT_LIST_HEAD(&zhdr->buddy);
INIT_LIST_HEAD(&zhdr->lru);
- zhdr->under_reclaim = 0;
return zhdr;
}
-/* Resets the struct page fields and frees the page */
-static void free_zbud_page(struct zbud_header *zhdr)
-{
- __free_page(virt_to_page(zhdr));
-}
-
/*
* Encodes the handle of a particular buddy within a zbud page
* Pool lock should be held as this function accesses first|last_chunks
@@ -188,6 +180,31 @@ static int num_free_chunks(struct zbud_header *zhdr)
return NCHUNKS - zhdr->first_chunks - zhdr->last_chunks - 1;
}
+/*
+ * Increases ref count for zbud page.
+ */
+static void get_zbud_page(struct zbud_header *zhdr)
+{
+ get_page(virt_to_page(zhdr));
+}
+
+/*
+ * Decreases ref count for zbud page and frees the page if it reaches 0
+ * (no external references, e.g. handles).
+ *
+ * Returns 1 if page was freed and 0 otherwise.
+ */
+static int put_zbud_page(struct zbud_header *zhdr)
+{
+ struct page *page = virt_to_page(zhdr);
+ if (put_page_testzero(page)) {
+ free_hot_cold_page(page, 0);
+ return 1;
+ }
+ return 0;
+}
+
+
/*
* API Functions
*/
@@ -273,6 +290,7 @@ int zbud_alloc(struct zbud_pool *pool, int size, gfp_t gfp,
bud = FIRST;
else
bud = LAST;
+ get_zbud_page(zhdr);
goto found;
}
}
@@ -284,6 +302,10 @@ int zbud_alloc(struct zbud_pool *pool, int size, gfp_t gfp,
return -ENOMEM;
spin_lock(&pool->lock);
pool->pages_nr++;
+ /*
+* We will be using zhdr instead of page, so
+* don't increase the page count.
+*/
zhdr = init_zbud_page(page);
bud = FIRST;
@@ -318,10 +340,11 @@ found:
* @pool: pool in which the allocation resided
* @handle:handle associated with the allocation returned by zbud_alloc()
*
- * In the case that the zbud page in which the allocation resides is under
- * reclaim, as indicated by the PG_reclaim flag being set, this function
- * only sets the first|last_chunks to 0. The page is actually freed
- * once both buddies are evicted (see zbud_reclaim_page() below).
+ * This function sets first|last_chunks to 0, removes zbud header from
+ * appropriate lists (LRU, buddied/unbuddied) and puts the reference count
+ * for it. The page is actually freed once both buddies are evicted
+ * (zbud_free() called on both handles or page reclaim in zbud_reclaim_page()
+ * below).
*/
void zbud_free(struct zbud_pool *pool, unsigned long handle)
{
@@ -337,19 +360,11 @@ void zbud_free(struct zbud_pool *pool, unsigned long
handle)
else
zhdr->first_chunks = 0;
- if (zhdr->under_reclaim) {
- /* zbud page is under reclaim, reclaim will free */
- spin_unlock(&pool->lock);
- return;
- }
-
/* Remove from existing buddy list */
list_del(&zhdr->buddy);
if (zhdr->first_chunks == 0 && zhdr->last_chunks == 0) {
- /* zbud page is empty, free */
list_del(&zhdr->lru);
- free_zbud_page(zhdr);
pool->pages_nr--;
} else {
/* Add to unbuddied list */
@@ -357,6 +372,7 @@ void zbud_free(struct zbud_pool *pool, unsigned long handle)
list_add(&zhdr->buddy, &pool->unbuddied[freechunks]);
}
+ put_zbud_page(zhdr);
spin_unlock(&pool->lock);
}
@@ -378,21 +394,23 @@ void zbud_free(struct zbud_pool *pool, unsigned long
handle)
* To avoid these, this is how zbud_reclaim_page() should be called:
* The user detects a page should be reclaimed and calls zbud_reclaim_page().
- * zbud_reclaim_page() will remove a zbud page from the pool LRU list and call
- * the user-defined evicti
[PATCH v2 5/5] mm: migrate zbud pages
Add migration support for zbud. This allows adding __GFP_MOVABLE flag
when allocating zbud pages and effectively CMA pool can be used for
zswap.
zbud pages are not movable and are not stored under any LRU (except
zbud's LRU). PageZbud flag is used in isolate_migratepages_range() to
grab zbud pages and pass them later for migration.
page->private field is used for storing pointer to zbud_pool.
This pointer to zbud_pool is needed during migration for locking the
pool and accessing radix tree.
The zbud migration code utilizes mapping so many exceptions to migrate
code was added. It can be replaced for example with pin page control
subsystem:
http://article.gmane.org/gmane.linux.kernel.mm/105308
In such case the zbud migration code (zbud_migrate_page()) can be safely
re-used.
Signed-off-by: Krzysztof Kozlowski
---
include/linux/zbud.h |1 +
mm/compaction.c |7 +++
mm/migrate.c | 17 +-
mm/zbud.c| 164 +++---
mm/zswap.c |4 +-
5 files changed, 179 insertions(+), 14 deletions(-)
diff --git a/include/linux/zbud.h b/include/linux/zbud.h
index 12d72df..3bc2e38 100644
--- a/include/linux/zbud.h
+++ b/include/linux/zbud.h
@@ -11,6 +11,7 @@ struct zbud_ops {
struct zbud_pool *zbud_create_pool(gfp_t gfp, struct zbud_ops *ops);
void zbud_destroy_pool(struct zbud_pool *pool);
+int zbud_put_page(struct page *page);
int zbud_alloc(struct zbud_pool *pool, int size, gfp_t gfp,
unsigned long *handle);
void zbud_free(struct zbud_pool *pool, unsigned long handle);
diff --git a/mm/compaction.c b/mm/compaction.c
index 05ccb4c..8acd198 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -534,6 +534,12 @@ isolate_migratepages_range(struct zone *zone, struct
compact_control *cc,
goto next_pageblock;
}
+ if (PageZbud(page)) {
+ BUG_ON(PageLRU(page));
+ get_page(page);
+ goto isolated;
+ }
+
/*
* Check may be lockless but that's ok as we recheck later.
* It's possible to migrate LRU pages and balloon pages
@@ -601,6 +607,7 @@ isolate_migratepages_range(struct zone *zone, struct
compact_control *cc,
/* Successfully isolated */
cc->finished_update_migrate = true;
del_page_from_lru_list(page, lruvec, page_lru(page));
+isolated:
list_add(&page->lru, migratelist);
cc->nr_migratepages++;
nr_isolated++;
diff --git a/mm/migrate.c b/mm/migrate.c
index 6f0c244..5254eb2 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include
@@ -105,6 +106,8 @@ void putback_movable_pages(struct list_head *l)
page_is_file_cache(page));
if (unlikely(balloon_page_movable(page)))
balloon_page_putback(page);
+ else if (unlikely(PageZbud(page)))
+ zbud_put_page(page);
else
putback_lru_page(page);
}
@@ -832,6 +835,10 @@ static int __unmap_and_move(struct page *page, struct page
*newpage,
goto skip_unmap;
}
+ if (unlikely(PageZbud(page))) {
+ remap_swapcache = 0;
+ goto skip_unmap;
+ }
/* Establish migration ptes or remove ptes */
try_to_unmap(page, TTU_MIGRATION|TTU_IGNORE_MLOCK|TTU_IGNORE_ACCESS);
@@ -902,13 +909,19 @@ out:
list_del(&page->lru);
dec_zone_page_state(page, NR_ISOLATED_ANON +
page_is_file_cache(page));
- putback_lru_page(page);
+ if (unlikely(PageZbud(page)))
+ zbud_put_page(page);
+ else
+ putback_lru_page(page);
}
/*
* Move the new page to the LRU. If migration was not successful
* then this will free the page.
*/
- putback_lru_page(newpage);
+ if (unlikely(PageZbud(newpage)))
+ zbud_put_page(newpage);
+ else
+ putback_lru_page(newpage);
if (result) {
if (rc)
*result = rc;
diff --git a/mm/zbud.c b/mm/zbud.c
index 795d56a..de8132d 100644
--- a/mm/zbud.c
+++ b/mm/zbud.c
@@ -51,6 +51,8 @@
#include
#include
#include
+#include
+#include
#include
/*
@@ -211,17 +213,9 @@ static void get_zbud_page(struct zbud_header *zhdr)
*
* Returns 1 if page was freed and 0 otherwise.
*/
-static int put_zbud_page(struct zbud_header *zhdr)
+static inline int put_zbud_page(struct zbud_header *zhdr)
{
- struct page *page = virt_to_page(zhdr);
- VM_BUG_ON(!PageZbud(page));
-
- if (put_page_testzero(page)) {
- ClearPageZbud(page);
-
Re: [117/251] radeon kms: do not flush uninitialized hotplug work
On (09/11/13 00:29), Steven Rostedt wrote:
> 3.6.11.9-rc1 stable review patch.
> If anyone has any objections, please let me know.
>
Hello,
Steven, this patch makes r100_irq_process() unhappy and there
is additional fix on top of this patch.
upstream 27c505ca84e164ec66ad55dcf3f5befaac83f10a
I'll prepare a proper patch for stable.
-ss
> --
>
> From: Sergey Senozhatsky
>
> [ Upstream commit a01c34f72e7cd2624570818f579b5ab464f93de2 ]
>
> Fix a warning from lockdep caused by calling flush_work() for
> uninitialized hotplug work. Initialize hotplug_work, audio_work
> and reset_work upon successful radeon_irq_kms_init() completion
> and thus perform hotplug flush_work only when rdev->irq.installed
> is true.
>
> [4.790019] [drm] Loading CEDAR Microcode
> [4.790943] r600_cp: Failed to load firmware "radeon/CEDAR_smc.bin"
> [4.791152] [drm:evergreen_startup] *ERROR* Failed to load firmware!
> [4.791330] radeon :01:00.0: disabling GPU acceleration
>
> [4.792633] INFO: trying to register non-static key.
> [4.792792] the code is fine but needs lockdep annotation.
> [4.792953] turning off the locking correctness validator.
>
> [4.793114] CPU: 2 PID: 1 Comm: swapper/0 Not tainted
> 3.11.0-rc0-dbg-10676-gfe56456-dirty #1816
> [4.793314] Hardware name: Acer Aspire 5741G/Aspire 5741G
> , BIOS V1.20 02/08/2011
> [4.793507] 821fd810 8801530b9a18 8160434e
> 0002
> [4.794155] 8801530b9ad8 810b8404 8801530b0798
> 8801530b
> [4.794789] 8801530b9b00 0046 04c0
>
> [4.795418] Call Trace:
> [4.795573] [] dump_stack+0x4e/0x82
> [4.795731] [] __lock_acquire+0x1a64/0x1d30
> [4.795893] [] ? dev_vprintk_emit+0x50/0x60
> [4.796034] [] lock_acquire+0xa4/0x200
> [4.796216] [] ? flush_work+0x5/0x280
> [4.796375] [] flush_work+0x3d/0x280
> [4.796520] [] ? flush_work+0x5/0x280
> [4.796682] [] ? trace_hardirqs_on_caller+0xfd/0x1c0
> [4.796862] [] ? delay_tsc+0x95/0xf0
> [4.797024] [] radeon_irq_kms_fini+0x2b/0x70
> [4.797186] [] evergreen_init+0x2a9/0x2e0
> [4.797347] [] radeon_device_init+0x5ef/0x700
> [4.797511] [] ? pci_find_capability+0x47/0x50
> [4.797672] [] radeon_driver_load_kms+0x8d/0x150
> [4.797843] [] drm_get_pci_dev+0x166/0x280
> [4.798007] [] ? kfree+0xf5/0x2e0
> [4.798168] [] ? radeon_pci_probe+0x98/0xd0
> [4.798329] [] radeon_pci_probe+0xaa/0xd0
> [4.798489] [] pci_device_probe+0x84/0xe0
> [4.798644] [] driver_probe_device+0x76/0x240
> [4.798805] [] __driver_attach+0x93/0xa0
> [4.798948] [] ? __device_attach+0x40/0x40
> [4.799126] [] bus_for_each_dev+0x6b/0xb0
> [4.799272] [] driver_attach+0x1e/0x20
> [4.799434] [] bus_add_driver+0x1f0/0x280
> [4.799596] [] driver_register+0x74/0x150
> [4.799758] [] __pci_register_driver+0x5d/0x60
> [4.799936] [] ? ttm_init+0x67/0x67
> [4.800081] [] drm_pci_init+0x115/0x130
> [4.800243] [] ? ttm_init+0x67/0x67
> [4.800405] [] radeon_init+0x9c/0xba
> [4.800586] [] do_one_initcall+0xfa/0x150
> [4.800746] [] ? parse_args+0x120/0x330
> [4.800909] [] kernel_init_freeable+0x111/0x191
> [4.801052] [] ? do_early_param+0x88/0x88
> [4.801233] [] ? rest_init+0x140/0x140
> [4.801393] [] kernel_init+0xe/0x180
> [4.801556] [] ret_from_fork+0x7c/0xb0
> [4.801718] [] ? rest_init+0x140/0x140
>
> Signed-off-by: Sergey Senozhatsky
> Signed-off-by: Alex Deucher
> Cc: sta...@vger.kernel.org
> Signed-off-by: Steven Rostedt
> ---
> drivers/gpu/drm/radeon/radeon_irq_kms.c |9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c
> b/drivers/gpu/drm/radeon/radeon_irq_kms.c
> index 443bd49..4bc6be5 100644
> --- a/drivers/gpu/drm/radeon/radeon_irq_kms.c
> +++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c
> @@ -243,9 +243,6 @@ int radeon_irq_kms_init(struct radeon_device *rdev)
> {
> int r = 0;
>
> - INIT_WORK(&rdev->hotplug_work, radeon_hotplug_work_func);
> - INIT_WORK(&rdev->audio_work, r600_audio_update_hdmi);
> -
> spin_lock_init(&rdev->irq.lock);
> r = drm_vblank_init(rdev->ddev, rdev->num_crtc);
> if (r) {
> @@ -267,6 +264,10 @@ int radeon_irq_kms_init(struct radeon_device *rdev)
> rdev->irq.installed = false;
> return r;
> }
> +
> + INIT_WORK(&rdev->hotplug_work, radeon_hotplug_work_func);
> + INIT_WORK(&rdev->audio_work, r600_audio_update_hdmi);
> +
> DRM_INFO("radeon: irq initialized.\n");
> return 0;
> }
> @@ -286,8 +287,8 @@ void radeon_irq_kms_fini(struct radeon_device *rdev)
> rdev->irq.installed = false;
> if (rdev->msi_enabled)
> pci_disable_msi(rdev->pdev);
> + flush_work_sync(&rde
Re: [PATCH 2/2] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
On mer., 2013-09-11 at 08:45 +, Matthew Garrett wrote: > On Wed, 2013-09-11 at 11:45 +0300, Jani Nikula wrote: > > > Before plunging forward, have you observed any difference between the > > boot modes? We have reports [1] that the backlight behaviour is > > different with UEFI vs. UEFI+CSM or legacy boot. So I'm wondering if the > > acpi_gbl_osi_data >= ACPI_OSI_WIN_8 check in patch 2/2 is the whole > > story. > > > > Further, if we tell the BIOS we're Windows 8 to use the tested BIOS code > > paths, what guarantees do we have of UEFI+CSM or legacy boots working? > > We have no evidence of Windows behaving differently based on the exposed > firmware type. > I do have an X230 which boots fine using pure UEFI or UEFI+CSM (and I guess I can try booting it with a grml for pure legacy), so I can do tests if needed. Regards, -- Yves-Alexis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Deadlock in fb and tty
Hi, I'm consistently and constantly hitting a deadlock. console_callback in drivers/tty/vt/vt.c does: console_lock() and then calls: do_blank_screen, which calls: vc->vc_sw->con_blank(..) which can be a pointer to the function: fbcon_blank in video/console/fbcon.c. This is missing a WARN_CONSOLE_UNLOCKED. This calls: fbcon_generic_blank which does lock_fb_info(info) So we have a console_lock() followed by a lock_fb_info(info). Now if while that is running, we have an ioctl call: do_fb_ioctl in drivers/video/fbmem.c which does: if (!lock_fb_info(info)) return -ENODEV; console_lock(); So it tries to acquire the same locks in the reverse order. This deadlocks consistently for me. (I'm also curious why I'm hitting this continually, when everyone else seems to be okay.) I understand that this is really difficult to fix, but if anyone has even a suggestion on how to hack it to make it work for me, I'd be very grateful. Thank you, John Tapsell -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: dgnc: fix potential format string flaw
On Tue, Sep 10, 2013 at 10:19:17PM -0700, Kees Cook wrote: > In the former case, format characters will get processed by the > sprintf logic. In the latter, they are printed as-is. In this specific > case, if there was a way to inject strings like "ohai %n" into the > msgbuf string, the former would actually attempt to resolve the %n. In > the simple case, this could lead to Oopses, and in the unlucky case, > it could allow arbitrary memory writing and execution control. > > http://en.wikipedia.org/wiki/Uncontrolled_format_string The kernel ignores %n so hopefully it can't actually write to memory. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 00/12] One more attempt at useful kernel lockdown
於 二，2013-09-10 於 18:26 +，Matthew Garrett 提到：
> On Tue, 2013-09-10 at 14:23 -0300, Henrique de Moraes Holschuh wrote:
> > On Tue, 10 Sep 2013, Matthew Garrett wrote:
> > > That's why modern systems require signed firmware updates.
> >
> > Linux doesn't. Is someone working on adding signature support to the
> > runtime firmware loader?
>
> It'd be simple to do so, but so far the model appears to be that devices
> that expect signed firmware enforce that themselves.
>
> --
> Matthew Garrett
> NrybXǧv^){.n+{y^nrzh& Gh(階ݢj"mzޖfh~m
Takashi has a implementation of firmware check:
[PATCH RFC v2 0/4] Add firmware signature file check
https://lkml.org/lkml/2012/11/8/343
Thanks
Joey Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Xen-devel] [PATCH v1 0/5] xen/PMU: PMU support for Xen PV guests
On 10/09/13 16:31, Boris Ostrovsky wrote: > This is the Linux side of Xen PMU support for PV guests, including dom0. Only > kernel changes are here, toolstack patch will be provided separately. > > Here is description from the hypervisor patch submission that applies to this > series as well: > > This version has following limitations: > * For accurate profiling of dom0/Xen dom0 VCPUs should be pinned. > * Hypervisor code is only profiled on processors that have running dom0 VCPUs > on them. > * No backtrace support. These are some pretty significant limitations. Is there a plan for how to remove them? David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/38] ARM: ux500: Remove PrimeCell IDs from Nomadik I2C DT nodes
On Wed, Sep 11, 2013 at 10:19 AM, Lee Jones wrote: > On Wed, 11 Sep 2013, Linus Walleij wrote: > >> Weird, yeah there is something wrong on Torvalds' HEAD, with >> earlyprint it says: >> >> Uncompressing Linux... done, booting the kernel. >> Error: unrecognized/unsupported processor variant (0x412fc091). >> This comes from arch/arm/kernel/head-common.S >> >> I'm trying to bisect and find out what is causing this... > > Ah nice. Keep us informed of any progress. No it was something transient, after a clean rebuild it boots just fine. :-/ I'll see if I can boot the same uImage on the Snowball too. Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net] tuntap: correctly handle error in tun_set_iff()
On Wed, Sep 11, 2013 at 04:24:05PM +0800, Jason Wang wrote: > Commit c8d68e6be1c3b242f1c598595830890b65cea64a (tuntap: multiqueue support) > only call free_netdev() on err in tun_set_iff(). This causes several issues: > > - memory of tun security were leaked Not just tun security - sock reference too (didn't detach) > - use after free since the flow gc timer was not deleted and the tfile were > not > detached > > This patch solves the above issues. > > Reported-by: Wannes Rombouts > Cc: Michael S. Tsirkin > Signed-off-by: Jason Wang > --- > The patch were also needed for stable 3.8+. > --- > drivers/net/tun.c |9 +++-- > 1 files changed, 7 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/tun.c b/drivers/net/tun.c > index a639de8..e5fb5d3 100644 > --- a/drivers/net/tun.c > +++ b/drivers/net/tun.c > @@ -1641,11 +1641,11 @@ static int tun_set_iff(struct net *net, struct file > *file, struct ifreq *ifr) > INIT_LIST_HEAD(&tun->disabled); > err = tun_attach(tun, file, false); > if (err < 0) > - goto err_free_dev; > + goto err_free_flow; > > err = register_netdevice(tun->dev); > if (err < 0) > - goto err_free_dev; > + goto err_detach; > > if (device_create_file(&tun->dev->dev, &dev_attr_tun_flags) || > device_create_file(&tun->dev->dev, &dev_attr_owner) || > @@ -1689,6 +1689,11 @@ static int tun_set_iff(struct net *net, struct file > *file, struct ifreq *ifr) > strcpy(ifr->ifr_name, tun->dev->name); > return 0; > > +err_detach: > + tun_detach_all(dev); > +err_free_flow: > + tun_flow_uninit(tun); > + security_tun_dev_free_security(tun->security); This bit looks wrong: if flow_init fails, we need security_tun_dev_free_security, don't we? I think we need: +err_free_sec: security_tun_dev_free_security(tun->security); and goto here on flow_init failures. > err_free_dev: Pls shift this one 1 space left for consistency. > free_netdev(dev); > return err; > -- > 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 11/13] xen: introduce xen_alloc/free_coherent_pages
On Mon, Sep 09, 2013 at 05:46:59PM +0100, Stefano Stabellini wrote:
> On Mon, 9 Sep 2013, Catalin Marinas wrote:
> > >>> They could also happen in a DomU if we assign a physical device to it
> > >>> (and an SMMU is not available).
> > >>
> > >> The problem is that you don't necessarily know one kind of coherency you
> > >> know for a physical device. As I said, we plan to do this DT-driven.
> > >
> > > OK, but if I call arm64_swiotlb_dma_ops.alloc passing the right
> > > arguments to it, I should be able to get the right coherency for the
> > > right device, correct?
> >
> > I think it needs a bit more work on the Xen part. Basically
> > dma_alloc_attrs() calls get_dma_ops() to obtain the best DMA operations
> > for a device. arm64_swiotlb_dma_ops is just the default implementation
> > and I'll add a _noncoherent variant as well. Default dma_ops will be
> > set to one of these during boot. But a device is also allowed to have
> > its own dev->archdata.dma_ops, set via set_dma_ops().
> >
> > So even if you set the default dma_ops to Xen ops, you may not get them
> > via dma_alloc_coherent(). I don't see any easier solution other than
> > patching the dma_alloc_attrs() function to issue a Hyp call after the
> > memory has been allocated with the get_dma_ops()->alloc(). But I don't
> > like this either.
>
> I see. This problem affects arch/arm as well.
> Either we add an if (!xen_domain()) in get_dma_ops, or we could make
> get_dma_ops a function pointer and let people overwrite it.
> See below the first option implemented for arch/arm on top of the
> swiotlb series:
>
>
> diff --git a/arch/arm/include/asm/dma-mapping.h
> b/arch/arm/include/asm/dma-mapping.h
> index 7d6e4f9..0b8b5e4 100644
> --- a/arch/arm/include/asm/dma-mapping.h
> +++ b/arch/arm/include/asm/dma-mapping.h
> @@ -12,6 +12,8 @@
> #include
> #include
>
> +#include
> +
> #define DMA_ERROR_CODE (~0)
> extern struct dma_map_ops *dma_ops;
> extern struct dma_map_ops arm_dma_ops;
> @@ -19,7 +21,7 @@ extern struct dma_map_ops arm_coherent_dma_ops;
>
> static inline struct dma_map_ops *get_dma_ops(struct device *dev)
> {
> - if (dev && dev->archdata.dma_ops)
> + if (!xen_domain() && dev && dev->archdata.dma_ops)
> return dev->archdata.dma_ops;
> return dma_ops;
> }
> diff --git a/arch/arm/include/asm/xen/page-coherent.h
> b/arch/arm/include/asm/xen/page-coherent.h
> index af2cf8d..c2232fe 100644
> --- a/arch/arm/include/asm/xen/page-coherent.h
> +++ b/arch/arm/include/asm/xen/page-coherent.h
> @@ -9,6 +9,8 @@ static inline void *xen_alloc_coherent_pages(struct device
> *hwdev, size_t size,
> dma_addr_t *dma_handle, gfp_t flags,
> struct dma_attrs *attrs)
> {
> + if (hwdev && hwdev->archdata.dma_ops)
> + return hwdev->archdata.dma_ops->alloc(hwdev, size, dma_handle,
> flags, attrs);
> return arm_dma_ops.alloc(hwdev, size, dma_handle, flags, attrs);
I still don't like xen digging into the archdata internals. What about:
diff --git a/arch/arm/include/asm/dma-mapping.h
b/arch/arm/include/asm/dma-mapping.h
index 5b579b9..5fa472c 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -15,13 +15,20 @@
extern struct dma_map_ops arm_dma_ops;
extern struct dma_map_ops arm_coherent_dma_ops;
-static inline struct dma_map_ops *get_dma_ops(struct device *dev)
+static inline struct dma_map_ops *__get_dma_ops(struct device *dev)
{
if (dev && dev->archdata.dma_ops)
return dev->archdata.dma_ops;
return &arm_dma_ops;
}
+static inline struct dma_map_ops *get_dma_ops(struct device *dev)
+{
+ if (xen_domain())
+ return xen_dma_ops;
+ return __get_dma_ops(dev);
+}
+
static inline void set_dma_ops(struct device *dev, struct dma_map_ops *ops)
{
BUG_ON(!dev);
@@ -32,7 +39,7 @@ static inline void set_dma_ops(struct device *dev, struct
dma_map_ops *ops)
static inline int dma_set_mask(struct device *dev, u64 mask)
{
- return get_dma_ops(dev)->set_dma_mask(dev, mask);
+ return __get_dma_ops(dev)->set_dma_mask(dev, mask);
}
#ifdef __arch_page_to_dma
And in xen_alloc_coherent_pages():
return __get_dma_ops(dev).alloc(...);
Alternatively, add the xen_domain() check in dma_alloc_attrs() instead
of get_dma_ops() (and other functions like map_sg etc.)
--
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 1/2] hwmon: (lm90) Add power control
On 09/10/2013 08:11 PM, Mark Brown wrote: > * PGP Signed by an unknown key > > On Tue, Sep 10, 2013 at 07:29:40PM +0800, Wei Ni wrote: > >> On my platform, it use palmas-regulator.c, ldo6 for this lm90 power >> rail. I checked this driver, it will handle ramp_delay except LDOx. >> Since I'm not familiar with this palmas device and driver, so do you >> mean I can set regulator-ramp-delay property in the DT for ldo6, but I >> really don't know what value should I set :( > > Laxman just submitted a patch adding the ramp delay information which I > applied. It seems like this is just a hack for your board and can > therefore be removed? Oh, yes, it seems the patches is Laxman's [PATCH 1/2] regulator: palmas: configure enable time for LDOs. Thanks, I will check it, and remove the delay in my next patch. Wei. > > * Unknown Key > * 0x7EA229BD > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net] tuntap: correctly handle error in tun_set_iff()
- Original Message - > On Wed, Sep 11, 2013 at 04:24:05PM +0800, Jason Wang wrote: > > Commit c8d68e6be1c3b242f1c598595830890b65cea64a (tuntap: multiqueue > > support) > > only call free_netdev() on err in tun_set_iff(). This causes several > > issues: > > > > - memory of tun security were leaked > > Not just tun security - sock reference too (didn't detach) > Yes, I mention it in the next item. > > - use after free since the flow gc timer was not deleted and the tfile were > > not > > detached > > > > This patch solves the above issues. > > > > Reported-by: Wannes Rombouts > > Cc: Michael S. Tsirkin > > Signed-off-by: Jason Wang > > --- > > The patch were also needed for stable 3.8+. > > --- > > drivers/net/tun.c |9 +++-- > > 1 files changed, 7 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/net/tun.c b/drivers/net/tun.c > > index a639de8..e5fb5d3 100644 > > --- a/drivers/net/tun.c > > +++ b/drivers/net/tun.c > > @@ -1641,11 +1641,11 @@ static int tun_set_iff(struct net *net, struct file > > *file, struct ifreq *ifr) > > INIT_LIST_HEAD(&tun->disabled); > > err = tun_attach(tun, file, false); > > if (err < 0) > > - goto err_free_dev; > > + goto err_free_flow; > > > > err = register_netdevice(tun->dev); > > if (err < 0) > > - goto err_free_dev; > > + goto err_detach; > > > > if (device_create_file(&tun->dev->dev, &dev_attr_tun_flags) || > > device_create_file(&tun->dev->dev, &dev_attr_owner) || > > @@ -1689,6 +1689,11 @@ static int tun_set_iff(struct net *net, struct file > > *file, struct ifreq *ifr) > > strcpy(ifr->ifr_name, tun->dev->name); > > return 0; > > > > +err_detach: > > + tun_detach_all(dev); > > +err_free_flow: > > + tun_flow_uninit(tun); > > + security_tun_dev_free_security(tun->security); > > This bit looks wrong: if flow_init fails, we > need security_tun_dev_free_security, don't we? > I think we need: > +err_free_sec: security_tun_dev_free_security(tun->security); > and goto here on flow_init failures. tun_flow_init() always succeed. So we're ok here. > > > err_free_dev: > > Pls shift this one 1 space left for consistency. > Ok. > > free_netdev(dev); > > return err; > > -- > > 1.7.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/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 RESEND 1/2] i2c: prepare runtime PM support for I2C client devices
On Wed, Sep 11, 2013 at 09:01:16AM +0800, Aaron Lu wrote: > Looks like, it all boils down to how many I2C devices should be allowed > for runtime PM by default and how many I2C devices should be forbidden. > , and then we allow/forbid runtime PM for the majority case in I2C core > while individual driver can still forbid/allow it in their own code. > So if the majority case is runtime PM should be allowed by default, I'm > also OK to not forbid runtime PM for I2C client device in I2C core. My > original intention to forbid runtime PM by default is to make sure no > adverse effect would occur to some I2C devices that used to work well > before runtime PM. The really big problem here is that there are I2C devices currently using runtime PM quite happily and forbidding it by default will break them. In general though requiring userspace to manually activate power saving features isn't going to make people happy. signature.asc Description: Digital signature
[080/251] ARM: 7722/1: zImage: Convert 32bits memory size and address from ATAG to 64bits DTB
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Gregory CLEMENT
[ Upstream commit faefd550c45d8d314e8f260f21565320355c947f ]
When CONFIG_ARM_APPENDED_DTB is selected, if the bootloader provides
an ATAG_MEM it replaces the memory size and the memory address in the
memory node of the device tree. In the case of a system which can
handle more than 4GB, the memory node cell size is 4: each data
(memory size and memory address) are 64 bits and then use 2 cells.
The current code in atags_to_fdt.c made the assumption of a cell size
of 2 (one cell for the memory size and one cell for the memory
address), this leads to an improper write of the data and ends with a
boot hang.
This patch writes the memory size and the memory address on the memory
node in the device tree depending of the size of the memory node (32
bits or 64 bits).
It has been tested in the 2 cases:
- with a dtb using skeleton.dtsi
- and with a dtb using skeleton64.dtsi
Signed-off-by: Gregory CLEMENT
Acked-by: Nicolas Pitre
Signed-off-by: Russell King
Signed-off-by: Steven Rostedt
---
arch/arm/boot/compressed/atags_to_fdt.c | 44 ++-
1 file changed, 38 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/compressed/atags_to_fdt.c
b/arch/arm/boot/compressed/atags_to_fdt.c
index aabc02a..d1153c8 100644
--- a/arch/arm/boot/compressed/atags_to_fdt.c
+++ b/arch/arm/boot/compressed/atags_to_fdt.c
@@ -53,6 +53,17 @@ static const void *getprop(const void *fdt, const char
*node_path,
return fdt_getprop(fdt, offset, property, len);
}
+static uint32_t get_cell_size(const void *fdt)
+{
+ int len;
+ uint32_t cell_size = 1;
+ const uint32_t *size_len = getprop(fdt, "/", "#size-cells", &len);
+
+ if (size_len)
+ cell_size = fdt32_to_cpu(*size_len);
+ return cell_size;
+}
+
static void merge_fdt_bootargs(void *fdt, const char *fdt_cmdline)
{
char cmdline[COMMAND_LINE_SIZE];
@@ -95,9 +106,11 @@ static void merge_fdt_bootargs(void *fdt, const char
*fdt_cmdline)
int atags_to_fdt(void *atag_list, void *fdt, int total_space)
{
struct tag *atag = atag_list;
- uint32_t mem_reg_property[2 * NR_BANKS];
+ /* In the case of 64 bits memory size, need to reserve 2 cells for
+* address and size for each bank */
+ uint32_t mem_reg_property[2 * 2 * NR_BANKS];
int memcount = 0;
- int ret;
+ int ret, memsize;
/* make sure we've got an aligned pointer */
if ((u32)atag_list & 0x3)
@@ -137,8 +150,25 @@ int atags_to_fdt(void *atag_list, void *fdt, int
total_space)
continue;
if (!atag->u.mem.size)
continue;
- mem_reg_property[memcount++] =
cpu_to_fdt32(atag->u.mem.start);
- mem_reg_property[memcount++] =
cpu_to_fdt32(atag->u.mem.size);
+ memsize = get_cell_size(fdt);
+
+ if (memsize == 2) {
+ /* if memsize is 2, that means that
+* each data needs 2 cells of 32 bits,
+* so the data are 64 bits */
+ uint64_t *mem_reg_prop64 =
+ (uint64_t *)mem_reg_property;
+ mem_reg_prop64[memcount++] =
+ cpu_to_fdt64(atag->u.mem.start);
+ mem_reg_prop64[memcount++] =
+ cpu_to_fdt64(atag->u.mem.size);
+ } else {
+ mem_reg_property[memcount++] =
+ cpu_to_fdt32(atag->u.mem.start);
+ mem_reg_property[memcount++] =
+ cpu_to_fdt32(atag->u.mem.size);
+ }
+
} else if (atag->hdr.tag == ATAG_INITRD2) {
uint32_t initrd_start, initrd_size;
initrd_start = atag->u.initrd.start;
@@ -150,8 +180,10 @@ int atags_to_fdt(void *atag_list, void *fdt, int
total_space)
}
}
- if (memcount)
- setprop(fdt, "/memory", "reg", mem_reg_property, 4*memcount);
+ if (memcount) {
+ setprop(fdt, "/memory", "reg", mem_reg_property,
+ 4 * memcount * memsize);
+ }
return fdt_pack(fdt);
}
--
1.7.10.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 v2 6/9] x86, acpi: Support allocate memory from bottom upwards in acpi_initrd_override().
During early boot, if the bottom up mode is set, just
try allocating bottom up from the end of kernel image,
and if that fails, do normal top down allocation.
So in function acpi_initrd_override(), we add the
above logic.
Signed-off-by: Tang Chen
Reviewed-by: Zhang Yanfei
---
drivers/acpi/osl.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index e5f416c..978dcfa 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -632,6 +632,15 @@ void __init acpi_initrd_override(void *data, size_t size)
if (table_nr == 0)
return;
+ if (memblock_direction_bottom_up()) {
+ acpi_tables_addr = memblock_alloc_bottom_up(
+ MEMBLOCK_ALLOC_ACCESSIBLE,
+ max_low_pfn_mapped << PAGE_SHIFT,
+ all_tables_size, PAGE_SIZE);
+ if (acpi_tables_addr)
+ goto success;
+ }
+
acpi_tables_addr =
memblock_find_in_range(0, max_low_pfn_mapped << PAGE_SHIFT,
all_tables_size, PAGE_SIZE);
@@ -639,6 +648,8 @@ void __init acpi_initrd_override(void *data, size_t size)
WARN_ON(1);
return;
}
+
+success:
/*
* Only calling e820_add_reserve does not work and the
* tables are invalid (memory got used) later.
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 7/9] x86, acpi, crash, kdump: Do reserve_crashkernel() after SRAT is parsed.
Memory reserved for crashkernel could be large. So we should not allocate this memory bottom up from the end of kernel image. When SRAT is parsed, we will be able to know whihc memory is hotpluggable, and we can avoid allocating this memory for the kernel. So reorder reserve_crashkernel() after SRAT is parsed. Signed-off-by: Tang Chen Reviewed-by: Zhang Yanfei --- arch/x86/kernel/setup.c |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index 7372be7..fa56a57 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -1130,8 +1130,6 @@ void __init setup_arch(char **cmdline_p) acpi_initrd_override((void *)initrd_start, initrd_end - initrd_start); #endif - reserve_crashkernel(); - vsmp_init(); io_delay_init(); @@ -1146,6 +1144,12 @@ void __init setup_arch(char **cmdline_p) initmem_init(); memblock_find_dma_reserve(); + /* +* Reserve memory for crash kernel after SRAT is parsed so that it +* won't consume hotpluggable memory. +*/ + reserve_crashkernel(); + #ifdef CONFIG_KVM_GUEST kvmclock_init(); #endif -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net] tuntap: correctly handle error in tun_set_iff()
On Wed, Sep 11, 2013 at 05:55:04AM -0400, Jason Wang wrote: > > > - Original Message - > > On Wed, Sep 11, 2013 at 04:24:05PM +0800, Jason Wang wrote: > > > Commit c8d68e6be1c3b242f1c598595830890b65cea64a (tuntap: multiqueue > > > support) > > > only call free_netdev() on err in tun_set_iff(). This causes several > > > issues: > > > > > > - memory of tun security were leaked > > > > Not just tun security - sock reference too (didn't detach) > > > > Yes, I mention it in the next item. That line's a bit too long btw. Keep it under 70 chars for commit logs. > > > - use after free since the flow gc timer was not deleted and the tfile > > > were > > > not > > > detached > > > > > > This patch solves the above issues. > > > > > > Reported-by: Wannes Rombouts > > > Cc: Michael S. Tsirkin > > > Signed-off-by: Jason Wang > > > --- > > > The patch were also needed for stable 3.8+. > > > --- > > > drivers/net/tun.c |9 +++-- > > > 1 files changed, 7 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/net/tun.c b/drivers/net/tun.c > > > index a639de8..e5fb5d3 100644 > > > --- a/drivers/net/tun.c > > > +++ b/drivers/net/tun.c > > > @@ -1641,11 +1641,11 @@ static int tun_set_iff(struct net *net, struct > > > file > > > *file, struct ifreq *ifr) > > > INIT_LIST_HEAD(&tun->disabled); > > > err = tun_attach(tun, file, false); > > > if (err < 0) > > > - goto err_free_dev; > > > + goto err_free_flow; > > > > > > err = register_netdevice(tun->dev); > > > if (err < 0) > > > - goto err_free_dev; > > > + goto err_detach; > > > > > > if (device_create_file(&tun->dev->dev, &dev_attr_tun_flags) || > > > device_create_file(&tun->dev->dev, &dev_attr_owner) || > > > @@ -1689,6 +1689,11 @@ static int tun_set_iff(struct net *net, struct file > > > *file, struct ifreq *ifr) > > > strcpy(ifr->ifr_name, tun->dev->name); > > > return 0; > > > > > > +err_detach: > > > + tun_detach_all(dev); > > > +err_free_flow: > > > + tun_flow_uninit(tun); > > > + security_tun_dev_free_security(tun->security); > > > > This bit looks wrong: if flow_init fails, we > > need security_tun_dev_free_security, don't we? > > I think we need: > > +err_free_sec: security_tun_dev_free_security(tun->security); > > and goto here on flow_init failures. > > tun_flow_init() always succeed. So we're ok here. True. So please make it return void then. > > > > > err_free_dev: > > > > Pls shift this one 1 space left for consistency. > > > > Ok. > > > free_netdev(dev); > > > return err; > > > -- > > > 1.7.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/ > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 8/9] x86, mem-hotplug: Support initialize page tables from low to high.
init_mem_mapping() is called before SRAT is parsed. And memblock will allocate
memory for page tables. To prevent page tables being allocated within
hotpluggable
memory, we will allocate page tables from the end of kernel image to the higher
memory.
Signed-off-by: Tang Chen
Reviewed-by: Zhang Yanfei
---
arch/x86/mm/init.c | 133 ---
1 files changed, 104 insertions(+), 29 deletions(-)
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 04664cd..7dae4e3 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -54,11 +54,23 @@ __ref void *alloc_low_pages(unsigned int num)
unsigned long ret;
if (min_pfn_mapped >= max_pfn_mapped)
panic("alloc_low_page: ran out of memory");
+
+ if (memblock_direction_bottom_up()) {
+ ret = memblock_alloc_bottom_up(
+ MEMBLOCK_ALLOC_ACCESSIBLE,
+ max_pfn_mapped << PAGE_SHIFT,
+ PAGE_SIZE * num, PAGE_SIZE);
+ if (ret)
+ goto reserve;
+ }
+
ret = memblock_find_in_range(min_pfn_mapped << PAGE_SHIFT,
max_pfn_mapped << PAGE_SHIFT,
PAGE_SIZE * num , PAGE_SIZE);
if (!ret)
panic("alloc_low_page: can not alloc memory");
+
+reserve:
memblock_reserve(ret, PAGE_SIZE * num);
pfn = ret >> PAGE_SHIFT;
} else {
@@ -401,13 +413,79 @@ static unsigned long __init init_range_memory_mapping(
/* (PUD_SHIFT-PMD_SHIFT)/2 */
#define STEP_SIZE_SHIFT 5
-void __init init_mem_mapping(void)
+
+#ifdef CONFIG_MOVABLE_NODE
+/**
+ * memory_map_from_low - Map [start, end) from low to high
+ * @start: start address of the target memory range
+ * @end: end address of the target memory range
+ *
+ * This function will setup direct mapping for memory range [start, end) in a
+ * heuristic way. In the beginning, step_size is small. The more memory we map
+ * memory in the next loop.
+ */
+static void __init memory_map_from_low(unsigned long start, unsigned long end)
+{
+ unsigned long next, new_mapped_ram_size;
+ unsigned long mapped_ram_size = 0;
+ /* step_size need to be small so pgt_buf from BRK could cover it */
+ unsigned long step_size = PMD_SIZE;
+
+ while (start < end) {
+ if (end - start > step_size) {
+ next = round_up(start + 1, step_size);
+ if (next > end)
+ next = end;
+ } else
+ next = end;
+
+ new_mapped_ram_size = init_range_memory_mapping(start, next);
+ min_pfn_mapped = start >> PAGE_SHIFT;
+ start = next;
+
+ if (new_mapped_ram_size > mapped_ram_size)
+ step_size <<= STEP_SIZE_SHIFT;
+ mapped_ram_size += new_mapped_ram_size;
+ }
+}
+#endif /* CONFIG_MOVABLE_NODE */
+
+/**
+ * memory_map_from_high - Map [start, end) from high to low
+ * @start: start address of the target memory range
+ * @end: end address of the target memory range
+ *
+ * This function is similar to memory_map_from_low() except it maps memory
+ * from high to low.
+ */
+static void __init memory_map_from_high(unsigned long start, unsigned long end)
{
- unsigned long end, real_end, start, last_start;
- unsigned long step_size;
- unsigned long addr;
+ unsigned long prev, new_mapped_ram_size;
unsigned long mapped_ram_size = 0;
- unsigned long new_mapped_ram_size;
+ /* step_size need to be small so pgt_buf from BRK could cover it */
+ unsigned long step_size = PMD_SIZE;
+
+ while (start < end) {
+ if (end > step_size) {
+ prev = round_down(end - 1, step_size);
+ if (prev < start)
+ prev = start;
+ } else
+ prev = start;
+
+ new_mapped_ram_size = init_range_memory_mapping(prev, end);
+ min_pfn_mapped = prev >> PAGE_SHIFT;
+ end = prev;
+
+ if (new_mapped_ram_size > mapped_ram_size)
+ step_size <<= STEP_SIZE_SHIFT;
+ mapped_ram_size += new_mapped_ram_size;
+ }
+}
+
+void __init init_mem_mapping(void)
+{
+ unsigned long end;
probe_page_size_mask();
@@ -417,45 +495,42 @@ void __init init_mem_mapping(void)
end = max_low_pfn << PAGE_SHIFT;
#endif
- /* the ISA range is always mapped regardless of memory holes */
- init_memory_mapping(0, ISA_END_ADDRESS);
+ max_pfn_mapped = 0; /* will get exact value next */
+ min_pfn_mapped = end >> PAGE_SH
[PATCH v2 2/9] x86, memblock: Introduce memblock_alloc_bottom_up() to memblock.
This patch introduces a new API memblock_alloc_bottom_up() to make memblock be
able to allocate from bottom upwards.
During early boot, if the bottom up mode is set, just try allocating bottom up
from the end of kernel image, and if that fails, do normal top down allocation.
Suggested-by: Tejun Heo
Signed-off-by: Tang Chen
Reviewed-by: Zhang Yanfei
---
include/linux/memblock.h |2 ++
mm/memblock.c| 38 ++
2 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index fbf6b6d..9a0958f 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -151,6 +151,8 @@ phys_addr_t memblock_alloc_nid(phys_addr_t size,
phys_addr_t align, int nid);
phys_addr_t memblock_alloc_try_nid(phys_addr_t size, phys_addr_t align, int
nid);
phys_addr_t memblock_alloc(phys_addr_t size, phys_addr_t align);
+phys_addr_t memblock_alloc_bottom_up(phys_addr_t start, phys_addr_t end,
+phys_addr_t size, phys_addr_t align);
static inline bool memblock_direction_bottom_up(void)
{
diff --git a/mm/memblock.c b/mm/memblock.c
index 7add615..d7485b9 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -20,6 +20,8 @@
#include
#include
+#include
+
static struct memblock_region
memblock_memory_init_regions[INIT_MEMBLOCK_REGIONS] __initdata_memblock;
static struct memblock_region
memblock_reserved_init_regions[INIT_MEMBLOCK_REGIONS] __initdata_memblock;
@@ -786,6 +788,42 @@ static phys_addr_t __init
memblock_alloc_base_nid(phys_addr_t size,
return 0;
}
+/**
+ * memblock_alloc_bottom_up - allocate memory from bottom upwards
+ * @start: start of candidate range, can be %MEMBLOCK_ALLOC_ACCESSIBLE
+ * @@end: end of candidate range, can be %MEMBLOCK_ALLOC_{ANYWHERE|ACCESSIBLE}
+ * @size: size of free area to allocate
+ * @align: alignment of free area to allocate
+ *
+ * Allocate @size free area aligned to @align from the end of the kernel image
+ * upwards.
+ *
+ * Found address on success, %0 on failure.
+ */
+phys_addr_t __init_memblock memblock_alloc_bottom_up(phys_addr_t start,
+ phys_addr_t end, phys_addr_t size,
+ phys_addr_t align)
+{
+ phys_addr_t this_start, this_end, cand;
+ u64 i;
+
+ if (start == MEMBLOCK_ALLOC_ACCESSIBLE)
+ start = __pa_symbol(_end); /* End of kernel image. */
+ if (end == MEMBLOCK_ALLOC_ACCESSIBLE)
+ end = memblock.current_limit;
+
+ for_each_free_mem_range(i, MAX_NUMNODES, &this_start, &this_end, NULL) {
+ this_start = clamp(this_start, start, end);
+ this_end = clamp(this_end, start, end);
+
+ cand = round_up(this_start, align);
+ if (cand < this_end && this_end - cand >= size)
+ return cand;
+ }
+
+ return 0;
+}
+
phys_addr_t __init memblock_alloc_nid(phys_addr_t size, phys_addr_t align, int
nid)
{
return memblock_alloc_base_nid(size, align, MEMBLOCK_ALLOC_ACCESSIBLE,
nid);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 9/9] mem-hotplug: Introduce movablenode boot option to control memblock allocation direction.
The Hot-Pluggable fired in SRAT specifies which memory is hotpluggable.
As we mentioned before, if hotpluggable memory is used by the kernel,
it cannot be hot-removed. So memory hotplug users may want to set all
hotpluggable memory in ZONE_MOVABLE so that the kernel won't use it.
Memory hotplug users may also set a node as movable node, which has
ZONE_MOVABLE only, so that the whole node can be hot-removed.
But the kernel cannot use memory in ZONE_MOVABLE. By doing this, the
kernel cannot use memory in movable nodes. This will cause NUMA
performance down. And other users may be unhappy.
So we need a way to allow users to enable and disable this functionality.
In this patch, we introduce movablenode boot option to allow users to
choose to reserve hotpluggable memory and set it as ZONE_MOVABLE or not.
Users can specify "movablenode" in kernel commandline to enable this
functionality. For those who don't use memory hotplug or who don't want
to lose their NUMA performance, just don't specify anything. The kernel
will work as before.
After memblock is ready, before SRAT is parsed, we should allocate memory
near the kernel image. So this patch does the following:
1. After memblock is ready, make memblock allocate memory from low address
to high.
2. After SRAT is parsed, make memblock behave as default, allocate memory
from high address to low.
This behavior is controlled by movablenode boot option.
Suggested-by: Kamezawa Hiroyuki
Signed-off-by: Tang Chen
Reviewed-by: Wanpeng Li
Reviewed-by: Zhang Yanfei
---
Documentation/kernel-parameters.txt | 15 ++
arch/x86/kernel/setup.c | 36 +++
include/linux/memory_hotplug.h |5
mm/memory_hotplug.c |9
4 files changed, 65 insertions(+), 0 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 479eeaf..f177c83 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1769,6 +1769,21 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
that the amount of memory usable for all allocations
is not too small.
+ movablenode [KNL,X86] This parameter enables/disables the
+ kernel to arrange hotpluggable memory ranges recorded
+ in ACPI SRAT(System Resource Affinity Table) as
+ ZONE_MOVABLE. And these memory can be hot-removed when
+ the system is up.
+ By specifying this option, all the hotpluggable memory
+ will be in ZONE_MOVABLE, which the kernel cannot use.
+ This will cause NUMA performance down. For users who
+ care about NUMA performance, just don't use it.
+ If all the memory ranges in the system are hotpluggable,
+ then the ones used by the kernel at early time, such as
+ kernel code and data segments, initrd file and so on,
+ won't be set as ZONE_MOVABLE, and won't be hotpluggable.
+ Otherwise the kernel won't have enough memory to boot.
+
MTD_Partition= [MTD]
Format: ,,,
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index fa56a57..b87069b 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1104,6 +1104,31 @@ void __init setup_arch(char **cmdline_p)
trim_platform_memory_ranges();
trim_low_memory_range();
+#ifdef CONFIG_MOVABLE_NODE
+ if (movablenode_enable_srat) {
+ /*
+* Memory used by the kernel cannot be hot-removed because Linux
+* cannot migrate the kernel pages. When memory hotplug is
+* enabled, we should prevent memblock from allocating memory
+* for the kernel.
+*
+* ACPI SRAT records all hotpluggable memory ranges. But before
+* SRAT is parsed, we don't know about it.
+*
+* The kernel image is loaded into memory at very early time. We
+* cannot prevent this anyway. So on NUMA system, we set any
+* node the kernel resides in as un-hotpluggable.
+*
+* Since on modern servers, one node could have double-digit
+* gigabytes memory, we can assume the memory around the kernel
+* image is also un-hotpluggable. So before SRAT is parsed, just
+* allocate memory near the kernel image to try the best to keep
+* the kernel away from hotpluggable memory.
+*/
+ memblock_set_current_direction(MEMBLOCK_DIRECTION_LOW_TO_HIGH);
+ }
+#endif /* CONFIG_MOVABLE_NODE */
+
init_mem_mapping();
[PATCH v2 1/9] memblock: Introduce allocation direction to memblock.
The Linux kernel cannot migrate pages used by the kernel. As a result, kernel
pages cannot be hot-removed. So we cannot allocate hotpluggable memory for
the kernel.
ACPI SRAT (System Resource Affinity Table) contains the memory hotplug info.
But before SRAT is parsed, memblock has already started to allocate memory
for the kernel. So we need to prevent memblock from doing this.
In a memory hotplug system, any numa node the kernel resides in should
be unhotpluggable. And for a modern server, each node could have at least
16GB memory. So memory around the kernel image is highly likely unhotpluggable.
So the basic idea is: Allocate memory from the end of the kernel image and
to the higher memory. Since memory allocation before SRAT is parsed won't
be too much, it could highly likely be in the same node with kernel image.
The current memblock can only allocate memory from high address to low.
So this patch introduces the allocation direct to memblock. It could be
used to tell memblock to allocate memory from high to low or from low
to high.
Signed-off-by: Tang Chen
Reviewed-by: Zhang Yanfei
---
include/linux/memblock.h | 22 ++
mm/memblock.c| 13 +
2 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index f388203..fbf6b6d 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -19,6 +19,11 @@
#define INIT_MEMBLOCK_REGIONS 128
+/* Allocation order. */
+#define MEMBLOCK_DIRECTION_HIGH_TO_LOW 0
+#define MEMBLOCK_DIRECTION_LOW_TO_HIGH 1
+#define MEMBLOCK_DIRECTION_DEFAULT MEMBLOCK_DIRECTION_HIGH_TO_LOW
+
struct memblock_region {
phys_addr_t base;
phys_addr_t size;
@@ -35,6 +40,7 @@ struct memblock_type {
};
struct memblock {
+ int current_direction; /* allocate from higher or lower address */
phys_addr_t current_limit;
struct memblock_type memory;
struct memblock_type reserved;
@@ -146,6 +152,12 @@ phys_addr_t memblock_alloc_try_nid(phys_addr_t size,
phys_addr_t align, int nid)
phys_addr_t memblock_alloc(phys_addr_t size, phys_addr_t align);
+static inline bool memblock_direction_bottom_up(void)
+{
+ return memblock.current_direction == MEMBLOCK_DIRECTION_LOW_TO_HIGH;
+}
+
+
/* Flags for memblock_alloc_base() amd __memblock_alloc_base() */
#define MEMBLOCK_ALLOC_ANYWHERE(~(phys_addr_t)0)
#define MEMBLOCK_ALLOC_ACCESSIBLE 0
@@ -173,6 +185,16 @@ static inline void memblock_dump_all(void)
}
/**
+ * memblock_set_current_direction - Set current allocation direction to allow
+ * allocating memory from higher to lower
+ * address or from lower to higher address
+ *
+ * @direction: In which order to allocate memory. Could be
+ * MEMBLOCK_DIRECTION_{HIGH_TO_LOW|LOW_TO_HIGH}
+ */
+void memblock_set_current_direction(int direction);
+
+/**
* memblock_set_current_limit - Set the current allocation limit to allow
* limiting allocations to what is currently
* accessible during boot
diff --git a/mm/memblock.c b/mm/memblock.c
index a847bfe..7add615 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -32,6 +32,7 @@ struct memblock memblock __initdata_memblock = {
.reserved.cnt = 1,/* empty dummy entry */
.reserved.max = INIT_MEMBLOCK_REGIONS,
+ .current_direction = MEMBLOCK_DIRECTION_DEFAULT,
.current_limit = MEMBLOCK_ALLOC_ANYWHERE,
};
@@ -977,6 +978,18 @@ void __init_memblock memblock_trim_memory(phys_addr_t
align)
}
}
+void __init_memblock memblock_set_current_direction(int direction)
+{
+ if (direction != MEMBLOCK_DIRECTION_HIGH_TO_LOW &&
+ direction != MEMBLOCK_DIRECTION_LOW_TO_HIGH) {
+ pr_warn("memblock: Failed to set allocation order. "
+ "Invalid order type: %d\n", direction);
+ return;
+ }
+
+ memblock.current_direction = direction;
+}
+
void __init_memblock memblock_set_current_limit(phys_addr_t limit)
{
memblock.current_limit = limit;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/9] x86: Support allocate memory from bottom upwards in setup_log_buf().
During early boot, if the bottom up mode is set, just
try allocating bottom up from the end of kernel image,
and if that fails, do normal top down allocation.
So in function setup_log_buf(), we add the above logic.
Signed-off-by: Tang Chen
Reviewed-by: Zhang Yanfei
---
kernel/printk/printk.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index b4e8500..2958118 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -759,9 +759,20 @@ void __init setup_log_buf(int early)
if (early) {
unsigned long mem;
+ if (memblock_direction_bottom_up()) {
+ mem = memblock_alloc_bottom_up(
+ MEMBLOCK_ALLOC_ACCESSIBLE,
+ MEMBLOCK_ALLOC_ACCESSIBLE,
+ new_log_buf_len, PAGE_SIZE);
+ if (mem)
+ goto success;
+ }
+
mem = memblock_alloc(new_log_buf_len, PAGE_SIZE);
if (!mem)
return;
+
+success:
new_log_buf = __va(mem);
} else {
new_log_buf = alloc_bootmem_nopanic(new_log_buf_len);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/9] x86, memblock: Allocate memory near kernel image before SRAT parsed.
This patch-set is based on tj's suggestion, and not fully tested. Just for review and discussion. And according to tj's suggestion, implemented a new function memblock_alloc_bottom_up() to allocate memory from bottom upwards, whihc can simplify the code. [Problem] The current Linux cannot migrate pages used by the kerenl because of the kernel direct mapping. In Linux kernel space, va = pa + PAGE_OFFSET. When the pa is changed, we cannot simply update the pagetable and keep the va unmodified. So the kernel pages are not migratable. There are also some other issues will cause the kernel pages not migratable. For example, the physical address may be cached somewhere and will be used. It is not to update all the caches. When doing memory hotplug in Linux, we first migrate all the pages in one memory device somewhere else, and then remove the device. But if pages are used by the kernel, they are not migratable. As a result, memory used by the kernel cannot be hot-removed. Modifying the kernel direct mapping mechanism is too difficult to do. And it may cause the kernel performance down and unstable. So we use the following way to do memory hotplug. [What we are doing] In Linux, memory in one numa node is divided into several zones. One of the zones is ZONE_MOVABLE, which the kernel won't use. In order to implement memory hotplug in Linux, we are going to arrange all hotpluggable memory in ZONE_MOVABLE so that the kernel won't use these memory. To do this, we need ACPI's help. In ACPI, SRAT(System Resource Affinity Table) contains NUMA info. The memory affinities in SRAT record every memory range in the system, and also, flags specifying if the memory range is hotpluggable. (Please refer to ACPI spec 5.0 5.2.16) With the help of SRAT, we have to do the following two things to achieve our goal: 1. When doing memory hot-add, allow the users arranging hotpluggable as ZONE_MOVABLE. (This has been done by the MOVABLE_NODE functionality in Linux.) 2. when the system is booting, prevent bootmem allocator from allocating hotpluggable memory for the kernel before the memory initialization finishes. The problem 2 is the key problem we are going to solve. But before solving it, we need some preparation. Please see below. [Preparation] Bootloader has to load the kernel image into memory. And this memory must be unhotpluggable. We cannot prevent this anyway. So in a memory hotplug system, we can assume any node the kernel resides in is not hotpluggable. Before SRAT is parsed, we don't know which memory ranges are hotpluggable. But memblock has already started to work. In the current kernel, memblock allocates the following memory before SRAT is parsed: setup_arch() |->memblock_x86_fill()/* memblock is ready */ |.. |->early_reserve_e820_mpc_new() /* allocate memory under 1MB */ |->reserve_real_mode()/* allocate memory under 1MB */ |->init_mem_mapping() /* allocate page tables, about 2MB to map 1GB memory */ |->dma_contiguous_reserve() /* specified by user, should be low */ |->setup_log_buf()/* specified by user, several mega bytes */ |->relocate_initrd() /* could be large, but will be freed after boot, should reorder */ |->acpi_initrd_override() /* several mega bytes */ |->reserve_crashkernel() /* could be large, should reorder */ |.. |->initmem_init() /* Parse SRAT */ According to Tejun's advice, before SRAT is parsed, we should try our best to allocate memory near the kernel image. Since the whole node the kernel resides in won't be hotpluggable, and for a modern server, a node may have at least 16GB memory, allocating several mega bytes memory around the kernel image won't cross to hotpluggable memory. [About this patch-set] So this patch-set does the following: 1. Make memblock be able to allocate memory from low address to high address. 2. Improve all functions who need to allocate memory before SRAT to support allocating memory from low address to high address. 3. Introduce "movablenode" boot option to enable and disable this functionality. PS: Reordering of relocate_initrd() has not been done yet. acpi_initrd_override() needs to access initrd with virtual address. So relocate_initrd() must be done before acpi_initrd_override(). Change log v1 -> v2: 1. According to tj's suggestion, implemented a new function memblock_alloc_bottom_up() to allocate memory from bottom upwards, whihc can simplify the code. Tang Chen (9): memblock: Introduce allocation direction to memblock. x86, memblock: Introduce memblock_alloc_bottom_up() to memblock. x86, dma: Support allocate memory from bottom upwards in dma_contiguous_reserve(). x86: Support allocate memory from bottom upwards in setup_log_buf(). x86: Support allocate memory from bottom upwards in relocate_initrd(). x86, acpi: Support allocate memory from bottom upward
[PATCH v2 3/9] x86, dma: Support allocate memory from bottom upwards in dma_contiguous_reserve().
During early boot, if the bottom up mode is set, just
try allocating bottom up from the end of kernel image,
and if that fails, do normal top down allocation.
So in function dma_contiguous_reserve(), we add the
above logic.
Signed-off-by: Tang Chen
Reviewed-by: Zhang Yanfei
---
drivers/base/dma-contiguous.c | 17 ++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index 6c9cdaa..3b4e031 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -260,17 +260,28 @@ int __init dma_declare_contiguous(struct device *dev,
phys_addr_t size,
goto err;
}
} else {
+ phys_addr_t addr;
+
+ if (memblock_direction_bottom_up()) {
+ addr = memblock_alloc_bottom_up(
+ MEMBLOCK_ALLOC_ACCESSIBLE,
+ limit, size, alignment);
+ if (addr)
+ goto success;
+ }
+
/*
* Use __memblock_alloc_base() since
* memblock_alloc_base() panic()s.
*/
- phys_addr_t addr = __memblock_alloc_base(size, alignment,
limit);
+ addr = __memblock_alloc_base(size, alignment, limit);
if (!addr) {
base = -ENOMEM;
goto err;
- } else {
- base = addr;
}
+
+success:
+ base = addr;
}
/*
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 5/9] x86: Support allocate memory from bottom upwards in relocate_initrd().
During early boot, if the bottom up mode is set, just
try allocating bottom up from the end of kernel image,
and if that fails, do normal top down allocation.
So in function relocate_initrd(), we add the above logic.
Signed-off-by: Tang Chen
Reviewed-by: Zhang Yanfei
---
arch/x86/kernel/setup.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index f0de629..7372be7 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -326,6 +326,15 @@ static void __init relocate_initrd(void)
char *p, *q;
/* We need to move the initrd down into directly mapped mem */
+ if (memblock_direction_bottom_up()) {
+ ramdisk_here = memblock_alloc_bottom_up(
+ MEMBLOCK_ALLOC_ACCESSIBLE,
+ PFN_PHYS(max_pfn_mapped),
+ area_size, PAGE_SIZE);
+ if (ramdisk_here)
+ goto success;
+ }
+
ramdisk_here = memblock_find_in_range(0, PFN_PHYS(max_pfn_mapped),
area_size, PAGE_SIZE);
@@ -333,6 +342,7 @@ static void __init relocate_initrd(void)
panic("Cannot find place for new RAMDISK of size %lld\n",
ramdisk_size);
+success:
/* Note: this includes all the mem currently occupied by
the initrd, we rely on that fact to keep the data intact. */
memblock_reserve(ramdisk_here, area_size);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] Cpufreq: Remove fossil comment of cpufreq_set_policy
On 11 September 2013 08:58, Lan Tianyu wrote: > From 668e1b6fd94b5c0e56a651b4c60cbbc7a6868b46 Mon Sep 17 00:00:00 2001 > From: Lan Tianyu > Date: Wed, 11 Sep 2013 11:31:15 +0800 > Subject: [PATCH] Cpufreq/governor: Remove fossil comment > > cpufreq_set_policy() has been changed to origin __cpufreq_set_policy() > and policy->lock has been converted to rewrite lock by commit 5a01f2. > So remove it. > > Signed-off-by: Lan Tianyu > --- > drivers/cpufreq/cpufreq_userspace.c | 11 --- > 1 file changed, 11 deletions(-) > > diff --git a/drivers/cpufreq/cpufreq_userspace.c > b/drivers/cpufreq/cpufreq_userspace.c > index 0307809..4dbf1db 100644 > --- a/drivers/cpufreq/cpufreq_userspace.c > +++ b/drivers/cpufreq/cpufreq_userspace.c > @@ -38,18 +38,7 @@ static int cpufreq_set(struct cpufreq_policy *policy, > unsigned int freq) > if (!per_cpu(cpu_is_managed, policy->cpu)) > goto err; > > - /* > -* We're safe from concurrent calls to ->target() here > -* as we hold the userspace_mutex lock. If we were calling > -* cpufreq_driver_target, a deadlock situation might occur: > -* A: cpufreq_set (lock userspace_mutex) -> > -* cpufreq_driver_target(lock policy->lock) > -* B: cpufreq_set_policy(lock policy->lock) -> > -* __cpufreq_governor -> > -* cpufreq_governor_userspace (lock userspace_mutex) > -*/ > ret = __cpufreq_driver_target(policy, freq, CPUFREQ_RELATION_L); > - > err: > mutex_unlock(&userspace_mutex); > return ret; Looks fine: Acked-by: Viresh Kumar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] serial: samsung: add support for manual RTS setting
The Samsung serial driver currently does not support setting the
RTS pin with an ioctl(TIOCMSET) call. This patch adds this support.
Signed-off-by: José Miguel Gonçalves
---
drivers/tty/serial/samsung.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index f3dfa19..e5dd808 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -407,7 +407,14 @@ static unsigned int s3c24xx_serial_get_mctrl(struct
uart_port *port)
static void s3c24xx_serial_set_mctrl(struct uart_port *port, unsigned int
mctrl)
{
- /* todo - possibly remove AFC and do manual CTS */
+ unsigned int umcon = rd_regl(port, S3C2410_UMCON);
+
+ if (mctrl & TIOCM_RTS)
+ umcon |= S3C2410_UMCOM_RTS_LOW;
+ else
+ umcon &= ~S3C2410_UMCOM_RTS_LOW;
+
+ wr_regl(port, S3C2410_UMCON, umcon);
}
static void s3c24xx_serial_break_ctl(struct uart_port *port, int break_state)
@@ -774,8 +781,6 @@ static void s3c24xx_serial_set_termios(struct uart_port
*port,
if (termios->c_cflag & CSTOPB)
ulcon |= S3C2410_LCON_STOPB;
- umcon = (termios->c_cflag & CRTSCTS) ? S3C2410_UMCOM_AFC : 0;
-
if (termios->c_cflag & PARENB) {
if (termios->c_cflag & PARODD)
ulcon |= S3C2410_LCON_PODD;
@@ -792,6 +797,12 @@ static void s3c24xx_serial_set_termios(struct uart_port
*port,
wr_regl(port, S3C2410_ULCON, ulcon);
wr_regl(port, S3C2410_UBRDIV, quot);
+
+ if (termios->c_cflag & CRTSCTS)
+ umcon = S3C2410_UMCOM_AFC;
+ else
+ umcon = rd_regb(port, S3C2410_UMCON) & ~S3C2410_UMCOM_AFC;
+
wr_regl(port, S3C2410_UMCON, umcon);
if (ourport->info->has_divslot)
--
1.7.10.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/
Re: [PATCH 2/2] am335x-boneblack: add eMMC DT entry
On Wednesday 11 September 2013 11:42 AM, Koen Kooi wrote:
> Signed-off-by: Koen Kooi
> ---
> arch/arm/boot/dts/am335x-bone-common.dtsi | 7 +++
> arch/arm/boot/dts/am335x-boneblack.dts| 15 +++
> 2 files changed, 22 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
> b/arch/arm/boot/dts/am335x-bone-common.dtsi
> index ced256c..9c61fef 100644
> --- a/arch/arm/boot/dts/am335x-bone-common.dtsi
> +++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
> @@ -241,6 +241,13 @@
> regulator-always-on;
> };
> };
> +
> + vmmcsd_fixed: fixedregulator@0 {
> + compatible = "regulator-fixed";
> + regulator-name = "vmmcsd_fixed";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + };
> };
>
> &cpsw_emac0 {
> diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
> b/arch/arm/boot/dts/am335x-boneblack.dts
> index 197cadf..c09947a 100644
> --- a/arch/arm/boot/dts/am335x-boneblack.dts
> +++ b/arch/arm/boot/dts/am335x-boneblack.dts
> @@ -15,3 +15,18 @@
> regulator-max-microvolt = <180>;
> regulator-always-on;
> };
> +
> +&mmc1 {
> + vmmc-supply = <&vmmcsd_fixed>;
> +};
> +
> +&mmc2 {
> + vmmc-supply = <&vmmcsd_fixed>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&emmc_pins>;
> + bus-width = <8>;
> + ti,non-removable;
There is a standard binding available for this: "non-removable"
There should not be a need to introduce a TI specific binding for this
(I know this is not your fault).
I will send a patch to change the existing .dts files and update the
driver - can you drop this line for now so we don't introduce more
incompatibilities? I can send a patch adding "non-removable" to this
node as part of my clean-up series.
Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] fuse: wait for writeback in fuse_file_fallocate() -v2
On Fri, Aug 30, 2013 at 1:33 PM, Maxim Patlasov wrote: > 08/30/2013 01:13 PM, Miklos Szeredi пишет: > >> On Thu, Aug 29, 2013 at 6:41 PM, Miklos Szeredi wrote: >>> >>> BTW, isn't it enough to do the filemap_write_and_wait() *plus* the >>> fuse_set_nowrite()? >> >> Thought about it a bit and I think this should do fine. >> >> Any writes before the fallocate will go trough before the fallocate. >> i_mutex guarantees that only one instance of fuse_set_nowrite() is >> running. Any mmaped writes during the fallocate() will go after the >> fallocate request and the page cache truncation and that's fine too. >> Page cache is consistent since it doens't contain pages for those >> writes to the hole. Subsequent reads to that area will fill them in. >> >> Any other concerns? > > > No. What you suggest looks as a neat and correct solution. I'll resend the > updated patch after some testing (since now till Monday). > > As for proof-of-correctness, all you wrote above is correct, but the first > point had been boiling my mind for a while. I came to the following > reasoning (hopefully it is what you meant): > > The fact that filemap_write_and_wait() returned infers that > end_page_writeback() was called for all relevant pages. And fuse doesn't > call it before adding request to fi->queued_writes and calling > fuse_flush_writepages(). And the latter, in turn, guarantees proper > accounting of request in fi->writectr. Here, of course, it's crucial that we > can't have concurrent fuse_set_nowrite(), as you explained. Hence, so far as > fi->writectr was bumped, fuse_set_nowrite() we call after > filemap_write_and_wait() would wait until all changes have gone to the > server. Any news about this? Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] CPUFreq: Last set of updates for 3.13
Hi Rafael, I really tried to stop after you asked me to, but still got few more patches.. These are very minor changes and a fairly smaller patchset.. I have rebased this over your linux-next branch 7c218b1 Merge branch 'acpi-bind-next' into linux-next and tested over my exynos board.. I don't expect them to do any crappy stuff.. You can include these first (if they look fine) and then I will send all other patches that I have queued up for 3.13.. I will send all of them in one lot, with partition numbers mentioned (i.e. patches that should go together) and then you can apply them the way you wish.. Set by set or all at once.. Thanks.. Viresh Kumar (5): cpufreq: Optimize cpufreq_frequency_table_verify() cpufreq: rename __cpufreq_set_policy() as cpufreq_set_policy() cpufreq: rewrite cpufreq_driver->flags using shift operator cpufreq: use cpufreq_driver->flags to mark CPUFREQ_HAVE_GOVERNOR_PER_POLICY cpufreq: add new routine cpufreq_verify_within_cpu_limits() drivers/cpufreq/arm_big_little.c | 4 ++-- drivers/cpufreq/cpufreq-nforce2.c| 4 +--- drivers/cpufreq/cpufreq.c| 24 ++- drivers/cpufreq/cpufreq_governor.h | 5 - drivers/cpufreq/davinci-cpufreq.c| 4 +--- drivers/cpufreq/freq_table.c | 27 +- drivers/cpufreq/integrator-cpufreq.c | 9 ++--- drivers/cpufreq/intel_pstate.c | 4 +--- drivers/cpufreq/longrun.c| 4 +--- drivers/cpufreq/pcc-cpufreq.c| 3 +-- drivers/cpufreq/sh-cpufreq.c | 7 ++- drivers/cpufreq/unicore2-cpufreq.c | 4 +--- include/linux/cpufreq.h | 37 ++-- 13 files changed, 62 insertions(+), 74 deletions(-) -- 1.7.12.rc2.18.g61b472e -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/5] cpufreq: Optimize cpufreq_frequency_table_verify()
cpufreq_frequency_table_verify() is a bit rewritten here to make it more logical
and optimal.
- merge multiple lines for variable declarations together.
- quit early if any frequency between min/max is found.
- don't call cpufreq_verify_within_limits() in case any valid freq is found as
it is of no use.
- count renamed as found and made a boolean.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/freq_table.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
index f111454a..53a2f1a 100644
--- a/drivers/cpufreq/freq_table.c
+++ b/drivers/cpufreq/freq_table.c
@@ -54,9 +54,8 @@ EXPORT_SYMBOL_GPL(cpufreq_frequency_table_cpuinfo);
int cpufreq_frequency_table_verify(struct cpufreq_policy *policy,
struct cpufreq_frequency_table *table)
{
- unsigned int next_larger = ~0;
- unsigned int i;
- unsigned int count = 0;
+ unsigned int next_larger = ~0, freq, i = 0;
+ bool found = false;
pr_debug("request for verification of policy (%u - %u kHz) for cpu
%u\n",
policy->min, policy->max, policy->cpu);
@@ -64,21 +63,23 @@ int cpufreq_frequency_table_verify(struct cpufreq_policy
*policy,
cpufreq_verify_within_limits(policy, policy->cpuinfo.min_freq,
policy->cpuinfo.max_freq);
- for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
- unsigned int freq = table[i].frequency;
+ for (; freq = table[i].frequency, freq != CPUFREQ_TABLE_END; i++) {
if (freq == CPUFREQ_ENTRY_INVALID)
continue;
- if ((freq >= policy->min) && (freq <= policy->max))
- count++;
- else if ((next_larger > freq) && (freq > policy->max))
+ if ((freq >= policy->min) && (freq <= policy->max)) {
+ found = true;
+ break;
+ }
+
+ if ((next_larger > freq) && (freq > policy->max))
next_larger = freq;
}
- if (!count)
+ if (!found) {
policy->max = next_larger;
-
- cpufreq_verify_within_limits(policy, policy->cpuinfo.min_freq,
-policy->cpuinfo.max_freq);
+ cpufreq_verify_within_limits(policy, policy->cpuinfo.min_freq,
+ policy->cpuinfo.max_freq);
+ }
pr_debug("verification lead to (%u - %u kHz) for cpu %u\n",
policy->min, policy->max, policy->cpu);
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] cpufreq: rename __cpufreq_set_policy() as cpufreq_set_policy()
Earlier there used to be two functions named __cpufreq_set_policy() and
cpufreq_set_policy(), but now we only have a single routine lets name it
cpufreq_set_policy() instead of __cpufreq_set_policy().
This also removes some invalid comments or fixes some incorrect comments.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 5a64f66..749bf06 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -414,7 +414,7 @@ show_one(scaling_min_freq, min);
show_one(scaling_max_freq, max);
show_one(scaling_cur_freq, cur);
-static int __cpufreq_set_policy(struct cpufreq_policy *policy,
+static int cpufreq_set_policy(struct cpufreq_policy *policy,
struct cpufreq_policy *new_policy);
/**
@@ -435,7 +435,7 @@ static ssize_t store_##file_name
\
if (ret != 1) \
return -EINVAL; \
\
- ret = __cpufreq_set_policy(policy, &new_policy);\
+ ret = cpufreq_set_policy(policy, &new_policy); \
policy->user_policy.object = policy->object;\
\
return ret ? ret : count; \
@@ -493,11 +493,7 @@ static ssize_t store_scaling_governor(struct
cpufreq_policy *policy,
&new_policy.governor))
return -EINVAL;
- /*
-* Do not use cpufreq_set_policy here or the user_policy.max
-* will be wrongly overridden
-*/
- ret = __cpufreq_set_policy(policy, &new_policy);
+ ret = cpufreq_set_policy(policy, &new_policy);
policy->user_policy.policy = policy->policy;
policy->user_policy.governor = policy->governor;
@@ -844,11 +840,11 @@ static void cpufreq_init_policy(struct cpufreq_policy
*policy)
int ret = 0;
memcpy(&new_policy, policy, sizeof(*policy));
- /* assure that the starting sequence is run in __cpufreq_set_policy */
+ /* assure that the starting sequence is run in cpufreq_set_policy */
policy->governor = NULL;
/* set default policy */
- ret = __cpufreq_set_policy(policy, &new_policy);
+ ret = cpufreq_set_policy(policy, &new_policy);
policy->user_policy.policy = policy->policy;
policy->user_policy.governor = policy->governor;
@@ -1844,10 +1840,10 @@ int cpufreq_get_policy(struct cpufreq_policy *policy,
unsigned int cpu)
EXPORT_SYMBOL(cpufreq_get_policy);
/*
- * data : current policy.
- * policy : policy to be set.
+ * policy : current policy.
+ * new_policy: policy to be set.
*/
-static int __cpufreq_set_policy(struct cpufreq_policy *policy,
+static int cpufreq_set_policy(struct cpufreq_policy *policy,
struct cpufreq_policy *new_policy)
{
int ret = 0, failed = 1;
@@ -1996,7 +1992,7 @@ int cpufreq_update_policy(unsigned int cpu)
}
}
- ret = __cpufreq_set_policy(policy, &new_policy);
+ ret = cpufreq_set_policy(policy, &new_policy);
unlock_policy_rwsem_write(cpu);
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] cpufreq: rewrite cpufreq_driver->flags using shift operator
Currently cpufreq_driver's flags are defined directly using 0x1, 0x2, 0x4, 0x8,
etc.. As the list grows it doesn't stays much readable..
Lets use bitwise shift operator << to generate these numbers for respective
positions.
Signed-off-by: Viresh Kumar
---
include/linux/cpufreq.h | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index fcabc42..c71dc0f 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -211,13 +211,14 @@ struct cpufreq_driver {
};
/* flags */
-#define CPUFREQ_STICKY 0x01/* the driver isn't removed even if
-* all ->init() calls failed */
-#define CPUFREQ_CONST_LOOPS0x02/* loops_per_jiffy or other kernel
-* "constants" aren't affected by
-* frequency transitions */
-#define CPUFREQ_PM_NO_WARN 0x04/* don't warn on suspend/resume speed
-* mismatches */
+#define CPUFREQ_STICKY (1 << 0)/* driver isn't removed even if
+ all ->init() calls failed */
+#define CPUFREQ_CONST_LOOPS(1 << 1)/* loops_per_jiffy or other
+ kernel "constants" aren't
+ affected by frequency
+ transitions */
+#define CPUFREQ_PM_NO_WARN (1 << 2)/* don't warn on suspend/resume
+ speed mismatches */
int cpufreq_register_driver(struct cpufreq_driver *driver_data);
int cpufreq_unregister_driver(struct cpufreq_driver *driver_data);
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/5] cpufreq: use cpufreq_driver->flags to mark CPUFREQ_HAVE_GOVERNOR_PER_POLICY
Lets use cpufreq_driver->flags to mark CPUFREQ_HAVE_GOVERNOR_PER_POLICY instead
of a separate field within cpufreq_driver. This will save some bytes for us.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/arm_big_little.c | 4 ++--
drivers/cpufreq/cpufreq.c | 2 +-
drivers/cpufreq/cpufreq_governor.h | 5 -
include/linux/cpufreq.h| 15 ---
4 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c
index 3549f07..768aa9c 100644
--- a/drivers/cpufreq/arm_big_little.c
+++ b/drivers/cpufreq/arm_big_little.c
@@ -214,13 +214,13 @@ static struct freq_attr *bL_cpufreq_attr[] = {
static struct cpufreq_driver bL_cpufreq_driver = {
.name = "arm-big-little",
- .flags = CPUFREQ_STICKY,
+ .flags = CPUFREQ_STICKY |
+ CPUFREQ_HAVE_GOVERNOR_PER_POLICY,
.verify = bL_cpufreq_verify_policy,
.target = bL_cpufreq_set_target,
.get= bL_cpufreq_get,
.init = bL_cpufreq_init,
.exit = bL_cpufreq_exit,
- .have_governor_per_policy = true,
.attr = bL_cpufreq_attr,
};
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 749bf06..3ac98a5 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -135,7 +135,7 @@ static DEFINE_MUTEX(cpufreq_governor_mutex);
bool have_governor_per_policy(void)
{
- return cpufreq_driver->have_governor_per_policy;
+ return !!(cpufreq_driver->flags & CPUFREQ_HAVE_GOVERNOR_PER_POLICY);
}
EXPORT_SYMBOL_GPL(have_governor_per_policy);
diff --git a/drivers/cpufreq/cpufreq_governor.h
b/drivers/cpufreq/cpufreq_governor.h
index 88cd39f..b5f2b86 100644
--- a/drivers/cpufreq/cpufreq_governor.h
+++ b/drivers/cpufreq/cpufreq_governor.h
@@ -191,7 +191,10 @@ struct common_dbs_data {
struct attribute_group *attr_group_gov_sys; /* one governor - system */
struct attribute_group *attr_group_gov_pol; /* one governor - policy */
- /* Common data for platforms that don't set have_governor_per_policy */
+ /*
+* Common data for platforms that don't set
+* CPUFREQ_HAVE_GOVERNOR_PER_POLICY
+*/
struct dbs_data *gdbs_data;
struct cpu_dbs_common_info *(*get_cpu_cdbs)(int cpu);
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index c71dc0f..e0a9f15 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -180,13 +180,6 @@ __ATTR(_name, 0644, show_##_name, store_##_name)
struct cpufreq_driver {
charname[CPUFREQ_NAME_LEN];
u8 flags;
- /*
-* This should be set by platforms having multiple clock-domains, i.e.
-* supporting multiple policies. With this sysfs directories of governor
-* would be created in cpu/cpu/cpufreq/ directory and so they can
-* use the same governor with different tunables for different clusters.
-*/
- boolhave_governor_per_policy;
/* needed by all drivers */
int (*init) (struct cpufreq_policy *policy);
@@ -220,6 +213,14 @@ struct cpufreq_driver {
#define CPUFREQ_PM_NO_WARN (1 << 2)/* don't warn on suspend/resume
speed mismatches */
+/*
+ * This should be set by platforms having multiple clock-domains, i.e.
+ * supporting multiple policies. With this sysfs directories of governor would
+ * be created in cpu/cpu/cpufreq/ directory and so they can use the same
+ * governor with different tunables for different clusters.
+ */
+#define CPUFREQ_HAVE_GOVERNOR_PER_POLICY (1 << 3)
+
int cpufreq_register_driver(struct cpufreq_driver *driver_data);
int cpufreq_unregister_driver(struct cpufreq_driver *driver_data);
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net] tuntap: correctly handle error in tun_set_iff()
- Original Message - > On Wed, Sep 11, 2013 at 05:55:04AM -0400, Jason Wang wrote: > > > > > > - Original Message - > > > On Wed, Sep 11, 2013 at 04:24:05PM +0800, Jason Wang wrote: > > > > Commit c8d68e6be1c3b242f1c598595830890b65cea64a (tuntap: multiqueue > > > > support) > > > > only call free_netdev() on err in tun_set_iff(). This causes several > > > > issues: > > > > > > > > - memory of tun security were leaked > > > > > > Not just tun security - sock reference too (didn't detach) > > > > > > > Yes, I mention it in the next item. > > That line's a bit too long btw. > Keep it under 70 chars for commit logs. > Ok. > > > > - use after free since the flow gc timer was not deleted and the tfile > > > > were > > > > not > > > > detached > > > > > > > > This patch solves the above issues. > > > > > > > > Reported-by: Wannes Rombouts > > > > Cc: Michael S. Tsirkin > > > > Signed-off-by: Jason Wang > > > > --- > > > > The patch were also needed for stable 3.8+. > > > > --- > > > > drivers/net/tun.c |9 +++-- > > > > 1 files changed, 7 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/drivers/net/tun.c b/drivers/net/tun.c > > > > index a639de8..e5fb5d3 100644 > > > > --- a/drivers/net/tun.c > > > > +++ b/drivers/net/tun.c > > > > @@ -1641,11 +1641,11 @@ static int tun_set_iff(struct net *net, struct > > > > file > > > > *file, struct ifreq *ifr) > > > > INIT_LIST_HEAD(&tun->disabled); > > > > err = tun_attach(tun, file, false); > > > > if (err < 0) > > > > - goto err_free_dev; > > > > + goto err_free_flow; > > > > > > > > err = register_netdevice(tun->dev); > > > > if (err < 0) > > > > - goto err_free_dev; > > > > + goto err_detach; > > > > > > > > if (device_create_file(&tun->dev->dev, > > > > &dev_attr_tun_flags) || > > > > device_create_file(&tun->dev->dev, &dev_attr_owner) > > > > || > > > > @@ -1689,6 +1689,11 @@ static int tun_set_iff(struct net *net, struct > > > > file > > > > *file, struct ifreq *ifr) > > > > strcpy(ifr->ifr_name, tun->dev->name); > > > > return 0; > > > > > > > > +err_detach: > > > > + tun_detach_all(dev); > > > > +err_free_flow: > > > > + tun_flow_uninit(tun); > > > > + security_tun_dev_free_security(tun->security); > > > > > > This bit looks wrong: if flow_init fails, we > > > need security_tun_dev_free_security, don't we? > > > I think we need: > > > +err_free_sec: security_tun_dev_free_security(tun->security); > > > and goto here on flow_init failures. > > > > tun_flow_init() always succeed. So we're ok here. > > True. So please make it return void then. > It has already returned void. > > > > > > > err_free_dev: > > > > > > Pls shift this one 1 space left for consistency. > > > > > > > Ok. > > > > free_netdev(dev); > > > > return err; > > > > -- > > > > 1.7.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/ > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] cpufreq: add new routine cpufreq_verify_within_cpu_limits()
Most of the users of cpufreq_verify_within_limits() calls it for limiting with
min/max from policy->cpuinfo. We can make that code simple by introducing
another routine which will do this for them automatically.
This patch adds another routine cpufreq_verify_within_cpu_limits() and updates
others to use it.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq-nforce2.c| 4 +---
drivers/cpufreq/davinci-cpufreq.c| 4 +---
drivers/cpufreq/freq_table.c | 6 ++
drivers/cpufreq/integrator-cpufreq.c | 9 ++---
drivers/cpufreq/intel_pstate.c | 4 +---
drivers/cpufreq/longrun.c| 4 +---
drivers/cpufreq/pcc-cpufreq.c| 3 +--
drivers/cpufreq/sh-cpufreq.c | 7 ++-
drivers/cpufreq/unicore2-cpufreq.c | 4 +---
include/linux/cpufreq.h | 7 +++
10 files changed, 19 insertions(+), 33 deletions(-)
diff --git a/drivers/cpufreq/cpufreq-nforce2.c
b/drivers/cpufreq/cpufreq-nforce2.c
index b83d45f6..56c964c 100644
--- a/drivers/cpufreq/cpufreq-nforce2.c
+++ b/drivers/cpufreq/cpufreq-nforce2.c
@@ -303,9 +303,7 @@ static int nforce2_verify(struct cpufreq_policy *policy)
if (policy->min < (fsb_pol_max * fid * 100))
policy->max = (fsb_pol_max + 1) * fid * 100;
- cpufreq_verify_within_limits(policy,
-policy->cpuinfo.min_freq,
-policy->cpuinfo.max_freq);
+ cpufreq_verify_within_cpu_limits(policy);
return 0;
}
diff --git a/drivers/cpufreq/davinci-cpufreq.c
b/drivers/cpufreq/davinci-cpufreq.c
index 551dd65..d049937 100644
--- a/drivers/cpufreq/davinci-cpufreq.c
+++ b/drivers/cpufreq/davinci-cpufreq.c
@@ -50,9 +50,7 @@ static int davinci_verify_speed(struct cpufreq_policy *policy)
if (policy->cpu)
return -EINVAL;
- cpufreq_verify_within_limits(policy, policy->cpuinfo.min_freq,
-policy->cpuinfo.max_freq);
-
+ cpufreq_verify_within_cpu_limits(policy);
policy->min = clk_round_rate(armclk, policy->min * 1000) / 1000;
policy->max = clk_round_rate(armclk, policy->max * 1000) / 1000;
cpufreq_verify_within_limits(policy, policy->cpuinfo.min_freq,
diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
index 53a2f1a..29ff77f 100644
--- a/drivers/cpufreq/freq_table.c
+++ b/drivers/cpufreq/freq_table.c
@@ -60,8 +60,7 @@ int cpufreq_frequency_table_verify(struct cpufreq_policy
*policy,
pr_debug("request for verification of policy (%u - %u kHz) for cpu
%u\n",
policy->min, policy->max, policy->cpu);
- cpufreq_verify_within_limits(policy, policy->cpuinfo.min_freq,
-policy->cpuinfo.max_freq);
+ cpufreq_verify_within_cpu_limits(policy);
for (; freq = table[i].frequency, freq != CPUFREQ_TABLE_END; i++) {
if (freq == CPUFREQ_ENTRY_INVALID)
@@ -77,8 +76,7 @@ int cpufreq_frequency_table_verify(struct cpufreq_policy
*policy,
if (!found) {
policy->max = next_larger;
- cpufreq_verify_within_limits(policy, policy->cpuinfo.min_freq,
- policy->cpuinfo.max_freq);
+ cpufreq_verify_within_cpu_limits(policy);
}
pr_debug("verification lead to (%u - %u kHz) for cpu %u\n",
diff --git a/drivers/cpufreq/integrator-cpufreq.c
b/drivers/cpufreq/integrator-cpufreq.c
index f7c99df..8152a9b 100644
--- a/drivers/cpufreq/integrator-cpufreq.c
+++ b/drivers/cpufreq/integrator-cpufreq.c
@@ -59,9 +59,7 @@ static int integrator_verify_policy(struct cpufreq_policy
*policy)
{
struct icst_vco vco;
- cpufreq_verify_within_limits(policy,
-policy->cpuinfo.min_freq,
-policy->cpuinfo.max_freq);
+ cpufreq_verify_within_cpu_limits(policy);
vco = icst_hz_to_vco(&cclk_params, policy->max * 1000);
policy->max = icst_hz(&cclk_params, vco) / 1000;
@@ -69,10 +67,7 @@ static int integrator_verify_policy(struct cpufreq_policy
*policy)
vco = icst_hz_to_vco(&cclk_params, policy->min * 1000);
policy->min = icst_hz(&cclk_params, vco) / 1000;
- cpufreq_verify_within_limits(policy,
-policy->cpuinfo.min_freq,
-policy->cpuinfo.max_freq);
-
+ cpufreq_verify_within_cpu_limits(policy);
return 0;
}
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 9733f29..a02bd77 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -611,9 +611,7 @@ static int intel_pstate_set_policy(struct cpufreq_policy
*policy)
static int intel_pstate_verify_policy(struct cpufreq_policy *policy)
{
- cpufreq_verify_within_limits(policy,
- policy->cpuinfo.min_freq,
-
[PATCH net V2] tuntap: correctly handle error in tun_set_iff()
Commit c8d68e6be1c3b242f1c598595830890b65cea64a (tuntap: multiqueue support) only call free_netdev() on error in tun_set_iff(). This causes several issues: - memory of tun security were leaked - use after free since the flow gc timer was not deleted and the tfile were not detached This patch solves the above issues. Reported-by: Wannes Rombouts Cc: Michael S. Tsirkin Signed-off-by: Jason Wang --- - Changes from V1: shift 1 space for label err_free_netdev and keep commit log under 70 chars per line. - The patch were needed for stable kernel 3.8+. --- drivers/net/tun.c | 11 --- 1 files changed, 8 insertions(+), 3 deletions(-) diff --git a/drivers/net/tun.c b/drivers/net/tun.c index a639de8..807815f 100644 --- a/drivers/net/tun.c +++ b/drivers/net/tun.c @@ -1641,11 +1641,11 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr) INIT_LIST_HEAD(&tun->disabled); err = tun_attach(tun, file, false); if (err < 0) - goto err_free_dev; + goto err_free_flow; err = register_netdevice(tun->dev); if (err < 0) - goto err_free_dev; + goto err_detach; if (device_create_file(&tun->dev->dev, &dev_attr_tun_flags) || device_create_file(&tun->dev->dev, &dev_attr_owner) || @@ -1689,7 +1689,12 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr) strcpy(ifr->ifr_name, tun->dev->name); return 0; - err_free_dev: +err_detach: + tun_detach_all(dev); +err_free_flow: + tun_flow_uninit(tun); + security_tun_dev_free_security(tun->security); +err_free_dev: free_netdev(dev); return err; } -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq_stats NULL deref on second system suspend
On 09/11/2013 04:04 AM, Rafael J. Wysocki wrote:
> On Tuesday, September 10, 2013 02:53:01 PM Stephen Warren wrote:
>> On 09/09/2013 05:14 PM, Rafael J. Wysocki wrote:
>>> On Monday, September 09, 2013 03:29:06 PM Stephen Warren wrote:
On 09/09/2013 02:24 PM, Rafael J. Wysocki wrote:
> On Monday, September 09, 2013 02:01:32 PM Stephen Warren wrote:
>> On 09/09/2013 02:01 PM, Rafael J. Wysocki wrote:
>>> On Monday, September 09, 2013 01:22:23 PM Stephen Warren wrote:
Viresh,
I'm seeing the crash below when suspending my system for the second
time.
I can avoid this with the following patch, which adds a check which
already exists in all-but-one other places that the same lookup is
made:
>>>
>>> Which kernel did you test?
>>
>> next-20130909.
>
> Is it reproducible with the current mainline?
This does not affect v3.11, but does affect current HEAD; 300893b "Merge
tag 'xfs-for-linus-v3.12-rc1' of git://oss.sgi.com/xfs/xfs".
>>>
>>> What system does it break on?
>>
>> A dual-core ARM system (NVIDIA Tegra20 SoC, Harmony board).
>>
>>> Any chance to bisect cpufreq changes between 3.11 and the current HEAD?
>>
>> Sure, it's due to 5302c3f "cpufreq: Perform light-weight init/teardown
>> during suspend/resume".
>
> Thanks!
>
> Srivatsa, any chance to look into this?
>
Sure, Rafael. Thanks for CC'ing me.
Stephen, I went through the code and I think I found out what is going wrong.
Can you please try the following patch?
Regards,
Srivatsa S. Bhat
From: Srivatsa S. Bhat
Subject: [PATCH] cpufreq: Fix crash in cpufreq-stats during suspend/resume
Stephen Warren reported that the cpufreq-stats code hits a NULL pointer
dereference during the second attempt to suspend a system. He also
pin-pointed the problem to commit 5302c3f "cpufreq: Perform light-weight
init/teardown during suspend/resume".
That commit actually ensured that the cpufreq-stats table and the
cpufreq-stats sysfs entries are *not* torn down (ie., not freed) during
suspend/resume, which makes it all the more surprising. However, it turns
out that the root-cause is not that we access an already freed memory, but
that the reference to the allocated memory gets moved around and we lose
track of that during resume, leading to the reported crash in a subsequent
suspend attempt.
In the suspend path, during CPU offline, the value of policy->cpu is updated
by choosing one of the surviving CPUs in that policy, as long as there is
atleast one CPU in that policy. And cpufreq_stats_update_policy_cpu() is
invoked to update the reference to the stats structure by assigning it to
the new CPU. However, in the resume path, during CPU online, we end up
assigning a fresh CPU as the policy->cpu, without letting cpufreq-stats
know about this. Thus the reference to the stats structure remains
(incorrectly) associated with the old CPU. So, in a subsequent suspend attempt,
during CPU offline, we end up accessing an incorrect location to get the
stats structure, which eventually leads to the NULL pointer dereference.
Fix this by letting cpufreq-stats know about the update of the policy->cpu
during CPU online in the resume path. (Also, move the update_policy_cpu()
function higher up in the file, so that __cpufreq_add_dev() can invoke
it).
Reported-by: Stephen Warren
Signed-off-by: Srivatsa S. Bhat
---
drivers/cpufreq/cpufreq.c | 37 -
1 file changed, 24 insertions(+), 13 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 5a64f66..62bdb95 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -947,6 +947,18 @@ static void cpufreq_policy_free(struct cpufreq_policy
*policy)
kfree(policy);
}
+static void update_policy_cpu(struct cpufreq_policy *policy, unsigned int cpu)
+{
+ policy->last_cpu = policy->cpu;
+ policy->cpu = cpu;
+
+#ifdef CONFIG_CPU_FREQ_TABLE
+ cpufreq_frequency_table_update_policy_cpu(policy);
+#endif
+ blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
+ CPUFREQ_UPDATE_POLICY_CPU, policy);
+}
+
static int __cpufreq_add_dev(struct device *dev, struct subsys_interface *sif,
bool frozen)
{
@@ -1000,7 +1012,18 @@ static int __cpufreq_add_dev(struct device *dev, struct
subsys_interface *sif,
if (!policy)
goto nomem_out;
- policy->cpu = cpu;
+
+ /*
+* In the resume path, since we restore a saved policy, the assignment
+* to policy->cpu is like an update of the existing policy, rather than
+* the creation of a brand new one. So we need to perform this update
+* by invoking update_policy_cpu().
+*/
+ if (frozen && cpu != policy->cpu)
+ update_policy_cpu(policy, cpu);
+
Re: [PATCH V3]hrtimer: Fix a performance regression by disable reprogramming in remove_hrtimer
On Wed, 2013-09-11 at 10:56 +0200, Peter Zijlstra wrote:
> On Mon, Sep 09, 2013 at 03:46:35PM +0200, Peter Zijlstra wrote:
> > On Mon, Sep 09, 2013 at 03:30:44PM +0200, Peter Zijlstra wrote:
> > > diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
> > > index fa6964d..486c0ba 100644
> > > --- a/drivers/idle/intel_idle.c
> > > +++ b/drivers/idle/intel_idle.c
> > > @@ -359,6 +359,14 @@ static int intel_idle(struct cpuidle_device *dev,
> > > if (!(lapic_timer_reliable_states & (1 << (cstate
> > > clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu);
> > >
> > > + current_thread_into()->status |= TS_POLLING;
> > > +
> > > + /*
> > > + * Order against setting of TS_POLLING against the reading of
> > > + * NEED_RESCHED, matched by resched_task().
> > > + */
> > > + smp_mb();
> > > +
> > > if (!need_resched()) {
> > >
> > > __monitor((void *)¤t_thread_info()->flags, 0, 0);
> > > @@ -367,6 +375,8 @@ static int intel_idle(struct cpuidle_device *dev,
> > > __mwait(eax, ecx);
> > > }
> > >
> > > + current_thread_into()->status &= ~TS_POLLING;
> > > +
> > > if (!(lapic_timer_reliable_states & (1 << (cstate
> > > clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu);
> >
> > Hmm, arguably it would be better to set this from
> > intel_idle_cpuidle_driver_init() and clear it whenever this goes away.
> > Not sure how all that works, the cpuidle driver framework seems 'weird'.
>
> OK, so I went over the idle stuff again, and we do set TS_POLLING like
> stuff, it got hidden in current_{clr,set}_polling().
>
> Still if that patch causes extra IPIs its bound to be broken in some
> creative way.. I'll prod.
(thanks, when I get a break from testing/poking this'n'that, I'll take a
peek too... well, good_intentions++ anyway;)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
On Wed, 11 Sep 2013, Matthew Garrett wrote: > On Wed, 2013-09-11 at 11:45 +0300, Jani Nikula wrote: > >> Before plunging forward, have you observed any difference between the >> boot modes? We have reports [1] that the backlight behaviour is >> different with UEFI vs. UEFI+CSM or legacy boot. So I'm wondering if the >> acpi_gbl_osi_data >= ACPI_OSI_WIN_8 check in patch 2/2 is the whole >> story. >> >> Further, if we tell the BIOS we're Windows 8 to use the tested BIOS code >> paths, what guarantees do we have of UEFI+CSM or legacy boots working? > > We have no evidence of Windows behaving differently based on the exposed > firmware type. By "behaving differently", do you mean internally adapting to the boot mode, or exhibiting different behaviour to the user? We have evidence of the firmware behaving differently (VBT, backlight) based on the boot mode, all else being equal. We don't adapt to that, and we fail. I don't know if we should adapt, or do things differently altogether. I don't even know if Windows 8 works on all boot modes on the machines in question. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sparc: fix MSI build failure on Sparc32
Commit ebd97be635 ('PCI: remove ARCH_SUPPORTS_MSI kconfig option')
removes the ARCH_SUPPORTS_MSI Kconfig option that allowed
architectures to indicate whether they support PCI MSI or not. Now,
PCI MSI support can be compiled in on any architecture thanks to the
use of weak functions thanks to 4287d824f265 ('PCI: use weak functions
for MSI arch-specific functions').
So, architecture specific code is now responsible to ensure that its
PCI MSI code builds in all cases, or be appropriately conditionally
compiled.
On Sparc, the MSI support is only provided for Sparc64, so the
ARCH_SUPPORTS_MSI kconfig option was only selected for SPARC64, and
not for the Sparc architecture as a whole. Therefore, removing
ARCH_SUPPORTS_MSI broke Sparc32 configurations with CONFIG_PCI_MSI=y,
because the Sparc-specific MSI code is not designed to be built on
Sparc32.
To solve this, this commit ensures that the Sparc MSI code is only
built on Sparc64. This is done thanks to a new Kconfig Makefile helper
option SPARC64_PCI_MSI, modeled after the existing SPARC64_PCI. The
SPARC64_PCI_MSI option is an hidden option that is true when both
Sparc64 PCI support is enabled and MSI is enabled. The
arch/sparc/kernel/pci_msi.c file is now only built when
SPARC64_PCI_MSI is true.
Signed-off-by: Thomas Petazzoni
Reported-by: Guenter Roeck
---
arch/sparc/Kconfig | 7 ++-
arch/sparc/kernel/Makefile | 3 ++-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 1570ad2..a284efa 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -507,12 +507,17 @@ config SUN_OPENPROMFS
Only choose N if you know in advance that you will not need to modify
OpenPROM settings on the running system.
-# Makefile helper
+# Makefile helpers
config SPARC64_PCI
bool
default y
depends on SPARC64 && PCI
+config SPARC64_PCI_MSI
+ bool
+ default y
+ depends on SPARC64_PCI && PCI_MSI
+
endmenu
menu "Executable file formats"
diff --git a/arch/sparc/kernel/Makefile b/arch/sparc/kernel/Makefile
index d432fb2..d15cc17 100644
--- a/arch/sparc/kernel/Makefile
+++ b/arch/sparc/kernel/Makefile
@@ -1,3 +1,4 @@
+
#
# Makefile for the linux kernel.
#
@@ -99,7 +100,7 @@ obj-$(CONFIG_STACKTRACE) += stacktrace.o
obj-$(CONFIG_SPARC64_PCI)+= pci.o pci_common.o psycho_common.o
obj-$(CONFIG_SPARC64_PCI)+= pci_psycho.o pci_sabre.o pci_schizo.o
obj-$(CONFIG_SPARC64_PCI)+= pci_sun4v.o pci_sun4v_asm.o pci_fire.o
-obj-$(CONFIG_PCI_MSI)+= pci_msi.o
+obj-$(CONFIG_SPARC64_PCI_MSI) += pci_msi.o
obj-$(CONFIG_COMPAT) += sys32.o sys_sparc32.o signal32.o
--
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/
Re: [PATCH 2/2] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
On Wed, 2013-09-11 at 13:29 +0300, Jani Nikula wrote:
> On Wed, 11 Sep 2013, Matthew Garrett wrote:
> > On Wed, 2013-09-11 at 11:45 +0300, Jani Nikula wrote:
> >
> >> Before plunging forward, have you observed any difference between the
> >> boot modes? We have reports [1] that the backlight behaviour is
> >> different with UEFI vs. UEFI+CSM or legacy boot. So I'm wondering if the
> >> acpi_gbl_osi_data >= ACPI_OSI_WIN_8 check in patch 2/2 is the whole
> >> story.
> >>
> >> Further, if we tell the BIOS we're Windows 8 to use the tested BIOS code
> >> paths, what guarantees do we have of UEFI+CSM or legacy boots working?
> >
> > We have no evidence of Windows behaving differently based on the exposed
> > firmware type.
>
> By "behaving differently", do you mean internally adapting to the boot
> mode, or exhibiting different behaviour to the user?
As far as backlight control goes, both.
> We have evidence of the firmware behaving differently (VBT, backlight)
> based on the boot mode, all else being equal. We don't adapt to that,
> and we fail. I don't know if we should adapt, or do things differently
> altogether. I don't even know if Windows 8 works on all boot modes on
> the machines in question.
Sure, but Windows knows nothing about VBT or opregion-backed backlight
control. That's up to the Intel driver.
--
Matthew Garrett
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH net V2] tuntap: correctly handle error in tun_set_iff()
On Wed, Sep 11, 2013 at 06:09:48PM +0800, Jason Wang wrote: > Commit c8d68e6be1c3b242f1c598595830890b65cea64a > (tuntap: multiqueue support) only call free_netdev() on error in > tun_set_iff(). This causes several issues: > > - memory of tun security were leaked > - use after free since the flow gc timer was not deleted and the tfile > were not detached > > This patch solves the above issues. > > Reported-by: Wannes Rombouts > Cc: Michael S. Tsirkin > Signed-off-by: Jason Wang Acked-by: Michael S. Tsirkin > --- > - Changes from V1: shift 1 space for label err_free_netdev and keep > commit log under 70 chars per line. > - The patch were needed for stable kernel 3.8+. > --- > drivers/net/tun.c | 11 --- > 1 files changed, 8 insertions(+), 3 deletions(-) > > diff --git a/drivers/net/tun.c b/drivers/net/tun.c > index a639de8..807815f 100644 > --- a/drivers/net/tun.c > +++ b/drivers/net/tun.c > @@ -1641,11 +1641,11 @@ static int tun_set_iff(struct net *net, struct file > *file, struct ifreq *ifr) > INIT_LIST_HEAD(&tun->disabled); > err = tun_attach(tun, file, false); > if (err < 0) > - goto err_free_dev; > + goto err_free_flow; > > err = register_netdevice(tun->dev); > if (err < 0) > - goto err_free_dev; > + goto err_detach; > > if (device_create_file(&tun->dev->dev, &dev_attr_tun_flags) || > device_create_file(&tun->dev->dev, &dev_attr_owner) || > @@ -1689,7 +1689,12 @@ static int tun_set_iff(struct net *net, struct file > *file, struct ifreq *ifr) > strcpy(ifr->ifr_name, tun->dev->name); > return 0; > > - err_free_dev: > +err_detach: > + tun_detach_all(dev); > +err_free_flow: > + tun_flow_uninit(tun); > + security_tun_dev_free_security(tun->security); > +err_free_dev: > free_netdev(dev); > return err; > } > -- > 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq_stats NULL deref on second system suspend
On 11 September 2013 15:51, Srivatsa S. Bhat
wrote:
> On 09/11/2013 04:04 AM, Rafael J. Wysocki wrote:
>> On Tuesday, September 10, 2013 02:53:01 PM Stephen Warren wrote:
>>> Sure, it's due to 5302c3f "cpufreq: Perform light-weight init/teardown
>>> during suspend/resume".
Sorry Stephen, I was away on vacations and came back yesterday only..
And was badly stuck in something other CPUFreq bugs until now :)
> Sure, Rafael. Thanks for CC'ing me.
Thanks for jumping in and helping us out buddy!!!.
> Stephen, I went through the code and I think I found out what is going wrong.
> Can you please try the following patch?
>
> Regards,
> Srivatsa S. Bhat
>
>
>
>
> From: Srivatsa S. Bhat
> Subject: [PATCH] cpufreq: Fix crash in cpufreq-stats during suspend/resume
>
> Stephen Warren reported that the cpufreq-stats code hits a NULL pointer
> dereference during the second attempt to suspend a system. He also
> pin-pointed the problem to commit 5302c3f "cpufreq: Perform light-weight
> init/teardown during suspend/resume".
>
> That commit actually ensured that the cpufreq-stats table and the
> cpufreq-stats sysfs entries are *not* torn down (ie., not freed) during
> suspend/resume, which makes it all the more surprising. However, it turns
> out that the root-cause is not that we access an already freed memory, but
> that the reference to the allocated memory gets moved around and we lose
> track of that during resume, leading to the reported crash in a subsequent
> suspend attempt.
>
> In the suspend path, during CPU offline, the value of policy->cpu is updated
> by choosing one of the surviving CPUs in that policy, as long as there is
> atleast one CPU in that policy. And cpufreq_stats_update_policy_cpu() is
> invoked to update the reference to the stats structure by assigning it to
> the new CPU. However, in the resume path, during CPU online, we end up
> assigning a fresh CPU as the policy->cpu, without letting cpufreq-stats
> know about this. Thus the reference to the stats structure remains
> (incorrectly) associated with the old CPU. So, in a subsequent suspend
> attempt,
> during CPU offline, we end up accessing an incorrect location to get the
> stats structure, which eventually leads to the NULL pointer dereference.
>
> Fix this by letting cpufreq-stats know about the update of the policy->cpu
> during CPU online in the resume path. (Also, move the update_policy_cpu()
> function higher up in the file, so that __cpufreq_add_dev() can invoke
> it).
Observation looks good..
> Reported-by: Stephen Warren
> Signed-off-by: Srivatsa S. Bhat
> ---
>
> drivers/cpufreq/cpufreq.c | 37 -
> 1 file changed, 24 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 5a64f66..62bdb95 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -947,6 +947,18 @@ static void cpufreq_policy_free(struct cpufreq_policy
> *policy)
> kfree(policy);
> }
>
> +static void update_policy_cpu(struct cpufreq_policy *policy, unsigned int
> cpu)
> +{
> + policy->last_cpu = policy->cpu;
> + policy->cpu = cpu;
> +
> +#ifdef CONFIG_CPU_FREQ_TABLE
> + cpufreq_frequency_table_update_policy_cpu(policy);
> +#endif
> + blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
> + CPUFREQ_UPDATE_POLICY_CPU, policy);
> +}
> +
> static int __cpufreq_add_dev(struct device *dev, struct subsys_interface
> *sif,
> bool frozen)
> {
> @@ -1000,7 +1012,18 @@ static int __cpufreq_add_dev(struct device *dev,
> struct subsys_interface *sif,
> if (!policy)
> goto nomem_out;
>
> - policy->cpu = cpu;
> +
> + /*
> +* In the resume path, since we restore a saved policy, the assignment
> +* to policy->cpu is like an update of the existing policy, rather
> than
> +* the creation of a brand new one. So we need to perform this update
> +* by invoking update_policy_cpu().
> +*/
> + if (frozen && cpu != policy->cpu)
> + update_policy_cpu(policy, cpu);
> + else
> + policy->cpu = cpu;
> +
> policy->governor = CPUFREQ_DEFAULT_GOVERNOR;
> cpumask_copy(policy->cpus, cpumask_of(cpu));
>
> @@ -1092,18 +1115,6 @@ static int cpufreq_add_dev(struct device *dev, struct
> subsys_interface *sif)
> return __cpufreq_add_dev(dev, sif, false);
> }
>
> -static void update_policy_cpu(struct cpufreq_policy *policy, unsigned int
> cpu)
> -{
> - policy->last_cpu = policy->cpu;
> - policy->cpu = cpu;
> -
> -#ifdef CONFIG_CPU_FREQ_TABLE
> - cpufreq_frequency_table_update_policy_cpu(policy);
> -#endif
> - blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
> - CPUFREQ_UPDATE_POLICY_CPU, policy);
> -}
> -
But I would h
Re: cpufreq_stats NULL deref on second system suspend
On 11 September 2013 16:14, Viresh Kumar wrote: > But I would have solved it differently :) > > We don't really need to call update_policy_cpu() again and again > as we don't really need to update policy->cpu... > > Rather it would be better to just move following inside > cpufreq_policy_alloc(): Half written mail sent :( What about moving following to cpufreq_policy_alloc(): policy->cpu = cpu; ?? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: 3.10.5: rcu_sched detected stalls on CPUs/tasks
Hello, On Tue, Sep 10, 2013 at 10:54:53AM -0700, Paul E. McKenney wrote: > Their stall was due to old-style creation of sysfs entries for memory. > Yours might be having a similar issue with the creation of /dev entries, > so it would be worth trying it. OK, compiling 3.10.11 with your patch right now. > One thing to try would be to insert delays into the code involved in > creating the /dev entries. These delays will need to be busy-waits > rather than sleeps. Uh, I will have a look. But I'm no kernel developer. :) Best greetings, Jochen. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ASLR creates bad memory layout for PIE
Hi, It seems that ASLR with PIE binaries (linux-3.11.0-vanilla on ARM) seems to create bad memory layout - the programs run out of memory relatively soon, especially if they also mmap() lot of memory. I believe the problem is that fs/binfmt_elf.c:load_elf_binary() sets load_bias to 0 when CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE is set (true for arm). This causes the following elf_map() to get zero addr (vaddr is zero also for the main program PT_LOAD), and we get the main binary mmapped to random position from the regular mmap area. Thus, brk is also in the same area. I believe load_elf_binary() should instead manually randomize load_bias to be within beginning of the user address space (or at least somewhere close to ELF_ET_DYN_BASE). This would avoid the very restricted heap size what we get now. The memory layout I get on my arm board, with PIE executables and randomize_va_space=2 (boot time default): b6db2000-b6df4000 r-xp 00:0f 5682 /usr/lib/libncurses.so.5.9 b6df4000-b6df7000 rw-p 0003a000 00:0f 5682 /usr/lib/libncurses.so.5.9 b6df7000-b6e31000 r-xp 00:0f 7364 /usr/lib/libreadline.so.6.2 b6e31000-b6e35000 rw-p 00032000 00:0f 7364 /usr/lib/libreadline.so.6.2 b6e35000-b6e36000 rw-p 00:00 0 b6e36000-b6eb3000 r-xp 00:0f 3233 /lib/ld-musl-armhf.so.1 b6eb9000-b6eba000 r-xp 00:00 0 [sigpage] b6eba000-b6ebc000 rw-p 0007c000 00:0f 3233 /lib/ld-musl-armhf.so.1 b6ebc000-b6ebd000 rw-p 00:00 0 b6ebd000-b6f6 r-xp 00:0f 7368 /bin/bash b6f68000-b6f6c000 rw-p 000a3000 00:0f 7368 /bin/bash b6f6c000-b6f7 rw-p 00:00 0 b7641000-b764e000 rw-p 00:00 0 [heap] becd2000-becf3000 rw-p 00:00 0 [stack] -1000 r-xp 00:00 0 [vectors] And with randomize_vaspace=0: 2a00-2a0a3000 r-xp 00:0f 7368 /bin/bash 2a0ab000-2a0af000 rw-p 000a3000 00:0f 7368 /bin/bash 2a0af000-2a0bf000 rw-p 00:00 0 [heap] b6ef5000-b6f37000 r-xp 00:0f 5682 /usr/lib/libncurses.so.5.9 b6f37000-b6f3a000 rw-p 0003a000 00:0f 5682 /usr/lib/libncurses.so.5.9 b6f3a000-b6f74000 r-xp 00:0f 7364 /usr/lib/libreadline.so.6.2 b6f74000-b6f78000 rw-p 00032000 00:0f 7364 /usr/lib/libreadline.so.6.2 b6f78000-b6f79000 rw-p 00:00 0 b6f79000-b6ff6000 r-xp 00:0f 3233 /lib/ld-musl-armhf.so.1 b6ffc000-b6ffd000 r-xp 00:00 0 [sigpage] b6ffd000-b6fff000 rw-p 0007c000 00:0f 3233 /lib/ld-musl-armhf.so.1 b6fff000-b700 rw-p 00:00 0 befdf000-bf00 rw-p 00:00 0 [stack] -1000 r-xp 00:00 0 [vectors] Any comments, or suggestions? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] more s390 updates for 3.12 merge window
Hi Linus, please pull from git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus to receive a couple of s390 updates for 3.12. This includes one bpf/jit bug fix where the jit compiler could sometimes write generated code out of bounds of the allocated memory area. The rest of the patches are only cleanups and minor improvements. Thanks, Heiko --- Heiko Carstens (13): s390/bpf,jit: fix address randomization s390: update defconfig s390/dumpstack: convert print_symbol to %pSR s390/irq: use hlists for external interrupt handler array s390/irq: rework irq subclass handling s390: keep Kconfig sorted s390/mm: add __releases()/__acquires() annotations to gmap_alloc_table() s390/compat signal: add couple of __force annotations s390: make various functions static, add declarations to header files s390/ftrace: avoid pointer arithmetics with function pointers s390/ap_bus: use and-mask instead of a cast s390/compat,uid16: use current_cred() s390/irq: reduce size of external interrupt handler hash array Hendrik Brueckner (1): s390/perf: Remove print_hex_dump_bytes() debug output arch/s390/Kconfig| 6 +-- arch/s390/defconfig | 39 -- arch/s390/include/asm/irq.h | 12 -- arch/s390/kernel/compat_linux.c | 9 +++-- arch/s390/kernel/compat_signal.c | 10 ++--- arch/s390/kernel/dumpstack.c | 20 +- arch/s390/kernel/entry.h | 18 +++-- arch/s390/kernel/ftrace.c| 5 ++- arch/s390/kernel/irq.c | 85 +++- arch/s390/kernel/machine_kexec.c | 2 +- arch/s390/kernel/perf_cpum_cf.c | 4 +- arch/s390/kernel/perf_event.c| 5 +-- arch/s390/kernel/runtime_instr.c | 4 +- arch/s390/kernel/smp.c | 2 +- arch/s390/kernel/suspend.c | 1 + arch/s390/mm/fault.c | 2 +- arch/s390/mm/maccess.c | 1 + arch/s390/mm/pgtable.c | 6 ++- arch/s390/net/bpf_jit_comp.c | 2 +- arch/s390/oprofile/hwsampler.c | 6 +-- drivers/s390/block/dasd_diag.c | 4 +- drivers/s390/char/fs3270.c | 6 +-- drivers/s390/char/sclp.c | 6 +-- drivers/s390/char/tty3270.c | 6 +-- drivers/s390/crypto/ap_bus.c | 2 +- drivers/s390/kvm/kvm_virtio.c| 2 +- 26 files changed, 130 insertions(+), 135 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 0/5] CPUFreq: Last set of updates for 3.13
On Wed, Sep 11, 2013 at 3:43 PM, Viresh Kumar wrote: > Hi Rafael, > > I really tried to stop after you asked me to, but still got few more patches.. > These are very minor changes and a fairly smaller patchset.. > > I have rebased this over your linux-next branch > > 7c218b1 Merge branch 'acpi-bind-next' into linux-next > > and tested over my exynos board.. I don't expect them to do any crappy stuff.. > > You can include these first (if they look fine) and then I will send all other > patches that I have queued up for 3.13.. I will send all of them in one lot, > with partition numbers mentioned (i.e. patches that should go together) and > then > you can apply them the way you wish.. Set by set or all at once.. > > Thanks.. Viresh, Thanks for the great work cleaning up all the drivers. IIUC, you have ~200 patches lined up for the 3.13 merge window. That causes some worries. Can we quickly do the following to get more confidence that there won't be wide-spread breakage: 1. Get all of these into linux-next quickly 2. Set up a LAVA[1] job to get linux-next kernels running on boards in our farm 3. Run cpufreq functional tests, e.g. PM-QA[2] test suite from Linaro with these kernels Regards, Amit [1] An automated test harness used by Linaro [2] https://git.linaro.org/gitweb?p=tools/pm-qa.git;a=tree;f=cpufreq;h=b53f7ad0fe778011d75e94ec7bd2b2fc1fc4cfd7;hb=HEAD -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] ARM64: Split out CONFIG_ARM64_AARCH32 from CONFIG_COMPAT. Signed-off-by: Andrew Pinski
Hi Andrew,
On Mon, Sep 09, 2013 at 10:32:55PM +0100, Andrew Pinski wrote:
> Right now CONFIG_COMPAT means enabling AARCH32 support in the ARM64 traget,
> which we want to split out so we can it to mean any 32bit ABI support instead.
First, there are some coding style and patch format issues. Please pass
the patches through checkpatch.pl.
Also, I would like to see a cover letter giving an overview of the ABI
changes needed for arm64 ILP32 and better, longer patch description. At
a first look, you would think that this simply changes CONFIG_COMPAT to
CONFIG_ARM64_AARCH32 but you have other changes like compat_elf_greg_t
types.
More comments below.
> --- a/arch/arm64/include/asm/compat.h
> +++ b/arch/arm64/include/asm/compat.h
> @@ -279,28 +279,52 @@ struct compat_shmid64_ds {
> compat_ulong_t __unused5;
> };
>
> -static inline int is_compat_task(void)
> +#if defined(CONFIG_ARM64_AARCH32)
> +static inline int is_aarch32_task(void)
> {
> return test_thread_flag(TIF_32BIT);
> }
>
> -static inline int is_compat_thread(struct thread_info *thread)
> +static inline int is_aarch32_thread(struct thread_info *thread)
> {
> return test_ti_thread_flag(thread, TIF_32BIT);
> }
> +#else
> +static inline int is_aarch32_task(void)
> +{
> + return 0;
> +}
> +
> +static inline int is_aarch32_thread(struct thread_info *thread)
> +{
> + return 0;
> +}
> +#endif
> +
>
> #else /* !CONFIG_COMPAT */
Is the comment still correct here?
> -static inline int is_compat_task(void)
> +static inline int is_aarch32_task(void)
> {
> return 0;
> }
>
> -static inline int is_compat_thread(struct thread_info *thread)
> +static inline int is_aarch32_thread(struct thread_info *thread)
> {
> return 0;
> }
>
> #endif /* CONFIG_COMPAT */
Same here.
> diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
> index e7fa87f..0a89e94 100644
> --- a/arch/arm64/include/asm/elf.h
> +++ b/arch/arm64/include/asm/elf.h
> @@ -153,24 +153,33 @@ extern unsigned long arch_randomize_brk(struct
> mm_struct *mm);
>
> #define COMPAT_ELF_ET_DYN_BASE (randomize_et_dyn(2 * TASK_SIZE_32 /
> 3))
>
> +#ifdef CONFIG_ARM64_AARCH32
> /* AArch32 registers. */
> #define COMPAT_ELF_NGREG 18
> -typedef unsigned int compat_elf_greg_t;
> -typedef compat_elf_greg_t
> compat_elf_gregset_t[COMPAT_ELF_NGREG];
> +typedef unsigned int compat_a32_elf_greg_t;
> +typedef compat_a32_elf_greg_t compat_a32_elf_gregset_t[COMPAT_ELF_NGREG];
I'm not sure we need to bother placing typedefs under #ifdef. I'll have
to see how this file is modified in later patches.
>
> /* AArch32 EABI. */
> #define EF_ARM_EABI_MASK 0xff00
> -#define compat_elf_check_arch(x) (((x)->e_machine == EM_ARM) && \
> +#define compat_elf_a32_check_arch(x) (((x)->e_machine == EM_ARM) && \
> ((x)->e_flags & EF_ARM_EABI_MASK))
>
> -#define compat_start_threadcompat_start_thread
> -#define COMPAT_SET_PERSONALITY(ex) set_thread_flag(TIF_32BIT);
> +#define COMPAT_SET_A32_PERSONALITY(ex) set_thread_flag(TIF_32BIT);
> #define COMPAT_ARCH_DLINFO
> +
> extern int aarch32_setup_vectors_page(struct linux_binprm *bprm,
> int uses_interp);
> #define compat_arch_setup_additional_pages \
> aarch32_setup_vectors_page
>
> +typedef compat_a32_elf_greg_t compat_elf_greg_t;
> +typedef compat_a32_elf_gregset_t compat_elf_gregset_t;
> +#endif
> +
> +#define compat_elf_check_arch(x) compat_elf_a32_check_arch(x)
> +#define COMPAT_SET_PERSONALITY(ex) COMPAT_SET_A32_PERSONALITY(x)
> +#define compat_start_threadcompat_start_thread
> +
> #endif /* CONFIG_COMPAT */
Mismatched comment?
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index 20925bc..4a644a5 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -49,11 +49,11 @@
>
> #ifdef CONFIG_COMPAT
> #define TASK_SIZE_32 UL(0x1)
> -#define TASK_SIZE (test_thread_flag(TIF_32BIT) ? \
> +#define TASK_SIZE (is_compat_task() ? \
> TASK_SIZE_32 : TASK_SIZE_64)
Does this file also need to include compat.h?
> --- a/arch/arm64/include/asm/processor.h
> +++ b/arch/arm64/include/asm/processor.h
> @@ -38,7 +38,7 @@
> #define STACK_TOP_MAX TASK_SIZE_64
> #ifdef CONFIG_COMPAT
> #define AARCH32_VECTORS_BASE 0x
> -#define STACK_TOP (test_thread_flag(TIF_32BIT) ? \
> +#define STACK_TOP (is_compat_task() ? \
> AARCH32_VECTORS_BASE : STACK_TOP_MAX)
Same here.
> --- a/arch/arm64/include/asm/ptrace.h
> +++ b/arch/arm64/include/asm/ptrace.h
> @@ -107,7 +107,7 @@ struct pt_regs {
>
> #define arch_has_single_step() (1)
>
> -#ifd
Re: [PATCH net] tuntap: correctly handle error in tun_set_iff()
On Wed, Sep 11, 2013 at 01:08:04PM +0300, Michael S. Tsirkin wrote: > On Wed, Sep 11, 2013 at 05:55:04AM -0400, Jason Wang wrote: > > > > > > - Original Message - > > > On Wed, Sep 11, 2013 at 04:24:05PM +0800, Jason Wang wrote: > > > > Commit c8d68e6be1c3b242f1c598595830890b65cea64a (tuntap: multiqueue > > > > support) > > > > only call free_netdev() on err in tun_set_iff(). This causes several > > > > issues: > > > > > > > > - memory of tun security were leaked > > > > > > Not just tun security - sock reference too (didn't detach) > > > > > > > Yes, I mention it in the next item. > > That line's a bit too long btw. > Keep it under 70 chars for commit logs. > > > > > - use after free since the flow gc timer was not deleted and the tfile > > > > were > > > > not > > > > detached > > > > > > > > This patch solves the above issues. > > > > > > > > Reported-by: Wannes Rombouts > > > > Cc: Michael S. Tsirkin > > > > Signed-off-by: Jason Wang > > > > --- > > > > The patch were also needed for stable 3.8+. > > > > --- > > > > drivers/net/tun.c |9 +++-- > > > > 1 files changed, 7 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/drivers/net/tun.c b/drivers/net/tun.c > > > > index a639de8..e5fb5d3 100644 > > > > --- a/drivers/net/tun.c > > > > +++ b/drivers/net/tun.c > > > > @@ -1641,11 +1641,11 @@ static int tun_set_iff(struct net *net, struct > > > > file > > > > *file, struct ifreq *ifr) > > > > INIT_LIST_HEAD(&tun->disabled); > > > > err = tun_attach(tun, file, false); > > > > if (err < 0) > > > > - goto err_free_dev; > > > > + goto err_free_flow; > > > > > > > > err = register_netdevice(tun->dev); > > > > if (err < 0) > > > > - goto err_free_dev; > > > > + goto err_detach; > > > > > > > > if (device_create_file(&tun->dev->dev, > > > > &dev_attr_tun_flags) || > > > > device_create_file(&tun->dev->dev, &dev_attr_owner) > > > > || > > > > @@ -1689,6 +1689,11 @@ static int tun_set_iff(struct net *net, struct > > > > file > > > > *file, struct ifreq *ifr) > > > > strcpy(ifr->ifr_name, tun->dev->name); > > > > return 0; > > > > > > > > +err_detach: > > > > + tun_detach_all(dev); > > > > +err_free_flow: > > > > + tun_flow_uninit(tun); > > > > + security_tun_dev_free_security(tun->security); > > > > > > This bit looks wrong: if flow_init fails, we > > > need security_tun_dev_free_security, don't we? > > > I think we need: > > > +err_free_sec: security_tun_dev_free_security(tun->security); > > > and goto here on flow_init failures. > > > > tun_flow_init() always succeed. So we're ok here. > > True. So please make it return void then. Heh I was looking at a stale tree, this is already fixed in commit 944a1376b. > > > > > > > err_free_dev: > > > > > > Pls shift this one 1 space left for consistency. > > > > > > > Ok. > > > > free_netdev(dev); > > > > return err; > > > > -- > > > > 1.7.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/ > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] am335x-boneblack: add eMMC DT entry
Op 11 sep. 2013, om 12:06 heeft Sekhar Nori het volgende
geschreven:
> On Wednesday 11 September 2013 11:42 AM, Koen Kooi wrote:
>> Signed-off-by: Koen Kooi
>> ---
>> arch/arm/boot/dts/am335x-bone-common.dtsi | 7 +++
>> arch/arm/boot/dts/am335x-boneblack.dts| 15 +++
>> 2 files changed, 22 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
>> b/arch/arm/boot/dts/am335x-bone-common.dtsi
>> index ced256c..9c61fef 100644
>> --- a/arch/arm/boot/dts/am335x-bone-common.dtsi
>> +++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
>> @@ -241,6 +241,13 @@
>> regulator-always-on;
>> };
>> };
>> +
>> +vmmcsd_fixed: fixedregulator@0 {
>> +compatible = "regulator-fixed";
>> +regulator-name = "vmmcsd_fixed";
>> +regulator-min-microvolt = <330>;
>> +regulator-max-microvolt = <330>;
>> +};
>> };
>>
>> &cpsw_emac0 {
>> diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
>> b/arch/arm/boot/dts/am335x-boneblack.dts
>> index 197cadf..c09947a 100644
>> --- a/arch/arm/boot/dts/am335x-boneblack.dts
>> +++ b/arch/arm/boot/dts/am335x-boneblack.dts
>> @@ -15,3 +15,18 @@
>> regulator-max-microvolt = <180>;
>> regulator-always-on;
>> };
>> +
>> +&mmc1 {
>> +vmmc-supply = <&vmmcsd_fixed>;
>> +};
>> +
>> +&mmc2 {
>> +vmmc-supply = <&vmmcsd_fixed>;
>> +pinctrl-names = "default";
>> +pinctrl-0 = <&emmc_pins>;
>> +bus-width = <8>;
>> +ti,non-removable;
>
> There is a standard binding available for this: "non-removable"
> There should not be a need to introduce a TI specific binding for this
> (I know this is not your fault).
>
> I will send a patch to change the existing .dts files and update the
> driver - can you drop this line for now so we don't introduce more
> incompatibilities? I can send a patch adding "non-removable" to this
> node as part of my clean-up series.
Sure, I'll send a v2 shortly. Thank you very much for killing another ti,
prefixed node!
regards,
Koen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] ARM64: Move some signal code to a seperate file to be reused by ILP32.
On Mon, Sep 09, 2013 at 10:32:56PM +0100, Andrew Pinski wrote: > Since the ILP32 ABI uses similar signal code as the LP64 ABI, it makes sense > to reuse rather > than copy the same code. At a first look, I don't really like this part. I'll comment more on the last patch. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] CPUFreq: Last set of updates for 3.13
On 11 September 2013 16:23, Amit Kucheria wrote: > Thanks for the great work cleaning up all the drivers. IIUC, you have > ~200 patches lined up for the 3.13 merge window. 227 to be precise :) > That causes some worries. > > Can we quickly do the following to get more confidence that there > won't be wide-spread breakage: > > 1. Get all of these into linux-next quickly Yes, even Myself and Rafael wanted to do that.. And were waiting for pull request to go for 3.12-rc1.. I am mostly ready with my patches, wouldn't take long time for me to review those completely before sending them.. > 2. Set up a LAVA[1] job to get linux-next kernels running on boards in our > farm > 3. Run cpufreq functional tests, e.g. PM-QA[2] test suite from Linaro > with these kernels That would be nice actually.. Anyway some people would test it on linux-next, but doing that for few boards by Linaro would be Awesome.. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
