* Re: [PATCH net-next v3] Add Common Applications Kept Enhanced (cake) qdisc
From: Toke Høiland-Jørgensen @ 2018-04-25 16:55 UTC (permalink / raw)
To: Eric Dumazet, netdev; +Cc: cake, Dave Taht
In-Reply-To: <8bae2ee1-efcc-1571-2a30-5b7779de2c88@gmail.com>
Eric Dumazet <eric.dumazet@gmail.com> writes:
> On 04/25/2018 09:06 AM, Toke Høiland-Jørgensen wrote:
>> Eric Dumazet <eric.dumazet@gmail.com> writes:
>>
>>> On 04/25/2018 08:22 AM, Toke Høiland-Jørgensen wrote:
>>>> Eric Dumazet <eric.dumazet@gmail.com> writes:
>>>
>>>>> What performance number do you get on a 10Gbit NIC for example ?
>>>>
>>>> Single-flow throughput through 2 hops on a 40Gbit connection (with CAKE
>>>> in unlimited mode vs pfifo_fast on the router):
>>>>
>>>> MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to testbed-40g-2 () port 0 AF_INET : demo
>>>> Recv Send Send
>>>> Socket Socket Message Elapsed
>>>> Size Size Size Time Throughput
>>>> bytes bytes bytes secs. 10^6bits/sec
>>>>
>>>> 87380 16384 16384 10.00 18840.40
>>>>
>>>> MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to testbed-40g-2 () port 0 AF_INET : demo
>>>> Recv Send Send
>>>> Socket Socket Message Elapsed
>>>> Size Size Size Time Throughput
>>>> bytes bytes bytes secs. 10^6bits/sec
>>>>
>>>> 87380 16384 16384 10.00 24804.77
>>>
>>> CPU performance would be interesting here. (netperf -Cc)
>>
>>
>> $ sudo tc qdisc replace dev ens2 root cake
>> $ netperf -cC -H 10.70.2.2
>> MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.70.2.2 () port 0 AF_INET : demo
>> Recv Send Send Utilization Service Demand
>> Socket Socket Message Elapsed Send Recv Send Recv
>> Size Size Size Time Throughput local remote local remote
>> bytes bytes bytes secs. 10^6bits/s % S % S us/KB us/KB
>>
>> 87380 16384 16384 10.00 15450.35 13.35 6.68 0.849 0.283
>>
>> $ sudo tc qdisc del dev ens2 root
>> $ netperf -cC -H 10.70.2.2
>> MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.70.2.2 () port 0 AF_INET : demo
>> Recv Send Send Utilization Service Demand
>> Socket Socket Message Elapsed Send Recv Send Recv
>> Size Size Size Time Throughput local remote local remote
>> bytes bytes bytes secs. 10^6bits/s % S % S us/KB us/KB
>>
>> 87380 16384 16384 10.00 36414.23 8.20 14.30 0.221 0.257
>>
>>
>> (In this test I'm running netperf on the machine that was a router
>> before, which is why the base throughput is higher; the other machine
>> runs out of CPU on the sender side).
>
> We can see here the high cost of forcing software GSO :/
>
> Really, this should be done only :
> 1) If requested by the admin ( tc .... gso ....)
>
> 2) If packet size is above a threshold.
> The threshold could be set by the admin, and/or based on a fraction of the bandwidth parameter.
>
> I totally understand why you prefer to segment yourself for < 100 Mbit links.
>
> But this makes no sense on 10Gbit+
Well, as I said, 10Gbit+ links are not really the target audience ;)
We did actually have a threshold at some point, but it was removed
because it didn't work well (I'm not sure of the details, perhaps
someone else will chime in).
However, I'm fine with adding a flag, as long as peeling defaults to on,
at least when the shaper is active (to properly account for packet
overhead we really need to see every packet that goes out on the wire).
Would that be acceptable?
-Toke
^ permalink raw reply
* Re: [PATCH] rds: ib: Fix missing call to rds_ib_dev_put in rds_ib_setup_qp
From: Santosh Shilimkar @ 2018-04-25 16:53 UTC (permalink / raw)
To: Dag Moxnes, David S. Miller, netdev, linux-rdma, rds-devel,
linux-kernel
In-Reply-To: <1524655321-8379-1-git-send-email-dag.moxnes@oracle.com>
On 4/25/2018 4:22 AM, Dag Moxnes wrote:
> The function rds_ib_setup_qp is calling rds_ib_get_client_data and
> should correspondingly call rds_ib_dev_put. This call was lost in
> the non-error path with the introduction of error handling done in
> commit 3b12f73a5c29 ("rds: ib: add error handle")
>
> Signed-off-by: Dag Moxnes <dag.moxnes@oracle.com>
> ---
Thanks Dag for following it up.
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
^ permalink raw reply
* Re: [Cake] [PATCH net-next v3] Add Common Applications Kept Enhanced (cake) qdisc
From: Jonathan Morton @ 2018-04-25 16:52 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Toke Høiland-Jørgensen, netdev, cake
In-Reply-To: <8bae2ee1-efcc-1571-2a30-5b7779de2c88@gmail.com>
> We can see here the high cost of forcing software GSO :/
>
> Really, this should be done only :
> 1) If requested by the admin ( tc .... gso ....)
>
> 2) If packet size is above a threshold.
> The threshold could be set by the admin, and/or based on a fraction of the bandwidth parameter.
>
> I totally understand why you prefer to segment yourself for < 100 Mbit links.
>
> But this makes no sense on 10Gbit+
It is absolutely necessary, so far as I can see, to segment GSO superpackets when overhead compensation is selected - as it very often should be, even on pure Ethernet links. Without that, the calculation of link occupancy time will be wrong. (The actual transmission time of an Ethernet frame is rather more than just 14 bytes longer than the underlying IP packet.)
Another reason to apply GSO segmentation is to achieve maximal smoothness of flow isolation. This should still be achievable within some tolerance at high link rates, but calculating this tolerance is complicated by the triple-isolate algorithm.
If there's a way to obtain the individual packet sizes without incurring the full segmentation overhead, it may be worth considering (at high link rates only). I would want to leave it on by default, because some of Cake's demonstrably superior latency performance depends on seeing the real packets, not the aggregates, and the overhead only becomes significant above 100Mbps on weak MIPS CPUs and 1Gbps on vaguely modern x86 stuff.
- Jonathan Morton
^ permalink raw reply
* Re: [PATCH bpf-next v6 02/10] bpf: add bpf_get_stack helper
From: Yonghong Song @ 2018-04-25 16:44 UTC (permalink / raw)
To: Daniel Borkmann, ast, netdev, ecree; +Cc: kernel-team
In-Reply-To: <89ee3446-8119-8bf4-ee69-bd43e4167a2e@iogearbox.net>
On 4/25/18 2:00 AM, Daniel Borkmann wrote:
> On 04/23/2018 11:27 PM, Yonghong Song wrote:
>> Currently, stackmap and bpf_get_stackid helper are provided
>> for bpf program to get the stack trace. This approach has
>> a limitation though. If two stack traces have the same hash,
>> only one will get stored in the stackmap table,
>> so some stack traces are missing from user perspective.
>>
>> This patch implements a new helper, bpf_get_stack, will
>> send stack traces directly to bpf program. The bpf program
>> is able to see all stack traces, and then can do in-kernel
>> processing or send stack traces to user space through
>> shared map or bpf_perf_event_output.
>>
>> Acked-by: Alexei Starovoitov <ast@fb.com>
>> Signed-off-by: Yonghong Song <yhs@fb.com>
> [...]
>> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
>> index d315b39..bf22eca 100644
>> --- a/kernel/bpf/core.c
>> +++ b/kernel/bpf/core.c
>> @@ -31,6 +31,7 @@
>> #include <linux/rbtree_latch.h>
>> #include <linux/kallsyms.h>
>> #include <linux/rcupdate.h>
>> +#include <linux/perf_event.h>
>>
>> #include <asm/unaligned.h>
>>
>> @@ -1709,6 +1710,10 @@ static void bpf_prog_free_deferred(struct work_struct *work)
>> aux = container_of(work, struct bpf_prog_aux, work);
>> if (bpf_prog_is_dev_bound(aux))
>> bpf_prog_offload_destroy(aux->prog);
>> +#ifdef CONFIG_PERF_EVENTS
>> + if (aux->prog->need_callchain_buf)
>> + put_callchain_buffers();
>> +#endif
>> for (i = 0; i < aux->func_cnt; i++)
>> bpf_jit_free(aux->func[i]);
>> if (aux->func_cnt) {
> [...]
>> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
>> index fe23dc5a..1ee71f6 100644
>> --- a/kernel/bpf/syscall.c
>> +++ b/kernel/bpf/syscall.c
>> @@ -1360,6 +1360,16 @@ static int bpf_prog_load(union bpf_attr *attr)
>> if (err)
>> goto free_used_maps;
>>
>> + if (prog->need_callchain_buf) {
>> +#ifdef CONFIG_PERF_EVENTS
>> + err = get_callchain_buffers(sysctl_perf_event_max_stack);
>> +#else
>> + err = -ENOTSUPP;
>> +#endif
>> + if (err)
>> + goto free_used_maps;
>> + }
>> +
>> err = bpf_prog_new_fd(prog);
>> if (err < 0) {
>> /* failed to allocate fd.
>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>> index 5dd1dcb..aba9425 100644
>> --- a/kernel/bpf/verifier.c
>> +++ b/kernel/bpf/verifier.c
>> @@ -2460,6 +2460,9 @@ static int check_helper_call(struct bpf_verifier_env *env, int func_id, int insn
>> if (err)
>> return err;
>>
>> + if (func_id == BPF_FUNC_get_stack)
>> + env->prog->need_callchain_buf = true;
>> +
>> if (changes_data)
>> clear_all_pkt_pointers(env);
>> return 0;
>
> The above three hunks will cause a use-after-free on the perf callchain buffers.
>
> In check_helper_call() you mark the prog with need_callchain_buf, where the
> program hasn't fully completed verification phase yet, meaning some buggy prog
> will still bail out.
>
> However, you do the get_callchain_buffers() at a much later phase, so when you
> bail out with error from bpf_check(), you take the free_used_maps error path
> which calls bpf_prog_free().
>
> The latter calls into bpf_prog_free_deferred() where you do the put_callchain_buffers()
> since the need_callchain_buf is marked, but without prior get_callchain_buffers().
Thanks for catching this! Yes, this is a real issue. I will fix it and
respin.
^ permalink raw reply
* Re: [PATCH net-next 1/2] tcp: add TCP_ZEROCOPY_RECEIVE support for zerocopy receive
From: Eric Dumazet @ 2018-04-25 16:44 UTC (permalink / raw)
To: Andy Lutomirski, Matthew Wilcox
Cc: Christoph Hellwig, Eric Dumazet, David S . Miller, netdev,
linux-kernel, linux-mm, Soheil Hassas Yeganeh
In-Reply-To: <155a86d5-a910-c366-f521-216a0582bad8@gmail.com>
On 04/25/2018 09:35 AM, Eric Dumazet wrote:
>
>
> On 04/25/2018 09:22 AM, Andy Lutomirski wrote:
>
>> In general, I suspect that the zerocopy receive mechanism will only
>> really be a win in single-threaded applications that consume large
>> amounts of receive bandwidth on a single TCP socket using lots of
>> memory and don't do all that much else.
>
> This was dully noted in the original patch submission.
>
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=309c446cb45f6663932c8e6d0754f4ac81d1b5cd
>
> Our intent at Google is to use it for some specific 1MB+ receives, not as a generic and universal mechanism.
>
> The major benefit is really the 4KB+ MTU, allowing to pack exactly 4096 bytes of payload per page.
>
Some perf numbers with 10 concurrent threads in tcp_mmap with zero copy enabled :
(tcp_mmap uses 512 KB chunks, not 1MB ones)
received 32768 MB (100 % mmap'ed) in 28.3054 s, 9.71116 Gbit
cpu usage user:0.039 sys:1.946, 60.5774 usec per MB, 65536 c-switches
received 32768 MB (100 % mmap'ed) in 28.2504 s, 9.73004 Gbit
cpu usage user:0.052 sys:1.941, 60.8215 usec per MB, 65536 c-switches
received 32768 MB (99.9998 % mmap'ed) in 28.2508 s, 9.72993 Gbit
cpu usage user:0.056 sys:1.915, 60.1501 usec per MB, 65539 c-switches
received 32768 MB (100 % mmap'ed) in 28.2544 s, 9.72866 Gbit
cpu usage user:0.053 sys:1.966, 61.615 usec per MB, 65536 c-switches
received 32768 MB (100 % mmap'ed) in 115.985 s, 2.36995 Gbit
cpu usage user:0.057 sys:2.492, 77.7893 usec per MB, 65536 c-switches
received 32768 MB (100 % mmap'ed) in 62.633 s, 4.38871 Gbit
cpu usage user:0.048 sys:2.076, 64.8193 usec per MB, 65536 c-switches
received 32768 MB (100 % mmap'ed) in 59.4608 s, 4.62285 Gbit
cpu usage user:0.047 sys:1.965, 61.4014 usec per MB, 65536 c-switches
received 32768 MB (100 % mmap'ed) in 119.364 s, 2.30285 Gbit
cpu usage user:0.057 sys:2.757, 85.8765 usec per MB, 65536 c-switches
received 32768 MB (100 % mmap'ed) in 121.37 s, 2.2648 Gbit
cpu usage user:0.05 sys:2.224, 69.397 usec per MB, 65536 c-switches
received 32768 MB (100 % mmap'ed) in 121.382 s, 2.26457 Gbit
cpu usage user:0.049 sys:2.163, 67.5049 usec per MB, 65538 c-switches
received 32768 MB (100 % mmap'ed) in 39.7636 s, 6.91281 Gbit
cpu usage user:0.055 sys:2.053, 64.3311 usec per MB, 65536 c-switches
received 32768 MB (100 % mmap'ed) in 21.2803 s, 12.917 Gbit
cpu usage user:0.043 sys:2.057, 64.0869 usec per MB, 65537 c-switches
When zero copy is not enabled :
received 32768 MB (0 % mmap'ed) in 49.4301 s, 5.56094 Gbit
cpu usage user:0.036 sys:6.747, 207.001 usec per MB, 65546 c-switches
received 32768 MB (0 % mmap'ed) in 49.431 s, 5.56084 Gbit
cpu usage user:0.042 sys:5.262, 161.865 usec per MB, 65540 c-switches
received 32768 MB (0 % mmap'ed) in 84.7254 s, 3.24434 Gbit
cpu usage user:0.045 sys:5.154, 158.661 usec per MB, 65548 c-switches
received 32768 MB (0 % mmap'ed) in 84.7274 s, 3.24426 Gbit
cpu usage user:0.043 sys:6.528, 200.531 usec per MB, 65542 c-switches
received 32768 MB (0 % mmap'ed) in 35.3133 s, 7.78398 Gbit
cpu usage user:0.032 sys:5.066, 155.579 usec per MB, 65540 c-switches
received 32768 MB (0 % mmap'ed) in 35.3137 s, 7.78389 Gbit
cpu usage user:0.034 sys:6.358, 195.068 usec per MB, 65536 c-switches
received 32768 MB (0 % mmap'ed) in 98.8568 s, 2.78057 Gbit
cpu usage user:0.042 sys:6.519, 200.226 usec per MB, 65550 c-switches
received 32768 MB (0 % mmap'ed) in 98.8638 s, 2.78037 Gbit
cpu usage user:0.042 sys:5.243, 161.285 usec per MB, 65545 c-switches
received 32768 MB (0 % mmap'ed) in 108.282 s, 2.53853 Gbit
cpu usage user:0.059 sys:5.938, 183.014 usec per MB, 65538 c-switches
received 32768 MB (0 % mmap'ed) in 108.314 s, 2.53778 Gbit
cpu usage user:0.04 sys:6.096, 187.256 usec per MB, 65548 c-switches
received 32768 MB (0 % mmap'ed) in 29.4351 s, 9.33845 Gbit
cpu usage user:0.041 sys:6.03, 185.272 usec per MB, 65536 c-switches
received 32768 MB (0 % mmap'ed) in 44.3993 s, 6.19104 Gbit
cpu usage user:0.034 sys:5.115, 157.135 usec per MB, 65535 c-switches
received 32768 MB (0 % mmap'ed) in 79.7203 s, 3.44803 Gbit
cpu usage user:0.046 sys:5.214, 160.522 usec per MB, 65540 c-switches
^ permalink raw reply
* Re: [PATCH net-next 1/2] tcp: add TCP_ZEROCOPY_RECEIVE support for zerocopy receive
From: Eric Dumazet @ 2018-04-25 16:35 UTC (permalink / raw)
To: Andy Lutomirski, Matthew Wilcox
Cc: Eric Dumazet, Christoph Hellwig, Eric Dumazet, David S . Miller,
netdev, linux-kernel, linux-mm, Soheil Hassas Yeganeh
In-Reply-To: <CALCETrWaekirEe+rKiPB-Zim6ZHKL-n7nfk9wrsHra_FtrS=DA@mail.gmail.com>
On 04/25/2018 09:22 AM, Andy Lutomirski wrote:
> In general, I suspect that the zerocopy receive mechanism will only
> really be a win in single-threaded applications that consume large
> amounts of receive bandwidth on a single TCP socket using lots of
> memory and don't do all that much else.
This was dully noted in the original patch submission.
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=309c446cb45f6663932c8e6d0754f4ac81d1b5cd
Our intent at Google is to use it for some specific 1MB+ receives, not as a generic and universal mechanism.
The major benefit is really the 4KB+ MTU, allowing to pack exactly 4096 bytes of payload per page.
^ permalink raw reply
* Re: [PATCH net-next 1/2] tcp: add TCP_ZEROCOPY_RECEIVE support for zerocopy receive
From: Matthew Wilcox @ 2018-04-25 16:30 UTC (permalink / raw)
To: Eric Dumazet
Cc: Christoph Hellwig, Eric Dumazet, David S . Miller, netdev,
Andy Lutomirski, linux-kernel, linux-mm, Soheil Hassas Yeganeh
In-Reply-To: <8ce78bd6-8142-2937-11fd-2e4a2b22d90c@gmail.com>
On Wed, Apr 25, 2018 at 09:20:55AM -0700, Eric Dumazet wrote:
> On 04/25/2018 09:04 AM, Matthew Wilcox wrote:
> > If you don't zap the page range, any of the CPUs in the system where
> > any thread in this task have ever run may have a TLB entry pointing to
> > this page ... if the page is being recycled into the page allocator,
> > then that page might end up as a slab page or page table or page cache
> > while the other CPU still have access to it.
>
> Yes, this makes sense.
>
> >
> > You could hang onto the page until you've built up a sufficiently large
> > batch, then bulk-invalidate all of the TLB entries, but we start to get
> > into weirdnesses on different CPU architectures.
> >
>
> zap_page_range() is already doing a bulk-invalidate,
> so maybe vm_replace_page() wont bring serious improvement if we end-up doing same dance.
Sorry, I was unclear. zap_page_range() bulk-invalidates all pages that
were torn down as part of this call. What I was trying to say was that
we could have a whole new API which put page after page into the same
address, and bumped the refcount on them to prevent them from actually
being freed. Once we get to a batch limit, we invalidate all of the
pages which were mapped at those addresses and can then free the pages
back to the allocator.
I don't think you can implement this scheme on s390 because it requires
the userspace address to still be mapped to that page on shootdown
(?) but I think we could implement it on x86.
Another possibility is if we had some way to insert the TLB entry into
the local CPU's page tables only, we wouldn't need to broadcast-invalidate
the TLB entry; we could just do it locally which is relatively quick.
^ permalink raw reply
* [net 1/1] tipc: fix bug in function tipc_nl_node_dump_monitor
From: Jon Maloy @ 2018-04-25 16:29 UTC (permalink / raw)
To: davem, netdev
Cc: mohan.krishna.ghanta.krishnamurthy, tung.q.nguyen, hoang.h.le,
jon.maloy, canh.d.luu, ying.xue, tipc-discussion
Commit 36a50a989ee8 ("tipc: fix infinite loop when dumping link monitor
summary") intended to fix a problem with user tool looping when max
number of bearers are enabled.
Unfortunately, the wrong version of the commit was posted, so the
problem was not solved at all.
This commit adds the missing part.
Fixes: 36a50a989ee8 ("tipc: fix infinite loop when dumping link monitor summary")
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
---
net/tipc/node.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/tipc/node.c b/net/tipc/node.c
index 6f98b56..baaf93f 100644
--- a/net/tipc/node.c
+++ b/net/tipc/node.c
@@ -2244,7 +2244,7 @@ int tipc_nl_node_dump_monitor(struct sk_buff *skb, struct netlink_callback *cb)
rtnl_lock();
for (bearer_id = prev_bearer; bearer_id < MAX_BEARERS; bearer_id++) {
- err = __tipc_nl_add_monitor(net, &msg, prev_bearer);
+ err = __tipc_nl_add_monitor(net, &msg, bearer_id);
if (err)
break;
}
--
2.1.4
^ permalink raw reply related
* Re: [PATCH net-next v3] Add Common Applications Kept Enhanced (cake) qdisc
From: Eric Dumazet @ 2018-04-25 16:29 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, Eric Dumazet, netdev; +Cc: cake, Dave Taht
In-Reply-To: <8736zj6zj2.fsf@toke.dk>
On 04/25/2018 09:06 AM, Toke Høiland-Jørgensen wrote:
> Eric Dumazet <eric.dumazet@gmail.com> writes:
>
>> On 04/25/2018 08:22 AM, Toke Høiland-Jørgensen wrote:
>>> Eric Dumazet <eric.dumazet@gmail.com> writes:
>>
>>>> What performance number do you get on a 10Gbit NIC for example ?
>>>
>>> Single-flow throughput through 2 hops on a 40Gbit connection (with CAKE
>>> in unlimited mode vs pfifo_fast on the router):
>>>
>>> MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to testbed-40g-2 () port 0 AF_INET : demo
>>> Recv Send Send
>>> Socket Socket Message Elapsed
>>> Size Size Size Time Throughput
>>> bytes bytes bytes secs. 10^6bits/sec
>>>
>>> 87380 16384 16384 10.00 18840.40
>>>
>>> MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to testbed-40g-2 () port 0 AF_INET : demo
>>> Recv Send Send
>>> Socket Socket Message Elapsed
>>> Size Size Size Time Throughput
>>> bytes bytes bytes secs. 10^6bits/sec
>>>
>>> 87380 16384 16384 10.00 24804.77
>>
>> CPU performance would be interesting here. (netperf -Cc)
>
>
> $ sudo tc qdisc replace dev ens2 root cake
> $ netperf -cC -H 10.70.2.2
> MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.70.2.2 () port 0 AF_INET : demo
> Recv Send Send Utilization Service Demand
> Socket Socket Message Elapsed Send Recv Send Recv
> Size Size Size Time Throughput local remote local remote
> bytes bytes bytes secs. 10^6bits/s % S % S us/KB us/KB
>
> 87380 16384 16384 10.00 15450.35 13.35 6.68 0.849 0.283
>
> $ sudo tc qdisc del dev ens2 root
> $ netperf -cC -H 10.70.2.2
> MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.70.2.2 () port 0 AF_INET : demo
> Recv Send Send Utilization Service Demand
> Socket Socket Message Elapsed Send Recv Send Recv
> Size Size Size Time Throughput local remote local remote
> bytes bytes bytes secs. 10^6bits/s % S % S us/KB us/KB
>
> 87380 16384 16384 10.00 36414.23 8.20 14.30 0.221 0.257
>
>
> (In this test I'm running netperf on the machine that was a router
> before, which is why the base throughput is higher; the other machine
> runs out of CPU on the sender side).
We can see here the high cost of forcing software GSO :/
Really, this should be done only :
1) If requested by the admin ( tc .... gso ....)
2) If packet size is above a threshold.
The threshold could be set by the admin, and/or based on a fraction of the bandwidth parameter.
I totally understand why you prefer to segment yourself for < 100 Mbit links.
But this makes no sense on 10Gbit+
^ permalink raw reply
* Re: [PATCH 3/8] ARM: dts: stm32: add ethernet pins to stm32mp157c
From: Alexandre Torgue @ 2018-04-25 16:22 UTC (permalink / raw)
To: Rob Herring, Christophe Roullier
Cc: Mark Rutland, Maxime Coquelin, Giuseppe CAVALLARO, devicetree,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE, netdev
In-Reply-To: <CAL_JsqL7bY=OSuzeVHH2UxxaBmCMzpFc8djnuZAY6VWcTgUmZw@mail.gmail.com>
Hi Rob,
On 04/25/2018 05:09 PM, Rob Herring wrote:
> On Tue, Apr 24, 2018 at 10:01 AM, Christophe Roullier
> <christophe.roullier@st.com> wrote:
>> Add ethernet pins on stm32mp157c.
>>
>> Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
>> ---
>> arch/arm/boot/dts/stm32mp157-pinctrl.dtsi | 46 +++++++++++++++++++++++++++++++
>> 1 file changed, 46 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi b/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
>> index 6f044100..86720a5 100644
>> --- a/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
>> +++ b/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
>> @@ -158,6 +158,52 @@
>> bias-disable;
>> };
>> };
>> +
>> + ethernet0_rgmii_pins_a: rgmii@0 {
>
> A unit-address without 'reg' property is not valid, so drop the '@0'.
>
Thanks for the highlights. We could replace rgmii@0 by rgmii-0.
If no objections, I will send a series to update all STM32 device tree
files (MCUs legacy). I will take care about it for future STM32 DT review.
Thanks
Alex
> Please build your dtb with W=1 or W=12 which will tell you this and
> other errors.
>
> Rob
>
^ permalink raw reply
* Re: [PATCH net-next 1/2] tcp: add TCP_ZEROCOPY_RECEIVE support for zerocopy receive
From: Andy Lutomirski @ 2018-04-25 16:22 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Eric Dumazet, Christoph Hellwig, Eric Dumazet, David S . Miller,
netdev, Andy Lutomirski, linux-kernel, linux-mm,
Soheil Hassas Yeganeh
In-Reply-To: <20180425160413.GC8546@bombadil.infradead.org>
On Wed, Apr 25, 2018 at 9:04 AM, Matthew Wilcox <willy@infradead.org> wrote:
> On Wed, Apr 25, 2018 at 06:01:02AM -0700, Eric Dumazet wrote:
>> On 04/24/2018 11:28 PM, Christoph Hellwig wrote:
>> > On Tue, Apr 24, 2018 at 10:27:21PM -0700, Eric Dumazet wrote:
>> >> When adding tcp mmap() implementation, I forgot that socket lock
>> >> had to be taken before current->mm->mmap_sem. syzbot eventually caught
>> >> the bug.
>> >>
>> >> Since we can not lock the socket in tcp mmap() handler we have to
>> >> split the operation in two phases.
>> >>
>> >> 1) mmap() on a tcp socket simply reserves VMA space, and nothing else.
>> >> This operation does not involve any TCP locking.
>> >>
>> >> 2) setsockopt(fd, IPPROTO_TCP, TCP_ZEROCOPY_RECEIVE, ...) implements
>> >> the transfert of pages from skbs to one VMA.
>> >> This operation only uses down_read(¤t->mm->mmap_sem) after
>> >> holding TCP lock, thus solving the lockdep issue.
>> >>
>> >> This new implementation was suggested by Andy Lutomirski with great details.
>> >
>> > Thanks, this looks much more sensible to me.
>> >
>>
>> Thanks Christoph
>>
>> Note the high cost of zap_page_range(), needed to avoid -EBUSY being returned
>> from vm_insert_page() the second time TCP_ZEROCOPY_RECEIVE is used on one VMA.
>>
>> Ideally a vm_replace_page() would avoid this cost ?
>
> If you don't zap the page range, any of the CPUs in the system where
> any thread in this task have ever run may have a TLB entry pointing to
> this page ... if the page is being recycled into the page allocator,
> then that page might end up as a slab page or page table or page cache
> while the other CPU still have access to it.
Indeed. This is one of the reasons that Linus has generally been
quite vocal that he doesn't like MMU-based zerocopy schemes.
>
> You could hang onto the page until you've built up a sufficiently large
> batch, then bulk-invalidate all of the TLB entries, but we start to get
> into weirdnesses on different CPU architectures.
The existing mmu_gather code should already handle this at least
moderately well. If it's not, then it should be fixed.
On x86, there is no operation to flush a range of addresses. You can
flush one address or you can flush all of them. If you flush one page
at a time, then you might never recover the performance of a plain old
memcpy(). If you flush all of them, then you're hurting the
performance of everything else in the task.
In general, I suspect that the zerocopy receive mechanism will only
really be a win in single-threaded applications that consume large
amounts of receive bandwidth on a single TCP socket using lots of
memory and don't do all that much else.
^ permalink raw reply
* Re: [PATCH net-next 1/2] tcp: add TCP_ZEROCOPY_RECEIVE support for zerocopy receive
From: Eric Dumazet @ 2018-04-25 16:20 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Christoph Hellwig, Eric Dumazet, David S . Miller, netdev,
Andy Lutomirski, linux-kernel, linux-mm, Soheil Hassas Yeganeh
In-Reply-To: <20180425160413.GC8546@bombadil.infradead.org>
On 04/25/2018 09:04 AM, Matthew Wilcox wrote:
> If you don't zap the page range, any of the CPUs in the system where
> any thread in this task have ever run may have a TLB entry pointing to
> this page ... if the page is being recycled into the page allocator,
> then that page might end up as a slab page or page table or page cache
> while the other CPU still have access to it.
Yes, this makes sense.
>
> You could hang onto the page until you've built up a sufficiently large
> batch, then bulk-invalidate all of the TLB entries, but we start to get
> into weirdnesses on different CPU architectures.
>
zap_page_range() is already doing a bulk-invalidate,
so maybe vm_replace_page() wont bring serious improvement if we end-up doing same dance.
Thanks.
^ permalink raw reply
* Re: [PATCH 0/3] bpf: Store/dump license string for loaded program
From: Jiri Olsa @ 2018-04-25 16:20 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Jiri Olsa, Alexei Starovoitov, Daniel Borkmann, lkml, netdev,
Quentin Monnet
In-Reply-To: <20180425161527.w7xgpg75npdx2zmb@ast-mbp>
On Wed, Apr 25, 2018 at 10:15:29AM -0600, Alexei Starovoitov wrote:
> On Wed, Apr 25, 2018 at 12:17:13PM +0200, Jiri Olsa wrote:
> > On Mon, Apr 23, 2018 at 02:11:36PM -0600, Alexei Starovoitov wrote:
> > > On Mon, Apr 23, 2018 at 08:59:24AM +0200, Jiri Olsa wrote:
> > > > hi,
> > > > sending the change to store and dump the license
> > > > info for loaded BPF programs. It's important for
> > > > us get the license info, when investigating on
> > > > screwed up machine.
> > >
> > > hmm. boolean flag whether bpf prog is gpl or not
> > > is already exposed via bpf_prog_info.
> >
> > hum, I can't see that (on bpf-next/master)
> > would the attached change be ok with you?
> >
> > jirka
> >
> >
> > ---
> > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> > index e6679393b687..2ce9c9d41c2b 100644
> > --- a/include/uapi/linux/bpf.h
> > +++ b/include/uapi/linux/bpf.h
> > @@ -1062,6 +1062,7 @@ struct bpf_prog_info {
> > __u32 ifindex;
> > __u64 netns_dev;
> > __u64 netns_ino;
> > + __u16 gpl_compatible:1;
> > } __attribute__((aligned(8)));
>
> ahh. I swear there were patches to add it and I thought we accepted them.
> Also just noticed that commit 675fc275a3a2d added 4-byte hole in there.
> So I'm thinking we can fill the hole with
> __u32 ifindex;
> + __u32 gpl_compatible:1;
> __u64 netns_dev;
> __u64 netns_ino;
>
> and keep adding bit fields in there without breaking user space.
> Such patch would need to go to bpf tree.
>
ok, will post v2 with that
thanks,
jirka
^ permalink raw reply
* Re: [PATCH net-next v3] Add Common Applications Kept Enhanced (cake) qdisc
From: Toke Høiland-Jørgensen @ 2018-04-25 16:17 UTC (permalink / raw)
To: Eric Dumazet, netdev; +Cc: cake, Dave Taht
In-Reply-To: <fd92ddfd-e2a6-6ea9-ccf6-d7eef3a5f207@gmail.com>
Eric Dumazet <eric.dumazet@gmail.com> writes:
> On 04/25/2018 08:22 AM, Toke Høiland-Jørgensen wrote:
>> Eric Dumazet <eric.dumazet@gmail.com> writes:
>
>>> Lack of any pskb_may_pull() is really concerning.
>>
>> By this you mean "check that the packet is long enough to contain the
>> header we are looking for before trying to do ACK filtering", right?
>
>
> skb->len is not enough, you also have skb->data_len that matters.
>
> A qdisc can be fed with skbs that are not linear, or pretend to be
> TCP, but they be truncated by malicious sender.
>
> skb might have headers or payload in the page fragments, thus we
> generally have to call pskb_may_pull() to bring headers in skb->head
Right, gotcha; was just making sure I understood you correctly.
> Quite frankly , an ack-filter does not belong to a packet scheduler.
>
> It might be added to tcp conntrack module _if_ someone really cares.
Well, integrating it with the queue does have the advantage of only
filtering ACKs if the flow is actually bottlenecked...
That being said, I'm not personally hugely attached to the ACK filter;
let's see if someone one the cake list speaks up in favour of keeping
it.
Or am I to interpret that as a hard NAK on having this feature in CAKE
(even if we fix the issues you pointed out)?
-Toke
^ permalink raw reply
* Re: [PATCH 0/3] bpf: Store/dump license string for loaded program
From: Alexei Starovoitov @ 2018-04-25 16:15 UTC (permalink / raw)
To: Jiri Olsa
Cc: Jiri Olsa, Alexei Starovoitov, Daniel Borkmann, lkml, netdev,
Quentin Monnet
In-Reply-To: <20180425101713.GB3396@krava>
On Wed, Apr 25, 2018 at 12:17:13PM +0200, Jiri Olsa wrote:
> On Mon, Apr 23, 2018 at 02:11:36PM -0600, Alexei Starovoitov wrote:
> > On Mon, Apr 23, 2018 at 08:59:24AM +0200, Jiri Olsa wrote:
> > > hi,
> > > sending the change to store and dump the license
> > > info for loaded BPF programs. It's important for
> > > us get the license info, when investigating on
> > > screwed up machine.
> >
> > hmm. boolean flag whether bpf prog is gpl or not
> > is already exposed via bpf_prog_info.
>
> hum, I can't see that (on bpf-next/master)
> would the attached change be ok with you?
>
> jirka
>
>
> ---
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index e6679393b687..2ce9c9d41c2b 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -1062,6 +1062,7 @@ struct bpf_prog_info {
> __u32 ifindex;
> __u64 netns_dev;
> __u64 netns_ino;
> + __u16 gpl_compatible:1;
> } __attribute__((aligned(8)));
ahh. I swear there were patches to add it and I thought we accepted them.
Also just noticed that commit 675fc275a3a2d added 4-byte hole in there.
So I'm thinking we can fill the hole with
__u32 ifindex;
+ __u32 gpl_compatible:1;
__u64 netns_dev;
__u64 netns_ino;
and keep adding bit fields in there without breaking user space.
Such patch would need to go to bpf tree.
^ permalink raw reply
* Re: [PATCH net-next v3] Add Common Applications Kept Enhanced (cake) qdisc
From: Toke Høiland-Jørgensen @ 2018-04-25 16:06 UTC (permalink / raw)
To: Eric Dumazet, netdev; +Cc: cake, Dave Taht
In-Reply-To: <6bc11ded-028f-6c8f-964e-a569b4e10813@gmail.com>
Eric Dumazet <eric.dumazet@gmail.com> writes:
> On 04/25/2018 08:22 AM, Toke Høiland-Jørgensen wrote:
>> Eric Dumazet <eric.dumazet@gmail.com> writes:
>
>>> What performance number do you get on a 10Gbit NIC for example ?
>>
>> Single-flow throughput through 2 hops on a 40Gbit connection (with CAKE
>> in unlimited mode vs pfifo_fast on the router):
>>
>> MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to testbed-40g-2 () port 0 AF_INET : demo
>> Recv Send Send
>> Socket Socket Message Elapsed
>> Size Size Size Time Throughput
>> bytes bytes bytes secs. 10^6bits/sec
>>
>> 87380 16384 16384 10.00 18840.40
>>
>> MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to testbed-40g-2 () port 0 AF_INET : demo
>> Recv Send Send
>> Socket Socket Message Elapsed
>> Size Size Size Time Throughput
>> bytes bytes bytes secs. 10^6bits/sec
>>
>> 87380 16384 16384 10.00 24804.77
>
> CPU performance would be interesting here. (netperf -Cc)
$ sudo tc qdisc replace dev ens2 root cake
$ netperf -cC -H 10.70.2.2
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.70.2.2 () port 0 AF_INET : demo
Recv Send Send Utilization Service Demand
Socket Socket Message Elapsed Send Recv Send Recv
Size Size Size Time Throughput local remote local remote
bytes bytes bytes secs. 10^6bits/s % S % S us/KB us/KB
87380 16384 16384 10.00 15450.35 13.35 6.68 0.849 0.283
$ sudo tc qdisc del dev ens2 root
$ netperf -cC -H 10.70.2.2
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.70.2.2 () port 0 AF_INET : demo
Recv Send Send Utilization Service Demand
Socket Socket Message Elapsed Send Recv Send Recv
Size Size Size Time Throughput local remote local remote
bytes bytes bytes secs. 10^6bits/s % S % S us/KB us/KB
87380 16384 16384 10.00 36414.23 8.20 14.30 0.221 0.257
(In this test I'm running netperf on the machine that was a router
before, which is why the base throughput is higher; the other machine
runs out of CPU on the sender side).
-Toke
^ permalink raw reply
* [PATCH 12/17] y2038: aio: Prepare sys_io_getevents for __kernel_timespec
From: Arnd Bergmann @ 2018-04-25 16:03 UTC (permalink / raw)
To: y2038, linux-kernel
Cc: Arnd Bergmann, linux-api, linux-arch, libc-alpha, tglx, netdev,
deepa.kernel, viro, albert.aribaud, Peter Zijlstra, Darren Hart,
Eric W. Biederman, Dominik Brodowski
In-Reply-To: <20180425160311.2718314-1-arnd@arndb.de>
This is a preparation patch for converting sys_io_getevents to
work with 64-bit time_t on 32-bit architectures. The 'timeout' argument
is changed to struct __kernel_timespec, which will be redefined using
64-bit time_t in the future. The compat version of the system call in
turn is enabled for compilation with CONFIG_COMPAT_32BIT_TIME so
the individual 32-bit architectures can share the handling of the
traditional argument with 64-bit architectures providing it for their
compat mode.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
fs/aio.c | 4 ++--
include/linux/syscalls.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/aio.c b/fs/aio.c
index 88d7927ffbc6..64fea8c27b16 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -1858,7 +1858,7 @@ SYSCALL_DEFINE5(io_getevents, aio_context_t, ctx_id,
long, min_nr,
long, nr,
struct io_event __user *, events,
- struct timespec __user *, timeout)
+ struct __kernel_timespec __user *, timeout)
{
struct timespec64 ts;
@@ -1870,7 +1870,7 @@ SYSCALL_DEFINE5(io_getevents, aio_context_t, ctx_id,
return do_io_getevents(ctx_id, min_nr, nr, events, timeout ? &ts : NULL);
}
-#ifdef CONFIG_COMPAT
+#ifdef CONFIG_COMPAT_32BIT_TIME
COMPAT_SYSCALL_DEFINE5(io_getevents, compat_aio_context_t, ctx_id,
compat_long_t, min_nr,
compat_long_t, nr,
diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
index 2619678359ee..ffd8674e9df7 100644
--- a/include/linux/syscalls.h
+++ b/include/linux/syscalls.h
@@ -289,7 +289,7 @@ asmlinkage long sys_io_getevents(aio_context_t ctx_id,
long min_nr,
long nr,
struct io_event __user *events,
- struct timespec __user *timeout);
+ struct __kernel_timespec __user *timeout);
/* fs/xattr.c */
asmlinkage long sys_setxattr(const char __user *path, const char __user *name,
--
2.9.0
^ permalink raw reply related
* [PATCH 17/17] y2038: signal: Add compat_sys_rt_sigtimedwait_time64
From: Arnd Bergmann @ 2018-04-25 16:03 UTC (permalink / raw)
To: y2038, linux-kernel
Cc: Arnd Bergmann, linux-api, linux-arch, libc-alpha, tglx, netdev,
deepa.kernel, viro, albert.aribaud, Peter Zijlstra, Darren Hart,
Eric W. Biederman, Dominik Brodowski
In-Reply-To: <20180425160311.2718314-1-arnd@arndb.de>
Now that 32-bit architectures have two variants of
sys_rt_sigtimedwaid() for 32-bit and 64-bit time_t, we also
need to have a second compat system call entry point on the
corresponding 64-bit architectures.
The traditional system call keeps getting handled
by compat_sys_rt_sigtimedwait(), and this adds a new
compat_sys_rt_sigtimedwait_time64() that differs only in
the timeout argument type.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
kernel/signal.c | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/kernel/signal.c b/kernel/signal.c
index 72609c6835fd..1927fcfa7077 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -3249,6 +3249,38 @@ COMPAT_SYSCALL_DEFINE4(rt_sigtimedwait, compat_sigset_t __user *, uthese,
}
#endif
+#ifdef CONFIG_COMPAT
+COMPAT_SYSCALL_DEFINE4(rt_sigtimedwait_time64, compat_sigset_t __user *, uthese,
+ struct compat_siginfo __user *, uinfo,
+ struct __kernel_timespec __user *, uts, compat_size_t, sigsetsize)
+{
+ sigset_t s;
+ struct timespec64 t;
+ siginfo_t info;
+ long ret;
+
+ if (sigsetsize != sizeof(sigset_t))
+ return -EINVAL;
+
+ if (get_compat_sigset(&s, uthese))
+ return -EFAULT;
+
+ if (uts) {
+ if (get_timespec64(&t, uts))
+ return -EFAULT;
+ }
+
+ ret = do_sigtimedwait(&s, &info, uts ? &t : NULL);
+
+ if (ret > 0 && uinfo) {
+ if (copy_siginfo_to_user32(uinfo, &info))
+ ret = -EFAULT;
+ }
+
+ return ret;
+}
+#endif
+
/**
* sys_kill - send a signal to a process
* @pid: the PID of the process
--
2.9.0
^ permalink raw reply related
* [PATCH 01/17] y2038: compat: Move common compat types to asm-generic/compat.h
From: Arnd Bergmann @ 2018-04-25 16:02 UTC (permalink / raw)
To: y2038, linux-kernel
Cc: Arnd Bergmann, linux-api, linux-arch, libc-alpha, tglx, netdev,
deepa.kernel, viro, albert.aribaud, Peter Zijlstra, Darren Hart,
Eric W. Biederman, Dominik Brodowski
In-Reply-To: <20180425160311.2718314-1-arnd@arndb.de>
The architectures that support 32-bit compat mode define a number
of simple types for use in compat handlers. About half of those
are identical between architectures, and some of those are also
required now by handlers shared with CONFIG_COMPAT_32BIT_TIME
functions on 32-bit architectures.
Let's move all the identical ones into asm-generic/compat.h to avoid
having to add even more identical definitions of those types.
For unknown reasons, mips defines __compat_gid32_t, __compat_uid32_t
and compat_caddr_t as signed, while all others have them unsigned.
This seems to be a mistake, but I'm leaving it alone here. The other
types all differ by size or alignment on at least on architecture.
compat_aio_context_t is currently defined in linux/compat.h but
also needed for compat_sys_io_getevents(), so let's move it into
the same place.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm64/include/asm/compat.h | 20 ++------------------
arch/mips/include/asm/compat.h | 22 ++--------------------
arch/parisc/include/asm/compat.h | 18 ++----------------
arch/powerpc/include/asm/compat.h | 18 ++----------------
arch/s390/include/asm/compat.h | 18 ++----------------
arch/sparc/include/asm/compat.h | 19 ++-----------------
arch/x86/include/asm/compat.h | 19 ++-----------------
include/asm-generic/compat.h | 24 +++++++++++++++++++++++-
include/linux/compat.h | 2 --
9 files changed, 37 insertions(+), 123 deletions(-)
diff --git a/arch/arm64/include/asm/compat.h b/arch/arm64/include/asm/compat.h
index 1a037b94eba1..a4c79f9e856d 100644
--- a/arch/arm64/include/asm/compat.h
+++ b/arch/arm64/include/asm/compat.h
@@ -25,6 +25,8 @@
#include <linux/sched.h>
#include <linux/sched/task_stack.h>
+#include <asm-generic/compat.h>
+
#define COMPAT_USER_HZ 100
#ifdef __AARCH64EB__
#define COMPAT_UTS_MACHINE "armv8b\0\0"
@@ -32,10 +34,6 @@
#define COMPAT_UTS_MACHINE "armv8l\0\0"
#endif
-typedef u32 compat_size_t;
-typedef s32 compat_ssize_t;
-typedef s32 compat_clock_t;
-typedef s32 compat_pid_t;
typedef u16 __compat_uid_t;
typedef u16 __compat_gid_t;
typedef u16 __compat_uid16_t;
@@ -43,27 +41,13 @@ typedef u16 __compat_gid16_t;
typedef u32 __compat_uid32_t;
typedef u32 __compat_gid32_t;
typedef u16 compat_mode_t;
-typedef u32 compat_ino_t;
typedef u32 compat_dev_t;
-typedef s32 compat_off_t;
-typedef s64 compat_loff_t;
typedef s32 compat_nlink_t;
typedef u16 compat_ipc_pid_t;
-typedef s32 compat_daddr_t;
typedef u32 compat_caddr_t;
typedef __kernel_fsid_t compat_fsid_t;
-typedef s32 compat_key_t;
-typedef s32 compat_timer_t;
-
-typedef s16 compat_short_t;
-typedef s32 compat_int_t;
-typedef s32 compat_long_t;
typedef s64 compat_s64;
-typedef u16 compat_ushort_t;
-typedef u32 compat_uint_t;
-typedef u32 compat_ulong_t;
typedef u64 compat_u64;
-typedef u32 compat_uptr_t;
struct compat_stat {
#ifdef __AARCH64EB__
diff --git a/arch/mips/include/asm/compat.h b/arch/mips/include/asm/compat.h
index 78675f19440f..7033a7c93b48 100644
--- a/arch/mips/include/asm/compat.h
+++ b/arch/mips/include/asm/compat.h
@@ -9,43 +9,25 @@
#include <asm/page.h>
#include <asm/ptrace.h>
+#include <asm-generic/compat.h>
+
#define COMPAT_USER_HZ 100
#define COMPAT_UTS_MACHINE "mips\0\0\0"
-typedef u32 compat_size_t;
-typedef s32 compat_ssize_t;
-typedef s32 compat_clock_t;
-typedef s32 compat_suseconds_t;
-
-typedef s32 compat_pid_t;
typedef s32 __compat_uid_t;
typedef s32 __compat_gid_t;
typedef __compat_uid_t __compat_uid32_t;
typedef __compat_gid_t __compat_gid32_t;
typedef u32 compat_mode_t;
-typedef u32 compat_ino_t;
typedef u32 compat_dev_t;
-typedef s32 compat_off_t;
-typedef s64 compat_loff_t;
typedef u32 compat_nlink_t;
typedef s32 compat_ipc_pid_t;
-typedef s32 compat_daddr_t;
typedef s32 compat_caddr_t;
typedef struct {
s32 val[2];
} compat_fsid_t;
-typedef s32 compat_timer_t;
-typedef s32 compat_key_t;
-
-typedef s16 compat_short_t;
-typedef s32 compat_int_t;
-typedef s32 compat_long_t;
typedef s64 compat_s64;
-typedef u16 compat_ushort_t;
-typedef u32 compat_uint_t;
-typedef u32 compat_ulong_t;
typedef u64 compat_u64;
-typedef u32 compat_uptr_t;
struct compat_stat {
compat_dev_t st_dev;
diff --git a/arch/parisc/include/asm/compat.h b/arch/parisc/include/asm/compat.h
index ab8a54771507..f707e025f89b 100644
--- a/arch/parisc/include/asm/compat.h
+++ b/arch/parisc/include/asm/compat.h
@@ -8,36 +8,22 @@
#include <linux/sched.h>
#include <linux/thread_info.h>
+#include <asm-generic/compat.h>
+
#define COMPAT_USER_HZ 100
#define COMPAT_UTS_MACHINE "parisc\0\0"
-typedef u32 compat_size_t;
-typedef s32 compat_ssize_t;
-typedef s32 compat_clock_t;
-typedef s32 compat_pid_t;
typedef u32 __compat_uid_t;
typedef u32 __compat_gid_t;
typedef u32 __compat_uid32_t;
typedef u32 __compat_gid32_t;
typedef u16 compat_mode_t;
-typedef u32 compat_ino_t;
typedef u32 compat_dev_t;
-typedef s32 compat_off_t;
-typedef s64 compat_loff_t;
typedef u16 compat_nlink_t;
typedef u16 compat_ipc_pid_t;
-typedef s32 compat_daddr_t;
typedef u32 compat_caddr_t;
-typedef s32 compat_key_t;
-typedef s32 compat_timer_t;
-
-typedef s32 compat_int_t;
-typedef s32 compat_long_t;
typedef s64 compat_s64;
-typedef u32 compat_uint_t;
-typedef u32 compat_ulong_t;
typedef u64 compat_u64;
-typedef u32 compat_uptr_t;
struct compat_stat {
compat_dev_t st_dev; /* dev_t is 32 bits on parisc */
diff --git a/arch/powerpc/include/asm/compat.h b/arch/powerpc/include/asm/compat.h
index 85c8af2bb272..036b210b1582 100644
--- a/arch/powerpc/include/asm/compat.h
+++ b/arch/powerpc/include/asm/compat.h
@@ -8,6 +8,8 @@
#include <linux/types.h>
#include <linux/sched.h>
+#include <asm-generic/compat.h>
+
#define COMPAT_USER_HZ 100
#ifdef __BIG_ENDIAN__
#define COMPAT_UTS_MACHINE "ppc\0\0"
@@ -15,34 +17,18 @@
#define COMPAT_UTS_MACHINE "ppcle\0\0"
#endif
-typedef u32 compat_size_t;
-typedef s32 compat_ssize_t;
-typedef s32 compat_clock_t;
-typedef s32 compat_pid_t;
typedef u32 __compat_uid_t;
typedef u32 __compat_gid_t;
typedef u32 __compat_uid32_t;
typedef u32 __compat_gid32_t;
typedef u32 compat_mode_t;
-typedef u32 compat_ino_t;
typedef u32 compat_dev_t;
-typedef s32 compat_off_t;
-typedef s64 compat_loff_t;
typedef s16 compat_nlink_t;
typedef u16 compat_ipc_pid_t;
-typedef s32 compat_daddr_t;
typedef u32 compat_caddr_t;
typedef __kernel_fsid_t compat_fsid_t;
-typedef s32 compat_key_t;
-typedef s32 compat_timer_t;
-
-typedef s32 compat_int_t;
-typedef s32 compat_long_t;
typedef s64 compat_s64;
-typedef u32 compat_uint_t;
-typedef u32 compat_ulong_t;
typedef u64 compat_u64;
-typedef u32 compat_uptr_t;
struct compat_stat {
compat_dev_t st_dev;
diff --git a/arch/s390/include/asm/compat.h b/arch/s390/include/asm/compat.h
index 97db2fba546a..63b46e30b2c3 100644
--- a/arch/s390/include/asm/compat.h
+++ b/arch/s390/include/asm/compat.h
@@ -9,6 +9,8 @@
#include <linux/sched/task_stack.h>
#include <linux/thread_info.h>
+#include <asm-generic/compat.h>
+
#define __TYPE_IS_PTR(t) (!__builtin_types_compatible_p( \
typeof(0?(__force t)0:0ULL), u64))
@@ -51,34 +53,18 @@
#define COMPAT_USER_HZ 100
#define COMPAT_UTS_MACHINE "s390\0\0\0\0"
-typedef u32 compat_size_t;
-typedef s32 compat_ssize_t;
-typedef s32 compat_clock_t;
-typedef s32 compat_pid_t;
typedef u16 __compat_uid_t;
typedef u16 __compat_gid_t;
typedef u32 __compat_uid32_t;
typedef u32 __compat_gid32_t;
typedef u16 compat_mode_t;
-typedef u32 compat_ino_t;
typedef u16 compat_dev_t;
-typedef s32 compat_off_t;
-typedef s64 compat_loff_t;
typedef u16 compat_nlink_t;
typedef u16 compat_ipc_pid_t;
-typedef s32 compat_daddr_t;
typedef u32 compat_caddr_t;
typedef __kernel_fsid_t compat_fsid_t;
-typedef s32 compat_key_t;
-typedef s32 compat_timer_t;
-
-typedef s32 compat_int_t;
-typedef s32 compat_long_t;
typedef s64 compat_s64;
-typedef u32 compat_uint_t;
-typedef u32 compat_ulong_t;
typedef u64 compat_u64;
-typedef u32 compat_uptr_t;
typedef struct {
u32 mask;
diff --git a/arch/sparc/include/asm/compat.h b/arch/sparc/include/asm/compat.h
index 4eb51d2dae98..985286b79891 100644
--- a/arch/sparc/include/asm/compat.h
+++ b/arch/sparc/include/asm/compat.h
@@ -6,38 +6,23 @@
*/
#include <linux/types.h>
+#include <asm-generic/compat.h>
+
#define COMPAT_USER_HZ 100
#define COMPAT_UTS_MACHINE "sparc\0\0"
-typedef u32 compat_size_t;
-typedef s32 compat_ssize_t;
-typedef s32 compat_clock_t;
-typedef s32 compat_pid_t;
typedef u16 __compat_uid_t;
typedef u16 __compat_gid_t;
typedef u32 __compat_uid32_t;
typedef u32 __compat_gid32_t;
typedef u16 compat_mode_t;
-typedef u32 compat_ino_t;
typedef u16 compat_dev_t;
-typedef s32 compat_off_t;
-typedef s64 compat_loff_t;
typedef s16 compat_nlink_t;
typedef u16 compat_ipc_pid_t;
-typedef s32 compat_daddr_t;
typedef u32 compat_caddr_t;
typedef __kernel_fsid_t compat_fsid_t;
-typedef s32 compat_key_t;
-typedef s32 compat_timer_t;
-
-typedef s32 compat_int_t;
-typedef s32 compat_long_t;
typedef s64 compat_s64;
-typedef u32 compat_uint_t;
-typedef u32 compat_ulong_t;
typedef u64 compat_u64;
-typedef u32 compat_uptr_t;
-
struct compat_stat {
compat_dev_t st_dev;
compat_ino_t st_ino;
diff --git a/arch/x86/include/asm/compat.h b/arch/x86/include/asm/compat.h
index fb97cf7c4137..0ce6f452d334 100644
--- a/arch/x86/include/asm/compat.h
+++ b/arch/x86/include/asm/compat.h
@@ -12,38 +12,23 @@
#include <asm/user32.h>
#include <asm/unistd.h>
+#include <asm-generic/compat.h>
+
#define COMPAT_USER_HZ 100
#define COMPAT_UTS_MACHINE "i686\0\0"
-typedef u32 compat_size_t;
-typedef s32 compat_ssize_t;
-typedef s32 compat_clock_t;
-typedef s32 compat_pid_t;
typedef u16 __compat_uid_t;
typedef u16 __compat_gid_t;
typedef u32 __compat_uid32_t;
typedef u32 __compat_gid32_t;
typedef u16 compat_mode_t;
-typedef u32 compat_ino_t;
typedef u16 compat_dev_t;
-typedef s32 compat_off_t;
-typedef s64 compat_loff_t;
typedef u16 compat_nlink_t;
typedef u16 compat_ipc_pid_t;
-typedef s32 compat_daddr_t;
typedef u32 compat_caddr_t;
typedef __kernel_fsid_t compat_fsid_t;
-typedef s32 compat_timer_t;
-typedef s32 compat_key_t;
-
-typedef s32 compat_int_t;
-typedef s32 compat_long_t;
typedef s64 __attribute__((aligned(4))) compat_s64;
-typedef u32 compat_uint_t;
-typedef u32 compat_ulong_t;
-typedef u32 compat_u32;
typedef u64 __attribute__((aligned(4))) compat_u64;
-typedef u32 compat_uptr_t;
struct compat_stat {
compat_dev_t st_dev;
diff --git a/include/asm-generic/compat.h b/include/asm-generic/compat.h
index 28819451b6d1..a86f65bffab8 100644
--- a/include/asm-generic/compat.h
+++ b/include/asm-generic/compat.h
@@ -1,3 +1,25 @@
/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __ASM_GENERIC_COMPAT_H
+#define __ASM_GENERIC_COMPAT_H
-/* This is an empty stub for 32-bit-only architectures */
+/* These types are common across all compat ABIs */
+typedef u32 compat_size_t;
+typedef s32 compat_ssize_t;
+typedef s32 compat_clock_t;
+typedef s32 compat_pid_t;
+typedef u32 compat_ino_t;
+typedef s32 compat_off_t;
+typedef s64 compat_loff_t;
+typedef s32 compat_daddr_t;
+typedef s32 compat_timer_t;
+typedef s32 compat_key_t;
+typedef s16 compat_short_t;
+typedef s32 compat_int_t;
+typedef s32 compat_long_t;
+typedef u16 compat_ushort_t;
+typedef u32 compat_uint_t;
+typedef u32 compat_ulong_t;
+typedef u32 compat_uptr_t;
+typedef u32 compat_aio_context_t;
+
+#endif
diff --git a/include/linux/compat.h b/include/linux/compat.h
index cfc1b6383ae0..af5ac9de4bdf 100644
--- a/include/linux/compat.h
+++ b/include/linux/compat.h
@@ -104,8 +104,6 @@ typedef struct compat_sigaltstack {
typedef __compat_uid32_t compat_uid_t;
typedef __compat_gid32_t compat_gid_t;
-typedef compat_ulong_t compat_aio_context_t;
-
struct compat_sel_arg_struct;
struct rusage;
--
2.9.0
^ permalink raw reply related
* Re: [PATCH net-next 1/2] tcp: add TCP_ZEROCOPY_RECEIVE support for zerocopy receive
From: Matthew Wilcox @ 2018-04-25 16:04 UTC (permalink / raw)
To: Eric Dumazet
Cc: Christoph Hellwig, Eric Dumazet, David S . Miller, netdev,
Andy Lutomirski, linux-kernel, linux-mm, Soheil Hassas Yeganeh
In-Reply-To: <5cd31eba-63b5-9160-0a2e-f441340df0d3@gmail.com>
On Wed, Apr 25, 2018 at 06:01:02AM -0700, Eric Dumazet wrote:
> On 04/24/2018 11:28 PM, Christoph Hellwig wrote:
> > On Tue, Apr 24, 2018 at 10:27:21PM -0700, Eric Dumazet wrote:
> >> When adding tcp mmap() implementation, I forgot that socket lock
> >> had to be taken before current->mm->mmap_sem. syzbot eventually caught
> >> the bug.
> >>
> >> Since we can not lock the socket in tcp mmap() handler we have to
> >> split the operation in two phases.
> >>
> >> 1) mmap() on a tcp socket simply reserves VMA space, and nothing else.
> >> This operation does not involve any TCP locking.
> >>
> >> 2) setsockopt(fd, IPPROTO_TCP, TCP_ZEROCOPY_RECEIVE, ...) implements
> >> the transfert of pages from skbs to one VMA.
> >> This operation only uses down_read(¤t->mm->mmap_sem) after
> >> holding TCP lock, thus solving the lockdep issue.
> >>
> >> This new implementation was suggested by Andy Lutomirski with great details.
> >
> > Thanks, this looks much more sensible to me.
> >
>
> Thanks Christoph
>
> Note the high cost of zap_page_range(), needed to avoid -EBUSY being returned
> from vm_insert_page() the second time TCP_ZEROCOPY_RECEIVE is used on one VMA.
>
> Ideally a vm_replace_page() would avoid this cost ?
If you don't zap the page range, any of the CPUs in the system where
any thread in this task have ever run may have a TLB entry pointing to
this page ... if the page is being recycled into the page allocator,
then that page might end up as a slab page or page table or page cache
while the other CPU still have access to it.
You could hang onto the page until you've built up a sufficiently large
batch, then bulk-invalidate all of the TLB entries, but we start to get
into weirdnesses on different CPU architectures.
^ permalink raw reply
* [PATCH 00/17] y2038: system calls, part 3
From: Arnd Bergmann @ 2018-04-25 16:02 UTC (permalink / raw)
To: y2038, linux-kernel
Cc: Arnd Bergmann, linux-api, linux-arch, libc-alpha, tglx, netdev,
deepa.kernel, viro, albert.aribaud, Peter Zijlstra, Darren Hart,
Eric W. Biederman, Dominik Brodowski
After the first timekeeping series from Deepa (merged into -tip now)
and my follow-up for IPC system calls, this is a third set of system
call conversions following the same principle.
Most of the changes are straightforward, so I'm grouping them into a
larger series even though the system calls are mostly unrelated to one
another. After this series, the remaining calls that need to be changed
are getrusage()/waitid(), pselect6/ppoll(), timer{,fd}_{get,set}time()
and getitimer()/setitimer(). Those will be sent separately, once they
are matured enough.
To put the changes into perspective, a list of all system calls that
require changes is available in a spreadsheet[1] and I have made
another experimental patch that changes over x86[2] and arm[3] to
actually use them.
Please review!
Arnd
[1] https://docs.google.com/spreadsheets/d/1HCYwHXxs48TsTb6IGUduNjQnmfRvMPzCN6T_0YiQwis
[2] https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/commit/?h=y2038-next&id=2174e03cd47384f30dc522f173f36c0d72cfedd7
[3] https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/commit/?h=y2038-next&id=ba9a341eff2b13a8e25b5d42b3035b1c1dbfeacf
Arnd Bergmann (17):
y2038: compat: Move common compat types to asm-generic/compat.h
y2038: Remove newstat family from default syscall set
y2038: Remove stat64 family from default syscall set
asm-generic: Remove unneeded __ARCH_WANT_SYS_LLSEEK macro
asm-generic: Remove empty asm/unistd.h
y2038: Change sys_utimensat() to use __kernel_timespec
y2038: Compile utimes()/futimesat() conditionally
y2038: utimes: Rework #ifdef guards for compat syscalls
y2038: futex: Move compat implementation into futex.c
y2038: futex: Add support for __kernel_timespec
y2038: Prepare sched_rr_get_interval for __kernel_timespec
y2038: aio: Prepare sys_io_getevents for __kernel_timespec
y2038: socket: Convert recvmmsg to __kernel_timespec
y2038: socket: Add compat_sys_recvmmsg_time64
y2038: signal: Change rt_sigtimedwait to use __kernel_timespec
y2038: Make compat_sys_rt_sigtimedwait usable on 32-bit
y2038: signal: Add compat_sys_rt_sigtimedwait_time64
Cc: linux-api@vger.kernel.org
Cc: linux-arch@vger.kernel.org
Cc: libc-alpha@sourceware.org
Cc: tglx@linutronix.de
Cc: netdev@vger.kernel.org
Cc: deepa.kernel@gmail.com
Cc: viro@zeniv.linux.org.uk
Cc: albert.aribaud@3adev.fr
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Darren Hart <dvhart@infradead.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
arch/alpha/include/asm/unistd.h | 2 +
arch/arc/include/uapi/asm/unistd.h | 1 +
arch/arm/include/asm/unistd.h | 4 +-
arch/arm64/include/asm/compat.h | 20 +--
arch/arm64/include/asm/unistd.h | 2 +-
arch/arm64/include/uapi/asm/unistd.h | 1 +
arch/c6x/include/uapi/asm/unistd.h | 1 +
arch/h8300/include/uapi/asm/unistd.h | 1 +
arch/hexagon/include/uapi/asm/unistd.h | 1 +
arch/ia64/include/asm/unistd.h | 3 +
arch/m68k/include/asm/unistd.h | 2 +-
arch/microblaze/include/asm/unistd.h | 2 +-
arch/mips/include/asm/compat.h | 22 +---
arch/mips/include/asm/unistd.h | 3 +-
arch/nds32/include/uapi/asm/unistd.h | 1 +
arch/nios2/include/uapi/asm/unistd.h | 1 +
arch/openrisc/include/uapi/asm/unistd.h | 1 +
arch/parisc/include/asm/compat.h | 18 +--
arch/parisc/include/asm/unistd.h | 3 +-
arch/powerpc/include/asm/compat.h | 18 +--
arch/powerpc/include/asm/unistd.h | 3 +-
arch/s390/include/asm/compat.h | 18 +--
arch/s390/include/asm/unistd.h | 3 +-
arch/sh/include/asm/unistd.h | 2 +-
arch/sparc/include/asm/compat.h | 19 +--
arch/sparc/include/asm/unistd.h | 3 +-
arch/unicore32/include/uapi/asm/unistd.h | 1 +
arch/x86/include/asm/compat.h | 19 +--
arch/x86/include/asm/unistd.h | 3 +-
arch/xtensa/include/asm/unistd.h | 2 +-
fs/aio.c | 4 +-
fs/read_write.c | 2 +-
fs/stat.c | 3 +
fs/utimes.c | 59 +++++----
include/asm-generic/compat.h | 24 +++-
include/asm-generic/unistd.h | 13 --
include/linux/compat.h | 12 +-
include/linux/compat_time.h | 5 +
include/linux/futex.h | 8 --
include/linux/socket.h | 19 ++-
include/linux/syscalls.h | 23 ++--
include/uapi/asm-generic/unistd.h | 2 +
kernel/Makefile | 3 -
kernel/futex.c | 207 +++++++++++++++++++++++++++++--
kernel/futex_compat.c | 202 ------------------------------
kernel/sched/core.c | 4 +-
kernel/signal.c | 68 ++++++++--
kernel/sys_ni.c | 1 +
net/compat.c | 16 +--
net/socket.c | 55 ++++++--
50 files changed, 456 insertions(+), 454 deletions(-)
delete mode 100644 include/asm-generic/unistd.h
delete mode 100644 kernel/futex_compat.c
--
2.9.0
^ permalink raw reply
* [PATCH 16/17] y2038: Make compat_sys_rt_sigtimedwait usable on 32-bit
From: Arnd Bergmann @ 2018-04-25 16:03 UTC (permalink / raw)
To: y2038, linux-kernel
Cc: Arnd Bergmann, linux-api, linux-arch, libc-alpha, tglx, netdev,
deepa.kernel, viro, albert.aribaud, Peter Zijlstra, Darren Hart,
Eric W. Biederman, Dominik Brodowski
In-Reply-To: <20180425160311.2718314-1-arnd@arndb.de>
Once sys_rt_sigtimedwait() gets changed to a 64-bit time_t, we have
to provide compatibility support for existing binaries. Using the
compat_sys_rt_sigtimedwait() entry point is convenient because it allows
to share the implementation with 64-bit architectures.
Unfortunately, the get_compat_sigset() and copy_siginfo_to_user32()
functions are used in that function, but we can replace them with
trivial helpers that do the same thing as before.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
kernel/signal.c | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/kernel/signal.c b/kernel/signal.c
index d8d68a9556ae..72609c6835fd 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -3104,7 +3104,22 @@ int copy_siginfo_from_user32(struct siginfo *to,
}
return 0;
}
-#endif /* CONFIG_COMPAT */
+
+#else /* !CONFIG_COMPAT */
+
+/* 32-bit architectures only need to convert compat_time_t, not siginfo or sigset_t */
+
+#define compat_siginfo siginfo
+#define compat_sigset_t sigset_t
+#define copy_siginfo_to_user32 copy_siginfo_to_user
+static inline int get_compat_sigset(sigset_t *set, const sigset_t __user *compat)
+{
+ if (copy_from_user(set, compat, sizeof *set))
+ return -EFAULT;
+
+ return 0;
+}
+#endif /* !CONFIG_COMPAT */
/**
* do_sigtimedwait - wait for queued signals specified in @which
@@ -3202,7 +3217,7 @@ SYSCALL_DEFINE4(rt_sigtimedwait, const sigset_t __user *, uthese,
return ret;
}
-#ifdef CONFIG_COMPAT
+#ifdef CONFIG_COMPAT_32BIT_TIME
COMPAT_SYSCALL_DEFINE4(rt_sigtimedwait, compat_sigset_t __user *, uthese,
struct compat_siginfo __user *, uinfo,
struct compat_timespec __user *, uts, compat_size_t, sigsetsize)
--
2.9.0
^ permalink raw reply related
* [PATCH 15/17] y2038: signal: Change rt_sigtimedwait to use __kernel_timespec
From: Arnd Bergmann @ 2018-04-25 16:03 UTC (permalink / raw)
To: y2038, linux-kernel
Cc: Arnd Bergmann, linux-api, linux-arch, libc-alpha, tglx, netdev,
deepa.kernel, viro, albert.aribaud, Peter Zijlstra, Darren Hart,
Eric W. Biederman, Dominik Brodowski
In-Reply-To: <20180425160311.2718314-1-arnd@arndb.de>
This changes sys_rt_sigtimedwait() to use get_timespec64(), changing
the timeout type to __kernel_timespec, which will be changed to use
a 64-bit time_t in the future. Since the do_sigtimedwait() core
function changes, we also have to modify the compat version of this
system call in the same way.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
include/linux/syscalls.h | 2 +-
kernel/signal.c | 17 +++++++++--------
2 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
index eaa32317f573..a756ab42894f 100644
--- a/include/linux/syscalls.h
+++ b/include/linux/syscalls.h
@@ -622,7 +622,7 @@ asmlinkage long sys_rt_sigprocmask(int how, sigset_t __user *set,
asmlinkage long sys_rt_sigpending(sigset_t __user *set, size_t sigsetsize);
asmlinkage long sys_rt_sigtimedwait(const sigset_t __user *uthese,
siginfo_t __user *uinfo,
- const struct timespec __user *uts,
+ const struct __kernel_timespec __user *uts,
size_t sigsetsize);
asmlinkage long sys_rt_sigqueueinfo(pid_t pid, int sig, siginfo_t __user *uinfo);
diff --git a/kernel/signal.c b/kernel/signal.c
index d4ccea599692..d8d68a9556ae 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -3113,7 +3113,7 @@ int copy_siginfo_from_user32(struct siginfo *to,
* @ts: upper bound on process time suspension
*/
static int do_sigtimedwait(const sigset_t *which, siginfo_t *info,
- const struct timespec *ts)
+ const struct timespec64 *ts)
{
ktime_t *to = NULL, timeout = KTIME_MAX;
struct task_struct *tsk = current;
@@ -3121,9 +3121,9 @@ static int do_sigtimedwait(const sigset_t *which, siginfo_t *info,
int sig, ret = 0;
if (ts) {
- if (!timespec_valid(ts))
+ if (!timespec64_valid(ts))
return -EINVAL;
- timeout = timespec_to_ktime(*ts);
+ timeout = timespec64_to_ktime(*ts);
to = &timeout;
}
@@ -3171,11 +3171,12 @@ static int do_sigtimedwait(const sigset_t *which, siginfo_t *info,
* @sigsetsize: size of sigset_t type
*/
SYSCALL_DEFINE4(rt_sigtimedwait, const sigset_t __user *, uthese,
- siginfo_t __user *, uinfo, const struct timespec __user *, uts,
+ siginfo_t __user *, uinfo,
+ const struct __kernel_timespec __user *, uts,
size_t, sigsetsize)
{
sigset_t these;
- struct timespec ts;
+ struct timespec64 ts;
siginfo_t info;
int ret;
@@ -3187,7 +3188,7 @@ SYSCALL_DEFINE4(rt_sigtimedwait, const sigset_t __user *, uthese,
return -EFAULT;
if (uts) {
- if (copy_from_user(&ts, uts, sizeof(ts)))
+ if (get_timespec64(&ts, uts))
return -EFAULT;
}
@@ -3207,7 +3208,7 @@ COMPAT_SYSCALL_DEFINE4(rt_sigtimedwait, compat_sigset_t __user *, uthese,
struct compat_timespec __user *, uts, compat_size_t, sigsetsize)
{
sigset_t s;
- struct timespec t;
+ struct timespec64 t;
siginfo_t info;
long ret;
@@ -3218,7 +3219,7 @@ COMPAT_SYSCALL_DEFINE4(rt_sigtimedwait, compat_sigset_t __user *, uthese,
return -EFAULT;
if (uts) {
- if (compat_get_timespec(&t, uts))
+ if (compat_get_timespec64(&t, uts))
return -EFAULT;
}
--
2.9.0
^ permalink raw reply related
* [PATCH 14/17] y2038: socket: Add compat_sys_recvmmsg_time64
From: Arnd Bergmann @ 2018-04-25 16:03 UTC (permalink / raw)
To: y2038, linux-kernel
Cc: Arnd Bergmann, linux-api, linux-arch, libc-alpha, tglx, netdev,
deepa.kernel, viro, albert.aribaud, Peter Zijlstra, Darren Hart,
Eric W. Biederman, Dominik Brodowski
In-Reply-To: <20180425160311.2718314-1-arnd@arndb.de>
recvmmsg() takes two arguments to pointers of structures that differ
between 32-bit and 64-bit architectures: mmsghdr and timespec.
For y2038 compatbility, we are changing the native system call from
timespec to __kernel_timespec with a 64-bit time_t (in another patch),
and use the existing compat system call on both 32-bit and 64-bit
architectures for compatibility with traditional 32-bit user space.
As we now have two variants of recvmmsg() for 32-bit tasks that are both
different from the variant that we use on 64-bit tasks, this means we
also require two compat system calls!
The solution I picked is to flip things around: The existing
compat_sys_recvmmsg() call gets moved from net/compat.c into net/socket.c
and now handles the case for old user space on all architectures that
have set CONFIG_COMPAT_32BIT_TIME. A new compat_sys_recvmmsg_time64()
call gets added in the old place for 64-bit architectures only, this
one handles the case of a compat mmsghdr structure combined with
__kernel_timespec.
In the indirect sys_socketcall(), we now need to call either
do_sys_recvmmsg() or __compat_sys_recvmmsg(), depending on what kind of
architecture we are on. For compat_sys_socketcall(), no such change is
needed, we always call __compat_sys_recvmmsg().
I decided to not add a new SYS_RECVMMSG_TIME64 socketcall: Any libc
implementation for 64-bit time_t will need significant changes including
an updated asm/unistd.h, and it seems better to consistently use the
separate syscalls that configuration, leaving the socketcall only for
backward compatibility with 32-bit time_t based libc.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
include/linux/compat.h | 5 ++++-
include/linux/socket.h | 15 ++++++++++++++-
kernel/sys_ni.c | 1 +
net/compat.c | 14 +++++++-------
net/socket.c | 39 +++++++++++++++++++++++++++++++++++++--
5 files changed, 63 insertions(+), 11 deletions(-)
diff --git a/include/linux/compat.h b/include/linux/compat.h
index 7887b0a54c1e..f9423bbf7e7c 100644
--- a/include/linux/compat.h
+++ b/include/linux/compat.h
@@ -863,7 +863,10 @@ asmlinkage long compat_sys_move_pages(pid_t pid, compat_ulong_t nr_pages,
asmlinkage long compat_sys_rt_tgsigqueueinfo(compat_pid_t tgid,
compat_pid_t pid, int sig,
struct compat_siginfo __user *uinfo);
-asmlinkage long compat_sys_recvmmsg(int fd, struct compat_mmsghdr __user *mmsg,
+asmlinkage long compat_sys_recvmmsg_time64(int fd, struct compat_mmsghdr __user *mmsg,
+ unsigned vlen, unsigned int flags,
+ struct __kernel_timespec __user *timeout);
+asmlinkage long compat_sys_recvmmsg(int fd, struct mmsghdr __user *mmsg,
unsigned vlen, unsigned int flags,
struct compat_timespec __user *timeout);
asmlinkage long compat_sys_wait4(compat_pid_t pid,
diff --git a/include/linux/socket.h b/include/linux/socket.h
index d36a6c1bdbaf..22358e0e1288 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -2,8 +2,8 @@
#ifndef _LINUX_SOCKET_H
#define _LINUX_SOCKET_H
-
#include <asm/socket.h> /* arch-dependent defines */
+#include <linux/errno.h>
#include <linux/sockios.h> /* the SIOCxxx I/O controls */
#include <linux/uio.h> /* iovec support */
#include <linux/types.h> /* pid_t */
@@ -346,6 +346,7 @@ extern int move_addr_to_kernel(void __user *uaddr, int ulen, struct sockaddr_sto
extern int put_cmsg(struct msghdr*, int level, int type, int len, void *data);
struct timespec64;
+struct compat_timespec;
/* The __sys_...msg variants allow MSG_CMSG_COMPAT iff
* forbid_cmsg_compat==false
@@ -356,6 +357,18 @@ extern long __sys_sendmsg(int fd, struct user_msghdr __user *msg,
unsigned int flags, bool forbid_cmsg_compat);
extern int __sys_recvmmsg(int fd, struct mmsghdr __user *mmsg, unsigned int vlen,
unsigned int flags, struct timespec64 *timeout);
+#ifdef CONFIG_COMPAT_32BIT_TIME
+extern int __compat_sys_recvmmsg(int fd, struct mmsghdr __user *mmsg,
+ unsigned int vlen, unsigned int flags,
+ struct compat_timespec __user *timeout);
+#else
+static inline int __compat_sys_recvmmsg(int fd, struct mmsghdr __user *mmsg,
+ unsigned int vlen, unsigned int flags,
+ struct compat_timespec __user *timeout)
+{
+ return -EINVAL;
+}
+#endif
extern int __sys_sendmmsg(int fd, struct mmsghdr __user *mmsg,
unsigned int vlen, unsigned int flags,
bool forbid_cmsg_compat);
diff --git a/kernel/sys_ni.c b/kernel/sys_ni.c
index 9791364925dc..61fc9babe6ce 100644
--- a/kernel/sys_ni.c
+++ b/kernel/sys_ni.c
@@ -283,6 +283,7 @@ COND_SYSCALL(perf_event_open);
COND_SYSCALL(accept4);
COND_SYSCALL(recvmmsg);
COND_SYSCALL_COMPAT(recvmmsg);
+COND_SYSCALL_COMPAT(recvmmsg_time64);
/*
* Architecture specific syscalls: see further below
diff --git a/net/compat.c b/net/compat.c
index 93b80a3d967c..7521a0afe18d 100644
--- a/net/compat.c
+++ b/net/compat.c
@@ -810,9 +810,9 @@ COMPAT_SYSCALL_DEFINE6(recvfrom, int, fd, void __user *, buf, compat_size_t, len
return __compat_sys_recvfrom(fd, buf, len, flags, addr, addrlen);
}
-static int __compat_sys_recvmmsg(int fd, struct compat_mmsghdr __user *mmsg,
+static int __compat_sys_recvmmsg_time64(int fd, struct compat_mmsghdr __user *mmsg,
unsigned int vlen, unsigned int flags,
- struct compat_timespec __user *timeout)
+ struct __kernel_timespec __user *timeout)
{
int datagrams;
struct timespec64 ktspec;
@@ -821,22 +821,22 @@ static int __compat_sys_recvmmsg(int fd, struct compat_mmsghdr __user *mmsg,
return __sys_recvmmsg(fd, (struct mmsghdr __user *)mmsg, vlen,
flags | MSG_CMSG_COMPAT, NULL);
- if (compat_get_timespec64(&ktspec, timeout))
+ if (get_timespec64(&ktspec, timeout))
return -EFAULT;
datagrams = __sys_recvmmsg(fd, (struct mmsghdr __user *)mmsg, vlen,
flags | MSG_CMSG_COMPAT, &ktspec);
- if (datagrams > 0 && compat_put_timespec64(&ktspec, timeout))
+ if (datagrams > 0 && put_timespec64(&ktspec, timeout))
datagrams = -EFAULT;
return datagrams;
}
-COMPAT_SYSCALL_DEFINE5(recvmmsg, int, fd, struct compat_mmsghdr __user *, mmsg,
+COMPAT_SYSCALL_DEFINE5(recvmmsg_time64, int, fd, struct compat_mmsghdr __user *, mmsg,
unsigned int, vlen, unsigned int, flags,
- struct compat_timespec __user *, timeout)
+ struct __kernel_timespec __user *, timeout)
{
- return __compat_sys_recvmmsg(fd, mmsg, vlen, flags, timeout);
+ return __compat_sys_recvmmsg_time64(fd, mmsg, vlen, flags, timeout);
}
COMPAT_SYSCALL_DEFINE2(socketcall, int, call, u32 __user *, args)
diff --git a/net/socket.c b/net/socket.c
index 4510e6269764..5e97b645bfee 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -2483,6 +2483,37 @@ SYSCALL_DEFINE5(recvmmsg, int, fd, struct mmsghdr __user *, mmsg,
return do_sys_recvmmsg(fd, mmsg, vlen, flags, timeout);
}
+#ifdef CONFIG_COMPAT_32BIT_TIME
+int __compat_sys_recvmmsg(int fd, struct mmsghdr __user *mmsg,
+ unsigned int vlen, unsigned int flags,
+ struct compat_timespec __user *timeout)
+{
+ int datagrams;
+ struct timespec64 ktspec;
+
+ if (timeout == NULL)
+ return __sys_recvmmsg(fd, (struct mmsghdr __user *)mmsg, vlen,
+ flags | MSG_CMSG_COMPAT, NULL);
+
+ if (compat_get_timespec64(&ktspec, timeout))
+ return -EFAULT;
+
+ datagrams = __sys_recvmmsg(fd, (struct mmsghdr __user *)mmsg, vlen,
+ flags | MSG_CMSG_COMPAT, &ktspec);
+ if (datagrams > 0 && compat_put_timespec64(&ktspec, timeout))
+ datagrams = -EFAULT;
+
+ return datagrams;
+}
+
+COMPAT_SYSCALL_DEFINE5(recvmmsg, int, fd, struct mmsghdr __user *, mmsg,
+ unsigned int, vlen, unsigned int, flags,
+ struct compat_timespec __user *, timeout)
+{
+ return __compat_sys_recvmmsg(fd, mmsg, vlen, flags, timeout);
+}
+#endif
+
#ifdef __ARCH_WANT_SYS_SOCKETCALL
/* Argument list sizes for sys_socketcall */
#define AL(x) ((x) * sizeof(unsigned long))
@@ -2600,8 +2631,12 @@ SYSCALL_DEFINE2(socketcall, int, call, unsigned long __user *, args)
a[2], true);
break;
case SYS_RECVMMSG:
- err = do_sys_recvmmsg(a0, (struct mmsghdr __user *)a1, a[2],
- a[3], (struct __kernel_timespec __user *)a[4]);
+ if (IS_ENABLED(CONFIG_64BIT) || !IS_ENABLED(CONFIG_64BIT_TIME))
+ err = do_sys_recvmmsg(a0, (struct mmsghdr __user *)a1, a[2],
+ a[3], (struct __kernel_timespec __user *)a[4]);
+ else
+ err = __compat_sys_recvmmsg(a0, (struct mmsghdr __user *)a1, a[2],
+ a[3], (struct compat_timespec __user *)a[4]);
break;
case SYS_ACCEPT4:
err = __sys_accept4(a0, (struct sockaddr __user *)a1,
--
2.9.0
^ permalink raw reply related
* [PATCH 13/17] y2038: socket: Convert recvmmsg to __kernel_timespec
From: Arnd Bergmann @ 2018-04-25 16:03 UTC (permalink / raw)
To: y2038, linux-kernel
Cc: Arnd Bergmann, linux-api, linux-arch, libc-alpha, tglx, netdev,
deepa.kernel, viro, albert.aribaud, Peter Zijlstra, Darren Hart,
Eric W. Biederman, Dominik Brodowski
In-Reply-To: <20180425160311.2718314-1-arnd@arndb.de>
This converts the recvmmsg() system call in all its variations to use
'timespec64' internally for its timeout, and have a __kernel_timespec64
argument in the native entry point. This lets us change the type to use
64-bit time_t at a later point while using the 32-bit compat system call
emulation for existing user space.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
include/linux/socket.h | 4 ++--
include/linux/syscalls.h | 2 +-
net/compat.c | 6 +++---
net/socket.c | 18 ++++++++----------
4 files changed, 14 insertions(+), 16 deletions(-)
diff --git a/include/linux/socket.h b/include/linux/socket.h
index ea50f4a65816..d36a6c1bdbaf 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -345,7 +345,7 @@ struct ucred {
extern int move_addr_to_kernel(void __user *uaddr, int ulen, struct sockaddr_storage *kaddr);
extern int put_cmsg(struct msghdr*, int level, int type, int len, void *data);
-struct timespec;
+struct timespec64;
/* The __sys_...msg variants allow MSG_CMSG_COMPAT iff
* forbid_cmsg_compat==false
@@ -355,7 +355,7 @@ extern long __sys_recvmsg(int fd, struct user_msghdr __user *msg,
extern long __sys_sendmsg(int fd, struct user_msghdr __user *msg,
unsigned int flags, bool forbid_cmsg_compat);
extern int __sys_recvmmsg(int fd, struct mmsghdr __user *mmsg, unsigned int vlen,
- unsigned int flags, struct timespec *timeout);
+ unsigned int flags, struct timespec64 *timeout);
extern int __sys_sendmmsg(int fd, struct mmsghdr __user *mmsg,
unsigned int vlen, unsigned int flags,
bool forbid_cmsg_compat);
diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
index ffd8674e9df7..eaa32317f573 100644
--- a/include/linux/syscalls.h
+++ b/include/linux/syscalls.h
@@ -817,7 +817,7 @@ asmlinkage long sys_perf_event_open(
asmlinkage long sys_accept4(int, struct sockaddr __user *, int __user *, int);
asmlinkage long sys_recvmmsg(int fd, struct mmsghdr __user *msg,
unsigned int vlen, unsigned flags,
- struct timespec __user *timeout);
+ struct __kernel_timespec __user *timeout);
asmlinkage long sys_wait4(pid_t pid, int __user *stat_addr,
int options, struct rusage __user *ru);
diff --git a/net/compat.c b/net/compat.c
index 5ae7437d3853..93b80a3d967c 100644
--- a/net/compat.c
+++ b/net/compat.c
@@ -815,18 +815,18 @@ static int __compat_sys_recvmmsg(int fd, struct compat_mmsghdr __user *mmsg,
struct compat_timespec __user *timeout)
{
int datagrams;
- struct timespec ktspec;
+ struct timespec64 ktspec;
if (timeout == NULL)
return __sys_recvmmsg(fd, (struct mmsghdr __user *)mmsg, vlen,
flags | MSG_CMSG_COMPAT, NULL);
- if (compat_get_timespec(&ktspec, timeout))
+ if (compat_get_timespec64(&ktspec, timeout))
return -EFAULT;
datagrams = __sys_recvmmsg(fd, (struct mmsghdr __user *)mmsg, vlen,
flags | MSG_CMSG_COMPAT, &ktspec);
- if (datagrams > 0 && compat_put_timespec(&ktspec, timeout))
+ if (datagrams > 0 && compat_put_timespec64(&ktspec, timeout))
datagrams = -EFAULT;
return datagrams;
diff --git a/net/socket.c b/net/socket.c
index f10f1d947c78..4510e6269764 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -2343,7 +2343,7 @@ SYSCALL_DEFINE3(recvmsg, int, fd, struct user_msghdr __user *, msg,
*/
int __sys_recvmmsg(int fd, struct mmsghdr __user *mmsg, unsigned int vlen,
- unsigned int flags, struct timespec *timeout)
+ unsigned int flags, struct timespec64 *timeout)
{
int fput_needed, err, datagrams;
struct socket *sock;
@@ -2408,8 +2408,7 @@ int __sys_recvmmsg(int fd, struct mmsghdr __user *mmsg, unsigned int vlen,
if (timeout) {
ktime_get_ts64(&timeout64);
- *timeout = timespec64_to_timespec(
- timespec64_sub(end_time, timeout64));
+ *timeout = timespec64_sub(end_time, timeout64);
if (timeout->tv_sec < 0) {
timeout->tv_sec = timeout->tv_nsec = 0;
break;
@@ -2455,10 +2454,10 @@ int __sys_recvmmsg(int fd, struct mmsghdr __user *mmsg, unsigned int vlen,
static int do_sys_recvmmsg(int fd, struct mmsghdr __user *mmsg,
unsigned int vlen, unsigned int flags,
- struct timespec __user *timeout)
+ struct __kernel_timespec __user *timeout)
{
int datagrams;
- struct timespec timeout_sys;
+ struct timespec64 timeout_sys;
if (flags & MSG_CMSG_COMPAT)
return -EINVAL;
@@ -2466,13 +2465,12 @@ static int do_sys_recvmmsg(int fd, struct mmsghdr __user *mmsg,
if (!timeout)
return __sys_recvmmsg(fd, mmsg, vlen, flags, NULL);
- if (copy_from_user(&timeout_sys, timeout, sizeof(timeout_sys)))
+ if (get_timespec64(&timeout_sys, timeout))
return -EFAULT;
datagrams = __sys_recvmmsg(fd, mmsg, vlen, flags, &timeout_sys);
- if (datagrams > 0 &&
- copy_to_user(timeout, &timeout_sys, sizeof(timeout_sys)))
+ if (datagrams > 0 && put_timespec64(&timeout_sys, timeout))
datagrams = -EFAULT;
return datagrams;
@@ -2480,7 +2478,7 @@ static int do_sys_recvmmsg(int fd, struct mmsghdr __user *mmsg,
SYSCALL_DEFINE5(recvmmsg, int, fd, struct mmsghdr __user *, mmsg,
unsigned int, vlen, unsigned int, flags,
- struct timespec __user *, timeout)
+ struct __kernel_timespec __user *, timeout)
{
return do_sys_recvmmsg(fd, mmsg, vlen, flags, timeout);
}
@@ -2603,7 +2601,7 @@ SYSCALL_DEFINE2(socketcall, int, call, unsigned long __user *, args)
break;
case SYS_RECVMMSG:
err = do_sys_recvmmsg(a0, (struct mmsghdr __user *)a1, a[2],
- a[3], (struct timespec __user *)a[4]);
+ a[3], (struct __kernel_timespec __user *)a[4]);
break;
case SYS_ACCEPT4:
err = __sys_accept4(a0, (struct sockaddr __user *)a1,
--
2.9.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox