* Re: [PATCH net-next] cxgb4vf: display pause settings
From: David Miller @ 2018-04-17 17:54 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, indranil, venkatesh
In-Reply-To: <1523958431-8623-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Tue, 17 Apr 2018 15:17:11 +0530
> Add support to display pause settings
>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Applied to net-next, thank you.
^ permalink raw reply
* Re: [PATCH bpf-next v3 7/8] bpf: add documentation for eBPF helpers (51-57)
From: Andrey Ignatov @ 2018-04-17 17:55 UTC (permalink / raw)
To: Quentin Monnet
Cc: daniel, ast, netdev, oss-drivers, linux-doc, linux-man,
Lawrence Brakmo, Yonghong Song, Josef Bacik
In-Reply-To: <20180417143438.7018-8-quentin.monnet@netronome.com>
Quentin Monnet <quentin.monnet@netronome.com> [Tue, 2018-04-17 07:36 -0700]:
> Add documentation for eBPF helper functions to bpf.h user header file.
> This documentation can be parsed with the Python script provided in
> another commit of the patch series, in order to provide a RST document
> that can later be converted into a man page.
>
> The objective is to make the documentation easily understandable and
> accessible to all eBPF developers, including beginners.
>
> This patch contains descriptions for the following helper functions:
>
> Helpers from Lawrence:
> - bpf_setsockopt()
> - bpf_getsockopt()
> - bpf_sock_ops_cb_flags_set()
>
> Helpers from Yonghong:
> - bpf_perf_event_read_value()
> - bpf_perf_prog_read_value()
>
> Helper from Josef:
> - bpf_override_return()
>
> Helper from Andrey:
> - bpf_bind()
>
> v3:
> - bpf_perf_event_read_value(): Fix time of selection for perf event type
> in description. Remove occurences of "cores" to avoid confusion with
> "CPU".
> - bpf_bind(): Remove last paragraph of description, which was off topic.
>
> Cc: Lawrence Brakmo <brakmo@fb.com>
> Cc: Yonghong Song <yhs@fb.com>
> Cc: Josef Bacik <jbacik@fb.com>
> Cc: Andrey Ignatov <rdna@fb.com>
> Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
>
> fix patch 7: Yonghong and Andrey
> ---
> include/uapi/linux/bpf.h | 178 +++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 178 insertions(+)
>
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index dd79a1c82adf..350459c583de 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> + *
> + * int bpf_bind(struct bpf_sock_addr_kern *ctx, struct sockaddr *addr, int addr_len)
> + * Description
> + * Bind the socket associated to *ctx* to the address pointed by
> + * *addr*, of length *addr_len*. This allows for making outgoing
> + * connection from the desired IP address, which can be useful for
> + * example when all processes inside a cgroup should use one
> + * single IP address on a host that has multiple IP configured.
> + *
> + * This helper works for IPv4 and IPv6, TCP and UDP sockets. The
> + * domain (*addr*\ **->sa_family**) must be **AF_INET** (or
> + * **AF_INET6**). Looking for a free port to bind to can be
> + * expensive, therefore binding to port is not permitted by the
> + * helper: *addr*\ **->sin_port** (or **sin6_port**, respectively)
> + * must be set to zero.
> + * Return
> + * 0 on success, or a negative error in case of failure.
Acked-by: Andrey Ignatov <rdna@fb.com>
for bpf_bind() helper.
--
Andrey Ignatov
^ permalink raw reply
* Re: [PATCH net] vlan: Fix reading memory beyond skb->tail in skb_vlan_tagged_multi
From: David Miller @ 2018-04-17 18:02 UTC (permalink / raw)
To: makita.toshiaki; +Cc: netdev, jesse
In-Reply-To: <1523958374-2471-1-git-send-email-makita.toshiaki@lab.ntt.co.jp>
From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Date: Tue, 17 Apr 2018 18:46:14 +0900
> Syzkaller spotted an old bug which leads to reading skb beyond tail by 4
> bytes on vlan tagged packets.
> This is caused because skb_vlan_tagged_multi() did not check
> skb_headlen.
...
> Fixes: 58e998c6d239 ("offloading: Force software GSO for multiple vlan tags.")
> Reported-and-tested-by: syzbot+0bbe42c764feafa82c5a@syzkaller.appspotmail.com
> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Applied and queued up for -stable, thank you.
^ permalink raw reply
* Re: [PATCH net-next] ipv6: send netlink notifications for manually configured addresses
From: David Miller @ 2018-04-17 18:05 UTC (permalink / raw)
To: lorenzo.bianconi; +Cc: netdev, thaller
In-Reply-To: <934e7797f7fb3541e36c01c5c753e0592679527b.1523956672.git.lorenzo.bianconi@redhat.com>
From: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Date: Tue, 17 Apr 2018 11:54:39 +0200
> Send a netlink notification when userspace adds a manually configured
> address if DAD is enabled and optimistic flag isn't set.
> Moreover send RTM_DELADDR notifications for tentative addresses.
>
> Some userspace applications (e.g. NetworkManager) are interested in
> addr netlink events albeit the address is still in tentative state,
> however events are not sent if DAD process is not completed.
> If the address is added and immediately removed userspace listeners
> are not notified. This behaviour can be easily reproduced by using
> veth interfaces:
>
> $ ip -b - <<EOF
>> link add dev vm1 type veth peer name vm2
>> link set dev vm1 up
>> link set dev vm2 up
>> addr add 2001:db8:a:b:1:2:3:4/64 dev vm1
>> addr del 2001:db8:a:b:1:2:3:4/64 dev vm1
> EOF
>
> This patch reverts the behaviour introduced by the commit f784ad3d79e5
> ("ipv6: do not send RTM_DELADDR for tentative addresses")
>
> Suggested-by: Thomas Haller <thaller@redhat.com>
> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Ok, applied to net-next.
It would be really nice if we clearly documented somewhere the exact
situations where we desire ipv6 address netlink notifications to be
sent out.
Maybe even a common function that guards the event emission, where we
encode the rules. Or a comment somewhere prominent. Something like
that.
Right now this isn't spelled out clearly anywhere, and that's probably
why things keep being adjusted back and forth like this.
Thank you.
^ permalink raw reply
* Re: [PATCH 08/10] net: ax88796: Make reset more robust on AX88796B
From: Florian Fainelli @ 2018-04-17 18:08 UTC (permalink / raw)
To: Andrew Lunn, Michael Karcher
Cc: Michael Schmitz, netdev, Linux/m68k, John Paul Adrian Glaubitz,
Michael Karcher
In-Reply-To: <20180417130106.GG2591@lunn.ch>
On 04/17/2018 06:01 AM, Andrew Lunn wrote:
> On Tue, Apr 17, 2018 at 07:18:10AM +0200, Michael Karcher wrote:
>> [Andrew, sorry for the dup. I did hit reply-to-auhor instead of
>> reply-to-all first.]
>>
>> Andrew Lunn schrieb:
>>>>> This should really be fixed in the PHY driver, not the MAC.
>>>>
>>>> OK - do you want this separate, or as part of this series? Might have
>>>> a few side effects on more commonly used hardware, perhaps?
>>>
>>> Hi Michael
>>>
>>> What PHY driver is used?
>> The ax88796b comes with its own integrated (buggy) PHY needing this
>> workaround. This PHY has its own ID which is not known by Linux, so it is
>> using the genphy driver as fallback.
>>
>>> In the driver you can implement a .soft_reset
>>> function which first does the dummy write, and then uses
>>> genphy_soft_reset() to do the actual reset.
>> We could do that - but I dont't see the point in creating a PHY driver
>> that is only ever used by this MAC driver, just to add a single line to
>> the genphy driver. If the same PHY might be used with a different MAC,
>> you definitely would have a point there, though.
>
>
> Hi Michael
>
> We try to keep the core code clean, and put all workarounds for buggy
> hardware in drivers specific to them. It just helps keep the core code
> maintainable.
>
> I would prefer a driver specific to this PHY with the workaround. But
> lets see what Florian says.
If you are already using the generic PHY driver, coming up with a custom
one that only overrides the soft_reset and/or config_init callback is
really not that much work, and as Andrew says, it helps make things
clearer and properly isolated. As far as where to place that driver, you
can either create a new file under drivers/net/phy/* or you can even
register a phy_driver instance from within ax88796 if that makes it any
clearer.
FWIW, there are plenty of examples where there is a PHY driver used by a
single MAC, and that is perfectly fine, because the abstraction is still
preserved.
--
Florian
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: phy: Add binding for vendor specific C45 MDIO address space
From: Florian Fainelli @ 2018-04-17 18:18 UTC (permalink / raw)
To: vicentiu.galanopulo, andrew, robh, netdev, linux-kernel,
mark.rutland, davem, marcel, devicetree
Cc: alexandru.marginean, madalin.bucur
In-Reply-To: <20180417090233.21548-2-vicentiu.galanopulo@nxp.com>
On 04/17/2018 02:02 AM, Vicentiu Galanopulo wrote:
> The extra property enables the discovery on the MDIO bus
> of the PHYs which have a vendor specific address space
> for accessing the C45 MDIO registers.
>
> Signed-off-by: Vicentiu Galanopulo <vicentiu.galanopulo@nxp.com>
> ---
> Documentation/devicetree/bindings/net/phy.txt | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/phy.txt b/Documentation/devicetree/bindings/net/phy.txt
> index d2169a5..82692e2 100644
> --- a/Documentation/devicetree/bindings/net/phy.txt
> +++ b/Documentation/devicetree/bindings/net/phy.txt
> @@ -61,6 +61,11 @@ Optional Properties:
> - reset-deassert-us: Delay after the reset was deasserted in microseconds.
> If this property is missing the delay will be skipped.
>
> +- dev-addr: If set, it indicates the device address of the PHY to be used
> + when accessing the C45 PHY registers over MDIO. It is used for vendor specific
> + register space addresses that do no conform to standard address for the MDIO
> + registers (e.g. MMD30)
Rob made that comment earlier, and I have to ask again now, why don't we
have the Clause 45 PHY binding be modified such that you have a reg
property that has #address-size = 2? This should be entirely backwards
compatible, but it would allow you to specify that device address in a
more traditional way.
> +
> Example:
>
> ethernet-phy@0 {
> @@ -72,4 +77,5 @@ ethernet-phy@0 {
> reset-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
> reset-assert-us = <1000>;
> reset-deassert-us = <2000>;
> + dev-addr = <0x1e>;
> };
>
--
Florian
^ permalink raw reply
* Re: [PATCH net-next 2/3] net: phy: Change the array size to 32 for device_ids
From: Florian Fainelli @ 2018-04-17 18:18 UTC (permalink / raw)
To: vicentiu.galanopulo, andrew, robh, netdev, linux-kernel,
mark.rutland, davem, marcel, devicetree
Cc: alexandru.marginean, madalin.bucur
In-Reply-To: <20180417090233.21548-3-vicentiu.galanopulo@nxp.com>
On 04/17/2018 02:02 AM, Vicentiu Galanopulo wrote:
> In the context of enabling the discovery of the PHYs
> which have the C45 MDIO address space in a non-standard
> address: num_ids in get_phy_c45_ids, has the
> value 8 (ARRAY_SIZE(c45_ids->device_ids)), but the
> u32 *devs can store 32 devices in the bitfield.
>
> If a device is stored in *devs, in bits 32 to 9
> (bit counting in lookup loop starts from 1), it will
> not be found.
>
> Signed-off-by: Vicentiu Galanopulo <vicentiu.galanopulo@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH bpf-next v3 00/10] BTF: BPF Type Format
From: Martin KaFai Lau @ 2018-04-17 18:19 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: netdev, Alexei Starovoitov, Daniel Borkmann, kernel-team
In-Reply-To: <20180416202200.GA3553@kernel.org>
On Mon, Apr 16, 2018 at 05:22:00PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Mon, Apr 16, 2018 at 12:33:17PM -0700, Martin KaFai Lau escreveu:
> > This patch introduces BPF Type Format (BTF).
> >
> > BTF (BPF Type Format) is the meta data format which describes
> > the data types of BPF program/map. Hence, it basically focus
> > on the C programming language which the modern BPF is primary
> > using. The first use case is to provide a generic pretty print
> > capability for a BPF map.
> >
> > A modified pahole (Cc: Arnaldo) that can convert dwarf to BTF is here:
> > https://github.com/iamkafai/pahole/tree/btf
>
> Thanks for CCing me, no changes since when you posted the pahole
> patches, I gave it a quick look, seems sane, will try to merge and push
> a new pahole version out so that distros can pick it, at least fedora
> will 8-)
Thanks! Right, the last commit should be on April 3rd.
>
> - Arnaldo
>
> > Please see individual patch for details.
> >
> > v3:
> > - Rebase to bpf-next
> > - Fix sparse warning (by adding static)
> > - Add BTF header logging: btf_verifier_log_hdr()
> > - Fix the alignment test on btf->type_off
> > - Add tests for the BTF header
> > - Lower the max BTF size to 16MB. It should be enough
> > for some time. We could raise it later if it would
> > be needed.
> >
> > v2:
> > - Use kvfree where needed in patch 1 and 2
> > - Also consider BTF_INT_OFFSET() in the btf_int_check_meta()
> > in patch 1
> > - Fix an incorrect goto target in map_create() during
> > the btf-error-path in patch 7
> > - re-org some local vars to keep the rev xmas tree in btf.c
> >
> > Martin KaFai Lau (10):
> > bpf: btf: Introduce BPF Type Format (BTF)
> > bpf: btf: Validate type reference
> > bpf: btf: Check members of struct/union
> > bpf: btf: Add pretty print capability for data with BTF type info
> > bpf: btf: Add BPF_BTF_LOAD command
> > bpf: btf: Add BPF_OBJ_GET_INFO_BY_FD support to BTF fd
> > bpf: btf: Add pretty print support to the basic arraymap
> > bpf: btf: Sync bpf.h and btf.h to tools/
> > bpf: btf: Add BTF support to libbpf
> > bpf: btf: Add BTF tests
> >
> > include/linux/bpf.h | 20 +-
> > include/linux/btf.h | 48 +
> > include/uapi/linux/bpf.h | 12 +
> > include/uapi/linux/btf.h | 132 ++
> > kernel/bpf/Makefile | 1 +
> > kernel/bpf/arraymap.c | 50 +
> > kernel/bpf/btf.c | 2093 ++++++++++++++++++++++++++
> > kernel/bpf/inode.c | 146 +-
> > kernel/bpf/syscall.c | 51 +-
> > tools/include/uapi/linux/bpf.h | 13 +
> > tools/include/uapi/linux/btf.h | 132 ++
> > tools/lib/bpf/Build | 2 +-
> > tools/lib/bpf/bpf.c | 92 +-
> > tools/lib/bpf/bpf.h | 16 +
> > tools/lib/bpf/btf.c | 377 +++++
> > tools/lib/bpf/btf.h | 22 +
> > tools/lib/bpf/libbpf.c | 148 +-
> > tools/lib/bpf/libbpf.h | 3 +
> > tools/testing/selftests/bpf/Makefile | 26 +-
> > tools/testing/selftests/bpf/test_btf.c | 1669 ++++++++++++++++++++
> > tools/testing/selftests/bpf/test_btf_haskv.c | 48 +
> > tools/testing/selftests/bpf/test_btf_nokv.c | 43 +
> > 22 files changed, 5103 insertions(+), 41 deletions(-)
> > create mode 100644 include/linux/btf.h
> > create mode 100644 include/uapi/linux/btf.h
> > create mode 100644 kernel/bpf/btf.c
> > create mode 100644 tools/include/uapi/linux/btf.h
> > create mode 100644 tools/lib/bpf/btf.c
> > create mode 100644 tools/lib/bpf/btf.h
> > create mode 100644 tools/testing/selftests/bpf/test_btf.c
> > create mode 100644 tools/testing/selftests/bpf/test_btf_haskv.c
> > create mode 100644 tools/testing/selftests/bpf/test_btf_nokv.c
> >
> > --
> > 2.9.5
^ permalink raw reply
* Re: [PATCH RESEND net-next v2] KEYS: DNS: limit the length of option strings
From: Eric Biggers @ 2018-04-17 18:23 UTC (permalink / raw)
To: David Miller; +Cc: netdev, keyrings, mark.rutland, ebiggers
In-Reply-To: <20180417.134316.1413649044013070735.davem@davemloft.net>
On Tue, Apr 17, 2018 at 01:43:16PM -0400, David Miller wrote:
> From: Eric Biggers <ebiggers3@gmail.com>
> Date: Mon, 16 Apr 2018 14:29:22 -0700
>
> > From: Eric Biggers <ebiggers@google.com>
> >
> > Adding a dns_resolver key whose payload contains a very long option name
> > resulted in that string being printed in full. This hit the WARN_ONCE()
> > in set_precision() during the printk(), because printk() only supports a
> > precision of up to 32767 bytes:
> >
> > precision 1000000 too large
> > WARNING: CPU: 0 PID: 752 at lib/vsprintf.c:2189 vsnprintf+0x4bc/0x5b0
> >
> > Fix it by limiting option strings (combined name + value) to a much more
> > reasonable 128 bytes. The exact limit is arbitrary, but currently the
> > only recognized option is formatted as "dnserror=%lu" which fits well
> > within this limit.
> >
> > Also ratelimit the printks.
> >
> > Reproducer:
> >
> > perl -e 'print "#", "A" x 1000000, "\x00"' | keyctl padd dns_resolver desc @s
> >
> > This bug was found using syzkaller.
> >
> > Reported-by: Mark Rutland <mark.rutland@arm.com>
> > Fixes: 4a2d789267e0 ("DNS: If the DNS server returns an error, allow that to be cached [ver #2]")
> > Signed-off-by: Eric Biggers <ebiggers@google.com>
>
> Applied, thanks.
Can you queue this up for stable too? syzbot has been hitting this on older
kernel versions.
Eric
^ permalink raw reply
* Re: [PATCH RESEND net-next v2] KEYS: DNS: limit the length of option strings
From: David Miller @ 2018-04-17 18:24 UTC (permalink / raw)
To: ebiggers3; +Cc: netdev, keyrings, mark.rutland, ebiggers
In-Reply-To: <20180417182340.GB9237@gmail.com>
From: Eric Biggers <ebiggers3@gmail.com>
Date: Tue, 17 Apr 2018 11:23:40 -0700
> Can you queue this up for stable too? syzbot has been hitting this on older
> kernel versions.
If you want a patch bound for stable, it must show up in Linus's tree
first which means you should target 'net' rather than 'net-next'.
^ permalink raw reply
* Re: [PATCH net-next 3/3] net: phy: Enable C45 PHYs with vendor specific address space
From: Florian Fainelli @ 2018-04-17 18:27 UTC (permalink / raw)
To: vicentiu.galanopulo, andrew, robh, netdev, linux-kernel,
mark.rutland, davem, marcel, devicetree
Cc: alexandru.marginean, madalin.bucur
In-Reply-To: <20180417090233.21548-4-vicentiu.galanopulo@nxp.com>
On 04/17/2018 02:02 AM, Vicentiu Galanopulo wrote:
> A search of the dev-addr property is done in of_mdiobus_register.
> If the property is found in the PHY node, of_mdiobus_register_vend_spec_phy()
> is called. This is a wrapper function for of_mdiobus_register_phy()
> which finds the device in package based on dev-addr, and fills
> devices_addrs, which is a new field added to phy_c45_device_ids.
> This new field will store the dev-addr property on the same index
> where the device in package has been found.
>
> The of_mdiobus_register_phy() now contains an extra parameter,
> which is struct phy_c45_device_ids *c45_ids.
> If c45_ids is not NULL, get_vend_spec_addr_phy_device() is called
> and c45_ids are propagated all the way to get_phy_c45_ids().
>
> Having dev-addr stored in devices_addrs, in get_phy_c45_ids(),
> when probing the identifiers, dev-addr can be extracted from
> devices_addrs and probed if devices_addrs[current_identifier] is not 0.
I must clearly be missing something, but why are you introducing all
these conditionals instead of updating the existing code to be able to
operate against an arbitrary dev-addr value, and then just making sure
the first thing you do is fetch that property from Device Tree? There is
no way someone is going to be testing with your specific use case in the
future (except yourselves) so unless you make supporting an arbitrary
"dev-addr" value become part of how the code works, this is going to be
breaking badly.
And please, can you keep me copied for next submissions?
>
> Signed-off-by: Vicentiu Galanopulo <vicentiu.galanopulo@nxp.com>
> ---
> drivers/net/phy/phy_device.c | 49 +++++++++++++++++--
> drivers/of/of_mdio.c | 113 +++++++++++++++++++++++++++++++++++++++++--
> include/linux/phy.h | 14 ++++++
> 3 files changed, 169 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index ac23322..5c79fd8 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -457,7 +457,7 @@ static int get_phy_c45_devs_in_pkg(struct mii_bus *bus, int addr, int dev_addr,
> static int get_phy_c45_ids(struct mii_bus *bus, int addr, u32 *phy_id,
> struct phy_c45_device_ids *c45_ids) {
> int phy_reg;
> - int i, reg_addr;
> + int i, reg_addr, dev_addr;
> const int num_ids = ARRAY_SIZE(c45_ids->device_ids);
> u32 *devs = &c45_ids->devices_in_package;
>
> @@ -493,13 +493,23 @@ static int get_phy_c45_ids(struct mii_bus *bus, int addr, u32 *phy_id,
> if (!(c45_ids->devices_in_package & (1 << i)))
> continue;
>
> - reg_addr = MII_ADDR_C45 | i << 16 | MII_PHYSID1;
> + /* if c45_ids->devices_addrs for the current id is not 0,
> + * then dev-addr was defined in the PHY device tree node,
> + * and the PHY has been seen as a valid device, and added
> + * in the package. In this case we can use the
> + * dev-addr(c45_ids->devices_addrs[i]) to do the MDIO
> + * reading of the PHY ID.
> + */
> + dev_addr = !!c45_ids->devices_addrs[i] ?
> + c45_ids->devices_addrs[i] : i;
> +
> + reg_addr = MII_ADDR_C45 | dev_addr << 16 | MII_PHYSID1;
> phy_reg = mdiobus_read(bus, addr, reg_addr);
> if (phy_reg < 0)
> return -EIO;
> c45_ids->device_ids[i] = (phy_reg & 0xffff) << 16;
>
> - reg_addr = MII_ADDR_C45 | i << 16 | MII_PHYSID2;
> + reg_addr = MII_ADDR_C45 | dev_addr << 16 | MII_PHYSID2;
> phy_reg = mdiobus_read(bus, addr, reg_addr);
> if (phy_reg < 0)
> return -EIO;
> @@ -551,6 +561,39 @@ static int get_phy_id(struct mii_bus *bus, int addr, u32 *phy_id,
> }
>
> /**
> + * get_vend_spec_addr_phy_device - reads the specified PHY device
> + * and returns its @phy_device struct
> + * @bus: the target MII bus
> + * @addr: PHY address on the MII bus
> + * @is_c45: If true the PHY uses the 802.3 clause 45 protocol
> + * @c45_ids: Query the c45_ids to see if a PHY with a vendor specific
> + * register address space was defined in the PHY device tree
> + * node by adding the "dev-addr" property to the node.
> + * Store the c45 ID information about the rest of the PHYs
> + * found PHYs on the MDIO bus during probing.
> + *
> + * Description: Reads the ID registers of the PHY at @addr on the
> + * @bus, then allocates and returns the phy_device to represent it.
> + */
> +struct phy_device *get_vend_spec_addr_phy_device(struct mii_bus *bus,
> + int addr, bool is_c45,
> + struct phy_c45_device_ids *c45_ids)
> +{
> + u32 phy_id = 0;
> + int r;
> +
> + r = get_phy_id(bus, addr, &phy_id, is_c45, c45_ids);
> + if (r)
> + return ERR_PTR(r);
> +
> + /* If the phy_id is mostly Fs, there is no device there */
> + if ((phy_id & 0x1fffffff) == 0x1fffffff)
> + return ERR_PTR(-ENODEV);
> +
> + return phy_device_create(bus, addr, phy_id, is_c45, c45_ids);
> +}
> +
> +/**
> * get_phy_device - reads the specified PHY device and returns its @phy_device
> * struct
> * @bus: the target MII bus
> diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
> index 8c0c927..52e8bfb 100644
> --- a/drivers/of/of_mdio.c
> +++ b/drivers/of/of_mdio.c
> @@ -45,7 +45,8 @@ static int of_get_phy_id(struct device_node *device, u32 *phy_id)
> }
>
> static int of_mdiobus_register_phy(struct mii_bus *mdio,
> - struct device_node *child, u32 addr)
> + struct device_node *child, u32 addr,
> + struct phy_c45_device_ids *c45_ids)
> {
> struct phy_device *phy;
> bool is_c45;
> @@ -58,7 +59,12 @@ static int of_mdiobus_register_phy(struct mii_bus *mdio,
> if (!is_c45 && !of_get_phy_id(child, &phy_id))
> phy = phy_device_create(mdio, addr, phy_id, 0, NULL);
> else
> - phy = get_phy_device(mdio, addr, is_c45);
> + if (c45_ids)
> + phy = get_vend_spec_addr_phy_device(mdio,
> + addr, is_c45,
> + c45_ids);
> + else
> + phy = get_phy_device(mdio, addr, is_c45);
> if (IS_ERR(phy))
> return PTR_ERR(phy);
>
> @@ -190,6 +196,72 @@ static bool of_mdiobus_child_is_phy(struct device_node *child)
> return false;
> }
>
> +static void of_fill_c45_devices_addrs(u32 dev_addr,
> + struct phy_c45_device_ids *c45_ids)
> +{
> + int i;
> + const int num_ids = ARRAY_SIZE(c45_ids->device_ids);
> +
> + /* Search through all Device Identifiers
> + * and set dev_addr in c45_ids->devices_addrs,
> + * if the device bit is set in
> + * c45_ids->devices_in_package
> + */
> + for (i = 1; i < num_ids; i++) {
> + if (!(c45_ids->devices_in_package & (1 << i)))
> + continue;
> +
> + c45_ids->devices_addrs[i] = dev_addr;
> + }
> +}
> +
> +static int of_find_devaddr_in_pkg(struct mii_bus *bus, u32 addr, u32 dev_addr,
> + struct phy_c45_device_ids *c45_ids)
> +{
> + u32 *devs = &c45_ids->devices_in_package;
> + int phy_reg, reg_addr;
> +
> + reg_addr = MII_ADDR_C45 | dev_addr << 16 | MDIO_DEVS2;
> + phy_reg = mdiobus_read(bus, addr, reg_addr);
> + if (phy_reg < 0)
> + return -EIO;
> +
> + *devs = (phy_reg & 0xffff) << 16;
> +
> + reg_addr = MII_ADDR_C45 | dev_addr << 16 | MDIO_DEVS1;
> + phy_reg = mdiobus_read(bus, addr, reg_addr);
> + if (phy_reg < 0)
> + return -EIO;
> +
> + *devs |= (phy_reg & 0xffff);
> +
> + return 0;
> +}
> +
> +/*
> + * Finds the device in package and populates the c45_ids
> + * if any device is found at dev_addr address. After this
> + * the PHY is registered
> + */
> +static int of_mdiobus_register_vend_spec_phy(struct mii_bus *mdio,
> + struct device_node *child,
> + u32 addr, u32 dev_addr)
> +{
> + struct phy_c45_device_ids c45_ids = {0};
> + int dev_err = 0;
> +
> + if (!dev_addr)
> + goto register_phy;
> +
> + dev_err = of_find_devaddr_in_pkg(mdio, addr, dev_addr, &c45_ids);
> +
> + if (!dev_err)
> + of_fill_c45_devices_addrs(dev_addr, &c45_ids);
> +
> +register_phy:
> + return of_mdiobus_register_phy(mdio, child, addr, &c45_ids);
> +}
> +
> /**
> * of_mdiobus_register - Register mii_bus and create PHYs from the device tree
> * @mdio: pointer to mii_bus structure
> @@ -202,7 +274,10 @@ int of_mdiobus_register(struct mii_bus *mdio, struct device_node *np)
> {
> struct device_node *child;
> bool scanphys = false;
> + bool dev_addr_found = true;
> int addr, rc;
> + int dev_addr = 0;
> + int ret;
>
> /* Do not continue if the node is disabled */
> if (!of_device_is_available(np))
> @@ -226,6 +301,14 @@ int of_mdiobus_register(struct mii_bus *mdio, struct device_node *np)
>
> /* Loop over the child nodes and register a phy_device for each phy */
> for_each_available_child_of_node(np, child) {
> + /* Check if dev-addr is set in the PHY node */
> + ret = of_property_read_u32(child, "dev-addr", &dev_addr);
> +
> + if (ret < 0) {
> + /* either not set or invalid */
> + dev_addr_found = false;
> + }
> +
> addr = of_mdio_parse_addr(&mdio->dev, child);
> if (addr < 0) {
> scanphys = true;
> @@ -233,7 +316,14 @@ int of_mdiobus_register(struct mii_bus *mdio, struct device_node *np)
> }
>
> if (of_mdiobus_child_is_phy(child))
> - rc = of_mdiobus_register_phy(mdio, child, addr);
> + if (dev_addr_found)
> + rc = of_mdiobus_register_vend_spec_phy(mdio,
> + child,
> + addr,
> + dev_addr);
> + else
> + rc = of_mdiobus_register_phy(mdio, child,
> + addr, NULL);
> else
> rc = of_mdiobus_register_device(mdio, child, addr);
>
> @@ -248,8 +338,16 @@ int of_mdiobus_register(struct mii_bus *mdio, struct device_node *np)
> if (!scanphys)
> return 0;
>
> + /* reset device found variable */
> + dev_addr_found = true;
> +
> /* auto scan for PHYs with empty reg property */
> for_each_available_child_of_node(np, child) {
> + /* Check if dev-addr is set in the PHY node,
> + * for PHYs which don't have reg property set
> + */
> + ret = of_property_read_u32(child, "dev-addr", &dev_addr);
> +
> /* Skip PHYs with reg property set */
> if (of_find_property(child, "reg", NULL))
> continue;
> @@ -264,7 +362,14 @@ int of_mdiobus_register(struct mii_bus *mdio, struct device_node *np)
> child->name, addr);
>
> if (of_mdiobus_child_is_phy(child)) {
> - rc = of_mdiobus_register_phy(mdio, child, addr);
> + if (dev_addr_found)
> + rc = of_mdiobus_register_vend_spec_phy(mdio,
> + child,
> + addr,
> + dev_addr);
> + else
> + rc = of_mdiobus_register_phy(mdio, child,
> + addr, NULL);
> if (rc && rc != -ENODEV)
> goto unregister;
> }
> diff --git a/include/linux/phy.h b/include/linux/phy.h
> index 26aa320..889d85e 100644
> --- a/include/linux/phy.h
> +++ b/include/linux/phy.h
> @@ -357,10 +357,13 @@ enum phy_state {
> * struct phy_c45_device_ids - 802.3-c45 Device Identifiers
> * @devices_in_package: Bit vector of devices present.
> * @device_ids: The device identifer for each present device.
> + * @devices_addrs: The devices addresses from the device tree
> + * for each present device.
> */
> struct phy_c45_device_ids {
> u32 devices_in_package;
> u32 device_ids[32];
> + u32 devices_addrs[32];
> };
>
> /* phy_device: An instance of a PHY
> @@ -904,6 +907,9 @@ struct phy_device *phy_device_create(struct mii_bus *bus, int addr, int phy_id,
> struct phy_c45_device_ids *c45_ids);
> #if IS_ENABLED(CONFIG_PHYLIB)
> struct phy_device *get_phy_device(struct mii_bus *bus, int addr, bool is_c45);
> +struct phy_device *get_vend_spec_addr_phy_device(struct mii_bus *bus, int addr,
> + bool is_c45,
> + struct phy_c45_device_ids *c45_ids);
> int phy_device_register(struct phy_device *phy);
> void phy_device_free(struct phy_device *phydev);
> #else
> @@ -913,6 +919,14 @@ struct phy_device *get_phy_device(struct mii_bus *bus, int addr, bool is_c45)
> return NULL;
> }
>
> +static inline
> +struct phy_device *get_vend_spec_addr_phy_device(struct mii_bus *bus, int addr,
> + bool is_c45,
> + struct phy_c45_device_ids *c45_ids)
> +{
> + return NULL;
> +}
> +
> static inline int phy_device_register(struct phy_device *phy)
> {
> return 0;
>
--
Florian
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: phy: Add binding for vendor specific C45 MDIO address space
From: Andrew Lunn @ 2018-04-17 18:27 UTC (permalink / raw)
To: Florian Fainelli
Cc: vicentiu.galanopulo, robh, netdev, linux-kernel, mark.rutland,
davem, marcel, devicetree, alexandru.marginean, madalin.bucur
In-Reply-To: <bc00cc86-2293-0fd2-4e98-c516f59f97ce@gmail.com>
On Tue, Apr 17, 2018 at 11:18:20AM -0700, Florian Fainelli wrote:
> On 04/17/2018 02:02 AM, Vicentiu Galanopulo wrote:
> > The extra property enables the discovery on the MDIO bus
> > of the PHYs which have a vendor specific address space
> > for accessing the C45 MDIO registers.
> >
> > Signed-off-by: Vicentiu Galanopulo <vicentiu.galanopulo@nxp.com>
> > ---
> > Documentation/devicetree/bindings/net/phy.txt | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/net/phy.txt b/Documentation/devicetree/bindings/net/phy.txt
> > index d2169a5..82692e2 100644
> > --- a/Documentation/devicetree/bindings/net/phy.txt
> > +++ b/Documentation/devicetree/bindings/net/phy.txt
> > @@ -61,6 +61,11 @@ Optional Properties:
> > - reset-deassert-us: Delay after the reset was deasserted in microseconds.
> > If this property is missing the delay will be skipped.
> >
> > +- dev-addr: If set, it indicates the device address of the PHY to be used
> > + when accessing the C45 PHY registers over MDIO. It is used for vendor specific
> > + register space addresses that do no conform to standard address for the MDIO
> > + registers (e.g. MMD30)
>
> Rob made that comment earlier, and I have to ask again now, why don't we
> have the Clause 45 PHY binding be modified such that you have a reg
> property that has #address-size = 2? This should be entirely backwards
> compatible, but it would allow you to specify that device address in a
> more traditional way.
Hi Florian
I think we might get into trouble when we have both c22 and c45 on the
same bus. Two different reg formats. I would have to try it and see to
be sure.
Andrew
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: phy: Add binding for vendor specific C45 MDIO address space
From: Florian Fainelli @ 2018-04-17 18:29 UTC (permalink / raw)
To: Andrew Lunn
Cc: vicentiu.galanopulo, robh, netdev, linux-kernel, mark.rutland,
davem, marcel, devicetree, alexandru.marginean, madalin.bucur
In-Reply-To: <20180417182741.GC6688@lunn.ch>
On 04/17/2018 11:27 AM, Andrew Lunn wrote:
> On Tue, Apr 17, 2018 at 11:18:20AM -0700, Florian Fainelli wrote:
>> On 04/17/2018 02:02 AM, Vicentiu Galanopulo wrote:
>>> The extra property enables the discovery on the MDIO bus
>>> of the PHYs which have a vendor specific address space
>>> for accessing the C45 MDIO registers.
>>>
>>> Signed-off-by: Vicentiu Galanopulo <vicentiu.galanopulo@nxp.com>
>>> ---
>>> Documentation/devicetree/bindings/net/phy.txt | 6 ++++++
>>> 1 file changed, 6 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/net/phy.txt b/Documentation/devicetree/bindings/net/phy.txt
>>> index d2169a5..82692e2 100644
>>> --- a/Documentation/devicetree/bindings/net/phy.txt
>>> +++ b/Documentation/devicetree/bindings/net/phy.txt
>>> @@ -61,6 +61,11 @@ Optional Properties:
>>> - reset-deassert-us: Delay after the reset was deasserted in microseconds.
>>> If this property is missing the delay will be skipped.
>>>
>>> +- dev-addr: If set, it indicates the device address of the PHY to be used
>>> + when accessing the C45 PHY registers over MDIO. It is used for vendor specific
>>> + register space addresses that do no conform to standard address for the MDIO
>>> + registers (e.g. MMD30)
>>
>> Rob made that comment earlier, and I have to ask again now, why don't we
>> have the Clause 45 PHY binding be modified such that you have a reg
>> property that has #address-size = 2? This should be entirely backwards
>> compatible, but it would allow you to specify that device address in a
>> more traditional way.
>
> Hi Florian
>
> I think we might get into trouble when we have both c22 and c45 on the
> same bus. Two different reg formats. I would have to try it and see to
> be sure.
Hum indeed, we would no longer be able to mix and match on the same MDIO
bus, unless we give C22 PHYs a "fake" second cell. Disregard that idea
then, and let's stick with 'dev-addr'.
--
Florian
^ permalink raw reply
* Re: [PATCH RESEND net-next v2] KEYS: DNS: limit the length of option strings
From: Eric Biggers @ 2018-04-17 18:37 UTC (permalink / raw)
To: David Miller; +Cc: netdev, keyrings, mark.rutland, ebiggers
In-Reply-To: <20180417.142437.1105065334888296683.davem@davemloft.net>
On Tue, Apr 17, 2018 at 02:24:37PM -0400, David Miller wrote:
> From: Eric Biggers <ebiggers3@gmail.com>
> Date: Tue, 17 Apr 2018 11:23:40 -0700
>
> > Can you queue this up for stable too? syzbot has been hitting this on older
> > kernel versions.
>
> If you want a patch bound for stable, it must show up in Linus's tree
> first which means you should target 'net' rather than 'net-next'.
Okay, can you move the patch there, or do I need to resend, or is it too late
already? It's a clean cherry-pick. Sorry, I'm not too familiar with the quirks
of net and netdev -- most other maintainers do things differently.
Thanks,
Eric
^ permalink raw reply
* Re: [PATCH 04/10] net: ax88796: Add block_input/output hooks to ax_plat_data
From: kbuild test robot @ 2018-04-17 18:46 UTC (permalink / raw)
To: Michael Schmitz
Cc: kbuild-all, netdev, linux-m68k, Michael.Karcher, Michael Schmitz,
Michael Karcher
In-Reply-To: <1523916285-6057-5-git-send-email-schmitzmic@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2005 bytes --]
Hi Michael,
I love your patch! Perhaps something to improve:
[auto build test WARNING on v4.16]
[cannot apply to net-next/master net/master v4.17-rc1 next-20180417]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Michael-Schmitz/New-network-driver-for-Amiga-X-Surf-100-m68k/20180417-141150
config: arm-samsung (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All warnings (new ones prefixed by >>):
In file included from arch/arm/mach-s3c24xx/mach-anubis.c:42:0:
>> include/net/ax88796.h:35:11: warning: 'struct sk_buff' declared inside parameter list will not be visible outside of this definition or declaration
struct sk_buff *skb, int ring_offset);
^~~~~~~
vim +35 include/net/ax88796.h
20
21 struct ax_plat_data {
22 unsigned int flags;
23 unsigned char wordlength; /* 1 or 2 */
24 unsigned char dcr_val; /* default value for DCR */
25 unsigned char rcr_val; /* default value for RCR */
26 unsigned char gpoc_val; /* default value for GPOC */
27 u32 *reg_offsets; /* register offsets */
28 u8 *mac_addr; /* MAC addr (only used when
29 AXFLG_MAC_FROMPLATFORM is used */
30
31 /* uses default ax88796 buffer if set to NULL */
32 void (*block_output)(struct net_device *dev, int count,
33 const unsigned char *buf, int star_page);
34 void (*block_input)(struct net_device *dev, int count,
> 35 struct sk_buff *skb, int ring_offset);
36 };
37
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 22607 bytes --]
^ permalink raw reply
* Re: [PATCH RESEND net-next v2] KEYS: DNS: limit the length of option strings
From: David Miller @ 2018-04-17 18:52 UTC (permalink / raw)
To: ebiggers3; +Cc: netdev, keyrings, mark.rutland, ebiggers
In-Reply-To: <20180417183736.GC9237@gmail.com>
From: Eric Biggers <ebiggers3@gmail.com>
Date: Tue, 17 Apr 2018 11:37:36 -0700
> On Tue, Apr 17, 2018 at 02:24:37PM -0400, David Miller wrote:
>> From: Eric Biggers <ebiggers3@gmail.com>
>> Date: Tue, 17 Apr 2018 11:23:40 -0700
>>
>> > Can you queue this up for stable too? syzbot has been hitting this on older
>> > kernel versions.
>>
>> If you want a patch bound for stable, it must show up in Linus's tree
>> first which means you should target 'net' rather than 'net-next'.
>
> Okay, can you move the patch there, or do I need to resend, or is it too late
> already? It's a clean cherry-pick. Sorry, I'm not too familiar with the quirks
> of net and netdev -- most other maintainers do things differently.
It's already in net-next, so submit another copy based on net.
^ permalink raw reply
* Re: [PATCH RESEND net-next] ipv6: provide Kconfig switch to disable accept_ra by default
From: David Miller @ 2018-04-17 19:05 UTC (permalink / raw)
To: mschiffer; +Cc: netdev, kuznet, yoshfuji, linux-kernel
In-Reply-To: <b39b1b4304524c43dfd83280aea4cfb4e8ac97f5.1523959377.git.mschiffer@universe-factory.net>
From: Matthias Schiffer <mschiffer@universe-factory.net>
Date: Tue, 17 Apr 2018 12:04:50 +0200
> Many distributions and users prefer to handle router advertisements in
> userspace; one example is OpenWrt, which includes a combined RA and DHCPv6
> client. For such configurations, accept_ra should not be enabled by
> default.
>
> As setting net.ipv6.conf.default.accept_ra via sysctl.conf or similar
> facilities may be too late to catch all interfaces and common sysctl.conf
> tools do not allow setting an option for all existing interfaces, this
> patch provides a Kconfig option to control the default value of
> default.accept_ra.
>
> Using default.accept_ra is preferable to all.accept_ra for our usecase,
> as disabling all.accept_ra would preclude users from explicitly enabling
> accept_ra on individual interfaces.
>
> Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
This kind of Kconfig option makes an irreversible behavior choice at
compile time, which satisfies one set of users whilst completely
precluding another set.
So no matter what setting a distribution chooses, one set of users are
basically out of luck.
For that reason I consider this a poor approach.
I hate module options, but at least with that the user can choose
regardless of what the distribution maker decided to do with their
kernel.
This is essentially how we handle "disable_ipv6"
I'm not applying this, because it is as much of a step backwards as
it is a step forward, sorry.
^ permalink raw reply
* Re: [PATCH net-next 1/5] virtio: Add support for SCTP checksum offloading
From: Vlad Yasevich @ 2018-04-17 19:06 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Vladislav Yasevich, netdev, linux-sctp, virtualization, jasowang,
nhorman
In-Reply-To: <20180416200743-mutt-send-email-mst@kernel.org>
On 04/16/2018 01:09 PM, Michael S. Tsirkin wrote:
> On Mon, Apr 16, 2018 at 09:45:48AM -0400, Vlad Yasevich wrote:
>> On 04/11/2018 06:49 PM, Michael S. Tsirkin wrote:
>>> On Mon, Apr 02, 2018 at 09:40:02AM -0400, Vladislav Yasevich wrote:
>>>> To support SCTP checksum offloading, we need to add a new feature
>>>> to virtio_net, so we can negotiate support between the hypervisor
>>>> and the guest.
>>>>
>>>> The signalling to the guest that an alternate checksum needs to
>>>> be used is done via a new flag in the virtio_net_hdr. If the
>>>> flag is set, the host will know to perform an alternate checksum
>>>> calculation, which right now is only CRC32c.
>>>>
>>>> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
>>>> ---
>>>> drivers/net/virtio_net.c | 11 ++++++++---
>>>> include/linux/virtio_net.h | 6 ++++++
>>>> include/uapi/linux/virtio_net.h | 2 ++
>>>> 3 files changed, 16 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>>>> index 7b187ec..b601294 100644
>>>> --- a/drivers/net/virtio_net.c
>>>> +++ b/drivers/net/virtio_net.c
>>>> @@ -2724,9 +2724,14 @@ static int virtnet_probe(struct virtio_device *vdev)
>>>> /* Do we support "hardware" checksums? */
>>>> if (virtio_has_feature(vdev, VIRTIO_NET_F_CSUM)) {
>>>> /* This opens up the world of extra features. */
>>>> - dev->hw_features |= NETIF_F_HW_CSUM | NETIF_F_SG;
>>>> + netdev_features_t sctp = 0;
>>>> +
>>>> + if (virtio_has_feature(vdev, VIRTIO_NET_F_SCTP_CSUM))
>>>> + sctp |= NETIF_F_SCTP_CRC;
>>>> +
>>>> + dev->hw_features |= NETIF_F_HW_CSUM | NETIF_F_SG | sctp;
>>>> if (csum)
>>>> - dev->features |= NETIF_F_HW_CSUM | NETIF_F_SG;
>>>> + dev->features |= NETIF_F_HW_CSUM | NETIF_F_SG | sctp;
>>>>
>>>> if (virtio_has_feature(vdev, VIRTIO_NET_F_GSO)) {
>>>> dev->hw_features |= NETIF_F_TSO
>>>> @@ -2952,7 +2957,7 @@ static struct virtio_device_id id_table[] = {
>>>> };
>>>>
>>>> #define VIRTNET_FEATURES \
>>>> - VIRTIO_NET_F_CSUM, VIRTIO_NET_F_GUEST_CSUM, \
>>>> + VIRTIO_NET_F_CSUM, VIRTIO_NET_F_GUEST_CSUM, VIRTIO_NET_F_SCTP_CSUM, \
>>>> VIRTIO_NET_F_MAC, \
>>>> VIRTIO_NET_F_HOST_TSO4, VIRTIO_NET_F_HOST_UFO, VIRTIO_NET_F_HOST_TSO6, \
>>>> VIRTIO_NET_F_HOST_ECN, VIRTIO_NET_F_GUEST_TSO4, VIRTIO_NET_F_GUEST_TSO6, \
>>>> diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
>>>> index f144216..2e7a64a 100644
>>>> --- a/include/linux/virtio_net.h
>>>> +++ b/include/linux/virtio_net.h
>>>> @@ -39,6 +39,9 @@ static inline int virtio_net_hdr_to_skb(struct sk_buff *skb,
>>>>
>>>> if (!skb_partial_csum_set(skb, start, off))
>>>> return -EINVAL;
>>>> +
>>>> + if (hdr->flags & VIRTIO_NET_HDR_F_CSUM_NOT_INET)
>>>> + skb->csum_not_inet = 1;
>>>> }
>>>>
>>>> if (hdr->gso_type != VIRTIO_NET_HDR_GSO_NONE) {
>>>> @@ -96,6 +99,9 @@ static inline int virtio_net_hdr_from_skb(const struct sk_buff *skb,
>>>> hdr->flags = VIRTIO_NET_HDR_F_DATA_VALID;
>>>> } /* else everything is zero */
>>>>
>>>> + if (skb->csum_not_inet)
>>>> + hdr->flags &= VIRTIO_NET_HDR_F_CSUM_NOT_INET;
>>>> +
>>>> return 0;
>>>> }
>>>>
>>>> diff --git a/include/uapi/linux/virtio_net.h b/include/uapi/linux/virtio_net.h
>>>> index 5de6ed3..3f279c8 100644
>>>> --- a/include/uapi/linux/virtio_net.h
>>>> +++ b/include/uapi/linux/virtio_net.h
>>>> @@ -36,6 +36,7 @@
>>>> #define VIRTIO_NET_F_GUEST_CSUM 1 /* Guest handles pkts w/ partial csum */
>>>> #define VIRTIO_NET_F_CTRL_GUEST_OFFLOADS 2 /* Dynamic offload configuration. */
>>>> #define VIRTIO_NET_F_MTU 3 /* Initial MTU advice */
>>>> +#define VIRTIO_NET_F_SCTP_CSUM 4 /* SCTP checksum offload support */
>>>> #define VIRTIO_NET_F_MAC 5 /* Host has given MAC address. */
>>>> #define VIRTIO_NET_F_GUEST_TSO4 7 /* Guest can handle TSOv4 in. */
>>>> #define VIRTIO_NET_F_GUEST_TSO6 8 /* Guest can handle TSOv6 in. */
>>>
>>> Is this a guest or a host checksum? We should differenciate between the
>>> two.
>>
>> I suppose this is HOST checksum, since it behaves like VIRTIO_NET_F_CSUM only for
>> SCTP. I couldn't find the use for the GUEST side flag, since there technically
>> isn't any validations and there is no additional mappings from VIRTIO flag to a
>> NETIF flag.
>>
>> If the feature is negotiated, the guest ends up generating partially check-summed
>> packets, and the host turns on appropriate flags on it's side. The host will
>> also make sure the checksum if fixed up if the guest doesn't support it.
>> So 1 flag is currently all that is needed.
>>
>> -vlad
>
> I see code handling VIRTIO_NET_HDR_F_CSUM_NOT_INET on RX side. Host
> needs to know whether it's ok/worth it to set this flag, too.
I think I understand. I have to re-consider outside of the context of
Linux behavior.
-vlad
>
>>>
>>>
>>>> @@ -101,6 +102,7 @@ struct virtio_net_config {
>>>> struct virtio_net_hdr_v1 {
>>>> #define VIRTIO_NET_HDR_F_NEEDS_CSUM 1 /* Use csum_start, csum_offset */
>>>> #define VIRTIO_NET_HDR_F_DATA_VALID 2 /* Csum is valid */
>>>> +#define VIRTIO_NET_HDR_F_CSUM_NOT_INET 4 /* Checksum is not inet */
>>>> __u8 flags;
>>>> #define VIRTIO_NET_HDR_GSO_NONE 0 /* Not a GSO frame */
>>>> #define VIRTIO_NET_HDR_GSO_TCPV4 1 /* GSO frame, IPv4 TCP (TSO) */
>>>> --
>>>> 2.9.5
^ permalink raw reply
* [PATCH RESEND net v2] KEYS: DNS: limit the length of option strings
From: Eric Biggers @ 2018-04-17 19:07 UTC (permalink / raw)
To: netdev, David S . Miller; +Cc: keyrings, Mark Rutland, Eric Biggers
From: Eric Biggers <ebiggers@google.com>
Adding a dns_resolver key whose payload contains a very long option name
resulted in that string being printed in full. This hit the WARN_ONCE()
in set_precision() during the printk(), because printk() only supports a
precision of up to 32767 bytes:
precision 1000000 too large
WARNING: CPU: 0 PID: 752 at lib/vsprintf.c:2189 vsnprintf+0x4bc/0x5b0
Fix it by limiting option strings (combined name + value) to a much more
reasonable 128 bytes. The exact limit is arbitrary, but currently the
only recognized option is formatted as "dnserror=%lu" which fits well
within this limit.
Also ratelimit the printks.
Reproducer:
perl -e 'print "#", "A" x 1000000, "\x00"' | keyctl padd dns_resolver desc @s
This bug was found using syzkaller.
Reported-by: Mark Rutland <mark.rutland@arm.com>
Fixes: 4a2d789267e0 ("DNS: If the DNS server returns an error, allow that to be cached [ver #2]")
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
net/dns_resolver/dns_key.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/net/dns_resolver/dns_key.c b/net/dns_resolver/dns_key.c
index 8396705deffc..40c851693f77 100644
--- a/net/dns_resolver/dns_key.c
+++ b/net/dns_resolver/dns_key.c
@@ -91,9 +91,9 @@ dns_resolver_preparse(struct key_preparsed_payload *prep)
next_opt = memchr(opt, '#', end - opt) ?: end;
opt_len = next_opt - opt;
- if (!opt_len) {
- printk(KERN_WARNING
- "Empty option to dns_resolver key\n");
+ if (opt_len <= 0 || opt_len > 128) {
+ pr_warn_ratelimited("Invalid option length (%d) for dns_resolver key\n",
+ opt_len);
return -EINVAL;
}
@@ -127,10 +127,8 @@ dns_resolver_preparse(struct key_preparsed_payload *prep)
}
bad_option_value:
- printk(KERN_WARNING
- "Option '%*.*s' to dns_resolver key:"
- " bad/missing value\n",
- opt_nlen, opt_nlen, opt);
+ pr_warn_ratelimited("Option '%*.*s' to dns_resolver key: bad/missing value\n",
+ opt_nlen, opt_nlen, opt);
return -EINVAL;
} while (opt = next_opt + 1, opt < end);
}
--
2.17.0.484.g0c8726318c-goog
^ permalink raw reply related
* Re: [PATCH net] sfc: check RSS is active for filter insert
From: David Miller @ 2018-04-17 19:13 UTC (permalink / raw)
To: bkenward; +Cc: netdev, linux-net-drivers
In-Reply-To: <3b70d5bb-fef4-466b-3b40-fb76b0a55659@solarflare.com>
From: Bert Kenward <bkenward@solarflare.com>
Date: Tue, 17 Apr 2018 13:32:39 +0100
> For some firmware variants - specifically 'capture packed stream' - RSS
> filters are not valid. We must check if RSS is actually active rather
> than merely enabled.
>
> Fixes: 42356d9a137b ("sfc: support RSS spreading of ethtool ntuple filters")
> Signed-off-by: Bert Kenward <bkenward@solarflare.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCHv2 net-next] vxlan: add ttl inherit support
From: David Miller @ 2018-04-17 19:16 UTC (permalink / raw)
To: liuhangbin; +Cc: netdev, jbenc, lucien.xin, sbrivio
In-Reply-To: <1523969574-3279-1-git-send-email-liuhangbin@gmail.com>
From: Hangbin Liu <liuhangbin@gmail.com>
Date: Tue, 17 Apr 2018 20:52:54 +0800
> Like tos inherit, ttl inherit should also means inherit the inner protocol's
> ttl values, which actually not implemented in vxlan yet.
>
> But we could not treat ttl == 0 as "use the inner TTL", because that would be
> used also when the "ttl" option is not specified and that would be a behavior
> change, and breaking real use cases.
>
> So add a different attribute IFLA_VXLAN_TTL_INHERIT when "ttl inherit" is
> specified.
>
> ---
> v2: As suggested by Stefano, clean up function ip_tunnel_get_ttl().
>
> Suggested-by: Jiri Benc <jbenc@redhat.com>
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
I already applied V1 of your patch.
Furthermore, this commit message would cause your signoffs and other tags
to be removed due to the "---" deliminator.
I generally encourage people to leave the change history text _in_ the
commit message anyways. It is useful information for the future.
^ permalink raw reply
* Re: [PATCH RESEND net v2] KEYS: DNS: limit the length of option strings
From: David Miller @ 2018-04-17 19:18 UTC (permalink / raw)
To: ebiggers3; +Cc: netdev, keyrings, mark.rutland, ebiggers
In-Reply-To: <20180417190706.217384-1-ebiggers3@gmail.com>
From: Eric Biggers <ebiggers3@gmail.com>
Date: Tue, 17 Apr 2018 12:07:06 -0700
> From: Eric Biggers <ebiggers@google.com>
>
> Adding a dns_resolver key whose payload contains a very long option name
> resulted in that string being printed in full. This hit the WARN_ONCE()
> in set_precision() during the printk(), because printk() only supports a
> precision of up to 32767 bytes:
>
> precision 1000000 too large
> WARNING: CPU: 0 PID: 752 at lib/vsprintf.c:2189 vsnprintf+0x4bc/0x5b0
>
> Fix it by limiting option strings (combined name + value) to a much more
> reasonable 128 bytes. The exact limit is arbitrary, but currently the
> only recognized option is formatted as "dnserror=%lu" which fits well
> within this limit.
>
> Also ratelimit the printks.
>
> Reproducer:
>
> perl -e 'print "#", "A" x 1000000, "\x00"' | keyctl padd dns_resolver desc @s
>
> This bug was found using syzkaller.
>
> Reported-by: Mark Rutland <mark.rutland@arm.com>
> Fixes: 4a2d789267e0 ("DNS: If the DNS server returns an error, allow that to be cached [ver #2]")
> Signed-off-by: Eric Biggers <ebiggers@google.com>
Applied and qeueud up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next 2/4] net/smc: handle sockopt TCP_NODELAY
From: David Miller @ 2018-04-17 19:23 UTC (permalink / raw)
To: ubraun; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl, ubraun
In-Reply-To: <20180417151815.77191-3-ubraun@linux.ibm.com>
From: Ursula Braun <ubraun@linux.ibm.com>
Date: Tue, 17 Apr 2018 17:18:13 +0200
> From: Ursula Braun <ubraun@linux.vnet.ibm.com>
>
> TCP sockopts must not interfere with the CLC handshake on the
> CLC socket. Therefore, we defer some of them till the CLC
> handshake has completed, like resetting TCP_NODELAY.
>
> While touching setsockopt, the TCP_FASTOPEN sockopts are
> ignored, since SMC-connection setup is based on the TCP
> three-way-handshake.
>
> Signed-off-by: Ursula Braun <ubraun@linux.vnet.ibm.com>
Especially with fast-open, if you don't support the socket option
you should signal an error.
Also, the deferral mechanism means you'll never properly propagate
any errors back to the user. The kernel_setsockopt() return value
isn't validated at all.
Color me not impressed at all with this change.
These kind of things have to have clear and proper semantics, plus
full error processing with proper propagation back to the user.
^ permalink raw reply
* Re: [PATCH 08/10] net: ax88796: Make reset more robust on AX88796B
From: Michael Schmitz @ 2018-04-17 19:25 UTC (permalink / raw)
To: Florian Fainelli
Cc: Andrew Lunn, Michael Karcher, netdev, Linux/m68k,
John Paul Adrian Glaubitz, Michael Karcher
In-Reply-To: <4e18a2db-b2e5-2000-b1c3-4c6ddcc0d3ed@gmail.com>
Thanks Florian,
I'll keep the Asix PHY driver separate from ax88796 for now. Mainly to
simplify testing. Let's see whether it can be used by any other MAC -
can still fold it into ax88796 later.
Cheers,
Michael
On Wed, Apr 18, 2018 at 6:08 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 04/17/2018 06:01 AM, Andrew Lunn wrote:
>> On Tue, Apr 17, 2018 at 07:18:10AM +0200, Michael Karcher wrote:
>>> [Andrew, sorry for the dup. I did hit reply-to-auhor instead of
>>> reply-to-all first.]
>>>
>>> Andrew Lunn schrieb:
>>>>>> This should really be fixed in the PHY driver, not the MAC.
>>>>>
>>>>> OK - do you want this separate, or as part of this series? Might have
>>>>> a few side effects on more commonly used hardware, perhaps?
>>>>
>>>> Hi Michael
>>>>
>>>> What PHY driver is used?
>>> The ax88796b comes with its own integrated (buggy) PHY needing this
>>> workaround. This PHY has its own ID which is not known by Linux, so it is
>>> using the genphy driver as fallback.
>>>
>>>> In the driver you can implement a .soft_reset
>>>> function which first does the dummy write, and then uses
>>>> genphy_soft_reset() to do the actual reset.
>>> We could do that - but I dont't see the point in creating a PHY driver
>>> that is only ever used by this MAC driver, just to add a single line to
>>> the genphy driver. If the same PHY might be used with a different MAC,
>>> you definitely would have a point there, though.
>>
>>
>> Hi Michael
>>
>> We try to keep the core code clean, and put all workarounds for buggy
>> hardware in drivers specific to them. It just helps keep the core code
>> maintainable.
>>
>> I would prefer a driver specific to this PHY with the workaround. But
>> lets see what Florian says.
>
> If you are already using the generic PHY driver, coming up with a custom
> one that only overrides the soft_reset and/or config_init callback is
> really not that much work, and as Andrew says, it helps make things
> clearer and properly isolated. As far as where to place that driver, you
> can either create a new file under drivers/net/phy/* or you can even
> register a phy_driver instance from within ax88796 if that makes it any
> clearer.
>
> FWIW, there are plenty of examples where there is a PHY driver used by a
> single MAC, and that is perfectly fine, because the abstraction is still
> preserved.
> --
> Florian
^ permalink raw reply
* [net 1/1] tipc: fix use-after-free in tipc_nametbl_stop
From: Jon Maloy @ 2018-04-17 19:25 UTC (permalink / raw)
To: davem, netdev
Cc: mohan.krishna.ghanta.krishnamurthy, tung.q.nguyen, hoang.h.le,
jon.maloy, canh.d.luu, ying.xue, tipc-discussion
When we delete a service item in tipc_nametbl_stop() we loop over
all service ranges in the service's RB tree, and for each service
range we loop over its pertaining publications while calling
tipc_service_remove_publ() for each of them.
However, tipc_service_remove_publ() has the side effect that it also
removes the comprising service range item when there are no publications
left. This leads to a "use-after-free" access when the inner loop
continues to the next iteration, since the range item holding the list
we are looping no longer exists.
We fix this by moving the delete of the service range item outside
the said function. Instead, we now let the two functions calling it
test if the list is empty and perform the removal when that is the
case.
Reported-by: syzbot+d64b64afc55660106556@syzkaller.appspotmail.com
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
---
net/tipc/name_table.c | 29 +++++++++++++++++------------
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/net/tipc/name_table.c b/net/tipc/name_table.c
index 4068eaa..dd1c4fa 100644
--- a/net/tipc/name_table.c
+++ b/net/tipc/name_table.c
@@ -241,7 +241,8 @@ static struct publication *tipc_service_insert_publ(struct net *net,
static struct publication *tipc_service_remove_publ(struct net *net,
struct tipc_service *sc,
u32 lower, u32 upper,
- u32 node, u32 key)
+ u32 node, u32 key,
+ struct service_range **rng)
{
struct tipc_subscription *sub, *tmp;
struct service_range *sr;
@@ -275,19 +276,15 @@ static struct publication *tipc_service_remove_publ(struct net *net,
list_del(&p->all_publ);
list_del(&p->local_publ);
-
- /* Remove service range item if this was its last publication */
- if (list_empty(&sr->all_publ)) {
+ if (list_empty(&sr->all_publ))
last = true;
- rb_erase(&sr->tree_node, &sc->ranges);
- kfree(sr);
- }
/* Notify any waiting subscriptions */
list_for_each_entry_safe(sub, tmp, &sc->subscriptions, service_list) {
tipc_sub_report_overlap(sub, p->lower, p->upper, TIPC_WITHDRAWN,
p->port, p->node, p->scope, last);
}
+ *rng = sr;
return p;
}
@@ -379,13 +376,20 @@ struct publication *tipc_nametbl_remove_publ(struct net *net, u32 type,
u32 node, u32 key)
{
struct tipc_service *sc = tipc_service_find(net, type);
+ struct service_range *sr = NULL;
struct publication *p = NULL;
if (!sc)
return NULL;
spin_lock_bh(&sc->lock);
- p = tipc_service_remove_publ(net, sc, lower, upper, node, key);
+ p = tipc_service_remove_publ(net, sc, lower, upper, node, key, &sr);
+
+ /* Remove service range item if this was its last publication */
+ if (sr && list_empty(&sr->all_publ)) {
+ rb_erase(&sr->tree_node, &sc->ranges);
+ kfree(sr);
+ }
/* Delete service item if this no more publications and subscriptions */
if (RB_EMPTY_ROOT(&sc->ranges) && list_empty(&sc->subscriptions)) {
@@ -747,16 +751,17 @@ int tipc_nametbl_init(struct net *net)
static void tipc_service_delete(struct net *net, struct tipc_service *sc)
{
struct service_range *sr, *tmpr;
- struct publication *p, *tmpb;
+ struct publication *p, *tmp;
spin_lock_bh(&sc->lock);
rbtree_postorder_for_each_entry_safe(sr, tmpr, &sc->ranges, tree_node) {
- list_for_each_entry_safe(p, tmpb,
- &sr->all_publ, all_publ) {
+ list_for_each_entry_safe(p, tmp, &sr->all_publ, all_publ) {
tipc_service_remove_publ(net, sc, p->lower, p->upper,
- p->node, p->key);
+ p->node, p->key, &sr);
kfree_rcu(p, rcu);
}
+ rb_erase(&sr->tree_node, &sc->ranges);
+ kfree(sr);
}
hlist_del_init_rcu(&sc->service_list);
spin_unlock_bh(&sc->lock);
--
2.1.4
^ permalink raw reply related
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