[PATCH v6 2/3] dm: export a table+mapped device to the ioctl interface

From: Will Drewry One function is added which allows for a programmatically created mapped device to be inserted into the dm-ioctl hash table. This binds the device to a name and, optional, uuid which is needed by udev and allows for userspace management of the mapped device. Signed-off-by:

[patch V2 06/10] timer: Restructure internal locking

Move the locking out from __run_timers() to the call sites, so the protected section can be extended at the call site. Preparatory patch for changing the NOHZ timer placement to a pull at expiry time model. No functional change. Signed-off-by: Richard Cochran Signed-off-by: Anna-Maria Gleixner

Re: [PATCH -v2 0/9] mm: make movable onlining suck less

On Tue, Apr 18, 2017 at 12:14 AM, Michal Hocko wrote: > On Mon 17-04-17 14:51:12, Dan Williams wrote: >> On Tue, Apr 11, 2017 at 10:03 AM, Michal Hocko wrote: >> > All the reported issue seem to be fixed and pushed to my git tree >> >

Re: [PATCH -v2 0/9] mm: make movable onlining suck less

On Tue, Apr 18, 2017 at 12:14 AM, Michal Hocko wrote: > On Mon 17-04-17 14:51:12, Dan Williams wrote: >> On Tue, Apr 11, 2017 at 10:03 AM, Michal Hocko wrote: >> > All the reported issue seem to be fixed and pushed to my git tree >> > attempts/rewrite-mem_hotplug branch. I will wait a day or two

[patch V2 04/10] timer: Keep the pinned timers separate from the others

Seperate the storage space for pinned timers. This is preparatory work for changing the NOHZ timer placement from a push at enqueue time to a pull at expiry time model. No functional change. Signed-off-by: Richard Cochran Signed-off-by: Anna-Maria Gleixner

[patch V2 04/10] timer: Keep the pinned timers separate from the others

Seperate the storage space for pinned timers. This is preparatory work for changing the NOHZ timer placement from a push at enqueue time to a pull at expiry time model. No functional change. Signed-off-by: Richard Cochran Signed-off-by: Anna-Maria Gleixner Signed-off-by: Thomas Gleixner ---

[patch V2 03/10] timers: Rework idle logic

Storing next event and determining whether the base is idle can be done in __next_timer_interrupt(). Preparatory patch for new call sites which need this information as well. Signed-off-by: Thomas Gleixner --- kernel/time/timer.c | 43

[patch V2 03/10] timers: Rework idle logic

Storing next event and determining whether the base is idle can be done in __next_timer_interrupt(). Preparatory patch for new call sites which need this information as well. Signed-off-by: Thomas Gleixner --- kernel/time/timer.c | 43 --- 1 file

[patch V2 02/10] timerqueue: Document return values of timerqueue_add/del()

The return values of timerqueue_add/del() are not documented in the kernel doc comment. Add proper documentation. Signed-off-by: Anna-Maria Gleixner Cc: John Stultz Signed-off-by: Thomas Gleixner --- lib/timerqueue.c |

[patch V2 02/10] timerqueue: Document return values of timerqueue_add/del()

The return values of timerqueue_add/del() are not documented in the kernel doc comment. Add proper documentation. Signed-off-by: Anna-Maria Gleixner Cc: John Stultz Signed-off-by: Thomas Gleixner --- lib/timerqueue.c |8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) Index:

[patch V2 01/10] timer: Invoke timer_start_debug() where it makes sense

The timer start debug function is called before the proper timer base is set. As a consequence the trace data contains the stale CPU and flags values. Call the debug function after setting the new base and flags. Signed-off-by: Anna-Maria Gleixner Signed-off-by:

[patch V2 01/10] timer: Invoke timer_start_debug() where it makes sense

The timer start debug function is called before the proper timer base is set. As a consequence the trace data contains the stale CPU and flags values. Call the debug function after setting the new base and flags. Signed-off-by: Anna-Maria Gleixner Signed-off-by: Thomas Gleixner ---

[patch V2 00/10] timer: Move from a push remote at enqueue to a pull at expiry model

Placing timers at enqueue time on a target CPU based on dubious heuristics does not make any sense: 1) Most timer wheel timers are canceled or rearmed before they expire. 2) The heuristics to predict which CPU will be busy when the timer expires are wrong by definition. So we waste

[patch V2 00/10] timer: Move from a push remote at enqueue to a pull at expiry model

Placing timers at enqueue time on a target CPU based on dubious heuristics does not make any sense: 1) Most timer wheel timers are canceled or rearmed before they expire. 2) The heuristics to predict which CPU will be busy when the timer expires are wrong by definition. So we waste

Re: [PATCH 3/3] sound: ASoC: tegra: Select tegra30 i2s and ahub for tegra124 SoC

Le mardi 18 avril 2017 à 10:15 -0600, Stephen Warren a écrit : > On 04/18/2017 09:11 AM, Paul Kocialkowski wrote: > > This selects the tegra30 i2s and ahub controllers for the tegra124 SoC. > > These are needed when building without ARCH_TEGRA_3x_SOC set. > > diff --git a/sound/soc/tegra/Kconfig

Re: [PATCH 3/3] sound: ASoC: tegra: Select tegra30 i2s and ahub for tegra124 SoC

Le mardi 18 avril 2017 à 10:15 -0600, Stephen Warren a écrit : > On 04/18/2017 09:11 AM, Paul Kocialkowski wrote: > > This selects the tegra30 i2s and ahub controllers for the tegra124 SoC. > > These are needed when building without ARCH_TEGRA_3x_SOC set. > > diff --git a/sound/soc/tegra/Kconfig

Re: [PATCH 06/38] Annotate hardware config module parameters in drivers/clocksource/

On 04/15/2017 00:59, David Howells wrote: > When the kernel is running in secure boot mode [...] prevent > access by means of configuring driver modules I may easily be wrong, but doesn't secure boot require EFI? Do secure boot capable systems with old CS5535/36 even exist? Thanks, Jens

Re: [PATCH 06/38] Annotate hardware config module parameters in drivers/clocksource/

On 04/15/2017 00:59, David Howells wrote: > When the kernel is running in secure boot mode [...] prevent > access by means of configuring driver modules I may easily be wrong, but doesn't secure boot require EFI? Do secure boot capable systems with old CS5535/36 even exist? Thanks, Jens

Re: RFC: WMI Enhancements

On Tue, Apr 18, 2017 at 03:07:06PM +0200, Rafael Wysocki wrote: > On Monday, April 17, 2017 04:10:51 PM Darren Hart wrote: > > On Mon, Apr 17, 2017 at 03:03:29PM -0700, Andy Lutomirski wrote: > > > On Fri, Apr 14, 2017 at 4:05 PM, Darren Hart wrote: > > > > On Sat, Apr 15,

Re: RFC: WMI Enhancements

On Tue, Apr 18, 2017 at 03:07:06PM +0200, Rafael Wysocki wrote: > On Monday, April 17, 2017 04:10:51 PM Darren Hart wrote: > > On Mon, Apr 17, 2017 at 03:03:29PM -0700, Andy Lutomirski wrote: > > > On Fri, Apr 14, 2017 at 4:05 PM, Darren Hart wrote: > > > > On Sat, Apr 15, 2017 at 12:45:30AM

Re: [PATCH] regulator/core.c: remove the else statement

On Tue, 2017-04-18 at 16:49 +0100, Mark Brown wrote: > On Tue, Apr 18, 2017 at 11:39:34PM +0800, hubiaoyong wrote: > > in the function regulator_ena_gpio_free, the if branch contains > > the return statement, so remove the else statement. > > Why is it a benefit to make this change? In general,

Re: [RFC PATCH] x86, mce: change the mce notifier to 'blocking' from 'atomic'

