On Sun, Jul 19, 2020 at 11:54 PM Joel Fernandes wrote:
>
> These ifdeffery and checkpatch / command line parameter issues were added by
> Vineeth before he sent out my patch. I'll let him comment on these, agreed
> they all need fixing!
>
Will fix this in the next iteration. Regarding the __setup
Joel,
Joel Fernandes writes:
> On Sat, Jul 18, 2020 at 01:36:16AM +0200, Thomas Gleixner wrote:
>>
>> The entry case condition wants to have a TIF bit as well, i.e.
>>
>> if (thread_test_bit(TIF_CORE_SCHED_REQUIRED) {
>> sched_ipi_dance() {
>> if
On Sat, Jul 18, 2020 at 01:36:16AM +0200, Thomas Gleixner wrote:
> Vineeth, Joel!
Hi Thomas,
> Vineeth Remanan Pillai writes:
> > From: "Joel Fernandes (Google)"
> >
> > Lastly, we also check in the schedule loop if we are about to schedule
> > an untrusted process while the core is in such a
On Sat, Jul 18, 2020 at 01:37:50AM +0200, Thomas Gleixner wrote:
> "Li, Aubrey" writes:
> > On 2020/7/1 5:32, Vineeth Remanan Pillai wrote:
> >
> > We saw a lot of soft lockups on the screen when we tested v6.
> >
> > [ 186.527883] watchdog: BUG: soft lockup - CPU#86 stuck for 22s!
> >
"Li, Aubrey" writes:
> On 2020/7/1 5:32, Vineeth Remanan Pillai wrote:
>
> We saw a lot of soft lockups on the screen when we tested v6.
>
> [ 186.527883] watchdog: BUG: soft lockup - CPU#86 stuck for 22s! [uperf:5551]
> [ 186.535884] watchdog: BUG: soft lockup - CPU#87 stuck for 22s!
Vineeth, Joel!
Vineeth Remanan Pillai writes:
> From: "Joel Fernandes (Google)"
>
> Lastly, we also check in the schedule loop if we are about to schedule
> an untrusted process while the core is in such a state. This is possible
> if a trusted thread enters the scheduler by way of yielding
On Fri, Jul 10, 2020 at 9:36 PM Vineeth Remanan Pillai
wrote:
>
> Hi Aubrey,
>
> On Fri, Jul 10, 2020 at 8:19 AM Li, Aubrey wrote:
> >
> > Hi Joel/Vineeth,
> > [...]
> > The problem is gone when we reverted this patch. We are running multiple
> > uperf threads(equal to cpu number) in a cgroup
Hi Aubrey,
On Fri, Jul 10, 2020 at 8:19 AM Li, Aubrey wrote:
>
> Hi Joel/Vineeth,
> [...]
> The problem is gone when we reverted this patch. We are running multiple
> uperf threads(equal to cpu number) in a cgroup with coresched enabled.
> This is 100% reproducible on our side.
>
> Just wonder
On Fri, Jul 10, 2020 at 08:19:24PM +0800, Li, Aubrey wrote:
> Hi Joel/Vineeth,
>
> On 2020/7/1 5:32, Vineeth Remanan Pillai wrote:
> > From: "Joel Fernandes (Google)"
> >
> > With current core scheduling patchset, non-threaded IRQ and softirq
> > victims can leak data from its hyperthread to a
Hi Joel/Vineeth,
On 2020/7/1 5:32, Vineeth Remanan Pillai wrote:
> From: "Joel Fernandes (Google)"
>
> With current core scheduling patchset, non-threaded IRQ and softirq
> victims can leak data from its hyperthread to a sibling hyperthread
> running an attacker.
>
> For MDS, it is possible
From: "Joel Fernandes (Google)"
With current core scheduling patchset, non-threaded IRQ and softirq
victims can leak data from its hyperthread to a sibling hyperthread
running an attacker.
For MDS, it is possible for the IRQ and softirq handlers to leak data to
either host or guest attackers.
11 matches
Mail list logo
