Re: [PATCH 2/2] x86: Match bitops prototypes

On Thu, 16 Mar 2017 20:07:09 +0100 Joakim Tjernlund wrote: > Adjust bitops function prototypes in asm-generic/bitops/le.h > to match the generic ones in arch/x86/include/asm/le.h > That is, replace void* with unsigned long* > > Cc: #

Re: [PATCH 2/2] x86: Match bitops prototypes

On Thu, 16 Mar 2017 20:07:09 +0100 Joakim Tjernlund wrote: > Adjust bitops function prototypes in asm-generic/bitops/le.h > to match the generic ones in arch/x86/include/asm/le.h > That is, replace void* with unsigned long* > > Cc: # v4.9+ Again, no reason is provided. Also, please cc the

Re: [PATCH 1/2] x86: asm/bitops.h

On Thu, 16 Mar 2017 20:07:08 +0100 Joakim Tjernlund wrote: > Replace void * cast with uintptr_t to do pointer arithmetic's Why? The changelog doesn't describe whats wrong with the current code and gives nobody any reason to apply the patch. > Cc:

Re: [PATCH 1/2] x86: asm/bitops.h

On Thu, 16 Mar 2017 20:07:08 +0100 Joakim Tjernlund wrote: > Replace void * cast with uintptr_t to do pointer arithmetic's Why? The changelog doesn't describe whats wrong with the current code and gives nobody any reason to apply the patch. > Cc: # v4.9+ And you think it should be

Re: [PATCH v2 0/5] mm: support parallel free of memory

On Wed, Mar 15, 2017 at 04:59:59PM +0800, Aaron Lu wrote: > v2 changes: Nothing major, only minor ones. > - rebased on top of v4.11-rc2-mmotm-2017-03-14-15-41; > - use list_add_tail instead of list_add to add worker to tlb's worker >list so that when doing flush, the first queued worker gets

Re: [PATCH v2 0/5] mm: support parallel free of memory

On Wed, Mar 15, 2017 at 04:59:59PM +0800, Aaron Lu wrote: > v2 changes: Nothing major, only minor ones. > - rebased on top of v4.11-rc2-mmotm-2017-03-14-15-41; > - use list_add_tail instead of list_add to add worker to tlb's worker >list so that when doing flush, the first queued worker gets

Re: Legacy PCI interrupt support in PCIe host driver

On Thu, 16 Mar 2017, Mason wrote: > On 16/03/2017 18:47, Thomas Gleixner wrote: > > On Thu, 16 Mar 2017, Mason wrote: > >> I guess if two interrupts fire at the same time, we'll just take two > >> separate exceptions? > > > > Wrong guess. That might work with level interrupts, but with other

Re: Legacy PCI interrupt support in PCIe host driver

On Thu, 16 Mar 2017, Mason wrote: > On 16/03/2017 18:47, Thomas Gleixner wrote: > > On Thu, 16 Mar 2017, Mason wrote: > >> I guess if two interrupts fire at the same time, we'll just take two > >> separate exceptions? > > > > Wrong guess. That might work with level interrupts, but with other

[PATCH v2] x86: mostly disable '-maccumulate-outgoing-args'

The gcc '-maccumulate-outgoing-args' flag is enabled for most configs, mostly because of issues which are no longer relevant. For most configs, and with most recent versions of gcc, it's no longer needed. Clarify which cases need it, and only enable it for those cases. Also produce a

[PATCH v2] x86: mostly disable '-maccumulate-outgoing-args'

The gcc '-maccumulate-outgoing-args' flag is enabled for most configs, mostly because of issues which are no longer relevant. For most configs, and with most recent versions of gcc, it's no longer needed. Clarify which cases need it, and only enable it for those cases. Also produce a

Re: [PATCH 4.9 00/44] 4.9.16-stable review

On 03/16/2017 08:29 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.16 release. > There are 44 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. > > Responses

Re: [PATCH 4.9 00/44] 4.9.16-stable review

On 03/16/2017 08:29 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.16 release. > There are 44 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. > > Responses

Re: 'perf test tsc' failing, bisected to "sched/clock: Provide better clock continuity"

Em Thu, Mar 16, 2017 at 03:36:17PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Thu, Mar 16, 2017 at 07:11:21PM +0100, Peter Zijlstra escreveu: > > On Thu, Mar 16, 2017 at 03:53:11PM +0100, Peter Zijlstra wrote: > > > On Thu, Mar 16, 2017 at 11:01:03AM -0300, Arnaldo Carvalho de Melo wrote: > >

Re: 'perf test tsc' failing, bisected to "sched/clock: Provide better clock continuity"

Em Thu, Mar 16, 2017 at 03:36:17PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Thu, Mar 16, 2017 at 07:11:21PM +0100, Peter Zijlstra escreveu: > > On Thu, Mar 16, 2017 at 03:53:11PM +0100, Peter Zijlstra wrote: > > > On Thu, Mar 16, 2017 at 11:01:03AM -0300, Arnaldo Carvalho de Melo wrote: > >

Re: [PATCH 4/5 v3] ftrace/x86_32: Clean up ftrace_regs_caller

On Thu, Mar 16, 2017 at 12:24 PM, Steven Rostedt wrote: > popl%ds > popl%es > popl%fs > popl%gs Do you even need these? Can they be changed by ftrace? And see the previous email about not touching the original location at all,

Re: [PATCH 4.10 00/48] 4.10.4-stable review

On 03/16/2017 08:29 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.10.4 release. > There are 48 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. > > Responses

Re: [PATCH 4/5 v3] ftrace/x86_32: Clean up ftrace_regs_caller

On Thu, Mar 16, 2017 at 12:24 PM, Steven Rostedt wrote: > popl%ds > popl%es > popl%fs > popl%gs Do you even need these? Can they be changed by ftrace? And see the previous email about not touching the original location at all, adn just duplicating

Re: [PATCH 4.10 00/48] 4.10.4-stable review

On 03/16/2017 08:29 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.10.4 release. > There are 48 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. > > Responses

Re: [PATCH 4/5 v3] ftrace/x86_32: Clean up ftrace_regs_caller

On Thu, Mar 16, 2017 at 12:19 PM, Steven Rostedt wrote: > > The thing is we don't return, we jump to the location that may be > modified to run the function graph tracer. Hmm. How about just making the stack frame a tiny bit bigger, and getting rid of *all* the games. IOW,

Re: [PATCH 4/5 v3] ftrace/x86_32: Clean up ftrace_regs_caller

On Thu, Mar 16, 2017 at 12:19 PM, Steven Rostedt wrote: > > The thing is we don't return, we jump to the location that may be > modified to run the function graph tracer. Hmm. How about just making the stack frame a tiny bit bigger, and getting rid of *all* the games. IOW, just duplicate the

Re: [PATCH v5 untested] kvm: better MWAIT emulation for guests

On Thu, Mar 16, 2017 at 03:24:41PM -0400, Gabriel L. Somlo wrote: > On Thu, Mar 16, 2017 at 08:29:32PM +0200, Michael S. Tsirkin wrote: > > Let's take a step back and try to figure out how is > > mwait called. How about dumping code of VCPUs > > around mwait? gdb disa command will do this. > >

Re: [PATCH v5 untested] kvm: better MWAIT emulation for guests

On Thu, Mar 16, 2017 at 03:24:41PM -0400, Gabriel L. Somlo wrote: > On Thu, Mar 16, 2017 at 08:29:32PM +0200, Michael S. Tsirkin wrote: > > Let's take a step back and try to figure out how is > > mwait called. How about dumping code of VCPUs > > around mwait? gdb disa command will do this. > >

Re: [PATCH 4/5 v3] ftrace/x86_32: Clean up ftrace_regs_caller

On Thu, 16 Mar 2017 15:19:32 -0400 Steven Rostedt wrote: > > > The thing is we don't return, we jump to the location that may be > modified to run the function graph tracer. That said, maybe the below is better? /* restore flags */ pushl 14*4(%esp)

Re: [PATCH 4/5 v3] ftrace/x86_32: Clean up ftrace_regs_caller

On Thu, 16 Mar 2017 15:19:32 -0400 Steven Rostedt wrote: > > > The thing is we don't return, we jump to the location that may be > modified to run the function graph tracer. That said, maybe the below is better? /* restore flags */ pushl 14*4(%esp) popf /*

Re: [PATCH v5 untested] kvm: better MWAIT emulation for guests

On Thu, Mar 16, 2017 at 08:29:32PM +0200, Michael S. Tsirkin wrote: > Let's take a step back and try to figure out how is > mwait called. How about dumping code of VCPUs > around mwait? gdb disa command will do this. Started guest with '-s', tried to attach from gdb with "target remote

Re: [PATCH v5 untested] kvm: better MWAIT emulation for guests

On Thu, Mar 16, 2017 at 08:29:32PM +0200, Michael S. Tsirkin wrote: > Let's take a step back and try to figure out how is > mwait called. How about dumping code of VCPUs > around mwait? gdb disa command will do this. Started guest with '-s', tried to attach from gdb with "target remote

[PATCH v3] usb: hub: Fix error loop seen after hub communication errors

While stress testing a usb controller using a bind/unbind looop, the following error loop was observed. usb 7-1.2: new low-speed USB device number 3 using xhci-hcd usb 7-1.2: hub failed to enable device, error -108 usb 7-1-port2: cannot disable (err = -22) usb 7-1-port2: couldn't allocate

[PATCH v3] usb: hub: Fix error loop seen after hub communication errors

While stress testing a usb controller using a bind/unbind looop, the following error loop was observed. usb 7-1.2: new low-speed USB device number 3 using xhci-hcd usb 7-1.2: hub failed to enable device, error -108 usb 7-1-port2: cannot disable (err = -22) usb 7-1-port2: couldn't allocate