On Thu, Apr 13, 2017 at 02:12:16PM +0200, Borislav Petkov wrote: > On Thu, Apr 13, 2017 at 01:31:59PM +0200, Borislav Petkov wrote: > > @@ -321,18 +321,8 @@ static void __print_mce(struct mce *m) > > > > static void print_mce(struct mce *m) > > { > > - int ret = 0; > > - > >

Re: [PATCH] regulator/core.c: remove the else statement

On Tue, 2017-04-18 at 16:49 +0100, Mark Brown wrote: > On Tue, Apr 18, 2017 at 11:39:34PM +0800, hubiaoyong wrote: > > in the function regulator_ena_gpio_free, the if branch contains > > the return statement, so remove the else statement. > > Why is it a benefit to make this change? In general,

Re: [RFC PATCH] x86, mce: change the mce notifier to 'blocking' from 'atomic'

On Thu, Apr 13, 2017 at 02:12:16PM +0200, Borislav Petkov wrote: > On Thu, Apr 13, 2017 at 01:31:59PM +0200, Borislav Petkov wrote: > > @@ -321,18 +321,8 @@ static void __print_mce(struct mce *m) > > > > static void print_mce(struct mce *m) > > { > > - int ret = 0; > > - > >

Re: [PATCH 3/3] sound: ASoC: tegra: Select tegra30 i2s and ahub for tegra124 SoC

On 04/18/2017 09:11 AM, Paul Kocialkowski wrote: This selects the tegra30 i2s and ahub controllers for the tegra124 SoC. These are needed when building without ARCH_TEGRA_3x_SOC set. diff --git a/sound/soc/tegra/Kconfig b/sound/soc/tegra/Kconfig index efbe8d4c019e..bcd18d2cf7a7 100644 ---

Re: [PATCH 3/3] sound: ASoC: tegra: Select tegra30 i2s and ahub for tegra124 SoC

On 04/18/2017 09:11 AM, Paul Kocialkowski wrote: This selects the tegra30 i2s and ahub controllers for the tegra124 SoC. These are needed when building without ARCH_TEGRA_3x_SOC set. diff --git a/sound/soc/tegra/Kconfig b/sound/soc/tegra/Kconfig index efbe8d4c019e..bcd18d2cf7a7 100644 ---

Re: RFC: drop the T10 OSD code and its users

On 04/12/2017 07:01 PM, Christoph Hellwig wrote: Hi Sir Christoph > The only real user of the T10 OSD protocol, the pNFS object layout > driver never went to the point of having shipping products, and the > other two users (osdblk and exofs) were simple example of it's usage. > I understand

Re: RFC: drop the T10 OSD code and its users

On 04/12/2017 07:01 PM, Christoph Hellwig wrote: Hi Sir Christoph > The only real user of the T10 OSD protocol, the pNFS object layout > driver never went to the point of having shipping products, and the > other two users (osdblk and exofs) were simple example of it's usage. > I understand

Re: [PATCH 06/38] Annotate hardware config module parameters in drivers/clocksource/

Hi, On 04/14/2017 20:25, Thomas Gleixner wrote: >> static int timer_irq; >> -module_param_named(irq, timer_irq, int, 0644); >> +module_param_hw_named(irq, timer_irq, int, irq, 0644); >> MODULE_PARM_DESC(irq, "Which IRQ to use for the clock source MFGPT ticks."); > > I'm not sure about this.

Re: [PATCH 06/38] Annotate hardware config module parameters in drivers/clocksource/

Hi, On 04/14/2017 20:25, Thomas Gleixner wrote: >> static int timer_irq; >> -module_param_named(irq, timer_irq, int, 0644); >> +module_param_hw_named(irq, timer_irq, int, irq, 0644); >> MODULE_PARM_DESC(irq, "Which IRQ to use for the clock source MFGPT ticks."); > > I'm not sure about this.

Re: [PATCH] ASoC: dwc: disallow building designware_pcm as a module

On Tue, 2017-04-18 at 16:18 +0100, Mark Brown wrote: > On Tue, Apr 18, 2017 at 12:59:54PM +0200, Lubomir Rintel wrote: > > It makes not sense: the whether the PIO PCM extension is used is > > hardcoded to the designware_i2s driver and designware_pcm doesn't > > have any module metadata, causing a

Re: [PATCH] ASoC: dwc: disallow building designware_pcm as a module

On Tue, 2017-04-18 at 16:18 +0100, Mark Brown wrote: > On Tue, Apr 18, 2017 at 12:59:54PM +0200, Lubomir Rintel wrote: > > It makes not sense: the whether the PIO PCM extension is used is > > hardcoded to the designware_i2s driver and designware_pcm doesn't > > have any module metadata, causing a

Re: [PATCH] of: fix "/cpus" reference leak in of_numa_parse_cpu_nodes()

On Tue, Apr 18, 2017 at 10:16 AM, David Daney wrote: > On 04/17/2017 05:29 PM, Tyrel Datwyler wrote: >> >> The call to of_find_node_by_path("/cpus") returns the cpus device_node >> with its reference count incremented. There is no matching of_node_put() >> call in

Re: [PATCH] of: fix "/cpus" reference leak in of_numa_parse_cpu_nodes()

On Tue, Apr 18, 2017 at 10:16 AM, David Daney wrote: > On 04/17/2017 05:29 PM, Tyrel Datwyler wrote: >> >> The call to of_find_node_by_path("/cpus") returns the cpus device_node >> with its reference count incremented. There is no matching of_node_put() >> call in of_numa_parse_cpu_nodes() which

RE: [PATCH] ACPICA: Export mutex functions

> -Original Message- > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Sent: Tuesday, April 18, 2017 7:15 AM > To: Guenter Roeck > Cc: Zheng, Lv ; Rafael J. Wysocki > ; Moore, Robert ; Wysocki, >

RE: [PATCH] ACPICA: Export mutex functions

> -Original Message- > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Sent: Tuesday, April 18, 2017 7:15 AM > To: Guenter Roeck > Cc: Zheng, Lv ; Rafael J. Wysocki > ; Moore, Robert ; Wysocki, > Rafael J ; Len Brown ; > linux-a...@vger.kernel.org; de...@acpica.org; linux- >

Re: [PATCH] platform: x86: intel-hid: Add missing ->thaw callback

On Tue, Apr 18, 2017 at 03:49:06PM +0200, Rafael Wysocki wrote: > From: Rafael J. Wysocki > > The intel-hid driver is missing a PM ->thaw callback allowing the > device to go back to the operational state after creating a > hibernation image or when there is an image

Re: [PATCH] platform: x86: intel-hid: Add missing ->thaw callback

On Tue, Apr 18, 2017 at 03:49:06PM +0200, Rafael Wysocki wrote: > From: Rafael J. Wysocki > > The intel-hid driver is missing a PM ->thaw callback allowing the > device to go back to the operational state after creating a > hibernation image or when there is an image restoration error during >

Re: net/ipv4: use-after-free in ip_queue_xmit

On Tue, Apr 18, 2017 at 5:15 AM, Andrey Konovalov wrote: > Yes, I don't have this field in the rtable struct. > > I'm on 39da7c509acff13fc8cb12ec1bb20337c988ed36 (4.11-rc6). > > I also don't see it in the cross reference: >

Re: net/ipv4: use-after-free in ip_queue_xmit

On Tue, Apr 18, 2017 at 5:15 AM, Andrey Konovalov wrote: > Yes, I don't have this field in the rtable struct. > > I'm on 39da7c509acff13fc8cb12ec1bb20337c988ed36 (4.11-rc6). > > I also don't see it in the cross reference: > http://lxr.free-electrons.com/source/include/net/route.h#L51 > It is

Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains

On 17/04/17 06:33, Viresh Kumar wrote: > On 13-04-17, 14:43, Sudeep Holla wrote: >> Interesting. My understand of power domain and in particular power >> domain performance was that it would control both. The abstract number >> you introduce would hide clocks and regulators. >> >> But if the

Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains

On 17/04/17 06:33, Viresh Kumar wrote: > On 13-04-17, 14:43, Sudeep Holla wrote: >> Interesting. My understand of power domain and in particular power >> domain performance was that it would control both. The abstract number >> you introduce would hide clocks and regulators. >> >> But if the

Re: [PATCH 0/4] assorted TTY code cleanups

On Wed, Apr 12, 2017 at 06:37:13PM -0400, Nicolas Pitre wrote: > Those are, I hope, fairly uncontrovertial patches that should require very > little review as they mostly do code movement providing nice cleanups. > No logical changes are introduced by those patches. > > My minitty patch series is

Re: [PATCH 0/4] assorted TTY code cleanups

On Wed, Apr 12, 2017 at 06:37:13PM -0400, Nicolas Pitre wrote: > Those are, I hope, fairly uncontrovertial patches that should require very > little review as they mostly do code movement providing nice cleanups. > No logical changes are introduced by those patches. > > My minitty patch series is

Re: [PATCH 5/6] platform/x86: fujitsu-laptop: do not log LED registration failures

On Tue, Apr 18, 2017 at 10:10:01AM +0200, Michał Kępień wrote: > Jonathan, I hope this response to Darren's message also addresses your > concerns. Feel free to let me know if it does not. > > > On Fri, Apr 07, 2017 at 03:07:12PM +0200, Michał Kępień wrote: > > > If

Re: [PATCH 5/6] platform/x86: fujitsu-laptop: do not log LED registration failures

On Tue, Apr 18, 2017 at 10:10:01AM +0200, Michał Kępień wrote: > Jonathan, I hope this response to Darren's message also addresses your > concerns. Feel free to let me know if it does not. > > > On Fri, Apr 07, 2017 at 03:07:12PM +0200, Michał Kępień wrote: > > > If

Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains

On 17/04/17 06:27, Viresh Kumar wrote: > On 13-04-17, 14:42, Sudeep Holla wrote: >> What I was referring is about power domain provider with multiple power >> domains(simply #power-domain-cells=<1> case as explained in the >> power-domain specification. > > I am not sure if we should be looking

Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains

On 17/04/17 06:27, Viresh Kumar wrote: > On 13-04-17, 14:42, Sudeep Holla wrote: >> What I was referring is about power domain provider with multiple power >> domains(simply #power-domain-cells=<1> case as explained in the >> power-domain specification. > > I am not sure if we should be looking

Re: [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function

On 18/04/17 09:50 AM, Konrad Rzeszutek Wilk wrote: > I am not sure if you know, but you can add on each patch the respective > maintainer via 'CC'. That way you can have certain maintainers CCed only > on the subsystems they cover. You put it after (or before) your SoB and > git send-email

Re: [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function

On 18/04/17 09:50 AM, Konrad Rzeszutek Wilk wrote: > I am not sure if you know, but you can add on each patch the respective > maintainer via 'CC'. That way you can have certain maintainers CCed only > on the subsystems they cover. You put it after (or before) your SoB and > git send-email

Re: [PATCH v24 08/11] acpi: Introduce acpi_unregister_irq function

On Sat, Apr 15, 2017 at 02:40:11AM +0800, fu@linaro.org wrote: > From: Fu Wei > > This patch introduces acpi_unregister_irq function to free a > linux IRQ number<->GSI mapping by a given linux IRQ number. > > Even we have successfully registered the GSI, when some error

Re: [PATCH v24 08/11] acpi: Introduce acpi_unregister_irq function

On Sat, Apr 15, 2017 at 02:40:11AM +0800, fu@linaro.org wrote: > From: Fu Wei > > This patch introduces acpi_unregister_irq function to free a > linux IRQ number<->GSI mapping by a given linux IRQ number. > > Even we have successfully registered the GSI, when some error occurs, we > may

Re: [PATCH] Remove ARM errata Workarounds 458693 and 460075

On Sun, Apr 16, 2017 at 09:04:46AM +0100, Russell King - ARM Linux wrote: > On Sat, Apr 15, 2017 at 07:06:06PM -0500, Nisal Menuka wrote: > > According to ARM, these errata exist only in a version of Cortex-A8 > > (r2p0) which was never built. Therefore, I believe there are no platforms > > where

Re: [PATCH] Remove ARM errata Workarounds 458693 and 460075

On Sun, Apr 16, 2017 at 09:04:46AM +0100, Russell King - ARM Linux wrote: > On Sat, Apr 15, 2017 at 07:06:06PM -0500, Nisal Menuka wrote: > > According to ARM, these errata exist only in a version of Cortex-A8 > > (r2p0) which was never built. Therefore, I believe there are no platforms > > where

Re: 答复: Using ion memory for direct-io

On 04/17/2017 07:05 PM, Zengtao (B) wrote: > Hi Laura: > >> -邮件原件- >> 发件人: Laura Abbott [mailto:labb...@redhat.com] >> 发送时间: 2017年4月18日 0:14 >> 收件人: Zengtao (B) ; sumit.sem...@linaro.org >> 抄送: gre...@linuxfoundation.org; a...@android.com; >>

Re: 答复: Using ion memory for direct-io

On 04/17/2017 07:05 PM, Zengtao (B) wrote: > Hi Laura: > >> -邮件原件- >> 发件人: Laura Abbott [mailto:labb...@redhat.com] >> 发送时间: 2017年4月18日 0:14 >> 收件人: Zengtao (B) ; sumit.sem...@linaro.org >> 抄送: gre...@linuxfoundation.org; a...@android.com; >> riandr...@android.com;

Re: [PATCH v4 1/1] pwm: pca9685: fix gpio-only operation.

Thanks for the feedback Andy !! > I would go with > > /* Wait for @sleep microseconds for the oscillator to be back up */ > if (sleep) > udelay(sleep); > > Otherwise int sleep is oddly here. > > Or > > bool sleep > > /* Wait 500us ... */ > if (sleep) > udelay(500); > >> +} I think you may be

Re: [PATCH v4 1/1] pwm: pca9685: fix gpio-only operation.

Thanks for the feedback Andy !! > I would go with > > /* Wait for @sleep microseconds for the oscillator to be back up */ > if (sleep) > udelay(sleep); > > Otherwise int sleep is oddly here. > > Or > > bool sleep > > /* Wait 500us ... */ > if (sleep) > udelay(500); > >> +} I think you may be

Re: [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function

On Tue, Apr 18, 2017 at 09:42:20AM -0600, Logan Gunthorpe wrote: > > > On 18/04/17 08:27 AM, Konrad Rzeszutek Wilk wrote: > > Interesting that you didn't CC any of the maintainers. Could you > > do that in the future please? > > Please read the cover letter. The distribution list for the

Re: [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function

On Tue, Apr 18, 2017 at 09:42:20AM -0600, Logan Gunthorpe wrote: > > > On 18/04/17 08:27 AM, Konrad Rzeszutek Wilk wrote: > > Interesting that you didn't CC any of the maintainers. Could you > > do that in the future please? > > Please read the cover letter. The distribution list for the

Re: [Patch v3 1/2] lustre: Parantheses added for Macro argument to avoid precedence issues

On Sat, Apr 15, 2017 at 01:50:42PM +, Rishiraj Manwatkar wrote: > Parantheses are added for Macro argument, to avoid precedence issues. > > Signed-off-by: Rishiraj Manwatkar > --- > v1 -> v2: Added mailing list in cc. > v2 -> v3: Changed From: to be same as

Re: [Patch v3 1/2] lustre: Parantheses added for Macro argument to avoid precedence issues

On Sat, Apr 15, 2017 at 01:50:42PM +, Rishiraj Manwatkar wrote: > Parantheses are added for Macro argument, to avoid precedence issues. > > Signed-off-by: Rishiraj Manwatkar > --- > v1 -> v2: Added mailing list in cc. > v2 -> v3: Changed From: to be same as Signed-off-by:. >

Re: [PATCH] regulator/core.c: remove the else statement

On Tue, Apr 18, 2017 at 11:39:34PM +0800, hubiaoyong wrote: > in the function regulator_ena_gpio_free, the if branch contains > the return statement, so remove the else statement. Why is it a benefit to make this change? signature.asc Description: PGP signature

Re: [PATCH] regulator/core.c: remove the else statement

On Tue, Apr 18, 2017 at 11:39:34PM +0800, hubiaoyong wrote: > in the function regulator_ena_gpio_free, the if branch contains > the return statement, so remove the else statement. Why is it a benefit to make this change? signature.asc Description: PGP signature

Re: [kernel-hardening] Re: [PATCH 1/4] added SECURITY_TIOCSTI_RESTRICT kernel config

On Tue, Apr 18, 2017 at 6:40 AM, Alan Cox wrote: >> Since tty sessions are usually separated by different users, how would >> they have the same one and yet need something like this? >> >> Also, why not put this in the tty config section? > > The normal attack use case

Re: [kernel-hardening] Re: [PATCH 1/4] added SECURITY_TIOCSTI_RESTRICT kernel config

On Tue, Apr 18, 2017 at 6:40 AM, Alan Cox wrote: >> Since tty sessions are usually separated by different users, how would >> they have the same one and yet need something like this? >> >> Also, why not put this in the tty config section? > > The normal attack use case people argue about is a

Re: net/ipv6: slab-out-of-bounds read in seg6_validate_srh

On Tue, Apr 18, 2017 at 5:16 PM, David Lebrun wrote: > On 04/18/2017 04:54 PM, Andrey Konovalov wrote: >> Hi, >> >> I've got the following error report while fuzzing the kernel with syzkaller. >> >> On commit 4f7d029b9bf009fbee76bb10c0c4351a1870d2f3 (4.11-rc7). >> >> A

Re: net/ipv6: slab-out-of-bounds read in seg6_validate_srh

On Tue, Apr 18, 2017 at 5:16 PM, David Lebrun wrote: > On 04/18/2017 04:54 PM, Andrey Konovalov wrote: >> Hi, >> >> I've got the following error report while fuzzing the kernel with syzkaller. >> >> On commit 4f7d029b9bf009fbee76bb10c0c4351a1870d2f3 (4.11-rc7). >> >> A reproducer and .config are

Re: [PATCH 05/22] drm/i915: Make use of the new sg_map helper function

On 18/04/17 12:44 AM, Daniel Vetter wrote: > On Thu, Apr 13, 2017 at 04:05:18PM -0600, Logan Gunthorpe wrote: >> This is a single straightforward conversion from kmap to sg_map. >> >> Signed-off-by: Logan Gunthorpe > > Acked-by: Daniel Vetter > >

Re: [PATCH 05/22] drm/i915: Make use of the new sg_map helper function

On 18/04/17 12:44 AM, Daniel Vetter wrote: > On Thu, Apr 13, 2017 at 04:05:18PM -0600, Logan Gunthorpe wrote: >> This is a single straightforward conversion from kmap to sg_map. >> >> Signed-off-by: Logan Gunthorpe > > Acked-by: Daniel Vetter > > Probably makes sense to merge through some

Re: [PATCH 0/4] staging: add ccree crypto driver

On Tue, Apr 18, 2017 at 06:29:22PM +0300, Gilad Ben-Yossef wrote: > On Tue, Apr 18, 2017 at 6:13 PM, Mark Rutland wrote: > > On Tue, Apr 18, 2017 at 05:07:50PM +0300, Gilad Ben-Yossef wrote: > >> Arm TrustZone CryptoCell 700 is a family of cryptographic hardware > >>

Re: [PATCH 0/4] staging: add ccree crypto driver

On Tue, Apr 18, 2017 at 06:29:22PM +0300, Gilad Ben-Yossef wrote: > On Tue, Apr 18, 2017 at 6:13 PM, Mark Rutland wrote: > > On Tue, Apr 18, 2017 at 05:07:50PM +0300, Gilad Ben-Yossef wrote: > >> Arm TrustZone CryptoCell 700 is a family of cryptographic hardware > >> accelerators. It is supported

Re: [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function

On 18/04/17 08:27 AM, Konrad Rzeszutek Wilk wrote: > Interesting that you didn't CC any of the maintainers. Could you > do that in the future please? Please read the cover letter. The distribution list for the patchset would have been way too large to cc every maintainer (even as limited as it

Re: [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function

On 18/04/17 08:27 AM, Konrad Rzeszutek Wilk wrote: > Interesting that you didn't CC any of the maintainers. Could you > do that in the future please? Please read the cover letter. The distribution list for the patchset would have been way too large to cc every maintainer (even as limited as it

[PATCH] regulator/core.c: remove the else statement

in the function regulator_ena_gpio_free, the if branch contains the return statement, so remove the else statement. Signed-off-by: hubiaoyong --- drivers/regulator/core.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/regulator/core.c

[PATCH] regulator/core.c: remove the else statement

in the function regulator_ena_gpio_free, the if branch contains the return statement, so remove the else statement. Signed-off-by: hubiaoyong --- drivers/regulator/core.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/regulator/core.c

Re: [PATCH 0/4] staging: add ccree crypto driver

On Tue, Apr 18, 2017 at 05:07:50PM +0300, Gilad Ben-Yossef wrote: > Arm TrustZone CryptoCell 700 is a family of cryptographic hardware > accelerators. It is supported by a long lived series of out of tree > drivers, which I am now in the process of unifying and upstreaming. > This is the first

Re: [PATCH 0/4] staging: add ccree crypto driver

On Tue, Apr 18, 2017 at 05:07:50PM +0300, Gilad Ben-Yossef wrote: > Arm TrustZone CryptoCell 700 is a family of cryptographic hardware > accelerators. It is supported by a long lived series of out of tree > drivers, which I am now in the process of unifying and upstreaming. > This is the first

Re: [PATCH v2] crypto: arm64/sha: Add constant operand modifier to ASM_EXPORT

On 18 April 2017 at 15:47, Paul Gortmaker wrote: > On Wed, Apr 5, 2017 at 2:34 PM, Matthias Kaehlcke wrote: >> The operand is an integer constant, make the constness explicit by >> adding the modifier. This is needed for clang to generate valid

Re: [PATCH v2] crypto: arm64/sha: Add constant operand modifier to ASM_EXPORT

On 18 April 2017 at 15:47, Paul Gortmaker wrote: > On Wed, Apr 5, 2017 at 2:34 PM, Matthias Kaehlcke wrote: >> The operand is an integer constant, make the constness explicit by >> adding the modifier. This is needed for clang to generate valid code >> and also works with gcc. > > Actually it

Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down

Ben Hutchings wrote: > > Shouldn't this now appear under /sys/kernel/tracing/ ? > > True, but old tracing scripts didn't go away. Conversion to a symlink would fix that. David

Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down

Ben Hutchings wrote: > > Shouldn't this now appear under /sys/kernel/tracing/ ? > > True, but old tracing scripts didn't go away. Conversion to a symlink would fix that. David

Re: [PATCH] kbuild: avoid conflict between -ffunction-sections and -pg on gcc-4.7

Hi Arnd, 2017-04-14 15:17 GMT+09:00 Masahiro Yamada : > Arnd Bergmann reported: > "When ftrace is enabled and we build with gcc-4.7 or older, we > get a warning for each file on architectures that select > CONFIG_LD_DEAD_CODE_DATA_ELIMINATION: > > warning:

Re: [PATCH] kbuild: avoid conflict between -ffunction-sections and -pg on gcc-4.7

Hi Arnd, 2017-04-14 15:17 GMT+09:00 Masahiro Yamada : > Arnd Bergmann reported: > "When ftrace is enabled and we build with gcc-4.7 or older, we > get a warning for each file on architectures that select > CONFIG_LD_DEAD_CODE_DATA_ELIMINATION: > > warning: -ffunction-sections disabled;

Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down

Ben Hutchings wrote: > So it's generally not going to be OK to turn off debugfs. There will > probably need to be a distinction between believed-safe and unsafe > directories/files. Any suggestion on how to mark this distinction? I'd prefer not to modify every read/write

Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down

Ben Hutchings wrote: > So it's generally not going to be OK to turn off debugfs. There will > probably need to be a distinction between believed-safe and unsafe > directories/files. Any suggestion on how to mark this distinction? I'd prefer not to modify every read/write op associated with a

Re: [PATCH 0/4] staging: add ccree crypto driver

Hi Mark, On Tue, Apr 18, 2017 at 6:13 PM, Mark Rutland wrote: > Hi, > > On Tue, Apr 18, 2017 at 05:07:50PM +0300, Gilad Ben-Yossef wrote: >> Arm TrustZone CryptoCell 700 is a family of cryptographic hardware >> accelerators. It is supported by a long lived series of out of

Re: [PATCH 0/4] staging: add ccree crypto driver

Hi Mark, On Tue, Apr 18, 2017 at 6:13 PM, Mark Rutland wrote: > Hi, > > On Tue, Apr 18, 2017 at 05:07:50PM +0300, Gilad Ben-Yossef wrote: >> Arm TrustZone CryptoCell 700 is a family of cryptographic hardware >> accelerators. It is supported by a long lived series of out of tree >> drivers, which

Re: [PATCH] fpga: allow to compile-test Altera FPGA bridge drivers

On Wed, 12 Apr 2017, kbuild test robot wrote: Hi Tobias, Hi Tobias, This is very interesting issue brought up by your patch that turns on COMPILE_TEST in drivers/fpga/Kconfig. See my comment below. Matthew Gerlach [auto build test WARNING on linus/master] [also build test WARNING on

Re: [PATCH] fpga: allow to compile-test Altera FPGA bridge drivers

On Wed, 12 Apr 2017, kbuild test robot wrote: Hi Tobias, Hi Tobias, This is very interesting issue brought up by your patch that turns on COMPILE_TEST in drivers/fpga/Kconfig. See my comment below. Matthew Gerlach [auto build test WARNING on linus/master] [also build test WARNING on

Re: [PATCH 1/3] mtd: sharpsl: add sharpslpart MTD partition parser

2017-04-17 17:44 GMT+03:00 Boris Brezillon : > Marek, Andrea, > > Before we even start discussing minor improvements (like coding style), > I'd like to discuss the sharp FTL and partition table format, and > decide whether we want to have such an old FTL

Re: [PATCH 1/3] mtd: sharpsl: add sharpslpart MTD partition parser

2017-04-17 17:44 GMT+03:00 Boris Brezillon : > Marek, Andrea, > > Before we even start discussing minor improvements (like coding style), > I'd like to discuss the sharp FTL and partition table format, and > decide whether we want to have such an old FTL included in the kernel. > > Actually,

Re: [PATCH 0/4] Properly invalidate data in the cleancache.

On Fri, Apr 14, 2017 at 05:07:49PM +0300, Andrey Ryabinin wrote: > We've noticed that after direct IO write, buffered read sometimes gets > stale data which is coming from the cleancache. That is not good. > The reason for this is that some direct write hooks call call >

Re: [PATCH 0/4] Properly invalidate data in the cleancache.

On Fri, Apr 14, 2017 at 05:07:49PM +0300, Andrey Ryabinin wrote: > We've noticed that after direct IO write, buffered read sometimes gets > stale data which is coming from the cleancache. That is not good. > The reason for this is that some direct write hooks call call >

Re: [PATCH v6 5/8] coresight: use const for device_node structures

On Thu, Apr 06, 2017 at 09:30:58PM +0800, Leo Yan wrote: > Almost low level functions from open firmware have used const to > qualify device_node structures, so add const for device_node > parameters in of_coresight related functions. > > Reviewed-by: Stephen Boyd >

Re: [PATCH v6 5/8] coresight: use const for device_node structures

On Thu, Apr 06, 2017 at 09:30:58PM +0800, Leo Yan wrote: > Almost low level functions from open firmware have used const to > qualify device_node structures, so add const for device_node > parameters in of_coresight related functions. > > Reviewed-by: Stephen Boyd > Signed-off-by: Leo Yan I

Re: net/ipv6: slab-out-of-bounds read in seg6_validate_srh

On 04/18/2017 04:54 PM, Andrey Konovalov wrote: > Hi, > > I've got the following error report while fuzzing the kernel with syzkaller. > > On commit 4f7d029b9bf009fbee76bb10c0c4351a1870d2f3 (4.11-rc7). > > A reproducer and .config are attached. > >

Re: net/ipv6: slab-out-of-bounds read in seg6_validate_srh

On 04/18/2017 04:54 PM, Andrey Konovalov wrote: > Hi, > > I've got the following error report while fuzzing the kernel with syzkaller. > > On commit 4f7d029b9bf009fbee76bb10c0c4351a1870d2f3 (4.11-rc7). > > A reproducer and .config are attached. > >

Re: [RFC PATCH 9/9] debugfs: free debugfs_fsdata instances

On Tue, 2017-04-18 at 08:17 -0700, Paul E. McKenney wrote: > > Again, no (S)RCU abuse here, just an ABBA deadlock. > > OK, please accept my apologies for failing to follow the thread. No worries - just wanted to clarify this in case I was missing something. > I nevertheless reiterate my advice

Re: [RFC PATCH 9/9] debugfs: free debugfs_fsdata instances

On Tue, 2017-04-18 at 08:17 -0700, Paul E. McKenney wrote: > > Again, no (S)RCU abuse here, just an ABBA deadlock. > > OK, please accept my apologies for failing to follow the thread. No worries - just wanted to clarify this in case I was missing something. > I nevertheless reiterate my advice

<    5   6   7   8   9   10   11   12   13   14   >