On Fri, 2019-05-17 at 14:01 -0700, Rick Edgecomb e wrote:
> Meelis Roos reported issues with the new VM_FLUSH_RESET_PERMS flag on
> the
> sparc architecture.
>
Argh, this patch is not correct in the flush range for non-x86. I'll
send a revision.
Hi,
After investigating this more, I am not positive why this fixes the
issue on sparc. I will continue to investigate as best I can, but would
like to request help from some sparc experts on evaluating my line of
thinking. I think the changes in this patch are still very worthwhile
generally thou
On Mon, 2019-05-13 at 10:01 -0700, Rick Edgecombe wrote:
> On Mon, 2019-05-13 at 17:01 +0300, Meelis Roos wrote:
> > I tested yesterdays 5.2 devel git and it failed to boot on my Sun Fire V445
> > (4x UltraSparc III). Init is started and it hangs there:
> >
> > [ 38.414436] Run /sbin/init as ini
On Mon, 2019-05-13 at 17:01 +0300, Meelis Roos wrote:
> I tested yesterdays 5.2 devel git and it failed to boot on my Sun Fire V445
> (4x UltraSparc III). Init is started and it hangs there:
>
> [ 38.414436] Run /sbin/init as init process
> [ 38.530711] random: fast init done
> [ 39.580678]
On Wed, 2019-02-06 at 00:35 +, Alexei Starovoitov wrote:
> On 2/5/19 2:50 PM, Rick Edgecombe wrote:
> > This introduces a new capability for BPF program JIT's to be located in
> > vmalloc
> > space on x86_64. This can serve as a backup area for
> > CONFIG_BPF_JIT_ALWAYS_ON in
> > case an unpriv
On Mon, 2018-12-17 at 05:41 +0100, Jessica Yu wrote:
> +++ Edgecombe, Rick P [12/12/18 23:05 +]:
> > On Wed, 2018-11-28 at 01:40 +, Edgecombe, Rick P wrote:
> > > On Tue, 2018-11-27 at 11:21 +0100, Daniel Borkmann wrote:
> > > > On 11/27/2018 01:19 AM, Edgecom
On Sat, 2018-12-15 at 10:52 -0800, Andy Lutomirski wrote:
> On Wed, Dec 12, 2018 at 2:01 PM Edgecombe, Rick P
> wrote:
> >
> > On Wed, 2018-12-12 at 11:57 -0800, Andy Lutomirski wrote:
> > > On Wed, Dec 12, 2018 at 11:50 AM Edgecombe, Rick P
> > > wrote:
&g
On Thu, 2018-12-13 at 19:27 +, Nadav Amit wrote:
> > On Dec 13, 2018, at 11:02 AM, Edgecombe, Rick P
> > wrote:
> >
> > On Wed, 2018-12-12 at 23:40 +, Nadav Amit wrote:
> > > > On Dec 11, 2018, at 4:03 PM, Rick Edgecombe
> > > > wrote:
>
On Wed, 2018-12-12 at 23:40 +, Nadav Amit wrote:
> > On Dec 11, 2018, at 4:03 PM, Rick Edgecombe
> > wrote:
> >
> > Add new flags for handling freeing of special permissioned memory in
> > vmalloc,
> > and remove places where the handling was done in module.c.
> >
> > This will enable this f
On Wed, 2018-11-28 at 01:40 +, Edgecombe, Rick P wrote:
> On Tue, 2018-11-27 at 11:21 +0100, Daniel Borkmann wrote:
> > On 11/27/2018 01:19 AM, Edgecombe, Rick P wrote:
> > > On Mon, 2018-11-26 at 16:36 +0100, Jessica Yu wrote:
> > > > +++ Rick E
On Wed, 2018-12-12 at 11:57 -0800, Andy Lutomirski wrote:
> On Wed, Dec 12, 2018 at 11:50 AM Edgecombe, Rick P
> wrote:
> >
> > On Tue, 2018-12-11 at 18:20 -0800, Andy Lutomirski wrote:
> > > On Tue, Dec 11, 2018 at 4:12 PM Rick Edgecombe
> > > wrote:
>
On Wed, 2018-12-12 at 06:30 +, Nadav Amit wrote:
> > On Dec 11, 2018, at 4:03 PM, Rick Edgecombe
> > wrote:
> >
> > This adds a more efficient x86 architecture specific implementation of
> > arch_vunmap, that can free any type of special permission memory with only 1
> > TLB
> > flush.
> >
>
On Tue, 2018-12-11 at 18:24 -0800, Andy Lutomirski wrote:
> On Tue, Dec 11, 2018 at 4:12 PM Rick Edgecombe
> wrote:
> >
> > This adds a more efficient x86 architecture specific implementation of
> > arch_vunmap, that can free any type of special permission memory with only 1
> > TLB
> > flush.
>
On Tue, 2018-12-11 at 18:20 -0800, Andy Lutomirski wrote:
> On Tue, Dec 11, 2018 at 4:12 PM Rick Edgecombe
> wrote:
> >
> > This adds two new flags VM_IMMEDIATE_UNMAP and VM_HAS_SPECIAL_PERMS, for
> > enabling vfree operations to immediately clear executable TLB entries to
> > freed
> > pages, an
On Thu, 2018-12-06 at 15:08 -0800, Nadav Amit wrote:
> > On Dec 6, 2018, at 12:17 PM, Andy Lutomirski wrote:
> >
> > On Thu, Dec 6, 2018 at 11:39 AM Nadav Amit wrote:
> > > > On Dec 6, 2018, at 11:19 AM, Andy Lutomirski wrote:
> > > >
> > > > On Thu, Dec 6, 2018 at 11:01 AM Tycho Andersen wro
On Thu, 2018-12-06 at 11:19 -0800, Andy Lutomirski wrote:
> On Thu, Dec 6, 2018 at 11:01 AM Tycho Andersen wrote:
> >
> > On Thu, Dec 06, 2018 at 10:53:50AM -0800, Andy Lutomirski wrote:
> > > > If we are going to unmap the linear alias, why not do it at vmalloc()
> > > > time rather than vfree()
On Tue, 2018-12-04 at 16:53 -0800, Nadav Amit wrote:
> > On Dec 4, 2018, at 4:29 PM, Edgecombe, Rick P
> > wrote:
> >
> > On Tue, 2018-12-04 at 16:01 -0800, Nadav Amit wrote:
> > > > On Dec 4, 2018, at 3:51 PM, Edgecombe, Rick P <
> >
On Tue, 2018-12-04 at 14:48 -0800, Nadav Amit wrote:
> > On Dec 4, 2018, at 11:48 AM, Andy Lutomirski wrote:
> >
> > On Tue, Dec 4, 2018 at 11:45 AM Nadav Amit wrote:
> > > > On Dec 4, 2018, at 10:56 AM, Andy Lutomirski wrote:
> > > >
> > > > On Mon, Dec 3, 2018 at 5:43 PM Nadav Amit wrote:
>
On Tue, 2018-12-04 at 16:01 -0800, Nadav Amit wrote:
> > On Dec 4, 2018, at 3:51 PM, Edgecombe, Rick P
> > wrote:
> >
> > On Tue, 2018-12-04 at 12:36 -0800, Nadav Amit wrote:
> > > > On Dec 4, 2018, at 12:02 PM, Edgecombe, Rick P <
> >
On Tue, 2018-12-04 at 12:09 -0800, Andy Lutomirski wrote:
> On Tue, Dec 4, 2018 at 12:02 PM Edgecombe, Rick P
> wrote:
> >
> > On Tue, 2018-12-04 at 16:03 +, Will Deacon wrote:
> > > On Mon, Dec 03, 2018 at 05:43:11PM -0800, Nadav Amit wrote:
> > > &
On Tue, 2018-12-04 at 16:03 +, Will Deacon wrote:
> On Mon, Dec 03, 2018 at 05:43:11PM -0800, Nadav Amit wrote:
> > > On Nov 27, 2018, at 4:07 PM, Rick Edgecombe
> > > wrote:
> > >
> > > Since vfree will lazily flush the TLB, but not lazily free the underlying
> > > pages,
> > > it often leav
It looks like this new flag is in linux-next now. As I am reading it, these
architectures have a module_alloc that uses some sort of executable flag and
are not using the default module_alloc which is already covered, and so may need
it plugged in:
arm
arm64
parisc
s390
unicore32
Thanks,
Rick
On
On Thu, 2018-11-29 at 23:06 +0900, Masami Hiramatsu wrote:
> On Tue, 27 Nov 2018 16:07:52 -0800
> Rick Edgecombe wrote:
>
> > Sometimes when memory is freed via the module subsystem, an executable
> > permissioned TLB entry can remain to a freed page. If the page is re-used to
> > back an address
On Wed, 2018-11-28 at 17:40 -0800, Andy Lutomirski wrote:
> > On Nov 27, 2018, at 4:07 PM, Rick Edgecombe <
> > rick.p.edgeco...@intel.com> wrote:
> >
> > Change the module allocations to flush before freeing the pages.
> >
> > Signed-off-by: Rick Edgecombe
> > ---
> > arch/x86/kernel/module.c |
On Wed, 2018-11-28 at 15:11 -0800, Andrew Morton wrote:
> On Tue, 27 Nov 2018 16:07:54 -0800 Rick Edgecombe
> wrote:
>
> > Change the module allocations to flush before freeing the pages.
> >
> > ...
> >
> > --- a/arch/x86/kernel/module.c
> > +++ b/arch/x86/kernel/module.c
> > @@ -87,8 +87,8 @@
On Tue, 2018-11-27 at 11:21 +0100, Daniel Borkmann wrote:
> On 11/27/2018 01:19 AM, Edgecombe, Rick P wrote:
> > On Mon, 2018-11-26 at 16:36 +0100, Jessica Yu wrote:
> > > +++ Rick Edgecombe [20/11/18 15:23 -0800]:
> >
> > [snip]
> > > Hi Rick!
> > >
On Fri, 2018-11-23 at 23:18 +0100, Ard Biesheuvel wrote:
> By default, BPF uses module_alloc() to allocate executable memory,
> but this is not necessary on all arches and potentially undesirable
> on some of them.
>
> So break out the module_alloc() and module_memfree() calls into __weak
> functi
27 matches
Mail list logo
