* Re: [virtio-dev] Re: [RFC PATCH 1/3] qemu: virtio-bypass should explicitly bind to a passthrough device
From: Paolo Bonzini @ 2018-04-05 15:31 UTC (permalink / raw)
To: Siwei Liu, Michael S. Tsirkin
Cc: Si-Wei Liu, Jiri Pirko, Stephen Hemminger, Alexander Duyck,
David Miller, Brandeburg, Jesse, Jakub Kicinski, Jason Wang,
Samudrala, Sridhar, Netdev, virtualization, virtio-dev
In-Reply-To: <CADGSJ23jr7xrq8h9rFHLtXkbpsB+AK8wcUzOQnpeftbhiYdOvA@mail.gmail.com>
On 04/04/2018 10:02, Siwei Liu wrote:
>> pci_bus_num is almost always a bug if not done within
>> a context of a PCI host, bridge, etc.
>>
>> In particular this will not DTRT if run before guest assigns bus
>> numbers.
>>
> I was seeking means to reserve a specific pci bus slot from drivers,
> and update the driver when guest assigns the bus number but it seems
> there's no low-hanging fruits. Because of that reason the bus_num is
> only obtained until it's really needed (during get_config) and I
> assume at that point the pci bus assignment is already done. I know
> the current one is not perfect, but we need that information (PCI
> bus:slot.func number) to name the guest device correctly.
Can you use the -device "id", and look it up as
devices = container_get(qdev_get_machine(), "/peripheral");
return object_resolve_path_component(devices, id);
?
Thanks,
Paolo
^ permalink raw reply
* RE: [PATCH v3 2/4] bus: fsl-mc: add restool userspace support
From: Ruxandra Ioana Ciocoi Radulescu @ 2018-04-05 15:35 UTC (permalink / raw)
To: Andrew Lunn, Laurentiu Tudor
Cc: Stuart Yoder, Arnd Bergmann, Ioana Ciornei, gregkh,
Linux Kernel Mailing List, Razvan Stefanescu, Roy Pledge,
Networking
In-Reply-To: <20180405152348.GC32663@lunn.ch>
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Thursday, April 5, 2018 6:24 PM
> To: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> Cc: Stuart Yoder <stuyoder@gmail.com>; Arnd Bergmann <arnd@arndb.de>;
> Ioana Ciornei <ioana.ciornei@nxp.com>; gregkh
> <gregkh@linuxfoundation.org>; Linux Kernel Mailing List <linux-
> kernel@vger.kernel.org>; Ruxandra Ioana Ciocoi Radulescu
> <ruxandra.radulescu@nxp.com>; Razvan Stefanescu
> <razvan.stefanescu@nxp.com>; Roy Pledge <roy.pledge@nxp.com>;
> Networking <netdev@vger.kernel.org>
> Subject: Re: [PATCH v3 2/4] bus: fsl-mc: add restool userspace support
>
> On Thu, Apr 05, 2018 at 02:43:29PM +0000, Laurentiu Tudor wrote:
> > Hi Andrew,
> >
> > On 04/05/2018 03:48 PM, Andrew Lunn wrote:
> > >>> Hi Laurentiu
> > >>>
> > >>> So i can use switchdev without it? I can modprobe the switchdev
> > >>> driver, all the physical interfaces will appear, and i can use ip addr
> > >>> add etc. I do not need to use a user space tool at all in order to use
> > >>> the network functionality?
> > >>
> > >> Absolutely!
> > >
> > > Great.
> > >
> > > Then the easiest way forwards is to simply drop the IOCTL code for the
> > > moment. Get the basic support for the hardware into the kernel
> > > first. Then come back later to look at dynamic behaviour which needs
> > > some form of configuration.
> >
> > Hmm, not sure I understand. We already have a fully functional ethernet
> > driver [1] and a switch driver [2] ...
>
> In staging, the tree of crap. You want to get it out of there and into
> the main tree. But that effort is being side lined by the discussion
> around this IOCTL call. The best way forward is to to accept Greg is
> not going to take this patchset at the moment, and move on. As you
> said, it is not needed for the Ethernet and switchdev driver.
>
> What needs to happen before the Ethernet driver can be reviewed for
> moving out of staging?
Hi Andrew,
We're waiting for the DPIO driver (which we depend on) to be moved
out of staging first, it's currently under review:
https://lkml.org/lkml/2018/3/27/1086
Ioana
^ permalink raw reply
* [PATCH] qtnfmac: pearl: pcie: fix memory leak in qtnf_fw_work_handler
From: Gustavo A. R. Silva @ 2018-04-05 15:49 UTC (permalink / raw)
To: Igor Mitsyanko, Avinash Patil, Sergey Matyukevich, Kalle Valo
Cc: linux-wireless, netdev, linux-kernel, Gustavo A. R. Silva
In case memory resources for fw were succesfully allocated, release
them before jumping to fw_load_fail.
Addresses-Coverity-ID: 1466092 ("Resource leak")
Fixes: c3b2f7ca4186 ("qtnfmac: implement asynchronous firmware loading")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
index f117904..6c1e139 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
@@ -1185,6 +1185,10 @@ static void qtnf_fw_work_handler(struct work_struct *work)
if (qtnf_poll_state(&priv->bda->bda_ep_state, QTN_EP_FW_LOADRDY,
QTN_FW_DL_TIMEOUT_MS)) {
pr_err("card is not ready\n");
+
+ if (!flashboot)
+ release_firmware(fw);
+
goto fw_load_fail;
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 3/9] kbuild: Do not pass arguments to link-vmlinux.sh
From: Masahiro Yamada @ 2018-04-05 15:50 UTC (permalink / raw)
To: Jiri Olsa
Cc: Alexei Starovoitov, Daniel Borkmann, lkml, netdev,
Linux Kbuild mailing list, Quentin Monnet, Eugene Syromiatnikov,
Jiri Benc, Stanislav Kozina, Jerome Marchand,
Arnaldo Carvalho de Melo, Michal Marek, Jiri Kosina
In-Reply-To: <20180405151645.19130-4-jolsa@kernel.org>
2018-04-06 0:16 GMT+09:00 Jiri Olsa <jolsa@kernel.org>:
> There's no need to pass LD* arguments to link-vmlinux.sh,
> because they are passed as variables. The only argument
> the link-vmlinux.sh supports is the 'clean' argument.
>
> Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> ---
Wrong.
$(LD) $(LDFLAGS) $(LDFLAGS_vmlinux)
exist here so that any change in them
invokes scripts/linkk-vmlinux.sh
> Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index d3300e46f925..a65a3919c6ad 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1027,7 +1027,7 @@ ARCH_POSTLINK := $(wildcard $(srctree)/arch/$(SRCARCH)/Makefile.postlink)
>
> # Final link of vmlinux with optional arch pass after final link
> cmd_link-vmlinux = \
> - $(CONFIG_SHELL) $< $(LD) $(LDFLAGS) $(LDFLAGS_vmlinux) ; \
> + $(CONFIG_SHELL) $< ; \
> $(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)
>
> vmlinux: scripts/link-vmlinux.sh vmlinux_prereq $(vmlinux-deps) FORCE
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH v2 bpf-next 0/3] bpf/verifier: subprog/func_call simplifications
From: Jiong Wang @ 2018-04-05 15:50 UTC (permalink / raw)
To: Alexei Starovoitov, Edward Cree; +Cc: Daniel Borkmann, netdev
In-Reply-To: <20180403010802.jkqffxw4m75oioj7@ast-mbp>
On 03/04/2018 02:08, Alexei Starovoitov wrote:
> Combining subprog pass with do_check is going into opposite direction
> of this long term work. Divide and conquer. Combining more things into
> do_check is the opposite of this programming principle.
Agree. And for the redundant insn traversal issue in check_subprogs that
Edward trying to fix, I am thinking we could do it by utilizing the
existing DFS traversal in check_cfg.
The current DFS probably could be improved into an generic instruction
information collection pass.
This won't make the existing DFS complexer as it only does information
collection as a side job during traversal. These collected information
then could be used to build any other information to be consumed later,
for example subprog, basic blocks etc.
For the redundant insn traversal issue during subprog detection, the
Like how we mark STATE_LIST_MARK in DFS, we could just call add_subprog
for BPF_PSEUDO_CALL insn during DFS.
i.e we change the code logic of check_cfg into:
check_cfg
{
* DFS traversal:
- detect back-edge.
- collect STATE_LIST_MARK.
- collect subprog destination.
* check all insns are reachable.
* check_subprogs (insn traversal removed).
}
I prototyped a patch for above change, the change looks to me is easier to
review. There are 8 regressions on selftests however after this change due
to check_subprogs moved after some checks in DFS that some errors detected
before the expected errors, need to be cleaned up.
Does this direction sound good?
And if we want to build basic-block later, we could just call a new add_bb
(similar as add_subprog) for jump targets etc. (some of those places are
actually STATE_LIST_MARK_JMPTARGET if we separate STATE_LIST_MARK as
STATE_LIST_MARK_JMPTARGET and STATE_LIST_MARK_HEURISTIC).
Regards,
Jiong
^ permalink raw reply
* Re: [RFC] ethtool: Support for driver private ioctl's
From: Florian Fainelli @ 2018-04-05 15:50 UTC (permalink / raw)
To: Jose Abreu, David Miller, Jakub Jelinek, Jeff Garzik, Tim Hockin,
Eli Kupermann, Chris Leech, Scott Feldman, Ben Hutchings
Cc: netdev, Joao Pinto
In-Reply-To: <cbd05f37-509b-118b-e681-0ccd0ebebd73@synopsys.com>
On 04/05/2018 03:47 AM, Jose Abreu wrote:
> Hi All,
>
> I would like to know your opinion regarding adding support for
> driver private ioctl's in ethtool.
>
> Background: Synopsys Ethernet IP's have a certain number of
> features which can be reconfigured at runtime. Giving you two
> examples: One of the most recent one is the safety features,
> which can be enabled/disabled and forced at runtime. Another one
> is a Flexible RX Parser which can route specific packets to
> specific RX DMA channels. Given that these are features specific
> to our IP's it would not be useful to add an uniform API for this
> because the users would only be one or two drivers ...
Parsing of packets and directing the matched packets to specific
queues/channels can be done through ethtool rxnfc API, tc/cls_flower as
well, so you should really check whether those APIs don't already allow
you to do what you want.
ethtool already supports a concept of private flags, not ioctl() though
which allows you to toggle boolean values for instance (or technically
up to how many bits a "flag" is used to represent) is that enough or do
you need to turn on/off the feature as well as pass configuration
parameters?
>
> This new feature would change the help usage for ethtool so that
> each driver private option would be shown, and then each driver
> specific file would have a structure with all the available
> options. Finally, each driver would have to handle the private
> IOCTL's.
>
> We already have this working locally and now I would like to know
> your opinion about upstreaming this ... Do you think this can be
> useful for anyone else? Or should we change direction to use, for
> example, debugfs/configfs?
In general, even if there is only one driver implementing a particular
feature, the approach chosen is to come up with an API that is as
generic as possible. Even if there is a single user of that API in tree,
having something that was thought to be generic is better than allowing
uncontrolled private ioctl() implementations.
--
Florian
^ permalink raw reply
* Re: marvell switch
From: Ran Shalit @ 2018-04-05 15:59 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
In-Reply-To: <20180405122223.GC12178@lunn.ch>
On Thu, Apr 5, 2018 at 3:22 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> On Thu, Apr 05, 2018 at 05:47:24AM +0300, Ran Shalit wrote:
>> Hello,
>>
>> I am trying to use marvell switch in linux,
>> Is it that the kernel drivers from marvell switch are used just to
>> enable all ports, or do they also provide APIs to userspace to enable
>> specific ports only.
>> I have not find examples or wiki for marvell switch, so I am not too
>> sure as what are the drivers meant for.
>
> Hi Ran
>
> The Marvell driver makes each port act like a normal Linux network
> interface. So if you want to enable a port, do
>
> ip link set lan0 up
>
> Want to add an ip address to a port
>
> ip addr add 10.42.42.42/24 dev lan0
>
> Want to bridge two ports
>
> ip link add name br0 type bridge
> ip link set dev br0 up
> ip link set dev lan0 master br0
> ip link set dev lan1 master br0
>
> Just treat them as normal interfaces.
>
Is there a wiki which explains switch configuration ?
What does it mean that they are treated as normal interfaces ?
Is it possible to open socket and send/recieve on switch ports (lan0
for example) ?
My understanding is that these ports are not treated the same as eth0
interface for example.
Thanks for the assistance,
ranran
> Andrew
^ permalink raw reply
* Re: [PATCH 1/2] net: phy: Helper function for reading strapped configuration values
From: Florian Fainelli @ 2018-04-05 16:00 UTC (permalink / raw)
To: esben.haabendal, Andrew Lunn, open list:ETHERNET PHY LIBRARY,
open list
Cc: Esben Haabendal, Rasmus Villemoes
In-Reply-To: <20180405114424.8519-1-esben.haabendal@gmail.com>
On 04/05/2018 04:44 AM, esben.haabendal@gmail.com wrote:
> From: Esben Haabendal <eha@deif.com>
>
> Add a function for use in PHY driver probe functions, reading current
> autoneg, speed and duplex configuration from BMCR register.
>
> Useful for PHY that supports hardware strapped configuration, enabling
> Linux to respect that configuration (i.e. strapped non-autoneg
> configuration).
>
> Signed-off-by: Esben Haabendal <eha@deif.com>
> Cc: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
> ---
> drivers/net/phy/phy_device.c | 41 +++++++++++++++++++++++++++++++++++++++++
> include/linux/phy.h | 1 +
> 2 files changed, 42 insertions(+)
>
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index 74664a6c0cdc..cc52ff2a2344 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -1673,6 +1673,47 @@ int genphy_config_init(struct phy_device *phydev)
> }
> EXPORT_SYMBOL(genphy_config_init);
>
> +/**
> + * genphy_read_config - read configuration from PHY
> + * @phydev: target phy_device struct
> + *
> + * Description: Reads MII_BMCR and sets phydev autoneg, speed and duplex
> + * accordingly. For use in driver probe functions, to respect strapped
> + * configuration settings.
> + */
> +int genphy_read_config(struct phy_device *phydev)
This duplicates what already exists, in part at least within
genphy_read_status() can you find a way to use that?
I really wonder how this is going to work though because an user can
decide to force the PHY to have auto-negotiation disabled just like a
MAC could actually attempt to do that while connecting to the PHY...
more comments in patch 2.
--
Florian
^ permalink raw reply
* Re: [PATCH 2/2] net: phy: dp83640: Read strapped configuration settings
From: Florian Fainelli @ 2018-04-05 16:02 UTC (permalink / raw)
To: esben.haabendal, Richard Cochran, Andrew Lunn,
open list:PTP HARDWARE CLOCK SUPPORT, open list
Cc: Esben Haabendal, Rasmus Villemoes
In-Reply-To: <20180405114424.8519-2-esben.haabendal@gmail.com>
On 04/05/2018 04:44 AM, esben.haabendal@gmail.com wrote:
> From: Esben Haabendal <eha@deif.com>
>
> Read configration settings, to allow automatic forced speed/duplex setup
> by hardware strapping.
OK but why? What problem is this solving for you? In general, we do not
really want to preserve too much of what the PHY has been previously
configured with, provided that the PHY driver can re-instate these
configuration values.
I just wonder how this can be robust when you connect this PHY with
auto-negotiation disabled to a peer that expects a set of link
parameters not covered by the default advertisement values? This really
looks like a recipe for disaster when you could just disable
auto-negotiation with ethtool.
>
> Signed-off-by: Esben Haabendal <eha@deif.com>
> Cc: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
> ---
> drivers/net/phy/dp83640.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/net/phy/dp83640.c b/drivers/net/phy/dp83640.c
> index 654f42d00092..01e21b4998ad 100644
> --- a/drivers/net/phy/dp83640.c
> +++ b/drivers/net/phy/dp83640.c
> @@ -1134,6 +1134,10 @@ static int dp83640_probe(struct phy_device *phydev)
> if (!dp83640)
> goto no_memory;
>
> + err = genphy_read_config(phydev);
> + if (err)
> + goto no_config;
> +
> dp83640->phydev = phydev;
> INIT_DELAYED_WORK(&dp83640->ts_work, rx_timestamp_work);
>
> @@ -1166,6 +1170,7 @@ static int dp83640_probe(struct phy_device *phydev)
>
> no_register:
> clock->chosen = NULL;
> +no_config:
> kfree(dp83640);
> no_memory:
> dp83640_clock_put(clock);
>
--
Florian
^ permalink raw reply
* Re: [PATCH] net: thunderx: rework mac addresses list to u64 array
From: Vadim Lomovtsev @ 2018-04-05 16:07 UTC (permalink / raw)
To: Christoph Hellwig
Cc: sgoutham, sunil.kovvuri, rric, linux-arm-kernel, netdev,
linux-kernel, davem, dnelson, gustavo, Vadim Lomovtsev
In-Reply-To: <20180405150748.GA5716@infradead.org>
Hi Christoph,
Thank you for your feedback and time.
On Thu, Apr 05, 2018 at 08:07:48AM -0700, Christoph Hellwig wrote:
> > struct xcast_addr_list {
> > - struct list_head list;
> > int count;
> > + u64 mc[0];
>
> Please use the standard C99 syntax here:
>
> u64 mc[];
Ok, will update.
>
> > + mc_list = kmalloc(sizeof(*mc_list) +
> > + sizeof(u64) * netdev_mc_count(netdev),
> > + GFP_ATOMIC);
>
> kmalloc_array(), please.
In this case it would require two memory allocation calls to kmalloc() for
xcast_addr_list struct and to kmalloc_array() for 'mc' addresses, becasue of
different data types and so two null-ptr checks .. this is what I'd like get rid off.
My idea of this was to keep number of array elements and themselves within the
same memory block/page to reduce number of memory allocation requests, number
of allocated pages/blocks and avoid possible memory fragmentation (however, I believe
the latter is already handled at the mm layer).
WBR,
Vadim
^ permalink raw reply
* Re: marvell switch
From: Andrew Lunn @ 2018-04-05 16:09 UTC (permalink / raw)
To: Ran Shalit; +Cc: netdev
In-Reply-To: <CAJ2oMhKpwfQ3-=syCL1Uy+W0R1CFLW+dDOQpFGw7_bLzdkjfVQ@mail.gmail.com>
> Is there a wiki which explains switch configuration ?
Nope. The whole idea is that they behave like normal linux
interfaces. So there is no need to document them. You already know how
to use them.
> Is it possible to open socket and send/recieve on switch ports (lan0
> for example) ?
Sure. It is as normal interface. Give is an IP address and then do
TCP/IP as usual.
Andrew
^ permalink raw reply
* Re: [PATCH v3 2/4] bus: fsl-mc: add restool userspace support
From: gregkh @ 2018-04-05 16:12 UTC (permalink / raw)
To: Ruxandra Ioana Ciocoi Radulescu
Cc: Andrew Lunn, Laurentiu Tudor, Stuart Yoder, Arnd Bergmann,
Ioana Ciornei, Linux Kernel Mailing List, Razvan Stefanescu,
Roy Pledge, Networking
In-Reply-To: <HE1PR0402MB2700E32234735AC12C18BB8F94BB0@HE1PR0402MB2700.eurprd04.prod.outlook.com>
On Thu, Apr 05, 2018 at 03:35:30PM +0000, Ruxandra Ioana Ciocoi Radulescu wrote:
> > -----Original Message-----
> > From: Andrew Lunn [mailto:andrew@lunn.ch]
> > Sent: Thursday, April 5, 2018 6:24 PM
> > To: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> > Cc: Stuart Yoder <stuyoder@gmail.com>; Arnd Bergmann <arnd@arndb.de>;
> > Ioana Ciornei <ioana.ciornei@nxp.com>; gregkh
> > <gregkh@linuxfoundation.org>; Linux Kernel Mailing List <linux-
> > kernel@vger.kernel.org>; Ruxandra Ioana Ciocoi Radulescu
> > <ruxandra.radulescu@nxp.com>; Razvan Stefanescu
> > <razvan.stefanescu@nxp.com>; Roy Pledge <roy.pledge@nxp.com>;
> > Networking <netdev@vger.kernel.org>
> > Subject: Re: [PATCH v3 2/4] bus: fsl-mc: add restool userspace support
> >
> > On Thu, Apr 05, 2018 at 02:43:29PM +0000, Laurentiu Tudor wrote:
> > > Hi Andrew,
> > >
> > > On 04/05/2018 03:48 PM, Andrew Lunn wrote:
> > > >>> Hi Laurentiu
> > > >>>
> > > >>> So i can use switchdev without it? I can modprobe the switchdev
> > > >>> driver, all the physical interfaces will appear, and i can use ip addr
> > > >>> add etc. I do not need to use a user space tool at all in order to use
> > > >>> the network functionality?
> > > >>
> > > >> Absolutely!
> > > >
> > > > Great.
> > > >
> > > > Then the easiest way forwards is to simply drop the IOCTL code for the
> > > > moment. Get the basic support for the hardware into the kernel
> > > > first. Then come back later to look at dynamic behaviour which needs
> > > > some form of configuration.
> > >
> > > Hmm, not sure I understand. We already have a fully functional ethernet
> > > driver [1] and a switch driver [2] ...
> >
> > In staging, the tree of crap. You want to get it out of there and into
> > the main tree. But that effort is being side lined by the discussion
> > around this IOCTL call. The best way forward is to to accept Greg is
> > not going to take this patchset at the moment, and move on. As you
> > said, it is not needed for the Ethernet and switchdev driver.
> >
> > What needs to happen before the Ethernet driver can be reviewed for
> > moving out of staging?
>
> Hi Andrew,
>
> We're waiting for the DPIO driver (which we depend on) to be moved
> out of staging first, it's currently under review:
> https://lkml.org/lkml/2018/3/27/1086
That's stalled on my side right now as the merge window is open and I
can't do any new stuff until after 4.17-rc1 is out. So everyone please
be patient a bit...
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] net: thunderx: rework mac addresses list to u64 array
From: Christoph Hellwig @ 2018-04-05 16:15 UTC (permalink / raw)
To: Vadim Lomovtsev
Cc: Christoph Hellwig, sgoutham, sunil.kovvuri, rric,
linux-arm-kernel, netdev, linux-kernel, davem, dnelson, gustavo,
Vadim Lomovtsev
In-Reply-To: <20180405160749.GB12703@localhost.localdomain>
On Thu, Apr 05, 2018 at 09:07:49AM -0700, Vadim Lomovtsev wrote:
> >
> > > + mc_list = kmalloc(sizeof(*mc_list) +
> > > + sizeof(u64) * netdev_mc_count(netdev),
> > > + GFP_ATOMIC);
> >
> > kmalloc_array(), please.
>
> In this case it would require two memory allocation calls to kmalloc() for
> xcast_addr_list struct and to kmalloc_array() for 'mc' addresses, becasue of
> different data types and so two null-ptr checks .. this is what I'd like get rid off.
>
> My idea of this was to keep number of array elements and themselves within the
> same memory block/page to reduce number of memory allocation requests, number
> of allocated pages/blocks and avoid possible memory fragmentation (however, I believe
> the latter is already handled at the mm layer).
Indeed, lets keep it as-is.
^ permalink raw reply
* [PATCH] ieee802154: mcr20a: Fix memory leak in mcr20a_probe
From: Gustavo A. R. Silva @ 2018-04-05 16:20 UTC (permalink / raw)
To: Xue Liu, Alexander Aring, Stefan Schmidt
Cc: linux-wpan, netdev, linux-kernel, Gustavo A. R. Silva
Free allocated memory for pdata before return.
Addresses-Coverity-ID: 1466096 ("Resource leak")
Fixes: 8c6ad9cc5157 ("ieee802154: Add NXP MCR20A IEEE 802.15.4 transceiver driver")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/net/ieee802154/mcr20a.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ieee802154/mcr20a.c b/drivers/net/ieee802154/mcr20a.c
index 55a22c7..944470d 100644
--- a/drivers/net/ieee802154/mcr20a.c
+++ b/drivers/net/ieee802154/mcr20a.c
@@ -1267,7 +1267,7 @@ mcr20a_probe(struct spi_device *spi)
ret = mcr20a_get_platform_data(spi, pdata);
if (ret < 0) {
dev_crit(&spi->dev, "mcr20a_get_platform_data failed.\n");
- return ret;
+ goto free_pdata;
}
/* init reset gpio */
@@ -1275,7 +1275,7 @@ mcr20a_probe(struct spi_device *spi)
ret = devm_gpio_request_one(&spi->dev, pdata->rst_gpio,
GPIOF_OUT_INIT_HIGH, "reset");
if (ret)
- return ret;
+ goto free_pdata;
}
/* reset mcr20a */
@@ -1291,7 +1291,8 @@ mcr20a_probe(struct spi_device *spi)
hw = ieee802154_alloc_hw(sizeof(*lp), &mcr20a_hw_ops);
if (!hw) {
dev_crit(&spi->dev, "ieee802154_alloc_hw failed\n");
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto free_pdata;
}
/* init mcr20a local data */
@@ -1366,6 +1367,8 @@ mcr20a_probe(struct spi_device *spi)
free_dev:
ieee802154_free_hw(lp->hw);
+free_pdata:
+ kfree(pdata);
return ret;
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2 bpf-next 0/3] bpf/verifier: subprog/func_call simplifications
From: Edward Cree @ 2018-04-05 16:29 UTC (permalink / raw)
To: Jiong Wang, Alexei Starovoitov; +Cc: Daniel Borkmann, netdev
In-Reply-To: <2ff89131-c6ea-5ddf-156c-c6f6e455fbdd@netronome.com>
On 05/04/18 16:50, Jiong Wang wrote:
> On 03/04/2018 02:08, Alexei Starovoitov wrote:
>> Combining subprog pass with do_check is going into opposite direction
>> of this long term work. Divide and conquer. Combining more things into
>> do_check is the opposite of this programming principle.
>
> Agree. And for the redundant insn traversal issue in check_subprogs that
> Edward trying to fix, I am thinking we could do it by utilizing the
> existing DFS traversal in check_cfg.
>
> The current DFS probably could be improved into an generic instruction
> information collection pass.
<snip>
> And if we want to build basic-block later, we could just call a new add_bb
> (similar as add_subprog) for jump targets etc. (some of those places are
> actually STATE_LIST_MARK_JMPTARGET if we separate STATE_LIST_MARK as
> STATE_LIST_MARK_JMPTARGET and STATE_LIST_MARK_HEURISTIC).
>
> Regards,
> Jiong
>
This is broadly similar to my medium-term plan, except that I would use
the Kahn's-algorithm style tsort rather than the depth-first tsort
algorithm used by current check_cfg.
* chop up prog into functions and bbs, incidentally placing S_L_Ms
* create control flow graph similar to my function call graph
* tsort it to detect loops, similar to how my check_max_stack_depth()
implementation detects recursion.
-Ed
^ permalink raw reply
* Re: [PATCH] qtnfmac: pearl: pcie: fix memory leak in qtnf_fw_work_handler
From: Sergey Matyukevich @ 2018-04-05 16:31 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Igor Mitsyanko, Avinash Patil, Sergey Matyukevich, Kalle Valo,
linux-wireless, netdev, linux-kernel
In-Reply-To: <20180405154949.GA32223@embeddedor.com>
Hello Gustavo,
> In case memory resources for fw were succesfully allocated, release
> them before jumping to fw_load_fail.
>
> Addresses-Coverity-ID: 1466092 ("Resource leak")
> Fixes: c3b2f7ca4186 ("qtnfmac: implement asynchronous firmware loading")
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
> ---
> drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c | 4 ++++
> 1 file changed, 4 insertions(+)
Thanks for the patch!
Reviewed-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
Regards,
Sergey
^ permalink raw reply
* Re: [PATCH] qtnfmac: pearl: pcie: fix memory leak in qtnf_fw_work_handler
From: Gustavo A. R. Silva @ 2018-04-05 16:33 UTC (permalink / raw)
To: Igor Mitsyanko, Avinash Patil, Sergey Matyukevich, Kalle Valo,
linux-wireless, netdev, linux-kernel
In-Reply-To: <20180405163100.cuaedftds47pxdrn@bars>
Hi Sergey,
On 04/05/2018 11:31 AM, Sergey Matyukevich wrote:
> Hello Gustavo,
>
>> In case memory resources for fw were succesfully allocated, release
>> them before jumping to fw_load_fail.
>>
>> Addresses-Coverity-ID: 1466092 ("Resource leak")
>> Fixes: c3b2f7ca4186 ("qtnfmac: implement asynchronous firmware loading")
>> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
>> ---
>> drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>
> Thanks for the patch!
>
Glad to help. :)
> Reviewed-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
>
Thanks
--
Gustavo
^ permalink raw reply
* Re: [PATCH net-next] pptp: remove a buggy dst release in pptp_connect()
From: Sasha Levin @ 2018-04-05 16:42 UTC (permalink / raw)
To: Sasha Levin, Eric Dumazet, David S . Miller
Cc: netdev, stable@vger.kernel.org
In-Reply-To: <20180403014837.56377-1-edumazet@google.com>
Hi.
[This is an automated email]
This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 30.1120)
The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126,
v4.15.15: Build OK!
v4.14.32: Build OK!
v4.9.92: Build OK!
v4.4.126: Build OK!
Please let us know if you'd like to have this patch included in a stable tree.
^ permalink raw reply
* Re: [PATCH v3 2/4] bus: fsl-mc: add restool userspace support
From: Andrew Lunn @ 2018-04-05 16:56 UTC (permalink / raw)
To: gregkh
Cc: Ruxandra Ioana Ciocoi Radulescu, Laurentiu Tudor, Stuart Yoder,
Arnd Bergmann, Ioana Ciornei, Linux Kernel Mailing List,
Razvan Stefanescu, Roy Pledge, Networking
In-Reply-To: <20180405161214.GB9976@kroah.com>
> > Hi Andrew,
> >
> > We're waiting for the DPIO driver (which we depend on) to be moved
> > out of staging first, it's currently under review:
> > https://lkml.org/lkml/2018/3/27/1086
>
> That's stalled on my side right now as the merge window is open and I
> can't do any new stuff until after 4.17-rc1 is out. So everyone please
> be patient a bit...
I took a quick look.
There are a few inline functions in .c files which is generally
frowned upon. Let the compiler decide.
e.g:
static inline struct dpaa2_io *service_select_by_cpu(struct dpaa2_io *d,
int cpu)
static inline struct dpaa2_io *service_select(struct dpaa2_io *d)
dpaa2_io_down() seems to be too simple. dpaa2_io_create() sets up
interrupt triggers, notifications, and adds the new object to the
dpio_list. dpaa2_io_down() seems to just free the memory. Do
notifications need to be disabled, the object taken off the list?
dpaa2_io_store_create() allocates memory using kzalloc() and then uses
dma_map_single(,,DMA_FROM_DEVICE). The documentation says:
DMA_FROM_DEVICE synchronisation must be done before the driver
accesses data that may be changed by the device. This memory
should be treated as read-only by the driver. If the driver needs
to write to it at any point, it should be DMA_BIDIRECTIONAL (see
below).
Since it has just been allocated, this seems questionable.
I'm also not sure where the correct call to
dma_map_single(,,DMA_FROM_DEVICE) is? Should dpaa2_io_store_next()
doing this?
The DMA API usage might need a closer review.
Andrew
^ permalink raw reply
* Re: [PATCH iproute2] ip/l2tp: remove offset and peer-offset options
From: Guillaume Nault @ 2018-04-05 17:19 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, James Chapman
In-Reply-To: <20180404164310.43259e82@xeon-e3>
On Wed, Apr 04, 2018 at 04:43:10PM -0700, Stephen Hemminger wrote:
> On Tue, 3 Apr 2018 17:39:54 +0200
> Guillaume Nault <g.nault@alphalink.fr> wrote:
>
> > Ignore options "peer-offset" and "offset" when creating sessions. Keep
> > them when dumping sessions in order to avoid breaking external scripts.
> >
> > "peer-offset" has always been a noop in iproute2. "offset" is now
> > ignored in Linux 4.16 (and was broken before that).
> >
> > Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
>
> Sure, this makes sense applied.
> In theory, you could have just dropped them from the JSON output.
Indeed, I'll followup on this.
^ permalink raw reply
* [PATCH iproute2] l2tp: no need to export session offsets in JSON output
From: Guillaume Nault @ 2018-04-05 17:24 UTC (permalink / raw)
To: netdev; +Cc: James Chapman, Stephen Hemminger
The offset and peer_offset parameters are only printed to avoid
confusing external scripts that may parse "ip l2tp show session"
output. There's no reason to keep them in JSON.
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
---
ip/ipl2tp.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/ip/ipl2tp.c b/ip/ipl2tp.c
index 427e0249..05e96387 100644
--- a/ip/ipl2tp.c
+++ b/ip/ipl2tp.c
@@ -306,8 +306,9 @@ static void print_session(struct l2tp_data *data)
print_string(PRINT_FP, NULL, "%s", _SL_);
}
- print_uint(PRINT_ANY, "offset", " offset %u,", 0);
- print_uint(PRINT_ANY, "peer_offset", " peer offset %u\n", 0);
+ /* Show offsets only for plain console output (for legacy scripts) */
+ print_uint(PRINT_FP, "offset", " offset %u,", 0);
+ print_uint(PRINT_FP, "peer_offset", " peer offset %u\n", 0);
if (p->cookie_len > 0)
print_cookie("cookie", "cookie",
--
2.17.0
^ permalink raw reply related
* Re: Kernel bug from adding bpf actions in tc
From: Davide Caratti @ 2018-04-05 17:27 UTC (permalink / raw)
To: Lucas Bates; +Cc: Linux Kernel Network Developers
In-Reply-To: <CAMDBHY+SBEUS=-XCWugKeyRd99HDi9fT+jEFs2iYF-oueuBjRg@mail.gmail.com>
On Thu, 2018-04-05 at 11:23 -0400, Lucas Bates wrote:
> Hi Davide,
>
> Our overnight tc test runs of net-next revealed a kernel bug on one of
> the BPF tests you submitted, d959. The add action completes
> successfully, but the bug occurs on the verify when tdc does a get of
> the action that was just added. Here's the text of the dump:
>
looking at the call trace, I think cfg->filter is NULL when
tcf_bpf_cleanup() is called, and apparently we are in the error path of
tcf_bpf_init(), when
prog->bpf_ops = cfg.bpf_ops;
...
rcu_assign_pointer(prog->filter, cfg.filter);
have not been executed yet.
If tcf_idr_release() is called in this situation, cfg->is_ebpf is assigned
to true, and bpf_prog_put() can dereference a NULL pointer.
I will try reproducing in the next hours, and eventually followup with a
patch.
thanks!
regards,
--
davide
^ permalink raw reply
* Re: [PATCH net-next 6/6] netdevsim: Add simple FIB resource controller via devlink
From: Jiri Pirko @ 2018-04-05 17:27 UTC (permalink / raw)
To: David Ahern
Cc: netdev, davem, roopa, shm, jiri, idosch, jakub.kicinski,
andy.roulin
In-Reply-To: <20180328012200.15175-7-dsa@cumulusnetworks.com>
Wed, Mar 28, 2018 at 03:22:00AM CEST, dsa@cumulusnetworks.com wrote:
>Add devlink support to netdevsim and use it to implement a simple,
>profile based resource controller. Only one controller is needed
>per namespace, so the first netdevsim netdevice in a namespace
>registers with devlink. If that device is deleted, the resource
>settings are deleted.
I don't understand why you add 1:1 fixed relationship between
netnamespace and devlink instance. That is highly misleading and reader
might think that those 2 are somehow related. They are not. You can have
multiple devlink instances for many ports in a single namespace.
Could you please clarify?
Also, to see the relationship between individual netdevsim netdevices
and the parent devlink instance, we should use devlink_port
instances, like this:
devlink1 devlink2
| | | |
dl_port1_1 dlport1_2 dlport2_1 dlport2_2
| | | |
eth0 eth1 eth2 eth3
Note that "devlink instance" reprensents one ASIC.
The address of the devlink instance is the bus address of the ASIC.
Here, you use address of some/first netdevsim netdev instance.
The way it is implemented in netdevsim by this patch is wrong on
so many levels :(
Could you please fix this? I'm more than happy to help you with this,
please say so. Thanks!
[...]
>+ err = devlink_resource_register(devlink, "IPv4", (u64)-1,
>+ NSIM_RESOURCE_IPV4,
>+ DEVLINK_RESOURCE_ID_PARENT_TOP,
>+ ¶ms, NULL);
>+ if (err) {
>+ pr_err("Failed to register IPv4 top resource\n");
>+ goto out;
this goto is pointless. Just return.
^ permalink raw reply
* RE: [Intel-wired-lan] [next-queue PATCH v6 08/10] igb: Add MAC address support for ethtool nftuple filters
From: Vinicius Costa Gomes @ 2018-04-05 17:59 UTC (permalink / raw)
To: Brown, Aaron F, intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, Sanchez-Palencia, Jesus
In-Reply-To: <309B89C4C689E141A5FF6A0C5FB2118B8C824FA7@ORSMSX101.amr.corp.intel.com>
Hi,
"Brown, Aaron F" <aaron.f.brown@intel.com> writes:
>> From: Intel-wired-lan [mailto:intel-wired-lan-bounces@osuosl.org] On
>> Behalf Of Vinicius Costa Gomes
>> Sent: Thursday, March 29, 2018 2:08 PM
>> To: intel-wired-lan@lists.osuosl.org
>> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus <jesus.sanchez-
>> palencia@intel.com>
>> Subject: [Intel-wired-lan] [next-queue PATCH v6 08/10] igb: Add MAC
>> address support for ethtool nftuple filters
>>
>> This adds the capability of configuring the queue steering of arriving
>> packets based on their source and destination MAC addresses.
>>
>> In practical terms this adds support for the following use cases,
>> characterized by these examples:
>>
>> $ ethtool -N eth0 flow-type ether dst aa:aa:aa:aa:aa:aa action 0
>> (this will direct packets with destination address "aa:aa:aa:aa:aa:aa"
>> to the RX queue 0)
>
> This is now working for me, testing with the dst MAC being the MAC on the i210. I set the filter and all the traffic to the destination MAC address gets routed to the chosen RX queue.
>
>> $ ethtool -N eth0 flow-type ether src 44:44:44:44:44:44 action 3
>> (this will direct packets with source address "44:44:44:44:44:44" to
>> the RX queue 3)
>
> However, I am still not getting the raw ethernet source filter to
> work. Even back to back with no other system to "confuse" the stream,
> I set the filter so the source MAC is the same as the MAC on the link
> partner, send traffic and the traffic bounces around the queues as if
> the filter is not set.
It seems there is at least a documentation issue in the i210 datasheet,
steering (placing traffic into a specific queue) by source address
doesn't work, filtering (accepting the traffic based on some rule) does
work. I pointed this out in the cover letter of v5 as a known issue, but
forgot to repeat it for v6, sorry about the confusion.
But only the filtering part is useful, I think, it enables cases like
this:
$ ethtool -N enp2s0 flow-type ether src 68:05:ca:4a:c9:73 proto 0x22f0 action 3
I added that note in the hope that someone else would have an stronger
opinion about what to do.
Anyway, my plan for now will be to document this better and turn the
case that only the source address is specified into an error.
>
>>
>> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
>> ---
>> drivers/net/ethernet/intel/igb/igb_ethtool.c | 35
>> ++++++++++++++++++++++++----
>> 1 file changed, 31 insertions(+), 4 deletions(-)
Cheers,
^ permalink raw reply
* Re: marvell switch
From: Andrew Lunn @ 2018-04-05 18:04 UTC (permalink / raw)
To: Ran Shalit; +Cc: netdev
In-Reply-To: <CAJ2oMhL5APVabJuk9R6Bp17VpEg0HZqdkA88tNhajZumsB+f6g@mail.gmail.com>
On Thu, Apr 05, 2018 at 05:26:37PM +0000, Ran Shalit wrote:
> בתאריך יום ה׳, 5 באפר׳ 2018, 19:09, מאת Andrew Lunn <andrew@lunn.ch>:
>
> > > Is there a wiki which explains switch configuration ?
> >
> > Nope. The whole idea is that they behave like normal linux
> > interfaces. So there is no need to document them. You already know how
> > to use them.
> >
> > > Is it possible to open socket and send/recieve on switch ports (lan0
> > > for example) ?
> >
> > Sure. It is as normal interface. Give is an IP address and then do
> > TCP/IP as usual.
> >
>
> There is something I don't fully understand.
> I thought that ports in switch which are not connected to the manage cpu
> are only configured by cpu and then can coomunicate with each other.
>
> What does it mean to open socket in such port (not the cpu port) and send
> data (ethernet frames) ? Does it mean that the cpu port is sending data
> directly to that port ?
The CPU port is configured to use {E}DSA tagging. Frames ingressing on
the CPU port contain an extra header. That header tells the switch
which port to send the frame out of. The switch can also send frames
received on a port out the CPU port to the host, again, with a
header. The host can tell from the header which port the frame
ingressed.
Using this, we can make ports look like normal Linux interfaces.
Andrew
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox