Re: x86: Hardware breakpoints are not always triggered

On Thu, Jan 28, 2016 at 10:33:28PM +0100, Paolo Bonzini wrote: > > > On 28/01/2016 09:31, Andrey Wagin wrote: > > I tried to print drX registers after a break-point. Looks like they > > are set correctly. > > Can you try this KVM patch? Looks like it fixes a case w

x86: Hardware breakpoints are not always triggered

Hi, We use hardware breakpoints in CRIU and we found that sometimes we set a break-point, but a process doesn't stop on it. I write a small reproducer for this bug. It create two processes, where a parent process traces a child. The parent process sets a break-point and each time when the child

Re: x86: Hardware breakpoints are not always triggered

On Thu, Jan 28, 2016 at 10:33:28PM +0100, Paolo Bonzini wrote: > > > On 28/01/2016 09:31, Andrey Wagin wrote: > > I tried to print drX registers after a break-point. Looks like they > > are set correctly. > > Can you try this KVM patch? Looks like it fixes a case w

x86: Hardware breakpoints are not always triggered

Hi, We use hardware breakpoints in CRIU and we found that sometimes we set a break-point, but a process doesn't stop on it. I write a small reproducer for this bug. It create two processes, where a parent process traces a child. The parent process sets a break-point and each time when the child

Re: WARNING: static_key_slow_dec used before call to jump_label_init

2015-09-24 9:57 GMT+03:00 Andrey Wagin : > Hello, > > I booted kernel with cgroup_disable=cpu and get this warning: > > [0.00] Kernel command line: > BOOT_IMAGE=/boot/vmlinuz-4.3.0-rc2-next-20150923 no_timer_check > console=ttyS0,115200n8 root=UUID=01bc7316-b1f4-45c9-

WARNING: static_key_slow_dec used before call to jump_label_init

Hello, I booted kernel with cgroup_disable=cpu and get this warning: [0.00] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.3.0-rc2-next-20150923 no_timer_check console=ttyS0,115200n8 root=UUID=01bc7316-b1f4-45c9-a23a-0 [0.00] [ cut here ] [0.00]

WARNING: static_key_slow_dec used before call to jump_label_init

Hello, I booted kernel with cgroup_disable=cpu and get this warning: [0.00] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.3.0-rc2-next-20150923 no_timer_check console=ttyS0,115200n8 root=UUID=01bc7316-b1f4-45c9-a23a-0 [0.00] [ cut here ] [0.00]

Re: WARNING: static_key_slow_dec used before call to jump_label_init

2015-09-24 9:57 GMT+03:00 Andrey Wagin <ava...@gmail.com>: > Hello, > > I booted kernel with cgroup_disable=cpu and get this warning: > > [0.00] Kernel command line: > BOOT_IMAGE=/boot/vmlinuz-4.3.0-rc2-next-20150923 no_timer_check > console=ttyS0,115200n8 root=U

Re: [PATCH] inotify: hide internal kernel bits from fdinfo

t trying > to set a bit that was already set. > > This patch hides that bit from fdinfo. CRIU will not see the > bit, not try to set it, and should work as before. We should not > have been exposing this bit in the first place, so this is a good > patch independent of the CRIU pro

Re: [PATCH] inotify: actually check for invalid bits in sys_inotify_add_watch()

2015-09-10 23:49 GMT+03:00 Andrew Morton : > On Wed, 9 Sep 2015 16:32:37 -0700 Dave Hansen wrote: > >> On 09/09/2015 04:16 PM, Eric Paris wrote: >> > Looks fine to me. And usually akpm picks them up these days. >> >> Is that an Acked-by? :) > > I grabbed it for 4.3. This patch breaks CRIU. When

Re: [PATCH] inotify: actually check for invalid bits in sys_inotify_add_watch()

2015-09-10 23:49 GMT+03:00 Andrew Morton : > On Wed, 9 Sep 2015 16:32:37 -0700 Dave Hansen wrote: > >> On 09/09/2015 04:16 PM, Eric Paris wrote: >> > Looks fine to me. And usually akpm picks them up these days. >> >> Is that an Acked-by? :) > > I grabbed

Re: [PATCH] inotify: hide internal kernel bits from fdinfo

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: Andrey Vagin <ava...@openvz.org> Thanks, Andrey > Cc: Andrew Morton <a...@linux-f

Re: linux-next: BUG: unable to handle kernel NULL pointer dereference in cfq_print_leaf_weight()

2015-06-19 23:26 GMT+03:00 Andrey Wagin : > 2015-06-19 19:24 GMT+03:00 Jens Axboe : >> On 06/17/2015 03:55 PM, Andrey Wagin wrote: >>> >>> Hi All, >>> >>> I executed CRIU tests on the 4.1.0-rc8-next-20150617 kernel and met >>> thi

Re: linux-next: BUG: unable to handle kernel NULL pointer dereference in cfq_print_leaf_weight()

2015-06-19 23:26 GMT+03:00 Andrey Wagin ava...@gmail.com: 2015-06-19 19:24 GMT+03:00 Jens Axboe ax...@kernel.dk: On 06/17/2015 03:55 PM, Andrey Wagin wrote: Hi All, I executed CRIU tests on the 4.1.0-rc8-next-20150617 kernel and met this bug. Maybe it will be interested for someone to look

