[PATCH v4] net: thunderx: rework mac addresses list to u64 array

From: Vadim Lomovtsev It is too expensive to pass u64 values via linked list, instead allocate array for them by overall number of mac addresses from netdev. This eventually removes multiple kmalloc() calls, aviod memory fragmentation and allow to put single null check on kmalloc return value

Re: Problem with commit 31e77c93e432 "sched/fair: Update blocked load when newly idle"

Am 06.04.2018 um 18:03 schrieb Vincent Guittot: > Hi Heiner, > > On 30 March 2018 at 10:37, Heiner Kallweit wrote: >> Am 30.03.2018 um 08:50 schrieb Vincent Guittot: >>> On 29 March 2018 at 19:40, Heiner Kallweit wrote: Am 29.03.2018 um 09:41 schrieb Vincent Guittot: >>> > > I'm

Re: [PATCH v1]: perf/x86: store user space frame-pointer value on a sample

On Fri, Apr 06, 2018 at 10:06:26PM +0300, Alexey Budankov wrote: > On 06.04.2018 18:31, Andi Kleen wrote: > >> diff --git a/arch/x86/kernel/perf_regs.c b/arch/x86/kernel/perf_regs.c > >> index e47b2dbbdef3..9284048cf5b0 100644 > >> --- a/arch/x86/kernel/perf_regs.c > >> +++

[PATCH] fs: Add MODULE_SOFTDEP declarations for hard-coded crypto drivers

This helps initramfs builders and other tools to find the full dependencies of a module. Debian on powerpc (ppc32) still uses yaboot as default boot loader. Using a default installation (debian-installer) 64bit and metadata_csum feature are not setup in ext4. This is discussed in more details at:

Re: [PATCH v1]: perf/x86: store user space frame-pointer value on a sample

On Fri, Apr 06, 2018 at 10:06:26PM +0300, Alexey Budankov wrote: > On 06.04.2018 18:31, Andi Kleen wrote: > >> diff --git a/arch/x86/kernel/perf_regs.c b/arch/x86/kernel/perf_regs.c > >> index e47b2dbbdef3..9284048cf5b0 100644 > >> --- a/arch/x86/kernel/perf_regs.c > >> +++

[PATCH] fs: Add MODULE_SOFTDEP declarations for hard-coded crypto drivers

This helps initramfs builders and other tools to find the full dependencies of a module. Debian on powerpc (ppc32) still uses yaboot as default boot loader. Using a default installation (debian-installer) 64bit and metadata_csum feature are not setup in ext4. This is discussed in more details at:

Re: [PATCH v10 05/10] livepatch: Support separate list for replaced patches.

On Mon, Mar 26, 2018 at 12:11:07PM +0200, Petr Mladek wrote: > On Fri 2018-03-23 17:44:10, Josh Poimboeuf wrote: > > On Fri, Mar 23, 2018 at 10:45:07AM +0100, Petr Mladek wrote: > > > On Tue 2018-03-20 15:15:02, Josh Poimboeuf wrote: > > > > On Tue, Mar 20, 2018 at 01:25:38PM +0100, Petr Mladek

Re: [PATCH v10 05/10] livepatch: Support separate list for replaced patches.

On Mon, Mar 26, 2018 at 12:11:07PM +0200, Petr Mladek wrote: > On Fri 2018-03-23 17:44:10, Josh Poimboeuf wrote: > > On Fri, Mar 23, 2018 at 10:45:07AM +0100, Petr Mladek wrote: > > > On Tue 2018-03-20 15:15:02, Josh Poimboeuf wrote: > > > > On Tue, Mar 20, 2018 at 01:25:38PM +0100, Petr Mladek

Re: [PATCH v4] drm/i915/dp: Send DPCD ON for MST before phy_up

On Fri, 2018-04-06 at 12:48 -0700, Laura Abbott wrote: > On 04/06/2018 11:52 AM, Lyude Paul wrote: > > When doing a modeset where the sink is transitioning from D3 to D0 , it > > would sometimes be possible for the initial power_up_phy() to start > > timing out. This would only be observed in the

Re: [PATCH v4] drm/i915/dp: Send DPCD ON for MST before phy_up

On Fri, 2018-04-06 at 12:48 -0700, Laura Abbott wrote: > On 04/06/2018 11:52 AM, Lyude Paul wrote: > > When doing a modeset where the sink is transitioning from D3 to D0 , it > > would sometimes be possible for the initial power_up_phy() to start > > timing out. This would only be observed in the

Re: [PATCH v4] drm/i915/dp: Send DPCD ON for MST before phy_up

On 04/06/2018 11:52 AM, Lyude Paul wrote: When doing a modeset where the sink is transitioning from D3 to D0 , it would sometimes be possible for the initial power_up_phy() to start timing out. This would only be observed in the last action before the sink went into D3 mode was

