Re: [PATCH v8 6/6] powerpc/fadump: use the new parse_args callback arguments

In case, someone wishes for a changelog: With fadump_rework_cmdline_params() function, parse_args() callback function, taking new arguments - current & next, use them to process 'fadump_extra_args=' parmeter, in enforcing the parameters passed through it for fadump kernel. On Tuesday 12

Re: [PATCH v8 6/6] powerpc/fadump: use the new parse_args callback arguments

In case, someone wishes for a changelog: With fadump_rework_cmdline_params() function, parse_args() callback function, taking new arguments - current & next, use them to process 'fadump_extra_args=' parmeter, in enforcing the parameters passed through it for fadump kernel. On Tuesday 12

Re: [PATCH -v2 03/18] sched/fair: Cure calc_cfs_shares() vs reweight_entity()

On Fri, Sep 29, 2017 at 01:38:53PM +0200, Peter Zijlstra wrote: > On Fri, Sep 29, 2017 at 10:04:34AM +0100, Morten Rasmussen wrote: > > > > - load = scale_load_down(cfs_rq->load.weight); > > > + load = max(scale_load_down(cfs_rq->load.weight), cfs_rq->avg.load_avg); > > > > We use

Re: [PATCH -v2 03/18] sched/fair: Cure calc_cfs_shares() vs reweight_entity()

On Fri, Sep 29, 2017 at 01:38:53PM +0200, Peter Zijlstra wrote: > On Fri, Sep 29, 2017 at 10:04:34AM +0100, Morten Rasmussen wrote: > > > > - load = scale_load_down(cfs_rq->load.weight); > > > + load = max(scale_load_down(cfs_rq->load.weight), cfs_rq->avg.load_avg); > > > > We use

Re: [PATCH 1/8] sched: Consistent task-state printing

On Fri, 29 Sep 2017 13:50:16 +0200 Peter Zijlstra wrote: > On Mon, Sep 25, 2017 at 04:01:09PM -0400, Steven Rostedt wrote: > > On Mon, 25 Sep 2017 14:07:48 +0200 > > Peter Zijlstra wrote: > > > > > +static inline char __task_state_to_char(unsigned

Re: [PATCH 1/8] sched: Consistent task-state printing

On Fri, 29 Sep 2017 13:50:16 +0200 Peter Zijlstra wrote: > On Mon, Sep 25, 2017 at 04:01:09PM -0400, Steven Rostedt wrote: > > On Mon, 25 Sep 2017 14:07:48 +0200 > > Peter Zijlstra wrote: > > > > > +static inline char __task_state_to_char(unsigned int state) > > > +{ > > > + static const

[PATCH 1/3] drm/bridge: make drm_panel_bridge_remove more robust

Make sure that bridge parameter is not NULL and can be safely cast into a panel_bridge structure. Signed-off-by: Benjamin Gaignard --- drivers/gpu/drm/bridge/panel.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git

[PATCH 1/3] drm/bridge: make drm_panel_bridge_remove more robust

Make sure that bridge parameter is not NULL and can be safely cast into a panel_bridge structure. Signed-off-by: Benjamin Gaignard --- drivers/gpu/drm/bridge/panel.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/panel.c

[PATCH 2/3] drm/drm_of: add drm_of_panel_bridge_remove function

This function is the pendant of drm_of_find_panel_or_bridge() to remove a previously allocated panel_bridge. Given a specific port and endpoint it remove the panel bridge. Since drm_panel_bridge_remove() will check that bridge parameter is not NULL and is a real drm_panel_bridge and no a simple

[PATCH 2/3] drm/drm_of: add drm_of_panel_bridge_remove function

This function is the pendant of drm_of_find_panel_or_bridge() to remove a previously allocated panel_bridge. Given a specific port and endpoint it remove the panel bridge. Since drm_panel_bridge_remove() will check that bridge parameter is not NULL and is a real drm_panel_bridge and no a simple

[PATCH 3/3] drm/stm: ltdc: remove bridge from driver internal structure

With a call to drm_of_panel_bridge_remove() we could remove the bridge without store it in ldtc internal driver structure. Signed-off-by: Benjamin Gaignard --- drivers/gpu/drm/stm/ltdc.c | 16 +--- drivers/gpu/drm/stm/ltdc.h | 2 -- 2 files changed, 5

[PATCH 3/3] drm/stm: ltdc: remove bridge from driver internal structure

With a call to drm_of_panel_bridge_remove() we could remove the bridge without store it in ldtc internal driver structure. Signed-off-by: Benjamin Gaignard --- drivers/gpu/drm/stm/ltdc.c | 16 +--- drivers/gpu/drm/stm/ltdc.h | 2 -- 2 files changed, 5 insertions(+), 13 deletions(-)

[PATCH 0/3] Simplify panel bridge cleanup

The goal of this series is to simplify driver code when they need to clean up a previously allocated panel bridge. Few drivers have "is_panel_bridge" flag to be able to distinguish a drm_panel_bridge from "simple" drm_bridge. To remove this flag I propose to - let drm_panel_bridge_remove() check

[PATCH 0/3] Simplify panel bridge cleanup

The goal of this series is to simplify driver code when they need to clean up a previously allocated panel bridge. Few drivers have "is_panel_bridge" flag to be able to distinguish a drm_panel_bridge from "simple" drm_bridge. To remove this flag I propose to - let drm_panel_bridge_remove() check

Re: How to verify linux-next

On Fri, 29 Sep 2017 16:08:07 +0530, Pintu Kumar said: > I have a general question. > How do we normally verify linux-next tree? The same exact way you "verify" any other Linux kernel, for whatever definition of "verify" you plan to use. > 1) For Oracle virtual box 5.1.26 with ubuntu-32 bit, the

Re: How to verify linux-next

On Fri, 29 Sep 2017 16:08:07 +0530, Pintu Kumar said: > I have a general question. > How do we normally verify linux-next tree? The same exact way you "verify" any other Linux kernel, for whatever definition of "verify" you plan to use. > 1) For Oracle virtual box 5.1.26 with ubuntu-32 bit, the

