On Mon, Dec 14, 2015 at 11:12:38AM +0300, Konstantin Khlebnikov wrote:
> Here several rated changes bundled together:
> * keep vma counting if CONFIG_PROC_FS=n, will be used for limits
> * replace mm->shared_vm with better defined mm->data_vm
> * account anonymous executable areas as executable
>
On Mon, Dec 14, 2015 at 04:32:34PM +0100, Quentin Casasnovas wrote:
> >
> > growsup/down stand for stack usage iirc, so it was intentionally
> > not accounted here.
> >
>
> Right, but in the same vein of Linus saying RLIMIT_DATA is/was useless
> because everyone could use mmap() instead of brk()
On Mon, Dec 14, 2015 at 03:51:26PM +0100, Quentin Casasnovas wrote:
...
>
> Do we want to fold may_expand_anon_vm() into may_expand_vm() (potentially
> passing it the flags/struct file if needed) so there is just one such
> helper function? Rationale being that it then gets hard to see what
>
: Vladimir Davydov
CC: Konstantin Khlebnikov
CC: Pavel Emelyanov
CC: Vladimir Davydov
CC: Peter Zijlstra
Signed-off-by: Cyrill Gorcunov
---
Documentation/filesystems/proc.txt |1
fs/proc/task_mmu.c |2 +
include/linux/mm_types.h |1
mm/mmap.c
Take a look please, once time permit. Hopefully I didnt
miss something obvious (it's been spinning on my VM
for sometime without problem but if there some more
tests which can be runned please point me).
The second version is slightly different because
I added rlimit-data tests for do_brk and
Signed-off-by: Cyrill Gorcunov
---
tools/testing/selftests/vm/Makefile |1
tools/testing/selftests/vm/rlimit-data.c | 201 +++
tools/testing/selftests/vm/run_vmtests |4
3 files changed, 204 insertions(+), 2 deletions(-)
Index: linux-ml.git/tools
lt;xe...@virtuozzo.com>
CC: Vladimir Davydov <vdavy...@virtuozzo.com>
CC: Peter Zijlstra <a.p.zijls...@chello.nl>
Signed-off-by: Cyrill Gorcunov <gorcu...@openvz.org>
---
Documentation/filesystems/proc.txt |1
fs/proc/task_mmu.c |2 +
include/linux
Take a look please, once time permit. Hopefully I didnt
miss something obvious (it's been spinning on my VM
for sometime without problem but if there some more
tests which can be runned please point me).
The second version is slightly different because
I added rlimit-data tests for do_brk and
<l...@amacapital.net>
CC: Kees Cook <keesc...@google.com>
CC: Vladimir Davydov <vdavy...@virtuozzo.com>
CC: Konstantin Khlebnikov <koc...@gmail.com>
CC: Pavel Emelyanov <xe...@virtuozzo.com>
CC: Vladimir Davydov <vdavy...@virtuozzo.com>
CC: Peter Zijlstra &l
On Fri, Dec 11, 2015 at 12:55:51PM -0800, Linus Torvalds wrote:
> >
> > +static inline int anon_accountable_mapping(struct file *file, vm_flags_t
> > vm_flags)
> > +{
> > + return !file &&
> > + (vm_flags & (VM_GROWSDOWN | VM_GROWSUP |
> > +
Zijlstra
Signed-off-by: Cyrill Gorcunov
---
fs/proc/task_mmu.c |2 ++
include/linux/mm_types.h |1 +
mm/mmap.c| 22 ++
3 files changed, 25 insertions(+)
Index: linux-ml.git/fs/proc/task_mmu.c
;
CC: Andy Lutomirski <l...@amacapital.net>
CC: Kees Cook <keesc...@google.com>
CC: Vladimir Davydov <vdavy...@virtuozzo.com>
CC: Konstantin Khlebnikov <koc...@gmail.com>
CC: Pavel Emelyanov <xe...@virtuozzo.com>
CC: Vladimir Davydov <vdavy...@virtuozzo.com>
CC: Peter Zijlstra &l
On Fri, Dec 11, 2015 at 12:55:51PM -0800, Linus Torvalds wrote:
> >
> > +static inline int anon_accountable_mapping(struct file *file, vm_flags_t
> > vm_flags)
> > +{
> > + return !file &&
> > + (vm_flags & (VM_GROWSDOWN | VM_GROWSUP |
> > +
On Wed, Oct 14, 2015 at 07:57:02PM +0300, Stas Sergeev wrote:
...
> > correct? This should work for us. Stas, mind to refresh my memory,
> > which ss value doesmu setups here?
>
> Nothing.
> Older dosemus didn't care about touching __pad0, so
> whatever kernel saves there, is still there, even
On Wed, Oct 14, 2015 at 09:42:58AM -0700, Andy Lutomirski wrote:
>
> That's the intent.
>
> If you write __pad = 0, don't set UC_STRICT_RESTORE_SS, and leave cs
> set to a 64-bit value, then the kernel will detect that 0 is not a
> valid SS and will fix it for you.
>
> If you do write
es, __pad0 is left as an alias for ss in
> ucontext.
>
> The nitty-gritty details are documented in the header file.
>
> Cc: Stas Sergeev
> Cc: Linus Torvalds
> Cc: Cyrill Gorcunov
> Cc: Pavel Emelyanov
> Signed-off-by: Andy Lutomirski
Andy, so for old criu version
On Wed, Oct 14, 2015 at 09:42:58AM -0700, Andy Lutomirski wrote:
>
> That's the intent.
>
> If you write __pad = 0, don't set UC_STRICT_RESTORE_SS, and leave cs
> set to a 64-bit value, then the kernel will detect that 0 is not a
> valid SS and will fix it for you.
>
> If you do write
es, __pad0 is left as an alias for ss in
> ucontext.
>
> The nitty-gritty details are documented in the header file.
>
> Cc: Stas Sergeev <s...@list.ru>
> Cc: Linus Torvalds <torva...@linux-foundation.org>
> Cc: Cyrill Gorcunov <gorcu...@gmail.com>
> Cc:
On Wed, Oct 14, 2015 at 07:57:02PM +0300, Stas Sergeev wrote:
...
> > correct? This should work for us. Stas, mind to refresh my memory,
> > which ss value doesmu setups here?
>
> Nothing.
> Older dosemus didn't care about touching __pad0, so
> whatever kernel saves there, is still there, even
ependent of the CRIU problem.
>
> Signed-off-by: Dave Hansen
> Reported-by: Andrey Wagin
Acked-by: Cyrill Gorcunov
Thank you!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ce, so this is a good
> patch independent of the CRIU problem.
>
> Signed-off-by: Dave Hansen <dave.han...@linux.intel.com>
> Reported-by: Andrey Wagin <ava...@gmail.com>
Acked-by: Cyrill Gorcunov <gorcu...@openvz.org>
Thank you!
--
To unsubscribe from this list: send t
On Fri, Aug 14, 2015 at 01:02:14PM +0300, Pavel Emelyanov wrote:
...
> > IOW we've been not setting up __pad0 which became ss
> > inside the kernel (in result we've been passing 0 here,
> > which caused the problem).
> >
> > fwiw, we declare that new criu versions may require new
> > kernels to
On Thu, Aug 13, 2015 at 08:43:24AM -0700, Andy Lutomirski wrote:
...
> >
> > That rule hasn't gone anywhere.
> >
> > Does a plain revert just fix everything? Because if so, that's the
> > right thing to do, and we can just re-visit this later.
> >
> > I don't understand why Andy and Ingo are even
On Thu, Aug 13, 2015 at 01:09:47PM -0700, Linus Torvalds wrote:
> On Thu, Aug 13, 2015 at 1:08 PM, Cyrill Gorcunov wrote:
> >
> > If only I'm not missin something obvious this should not hurt us.
> > But I gonna build test kernel and check to be sure tomorrow, ok?
Managed
On Thu, Aug 13, 2015 at 01:09:47PM -0700, Linus Torvalds wrote:
On Thu, Aug 13, 2015 at 1:08 PM, Cyrill Gorcunov gorcu...@gmail.com wrote:
If only I'm not missin something obvious this should not hurt us.
But I gonna build test kernel and check to be sure tomorrow, ok?
Managed to test
On Thu, Aug 13, 2015 at 08:43:24AM -0700, Andy Lutomirski wrote:
...
That rule hasn't gone anywhere.
Does a plain revert just fix everything? Because if so, that's the
right thing to do, and we can just re-visit this later.
I don't understand why Andy and Ingo are even discussing
On Fri, Aug 14, 2015 at 01:02:14PM +0300, Pavel Emelyanov wrote:
...
IOW we've been not setting up __pad0 which became ss
inside the kernel (in result we've been passing 0 here,
which caused the problem).
fwiw, we declare that new criu versions may require new
kernels to work but
On Thu, Aug 13, 2015 at 12:53:03PM -0700, Linus Torvalds wrote:
> On Thu, Aug 13, 2015 at 11:41 AM, Andy Lutomirski wrote:
> > On Thu, Aug 13, 2015 at 11:35 AM, Linus Torvalds
> > wrote:
> >>
> >> Ok. So I'm inclined to do the bigger revert, just to fix the compile
> >> issue. It would be crazy
On Thu, Aug 13, 2015 at 12:53:03PM -0700, Linus Torvalds wrote:
On Thu, Aug 13, 2015 at 11:41 AM, Andy Lutomirski l...@amacapital.net wrote:
On Thu, Aug 13, 2015 at 11:35 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
Ok. So I'm inclined to do the bigger revert, just to fix the
that a lot of scripts and tools
> > could benefit from (starting with pstree I suppose.)
>
> I don't think I have enough information to answer that question. I'll CC
> Cyrill
> Gorcunov and Andrew Morton.
The interface is not expensive per-se but it was developed for
checkpoint/restor
could benefit from (starting with pstree I suppose.)
I don't think I have enough information to answer that question. I'll CC
Cyrill
Gorcunov and Andrew Morton.
The interface is not expensive per-se but it was developed for
checkpoint/restore in first place so we've been wrapping any
new code
On Wed, Jun 10, 2015 at 05:00:35PM +0900, Minchan Kim wrote:
> >
> > Ah, I recall. If there is no way to escape dirtifying the page in pte itself
> > maybe we should at least not make it softdirty on read faults?
>
> You mean this?
>
> diff --git a/mm/memory.c b/mm/memory.c
> index
On Wed, Jun 10, 2015 at 08:52:06AM +0900, Minchan Kim wrote:
> > > +++ b/mm/memory.c
> > > @@ -2557,9 +2557,11 @@ static int do_swap_page(struct mm_struct *mm,
> > > struct vm_area_struct *vma,
> > >
> > > inc_mm_counter_fast(mm, MM_ANONPAGES);
> > > dec_mm_counter_fast(mm, MM_SWAPENTS);
>
On Wed, Jun 10, 2015 at 05:00:35PM +0900, Minchan Kim wrote:
Ah, I recall. If there is no way to escape dirtifying the page in pte itself
maybe we should at least not make it softdirty on read faults?
You mean this?
diff --git a/mm/memory.c b/mm/memory.c
index e1c45d0..c95340d
On Wed, Jun 10, 2015 at 08:52:06AM +0900, Minchan Kim wrote:
+++ b/mm/memory.c
@@ -2557,9 +2557,11 @@ static int do_swap_page(struct mm_struct *mm,
struct vm_area_struct *vma,
inc_mm_counter_fast(mm, MM_ANONPAGES);
dec_mm_counter_fast(mm, MM_SWAPENTS);
- pte =
y
> under us.
>
> With MADV_FREE point of view, marking dirty unconditionally is
> no problem because we dropped swapped page in MADV_FREE sycall
> context(ie, Look at madvise_free_pte_range) so every swapping-in
> pages are no MADV_FREE hinted pages.
>
> Cc: Hugh Dickins
On Tue, Jun 09, 2015 at 10:47:31AM -0700, Andy Lutomirski wrote:
...
> >
> > Cool, I think this looks good. Thanks!
> >
> > Reviewed-by: Kees Cook
> >
>
> Looks good to me, too.
Wow! Great job, Calvin, thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Tue, Jun 09, 2015 at 10:47:31AM -0700, Andy Lutomirski wrote:
...
Cool, I think this looks good. Thanks!
Reviewed-by: Kees Cook keesc...@chromium.org
Looks good to me, too.
Wow! Great job, Calvin, thanks!
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
, marking dirty unconditionally is
no problem because we dropped swapped page in MADV_FREE sycall
context(ie, Look at madvise_free_pte_range) so every swapping-in
pages are no MADV_FREE hinted pages.
Cc: Hugh Dickins hu...@google.com
Cc: Cyrill Gorcunov gorcu...@gmail.com
Cc: Pavel Emelyanov
On Thu, May 28, 2015 at 02:35:07PM +0300, Cyrill Gorcunov wrote:
> On Thu, May 28, 2015 at 02:14:41PM +0300, Alexey Dobriyan wrote:
> > >>
> > >> It is snapshot w.r.t getting both pairs not snapshot w.r.t atomicity or
> > >> something (unsigned long acces
On Thu, May 28, 2015 at 02:14:41PM +0300, Alexey Dobriyan wrote:
> >>
> >> It is snapshot w.r.t getting both pairs not snapshot w.r.t atomicity or
> >> something (unsigned long access is atomic after all). Once down_write()
> >> is used in the other place, it even becomes obviously correct code!
>
On Thu, May 28, 2015 at 02:12:07AM +0300, Alexey Dobriyan wrote:
> > > >
> > > > Could you please explain why this down/up is needed?
> > >
> > > Code is written this way to get constistent snapshot of data.
> >
> > it does not. you fetch data into local variables which is the
> > same as
On Thu, May 28, 2015 at 02:12:07AM +0300, Alexey Dobriyan wrote:
Could you please explain why this down/up is needed?
Code is written this way to get constistent snapshot of data.
it does not. you fetch data into local variables which is the
same as simply read them
On Thu, May 28, 2015 at 02:14:41PM +0300, Alexey Dobriyan wrote:
It is snapshot w.r.t getting both pairs not snapshot w.r.t atomicity or
something (unsigned long access is atomic after all). Once down_write()
is used in the other place, it even becomes obviously correct code!
Not at
On Thu, May 28, 2015 at 02:35:07PM +0300, Cyrill Gorcunov wrote:
On Thu, May 28, 2015 at 02:14:41PM +0300, Alexey Dobriyan wrote:
It is snapshot w.r.t getting both pairs not snapshot w.r.t atomicity or
something (unsigned long access is atomic after all). Once down_write()
is used
On Thu, May 28, 2015 at 01:29:42AM +0300, Alexey Dobriyan wrote:
> > > +
> > > + page = (char *)__get_free_page(GFP_TEMPORARY);
> > > + if (!page) {
> > > + rv = -ENOMEM;
> > > + goto out_mmput;
> > > + }
> > > +
> > > + down_read(>mmap_sem);
> > > + arg_start = mm->arg_start;
> >
On Thu, May 28, 2015 at 01:12:14AM +0300, Alexey Dobriyan wrote:
> On Thu, May 28, 2015 at 01:02:29AM +0300, Cyrill Gorcunov wrote:
> > On Thu, May 28, 2015 at 12:47:57AM +0300, Alexey Dobriyan wrote:
> > > Individual prctl(PR_SET_MM_*) calls do some checking to maintain
>
On Thu, May 28, 2015 at 12:49:53AM +0300, Alexey Dobriyan wrote:
...
> -static int proc_pid_cmdline(struct seq_file *m, struct pid_namespace *ns,
> - struct pid *pid, struct task_struct *task)
> +static ssize_t proc_pid_cmdline_read(struct file *file, char __user *buf,
> +
t; The program below makes both ARGV and ENVP areas reverted,
> makes /proc/$PID/cmdline show garbage (doesn't oops by luck).
Why should it oops? Actually i would really love to drop off old
PR_SET_MM_ interface completely (which requires CAP_SYS_RESOURCE),
leaving only MM_MAP. Bu
On Thu, May 28, 2015 at 01:29:42AM +0300, Alexey Dobriyan wrote:
+
+ page = (char *)__get_free_page(GFP_TEMPORARY);
+ if (!page) {
+ rv = -ENOMEM;
+ goto out_mmput;
+ }
+
+ down_read(mm-mmap_sem);
+ arg_start = mm-arg_start;
+ arg_end = mm-arg_end;
areas reverted,
makes /proc/$PID/cmdline show garbage (doesn't oops by luck).
Why should it oops? Actually i would really love to drop off old
PR_SET_MM_ interface completely (which requires CAP_SYS_RESOURCE),
leaving only MM_MAP. But thank you!
Acked-by: Cyrill Gorcunov gorcu...@openvz.org
On Thu, May 28, 2015 at 12:49:53AM +0300, Alexey Dobriyan wrote:
...
-static int proc_pid_cmdline(struct seq_file *m, struct pid_namespace *ns,
- struct pid *pid, struct task_struct *task)
+static ssize_t proc_pid_cmdline_read(struct file *file, char __user *buf,
+
On Thu, May 28, 2015 at 01:12:14AM +0300, Alexey Dobriyan wrote:
On Thu, May 28, 2015 at 01:02:29AM +0300, Cyrill Gorcunov wrote:
On Thu, May 28, 2015 at 12:47:57AM +0300, Alexey Dobriyan wrote:
Individual prctl(PR_SET_MM_*) calls do some checking to maintain
consistent view of mm
On Tue, Apr 28, 2015 at 03:23:53PM -0700, Calvin Owens wrote:
> >
> > Guys, I'm really-really sorry for not replying the email that long.
> > If I understand correctly all concerns were addressed, right?
>
> Ping!
>
> I thought everybody was happy after the permission check was changed
> to be
On Tue, Apr 28, 2015 at 03:23:53PM -0700, Calvin Owens wrote:
Guys, I'm really-really sorry for not replying the email that long.
If I understand correctly all concerns were addressed, right?
Ping!
I thought everybody was happy after the permission check was changed
to be
On Mon, Apr 13, 2015 at 09:56:20PM +0200, Michael Kerrisk (man-pages) wrote:
> Hello Cyrill,
>
> On 07/15/2014 11:54 PM, Cyrill Gorcunov wrote:
> > ioctl(2)
> > The following commands are supported: TFD_IOC_SET_TICKS to adjust
> > the number of the timer exp
On Mon, Apr 13, 2015 at 09:56:20PM +0200, Michael Kerrisk (man-pages) wrote:
Hello Cyrill,
On 07/15/2014 11:54 PM, Cyrill Gorcunov wrote:
ioctl(2)
The following commands are supported: TFD_IOC_SET_TICKS to adjust
the number of the timer expirations that have occurred
On Fri, Apr 10, 2015 at 03:16:18PM -0700, Andy Lutomirski wrote:
> On Fri, Apr 10, 2015 at 3:11 PM, Cyrill Gorcunov wrote:
> > On Fri, Apr 10, 2015 at 02:59:19PM -0700, Andy Lutomirski wrote:
> >>
> >> As long as you're doing that, any chance you could remove CP
On Fri, Apr 10, 2015 at 02:59:19PM -0700, Andy Lutomirski wrote:
>
> As long as you're doing that, any chance you could remove CPREG1(gs)
> and CPREG1(fs) as well? They haven't had any effect since
> 2.5.something_very_old, and the kernel might want to reuse those
> sigcontext slots some day.
On Fri, Apr 10, 2015 at 02:59:19PM -0700, Andy Lutomirski wrote:
As long as you're doing that, any chance you could remove CPREG1(gs)
and CPREG1(fs) as well? They haven't had any effect since
2.5.something_very_old, and the kernel might want to reuse those
sigcontext slots some day.
Yeah,
On Fri, Apr 10, 2015 at 03:16:18PM -0700, Andy Lutomirski wrote:
On Fri, Apr 10, 2015 at 3:11 PM, Cyrill Gorcunov gorcu...@gmail.com wrote:
On Fri, Apr 10, 2015 at 02:59:19PM -0700, Andy Lutomirski wrote:
As long as you're doing that, any chance you could remove CPREG1(gs)
and CPREG1(fs
On Mon, Mar 30, 2015 at 05:59:15PM +0900, Minchan Kim wrote:
> Hi Cyrill,
>
> On Mon, Mar 30, 2015 at 11:51:12AM +0300, Cyrill Gorcunov wrote:
> > On Mon, Mar 30, 2015 at 02:22:50PM +0900, Minchan Kim wrote:
> > > 2nd description trial.
> > ...
> > Hi Minch
On Mon, Mar 30, 2015 at 02:22:50PM +0900, Minchan Kim wrote:
> 2nd description trial.
...
Hi Minchan, could you please point for which repo this patch,
linux-next?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
On Mon, Mar 30, 2015 at 02:22:50PM +0900, Minchan Kim wrote:
2nd description trial.
...
Hi Minchan, could you please point for which repo this patch,
linux-next?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
On Mon, Mar 30, 2015 at 05:59:15PM +0900, Minchan Kim wrote:
Hi Cyrill,
On Mon, Mar 30, 2015 at 11:51:12AM +0300, Cyrill Gorcunov wrote:
On Mon, Mar 30, 2015 at 02:22:50PM +0900, Minchan Kim wrote:
2nd description trial.
...
Hi Minchan, could you please point for which repo this patch
On Mon, Mar 16, 2015 at 03:08:40PM -0700, Kees Cook wrote:
> >
> >> Ok I think I am finally seeing where you are going. And I like it *a
> >> lot* because it allows us to basically replace mmap_sem with rcu
> >> (MMF_EXE_FILE_CHANGED being the only user that requires a lock!!), but
> >> am afraid
On Fri, Mar 20, 2015 at 03:07:38PM +0100, Oleg Nesterov wrote:
>
> Another downside (to me) is that this special case can help, but only
> "by accident".
>
> For example, criu has ->ss = 0, but it was not initialized explicitly.
>
> But as I said, I won't argue.
OK, after talking to Pavel --
On Fri, Mar 20, 2015 at 02:56:22PM +0300, Cyrill Gorcunov wrote:
> > >
> > > fwiw currently we're passing zero in this __pad0 (replying to your
> > > previous email, so we can workaround in the kernel assuming zero
> > > as a special case, not that good but be
On Fri, Mar 20, 2015 at 12:43:14PM +0100, Denys Vlasenko wrote:
> On Thu, Mar 19, 2015 at 8:35 AM, Cyrill Gorcunov wrote:
> > On Wed, Mar 18, 2015 at 03:03:27PM -0700, Andy Lutomirski wrote:
> >> I don't have a great idea for how to work around this, unfortunately.
> >
On Fri, Mar 20, 2015 at 03:07:38PM +0100, Oleg Nesterov wrote:
Another downside (to me) is that this special case can help, but only
by accident.
For example, criu has -ss = 0, but it was not initialized explicitly.
But as I said, I won't argue.
OK, after talking to Pavel -- it's fine
On Fri, Mar 20, 2015 at 12:43:14PM +0100, Denys Vlasenko wrote:
On Thu, Mar 19, 2015 at 8:35 AM, Cyrill Gorcunov gorcu...@gmail.com wrote:
On Wed, Mar 18, 2015 at 03:03:27PM -0700, Andy Lutomirski wrote:
I don't have a great idea for how to work around this, unfortunately.
Ideally we'd
On Fri, Mar 20, 2015 at 02:56:22PM +0300, Cyrill Gorcunov wrote:
fwiw currently we're passing zero in this __pad0 (replying to your
previous email, so we can workaround in the kernel assuming zero
as a special case, not that good but better than nothing).
Special-casing zero
On Mon, Mar 16, 2015 at 03:08:40PM -0700, Kees Cook wrote:
Ok I think I am finally seeing where you are going. And I like it *a
lot* because it allows us to basically replace mmap_sem with rcu
(MMF_EXE_FILE_CHANGED being the only user that requires a lock!!), but
am afraid it might not
On Thu, Mar 19, 2015 at 09:08:08AM -0700, Andy Lutomirski wrote:
> >> >
> >> >> So... do we introduce somewhat nasty code into the kernel to keep old
> >> >> CRIU versions working, or do we require that users who want to restore
> >> >> onto new kernels use new CRIU?
> >> >
> >> > It's OK (I
On Thu, Mar 19, 2015 at 01:41:03PM +0300, Vladimir Davydov wrote:
> >
> > Vladimir, might we need get_online_mems/put_online_mems here,
> > or if node gets offline this wont be a problem? (Asking
> > because i don't know).
>
> I only need to dereference page structs corresponding to the node
On Wed, Mar 18, 2015 at 11:44:36PM +0300, Vladimir Davydov wrote:
> Knowing the portion of memory that is not used by a certain application
> or memory cgroup (idle memory) can be useful for partitioning the system
> efficiently. Currently, the only means to estimate the amount of idle
> memory
On Wed, Mar 18, 2015 at 03:03:27PM -0700, Andy Lutomirski wrote:
> On Wed, Mar 18, 2015 at 2:34 PM, Pavel Emelyanov wrote:
> > On 03/19/2015 12:26 AM, Andy Lutomirski wrote:
> >> On Wed, Mar 18, 2015 at 1:02 PM, Oleg Nesterov wrote:
> >>> On 03/18, Andrey Wagin wrote:
>
> This patch
On Wed, Mar 18, 2015 at 03:03:27PM -0700, Andy Lutomirski wrote:
On Wed, Mar 18, 2015 at 2:34 PM, Pavel Emelyanov xe...@parallels.com wrote:
On 03/19/2015 12:26 AM, Andy Lutomirski wrote:
On Wed, Mar 18, 2015 at 1:02 PM, Oleg Nesterov o...@redhat.com wrote:
On 03/18, Andrey Wagin wrote:
On Thu, Mar 19, 2015 at 01:41:03PM +0300, Vladimir Davydov wrote:
Vladimir, might we need get_online_mems/put_online_mems here,
or if node gets offline this wont be a problem? (Asking
because i don't know).
I only need to dereference page structs corresponding to the node here,
and
On Wed, Mar 18, 2015 at 11:44:36PM +0300, Vladimir Davydov wrote:
Knowing the portion of memory that is not used by a certain application
or memory cgroup (idle memory) can be useful for partitioning the system
efficiently. Currently, the only means to estimate the amount of idle
memory
On Thu, Mar 19, 2015 at 09:08:08AM -0700, Andy Lutomirski wrote:
So... do we introduce somewhat nasty code into the kernel to keep old
CRIU versions working, or do we require that users who want to restore
onto new kernels use new CRIU?
It's OK (I think) to require newer versions
On Wed, Mar 18, 2015 at 07:25:22PM +0100, Oleg Nesterov wrote:
> On 03/18, Cyrill Gorcunov wrote:
> >
> > On Wed, Mar 18, 2015 at 11:06:00AM -0700, Andy Lutomirski wrote:
> > > > --- a/arch/x86/crtools.c
> > > > +++ b/arch/x86/crtools.c
> > >
On Wed, Mar 18, 2015 at 07:31:33PM +0100, Oleg Nesterov wrote:
> On 03/18, Cyrill Gorcunov wrote:
> >
> > On Wed, Mar 18, 2015 at 06:48:43PM +0100, Oleg Nesterov wrote:
> > >
> > > Shot in a dark afer a quick grep: restore_gpregs() should initialize ->ss?
&
On Wed, Mar 18, 2015 at 11:20:08AM -0700, Andy Lutomirski wrote:
> >
> > Basically the initial registers values are fetched with ptrace
> > when program is been dumped, then on restore we copy them back
> > into sigcontext. That said we don't mangle fs/gs anyhow simply
> > restore the values back
On Wed, Mar 18, 2015 at 11:06:00AM -0700, Andy Lutomirski wrote:
> > --- a/arch/x86/crtools.c
> > +++ b/arch/x86/crtools.c
> > @@ -475,6 +475,7 @@ int restore_gpregs(struct rt_sigframe *f,
> > UserX86RegsEntry *r)
> > CPREG2(rip, ip);
> > CPREG2(eflags, flags);
> >
On Wed, Mar 18, 2015 at 06:48:43PM +0100, Oleg Nesterov wrote:
> On 03/18, Andrey Wagin wrote:
> >
> > This commit breaks CRIU. I don't have any details yet. I'm going to
> > investigate this issue and provide more details tomorrow.
> >
> > [root@avagin-fc19-cr criu]# setsid sleep 1000 &
> > [1]
On Wed, Mar 18, 2015 at 11:06:00AM -0700, Andy Lutomirski wrote:
--- a/arch/x86/crtools.c
+++ b/arch/x86/crtools.c
@@ -475,6 +475,7 @@ int restore_gpregs(struct rt_sigframe *f,
UserX86RegsEntry *r)
CPREG2(rip, ip);
CPREG2(eflags, flags);
CPREG1(cs);
+
On Wed, Mar 18, 2015 at 06:48:43PM +0100, Oleg Nesterov wrote:
On 03/18, Andrey Wagin wrote:
This commit breaks CRIU. I don't have any details yet. I'm going to
investigate this issue and provide more details tomorrow.
[root@avagin-fc19-cr criu]# setsid sleep 1000
[1] 1225
On Wed, Mar 18, 2015 at 11:20:08AM -0700, Andy Lutomirski wrote:
Basically the initial registers values are fetched with ptrace
when program is been dumped, then on restore we copy them back
into sigcontext. That said we don't mangle fs/gs anyhow simply
restore the values back from dump.
On Wed, Mar 18, 2015 at 07:25:22PM +0100, Oleg Nesterov wrote:
On 03/18, Cyrill Gorcunov wrote:
On Wed, Mar 18, 2015 at 11:06:00AM -0700, Andy Lutomirski wrote:
--- a/arch/x86/crtools.c
+++ b/arch/x86/crtools.c
@@ -475,6 +475,7 @@ int restore_gpregs(struct rt_sigframe *f
On Wed, Mar 18, 2015 at 07:31:33PM +0100, Oleg Nesterov wrote:
On 03/18, Cyrill Gorcunov wrote:
On Wed, Mar 18, 2015 at 06:48:43PM +0100, Oleg Nesterov wrote:
Shot in a dark afer a quick grep: restore_gpregs() should initialize -ss?
It hasn't been needed earlier, if this would help
On Sun, Mar 15, 2015 at 08:42:05AM -0700, Davidlohr Bueso wrote:
> > > > Yes, this code needs cleanups, I agree. Does this series makes it
> > > > better?
> > > > To me it doesn't, and the diffstat below shows that it blows the code.
> > >
> > > Looking at some of the caller paths now, I have to
On Sun, Mar 15, 2015 at 08:42:05AM -0700, Davidlohr Bueso wrote:
Yes, this code needs cleanups, I agree. Does this series makes it
better?
To me it doesn't, and the diffstat below shows that it blows the code.
Looking at some of the caller paths now, I have to disagree.
And
On Tue, Mar 10, 2015 at 04:41:39PM -0600, Shuah Khan wrote:
>
> Are you looking for something like this:
>
> all: kcmp_test
>
> kcmp_test:
> $(CC) $(CFLAGS) kcmp_test.c -o kcmp_test
>
> I just simplified it and removed the prerequsite.
> If you prefer, I can make the change to keep the
>
On Sat, Feb 14, 2015 at 12:40:09PM -0800, Calvin Owens wrote:
> Currently, /proc//map_files/ is restricted to CAP_SYS_ADMIN, and
> is only exposed if CONFIG_CHECKPOINT_RESTORE is set. This interface is
> very useful for enumerating the files mapped into a process when the
> more verbose
On Tue, Mar 10, 2015 at 04:00:59PM -0600, Shuah Khan wrote:
> kcmp Makefile doesn't have an explicit build rule. As a result,
> kcmp build fails, when it is run from top level Makefile target
> kselftest. Without the explicit rule, make works only when it is
> run in the current directory or from
On Tue, Mar 10, 2015 at 04:00:59PM -0600, Shuah Khan wrote:
kcmp Makefile doesn't have an explicit build rule. As a result,
kcmp build fails, when it is run from top level Makefile target
kselftest. Without the explicit rule, make works only when it is
run in the current directory or from
On Sat, Feb 14, 2015 at 12:40:09PM -0800, Calvin Owens wrote:
Currently, /proc/pid/map_files/ is restricted to CAP_SYS_ADMIN, and
is only exposed if CONFIG_CHECKPOINT_RESTORE is set. This interface is
very useful for enumerating the files mapped into a process when the
more verbose information
On Tue, Mar 10, 2015 at 04:41:39PM -0600, Shuah Khan wrote:
Are you looking for something like this:
all: kcmp_test
kcmp_test:
$(CC) $(CFLAGS) kcmp_test.c -o kcmp_test
I just simplified it and removed the prerequsite.
If you prefer, I can make the change to keep the
prereq.
t; ...
>
> $ ps -C rpcbind
> PID TTY TIME CMD
> 332 ?00:00:00 rpcbind
>
...
Looks reasonable to me, thanks!
Acked-by: Cyrill Gorcunov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord..
601 - 700 of 2647 matches
Mail list logo
