[PATCH 1/6] ftrace: Remove incorrect setting of glob search field

From: "Steven Rostedt (VMware)" __unregister_ftrace_function_probe() will incorrectly parse the glob filter because it resets the search variable that was setup by filter_parse_regex(). Al Viro reported this: After that call of filter_parse_regex() we could have

[PATCH 0/6] [GIT PULL] tracing: Some fixes to filter parsing

Linus, Al Viro discovered some breakage with the parsing of the set_ftrace_filter as well as the removing of function probes. This fixes the code with Al's suggestions. I also added a few selftests to test the broken cases such that they wont happen again. Please pull the latest

[PATCH 0/6] [GIT PULL] tracing: Some fixes to filter parsing

Linus, Al Viro discovered some breakage with the parsing of the set_ftrace_filter as well as the removing of function probes. This fixes the code with Al's suggestions. I also added a few selftests to test the broken cases such that they wont happen again. Please pull the latest

[PATCH 1/6] ftrace: Remove incorrect setting of glob search field

From: "Steven Rostedt (VMware)" __unregister_ftrace_function_probe() will incorrectly parse the glob filter because it resets the search variable that was setup by filter_parse_regex(). Al Viro reported this: After that call of filter_parse_regex() we could have func_g.search not equal

[GIT] Networking

1) Make allocations less aggressive in x_tables, from Minchal Hocko. 2) Fix netfilter flowtable Kconfig deps, from Pablo Neira Ayuso. 3) Fix connection loss problems in rtlwifi, from Larry Finger. 4) Correct DRAM dump length for some chips in ath10k driver, from Yu Wang. 5) Fix ABORT

[GIT] Networking

1) Make allocations less aggressive in x_tables, from Minchal Hocko. 2) Fix netfilter flowtable Kconfig deps, from Pablo Neira Ayuso. 3) Fix connection loss problems in rtlwifi, from Larry Finger. 4) Correct DRAM dump length for some chips in ath10k driver, from Yu Wang. 5) Fix ABORT

Re: [PATCH 09/31] x86/entry/32: Leave the kernel via trampoline stack

On Fri, Feb 9, 2018 at 11:25 AM, Joerg Roedel wrote: > > Ugh, okay. So I switch to movsl, that should at least perform on-par > with the chain of 'pushl' instructions I had before. It should generally be roughly in the same ballpark. I think the instruction scheduling ends up

Re: [PATCH 09/31] x86/entry/32: Leave the kernel via trampoline stack

On Fri, Feb 9, 2018 at 11:25 AM, Joerg Roedel wrote: > > Ugh, okay. So I switch to movsl, that should at least perform on-par > with the chain of 'pushl' instructions I had before. It should generally be roughly in the same ballpark. I think the instruction scheduling ends up basically breaking

Re: [RFC] Rebasing the IDR

On Mon, Dec 11, 2017 at 10:54:51AM +, Chris Wilson wrote: > Quoting Matthew Wilcox (2017-11-30 17:36:30) > > About 40 of the approximately 180 users of the IDR in the kernel are > > "1-based" instead of "0-based". That is, they never want to have ID 0 > > allocated; they want to see IDs

Re: [RFC] Rebasing the IDR

On Mon, Dec 11, 2017 at 10:54:51AM +, Chris Wilson wrote: > Quoting Matthew Wilcox (2017-11-30 17:36:30) > > About 40 of the approximately 180 users of the IDR in the kernel are > > "1-based" instead of "0-based". That is, they never want to have ID 0 > > allocated; they want to see IDs

Re: [GIT PULL] xen: fixes for 4.16 rc1

On Fri, Feb 9, 2018 at 10:59 AM, Juergen Gross wrote: > > Do you want me to setup the patches for pulling again? No, I've pulled, I just don't want to see these unexplained merges again. Preferably I don't want to see back-merges at all, but when I do see them, I want to see an

Re: [GIT PULL] xen: fixes for 4.16 rc1

On Fri, Feb 9, 2018 at 10:59 AM, Juergen Gross wrote: > > Do you want me to setup the patches for pulling again? No, I've pulled, I just don't want to see these unexplained merges again. Preferably I don't want to see back-merges at all, but when I do see them, I want to see an explanation for

Re: [PATCH 1/7] watchdog: sama5d4: make use of timeout-secs provided in devicetree

The summary email did not make it for some reason. However. All these drivers is using watchdog_init_timeout() to set timeout. If the timeout-parameter is set to an valid value, it will allways pick that and not even consider if timeout-secs is set in devicetree. Most of the patches will just

Re: [PATCH 1/7] watchdog: sama5d4: make use of timeout-secs provided in devicetree

The summary email did not make it for some reason. However. All these drivers is using watchdog_init_timeout() to set timeout. If the timeout-parameter is set to an valid value, it will allways pick that and not even consider if timeout-secs is set in devicetree. Most of the patches will just

