Re: [PATCH 5/9] apm32: remove paravirt_enabled() use

On Fri, Feb 19, 2016 at 10:08:43AM -0500, Boris Ostrovsky wrote: > > > On 02/19/2016 08:08 AM, Luis R. Rodriguez wrote: > >There is already a check for apm_info.bios == 0, the > >apm_info.bios is set from the boot_params.apm_bios_info. > >Both Xen and lguest, which are also the only ones that

Re: [PATCH 5/9] apm32: remove paravirt_enabled() use

On Fri, Feb 19, 2016 at 10:08:43AM -0500, Boris Ostrovsky wrote: > > > On 02/19/2016 08:08 AM, Luis R. Rodriguez wrote: > >There is already a check for apm_info.bios == 0, the > >apm_info.bios is set from the boot_params.apm_bios_info. > >Both Xen and lguest, which are also the only ones that

Re: [PATCH v2 1/3] net: ti: netcp: restore get/set_pad_info() functionality

On Friday 19 February 2016 12:58:42 Murali Karicheri wrote: > The commit 899077791403 ("netcp: try to reduce type confusion in > descriptors") introduces a regression in Kernel 4.5-rc1 and it breaks > get/set_pad_info() functionality. > > The TI NETCP driver uses pad0 and pad1 fields of

Re: [PATCH v2 1/3] net: ti: netcp: restore get/set_pad_info() functionality

On Friday 19 February 2016 12:58:42 Murali Karicheri wrote: > The commit 899077791403 ("netcp: try to reduce type confusion in > descriptors") introduces a regression in Kernel 4.5-rc1 and it breaks > get/set_pad_info() functionality. > > The TI NETCP driver uses pad0 and pad1 fields of

Re: [PATCH 1/1] ser_gigaset: use container_of() instead of detour

From: Paul Bolle Date: Thu, 18 Feb 2016 21:29:08 +0100 > The purpose of gigaset_device_release() is to kfree() the struct > ser_cardstate that contains our struct device. This is done via a bit of > a detour. First we make our struct device's driver_data point to the >

Re: [PATCH 1/1] ser_gigaset: use container_of() instead of detour

From: Paul Bolle Date: Thu, 18 Feb 2016 21:29:08 +0100 > The purpose of gigaset_device_release() is to kfree() the struct > ser_cardstate that contains our struct device. This is done via a bit of > a detour. First we make our struct device's driver_data point to the > container of our struct

Re: [PATCH v2 3/3] net: netcp: rework the code for get/set sw_data in dma desc

On Friday 19 February 2016 12:58:44 Murali Karicheri wrote: > SW data field in descriptor can be used by software to hold private > data for the driver. As there are 4 words available for this purpose, > use separate macros to place it or retrieve the same to/from > descriptors. Also do type cast

Re: [PATCH v2 3/3] net: netcp: rework the code for get/set sw_data in dma desc

On Friday 19 February 2016 12:58:44 Murali Karicheri wrote: > SW data field in descriptor can be used by software to hold private > data for the driver. As there are 4 words available for this purpose, > use separate macros to place it or retrieve the same to/from > descriptors. Also do type cast

Re: [PATCH v2 2/3] soc: ti: knav_dma: rename pad in struct knav_dma_desc to sw_data

On Friday 19 February 2016 12:58:43 Murali Karicheri wrote: > Rename the pad to sw_data as per description of this field in the hardware > spec(refer sprugr9 from www.ti.com). Latest version of the document is > at http://www.ti.com/lit/ug/sprugr9h/sprugr9h.pdf and section 3.1 > Host Packet

Re: [PATCH v2 2/3] soc: ti: knav_dma: rename pad in struct knav_dma_desc to sw_data

On Friday 19 February 2016 12:58:43 Murali Karicheri wrote: > Rename the pad to sw_data as per description of this field in the hardware > spec(refer sprugr9 from www.ti.com). Latest version of the document is > at http://www.ti.com/lit/ug/sprugr9h/sprugr9h.pdf and section 3.1 > Host Packet

Re: [PATCH block/for-4.5-fixes] writeback: keep superblock pinned during cgroup writeback association switches

Hello, Al. On Fri, Feb 19, 2016 at 08:18:06PM +, Al Viro wrote: > On Thu, Feb 18, 2016 at 08:00:33AM -0500, Tejun Heo wrote: > > So, the question is why aren't we just using s_active and draining it > > on umount of the last mountpoint. Because, right now, the behavior is > > weird in that

Re: [PATCH block/for-4.5-fixes] writeback: keep superblock pinned during cgroup writeback association switches

Hello, Al. On Fri, Feb 19, 2016 at 08:18:06PM +, Al Viro wrote: > On Thu, Feb 18, 2016 at 08:00:33AM -0500, Tejun Heo wrote: > > So, the question is why aren't we just using s_active and draining it > > on umount of the last mountpoint. Because, right now, the behavior is > > weird in that

Re: pull-request: wireless-drivers 2016-02-18

From: Kalle Valo Date: Thu, 18 Feb 2016 17:28:14 +0200 > I have some important fixes I would like to get 4.5 still, more info in > the signed tag. Please let me know if you have problems. Pulled, thanks.

Re: pull-request: wireless-drivers 2016-02-18

From: Kalle Valo Date: Thu, 18 Feb 2016 17:28:14 +0200 > I have some important fixes I would like to get 4.5 still, more info in > the signed tag. Please let me know if you have problems. Pulled, thanks.

Re: [PATCH V2] i2c: i801: Intel DNV_N device IDs SMBus

On Thu, Feb 18, 2016 at 01:21:13PM +0100, Wolfram Sang wrote: > On Wed, Feb 17, 2016 at 06:23:48PM -0800, Alexandra Yates wrote: > > Adding Intel codename DNV_N platform device IDs for SMBus. > > > > Signed-off-by: Alexandra Yates > > Applied to for-current,

Re: [PATCH V2] i2c: i801: Intel DNV_N device IDs SMBus

On Thu, Feb 18, 2016 at 01:21:13PM +0100, Wolfram Sang wrote: > On Wed, Feb 17, 2016 at 06:23:48PM -0800, Alexandra Yates wrote: > > Adding Intel codename DNV_N platform device IDs for SMBus. > > > > Signed-off-by: Alexandra Yates > > Applied to for-current, thanks! Note: As stated elsewhere,

Re: [PATCH net-next] hv_netvsc: add software transmit timestamp support

From: Simon Xiao Date: Wed, 17 Feb 2016 16:43:59 -0800 > Enable skb_tx_timestamp in hyperv netvsc. > > Signed-off-by: Simon Xiao > Reviewed-by: K. Y. Srinivasan > Reviewed-by: Haiyang Zhang Applied.

Re: [PATCH net-next] hv_netvsc: add software transmit timestamp support

From: Simon Xiao Date: Wed, 17 Feb 2016 16:43:59 -0800 > Enable skb_tx_timestamp in hyperv netvsc. > > Signed-off-by: Simon Xiao > Reviewed-by: K. Y. Srinivasan > Reviewed-by: Haiyang Zhang Applied.

Re: [PATCH v6 0/3] mailbox: Add APM X-Gene platform mailbox driver

On Fri, Feb 12, 2016 at 7:39 PM, Duc Dang wrote: > APM X-Gene SoC has a mailbox controller that provides > communication mechanism for X-Gene Arm64 cores to communicate > with X-Gene SoC's Cortex M3 (SLIMpro) processor. > > X-Gene mailbox controller provides 8 mailbox channels,

Re: [PATCH v6 0/3] mailbox: Add APM X-Gene platform mailbox driver

On Fri, Feb 12, 2016 at 7:39 PM, Duc Dang wrote: > APM X-Gene SoC has a mailbox controller that provides > communication mechanism for X-Gene Arm64 cores to communicate > with X-Gene SoC's Cortex M3 (SLIMpro) processor. > > X-Gene mailbox controller provides 8 mailbox channels, with > each

Re: [PATCH] tipc: unlock in error path

From: Insu Yun Date: Wed, 17 Feb 2016 11:47:35 -0500 > tipc_bcast_unlock need to be unlocked in error path. > > Signed-off-by: Insu Yun Applied.

Re: [PATCH] tipc: unlock in error path

From: Insu Yun Date: Wed, 17 Feb 2016 11:47:35 -0500 > tipc_bcast_unlock need to be unlocked in error path. > > Signed-off-by: Insu Yun Applied.

[PATCH v4 2/2] powercap/rapl: reduce ipi calls

Reduce remote CPU calls for MSR access by combining read modify write into one function. Also optimize calling active CPU on package by tracking a lead cpu for each package. Suggested-by: Peter Zijlstra Signed-off-by: Jacob Pan ---

[PATCH v4 1/2] cpumask: export cpumask_any_but

Export cpumask_any_but() for module use. This will be used by drivers such as intel_rapl to locate an active cpu on a socket. Signed-off-by: Jacob Pan --- lib/cpumask.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/cpumask.c b/lib/cpumask.c index

[PATCH v4 2/2] powercap/rapl: reduce ipi calls

