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
>
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
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
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
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
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
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
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
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
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
>
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
>
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
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
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
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
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
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
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
>
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
>
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
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
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
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
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
>
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
>
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
>
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
>
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:
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:
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
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
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
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
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
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
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
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
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
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
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
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
..@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
..@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
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
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,
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
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
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
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
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
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
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
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
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,
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,
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
> >
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
> >
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
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
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>
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
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
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
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.
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.
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
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
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
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
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
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
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
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
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
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
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
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
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:
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:
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
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
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
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
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
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
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.
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.
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
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
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:
> > >
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:
> > >
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
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
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.
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.
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
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
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
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
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
301 - 400 of 3671 matches
Mail list logo