[PATCH 10/10] dma: imx-sdma: clear channel0 interrupt bit in irq routine

When SDMA channel0 timeouts, even it's disabled in error path, but sometimes we still see its interrupt bit be asserted, which causes irq routine be triggered continuously because no one else clears this bit. This commit clears channel0 interrupt as well in irq routine, so that even channel0

[PATCH v1 00/10] *** imx-sdma: misc fix ***

this patch set contains the following changes 1. fix issues in cyclic dma 2. add support to SYNC DMA termination 3. avoid system hang, when SDMA channel 0 timeouts 4. add lock to prevent race condition Jiada Wang (10): dma: imx-sdma: use chn_real_count to report residue for UART dma:

[PATCH 07/10] dma: imx-sdma: Add synchronization support

Implement the new device_synchronize() callback to allow proper synchronization when stopping a channel. Since the driver already makes sure that no new complete callbacks are scheduled after the device_terminate_all() has been called, all left to do in the device_synchronize() callback is to wait

[PATCH 10/10] dma: imx-sdma: clear channel0 interrupt bit in irq routine

When SDMA channel0 timeouts, even it's disabled in error path, but sometimes we still see its interrupt bit be asserted, which causes irq routine be triggered continuously because no one else clears this bit. This commit clears channel0 interrupt as well in irq routine, so that even channel0

[PATCH 05/10] dma: imx-sdma: add flag to indicate SDMA channel state

There is race between STOP of SDMA channel and finish of SDMA transfer, so some times, even after sdma_disable_channel() is called, the bit of 'terminated channel' in INTR may still get asserted, thus cause an extra sdma tasklet be called. Add flag 'enabled' to each sdma channel to indicate its

[PATCH 01/10] dma: imx-sdma: use chn_real_count to report residue for UART

For uart rx dma data may not receive fully, so the number of data read by sdma script once isn't always equal to period_len, thus residue returned from sdma_tx_status() isn't valid for uart rx dma. The old way to use chn_real_count to report residue should be used for uart rx dma. Signed-off-by:

[PATCH 05/10] dma: imx-sdma: add flag to indicate SDMA channel state

There is race between STOP of SDMA channel and finish of SDMA transfer, so some times, even after sdma_disable_channel() is called, the bit of 'terminated channel' in INTR may still get asserted, thus cause an extra sdma tasklet be called. Add flag 'enabled' to each sdma channel to indicate its

[PATCH 01/10] dma: imx-sdma: use chn_real_count to report residue for UART

For uart rx dma data may not receive fully, so the number of data read by sdma script once isn't always equal to period_len, thus residue returned from sdma_tx_status() isn't valid for uart rx dma. The old way to use chn_real_count to report residue should be used for uart rx dma. Signed-off-by:

[PATCH 08/10] dma: imx-sdma: abort updating channel when it has been terminated

In case the corresponding channel has already been terminated, then instead of go on updating channel status, driver should abort from sdma_handle_channel_loop(), otherwise channel status will be updated incorrecly. This patch also adds lock to avoid race between terminate of channel, and updaing

[PATCH 08/10] dma: imx-sdma: abort updating channel when it has been terminated

In case the corresponding channel has already been terminated, then instead of go on updating channel status, driver should abort from sdma_handle_channel_loop(), otherwise channel status will be updated incorrecly. This patch also adds lock to avoid race between terminate of channel, and updaing

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Mon, May 16, 2016 at 10:28:32PM -0400, James Bottomley wrote: > On Mon, 2016-05-16 at 19:41 +, Serge Hallyn wrote: > > Hey James, > > > > I probably did something wrong - but i applied your patch onto 4.6, > > compiled in shiftfs, did > > > > mount -t shiftfs -o

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Mon, May 16, 2016 at 10:28:32PM -0400, James Bottomley wrote: > On Mon, 2016-05-16 at 19:41 +, Serge Hallyn wrote: > > Hey James, > > > > I probably did something wrong - but i applied your patch onto 4.6, > > compiled in shiftfs, did > > > > mount -t shiftfs -o

[PATCH] asix: Fix offset calculation in asix_rx_fixup() causing slow transmissions

In testing with HiKey, we found that since commit 3f30b158eba5 ("asix: On RX avoid creating bad Ethernet frames"), we're seeing lots of noise during network transfers: [ 239.027993] asix 1-1.1:1.0 eth0: asix_rx_fixup() Data Header synchronisation was lost, remaining 988 [ 239.037310] asix

[PATCH] asix: Fix offset calculation in asix_rx_fixup() causing slow transmissions

In testing with HiKey, we found that since commit 3f30b158eba5 ("asix: On RX avoid creating bad Ethernet frames"), we're seeing lots of noise during network transfers: [ 239.027993] asix 1-1.1:1.0 eth0: asix_rx_fixup() Data Header synchronisation was lost, remaining 988 [ 239.037310] asix

Re: [PATCH] Staging: comedi: quatech_daqp_cs.c: fixed a warning issue

A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Tue, May 17, 2016 at 08:55:56AM +0530, Amit Ghadge wrote: > I check with "./scripts/checkpatch.pl --file --terse > drivers/staging/comedi/drivers/quatech_daqp_cs.c" and show the warning >

Re: [PATCH] Staging: comedi: quatech_daqp_cs.c: fixed a warning issue

A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Tue, May 17, 2016 at 08:55:56AM +0530, Amit Ghadge wrote: > I check with "./scripts/checkpatch.pl --file --terse > drivers/staging/comedi/drivers/quatech_daqp_cs.c" and show the warning >

[PATCH] Drivers: hv: vmbus: fix the race when querying & updating the percpu list

There is a rare race when we remove an entry from the global list hv_context.percpu_list[cpu] in hv_process_channel_removal() -> percpu_channel_deq() -> list_del(): at this time, if vmbus_on_event() -> process_chn_event() -> pcpu_relid2channel() is trying to query the list, we can get the general

[PATCH] Drivers: hv: vmbus: fix the race when querying & updating the percpu list

There is a rare race when we remove an entry from the global list hv_context.percpu_list[cpu] in hv_process_channel_removal() -> percpu_channel_deq() -> list_del(): at this time, if vmbus_on_event() -> process_chn_event() -> pcpu_relid2channel() is trying to query the list, we can get the general

Re: [PATCH] Staging: comedi: quatech_daqp_cs.c: fixed a warning issue

I check with "./scripts/checkpatch.pl --file --terse drivers/staging/comedi/drivers/quatech_daqp_cs.c" and show the warning message, "drivers/staging/comedi/drivers/quatech_daqp_cs.c:646: WARNING: Prefer 'unsigned int' to bare use of 'unsigned'" This patch reduced the warning message. On Mon,

Re: [PATCH] Staging: comedi: quatech_daqp_cs.c: fixed a warning issue

I check with "./scripts/checkpatch.pl --file --terse drivers/staging/comedi/drivers/quatech_daqp_cs.c" and show the warning message, "drivers/staging/comedi/drivers/quatech_daqp_cs.c:646: WARNING: Prefer 'unsigned int' to bare use of 'unsigned'" This patch reduced the warning message. On Mon,

Re: [PATCH 2/8] Documentation: regulator: tps65218: Update examples

On Monday 16 May 2016 08:18 PM, Rob Herring wrote: On Wed, May 11, 2016 at 11:18:05AM +0530, Keerthy wrote: This updates the device tree according to the preferred way of parsing the nodes using the regulator framework. Signed-off-by: Keerthy ---

Re: [PATCH 2/8] Documentation: regulator: tps65218: Update examples

On Monday 16 May 2016 08:18 PM, Rob Herring wrote: On Wed, May 11, 2016 at 11:18:05AM +0530, Keerthy wrote: This updates the device tree according to the preferred way of parsing the nodes using the regulator framework. Signed-off-by: Keerthy ---

[GIT PULL] Thermal SoC management updates for v4.7

Hello Rui, Here is material for 4.7 on thermal SoC. I have rebased this branch on top of latest linus tree. But this material have been tested and on linux-next for several weeks. The following changes since commit b6ae4055f4ab55c05df31cc1b6a7ea8c85eb525d: Merge tag 'arm64-perf' of

[GIT PULL] Thermal SoC management updates for v4.7

Hello Rui, Here is material for 4.7 on thermal SoC. I have rebased this branch on top of latest linus tree. But this material have been tested and on linux-next for several weeks. The following changes since commit b6ae4055f4ab55c05df31cc1b6a7ea8c85eb525d: Merge tag 'arm64-perf' of

