Re: [PATCH v5 06/12] PCI: designware-ep: Make dw_pcie_ep_set_bar() handle 64-bit BARs properly

On Tue, Apr 03, 2018 at 01:53:12PM +0100, Lorenzo Pieralisi wrote: > On Mon, Apr 02, 2018 at 09:37:03PM +0200, Niklas Cassel wrote: > > On Thu, Mar 29, 2018 at 03:17:11PM +0530, Kishon Vijay Abraham I wrote: > > > Hi, > > > > > > On Wednesday 28 March 2018 05:20 PM, Niklas Cassel wrote: > > > >

Re: [PATCH v5 06/12] PCI: designware-ep: Make dw_pcie_ep_set_bar() handle 64-bit BARs properly

On Tue, Apr 03, 2018 at 01:53:12PM +0100, Lorenzo Pieralisi wrote: > On Mon, Apr 02, 2018 at 09:37:03PM +0200, Niklas Cassel wrote: > > On Thu, Mar 29, 2018 at 03:17:11PM +0530, Kishon Vijay Abraham I wrote: > > > Hi, > > > > > > On Wednesday 28 March 2018 05:20 PM, Niklas Cassel wrote: > > > >

[PATCH v2] x86/smpboot: Don't do mwait_play_dead() on AMD systems

From: Yazen Ghannam Recent AMD systems support using MWAIT for C1 state. However, MWAIT will not allow deeper cstates than C1 on current systems. With play_dead() we expect the OS to use the deepest state available. The deepest state available on AMD systems is reached

[PATCH v2] x86/smpboot: Don't do mwait_play_dead() on AMD systems

From: Yazen Ghannam Recent AMD systems support using MWAIT for C1 state. However, MWAIT will not allow deeper cstates than C1 on current systems. With play_dead() we expect the OS to use the deepest state available. The deepest state available on AMD systems is reached through SystemIO or HALT.

Re: [PATCH 1/6] drivers/i2c: Update i2c_trace_msg static key to modern api

Wolfram Sang wrote: > > No changes in refcount semantics -- key init is false; replace > > > > static_key_slow_inc|dec with static_branch_inc|dec > > static_key_false with static_branch_unlikely > > > > Added a '_key' suffix to i2c_trace_msg, for better self

Re: [PATCH 1/6] drivers/i2c: Update i2c_trace_msg static key to modern api

Wolfram Sang wrote: > > No changes in refcount semantics -- key init is false; replace > > > > static_key_slow_inc|dec with static_branch_inc|dec > > static_key_false with static_branch_unlikely > > > > Added a '_key' suffix to i2c_trace_msg, for better self > > documentation. >

Re: [GIT PULL] Andes(nds32) Port for Linux 4.17

On Mon, Apr 2, 2018 at 6:04 PM, Linus Torvalds wrote: > On Sun, Apr 1, 2018 at 11:01 PM, Greentime Hu wrote: >> >> This tag contains the core nds32 Linux port(including interrupt controller >> driver and timer driver), which has been through 7

[GIT PULL] Btrfs updates for 4.17

Hi, please pull the following btrfs changes. There are a several user visible changes, the rest is mostly invisible and continues to clean up the whole code base. There are no merge conflicts with current master. Please pull, thanks. User visible changes: - new mount option nossd_spread

Re: [GIT PULL] Andes(nds32) Port for Linux 4.17

On Mon, Apr 2, 2018 at 6:04 PM, Linus Torvalds wrote: > On Sun, Apr 1, 2018 at 11:01 PM, Greentime Hu wrote: >> >> This tag contains the core nds32 Linux port(including interrupt controller >> driver and timer driver), which has been through 7 rounds of review on >> mailing >> list. > > Can I

[GIT PULL] Btrfs updates for 4.17

Hi, please pull the following btrfs changes. There are a several user visible changes, the rest is mostly invisible and continues to clean up the whole code base. There are no merge conflicts with current master. Please pull, thanks. User visible changes: - new mount option nossd_spread

Re: [PATCH v3] vsprintf: Prevent crash when dereferencing invalid pointers

On (04/03/18 13:52), Petr Mladek wrote: > On Tue 2018-04-03 10:12:37, Sergey Senozhatsky wrote: > > On (04/02/18 17:15), Andy Shevchenko wrote: > > > > > > > > Hmm, I have never seen the error code in this form. > > > > > > We have limited space to print it and error numbers currently can be up

Re: [PATCH v3] vsprintf: Prevent crash when dereferencing invalid pointers

On (04/03/18 13:52), Petr Mladek wrote: > On Tue 2018-04-03 10:12:37, Sergey Senozhatsky wrote: > > On (04/02/18 17:15), Andy Shevchenko wrote: > > > > > > > > Hmm, I have never seen the error code in this form. > > > > > > We have limited space to print it and error numbers currently can be up

Re: [PATCH v1] kernel/trace:check the val against the available mem

On Tue 03-04-18 09:32:45, Steven Rostedt wrote: > On Tue, 3 Apr 2018 14:35:14 +0200 > Michal Hocko wrote: [...] > > Being clever is OK if it doesn't add a tricky code. And relying on > > si_mem_available is definitely tricky and obscure. > > Can we get the mm subsystem to

