Asap2 direct 3.3 next #450

mishuang2017 · 2017-08-17T10:58:12Z

No description provided.

Allow the user to provide attribute flags when calling the switchdev same parent HW id helper. This patch doesn't add any new functionality. Issue: 974864 Change-Id: Ie16042078baea6ffbc7a68767659d017e64887bf Signed-off-by: Hadar Hen Zion <[email protected]> Reviewed-by: Or Gerlitz <[email protected]>

We use the switchdev parent HW id helper to identify if the mirred device shares the same ASIC with the ingress device. This can get us wrong in the presence of upper devices (e.g vlan, team, etc). To fail offload attempts in such cases, we move to do the parent id checks without recursion, using the SWITCHDEV_F_NO_RECURSE flag. Issue: 974864 Change-Id: I6f45e549f5a8abef13ff3b156a2e9d7cb12b2a9e Fixes: 03a9d11 ("net/mlx5e: Add TC drop and mirred/redirect action parsing for SRIOV offloads") Signed-off-by: Hadar Hen Zion <[email protected]> Reviewed-by: Or Gerlitz <[email protected]>

…tions When offloading header re-write, the HW may need to adjust checksums along the packet. For IP traffic, and a case where we are asked to modify fields in the IP header, current HW supports that only for TCP and UDP. Enforce it, in this case fail the offloading attempt for non TCP/UDP packets. issue: 1050641 Change-Id: Ia575dfd157bb965bcde03a79e1a95a633074bf38 Signed-off-by: Or Gerlitz <[email protected]>

The counter list hardware structure doesn't contain a clear and num_of_counters fields, remove them. These wrong fields were never used by the driver hence no other driver changes. Issue: 1070560 Change-Id: Ifbd657052eeb2bbc048ea9611aa5a0ff1564d7c2 Fixes: a351a1b ("net/mlx5: Introduce bulk reading of flow counters") Signed-off-by: Rabie Loulou <[email protected]> Reviewed-by: Or Gerlitz <[email protected]>

Read new NIC capability field which represnts 16 MSBs of the max flow counters number supported (max_flow_counter_31_16). Backward compatibility with older firmware is preserved, the modified driver reads max_flow_counter_31_16 as 0 from the older firmware and uses up to 64K counters. Changed flow counter id from 16 bits to 32 bits. Backward compatibility with older firmware is preserved as we kept the 16 LSBs of the counter id in place and added 16 MSBs from reserved field. Changed the background bulk reading of flow counters to work in chunks of at most 32K counters, to make sure we don't attempt to allocate very large buffers. Changed mlx5_cmd_fc_bulk_alloc function to use vzalloc instead of kzalloc. Changed mlx5_cmd_fc_bulk_free function to use kvfree instead of kfree. Issue: 1070560 Change-Id: I9ffc8a09a6b76b5362697aacfa5943dbfb011ec1 Signed-off-by: Rabie Loulou <[email protected]> Reviewed-by: Or Gerlitz <[email protected]>

The NIC TC offload table size was hard coded to 1k. Change it to be min(max NIC RX table size, min(max flow counters, 64k) * num flow groups) where the max values are read from the firmware and the number of flow groups is hard-coded as before this change. We don't know upfront the division of flows to groups (== different masks). This setup allows each group to be of size up to the where we want to go (when supported, all offloaded flows use counters). Thus, we don't expect multiple occurences for a group which in turn would add steering hops. issue: 900706 Change-Id: I137e6cb41637ba9b3208a6683712541d69ca0fa4 Signed-off-by: Or Gerlitz <[email protected]>

KernelPRBot · 2017-08-17T11:00:08Z

Hi @mishuang2017!

Thanks for your contribution to the Linux kernel!

Linux kernel development happens on mailing lists, rather than on GitHub - this GitHub repository is a read-only mirror that isn't used for accepting contributions. So that your change can become part of Linux, please email it to us as a patch.

Sending patches isn't quite as simple as sending a pull request, but fortunately it is a well documented process.

Here's what to do:

Format your contribution according to kernel requirements
Decide who to send your contribution to
Set up your system to send your contribution as an email
Send your contribution and wait for feedback

How do I format my contribution?

The Linux kernel community is notoriously picky about how contributions are formatted and sent. Fortunately, they have documented their expectations.

Firstly, all contributions need to be formatted as patches. A patch is a plain text document showing the change you want to make to the code, and documenting why it is a good idea.

You can create patches with git format-patch.

Secondly, patches need 'commit messages', which is the human-friendly documentation explaining what the change is and why it's necessary.

Thirdly, changes have some technical requirements. There is a Linux kernel coding style, and there are licensing requirements you need to comply with.

Both of these are documented in the Submitting Patches documentation that is part of the kernel.

Note that you will almost certainly have to modify your existing git commits to satisfy these requirements. Don't worry: there are many guides on the internet for doing this.

Who do I send my contribution to?

The Linux kernel is composed of a number of subsystems. These subsystems are maintained by different people, and have different mailing lists where they discuss proposed changes.

If you don't already know what subsystem your change belongs to, the get_maintainer.pl script in the kernel source can help you.

get_maintainer.pl will take the patch or patches you created in the previous step, and tell you who is responsible for them, and what mailing lists are used. You can also take a look at the MAINTAINERS file by hand.

Make sure that your list of recipients includes a mailing list. If you can't find a more specific mailing list, then LKML - the Linux Kernel Mailing List - is the place to send your patches.

It's not usually necessary to subscribe to the mailing list before you send the patches, but if you're interested in kernel development, subscribing to a subsystem mailing list is a good idea. (At this point, you probably don't need to subscribe to LKML - it is a very high traffic list with about a thousand messages per day, which is often not useful for beginners.)

How do I send my contribution?

Use git send-email, which will ensure that your patches are formatted in the standard manner. In order to use git send-email, you'll need to configure git to use your SMTP email server.

For more information about using git send-email, look at the Git documentation or type git help send-email. There are a number of useful guides and tutorials about git send-email that can be found on the internet.

How do I get help if I'm stuck?

Firstly, don't get discouraged! There are an enormous number of resources on the internet, and many kernel developers who would like to see you succeed.

Many issues - especially about how to use certain tools - can be resolved by using your favourite internet search engine.

If you can't find an answer, there are a few places you can turn:

Kernel Newbies - this website contains a lot of useful resources for new kernel developers.
If you'd like a step-by-step, challenge-based introduction to kernel development, the Eudyptula Challenge would be an excellent start.
The kernel documentation - see also the Documentation directory in the kernel tree.

If you get really, really stuck, you could try the owners of this bot, @daxtens and @ajdlinux. Please be aware that we do have full-time jobs, so we are almost certainly the slowest way to get answers!

I sent my patch - now what?

You wait.

You can check that your email has been received by checking the mailing list archives for the mailing list you sent your patch to. Messages may not be received instantly, so be patient. Kernel developers are generally very busy people, so it may take a few weeks before your patch is looked at.

Then, you keep waiting. Three things may happen:

You might get a response to your email. Often these will be comments, which may require you to make changes to your patch, or explain why your way is the best way. You should respond to these comments, and you may need to submit another revision of your patch to address the issues raised.
Your patch might be merged into the subsystem tree. Code that becomes part of Linux isn't merged into the main repository straight away - it first goes into the subsystem tree, which is managed by the subsystem maintainer. It is then batched up with a number of other changes sent to Linus for inclusion. (This process is described in some detail in the kernel development process guide).
Your patch might be ignored completely. This happens sometimes - don't take it personally. Here's what to do:
- Wait a bit more - patches often take several weeks to get a response; more if they were sent at a busy time.
- Kernel developers often silently ignore patches that break the rules. Check for obvious violations of the the Submitting Patches guidelines, the style guidelines, and any other documentation you can find about your subsystem. Check that you're sending your patch to the right place.
- Try again later. When you resend it, don't add angry commentary, as that will get your patch ignored. It might also get you silently blacklisted.

Further information

Working with the kernel development community - the official documentation for new kernel contributors

Happy hacking!

This message was posted by a bot - if you have any questions or suggestions, please talk to my owners, @ajdlinux and @daxtens, or raise an issue at https://github.com/ajdlinux/KernelPRBot.

When allocating a flow table entry, we need to allocate a free index in the flow group. Currently, this is done by traversing the existing flow table entries in the flow group, until a free index is found. Replacing this by using a ida, which allows us to find a free index much faster. issue: 1055697 Change-Id: Ie0ce533c435de89105c7a465c0a240a070b5a766 Signed-off-by: Matan Barak <[email protected]> Reviewed-by: Maor Gottlieb <[email protected]>

The current code stores fte_match_param in the software representation of FTEs and FGs. fte_match_param contains a large reserved area at the bottom of the struct. Since downstream patches are going to hash this part, we would like to avoid doing so on a reserved part. issue: 1055697 Change-Id: Id6cee97302b7ed665067037b033589acad4b1cae Signed-off-by: Matan Barak <[email protected]>

When adding a flow table entry (fte) to a flow group (fg), we first need to check whether this fte exist. In such a case we just merge the destinations (if possible). Currently, this is done by traversing the fte list available in a fg. This could take a lot of time when using large flow groups. Speeding this up by using rhashtable, which is much faster. issue: 1055697 Change-Id: Ibe19bb72c7d48cc8377a83b4e0e783881e141a13 Signed-off-by: Matan Barak <[email protected]> Reviewed-by: Maor Gottlieb <[email protected]>

When adding a flow table entry (fte) to a flow table (ft), we first need to find its flow group (fg). Currently, this is done by traversing a linear list of all flow groups in the flow table. Furthermore, since multiple flow groups which correspond to the same fte mask may exist in the same ft, we can't just stop at the first match. Converting the linear list to rhltable in order to speed things up. The last four patches increases the steering rules update rate by a factor of more than 7 (for insertion of 50K steering rules). issue: 1055697 Change-Id: I169e5a6bfb13befd64f21e139139934eab740584 Signed-off-by: Matan Barak <[email protected]> Reviewed-by: Maor Gottlieb <[email protected]>

Add a tracepoint infrastructure for mlx5_core driver. Implemented flow steering tracepoints: 1. Add flow group 2. Remove flow group 3. Add flow table entry 4. Remove flow table entry 5. Add flow table rule 6. Remove flow table rule issue: 1055697 Change-Id: I0f25e1ec9df085a3252b907078d5a59fc8f49c8a Signed-off-by: Matan Barak <[email protected]> Reviewed-by: Mark Bloch <[email protected]>

Currently, when a flow steering rule is added, we look for a FTE with an identical value. If we find a match, we try to merge the required destinations with the existing ones. In a case where the existing destination list is full, the code should return an error to its consumer. However, the current code just tries to create another FTE. Fixing that by returning an error in this special scenario. Fixes: f478be7 ("net/mlx5: Add hash table for flow groups in flow table") issue: 1115444 Change-Id: Iee0b3bc494aa877c528dbb631bea22e7e8c32763

Do not create flow table entry in hardware if encap exists but is not valid. This may happen when encap was removed from hardware due to neighbour state change. Similar case when new encap is created on neighbour that is not in valid state is handled by returning EAGAIN to upper layer. When EAGAIN is returned, flow table entry provision to hardware is performed by mlx5e_rep_neigh_update when neighbour becomes connected. Issue: 1048140 Change-Id: I15ca50c94b8d3e7fc7dd6654f58ad072ce707a5a Fixes: 232c001 ("net/mlx5e: Add support to neighbour update flow") Signed-off-by: Vlad Buslov <[email protected]> Reviewed-by: Roi Dayan <[email protected]>

When cleaning rdma netdevice we need to save the mdev pointer because priv is released when we release netdev. Found by KASAN: use-after-free in mlx5_rdma_netdev_free+0xe3/0x100 [mlx5_core] Issue: 1121098 Fixes: 48935bb ("net/mlx5e: IPoIB, Add netdevice profile skeleton") Change-Id: Ibc253182650f95589e76b4e08aa6da19f60236d8 Signed-off-by: Roi Dayan <[email protected]>

…ress Currently if vxlan tunnel ipv6 src isn't supplied the driver fails to resolve it as part of the route lookup. The resulting encap header is left with a zeroed out ipv6 src address so the packets are sent with this src ip. Use an appropriate route lookup API that also resolves the source ipv6 address if it's not supplied. Issue: 1092855 Change-Id: Iad49a00461e9f1cb8804112a012c74dc006b7dfd Fixes: ce99f6b ('net/mlx5e: Support SRIOV TC encapsulation offloads for IPv6 tunnels') Signed-off-by: Paul Blakey <[email protected]>

This fixes a bug in which changing mode to legacy while handling VXLAN traffic causes a NULL derefrence. When switching from switchdev to legacy all the port devices (nic and reps) are cleaned up. Part of this cleaning process is removing the neigh entry and the hash table containing them. however, a representor neigh entry might be linked to the nic hash table and if the nic is cleaned first the cleaning of the representor will end up in null deref. Fix that by unloading the representors in the opposite order of load. Issue: 1063609 Change-Id: I609697cc684574413ad23d53cae75ea28cef9dc5 Fixes: cb67b83 ("net/mlx5e: Introduce SRIOV VF representors") Signed-off-by: Shahar Klein <[email protected]> Reviewed-by: Roi Dayan <[email protected]>

The following new APIs are added: int idr_alloc_ext(struct idr *idr, void *ptr, unsigned long *index, unsigned long start, unsigned long end, gfp_t gfp); static inline void *idr_remove_ext(struct idr *idr, unsigned long id); static inline void *idr_find_ext(const struct idr *idr, unsigned long id); void *idr_replace_ext(struct idr *idr, void *ptr, unsigned long id); void *idr_get_next_ext(struct idr *idr, unsigned long *nextid); Signed-off-by: Chris Mi <[email protected]> Signed-off-by: Jiri Pirko <[email protected]>

Currently, all filters with the same priority are linked in a doubly linked list. Every filter should have a unique handle. To make the handle unique, we need to iterate the list every time to see if the handle exists or not when inserting a new filter. It is time-consuming. For example, it takes about 5m3.169s to insert 64K rules. This patch changes cls_flower to use IDR. With this patch, it takes about 0m1.127s to insert 64K rules. The improvement is huge. But please note that in this testing, all filters share the same action. If every filter has a unique action, that is another bottleneck. Follow-up patch in this patchset addresses that. Signed-off-by: Chris Mi <[email protected]> Signed-off-by: Jiri Pirko <[email protected]>

Typically, each TC filter has its own action. All the actions of the same type are saved in its hash table. But the hash buckets are too small that it degrades to a list. And the performance is greatly affected. For example, it takes about 0m11.914s to insert 64K rules. If we convert the hash table to IDR, it only takes about 0m1.500s. The improvement is huge. But please note that the test result is based on previous patch that cls_flower uses IDR. Signed-off-by: Chris Mi <[email protected]> Signed-off-by: Jiri Pirko <[email protected]>

Signed-off-by: Chris Mi <[email protected]>

When destroying filters, actions should be destroyed first. The pointers of each action are saved in an array. TC doesn't use the array directly, but put all actions in a doubly linked list and use the list as the parameter. There is no problem if each filter has its own actions. But if some filters share the same action, when these filters are destroyed, RCU callback fl_destroy_filter() may be called at the same time. That means the same action's 'struct list_head list' could be manipulated at the same time. It may point to some illegal address so that system will panic. So this patch uses the action array directly. And we add a new parameter to tell how many actions we have. After testing, this patch fixes this issue. Signed-off-by: Chris Mi <[email protected]>

In case the neighbour for the encap header isn't valid we send off a neighbour update request but we free the encap header buffer. We still need it for as base for allocating an encap header onces neighbour is available. Fix that by skipping freeing it if we wait for neighbour. Issue: 1120257 Change-Id: I8c266cc7f5293670fb1a35e8e072fded2397737a Fixes: 232c001 ('net/mlx5e: Add support to neighbour update flow') Signed-off-by: Paul Blakey <[email protected]>

Fixes: c15ab23 ("net/sched: Change cls_flower to use IDR") Cc: Chris Mi <[email protected]> Cc: Jiri Pirko <[email protected]> Signed-off-by: Cong Wang <[email protected]> Acked-by: Jiri Pirko <[email protected]> Signed-off-by: David S. Miller <[email protected]>

Since mlx5e_tc_add_fdb_flow() didn't attach encap, it shouldn't release it on error. Before this commit mlx5e_tc_add_fdb_flow(), on error it detached and released encap though a caller is going the list that was freed. The second release is when actually cleaning the flow. Move the release on error to the caller that actually attached the encap. Issue: 1147629 Fixes: aa0cbba ("net/mlx5e: Properly deal with resource cleanup when adding TC flow fails") Change-Id: I5f380ea04834974c6eeb563e9beaf627084631ee Signed-off-by: Roi Dayan <[email protected]>

Add hairpin definitions to the IFC file. issue: 1068457 Change-Id: I3fc9dba9ad80a263b00c38f36672284d83094f3e Signed-off-by: Or Gerlitz <[email protected]>

Low level code to setup hairpin contexts (SQ, RQ, TIR) Deal with: - Create RQ/SQ - Modify RQ/SQ (rst2rdy and rdy2rst) - Destroy RQ/SQ - Create TIR - Destroy TIR issue: 1068457 Change-Id: I7112408a5b71b58be7a4ea024ad06e187f8a6564 Signed-off-by: Or Gerlitz <[email protected]>

Hairpin is TC **NIC** rule that involves forwarding. All hairpin rules from the current NIC device (called "func" in the code) to a given peer are set on the same hairpin RQ/SQ pair. The hairpin RQ/SQ pair is set on demand and removed when there are no TC rules that need it. When we set the func --> peer pair we immediately set also the peer --> func pair. We delete both when there's no demand for either of them (note add/del are under rtnl). TC rule that matches on ICMP, does header re-write of the dst mac and hairpin from RX of P1 to TX on P2 (P1 and P2 are two VF devices in this example): tc filter add dev enp1s2f1 protocol ip parent ffff: prio 2 flower skip_sw ip_proto icmp action pedit ex munge eth dst set 10:22:33:44:55:66 pipe action mirred egress redirect dev enp1s2f2 issue: 1068457 Change-Id: I1ea222342c3189c27cdc0c0158828a870d5e558a Signed-off-by: Or Gerlitz <[email protected]>

nonthasuk

aha

This reverts commit f031786.

Currently, the encap action offload is handled in the actions parse function and not in mlx5e_tc_add_fdb_flow() where we deal with all the other aspects of offloading actions (vlan, modify header) and the rule itself. When the neigh update code (mlx5e_tc_encap_flows_add()) recreates the encap entry and offloads the related flows, we wrongly call again into mlx5e_tc_add_fdb_flow(), this for itself would cause us to handle again the offloading of vlans and header re-write which puts things in non consistent state and step on freed memory (e.g the modify header parse buffer which is already freed). Since on error, mlx5e_tc_add_fdb_flow() detaches and may release the encap entry, it causes a corruption at the neigh update code which goes over the list of flows associated with this encap entry, or double free when the tc flow is later deleted by user-space. When neigh update (mlx5e_tc_encap_flows_del()) unoffloads the flows related to an encap entry which is now invalid, we do a partial repeat of the eswitch flow removal code which is wrong too. To fix things up we do the following: (1) handle the encap action offload in the eswitch flow add function mlx5e_tc_add_fdb_flow() as done for the other actions and the rule itself. (2) modify the neigh update code (mlx5e_tc_encap_flows_add/del) to only deal with the encap entry and rules delete/add and not with any of the other offloaded actions. Fixes: 232c001 ('net/mlx5e: Add support to neighbour update flow') Signed-off-by: Or Gerlitz <[email protected]> Reviewed-by: Paul Blakey <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>

The new TC IDR code uses GFP_KERNEL under spin lock. Which leads to: [ 582.621091] BUG: sleeping function called from invalid context at ../mm/slab.h:416 [ 582.629721] in_atomic(): 1, irqs_disabled(): 0, pid: 3379, name: tc [ 582.636939] 2 locks held by tc/3379: [ 582.641049] #0: (rtnl_mutex){+.+.+.}, at: [<ffffffff910354ce>] rtnetlink_rcv_msg+0x92e/0x1400 [ 582.650958] #1: (&(&tn->idrinfo->lock)->rlock){+.-.+.}, at: [<ffffffff9110a5e0>] tcf_idr_create+0x2f0/0x8e0 [ 582.662217] Preemption disabled at: [ 582.662222] [<ffffffff9110a5e0>] tcf_idr_create+0x2f0/0x8e0 [ 582.672592] CPU: 9 PID: 3379 Comm: tc Tainted: G W 4.13.0-rc7-debug-00648-g43503a79b9f0 torvalds#287 [ 582.683432] Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.3.4 11/08/2016 [ 582.691937] Call Trace: ... [ 582.742460] kmem_cache_alloc+0x286/0x540 [ 582.747055] radix_tree_node_alloc.constprop.6+0x4a/0x450 [ 582.753209] idr_get_free_cmn+0x627/0xf80 ... [ 582.815525] idr_alloc_cmn+0x1a8/0x270 ... [ 582.833804] tcf_idr_create+0x31b/0x8e0 ... Try to preallocate the memory with idr_prealloc(GFP_KERNEL) (as suggested by Eric Dumazet), and change the allocation flags under spin lock. Change-Id: I2667c6883ffe1c8ceb7fd44ce7afe481bdb56ca4 Fixes: 65a206c ("net/sched: Change act_api and act_xxx modules to use IDR") Signed-off-by: Jakub Kicinski <[email protected]> Reviewed-by: Simon Horman <[email protected]> Acked-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>

Brought the offload attribute set of the representors to be more similar to that of the regular NIC netdevs, in order to increase the representor's performance. The impact of this change can be seen in the following measurements: Baseline VF/VM: TCP Throughput [Gb/s] UDP Received PPS (Drop %) VF to VM 29.1 571K (0%) VM to VF 16.4 623K (27%) Representor/VM before current changes: TCP Throughput [Gb/s] UDP Received PPS (Drop %) Representor to VM 4.4 450K (0%) VM to Representor 0.6 232K (75%) Representor/VM after current changes: TCP Throughput [Gb/s] UDP Received PPS (Drop %) Representor to VM 40.8 462K (0%) VM to Representor 0.6 248K (74%) Issue: 1155559 Change-Id: I07ebdc98b1593ae4fd1719e3af383a9a9dbd6112 Signed-off-by: Gavi Teitz <[email protected]>

Set the representor's rq params using the same method the standard nic netdev uses to set its rq params. This allowed the representor to use a striding rq if it is supported, and allowed for increasing the size of the representor's rq if it is not. This increases the representor's receive performance, as can be seen in the following measruements: Baseline VF/VM: TCP Throughput [Gb/s] UDP Received PPS (Drop %) VF to VM 29.1 571K (0%) VM to VF 16.4 623K (27%) Representor/VM before current changes: TCP Throughput [Gb/s] UDP Received PPS (Drop %) Representor to VM 40.8 462K (0%) VM to Representor 0.6 248K (74%) Representor/VM after current changes: TCP Throughput [Gb/s] UDP Received PPS (Drop %) Representor to VM 40.6 476K (0%) VM to Representor 20.2 620K (74%) Issue: 1155559 Change-Id: I6cd96f24d1c93da4dd2b8d80ce0ae4ab19028d2a Signed-off-by: Gavi Teitz <[email protected]>

This reverts commit 27b3360.

Increased the RQ size of the representors, to match that of a standard mlx5 NIC netdev, which increased the performance of the represntor's receive rate by about 50x. Issue: 1155559 Change-Id: I6cd96f24d1c93da4dd2b8d80ce0ae4ab19028d2a Signed-off-by: Gavi Teitz <[email protected]>

The following warning pops up with enabled UBSAN in tests fstests/generic/303: [23127.529395] UBSAN: Undefined behaviour in fs/read_write.c:1725:7 [23127.529400] signed integer overflow: [23127.529403] 4611686018427322368 + 9223372036854775807 cannot be represented in type 'long long int' [23127.529412] CPU: 4 PID: 26180 Comm: xfs_io Not tainted 5.2.0-rc2-1.ge195904-vanilla+ torvalds#450 [23127.556999] Hardware name: empty empty/S3993, BIOS PAQEX0-3 02/24/2008 [23127.557001] Call Trace: [23127.557060] dump_stack+0x67/0x9b [23127.557070] ubsan_epilogue+0x9/0x40 [23127.573496] handle_overflow+0xb3/0xc0 [23127.573514] do_clone_file_range+0x28f/0x2a0 [23127.573547] vfs_clone_file_range+0x35/0xb0 [23127.573564] ioctl_file_clone+0x8d/0xc0 [23127.590144] do_vfs_ioctl+0x300/0x700 [23127.590160] ksys_ioctl+0x70/0x80 [23127.590203] ? trace_hardirqs_off_thunk+0x1a/0x1c [23127.590210] __x64_sys_ioctl+0x16/0x20 [23127.590215] do_syscall_64+0x5c/0x1d0 [23127.590224] entry_SYSCALL_64_after_hwframe+0x49/0xbe [23127.590231] RIP: 0033:0x7ff6d7250327 [23127.590241] RSP: 002b:00007ffe3a38f1d8 EFLAGS: 00000206 ORIG_RAX: 0000000000000010 [23127.590246] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007ff6d7250327 [23127.590249] RDX: 00007ffe3a38f220 RSI: 000000004020940d RDI: 0000000000000003 [23127.590252] RBP: 0000000000000000 R08: 00007ffe3a3c80a0 R09: 00007ffe3a3c8080 [23127.590255] R10: 000000000fa99fa0 R11: 0000000000000206 R12: 0000000000000000 [23127.590260] R13: 0000000000000000 R14: 3fffffffffff0000 R15: 00007ff6d750a20c As loff_t is a signed type, we should use the safe overflow checks instead of relying on compiler implementation. The bogus values are intentional and the test is supposed to verify the boundary conditions. Signed-off-by: David Sterba <[email protected]>

rcu_read_lock is needed to protect access to psock inside sock_map_unref when tearing down the map. However, we can't afford to sleep in lock_sock while in RCU read-side critical section. Grab the RCU lock only after we have locked the socket. This fixes RCU warnings triggerable on a VM with 1 vCPU when free'ing a sockmap/sockhash that contains at least one socket: | ============================= | WARNING: suspicious RCU usage | 5.5.0-04005-g8fc91b972b73 torvalds#450 Not tainted | ----------------------------- | include/linux/rcupdate.h:272 Illegal context switch in RCU read-side critical section! | | other info that might help us debug this: | | | rcu_scheduler_active = 2, debug_locks = 1 | 4 locks held by kworker/0:1/62: | #0: ffff88813b019748 ((wq_completion)events){+.+.}, at: process_one_work+0x1d7/0x5e0 | #1: ffffc900000abe50 ((work_completion)(&map->work)){+.+.}, at: process_one_work+0x1d7/0x5e0 | #2: ffffffff82065d20 (rcu_read_lock){....}, at: sock_map_free+0x5/0x170 | #3: ffff8881368c5df8 (&stab->lock){+...}, at: sock_map_free+0x64/0x170 | | stack backtrace: | CPU: 0 PID: 62 Comm: kworker/0:1 Not tainted 5.5.0-04005-g8fc91b972b73 torvalds#450 | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 | Workqueue: events bpf_map_free_deferred | Call Trace: | dump_stack+0x71/0xa0 | ___might_sleep+0x105/0x190 | lock_sock_nested+0x28/0x90 | sock_map_free+0x95/0x170 | bpf_map_free_deferred+0x58/0x80 | process_one_work+0x260/0x5e0 | worker_thread+0x4d/0x3e0 | kthread+0x108/0x140 | ? process_one_work+0x5e0/0x5e0 | ? kthread_park+0x90/0x90 | ret_from_fork+0x3a/0x50 | ============================= | WARNING: suspicious RCU usage | 5.5.0-04005-g8fc91b972b73-dirty torvalds#452 Not tainted | ----------------------------- | include/linux/rcupdate.h:272 Illegal context switch in RCU read-side critical section! | | other info that might help us debug this: | | | rcu_scheduler_active = 2, debug_locks = 1 | 4 locks held by kworker/0:1/62: | #0: ffff88813b019748 ((wq_completion)events){+.+.}, at: process_one_work+0x1d7/0x5e0 | #1: ffffc900000abe50 ((work_completion)(&map->work)){+.+.}, at: process_one_work+0x1d7/0x5e0 | #2: ffffffff82065d20 (rcu_read_lock){....}, at: sock_hash_free+0x5/0x1d0 | #3: ffff888139966e00 (&htab->buckets[i].lock){+...}, at: sock_hash_free+0x92/0x1d0 | | stack backtrace: | CPU: 0 PID: 62 Comm: kworker/0:1 Not tainted 5.5.0-04005-g8fc91b972b73-dirty torvalds#452 | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 | Workqueue: events bpf_map_free_deferred | Call Trace: | dump_stack+0x71/0xa0 | ___might_sleep+0x105/0x190 | lock_sock_nested+0x28/0x90 | sock_hash_free+0xec/0x1d0 | bpf_map_free_deferred+0x58/0x80 | process_one_work+0x260/0x5e0 | worker_thread+0x4d/0x3e0 | kthread+0x108/0x140 | ? process_one_work+0x5e0/0x5e0 | ? kthread_park+0x90/0x90 | ret_from_fork+0x3a/0x50 Fixes: 7e81a35 ("bpf: Sockmap, ensure sock lock held during tear down") Signed-off-by: Jakub Sitnicki <[email protected]>

rcu_read_lock is needed to protect access to psock inside sock_map_unref when tearing down the map. However, we can't afford to sleep in lock_sock while in RCU read-side critical section. Grab the RCU lock only after we have locked the socket. This fixes RCU warnings triggerable on a VM with 1 vCPU when free'ing a sockmap/sockhash that contains at least one socket: | ============================= | WARNING: suspicious RCU usage | 5.5.0-04005-g8fc91b972b73 #450 Not tainted | ----------------------------- | include/linux/rcupdate.h:272 Illegal context switch in RCU read-side critical section! | | other info that might help us debug this: | | | rcu_scheduler_active = 2, debug_locks = 1 | 4 locks held by kworker/0:1/62: | #0: ffff88813b019748 ((wq_completion)events){+.+.}, at: process_one_work+0x1d7/0x5e0 | #1: ffffc900000abe50 ((work_completion)(&map->work)){+.+.}, at: process_one_work+0x1d7/0x5e0 | #2: ffffffff82065d20 (rcu_read_lock){....}, at: sock_map_free+0x5/0x170 | #3: ffff8881368c5df8 (&stab->lock){+...}, at: sock_map_free+0x64/0x170 | | stack backtrace: | CPU: 0 PID: 62 Comm: kworker/0:1 Not tainted 5.5.0-04005-g8fc91b972b73 #450 | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 | Workqueue: events bpf_map_free_deferred | Call Trace: | dump_stack+0x71/0xa0 | ___might_sleep+0x105/0x190 | lock_sock_nested+0x28/0x90 | sock_map_free+0x95/0x170 | bpf_map_free_deferred+0x58/0x80 | process_one_work+0x260/0x5e0 | worker_thread+0x4d/0x3e0 | kthread+0x108/0x140 | ? process_one_work+0x5e0/0x5e0 | ? kthread_park+0x90/0x90 | ret_from_fork+0x3a/0x50 | ============================= | WARNING: suspicious RCU usage | 5.5.0-04005-g8fc91b972b73-dirty #452 Not tainted | ----------------------------- | include/linux/rcupdate.h:272 Illegal context switch in RCU read-side critical section! | | other info that might help us debug this: | | | rcu_scheduler_active = 2, debug_locks = 1 | 4 locks held by kworker/0:1/62: | #0: ffff88813b019748 ((wq_completion)events){+.+.}, at: process_one_work+0x1d7/0x5e0 | #1: ffffc900000abe50 ((work_completion)(&map->work)){+.+.}, at: process_one_work+0x1d7/0x5e0 | #2: ffffffff82065d20 (rcu_read_lock){....}, at: sock_hash_free+0x5/0x1d0 | #3: ffff888139966e00 (&htab->buckets[i].lock){+...}, at: sock_hash_free+0x92/0x1d0 | | stack backtrace: | CPU: 0 PID: 62 Comm: kworker/0:1 Not tainted 5.5.0-04005-g8fc91b972b73-dirty #452 | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 | Workqueue: events bpf_map_free_deferred | Call Trace: | dump_stack+0x71/0xa0 | ___might_sleep+0x105/0x190 | lock_sock_nested+0x28/0x90 | sock_hash_free+0xec/0x1d0 | bpf_map_free_deferred+0x58/0x80 | process_one_work+0x260/0x5e0 | worker_thread+0x4d/0x3e0 | kthread+0x108/0x140 | ? process_one_work+0x5e0/0x5e0 | ? kthread_park+0x90/0x90 | ret_from_fork+0x3a/0x50 Fixes: 7e81a35 ("bpf: Sockmap, ensure sock lock held during tear down") Signed-off-by: Jakub Sitnicki <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: John Fastabend <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]

commit db6a501 upstream. rcu_read_lock is needed to protect access to psock inside sock_map_unref when tearing down the map. However, we can't afford to sleep in lock_sock while in RCU read-side critical section. Grab the RCU lock only after we have locked the socket. This fixes RCU warnings triggerable on a VM with 1 vCPU when free'ing a sockmap/sockhash that contains at least one socket: | ============================= | WARNING: suspicious RCU usage | 5.5.0-04005-g8fc91b972b73 torvalds#450 Not tainted | ----------------------------- | include/linux/rcupdate.h:272 Illegal context switch in RCU read-side critical section! | | other info that might help us debug this: | | | rcu_scheduler_active = 2, debug_locks = 1 | 4 locks held by kworker/0:1/62: | #0: ffff88813b019748 ((wq_completion)events){+.+.}, at: process_one_work+0x1d7/0x5e0 | #1: ffffc900000abe50 ((work_completion)(&map->work)){+.+.}, at: process_one_work+0x1d7/0x5e0 | #2: ffffffff82065d20 (rcu_read_lock){....}, at: sock_map_free+0x5/0x170 | #3: ffff8881368c5df8 (&stab->lock){+...}, at: sock_map_free+0x64/0x170 | | stack backtrace: | CPU: 0 PID: 62 Comm: kworker/0:1 Not tainted 5.5.0-04005-g8fc91b972b73 torvalds#450 | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 | Workqueue: events bpf_map_free_deferred | Call Trace: | dump_stack+0x71/0xa0 | ___might_sleep+0x105/0x190 | lock_sock_nested+0x28/0x90 | sock_map_free+0x95/0x170 | bpf_map_free_deferred+0x58/0x80 | process_one_work+0x260/0x5e0 | worker_thread+0x4d/0x3e0 | kthread+0x108/0x140 | ? process_one_work+0x5e0/0x5e0 | ? kthread_park+0x90/0x90 | ret_from_fork+0x3a/0x50 | ============================= | WARNING: suspicious RCU usage | 5.5.0-04005-g8fc91b972b73-dirty torvalds#452 Not tainted | ----------------------------- | include/linux/rcupdate.h:272 Illegal context switch in RCU read-side critical section! | | other info that might help us debug this: | | | rcu_scheduler_active = 2, debug_locks = 1 | 4 locks held by kworker/0:1/62: | #0: ffff88813b019748 ((wq_completion)events){+.+.}, at: process_one_work+0x1d7/0x5e0 | #1: ffffc900000abe50 ((work_completion)(&map->work)){+.+.}, at: process_one_work+0x1d7/0x5e0 | #2: ffffffff82065d20 (rcu_read_lock){....}, at: sock_hash_free+0x5/0x1d0 | #3: ffff888139966e00 (&htab->buckets[i].lock){+...}, at: sock_hash_free+0x92/0x1d0 | | stack backtrace: | CPU: 0 PID: 62 Comm: kworker/0:1 Not tainted 5.5.0-04005-g8fc91b972b73-dirty torvalds#452 | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 | Workqueue: events bpf_map_free_deferred | Call Trace: | dump_stack+0x71/0xa0 | ___might_sleep+0x105/0x190 | lock_sock_nested+0x28/0x90 | sock_hash_free+0xec/0x1d0 | bpf_map_free_deferred+0x58/0x80 | process_one_work+0x260/0x5e0 | worker_thread+0x4d/0x3e0 | kthread+0x108/0x140 | ? process_one_work+0x5e0/0x5e0 | ? kthread_park+0x90/0x90 | ret_from_fork+0x3a/0x50 Fixes: 7e81a35 ("bpf: Sockmap, ensure sock lock held during tear down") Signed-off-by: Jakub Sitnicki <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: John Fastabend <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/1867677 commit db6a501 upstream. rcu_read_lock is needed to protect access to psock inside sock_map_unref when tearing down the map. However, we can't afford to sleep in lock_sock while in RCU read-side critical section. Grab the RCU lock only after we have locked the socket. This fixes RCU warnings triggerable on a VM with 1 vCPU when free'ing a sockmap/sockhash that contains at least one socket: | ============================= | WARNING: suspicious RCU usage | 5.5.0-04005-g8fc91b972b73 torvalds#450 Not tainted | ----------------------------- | include/linux/rcupdate.h:272 Illegal context switch in RCU read-side critical section! | | other info that might help us debug this: | | | rcu_scheduler_active = 2, debug_locks = 1 | 4 locks held by kworker/0:1/62: | #0: ffff88813b019748 ((wq_completion)events){+.+.}, at: process_one_work+0x1d7/0x5e0 | #1: ffffc900000abe50 ((work_completion)(&map->work)){+.+.}, at: process_one_work+0x1d7/0x5e0 | #2: ffffffff82065d20 (rcu_read_lock){....}, at: sock_map_free+0x5/0x170 | #3: ffff8881368c5df8 (&stab->lock){+...}, at: sock_map_free+0x64/0x170 | | stack backtrace: | CPU: 0 PID: 62 Comm: kworker/0:1 Not tainted 5.5.0-04005-g8fc91b972b73 torvalds#450 | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 | Workqueue: events bpf_map_free_deferred | Call Trace: | dump_stack+0x71/0xa0 | ___might_sleep+0x105/0x190 | lock_sock_nested+0x28/0x90 | sock_map_free+0x95/0x170 | bpf_map_free_deferred+0x58/0x80 | process_one_work+0x260/0x5e0 | worker_thread+0x4d/0x3e0 | kthread+0x108/0x140 | ? process_one_work+0x5e0/0x5e0 | ? kthread_park+0x90/0x90 | ret_from_fork+0x3a/0x50 | ============================= | WARNING: suspicious RCU usage | 5.5.0-04005-g8fc91b972b73-dirty torvalds#452 Not tainted | ----------------------------- | include/linux/rcupdate.h:272 Illegal context switch in RCU read-side critical section! | | other info that might help us debug this: | | | rcu_scheduler_active = 2, debug_locks = 1 | 4 locks held by kworker/0:1/62: | #0: ffff88813b019748 ((wq_completion)events){+.+.}, at: process_one_work+0x1d7/0x5e0 | #1: ffffc900000abe50 ((work_completion)(&map->work)){+.+.}, at: process_one_work+0x1d7/0x5e0 | #2: ffffffff82065d20 (rcu_read_lock){....}, at: sock_hash_free+0x5/0x1d0 | #3: ffff888139966e00 (&htab->buckets[i].lock){+...}, at: sock_hash_free+0x92/0x1d0 | | stack backtrace: | CPU: 0 PID: 62 Comm: kworker/0:1 Not tainted 5.5.0-04005-g8fc91b972b73-dirty torvalds#452 | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 | Workqueue: events bpf_map_free_deferred | Call Trace: | dump_stack+0x71/0xa0 | ___might_sleep+0x105/0x190 | lock_sock_nested+0x28/0x90 | sock_hash_free+0xec/0x1d0 | bpf_map_free_deferred+0x58/0x80 | process_one_work+0x260/0x5e0 | worker_thread+0x4d/0x3e0 | kthread+0x108/0x140 | ? process_one_work+0x5e0/0x5e0 | ? kthread_park+0x90/0x90 | ret_from_fork+0x3a/0x50 Fixes: 7e81a35 ("bpf: Sockmap, ensure sock lock held during tear down") Signed-off-by: Jakub Sitnicki <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: John Fastabend <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Kamal Mostafa <[email protected]> Signed-off-by: Khalid Elmously <[email protected]>

The following warning pops up with enabled UBSAN in tests fstests/generic/303: [23127.529395] UBSAN: Undefined behaviour in fs/read_write.c:1725:7 [23127.529400] signed integer overflow: [23127.529403] 4611686018427322368 + 9223372036854775807 cannot be represented in type 'long long int' [23127.529412] CPU: 4 PID: 26180 Comm: xfs_io Not tainted 5.2.0-rc2-1.ge195904-vanilla+ torvalds#450 [23127.556999] Hardware name: empty empty/S3993, BIOS PAQEX0-3 02/24/2008 [23127.557001] Call Trace: [23127.557060] dump_stack+0x67/0x9b [23127.557070] ubsan_epilogue+0x9/0x40 [23127.573496] handle_overflow+0xb3/0xc0 [23127.573514] do_clone_file_range+0x28f/0x2a0 [23127.573547] vfs_clone_file_range+0x35/0xb0 [23127.573564] ioctl_file_clone+0x8d/0xc0 [23127.590144] do_vfs_ioctl+0x300/0x700 [23127.590160] ksys_ioctl+0x70/0x80 [23127.590203] ? trace_hardirqs_off_thunk+0x1a/0x1c [23127.590210] __x64_sys_ioctl+0x16/0x20 [23127.590215] do_syscall_64+0x5c/0x1d0 [23127.590224] entry_SYSCALL_64_after_hwframe+0x49/0xbe [23127.590231] RIP: 0033:0x7ff6d7250327 [23127.590241] RSP: 002b:00007ffe3a38f1d8 EFLAGS: 00000206 ORIG_RAX: 0000000000000010 [23127.590246] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007ff6d7250327 [23127.590249] RDX: 00007ffe3a38f220 RSI: 000000004020940d RDI: 0000000000000003 [23127.590252] RBP: 0000000000000000 R08: 00007ffe3a3c80a0 R09: 00007ffe3a3c8080 [23127.590255] R10: 000000000fa99fa0 R11: 0000000000000206 R12: 0000000000000000 [23127.590260] R13: 0000000000000000 R14: 3fffffffffff0000 R15: 00007ff6d750a20c As loff_t is a signed type, we should use the safe overflow checks instead of relying on compiler implementation. The bogus values are intentional and the test is supposed to verify the boundary conditions. Signed-off-by: David Sterba <[email protected]>

The following warning pops up with enabled UBSAN in tests fstests/generic/303: [23127.529395] UBSAN: Undefined behaviour in fs/read_write.c:1725:7 [23127.529400] signed integer overflow: [23127.529403] 4611686018427322368 + 9223372036854775807 cannot be represented in type 'long long int' [23127.529412] CPU: 4 PID: 26180 Comm: xfs_io Not tainted 5.2.0-rc2-1.ge195904-vanilla+ torvalds#450 [23127.556999] Hardware name: empty empty/S3993, BIOS PAQEX0-3 02/24/2008 [23127.557001] Call Trace: [23127.557060] dump_stack+0x67/0x9b [23127.557070] ubsan_epilogue+0x9/0x40 [23127.573496] handle_overflow+0xb3/0xc0 [23127.573514] do_clone_file_range+0x28f/0x2a0 [23127.573547] vfs_clone_file_range+0x35/0xb0 [23127.573564] ioctl_file_clone+0x8d/0xc0 [23127.590144] do_vfs_ioctl+0x300/0x700 [23127.590160] ksys_ioctl+0x70/0x80 [23127.590203] ? trace_hardirqs_off_thunk+0x1a/0x1c [23127.590210] __x64_sys_ioctl+0x16/0x20 [23127.590215] do_syscall_64+0x5c/0x1d0 [23127.590224] entry_SYSCALL_64_after_hwframe+0x49/0xbe [23127.590231] RIP: 0033:0x7ff6d7250327 [23127.590241] RSP: 002b:00007ffe3a38f1d8 EFLAGS: 00000206 ORIG_RAX: 0000000000000010 [23127.590246] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007ff6d7250327 [23127.590249] RDX: 00007ffe3a38f220 RSI: 000000004020940d RDI: 0000000000000003 [23127.590252] RBP: 0000000000000000 R08: 00007ffe3a3c80a0 R09: 00007ffe3a3c8080 [23127.590255] R10: 000000000fa99fa0 R11: 0000000000000206 R12: 0000000000000000 [23127.590260] R13: 0000000000000000 R14: 3fffffffffff0000 R15: 00007ff6d750a20c As loff_t is a signed type, we should use the safe overflow checks instead of relying on compiler implementation. The bogus values are intentional and the test is supposed to verify the boundary conditions. Signed-off-by: David Sterba <[email protected]> Message-Id: <[email protected]> Signed-off-by: Christian Brauner <[email protected]>

hadarhenzion and others added 6 commits August 16, 2017 15:37

matanb10 and others added 7 commits August 24, 2017 11:00

roidayan force-pushed the asap2-direct-3.3-next branch from c8462ac to 54d6c88 Compare August 24, 2017 08:03

roidayan and others added 9 commits August 28, 2017 11:49

net/sched: Change tc_action refcnt and bindcnt to atomic

15390b2

Signed-off-by: Chris Mi <[email protected]>

roidayan force-pushed the asap2-direct-3.3-next branch from 54d6c88 to 4d3f831 Compare September 17, 2017 05:59

congwang and others added 5 commits September 28, 2017 18:02

net/mlx5: Add hairpin definitions to the FW API

016b216

Add hairpin definitions to the IFC file. issue: 1068457 Change-Id: I3fc9dba9ad80a263b00c38f36672284d83094f3e Signed-off-by: Or Gerlitz <[email protected]>

nonthasuk reviewed Oct 11, 2017

View reviewed changes

roidayan and others added 7 commits October 26, 2017 16:53

Revert "net/mlx5e: Fix double encap cleanup"

e8e73b6

This reverts commit f031786.

Revert "net/mlx5e: Change VF representor's RQ size and type"

5ef7c32

This reverts commit 27b3360.

roidayan deleted the asap2-direct-3.3-next branch May 26, 2020 18:31

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Asap2 direct 3.3 next #450

Asap2 direct 3.3 next #450

mishuang2017 commented Aug 17, 2017

KernelPRBot commented Aug 17, 2017

nonthasuk left a comment

Asap2 direct 3.3 next #450

Are you sure you want to change the base?

Asap2 direct 3.3 next #450

Conversation

mishuang2017 commented Aug 17, 2017

KernelPRBot commented Aug 17, 2017

How do I format my contribution?

Who do I send my contribution to?

How do I send my contribution?

How do I get help if I'm stuck?

I sent my patch - now what?

Further information

nonthasuk left a comment

Choose a reason for hiding this comment