Reduce remote CPU calls for MSR access by combining read modify write into one function. Also optimize calling active CPU on package by tracking a lead cpu for each package. Suggested-by: Peter Zijlstra Signed-off-by: Jacob Pan --- drivers/powercap/intel_rapl.c | 224

[PATCH v4 1/2] cpumask: export cpumask_any_but

Export cpumask_any_but() for module use. This will be used by drivers such as intel_rapl to locate an active cpu on a socket. Signed-off-by: Jacob Pan --- lib/cpumask.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/cpumask.c b/lib/cpumask.c index 5a70f61..81dedaa 100644 ---

[PATCH v4 0/2] powercap/rapl: reduce ipi calls and misc clean up

Changes since V3: - Avoid for_each_online_cpu() search for per package MSR access. This is achieved by tracking a per package lead cpu via cpumask_xx() calls. (suggested by Thomas Gleixner ) - Add direct reference of RAPL package for each

[PATCH v4 0/2] powercap/rapl: reduce ipi calls and misc clean up

Changes since V3: - Avoid for_each_online_cpu() search for per package MSR access. This is achieved by tracking a per package lead cpu via cpumask_xx() calls. (suggested by Thomas Gleixner ) - Add direct reference of RAPL package for each RAPL domain. This

Re: [RFC v2 2/7] tables.h: add linker table support

On 02/19/2016 05:45 AM, Luis R. Rodriguez wrote: > +/** > + * LINKTABLE_RUN_ERR - run each linker table entry func and return error if > any > + * > + * @tbl: linker table > + * @func: structure name for the function name we want to call. > + * @args...: arguments to pass to func > + * > + *

Re: [RFC v2 2/7] tables.h: add linker table support

On 02/19/2016 05:45 AM, Luis R. Rodriguez wrote: > +/** > + * LINKTABLE_RUN_ERR - run each linker table entry func and return error if > any > + * > + * @tbl: linker table > + * @func: structure name for the function name we want to call. > + * @args...: arguments to pass to func > + * > + *

Re: [RFC v2 4/7] asm/sections: add a generic push_section_tbl()

On 02/19/2016 05:45 AM, Luis R. Rodriguez wrote: > With a generic linker tables solution in place we > need a general asm solution for declaring entries > with asm. The first easy target is to cover the C > asm declarations, guard the header file for now > and define a first generic entry

Re: [RFC v2 4/7] asm/sections: add a generic push_section_tbl()

On 02/19/2016 05:45 AM, Luis R. Rodriguez wrote: > With a generic linker tables solution in place we > need a general asm solution for declaring entries > with asm. The first easy target is to cover the C > asm declarations, guard the header file for now > and define a first generic entry

Re: [PATCH] rtnl: RTM_GETNETCONF: fix wrong return value

From: Anton Protopopov Date: Tue, 16 Feb 2016 21:43:16 -0500 > An error response from a RTM_GETNETCONF request can return the positive > error value EINVAL in the struct nlmsgerr that can mislead userspace. > > Signed-off-by: Anton Protopopov

Re: [PATCH] rtnl: RTM_GETNETCONF: fix wrong return value

From: Anton Protopopov Date: Tue, 16 Feb 2016 21:43:16 -0500 > An error response from a RTM_GETNETCONF request can return the positive > error value EINVAL in the struct nlmsgerr that can mislead userspace. > > Signed-off-by: Anton Protopopov Applied and queued up for -stable, thanks.

Re: [PATCH net-next,V2] net: macb: make magic-packet property generic

From: Sergio Prado Date: Tue, 16 Feb 2016 21:10:45 -0200 > As requested by Rob Herring on patch > https://patchwork.ozlabs.org/patch/580862/. > > This is a new property that it's still in net-next and has never been > used in production, so we are not breaking

Re: [PATCH net-next,V2] net: macb: make magic-packet property generic

From: Sergio Prado Date: Tue, 16 Feb 2016 21:10:45 -0200 > As requested by Rob Herring on patch > https://patchwork.ozlabs.org/patch/580862/. > > This is a new property that it's still in net-next and has never been > used in production, so we are not breaking anything with the > incompatible

RE: [RFC PATCH 9/9] iio: imu: inv_mpu6050: Fix deadlock between i2c adapter lock and mpu lock

"there was one comment before that power off will cause the the bypass i2c lines to disable for some MPU chips which this driver can support." This is right. I remember there was some code about it earlier trying to take advantage of the secondary bus without enabling the MPU chip itself. This

RE: [RFC PATCH 9/9] iio: imu: inv_mpu6050: Fix deadlock between i2c adapter lock and mpu lock

"there was one comment before that power off will cause the the bypass i2c lines to disable for some MPU chips which this driver can support." This is right. I remember there was some code about it earlier trying to take advantage of the secondary bus without enabling the MPU chip itself. This

Re: [RFC v2 2/7] tables.h: add linker table support

On 02/19/2016 05:45 AM, Luis R. Rodriguez wrote: > + > +/** > + * DOC: Regular linker linker table constructors > + * > + * Regular constructors are expected to be used for valid linker table > entries. > + * Valid uses of weak entries other than the beginning and is currently > + * untested but

Re: [RFC v2 2/7] tables.h: add linker table support

On 02/19/2016 05:45 AM, Luis R. Rodriguez wrote: > + > +/** > + * DOC: Regular linker linker table constructors > + * > + * Regular constructors are expected to be used for valid linker table > entries. > + * Valid uses of weak entries other than the beginning and is currently > + * untested but

Re: [RFC v2 0/7] linux: add linker tables

On 02/19/2016 05:45 AM, Luis R. Rodriguez wrote: > This is my v2 of the original linker table work [0], now with > six proof of concepts ports of existing code using custom section > with custom linker script modifications: > > * DEFINE_LINKTABLE_TEXT(char, kprobes); > *

Re: [PATCH] mm: scale kswapd watermarks in proportion to memory

On Fri, Feb 19, 2016 at 11:25:43AM +, Mel Gorman wrote: > On Thu, Feb 18, 2016 at 11:41:59AM -0500, Johannes Weiner wrote: > > In machines with 140G of memory and enterprise flash storage, we have > > seen read and write bursts routinely exceed the kswapd watermarks and > > cause thundering

Re: [RFC v2 0/7] linux: add linker tables

On 02/19/2016 05:45 AM, Luis R. Rodriguez wrote: > This is my v2 of the original linker table work [0], now with > six proof of concepts ports of existing code using custom section > with custom linker script modifications: > > * DEFINE_LINKTABLE_TEXT(char, kprobes); > *

Re: [PATCH] mm: scale kswapd watermarks in proportion to memory

On Fri, Feb 19, 2016 at 11:25:43AM +, Mel Gorman wrote: > On Thu, Feb 18, 2016 at 11:41:59AM -0500, Johannes Weiner wrote: > > In machines with 140G of memory and enterprise flash storage, we have > > seen read and write bursts routinely exceed the kswapd watermarks and > > cause thundering

Re: About support XZ-compressed kernel on x86

On 2016-02-18 Baoquan He wrote: > OK. I still don't understand below snippet taken from misc.c. As you > said overwriting happened when the write position quickly approaches > the read position. how could it happpen if the input pointer is moving > faster than the output pointer? > > > * The

Re: About support XZ-compressed kernel on x86

On 2016-02-18 Baoquan He wrote: > OK. I still don't understand below snippet taken from misc.c. As you > said overwriting happened when the write position quickly approaches > the read position. how could it happpen if the input pointer is moving > faster than the output pointer? > > > * The

[PATCH] Documentation: update the devices.txt documentation

Alan is no longer maintaining this list through the Linux assigned numbers authority. Make it a collective document by referring to "the maintainers" in plural throughout, and naming the chardev and block layer maintainers in particular as parties of involvement. Cut down and remove some sections

[PATCH] Documentation: update the devices.txt documentation

Alan is no longer maintaining this list through the Linux assigned numbers authority. Make it a collective document by referring to "the maintainers" in plural throughout, and naming the chardev and block layer maintainers in particular as parties of involvement. Cut down and remove some sections

Re: [PATCH block/for-4.5-fixes] writeback: keep superblock pinned during cgroup writeback association switches

On Thu, Feb 18, 2016 at 08:00:33AM -0500, Tejun Heo wrote: > So, the question is why aren't we just using s_active and draining it > on umount of the last mountpoint. Because, right now, the behavior is > weird in that we allow umounts to proceed but then let the superblock > hang onto the block

Re: [PATCH block/for-4.5-fixes] writeback: keep superblock pinned during cgroup writeback association switches

On Thu, Feb 18, 2016 at 08:00:33AM -0500, Tejun Heo wrote: > So, the question is why aren't we just using s_active and draining it > on umount of the last mountpoint. Because, right now, the behavior is > weird in that we allow umounts to proceed but then let the superblock > hang onto the block

Re: [PATCH v7 2/3] clk: clk-pic32: Add PIC32 clock driver

Quoting Joshua Henderson (2016-02-19 08:25:35) > +const struct clk_ops pic32_roclk_ops = { > + .enable = roclk_enable, > + .disable= roclk_disable, > + .is_enabled = roclk_is_enabled, > + .get_parent =

Re: [PATCH v7 2/3] clk: clk-pic32: Add PIC32 clock driver

Quoting Joshua Henderson (2016-02-19 08:25:35) > +const struct clk_ops pic32_roclk_ops = { > + .enable = roclk_enable, > + .disable= roclk_disable, > + .is_enabled = roclk_is_enabled, > + .get_parent =

[PATCH][RESEND] fdinfo: handle large fdinfo buffers

Currently the way we deal with special fdinfo information is with the fop->show_fdinfo, which seq_printf's and carries on. This works in 99% of the cases, but for things like inotify/fanotify we can have lots of stuff that we want to print out, so we can easily overflow the seq buffer and result

[PATCH][RESEND] fdinfo: handle large fdinfo buffers

Currently the way we deal with special fdinfo information is with the fop->show_fdinfo, which seq_printf's and carries on. This works in 99% of the cases, but for things like inotify/fanotify we can have lots of stuff that we want to print out, so we can easily overflow the seq buffer and result

[GIT PULL] ext4 bug fixes for 4.5

The following changes since commit 36f90b0a2ddd60823fe193a85e60ff1906c2a9b3: Linux 4.5-rc2 (2016-01-31 18:12:16 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git tags/ext4_for_linus_stable for you to fetch changes up to

[GIT PULL] ext4 bug fixes for 4.5

The following changes since commit 36f90b0a2ddd60823fe193a85e60ff1906c2a9b3: Linux 4.5-rc2 (2016-01-31 18:12:16 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git tags/ext4_for_linus_stable for you to fetch changes up to

Re: [PATCH v2] staging/android/ion : fix a race condition in the ion driver

On 02/19/2016 04:03 AM, EunTaik Lee wrote: > There is a use-after-free problem in the ion driver. > This is caused by a race condition in the ion_ioctl() > function. > > A handle has ref count of 1 and two tasks on different > cpus calls ION_IOC_FREE simultaneously. > > cpu 0

Re: [PATCH v2] staging/android/ion : fix a race condition in the ion driver

On 02/19/2016 04:03 AM, EunTaik Lee wrote: > There is a use-after-free problem in the ion driver. > This is caused by a race condition in the ion_ioctl() > function. > > A handle has ref count of 1 and two tasks on different > cpus calls ION_IOC_FREE simultaneously. > > cpu 0

Re: [RFC v2 1/7] sections.h: add sections header to collect all section info

On Fri, Feb 19, 2016 at 08:23:29AM -0800, Greg KH wrote: > On Fri, Feb 19, 2016 at 05:45:53AM -0800, Luis R. Rodriguez wrote: > > Linux makes extensive use of custom ELF header sections, > > documentation for these are well scatterred. Unify this > > documentation in a central place. > > Minor

Re: [RFC v2 1/7] sections.h: add sections header to collect all section info

On Fri, Feb 19, 2016 at 08:23:29AM -0800, Greg KH wrote: > On Fri, Feb 19, 2016 at 05:45:53AM -0800, Luis R. Rodriguez wrote: > > Linux makes extensive use of custom ELF header sections, > > documentation for these are well scatterred. Unify this > > documentation in a central place. > > Minor

[Patch] media: ti-vpe: cal: Fix warning: variable dereference before being checked

As reported ctx->sensor is being dereferenced before being checked in cal_get_external_info(). That being the case it was also checked twice in multiple other location where v4l2_subdev_call is already checking it so no need to explicitly check it again. Reported-by: Dan Carpenter

[Patch] media: ti-vpe: cal: Fix warning: variable dereference before being checked

As reported ctx->sensor is being dereferenced before being checked in cal_get_external_info(). That being the case it was also checked twice in multiple other location where v4l2_subdev_call is already checking it so no need to explicitly check it again. Reported-by: Dan Carpenter Signed-off-by:

Re: [PATCH 1/2] chrdev: emit a warning when we go below dynamic major range

On Fri, Feb 19, 2016 at 5:06 PM, Alan Cox wrote: >> Alan: is your list at LANANA even maintained? It seems wildly >> out of sync with what's in the kernel. Maybe time to patch out >> some of the text in devices.txt directing people over there? > > Someone took my access to

Re: [PATCH 1/2] chrdev: emit a warning when we go below dynamic major range

On Fri, Feb 19, 2016 at 5:06 PM, Alan Cox wrote: >> Alan: is your list at LANANA even maintained? It seems wildly >> out of sync with what's in the kernel. Maybe time to patch out >> some of the text in devices.txt directing people over there? > > Someone took my access to update the database

Re: [PATCH] Create sysfs entries for PCI VPDI and VPDR tags

>On 02/19/2016 03:07 PM, Jordan Hargrave wrote: >> On Fri, Feb 19, 2016 at 4:00 AM, Hannes Reinecke wrote: >>> >>> On 02/18/2016 09:04 PM, Jordan Hargrave wrote: The VPD-R is a readonly area of the PCI Vital Product Data region. There are some standard keywords for serial

Re: [PATCH] Create sysfs entries for PCI VPDI and VPDR tags

>On 02/19/2016 03:07 PM, Jordan Hargrave wrote: >> On Fri, Feb 19, 2016 at 4:00 AM, Hannes Reinecke wrote: >>> >>> On 02/18/2016 09:04 PM, Jordan Hargrave wrote: The VPD-R is a readonly area of the PCI Vital Product Data region. There are some standard keywords for serial number,

Re: [PATCH] mm: scale kswapd watermarks in proportion to memory

On Thu, Feb 18, 2016 at 03:15:43PM -0500, Rik van Riel wrote: > On Thu, 2016-02-18 at 11:41 -0500, Johannes Weiner wrote: > > In machines with 140G of memory and enterprise flash storage, we have > > seen read and write bursts routinely exceed the kswapd watermarks and > > cause thundering herds

Re: [PATCH] mm: scale kswapd watermarks in proportion to memory

On Thu, Feb 18, 2016 at 03:15:43PM -0500, Rik van Riel wrote: > On Thu, 2016-02-18 at 11:41 -0500, Johannes Weiner wrote: > > In machines with 140G of memory and enterprise flash storage, we have > > seen read and write bursts routinely exceed the kswapd watermarks and > > cause thundering herds

Re: [PATCH v2] bpf: grab rcu read lock for bpf_percpu_hash_update

From: Sasha Levin Date: Fri, 19 Feb 2016 13:53:10 -0500 > bpf_percpu_hash_update() expects rcu lock to be held and warns if it's not, > which pointed out a missing rcu read lock. > > Fixes: 15a07b338 ("bpf: add lookup/update support for per-cpu hash and array > maps") >

Re: [PATCH v2] bpf: grab rcu read lock for bpf_percpu_hash_update

From: Sasha Levin Date: Fri, 19 Feb 2016 13:53:10 -0500 > bpf_percpu_hash_update() expects rcu lock to be held and warns if it's not, > which pointed out a missing rcu read lock. > > Fixes: 15a07b338 ("bpf: add lookup/update support for per-cpu hash and array > maps") > Signed-off-by: Sasha

Re: [PATCH v13 08/29] tracing: Add lock-free tracing_map

On Thu, 10 Dec 2015 12:50:50 -0600 Tom Zanussi wrote: > diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig > index e45db6b..48b7329 100644 > --- a/kernel/trace/Kconfig > +++ b/kernel/trace/Kconfig > @@ -528,6 +528,19 @@ config MMIOTRACE > See

Re: [PATCH v13 08/29] tracing: Add lock-free tracing_map

On Thu, 10 Dec 2015 12:50:50 -0600 Tom Zanussi wrote: > diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig > index e45db6b..48b7329 100644 > --- a/kernel/trace/Kconfig > +++ b/kernel/trace/Kconfig > @@ -528,6 +528,19 @@ config MMIOTRACE > See Documentation/trace/mmiotrace.txt. >

Re: fs: NULL deref in atime_needs_update

On Wed, Feb 17, 2016 at 12:40 AM, Mickaël Salaün wrote: > Hi, > > Actually I found the same bug (without fuzzing) and I can reproduce it in a > deterministic way (e.g. by creating a LSM that return 1 for the > security_file_open hook). At least, from v4.2.8 I can easily

Re: fs: NULL deref in atime_needs_update

On Wed, Feb 17, 2016 at 12:40 AM, Mickaël Salaün wrote: > Hi, > > Actually I found the same bug (without fuzzing) and I can reproduce it in a > deterministic way (e.g. by creating a LSM that return 1 for the > security_file_open hook). At least, from v4.2.8 I can easily trigger traces > like

Re: [PATCH v13 06/29] tracing: Add needs_rec flag to event triggers

On Thu, 10 Dec 2015 12:50:48 -0600 Tom Zanussi wrote: > Add a new needs_rec flag for triggers that require unconditional > access to trace records in order to function. > > Normally a trigger requires access to the contents of a trace record > only if it has a

Re: [PATCH v13 06/29] tracing: Add needs_rec flag to event triggers

On Thu, 10 Dec 2015 12:50:48 -0600 Tom Zanussi wrote: > Add a new needs_rec flag for triggers that require unconditional > access to trace records in order to function. > > Normally a trigger requires access to the contents of a trace record > only if it has a filter associated with it (since

Re: [PATCHv2] serial: samsung: drop the spinlock around uart_write_wakeup

[ +cc Krzysztof Kozlowski ] On 02/18/2016 09:15 PM, Anand Moon wrote: > From: Anand Moon > > drop the spin_unlock/lock around uart_write_wakeup to protect > write wakeup for uart port. What Krzysztof was saying wrt v1 of this patch is that the changelog should provide as

Re: [PATCHv2] serial: samsung: drop the spinlock around uart_write_wakeup

[ +cc Krzysztof Kozlowski ] On 02/18/2016 09:15 PM, Anand Moon wrote: > From: Anand Moon > > drop the spin_unlock/lock around uart_write_wakeup to protect > write wakeup for uart port. What Krzysztof was saying wrt v1 of this patch is that the changelog should provide as much information as

[Patch] media: ti-vpe: cal: Fix unreachable code in enum_frame_interval

As reported, the current cal_enum_frameintervals() is confusing and does not have the intended behavior. Fix this by re-implementing to properly propagate the enum_frame_interval request to the subdevice. Reported-by: Dan Carpenter Reported-by: Mauro Carvalho Chehab

[Patch] media: ti-vpe: cal: Fix unreachable code in enum_frame_interval

As reported, the current cal_enum_frameintervals() is confusing and does not have the intended behavior. Fix this by re-implementing to properly propagate the enum_frame_interval request to the subdevice. Reported-by: Dan Carpenter Reported-by: Mauro Carvalho Chehab Signed-off-by: Benoit Parrot

Re: [Patch v6 3/3] media: ti-vpe: Add CAL v4l2 camera capture driver

Mauro, Thanks for the proposed fix. But I decided to fix it in a different way. I'll send a patch shortly. Regards, Benoit Mauro Carvalho Chehab wrote on Fri [2016-Feb-19 14:54:23 -0200]: > Em Wed, 6 Jan 2016 17:37:26 -0600 > Benoit Parrot escreveu: >

Re: [Patch v6 3/3] media: ti-vpe: Add CAL v4l2 camera capture driver

Mauro, Thanks for the proposed fix. But I decided to fix it in a different way. I'll send a patch shortly. Regards, Benoit Mauro Carvalho Chehab wrote on Fri [2016-Feb-19 14:54:23 -0200]: > Em Wed, 6 Jan 2016 17:37:26 -0600 > Benoit Parrot escreveu: > > > The Camera Adaptation Layer (CAL)

[PATCH net] Driver: Vmxnet3: Update Rx ring 2 max size

Device emulation supports max size of 4096. Signed-off-by: Shrikrishna Khare Signed-off-by: Bhavesh Davda --- drivers/net/vmxnet3/vmxnet3_defs.h | 2 +- drivers/net/vmxnet3/vmxnet3_int.h | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff

[PATCH net] Driver: Vmxnet3: Update Rx ring 2 max size

Device emulation supports max size of 4096. Signed-off-by: Shrikrishna Khare Signed-off-by: Bhavesh Davda --- drivers/net/vmxnet3/vmxnet3_defs.h | 2 +- drivers/net/vmxnet3/vmxnet3_int.h | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git

Re: [PATCH 0/3] LightNVM patches for next 4.5-rc

On Fri, Feb 19 2016, Matias Bjørling wrote: > Hi Jens, > > Here is a couple of patches for the next 4.5-rc. > > A patch from Alan that fixes up logic in nvm_configure_get. Another > patch from Javier that fixes a bug with multiple luns in RRPC, and at > last a patch from me that fixes the get

Re: [PATCH 0/3] LightNVM patches for next 4.5-rc

On Fri, Feb 19 2016, Matias Bjørling wrote: > Hi Jens, > > Here is a couple of patches for the next 4.5-rc. > > A patch from Alan that fixes up logic in nvm_configure_get. Another > patch from Javier that fixes a bug with multiple luns in RRPC, and at > last a patch from me that fixes the get

Re: [PATCHv2] lkdtm: Add READ_AFTER_FREE test

On Thu, Feb 18, 2016 at 5:15 PM, Laura Abbott wrote: > > In a similar manner to WRITE_AFTER_FREE, add a READ_AFTER_FREE > test to test free poisoning features. Sample output when > no sanitization is present: > > [ 22.414170] lkdtm: Performing direct entry

Re: [PATCHv2] lkdtm: Add READ_AFTER_FREE test

On Thu, Feb 18, 2016 at 5:15 PM, Laura Abbott wrote: > > In a similar manner to WRITE_AFTER_FREE, add a READ_AFTER_FREE > test to test free poisoning features. Sample output when > no sanitization is present: > > [ 22.414170] lkdtm: Performing direct entry READ_AFTER_FREE > [ 22.415124]

[GIT PULL] Btrfs

Hi Linus, My for-linus-4.5 branch has a btrfs DIO error passing fix. I know how much you love DIO, so I'm going to suggest against reading it. We'll follow up with a patch to drop the error arg from dio_end_io in the next merge window.

[GIT PULL] Btrfs

Hi Linus, My for-linus-4.5 branch has a btrfs DIO error passing fix. I know how much you love DIO, so I'm going to suggest against reading it. We'll follow up with a patch to drop the error arg from dio_end_io in the next merge window.

Re: linux-next: Tree for Feb 19 (rapidio: rio_mport_cdev.c)

On 02/18/16 20:49, Stephen Rothwell wrote: > Hi all, > > Changes since 20160218: > on x86_64 (for the past 3 days or so): when CONFIG_DMA_ENGINE is not enabled: ../drivers/rapidio/devices/rio_mport_cdev.c: In function 'mport_cdev_open': ../drivers/rapidio/devices/rio_mport_cdev.c:1938:22:

Re: linux-next: Tree for Feb 19 (rapidio: rio_mport_cdev.c)

On 02/18/16 20:49, Stephen Rothwell wrote: > Hi all, > > Changes since 20160218: > on x86_64 (for the past 3 days or so): when CONFIG_DMA_ENGINE is not enabled: ../drivers/rapidio/devices/rio_mport_cdev.c: In function 'mport_cdev_open': ../drivers/rapidio/devices/rio_mport_cdev.c:1938:22:

Re: [PATCH v2] bpf: grab rcu read lock for bpf_percpu_hash_update

On 02/19/2016 07:53 PM, Sasha Levin wrote: bpf_percpu_hash_update() expects rcu lock to be held and warns if it's not, which pointed out a missing rcu read lock. Fixes: 15a07b338 ("bpf: add lookup/update support for per-cpu hash and array maps") Signed-off-by: Sasha Levin

Re: [PATCH v2] bpf: grab rcu read lock for bpf_percpu_hash_update

On 02/19/2016 07:53 PM, Sasha Levin wrote: bpf_percpu_hash_update() expects rcu lock to be held and warns if it's not, which pointed out a missing rcu read lock. Fixes: 15a07b338 ("bpf: add lookup/update support for per-cpu hash and array maps") Signed-off-by: Sasha Levin LGTM, patch is

Re: [PATCH v2] bpf: grab rcu read lock for bpf_percpu_hash_update

On Fri, Feb 19, 2016 at 01:53:10PM -0500, Sasha Levin wrote: > bpf_percpu_hash_update() expects rcu lock to be held and warns if it's not, > which pointed out a missing rcu read lock. > > Fixes: 15a07b338 ("bpf: add lookup/update support for per-cpu hash and array > maps") > Signed-off-by: Sasha

Re: [PATCH v2] bpf: grab rcu read lock for bpf_percpu_hash_update

On Fri, Feb 19, 2016 at 01:53:10PM -0500, Sasha Levin wrote: > bpf_percpu_hash_update() expects rcu lock to be held and warns if it's not, > which pointed out a missing rcu read lock. > > Fixes: 15a07b338 ("bpf: add lookup/update support for per-cpu hash and array > maps") > Signed-off-by: Sasha

Re: [PATCH v2 1/2] ARM: dts: am43x-epos-evm: Add the am438 compatible string

* Keerthy [160218 20:39]: > The SoCs on am43x-epos-evm are named am438x. > Hence add the compatibility string and remove the am4372 string. Applying into omap-for-v4.6/dt thanks. Tony

Re: [PATCH v2 1/2] ARM: dts: am43x-epos-evm: Add the am438 compatible string

* Keerthy [160218 20:39]: > The SoCs on am43x-epos-evm are named am438x. > Hence add the compatibility string and remove the am4372 string. Applying into omap-for-v4.6/dt thanks. Tony

[PATCH v2] bpf: grab rcu read lock for bpf_percpu_hash_update

bpf_percpu_hash_update() expects rcu lock to be held and warns if it's not, which pointed out a missing rcu read lock. Fixes: 15a07b338 ("bpf: add lookup/update support for per-cpu hash and array maps") Signed-off-by: Sasha Levin --- kernel/bpf/hashtab.c |8 +++-

[PATCH v2] bpf: grab rcu read lock for bpf_percpu_hash_update

bpf_percpu_hash_update() expects rcu lock to be held and warns if it's not, which pointed out a missing rcu read lock. Fixes: 15a07b338 ("bpf: add lookup/update support for per-cpu hash and array maps") Signed-off-by: Sasha Levin --- kernel/bpf/hashtab.c |8 +++- 1 file changed, 7

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