On 10/11/2016 10:36 AM, Nikolay Borisov wrote:
> This patchset converts inotify to using the newly introduced
> per-userns sysctl infrastructure.
>
> Currently the inotify instances/watches are being accounted in the
> user_struct structure. This means that in setups where mult
e with the
mutex locking code, since they both fiddle with the task state.
Fix the issue by using the newly-added nested blocking infrastructure
in 61ada528dea0 ("sched/wait: Provide infrastructure to deal with
nested blocking")
Link: https://lwn.net/Articles/628628/
Signed-off-by: Nikolay B
e with the
mutex locking code, since they both fiddle with the task state.
Fix the issue by using the newly-added nested blocking infrastructure
in 61ada528dea0 ("sched/wait: Provide infrastructure to deal with
nested blocking")
Link: https://lwn.net/Articles/628628/
Signed-off-by: Nikolay B
limits, which can further be tuned inside every
individual user namespace. Additionally, in order to preserve the
sysctl ABI make the existing inotify instances/watches sysctls
modify the values of the initial user namespace.
Signed-off-by: Nikolay Borisov
---
So here is a revised version which
On Mon, Oct 10, 2016 at 11:49 PM, Eric W. Biederman
wrote:
> Jan Kara writes:
>
>> On Mon 10-10-16 09:44:19, Nikolay Borisov wrote:
>>> On 10/07/2016 09:14 PM, Eric W. Biederman wrote:
>>> > Nikolay Borisov writes:
>>> >
>>> >>
On 10/10/2016 04:11 PM, Yan, Zheng wrote:
>
>> On 10 Oct 2016, at 20:56, Nikolay Borisov wrote:
>>
>> In case __ceph_do_getattr returns an error and the retry_op in
>> ceph_read_iter is not READ_INLINE, then it's possible to invoke
>> __free_page on a pa
is by explicitly checking whether the page is set or not.
Signed-off-by: Nikolay Borisov
Link: http://www.spinics.net/lists/ceph-users/msg31592.html
---
Inverted the condition, so resending with correct condition
this time.
fs/ceph/file.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
is by explicitly checking whether the page is set or not.
Signed-off-by: Nikolay Borisov
Link: http://www.spinics.net/lists/ceph-users/msg31592.html
---
fs/ceph/file.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/ceph/file.c b/fs/ceph/file.c
index 3c68e6aee2f0..7413313
On 10/07/2016 09:14 PM, Eric W. Biederman wrote:
> Nikolay Borisov writes:
>
>> This patchset converts inotify to using the newly introduced
>> per-userns sysctl infrastructure.
>>
>> Currently the inotify instances/watches are being accounted in the
>> us
limits, which can further be tuned inside every
individual user namespace.
Signed-off-by: Nikolay Borisov
---
Hello Eric,
I saw you've finally sent your pull request for 4.9 and it
includes your implementatino of the ucount infrastructure. So
here is my respin of the inotify patches using
On 10/06/2016 03:45 PM, Paul E. McKenney wrote:
> On Wed, Oct 05, 2016 at 05:18:09PM +0300, Nikolay Borisov wrote:
>>
>>
>> On 10/05/2016 05:03 PM, Paul E. McKenney wrote:
>>> On Wed, Oct 05, 2016 at 10:06:21AM +0300, Nikolay Borisov wrote:
>>>> Explic
On 10/05/2016 05:03 PM, Paul E. McKenney wrote:
> On Wed, Oct 05, 2016 at 10:06:21AM +0300, Nikolay Borisov wrote:
>> Explicitly state that enabling RCU_TRACE enables more
>> tracepoints and not just "additional tracing".
>>
>> Signed-off-by: Nik
Explicitly state that enabling RCU_TRACE enables more
tracepoints and not just "additional tracing".
Signed-off-by: Nikolay Borisov
---
Hello Paul,
Following our latest conversation re. enabling RCU tracing
I had to actually go and look into the code to see which
option e
Hello Peter,
I've emailed you before re. spurious hangs in the TTY layer, but
at that time I was running a rather old (but LTS) 3.12 kernel. Now,
I'm running a 4.4.10 and I still observe the following lock-ups.
I have multiple processes which hang with the following callstack:
[4592064.96744
Commit-ID: 08645077b7f9f7824dbaf1959b0e014a894c8acc
Gitweb: http://git.kernel.org/tip/08645077b7f9f7824dbaf1959b0e014a894c8acc
Author: Nikolay Borisov
AuthorDate: Mon, 26 Sep 2016 21:11:18 +0300
Committer: Ingo Molnar
CommitDate: Fri, 30 Sep 2016 10:56:01 +0200
x86/cmpxchg, locking
On 09/29/2016 04:14 PM, Nikolay Borisov wrote:
> From: Nikolay Borisov
>
> In some situation it might be useful to disable checking the
> kernel release. This happens when a kernel module is being rebuilt
> and then probed. Without this override one has to reboot the machine
ch in turn block
synchronize_rcu operations, which more or less de-stabilises
the whole system.
Fix this by introducing a cond_resched at the beginning
of the loop.
Signed-off-by: Nikolay Borisov
---
So this patch fixes the following:
NMI watchdog: BUG: soft lockup - CPU#10 stuck for 23s! [h
From: Nikolay Borisov
In some situation it might be useful to disable checking the
kernel release. This happens when a kernel module is being rebuilt
and then probed. Without this override one has to reboot the machine
with the new kernel (and module) and then use systemtap.
To rectify the
[Added Dave Miller to see what's the status of this patch]
On 08/30/2016 12:18 PM, Miklos Szeredi wrote:
> On Tue, Aug 30, 2016 at 12:37 AM, Miklos Szeredi wrote:
>> On Sat, Aug 27, 2016 at 11:55 AM, Miklos Szeredi wrote:
>
>> crash> list -H gc_inflight_list unix_sock.link -s unix_sock.inflight
cmpxchg contained definitions for unused (x)add_* operations, dating back
to the original ticket spinlock implementation. Nowadays these are
unused so remove them.
Signed-off-by: Nikolay Borisov
---
arch/x86/include/asm/cmpxchg.h | 44 --
1 file changed
On 25.09.2016 15:40, Tomasz Chmielewski wrote:
> On 2016-09-25 18:29, Tomasz Chmielewski wrote:
>
>>> I'll try to bisect.
>>
>> OK, not a kernel regression, but some config change caused it.
>> However, I'm not able to locate which change exactly.
>>
>> I'm attaching two configs which I've tried
On Wed, Sep 14, 2016 at 3:58 PM, Oleg Nesterov wrote:
> On 09/14, Nikolay Borisov wrote:
>>
>> [ 557.006656] [] dump_stack+0x6b/0xa0
>> [ 557.012737] [] warn_slowpath_common+0x95/0xe0
>> [ 557.019781] [] warn_slowpath_null+0x1a/0x20
>> [ 557.02664
On 09/13/2016 06:20 PM, Oleg Nesterov wrote:
> On 09/13, Nikolay Borisov wrote:
>>
>> On 09/13/2016 05:35 PM, Nikolay Borisov wrote:
>>>
>>> On 09/13/2016 04:43 PM, Oleg Nesterov wrote:
>>>> On 09/13, Oleg Nesterov wrote:
>>>>>
>&g
On 09/13/2016 05:38 PM, Nikolay Borisov wrote:
>
>
> On 09/13/2016 05:35 PM, Nikolay Borisov wrote:
>>
>>
>> On 09/13/2016 04:43 PM, Oleg Nesterov wrote:
>>> On 09/13, Oleg Nesterov wrote:
>>>>
>>>> OK... perhaps the unbal
On 09/13/2016 04:43 PM, Oleg Nesterov wrote:
> On 09/13, Oleg Nesterov wrote:
>>
>> OK... perhaps the unbalanced up_write... I'll try to look at freeze/thaw
>> code,
>
> Heh, yes, it looks racy or I am totally confused.
>
>> could test the debugging patch below meanwhile?
>
> Yes please. I'll
On 09/13/2016 05:35 PM, Nikolay Borisov wrote:
>
>
> On 09/13/2016 04:43 PM, Oleg Nesterov wrote:
>> On 09/13, Oleg Nesterov wrote:
>>>
>>> OK... perhaps the unbalanced up_write... I'll try to look at freeze/thaw
>>> code,
>>
>> Heh
On 09/12/2016 04:01 PM, Oleg Nesterov wrote:
> Hi Nikolay,
>
[SNIP..]
>>
>>
>> The bug on in question is this: BUG_ON(rsp->gp_state != GP_PASSED);
>>
>> Have you seen something like that before - the kernel is fairly old 4.4.2,
>
> No... thanks, I'll try to look tomorrow.
I just re-run the tes
On 08/24/2016 07:40 PM, Tejun Heo wrote:
> Hello, Alexander.
>
> On Wed, Aug 24, 2016 at 06:37:35PM +0200, Alexander Potapenko wrote:
>> Commit the script that symbolizes BUG messages and KASAN error reports
>> by adding file:line information to each stack frame.
>> The script is a copy of
>> ht
On 08/30/2016 12:18 PM, Miklos Szeredi wrote:
> On Tue, Aug 30, 2016 at 12:37 AM, Miklos Szeredi wrote:
>> On Sat, Aug 27, 2016 at 11:55 AM, Miklos Szeredi wrote:
>
>> crash> list -H gc_inflight_list unix_sock.link -s unix_sock.inflight |
>> grep counter | cut -d= -f2 | awk '{s+=$1} END {print
On Thu, Aug 25, 2016 at 12:40 AM, Hannes Frederic Sowa
wrote:
> On 24.08.2016 16:24, Nikolay Borisov wrote:
[SNIP]
>
> One commit which could have to do with that is
>
> commit fc64869c48494a401b1fb627c9ecc4e6c1d74b0d
> Author: Andrey Ryabinin
> Date: Wed May 18 19:19:27 2
Hello,
I hit the following BUG:
[1851513.239831] [ cut here ]
[1851513.240079] kernel BUG at net/unix/garbage.c:149!
[1851513.240313] invalid opcode: [#1] SMP
[1851513.248320] CPU: 37 PID: 11683 Comm: nginx Tainted: G O
4.4.14-clouder3 #26
[1851513.24
On 22.08.2016 19:44, Paul E. McKenney wrote:
> On Mon, Aug 22, 2016 at 07:19:53PM +0300, Nikolay Borisov wrote:
>>
>> [SNIP]
>>>
>>> Signed-off-by: Ding Tianhong
>>> [ paulmck: Substituted cond_resched_rcu_qs for cond_resched. ]
>>
>> This
[SNIP]
>
> Signed-off-by: Ding Tianhong
> [ paulmck: Substituted cond_resched_rcu_qs for cond_resched. ]
This contradicts...
> Signed-off-by: Paul E. McKenney
> ---
> kernel/rcu/tree_plugin.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree
On 20.08.2016 20:03, T. Smith wrote:
> The goal is to isolate causes of indeterminism when using the PREEMPT_RT
> kernel configuration with full preemption and to characterize latency and
> jitter using ftrace, any recommendations?
What hardware is it ? If it's x86 it's entirely possible you a
On 08/04/2016 06:29 PM, Jiri Olsa wrote:
> On Tue, Jul 26, 2016 at 02:30:46PM +0300, Nikolay Borisov wrote:
[SNIP]
>
> sorry for late response..
>
> I checked on f22 kernel and it's missing the core2 PEBs fix:
> 1424a09a9e18 perf/x86: fix PEBS issues on Intel At
On 08/03/2016 06:06 PM, J. Bruce Fields wrote:
> Digging around... Oh, I see, there's an optional 'lock:..' line in
> /proc/[pid]/fdinfo/[pid] file, is that what you're looking at? I'd
> forgotten. Yeah, maybe that would make more sense long term.
Yep, that's the one but this requires the use
On 08/03/2016 05:54 PM, Pavel Emelyanov wrote:
> On 08/03/2016 05:17 PM, Nikolay Borisov wrote:
>>
>>
[SNIP]
>>
>> [CCing some people from openvz/CRIU]
>
> Thanks :)
>
>> My train of thought was "we should have means which would be the one
>&g
On 08/03/2016 05:28 PM, J. Bruce Fields wrote:
> On Wed, Aug 03, 2016 at 05:17:09PM +0300, Nikolay Borisov wrote:
>>
>>
>> On 08/03/2016 04:46 PM, Jeff Layton wrote:
>>> On Wed, 2016-08-03 at 10:35 +0300, Nikolay Borisov wrote:
>>>> On busy container
On 08/03/2016 04:46 PM, Jeff Layton wrote:
> On Wed, 2016-08-03 at 10:35 +0300, Nikolay Borisov wrote:
>> On busy container servers reading /proc/locks shows all the locks
>> created by all clients. This can cause large latency spikes. In my
>> case I observed lsof taki
one the proc was mounted in. When reading
/proc/locks from the init_pid_ns show everything.
Signed-off-by: Nikolay Borisov
---
fs/locks.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/fs/locks.c b/fs/locks.c
index ee1b15f6fc13..751673d7f7fc 100644
--- a/fs/locks.c
+++ b/fs/locks.c
gt; >
>> > > On Tue, Aug 02, 2016 at 11:00:39AM -0500, Eric W. Biederman wrote:
>> > > >
>> > > > > > > > Nikolay Borisov writes:
>> > > >
>> > > > >
>> > > > > Currently when /proc/locks is read
On 08/02/2016 06:05 PM, J. Bruce Fields wrote:
> On Tue, Aug 02, 2016 at 05:42:23PM +0300, Nikolay Borisov wrote:
>> Currently when /proc/locks is read it will show all the file locks
>> which are currently created on the machine. On containers, hosted
>> on busy servers
of relevant entries. Fix it by
filtering the locks listed by the pidns of the current process
and the process which created the lock.
Signed-off-by: Nikolay Borisov
---
fs/locks.c | 8
1 file changed, 8 insertions(+)
diff --git a/fs/locks.c b/fs/locks.c
index 6333263b7bc8..53e96df4c583
On 08/02/2016 05:42 PM, Nikolay Borisov wrote:
> Currently when /proc/locks is read it will show all the file locks
> which are currently created on the machine. On containers, hosted
> on busy servers this means that doing lsof can be very slow. I
> observed up to 5 seconds stalls
On 07/20/2016 05:38 PM, Jiri Olsa wrote:
> On Wed, Jul 20, 2016 at 04:34:17PM +0200, Jiri Olsa wrote:
>> On Wed, Jul 20, 2016 at 04:28:34PM +0300, Nikolay Borisov wrote:
>>> Hello,
>>>
>>> Running perf version 4.4.14.g0cb188d (no modification to the PMU/perf
by removing the reclaimable flag for the file's cache.
Signed-off-by: Nikolay Borisov
---
Fixed checkpatch warning + missing SOB line
fs/ceph/super.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/ceph/super.c b/fs/ceph/super.c
index 91e02481ce06..8697cac6add0 1
Ceph creates multiple caches with the SLAB_RECLAIMABLE flag set, so
that it can satisfy its internal needs. Inspecting the code shows that
most of the caches are indeed reclaimable since they are directly
related to the generic inode/dentry shrinkers. However, one of the
cache used to satisfy struc
On 07/20/2016 05:34 PM, Jiri Olsa wrote:
> On Wed, Jul 20, 2016 at 04:28:34PM +0300, Nikolay Borisov wrote:
>> Hello,
>>
>> Running perf version 4.4.14.g0cb188d (no modification to the PMU/perf
>> code) I observed that "perf top" counts no cycles and produ
Hello,
Running perf version 4.4.14.g0cb188d (no modification to the PMU/perf
code) I observed that "perf top" counts no cycles and produces no
output. After a bit of head scratching and testing I figured that
running "perf top -e cycles" actually works whereas the default option
is equivalent to r
On 07/14/2016 02:12 PM, Biscuit Ninja wrote:
>> A softlockup in shrink_dentry_list when called from shrink_dcache_sb
>> was observed on a very busy server. It's possible that the list
>> passed to shrink_dentry_list is so big that it takes a while to
>> dispose of all entries. Adding a simple con
On 07/12/2016 02:47 PM, Peter Zijlstra wrote:
> On Tue, Jul 12, 2016 at 02:56:17PM +0530, Aravinda Prasad wrote:
>>
>>
>> On Monday 27 June 2016 09:20 PM, Peter Zijlstra wrote:
>>> On Tue, Jun 14, 2016 at 10:19:51PM +0530, Aravinda Prasad wrote:
Whenever perf tool is executed inside a contai
On 07/07/2016 01:17 PM, Wei Jiangang wrote:
> If we specify the 'notsc' boot parameter for the dump-capture kernel,
> and then trigger a crash(panic) by using "ALT-SysRq-c" or "echo c >
> /proc/sysrq-trigger",
> the dump-capture kernel will hang in calibrate_delay_converge():
>
> /* wait for
On 07/07/2016 04:19 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.15 release.
> There are 32 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
Greg, I'd like
After some days of inactivity a gentle ping is in order.
On 06/23/2016 09:17 PM, Nikolay Borisov wrote:
> BTRFS is using a variety of slab caches to satisfy internal needs.
> Those slab caches are always allocated with the SLAB_RECLAIM_ACCOUNT,
> meaning allocations from the caches are
On 06/30/2016 10:35 PM, r...@redhat.com wrote:
> Currently irq time accounting only works in these cases:
> 1) purely ticke based accounting
> 2) nohz_full accounting, but only on housekeeping & nohz_full CPUs
> 3) architectures with native vtime accounting
>
> On nohz_idle CPUs, which are proba
On 07/01/2016 08:38 PM, Tejun Heo wrote:
> On Fri, Jul 01, 2016 at 12:00:50PM +0200, Jan Kara wrote:
>> Hello,
>>
>> On Thu 30-06-16 14:18:14, Nikolay Borisov wrote:
>>> In light of the discussion in https://patchwork.kernel.org/patch/9187411/
>>>
Hello,
In light of the discussion in https://patchwork.kernel.org/patch/9187411/ and
the discussion at https://groups.google.com/forum/#!topic/syzkaller/XvxH3cBQ134
I think the following might be related:
[1416412.898946] BUG: unable to handle kernel NULL pointer dereference at
00
On 06/29/2016 05:00 PM, Christoph Lameter wrote:
> On Wed, 29 Jun 2016, Nikolay Borisov wrote:
>
>> I've observed a rather strange unbounded growth of the kmalloc-192
>> slab cache:
>>
>> OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME
>> 7
Hello Christoph,
I've observed a rather strange unbounded growth of the kmalloc-192
slab cache:
OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME
711124869 411527215 3%0.19K 16934908 42 135479264K kmalloc-192
Essentially the kmalloc is around 130 GB , ye
to vfs calling into btrfs_evict_inode.
This leads to null pointer dereference. To handle this situation check whether
the passed inode has root set and just free it in case it doesn't.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/inode.c | 9 -
1 file changed, 8 insertions(+), 1
On 06/24/2016 02:37 AM, Byungchul Park wrote:
> On Mon, Jun 20, 2016 at 01:55:15PM +0900, Byungchul Park wrote:
>
> Hello,
>
> I have a plan to resend this patchset after reinforcement of
> documentation. However I am wondering what you think about the
> main concept of this. A main motivation
SLAB_TEMPORARY,
to better document the lifetime of the objects (it just translates
to SLAB_RECLAIM_ACCOUNT).
Signed-off-by: Nikolay Borisov
---
fs/btrfs/backref.c | 2 +-
fs/btrfs/delayed-inode.c | 2 +-
fs/btrfs/delayed-ref.c | 8
fs/btrfs/disk-io.c | 2 +-
fs/btrfs/extent_io.c
On 06/17/2016 07:25 PM, Johannes Weiner wrote:
> The memory controller has quite a bit of state that usually outlives
> the cgroup and pins its CSS until said state disappears. At the same
> time it imposes a 16-bit limit on the CSS ID space to economically
> store IDs in the wild. Consequently,
Python doesn't do automatic expansion of paths. In case one passes
path of the from ~/foo/bar the gdb scripts won't automatically expand
that and as a result the symbols files won't be loaded. Fix this
by explicitly expanding all paths which begin with "~"
Signe
On 06/08/2016 12:35 PM, Jan Kiszka wrote:
> On 2016-06-07 23:26, Nikolay Borisov wrote:
>> Python doesn't do automatic expansion of paths. In case one passes
>> path of the from ~/foo/bar the gdb scripts won't automatically expand
>> that and as a result the sym
Python doesn't do automatic expansion of paths. In case one passes
path of the from ~/foo/bar the gdb scripts won't automatically expand
that and as a result the symbols files won't be loaded. Fix this
by explicitly expanding all paths which begin with "~"
Signe
On 06/07/2016 05:17 AM, Wei Tang wrote:
> This patch fixes the checkpatch.pl error to inotify_fsnotify.c:
>
> ERROR: do not initialise statics to false
So if a variable is declared as static this means it's going to live in
the BSS which is zeroed out on load. So implicitly it is going to be 0,
On 06/06/2016 11:05 AM, Cyrill Gorcunov wrote:
> On Wed, Jun 01, 2016 at 10:52:57AM +0300, Nikolay Borisov wrote:
>> This patch adds the necessary members to user_struct. The idea behind
>> the solution is really simple - user the userns pointers as keys into
>> a hash
On 06/03/2016 11:41 PM, Eric W. Biederman wrote:
> Nikolay Borisov writes:
>
>> On 06/02/2016 07:58 PM, Eric W. Biederman wrote:
>>>
>>> Nikolay please see my question for you at the end.
> [snip]
>>> All of that said there is definitely a pra
On 06/02/2016 07:58 PM, Eric W. Biederman wrote:
>
> Nikolay please see my question for you at the end.
>
> Jan Kara writes:
>
>> On Wed 01-06-16 11:00:06, Eric W. Biederman wrote:
>>> Cc'd the containers list.
>>>
>>> Nikolay Borisov wri
On 06/01/2016 07:00 PM, Eric W. Biederman wrote:
> Cc'd the containers list.
>
>
> Nikolay Borisov writes:
>
>> Currently the inotify instances/watches are being accounted in the
>> user_struct structure. This means that in setups where multiple
>> u
Signed-off-by: Nikolay Borisov
---
fs/notify/inotify/inotify_fsnotify.c | 14 +-
fs/notify/inotify/inotify_user.c | 23 +++
include/linux/sched.h| 2 --
3 files changed, 28 insertions(+), 11 deletions(-)
diff --git a/fs/notify/inotify
it's needed so that building the kernel
with !CONFIG_INOTIFY_USER doesn't fail (with patch 1 being applied).
However, fdinfo.c doesn't really need inotify.h
Nikolay Borisov (4):
inotify: Add infrastructure to account inotify limits per-namespace
inotify: Convert inotify limits t
scenarios such as a single mapped user in a
container deplete the inotify resources for all other users, which
map to the exact same real user.
Signed-off-by: Nikolay Borisov
---
fs/notify/inotify/inotify.h | 68
fs/notify/inotify/inotify_user.c | 36
Signed-off-by: Nikolay Borisov
---
fs/notify/fdinfo.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/notify/fdinfo.c b/fs/notify/fdinfo.c
index fd98e5100cab..62068f89d144 100644
--- a/fs/notify/fdinfo.c
+++ b/fs/notify/fdinfo.c
@@ -13,7 +13,10 @@
#include
#include
+#ifdef
This change is required since the inotify-per-namespace code added
hashtable.h to the include list of sched.h. This in turn causes
compiler warnings since HASH_SIZE is being defined in multiple
locations
Signed-off-by: Nikolay Borisov
---
fs/logfs/dir.c | 6
Hello,
I'm currently dealing with a synchronization scheme which utilizes RCU
but I'm observing a race condition. So I have an rcu-enabled list, which
contains various entries. The add/delete paths of the list are protected
by a single spin_lock. I'm observing the following thing happening:
T1
This patch changes the export attributes of the init_user_ns from
GPL-only to any modules. This needed so that non-gpl modules, such as
ZFS, utilize functions like i_(uid|gid)_(read|write).
Signed-off-by: Nikolay Borisov
---
kernel/user.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
Hello Josh,
I'd like to ask you whether objtool is supposed to produce a
warning when arch/x86/lib/csum-copy_64.o (produced from
arch/x86/lib/csum-copy_64.S). Since I cannot see any specific
usage of rbp for defining a stackframe. I'm chasing against
poor performance of a network benchmark an
On 05/11/2016 09:38 AM, Nikolay Borisov wrote:
>
>
> On 05/11/2016 01:01 AM, Paolo Valente wrote:
>> When a bio is cloned, the newly created bio must be associated with
>> the same blkcg as the original bio (if BLK_CGROUP is enabled). If
>> this operation is not per
ne_fast to also apply this for
dm backed devices.
Otherwise:
Reviewed-by: Nikolay Borisov
Hello,
On a 4.4.1 kernel I observed the following crash:
[1157738.189104] BUG: unable to handle kernel NULL pointer dereference at
(null)
[1157738.189374] IP: [] __wake_up_common+0x2e/0x90
[1157738.189596] PGD 4382a6067 PUD 43827e067 PMD 0
[1157738.189901] Oops: [#1] SMP
[1157
On 04/06/2016 10:26 AM, Nikolay Borisov wrote:
>
>
> On 04/06/2016 04:25 AM, David Rientjes wrote:
>> The page_counter rounds limits down to page size values. This makes
>> sense, except in the case of hugetlb_cgroup where it's not possible to
>> charge pa
On 04/06/2016 04:25 AM, David Rientjes wrote:
> The page_counter rounds limits down to page size values. This makes
> sense, except in the case of hugetlb_cgroup where it's not possible to
> charge partial hugepages.
>
> Round the hugetlb_cgroup limit down to hugepage size.
>
> Signed-off-by:
eempt_disable();
> + pstat = this_cpu_ptr(&pcs->stats[stat]);
> + *pstat += cnt;
> + preempt_enable();
> +}
pstat = get_cpu_ptr(&pcs->stats[stat]);
*pstat += cnt;
put_cpu_ptr(&pcs->stats[stat]);
It will generate identical code but this one uses APIs, making the
intention clearer. But as I said this is just a minor nit.
you can add my Reviewed-by: Nikolay Borisov for this
particular patch.
On 04/01/2016 06:49 PM, Andy Lutomirski wrote:
> Sadly, hardware turbo mode buttons are few and far between in these
> degenerate times. Add a software control at /proc/sys/turbo_mode.
>
> Unfortunately, Linux graphical environments have become very
> heavy-weight and are essentially unusable o
On 03/28/2016 08:26 AM, js1...@gmail.com wrote:
> From: Joonsoo Kim
>
> Major kmem_cache metadata in slab subsystem is synchronized with
> the slab_mutex. In SLAB, if some of them is changed, node's shared
> array cache would be freed and re-populated. If __kmem_cache_shrink()
> is called at th
other useful work and no trip the
softlockup watchdog.
Signed-off-by: Nikolay Borisov
---
Here is what the splat looked like. Even though this was observed
on a 3.12 kernel I don't see why it can't happen on recent
kernels as well.
[1294411.570734] BUG: soft lockup - CPU#3 stuck for 22
On 03/11/2016 01:17 PM, Christoph Hellwig wrote:
> On Sat, Mar 05, 2016 at 07:18:30PM +0700, Linus Walleij wrote:
>> Depends on what time horizon and target I'd say. Paolo was in contact with
>> the MMC/SD subsystem maintainer Ulf Hansson. (e)MMC/SD are both
>> synchronous command-response-based
s. The first user wins. Either the probe or the patch
> + is rejected when the handler is already in use by the other.
> +
> +
> + + Kprobes in the original function are ignored when the code is redirected
> +to the new implementation.
> +
> +There is a work in progress to add warnings about this situations.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4029c63d8a7d..0e7049688862 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6590,6 +6590,7 @@ F: kernel/livepatch/
> F: include/linux/livepatch.h
> F: arch/x86/include/asm/livepatch.h
> F: arch/x86/kernel/livepatch.c
> +F: Documentation/livepatch/
> F: Documentation/ABI/testing/sysfs-kernel-livepatch
> F: samples/livepatch/
> L: live-patch...@vger.kernel.org
>
It's a good starting point. Hopefully a bit of tweaking will make it
even more friendly to newcomers of livepatching (I have read the sources
but I'm in no way VERY familiar with it). I'm especially interested in
the relocation and current consistency model documentation.
Reviewed-by: Nikolay Borisov
e USR or GRP quota
are initialised then the PRJ pointer in the "got" array would remain
uninitialised. This will cause the NULL ptr check in dqput to pass
but actually the pointer is going to be invalid. Eventually this would
cause a GFP.
To fix this just zero out the got array
Signed-
ARN_ON_ONCE(unlikely(gfp_flags & __GFP_NOFAIL) && (order > 1));
WARN_ON_ONCE already includes an unlikely in its definition:
http://lxr.free-electrons.com/source/include/asm-generic/bug.h#L109
> spin_lock_irqsave(&zone->lock, flags);
>
> page = NULL;
>
Reviewed-by: Nikolay Borisov
On 02/25/2016 11:08 AM, Michal Hocko wrote:
> On Thu 25-02-16 11:01:32, Nikolay Borisov wrote:
>>
>>
>> On 02/24/2016 07:09 PM, Konstantin Khlebnikov wrote:
>>> This might be unexpected but pages allocated for sbi->s_buddy_cache are
>>> charged to curr
On 02/24/2016 07:09 PM, Konstantin Khlebnikov wrote:
> This might be unexpected but pages allocated for sbi->s_buddy_cache are
> charged to current memory cgroup. So, GFP_NOFS allocation could fail if
> current task has been killed by OOM or if current memory cgroup has no
> free memory left. Blo
On 02/16/2016 08:24 PM, Tejun Heo wrote:
> Signed-off-by: Tejun Heo
> Reported-and-tested-by: Tahsin Erdogan
> Link:
> http://lkml.kernel.org/g/caaeu0ancq7lgodvvgru-ou_o-6enii5ey0p1c26d1zzywkd...@mail.gmail.com
> Fixes: d10c80955265 ("writeback: implement foreign cgroup inode bdi_writeback
>
select_inode = ovl_d_select_inode,
> .d_revalidate = ovl_dentry_revalidate,
> .d_weak_revalidate = ovl_dentry_weak_revalidate,
> };
I wish I had seen this patch earlier than
https://marc.info/?l=linux-unionfs&m=145494313009959
Reviewed-by: Nikolay Borisov
Tested-by: Nikolay Borisov
;
> -#endif
> }
> spin_unlock_bh(&pmc->lock);
> return err;
> @@ -2711,13 +2691,10 @@ static int igmp_mc_seq_show(struct seq_file *seq,
> void *v)
> char *querier;
> long delta;
>
> -#ifdef CONFIG_IP_MULTICAST
> - querier = IGMP_V1_SEEN(state->in_dev) ? "V1" :
> + querier = !IS_ENABLED(CONFIG_IP_MULTICAST) ? "NONE" :
> + IGMP_V1_SEEN(state->in_dev) ? "V1" :
> IGMP_V2_SEEN(state->in_dev) ? "V2" :
> "V3";
> -#else
> - querier = "NONE";
> -#endif
>
> if (rcu_access_pointer(state->in_dev->mc_list) == im) {
> seq_printf(seq, "%d\t%-10s: %5d %7s\n",
>
Reviewed-by: Nikolay Borisov
On 02/15/2016 04:09 AM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the net-next tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
>
> net/ipv4/igmp.c: In function 'igmp_group_added':
> net/ipv4/igmp.c:1227:14: warning: unused variable 'net' [-Wunused-vari
Hi Jiri,
I think this commit should also be included:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=18d03e8c25f173f4107a40d0b8c24defb6ed69f3
On 02/11/2016 03:59 PM, Jiri Slaby wrote:
> This is the start of the stable review cycle for the 3.12.54 release.
> There are 6
ons, which allows querying the correct inode
when writing to an overlayed location, using a remote lower dir.
Fixes: daee0af5b522 ("overlayfs: Make f_path always point to the
overlay and f_inode to the underlay")
Signed-off-by: Nikolay Borisov
---
This took me quite a while to
201 - 300 of 378 matches
Mail list logo
