net/hsr: Add support for IEC 62439-3 High-availability Seamless Redundancy

Review

Quoted 10 lines · On Tue, 27 Mar 2012 15:20:45 +0200 Arvid Brodin <[email protected]> wrote:

(quoted diff) +10 -0

+config NONSTANDARD_HSR
+	bool "HSR: Use efficient tag (breaks HSR standard, read help!)"
+	depends on HSR
+	---help---
+	  The HSR standard specifies a 6-byte HSR tag to be inserted into the
+	  transmitted network frames. This breaks the 32-bit alignment that the
+	  Linux network stack relies on, and would cause kernel panics on
+	  certain architectures. To avoid this, the whole frame payload is
+	  memmoved 2 bytes on reception on these architectures - which is very
+	  inefficient!

This option won't fly. Don't do it.
If you need to copy/realign packets on some architecture the stack should be changed to handle it.

Quoted 17 lines · Stephen Hemminger

Review

Quoted 10 lines · On Tue, 27 Mar 2012 15:20:45 +0200 Arvid Brodin <[email protected]> wrote:

(quoted diff) +10 -0

+config NONSTANDARD_HSR
+	bool "HSR: Use efficient tag (breaks HSR standard, read help!)"
+	depends on HSR
+	---help---
+	  The HSR standard specifies a 6-byte HSR tag to be inserted into the
+	  transmitted network frames. This breaks the 32-bit alignment that the
+	  Linux network stack relies on, and would cause kernel panics on
+	  certain architectures. To avoid this, the whole frame payload is
+	  memmoved 2 bytes on reception on these architectures - which is very
+	  inefficient!

This option won't fly. Don't do it.
If you need to copy/realign packets on some architecture the stack should be changed to handle it.

Ok. The problems are in net/ipv4/icmp.c. The below patch seems to do the trick for me - does it look OK (and if so, should I resend it as a normal patch instead of a reply or is this enough)?

Note that I've only triggered this problem in icmp_echo(), but I noticed that icmp_timestamp() does the same thing, so I made the change there too.

[PATCH] net/ipv4/icmp: Fix kernel panic due to unaligned access with HSR on AVR32

icmp_echo() and icmp_timestamp() requires the icmphdr struct to be 32-bit aligned. This causes a kernel panic on AVR32 when HSR is used, since the HSR protocol inserts a 6-byte "HSR tag" into Ethernet frame headers, thus changing the alignment.

HSR = IEC 62439-3 High-availability Seamless Redundancy.

Signed-off-by Arvid Brodin <[email protected]>

---
 net/ipv4/icmp.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

net/ipv4/icmp.c +2 -1

