* [PATCH net 1/2] net/tls: Protect from calling tls_dev_del for TLS RX twice
@ 2020-11-17 20:33 Saeed Mahameed
2020-11-17 20:33 ` [PATCH net 2/2] net: Call skb destructor on NAPI_GRO_FREE_STOLEN_HEAD Saeed Mahameed
2020-11-19 1:13 ` [PATCH net 1/2] net/tls: Protect from calling tls_dev_del for TLS RX twice Jakub Kicinski
0 siblings, 2 replies; 9+ messages in thread
From: Saeed Mahameed @ 2020-11-17 20:33 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, David S. Miller, Maxim Mikityanskiy, Saeed Mahameed
From: Maxim Mikityanskiy <maximmi@mellanox.com>
tls_device_offload_cleanup_rx doesn't clear tls_ctx->netdev after
calling tls_dev_del if TLX TX offload is also enabled. Clearing
tls_ctx->netdev gets postponed until tls_device_gc_task. It leaves a
time frame when tls_device_down may get called and call tls_dev_del for
RX one extra time, confusing the driver, which may lead to a crash.
This patch corrects this racy behavior by adding a flag to prevent
tls_device_down from calling tls_dev_del the second time.
Fixes: e8f69799810c ("net/tls: Add generic NIC offload infrastructure")
Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
---
For -stable: 5.3
include/net/tls.h | 1 +
net/tls/tls_device.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/net/tls.h b/include/net/tls.h
index baf1e99d8193..a0deddfde412 100644
--- a/include/net/tls.h
+++ b/include/net/tls.h
@@ -199,6 +199,7 @@ enum tls_context_flags {
* to be atomic.
*/
TLS_TX_SYNC_SCHED = 1,
+ TLS_RX_DEV_RELEASED = 2,
};
struct cipher_context {
diff --git a/net/tls/tls_device.c b/net/tls/tls_device.c
index cec86229a6a0..b2261caac6be 100644
--- a/net/tls/tls_device.c
+++ b/net/tls/tls_device.c
@@ -1241,6 +1241,7 @@ void tls_device_offload_cleanup_rx(struct sock *sk)
netdev->tlsdev_ops->tls_dev_del(netdev, tls_ctx,
TLS_OFFLOAD_CTX_DIR_RX);
+ set_bit(TLS_RX_DEV_RELEASED, &tls_ctx->flags);
if (tls_ctx->tx_conf != TLS_HW) {
dev_put(netdev);
@@ -1274,7 +1275,7 @@ static int tls_device_down(struct net_device *netdev)
if (ctx->tx_conf == TLS_HW)
netdev->tlsdev_ops->tls_dev_del(netdev, ctx,
TLS_OFFLOAD_CTX_DIR_TX);
- if (ctx->rx_conf == TLS_HW)
+ if (ctx->rx_conf == TLS_HW && !test_bit(TLS_RX_DEV_RELEASED, &ctx->flags))
netdev->tlsdev_ops->tls_dev_del(netdev, ctx,
TLS_OFFLOAD_CTX_DIR_RX);
WRITE_ONCE(ctx->netdev, NULL);
--
2.26.2
^ permalink raw reply related [flat|nested] 9+ messages in thread
* [PATCH net 2/2] net: Call skb destructor on NAPI_GRO_FREE_STOLEN_HEAD
2020-11-17 20:33 [PATCH net 1/2] net/tls: Protect from calling tls_dev_del for TLS RX twice Saeed Mahameed
@ 2020-11-17 20:33 ` Saeed Mahameed
2020-11-18 19:22 ` Jakub Kicinski
2020-11-19 1:13 ` [PATCH net 1/2] net/tls: Protect from calling tls_dev_del for TLS RX twice Jakub Kicinski
1 sibling, 1 reply; 9+ messages in thread
From: Saeed Mahameed @ 2020-11-17 20:33 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, David S. Miller, Maxim Mikityanskiy, Tariq Toukan,
Saeed Mahameed
From: Maxim Mikityanskiy <maximmi@mellanox.com>
All GRO flows except one call skb->destructor, however, GRO_MERGED_FREE
doesn't do it in case of NAPI_GRO_FREE_STOLEN_HEAD. For better
consistency and to add resiliency against the drivers that may pass SKBs
with a destructor, this patch changes napi_skb_free_stolen_head to use
skb_release_head_state, which should perform all the needed cleanups,
including a call to the destructor. This way the code of GRO_MERGED_FREE
becomes similar to kfree_skb_partial.
Fixes: e44699d2c280 ("net: handle NAPI_GRO_FREE_STOLEN_HEAD case also in napi_frags_finish()")
Fixes: d7e8883cfcf4 ("net: make GRO aware of skb->head_frag")
Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
---
For -stable: 5.4
net/core/dev.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 82dc6b48e45f..85dcc7f19902 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -6048,8 +6048,7 @@ EXPORT_SYMBOL(gro_find_complete_by_type);
static void napi_skb_free_stolen_head(struct sk_buff *skb)
{
- skb_dst_drop(skb);
- skb_ext_put(skb);
+ skb_release_head_state(skb);
kmem_cache_free(skbuff_head_cache, skb);
}
--
2.26.2
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH net 2/2] net: Call skb destructor on NAPI_GRO_FREE_STOLEN_HEAD
2020-11-17 20:33 ` [PATCH net 2/2] net: Call skb destructor on NAPI_GRO_FREE_STOLEN_HEAD Saeed Mahameed
@ 2020-11-18 19:22 ` Jakub Kicinski
2020-11-18 20:02 ` Eric Dumazet
0 siblings, 1 reply; 9+ messages in thread
From: Jakub Kicinski @ 2020-11-18 19:22 UTC (permalink / raw)
To: Saeed Mahameed
Cc: netdev, David S. Miller, Maxim Mikityanskiy, Tariq Toukan, Eric Dumazet
On Tue, 17 Nov 2020 12:33:55 -0800 Saeed Mahameed wrote:
> From: Maxim Mikityanskiy <maximmi@mellanox.com>
>
> All GRO flows except one call skb->destructor, however, GRO_MERGED_FREE
> doesn't do it in case of NAPI_GRO_FREE_STOLEN_HEAD. For better
> consistency and to add resiliency against the drivers that may pass SKBs
> with a destructor, this patch changes napi_skb_free_stolen_head to use
> skb_release_head_state, which should perform all the needed cleanups,
> including a call to the destructor. This way the code of GRO_MERGED_FREE
> becomes similar to kfree_skb_partial.
>
> Fixes: e44699d2c280 ("net: handle NAPI_GRO_FREE_STOLEN_HEAD case also in napi_frags_finish()")
> Fixes: d7e8883cfcf4 ("net: make GRO aware of skb->head_frag")
> Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com>
> Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
CC Eric for GRO expertise.
Makes sense to me, but do you still need "net/mlx5e: Fix refcount leak
on kTLS RX resync" even with this applied?
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 82dc6b48e45f..85dcc7f19902 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -6048,8 +6048,7 @@ EXPORT_SYMBOL(gro_find_complete_by_type);
>
> static void napi_skb_free_stolen_head(struct sk_buff *skb)
> {
> - skb_dst_drop(skb);
> - skb_ext_put(skb);
> + skb_release_head_state(skb);
> kmem_cache_free(skbuff_head_cache, skb);
> }
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH net 2/2] net: Call skb destructor on NAPI_GRO_FREE_STOLEN_HEAD
2020-11-18 19:22 ` Jakub Kicinski
@ 2020-11-18 20:02 ` Eric Dumazet
2020-11-18 20:14 ` Jakub Kicinski
0 siblings, 1 reply; 9+ messages in thread
From: Eric Dumazet @ 2020-11-18 20:02 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Saeed Mahameed, netdev, David S. Miller, Maxim Mikityanskiy,
Tariq Toukan
On Wed, Nov 18, 2020 at 8:22 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Tue, 17 Nov 2020 12:33:55 -0800 Saeed Mahameed wrote:
> > From: Maxim Mikityanskiy <maximmi@mellanox.com>
> >
> > All GRO flows except one call skb->destructor, however, GRO_MERGED_FREE
> > doesn't do it in case of NAPI_GRO_FREE_STOLEN_HEAD. For better
> > consistency and to add resiliency against the drivers that may pass SKBs
> > with a destructor, this patch changes napi_skb_free_stolen_head to use
> > skb_release_head_state, which should perform all the needed cleanups,
> > including a call to the destructor. This way the code of GRO_MERGED_FREE
> > becomes similar to kfree_skb_partial.
> >
> > Fixes: e44699d2c280 ("net: handle NAPI_GRO_FREE_STOLEN_HEAD case also in napi_frags_finish()")
> > Fixes: d7e8883cfcf4 ("net: make GRO aware of skb->head_frag")
> > Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com>
> > Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
> > Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
>
> CC Eric for GRO expertise.
Thanks for CCing me.
Since when drivers can pass funny skbs with destructors ???
Can we please stop adding more cycles to _already_ expensive GRO ?
>
> Makes sense to me, but do you still need "net/mlx5e: Fix refcount leak
> on kTLS RX resync" even with this applied?
>
> > diff --git a/net/core/dev.c b/net/core/dev.c
> > index 82dc6b48e45f..85dcc7f19902 100644
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -6048,8 +6048,7 @@ EXPORT_SYMBOL(gro_find_complete_by_type);
> >
> > static void napi_skb_free_stolen_head(struct sk_buff *skb)
> > {
> > - skb_dst_drop(skb);
> > - skb_ext_put(skb);
> > + skb_release_head_state(skb);
> > kmem_cache_free(skbuff_head_cache, skb);
> > }
> >
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH net 2/2] net: Call skb destructor on NAPI_GRO_FREE_STOLEN_HEAD
2020-11-18 20:02 ` Eric Dumazet
@ 2020-11-18 20:14 ` Jakub Kicinski
2020-11-18 20:21 ` Eric Dumazet
0 siblings, 1 reply; 9+ messages in thread
From: Jakub Kicinski @ 2020-11-18 20:14 UTC (permalink / raw)
To: Eric Dumazet
Cc: Saeed Mahameed, netdev, David S. Miller, Maxim Mikityanskiy,
Tariq Toukan
On Wed, 18 Nov 2020 21:02:29 +0100 Eric Dumazet wrote:
> On Wed, Nov 18, 2020 at 8:22 PM Jakub Kicinski <kuba@kernel.org> wrote:
> >
> > On Tue, 17 Nov 2020 12:33:55 -0800 Saeed Mahameed wrote:
> > > From: Maxim Mikityanskiy <maximmi@mellanox.com>
> > >
> > > All GRO flows except one call skb->destructor, however, GRO_MERGED_FREE
> > > doesn't do it in case of NAPI_GRO_FREE_STOLEN_HEAD. For better
> > > consistency and to add resiliency against the drivers that may pass SKBs
> > > with a destructor, this patch changes napi_skb_free_stolen_head to use
> > > skb_release_head_state, which should perform all the needed cleanups,
> > > including a call to the destructor. This way the code of GRO_MERGED_FREE
> > > becomes similar to kfree_skb_partial.
> > >
> > > Fixes: e44699d2c280 ("net: handle NAPI_GRO_FREE_STOLEN_HEAD case also in napi_frags_finish()")
> > > Fixes: d7e8883cfcf4 ("net: make GRO aware of skb->head_frag")
> > > Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com>
> > > Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
> > > Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
> >
> > CC Eric for GRO expertise.
>
> Thanks for CCing me.
>
> Since when drivers can pass funny skbs with destructors ???
>
> Can we please stop adding more cycles to _already_ expensive GRO ?
I don't think they do that today much (save for the ktls optimization
in mlx5 Maxim is fixing separately). But I believe the idea of early
demux in XDP had been floated in the past.
If we don't want that to happen we should document it (stating the
obvious).
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH net 2/2] net: Call skb destructor on NAPI_GRO_FREE_STOLEN_HEAD
2020-11-18 20:14 ` Jakub Kicinski
@ 2020-11-18 20:21 ` Eric Dumazet
2020-11-25 22:11 ` Saeed Mahameed
0 siblings, 1 reply; 9+ messages in thread
From: Eric Dumazet @ 2020-11-18 20:21 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Saeed Mahameed, netdev, David S. Miller, Maxim Mikityanskiy,
Tariq Toukan
On Wed, Nov 18, 2020 at 9:14 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Wed, 18 Nov 2020 21:02:29 +0100 Eric Dumazet wrote:
> > On Wed, Nov 18, 2020 at 8:22 PM Jakub Kicinski <kuba@kernel.org> wrote:
> > >
> > > On Tue, 17 Nov 2020 12:33:55 -0800 Saeed Mahameed wrote:
> > > > From: Maxim Mikityanskiy <maximmi@mellanox.com>
> > > >
> > > > All GRO flows except one call skb->destructor, however, GRO_MERGED_FREE
> > > > doesn't do it in case of NAPI_GRO_FREE_STOLEN_HEAD. For better
> > > > consistency and to add resiliency against the drivers that may pass SKBs
> > > > with a destructor, this patch changes napi_skb_free_stolen_head to use
> > > > skb_release_head_state, which should perform all the needed cleanups,
> > > > including a call to the destructor. This way the code of GRO_MERGED_FREE
> > > > becomes similar to kfree_skb_partial.
> > > >
> > > > Fixes: e44699d2c280 ("net: handle NAPI_GRO_FREE_STOLEN_HEAD case also in napi_frags_finish()")
> > > > Fixes: d7e8883cfcf4 ("net: make GRO aware of skb->head_frag")
> > > > Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com>
> > > > Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
> > > > Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
> > >
> > > CC Eric for GRO expertise.
> >
> > Thanks for CCing me.
> >
> > Since when drivers can pass funny skbs with destructors ???
> >
> > Can we please stop adding more cycles to _already_ expensive GRO ?
>
> I don't think they do that today much (save for the ktls optimization
> in mlx5 Maxim is fixing separately). But I believe the idea of early
> demux in XDP had been floated in the past.
>
> If we don't want that to happen we should document it (stating the
> obvious).
This is a patch targeting the net tree, with Fixes: tag pretending
this is an old bug.
How can we possibly merge two skbs if they have destructors ?
We do not make sure it is even possible.
Many destructors track skb->truesize against a socket wmem_alloc or rmem_alloc,
this stuff can not possibly work, unless stronger checks in GRO, since
GRO changes skb->truesize
without checking skb->destructor.
If skb has a destructor, just bypass GRO completely, this is the only
thing we can do.
This would be quite unfortunate to add such a check "just because
someone tries to fool us"
diff --git a/net/core/dev.c b/net/core/dev.c
index 4bfdcd6b20e8836e2884c51c6ce349ed54130bfa..76f0a627b6a1ee02339a724ecb6e4dbade80501b
100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5920,7 +5920,7 @@ static enum gro_result dev_gro_receive(struct
napi_struct *napi, struct sk_buff
int same_flow;
int grow;
- if (netif_elide_gro(skb->dev))
+ if (netif_elide_gro(skb->dev) || skb->destructor)
goto normal;
gro_head = gro_list_prepare(napi, skb);
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH net 1/2] net/tls: Protect from calling tls_dev_del for TLS RX twice
2020-11-17 20:33 [PATCH net 1/2] net/tls: Protect from calling tls_dev_del for TLS RX twice Saeed Mahameed
2020-11-17 20:33 ` [PATCH net 2/2] net: Call skb destructor on NAPI_GRO_FREE_STOLEN_HEAD Saeed Mahameed
@ 2020-11-19 1:13 ` Jakub Kicinski
2020-11-25 22:14 ` Saeed Mahameed
1 sibling, 1 reply; 9+ messages in thread
From: Jakub Kicinski @ 2020-11-19 1:13 UTC (permalink / raw)
To: Saeed Mahameed; +Cc: netdev, David S. Miller, Maxim Mikityanskiy
On Tue, 17 Nov 2020 12:33:54 -0800 Saeed Mahameed wrote:
> From: Maxim Mikityanskiy <maximmi@mellanox.com>
>
> tls_device_offload_cleanup_rx doesn't clear tls_ctx->netdev after
> calling tls_dev_del if TLX TX offload is also enabled. Clearing
> tls_ctx->netdev gets postponed until tls_device_gc_task. It leaves a
> time frame when tls_device_down may get called and call tls_dev_del for
> RX one extra time, confusing the driver, which may lead to a crash.
>
> This patch corrects this racy behavior by adding a flag to prevent
> tls_device_down from calling tls_dev_del the second time.
>
> Fixes: e8f69799810c ("net/tls: Add generic NIC offload infrastructure")
> Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com>
> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
> ---
> For -stable: 5.3
>
> include/net/tls.h | 1 +
> net/tls/tls_device.c | 3 ++-
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/include/net/tls.h b/include/net/tls.h
> index baf1e99d8193..a0deddfde412 100644
> --- a/include/net/tls.h
> +++ b/include/net/tls.h
> @@ -199,6 +199,7 @@ enum tls_context_flags {
> * to be atomic.
> */
> TLS_TX_SYNC_SCHED = 1,
Please add a comment here explaining that this bit is set when device
state is partially released, and ctx->netdev cannot be cleared but RX
side was already removed.
> + TLS_RX_DEV_RELEASED = 2,
> };
>
> struct cipher_context {
> diff --git a/net/tls/tls_device.c b/net/tls/tls_device.c
> index cec86229a6a0..b2261caac6be 100644
> --- a/net/tls/tls_device.c
> +++ b/net/tls/tls_device.c
> @@ -1241,6 +1241,7 @@ void tls_device_offload_cleanup_rx(struct sock *sk)
>
> netdev->tlsdev_ops->tls_dev_del(netdev, tls_ctx,
> TLS_OFFLOAD_CTX_DIR_RX);
> + set_bit(TLS_RX_DEV_RELEASED, &tls_ctx->flags);
Would the semantics of the bit be clearer if we only set the bit in an
else branch below and renamed it TLS_RX_DEV_CLOSED?
Otherwise it could be confusing to the reader that his bit is only set
here but not in tls_device_down().
> if (tls_ctx->tx_conf != TLS_HW) {
> dev_put(netdev);
> @@ -1274,7 +1275,7 @@ static int tls_device_down(struct net_device *netdev)
> if (ctx->tx_conf == TLS_HW)
> netdev->tlsdev_ops->tls_dev_del(netdev, ctx,
> TLS_OFFLOAD_CTX_DIR_TX);
> - if (ctx->rx_conf == TLS_HW)
> + if (ctx->rx_conf == TLS_HW && !test_bit(TLS_RX_DEV_RELEASED, &ctx->flags))
> netdev->tlsdev_ops->tls_dev_del(netdev, ctx,
> TLS_OFFLOAD_CTX_DIR_RX);
> WRITE_ONCE(ctx->netdev, NULL);
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH net 2/2] net: Call skb destructor on NAPI_GRO_FREE_STOLEN_HEAD
2020-11-18 20:21 ` Eric Dumazet
@ 2020-11-25 22:11 ` Saeed Mahameed
0 siblings, 0 replies; 9+ messages in thread
From: Saeed Mahameed @ 2020-11-25 22:11 UTC (permalink / raw)
To: Eric Dumazet, Jakub Kicinski
Cc: netdev, David S. Miller, Maxim Mikityanskiy, Tariq Toukan
On Wed, 2020-11-18 at 21:21 +0100, Eric Dumazet wrote:
> On Wed, Nov 18, 2020 at 9:14 PM Jakub Kicinski <kuba@kernel.org>
> wrote:
> > On Wed, 18 Nov 2020 21:02:29 +0100 Eric Dumazet wrote:
> > > On Wed, Nov 18, 2020 at 8:22 PM Jakub Kicinski <kuba@kernel.org>
> > > wrote:
> > > > On Tue, 17 Nov 2020 12:33:55 -0800 Saeed Mahameed wrote:
> > > > > From: Maxim Mikityanskiy <maximmi@mellanox.com>
> > > > >
> > > > > All GRO flows except one call skb->destructor, however,
> > > > > GRO_MERGED_FREE
> > > > > doesn't do it in case of NAPI_GRO_FREE_STOLEN_HEAD. For
> > > > > better
> > > > > consistency and to add resiliency against the drivers that
> > > > > may pass SKBs
> > > > > with a destructor, this patch changes
> > > > > napi_skb_free_stolen_head to use
> > > > > skb_release_head_state, which should perform all the needed
> > > > > cleanups,
> > > > > including a call to the destructor. This way the code of
> > > > > GRO_MERGED_FREE
> > > > > becomes similar to kfree_skb_partial.
> > > > >
> > > > > Fixes: e44699d2c280 ("net: handle NAPI_GRO_FREE_STOLEN_HEAD
> > > > > case also in napi_frags_finish()")
> > > > > Fixes: d7e8883cfcf4 ("net: make GRO aware of skb->head_frag")
> > > > > Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com>
> > > > > Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
> > > > > Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
> > > >
> > > > CC Eric for GRO expertise.
> > >
> > > Thanks for CCing me.
> > >
> > > Since when drivers can pass funny skbs with destructors ???
> > >
> > > Can we please stop adding more cycles to _already_ expensive GRO
> > > ?
> >
> > I don't think they do that today much (save for the ktls
> > optimization
> > in mlx5 Maxim is fixing separately). But I believe the idea of
> > early
> > demux in XDP had been floated in the past.
> >
> > If we don't want that to happen we should document it (stating the
> > obvious).
>
> This is a patch targeting the net tree, with Fixes: tag pretending
> this is an old bug.
>
> How can we possibly merge two skbs if they have destructors ?
>
> We do not make sure it is even possible.
>
> Many destructors track skb->truesize against a socket wmem_alloc or
> rmem_alloc,
> this stuff can not possibly work, unless stronger checks in GRO,
> since
> GRO changes skb->truesize
> without checking skb->destructor.
>
> If skb has a destructor, just bypass GRO completely, this is the only
> thing we can do.
> This would be quite unfortunate to add such a check "just because
> someone tries to fool us"
>
Thanks Eric !!
We don't actually need this patch, as the kTLS SKBs are handled locally
in the drivers, I think we don't need to add any extra check in the
datapath and just enforce the policy somehow with debug macros
maybe WARN_ONE_ONCE()
I will drop this patch, but the XDP folks who are going to implement
XDP early demux should take care of this themselves.
> diff --git a/net/core/dev.c b/net/core/dev.c
> index
> 4bfdcd6b20e8836e2884c51c6ce349ed54130bfa..76f0a627b6a1ee02339a724ecb6
> e4dbade80501b
> 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -5920,7 +5920,7 @@ static enum gro_result dev_gro_receive(struct
> napi_struct *napi, struct sk_buff
> int same_flow;
> int grow;
>
> - if (netif_elide_gro(skb->dev))
> + if (netif_elide_gro(skb->dev) || skb->destructor)
> goto normal;
>
> gro_head = gro_list_prepare(napi, skb);
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH net 1/2] net/tls: Protect from calling tls_dev_del for TLS RX twice
2020-11-19 1:13 ` [PATCH net 1/2] net/tls: Protect from calling tls_dev_del for TLS RX twice Jakub Kicinski
@ 2020-11-25 22:14 ` Saeed Mahameed
0 siblings, 0 replies; 9+ messages in thread
From: Saeed Mahameed @ 2020-11-25 22:14 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev, David S. Miller, Maxim Mikityanskiy
On Wed, 2020-11-18 at 17:13 -0800, Jakub Kicinski wrote:
> On Tue, 17 Nov 2020 12:33:54 -0800 Saeed Mahameed wrote:
> > From: Maxim Mikityanskiy <maximmi@mellanox.com>
> >
> > tls_device_offload_cleanup_rx doesn't clear tls_ctx->netdev after
> > calling tls_dev_del if TLX TX offload is also enabled. Clearing
> > tls_ctx->netdev gets postponed until tls_device_gc_task. It leaves
> > a
> > time frame when tls_device_down may get called and call tls_dev_del
> > for
> > RX one extra time, confusing the driver, which may lead to a crash.
> >
> > This patch corrects this racy behavior by adding a flag to prevent
> > tls_device_down from calling tls_dev_del the second time.
> >
> > Fixes: e8f69799810c ("net/tls: Add generic NIC offload
> > infrastructure")
> > Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com>
> > Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
> > ---
> > For -stable: 5.3
> >
> > include/net/tls.h | 1 +
> > net/tls/tls_device.c | 3 ++-
> > 2 files changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/net/tls.h b/include/net/tls.h
> > index baf1e99d8193..a0deddfde412 100644
> > --- a/include/net/tls.h
> > +++ b/include/net/tls.h
> > @@ -199,6 +199,7 @@ enum tls_context_flags {
> > * to be atomic.
> > */
> > TLS_TX_SYNC_SCHED = 1,
>
> Please add a comment here explaining that this bit is set when device
> state is partially released, and ctx->netdev cannot be cleared but RX
> side was already removed.
>
> > + TLS_RX_DEV_RELEASED = 2,
> > };
> >
> > struct cipher_context {
> > diff --git a/net/tls/tls_device.c b/net/tls/tls_device.c
> > index cec86229a6a0..b2261caac6be 100644
> > --- a/net/tls/tls_device.c
> > +++ b/net/tls/tls_device.c
> > @@ -1241,6 +1241,7 @@ void tls_device_offload_cleanup_rx(struct
> > sock *sk)
> >
> > netdev->tlsdev_ops->tls_dev_del(netdev, tls_ctx,
> > TLS_OFFLOAD_CTX_DIR_RX);
> > + set_bit(TLS_RX_DEV_RELEASED, &tls_ctx->flags);
>
> Would the semantics of the bit be clearer if we only set the bit in
> an
> else branch below and renamed it TLS_RX_DEV_CLOSED?
>
> Otherwise it could be confusing to the reader that his bit is only
> set
> here but not in tls_device_down().
>
Thanks Jakub, Maxim handled both comments, I will send V2 and drop the
other patch !
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-11-25 22:14 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-17 20:33 [PATCH net 1/2] net/tls: Protect from calling tls_dev_del for TLS RX twice Saeed Mahameed
2020-11-17 20:33 ` [PATCH net 2/2] net: Call skb destructor on NAPI_GRO_FREE_STOLEN_HEAD Saeed Mahameed
2020-11-18 19:22 ` Jakub Kicinski
2020-11-18 20:02 ` Eric Dumazet
2020-11-18 20:14 ` Jakub Kicinski
2020-11-18 20:21 ` Eric Dumazet
2020-11-25 22:11 ` Saeed Mahameed
2020-11-19 1:13 ` [PATCH net 1/2] net/tls: Protect from calling tls_dev_del for TLS RX twice Jakub Kicinski
2020-11-25 22:14 ` Saeed Mahameed
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).