On Tue, Oct 29, 2013 at 11:40 PM, David Miller wrote:
> From: Cong Wang
> Date: Tue, 29 Oct 2013 20:50:08 -0700
>
>> Normally ->poll() is called in softirq context, while netpoll could
>> be called in any context depending on its caller.
>
> It still makes amends
On Wed, Oct 30, 2013 at 2:32 PM, David Miller wrote:
>
> Explain to me then why other ethernet drivers implemented identically,
> such as tg3, can use plain dev_kfree_skb() just fine?
I don't think they are fine, I just don't see bug reports
for them. At very least, I saw a same bug report for be
On Mon, Dec 16, 2013 at 3:35 AM, Christoph Paasch
wrote:
> Hello,
>
> since 3.5, my crashkernel does not boot anymore when triggering an oops with
> /proc/sysrq-trigger on my HP Elitebook 8540p.
>
> I bisected it down to 722bc6b16771ed8 (x86/mm: Fix the size calculation of
> mapping tables).
>
It
On Mon, Dec 16, 2013 at 7:00 AM, Li Wang wrote:
> This patch extend the 'drop_caches' interface to
> support directory level cache cleaning and has a complete
> backward compatibility. '{1,2,3}' keeps the same semantics
> as before. Besides, "{1,2,3}:DIRECTORY_PATH_NAME" is allowed
> to recursivel
On Tue, Jul 29, 2014 at 2:29 AM, zhuyj wrote:
> Hi,all
>
> I did a test on kernel3.16 rc6:
>
> root@qemu1:~# echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
> root@qemu1:~# echo 1 > /proc/sys/net/ipv4/conf/all/forwarding
> root@qemu1:~# ip netns list
> root@qemu1:~# ip netns add fib1
> root@qemu1:
ay_load(), because cgroup_pidlist_stop() will be called
> no matter if cgroup_pidlist_start() returns errno or not.
>
I found same thing yesterday and tried to analysis if this could
be the cause of the the NULL ptr def bug I saw, it seems not.
Anyway, this fix is definitely correct,
Acked-by: Cong Wang
Hi, Zefan
Thanks for your reply. You are right, vfs refcount should guarantee us
there is no more file read before we destroy that cgroup. I thought
there is somewhere else could release that cgroup refcount.
Maybe I didn't make it clear, this bug is hardly reproducible, we only
saw it once (oth
(Networking bug report needs to go netdev@)
On Mon, Sep 22, 2014 at 4:30 AM, Pete Clements
wrote:
> Heads up fyi: system is i386 UP.
>
> Started getting some pop3 reception errors from the above system.
> Investigating the problem discovered scp of the mailbox failed
> with "Corrupted MAC on inpu
On Tue, Sep 23, 2014 at 6:20 AM, Nicolas Dichtel
wrote:
>
> Here is a small screenshot to show how it can be used by userland:
> $ ip netns add foo
> $ ip netns del foo
> $ ip netns
> $ touch /var/run/netns/init_net
> $ mount --bind /proc/1/ns/net /var/run/netns/init_net
> $ ip netns add foo
> $ i
On Wed, Sep 24, 2014 at 2:23 AM, Nicolas Dichtel
wrote:
> Le 23/09/2014 21:22, Cong Wang a écrit :
>
>> On Tue, Sep 23, 2014 at 6:20 AM, Nicolas Dichtel
>> wrote:
>>>
>>>
>>> Here is a small screenshot to show how it can be used by userland:
>>&
On Wed, Sep 24, 2014 at 9:01 AM, Cong Wang wrote:
>
> And clearly you missed my question above: how do you get netns id
> without sharing /var/run/netns/ ?
OK, I found it:
> Ids are stored in the parent user namespace. These ids are valid only inside
> this user namespace. The us
On Wed, Sep 24, 2014 at 9:27 AM, Nicolas Dichtel
wrote:
> Now informations got with 'ip link' are wrong and incomplete:
> - the link dev is now tunl0 instead of eth0, because we only got an
> ifindex
> from the kernel without any netns informations.
This is not new, macvlan has the same pro
On Wed, Sep 24, 2014 at 9:31 AM, Nicolas Dichtel
wrote:
>> I think in this case your ID's are still available, but aren't you
>> providing a new way
>> for the inner netns device to escape which we are trying to avoid?
>
> It's why the ids depend on user ns. Only if user ns are the same we allow t
On Wed, Sep 24, 2014 at 7:29 AM, Andrey Wagin wrote:
> 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 va
est doesn't trigger, but there is hope that maybe this fixes things.
I read this as it fixes your crash as well?
>
> Cong Wang, do you have more info on how you came across this bug? And how
> you tracked down the problem?
Sure, as I said in the changelog, it is a soft lockup which
On Thu, Sep 25, 2014 at 1:53 AM, Nicolas Dichtel
wrote:
> Le 24/09/2014 18:48, Cong Wang a écrit :
>
>> On Wed, Sep 24, 2014 at 9:31 AM, Nicolas Dichtel
>> wrote:
>>>>
>>>> I think in this case your ID's are still available, but aren't you
>
On Thu, Sep 25, 2014 at 1:53 AM, Nicolas Dichtel
wrote:
> Le 24/09/2014 18:45, Cong Wang a écrit :
>>
>> On Wed, Sep 24, 2014 at 9:27 AM, Nicolas Dichtel
>> wrote:
>>>
>>> Now informations got with 'ip link' are wrong and incomplete:
>>>
On Mon, Sep 8, 2014 at 4:29 PM, Cong Wang wrote:
> On Mon, Sep 8, 2014 at 4:42 PM, Rafael J. Wysocki wrote:
>> On Monday, September 08, 2014 04:16:15 PM Cong Wang wrote:
>>> On Mon, Sep 8, 2014 at 4:23 PM, Rafael J. Wysocki
>>> wrote:
>>> >
>>>
On Wed, Sep 10, 2014 at 4:38 PM, Rafael J. Wysocki wrote:
> On Wednesday, September 10, 2014 01:30:25 PM Cong Wang wrote:
>> I am wondering if the folllowing check makes any sense with regarding
>> to rule out PM freeze:
>>
>> if ((!pm_nos
Hi, Johannes and Greg
Please consider to backport the following commit to stable kernels < 3.12.
commit 3812c8c8f3953921ef18544110dafc3505c1ac62
Author: Johannes Weiner
Date: Thu Sep 12 15:13:44 2013 -0700
mm: memcg: do not trap chargers with full callstack on OOM
It should solve some s
On Tue, Sep 30, 2014 at 1:16 AM, Michal Hocko wrote:
> On Mon 29-09-14 20:43:46, Cong Wang wrote:
>> Hi, Johannes and Greg
>>
>>
>> Please consider to backport the following commit to stable kernels < 3.12.
>>
>> commit 3812c8c8f3953921ef18544110dafc3505
On Sun, Sep 28, 2014 at 10:21 PM, Vince Weaver wrote:
> On Thu, 25 Sep 2014, Cong Wang wrote:
>
>> On Wed, Sep 24, 2014 at 9:59 PM, Vince Weaver
>> wrote:
>
>> > Now that just might mean the patch pushed the code around enough so my
>> > test doesn'
On Mon, Sep 15, 2014 at 2:36 AM, Michal Hocko wrote:
> This patch builds on top of Cong Wang's. What do you think?
I think it is should a preliminary of my patch, not a followup. I can carry
this patch for you if you want.
> ---
> From cdf97a20b107ee584352f07274a88d7c3f014ab2 Mon Sep 17 00:00:00
On Mon, Sep 15, 2014 at 4:22 AM, Michal Hocko wrote:
> On Thu 04-09-14 15:30:41, Cong Wang wrote:
>> There is a race condition between OOM killer and freezer when
>> they try to operate on the same process, something like below:
>>
>> Process A Proces
Hi, Tejun
We saw some kernel null pointer dereference in
cgroup_pidlist_destroy_work_fn(), more precisely at
__mutex_lock_slowpath(), on 3.14. I can show you the full stack trace
on request.
Looking at the code, it seems flush_workqueue() doesn't care about new
incoming works, it only processes
On Sun, Mar 9, 2014 at 8:39 PM, Linus Lüssing wrote:
> + is_general_query = group && ipv6_addr_any(group) ? true : false;
> +
Just "is_general_query = group && ipv6_addr_any(group);" should be okay.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Mon, May 19, 2014 at 1:05 PM, Michael Spang wrote:
> On Mon, May 19, 2014 at 1:44 PM, Eric Dumazet wrote:
>>
>> I removed stable@ , as stable submissions are not done like that.
>>
>
> Perhaps I've misunderstood something, but this suggestion is right
> from https://www.kernel.org/doc/Document
On Wed, May 14, 2014 at 11:47 PM, Stephen Rothwell
wrote:
> Hi all,
>
> After merging the net-next tree, today's linux-next build (powerpc
> allnoconfig) produced this warning:
>
>
> include/net/ip.h:211:5: warning: "CONFIG_SYSCTL" is not defined [-Wundef]
> #if CONFIG_SYSCTL
> ^
>
> Introd
On Thu, May 15, 2014 at 10:43 AM, David Miller wrote:
>
> I've just pushed out a fix for this, thanks everyone.
Thanks, David!
--
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.kerne
On Mon, May 12, 2014 at 8:53 PM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in
> net/ipv6/xfrm6_output.c between commit 5596732fa8c1 ("xfrm: Fix crash
> with ipv6 IPsec tunnel and NAT") from the ipsec tree and commit
> 60ff746739bf ("net: ren
On Fri, Jul 25, 2014 at 9:38 AM, Jun Zhao wrote:
> ndm_type means L3 address type, in neighbour proxy and vxlan, it's
> RTN_UNICAST.
> NDA_DST is for netlink TLV type, hence it's not right value in this context.
>
Looks correct to me, at least libnl uses RTN_* for ndm_type.
--
To unsubscribe fro
On Sun, Jul 6, 2014 at 8:41 PM, Linus Lüssing wrote:
> diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h
> index fd22789..e0c575c 100644
> --- a/include/linux/if_bridge.h
> +++ b/include/linux/if_bridge.h
> @@ -36,8 +36,22 @@ extern void brioctl_set(int (*ioctl_hook)(struct net *,
(Please Cc netdev@ for networking bugs...)
On Thu, Apr 17, 2014 at 3:05 PM, Rich, Jason wrote:
> Greetings,
> Before we begin, please CC me directly when responding, thanks.
>
> I've recently upgraded my distribution to build the latest mellanox
> ConnectX(r)-3 EN Single/Dual-Port 10/40/56GbE dr
(Please Cc netdev@ for networking bugs...)
On Thu, Apr 17, 2014 at 10:40 AM, Marcin Gibula wrote:
> Hi,
>
> I've encountered these warnings on one of my servers running 3.12.17.
> Warning probably originates from bridge connecting virtual machines
> with bonded interface.
>
> Is this something I
On Fri, Jun 6, 2014 at 12:19 PM, Dmitry Popov wrote:
> ipv4_{update_pmtu,redirect} were called with tunnel's ifindex (t->dev is a
> tunnel netdevice). It caused wrong route lookup and failure of pmtu update or
> redirect. We should use the same ifindex that we use in ip_route_output_* in
> *tunnel
On Fri, Mar 28, 2014 at 8:21 PM, Jongman Heo wrote:
>
> Hi, guys,
>
> With today's linus git tree, I got following messages;
>
> [ 97.426196] =
> [ 97.426198] [ INFO: inconsistent lock state ]
> [ 97.426221] 3.14.0-rc8+ #45 Tainted: GW
> [ 97.426224]
On Mon, May 19, 2014 at 10:09 AM, Milos Vyletel wrote:
> As it is right now most of these tunables don't do anything - they don't
> set any interface specific settings to the desired value and they don't
> take precedence before device specific settings in most cases.
>
> Documentation/networking/
On Wed, May 21, 2014 at 9:42 PM, Jet Chen wrote:
> Hi Steffen,
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
>
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master
> commit 78ff4be45a4c51d8fb21ad92e4fabb467c6c3eeb
> Author: Steffen Klassert
> Au
On Tue, May 27, 2014 at 3:27 AM, Cyrill Gorcunov wrote:
> On Tue, May 27, 2014 at 01:20:13PM +0300, Kirill A. Shutemov wrote:
>> Cyrill Gorcunov wrote:
>> > Hi! While been trying to run criu on linux-next (due to recent Kirill's
>> > patch related
>> > to /proc/pid/clear_refs with THP enabled) I
On Tue, May 6, 2014 at 10:55 AM, wrote:
> On Tue, May 06, 2014 at 01:16:43PM -0400, David Miller wrote:
>> From: j...@joshtriplett.org
>> Date: Tue, 6 May 2014 09:41:08 -0700
>>
>> > Every KB of RAM costs real money and SoC die area (for eDRAM/eSRAM).
>>
>> Another poster commented that 16MB of D
On Mon, Jun 16, 2014 at 5:51 AM, Stefan Priebe - Profihost AG
wrote:
> Hi,
>
> i'm using a vanilla 3.10.43 kernel and netconsole on top of a bridge.
>
> netconsole is used with vmbr0 (bridge) which is on top of bond0.
>
> If i want to add another bridge to vmbr0 is fails as long as netconsole
> is
On Mon, Jun 16, 2014 at 11:41 AM, Stefan Priebe - Profihost AG
wrote:
>
>> Am 16.06.2014 um 20:05 schrieb Cong Wang :
>>
>> On Mon, Jun 16, 2014 at 5:51 AM, Stefan Priebe - Profihost AG
>> wrote:
>>> Hi,
>>>
>>> i'm using
On Mon, Jun 16, 2014 at 12:05 PM, Stefan Priebe - Profihost AG
wrote:
>
>> Am 16.06.2014 um 20:51 schrieb Cong Wang :
>>
>> On Mon, Jun 16, 2014 at 11:41 AM, Stefan Priebe - Profihost AG
>> wrote:
>>>
>>>> Am 16.06.2014 um 20:05 schrieb Cong
On Wed, Jun 25, 2014 at 1:42 PM, Zoltan Kiss wrote:
> This is a prototype patch to enable sending TCP packets with pktgen. The
> original motivation is to test TCP GSO with xen-netback/netfront, but I'm not
> sure about how the checksum should be set up, and also someone should verify
> the
> GSO
On Tue, Feb 4, 2014 at 6:19 AM, Geert Uytterhoeven wrote:
>
> Anyone with a clue?
>
Looks like we need:
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index ac2dff3..bdbf68b 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -1443,7 +1443,8 @@ static size_t inet_nlmsg_size(void)
On Mon, Feb 3, 2014 at 9:26 PM, Eric W. Biederman wrote:
> diff --git a/fs/file.c b/fs/file.c
> index 771578b33fb6..db25c2bdfe46 100644
> --- a/fs/file.c
> +++ b/fs/file.c
> @@ -34,7 +34,7 @@ static void *alloc_fdmem(size_t size)
> * vmalloc() if the allocation size will be considered "la
ady
> done for ipv6.
>
> Suggested-by: Cong Wang
> Signed-off-by: Geert Uytterhoeven
Signed-off-by: Cong Wang
Seems a candidate for -stable.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
On Sat, Oct 19, 2013 at 3:58 PM, Linus Lüssing wrote:
> While this commit was a good attempt to fix issues occuring when no
> multicast querier is present, this commit still has two more issues:
>
> 1) There are cases where mdb entries do not expire even if there is a
> querier present. The bridge
On Thu, Feb 6, 2014 at 1:33 PM, Carlos O'Donell wrote:
> On 02/06/2014 06:10 AM, Jan Moskyto Matejka wrote:
>> Reverting this change back to define's to fix the aliases.
>>
>> modinfo mip6 (before this change)
>> alias: xfrm-type-10-IPPROTO_DSTOPTS
>> alias: xfrm-type-10-IPPROTO_
On Thu, Jan 2, 2014 at 7:11 PM, Libo Chen wrote:
> Hi guys,
>
> Now, lxc created with veth can not be under control by
> cls_cgroup.
>
> the former discussion:
> http://lkml.indiana.edu/hypermail/linux/kernel/1312.1/00214.html
>
> In short, because cls_cgroup relys classid attached to sock
> filte
On Sun, Aug 24, 2014 at 1:21 PM, Alexei Starovoitov wrote:
> 'maps' is a generic storage of different types for sharing data between kernel
> and userspace.
>
> The maps are accessed from user space via BPF syscall, which has commands:
>
> - create a map with given type and attributes
> fd = bpf
From: Cong Wang
We saw a kernel soft lockup in perf_remove_from_context(),
it looks like the `perf` process, when exiting, could not go
out of the retry loop. Meanwhile, the target process was forking
a child. So either the target process should execute the smp
function call to deactive the
On Fri, Sep 5, 2014 at 4:32 PM, Rafael J. Wysocki wrote:
> On Saturday, September 06, 2014 07:45:54 AM Tejun Heo wrote:
>> Hello,
>>
>> On Fri, Sep 05, 2014 at 11:12:24AM -0700, Cong Wang wrote:
>> > > Rafael, can you please help?
>> >
>> > Raf
On Mon, Sep 8, 2014 at 1:54 PM, Rafael J. Wysocki wrote:
> On Monday, September 08, 2014 10:40:17 AM Cong Wang wrote:
>>
>> We asked you to comment on either if this patch is safe for PM freeze
>> if we don't have the cgroup_freezing() check, or if it is not safe why (s
On Mon, Sep 8, 2014 at 4:15 PM, Rafael J. Wysocki wrote:
> On Tuesday, September 09, 2014 07:50:12 AM Tejun Heo wrote:
>> Hello,
>>
>> On Tue, Sep 09, 2014 at 12:48:28AM +0200, Rafael J. Wysocki wrote:
>> > Well, not exactly from anywhere. Just from where try_to_freeze() is called
>> > I suppose?
On Mon, Sep 8, 2014 at 4:23 PM, Rafael J. Wysocki wrote:
>
> The reason why it matters for the suspend-time freezing is that we freeze
> tasks
> to take them out of the picture entirely until they are thawed. Therefore we
> can't allow them to go back to the picture just for a while until they a
On Mon, Sep 8, 2014 at 4:42 PM, Rafael J. Wysocki wrote:
> On Monday, September 08, 2014 04:16:15 PM Cong Wang wrote:
>> On Mon, Sep 8, 2014 at 4:23 PM, Rafael J. Wysocki wrote:
>> >
>> > The reason why it matters for the suspend-time freezing is that we freeze
>&
On Mon, Sep 8, 2014 at 4:54 PM, Trond Myklebust
wrote:
> On Wed, Aug 27, 2014 at 6:41 PM, Al Viro wrote:
>> On Tue, Aug 19, 2014 at 09:20:38PM -0700, Eric W. Biederman wrote:
>>> Cong Wang writes:
>>>
>>> > I saw the following kernel warning:
>>&g
On Mon, Sep 8, 2014 at 2:25 PM, Andres Freund wrote:
> Hi,
>
> (don't have netdev archived, thus answering here, sorry)
>
> On 2014-09-07 16:41:09 -0700, David Miller wrote:
>> Alexander Y. Fomichev (1):
>> net: prevent of emerging cross-namespace symlinks
>
Since you are quoting this chang
On Tue, Sep 9, 2014 at 1:48 PM, Rafael J. Wysocki wrote:
> On Wednesday, September 10, 2014 12:23:36 AM Tejun Heo wrote:
>> On Tue, Sep 09, 2014 at 05:16:55PM +0200, Michal Hocko wrote:
>> > But OOM killer doesn't kill kernel threads as they do not own any
>> > memory. So the check should be safe,
On Tue, Aug 19, 2014 at 7:50 PM, Jiang Liu wrote:
> Hi Kujau,
> It seems like a different issue, something wrong with
> void nfs_fs_proc_net_exit(struct net *net)
http://marc.info/?l=linux-nfs&m=140821782107427&w=2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Wed, Sep 3, 2014 at 8:42 AM, Tejun Heo wrote:
> Hello, Cong.
>
> On Tue, Sep 02, 2014 at 03:52:40PM -0700, Cong Wang wrote:
>> diff --git a/kernel/freezer.c b/kernel/freezer.c
>> index 33cbcb0..b06a059 100644
>> --- a/kernel/freezer.c
>> +++ b/kernel/freezer.c
__thaw_task() no longer clears frozen flag since commit a3201227f803
(freezer: make freezing() test freeze conditions in effect instead of
TIF_FREEZE).
Cc: David Rientjes
Cc: "Rafael J. Wysocki"
Cc: Tejun Heo
Cc: Andrew Morton
Cc: Michal Hocko
Reviewed-by: Michal Hocko
Signed-of
es
Cc: Michal Hocko
Cc: "Rafael J. Wysocki"
Cc: Tejun Heo
Cc: Andrew Morton
Acked-by: Michal Hocko
Signed-off-by: Cong Wang
---
kernel/freezer.c | 18 --
mm/oom_kill.c| 2 --
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/kernel/freezer.c b/
On Fri, Sep 5, 2014 at 7:08 AM, Tejun Heo wrote:
>> + /* It might not be safe to check TIF_MEMDIE for pm freeze. */
>
> This is just another representation of the following code which isn't
> particularly useful. Wouldn't it be better if the comment actually
> explains why this might not be s
On Fri, Sep 5, 2014 at 7:08 AM, Tejun Heo wrote:
>
> Prolly should sta...@vger.kernel.org?
Oh, yes. I assume the maintainer (Michal?) will send it to stable
once it is accepted, or I can do that after it is merged.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Fri, Sep 5, 2014 at 11:00 AM, Tejun Heo wrote:
> On Fri, Sep 05, 2014 at 09:31:50AM -0700, Cong Wang wrote:
>> On Fri, Sep 5, 2014 at 7:08 AM, Tejun Heo wrote:
>> >> + /* It might not be safe to check TIF_MEMDIE for pm freeze. */
>> >
>> > Thi
ASSERT_RTNL() up a level in the call stack.
>>
>> Signed-off-by: Cong Wang
>> Signed-off-by: Sabrina Dubroca
>> Reported-by: Tommi Rantala
>
> Applied and queued up for -stable, thanks.
I believe you applied a wrong version, at least the following
is not correct:
On Fri, Sep 5, 2014 at 12:12 PM, Hannes Frederic Sowa
wrote:
>
> What games are you playing? You know how patches are processed by David
> and I even let him the choice by pointing out a problem in your patch so
> that you could an update and send v2.
I assume David goes over all the discussion b
On Fri, Sep 5, 2014 at 12:25 PM, David Miller wrote:
>
> I thought the retention of RCU locking was reasonable, and that your
> feedback was something I disagreed with.
>
> This is different from ignoring your feedback.
The point is we don't need to backport the patch that far, as I already
menti
] ? ipv6_sock_ac_join+0x99/0x360
> [ 77.307798] [] do_ipv6_setsockopt.isra.5+0xa70/0xf20
I think we should just use rtnl_lock() instead of rcu_read_lock() there,
it is not a hot path worth optimization.
Please try the attached patch.
commit 31d83db0b417f705cbb31b2159603b8b53b81ab6
Author: Cong Wang
Date: Fri
On Fri, Aug 29, 2014 at 12:53 PM, Sabrina Dubroca wrote:
> 2014-08-29, 11:14:48 -0700, Cong Wang wrote:
>> On Fri, Aug 29, 2014 at 8:26 AM, Tommi Rantala wrote:
>> > [ 77.297196] RTNL: assertion failed at net/ipv6/addrconf.c (1699)
>> > [ 77.298080] CPU: 0 PID:
On Tue, Sep 2, 2014 at 1:29 AM, Sabrina Dubroca wrote:
>
> v2:
> - based on net
> - keep dev_get_by_flags_rcu and RCU in ipv6_sock_ac_*
> - remove two ASSERT_RTNL() that are not necessary
There is no point to keep RCU here. Hannes' reply doesn't make
any sense.
--
To unsubscribe from this list
On Fri, Aug 29, 2014 at 6:51 PM, Hannes Frederic Sowa
wrote:
>
> Also rtnl_lock and rcu_read_lock compose in that order, so we don't need
> to change dev_get_by_flags, but as this is the only user it sure is
> possible. RCU locked version is just easier composeable, so I wouldn't
> touch that if n
On Tue, Sep 2, 2014 at 10:58 AM, Hannes Frederic Sowa
wrote:
> Hi Cong,
>
> On Tue, Sep 2, 2014, at 18:50, Cong Wang wrote:
>> On Fri, Aug 29, 2014 at 6:51 PM, Hannes Frederic Sowa
>> wrote:
>> >
>> > Also rtnl_lock and rcu_read_lock compose in that
On Tue, Sep 2, 2014 at 11:11 AM, Eric Dumazet wrote:
> On Tue, 2014-09-02 at 11:04 -0700, Cong Wang wrote:
>> On Tue, Sep 2, 2014 at 10:58 AM, Hannes Frederic Sowa
>
>> > I definitely don't have a problem cleaning this up in net-next. I wanted
>> > a minima
On Tue, Sep 2, 2014 at 11:21 AM, Eric Dumazet wrote:
> On Tue, 2014-09-02 at 11:15 -0700, Cong Wang wrote:
>
>> That is what we do when backporting patches, I can do that if David asks
>> me to backport it, but you know for netdev that is David's work.
>>
>> (I
On Tue, Sep 2, 2014 at 11:18 AM, Hannes Frederic Sowa
wrote:
> Those ASSERT_RTNLs were misplaced and only caught the callers mostly
> from addrconf.c. I don't mind getting reports from stable kernel users
> and fixing those, too (or help fixing those). ASSERT_RTNL is not
> dangerous.
>
> We had a
On Tue, Sep 2, 2014 at 12:02 PM, Hannes Frederic Sowa
wrote:
>
> If fixes tag is well researched, it won't point to the addition of
> ASSERT_RTNL() but your patch would help to discover a bug somewhere else
> in the stack.
>
> I think for this patch a fixes-tag is hard to find because it is hard t
On Mon, Sep 1, 2014 at 1:38 AM, Peter Zijlstra wrote:
> On Thu, Aug 28, 2014 at 04:27:35PM -0700, Cong Wang wrote:
>> From: Cong Wang
>>
>> We saw a kernel soft lockup in perf_remove_from_context(),
>> it looks like the `perf` process, when exiting, could not
From: Cong Wang
We saw a kernel soft lockup in perf_remove_from_context(),
it looks like the `perf` process, when exiting, could not go
out of the retry loop. Meanwhile, the target process was forking
a child. So either the target process should execute the smp
function call to deactive the
On Sat, Aug 16, 2014 at 5:20 AM, Tejun Heo wrote:
> On Thu, Aug 14, 2014 at 02:15:25PM -0700, Cong Wang wrote:
>> +static bool should_thaw_current(bool check_kthr_stop)
>> +{
>> + if (!freezing(current) ||
>> + (check_kthr_
ael J. Wysocki"
Cc: Tejun Heo
Cc: Andrew Morton
Signed-off-by: Cong Wang
---
diff --git a/kernel/freezer.c b/kernel/freezer.c
index aa6a8aa..c6d189d 100644
--- a/kernel/freezer.c
+++ b/kernel/freezer.c
@@ -68,7 +68,9 @@ bool __refrigerator(bool check_kthr_stop)
spi
On Fri, Aug 8, 2014 at 7:00 PM, Kyungmin Park wrote:
>
> Similar patch is posted and discussed but no conclusion.
> http://marc.info/?t=13769976944&r=1&w=1
>
I noticed this thread before sending my patch. I don't think
we are trying to solve the same problem:
a) I only care OOM kill, not oth
On Sat, Aug 9, 2014 at 1:55 AM, David Rientjes wrote:
> On Fri, 8 Aug 2014, Cong Wang wrote:
>
>> diff --git a/kernel/freezer.c b/kernel/freezer.c
>> index aa6a8aa..c6d189d 100644
>> --- a/kernel/freezer.c
>> +++ b/kernel/freezer.c
>> @@ -68,7 +68,9 @@ bool
On Mon, Aug 11, 2014 at 6:18 AM, Michal Hocko wrote:
>
> OK, so the system/memcg is still OOM and a new allocation/charge
> would trigger killer again, right? Then oom_scan_process_thread sees
> TIF_MEMDIE frozen task and thaw it so it can go away and die. So this
> shouldn't be a permanent state.
Rientjes
Cc: Michal Hocko
Cc: "Rafael J. Wysocki"
Cc: Tejun Heo
Cc: Andrew Morton
Signed-off-by: Cong Wang
---
kernel/freezer.c | 19 +++
mm/oom_kill.c| 2 --
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/kernel/freezer.c b/kernel/freezer.c
index
Gleixner
Cc: Ingo Molnar
Cc: David Rientjes
Cc: Michal Hocko
Cc: "Rafael J. Wysocki"
Cc: Tejun Heo
Cc: Andrew Morton
Signed-off-by: Cong Wang
---
arch/x86/mm/fault.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index a241946..ad97
On Tue, Aug 12, 2014 at 5:09 AM, Michal Hocko wrote:
> On Mon 11-08-14 17:53:55, Cong Wang wrote:
>> When a process triggers a page fault and kernel keeps
>> trying to retry the fault, there is no chance for this process
>> to be frozen, so the freeze request will always be p
On Tue, Aug 12, 2014 at 4:44 AM, Michal Hocko wrote:
> Has it stopped working as a result of a3201227f803 (freezer: make
> freezing() test freeze conditions in effect instead of TIF_FREEZE)?
> It removes clear_freeze_flag from __thaw_task and so the OOM victim
> cannot escape from the refrigerator
On Wed, Aug 13, 2014 at 2:26 AM, Michal Hocko wrote:
> On Tue 12-08-14 17:53:33, Cong Wang wrote:
>> On Tue, Aug 12, 2014 at 4:44 AM, Michal Hocko wrote:
> [...]
>> >> @@ -147,12 +156,6 @@ void __thaw_task(struct task_struct *p)
>> >>
On Wed, Aug 13, 2014 at 2:36 AM, Michal Hocko wrote:
> On Tue 12-08-14 17:47:02, Cong Wang wrote:
> [...]
>> Does the following updated patch make any sense to you? If not, I will just
>> drop it.
>
> Not really to be honest. I do not see what problem you are trying to fi
On Thu, Aug 14, 2014 at 2:41 AM, Stephane Chazelas
wrote:
> By the way, this is related:
>
> $ ip link add link eth0 eth0:123 type vlan id 123
> $ ip link del link eth0 eth0:123
> RTNETLINK answers: Operation not supported
Kernel reads "eth0:123" as an alias of "eth0", so it will just
truncate th
es
Cc: Michal Hocko
Cc: "Rafael J. Wysocki"
Cc: Tejun Heo
Cc: Andrew Morton
Acked-by: Michal Hocko
Signed-off-by: Cong Wang
---
kernel/freezer.c | 13 +++--
mm/oom_kill.c| 2 --
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/kernel/freezer.c b/
__thaw_task() no longer clears frozen flag.
Cc: David Rientjes
Cc: "Rafael J. Wysocki"
Cc: Tejun Heo
Cc: Andrew Morton
Cc: Michal Hocko
Signed-off-by: Cong Wang
---
kernel/freezer.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/kernel/freezer.c b/kernel/freezer.c
ind
n nfs_fs_proc_net_exit().
Fixes: commit 65b38851a17 (NFS: Fix /proc/fs/nfsfs/servers and
/proc/fs/nfsfs/volumes)
Cc: Eric W. Biederman
Cc: Trond Myklebust
Cc: Stanislav Kinsbursky
Signed-off-by: Cong Wang
---
fs/nfs/client.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/nfs/
On Fri, Aug 15, 2014 at 1:33 AM, Stephane Chazelas
wrote:
> Yes, I know those are also used for the eth0:1 "aliases", but the bug
> is, since it is allowed to do
>
> ip link add link eth0 eth0:123 type vlan id 123
>
> Then the
>
> ip link del link eth0 eth0:123
>
> should be allowed as we
On Sat, Aug 16, 2014 at 5:20 AM, Tejun Heo wrote:
> On Thu, Aug 14, 2014 at 02:15:25PM -0700, Cong Wang wrote:
>> +static bool should_thaw_current(bool check_kthr_stop)
>> +{
>> + if (!freezing(current) ||
>> + (check_kthr_
n nfs_fs_proc_net_exit().
Fixes: commit 65b38851a17 (NFS: Fix /proc/fs/nfsfs/servers and
/proc/fs/nfsfs/volumes)
Cc: Eric W. Biederman
Cc: Trond Myklebust
Cc: Dan Aloni
Signed-off-by: Cong Wang
---
v2 - fix nfs_fs_proc_net_init() as well
fs/nfs/client.c | 4 ++--
1 file changed, 2 insertions(+), 2 de
On Fri, Aug 1, 2014 at 5:32 AM, Fengguang Wu wrote:
> Hi Anish,
>
> FYI, here is one more bug message for
>
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> commit 759a0cc5a3e1bc2cc48fa3c0b91bdcad8b8f87d6 ("cxgb4i: Add ipv6 code to
> driver, call into libcxgbi ipv6 api
301 - 400 of 884 matches
Mail list logo
