[PATCH] staging: comedi: ni_mio_common: fix wrong insn_write handler

For counter subdevices, the `s->insn_write` handler is being set to the wrong function, `ni_tio_insn_read()`. It should be `ni_tio_insn_write()`. Signed-off-by: Ian Abbott Reported-by: Éric Piel Fixes: 10f74377eec3 ("staging: comedi: ni_tio: make

[PATCH net-next 3/3] net: dsa: mv88e6xxx: kill last locked reg_read

Get rid of the last usage of the locked mv88e6xxx_reg_read function with a new mv88e6xxx_port_read helper, useful later for chips with different port registers base address. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx/chip.c | 35

Re: [PATCH 03/10] coresight: etm-perf: configuring filters from perf core

On 18/07/16 20:51, Mathieu Poirier wrote: This patch implements the required API needed to access and retrieve range and start/stop filters from the perf core. Signed-off-by: Mathieu Poirier --- drivers/hwtracing/coresight/coresight-etm-perf.c | 146

Re: [PATCH] staging: comedi: ni_mio_common: fix AO inttrig backwards compatibility

On 20/07/16 16:55, Hartley Sweeten wrote: On Tuesday, July 19, 2016 4:18 AM, Ian Abbott wrote: Commit ebb657babfa9 ("staging: comedi: ni_mio_common: clarify the cmd->start_arg validation and use") introduced a backwards compatibility issue in the use of asynchronous commands on the AO subdevice

[PATCH net-next 2/3] net: dsa: mv88e6xxx: rework EEPROM access

The 6352 family of switches and compatibles provide a 8-bit address and 16-bit data access to an optional EEPROM. Newer chip such as the 6390 family slightly changed the access to 16-bit address and 8-bit data. This commit cleans up the EEPROM access code for 16-bit access and makes it easy to

[PATCH] staging: comedi: ni_mio_common: fix wrong insn_write handler

For counter subdevices, the `s->insn_write` handler is being set to the wrong function, `ni_tio_insn_read()`. It should be `ni_tio_insn_write()`. Signed-off-by: Ian Abbott Reported-by: Éric Piel Fixes: 10f74377eec3 ("staging: comedi: ni_tio: make ni_tio_winsn() a proper comedi (*insn_write)"

[PATCH net-next 3/3] net: dsa: mv88e6xxx: kill last locked reg_read

Get rid of the last usage of the locked mv88e6xxx_reg_read function with a new mv88e6xxx_port_read helper, useful later for chips with different port registers base address. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx/chip.c | 35 +++ 1 file

Re: [PATCH 03/10] coresight: etm-perf: configuring filters from perf core

On 18/07/16 20:51, Mathieu Poirier wrote: This patch implements the required API needed to access and retrieve range and start/stop filters from the perf core. Signed-off-by: Mathieu Poirier --- drivers/hwtracing/coresight/coresight-etm-perf.c | 146 ---

Re: [PATCH] staging: comedi: ni_mio_common: fix AO inttrig backwards compatibility

On 20/07/16 16:55, Hartley Sweeten wrote: On Tuesday, July 19, 2016 4:18 AM, Ian Abbott wrote: Commit ebb657babfa9 ("staging: comedi: ni_mio_common: clarify the cmd->start_arg validation and use") introduced a backwards compatibility issue in the use of asynchronous commands on the AO subdevice

[PATCH net-next 2/3] net: dsa: mv88e6xxx: rework EEPROM access

The 6352 family of switches and compatibles provide a 8-bit address and 16-bit data access to an optional EEPROM. Newer chip such as the 6390 family slightly changed the access to 16-bit address and 8-bit data. This commit cleans up the EEPROM access code for 16-bit access and makes it easy to

[PATCH v2] [media] vb2: include lengths in dmabuf qbuf debug message

If the VIDIOC_QBUF ioctl fails due a wrong dmabuf length, it's useful to get the invalid and minimum lengths as a debug info. Before this patch: vb2-core: __qbuf_dmabuf: invalid dmabuf length for plane 1 After this patch: vb2-core: __qbuf_dmabuf: invalid dmabuf length 221248 for plane 1,

[PATCH v2] [media] vb2: include lengths in dmabuf qbuf debug message

If the VIDIOC_QBUF ioctl fails due a wrong dmabuf length, it's useful to get the invalid and minimum lengths as a debug info. Before this patch: vb2-core: __qbuf_dmabuf: invalid dmabuf length for plane 1 After this patch: vb2-core: __qbuf_dmabuf: invalid dmabuf length 221248 for plane 1,

[PATCH net-next 0/3] net: dsa: mv88e6xxx: rework EEPROM code

Some switches can access an optional external EEPROM via its registers. The 88E6352 family of switches have 8-bit address / 16-bit data access. The new 88E6390 family has 16-bit address / 8-bit data access. This patchset cleans up the EEPROM code with 16-suffixed Global2 helpers and makes it

[PATCH net-next 0/3] net: dsa: mv88e6xxx: rework EEPROM code

Some switches can access an optional external EEPROM via its registers. The 88E6352 family of switches have 8-bit address / 16-bit data access. The new 88E6390 family has 16-bit address / 8-bit data access. This patchset cleans up the EEPROM code with 16-suffixed Global2 helpers and makes it

[PATCH net-next 1/3] net: dsa: mv88e6xxx: remove unused phy_mutex

Only reg_lock is necessary now and phy_mutex is dead. Remove it. --- drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h index 899ca1d..99de41f 100644 ---

[PATCH net-next 1/3] net: dsa: mv88e6xxx: remove unused phy_mutex

Only reg_lock is necessary now and phy_mutex is dead. Remove it. --- drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h index 899ca1d..99de41f 100644 ---

RE: [PATCH v3 00/11] mm: Hardened usercopy

From: Kees Cook > Sent: 20 July 2016 16:32 ... > Yup: that's exactly what it's doing: walking up the stack. :) Remind me to make sure all our customers run kernels with it disabled. David

RE: [PATCH v3 00/11] mm: Hardened usercopy

From: Kees Cook > Sent: 20 July 2016 16:32 ... > Yup: that's exactly what it's doing: walking up the stack. :) Remind me to make sure all our customers run kernels with it disabled. David