Re: [PATCH v1] kernel/trace:check the val against the available mem

On Tue 03-04-18 09:32:45, Steven Rostedt wrote: > On Tue, 3 Apr 2018 14:35:14 +0200 > Michal Hocko wrote: [...] > > Being clever is OK if it doesn't add a tricky code. And relying on > > si_mem_available is definitely tricky and obscure. > > Can we get the mm subsystem to provide a better method

RE: [PATCH] x86/smpboot: Don't do mwait_play_dead() on AMD systems

> -Original Message- > From: Ingo Molnar On Behalf Of Ingo Molnar > Sent: Tuesday, April 3, 2018 7:04 AM > To: Ghannam, Yazen > Cc: x...@kernel.org; linux-kernel@vger.kernel.org; b...@suse.de > Subject: Re: [PATCH] x86/smpboot: Don't do

RE: [PATCH] x86/smpboot: Don't do mwait_play_dead() on AMD systems

> -Original Message- > From: Ingo Molnar On Behalf Of Ingo Molnar > Sent: Tuesday, April 3, 2018 7:04 AM > To: Ghannam, Yazen > Cc: x...@kernel.org; linux-kernel@vger.kernel.org; b...@suse.de > Subject: Re: [PATCH] x86/smpboot: Don't do mwait_play_dead() on AMD > systems > > > * Yazen

Re: [PATCH] usbip: vhci_hcd: Fix usb device and sockfd leaks

On 04/03/2018 12:56 AM, Greg KH wrote: > On Mon, Apr 02, 2018 at 02:52:32PM -0600, Shuah Khan wrote: >> vhci_hcd fails to do reset to put usb device and sockfd in the >> module remove/stop paths. Fix the leak. >> >> Signed-off-by: Shuah Khan > > Should this be marked for

Re: [PATCH] usbip: vhci_hcd: Fix usb device and sockfd leaks

On 04/03/2018 12:56 AM, Greg KH wrote: > On Mon, Apr 02, 2018 at 02:52:32PM -0600, Shuah Khan wrote: >> vhci_hcd fails to do reset to put usb device and sockfd in the >> module remove/stop paths. Fix the leak. >> >> Signed-off-by: Shuah Khan > > Should this be marked for the stable kernels? >

Re: [PATCH v2 1/3] locking: Document the semantics of spin_is_locked()

Andrea Parri wrote: > > It's more complicated than that. This function is dangerous and should be > > used with extreme care. In the case where CONFIG_SMP=n the value is locked > > one way or the other and it might be the wrong way. > > You mean "unlocked"?

Re: [PATCH v2 1/3] locking: Document the semantics of spin_is_locked()

Andrea Parri wrote: > > It's more complicated than that. This function is dangerous and should be > > used with extreme care. In the case where CONFIG_SMP=n the value is locked > > one way or the other and it might be the wrong way. > > You mean "unlocked"? (aka, return 0) No, I mean

Re: [PATCH 1/1] taging: fbtft: fix memory leak

There is a typo in the subject. It should be "Staging" instead of "taging:". On Tue, Apr 03, 2018 at 09:14:28PM +0800, Xidong Wang wrote: > From: Xidong Wang <2711406...@qq.com> > > In function fbtft_framebuffer_alloc(), the memory allocated by > framebuffer_alloc() is not released on the error

Re: [PATCH 1/1] taging: fbtft: fix memory leak

There is a typo in the subject. It should be "Staging" instead of "taging:". On Tue, Apr 03, 2018 at 09:14:28PM +0800, Xidong Wang wrote: > From: Xidong Wang <2711406...@qq.com> > > In function fbtft_framebuffer_alloc(), the memory allocated by > framebuffer_alloc() is not released on the error

Re: [PATCH v4 1/3] Add notrace to lib/ucmpdi2.c

Hi Palmer, On 29/03/18 22:59, Palmer Dabbelt wrote: On Thu, 29 Mar 2018 03:41:21 PDT (-0700), matt.redfe...@mips.com wrote: From: Palmer Dabbelt As part of the MIPS conversion to use the generic GCC library routines, Matt Redfearn discovered that I'd missed a notrace on

Re: [PATCH v4 1/3] Add notrace to lib/ucmpdi2.c

Hi Palmer, On 29/03/18 22:59, Palmer Dabbelt wrote: On Thu, 29 Mar 2018 03:41:21 PDT (-0700), matt.redfe...@mips.com wrote: From: Palmer Dabbelt As part of the MIPS conversion to use the generic GCC library routines, Matt Redfearn discovered that I'd missed a notrace on __ucmpdi2().  This

Re: [PATCH RFC tools/memory-model] Add s390.{cfg,cat}

On Mon, 2 Apr 2018, Paul E. McKenney wrote: > > > I will look at this more later, reaching end of both battery and useful > > > attention span... > > Like the following, perhaps? > > Thanx, Paul > >

Re: [PATCH RFC tools/memory-model] Add s390.{cfg,cat}

On Mon, 2 Apr 2018, Paul E. McKenney wrote: > > > I will look at this more later, reaching end of both battery and useful > > > attention span... > > Like the following, perhaps? > > Thanx, Paul > >

Re: [PATCH 2/2] smp: introduce kick_active_cpus_sync()

Hi Yury, On Sun, Apr 01, 2018 at 02:11:08PM +0300, Yury Norov wrote: > +/* > + * Flush I-cache if CPU is in extended quiescent state > + */ This comment is misleading. An ISB doesn't touch the I-cache; it forces a context synchronization event. > + .macro isb_if_eqs > +#ifndef

Re: [PATCH 2/2] smp: introduce kick_active_cpus_sync()

Hi Yury, On Sun, Apr 01, 2018 at 02:11:08PM +0300, Yury Norov wrote: > +/* > + * Flush I-cache if CPU is in extended quiescent state > + */ This comment is misleading. An ISB doesn't touch the I-cache; it forces a context synchronization event. > + .macro isb_if_eqs > +#ifndef

Re: Signal handling in a page fault handler

On Tue, Apr 03, 2018 at 02:20:43PM +0100, Chris Wilson wrote: > Quoting Matthew Wilcox (2018-04-03 14:10:25) > > On Tue, Apr 03, 2018 at 01:33:15PM +0100, Chris Wilson wrote: > > > Quoting Matthew Wilcox (2018-04-02 15:10:58) > > > > I don't think the graphics drivers really want to be interrupted

Re: Signal handling in a page fault handler

On Tue, Apr 03, 2018 at 02:20:43PM +0100, Chris Wilson wrote: > Quoting Matthew Wilcox (2018-04-03 14:10:25) > > On Tue, Apr 03, 2018 at 01:33:15PM +0100, Chris Wilson wrote: > > > Quoting Matthew Wilcox (2018-04-02 15:10:58) > > > > I don't think the graphics drivers really want to be interrupted

Re: [alsa-devel] [PATCH] ASoC: atmel_ssc_dai: fix spelling mistake: "Stoping" -> "Stopping"

On Fri, Mar 30, 2018 at 04:44:20PM +0100, Colin King wrote: > From: Colin Ian King Hello Colin, > Trivial fix to spelling mistake in pr_debug message text would you mind making this patch a bit less non-trivial and change pr_debug to dev_dbg dropping Atmel_ssc_dai

Re: [alsa-devel] [PATCH] ASoC: atmel_ssc_dai: fix spelling mistake: "Stoping" -> "Stopping"

On Fri, Mar 30, 2018 at 04:44:20PM +0100, Colin King wrote: > From: Colin Ian King Hello Colin, > Trivial fix to spelling mistake in pr_debug message text would you mind making this patch a bit less non-trivial and change pr_debug to dev_dbg dropping Atmel_ssc_dai prefix? Thank you. >

Re: [PATCH v17 04/10] PCI: Apply the new generic I/O management on PCI IO hosts

On Thu, Mar 15, 2018 at 02:15:53AM +0800, John Garry wrote: > From: Zhichang Yuan > > After introducing the new generic I/O space management(Logical PIO), the > original PCI MMIO relevant helpers need to be updated based on the new > interfaces defined in logical PIO.

Re: [PATCH v17 04/10] PCI: Apply the new generic I/O management on PCI IO hosts

On Thu, Mar 15, 2018 at 02:15:53AM +0800, John Garry wrote: > From: Zhichang Yuan > > After introducing the new generic I/O space management(Logical PIO), the > original PCI MMIO relevant helpers need to be updated based on the new > interfaces defined in logical PIO. > This patch adapts the

RE: Re: [PATCH 1/1] lz4: Implement lz4 with dynamic offset length.

Hi Sergey, >You shrink a 2 bytes offset down to a 1 byte offset, thus you enforce that 2 Byte offset is not shrinked to 1 byte, Its only 1 bit is reserved out of 16 bits of offset. So only 15 Bits can be used to store offset value. >'page should be less than 32KB', which I'm sure will be

RE: Re: [PATCH 1/1] lz4: Implement lz4 with dynamic offset length.

Hi Sergey, >You shrink a 2 bytes offset down to a 1 byte offset, thus you enforce that 2 Byte offset is not shrinked to 1 byte, Its only 1 bit is reserved out of 16 bits of offset. So only 15 Bits can be used to store offset value. >'page should be less than 32KB', which I'm sure will be

[PATCH] arm64: allwinner: h6: restore the usage of CCU slice macros

As the definition of CCU slice macros are already merged into the source tree, restore the usage of the macros now. Signed-off-by: Icenowy Zheng --- arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 20 +++- 1 file changed, 11 insertions(+), 9 deletions(-) diff

[PATCH] arm64: allwinner: h6: restore the usage of CCU slice macros

As the definition of CCU slice macros are already merged into the source tree, restore the usage of the macros now. Signed-off-by: Icenowy Zheng --- arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 20 +++- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git

Re: [PATCH v3] vsprintf: Prevent crash when dereferencing invalid pointers

On Tue, 2018-04-03 at 15:13 +0200, Petr Mladek wrote: > On Tue 2018-04-03 14:54:18, Andy Shevchenko wrote: > > On Tue, 2018-04-03 at 13:46 +0200, Petr Mladek wrote: > > > On Mon 2018-04-02 17:15:23, Andy Shevchenko wrote: > > > > On Thu, 2018-03-29 at 16:53 +0200, Petr Mladek wrote: > > > > > On

Re: [PATCH v3] vsprintf: Prevent crash when dereferencing invalid pointers

On Tue, 2018-04-03 at 15:13 +0200, Petr Mladek wrote: > On Tue 2018-04-03 14:54:18, Andy Shevchenko wrote: > > On Tue, 2018-04-03 at 13:46 +0200, Petr Mladek wrote: > > > On Mon 2018-04-02 17:15:23, Andy Shevchenko wrote: > > > > On Thu, 2018-03-29 at 16:53 +0200, Petr Mladek wrote: > > > > > On

Re: [PATCH v3 07/14] KVM: s390: interfaces to configure/deconfigure guest's AP matrix

On Tue, 3 Apr 2018 09:17:59 -0400 Tony Krowiak wrote: > On 04/03/2018 07:07 AM, Cornelia Huck wrote: > > On Wed, 14 Mar 2018 14:25:47 -0400 > > Tony Krowiak wrote: > > > >> Provides interfaces to assign AP adapters, usage domains > >>

Re: [PATCH v3 07/14] KVM: s390: interfaces to configure/deconfigure guest's AP matrix

On Tue, 3 Apr 2018 09:17:59 -0400 Tony Krowiak wrote: > On 04/03/2018 07:07 AM, Cornelia Huck wrote: > > On Wed, 14 Mar 2018 14:25:47 -0400 > > Tony Krowiak wrote: > > > >> Provides interfaces to assign AP adapters, usage domains > >> and control domains to a KVM guest. > >> > >> A KVM guest

Re: [PATCH v2 1/3] locking: Document the semantics of spin_is_locked()

On Tue, Apr 03, 2018 at 01:49:09PM +0100, David Howells wrote: > Andrea Parri wrote: > > > +/** > > + * spin_is_locked() - Check whether a spinlock is locked. > > + * @lock: Pointer to the spinlock. > > + * > > + * This function is NOT required to provide any

Re: [PATCH v2 1/3] locking: Document the semantics of spin_is_locked()

On Tue, Apr 03, 2018 at 01:49:09PM +0100, David Howells wrote: > Andrea Parri wrote: > > > +/** > > + * spin_is_locked() - Check whether a spinlock is locked. > > + * @lock: Pointer to the spinlock. > > + * > > + * This function is NOT required to provide any memory ordering > > + * guarantees;

Re: [PATCH] MAINTAINERS: Add drm/xen-front maintainer entry

On 04/03/2018 03:32 PM, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Add myself as drivers/gpu/drm/xen maintainer. Signed-off-by: Oleksandr Andrushchenko --- MAINTAINERS | 9 + 1 file changed, 9

[PATCH 1/1] taging: fbtft: fix memory leak

From: Xidong Wang <2711406...@qq.com> In function fbtft_framebuffer_alloc(), the memory allocated by framebuffer_alloc() is not released on the error path that txbuflen > 0 and txbuf, which holds the return value of devm_kzalloc(), is NULL. This will result in a memory leak bug. Signed-off-by:

Re: [PATCH] MAINTAINERS: Add drm/xen-front maintainer entry

On 04/03/2018 03:32 PM, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Add myself as drivers/gpu/drm/xen maintainer. Signed-off-by: Oleksandr Andrushchenko --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index

[PATCH 1/1] taging: fbtft: fix memory leak

From: Xidong Wang <2711406...@qq.com> In function fbtft_framebuffer_alloc(), the memory allocated by framebuffer_alloc() is not released on the error path that txbuflen > 0 and txbuf, which holds the return value of devm_kzalloc(), is NULL. This will result in a memory leak bug. Signed-off-by:

Re: [PATCH v3 08/14] s390: vfio-ap: sysfs interfaces to configure adapters

On 04/03/2018 07:10 AM, Cornelia Huck wrote: On Wed, 14 Mar 2018 14:25:48 -0400 Tony Krowiak wrote: diff --git a/drivers/s390/crypto/vfio_ap_private.h b/drivers/s390/crypto/vfio_ap_private.h index a388b66..f6e7ed1 100644 ---

Re: [PATCH v3 08/14] s390: vfio-ap: sysfs interfaces to configure adapters

On 04/03/2018 07:10 AM, Cornelia Huck wrote: On Wed, 14 Mar 2018 14:25:48 -0400 Tony Krowiak wrote: diff --git a/drivers/s390/crypto/vfio_ap_private.h b/drivers/s390/crypto/vfio_ap_private.h index a388b66..f6e7ed1 100644 --- a/drivers/s390/crypto/vfio_ap_private.h +++

Multiple generic PHY instances for DWC3 USB IP

Hi. Currently, DWC3 core IP (drivers/usb/dwc3/core.c) can take only one PHY phandle for each of SS, HS. (phy-names DT property is "usb2-phy" and "usb3-phy" for each) The DWC3 core IP is provided by Synopsys, but some SoC-dependent parts (a.k.a glue-layer) are implemented by SoC venders. The

Multiple generic PHY instances for DWC3 USB IP

Hi. Currently, DWC3 core IP (drivers/usb/dwc3/core.c) can take only one PHY phandle for each of SS, HS. (phy-names DT property is "usb2-phy" and "usb3-phy" for each) The DWC3 core IP is provided by Synopsys, but some SoC-dependent parts (a.k.a glue-layer) are implemented by SoC venders. The

Re: [PATCH v1] kernel/trace:check the val against the available mem

On Tue, 3 Apr 2018 14:35:14 +0200 Michal Hocko wrote: > > If we use NORETRY, then we have those that complain that we do not try > > hard enough to reclaim memory. If we use RETRY_MAYFAIL we have this > > issue of taking up all memory before we get what we want. > > Just

Re: [PATCH v1] kernel/trace:check the val against the available mem

On Tue, 3 Apr 2018 14:35:14 +0200 Michal Hocko wrote: > > If we use NORETRY, then we have those that complain that we do not try > > hard enough to reclaim memory. If we use RETRY_MAYFAIL we have this > > issue of taking up all memory before we get what we want. > > Just try to do what admin

Re: [PATCH V3 4/4] genirq/affinity: irq vector spread among online CPUs as far as possible

On Thu, 8 Mar 2018, Ming Lei wrote: > 1) before 84676c1f21 ("genirq/affinity: assign vectors to all possible CPUs") > irq 39, cpu list 0 > irq 40, cpu list 1 > irq 41, cpu list 2 > irq 42, cpu list 3 > > 2) after 84676c1f21 ("genirq/affinity: assign vectors to all possible

Re: [PATCH V3 4/4] genirq/affinity: irq vector spread among online CPUs as far as possible

On Thu, 8 Mar 2018, Ming Lei wrote: > 1) before 84676c1f21 ("genirq/affinity: assign vectors to all possible CPUs") > irq 39, cpu list 0 > irq 40, cpu list 1 > irq 41, cpu list 2 > irq 42, cpu list 3 > > 2) after 84676c1f21 ("genirq/affinity: assign vectors to all possible

Re: [RFC PATCH 1/1] vmscan: Support multiple kswapd threads per node

On Mon 02-04-18 09:24:22, Buddy Lumpkin wrote: > Page replacement is handled in the Linux Kernel in one of two ways: > > 1) Asynchronously via kswapd > 2) Synchronously, via direct reclaim > > At page allocation time the allocating task is immediately given a page > from the zone free list

Re: [RFC PATCH 1/1] vmscan: Support multiple kswapd threads per node

On Mon 02-04-18 09:24:22, Buddy Lumpkin wrote: > Page replacement is handled in the Linux Kernel in one of two ways: > > 1) Asynchronously via kswapd > 2) Synchronously, via direct reclaim > > At page allocation time the allocating task is immediately given a page > from the zone free list

Re: [PATCH 1/1] taging: fbtft: fix memory leak

On Tue, Apr 03, 2018 at 09:14:28PM +0800, Xidong Wang wrote: > From: Xidong Wang <2711406...@qq.com> > > In function fbtft_framebuffer_alloc(), the memory allocated by > framebuffer_alloc() is not released on the error path that txbuflen > 0 > and txbuf, which holds the return value of

Re: [PATCH 1/1] taging: fbtft: fix memory leak

On Tue, Apr 03, 2018 at 09:14:28PM +0800, Xidong Wang wrote: > From: Xidong Wang <2711406...@qq.com> > > In function fbtft_framebuffer_alloc(), the memory allocated by > framebuffer_alloc() is not released on the error path that txbuflen > 0 > and txbuf, which holds the return value of

Re: [PATCH 05/45] C++: Set compilation as C++ for .c files

On Tue, Apr 03, 2018 at 02:16:50PM +0100, David Howells wrote: kbuild test robot wrote: scripts/Makefile.kasan:17: Cannot use CONFIG_KASAN: -fsanitize=kernel-address is not supported by compiler cc1: warning: command line option '-fno-rtti' is valid for C++/ObjC++ but

Re: [PATCH 05/45] C++: Set compilation as C++ for .c files

On Tue, Apr 03, 2018 at 02:16:50PM +0100, David Howells wrote: kbuild test robot wrote: scripts/Makefile.kasan:17: Cannot use CONFIG_KASAN: -fsanitize=kernel-address is not supported by compiler cc1: warning: command line option '-fno-rtti' is valid for C++/ObjC++ but not for C

Re: [PATCH] vhost-net: add limitation of sent packets for tx polling

On Tue, Apr 03, 2018 at 12:29:47PM +, haibinzhang(张海斌) wrote: > > >On Tue, Apr 03, 2018 at 08:08:26AM +, haibinzhang wrote: > >> handle_tx will delay rx for a long time when tx busy polling udp packets > >> with small length(e.g. 1byte udp payload), because setting VHOST_NET_WEIGHT > >>

Re: [PATCH] vhost-net: add limitation of sent packets for tx polling

On Tue, Apr 03, 2018 at 12:29:47PM +, haibinzhang(张海斌) wrote: > > >On Tue, Apr 03, 2018 at 08:08:26AM +, haibinzhang wrote: > >> handle_tx will delay rx for a long time when tx busy polling udp packets > >> with small length(e.g. 1byte udp payload), because setting VHOST_NET_WEIGHT > >>

Re: [GIT PULL] Kernel lockdown for secure boot

(+ Andy and Kees so they can respond to the thread) On 31 March 2018 at 12:20, David Howells wrote: > James Morris wrote: > >> Are there any known coverage gaps now? > > I've covered all the ones I know about. > Andy (and Kees) responded to this without

Re: [GIT PULL] Kernel lockdown for secure boot

(+ Andy and Kees so they can respond to the thread) On 31 March 2018 at 12:20, David Howells wrote: > James Morris wrote: > >> Are there any known coverage gaps now? > > I've covered all the ones I know about. > Andy (and Kees) responded to this without keeping all the cc's. Given that I share

[PATCH v3 1/3] clk: qcom: Clear hardware clock control bit of RCG

For upcoming targets like sdm845, POR value of the hardware clock control bit is set for most of root clocks which needs to be cleared for software to be able to control. For older targets like MSM8996, this bit is reserved bit and having POR value as 0 so this patch will work for the older

[PATCH v3 1/3] clk: qcom: Clear hardware clock control bit of RCG

For upcoming targets like sdm845, POR value of the hardware clock control bit is set for most of root clocks which needs to be cleared for software to be able to control. For older targets like MSM8996, this bit is reserved bit and having POR value as 0 so this patch will work for the older

[PATCH v3 3/3] clk: qcom: Add Global Clock controller (GCC) driver for SDM845

From: Taniya Das Add support for the global clock controller found on SDM845 based devices. This should allow most non-multimedia device drivers to probe and control their clocks. Signed-off-by: Taniya Das Signed-off-by: Amit Nischal

[PATCH v3 3/3] clk: qcom: Add Global Clock controller (GCC) driver for SDM845

From: Taniya Das Add support for the global clock controller found on SDM845 based devices. This should allow most non-multimedia device drivers to probe and control their clocks. Signed-off-by: Taniya Das Signed-off-by: Amit Nischal --- The patch is dependent upon the below patches related

[PATCH v3 2/3] clk: qcom: Configure the RCGs to a safe source as needed

For some root clock generators, there could be child branches which are controlled by an entity other than application processor subsystem. For such RCGs, as per application processor subsystem clock driver, all of its downstream clocks are disabled and RCG is in disabled state but in reality

[PATCH v3 2/3] clk: qcom: Configure the RCGs to a safe source as needed

For some root clock generators, there could be child branches which are controlled by an entity other than application processor subsystem. For such RCGs, as per application processor subsystem clock driver, all of its downstream clocks are disabled and RCG is in disabled state but in reality

[PATCH v3 0/3] Misc patches to support clocks for SDM845

Changes in v3: 1. Adressed review comments given for v2 series. 2. The GCC clock driver(patch 3) depends upon the below patches related to GDSC operation and are under review. https://lkml.org/lkml/2018/4/2/142 Changes in v2: Fixup for recalc_rate ops for clk_rcg2_shared_ops: There could

[PATCH v3 0/3] Misc patches to support clocks for SDM845

Changes in v3: 1. Adressed review comments given for v2 series. 2. The GCC clock driver(patch 3) depends upon the below patches related to GDSC operation and are under review. https://lkml.org/lkml/2018/4/2/142 Changes in v2: Fixup for recalc_rate ops for clk_rcg2_shared_ops: There could

Re: [PATCH 3/8] bindings: PCI: designware: Add support for the EP in designware driver

Hi Kishon, On 03/04/2018 11:55, Kishon Vijay Abraham I wrote: > Hi, > > On Tuesday 03 April 2018 04:13 PM, Gustavo Pimentel wrote: >> Hi Kishon, >> >> On 02/04/2018 06:35, Kishon Vijay Abraham I wrote: >>> >>> >>> On Wednesday 28 March 2018 05:08 PM, Gustavo Pimentel wrote: Signed-off-by:

Re: [PATCH 3/8] bindings: PCI: designware: Add support for the EP in designware driver

Hi Kishon, On 03/04/2018 11:55, Kishon Vijay Abraham I wrote: > Hi, > > On Tuesday 03 April 2018 04:13 PM, Gustavo Pimentel wrote: >> Hi Kishon, >> >> On 02/04/2018 06:35, Kishon Vijay Abraham I wrote: >>> >>> >>> On Wednesday 28 March 2018 05:08 PM, Gustavo Pimentel wrote: Signed-off-by:

Re: Signal handling in a page fault handler

On 04/03/2018 02:33 PM, Chris Wilson wrote: Quoting Matthew Wilcox (2018-04-02 15:10:58) Souptick and I have been auditing the various page fault handler routines and we've noticed that graphics drivers assume that a signal should be able to interrupt a page fault. In contrast, the page cache

Re: [PATCH 2/3] virt: vbox: Use __get_free_pages instead of kmalloc for DMA32 memory

Hi, On 29-03-18 18:39, Greg Kroah-Hartman wrote: On Thu, Mar 29, 2018 at 03:42:59PM +0200, Hans de Goede wrote: Hi, On 29-03-18 13:58, Greg Kroah-Hartman wrote: On Thu, Mar 29, 2018 at 01:21:15PM +0200, Hans de Goede wrote: It is not possible to get DMA32 zone memory through kmalloc, Why

Re: Signal handling in a page fault handler

On 04/03/2018 02:33 PM, Chris Wilson wrote: Quoting Matthew Wilcox (2018-04-02 15:10:58) Souptick and I have been auditing the various page fault handler routines and we've noticed that graphics drivers assume that a signal should be able to interrupt a page fault. In contrast, the page cache

Re: [PATCH 2/3] virt: vbox: Use __get_free_pages instead of kmalloc for DMA32 memory

Hi, On 29-03-18 18:39, Greg Kroah-Hartman wrote: On Thu, Mar 29, 2018 at 03:42:59PM +0200, Hans de Goede wrote: Hi, On 29-03-18 13:58, Greg Kroah-Hartman wrote: On Thu, Mar 29, 2018 at 01:21:15PM +0200, Hans de Goede wrote: It is not possible to get DMA32 zone memory through kmalloc, Why

Re: [PATCH 1/6] drivers/i2c: Update i2c_trace_msg static key to modern api

On Mon, Mar 26, 2018 at 02:09:24PM -0700, Davidlohr Bueso wrote: > No changes in refcount semantics -- key init is false; replace > > static_key_slow_inc|dec with static_branch_inc|dec > static_key_false with static_branch_unlikely > > Added a '_key' suffix to i2c_trace_msg, for

Re: [PATCH 1/6] drivers/i2c: Update i2c_trace_msg static key to modern api

On Mon, Mar 26, 2018 at 02:09:24PM -0700, Davidlohr Bueso wrote: > No changes in refcount semantics -- key init is false; replace > > static_key_slow_inc|dec with static_branch_inc|dec > static_key_false with static_branch_unlikely > > Added a '_key' suffix to i2c_trace_msg, for

Re: [PATCH v3 07/14] KVM: s390: interfaces to configure/deconfigure guest's AP matrix

On 04/03/2018 07:07 AM, Cornelia Huck wrote: On Wed, 14 Mar 2018 14:25:47 -0400 Tony Krowiak wrote: Provides interfaces to assign AP adapters, usage domains and control domains to a KVM guest. A KVM guest is started by executing the Start Interpretive Execution

Re: [PATCH v3 07/14] KVM: s390: interfaces to configure/deconfigure guest's AP matrix

On 04/03/2018 07:07 AM, Cornelia Huck wrote: On Wed, 14 Mar 2018 14:25:47 -0400 Tony Krowiak wrote: Provides interfaces to assign AP adapters, usage domains and control domains to a KVM guest. A KVM guest is started by executing the Start Interpretive Execution (SIE) instruction. The SIE

[PATCH 1/1] taging: fbtft: fix memory leak

From: Xidong Wang <2711406...@qq.com> In function fbtft_framebuffer_alloc(), the memory allocated by framebuffer_alloc() is not released on the error path that txbuflen > 0 and txbuf, which holds the return value of devm_kzalloc(), is NULL. This will result in a memory leak bug. Signed-off-by:

[PATCH 1/1] taging: fbtft: fix memory leak

From: Xidong Wang <2711406...@qq.com> In function fbtft_framebuffer_alloc(), the memory allocated by framebuffer_alloc() is not released on the error path that txbuflen > 0 and txbuf, which holds the return value of devm_kzalloc(), is NULL. This will result in a memory leak bug. Signed-off-by:

Re: [PATCH 05/45] C++: Set compilation as C++ for .c files

kbuild test robot wrote: >scripts/Makefile.kasan:17: Cannot use CONFIG_KASAN: > -fsanitize=kernel-address is not supported by compiler >cc1: warning: command line option '-fno-rtti' is valid for C++/ObjC++ but > not for C >cc1: warning: command line option

Re: [PATCH 05/45] C++: Set compilation as C++ for .c files

kbuild test robot wrote: >scripts/Makefile.kasan:17: Cannot use CONFIG_KASAN: > -fsanitize=kernel-address is not supported by compiler >cc1: warning: command line option '-fno-rtti' is valid for C++/ObjC++ but > not for C >cc1: warning: command line option '-fpermissive' is valid

Re: [PATCH 1/8] bindings: PCI: designware: Example update

Hi Kishon, On 03/04/2018 11:53, Kishon Vijay Abraham I wrote: > Hi, > > On Tuesday 03 April 2018 04:22 PM, Kishon Vijay Abraham I wrote: >> >> >> On Tuesday 03 April 2018 04:03 PM, Gustavo Pimentel wrote: >>> Hi Kishon, >>> >>> On 02/04/2018 06:23, Kishon Vijay Abraham I wrote: Hi,

Re: [PATCH 1/8] bindings: PCI: designware: Example update

Hi Kishon, On 03/04/2018 11:53, Kishon Vijay Abraham I wrote: > Hi, > > On Tuesday 03 April 2018 04:22 PM, Kishon Vijay Abraham I wrote: >> >> >> On Tuesday 03 April 2018 04:03 PM, Gustavo Pimentel wrote: >>> Hi Kishon, >>> >>> On 02/04/2018 06:23, Kishon Vijay Abraham I wrote: Hi,

Re: [PATCH v3] vsprintf: Prevent crash when dereferencing invalid pointers

On Tue 2018-04-03 14:54:18, Andy Shevchenko wrote: > On Tue, 2018-04-03 at 13:46 +0200, Petr Mladek wrote: > > On Mon 2018-04-02 17:15:23, Andy Shevchenko wrote: > > > On Thu, 2018-03-29 at 16:53 +0200, Petr Mladek wrote: > > > > On Fri 2018-03-16 20:19:35, Andy Shevchenko wrote: > > > > > On Thu,

Re: [PATCH v3] vsprintf: Prevent crash when dereferencing invalid pointers

On Tue 2018-04-03 14:54:18, Andy Shevchenko wrote: > On Tue, 2018-04-03 at 13:46 +0200, Petr Mladek wrote: > > On Mon 2018-04-02 17:15:23, Andy Shevchenko wrote: > > > On Thu, 2018-03-29 at 16:53 +0200, Petr Mladek wrote: > > > > On Fri 2018-03-16 20:19:35, Andy Shevchenko wrote: > > > > > On Thu,

Re: [virtio-dev] [pci PATCH v7 2/5] virtio_pci: Add support for unmanaged SR-IOV on virtio_pci devices

On Fri, Mar 16, 2018 at 09:40:34AM -0700, Alexander Duyck wrote: > On Fri, Mar 16, 2018 at 9:34 AM, Michael S. Tsirkin wrote: > > On Thu, Mar 15, 2018 at 11:42:41AM -0700, Alexander Duyck wrote: > >> From: Alexander Duyck > >> > >> Hardware-realized

Re: [virtio-dev] [pci PATCH v7 2/5] virtio_pci: Add support for unmanaged SR-IOV on virtio_pci devices

On Fri, Mar 16, 2018 at 09:40:34AM -0700, Alexander Duyck wrote: > On Fri, Mar 16, 2018 at 9:34 AM, Michael S. Tsirkin wrote: > > On Thu, Mar 15, 2018 at 11:42:41AM -0700, Alexander Duyck wrote: > >> From: Alexander Duyck > >> > >> Hardware-realized virtio_pci devices can implement SR-IOV, so

Re: [virtio-dev] [pci PATCH v7 2/5] virtio_pci: Add support for unmanaged SR-IOV on virtio_pci devices

On Thu, Mar 15, 2018 at 11:42:41AM -0700, Alexander Duyck wrote: > From: Alexander Duyck > > Hardware-realized virtio_pci devices can implement SR-IOV, so this > patch enables its use. The device in question is an upcoming Intel > NIC that implements both a

Re: [virtio-dev] [pci PATCH v7 2/5] virtio_pci: Add support for unmanaged SR-IOV on virtio_pci devices

On Thu, Mar 15, 2018 at 11:42:41AM -0700, Alexander Duyck wrote: > From: Alexander Duyck > > Hardware-realized virtio_pci devices can implement SR-IOV, so this > patch enables its use. The device in question is an upcoming Intel > NIC that implements both a virtio_net PF and virtio_net VFs.

Re: Signal handling in a page fault handler

On Tue, Apr 03, 2018 at 01:33:15PM +0100, Chris Wilson wrote: > Quoting Matthew Wilcox (2018-04-02 15:10:58) > > Souptick and I have been auditing the various page fault handler routines > > and we've noticed that graphics drivers assume that a signal should be > > able to interrupt a page fault.

Re: Signal handling in a page fault handler

On Tue, Apr 03, 2018 at 01:33:15PM +0100, Chris Wilson wrote: > Quoting Matthew Wilcox (2018-04-02 15:10:58) > > Souptick and I have been auditing the various page fault handler routines > > and we've noticed that graphics drivers assume that a signal should be > > able to interrupt a page fault.

Re: [PATCH v2 2/2] io: prevent compiler reordering on the default readX() implementation

On 4/3/2018 8:56 AM, Arnd Bergmann wrote: > On Tue, Apr 3, 2018 at 2:44 PM, Sinan Kaya wrote: >> On 4/3/2018 7:13 AM, Arnd Bergmann wrote: >>> On Tue, Apr 3, 2018 at 12:49 PM, Mark Rutland wrote: Hi, On Fri, Mar 30, 2018 at 11:58:13AM

Re: [PATCH v2 2/2] io: prevent compiler reordering on the default readX() implementation

On 4/3/2018 8:56 AM, Arnd Bergmann wrote: > On Tue, Apr 3, 2018 at 2:44 PM, Sinan Kaya wrote: >> On 4/3/2018 7:13 AM, Arnd Bergmann wrote: >>> On Tue, Apr 3, 2018 at 12:49 PM, Mark Rutland wrote: Hi, On Fri, Mar 30, 2018 at 11:58:13AM -0400, Sinan Kaya wrote: > The default

<    7   8   9   10   11   12   13   14   15   16   >