Re: [PATCH v2 02/10] pinctrl: axp209: add pinctrl features (fwd)

l: axp209: add pinctrl features > > > > Hi Quentin, > > > > [auto build test WARNING on ] > > > > url: > > https://github.com/0day-ci/linux/commits/Quentin-Schulz/add-pinmuxing-support-for-pins-in-AXP209-and-AXP813-PMICs/20170929-162846 > > base: &g

Re: [PATCH v2 02/10] pinctrl: axp209: add pinctrl features (fwd)

> > > -- Forwarded message -- > > Date: Fri, 29 Sep 2017 20:00:03 +0800 > > From: kbuild test robot > > To: kbu...@01.org > > Cc: Julia Lawall > > Subject: Re: [PATCH v2 02/10] pinctrl: axp209: add pinctrl features > > > > Hi Q

Re: [PATCH 3/3 v12] printk: Add monotonic, boottime, and realtime timestamps

Hi! > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > index b19c491cbc4e..e21b0c002d0f 100644 > --- a/lib/Kconfig.debug > +++ b/lib/Kconfig.debug > @@ -8,12 +8,58 @@ config PRINTK_TIME > messages to be added to the output of the syslog() system > call and at the console. >

Re: [PATCH 3/3 v12] printk: Add monotonic, boottime, and realtime timestamps

Hi! > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > index b19c491cbc4e..e21b0c002d0f 100644 > --- a/lib/Kconfig.debug > +++ b/lib/Kconfig.debug > @@ -8,12 +8,58 @@ config PRINTK_TIME > messages to be added to the output of the syslog() system > call and at the console. >

Re: [PATCH v2 02/10] pinctrl: axp209: add pinctrl features (fwd)

RNING on ] > > url: > https://github.com/0day-ci/linux/commits/Quentin-Schulz/add-pinmuxing-support-for-pins-in-AXP209-and-AXP813-PMICs/20170929-162846 > base: > :: branch date: 4 hours ago > :: commit date: 4 hours ago > >>> drivers/pinctrl/pinctrl-axp2

Re: [PATCH v2 02/10] pinctrl: axp209: add pinctrl features (fwd)

ux/commits/Quentin-Schulz/add-pinmuxing-support-for-pins-in-AXP209-and-AXP813-PMICs/20170929-162846 > base: > :: branch date: 4 hours ago > :: commit date: 4 hours ago > >>> drivers/pinctrl/pinctrl-axp209.c:485:19-27: WARNING: invalid free of devm_ >>> alloc

[RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

PR_SET_PDEATHSIG sets a parent death signal that the calling process will get when its parent thread dies, even when the result of getppid() doesn't change because the calling process is reparented to a different thread in the same parent process. When managing multiple processes, a process-based

[RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

PR_SET_PDEATHSIG sets a parent death signal that the calling process will get when its parent thread dies, even when the result of getppid() doesn't change because the calling process is reparented to a different thread in the same parent process. When managing multiple processes, a process-based

Re: [Part1 PATCH v5 02/17] x86/mm: Add Secure Encrypted Virtualization (SEV) support

On 9/28/17 2:23 PM, Borislav Petkov wrote: ... > So actually we need chicken bits to be able to *enable* both when > CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT is not set. > > I.e., > > * mem_encrypt=on - both SME and SEV enabled > > * mem_encrypt=smeonly - only SME, no SEV on the host. This

Re: [Part1 PATCH v5 02/17] x86/mm: Add Secure Encrypted Virtualization (SEV) support

On 9/28/17 2:23 PM, Borislav Petkov wrote: ... > So actually we need chicken bits to be able to *enable* both when > CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT is not set. > > I.e., > > * mem_encrypt=on - both SME and SEV enabled > > * mem_encrypt=smeonly - only SME, no SEV on the host. This

[PATCH v2 net] net: mvpp2: Fix clock resource by adding an optional bus clock

On Armada 7K/8K we need to explicitly enable the bus clock. The bus clock is optional because not all the SoCs need them but at least for Armada 7K/8K it is actually mandatory. The binding documentation is updating accordingly. Signed-off-by: Gregory CLEMENT

[PATCH v2 net] net: mvpp2: Fix clock resource by adding an optional bus clock

On Armada 7K/8K we need to explicitly enable the bus clock. The bus clock is optional because not all the SoCs need them but at least for Armada 7K/8K it is actually mandatory. The binding documentation is updating accordingly. Signed-off-by: Gregory CLEMENT --- Changelog: v1 -> v2: - manage

Re: [PATCH v2 0/2] mtd: nand: wait for tWHR, and fix the setup_data_interface of Denali

On Fri, 29 Sep 2017 19:38:38 +0900 Masahiro Yamada wrote: > 1/2 : add NAND_WAIT_TWHR and nand_whr_delay(). > You can set this new flag if you want nand_command(_lp) > to insert tWHR delay where needed. > > 2/2 : Fix Denali setup_data_interface. >

Re: [PATCH v2 0/2] mtd: nand: wait for tWHR, and fix the setup_data_interface of Denali

On Fri, 29 Sep 2017 19:38:38 +0900 Masahiro Yamada wrote: > 1/2 : add NAND_WAIT_TWHR and nand_whr_delay(). > You can set this new flag if you want nand_command(_lp) > to insert tWHR delay where needed. > > 2/2 : Fix Denali setup_data_interface. > Boris' suggestion in v1 was a

Re: [lkp-robot] [x86/mm] 9e52fc2b50: will-it-scale.per_thread_ops -16% regression

kernel test robot writes: > Greeting, > > FYI, we noticed a -16% regression of will-it-scale.per_thread_ops due to > commit: > > commit: 9e52fc2b50de3a1c08b44f94c610fbe998c0031a ("x86/mm: Enable RCU based > page table freeing (CONFIG_HAVE_RCU_TABLE_FREE=y)") >

Re: [lkp-robot] [x86/mm] 9e52fc2b50: will-it-scale.per_thread_ops -16% regression

kernel test robot writes: > Greeting, > > FYI, we noticed a -16% regression of will-it-scale.per_thread_ops due to > commit: > > commit: 9e52fc2b50de3a1c08b44f94c610fbe998c0031a ("x86/mm: Enable RCU based > page table freeing (CONFIG_HAVE_RCU_TABLE_FREE=y)") >

Re: [PATCH v6] PCI: quirks: update Cavium ThunderX ACS quirk implementation

Hi Bjorn, On Wed, Sep 27, 2017 at 02:18:54PM -0600, Alex Williamson wrote: > On Wed, 27 Sep 2017 11:20:39 -0700 > Vadim Lomovtsev wrote: > > > This commit makes Cavium PCI ACS quirk applicable only to Cavium > > ThunderX (CN8XXX) family PCIE Root Ports which

Re: [PATCH v6] PCI: quirks: update Cavium ThunderX ACS quirk implementation

Hi Bjorn, On Wed, Sep 27, 2017 at 02:18:54PM -0600, Alex Williamson wrote: > On Wed, 27 Sep 2017 11:20:39 -0700 > Vadim Lomovtsev wrote: > > > This commit makes Cavium PCI ACS quirk applicable only to Cavium > > ThunderX (CN8XXX) family PCIE Root Ports which has limited PCI capabilities > > in

Re: [Part2 PATCH v4 02/29] x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature

On Tue, Sep 19, 2017 at 03:46:00PM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > Update the CPU features to include identifying and reporting on the > Secure Encrypted Virtualization (SEV) feature. SEV is identified by > CPUID 0x801f, but requires BIOS

Re: [Part2 PATCH v4 02/29] x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature

On Tue, Sep 19, 2017 at 03:46:00PM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > Update the CPU features to include identifying and reporting on the > Secure Encrypted Virtualization (SEV) feature. SEV is identified by > CPUID 0x801f, but requires BIOS support to enable it (set bit

Re: [PATCH v2 02/10] pinctrl: axp209: add pinctrl features (fwd)

Subject: Re: [PATCH v2 02/10] pinctrl: axp209: add pinctrl features Hi Quentin, [auto build test WARNING on ] url: https://github.com/0day-ci/linux/commits/Quentin-Schulz/add-pinmuxing-support-for-pins-in-AXP209-and-AXP813-PMICs/20170929-162846 base: :: branch date: 4 hours ago :: co

Re: [PATCH v2 02/10] pinctrl: axp209: add pinctrl features (fwd)

features Hi Quentin, [auto build test WARNING on ] url: https://github.com/0day-ci/linux/commits/Quentin-Schulz/add-pinmuxing-support-for-pins-in-AXP209-and-AXP813-PMICs/20170929-162846 base: :: branch date: 4 hours ago :: commit date: 4 hours ago >> drivers/pinctrl/pinctrl-ax

[PATCH v1] ARM: configs: stm32: Add I2C support in STM32 defconfig

This patch adds I2C support for STM32 Signed-off-by: Pierre-Yves MORDRET --- Version history: v1: * Initial --- --- arch/arm/configs/stm32_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/stm32_defconfig

[PATCH v1] ARM: configs: stm32: Add I2C support in STM32 defconfig

This patch adds I2C support for STM32 Signed-off-by: Pierre-Yves MORDRET --- Version history: v1: * Initial --- --- arch/arm/configs/stm32_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig index

Re: [PATCH 3/4] iommu/arm-smmu-v3: Use NUMA memory allocations for stream tables and comamnd queues

Hi Robin, On 2017-09-21 13:58, Robin Murphy wrote: [+Christoph and Marek] On 21/09/17 09:59, Ganapatrao Kulkarni wrote: Introduce smmu_alloc_coherent and smmu_free_coherent functions to allocate/free dma coherent memory from NUMA node associated with SMMU. Replace all calls of

Re: [PATCH 3/4] iommu/arm-smmu-v3: Use NUMA memory allocations for stream tables and comamnd queues

Hi Robin, On 2017-09-21 13:58, Robin Murphy wrote: [+Christoph and Marek] On 21/09/17 09:59, Ganapatrao Kulkarni wrote: Introduce smmu_alloc_coherent and smmu_free_coherent functions to allocate/free dma coherent memory from NUMA node associated with SMMU. Replace all calls of

Re: [PATCH RFC 3/5] Add KSZ8795 switch driver

On Fri, Sep 29, 2017 at 09:14:26AM +, David Laight wrote: > From: Andrew Lunn > > Sent: 28 September 2017 20:34 > ... > > > There are 34 counters. In normal case using generic bus I/O or PCI to > > > read them > > > is very quick, but the switch is mostly accessed using SPI, or even I2C. >

Re: [PATCH RFC 3/5] Add KSZ8795 switch driver

On Fri, Sep 29, 2017 at 09:14:26AM +, David Laight wrote: > From: Andrew Lunn > > Sent: 28 September 2017 20:34 > ... > > > There are 34 counters. In normal case using generic bus I/O or PCI to > > > read them > > > is very quick, but the switch is mostly accessed using SPI, or even I2C. >

[RESEND PATCH] fs: add RWF_APPEND

This is the per-I/O equivalent of O_APPEND to support atomic append operations on any open file. If a file is opened with O_APPEND, pwrite() ignores the offset and always appends data to the end of the file. RWF_APPEND enables atomic append and pwrite() with offset on a single file descriptor.

[RESEND PATCH] fs: add RWF_APPEND

This is the per-I/O equivalent of O_APPEND to support atomic append operations on any open file. If a file is opened with O_APPEND, pwrite() ignores the offset and always appends data to the end of the file. RWF_APPEND enables atomic append and pwrite() with offset on a single file descriptor.

Re: [PATCH 1/6] mm: add kmalloc_array_node and kcalloc_node

On 09/27/2017 10:20 AM, Johannes Thumshirn wrote: > We have kmalloc_array() and kcalloc() wrappers on top of kmalloc() which > ensure us overflow free multiplication for the size of a memory > allocation but these implementations are not NUMA-aware. > > Likewise we have kmalloc_node() which is a

Re: [PATCH 1/6] mm: add kmalloc_array_node and kcalloc_node

On 09/27/2017 10:20 AM, Johannes Thumshirn wrote: > We have kmalloc_array() and kcalloc() wrappers on top of kmalloc() which > ensure us overflow free multiplication for the size of a memory > allocation but these implementations are not NUMA-aware. > > Likewise we have kmalloc_node() which is a

Re: [PATCH v8 12/28] x86/insn-eval: Add utility functions to get segment selector

On Thu, Sep 28, 2017 at 11:06:42PM -0700, Ricardo Neri wrote: > I agree. In fact, insn_get_seg_base() does not need insn at all. All it needs > is > a INAT_SEG_REG_* index. This would make things clear. UMIP (and callers that > need to copy_from_user code can do insn_get_seg_base(regs,

Re: [PATCH v8 12/28] x86/insn-eval: Add utility functions to get segment selector

On Thu, Sep 28, 2017 at 11:06:42PM -0700, Ricardo Neri wrote: > I agree. In fact, insn_get_seg_base() does not need insn at all. All it needs > is > a INAT_SEG_REG_* index. This would make things clear. UMIP (and callers that > need to copy_from_user code can do insn_get_seg_base(regs,

Re: [PATCH] staging: wlan-ng: resolve sparse Endianness issue.

Someone already sent this. Work against linux-next or staging-next. regards, dan carpenter

Re: [PATCH] staging: wlan-ng: resolve sparse Endianness issue.

Someone already sent this. Work against linux-next or staging-next. regards, dan carpenter

Re: [PATCH v3] mmc: dt-bindings: Add reg/source_cg/latch-ck for Mediatek MMC bindings

On Fri, 2017-09-29 at 13:11 +0200, Matthias Brugger wrote: > > On 09/22/2017 02:03 PM, Chaotian Jing wrote: > > Change the comptiable for support of multi-platform > > Add description for reg > > Add description for source_cg > > Add description for mediatek,latch-ck > > Note that source_cg and

Re: [PATCH v3] mmc: dt-bindings: Add reg/source_cg/latch-ck for Mediatek MMC bindings

On Fri, 2017-09-29 at 13:11 +0200, Matthias Brugger wrote: > > On 09/22/2017 02:03 PM, Chaotian Jing wrote: > > Change the comptiable for support of multi-platform > > Add description for reg > > Add description for source_cg > > Add description for mediatek,latch-ck > > Note that source_cg and

Re: [PATCH 1/8] sched: Consistent task-state printing

On Mon, Sep 25, 2017 at 04:01:09PM -0400, Steven Rostedt wrote: > On Mon, 25 Sep 2017 14:07:48 +0200 > Peter Zijlstra wrote: > > > +static inline char __task_state_to_char(unsigned int state) > > +{ > > + static const char state_char[] = "RSDTtXZ"; > > + > > +

Re: [PATCH 1/8] sched: Consistent task-state printing

On Mon, Sep 25, 2017 at 04:01:09PM -0400, Steven Rostedt wrote: > On Mon, 25 Sep 2017 14:07:48 +0200 > Peter Zijlstra wrote: > > > +static inline char __task_state_to_char(unsigned int state) > > +{ > > + static const char state_char[] = "RSDTtXZ"; > > + > > + BUILD_BUG_ON(1 +

Re: [PATCH][trace-cmd] trace-view: Pick up sched_wakeup_new event

On 2017-09-29 13:29, Jan Kiszka wrote: > From: Jan Kiszka > > Seems like a copy bug of the initial commit 7b0139ebb1cf. > > Signed-off-by: Jan Kiszka > --- > > I didn't manage to test this so far, but this looked strange while > reading the

Re: [PATCH][trace-cmd] trace-view: Pick up sched_wakeup_new event

On 2017-09-29 13:29, Jan Kiszka wrote: > From: Jan Kiszka > > Seems like a copy bug of the initial commit 7b0139ebb1cf. > > Signed-off-by: Jan Kiszka > --- > > I didn't manage to test this so far, but this looked strange while > reading the code. Now I found out how it is supposed to work

Re: [PATCH v4 for 4.14 1/3] membarrier: Provide register expedited private command

On Fri, Sep 29, 2017 at 09:38:53PM +1000, Nicholas Piggin wrote: > Not really. There is some ability to hold onto a line for a time, but > there is no way to starve them, let alone starve hundreds of other > CPUs. They will request the cacheline exclusive and eventually get it. OK, hardware

Re: [PATCH v4 for 4.14 1/3] membarrier: Provide register expedited private command

On Fri, Sep 29, 2017 at 09:38:53PM +1000, Nicholas Piggin wrote: > Not really. There is some ability to hold onto a line for a time, but > there is no way to starve them, let alone starve hundreds of other > CPUs. They will request the cacheline exclusive and eventually get it. OK, hardware

Re: [PATCH v3 tip/core/rcu 40/40] rcu: Make non-preemptive schedule be Tasks RCU quiescent state

On 29/09/2017 12:34, Peter Zijlstra wrote: > On Fri, Sep 29, 2017 at 12:01:24PM +0200, Paolo Bonzini wrote: >>> Does this mean whenever we get a page fault in a RCU read-side critical >>> section, we may hit this? >>> >>> Could we simply avoid to schedule() in kvm_async_pf_task_wait() if the >>>

Re: [PATCH v3 tip/core/rcu 40/40] rcu: Make non-preemptive schedule be Tasks RCU quiescent state

On 29/09/2017 12:34, Peter Zijlstra wrote: > On Fri, Sep 29, 2017 at 12:01:24PM +0200, Paolo Bonzini wrote: >>> Does this mean whenever we get a page fault in a RCU read-side critical >>> section, we may hit this? >>> >>> Could we simply avoid to schedule() in kvm_async_pf_task_wait() if the >>>

Re: usb/misc/usbtest: null-ptr-deref in usbtest_probe/get_endpoints

On Thu, Sep 28, 2017 at 7:01 PM, Alan Stern wrote: > On Thu, 28 Sep 2017, Andrey Konovalov wrote: > >> Hi! >> >> I've got the following report while fuzzing the kernel with syzkaller. >> >> On commit dc972a67cc54585bd83ad811c4e9b6ab3dcd427e (4.14-rc2+). >> >> It seems

Re: usb/misc/usbtest: null-ptr-deref in usbtest_probe/get_endpoints

On Thu, Sep 28, 2017 at 7:01 PM, Alan Stern wrote: > On Thu, 28 Sep 2017, Andrey Konovalov wrote: > >> Hi! >> >> I've got the following report while fuzzing the kernel with syzkaller. >> >> On commit dc972a67cc54585bd83ad811c4e9b6ab3dcd427e (4.14-rc2+). >> >> It seems that out pointer ends up

Re: [PATCH v4 for 4.14 1/3] membarrier: Provide register expedited private command

On Fri, 29 Sep 2017 12:31:31 +0200 Peter Zijlstra wrote: > On Fri, Sep 29, 2017 at 02:27:57AM +1000, Nicholas Piggin wrote: > > > The biggest power boxes are more tightly coupled than those big > > SGI systems, but even so just plodding along taking and releasing > > locks

Re: [PATCH v4 for 4.14 1/3] membarrier: Provide register expedited private command

On Fri, 29 Sep 2017 12:31:31 +0200 Peter Zijlstra wrote: > On Fri, Sep 29, 2017 at 02:27:57AM +1000, Nicholas Piggin wrote: > > > The biggest power boxes are more tightly coupled than those big > > SGI systems, but even so just plodding along taking and releasing > > locks in turn would be fine

Re: [PATCH -v2 03/18] sched/fair: Cure calc_cfs_shares() vs reweight_entity()

On Fri, Sep 29, 2017 at 10:04:34AM +0100, Morten Rasmussen wrote: > > - load = scale_load_down(cfs_rq->load.weight); > > + load = max(scale_load_down(cfs_rq->load.weight), cfs_rq->avg.load_avg); > > We use cfs_rq->tg_load_avg_contrib (the filtered version of > cfs_rq->avg.load_avg) instead

Re: [PATCH -v2 03/18] sched/fair: Cure calc_cfs_shares() vs reweight_entity()

On Fri, Sep 29, 2017 at 10:04:34AM +0100, Morten Rasmussen wrote: > > - load = scale_load_down(cfs_rq->load.weight); > > + load = max(scale_load_down(cfs_rq->load.weight), cfs_rq->avg.load_avg); > > We use cfs_rq->tg_load_avg_contrib (the filtered version of > cfs_rq->avg.load_avg) instead

Re: usb/serial/visor: slab-out-of-bounds in palm_os_3_probe

On Fri, Sep 29, 2017 at 10:37 AM, Greg Kroah-Hartman wrote: > On Thu, Sep 28, 2017 at 07:57:46PM +0200, Andrey Konovalov wrote: >> Hi! >> >> I've got the following report while fuzzing the kernel with syzkaller. >> >> On commit dc972a67cc54585bd83ad811c4e9b6ab3dcd427e

Re: usb/serial/visor: slab-out-of-bounds in palm_os_3_probe

On Fri, Sep 29, 2017 at 10:37 AM, Greg Kroah-Hartman wrote: > On Thu, Sep 28, 2017 at 07:57:46PM +0200, Andrey Konovalov wrote: >> Hi! >> >> I've got the following report while fuzzing the kernel with syzkaller. >> >> On commit dc972a67cc54585bd83ad811c4e9b6ab3dcd427e (4.14-rc2+). >> >> There's

Re: [PATCH -v2 02/18] sched/fair: Add comment to calc_cfs_shares()

On Thu, Sep 28, 2017 at 11:03:03AM +0100, Morten Rasmussen wrote: > > +/* > > + * All this does is approximate the hierarchical proportion which includes > > that > > + * global sum we all love to hate. > > + * > > + * That is, the weight of a group entity, is the proportional share of the > > +

Re: [PATCH -v2 02/18] sched/fair: Add comment to calc_cfs_shares()

On Thu, Sep 28, 2017 at 11:03:03AM +0100, Morten Rasmussen wrote: > > +/* > > + * All this does is approximate the hierarchical proportion which includes > > that > > + * global sum we all love to hate. > > + * > > + * That is, the weight of a group entity, is the proportional share of the > > +

Re: [PATCH v3] ebtables: fix race condition in frame_filter_net_init()

On Tue, Sep 26, 2017 at 06:35:45PM +0200, Artem Savkov wrote: > It is possible for ebt_in_hook to be triggered before ebt_table is assigned > resulting in a NULL-pointer dereference. Make sure hooks are > registered as the last step. Applied, thanks.

Re: [PATCH v3] ebtables: fix race condition in frame_filter_net_init()

On Tue, Sep 26, 2017 at 06:35:45PM +0200, Artem Savkov wrote: > It is possible for ebt_in_hook to be triggered before ebt_table is assigned > resulting in a NULL-pointer dereference. Make sure hooks are > registered as the last step. Applied, thanks.

[PATCH][trace-cmd] trace-view: Pick up sched_wakeup_new event

From: Jan Kiszka Seems like a copy bug of the initial commit 7b0139ebb1cf. Signed-off-by: Jan Kiszka --- I didn't manage to test this so far, but this looked strange while reading the code. trace-view-store.c | 2 +- 1 file changed, 1

[PATCH][trace-cmd] trace-view: Pick up sched_wakeup_new event

From: Jan Kiszka Seems like a copy bug of the initial commit 7b0139ebb1cf. Signed-off-by: Jan Kiszka --- I didn't manage to test this so far, but this looked strange while reading the code. trace-view-store.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[tip:x86/urgent] x86/asm: Fix inline asm call constraints for GCC 4.4

Commit-ID: 520a13c530aeb5f63e011d668c42db1af19ed349 Gitweb: https://git.kernel.org/tip/520a13c530aeb5f63e011d668c42db1af19ed349 Author: Josh Poimboeuf AuthorDate: Thu, 28 Sep 2017 16:58:26 -0500 Committer: Ingo Molnar CommitDate: Fri, 29 Sep 2017

[tip:x86/urgent] x86/asm: Fix inline asm call constraints for GCC 4.4

Commit-ID: 520a13c530aeb5f63e011d668c42db1af19ed349 Gitweb: https://git.kernel.org/tip/520a13c530aeb5f63e011d668c42db1af19ed349 Author: Josh Poimboeuf AuthorDate: Thu, 28 Sep 2017 16:58:26 -0500 Committer: Ingo Molnar CommitDate: Fri, 29 Sep 2017 13:15:44 +0200 x86/asm: Fix inline asm

Re: [PATCH v3] mmc: dt-bindings: Add reg/source_cg/latch-ck for Mediatek MMC bindings

On 09/22/2017 02:03 PM, Chaotian Jing wrote: Change the comptiable for support of multi-platform Add description for reg Add description for source_cg Add description for mediatek,latch-ck Note that source_cg and mediatek,latch-ck are optional for some projects, eg, MT2701 do not have

Re: [PATCH v3] mmc: dt-bindings: Add reg/source_cg/latch-ck for Mediatek MMC bindings

On 09/22/2017 02:03 PM, Chaotian Jing wrote: Change the comptiable for support of multi-platform Add description for reg Add description for source_cg Add description for mediatek,latch-ck Note that source_cg and mediatek,latch-ck are optional for some projects, eg, MT2701 do not have

Re: [PATCH 3/4] sched: WARN when migrating to an offline CPU

On Thu, Sep 28, 2017 at 01:42:49PM +0200, Peter Zijlstra wrote: > On Thu, Sep 28, 2017 at 11:03:10AM +, Levin, Alexander (Sasha Levin) > wrote: > > On Thu, Sep 28, 2017 at 12:35:41PM +0200, Peter Zijlstra wrote: > > >On Thu, Sep 28, 2017 at 02:14:15AM -0700, Sasha Levin wrote: > > > >>

Re: [PATCH 3/4] sched: WARN when migrating to an offline CPU

On Thu, Sep 28, 2017 at 01:42:49PM +0200, Peter Zijlstra wrote: > On Thu, Sep 28, 2017 at 11:03:10AM +, Levin, Alexander (Sasha Levin) > wrote: > > On Thu, Sep 28, 2017 at 12:35:41PM +0200, Peter Zijlstra wrote: > > >On Thu, Sep 28, 2017 at 02:14:15AM -0700, Sasha Levin wrote: > > > >>

[PATCH v2] xhci: Cleanup current_cmd in xhci_cleanup_command_queue()

KASAN reported use-after-free bug when xhci host controller died: [ 176.952537] BUG: KASAN: use-after-free in xhci_handle_command_timeout+0x68/0x224 [ 176.960846] Write of size 4 at addr ffc0cbb01608 by task kworker/3:3/1680 ... [ 177.180644] Freed by task 0: [ 177.183882]

[PATCH v2] xhci: Cleanup current_cmd in xhci_cleanup_command_queue()

KASAN reported use-after-free bug when xhci host controller died: [ 176.952537] BUG: KASAN: use-after-free in xhci_handle_command_timeout+0x68/0x224 [ 176.960846] Write of size 4 at addr ffc0cbb01608 by task kworker/3:3/1680 ... [ 177.180644] Freed by task 0: [ 177.183882]

[PATCH] kvm/x86: Handle async PF in RCU read-side critical sections

Sasha Levin reported a WARNING: | WARNING: CPU: 0 PID: 6974 at kernel/rcu/tree_plugin.h:329 | rcu_preempt_note_context_switch kernel/rcu/tree_plugin.h:329 [inline] | WARNING: CPU: 0 PID: 6974 at kernel/rcu/tree_plugin.h:329 | rcu_note_context_switch+0x16c/0x2210 kernel/rcu/tree.c:458 ... | CPU: 0

[PATCH] kvm/x86: Handle async PF in RCU read-side critical sections

Sasha Levin reported a WARNING: | WARNING: CPU: 0 PID: 6974 at kernel/rcu/tree_plugin.h:329 | rcu_preempt_note_context_switch kernel/rcu/tree_plugin.h:329 [inline] | WARNING: CPU: 0 PID: 6974 at kernel/rcu/tree_plugin.h:329 | rcu_note_context_switch+0x16c/0x2210 kernel/rcu/tree.c:458 ... | CPU: 0

Re: [PATCH v1 02/14] tee: add register user memory

On Thu, Sep 28, 2017 at 09:03:59PM +0300, Volodymyr Babchuk wrote: > +static int > +tee_ioctl_shm_register(struct tee_context *ctx, > +struct tee_ioctl_shm_register_data __user *udata) > +{ > + long ret; > + struct tee_ioctl_shm_register_data data; > + struct

Re: [PATCH v1 02/14] tee: add register user memory

On Thu, Sep 28, 2017 at 09:03:59PM +0300, Volodymyr Babchuk wrote: > +static int > +tee_ioctl_shm_register(struct tee_context *ctx, > +struct tee_ioctl_shm_register_data __user *udata) > +{ > + long ret; > + struct tee_ioctl_shm_register_data data; > + struct

Re: [PATCH v1 00/14] tee: optee: add dynamic shared memory support

Hello Mark, On 29.09.17 13:31, Mark Rutland wrote: Hi, On Thu, Sep 28, 2017 at 09:03:57PM +0300, Volodymyr Babchuk wrote: From: Volodymyr Babchuk This patch series enables dynamic shared memory support in the TEE subsystem as a whole and in OP-TEE in particular.

Re: [PATCH v1 00/14] tee: optee: add dynamic shared memory support

Hello Mark, On 29.09.17 13:31, Mark Rutland wrote: Hi, On Thu, Sep 28, 2017 at 09:03:57PM +0300, Volodymyr Babchuk wrote: From: Volodymyr Babchuk This patch series enables dynamic shared memory support in the TEE subsystem as a whole and in OP-TEE in particular. Global Platform TEE

[PATCH v2 1/2] mtd: nand: wait for tWHR after NAND_CMD_STATUS / NAND_CMD_READID

For commands such as Read Status, Read ID, etc. the controller needs to wait for tWHR before it reads out the first data. If the controller does not take care of it, the driver has to wait explicitly to make sure to meet the spec. Introduce NAND_WAIT_TWHR, which works like NAND_WAIT_TCCS. The

[PATCH v2 2/2] mtd: nand: denali: fix setup_data_interface to meet tCCS delay

The WE_2_RE register specifies the number of clock cycles inserted between the rising edge of #WE and the falling edge of #RE. The current setup_data_interface implementation takes care of tWHR, but tCCS is missing. Wait max(tCSS, tWHR) to meet the spec. With setup_data_interface() is properly

[PATCH v2 1/2] mtd: nand: wait for tWHR after NAND_CMD_STATUS / NAND_CMD_READID

For commands such as Read Status, Read ID, etc. the controller needs to wait for tWHR before it reads out the first data. If the controller does not take care of it, the driver has to wait explicitly to make sure to meet the spec. Introduce NAND_WAIT_TWHR, which works like NAND_WAIT_TCCS. The

[PATCH v2 2/2] mtd: nand: denali: fix setup_data_interface to meet tCCS delay

The WE_2_RE register specifies the number of clock cycles inserted between the rising edge of #WE and the falling edge of #RE. The current setup_data_interface implementation takes care of tWHR, but tCCS is missing. Wait max(tCSS, tWHR) to meet the spec. With setup_data_interface() is properly

[PATCH v2 0/2] mtd: nand: wait for tWHR, and fix the setup_data_interface of Denali

1/2 : add NAND_WAIT_TWHR and nand_whr_delay(). You can set this new flag if you want nand_command(_lp) to insert tWHR delay where needed. 2/2 : Fix Denali setup_data_interface. Boris' suggestion in v1 was a good reminder that made me realize tCCS was missing in the

[PATCH v2 0/2] mtd: nand: wait for tWHR, and fix the setup_data_interface of Denali

1/2 : add NAND_WAIT_TWHR and nand_whr_delay(). You can set this new flag if you want nand_command(_lp) to insert tWHR delay where needed. 2/2 : Fix Denali setup_data_interface. Boris' suggestion in v1 was a good reminder that made me realize tCCS was missing in the

Re: [RFC PATCH v2 3/7] sched/idle: Add poll before enter real idle path

On 2017/9/1 14:49, Quan Xu wrote: on 2017/8/29 22:39, Borislav Petkov wrote: On Tue, Aug 29, 2017 at 11:46:37AM +, Yang Zhang wrote: Add poll in do_idle. For UP VM, if there are running task, it will not goes into idle path, so we only enable poll in SMP VM. Signed-off-by: Yang Zhang

Re: [RFC PATCH v2 3/7] sched/idle: Add poll before enter real idle path

On 2017/9/1 14:49, Quan Xu wrote: on 2017/8/29 22:39, Borislav Petkov wrote: On Tue, Aug 29, 2017 at 11:46:37AM +, Yang Zhang wrote: Add poll in do_idle. For UP VM, if there are running task, it will not goes into idle path, so we only enable poll in SMP VM. Signed-off-by: Yang Zhang

Re: How to verify linux-next

Hi, I have a general question. How do we normally verify linux-next tree? I wanted to work on linux-next but I am facing some issues. I could able to build linux-next for both x86 and arm, but I could not verify it on any machine. Currently I don't have a real Linux PC to boot with linux-next

Re: How to verify linux-next

Hi, I have a general question. How do we normally verify linux-next tree? I wanted to work on linux-next but I am facing some issues. I could able to build linux-next for both x86 and arm, but I could not verify it on any machine. Currently I don't have a real Linux PC to boot with linux-next

<    5   6   7   8   9   10   11   12   13   >