index 2cb2bf8..fdd8097 100644
@@ -818,7 +818,8 @@ static void icmp_echo(struct sk_buff *skb)
 	if (!net->ipv4.sysctl_icmp_echo_ignore_all) {
 		struct icmp_bxm icmp_param;
 
-		icmp_param.data.icmph	   = *icmp_hdr(skb);
+		memcpy(&icmp_param.data.icmph, icmp_hdr(skb),
+						sizeof(icmp_param.data.icmph));
 		icmp_param.data.icmph.type = ICMP_ECHOREPLY;
 		icmp_param.skb		   = skb;
 		icmp_param.offset	   = 0;

That isn't so bad, doing a memcpy versus a structure copy.

From: Stephen Hemminger <[email protected]>
Date: Wed, 4 Apr 2012 16:55:59 -0700

Quoted 1 line

That isn't so bad, doing a memcpy versus a structure copy.

GCC is going to inline the memcpy and thus we'll still do the unaligned accesses. This change therefore won't fix the problem.

Just out of curiosity, what's the mechanism behind this inline assignment that turns the memcpy into an unaligned access? If gcc is "smart" enough to detect a bunch of char * accesses and turn them into unaligned 32-bit accesses, isn't that a bug in gcc?

From: Arvid Brodin <[email protected]>
Date: Fri, 6 Apr 2012 17:51:24 +0200

Quoted 4 lines

Just out of curiosity, what's the mechanism behind this inline assignment that turns the memcpy into an unaligned access? If gcc is "smart" enough to detect a bunch of char * accesses and turn them into unaligned 32-bit accesses, isn't that a bug in gcc?

It's not doing it with "char *", it's doing it with other types like the type of the ICMP header in this case.

memcpy is expanded by the compiler internally into __builtin_memcpy() which if it sees the length is reasonably short will inline the copy. And subsequently it uses the alignment of the types involved to determine what kinds of loads and stores it can use in that inline memcpy().

So the result is that just because in your case with your compiler it doesn't get expanded inline and fault, it doesn't mean it won't for someone else.

You're just lucky, and you really haven't fixed the bug.

Quoted 7 lines · David Miller

From: Stephen Hemminger <[email protected]>
Date: Wed, 4 Apr 2012 16:55:59 -0700

Quoted 1 line

That isn't so bad, doing a memcpy versus a structure copy.

GCC is going to inline the memcpy and thus we'll still do the unaligned accesses. This change therefore won't fix the problem.

Well, it does work for me, with gcc-4.2.2-compiled linux-2.6.37 running on an AVR32 board.

Just out of curiosity, what's the mechanism behind this inline assignment that turns the memcpy into an unaligned access? If gcc is "smart" enough to detect a bunch of char * accesses and turn them into unaligned 32-bit accesses, isn't that a bug in gcc?

Or will this only happen on archs which __HAVE_ARCH_MEMCPY? (But looking at a couple of arch/xxx/lib/string.c, these too seem to take alignment into account.)

Quoted 9 lines · Arvid Brodin

Quoted 7 lines · David Miller

From: Stephen Hemminger <[email protected]>
Date: Wed, 4 Apr 2012 16:55:59 -0700

Quoted 1 line

That isn't so bad, doing a memcpy versus a structure copy.

GCC is going to inline the memcpy and thus we'll still do the unaligned accesses. This change therefore won't fix the problem.

Quoted 7 lines

Well, it does work for me, with gcc-4.2.2-compiled linux-2.6.37 running on an AVR32 board.

Just out of curiosity, what's the mechanism behind this inline assignment that turns the memcpy into an unaligned access? If gcc is "smart" enough to detect a bunch of char * accesses and turn them into unaligned 32-bit accesses, isn't that a bug in gcc?

If I remember correctly, casting a char* pointer to foo* where the original pointer isn't properly aligned for type foo results in undefined behaviour. And that is what icmp_hdr() is doing, so there is no requirement that the compiler does anything reasonable with the result. Removing that cast (using skb_transport_header() instead of icmp_hdr()) should avoid that.

(We do generally assume, however, that if the processor can handle unaligned accesses in a useful way then the compiler will be reasonable and not break them.)

Ben.

Quoted 4 lines

Or will this only happen on archs which __HAVE_ARCH_MEMCPY? (But looking at a couple of arch/xxx/lib/string.c, these too seem to take alignment into account.)

Quoted 31 lines · On Fri, 6 Apr 2012 18:06:31 +0100 Ben Hutchings <[email protected]>…

Quoted 9 lines · Arvid Brodin

Quoted 7 lines · David Miller

From: Stephen Hemminger <[email protected]>
Date: Wed, 4 Apr 2012 16:55:59 -0700

Quoted 1 line

That isn't so bad, doing a memcpy versus a structure copy.

GCC is going to inline the memcpy and thus we'll still do the unaligned accesses. This change therefore won't fix the problem.

Quoted 7 lines

Well, it does work for me, with gcc-4.2.2-compiled linux-2.6.37 running on an AVR32 board.

Just out of curiosity, what's the mechanism behind this inline assignment that turns the memcpy into an unaligned access? If gcc is "smart" enough to detect a bunch of char * accesses and turn them into unaligned 32-bit accesses, isn't that a bug in gcc?

If I remember correctly, casting a char* pointer to foo* where the original pointer isn't properly aligned for type foo results in undefined behaviour. And that is what icmp_hdr() is doing, so there is no requirement that the compiler does anything reasonable with the result. Removing that cast (using skb_transport_header() instead of icmp_hdr()) should avoid that.

(We do generally assume, however, that if the processor can handle unaligned accesses in a useful way then the compiler will be reasonable and not break them.)

Ben.

Quoted 5 lines

Quoted 4 lines

Or will this only happen on archs which __HAVE_ARCH_MEMCPY? (But looking at a couple of arch/xxx/lib/string.c, these too seem to take alignment into account.)

Since icmp_hdr is 64 bits you might be able to use get_unaligned64 in some way.

From: Ben Hutchings <[email protected]>
Date: Thu, 5 Apr 2012 20:21:08 +0100

Quoted 2 lines

So presumably icmp_hdr() should be changed to skb_transport_header().

I would not say so. Otherwise we introduce ugly casts everywhere.

3) My feeble suggestion to cast icmp_hdr() to (char *) is of course even worse (it doesn't even avoid the erroneous cast in the first place).

So what do we do?

Quoted 6 lines

3) My feeble suggestion to cast icmp_hdr() to (char *) is of course even worse (it doesn't even avoid the erroneous cast in the first place).

So what do we do?

Reading Documentation/unalgined-memory-access.txt suggests that you probably should copy the skb before passing up the stack (if necessary). That is safe (but slightly slower).

From: Arvid Brodin <[email protected]>
Date: Thu, 5 Apr 2012 01:09:48 +0200

net/ipv4/icmp.c static void icmp_echo(struct sk_buff *skb) · line 822

Quoted 3 lines

net/ipv4/icmp.c +2 -1

-		icmp_param.data.icmph	   = *icmp_hdr(skb);
+		memcpy(&icmp_param.data.icmph, icmp_hdr(skb),
+						sizeof(icmp_param.data.icmph));

GCC can and will optimize this into an inline assignment, and thus have the same unaligned access problems, because it determines alignment based upon the types involved.

Quoted 10 lines

From: Arvid Brodin <[email protected]>
Date: Thu, 5 Apr 2012 01:09:48 +0200

net/ipv4/icmp.c static void icmp_echo(struct sk_buff *skb) · line 822

Quoted 3 lines

net/ipv4/icmp.c +2 -1

-		icmp_param.data.icmph	   = *icmp_hdr(skb);
+		memcpy(&icmp_param.data.icmph, icmp_hdr(skb),
+						sizeof(icmp_param.data.icmph));

GCC can and will optimize this into an inline assignment, and thus have the same unaligned access problems, because it determines alignment based upon the types involved.

So presumably icmp_hdr() should be changed to skb_transport_header().

Hi!

2) I have a locking problem that I haven't managed to figure out. This happens the first time I send any packet (hsr_dev_xmit() in hsr_device.c:121, called from hsr_device.c:147). It happens even if I set skb2 to NULL (i.e. only send one copy):