Re: [PATCH v4] drm/i915/dp: Send DPCD ON for MST before phy_up

On 04/06/2018 11:52 AM, Lyude Paul wrote: When doing a modeset where the sink is transitioning from D3 to D0 , it would sometimes be possible for the initial power_up_phy() to start timing out. This would only be observed in the last action before the sink went into D3 mode was

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

There appeared to be a certain, recurrent uncertainty concerning the semantics of spin_is_locked(), likely a consequence of the fact that this semantics remains undocumented or that it has been historically linked to the (likewise unclear) semantics of spin_unlock_wait(). A recent auditing [1] of

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

There appeared to be a certain, recurrent uncertainty concerning the semantics of spin_is_locked(), likely a consequence of the fact that this semantics remains undocumented or that it has been historically linked to the (likewise unclear) semantics of spin_unlock_wait(). A recent auditing [1] of

Re: [PATCH 0/4 v2] init, tracing: Add initcall trace events

On Fri, 6 Apr 2018 21:34:24 +0200 Peter Zijlstra wrote: > On Fri, Apr 06, 2018 at 03:19:23PM -0400, Steven Rostedt wrote: > > > > Peter, Andrew, > > > > This keeps initcall_debug printing printk()s, but adds the feature of > > those locations also being trace events. Are

Re: [PATCH 0/4 v2] init, tracing: Add initcall trace events

On Fri, 6 Apr 2018 21:34:24 +0200 Peter Zijlstra wrote: > On Fri, Apr 06, 2018 at 03:19:23PM -0400, Steven Rostedt wrote: > > > > Peter, Andrew, > > > > This keeps initcall_debug printing printk()s, but adds the feature of > > those locations also being trace events. Are you OK if I add this?

Re: [PATCH] swap: divide-by-zero when zero length swap file on ssd

On Fri, 6 Apr 2018 09:52:50 -0700 Randy Dunlap wrote: > [adding linux-mm and akpm] Thanks. > ... The patch is a huge mess, with leading and trailing whitespace. I fixed all that up, but we'd like to receive Tom's signed-off-by:, please.

Re: [PATCH] swap: divide-by-zero when zero length swap file on ssd

On Fri, 6 Apr 2018 09:52:50 -0700 Randy Dunlap wrote: > [adding linux-mm and akpm] Thanks. > ... The patch is a huge mess, with leading and trailing whitespace. I fixed all that up, but we'd like to receive Tom's signed-off-by:, please. Documentation/process/submitting-patches.rst section

Re: [PATCH net-next 00/12] fscache: Fixes, traces and development

On Fri, Apr 6, 2018 at 12:28 PM, David Howells wrote: > > That's okay with all the patches as follow up emails? Actually, I generally just look at the git tree and don't need the individual patches at all, at least as long as they are only to a particular subsystem. So if

Re: [PATCH net-next 00/12] fscache: Fixes, traces and development

On Fri, Apr 6, 2018 at 12:28 PM, David Howells wrote: > > That's okay with all the patches as follow up emails? Actually, I generally just look at the git tree and don't need the individual patches at all, at least as long as they are only to a particular subsystem. So if your git tree only

Re: [PATCH] mfd: twl-core: Fix clock initialization

On 04/05/2018 02:46 PM, Peter Ujfalusi wrote: > When looking up the clock we must use the client->dev as device since that > is the one which is probed via DT. > > Signed-off-by: Peter Ujfalusi > Cc: sta...@vger.kernel.org > Fixes: 7e2e6c5758de9 ("mfd: twl-core: Do not

Re: [PATCH] mfd: twl-core: Fix clock initialization

On 04/05/2018 02:46 PM, Peter Ujfalusi wrote: > When looking up the clock we must use the client->dev as device since that > is the one which is probed via DT. > > Signed-off-by: Peter Ujfalusi > Cc: sta...@vger.kernel.org > Fixes: 7e2e6c5758de9 ("mfd: twl-core: Do not create dummy pdata when

Re: [PATCH for-4.16 2/3] drivers: change struct device_driver::coredump() return type to void

Op vr 6 apr. 2018 4:46 PM schreef Greg Kroah-Hartman : > > On Fri, Apr 06, 2018 at 12:13:38PM +0200, Arend van Spriel wrote: > > On Sat, Mar 24, 2018 at 10:04 AM, Greg Kroah-Hartman > > wrote: > > > On Sat, Mar 24, 2018 at 09:50:05AM +0100,

Re: [PATCH for-4.16 2/3] drivers: change struct device_driver::coredump() return type to void

Op vr 6 apr. 2018 4:46 PM schreef Greg Kroah-Hartman : > > On Fri, Apr 06, 2018 at 12:13:38PM +0200, Arend van Spriel wrote: > > On Sat, Mar 24, 2018 at 10:04 AM, Greg Kroah-Hartman > > wrote: > > > On Sat, Mar 24, 2018 at 09:50:05AM +0100, Arend van Spriel wrote: > > >> On Fri, Mar 23, 2018 at

Re: [PATCH 0/4 v2] init, tracing: Add initcall trace events

On Fri, Apr 06, 2018 at 03:19:23PM -0400, Steven Rostedt wrote: > > Peter, Andrew, > > This keeps initcall_debug printing printk()s, but adds the feature of > those locations also being trace events. Are you OK if I add this? Yeah, I don't see any real problems with it.

Re: [PATCH 0/4 v2] init, tracing: Add initcall trace events

On Fri, Apr 06, 2018 at 03:19:23PM -0400, Steven Rostedt wrote: > > Peter, Andrew, > > This keeps initcall_debug printing printk()s, but adds the feature of > those locations also being trace events. Are you OK if I add this? Yeah, I don't see any real problems with it.

Re: [PATCH net-next 00/12] fscache: Fixes, traces and development

Linus Torvalds wrote: > So if you have that [GIT PULL] in the subject line, the pulls will > often be a bit timelier. That's okay with all the patches as follow up emails? David

Re: [PATCH net-next 00/12] fscache: Fixes, traces and development

Linus Torvalds wrote: > So if you have that [GIT PULL] in the subject line, the pulls will > often be a bit timelier. That's okay with all the patches as follow up emails? David

Re: [LINUX PATCH v8 2/2] mtd: rawnand: pl353: Add basic driver for arm pl353 smc nand interface

On 03/23/2018 09:58 AM, Naga Sureshkumar Relli wrote: Hi Miquel, Thanks for reviewing the patch. Please see my comments inline. -Original Message- From: Miquel Raynal [mailto:miquel.ray...@bootlin.com] Sent: Tuesday, March 20, 2018 4:08 AM To: nagasureshkumarre...@gmail.com Cc:

Re: [LINUX PATCH v8 2/2] mtd: rawnand: pl353: Add basic driver for arm pl353 smc nand interface

On 03/23/2018 09:58 AM, Naga Sureshkumar Relli wrote: Hi Miquel, Thanks for reviewing the patch. Please see my comments inline. -Original Message- From: Miquel Raynal [mailto:miquel.ray...@bootlin.com] Sent: Tuesday, March 20, 2018 4:08 AM To: nagasureshkumarre...@gmail.com Cc:

Re: [Question] patch posting process

Hi Vadim, On Fri, Apr 06, 2018 at 11:29:16AM -0700, Vadim Lomovtsev wrote: > Hi all, > > I bring my Apologise for wasting your time, but .. Questions about doing things right rarely are a waste of time if they save others from having to do useless work! > May I ask for some clarification..

Re: [Question] patch posting process

Hi Vadim, On Fri, Apr 06, 2018 at 11:29:16AM -0700, Vadim Lomovtsev wrote: > Hi all, > > I bring my Apologise for wasting your time, but .. Questions about doing things right rarely are a waste of time if they save others from having to do useless work! > May I ask for some clarification..

Re: [PATCH v4] drm/i915/dp: Send DPCD ON for MST before phy_up

On Fri, Apr 06, 2018 at 12:28:30PM -0700, Dhinakaran Pandiyan wrote: > > > > On Fri, 2018-04-06 at 14:52 -0400, Lyude Paul wrote: > > When doing a modeset where the sink is transitioning from D3 to D0 , it > > would sometimes be possible for the initial power_up_phy() to start > > timing out.

Re: [PATCH v4] drm/i915/dp: Send DPCD ON for MST before phy_up

On Fri, Apr 06, 2018 at 12:28:30PM -0700, Dhinakaran Pandiyan wrote: > > > > On Fri, 2018-04-06 at 14:52 -0400, Lyude Paul wrote: > > When doing a modeset where the sink is transitioning from D3 to D0 , it > > would sometimes be possible for the initial power_up_phy() to start > > timing out.

Re: [PATCH 0/4 v2] init, tracing: Add initcall trace events

Peter, Andrew, This keeps initcall_debug printing printk()s, but adds the feature of those locations also being trace events. Are you OK if I add this? Works with and without TRACEPOINTS enabled. -- Steve On Fri, 06 Apr 2018 15:08:54 -0400 Steven Rostedt wrote: > A

Re: [PATCH 0/4 v2] init, tracing: Add initcall trace events

Peter, Andrew, This keeps initcall_debug printing printk()s, but adds the feature of those locations also being trace events. Are you OK if I add this? Works with and without TRACEPOINTS enabled. -- Steve On Fri, 06 Apr 2018 15:08:54 -0400 Steven Rostedt wrote: > A while ago we had a boot

[PATCH 4/4 v2] init: Have initcall_debug still work without CONFIG_TRACEPOINTS

From: "Steven Rostedt (VMware)" Add macros around the initcall_debug tracepoint code to have the code to default back to the old method if CONFIG_TRACEPOINTS is not enabled. Signed-off-by: Steven Rostedt (VMware) --- init/main.c | 24

[PATCH 4/4 v2] init: Have initcall_debug still work without CONFIG_TRACEPOINTS

From: "Steven Rostedt (VMware)" Add macros around the initcall_debug tracepoint code to have the code to default back to the old method if CONFIG_TRACEPOINTS is not enabled. Signed-off-by: Steven Rostedt (VMware) --- init/main.c | 24 ++-- 1 file changed, 22 insertions(+),

[PATCH 0/4 v2] init, tracing:

A while ago we had a boot tracer. But it was eventually removed: commit 30dbb20e68e6f ("tracing: Remove boot tracer"). The rationale was because there is already a initcall_debug boot option that causes printk()s of all the initcall functions. The problem with the initcall_debug option is that

[PATCH 0/4 v2] init, tracing:

A while ago we had a boot tracer. But it was eventually removed: commit 30dbb20e68e6f ("tracing: Remove boot tracer"). The rationale was because there is already a initcall_debug boot option that causes printk()s of all the initcall functions. The problem with the initcall_debug option is that

[PATCH 1/4 v2] init, tracing: Add initcall trace events

From: "Steven Rostedt (VMware)" Being able to trace the start and stop of initcalls is useful to see where the timings are an issue. There is already an "initcall_debug" parameter, but that can cause a large overhead itself, as the printing of the information may take longer

[PATCH 1/4 v2] init, tracing: Add initcall trace events

From: "Steven Rostedt (VMware)" Being able to trace the start and stop of initcalls is useful to see where the timings are an issue. There is already an "initcall_debug" parameter, but that can cause a large overhead itself, as the printing of the information may take longer than the initcall

Re: [PATCH 0/4 v2] init, tracing: Add initcall trace events

Bah, Saved the cover letter before putting back in the original subject. -- Steve

Re: [PATCH 0/4 v2] init, tracing: Add initcall trace events

Bah, Saved the cover letter before putting back in the original subject. -- Steve

[PATCH 2/4 v2] init, tracing: instrument security and console initcall trace events

From: Abderrahmane Benbachir Trace events have been added around the initcall functions defined in init/main.c. But console and security have their own initcalls. This adds the trace events associated for those initcall functions. Link:

[PATCH 3/4 v2] init, tracing: Have printk come through the trace events for initcall_debug

From: "Steven Rostedt (VMware)" With trace events set before and after the initcall function calls, instead of having a separate routine for printing out the initcalls when initcall_debug is specified on the kernel command line, have the code register a callback to the

[PATCH 2/4 v2] init, tracing: instrument security and console initcall trace events

From: Abderrahmane Benbachir Trace events have been added around the initcall functions defined in init/main.c. But console and security have their own initcalls. This adds the trace events associated for those initcall functions. Link:

[PATCH 3/4 v2] init, tracing: Have printk come through the trace events for initcall_debug

From: "Steven Rostedt (VMware)" With trace events set before and after the initcall function calls, instead of having a separate routine for printing out the initcalls when initcall_debug is specified on the kernel command line, have the code register a callback to the tracepoints where the

Re: [PATCH 3.18 00/93] 3.18.103-stable review

On 6 April 2018 6:52:29 PM IST, Greg Kroah-Hartman wrote: >This is the start of the stable review cycle for the 3.18.103 release. >There are 93 patches in this series, all will be posted as a response >to this one. If anyone has any issues with these being applied,

Re: [PATCH 3.18 00/93] 3.18.103-stable review

On 6 April 2018 6:52:29 PM IST, Greg Kroah-Hartman wrote: >This is the start of the stable review cycle for the 3.18.103 release. >There are 93 patches in this series, all will be posted as a response >to this one. If anyone has any issues with these being applied, please >let me know. >

s390: defective uses of va_arg in __debug_sprintf_event

debug_sprintf_event calls __debug_sprintf_event with a format and arguments. There various types of arguments used in these call, but __debug_sprintf_event uses va_arg with only long as the type argument so random errors could occur because the type and argument are supposed to match.

s390: defective uses of va_arg in __debug_sprintf_event

debug_sprintf_event calls __debug_sprintf_event with a format and arguments. There various types of arguments used in these call, but __debug_sprintf_event uses va_arg with only long as the type argument so random errors could occur because the type and argument are supposed to match.

Re: [PATCH v1]: perf/x86: store user space frame-pointer value on a sample

On 06.04.2018 18:31, Andi Kleen wrote: >> diff --git a/arch/x86/kernel/perf_regs.c b/arch/x86/kernel/perf_regs.c >> index e47b2dbbdef3..9284048cf5b0 100644 >> --- a/arch/x86/kernel/perf_regs.c >> +++ b/arch/x86/kernel/perf_regs.c >> @@ -157,6 +157,15 @@ void perf_get_regs_user(struct perf_regs

Re: [PATCH v1]: perf/x86: store user space frame-pointer value on a sample

On 06.04.2018 18:31, Andi Kleen wrote: >> diff --git a/arch/x86/kernel/perf_regs.c b/arch/x86/kernel/perf_regs.c >> index e47b2dbbdef3..9284048cf5b0 100644 >> --- a/arch/x86/kernel/perf_regs.c >> +++ b/arch/x86/kernel/perf_regs.c >> @@ -157,6 +157,15 @@ void perf_get_regs_user(struct perf_regs

Re: [PATCH v4] drm/i915/dp: Send DPCD ON for MST before phy_up

On Fri, 2018-04-06 at 14:52 -0400, Lyude Paul wrote: > When doing a modeset where the sink is transitioning from D3 to D0 , it > would sometimes be possible for the initial power_up_phy() to start > timing out. This would only be observed in the last action before the > sink went into D3 mode

Re: [PATCH v4] drm/i915/dp: Send DPCD ON for MST before phy_up

On Fri, 2018-04-06 at 14:52 -0400, Lyude Paul wrote: > When doing a modeset where the sink is transitioning from D3 to D0 , it > would sometimes be possible for the initial power_up_phy() to start > timing out. This would only be observed in the last action before the > sink went into D3 mode

kernel BUG at drivers/vhost/vhost.c:LINE! (2)

Hello, syzbot hit the following crash on upstream commit 38c23685b273cfb4ccf31a199feccce3bdcb5d83 (Fri Apr 6 04:29:35 2018 +) Merge tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc syzbot dashboard link:

kernel BUG at drivers/vhost/vhost.c:LINE! (2)

Hello, syzbot hit the following crash on upstream commit 38c23685b273cfb4ccf31a199feccce3bdcb5d83 (Fri Apr 6 04:29:35 2018 +) Merge tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc syzbot dashboard link:

Re: [PATCH 8/8] drm/arm/malidp: Added the late system pm functions

On Tue, Mar 27, 2018 at 01:09:36PM +0200, Daniel Vetter wrote: > On Tue, Mar 27, 2018 at 11:59 AM, Ayan Halder wrote: > > On Tue, Mar 27, 2018 at 10:29:03AM +0200, Daniel Vetter wrote: > >> On Mon, Mar 26, 2018 at 06:03:20PM +0100, Ayan Kumar Halder wrote: > >> >

Re: [PATCH 8/8] drm/arm/malidp: Added the late system pm functions

On Tue, Mar 27, 2018 at 01:09:36PM +0200, Daniel Vetter wrote: > On Tue, Mar 27, 2018 at 11:59 AM, Ayan Halder wrote: > > On Tue, Mar 27, 2018 at 10:29:03AM +0200, Daniel Vetter wrote: > >> On Mon, Mar 26, 2018 at 06:03:20PM +0100, Ayan Kumar Halder wrote: > >> > malidp_pm_suspend_late checks if

[GIT PULL] PCI changes for v4.17

PCI changes: - move pci_uevent_ers() out of pci.h (Michael Ellerman) - skip ASPM common clock warning if BIOS already configured it (Sinan Kaya) - fix ASPM Coverity warning about threshold_ns (Gustavo A. R. Silva) - remove last user of pci_get_bus_and_slot() and the function itself

[GIT PULL] PCI changes for v4.17

PCI changes: - move pci_uevent_ers() out of pci.h (Michael Ellerman) - skip ASPM common clock warning if BIOS already configured it (Sinan Kaya) - fix ASPM Coverity warning about threshold_ns (Gustavo A. R. Silva) - remove last user of pci_get_bus_and_slot() and the function itself

Re: [PATCH] usbip: vhci_hcd: check rhport before using in vhci_hub_control()

On 04/06/2018 02:01 AM, Sergei Shtylyov wrote: > Hello! > > On 4/6/2018 1:31 AM, Shuah Khan wrote: > >> Validate !rhport < 0 before using it to access port_status array. > >    Why '!'? > I should have explained it better in the commit log. rhport is set based on input wIndex which could be

Re: [PATCH] usbip: vhci_hcd: check rhport before using in vhci_hub_control()

On 04/06/2018 02:01 AM, Sergei Shtylyov wrote: > Hello! > > On 4/6/2018 1:31 AM, Shuah Khan wrote: > >> Validate !rhport < 0 before using it to access port_status array. > >    Why '!'? > I should have explained it better in the commit log. rhport is set based on input wIndex which could be

[PATCH] uapi/linux/keyctl.h: don't use C++ reserved keyword as a struct member name

From: Randy Dunlap Since this header is in "include/uapi/linux/", apparently people want to use it in userspace programs -- even in C++ ones. However, the header uses a C++ reserved keyword ("private"), so change that to "dh_private" instead to allow the header file to be

[PATCH] uapi/linux/keyctl.h: don't use C++ reserved keyword as a struct member name

From: Randy Dunlap Since this header is in "include/uapi/linux/", apparently people want to use it in userspace programs -- even in C++ ones. However, the header uses a C++ reserved keyword ("private"), so change that to "dh_private" instead to allow the header file to be used in C++ userspace.

Re: [RfC PATCH] Add udmabuf misc device

On Fri, Apr 06, 2018 at 03:36:03PM +0300, Oleksandr Andrushchenko wrote: > On 04/06/2018 02:57 PM, Gerd Hoffmann wrote: > > Hi, > > > >>>I fail to see any common ground for xen-zcopy and udmabuf ... > >>Does the above mean you can assume that xen-zcopy and udmabuf > >>can co-exist as two

Re: [RfC PATCH] Add udmabuf misc device

On Fri, Apr 06, 2018 at 03:36:03PM +0300, Oleksandr Andrushchenko wrote: > On 04/06/2018 02:57 PM, Gerd Hoffmann wrote: > > Hi, > > > >>>I fail to see any common ground for xen-zcopy and udmabuf ... > >>Does the above mean you can assume that xen-zcopy and udmabuf > >>can co-exist as two

[PATCH v2] writeback: safer lock nesting

lock_page_memcg()/unlock_page_memcg() use spin_lock_irqsave/restore() if the page's memcg is undergoing move accounting, which occurs when a process leaves its memcg for a new one that has memory.move_charge_at_immigrate set. unlocked_inode_to_wb_begin,end() use spin_lock_irq/spin_unlock_irq() if

[PATCH v2] writeback: safer lock nesting

lock_page_memcg()/unlock_page_memcg() use spin_lock_irqsave/restore() if the page's memcg is undergoing move accounting, which occurs when a process leaves its memcg for a new one that has memory.move_charge_at_immigrate set. unlocked_inode_to_wb_begin,end() use spin_lock_irq/spin_unlock_irq() if

[PATCH v4] drm/i915/dp: Send DPCD ON for MST before phy_up

When doing a modeset where the sink is transitioning from D3 to D0 , it would sometimes be possible for the initial power_up_phy() to start timing out. This would only be observed in the last action before the sink went into D3 mode was intel_dp_sink_dpms(DRM_MODE_DPMS_OFF). We originally thought

[PATCH v4] drm/i915/dp: Send DPCD ON for MST before phy_up

When doing a modeset where the sink is transitioning from D3 to D0 , it would sometimes be possible for the initial power_up_phy() to start timing out. This would only be observed in the last action before the sink went into D3 mode was intel_dp_sink_dpms(DRM_MODE_DPMS_OFF). We originally thought

Re: [RFC PATCH] mm: use rbtree for page-wait

On 04/03/2018 02:59 PM, Sebastian Andrzej Siewior wrote: > I noticed commit 2554db916586 ("sched/wait: Break up long wake list > walk") in which it is claimed that > |We saw page wait list that are up to 3700+ entries long in tests of > |large 4 and 8 socket systems. > > Here is another approach:

Re: [RFC PATCH] mm: use rbtree for page-wait

On 04/03/2018 02:59 PM, Sebastian Andrzej Siewior wrote: > I noticed commit 2554db916586 ("sched/wait: Break up long wake list > walk") in which it is claimed that > |We saw page wait list that are up to 3700+ entries long in tests of > |large 4 and 8 socket systems. > > Here is another approach:

Re: [PATCH] writeback: safer lock nesting

On Fri, Apr 6, 2018 at 1:07 AM Michal Hocko wrote: > On Fri 06-04-18 01:03:24, Greg Thelen wrote: > [...] > > diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c > > index d4d04fee568a..d51bae5a53e2 100644 > > --- a/fs/fs-writeback.c > > +++ b/fs/fs-writeback.c > > @@ -746,10

Re: [PATCH] writeback: safer lock nesting

On Fri, Apr 6, 2018 at 1:07 AM Michal Hocko wrote: > On Fri 06-04-18 01:03:24, Greg Thelen wrote: > [...] > > diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c > > index d4d04fee568a..d51bae5a53e2 100644 > > --- a/fs/fs-writeback.c > > +++ b/fs/fs-writeback.c > > @@ -746,10 +746,11 @@ int

Re: [PATCH v3 1/6] clk: meson: aoclk: refactor common code into dedicated file

Quoting Yixun Lan (2018-03-27 19:50:45) > diff --git a/drivers/clk/meson/gxbb-aoclk.c b/drivers/clk/meson/gxbb-aoclk.c > index 9ec23ae9a219..5a922639a264 100644 > --- a/drivers/clk/meson/gxbb-aoclk.c > +++ b/drivers/clk/meson/gxbb-aoclk.c > @@ -165,38 +135,39 @@ static int gxbb_aoclkc_probe(struct

Re: [PATCH v3 1/6] clk: meson: aoclk: refactor common code into dedicated file

Quoting Yixun Lan (2018-03-27 19:50:45) > diff --git a/drivers/clk/meson/gxbb-aoclk.c b/drivers/clk/meson/gxbb-aoclk.c > index 9ec23ae9a219..5a922639a264 100644 > --- a/drivers/clk/meson/gxbb-aoclk.c > +++ b/drivers/clk/meson/gxbb-aoclk.c > @@ -165,38 +135,39 @@ static int gxbb_aoclkc_probe(struct

[4.15 & 4.14 stable 02/12] x86/CPU: Add a microcode loader callback

From: Borislav Petkov commit 1008c52c09dcb23d93f8e0ea83a6246265d2cce0 upstream Add a callback function which the microcode loader calls when microcode has been updated to a newer revision. Do the callback only when no error was encountered during loading. Tested-by: Ashok Raj

[4.15 & 4.14 stable 02/12] x86/CPU: Add a microcode loader callback

From: Borislav Petkov commit 1008c52c09dcb23d93f8e0ea83a6246265d2cce0 upstream Add a callback function which the microcode loader calls when microcode has been updated to a newer revision. Do the callback only when no error was encountered during loading. Tested-by: Ashok Raj Signed-off-by:

[4.15 & 4.14 stable 01/12] x86/microcode: Propagate return value from updating functions

From: Borislav Petkov commit 3f1f576a195aa266813cbd4ca70291deb61e0129 upstream ... so that callers can know when microcode was updated and act accordingly. Tested-by: Ashok Raj Signed-off-by: Borislav Petkov Reviewed-by: Ashok Raj

[4.15 & 4.14 stable 01/12] x86/microcode: Propagate return value from updating functions

From: Borislav Petkov commit 3f1f576a195aa266813cbd4ca70291deb61e0129 upstream ... so that callers can know when microcode was updated and act accordingly. Tested-by: Ashok Raj Signed-off-by: Borislav Petkov Reviewed-by: Ashok Raj Cc: Andy Lutomirski Cc: Arjan van de Ven Cc: Borislav

[4.15 & 4.14 stable 03/12] x86/CPU: Check CPU feature bits after microcode upgrade

From: Borislav Petkov commit 42ca8082e260dcfd8afa2afa6ec1940b9d41724c upstream With some microcode upgrades, new CPUID features can become visible on the CPU. Check what the kernel has mirrored now and issue a warning hinting at possible things the user/admin can do to make use of

[4.15 & 4.14 stable 03/12] x86/CPU: Check CPU feature bits after microcode upgrade

From: Borislav Petkov commit 42ca8082e260dcfd8afa2afa6ec1940b9d41724c upstream With some microcode upgrades, new CPUID features can become visible on the CPU. Check what the kernel has mirrored now and issue a warning hinting at possible things the user/admin can do to make use of the newly

[4.15 & 4.14 stable 11/12] x86/microcode: Attempt late loading only when new microcode is present

From: Borislav Petkov commit 2613f36ed965d0e5a595a1d931fd3b480e82d6fd upstream Return UCODE_NEW from the scanning functions to denote that new microcode was found and only then attempt the expensive synchronization dance. Reported-by: Emanuel Czirai

[4.15 & 4.14 stable 11/12] x86/microcode: Attempt late loading only when new microcode is present

From: Borislav Petkov commit 2613f36ed965d0e5a595a1d931fd3b480e82d6fd upstream Return UCODE_NEW from the scanning functions to denote that new microcode was found and only then attempt the expensive synchronization dance. Reported-by: Emanuel Czirai Signed-off-by: Borislav Petkov

[4.15 & 4.14 stable 12/12] x86/microcode: Fix CPU synchronization routine

From: Borislav Petkov commit bb8c13d61a629276a162c1d2b1a20a815cbcfbb7 upstream Emanuel reported an issue with a hang during microcode update because my dumb idea to use one atomic synchronization variable for both rendezvous - before and after update - was simply bollocks:

[4.15 & 4.14 stable 12/12] x86/microcode: Fix CPU synchronization routine

From: Borislav Petkov commit bb8c13d61a629276a162c1d2b1a20a815cbcfbb7 upstream Emanuel reported an issue with a hang during microcode update because my dumb idea to use one atomic synchronization variable for both rendezvous - before and after update - was simply bollocks: microcode:

Re: [PATCH net-next 00/12] fscache: Fixes, traces and development

On Fri, Apr 6, 2018 at 11:21 AM, Linus Torvalds wrote: > > No, but if you can redo the pull request part so that the diffstat I > get will match the diffstat I see in the pull request, that would be > good. Oh, and can you please make sure there is a "[GIT PULL]"

Re: [PATCH net-next 00/12] fscache: Fixes, traces and development

On Fri, Apr 6, 2018 at 11:21 AM, Linus Torvalds wrote: > > No, but if you can redo the pull request part so that the diffstat I > get will match the diffstat I see in the pull request, that would be > good. Oh, and can you please make sure there is a "[GIT PULL]" in the subject line for your

Re: [PATCH v4 03/19] powerpc: Mark variable `l` as unused, remove `path`

On Fri, Apr 6, 2018 at 5:33 PM, LEROY Christophe wrote: > Mathieu Malaterre a écrit : > >> Add gcc attribute unused for `l` variable, replace `path` variable >> directly >> with prom_scratch. Fix warnings treated as errors with W=1: >> >>

Re: [PATCH v4 03/19] powerpc: Mark variable `l` as unused, remove `path`

On Fri, Apr 6, 2018 at 5:33 PM, LEROY Christophe wrote: > Mathieu Malaterre a écrit : > >> Add gcc attribute unused for `l` variable, replace `path` variable >> directly >> with prom_scratch. Fix warnings treated as errors with W=1: >> >> arch/powerpc/kernel/prom_init.c:607:6: error: variable

[4.15 & 4.14 stable 00/12] Series to update microcode loading.

Hi Greg Here is a series that addresses microcode loading stability issues post Spectre. All of them are simply cherry-picked and the patches themselves have the upstream commit ID's. I checked this for Intel platforms and thanks to Boris for checking on AMD platforms. I'm still working on a

[4.15 & 4.14 stable 00/12] Series to update microcode loading.

Hi Greg Here is a series that addresses microcode loading stability issues post Spectre. All of them are simply cherry-picked and the patches themselves have the upstream commit ID's. I checked this for Intel platforms and thanks to Boris for checking on AMD platforms. I'm still working on a

[4.15 & 4.14 stable 10/12] x86/microcode: Synchronize late microcode loading

commit a5321aec6412b20b5ad15db2d6b916c05349dbff upstream Original idea by Ashok, completely rewritten by Borislav. Before you read any further: the early loading method is still the preferred one and you should always do that. The following patch is improving the late loading mechanism for long

[4.15 & 4.14 stable 10/12] x86/microcode: Synchronize late microcode loading

commit a5321aec6412b20b5ad15db2d6b916c05349dbff upstream Original idea by Ashok, completely rewritten by Borislav. Before you read any further: the early loading method is still the preferred one and you should always do that. The following patch is improving the late loading mechanism for long

[4.15 & 4.14 stable 06/12] x86/microcode/intel: Writeback and invalidate caches before updating microcode

commit 91df9fdf51492aec9fed6b4cbd33160886740f47 upstream Updating microcode is less error prone when caches have been flushed and depending on what exactly the microcode is updating. For example, some of the issues around certain Broadwell parts can be addressed by doing a full cache flush. [

[4.15 & 4.14 stable 06/12] x86/microcode/intel: Writeback and invalidate caches before updating microcode

commit 91df9fdf51492aec9fed6b4cbd33160886740f47 upstream Updating microcode is less error prone when caches have been flushed and depending on what exactly the microcode is updating. For example, some of the issues around certain Broadwell parts can be addressed by doing a full cache flush. [

[4.15 & 4.14 stable 05/12] x86/microcode/intel: Check microcode revision before updating sibling threads

commit c182d2b7d0ca48e0d6ff16f7d883161238c447ed upstream After updating microcode on one of the threads of a core, the other thread sibling automatically gets the update since the microcode resources on a hyperthreaded core are shared between the two threads. Check the microcode revision on the

[4.15 & 4.14 stable 05/12] x86/microcode/intel: Check microcode revision before updating sibling threads

commit c182d2b7d0ca48e0d6ff16f7d883161238c447ed upstream After updating microcode on one of the threads of a core, the other thread sibling automatically gets the update since the microcode resources on a hyperthreaded core are shared between the two threads. Check the microcode revision on the

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