[PATCH] drm/atomic: Delete an unnecessary check before drm_property_unreference_blob()

From: Markus Elfring Date: Wed, 20 Jul 2016 17:54:32 +0200 The drm_property_unreference_blob() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle

Re: SOC-specific action for irq_set_wake

On Wed, 2016-07-20 at 14:36:12 +0100, Marc Zyngier wrote: > Hi Sören, > > On 20/07/16 14:16, Sören Brinkmann wrote: > > Hi Marc, > > > Does anybody have similar problems and probably already solved it? > > Any other suggestions for approaching the problem? Any preferred > > solution?

[PATCH] drm/atomic: Delete an unnecessary check before drm_property_unreference_blob()

From: Markus Elfring Date: Wed, 20 Jul 2016 17:54:32 +0200 The drm_property_unreference_blob() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus

Re: SOC-specific action for irq_set_wake

On Wed, 2016-07-20 at 14:36:12 +0100, Marc Zyngier wrote: > Hi Sören, > > On 20/07/16 14:16, Sören Brinkmann wrote: > > Hi Marc, > > > Does anybody have similar problems and probably already solved it? > > Any other suggestions for approaching the problem? Any preferred > > solution?

Re: [PATCH 4/8] mm, page_alloc: restructure direct compaction handling in slowpath