Re: 'perf test tsc' failing, bisected to "sched/clock: Provide better clock continuity"

Em Thu, Mar 16, 2017 at 04:21:38PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Thu, Mar 16, 2017 at 03:36:17PM -0300, Arnaldo Carvalho de Melo escreveu: > > Em Thu, Mar 16, 2017 at 07:11:21PM +0100, Peter Zijlstra escreveu: > > > On Thu, Mar 16, 2017 at 03:53:11PM +0100, Peter Zijlstra wrote: >

Re: 'perf test tsc' failing, bisected to "sched/clock: Provide better clock continuity"

Em Thu, Mar 16, 2017 at 04:21:38PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Thu, Mar 16, 2017 at 03:36:17PM -0300, Arnaldo Carvalho de Melo escreveu: > > Em Thu, Mar 16, 2017 at 07:11:21PM +0100, Peter Zijlstra escreveu: > > > On Thu, Mar 16, 2017 at 03:53:11PM +0100, Peter Zijlstra wrote: >

Re: [RFC PATCH v2 05/32] x86: Use encrypted access of BOOT related data with SEV

On 3/7/2017 5:09 AM, Borislav Petkov wrote: On Thu, Mar 02, 2017 at 10:12:59AM -0500, Brijesh Singh wrote: From: Tom Lendacky When Secure Encrypted Virtualization (SEV) is active, BOOT data (such as EFI related data, setup data) is encrypted and needs to be accessed

Re: [RFC PATCH v2 05/32] x86: Use encrypted access of BOOT related data with SEV

On 3/7/2017 5:09 AM, Borislav Petkov wrote: On Thu, Mar 02, 2017 at 10:12:59AM -0500, Brijesh Singh wrote: From: Tom Lendacky When Secure Encrypted Virtualization (SEV) is active, BOOT data (such as EFI related data, setup data) is encrypted and needs to be accessed as such when mapped.

Re: [PATCH 4.4 00/35] 4.4.55-stable review

On 03/16/2017 08:29 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.55 release. > There are 35 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. > > Responses

Re: [PATCH v1 1/1] platform/x86: intel_pmc_ipc: fix io mem mapping size

On Thu, Mar 16, 2017 at 11:50:16AM -0700, sathyanarayanan kuppuswamy wrote: > Hi, > > > On 03/16/2017 07:52 AM, Rajneesh Bhardwaj wrote: > >On Wed, Mar 15, 2017 at 08:32:53PM -0700, Kuppuswamy Sathyanarayanan wrote: > >>Mapping entire GCR mem region in this driver creates > >>mem region request

Re: [PATCH 4.4 00/35] 4.4.55-stable review

On 03/16/2017 08:29 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.55 release. > There are 35 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. > > Responses

Re: [PATCH v1 1/1] platform/x86: intel_pmc_ipc: fix io mem mapping size

On Thu, Mar 16, 2017 at 11:50:16AM -0700, sathyanarayanan kuppuswamy wrote: > Hi, > > > On 03/16/2017 07:52 AM, Rajneesh Bhardwaj wrote: > >On Wed, Mar 15, 2017 at 08:32:53PM -0700, Kuppuswamy Sathyanarayanan wrote: > >>Mapping entire GCR mem region in this driver creates > >>mem region request

Re: [PATCH 4/5 v3] ftrace/x86_32: Clean up ftrace_regs_caller

On Thu, 16 Mar 2017 11:19:44 -0700 Linus Torvalds wrote: > On Thu, Mar 16, 2017 at 11:09 AM, Steven Rostedt wrote: > > + > > + /* Since we don't care about cs, move flags there to simplify > > return */ > > + movl14*4(%esp),

Re: [PATCH 4/5 v3] ftrace/x86_32: Clean up ftrace_regs_caller

On Thu, 16 Mar 2017 11:19:44 -0700 Linus Torvalds wrote: > On Thu, Mar 16, 2017 at 11:09 AM, Steven Rostedt wrote: > > + > > + /* Since we don't care about cs, move flags there to simplify > > return */ > > + movl14*4(%esp), %eax > > + movl%eax, 13*4(%esp) > > + > > +

[PATCH 2/2] x86: Match bitops prototypes

Adjust bitops function prototypes in asm-generic/bitops/le.h to match the generic ones in arch/x86/include/asm/le.h That is, replace void* with unsigned long* Cc: # v4.9+ Signed-off-by: Joakim Tjernlund --- include/asm-generic/bitops/le.h

[PATCH 2/2] x86: Match bitops prototypes

Adjust bitops function prototypes in asm-generic/bitops/le.h to match the generic ones in arch/x86/include/asm/le.h That is, replace void* with unsigned long* Cc: # v4.9+ Signed-off-by: Joakim Tjernlund --- include/asm-generic/bitops/le.h | 42 ++--- 1 file

[PATCH 1/2] x86: asm/bitops.h