Re: linux-next: BUG: unable to handle kernel NULL pointer dereference in cfq_print_leaf_weight()

2015-06-19 19:24 GMT+03:00 Jens Axboe : > On 06/17/2015 03:55 PM, Andrey Wagin wrote: >> >> Hi All, >> >> I executed CRIU tests on the 4.1.0-rc8-next-20150617 kernel and met >> this bug. Maybe it will be interested for someone to look at it. > > > This sh

Re: linux-next: BUG: unable to handle kernel NULL pointer dereference in cfq_print_leaf_weight()

2015-06-19 19:24 GMT+03:00 Jens Axboe ax...@kernel.dk: On 06/17/2015 03:55 PM, Andrey Wagin wrote: Hi All, I executed CRIU tests on the 4.1.0-rc8-next-20150617 kernel and met this bug. Maybe it will be interested for someone to look at it. This should fix it: http://git.kernel.dk/cgit

Re: linux-next: BUG: unable to handle kernel NULL pointer dereference in cfq_print_leaf_weight()

2015-06-18 0:55 GMT+03:00 Andrey Wagin : > Hi All, > > I executed CRIU tests on the 4.1.0-rc8-next-20150617 kernel and met > this bug. Maybe it will be interested for someone to look at it. This bug isn't reproduced if one of devices uses the cfq scheduler: [root@avagin-fc19-cr

Re: linux-next: BUG: unable to handle kernel NULL pointer dereference in cfq_print_leaf_weight()

2015-06-18 0:55 GMT+03:00 Andrey Wagin ava...@gmail.com: Hi All, I executed CRIU tests on the 4.1.0-rc8-next-20150617 kernel and met this bug. Maybe it will be interested for someone to look at it. This bug isn't reproduced if one of devices uses the cfq scheduler: [root@avagin-fc19-cr

linux-next: BUG: unable to handle kernel NULL pointer dereference in cfq_print_leaf_weight()