On 07/20/2016 12:50 AM, David Rientjes wrote: > On Mon, 18 Jul 2016, Vlastimil Babka wrote: > >> diff --git a/mm/page_alloc.c b/mm/page_alloc.c >> index 30443804f156..a04a67745927 100644 >> --- a/mm/page_alloc.c >> +++ b/mm/page_alloc.c >> @@ -3510,7 +3510,7 @@ __alloc_pages_slowpath(gfp_t

Re: [PATCH] Staging: ks7010: michael_mic: fixed macros coding style issue

On Tue, Jul 19, 2016 at 09:51:06AM +0800, Bing Sun wrote: > Fixed coding style issue: > Enclose multiple statements macros definition in a do while loop. > Use one space around binary operators. > > Signed-off-by: Bing Sun Looks good for what it is. One comment below.

Re: [PATCH 4/8] mm, page_alloc: restructure direct compaction handling in slowpath

On 07/20/2016 12:50 AM, David Rientjes wrote: > On Mon, 18 Jul 2016, Vlastimil Babka wrote: > >> diff --git a/mm/page_alloc.c b/mm/page_alloc.c >> index 30443804f156..a04a67745927 100644 >> --- a/mm/page_alloc.c >> +++ b/mm/page_alloc.c >> @@ -3510,7 +3510,7 @@ __alloc_pages_slowpath(gfp_t

Re: [PATCH] Staging: ks7010: michael_mic: fixed macros coding style issue

On Tue, Jul 19, 2016 at 09:51:06AM +0800, Bing Sun wrote: > Fixed coding style issue: > Enclose multiple statements macros definition in a do while loop. > Use one space around binary operators. > > Signed-off-by: Bing Sun Looks good for what it is. One comment below. I will test this tomorrow.

Re: [PATCH 4/9] staging: ks7010: Rename jump labels

On Sun, Jul 17, 2016 at 08:20:12PM +0200, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sun, 17 Jul 2016 16:26:18 +0200 > > Adjust jump targets according to the Linux coding style convention. Really? Is that documented somewhere? Quoting Jean Delvare:

Re: [PATCH 4/9] staging: ks7010: Rename jump labels

On Sun, Jul 17, 2016 at 08:20:12PM +0200, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sun, 17 Jul 2016 16:26:18 +0200 > > Adjust jump targets according to the Linux coding style convention. Really? Is that documented somewhere? Quoting Jean Delvare: "> It is generally accepted to

Re: [PATCH] crypto: qat - make qat_asym_algs.o depend on asn1 headers

Den 01-07-2016 kl. 12:30, skrev Herbert Xu: On Thu, Jun 30, 2016 at 12:23:51PM +0200, Jan Stancek wrote: Parallel build can sporadically fail because asn1 headers may not be built yet by the time qat_asym_algs.o is compiled: drivers/crypto/qat/qat_common/qat_asym_algs.c:55:32: fatal error:

Re: [PATCH] crypto: qat - make qat_asym_algs.o depend on asn1 headers

Den 01-07-2016 kl. 12:30, skrev Herbert Xu: On Thu, Jun 30, 2016 at 12:23:51PM +0200, Jan Stancek wrote: Parallel build can sporadically fail because asn1 headers may not be built yet by the time qat_asym_algs.o is compiled: drivers/crypto/qat/qat_common/qat_asym_algs.c:55:32: fatal error:

[PATCH 2/3] staging/rtl8192e: use s8 instead of char

Compiling the rtlwifi drivers for ARM with gcc -Wextra warns about lots of incorrect code that results from 'char' being unsigned here, e.g. staging/rtl8192e/rtl8192e/r8192E_phy.c:1072:36: error: comparison is always false due to limited range of data type [-Werror=type-limits]

[PATCH 2/3] staging/rtl8192e: use s8 instead of char

Compiling the rtlwifi drivers for ARM with gcc -Wextra warns about lots of incorrect code that results from 'char' being unsigned here, e.g. staging/rtl8192e/rtl8192e/r8192E_phy.c:1072:36: error: comparison is always false due to limited range of data type [-Werror=type-limits]

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

On Wednesday, July 20, 2016 11:33:43 AM CEST Jes Sorensen wrote: > Arnd Bergmann writes: > > On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote: > >> Arnd Bergmann writes: > >> Well it really all depends on how much time I have and how much others > >>

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

On Wednesday, July 20, 2016 11:33:43 AM CEST Jes Sorensen wrote: > Arnd Bergmann writes: > > On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote: > >> Arnd Bergmann writes: > >> Well it really all depends on how much time I have and how much others > >> step up and help contribute to

Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants

Hello, Aleksa. On Tue, Jul 19, 2016 at 02:18:16AM +1000, Aleksa Sarai wrote: > If we're moving from a parent to a direct descendant, the only end > result (on cgroupv2 hierarchies) is that the process experiences more > restrictive resource limits. Thus, there's no reason to restrict > processes

Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants

Hello, Aleksa. On Tue, Jul 19, 2016 at 02:18:16AM +1000, Aleksa Sarai wrote: > If we're moving from a parent to a direct descendant, the only end > result (on cgroupv2 hierarchies) is that the process experiences more > restrictive resource limits. Thus, there's no reason to restrict > processes

Re: [PATCH 9/9] staging: ks7010: Delete three unnecessary variable initialisations

On Sun, Jul 17, 2016 at 08:51:39PM +0200, Julia Lawall wrote: > > > On Sun, 17 Jul 2016, SF Markus Elfring wrote: > > > From: Markus Elfring > > Date: Sun, 17 Jul 2016 19:40:47 +0200 > > > > Three variables will be set to an appropriate value a bit later. > >

Re: [PATCH 9/9] staging: ks7010: Delete three unnecessary variable initialisations

On Sun, Jul 17, 2016 at 08:51:39PM +0200, Julia Lawall wrote: > > > On Sun, 17 Jul 2016, SF Markus Elfring wrote: > > > From: Markus Elfring > > Date: Sun, 17 Jul 2016 19:40:47 +0200 > > > > Three variables will be set to an appropriate value a bit later. > > Thus omit the explicit

Re: [PATCH 8/9] staging: ks7010: Delete a variable in write_to_device()

On Sun, Jul 17, 2016 at 08:28:44PM +0200, SF Markus Elfring wrote: > From 01291121668ccb54f1a784765a8d2b5811afa75a Mon Sep 17 00:00:00 2001 > From: Markus Elfring > Date: Sun, 17 Jul 2016 19:26:15 +0200 > Subject: [PATCH 8/9] staging: ks7010: Delete a variable in

Re: [PATCH 8/9] staging: ks7010: Delete a variable in write_to_device()

On Sun, Jul 17, 2016 at 08:28:44PM +0200, SF Markus Elfring wrote: > From 01291121668ccb54f1a784765a8d2b5811afa75a Mon Sep 17 00:00:00 2001 > From: Markus Elfring > Date: Sun, 17 Jul 2016 19:26:15 +0200 > Subject: [PATCH 8/9] staging: ks7010: Delete a variable in write_to_device() > > The local

Re: [PATCH 7/9] staging: ks7010: Replace three printk() calls by pr_err()

On Sun, Jul 17, 2016 at 01:26:03PM -0700, Joe Perches wrote: > On Sun, 2016-07-17 at 20:27 +0200, SF Markus Elfring wrote: > > From: Markus Elfring > > Date: Sun, 17 Jul 2016 19:12:27 +0200 > > > > Prefer usage of the macro "pr_err" over the interface "printk". > >

Re: [PATCH 7/9] staging: ks7010: Replace three printk() calls by pr_err()

On Sun, Jul 17, 2016 at 01:26:03PM -0700, Joe Perches wrote: > On Sun, 2016-07-17 at 20:27 +0200, SF Markus Elfring wrote: > > From: Markus Elfring > > Date: Sun, 17 Jul 2016 19:12:27 +0200 > > > > Prefer usage of the macro "pr_err" over the interface "printk". > > Fix a typo in an error

Re: [PATCH 6/9] staging: ks7010: Delete unnecessary braces

On Sun, Jul 17, 2016 at 08:55:41PM +0200, Julia Lawall wrote: > > > On Sun, 17 Jul 2016, SF Markus Elfring wrote: > > > From: Markus Elfring > > Date: Sun, 17 Jul 2016 18:39:03 +0200 > > > > Do not use curly brackets at some source code places > > where a single

Re: [PATCH 6/9] staging: ks7010: Delete unnecessary braces

On Sun, Jul 17, 2016 at 08:55:41PM +0200, Julia Lawall wrote: > > > On Sun, 17 Jul 2016, SF Markus Elfring wrote: > > > From: Markus Elfring > > Date: Sun, 17 Jul 2016 18:39:03 +0200 > > > > Do not use curly brackets at some source code places > > where a single statement should be sufficient.

Re: [PATCH 5/9] staging: ks7010: Delete unnecessary uses of the variable "retval"

On Sun, Jul 17, 2016 at 08:56:59PM +0200, Julia Lawall wrote: > > > On Sun, 17 Jul 2016, SF Markus Elfring wrote: > > > From: Markus Elfring > > Date: Sun, 17 Jul 2016 18:15:23 +0200 > > > > Some return values can also be directly used for various condition

Re: [PATCH 5/9] staging: ks7010: Delete unnecessary uses of the variable "retval"

On Sun, Jul 17, 2016 at 08:56:59PM +0200, Julia Lawall wrote: > > > On Sun, 17 Jul 2016, SF Markus Elfring wrote: > > > From: Markus Elfring > > Date: Sun, 17 Jul 2016 18:15:23 +0200 > > > > Some return values can also be directly used for various condition checks. > > Thus remove a local

Re: [RFC 0/3] extend kexec_file_load system call

Am Mittwoch, 20 Juli 2016, 13:12:20 schrieb Arnd Bergmann: > On Wednesday, July 20, 2016 8:47:45 PM CEST Michael Ellerman wrote: > > At least for stdout-path, I can't really see how that would > > significantly help an attacker, but I'm all ears if anyone has ideas. > > That's actually an easy

Re: [RFC 0/3] extend kexec_file_load system call

Am Mittwoch, 20 Juli 2016, 13:12:20 schrieb Arnd Bergmann: > On Wednesday, July 20, 2016 8:47:45 PM CEST Michael Ellerman wrote: > > At least for stdout-path, I can't really see how that would > > significantly help an attacker, but I'm all ears if anyone has ideas. > > That's actually an easy

Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support

On Fri, Jul 08, 2016 at 12:35:48PM -0400, David Long wrote: > +#define MIN_STACK_SIZE(addr) (on_irq_stack(addr, raw_smp_processor_id()) ? \ > + min((unsigned long)IRQ_STACK_SIZE, \ > + IRQ_STACK_PTR(raw_smp_processor_id()) - (addr)) : \ > + min((unsigned long)MAX_STACK_SIZE,

Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support

On Fri, Jul 08, 2016 at 12:35:48PM -0400, David Long wrote: > +#define MIN_STACK_SIZE(addr) (on_irq_stack(addr, raw_smp_processor_id()) ? \ > + min((unsigned long)IRQ_STACK_SIZE, \ > + IRQ_STACK_PTR(raw_smp_processor_id()) - (addr)) : \ > + min((unsigned long)MAX_STACK_SIZE,

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

On Wednesday, July 20, 2016 5:06:27 PM CEST Xose Vazquez Perez wrote: > Arnd Bergmann wrote: > > > rtlwifi, but I found the older r8712u device to work fine with > > the staging/rtl8712 driver. > > A replacement for "staging/rtl8712", with MAC80211 support, is > available at:

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

On Wednesday, July 20, 2016 5:06:27 PM CEST Xose Vazquez Perez wrote: > Arnd Bergmann wrote: > > > rtlwifi, but I found the older r8712u device to work fine with > > the staging/rtl8712 driver. > > A replacement for "staging/rtl8712", with MAC80211 support, is > available at:

Re: [PATCH 3/9] staging: ks7010: Return directly after a failed kmalloc()

On Sun, Jul 17, 2016 at 08:58:14PM +0200, Julia Lawall wrote: > > > On Sun, 17 Jul 2016, SF Markus Elfring wrote: > > > From: Markus Elfring > > Date: Sun, 17 Jul 2016 15:55:02 +0200 > > > > Return directly after a memory allocation failed at the beginning. > > >

Re: [PATCH 3/9] staging: ks7010: Return directly after a failed kmalloc()

On Sun, Jul 17, 2016 at 08:58:14PM +0200, Julia Lawall wrote: > > > On Sun, 17 Jul 2016, SF Markus Elfring wrote: > > > From: Markus Elfring > > Date: Sun, 17 Jul 2016 15:55:02 +0200 > > > > Return directly after a memory allocation failed at the beginning. > > > > Signed-off-by: Markus

Re: [RFD] Efficient unit test and fuzz tools for kernel/libc porting

On Wed, 6 Jul 2016, Zhangjian (Bamvor) wrote: > correct or not. After learn and compare some fuzz tools, I feel that there is > no such fuzz tools could help me. So, I wrote a new fuzz tools base on the > trinity and it found several wrapper issues in glibc. I will first explain the > different

Re: [RFD] Efficient unit test and fuzz tools for kernel/libc porting

On Wed, 6 Jul 2016, Zhangjian (Bamvor) wrote: > correct or not. After learn and compare some fuzz tools, I feel that there is > no such fuzz tools could help me. So, I wrote a new fuzz tools base on the > trinity and it found several wrapper issues in glibc. I will first explain the > different

Re: [PATCH v1 2/3] cgroup: allow for unprivileged subtree management

Hello, Aleksa. On Tue, Jul 19, 2016 at 02:18:15AM +1000, Aleksa Sarai wrote: > +static int cgroup_permission(struct inode *inode, struct kernfs_node *kn, > + int mask) > +{ > + int ret; > + struct cgroup *cgroup; > + struct cgroup_namespace *cgroupns; > + > +

Re: [PATCH v1 2/3] cgroup: allow for unprivileged subtree management

Hello, Aleksa. On Tue, Jul 19, 2016 at 02:18:15AM +1000, Aleksa Sarai wrote: > +static int cgroup_permission(struct inode *inode, struct kernfs_node *kn, > + int mask) > +{ > + int ret; > + struct cgroup *cgroup; > + struct cgroup_namespace *cgroupns; > + > +

[PATCH v4] ipc/msg: Implement lockless pipelined wakeups

This patch moves the wakeup_process() invocation so it is not done under the perm->lock by making use of a lockless wake_q. With this change, the waiter is woken up once the message has been assigned and it does not need to loop on SMP if the message points to NULL. In the signal case we still

[PATCH v4] ipc/msg: Implement lockless pipelined wakeups

This patch moves the wakeup_process() invocation so it is not done under the perm->lock by making use of a lockless wake_q. With this change, the waiter is woken up once the message has been assigned and it does not need to loop on SMP if the message points to NULL. In the signal case we still

Re: [PATCH 2/9] staging: ks7010: Delete unnecessary assignments for buffer variables

On Sun, Jul 17, 2016 at 08:15:11PM +0200, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sun, 17 Jul 2016 13:38:46 +0200 > > A few variables were assigned a null pointer despite of the detail > that they were immediately reassigned by the following

Re: [PATCH 2/9] staging: ks7010: Delete unnecessary assignments for buffer variables

On Sun, Jul 17, 2016 at 08:15:11PM +0200, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sun, 17 Jul 2016 13:38:46 +0200 > > A few variables were assigned a null pointer despite of the detail > that they were immediately reassigned by the following statement. > Thus remove such

Re: [PATCH 1/9] staging: ks7010: Delete unnecessary checks before the function call "kfree"

On Sun, Jul 17, 2016 at 08:10:48PM +0200, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sun, 17 Jul 2016 13:14:57 +0200 > > The kfree() function tests whether its argument is NULL and then > returns immediately. Thus the test around the calls is not

Re: [PATCH 1/9] staging: ks7010: Delete unnecessary checks before the function call "kfree"

On Sun, Jul 17, 2016 at 08:10:48PM +0200, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sun, 17 Jul 2016 13:14:57 +0200 > > The kfree() function tests whether its argument is NULL and then > returns immediately. Thus the test around the calls is not needed. > > This issue was detected

Re: [PATCH v3 02/11] mm: Hardened usercopy

On 07/20/2016 03:24 AM, Balbir Singh wrote: On Tue, 2016-07-19 at 11:48 -0700, Kees Cook wrote: On Mon, Jul 18, 2016 at 6:06 PM, Laura Abbott wrote: On 07/15/2016 02:44 PM, Kees Cook wrote: This doesn't work when copying CMA allocated memory since CMA purposely allocates

Re: [PATCH v3 02/11] mm: Hardened usercopy

On 07/20/2016 03:24 AM, Balbir Singh wrote: On Tue, 2016-07-19 at 11:48 -0700, Kees Cook wrote: On Mon, Jul 18, 2016 at 6:06 PM, Laura Abbott wrote: On 07/15/2016 02:44 PM, Kees Cook wrote: This doesn't work when copying CMA allocated memory since CMA purposely allocates larger than a page

Re: [PATCH 3/3] staging/rtl8192e: avoid comparing unsigned type >= 0

Arnd Bergmann writes: > There is one remaining warning about a type limit check in rtl8192e: > > staging/rtl8192e/rtl819x_TSProc.c:326:14: error: comparison is always true > due to limited range of data type [-Werror=type-limits] > > This changes a macro into a local function to

Re: [PATCH 3/3] staging/rtl8192e: avoid comparing unsigned type >= 0

Arnd Bergmann writes: > There is one remaining warning about a type limit check in rtl8192e: > > staging/rtl8192e/rtl819x_TSProc.c:326:14: error: comparison is always true > due to limited range of data type [-Werror=type-limits] > > This changes a macro into a local function to clarify the

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

Arnd Bergmann writes: > On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote: >> Arnd Bergmann writes: >> Well it really all depends on how much time I have and how much others >> step up and help contribute to the code. For rtl8xxxu my plans are as >>

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

Arnd Bergmann writes: > On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote: >> Arnd Bergmann writes: >> Well it really all depends on how much time I have and how much others >> step up and help contribute to the code. For rtl8xxxu my plans are as >> follows: >> >> 1) rtl8188eu

Re: [PATCH 03/13] RTC: ds1307: Add DS1341 specific power-saving options

On 20/07/2016 at 07:36:55 -0700, Andrey Smirnov wrote : > On Wed, Jul 20, 2016 at 2:02 AM, Alexandre Belloni > wrote: > > On 19/07/2016 at 16:56:56 -0700, Andrey Smirnov wrote : > >> >> I don't see any value in doing that, could you give me a realistic > >>

Re: [PATCH 03/13] RTC: ds1307: Add DS1341 specific power-saving options

On 20/07/2016 at 07:36:55 -0700, Andrey Smirnov wrote : > On Wed, Jul 20, 2016 at 2:02 AM, Alexandre Belloni > wrote: > > On 19/07/2016 at 16:56:56 -0700, Andrey Smirnov wrote : > >> >> I don't see any value in doing that, could you give me a realistic > >> >> example of a scenario in which a

Re: [net-next PATCH 1/3] net: phy: dp83867: Add documentation for optional impedance control

On 07/20/2016 09:56 AM, Mugunthan V N wrote: Add documention of ti,impedance-control which can be used to correct MAC impedance mismatch using phy extended registers. Signed-off-by: Mugunthan V N --- Documentation/devicetree/bindings/net/ti,dp83867.txt | 7 +++ 1

Re: [PATCH 01/10] coresight: etm-perf: pass struct perf_event to source::enable/disable()

On 18/07/16 20:51, Mathieu Poirier wrote: With this commit [1] address range filter information is now found in the struct hw_perf_event::addr_filters. As such pass the event itself to the coresight_source::enable/disable() functions so that both event attribute and filter can be accessible for

Re: [net-next PATCH 1/3] net: phy: dp83867: Add documentation for optional impedance control

On 07/20/2016 09:56 AM, Mugunthan V N wrote: Add documention of ti,impedance-control which can be used to correct MAC impedance mismatch using phy extended registers. Signed-off-by: Mugunthan V N --- Documentation/devicetree/bindings/net/ti,dp83867.txt | 7 +++ 1 file changed, 7

Re: [PATCH 01/10] coresight: etm-perf: pass struct perf_event to source::enable/disable()

On 18/07/16 20:51, Mathieu Poirier wrote: With this commit [1] address range filter information is now found in the struct hw_perf_event::addr_filters. As such pass the event itself to the coresight_source::enable/disable() functions so that both event attribute and filter can be accessible for

[PATCH 3/3] staging/rtl8192e: avoid comparing unsigned type >= 0

There is one remaining warning about a type limit check in rtl8192e: staging/rtl8192e/rtl819x_TSProc.c:326:14: error: comparison is always true due to limited range of data type [-Werror=type-limits] This changes a macro into a local function to clarify the types and simplify the check while

[PATCH 3/3] staging/rtl8192e: avoid comparing unsigned type >= 0

There is one remaining warning about a type limit check in rtl8192e: staging/rtl8192e/rtl819x_TSProc.c:326:14: error: comparison is always true due to limited range of data type [-Werror=type-limits] This changes a macro into a local function to clarify the types and simplify the check while

[PATCH] leds/trigger/cpu: move from CPU_STARTING to ONLINE level

There is no need the ledtriger to be called *that* early in the hotplug process (+ with disabled interrupts). As explained by Jacek Anaszewski [0] there is no need for it. Therefore this patch moves it to the ONLINE/PREPARE_DOWN level using the dynamic registration for the id. [0]

[PATCH] leds/trigger/cpu: move from CPU_STARTING to ONLINE level

There is no need the ledtriger to be called *that* early in the hotplug process (+ with disabled interrupts). As explained by Jacek Anaszewski [0] there is no need for it. Therefore this patch moves it to the ONLINE/PREPARE_DOWN level using the dynamic registration for the id. [0]

Re: [PATCH v3 00/11] mm: Hardened usercopy

On Wed, Jul 20, 2016 at 2:52 AM, David Laight wrote: > From: Kees Cook >> Sent: 15 July 2016 22:44 >> This is a start of the mainline port of PAX_USERCOPY[1]. > ... >> - if address range is in the current process stack, it must be within the >> current stack frame (if

Re: [PATCH v3 00/11] mm: Hardened usercopy

On Wed, Jul 20, 2016 at 2:52 AM, David Laight wrote: > From: Kees Cook >> Sent: 15 July 2016 22:44 >> This is a start of the mainline port of PAX_USERCOPY[1]. > ... >> - if address range is in the current process stack, it must be within the >> current stack frame (if such checking is possible)

Re: Cgroup: iops throttle problem

Hello, On Mon, Jul 18, 2016 at 09:35:12PM +0800, 张真 wrote: > Hello > My name is Zhen Zhang , me and Jiale Li recently test and analyze the cgroup > blkio functions. > We tested the buffered read a file using bio when the > blkio.throttle.read_iops_device is set 1000. > The fio result file

Re: Cgroup: iops throttle problem

Hello, On Mon, Jul 18, 2016 at 09:35:12PM +0800, 张真 wrote: > Hello > My name is Zhen Zhang , me and Jiale Li recently test and analyze the cgroup > blkio functions. > We tested the buffered read a file using bio when the > blkio.throttle.read_iops_device is set 1000. > The fio result file

[PATCH 3/5] mm, vmscan: Remove highmem_file_pages

With the reintroduction of per-zone LRU stats, highmem_file_pages is redundant so remove it. Signed-off-by: Mel Gorman --- include/linux/mm_inline.h | 17 - mm/page-writeback.c | 12 2 files changed, 4 insertions(+), 25

[PATCH 3/5] mm, vmscan: Remove highmem_file_pages

With the reintroduction of per-zone LRU stats, highmem_file_pages is redundant so remove it. Signed-off-by: Mel Gorman --- include/linux/mm_inline.h | 17 - mm/page-writeback.c | 12 2 files changed, 4 insertions(+), 25 deletions(-) diff --git

Re: [PATCH 3/8] mm, page_alloc: don't retry initial attempt in slowpath

On 07/20/2016 12:36 AM, David Rientjes wrote: > On Mon, 18 Jul 2016, Vlastimil Babka wrote: > >> After __alloc_pages_slowpath() sets up new alloc_flags and wakes up kswapd, >> it >> first tries get_page_from_freelist() with the new alloc_flags, as it may >> succeed e.g. due to using min

Re: [PATCH 3/8] mm, page_alloc: don't retry initial attempt in slowpath

On 07/20/2016 12:36 AM, David Rientjes wrote: > On Mon, 18 Jul 2016, Vlastimil Babka wrote: > >> After __alloc_pages_slowpath() sets up new alloc_flags and wakes up kswapd, >> it >> first tries get_page_from_freelist() with the new alloc_flags, as it may >> succeed e.g. due to using min

Re: [PATCH v2 02/10] driver core: Functional dependencies tracking support

On Wed, Jul 20, 2016 at 02:52:42PM +0200, Rafael J. Wysocki wrote: > On Wednesday, July 20, 2016 08:24:50 AM Lukas Wunner wrote: > > On Wed, Jul 20, 2016 at 02:33:18AM +0200, Rafael J. Wysocki wrote: > > > On Friday, June 17, 2016 04:07:38 PM Lukas Wunner wrote: > > > > On Fri, Jun 17, 2016 at

Re: [PATCH v2 02/10] driver core: Functional dependencies tracking support

On Wed, Jul 20, 2016 at 02:52:42PM +0200, Rafael J. Wysocki wrote: > On Wednesday, July 20, 2016 08:24:50 AM Lukas Wunner wrote: > > On Wed, Jul 20, 2016 at 02:33:18AM +0200, Rafael J. Wysocki wrote: > > > On Friday, June 17, 2016 04:07:38 PM Lukas Wunner wrote: > > > > On Fri, Jun 17, 2016 at

[PATCH 4/5] mm: Remove reclaim and compaction retry approximations

If per-zone LRU accounting is available then there is no point approximating whether reclaim and compaction should retry based on pgdat statistics. This is effectively a revert of "mm, vmstat: remove zone and node double accounting by approximating retries" with the difference that inactive/active

[PATCH 0/5] Candidate fixes for premature OOM kills with node-lru v1

Both Joonsoo Kim and Minchan Kim have reported premature OOM kills on a 32-bit platform. The common element is a zone-constrained high-order allocation failing. Two factors appear to be at fault -- pgdat being considered unreclaimable prematurely and insufficient rotation of the active list.

[PATCH 2/5] mm: add per-zone lru list stat

From: Minchan Kim While I did stress test with hackbench, I got OOM message frequently which didn't ever happen in zone-lru. gfp_mask=0x26004c0(GFP_KERNEL|__GFP_REPEAT|__GFP_NOTRACK), order=0 .. .. [] __alloc_pages_nodemask+0xe52/0xe60 [] ? new_slab+0x39c/0x3b0 []

[PATCH 4/5] mm: Remove reclaim and compaction retry approximations

If per-zone LRU accounting is available then there is no point approximating whether reclaim and compaction should retry based on pgdat statistics. This is effectively a revert of "mm, vmstat: remove zone and node double accounting by approximating retries" with the difference that inactive/active

[PATCH 0/5] Candidate fixes for premature OOM kills with node-lru v1

Both Joonsoo Kim and Minchan Kim have reported premature OOM kills on a 32-bit platform. The common element is a zone-constrained high-order allocation failing. Two factors appear to be at fault -- pgdat being considered unreclaimable prematurely and insufficient rotation of the active list.

[PATCH 2/5] mm: add per-zone lru list stat

From: Minchan Kim While I did stress test with hackbench, I got OOM message frequently which didn't ever happen in zone-lru. gfp_mask=0x26004c0(GFP_KERNEL|__GFP_REPEAT|__GFP_NOTRACK), order=0 .. .. [] __alloc_pages_nodemask+0xe52/0xe60 [] ? new_slab+0x39c/0x3b0 [] new_slab+0x39c/0x3b0 []

[PATCH 5/5] mm: consider per-zone inactive ratio to deactivate

From: Minchan Kim Minchan Kim reported that with per-zone lru state it was possible to identify that a normal zone with 8^M anonymous pages could trigger OOM with non-atomic order-0 allocations as all pages in the zone were in the active list.

[PATCH 5/5] mm: consider per-zone inactive ratio to deactivate

From: Minchan Kim Minchan Kim reported that with per-zone lru state it was possible to identify that a normal zone with 8^M anonymous pages could trigger OOM with non-atomic order-0 allocations as all pages in the zone were in the active list.

[PATCH 1/5] mm, vmscan: Do not account skipped pages as scanned

Page reclaim determines whether a pgdat is unreclaimable by examining how many pages have been scanned since a page was freed and comparing that to the LRU sizes. Skipped pages are not considered reclaim candidates but contribute to scanned. This can prematurely mark a pgdat as unreclaimable and

[PATCH 1/5] mm, vmscan: Do not account skipped pages as scanned

Page reclaim determines whether a pgdat is unreclaimable by examining how many pages have been scanned since a page was freed and comparing that to the LRU sizes. Skipped pages are not considered reclaim candidates but contribute to scanned. This can prematurely mark a pgdat as unreclaimable and

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