Replace void * cast with uintptr_t to do pointer arithmetic's Cc: # v4.9+ Signed-off-by: Joakim Tjernlund --- arch/x86/include/asm/bitops.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/include/asm/bitops.h

[PATCH 1/2] x86: asm/bitops.h

Replace void * cast with uintptr_t to do pointer arithmetic's Cc: # v4.9+ Signed-off-by: Joakim Tjernlund --- arch/x86/include/asm/bitops.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/include/asm/bitops.h b/arch/x86/include/asm/bitops.h index 8540227..b561304

Re: Legacy PCI interrupt support in PCIe host driver

On 16/03/2017 18:47, Thomas Gleixner wrote: > On Thu, 16 Mar 2017, Mason wrote: >> I guess if two interrupts fire at the same time, we'll just take two >> separate exceptions? > > Wrong guess. That might work with level interrupts, but with other types > nothing will raise another exception.

Re: [PATCH] x86: mostly disable '-maccumulate-outgoing-args'

On Thu, Mar 16, 2017 at 01:53:05PM -0500, Josh Poimboeuf wrote: > On Thu, Mar 16, 2017 at 01:36:35PM -0500, Josh Poimboeuf wrote: > > On Thu, Mar 16, 2017 at 01:32:01PM -0400, Steven Rostedt wrote: > > > On Thu, 16 Mar 2017 10:42:08 -0500 > > > Josh Poimboeuf wrote: > > > > +

Re: Legacy PCI interrupt support in PCIe host driver

On 16/03/2017 18:47, Thomas Gleixner wrote: > On Thu, 16 Mar 2017, Mason wrote: >> I guess if two interrupts fire at the same time, we'll just take two >> separate exceptions? > > Wrong guess. That might work with level interrupts, but with other types > nothing will raise another exception.

Re: [PATCH] x86: mostly disable '-maccumulate-outgoing-args'

On Thu, Mar 16, 2017 at 01:53:05PM -0500, Josh Poimboeuf wrote: > On Thu, Mar 16, 2017 at 01:36:35PM -0500, Josh Poimboeuf wrote: > > On Thu, Mar 16, 2017 at 01:32:01PM -0400, Steven Rostedt wrote: > > > On Thu, 16 Mar 2017 10:42:08 -0500 > > > Josh Poimboeuf wrote: > > > > +

Re: [PATCH 7/7] x86/mm: Switch to generic get_user_page_fast() implementation

On Thu, Mar 16, 2017 at 06:20:46PM +0100, Peter Zijlstra wrote: > On Thu, Mar 16, 2017 at 06:26:55PM +0300, Kirill A. Shutemov wrote: > > +config HAVE_GENERIC_RCU_GUP > > + def_bool y > > + > > Nothing immediately jumped out to me; except that this option might be > misnamed. > > AFAICT that

Re: ZONE_NORMAL vs. ZONE_MOVABLE

Hello Joonsoo, On Thu, Mar 16, 2017 at 02:31:22PM +0900, Joonsoo Kim wrote: > I don't follow up previous discussion so please let me know if I miss > something. I'd just like to mention about sticky pageblocks. The interesting part of the previous discussion relevant for the sticky movable

Re: [PATCH 7/7] x86/mm: Switch to generic get_user_page_fast() implementation

On Thu, Mar 16, 2017 at 06:20:46PM +0100, Peter Zijlstra wrote: > On Thu, Mar 16, 2017 at 06:26:55PM +0300, Kirill A. Shutemov wrote: > > +config HAVE_GENERIC_RCU_GUP > > + def_bool y > > + > > Nothing immediately jumped out to me; except that this option might be > misnamed. > > AFAICT that

Re: ZONE_NORMAL vs. ZONE_MOVABLE

Hello Joonsoo, On Thu, Mar 16, 2017 at 02:31:22PM +0900, Joonsoo Kim wrote: > I don't follow up previous discussion so please let me know if I miss > something. I'd just like to mention about sticky pageblocks. The interesting part of the previous discussion relevant for the sticky movable

[GIT PULL] xfs: fixes for 4.11-rc3

Hi Linus, Here's a single fix for -rc3 to improve input validation on inline directory metadata. Could you pull it please? (After the 4.10 cycle was over Dave told me that it's not customary to keep rebasing the -fixes branch with every rc, so this time around I'm sticking to appending fixes

Re: [PATCH 07/17] net: convert sock.sk_refcnt from atomic_t to refcount_t

From: Kees Cook Date: Thu, 16 Mar 2017 11:38:25 -0600 > I am, of course, biased, but I think the evidence of actual > refcounting attacks outweighs the theoretical performance cost of > these changes. This is not theoretical at all. We count the nanoseconds that every

[GIT PULL] xfs: fixes for 4.11-rc3

Hi Linus, Here's a single fix for -rc3 to improve input validation on inline directory metadata. Could you pull it please? (After the 4.10 cycle was over Dave told me that it's not customary to keep rebasing the -fixes branch with every rc, so this time around I'm sticking to appending fixes

Re: [PATCH 07/17] net: convert sock.sk_refcnt from atomic_t to refcount_t

From: Kees Cook Date: Thu, 16 Mar 2017 11:38:25 -0600 > I am, of course, biased, but I think the evidence of actual > refcounting attacks outweighs the theoretical performance cost of > these changes. This is not theoretical at all. We count the nanoseconds that every packet takes to get

Re: [PATCH] x86: mostly disable '-maccumulate-outgoing-args'

On Thu, 16 Mar 2017 14:04:01 -0500 Josh Poimboeuf wrote: > > After some snooping I discovered there's some precedent for doing this > > in the scripts/gcc-*.sh files. So maybe I'll add a test there and call > > it from the Makefile. > > But now I realize that those other

Re: [PATCH] x86: mostly disable '-maccumulate-outgoing-args'

On Thu, 16 Mar 2017 14:04:01 -0500 Josh Poimboeuf wrote: > > After some snooping I discovered there's some precedent for doing this > > in the scripts/gcc-*.sh files. So maybe I'll add a test there and call > > it from the Makefile. > > But now I realize that those other tests are just build

Re: [PATCH] x86: mostly disable '-maccumulate-outgoing-args'

On Thu, 16 Mar 2017 13:36:35 -0500 Josh Poimboeuf wrote: > On Thu, Mar 16, 2017 at 01:32:01PM -0400, Steven Rostedt wrote: > > On Thu, 16 Mar 2017 10:42:08 -0500 > > Josh Poimboeuf wrote: > > > > > Signed-off-by: Josh Poimboeuf

Re: [PATCH] x86: mostly disable '-maccumulate-outgoing-args'

On Thu, 16 Mar 2017 13:36:35 -0500 Josh Poimboeuf wrote: > On Thu, Mar 16, 2017 at 01:32:01PM -0400, Steven Rostedt wrote: > > On Thu, 16 Mar 2017 10:42:08 -0500 > > Josh Poimboeuf wrote: > > > > > Signed-off-by: Josh Poimboeuf > > > --- > > > arch/x86/Makefile| 29

Re: [PATCH v4 00/13] mm: sub-section memory hotplug support

On Thu, Mar 16, 2017 at 10:48 AM, Michal Hocko wrote: > Hi, > I didn't get to look through the patch series yet and I might not be > able before LSF/MM. How urgent is this? I am primarily asking because > the memory hotplug is really convoluted right now and putting more on >

Re: [PATCH v4 00/13] mm: sub-section memory hotplug support

On Thu, Mar 16, 2017 at 10:48 AM, Michal Hocko wrote: > Hi, > I didn't get to look through the patch series yet and I might not be > able before LSF/MM. How urgent is this? I am primarily asking because > the memory hotplug is really convoluted right now and putting more on > top doesn't really

Re: [PATCH] staging: android: ion: reduce lock contention latency

Hi Junil, [auto build test ERROR on staging/staging-testing] [also build test ERROR on v4.11-rc2 next-20170310] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH] staging: android: ion: reduce lock contention latency

Hi Junil, [auto build test ERROR on staging/staging-testing] [also build test ERROR on v4.11-rc2 next-20170310] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH] net: ethernet: bgmac: Allow MAC address to be specified in DTB

From: Steve Lin Date: Thu, 16 Mar 2017 11:48:58 -0400 > Allows the BCMA version of the bgmac driver to obtain MAC address > from the device tree. If no MAC address is specified there, then > the previous behavior (obtaining MAC address from SPROM) is > used. > >

Re: [PATCH] net: ethernet: bgmac: Allow MAC address to be specified in DTB

From: Steve Lin Date: Thu, 16 Mar 2017 11:48:58 -0400 > Allows the BCMA version of the bgmac driver to obtain MAC address > from the device tree. If no MAC address is specified there, then > the previous behavior (obtaining MAC address from SPROM) is > used. > > Signed-off-by: Steve Lin

Re: [PATCH v2 10/10] mm: remove SWAP_[SUCCESS|AGAIN|FAIL]

Hi Minchan, [auto build test ERROR on mmotm/master] [also build test ERROR on next-20170310] [cannot apply to v4.11-rc2] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH v2 10/10] mm: remove SWAP_[SUCCESS|AGAIN|FAIL]

Hi Minchan, [auto build test ERROR on mmotm/master] [also build test ERROR on next-20170310] [cannot apply to v4.11-rc2] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

[PATCH] drm: vc4: remove redundant check of plane being non-null

From: Colin Ian King The pointer plane is always null on the error path at label 'fail' hence the check if it is non-null is redundant. We can therefore remove the check and the destruction of plane as well as the fail error path and instead just return an -ENOMEM

[PATCH] drm: vc4: remove redundant check of plane being non-null

From: Colin Ian King The pointer plane is always null on the error path at label 'fail' hence the check if it is non-null is redundant. We can therefore remove the check and the destruction of plane as well as the fail error path and instead just return an -ENOMEM ERR_PTR. Detected by

