[PATCH v1 1/1] Add Trusted Path Execution as a stackable LSM

This patch was modified from Brad Spengler's Trusted Path Execution (TPE) feature in Grsecurity and also incorporates logging ideas from cormander's tpe-lkm. Modifications from the Grsecurity implementation of TPE were made to turn it into a stackable LSM using the existing LSM hook

[PATCH v1 1/1] Add Trusted Path Execution as a stackable LSM

This patch was modified from Brad Spengler's Trusted Path Execution (TPE) feature in Grsecurity and also incorporates logging ideas from cormander's tpe-lkm. Modifications from the Grsecurity implementation of TPE were made to turn it into a stackable LSM using the existing LSM hook

Re: [PATCH v1 7/8] powerpc/Kconfig: Enable STRICT_KERNEL_RWX

On Mon, May 29, 2017 at 6:00 PM, Christophe LEROY wrote: > > > Le 25/05/2017 à 18:45, kbuild test robot a écrit : >> >> Hi Balbir, >> >> [auto build test ERROR on powerpc/next] >> [also build test ERROR on v4.12-rc2 next-20170525] >> [if your patch is applied to the wrong

Re: [PATCH v1 7/8] powerpc/Kconfig: Enable STRICT_KERNEL_RWX

On Mon, May 29, 2017 at 6:00 PM, Christophe LEROY wrote: > > > Le 25/05/2017 à 18:45, kbuild test robot a écrit : >> >> Hi Balbir, >> >> [auto build test ERROR on powerpc/next] >> [also build test ERROR on v4.12-rc2 next-20170525] >> [if your patch is applied to the wrong git tree, please drop us

Re: [PATCH 07/11] blktrace: export cgroup info in trace

Hi Shaohua, [auto build test WARNING on driver-core/driver-core-testing] [also build test WARNING on v4.12-rc3 next-20170602] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Shaohua-Li/kernfs

Re: [PATCH 07/11] blktrace: export cgroup info in trace

Hi Shaohua, [auto build test WARNING on driver-core/driver-core-testing] [also build test WARNING on v4.12-rc3 next-20170602] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Shaohua-Li/kernfs

Re: Hang/soft lockup in d_invalidate with simultaneous calls

On Fri, Jun 2, 2017 at 6:12 PM, Al Viro wrote: > Part of that could be relieved if we turned check_and_drop() into > static void check_and_drop(void *_data) > { > struct detach_data *data = _data; > > if (!data->mountpoint && list_empty(>select.dispose)) >

Re: Hang/soft lockup in d_invalidate with simultaneous calls

On Fri, Jun 2, 2017 at 6:12 PM, Al Viro wrote: > Part of that could be relieved if we turned check_and_drop() into > static void check_and_drop(void *_data) > { > struct detach_data *data = _data; > > if (!data->mountpoint && list_empty(>select.dispose)) >

Re: [PATCH v3 3/8] nvmet: implement namespace identify descriptor list

On Fri, Jun 02, 2017 at 04:46:40PM +0300, Sagi Grimberg wrote: > >> switch (type) { >> case NVME_NQN_NVME: >> diff --git a/drivers/nvme/target/nvmet.h b/drivers/nvme/target/nvmet.h >> index cfc5c7fb0ab7..4c6cb5ea1186 100644 >> --- a/drivers/nvme/target/nvmet.h >> +++

net: icmp vs udp_poll race?

Hi all, On the latest linux-next I'm seeing issues that look like an icmp socket destruction racing with poll(). It manifests in two ways, first: BUG: KASAN: slab-out-of-bounds in skb_queue_empty include/linux/skbuff.h:1197 [inline] BUG: KASAN: slab-out-of-bounds in udp_poll+0x5fb/0x6f0

Re: [PATCH v3 3/8] nvmet: implement namespace identify descriptor list

On Fri, Jun 02, 2017 at 04:46:40PM +0300, Sagi Grimberg wrote: > >> switch (type) { >> case NVME_NQN_NVME: >> diff --git a/drivers/nvme/target/nvmet.h b/drivers/nvme/target/nvmet.h >> index cfc5c7fb0ab7..4c6cb5ea1186 100644 >> --- a/drivers/nvme/target/nvmet.h >> +++

net: icmp vs udp_poll race?

Hi all, On the latest linux-next I'm seeing issues that look like an icmp socket destruction racing with poll(). It manifests in two ways, first: BUG: KASAN: slab-out-of-bounds in skb_queue_empty include/linux/skbuff.h:1197 [inline] BUG: KASAN: slab-out-of-bounds in udp_poll+0x5fb/0x6f0

Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

On Fri, 2 Jun 2017, Paul E. McKenney wrote: > On Fri, May 12, 2017 at 12:10:05PM -0700, Paul E. McKenney wrote: > > On Fri, May 12, 2017 at 02:59:48PM -0400, Nicolas Pitre wrote: > > > On Fri, 12 May 2017, Paul E. McKenney wrote: > > [ . . . ] > > > > No. "Available in mainline" is the name of

Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

On Fri, 2 Jun 2017, Paul E. McKenney wrote: > On Fri, May 12, 2017 at 12:10:05PM -0700, Paul E. McKenney wrote: > > On Fri, May 12, 2017 at 02:59:48PM -0400, Nicolas Pitre wrote: > > > On Fri, 12 May 2017, Paul E. McKenney wrote: > > [ . . . ] > > > > No. "Available in mainline" is the name of

Re: [PATCH v4] add the option of fortified string.h functions

On Fri, Jun 2, 2017 at 2:32 PM, Daniel Micay wrote: > On Fri, 2017-06-02 at 14:07 -0700, Andrew Morton wrote: >> On Fri, 26 May 2017 05:54:04 -0400 Daniel Micay > > wrote: >> >> > This adds support for compiling with a rough equivalent to the glibc

Re: [PATCH v4] add the option of fortified string.h functions

On Fri, Jun 2, 2017 at 2:32 PM, Daniel Micay wrote: > On Fri, 2017-06-02 at 14:07 -0700, Andrew Morton wrote: >> On Fri, 26 May 2017 05:54:04 -0400 Daniel Micay > > wrote: >> >> > This adds support for compiling with a rough equivalent to the glibc >> > _FORTIFY_SOURCE=1 feature, providing

[PATCH net] net: dsa: Fix stale cpu_switch reference after unbind then bind

Commit 9520ed8fb841 ("net: dsa: use cpu_switch instead of ds[0]") replaced the use of dst->ds[0] with dst->cpu_switch since that is functionally equivalent, however, we can now run into an use after free scenario after unbinding then rebinding the switch driver. The use after free happens because

[PATCH net] net: dsa: Fix stale cpu_switch reference after unbind then bind

Commit 9520ed8fb841 ("net: dsa: use cpu_switch instead of ds[0]") replaced the use of dst->ds[0] with dst->cpu_switch since that is functionally equivalent, however, we can now run into an use after free scenario after unbinding then rebinding the switch driver. The use after free happens because

Re: get_random_bytes returns bad randomness before seeding is complete

On Sat, Jun 03, 2017 at 01:58:25AM +0200, Jason A. Donenfeld wrote: > Hi Ted, > > Based on the tone of your last email, before I respond to your > individual points May I gently point out that *your* tone that started this whole thread has been pretty terrible? Quoting your your first

Re: get_random_bytes returns bad randomness before seeding is complete

On Sat, Jun 03, 2017 at 01:58:25AM +0200, Jason A. Donenfeld wrote: > Hi Ted, > > Based on the tone of your last email, before I respond to your > individual points May I gently point out that *your* tone that started this whole thread has been pretty terrible? Quoting your your first

Re: [kernel-hardening] [PATCH 3/6] x86/mmap: properly account for stack randomization in mmap_base

On Fri, Jun 2, 2017 at 8:20 AM, wrote: > From: Rik van Riel > > When RLIMIT_STACK is, for example, 256MB, the current code results in > a gap between the top of the task and mmap_base of 256MB, failing to > take into account the amount by which the stack

Re: [kernel-hardening] [PATCH 3/6] x86/mmap: properly account for stack randomization in mmap_base

On Fri, Jun 2, 2017 at 8:20 AM, wrote: > From: Rik van Riel > > When RLIMIT_STACK is, for example, 256MB, the current code results in > a gap between the top of the task and mmap_base of 256MB, failing to > take into account the amount by which the stack address was randomized. > In other

Re: [kernel-hardening] [PATCH 0/6] move mmap_area and PIE binaries away from the stack

On Fri, Jun 2, 2017 at 8:20 AM, wrote: > There are a few bugs causing the kernel to sometimes map PIE > binaries and the mmap_area where the stack is supposed to go. > > This series fixes them for x86, ARM64, and PPC. > S390 seems to be ok. > > If people are fine with this

Re: [kernel-hardening] [PATCH 0/6] move mmap_area and PIE binaries away from the stack

On Fri, Jun 2, 2017 at 8:20 AM, wrote: > There are a few bugs causing the kernel to sometimes map PIE > binaries and the mmap_area where the stack is supposed to go. > > This series fixes them for x86, ARM64, and PPC. > S390 seems to be ok. > > If people are fine with this approach, I can work

Re: Early discussion about a new lock mechanism

I resend this mail due to I forgot to change it to text mode and was blocked from some servers. Sorry for the inconvenience. 2017-05-25 20:58 GMT+08:00 Rick Chang : > hi > > I would like to provide a lock module to solve the problem as follows: > > I want to efficiently use

Re: Early discussion about a new lock mechanism

I resend this mail due to I forgot to change it to text mode and was blocked from some servers. Sorry for the inconvenience. 2017-05-25 20:58 GMT+08:00 Rick Chang : > hi > > I would like to provide a lock module to solve the problem as follows: > > I want to efficiently use different resources

Re: [PATCH] clk: sunxi-ng: Move all clock types to a library

Hi Stephen, [auto build test ERROR on sunxi/sunxi/for-next] [also build test ERROR on next-20170602] [cannot apply to clk/clk-next v4.12-rc3] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits

Re: [PATCH] clk: sunxi-ng: Move all clock types to a library

Hi Stephen, [auto build test ERROR on sunxi/sunxi/for-next] [also build test ERROR on next-20170602] [cannot apply to clk/clk-next v4.12-rc3] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits

Re: [PATCH 2/6] x86/elf: move 32 bit ELF_ET_DYN_BASE to 256MB

On Fri, Jun 2, 2017 at 8:20 AM, wrote: > From: Rik van Riel > > When setting up mmap_base, we take care to start the mmap base > below the maximum extent to which the stack will grow. However, > we take no such precautions with PIE binaries, which are placed >

Re: [PATCH 2/6] x86/elf: move 32 bit ELF_ET_DYN_BASE to 256MB

On Fri, Jun 2, 2017 at 8:20 AM, wrote: > From: Rik van Riel > > When setting up mmap_base, we take care to start the mmap base > below the maximum extent to which the stack will grow. However, > we take no such precautions with PIE binaries, which are placed > at 5/6 of TASK_SIZE plus a random

Re: [REGRESSION] Touchpad failure after e7348396c6d5 ("Input: ALPS - fix V8+ protocol handling (73 03 28)")

This might be related to https://bugzilla.kernel.org/show_bug.cgi?id=195215 Could you have the user try this change? https://bugzilla.kernel.org/show_bug.cgi?id=195215#c12 On Fri, Jun 02, 2017 at 10:54:52AM -0700, Laura Abbott wrote: > Hi, > > Fedora got a bug report

Re: [REGRESSION] Touchpad failure after e7348396c6d5 ("Input: ALPS - fix V8+ protocol handling (73 03 28)")

This might be related to https://bugzilla.kernel.org/show_bug.cgi?id=195215 Could you have the user try this change? https://bugzilla.kernel.org/show_bug.cgi?id=195215#c12 On Fri, Jun 02, 2017 at 10:54:52AM -0700, Laura Abbott wrote: > Hi, > > Fedora got a bug report

[PATCH v4 net-next 3/3] bpf: update perf event helper functions documentation

From: Teng Qin This commit updates documentation of the bpf_perf_event_output and bpf_perf_event_read helpers to match their implementation. Signed-off-by: Teng Qin Signed-off-by: Alexei Starovoitov --- include/uapi/linux/bpf.h | 11

[PATCH v4 net-next 3/3] bpf: update perf event helper functions documentation

From: Teng Qin This commit updates documentation of the bpf_perf_event_output and bpf_perf_event_read helpers to match their implementation. Signed-off-by: Teng Qin Signed-off-by: Alexei Starovoitov --- include/uapi/linux/bpf.h | 11 +++ tools/include/uapi/linux/bpf.h | 11

[PATCH v4 net-next 2/3] samples/bpf: add tests for more perf event types

From: Teng Qin $ trace_event tests attaching BPF program to HW_CPU_CYCLES, SW_CPU_CLOCK, HW_CACHE_L1D and other events. It runs 'dd' in the background while bpf program collects user and kernel stack trace on counter overflow. User space expects to see sys_read and sys_write in

[PATCH v2 2/3] PCI: Enable PCIe Relaxed Ordering if supported

The PCIe Device Control Register use the bit 4 to indicate that whether the device is permitted to enable relaxed ordering or not. But relaxed ordering is not safe for some platform which could only use strong write ordering, so devices are allowed (but not required) to enable relaxed ordering bit

[PATCH v2 2/3] PCI: Enable PCIe Relaxed Ordering if supported

The PCIe Device Control Register use the bit 4 to indicate that whether the device is permitted to enable relaxed ordering or not. But relaxed ordering is not safe for some platform which could only use strong write ordering, so devices are allowed (but not required) to enable relaxed ordering bit

[PATCH v4 net-next 2/3] samples/bpf: add tests for more perf event types

From: Teng Qin $ trace_event tests attaching BPF program to HW_CPU_CYCLES, SW_CPU_CLOCK, HW_CACHE_L1D and other events. It runs 'dd' in the background while bpf program collects user and kernel stack trace on counter overflow. User space expects to see sys_read and sys_write in the kernel

[PATCH v2 0/3] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

Some devices have problems with Transaction Layer Packets with the Relaxed Ordering Attribute set. This patch set adds a new PCIe Device Flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING, a set of PCI Quirks to catch some known devices with Relaxed Ordering issues, and a use of this new flag by the cxgb4

[PATCH v2 0/3] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

Some devices have problems with Transaction Layer Packets with the Relaxed Ordering Attribute set. This patch set adds a new PCIe Device Flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING, a set of PCI Quirks to catch some known devices with Relaxed Ordering issues, and a use of this new flag by the cxgb4

[PATCH v2 3/3] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

From: Casey Leedom cxgb4 Ethernet driver now queries Root Complex Port to determine if it can send TLPs to it with the Relaxed Ordering Attribute set. Signed-off-by: Casey Leedom Signed-off-by: Ding Tianhong ---

[PATCH v2 1/3] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING

From: Casey Leedom The new flag PCI_DEV_FLAGS_NO_RELAXED_ORDERING indicates that the Relaxed Ordering Attribute should not be used on Transaction Layer Packets destined for the PCIe End Node so flagged. Initially flagged this way are Intel E5-26xx Root Complex Ports which

[PATCH v2 3/3] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

From: Casey Leedom cxgb4 Ethernet driver now queries Root Complex Port to determine if it can send TLPs to it with the Relaxed Ordering Attribute set. Signed-off-by: Casey Leedom Signed-off-by: Ding Tianhong --- drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 1 +

[PATCH v2 1/3] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING

From: Casey Leedom The new flag PCI_DEV_FLAGS_NO_RELAXED_ORDERING indicates that the Relaxed Ordering Attribute should not be used on Transaction Layer Packets destined for the PCIe End Node so flagged. Initially flagged this way are Intel E5-26xx Root Complex Ports which suffer from a Flow

[PATCH v4 net-next 1/3] perf, bpf: Add BPF support to all perf_event types

Allow BPF_PROG_TYPE_PERF_EVENT program types to attach to all perf_event types, including HW_CACHE, RAW, and dynamic pmu events. Only tracepoint/kprobe events are treated differently which require BPF_PROG_TYPE_TRACEPOINT/BPF_PROG_TYPE_KPROBE program types accordingly. Also add support for

[PATCH v4 net-next 0/3] bpf: Add BPF support to all perf_event

v3->v4: one more tweak to reject unsupported events at map update time as Peter suggested v2->v3: more refactoring to address Peter's feedback. Now all perf_events are attachable and readable v1->v2: address Peter's feedback. Refactor patch 1 to allow attaching bpf programs to all event types

[PATCH v4 net-next 1/3] perf, bpf: Add BPF support to all perf_event types

Allow BPF_PROG_TYPE_PERF_EVENT program types to attach to all perf_event types, including HW_CACHE, RAW, and dynamic pmu events. Only tracepoint/kprobe events are treated differently which require BPF_PROG_TYPE_TRACEPOINT/BPF_PROG_TYPE_KPROBE program types accordingly. Also add support for

[PATCH v4 net-next 0/3] bpf: Add BPF support to all perf_event

v3->v4: one more tweak to reject unsupported events at map update time as Peter suggested v2->v3: more refactoring to address Peter's feedback. Now all perf_events are attachable and readable v1->v2: address Peter's feedback. Refactor patch 1 to allow attaching bpf programs to all event types

Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

On Fri, May 12, 2017 at 12:10:05PM -0700, Paul E. McKenney wrote: > On Fri, May 12, 2017 at 02:59:48PM -0400, Nicolas Pitre wrote: > > On Fri, 12 May 2017, Paul E. McKenney wrote: [ . . . ] > > No. "Available in mainline" is the name of the game for all I do. If it > > can't be made acceptable

Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

On Fri, May 12, 2017 at 12:10:05PM -0700, Paul E. McKenney wrote: > On Fri, May 12, 2017 at 02:59:48PM -0400, Nicolas Pitre wrote: > > On Fri, 12 May 2017, Paul E. McKenney wrote: [ . . . ] > > No. "Available in mainline" is the name of the game for all I do. If it > > can't be made acceptable

[PATCH] perf/tracing/cpuhotplug: don't release cred_guard_mutex if not taken

From: Alexander Levin If we failed to acquire task's cred_guard_mutex we shouldn't proceed to release it in the error path. Fixes: a63fbed776c ("perf/tracing/cpuhotplug: Fix locking order") Signed-off-by: Alexander Levin ---

[PATCH] perf/tracing/cpuhotplug: don't release cred_guard_mutex if not taken

From: Alexander Levin If we failed to acquire task's cred_guard_mutex we shouldn't proceed to release it in the error path. Fixes: a63fbed776c ("perf/tracing/cpuhotplug: Fix locking order") Signed-off-by: Alexander Levin --- kernel/events/core.c | 2 +- 1 file changed, 1 insertion(+), 1

Re: [PATCH 6/7] RISC-V: arch/riscv/kernel

On Thu, 25 May 2017 10:05:05 PDT (-0700), pa...@ucw.cz wrote: >> +static void ci_leaf_init(struct cacheinfo *this_leaf, >> + struct device_node *node, >> + enum cache_type type, unsigned int level) >> +{ >> +this_leaf->of_node = node; >> +

Re: [PATCH 6/7] RISC-V: arch/riscv/kernel

On Thu, 25 May 2017 10:05:05 PDT (-0700), pa...@ucw.cz wrote: >> +static void ci_leaf_init(struct cacheinfo *this_leaf, >> + struct device_node *node, >> + enum cache_type type, unsigned int level) >> +{ >> +this_leaf->of_node = node; >> +

[PATCH] KVM: nVMX: Fix exception injection

From: Wanpeng Li WARNING: CPU: 3 PID: 2840 at arch/x86/kvm/vmx.c:10966 nested_vmx_vmexit+0xdcd/0xde0 [kvm_intel] CPU: 3 PID: 2840 Comm: qemu-system-x86 Tainted: G OE 4.12.0-rc3+ #23 RIP: 0010:nested_vmx_vmexit+0xdcd/0xde0 [kvm_intel] Call Trace: ?

[PATCH] KVM: nVMX: Fix exception injection

From: Wanpeng Li WARNING: CPU: 3 PID: 2840 at arch/x86/kvm/vmx.c:10966 nested_vmx_vmexit+0xdcd/0xde0 [kvm_intel] CPU: 3 PID: 2840 Comm: qemu-system-x86 Tainted: G OE 4.12.0-rc3+ #23 RIP: 0010:nested_vmx_vmexit+0xdcd/0xde0 [kvm_intel] Call Trace: ?

[RFC PATCH v3 04/11] [media] vimc: common: Add vimc_pipeline_s_stream helper

Move the vimc_cap_pipeline_s_stream from the vimc-cap.c to vimc-common.c as this core will be reused by other subdevices to activate the stream in their directly connected nodes Signed-off-by: Helen Koike --- Changes in v3: [media] vimc: Add vimc_pipeline_s_stream in

[RFC PATCH v3 04/11] [media] vimc: common: Add vimc_pipeline_s_stream helper

Move the vimc_cap_pipeline_s_stream from the vimc-cap.c to vimc-common.c as this core will be reused by other subdevices to activate the stream in their directly connected nodes Signed-off-by: Helen Koike --- Changes in v3: [media] vimc: Add vimc_pipeline_s_stream in the core - add it

[RFC PATCH v3 03/11] [media] vimc: common: Add vimc_ent_sd_* helper

As all the subdevices in the topology will be initialized in the same way, to avoid code repetition the vimc_ent_sd_{register, unregister} helper functions were created Signed-off-by: Helen Koike --- Changes in v3: [media] vimc: Add vimc_ent_sd_* helper functions

Re: [media] vimc: API proposal, configuring the topology from user space

ping On 2017-04-10 07:53 PM, Helen Koike wrote: Hi, Continuing the discussion about the API of the vimc driver, I made some changes based on the previous comments, please see below and let me know your opinion about it. Helen /*** Configfs considerations:

Re: [media] vimc: API proposal, configuring the topology from user space

ping On 2017-04-10 07:53 PM, Helen Koike wrote: Hi, Continuing the discussion about the API of the vimc driver, I made some changes based on the previous comments, please see below and let me know your opinion about it. Helen /*** Configfs considerations:

[RFC PATCH v3 03/11] [media] vimc: common: Add vimc_ent_sd_* helper

As all the subdevices in the topology will be initialized in the same way, to avoid code repetition the vimc_ent_sd_{register, unregister} helper functions were created Signed-off-by: Helen Koike --- Changes in v3: [media] vimc: Add vimc_ent_sd_* helper functions - add it in

Re: Unify the various copies of libgcc into lib

On Wed, 24 May 2017 02:21:22 PDT (-0700), ge...@linux-m68k.org wrote: > Hi Palmer, > > On Wed, May 24, 2017 at 12:05 AM, Palmer Dabbelt wrote: >> I'm in the process of submitting the RISC-V Linux port, and someone noticed >> that we were adding copies of some libgcc emulation

Re: Unify the various copies of libgcc into lib

On Wed, 24 May 2017 02:21:22 PDT (-0700), ge...@linux-m68k.org wrote: > Hi Palmer, > > On Wed, May 24, 2017 at 12:05 AM, Palmer Dabbelt wrote: >> I'm in the process of submitting the RISC-V Linux port, and someone noticed >> that we were adding copies of some libgcc emulation routines that were

[RFC PATCH v3 02/11] [media] vimc: Move common code from the core

Remove helper functions from vimc-core and add it in vimc-common to clean up the core. Signed-off-by: Helen Koike --- Changes in v3: [media] vimc: Move common code from the core - This is a new patch in the series Changes in v2: None ---

[RFC PATCH v3 02/11] [media] vimc: Move common code from the core

Remove helper functions from vimc-core and add it in vimc-common to clean up the core. Signed-off-by: Helen Koike --- Changes in v3: [media] vimc: Move common code from the core - This is a new patch in the series Changes in v2: None --- drivers/media/platform/vimc/Makefile

[RFC PATCH v3 01/11] [media] vimc: sen: Integrate the tpg on the sensor

Initialize the test pattern generator on the sensor Generate a colored bar image instead of a grey one Signed-off-by: Helen Koike --- Changes in v3: [media] vimc: sen: Integrate the tpg on the sensor - Declare frame_size as a local variable - Set tpg

[RFC PATCH v3 01/11] [media] vimc: sen: Integrate the tpg on the sensor

Initialize the test pattern generator on the sensor Generate a colored bar image instead of a grey one Signed-off-by: Helen Koike --- Changes in v3: [media] vimc: sen: Integrate the tpg on the sensor - Declare frame_size as a local variable - Set tpg frame format before

[RFC PATCH v3 06/11] [media] vimc: sen: Support several image formats

Allow user space to change the image format as the frame size, the media bus pixel format, colorspace, quantization, field YCbCr encoding and the transfer function Signed-off-by: Helen Koike --- Changes in v3: [media] vimc: sen: Support several image formats

[RFC PATCH v3 06/11] [media] vimc: sen: Support several image formats

Allow user space to change the image format as the frame size, the media bus pixel format, colorspace, quantization, field YCbCr encoding and the transfer function Signed-off-by: Helen Koike --- Changes in v3: [media] vimc: sen: Support several image formats - remove support for

[RFC PATCH v3 09/11] [media] vimc: Subdevices as modules

Change the core structure for adding subdevices in the topology. Instead of calling the specific create function for each subdevice, inject a child platform_device with the driver's name. Each type of node in the topology (sensor, capture, debayer, scaler) will register a platform_driver with the

[RFC PATCH v3 10/11] [media] vimc: deb: Add debayer filter

Implement the debayer filter and integrate it with the core Signed-off-by: Helen Koike --- Changes in v3: [media] vimc: deb: Add debayer filter - Declare frame_size as a local variable - s_stream(sd, 1): return 0 if stream is already enabled -

[RFC PATCH v3 10/11] [media] vimc: deb: Add debayer filter

Implement the debayer filter and integrate it with the core Signed-off-by: Helen Koike --- Changes in v3: [media] vimc: deb: Add debayer filter - Declare frame_size as a local variable - s_stream(sd, 1): return 0 if stream is already enabled - s_stream(sd, 0): return 0

[RFC PATCH v3 09/11] [media] vimc: Subdevices as modules

Change the core structure for adding subdevices in the topology. Instead of calling the specific create function for each subdevice, inject a child platform_device with the driver's name. Each type of node in the topology (sensor, capture, debayer, scaler) will register a platform_driver with the

[RFC PATCH v3 08/11] [media] vimc: Optimize frame generation through the pipe

Add a parameter called vsen_tpg, if true then vimc will work as before: frames will be generated in the sensor nodes then propagated through the pipe and processed by each node until a capture node is reached. If vsen_tpg is false, then the frame is not generated by the sensor, but directly from

[RFC PATCH v3 07/11] [media] vimc: cap: Support several image formats

Allow user space to change the image format as the frame size, the pixel format, colorspace, quantization, field YCbCr encoding and the transfer function Signed-off-by: Helen Koike --- Changes in v3: [media] vimc: cap: Support several image formats - use

[RFC PATCH v3 11/11] [media] vimc: sca: Add scaler

Implement scaler and integrated with the core Signed-off-by: Helen Koike --- Changes in v3: [media] vimc: sca: Add scaler - Declare frame_size as a local variable - s_stream(sd, 1): return 0 if stream is already enabled - s_stream(sd, 0):

[RFC PATCH v3 07/11] [media] vimc: cap: Support several image formats

Allow user space to change the image format as the frame size, the pixel format, colorspace, quantization, field YCbCr encoding and the transfer function Signed-off-by: Helen Koike --- Changes in v3: [media] vimc: cap: Support several image formats - use *_DEFAULT macros for

[RFC PATCH v3 11/11] [media] vimc: sca: Add scaler

Implement scaler and integrated with the core Signed-off-by: Helen Koike --- Changes in v3: [media] vimc: sca: Add scaler - Declare frame_size as a local variable - s_stream(sd, 1): return 0 if stream is already enabled - s_stream(sd, 0): return 0 if stream is already

[RFC PATCH v3 08/11] [media] vimc: Optimize frame generation through the pipe

Add a parameter called vsen_tpg, if true then vimc will work as before: frames will be generated in the sensor nodes then propagated through the pipe and processed by each node until a capture node is reached. If vsen_tpg is false, then the frame is not generated by the sensor, but directly from

[RFC PATCH v3 05/11] [media] vimc: common: Add vimc_link_validate

All links will be checked in the same way. Adding a helper function for that Signed-off-by: Helen Koike --- Changes in v3: [media] vimc: common: Add vimc_link_validate - this is a new patch in the series Changes in v2: None ---

[RFC PATCH v3 05/11] [media] vimc: common: Add vimc_link_validate

All links will be checked in the same way. Adding a helper function for that Signed-off-by: Helen Koike --- Changes in v3: [media] vimc: common: Add vimc_link_validate - this is a new patch in the series Changes in v2: None --- drivers/media/platform/vimc/vimc-capture.c | 78

Re: security/keys: add CONFIG_KEYS_COMPAT to Kconfig

On Wed, Mar 29, 2017 at 12:20:02PM -0700, Eric Biggers wrote: > On Thu, 9 Feb 2017 22:11:38 +0100, Bilal Amarni wrote: > > CONFIG_KEYS_COMPAT is defined in arch-specific Kconfigs and is missing for > > several 64-bit architectures : arm64, mips, parisc, tile. > > > > At the moment and for those

Re: security/keys: add CONFIG_KEYS_COMPAT to Kconfig

On Wed, Mar 29, 2017 at 12:20:02PM -0700, Eric Biggers wrote: > On Thu, 9 Feb 2017 22:11:38 +0100, Bilal Amarni wrote: > > CONFIG_KEYS_COMPAT is defined in arch-specific Kconfigs and is missing for > > several 64-bit architectures : arm64, mips, parisc, tile. > > > > At the moment and for those

[PATCH] staging: rtl8192e: all lines in dot11d.h are less than 80 chars long

This patch fixes the checkpoint.pl warning: WARNING: line over 80 characters Signed-off-by: Konrad Malkowski --- drivers/staging/rtl8192e/dot11d.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/rtl8192e/dot11d.h

[PATCH] staging: rtl8192e: all lines in dot11d.h are less than 80 chars long

This patch fixes the checkpoint.pl warning: WARNING: line over 80 characters Signed-off-by: Konrad Malkowski --- drivers/staging/rtl8192e/dot11d.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/rtl8192e/dot11d.h b/drivers/staging/rtl8192e/dot11d.h

[PATCH RFC 2/3] random: add get_random_{bytes,u32,u64,int,long}_wait family

These functions are simple convience wrappers that call wait_for_random_bytes before calling the respective get_random_* function. Signed-off-by: Jason A. Donenfeld --- include/linux/random.h | 30 ++ 1 file changed, 30 insertions(+) diff --git

[PATCH RFC 2/3] random: add get_random_{bytes,u32,u64,int,long}_wait family

These functions are simple convience wrappers that call wait_for_random_bytes before calling the respective get_random_* function. Signed-off-by: Jason A. Donenfeld --- include/linux/random.h | 30 ++ 1 file changed, 30 insertions(+) diff --git

[PATCH RFC 3/3] random: warn when kernel uses unseeded randomness

This enables an important dmesg notification about when drivers have used the crng without it being seeded first. Prior, these errors would occur silently, and so there hasn't been a great way of diagnosing these types of bugs for obscure setups. By adding this as a config option, we can leave it

[PATCH RFC 3/3] random: warn when kernel uses unseeded randomness

This enables an important dmesg notification about when drivers have used the crng without it being seeded first. Prior, these errors would occur silently, and so there hasn't been a great way of diagnosing these types of bugs for obscure setups. By adding this as a config option, we can leave it

[PATCH RFC 0/3] get_random_bytes seed blocking

Per the other thread on this mailing list, here's an initial stab at what we discussed -- adding a blocking API for the RNG, and adding a default-on dmesg Kconfig value for when things go wrong. Let me know what you think of this general implementation strategy, and if you like it, I'll move

[PATCH RFC 1/3] random: add synchronous API for the urandom pool

This enables users of get_random_{bytes,u32,u64,int,long} to wait until the pool is ready before using this function, in case they actually want to have reliable randomness. Signed-off-by: Jason A. Donenfeld --- drivers/char/random.c | 46

[PATCH RFC 0/3] get_random_bytes seed blocking

Per the other thread on this mailing list, here's an initial stab at what we discussed -- adding a blocking API for the RNG, and adding a default-on dmesg Kconfig value for when things go wrong. Let me know what you think of this general implementation strategy, and if you like it, I'll move

[PATCH RFC 1/3] random: add synchronous API for the urandom pool

This enables users of get_random_{bytes,u32,u64,int,long} to wait until the pool is ready before using this function, in case they actually want to have reliable randomness. Signed-off-by: Jason A. Donenfeld --- drivers/char/random.c | 46 --

Re: [PATCH] mm/vmalloc: a slight change of compare target in __insert_vmap_area()

On Fri, Jun 02, 2017 at 10:26:06AM +0800, zhong jiang wrote: >On 2017/6/2 9:45, Wei Yang wrote: >> On Fri, May 26, 2017 at 09:55:31AM +0800, zhong jiang wrote: >>> On 2017/5/26 9:36, Wei Yang wrote: On Thu, May 25, 2017 at 11:04:44AM +0800, zhong jiang wrote: > I hit the overlap issue,

Re: [PATCH] mm/vmalloc: a slight change of compare target in __insert_vmap_area()

On Fri, Jun 02, 2017 at 10:26:06AM +0800, zhong jiang wrote: >On 2017/6/2 9:45, Wei Yang wrote: >> On Fri, May 26, 2017 at 09:55:31AM +0800, zhong jiang wrote: >>> On 2017/5/26 9:36, Wei Yang wrote: On Thu, May 25, 2017 at 11:04:44AM +0800, zhong jiang wrote: > I hit the overlap issue,

Re: [RFC PATCH 2/4] mm, tree wide: replace __GFP_REPEAT by __GFP_RETRY_MAYFAIL with more useful semantic

Hi, Michal Just go through your patch. I have one question and one suggestion as below. One suggestion: This patch does two things to me: 1. Replace __GFP_REPEAT with __GFP_RETRY_MAYFAIL 2. Adjust the logic in page_alloc to provide the middle semantic My suggestion is to split these two task

Re: [RFC PATCH 2/4] mm, tree wide: replace __GFP_REPEAT by __GFP_RETRY_MAYFAIL with more useful semantic

Hi, Michal Just go through your patch. I have one question and one suggestion as below. One suggestion: This patch does two things to me: 1. Replace __GFP_REPEAT with __GFP_RETRY_MAYFAIL 2. Adjust the logic in page_alloc to provide the middle semantic My suggestion is to split these two task

Re: [PATCH 4/7] mips: Use lib/{ashldi3,ashrdi3,cmpdi2,lshrdi3,ucmpdi2}.c

On Wed, 24 May 2017 02:01:39 PDT (-0700), matt.redfe...@imgtec.com wrote: > Hi Palmer, > This patch doesn't quite match the subject, since it only removes the > mips specific implementation of __ucmpdi2. The following patch removes > all of the intrinsics that you added to lib/ from arch/mips/lib.

Re: [PATCH 4/7] mips: Use lib/{ashldi3,ashrdi3,cmpdi2,lshrdi3,ucmpdi2}.c

On Wed, 24 May 2017 02:01:39 PDT (-0700), matt.redfe...@imgtec.com wrote: > Hi Palmer, > This patch doesn't quite match the subject, since it only removes the > mips specific implementation of __ucmpdi2. The following patch removes > all of the intrinsics that you added to lib/ from arch/mips/lib.

  1   2   3   4   5   6   7   8   9   10   >