* Re: [PATCH v2 nf 1/4] netfilter: flowtable: fix excessive hw offload attempts after failure
From: Pablo Neira Ayuso @ 2022-05-16 10:59 UTC (permalink / raw)
To: Felix Fietkau; +Cc: netdev, netfilter-devel
In-Reply-To: <20220509122616.65449-1-nbd@nbd.name>
Series applied to nf.git
^ permalink raw reply
* Re: [PATCH net v2] netfilter: nf_flow_table: fix teardown flow timeout
From: Pablo Neira Ayuso @ 2022-05-16 10:56 UTC (permalink / raw)
To: Oz Shlomo
Cc: Sven Auhagen, Felix Fietkau, netdev, netfilter-devel,
Florian Westphal, Paul Blakey
In-Reply-To: <20220512182803.6353-1-ozsh@nvidia.com>
On Thu, May 12, 2022 at 09:28:03PM +0300, Oz Shlomo wrote:
> Connections leaving the established state (due to RST / FIN TCP packets)
> set the flow table teardown flag. The packet path continues to set lower
> timeout value as per the new TCP state but the offload flag remains set.
>
> Hence, the conntrack garbage collector may race to undo the timeout
> adjustment of the packet path, leaving the conntrack entry in place with
> the internal offload timeout (one day).
>
> Avoid ct gc timeout overwrite by flagging teared down flowtable
> connections.
>
> On the nftables side we only need to allow established TCP connections to
> create a flow offload entry. Since we can not guaruantee that
> flow_offload_teardown is called by a TCP FIN packet we also need to make
> sure that flow_offload_fixup_ct is also called in flow_offload_del
> and only fixes up established TCP connections.
[...]
> diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
> index 0164e5f522e8..324fdb62c08b 100644
> --- a/net/netfilter/nf_conntrack_core.c
> +++ b/net/netfilter/nf_conntrack_core.c
> @@ -1477,7 +1477,8 @@ static void gc_worker(struct work_struct *work)
> tmp = nf_ct_tuplehash_to_ctrack(h);
>
> if (test_bit(IPS_OFFLOAD_BIT, &tmp->status)) {
> - nf_ct_offload_timeout(tmp);
Hm, it is the trick to avoid checking for IPS_OFFLOAD from the packet
path that triggers the race, ie. nf_ct_is_expired()
The flowtable ct fixup races with conntrack gc collector.
Clearing IPS_OFFLOAD might result in offloading the entry again for
the closing packets.
Probably clear IPS_OFFLOAD from teardown, and skip offload if flow is
in a TCP state that represent closure?
if (unlikely(!tcph || tcph->fin || tcph->rst))
goto out;
this is already the intention in the existing code.
If this does work, could you keep IPS_OFFLOAD_TEARDOWN_BIT internal,
ie. no in uapi? Define it at include/net/netfilter/nf_conntrack.h and
add a comment regarding this to avoid an overlap in the future.
> + if (!test_bit(IPS_OFFLOAD_TEARDOWN_BIT, &tmp->status))
> + nf_ct_offload_timeout(tmp);
> continue;
> }
>
> diff --git a/net/netfilter/nf_flow_table_core.c b/net/netfilter/nf_flow_table_core.c
> index 3db256da919b..aaed1a244013 100644
> --- a/net/netfilter/nf_flow_table_core.c
> +++ b/net/netfilter/nf_flow_table_core.c
> @@ -177,14 +177,8 @@ int flow_offload_route_init(struct flow_offload *flow,
> }
> EXPORT_SYMBOL_GPL(flow_offload_route_init);
>
> -static void flow_offload_fixup_tcp(struct ip_ct_tcp *tcp)
> -{
> - tcp->state = TCP_CONNTRACK_ESTABLISHED;
> - tcp->seen[0].td_maxwin = 0;
> - tcp->seen[1].td_maxwin = 0;
> -}
>
> -static void flow_offload_fixup_ct_timeout(struct nf_conn *ct)
> +static void flow_offload_fixup_ct(struct nf_conn *ct)
> {
> struct net *net = nf_ct_net(ct);
> int l4num = nf_ct_protonum(ct);
> @@ -192,8 +186,12 @@ static void flow_offload_fixup_ct_timeout(struct nf_conn *ct)
>
> if (l4num == IPPROTO_TCP) {
> struct nf_tcp_net *tn = nf_tcp_pernet(net);
> + struct ip_ct_tcp *tcp = &ct->proto.tcp;
> +
> + tcp->seen[0].td_maxwin = 0;
> + tcp->seen[1].td_maxwin = 0;
>
> - timeout = tn->timeouts[TCP_CONNTRACK_ESTABLISHED];
> + timeout = tn->timeouts[ct->proto.tcp.state];
> timeout -= tn->offload_timeout;
> } else if (l4num == IPPROTO_UDP) {
> struct nf_udp_net *tn = nf_udp_pernet(net);
> @@ -211,18 +209,6 @@ static void flow_offload_fixup_ct_timeout(struct nf_conn *ct)
> WRITE_ONCE(ct->timeout, nfct_time_stamp + timeout);
> }
>
> -static void flow_offload_fixup_ct_state(struct nf_conn *ct)
> -{
> - if (nf_ct_protonum(ct) == IPPROTO_TCP)
> - flow_offload_fixup_tcp(&ct->proto.tcp);
> -}
> -
> -static void flow_offload_fixup_ct(struct nf_conn *ct)
> -{
> - flow_offload_fixup_ct_state(ct);
> - flow_offload_fixup_ct_timeout(ct);
> -}
> -
> static void flow_offload_route_release(struct flow_offload *flow)
> {
> nft_flow_dst_release(flow, FLOW_OFFLOAD_DIR_ORIGINAL);
> @@ -353,6 +339,10 @@ static inline bool nf_flow_has_expired(const struct flow_offload *flow)
> static void flow_offload_del(struct nf_flowtable *flow_table,
> struct flow_offload *flow)
> {
> + struct nf_conn *ct = flow->ct;
> +
> + set_bit(IPS_OFFLOAD_TEARDOWN_BIT, &flow->ct->status);
> +
> rhashtable_remove_fast(&flow_table->rhashtable,
> &flow->tuplehash[FLOW_OFFLOAD_DIR_ORIGINAL].node,
> nf_flow_offload_rhash_params);
> @@ -360,12 +350,11 @@ static void flow_offload_del(struct nf_flowtable *flow_table,
> &flow->tuplehash[FLOW_OFFLOAD_DIR_REPLY].node,
> nf_flow_offload_rhash_params);
>
> - clear_bit(IPS_OFFLOAD_BIT, &flow->ct->status);
> -
> if (nf_flow_has_expired(flow))
> - flow_offload_fixup_ct(flow->ct);
> - else
> - flow_offload_fixup_ct_timeout(flow->ct);
> + flow_offload_fixup_ct(ct);
Very unlikely, but race might still happen between fixup and
clear IPS_OFFLOAD_BIT with gc below?
Without checking from the packet path, the conntrack gc might race to
refresh the timeout, I don't see a 100% race free solution.
Probably update the nf_ct_offload_timeout to a shorter value than a
day would mitigate this issue too.
> + clear_bit(IPS_OFFLOAD_BIT, &ct->status);
> + clear_bit(IPS_OFFLOAD_TEARDOWN_BIT, &ct->status);
>
> flow_offload_free(flow);
> }
> @@ -373,8 +362,9 @@ static void flow_offload_del(struct nf_flowtable *flow_table,
> void flow_offload_teardown(struct flow_offload *flow)
> {
> set_bit(NF_FLOW_TEARDOWN, &flow->flags);
> + set_bit(IPS_OFFLOAD_TEARDOWN_BIT, &flow->ct->status);
>
> - flow_offload_fixup_ct_state(flow->ct);
> + flow_offload_fixup_ct(flow->ct);
> }
> EXPORT_SYMBOL_GPL(flow_offload_teardown);
>
> diff --git a/net/netfilter/nft_flow_offload.c b/net/netfilter/nft_flow_offload.c
> index 900d48c810a1..9cc3ea08eb3a 100644
> --- a/net/netfilter/nft_flow_offload.c
> +++ b/net/netfilter/nft_flow_offload.c
> @@ -295,6 +295,8 @@ static void nft_flow_offload_eval(const struct nft_expr *expr,
> sizeof(_tcph), &_tcph);
> if (unlikely(!tcph || tcph->fin || tcph->rst))
> goto out;
> + if (unlikely(!nf_conntrack_tcp_established(ct)))
> + goto out;
This chunk is not required, from ruleset users can do
... ct status assured ...
instead.
> break;
> case IPPROTO_UDP:
> break;
> --
> 1.8.3.1
>
^ permalink raw reply
* [net-next PATCH V2] octeontx2-pf: Add support for adaptive interrupt coalescing
From: Suman Ghosh @ 2022-05-16 10:53 UTC (permalink / raw)
To: davem, edumazet, kuba, pabeni, sgoutham, sbhatta, gakula,
Sunil.Goutham, hkelam, colin.king, netdev
Cc: Suman Ghosh
Added support for adaptive IRQ coalescing. It uses net_dim
algorithm to find the suitable delay/IRQ count based on the
current packet rate.
Signed-off-by: Suman Ghosh <sumang@marvell.com>
Reviewed-by: Sunil Kovvuri Goutham <sgoutham@marvell.com>
---
Changes since V1
- Addressed review comments.
.../net/ethernet/marvell/octeontx2/Kconfig | 1 +
.../marvell/octeontx2/nic/otx2_common.c | 5 ---
.../marvell/octeontx2/nic/otx2_common.h | 10 +++++
.../marvell/octeontx2/nic/otx2_ethtool.c | 38 +++++++++++++++++--
.../ethernet/marvell/octeontx2/nic/otx2_pf.c | 22 +++++++++++
.../marvell/octeontx2/nic/otx2_txrx.c | 23 +++++++++++
.../marvell/octeontx2/nic/otx2_txrx.h | 1 +
7 files changed, 92 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/marvell/octeontx2/Kconfig b/drivers/net/ethernet/marvell/octeontx2/Kconfig
index 639893d87055..e1036b0eb6b1 100644
--- a/drivers/net/ethernet/marvell/octeontx2/Kconfig
+++ b/drivers/net/ethernet/marvell/octeontx2/Kconfig
@@ -33,6 +33,7 @@ config OCTEONTX2_PF
select OCTEONTX2_MBOX
select NET_DEVLINK
depends on (64BIT && COMPILE_TEST) || ARM64
+ select DIMLIB
depends on PCI
depends on PTP_1588_CLOCK_OPTIONAL
help
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
index b9d7601138ca..fb8db5888d2f 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
@@ -97,11 +97,6 @@ void otx2_get_dev_stats(struct otx2_nic *pfvf)
{
struct otx2_dev_stats *dev_stats = &pfvf->hw.dev_stats;
-#define OTX2_GET_RX_STATS(reg) \
- otx2_read64(pfvf, NIX_LF_RX_STATX(reg))
-#define OTX2_GET_TX_STATS(reg) \
- otx2_read64(pfvf, NIX_LF_TX_STATX(reg))
-
dev_stats->rx_bytes = OTX2_GET_RX_STATS(RX_OCTS);
dev_stats->rx_drops = OTX2_GET_RX_STATS(RX_DROP);
dev_stats->rx_bcast_frames = OTX2_GET_RX_STATS(RX_BCAST);
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
index c587c14ac2a3..ce2766317c0b 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
@@ -18,6 +18,7 @@
#include <net/pkt_cls.h>
#include <net/devlink.h>
#include <linux/time64.h>
+#include <linux/dim.h>
#include <mbox.h>
#include <npc.h>
@@ -54,6 +55,11 @@ enum arua_mapped_qtypes {
/* Send skid of 2000 packets required for CQ size of 4K CQEs. */
#define SEND_CQ_SKID 2000
+#define OTX2_GET_RX_STATS(reg) \
+ otx2_read64(pfvf, NIX_LF_RX_STATX(reg))
+#define OTX2_GET_TX_STATS(reg) \
+ otx2_read64(pfvf, NIX_LF_TX_STATX(reg))
+
struct otx2_lmt_info {
u64 lmt_addr;
u16 lmt_id;
@@ -351,6 +357,7 @@ struct otx2_nic {
#define OTX2_FLAG_TC_MATCHALL_EGRESS_ENABLED BIT_ULL(12)
#define OTX2_FLAG_TC_MATCHALL_INGRESS_ENABLED BIT_ULL(13)
#define OTX2_FLAG_DMACFLTR_SUPPORT BIT_ULL(14)
+#define OTX2_FLAG_ADPTV_INT_COAL_ENABLED BIT_ULL(16)
u64 flags;
u64 *cq_op_addr;
@@ -408,6 +415,9 @@ struct otx2_nic {
u8 pfc_en;
u8 *queue_to_pfc_map;
#endif
+
+ /* napi event count. It is needed for adaptive irq coalescing. */
+ u32 napi_events;
};
static inline bool is_otx2_lbkvf(struct pci_dev *pdev)
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c
index fc328de5345e..233c540ae0a7 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c
@@ -455,6 +455,14 @@ static int otx2_get_coalesce(struct net_device *netdev,
cmd->rx_max_coalesced_frames = hw->cq_ecount_wait;
cmd->tx_coalesce_usecs = hw->cq_time_wait;
cmd->tx_max_coalesced_frames = hw->cq_ecount_wait;
+ if ((pfvf->flags & OTX2_FLAG_ADPTV_INT_COAL_ENABLED) ==
+ OTX2_FLAG_ADPTV_INT_COAL_ENABLED) {
+ cmd->use_adaptive_rx_coalesce = 1;
+ cmd->use_adaptive_tx_coalesce = 1;
+ } else {
+ cmd->use_adaptive_rx_coalesce = 0;
+ cmd->use_adaptive_tx_coalesce = 0;
+ }
return 0;
}
@@ -466,11 +474,24 @@ static int otx2_set_coalesce(struct net_device *netdev,
{
struct otx2_nic *pfvf = netdev_priv(netdev);
struct otx2_hw *hw = &pfvf->hw;
+ u8 priv_coalesce_status;
int qidx;
if (!ec->rx_max_coalesced_frames || !ec->tx_max_coalesced_frames)
return 0;
+ /* Check and update coalesce status */
+ if ((pfvf->flags & OTX2_FLAG_ADPTV_INT_COAL_ENABLED) ==
+ OTX2_FLAG_ADPTV_INT_COAL_ENABLED) {
+ priv_coalesce_status = 1;
+ if (!ec->use_adaptive_rx_coalesce || !ec->use_adaptive_tx_coalesce)
+ pfvf->flags &= ~OTX2_FLAG_ADPTV_INT_COAL_ENABLED;
+ } else {
+ priv_coalesce_status = 0;
+ if (ec->use_adaptive_rx_coalesce || ec->use_adaptive_tx_coalesce)
+ pfvf->flags |= OTX2_FLAG_ADPTV_INT_COAL_ENABLED;
+ }
+
/* 'cq_time_wait' is 8bit and is in multiple of 100ns,
* so clamp the user given value to the range of 1 to 25usec.
*/
@@ -494,9 +515,9 @@ static int otx2_set_coalesce(struct net_device *netdev,
* so clamp the user given value to the range of 1 to 64k.
*/
ec->rx_max_coalesced_frames = clamp_t(u32, ec->rx_max_coalesced_frames,
- 1, U16_MAX);
+ 1, NAPI_POLL_WEIGHT);
ec->tx_max_coalesced_frames = clamp_t(u32, ec->tx_max_coalesced_frames,
- 1, U16_MAX);
+ 1, NAPI_POLL_WEIGHT);
/* Rx and Tx are mapped to same CQ, check which one
* is changed, if both then choose the min.
@@ -509,6 +530,17 @@ static int otx2_set_coalesce(struct net_device *netdev,
hw->cq_ecount_wait = min_t(u16, ec->rx_max_coalesced_frames,
ec->tx_max_coalesced_frames);
+ /* Reset 'cq_time_wait' and 'cq_ecount_wait' to
+ * default values if coalesce status changed from
+ * 'on' to 'off'.
+ */
+ if (priv_coalesce_status &&
+ ((pfvf->flags & OTX2_FLAG_ADPTV_INT_COAL_ENABLED) !=
+ OTX2_FLAG_ADPTV_INT_COAL_ENABLED)) {
+ hw->cq_time_wait = CQ_TIMER_THRESH_DEFAULT;
+ hw->cq_ecount_wait = CQ_CQE_THRESH_DEFAULT;
+ }
+
if (netif_running(netdev)) {
for (qidx = 0; qidx < pfvf->hw.cint_cnt; qidx++)
otx2_config_irq_coalescing(pfvf, qidx);
@@ -1230,7 +1262,7 @@ static int otx2_set_link_ksettings(struct net_device *netdev,
static const struct ethtool_ops otx2_ethtool_ops = {
.supported_coalesce_params = ETHTOOL_COALESCE_USECS |
- ETHTOOL_COALESCE_MAX_FRAMES,
+ ETHTOOL_COALESCE_MAX_FRAMES | ETHTOOL_COALESCE_USE_ADAPTIVE,
.supported_ring_params = ETHTOOL_RING_USE_RX_BUF_LEN |
ETHTOOL_RING_USE_CQE_SIZE,
.get_link = otx2_get_link,
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
index 53b2706d65a1..a7e919b81a2e 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
@@ -1254,6 +1254,7 @@ static irqreturn_t otx2_cq_intr_handler(int irq, void *cq_irq)
otx2_write64(pf, NIX_LF_CINTX_ENA_W1C(qidx), BIT_ULL(0));
/* Schedule NAPI */
+ pf->napi_events++;
napi_schedule_irqoff(&cq_poll->napi);
return IRQ_HANDLED;
@@ -1267,6 +1268,7 @@ static void otx2_disable_napi(struct otx2_nic *pf)
for (qidx = 0; qidx < pf->hw.cint_cnt; qidx++) {
cq_poll = &qset->napi[qidx];
+ cancel_work_sync(&cq_poll->dim.work);
napi_disable(&cq_poll->napi);
netif_napi_del(&cq_poll->napi);
}
@@ -1546,6 +1548,24 @@ static void otx2_do_set_rx_mode(struct otx2_nic *pf)
mutex_unlock(&pf->mbox.lock);
}
+static void otx2_dim_work(struct work_struct *w)
+{
+ struct dim_cq_moder cur_moder;
+ struct otx2_cq_poll *cq_poll;
+ struct otx2_nic *pfvf;
+ struct dim *dim;
+
+ dim = container_of(w, struct dim, work);
+ cur_moder = net_dim_get_rx_moderation(dim->mode, dim->profile_ix);
+ cq_poll = container_of(dim, struct otx2_cq_poll, dim);
+ pfvf = (struct otx2_nic *)cq_poll->dev;
+ pfvf->hw.cq_time_wait = (cur_moder.usec > CQ_TIMER_THRESH_MAX) ?
+ CQ_TIMER_THRESH_MAX : cur_moder.usec;
+ pfvf->hw.cq_ecount_wait = (cur_moder.pkts > NAPI_POLL_WEIGHT) ?
+ NAPI_POLL_WEIGHT : cur_moder.pkts;
+ dim->state = DIM_START_MEASURE;
+}
+
int otx2_open(struct net_device *netdev)
{
struct otx2_nic *pf = netdev_priv(netdev);
@@ -1612,6 +1632,8 @@ int otx2_open(struct net_device *netdev)
cq_poll->cq_ids[CQ_XDP] = CINT_INVALID_CQ;
cq_poll->dev = (void *)pf;
+ cq_poll->dim.mode = DIM_CQ_PERIOD_MODE_START_FROM_CQE;
+ INIT_WORK(&cq_poll->dim.work, otx2_dim_work);
netif_napi_add(netdev, &cq_poll->napi,
otx2_napi_handler, NAPI_POLL_WEIGHT);
napi_enable(&cq_poll->napi);
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c
index c26de15b2ac3..3baeafc40807 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c
@@ -484,6 +484,18 @@ static int otx2_tx_napi_handler(struct otx2_nic *pfvf,
return 0;
}
+static void otx2_adjust_adaptive_coalese(struct otx2_nic *pfvf, struct otx2_cq_poll *cq_poll)
+{
+ struct dim_sample dim_sample;
+ u64 rx_frames, rx_bytes;
+
+ rx_frames = OTX2_GET_RX_STATS(RX_BCAST) + OTX2_GET_RX_STATS(RX_MCAST) +
+ OTX2_GET_RX_STATS(RX_UCAST);
+ rx_bytes = OTX2_GET_RX_STATS(RX_OCTS);
+ dim_update_sample(pfvf->napi_events, rx_frames, rx_bytes, &dim_sample);
+ net_dim(&cq_poll->dim, dim_sample);
+}
+
int otx2_napi_handler(struct napi_struct *napi, int budget)
{
struct otx2_cq_queue *rx_cq = NULL;
@@ -521,6 +533,17 @@ int otx2_napi_handler(struct napi_struct *napi, int budget)
if (pfvf->flags & OTX2_FLAG_INTF_DOWN)
return workdone;
+ /* Check for adaptive interrupt coalesce */
+ if (workdone != 0 &&
+ ((pfvf->flags & OTX2_FLAG_ADPTV_INT_COAL_ENABLED) ==
+ OTX2_FLAG_ADPTV_INT_COAL_ENABLED)) {
+ /* Adjust irq coalese using net_dim */
+ otx2_adjust_adaptive_coalese(pfvf, cq_poll);
+ /* Update irq coalescing */
+ for (i = 0; i < pfvf->hw.cint_cnt; i++)
+ otx2_config_irq_coalescing(pfvf, i);
+ }
+
/* Re-enable interrupts */
otx2_write64(pfvf, NIX_LF_CINTX_ENA_W1S(cq_poll->cint_idx),
BIT_ULL(0));
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.h b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.h
index f1a04cf9210c..c88e8a436029 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.h
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.h
@@ -109,6 +109,7 @@ struct otx2_cq_poll {
#define CINT_INVALID_CQ 255
u8 cint_idx;
u8 cq_ids[CQS_PER_CINT];
+ struct dim dim;
struct napi_struct napi;
};
--
2.25.1
^ permalink raw reply related
* RE: [EXT] Re: [net-next PATCH] octeontx2-pf: Add support for adaptive interrupt coalescing
From: Suman Ghosh @ 2022-05-16 10:54 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem@davemloft.net, edumazet@google.com, pabeni@redhat.com,
Sunil Kovvuri Goutham, Subbaraya Sundeep Bhatta,
Geethasowjanya Akula, Sunil.Goutham@cavium.com, Hariprasad Kelam,
colin.king@intel.com, netdev@vger.kernel.org
In-Reply-To: <SJ0PR18MB521639671BD7597B7CF6C0BDDBCF9@SJ0PR18MB5216.namprd18.prod.outlook.com>
>>You still claim this is tested? How can it work if you're not changing
>>.supported_coalesce_params? Do we have a bug in the core?
>[Suman] Added the flag.
>>
>>> + /* Check and update coalesce status */
>>> + if ((pfvf->flags & OTX2_FLAG_ADPTV_INT_COAL_ENABLED) ==
>>> + OTX2_FLAG_ADPTV_INT_COAL_ENABLED) {
>>> + priv_coalesce_status = 1;
>>> + if (!ec->use_adaptive_rx_coalesce || !ec-
>>>use_adaptive_tx_coalesce)
>>> + pfvf->flags &= ~OTX2_FLAG_ADPTV_INT_COAL_ENABLED;
>>> + } else {
>>> + priv_coalesce_status = 0;
>>> + if (ec->use_adaptive_rx_coalesce || ec-
>>>use_adaptive_tx_coalesce)
>>> + pfvf->flags |= OTX2_FLAG_ADPTV_INT_COAL_ENABLED;
>>> + }
>>
>>Won't this flip-flop the flag? You should probably reject adaptive_rx
>>!= adaptive_tx.
>[Suman] The idea here is to enable/disable coalesce if either rx or tx
>status is enable/disable.
>If we enable only adaptive_rx then adaptive_tx will also get enabled as
>for this hardware both RX and TX are mapped to the same queue. We do not
>support separate setting for rx/tx coalesce for a net-device.
>>
>>> /* Re-enable interrupts */
>>> otx2_write64(pfvf, NIX_LF_CINTX_ENA_W1S(cq_poll->cint_idx),
>>> - BIT_ULL(0));
>>> + BIT_ULL(0));
>>
>>Unrelated and possibly misalinged?
>[Suman] Yes, will fix in V2.
^ permalink raw reply
* Re: [RFC Patch net-next v2 2/9] net: dsa: microchip: move ksz_chip_data to ksz_common
From: Vladimir Oltean @ 2022-05-16 10:51 UTC (permalink / raw)
To: Arun Ramadoss
Cc: linux-kernel, netdev, Russell King, Woojung Huh, UNGLinuxDriver,
Andrew Lunn, Vivien Didelot, Florian Fainelli, David S. Miller,
Jakub Kicinski, Paolo Abeni, Oleksij Rempel, Marek Vasut,
Michael Grzeschik, Eric Dumazet
In-Reply-To: <20220513102219.30399-3-arun.ramadoss@microchip.com>
On Fri, May 13, 2022 at 03:52:12PM +0530, Arun Ramadoss wrote:
> This patch moves the ksz_chip_data in ksz8795 and ksz9477 to ksz_common.
> At present, the dev->chip_id is iterated with the ksz_chip_data and then
> copy its value to the ksz_dev structure. These values are declared as
> constant.
> Instead of copying the values and referencing it, this patch update the
> dev->info to the ksz_chip_data based on the chip_id in the init
> function. And also update the ksz_chip_data values for the LAN937x based
> switches.
>
> Signed-off-by: Arun Ramadoss <arun.ramadoss@microchip.com>
> ---
Thanks, this looks good. I see that dev->info is assigned in
ksz_switch_register and I had to look to see whether there is any
dev->info dereference from before the call to ksz_switch_register(),
and it looks like we're ok.
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
^ permalink raw reply
* Re: [PATCH v2 net-next] net: wwan: t7xx: Fix return type of t7xx_dl_add_timedout()
From: patchwork-bot+netdevbpf @ 2022-05-16 10:50 UTC (permalink / raw)
To: YueHaibing
Cc: chandrashekar.devegowda, linuxwwan, chiranjeevi.rapolu,
haijun.liu, m.chetan.kumar, ricardo.martinez, loic.poulain,
ryazanov.s.a, johannes, davem, edumazet, kuba, pabeni, netdev,
linux-kernel
In-Reply-To: <20220513075611.1972-1-yuehaibing@huawei.com>
Hello:
This patch was applied to netdev/net-next.git (master)
by David S. Miller <davem@davemloft.net>:
On Fri, 13 May 2022 15:56:11 +0800 you wrote:
> t7xx_dl_add_timedout() now return int 'ret', but the return type
> is bool. Change the return type to int for furthor errcode upstream.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> v2: Remove unneeded ret variable
>
> [...]
Here is the summary with links:
- [v2,net-next] net: wwan: t7xx: Fix return type of t7xx_dl_add_timedout()
https://git.kernel.org/netdev/net-next/c/b321dfafb0b9
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH] octeontx2-pf: Remove unnecessary synchronize_irq() before free_irq()
From: patchwork-bot+netdevbpf @ 2022-05-16 10:50 UTC (permalink / raw)
To: CGEL
Cc: sgoutham, gakula, sbhatta, hkelam, davem, netdev, linux-kernel,
chi.minghao, zealci
In-Reply-To: <20220513081918.1631351-1-chi.minghao@zte.com.cn>
Hello:
This patch was applied to netdev/net-next.git (master)
by David S. Miller <davem@davemloft.net>:
On Fri, 13 May 2022 08:19:18 +0000 you wrote:
> From: Minghao Chi <chi.minghao@zte.com.cn>
>
> Calling synchronize_irq() right before free_irq() is quite useless. On one
> hand the IRQ can easily fire again before free_irq() is entered, on the
> other hand free_irq() itself calls synchronize_irq() internally (in a race
> condition free way), before any state associated with the IRQ is freed.
>
> [...]
Here is the summary with links:
- octeontx2-pf: Remove unnecessary synchronize_irq() before free_irq()
https://git.kernel.org/netdev/net-next/c/d887ae3247e0
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next] octeon_ep: delete unnecessary NULL check
From: patchwork-bot+netdevbpf @ 2022-05-16 10:50 UTC (permalink / raw)
To: Ziyang Xuan
Cc: vburru, aayarekar, davem, edumazet, kuba, pabeni, netdev,
linux-kernel
In-Reply-To: <20220513072928.3713739-1-william.xuanziyang@huawei.com>
Hello:
This patch was applied to netdev/net-next.git (master)
by David S. Miller <davem@davemloft.net>:
On Fri, 13 May 2022 15:29:28 +0800 you wrote:
> vfree(NULL) is safe. NULL check before vfree() is not needed.
> Delete them to simplify the code.
>
> Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
> ---
> drivers/net/ethernet/marvell/octeon_ep/octep_main.c | 3 +--
> drivers/net/ethernet/marvell/octeon_ep/octep_rx.c | 3 +--
> drivers/net/ethernet/marvell/octeon_ep/octep_tx.c | 3 +--
> 3 files changed, 3 insertions(+), 6 deletions(-)
Here is the summary with links:
- [net-next] octeon_ep: delete unnecessary NULL check
https://git.kernel.org/netdev/net-next/c/1dee43c2c6f1
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net] net/sched: act_pedit: sanitize shift argument before usage
From: patchwork-bot+netdevbpf @ 2022-05-16 10:50 UTC (permalink / raw)
To: Paolo Abeni; +Cc: netdev, jhs, xiyou.wangcong, jiri
In-Reply-To: <a6bca963dca72d5ffeb811a254a4f6415ac7ff74.1652433977.git.pabeni@redhat.com>
Hello:
This patch was applied to netdev/net.git (master)
by David S. Miller <davem@davemloft.net>:
On Fri, 13 May 2022 11:27:06 +0200 you wrote:
> syzbot was able to trigger an Out-of-Bound on the pedit action:
>
> UBSAN: shift-out-of-bounds in net/sched/act_pedit.c:238:43
> shift exponent 1400735974 is too large for 32-bit type 'unsigned int'
> CPU: 0 PID: 3606 Comm: syz-executor151 Not tainted 5.18.0-rc5-syzkaller-00165-g810c2f0a3f86 #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Call Trace:
> <TASK>
> __dump_stack lib/dump_stack.c:88 [inline]
> dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
> ubsan_epilogue+0xb/0x50 lib/ubsan.c:151
> __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x187 lib/ubsan.c:322
> tcf_pedit_init.cold+0x1a/0x1f net/sched/act_pedit.c:238
> tcf_action_init_1+0x414/0x690 net/sched/act_api.c:1367
> tcf_action_init+0x530/0x8d0 net/sched/act_api.c:1432
> tcf_action_add+0xf9/0x480 net/sched/act_api.c:1956
> tc_ctl_action+0x346/0x470 net/sched/act_api.c:2015
> rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5993
> netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502
> netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
> netlink_unicast+0x543/0x7f0 net/netlink/af_netlink.c:1345
> netlink_sendmsg+0x904/0xe00 net/netlink/af_netlink.c:1921
> sock_sendmsg_nosec net/socket.c:705 [inline]
> sock_sendmsg+0xcf/0x120 net/socket.c:725
> ____sys_sendmsg+0x6e2/0x800 net/socket.c:2413
> ___sys_sendmsg+0xf3/0x170 net/socket.c:2467
> __sys_sendmsg+0xe5/0x1b0 net/socket.c:2496
> do_syscall_x64 arch/x86/entry/common.c:50 [inline]
> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
> entry_SYSCALL_64_after_hwframe+0x44/0xae
> RIP: 0033:0x7fe36e9e1b59
> Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007ffef796fe88 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe36e9e1b59
> RDX: 0000000000000000 RSI: 0000000020000300 RDI: 0000000000000003
> RBP: 00007fe36e9a5d00 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe36e9a5d90
> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> </TASK>
>
> [...]
Here is the summary with links:
- [net] net/sched: act_pedit: sanitize shift argument before usage
https://git.kernel.org/netdev/net/c/4d42d54a7d6a
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net] NFC: hci: fix sleep in atomic context bugs in nfc_hci_hcp_message_tx
From: Krzysztof Kozlowski @ 2022-05-16 10:43 UTC (permalink / raw)
To: duoming
Cc: linux-kernel, davem, edumazet, kuba, pabeni, gregkh,
alexander.deucher, broonie, netdev
In-Reply-To: <6aba1413.196eb.180cc609bf1.Coremail.duoming@zju.edu.cn>
On 16/05/2022 12:18, duoming@zju.edu.cn wrote:
> Hello,
>
> On Mon, 16 May 2022 08:44:39 +0200 Krzysztof wrote:
>
>>> There are sleep in atomic context bugs when the request to secure
>>> element of st21nfca is timeout. The root cause is that kzalloc and
>>> alloc_skb with GFP_KERNEL parameter is called in st21nfca_se_wt_timeout
>>> which is a timer handler. The call tree shows the execution paths that
>>> could lead to bugs:
>>>
>>> (Interrupt context)
>>> st21nfca_se_wt_timeout
>>> nfc_hci_send_event
>>> nfc_hci_hcp_message_tx
>>> kzalloc(..., GFP_KERNEL) //may sleep
>>> alloc_skb(..., GFP_KERNEL) //may sleep
>>>
>>> This patch changes allocation mode of kzalloc and alloc_skb from
>>> GFP_KERNEL to GFP_ATOMIC in order to prevent atomic context from
>>> sleeping. The GFP_ATOMIC flag makes memory allocation operation
>>> could be used in atomic context.
>>>
>>> Fixes: 8b8d2e08bf0d ("NFC: HCI support")
>>> Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
>>> ---
>>> net/nfc/hci/hcp.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/net/nfc/hci/hcp.c b/net/nfc/hci/hcp.c
>>> index 05c60988f59..1caf9c2086f 100644
>>> --- a/net/nfc/hci/hcp.c
>>> +++ b/net/nfc/hci/hcp.c
>>> @@ -30,7 +30,7 @@ int nfc_hci_hcp_message_tx(struct nfc_hci_dev *hdev, u8 pipe,
>>> int hci_len, err;
>>> bool firstfrag = true;
>>>
>>> - cmd = kzalloc(sizeof(struct hci_msg), GFP_KERNEL);
>>> + cmd = kzalloc(sizeof(*cmd), GFP_ATOMIC);
>>
>> No, this does not look correct. This function can sleep, so it can use
>> GFP_KERNEL. Please just look at the function before replacing any flags...
>
> I am sorry, I don`t understand why nfc_hci_hcp_message_tx() can sleep.
Why? because in line 93 it uses a mutex (which is a sleeping primitve).
>
> I think st21nfca_se_wt_timeout() is a timer handler, which is in interrupt context.
> The call tree shows the execution paths that could lead to bugs:
>
> st21nfca_hci_se_io()
> mod_timer(&info->se_info.bwi_timer,...)
> st21nfca_se_wt_timeout() //timer handler, interrupt context
> nfc_hci_send_event()
> nfc_hci_hcp_message_tx()
> kzalloc(..., GFP_KERNEL) //may sleep
> alloc_skb(..., GFP_KERNEL) //may sleep
>
> What`s more, I think the "mutex_lock(&hdev->msg_tx_mutex)" called by nfc_hci_hcp_message_tx()
> is also improper.
>
> Please correct me, If you think I am wrong. Thanks for your time.
Your patch is not correct in current semantics of this function. This
function can sleep (because it uses a mutex), so the mistake is rather
calling it from interrupt context.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [RFC Patch net-next v2 1/9] net: dsa: microchip: ksz8795: update the port_cnt value in ksz_chip_data
From: Vladimir Oltean @ 2022-05-16 10:40 UTC (permalink / raw)
To: Arun Ramadoss
Cc: linux-kernel, netdev, Russell King, Woojung Huh, UNGLinuxDriver,
Andrew Lunn, Vivien Didelot, Florian Fainelli, David S. Miller,
Jakub Kicinski, Paolo Abeni, Oleksij Rempel, Marek Vasut,
Michael Grzeschik, Eric Dumazet
In-Reply-To: <20220513102219.30399-2-arun.ramadoss@microchip.com>
On Fri, May 13, 2022 at 03:52:11PM +0530, Arun Ramadoss wrote:
> The port_cnt value in the structure is not used in the switch_init.
> Instead it uses the fls(chip->cpu_port), this is due to one of port in
> the ksz8794 unavailable. The cpu_port for the 8794 is 0x10, fls(0x10) =
> 5, hence updating it directly in the ksz_chip_data structure in order to
> same with all the other switches in ksz8795.c and ksz9477.c files.
>
> Signed-off-by: Arun Ramadoss <arun.ramadoss@microchip.com>
> ---
Sounds like a straightforward transformation based on a valid observation.
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
> drivers/net/dsa/microchip/ksz8795.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/dsa/microchip/ksz8795.c b/drivers/net/dsa/microchip/ksz8795.c
> index f91deea9368e..83bcabf2dc54 100644
> --- a/drivers/net/dsa/microchip/ksz8795.c
> +++ b/drivers/net/dsa/microchip/ksz8795.c
> @@ -1607,6 +1607,7 @@ static const struct ksz_chip_data ksz8_switch_chips[] = {
> * KSZ8794 0,1,2 4
> * KSZ8795 0,1,2,3 4
> * KSZ8765 0,1,2,3 4
> + * port_cnt is configured as 5, even though it is 4
> */
> .chip_id = 0x8794,
> .dev_name = "KSZ8794",
> @@ -1614,7 +1615,7 @@ static const struct ksz_chip_data ksz8_switch_chips[] = {
> .num_alus = 0,
> .num_statics = 8,
> .cpu_ports = 0x10, /* can be configured as cpu port */
> - .port_cnt = 4, /* total cpu and user ports */
> + .port_cnt = 5, /* total cpu and user ports */
> .ksz87xx_eee_link_erratum = true,
> },
> {
> @@ -1653,7 +1654,7 @@ static int ksz8_switch_init(struct ksz_device *dev)
> dev->num_vlans = chip->num_vlans;
> dev->num_alus = chip->num_alus;
> dev->num_statics = chip->num_statics;
> - dev->port_cnt = fls(chip->cpu_ports);
> + dev->port_cnt = chip->port_cnt;
> dev->cpu_port = fls(chip->cpu_ports) - 1;
> dev->phy_port_cnt = dev->port_cnt - 1;
> dev->cpu_ports = chip->cpu_ports;
> --
> 2.33.0
>
^ permalink raw reply
* Re: [PATCH v2 -next] octeon_ep: add missing destroy_workqueue in octep_init_module
From: patchwork-bot+netdevbpf @ 2022-05-16 10:40 UTC (permalink / raw)
To: Zheng Bin
Cc: vburru, aayarekar, davem, edumazet, kuba, pabeni, netdev,
linux-kernel, gaochao49
In-Reply-To: <20220513071018.3279210-1-zhengbin13@huawei.com>
Hello:
This patch was applied to netdev/net-next.git (master)
by David S. Miller <davem@davemloft.net>:
On Fri, 13 May 2022 15:10:18 +0800 you wrote:
> octep_init_module misses destroy_workqueue in error path,
> this patch fixes that.
>
> Fixes: 862cd659a6fb ("octeon_ep: Add driver framework and device initialization")
> Signed-off-by: Zheng Bin <zhengbin13@huawei.com>
> ---
> v1->v2: add Fixes tag
> drivers/net/ethernet/marvell/octeon_ep/octep_main.c | 1 +
> 1 file changed, 1 insertion(+)
>
> [...]
Here is the summary with links:
- [v2,-next] octeon_ep: add missing destroy_workqueue in octep_init_module
https://git.kernel.org/netdev/net-next/c/e68372efb9fe
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next 0/4] net: polish skb defer freeing
From: patchwork-bot+netdevbpf @ 2022-05-16 10:40 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, kuba, pabeni, netdev, edumazet
In-Reply-To: <20220516042456.3014395-1-eric.dumazet@gmail.com>
Hello:
This series was applied to netdev/net-next.git (master)
by David S. Miller <davem@davemloft.net>:
On Sun, 15 May 2022 21:24:52 -0700 you wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> While testing this recently added feature on a variety
> of platforms/configurations, I found the following issues:
>
> 1) A race leading to concurrent calls to smp_call_function_single_async()
>
> [...]
Here is the summary with links:
- [net-next,1/4] net: fix possible race in skb_attempt_defer_free()
https://git.kernel.org/netdev/net-next/c/97e719a82b43
- [net-next,2/4] net: use napi_consume_skb() in skb_defer_free_flush()
https://git.kernel.org/netdev/net-next/c/2db60eed1a95
- [net-next,3/4] net: add skb_defer_max sysctl
https://git.kernel.org/netdev/net-next/c/39564c3fdc66
- [net-next,4/4] net: call skb_defer_free_flush() before each napi_poll()
https://git.kernel.org/netdev/net-next/c/909876500251
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v2] net: tulip: convert to devres
From: patchwork-bot+netdevbpf @ 2022-05-16 10:40 UTC (permalink / raw)
To: Rolf Eike Beer
Cc: kuba, linux-kernel, linux-parisc, netdev, yangyingliang, davem,
edumazet
In-Reply-To: <2630407.mvXUDI8C0e@eto.sf-tec.de>
Hello:
This patch was applied to netdev/net-next.git (master)
by David S. Miller <davem@davemloft.net>:
On Fri, 13 May 2022 19:23:59 +0200 you wrote:
> Works fine on my HP C3600:
>
> [ 274.452394] tulip0: no phy info, aborting mtable build
> [ 274.499041] tulip0: MII transceiver #1 config 1000 status 782d advertising 01e1
> [ 274.750691] net eth0: Digital DS21142/43 Tulip rev 65 at MMIO 0xf4008000, 00:30:6e:08:7d:21, IRQ 17
> [ 283.104520] net eth0: Setting full-duplex based on MII#1 link partner capability of c1e1
>
> [...]
Here is the summary with links:
- [v2] net: tulip: convert to devres
https://git.kernel.org/netdev/net-next/c/3daebfbeb455
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net] NFC: hci: fix sleep in atomic context bugs in nfc_hci_hcp_message_tx
From: duoming @ 2022-05-16 10:18 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-kernel, davem, edumazet, kuba, pabeni, gregkh,
alexander.deucher, broonie, netdev
In-Reply-To: <d5fdfe27-a6de-3030-ce51-9f4f45d552f3@linaro.org>
Hello,
On Mon, 16 May 2022 08:44:39 +0200 Krzysztof wrote:
> > There are sleep in atomic context bugs when the request to secure
> > element of st21nfca is timeout. The root cause is that kzalloc and
> > alloc_skb with GFP_KERNEL parameter is called in st21nfca_se_wt_timeout
> > which is a timer handler. The call tree shows the execution paths that
> > could lead to bugs:
> >
> > (Interrupt context)
> > st21nfca_se_wt_timeout
> > nfc_hci_send_event
> > nfc_hci_hcp_message_tx
> > kzalloc(..., GFP_KERNEL) //may sleep
> > alloc_skb(..., GFP_KERNEL) //may sleep
> >
> > This patch changes allocation mode of kzalloc and alloc_skb from
> > GFP_KERNEL to GFP_ATOMIC in order to prevent atomic context from
> > sleeping. The GFP_ATOMIC flag makes memory allocation operation
> > could be used in atomic context.
> >
> > Fixes: 8b8d2e08bf0d ("NFC: HCI support")
> > Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
> > ---
> > net/nfc/hci/hcp.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/net/nfc/hci/hcp.c b/net/nfc/hci/hcp.c
> > index 05c60988f59..1caf9c2086f 100644
> > --- a/net/nfc/hci/hcp.c
> > +++ b/net/nfc/hci/hcp.c
> > @@ -30,7 +30,7 @@ int nfc_hci_hcp_message_tx(struct nfc_hci_dev *hdev, u8 pipe,
> > int hci_len, err;
> > bool firstfrag = true;
> >
> > - cmd = kzalloc(sizeof(struct hci_msg), GFP_KERNEL);
> > + cmd = kzalloc(sizeof(*cmd), GFP_ATOMIC);
>
> No, this does not look correct. This function can sleep, so it can use
> GFP_KERNEL. Please just look at the function before replacing any flags...
I am sorry, I don`t understand why nfc_hci_hcp_message_tx() can sleep.
I think st21nfca_se_wt_timeout() is a timer handler, which is in interrupt context.
The call tree shows the execution paths that could lead to bugs:
st21nfca_hci_se_io()
mod_timer(&info->se_info.bwi_timer,...)
st21nfca_se_wt_timeout() //timer handler, interrupt context
nfc_hci_send_event()
nfc_hci_hcp_message_tx()
kzalloc(..., GFP_KERNEL) //may sleep
alloc_skb(..., GFP_KERNEL) //may sleep
What`s more, I think the "mutex_lock(&hdev->msg_tx_mutex)" called by nfc_hci_hcp_message_tx()
is also improper.
Please correct me, If you think I am wrong. Thanks for your time.
Best regards,
Duoming Zhou
^ permalink raw reply
* Re: [RFC PATCH v4 10/15] seltest/landlock: add tests for bind() hooks
From: Konstantin Meskhidze @ 2022-05-16 10:22 UTC (permalink / raw)
To: Mickaël Salaün
Cc: willemdebruijn.kernel, linux-security-module, netdev,
netfilter-devel, yusongping, artem.kuzin, anton.sirazetdinov
In-Reply-To: <78882640-70ff-9610-1eda-5917550f0ab8@digikod.net>
5/16/2022 1:10 PM, Mickaël Salaün пишет:
>
> On 01/04/2022 18:52, Mickaël Salaün wrote:
>> You need to update tools/testing/selftests/landlock/config to enable
>> CONFIG_NET and CONFIG_INET.
>>
>>
>> On 09/03/2022 14:44, Konstantin Meskhidze wrote:
>>> Adds two selftests for bind socket action.
>>> The one is with no landlock restrictions:
>>> - bind_no_restrictions;
>>> The second one is with mixed landlock rules:
>>> - bind_with_restrictions;
>>
>> Some typos (that propagated to all selftest patches):
>>
>> selftest/landlock: Add tests for bind hook
>
> I did some typo myself, it should be "selftests/landlock:"
> .
Thanks, cause I was ready to send a patch V5. I will fix it.
^ permalink raw reply
* Re: [PATCH 24/30] panic: Refactor the panic path
From: Petr Mladek @ 2022-05-16 10:21 UTC (permalink / raw)
To: Guilherme G. Piccoli
Cc: michael Kelley (LINUX), Baoquan He, Dave Young, d.hatayama, akpm,
kexec, linux-kernel, bcm-kernel-feedback-list, linuxppc-dev,
linux-alpha, linux-arm-kernel, linux-edac, linux-hyperv,
linux-leds, linux-mips, linux-parisc, linux-pm, linux-remoteproc,
linux-s390, linux-tegra, linux-um, linux-xtensa, netdev,
openipmi-developer, rcu, sparclinux, xen-devel, x86, kernel-dev,
kernel, halves, fabiomirmar, alejandro.j.jimenez,
andriy.shevchenko, arnd, bp, corbet, dave.hansen, feng.tang,
gregkh, hidehiro.kawai.ez, jgross, john.ogness, keescook, luto,
mhiramat, mingo, paulmck, peterz, rostedt, senozhatsky, stern,
tglx, vgoyal, vkuznets, will
In-Reply-To: <d313eec2-96b6-04e3-35cd-981f103d010e@igalia.com>
On Sun 2022-05-15 19:47:39, Guilherme G. Piccoli wrote:
> On 12/05/2022 11:03, Petr Mladek wrote:
> > This talks only about kdump. The reality is much more complicated.
> > The level affect the order of:
> >
> > + notifiers vs. kdump
> > + notifiers vs. crash_dump
> > + crash_dump vs. kdump
>
> First of all, I'd like to ask you please to clarify to me *exactly* what
> are the differences between "crash_dump" and "kdump". I'm sorry if
> that's a silly question, I need to be 100% sure I understand the
> concepts the same way you do.
Ah, it should have been:
+ notifiers vs. kmsg_dump
+ notifiers vs. crash_dump
+ crash_dump vs. kmsg_dump
I am sorry for the confusion. Even "crash_dump" is slightly
misleading because there is no function with this name.
But it seems to be easier to understand than __crash_kexec().
> > There might theoretically many variants of the ordering of kdump,
> > crash_dump, and the 4 notifier list. Some variants do not make
> > much sense. You choose 5 variants and tried to select them by
> > a level number.
> >
> > The question is if we really could easily describe the meaning this
> > way. It is not only about a "level" of notifiers before kdump. It is
> > also about the ordering of crash_dump vs. kdump. IMHO, "level"
> > semantic does not fit there.
> >
> > Maybe more parameters might be easier to understand the effect.
> > Anyway, we first need to agree on the chosen variants.
> > I am going to discuss it more in the code, see below.
> >
> >
> > [...]
> > Here is the code using the above functions. It helps to discuss
> > the design and logic.
> >
> > I have to say that the logic is very unclear. Almost all
> > functions are called twice:
> >
> > The really used code path is defined by order_panic_notifiers_and_kdump()
> > that encodes "level" into "bits". The bits are then flipped in
> > panic_notifier_*_once() calls that either do something or not.
> > kmsg_dump() is called according to the bit flip.
> >
> > Also I guess that it is good proof that "level" abstraction does
> > not fit here. Normal levels would not need this kind of magic.
>
> Heheh OK, I appreciate your opinion, but I guess we'll need to agree in
> disagree here - I'm much more fond to this kind of code than a bunch of
> if/else blocks that almost give headaches. Encoding such "level" logic
> in the if/else scheme is very convoluted, generates a very big code. And
> the functions aren't so black magic - they map a level in bits, and the
> functions _once() are called...once! Although we switch the position in
> the code, so there are 2 calls, one of them is called and the other not.
I see. Well, I would consider this as a warning that the approach is
too complex. If the code, using if/then/else, would cause headaches
then also understanding of the behavior would cause headaches for
both users and programmers.
> But that's totally fine to change - especially if we're moving away from
> the "level" logic. I see below you propose a much simpler approach - if
> we follow that, definitely we won't need the "black magic" approach heheh
I do not say that my proposal is fully correct. But we really need
this kind of simpler approach.
> > OK, the question is how to make it better.
> > One option "panic_prefer_crash_dump" should be enough.
> > And the code might look like:
> >
> > void panic()
> > {
> > [...]
> > dump_stack();
> > kgdb_panic(buf);
> >
> > < --- here starts the reworked code --- >
> >
> > /* crash dump is enough when enabled and preferred. */
> > if (panic_prefer_crash_dump)
> > __crash_kexec(NULL);
> >
> > /* Stop other CPUs and focus on handling the panic state. */
> > if (has_kexec_crash_image)
> > crash_smp_send_stop();
> > else
> > smp_send_stop()
> >
>
> Here we have a very important point. Why do we need 2 variants of SMP
> CPU stopping functions? I disagree with that - my understanding of this
> after some study in architectures is that the crash_() variant is
> "stronger", should work in all cases and if not, we should fix that -
> that'd be a bug.
>
> Such variant either maps to smp_send_stop() (in various architectures,
> including XEN/x86) or overrides the basic function with more proper
> handling for panic() case...I don't see why we still need such
> distinction, if you / others have some insight about that, I'd like to
> hear =)
The two variants were introduced by the commit 0ee59413c967c35a6dd
("x86/panic: replace smp_send_stop() with kdump friendly version in
panic path")
It points to https://lkml.org/lkml/2015/6/24/44 that talks about
still running watchdogs.
It is possible that the problem could be fixed another way. It is
even possible that it has already been fixed by the notifiers
that disable the watchdogs.
Anyway, any change of the smp_send_stop() behavior should be done
in a separate patch. It will help with bisection of possible
regression. Also it would require a good explanation in
the commit message. I would personally do it in a separate
patch(set).
> > /* Notify hypervisor about the system panic. */
> > atomic_notifier_call_chain(&panic_hypervisor_list, 0, NULL);
> >
> > /*
> > * No need to risk extra info when there is no kmsg dumper
> > * registered.
> > */
> > if (!has_kmsg_dumper())
> > __crash_kexec(NULL);
> >
> > /* Add extra info from different subsystems. */
> > atomic_notifier_call_chain(&panic_info_list, 0, NULL);
> >
> > kmsg_dump(KMSG_DUMP_PANIC);
> > __crash_kexec(NULL);
> >
> > /* Flush console */
> > unblank_screen();
> > console_unblank();
> > debug_locks_off();
> > console_flush_on_panic(CONSOLE_FLUSH_PENDING);
> >
> > if (panic_timeout > 0) {
> > delay()
> > }
> >
> > /*
> > * Prepare system for eventual reboot and allow custom
> > * reboot handling.
> > */
> > atomic_notifier_call_chain(&panic_reboot_list, 0, NULL);
>
> You had the order of panic_reboot_list VS. consoles flushing inverted.
> It might make sense, although I didn't do that in V1...
IMHO, it makes sense:
1. panic_reboot_list contains notifiers that do the reboot
immediately, for example, xen_panic_event, alpha_panic_event.
The consoles have to be flushed earlier.
2. console_flush_on_panic() ignores the result of console_trylock()
and always calls console_unlock(). As a result the lock should
be unlocked at the end. And any further printk() should be able
to printk the messages to the console immediately. It means
that any messages printed by the reboot notifiers should appear
on the console as well.
> Are you OK in having a helper for console flushing, as I did in V1? It
> makes code of panic() a bit less polluted / more focused I feel.
Yes, it makes sense. Well, it would better to do it in a separate
patch. The patch patch reworking the logic should be as small
as possible. It will simplify the review.
> > if (panic_timeout != 0) {
> > reboot();
> > }
> >
> > /*
> > * Prepare system for the infinite waiting, for example,
> > * setup blinking.
> > */
> > atomic_notifier_call_chain(&panic_loop_list, 0, NULL);
> >
> > infinite_loop();
> > }
> >
> >
> > __crash_kexec() is there 3 times but otherwise the code looks
> > quite straight forward.
> >
> > Note 1: I renamed the two last notifier list. The name 'post-reboot'
> > did sound strange from the logical POV ;-)
> >
> > Note 2: We have to avoid the possibility to call "reboot" list
> > before kmsg_dump(). All callbacks providing info
> > have to be in the info list. It a callback combines
> > info and reboot functionality then it should be split.
> >
> > There must be another way to calm down problematic
> > info callbacks. And it has to be solved when such
> > a problem is reported. Is there any known issue, please?
> >
> > It is possible that I have missed something important.
> > But I would really like to make the logic as simple as possible.
>
> OK, I agree with you! It's indeed simpler and if others agree, I can
> happily change the logic to what you proposed. Although...currently the
> "crash_kexec_post_notifiers" allows to call _all_ panic_reboot_list
> callbacks _before kdump_.
>
> We need to mention this change in the commit messages, but I really
> would like to hear the opinions of heavy users of notifiers (as
> Michael/Hyper-V) and the kdump interested parties (like Baoquan / Dave
> Young / Hayatama). If we all agree on such approach, will change that
> for V2 =)
Sure, we need to make sure that we call everything that is needed.
And it should be documented.
I believe that this is the right way because:
+ It was actually the motivation for this patchset. We split
the notifiers into separate lists because we want to call
only the really needed ones before kmsg_dump and crash_dump.
+ If anything is needed for crash_dump that it should be called
even when crash_dump is called first. It should be either
hardcoded into crash_dump() or we would need another notifier
list that will be always called before crash_dump.
Thanks a lot for working on this.
Best Regards,
Petr
^ permalink raw reply
* [PATCH] net: thunderx: remove null check after call container_of()
From: Haowen Bai @ 2022-05-16 10:16 UTC (permalink / raw)
To: Sunil Goutham, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: Haowen Bai, linux-arm-kernel, netdev, linux-kernel
container_of() will never return NULL, so remove useless code.
Signed-off-by: Haowen Bai <baihaowen@meizu.com>
---
drivers/net/ethernet/cavium/thunder/nicvf_main.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
index a04aa206fddc..768ea426d49f 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -2024,9 +2024,6 @@ static void nicvf_set_rx_mode_task(struct work_struct *work_arg)
u8 mode;
struct xcast_addr_list *mc;
- if (!vf_work)
- return;
-
/* Save message data locally to prevent them from
* being overwritten by next ndo_set_rx_mode call().
*/
--
2.7.4
^ permalink raw reply related
* Re: [RFC PATCH v4 10/15] seltest/landlock: add tests for bind() hooks
From: Mickaël Salaün @ 2022-05-16 10:10 UTC (permalink / raw)
To: Konstantin Meskhidze
Cc: willemdebruijn.kernel, linux-security-module, netdev,
netfilter-devel, yusongping, artem.kuzin, anton.sirazetdinov
In-Reply-To: <d3340ed0-fe61-3f00-d7ba-44ece235a319@digikod.net>
On 01/04/2022 18:52, Mickaël Salaün wrote:
> You need to update tools/testing/selftests/landlock/config to enable
> CONFIG_NET and CONFIG_INET.
>
>
> On 09/03/2022 14:44, Konstantin Meskhidze wrote:
>> Adds two selftests for bind socket action.
>> The one is with no landlock restrictions:
>> - bind_no_restrictions;
>> The second one is with mixed landlock rules:
>> - bind_with_restrictions;
>
> Some typos (that propagated to all selftest patches):
>
> selftest/landlock: Add tests for bind hook
I did some typo myself, it should be "selftests/landlock:"
^ permalink raw reply
* Re: [BUG] Layerscape CAAM+kTLS+io_uring
From: Steffen Trumtrar @ 2022-05-16 10:06 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Marc Kleine-Budde, linux-crypto, io-uring, kernel,
Horia Geantă, Pankaj Gupta, Gaurav Jain, Jens Axboe,
Pavel Begunkov, Boris Pismenny, John Fastabend, Daniel Borkmann,
netdev
In-Reply-To: <20220505171000.48a9155b@kernel.org>
Jakub Kicinski <kuba@kernel.org> writes:
> On Thu, 5 May 2022 21:20:46 +0200 Marc Kleine-Budde wrote:
>> Hello,
>>
>> no one seems to care about this problem. :/
>>
>> Maybe too many components are involved, I'm the respective maintainers
>> on Cc.
>>
>> Cc += the CAAM maintainers
>> Cc += the io_uring maintainers
>> Cc += the kTLS maintainers
>>
>> On 27.04.2022 10:20:40, Steffen Trumtrar wrote:
>> > Hi all,
>> >
>> > I have a Layerscape-1046a based board where I'm trying to use a
>> > combination of liburing (v2.0) with splice, kTLS and CAAM (kernel
>> > v5.17). The problem I see is that on shutdown the last bytes are
>> > missing. It looks like io_uring is not waiting for all completions
>> > from the CAAM driver.
>> >
>> > With ARM-ASM instead of the CAAM, the setup works fine.
>>
>> What's the difference between the CAAM and ARM-ASM crypto? Without
>> looking into the code I think the CAAM is asynchron while ARM-ASM is
>> synchron. Is this worth investigating?
>
> Sounds like
> 20ffc7adf53a ("net/tls: missing received data after fast remote close")
That fixes something in tls_sw. I have a kernel that includes this
patch. So this sounds right, but can't be it, right?
Best regards,
Steffen
--
Pengutronix e.K. | Dipl.-Inform. Steffen Trumtrar |
Steuerwalder Str. 21 | https://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686| Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH v2 -next] net: hinic: add missing destroy_workqueue in hinic_pf_to_mgmt_init
From: patchwork-bot+netdevbpf @ 2022-05-16 10:00 UTC (permalink / raw)
To: Zheng Bin; +Cc: davem, edumazet, kuba, pabeni, netdev, linux-kernel, gaochao49
In-Reply-To: <20220513070922.3278070-1-zhengbin13@huawei.com>
Hello:
This patch was applied to netdev/net-next.git (master)
by David S. Miller <davem@davemloft.net>:
On Fri, 13 May 2022 15:09:22 +0800 you wrote:
> hinic_pf_to_mgmt_init misses destroy_workqueue in error path,
> this patch fixes that.
>
> Fixes: 6dbb89014dc3 ("hinic: fix sending mailbox timeout in aeq event work")
> Signed-off-by: Zheng Bin <zhengbin13@huawei.com>
> ---
> v1->v2: add Fixes tag
> drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> [...]
Here is the summary with links:
- [v2,-next] net: hinic: add missing destroy_workqueue in hinic_pf_to_mgmt_init
https://git.kernel.org/netdev/net-next/c/382d917bfc1e
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next v3 0/4] net: skb: check the boundrary of skb drop reason
From: patchwork-bot+netdevbpf @ 2022-05-16 10:00 UTC (permalink / raw)
To: Menglong Dong
Cc: kuba, nhorman, davem, edumazet, pabeni, yoshfuji, dsahern,
imagedong, kafai, talalahmad, keescook, asml.silence, willemb,
vasily.averin, ilias.apalodimas, luiz.von.dentz, linux-kernel,
netdev
In-Reply-To: <20220513030339.336580-1-imagedong@tencent.com>
Hello:
This series was applied to netdev/net-next.git (master)
by David S. Miller <davem@davemloft.net>:
On Fri, 13 May 2022 11:03:35 +0800 you wrote:
> From: Menglong Dong <imagedong@tencent.com>
>
> In the commit 1330b6ef3313 ("skb: make drop reason booleanable"),
> SKB_NOT_DROPPED_YET is added to the enum skb_drop_reason, which makes
> the invalid drop reason SKB_NOT_DROPPED_YET can leak to the kfree_skb
> tracepoint. Once this happen (it happened, as 4th patch says), it can
> cause NULL pointer in drop monitor and result in kernel panic.
>
> [...]
Here is the summary with links:
- [net-next,v3,1/4] net: dm: check the boundary of skb drop reasons
https://git.kernel.org/netdev/net-next/c/a3af33abd921
- [net-next,v3,2/4] net: skb: check the boundrary of drop reason in kfree_skb_reason()
https://git.kernel.org/netdev/net-next/c/20bbcd0a94c6
- [net-next,v3,3/4] net: skb: change the definition SKB_DR_SET()
https://git.kernel.org/netdev/net-next/c/7ebd3f3ee51a
- [net-next,v3,4/4] net: tcp: reset 'drop_reason' to NOT_SPCIFIED in tcp_v{4,6}_rcv()
https://git.kernel.org/netdev/net-next/c/f8319dfd1b3b
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next v2] net/smc: align the connect behaviour with TCP
From: patchwork-bot+netdevbpf @ 2022-05-16 9:50 UTC (permalink / raw)
To: Guangguan Wang
Cc: kgraul, davem, kuba, pabeni, linux-s390, netdev, linux-kernel
In-Reply-To: <20220513022453.7256-1-guangguan.wang@linux.alibaba.com>
Hello:
This patch was applied to netdev/net-next.git (master)
by David S. Miller <davem@davemloft.net>:
On Fri, 13 May 2022 10:24:53 +0800 you wrote:
> Connect with O_NONBLOCK will not be completed immediately
> and returns -EINPROGRESS. It is possible to use selector/poll
> for completion by selecting the socket for writing. After select
> indicates writability, a second connect function call will return
> 0 to indicate connected successfully as TCP does, but smc returns
> -EISCONN. Use socket state for smc to indicate connect state, which
> can help smc aligning the connect behaviour with TCP.
>
> [...]
Here is the summary with links:
- [net-next,v2] net/smc: align the connect behaviour with TCP
https://git.kernel.org/netdev/net-next/c/3aba103006bc
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v2 net-next 00/10]
From: patchwork-bot+netdevbpf @ 2022-05-16 9:40 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, kuba, pabeni, netdev, edumazet
In-Reply-To: <20220513185550.844558-1-eric.dumazet@gmail.com>
Hello:
This series was applied to netdev/net-next.git (master)
by David S. Miller <davem@davemloft.net>:
On Fri, 13 May 2022 11:55:40 -0700 you wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> net: add annotations for sk->sk_bound_dev_if
>
> While writes on sk->sk_bound_dev_if are protected by socket lock,
> we have many lockless reads all over the places.
>
> [...]
Here is the summary with links:
- [v2,net-next,01/10] net: annotate races around sk->sk_bound_dev_if
https://git.kernel.org/netdev/net-next/c/4c971d2f3548
- [v2,net-next,02/10] sctp: read sk->sk_bound_dev_if once in sctp_rcv()
https://git.kernel.org/netdev/net-next/c/a20ea298071f
- [v2,net-next,03/10] tcp: sk->sk_bound_dev_if once in inet_request_bound_dev_if()
https://git.kernel.org/netdev/net-next/c/fdb5fd7f736e
- [v2,net-next,04/10] net: core: add READ_ONCE/WRITE_ONCE annotations for sk->sk_bound_dev_if
https://git.kernel.org/netdev/net-next/c/e5fccaa1eb7f
- [v2,net-next,05/10] dccp: use READ_ONCE() to read sk->sk_bound_dev_if
https://git.kernel.org/netdev/net-next/c/36f7cec4f3af
- [v2,net-next,06/10] inet: add READ_ONCE(sk->sk_bound_dev_if) in inet_csk_bind_conflict()
https://git.kernel.org/netdev/net-next/c/d2c135619cb8
- [v2,net-next,07/10] net_sched: em_meta: add READ_ONCE() in var_sk_bound_if()
https://git.kernel.org/netdev/net-next/c/70f87de9fa0d
- [v2,net-next,08/10] l2tp: use add READ_ONCE() to fetch sk->sk_bound_dev_if
https://git.kernel.org/netdev/net-next/c/ff0094030f14
- [v2,net-next,09/10] ipv6: add READ_ONCE(sk->sk_bound_dev_if) in INET6_MATCH()
(no matching commit)
- [v2,net-next,10/10] inet: rename INET_MATCH()
https://git.kernel.org/netdev/net-next/c/eda090c31fe9
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v7 net-next 00/13] tcp: BIG TCP implementation
From: patchwork-bot+netdevbpf @ 2022-05-16 9:40 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, kuba, pabeni, netdev, alexanderduyck, lixiaoyan, edumazet
In-Reply-To: <20220513183408.686447-1-eric.dumazet@gmail.com>
Hello:
This series was applied to netdev/net-next.git (master)
by David S. Miller <davem@davemloft.net>:
On Fri, 13 May 2022 11:33:55 -0700 you wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> This series implements BIG TCP as presented in netdev 0x15:
>
> https://netdevconf.info/0x15/session.html?BIG-TCP
>
> Jonathan Corbet made a nice summary: https://lwn.net/Articles/884104/
>
> [...]
Here is the summary with links:
- [v7,net-next,01/13] net: add IFLA_TSO_{MAX_SIZE|SEGS} attributes
https://git.kernel.org/netdev/net-next/c/89527be8d8d6
- [v7,net-next,02/13] net: allow gso_max_size to exceed 65536
https://git.kernel.org/netdev/net-next/c/7c4e983c4f3c
- [v7,net-next,03/13] net: limit GSO_MAX_SIZE to 524280 bytes
https://git.kernel.org/netdev/net-next/c/34b92e8d19da
- [v7,net-next,04/13] tcp_cubic: make hystart_ack_delay() aware of BIG TCP
https://git.kernel.org/netdev/net-next/c/9957b38b5e7a
- [v7,net-next,05/13] ipv6: add struct hop_jumbo_hdr definition
https://git.kernel.org/netdev/net-next/c/7c96d8ec96bb
- [v7,net-next,06/13] ipv6/gso: remove temporary HBH/jumbo header
https://git.kernel.org/netdev/net-next/c/09f3d1a3a52c
- [v7,net-next,07/13] ipv6/gro: insert temporary HBH/jumbo header
https://git.kernel.org/netdev/net-next/c/81fbc812132c
- [v7,net-next,08/13] net: allow gro_max_size to exceed 65536
https://git.kernel.org/netdev/net-next/c/0fe79f28bfaf
- [v7,net-next,09/13] ipv6: Add hop-by-hop header to jumbograms in ip6_output
https://git.kernel.org/netdev/net-next/c/80e425b61342
- [v7,net-next,10/13] net: loopback: enable BIG TCP packets
https://git.kernel.org/netdev/net-next/c/d6f938ce52f9
- [v7,net-next,11/13] veth: enable BIG TCP packets
https://git.kernel.org/netdev/net-next/c/d406099d6a15
- [v7,net-next,12/13] mlx4: support BIG TCP packets
https://git.kernel.org/netdev/net-next/c/1169a64265c4
- [v7,net-next,13/13] mlx5: support BIG TCP packets
https://git.kernel.org/netdev/net-next/c/de78960e025f
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox