On 7/19/19 3:30 AM, Navid Emamdoost wrote:
> call to kzalloc may fail and return null. So the result should be checked
> against null. Added the check to cover kzalloc failure case.
>
> Signed-off-by: Navid Emamdoost
> ---
> net/sched/sch_gred.c | 3 +++
> 1 file changed, 3 insertions(+)
>
On 7/18/19 2:55 PM, Sudip Mukherjee wrote:
> Thanks Eric. But there is no improvement in delay between
> softirq_raise and softirq_entry with this change.
> But moving to a later kernel (linus master branch? ) like Thomas has
> said in the other mail might be difficult atm. I can definitely
>
On 7/18/19 1:18 PM, Sudip Mukherjee wrote:
> Hi Eric,
>
> On Thu, Jul 18, 2019 at 7:58 AM Eric Dumazet wrote:
>>
>>
>>
>> On 7/17/19 11:52 PM, Thomas Gleixner wrote:
>>> Sudip,
>>>
>>> On Wed, 17 Jul 2019, Sudip Mukherjee wrote:
On 7/17/19 11:52 PM, Thomas Gleixner wrote:
> Sudip,
>
> On Wed, 17 Jul 2019, Sudip Mukherjee wrote:
>> On Wed, Jul 17, 2019 at 9:53 PM Thomas Gleixner wrote:
>>> You can hack ksoftirq_running() to return always false to avoid this, but
>>> that might cause application starvation and a huge
On 7/10/19 9:09 PM, Bart Van Assche wrote:
> On 7/10/19 11:44 AM, Eric Dumazet wrote:
>> If anything using workqueues in dynamically allocated objects can turn off
>> lockdep,
>> we have a serious issue.
>
> As far as I know that issue is only hit by syzbot test
On 7/10/19 8:36 PM, Bart Van Assche wrote:
> On 7/10/19 11:02 AM, Eric Biggers wrote:
>> I already mentioned that io_uring triggers it too.
>>
>> Those are just 2 cases that syzbot happened to generate reproducers for. I
>> expect there are many others too, since many places in the kernel
On 7/10/19 12:26 PM, bsauce wrote:
> In seq_release(), 'm->buf' points to a chunk. It is freed but not cleared to
> null right away. It can be reused by seq_read() or srm_env_proc_write().
> For example, /arch/alpha/kernel/srm_env.c provide several interfaces to
> userspace, like
On 7/9/19 10:15 PM, Jon Maloy wrote:
>
> It is not only for lockdep purposes, -it is essential. But please provide
> details about where you see that more fixes are needed.
>
Simple fact that you detect a problem only when skb_queue_purge() is called
should talk by itself.
As I stated,
On 7/9/19 3:25 PM, Jon Maloy wrote:
>
>
>> -Original Message-----
>> From: Eric Dumazet
>> Sent: 9-Jul-19 03:31
>> To: Chris Packham ; Eric Dumazet
>> ; Jon Maloy ;
>> ying@windriver.com; da...@davemloft.net
>> Cc: net...@vger.kernel.o
On 7/8/19 11:13 PM, Chris Packham wrote:
> On 9/07/19 8:43 AM, Chris Packham wrote:
>> On 8/07/19 8:18 PM, Eric Dumazet wrote:
>>>
>>>
>>> On 7/8/19 12:53 AM, Chris Packham wrote:
>>>> tipc_named_node_up() creates a skb list. It passes the list to
On 7/8/19 12:53 AM, Chris Packham wrote:
> tipc_named_node_up() creates a skb list. It passes the list to
> tipc_node_xmit() which has some code paths that can call
> skb_queue_purge() which relies on the list->lock being initialised.
> Ensure tipc_named_node_up() uses skb_queue_head_init() so
On 7/2/19 9:17 AM, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 6fbc7275 Linux 5.2-rc7
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=13fb8fe5a0
> kernel config:
On Wed, Jun 26, 2019 at 8:22 AM Greg Kroah-Hartman
wrote:
>
> On Wed, Jun 26, 2019 at 06:20:17AM +0200, Eric Dumazet wrote:
> > On Wed, Jun 26, 2019 at 5:43 AM Guenter Roeck wrote:
> > >
> > > On 6/25/19 7:29 PM, Greg Kroah-Hartman wrote:
> > > > On Tue,
On Wed, Jun 26, 2019 at 5:43 AM Guenter Roeck wrote:
>
> On 6/25/19 7:29 PM, Greg Kroah-Hartman wrote:
> > On Tue, Jun 25, 2019 at 07:02:20PM -0700, Guenter Roeck wrote:
> >> Hi Greg,
> >>
> >> On Sat, Jun 22, 2019 at 09:37:53AM +0200, Greg Kroah-Hartman wrote:
> >>> On Fri, Jun 21, 2019 at
On 6/24/19 3:54 AM, Dmitry Vyukov wrote:
> On Mon, Jun 24, 2019 at 11:34 AM Thomas Gleixner wrote:
>>
>> On Mon, 24 Jun 2019, syzbot wrote:
>>
>>> Hello,
>>>
>>> syzbot found the following crash on:
>>>
>>> HEAD commit:fd6b99fa Merge branch 'akpm' (patches from Andrew)
>>> git tree:
following hours.
Thanks.
> I guess I'll ask people on the github thread to test that too.
>
> Linus
>
> On Fri, Jun 21, 2019 at 3:38 PM Eric Dumazet wrote:
> >
> > Please look at my recent patch.
> > Sorry I am travelling
> >
> &
On Thu, Jun 20, 2019 at 10:52 AM Qian Cai wrote:
>
> The linux-next commit "inet: fix various use-after-free in defrags
> units" [1] introduced compilation warnings,
>
> ./include/net/inet_frag.h:117:1: warning: 'inline' is not at beginning
> of declaration [-Wold-style-declaration]
> static
On 6/14/19 7:25 AM, Eric Dumazet wrote:
> On Fri, Jun 14, 2019 at 7:04 AM maowenan wrote:
>> I agree that this is a special case.
>> I propose one point about the sequence of synack, if two synack with two
>> different
>> sequence since the time elapse
On Fri, Jun 14, 2019 at 7:04 AM maowenan wrote:
> I agree that this is a special case.
> I propose one point about the sequence of synack, if two synack with two
> different
> sequence since the time elapse 64ns, this issue disappear.
>
>
On Fri, Jun 14, 2019 at 2:35 AM maowenan wrote:
>
>
>
> On 2019/6/14 12:28, Eric Dumazet wrote:
> >
> >
> > On 6/13/19 9:19 PM, maowenan wrote:
> >>
> >>
> >> @Eric, for this issue I only want to check TCP_NEW_SYN_RECV sk, is it OK
On 6/13/19 9:19 PM, maowenan wrote:
>
>
> @Eric, for this issue I only want to check TCP_NEW_SYN_RECV sk, is it OK like
> below?
> + if (!osk && sk->sk_state == TCP_NEW_SYN_RECV)
> + reqsk = __inet_lookup_established(sock_net(sk),
> _hashinfo,
> +
On Tue, Jun 11, 2019 at 8:49 PM Mao Wenan wrote:
>
> There is one issue about bonding mode BOND_MODE_BROADCAST, and
> two slaves with diffierent affinity, so packets will be handled
> by different cpu. These are two pre-conditions in this case.
>
> When two slaves receive the same syn packets at
On 6/7/19 8:32 AM, Herbert Xu wrote:
> On Fri, Jun 07, 2019 at 08:26:12AM -0700, Eric Dumazet wrote:
>>
>> There is common knowledge among us programmers that bit fields
>> (or bool) sharing a common 'word' need to be protected
>> with a common lock.
>>
>>
On 6/7/19 7:09 AM, Herbert Xu wrote:
> On Tue, Jun 04, 2019 at 09:04:55AM -0700, Linus Torvalds wrote:
>>
>> In fact, the alpha port was always subtly buggy exactly because of the
>> "byte write turns into a read-and-masked-write", even if I don't think
>> anybody ever noticed (we did fix cases
On 6/5/19 1:52 AM, Zhiqiang Liu wrote:
>
>
> 在 2019/6/4 23:24, Eric Dumazet 写道:
>> On Tue, Jun 4, 2019 at 7:47 AM Mao Wenan wrote:
>>>
>>> There is one issue about bonding mode BOND_MODE_BROADCAST, and
>>> two slaves with diffierent affinity, so pa
On Tue, Jun 4, 2019 at 7:07 PM maowenan wrote:
>
>
>
> On 2019/6/4 23:24, Eric Dumazet wrote:
> > On Tue, Jun 4, 2019 at 7:47 AM Mao Wenan wrote:
> >>
> >> There is one issue about bonding mode BOND_MODE_BROADCAST, and
> >> two slaves with di
On Tue, Jun 4, 2019 at 7:47 AM Mao Wenan wrote:
>
> There is one issue about bonding mode BOND_MODE_BROADCAST, and
> two slaves with diffierent affinity, so packets will be handled
> by different cpu. These are two pre-conditions in this case.
>
> When two slaves receive the same syn packets at
not needed at all.
If this was needed, then we would have to fix the callers, which you did not.
Citing arbitrary CVE is of no use, we do not copy/paste patches or CVE.
> On Sat, Jun 1, 2019 at 1:35 AM Eric Dumazet wrote:
>>
>>
>>
>> On 5/30/19 8:04 PM, Yang Xiao wro
On 5/30/19 8:04 PM, Yang Xiao wrote:
> On Fri, May 31, 2019 at 1:17 AM Eric Dumazet wrote:
>>
>>
>>
>> On 5/30/19 8:28 AM, Young Xiao wrote:
>>> The fragmentation code tries to parse the header options in order
>>> to figure out where to inse
On 5/31/19 7:54 AM, Herbert Xu wrote:
> On Fri, May 31, 2019 at 07:50:06AM -0700, Eric Dumazet wrote:
>>
>> What do you mean by should ?
>>
>> Are they currently already linearized before the function is called,
>> or is it missing and a bug needs to be fixed ?
On 5/30/19 11:29 PM, Herbert Xu wrote:
> On Thu, May 30, 2019 at 10:17:04AM -0700, Eric Dumazet wrote:
>>
>> xfrm6_transport_output() seems buggy as well,
>> unless the skbs are linearized before entering these functions ?
>
> The headers that it's
On 5/30/19 3:52 PM, Alexander Duyck wrote:
> Actually I think there are some parts that don't have any receive
> limits that are supported by the e1000 part. What ends up happening is
> that we only drop the packet if it spans more than one buffer if I
> recall correctly, and buffer size is
On 5/30/19 8:28 AM, Young Xiao wrote:
> The fragmentation code tries to parse the header options in order
> to figure out where to insert the fragment option. Since nexthdr points
> to an invalid option, the calculation of the size of the network header
> can made to be much larger than the
On Thu, May 30, 2019 at 3:31 AM Feng Tang wrote:
>
> On Wed, Apr 03, 2019 at 02:34:36PM +0800, kernel test robot wrote:
> > Greeting,
> >
> > FYI, we noticed a -25.7% regression of netperf.Throughput_Mbps due to
> > commit:
> >
> >
> > commit: 8b27dae5a2e89a61c46c6dbc76c040c0e6d0ed4c ("tcp: add
On Wed, May 29, 2019 at 7:49 AM Paul Menzel wrote:
>
> Dear Eric,
>
>
> Thank you for the quick reply.
>
> On 05/28/19 19:18, Eric Dumazet wrote:
> > On 5/28/19 8:42 AM, Paul Menzel wrote:
>
> >> Occasionally, Linux outputs the message below on the
ing byte.
>
> On Wed, May 29, 2019 at 10:20 PM Eric Dumazet wrote:
> >
> > On Wed, May 29, 2019 at 1:10 AM Young Xiao <92siuy...@gmail.com> wrote:
> > >
> > > The TCP option parsing routines in tcp_parse_options function could
> > > read
since we have at least 320 bytes of room there,
and the test done later catches silly options.
if (opsize < 2) /* "silly options" */
return;
if (opsize > length) /* remember, opsize >= 2 here */
return; /* don't parse partial options */
I guess adding yet another conditional will make this code obviously
correct for all eyes
and various tools.
Thanks.
Signed-off-by: Eric Dumazet
On 5/28/19 8:42 AM, Paul Menzel wrote:
> Dear Linux folks,
>
>
> Occasionally, Linux outputs the message below on the workstation Dell
> OptiPlex 5040 MT.
>
> TCP: net00: Driver has suspect GRO implementation, TCP performance may be
> compromised.
>
> Linux 4.14.55 and Linux 5.2-rc2
On Fri, May 24, 2019 at 7:30 AM Kefeng Wang wrote:
>
> 3e67f106f619 ("inet: frags: break the 2GB limit for frags storage"),
> changes ipfrag_high/low_thread 'type' from int to long, using CTL_ULONG
> instead of CTL_INT to keep consistent.
What about compatibility with existing applications ?
On Wed, May 15, 2019 at 7:43 AM Matthew Wilcox wrote:
>
> > > W dniu 25.04.2019 o 11:25, Lech Perczak pisze:
> > >> Some time ago, after upgrading the Kernel on our i.MX6Q-based boards to
> > >> mainline 4.18, and now to LTS 4.19 line, during stress tests we started
> > >> noticing strange
On Wed, May 8, 2019 at 11:59 AM Dennis Zhou wrote:
>
> On Tue, May 07, 2019 at 06:43:20PM -0700, John Sperbeck wrote:
> > In free_percpu() we sometimes call pcpu_schedule_balance_work() to
> > queue a work item (which does a wakeup) while holding pcpu_lock.
> > This creates an unnecessary lock
On 5/8/19 11:56 AM, Lukasz Pawelczyk wrote:
> On Wed, 2019-05-08 at 08:41 -0700, Eric Dumazet wrote:
>>
>> On 5/8/19 11:25 AM, Lukasz Pawelczyk wrote:
>>> On Wed, 2019-05-08 at 07:58 -0700, Eric Dumazet wrote:
>>>> On 5/8/19 10:12 AM, Lukasz Pawelczyk w
On Wed, May 8, 2019 at 8:33 AM YueHaibing wrote:
>
> kernel BUG at lib/list_debug.c:47!
> invalid opcode: [#1
> CPU: 0 PID: 11195 Comm: rmmod Tainted: GW 5.1.0+ #33
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
>
On 5/8/19 11:25 AM, Lukasz Pawelczyk wrote:
> On Wed, 2019-05-08 at 07:58 -0700, Eric Dumazet wrote:
>>
>> On 5/8/19 10:12 AM, Lukasz Pawelczyk wrote:
>>> The XT_SUPPL_GROUPS flag causes GIDs specified with XT_OWNER_GID to
>>> be also checked in the
On 04/18/2019 07:01 PM, PlusOneSecond wrote:
> In ax25_info_show of af_ax25.c:1891, linux-5.1.
> The pointer ax25 is cast to long type to print out.
>
> Why it prints the a pointer 'ax25' use %8.8lx rather than %p?
> If it really want to print the value of ax25, it should use %px.
I guess
On 04/18/2019 03:24 PM, Andrew Morton wrote:
> afaict, vfree() will only do a mutex_trylock() in
> try_purge_vmap_area_lazy(). So does vfree actually sleep in any
> situation? Whether or not local interrupts are enabled?
We would be in a big trouble if vfree() could potentially sleep...
On 03/06/2019 01:55 PM, Myungho Jung wrote:
> In esp4_gro_receive() and esp6_gro_receive(), secpath can be allocated
> without adding xfrm state to xvec. Then, sp->xvec[sp->len - 1] would
> fail and result in dereferencing invalid pointer in esp4_gso_segment()
> and esp6_gso_segment(). Reset
On 03/04/2019 02:23 PM, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 9e9322e5d28e selftest/net: Remove duplicate header
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=1351623320
> kernel config:
fput(req->file);
> return apt.error;
>
Very nice changelog Al, thanks for fixing this.
Reviewed-by: Eric Dumazet
On 03/01/2019 02:03 PM, Guenter Roeck wrote:
> Hi,
>
> On Mon, Feb 25, 2019 at 02:28:39PM -0800, Alexei Starovoitov wrote:
>> JITed BPF programs are indistinguishable from kernel functions, but unlike
>> kernel code BPF code can be changed often.
>> Typical approach of "perf record" + "perf
On 03/01/2019 02:03 PM, Guenter Roeck wrote:
> Hi,
>
> On Mon, Feb 25, 2019 at 02:28:39PM -0800, Alexei Starovoitov wrote:
>> JITed BPF programs are indistinguishable from kernel functions, but unlike
>> kernel code BPF code can be changed often.
>> Typical approach of "perf record" + "perf
copying the data
is not free, since the freeing of the skb (and associated
page frags put_page()) can happen after cache lines have been evicted.
Signed-off-by: Eric Dumazet
Cc: Al Viro
---
lib/iov_iter.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/lib
On 02/26/2019 12:41 AM, Geliang Tang wrote:
> The function name tcp_do_sendmsg has been renamed. But it still
> appears in __tcp_transmit_skb's comment text. This patch changes
> it to tcp_sendmsg_locked.
>
> Signed-off-by: Geliang Tang
> ---
> net/ipv4/tcp_output.c | 2 +-
> 1 file changed,
On 02/25/2019 03:21 PM, Dmitry Safonov wrote:
> Hi Eric,
>
> On 2/25/19 11:09 PM, Eric Dumazet wrote:
>> On 02/25/2019 01:27 PM, Dmitry Safonov wrote:
>>> While it's possible to document that rtnl_unregister() requires
>>> synchronize_net() afterwards - unlike
On 02/25/2019 01:27 PM, Dmitry Safonov wrote:
> rtnl_unregister() unsets handler from table, which is protected
> by rtnl_lock or RCU. At this moment only dump handlers access the table
> with rcu_lock(). Every other user accesses under rtnl.
>
> Callers may expect that rtnl_unregister()
TM, thanks.
Reviewed-by: Eric Dumazet
On 02/24/2019 10:12 PM, David Miller wrote:
> From: Timur Celik
> Date: Sat, 23 Feb 2019 12:53:13 +0100
>
>> This patch moves setting of the current state into the loop. Otherwise
>> the task may end up in a busy wait loop if none of the break conditions
>> are met.
>>
>> Signed-off-by: Timur
On 02/22/2019 09:57 AM, Eric Biggers wrote:
> ->setattr() is called under inode_lock(), which __sock_release() also takes.
> So
> the uses of sock->sk are serialized. See commit 6d8c50dcb029 ("socket: close
> race condition between sock_close() and sockfs_setattr()").
Oh right, we added
On 02/21/2019 02:13 PM, Eric Biggers wrote:
> From: Eric Biggers
>
> Commit 9060cb719e61 ("net: crypto set sk to NULL when af_alg_release.")
> fixed a use-after-free in sockfs_setattr() when an AF_ALG socket is
> closed concurrently with fchownat(). However, it ignored that many
> other
On Tue, Feb 12, 2019 at 6:07 PM Yafang Shao wrote:
>
> Let me explain the background for you.
> I want to track some TCP abnormal behavior in TCP/IP stack. But I
> find there's no good way to do it.
> The current MIBs are per net, other than per socket, that makes it not
> very powerful.
> And
On 02/09/2019 02:35 AM, Konstantin Khlebnikov wrote:
> Field idiag_ext in struct inet_diag_req_v2 used as bitmap of requested
> extensions has only 8 bits. Thus extensions starting from DCTCPINFO
> cannot be requested directly. Some of them included into response
> unconditionally or hook into
On 02/12/2019 03:31 AM, Yafang Shao wrote:
> Introuce this new op BPF_SOCK_OPS_STATS_CB for tcp_stats() such that it
> can be traced via BPF on a per socket basis.
> There's one argument in BPF_SOCK_OPS_STATS_CB, which is Linux MIB index
> LINUX_MIB_* to indicate the TCP event.
> All these
On 02/12/2019 03:31 AM, Yafang Shao wrote:
> SOCK_DEBUG is a very ancient debugging interface, and it's not very useful
> for debugging.
> So this patch removes the SOCK_DEBUG() and introduce a new function
> tcp_stats() to trace this kind of events.
> Some MIBs are added for these events.
>
>
sent_queue
>>>>
>>> You're right. Thought this was added in 4.20 already.
>>> The BQL code pattern I copied from the mlx4 driver and so far I haven't
>>> heard about
>>> this issue from any user of physical hw. And due to the fact that a lot of
>
d, , 0) == pid);
> }
> }
>
> Before:
>
> $ time ./unshare2
>
> real0m9.784s
> user0m0.428s
> sys 0m0.000s
>
> After:
>
> $ time ./unshare2
>
> real0m0.368s
> user0m0.226s
> sys 0m0.122s
>
> Signed-
On 02/05/2019 07:28 PM, Dmitry Vyukov wrote:
> On Wed, Jan 30, 2019 at 10:02 PM syzbot
> wrote:
>>
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit:62967898789d Merge git://git.kernel.org/pub/scm/linux/kern..
>> git tree: upstream
>> console output:
On 02/05/2019 12:18 PM, Joe Perches wrote:
> I still think adding __align() is unnecessary here unless
> it follows something like a bool or a u8.
This would be some historical side effect, and we do not want to rely on that.
A security feature could in fact ask a compiler to perform random
On 02/05/2019 10:42 AM, Joe Perches wrote:
>
> It's declared after a pointer so it is already is 2 byte aligned.
>
> A lot of drivers wouldn't work otherwise.
Maybe these drivers are only used on arches where this does not matter.
On 01/31/2019 07:15 AM, Eric Dumazet wrote:
>
>
> On 01/31/2019 05:49 AM, Kirill Tkhai wrote:
>>
>> 2)Not related to your patch -- it looks like we have problem in existing
>> code with this netdev_refcnt_read(). It does not imply a memory ordering
>> or som
On 01/31/2019 05:49 AM, Kirill Tkhai wrote:
>
> 2)Not related to your patch -- it looks like we have problem in existing
> code with this netdev_refcnt_read(). It does not imply a memory ordering
> or some guarantees about reading percpu values. For example, in generic
> code struct percpu_ref
On 01/22/2019 08:39 AM, Huazhong Tan wrote:
> From: Jian Shen
>
> This patch adds rx multicast packets statistic for each ring.
>
> Signed-off-by: Jian Shen
> Signed-off-by: Peng Li
> Signed-off-by: Huazhong Tan
> ---
> drivers/net/ethernet/hisilicon/hns3/hns3_enet.c| 9 +
>
On Thu, Jan 10, 2019 at 12:55 AM Paolo Abeni wrote:
>
> On Thu, 2019-01-10 at 09:25 +0100, Ian Kumlien wrote:
> > This works, and so does:
> > https://marc.info/?l=linux-netdev=154696956604748=2
> >
> > Pointed out by Paolo (tested both separately)
>
> Note: I cleared the tstamp in
On Wed, Jan 9, 2019 at 4:48 PM Ian Kumlien wrote:
>
> Hi,
>
> Just been trough ~5+ hours of bisecting and eventually actually found
> the culprit =)
>
> commit fb420d5d91c1274d5966917725e71f27ed092a85 (refs/bisect/bad)
> Author: Eric Dumazet
> Date: Fri Sep 28 10:2
On 01/08/2019 01:30 AM, Konstantin Khlebnikov wrote:
> This fixes false-positive kmemleak reports about leaked neighbour entries:
>
> unreferenced object 0x8885c6e4d0a8 (size 1024):
size 1024 object : should have been allocated by kzalloc(), right ?
> comm "softirq", pid 0, jiffies
On 01/03/2019 05:07 AM, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 195303136f19 Merge tag 'kconfig-v4.21-2' of git://git.kern..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=12245d8f40
> kernel config:
vior, specifically not allowing alloc_skb() to fail for small orders
> and oom kill if necessary rather than allowing RPCs to fail.
>
> Fixes: dcda9b04713c ("mm, tree wide: replace __GFP_REPEAT by
> __GFP_RETRY_MAYFAIL with more useful semantic")
> Signed-off-by: David Rientjes
Reviewed-by: Eric Dumazet
Thanks David.
On 01/02/2019 02:41 AM, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 28e8c4bc8eb4 Merge tag 'rtc-4.21' of git://git.kernel.org/..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=10c040d340
> kernel config:
On 12/21/2018 12:27 PM, Deepa Dinamani wrote:
> Al Viro mentioned that there is probably a race condition
> lurking in accesses of sk_tstamp on 32-bit machines.
>
> sock->sk_tstamp is of type ktime_t which is always an s64.
> On a 32 bit architecture, we might run into situations of
> unsafe
On 12/17/2018 06:40 AM, Dmitry Vyukov wrote:
> On Mon, Dec 17, 2018 at 3:14 PM Arjan van de Ven
> wrote:
>>
>> On 12/17/2018 3:29 AM, Paul E. McKenney wrote:
>>> As does this sort of report on a line that contains simple integer
>>> arithmetic and boolean operations.;-)
>>>
>>> Any chance of
On 12/08/2018 05:37 AM, Eric Dumazet wrote:
> Avoid cache line miss dereferencing struct page if we can.
>
> page_copy_sane() mostly deals with order-0 pages.
>
> Signed-off-by: Eric Dumazet
> Cc: Al Viro
> ---
> lib/iov_iter.c | 14 --
> 1 file c
On Mon, Dec 17, 2018 at 2:03 AM Ido Schimmel wrote:
>
> On Mon, Dec 17, 2018 at 11:31:06AM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the net-next tree got a conflict in:
> >
> > net/ipv6/ip6_output.c
> >
> > between commit:
> >
> > 8203e2d844d3 ("net:
On 12/15/2018 01:33 AM, Yafang Shao wrote:
> When we building a syn packet, the tcp_skb_pcount(skb) is always 1,
> which is set in tcp_init_nondata_skb().
> Regarding the syn_data, it is set through
> memcpy(syn_data->cb, syn->cb, sizeof(syn->cb)),
> which is always 1 as well.
>
> So we don't
On Fri, Dec 14, 2018 at 7:54 AM Christoph Paasch wrote:
> To clarify: Backport to v4.19.x is needed. The backport to v4.14 and older
> should not be needed.
Sure, but this does not cause any harm.
No further action needed :)
On 12/14/2018 07:04 AM, Jon Maloy wrote:
>
>
>> -Original Message-
>> From: Cong Wang
>> Sent: 12-Dec-18 01:17
>> To: Dmitry Vyukov
>> Cc: syzbot+c56449ed3652e6720...@syzkaller.appspotmail.com; Jon Maloy
>> ; Ying Xue ; tipc-
>> discuss...@lists.sourceforge.net; David Miller ;
>>
On 12/12/2018 06:28 PM, Michal Kubecek wrote:
> Since commit 7969e5c40dfd ("ip: discard IPv4 datagrams with overlapping
> segments.") IPv4 reassembly code drops the whole queue whenever an
> overlapping fragment is received. However, the test is written in a way
> which detects duplicate
Avoid cache line miss dereferencing struct page if we can.
page_copy_sane() mostly deals with order-0 pages.
Signed-off-by: Eric Dumazet
Cc: Al Viro
---
lib/iov_iter.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/lib/iov_iter.c b/lib/iov_iter.c
index
Avoid cache line miss dereferencing struct page if we can.
page_copy_sane() mostly deals with order-0 pages.
Signed-off-by: Eric Dumazet
Cc: Al Viro
---
lib/iov_iter.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/lib/iov_iter.c b/lib/iov_iter.c
index
On Wed, Oct 24, 2018 at 9:54 AM Joe Perches wrote:
> I think if the point is to test for negative numbers,
> it's clearer to do that before using min_t.and it's
> probably clearer not to use min_t at all.
>
...
>
> if (len > sizeof(int))
> len = sizeof(int);
It is a
On Wed, Oct 24, 2018 at 9:54 AM Joe Perches wrote:
> I think if the point is to test for negative numbers,
> it's clearer to do that before using min_t.and it's
> probably clearer not to use min_t at all.
>
...
>
> if (len > sizeof(int))
> len = sizeof(int);
It is a
On Thu, Oct 11, 2018 at 8:50 AM Peter Zijlstra wrote:
> Right; it goes back a long long way... is:
>
> 7c3576d261ce ("[PATCH] i386: Convert PDA into the percpu section")
>
> early enough? That introduces percpu_from_op(), but arguably the
> pda_from_op() it replaces was buggy already.
Yeah I
On Thu, Oct 11, 2018 at 8:50 AM Peter Zijlstra wrote:
> Right; it goes back a long long way... is:
>
> 7c3576d261ce ("[PATCH] i386: Convert PDA into the percpu section")
>
> early enough? That introduces percpu_from_op(), but arguably the
> pda_from_op() it replaces was buggy already.
Yeah I
On Thu, Oct 11, 2018 at 8:02 AM Eric Dumazet wrote:
>
> On Thu, Oct 11, 2018 at 3:45 AM Peter Zijlstra wrote:
> >
> > Eric reported that a sequence count loop using this_cpu_read() got
> > optimized out. This is wrong, this_cpu_read() must imply READ_ONCE()
> > bec
On Thu, Oct 11, 2018 at 8:02 AM Eric Dumazet wrote:
>
> On Thu, Oct 11, 2018 at 3:45 AM Peter Zijlstra wrote:
> >
> > Eric reported that a sequence count loop using this_cpu_read() got
> > optimized out. This is wrong, this_cpu_read() must imply READ_ONCE()
> > bec
On Thu, Oct 11, 2018 at 12:31 AM Peter Zijlstra wrote:
>
> On Wed, Oct 10, 2018 at 05:33:36PM -0700, Eric Dumazet wrote:
> > While looking at native_sched_clock() disassembly I had
> > the surprise to see the compiler (gcc 7.3 here) had
> > optimized out the loop, me
On Thu, Oct 11, 2018 at 12:31 AM Peter Zijlstra wrote:
>
> On Wed, Oct 10, 2018 at 05:33:36PM -0700, Eric Dumazet wrote:
> > While looking at native_sched_clock() disassembly I had
> > the surprise to see the compiler (gcc 7.3 here) had
> > optimized out the loop, me
e per-cpu value.
>
> Fixes: 59eaef78bfea ("x86/tsc: Remodel cyc2ns to use seqcount_latch()")
> Reported-by: Eric Dumazet
> Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Eric Dumazet
> ---
> arch/x86/include/asm/percpu.h |8
> 1 file changed, 4 in
e per-cpu value.
>
> Fixes: 59eaef78bfea ("x86/tsc: Remodel cyc2ns to use seqcount_latch()")
> Reported-by: Eric Dumazet
> Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Eric Dumazet
> ---
> arch/x86/include/asm/percpu.h |8
> 1 file changed, 4 in
() by one this_cpu_ptr() makes
the generated code smaller.
Fixes: 59eaef78bfea ("x86/tsc: Remodel cyc2ns to use seqcount_latch()")
Signed-off-by: Eric Dumazet
Cc: Peter Zijlstra (Intel)
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
---
arch/x86/kernel/tsc.c | 15 +++
() by one this_cpu_ptr() makes
the generated code smaller.
Fixes: 59eaef78bfea ("x86/tsc: Remodel cyc2ns to use seqcount_latch()")
Signed-off-by: Eric Dumazet
Cc: Peter Zijlstra (Intel)
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
---
arch/x86/kernel/tsc.c | 15 +++
On Tue, Oct 9, 2018 at 7:58 AM Eric Dumazet wrote:
>
> We do not add bloat in the kernel if no application is ever going to
> use it, especially in the TCP fast path.
>
BTW, are you willing to change all memory allocations in the kernel as well ?
Let say an application is using a
401 - 500 of 5670 matches
Mail list logo