Re: [PATCH v1 1/1] platform/x86: intel_pmc_ipc: fix io mem mapping size

Hi, On 03/16/2017 07:52 AM, Rajneesh Bhardwaj wrote: On Wed, Mar 15, 2017 at 08:32:53PM -0700, Kuppuswamy Sathyanarayanan wrote: Mapping entire GCR mem region in this driver creates mem region request conflict in sub devices that depend on PMC. This creates driver probe failure in devices

Re: [PATCH v1 1/1] platform/x86: intel_pmc_ipc: fix io mem mapping size

Hi, On 03/16/2017 07:52 AM, Rajneesh Bhardwaj wrote: On Wed, Mar 15, 2017 at 08:32:53PM -0700, Kuppuswamy Sathyanarayanan wrote: Mapping entire GCR mem region in this driver creates mem region request conflict in sub devices that depend on PMC. This creates driver probe failure in devices

Re: [PATCH] x86: mostly disable '-maccumulate-outgoing-args'

On Thu, Mar 16, 2017 at 01:36:35PM -0500, Josh Poimboeuf wrote: > On Thu, Mar 16, 2017 at 01:32:01PM -0400, Steven Rostedt wrote: > > On Thu, 16 Mar 2017 10:42:08 -0500 > > Josh Poimboeuf wrote: > > > + ACCUMULATE_OUTGOING_ARGS := 1 > > > +endif > > > + endif > > >

Re: [PATCH] x86: mostly disable '-maccumulate-outgoing-args'

On Thu, Mar 16, 2017 at 01:36:35PM -0500, Josh Poimboeuf wrote: > On Thu, Mar 16, 2017 at 01:32:01PM -0400, Steven Rostedt wrote: > > On Thu, 16 Mar 2017 10:42:08 -0500 > > Josh Poimboeuf wrote: > > > + ACCUMULATE_OUTGOING_ARGS := 1 > > > +endif > > > + endif > > > +endif > > > + > > > +#

Re: perf: massive perf_event slowdown between 4.9 and 4.11-rc

On Thu, Mar 16, 2017 at 01:57:31PM -0400, Vince Weaver wrote: > On Thu, 16 Mar 2017, Vince Weaver wrote: > > > Anyway all perf_event functionality (especially reads) has become about > > 20x slower, at least on Intel machines (haswell and skylake are the only > > ones I've tested) sometime

Re: perf: massive perf_event slowdown between 4.9 and 4.11-rc

On Thu, Mar 16, 2017 at 01:57:31PM -0400, Vince Weaver wrote: > On Thu, 16 Mar 2017, Vince Weaver wrote: > > > Anyway all perf_event functionality (especially reads) has become about > > 20x slower, at least on Intel machines (haswell and skylake are the only > > ones I've tested) sometime

Re: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3 is enabled

On Thu, Mar 16, 2017 at 2:14 PM, Diego Viola wrote: > On Thu, Mar 16, 2017 at 12:07 PM, Alan Stern > wrote: >> On Thu, 16 Mar 2017, Ulf Hansson wrote: >> >>> +Alan >>> >>> On 15 March 2017 at 15:00, Diego Viola wrote: >>>

Re: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3 is enabled

On Thu, Mar 16, 2017 at 2:14 PM, Diego Viola wrote: > On Thu, Mar 16, 2017 at 12:07 PM, Alan Stern > wrote: >> On Thu, 16 Mar 2017, Ulf Hansson wrote: >> >>> +Alan >>> >>> On 15 March 2017 at 15:00, Diego Viola wrote: >>> > On Tue, Mar 14, 2017 at 4:15 PM, Diego Viola >>> > wrote: >>> >> On

Re: [RESEND PATCH 1/2] auxdisplay: img-ascii-lcd: Add a sentinel entry to OF device ID table

Hello Dmitry, On 03/16/2017 03:41 PM, Dmitry Torokhov wrote: [snip] >>> >>> It looks like Greg KH picked my version of this patch... >>> >> >> Great, glad that your version was picked since it seems these two patches >> were never going to make it. > > How about you try sending the 2nd patch

[PATCH stable] powerpc/ptrace: Fix out of bounds array access warning

From: Khem Raj [ Upstream commit 1e407ee3b21f981140491d5b8a36422979ca246f ] gcc-6 correctly warns about a out of bounds access arch/powerpc/kernel/ptrace.c:407:24: warning: index 32 denotes an offset greater than size of 'u64[32][1] {aka long long unsigned int[32][1]}'

Re: [RESEND PATCH 1/2] auxdisplay: img-ascii-lcd: Add a sentinel entry to OF device ID table

Hello Dmitry, On 03/16/2017 03:41 PM, Dmitry Torokhov wrote: [snip] >>> >>> It looks like Greg KH picked my version of this patch... >>> >> >> Great, glad that your version was picked since it seems these two patches >> were never going to make it. > > How about you try sending the 2nd patch

[PATCH stable] powerpc/ptrace: Fix out of bounds array access warning

From: Khem Raj [ Upstream commit 1e407ee3b21f981140491d5b8a36422979ca246f ] gcc-6 correctly warns about a out of bounds access arch/powerpc/kernel/ptrace.c:407:24: warning: index 32 denotes an offset greater than size of 'u64[32][1] {aka long long unsigned int[32][1]}' [-Warray-bounds]

Re: [mmotm] "x86/atomic: move __arch_atomic_add_unless out of line" build error

On Thu, 16 Mar 2017 09:41:10 -0700 Andi Kleen wrote: > > Andi, why did you completely remove __arch_atomic_add_unless() from > > the header? Don't we need at least a declaration there? > > Actually it's there in my git version: > > I wonder where it disappeared. > > -/**

Re: [mmotm] "x86/atomic: move __arch_atomic_add_unless out of line" build error

On Thu, 16 Mar 2017 09:41:10 -0700 Andi Kleen wrote: > > Andi, why did you completely remove __arch_atomic_add_unless() from > > the header? Don't we need at least a declaration there? > > Actually it's there in my git version: > > I wonder where it disappeared. > > -/** > - *

Re: [RFC PATCH v2 29/32] kvm: svm: Add support for SEV DEBUG_DECRYPT command

On 03/16/2017 05:54 AM, Paolo Bonzini wrote: On 02/03/2017 16:18, Brijesh Singh wrote: +static int __sev_dbg_decrypt_page(struct kvm *kvm, unsigned long src, + void *dst, int *error) +{ + inpages = sev_pin_memory(src, PAGE_SIZE, ); + if (!inpages) { +

Re: [RFC PATCH v2 29/32] kvm: svm: Add support for SEV DEBUG_DECRYPT command

On 03/16/2017 05:54 AM, Paolo Bonzini wrote: On 02/03/2017 16:18, Brijesh Singh wrote: +static int __sev_dbg_decrypt_page(struct kvm *kvm, unsigned long src, + void *dst, int *error) +{ + inpages = sev_pin_memory(src, PAGE_SIZE, ); + if (!inpages) { +

Re: [RESEND PATCH 1/2] auxdisplay: img-ascii-lcd: Add a sentinel entry to OF device ID table

On Thu, Mar 16, 2017 at 11:38 AM, Javier Martinez Canillas wrote: > Hello Dmitry, > > On 03/16/2017 03:25 PM, Dmitry Torokhov wrote: >> On Fri, Mar 10, 2017 at 10:22 AM, Dmitry Torokhov >> wrote: >>> >>> On Fri, Mar 10, 2017 at 10:33:06AM -0300,

Re: [RESEND PATCH 1/2] auxdisplay: img-ascii-lcd: Add a sentinel entry to OF device ID table

On Thu, Mar 16, 2017 at 11:38 AM, Javier Martinez Canillas wrote: > Hello Dmitry, > > On 03/16/2017 03:25 PM, Dmitry Torokhov wrote: >> On Fri, Mar 10, 2017 at 10:22 AM, Dmitry Torokhov >> wrote: >>> >>> On Fri, Mar 10, 2017 at 10:33:06AM -0300, Javier Martinez Canillas wrote: The OF device

[net-next PATCH 2/5] net: Call sk_mark_napi_id() in the ACK receive path

From: Sridhar Samudrala Call sk_mark_napi_id() in the ACK receive path of a TCP_NEW_SYN_RECV socket, so that sk->napi_id is set even if the socket hasn't yet received any data. With this change we should be able to start busy polling slightly earlier.

[net-next PATCH 2/5] net: Call sk_mark_napi_id() in the ACK receive path

From: Sridhar Samudrala Call sk_mark_napi_id() in the ACK receive path of a TCP_NEW_SYN_RECV socket, so that sk->napi_id is set even if the socket hasn't yet received any data. With this change we should be able to start busy polling slightly earlier. Signed-off-by: Sridhar Samudrala

Re: [RESEND PATCH 1/2] auxdisplay: img-ascii-lcd: Add a sentinel entry to OF device ID table

Hello Dmitry, On 03/16/2017 03:25 PM, Dmitry Torokhov wrote: > On Fri, Mar 10, 2017 at 10:22 AM, Dmitry Torokhov > wrote: >> >> On Fri, Mar 10, 2017 at 10:33:06AM -0300, Javier Martinez Canillas wrote: >>> The OF device ID table doesn't have a sentinel NULL entry and

Re: [RESEND PATCH 1/2] auxdisplay: img-ascii-lcd: Add a sentinel entry to OF device ID table

Hello Dmitry, On 03/16/2017 03:25 PM, Dmitry Torokhov wrote: > On Fri, Mar 10, 2017 at 10:22 AM, Dmitry Torokhov > wrote: >> >> On Fri, Mar 10, 2017 at 10:33:06AM -0300, Javier Martinez Canillas wrote: >>> The OF device ID table doesn't have a sentinel NULL entry and so it >>> causes the

Re: [PATCH 1/3] mm: page_alloc: Reduce object size by neatening printks

On Thu, 2017-03-16 at 20:30 +0900, Sergey Senozhatsky wrote: > On (03/15/17 18:43), Joe Perches wrote: > [..] > > - printk("active_anon:%lu inactive_anon:%lu isolated_anon:%lu\n" > > - " active_file:%lu inactive_file:%lu isolated_file:%lu\n" > > - " unevictable:%lu dirty:%lu

Re: [PATCH 1/3] mm: page_alloc: Reduce object size by neatening printks

On Thu, 2017-03-16 at 20:30 +0900, Sergey Senozhatsky wrote: > On (03/15/17 18:43), Joe Perches wrote: > [..] > > - printk("active_anon:%lu inactive_anon:%lu isolated_anon:%lu\n" > > - " active_file:%lu inactive_file:%lu isolated_file:%lu\n" > > - " unevictable:%lu dirty:%lu

Re: 'perf test tsc' failing, bisected to "sched/clock: Provide better clock continuity"

Em Thu, Mar 16, 2017 at 07:11:21PM +0100, Peter Zijlstra escreveu: > On Thu, Mar 16, 2017 at 03:53:11PM +0100, Peter Zijlstra wrote: > > On Thu, Mar 16, 2017 at 11:01:03AM -0300, Arnaldo Carvalho de Melo wrote: > > > [root@jouet ~]# perf test -v tsc > > > 55: Convert perf time to TSC

Re: [PATCH] x86: mostly disable '-maccumulate-outgoing-args'

On Thu, Mar 16, 2017 at 01:32:01PM -0400, Steven Rostedt wrote: > On Thu, 16 Mar 2017 10:42:08 -0500 > Josh Poimboeuf wrote: > > > Signed-off-by: Josh Poimboeuf > > --- > > arch/x86/Makefile| 29 + > >

Re: [PATCH v2 0/5] mm: support parallel free of memory

On Thu, 2017-03-16 at 10:07 +0100, Michal Hocko wrote: > On Wed 15-03-17 14:38:34, Tim Chen wrote: > > > > On Wed, 2017-03-15 at 17:28 +0100, Michal Hocko wrote: > > > > > > On Wed 15-03-17 23:44:07, Aaron Lu wrote: > > > > > > > > > > > > On Wed, Mar 15, 2017 at 03:18:14PM +0100, Michal Hocko

Re: 'perf test tsc' failing, bisected to "sched/clock: Provide better clock continuity"

Em Thu, Mar 16, 2017 at 07:11:21PM +0100, Peter Zijlstra escreveu: > On Thu, Mar 16, 2017 at 03:53:11PM +0100, Peter Zijlstra wrote: > > On Thu, Mar 16, 2017 at 11:01:03AM -0300, Arnaldo Carvalho de Melo wrote: > > > [root@jouet ~]# perf test -v tsc > > > 55: Convert perf time to TSC

Re: [PATCH] x86: mostly disable '-maccumulate-outgoing-args'

On Thu, Mar 16, 2017 at 01:32:01PM -0400, Steven Rostedt wrote: > On Thu, 16 Mar 2017 10:42:08 -0500 > Josh Poimboeuf wrote: > > > Signed-off-by: Josh Poimboeuf > > --- > > arch/x86/Makefile| 29 + > > arch/x86/Makefile_32.cpu | 18 -- > >

Re: [PATCH v2 0/5] mm: support parallel free of memory

On Thu, 2017-03-16 at 10:07 +0100, Michal Hocko wrote: > On Wed 15-03-17 14:38:34, Tim Chen wrote: > > > > On Wed, 2017-03-15 at 17:28 +0100, Michal Hocko wrote: > > > > > > On Wed 15-03-17 23:44:07, Aaron Lu wrote: > > > > > > > > > > > > On Wed, Mar 15, 2017 at 03:18:14PM +0100, Michal Hocko

Re: [RFC PATCH v2 30/32] kvm: svm: Add support for SEV DEBUG_ENCRYPT command

On 03/16/2017 06:03 AM, Paolo Bonzini wrote: On 02/03/2017 16:18, Brijesh Singh wrote: + data = (void *) get_zeroed_page(GFP_KERNEL); The page does not need to be zeroed, does it? No, we don't have to zero it. I will fix it. + + if ((len & 15) || (dst_addr & 15)) { +

Re: [RFC PATCH v2 30/32] kvm: svm: Add support for SEV DEBUG_ENCRYPT command

On 03/16/2017 06:03 AM, Paolo Bonzini wrote: On 02/03/2017 16:18, Brijesh Singh wrote: + data = (void *) get_zeroed_page(GFP_KERNEL); The page does not need to be zeroed, does it? No, we don't have to zero it. I will fix it. + + if ((len & 15) || (dst_addr & 15)) { +

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