[PATCH] PM / devfreq: exynos-ppmu: Delete an error message for a failed memory allocation in exynos_ppmu_probe()

From: Markus Elfring Date: Tue, 13 Feb 2018 22:10:42 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

[PATCH] PM / devfreq: exynos-ppmu: Delete an error message for a failed memory allocation in exynos_ppmu_probe()

From: Markus Elfring Date: Tue, 13 Feb 2018 22:10:42 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/devfreq/event/exynos-ppmu.c | 6 ++ 1 file changed, 2

Re: [PATCH] tracing: Fix incorrect file name

On Sun, 04 Feb 2018 18:14:24 +0800 Xiongwei Song wrote: > There is no file named 'enabled' in the directory tracing/events. It should > be the file 'enable'. Makes sense, applied to the docs tree, thanks. jon

Re: [PATCH] tracing: Fix incorrect file name

On Sun, 04 Feb 2018 18:14:24 +0800 Xiongwei Song wrote: > There is no file named 'enabled' in the directory tracing/events. It should > be the file 'enable'. Makes sense, applied to the docs tree, thanks. jon

Re: [PATCH v2] fs: fsnotify: account fsnotify metadata to kmemcg

On Mon, Feb 12, 2018 at 10:30 PM, Amir Goldstein wrote: > On Thu, Jan 25, 2018 at 10:36 PM, Amir Goldstein wrote: >> On Thu, Jan 25, 2018 at 10:20 PM, Shakeel Butt wrote: >>> On Wed, Jan 24, 2018 at 11:51 PM, Amir Goldstein

Re: [PATCH v2] fs: fsnotify: account fsnotify metadata to kmemcg

On Mon, Feb 12, 2018 at 10:30 PM, Amir Goldstein wrote: > On Thu, Jan 25, 2018 at 10:36 PM, Amir Goldstein wrote: >> On Thu, Jan 25, 2018 at 10:20 PM, Shakeel Butt wrote: >>> On Wed, Jan 24, 2018 at 11:51 PM, Amir Goldstein wrote: There is a nicer alternative, instead of failing the

Re: [RFC 1/3] seccomp: add a return code to trap to userspace

On Sun, Feb 4, 2018 at 2:49 AM, Tycho Andersen wrote: > This patch introduces a means for syscalls matched in seccomp to notify > some other task that a particular filter has been triggered. > > The motivation for this is primarily for use with containers. For example, > if a

Re: [RFC 1/3] seccomp: add a return code to trap to userspace

On Sun, Feb 4, 2018 at 2:49 AM, Tycho Andersen wrote: > This patch introduces a means for syscalls matched in seccomp to notify > some other task that a particular filter has been triggered. > > The motivation for this is primarily for use with containers. For example, > if a container does an

Re: [RFC PATCH v1 00/13] lru_lock scalability

On 02/08/2018 06:36 PM, Andrew Morton wrote: On Wed, 31 Jan 2018 18:04:00 -0500 daniel.m.jor...@oracle.com wrote: lru_lock, a per-node* spinlock that protects an LRU list, is one of the hottest locks in the kernel. On some workloads on large machines, it shows up at the top of lock_stat. Do

Re: [RFC PATCH v1 00/13] lru_lock scalability

On 02/08/2018 06:36 PM, Andrew Morton wrote: On Wed, 31 Jan 2018 18:04:00 -0500 daniel.m.jor...@oracle.com wrote: lru_lock, a per-node* spinlock that protects an LRU list, is one of the hottest locks in the kernel. On some workloads on large machines, it shows up at the top of lock_stat. Do