Hi All, I executed CRIU tests on the 4.1.0-rc8-next-20150617 kernel and met this bug. Maybe it will be interested for someone to look at it. [ 30.130897] BUG: unable to handle kernel NULL pointer dereference at 001c [ 30.130970] IP: [] cfq_print_leaf_weight+0x31/0x50 [

linux-next: BUG: unable to handle kernel NULL pointer dereference in cfq_print_leaf_weight()

Hi All, I executed CRIU tests on the 4.1.0-rc8-next-20150617 kernel and met this bug. Maybe it will be interested for someone to look at it. [ 30.130897] BUG: unable to handle kernel NULL pointer dereference at 001c [ 30.130970] IP: [813bc7e1]

Re: [PATCH] seccomp: add ptrace commands for suspend/resume

2015-06-01 22:28 GMT+03:00 Tycho Andersen : > This patch is the first step in enabling checkpoint/restore of processes > with seccomp enabled. > > One of the things CRIU does while dumping tasks is inject code into them > via ptrace to collect information that is only available to the process >

Re: [PATCH] seccomp: add ptrace commands for suspend/resume

2015-06-01 22:28 GMT+03:00 Tycho Andersen tycho.ander...@canonical.com: This patch is the first step in enabling checkpoint/restore of processes with seccomp enabled. One of the things CRIU does while dumping tasks is inject code into them via ptrace to collect information that is only

Re: [PATCH] fbcon: Avoid deleting a timer in IRQ context

2015-05-21 10:58 GMT+03:00 Thierry Reding : > From: Thierry Reding > > Commit 27a4c827c34a ("fbcon: use the cursor blink interval provided by > vt") unconditionally removes the cursor blink timer. Unfortunately that > wreaks havoc under some circumstances. An easily reproducible way is to > use

Re: [PATCH 2/2] fbcon: use the cursor blink interval provided by vt

2015-05-27 10:52 GMT+03:00 Scot Doyle : > On Wed, 27 May 2015, Andrey Wagin wrote: > ... >> I regularly execute criu tests on linux-next. For this, I use virtual >> machine from the digitalocean clould. The current version of >> linux-next hangs after a few seconds.

Re: [PATCH 2/2] fbcon: use the cursor blink interval provided by vt

2015-05-27 10:52 GMT+03:00 Scot Doyle lkm...@scotdoyle.com: On Wed, 27 May 2015, Andrey Wagin wrote: ... I regularly execute criu tests on linux-next. For this, I use virtual machine from the digitalocean clould. The current version of linux-next hangs after a few seconds. I use git bisect

Re: [PATCH] fbcon: Avoid deleting a timer in IRQ context

2015-05-21 10:58 GMT+03:00 Thierry Reding thierry.red...@gmail.com: From: Thierry Reding tred...@nvidia.com Commit 27a4c827c34a (fbcon: use the cursor blink interval provided by vt) unconditionally removes the cursor blink timer. Unfortunately that wreaks havoc under some circumstances. An

Re: [PATCH 2/2] fbcon: use the cursor blink interval provided by vt

2015-02-27 22:15 GMT+03:00 Scot Doyle : > vt now provides a cursor blink interval via vc_data. Use this > interval instead of the currently hardcoded 200 msecs. Store it in > fbcon_ops to avoid locking the console in cursor_timer_handler(). I regularly execute criu tests on linux-next. For this,

Re: [PATCH 2/2] fbcon: use the cursor blink interval provided by vt

2015-02-27 22:15 GMT+03:00 Scot Doyle lkm...@scotdoyle.com: vt now provides a cursor blink interval via vc_data. Use this interval instead of the currently hardcoded 200 msecs. Store it in fbcon_ops to avoid locking the console in cursor_timer_handler(). I regularly execute criu tests on

Re: [PATCH] fs: show locked and lock_ro options in mountinfo

2015-03-28 1:47 GMT+03:00 Richard Weinberger : > Hi! > > Am 27.03.2015 um 23:35 schrieb Andrey Wagin: >> 2015-03-28 0:42 GMT+03:00 Richard Weinberger : >>> On Fri, Mar 27, 2015 at 9:39 PM, Andrey Vagin wrote: >>>> I don't see any reasons to hide them. This inf

Re: [PATCH] fs: show locked and lock_ro options in mountinfo

2015-03-28 1:47 GMT+03:00 Richard Weinberger rich...@nod.at: Hi! Am 27.03.2015 um 23:35 schrieb Andrey Wagin: 2015-03-28 0:42 GMT+03:00 Richard Weinberger richard.weinber...@gmail.com: On Fri, Mar 27, 2015 at 9:39 PM, Andrey Vagin ava...@openvz.org wrote: I don't see any reasons to hide them

Re: [PATCH] fs: show locked and lock_ro options in mountinfo

2015-03-28 0:42 GMT+03:00 Richard Weinberger : > On Fri, Mar 27, 2015 at 9:39 PM, Andrey Vagin wrote: >> I don't see any reasons to hide them. This information can help to >> understand errors. > > Because these flags are set/read only internally by the VFS. In contrast > to the other flags shown

Re: [PATCH] fs: show locked and lock_ro options in mountinfo

2015-03-28 0:42 GMT+03:00 Richard Weinberger richard.weinber...@gmail.com: On Fri, Mar 27, 2015 at 9:39 PM, Andrey Vagin ava...@openvz.org wrote: I don't see any reasons to hide them. This information can help to understand errors. Because these flags are set/read only internally by the VFS.

Re: [PATCH v3 1/2] x86_64,signal: Fix SS handling for signals delivered to 64-bit programs

2015-03-18 21:50 GMT+03:00 Cyrill Gorcunov : > 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

Re: [PATCH v3 1/2] x86_64,signal: Fix SS handling for signals delivered to 64-bit programs

2015-03-12 23:57 GMT+03:00 Andy Lutomirski : > From: Andy Lutomirski > > The comment in the signal code says that apps can save/restore other > segments on their own. It's true that apps can *save* SS on their > own, but there's no way for apps to restore it: SYSCALL effectively > resets SS to

Re: [PATCH v3 1/2] x86_64,signal: Fix SS handling for signals delivered to 64-bit programs

2015-03-12 23:57 GMT+03:00 Andy Lutomirski l...@kernel.org: From: Andy Lutomirski l...@amacapital.net The comment in the signal code says that apps can save/restore other segments on their own. It's true that apps can *save* SS on their own, but there's no way for apps to restore it: SYSCALL

Re: [PATCH v3 1/2] x86_64,signal: Fix SS handling for signals delivered to 64-bit programs

2015-03-18 21:50 GMT+03:00 Cyrill Gorcunov gorcu...@gmail.com: 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

Re: [PATCH] selftests/kcmp: exit with non-zero code in a fail case

2015-03-13 13:37 GMT+03:00 Michael Ellerman : > On Fri, 2015-03-13 at 12:27 +0300, Andrey Vagin wrote: >> diff --git a/tools/testing/selftests/kselftest.h >> b/tools/testing/selftests/kselftest.h >> index 572c888..a0ec8b8 100644 >> --- a/tools/testing/selftests/kselftest.h >> +++

Re: [PATCH] selftests/kcmp: exit with non-zero code in a fail case

2015-03-13 13:37 GMT+03:00 Michael Ellerman m...@ellerman.id.au: On Fri, 2015-03-13 at 12:27 +0300, Andrey Vagin wrote: diff --git a/tools/testing/selftests/kselftest.h b/tools/testing/selftests/kselftest.h index 572c888..a0ec8b8 100644 --- a/tools/testing/selftests/kselftest.h +++

Re: [PATCH] proc: show locks in /proc/pid/fdinfo/X

2015-03-12 22:23 GMT+03:00 Andrew Morton : > On Thu, 12 Mar 2015 18:54:42 +0300 Andrew Vagin wrote: > >> v2: use seq_has_overflowed() properly > > --- a/fs/proc/fd.c~proc-show-locks-in-proc-pid-fdinfo-x-v2 > +++ a/fs/proc/fd.c > @@ -57,17 +57,15 @@ static int seq_show(struct seq_file *m, >

Re: [PATCH] proc: show locks in /proc/pid/fdinfo/X

2015-03-12 22:23 GMT+03:00 Andrew Morton a...@linux-foundation.org: On Thu, 12 Mar 2015 18:54:42 +0300 Andrew Vagin ava...@parallels.com wrote: v2: use seq_has_overflowed() properly --- a/fs/proc/fd.c~proc-show-locks-in-proc-pid-fdinfo-x-v2 +++ a/fs/proc/fd.c @@ -57,17 +57,15 @@ static int

Re: [PATCH 2/3 v3] x86: entry_64.S: always allocate complete "struct pt_regs"

2015-02-25 21:42 GMT+03:00 Denys Vlasenko : > On 02/25/2015 01:37 PM, Andrey Wagin wrote: >> 2015-02-13 0:54 GMT+03:00 Denys Vlasenko : >>> 64-bit code was using six stack slots less by not saving/restoring >>> registers which are callee-preserved according to C ABI, &

Re: [PATCH 2/3 v3] x86: entry_64.S: always allocate complete struct pt_regs

2015-02-25 21:42 GMT+03:00 Denys Vlasenko dvlas...@redhat.com: On 02/25/2015 01:37 PM, Andrey Wagin wrote: 2015-02-13 0:54 GMT+03:00 Denys Vlasenko dvlas...@redhat.com: 64-bit code was using six stack slots less by not saving/restoring registers which are callee-preserved according to C ABI

Re: BUG at /build/buildd/linux-3.13.0/fs/pnode.c:372!

2014-10-06 23:44 GMT+04:00 Serge E. Hallyn : > Quoting Andrey Wagin (ava...@gmail.com): >> 2014-10-06 22:19 GMT+04:00 Serge E. Hallyn : >> > Quoting Andrey Wagin (ava...@gmail.com): >> >> Hi All, >> >> >> >> Here is a small program, whi

Re: BUG at /build/buildd/linux-3.13.0/fs/pnode.c:372!

2014-10-06 22:19 GMT+04:00 Serge E. Hallyn : > Quoting Andrey Wagin (ava...@gmail.com): >> Hi All, >> >> Here is a small program, which triggers a bug. Is it interested for someone? > > Yup, would > > diff --git a/fs/namespace.c b/fs/namespace.c > inde

BUG at /build/buildd/linux-3.13.0/fs/pnode.c:372!

Hi All, Here is a small program, which triggers a bug. Is it interested for someone? root@ubuntu:/home/avagin# cat nsenter.c #define _GNU_SOURCE /* See feature_test_macros(7) */ #include #include #include #include #include #include int main(int argc, char **argv) { int

BUG at /build/buildd/linux-3.13.0/fs/pnode.c:372!

Hi All, Here is a small program, which triggers a bug. Is it interested for someone? root@ubuntu:/home/avagin# cat nsenter.c #define _GNU_SOURCE /* See feature_test_macros(7) */ #include sched.h #include sys/types.h #include sys/stat.h #include fcntl.h #include unistd.h #include

Re: BUG at /build/buildd/linux-3.13.0/fs/pnode.c:372!

2014-10-06 22:19 GMT+04:00 Serge E. Hallyn se...@hallyn.com: Quoting Andrey Wagin (ava...@gmail.com): Hi All, Here is a small program, which triggers a bug. Is it interested for someone? Yup, would diff --git a/fs/namespace.c b/fs/namespace.c index ef42d9b..ddef25d 100644 --- a/fs

Re: BUG at /build/buildd/linux-3.13.0/fs/pnode.c:372!

2014-10-06 23:44 GMT+04:00 Serge E. Hallyn se...@hallyn.com: Quoting Andrey Wagin (ava...@gmail.com): 2014-10-06 22:19 GMT+04:00 Serge E. Hallyn se...@hallyn.com: Quoting Andrey Wagin (ava...@gmail.com): Hi All, Here is a small program, which triggers a bug. Is it interested

Does MNT_LOCKED work as expected?

Hi All, I think I found a case, when MNT_LOCKED (5ff9d8a65ce8 "vfs: Lock in place mounts from more privileged users") doesn't help to hide overmounted parts from unprivileged users. The problem exists for mounts, which are not overmounted entirely. In such cases we can open a directory from a

Does MNT_LOCKED work as expected?

Hi All, I think I found a case, when MNT_LOCKED (5ff9d8a65ce8 vfs: Lock in place mounts from more privileged users) doesn't help to hide overmounted parts from unprivileged users. The problem exists for mounts, which are not overmounted entirely. In such cases we can open a directory from a

Re: linux-next: cgroup_mount() falls asleep forever

2014-09-24 14:31 GMT+04:00 Andrey Wagin : > Hi All, > > I execute CRIU tests on linux-next. Today I found that one of tests > hangs up forever. > > [root@linux-next-test linux-next]# git describe HEAD > next-20140922 > [root@linux-next-test ~]# ps axf > ... > 698

Re: linux-next: cgroup_mount() falls asleep forever

2014-09-24 14:31 GMT+04:00 Andrey Wagin : > Hi All, The problem is in a following commit: commit 0c7bf3e8cab7900e17ce7f97104c39927d835469 Author: Zefan Li Date: Sat Sep 20 14:49:10 2014 +0800 cgroup: remove redundant variable in cgroup_mount() Both pinned_sb and new_sb indic

linux-next: cgroup_mount() falls asleep forever

Hi All, I execute CRIU tests on linux-next. Today I found that one of tests hangs up forever. [root@linux-next-test linux-next]# git describe HEAD next-20140922 [root@linux-next-test ~]# ps axf ... 698 ?Ss 0:05 \_ sshd: root@notty 700 ?Ss 0:00 | \_ bash -x

linux-next: cgroup_mount() falls asleep forever

Hi All, I execute CRIU tests on linux-next. Today I found that one of tests hangs up forever. [root@linux-next-test linux-next]# git describe HEAD next-20140922 [root@linux-next-test ~]# ps axf ... 698 ?Ss 0:05 \_ sshd: root@notty 700 ?Ss 0:00 | \_ bash -x

Re: linux-next: cgroup_mount() falls asleep forever

2014-09-24 14:31 GMT+04:00 Andrey Wagin ava...@gmail.com: Hi All, The problem is in a following commit: commit 0c7bf3e8cab7900e17ce7f97104c39927d835469 Author: Zefan Li lize...@huawei.com Date: Sat Sep 20 14:49:10 2014 +0800 cgroup: remove redundant variable in cgroup_mount() Both

Re: linux-next: cgroup_mount() falls asleep forever

2014-09-24 14:31 GMT+04:00 Andrey Wagin ava...@gmail.com: Hi All, I execute CRIU tests on linux-next. Today I found that one of tests hangs up forever. [root@linux-next-test linux-next]# git describe HEAD next-20140922 [root@linux-next-test ~]# ps axf ... 698 ?Ss 0:05

Re: [PATCH] Documentation/video4linux: don't build without CONFIG_VIDEO_V4L2

2014-08-29 0:42 GMT+04:00 Randy Dunlap : > On 08/28/14 13:34, Andrey Vagin wrote: >> Otherwise we get warnings: >> WARNING: "vb2_ops_wait_finish" >> [Documentation//video4linux/v4l2-pci-skeleton.ko] undefined! >> WARNING: "vb2_ops_wait_prepare" >>

Re: [PATCH] Documentation/video4linux: don't build without CONFIG_VIDEO_V4L2

2014-08-29 0:42 GMT+04:00 Randy Dunlap rdun...@infradead.org: On 08/28/14 13:34, Andrey Vagin wrote: Otherwise we get warnings: WARNING: vb2_ops_wait_finish [Documentation//video4linux/v4l2-pci-skeleton.ko] undefined! WARNING: vb2_ops_wait_prepare

Re: [PATCH 2/4] Documentation: add makefiles for more targets

Hi Peter, I have got following errors with this patch. I think Documentation/video4linux should be built only if a config contains a proper options set. Building modules, stage 2. MODPOST 73 modules ERROR: "vb2_ops_wait_finish" [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined!

Re: [PATCH 2/4] Documentation: add makefiles for more targets

Hi Peter, I have got following errors with this patch. I think Documentation/video4linux should be built only if a config contains a proper options set. Building modules, stage 2. MODPOST 73 modules ERROR: vb2_ops_wait_finish [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR:

Re: [PATCH driver-core-linus] kernfs, sysfs, cgroup: restrict extra perm check on open to sysfs

ags. > It works for me. Thank you for the quick response. Tested-by: Andrey Wagin > Signed-off-by: Tejun Heo > Reported-by: Andrey Wagin > Cc: Li Zefan > References: > http://lkml.kernel.org/g/CANaxB-xUm3rJ-Cbp72q-rQJO5mZe1qK6qXsQM=vh0u8upj4...@mail.gmail.com > Fixes: 2bd

Re: [PATCH driver-core-linus] kernfs, sysfs, cgroup: restrict extra perm check on open to sysfs

can perform any operation regardless of the permissions as it was before kernfs conversion. Note that kernfs still fails unimplemented operations with -EINVAL. While at it, add comments explaining KERNFS_ROOT flags. It works for me. Thank you for the quick response. Tested-by: Andrey Wagin

Re: [rfc 2/2] docs: procfs -- Document timerfd output

2014-03-31 21:54 GMT+04:00 Cyrill Gorcunov : > CC: Shawn Landden > CC: Thomas Gleixner > CC: Andrew Morton > CC: Andrey Vagin > CC: Pavel Emelyanov > Signed-off-by: Cyrill Gorcunov > --- > Documentation/filesystems/proc.txt |9 + > 1 file changed, 9 insertions(+) > > Index:

Re: [rfc 2/2] docs: procfs -- Document timerfd output

2014-03-31 21:54 GMT+04:00 Cyrill Gorcunov gorcu...@openvz.org: CC: Shawn Landden sh...@churchofgit.com CC: Thomas Gleixner t...@linutronix.de CC: Andrew Morton a...@linux-foundation.org CC: Andrey Vagin ava...@openvz.org CC: Pavel Emelyanov xe...@parallels.com Signed-off-by: Cyrill Gorcunov

Re: [CRIU] [PATCH 1/3] prctl: reduce permissions to change boundaries of data, brk and stack

2014-02-14 23:16 GMT+04:00 Eric W. Biederman : > Cyrill Gorcunov writes: > >> On Fri, Feb 14, 2014 at 09:43:14PM +0400, Andrew Vagin wrote: >>> > My brain hurts just looking at this patch and how you are justifying it. >>> > >>> > For the resources you are mucking with below all you have to do is

Re: [CRIU] [PATCH 1/3] prctl: reduce permissions to change boundaries of data, brk and stack

2014-02-14 23:16 GMT+04:00 Eric W. Biederman ebied...@xmission.com: Cyrill Gorcunov gorcu...@gmail.com writes: On Fri, Feb 14, 2014 at 09:43:14PM +0400, Andrew Vagin wrote: My brain hurts just looking at this patch and how you are justifying it. For the resources you are mucking with

Re: [PATCH] netfilter: nf_conntrack: fix RCU race in nf_conntrack_find_get (v3)

> > Eh, looks like this path is incomplete too:( > > I think we can't set a reference counter for objects which is allocated > from a SLAB_DESTROY_BY_RCU cache. Look at the following backtrace. > > cpu1cpu2 > ct = nf_conntrack_find() >

Re: [PATCH] netfilter: nf_conntrack: fix RCU race in nf_conntrack_find_get (v3)

Eh, looks like this path is incomplete too:( I think we can't set a reference counter for objects which is allocated from a SLAB_DESTROY_BY_RCU cache. Look at the following backtrace. cpu1cpu2 ct = nf_conntrack_find()

Re: [PATCH] netfilter: nf_conntrack: fix RCU race in nf_conntrack_find_get

2014/1/9 Eric Dumazet : > On Thu, 2014-01-09 at 09:24 +0400, Andrew Vagin wrote: > >> I have one more question. Looks like I found another problem. >> >> init_conntrack: >> hlist_nulls_add_head_rcu(>tuplehash[IP_CT_DIR_ORIGINAL].hnnode, >> >ct.unconfirmed); >> >>

Re: [PATCH] netfilter: nf_conntrack: fix RCU race in nf_conntrack_find_get

2014/1/9 Eric Dumazet eric.duma...@gmail.com: On Thu, 2014-01-09 at 09:24 +0400, Andrew Vagin wrote: I have one more question. Looks like I found another problem. init_conntrack: hlist_nulls_add_head_rcu(ct-tuplehash[IP_CT_DIR_ORIGINAL].hnnode,

Re: [PATCH] netfilter: nf_conntrack: release conntrack from rcu callback

Hi Florian, 2014/1/7 Florian Westphal : > Andrew Vagin wrote: >> > ct = nf_ct_tuplehash_to_ctrack(h); >> > if (unlikely(nf_ct_is_dying(ct) || >> > !atomic_inc_not_zero(>ct_general.use))) >> > // which means we

Re: [PATCH] netfilter: nf_conntrack: release conntrack from rcu callback

Hi Florian, 2014/1/7 Florian Westphal f...@strlen.de: Andrew Vagin ava...@gmail.com wrote: ct = nf_ct_tuplehash_to_ctrack(h); if (unlikely(nf_ct_is_dying(ct) || !atomic_inc_not_zero(ct-ct_general.use))) //

Re: [CRIU] [PATCH] timerfd: show procfs fdinfo helper

2013/12/24 Shawn Landden : > | pos: 0 > | flags:02004002 > | clockid: 0 > > Cc: Thomas Gleixner > Cc: Alexander Viro > Signed-off-by: Shawn Landden > --- > fs/timerfd.c | 17 + > 1 file changed, 17 insertions(+) > > diff --git a/fs/timerfd.c b/fs/timerfd.c > index

Re: [CRIU] [PATCH] timerfd: show procfs fdinfo helper

2013/12/24 Shawn Landden sh...@churchofgit.com: | pos: 0 | flags:02004002 | clockid: 0 Cc: Thomas Gleixner t...@linutronix.de Cc: Alexander Viro v...@zeniv.linux.org.uk Signed-off-by: Shawn Landden sh...@churchofgit.com --- fs/timerfd.c | 17 + 1 file

Re: [PATCH] thp: move preallocated PTE page table on move_huge_pmd()

2013/12/4 Kirill A. Shutemov : > Andrey Wagin reported crash on VM_BUG_ON() in pgtable_pmd_page_dtor() > with fallowing backtrace: > > [] free_pgd_range+0x2bf/0x410 > [] free_pgtables+0xce/0x120 > [] unmap_region+0xe0/0x120 > [] ? move_page_tables+0x526/0x6b0 >

Re: [PATCH] thp: move preallocated PTE page table on move_huge_pmd()

2013/12/4 Kirill A. Shutemov kirill.shute...@linux.intel.com: Andrey Wagin reported crash on VM_BUG_ON() in pgtable_pmd_page_dtor() with fallowing backtrace: [8119427f] free_pgd_range+0x2bf/0x410 [8119449e] free_pgtables+0xce/0x120 [8119b900] unmap_region+0xe0

Re: [PATCH 34/34] mm: dynamically allocate page->ptl if it cannot be embedded to struct page

2013/11/20 Kirill A. Shutemov : > Andrey Wagin wrote: >> 2013/11/20 Kirill A. Shutemov : >> > Andrey Wagin wrote: >> >> Hi Kirill, >> >> >> >> Looks like this patch adds memory leaks. >> >> [ 116.188310] kmemleak: 1567

Re: [PATCH 34/34] mm: dynamically allocate page->ptl if it cannot be embedded to struct page

2013/11/20 Kirill A. Shutemov : > Andrey Wagin wrote: >> Hi Kirill, >> >> Looks like this patch adds memory leaks. >> [ 116.188310] kmemleak: 15672 new suspected memory leaks (see >> /sys/kernel/debug/kmemleak) >> unreferenced object 0x8800da45a350 (siz

Re: [PATCH 34/34] mm: dynamically allocate page->ptl if it cannot be embedded to struct page

Hi Kirill, Looks like this patch adds memory leaks. [ 116.188310] kmemleak: 15672 new suspected memory leaks (see /sys/kernel/debug/kmemleak) unreferenced object 0x8800da45a350 (size 96): comm "dracut-initqueu", pid 93, jiffies 4294671391 (age 362.277s) hex dump (first 32 bytes): 07

Re: [PATCH 34/34] mm: dynamically allocate page-ptl if it cannot be embedded to struct page

Hi Kirill, Looks like this patch adds memory leaks. [ 116.188310] kmemleak: 15672 new suspected memory leaks (see /sys/kernel/debug/kmemleak) unreferenced object 0x8800da45a350 (size 96): comm dracut-initqueu, pid 93, jiffies 4294671391 (age 362.277s) hex dump (first 32 bytes): 07 00

Re: [PATCH 34/34] mm: dynamically allocate page-ptl if it cannot be embedded to struct page

2013/11/20 Kirill A. Shutemov kirill.shute...@linux.intel.com: Andrey Wagin wrote: Hi Kirill, Looks like this patch adds memory leaks. [ 116.188310] kmemleak: 15672 new suspected memory leaks (see /sys/kernel/debug/kmemleak) unreferenced object 0x8800da45a350 (size 96): comm dracut

Re: [PATCH 34/34] mm: dynamically allocate page-ptl if it cannot be embedded to struct page

2013/11/20 Kirill A. Shutemov kirill.shute...@linux.intel.com: Andrey Wagin wrote: 2013/11/20 Kirill A. Shutemov kirill.shute...@linux.intel.com: Andrey Wagin wrote: Hi Kirill, Looks like this patch adds memory leaks. [ 116.188310] kmemleak: 15672 new suspected memory leaks (see

Re: [PATCH] [RFC] kmemcg: remove union from memcg_params

2013/8/13 Andrew Morton : > On Fri, 9 Aug 2013 00:51:26 +0400 Andrey Vagin wrote: > >> struct memcg_cache_params { >> bool is_root_cache; >> union { >> struct kmem_cache *memcg_caches[0]; >> struct { >> struct mem_cgroup

Re: [PATCH] [RFC] kmemcg: remove union from memcg_params

2013/8/13 Andrew Morton a...@linux-foundation.org: On Fri, 9 Aug 2013 00:51:26 +0400 Andrey Vagin ava...@openvz.org wrote: struct memcg_cache_params { bool is_root_cache; union { struct kmem_cache *memcg_caches[0]; struct {

Re: [PATCH] [RFC] mnt: restrict a number of "struct mnt"

On Tue, Jun 18, 2013 at 02:56:51AM +0400, Andrey Wagin wrote: > 2013/6/17 Eric W. Biederman : > > So for anyone seriously worried about this kind of thing in general we > > already have the memory control group, which is quite capable of > > limiting this kind of thing, >

Re: [PATCH] [RFC] mnt: restrict a number of struct mnt

On Tue, Jun 18, 2013 at 02:56:51AM +0400, Andrey Wagin wrote: 2013/6/17 Eric W. Biederman ebied...@xmission.com: So for anyone seriously worried about this kind of thing in general we already have the memory control group, which is quite capable of limiting this kind of thing

Re: [PATCH] [RFC] mnt: restrict a number of "struct mnt"

2013/6/17 Eric W. Biederman : > Andrey Vagin writes: > >> I found that a few processes can eat all host memory and nobody can kill >> them. >> $ mount -t tmpfs xxx /mnt >> $ mount --make-shared /mnt >> $ for i in `seq 30`; do mount --bind /mnt `mktemp -d /mnt/test.XX` & done >> >> All this

Re: [PATCH] [RFC] mnt: restrict a number of struct mnt

2013/6/17 Eric W. Biederman ebied...@xmission.com: Andrey Vagin ava...@openvz.org writes: I found that a few processes can eat all host memory and nobody can kill them. $ mount -t tmpfs xxx /mnt $ mount --make-shared /mnt $ for i in `seq 30`; do mount --bind /mnt `mktemp -d

Re: [PATCH 1/1] move exit_task_namespaces() outside of exit_notify()

2013/4/13 Oleg Nesterov > > exit_notify() does exit_task_namespaces() after > forget_original_parent(). This was needed to ensure that ->nsproxy > can't be cleared prematurely, an exiting child we are going to > reparent can do do_notify_parent() and use the parent's (ours) pid_ns. > > However,

Re: [PATCH 1/1] move exit_task_namespaces() outside of exit_notify()

2013/4/13 Oleg Nesterov o...@redhat.com exit_notify() does exit_task_namespaces() after forget_original_parent(). This was needed to ensure that -nsproxy can't be cleared prematurely, an exiting child we are going to reparent can do do_notify_parent() and use the parent's (ours) pid_ns.

Re: [PATCH] ptrace: add ability to retrieve signals without removing from a queue (v2)

Andrew, thank you for the comments. I will fix them and send a new patch. A few comments are inline. 2013/2/26 Andrew Morton : > On Mon, 25 Feb 2013 14:06:53 +0400 >> + for (i = 0; i < arg.nr; i++) { >> + off = arg.off + i; > > "long long" = "u64" + "int". > > Wanna have a little

Re: [PATCH] ptrace: add ability to retrieve signals without removing from a queue (v2)

2013/2/25 Pavel Emelyanov : >> + for (i = 0; i < arg.nr; i++) { >> + off = arg.off + i; >> + >> + spin_lock_irq(>sighand->siglock); >> + list_for_each_entry(q, >list, list) { >> + if (!off--) { >> +

Re: [PATCH] ptrace: add ability to retrieve signals without removing from a queue (v2)

Andrew, thank you for the comments. I will fix them and send a new patch. A few comments are inline. 2013/2/26 Andrew Morton a...@linux-foundation.org: On Mon, 25 Feb 2013 14:06:53 +0400 + for (i = 0; i arg.nr; i++) { + off = arg.off + i; long long = u64 + int. Wanna have

Re: [PATCH] ptrace: add ability to retrieve signals without removing from a queue (v2)

2013/2/25 Pavel Emelyanov xe...@parallels.com: + for (i = 0; i arg.nr; i++) { + off = arg.off + i; + + spin_lock_irq(child-sighand-siglock); + list_for_each_entry(q, pending-list, list) { + if (!off--) { +

Re: [PATCH] ptrace: add ability to retrieve signals without removing them from a queue

2013/2/16 Pedro Alves : > Forgot to reply to this bit: > > On 02/15/2013 07:43 PM, Oleg Nesterov wrote: >>> We'd miss the poke >>> > variant, but that looks like something that could be always be added >>> > later. >> Yes. _POKE_ or _QUEUE_ or _DEQUEUE_, we can add more features if user- >> space

Re: [PATCH] ptrace: add ability to retrieve signals without removing them from a queue

2013/2/16 Pedro Alves pal...@redhat.com: Forgot to reply to this bit: On 02/15/2013 07:43 PM, Oleg Nesterov wrote: We'd miss the poke variant, but that looks like something that could be always be added later. Yes. _POKE_ or _QUEUE_ or _DEQUEUE_, we can add more features if user- space

Re: [PATCH 3/3] signalfd: add ability to read siginfo-s without dequeuing signals (v2)

2013/2/7 Oleg Nesterov : > Andrey, sorry for delay. > > As for API, I leave this to you and Michael. Not that I like these > new flags, but I agree that pread() hack was not pretty too. > > On 01/29, Andrey Vagin wrote: >> +static ssize_t signalfd_peek(struct signalfd_ctx *ctx, >> +

Re: [PATCH 3/3] signalfd: add ability to read siginfo-s without dequeuing signals (v2)

2013/2/7 Oleg Nesterov o...@redhat.com: Andrey, sorry for delay. As for API, I leave this to you and Michael. Not that I like these new flags, but I agree that pread() hack was not pretty too. On 01/29, Andrey Vagin wrote: +static ssize_t signalfd_peek(struct signalfd_ctx *ctx, +

Re: [PATCH 3/3] signalfd: add ability to read siginfo-s without dequeuing signals (v2)

2013/2/2 Michael Kerrisk (man-pages) : > > On Jan 30, 2013 8:05 AM, "Andrey Vagin" wrote: >> >> If signalfd is created with the flag SFD_PEEK, it reads siginfo-s >> without dequeuing signals. >> >> For reading not first siginfo pread(fd, buf, size, pos) can be used, >> where ppos /

Re: [PATCH 3/3] signalfd: add ability to read siginfo-s without dequeuing signals (v2)

2013/2/2 Michael Kerrisk (man-pages) mtk.manpa...@gmail.com: On Jan 30, 2013 8:05 AM, Andrey Vagin ava...@openvz.org wrote: If signalfd is created with the flag SFD_PEEK, it reads siginfo-s without dequeuing signals. For reading not first siginfo pread(fd, buf, size, pos) can be used,

  1   2   >