t task's one. Accordingly, add a new argument to
the function so that one can define explicitly which memory map should be
used.
Signed-off-by: Till Smejkal
---
include/linux/mm.h | 4
mm/mmap.c | 14 +-
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git
eed to be usable
for other memory maps than just the one of the current process. Hence,
explicitly define during the function call which memory map to use.
Signed-off-by: Till Smejkal
---
arch/x86/mm/mpx.c | 4 ++--
fs/aio.c | 4 ++--
include/linux/mm.h | 11 ++-
ipc/shm.c
both
functions also need to be able to operate on other memory maps than just
the one of the current task. Accordingly, it is now possible to specify
explicitly which memory map these functions should use via an additional
argument.
Signed-off-by: Till Smejkal
---
arch/x86/mm/mpx.c | 2 +-
inc
her memory
maps than only the current task ones. By adding it as argument we can now
explicitly define which memory map to use.
Signed-off-by: Till Smejkal
---
arch/mips/kernel/vdso.c | 2 +-
arch/tile/mm/elf.c | 2 +-
include/linux/mm.h | 5 +++--
mm/mmap.c | 10 +
This code was developed during an internship at Hewlett Packard Enterprise.
[1] http://impact.crhc.illinois.edu/shared/Papers/ASPLOS16-SpaceJMP.pdf
Till Smejkal (13):
mm: Add mm_struct argument to 'mmap_region'
mm: Add mm_struct argument to 'do_mmap' and 'do_mmap_pg
eded by the first class
virtual address space feature. Both functions, 'mm_setup' and 'mm_set_task'
are also exported, so that they can be used in all files in the source
tree.
Signed-off-by: Till Smejkal
---
arch/arm/mach-rpc/ecard.c | 2 +-
hey are replaced with the new ones.
Signed-off-by: Till Smejkal
---
include/linux/huge_mm.h | 6 +
include/linux/hugetlb.h | 5 +
include/linux/mm.h | 2 +
mm/huge_memory.c| 65 +++
mm/hugetlb.c| 205 +++--
mm/memory.c | 461 +++
x27;vm_unmapped_area' function with its dependents have to take the memory
map that they should work on as additional argument. Simply using the one
of the current task, as these functions did before, is not correct anymore
and leads to incorrect results.
Signed-off-by: Till S
Make the functions 'vma_link' and 'find_vma_links' accessible to other
source files in the mm/ source directory of the kernel so that other files
in that directory can also perform low level changes to mm_struct data
structures.
Signed-off-by: Till Smejkal
---
mm/internal.h
Hi Greg,
First of all thanks for your reply.
On Tue, 14 Mar 2017, Greg Kroah-Hartman wrote:
> On Mon, Mar 13, 2017 at 03:14:12PM -0700, Till Smejkal wrote:
>
> There's no way with that many cc: lists and people that this is really
> making it through very many people's fil
m instead of
again deciding which mm_struct to use.
Signed-off-by: Till Smejkal
---
kernel/fork.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/kernel/fork.c b/kernel/fork.c
index 9209f6d5d7c0..d3087d870855 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1158,
Hi Matthew,
On Mon, 13 Mar 2017, Matthew Wilcox wrote:
> On Mon, Mar 13, 2017 at 03:14:13PM -0700, Till Smejkal wrote:
> > +/**
> > + * Create a new VAS segment.
> > + *
> > + * @param[in] name:The name of the new VAS segment.
> > + * @param[in]
destroy or create a virtual segment. Via attaching a VAS segment to a first
class virtual address space, the memory that is contained in the VAS
segment can be accessed and changed.
Signed-off-by: Till Smejkal
Signed-off-by: Marco Benatto
---
arch/x86/entry/syscalls/syscall_32.tbl |7
On Tue, 14 Mar 2017, Richard Henderson wrote:
> On 03/14/2017 08:14 AM, Till Smejkal wrote:
> > At the current state of the development, first class virtual address spaces
> > have one limitation, that we haven't been able to solve so far. The feature
> > allows, that dif
On Tue, 14 Mar 2017, Richard Henderson wrote:
> On 03/14/2017 10:39 AM, Till Smejkal wrote:
> > > Is this an indication that full virtual address spaces are useless? It
> > > would seem like if you only use virtual address segments then you avoid
> > > all
> &
folder of the underlying
VAS.
Signed-off-by: Till Smejkal
---
fs/proc/base.c | 528 +
fs/proc/inode.c| 1 +
fs/proc/internal.h | 1 +
mm/Kconfig | 9 +
4 files changed, 539 insertions(+)
diff --git a/fs/proc/base.c b/fs/p
ses at the same time if the underlying memory is only
readable. This mechanism allows sharing of whole address spaces between
multiple processes that can both execute in them using the contained
memory.
Signed-off-by: Till Smejkal
Signed-off-by: Marco Benatto
---
M
inside the
first class virtual address space. The only memory region which is always
duplicated during the attach-operation is the code memory section, because
this memory region is always necessary for execution and saves us one page
fault later during the process execution.
Signed-off-by: Till
Hi Vineet,
On Mon, 13 Mar 2017, Vineet Gupta wrote:
> I've not looked at the patches closely (or read the references paper fully
> yet),
> but at first glance it seems on ARC architecture, we can can potentially
> use/leverage this mechanism to implement the shared TLB entries. Before anyone
> sh
On Mon, 13 Mar 2017, Andy Lutomirski wrote:
> On Mon, Mar 13, 2017 at 3:14 PM, Till Smejkal
> wrote:
> > This patchset extends the kernel memory management subsystem with a new
> > type of address spaces (called VAS) which can be created and destroyed
> > independently o
On Tue, 14 Mar 2017, David Laight wrote:
> From: Linuxppc-dev Till Smejkal
> > Sent: 13 March 2017 22:14
> > The only way until now to create a new memory map was via the exported
> > function 'mm_alloc'. Unfortunately, this function not only allocates a new
>
On Tue, 14 Mar 2017, Chris Metcalf wrote:
> On 3/14/2017 12:12 PM, Till Smejkal wrote:
> > On Mon, 13 Mar 2017, Andy Lutomirski wrote:
> > > On Mon, Mar 13, 2017 at 7:07 PM, Till Smejkal
> > > wrote:
> > > > On Mon, 13 Mar 2017, Andy Lutomirski wrote:
&
On Mon, 13 Mar 2017, Andy Lutomirski wrote:
> On Mon, Mar 13, 2017 at 7:07 PM, Till Smejkal
> wrote:
> > On Mon, 13 Mar 2017, Andy Lutomirski wrote:
> >> This sounds rather complicated. Getting TLB flushing right seems
> >> tricky. Why not just map the same thing i
On Wed, 15 Mar 2017, Rich Felker wrote:
> On Wed, Mar 15, 2017 at 12:44:47PM -0700, Till Smejkal wrote:
> > On Wed, 15 Mar 2017, Andy Lutomirski wrote:
> > > > One advantage of VAS segments is that they can be globally queried by
> > > > user programs
> > &
On Wed, 15 Mar 2017, Andy Lutomirski wrote:
> > One advantage of VAS segments is that they can be globally queried by user
> > programs
> > which means that VAS segments can be shared by applications that not
> > necessarily have
> > to be related. If I am not mistaken, MAP_SHARED of pure in memo
On Wed, 15 Mar 2017, Andy Lutomirski wrote:
> On Wed, Mar 15, 2017 at 12:44 PM, Till Smejkal
> wrote:
> > On Wed, 15 Mar 2017, Andy Lutomirski wrote:
> >> > One advantage of VAS segments is that they can be globally queried by
> >> > user programs
> &g
On Wed, 15 Mar 2017, Luck, Tony wrote:
> On Wed, Mar 15, 2017 at 03:02:34PM -0700, Till Smejkal wrote:
> > I don't agree here. VAS segments are basically in-memory files that are
> > handled by
> > the kernel directly without using a file system. Hence, if an a
On Thu, 16 Mar 2017, Thomas Gleixner wrote:
> Why do we need yet another mechanism to represent something which looks
> like a file instead of simply using existing mechanisms and extend them?
You are right. I also recognized during the discussion with Andy, Chris,
Matthew,
Luck, Rich and the oth
On Thu, 16 Mar 2017, Thomas Gleixner wrote:
> On Thu, 16 Mar 2017, Till Smejkal wrote:
> > On Thu, 16 Mar 2017, Thomas Gleixner wrote:
> > > Why do we need yet another mechanism to represent something which looks
> > > like a file instead of simply using existing
29 matches
Mail list logo
