On Tue, 2020-06-02 at 16:28 -0700, Linus Torvalds wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you can confirm the sender and know the
> content is safe.
>
>
>
> On Tue, Jun 2, 2020 at 4:01 PM Singh, Balbir wrote:
>
On Tue, Jun 2, 2020 at 4:01 PM Singh, Balbir wrote:
>
> > (c) and if I read the code correctly, trying to flush the L1D$ on
> > non-intel without the HW support, it causes a WARN_ON_ONCE()! WTF?
>
> That is not correct, the function only complains if we do a software fallback
> flush without
On Tue, 2020-06-02 at 12:14 -0700, Linus Torvalds wrote:
>
> On Tue, Jun 2, 2020 at 11:29 AM Thomas Gleixner wrote:
> >
> > It's trivial enough to fix. We have a static key already which is
> > telling us whether SMT scheduling is active.
>
> .. but should we do it here, in switch_mm() in the f
On Tue, Jun 2, 2020 at 11:29 AM Thomas Gleixner wrote:
>
> It's trivial enough to fix. We have a static key already which is
> telling us whether SMT scheduling is active.
.. but should we do it here, in switch_mm() in the first place?
Should it perhaps just return an error if user land tries to
Benjamin Herrenschmidt writes:
> On Tue, 2020-06-02 at 09:33 +0200, Ingo Molnar wrote:
>> Or rather, we should ask a higher level question as well, maybe we
>> should not do this feature at all?
>
> Well, it does solve a real issue in some circumstances and there was a
> reasonable discussion abo
On Mon, 2020-06-01 at 19:35 -0700, Linus Torvalds wrote:
>
> On Mon, Jun 1, 2020 at 6:06 PM Balbir Singh wrote:
> >
> > I think apps can do this independently today as in do the flush
> > via software fallback in the app themselves.
>
> Sure, but they can't force the kernel to do crazy things f
On Tue, 2020-06-02 at 09:33 +0200, Ingo Molnar wrote:
> Or rather, we should ask a higher level question as well, maybe we
> should not do this feature at all?
Well, it does solve a real issue in some circumstances and there was a
reasonable discussion about this on the list that lead to it being
* Balbir Singh wrote:
> > At a _minimum_, SMT being enabled should disable this kind of crazy
> > pseudo-security entirely, since it is completely pointless in that
> > situation. Scheduling simply isn't a synchronization point with SMT
> > on, so saying "sure, I'll flush the L1 at context swit
On Mon, Jun 1, 2020 at 6:06 PM Balbir Singh wrote:
>
> I think apps can do this independently today as in do the flush
> via software fallback in the app themselves.
Sure, but they can't force the kernel to do crazy things for every task switch.
> But I see your concern with
> respect to an over
On Mon, Jun 1, 2020 at 10:01 AM Ingo Molnar wrote:
>
> - Provide an opt-in (prctl driven) mechanism to flush the L1D cache on
> context switch.
>The goal is to allow tasks that are paranoid due to the recent snoop
> assisted data
>sampling vulnerabilites, to flush their L1D on being swi
Linus,
Please pull the latest x86/mm git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-mm-2020-06-01
# HEAD: 0fcfdf55db9e1ecf85edd6aa8d0bc78a448cb96a Documentation: Add L1D
flushing Documentation
Misc changes:
- Unexport various PAT primitives
- Unexport pe
11 matches
Mail list logo
