Re: [RFC PATCH 2/3] Add generation of Module.ksymb file in streamline_config.pl

On Mon, 8 Aug 2016, Luis R. Rodriguez wrote: > On Sun, Jul 31, 2016 at 05:33:51PM +0200, Cristina Moraru wrote: > > Add generation of ./scripts/mod/Module.ksymb file containing > > associations of driver file names and corresponding CONFIG_* > > symbol. > > > > This file will be used by modpost

Re: [RFC PATCH 2/3] Add generation of Module.ksymb file in streamline_config.pl

On Mon, 8 Aug 2016, Luis R. Rodriguez wrote: > On Sun, Jul 31, 2016 at 05:33:51PM +0200, Cristina Moraru wrote: > > Add generation of ./scripts/mod/Module.ksymb file containing > > associations of driver file names and corresponding CONFIG_* > > symbol. > > > > This file will be used by modpost

[PATCH v4 02/10] usb: gadget: change len to size_t on alloc_ep_req()

Length of buffers should be of type size_t whenever possible. Altough recommended, this change has no real practical change, unless a driver has a uses a huge or negative buffer size - it might help find these bugs. Signed-off-by: Felipe F. Tonello ---

[PATCH v4 02/10] usb: gadget: change len to size_t on alloc_ep_req()

Length of buffers should be of type size_t whenever possible. Altough recommended, this change has no real practical change, unless a driver has a uses a huge or negative buffer size - it might help find these bugs. Signed-off-by: Felipe F. Tonello --- drivers/usb/gadget/u_f.c | 2 +-

Re: [PATCH] clk: rockchip: add clock flag parameter when register pll

Am Freitag, 22. Juli 2016, 14:37:45 schrieb Lin Huang: > From: Heiko Stübner > > add clock flag parameter so we can pass specific clock flag > (like CLK_GET_RATE_NOCACHE etc..)to pll driver. > > Change-Id: I1e076b3efa6b5da082b6e68e2e2a4c9dfd93e3d4 > Signed-off-by: Heiko Stübner

[PATCH v4 08/10] usb: gadget: remove useless parameter in alloc_ep_req()

The default_length parameter of alloc_ep_req was not really necessary and gadget drivers would almost always create an inline function to pass the same value to len and default_len. So this patch also removes duplicate code from few drivers. Signed-off-by: Felipe F. Tonello

Re: [PATCH] clk: rockchip: add clock flag parameter when register pll

Am Freitag, 22. Juli 2016, 14:37:45 schrieb Lin Huang: > From: Heiko Stübner > > add clock flag parameter so we can pass specific clock flag > (like CLK_GET_RATE_NOCACHE etc..)to pll driver. > > Change-Id: I1e076b3efa6b5da082b6e68e2e2a4c9dfd93e3d4 > Signed-off-by: Heiko Stübner >

[PATCH v4 08/10] usb: gadget: remove useless parameter in alloc_ep_req()

The default_length parameter of alloc_ep_req was not really necessary and gadget drivers would almost always create an inline function to pass the same value to len and default_len. So this patch also removes duplicate code from few drivers. Signed-off-by: Felipe F. Tonello ---

[PATCH v4 09/10] usb: gadget: f_hid: use free_ep_req()

We should always use free_ep_req() when allocating requests with alloc_ep_req(). Signed-off-by: Felipe F. Tonello --- drivers/usb/gadget/function/f_hid.c | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/drivers/usb/gadget/function/f_hid.c

[PATCH v4 09/10] usb: gadget: f_hid: use free_ep_req()

We should always use free_ep_req() when allocating requests with alloc_ep_req(). Signed-off-by: Felipe F. Tonello --- drivers/usb/gadget/function/f_hid.c | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/drivers/usb/gadget/function/f_hid.c

[PATCH v4 06/10] usb: gadget: f_midi: refactor state machine

This refactor results in a cleaner state machine code and promotes consistency, readability, and maintanability of this driver. This refactor state machine was well tested and it is currently running in production code and devices. Signed-off-by: Felipe F. Tonello ---

[PATCH v4 06/10] usb: gadget: f_midi: refactor state machine

This refactor results in a cleaner state machine code and promotes consistency, readability, and maintanability of this driver. This refactor state machine was well tested and it is currently running in production code and devices. Signed-off-by: Felipe F. Tonello ---

[PATCH v4 03/10] usb: gadget: align buffer size when allocating for OUT endpoint

Using usb_ep_align() makes sure that the buffer size for OUT endpoints is always aligned with wMaxPacketSize (512 usually). This makes sure that no buffer has the wrong size, which can cause nasty bugs. Signed-off-by: Felipe F. Tonello --- drivers/usb/gadget/u_f.c | 3

[PATCH v4 03/10] usb: gadget: align buffer size when allocating for OUT endpoint

Using usb_ep_align() makes sure that the buffer size for OUT endpoints is always aligned with wMaxPacketSize (512 usually). This makes sure that no buffer has the wrong size, which can cause nasty bugs. Signed-off-by: Felipe F. Tonello --- drivers/usb/gadget/u_f.c | 3 +++

[PATCH v4 07/10] usb: gadget: f_midi: drop substreams when disabling endpoint

This change makes sure that the ALSA buffers are cleaned if an endpoint becomes disabled. Before this change, if the internal ALSA buffer did overflow, the MIDI function would stop sending MIDI to the host. Signed-off-by: Felipe F. Tonello ---

[PATCH v4 07/10] usb: gadget: f_midi: drop substreams when disabling endpoint

This change makes sure that the ALSA buffers are cleaned if an endpoint becomes disabled. Before this change, if the internal ALSA buffer did overflow, the MIDI function would stop sending MIDI to the host. Signed-off-by: Felipe F. Tonello --- drivers/usb/gadget/function/f_midi.c | 27

[PATCH v4 10/10] usb: gadget: f_hid: use alloc_ep_req()

Use gadget's framework allocation function instead of directly calling usb_ep_alloc_request(). Signed-off-by: Felipe F. Tonello --- drivers/usb/gadget/function/f_hid.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git

[PATCH v4 10/10] usb: gadget: f_hid: use alloc_ep_req()

Use gadget's framework allocation function instead of directly calling usb_ep_alloc_request(). Signed-off-by: Felipe F. Tonello --- drivers/usb/gadget/function/f_hid.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/usb/gadget/function/f_hid.c

[PATCH] get_next_timer_interrupt: preserve KTIME_MAX expiration

The tick_nohz_stop_sched_tick() routine is not properly canceling the sched timer when nothing is pending, because get_next_timer_interrupt() is no longer returning KTIME_MAX in that case. This causes periodic interrupts when none are needed. When determining the next interrupt time, we first

[PATCH] get_next_timer_interrupt: preserve KTIME_MAX expiration

The tick_nohz_stop_sched_tick() routine is not properly canceling the sched timer when nothing is pending, because get_next_timer_interrupt() is no longer returning KTIME_MAX in that case. This causes periodic interrupts when none are needed. When determining the next interrupt time, we first

Re: [PATCH] tpm: fix build error

As the fix is quite trivial I already pushed this fixup on tip of my master branch in order to make testing easy. /Jarkko On Mon, Aug 08, 2016 at 11:25:26PM +0300, Jarkko Sakkinen wrote: > tpm_getcap and tpm2_get_tpm_pt were not properly exported. This commit > adds the exports. The build error

Re: [PATCH] tpm: fix build error

As the fix is quite trivial I already pushed this fixup on tip of my master branch in order to make testing easy. /Jarkko On Mon, Aug 08, 2016 at 11:25:26PM +0300, Jarkko Sakkinen wrote: > tpm_getcap and tpm2_get_tpm_pt were not properly exported. This commit > adds the exports. The build error

[PATCH] tpm: fix build error

tpm_getcap and tpm2_get_tpm_pt were not properly exported. This commit adds the exports. The build error exist only in the master (bleeding edge) branch so this problem does not concern 4.8 release. The commit will be folded to 4d970e733b09 as soon as it is tested and reviewed. Fixes:

[PATCH] tpm: fix build error

tpm_getcap and tpm2_get_tpm_pt were not properly exported. This commit adds the exports. The build error exist only in the master (bleeding edge) branch so this problem does not concern 4.8 release. The commit will be folded to 4d970e733b09 as soon as it is tested and reviewed. Fixes:

Re: [PATCH V5 1/3] x86/ioapic: Support hot-removal of IOAPICs present during boot

On Sun, Jun 26, 2016 at 11:44:57AM +0800, Rui Wang wrote: > v5: Remove #ifdef CONFIG_X86 from setup-bus.c, making it neutral to archs. > v4: Add comments explaining when to call acpi_ioapic_add(). > v3: Previous versions break mips. This version fixes it. > > IOAPICs present during system boot

