Re: [PATCH v3 2/2] sysctl: handle overflow for file-max

2018-10-18 Thread Andrea Arcangeli
Hi Al, On Wed, Oct 17, 2018 at 01:35:48AM +0100, Al Viro wrote: > On Wed, Oct 17, 2018 at 12:33:22AM +0200, Christian Brauner wrote: > > Currently, when writing > > > > echo 18446744073709551616 > /proc/sys/fs/file-max > > > > /proc/sys/fs/file-max will overflow and be set to 0. That quickly >

Re: possible deadlock in aio_poll

2018-10-17 Thread Andrea Arcangeli
break; > } > - spin_unlock(>fd_wqh.lock); > + spin_unlock_irq(>fd_wqh.lock); > schedule(); > - spin_lock(>fd_wqh.lock); > + spin_lock_irq(>fd_wqh.lock); > } > __remove_wait_queue(>fd_wq

Re: possible deadlock in aio_poll

2018-10-17 Thread Andrea Arcangeli
break; > } > - spin_unlock(>fd_wqh.lock); > + spin_unlock_irq(>fd_wqh.lock); > schedule(); > - spin_lock(>fd_wqh.lock); > + spin_lock_irq(>fd_wqh.lock); > } > __remove_wait_queue(>fd_wq

Re: [PATCH] mm/thp: Correctly differentiate between mapped THP and PMD migration entry

2018-10-16 Thread Andrea Arcangeli
Hello Zi, On Sun, Oct 14, 2018 at 08:53:55PM -0400, Zi Yan wrote: > Hi Andrea, what is the purpose/benefit of making x86’s pmd_present() returns > true > for a THP under splitting? Does it cause problems when ARM64’s pmd_present() > returns false in the same situation? !pmd_present means it's a

Re: [PATCH] mm/thp: Correctly differentiate between mapped THP and PMD migration entry

2018-10-16 Thread Andrea Arcangeli
Hello Zi, On Sun, Oct 14, 2018 at 08:53:55PM -0400, Zi Yan wrote: > Hi Andrea, what is the purpose/benefit of making x86’s pmd_present() returns > true > for a THP under splitting? Does it cause problems when ARM64’s pmd_present() > returns false in the same situation? !pmd_present means it's a

Re: [PATCH 1/2] mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings

2018-10-16 Thread Andrea Arcangeli
Hello, On Tue, Oct 16, 2018 at 03:37:15PM -0700, Andrew Morton wrote: > we'll still make it into 4.19.1. Am reluctant to merge this while > discussion, testing and possibly more development are ongoing. I think there can be definitely more developments primarily to make the compact deferred

Re: [PATCH 1/2] mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings

2018-10-16 Thread Andrea Arcangeli
Hello, On Tue, Oct 16, 2018 at 03:37:15PM -0700, Andrew Morton wrote: > we'll still make it into 4.19.1. Am reluctant to merge this while > discussion, testing and possibly more development are ongoing. I think there can be definitely more developments primarily to make the compact deferred

Re: [PATCH 1/2] mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings

2018-10-15 Thread Andrea Arcangeli
Hello Andrew, On Mon, Oct 15, 2018 at 03:44:59PM -0700, Andrew Morton wrote: > On Mon, 15 Oct 2018 15:30:17 -0700 (PDT) David Rientjes > wrote: > > Would it be possible to test with my > > patch[*] that does not try reclaim to address the thrashing issue? > > Yes please. It'd also be great

Re: [PATCH 1/2] mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings

2018-10-15 Thread Andrea Arcangeli
Hello Andrew, On Mon, Oct 15, 2018 at 03:44:59PM -0700, Andrew Morton wrote: > On Mon, 15 Oct 2018 15:30:17 -0700 (PDT) David Rientjes > wrote: > > Would it be possible to test with my > > patch[*] that does not try reclaim to address the thrashing issue? > > Yes please. It'd also be great

Re: [PATCH 1/2] mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings

2018-10-15 Thread Andrea Arcangeli
On Mon, Oct 15, 2018 at 03:30:17PM -0700, David Rientjes wrote: > At the risk of beating a dead horse that has already been beaten, what are > the plans for this patch when the merge window opens? It would be rather > unfortunate for us to start incurring a 14% increase in access latency and >

Re: [PATCH 1/2] mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings

2018-10-15 Thread Andrea Arcangeli
On Mon, Oct 15, 2018 at 03:30:17PM -0700, David Rientjes wrote: > At the risk of beating a dead horse that has already been beaten, what are > the plans for this patch when the merge window opens? It would be rather > unfortunate for us to start incurring a 14% increase in access latency and >

Re: [PATCH] mm/thp: fix call to mmu_notifier in set_pmd_migration_entry()

2018-10-12 Thread Andrea Arcangeli
On Fri, Oct 12, 2018 at 01:35:19PM -0400, Jerome Glisse wrote: > On Fri, Oct 12, 2018 at 01:24:22PM -0400, Andrea Arcangeli wrote: > > Hello, > > > > On Fri, Oct 12, 2018 at 12:20:54PM -0400, Zi Yan wrote: > > > On 12 Oct 2018, at 12:09, jgli...@redhat.com wrot

Re: [PATCH] mm/thp: fix call to mmu_notifier in set_pmd_migration_entry()

2018-10-12 Thread Andrea Arcangeli
On Fri, Oct 12, 2018 at 01:35:19PM -0400, Jerome Glisse wrote: > On Fri, Oct 12, 2018 at 01:24:22PM -0400, Andrea Arcangeli wrote: > > Hello, > > > > On Fri, Oct 12, 2018 at 12:20:54PM -0400, Zi Yan wrote: > > > On 12 Oct 2018, at 12:09, jgli...@redhat.com wrot

Re: [PATCH] mm/thp: fix call to mmu_notifier in set_pmd_migration_entry()

2018-10-12 Thread Andrea Arcangeli
s not _range_only_end, if it was _range_only_end the above would be needed) > > calling mmu_notifier_invalidate_range_start/end() inside the function > > calling set_pmd_migration_entry() (see try_to_unmap_one()). > > > > Signed-off-by: Jérôme Glisse > > Reported-by: A

