* [PATCH v2 1/2] net: stmmac: Delete dead code for MDIO registration
From: Romain Perier @ 2017-08-21 11:45 UTC (permalink / raw)
To: Giuseppe Cavallaro, Alexandre Torgue, Andrew Lunn,
Florian Fainelli
Cc: netdev, linux-kernel, Romain Perier
In-Reply-To: <20170821114530.13706-1-romain.perier@collabora.com>
This code is no longer used, the logging function was changed by commit
fbca164776e4 ("net: stmmac: Use the right logging functi").
Fixes: fbca164776e4 ("net: stmmac: Use the right logging functi")
Signed-off-by: Romain Perier <romain.perier@collabora.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 16 ----------------
1 file changed, 16 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index 72ec711fcba2..f5f37bfa1d58 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -248,9 +248,6 @@ int stmmac_mdio_register(struct net_device *ndev)
found = 0;
for (addr = 0; addr < PHY_MAX_ADDR; addr++) {
struct phy_device *phydev = mdiobus_get_phy(new_bus, addr);
- int act = 0;
- char irq_num[4];
- char *irq_str;
if (!phydev)
continue;
@@ -273,19 +270,6 @@ int stmmac_mdio_register(struct net_device *ndev)
if (priv->plat->phy_addr == -1)
priv->plat->phy_addr = addr;
- act = (priv->plat->phy_addr == addr);
- switch (phydev->irq) {
- case PHY_POLL:
- irq_str = "POLL";
- break;
- case PHY_IGNORE_INTERRUPT:
- irq_str = "IGNORE";
- break;
- default:
- sprintf(irq_num, "%d", phydev->irq);
- irq_str = irq_num;
- break;
- }
phy_attached_info(phydev);
found = 1;
}
--
2.11.0
^ permalink raw reply related
* [PATCH v2 2/2] net: phy: Don't use drv when it is NULL in phy_attached_print
From: Romain Perier @ 2017-08-21 11:45 UTC (permalink / raw)
To: Giuseppe Cavallaro, Alexandre Torgue, Andrew Lunn,
Florian Fainelli
Cc: netdev, linux-kernel, Romain Perier
In-Reply-To: <20170821114530.13706-1-romain.perier@collabora.com>
Currently, if this logging function is used prior the phy driver is
bound to the phy device (that is usually done from .ndo_open),
'phydev->drv' might be NULL, resulting in a kernel crash. That is
typically the case in the stmmac driver, info about the phy is displayed
during the registration of the MDIO bus, and then genphy driver is bound
to this phydev when .ndo_open is called.
This commit fixes the issue by using the right genphy driver, when
phydev->drv is NULL.
Fixes: fbca164776e4 ("net: stmmac: Use the right logging functi")
Signed-off-by: Romain Perier <romain.perier@collabora.com>
---
drivers/net/phy/phy_device.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 1790f7fec125..6af6dc6dfeaf 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -864,15 +864,24 @@ EXPORT_SYMBOL(phy_attached_info);
#define ATTACHED_FMT "attached PHY driver [%s] (mii_bus:phy_addr=%s, irq=%d)"
void phy_attached_print(struct phy_device *phydev, const char *fmt, ...)
{
+ struct phy_driver *drv = phydev->drv;
+
+ if (!drv) {
+ if (phydev->is_c45)
+ drv = &genphy_10g_driver;
+ else
+ drv = &genphy_driver;
+ }
+
if (!fmt) {
dev_info(&phydev->mdio.dev, ATTACHED_FMT "\n",
- phydev->drv->name, phydev_name(phydev),
+ drv->name, phydev_name(phydev),
phydev->irq);
} else {
va_list ap;
dev_info(&phydev->mdio.dev, ATTACHED_FMT,
- phydev->drv->name, phydev_name(phydev),
+ drv->name, phydev_name(phydev),
phydev->irq);
va_start(ap, fmt);
--
2.11.0
^ permalink raw reply related
* Re: [PATCH 2/2] net: phy: Don't use drv when it is NULL in phy_attached_print
From: Romain Perier @ 2017-08-21 11:46 UTC (permalink / raw)
To: Sergei Shtylyov, Giuseppe Cavallaro, Alexandre Torgue,
Andrew Lunn, Florian Fainelli
Cc: netdev, linux-kernel
In-Reply-To: <5c7d444c-427f-7a4d-8603-02bd4dc4b909@cogentembedded.com>
Hello,
Le 21/08/2017 à 11:45, Sergei Shtylyov a écrit :
> Hello!
>
> On 8/21/2017 10:52 AM, Romain Perier wrote:
>
>> Currently, if this logging function is used prior the phy driver is
>> binded to the phy device (that is usually done from .ndo_open),
>
> s/binded/bound/.
>
>> 'phydev->drv' might be NULL, resulting in a kernel crash. That is
>> typically the case in the stmmac driver, info about the phy is displayed
>> during the registration of the MDIO bus, and then genphy driver is
>> binded
>
> Likewise.
>
>> to this phydev when .ndo_open is called.
>>
>> This commit fixes the issue by using the right genphy driver, when
>> phydev->drv is NULL.
>>
>> Fixes: commit fbca164776e4 ("net: stmmac: Use the right logging functi")
>
> "Commit" not needed here.
Fixed, thanks
Romain
^ permalink raw reply
* Re: [PATCH net-next] virtio-net: make napi_tx param easier to grasp
From: Koichiro Den @ 2017-08-21 11:49 UTC (permalink / raw)
To: Willem de Bruijn; +Cc: Michael S. Tsirkin, virtualization, Network Development
In-Reply-To: <CAF=yD-JA_JPyUbDd=SR9Epvzw6-kbUcrfvwRWODwmeV+yHEMHw@mail.gmail.com>
On Sun, 2017-08-20 at 16:30 -0400, Willem de Bruijn wrote:
> On Sat, Aug 19, 2017 at 2:37 AM, Koichiro Den <den@klaipeden.com> wrote:
> > The module param napi_tx needs not to be writable for now since we do
> > not have any means of activating/deactivating it online,
>
> A virtio_net device inherits its napi tx mode from the global napi_tx flag
> on device up. It is possible to change the parameter and bring a device
> down/up to change the device mode.
>
> > @@ -1179,13 +1172,19 @@ static int virtnet_open(struct net_device *dev)
> > struct virtnet_info *vi = netdev_priv(dev);
> > int i;
> >
> > + /* Tx napi touches cachelines on the cpu handling tx interrupts.
> > Only
> > + * enable the feature if this is likely affine with the transmit
> > path.
> > + */
> > + if (!vi->affinity_hint_set)
> > + napi_tx = false;
> > +
>
> This disables napi globally if a specific device lacks affinity.
Now I see this is not appropriate since it just represents whether or not TX
napi is available, not that whether or not it is being turned on or off on a
particular device. Thank you.
To be honest I hoped to make it possible to see which mode it is currently
running on with ease, but I guess it's not nice to accomplish it with net sysfs
nor ethtool or whatever because it seems not much generic matter.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next v4] openvswitch: enable NSH support
From: Jiri Benc @ 2017-08-21 11:50 UTC (permalink / raw)
To: Jan Scheurich
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org, e@erig.me
In-Reply-To: <CFF8EF42F1132E4CBE2BF0AB6C21C58D7274A5C7-hqolJogE5njKJFWPz4pdheaU1rCVNFv4@public.gmane.org>
On Mon, 21 Aug 2017 10:10:38 +0000, Jan Scheurich wrote:
> If I understand correctly, this is a default definition that can be
> overridden by drivers so that we still cannot rely on the Ethernet
> payload always being 32-bit-aligned.
Not by drivers, by architectures. Only architectures that can
efficiently handle unaligned access (or on which the cost of handling
unaligned access is lower than the cost of unaligned DMA access) set
NET_IP_ALIGN to 0.
> Furthermore, there seem to be machine architectures that cannot
> handle misaligned 32-bit access at all (not even with a performance
> penalty).
Those leave NET_IP_ALIGN to 2.
> Or why else does OVS user space code take so great pain to model
> possible misalignment and provide/use safe access functions?
I don't know how the ovs user space deals with packet allocation. In
the kernel, the network header is aligned in a way that it allows
efficient 32bit access.
> Does Linux kernel code generally ignore this risk?
Given the fact that IPv4 addresses are 32bit, are accessed as such and
one can't say that IPv4 implementation on Linux is non-functional, the
answer is obvious :-)
Jiri
^ permalink raw reply
* Re: [PATCH 0/3] Fix y2038 issues for security/keys subsystem
From: Baolin Wang @ 2017-08-21 12:12 UTC (permalink / raw)
To: David Howells
Cc: David Miller, James Morris, Serge E. Hallyn, marc.dionne,
Dan Carpenter, Jason A. Donenfeld, Arnd Bergmann, Mark Brown,
keyrings, LKML, linux-security-module, Networking
In-Reply-To: <4455.1502267323@warthog.procyon.org.uk>
Hi David and James,
On 9 August 2017 at 16:28, David Howells <dhowells@redhat.com> wrote:
> The rxrpc patch isn't part of the security/keys subsystem. I'll push it
> to the network tree. The other two I'll push to James.
Could you apply this patch serials if there are no other comments? Thanks.
--
Baolin.wang
Best Regards
^ permalink raw reply
* Re: [PATCH net-next 1/3 v6] net: ether: Add support for multiplexing and aggregation type
From: Jamal Hadi Salim @ 2017-08-21 12:17 UTC (permalink / raw)
To: David Miller
Cc: subashab, netdev, fengguang.wu, dcbw, jiri, stephen, David.Laight,
marcel
In-Reply-To: <20170820.151207.1229905735989482121.davem@davemloft.net>
On 17-08-20 06:12 PM, David Miller wrote:
>>> +#define ETH_P_MAP 0xDA1A /* Multiplexing and Aggregation Protocol
>>> + * NOT AN OFFICIALLY REGISTERED ID ]
>>
>> You cant just arbitrarly assign yourself an ethertype. The IEEE may
>> never issue you one - and if they do, it will likely not be the one
>> you want i.e above.
>>
>> If there is a way for you to make this a config option that is not
>> hardcoded to some default value then that would be the best approach
>> to take.
>
> This may be a kind of a different situation, these ethertypes exist
> only internally in the kernel and never on the wire.
>
> It's just controlling the demux on ethernet receive.
>
> We have several IDs like this, and thus this addition is consistent
> with existing practice.
Ok, so if the IEEE issued this ID to someone there will be no conflict
then?
I checked - all the ether types listed in the header file as
"NOT AN OFFICIALLY REGISTERED ID" are not currently assigned by IEEE.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 0/6] drivers: make device_attribute const
From: Rafael J. Wysocki @ 2017-08-21 12:28 UTC (permalink / raw)
To: Bhumika Goyal
Cc: Julia Lawall, Rafael J. Wysocki, Len Brown, jbacik, Jiri Kosina,
Benjamin Tissoires, manish.chopra, rahul.verma,
Dept-GELinuxNICDev, harish.patil, cascardo, don, Darren Hart,
andy, Sebastian Reichel, ACPI Devel Maling List,
Linux Kernel Mailing List, linux-block, nbd-general, linux-input,
netdev, Platform Driver, Linux PM
In-Reply-To: <1503315792-14837-1-git-send-email-bhumirks@gmail.com>
On Mon, Aug 21, 2017 at 1:43 PM, Bhumika Goyal <bhumirks@gmail.com> wrote:
> Make these const. Done using Coccinelle.
>
> @match disable optional_qualifier@
> identifier s;
> @@
> static struct device_attribute s = {...};
>
> @ref@
> position p;
> identifier match.s;
> @@
> s@p
>
> @good1@
> identifier match.s;
> expression e1;
> position ref.p;
> @@
> device_remove_file(e1,&s@p,...)
>
> @good2@
> identifier match.s;
> expression e1;
> position ref.p;
> @@
> device_create_file(e1,&s@p,...)
>
>
> @bad depends on !good1 && !good2@
> position ref.p;
> identifier match.s;
> @@
> s@p
>
> @depends on forall !bad disable optional_qualifier@
> identifier match.s;
> @@
> static
> + const
> struct device_attribute s;
>
> Bhumika Goyal (6):
> ACPI: make device_attribute const
> nbd: make device_attribute const
> hid: make device_attribute const
> qlogic: make device_attribute const
> platform/x86: make device_attribute const
> power: supply: make device_attribute const
It would be better to send these patches separately, because they
touch code maintained by different people and I guess no one will take
the whole series.
I'll take care of the ACPI one, but the rest needs to go in via their
proper trees.
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH net-next] virtio-net: invoke zerocopy callback on xmit path if no tx napi
From: Jason Wang @ 2017-08-21 12:33 UTC (permalink / raw)
To: Koichiro Den, mst; +Cc: virtualization, netdev
In-Reply-To: <20170819063854.27010-1-den@klaipeden.com>
On 2017年08月19日 14:38, Koichiro Den wrote:
> Facing the possible unbounded delay relying on freeing on xmit path,
> we also better to invoke and clear the upper layer zerocopy callback
> beforehand to keep them from waiting for unbounded duration in vain.
> For instance, this removes the possible deadlock in the case that the
> upper layer is a zerocopy-enabled vhost-net.
> This does not apply if napi_tx is enabled since it will be called in
> reasonale time.
>
> Signed-off-by: Koichiro Den <den@klaipeden.com>
> ---
> drivers/net/virtio_net.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 4302f313d9a7..f7deaa5b7b50 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -1290,6 +1290,14 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct net_device *dev)
>
> /* Don't wait up for transmitted skbs to be freed. */
> if (!use_napi) {
> + if (skb_shinfo(skb)->tx_flags & SKBTX_DEV_ZEROCOPY) {
> + struct ubuf_info *uarg;
> + uarg = skb_shinfo(skb)->destructor_arg;
> + if (uarg->callback)
> + uarg->callback(uarg, true);
> + skb_shinfo(skb)->destructor_arg = NULL;
> + skb_shinfo(skb)->tx_flags &= ~SKBTX_DEV_ZEROCOPY;
> + }
> skb_orphan(skb);
> nf_reset(skb);
> }
Interesting, deadlock could be treated as a a radical case of the
discussion here https://patchwork.kernel.org/patch/3787671/.
git grep tells more similar skb_orphan() cases. Do we need to change
them all (or part)?
Actually, we may meet similar issues at many other places (e.g netem).
Need to consider a complete solution for this. Figuring out all places
that could delay a packet is a method.
Thanks
^ permalink raw reply
* Re: [PATCH net-next] virtio-net: invoke zerocopy callback on xmit path if no tx napi
From: Koichiro Den @ 2017-08-21 12:40 UTC (permalink / raw)
To: Willem de Bruijn; +Cc: Michael S. Tsirkin, virtualization, Network Development
In-Reply-To: <CAF=yD-LYLsQNt_5yYZ+PUwv04ZwaJUXn-YakH=tuh0TV+BG7iA@mail.gmail.com>
On Sun, 2017-08-20 at 16:49 -0400, Willem de Bruijn wrote:
> On Sat, Aug 19, 2017 at 2:38 AM, Koichiro Den <den@klaipeden.com> wrote:
> > Facing the possible unbounded delay relying on freeing on xmit path,
> > we also better to invoke and clear the upper layer zerocopy callback
> > beforehand to keep them from waiting for unbounded duration in vain.
>
> Good point.
>
> > For instance, this removes the possible deadlock in the case that the
> > upper layer is a zerocopy-enabled vhost-net.
> > This does not apply if napi_tx is enabled since it will be called in
> > reasonale time.
>
> Indeed. Btw, I am gathering data to eventually make napi the default
> mode. But that is taking some time.
I'm looking forward to it. Btw I'm just guessing somehow delayed napi disabling
seems to relieve the interrupt costs much, though it might need to be stateful
so sounds a bit offensive. That's to say, not-yet-used ones are not necessarily
going to be used in the near future, so we have to limit the delay with some
sort of counter. Just guessing as a virtio novice, so pls take it with a grain
of salt ;)
>
> >
> > Signed-off-by: Koichiro Den <den@klaipeden.com>
> > ---
> > drivers/net/virtio_net.c | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > index 4302f313d9a7..f7deaa5b7b50 100644
> > --- a/drivers/net/virtio_net.c
> > +++ b/drivers/net/virtio_net.c
> > @@ -1290,6 +1290,14 @@ static netdev_tx_t start_xmit(struct sk_buff *skb,
> > struct net_device *dev)
> >
> > /* Don't wait up for transmitted skbs to be freed. */
> > if (!use_napi) {
> > + if (skb_shinfo(skb)->tx_flags & SKBTX_DEV_ZEROCOPY) {
> > + struct ubuf_info *uarg;
> > + uarg = skb_shinfo(skb)->destructor_arg;
> > + if (uarg->callback)
> > + uarg->callback(uarg, true);
> > + skb_shinfo(skb)->destructor_arg = NULL;
> > + skb_shinfo(skb)->tx_flags &= ~SKBTX_DEV_ZEROCOPY;
> > + }
>
> Instead of open coding, this can use skb_zcopy_clear.
I didn't notice it, seems necessary and sufficient. Please let me repost.
Thank you.
>
> > skb_orphan(skb);
> > nf_reset(skb);
> > }
> > --
> > 2.9.4
> >
> >
^ permalink raw reply
* Re: [PATCH 2/2] vhost-net: revert vhost_exceeds_maxpend logic to its original
From: Jason Wang @ 2017-08-21 12:40 UTC (permalink / raw)
To: Koichiro Den, mst; +Cc: netdev, kvm, virtualization
In-Reply-To: <0cbc33d6-eb1e-cea4-4cdf-a8a88932da62@redhat.com>
On 2017年08月21日 11:06, Jason Wang wrote:
>
>
> On 2017年08月19日 14:41, Koichiro Den wrote:
>> To depend on vq.num and the usage of VHOST_MAX_PEND is not succinct
>> and in some case unexpected, so revert its logic part only.
>
> Hi:
>
> Could you explain a little bit more on the case that is was not
> sufficent?
>
> Thanks
Just have another thought.
I wonder whether or not just use ulimit(memlock) is better here. It
looks more flexible.
Thanks
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC PATCH] dt-binding: net: sfp binding documentation
From: Russell King - ARM Linux @ 2017-08-21 12:53 UTC (permalink / raw)
To: Baruch Siach
Cc: Rob Herring, Mark Rutland, Andrew Lunn, Florian Fainelli,
David S . Miller, netdev, devicetree
In-Reply-To: <d73b635069a2054d110632f1f4196cd4bc281e7f.1503224886.git.baruch@tkos.co.il>
On Sun, Aug 20, 2017 at 01:28:06PM +0300, Baruch Siach wrote:
> Add device-tree binding documentation SFP transceivers. Support for SFP
> transceivers has been recently introduced (drivers/net/phy/sfp.c).
>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> ---
>
> The SFP driver is on net-next.
>
> Not sure about the rate-select-gpio property name. The SFP+ standard
> (not supported yet) uses two signals, RS0 and RS1. RS0 is compatible
> with the SFP rate select signal, while RS1 controls the Tx rate.
SFP+ is usable with this, but the platforms I have do not wire the
rate select pins on the SFP+ sockets to GPIOs, but hard-wire them.
Note that I didn't expect the SFP code to just get merged with very
little in the way of real in-depth review of things like:
* the way the SFP code works, and its structure
* analysis of the bindings checking that they're fit for everyone's
purposes.
The implementation that I've designed is based around the boards that
I have access to and the various public SFP documentation. I think
documenting the bindings suggests that they are stable - I don't think
we're really ready to make that assertion yet - there may be things
that have been missed which will only come up when other people start
using this code.
> ---
> Documentation/devicetree/bindings/net/sff-sfp.txt | 24 +++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/sff-sfp.txt
>
> diff --git a/Documentation/devicetree/bindings/net/sff-sfp.txt b/Documentation/devicetree/bindings/net/sff-sfp.txt
> new file mode 100644
> index 000000000000..f0c27bc3925e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/sff-sfp.txt
> @@ -0,0 +1,24 @@
> +Small Form Factor (SFF) Committee Small Form-factor Pluggable (SFP)
> +Transceiver
> +
> +Required properties:
> +
> +- compatible : must be "sff,sfp"
> +
> +Optional Properties:
> +
> +- i2c-bus : phandle of an I2C bus controller for the SFP two wire serial
> + interface
The code as it currently stands pretty much requires an I2C bus to be
functional - but when I wrote the code, I left the possibility open for
an implementation (eg, network driver) to provide its own functionality
for reading the I2C EEPROM on the module. Some adapters which already
have SFP support do this.
Hence, for current implementations, this is required.
> +
> +- moddef0-gpio : phandle of the MOD-DEF0 (AKA Mod_ABS) module presence input
> + gpio signal
> +
> +- los-gpio : phandle of the Receiver Loss of Signal Indication input gpio
> + signal
> +
> +- tx-fault-gpio : phandle of the Module Transmitter Fault input gpio signal
> +
> +- tx-disable-gpio : phandle of the Transmitter Disable output gpio signal
> +
> +- rate-select-gpio : phandle of the Rx Signaling Rate Select (AKA RS0) output
> + gpio
> --
> 2.14.1
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* Re: [PATCH 0/6] drivers: make device_attribute const
From: Bhumika Goyal @ 2017-08-21 12:55 UTC (permalink / raw)
To: Julia Lawall, rjw, Len Brown, jbacik, jikos, benjamin.tissoires,
manish.chopra, rahul.verma, Dept-GELinuxNICDev, harish.patil,
cascardo, don, dvhart, Andy Shevchenko, sre, linux-acpi,
linux-kernel, linux-block, nbd-general, linux-input, netdev,
Platform Driver, linux-pm
Cc: Bhumika Goyal
In-Reply-To: <1503315792-14837-1-git-send-email-bhumirks@gmail.com>
On Mon, Aug 21, 2017 at 5:13 PM, Bhumika Goyal <bhumirks@gmail.com> wrote:
> Make these const. Done using Coccinelle.
>
> @match disable optional_qualifier@
> identifier s;
> @@
> static struct device_attribute s = {...};
>
> @ref@
> position p;
> identifier match.s;
> @@
> s@p
>
> @good1@
> identifier match.s;
> expression e1;
> position ref.p;
> @@
> device_remove_file(e1,&s@p,...)
>
> @good2@
> identifier match.s;
> expression e1;
> position ref.p;
> @@
> device_create_file(e1,&s@p,...)
>
>
> @bad depends on !good1 && !good2@
> position ref.p;
> identifier match.s;
> @@
> s@p
>
> @depends on forall !bad disable optional_qualifier@
> identifier match.s;
> @@
> static
> + const
> struct device_attribute s;
>
> Bhumika Goyal (6):
> ACPI: make device_attribute const
> nbd: make device_attribute const
> hid: make device_attribute const
> qlogic: make device_attribute const
> platform/x86: make device_attribute const
> power: supply: make device_attribute const
>
Hello all,
The patches are all independent, so please take what seems relevant.
Thanks,
Bhumika
> drivers/acpi/battery.c | 2 +-
> drivers/acpi/sbs.c | 2 +-
> drivers/block/nbd.c | 2 +-
> drivers/hid/hid-core.c | 2 +-
> drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c | 4 ++--
> drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c | 6 +++---
> drivers/platform/x86/classmate-laptop.c | 6 +++---
> drivers/platform/x86/intel-rst.c | 4 ++--
> drivers/power/supply/olpc_battery.c | 2 +-
> 9 files changed, 15 insertions(+), 15 deletions(-)
>
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH 0/6] drivers: make device_attribute const
From: Bhumika Goyal @ 2017-08-21 12:57 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Julia Lawall, Rafael J. Wysocki, Len Brown, jbacik, Jiri Kosina,
Benjamin Tissoires, manish.chopra, rahul.verma,
Dept-GELinuxNICDev, harish.patil, cascardo, don, Darren Hart,
Andy Shevchenko, Sebastian Reichel, ACPI Devel Maling List,
Linux Kernel Mailing List, linux-block, nbd-general, linux-input,
netdev, Platform Driver, Linux PM
In-Reply-To: <CAJZ5v0jo6q5mniU2HihHcOSqggZ8HFy3mtuo0vXYwuc2tLQ7=w@mail.gmail.com>
On Mon, Aug 21, 2017 at 5:58 PM, Rafael J. Wysocki <rafael@kernel.org> wrote:
> On Mon, Aug 21, 2017 at 1:43 PM, Bhumika Goyal <bhumirks@gmail.com> wrote:
>> Make these const. Done using Coccinelle.
>>
>> @match disable optional_qualifier@
>> identifier s;
>> @@
>> static struct device_attribute s = {...};
>>
>> @ref@
>> position p;
>> identifier match.s;
>> @@
>> s@p
>>
>> @good1@
>> identifier match.s;
>> expression e1;
>> position ref.p;
>> @@
>> device_remove_file(e1,&s@p,...)
>>
>> @good2@
>> identifier match.s;
>> expression e1;
>> position ref.p;
>> @@
>> device_create_file(e1,&s@p,...)
>>
>>
>> @bad depends on !good1 && !good2@
>> position ref.p;
>> identifier match.s;
>> @@
>> s@p
>>
>> @depends on forall !bad disable optional_qualifier@
>> identifier match.s;
>> @@
>> static
>> + const
>> struct device_attribute s;
>>
>> Bhumika Goyal (6):
>> ACPI: make device_attribute const
>> nbd: make device_attribute const
>> hid: make device_attribute const
>> qlogic: make device_attribute const
>> platform/x86: make device_attribute const
>> power: supply: make device_attribute const
>
> It would be better to send these patches separately, because they
> touch code maintained by different people and I guess no one will take
> the whole series.
>
> I'll take care of the ACPI one, but the rest needs to go in via their
> proper trees.
>
Thanks for the note. From now onwards, I will send it separately
depending on the maintainers. But is possible please consider it this
time.
Thanks,
Bhumika
> Thanks,
> Rafael
^ permalink raw reply
* Re: [PATCH net-next] virtio-net: invoke zerocopy callback on xmit path if no tx napi
From: Koichiro Den @ 2017-08-21 12:58 UTC (permalink / raw)
To: Jason Wang, mst; +Cc: virtualization, netdev
In-Reply-To: <5352c98a-fa48-fcf9-c062-9986a317a1b0@redhat.com>
On Mon, 2017-08-21 at 20:33 +0800, Jason Wang wrote:
>
> On 2017年08月19日 14:38, Koichiro Den wrote:
> > Facing the possible unbounded delay relying on freeing on xmit path,
> > we also better to invoke and clear the upper layer zerocopy callback
> > beforehand to keep them from waiting for unbounded duration in vain.
> > For instance, this removes the possible deadlock in the case that the
> > upper layer is a zerocopy-enabled vhost-net.
> > This does not apply if napi_tx is enabled since it will be called in
> > reasonale time.
> >
> > Signed-off-by: Koichiro Den <den@klaipeden.com>
> > ---
> > drivers/net/virtio_net.c | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > index 4302f313d9a7..f7deaa5b7b50 100644
> > --- a/drivers/net/virtio_net.c
> > +++ b/drivers/net/virtio_net.c
> > @@ -1290,6 +1290,14 @@ static netdev_tx_t start_xmit(struct sk_buff *skb,
> > struct net_device *dev)
> >
> > /* Don't wait up for transmitted skbs to be freed. */
> > if (!use_napi) {
> > + if (skb_shinfo(skb)->tx_flags & SKBTX_DEV_ZEROCOPY) {
> > + struct ubuf_info *uarg;
> > + uarg = skb_shinfo(skb)->destructor_arg;
> > + if (uarg->callback)
> > + uarg->callback(uarg, true);
> > + skb_shinfo(skb)->destructor_arg = NULL;
> > + skb_shinfo(skb)->tx_flags &= ~SKBTX_DEV_ZEROCOPY;
> > + }
> > skb_orphan(skb);
> > nf_reset(skb);
> > }
>
>
> Interesting, deadlock could be treated as a a radical case of the
> discussion here https://patchwork.kernel.org/patch/3787671/.
Thanks for letting me know this one. I am going to read it.
>
> git grep tells more similar skb_orphan() cases. Do we need to change
> them all (or part)?
Maybe, even though it seems less likely that we may meet it than the one I
described as an example, such as virtio-net sandwiched between vhost-net.
>
> Actually, we may meet similar issues at many other places (e.g netem).
> Need to consider a complete solution for this. Figuring out all places
> that could delay a packet is a method.
Okay I will do it and post the result and a suggestion if possible. Thanks.
>
> Thanks
^ permalink raw reply
* Re: [PATCH 2/2] net: phy: Don't use drv when it is NULL in phy_attached_print
From: Andrew Lunn @ 2017-08-21 13:16 UTC (permalink / raw)
To: Romain Perier
Cc: Giuseppe Cavallaro, Alexandre Torgue, Florian Fainelli, netdev,
linux-kernel
In-Reply-To: <20170821075235.28473-3-romain.perier@collabora.com>
On Mon, Aug 21, 2017 at 09:52:35AM +0200, Romain Perier wrote:
> Currently, if this logging function is used prior the phy driver is
> binded to the phy device (that is usually done from .ndo_open),
> 'phydev->drv' might be NULL, resulting in a kernel crash. That is
> typically the case in the stmmac driver, info about the phy is displayed
> during the registration of the MDIO bus, and then genphy driver is binded
> to this phydev when .ndo_open is called.
>
> This commit fixes the issue by using the right genphy driver, when
> phydev->drv is NULL.
>
> Fixes: commit fbca164776e4 ("net: stmmac: Use the right logging functi")
> Signed-off-by: Romain Perier <romain.perier@collabora.com>
> ---
> drivers/net/phy/phy_device.c | 13 +++++++++++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index 9493fb369682..b38926bc275f 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -877,15 +877,24 @@ EXPORT_SYMBOL(phy_attached_info);
> #define ATTACHED_FMT "attached PHY driver [%s] (mii_bus:phy_addr=%s, irq=%d)"
> void phy_attached_print(struct phy_device *phydev, const char *fmt, ...)
> {
> + struct phy_driver *drv = phydev->drv;
> +
> + if (!drv) {
> + if (phydev->is_c45)
> + drv = &genphy_10g_driver;
> + else
> + drv = &genphy_driver;
> + }
Hi Romain
I don't like this. You end up with the same code twice. c45 does not
imply 10g, so i would not be surprised if sometime in the future this
changes. And then we have two places we need to make the same change.
I also wonder what happens if you load the PHY driver later, but
before it is bound. Will it then use the correct driver?
> +
> if (!fmt) {
> dev_info(&phydev->mdio.dev, ATTACHED_FMT "\n",
> - phydev->drv->name, phydev_name(phydev),
> + drv->name, phydev_name(phydev),
I would prefer (phydev->drv ? phydev->drv->name, "unknown")
Andrew
^ permalink raw reply
* Re: [PATCH v2 net-next] net: ipv6: put host and anycast routes on device with address
From: David Ahern @ 2017-08-21 13:19 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: netdev, yoshfuji, David Miller
In-Reply-To: <87inhkl7sq.fsf@stressinduktion.org>
On 8/18/17 6:28 PM, Hannes Frederic Sowa wrote:
> David Ahern <dsahern@gmail.com> writes:
>
>> On 8/18/17 6:05 PM, David Ahern wrote:
>>> On 8/18/17 5:15 PM, Hannes Frederic Sowa wrote:
>>>> Hello David,
>>>>
>>>> David Ahern <dsahern@gmail.com> writes:
>>>>
>>>>> @@ -2688,15 +2716,9 @@ struct rt6_info *addrconf_dst_alloc(struct inet6_dev *idev,
>>>>> {
>>>>> u32 tb_id;
>>>>> struct net *net = dev_net(idev->dev);
>>>>> - struct net_device *dev = net->loopback_dev;
>>>>> + struct net_device *dev = idev->dev;
>>>>> struct rt6_info *rt;
>>>>>
>>>>> - /* use L3 Master device as loopback for host routes if device
>>>>> - * is enslaved and address is not link local or multicast
>>>>> - */
>>>>> - if (!rt6_need_strict(addr))
>>>>> - dev = l3mdev_master_dev_rcu(idev->dev) ? : dev;
>>>>> -
>>>>> rt = ip6_dst_alloc(net, dev, DST_NOCOUNT);
>>>>> if (!rt)
>>>>> return ERR_PTR(-ENOMEM);
>>>>
>>>> I am afraid this change might break Java:
>>>>
>>>> <http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/65464a307408/src/java.base/unix/native/libnet/net_util_md.c#l574>
>>>>
>>>> I am all in for this change, but maybe it might be necessary to mask
>>>> RTF_LOCAL routes with "lo" somehow.
>>>
>>> That's asinine. The if_inet6 processing is just getting the 'lo'
>>> interface index. Why scan the file looking for that? The ipv6_route
>>> processing is assembling routes against the loopback device regardless
>>> of what the route is. Do you know why - what the route list is used for?
>>
>>
>> If I read it correctly, seems to be a 2.4 workaround:
>> - only user of the route list is needsLoopbackRoute()
>> - only caller of needsLoopbackRoute is here:
>>
>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/65464a307408/src/java.base/unix/native/libnet/net_util_md.c#l828
>
> I agree that it looks like dead code now. But I know for sure that this
> code has been excercised at least at some point in time and caused
> problems for JVMs on Linux with IPv6.
>
> On the top of this file I found this comment:
>
> -- >8 --
> /* following code creates a list of addresses from the kernel
> * routing table that are routed via the loopback address.
> * We check all destination addresses against this table
> * and override the scope_id field to use the relevant value for "lo"
> * in order to work-around the Linux bug that prevents packets destined
> * for certain local addresses from being sent via a physical interface.
> */
> -- 8< --
>
> I don't know if it makes sense to dive down into java history (and I
> also found e.g. net-snmp scanning /proc/net/ipv6_route). The same
> problem might be visible via RTM_GETROUTE dumps if applications
> implement their own source address selection maybe. :/
Dave: The java code appears to be dead code from 2.4 time frame. no
longer relevant for this patch.
Hannes: I believe the net-snmp use case is populating the MIB. MIB
entries, like the proc files and rtnetlink responses, will have the
change in that host routes show the device with the address rather than
loopback. But, looking at the send code I don't see this change having
an impact.
^ permalink raw reply
* Re: [PATCH v3 3/4] net: stmmac: register parent MDIO node for sun8i-h3-emac
From: Andrew Lunn @ 2017-08-21 13:20 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Corentin Labbe, Rob Herring, Mark Rutland, Russell King,
Maxime Ripard, Giuseppe Cavallaro, Alexandre Torgue, devicetree,
linux-arm-kernel, linux-kernel, netdev
In-Reply-To: <CAGb2v67hQXSoCKP7qW+KRUYX+0djQ1Z23cQ67Lyg6G7ozGyfGQ@mail.gmail.com>
> With our hardware, and likely Rockchip's as well, the muxed connections
> include the MDIO and MII connections
Ah, i did not realise the MII was muxed as well. Then i agree, an MDIO
mux is wrong.
However, please try to make the binding not look like an mdio mux. We
don't want people misunderstanding the binding and thinking it is an
mdio mux.
Andrew
^ permalink raw reply
* Re: [PATCH 5/6] platform/x86: make device_attribute const
From: Thadeu Lima de Souza Cascardo @ 2017-08-21 13:22 UTC (permalink / raw)
To: Bhumika Goyal
Cc: julia.lawall, rjw, lenb, jbacik, jikos, benjamin.tissoires,
manish.chopra, rahul.verma, Dept-GELinuxNICDev, harish.patil, don,
dvhart, andy, sre, linux-acpi, linux-kernel, linux-block,
nbd-general, linux-input, netdev, platform-driver-x86, linux-pm
In-Reply-To: <1503315792-14837-6-git-send-email-bhumirks@gmail.com>
For classmate-laptop.c
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
^ permalink raw reply
* [iproute PATCH v3 7/7] lib/ll_map: Choose size of new cache items at run-time
From: Phil Sutter @ 2017-08-21 13:23 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20170821132341.23118-1-phil@nwl.cc>
Instead of having a fixed buffer of 16 bytes for the interface name,
tailor size of new ll_cache entry using the interface name's actual
length. This also makes sure the following call to strcpy() is safe.
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
lib/ll_map.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/ll_map.c b/lib/ll_map.c
index 4e4556c9ac80b..70684b02042b6 100644
--- a/lib/ll_map.c
+++ b/lib/ll_map.c
@@ -30,7 +30,7 @@ struct ll_cache {
unsigned flags;
unsigned index;
unsigned short type;
- char name[IFNAMSIZ];
+ char name[];
};
#define IDXMAP_SIZE 1024
@@ -120,7 +120,7 @@ int ll_remember_index(const struct sockaddr_nl *who,
return 0;
}
- im = malloc(sizeof(*im));
+ im = malloc(sizeof(*im) + strlen(ifname) + 1);
if (im == NULL)
return 0;
im->index = ifi->ifi_index;
--
2.13.1
^ permalink raw reply related
* [iproute PATCH v3 0/7] Covscan: Fixes for string termination
From: Phil Sutter @ 2017-08-21 13:23 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
This series collects patches from v1 dealing with code potentially
leaving string buffers unterminated. This does not include situations
where it happens for parsed interface names since an overall solution
was attempted for that and it's state is still unclear due to lack of
feedback from upstream.
Changes since v2:
- Rebased onto current upstream master branch.
- Replaced patches 1, 4 and 7 by more appropriate ones given feedback
from v2 review.
Phil Sutter (7):
ipntable: Avoid memory allocation for filter.name
xfrm_state: Make sure alg_name is NULL-terminated
lib/fs: Fix format string in find_fs_mount()
lib/inet_proto: Review inet_proto_{a2n,n2a}()
lnstat_util: Simplify alloc_and_open() a bit
tc/m_xt: Fix for potential string buffer overflows
lib/ll_map: Choose size of new cache items at run-time
ip/ipntable.c | 6 +++---
ip/xfrm_state.c | 3 ++-
lib/fs.c | 2 +-
lib/inet_proto.c | 24 +++++++++++++-----------
lib/ll_map.c | 4 ++--
misc/lnstat_util.c | 7 ++-----
tc/m_xt.c | 7 ++++---
7 files changed, 27 insertions(+), 26 deletions(-)
--
2.13.1
^ permalink raw reply
* [iproute PATCH v3 6/7] tc/m_xt: Fix for potential string buffer overflows
From: Phil Sutter @ 2017-08-21 13:23 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20170821132341.23118-1-phil@nwl.cc>
- Use strncpy() when writing to target->t->u.user.name and make sure the
final byte remains untouched (xtables_calloc() set it to zero).
- 'tname' length sanitization was completely wrong: If it's length
exceeded the 16 bytes available in 'k', passing a length value of 16
to strncpy() would overwrite the previously NULL'ed 'k[15]'. Also, the
sanitization has to happen if 'tname' is exactly 16 bytes long as
well.
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
tc/m_xt.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/tc/m_xt.c b/tc/m_xt.c
index ad52d239caf61..9218b14594403 100644
--- a/tc/m_xt.c
+++ b/tc/m_xt.c
@@ -95,7 +95,8 @@ build_st(struct xtables_target *target, struct xt_entry_target *t)
if (t == NULL) {
target->t = xtables_calloc(1, size);
target->t->u.target_size = size;
- strcpy(target->t->u.user.name, target->name);
+ strncpy(target->t->u.user.name, target->name,
+ sizeof(target->t->u.user.name) - 1);
target->t->u.user.revision = target->revision;
if (target->init != NULL)
@@ -277,8 +278,8 @@ static int parse_ipt(struct action_util *a, int *argc_p,
}
fprintf(stdout, " index %d\n", index);
- if (strlen(tname) > 16) {
- size = 16;
+ if (strlen(tname) >= 16) {
+ size = 15;
k[15] = 0;
} else {
size = 1 + strlen(tname);
--
2.13.1
^ permalink raw reply related
* [iproute PATCH v3 2/7] xfrm_state: Make sure alg_name is NULL-terminated
From: Phil Sutter @ 2017-08-21 13:23 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20170821132341.23118-1-phil@nwl.cc>
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
ip/xfrm_state.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/ip/xfrm_state.c b/ip/xfrm_state.c
index e11c93bf1c3b5..7c0389038986e 100644
--- a/ip/xfrm_state.c
+++ b/ip/xfrm_state.c
@@ -125,7 +125,8 @@ static int xfrm_algo_parse(struct xfrm_algo *alg, enum xfrm_attr_type_t type,
fprintf(stderr, "warning: ALGO-NAME/ALGO-KEYMAT values will be sent to the kernel promiscuously! (verifying them isn't implemented yet)\n");
#endif
- strncpy(alg->alg_name, name, sizeof(alg->alg_name));
+ strncpy(alg->alg_name, name, sizeof(alg->alg_name) - 1);
+ alg->alg_name[sizeof(alg->alg_name) - 1] = '\0';
if (slen > 2 && strncmp(key, "0x", 2) == 0) {
/* split two chars "0x" from the top */
--
2.13.1
^ permalink raw reply related
* [iproute PATCH v3 5/7] lnstat_util: Simplify alloc_and_open() a bit
From: Phil Sutter @ 2017-08-21 13:23 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20170821132341.23118-1-phil@nwl.cc>
Relying upon callers and using unsafe strcpy() is probably not the best
idea. Aside from that, using snprintf() allows to format the string for
lf->path in one go.
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
misc/lnstat_util.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/misc/lnstat_util.c b/misc/lnstat_util.c
index cc54598fe1bef..ec19238c24b94 100644
--- a/misc/lnstat_util.c
+++ b/misc/lnstat_util.c
@@ -180,11 +180,8 @@ static struct lnstat_file *alloc_and_open(const char *path, const char *file)
}
/* initialize */
- /* de->d_name is guaranteed to be <= NAME_MAX */
- strcpy(lf->basename, file);
- strcpy(lf->path, path);
- strcat(lf->path, "/");
- strcat(lf->path, lf->basename);
+ snprintf(lf->basename, sizeof(lf->basename), "%s", file);
+ snprintf(lf->path, sizeof(lf->path), "%s/%s", path, file);
/* initialize to default */
lf->interval.tv_sec = 1;
--
2.13.1
^ permalink raw reply related
* [iproute PATCH v3 1/7] ipntable: Avoid memory allocation for filter.name
From: Phil Sutter @ 2017-08-21 13:23 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20170821132341.23118-1-phil@nwl.cc>
The original issue was that filter.name might end up unterminated if
user provided string was too long. But in fact it is not necessary to
copy the commandline parameter at all: just make filter.name point to it
instead.
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
ip/ipntable.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/ip/ipntable.c b/ip/ipntable.c
index 879626ee4f491..e0bd9b6ebd155 100644
--- a/ip/ipntable.c
+++ b/ip/ipntable.c
@@ -37,7 +37,7 @@ static struct
int family;
int index;
#define NONE_DEV (-1)
- char name[1024];
+ const char *name;
} filter;
static void usage(void) __attribute__((noreturn));
@@ -369,7 +369,7 @@ static int print_ntable(const struct sockaddr_nl *who, struct nlmsghdr *n, void
if (tb[NDTA_NAME]) {
const char *name = rta_getattr_str(tb[NDTA_NAME]);
- if (strlen(filter.name) > 0 && strcmp(filter.name, name))
+ if (filter.name && strcmp(filter.name, name))
return 0;
}
if (tb[NDTA_PARMS]) {
@@ -633,7 +633,7 @@ static int ipntable_show(int argc, char **argv)
} else if (strcmp(*argv, "name") == 0) {
NEXT_ARG();
- strncpy(filter.name, *argv, sizeof(filter.name));
+ filter.name = *argv;
} else
invarg("unknown", *argv);
--
2.13.1
^ 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