Netdev List
 help / color / mirror / Atom feed
* [PATCH net 1/2] bpf/verifier: fix bounds calculation on BPF_RSH
From: Edward Cree @ 2017-12-05 19:15 UTC (permalink / raw)
  To: davem; +Cc: netdev, Jann Horn, Alexei Starovoitov, Daniel Borkmann
In-Reply-To: <7c4a1470-3cf1-ceae-c99f-6591f1882063@solarflare.com>

Incorrect signed bounds were being computed, although this had no effect
 since the propagation in __reg_deduce_bounds() happened to overwrite them.

Fixes: b03c9f9fdc37 ("bpf/verifier: track signed and unsigned min/max values")
Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: Edward Cree <ecree@solarflare.com>
---
 kernel/bpf/verifier.c | 30 ++++++++++++++++--------------
 1 file changed, 16 insertions(+), 14 deletions(-)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index d4593571c404..5bed7f773c87 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -2184,20 +2184,22 @@ static int adjust_scalar_min_max_vals(struct bpf_verifier_env *env,
 			mark_reg_unknown(env, regs, insn->dst_reg);
 			break;
 		}
-		/* BPF_RSH is an unsigned shift, so make the appropriate casts */
-		if (dst_reg->smin_value < 0) {
-			if (umin_val) {
-				/* Sign bit will be cleared */
-				dst_reg->smin_value = 0;
-			} else {
-				/* Lost sign bit information */
-				dst_reg->smin_value = S64_MIN;
-				dst_reg->smax_value = S64_MAX;
-			}
-		} else {
-			dst_reg->smin_value =
-				(u64)(dst_reg->smin_value) >> umax_val;
-		}
+		/* BPF_RSH is an unsigned shift.  If the value in dst_reg might
+		 * be negative, then either:
+		 * 1) src_reg might be zero, so the sign bit of the result is
+		 *    unknown, so we lose our signed bounds
+		 * 2) it's known negative, thus the unsigned bounds capture the
+		 *    signed bounds
+		 * 3) the signed bounds cross zero, so they tell us nothing
+		 *    about the result
+		 * If the value in dst_reg is known nonnegative, then again the
+		 * unsigned bounts capture the signed bounds.
+		 * Thus, in all cases it suffices to blow away our signed bounds
+		 * and rely on inferring new ones from the unsigned bounds and
+		 * var_off of the result.
+		 */
+		dst_reg->smin_value = S64_MIN;
+		dst_reg->smax_value = S64_MAX;
 		if (src_known)
 			dst_reg->var_off = tnum_rshift(dst_reg->var_off,
 						       umin_val);

^ permalink raw reply related

* [PATCH net 0/2] bpf/verifier: fix bounds calculation on BPF_RSH
From: Edward Cree @ 2017-12-05 19:13 UTC (permalink / raw)
  To: davem; +Cc: netdev, Jann Horn, Alexei Starovoitov, Daniel Borkmann

Fix a bug in adjust_scalar_min_max_vals().  Since the bug has no effect (a
 later call to __reg_deduce_bounds() happens to mask it), it can't be
 tested for directly without adding extra debug prints; but add a test case
 to at least cover the relevant behaviour.

Edward Cree (2):
  bpf/verifier: fix bounds calculation on BPF_RSH
  selftests/bpf: Add a test for shifts of values that might be negative

 kernel/bpf/verifier.c                    | 30 ++++++++++++------------
 tools/testing/selftests/bpf/test_align.c | 39 ++++++++++++++++++++++++++++++++
 2 files changed, 55 insertions(+), 14 deletions(-)

^ permalink raw reply

* Re: [PATCH net 1/2] netlink: add NLA_U8_BUGGY attribute type
From: David Miller @ 2017-12-05 19:08 UTC (permalink / raw)
  To: dsahern; +Cc: johannes, linux-wireless, netdev, j
In-Reply-To: <c9bbb3a1-4a94-fece-478f-7e347734ddd2@gmail.com>

From: David Ahern <dsahern@gmail.com>
Date: Tue, 5 Dec 2017 11:15:29 -0700

> Is the patch I sent as an attachment good or should I re-send
> standalone? (don't see it in patchwork)

Patchwork has been wonky laterly, please resubmit as a fresh
email for rewiew.

Thanks.

^ permalink raw reply

* Re: [PATCH 1/2] net: sh_eth: add support for SH7786
From: Sergei Shtylyov @ 2017-12-05 19:04 UTC (permalink / raw)
  To: Thomas Petazzoni
  Cc: David S. Miller, Niklas Söderlund, Geert Uytterhoeven,
	Simon Horman, netdev, linux-renesas-soc
In-Reply-To: <20171205084945.384ea35e@windsurf.lan>

Hello!

On 12/05/2017 10:49 AM, Thomas Petazzoni wrote:

>>> This commit adds the sh_eth_cpu_data structure that describes the
>>> SH7786 variant of the IP.
>>
>>      The manual seems to be unavailable, so I have to trust you. :-)
> 
> Yes, sadly. However, if you tell me what to double check, I'd be happy
> to do so.

    I have the manual now, will check against it...
    DaveM, I'm retracting my ACK for the time being.

> Thanks!
> 
> Thomas

MBR, Sergei

^ permalink raw reply

* Re: [PATCH net-next 2/2 v6] net: ethernet: Add a driver for Gemini gigabit ethernet
From: Michał Mirosław @ 2017-12-05 19:03 UTC (permalink / raw)
  To: Linus Walleij
  Cc: Tobias Waldvogel, Florian Fainelli, Paulius Zaleckas, netdev,
	Hans Ulli Kroll, Janos Laube, David S . Miller, linux-arm-kernel
In-Reply-To: <20171202110640.5284-2-linus.walleij@linaro.org>

On Sat, Dec 02, 2017 at 12:06:40PM +0100, Linus Walleij wrote:
[...]
> The latest v6 incarnation of this driver was written by Michał
> Mirosław and submitted for inclusion in 2011. This was the
> last post:
> https://lwn.net/Articles/437889/
> 
> DaveM ACKed it at the time:
> https://marc.info/?l=linux-netdev&m=130255434310315&w=2
> 
> The controversial pieces under ARM (board files) and other
> subsystems are now gone and replaced by DeviceTree.
> 
> Michał: I hope you don't mind me picking it up and hope
> you can still test it on your ICYbox, I have device tree
> patches in my tree:
> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git/log/?h=gemini-ethernet

I'm happy to see that my work didn't go to /dev/null after all.
I haven't finished it at the time because the box I had broke down
beyond repair.

I skimmed through the patch - please find my comments below.

Best Regards,
Michał Mirosław


[...]
> --- /dev/null
> +++ b/drivers/net/ethernet/cortina/gemini.c
> @@ -0,0 +1,2461 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Ethernet device driver for Cortina Systems Gemini SoC
> + * Also known as the StorLink SL3512 and SL3516 (SL351x) GMAC
> + *
> + * Authors:
> + * Linus Walleij <linus.walleij@linaro.org>
> + * Tobias Waldvogel <tobias.waldvogel@gmail.com> (OpenWRT)
> + * Michał Mirosław <mirq-linux@rere.qmqm.pl>

Doubly UTF-8 encoded?

[...]
> +static int gmac_setup_txqs(struct net_device *netdev)
> +{
[...]
> +	desc_ring = dma_alloc_coherent(geth->dev, len * sizeof(*desc_ring),
> +		&port->txq_dma_base, GFP_KERNEL);
> +
> +	if (!desc_ring) {

Should check with dma_mapping_error().

> +		kfree(skb_tab);
> +		return -ENOMEM;
> +	}
> +
> +	BUG_ON(port->txq_dma_base & ~DMA_Q_BASE_MASK);

BUG is too hard here. return -EINVAL or other error? Shouldn't happen
if dma_alloc_coherent() guarantees 16B alignment.

[...]
> +static int gmac_setup_rxq(struct net_device *netdev)
> +{
[...]
> +	BUG_ON(port->rxq_dma_base & ~NONTOE_QHDR0_BASE_MASK);

Like above.

[...]
> +static struct page *geth_freeq_alloc_map_page(struct gemini_ethernet *geth,
> +					      int pn)
> +{
> +	unsigned int fpp_order = PAGE_SHIFT - geth->freeq_frag_order;
> +	unsigned int frag_len = 1 << geth->freeq_frag_order;
> +	GMAC_RXDESC_T *freeq_entry;
> +	dma_addr_t mapping;
> +	struct page *page;
> +	int i;
> +
> +	page = alloc_page(GFP_ATOMIC);
> +	if (!page)
> +		return NULL;
> +
> +	mapping = dma_map_single(geth->dev, page_address(page),
> +				PAGE_SIZE, DMA_FROM_DEVICE);
> +
> +	if (unlikely(dma_mapping_error(geth->dev, mapping) || !mapping)) {

This should test only dma_mapping_error() since mapping == 0 is valid,
but unlikely.

> +static int geth_setup_freeq(struct gemini_ethernet *geth)
> +{
> +	void __iomem *dma_reg = geth->base + GLOBAL_SW_FREEQ_BASE_SIZE_REG;
> +	QUEUE_THRESHOLD_T qt;
> +	DMA_SKB_SIZE_T skbsz;
> +	unsigned int filled;
> +	unsigned int frag_len = 1 << geth->freeq_frag_order;
> +	unsigned int len = 1 << geth->freeq_order;
> +	unsigned int fpp_order = PAGE_SHIFT - geth->freeq_frag_order;
> +	unsigned int pages = len >> fpp_order;
> +	dma_addr_t mapping;
> +	unsigned int pn;
> +
> +	geth->freeq_ring = dma_alloc_coherent(geth->dev,
> +		sizeof(*geth->freeq_ring) << geth->freeq_order,
> +		&geth->freeq_dma_base, GFP_KERNEL);
> +	if (!geth->freeq_ring)
> +		return -ENOMEM;
> +
> +	BUG_ON(geth->freeq_dma_base & ~DMA_Q_BASE_MASK);

Another BUG_ON:

if (WARN_ON(...)) goto err_freeq;

[...]
> +static int gmac_map_tx_bufs(struct net_device *netdev, struct sk_buff *skb,
> +			    struct gmac_txq *txq, unsigned short *desc)
> +{
[...]
> +	if (word1 > mtu) {
> +		word1 |= TSS_MTU_ENABLE_BIT;
> +		word3 += mtu;

word3 |= mtu; would be more natural.

[...]
> +		mapping = dma_map_single(geth->dev, buffer, buflen,
> +					DMA_TO_DEVICE);
> +		if (dma_mapping_error(geth->dev, mapping) ||
> +			!(mapping & PAGE_MASK))
> +			goto map_error;

Is page at phys 0 special to the HW?

[...]
> +map_error:
> +	while (w != *desc) {
> +		w--;
> +		w &= m;
> +
> +		dma_unmap_page(geth->dev, txq->ring[w].word2.buf_adr,
> +			txq->ring[w].word0.bits.buffer_size, DMA_TO_DEVICE);
> +	}
> +	return ENOMEM;

return -ENOMEM; for consistency, though not used in the caller.

[...]
> +static int gmac_start_xmit(struct sk_buff *skb, struct net_device *netdev)
> +{
[...]
> +	if (unlikely(gmac_map_tx_bufs(netdev, skb, txq, &w))) {
> +		if (skb_linearize(skb))
> +			goto out_drop;
> +
> +		if (unlikely(gmac_map_tx_bufs(netdev, skb, txq, &w)))
> +			goto out_drop_free;
> +
> +		u64_stats_update_begin(&port->tx_stats_syncp);
> +		port->tx_frags_linearized++;
> +		u64_stats_update_end(&port->tx_stats_syncp);

This misses stats update when mapping after skb_linearize() fails.

[...]
> +static struct sk_buff *gmac_skb_if_good_frame(struct gemini_ethernet_port *port,
> +	GMAC_RXDESC_0_T word0, unsigned frame_len)
> +{
> +	struct sk_buff *skb = NULL;
> +	unsigned rx_status = word0.bits.status;
> +	unsigned rx_csum = word0.bits.chksum_status;

> +	port->rx_stats[rx_status]++;
> +	port->rx_csum_stats[rx_csum]++;
> +
> +	if (word0.bits.derr || word0.bits.perr ||
> +	    rx_status || frame_len < ETH_ZLEN ||
> +	    rx_csum >= RX_CHKSUM_IP_ERR_UNKNOWN) {
> +		port->stats.rx_errors++;
> +
> +		if (frame_len < ETH_ZLEN || RX_ERROR_LENGTH(rx_status))
> +			port->stats.rx_length_errors++;
> +		if (RX_ERROR_OVER(rx_status))
> +			port->stats.rx_over_errors++;
> +		if (RX_ERROR_CRC(rx_status))
> +			port->stats.rx_crc_errors++;
> +		if (RX_ERROR_FRAME(rx_status))
> +			port->stats.rx_frame_errors++;
> +
> +		return NULL;

Could support RXALL feature here.

> +	skb = napi_get_frags(&port->napi);
> +	if (!skb)
> +		return NULL;

This case could get a stats update, too.

> +static unsigned int gmac_rx(struct net_device *netdev, unsigned budget)
> +{
[...]
> +		if (unlikely(!mapping)) {
> +			netdev_err(netdev,
> +				   "rxq[%u]: HW BUG: zero DMA desc\n", r);
> +			goto err_drop;
> +		}

I wonder if this was a bug in the driver or in HW. Does it trigger on
your boxes?

[...]
> +static void gmac_set_rx_mode(struct net_device *netdev)
> +{
> +	struct gemini_ethernet_port *port = netdev_priv(netdev);
> +	struct netdev_hw_addr *ha;
> +	__u32 mc_filter[2];
> +	unsigned bit_nr;
> +	GMAC_RX_FLTR_T filter = { .bits = {
> +		.broadcast = 1,
> +		.multicast = 1,
> +		.unicast = 1,
> +	} };
> +
> +	mc_filter[1] = mc_filter[0] = 0;

Looks like this should be = ~0u (IFF_ALLMULTI case).

> +	if (netdev->flags & IFF_PROMISC) {
> +		filter.bits.error = 1;
> +		filter.bits.promiscuous = 1;
> +	} else if (!(netdev->flags & IFF_ALLMULTI)) {
> +		mc_filter[1] = mc_filter[0] = 0;
> +		netdev_for_each_mc_addr(ha, netdev) {
> +			bit_nr = ~crc32_le(~0, ha->addr, ETH_ALEN) & 0x3f;
> +			mc_filter[bit_nr >> 5] |= 1 << (bit_nr & 0x1f);
> +		}
> +	}
[...]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH net-next 1/6] net: qualcomm: rmnet: Remove the rmnet_map_results enum
From: Subash Abhinov Kasiviswanathan @ 2017-12-05 19:02 UTC (permalink / raw)
  To: David Miller; +Cc: netdev
In-Reply-To: <20171205.115340.922583515967797421.davem@davemloft.net>

> This will crash, you didn't test the new code path that does the
> kfree_skb().
> 
> You should use an SKB helper function which will realloc the headroom
> if ETH_HLEN is not available, instead of failing.
...
> That is definitely not the only thing this change is doing:
> Previously these paths would return "RMNET_MAP_CONSUMED":
> Causing this code to return.
> Now, instead the code jumps to fail:
> 
>> @@ -142,7 +142,11 @@ static int rmnet_map_egress_handler(struct 
>> sk_buff *skb,
>> 
>>  	skb->protocol = htons(ETH_P_MAP);
>> 
>> -	return RMNET_MAP_SUCCESS;
>> +	return 0;
>> +
>> +fail:
>> +	kfree_skb(skb);
>> +	return -ENOMEM;
>>  }
>> 
> 
> Which frees the SKB.
> 
> This is a behavioral change, perhaps a bug fix.
> 
> Well, nobody knows because you do not explain this at all in your
> commit message.
> 
> Do not mix functional changes with cleanups.  If you want to change how
> freeing the SKB is done, do it in a separate change from the patch that
> removes this enumeration.
> 
> Thank you.

Hi David

I will send the change in freeing behavior as a bug fix for net and then
post updates on this series after it.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply

* Re: [PATCH v2] net: sh_eth: do not advertise Gigabit capabilities when not available
From: Sergei Shtylyov @ 2017-12-05 19:02 UTC (permalink / raw)
  To: Thomas Petazzoni, David S. Miller, Niklas Söderlund,
	Geert Uytterhoeven, Simon Horman
  Cc: netdev, linux-renesas-soc
In-Reply-To: <20171205092952.3455-1-thomas.petazzoni@free-electrons.com>

Hello!

On 12/05/2017 12:29 PM, Thomas Petazzoni wrote:

> Not all variants of the sh_eth hardware have Gigabit
> support. Unfortunately, the current driver doesn't tell the PHY about
> the limited MAC capabilities. Due to this, if you have a Gigabit
> capable PHY, the PHY will advertise its Gigabit capability and
> establish a link at 1Gbit/s, even though the MAC doesn't support it.
> 
> In order to avoid this, we use the recently introduced
> phy_set_max_speed() to tell the PHY to not advertise speed higher than
> 100 MBit/s.
> 
> Tested on a SH7786 platform, with a Gigabit PHY.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> Changes since v1:
>   - Use phy_set_max_speed(), as suggested by Sergei Shtylyov
>     <sergei.shtylyov@cogentembedded.com>.
> ---
>   drivers/net/ethernet/renesas/sh_eth.c | 14 ++++++++++++++
>   1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
> index db72d13cebb9..44ff2835c954 100644
> --- a/drivers/net/ethernet/renesas/sh_eth.c
> +++ b/drivers/net/ethernet/renesas/sh_eth.c
[...]
> @@ -1892,9 +1893,22 @@ static int sh_eth_phy_init(struct net_device *ndev)
>   		return PTR_ERR(phydev);
>   	}
>   
> +	/* mask with MAC supported features */
> +	if (mdp->cd->register_type != SH_ETH_REG_GIGABIT) {
> +		err = phy_set_max_speed(phydev, SPEED_100);
> +		if (err) {
> +			netdev_err(ndev, "failed to limit PHY to 100 Mbit/s\n");
> +			goto err_phy_disconnect;

    Er, why do we need a *goto* here at all? Just call phy_disconnect() here 
and be done with that...

> +		}
> +	}
> +
>   	phy_attached_info(phydev);
>   
>   	return 0;
> +
> +err_phy_disconnect:
> +	phy_disconnect(phydev);
> +	return err;
>   }
>   
>   /* PHY control start function */

MBR, Sergei

^ permalink raw reply

* Re: [PATCH net-next 01/12] sctp: add stream interleave enable members and sockopt
From: Marcelo Ricardo Leitner @ 2017-12-05 18:59 UTC (permalink / raw)
  To: Neil Horman; +Cc: Xin Long, network dev, linux-sctp, davem
In-Reply-To: <20171205183540.GB10327@hmswarspite.think-freely.org>

On Tue, Dec 05, 2017 at 01:35:40PM -0500, Neil Horman wrote:
> On Tue, Dec 05, 2017 at 11:15:58PM +0800, Xin Long wrote:
> > This patch adds intl_enable in asoc and netns, and strm_interleave in
> > sctp_sock to indicate if stream interleave is enabled and supported.
> > 
> > netns intl_enable would be set via procfs, but that is not added yet
> > until all stream interleave codes are completely implemented; asoc
> > intl_enable will be set when doing 4-shakehands.
> > 
> Which patch did you implement the per-namespace proc file in?  I don't see it in
> the patch that you referenced above
> Neil
> 

It's in the next series. As the next one introduces the compatibility
needed for other extensions, which are already in the stack, it's
safer to not be able to enable it yet.

Xin, can you please post it as RFC too? So Neil can have a look at the
big picture here. Thanks

  Marcelo

^ permalink raw reply

* Re: [PATCH tip/core/rcu 21/21] drivers/vhost: Remove now-redundant read_barrier_depends()
From: Michael S. Tsirkin @ 2017-12-05 18:57 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: tglx, kvm, fweisbec, jiangshanlai, linux-kernel, rostedt, josh,
	dhowells, edumazet, netdev, mathieu.desnoyers, oleg, dipankar,
	akpm, Paul E. McKenney, virtualization, mingo
In-Reply-To: <20171205183946.GP3165@worktop.lehotels.local>

On Tue, Dec 05, 2017 at 07:39:46PM +0100, Peter Zijlstra wrote:
> On Tue, Dec 05, 2017 at 08:31:20PM +0200, Michael S. Tsirkin wrote:
> 
> > Apropos, READ_ONCE is now asymmetrical with WRITE_ONCE.
> > 
> > I can read a pointer with READ_ONCE and be sure the value
> > is sane, but only if I also remember to put in smp_wmb before
> > WRITE_ONCE. Otherwise the pointer is ok but no guarantees
> > about the data pointed to.
> 
> That was already the case on everything except Alpha. And the canonical
> match do the data dependency is store_release, not wmb.

Oh, interesting

static __always_inline void __write_once_size(volatile void *p, void *res, int size)
{
        switch (size) {
        case 1: *(volatile __u8 *)p = *(__u8 *)res; break;
        case 2: *(volatile __u16 *)p = *(__u16 *)res; break;
        case 4: *(volatile __u32 *)p = *(__u32 *)res; break;
        case 8: *(volatile __u64 *)p = *(__u64 *)res; break;
        default:
                barrier();
                __builtin_memcpy((void *)p, (const void *)res, size);
                barrier();
        }
}

#define WRITE_ONCE(x, val) \
({                                                      \
        union { typeof(x) __val; char __c[1]; } __u =   \
                { .__val = (__force typeof(x)) (val) }; \
        __write_once_size(&(x), __u.__c, sizeof(x));    \
        __u.__val;                                      \
})

I don't see WRITE_ONCE inserting any barriers, release or
write.

So it seems that on an architecture where writes can be reordered,
if I do

*pointer = 0xa;
WRITE_ONCE(array[x], pointer);

array write might bypass the pointer write,
and readers will read a stale value.




-- 
MST

^ permalink raw reply

* Re: [PATCH net-next 07/12] sctp: implement ulpevent_data for sctp_stream_interleave
From: Marcelo Ricardo Leitner @ 2017-12-05 18:48 UTC (permalink / raw)
  To: Neil Horman; +Cc: Xin Long, network dev, linux-sctp, davem
In-Reply-To: <20171205182855.GA10327@hmswarspite.think-freely.org>

On Tue, Dec 05, 2017 at 01:28:55PM -0500, Neil Horman wrote:
> On Tue, Dec 05, 2017 at 11:16:04PM +0800, Xin Long wrote:
> > ulpevent_data is added as a member of sctp_stream_interleave, used to
> > do the most process in ulpq, including to convert data or idata chunk
> > to event, reasm them in reasm queue and put them in lobby queue in
> > right order, and deliver them up to user sk rx queue.
> > 
> > This procedure is described in section 2.2.3 of RFC8260.
> > 
> > It adds most functions for idata here to do the similar process as
> > the old functions for data. But since the details are very different
> > between them, the old functions can not be reused for idata.
> > 
> > event->ssn and event->ppid settings are moved to ulpevent_data from
> > sctp_ulpevent_make_rcvmsg, so that sctp_ulpevent_make_rcvmsg could
> > work for both data and idata.
> > 
> > Note that mid is added in sctp_ulpevent for idata, __packed has to
> > be used for defining sctp_ulpevent, or it would exceeds the skb cb
> > that saves a sctp_ulpevent variable for ulp layer process.
> > 
> > Signed-off-by: Xin Long <lucien.xin@gmail.com>
> > ---
> >  include/net/sctp/stream_interleave.h |   2 +
> >  include/net/sctp/structs.h           |   3 +
> >  include/net/sctp/ulpevent.h          |  20 +-
> >  net/sctp/sm_sideeffect.c             |   5 +-
> >  net/sctp/stream_interleave.c         | 418 +++++++++++++++++++++++++++++++++++
> >  net/sctp/ulpevent.c                  |   2 -
> >  net/sctp/ulpqueue.c                  |  12 +-
> >  7 files changed, 451 insertions(+), 11 deletions(-)
> > 
> > diff --git a/include/net/sctp/stream_interleave.h b/include/net/sctp/stream_interleave.h
> > index d8d1b51..02f60f5 100644
> > --- a/include/net/sctp/stream_interleave.h
> > +++ b/include/net/sctp/stream_interleave.h
> > @@ -39,6 +39,8 @@ struct sctp_stream_interleave {
> >  					    int len, __u8 flags, gfp_t gfp);
> >  	void	(*assign_number)(struct sctp_chunk *chunk);
> >  	bool	(*validate_data)(struct sctp_chunk *chunk);
> > +	int	(*ulpevent_data)(struct sctp_ulpq *ulpq,
> > +				 struct sctp_chunk *chunk, gfp_t gfp);
> >  };
> >  
> >  void sctp_stream_interleave_init(struct sctp_stream *stream);
> > diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
> > index 348b25e..d7da719 100644
> > --- a/include/net/sctp/structs.h
> > +++ b/include/net/sctp/structs.h
> > @@ -411,6 +411,8 @@ void sctp_stream_update(struct sctp_stream *stream, struct sctp_stream *new);
> >  #define sctp_mid_skip(stream, type, sid, mid) \
> >  	((stream)->type[sid].mid = mid + 1)
> >  
> > +#define sctp_stream_in(asoc, sid) (&(asoc)->stream.in[sid])
> > +
> >  /*
> >   * Pointers to address related SCTP functions.
> >   * (i.e. things that depend on the address family.)
> > @@ -1386,6 +1388,7 @@ struct sctp_stream_in {
> >  		__u16 ssn;
> >  	};
> >  	__u32 fsn;
> > +	char pd_mode;
> >  };
> >  
> >  struct sctp_stream {
> > diff --git a/include/net/sctp/ulpevent.h b/include/net/sctp/ulpevent.h
> > index 231dc42..ce4f2aa 100644
> > --- a/include/net/sctp/ulpevent.h
> > +++ b/include/net/sctp/ulpevent.h
> > @@ -45,19 +45,29 @@
> >  /* A structure to carry information to the ULP (e.g. Sockets API) */
> >  /* Warning: This sits inside an skb.cb[] area.  Be very careful of
> >   * growing this structure as it is at the maximum limit now.
> > + *
> > + * sctp_ulpevent is saved in sk->cb(48 bytes), whose last 4 bytes
> > + * have been taken by sock_skb_cb, So here it has to use 'packed'
> > + * to make sctp_ulpevent fit into the rest 44 bytes.
> >   */
> >  struct sctp_ulpevent {
> >  	struct sctp_association *asoc;
> >  	struct sctp_chunk *chunk;
> >  	unsigned int rmem_len;
> > -	__u32 ppid;
> > +	union {
> > +		__u32 mid;
> > +		__u16 ssn;
> > +	};
> > +	union {
> > +		__u32 ppid;
> > +		__u32 fsn;
> > +	};
> >  	__u32 tsn;
> >  	__u32 cumtsn;
> >  	__u16 stream;
> > -	__u16 ssn;
> >  	__u16 flags;
> >  	__u16 msg_flags;
> > -};
> > +} __packed;
> >  
> What kind  of performance do you see before and after this patch?  I ask because
> it seems like the members between ppid through stream are going to be misaligned
> (not on a 4 byte boundary), now that you've made this structure packed.

It shouldn't be misaligned because the __u16 ssn field is wrapped on a union
with __u32 mid, causing the next field to be aligned on the largest member,
which is __u32.

FWIW, before:
struct sctp_ulpevent {
        struct sctp_association *  asoc;                 /*     0     8 */
        struct sctp_chunk *        chunk;                /*     8     8 */
        unsigned int               rmem_len;             /*    16     4 */
        __u32                      ppid;                 /*    20     4 */
        __u32                      tsn;                  /*    24     4 */
        __u32                      cumtsn;               /*    28     4 */
        __u16                      stream;               /*    32     2 */
        __u16                      ssn;                  /*    34     2 */
        __u16                      flags;                /*    36     2 */
        __u16                      msg_flags;            /*    38     2 */

        /* size: 40, cachelines: 1, members: 10 */
        /* last cacheline: 40 bytes */
};

and after:
struct sctp_ulpevent {
        struct sctp_association *  asoc;                 /*     0     8 */
        struct sctp_chunk *        chunk;                /*     8     8 */
        unsigned int               rmem_len;             /*    16     4 */
        union {
                __u32              mid;                  /*           4 */
                __u16              ssn;                  /*           2 */
        };                                               /*    20     4 */
        union {
                __u32              ppid;                 /*           4 */
                __u32              fsn;                  /*           4 */
        };                                               /*    24     4 */
        __u32                      tsn;                  /*    28     4 */
        __u32                      cumtsn;               /*    32     4 */
        __u16                      stream;               /*    36     2 */
        __u16                      flags;                /*    38     2 */
        __u16                      msg_flags;            /*    40     2 */

        /* size: 42, cachelines: 1, members: 10 */
        /* last cacheline: 42 bytes */
};

  Marcelo

^ permalink raw reply

* Re: [PATCH net-next] net: phy: meson-gxl: cleanup by defining the control registers
From: Jerome Brunet @ 2017-12-05 18:47 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: Florian Fainelli, Neil Armstrong, netdev, linux-amlogic,
	linux-kernel
In-Reply-To: <20171205180142.GS12805@lunn.ch>

On Tue, 2017-12-05 at 19:01 +0100, Andrew Lunn wrote:
> On Tue, Dec 05, 2017 at 10:33:34AM +0100, Jerome Brunet wrote:
> > From: Neil Armstrong <narmstrong@baylibre.com>
> > 
> > Define registers and bits in meson-gxl PHY driver to make a bit
> > more human friendly. No functional change
> 
> 
> >  static int meson_gxl_config_init(struct phy_device *phydev)
> >  {
> > -	/* Enable Analog and DSP register Bank access by */
> > -	phy_write(phydev, 0x14, 0x0000);
> > -	phy_write(phydev, 0x14, 0x0400);
> > -	phy_write(phydev, 0x14, 0x0000);
> > -	phy_write(phydev, 0x14, 0x0400);
> > +	int ret;
> >  
> > -	/* Write Analog register 23 */
> > -	phy_write(phydev, 0x17, 0x8E0D);
> > -	phy_write(phydev, 0x14, 0x4417);
> > +	/* Write PLL Configuration 1 */
> > +	ret = meson_gxl_write_reg(phydev, BANK_ANALOG_DSP, A6_CONFIG_REG,
> > +				  A6_CONFIG_PLLMULX4ICH |
> > +				  FIELD_PREP(A6_CONFIG_PLLBUFITRIM, 7) |
> > +				  A6_CONFIG_PLLRSTVCOPD |
> > +				  A6_CONFIG_PLLCPOFF |
> > +				  A6_CONFIG_PLL_SRC);
> > +	if (ret)
> > +		return ret;
> 
> This does not look like "No functional Change".
> 
> Please can you break this up. First make use of #defines.
> That should be a clear "No functional Change".
> 
> Then a second patch adding a helper for banked registers?

Sure, It would be better.
I also noticed that the write function was inlined which is probably not good.

> 
>      Thanks
> 	Andrew

^ permalink raw reply

* Re: [PATCH tip/core/rcu 21/21] drivers/vhost: Remove now-redundant read_barrier_depends()
From: Peter Zijlstra @ 2017-12-05 18:39 UTC (permalink / raw)
  To: Michael S. Tsirkin
  Cc: tglx, kvm, fweisbec, jiangshanlai, linux-kernel, rostedt, josh,
	dhowells, edumazet, netdev, mathieu.desnoyers, oleg, dipankar,
	akpm, Paul E. McKenney, virtualization, mingo
In-Reply-To: <20171205202928-mutt-send-email-mst@kernel.org>

On Tue, Dec 05, 2017 at 08:31:20PM +0200, Michael S. Tsirkin wrote:

> Apropos, READ_ONCE is now asymmetrical with WRITE_ONCE.
> 
> I can read a pointer with READ_ONCE and be sure the value
> is sane, but only if I also remember to put in smp_wmb before
> WRITE_ONCE. Otherwise the pointer is ok but no guarantees
> about the data pointed to.

That was already the case on everything except Alpha. And the canonical
match do the data dependency is store_release, not wmb.

^ permalink raw reply

* Re: [PATCH net-next 01/12] sctp: add stream interleave enable members and sockopt
From: Neil Horman @ 2017-12-05 18:35 UTC (permalink / raw)
  To: Xin Long; +Cc: network dev, linux-sctp, Marcelo Ricardo Leitner, davem
In-Reply-To: <b830faf5987dbed8b1e724f039348e960b8537e3.1512486606.git.lucien.xin@gmail.com>

On Tue, Dec 05, 2017 at 11:15:58PM +0800, Xin Long wrote:
> This patch adds intl_enable in asoc and netns, and strm_interleave in
> sctp_sock to indicate if stream interleave is enabled and supported.
> 
> netns intl_enable would be set via procfs, but that is not added yet
> until all stream interleave codes are completely implemented; asoc
> intl_enable will be set when doing 4-shakehands.
> 
Which patch did you implement the per-namespace proc file in?  I don't see it in
the patch that you referenced above
Neil

^ permalink raw reply

* Re: [PATCH tip/core/rcu 21/21] drivers/vhost: Remove now-redundant read_barrier_depends()
From: Michael S. Tsirkin @ 2017-12-05 18:31 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: linux-kernel, mingo, jiangshanlai, dipankar, akpm,
	mathieu.desnoyers, josh, tglx, peterz, rostedt, dhowells,
	edumazet, fweisbec, oleg, Jason Wang, kvm, virtualization, netdev
In-Reply-To: <1512157876-24665-21-git-send-email-paulmck@linux.vnet.ibm.com>

On Fri, Dec 01, 2017 at 11:51:16AM -0800, Paul E. McKenney wrote:
> Because READ_ONCE() now implies read_barrier_depends(), the
> read_barrier_depends() in next_desc() is now redundant.  This commit
> therefore removes it and the related comments.
> 
> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Cc: "Michael S. Tsirkin" <mst@redhat.com>
> Cc: Jason Wang <jasowang@redhat.com>
> Cc: <kvm@vger.kernel.org>
> Cc: <virtualization@lists.linux-foundation.org>
> Cc: <netdev@vger.kernel.org>

Apropos, READ_ONCE is now asymmetrical with WRITE_ONCE.

I can read a pointer with READ_ONCE and be sure the value
is sane, but only if I also remember to put in smp_wmb before
WRITE_ONCE. Otherwise the pointer is ok but no guarantees
about the data pointed to.

It would be better if the API reflected he assymetry somehow.

> ---
>  drivers/vhost/vhost.c | 7 +------
>  1 file changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index 33ac2b186b85..78b5940a415a 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -1877,12 +1877,7 @@ static unsigned next_desc(struct vhost_virtqueue *vq, struct vring_desc *desc)
>  		return -1U;
>  
>  	/* Check they're not leading us off end of descriptors. */
> -	next = vhost16_to_cpu(vq, desc->next);
> -	/* Make sure compiler knows to grab that: we don't want it changing! */
> -	/* We will use the result as an index in an array, so most
> -	 * architectures only need a compiler barrier here. */
> -	read_barrier_depends();
> -
> +	next = vhost16_to_cpu(vq, READ_ONCE(desc->next));
>  	return next;
>  }
>  
> -- 
> 2.5.2

^ permalink raw reply

* Re: [PATCH net-next 07/12] sctp: implement ulpevent_data for sctp_stream_interleave
From: Neil Horman @ 2017-12-05 18:28 UTC (permalink / raw)
  To: Xin Long; +Cc: network dev, linux-sctp, Marcelo Ricardo Leitner, davem
In-Reply-To: <7dd410b23c38f41fb8402880185f5e583dabbc04.1512486606.git.lucien.xin@gmail.com>

On Tue, Dec 05, 2017 at 11:16:04PM +0800, Xin Long wrote:
> ulpevent_data is added as a member of sctp_stream_interleave, used to
> do the most process in ulpq, including to convert data or idata chunk
> to event, reasm them in reasm queue and put them in lobby queue in
> right order, and deliver them up to user sk rx queue.
> 
> This procedure is described in section 2.2.3 of RFC8260.
> 
> It adds most functions for idata here to do the similar process as
> the old functions for data. But since the details are very different
> between them, the old functions can not be reused for idata.
> 
> event->ssn and event->ppid settings are moved to ulpevent_data from
> sctp_ulpevent_make_rcvmsg, so that sctp_ulpevent_make_rcvmsg could
> work for both data and idata.
> 
> Note that mid is added in sctp_ulpevent for idata, __packed has to
> be used for defining sctp_ulpevent, or it would exceeds the skb cb
> that saves a sctp_ulpevent variable for ulp layer process.
> 
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> ---
>  include/net/sctp/stream_interleave.h |   2 +
>  include/net/sctp/structs.h           |   3 +
>  include/net/sctp/ulpevent.h          |  20 +-
>  net/sctp/sm_sideeffect.c             |   5 +-
>  net/sctp/stream_interleave.c         | 418 +++++++++++++++++++++++++++++++++++
>  net/sctp/ulpevent.c                  |   2 -
>  net/sctp/ulpqueue.c                  |  12 +-
>  7 files changed, 451 insertions(+), 11 deletions(-)
> 
> diff --git a/include/net/sctp/stream_interleave.h b/include/net/sctp/stream_interleave.h
> index d8d1b51..02f60f5 100644
> --- a/include/net/sctp/stream_interleave.h
> +++ b/include/net/sctp/stream_interleave.h
> @@ -39,6 +39,8 @@ struct sctp_stream_interleave {
>  					    int len, __u8 flags, gfp_t gfp);
>  	void	(*assign_number)(struct sctp_chunk *chunk);
>  	bool	(*validate_data)(struct sctp_chunk *chunk);
> +	int	(*ulpevent_data)(struct sctp_ulpq *ulpq,
> +				 struct sctp_chunk *chunk, gfp_t gfp);
>  };
>  
>  void sctp_stream_interleave_init(struct sctp_stream *stream);
> diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
> index 348b25e..d7da719 100644
> --- a/include/net/sctp/structs.h
> +++ b/include/net/sctp/structs.h
> @@ -411,6 +411,8 @@ void sctp_stream_update(struct sctp_stream *stream, struct sctp_stream *new);
>  #define sctp_mid_skip(stream, type, sid, mid) \
>  	((stream)->type[sid].mid = mid + 1)
>  
> +#define sctp_stream_in(asoc, sid) (&(asoc)->stream.in[sid])
> +
>  /*
>   * Pointers to address related SCTP functions.
>   * (i.e. things that depend on the address family.)
> @@ -1386,6 +1388,7 @@ struct sctp_stream_in {
>  		__u16 ssn;
>  	};
>  	__u32 fsn;
> +	char pd_mode;
>  };
>  
>  struct sctp_stream {
> diff --git a/include/net/sctp/ulpevent.h b/include/net/sctp/ulpevent.h
> index 231dc42..ce4f2aa 100644
> --- a/include/net/sctp/ulpevent.h
> +++ b/include/net/sctp/ulpevent.h
> @@ -45,19 +45,29 @@
>  /* A structure to carry information to the ULP (e.g. Sockets API) */
>  /* Warning: This sits inside an skb.cb[] area.  Be very careful of
>   * growing this structure as it is at the maximum limit now.
> + *
> + * sctp_ulpevent is saved in sk->cb(48 bytes), whose last 4 bytes
> + * have been taken by sock_skb_cb, So here it has to use 'packed'
> + * to make sctp_ulpevent fit into the rest 44 bytes.
>   */
>  struct sctp_ulpevent {
>  	struct sctp_association *asoc;
>  	struct sctp_chunk *chunk;
>  	unsigned int rmem_len;
> -	__u32 ppid;
> +	union {
> +		__u32 mid;
> +		__u16 ssn;
> +	};
> +	union {
> +		__u32 ppid;
> +		__u32 fsn;
> +	};
>  	__u32 tsn;
>  	__u32 cumtsn;
>  	__u16 stream;
> -	__u16 ssn;
>  	__u16 flags;
>  	__u16 msg_flags;
> -};
> +} __packed;
>  
What kind  of performance do you see before and after this patch?  I ask because
it seems like the members between ppid through stream are going to be misaligned
(not on a 4 byte boundary), now that you've made this structure packed.


Neil

^ permalink raw reply

* Re: [PATCH net 1/2] netlink: add NLA_U8_BUGGY attribute type
From: David Ahern @ 2017-12-05 18:15 UTC (permalink / raw)
  To: David Miller, johannes-cdvu00un1VgdHxzADdlk8Q
  Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
	netdev-u79uwXL29TY76Z2rM5mHXA, j
In-Reply-To: <20171205.124038.2265447675450126665.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>

On 12/5/17 10:40 AM, David Miller wrote:
> From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
> Date: Tue, 05 Dec 2017 18:30:10 +0100
> 
>> On Tue, 2017-12-05 at 11:41 -0500, David Miller wrote:
>>>
>>> There is no reasonable interpretation for what that application is
>>> doing, so I think we can safely call that case as buggy.
>>>
>>> We are only trying to handle the situation where a U8 attribute
>>> is presented as a bonafide U32 or a correct U8.
>>>
>>> Does this make sense?
>>
>> Well the application is buggy, but we don't really know in what way?
>> Perhaps somebody even did the equivalent of
>>     nla_put_u32(ATTR, cpu_to_le32(x))
>> when they noticed it was broken on BE, and end up with a similar case
>> as I had above.
>>
>> I don't think there's a good solution to this, applications must be
>> fixed anyhow. I'm just saying that I'd save the extra code and stay
>> compatible with applications as written today, even if they're now
>> broken on BE - and rely on the warning to fix it. Trying to fix it up
>> seems to have the potential to just break something else.

+1

> 
> You might be right.
> 
> Ok let's just go with the warning + existing behavior for now.

Is the patch I sent as an attachment good or should I re-send
standalone? (don't see it in patchwork)

^ permalink raw reply

* Re: [Intel-wired-lan] [next-queue 08/10] ixgbe: process the Tx ipsec offload
From: Alexander Duyck @ 2017-12-05 18:13 UTC (permalink / raw)
  To: Shannon Nelson
  Cc: intel-wired-lan, Jeff Kirsher, Steffen Klassert, Sowmini Varadhan,
	Netdev
In-Reply-To: <1512452116-14795-9-git-send-email-shannon.nelson@oracle.com>

On Mon, Dec 4, 2017 at 9:35 PM, Shannon Nelson
<shannon.nelson@oracle.com> wrote:
> If the skb has a security association referenced in the skb, then
> set up the Tx descriptor with the ipsec offload bits.  While we're
> here, we fix an oddly named field in the context descriptor struct.
>
> Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com>
> ---
>  drivers/net/ethernet/intel/ixgbe/ixgbe.h       | 10 +++-
>  drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 77 ++++++++++++++++++++++++++
>  drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c   |  4 +-
>  drivers/net/ethernet/intel/ixgbe/ixgbe_main.c  | 38 ++++++++++---
>  drivers/net/ethernet/intel/ixgbe/ixgbe_type.h  |  2 +-
>  5 files changed, 118 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
> index 77f07dc..68097fe 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
> @@ -171,10 +171,11 @@ enum ixgbe_tx_flags {
>         IXGBE_TX_FLAGS_CC       = 0x08,
>         IXGBE_TX_FLAGS_IPV4     = 0x10,
>         IXGBE_TX_FLAGS_CSUM     = 0x20,
> +       IXGBE_TX_FLAGS_IPSEC    = 0x40,
>
>         /* software defined flags */
> -       IXGBE_TX_FLAGS_SW_VLAN  = 0x40,
> -       IXGBE_TX_FLAGS_FCOE     = 0x80,
> +       IXGBE_TX_FLAGS_SW_VLAN  = 0x80,
> +       IXGBE_TX_FLAGS_FCOE     = 0x100,
>  };
>
>  /* VLAN info */
> @@ -1012,12 +1013,17 @@ void ixgbe_init_ipsec_offload(struct ixgbe_adapter *adapter);
>  void ixgbe_ipsec_rx(struct ixgbe_ring *rx_ring,
>                     union ixgbe_adv_rx_desc *rx_desc,
>                     struct sk_buff *skb);
> +int ixgbe_ipsec_tx(struct ixgbe_ring *tx_ring, struct sk_buff *skb,
> +                  __be16 protocol, struct ixgbe_ipsec_tx_data *itd);
>  void ixgbe_ipsec_restore(struct ixgbe_adapter *adapter);
>  #else
>  static inline void ixgbe_init_ipsec_offload(struct ixgbe_adapter *adapter) { };
>  static inline void ixgbe_ipsec_rx(struct ixgbe_ring *rx_ring,
>                                   union ixgbe_adv_rx_desc *rx_desc,
>                                   struct sk_buff *skb) { };
> +static inline int ixgbe_ipsec_tx(struct ixgbe_ring *tx_ring,
> +                                struct sk_buff *skb, __be16 protocol,
> +                                struct ixgbe_ipsec_tx_data *itd) { return 0; };
>  static inline void ixgbe_ipsec_restore(struct ixgbe_adapter *adapter) { };
>  #endif /* CONFIG_XFRM_OFFLOAD */
>  #endif /* _IXGBE_H_ */
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
> index fd06d9b..2a0dd7a 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
> @@ -703,12 +703,89 @@ static void ixgbe_ipsec_del_sa(struct xfrm_state *xs)
>         }
>  }
>
> +/**
> + * ixgbe_ipsec_offload_ok - can this packet use the xfrm hw offload
> + * @skb: current data packet
> + * @xs: pointer to transformer state struct
> + **/
> +static bool ixgbe_ipsec_offload_ok(struct sk_buff *skb, struct xfrm_state *xs)
> +{
> +       if (xs->props.family == AF_INET) {
> +               /* Offload with IPv4 options is not supported yet */
> +               if (ip_hdr(skb)->ihl > 5)

I would make this ihl != 5 instead of "> 5" since smaller values would
be invalid as well.

> +                       return false;
> +       } else {
> +               /* Offload with IPv6 extension headers is not support yet */
> +               if (ipv6_ext_hdr(ipv6_hdr(skb)->nexthdr))
> +                       return false;
> +       }
> +
> +       return true;
> +}
> +
>  static const struct xfrmdev_ops ixgbe_xfrmdev_ops = {
>         .xdo_dev_state_add = ixgbe_ipsec_add_sa,
>         .xdo_dev_state_delete = ixgbe_ipsec_del_sa,
> +       .xdo_dev_offload_ok = ixgbe_ipsec_offload_ok,
>  };
>
>  /**
> + * ixgbe_ipsec_tx - setup Tx flags for ipsec offload
> + * @tx_ring: outgoing context
> + * @skb: current data packet
> + * @protocol: network protocol
> + * @itd: ipsec Tx data for later use in building context descriptor
> + **/
> +int ixgbe_ipsec_tx(struct ixgbe_ring *tx_ring, struct sk_buff *skb,
> +                  __be16 protocol, struct ixgbe_ipsec_tx_data *itd)
> +{
> +       struct ixgbe_adapter *adapter = netdev_priv(tx_ring->netdev);
> +       struct ixgbe_ipsec *ipsec = adapter->ipsec;
> +       struct xfrm_state *xs;
> +       struct tx_sa *tsa;
> +
> +       if (!skb->sp->len) {
> +               netdev_err(tx_ring->netdev, "%s: no xfrm state len = %d\n",
> +                          __func__, skb->sp->len);
> +               return 0;
> +       }
> +
> +       xs = xfrm_input_state(skb);
> +       if (!xs) {
> +               netdev_err(tx_ring->netdev, "%s: no xfrm_input_state() xs = %p\n",
> +                          __func__, xs);
> +               return 0;
> +       }
> +
> +       itd->sa_idx = xs->xso.offload_handle - IXGBE_IPSEC_BASE_TX_INDEX;
> +       if (itd->sa_idx > IXGBE_IPSEC_MAX_SA_COUNT) {
> +               netdev_err(tx_ring->netdev, "%s: bad sa_idx=%d handle=%lu\n",
> +                          __func__, itd->sa_idx, xs->xso.offload_handle);
> +               return 0;
> +       }
> +
> +       tsa = &ipsec->tx_tbl[itd->sa_idx];
> +       if (!tsa->used) {
> +               netdev_err(tx_ring->netdev, "%s: unused sa_idx=%d\n",
> +                          __func__, itd->sa_idx);
> +               return 0;
> +       }
> +
> +       itd->flags = 0;
> +       if (xs->id.proto == IPPROTO_ESP) {
> +               itd->flags |= IXGBE_ADVTXD_TUCMD_IPSEC_TYPE_ESP |
> +                             IXGBE_ADVTXD_TUCMD_L4T_TCP;

Why is the TCP value being set here? This doesn't seem correct either.
This implies TCP a TCP offload. It seems like this should only be
setting ESP.

> +               if (protocol == htons(ETH_P_IP))
> +                       itd->flags |= IXGBE_ADVTXD_TUCMD_IPV4;

Does the IPsec offload need to know if the frame is v4 or v6? I'm just
wondering if it does or not. If not then this probably isn't needed.
One thought on this line is you might look at moving it into
ixgbe_tx_csum. If setting the bit is harmless without setting IXSM we
might look at moving it into the end of ixgbe_tx_csum and just make it
compare against first->protocol there.

> +               itd->trailer_len = xs->props.trailer_len;
> +       }
> +       if (tsa->encrypt)
> +               itd->flags |= IXGBE_ADVTXD_TUCMD_IPSEC_ENCRYPT_EN;
> +
> +       return 1;
> +}
> +
> +/**
>   * ixgbe_ipsec_rx - decode ipsec bits from Rx descriptor
>   * @rx_ring: receiving ring
>   * @rx_desc: receive data descriptor
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c
> index f1bfae0..d7875b3 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c
> @@ -1261,7 +1261,7 @@ void ixgbe_clear_interrupt_scheme(struct ixgbe_adapter *adapter)
>  }
>
>  void ixgbe_tx_ctxtdesc(struct ixgbe_ring *tx_ring, u32 vlan_macip_lens,
> -                      u32 fcoe_sof_eof, u32 type_tucmd, u32 mss_l4len_idx)
> +                      u32 fceof_saidx, u32 type_tucmd, u32 mss_l4len_idx)
>  {
>         struct ixgbe_adv_tx_context_desc *context_desc;
>         u16 i = tx_ring->next_to_use;
> @@ -1275,7 +1275,7 @@ void ixgbe_tx_ctxtdesc(struct ixgbe_ring *tx_ring, u32 vlan_macip_lens,
>         type_tucmd |= IXGBE_TXD_CMD_DEXT | IXGBE_ADVTXD_DTYP_CTXT;
>
>         context_desc->vlan_macip_lens   = cpu_to_le32(vlan_macip_lens);
> -       context_desc->seqnum_seed       = cpu_to_le32(fcoe_sof_eof);
> +       context_desc->fceof_saidx       = cpu_to_le32(fceof_saidx);
>         context_desc->type_tucmd_mlhl   = cpu_to_le32(type_tucmd);
>         context_desc->mss_l4len_idx     = cpu_to_le32(mss_l4len_idx);
>  }
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> index 60f9f2d..c857594 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> @@ -7659,9 +7659,10 @@ static void ixgbe_service_task(struct work_struct *work)
>
>  static int ixgbe_tso(struct ixgbe_ring *tx_ring,
>                      struct ixgbe_tx_buffer *first,
> -                    u8 *hdr_len)
> +                    u8 *hdr_len,
> +                    struct ixgbe_ipsec_tx_data *itd)
>  {
> -       u32 vlan_macip_lens, type_tucmd, mss_l4len_idx;
> +       u32 vlan_macip_lens, type_tucmd, mss_l4len_idx, fceof_saidx = 0;
>         struct sk_buff *skb = first->skb;
>         union {
>                 struct iphdr *v4;
> @@ -7740,7 +7741,12 @@ static int ixgbe_tso(struct ixgbe_ring *tx_ring,
>         vlan_macip_lens |= (ip.hdr - skb->data) << IXGBE_ADVTXD_MACLEN_SHIFT;
>         vlan_macip_lens |= first->tx_flags & IXGBE_TX_FLAGS_VLAN_MASK;
>
> -       ixgbe_tx_ctxtdesc(tx_ring, vlan_macip_lens, 0, type_tucmd,
> +       if (first->tx_flags & IXGBE_TX_FLAGS_IPSEC) {
> +               fceof_saidx |= itd->sa_idx;
> +               type_tucmd |= itd->flags | itd->trailer_len;
> +       }
> +
> +       ixgbe_tx_ctxtdesc(tx_ring, vlan_macip_lens, fceof_saidx, type_tucmd,
>                           mss_l4len_idx);
>
>         return 1;
> @@ -7756,10 +7762,12 @@ static inline bool ixgbe_ipv6_csum_is_sctp(struct sk_buff *skb)
>  }
>
>  static void ixgbe_tx_csum(struct ixgbe_ring *tx_ring,
> -                         struct ixgbe_tx_buffer *first)
> +                         struct ixgbe_tx_buffer *first,
> +                         struct ixgbe_ipsec_tx_data *itd)
>  {
>         struct sk_buff *skb = first->skb;
>         u32 vlan_macip_lens = 0;
> +       u32 fceof_saidx = 0;
>         u32 type_tucmd = 0;
>
>         if (skb->ip_summed != CHECKSUM_PARTIAL) {
> @@ -7800,7 +7808,12 @@ static void ixgbe_tx_csum(struct ixgbe_ring *tx_ring,
>         vlan_macip_lens |= skb_network_offset(skb) << IXGBE_ADVTXD_MACLEN_SHIFT;
>         vlan_macip_lens |= first->tx_flags & IXGBE_TX_FLAGS_VLAN_MASK;
>
> -       ixgbe_tx_ctxtdesc(tx_ring, vlan_macip_lens, 0, type_tucmd, 0);
> +       if (first->tx_flags & IXGBE_TX_FLAGS_IPSEC) {
> +               fceof_saidx |= itd->sa_idx;
> +               type_tucmd |= itd->flags | itd->trailer_len;
> +       }
> +
> +       ixgbe_tx_ctxtdesc(tx_ring, vlan_macip_lens, fceof_saidx, type_tucmd, 0);
>  }
>
>  #define IXGBE_SET_FLAG(_input, _flag, _result) \
> @@ -7843,11 +7856,16 @@ static void ixgbe_tx_olinfo_status(union ixgbe_adv_tx_desc *tx_desc,
>                                         IXGBE_TX_FLAGS_CSUM,
>                                         IXGBE_ADVTXD_POPTS_TXSM);
>
> -       /* enble IPv4 checksum for TSO */
> +       /* enable IPv4 checksum for TSO */
>         olinfo_status |= IXGBE_SET_FLAG(tx_flags,
>                                         IXGBE_TX_FLAGS_IPV4,
>                                         IXGBE_ADVTXD_POPTS_IXSM);
>
> +       /* enable IPsec */
> +       olinfo_status |= IXGBE_SET_FLAG(tx_flags,
> +                                       IXGBE_TX_FLAGS_IPSEC,
> +                                       IXGBE_ADVTXD_POPTS_IPSEC);
> +
>         /*
>          * Check Context must be set if Tx switch is enabled, which it
>          * always is for case where virtual functions are running
> @@ -8306,6 +8324,7 @@ netdev_tx_t ixgbe_xmit_frame_ring(struct sk_buff *skb,
>         u32 tx_flags = 0;
>         unsigned short f;
>         u16 count = TXD_USE_COUNT(skb_headlen(skb));
> +       struct ixgbe_ipsec_tx_data ipsec_tx = { 0 };
>         __be16 protocol = skb->protocol;
>         u8 hdr_len = 0;
>
> @@ -8394,6 +8413,9 @@ netdev_tx_t ixgbe_xmit_frame_ring(struct sk_buff *skb,
>                 }
>         }
>
> +       if (skb->sp && ixgbe_ipsec_tx(tx_ring, skb, protocol, &ipsec_tx))
> +               tx_flags |= IXGBE_TX_FLAGS_IPSEC | IXGBE_TX_FLAGS_CC;

You might just want to pull the skb->sp check into ixgbe_ipsec_tx and
could pass tx_flags as a part of the first buffer. It doesn't really
matter anyway as most of this will just be inlined so it will all end
up a part of the same function anyway.

Also I would move this down so that it is handled after the fields in
the first buffer_info structure are set. Then this can ll just fall
inline with the TSO block and get handled there.

> +
>         /* record initial flags and protocol */
>         first->tx_flags = tx_flags;
>         first->protocol = protocol;
> @@ -8410,11 +8432,11 @@ netdev_tx_t ixgbe_xmit_frame_ring(struct sk_buff *skb,
>         }
>
>  #endif /* IXGBE_FCOE */

So if you move the function down here it will help to avoid any other
complication. In addition you could follow the same logic that we do
for ixgbe_tso/fso so you could drop the frame instead of transmitting
it if it is requesting a bad offload.

> -       tso = ixgbe_tso(tx_ring, first, &hdr_len);
> +       tso = ixgbe_tso(tx_ring, first, &hdr_len, &ipsec_tx);
>         if (tso < 0)
>                 goto out_drop;
>         else if (!tso)
> -               ixgbe_tx_csum(tx_ring, first);
> +               ixgbe_tx_csum(tx_ring, first, &ipsec_tx);
>
>         /* add the ATR filter if ATR is on */
>         if (test_bit(__IXGBE_TX_FDIR_INIT_DONE, &tx_ring->state))
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
> index 3df0763..0ac725fa 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
> @@ -2856,7 +2856,7 @@ union ixgbe_adv_rx_desc {
>  /* Context descriptors */
>  struct ixgbe_adv_tx_context_desc {
>         __le32 vlan_macip_lens;
> -       __le32 seqnum_seed;
> +       __le32 fceof_saidx;
>         __le32 type_tucmd_mlhl;
>         __le32 mss_l4len_idx;
>  };
> --
> 2.7.4
>
> _______________________________________________
> Intel-wired-lan mailing list
> Intel-wired-lan@osuosl.org
> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

^ permalink raw reply

* Re: [PATCH net-next 2/4] bnxt_en: Use NETIF_F_GRO_HW.
From: Marcelo Ricardo Leitner @ 2017-12-05 18:10 UTC (permalink / raw)
  To: Michael Chan; +Cc: Eric Dumazet, Or Gerlitz, David Miller, Linux Netdev List
In-Reply-To: <CACKFLi=nDh_xfwwa6jp-amKp21+9SdeUA4TcrVGGvmi8UKGv3A@mail.gmail.com>

On Mon, Dec 04, 2017 at 04:07:15PM -0800, Michael Chan wrote:
> As already pointed out, GRO_HW is a subset of GRO.  Packets that
> cannot be aggregated in hardware (due to hardware resource limitations
> or protocol types that it doesn't handle) can just be passed to the
> stack for GRO aggregation.

How would the parameters/limits work in this case? I mean, currently
we have the default weight of 64 packets per napi poll cycle, the
budget of 300 per cycle and also the time constrain,
net.core.netdev_budget_usecs.

With GRO_HW, this 64 limit may be exceeded. I'm looking at qede code
and it works by couting each completion as 1 rcv_pkts
(qede_fp.c:1318). So if it now gets 64 packets, it's up to 64*MTU
aprox, GRO'ed or not. But with GRO_HW, seems it may be much more than
that and which may not be fair with other interfaces in the system.
Drivers supporting GRO_HW probably should account for this.

And how can one control how much time a packet may spend on NIC queue
waiting to be GRO'ed? Does it use the coalescing parameters for that?

  Marcelo

^ permalink raw reply

* Re: [PATCH net-next v3 2/4] phylib: add reset after clk enable support
From: Richard Leitner @ 2017-12-05 18:08 UTC (permalink / raw)
  To: Andrew Lunn, Richard Leitner
  Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
	fugang.duan-3arQi8VN3Tc, f.fainelli-Re5JQEeQqe8AvxtiuMwx3w,
	frowand.list-Re5JQEeQqe8AvxtiuMwx3w, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
	geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
	sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8,
	baruch-NswTu9S1W3P6gbPvEgmw2w, david.wu-TNX95d0MmH7DzftRWevZcw,
	lukma-ynQEQJNshbs, netdev-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171205173407.GN12805-g2DYL2Zd6BY@public.gmane.org>

Hi Andrew,

On 12/05/2017 06:34 PM, Andrew Lunn wrote:
> On Tue, Dec 05, 2017 at 02:25:58PM +0100, Richard Leitner wrote:
>> From: Richard Leitner <richard.leitner-WcANXNA0UjBBDgjK7y7TUQ@public.gmane.org>
>>
>> Some PHYs need the refclk to be a continuous clock. Therefore they don't
>> allow turning it off and on again during operation. Nonetheless such a
>> clock switching is performed by some ETH drivers (namely FEC [1]) for
>> power saving reasons. An example for an affected PHY is the
>> SMSC/Microchip LAN8720 in "REF_CLK In Mode".
>>
>> In order to provide a uniform method to overcome this problem this patch
>> adds a new phy_driver flag (PHY_RST_AFTER_CLK_EN) and corresponding
>> function phy_reset_after_clk_enable() to the phylib. These should be
>> used to trigger reset of the PHY after the refclk is switched on again.
>>
>> This patch depends on the "phylib: Add device reset GPIO support" patch
>> submitted by Geert Uytterhoeven/Sergei Shtylyov [2].
>>
>> [1] commit e8fcfcd5684a ("net: fec: optimize the clock management to save power")
>> [2] https://patchwork.kernel.org/patch/10090149/
>>
>> Signed-off-by: Richard Leitner <richard.leitner-WcANXNA0UjBBDgjK7y7TUQ@public.gmane.org>
> 
> Hi Richard
> 
> Same comment about moving text below the ---

Ok. Thanks for your feedback and review.

> 
> Reviewed-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
> 

regards;Richard.L

>      Andrew
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH net-next v3 1/4] phylib: Add device reset delay support
From: Richard Leitner @ 2017-12-05 18:06 UTC (permalink / raw)
  To: Andrew Lunn, Richard Leitner
  Cc: robh+dt, mark.rutland, fugang.duan, f.fainelli, frowand.list,
	davem, geert+renesas, sergei.shtylyov, baruch, david.wu, lukma,
	netdev, devicetree, linux-kernel
In-Reply-To: <20171205172852.GM12805@lunn.ch>

Hi Andrew,

On 12/05/2017 06:28 PM, Andrew Lunn wrote:
> Hi Richard
> 
>> +++ b/drivers/of/of_mdio.c
>> @@ -77,6 +77,14 @@ static int of_mdiobus_register_phy(struct mii_bus *mdio,
>>   	if (of_property_read_bool(child, "broken-turn-around"))
>>   		mdio->phy_ignore_ta_mask |= 1 << addr;
>>   
>> +	if (of_property_read_u32(child, "reset-delay-us",
>> +				 &phy->mdio.reset_delay))
>> +		phy->mdio.reset_delay = 0;
>> +
>> +	if (of_property_read_u32(child, "reset-post-delay-us",
>> +				 &phy->mdio.reset_post_delay))
>> +		phy->mdio.reset_post_delay = 0;
> 
> of_property_read_u32() should not change the variable you pass to it,
> if it does not find the property. So you can change this to:
> 
> 	phy->mdio.reset_delay = 0;
> 	phy->mdio.reset_post_delay = 0;
> 
> 	of_property_read_u32(child, "reset-delay-us",
> 			     &phy->mdio.reset_delay);
> 
> 	of_property_read_u32(child, "reset-post-delay-us",
> 			     &phy->mdio.reset_post_delay);

Geert already pointed this out, but he said it's possible to omit also 
the zeroing of the variables.

 > On 12/05/2017 02:54 PM, Geert Uytterhoeven wrote:
 >> If of_property_read_u32() fails, it doesn't write to its output
 >> parameter.
 >> As the structure should be zeroed during allocation, you can just
 >> write:
 >>
 >> of_property_read_u32(child, "reset-delay-us",&phy->mdio.reset_delay);
 >> of_property_read_u32(child, "reset-post-delay-us",
 >>                      &phy->mdio.reset_post_delay);

If that's ok I'll take the shorter (Geerts) suggestion for v4.

Nonetheless thanks for your quick feedback!

regards;Richard.L

^ permalink raw reply

* Re: [RFC PATCH] net: stmmac: enable EEE in MII, GMII or RGMII only
From: Andrew Lunn @ 2017-12-05 18:03 UTC (permalink / raw)
  To: Jerome Brunet
  Cc: Giuseppe Cavallaro, Alexandre Torgue, netdev, linux-amlogic,
	linux-kernel
In-Reply-To: <20171205102809.4347-1-jbrunet@baylibre.com>

>  bool stmmac_eee_init(struct stmmac_priv *priv)
>  {
>  	struct net_device *ndev = priv->dev;
> +	int interface = priv->plat->interface;
>  	unsigned long flags;
>  	bool ret = false;
>  
> +	if ((interface != PHY_INTERFACE_MODE_MII) &&
> +	    (interface != PHY_INTERFACE_MODE_GMII) &&
> +	    (interface != PHY_INTERFACE_MODE_RGMII) &&
> +	    (interface != PHY_INTERFACE_MODE_RGMII_ID) &&
> +	    (interface != PHY_INTERFACE_MODE_RGMII_TXID) &&
> +	    (interface != PHY_INTERFACE_MODE_RGMII_RXID))
> +		goto out;

phy_interface_mode_is_rgmii() will make this smaller.

      Andrew

^ permalink raw reply

* Re: [PATCH net-next] net: phy: meson-gxl: cleanup by defining the control registers
From: Andrew Lunn @ 2017-12-05 18:01 UTC (permalink / raw)
  To: Jerome Brunet
  Cc: Florian Fainelli, Neil Armstrong, netdev, linux-amlogic,
	linux-kernel
In-Reply-To: <20171205093334.8261-1-jbrunet@baylibre.com>

On Tue, Dec 05, 2017 at 10:33:34AM +0100, Jerome Brunet wrote:
> From: Neil Armstrong <narmstrong@baylibre.com>
> 
> Define registers and bits in meson-gxl PHY driver to make a bit
> more human friendly. No functional change


>  static int meson_gxl_config_init(struct phy_device *phydev)
>  {
> -	/* Enable Analog and DSP register Bank access by */
> -	phy_write(phydev, 0x14, 0x0000);
> -	phy_write(phydev, 0x14, 0x0400);
> -	phy_write(phydev, 0x14, 0x0000);
> -	phy_write(phydev, 0x14, 0x0400);
> +	int ret;
>  
> -	/* Write Analog register 23 */
> -	phy_write(phydev, 0x17, 0x8E0D);
> -	phy_write(phydev, 0x14, 0x4417);
> +	/* Write PLL Configuration 1 */
> +	ret = meson_gxl_write_reg(phydev, BANK_ANALOG_DSP, A6_CONFIG_REG,
> +				  A6_CONFIG_PLLMULX4ICH |
> +				  FIELD_PREP(A6_CONFIG_PLLBUFITRIM, 7) |
> +				  A6_CONFIG_PLLRSTVCOPD |
> +				  A6_CONFIG_PLLCPOFF |
> +				  A6_CONFIG_PLL_SRC);
> +	if (ret)
> +		return ret;

This does not look like "No functional Change".

Please can you break this up. First make use of #defines.
That should be a clear "No functional Change".

Then a second patch adding a helper for banked registers?

     Thanks
	Andrew

^ permalink raw reply

* Re: [PATCH v2] net: sh_eth: do not advertise Gigabit capabilities when not available
From: Andrew Lunn @ 2017-12-05 17:55 UTC (permalink / raw)
  To: Thomas Petazzoni
  Cc: David S. Miller, Sergei Shtylyov, Niklas Söderlund,
	Geert Uytterhoeven, Simon Horman, netdev, linux-renesas-soc
In-Reply-To: <20171205092952.3455-1-thomas.petazzoni@free-electrons.com>

On Tue, Dec 05, 2017 at 10:29:52AM +0100, Thomas Petazzoni wrote:
> Not all variants of the sh_eth hardware have Gigabit
> support. Unfortunately, the current driver doesn't tell the PHY about
> the limited MAC capabilities. Due to this, if you have a Gigabit
> capable PHY, the PHY will advertise its Gigabit capability and
> establish a link at 1Gbit/s, even though the MAC doesn't support it.
> 
> In order to avoid this, we use the recently introduced
> phy_set_max_speed() to tell the PHY to not advertise speed higher than
> 100 MBit/s.
> 
> Tested on a SH7786 platform, with a Gigabit PHY.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew

^ permalink raw reply

* Re: [PATCH v4 0/4] Teach phylib hard-resetting devices
From: David Miller @ 2017-12-05 17:51 UTC (permalink / raw)
  To: geert+renesas
  Cc: andrew, f.fainelli, horms, magnus.damm, sergei.shtylyov, robh+dt,
	mark.rutland, nicolas.ferre, richard.leitner, netdev, devicetree,
	linux-renesas-soc, linux-kernel
In-Reply-To: <1512383692-14009-1-git-send-email-geert+renesas@glider.be>

From: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Mon,  4 Dec 2017 11:34:48 +0100

> This patch series adds optional PHY reset support to phylib.

Patch #1 and #2 applied to net-next, using v4.1 of patch #1.

Thanks.

^ permalink raw reply

* Re: [PATCH net 1/2] netlink: add NLA_U8_BUGGY attribute type
From: David Miller @ 2017-12-05 17:40 UTC (permalink / raw)
  To: johannes; +Cc: linux-wireless, netdev, j, dsahern
In-Reply-To: <1512495010.26976.24.camel@sipsolutions.net>

From: Johannes Berg <johannes@sipsolutions.net>
Date: Tue, 05 Dec 2017 18:30:10 +0100

> On Tue, 2017-12-05 at 11:41 -0500, David Miller wrote:
>> 
>> There is no reasonable interpretation for what that application is
>> doing, so I think we can safely call that case as buggy.
>> 
>> We are only trying to handle the situation where a U8 attribute
>> is presented as a bonafide U32 or a correct U8.
>> 
>> Does this make sense?
> 
> Well the application is buggy, but we don't really know in what way?
> Perhaps somebody even did the equivalent of
>     nla_put_u32(ATTR, cpu_to_le32(x))
> when they noticed it was broken on BE, and end up with a similar case
> as I had above.
> 
> I don't think there's a good solution to this, applications must be
> fixed anyhow. I'm just saying that I'd save the extra code and stay
> compatible with applications as written today, even if they're now
> broken on BE - and rely on the warning to fix it. Trying to fix it up
> seems to have the potential to just break something else.

You might be right.

Ok let's just go with the warning + existing behavior for now.

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox