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/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
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 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
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/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
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
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
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
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/
>>>
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
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
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
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
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
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
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
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(-)
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
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:
>>> >
>>> >>
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
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
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
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/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
Hello Paul,
I'm currently going through a crashdump which seems to indicate some
memory corruption, possibly triggered by btrfs. I have several
entries such as :
[1626691.276310] BUG: Bad page state in process fstrim pfn:230ee7
[1626691.276488] page:ea0008c3b9c0 count:0 mapcount:0
mapp
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
So this thing resurfaced again and I took a hard look into the code but
couldn't find anything suspicious. So the allocating and freeing
contexts leads me to believe it's the 'tbl' pointer that is being
corrupted. The only thing which I do with it is to increase it by two.
Perhaps some liveness is
On 13.12.2016 20:51, Eric W. Biederman wrote:
> Nikolay Borisov writes:
>
>> So this thing resurfaced again and I took a hard look into the code but
>> couldn't find anything suspicious. So the allocating and freeing
>> contexts leads me to believe it'
On 24.12.2016 14:43, Haishuang Yan wrote:
> Signed-off-by: Haishuang Yan
Reviewed-by: Nikolay Borisov
On 28.12.2016 17:30, Michal Hocko wrote:
> From: Michal Hocko
>
> mm_vmscan_lru_isolate currently prints only whether the LRU we isolate
> from is file or anonymous but we do not know which LRU this is. It is
> useful to know whether the list is file or anonymous as well. Change
Maybe you wante
On 28.12.2016 18:00, Michal Hocko wrote:
> On Wed 28-12-16 17:50:31, Nikolay Borisov wrote:
>>
>>
>> On 28.12.2016 17:30, Michal Hocko wrote:
>>> From: Michal Hocko
>>>
>>> mm_vmscan_lru_isolate currently prints only whether the LRU we isolate
Hello,
I was doing some kasan-related debugging and when I enabled it I started
getting warnings for large stackframes. So CONFIG_FRAME_WARN has :
int "Warn for stack frames larger than (needs gcc 4.4)"
range 0 8192
default 0 if KASAN
default 2048 if GCC_PLUGIN_LATENT_ENTROPY
defa
On 15.12.2016 23:32, Randy Dunlap wrote:
> On 12/15/16 10:09, Nikolay Borisov wrote:
>> Hello,
>>
>> I was doing some kasan-related debugging and when I enabled it I started
>> getting warnings for large stackframes. So CONFIG_FRAME_WARN has :
>>
>> int &q
On 16.12.2016 09:50, Nikolay Borisov wrote:
>
>
> On 15.12.2016 23:32, Randy Dunlap wrote:
>> On 12/15/16 10:09, Nikolay Borisov wrote:
>>> Hello,
>>>
>>> I was doing some kasan-related debugging and when I enabled it I started
>>> getting w
On 18.12.2016 13:03, Arend Van Spriel wrote:
> On 18-12-2016 11:49, Jiri Slaby wrote:
>> On 12/18/2016, 12:59 AM, Linus Torvalds wrote:
>>> On Sat, Dec 17, 2016 at 12:57 AM, Jiri Slaby wrote:
Yes, disk drivers won't load:
[2.141973] virtio_pci: disagrees about version of symbo
On 18.12.2016 16:45, Jiri Slaby wrote:
> Moreover, with some modules, __put_user_1 and others are reported
> instead of mcount.
nm vmlinux | grep __fentry__
nm vmlinux | grep mcount
What do these report ? I bet you that in your vmlinux the first one
would return something like :
822f1
is referenced.
Fix this by failing to register the filesystem in case there is not enough
memory to fully construct the shrinker object.
Signed-off-by: Nikolay Borisov
---
fs/super.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/fs/super.c b/fs/super.c
in
is referenced.
Fix this by failing to register the filesystem in case there is not enough
memory to fully construct the shrinker object.
Signed-off-by: Nikolay Borisov
Fixes: 1d3d4437eae1 ("vmscan: per-node deferred work")
Link:
lkml.kernel.org/r/CACT4Y+b-purC3HHbw=sctms3ma8fkqtnyz
is referenced.
Fix this by failing to register the filesystem in case there is not enough
memory to fully construct the shrinker object.
Signed-off-by: Nikolay Borisov
---
fs/super.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/fs/super.c b/fs/super.c
in
On 7.03.2017 00:35, Rafael J. Wysocki wrote:
> On Mon, Mar 6, 2017 at 9:31 PM, Nikolay Borisov
> wrote:
>> Hello,
>>
>> Booting 4.11-rc1 with kasan enabled and "slub_debug=F" produces the
>&g
On 7.03.2017 11:38, Nikolay Borisov wrote:
>
>
> On 7.03.2017 00:35, Rafael J. Wysocki wrote:
>> On Mon, Mar 6, 2017 at 9:31 PM, Nikolay Borisov
>> wrote:
>>> Hello,
>>>
>>> Booting 4.11-rc1 with kasan enabled and "slub_debug=F"
Hello,
I've been chasing a particular UAF as reported by kasan
(https://www.spinics.net/lists/kernel/msg2458136.html). However, one
thing which I took notice of rather lately is that I was building my
kernel with gcc 4.7.4 which is not supported by kasan as indicated by
the following string:
scri
On 7.03.2017 18:05, Alexander Potapenko wrote:
> On Tue, Mar 7, 2017 at 4:54 PM, Dmitry Vyukov wrote:
>> On Tue, Mar 7, 2017 at 4:35 PM, Nikolay Borisov
>> wrote:
>>> Hello,
>>>
>>> I've been chasing a particular UAF as reported by kasan
>&
On 7.03.2017 19:51, Alexander Potapenko wrote:
> On Tue, Mar 7, 2017 at 6:33 PM, Nikolay Borisov
> wrote:
>>
>>
>> On 7.03.2017 18:05, Alexander Potapenko wrote:
>>> On Tue, Mar 7, 2017 at 4:54 PM, Dmitry Vyukov wrote:
>>>> On Tue, Mar 7,
On 7.03.2017 16:33, Nikolay Borisov wrote:
>
>
> On 7.03.2017 11:38, Nikolay Borisov wrote:
>>
>>
>> On 7.03.2017 00:35, Rafael J. Wysocki wrote:
>>> On Mon, Mar 6, 2017 at 9:31 PM, Nikolay Borisov
>>> wrote:
>>>> Hello,
>&g
>>
>>
>> New report from linux-next/c0b7b2b33bd17f7155956d0338ce92615da686c9
>>
>> [ cut here ]
>> kernel BUG at net/unix/garbage.c:149!
>> invalid opcode: [#1] SMP KASAN
>> Dumping ftrace buffer:
>>(ftrace buffer empty)
>> Modules linked in:
>> CPU: 0 PID: 1806 Co
On 7.03.2017 17:54, Dmitry Vyukov wrote:
> On Tue, Mar 7, 2017 at 4:35 PM, Nikolay Borisov
> wrote:
>> Hello,
>>
>> I've been chasing a particular UAF as reported by kasan
>> (https://www.spinics.net/lists/kernel/msg2458136.html). However, one
>> thin
On 9.03.2017 03:58, Theodore Ts'o wrote:
> On Tue, Mar 07, 2017 at 10:40:53PM +0200, Nikolay Borisov wrote:
>> So this is wrong, the reason why the issues seemed fix is because I
>> switched my compiler to version 5.4.0. So this manifests only if I'm
>> using gc
On 9.03.2017 11:46, Andrey Ryabinin wrote:
> On 03/08/2017 11:10 AM, Nikolay Borisov wrote:
>
>>
>> So apparently this is indeed a false positive, resulting from using the old
>> compiler. I used the attached patch to verify it.
>>
>> And what it prints is
Hello,
Booting 4.11-rc1 with kasan enabled and "slub_debug=F" produces the following
errors:
[7.070797]
==
[7.071724] BUG: KASAN: slab-out-of-bounds in filldir+0xc3/0x160 at addr
88006bc2b0ae
[7.071724] Read of si
k into the filesystem
without explicitly changing the flags for every allocation site. Yet, lockdep
not being aware of that is prone to showing false positives. Fix this
by teaching it that the presence of PF_MEMALLOC_NOIO flag mean we are not
going to issue any I/O
Signed-off-by: Nikolay Borisov
---
kern
k into the filesystem
without explicitly changing the flags for every allocation site. Yet, lockdep
not being aware of that is prone to showing false positives. Fix this
by teaching it that the presence of PF_MEMALLOC_NOIO flag mean we are not
going to issue any I/O
Signed-off-by: Nikolay Borisov
---
kern
On 1.03.2017 11:46, Peter Zijlstra wrote:
> On Wed, Mar 01, 2017 at 09:59:00AM +0200, Nikolay Borisov wrote:
>> Commit 21caf2fc1931 ("mm: teach mm by current context info to not do I/O
>> during memory allocation") added the memalloc_noio_(save|restore) functions
>
On 1.03.2017 12:31, Michal Hocko wrote:
> On Wed 01-03-17 11:22:51, Vlastimil Babka wrote:
>> On 03/01/2017 08:48 AM, Nikolay Borisov wrote:
>>> Commit 21caf2fc1931 ("mm: teach mm by current context info to not do I/O
>>> during memory allocation")
r __GFP_FS when PF_MEMALLOC_NOIO is set")
Signed-off-by: Nikolay Borisov
---
kernel/locking/lockdep.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Changes since v2:
* Incorporate Michal's suggestion of using memalloc_noio_flags
explicitly.
* Tune the commi
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
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 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
gt; >
>> > > On Tue, Aug 02, 2016 at 11:00:39AM -0500, Eric W. Biederman wrote:
>> > > >
>> > > > > > > > Nikolay Borisov writes:
>> > > >
>> > > > >
>> > > > > Currently when /proc/locks is read
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
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
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 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 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/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 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,
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
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 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/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/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
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
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
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,
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 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
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
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
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-
Hello,
I'm running the stable 3.12.47 kernel and today one of the server
started reporting softlockups and rcushed stalls. I believe the 2
things are related with the culprit being the following:
INFO: rcu_sched detected stalls on CPUs/tasks: { 9} (detected by 6, t=10020747
jiffies, g=532488
On 09/26/2015 02:11 AM, Aleksa Sarai wrote:
>> On Thu, Sep 24, 2015 at 09:42:38AM +1000, Aleksa Sarai wrote:
>>> Does it make sense for the PIDs controller to allow a user to set a
>>> limit of 0? Since we don't cancel attaches, a limit of 0 doesn't
>>> affect anything (nothing stops attaches, an
Hello,
On a fairly busy server, running LXC I'm observing that sometimes
the processes for a particular container lock up by going into D
(uninterruptible sleep) state. Obtaining backtraces for those
processes one thing which stands out is that they are all
blocked in wait_transaction_locked (part
On 07/15/2015 01:26 PM, Jan Kara wrote:
> Hello,
>
> so I have created this patch set which removes ext3 driver (and some
> related support
> code) from the kernel. See changelog of patch 2/3 for more details. If noone
> objects,
> I will queue the series in my tree for the next merge wind
On 12/09/2015 06:27 PM, Tejun Heo wrote:
> Hello,
>
> On Wed, Dec 09, 2015 at 06:23:15PM +0200, Nikolay Borisov wrote:
>> I think we are seeing this at least daily on at least 1 server (we have
>> multiple servers like that). So adding printk's would likely be the
On 12/10/2015 05:29 PM, Tejun Heo wrote:
> On Thu, Dec 10, 2015 at 11:28:02AM +0200, Nikolay Borisov wrote:
>> On 12/09/2015 06:27 PM, Tejun Heo wrote:
>>> Hello,
>>>
>>> On Wed, Dec 09, 2015 at 06:23:15PM +0200, Nikolay Borisov wrote:
>>>> I think
On Fri, Dec 11, 2015 at 7:08 PM, Tejun Heo wrote:
> Hello, Nikolay.
>
> On Fri, Dec 11, 2015 at 05:57:22PM +0200, Nikolay Borisov wrote:
>> So I had a server with the patch just crash on me:
>>
>> Here is how the queue looks like:
>> crash> struct workqueue
On 12/12/2015 10:52 AM, Xishi Qiu wrote:
> [60050.458309] kjournald starting. Commit interval 5 seconds
> [60076.821224] EXT3-fs (sda1): using internal journal
> [60098.811865] EXT3-fs (sda1): mounted filesystem with ordered data mode
> [60138.687054] kjournald starting. Commit interval 5 secon
On 12/11/2015 09:14 PM, Mike Snitzer wrote:
> On Fri, Dec 11 2015 at 1:00pm -0500,
> Nikolay Borisov wrote:
>
>> On Fri, Dec 11, 2015 at 7:08 PM, Tejun Heo wrote:
>>>
>>> Hmmm... No idea why it didn't show up in the debug log but the only
>>>
Signed-off-by: Nikolay Borisov
---
include/net/netns/ipv4.h | 2 +-
include/net/tcp.h | 4 +++-
net/ipv4/sysctl_net_ipv4.c | 14 +++---
net/ipv4/tcp.c | 2 +-
net/ipv4/tcp_input.c | 12 ++--
net/ipv4/tcp_ipv4.c| 2 +-
net/ipv4
Signed-off-by: Nikolay Borisov
---
include/net/netns/ipv4.h | 1 +
include/net/tcp.h | 3 +--
net/ipv4/sysctl_net_ipv4.c | 14 +++---
net/ipv4/tcp.c | 7 +++
net/ipv4/tcp_ipv4.c| 1 +
5 files changed, 13 insertions(+), 13 deletions(-)
diff --git a
Signed-off-by: Nikolay Borisov
---
include/net/netns/ipv4.h | 1 +
include/net/tcp.h | 1 -
net/ipv4/sysctl_net_ipv4.c | 14 +++---
net/ipv4/tcp_ipv4.c| 1 +
net/ipv4/tcp_timer.c | 3 +--
5 files changed, 10 insertions(+), 10 deletions(-)
diff --git a
Signed-off-by: Nikolay Borisov
---
include/net/netns/ipv4.h | 1 +
include/net/tcp.h | 1 -
net/ipv4/sysctl_net_ipv4.c | 14 +++---
net/ipv4/tcp_ipv4.c| 1 +
net/ipv4/tcp_output.c | 3 ++-
net/ipv4/tcp_timer.c | 5 ++---
6 files changed, 13 insertions
Signed-off-by: Nikolay Borisov
---
include/net/netns/ipv4.h | 1 +
include/net/tcp.h | 4 ++--
net/ipv4/sysctl_net_ipv4.c | 14 +++---
net/ipv4/tcp_ipv4.c| 1 +
net/ipv4/tcp_output.c | 3 ---
5 files changed, 11 insertions(+), 12 deletions(-)
diff --git a
Signed-off-by: Nikolay Borisov
---
include/net/netns/ipv4.h | 2 ++
include/net/tcp.h | 1 -
net/ipv4/syncookies.c | 4 +---
net/ipv4/sysctl_net_ipv4.c | 18 +-
net/ipv4/tcp_input.c | 10 ++
net/ipv4/tcp_ipv4.c| 3 ++-
net/ipv4
it is required to tune the
tcp settings for each independently of the host node.
I've split the patches to be per-sysctl but after
the review if the outcome is positive I'm happy
to either send it in one big blob or just.
Nikolay Borisov (9):
ipv4: Namespaceify tcp syn retries sys
201 - 300 of 378 matches
Mail list logo