perf: WARNING: kernel/events/core.c:4893 perf_mmap_close

Hello running the perf_fuzzer on Haswell, this is a new warning I don't think I've seen before. It works out to be this code here: /* this has to be the last one */ rb_free_aux(rb); WARN_ON_ONCE(atomic_read(>aux_refcount));

Re: [PATCH V5 1/3] x86/ioapic: Support hot-removal of IOAPICs present during boot

On Sun, Jun 26, 2016 at 11:44:57AM +0800, Rui Wang wrote: > v5: Remove #ifdef CONFIG_X86 from setup-bus.c, making it neutral to archs. > v4: Add comments explaining when to call acpi_ioapic_add(). > v3: Previous versions break mips. This version fixes it. > > IOAPICs present during system boot

perf: WARNING: kernel/events/core.c:4893 perf_mmap_close

Hello running the perf_fuzzer on Haswell, this is a new warning I don't think I've seen before. It works out to be this code here: /* this has to be the last one */ rb_free_aux(rb); WARN_ON_ONCE(atomic_read(>aux_refcount));

[PATCH] mm: memcontrol: only mark charged pages with PageKmemcg

To distinguish non-slab pages charged to kmemcg we mark them PageKmemcg, which sets page->_mapcount to -512. Currently, we set/clear PageKmemcg in __alloc_pages_nodemask()/free_pages_prepare() for any page allocated with __GFP_ACCOUNT, including those that aren't actually charged to any cgroup,

[PATCH] mm: memcontrol: only mark charged pages with PageKmemcg

To distinguish non-slab pages charged to kmemcg we mark them PageKmemcg, which sets page->_mapcount to -512. Currently, we set/clear PageKmemcg in __alloc_pages_nodemask()/free_pages_prepare() for any page allocated with __GFP_ACCOUNT, including those that aren't actually charged to any cgroup,

Re: linux-4.8-rc1/drivers/scsi/sd.c:317: pointless test ?

- Original Message - > From: "David Binderman" > To: j...@linux.vnet.ibm.com, "martin petersen" , > linux-s...@vger.kernel.org, "Linux > Kernel Mailing List" , dcb...@hotmail.com > Sent: Monday,

Re: linux-4.8-rc1/drivers/scsi/sd.c:317: pointless test ?

- Original Message - > From: "David Binderman" > To: j...@linux.vnet.ibm.com, "martin petersen" , > linux-s...@vger.kernel.org, "Linux > Kernel Mailing List" , dcb...@hotmail.com > Sent: Monday, August 8, 2016 9:46:53 AM > Subject: linux-4.8-rc1/drivers/scsi/sd.c:317: pointless test ?

Re: [PATCH v3 00/14] pxa_camera transition to v4l2 standalone device

On 08/08/2016 09:30 PM, Robert Jarzmik wrote: > Hi Hans, > > We're leaving the domain of the RFC to a proper submission. > > This is very alike to what you reviewed earlier, the code is very close, and : > - the split between patches is done to better isolate cleanups from real code > -

Re: [PATCH v3 00/14] pxa_camera transition to v4l2 standalone device

On 08/08/2016 09:30 PM, Robert Jarzmik wrote: > Hi Hans, > > We're leaving the domain of the RFC to a proper submission. > > This is very alike to what you reviewed earlier, the code is very close, and : > - the split between patches is done to better isolate cleanups from real code > -

Re: [rcu:rcu/next 25/36] include/linux/irqflags.h:79:3: error: implicit declaration of function 'arch_irqs_disabled_flags'

Paul, Am 15.06.2016 um 14:45 schrieb Paul E. McKenney: > On Wed, Jun 15, 2016 at 09:05:37AM +0200, Richard Weinberger wrote: >> Paul, >> >> Am 15.06.2016 um 00:54 schrieb Paul E. McKenney: >>> On Mon, Jun 06, 2016 at 02:04:03AM +0800, kbuild test robot wrote: tree:

Re: perf: hard fuzzer crash on 4.8-rc1

On Mon, Aug 08, 2016 at 03:57:05PM -0400, Vince Weaver wrote: > On Mon, 8 Aug 2016, Peter Zijlstra wrote: > > > On Mon, Aug 08, 2016 at 01:57:28PM -0400, Vince Weaver wrote: > > > > > > [ 637.250130] BUG: unable to handle kernel > > > > > > About 10 times of triggering this, this is all I get.

Re: [rcu:rcu/next 25/36] include/linux/irqflags.h:79:3: error: implicit declaration of function 'arch_irqs_disabled_flags'

Paul, Am 15.06.2016 um 14:45 schrieb Paul E. McKenney: > On Wed, Jun 15, 2016 at 09:05:37AM +0200, Richard Weinberger wrote: >> Paul, >> >> Am 15.06.2016 um 00:54 schrieb Paul E. McKenney: >>> On Mon, Jun 06, 2016 at 02:04:03AM +0800, kbuild test robot wrote: tree:

Re: perf: hard fuzzer crash on 4.8-rc1

On Mon, Aug 08, 2016 at 03:57:05PM -0400, Vince Weaver wrote: > On Mon, 8 Aug 2016, Peter Zijlstra wrote: > > > On Mon, Aug 08, 2016 at 01:57:28PM -0400, Vince Weaver wrote: > > > > > > [ 637.250130] BUG: unable to handle kernel > > > > > > About 10 times of triggering this, this is all I get.

Re: Build regressions/improvements in v4.8-rc1

On Mon, Aug 8, 2016 at 7:02 PM, Andreas Schwab wrote: > On Mo, Aug 08 2016, Rich Felker wrote: > >> Users should leave builtin-DTB off, but allyesconfig turns it on. > > Perhaps you could inverse the meaning of the config so that y means > builtin-DTB off?

Re: Build regressions/improvements in v4.8-rc1

On Mon, Aug 8, 2016 at 7:02 PM, Andreas Schwab wrote: > On Mo, Aug 08 2016, Rich Felker wrote: > >> Users should leave builtin-DTB off, but allyesconfig turns it on. > > Perhaps you could inverse the meaning of the config so that y means > builtin-DTB off? That's one option, The other one is

Re: [PATCH] x86/paravirt: Do not trace _paravirt_ident_*() functions

Hmm, I'm guessing this patch got lost. -- Steve On Wed, 25 May 2016 13:47:26 -0400 Steven Rostedt wrote: > Łukasz Daniluk reported that on a RHEL kernel that his machine would lock up > after enabling function tracer. I asked him to bisect the functions within >

Re: [PATCH] x86/paravirt: Do not trace _paravirt_ident_*() functions

Hmm, I'm guessing this patch got lost. -- Steve On Wed, 25 May 2016 13:47:26 -0400 Steven Rostedt wrote: > Łukasz Daniluk reported that on a RHEL kernel that his machine would lock up > after enabling function tracer. I asked him to bisect the functions within > available_filter_functions,

Re: [RFD] I/O scheduling in blk-mq

On Mon, Aug 08, 2016 at 04:09:56PM +0200, Paolo wrote: > Hi Jens, Tejun, Christoph, all, > AFAIK blk-mq does not yet feature I/O schedulers. In particular, there > is no scheduler providing strong guarantees in terms of > responsiveness, latency for time-sensitive applications and bandwidth >

Re: [RFD] I/O scheduling in blk-mq

On Mon, Aug 08, 2016 at 04:09:56PM +0200, Paolo wrote: > Hi Jens, Tejun, Christoph, all, > AFAIK blk-mq does not yet feature I/O schedulers. In particular, there > is no scheduler providing strong guarantees in terms of > responsiveness, latency for time-sensitive applications and bandwidth >

Re: NULL ptr deref in perf/filter_match

On Thu, 4 Aug 2016, Vegard Nossum wrote: > BTW, this seems to show up slightly more frequently although I've seen > it a couple of times before without your patch too so it's probably > unrelated: > > WARNING: CPU: 0 PID: 1244 at arch/x86/kernel/hw_breakpoint.c:121 >

Re: NULL ptr deref in perf/filter_match

On Thu, 4 Aug 2016, Vegard Nossum wrote: > BTW, this seems to show up slightly more frequently although I've seen > it a couple of times before without your patch too so it's probably > unrelated: > > WARNING: CPU: 0 PID: 1244 at arch/x86/kernel/hw_breakpoint.c:121 >

Re: [RFC PATCH 3/3] Add dynamic pegging of Kconfig symbol

On Sun, Jul 31, 2016 at 05:33:52PM +0200, Cristina Moraru wrote: > Update modpost to add dynamic pegging of CONFIG_* symbol > from file ./scripts/mod/Module.ksymb into kconfig_symbol > attribute of struct module. This information will be > further exposed in userspace for extracting build options

Re: [RFC PATCH 3/3] Add dynamic pegging of Kconfig symbol

On Sun, Jul 31, 2016 at 05:33:52PM +0200, Cristina Moraru wrote: > Update modpost to add dynamic pegging of CONFIG_* symbol > from file ./scripts/mod/Module.ksymb into kconfig_symbol > attribute of struct module. This information will be > further exposed in userspace for extracting build options

Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly

On Mon, Aug 8, 2016 at 8:00 PM, Thomas Garnier wrote: > On Mon, Aug 8, 2016 at 6:54 AM, Rafael J. Wysocki wrote: >> On Mon, Aug 8, 2016 at 3:40 PM, Borislav Petkov wrote: >>> On Mon, Aug 08, 2016 at 03:31:31PM +0200, Rafael J. Wysocki wrote:

Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly

On Mon, Aug 8, 2016 at 8:00 PM, Thomas Garnier wrote: > On Mon, Aug 8, 2016 at 6:54 AM, Rafael J. Wysocki wrote: >> On Mon, Aug 8, 2016 at 3:40 PM, Borislav Petkov wrote: >>> On Mon, Aug 08, 2016 at 03:31:31PM +0200, Rafael J. Wysocki wrote: From: Rafael J. Wysocki The low-level

Re: [PATCH 2/7] staging/android: display sync_pt name on debugfs

2016-08-08 Maarten Lankhorst : > Op 20-06-16 om 17:53 schreef Gustavo Padovan: > > From: Gustavo Padovan > > > > When creating a sync_pt the name received wasn't used anywhere. > > Now we add it to the sync info debug output to

Re: [PATCH 2/7] staging/android: display sync_pt name on debugfs

2016-08-08 Maarten Lankhorst : > Op 20-06-16 om 17:53 schreef Gustavo Padovan: > > From: Gustavo Padovan > > > > When creating a sync_pt the name received wasn't used anywhere. > > Now we add it to the sync info debug output to make it easier to indetify > > the userspace name of that sync pt. >

Re: [PATCH v2 2/2] soc: qcom: add l2 cache perf events driver

On 8/5/2016 07:15 PM, Paul Gortmaker wrote: > On Thu, Aug 4, 2016 at 5:11 PM, Neil Leeder wrote: >> Adds perf events support for L2 cache PMU. >> >> The L2 cache PMU driver is named 'l2cache_0' and can be used >> with perf events to profile L2 events such as cache hits

Re: [PATCH v2 2/2] soc: qcom: add l2 cache perf events driver

On 8/5/2016 07:15 PM, Paul Gortmaker wrote: > On Thu, Aug 4, 2016 at 5:11 PM, Neil Leeder wrote: >> Adds perf events support for L2 cache PMU. >> >> The L2 cache PMU driver is named 'l2cache_0' and can be used >> with perf events to profile L2 events such as cache hits >> and misses. >> >>

Re: perf: hard fuzzer crash on 4.8-rc1

On Mon, 8 Aug 2016, Peter Zijlstra wrote: > On Mon, Aug 08, 2016 at 01:57:28PM -0400, Vince Weaver wrote: > > > > [ 637.250130] BUG: unable to handle kernel > > > > About 10 times of triggering this, this is all I get. Machine is fairly > > thoroughly locked at that point. > > > > Any advice

Re: perf: hard fuzzer crash on 4.8-rc1

On Mon, 8 Aug 2016, Peter Zijlstra wrote: > On Mon, Aug 08, 2016 at 01:57:28PM -0400, Vince Weaver wrote: > > > > [ 637.250130] BUG: unable to handle kernel > > > > About 10 times of triggering this, this is all I get. Machine is fairly > > thoroughly locked at that point. > > > > Any advice

Re: [Patch v3 10/11] driver/edac/layerscape_edac: Add Layerscape EDAC support

On 08/08/2016 11:07 AM, Marc Zyngier wrote: > On Thu, 4 Aug 2016 15:58:35 -0700 > York Sun wrote: > >> Add DDR EDAC for ARM-based compatible controllers. Both big-endian >> and little-endian are supported. >> >> Signed-off-by: York Sun >> >> --- >> Change log

Re: [Patch v3 10/11] driver/edac/layerscape_edac: Add Layerscape EDAC support

On 08/08/2016 11:07 AM, Marc Zyngier wrote: > On Thu, 4 Aug 2016 15:58:35 -0700 > York Sun wrote: > >> Add DDR EDAC for ARM-based compatible controllers. Both big-endian >> and little-endian are supported. >> >> Signed-off-by: York Sun >> >> --- >> Change log >> v3: no change >> v2: Create

[PATCH 3.14 11/21] ecryptfs: dont allow mmap when the lower fs doesnt support it

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Jeff Mahoney commit f0fe970df3838c202ef6c07a4c2b36838ef0a88b upstream. There are legitimate reasons to disallow mmap on certain files, notably in sysfs or procfs. We

[PATCH 3.14 16/21] can: at91_can: RX queue could get stuck at high bus load

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Wolfgang Grandegger commit 43200a4480cbbe660309621817f54cbb93907108 upstream. At high bus load it could happen that "at91_poll()" enters with all RX message boxes filled

Re: [PATCH 0/7] de-stage SW_SYNC validation frawework

2016-07-24 Pavel Machek : > On Mon 2016-08-08 16:08:12, Gustavo Padovan wrote: > > 2016-08-07 Pavel Machek : > > > > > On Sun 2016-07-24 15:21:11, Greg Kroah-Hartman wrote: > > > > On Mon, Jul 18, 2016 at 04:12:45PM -0300, Gustavo Padovan wrote: > > > > > Hi, > > > >

[PATCH 3.14 14/21] qeth: delete napi struct when removing a qeth device

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Ursula Braun commit 7831b4ff0d926e0deeaabef9db8800ed069a2757 upstream. A qeth_card contains a napi_struct linked to the net_device during device probing. This

[PATCH 3.14 11/21] ecryptfs: dont allow mmap when the lower fs doesnt support it

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Jeff Mahoney commit f0fe970df3838c202ef6c07a4c2b36838ef0a88b upstream. There are legitimate reasons to disallow mmap on certain files, notably in sysfs or procfs. We shouldn't emulate mmap

[PATCH 3.14 16/21] can: at91_can: RX queue could get stuck at high bus load

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Wolfgang Grandegger commit 43200a4480cbbe660309621817f54cbb93907108 upstream. At high bus load it could happen that "at91_poll()" enters with all RX message boxes filled up. If then at the

Re: [PATCH 0/7] de-stage SW_SYNC validation frawework

2016-07-24 Pavel Machek : > On Mon 2016-08-08 16:08:12, Gustavo Padovan wrote: > > 2016-08-07 Pavel Machek : > > > > > On Sun 2016-07-24 15:21:11, Greg Kroah-Hartman wrote: > > > > On Mon, Jul 18, 2016 at 04:12:45PM -0300, Gustavo Padovan wrote: > > > > > Hi, > > > > > > > > > > Do you think

[PATCH 3.14 14/21] qeth: delete napi struct when removing a qeth device

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Ursula Braun commit 7831b4ff0d926e0deeaabef9db8800ed069a2757 upstream. A qeth_card contains a napi_struct linked to the net_device during device probing. This struct must be deleted when

[PATCH 3.14 15/21] mmc: block: fix packed command header endianness

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Taras Kondratiuk commit f68381a70bb2b26c31b13fdaf67c778f92fd32b4 upstream. The code that fills packed command header assumes that CPU runs in little-endian mode. Hence the

[PATCH 3.14 15/21] mmc: block: fix packed command header endianness

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Taras Kondratiuk commit f68381a70bb2b26c31b13fdaf67c778f92fd32b4 upstream. The code that fills packed command header assumes that CPU runs in little-endian mode. Hence the header is malformed

[PATCH 4.4 03/68] x86/quirks: Reintroduce scanning of secondary buses

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Lukas Wunner commit 850c321027c2e31d0afc71588974719a4b565550 upstream. We used to scan secondary buses until the following commit that was applied in 2009: 8659c406ade3

[PATCH 4.4 18/68] ARC: unwind: ensure that .debug_frame is generated (vs. .eh_frame)

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Vineet Gupta commit f52e126cc7476196f44f3c313b7d9f0699a881fc upstream. With recent binutils update to support dwarf CFI pseudo-ops in gas, we now get .eh_frame vs.

[PATCH 4.4 03/68] x86/quirks: Reintroduce scanning of secondary buses

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Lukas Wunner commit 850c321027c2e31d0afc71588974719a4b565550 upstream. We used to scan secondary buses until the following commit that was applied in 2009: 8659c406ade3 ("x86: only scan the

[PATCH 4.4 18/68] ARC: unwind: ensure that .debug_frame is generated (vs. .eh_frame)

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Vineet Gupta commit f52e126cc7476196f44f3c313b7d9f0699a881fc upstream. With recent binutils update to support dwarf CFI pseudo-ops in gas, we now get .eh_frame vs. .debug_frame. Although the

[PATCH 4.4 19/68] xen/pciback: Fix conf_space read/write overlap check.

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Andrey Grodzovsky commit 02ef871ecac290919ea0c783d05da7eedeffc10e upstream. Current overlap check is evaluating to false a case where a filter field is fully contained

[PATCH 4.4 19/68] xen/pciback: Fix conf_space read/write overlap check.

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Andrey Grodzovsky commit 02ef871ecac290919ea0c783d05da7eedeffc10e upstream. Current overlap check is evaluating to false a case where a filter field is fully contained (proper subset) of a r/w

[PATCH 4.4 27/68] Input: xpad - fix oops when attaching an unknown Xbox One gamepad

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Cameron Gutman commit c7f1429389ec1aa25e042bb13451385fbb596f8c upstream. Xbox One controllers have multiple interfaces which all have the same class, subclass, and

[PATCH 4.4 09/68] mm, compaction: abort free scanner if split fails

4.4-stable review patch. If anyone has any objections, please let me know. -- From: David Rientjes commit a4f04f2c6955aff5e2c08dcb40aca247ff4d7370 upstream. If the memory compaction free scanner cannot successfully split a free page (only possible due to

[PATCH 4.4 27/68] Input: xpad - fix oops when attaching an unknown Xbox One gamepad

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Cameron Gutman commit c7f1429389ec1aa25e042bb13451385fbb596f8c upstream. Xbox One controllers have multiple interfaces which all have the same class, subclass, and protocol. One of the these

[PATCH 4.4 09/68] mm, compaction: abort free scanner if split fails

4.4-stable review patch. If anyone has any objections, please let me know. -- From: David Rientjes commit a4f04f2c6955aff5e2c08dcb40aca247ff4d7370 upstream. If the memory compaction free scanner cannot successfully split a free page (only possible due to per-zone low

[PATCH 4.4 20/68] xenbus: dont BUG() on user mode induced condition

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Jan Beulich commit 0beef634b86a1350c31da5fcc2992f0d7c8a622b upstream. Inability to locate a user mode specified transaction ID should not lead to a kernel crash. For other

[PATCH 4.4 20/68] xenbus: dont BUG() on user mode induced condition

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Jan Beulich commit 0beef634b86a1350c31da5fcc2992f0d7c8a622b upstream. Inability to locate a user mode specified transaction ID should not lead to a kernel crash. For other than

[PATCH 4.4 34/68] cgroup: set css->id to -1 during init

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Tejun Heo commit 8fa3b8d689a54d6d04ff7803c724fb7aca6ce98e upstream. If percpu_ref initialization fails during css_create(), the free path can end up trying to free css->id of

[PATCH 4.4 29/68] Input: xpad - validate USB endpoint count during probe

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Cameron Gutman commit caca925fca4fb30c67be88cacbe908eec6721e43 upstream. This prevents a malicious USB device from causing an oops. Signed-off-by: Cameron Gutman

[PATCH 4.4 31/68] pvclock: Add CPU barriers to get correct version value

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Minfei Huang commit 749d088b8e7f4b9826ede02b9a043e417fa84aa1 upstream. Protocol for the "version" fields is: hypervisor raises it (making it uneven) before it starts

[PATCH 4.4 39/68] ext4: verify extent header depth

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Vegard Nossum commit 7bc9491645118c9461bd21099c31755ff6783593 upstream. Although the extent tree depth of 5 should enough be for the worst case of 2*32 extents of

[PATCH 4.4 34/68] cgroup: set css->id to -1 during init

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Tejun Heo commit 8fa3b8d689a54d6d04ff7803c724fb7aca6ce98e upstream. If percpu_ref initialization fails during css_create(), the free path can end up trying to free css->id of zero. As ID 0 is

[PATCH 4.4 29/68] Input: xpad - validate USB endpoint count during probe

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Cameron Gutman commit caca925fca4fb30c67be88cacbe908eec6721e43 upstream. This prevents a malicious USB device from causing an oops. Signed-off-by: Cameron Gutman Signed-off-by: Dmitry

[PATCH 4.4 31/68] pvclock: Add CPU barriers to get correct version value

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Minfei Huang commit 749d088b8e7f4b9826ede02b9a043e417fa84aa1 upstream. Protocol for the "version" fields is: hypervisor raises it (making it uneven) before it starts updating the fields and

[PATCH 4.4 39/68] ext4: verify extent header depth

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Vegard Nossum commit 7bc9491645118c9461bd21099c31755ff6783593 upstream. Although the extent tree depth of 5 should enough be for the worst case of 2*32 extents of length 1, the extent tree

[PATCH 4.4 41/68] namespace: update event counter when umounting a deleted dentry

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Andrey Ulanov commit e06b933e6ded42384164d28a2060b7f89243b895 upstream. - m_start() in fs/namespace.c expects that ns->event is incremented each time a mount added or

[PATCH 4.4 43/68] spi: sun4i: fix FIFO limit

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Michal Suchanek commit 6d9fe44bd73d567d04d3a68a2d2fa521ab9532f2 upstream. When testing SPI without DMA I noticed that filling the FIFO on the spi controller causes timeout.

[PATCH 4.4 38/68] ecryptfs: dont allow mmap when the lower fs doesnt support it

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Jeff Mahoney commit f0fe970df3838c202ef6c07a4c2b36838ef0a88b upstream. There are legitimate reasons to disallow mmap on certain files, notably in sysfs or procfs. We shouldn't

Re: [PATCH v13 00/16] PCI: Fixup for 64bit resource with sparc

On Fri, Jun 17, 2016 at 07:24:45PM -0700, Yinghai Lu wrote: > Hi Bjorn, > > After 5b28541552ef (PCI: Restrict 64-bit prefetchable bridge windows > to 64-bit resources), we have several reports on resource allocation > failure, and we try to fix the problem with resource clip, and find > more

[PATCH 4.4 40/68] 9p: use file_dentry()

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Miklos Szeredi commit b403f0e37a11f84f7ceaf40b0075499e5bcfd220 upstream. v9fs may be used as lower layer of overlayfs and accessing f_path.dentry can lead to a crash. In

[PATCH 4.4 43/68] spi: sun4i: fix FIFO limit

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Michal Suchanek commit 6d9fe44bd73d567d04d3a68a2d2fa521ab9532f2 upstream. When testing SPI without DMA I noticed that filling the FIFO on the spi controller causes timeout. Always leave room

[PATCH 4.4 38/68] ecryptfs: dont allow mmap when the lower fs doesnt support it

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Jeff Mahoney commit f0fe970df3838c202ef6c07a4c2b36838ef0a88b upstream. There are legitimate reasons to disallow mmap on certain files, notably in sysfs or procfs. We shouldn't emulate mmap

Re: [PATCH v13 00/16] PCI: Fixup for 64bit resource with sparc

On Fri, Jun 17, 2016 at 07:24:45PM -0700, Yinghai Lu wrote: > Hi Bjorn, > > After 5b28541552ef (PCI: Restrict 64-bit prefetchable bridge windows > to 64-bit resources), we have several reports on resource allocation > failure, and we try to fix the problem with resource clip, and find > more

[PATCH 4.4 40/68] 9p: use file_dentry()

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Miklos Szeredi commit b403f0e37a11f84f7ceaf40b0075499e5bcfd220 upstream. v9fs may be used as lower layer of overlayfs and accessing f_path.dentry can lead to a crash. In this case it's a NULL

[PATCH 4.4 41/68] namespace: update event counter when umounting a deleted dentry

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Andrey Ulanov commit e06b933e6ded42384164d28a2060b7f89243b895 upstream. - m_start() in fs/namespace.c expects that ns->event is incremented each time a mount added or removed from ns->list.

[PATCH 4.4 13/68] mm, meminit: ensure node is online before checking whether pages are uninitialised

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Mel Gorman commit ef70b6f41cda6270165a6f27b2548ed31cfa3cb2 upstream. early_page_uninitialised looks up an arbitrary PFN. While a machine without node 0 will boot

[PATCH 4.4 44/68] clk: rockchip: initialize flags of clk_init_data in mmc-phase clock

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Heiko Stuebner commit 595144c1141c951a3c6bb9004ae6a2bc29aad66f upstream. The flags element of clk_init_data was never initialized for mmc- phase-clocks resulting in the

<    1   2   3   4   5   6   7   8   9   10   >