♟ hselasky

Fix compilation issue with mlx5core and sparc64 (gcc48):

Implement hardware TLS via send tags for mlx5en(4), which is supported by

In D22669#496485, @jhb wrote:

As I have told you multiple times, it is _not_ the same for Chelsio as TLS send tags on Chelsio always support rate limiting. However, it doesn't seem like this is blocking upstreaming since you've just committed the non-ratelimit TLS code today?

Add basic support for TCP/IP based hardware TLS offload to mlx5core.

MFC r355108 and r355170:

In D22669#495980, @jhb wrote:

How does changing the rate work? Right now you'd have to have all the places that change the rate figure out what type the tag is to send a different structure down for modifying the rate. That is sub-optimal. This also doesn't address the issue of how to make the socket option adjust the rate of an existing tag. Just adding a new tag type is the easy part of the problem, but not a full solution on its own.

Use refcount from "in_joingroup_locked()" when joining multicast

Implement suggestion from @rgrimes .

Looks good with regards to EPOCH and wrapping counters.

Factor out check for mounted root file system.

Handle comments from @kib

Keep the rootvnode check in case the root file system gets unmounted.
Update comment.

Index: sys/kern/kern_linker.c
===================================================================
--- sys/kern/kern_linker.c	(revision 355108)
+++ sys/kern/kern_linker.c	(working copy)
@@ -2067,6 +2067,7 @@
     struct linker_file *parent, const struct mod_depend *verinfo,
     struct linker_file **lfpp)
 {
+	struct proc *cp = curproc;
 	linker_file_t lfdep;
 	const char *filename;
 	char *pathname;
@@ -2079,13 +2080,13 @@
  		 */
 		KASSERT(verinfo == NULL, ("linker_load_module: verinfo"
 		    " is not NULL"));
-		if (rootvnode == NULL)
+		if (rootvnode == NULL || cp->p_fd == NULL || cp->p_fd->fd_rdir == NULL)
 			return (ENXIO);
 		pathname = linker_search_kld(kldname);
 	} else {
 		if (modlist_lookup2(modname, verinfo) != NULL)
 			return (EEXIST);
-		if (rootvnode == NULL)
+		if (rootvnode == NULL || cp->p_fd == NULL || cp->p_fd->fd_rdir == NULL)
 			return (ENXIO);
 		if (kldname != NULL)
 			pathname = strdup(kldname, M_LINKER);

I wonder if this check should be factored out? It is not only the LinuxKPI which access these code paths too early, but USB drivers loading firmware .ko's can also do the same??

Fix panic when loading kernel modules before root file system is mounted.

Include full context.

Add USB ID for Diamond Multimedia BVU195 Display Link device.

Prevent potential underflow in ibcore.

Correct MR length field to be 64-bit in ibcore.

Check CSUM_SND_TAG flag before classifying packet has having a send

Revert accidential chunk added to GENERIC from previous commit.

Partial MFC of CSUM_SND_TAG flag from r348254.

Enable device class group attributes in the LinuxKPI.

Who will submit this patch?

Please add code to drain this new task.

Fix panic in network stack due to use after free when receiving

VLAN_TRUNKDEV() requires epochification in ibcore after r353292.

Replace rdma_is_upper_dev_rcu() with rdma_vlan_dev_real_dev() in ibcore.

VLAN_DEVAT() requires epochification in ipoib after r353292.

The two functions ifnet_byindex() and ifnet_byindex_locked() are exactly the

Exclude the network link eventhandler from epochification after r353292.

Fix missing epochification of the LinuxKPI after r353292.

Fix missing epochification of the ibcore code after r353292.

Fix missing epochification of the ipoib code after r353292.

Update port to v1.0-alpha.2

Remove whitespace at end of line.

I've added prints in the new code paths and verified that:

Factor out TCP rateset destruction code.

Fix locking order reversal in the TCP ratelimit code by moving

No need to check shutdown flag in IPv6 fragment cleanup code yet (@bz fill add this later)

Fix check for shutdown in IPv4 reassembly cleanup.

Yes, that's the simplest.

Update port Makefile as suggested by mat@ .

Ultimately, why does this stuff need to be done asynchronously in a different process? I would understand if bits outside of dev/usb/serial/* were submitting commands to this process as well, but that's simply not the case as far as I can tell -- it looks like it was mostly done like this to match the structure of usb_ethernet, which is not a solid reason.

@bz: The old checks don't respect if we are bringing up or destroying a VNET. For example this one in if_detach:

sys/ofed, sys/dev/mlx4, sys/dev/mlx5 and sys/dev/usb changes look OK.

hselasky (Hans Petter Selasky)
User

Projects

User Details

Recent Activity
View All

Yesterday

Thu, Dec 5

Wed, Dec 4

Tue, Dec 3

Sun, Dec 1

Sat, Nov 30

Fri, Nov 29

Thu, Nov 28

Wed, Nov 27

Tue, Nov 26

Mon, Nov 25

Fri, Nov 22

Thu, Nov 21

Tue, Nov 19

Fri, Nov 15

Mon, Nov 11

Thu, Nov 7

Nov 4 2019

Oct 25 2019

Oct 16 2019

Oct 15 2019

Oct 14 2019

Oct 10 2019

Oct 9 2019

Oct 8 2019

hselasky (Hans Petter Selasky)User