[PATCH 1/7] watchdog: sama5d4: make use of timeout-secs provided in devicetree

watchdog_init_timeout() will allways pick timeout_param since it defaults to a valid timeout. Following best practice described in Documentation/watchdog/watchdog-kernel-api.txt to make use of the parameter logic. Signed-off-by: Marcus Folkesson ---

Re: [PATCH 09/31] x86/entry/32: Leave the kernel via trampoline stack

On 02/09/2018 08:02 PM, Joerg Roedel wrote: On Fri, Feb 09, 2018 at 09:05:02AM -0800, Linus Torvalds wrote: On Fri, Feb 9, 2018 at 1:25 AM, Joerg Roedel wrote: + + /* Copy over the stack-frame */ + cld + rep movsb Ugh. This is going to be horrendous. Maybe

[PATCH 1/7] watchdog: sama5d4: make use of timeout-secs provided in devicetree

watchdog_init_timeout() will allways pick timeout_param since it defaults to a valid timeout. Following best practice described in Documentation/watchdog/watchdog-kernel-api.txt to make use of the parameter logic. Signed-off-by: Marcus Folkesson --- drivers/watchdog/sama5d4_wdt.c | 4 ++-- 1

Re: [PATCH 09/31] x86/entry/32: Leave the kernel via trampoline stack

On 02/09/2018 08:02 PM, Joerg Roedel wrote: On Fri, Feb 09, 2018 at 09:05:02AM -0800, Linus Torvalds wrote: On Fri, Feb 9, 2018 at 1:25 AM, Joerg Roedel wrote: + + /* Copy over the stack-frame */ + cld + rep movsb Ugh. This is going to be horrendous. Maybe not noticeable

[PATCH 3/7] watchdog: sirfsoc: allow setting timeout in devicetree

watchdog_init_timeout() will allways pick timeout_param since it defaults to a valid timeout. By following best practice described in Documentation/watchdog/watchdog-kernel-api.txt, it also let us to set timout-sec property in devicetree. Signed-off-by: Marcus Folkesson

[PATCH 3/7] watchdog: sirfsoc: allow setting timeout in devicetree

watchdog_init_timeout() will allways pick timeout_param since it defaults to a valid timeout. By following best practice described in Documentation/watchdog/watchdog-kernel-api.txt, it also let us to set timout-sec property in devicetree. Signed-off-by: Marcus Folkesson ---

[PATCH 2/7] watchdog: sunxi: allow setting timeout in devicetree

watchdog_init_timeout() will allways pick timeout_param since it defaults to a valid timeout. By following best practice described in Documentation/watchdog/watchdog-kernel-api.txt, it also let us to set timout-sec property in devicetree. Signed-off-by: Marcus Folkesson

[PATCH 2/7] watchdog: sunxi: allow setting timeout in devicetree

watchdog_init_timeout() will allways pick timeout_param since it defaults to a valid timeout. By following best practice described in Documentation/watchdog/watchdog-kernel-api.txt, it also let us to set timout-sec property in devicetree. Signed-off-by: Marcus Folkesson ---

[PATCH 5/7] watchdog: mtk: allow setting timeout in devicetree

watchdog_init_timeout() will allways pick timeout_param since it defaults to a valid timeout. By following best practice described in Documentation/watchdog/watchdog-kernel-api.txt, it also let us to set timout-sec property in devicetree. Signed-off-by: Marcus Folkesson

[PATCH 5/7] watchdog: mtk: allow setting timeout in devicetree

watchdog_init_timeout() will allways pick timeout_param since it defaults to a valid timeout. By following best practice described in Documentation/watchdog/watchdog-kernel-api.txt, it also let us to set timout-sec property in devicetree. Signed-off-by: Marcus Folkesson ---

Re: WARNING: suspicious RCU usage in tipc_bearer_find

On Fri, Feb 9, 2018 at 8:27 PM, syzbot wrote: > Hello, > > syzbot hit the following crash on net-next commit > 617aebe6a97efa539cc4b8a52adccd89596e6be0 (Sun Feb 4 00:25:42 2018 +) > Merge tag 'usercopy-v4.16-rc1' of >

Re: WARNING: suspicious RCU usage in tipc_bearer_find

On Fri, Feb 9, 2018 at 8:27 PM, syzbot wrote: > Hello, > > syzbot hit the following crash on net-next commit > 617aebe6a97efa539cc4b8a52adccd89596e6be0 (Sun Feb 4 00:25:42 2018 +) > Merge tag 'usercopy-v4.16-rc1' of > git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux > > So far this

Re: [PATCH V4 1/2] ptr_ring: fail early if queue occupies more than KMALLOC_MAX_SIZE

From: Jason Wang Date: Fri, 9 Feb 2018 17:45:49 +0800 > To avoid slab to warn about exceeded size, fail early if queue > occupies more than KMALLOC_MAX_SIZE. > > Reported-by: syzbot+e4d4f9ddd42955397...@syzkaller.appspotmail.com > Fixes: 2e0ab8ca83c12 ("ptr_ring: array

Re: [PATCH V4 2/2] ptr_ring: try vmalloc() when kmalloc() fails

From: Jason Wang Date: Fri, 9 Feb 2018 17:45:50 +0800 > This patch switch to use kvmalloc_array() for using a vmalloc() > fallback to help in case kmalloc() fails. > > Reported-by: syzbot+e4d4f9ddd42955397...@syzkaller.appspotmail.com > Fixes: 2e0ab8ca83c12 ("ptr_ring:

Re: [PATCH V4 1/2] ptr_ring: fail early if queue occupies more than KMALLOC_MAX_SIZE

From: Jason Wang Date: Fri, 9 Feb 2018 17:45:49 +0800 > To avoid slab to warn about exceeded size, fail early if queue > occupies more than KMALLOC_MAX_SIZE. > > Reported-by: syzbot+e4d4f9ddd42955397...@syzkaller.appspotmail.com > Fixes: 2e0ab8ca83c12 ("ptr_ring: array based FIFO for

Re: [PATCH V4 2/2] ptr_ring: try vmalloc() when kmalloc() fails

From: Jason Wang Date: Fri, 9 Feb 2018 17:45:50 +0800 > This patch switch to use kvmalloc_array() for using a vmalloc() > fallback to help in case kmalloc() fails. > > Reported-by: syzbot+e4d4f9ddd42955397...@syzkaller.appspotmail.com > Fixes: 2e0ab8ca83c12 ("ptr_ring: array based FIFO for

[PATCH 7/7] watchdog: coh901327: make use of timeout-secs provided in devicetree

watchdog_init_timeout() will allways pick timeout_param since it defaults to a valid timeout. Following best practice described in Documentation/watchdog/watchdog-kernel-api.txt to make use of the parameter logic. Signed-off-by: Marcus Folkesson ---

[PATCH 7/7] watchdog: coh901327: make use of timeout-secs provided in devicetree

watchdog_init_timeout() will allways pick timeout_param since it defaults to a valid timeout. Following best practice described in Documentation/watchdog/watchdog-kernel-api.txt to make use of the parameter logic. Signed-off-by: Marcus Folkesson --- drivers/watchdog/coh901327_wdt.c | 2 +- 1

Re: [PATCH v4 00/20] crypto: arm64 - play nice with CONFIG_PREEMPT

On 9 February 2018 at 18:02, Sebastian Andrzej Siewior wrote: > On 2017-12-26 10:29:20 [+], Ard Biesheuvel wrote: >> As reported by Sebastian, the way the arm64 NEON crypto code currently >> keeps kernel mode NEON enabled across calls into skcipher_walk_xxx() is > … >>

Re: [PATCH v4 00/20] crypto: arm64 - play nice with CONFIG_PREEMPT

On 9 February 2018 at 18:02, Sebastian Andrzej Siewior wrote: > On 2017-12-26 10:29:20 [+], Ard Biesheuvel wrote: >> As reported by Sebastian, the way the arm64 NEON crypto code currently >> keeps kernel mode NEON enabled across calls into skcipher_walk_xxx() is > … >> So let's clean this up

[PATCH 0/7] watchdog: make use of timeout-secs

All these drivers is using watchdog_init_timeout() to set timeout. If the timeout-parameter is set to an valid value, it will allways pick that and not even consider if timeout-secs is set in the devicetree. Most of the patches will just remove the initial value for timeout-parameter. Some of

Re: suspicious RCU usage at net/tipc/bearer.c:LINE

On Thu, Feb 1, 2018 at 11:22 PM, Eric Biggers wrote: > On Sun, Dec 31, 2017 at 10:58:01AM -0800, syzbot wrote: >> Hello, >> >> syzkaller hit the following crash on >> 5aa90a84589282b87666f92b6c3c917c8080a9bf >>

[PATCH 0/7] watchdog: make use of timeout-secs

All these drivers is using watchdog_init_timeout() to set timeout. If the timeout-parameter is set to an valid value, it will allways pick that and not even consider if timeout-secs is set in the devicetree. Most of the patches will just remove the initial value for timeout-parameter. Some of

Re: suspicious RCU usage at net/tipc/bearer.c:LINE

On Thu, Feb 1, 2018 at 11:22 PM, Eric Biggers wrote: > On Sun, Dec 31, 2017 at 10:58:01AM -0800, syzbot wrote: >> Hello, >> >> syzkaller hit the following crash on >> 5aa90a84589282b87666f92b6c3c917c8080a9bf >> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master >> compiler:

[PATCH 4/7] watchdog: pnx4008: make use of timeout-secs provided in devicetree

watchdog_init_timeout() will allways pick timeout_param since it defaults to a valid timeout. Following best practice described in Documentation/watchdog/watchdog-kernel-api.txt to make use of the parameter logic. Signed-off-by: Marcus Folkesson ---

[PATCH 4/7] watchdog: pnx4008: make use of timeout-secs provided in devicetree

watchdog_init_timeout() will allways pick timeout_param since it defaults to a valid timeout. Following best practice described in Documentation/watchdog/watchdog-kernel-api.txt to make use of the parameter logic. Signed-off-by: Marcus Folkesson --- drivers/watchdog/pnx4008_wdt.c | 2 +- 1

[PATCH 6/7] watchdog: meson: allow setting timeout in devicetree

watchdog_init_timeout() will allways pick timeout_param since it defaults to a valid timeout. By following best practice described in Documentation/watchdog/watchdog-kernel-api.txt, it also let us to set timout-sec property in devicetree. Signed-off-by: Marcus Folkesson

[PATCH 6/7] watchdog: meson: allow setting timeout in devicetree

watchdog_init_timeout() will allways pick timeout_param since it defaults to a valid timeout. By following best practice described in Documentation/watchdog/watchdog-kernel-api.txt, it also let us to set timout-sec property in devicetree. Signed-off-by: Marcus Folkesson ---

Re: [PATCH 09/31] x86/entry/32: Leave the kernel via trampoline stack

On Fri, Feb 09, 2018 at 11:17:35AM -0800, Linus Torvalds wrote: > Yeah, it's only true on the very latest uarchs, and even there it's > not perfect for small copies. > > On the older machines that are relevant for 32-bit code, it's often > tens of cycles just for the ucode overhead, I think, and

Re: [PATCH 09/31] x86/entry/32: Leave the kernel via trampoline stack

On Fri, Feb 09, 2018 at 11:17:35AM -0800, Linus Torvalds wrote: > Yeah, it's only true on the very latest uarchs, and even there it's > not perfect for small copies. > > On the older machines that are relevant for 32-bit code, it's often > tens of cycles just for the ucode overhead, I think, and

Re: [PATCH net-next 0/3] stmmac irq fixes/cleanups

From: Niklas Cassel Date: Fri, 9 Feb 2018 17:22:44 +0100 > A couple of small stmmac irq fixes/cleanups. Seires applied.

Re: [PATCH net-next 0/3] stmmac irq fixes/cleanups

From: Niklas Cassel Date: Fri, 9 Feb 2018 17:22:44 +0100 > A couple of small stmmac irq fixes/cleanups. Seires applied.

[PATCH v3 1/1] mm: initialize pages on demand during boot

Deferred page initialization allows the boot cpu to initialize a small subset of the system's pages early in boot, with other cpus doing the rest later on. It is, however, problematic to know how many pages the kernel needs during boot. Different modules and kernel parameters may change the

[PATCH v3 0/1] initialize pages on demand during boot

Change log: v2 - v3 Andrew Morton's comments: - Moved read of pgdat->first_deferred_pfn into deferred_zone_grow_lock, thus got rid of READ_ONCE()/WRITE_ONCE() - Replaced spin_lock() with spin_lock_irqsave() in deferred_grow_zone - Updated

[PATCH v3 0/1] initialize pages on demand during boot

Change log: v2 - v3 Andrew Morton's comments: - Moved read of pgdat->first_deferred_pfn into deferred_zone_grow_lock, thus got rid of READ_ONCE()/WRITE_ONCE() - Replaced spin_lock() with spin_lock_irqsave() in deferred_grow_zone - Updated

[PATCH v3 1/1] mm: initialize pages on demand during boot

Deferred page initialization allows the boot cpu to initialize a small subset of the system's pages early in boot, with other cpus doing the rest later on. It is, however, problematic to know how many pages the kernel needs during boot. Different modules and kernel parameters may change the

Re: [PATCH 09/31] x86/entry/32: Leave the kernel via trampoline stack

On Fri, Feb 9, 2018 at 11:02 AM, Joerg Roedel wrote: > > Okay, I used movsb because I remembered that being the recommendation > for the most efficient memcpy, and it safes me an instruction. But that > is probably only true on modern CPUs. Yeah, it's only true on the very

Re: [PATCH 09/31] x86/entry/32: Leave the kernel via trampoline stack

On Fri, Feb 9, 2018 at 11:02 AM, Joerg Roedel wrote: > > Okay, I used movsb because I remembered that being the recommendation > for the most efficient memcpy, and it safes me an instruction. But that > is probably only true on modern CPUs. Yeah, it's only true on the very latest uarchs, and

Re: [PATCH] mm: thp: fix potential clearing to referenced flag in page_idle_clear_pte_refs_one()

On 2/9/18 12:16 AM, Kirill A. Shutemov wrote: On Thu, Feb 08, 2018 at 08:47:35PM -0800, Yang Shi wrote: On 2/8/18 8:33 PM, Kirill A. Shutemov wrote: On Thu, Feb 08, 2018 at 02:39:26PM -0800, Andrew Morton wrote: On Tue, 6 Feb 2018 08:06:36 +0800 Yang Shi

Re: [PATCH] mm: thp: fix potential clearing to referenced flag in page_idle_clear_pte_refs_one()

On 2/9/18 12:16 AM, Kirill A. Shutemov wrote: On Thu, Feb 08, 2018 at 08:47:35PM -0800, Yang Shi wrote: On 2/8/18 8:33 PM, Kirill A. Shutemov wrote: On Thu, Feb 08, 2018 at 02:39:26PM -0800, Andrew Morton wrote: On Tue, 6 Feb 2018 08:06:36 +0800 Yang Shi wrote: For PTE-mapped THP, the

[PATCH v2] mm: thp: fix potential clearing to referenced flag in page_idle_clear_pte_refs_one()

For PTE-mapped THP, the compound THP has not been split to normal 4K pages yet, the whole THP is considered referenced if any one of sub page is referenced. When walking PTE-mapped THP by pvmw, all relevant PTEs will be checked to retrieve referenced bit. But, the current code just returns the

[PATCH v2] mm: thp: fix potential clearing to referenced flag in page_idle_clear_pte_refs_one()

For PTE-mapped THP, the compound THP has not been split to normal 4K pages yet, the whole THP is considered referenced if any one of sub page is referenced. When walking PTE-mapped THP by pvmw, all relevant PTEs will be checked to retrieve referenced bit. But, the current code just returns the

Re: [PATCH] perf report: Add support to display group output for non group events

Em Fri, Feb 09, 2018 at 08:10:57PM +0100, Jiri Olsa escreveu: > On Fri, Feb 09, 2018 at 03:37:11PM -0300, Arnaldo Carvalho de Melo wrote: > > Em Fri, Feb 09, 2018 at 10:27:34AM +0100, Jiri Olsa escreveu: > > Humm, its a nice hack, but it would be even better if it didn't showed > > it as if it

Re: [PATCH] perf report: Add support to display group output for non group events

Em Fri, Feb 09, 2018 at 08:10:57PM +0100, Jiri Olsa escreveu: > On Fri, Feb 09, 2018 at 03:37:11PM -0300, Arnaldo Carvalho de Melo wrote: > > Em Fri, Feb 09, 2018 at 10:27:34AM +0100, Jiri Olsa escreveu: > > Humm, its a nice hack, but it would be even better if it didn't showed > > it as if it

Re: [PATCH 00/31 v2] PTI support for x86_32

Hi Andy, On Fri, Feb 09, 2018 at 05:47:43PM +, Andy Lutomirski wrote: > One thing worth noting is that performance of this whole series is > going to be abysmal due to the complete lack of 32-bit PCID. Maybe > any kernel built with this option set that runs on a CPU that has the > PCID bit

Re: [PATCH 00/31 v2] PTI support for x86_32

Hi Andy, On Fri, Feb 09, 2018 at 05:47:43PM +, Andy Lutomirski wrote: > One thing worth noting is that performance of this whole series is > going to be abysmal due to the complete lack of 32-bit PCID. Maybe > any kernel built with this option set that runs on a CPU that has the > PCID bit

Re: [PATCH] perf report: Add support to display group output for non group events

On Fri, Feb 09, 2018 at 03:37:11PM -0300, Arnaldo Carvalho de Melo wrote: > Em Fri, Feb 09, 2018 at 10:27:34AM +0100, Jiri Olsa escreveu: > > On Wed, Feb 07, 2018 at 10:52:35AM -0800, Stephane Eranian wrote: > > > > SNIP > > > > > >> Similar to what I get if I do instead: > > > >> $ perf record

Re: [PATCH] perf report: Add support to display group output for non group events

On Fri, Feb 09, 2018 at 03:37:11PM -0300, Arnaldo Carvalho de Melo wrote: > Em Fri, Feb 09, 2018 at 10:27:34AM +0100, Jiri Olsa escreveu: > > On Wed, Feb 07, 2018 at 10:52:35AM -0800, Stephane Eranian wrote: > > > > SNIP > > > > > >> Similar to what I get if I do instead: > > > >> $ perf record

Re: [PATCH 20/31] x86/mm/pae: Populate the user page-table with user pgd's

On Fri, Feb 09, 2018 at 05:48:36PM +, Andy Lutomirski wrote: > Can you rename the helper from pti_set_user_pgd() to > pti_set_user_top_level_entry() or similar? The name was already a bit > absurd, but now it's just nuts. Sure, I can do that, just pti_set_user_top_level_entry() is a bit

Re: [PATCH 20/31] x86/mm/pae: Populate the user page-table with user pgd's

On Fri, Feb 09, 2018 at 05:48:36PM +, Andy Lutomirski wrote: > Can you rename the helper from pti_set_user_pgd() to > pti_set_user_top_level_entry() or similar? The name was already a bit > absurd, but now it's just nuts. Sure, I can do that, just pti_set_user_top_level_entry() is a bit

Re: [PATCH 09/31] x86/entry/32: Leave the kernel via trampoline stack

On Fri, Feb 09, 2018 at 05:43:55PM +, Andy Lutomirski wrote: > The 64-bit code mostly uses a bunch of push instructions for this. I had it implemented with tons of push instructions first, but that doesn't work in cases where the stack switch needs to happen only after everything is copied

Re: [PATCH 09/31] x86/entry/32: Leave the kernel via trampoline stack

On Fri, Feb 09, 2018 at 05:43:55PM +, Andy Lutomirski wrote: > The 64-bit code mostly uses a bunch of push instructions for this. I had it implemented with tons of push instructions first, but that doesn't work in cases where the stack switch needs to happen only after everything is copied

Re: [PATCH 09/31] x86/entry/32: Leave the kernel via trampoline stack

On Fri, Feb 09, 2018 at 09:05:02AM -0800, Linus Torvalds wrote: > On Fri, Feb 9, 2018 at 1:25 AM, Joerg Roedel wrote: > > + > > + /* Copy over the stack-frame */ > > + cld > > + rep movsb > > Ugh. This is going to be horrendous. Maybe not noticeable on modern >

Re: [PATCH 09/31] x86/entry/32: Leave the kernel via trampoline stack

On Fri, Feb 09, 2018 at 09:05:02AM -0800, Linus Torvalds wrote: > On Fri, Feb 9, 2018 at 1:25 AM, Joerg Roedel wrote: > > + > > + /* Copy over the stack-frame */ > > + cld > > + rep movsb > > Ugh. This is going to be horrendous. Maybe not noticeable on modern > CPU's, but the

Re: [GIT PULL] xen: fixes for 4.16 rc1

On 09/02/18 19:48, Linus Torvalds wrote: > On Fri, Feb 9, 2018 at 6:28 AM, Juergen Gross wrote: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git >> for-linus-4.16-rc1-tag > > So I've pulled this, but the back-merges *really* annoy me. > > Seriously, DON'T DO

Re: [GIT PULL] xen: fixes for 4.16 rc1

On 09/02/18 19:48, Linus Torvalds wrote: > On Fri, Feb 9, 2018 at 6:28 AM, Juergen Gross wrote: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git >> for-linus-4.16-rc1-tag > > So I've pulled this, but the back-merges *really* annoy me. > > Seriously, DON'T DO MERGES IF YOU

Re: [PATCH v3 21/22] arm64: Delay enabling hardware DBM feature

On Fri, Feb 09, 2018 at 05:55:12PM +, Suzuki K Poulose wrote: > We enable hardware DBM bit in a capable CPU, very early in the > boot via __cpu_setup. This doesn't give us a flexibility of > optionally disable the feature, as the clearing the bit > is a bit costly as the TLB can cache the

Re: [PATCH v3 21/22] arm64: Delay enabling hardware DBM feature

On Fri, Feb 09, 2018 at 05:55:12PM +, Suzuki K Poulose wrote: > We enable hardware DBM bit in a capable CPU, very early in the > boot via __cpu_setup. This doesn't give us a flexibility of > optionally disable the feature, as the clearing the bit > is a bit costly as the TLB can cache the

Re: [PATCH 1/2] acpi/dptf: document sysfs atttributes

On Fri, 2018-02-09 at 11:31 +0100, Rafael J. Wysocki wrote: > On Wed, Feb 7, 2018 at 2:18 PM, Aishwarya Pant > wrote: > > The descriptions have been collected from git commit logs and > > reading > > through code. > > > > Signed-off-by: Aishwarya Pant > >

Re: [PATCH 1/2] acpi/dptf: document sysfs atttributes

On Fri, 2018-02-09 at 11:31 +0100, Rafael J. Wysocki wrote: > On Wed, Feb 7, 2018 at 2:18 PM, Aishwarya Pant > wrote: > > The descriptions have been collected from git commit logs and > > reading > > through code. > > > > Signed-off-by: Aishwarya Pant > > --- > >  

Re: [PATCH v2 2/2] arm64: dts: rockchip: enable I2S codec on rk3399-puma-haikou

Hi Klaus, Am Samstag, 3. Februar 2018, 16:50:16 CET schrieb Klaus Goger: > Enable the NXP SGTL5000 audio codec on the RK3399-Q7 EVK baseboard > Haikou. > > The i2s0_2ch_bus definition is only done in the SoM dtsi as it is > missing the LRCK_RX pin (that is used otherwise) and therefore not >

Re: [PATCH v2 2/2] arm64: dts: rockchip: enable I2S codec on rk3399-puma-haikou

Hi Klaus, Am Samstag, 3. Februar 2018, 16:50:16 CET schrieb Klaus Goger: > Enable the NXP SGTL5000 audio codec on the RK3399-Q7 EVK baseboard > Haikou. > > The i2s0_2ch_bus definition is only done in the SoM dtsi as it is > missing the LRCK_RX pin (that is used otherwise) and therefore not >

Re: [GIT PULL] xen: fixes for 4.16 rc1

On Fri, Feb 9, 2018 at 6:28 AM, Juergen Gross wrote: > > git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git > for-linus-4.16-rc1-tag So I've pulled this, but the back-merges *really* annoy me. Seriously, DON'T DO MERGES IF YOU CANNOT EVEN BE BOTHERED TO WRITE A REASON

Re: [GIT PULL] xen: fixes for 4.16 rc1

On Fri, Feb 9, 2018 at 6:28 AM, Juergen Gross wrote: > > git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git > for-linus-4.16-rc1-tag So I've pulled this, but the back-merges *really* annoy me. Seriously, DON'T DO MERGES IF YOU CANNOT EVEN BE BOTHERED TO WRITE A REASON FOR THEM! There

Re: [PATCH RFC tip/lkmm 04/10] EXP litmus_tests: Add comments explaining tests' purposes

On Fri, 9 Feb 2018, Paul E. McKenney wrote: > This commit adds comments to the litmus tests summarizing what these > tests are intended to demonstrate. > > Suggested-by: Ingo Molnar > Signed-off-by: Paul E. McKenney > [ paulmck: Apply Andrea's and

Re: [PATCH RFC tip/lkmm 04/10] EXP litmus_tests: Add comments explaining tests' purposes

On Fri, 9 Feb 2018, Paul E. McKenney wrote: > This commit adds comments to the litmus tests summarizing what these > tests are intended to demonstrate. > > Suggested-by: Ingo Molnar > Signed-off-by: Paul E. McKenney > [ paulmck: Apply Andrea's and Alan's feedback. ] > --- > ---

Re: [PATCH] perf report: Add support to display group output for non group events

Em Fri, Feb 09, 2018 at 03:37:11PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Fri, Feb 09, 2018 at 10:27:34AM +0100, Jiri Olsa escreveu: > > On Wed, Feb 07, 2018 at 10:52:35AM -0800, Stephane Eranian wrote: > > > > SNIP > > > > > >> Similar to what I get if I do instead: > > > >> $ perf

Re: [PATCH] perf report: Add support to display group output for non group events

Em Fri, Feb 09, 2018 at 03:37:11PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Fri, Feb 09, 2018 at 10:27:34AM +0100, Jiri Olsa escreveu: > > On Wed, Feb 07, 2018 at 10:52:35AM -0800, Stephane Eranian wrote: > > > > SNIP > > > > > >> Similar to what I get if I do instead: > > > >> $ perf

[GIT PULL] target updates for v4.16-rc1

Hi Linus, Here are the target-pending updates for v4.16-rc1. Please go ahead and pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git for-next The highlights include: - Numerous target-core-user improvements related to queue full and timeout handling. (MNC) -

[GIT PULL] target updates for v4.16-rc1

Hi Linus, Here are the target-pending updates for v4.16-rc1. Please go ahead and pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git for-next The highlights include: - Numerous target-core-user improvements related to queue full and timeout handling. (MNC) -

Re: [PATCH] perf report: Add support to display group output for non group events

Em Fri, Feb 09, 2018 at 10:27:34AM +0100, Jiri Olsa escreveu: > On Wed, Feb 07, 2018 at 10:52:35AM -0800, Stephane Eranian wrote: > > SNIP > > > >> Similar to what I get if I do instead: > > >> $ perf record -e '{branches,branches,branches,branches}' my_test > > >> $ perf report --group > > >> >

Re: [PATCH] perf report: Add support to display group output for non group events

Em Fri, Feb 09, 2018 at 10:27:34AM +0100, Jiri Olsa escreveu: > On Wed, Feb 07, 2018 at 10:52:35AM -0800, Stephane Eranian wrote: > > SNIP > > > >> Similar to what I get if I do instead: > > >> $ perf record -e '{branches,branches,branches,branches}' my_test > > >> $ perf report --group > > >> >

Re: [RFC][PATCH] : fix end_name_hash() for 64bit long

On Mon, Feb 5, 2018 at 9:32 AM, Amir Goldstein wrote: > The comment claims that this helper will try not to loose bits, but > for 64bit long it looses the high bits before hashing 64bit long into > 32bit int. Use the helper hash_long() to do the right thing for 64bit > long.

Re: [RFC][PATCH] : fix end_name_hash() for 64bit long

On Mon, Feb 5, 2018 at 9:32 AM, Amir Goldstein wrote: > The comment claims that this helper will try not to loose bits, but > for 64bit long it looses the high bits before hashing 64bit long into > 32bit int. Use the helper hash_long() to do the right thing for 64bit > long. For 32bit long, there

Re: [PATCH v3 11/22] arm64: capabilities: Group handling of features and errata workarounds

On Fri, Feb 09, 2018 at 05:54:51PM +, Suzuki K Poulose wrote: > Now that the features and errata workarounds have the same > rules and flow, group the handling of the tables. > > Cc: Dave Martin > Signed-off-by: Suzuki K Poulose The naming gets

Re: [PATCH v3 11/22] arm64: capabilities: Group handling of features and errata workarounds

On Fri, Feb 09, 2018 at 05:54:51PM +, Suzuki K Poulose wrote: > Now that the features and errata workarounds have the same > rules and flow, group the handling of the tables. > > Cc: Dave Martin > Signed-off-by: Suzuki K Poulose The naming gets a bit confusing, particularly with

Re: linux-next: manual merge of the tip tree with Linus' tree

On Thu, Feb 08, 2018 at 07:04:56PM +, Mathieu Desnoyers wrote: > - On Feb 8, 2018, at 1:56 PM, Will Deacon will.dea...@arm.com wrote: > > > On Thu, Feb 08, 2018 at 08:03:50AM +0100, Ingo Molnar wrote: > >> > >> * Will Deacon wrote: > >> > >> > For the sake of

Re: linux-next: manual merge of the tip tree with Linus' tree

On Thu, Feb 08, 2018 at 07:04:56PM +, Mathieu Desnoyers wrote: > - On Feb 8, 2018, at 1:56 PM, Will Deacon will.dea...@arm.com wrote: > > > On Thu, Feb 08, 2018 at 08:03:50AM +0100, Ingo Molnar wrote: > >> > >> * Will Deacon wrote: > >> > >> > For the sake of avoiding the conflict, can

Re: [PATCH v3 10/22] arm64: capabilities: Allow features based on local CPU scope

On Fri, Feb 09, 2018 at 05:54:49PM +, Suzuki K Poulose wrote: > So far we have treated the feature capabilities as system wide > and this doesn't help with features that could be detected on doesn't -> wouldn't (since no such features exist yet) detected to "detected locally" (maybe) > one

Re: [PATCH v3 10/22] arm64: capabilities: Allow features based on local CPU scope

On Fri, Feb 09, 2018 at 05:54:49PM +, Suzuki K Poulose wrote: > So far we have treated the feature capabilities as system wide > and this doesn't help with features that could be detected on doesn't -> wouldn't (since no such features exist yet) detected to "detected locally" (maybe) > one

Re: [PATCH 4.14 00/22] 4.14.19-stable review

On 02/09/2018 12:18 PM, Greg Kroah-Hartman wrote: Oops, yeah, I'll pick them up for the next release, sorry. Was traveling all this week and with the middle of the merge window, finding all of the stable patches that can be applied right now was hard. After 4.16-rc1 is out, it will get easier.

Re: [PATCH 4.14 00/22] 4.14.19-stable review

On 02/09/2018 12:18 PM, Greg Kroah-Hartman wrote: Oops, yeah, I'll pick them up for the next release, sorry. Was traveling all this week and with the middle of the merge window, finding all of the stable patches that can be applied right now was hard. After 4.16-rc1 is out, it will get easier.

Re: [PATCH 4.14 00/22] 4.14.19-stable review

On Fri, Feb 09, 2018 at 12:01:45PM -0600, Timur Tabi wrote: > On Fri, Feb 9, 2018 at 7:39 AM, Greg Kroah-Hartman > wrote: > > This is the start of the stable review cycle for the 4.14.19 release. > > There are 22 patches in this series, all will be posted as a response

Re: [PATCH v3 09/22] arm64: capabilities: Split the processing of errata work arounds

On Fri, Feb 09, 2018 at 05:54:48PM +, Suzuki K Poulose wrote: > Right now we run through the errata workarounds check on all boot > active CPUs, with SCOPE_ALL. This doesn't help with detecting the > errata's with a SYSTEM_SCOPE. While nobody uses it, let us clean > this up in preparation for

Re: [PATCH 4.14 00/22] 4.14.19-stable review

On Fri, Feb 09, 2018 at 12:01:45PM -0600, Timur Tabi wrote: > On Fri, Feb 9, 2018 at 7:39 AM, Greg Kroah-Hartman > wrote: > > This is the start of the stable review cycle for the 4.14.19 release. > > There are 22 patches in this series, all will be posted as a response > > to this one. If anyone

Re: [PATCH v3 09/22] arm64: capabilities: Split the processing of errata work arounds

On Fri, Feb 09, 2018 at 05:54:48PM +, Suzuki K Poulose wrote: > Right now we run through the errata workarounds check on all boot > active CPUs, with SCOPE_ALL. This doesn't help with detecting the > errata's with a SYSTEM_SCOPE. While nobody uses it, let us clean > this up in preparation for

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