Re: [BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2

Hi! > > You might think this absolutely crazy, but I would be willing to test > > such systems if I can get my hands on the needed hardware that I lack. > > I am already doing sanity testing on Intel > > i486/i586/i586-MMX/i686-PentiumPro systems, I just don't have the > > clone cpus (Cyrix,

Re: [BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2

Hi! > > You might think this absolutely crazy, but I would be willing to test > > such systems if I can get my hands on the needed hardware that I lack. > > I am already doing sanity testing on Intel > > i486/i586/i586-MMX/i686-PentiumPro systems, I just don't have the > > clone cpus (Cyrix,

Re: [BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2

On Thu 2018-02-08 20:52:40, Alan Cox wrote: > > > Also worth nothing that the difference between the cpu and memory > > > speeds is much lower - so far fewer instructions could be speculatively > > > executed while waiting a cache miss. > > But they also have more instructions that take a lot of

Re: [BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2

On Thu 2018-02-08 20:52:40, Alan Cox wrote: > > > Also worth nothing that the difference between the cpu and memory > > > speeds is much lower - so far fewer instructions could be speculatively > > > executed while waiting a cache miss. > > But they also have more instructions that take a lot of

Re: [PATCH v2 8/8] platform: vivid-cec: use 64-bit arithmetic instead of 32-bit

On Mon 2018-02-05 22:29:41, Hans Verkuil wrote: > On 02/05/2018 09:36 PM, Gustavo A. R. Silva wrote: > > Add suffix ULL to constant 10 in order to give the compiler complete > > information about the proper arithmetic to use. Notice that this > > constant is used in a context that expects an

Re: [PATCH v2 8/8] platform: vivid-cec: use 64-bit arithmetic instead of 32-bit

On Mon 2018-02-05 22:29:41, Hans Verkuil wrote: > On 02/05/2018 09:36 PM, Gustavo A. R. Silva wrote: > > Add suffix ULL to constant 10 in order to give the compiler complete > > information about the proper arithmetic to use. Notice that this > > constant is used in a context that expects an

[PATCH] dmaengine: at_xdmac: Delete an error message for a failed memory allocation in at_xdmac_probe()

From: Markus Elfring Date: Tue, 13 Feb 2018 21:48:26 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

[PATCH] dmaengine: at_xdmac: Delete an error message for a failed memory allocation in at_xdmac_probe()

From: Markus Elfring Date: Tue, 13 Feb 2018 21:48:26 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/dma/at_xdmac.c | 4 +--- 1 file changed, 1 insertion(+), 3

RE: [PATCH] igb: Fix a test with HWTSTAMP_TX_ON

> From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Christophe JAILLET > Sent: Tuesday, February 6, 2018 11:48 AM > To: Kirsher, Jeffrey T > Cc: intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; linux- >

RE: [PATCH] igb: Fix a test with HWTSTAMP_TX_ON

> From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Christophe JAILLET > Sent: Tuesday, February 6, 2018 11:48 AM > To: Kirsher, Jeffrey T > Cc: intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; linux- > ker...@vger.kernel.org;

Re: [PATCH] loop: Fix lost writes caused by missing flag

On Tue, Feb 13, 2018 at 11:22 AM, Ross Zwisler wrote: > On Tue, Feb 13, 2018 at 03:54:04PM +0100, Christoph Hellwig wrote: >> Looks good: >> >> Reviewed-by: Christoph Hellwig >> >> Can you wire up your test cases for blktests? > > Is blktests really the

Re: [PATCH] loop: Fix lost writes caused by missing flag

On Tue, Feb 13, 2018 at 11:22 AM, Ross Zwisler wrote: > On Tue, Feb 13, 2018 at 03:54:04PM +0100, Christoph Hellwig wrote: >> Looks good: >> >> Reviewed-by: Christoph Hellwig >> >> Can you wire up your test cases for blktests? > > Is blktests really the right place for this test? This failure

Re: [PATCH] rtc: goldfish: Add missing MODULE_LICENSE

On 16/01/2018 at 14:45:21 +, James Hogan wrote: > Fix the following warning in MIPS allmodconfig by adding a > MODULE_LICENSE() at the end of rtc-goldfish.c, based on the file header > comment which says GNU General Public License version 2: > > WARNING: modpost: missing MODULE_LICENSE() in

Re: [PATCH] rtc: goldfish: Add missing MODULE_LICENSE

On 16/01/2018 at 14:45:21 +, James Hogan wrote: > Fix the following warning in MIPS allmodconfig by adding a > MODULE_LICENSE() at the end of rtc-goldfish.c, based on the file header > comment which says GNU General Public License version 2: > > WARNING: modpost: missing MODULE_LICENSE() in

Re: [PATCH] lib/scatterlist: Make sg_page_count() accessible to other modules

On 02/13/2018 10:14 PM, Andy Shevchenko wrote: > On Sat, Feb 10, 2018 at 8:06 PM, Alexey Skidanov > wrote: >> Currently, sg_page_count() may be used only inside the scatterlist.c file. >> >> However, the same calculation is done outside of scatterlist.c file >>

Re: [PATCH] lib/scatterlist: Make sg_page_count() accessible to other modules

On 02/13/2018 10:14 PM, Andy Shevchenko wrote: > On Sat, Feb 10, 2018 at 8:06 PM, Alexey Skidanov > wrote: >> Currently, sg_page_count() may be used only inside the scatterlist.c file. >> >> However, the same calculation is done outside of scatterlist.c file >> causing to code duplication. >>

[PATCH 3/3] memory: brcmstb: dpfe: support new way of passing data from the DCPU

The DCPU can now send message data in two ways: - via the data RAM, as before (this is now message type 0) - via the message RAM (this is message type 1) In order to support both methods, we check the message type of the response (bits 31:28) and then treat the offset (bits 27:0) accordingly.

[PATCH 3/3] memory: brcmstb: dpfe: support new way of passing data from the DCPU

The DCPU can now send message data in two ways: - via the data RAM, as before (this is now message type 0) - via the message RAM (this is message type 1) In order to support both methods, we check the message type of the response (bits 31:28) and then treat the offset (bits 27:0) accordingly.

[PATCH 2/3] memory: brcmstb: dpfe: fix type declaration of variable "ret"

In some functions, variable "ret" should be ssize_t, so we fix it. Fixes: 2f330caff577 ("memory: brcmstb: Add driver for DPFE") Signed-off-by: Markus Mayer --- drivers/memory/brcmstb_dpfe.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

[PATCH 2/3] memory: brcmstb: dpfe: fix type declaration of variable "ret"

In some functions, variable "ret" should be ssize_t, so we fix it. Fixes: 2f330caff577 ("memory: brcmstb: Add driver for DPFE") Signed-off-by: Markus Mayer --- drivers/memory/brcmstb_dpfe.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/memory/brcmstb_dpfe.c

[PATCH 0/3] Update for the Broadcom STB DPFE driver

This series primarily introduces a new way of passing information from the DCPU to the host CPU. Previously, all communication was via the DCPU data RAM. This communication mode is still supported. In addition, we now support passing data via the message RAM. The driver will dynamically detect

[PATCH 0/3] Update for the Broadcom STB DPFE driver

This series primarily introduces a new way of passing information from the DCPU to the host CPU. Previously, all communication was via the DCPU data RAM. This communication mode is still supported. In addition, we now support passing data via the message RAM. The driver will dynamically detect

[PATCH 1/3] memory: brcmstb: dpfe: properly mask vendor error bits

We were printing the entire 32 bit register rather than just the lower 8 bits. Anything above bit 7 is reserved and may be any random value. Fixes: 2f330caff577 ("memory: brcmstb: Add driver for DPFE") Signed-off-by: Markus Mayer --- drivers/memory/brcmstb_dpfe.c | 3 ++- 1

[PATCH 1/3] memory: brcmstb: dpfe: properly mask vendor error bits

We were printing the entire 32 bit register rather than just the lower 8 bits. Anything above bit 7 is reserved and may be any random value. Fixes: 2f330caff577 ("memory: brcmstb: Add driver for DPFE") Signed-off-by: Markus Mayer --- drivers/memory/brcmstb_dpfe.c | 3 ++- 1 file changed, 2

Re: [PATCH 1/2] dma/ppc4xx: Delete an error message for a failed memory allocation in two functions

On Tue, 2018-02-13 at 21:25 +0100, SF Markus Elfring wrote: > Omit an extra message for a memory allocation failure in these functions. [] > diff --git a/drivers/dma/ppc4xx/adma.c b/drivers/dma/ppc4xx/adma.c [] > @@ -4183,7 +4183,6 @@ static int ppc440spe_adma_probe(struct platform_device >

Re: [PATCH 1/2] dma/ppc4xx: Delete an error message for a failed memory allocation in two functions

On Tue, 2018-02-13 at 21:25 +0100, SF Markus Elfring wrote: > Omit an extra message for a memory allocation failure in these functions. [] > diff --git a/drivers/dma/ppc4xx/adma.c b/drivers/dma/ppc4xx/adma.c [] > @@ -4183,7 +4183,6 @@ static int ppc440spe_adma_probe(struct platform_device >

[PATCH V3 04/10] sched/core: Prevent race condition between cpuset and __sched_setscheduler()

No synchronisation mechanism exist between the cpuset subsystem and calls to function __sched_setscheduler(). As such it is possible that new root domains are created on the cpuset side while a deadline acceptance test is carried out in __sched_setscheduler(), leading to a potential oversell of

[PATCH V3 04/10] sched/core: Prevent race condition between cpuset and __sched_setscheduler()

No synchronisation mechanism exist between the cpuset subsystem and calls to function __sched_setscheduler(). As such it is possible that new root domains are created on the cpuset side while a deadline acceptance test is carried out in __sched_setscheduler(), leading to a potential oversell of

[PATCH V3 01/10] sched/topology: Add check to backup comment about hotplug lock

The comment above function partition_sched_domains() clearly state that the cpu_hotplug_lock should be held but doesn't mandate one to abide to it. Adding an explicit check backs that comment and make it impossible for anyone to miss the requirement. Suggested-by: Juri Lelli

[PATCH V3 01/10] sched/topology: Add check to backup comment about hotplug lock

The comment above function partition_sched_domains() clearly state that the cpu_hotplug_lock should be held but doesn't mandate one to abide to it. Adding an explicit check backs that comment and make it impossible for anyone to miss the requirement. Suggested-by: Juri Lelli Signed-off-by:

[PATCH V3 03/10] sched/core: Streamlining calls to task_rq_unlock()

Calls to task_rq_unlock() are done several times in function __sched_setscheduler(). This is fine when only the rq lock needs to be handled but not so much when other locks come into play. This patch streamline the release of the rq lock so that only one location need to be modified when dealing

[PATCH V3 03/10] sched/core: Streamlining calls to task_rq_unlock()

Calls to task_rq_unlock() are done several times in function __sched_setscheduler(). This is fine when only the rq lock needs to be handled but not so much when other locks come into play. This patch streamline the release of the rq lock so that only one location need to be modified when dealing

[PATCH V3 07/10] cgroup: Constrain 'sched_load_balance' flag when DL tasks are present

This patch prevents the 'sched_load_balance' flag from being set to 0 when DL tasks are present in a CPUset. Otherwise we end up with the DL tasks using CPUs belonging to different root domains, something that breaks the mathematical model behind DL bandwidth management. For example on a 4 core

[PATCH V3 07/10] cgroup: Constrain 'sched_load_balance' flag when DL tasks are present

This patch prevents the 'sched_load_balance' flag from being set to 0 when DL tasks are present in a CPUset. Otherwise we end up with the DL tasks using CPUs belonging to different root domains, something that breaks the mathematical model behind DL bandwidth management. For example on a 4 core

[PATCH V3 05/10] cpuset: Rebuild root domain deadline accounting information

When the topology of root domains is modified by CPUset or CPUhotplug operations information about the current deadline bandwidth held in the root domain is lost. This patch address the issue by recalculating the lost deadline bandwidth information by circling through the deadline tasks held in

[PATCH V3 05/10] cpuset: Rebuild root domain deadline accounting information

When the topology of root domains is modified by CPUset or CPUhotplug operations information about the current deadline bandwidth held in the root domain is lost. This patch address the issue by recalculating the lost deadline bandwidth information by circling through the deadline tasks held in

[PATCH V3 10/10] sched/deadline: Prevent CPU hotplug operation if DL task on CPU

When a DL task is assigned a CPU the "utilisation" (this_bw) and the "active utilisation" (running_bw) fields of rq->dl are incremented accordingly. If the CPU is hotplugged out the DL task is transferred to another CPU but the task's contribution to this_bw and running_bw isn't substracted from

[PATCH V3 06/10] sched/deadline: Keep new DL task within root domain's boundary

When considering to move a task to the DL policy we need to make sure the CPUs it is allowed to run on matches the CPUs of the root domain of the runqueue it is currently assigned to. Otherwise the task will be allowed to roam on CPUs outside of this root domain, something that will skew system

[PATCH V3 09/10] sched/core: Don't change the affinity of DL tasks

Now that we mandate that on creation, the ->cpus_allowed mask of a future DL task has to be equal to the rd->span of the root domain it will be associated with, changing the affinity of a DL task doesn't make sense anymore. Indeed, if we set the task to a smaller affinity set then we may be

[PATCH V3 10/10] sched/deadline: Prevent CPU hotplug operation if DL task on CPU

When a DL task is assigned a CPU the "utilisation" (this_bw) and the "active utilisation" (running_bw) fields of rq->dl are incremented accordingly. If the CPU is hotplugged out the DL task is transferred to another CPU but the task's contribution to this_bw and running_bw isn't substracted from

[PATCH V3 06/10] sched/deadline: Keep new DL task within root domain's boundary

When considering to move a task to the DL policy we need to make sure the CPUs it is allowed to run on matches the CPUs of the root domain of the runqueue it is currently assigned to. Otherwise the task will be allowed to roam on CPUs outside of this root domain, something that will skew system

[PATCH V3 09/10] sched/core: Don't change the affinity of DL tasks

Now that we mandate that on creation, the ->cpus_allowed mask of a future DL task has to be equal to the rd->span of the root domain it will be associated with, changing the affinity of a DL task doesn't make sense anymore. Indeed, if we set the task to a smaller affinity set then we may be

[PATCH V3 08/10] cgroup: Constrain the addition of CPUs to a new CPUset

Care must be taken when CPUs are added to a new CPUset. If an ancestor of that set has its sched_load_balance flag switch off then the CPUs in the new CPUset will be added to a new root domain. If the ancestor also had DL tasks those will end up covering more than one root domain, breaking at

[PATCH V3 08/10] cgroup: Constrain the addition of CPUs to a new CPUset

Care must be taken when CPUs are added to a new CPUset. If an ancestor of that set has its sched_load_balance flag switch off then the CPUs in the new CPUset will be added to a new root domain. If the ancestor also had DL tasks those will end up covering more than one root domain, breaking at

[PATCH V3 02/10] sched/topology: Adding function partition_sched_domains_locked()

Introducing function partition_sched_domains_locked() by taking the mutex locking code out of the original function. That way the work done by partition_sched_domains_locked() can be reused without dropping the mutex lock. No change of functionality is introduced by this patch. Signed-off-by:

[PATCH V3 02/10] sched/topology: Adding function partition_sched_domains_locked()

Introducing function partition_sched_domains_locked() by taking the mutex locking code out of the original function. That way the work done by partition_sched_domains_locked() can be reused without dropping the mutex lock. No change of functionality is introduced by this patch. Signed-off-by:

[PATCH V3 00/10] sched/deadline: fix cpusets bandwidth accounting

This is the third installment of a patchset that attempt to fix a problem reported by Steve Rostedt [1] where DL bandwidth accounting is not recomputed after CPUset and CPU hotplug operations took place. When CPU hotplug and some CUPset manipulation take place root domains are destroyed and new

[PATCH V3 00/10] sched/deadline: fix cpusets bandwidth accounting

This is the third installment of a patchset that attempt to fix a problem reported by Steve Rostedt [1] where DL bandwidth accounting is not recomputed after CPUset and CPU hotplug operations took place. When CPU hotplug and some CUPset manipulation take place root domains are destroyed and new

Re: [RESEND PATCH] rtc: Fix overflow when converting time64_t to rtc_time

On 26/01/2018 at 13:06:01 +0800, Baolin Wang wrote: > If we convert one large time values to rtc_time, in the original formula > 'days * 86400' can be overflowed in 'unsigned int' type to make the formula > get one incorrect remain seconds value. Thus we can use div_s64_rem() > function to avoid

Re: [RESEND PATCH] rtc: Fix overflow when converting time64_t to rtc_time

On 26/01/2018 at 13:06:01 +0800, Baolin Wang wrote: > If we convert one large time values to rtc_time, in the original formula > 'days * 86400' can be overflowed in 'unsigned int' type to make the formula > get one incorrect remain seconds value. Thus we can use div_s64_rem() > function to avoid

Re: [PATCH v3] rtc: Add tracepoints for RTC system

On 14/12/2017 at 13:31:43 +0800, Baolin Wang wrote: > It will be more helpful to add some tracepoints to track RTC actions when > debugging RTC driver. Below sample is that we set/read the RTC time, then > set 2 alarms, so we can see the trace logs: > > set/read RTC time: > kworker/0:1-67 [000]

Re: [PATCH v3] rtc: Add tracepoints for RTC system

On 14/12/2017 at 13:31:43 +0800, Baolin Wang wrote: > It will be more helpful to add some tracepoints to track RTC actions when > debugging RTC driver. Below sample is that we set/read the RTC time, then > set 2 alarms, so we can see the trace logs: > > set/read RTC time: > kworker/0:1-67 [000]

[PATCH 2/2] dma/ppc4xx: Improve a size determination in ppc440spe_adma_alloc_chan_resources()

From: Markus Elfring Date: Tue, 13 Feb 2018 20:54:30 +0100 Replace the specification of a data structure by a pointer dereference as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style

[PATCH 2/2] dma/ppc4xx: Improve a size determination in ppc440spe_adma_alloc_chan_resources()

From: Markus Elfring Date: Tue, 13 Feb 2018 20:54:30 +0100 Replace the specification of a data structure by a pointer dereference as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style convention. This issue was

[PATCH 1/2] dma/ppc4xx: Delete an error message for a failed memory allocation in two functions

From: Markus Elfring Date: Tue, 13 Feb 2018 20:42:40 +0100 Omit an extra message for a memory allocation failure in these functions. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

[PATCH 1/2] dma/ppc4xx: Delete an error message for a failed memory allocation in two functions

From: Markus Elfring Date: Tue, 13 Feb 2018 20:42:40 +0100 Omit an extra message for a memory allocation failure in these functions. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/dma/ppc4xx/adma.c | 2 -- 1 file changed, 2 deletions(-)

[PATCH 0/2] DMA-PPC4xx: Adjustments for three function implementations

From: Markus Elfring Date: Tue, 13 Feb 2018 21:16:42 +0100 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an error message for a failed memory allocation in two functions Improve a size determination

[PATCH 0/2] DMA-PPC4xx: Adjustments for three function implementations

From: Markus Elfring Date: Tue, 13 Feb 2018 21:16:42 +0100 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an error message for a failed memory allocation in two functions Improve a size determination in

Re: [PATCH -next 0/3] sysvipc: introduce STAT_ALL commands

Davidlohr Bueso writes: > Hi, > > The following patches adds the discussed[1] new command for shm > as well as for sems and msq as they are subject to the same discrepancies > for ipc object permission checks between the syscall and via procfs. > These new commands are

Re: [PATCH -next 0/3] sysvipc: introduce STAT_ALL commands

Davidlohr Bueso writes: > Hi, > > The following patches adds the discussed[1] new command for shm > as well as for sems and msq as they are subject to the same discrepancies > for ipc object permission checks between the syscall and via procfs. > These new commands are justified in that (1) we

Re: [PATCH v10 0/3] arm: npcm: add basic support for Nuvoton BMCs

On 02/13/2018 12:09 PM, Brendan Higgins wrote: > Addressed comments from: > - Joel: https://www.spinics.net/lists/arm-kernel/msg634074.html > - Arnd: https://www.spinics.net/lists/arm-kernel/msg634091.html > > Summary of changes since previous update: > - Replaced "nuvoton,npcm7xx-smp"

Re: [PATCH v10 0/3] arm: npcm: add basic support for Nuvoton BMCs

On 02/13/2018 12:09 PM, Brendan Higgins wrote: > Addressed comments from: > - Joel: https://www.spinics.net/lists/arm-kernel/msg634074.html > - Arnd: https://www.spinics.net/lists/arm-kernel/msg634091.html > > Summary of changes since previous update: > - Replaced "nuvoton,npcm7xx-smp"

[PATCH 08/19 - v2] staging: lustre: simplify waiting in ldlm_completion_ast()

If a signal-callback (lwi_on_signal) is set without lwi_allow_intr, as is the case in ldlm_completion_ast(), the behavior depends on the timeout set. If a timeout is set, then signals are ignored. If the timeout is reached, the timeout handler is called. If the timeout handler return 0, which

[PATCH 08/19 - v2] staging: lustre: simplify waiting in ldlm_completion_ast()

If a signal-callback (lwi_on_signal) is set without lwi_allow_intr, as is the case in ldlm_completion_ast(), the behavior depends on the timeout set. If a timeout is set, then signals are ignored. If the timeout is reached, the timeout handler is called. If the timeout handler return 0, which

Re: BUG: free active (active state 0) object type: work_struct hint: strp_work

On Thu, Jan 4, 2018 at 8:36 PM, Tom Herbert wrote: > On Thu, Jan 4, 2018 at 4:10 AM, syzbot > wrote: >> Hello, >> >> syzkaller hit the following crash on >> 6bb8824732f69de0f233ae6b1a8158e149627b38 >>

Re: BUG: free active (active state 0) object type: work_struct hint: strp_work

On Thu, Jan 4, 2018 at 8:36 PM, Tom Herbert wrote: > On Thu, Jan 4, 2018 at 4:10 AM, syzbot > wrote: >> Hello, >> >> syzkaller hit the following crash on >> 6bb8824732f69de0f233ae6b1a8158e149627b38 >> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master >> compiler: gcc (GCC)

Re: [PATCH] lib/scatterlist: Make sg_page_count() accessible to other modules

On Sat, Feb 10, 2018 at 8:06 PM, Alexey Skidanov wrote: > Currently, sg_page_count() may be used only inside the scatterlist.c file. > > However, the same calculation is done outside of scatterlist.c file > causing to code duplication. > > To fix this, we move the

Re: [PATCH] lib/scatterlist: Make sg_page_count() accessible to other modules

On Sat, Feb 10, 2018 at 8:06 PM, Alexey Skidanov wrote: > Currently, sg_page_count() may be used only inside the scatterlist.c file. > > However, the same calculation is done outside of scatterlist.c file > causing to code duplication. > > To fix this, we move the sg_page_count() to the

[PATCH v1 4/4] platform/x86: mlx-platform: Add physical bus number auto detection

Add physical bus number auto detection mechanism in order to avoid a possible collision with I2C physical bus allocation. The mlx-platform driver activates i2c-mlxcpld driver with no bus number specification. It based on an assumption that on all Mellanox systems physical bus number is supposed to

[PATCH v1 4/4] platform/x86: mlx-platform: Add physical bus number auto detection

Add physical bus number auto detection mechanism in order to avoid a possible collision with I2C physical bus allocation. The mlx-platform driver activates i2c-mlxcpld driver with no bus number specification. It based on an assumption that on all Mellanox systems physical bus number is supposed to

[PATCH v1 2/4] platform/x86: mlx-platform: Add differed bus functionality

Add deferred bus functionality in order to enforce probing flow execution order. Driver mlx-platform activates platform driver i2c-mux-reg, which creates busses infrastructure, after that it activates mlxreg-hotplug driver, which uses these busses, for connecting devices. The possible

[PATCH v1 2/4] platform/x86: mlx-platform: Add differed bus functionality

Add deferred bus functionality in order to enforce probing flow execution order. Driver mlx-platform activates platform driver i2c-mux-reg, which creates busses infrastructure, after that it activates mlxreg-hotplug driver, which uses these busses, for connecting devices. The possible

[PATCH v1 1/4] platform/x86: mlx-platform: Use define for the channel numbers

Add define for the channels number for mux device, instead of using hardcoded value inside the code in order to improve code readability. Signed-off-by: Vadim Pasternak --- drivers/platform/x86/mlx-platform.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff

[PATCH v1 1/4] platform/x86: mlx-platform: Use define for the channel numbers

Add define for the channels number for mux device, instead of using hardcoded value inside the code in order to improve code readability. Signed-off-by: Vadim Pasternak --- drivers/platform/x86/mlx-platform.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git

[PATCH v1 0/4] platform/x86: mlx-platform: Add bus differed and auto detection functionalities

This patchset: - Adds define for the channels number for mux device. - Adds differed bus functionality. - Changes input for device create routine in mlxreg-hotplug driver. - Adds physical bus number auto detection. Vadim Pasternak (4): platform/x86: mlx-platform: Use define for the channel

[PATCH v1 0/4] platform/x86: mlx-platform: Add bus differed and auto detection functionalities

This patchset: - Adds define for the channels number for mux device. - Adds differed bus functionality. - Changes input for device create routine in mlxreg-hotplug driver. - Adds physical bus number auto detection. Vadim Pasternak (4): platform/x86: mlx-platform: Use define for the channel

[PATCH v1 3/4] platform/mellanox: mlxreg-hotplug: Change input for device create routine

Change the first input parameter in mlxreg_hotplug_device_create to the pointer to mlxreg_hotplug private data in order to allow to use the fields from the private data structure inside this routine. Signed-off-by: Vadim Pasternak ---

[PATCH v1 3/4] platform/mellanox: mlxreg-hotplug: Change input for device create routine

Change the first input parameter in mlxreg_hotplug_device_create to the pointer to mlxreg_hotplug private data in order to allow to use the fields from the private data structure inside this routine. Signed-off-by: Vadim Pasternak --- drivers/platform/mellanox/mlxreg-hotplug.c | 12 ++--

[martinbrandenburg:for-next 13/13] fs/orangefs/super.c:153:5: sparse: symbol 'orangefs_write_inode' was not declared. Should it be static?

tree: https://github.com/martinbrandenburg/linux for-next head: 525e7273bc80995f5bcfdc2780b870aa3ab37a18 commit: 525e7273bc80995f5bcfdc2780b870aa3ab37a18 [13/13] orangefs: let setattr write to cached inode reproduce: # apt-get install sparse git checkout

[martinbrandenburg:for-next 13/13] fs/orangefs/super.c:153:5: sparse: symbol 'orangefs_write_inode' was not declared. Should it be static?

tree: https://github.com/martinbrandenburg/linux for-next head: 525e7273bc80995f5bcfdc2780b870aa3ab37a18 commit: 525e7273bc80995f5bcfdc2780b870aa3ab37a18 [13/13] orangefs: let setattr write to cached inode reproduce: # apt-get install sparse git checkout

Re: KASAN: use-after-free Read in rds_find_bound

On Sat, Dec 30, 2017 at 8:41 PM, santosh.shilim...@oracle.com wrote: > On 12/30/17 1:17 AM, syzbot wrote: >> >> Hello, >> >> syzkaller hit the following crash on >> fba961ab29e5ffb055592442808bb0f7962e05da >>

Re: KASAN: use-after-free Read in rds_find_bound

On Sat, Dec 30, 2017 at 8:41 PM, santosh.shilim...@oracle.com wrote: > On 12/30/17 1:17 AM, syzbot wrote: >> >> Hello, >> >> syzkaller hit the following crash on >> fba961ab29e5ffb055592442808bb0f7962e05da >> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master >> compiler: gcc

[RFC PATCH martinbrandenburg] orangefs: orangefs_write_inode() can be static

Fixes: 525e7273bc80 ("orangefs: let setattr write to cached inode") Signed-off-by: Fengguang Wu --- super.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/orangefs/super.c b/fs/orangefs/super.c index 49bb1ce..c38310c 100644 ---

[RFC PATCH martinbrandenburg] orangefs: orangefs_write_inode() can be static

Fixes: 525e7273bc80 ("orangefs: let setattr write to cached inode") Signed-off-by: Fengguang Wu --- super.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/orangefs/super.c b/fs/orangefs/super.c index 49bb1ce..c38310c 100644 --- a/fs/orangefs/super.c +++

[PATCH v10 3/3] MAINTAINERS: Add entry for the Nuvoton NPCM architecture

Add maintainers and reviewers for the Nuvoton NPCM architecture. Signed-off-by: Brendan Higgins Reviewed-by: Tomer Maimon Reviewed-by: Avi Fishman --- MAINTAINERS | 14 ++ 1 file changed, 14 insertions(+)

[PATCH v10 3/3] MAINTAINERS: Add entry for the Nuvoton NPCM architecture

Add maintainers and reviewers for the Nuvoton NPCM architecture. Signed-off-by: Brendan Higgins Reviewed-by: Tomer Maimon Reviewed-by: Avi Fishman --- MAINTAINERS | 14 ++ 1 file changed, 14 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 44cb004c765d..2fa95aba0f7f

[PATCH v10 1/3] arm: npcm: add basic support for Nuvoton BMCs

Adds basic support for the Nuvoton NPCM750 BMC. Signed-off-by: Brendan Higgins Reviewed-by: Tomer Maimon Reviewed-by: Avi Fishman Tested-by: Tomer Maimon Tested-by: Avi Fishman

[PATCH v10 1/3] arm: npcm: add basic support for Nuvoton BMCs

Adds basic support for the Nuvoton NPCM750 BMC. Signed-off-by: Brendan Higgins Reviewed-by: Tomer Maimon Reviewed-by: Avi Fishman Tested-by: Tomer Maimon Tested-by: Avi Fishman --- arch/arm/Kconfig | 2 ++ arch/arm/Makefile| 1 + arch/arm/mach-npcm/Kconfig | 48

[PATCH v10 2/3] arm: dts: add Nuvoton NPCM750 device tree

Add a common device tree for all Nuvoton NPCM750 BMCs and a board specific device tree for the NPCM750 (Poleg) evaluation board. Signed-off-by: Brendan Higgins Reviewed-by: Tomer Maimon Reviewed-by: Avi Fishman

[PATCH v10 2/3] arm: dts: add Nuvoton NPCM750 device tree

Add a common device tree for all Nuvoton NPCM750 BMCs and a board specific device tree for the NPCM750 (Poleg) evaluation board. Signed-off-by: Brendan Higgins Reviewed-by: Tomer Maimon Reviewed-by: Avi Fishman Reviewed-by: Joel Stanley Reviewed-by: Rob Herring Tested-by: Tomer Maimon

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