(Adding Paul and Eric in Cc)
I am not aware of any change in net/core/dev.c related here,
so I guess it's a bug in rcu_barrier().
Thanks.
On Wed, Oct 22, 2014 at 10:12 AM, Josh Boyer wrote:
>
> Someone else is seeing this when they try and modprobe ppp_generic:
>
> [ 240.599195] INFO: task kwo
t;
> and the following glibc commit:
> 6c82a2f8d7c8e21e39237225c819f182ae438db3 Coordinate IPv6 definitions for
> Linux and glibc
>
> so actually include the header now.
>
> Reported-by: Colin Guthrie
> Reported-by: Christiaan Welvaart
> Reported-by: Thomas Backlund
> Cc: Florian Fainelli
&
(Adding netdev@...)
On Wed, Oct 29, 2014 at 9:16 AM, Peter Zijlstra wrote:
>
> Dave, this relies on bits currently in tip/sched/core, if you're ok I'll
> merge it through that tree.
>
> ---
> Subject: netdev: Fix sleeping inside wait event
> From: Peter Zijlstra
> Date: Wed Oct 29 17:04:56 CET 2
On Mon, Oct 6, 2014 at 2:51 PM, Joe Perches wrote:
> John, can you please verify that these gen_stats accesses
> are unnecessary? I believe the compiler can elide them in
> any case, but I'm not sure what you intended here.
>
> net/core/dev.c | 4 ++--
> net/core/gen_stats.c | 4
> ne
Hello again,
I realized it is a series of patch actually:
3812c8c8f3953921ef18544110dafc3505c1ac62 mm: memcg: do not trap
chargers with full callstack on OOM
fb2a6fc56be66c169f8b80e07ed999ba453a2db2 mm: memcg: rework and
document OOM waiting and wakeup
519e52473ebe9db5cdef44670d5a97f1fd53d721 mm:
On Fri, Oct 3, 2014 at 8:13 AM, Michal Hocko wrote:
>
> That commit fixes an OOM deadlock. Not a soft lockup. Do you have the
> OOM killer report from the log? This would tell us that the killed task
> was indeed sleeping on the lock which is hold by the charger which
> triggered the OOM. I am lit
On Fri, Oct 3, 2014 at 8:37 AM, Michal Hocko wrote:
> On Thu 02-10-14 14:04:08, Cong Wang wrote:
>> Hello again,
>>
>> I realized it is a series of patch actually:
>>
>> 3812c8c8f3953921ef18544110dafc3505c1ac62 mm: memcg: do not trap
>&
On Fri, Oct 3, 2014 at 11:16 AM, Cong Wang wrote:
>
> Why not? OOM killer tries to kill a process sleeping on a mutex it already
> holds, why not a deadlock? Given the fact that both are lots of inode mutex
> hung because of OOM, I am 90% sure they are the same.
>
I backported t
(Cc'ing netdev for network issues)
On Tue, Aug 4, 2015 at 6:42 AM, Shaun Crampton
wrote:
> Please CC me on any responses, thanks.
>
> Setting both ends of a veth to be oper UP completes very quickly but I
> find that pings only start flowing over the veth after about a second.
> This seems to cor
On Tue, Aug 4, 2015 at 7:39 PM, Nicholas Krause wrote:
> From: Nicholas Krause
>
> This fixes the issue with conncurrent access when calling the function
> inte6_addr_del due to this function using non locked wrapper versions
> of certain functions by locking the routing mutex before and after th
On Mon, Aug 3, 2015 at 10:29 PM, Sowmini Varadhan
wrote:
> +static struct pernet_operations rds_tcp_net_ops = {
> + .init = rds_tcp_init_net,
> + .exit = rds_tcp_exit_net,
> + .id = &rds_tcp_netid,
> + .size = sizeof(struct rds_tcp_net),
> +};
> +
> +static void rds_tcp_kil
On Mon, Jul 6, 2015 at 9:40 PM, wrote:
> From: Byungchul Park
>
> __sched_period() returns a period which a rq can have. the period has to be
> stretched by the number of task *the rq has*, when nr_running > nr_latency.
> otherwise, task slice can be very smaller than sysctl_sched_min_granularit
On Mon, Jul 6, 2015 at 5:15 PM, Steven Rostedt wrote:
> On Mon, 6 Jul 2015 12:15:45 -0700
> Cong Wang wrote:
>
>> Currently we only have one sched_switch trace event
>> for task switching, which is generated very early during
>> task switch. When we try to monitor p
On Mon, Jul 6, 2015 at 11:45 PM, Peter Zijlstra wrote:
> On Mon, Jul 06, 2015 at 12:15:45PM -0700, Cong Wang wrote:
>> Currently we only have one sched_switch trace event
>> for task switching, which is generated very early during
>> task switch. When we try to monit
Hi, Michael
I just got the following kernel bug while working on Dave's net tree
in a KVM guest. It looks like a bug in virtio.
Let me know if you need more information.
[ 69.816089] BUG kmalloc-64 (Not tainted): Poison overwritten
[ 69.816089]
-
On Tue, Aug 25, 2015 at 2:11 PM, Cong Wang wrote:
> Hi, Michael
>
> I just got the following kernel bug while working on Dave's net tree
> in a KVM guest. It looks like a bug in virtio.
>
Hmm, the stack trace is misleading, it could be caused by my own networking
code even th
(CC'ing netdev)
On Sat, Aug 15, 2015 at 7:20 PM, Jon Christopherson wrote:
> Hello All,
>
> the recent commit (26b552e0a85ba7e74d384a9624d83118d38071f7) causes
> softlocks on my system using the e1000e driver. Kernel builds before this
> commit do not experience the behavior. I have opened a bug
On Mon, May 16, 2016 at 11:40 AM, David Binderman
wrote:
> Hello there,
>
> linux-4.6/net/kcm/kcmsock.c:1508]: (style) Checking if unsigned
> variable 'copied' is less than zero.
>
> Source code is
>
> if (copied < 0) {
>
> but
>
>size_t copied;
>
> Suggest code rework.
Thanks for the rep
On Tue, May 17, 2016 at 9:44 AM, David Miller wrote:
> From: Cong Wang
> Date: Tue, 17 May 2016 09:04:21 -0700
>
>> On Mon, May 16, 2016 at 11:40 AM, David Binderman
>> wrote:
>>> Hello there,
>>>
>>> linux-4.6/net/kcm/kcmsock.c:1508]: (style) Ch
On Wed, Dec 16, 2015 at 11:34 AM, Dmitry Vyukov wrote:
> BUG: KASAN: slab-out-of-bounds in sock_setsockopt+0x1284/0x13d0 at
> addr 88006563ec10
> Read of size 4 by task syzkaller_execu/4755
> =
> BUG RAWv6 (Not tainted
On Wed, Dec 30, 2015 at 6:30 AM, Jacob Siverskog
wrote:
> On Wed, Dec 30, 2015 at 2:26 PM, Eric Dumazet wrote:
>> How often can you trigger this bug ?
>
> Ok. I don't have a good repro to trigger it unfortunately, I've seen it just a
> few times when bringing up/down network interfaces. Does the
On Fri, Jan 1, 2016 at 5:58 AM, Dmitry Vyukov wrote:
>
> kasan: GPF could be caused by NULL-ptr deref or user memory
> accessgeneral protection fault: [#51] SMP KASAN
> Modules linked in:
> CPU: 2 PID: 4207 Comm: a.out Not tainted 4.4.0-rc7+ #184
> Hardware name: QEMU Standard PC (i440FX + PI
On Fri, Jan 1, 2016 at 12:58 PM, Cong Wang wrote:
>
> It looks like we forget to initialize ->service_name_len
> and ->servicce_name before bind().
Never mind, __GFP_ZERO is passed in sk_alloc()...
--
To unsubscribe from this list: send the line "unsubscribe linux-kern
On Fri, Jan 1, 2016 at 5:58 AM, Dmitry Vyukov wrote:
> GPF seems to be caused by a data race on socket state.
Seems you are right, I think the following patch should work:
diff --git a/net/nfc/llcp_sock.c b/net/nfc/llcp_sock.c
index ecf0a01..5a91997 100644
--- a/net/nfc/llcp_sock.c
+++ b/net/nfc
On Tue, Feb 16, 2016 at 6:43 PM, Anton Protopopov
wrote:
> An error response from a RTM_GETNETCONF request can return the positive
> error value EINVAL in the struct nlmsgerr that can mislead userspace.
>
> Signed-off-by: Anton Protopopov
LGTM,
Acked-by: Cong Wang
On Fri, Feb 26, 2016 at 8:40 PM, zhao ya wrote:
> From: Zhao Ya
> Date: Sat, 27 Feb 2016 10:06:44 +0800
> Subject: [PATCH] IPIP tunnel performance improvement
>
> bypass the logic of each packet's own neighbour creation when using
> pointopint or loopback device.
>
> Recently, in our tests, met a
On Mon, Feb 22, 2016 at 2:05 AM, Dmitry Vyukov wrote:
> unreferenced object 0x8800628991d8 (size 4096):
> comm "a.out", pid 7081, jiffies 4294920662 (age 35.917s)
> hex dump (first 32 bytes):
> 00 00 00 00 00 00 00 00 61 78 30 00 00 00 00 00 ax0.
> 00 00 00 00 00 00 00
On Wed, Nov 19, 2014 at 11:46 AM, David Miller wrote:
>
> Often the issue with TX return values is lack of clear documentation
> and use cases.
>
NET_XMIT_* are marked as qdisc ->enqueue() return codes
in include/linux/netdevice.h, and are indeed used mostly by
qdisc:
$ git grep NET_XMIT_ -- net
On Mon, Nov 17, 2014 at 9:20 PM, Jason Wang wrote:
> After commit 5d097109257c03a71845729f8db6b5770c4bbedc
> ("tun: only queue packets on device"), NETDEV_TX_OK was returned for
> dropped packets. This will confuse pktgen since dropped packets were
> counted as sent ones.
>
> Fixing this by return
On Tue, Nov 18, 2014 at 8:22 AM, Pankaj Gupta wrote:
>
> As vmalloc() adds overhead on a critical network path,
> __GFP_REPEAT flag is used with kzalloc() to do this fallback
> only when really needed.
>
Are you sure we need __GFP_REPEAT? We have vmalloc() as
fallback of kmalloc() in many places
On Thu, Oct 16, 2014 at 1:39 PM, Oleg Nesterov wrote:
>> Fix the issue by checking for TIF_MEMDIE thread flag and get away from the
>> fridge if it is set. oom_scan_process_thread doesn't have to check for
>> the frozen task anymore because do_send_sig_info will wake up the thread
>> and TIF_MEMD
On Thu, Oct 16, 2014 at 2:11 PM, Oleg Nesterov wrote:
>
> But also I can't understand why this patch helps. The changelog says:
>
> do_send_sig_info will wake up the thread
>
> why?
>
This is a question for Michal who rewrites my changelog:
http://marc.info/?l=linux-kernel&m=140986986423
On Thu, Oct 16, 2014 at 2:35 PM, Oleg Nesterov wrote:
>
> If a task B is already frozen, it sleeps in D state.
>
> If OOM selects B as a victim after that, it won't be woken by
> SIGKILL, thus it obviously can't call should_thaw_current() and
> notice TIF_MEMDIE.
I see your point now, it would be
On Thu, Oct 16, 2014 at 3:22 PM, Oleg Nesterov wrote:
> On 10/16, Cong Wang wrote:
>>
>> On Thu, Oct 16, 2014 at 2:35 PM, Oleg Nesterov wrote:
>> >
>> > If a task B is already frozen, it sleeps in D state.
>> >
>> > If OOM selects B as a victim
se
> the 1st patch basically opens a race window fixed by the later patch.
> Original patch from Cong Wang has covered this by cgroup_freezing(current)
> check in should_thaw_current(). But this approach still suffers from OOM
> vs. PM freezer interaction (OOM killer would still live loc
On Tue, Oct 7, 2014 at 5:33 AM, Michal Hocko wrote:
> On Fri 03-10-14 11:16:31, Cong Wang wrote:
>> I am sorry to confuse you that it is my the above test case which caused
>> this bug. No, we saw this bug in *production* in our data center, it happened
>> on 30+ machines!
On Thu, Oct 9, 2014 at 9:05 AM, Omar Sandoval wrote:
> textsearch_find zeroes out the offset, but the control buffer (which may or
> may
> not matter in this case) needs to be zeroed out as well.
Why? skb_prepare_seq_read() initializes the cb.
Also, the comment says:
* @state: uninitialized t
On Wed, May 20, 2015 at 2:10 PM, Alex Gartrell wrote:
> Hey everyone,
>
> tl;dr; pure python generic netlink library with simple clients for ipvs and
> taskstats here: https://github.com/facebook/gnlpy
libnl should have python support for generic netlink too:
$ ls python/netlink/genl/
capi.i __
On Thu, May 21, 2015 at 5:56 PM, Linus Lüssing wrote:
> diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
> index 2d69d5c..066199e 100644
> --- a/net/bridge/br_multicast.c
> +++ b/net/bridge/br_multicast.c
> @@ -1775,8 +1775,6 @@ int br_multicast_set_router(struct net_bridge *br,
On Thu, May 21, 2015 at 8:17 PM, Herbert Xu wrote:
> On Thu, May 21, 2015 at 08:11:32PM -0700, Cong Wang wrote:
>>
>> For me it looks like we do use p->rlist in BH context, but I could easily
>> miss something here.
>
> Because the caller disables BH for us.
>
R
On Fri, May 22, 2015 at 6:32 AM, Linus Lüssing wrote:
> Changelog v2:
> * remove another now unnecessary -ENOENT initialization
> * consistently initialize to -EINVAL, allowing to shorten two switch-cases
>
Looks perfect now. :)
Thanks for update.
--
To unsubscribe from this list: send the line
On Fri, May 22, 2015 at 8:18 AM, Thadeu Lima de Souza Cascardo
wrote:
> When more than a multicast address is present in a MLDv2 report, all but
> the first address is ignored, because the code breaks out of the loop if
> there has not been an error adding that address.
>
> This has caused failure
(Cc'ing netdev.)
On Sat, May 2, 2015 at 5:29 AM, Wolfgang Walter wrote:
> Am Samstag, 2. Mai 2015, 02:16:36 schrieb Wolfgang Walter:
>> Hello,
>>
>> kernel 4.0 (and 4.0.1) crashes immediately when I use traceroute6 with an
>> isatap-tunnel.
>
> I did some further tests. To trigger the crash you n
(Cc'ing netdev and netfilter-devel)
On Mon, May 11, 2015 at 2:29 AM, Klaus Ethgen wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Recently I tried to mitigate some slow attacks via netfilter rule
> utilizing hashlimit target. I used the following specification:
>
>-A DETECT_INV
On Fri, Feb 6, 2015 at 6:17 PM, Rasmus Villemoes
wrote:
> src_ip is a pointer to a union vxlan_addr, one member of which is a
> struct sockaddr. Passing a pointer to src_ip is wrong; one should pass
> the value of src_ip itself. Since %pIS formally expects something of
> type struct sockaddr*, let
On Sat, Feb 7, 2015 at 4:34 AM, Rasmus Villemoes
wrote:
> On Sat, Feb 07 2015, Cong Wang wrote:
>
>> On Fri, Feb 6, 2015 at 6:17 PM, Rasmus Villemoes
>> wrote:
>>> src_ip is a pointer to a union vxlan_addr, one member of which is a
>>> struct sockaddr. Passi
On Wed, Feb 4, 2015 at 1:57 AM, Jinpu Wang wrote:
> Hi,
>
> I hit WARNING below after update to 3.19-rc6, when I running fio with libaio.
> Any one see this warning before, or maybe know how to fix it?
>
> From the call trace:
> (gdb) list *read_events+0x1e8
> 0x81225ad8 is in read_events
(Cc'ing netdev and netfilter-devel lists)
On Wed, Feb 11, 2015 at 10:31 AM, Chris Vine
wrote:
> On Wed, 11 Feb 2015 09:28:34 +
> Chris Vine wrote:
>> With kernel 3.19.0, the following iptables rule, where SSH_TRIES is
>> set to 4:
>>
>> iptables -D SSH_CHAIN -m conntrack --ctstate NEW \
>>
On Thu, Feb 12, 2015 at 6:33 PM, nick wrote:
> Greets to Everyone,
> I am wondering after running sparse on the latest mainline tree why we are
> not unlocking the spinlock_bh,lock when calling the function,
> gnet_stats_start_copy_compat at the end of this function's body. Unless
> someone can
riable which will be needed once multiple
> instances (per netns) of garbage collector are allowed.
>
> Signed-off-by: Michal Kubecek
Reviewed-by: Cong Wang
Thanks.
ers in other namespaces.
>
> Replace the global list with per-netns lists (and give each its own
> lock).
>
> Signed-off-by: Michal Kubecek
> ---
> v2: get rid of ifdef in ipv6_route_seq_setup_walk(), pass net from
> callers instead
Reviewed-by: Cong Wang
gt; Signed-off-by: Michal Kubecek
Reviewed-by: Cong Wang
On Wed, Apr 6, 2016 at 6:10 AM, Lars Persson wrote:
> A failure in validate_xmit_skb_list() triggered an unconditional call
> to dev_requeue_skb with skb=NULL. This slowly grows the queue
> discipline's qlen count until all traffic through the queue stops.
>
Sounds reasonable.
> Fixes: 55a93b3ea
On Sat, Apr 2, 2016 at 6:55 AM, Dmitry Vyukov wrote:
> Hello,
>
> The following program leads to memory leaks in:
>
> unreferenced object 0x88005c10d208 (size 96):
> comm "a.out", pid 10753, jiffies 4296778619 (age 43.118s)
> hex dump (first 32 bytes):
> e8 31 85 2d 00 88 ff ff 0f 00 0
he case of skb=NULL. So should it be there in this patch, another patch
>>> or not at all ?
>>
>>
>> Then maybe change return code ?
>>
>> It seems strange that a validate_xmit_skb_list() failure stops the
>> __qdisc_run() loop but schedules another ro
xmit_skb_list() failure stops the
>> > __qdisc_run() loop but schedules another round.
>> >
>> >
>>
>> It was suggested by Cong Wang to return 0 in order to stop the loop. Do
>> you guys agree that the loop should be stopped for such failures ?
On Mon, Apr 11, 2016 at 11:30 AM, Eric Dumazet wrote:
> On Mon, 2016-04-11 at 11:26 -0700, Eric Dumazet wrote:
>> On Mon, 2016-04-11 at 11:02 -0700, Cong Wang wrote:
>>
>> > I am fine with either way as long as the loop stops on failure.
>
>
> Note that skb that
(Cc'ing Jamal)
On Wed, Sep 30, 2015 at 5:49 PM, Vinson Lee wrote:
> Hi.
>
> We've hit this GPF on several different machines on Linux 4.1.
>
> general protection fault: [#1] SMP
> Modules linked in: sch_htb cls_basic act_mirred cls_u32 veth
> sch_ingress netconsole configfs cpufreq_ondemand
On Mon, Nov 2, 2015 at 7:22 AM, Sasha Levin wrote:
> Hi all,
>
> While fuzzing with syzkaller inside a KVM tools guest running the latest
> -next, I saw
> the following warning:
>
> [ 2391.993558] ==
> [ 2391.995441] [ INFO: possible circular lo
On Mon, Nov 2, 2015 at 1:31 PM, Cong Wang wrote:
>
> Good catch!
>
> This is probably introduced by:
>
> commit baf606d9c9b12517e47e0d1370e8aa9f7323f210
> Author: Marcelo Ricardo Leitner
> Date: Wed Mar 18 14:50:42 2015 -0300
>
> ipv4,ipv6: grab rtnl befo
On Mon, Nov 2, 2015 at 6:11 AM, Denys Fedoryshchenko
wrote:
> Hi!
>
> Actually seems i was getting this panic for a while (once per week) on
> loaded pppoe server, but just now was able to get full panic message.
> After checking commit logs on sch_fq.c i didnt seen any fixes, so probably
> upgrad
On Sun, Sep 8, 2019 at 12:29 AM Hillf Danton wrote:
>
>
> > syzbot found the following crash on Sat, 07 Sep 2019 23:08:08 -0700
> >
> > HEAD commit:3b47fd5c Merge tag 'nfs-for-5.3-4' of git://git.linux-nfs...
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.
#syz fix: net/sched: cbs: Set default link speed to 10 Mbps in cbs_set_port_rate
On Sun, Sep 8, 2019 at 10:19 AM Linus Torvalds
wrote:
> I see two solutions:
>
> (a) move the
>
> q->qdisc = &noop_qdisc;
>
> up earlier in sfb_init(), so that qdisc is always initialized
> after sfb_init(), even on failure.
>
> (b) just make qdisc_put(NULL) just silently work as a
On Fri, Aug 30, 2019 at 12:06 PM David Dai wrote:
> - if (p->peak_present)
> + if ((police->params->rate.rate_bytes_ps >= (1ULL << 32)) &&
> + nla_put_u64_64bit(skb, TCA_POLICE_RATE64,
> + police->params->rate.rate_bytes_ps,
On Fri, Aug 30, 2019 at 1:03 PM David Z. Dai wrote:
>
> On Fri, 2019-08-30 at 12:11 -0700, Cong Wang wrote:
> > On Fri, Aug 30, 2019 at 12:06 PM David Dai wrote:
> > > - if (p->peak_present)
> > > + if ((police->param
s_write
=> ksys_write
=> do_syscall_64
=> entry_SYSCALL_64_after_hwframe
The only thing that can't be injected is string pointers as they
require constant string pointers, this can't be done at run time.
Cc: Steven Rostedt
Cc: Ingo Molnar
Signed-off-by: Cong Wang
---
v3:
by: David Dai
> Signed-off-by: David Dai
Acked-by: Cong Wang
Thanks.
#syz fix: sch_hhf: ensure quantum and hhf_non_hh_weight are non-zero
#syz fix: sch_hhf: ensure quantum and hhf_non_hh_weight are non-zero
ot.com/x/repro.syz?x=10753bc160
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=111dfc1160
>
> The bug was bisected to:
>
> commit b9a1e627405d68d475a3c1f35e685ccfb5bbe668
> Author: Cong Wang
> Date: Thu Jul 4 00:21:13 2019 +
>
> hsr: implement dellin
On Mon, Sep 16, 2019 at 4:39 PM syzbot
wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:1609d760 Merge tag 'for-linus' of git://git.kernel.org/pub..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=10236abe60
> kernel config:
On Tue, Sep 17, 2019 at 1:27 AM Vlad Buslov wrote:
> Hi Cong,
>
> Don't see why we would need qdisc tree lock while releasing the
> reference to (or destroying) previous Qdisc. I've skimmed through other
> scheds and it looks like sch_multiq, sch_htb and sch_tbf are also
> affected. Do you want me
Hi, Steven
Any reviews for V3? I've addressed your concern about Kconfig.
Thanks.
On Mon, Jul 15, 2019 at 10:23 AM Oliver Hartkopp wrote:
>
> Hello all,
>
> On 14.07.19 06:07, syzbot wrote:
> > syzbot has found a reproducer for the following crash on:
>
> the internal users of the CAN networking subsystem like CAN_BCM and
> CAN_RAW hold a number of CAN identifier subscriptions
Hi, Arnaldo
On Tue, May 28, 2019 at 12:11 PM Arnaldo Carvalho de Melo
wrote:
>
> Em Tue, May 28, 2019 at 11:21:38AM -0700, Cong Wang escreveu:
> > Thanks for reviewing it. Is there anyone takes this patch?
>
> Enough time, acked already, picking it.
Where is this patch landed?
On Sat, Oct 12, 2019 at 12:16 AM Zhiyuan Hou
wrote:
> diff --git a/net/sched/act_mirred.c b/net/sched/act_mirred.c
> index 9ce073a05414..6108a64c0cd5 100644
> --- a/net/sched/act_mirred.c
> +++ b/net/sched/act_mirred.c
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
> #inc
On Sun, Oct 13, 2019 at 10:37 PM Eric Dumazet wrote:
> Infinite loop because tcf_add_notify() returns -EAGAIN as the message can not
> be delivered to the socket,
> since its SO_RCVBUF has been set to 0.
Interesting corner case...
>
> Perhaps we need this patch ?
This patch looks reasonable to
On Mon, Sep 23, 2019 at 2:13 PM Cong Wang wrote:
>
> Hi, Steven
>
> Any reviews for V3? I've addressed your concern about Kconfig.
>
Ping..
On Fri, Oct 18, 2019 at 2:25 PM Eyal Birger wrote:
>
> Hi,
>
> On Fri, 18 Oct 2019 00:33:53 +0800
> Zhiyuan Hou wrote:
>
> > On 2019/10/16 8:13 下午, Eyal Birger wrote:
> > > Hi,
> > >
> > > On Wed, 16 Oct 2019 01:22:01 +0800
> > > Zhiyu
On Mon, Oct 21, 2019 at 4:21 PM Steven Rostedt wrote:
>
> On Mon, 21 Oct 2019 13:41:51 -0700
> Cong Wang wrote:
>
> > On Mon, Sep 23, 2019 at 2:13 PM Cong Wang wrote:
> > >
> > > Hi, Steven
> > >
> > > Any reviews for V3? I've addressed
s_write
=> ksys_write
=> do_syscall_64
=> entry_SYSCALL_64_after_hwframe
The only thing that can't be injected is string pointers as they
require constant string pointers, this can't be done at run time.
Cc: Steven Rostedt
Cc: Ingo Molnar
Signed-off-by: Cong Wang
---
k
On Mon, Jul 29, 2019 at 1:24 AM Jia-Ju Bai wrote:
>
> In dequeue_func(), there is an if statement on line 74 to check whether
> skb is NULL:
> if (skb)
>
> When skb is NULL, it is used on line 77:
> prefetch(&skb->end);
>
> Thus, a possible null-pointer dereference may occur.
>
> To fix th
On Thu, Jan 31, 2019 at 10:56 PM Dmitry Vyukov wrote:
> Hi Paul,
>
> Searching for af_netrom across other syzbot bugs:
> https://groups.google.com/forum/#!searchin/syzkaller-bugs/af_netrom%7Csort:date
>
> I see at least:
> https://syzkaller.appspot.com/bug?extid=b0b1952f5864b4009b09
> https://syzk
,,instructions,24026790339,100.00,0.22,insn per cycle
,0.00,stalled cycles per insn
30939953,,cycles,24025512526,100.00,,
Cc: Andi Kleen
Cc: Jiri Olsa
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Signed-off-by: Cong Wang
---
tools/perf/util/stat-shadow.c | 3 ++-
1 file changed, 2 insertions
-off-by: Cong Wang
---
kernel/trace/trace_events_filter.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/trace/trace_events_filter.c
b/kernel/trace/trace_events_filter.c
index d3e59312ef40..550e8a0d048a 100644
--- a/kernel/trace/trace_events_filter.c
+++ b/kernel/trace
Molnar
Signed-off-by: Cong Wang
---
include/linux/trace_events.h | 8
kernel/trace/trace_events.c | 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/include/linux/trace_events.h b/include/linux/trace_events.h
index 5c6f2a6c8cd2..5150436783e8 100644
--- a/include
s_write
=> ksys_write
=> do_syscall_64
=> entry_SYSCALL_64_after_hwframe
The only thing that can't be injected is string pointers as they
require constant string pointers, this can't be done at run time.
Cc: Steven Rostedt
Cc: Ingo Molnar
Signed-off-by: Cong Wang
---
k
All callers of tracing_generic_entry_update() have to initialize
entry->type, so let's just simply move it inside.
Cc: Steven Rostedt
Cc: Ingo Molnar
Signed-off-by: Cong Wang
---
include/linux/trace_events.h| 1 +
kernel/trace/trace.c| 8
kern
: Steven Rostedt
Cc: Ingo Molnar
Signed-off-by: Cong Wang
---
Cong Wang (4):
trace: fold type initialization into tracing_generic_entry_update()
trace: let filter_assign_type() detect FILTER_PTR_STRING
trace: make trace_get_fields() global
trace: introduce trace event injection
include
On Sat, May 25, 2019 at 3:37 PM Steven Rostedt wrote:
>
> On Sat, 25 May 2019 09:57:58 -0700
> Cong Wang wrote:
>
> > This patchset introduces trace event injection, the first 3 patches
> > are some trivial prerequisites, the last one implements the trace
> > even
On Sat, May 25, 2019 at 6:15 PM Randy Dunlap wrote:
>
> On 5/25/19 1:37 PM, rwar...@gmx.de wrote:
> > hallo
> >
> > I today I got a regression
> >
> > see the attached dmesg
> >
> > --
> >
> > Ronald
>
>
> [adding netdev + TIPC maintainers]
This should have been fixed by the revert of commit
532
to force a reschedule on each target CPU before decreasing the counter
perf_cgroup_events, but this is expensive.
Suggestions? Thoughts?
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Arnaldo Carvalho de Melo
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Namhyung Kim
Signed-off-by: Cong Wang
---
include/li
On Tue, May 14, 2019 at 5:32 AM Peter Zijlstra wrote:
>
> On Mon, May 13, 2019 at 05:27:47PM -0700, Cong Wang wrote:
> > We have been consistently triggering the warning
> > WARN_ON_ONCE(cpuctx->cgrp) in perf_cgroup_switch() for a rather
> > long time, although we s
On Wed, Apr 17, 2019 at 2:15 PM Luck, Tony wrote:
>
> On Tue, Apr 16, 2019 at 07:37:41PM -0700, Cong Wang wrote:
> > On Tue, Apr 16, 2019 at 7:31 PM Cong Wang wrote:
> > > Yes it is, I have a stacktrace in production which clearly shows
> > > del_elem.isra.1+0x34/0x
s, which leaves mcelog "broken"
silently. I know it is arguable, but until we can switch from
mcelog to rasdaemon, mcelog should still work as before.
I like this idea of disabling it at runtime, so:
Acked-by: Cong Wang
Thanks.
On Thu, Apr 18, 2019 at 4:29 PM Borislav Petkov wrote:
>
> On Thu, Apr 18, 2019 at 03:51:07PM -0700, Cong Wang wrote:
> > On Thu, Apr 18, 2019 at 3:02 PM Tony Luck wrote:
> > >
> > > Useful when running error injection tests that want to
> > > see all of t
On Thu, Apr 18, 2019 at 5:26 PM Borislav Petkov wrote:
>
> Now, if any of that above still doesn't make it clear, please state what
> you're trying to achieve and I'll try to help.
Sorry that I misled you to believe we don't even enable
CONFIG_X86_MCELOG_LEGACY. Here is what we have and
what we h
On Thu, Apr 18, 2019 at 5:07 PM Luck, Tony wrote:
>
> On Fri, Apr 19, 2019 at 01:29:10AM +0200, Borislav Petkov wrote:
> > Which reminds me, Tony, I think all those debugging files "pfn"
> > and "array" and the one you add now, should all be under a
> > CONFIG_RAS_CEC_DEBUG which is default off an
On Sat, Apr 20, 2019 at 2:13 AM Borislav Petkov wrote:
>
> On Fri, Apr 19, 2019 at 10:43:03PM -0700, Cong Wang wrote:
> > With this change, although not even compiled, mcelog should still
> > receive correctable memory errors like before, even when we have
> > CONFIG_RAS_
401 - 500 of 884 matches
Mail list logo
