Hello,
Today a colleague was testing something and while doing so he observed
the following crash:
jbd2_journal_bmap: journal block not found at offset 67 on dm-26-8
Aborting journal on device dm-26-8.
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: []
Hello,
Today a colleague was testing something and while doing so he observed
the following crash:
jbd2_journal_bmap: journal block not found at offset 67 on dm-26-8
Aborting journal on device dm-26-8.
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: []
to make filesystems mountable in non-init user
namespace and
an arbitrary user could potentially cause instability on the system?
Regards,
Nikolay
On Wed, Sep 30, 2015 at 8:12 PM, Darrick J. Wong
<darrick.w...@oracle.com> wrote:
> On Wed, Sep 30, 2015 at 04:35:49PM +0300, Nikolay Bori
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,
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,
in the logic
of the function? And also is it normal that such a failure
mode could cause the whole machine to be unstable?
Regards,
Nikolay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
in the logic
of the function? And also is it normal that such a failure
mode could cause the whole machine to be unstable?
Regards,
Nikolay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
Hi Jiry,
Maybe you would want to consider this:
https://patchwork.ozlabs.org/patch/459088/
It has already found its ways in other stable kernels, despite not being
cc'ed to stable.
Regards,
Nikolay
On 09/15/2015 05:22 PM, Jiri Slaby wrote:
> This is the start of the stable review cy
Hi Jiry,
Maybe you would want to consider this:
https://patchwork.ozlabs.org/patch/459088/
It has already found its ways in other stable kernels, despite not being
cc'ed to stable.
Regards,
Nikolay
On 09/15/2015 05:22 PM, Jiri Slaby wrote:
> This is the start of the stable review cy
On 09/09/2015 05:01 PM, Christoph Lameter wrote:
> On Wed, 9 Sep 2015, Nikolay Borisov wrote:
>
>> [root@kernighan vm]# ./slabinfo -da kmalloc-32
>> Cannot write to dma-kmalloc-32/sanity
>> [root@kernighan vm]# ./slabinfo -dF kmalloc-32
>> Cannot write to
On 09/09/2015 05:01 PM, Christoph Lameter wrote:
> On Wed, 9 Sep 2015, Nikolay Borisov wrote:
>
>> [root@kernighan vm]# ./slabinfo -da kmalloc-32
>> Cannot write to dma-kmalloc-32/sanity
>> [root@kernighan vm]# ./slabinfo -dF kmalloc-32
>> Cannot write to
On 09/08/2015 06:15 PM, Christoph Lameter wrote:
> On Tue, 8 Sep 2015, Nikolay Borisov wrote:
>
>>> You have read https://www.kernel.org/doc/Documentation/vm/slub.txt?
>>
>> I've read that I'm also following the merge/nomerge thread on the DM
>> mailing list.
On 09/08/2015 06:15 PM, Christoph Lameter wrote:
> On Tue, 8 Sep 2015, Nikolay Borisov wrote:
>
>>> You have read https://www.kernel.org/doc/Documentation/vm/slub.txt?
>>
>> I've read that I'm also following the merge/nomerge thread on the DM
>> mailing list.
On 09/08/2015 05:27 PM, Christoph Lameter wrote:
> On Tue, 8 Sep 2015, Nikolay Borisov wrote:
>
>> Unfortunately I haven't found a way to reproduce it so the only option
>> would be to do this on a live server. However, the performance impact I
>> believe is goin
On 09/08/2015 04:58 PM, Christoph Lameter wrote:
> On Mon, 7 Sep 2015, Nikolay Borisov wrote:
>
>> Did a bit more investigation and it turns out the
>> corruption is happening in slab_alloc_node, in the
>> 'else' branch when get_freepointer is being called:
>
From: Nikolay Borisov
This patch add a simple hashtable to the user_namespace structure and
the necessary functions to work with it. The idea is to keep a
uid->nproc counts per-namespace.
Signed-off-by: Nikolay Borisov
---
include/linux/user_namespace.h | 15 +-
kernel/use
From: Nikolay Borisov
This patch introduce the usage of the userns_nproc_* functions
where necessary to have correct accounting of the processes.
Signed-off-by: Nikolay Borisov
---
kernel/cred.c | 36 ++--
kernel/exit.c | 9 +
kernel/fork.c | 33
From: Nikolay Borisov
Hello,
This is an initial try to have nproc count apply per-userns,
rather than per the global user struct. The implementation is
really simple - a hashtable holding uid->nproc mapping for each
id inside the respective namespace. In its current form I have also
l
From: Nikolay Borisov <n.bori...@siteground.com>
This patch add a simple hashtable to the user_namespace structure and
the necessary functions to work with it. The idea is to keep a
uid->nproc counts per-namespace.
Signed-off-by: Nikolay Borisov <ker...@kyup.com>
---
From: Nikolay Borisov <n.bori...@siteground.com>
This patch introduce the usage of the userns_nproc_* functions
where necessary to have correct accounting of the processes.
Signed-off-by: Nikolay Borisov <ker...@kyup.com>
---
kernel/cred.c | 36
From: Nikolay Borisov <n.bori...@siteground.com>
Hello,
This is an initial try to have nproc count apply per-userns,
rather than per the global user struct. The implementation is
really simple - a hashtable holding uid->nproc mapping for each
id inside the respective namespace. In it
On 09/08/2015 04:58 PM, Christoph Lameter wrote:
> On Mon, 7 Sep 2015, Nikolay Borisov wrote:
>
>> Did a bit more investigation and it turns out the
>> corruption is happening in slab_alloc_node, in the
>> 'else' branch when get_freepointer is being called:
>
On 09/08/2015 05:27 PM, Christoph Lameter wrote:
> On Tue, 8 Sep 2015, Nikolay Borisov wrote:
>
>> Unfortunately I haven't found a way to reproduce it so the only option
>> would be to do this on a live server. However, the performance impact I
>> believe is goin
Hi,
If you have the vmlinux image for the kernel you were running at the
time, the crash occured, could you post the output of addr2line -f -e
path/to/vmlinux 8115bd4d to see if it also fails in
get_freepointer.
Regards,
Nikolay
On 09/07/2015 01:37 PM, Holger Hoffstätte wrote:
> On
2line on the other paging request failures also show that the
issue is in the same function - get_freepointer:
addr2line -f -e vmlinux-4.1.6-clouder1 811824e5
get_freepointer
/home/projects/linux-stable/mm/slub.c:247
Regards,
Nikolay
On 09/07/2015 11:41 AM, Nikolay Borisov wrote:
> Hello
r in use:
grep -i slub kernel-conf-4.1
# CONFIG_SLUB_DEBUG is not set
CONFIG_SLUB=y
CONFIG_SLUB_CPU_PARTIAL=y
# CONFIG_SLUB_STATS is not set
If more information is needed I'm happy to provide it.
Any help will be much appreciated.
Regards,
Nikolay
--
To unsubscribe from this list:
r in use:
grep -i slub kernel-conf-4.1
# CONFIG_SLUB_DEBUG is not set
CONFIG_SLUB=y
CONFIG_SLUB_CPU_PARTIAL=y
# CONFIG_SLUB_STATS is not set
If more information is needed I'm happy to provide it.
Any help will be much appreciated.
Regards,
Nikolay
--
To unsubscribe from this list:
Hi,
If you have the vmlinux image for the kernel you were running at the
time, the crash occured, could you post the output of addr2line -f -e
path/to/vmlinux 8115bd4d to see if it also fails in
get_freepointer.
Regards,
Nikolay
On 09/07/2015 01:37 PM, Holger Hoffstätte wrote:
> On
2line on the other paging request failures also show that the
issue is in the same function - get_freepointer:
addr2line -f -e vmlinux-4.1.6-clouder1 811824e5
get_freepointer
/home/projects/linux-stable/mm/slub.c:247
Regards,
Nikolay
On 09/07/2015 11:41 AM, Nikolay Borisov wrote:
> Hello
on
the value of CONFIG_X86_X32_ABI
Signed-off-by: Nikolay Borisov
---
Sending v2 as I had forgotten to add my signed-off-by line.
arch/x86/entry/entry_64.S | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 8cb3e43
The entry_SYSCALL_64_fastpath was checking the value of __SYSCALL_MASK,
which in turn was being set in arch/x86/include/asm/unistd.h depending on
whether CONFIG_X86_X32_ABI was set or not. This made the intention a bit
cryptic.
Juggle the code around so that the conditional compilation depends on
on
the value of CONFIG_X86_X32_ABI
Signed-off-by: Nikolay Borisov <nikolay.b.bori...@gmail.com>
---
Sending v2 as I had forgotten to add my signed-off-by line.
arch/x86/entry/entry_64.S | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/entry/entry_64.S b/ar
The entry_SYSCALL_64_fastpath was checking the value of __SYSCALL_MASK,
which in turn was being set in arch/x86/include/asm/unistd.h depending on
whether CONFIG_X86_X32_ABI was set or not. This made the intention a bit
cryptic.
Juggle the code around so that the conditional compilation depends on
Date: Thu, 2 Jul 2015 17:05:05 +0200
>> Subject: [PATCH] mm, vmscan: Do not wait for page writeback for GFP_NOFS
>> allocations
>>
>> Nikolay has reported a hang when a memcg reclaim got stuck with the
>> following backtrace...
>
> Sorry, I couldn't manage more than
Subject: [PATCH] mm, vmscan: Do not wait for page writeback for GFP_NOFS
allocations
Nikolay has reported a hang when a memcg reclaim got stuck with the
following backtrace...
Sorry, I couldn't manage more than to ignore you when you Cc'ed me on
this a month ago. Dave's perfectly correct
On 07/30/2015 04:10 AM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> net/bridge/br_multicast.c
>
> between commit:
>
> 544586f742b4 ("bridge: mcast: give fast leave precedence over multicast
> router and querier")
>
> from the
On 07/30/2015 04:10 AM, Stephen Rothwell wrote:
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
net/bridge/br_multicast.c
between commit:
544586f742b4 (bridge: mcast: give fast leave precedence over multicast
router and querier)
from the net tree and
Hello,
I have a machine running kernel 3.13.3, in fact I have 3 such machines
which are connected via corosync in a cluster. On one of the machines
I observed the following lock-up:
Jul 26 06:01:14 shrek kernel: [ cut here ]
Jul 26 06:01:14 shrek kernel: WARNING: CPU:
Hello,
I have a machine running kernel 3.13.3, in fact I have 3 such machines
which are connected via corosync in a cluster. On one of the machines
I observed the following lock-up:
Jul 26 06:01:14 shrek kernel: [ cut here ]
Jul 26 06:01:14 shrek kernel: WARNING: CPU:
On 07/16/2015 11:00 PM, Mathieu Desnoyers wrote:
> Expose a new system call allowing threads to register a userspace memory
> area where to store the current CPU number. Scheduler migration sets the
> TIF_NOTIFY_RESUME flag on the current thread. Upon return to user-space,
> a notify-resume
On 07/15/2015 10:46 PM, Seth Forshee wrote:
> From: Andy Lutomirski
>
> If a process gets access to a mount from a different namespace user
> namespace, that process should not be able to take advantage of
> setuid files or selinux entrypoints from that filesystem.
> Technically, trusting
On 07/16/2015 11:00 PM, Mathieu Desnoyers wrote:
Expose a new system call allowing threads to register a userspace memory
area where to store the current CPU number. Scheduler migration sets the
TIF_NOTIFY_RESUME flag on the current thread. Upon return to user-space,
a notify-resume handler
On 07/15/2015 10:46 PM, Seth Forshee wrote:
From: Andy Lutomirski l...@amacapital.net
If a process gets access to a mount from a different namespace user
namespace, that process should not be able to take advantage of
setuid files or selinux entrypoints from that filesystem.
Technically,
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
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 window.
On 07/14/2015 03:46 AM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> net/bridge/br_mdb.c
>
> between commit:
>
> f1158b74e54f ("bridge: mdb: zero out the local br_ip variable before use")
>
> from Linus' tree and commit:
>
>
On 07/14/2015 03:46 AM, Stephen Rothwell wrote:
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
net/bridge/br_mdb.c
between commit:
f1158b74e54f (bridge: mdb: zero out the local br_ip variable before use)
from Linus' tree and commit:
74fe61f17e99
On 07/02/2015 09:14 AM, Theodore Ts'o wrote:
> On Tue, Jun 30, 2015 at 09:26:49AM +0300, Nikolay Borisov wrote:
>> Switch ext4 to using sb_getblk_gfp with GFP_NOFS added, this fixes
>> possible deadlocks in the page writeback path.
>>
>> Signed-off-by: Nikol
On 07/02/2015 09:14 AM, Theodore Ts'o wrote:
On Tue, Jun 30, 2015 at 09:26:49AM +0300, Nikolay Borisov wrote:
Switch ext4 to using sb_getblk_gfp with GFP_NOFS added, this fixes
possible deadlocks in the page writeback path.
Signed-off-by: Nikolay Borisov ker...@kyup.com
I've added
a sb_getblk_gfp with the only difference it can
accept user-provided GFP flags.
Signed-off-by: Nikolay Borisov
---
As per the discussion in this thread
(http://marc.info/?l=linux-ext4=143563347324528=2)
here are the patches which hopefully implement Ted's suggestion.
include/linux
Switch ext4 to using sb_getblk_gfp with GFP_NOFS added, this fixes
possible deadlocks in the page writeback path.
Signed-off-by: Nikolay Borisov
---
fs/ext4/extents.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index
a sb_getblk_gfp with the only difference it can
accept user-provided GFP flags.
Signed-off-by: Nikolay Borisov ker...@kyup.com
---
As per the discussion in this thread
(http://marc.info/?l=linux-ext4m=143563347324528w=2)
here are the patches which hopefully implement Ted's suggestion.
include
Switch ext4 to using sb_getblk_gfp with GFP_NOFS added, this fixes
possible deadlocks in the page writeback path.
Signed-off-by: Nikolay Borisov ker...@kyup.com
---
fs/ext4/extents.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/ext4/extents.c b/fs/ext4
possibly force a transaction to stall for hours?
Regards,
Nikolay
--
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 FA
?
Regards,
Nikolay
--
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/
Hello,
During a debugging session of my local code I encountered the following
lockdep splat but my machine did not deadlock, on subsequent repeats of
the same operations that led to this splat (enqueuing my rcu callback) I
couldn't reproduce it:
=
[ INFO:
Hello,
During a debugging session of my local code I encountered the following
lockdep splat but my machine did not deadlock, on subsequent repeats of
the same operations that led to this splat (enqueuing my rcu callback) I
couldn't reproduce it:
=
[ INFO:
On Mon, Jun 8, 2015 at 9:08 PM, Jarod Wilson wrote:
> On 6/6/2015 8:20 PM, Jarod Wilson wrote:
>>
>> On 6/6/2015 9:29 AM, Nikolay Aleksandrov wrote:
>>>
>>> On Sat, Jun 6, 2015 at 12:24 AM, Jarod Wilson wrote:
>>>>
>>>> Its possibl
On Mon, Jun 8, 2015 at 9:08 PM, Jarod Wilson ja...@redhat.com wrote:
On 6/6/2015 8:20 PM, Jarod Wilson wrote:
On 6/6/2015 9:29 AM, Nikolay Aleksandrov wrote:
On Sat, Jun 6, 2015 at 12:24 AM, Jarod Wilson ja...@redhat.com wrote:
Its possible for users to specify their own MAC address
On Sat, Jun 6, 2015 at 12:24 AM, Jarod Wilson wrote:
> Its possible for users to specify their own MAC address for a bonded link,
> and this used to work, until sometime in 2013...
>
> First, commit 409cc1f8a changed a condition to set the bond's mac to a
> slave device's, dropping the
On Sat, Jun 6, 2015 at 12:24 AM, Jarod Wilson ja...@redhat.com wrote:
Its possible for users to specify their own MAC address for a bonded link,
and this used to work, until sometime in 2013...
First, commit 409cc1f8a changed a condition to set the bond's mac to a
slave device's, dropping the
-in back and the kernel hasn't crashed.
Regards,
Nikolay
On 05/27/2015 06:16 PM, Eric W. Biederman wrote:
> Josh Boyer writes:
>
>> On Tue, May 26, 2015 at 12:31 PM, Eric W. Biederman
>> wrote:
>>> Alexander Larsson writes:
>>>
>>>> On mån, 20
-in back and the kernel hasn't crashed.
Regards,
Nikolay
On 05/27/2015 06:16 PM, Eric W. Biederman wrote:
Josh Boyer jwbo...@fedoraproject.org writes:
On Tue, May 26, 2015 at 12:31 PM, Eric W. Biederman
ebied...@xmission.com wrote:
Alexander Larsson al...@redhat.com writes:
On mån, 2015-05-18
Hello,
On one of our servers we are observing deadlocks when fsync running. The
kernel version in question is: 3.12.28
We've managed to acquire a backtrace from one of the hanging processes:
PID: 21575 TASK: 883f482ac200 CPU: 24 COMMAND: "exim"
#0 [8824be1ab0e8] __schedule at
Hello,
On one of our servers we are observing deadlocks when fsync running. The
kernel version in question is: 3.12.28
We've managed to acquire a backtrace from one of the hanging processes:
PID: 21575 TASK: 883f482ac200 CPU: 24 COMMAND: exim
#0 [8824be1ab0e8] __schedule at
Commit-ID: 8c8a457a60050d5922676f81913d87e4af6fd97b
Gitweb: http://git.kernel.org/tip/8c8a457a60050d5922676f81913d87e4af6fd97b
Author: Nikolay Borisov
AuthorDate: Thu, 14 May 2015 14:31:01 +0300
Committer: Ingo Molnar
CommitDate: Thu, 14 May 2015 20:04:43 +0200
sched: Remove redundant
Commit-ID: 8c8a457a60050d5922676f81913d87e4af6fd97b
Gitweb: http://git.kernel.org/tip/8c8a457a60050d5922676f81913d87e4af6fd97b
Author: Nikolay Borisov n.bori...@siteground.com
AuthorDate: Thu, 14 May 2015 14:31:01 +0300
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Thu, 14 May 2015
packets the top utility doesn't detect it (for me it was showing
sustained 0% usage both for kernel and user space)
Regards,
Nikolay
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 4.0.0 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
Hello,
I can confirm that I'm also observing the same issue. Here is the output
of turbostat:
without hping running (Most of the time is spent in idle C6 state, which
is expected):
pk cor CPU%c0 GHz TSC SMI%c1%c3%c6%c7 CTMP PTMP
%pc2 %pc3 %pc6 %pc7 Pkg_W
Hello,
I can confirm that I'm also observing the same issue. Here is the output
of turbostat:
without hping running (Most of the time is spent in idle C6 state, which
is expected):
pk cor CPU%c0 GHz TSC SMI%c1%c3%c6%c7 CTMP PTMP
%pc2 %pc3 %pc6 %pc7 Pkg_W
packets the top utility doesn't detect it (for me it was showing
sustained 0% usage both for kernel and user space)
Regards,
Nikolay
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 4.0.0 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
involved fix?
Regards,
Nikolay
--
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/
involved fix?
Regards,
Nikolay
--
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 04/30/2015 02:01 AM, Pai wrote:
> This fixes a few coding style issues in my previous patch:
> commit e913fb279c56
> ("net: Fix Kernel Panic in bonding driver debugfs file: rlb_hash_table")
>
> Signed-off-by: Vishwanath Pai
>
> diff --git a/drivers/net/bonding/bond_main.c
On 04/30/2015 02:01 AM, Pai wrote:
This fixes a few coding style issues in my previous patch:
commit e913fb279c56
(net: Fix Kernel Panic in bonding driver debugfs file: rlb_hash_table)
Signed-off-by: Vishwanath Pai v...@akamai.com
diff --git a/drivers/net/bonding/bond_main.c
On 04/29/2015 08:24 PM, Pai wrote:
> This patch fixes a Kernel Panic in bonding driver debugfs file:
> rlb_hash_table.
>
> $> modprobe bonding mode=6
> $> cat /sys/kernel/debug/bonding/bond0/rlb_hash_table
>
> This will crash the kernel. The struct alb_bond_info is initialized only when
> the
On 04/29/2015 08:24 PM, Pai wrote:
This patch fixes a Kernel Panic in bonding driver debugfs file:
rlb_hash_table.
$ modprobe bonding mode=6
$ cat /sys/kernel/debug/bonding/bond0/rlb_hash_table
This will crash the kernel. The struct alb_bond_info is initialized only when
the bonding
On Thu, Nov 13, 2014 at 4:23 PM, Eric Auger wrote:
> On 11/13/2014 03:16 PM, Eric Auger wrote:
>> On 11/13/2014 11:45 AM, Nikolay Nikolaev wrote:
>>> On Mon, Nov 10, 2014 at 6:27 PM, Christoffer Dall
>>> wrote:
>>>> On Mon, Nov 10, 2014 at 05:09:07PM +02
On Thu, Nov 13, 2014 at 1:52 PM, Andre Przywara wrote:
> Hi Nikolay,
>
> On 13/11/14 11:37, Marc Zyngier wrote:
>> [fixing Andre's email address]
>>
>> On 13/11/14 11:20, Christoffer Dall wrote:
>>> On Thu, Nov 13, 2014 at 12:4
On Mon, Nov 10, 2014 at 6:27 PM, Christoffer Dall
wrote:
> On Mon, Nov 10, 2014 at 05:09:07PM +0200, Nikolay Nikolaev wrote:
>> Hello,
>>
>> On Fri, Mar 28, 2014 at 9:09 PM, Christoffer Dall
>> wrote:
>> >
>> > On Thu, Mar 13, 201
On Mon, Nov 10, 2014 at 6:27 PM, Christoffer Dall
christoffer.d...@linaro.org wrote:
On Mon, Nov 10, 2014 at 05:09:07PM +0200, Nikolay Nikolaev wrote:
Hello,
On Fri, Mar 28, 2014 at 9:09 PM, Christoffer Dall
christoffer.d...@linaro.org wrote:
On Thu, Mar 13, 2014 at 04:57:26PM +0100
On Thu, Nov 13, 2014 at 1:52 PM, Andre Przywara andre.przyw...@arm.com wrote:
Hi Nikolay,
On 13/11/14 11:37, Marc Zyngier wrote:
[fixing Andre's email address]
On 13/11/14 11:20, Christoffer Dall wrote:
On Thu, Nov 13, 2014 at 12:45:42PM +0200, Nikolay Nikolaev wrote:
[...]
Going
On Thu, Nov 13, 2014 at 4:23 PM, Eric Auger eric.au...@linaro.org wrote:
On 11/13/2014 03:16 PM, Eric Auger wrote:
On 11/13/2014 11:45 AM, Nikolay Nikolaev wrote:
On Mon, Nov 10, 2014 at 6:27 PM, Christoffer Dall
christoffer.d...@linaro.org wrote:
On Mon, Nov 10, 2014 at 05:09:07PM +0200
ad/write callbacks. This
> > is a dependency for eventfd support (ioeventfd and irqfd).
> >
> > However, accesses to the VGIC are still left implemented independently,
> > since the kvm_io_bus_* API doesn't pass the VCPU pointer doing the access.
> >
> > Signed-off-by:
Signed-off-by: Nikolay Nikolaev n.nikol...@virtualopensystems.com
---
arch/arm/kvm/mmio.c | 32
virt/kvm/arm/vgic.c | 5 -
2 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kvm/mmio.c b/arch/arm/kvm/mmio.c
index 4cb5a93..1d17831
Sorry for butting in, but as a concerned user, let me add my two cents.
I have just about enough expertise in kernel to port this patch to
newer kernel versions. I have absolutely no idea on how to fix this
proper. And porting (in my case) is time-consuming and error-prone.
I wish this patch was
Sorry for butting in, but as a concerned user, let me add my two cents.
I have just about enough expertise in kernel to port this patch to
newer kernel versions. I have absolutely no idea on how to fix this
proper. And porting (in my case) is time-consuming and error-prone.
I wish this patch was
ardy
> ---
> net/netfilter/nft_hash.c | 291
> +--
> 1 file changed, 55 insertions(+), 236 deletions(-)
>
Reviewed-by: Nikolay Aleksandrov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bod
Thomas Graf
> ---
> net/netlink/af_netlink.c | 285
> ++-
> net/netlink/af_netlink.h | 18 +--
> net/netlink/diag.c | 11 +-
> 3 files changed, 119 insertions(+), 195 deletions(-)
>
Reviewed-by: Nikolay Aleksandrov
-
> 4 files changed, 1019 insertions(+), 1 deletion(-)
> create mode 100644 include/linux/rhashtable.h
> create mode 100644 lib/rhashtable.c
>
Reviewed-by: Nikolay Aleksandrov
--
To unsubscribe from this list: send the line "unsubscribe linu
mode 100644 include/linux/rhashtable.h
create mode 100644 lib/rhashtable.c
Reviewed-by: Nikolay Aleksandrov niko...@redhat.com
--
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
+--
net/netlink/diag.c | 11 +-
3 files changed, 119 insertions(+), 195 deletions(-)
Reviewed-by: Nikolay Aleksandrov niko...@redhat.com
--
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
...@trash.net
---
net/netfilter/nft_hash.c | 291
+--
1 file changed, 55 insertions(+), 236 deletions(-)
Reviewed-by: Nikolay Aleksandrov niko...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On 08/01/2014 05:15 PM, Thomas Graf wrote:
> On 08/01/14 at 04:51pm, Nikolay Aleksandrov wrote:
>> Hmm, in both the rhashtable_insert() and rhashtable_remove() calls in the
>> netlink code you're using GFP_ATOMIC flags but if rhashtable_expand/shring
>> gets
>> called
On 08/01/2014 01:58 PM, Thomas Graf wrote:
> Heavy Netlink users such as Open vSwitch spend a considerable amount of
> time in netlink_lookup() due to the read-lock on nl_table_lock. Use of
> RCU relieves the lock contention.
>
> Makes use of the new resizable hash table to avoid locking on the
>
On 08/01/2014 01:58 PM, Thomas Graf wrote:
> The sizing of the hash table and the practice of requiring a lookup
> to retrieve the pprev to be stored in the element cookie before the
> deletion of an entry is left intact.
>
> Signed-off-by: Thomas Graf
> Acked-by: Patrick McHardy
> ---
<>
> @@
On 08/01/2014 10:51 AM, Thomas Graf wrote:
> Generic implementation of a resizable, scalable, concurrent hash table
> based on [0]. The implementation supports both, fixed size keys specified
> via an offset and length, or arbitrary keys via own hash and compare
> functions.
>
> Lookups are
On 08/01/2014 10:51 AM, Thomas Graf wrote:
Generic implementation of a resizable, scalable, concurrent hash table
based on [0]. The implementation supports both, fixed size keys specified
via an offset and length, or arbitrary keys via own hash and compare
functions.
Lookups are lockless
On 08/01/2014 01:58 PM, Thomas Graf wrote:
The sizing of the hash table and the practice of requiring a lookup
to retrieve the pprev to be stored in the element cookie before the
deletion of an entry is left intact.
Signed-off-by: Thomas Graf tg...@suug.ch
Acked-by: Patrick McHardy
On 08/01/2014 01:58 PM, Thomas Graf wrote:
Heavy Netlink users such as Open vSwitch spend a considerable amount of
time in netlink_lookup() due to the read-lock on nl_table_lock. Use of
RCU relieves the lock contention.
Makes use of the new resizable hash table to avoid locking on the
901 - 1000 of 1054 matches
Mail list logo