Re: linux-next: manual merge of the vfs tree with the ext4 tree

On Tue, May 17, 2016 at 10:23:55AM +1000, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the vfs tree got conflicts in: > > fs/ext4/ext4.h > fs/ext4/indirect.c > fs/ext4/inode.c > > between commit: > > 914f82a32d02 ("ext4: refactor direct IO code") > > from the ext4

Re: linux-next: manual merge of the vfs tree with the ext4 tree

On Tue, May 17, 2016 at 10:23:55AM +1000, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the vfs tree got conflicts in: > > fs/ext4/ext4.h > fs/ext4/indirect.c > fs/ext4/inode.c > > between commit: > > 914f82a32d02 ("ext4: refactor direct IO code") > > from the ext4

[PATCH 2/2] net: Fix coding style warnings and errors.

Clean up checkpatch warnings and errors: * WARNING: Block comments use * on subsequent lines * WARNING: Missing a blank line after declarations * WARNING: networking block comments don't use an empty /* line, use /* * ERROR: code indent should use tabs where possible * WARNING: please, no space

[PATCH 2/2] net: Fix coding style warnings and errors.

Clean up checkpatch warnings and errors: * WARNING: Block comments use * on subsequent lines * WARNING: Missing a blank line after declarations * WARNING: networking block comments don't use an empty /* line, use /* * ERROR: code indent should use tabs where possible * WARNING: please, no space

Re: [PATCH] mpt3sas: Do scsi_remove_host() before deleting SAS PHY objects

On Monday 05/16 at 15:51 -0600, Sathya Prakash Veerichetty wrote: > Our understanding is the relationship between the SCSI host and SAS end > devices is a parent-child and before ripping of SCSI host we need to rip of > all the children. I know at least HPSA does the opposite, Elliott observes

Re: [PATCH] mpt3sas: Do scsi_remove_host() before deleting SAS PHY objects

On Monday 05/16 at 15:51 -0600, Sathya Prakash Veerichetty wrote: > Our understanding is the relationship between the SCSI host and SAS end > devices is a parent-child and before ripping of SCSI host we need to rip of > all the children. I know at least HPSA does the opposite, Elliott observes

Re: [PATCH V7 07/11] pci, acpi: Handle ACPI companion assignment.

Hi Tomasz I used the patchset and added "PATCH V6 11/13 specic quirks", tested on HiSilicon D02 board but met the below problem. [2.614115] [] hisi_pcie_init+0x6c/0x1ec [2.619571] [] pci_ecam_create+0x130/0x1ec [2.625209] [] pci_acpi_scan_root+0x160/0x218 [2.631096] []

Re: [PATCH V7 07/11] pci, acpi: Handle ACPI companion assignment.

Hi Tomasz I used the patchset and added "PATCH V6 11/13 specic quirks", tested on HiSilicon D02 board but met the below problem. [2.614115] [] hisi_pcie_init+0x6c/0x1ec [2.619571] [] pci_ecam_create+0x130/0x1ec [2.625209] [] pci_acpi_scan_root+0x160/0x218 [2.631096] []

Re: [f2fs-dev] [RFC] f2fs: fix a race condition between evict & gc

On 2016/5/16 23:10, Chao Yu wrote: Hi chao, Hi Pengyang, On 2016/5/16 18:40, Hou Pengyang wrote: When collecting data segment(gc_data_segment), there is a race condition between evict and phases of gc: 0) ra_node_page(dnode) 1) ra_node_page(inode) <--- evict the inode 2)

Re: [f2fs-dev] [RFC] f2fs: fix a race condition between evict & gc

On 2016/5/16 23:10, Chao Yu wrote: Hi chao, Hi Pengyang, On 2016/5/16 18:40, Hou Pengyang wrote: When collecting data segment(gc_data_segment), there is a race condition between evict and phases of gc: 0) ra_node_page(dnode) 1) ra_node_page(inode) <--- evict the inode 2)

[PATCH] ftrace/x86: Set ftrace_stub to weak to prevent gcc from using short jumps to it

Matt Fleming reported seeing crashes when enabling and disabling function profiling which uses function graph tracer. Later Namhyung Kim hit a similar issue and he found that the issue was due to the jmp to ftrace_stub in ftrace_graph_call was only two bytes, and when it was changed to jump to the

[PATCH] ftrace/x86: Set ftrace_stub to weak to prevent gcc from using short jumps to it

Matt Fleming reported seeing crashes when enabling and disabling function profiling which uses function graph tracer. Later Namhyung Kim hit a similar issue and he found that the issue was due to the jmp to ftrace_stub in ftrace_graph_call was only two bytes, and when it was changed to jump to the

RE: [PATCH] usb: gadget: f_fs: report error if excess data received

> There appears to be no kfifo support for iov_iter though, so I just went > with a simple buffer. > > I haven’t looked at the patch too carefully so this is an RFC rather > than an actual patch at this point. It does compile at least. > > Regardless, the more I thin about it, the more I’m

RE: [PATCH] usb: gadget: f_fs: report error if excess data received

> There appears to be no kfifo support for iov_iter though, so I just went > with a simple buffer. > > I haven’t looked at the patch too carefully so this is an RFC rather > than an actual patch at this point. It does compile at least. > > Regardless, the more I thin about it, the more I’m

[PATCH 06/12] perf symbols: Introduce DSO__NAME_KALLSYMS and DSO__NAME_KCORE

From: Masami Hiramatsu Instead of using a raw string, use DSO__NAME_KALLSYMS and DSO__NAME_KCORE macros for kallsyms and kcore. Signed-off-by: Masami Hiramatsu Cc: Ananth N Mavinakayanahalli Cc: Brendan Gregg

[PATCH 07/12] perf core: Generalize max_stack sysctl handler

From: Arnaldo Carvalho de Melo So that it can be used for other stack related knobs, such as the upcoming one to tweak the max number of of contexts per stack sample. In all those cases we can only change the value if there are no perf sessions collecting stacks, so they need

[PATCH 09/12] perf core: Add a 'nr' field to perf_event_callchain_context

From: Arnaldo Carvalho de Melo We will use it to count how many addresses are in the entry->ip[] array, excluding PERF_CONTEXT_{KERNEL,USER,etc} entries, so that we can really return the number of entries specified by the user via the relevant sysctl,

[PATCH 06/12] perf symbols: Introduce DSO__NAME_KALLSYMS and DSO__NAME_KCORE

From: Masami Hiramatsu Instead of using a raw string, use DSO__NAME_KALLSYMS and DSO__NAME_KCORE macros for kallsyms and kcore. Signed-off-by: Masami Hiramatsu Cc: Ananth N Mavinakayanahalli Cc: Brendan Gregg Cc: Hemant Kumar Cc: Namhyung Kim Cc: Peter Zijlstra Link:

[PATCH 07/12] perf core: Generalize max_stack sysctl handler

From: Arnaldo Carvalho de Melo So that it can be used for other stack related knobs, such as the upcoming one to tweak the max number of of contexts per stack sample. In all those cases we can only change the value if there are no perf sessions collecting stacks, so they need to grab that

[PATCH 09/12] perf core: Add a 'nr' field to perf_event_callchain_context

From: Arnaldo Carvalho de Melo We will use it to count how many addresses are in the entry->ip[] array, excluding PERF_CONTEXT_{KERNEL,USER,etc} entries, so that we can really return the number of entries specified by the user via the relevant sysctl, kernel.perf_event_max_contexts, or via the

[PATCH 05/12] perf stat: Use cpu-clock event for cpu targets

From: Namhyung Kim Currently 'perf stat' always counts task-clock event by default. But it's somewhat confusing for system-wide targets (especially with 'sleep N' as the 'sleep' task just sleeps and doesn't use cputime). Changing to cpu-clock event instead for that case

[PATCH 05/12] perf stat: Use cpu-clock event for cpu targets

From: Namhyung Kim Currently 'perf stat' always counts task-clock event by default. But it's somewhat confusing for system-wide targets (especially with 'sleep N' as the 'sleep' task just sleeps and doesn't use cputime). Changing to cpu-clock event instead for that case makes more sense IMHO.

[PATCH 03/12] perf stat: Fix indentation of stalled backend cycle

From: Namhyung Kim The commit 140aeadc1fb5 ("perf stat: Abstract stat metrics printing") changed how shadow metrics are printed, but it missed to update the width of the stalled backend cycles event to 7.2% like others. This resulted in misaligned output like below:

