Re: [patch-rt] sched,fair: Fix CFS bandwidth control lockdep DEADLOCK report

On Fri, 04 May 2018 08:14:38 +0200 Mike Galbraith wrote: > CFS bandwidth control yields the inversion gripe below, moving > handling quells it. > > > WARNING: possible irq lock inversion dependency detected > 4.16.7-rt1-rt

Re: [patch-rt] sched,fair: Fix CFS bandwidth control lockdep DEADLOCK report

On Fri, 04 May 2018 08:14:38 +0200 Mike Galbraith wrote: > CFS bandwidth control yields the inversion gripe below, moving > handling quells it. > > > WARNING: possible irq lock inversion dependency detected > 4.16.7-rt1-rt #2 Tainted: G

[GIT PULL] Btrfs updates for 4.17-rc3

Hi, please pull the following branch with 2 regression fixes and one fix for stable. Thanks. The following changes since commit c0872323746e11fc79344e3738b283a8cda86654: btrfs: print-tree: debugging output enhancement

[GIT PULL] Btrfs updates for 4.17-rc3

Hi, please pull the following branch with 2 regression fixes and one fix for stable. Thanks. The following changes since commit c0872323746e11fc79344e3738b283a8cda86654: btrfs: print-tree: debugging output enhancement

[PATCH] ntfs: don't disable interrupts during kmap_atomic()

ntfs_end_buffer_async_read() disables interrupts around kmap_atomic(). This is a leftover from the old kmap_atomic() implementation which relied on fixed mapping slots, so the caller had to make sure that the same slot could not be reused from an interrupting context. kmap_atomic() was changed to

[PATCH] ntfs: don't disable interrupts during kmap_atomic()

ntfs_end_buffer_async_read() disables interrupts around kmap_atomic(). This is a leftover from the old kmap_atomic() implementation which relied on fixed mapping slots, so the caller had to make sure that the same slot could not be reused from an interrupting context. kmap_atomic() was changed to

Re: [PATCH 2/3] kcov: prefault the kcov_area

On 05/04/2018 05:38 PM, Mark Rutland wrote: > On Fri, May 04, 2018 at 05:36:49PM +0300, Andrey Ryabinin wrote: >> >> >> On 05/04/2018 04:55 PM, Mark Rutland wrote: >> >>> >>> +static void kcov_fault_in_area(struct kcov *kcov) >>> +{ >>> + unsigned long stride = PAGE_SIZE / sizeof(unsigned

Re: [PATCH 2/3] kcov: prefault the kcov_area

On 05/04/2018 05:38 PM, Mark Rutland wrote: > On Fri, May 04, 2018 at 05:36:49PM +0300, Andrey Ryabinin wrote: >> >> >> On 05/04/2018 04:55 PM, Mark Rutland wrote: >> >>> >>> +static void kcov_fault_in_area(struct kcov *kcov) >>> +{ >>> + unsigned long stride = PAGE_SIZE / sizeof(unsigned

[PATCH v2] rdmacg: Convert to use match_string() helper

The new helper returns index of the matching string in an array. We are going to use it here. Signed-off-by: Andy Shevchenko --- - fix compile error kernel/cgroup/rdma.c | 35 --- 1 file changed, 16 insertions(+), 19

[PATCH v2] rdmacg: Convert to use match_string() helper

The new helper returns index of the matching string in an array. We are going to use it here. Signed-off-by: Andy Shevchenko --- - fix compile error kernel/cgroup/rdma.c | 35 --- 1 file changed, 16 insertions(+), 19 deletions(-) diff --git

[PATCH v2 1/3] drm/tegra: dc: Enable plane scaling filters

Currently resized plane produces a "pixelated" image which doesn't look nice, especially in a case of a video overlay. Enable scaling filters that significantly improve image quality of a scaled overlay. Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/tegra/dc.c | 81

[PATCH v2 1/3] drm/tegra: dc: Enable plane scaling filters

Currently resized plane produces a "pixelated" image which doesn't look nice, especially in a case of a video overlay. Enable scaling filters that significantly improve image quality of a scaled overlay. Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/tegra/dc.c | 81

[PATCH v2 2/3] drm/tegra: plane: Implement zPos plane property for older Tegra's

Older Tegra's do not support planes z position handling in hardware, but HW provides knobs for zPos implementation in software. Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/tegra/dc.c| 134 --- drivers/gpu/drm/tegra/plane.c | 193

[PATCH v2 2/3] drm/tegra: plane: Implement zPos plane property for older Tegra's

Older Tegra's do not support planes z position handling in hardware, but HW provides knobs for zPos implementation in software. Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/tegra/dc.c| 134 --- drivers/gpu/drm/tegra/plane.c | 193 --

[PATCH v2 3/3] drm/tegra: dc: Rename supports_blending to has_legacy_blending

Older Tegra's support blending. Rename SoC info entry supports_blending to has_legacy_blending to eliminate confusion. Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/tegra/dc.c | 20 ++-- drivers/gpu/drm/tegra/dc.h | 2 +- 2 files changed, 11

[PATCH v2 3/3] drm/tegra: dc: Rename supports_blending to has_legacy_blending

Older Tegra's support blending. Rename SoC info entry supports_blending to has_legacy_blending to eliminate confusion. Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/tegra/dc.c | 20 ++-- drivers/gpu/drm/tegra/dc.h | 2 +- 2 files changed, 11 insertions(+), 11 deletions(-)

[PATCH v2 0/3] Couple more DRM plane features for Tegra

Hi, This series improves DRM plane support by supporting zPos on older Tegra's and enabling plane scaling filters (up to Tegra210). Changelog: v2: - Addressed v1 review comments. Dmitry Osipenko (3): drm/tegra: dc: Enable plane scaling filters drm/tegra: plane: Implement zPos plane

[PATCH v2 0/3] Couple more DRM plane features for Tegra

Hi, This series improves DRM plane support by supporting zPos on older Tegra's and enabling plane scaling filters (up to Tegra210). Changelog: v2: - Addressed v1 review comments. Dmitry Osipenko (3): drm/tegra: dc: Enable plane scaling filters drm/tegra: plane: Implement zPos plane

[PATCH] kernel/signal: Remove no longer required irqsave/restore

From: Anna-Maria Gleixner Commit a841796f11c9 ("signal: align __lock_task_sighand() irq disabling and RCU") introduced a rcu read side critical section with interrupts disabled. The changelog suggested that a better long-term fix would be "to make rt_mutex_unlock()

[PATCH] kernel/signal: Remove no longer required irqsave/restore

From: Anna-Maria Gleixner Commit a841796f11c9 ("signal: align __lock_task_sighand() irq disabling and RCU") introduced a rcu read side critical section with interrupts disabled. The changelog suggested that a better long-term fix would be "to make rt_mutex_unlock() disable irqs when acquiring

Re: [PATCH 2/3] kcov: prefault the kcov_area

On Fri, May 04, 2018 at 05:36:49PM +0300, Andrey Ryabinin wrote: > > > On 05/04/2018 04:55 PM, Mark Rutland wrote: > > > > > +static void kcov_fault_in_area(struct kcov *kcov) > > +{ > > + unsigned long stride = PAGE_SIZE / sizeof(unsigned long); > > + unsigned long *area = kcov->area; >

Re: [PATCH 2/3] kcov: prefault the kcov_area

On Fri, May 04, 2018 at 05:36:49PM +0300, Andrey Ryabinin wrote: > > > On 05/04/2018 04:55 PM, Mark Rutland wrote: > > > > > +static void kcov_fault_in_area(struct kcov *kcov) > > +{ > > + unsigned long stride = PAGE_SIZE / sizeof(unsigned long); > > + unsigned long *area = kcov->area; >

Re: [PATCH v2] apparmor: secid: fix error return value in error handling path

Hi Gustavo, if you are using the coverity scan bug tracking, please can you mark a bug as being worked on by yourself so I don't work on it at the same time as we're duplicating work here. Colin On 04/05/18 15:09, Gustavo A. R. Silva wrote: > Currently, function apparmor_secid_to_secctx returns

Re: [PATCH v2] apparmor: secid: fix error return value in error handling path

Hi Gustavo, if you are using the coverity scan bug tracking, please can you mark a bug as being worked on by yourself so I don't work on it at the same time as we're duplicating work here. Colin On 04/05/18 15:09, Gustavo A. R. Silva wrote: > Currently, function apparmor_secid_to_secctx returns

Re: [PATCH] memcg: Replace mm->owner with mm->memcg

Oleg Nesterov writes: > On 05/03, Eric W. Biederman wrote: >> >> Oleg Nesterov writes: >> >> > On 05/02, Eric W. Biederman wrote: >> >> >> >> +static void mem_cgroup_fork(struct task_struct *tsk) >> >> +{ >> >> + struct cgroup_subsys_state *css; >> >> + >> >> +

Re: [PATCH] memcg: Replace mm->owner with mm->memcg

Oleg Nesterov writes: > On 05/03, Eric W. Biederman wrote: >> >> Oleg Nesterov writes: >> >> > On 05/02, Eric W. Biederman wrote: >> >> >> >> +static void mem_cgroup_fork(struct task_struct *tsk) >> >> +{ >> >> + struct cgroup_subsys_state *css; >> >> + >> >> + rcu_read_lock(); >> >> + css =

Re: [PATCH 3/3] sched/core / kcov: avoid kcov_area during task switch

On Fri, May 04, 2018 at 05:32:26PM +0300, Andrey Ryabinin wrote: > On 05/04/2018 04:55 PM, Mark Rutland wrote: > > > +#define kcov_prepare_switch(t) \ > > +do { \ > > + (t)->kcov_mode |= KCOV_IN_CTXSW;\ > > +} while (0) >

Re: [PATCH 3/3] sched/core / kcov: avoid kcov_area during task switch

On Fri, May 04, 2018 at 05:32:26PM +0300, Andrey Ryabinin wrote: > On 05/04/2018 04:55 PM, Mark Rutland wrote: > > > +#define kcov_prepare_switch(t) \ > > +do { \ > > + (t)->kcov_mode |= KCOV_IN_CTXSW;\ > > +} while (0) >

Re: perf: fuzzer causes stack going in wrong direction warnings

On Wed, 2 May 2018, Josh Poimboeuf wrote: > After looking closer, I realized that at least some of these warnings > are due to bad unwind hints in the entry code. Can you try this patch > instead of the last one? with just this new patch applied I still get warnings such as this: [

Re: perf: fuzzer causes stack going in wrong direction warnings

On Wed, 2 May 2018, Josh Poimboeuf wrote: > After looking closer, I realized that at least some of these warnings > are due to bad unwind hints in the entry code. Can you try this patch > instead of the last one? with just this new patch applied I still get warnings such as this: [

Re: [PATCH 2/3] kcov: prefault the kcov_area

On 05/04/2018 04:55 PM, Mark Rutland wrote: > > +static void kcov_fault_in_area(struct kcov *kcov) > +{ > + unsigned long stride = PAGE_SIZE / sizeof(unsigned long); > + unsigned long *area = kcov->area; > + unsigned long offset; > + > + for (offset = 0; offset < kcov->size;

Re: [PATCH 2/3] kcov: prefault the kcov_area

On 05/04/2018 04:55 PM, Mark Rutland wrote: > > +static void kcov_fault_in_area(struct kcov *kcov) > +{ > + unsigned long stride = PAGE_SIZE / sizeof(unsigned long); > + unsigned long *area = kcov->area; > + unsigned long offset; > + > + for (offset = 0; offset < kcov->size;

Re: [RFC PATCH for 4.18 12/23] cpu_opv: Provide cpu_opv system call (v7)

- On Apr 16, 2018, at 4:58 PM, Mathieu Desnoyers mathieu.desnoy...@efficios.com wrote: > - On Apr 16, 2018, at 3:26 PM, Linus Torvalds > torva...@linux-foundation.org > wrote: > >> On Mon, Apr 16, 2018 at 12:21 PM, Mathieu Desnoyers >> wrote: >>> >>>

Re: [RFC PATCH for 4.18 12/23] cpu_opv: Provide cpu_opv system call (v7)

- On Apr 16, 2018, at 4:58 PM, Mathieu Desnoyers mathieu.desnoy...@efficios.com wrote: > - On Apr 16, 2018, at 3:26 PM, Linus Torvalds > torva...@linux-foundation.org > wrote: > >> On Mon, Apr 16, 2018 at 12:21 PM, Mathieu Desnoyers >> wrote: >>> >>> And I try very hard to avoid being

[PATCH v2 0/4] Introduce LSM-hook for socketpair(2)

Hi This is v2 of the socketpair(2) LSM hook introduction. Changes since v1 are: - Added ACKs from previous series. - Moved the hook into generic socketpair(2) handling. The hook is now called security_socket_socketpair(), just like the other hooks on the socket layer. There is

[PATCH v2 0/4] Introduce LSM-hook for socketpair(2)

Hi This is v2 of the socketpair(2) LSM hook introduction. Changes since v1 are: - Added ACKs from previous series. - Moved the hook into generic socketpair(2) handling. The hook is now called security_socket_socketpair(), just like the other hooks on the socket layer. There is

Re: [PATCH 3/3] sched/core / kcov: avoid kcov_area during task switch

On 05/04/2018 04:55 PM, Mark Rutland wrote: > +#define kcov_prepare_switch(t) \ > +do { \ > + (t)->kcov_mode |= KCOV_IN_CTXSW;\ > +} while (0) > + > +#define kcov_finish_switch(t)\ > +do {

Re: [PATCH 3/3] sched/core / kcov: avoid kcov_area during task switch

On 05/04/2018 04:55 PM, Mark Rutland wrote: > +#define kcov_prepare_switch(t) \ > +do { \ > + (t)->kcov_mode |= KCOV_IN_CTXSW;\ > +} while (0) > + > +#define kcov_finish_switch(t)\ > +do {

[PATCH v2 3/4] selinux: provide socketpair callback

Make sure to implement the new socketpair callback so the SO_PEERSEC call on socketpair(2)s will return correct information. Acked-by: Serge Hallyn Acked-by: Stephen Smalley Signed-off-by: Tom Gundersen Signed-off-by: David Herrmann

[PATCH v2 3/4] selinux: provide socketpair callback

Make sure to implement the new socketpair callback so the SO_PEERSEC call on socketpair(2)s will return correct information. Acked-by: Serge Hallyn Acked-by: Stephen Smalley Signed-off-by: Tom Gundersen Signed-off-by: David Herrmann --- security/selinux/hooks.c | 13 + 1 file

Re: [PATCH 4/7] dt-bindings: gnss: add u-blox binding

* Sebastian Reichel [180504 13:40]: > Hi, > > On Fri, May 04, 2018 at 02:04:15PM +0200, H. Nikolaus Schaller wrote: > > > Am 04.05.2018 um 13:42 schrieb Sebastian Reichel : > > >> I think it does not need much more (if at all) than a gpio controller on > > >>

Re: [PATCH v3 0/9] trace_uprobe: Support SDT markers having reference count (semaphore)

Sorry Ravi, I saved the new version for review and forgot about it... I'll try to do this on weekend. On 05/03, Ravi Bangoria wrote: > > On 04/17/2018 10:02 AM, Ravi Bangoria wrote: > > Userspace Statically Defined Tracepoints[1] are dtrace style markers > > inside userspace applications.

Re: [PATCH 4/7] dt-bindings: gnss: add u-blox binding

* Sebastian Reichel [180504 13:40]: > Hi, > > On Fri, May 04, 2018 at 02:04:15PM +0200, H. Nikolaus Schaller wrote: > > > Am 04.05.2018 um 13:42 schrieb Sebastian Reichel : > > >> I think it does not need much more (if at all) than a gpio controller on > > >> the OMAP3 chip (I think the clocks

Re: [PATCH v3 0/9] trace_uprobe: Support SDT markers having reference count (semaphore)

Sorry Ravi, I saved the new version for review and forgot about it... I'll try to do this on weekend. On 05/03, Ravi Bangoria wrote: > > On 04/17/2018 10:02 AM, Ravi Bangoria wrote: > > Userspace Statically Defined Tracepoints[1] are dtrace style markers > > inside userspace applications.

[PATCH v2 4/4] smack: provide socketpair callback

From: Tom Gundersen Make sure to implement the new socketpair callback so the SO_PEERSEC call on socketpair(2)s will return correct information. Signed-off-by: Tom Gundersen Signed-off-by: David Herrmann --- security/smack/smack_lsm.c | 22

[PATCH v2 4/4] smack: provide socketpair callback

From: Tom Gundersen Make sure to implement the new socketpair callback so the SO_PEERSEC call on socketpair(2)s will return correct information. Signed-off-by: Tom Gundersen Signed-off-by: David Herrmann --- security/smack/smack_lsm.c | 22 ++ 1 file changed, 22

[PATCH v2 1/4] security: add hook for socketpair()

Right now the LSM labels for socketpairs are always uninitialized, since there is no security hook for the socketpair() syscall. This patch adds the required hooks so LSMs can properly label socketpairs. This allows SO_PEERSEC to return useful information on those sockets. Note that the behavior

[PATCH v2 1/4] security: add hook for socketpair()

Right now the LSM labels for socketpairs are always uninitialized, since there is no security hook for the socketpair() syscall. This patch adds the required hooks so LSMs can properly label socketpairs. This allows SO_PEERSEC to return useful information on those sockets. Note that the behavior

[PATCH v2 2/4] net: hook socketpair() into LSM

Use the newly created LSM-hook for socketpair(). The default hook return-value is 0, so behavior stays the same unless LSMs start using this hook. Acked-by: Serge Hallyn Signed-off-by: Tom Gundersen Signed-off-by: David Herrmann ---

[PATCH v2 2/4] net: hook socketpair() into LSM

Use the newly created LSM-hook for socketpair(). The default hook return-value is 0, so behavior stays the same unless LSMs start using this hook. Acked-by: Serge Hallyn Signed-off-by: Tom Gundersen Signed-off-by: David Herrmann --- net/socket.c | 7 +++ 1 file changed, 7 insertions(+)

Re: [PATCH 0/3] Introduce LSM-hook for socketpair(2)

Hey On Wed, Apr 25, 2018 at 9:02 PM, James Morris wrote: > On Wed, 25 Apr 2018, Paul Moore wrote: > >> On Wed, Apr 25, 2018 at 2:44 PM, James Morris wrote: >> > On Mon, 23 Apr 2018, David Herrmann wrote: >> >> This patch series tries to close this gap and

Re: [PATCH 0/3] Introduce LSM-hook for socketpair(2)

Hey On Wed, Apr 25, 2018 at 9:02 PM, James Morris wrote: > On Wed, 25 Apr 2018, Paul Moore wrote: > >> On Wed, Apr 25, 2018 at 2:44 PM, James Morris wrote: >> > On Mon, 23 Apr 2018, David Herrmann wrote: >> >> This patch series tries to close this gap and makes both behave the >> >> same. A new

[PATCH] Add a file named cgroup.procs_stat in cgroup

When I run "cat /proc/stat" in a container, container will access host's file directly which is a security risk. LXCFS is a good way to strengthen the isolation among containers. However, I can not get a container's correct status because LXCFS just transfer host's status to container. So I track

[PATCH] Add a file named cgroup.procs_stat in cgroup

When I run "cat /proc/stat" in a container, container will access host's file directly which is a security risk. LXCFS is a good way to strengthen the isolation among containers. However, I can not get a container's correct status because LXCFS just transfer host's status to container. So I track

Re: [PATCH v4 00/14] Copy Offload in NVMe Fabrics with P2P PCI Memory

Am 03.05.2018 um 20:43 schrieb Logan Gunthorpe: On 03/05/18 11:29 AM, Christian König wrote: Ok, that is the point where I'm stuck. Why do we need that in one function call in the PCIe subsystem? The problem at least with GPUs is that we seriously don't have that information here, cause the

Re: [PATCH v4 00/14] Copy Offload in NVMe Fabrics with P2P PCI Memory

Am 03.05.2018 um 20:43 schrieb Logan Gunthorpe: On 03/05/18 11:29 AM, Christian König wrote: Ok, that is the point where I'm stuck. Why do we need that in one function call in the PCIe subsystem? The problem at least with GPUs is that we seriously don't have that information here, cause the

Re: [PATCH v9 07/27] ARM: davinci: dm355: add new clock init using common clock framework

On 05/04/2018 05:01 AM, Sekhar Nori wrote: On Thursday 03 May 2018 09:14 PM, David Lechner wrote: On 05/03/2018 10:34 AM, Sekhar Nori wrote: On Friday 27 April 2018 05:47 AM, David Lechner wrote: This adds the new board-specific clock init in mach-davinci/dm355.c using the new common clock

Re: [PATCH v9 07/27] ARM: davinci: dm355: add new clock init using common clock framework

On 05/04/2018 05:01 AM, Sekhar Nori wrote: On Thursday 03 May 2018 09:14 PM, David Lechner wrote: On 05/03/2018 10:34 AM, Sekhar Nori wrote: On Friday 27 April 2018 05:47 AM, David Lechner wrote: This adds the new board-specific clock init in mach-davinci/dm355.c using the new common clock

[PATCH 3/4] ide: don't disable interrupts during kmap_atomic()

ide_pio_bytes() disables interrupts around kmap_atomic(). This is a leftover from the old kmap_atomic() implementation which relied on fixed mapping slots, so the caller had to make sure that the same slot could not be reused from an interrupting context. kmap_atomic() was changed to dynamic

[PATCH 3/4] ide: don't disable interrupts during kmap_atomic()

ide_pio_bytes() disables interrupts around kmap_atomic(). This is a leftover from the old kmap_atomic() implementation which relied on fixed mapping slots, so the caller had to make sure that the same slot could not be reused from an interrupting context. kmap_atomic() was changed to dynamic

[PATCH 2/4] ide: Handle irq disabling consistently

ide_timer_expiry() disables interrupt at function entry when acquiring hwif->lock. Before disabling the device interrupt it unlocks hwif->lock, but interrupts stay disabled. After the call to disable_irq() interrupts are disabled again, which is a pointless exercise. After the device irq handler

[PATCH 2/4] ide: Handle irq disabling consistently

ide_timer_expiry() disables interrupt at function entry when acquiring hwif->lock. Before disabling the device interrupt it unlocks hwif->lock, but interrupts stay disabled. After the call to disable_irq() interrupts are disabled again, which is a pointless exercise. After the device irq handler

[PATCH 4/4] ide: don't enable/disable interrupts in force threaded-IRQ mode

The interrupts are enabled/disabled so the interrupt handler can run with enabled interrupts while serving the interrupt and not lose other interrupts especially the timer tick. If the system runs with force-threaded interrupts then there is no need to enable the interrupts. Signed-off-by:

[PATCH 4/4] ide: don't enable/disable interrupts in force threaded-IRQ mode

The interrupts are enabled/disabled so the interrupt handler can run with enabled interrupts while serving the interrupt and not lose other interrupts especially the timer tick. If the system runs with force-threaded interrupts then there is no need to enable the interrupts. Signed-off-by:

[PATCH 1/4] alim15x3: move irq-restore before pci_dev_put()

init_chipset_ali15x3() initializes the chipset during init with disabled interrupts. There is no need to keep the interrupts disabled during pci_dev_put(). Move the irq-restore before pci_dev_put() is invoked. Side note: The same init is performed in drivers/ata/pata_ali.c::ali_init_chipset()

[PATCH 1/4] alim15x3: move irq-restore before pci_dev_put()

init_chipset_ali15x3() initializes the chipset during init with disabled interrupts. There is no need to keep the interrupts disabled during pci_dev_put(). Move the irq-restore before pci_dev_put() is invoked. Side note: The same init is performed in drivers/ata/pata_ali.c::ali_init_chipset()

[PATCH 0/4] avoid disabling interrupts where it is not required

This series avoids/limits disabling of interrupts in drivers/ide. This is from the -RT queue where it was reported initially (ata was not widespread back then) and it hurts -RT. While looking at alim15x3, there are some drivers which exist in both worlds (alim15x3 included was far as I can tell).

[PATCH 0/4] avoid disabling interrupts where it is not required

This series avoids/limits disabling of interrupts in drivers/ide. This is from the -RT queue where it was reported initially (ata was not widespread back then) and it hurts -RT. While looking at alim15x3, there are some drivers which exist in both worlds (alim15x3 included was far as I can tell).

[PATCH] clk: davinci: pll-dm355: fix SYSCLKn parent names

This fixes the parent clock names of the SYSCLKn clocks for the DM355 SoC in the TI DaVinici PLL clock driver. It appears that this name just didn't get updated to the correct name like the other SoCs during the driver's development. Reported-by: Sekhar Nori Signed-off-by: David

[PATCH] clk: davinci: pll-dm355: fix SYSCLKn parent names

This fixes the parent clock names of the SYSCLKn clocks for the DM355 SoC in the TI DaVinici PLL clock driver. It appears that this name just didn't get updated to the correct name like the other SoCs during the driver's development. Reported-by: Sekhar Nori Signed-off-by: David Lechner ---

Re: pciehp 0000:00:1c.0:pcie004: Timeout on hotplug command 0x1038 (issued 65284 msec ago)

On 2018-05-04 14:33, Bjorn Helgaas wrote: On Fri, May 04, 2018 at 07:37:40AM +0100, ok...@codeaurora.org wrote: On 2018-05-04 03:45, Bjorn Helgaas wrote: > On Thu, May 03, 2018 at 10:49:24AM +0200, Paul Menzel wrote: > > On 04/27/18 21:22, Bjorn Helgaas wrote: > > > [+cc Lukas, Sinan] > > > > >

Re: pciehp 0000:00:1c.0:pcie004: Timeout on hotplug command 0x1038 (issued 65284 msec ago)

On 2018-05-04 14:33, Bjorn Helgaas wrote: On Fri, May 04, 2018 at 07:37:40AM +0100, ok...@codeaurora.org wrote: On 2018-05-04 03:45, Bjorn Helgaas wrote: > On Thu, May 03, 2018 at 10:49:24AM +0200, Paul Menzel wrote: > > On 04/27/18 21:22, Bjorn Helgaas wrote: > > > [+cc Lukas, Sinan] > > > > >

Re: [PATCH 01/30] gcc-plugins: fix build condition of SANCOV plugin

Hi Kees, 2018-04-13 14:06 GMT+09:00 Masahiro Yamada : > Since commit d677a4d60193 ("Makefile: support flag > -fsanitizer-coverage=trace-cmp"), you miss to build the SANCOV > plugin under some circumstances. > > CONFIG_KCOV=y > CONFIG_KCOV_ENABLE_COMPARISONS=y >

Re: [PATCH 01/30] gcc-plugins: fix build condition of SANCOV plugin

Hi Kees, 2018-04-13 14:06 GMT+09:00 Masahiro Yamada : > Since commit d677a4d60193 ("Makefile: support flag > -fsanitizer-coverage=trace-cmp"), you miss to build the SANCOV > plugin under some circumstances. > > CONFIG_KCOV=y > CONFIG_KCOV_ENABLE_COMPARISONS=y > Your compiler does not

Re: [PATCH v3 6/9] trace_uprobe: Support SDT markers having reference count (semaphore)

Hi Masami, On 05/04/2018 10:18 AM, Masami Hiramatsu wrote: >> +void uprobe_down_write_dup_mmap(void) >> +{ >> +percpu_down_write(_mmap_sem); >> +} >> + >> +void uprobe_up_write_dup_mmap(void) >> +{ >> +percpu_up_write(_mmap_sem); >> +} >> + > I'm not sure why these hunks are not done in

Re: [PATCH v3 6/9] trace_uprobe: Support SDT markers having reference count (semaphore)

Hi Masami, On 05/04/2018 10:18 AM, Masami Hiramatsu wrote: >> +void uprobe_down_write_dup_mmap(void) >> +{ >> +percpu_down_write(_mmap_sem); >> +} >> + >> +void uprobe_up_write_dup_mmap(void) >> +{ >> +percpu_up_write(_mmap_sem); >> +} >> + > I'm not sure why these hunks are not done in

Re: [Ksummit-discuss] bug-introducing patches

Tony, Sasha, Mark On 4 May 2018 at 01:09, Tony Lindgren wrote: > * Mark Brown [180503 22:44]: >> On Wed, May 02, 2018 at 08:52:29PM -0700, Guenter Roeck wrote: >> >> > As for -next, me and others stopped reporting bugs in it, because when we >> > do >> >

Re: [Ksummit-discuss] bug-introducing patches

Tony, Sasha, Mark On 4 May 2018 at 01:09, Tony Lindgren wrote: > * Mark Brown [180503 22:44]: >> On Wed, May 02, 2018 at 08:52:29PM -0700, Guenter Roeck wrote: >> >> > As for -next, me and others stopped reporting bugs in it, because when we >> > do >> > we tend to get flamed for the "noise".

Re: [PATCH] memcg: Replace mm->owner with mm->memcg

On 05/03, Eric W. Biederman wrote: > > Oleg Nesterov writes: > > > On 05/02, Eric W. Biederman wrote: > >> > >> +static void mem_cgroup_fork(struct task_struct *tsk) > >> +{ > >> + struct cgroup_subsys_state *css; > >> + > >> + rcu_read_lock(); > >> + css = task_css(tsk,

Re: [PATCH] memcg: Replace mm->owner with mm->memcg

On 05/03, Eric W. Biederman wrote: > > Oleg Nesterov writes: > > > On 05/02, Eric W. Biederman wrote: > >> > >> +static void mem_cgroup_fork(struct task_struct *tsk) > >> +{ > >> + struct cgroup_subsys_state *css; > >> + > >> + rcu_read_lock(); > >> + css = task_css(tsk, memory_cgrp_id); > >>

Re: [PATCH] block: add verifier for cmdline partition

On 5/4/18 1:07 AM, Caizhiyong wrote: >> -Original Message- >> From: Wang YanQing [mailto:udkni...@gmail.com] >> Sent: Thursday, May 03, 2018 7:18 PM >> To: ax...@kernel.dk >> Cc: gre...@linuxfoundation.org; pombreda...@nexb.com; >> t...@linutronix.de; Caizhiyong ;

Re: [PATCH] block: add verifier for cmdline partition

On 5/4/18 1:07 AM, Caizhiyong wrote: >> -Original Message- >> From: Wang YanQing [mailto:udkni...@gmail.com] >> Sent: Thursday, May 03, 2018 7:18 PM >> To: ax...@kernel.dk >> Cc: gre...@linuxfoundation.org; pombreda...@nexb.com; >> t...@linutronix.de; Caizhiyong ; linux- >>

Re: [PATCH 5/5] hisi: Consolidate the Kconfigs for the CLOCK_STUB and the MAILBOX

On Wed, Apr 04, 2018 at 11:14:35AM +0800, Leo Yan wrote: > From: Daniel Lezcano > > The current defconfig is inconsistent as it selects the mailbox and > the clock for the hi6220 and the hi3660 without having their Kconfigs > making sure the dependencies are correct.

Re: [PATCH 5/5] hisi: Consolidate the Kconfigs for the CLOCK_STUB and the MAILBOX

On Wed, Apr 04, 2018 at 11:14:35AM +0800, Leo Yan wrote: > From: Daniel Lezcano > > The current defconfig is inconsistent as it selects the mailbox and > the clock for the hi6220 and the hi3660 without having their Kconfigs > making sure the dependencies are correct. It ends up when selecting >

[PATCHv4 4/7] dt-bindings: fpga: add Stratix10 SoC FPGA manager binding

From: Alan Tull Add a Device Tree binding for the Intel Stratix10 SoC FPGA manager. Signed-off-by: Alan Tull Signed-off-by: Richard Gong --- v2: this patch is added in patch set version 2 v3: change to put fpga_mgr node under

[PATCHv4 4/7] dt-bindings: fpga: add Stratix10 SoC FPGA manager binding

From: Alan Tull Add a Device Tree binding for the Intel Stratix10 SoC FPGA manager. Signed-off-by: Alan Tull Signed-off-by: Richard Gong --- v2: this patch is added in patch set version 2 v3: change to put fpga_mgr node under firmware/svc node v4: s/fpga-mgr@0/fpga-mgr/ to remove unit_address

[PATCHv4 6/7] fpga: add intel stratix10 soc fpga manager driver

From: Alan Tull Add driver for reconfiguring Intel Stratix10 SoC FPGA devices. This driver communicates through the Intel Service Driver which does communication with privileged hardware (that does the FPGA programming) through a secure mailbox. Signed-off-by: Alan Tull

[PATCHv4 6/7] fpga: add intel stratix10 soc fpga manager driver

From: Alan Tull Add driver for reconfiguring Intel Stratix10 SoC FPGA devices. This driver communicates through the Intel Service Driver which does communication with privileged hardware (that does the FPGA programming) through a secure mailbox. Signed-off-by: Alan Tull Signed-off-by: Richard

[PATCHv4 5/7] arm64: dts: stratix10: add fpga manager and region

From: Alan Tull Add the Stratix10 FPGA manager and a FPGA region to the device tree. Signed-off-by: Alan Tull Signed-off-by: Richard Gong --- v2: this patch is added in patch set version 2 v3: change to put fpga_mgr node under

[PATCHv4 7/7] defconfig: enable fpga and service layer

From: Richard Gong Enable fpga framework, Stratix 10 SoC FPGA manager and Stratix10 Service Layer Signed-off-by: Richard Gong Signed-off-by: Alan Tull --- v2: this patch is added in patch set version 2 v3: no change v4:

[PATCHv4 5/7] arm64: dts: stratix10: add fpga manager and region

From: Alan Tull Add the Stratix10 FPGA manager and a FPGA region to the device tree. Signed-off-by: Alan Tull Signed-off-by: Richard Gong --- v2: this patch is added in patch set version 2 v3: change to put fpga_mgr node under firmware/svc node v4: s/fpga-mgr@0/fpga-mgr/ to remove

[PATCHv4 7/7] defconfig: enable fpga and service layer

From: Richard Gong Enable fpga framework, Stratix 10 SoC FPGA manager and Stratix10 Service Layer Signed-off-by: Richard Gong Signed-off-by: Alan Tull --- v2: this patch is added in patch set version 2 v3: no change v4: s/CONFIG_INTEL_SERVICE/CONFIG_STRATIX10_SERVICE/ Add

[PATCHv4 1/7] dt-bindings, firmware: add Intel Stratix10 service layer binding

From: Richard Gong Add a device tree binding for the Intel Stratix10 service layer driver Signed-off-by: Richard Gong Signed-off-by: Alan Tull Reviewed-by: Rob Herring --- v2: Change to put service layer

[PATCHv4 2/7] arm64: dts: stratix10: add stratix10 service driver binding to base dtsi

From: Richard Gong Add Intel Stratix10 service layer to the device tree Signed-off-by: Richard Gong Signed-off-by: Alan Tull --- v2: Change to put service layer driver node under the firmware node Change compatible to

[PATCHv4 3/7] driver, misc: add Intel Stratix10 service layer driver

From: Richard Gong Some features of the Intel Stratix10 SoC require a level of privilege higher than the kernel is granted. Such secure features include FPGA programming. In terms of the ARMv8 architecture, the kernel runs at Exception Level 1 (EL1), access to the

[PATCHv4 1/7] dt-bindings, firmware: add Intel Stratix10 service layer binding

From: Richard Gong Add a device tree binding for the Intel Stratix10 service layer driver Signed-off-by: Richard Gong Signed-off-by: Alan Tull Reviewed-by: Rob Herring --- v2: Change to put service layer driver node under the firmware node Change compatible to "intel, stratix10-svc" v3:

[PATCHv4 2/7] arm64: dts: stratix10: add stratix10 service driver binding to base dtsi

From: Richard Gong Add Intel Stratix10 service layer to the device tree Signed-off-by: Richard Gong Signed-off-by: Alan Tull --- v2: Change to put service layer driver node under the firmware node Change compatible to "intel, stratix10-svc" v3: No change v4: s/service driver/stratix10

[PATCHv4 3/7] driver, misc: add Intel Stratix10 service layer driver

From: Richard Gong Some features of the Intel Stratix10 SoC require a level of privilege higher than the kernel is granted. Such secure features include FPGA programming. In terms of the ARMv8 architecture, the kernel runs at Exception Level 1 (EL1), access to the features requires Exception

[PATCHv4 0/7] Add Intel Stratix10 FPGA manager and service layer

From: Richard Gong This is the 4th submission of Intel stratix10 service layer patches. Intel Stratix10 FPGA manager, which is 1st Stratix10 service layer client, is included in this submission. Stratix10 service layer patches have been reviewed internally by Alan Tull

[PATCHv4 0/7] Add Intel Stratix10 FPGA manager and service layer

From: Richard Gong This is the 4th submission of Intel stratix10 service layer patches. Intel Stratix10 FPGA manager, which is 1st Stratix10 service layer client, is included in this submission. Stratix10 service layer patches have been reviewed internally by Alan Tull and other colleagues at

<    5   6   7   8   9   10   11   12   13   14   >