On Wed, 2019-05-22 at 15:40 -0700, Rick Edgecombe wrote:
> On Wed, 2019-05-22 at 12:26 -0700, Rick Edgecombe wrote:
> > On Wed, 2019-05-22 at 10:40 -0700, David Miller wrote:
> > > From: "Edgecombe, Rick P"
> > > Date: Tue, 21 May 2019 01:59:54 +
> > >
> > > > On Mon, 2019-05-20 at 18:43 -070
On Wed, 2019-05-22 at 12:26 -0700, Rick Edgecombe wrote:
> On Wed, 2019-05-22 at 10:40 -0700, David Miller wrote:
> > From: "Edgecombe, Rick P"
> > Date: Tue, 21 May 2019 01:59:54 +
> >
> > > On Mon, 2019-05-20 at 18:43 -0700, David Miller wrote:
> > > > From: "Edgecombe, Rick P"
> > > > Dat
On Wed, 2019-05-22 at 10:40 -0700, David Miller wrote:
> From: "Edgecombe, Rick P"
> Date: Tue, 21 May 2019 01:59:54 +
>
> > On Mon, 2019-05-20 at 18:43 -0700, David Miller wrote:
> > > From: "Edgecombe, Rick P"
> > > Date: Tue, 21 May 2019 01:20:33 +
> > >
> > > > Should it handle exec
From: "Edgecombe, Rick P"
Date: Tue, 21 May 2019 01:59:54 +
> On Mon, 2019-05-20 at 18:43 -0700, David Miller wrote:
>> From: "Edgecombe, Rick P"
>> Date: Tue, 21 May 2019 01:20:33 +
>>
>> > Should it handle executing an unmapped page gracefully? Because
>> > this
>> > change is causing
On Mon, 2019-05-20 at 18:43 -0700, David Miller wrote:
> From: "Edgecombe, Rick P"
> Date: Tue, 21 May 2019 01:20:33 +
>
> > Should it handle executing an unmapped page gracefully? Because
> > this
> > change is causing that to happen much earlier. If something was
> > relying
> > on a cached
From: "Edgecombe, Rick P"
Date: Tue, 21 May 2019 01:20:33 +
> Should it handle executing an unmapped page gracefully? Because this
> change is causing that to happen much earlier. If something was relying
> on a cached translation to execute something it could find the mapping
> disappear.
D
On Mon, 2019-05-20 at 20:33 -0400, David Miller wrote:
> From: "Edgecombe, Rick P"
> Date: Tue, 21 May 2019 00:20:13 +
>
> > This behavior shouldn't happen until modules or BPF are being
> > freed.
>
> Then that would rule out my theory.
>
> The only thing left is whether the permissions ar
From: "Edgecombe, Rick P"
Date: Tue, 21 May 2019 00:20:13 +
> This behavior shouldn't happen until modules or BPF are being freed.
Then that would rule out my theory.
The only thing left is whether the permissions are actually set
properly. If they aren't we'll take an exception when the B
On Mon, 2019-05-20 at 15:48 -0700, David Miller wrote:
> From: "Edgecombe, Rick P"
> Date: Mon, 20 May 2019 22:17:49 +
>
> > Thanks for testing. So I guess that suggests it's the TLB flush
> > causing
> > the problem on sparc and not any lazy purge deadlock. I had sent
> > Meelis
> > another
From: "Edgecombe, Rick P"
Date: Mon, 20 May 2019 22:17:49 +
> Thanks for testing. So I guess that suggests it's the TLB flush causing
> the problem on sparc and not any lazy purge deadlock. I had sent Meelis
> another test patch that just flushed the entire 0 to ULONG_MAX range to
> try to al
On Tue, 2019-05-21 at 00:36 +0300, Meelis Roos wrote:
> > Switch VM_FLUSH_RESET_PERMS to use a regular TLB flush intead of
> > vm_unmap_aliases() and fix calculation of the direct map for the
> > CONFIG_ARCH_HAS_SET_DIRECT_MAP case.
> >
> > Meelis Roos reported issues with the new VM_FLUSH_RESET_P
On Mon, 2019-05-20 at 14:25 -0700, Andy Lutomirski wrote:
>
>
> > On May 20, 2019, at 1:07 PM, Rick Edgecombe <
> > rick.p.edgeco...@intel.com> wrote:
> >
> > Switch VM_FLUSH_RESET_PERMS to use a regular TLB flush intead of
> > vm_unmap_aliases() and fix calculation of the direct map for the
> >
Switch VM_FLUSH_RESET_PERMS to use a regular TLB flush intead of
vm_unmap_aliases() and fix calculation of the direct map for the
CONFIG_ARCH_HAS_SET_DIRECT_MAP case.
Meelis Roos reported issues with the new VM_FLUSH_RESET_PERMS flag on a
sparc machine. On investigation some issues were noticed:
> On May 20, 2019, at 1:07 PM, Rick Edgecombe
> wrote:
>
> Switch VM_FLUSH_RESET_PERMS to use a regular TLB flush intead of
> vm_unmap_aliases() and fix calculation of the direct map for the
> CONFIG_ARCH_HAS_SET_DIRECT_MAP case.
>
> Meelis Roos reported issues with the new VM_FLUSH_RESET_P
Switch VM_FLUSH_RESET_PERMS to use a regular TLB flush intead of
vm_unmap_aliases() and fix calculation of the direct map for the
CONFIG_ARCH_HAS_SET_DIRECT_MAP case.
Meelis Roos reported issues with the new VM_FLUSH_RESET_PERMS flag on a
sparc machine. On investigation some issues were noticed:
15 matches
Mail list logo