[PATCH 03/12] perf stat: Fix indentation of stalled backend cycle

From: Namhyung Kim The commit 140aeadc1fb5 ("perf stat: Abstract stat metrics printing") changed how shadow metrics are printed, but it missed to update the width of the stalled backend cycles event to 7.2% like others. This resulted in misaligned output like below: Performance counter stats

[PATCH 04/12] perf stat: Update runtime using cpu-clock event

From: Namhyung Kim Currently only the task-clock event updates the runtime_nsec so it cannot show the metric when using cpu-clock events. However cpu clock works basically same as task-clock, so no need to not update the runtime IMHO. Before: # perf stat -a -e

[PATCH 02/12] perf symbols: Store vdso buildid unconditionally

From: He Kuang When unwinding callchains on a different machine, vdso info should be available so the unwind process won't be interrupted if address falls into vdso region. But in most cases, the addresses of sample events are not in vdso range, the buildid of a zero hit vdso

[PATCH 04/12] perf stat: Update runtime using cpu-clock event

From: Namhyung Kim Currently only the task-clock event updates the runtime_nsec so it cannot show the metric when using cpu-clock events. However cpu clock works basically same as task-clock, so no need to not update the runtime IMHO. Before: # perf stat -a -e

[PATCH 02/12] perf symbols: Store vdso buildid unconditionally

From: He Kuang When unwinding callchains on a different machine, vdso info should be available so the unwind process won't be interrupted if address falls into vdso region. But in most cases, the addresses of sample events are not in vdso range, the buildid of a zero hit vdso won't be stored

[PATCH 08/12] perf core: Pass max stack as a perf_callchain_entry context

From: Arnaldo Carvalho de Melo This makes perf_callchain_{user,kernel}() receive the max stack as context for the perf_callchain_entry, instead of accessing the global sysctl_perf_event_max_stack. Cc: Adrian Hunter Cc: Alexander Shishkin

[PATCH 08/12] perf core: Pass max stack as a perf_callchain_entry context

From: Arnaldo Carvalho de Melo This makes perf_callchain_{user,kernel}() receive the max stack as context for the perf_callchain_entry, instead of accessing the global sysctl_perf_event_max_stack. Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Alexei Starovoitov Cc: Brendan Gregg Cc: David

[GIT PULL 00/12] perf/core improvements and fixes

he git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo-20160516 for you to fetch changes up to a29d5c9b8167dbc21a7ca8c0302e3799f9063b4e: perf tools: Separate accounting of contexts and real addresses in a stack trace (2016-05-16 23:11:54

[GIT PULL 00/12] perf/core improvements and fixes

at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo-20160516 for you to fetch changes up to a29d5c9b8167dbc21a7ca8c0302e3799f9063b4e: perf tools: Separate accounting of contexts and real addresses in a stack trace (2016-05-16 23:11:54 -0300

RE: [PATCH v11 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock)

> From: David Miller [mailto:da...@davemloft.net] > Sent: Monday, May 16, 2016 1:16 > To: Dexuan Cui > Cc: gre...@linuxfoundation.org; net...@vger.kernel.org; linux- > ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de; > a...@canonical.com;

RE: [PATCH v11 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock)

> From: David Miller [mailto:da...@davemloft.net] > Sent: Monday, May 16, 2016 1:16 > To: Dexuan Cui > Cc: gre...@linuxfoundation.org; net...@vger.kernel.org; linux- > ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de; > a...@canonical.com; jasow...@redhat.com;

[PATCH 12/12] perf tools: Separate accounting of contexts and real addresses in a stack trace

From: Arnaldo Carvalho de Melo The perf_sample->ip_callchain->nr value includes all the entries in the ip_callchain->ip[] array, real addresses and PERF_CONTEXT_{KERNEL,USER,etc}, while what the user expects is that what is in the kernel.perf_event_max_stack sysctl or in the

[PATCH 11/12] perf core: Separate accounting of contexts and real addresses in a stack trace

From: Arnaldo Carvalho de Melo The perf_sample->ip_callchain->nr value includes all the entries in the ip_callchain->ip[] array, real addresses and PERF_CONTEXT_{KERNEL,USER,etc}, while what the user expects is that what is in the kernel.perf_event_max_stack sysctl or in the

[PATCH 10/12] perf core: Add perf_callchain_store_context() helper

From: Arnaldo Carvalho de Melo We need have different helpers to account how many contexts we have in the sample and for real addresses, so do it now as a prep patch, to ease review. Cc: David Ahern Cc: Frederic Weisbecker Cc: Jiri Olsa

[PATCH 01/12] perf stat: Avoid fractional digits for integer scales

From: Andi Kleen When the scaling factor is a full integer don't display fractional digits. This avoids unnecessary .00 output for topdown metrics with scale factors. v2: Remove redundant check. Signed-off-by: Andi Kleen Acked-by: Jiri Olsa

[PATCH 12/12] perf tools: Separate accounting of contexts and real addresses in a stack trace

From: Arnaldo Carvalho de Melo The perf_sample->ip_callchain->nr value includes all the entries in the ip_callchain->ip[] array, real addresses and PERF_CONTEXT_{KERNEL,USER,etc}, while what the user expects is that what is in the kernel.perf_event_max_stack sysctl or in the upcoming per event

[PATCH 11/12] perf core: Separate accounting of contexts and real addresses in a stack trace

From: Arnaldo Carvalho de Melo The perf_sample->ip_callchain->nr value includes all the entries in the ip_callchain->ip[] array, real addresses and PERF_CONTEXT_{KERNEL,USER,etc}, while what the user expects is that what is in the kernel.perf_event_max_stack sysctl or in the upcoming per event

[PATCH 10/12] perf core: Add perf_callchain_store_context() helper

From: Arnaldo Carvalho de Melo We need have different helpers to account how many contexts we have in the sample and for real addresses, so do it now as a prep patch, to ease review. Cc: David Ahern Cc: Frederic Weisbecker Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Link:

[PATCH 01/12] perf stat: Avoid fractional digits for integer scales

From: Andi Kleen When the scaling factor is a full integer don't display fractional digits. This avoids unnecessary .00 output for topdown metrics with scale factors. v2: Remove redundant check. Signed-off-by: Andi Kleen Acked-by: Jiri Olsa Cc: Peter Zijlstra Link:

Re: [GIT PULL] regulator updates for v4.7

On Mon, May 16, 2016 at 5:27 AM, Mark Brown wrote: > > Mark Brown (26): > regulator: Deprecate regulator_can_change_voltage() This needs to be fixed. It causes a build warning, and it's just not acceptable. We've had driver subsystems do this before, and then the

Re: [GIT PULL] regulator updates for v4.7

On Mon, May 16, 2016 at 5:27 AM, Mark Brown wrote: > > Mark Brown (26): > regulator: Deprecate regulator_can_change_voltage() This needs to be fixed. It causes a build warning, and it's just not acceptable. We've had driver subsystems do this before, and then the warning stays around for

Re: [kernel-hardening] [PATCH] doc: self-protection: provide initial details

On Mon, May 16, 2016 at 07:27:28PM -0700, Kees Cook wrote: > This document attempts to codify the intent around kernel self-protection > along with discussion of both existing and desired technologies, with > attention given to the rationale behind them, and the expectations of > their usage. > >

Re: [kernel-hardening] [PATCH] doc: self-protection: provide initial details

On Mon, May 16, 2016 at 07:27:28PM -0700, Kees Cook wrote: > This document attempts to codify the intent around kernel self-protection > along with discussion of both existing and desired technologies, with > attention given to the rationale behind them, and the expectations of > their usage. > >

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Mon, 2016-05-16 at 19:41 +, Serge Hallyn wrote: > Hey James, > > I probably did something wrong - but i applied your patch onto 4.6, > compiled in shiftfs, did > > mount -t shiftfs -o uidmap=0:10:65536,gidmap=0:10:65536 > /home/ubuntu /mnt > > and ls segfaults and gives me kernel

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Mon, 2016-05-16 at 19:41 +, Serge Hallyn wrote: > Hey James, > > I probably did something wrong - but i applied your patch onto 4.6, > compiled in shiftfs, did > > mount -t shiftfs -o uidmap=0:10:65536,gidmap=0:10:65536 > /home/ubuntu /mnt > > and ls segfaults and gives me kernel

[PATCH] doc: self-protection: provide initial details

This document attempts to codify the intent around kernel self-protection along with discussion of both existing and desired technologies, with attention given to the rationale behind them, and the expectations of their usage. Signed-off-by: Kees Cook ---

[PATCH] doc: self-protection: provide initial details

This document attempts to codify the intent around kernel self-protection along with discussion of both existing and desired technologies, with attention given to the rationale behind them, and the expectations of their usage. Signed-off-by: Kees Cook ---

Re: [PATCH 2/2] net: ethernet: fec-mpc52xx: use phy_ethtool_{get|set}_link_ksettings

From: Philippe Reynes Date: Tue, 17 May 2016 00:32:34 +0200 > There are two generics functions phy_ethtool_{get|set}_link_ksettings, > so we can use them instead of defining the same code in the driver. > > Signed-off-by: Philippe Reynes Applied.

Re: [PATCH 2/2] net: ethernet: fec-mpc52xx: use phy_ethtool_{get|set}_link_ksettings

From: Philippe Reynes Date: Tue, 17 May 2016 00:32:34 +0200 > There are two generics functions phy_ethtool_{get|set}_link_ksettings, > so we can use them instead of defining the same code in the driver. > > Signed-off-by: Philippe Reynes Applied.

Re: [PATCH 1/2] net: ethernet: fec-mpc52xx: use phydev from struct net_device

From: Philippe Reynes Date: Tue, 17 May 2016 00:32:33 +0200 > The private structure contain a pointer to phydev, but the structure > net_device already contain such pointer. So we can remove the pointer > phydev in the private structure, and update the driver to use the > one

Re: [PATCH 1/2] net: ethernet: fec-mpc52xx: use phydev from struct net_device

From: Philippe Reynes Date: Tue, 17 May 2016 00:32:33 +0200 > The private structure contain a pointer to phydev, but the structure > net_device already contain such pointer. So we can remove the pointer > phydev in the private structure, and update the driver to use the > one contained in struct

Re: [PATCH 2/2] net: ethernet: fs-enet: use phy_ethtool_{get|set}_link_ksettings

From: Philippe Reynes Date: Mon, 16 May 2016 16:52:37 +0200 > There are two generics functions phy_ethtool_{get|set}_link_ksettings, > so we can use them instead of defining the same code in the driver. > > Signed-off-by: Philippe Reynes Applied.

Re: [PATCH 1/2] net: ethernet: fs-enet: use phydev from struct net_device

From: Philippe Reynes Date: Mon, 16 May 2016 16:52:36 +0200 > The private structure contain a pointer to phydev, but the structure > net_device already contain such pointer. So we can remove the pointer > phydev in the private structure, and update the driver to use the > one

Re: [PATCH 2/2] net: ethernet: fs-enet: use phy_ethtool_{get|set}_link_ksettings

From: Philippe Reynes Date: Mon, 16 May 2016 16:52:37 +0200 > There are two generics functions phy_ethtool_{get|set}_link_ksettings, > so we can use them instead of defining the same code in the driver. > > Signed-off-by: Philippe Reynes Applied.

Re: [PATCH 1/2] net: ethernet: fs-enet: use phydev from struct net_device

From: Philippe Reynes Date: Mon, 16 May 2016 16:52:36 +0200 > The private structure contain a pointer to phydev, but the structure > net_device already contain such pointer. So we can remove the pointer > phydev in the private structure, and update the driver to use the > one contained in struct

[PATCH 3.14 16/17] net: fix a kernel infoleak in x25 module

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Kangjie Lu [ Upstream commit 79e48650320e6fba48369fccf13fd045315b19b8 ] Stack object "dte_facilities" is allocated in x25_rx_call_request(), which is supposed to be

[PATCH 3.14 16/17] net: fix a kernel infoleak in x25 module

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Kangjie Lu [ Upstream commit 79e48650320e6fba48369fccf13fd045315b19b8 ] Stack object "dte_facilities" is allocated in x25_rx_call_request(), which is supposed to be initialized in

[PATCH 3.14 11/17] atl2: Disable unimplemented scatter/gather feature

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Ben Hutchings [ Upstream commit f43bfaeddc79effbf3d0fcb53ca477cca66f3db8 ] atl2 includes NETIF_F_SG in hw_features even though it has no support for non-linear skbs.

[PATCH 3.14 11/17] atl2: Disable unimplemented scatter/gather feature

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Ben Hutchings [ Upstream commit f43bfaeddc79effbf3d0fcb53ca477cca66f3db8 ] atl2 includes NETIF_F_SG in hw_features even though it has no support for non-linear skbs. This bug was originally

[PATCH 3.14 17/17] arm64: Make arch_randomize_brk avoid stack area

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Jon Medhurst [As mentioned in the commit message, the problem this patch fixes can't occur in kernels with commit d1fd836dcf00, i.e Linux 4.1 and later., but earlier kernel

[PATCH 3.14 02/17] get_rock_ridge_filename(): handle malformed NM entries

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Al Viro commit 99d825822eade8d827a1817357cbf3f889a552d6 upstream. Payloads of NM entries are not supposed to contain NUL. When we run into such, only the part prior

[PATCH 3.14 15/17] net: bridge: fix old ioctl unlocked net device walk

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Nikolay Aleksandrov [ Upstream commit 31ca0458a61a502adb7ed192bf9716c6d05791a5 ] get_bridge_ifindices() is used from the old "deviceless" bridge ioctl calls which

[PATCH 3.14 02/17] get_rock_ridge_filename(): handle malformed NM entries

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Al Viro commit 99d825822eade8d827a1817357cbf3f889a552d6 upstream. Payloads of NM entries are not supposed to contain NUL. When we run into such, only the part prior to the first NUL goes

[PATCH 3.14 15/17] net: bridge: fix old ioctl unlocked net device walk

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Nikolay Aleksandrov [ Upstream commit 31ca0458a61a502adb7ed192bf9716c6d05791a5 ] get_bridge_ifindices() is used from the old "deviceless" bridge ioctl calls which aren't called with rtnl

[PATCH 3.14 17/17] arm64: Make arch_randomize_brk avoid stack area

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Jon Medhurst [As mentioned in the commit message, the problem this patch fixes can't occur in kernels with commit d1fd836dcf00, i.e Linux 4.1 and later., but earlier kernel versions need this

[PATCH 4.4 14/73] ipv4/fib: dont warn when primary address is missing if in_dev is dead

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Paolo Abeni [ Upstream commit 391a20333b8393ef2e13014e6e59d192c5594471 ] After commit fbd40ea0180a ("ipv4: Don't do expensive useless work during inetdev destroy.") when

[PATCH 3.14 04/17] asmlinkage, pnp: Make variables used from assembler code visible

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Andi Kleen commit a99aa42d0253f033cbb85096d3f2bd82201321e6 upstream. Mark variables referenced from assembler files visible. This fixes compile problems with LTO. Cc:

[PATCH 3.14 09/17] route: do not cache fib route info on local routes with oif

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Chris Friesen [ Upstream commit d6d5e999e5df67f8ec20b6be45e2229455ee3699 ] For local routes that require a particular output interface we do not want to cache the

[PATCH 4.4 14/73] ipv4/fib: dont warn when primary address is missing if in_dev is dead

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Paolo Abeni [ Upstream commit 391a20333b8393ef2e13014e6e59d192c5594471 ] After commit fbd40ea0180a ("ipv4: Don't do expensive useless work during inetdev destroy.") when deleting an interface,

[PATCH 3.14 04/17] asmlinkage, pnp: Make variables used from assembler code visible

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Andi Kleen commit a99aa42d0253f033cbb85096d3f2bd82201321e6 upstream. Mark variables referenced from assembler files visible. This fixes compile problems with LTO. Cc: Jaroslav Kysela

[PATCH 3.14 09/17] route: do not cache fib route info on local routes with oif

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Chris Friesen [ Upstream commit d6d5e999e5df67f8ec20b6be45e2229455ee3699 ] For local routes that require a particular output interface we do not want to cache the result. Caching the result

[PATCH 3.14 03/17] Input: max8997-haptic - fix NULL pointer dereference

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Marek Szyprowski commit 6ae645d5fa385f3787bf1723639cd907fe5865e7 upstream. NULL pointer derefence happens when booting with DTB because the platform data for haptic

[PATCH 3.14 03/17] Input: max8997-haptic - fix NULL pointer dereference

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Marek Szyprowski commit 6ae645d5fa385f3787bf1723639cd907fe5865e7 upstream. NULL pointer derefence happens when booting with DTB because the platform data for haptic device is not set in

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