=============================================
[ INFO: possible recursive locking detected ]
2.6.37 #118
---------------------------------------------
swapper/0 is trying to acquire lock:
(_xmit_ETHER#2){+.-...}, at: [<901bf38e>] sch_direct_xmit+0x24/0x152

but task is already holding lock:
(_xmit_ETHER#2){+.-...}, at: [<901b4d1a>] dev_queue_xmit+0x31e/0x3cc

other info that might help us debug this:
4 locks held by swapper/0:

 #0:  (&n->timer){+.-...}, at: [<9002bc20>] run_timer_softirq+0x98/0x184
 #1:  (rcu_read_lock_bh){.+....}, at: [<901b49fc>] dev_queue_xmit+0x0/0x3cc
 #2:  (_xmit_ETHER#2){+.-...}, at: [<901b4d1a>] dev_queue_xmit+0x31e/0x3cc
 #3:  (rcu_read_lock_bh){.+....}, at: [<901b49fc>] dev_queue_xmit+0x0/0x3cc

stack backtrace:
Call trace:
 [<9001c640>] dump_stack+0x18/0x20
 [<90040eac>] validate_chain+0x40c/0x9ac
 [<90041a58>] __lock_acquire+0x60c/0x670
 [<90042f32>] lock_acquire+0x3a/0x48
 [<902201a4>] _raw_spin_lock+0x20/0x44
 [<901bf38e>] sch_direct_xmit+0x24/0x152
 [<901b4c14>] dev_queue_xmit+0x218/0x3cc
 [<9021c2e0>] slave_xmit+0x10/0x14
 [<9021c540>] hsr_dev_xmit+0x88/0x8c
 [<901b4942>] dev_hard_start_xmit+0x3c6/0x480
 [<901b4d34>] dev_queue_xmit+0x338/0x3cc
 [<901e3cd8>] arp_xmit+0x8/0xc
 [<901e4436>] arp_send+0x2a/0x2c
 [<901e4e74>] arp_solicit+0x15c/0x170
 [<901bad0c>] neigh_timer_handler+0x1c0/0x204
 [<9002bc8a>] run_timer_softirq+0x102/0x184
 [<900287d8>] __do_softirq+0x64/0xe0
 [<9002896a>] do_softirq+0x26/0x48
 [<90028a66>] irq_exit+0x2e/0x64
 [<90019f16>] do_IRQ+0x46/0x5c
 [<90018428>] irq_level0+0x18/0x60
 [<9021cc16>] rest_init+0x72/0x98
 [<9000063c>] start_kernel+0x21c/0x258
 [<00000000>] 0x0

Any idea why this happens? I need help!

Quoted 1 line · Arvid Brodin

Hi!

*snip*

Quoted 50 lines

2) I have a locking problem that I haven't managed to figure out. This happens the first time I send any packet (hsr_dev_xmit() in hsr_device.c:121, called from hsr_device.c:147). It happens even if I set skb2 to NULL (i.e. only send one copy):

=============================================
[ INFO: possible recursive locking detected ]
2.6.37 #118
---------------------------------------------
swapper/0 is trying to acquire lock:
(_xmit_ETHER#2){+.-...}, at: [<901bf38e>] sch_direct_xmit+0x24/0x152

but task is already holding lock:
(_xmit_ETHER#2){+.-...}, at: [<901b4d1a>] dev_queue_xmit+0x31e/0x3cc

other info that might help us debug this:
4 locks held by swapper/0:

 #0:  (&n->timer){+.-...}, at: [<9002bc20>] run_timer_softirq+0x98/0x184
 #1:  (rcu_read_lock_bh){.+....}, at: [<901b49fc>] dev_queue_xmit+0x0/0x3cc
 #2:  (_xmit_ETHER#2){+.-...}, at: [<901b4d1a>] dev_queue_xmit+0x31e/0x3cc
 #3:  (rcu_read_lock_bh){.+....}, at: [<901b49fc>] dev_queue_xmit+0x0/0x3cc

stack backtrace:
Call trace:
 [<9001c640>] dump_stack+0x18/0x20
 [<90040eac>] validate_chain+0x40c/0x9ac
 [<90041a58>] __lock_acquire+0x60c/0x670
 [<90042f32>] lock_acquire+0x3a/0x48
 [<902201a4>] _raw_spin_lock+0x20/0x44
 [<901bf38e>] sch_direct_xmit+0x24/0x152
 [<901b4c14>] dev_queue_xmit+0x218/0x3cc
 [<9021c2e0>] slave_xmit+0x10/0x14
 [<9021c540>] hsr_dev_xmit+0x88/0x8c
 [<901b4942>] dev_hard_start_xmit+0x3c6/0x480
 [<901b4d34>] dev_queue_xmit+0x338/0x3cc
 [<901e3cd8>] arp_xmit+0x8/0xc
 [<901e4436>] arp_send+0x2a/0x2c
 [<901e4e74>] arp_solicit+0x15c/0x170
 [<901bad0c>] neigh_timer_handler+0x1c0/0x204
 [<9002bc8a>] run_timer_softirq+0x102/0x184
 [<900287d8>] __do_softirq+0x64/0xe0
 [<9002896a>] do_softirq+0x26/0x48
 [<90028a66>] irq_exit+0x2e/0x64
 [<90019f16>] do_IRQ+0x46/0x5c
 [<90018428>] irq_level0+0x18/0x60
 [<9021cc16>] rest_init+0x72/0x98
 [<9000063c>] start_kernel+0x21c/0x258
 [<00000000>] 0x0

Quoted 1 line

Any idea why this happens? I need help!

I've spent a few days digging into this and the key apparently is NETIF_F_LLTX.

The problem seems to be that HARD_TX_LOCK is called more than once, first for my virtual hsr device and then, recursively, for each of the slaves in turn. (At least that's where lockdep complains - at __netif_tx_lock(), that is.)

At first I just could not understand why both the VLAN and the bonding code got away with recursive calls to dev_queue_xmit() but I didn't. After some gooling (a lot, actually) I found some references to the NETIF_F_LLTX flag (here's one:
http://lwn.net/Articles/121566/). I realised both VLAN and bonding code set this flag. And sure enough, if I set it for my hsr device lockdep does not complain any more.

But NETIF_F_LLTX is described as deprecated in both netdevice.h and in Documentation/networking/netdevices.txt. Is there an alternative solution that I should use instead?

(To recap, a hsr device is a virtual device which uses two Ethernet devices as slaves. This gives redundancy with instant failover, and since nodes are connected in a ring topology, uses less cabling than duplication.)

Quoted 69 lines · On Mon, 14 May 2012 18:11:44 +0000 Arvid Brodin <[email protected]> wrote:

Quoted 1 line · Arvid Brodin

Hi!

*snip*

Quoted 50 lines

2) I have a locking problem that I haven't managed to figure out. This happens the first time I send any packet (hsr_dev_xmit() in hsr_device.c:121, called from hsr_device.c:147). It happens even if I set skb2 to NULL (i.e. only send one copy):

=============================================
[ INFO: possible recursive locking detected ]
2.6.37 #118
---------------------------------------------
swapper/0 is trying to acquire lock:
(_xmit_ETHER#2){+.-...}, at: [<901bf38e>] sch_direct_xmit+0x24/0x152

but task is already holding lock:
(_xmit_ETHER#2){+.-...}, at: [<901b4d1a>] dev_queue_xmit+0x31e/0x3cc

other info that might help us debug this:
4 locks held by swapper/0:

 #0:  (&n->timer){+.-...}, at: [<9002bc20>] run_timer_softirq+0x98/0x184
 #1:  (rcu_read_lock_bh){.+....}, at: [<901b49fc>] dev_queue_xmit+0x0/0x3cc
 #2:  (_xmit_ETHER#2){+.-...}, at: [<901b4d1a>] dev_queue_xmit+0x31e/0x3cc
 #3:  (rcu_read_lock_bh){.+....}, at: [<901b49fc>] dev_queue_xmit+0x0/0x3cc

stack backtrace:
Call trace:
 [<9001c640>] dump_stack+0x18/0x20
 [<90040eac>] validate_chain+0x40c/0x9ac
 [<90041a58>] __lock_acquire+0x60c/0x670
 [<90042f32>] lock_acquire+0x3a/0x48
 [<902201a4>] _raw_spin_lock+0x20/0x44
 [<901bf38e>] sch_direct_xmit+0x24/0x152
 [<901b4c14>] dev_queue_xmit+0x218/0x3cc
 [<9021c2e0>] slave_xmit+0x10/0x14
 [<9021c540>] hsr_dev_xmit+0x88/0x8c
 [<901b4942>] dev_hard_start_xmit+0x3c6/0x480
 [<901b4d34>] dev_queue_xmit+0x338/0x3cc
 [<901e3cd8>] arp_xmit+0x8/0xc
 [<901e4436>] arp_send+0x2a/0x2c
 [<901e4e74>] arp_solicit+0x15c/0x170
 [<901bad0c>] neigh_timer_handler+0x1c0/0x204
 [<9002bc8a>] run_timer_softirq+0x102/0x184
 [<900287d8>] __do_softirq+0x64/0xe0
 [<9002896a>] do_softirq+0x26/0x48
 [<90028a66>] irq_exit+0x2e/0x64
 [<90019f16>] do_IRQ+0x46/0x5c
 [<90018428>] irq_level0+0x18/0x60
 [<9021cc16>] rest_init+0x72/0x98
 [<9000063c>] start_kernel+0x21c/0x258
 [<00000000>] 0x0

Quoted 1 line

Any idea why this happens? I need help!

I've spent a few days digging into this and the key apparently is NETIF_F_LLTX.

The problem seems to be that HARD_TX_LOCK is called more than once, first for my virtual hsr device and then, recursively, for each of the slaves in turn. (At least that's where lockdep complains - at __netif_tx_lock(), that is.)

At first I just could not understand why both the VLAN and the bonding code got away with recursive calls to dev_queue_xmit() but I didn't. After some gooling (a lot, actually) I found some references to the NETIF_F_LLTX flag (here's one:
http://lwn.net/Articles/121566/). I realised both VLAN and bonding code set this flag. And sure enough, if I set it for my hsr device lockdep does not complain any more.

Quoted 8 lines

But NETIF_F_LLTX is described as deprecated in both netdevice.h and in Documentation/networking/netdevices.txt. Is there an alternative solution that I should use instead?

(To recap, a hsr device is a virtual device which uses two Ethernet devices as slaves. This gives redundancy with instant failover, and since nodes are connected in a ring topology, uses less cabling than duplication.)

LLTX is deprecated (ie should not be used) for physical devices.

Also, for virtual devices, there should be non transmit queue, this causes mulit-queue lockless semantics to be preserved as the call passes through the virtual device.

Quoted 81 lines · Stephen Hemminger

Quoted 69 lines · On Mon, 14 May 2012 18:11:44 +0000 Arvid Brodin <[email protected]> wrote:

Quoted 1 line · Arvid Brodin

Hi!

*snip*

Quoted 50 lines

2) I have a locking problem that I haven't managed to figure out. This happens the first time I send any packet (hsr_dev_xmit() in hsr_device.c:121, called from hsr_device.c:147). It happens even if I set skb2 to NULL (i.e. only send one copy):

=============================================
[ INFO: possible recursive locking detected ]
2.6.37 #118
---------------------------------------------
swapper/0 is trying to acquire lock:
(_xmit_ETHER#2){+.-...}, at: [<901bf38e>] sch_direct_xmit+0x24/0x152

but task is already holding lock:
(_xmit_ETHER#2){+.-...}, at: [<901b4d1a>] dev_queue_xmit+0x31e/0x3cc

other info that might help us debug this:
4 locks held by swapper/0:

 #0:  (&n->timer){+.-...}, at: [<9002bc20>] run_timer_softirq+0x98/0x184
 #1:  (rcu_read_lock_bh){.+....}, at: [<901b49fc>] dev_queue_xmit+0x0/0x3cc
 #2:  (_xmit_ETHER#2){+.-...}, at: [<901b4d1a>] dev_queue_xmit+0x31e/0x3cc
 #3:  (rcu_read_lock_bh){.+....}, at: [<901b49fc>] dev_queue_xmit+0x0/0x3cc

stack backtrace:
Call trace:
 [<9001c640>] dump_stack+0x18/0x20
 [<90040eac>] validate_chain+0x40c/0x9ac
 [<90041a58>] __lock_acquire+0x60c/0x670
 [<90042f32>] lock_acquire+0x3a/0x48
 [<902201a4>] _raw_spin_lock+0x20/0x44
 [<901bf38e>] sch_direct_xmit+0x24/0x152
 [<901b4c14>] dev_queue_xmit+0x218/0x3cc
 [<9021c2e0>] slave_xmit+0x10/0x14
 [<9021c540>] hsr_dev_xmit+0x88/0x8c
 [<901b4942>] dev_hard_start_xmit+0x3c6/0x480
 [<901b4d34>] dev_queue_xmit+0x338/0x3cc
 [<901e3cd8>] arp_xmit+0x8/0xc
 [<901e4436>] arp_send+0x2a/0x2c
 [<901e4e74>] arp_solicit+0x15c/0x170
 [<901bad0c>] neigh_timer_handler+0x1c0/0x204
 [<9002bc8a>] run_timer_softirq+0x102/0x184
 [<900287d8>] __do_softirq+0x64/0xe0
 [<9002896a>] do_softirq+0x26/0x48
 [<90028a66>] irq_exit+0x2e/0x64
 [<90019f16>] do_IRQ+0x46/0x5c
 [<90018428>] irq_level0+0x18/0x60
 [<9021cc16>] rest_init+0x72/0x98
 [<9000063c>] start_kernel+0x21c/0x258
 [<00000000>] 0x0

Quoted 1 line

Any idea why this happens? I need help!

I've spent a few days digging into this and the key apparently is NETIF_F_LLTX.

The problem seems to be that HARD_TX_LOCK is called more than once, first for my virtual hsr device and then, recursively, for each of the slaves in turn. (At least that's where lockdep complains - at __netif_tx_lock(), that is.)

At first I just could not understand why both the VLAN and the bonding code got away with recursive calls to dev_queue_xmit() but I didn't. After some gooling (a lot, actually) I found some references to the NETIF_F_LLTX flag (here's one:
http://lwn.net/Articles/121566/). I realised both VLAN and bonding code set this flag. And sure enough, if I set it for my hsr device lockdep does not complain any more.

Quoted 8 lines

But NETIF_F_LLTX is described as deprecated in both netdevice.h and in Documentation/networking/netdevices.txt. Is there an alternative solution that I should use instead?

(To recap, a hsr device is a virtual device which uses two Ethernet devices as slaves. This gives redundancy with instant failover, and since nodes are connected in a ring topology, uses less cabling than duplication.)

Quoted 5 lines

LLTX is deprecated (ie should not be used) for physical devices.

Also, for virtual devices, there should be non transmit queue, this causes mulit-queue lockless semantics to be preserved as the call passes through the virtual device.

(First: apologies for my late reply; your emails doesn't get through to me for some reason.)

So does this mean that it is OK to use LLTX for virtual devices? My virtual device has zero queue length (no transmit queue), but since it calls dev_queue_xmit for its slaves, I still get recursive locking if I don't set LLTX (just like vlan and bonding does).