Re: IB/qib: Adjust two size determinations in qib_init_pportdata()

>> How do you think about to take another look at remaining update candidates >> at other source code places for this Linux module? > > You mean the other patches in this patch-set? Partly, yes. - Do you care for adjustments around numbered jump labels (and suggestions from the script

Re: IB/qib: Adjust two size determinations in qib_init_pportdata()

>> How do you think about to take another look at remaining update candidates >> at other source code places for this Linux module? > > You mean the other patches in this patch-set? Partly, yes. - Do you care for adjustments around numbered jump labels (and suggestions from the script

Re: [PATCH 00/16] Intel FPGA Device Drivers

On Thu, Mar 30, 2017 at 08:08:00PM +0800, Wu Hao wrote: > Hi All, > > Here is a patch-series adding drivers for Intel FPGA devices. > > The Intel FPGA driver provides interfaces for userspace applications to > configure, enumerate, open, and access FPGA accelerators on platforms > equipped with

Re: [PATCH 00/16] Intel FPGA Device Drivers

On Thu, Mar 30, 2017 at 08:08:00PM +0800, Wu Hao wrote: > Hi All, > > Here is a patch-series adding drivers for Intel FPGA devices. > > The Intel FPGA driver provides interfaces for userspace applications to > configure, enumerate, open, and access FPGA accelerators on platforms > equipped with

Re: [PATCH 11/24] uswsusp: Disable when the kernel is locked down

On Thu, 6 Apr 2017, Rafael J. Wysocki wrote: > >>> Your swap partition may be located on an NVDIMM or be encrypted. > >> > >> An NVDIMM should be considered the same as any other persistent storage. > >> > >> It may be encrypted, but where's the key stored, how easy is it to retrieve > >> and

Re: [PATCH 11/24] uswsusp: Disable when the kernel is locked down

On Thu, 6 Apr 2017, Rafael J. Wysocki wrote: > >>> Your swap partition may be located on an NVDIMM or be encrypted. > >> > >> An NVDIMM should be considered the same as any other persistent storage. > >> > >> It may be encrypted, but where's the key stored, how easy is it to retrieve > >> and

Re: [PATCH] qed: fix missing break in OOO_LB_TC case

From: Colin King Date: Wed, 5 Apr 2017 13:35:44 +0100 > From: Colin Ian King > > There seems to be a missing break on the OOO_LB_TC case, pq_id > is being assigned and then re-assigned on the fall through default > case and that seems

Re: [PATCH] qed: fix missing break in OOO_LB_TC case

From: Colin King Date: Wed, 5 Apr 2017 13:35:44 +0100 > From: Colin Ian King > > There seems to be a missing break on the OOO_LB_TC case, pq_id > is being assigned and then re-assigned on the fall through default > case and that seems suspect. > > Detected by CoverityScan, CID#1424402

Re: [PATCH 3/4] tracing: Add stack_tracer_disable/enable() functions

On Thu, Apr 06, 2017 at 02:48:03PM -0400, Steven Rostedt wrote: > On Thu, 6 Apr 2017 11:12:22 -0700 > "Paul E. McKenney" wrote: > > > On Thu, Apr 06, 2017 at 12:42:40PM -0400, Steven Rostedt wrote: > > > From: "Steven Rostedt (VMware)" > > > > >

Re: [PATCH 3/4] tracing: Add stack_tracer_disable/enable() functions

On Thu, Apr 06, 2017 at 02:48:03PM -0400, Steven Rostedt wrote: > On Thu, 6 Apr 2017 11:12:22 -0700 > "Paul E. McKenney" wrote: > > > On Thu, Apr 06, 2017 at 12:42:40PM -0400, Steven Rostedt wrote: > > > From: "Steven Rostedt (VMware)" > > > > > > There are certain parts of the kernel that can

[PATCH RFC 5/6] KVM: mark requests that do not need a wakeup

Some operations must ensure that the guest is not running with stale data, but if the guest is halted, then the update can wait until another event happens. kvm_make_all_requests() currently doesn't wake up, so we can mark all requests used with it. First 8 bits were arbitrarily reserved for

[PATCH RFC 5/6] KVM: mark requests that do not need a wakeup

Some operations must ensure that the guest is not running with stale data, but if the guest is halted, then the update can wait until another event happens. kvm_make_all_requests() currently doesn't wake up, so we can mark all requests used with it. First 8 bits were arbitrarily reserved for

[PATCH 3/6] KVM: x86: use kvm_make_request instead of set_bit

Signed-off-by: Radim Krčmář --- arch/x86/kvm/x86.c | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 71a019832df9..57e9989232e5 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -2229,8

[PATCH 4/6] KVM: remove #ifndef CONFIG_S390 around kvm_vcpu_wake_up

The #ifndef was protecting a missing halt_wakeup stat, but that is no longer necessary. Signed-off-by: Radim Krčmář --- virt/kvm/kvm_main.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 2389e9c41cd2..a486c6ad27a6 100644

[PATCH 3/6] KVM: x86: use kvm_make_request instead of set_bit

Signed-off-by: Radim Krčmář --- arch/x86/kvm/x86.c | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 71a019832df9..57e9989232e5 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -2229,8 +2229,7 @@ int

[PATCH 4/6] KVM: remove #ifndef CONFIG_S390 around kvm_vcpu_wake_up

The #ifndef was protecting a missing halt_wakeup stat, but that is no longer necessary. Signed-off-by: Radim Krčmář --- virt/kvm/kvm_main.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 2389e9c41cd2..a486c6ad27a6 100644 ---

[PATCH 6/6] KVM: perform a wake_up in kvm_make_all_cpus_request

We want to have kvm_make_all_cpus_request() to be an optmized version of kvm_for_each_vcpu(i, vcpu, kvm) { kvm_make_request(vcpu, request); kvm_vcpu_kick(vcpu); } and kvm_vcpu_kick() wakes up the target vcpu. We know which requests do not need the wake up and use it to optimize the

[PATCH 6/6] KVM: perform a wake_up in kvm_make_all_cpus_request

We want to have kvm_make_all_cpus_request() to be an optmized version of kvm_for_each_vcpu(i, vcpu, kvm) { kvm_make_request(vcpu, request); kvm_vcpu_kick(vcpu); } and kvm_vcpu_kick() wakes up the target vcpu. We know which requests do not need the wake up and use it to optimize the

[PATCH 2/6] KVM: use kvm_{test,clear}_request instead of {test,clear}_bit

Users were expected to use kvm_check_request() for testing and clearing, but request have expanded their use since then and some users want to only test or do a faster clear. Make sure that requests are not directly accessed with bit operations, because we'll be clearing them later.

[PATCH 2/6] KVM: use kvm_{test,clear}_request instead of {test,clear}_bit

Users were expected to use kvm_check_request() for testing and clearing, but request have expanded their use since then and some users want to only test or do a faster clear. Make sure that requests are not directly accessed with bit operations, because we'll be clearing them later.

[PATCH RFC 1/6] KVM: fix guest_mode optimization in kvm_make_all_cpus_request()

We have kvm_arch_vcpu_should_kick() to decide whether the target cpu needs to be kicked. The previous condition was wrong, because architectures that don't use vcpu->mode would not get interrupts and also suboptimal, because it sent IPI in cases where none was necessary. The situation is even

[PATCH RFC 1/6] KVM: fix guest_mode optimization in kvm_make_all_cpus_request()

We have kvm_arch_vcpu_should_kick() to decide whether the target cpu needs to be kicked. The previous condition was wrong, because architectures that don't use vcpu->mode would not get interrupts and also suboptimal, because it sent IPI in cases where none was necessary. The situation is even

[PATCH 0/6] KVM: towards maintainable kvm_make_all_cpus_request()

[1/6] makes a significant change for s390 and might be too dangerous because of that. I'm ok with returning 0 from s390's kvm_arch_vcpu_should_kick() until we sort out architecture-specific kicks. Adding kvm_vcpu_wake_up() in [6/6] is the reason why the other patches were included. Compile

[PATCH 0/6] KVM: towards maintainable kvm_make_all_cpus_request()

[1/6] makes a significant change for s390 and might be too dangerous because of that. I'm ok with returning 0 from s390's kvm_arch_vcpu_should_kick() until we sort out architecture-specific kicks. Adding kvm_vcpu_wake_up() in [6/6] is the reason why the other patches were included. Compile

Re: [PATCH 1/4] ftrace: Add use of synchronize_rcu_tasks() with dynamic trampolines

On Thu, Apr 06, 2017 at 02:13:29PM -0400, Steven Rostedt wrote: > On Thu, 6 Apr 2017 11:05:53 -0700 > "Paul E. McKenney" wrote: > > > On Thu, Apr 06, 2017 at 12:42:38PM -0400, Steven Rostedt wrote: > > > From: "Steven Rostedt (VMware)" > > > > >

Re: [PATCH 1/4] ftrace: Add use of synchronize_rcu_tasks() with dynamic trampolines

On Thu, Apr 06, 2017 at 02:13:29PM -0400, Steven Rostedt wrote: > On Thu, 6 Apr 2017 11:05:53 -0700 > "Paul E. McKenney" wrote: > > > On Thu, Apr 06, 2017 at 12:42:38PM -0400, Steven Rostedt wrote: > > > From: "Steven Rostedt (VMware)" > > > > > > The function tracer needs to be more careful

[patch] mm, swap_cgroup: reschedule when neeed in swap_cgroup_swapoff()

We got need_resched() warnings in swap_cgroup_swapoff() because swap_cgroup_ctrl[type].length is particularly large. Reschedule when needed. Signed-off-by: David Rientjes --- mm/swap_cgroup.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mm/swap_cgroup.c

[patch] mm, swap_cgroup: reschedule when neeed in swap_cgroup_swapoff()

We got need_resched() warnings in swap_cgroup_swapoff() because swap_cgroup_ctrl[type].length is particularly large. Reschedule when needed. Signed-off-by: David Rientjes --- mm/swap_cgroup.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mm/swap_cgroup.c b/mm/swap_cgroup.c ---

Re: [PATCH 11/24] uswsusp: Disable when the kernel is locked down

On Thu, Apr 6, 2017 at 10:09 PM, Rafael J. Wysocki wrote: > On Thu, Apr 6, 2017 at 10:41 AM, David Howells wrote: >> Oliver Neukum wrote: >> >>> Your swap partition may be located on an NVDIMM or be encrypted. >> >> An NVDIMM should be

Re: [PATCH 11/24] uswsusp: Disable when the kernel is locked down

On Thu, Apr 6, 2017 at 10:09 PM, Rafael J. Wysocki wrote: > On Thu, Apr 6, 2017 at 10:41 AM, David Howells wrote: >> Oliver Neukum wrote: >> >>> Your swap partition may be located on an NVDIMM or be encrypted. >> >> An NVDIMM should be considered the same as any other persistent storage. >> >>

[PATCH 2/2] IB/usnic: Use kcalloc() in usnic_vnic_alloc_res_chunk()

From: Markus Elfring Date: Thu, 6 Apr 2017 21:45:33 +0200 A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus use the corresponding function "kcalloc". This issue was detected by using

[PATCH 2/2] IB/usnic: Use kcalloc() in usnic_vnic_alloc_res_chunk()

From: Markus Elfring Date: Thu, 6 Apr 2017 21:45:33 +0200 A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus use the corresponding function "kcalloc". This issue was detected by using the Coccinelle software.

[PATCH 1/2] IB/usnic: Use kcalloc() in alloc_res_chunk_list()

From: Markus Elfring Date: Thu, 6 Apr 2017 20:32:39 +0200 A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus use the corresponding function "kcalloc". This issue was detected by using

[PATCH 1/2] IB/usnic: Use kcalloc() in alloc_res_chunk_list()

From: Markus Elfring Date: Thu, 6 Apr 2017 20:32:39 +0200 A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus use the corresponding function "kcalloc". This issue was detected by using the Coccinelle software.

Re: [PATCH 11/24] uswsusp: Disable when the kernel is locked down

On Thu, Apr 6, 2017 at 10:41 AM, David Howells wrote: > Oliver Neukum wrote: > >> Your swap partition may be located on an NVDIMM or be encrypted. > > An NVDIMM should be considered the same as any other persistent storage. > > It may be encrypted, but

Re: [PATCH 11/24] uswsusp: Disable when the kernel is locked down

On Thu, Apr 6, 2017 at 10:41 AM, David Howells wrote: > Oliver Neukum wrote: > >> Your swap partition may be located on an NVDIMM or be encrypted. > > An NVDIMM should be considered the same as any other persistent storage. > > It may be encrypted, but where's the key stored, how easy is it to

Re: [PATCH v3 07/12] clk: mediatek: add clk support for MT6797

On 03/19, Mars Cheng wrote: > From: Kevin-CW Chen > > Add MT6797 clock support, include topckgen, apmixedsys, infracfg > and subsystem clocks > > Signed-off-by: Kevin-CW Chen > Signed-off-by: Mars Cheng >

Re: [PATCH v3 07/12] clk: mediatek: add clk support for MT6797

On 03/19, Mars Cheng wrote: > From: Kevin-CW Chen > > Add MT6797 clock support, include topckgen, apmixedsys, infracfg > and subsystem clocks > > Signed-off-by: Kevin-CW Chen > Signed-off-by: Mars Cheng > Tested-by: Matthias Brugger Acked-by: Stephen Boyd Looks fine to me except for the

[PATCH 0/2] IB/usnic: Fine-tuning for two function implementations

From: Markus Elfring Date: Thu, 6 Apr 2017 22:00:10 +0200 A few update suggestions were taken into account from static source code analysis. Markus Elfring (2): Use kcalloc() in alloc_res_chunk_list() Use kcalloc() in usnic_vnic_alloc_res_chunk()

[PATCH 0/2] IB/usnic: Fine-tuning for two function implementations

From: Markus Elfring Date: Thu, 6 Apr 2017 22:00:10 +0200 A few update suggestions were taken into account from static source code analysis. Markus Elfring (2): Use kcalloc() in alloc_res_chunk_list() Use kcalloc() in usnic_vnic_alloc_res_chunk()

[PATCH] phy: qcom-qmp: Add dependency on COMMON_CLK

The driver uses clock provider interface, and therefore it fails to build when enabled for COMPILE_TEST, since COMMON_CLK is not enabled at that time. So, make PHY_QCOM_QMP depend on COMMON_CLK as well. Cc: Fengguang Wu Cc: Kishon Vijay Abraham I

[PATCH] phy: qcom-qmp: Add dependency on COMMON_CLK

The driver uses clock provider interface, and therefore it fails to build when enabled for COMPILE_TEST, since COMMON_CLK is not enabled at that time. So, make PHY_QCOM_QMP depend on COMMON_CLK as well. Cc: Fengguang Wu Cc: Kishon Vijay Abraham I Signed-off-by: Vivek Gautam --- Hi Kishon,

Re: [PATCH 11/24] uswsusp: Disable when the kernel is locked down

On Thu, Apr 6, 2017 at 8:55 AM, David Howells wrote: > Rafael J. Wysocki wrote: > >> You probably want to disable hibernation altogether in this case. > > See patch 10. Does that mean patch 11 is superfluous? Yes, it does. You can't open /dev/snapshot

Re: [PATCH 11/24] uswsusp: Disable when the kernel is locked down

On Thu, Apr 6, 2017 at 8:55 AM, David Howells wrote: > Rafael J. Wysocki wrote: > >> You probably want to disable hibernation altogether in this case. > > See patch 10. Does that mean patch 11 is superfluous? Yes, it does. You can't open /dev/snapshot if hibernation_available() returns false.

Re: [RFC PATCH 0/4] fs: introduce new writeback error tracking infrastructure and convert ext4 to use it

On Thu, Apr 06, 2017 at 03:14:52PM -0400, Jeff Layton wrote: > @@ -868,6 +869,7 @@ struct file { > struct list_headf_tfile_llink; > #endif /* #ifdef CONFIG_EPOLL */ > struct address_space*f_mapping; > + u32 f_wb_err; > }

Re: [RFC PATCH 0/4] fs: introduce new writeback error tracking infrastructure and convert ext4 to use it

On Thu, Apr 06, 2017 at 03:14:52PM -0400, Jeff Layton wrote: > @@ -868,6 +869,7 @@ struct file { > struct list_headf_tfile_llink; > #endif /* #ifdef CONFIG_EPOLL */ > struct address_space*f_mapping; > + u32 f_wb_err; > }

Re: [PATCH v4 2/2] i2c: mux: ltc4306: LTC4306 and LTC4305 I2C multiplexer/switch

On 2017-04-06 13:31, Michael Hennerich wrote: > On 06.04.2017 10:39, Peter Rosin wrote: >> Hi Michael, >> >> I would still like to hear from someone with more gpio experience. > > I'll ping Linus. > >> >> Anyway, from my point of view, there's just a few minor things left, >> with comments

Re: [PATCH v4 2/2] i2c: mux: ltc4306: LTC4306 and LTC4305 I2C multiplexer/switch

On 2017-04-06 13:31, Michael Hennerich wrote: > On 06.04.2017 10:39, Peter Rosin wrote: >> Hi Michael, >> >> I would still like to hear from someone with more gpio experience. > > I'll ping Linus. > >> >> Anyway, from my point of view, there's just a few minor things left, >> with comments

Re: [PATCH net-next] net/mlx5e: fix build error without CONFIG_SYSFS

From: Tobias Regnery Date: Wed, 5 Apr 2017 11:11:10 +0200 > Commit 9008ae074885 ("net/mlx5e: Minimize mlx5e_{open/close}_locked") > copied the calls to netif_set_real_num_{tx,rx}_queues from > mlx5e_open_locked to mlx5e_activate_priv_channels and wraps them in an > if

Re: [PATCH net-next] net/mlx5e: fix build error without CONFIG_SYSFS

From: Tobias Regnery Date: Wed, 5 Apr 2017 11:11:10 +0200 > Commit 9008ae074885 ("net/mlx5e: Minimize mlx5e_{open/close}_locked") > copied the calls to netif_set_real_num_{tx,rx}_queues from > mlx5e_open_locked to mlx5e_activate_priv_channels and wraps them in an > if condition to test for

Re: [PATCH] of: Make of_match_node() an inline stub for CONFIG_OF=n

On Thu, Apr 06, 2017 at 12:32:24PM -0700, Florian Fainelli wrote: > Make of_match_node() an inline function when CONFIG_OF=n which allows the > compiler to eliminate warnings about unused variables. > > Suggested-by: Andrew Lunn > Signed-off-by: Florian Fainelli

Re: [PATCH] of: Make of_match_node() an inline stub for CONFIG_OF=n

On Thu, Apr 06, 2017 at 12:32:24PM -0700, Florian Fainelli wrote: > Make of_match_node() an inline function when CONFIG_OF=n which allows the > compiler to eliminate warnings about unused variables. > > Suggested-by: Andrew Lunn > Signed-off-by: Florian Fainelli Thanks Florian, Reviewed-by:

Re: [PATCH net-next v2] net: dsa: mv88e6xxx: Make SMI c22/c45 read/write functions static

Hi Florian, Florian Fainelli writes: > The SMI clause 22 & 45 read/write operations are local to the global2.c file, > so make them static. This eliminates the following warning: > > drivers/net/dsa/mv88e6xxx/global2.c:571:5: warning: no previous prototype for >

Re: [PATCH net-next v2] net: dsa: mv88e6xxx: Make SMI c22/c45 read/write functions static

Hi Florian, Florian Fainelli writes: > The SMI clause 22 & 45 read/write operations are local to the global2.c file, > so make them static. This eliminates the following warning: > > drivers/net/dsa/mv88e6xxx/global2.c:571:5: warning: no previous prototype for > 'mv88e6xxx_g2_smi_phy_read_c45'

Re: IB/qib: Adjust two size determinations in qib_init_pportdata()

On Wed, Apr 05, 2017 at 05:21:22PM +0200, SF Markus Elfring wrote: > > I found that the fix brings no harm to the existing code. > > How do you think about to take another look at remaining update candidates > at other source code places for this Linux module? You mean the other patches in this

Re: IB/qib: Adjust two size determinations in qib_init_pportdata()

On Wed, Apr 05, 2017 at 05:21:22PM +0200, SF Markus Elfring wrote: > > I found that the fix brings no harm to the existing code. > > How do you think about to take another look at remaining update candidates > at other source code places for this Linux module? You mean the other patches in this

Re: [PATCH 17/24] acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down

On Wed, Apr 5, 2017 at 10:16 PM, David Howells wrote: > From: Josh Boyer > > This option allows userspace to pass the RSDP address to the kernel, which > makes it possible for a user to circumvent any restrictions imposed on > loading modules. Ignore the

Re: [PATCH 17/24] acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down

On Wed, Apr 5, 2017 at 10:16 PM, David Howells wrote: > From: Josh Boyer > > This option allows userspace to pass the RSDP address to the kernel, which > makes it possible for a user to circumvent any restrictions imposed on > loading modules. Ignore the option when the kernel is locked down.

Re: [PATCH] af_unix: Use designated initializers

From: Kees Cook Date: Tue, 4 Apr 2017 22:12:09 -0700 > Prepare to mark sensitive kernel structures for randomization by making > sure they're using designated initializers. These were identified during > allyesconfig builds of x86, arm, and arm64, and the initializer fixes

Re: [PATCH] af_unix: Use designated initializers

From: Kees Cook Date: Tue, 4 Apr 2017 22:12:09 -0700 > Prepare to mark sensitive kernel structures for randomization by making > sure they're using designated initializers. These were identified during > allyesconfig builds of x86, arm, and arm64, and the initializer fixes > were extracted from

[PATCH net-next v2] net: dsa: mv88e6xxx: Make SMI c22/c45 read/write functions static

The SMI clause 22 & 45 read/write operations are local to the global2.c file, so make them static. This eliminates the following warning: drivers/net/dsa/mv88e6xxx/global2.c:571:5: warning: no previous prototype for 'mv88e6xxx_g2_smi_phy_read_c45' [-Wmissing-prototypes] int

[PATCH net-next v2] net: dsa: mv88e6xxx: Make SMI c22/c45 read/write functions static

The SMI clause 22 & 45 read/write operations are local to the global2.c file, so make them static. This eliminates the following warning: drivers/net/dsa/mv88e6xxx/global2.c:571:5: warning: no previous prototype for 'mv88e6xxx_g2_smi_phy_read_c45' [-Wmissing-prototypes] int

Re: [RFC][PATCH] spin loop arch primitives for busy waiting

On Thu, Apr 6, 2017 at 12:23 PM, Peter Zijlstra wrote: > > Something like so then. According to the SDM mwait is a no-op if we do > not execute monitor first. So this variant should get the first > iteration without expensive instructions. No, the problem is that we *would*

Re: [RFC][PATCH] spin loop arch primitives for busy waiting

On Thu, Apr 6, 2017 at 12:23 PM, Peter Zijlstra wrote: > > Something like so then. According to the SDM mwait is a no-op if we do > not execute monitor first. So this variant should get the first > iteration without expensive instructions. No, the problem is that we *would* have executed a prior

Re: [PATCH V2 04/16] block, bfq: modify the peak-rate estimator

> Il giorno 04 apr 2017, alle ore 17:28, Bart Van Assche > ha scritto: > > On Tue, 2017-04-04 at 12:42 +0200, Paolo Valente wrote: >>> Il giorno 31 mar 2017, alle ore 17:31, Bart Van Assche >>> ha scritto: >>> >>> On Fri, 2017-03-31 at

Re: [PATCH V2 04/16] block, bfq: modify the peak-rate estimator

> Il giorno 04 apr 2017, alle ore 17:28, Bart Van Assche > ha scritto: > > On Tue, 2017-04-04 at 12:42 +0200, Paolo Valente wrote: >>> Il giorno 31 mar 2017, alle ore 17:31, Bart Van Assche >>> ha scritto: >>> >>> On Fri, 2017-03-31 at 14:47 +0200, Paolo Valente wrote: +

Re: [PATCH] misc: sram-exec: Use aligned fncpy instead of memcpy

On 04/06/2017 02:29 PM, Russell King - ARM Linux wrote: On Thu, Apr 06, 2017 at 02:14:12PM -0500, Dave Gerlach wrote: On 04/06/2017 02:07 PM, Russell King - ARM Linux wrote: On Wed, Apr 05, 2017 at 02:22:33PM -0500, Dave Gerlach wrote: Russell, On 04/05/2017 02:21 PM, Dave Gerlach wrote:

Re: [PATCH] misc: sram-exec: Use aligned fncpy instead of memcpy

On 04/06/2017 02:29 PM, Russell King - ARM Linux wrote: On Thu, Apr 06, 2017 at 02:14:12PM -0500, Dave Gerlach wrote: On 04/06/2017 02:07 PM, Russell King - ARM Linux wrote: On Wed, Apr 05, 2017 at 02:22:33PM -0500, Dave Gerlach wrote: Russell, On 04/05/2017 02:21 PM, Dave Gerlach wrote:

Re: [PATCH v2] net: netfilter: Remove multiple assignment.

Hi Arushi, On Tue, Mar 28, 2017 at 04:03:27AM +0530, Arushi Singhal wrote: > This patch removes multiple assignments to follow the kernel coding > style as also reported by checkpatch.pl. > Done using coccinelle. > @@ > identifier i1,i2; > constant c; > @@ > - i1=i2=c; > + i1=c; > + i2=i1; I see

Re: [PATCH v2] net: netfilter: Remove multiple assignment.

Hi Arushi, On Tue, Mar 28, 2017 at 04:03:27AM +0530, Arushi Singhal wrote: > This patch removes multiple assignments to follow the kernel coding > style as also reported by checkpatch.pl. > Done using coccinelle. > @@ > identifier i1,i2; > constant c; > @@ > - i1=i2=c; > + i1=c; > + i2=i1; I see

Re: [PATCH V10 06/12] of: device: Fix overflow of coherent_dma_mask

On 04/06/17 04:01, Sricharan R wrote: > Hi Frank, > > On 4/6/2017 12:31 PM, Frank Rowand wrote: >> On 04/04/17 03:18, Sricharan R wrote: >>> Size of the dma-range is calculated as coherent_dma_mask + 1 >>> and passed to arch_setup_dma_ops further. It overflows when >>> the coherent_dma_mask is

Re: [PATCH V10 06/12] of: device: Fix overflow of coherent_dma_mask

On 04/06/17 04:01, Sricharan R wrote: > Hi Frank, > > On 4/6/2017 12:31 PM, Frank Rowand wrote: >> On 04/04/17 03:18, Sricharan R wrote: >>> Size of the dma-range is calculated as coherent_dma_mask + 1 >>> and passed to arch_setup_dma_ops further. It overflows when >>> the coherent_dma_mask is

Re: [PATCH v2] vfio/type1: Remove locked page accounting workqueue

On Thu, 6 Apr 2017 11:05:31 -0600 Alex Williamson wrote: > On Thu, 6 Apr 2017 18:53:04 +0200 > Auger Eric wrote: > > > Hi Alex, > > > > On 06/04/2017 16:53, Alex Williamson wrote: > > > If the mmap_sem is contented then the vfio type1 IOMMU

[PATCH] of: Make of_match_node() an inline stub for CONFIG_OF=n

Make of_match_node() an inline function when CONFIG_OF=n which allows the compiler to eliminate warnings about unused variables. Suggested-by: Andrew Lunn Signed-off-by: Florian Fainelli --- include/linux/of.h | 6 +- 1 file changed, 5 insertions(+), 1

Re: [PATCH v2] vfio/type1: Remove locked page accounting workqueue

On Thu, 6 Apr 2017 11:05:31 -0600 Alex Williamson wrote: > On Thu, 6 Apr 2017 18:53:04 +0200 > Auger Eric wrote: > > > Hi Alex, > > > > On 06/04/2017 16:53, Alex Williamson wrote: > > > If the mmap_sem is contented then the vfio type1 IOMMU backend will > > > defer locked page accounting

[PATCH] of: Make of_match_node() an inline stub for CONFIG_OF=n

Make of_match_node() an inline function when CONFIG_OF=n which allows the compiler to eliminate warnings about unused variables. Suggested-by: Andrew Lunn Signed-off-by: Florian Fainelli --- include/linux/of.h | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git

[PATCH] [media] media-entity: only call dev_dbg_obj if mdev is not NULL

Fix kernel Oops NULL pointer deference Call dev_dbg_obj only after checking if gobj->mdev is not NULL Signed-off-by: Helen Koike --- drivers/media/media-entity.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/media-entity.c

[PATCH] [media] media-entity: only call dev_dbg_obj if mdev is not NULL

Fix kernel Oops NULL pointer deference Call dev_dbg_obj only after checking if gobj->mdev is not NULL Signed-off-by: Helen Koike --- drivers/media/media-entity.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c

Re: [PATCH] misc: sram-exec: Use aligned fncpy instead of memcpy

On Thu, Apr 06, 2017 at 02:14:12PM -0500, Dave Gerlach wrote: > On 04/06/2017 02:07 PM, Russell King - ARM Linux wrote: > >On Wed, Apr 05, 2017 at 02:22:33PM -0500, Dave Gerlach wrote: > >>Russell, > >>On 04/05/2017 02:21 PM, Dave Gerlach wrote: > >>>Currently the sram-exec functionality, which

Re: [PATCH] misc: sram-exec: Use aligned fncpy instead of memcpy

On Thu, Apr 06, 2017 at 02:14:12PM -0500, Dave Gerlach wrote: > On 04/06/2017 02:07 PM, Russell King - ARM Linux wrote: > >On Wed, Apr 05, 2017 at 02:22:33PM -0500, Dave Gerlach wrote: > >>Russell, > >>On 04/05/2017 02:21 PM, Dave Gerlach wrote: > >>>Currently the sram-exec functionality, which

Re: [PATCH 11/16] fpga: intel: fme: add partial reconfiguration sub feature support

On Thu, Apr 6, 2017 at 5:57 AM, Wu Hao wrote: > On Wed, Apr 05, 2017 at 10:39:05AM -0500, Alan Tull wrote: >> On Wed, Apr 5, 2017 at 10:26 AM, Alan Tull wrote: >> > On Wed, Apr 5, 2017 at 6:40 AM, Wu, Hao wrote: >> >>> >> The

Re: [PATCH 11/16] fpga: intel: fme: add partial reconfiguration sub feature support

On Thu, Apr 6, 2017 at 5:57 AM, Wu Hao wrote: > On Wed, Apr 05, 2017 at 10:39:05AM -0500, Alan Tull wrote: >> On Wed, Apr 5, 2017 at 10:26 AM, Alan Tull wrote: >> > On Wed, Apr 5, 2017 at 6:40 AM, Wu, Hao wrote: >> >>> >> The fpga_image_info struct started life as just image specific info, >>

Re: [PATCH net-next] net: usbnet: Remove unused driver_name variable

From: Florian Fainelli Date: Tue, 4 Apr 2017 18:16:57 -0700 > With GCC 6.3, we can get the following warning: > > drivers/net/usb/usbnet.c:85:19: warning: 'driver_name' defined but not > used [-Wunused-const-variable=] > static const char driver_name [] = "usbnet"; >

Re: [PATCH net-next] net: usbnet: Remove unused driver_name variable

From: Florian Fainelli Date: Tue, 4 Apr 2017 18:16:57 -0700 > With GCC 6.3, we can get the following warning: > > drivers/net/usb/usbnet.c:85:19: warning: 'driver_name' defined but not > used [-Wunused-const-variable=] > static const char driver_name [] = "usbnet"; >

Re: [PATCH] mac80211: Fix clang warning about constant operand in logical operation

Hi Johannes, thanks for your comments El Thu, Apr 06, 2017 at 09:11:18PM +0200 Johannes Berg ha dit: > On Thu, 2017-04-06 at 11:56 -0700, Matthias Kaehlcke wrote: > > Clang raises a warning about the expression 'strlen(CONFIG_XXX)' > > being > > used in a logical operation. Clangs' builtin

Re: [PATCH] mac80211: Fix clang warning about constant operand in logical operation

Hi Johannes, thanks for your comments El Thu, Apr 06, 2017 at 09:11:18PM +0200 Johannes Berg ha dit: > On Thu, 2017-04-06 at 11:56 -0700, Matthias Kaehlcke wrote: > > Clang raises a warning about the expression 'strlen(CONFIG_XXX)' > > being > > used in a logical operation. Clangs' builtin

Re: [PATCH V10 06/12] of: device: Fix overflow of coherent_dma_mask

On 04/06/17 03:24, Robin Murphy wrote: > On 06/04/17 08:01, Frank Rowand wrote: >> On 04/04/17 03:18, Sricharan R wrote: >>> Size of the dma-range is calculated as coherent_dma_mask + 1 >>> and passed to arch_setup_dma_ops further. It overflows when >>> the coherent_dma_mask is set for full 64

Re: [PATCH V10 06/12] of: device: Fix overflow of coherent_dma_mask

On 04/06/17 03:24, Robin Murphy wrote: > On 06/04/17 08:01, Frank Rowand wrote: >> On 04/04/17 03:18, Sricharan R wrote: >>> Size of the dma-range is calculated as coherent_dma_mask + 1 >>> and passed to arch_setup_dma_ops further. It overflows when >>> the coherent_dma_mask is set for full 64

Re: [RFC][PATCH] spin loop arch primitives for busy waiting

On Thu, Apr 06, 2017 at 10:31:46AM -0700, Linus Torvalds wrote: > And we'd probably want to make it even more strict, in that soem mwait > implementations might simply not be very good for short waits. Yeah, we need to find something that works; assuming its beneficial at all on modern chips. >

Re: [RFC][PATCH] spin loop arch primitives for busy waiting

On Thu, Apr 06, 2017 at 10:31:46AM -0700, Linus Torvalds wrote: > And we'd probably want to make it even more strict, in that soem mwait > implementations might simply not be very good for short waits. Yeah, we need to find something that works; assuming its beneficial at all on modern chips. >

Re: [PATCH] fs: Handle register_shrinker failure

On 03/24/2017 02:55 AM, Nikolay Borisov wrote: > register_shrinker allocates dynamic memory and thus is susceptible to failures > under low-memory situation. Currently,get_userns ignores the return value of > register_shrinker, potentially exposing not fully initialised object. This > can lead

Re: [PATCH] fs: Handle register_shrinker failure

On 03/24/2017 02:55 AM, Nikolay Borisov wrote: > register_shrinker allocates dynamic memory and thus is susceptible to failures > under low-memory situation. Currently,get_userns ignores the return value of > register_shrinker, potentially exposing not fully initialised object. This > can lead

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

On Thu, Apr 06, 2017 at 07:58:57PM +0100, Sean Young wrote: > On Thu, Apr 06, 2017 at 01:34:20PM +1000, Stephen Rothwell wrote: > > Hi all, > > > > Today's linux-next merge of the staging tree got conflicts in: > > > > drivers/staging/media/lirc/lirc_sasem.c > >

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

On Thu, Apr 06, 2017 at 07:58:57PM +0100, Sean Young wrote: > On Thu, Apr 06, 2017 at 01:34:20PM +1000, Stephen Rothwell wrote: > > Hi all, > > > > Today's linux-next merge of the staging tree got conflicts in: > > > > drivers/staging/media/lirc/lirc_sasem.c > >

Re: [PATCH 8/8] x86/mm: Allow to have userspace mappings above 47-bits

On 04/06/2017 09:43 PM, Dmitry Safonov wrote: Hi Kirill, On 04/06/2017 05:01 PM, Kirill A. Shutemov wrote: On x86, 5-level paging enables 56-bit userspace virtual address space. Not all user space is ready to handle wide addresses. It's known that at least some JIT compilers use higher bits in

Re: [PATCH 8/8] x86/mm: Allow to have userspace mappings above 47-bits

On 04/06/2017 09:43 PM, Dmitry Safonov wrote: Hi Kirill, On 04/06/2017 05:01 PM, Kirill A. Shutemov wrote: On x86, 5-level paging enables 56-bit userspace virtual address space. Not all user space is ready to handle wide addresses. It's known that at least some JIT compilers use higher bits in

Re: [RFC PATCH 0/4] fs: introduce new writeback error tracking infrastructure and convert ext4 to use it

On Thu, 2017-04-06 at 10:02 +1000, NeilBrown wrote: > > > On Thu, Apr 06 2017, Jeff Layton wrote: > > > On Tue, 2017-04-04 at 10:09 -0700, Matthew Wilcox wrote: > > > On Tue, Apr 04, 2017 at 12:25:46PM -0400, Jeff Layton wrote: > > > > That said, I think giving more specific errors where we can

Re: [PATCH] misc: sram-exec: Use aligned fncpy instead of memcpy

On 04/06/2017 02:07 PM, Russell King - ARM Linux wrote: On Wed, Apr 05, 2017 at 02:22:33PM -0500, Dave Gerlach wrote: Russell, On 04/05/2017 02:21 PM, Dave Gerlach wrote: Currently the sram-exec functionality, which allows allocation of executable memory and provides an API to move code to it,

Re: [PATCH] misc: sram-exec: Use aligned fncpy instead of memcpy

On 04/06/2017 02:07 PM, Russell King - ARM Linux wrote: On Wed, Apr 05, 2017 at 02:22:33PM -0500, Dave Gerlach wrote: Russell, On 04/05/2017 02:21 PM, Dave Gerlach wrote: Currently the sram-exec functionality, which allows allocation of executable memory and provides an API to move code to it,

Re: [RFC PATCH 0/4] fs: introduce new writeback error tracking infrastructure and convert ext4 to use it

On Thu, 2017-04-06 at 10:02 +1000, NeilBrown wrote: > > > On Thu, Apr 06 2017, Jeff Layton wrote: > > > On Tue, 2017-04-04 at 10:09 -0700, Matthew Wilcox wrote: > > > On Tue, Apr 04, 2017 at 12:25:46PM -0400, Jeff Layton wrote: > > > > That said, I think giving more specific errors where we can

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