332 ?00:00:00 rpcbind
...
Looks reasonable to me, thanks!
Acked-by: Cyrill Gorcunov gorcu...@openvz.org
--
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
On Thu, Feb 26, 2015 at 11:36:57AM -0800, Davidlohr Bueso wrote:
> We currently use the mmap_sem to serialize the mm exe_file.
> This is atrocious and a clear example of the misuses this
> lock has all over the place, making any significant changes
> to the address space locking that much more
On Thu, Feb 26, 2015 at 11:36:57AM -0800, Davidlohr Bueso wrote:
We currently use the mmap_sem to serialize the mm exe_file.
This is atrocious and a clear example of the misuses this
lock has all over the place, making any significant changes
to the address space locking that much more complex
ODE_ATTACH);
> + put_task_struct(task);
> + }
else
return ERR_PTR(-ESRCH);
Other than that, looks good to me, thanks!
Rewieved-by: Cyrill Gorcunov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to m
(-ESRCH);
Other than that, looks good to me, thanks!
Rewieved-by: Cyrill Gorcunov gorcu...@openvz.org
--
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
On Tue, Jan 27, 2015 at 11:53:19AM -0800, Kees Cook wrote:
> >>
> >> Are mount namespaces handled in this output?
> >
> > Could you clarify this moment, i'm not sure i get it.
>
> I changed how I asked this question in my review of the documentation,
> but it looks like these symlinks aren't
On Tue, Jan 27, 2015 at 11:50:49AM -0800, Kees Cook wrote:
> > +
> > +The main purpose of map_files directory is to be able to retrieve a set of
> > +memory mapped files in a fast way instead of parsing /proc//maps or
> > +/proc//smaps which contain a way more records. Same time one can
> >
Signed-off-by: Cyrill Gorcunov
CC: Kees Cook
CC: Andrew Morton
CC: "Kirill A. Shutemov"
CC: Calvin Owens
CC: Alexey Dobriyan
CC: Oleg Nesterov
CC: "Eric W. Biederman"
CC: Al Viro
CC: Peter Feiner
CC: Pavel Emelyanov
---
Gentlemen, could you please take a look onc
Signed-off-by: Cyrill Gorcunov gorcu...@openvz.org
CC: Kees Cook keesc...@chromium.org
CC: Andrew Morton a...@linux-foundation.org
CC: Kirill A. Shutemov kir...@shutemov.name
CC: Calvin Owens calvinow...@fb.com
CC: Alexey Dobriyan adobri...@gmail.com
CC: Oleg Nesterov o...@redhat.com
CC: Eric W
On Tue, Jan 27, 2015 at 11:50:49AM -0800, Kees Cook wrote:
+
+The main purpose of map_files directory is to be able to retrieve a set of
+memory mapped files in a fast way instead of parsing /proc/pid/maps or
+/proc/pid/smaps which contain a way more records. Same time one can
open(2)
On Tue, Jan 27, 2015 at 11:53:19AM -0800, Kees Cook wrote:
Are mount namespaces handled in this output?
Could you clarify this moment, i'm not sure i get it.
I changed how I asked this question in my review of the documentation,
but it looks like these symlinks aren't regular symlinks
On Mon, Jan 26, 2015 at 04:15:26PM -0800, Kees Cook wrote:
> >
> > akpm3:/usr/src/25> grep -r map_files Documentation
>
> If akpm's comments weren't clear: this needs to be fixed. Everything
> in /proc should appear in Documentation.
I'll do that.
> > The 640708a2cff7f81 changelog says:
> >
> >
On Mon, Jan 26, 2015 at 10:50:23PM -0800, Andrew Morton wrote:
> On Tue, 27 Jan 2015 09:46:47 +0300 Cyrill Gorcunov wrote:
>
> > > There's one other problem here: we're assuming that the map_files
> > > implementation doesn't have bugs. If it does have bugs then relaxin
On Mon, Jan 26, 2015 at 03:43:46PM -0800, Andrew Morton wrote:
> >
> > Looks good to me, thanks! Though I would really appreciate if someone
> > from security camp take a look as well.
>
> hm, who's that. Kees comes to mind.
yup, I managed to forget CC him.
>
> And reviewers' task would be a
On Mon, Jan 26, 2015 at 02:47:31PM +0200, Kirill A. Shutemov wrote:
> On Fri, Jan 23, 2015 at 07:15:44PM -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
non-atomic if pte is larger than wordsize.
> Other pte walkers (smaps, numa_maps, clear_refs) already lock ptes.
>
> Signed-off-by: Konstantin Khlebnikov
> Reported-by: Andrey Ryabinin
> Fixes: 052fb0d635df ("proc: report file/anon bit in /proc/pid/pagemap")
> Cc: S
-by: Cyrill Gorcunov gorcu...@openvz.org
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/
On Mon, Jan 26, 2015 at 10:50:23PM -0800, Andrew Morton wrote:
On Tue, 27 Jan 2015 09:46:47 +0300 Cyrill Gorcunov gorcu...@gmail.com wrote:
There's one other problem here: we're assuming that the map_files
implementation doesn't have bugs. If it does have bugs then relaxing
On Mon, Jan 26, 2015 at 03:43:46PM -0800, Andrew Morton wrote:
Looks good to me, thanks! Though I would really appreciate if someone
from security camp take a look as well.
hm, who's that. Kees comes to mind.
yup, I managed to forget CC him.
And reviewers' task would be a heck of a
On Mon, Jan 26, 2015 at 04:15:26PM -0800, Kees Cook wrote:
akpm3:/usr/src/25 grep -r map_files Documentation
If akpm's comments weren't clear: this needs to be fixed. Everything
in /proc should appear in Documentation.
I'll do that.
The 640708a2cff7f81 changelog says:
: This
On Mon, Jan 26, 2015 at 02:47:31PM +0200, Kirill A. Shutemov wrote:
On Fri, Jan 23, 2015 at 07:15:44PM -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
On Wed, Jan 21, 2015 at 06:45:54PM -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 Wed, Jan 21, 2015 at 06:45:54PM -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 Mon, Jan 19, 2015 at 07:17:18PM +1100, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (sparc defconfig)
> failed like this:
>
> In file included from arch/sparc/include/asm/bug.h:20:0,
> from include/linux/bug.h:4,
>
On Mon, Jan 19, 2015 at 07:17:18PM +1100, Stephen Rothwell wrote:
Hi Andrew,
After merging the akpm tree, today's linux-next build (sparc defconfig)
failed like this:
In file included from arch/sparc/include/asm/bug.h:20:0,
from include/linux/bug.h:4,
On Wed, Jan 14, 2015 at 12:46:53PM -0800, Calvin Owens wrote:
> > >
> > > Restriction to CAP_SYSADMIN for follow_link is undertansble, but why do we
> > > restrict readdir and readlink?
> >
> > We didn't think this functionality might be needed someone but us (criu
> > camp),
> > so that the
nux
> kernel doesn't account PMD tables to the process, only PTE.
>
> The use-cases below use few tricks to allocate a lot of PMD page tables
> while keeping VmRSS and VmPTE low. oom_score for the process will be 0.
Reviewed-by: Cyrill Gorcunov
--
To unsubscribe from this list: se
On Wed, Jan 14, 2015 at 05:25:01PM +0200, Kirill A. Shutemov wrote:
...
> >
> > This gives lsof and suchlike a way to determine the pathnames of files
> > mapped into a process without incurring the O(N^2) behavior of the
> > maps file.
>
> We already have /proc/PID/map_files/ directory which
On Wed, Jan 14, 2015 at 04:33:58PM +0200, Kirill A. Shutemov wrote:
> >
> > It looks like this doesn't matter. The statistics here prints the size
> > of summary memory occupied for pte_t entries, here PTRS_PER_PTE *
> > sizeof(pte_t)
> > is only valid for, once we start accounting pmd into same
On Tue, Jan 13, 2015 at 01:49:10PM -0800, Dave Hansen wrote:
> On 01/13/2015 01:43 PM, Cyrill Gorcunov wrote:
> > On Tue, Jan 13, 2015 at 09:14:15PM +0200, Kirill A. Shutemov wrote:
> >> We're going to account pmd page tables too. Let's rename mm->nr_pgtables
> >
On Wed, Jan 14, 2015 at 12:46:53PM -0800, Calvin Owens wrote:
Restriction to CAP_SYSADMIN for follow_link is undertansble, but why do we
restrict readdir and readlink?
We didn't think this functionality might be needed someone but us (criu
camp),
so that the rule of thumb was
On Wed, Jan 14, 2015 at 04:33:58PM +0200, Kirill A. Shutemov wrote:
It looks like this doesn't matter. The statistics here prints the size
of summary memory occupied for pte_t entries, here PTRS_PER_PTE *
sizeof(pte_t)
is only valid for, once we start accounting pmd into same counter
On Wed, Jan 14, 2015 at 05:25:01PM +0200, Kirill A. Shutemov wrote:
...
This gives lsof and suchlike a way to determine the pathnames of files
mapped into a process without incurring the O(N^2) behavior of the
maps file.
We already have /proc/PID/map_files/ directory which lists all
doesn't account PMD tables to the process, only PTE.
The use-cases below use few tricks to allocate a lot of PMD page tables
while keeping VmRSS and VmPTE low. oom_score for the process will be 0.
Reviewed-by: Cyrill Gorcunov gorcu...@openvz.org
--
To unsubscribe from this list: send the line
On Tue, Jan 13, 2015 at 01:49:10PM -0800, Dave Hansen wrote:
On 01/13/2015 01:43 PM, Cyrill Gorcunov wrote:
On Tue, Jan 13, 2015 at 09:14:15PM +0200, Kirill A. Shutemov wrote:
We're going to account pmd page tables too. Let's rename mm-nr_pgtables
to something more generic.
Signed-off
On Tue, Jan 13, 2015 at 09:14:15PM +0200, Kirill A. Shutemov wrote:
> We're going to account pmd page tables too. Let's rename mm->nr_pgtables
> to something more generic.
>
> Signed-off-by: Kirill A. Shutemov
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -64,7 +64,7 @@ void
On Tue, Jan 13, 2015 at 09:14:15PM +0200, Kirill A. Shutemov wrote:
We're going to account pmd page tables too. Let's rename mm-nr_pgtables
to something more generic.
Signed-off-by: Kirill A. Shutemov kirill.shute...@linux.intel.com
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@
On Fri, Dec 19, 2014 at 02:11:37PM -0800, Andy Lutomirski wrote:
...
> >
> > Therefore, I can fix the current implementation (maintaining the
> > randomize_va_space=2) by moving the PIE executable from the mmap base
> > area to another one for x86*, ARM* and MIPS (as s390 and PowerPC do).
> > But
On Thu, Dec 18, 2014 at 10:04:09PM +0300, Cyrill Gorcunov wrote:
> case __NR_execveat:
>^
> arch/x86/ia32/audit.c:38:7: note: each undeclared identifier is reported only
> once for each function it appears in
> make[2]: *** [arch/x86/ia32/audit.o] Error 1
> make[1]:
On Thu, Dec 18, 2014 at 10:04:09PM +0300, Cyrill Gorcunov wrote:
case __NR_execveat:
^
arch/x86/ia32/audit.c:38:7: note: each undeclared identifier is reported only
once for each function it appears in
make[2]: *** [arch/x86/ia32/audit.o] Error 1
make[1]: *** [arch/x86/ia32] Error
On Fri, Dec 19, 2014 at 02:11:37PM -0800, Andy Lutomirski wrote:
...
Therefore, I can fix the current implementation (maintaining the
randomize_va_space=2) by moving the PIE executable from the mmap base
area to another one for x86*, ARM* and MIPS (as s390 and PowerPC do).
But we shall
Hi! Being trying to build latest repo (2dbfca5a181973558277b28b1f4c36362291f5e0)
and ended up in
CC arch/x86/ia32/audit.o
arch/x86/ia32/audit.c: In function ‘ia32_classify_syscall’:
arch/x86/ia32/audit.c:38:7: error: ‘__NR_execveat’ undeclared (first use in
this function)
case
Hi! Being trying to build latest repo (2dbfca5a181973558277b28b1f4c36362291f5e0)
and ended up in
CC arch/x86/ia32/audit.o
arch/x86/ia32/audit.c: In function ‘ia32_classify_syscall’:
arch/x86/ia32/audit.c:38:7: error: ‘__NR_execveat’ undeclared (first use in
this function)
case
On Fri, Nov 28, 2014 at 03:05:01PM -0800, Andy Lutomirski wrote:
> Pid reuse is common, which means that it's difficult or impossible
> to read information about a pid from /proc without races.
>
> This introduces a second number associated with each (task, pidns)
> pair called highpid. Highpid
On Fri, Nov 28, 2014 at 03:05:01PM -0800, Andy Lutomirski wrote:
Pid reuse is common, which means that it's difficult or impossible
to read information about a pid from /proc without races.
This introduces a second number associated with each (task, pidns)
pair called highpid. Highpid is a
On Thu, Oct 23, 2014 at 09:49:14AM +0200, Arnd Bergmann wrote:
> On Thursday 23 October 2014 16:07:12 Michael Ellerman wrote:
> > --- a/include/linux/kcmp.h
> > +++ b/include/linux/kcmp.h
> > @@ -1,17 +1,6 @@
> > #ifndef _LINUX_KCMP_H
> > #define _LINUX_KCMP_H
> >
> > -/* Comparison type */
>
On Thu, Oct 23, 2014 at 04:07:14PM +1100, Michael Ellerman wrote:
> Don't prevent the test building on non-x86. Just try and build it and
> let the chips fall where they may.
>
> Signed-off-by: Michael Ellerman
kcmp depends on checkpoint/restore config symbol which is known
to work on x86 and
ed-off-by: Michael Ellerman
The reason was to be able to run test without userspace headers generated.
Still this one is better I think.
Acked-by: Cyrill Gorcunov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
On Thu, Oct 23, 2014 at 04:07:12PM +1100, Michael Ellerman wrote:
> kcmp.h appears to be part of the API, it's documented in kcmp(2), and
> the selftests/kcmp code uses it. So move it to uapi so it's actually
> exported.
>
> Signed-off-by: Michael Ellerman
Acked-by:
On Thu, Oct 23, 2014 at 04:07:12PM +1100, Michael Ellerman wrote:
kcmp.h appears to be part of the API, it's documented in kcmp(2), and
the selftests/kcmp code uses it. So move it to uapi so it's actually
exported.
Signed-off-by: Michael Ellerman m...@ellerman.id.au
Acked-by: Cyrill Gorcunov
...@ellerman.id.au
The reason was to be able to run test without userspace headers generated.
Still this one is better I think.
Acked-by: Cyrill Gorcunov gorcu...@openvz.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
On Thu, Oct 23, 2014 at 04:07:14PM +1100, Michael Ellerman wrote:
Don't prevent the test building on non-x86. Just try and build it and
let the chips fall where they may.
Signed-off-by: Michael Ellerman m...@ellerman.id.au
kcmp depends on checkpoint/restore config symbol which is known
to
On Thu, Oct 23, 2014 at 09:49:14AM +0200, Arnd Bergmann wrote:
On Thursday 23 October 2014 16:07:12 Michael Ellerman wrote:
--- a/include/linux/kcmp.h
+++ b/include/linux/kcmp.h
@@ -1,17 +1,6 @@
#ifndef _LINUX_KCMP_H
#define _LINUX_KCMP_H
-/* Comparison type */
-enum kcmp_type
On Thu, Sep 25, 2014 at 10:30:10AM +0200, Jan Kara wrote:
> On Wed 24-09-14 13:19:47, Andrew Morton wrote:
> > On Wed, 24 Sep 2014 12:51:55 +0200 Jan Kara wrote:
> >
> > > Hello,
> > >
> > > Andrew, what do you think about the patch below? Al objected that it
> > > changes userspace visible
On Wed, Sep 24, 2014 at 02:59:27PM -0700, Andrew Morton wrote:
> On Sat, 20 Sep 2014 01:03:07 -0700 Peter Feiner wrote:
>
> > Fixes the same bug as b43790eedd31e9535b89bbfa45793919e9504c34 and
> > 9aed8614af5a05cdaa32a0b78b0f1a424754a958 where the return value of
> > pte_*mksoft_dirty was being
On Thu, Sep 25, 2014 at 10:30:10AM +0200, Jan Kara wrote:
On Wed 24-09-14 13:19:47, Andrew Morton wrote:
On Wed, 24 Sep 2014 12:51:55 +0200 Jan Kara j...@suse.cz wrote:
Hello,
Andrew, what do you think about the patch below? Al objected that it
changes userspace visible
On Wed, Sep 24, 2014 at 02:59:27PM -0700, Andrew Morton wrote:
On Sat, 20 Sep 2014 01:03:07 -0700 Peter Feiner pfei...@google.com wrote:
Fixes the same bug as b43790eedd31e9535b89bbfa45793919e9504c34 and
9aed8614af5a05cdaa32a0b78b0f1a424754a958 where the return value of
pte_*mksoft_dirty
;mk" function return values were
> being ignored, I annotated the functions in
> arch/x86/include/asm/pgtable.h with __must_check and rebuilt.
>
> Signed-off-by: Peter Feiner
Acked-by: Cyrill Gorcunov
I might be missing it, thanks a huge Peter!
--
To unsubscribe from this l
were
being ignored, I annotated the functions in
arch/x86/include/asm/pgtable.h with __must_check and rebuilt.
Signed-off-by: Peter Feiner pfei...@google.com
Acked-by: Cyrill Gorcunov gorcu...@openvz.org
I might be missing it, thanks a huge Peter!
--
To unsubscribe from this list: send
Reviewed-by: Jan Kara
Reviewed-by: Cyrill Gorcunov
--
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/
Reviewed-by: Cyrill Gorcunov gorcu...@openvz.org
--
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/
es userspace will see but I think there
were a bug before this patch, so
Reviewed-by: Cyrill Gorcunov
--
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-i
there
were a bug before this patch, so
Reviewed-by: Cyrill Gorcunov gorcu...@openvz.org
--
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
On Thu, Sep 04, 2014 at 12:40:06PM +0200, Rasmus Villemoes wrote:
> The C operator <= defines a perfectly fine total ordering on the set
> of values representable in a long. However, unlike its namesake in the
> integers, it is not translation invariant, meaning that we do not have
> "b <= c" iff
On Thu, Sep 04, 2014 at 12:40:06PM +0200, Rasmus Villemoes wrote:
The C operator = defines a perfectly fine total ordering on the set
of values representable in a long. However, unlike its namesake in the
integers, it is not translation invariant, meaning that we do not have
b = c iff a+b =
>
> Cc:
> Signed-off-by: Rasmus Villemoes
It's more than that, I looked into disassembly code and
found that compiler overoptimize obfuscation, instead of doing
^ and * sequently it substracts xor production of both operands
first and only then multiplies the result.
Lets stick
and
found that compiler overoptimize obfuscation, instead of doing
^ and * sequently it substracts xor production of both operands
first and only then multiplies the result.
Lets stick with the fix.
Reviewed-by: Cyrill Gorcunov gorcu...@openvz.org
I'll take more precise look at evening, thanks
On Tue, Sep 02, 2014 at 12:14:08PM +0400, Cyrill Gorcunov wrote:
> On Tue, Sep 02, 2014 at 12:00:14PM +0400, Andrey Vagin wrote:
> > MAX_HANDLE_SZ is equal to 128, but currently the size of pad is only 64
> > bytes, so exportfs_encode_inode_fh can return an error.
> >
&g
On Tue, Sep 02, 2014 at 12:00:15PM +0400, Andrey Vagin wrote:
> Currently we handle only ENOSPC. In case of other errors the file_handle
> variable isn't filled properly and we will show a part of stack.
>
> Cc: Cyrill Gorcunov
> Cc: Alexander Viro
> Cc: Andrew Morton
>
On Tue, Sep 02, 2014 at 12:00:14PM +0400, Andrey Vagin wrote:
> MAX_HANDLE_SZ is equal to 128, but currently the size of pad is only 64
> bytes, so exportfs_encode_inode_fh can return an error.
>
> Cc: Cyrill Gorcunov
> Cc: Alexander Viro
> Cc: Andrew Morton
> Signed
On Tue, Sep 02, 2014 at 12:00:14PM +0400, Andrey Vagin wrote:
MAX_HANDLE_SZ is equal to 128, but currently the size of pad is only 64
bytes, so exportfs_encode_inode_fh can return an error.
Cc: Cyrill Gorcunov gorcu...@openvz.org
Cc: Alexander Viro v...@zeniv.linux.org.uk
Cc: Andrew Morton
On Tue, Sep 02, 2014 at 12:00:15PM +0400, Andrey Vagin wrote:
Currently we handle only ENOSPC. In case of other errors the file_handle
variable isn't filled properly and we will show a part of stack.
Cc: Cyrill Gorcunov gorcu...@openvz.org
Cc: Alexander Viro v...@zeniv.linux.org.uk
Cc
On Tue, Sep 02, 2014 at 12:14:08PM +0400, Cyrill Gorcunov wrote:
On Tue, Sep 02, 2014 at 12:00:14PM +0400, Andrey Vagin wrote:
MAX_HANDLE_SZ is equal to 128, but currently the size of pad is only 64
bytes, so exportfs_encode_inode_fh can return an error.
Cc: Cyrill Gorcunov gorcu
On Wed, Aug 27, 2014 at 04:12:43PM -0700, Hugh Dickins wrote:
> > >
> > > Weak argument to me.
>
> Yes. However rarely it's modified, we don't want any chance of it
> corrupting another flag.
>
> VM_SOFTDIRTY is special in the sense that it's maintained in a very
> different way from the other
On Wed, Aug 27, 2014 at 04:12:43PM -0700, Hugh Dickins wrote:
Weak argument to me.
Yes. However rarely it's modified, we don't want any chance of it
corrupting another flag.
VM_SOFTDIRTY is special in the sense that it's maintained in a very
different way from the other VM_flags.
Dan reported that returning bytes left if copy_from_user failed
is a bad option, return traditional -EFAULT instead.
Reported-by: Dan Carpenter
Cc: Andrew Morton
Signed-off-by: Cyrill Gorcunov
---
Dan, this is not for current linux-next, but for Andrew's -mm
queue, since he has prctl code
Dan reported that returning bytes left if copy_from_user failed
is a bad option, return traditional -EFAULT instead.
Reported-by: Dan Carpenter dan.carpen...@oracle.com
Cc: Andrew Morton a...@linux-foundation.org
Signed-off-by: Cyrill Gorcunov gorcu...@gmail.com
---
Dan, this is not for current
,
| from Documentation/prctl/disable-tsc-test.c:14:
| ./usr/include/linux/prctl.h:132:2: error: unknown type name '__u64'
|
Include the header needed.
Signed-off-by: Cyrill Gorcunov
Cc: Andrew Morton
Cc: Stephen Rothwell
---
include/uapi/linux/prctl.h |2 ++
1 file changed, 2
On Tue, Aug 26, 2014 at 06:43:55PM +0300, Kirill A. Shutemov wrote:
> On Tue, Aug 26, 2014 at 07:18:13PM +0400, Cyrill Gorcunov wrote:
> > > Basically, it's safe if only soft-dirty is allowed to modify vm_flags
> > > without down_write(). But why is soft-dirty so special?
&g
On Tue, Aug 26, 2014 at 05:56:12PM +0300, Kirill A. Shutemov wrote:
> > >
> > > It seems safe in vma-softdirty context. But if somebody else will decide
> > > that
> > > it's fine to modify vm_flags without down_write (in their context), we
> > > will get trouble. Sasha will come with weird bug
On Tue, Aug 26, 2014 at 05:04:19PM +0300, Kirill A. Shutemov wrote:
> > >
> > > But now I'm realizing that if this is the _only_ place which modifies
> > > vm_flags with down_read, then it's "probably" safe. I've a vague
> > > feeling that this was discussed before - is that so, Cyrill?
> >
> >
On Mon, Aug 25, 2014 at 02:08:43PM +0400, Cyrill Gorcunov wrote:
> During development of c/r we've noticed that in case if we need to
> support user namespaces we face a problem with capabilities in
> prctl(PR_SET_MM, ...) call, in particular once new user namespace
> is cre
On Mon, Aug 25, 2014 at 09:45:34PM -0700, Hugh Dickins wrote:
> > +static int clear_refs(struct mm_struct *mm, enum clear_refs_types type,
> > + int write)
> > +{
...
> > +
> > + if (write)
> > + down_write(>mmap_sem);
> > + else
> > +
On Tue, Aug 26, 2014 at 04:35:02PM +1000, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> ./usr/include/linux/prctl.h:132: found __[us]{8,16,32,64} type without
> #include
> In file included
On Tue, Aug 26, 2014 at 04:35:02PM +1000, Stephen Rothwell wrote:
Hi Andrew,
After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) failed like this:
./usr/include/linux/prctl.h:132: found __[us]{8,16,32,64} type without
#include linux/types.h
In file
On Mon, Aug 25, 2014 at 09:45:34PM -0700, Hugh Dickins wrote:
+static int clear_refs(struct mm_struct *mm, enum clear_refs_types type,
+ int write)
+{
...
+
+ if (write)
+ down_write(mm-mmap_sem);
+ else
+ down_read(mm-mmap_sem);
+
+
On Mon, Aug 25, 2014 at 02:08:43PM +0400, Cyrill Gorcunov wrote:
During development of c/r we've noticed that in case if we need to
support user namespaces we face a problem with capabilities in
prctl(PR_SET_MM, ...) call, in particular once new user namespace
is created capable
On Tue, Aug 26, 2014 at 05:04:19PM +0300, Kirill A. Shutemov wrote:
But now I'm realizing that if this is the _only_ place which modifies
vm_flags with down_read, then it's probably safe. I've a vague
feeling that this was discussed before - is that so, Cyrill?
Well, as far as I
On Tue, Aug 26, 2014 at 05:56:12PM +0300, Kirill A. Shutemov wrote:
It seems safe in vma-softdirty context. But if somebody else will decide
that
it's fine to modify vm_flags without down_write (in their context), we
will get trouble. Sasha will come with weird bug report one day
On Tue, Aug 26, 2014 at 06:43:55PM +0300, Kirill A. Shutemov wrote:
On Tue, Aug 26, 2014 at 07:18:13PM +0400, Cyrill Gorcunov wrote:
Basically, it's safe if only soft-dirty is allowed to modify vm_flags
without down_write(). But why is soft-dirty so special?
because how we use this bit
:0,
| from Documentation/prctl/disable-tsc-test.c:14:
| ./usr/include/linux/prctl.h:132:2: error: unknown type name '__u64'
|
Include the header needed.
Signed-off-by: Cyrill Gorcunov gorcu...@openvz.org
Cc: Andrew Morton a...@linux-foundation.org
Cc: Stephen Rothwell s
On Mon, Aug 25, 2014 at 09:12:07PM +0200, Oleg Nesterov wrote:
> + vma = find_vma(current->mm, addr);
> + if (vma) {
> + unsigned long end = addr + size;
> +
> + if (vma->vm_flags & VM_GROWSDOWN)
> + end +=
bers validation lockless, it's unneeded
and confusing especially because of next bullet
- don't use VMA lookup, a program may map new vma
and unmap old own ones generated by the kernel
during executable startup
- use write-lock for mm::exe_link update so that
get_mm_exe_file won't race
and confusing especially because of next bullet
- don't use VMA lookup, a program may map new vma
and unmap old own ones generated by the kernel
during executable startup
- use write-lock for mm::exe_link update so that
get_mm_exe_file won't race with us
Signed-off-by: Cyrill Gorcunov
On Mon, Aug 25, 2014 at 09:12:07PM +0200, Oleg Nesterov wrote:
+ vma = find_vma(current-mm, addr);
+ if (vma) {
+ unsigned long end = addr + size;
+
+ if (vma-vm_flags VM_GROWSDOWN)
+ end +=
since
> VM_SOFTDIRTY is 0 in this case:
>
> if (IS_ENABLED(CONFIG_MEM_SOFT_DIRTY) && !(vm_flags & VM_SOFTDIRTY))
>
> Otherwise looks good to me.
>
> Suggested-by: Kirill A. Shutemov
> Reviewed-by: Kirill A. Shutemov
Really sorry for delay. Th
))
Otherwise looks good to me.
Suggested-by: Kirill A. Shutemov kirill.shute...@linux.intel.com
Reviewed-by: Kirill A. Shutemov kirill.shute...@linux.intel.com
Really sorry for delay. Thanks a huge, guys!
Reviewed-by: Cyrill Gorcunov gorcu...@openvz.org
--
To unsubscribe from this list: send
On Sat, Aug 23, 2014 at 09:29:15PM +0200, Oleg Nesterov wrote:
> On 08/23, Cyrill Gorcunov wrote:
> >
> > On Sat, Aug 23, 2014 at 05:32:22PM +0200, Oleg Nesterov wrote:
> > >
> > > And btw, where do you see RLIMIT_STACK in do_shmat() ?
> >
> > Indi
On Sat, Aug 23, 2014 at 05:32:22PM +0200, Oleg Nesterov wrote:
> > >
> > > Besides, it can't help anyway. cred_guard_mutex is per-process (not
> > > per-thread),
> > > suppose that a vfork()'ed child does prctl() while another thread reads
> > > the
> > > parent's /proc/pid/auxv.
> >
> > Then
d not
> dare to do this. So the patch only fixes the 1st problem (mostly to
> avoid the usage of mm->start_stack) and ignores VM_GROWSUP.
>
> Signed-off-by: Oleg Nesterov
Reviewed-by: Cyrill Gorcunov
I don't understand this check either, the comment above it says nothi
701 - 800 of 2647 matches
Mail list logo