Re: [PATCH] mm/thp: fix call to mmu_notifier in set_pmd_migration_entry()

2018-10-12 Thread Andrea Arcangeli
s not _range_only_end, if it was _range_only_end the above would be needed) > > calling mmu_notifier_invalidate_range_start/end() inside the function > > calling set_pmd_migration_entry() (see try_to_unmap_one()). > > > > Signed-off-by: Jérôme Glisse > > Reported-by: A

Re: [PATCH 1/2] mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings

2018-10-09 Thread Andrea Arcangeli
On Tue, Oct 09, 2018 at 04:25:10PM +0200, Michal Hocko wrote: > On Tue 09-10-18 14:00:34, Mel Gorman wrote: > > On Tue, Oct 09, 2018 at 02:27:45PM +0200, Michal Hocko wrote: > > > [Sorry for being slow in responding but I was mostly offline last few > > > days] > > > > > > On Tue 09-10-18

Re: [PATCH 1/2] mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings

2018-10-09 Thread Andrea Arcangeli
On Tue, Oct 09, 2018 at 04:25:10PM +0200, Michal Hocko wrote: > On Tue 09-10-18 14:00:34, Mel Gorman wrote: > > On Tue, Oct 09, 2018 at 02:27:45PM +0200, Michal Hocko wrote: > > > [Sorry for being slow in responding but I was mostly offline last few > > > days] > > > > > > On Tue 09-10-18

Re: [PATCH 1/2] mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings

2018-10-09 Thread Andrea Arcangeli
On Tue, Oct 09, 2018 at 03:17:30PM -0700, David Rientjes wrote: > causes workloads to severely regress both in fault and access latency when > we know that direct reclaim is unlikely to make direct compaction free an > entire pageblock. It's more likely than not that the reclaim was >

Re: [PATCH 1/2] mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings

2018-10-09 Thread Andrea Arcangeli
On Tue, Oct 09, 2018 at 03:17:30PM -0700, David Rientjes wrote: > causes workloads to severely regress both in fault and access latency when > we know that direct reclaim is unlikely to make direct compaction free an > entire pageblock. It's more likely than not that the reclaim was >

Re: [PATCH 1/2] mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings

2018-10-09 Thread Andrea Arcangeli
On Mon, Oct 08, 2018 at 01:41:09PM -0700, David Rientjes wrote: > The page allocator is expecting __GFP_NORETRY for thp allocations per its > comment: > > /* >* Checks for costly allocations with __GFP_NORETRY, which >* includes THP page fault

Re: [PATCH 1/2] mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings

2018-10-09 Thread Andrea Arcangeli
On Mon, Oct 08, 2018 at 01:41:09PM -0700, David Rientjes wrote: > The page allocator is expecting __GFP_NORETRY for thp allocations per its > comment: > > /* >* Checks for costly allocations with __GFP_NORETRY, which >* includes THP page fault

Re: [PATCH 1/2] mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings

2018-10-05 Thread Andrea Arcangeli
Hello, On Thu, Oct 04, 2018 at 04:05:26PM -0700, David Rientjes wrote: > The source of the problem needs to be addressed: memory compaction. We > regress because we lose __GFP_NORETRY and pointlessly try reclaim, but I commented in detail about the __GFP_NORETRY topic in the other email so I

Re: [PATCH 1/2] mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings

2018-10-05 Thread Andrea Arcangeli
Hello, On Thu, Oct 04, 2018 at 04:05:26PM -0700, David Rientjes wrote: > The source of the problem needs to be addressed: memory compaction. We > regress because we lose __GFP_NORETRY and pointlessly try reclaim, but I commented in detail about the __GFP_NORETRY topic in the other email so I

Re: [PATCH 1/2] mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings

2018-10-05 Thread Andrea Arcangeli
Hi, On Fri, Oct 05, 2018 at 01:35:15PM -0700, David Rientjes wrote: > Why is it ever appropriate to do heavy reclaim and swap activity to > allocate a transparent hugepage? This is exactly what the __GFP_NORETRY > check for high-order allocations is attempting to avoid, and it explicitly >

Re: [PATCH 1/2] mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings

2018-10-05 Thread Andrea Arcangeli
Hi, On Fri, Oct 05, 2018 at 01:35:15PM -0700, David Rientjes wrote: > Why is it ever appropriate to do heavy reclaim and swap activity to > allocate a transparent hugepage? This is exactly what the __GFP_NORETRY > check for high-order allocations is attempting to avoid, and it explicitly >

Re: [PATCH 1/2] mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings

2018-10-04 Thread Andrea Arcangeli
Hello David, On Thu, Oct 04, 2018 at 01:16:32PM -0700, David Rientjes wrote: > There are ways to address this without introducing regressions for > existing users of MADV_HUGEPAGE: introduce an madvise() mode to accept > remote thp allocations, which users of this library would never set, or >

Re: [PATCH 1/2] mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings

2018-10-04 Thread Andrea Arcangeli
Hello David, On Thu, Oct 04, 2018 at 01:16:32PM -0700, David Rientjes wrote: > There are ways to address this without introducing regressions for > existing users of MADV_HUGEPAGE: introduce an madvise() mode to accept > remote thp allocations, which users of this library would never set, or >

Re: [PATCH] mm, thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings

2018-09-12 Thread Andrea Arcangeli
Hello, On Tue, Sep 11, 2018 at 01:56:13PM +0200, Michal Hocko wrote: > Well, it seems that expectations differ for users. It seems that kvm > users do not really agree with your interpretation. Like David also mentioned here:

Re: [PATCH] mm, thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings

2018-09-12 Thread Andrea Arcangeli
Hello, On Tue, Sep 11, 2018 at 01:56:13PM +0200, Michal Hocko wrote: > Well, it seems that expectations differ for users. It seems that kvm > users do not really agree with your interpretation. Like David also mentioned here:

Re: [PATCH v3 1/3] ptrace: Provide ___ptrace_may_access() that can be applied on arbitrary tasks

2018-09-05 Thread Andrea Arcangeli
On Wed, Sep 05, 2018 at 08:29:07PM +0200, Jiri Kosina wrote: > (and no, my testing of the patch I sent on current tree didn't produce any > hangs -- was there a reliable way to trigger it on 3.10?). Only a very specific libvirt acceptance test found this after a while and it wasn't a customer it

Re: [PATCH v3 1/3] ptrace: Provide ___ptrace_may_access() that can be applied on arbitrary tasks

2018-09-05 Thread Andrea Arcangeli
On Wed, Sep 05, 2018 at 08:29:07PM +0200, Jiri Kosina wrote: > (and no, my testing of the patch I sent on current tree didn't produce any > hangs -- was there a reliable way to trigger it on 3.10?). Only a very specific libvirt acceptance test found this after a while and it wasn't a customer it

Re: [PATCH v3 1/3] ptrace: Provide ___ptrace_may_access() that can be applied on arbitrary tasks

2018-09-05 Thread Andrea Arcangeli
On Wed, Sep 05, 2018 at 08:58:23AM -0700, Andi Kleen wrote: > > So, after giving it a bit more thought, I still believe "I want spectre V2 > > protection" vs. "I do not care about spectre V2 on my system > > (=nospectre_v2)" are the sane options we should provide; so I'll respin v4 > > of my

Re: [PATCH v3 1/3] ptrace: Provide ___ptrace_may_access() that can be applied on arbitrary tasks

2018-09-05 Thread Andrea Arcangeli
On Wed, Sep 05, 2018 at 08:58:23AM -0700, Andi Kleen wrote: > > So, after giving it a bit more thought, I still believe "I want spectre V2 > > protection" vs. "I do not care about spectre V2 on my system > > (=nospectre_v2)" are the sane options we should provide; so I'll respin v4 > > of my

Re: [PATCH v3 1/3] ptrace: Provide ___ptrace_may_access() that can be applied on arbitrary tasks

2018-09-04 Thread Andrea Arcangeli
On Wed, Sep 05, 2018 at 01:00:37AM +, Schaufler, Casey wrote: > Sorry, I've been working in security too long for my > optimistic streak to be very wide. Eheh. So I was simply trying to follow in context, but it wasn't entirely clear, so I tried to take it out of context and then it was even

Re: [PATCH v3 1/3] ptrace: Provide ___ptrace_may_access() that can be applied on arbitrary tasks

2018-09-04 Thread Andrea Arcangeli
On Wed, Sep 05, 2018 at 01:00:37AM +, Schaufler, Casey wrote: > Sorry, I've been working in security too long for my > optimistic streak to be very wide. Eheh. So I was simply trying to follow in context, but it wasn't entirely clear, so I tried to take it out of context and then it was even

Re: [PATCH v3 1/3] ptrace: Provide ___ptrace_may_access() that can be applied on arbitrary tasks

2018-09-04 Thread Andrea Arcangeli
Hello, On Tue, Sep 04, 2018 at 06:10:47PM +, Schaufler, Casey wrote: > The real reason to use an LSM based approach is that overloading ptrace > checks is a Really Bad Idea. Ptrace is a user interface. Side-channel is a > processor interface. Even if ptrace_may_access() does exactly what you

Re: [PATCH v3 1/3] ptrace: Provide ___ptrace_may_access() that can be applied on arbitrary tasks

2018-09-04 Thread Andrea Arcangeli
Hello, On Tue, Sep 04, 2018 at 06:10:47PM +, Schaufler, Casey wrote: > The real reason to use an LSM based approach is that overloading ptrace > checks is a Really Bad Idea. Ptrace is a user interface. Side-channel is a > processor interface. Even if ptrace_may_access() does exactly what you

Re: [PATCH] KVM: try __get_user_pages_fast even if not in atomic context

2018-08-06 Thread Andrea Arcangeli
n't be calling get_user_pages_unlocked in hva_to_pfn_slow if we could pass FOLL_HWPOISON to get_user_pages_fast. And get_user_pages_fast is really just __get_user_pages_fast + get_user_pages_unlocked with just a difference (see below). Reviewed-by: Andrea Arcangeli > > > Can we apply this tech to

Re: [PATCH] KVM: try __get_user_pages_fast even if not in atomic context

2018-08-06 Thread Andrea Arcangeli
n't be calling get_user_pages_unlocked in hva_to_pfn_slow if we could pass FOLL_HWPOISON to get_user_pages_fast. And get_user_pages_fast is really just __get_user_pages_fast + get_user_pages_unlocked with just a difference (see below). Reviewed-by: Andrea Arcangeli > > > Can we apply this tech to

Re: [PATCH] userfaultfd: hugetlbfs: Fix userfaultfd_huge_must_wait pte access

2018-07-03 Thread Andrea Arcangeli
Hello, On Wed, Jun 27, 2018 at 10:47:44AM +0200, Janosch Frank wrote: > On 26.06.2018 19:00, Mike Kravetz wrote: > > On 06/26/2018 06:24 AM, Janosch Frank wrote: > >> Use huge_ptep_get to translate huge ptes to normal ptes so we can > >> check them with the huge_pte_* functions. Otherwise some

Re: [PATCH] userfaultfd: hugetlbfs: Fix userfaultfd_huge_must_wait pte access

2018-07-03 Thread Andrea Arcangeli
Hello, On Wed, Jun 27, 2018 at 10:47:44AM +0200, Janosch Frank wrote: > On 26.06.2018 19:00, Mike Kravetz wrote: > > On 06/26/2018 06:24 AM, Janosch Frank wrote: > >> Use huge_ptep_get to translate huge ptes to normal ptes so we can > >> check them with the huge_pte_* functions. Otherwise some

Re: [PATCH v2] mm/ksm: ignore STABLE_FLAG of rmap_item->address in rmap_walk_ksm

2018-06-07 Thread Andrea Arcangeli
..@gmail.com > Signed-off-by: Jia He > Cc: Suzuki K Poulose > Cc: Andrea Arcangeli > Cc: Minchan Kim > Cc: Claudio Imbrenda > Cc: Arvind Yadav > Cc: Mike Rapoport > Cc: Jia He > Cc: > Signed-off-by: Andrew Morton > --- > Reviewed-by: Andrea Arcangeli

Re: [PATCH v2] mm/ksm: ignore STABLE_FLAG of rmap_item->address in rmap_walk_ksm

2018-06-07 Thread Andrea Arcangeli
..@gmail.com > Signed-off-by: Jia He > Cc: Suzuki K Poulose > Cc: Andrea Arcangeli > Cc: Minchan Kim > Cc: Claudio Imbrenda > Cc: Arvind Yadav > Cc: Mike Rapoport > Cc: Jia He > Cc: > Signed-off-by: Andrew Morton > --- > Reviewed-by: Andrea Arcangeli

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

2018-01-26 Thread Andrea Arcangeli
his would be used for any other equivalent issue in the future and it won't stick to these 3 files, I didn't implement that yet, because it's less urgent if nobody adds any more files soon. >From 578b411c8dcb1435dd1f94a6cd062f4eedb70fb5 Mon Sep 17 00:00:00 2001 From: Andrea Arcangeli <aarc

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

2018-01-26 Thread Andrea Arcangeli
his would be used for any other equivalent issue in the future and it won't stick to these 3 files, I didn't implement that yet, because it's less urgent if nobody adds any more files soon. >From 578b411c8dcb1435dd1f94a6cd062f4eedb70fb5 Mon Sep 17 00:00:00 2001 From: Andrea Arcangeli Date: Wed,

Re: [PATCH v2] mm: Reduce memory bloat with THP

2018-01-25 Thread Andrea Arcangeli
On Thu, Jan 25, 2018 at 10:58:32AM +0100, Michal Hocko wrote: > Ohh, absolutely. And that is why we have changed the default in upstream > 444eb2a449ef ("mm: thp: set THP defrag by default to madvise and add a > stall-free defrag option") Agreed, that direct compaction change should already

Re: [PATCH v2] mm: Reduce memory bloat with THP

2018-01-25 Thread Andrea Arcangeli
On Thu, Jan 25, 2018 at 10:58:32AM +0100, Michal Hocko wrote: > Ohh, absolutely. And that is why we have changed the default in upstream > 444eb2a449ef ("mm: thp: set THP defrag by default to madvise and add a > stall-free defrag option") Agreed, that direct compaction change should already

Re: [PATCH v2] mm: Reduce memory bloat with THP

2018-01-25 Thread Andrea Arcangeli
On Thu, Jan 25, 2018 at 11:41:03AM -0800, Nitin Gupta wrote: > I'm trying to address many different THP issues and memory bloat is > first among them. You quoted redis in an earlier email, the redis issue has nothing to do with MADV_DONTNEED. I can quickly explain the redis issue. Redis uses

Re: [PATCH v2] mm: Reduce memory bloat with THP

2018-01-25 Thread Andrea Arcangeli
On Thu, Jan 25, 2018 at 11:41:03AM -0800, Nitin Gupta wrote: > I'm trying to address many different THP issues and memory bloat is > first among them. You quoted redis in an earlier email, the redis issue has nothing to do with MADV_DONTNEED. I can quickly explain the redis issue. Redis uses

Re: [RH72 Spectre] ibpb_enabled = 1 leads to hard LOCKUP under x86_64 host machine

2018-01-20 Thread Andrea Arcangeli
Hello everyone, On Sat, Jan 20, 2018 at 01:56:08PM +, Van De Ven, Arjan wrote: > well first of all don't use IBRS, use retpoline This issue triggers in the IBPB code during user to user context switch and IBPB is still needed there no matter if kernel is using retpolines or if it uses kernel

Re: [RH72 Spectre] ibpb_enabled = 1 leads to hard LOCKUP under x86_64 host machine

2018-01-20 Thread Andrea Arcangeli
Hello everyone, On Sat, Jan 20, 2018 at 01:56:08PM +, Van De Ven, Arjan wrote: > well first of all don't use IBRS, use retpoline This issue triggers in the IBPB code during user to user context switch and IBPB is still needed there no matter if kernel is using retpolines or if it uses kernel

Re: [PATCH 23/35] x86/speculation: Add basic speculation control code

2018-01-19 Thread Andrea Arcangeli
On Fri, Jan 19, 2018 at 04:15:33AM +, Van De Ven, Arjan wrote: > there is no such guarantee. Some of the IBRS implementations will > actually flush rather than disable, or flush parts and disable other > parts. To me it helps in order to memorize the spec to understand why the spec is the way

Re: [PATCH 23/35] x86/speculation: Add basic speculation control code

2018-01-19 Thread Andrea Arcangeli
On Fri, Jan 19, 2018 at 04:15:33AM +, Van De Ven, Arjan wrote: > there is no such guarantee. Some of the IBRS implementations will > actually flush rather than disable, or flush parts and disable other > parts. To me it helps in order to memorize the spec to understand why the spec is the way

Re: [PATCH 23/35] x86/speculation: Add basic speculation control code

2018-01-18 Thread Andrea Arcangeli
Hello, On Thu, Jan 18, 2018 at 03:25:25PM -0800, Andy Lutomirski wrote: > I read the whitepaper that documented the new MSRs a couple days ago > and I'm now completely unable to find it. If anyone could send the > link, that would be great. I see Andrew posted a link. > From memory, however,

Re: [PATCH 23/35] x86/speculation: Add basic speculation control code

2018-01-18 Thread Andrea Arcangeli
Hello, On Thu, Jan 18, 2018 at 03:25:25PM -0800, Andy Lutomirski wrote: > I read the whitepaper that documented the new MSRs a couple days ago > and I'm now completely unable to find it. If anyone could send the > link, that would be great. I see Andrew posted a link. > From memory, however,

Re: [PATCH 23/35] x86/speculation: Add basic speculation control code

2018-01-18 Thread Andrea Arcangeli
On Thu, Jan 18, 2018 at 12:24:31PM -0600, Josh Poimboeuf wrote: > On Thu, Jan 18, 2018 at 06:12:36PM +0100, Paolo Bonzini wrote: > > On 18/01/2018 18:08, Dave Hansen wrote: > > > On 01/18/2018 08:37 AM, Josh Poimboeuf wrote: > > >>> > > >>> --- a/Documentation/admin-guide/kernel-parameters.txt > >

Re: [PATCH 23/35] x86/speculation: Add basic speculation control code

2018-01-18 Thread Andrea Arcangeli
On Thu, Jan 18, 2018 at 12:24:31PM -0600, Josh Poimboeuf wrote: > On Thu, Jan 18, 2018 at 06:12:36PM +0100, Paolo Bonzini wrote: > > On 18/01/2018 18:08, Dave Hansen wrote: > > > On 01/18/2018 08:37 AM, Josh Poimboeuf wrote: > > >>> > > >>> --- a/Documentation/admin-guide/kernel-parameters.txt > >

Re: [mm 4.15-rc8] Random oopses under memory pressure.

2018-01-18 Thread Andrea Arcangeli
On Thu, Jan 18, 2018 at 06:45:00AM -0800, Dave Hansen wrote: > On 01/18/2018 04:25 AM, Kirill A. Shutemov wrote: > > [ 10.084024] diff: -858690919 > > [ 10.084258] hpage_nr_pages: 1 > > [ 10.084386] check1: 0 > > [ 10.084478] check2: 0 > ... > > diff --git a/mm/page_vma_mapped.c

Re: [mm 4.15-rc8] Random oopses under memory pressure.

2018-01-18 Thread Andrea Arcangeli
On Thu, Jan 18, 2018 at 06:45:00AM -0800, Dave Hansen wrote: > On 01/18/2018 04:25 AM, Kirill A. Shutemov wrote: > > [ 10.084024] diff: -858690919 > > [ 10.084258] hpage_nr_pages: 1 > > [ 10.084386] check1: 0 > > [ 10.084478] check2: 0 > ... > > diff --git a/mm/page_vma_mapped.c

Re: [PATCH] x86/pti: unpoison pgd for trusted boot

2018-01-10 Thread Andrea Arcangeli
On Wed, Jan 10, 2018 at 02:49:39PM -0800, Dave Hansen wrote: > > Updated to make this on top of x86/pti. Reviewed-by: Andrea Arcangeli <aarca...@redhat.com>

Re: [PATCH] x86/pti: unpoison pgd for trusted boot

2018-01-10 Thread Andrea Arcangeli
On Wed, Jan 10, 2018 at 02:49:39PM -0800, Dave Hansen wrote: > > Updated to make this on top of x86/pti. Reviewed-by: Andrea Arcangeli

Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

2018-01-10 Thread Andrea Arcangeli
On Wed, Jan 10, 2018 at 01:35:45PM -0800, Tim Chen wrote: > time may not provide full protection on all cpu models. All right no problem at all, it's fixed up. Until very recently the majority of microcodes wasn't available in the first place so I guess it's no big issue if in a subset of those

Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

2018-01-10 Thread Andrea Arcangeli
On Wed, Jan 10, 2018 at 01:35:45PM -0800, Tim Chen wrote: > time may not provide full protection on all cpu models. All right no problem at all, it's fixed up. Until very recently the majority of microcodes wasn't available in the first place so I guess it's no big issue if in a subset of those

Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

2018-01-10 Thread Andrea Arcangeli
On Wed, Jan 10, 2018 at 03:24:17PM +, David Woodhouse wrote: > Since it achieves nothing¹ but to make userspace run slower, there's no > need to write it again on returning to userspace. It will perform that > function just fine without doing so. Ok, very glad we are on the same page now.

Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

2018-01-10 Thread Andrea Arcangeli
On Wed, Jan 10, 2018 at 03:24:17PM +, David Woodhouse wrote: > Since it achieves nothing¹ but to make userspace run slower, there's no > need to write it again on returning to userspace. It will perform that > function just fine without doing so. Ok, very glad we are on the same page now.

Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

2018-01-10 Thread Andrea Arcangeli
On Wed, Jan 10, 2018 at 06:59:54AM -0800, Dave Hansen wrote: > On 01/10/2018 06:10 AM, Andrea Arcangeli wrote: > > Tim and Dave please comment too, Tim you originally wrote that code > > that leaves IBRS always on and never toggles it in the kernel entry > > point so yo

Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

2018-01-10 Thread Andrea Arcangeli
On Wed, Jan 10, 2018 at 06:59:54AM -0800, Dave Hansen wrote: > On 01/10/2018 06:10 AM, Andrea Arcangeli wrote: > > Tim and Dave please comment too, Tim you originally wrote that code > > that leaves IBRS always on and never toggles it in the kernel entry > > point so yo

Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

2018-01-10 Thread Andrea Arcangeli
Hello, On Wed, Jan 10, 2018 at 02:46:22PM +0100, Thomas Gleixner wrote: > So here is the simple list of questions all to be answered with YES or > NO. I don't want to see any of the 'but, though ...'. We all know by now > that it's CPU dependent and slow and whatever and that IBRS_ATT will be in

Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

2018-01-10 Thread Andrea Arcangeli
Hello, On Wed, Jan 10, 2018 at 02:46:22PM +0100, Thomas Gleixner wrote: > So here is the simple list of questions all to be answered with YES or > NO. I don't want to see any of the 'but, though ...'. We all know by now > that it's CPU dependent and slow and whatever and that IBRS_ATT will be in

Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

2018-01-10 Thread Andrea Arcangeli
On Wed, Jan 10, 2018 at 01:45:52PM +, Van De Ven, Arjan wrote: > > > Andrea, what you're saying is directly contradicting what I've heard > > from Intel. > > > > The documentation already distinguishes between IBRS on current > > hardware, and IBRS_ATT on future hardware. If it was the case

Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

2018-01-10 Thread Andrea Arcangeli
On Wed, Jan 10, 2018 at 01:45:52PM +, Van De Ven, Arjan wrote: > > > Andrea, what you're saying is directly contradicting what I've heard > > from Intel. > > > > The documentation already distinguishes between IBRS on current > > hardware, and IBRS_ATT on future hardware. If it was the case

Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

2018-01-10 Thread Andrea Arcangeli
On Wed, Jan 10, 2018 at 02:10:10PM +0100, Andrea Arcangeli wrote: > It's still incredibly faster to shutdown part of the CPU temporarily > than to flush its internal state as a whole with IBPB. If it wouldn't > be the case ibrs_enabled 0 ibpb_enabled 2 special mode would perform

Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

2018-01-10 Thread Andrea Arcangeli
On Wed, Jan 10, 2018 at 02:10:10PM +0100, Andrea Arcangeli wrote: > It's still incredibly faster to shutdown part of the CPU temporarily > than to flush its internal state as a whole with IBPB. If it wouldn't > be the case ibrs_enabled 0 ibpb_enabled 2 special mode would perform

Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

2018-01-10 Thread Andrea Arcangeli
On Wed, Jan 10, 2018 at 02:05:51PM +0100, Andrea Arcangeli wrote: > Also note, the slowdown of setting IBRS varies with older CPUs being To give a further detail, older CPUs to provide IBRS semantics have to do something even less finegrined that doesn't just restricts speculation across I

Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

2018-01-10 Thread Andrea Arcangeli
On Wed, Jan 10, 2018 at 02:05:51PM +0100, Andrea Arcangeli wrote: > Also note, the slowdown of setting IBRS varies with older CPUs being To give a further detail, older CPUs to provide IBRS semantics have to do something even less finegrined that doesn't just restricts speculation across I

Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

2018-01-10 Thread Andrea Arcangeli
On Wed, Jan 10, 2018 at 02:02:02PM +0100, Andrea Arcangeli wrote: > On Wed, Jan 10, 2018 at 12:51:13PM +, David Woodhouse wrote: > > If it worked as Andrea suggests, then there would be absolutely no > > point in the patches we've seen which add the IBRS-frobbing on sy

Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

2018-01-10 Thread Andrea Arcangeli
On Wed, Jan 10, 2018 at 02:02:02PM +0100, Andrea Arcangeli wrote: > On Wed, Jan 10, 2018 at 12:51:13PM +, David Woodhouse wrote: > > If it worked as Andrea suggests, then there would be absolutely no > > point in the patches we've seen which add the IBRS-frobbing on sy

Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

2018-01-10 Thread Andrea Arcangeli
On Wed, Jan 10, 2018 at 12:51:13PM +, David Woodhouse wrote: > If it worked as Andrea suggests, then there would be absolutely no > point in the patches we've seen which add the IBRS-frobbing on syscall > entry and vmexit. This is perhaps what you're missing I think, there is a huge point:

Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

2018-01-10 Thread Andrea Arcangeli
On Wed, Jan 10, 2018 at 12:51:13PM +, David Woodhouse wrote: > If it worked as Andrea suggests, then there would be absolutely no > point in the patches we've seen which add the IBRS-frobbing on syscall > entry and vmexit. This is perhaps what you're missing I think, there is a huge point:

Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

2018-01-10 Thread Andrea Arcangeli
On Wed, Jan 10, 2018 at 01:47:22PM +0100, Jiri Kosina wrote: > On Wed, 10 Jan 2018, Andrea Arcangeli wrote: > > > Perhaps the confusing come from "less privileged prediction mode" and > > you thought that meant "less privileged ring mode". It says &quo

Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

2018-01-10 Thread Andrea Arcangeli
On Wed, Jan 10, 2018 at 01:47:22PM +0100, Jiri Kosina wrote: > On Wed, 10 Jan 2018, Andrea Arcangeli wrote: > > > Perhaps the confusing come from "less privileged prediction mode" and > > you thought that meant "less privileged ring mode". It says &quo

Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

2018-01-10 Thread Andrea Arcangeli
On Wed, Jan 10, 2018 at 12:29:44PM +, David Woodhouse wrote: > On Wed, 2018-01-10 at 13:17 +0100, Andrea Arcangeli wrote: > > On Wed, Jan 10, 2018 at 12:09:34PM +, David Woodhouse wrote: > > > That is not consistent with the documentation I've seen, which Intel > &g

Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

2018-01-10 Thread Andrea Arcangeli
On Wed, Jan 10, 2018 at 12:29:44PM +, David Woodhouse wrote: > On Wed, 2018-01-10 at 13:17 +0100, Andrea Arcangeli wrote: > > On Wed, Jan 10, 2018 at 12:09:34PM +, David Woodhouse wrote: > > > That is not consistent with the documentation I've seen, which Intel > &g

Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

2018-01-10 Thread Andrea Arcangeli
On Wed, Jan 10, 2018 at 01:20:45PM +0100, Andrea Arcangeli wrote: > On Wed, Jan 10, 2018 at 12:12:53PM +, David Woodhouse wrote: > > IBRS is like a barrier. You must write it between the 'problematic' > > loading of the branch targets, and the kernel code which might

Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

2018-01-10 Thread Andrea Arcangeli
On Wed, Jan 10, 2018 at 01:20:45PM +0100, Andrea Arcangeli wrote: > On Wed, Jan 10, 2018 at 12:12:53PM +, David Woodhouse wrote: > > IBRS is like a barrier. You must write it between the 'problematic' > > loading of the branch targets, and the kernel code which might

Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

2018-01-10 Thread Andrea Arcangeli
On Wed, Jan 10, 2018 at 12:12:53PM +, David Woodhouse wrote: > IBRS is like a barrier. You must write it between the 'problematic' > loading of the branch targets, and the kernel code which might be > affected. > > You cannot, on current hardware, merely set it once and forget about > it.

Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

2018-01-10 Thread Andrea Arcangeli
On Wed, Jan 10, 2018 at 12:12:53PM +, David Woodhouse wrote: > IBRS is like a barrier. You must write it between the 'problematic' > loading of the branch targets, and the kernel code which might be > affected. > > You cannot, on current hardware, merely set it once and forget about > it.

Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

2018-01-10 Thread Andrea Arcangeli
On Wed, Jan 10, 2018 at 12:09:34PM +, David Woodhouse wrote: > That is not consistent with the documentation I've seen, which Intel > have so far utterly failed to publish AFAICT. > > "a near indirect jump/call/return may be affected by code in a less privileged > prediction mode that

Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

2018-01-10 Thread Andrea Arcangeli
On Wed, Jan 10, 2018 at 12:09:34PM +, David Woodhouse wrote: > That is not consistent with the documentation I've seen, which Intel > have so far utterly failed to publish AFAICT. > > "a near indirect jump/call/return may be affected by code in a less privileged > prediction mode that

Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

2018-01-10 Thread Andrea Arcangeli
On Wed, Jan 10, 2018 at 01:01:58PM +0100, Andrea Arcangeli wrote: > On Wed, Jan 10, 2018 at 11:58:54AM +, David Woodhouse wrote: > > On Wed, 2018-01-10 at 12:54 +0100, Andrea Arcangeli wrote: > > > On Wed, Jan 10, 2018 at 09:27:59AM +, David Woodhouse wrote: > > >

Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

2018-01-10 Thread Andrea Arcangeli
On Wed, Jan 10, 2018 at 01:01:58PM +0100, Andrea Arcangeli wrote: > On Wed, Jan 10, 2018 at 11:58:54AM +, David Woodhouse wrote: > > On Wed, 2018-01-10 at 12:54 +0100, Andrea Arcangeli wrote: > > > On Wed, Jan 10, 2018 at 09:27:59AM +, David Woodhouse wrote: > > >

Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

2018-01-10 Thread Andrea Arcangeli
On Wed, Jan 10, 2018 at 11:58:54AM +, David Woodhouse wrote: > On Wed, 2018-01-10 at 12:54 +0100, Andrea Arcangeli wrote: > > On Wed, Jan 10, 2018 at 09:27:59AM +, David Woodhouse wrote: > > > I don't know why you're calling that 'IBRS=2'; are you getting > > co

Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

2018-01-10 Thread Andrea Arcangeli
On Wed, Jan 10, 2018 at 11:58:54AM +, David Woodhouse wrote: > On Wed, 2018-01-10 at 12:54 +0100, Andrea Arcangeli wrote: > > On Wed, Jan 10, 2018 at 09:27:59AM +, David Woodhouse wrote: > > > I don't know why you're calling that 'IBRS=2'; are you getting > > co

Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

2018-01-10 Thread Andrea Arcangeli
On Wed, Jan 10, 2018 at 09:27:59AM +, David Woodhouse wrote: > I don't know why you're calling that 'IBRS=2'; are you getting confused > by Andrea's distro horridness? Eh, yes he's got confused. ibrs_enabled 2 simply means to leave IBRS set in SPEC_CTLR 100% of the time, except in guest mode.

Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

2018-01-10 Thread Andrea Arcangeli
On Wed, Jan 10, 2018 at 09:27:59AM +, David Woodhouse wrote: > I don't know why you're calling that 'IBRS=2'; are you getting confused > by Andrea's distro horridness? Eh, yes he's got confused. ibrs_enabled 2 simply means to leave IBRS set in SPEC_CTLR 100% of the time, except in guest mode.

Re: Avoid speculative indirect calls in kernel

2018-01-08 Thread Andrea Arcangeli
m> Cc: Ning Sun <ning@intel.com> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Ingo Molnar <mi...@redhat.com> Cc: "H. Peter Anvin" <h...@zytor.com> Cc: x...@kernel.org Cc: tboot-de...@lists.sourceforge.net Cc: linux-kernel@vger.kernel.org Signed-off-by: Andrea

Re: Avoid speculative indirect calls in kernel

2018-01-08 Thread Andrea Arcangeli
Peter Anvin" Cc: x...@kernel.org Cc: tboot-de...@lists.sourceforge.net Cc: linux-kernel@vger.kernel.org Signed-off-by: Andrea Arcangeli --- arch/x86/kernel/tboot.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/x86/kernel/tboot.c b/arch/x86/kernel/tboot.c in

Re: [PATCH v2 4/8] x86/spec_ctrl: Add sysctl knobs to enable/disable SPEC_CTRL feature

2018-01-08 Thread Andrea Arcangeli
On Mon, Jan 08, 2018 at 08:43:40PM +0300, Alexey Dobriyan wrote: > > + len = sprintf(buf, "%d\n", READ_ONCE(*field)); > > READ_ONCE isn't necessary as there is only one read being made. Others might disagree but you shouldn't ever let gcc touch any memory that can change under gcc without

Re: [PATCH v2 4/8] x86/spec_ctrl: Add sysctl knobs to enable/disable SPEC_CTRL feature

2018-01-08 Thread Andrea Arcangeli
On Mon, Jan 08, 2018 at 08:43:40PM +0300, Alexey Dobriyan wrote: > > + len = sprintf(buf, "%d\n", READ_ONCE(*field)); > > READ_ONCE isn't necessary as there is only one read being made. Others might disagree but you shouldn't ever let gcc touch any memory that can change under gcc without

Re: Avoid speculative indirect calls in kernel

2018-01-08 Thread Andrea Arcangeli
Signed-off-by: Dave Hansen <dave.han...@linux.intel.com> Cc: Ning Sun <ning@intel.com> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Ingo Molnar <mi...@redhat.com> Cc: "H. Peter Anvin" <h...@zytor.com> Cc: x...@kernel.org Cc: tboot-de...@lists.sourcefor

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