* RE: [RFC v1 17/19] RDMA/irdma: Add ABI definitions
From: Saleem, Shiraz @ 2019-02-20 14:52 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: dledford@redhat.com, davem@davemloft.net,
linux-rdma@vger.kernel.org, netdev@vger.kernel.org,
Ismail, Mustafa, Kirsher, Jeffrey T
In-Reply-To: <20190215171638.GA30706@ziepe.ca>
>Subject: Re: [RFC v1 17/19] RDMA/irdma: Add ABI definitions
>
>On Fri, Feb 15, 2019 at 11:11:04AM -0600, Shiraz Saleem wrote:
>> From: Mustafa Ismail <mustafa.ismail@intel.com>
>>
>> Add ABI definitions for irdma.
[....]
>>
>> +
>> +#include <linux/types.h>
>> +
>> +#define IRDMA_ABI_VER 6
>
>Starting with high numbers?
It's a bump on the current i40iw ABI ver. of 5 since we
want to be compatible and support current rdma-core's libi40iw
for Gen1 (X722) device.
>
>> +enum irdma_memreg_type {
>> + IW_MEMREG_TYPE_MEM = 0,
>> + IW_MEMREG_TYPE_QP = 1,
>> + IW_MEMREG_TYPE_CQ = 2,
>> + IW_MEMREG_TYPE_RSVD = 3,
>> + IW_MEMREG_TYPE_MW = 4,
>> +};
>> +
>> +struct irdma_alloc_ucontext_req {
>> + __u32 rsvd32;
>> + __u8 userspace_ver;
>> + __u8 rsvd8[3];
>> +};
>> +
>> +struct irdma_alloc_ucontext_resp {
>> + __u8 kernel_ver;
>> + __u8 rsvd[7];
>> + struct irdma_hw_attrs hw_attrs;
>
>This won't even compile like this - don't forget you have to send the rdma-core
>PR along with the kernel patches. You should already be running the travis
>checks yourself. rdma-core should detect malformed user space headers..
Yes. We will be sending the rdma-core patches soon.
Maybe we are missing something here, but this did compile with libirdma
in rdma-core-v22, but we havent run travis checks yet.
>
>> +struct irdma_mem_reg_req {
>> + __u16 reg_type; /* Memory, QP or CQ */
>> + __u16 cq_pages;
>> + __u16 rq_pages;
>> + __u16 sq_pages;
>> +};
>
>New structs should be aligned to 8 bytes.
>
>> +struct i40iw_create_qp_resp {
>> + __u32 qp_id;
>> + __u32 actual_sq_size;
>> + __u32 actual_rq_size;
>> + __u32 i40iw_drv_opt;
>> + __u16 push_idx;
>> + __u8 lsmm;
>> + __u8 rsvd2;
>> +};
>
>ditto
This is not aligned to 8 bytes. But the previous one is ok right?
>
>> +struct irdma_create_ah_resp {
>> + __u32 ah_id;
>> + __u32 rsvd[4];
>
>typo? __u8?
>
Yes. Thanks!
^ permalink raw reply
* RE: [RFC v1 12/19] RDMA/irdma: Implement device supported verb APIs
From: Saleem, Shiraz @ 2019-02-20 14:52 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: dledford@redhat.com, davem@davemloft.net,
linux-rdma@vger.kernel.org, netdev@vger.kernel.org,
Ismail, Mustafa, Kirsher, Jeffrey T
In-Reply-To: <20190215173539.GD30706@ziepe.ca>
>Subject: Re: [RFC v1 12/19] RDMA/irdma: Implement device supported verb APIs
>
>On Fri, Feb 15, 2019 at 11:10:59AM -0600, Shiraz Saleem wrote:
>
>> +static int irdma_alloc_pd(struct ib_pd *pd,
>> + struct ib_ucontext *context,
>> + struct ib_udata *udata)
>> +{
>> + struct irdma_pd *iwpd = to_iwpd(pd);
>> + struct irdma_device *iwdev = to_iwdev(pd->device);
>> + struct irdma_sc_dev *dev = &iwdev->rf->sc_dev;
>> + struct irdma_pci_f *rf = iwdev->rf;
>> + struct irdma_alloc_pd_resp uresp = {};
>> + struct irdma_sc_pd *sc_pd;
>> + struct irdma_ucontext *ucontext;
>> + u32 pd_id = 0;
>> + int err;
>> +
>> + if (iwdev->closing)
>> + return -ENODEV;
>
>No crazy unlocked 'closing' flags. The core code takes care of everything a driver
>needs to worry about if you use it properly.
OK. We are revisiting the use of this flag and need for internal refcnts
maintained on objects like the one you pointed out in other patch
(irdma_add_pdusecount). It will likely be dropped.
>
>> +/**
>> + * irdma_create_cq - create cq
>> + * @ibdev: device pointer from stack
>> + * @attr: attributes for cq
>> + * @context: user context created during alloc
>> + * @udata: user data
>> + */
>> +static struct ib_cq *irdma_create_cq(struct ib_device *ibdev,
>> + const struct ib_cq_init_attr *attr,
>> + struct ib_ucontext *context,
>> + struct ib_udata *udata)
>> +{
>> + struct irdma_device *iwdev = to_iwdev(ibdev);
>> + struct irdma_pci_f *rf = iwdev->rf;
>> + struct irdma_cq *iwcq;
>> + struct irdma_pbl *iwpbl;
>> + u32 cq_num = 0;
>> + struct irdma_sc_cq *cq;
>> + struct irdma_sc_dev *dev = &rf->sc_dev;
>> + struct irdma_cq_init_info info = {};
>> + enum irdma_status_code status;
>> + struct irdma_cqp_request *cqp_request;
>> + struct cqp_cmds_info *cqp_info;
>> + struct irdma_cq_uk_init_info *ukinfo = &info.cq_uk_init_info;
>> + unsigned long flags;
>> + int err_code;
>> + int entries = attr->cqe;
>> +
>> + if (iwdev->closing)
>> + return ERR_PTR(-ENODEV);
>> +
>> + if (entries > rf->max_cqe)
>> + return ERR_PTR(-EINVAL);
>> +
>> + iwcq = kzalloc(sizeof(*iwcq), GFP_KERNEL);
>> + if (!iwcq)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + err_code = irdma_alloc_rsrc(rf, rf->allocated_cqs,
>> + rf->max_cq, &cq_num,
>> + &rf->next_cq);
>> + if (err_code)
>> + goto error;
>> +
>> + cq = &iwcq->sc_cq;
>> + cq->back_cq = (void *)iwcq;
>> + spin_lock_init(&iwcq->lock);
>> + info.dev = dev;
>> + ukinfo->cq_size = max(entries, 4);
>> + ukinfo->cq_id = cq_num;
>> + iwcq->ibcq.cqe = info.cq_uk_init_info.cq_size;
>> + if (attr->comp_vector < rf->ceqs_count)
>> + info.ceq_id = attr->comp_vector;
>> + info.ceq_id_valid = true;
>> + info.ceqe_mask = 1;
>> + info.type = IRDMA_CQ_TYPE_IWARP;
>> + info.vsi = &iwdev->vsi;
>> +
>> + if (context) {
>
>Drivers should rarely write 'if context'. The test for userspaceness is 'if (udata)' -
>and in this case context is guarenteed. Lots of places with this wrong..
>
>Also this will need to be rebased as this all changed.
Will fix.
>
>> + return (struct ib_cq *)iwcq;
>
>And don't write casts like that, &iwcq->ib_qp or something.
>
>Find and fix them all please.
OK.
>
>> +/**
>> + * irdma_set_page - populate pbl list for fmr
>> + * @ibmr: ib mem to access iwarp mr pointer
>> + * @addr: page dma address fro pbl list */ static int
>> +irdma_set_page(struct ib_mr *ibmr,
>> + u64 addr)
>
>Can you please read through this giant driver and hit various places with wonky
>formatting with clang-format? We don't need to start out a new driver with bonkers
>indentation.
Will run clang-format. This should have been on on one line and not split.
>> +
>> +static const struct ib_device_ops irdma_roce_dev_ops = {
>> + .get_link_layer = irdma_get_link_layer,
>> + .query_ah = irdma_query_ah,
>> + .attach_mcast = irdma_attach_mcast,
>> + .detach_mcast = irdma_detach_mcast,
>> + .query_gid = irdma_query_gid_roce,
>> + .modify_qp = irdma_modify_qp_roce,
>> +};
>> +
>> +static const struct ib_device_ops irdma_iw_dev_ops = {
>> + .query_gid = irdma_query_gid,
>> + .modify_qp = irdma_modify_qp,
>> +};
>> +
>> +static const struct ib_device_ops irdma_dev_ops = {
>> + .get_port_immutable = irdma_port_immutable,
>> + .get_netdev = irdma_get_netdev,
>> + .query_port = irdma_query_port,
>> + .modify_port = irdma_modify_port,
>> + .query_pkey = irdma_query_pkey,
>> + .alloc_ucontext = irdma_alloc_ucontext,
>> + .dealloc_ucontext = irdma_dealloc_ucontext,
>> + .mmap = irdma_mmap,
>> + .alloc_pd = irdma_alloc_pd,
>> + .dealloc_pd = irdma_dealloc_pd,
>> + .create_qp = irdma_create_qp,
>> + .query_qp = irdma_query_qp,
>> + .destroy_qp = irdma_destroy_qp,
>> + .create_cq = irdma_create_cq,
>> + .destroy_cq = irdma_destroy_cq,
>> + .get_dma_mr = irdma_get_dma_mr,
>> + .reg_user_mr = irdma_reg_user_mr,
>> + .dereg_mr = irdma_dereg_mr,
>> + .alloc_mw = irdma_alloc_mw,
>> + .dealloc_mw = irdma_dealloc_mw,
>> + .alloc_hw_stats = irdma_alloc_hw_stats,
>> + .get_hw_stats = irdma_get_hw_stats,
>> + .query_device = irdma_query_device,
>> + .create_ah = irdma_create_ah,
>> + .destroy_ah = irdma_destroy_ah,
>> + .drain_sq = irdma_drain_sq,
>> + .drain_rq = irdma_drain_rq,
>> + .alloc_mr = irdma_alloc_mr,
>> + .map_mr_sg = irdma_map_mr_sg,
>> + .get_dev_fw_str = irdma_get_dev_fw_str,
>> + .poll_cq = irdma_poll_cq,
>> + .req_notify_cq = irdma_req_notify_cq,
>> + .post_send = irdma_post_send,
>> + .post_recv = irdma_post_recv,
>> + .disassociate_ucontext = irdma_disassociate_ucontext,
>> + INIT_RDMA_OBJ_SIZE(ib_pd, irdma_pd, ibpd), };
>
>All lists of things should be sorted. I saw many examples of unsorted lists.
>
OK. We weren't aware of this rule in kernel drivers. Is this subsystem specific?
>> +/**
>> + * irdma_init_roce_device - initialization of iwarp rdma device
>> + * @iwibdev: irdma ib device
>> + */
>> +static int irdma_init_iw_device(struct irdma_ib_device *iwibdev) {
>> + struct net_device *netdev = iwibdev->iwdev->netdev;
>> +
>> + iwibdev->ibdev.node_type = RDMA_NODE_RNIC;
>> + ether_addr_copy((u8 *)&iwibdev->ibdev.node_guid, netdev->dev_addr);
>> + iwibdev->ibdev.iwcm = kzalloc(sizeof(*iwibdev->ibdev.iwcm),
>GFP_KERNEL);
>> + if (!iwibdev->ibdev.iwcm)
>> + return -ENOMEM;
>> +
>> + iwibdev->ibdev.iwcm->add_ref = irdma_add_ref;
>> + iwibdev->ibdev.iwcm->rem_ref = irdma_rem_ref;
>> + iwibdev->ibdev.iwcm->get_qp = irdma_get_qp;
>> + iwibdev->ibdev.iwcm->connect = irdma_connect;
>> + iwibdev->ibdev.iwcm->accept = irdma_accept;
>> + iwibdev->ibdev.iwcm->reject = irdma_reject;
>> + iwibdev->ibdev.iwcm->create_listen = irdma_create_listen;
>> + iwibdev->ibdev.iwcm->destroy_listen = irdma_destroy_listen;
>
>Huh. These should probably be moved into the ops structure too.
Not sure. It looks cleaner this way. These are iWARP CM specific. Why allocate them for all devices?
Shiraz
^ permalink raw reply
* RE: [RFC v1 15/19] RDMA/irdma: Add miscellaneous utility definitions
From: Saleem, Shiraz @ 2019-02-20 14:53 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: dledford@redhat.com, davem@davemloft.net,
linux-rdma@vger.kernel.org, netdev@vger.kernel.org,
Ismail, Mustafa, Kirsher, Jeffrey T
In-Reply-To: <20190215174714.GE30706@ziepe.ca>
>Subject: Re: [RFC v1 15/19] RDMA/irdma: Add miscellaneous utility definitions
>
>On Fri, Feb 15, 2019 at 11:11:02AM -0600, Shiraz Saleem wrote:
>> From: Mustafa Ismail <mustafa.ismail@intel.com>
>>
>> Add miscellaneous utility functions and headers.
>>
[....]
>
>> +#define to_device(ptr) \
>> + (&((struct pci_dev *)((ptr)->hw->dev_context))->dev)
>
>?? Seems like this wants to be container_of??
Yes.
>
>> +/**
>> + * irdma_insert_wqe_hdr - write wqe header
>> + * @wqe: cqp wqe for header
>> + * @header: header for the cqp wqe
>> + */
>> +static inline void irdma_insert_wqe_hdr(__le64 *wqe, u64 hdr) {
>> + wmb(); /* make sure WQE is populated before polarity is set */
>> + set_64bit_val(wqe, 24, hdr);
>
>Generally don't like seeing wmbs in drivers.. Are you sure this isn't supposed to
>be smp_store_release(), or dma_wmb() perhaps?
Why is wmb() an issue in drivers?
>
>> +/**
>> + * irdma_inetaddr_event - system notifier for ipv4 addr events
>> + * @notfier: not used
>> + * @event: event for notifier
>> + * @ptr: if address
>> + */
>> +int irdma_inetaddr_event(struct notifier_block *notifier,
>> + unsigned long event,
>> + void *ptr)
>> +{
>> + struct in_ifaddr *ifa = ptr;
>> + struct net_device *event_netdev = ifa->ifa_dev->dev;
>> + struct net_device *netdev;
>> + struct net_device *upper_dev;
>> + struct irdma_device *iwdev;
>> + u32 local_ipaddr;
>> +
>> + iwdev = irdma_find_netdev(event_netdev);
>
>This is all being changed too (and is probably wrongly locked here)
OK. We ll adapt it based on your new series. Thanks!
[...]
>
>> +/**
>> + * irdma_add_devusecount - add dev refcount
>> + * @iwdev: dev for refcount
>> + */
>> +void irdma_add_devusecount(struct irdma_device *iwdev) {
>> + atomic64_inc(&iwdev->use_count);
>> +}
>> +
>> +/**
>> + * irdma_rem_devusecount - decrement refcount for dev
>> + * @iwdev: device
>> + */
>> +void irdma_rem_devusecount(struct irdma_device *iwdev) {
>> + if (!atomic64_dec_and_test(&iwdev->use_count))
>> + return;
>> + wake_up(&iwdev->close_wq);
>> +}
>> +
>> +/**
>> + * irdma_add_pdusecount - add pd refcount
>> + * @iwpd: pd for refcount
>> + */
>> +void irdma_add_pdusecount(struct irdma_pd *iwpd) {
>> + atomic_inc(&iwpd->usecount);
>> +}
>
>Why do we have these wrappers? Don't like wrappers liket his.
>
>Are you sure this should be an atomic, not a kref, refcount, etc?
>
>Very concerning to refcounting of HW object structures like this.. Most often when
>I see this in IB drivers it comes along with concurrency bugs in the destroy path.
The need for it is being re-visited and will likely go away.
>
>> +/**
>> + * irdma_allocate_dma_mem - Memory alloc helper fn
>> + * @hw: pointer to the HW structure
>> + * @mem: ptr to mem struct to fill out
>> + * @size: size of memory requested
>> + * @alignment: what to align the allocation to */ enum
>> +irdma_status_code irdma_allocate_dma_mem(struct irdma_hw *hw,
>> + struct irdma_dma_mem *mem,
>> + u64 size,
>> + u32 alignment)
>> +{
>> + struct pci_dev *pcidev = (struct pci_dev *)hw->dev_context;
>> +
>> + if (!mem)
>> + return IRDMA_ERR_PARAM;
>> +
>> + mem->size = ALIGN(size, alignment);
>> + mem->va = dma_alloc_coherent(&pcidev->dev, mem->size,
>> + (dma_addr_t *)&mem->pa, GFP_KERNEL);
>> + if (!mem->va)
>> + return IRDMA_ERR_NO_MEMORY;
>> +
>> + return 0;
>> +}
>
>More wrappers? Why?
I agree on your previous comment on wrapper for usecnt tracking but this does
consolidate some common code and avoid duplication.
Shiraz
^ permalink raw reply
* [RFC] net: dsa: qca8k: CPU port broken with commit 5502b218e001 ("net: phy: use phy_resolve_aneg_linkmode in genphy_read_status")
From: Michal Vokáč @ 2019-02-20 15:02 UTC (permalink / raw)
To: Andrew Lunn, Vinod Koul, Heiner Kallweit
Cc: David S. Miller, Florian Fainelli, netdev
Hi,
Another issue in a row with networking on imx6dl-yapp4 platform [1]
that uses QCA8334 Ethernet switch.
Very recently, with Vinod and Andrew, we solved an issue with
RGMII_ID mode by patch[2][3]. I tested those with next-20190215
and it worked just fine.
The patch[2] was merged into next-20190220 so I tested the latest version.
Now the cpu port does not work again. I tracked it down to this commit
5502b218e001 ("net: phy: use phy_resolve_aneg_linkmode in
genphy_read_status") [4]
If I revert the offending commit, cpu port works fine. I suspect the
problem is on the qca8k driver side but I am not really sure.
AFAICT autonegotiation is not available on the QCA833x cpu port (MAC0).
Any ideas what may be the root cause of the problem?
Thank you,
Michal
[1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=87489ec3a77f3e01bcf0d46e353ae7112ec8c4f0
[2] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=a968b5e9d5879f9535d6099505f9e14abcafb623
[3] https://lore.kernel.org/patchwork/patch/1043817/
[4] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=5502b218e001
^ permalink raw reply
* Re: Possible bug into DSA2 code.
From: Andrew Lunn @ 2019-02-20 15:02 UTC (permalink / raw)
To: Rodolfo Giometti
Cc: Florian Fainelli, Vivien Didelot, David S. Miller, netdev
In-Reply-To: <a2f6fa7e-49c3-cb3f-43eb-8ab248b0bb63@enneenne.com>
On Wed, Feb 20, 2019 at 08:54:01AM +0100, Rodolfo Giometti wrote:
> On 19/02/2019 01:03, Andrew Lunn wrote:
> >>diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
> >>index 54a5b660640a..bb46ebbb2bb8 100644
> >>--- a/drivers/net/dsa/mv88e6xxx/chip.c
> >>+++ b/drivers/net/dsa/mv88e6xxx/chip.c
> >>@@ -2399,7 +2399,7 @@ static int mv88e6xxx_setup(struct dsa_switch *ds)
> >> int i;
> >>
> >> chip->ds = ds;
> >>- ds->slave_mii_bus = mv88e6xxx_default_mdio_bus(chip);
> >>+ ds->slave_mii_bus = NULL;
> >>
> >> mutex_lock(&chip->reg_lock);
> >>
> >>Is that right?
> >
> >Hi Rodolfo
> >
> >Humm, that needs testing. There are two used combinations you need to
> >test:
> >
> >No MDIO node in device tree, e.g.
> >arch/arm/boot/dts/kirkwood-dir665.dts
> >
> >MDIO node in device tree, e.g:
> >arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
>
> I'm sorry but I haven't such boards... :'(
Hi Rodolfo
I know. But you should be able to modify the device tree of the boards
you are using to follow these patterns, and test them.
>
> >There is a third combination which will appear soon. There is only the
> >external mdio bus in device tree:
> >
> > port@9 {
> > reg = <9>;
> > label = "eth_cu_1000_2";
> > phy-handle = <&phy9>;
> > phy-mode = "sgmii";
> > managed = "in-band-status";
> > };
> > };
> >
> > mdio1 {
> > compatible = "marvell,mv88e6xxx-mdio-external";
> > #address-cells = <1>;
> > #size-cells = <0>;
> >
> > phy9: phy9@0 {
> > compatible = "ethernet-phy-ieee802.3-c45";
> > pinctrl-0 = <&pinctrl_gpio_phy9>;
> > pinctrl-names = "default";
> > interrupt-parent = <&gpio2>;
> > interrupts = <30 IRQ_TYPE_LEVEL_LOW>;
> > reg = <0>;
> > };
> > };
> >
> >Here port 9 uses the external MDIO bus and all the other ports
> >implicitly make use of the internal MDIO bus.
>
> Mmm... maybe should code into drivers/net/dsa/mv88e6xxx use private data to
> hold used mdio busses instead of ds->slave_mii_bus pointer?
I suspend that might break some of these different use cases.
Either there needs to be a well argued analysis, or some testing of
these setups.
Andrew
^ permalink raw reply
* Re: [PATCH] phonet: fix building with clang
From: Rémi Denis-Courmont @ 2019-02-20 14:57 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Remi Denis-Courmont, David S. Miller, Nathan Chancellor, netdev,
linux-kernel
In-Reply-To: <20190219215359.391543-1-arnd@arndb.de>
Le tiistaina 19. helmikuuta 2019, 23.53.50 EET Arnd Bergmann a écrit :
> clang warns about overflowing the data[] member in the struct pnpipehdr:
>
> net/phonet/pep.c:295:8: warning: array index 4 is past the end of the array
> (which contains 1 element) [-Warray-bounds] if (hdr->data[4] ==
> PEP_IND_READY)
> ^ ~
> include/net/phonet/pep.h:66:3: note: array 'data' declared here
> u8 data[1];
>
> Using a flexible array member at the end of the struct avoids the
> warning, but since we cannot have a flexible array member inside
> of the union, each index now has to be moved back by one, which
> makes it a little uglier.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Rémi Denis-Courmont <remi@remlab.net>
> ---
> include/net/phonet/pep.h | 5 +++--
> net/phonet/pep.c | 32 ++++++++++++++++----------------
> 2 files changed, 19 insertions(+), 18 deletions(-)
>
> diff --git a/include/net/phonet/pep.h b/include/net/phonet/pep.h
> index b669fe6dbc3b..98f31c7ea23d 100644
> --- a/include/net/phonet/pep.h
> +++ b/include/net/phonet/pep.h
> @@ -63,10 +63,11 @@ struct pnpipehdr {
> u8 state_after_reset; /* reset request */
> u8 error_code; /* any response */
> u8 pep_type; /* status indication */
> - u8 data[1];
> + u8 data0; /* anything else */
> };
> + u8 data[];
> };
> -#define other_pep_type data[1]
> +#define other_pep_type data[0]
>
> static inline struct pnpipehdr *pnp_hdr(struct sk_buff *skb)
> {
> diff --git a/net/phonet/pep.c b/net/phonet/pep.c
> index 9fc76b19cd3c..db3473540303 100644
> --- a/net/phonet/pep.c
> +++ b/net/phonet/pep.c
> @@ -132,7 +132,7 @@ static int pep_indicate(struct sock *sk, u8 id, u8 code,
> ph->utid = 0;
> ph->message_id = id;
> ph->pipe_handle = pn->pipe_handle;
> - ph->data[0] = code;
> + ph->error_code = code;
> return pn_skb_send(sk, skb, NULL);
> }
>
> @@ -153,7 +153,7 @@ static int pipe_handler_request(struct sock *sk, u8 id,
> u8 code, ph->utid = id; /* whatever */
> ph->message_id = id;
> ph->pipe_handle = pn->pipe_handle;
> - ph->data[0] = code;
> + ph->error_code = code;
> return pn_skb_send(sk, skb, NULL);
> }
>
> @@ -208,7 +208,7 @@ static int pep_ctrlreq_error(struct sock *sk, struct
> sk_buff *oskb, u8 code, struct pnpipehdr *ph;
> struct sockaddr_pn dst;
> u8 data[4] = {
> - oph->data[0], /* PEP type */
> + oph->pep_type, /* PEP type */
> code, /* error code, at an unusual offset */
> PAD, PAD,
> };
> @@ -221,7 +221,7 @@ static int pep_ctrlreq_error(struct sock *sk, struct
> sk_buff *oskb, u8 code, ph->utid = oph->utid;
> ph->message_id = PNS_PEP_CTRL_RESP;
> ph->pipe_handle = oph->pipe_handle;
> - ph->data[0] = oph->data[1]; /* CTRL id */
> + ph->data0 = oph->data[0]; /* CTRL id */
>
> pn_skb_get_src_sockaddr(oskb, &dst);
> return pn_skb_send(sk, skb, &dst);
> @@ -272,17 +272,17 @@ static int pipe_rcv_status(struct sock *sk, struct
> sk_buff *skb) return -EINVAL;
>
> hdr = pnp_hdr(skb);
> - if (hdr->data[0] != PN_PEP_TYPE_COMMON) {
> + if (hdr->pep_type != PN_PEP_TYPE_COMMON) {
> net_dbg_ratelimited("Phonet unknown PEP type: %u\n",
> - (unsigned int)hdr->data[0]);
> + (unsigned int)hdr->pep_type);
> return -EOPNOTSUPP;
> }
>
> - switch (hdr->data[1]) {
> + switch (hdr->data[0]) {
> case PN_PEP_IND_FLOW_CONTROL:
> switch (pn->tx_fc) {
> case PN_LEGACY_FLOW_CONTROL:
> - switch (hdr->data[4]) {
> + switch (hdr->data[3]) {
> case PEP_IND_BUSY:
> atomic_set(&pn->tx_credits, 0);
> break;
> @@ -292,7 +292,7 @@ static int pipe_rcv_status(struct sock *sk, struct
> sk_buff *skb) }
> break;
> case PN_ONE_CREDIT_FLOW_CONTROL:
> - if (hdr->data[4] == PEP_IND_READY)
> + if (hdr->data[3] == PEP_IND_READY)
> atomic_set(&pn->tx_credits, wake = 1);
> break;
> }
> @@ -301,12 +301,12 @@ static int pipe_rcv_status(struct sock *sk, struct
> sk_buff *skb) case PN_PEP_IND_ID_MCFC_GRANT_CREDITS:
> if (pn->tx_fc != PN_MULTI_CREDIT_FLOW_CONTROL)
> break;
> - atomic_add(wake = hdr->data[4], &pn->tx_credits);
> + atomic_add(wake = hdr->data[3], &pn->tx_credits);
> break;
>
> default:
> net_dbg_ratelimited("Phonet unknown PEP indication: %u\n",
> - (unsigned int)hdr->data[1]);
> + (unsigned int)hdr->data[0]);
> return -EOPNOTSUPP;
> }
> if (wake)
> @@ -318,7 +318,7 @@ static int pipe_rcv_created(struct sock *sk, struct
> sk_buff *skb) {
> struct pep_sock *pn = pep_sk(sk);
> struct pnpipehdr *hdr = pnp_hdr(skb);
> - u8 n_sb = hdr->data[0];
> + u8 n_sb = hdr->data0;
>
> pn->rx_fc = pn->tx_fc = PN_LEGACY_FLOW_CONTROL;
> __skb_pull(skb, sizeof(*hdr));
> @@ -506,7 +506,7 @@ static int pep_connresp_rcv(struct sock *sk, struct
> sk_buff *skb) return -ECONNREFUSED;
>
> /* Parse sub-blocks */
> - n_sb = hdr->data[4];
> + n_sb = hdr->data[3];
> while (n_sb > 0) {
> u8 type, buf[6], len = sizeof(buf);
> const u8 *data = pep_get_sb(skb, &type, &len, buf);
> @@ -739,7 +739,7 @@ static int pipe_do_remove(struct sock *sk)
> ph->utid = 0;
> ph->message_id = PNS_PIPE_REMOVE_REQ;
> ph->pipe_handle = pn->pipe_handle;
> - ph->data[0] = PAD;
> + ph->data0 = PAD;
> return pn_skb_send(sk, skb, NULL);
> }
>
> @@ -817,7 +817,7 @@ static struct sock *pep_sock_accept(struct sock *sk, int
> flags, int *errp, peer_type = hdr->other_pep_type << 8;
>
> /* Parse sub-blocks (options) */
> - n_sb = hdr->data[4];
> + n_sb = hdr->data[3];
> while (n_sb > 0) {
> u8 type, buf[1], len = sizeof(buf);
> const u8 *data = pep_get_sb(skb, &type, &len, buf);
> @@ -1109,7 +1109,7 @@ static int pipe_skb_send(struct sock *sk, struct
> sk_buff *skb) ph->utid = 0;
> if (pn->aligned) {
> ph->message_id = PNS_PIPE_ALIGNED_DATA;
> - ph->data[0] = 0; /* padding */
> + ph->data0 = 0; /* padding */
> } else
> ph->message_id = PNS_PIPE_DATA;
> ph->pipe_handle = pn->pipe_handle;
--
レミ・デニ-クールモン
http://www.remlab.net/
^ permalink raw reply
* Re: [PATCH v2 net-next 2/4] net: dsa: microchip: add MIB counter reading support
From: Andrew Lunn @ 2019-02-20 15:08 UTC (permalink / raw)
To: Tristram.Ha
Cc: Sergio Paracuellos, Florian Fainelli, Pavel Machek,
UNGLinuxDriver, netdev
In-Reply-To: <1550620623-13036-3-git-send-email-Tristram.Ha@microchip.com>
> +static void mib_monitor(struct timer_list *t)
> +{
> + struct ksz_device *dev = from_timer(dev, t, mib_read_timer);
> + const struct dsa_port *dp;
> + struct net_device *netdev;
> + struct ksz_port_mib *mib;
> + struct ksz_port *p;
> + int i;
> +
> + mod_timer(&dev->mib_read_timer, jiffies + dev->mib_read_interval);
> +
> + /* Check which port needs to read MIB counters. */
> + for (i = 0; i < dev->mib_port_cnt; i++) {
> + p = &dev->ports[i];
> + if (!p->on)
> + continue;
> + dp = dsa_to_port(dev->ds, i);
> + netdev = dp->slave;
> +
> + mib = &p->mib;
> + mutex_lock(&mib->cnt_mutex);
> +
> + /* Read only dropped counters when link is not up. */
> + if (netdev && netdev->phydev && !netdev->phydev->link)
> + mib->cnt_ptr = dev->reg_mib_cnt;
> + mutex_unlock(&mib->cnt_mutex);
> + p->read = true;
> + }
> + schedule_work(&dev->mib_read);
> +}
Hi Tristram
This is much easier to understand. Thanks for making the change.
However, i suspect Florian was suggesting you use
netif_carrier_ok(netdev), not poke around inside the phydev structure.
Andrew
^ permalink raw reply
* [PATCH net] ixgbe: don't do any AF_XDP zero-copy transmit if netif is not OK
From: Jan Sokolowski @ 2019-02-20 15:20 UTC (permalink / raw)
To: intel-wired-lan; +Cc: netdev, Jan Sokolowski
An issue has been found while testing zero-copy XDP that
causes a reset to be triggered. As it takes some time to
turn the carrier on after setting zc, and we already
start trying to transmit some packets, watchdog considers
this as an erroneous state and triggers a reset.
Don't do any work if netif carrier is not OK.
Fixes: 8221c5eba8c13 (ixgbe: add AF_XDP zero-copy Tx support)
Signed-off-by: Jan Sokolowski <jan.sokolowski@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
index 98870707b51a..51c29358c2a9 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
@@ -617,7 +617,8 @@ static bool ixgbe_xmit_zc(struct ixgbe_ring *xdp_ring, unsigned int budget)
dma_addr_t dma;
while (budget-- > 0) {
- if (unlikely(!ixgbe_desc_unused(xdp_ring))) {
+ if (unlikely(!ixgbe_desc_unused(xdp_ring)) ||
+ !netif_carrier_ok(xdp_ring->netdev)) {
work_done = false;
break;
}
--
2.18.1
^ permalink raw reply related
* Re: [RESEND PATCH 0/7] Add FOLL_LONGTERM to GUP fast and use it
From: Christoph Hellwig @ 2019-02-20 15:19 UTC (permalink / raw)
To: ira.weiny
Cc: John Hubbard, Andrew Morton, Michal Hocko, Kirill A. Shutemov,
Peter Zijlstra, Jason Gunthorpe, Benjamin Herrenschmidt,
Paul Mackerras, David S. Miller, Martin Schwidefsky,
Heiko Carstens, Rich Felker, Yoshinori Sato, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Ralf Baechle, Paul Burton,
James Hogan, linux-kernel, linux-mm, linux-mips, linuxppc-dev,
linux-s390, linux-sh, sparclinux, kvm-ppc, kvm, linux-fpga,
dri-devel, linux-rdma, linux-media, linux-scsi, devel,
virtualization, netdev, linux-fbdev, xen-devel, devel, ceph-devel,
rds-devel
In-Reply-To: <20190220053040.10831-1-ira.weiny@intel.com>
On Tue, Feb 19, 2019 at 09:30:33PM -0800, ira.weiny@intel.com wrote:
> From: Ira Weiny <ira.weiny@intel.com>
>
> Resending these as I had only 1 minor comment which I believe we have covered
> in this series. I was anticipating these going through the mm tree as they
> depend on a cleanup patch there and the IB changes are very minor. But they
> could just as well go through the IB tree.
>
> NOTE: This series depends on my clean up patch to remove the write parameter
> from gup_fast_permitted()[1]
>
> HFI1, qib, and mthca, use get_user_pages_fast() due to it performance
> advantages. These pages can be held for a significant time. But
> get_user_pages_fast() does not protect against mapping of FS DAX pages.
This I don't get - if you do lock down long term mappings performance
of the actual get_user_pages call shouldn't matter to start with.
What do I miss?
^ permalink raw reply
* [PATCH 4/6] ARM: dts: am335x: switch to use phy-gmii-sel
From: Grygorii Strashko @ 2019-02-20 15:25 UTC (permalink / raw)
To: David S. Miller, Kishon Vijay Abraham I, Rob Herring,
Tony Lindgren
Cc: netdev, Sekhar Nori, linux-kernel, linux-omap, devicetree,
linux-arm-kernel, Grygorii Strashko
In-Reply-To: <1550676319-6440-1-git-send-email-grygorii.strashko@ti.com>
Switch to use phy-gmii-sel PHY instead of cpsw-phy-sel.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
arch/arm/boot/dts/am335x-baltos-ir2110.dts | 4 ----
arch/arm/boot/dts/am335x-baltos-ir3220.dts | 4 ----
arch/arm/boot/dts/am335x-baltos-ir5221.dts | 4 ----
arch/arm/boot/dts/am335x-chiliboard.dts | 4 ----
arch/arm/boot/dts/am335x-icev2.dts | 4 ----
arch/arm/boot/dts/am335x-igep0033.dtsi | 4 ----
arch/arm/boot/dts/am335x-lxm.dts | 4 ----
arch/arm/boot/dts/am335x-moxa-uc-2100-common.dtsi | 5 -----
arch/arm/boot/dts/am335x-moxa-uc-8100-me-t.dts | 5 -----
arch/arm/boot/dts/am335x-phycore-som.dtsi | 4 ----
arch/arm/boot/dts/am33xx-l4.dtsi | 15 ++++++++-------
11 files changed, 8 insertions(+), 49 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-baltos-ir2110.dts b/arch/arm/boot/dts/am335x-baltos-ir2110.dts
index 75de1e723303..50dcf1290ac6 100644
--- a/arch/arm/boot/dts/am335x-baltos-ir2110.dts
+++ b/arch/arm/boot/dts/am335x-baltos-ir2110.dts
@@ -72,7 +72,3 @@
dual_emac_res_vlan = <2>;
phy-handle = <&phy1>;
};
-
-&phy_sel {
- rmii-clock-ext = <1>;
-};
diff --git a/arch/arm/boot/dts/am335x-baltos-ir3220.dts b/arch/arm/boot/dts/am335x-baltos-ir3220.dts
index 1b215c425c57..f3f1abd26470 100644
--- a/arch/arm/boot/dts/am335x-baltos-ir3220.dts
+++ b/arch/arm/boot/dts/am335x-baltos-ir3220.dts
@@ -114,7 +114,3 @@
dual_emac_res_vlan = <2>;
phy-handle = <&phy1>;
};
-
-&phy_sel {
- rmii-clock-ext = <1>;
-};
diff --git a/arch/arm/boot/dts/am335x-baltos-ir5221.dts b/arch/arm/boot/dts/am335x-baltos-ir5221.dts
index 832ead864dc5..42f473f0ed77 100644
--- a/arch/arm/boot/dts/am335x-baltos-ir5221.dts
+++ b/arch/arm/boot/dts/am335x-baltos-ir5221.dts
@@ -133,10 +133,6 @@
phy-handle = <&phy1>;
};
-&phy_sel {
- rmii-clock-ext = <1>;
-};
-
&dcan1 {
pinctrl-names = "default";
pinctrl-0 = <&dcan1_pins>;
diff --git a/arch/arm/boot/dts/am335x-chiliboard.dts b/arch/arm/boot/dts/am335x-chiliboard.dts
index 9c2a947aacf5..4a869534db50 100644
--- a/arch/arm/boot/dts/am335x-chiliboard.dts
+++ b/arch/arm/boot/dts/am335x-chiliboard.dts
@@ -151,10 +151,6 @@
phy-mode = "rmii";
};
-&phy_sel {
- rmii-clock-ext;
-};
-
/* USB */
&usb {
status = "okay";
diff --git a/arch/arm/boot/dts/am335x-icev2.dts b/arch/arm/boot/dts/am335x-icev2.dts
index f2005ecca74f..9ac775c71072 100644
--- a/arch/arm/boot/dts/am335x-icev2.dts
+++ b/arch/arm/boot/dts/am335x-icev2.dts
@@ -484,10 +484,6 @@
dual_emac;
};
-&phy_sel {
- rmii-clock-ext;
-};
-
&davinci_mdio {
pinctrl-names = "default", "sleep";
pinctrl-0 = <&davinci_mdio_default>;
diff --git a/arch/arm/boot/dts/am335x-igep0033.dtsi b/arch/arm/boot/dts/am335x-igep0033.dtsi
index 55b4c94cfafb..cbd22f25de95 100644
--- a/arch/arm/boot/dts/am335x-igep0033.dtsi
+++ b/arch/arm/boot/dts/am335x-igep0033.dtsi
@@ -123,10 +123,6 @@
phy-mode = "rmii";
};
-&phy_sel {
- rmii-clock-ext;
-};
-
&elm {
status = "okay";
};
diff --git a/arch/arm/boot/dts/am335x-lxm.dts b/arch/arm/boot/dts/am335x-lxm.dts
index 481edcfaf121..d0e8e720a4d6 100644
--- a/arch/arm/boot/dts/am335x-lxm.dts
+++ b/arch/arm/boot/dts/am335x-lxm.dts
@@ -328,10 +328,6 @@
dual_emac_res_vlan = <3>;
};
-&phy_sel {
- rmii-clock-ext;
-};
-
&mac {
pinctrl-names = "default", "sleep";
pinctrl-0 = <&cpsw_default>;
diff --git a/arch/arm/boot/dts/am335x-moxa-uc-2100-common.dtsi b/arch/arm/boot/dts/am335x-moxa-uc-2100-common.dtsi
index 14f781953475..cb5913a69837 100644
--- a/arch/arm/boot/dts/am335x-moxa-uc-2100-common.dtsi
+++ b/arch/arm/boot/dts/am335x-moxa-uc-2100-common.dtsi
@@ -159,11 +159,6 @@
status = "okay";
};
-&phy_sel {
- reg= <0x44e10650 0xf5>;
- rmii-clock-ext;
-};
-
&sham {
status = "okay";
};
diff --git a/arch/arm/boot/dts/am335x-moxa-uc-8100-me-t.dts b/arch/arm/boot/dts/am335x-moxa-uc-8100-me-t.dts
index 5a58efc0c874..e562ce40f290 100644
--- a/arch/arm/boot/dts/am335x-moxa-uc-8100-me-t.dts
+++ b/arch/arm/boot/dts/am335x-moxa-uc-8100-me-t.dts
@@ -446,11 +446,6 @@
dual_emac_res_vlan = <2>;
};
-&phy_sel {
- reg= <0x44e10650 0xf5>;
- rmii-clock-ext;
-};
-
&sham {
status = "okay";
};
diff --git a/arch/arm/boot/dts/am335x-phycore-som.dtsi b/arch/arm/boot/dts/am335x-phycore-som.dtsi
index 428a25e952b0..015adb626b03 100644
--- a/arch/arm/boot/dts/am335x-phycore-som.dtsi
+++ b/arch/arm/boot/dts/am335x-phycore-som.dtsi
@@ -100,10 +100,6 @@
status = "okay";
};
-&phy_sel {
- rmii-clock-ext;
-};
-
/* I2C Busses */
&am33xx_pinmux {
i2c0_pins: pinmux_i2c0 {
diff --git a/arch/arm/boot/dts/am33xx-l4.dtsi b/arch/arm/boot/dts/am33xx-l4.dtsi
index 7b818d9d2eab..f813131f8461 100644
--- a/arch/arm/boot/dts/am33xx-l4.dtsi
+++ b/arch/arm/boot/dts/am33xx-l4.dtsi
@@ -279,12 +279,6 @@
#pinctrl-cells = <1>;
ranges = <0 0 0x2000>;
- phy_sel: cpsw-phy-sel@650 {
- compatible = "ti,am3352-cpsw-phy-sel";
- reg= <0x650 0x4>;
- reg-names = "gmii-sel";
- };
-
am33xx_pinmux: pinmux@800 {
compatible = "pinctrl-single";
reg = <0x800 0x238>;
@@ -302,6 +296,12 @@
#size-cells = <1>;
ranges = <0 0 0x800>;
+ phy_gmii_sel: phy-gmii-sel {
+ compatible = "ti,am3352-phy-gmii-sel";
+ reg = <0x650 0x4>;
+ #phy-cells = <2>;
+ };
+
scm_clocks: clocks {
#address-cells = <1>;
#size-cells = <0>;
@@ -717,7 +717,6 @@
interrupts = <40 41 42 43>;
ranges = <0 0 0x8000>;
syscon = <&scm_conf>;
- cpsw-phy-sel = <&phy_sel>;
status = "disabled";
davinci_mdio: mdio@1000 {
@@ -733,11 +732,13 @@
cpsw_emac0: slave@200 {
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
+ phys = <&phy_gmii_sel 1 1>;
};
cpsw_emac1: slave@300 {
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
+ phys = <&phy_gmii_sel 2 1>;
};
};
};
--
2.17.1
^ permalink raw reply related
* [PATCH 6/6] net: ethernet: ti: cpsw: deprecate cpsw-phy-sel driver
From: Grygorii Strashko @ 2019-02-20 15:25 UTC (permalink / raw)
To: David S. Miller, Kishon Vijay Abraham I, Rob Herring,
Tony Lindgren
Cc: netdev, Sekhar Nori, linux-kernel, linux-omap, devicetree,
linux-arm-kernel, Grygorii Strashko
In-Reply-To: <1550676319-6440-1-git-send-email-grygorii.strashko@ti.com>
Deprecate cpsw-phy-sel driver as it's been replaced with new
TI phy-gmii-sel PHY driver.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
drivers/net/ethernet/ti/Kconfig | 6 +++---
drivers/net/ethernet/ti/cpsw.h | 6 ++++++
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
index bb126be1eb72..8b21b40a9fe5 100644
--- a/drivers/net/ethernet/ti/Kconfig
+++ b/drivers/net/ethernet/ti/Kconfig
@@ -49,10 +49,11 @@ config TI_DAVINCI_CPDMA
will be called davinci_cpdma. This is recommended.
config TI_CPSW_PHY_SEL
- bool
+ bool "TI CPSW Phy mode Selection (DEPRECATED)"
+ default n
---help---
This driver supports configuring of the phy mode connected to
- the CPSW.
+ the CPSW. DEPRECATED: use PHY_TI_GMII_SEL.
config TI_CPSW_ALE
tristate "TI CPSW ALE Support"
@@ -64,7 +65,6 @@ config TI_CPSW
depends on ARCH_DAVINCI || ARCH_OMAP2PLUS || COMPILE_TEST
select TI_DAVINCI_CPDMA
select TI_DAVINCI_MDIO
- select TI_CPSW_PHY_SEL
select TI_CPSW_ALE
select MFD_SYSCON
select REGMAP
diff --git a/drivers/net/ethernet/ti/cpsw.h b/drivers/net/ethernet/ti/cpsw.h
index cf111db3dc27..907e05fc22e4 100644
--- a/drivers/net/ethernet/ti/cpsw.h
+++ b/drivers/net/ethernet/ti/cpsw.h
@@ -21,7 +21,13 @@
((mac)[2] << 16) | ((mac)[3] << 24))
#define mac_lo(mac) (((mac)[4] << 0) | ((mac)[5] << 8))
+#if IS_ENABLED(CONFIG_TI_CPSW_PHY_SEL)
void cpsw_phy_sel(struct device *dev, phy_interface_t phy_mode, int slave);
+#else
+static inline
+void cpsw_phy_sel(struct device *dev, phy_interface_t phy_mode, int slave)
+{}
+#endif
int ti_cm_get_macid(struct device *dev, int slave, u8 *mac_addr);
#endif /* __CPSW_H__ */
--
2.17.1
^ permalink raw reply related
* [PATCH 5/6] dt-bindings: net: ti: deprecate cpsw-phy-sel bindings
From: Grygorii Strashko @ 2019-02-20 15:25 UTC (permalink / raw)
To: David S. Miller, Kishon Vijay Abraham I, Rob Herring,
Tony Lindgren
Cc: netdev, Sekhar Nori, linux-kernel, linux-omap, devicetree,
linux-arm-kernel, Grygorii Strashko
In-Reply-To: <1550676319-6440-1-git-send-email-grygorii.strashko@ti.com>
The cpsw-phy-sel driver was replaced with new PHY driver phy-gmii-sel, so
deprecate cpsw-phy-sel bindings.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
Documentation/devicetree/bindings/net/cpsw-phy-sel.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt b/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt
index 764c0c79b43d..5d76f991c027 100644
--- a/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt
+++ b/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt
@@ -1,4 +1,4 @@
-TI CPSW Phy mode Selection Device Tree Bindings
+TI CPSW Phy mode Selection Device Tree Bindings (DEPRECATED)
-----------------------------------------------
Required properties:
--
2.17.1
^ permalink raw reply related
* [PATCH 1/6] ARM: dts: dra7: switch to use phy-gmii-sel
From: Grygorii Strashko @ 2019-02-20 15:25 UTC (permalink / raw)
To: David S. Miller, Kishon Vijay Abraham I, Rob Herring,
Tony Lindgren
Cc: netdev, Sekhar Nori, linux-kernel, linux-omap, devicetree,
linux-arm-kernel, Grygorii Strashko
In-Reply-To: <1550676319-6440-1-git-send-email-grygorii.strashko@ti.com>
Switch to use phy-gmii-sel PHY instead of cpsw-phy-sel.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
arch/arm/boot/dts/dra7-l4.dtsi | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/dra7-l4.dtsi b/arch/arm/boot/dts/dra7-l4.dtsi
index bb45cb7fc3b6..414f1cd68733 100644
--- a/arch/arm/boot/dts/dra7-l4.dtsi
+++ b/arch/arm/boot/dts/dra7-l4.dtsi
@@ -77,18 +77,18 @@
};
};
+ phy_gmii_sel: phy-gmii-sel {
+ compatible = "ti,dra7xx-phy-gmii-sel";
+ reg = <0x554 0x4>;
+ #phy-cells = <1>;
+ };
+
scm_conf_clocks: clocks {
#address-cells = <1>;
#size-cells = <0>;
};
};
- phy_sel: cpsw-phy-sel@554 {
- compatible = "ti,dra7xx-cpsw-phy-sel";
- reg= <0x554 0x4>;
- reg-names = "gmii-sel";
- };
-
dra7_pmx_core: pinmux@1400 {
compatible = "ti,dra7-padconf",
"pinctrl-single";
@@ -3099,7 +3099,6 @@
<GIC_SPI 337 IRQ_TYPE_LEVEL_HIGH>;
ranges = <0 0 0x4000>;
syscon = <&scm_conf>;
- cpsw-phy-sel = <&phy_sel>;
status = "disabled";
davinci_mdio: mdio@1000 {
@@ -3114,11 +3113,13 @@
cpsw_emac0: slave@200 {
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
+ phys = <&phy_gmii_sel 1>;
};
cpsw_emac1: slave@300 {
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
+ phys = <&phy_gmii_sel 2>;
};
};
};
--
2.17.1
^ permalink raw reply related
* [PATCH 2/6] ARM: dts: dm814x: switch to use phy-gmii-sel
From: Grygorii Strashko @ 2019-02-20 15:25 UTC (permalink / raw)
To: David S. Miller, Kishon Vijay Abraham I, Rob Herring,
Tony Lindgren
Cc: netdev, Sekhar Nori, linux-kernel, linux-omap, devicetree,
linux-arm-kernel, Grygorii Strashko
In-Reply-To: <1550676319-6440-1-git-send-email-grygorii.strashko@ti.com>
Switch to use phy-gmii-sel PHY instead of cpsw-phy-sel.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
arch/arm/boot/dts/dm814x.dtsi | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/dm814x.dtsi b/arch/arm/boot/dts/dm814x.dtsi
index 601c57afd4fe..413ae19dd5f0 100644
--- a/arch/arm/boot/dts/dm814x.dtsi
+++ b/arch/arm/boot/dts/dm814x.dtsi
@@ -343,6 +343,12 @@
#size-cells = <1>;
ranges = <0 0 0x800>;
+ phy_gmii_sel: phy-gmii-sel {
+ compatible = "ti,dm814-phy-gmii-sel";
+ reg = <0x650 0x4>;
+ #phy-cells = <1>;
+ };
+
scm_clocks: clocks {
#address-cells = <1>;
#size-cells = <0>;
@@ -549,17 +555,14 @@
cpsw_emac0: slave@4a100200 {
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
+ phys = <&phy_gmii_sel 1>;
+
};
cpsw_emac1: slave@4a100300 {
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
- };
-
- phy_sel: cpsw-phy-sel@48140650 {
- compatible = "ti,am3352-cpsw-phy-sel";
- reg= <0x48140650 0x4>;
- reg-names = "gmii-sel";
+ phys = <&phy_gmii_sel 2>;
};
};
--
2.17.1
^ permalink raw reply related
* [PATCH 3/6] ARM: dts: am4372: switch to use phy-gmii-sel
From: Grygorii Strashko @ 2019-02-20 15:25 UTC (permalink / raw)
To: David S. Miller, Kishon Vijay Abraham I, Rob Herring,
Tony Lindgren
Cc: netdev, Sekhar Nori, linux-kernel, linux-omap, devicetree,
linux-arm-kernel, Grygorii Strashko
In-Reply-To: <1550676319-6440-1-git-send-email-grygorii.strashko@ti.com>
Switch to use phy-gmii-sel PHY instead of cpsw-phy-sel.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
arch/arm/boot/dts/am437x-l4.dtsi | 17 +++++++++--------
arch/arm/boot/dts/am43x-epos-evm.dts | 5 +----
2 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/am437x-l4.dtsi b/arch/arm/boot/dts/am437x-l4.dtsi
index ca0896f80248..85c6f4ff1824 100644
--- a/arch/arm/boot/dts/am437x-l4.dtsi
+++ b/arch/arm/boot/dts/am437x-l4.dtsi
@@ -280,12 +280,6 @@
#size-cells = <1>;
ranges = <0 0 0x4000>;
- phy_sel: cpsw-phy-sel@650 {
- compatible = "ti,am43xx-cpsw-phy-sel";
- reg= <0x650 0x4>;
- reg-names = "gmii-sel";
- };
-
am43xx_pinmux: pinmux@800 {
compatible = "ti,am437-padconf",
"pinctrl-single";
@@ -300,11 +294,17 @@
};
scm_conf: scm_conf@0 {
- compatible = "syscon";
+ compatible = "syscon", "simple-bus";
reg = <0x0 0x800>;
#address-cells = <1>;
#size-cells = <1>;
+ phy_gmii_sel: phy-gmii-sel {
+ compatible = "ti,am43xx-phy-gmii-sel";
+ reg = <0x650 0x4>;
+ #phy-cells = <2>;
+ };
+
scm_clocks: clocks {
#address-cells = <1>;
#size-cells = <0>;
@@ -555,7 +555,6 @@
cpts_clock_shift = <29>;
ranges = <0 0 0x8000>;
syscon = <&scm_conf>;
- cpsw-phy-sel = <&phy_sel>;
davinci_mdio: mdio@1000 {
compatible = "ti,am4372-mdio","ti,cpsw-mdio","ti,davinci_mdio";
@@ -572,11 +571,13 @@
cpsw_emac0: slave@200 {
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
+ phys = <&phy_gmii_sel 1 0>;
};
cpsw_emac1: slave@300 {
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
+ phys = <&phy_gmii_sel 2 0>;
};
};
};
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts b/arch/arm/boot/dts/am43x-epos-evm.dts
index 4ea753b3ee43..9dfd80e3b76e 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -584,10 +584,7 @@
&cpsw_emac0 {
phy-handle = <ðphy0>;
phy-mode = "rmii";
-};
-
-&phy_sel {
- rmii-clock-ext;
+ phys = <&phy_gmii_sel 1 1>;
};
&i2c0 {
--
2.17.1
^ permalink raw reply related
* [PATCH 0/6] ARM: dts: ti: cpsw: switch to phy-gmii-sel phy driver
From: Grygorii Strashko @ 2019-02-20 15:25 UTC (permalink / raw)
To: David S. Miller, Kishon Vijay Abraham I, Rob Herring,
Tony Lindgren
Cc: netdev, Sekhar Nori, linux-kernel, linux-omap, devicetree,
linux-arm-kernel, Grygorii Strashko
Hi Tony,
Hence prerequisite patches [1] have been merged already I'm sending final set
of DT patches to complete conversation of TI CPSW driver to use phy-gmii-sel
phy driver instead of cpsw-phy-sel.
[1] https://lkml.org/lkml/2018/11/26/154
Grygorii Strashko (6):
ARM: dts: dra7: switch to use phy-gmii-sel
ARM: dts: dm814x: switch to use phy-gmii-sel
ARM: dts: am4372: switch to use phy-gmii-sel
ARM: dts: am335x: switch to use phy-gmii-sel
dt-bindings: net: ti: deprecate cpsw-phy-sel bindings
net: ethernet: ti: cpsw: deprecate cpsw-phy-sel driver
.../devicetree/bindings/net/cpsw-phy-sel.txt | 2 +-
arch/arm/boot/dts/am335x-baltos-ir2110.dts | 4 ----
arch/arm/boot/dts/am335x-baltos-ir3220.dts | 4 ----
arch/arm/boot/dts/am335x-baltos-ir5221.dts | 4 ----
arch/arm/boot/dts/am335x-chiliboard.dts | 4 ----
arch/arm/boot/dts/am335x-icev2.dts | 4 ----
arch/arm/boot/dts/am335x-igep0033.dtsi | 4 ----
arch/arm/boot/dts/am335x-lxm.dts | 4 ----
.../boot/dts/am335x-moxa-uc-2100-common.dtsi | 5 -----
arch/arm/boot/dts/am335x-moxa-uc-8100-me-t.dts | 5 -----
arch/arm/boot/dts/am335x-phycore-som.dtsi | 4 ----
arch/arm/boot/dts/am33xx-l4.dtsi | 15 ++++++++-------
arch/arm/boot/dts/am437x-l4.dtsi | 17 +++++++++--------
arch/arm/boot/dts/am43x-epos-evm.dts | 5 +----
arch/arm/boot/dts/dm814x.dtsi | 15 +++++++++------
arch/arm/boot/dts/dra7-l4.dtsi | 15 ++++++++-------
drivers/net/ethernet/ti/Kconfig | 6 +++---
drivers/net/ethernet/ti/cpsw.h | 6 ++++++
18 files changed, 45 insertions(+), 78 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH net-next 1/2] ixgbe: add tracking of AF_XDP zero-copy state for each queue pair
From: Jan Sokolowski @ 2019-02-20 15:28 UTC (permalink / raw)
To: intel-wired-lan; +Cc: netdev, intel-wired-lan, Jan Sokolowski
Here, we add a bitmap to the ixgbe_adapter that tracks if a
certain queue pair has been "zero-copy enabled" via the ndo_bpf.
The bitmap is used in ixgbe_xsk_umem, and enables zero-copy if
and only if XDP is enabled, the corresponding qid in the bitmap
is set, and the umem is non-NULL;
Signed-off-by: Jan Sokolowski <jan.sokolowski@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 1 +
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 6 ++++++
drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c | 5 ++++-
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
index 08d85e336bd4..5f5db6eb261e 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
@@ -635,6 +635,7 @@ struct ixgbe_adapter {
/* XDP */
int num_xdp_queues;
struct ixgbe_ring *xdp_ring[MAX_XDP_QUEUES];
+ unsigned long *af_xdp_zc_qps; /* tracks AF_XDP ZC enabled rings */
/* TX */
struct ixgbe_ring *tx_ring[MAX_TX_QUEUES] ____cacheline_aligned_in_smp;
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 38c430b94ae3..46fc6fb8bb1b 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -6284,6 +6284,10 @@ static int ixgbe_sw_init(struct ixgbe_adapter *adapter,
if (ixgbe_init_rss_key(adapter))
return -ENOMEM;
+ adapter->af_xdp_zc_qps = bitmap_zalloc(MAX_XDP_QUEUES, GFP_KERNEL);
+ if (!adapter->af_xdp_zc_qps)
+ return -ENOMEM;
+
/* Set MAC specific capability flags and exceptions */
switch (hw->mac.type) {
case ixgbe_mac_82598EB:
@@ -11153,6 +11157,7 @@ static int ixgbe_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
kfree(adapter->jump_tables[0]);
kfree(adapter->mac_table);
kfree(adapter->rss_key);
+ bitmap_free(adapter->af_xdp_zc_qps);
err_ioremap:
disable_dev = !test_and_set_bit(__IXGBE_DISABLED, &adapter->state);
free_netdev(netdev);
@@ -11241,6 +11246,7 @@ static void ixgbe_remove(struct pci_dev *pdev)
kfree(adapter->mac_table);
kfree(adapter->rss_key);
+ bitmap_free(adapter->af_xdp_zc_qps);
disable_dev = !test_and_set_bit(__IXGBE_DISABLED, &adapter->state);
free_netdev(netdev);
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
index 51c29358c2a9..fccfb422e45c 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
@@ -15,7 +15,8 @@ struct xdp_umem *ixgbe_xsk_umem(struct ixgbe_adapter *adapter,
int qid = ring->ring_idx;
if (!adapter->xsk_umems || !adapter->xsk_umems[qid] ||
- qid >= adapter->num_xsk_umems || !xdp_on)
+ qid >= adapter->num_xsk_umems || !xdp_on ||
+ !test_bit(qid, adapter->af_xdp_zc_qps))
return NULL;
return adapter->xsk_umems[qid];
@@ -143,6 +144,7 @@ static int ixgbe_xsk_umem_enable(struct ixgbe_adapter *adapter,
if (if_running)
ixgbe_txrx_ring_disable(adapter, qid);
+ set_bit(qid, adapter->af_xdp_zc_qps);
err = ixgbe_add_xsk_umem(adapter, umem, qid);
if (if_running)
@@ -165,6 +167,7 @@ static int ixgbe_xsk_umem_disable(struct ixgbe_adapter *adapter, u16 qid)
if (if_running)
ixgbe_txrx_ring_disable(adapter, qid);
+ clear_bit(qid, adapter->af_xdp_zc_qps);
ixgbe_xsk_umem_dma_unmap(adapter, adapter->xsk_umems[qid]);
ixgbe_remove_xsk_umem(adapter, qid);
--
2.18.1
^ permalink raw reply related
* [PATCH net-next 2/2] ixgbe: remove umem from adapter
From: Jan Sokolowski @ 2019-02-20 15:28 UTC (permalink / raw)
To: intel-wired-lan; +Cc: netdev, intel-wired-lan, Jan Sokolowski
In-Reply-To: <20190220152826.14083-1-jan.sokolowski@intel.com>
As current implementation of netdev already contains and provides
umems for us, we no longer have the need to contain these
structures in ixgbe_adapter.
Refactor the code to operate on netdev-provided umems.
Signed-off-by: Jan Sokolowski <jan.sokolowski@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 11 +--
drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c | 77 ++++----------------
2 files changed, 19 insertions(+), 69 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
index 5f5db6eb261e..aa923d6d596b 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
@@ -775,11 +775,6 @@ struct ixgbe_adapter {
#ifdef CONFIG_IXGBE_IPSEC
struct ixgbe_ipsec *ipsec;
#endif /* CONFIG_IXGBE_IPSEC */
-
- /* AF_XDP zero-copy */
- struct xdp_umem **xsk_umems;
- u16 num_xsk_umems_used;
- u16 num_xsk_umems;
};
static inline u8 ixgbe_max_rss_indices(struct ixgbe_adapter *adapter)
@@ -1040,4 +1035,10 @@ static inline int ixgbe_ipsec_vf_add_sa(struct ixgbe_adapter *adapter,
static inline int ixgbe_ipsec_vf_del_sa(struct ixgbe_adapter *adapter,
u32 *mbuf, u32 vf) { return -EACCES; }
#endif /* CONFIG_IXGBE_IPSEC */
+
+static inline bool ixgbe_enabled_xdp_adapter(struct ixgbe_adapter *adapter)
+{
+ return !!adapter->xdp_prog;
+}
+
#endif /* _IXGBE_H_ */
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
index fccfb422e45c..6587a583c8c7 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
@@ -14,58 +14,10 @@ struct xdp_umem *ixgbe_xsk_umem(struct ixgbe_adapter *adapter,
bool xdp_on = READ_ONCE(adapter->xdp_prog);
int qid = ring->ring_idx;
- if (!adapter->xsk_umems || !adapter->xsk_umems[qid] ||
- qid >= adapter->num_xsk_umems || !xdp_on ||
- !test_bit(qid, adapter->af_xdp_zc_qps))
+ if (!xdp_on || !test_bit(qid, adapter->af_xdp_zc_qps))
return NULL;
- return adapter->xsk_umems[qid];
-}
-
-static int ixgbe_alloc_xsk_umems(struct ixgbe_adapter *adapter)
-{
- if (adapter->xsk_umems)
- return 0;
-
- adapter->num_xsk_umems_used = 0;
- adapter->num_xsk_umems = adapter->num_rx_queues;
- adapter->xsk_umems = kcalloc(adapter->num_xsk_umems,
- sizeof(*adapter->xsk_umems),
- GFP_KERNEL);
- if (!adapter->xsk_umems) {
- adapter->num_xsk_umems = 0;
- return -ENOMEM;
- }
-
- return 0;
-}
-
-static int ixgbe_add_xsk_umem(struct ixgbe_adapter *adapter,
- struct xdp_umem *umem,
- u16 qid)
-{
- int err;
-
- err = ixgbe_alloc_xsk_umems(adapter);
- if (err)
- return err;
-
- adapter->xsk_umems[qid] = umem;
- adapter->num_xsk_umems_used++;
-
- return 0;
-}
-
-static void ixgbe_remove_xsk_umem(struct ixgbe_adapter *adapter, u16 qid)
-{
- adapter->xsk_umems[qid] = NULL;
- adapter->num_xsk_umems_used--;
-
- if (adapter->num_xsk_umems == 0) {
- kfree(adapter->xsk_umems);
- adapter->xsk_umems = NULL;
- adapter->num_xsk_umems = 0;
- }
+ return xdp_get_umem_from_qid(adapter->netdev, qid);
}
static int ixgbe_xsk_umem_dma_map(struct ixgbe_adapter *adapter,
@@ -114,6 +66,7 @@ static int ixgbe_xsk_umem_enable(struct ixgbe_adapter *adapter,
struct xdp_umem *umem,
u16 qid)
{
+ struct net_device *netdev = adapter->netdev;
struct xdp_umem_fq_reuse *reuseq;
bool if_running;
int err;
@@ -121,12 +74,9 @@ static int ixgbe_xsk_umem_enable(struct ixgbe_adapter *adapter,
if (qid >= adapter->num_rx_queues)
return -EINVAL;
- if (adapter->xsk_umems) {
- if (qid >= adapter->num_xsk_umems)
- return -EINVAL;
- if (adapter->xsk_umems[qid])
- return -EBUSY;
- }
+ if (qid >= netdev->real_num_rx_queues ||
+ qid >= netdev->real_num_tx_queues)
+ return -EINVAL;
reuseq = xsk_reuseq_prepare(adapter->rx_ring[0]->count);
if (!reuseq)
@@ -139,13 +89,12 @@ static int ixgbe_xsk_umem_enable(struct ixgbe_adapter *adapter,
return err;
if_running = netif_running(adapter->netdev) &&
- READ_ONCE(adapter->xdp_prog);
+ ixgbe_enabled_xdp_adapter(adapter);
if (if_running)
ixgbe_txrx_ring_disable(adapter, qid);
set_bit(qid, adapter->af_xdp_zc_qps);
- err = ixgbe_add_xsk_umem(adapter, umem, qid);
if (if_running)
ixgbe_txrx_ring_enable(adapter, qid);
@@ -155,21 +104,21 @@ static int ixgbe_xsk_umem_enable(struct ixgbe_adapter *adapter,
static int ixgbe_xsk_umem_disable(struct ixgbe_adapter *adapter, u16 qid)
{
+ struct xdp_umem *umem;
bool if_running;
- if (!adapter->xsk_umems || qid >= adapter->num_xsk_umems ||
- !adapter->xsk_umems[qid])
+ umem = xdp_get_umem_from_qid(adapter->netdev, qid);
+ if (!umem)
return -EINVAL;
if_running = netif_running(adapter->netdev) &&
- READ_ONCE(adapter->xdp_prog);
+ ixgbe_enabled_xdp_adapter(adapter);
if (if_running)
ixgbe_txrx_ring_disable(adapter, qid);
clear_bit(qid, adapter->af_xdp_zc_qps);
- ixgbe_xsk_umem_dma_unmap(adapter, adapter->xsk_umems[qid]);
- ixgbe_remove_xsk_umem(adapter, qid);
+ ixgbe_xsk_umem_dma_unmap(adapter, umem);
if (if_running)
ixgbe_txrx_ring_enable(adapter, qid);
@@ -748,7 +697,7 @@ int ixgbe_xsk_async_xmit(struct net_device *dev, u32 qid)
if (qid >= adapter->num_xdp_queues)
return -ENXIO;
- if (!adapter->xsk_umems || !adapter->xsk_umems[qid])
+ if (!adapter->xdp_ring[qid]->xsk_umem)
return -ENXIO;
ring = adapter->xdp_ring[qid];
--
2.18.1
^ permalink raw reply related
* Re: [PATCH] tcp: Reset tcp connections in SYN-SENT state
From: Eric Dumazet @ 2019-02-20 15:47 UTC (permalink / raw)
To: Devi Sandeep Endluri V V; +Cc: netdev, subashab, sharathv, ssaha, strenche
In-Reply-To: <20190220142754.GA5073@dendluri-linux.qualcomm.com>
On Wed, Feb 20, 2019 at 6:28 AM Devi Sandeep Endluri V V
<dendluri@codeaurora.org> wrote:
>
> Userspace sends tcp connection (sock) destroy on network permission
> change. Kernel though doesn't send reset for the connections in
> SYN-SENT state and these connections continue to remain. Even as
> per RFC 793, there is no hard rule to not send RST on ABORT in
> this state. Change to make sure RST are send for connections in
> syn-sent state to avoid lingering connections on network switch.
>
> References from RFC 793
>
> ABORT Call
>
> SYN-SENT STATE
>
> All queued SENDs and RECEIVEs should be given "connection reset"
> notification, delete the TCB, enter CLOSED state, and return.
>
> SEGMENT ARRIVES
>
> If the state is SYN-SENT then
> If the RST bit is set
>
> If the ACK was acceptable then signal the user "error:
> connection reset", drop the segment, enter CLOSED state,
> delete TCB, and return. Otherwise (no ACK) drop the segment
> and return.
>
> Signed-off-by: Devi Sandeep Endluri V V <dendluri@codeaurora.org>
> ---
> net/ipv4/tcp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git net/ipv4/tcp.c net/ipv4/tcp.c
> index cf3c509..8569dc5e 100644
> --- net/ipv4/tcp.c
> +++ net/ipv4/tcp.c
> @@ -2495,7 +2495,7 @@ static inline bool tcp_need_reset(int state)
> {
> return (1 << state) &
> (TCPF_ESTABLISHED | TCPF_CLOSE_WAIT | TCPF_FIN_WAIT1 |
> - TCPF_FIN_WAIT2 | TCPF_SYN_RECV);
> + TCPF_FIN_WAIT2 | TCPF_SYN_RECV | TCPF_SYN_SENT);
> }
>
> static void tcp_rtx_queue_purge(struct sock *sk)
Hi
1) I do not believe this patch is complete :
You have not changed tcp_disconnect() which seems to have dead code
if we apply your patch.
2) I am not sure we want to send yet another packet if the prior SYN
packets elect no answer.
(It is not clear if your patch applies to this case)
3) If we do not RESET, the other side has not seen the 3rd packet and
should eventually exit from SYN_RECV state and die.
4) A RESET can be lost on the network, and nothing will retransmit it.
Can you describe the use case more precisely, because it seems in
contradiction of a feature that we plan to upstream.
(TCP_SILENT_CLOSE : do not send flood of RST/FIN when a gigantic
server process prematurely dies)
Thanks.
^ permalink raw reply
* Re: [PATCH 0/6] ARM: dts: ti: cpsw: switch to phy-gmii-sel phy driver
From: Tony Lindgren @ 2019-02-20 15:48 UTC (permalink / raw)
To: Grygorii Strashko
Cc: David S. Miller, Kishon Vijay Abraham I, Rob Herring, netdev,
Sekhar Nori, linux-kernel, linux-omap, devicetree,
linux-arm-kernel
In-Reply-To: <1550676319-6440-1-git-send-email-grygorii.strashko@ti.com>
* Grygorii Strashko <grygorii.strashko@ti.com> [190220 07:26]:
> Hi Tony,
>
> Hence prerequisite patches [1] have been merged already I'm sending final set
> of DT patches to complete conversation of TI CPSW driver to use phy-gmii-sel
> phy driver instead of cpsw-phy-sel.
>
> [1] https://lkml.org/lkml/2018/11/26/154
Great, I was wondering about update of that series, will
apply.
Thanks and welcome back!
Tony
^ permalink raw reply
* [PATCH net-next] gso: validate gso_type on ipip style tunnels
From: Willem de Bruijn @ 2019-02-20 15:52 UTC (permalink / raw)
To: netdev; +Cc: davem, Willem de Bruijn
From: Willem de Bruijn <willemb@google.com>
Commit 121d57af308d ("gso: validate gso_type in GSO handlers") added
gso_type validation to existing gso_segment callback functions, to
filter out illegal and potentially dangerous SKB_GSO_DODGY packets.
Convert tunnels that now call inet_gso_segment and ipv6_gso_segment
directly to have their own callbacks and extend validation to these.
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
net/ipv4/af_inet.c | 11 ++++++++++-
net/ipv6/ip6_offload.c | 33 ++++++++++++++++++++++++++++++---
2 files changed, 40 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 0dfb72c46671..eab3ebde981e 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1385,6 +1385,15 @@ struct sk_buff *inet_gso_segment(struct sk_buff *skb,
}
EXPORT_SYMBOL(inet_gso_segment);
+static struct sk_buff *ipip_gso_segment(struct sk_buff *skb,
+ netdev_features_t features)
+{
+ if (!(skb_shinfo(skb)->gso_type & SKB_GSO_IPXIP4))
+ return ERR_PTR(-EINVAL);
+
+ return inet_gso_segment(skb, features);
+}
+
INDIRECT_CALLABLE_DECLARE(struct sk_buff *tcp4_gro_receive(struct list_head *,
struct sk_buff *));
INDIRECT_CALLABLE_DECLARE(struct sk_buff *udp4_gro_receive(struct list_head *,
@@ -1861,7 +1870,7 @@ static struct packet_offload ip_packet_offload __read_mostly = {
static const struct net_offload ipip_offload = {
.callbacks = {
- .gso_segment = inet_gso_segment,
+ .gso_segment = ipip_gso_segment,
.gro_receive = ipip_gro_receive,
.gro_complete = ipip_gro_complete,
},
diff --git a/net/ipv6/ip6_offload.c b/net/ipv6/ip6_offload.c
index 5c045691c302..345882d9c061 100644
--- a/net/ipv6/ip6_offload.c
+++ b/net/ipv6/ip6_offload.c
@@ -383,9 +383,36 @@ static struct packet_offload ipv6_packet_offload __read_mostly = {
},
};
+static struct sk_buff *sit_gso_segment(struct sk_buff *skb,
+ netdev_features_t features)
+{
+ if (!(skb_shinfo(skb)->gso_type & SKB_GSO_IPXIP4))
+ return ERR_PTR(-EINVAL);
+
+ return ipv6_gso_segment(skb, features);
+}
+
+static struct sk_buff *ip4ip6_gso_segment(struct sk_buff *skb,
+ netdev_features_t features)
+{
+ if (!(skb_shinfo(skb)->gso_type & SKB_GSO_IPXIP6))
+ return ERR_PTR(-EINVAL);
+
+ return inet_gso_segment(skb, features);
+}
+
+static struct sk_buff *ip6ip6_gso_segment(struct sk_buff *skb,
+ netdev_features_t features)
+{
+ if (!(skb_shinfo(skb)->gso_type & SKB_GSO_IPXIP6))
+ return ERR_PTR(-EINVAL);
+
+ return ipv6_gso_segment(skb, features);
+}
+
static const struct net_offload sit_offload = {
.callbacks = {
- .gso_segment = ipv6_gso_segment,
+ .gso_segment = sit_gso_segment,
.gro_receive = sit_ip6ip6_gro_receive,
.gro_complete = sit_gro_complete,
},
@@ -393,7 +420,7 @@ static const struct net_offload sit_offload = {
static const struct net_offload ip4ip6_offload = {
.callbacks = {
- .gso_segment = inet_gso_segment,
+ .gso_segment = ip4ip6_gso_segment,
.gro_receive = ip4ip6_gro_receive,
.gro_complete = ip4ip6_gro_complete,
},
@@ -401,7 +428,7 @@ static const struct net_offload ip4ip6_offload = {
static const struct net_offload ip6ip6_offload = {
.callbacks = {
- .gso_segment = ipv6_gso_segment,
+ .gso_segment = ip6ip6_gso_segment,
.gro_receive = sit_ip6ip6_gro_receive,
.gro_complete = ip6ip6_gro_complete,
},
--
2.21.0.rc0.258.g878e2cd30e-goog
^ permalink raw reply related
* Re: skb_can_coalesce() merges tcp frags with XFS-related slab objects
From: Eric Dumazet @ 2019-02-20 15:53 UTC (permalink / raw)
To: Vasily Averin, David S. Miller
Cc: Linux Kernel Network Developers, Ilya Dryomov
In-Reply-To: <f8fde7da-9402-4e17-1bcc-cba08f1ec18b@virtuozzo.com>
On 02/20/2019 05:34 AM, Vasily Averin wrote:
> Dear David,
>
> currently do_tcp_sendpages() calls skb_can_coalesce() to merge proper tcp fragments.
> If these fragments are slab objects and the data is not transferred out of the local host
> then tcp_recvmsg() can crash host on BUG_ON (see [2] below).
>
> There is known usecase when slab objects are provided to tcp_sendpage:
> XFS over locally landed network blockdevice.
>
> I found few such cases:
> - _drbd_send_page() had PageSlab() check log time ago.
> - recently Ilya Dryomov fixed it in ceph
> by commit 7e241f647dc7 "libceph: fall back to sendmsg for slab pages"
>
> Recently OpenVZ team noticed this problem during experiments with
> XFS over locally-landed iscsi target.
>
> I would note: triggered BUG is not a real problem but false alert,
> that though crashes host.
>
> I can fix last problem by adding PageSlab() into iscsi_tcp_segment_map(),
> however it does not fix the problem completely,
> there are chances that the problem will be reproduced again with some other filesystems
> or with some other kind of network blockdevice.
>
> David, what do you think, is it probably better to add PageSlab() check
> directly into skb_can_coalesce()? (see [1] below)
>
No, this would be wrong.
There is no way a page fragment can be backed by slab object,
since a page fragment can be shared (the page refcount needs to be manipulated, without slab/slub
being aware of this)
Please fix the callers.
> Thank you,
> Vasily Averin
>
> [1] The patch preventing the merge of the Slab-based tcp fragments
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index 95d25b010a25..e1d200ba1fef 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -3089,7 +3089,7 @@ static inline bool skb_can_coalesce(struct sk_buff *skb, int i,
> if (i) {
> const struct skb_frag_struct *frag = &skb_shinfo(skb)->frags[i - 1];
>
> - return page == skb_frag_page(frag) &&
> + return page == skb_frag_page(frag) && !PageSlab(page) &&
> off == frag->page_offset + skb_frag_size(frag);
> }
> return false;
>
> [2] oops example, RHEL7-based OpenVZ node, XFS over locally-landed iscsi target
>
> [ 4902.545219] usercopy: kernel memory exposure attempt detected from ffff8c1497c92200 (kmalloc-512) (1024 bytes)
> [ 4902.550585] ------------[ cut here ]------------
> [ 4902.552472] kernel BUG at mm/usercopy.c:72!
> [ 4902.554148] invalid opcode: 0000 [#1] SMP
> [ 4902.555906] Modules linked in: nf_conntrack_netlink xt_mark raw_diag udp_diag netlink_diag af_packet_diag unix_diag dm_service_time iscsi_tcp libiscsi_tcp libiscsi xfs xt_CHECKSUM ip6t_rpfilter ipt_REJECT nf_reject_ipv4 ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat ebtable_broute ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter ip_tables binfmt_misc tun devlink tcp_diag inet_diag ip_set nfnetlink fuse kvm_intel ppdev kvm i2c_piix4 irqbypass sg virtio_balloon parport_pc parport joydev pcspkr libcrc32c br_netfilter veth overlay ip6_vzprivnet ip6_vznetstat
> [ 4903.413397] ip_vznetstat ip_vzprivnet vziolimit vzevent vzlist vzstat vznetstat vznetdev vzmon vzdev bridge pio_kaio pio_nfs pio_direct pfmt_raw pfmt_ploop1 ploop ext4 mbcache jbd2 sd_mod crc_t10dif sr_mod crct10dif_generic cdrom crct10dif_common ata_generic pata_acpi 8021q garp mrp stp llc virtio_net virtio_console virtio_scsi bochs_drm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm ata_piix scsi_transport_iscsi drm libata crc32c_intel serio_raw virtio_pci virtio_ring dm_multipath virtio drm_panel_orientation_quirks floppy sunrpc dm_mirror dm_region_hash dm_log dm_mod [last unloaded: ip_tables]
> [ 4903.433902] CPU: 0 PID: 13793 Comm: tgtd ve: 0 Kdump: loaded Not tainted 3.10.0-957.1.3.vz7.83.4 #1 83.4
> [ 4903.436975] Hardware name: Virtuozzo KVM, BIOS 1.10.2-3.1.vz7.3 04/01/2014
> [ 4903.439474] task: ffff8c14f898c740 ti: ffff8c14f8a94000 task.ti: ffff8c14f8a94000
> [ 4903.442278] RIP: 0010:[<ffffffff9ce59427>] [<ffffffff9ce59427>] __check_object_size+0x87/0x250
> [ 4903.445370] RSP: 0018:ffff8c14f8a97b58 EFLAGS: 00010246
> [ 4903.447547] RAX: 0000000000000062 RBX: ffff8c1497c92200 RCX: 0000000000000000
> [ 4903.450108] RDX: 0000000000000000 RSI: ffff8c167fc138d8 RDI: ffff8c167fc138d8
> [ 4903.452753] RBP: ffff8c14f8a97b78 R08: 0000000000000004 R09: ffff8c166d14af00
> [ 4903.455451] R10: 0000000000000080 R11: ffff97b6016ffff8 R12: 0000000000000400
> [ 4903.458142] R13: 0000000000000001 R14: ffff8c1497c92600 R15: 0000000000000400
> [ 4903.460759] FS: 00007fd59b2b7740(0000) GS:ffff8c167fc00000(0000) knlGS:0000000000000000
> [ 4903.463776] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 4903.466111] CR2: 0000000002701b58 CR3: 00000000b8a98000 CR4: 00000000000006f0
> [ 4903.468860] Call Trace:
> [ 4903.470483] [<ffffffff9cfb310d>] memcpy_toiovec+0x4d/0xb0
> [ 4903.472780] [<ffffffff9d2589e8>] skb_copy_datagram_iovec+0x128/0x280
> [ 4903.475388] [<ffffffff9d2c0646>] tcp_recvmsg+0x246/0xbb0
> [ 4903.477884] [<ffffffff9cdd42cd>] ? __alloc_pages_nodemask+0x26d/0x610
> [ 4903.480432] [<ffffffff9d2ef1d0>] inet_recvmsg+0x80/0xb0
> [ 4903.482718] [<ffffffff9d2467bc>] sock_aio_read.part.12+0x14c/0x170
> [ 4903.485255] [<ffffffff9d246801>] sock_aio_read+0x21/0x30
> [ 4903.487495] [<ffffffff9ce5edd6>] do_sync_read+0x96/0xe0
> [ 4903.489710] [<ffffffff9ce5f8b5>] vfs_read+0x145/0x170
> [ 4903.491975] [<ffffffff9ce606cf>] SyS_read+0x7f/0xf0
> [ 4903.494179] [<ffffffff9d3a4de1>] ? system_call_after_swapgs+0xae/0x146
> [ 4903.496684] [<ffffffff9d3a4e9b>] system_call_fastpath+0x22/0x27
> [ 4903.499143] [<ffffffff9d3a4de1>] ? system_call_after_swapgs+0xae/0x146
> [ 4903.501748] Code: 45 d1 48 c7 c6 f8 c3 68 9d 48 c7 c1 93 5e 69 9d 48 0f 45 f1 49 89 c0 4d 89 e1 48 89 d9 48 c7 c7 68 2b 69 9d 31 c0 e8 4f 1e 53 00 <0f> 0b 0f 1f 80 00 00 00 00 48 c7 c0 00 00 c0 9c 4c 39 f0 73 0d
> [ 4903.510508] RIP [<ffffffff9ce59427>] __check_object_size+0x87/0x250
> [ 4903.513149] RSP <ffff8c14f8a97b58>
>
^ permalink raw reply
* Re: [PATCH net] iptunnel: NULL pointer deref for ip_md_tunnel_xmit
From: Anders Roxell @ 2019-02-20 15:54 UTC (permalink / raw)
To: Alan Maguire
Cc: Networking, David Miller, kuznet, yoshfuji, Alexei Starovoitov,
Daniel Borkmann, kafai, songliubraving, yhs
In-Reply-To: <alpine.LRH.2.20.1902181230310.25660@dhcp-10-175-210-25.vpn.oracle.com>
On Mon, 18 Feb 2019 at 13:37, Alan Maguire <alan.maguire@oracle.com> wrote:
>
> Naresh Kamboju noted the following oops during execution of selftest
> tools/testing/selftests/bpf/test_tunnel.sh on x86_64:
>
> [ 274.120445] BUG: unable to handle kernel NULL pointer dereference
> at 0000000000000000
> [ 274.128285] #PF error: [INSTR]
> [ 274.131351] PGD 8000000414a0e067 P4D 8000000414a0e067 PUD 3b6334067 PMD 0
> [ 274.138241] Oops: 0010 [#1] SMP PTI
> [ 274.141734] CPU: 1 PID: 11464 Comm: ping Not tainted
> 5.0.0-rc4-next-20190129 #1
> [ 274.149046] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
> 2.0b 07/27/2017
> [ 274.156526] RIP: 0010: (null)
> [ 274.160280] Code: Bad RIP value.
> [ 274.163509] RSP: 0018:ffffbc9681f83540 EFLAGS: 00010286
> [ 274.168726] RAX: 0000000000000000 RBX: ffffdc967fa80a18 RCX: 0000000000000000
> [ 274.175851] RDX: ffff9db2ee08b540 RSI: 000000000000000e RDI: ffffdc967fa809a0
> [ 274.182974] RBP: ffffbc9681f83580 R08: ffff9db2c4d62690 R09: 000000000000000c
> [ 274.190098] R10: 0000000000000000 R11: ffff9db2ee08b540 R12: ffff9db31ce7c000
> [ 274.197222] R13: 0000000000000001 R14: 000000000000000c R15: ffff9db3179cf400
> [ 274.204346] FS: 00007ff4ae7c5740(0000) GS:ffff9db31fa80000(0000)
> knlGS:0000000000000000
> [ 274.212424] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 274.218162] CR2: ffffffffffffffd6 CR3: 00000004574da004 CR4: 00000000003606e0
> [ 274.225292] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 274.232416] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 274.239541] Call Trace:
> [ 274.241988] ? tnl_update_pmtu+0x296/0x3b0
> [ 274.246085] ip_md_tunnel_xmit+0x1bc/0x520
> [ 274.250176] gre_fb_xmit+0x330/0x390
> [ 274.253754] gre_tap_xmit+0x128/0x180
> [ 274.257414] dev_hard_start_xmit+0xb7/0x300
> [ 274.261598] sch_direct_xmit+0xf6/0x290
> [ 274.265430] __qdisc_run+0x15d/0x5e0
> [ 274.269007] __dev_queue_xmit+0x2c5/0xc00
> [ 274.273011] ? dev_queue_xmit+0x10/0x20
> [ 274.276842] ? eth_header+0x2b/0xc0
> [ 274.280326] dev_queue_xmit+0x10/0x20
> [ 274.283984] ? dev_queue_xmit+0x10/0x20
> [ 274.287813] arp_xmit+0x1a/0xf0
> [ 274.290952] arp_send_dst.part.19+0x46/0x60
> [ 274.295138] arp_solicit+0x177/0x6b0
> [ 274.298708] ? mod_timer+0x18e/0x440
> [ 274.302281] neigh_probe+0x57/0x70
> [ 274.305684] __neigh_event_send+0x197/0x2d0
> [ 274.309862] neigh_resolve_output+0x18c/0x210
> [ 274.314212] ip_finish_output2+0x257/0x690
> [ 274.318304] ip_finish_output+0x219/0x340
> [ 274.322314] ? ip_finish_output+0x219/0x340
> [ 274.326493] ip_output+0x76/0x240
> [ 274.329805] ? ip_fragment.constprop.53+0x80/0x80
> [ 274.334510] ip_local_out+0x3f/0x70
> [ 274.337992] ip_send_skb+0x19/0x40
> [ 274.341391] ip_push_pending_frames+0x33/0x40
> [ 274.345740] raw_sendmsg+0xc15/0x11d0
> [ 274.349403] ? __might_fault+0x85/0x90
> [ 274.353151] ? _copy_from_user+0x6b/0xa0
> [ 274.357070] ? rw_copy_check_uvector+0x54/0x130
> [ 274.361604] inet_sendmsg+0x42/0x1c0
> [ 274.365179] ? inet_sendmsg+0x42/0x1c0
> [ 274.368937] sock_sendmsg+0x3e/0x50
> [ 274.372460] ___sys_sendmsg+0x26f/0x2d0
> [ 274.376293] ? lock_acquire+0x95/0x190
> [ 274.380043] ? __handle_mm_fault+0x7ce/0xb70
> [ 274.384307] ? lock_acquire+0x95/0x190
> [ 274.388053] ? __audit_syscall_entry+0xdd/0x130
> [ 274.392586] ? ktime_get_coarse_real_ts64+0x64/0xc0
> [ 274.397461] ? __audit_syscall_entry+0xdd/0x130
> [ 274.401989] ? trace_hardirqs_on+0x4c/0x100
> [ 274.406173] __sys_sendmsg+0x63/0xa0
> [ 274.409744] ? __sys_sendmsg+0x63/0xa0
> [ 274.413488] __x64_sys_sendmsg+0x1f/0x30
> [ 274.417405] do_syscall_64+0x55/0x190
> [ 274.421064] entry_SYSCALL_64_after_hwframe+0x49/0xbe
> [ 274.426113] RIP: 0033:0x7ff4ae0e6e87
> [ 274.429686] Code: 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 80 00
> 00 00 00 8b 05 ca d9 2b 00 48 63 d2 48 63 ff 85 c0 75 10 b8 2e 00 00
> 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 53 48 89 f3 48 83 ec 10 48 89 7c
> 24 08
> [ 274.448422] RSP: 002b:00007ffcd9b76db8 EFLAGS: 00000246 ORIG_RAX:
> 000000000000002e
> [ 274.455978] RAX: ffffffffffffffda RBX: 0000000000000040 RCX: 00007ff4ae0e6e87
> [ 274.463104] RDX: 0000000000000000 RSI: 00000000006092e0 RDI: 0000000000000003
> [ 274.470228] RBP: 0000000000000000 R08: 00007ffcd9bc40a0 R09: 00007ffcd9bc4080
> [ 274.477349] R10: 000000000000060a R11: 0000000000000246 R12: 0000000000000003
> [ 274.484475] R13: 0000000000000016 R14: 00007ffcd9b77fa0 R15: 00007ffcd9b78da4
> [ 274.491602] Modules linked in: cls_bpf sch_ingress iptable_filter
> ip_tables algif_hash af_alg x86_pkg_temp_thermal fuse [last unloaded:
> test_bpf]
> [ 274.504634] CR2: 0000000000000000
> [ 274.507976] ---[ end trace 196d18386545eae1 ]---
> [ 274.512588] RIP: 0010: (null)
> [ 274.516334] Code: Bad RIP value.
> [ 274.519557] RSP: 0018:ffffbc9681f83540 EFLAGS: 00010286
> [ 274.524775] RAX: 0000000000000000 RBX: ffffdc967fa80a18 RCX: 0000000000000000
> [ 274.531921] RDX: ffff9db2ee08b540 RSI: 000000000000000e RDI: ffffdc967fa809a0
> [ 274.539082] RBP: ffffbc9681f83580 R08: ffff9db2c4d62690 R09: 000000000000000c
> [ 274.546205] R10: 0000000000000000 R11: ffff9db2ee08b540 R12: ffff9db31ce7c000
> [ 274.553329] R13: 0000000000000001 R14: 000000000000000c R15: ffff9db3179cf400
> [ 274.560456] FS: 00007ff4ae7c5740(0000) GS:ffff9db31fa80000(0000)
> knlGS:0000000000000000
> [ 274.568541] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 274.574277] CR2: ffffffffffffffd6 CR3: 00000004574da004 CR4: 00000000003606e0
> [ 274.581403] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 274.588535] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 274.595658] Kernel panic - not syncing: Fatal exception in interrupt
> [ 274.602046] Kernel Offset: 0x14400000 from 0xffffffff81000000
> (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
> [ 274.612827] ---[ end Kernel panic - not syncing: Fatal exception in
> interrupt ]---
> [ 274.620387] ------------[ cut here ]------------
>
> I'm also seeing the same failure on x86_64, and it reproduces
> consistently.
>
> From poking around it looks like the skb's dst entry is being used
> to calculate the mtu in:
>
> mtu = skb_dst(skb) ? dst_mtu(skb_dst(skb)) : dev->mtu;
>
> ...but because that dst_entry has an "ops" value set to md_dst_ops,
> the various ops (including mtu) are not set:
>
> crash> struct sk_buff._skb_refdst ffff928f87447700 -x
> _skb_refdst = 0xffffcd6fbf5ea590
> crash> struct dst_entry.ops 0xffffcd6fbf5ea590
> ops = 0xffffffffa0193800
> crash> struct dst_ops.mtu 0xffffffffa0193800
> mtu = 0x0
> crash>
>
> I confirmed that the dst entry also has dst->input set to
> dst_md_discard, so it looks like it's an entry that's been
> initialized via __metadata_dst_init alright.
>
> I think the fix here is to use skb_valid_dst(skb) - it checks
> for DST_METADATA also, and with that fix in place, the
> problem - which was previously 100% reproducible - disappears.
>
> The below patch resolves the panic and all bpf tunnel tests pass
> without incident.
>
> Fixes: c8b34e680a09 ("ip_tunnel: Add tnl_update_pmtu in ip_md_tunnel_xmit")
>
> Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
> Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
> Acked-by: Alexei Starovoitov <ast@kernel.org>
I saw the failure on hikey (arm64) also, with this patch test bpf
test_tunnel.sh passed.
Tested-by: Anders Roxell <anders.roxell@linaro.org>
Cheers,
Anders
> ---
> net/ipv4/ip_tunnel.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
> index 893f013..5dcf50c 100644
> --- a/net/ipv4/ip_tunnel.c
> +++ b/net/ipv4/ip_tunnel.c
> @@ -515,9 +515,10 @@ static int tnl_update_pmtu(struct net_device *dev, struct sk_buff *skb,
> mtu = dst_mtu(&rt->dst) - dev->hard_header_len
> - sizeof(struct iphdr) - tunnel_hlen;
> else
> - mtu = skb_dst(skb) ? dst_mtu(skb_dst(skb)) : dev->mtu;
> + mtu = skb_valid_dst(skb) ? dst_mtu(skb_dst(skb)) : dev->mtu;
>
> - skb_dst_update_pmtu(skb, mtu);
> + if (skb_valid_dst(skb))
> + skb_dst_update_pmtu(skb, mtu);
>
> if (skb->protocol == htons(ETH_P_IP)) {
> if (!skb_is_gso(skb) &&
> @@ -530,9 +531,11 @@ static int tnl_update_pmtu(struct net_device *dev, struct sk_buff *skb,
> }
> #if IS_ENABLED(CONFIG_IPV6)
> else if (skb->protocol == htons(ETH_P_IPV6)) {
> - struct rt6_info *rt6 = (struct rt6_info *)skb_dst(skb);
> + struct rt6_info *rt6;
> __be32 daddr;
>
> + rt6 = skb_valid_dst(skb) ? (struct rt6_info *)skb_dst(skb) :
> + NULL;
> daddr = md ? dst : tunnel->parms.iph.daddr;
>
> if (rt6 && mtu < dst_mtu(skb_dst(skb)) &&
> --
> 1.8.3.1
>
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Write in tls_push_record (2)
From: Dmitry Vyukov @ 2019-02-20 15:54 UTC (permalink / raw)
To: syzbot
Cc: aviadye, borisp, davejwatson, David Miller, LKML, netdev,
syzkaller-bugs
In-Reply-To: <00000000000087c36f05727375d2@google.com>
On Thu, Aug 2, 2018 at 3:05 PM syzbot
<syzbot+3d650eba9d63b8de7478@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 44960f2a7b63 staging: ashmem: Fix SIGBUS crash when traver..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=10f7ea72400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=2dc0cd7c2eefb46f
> dashboard link: https://syzkaller.appspot.com/bug?extid=3d650eba9d63b8de7478
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+3d650eba9d63b8de7478@syzkaller.appspotmail.com
This is probably:
#syz dup: KASAN: out-of-bounds Write in tls_push_record
> ==================================================================
> BUG: KASAN: slab-out-of-bounds in tls_fill_prepend include/net/tls.h:339
> [inline]
> BUG: KASAN: slab-out-of-bounds in tls_push_record+0x1091/0x1400
> net/tls/tls_sw.c:239
> Write of size 1 at addr ffff88019c5d8000 by task syz-executor2/11760
>
> CPU: 0 PID: 11760 Comm: syz-executor2 Not tainted 4.18.0-rc7+ #172
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
> print_address_description+0x6c/0x20b mm/kasan/report.c:256
> kasan_report_error mm/kasan/report.c:354 [inline]
> kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
> __asan_report_store1_noabort+0x17/0x20 mm/kasan/report.c:435
> tls_fill_prepend include/net/tls.h:339 [inline]
> tls_push_record+0x1091/0x1400 net/tls/tls_sw.c:239
> tls_sw_push_pending_record+0x22/0x30 net/tls/tls_sw.c:276
> tls_handle_open_record net/tls/tls_main.c:164 [inline]
> tls_sk_proto_close+0x74c/0xae0 net/tls/tls_main.c:264
> inet_release+0x104/0x1f0 net/ipv4/af_inet.c:427
> inet6_release+0x50/0x70 net/ipv6/af_inet6.c:459
> __sock_release+0xd7/0x260 net/socket.c:600
> sock_close+0x19/0x20 net/socket.c:1151
> __fput+0x355/0x8b0 fs/file_table.c:209
> ____fput+0x15/0x20 fs/file_table.c:243
> task_work_run+0x1ec/0x2a0 kernel/task_work.c:113
> tracehook_notify_resume include/linux/tracehook.h:192 [inline]
> exit_to_usermode_loop+0x313/0x370 arch/x86/entry/common.c:166
> prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
> syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
> do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x4105c1
> Code: 75 14 b8 03 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 34 19 00 00 c3 48
> 83 ec 08 e8 0a fc ff ff 48 89 04 24 b8 03 00 00 00 0f 05 <48> 8b 3c 24 48
> 89 c2 e8 53 fc ff ff 48 89 d0 48 83 c4 08 48 3d 01
> RSP: 002b:0000000000a3feb0 EFLAGS: 00000293 ORIG_RAX: 0000000000000003
> RAX: 0000000000000000 RBX: 0000000000000014 RCX: 00000000004105c1
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000013
> RBP: 0000000000000010 R08: 0000000000000000 R09: 0000000000000001
> R10: 0000000000a3fde0 R11: 0000000000000293 R12: 0000000000000000
> R13: 000000000002fd87 R14: 0000000000000094 R15: badc0ffeebadface
>
> Allocated by task 2597:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:448
> set_track mm/kasan/kasan.c:460 [inline]
> kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
> kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490
> kmem_cache_alloc+0x12e/0x760 mm/slab.c:3554
> getname_flags+0xd0/0x5a0 fs/namei.c:140
> user_path_at_empty+0x2d/0x50 fs/namei.c:2584
> user_path_at include/linux/namei.h:57 [inline]
> vfs_statx+0x129/0x210 fs/stat.c:185
> vfs_stat include/linux/fs.h:3102 [inline]
> __do_sys_newstat+0x8f/0x110 fs/stat.c:337
> __se_sys_newstat fs/stat.c:333 [inline]
> __x64_sys_newstat+0x54/0x80 fs/stat.c:333
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> Freed by task 2597:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:448
> set_track mm/kasan/kasan.c:460 [inline]
> __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
> kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
> __cache_free mm/slab.c:3498 [inline]
> kmem_cache_free+0x86/0x2d0 mm/slab.c:3756
> putname+0xf2/0x130 fs/namei.c:261
> filename_lookup+0x397/0x510 fs/namei.c:2330
> user_path_at_empty+0x40/0x50 fs/namei.c:2584
> user_path_at include/linux/namei.h:57 [inline]
> vfs_statx+0x129/0x210 fs/stat.c:185
> vfs_stat include/linux/fs.h:3102 [inline]
> __do_sys_newstat+0x8f/0x110 fs/stat.c:337
> __se_sys_newstat fs/stat.c:333 [inline]
> __x64_sys_newstat+0x54/0x80 fs/stat.c:333
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> The buggy address belongs to the object at ffff88019c5d8980
> which belongs to the cache names_cache of size 4096
> The buggy address is located 2432 bytes to the left of
> 4096-byte region [ffff88019c5d8980, ffff88019c5d9980)
> The buggy address belongs to the page:
> page:ffffea0006717600 count:1 mapcount:0 mapping:ffff8801dad85dc0 index:0x0
> compound_mapcount: 0
> flags: 0x2fffc0000008100(slab|head)
> raw: 02fffc0000008100 ffffea0006470d88 ffffea0006717688 ffff8801dad85dc0
> raw: 0000000000000000 ffff88019c5d8980 0000000100000001 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff88019c5d7f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ffff88019c5d7f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > ffff88019c5d8000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ^
> ffff88019c5d8080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff88019c5d8100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ==================================================================
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> syzbot.
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/00000000000087c36f05727375d2%40google.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH net] ipv6: route: purge exception on removal
From: Paolo Abeni @ 2019-02-20 16:00 UTC (permalink / raw)
To: netdev; +Cc: David Ahern, David S. Miller
In-Reply-To: <460ef555bb02ec46d8a6108aa0d7b0095e11afd1.1550662037.git.pabeni@redhat.com>
On Wed, 2019-02-20 at 15:08 +0100, Paolo Abeni wrote:
> When a netdevice is unregistered, we flush the relevant exception
> via rt6_sync_down_dev() -> fib6_ifdown() -> fib6_del() -> fib6_del_route().
>
> Finally, we end-up calling rt6_remove_exception(), where we release
> the relevant dst, while we keep the references to the related fib6_info and
> dev. Such references should be released later when the dst will be
> destroyed.
>
> There are a number of caches that can keep the exception around for an
> unlimited amount of time - namely dst_cache, possibly even socket cache.
> As a result device registration may hang, as demonstrated by this script:
>
> ip netns add cl
> ip netns add rt
> ip netns add srv
> ip netns exec rt sysctl -w net.ipv6.conf.all.forwarding=1
>
> ip link add name cl_veth type veth peer name cl_rt_veth
> ip link set dev cl_veth netns cl
> ip -n cl link set dev cl_veth up
> ip -n cl addr add dev cl_veth 2001::2/64
> ip -n cl route add default via 2001::1
>
> ip -n cl link add tunv6 type ip6tnl mode ip6ip6 local 2001::2 remote 2002::1 hoplimit 64 dev cl_veth
> ip -n cl link set tunv6 up
> ip -n cl addr add 2013::2/64 dev tunv6
>
> ip link set dev cl_rt_veth netns rt
> ip -n rt link set dev cl_rt_veth up
> ip -n rt addr add dev cl_rt_veth 2001::1/64
>
> ip link add name rt_srv_veth type veth peer name srv_veth
> ip link set dev srv_veth netns srv
> ip -n srv link set dev srv_veth up
> ip -n srv addr add dev srv_veth 2002::1/64
> ip -n srv route add default via 2002::2
>
> ip -n srv link add tunv6 type ip6tnl mode ip6ip6 local 2002::1 remote 2001::2 hoplimit 64 dev srv_veth
> ip -n srv link set tunv6 up
> ip -n srv addr add 2013::1/64 dev tunv6
>
> ip link set dev rt_srv_veth netns rt
> ip -n rt link set dev rt_srv_veth up
> ip -n rt addr add dev rt_srv_veth 2002::2/64
>
> ip netns exec srv netserver & sleep 0.1
> ip netns exec cl ping6 -c 4 2013::1
> ip netns exec cl netperf -H 2013::1 -t TCP_STREAM -l 3 & sleep 1
> ip -n rt link set dev rt_srv_veth mtu 1400
> wait %2
>
> ip -n cl link del cl_veth
>
> This commit addresses the issue purging all the references held by the
> exception at time, as we currently do for e.g. ipv6 pcpu dst entries.
>
> Fixes: 93531c674315 ("net/ipv6: separate handling of FIB entries from dst based routes")
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> ---
> net/ipv6/route.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index 964491cf3672..43a819ae46c2 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -1274,11 +1274,21 @@ static DEFINE_SPINLOCK(rt6_exception_lock);
> static void rt6_remove_exception(struct rt6_exception_bucket *bucket,
> struct rt6_exception *rt6_ex)
> {
> + struct fib6_info *from;
> struct net *net;
>
> if (!bucket || !rt6_ex)
> return;
>
> + /* purge completely the exception to allow releasing the held resources:
> + * some [sk] cache may keep the dst around for unlimited time
> + */
> + from = rcu_dereference_protected(rt6_ex->rt6i->from,
> + lockdep_is_held(&rt6_exception_lock));
> + rcu_assign_pointer(rt6_ex->rt6i->from, NULL);
> + fib6_info_release(from);
> + dst_dev_put(&rt6_ex->rt6i->dst);
> +
> net = dev_net(rt6_ex->rt6i->dst.dev);
uhm... This is possibly racy, if dev goes away on dst_dev_put(). I'll
send a v2 reordering the operation so that we don't access dev (and net
) after dst_dev_put().
Sorry for the noise,
Paolo
^ 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