* Re: [PATCH net-next 1/3] dt-bindings: net: sh_eth: add R-Car Gen[12] fallback compatibility strings
From: Sergei Shtylyov @ 2017-10-17 10:18 UTC (permalink / raw)
To: Simon Horman, David Miller; +Cc: Magnus Damm, netdev, linux-renesas-soc
In-Reply-To: <20171017074747.24159-2-horms+renesas@verge.net.au>
On 10/17/2017 10:47 AM, Simon Horman wrote:
> Add fallback compatibility strings for R-Car Gen 1 and 2.
>
> In the case of Renesas R-Car hardware we know that there are generations of
> SoCs, f.e. Gen 1 and 2. But beyond that its not clear what the relationship
> between IP blocks might be. For example, I believe that r8a7790 is older
> than r8a7791 but that doesn't imply that the latter is a descendant of the
> former or vice versa.
>
> We can, however, by examining the documentation and behaviour of the
> hardware at run-time observe that the current driver implementation appears
> to be compatible with the IP blocks on SoCs within a given generation.
>
> For the above reasons and convenience when enabling new SoCs a
> per-generation fallback compatibility string scheme being adopted for
> drivers for Renesas SoCs.
>
> Note that R-Car Gen2 and RZ/G1 have many compatible IP blocks. The
> approach that has been consistently taken for other IP blocks is to name
> common code, compatibility strings and so on after Rcar Gen2.
R-Car here too. :-)
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
MBR, Sergei
^ permalink raw reply
* Re: [PATCH v2 08/15] nvmet: make config_item_type const
From: Sagi Grimberg @ 2017-10-17 10:18 UTC (permalink / raw)
To: Bhumika Goyal, julia.lawall, rjw, lenb, alexander.shishkin, jic23,
knaack.h, lars, pmeerw, dledford, sean.hefty, hal.rosenstock, hch,
kishon, bhelgaas, nab, balbi, gregkh, laurent.pinchart, jlbec,
ccaulfie, teigland, mfasheh, linux-acpi, linux-kernel, linux-iio,
linux-rdma, netdev, linux-nvme, linux-pci, linux-scsi,
target-devel, linux-usb
In-Reply-To: <1508167134-6243-9-git-send-email-bhumirks@gmail.com>
Acked-by: Sagi Grimberg <sagi@grimberg.me>
^ permalink raw reply
* Re: [PATCH net-next 2/3] net: sh_eth: rename name structures as rcar_gen[12]_*
From: Sergei Shtylyov @ 2017-10-17 10:17 UTC (permalink / raw)
To: Simon Horman, David Miller; +Cc: Magnus Damm, netdev, linux-renesas-soc
In-Reply-To: <20171017074747.24159-3-horms+renesas@verge.net.au>
Hello!
On 10/17/2017 10:47 AM, Simon Horman wrote:
> Rename structures describing R-Car SoCs as rcar_gen[12]_*
> rather than r8a77[79]x_*. This seems a little easier on the
> eyes will make things slightly cleaner in a follow-up
^
"And" missing here?
> patch that adds fallback-compatibility strings for these SoCs.
>
> Note that R-Car Gen2 and RZ/G1 have many compatible IP blocks. The
> approach that has been consistently taken for other IP blocks is to name
> common code, compatibility strings and so on after Rcar Gen2.
R-Car.
> Also rename sh_eth_set_rate_r8a777x as sh_eth_set_rate_rcar as
> it it is used by the R-Car generations supported by the driver.
>
> This patch should have no run-time effect and
> is compile-tested only.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
[...]
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
MBR, Sergei
^ permalink raw reply
* Re: [PATCH v2 00/15] make structure field, function arguments and structures const
From: Julia Lawall @ 2017-10-17 10:16 UTC (permalink / raw)
To: Greg KH
Cc: Bhumika Goyal, julia.lawall, rjw, lenb, alexander.shishkin, jic23,
knaack.h, lars, pmeerw, dledford, sean.hefty, hal.rosenstock, hch,
sagi, kishon, bhelgaas, nab, balbi, laurent.pinchart, jlbec,
ccaulfie, teigland, mfasheh, linux-acpi, linux-kernel, linux-iio,
linux-rdma, netdev, linux-nvme, linux-pci, linux-scsi,
target-devel, linux-usb, cluster-de
In-Reply-To: <20171017101245.GA4646@kroah.com>
On Tue, 17 Oct 2017, Greg KH wrote:
> On Mon, Oct 16, 2017 at 05:18:39PM +0200, Bhumika Goyal wrote:
> > Make the ci_type field and some function arguments as const. After this
> > change, make config_item_type structures as const.
> >
> > * Changes in v2- Combine all the followup patches and the constification
> > patches into a series.
>
> Who do you want to take these patches? If you want, I can take them
> through my driver-core tree, which has done other configfs stuff like
> this in the past.
Christoph Hellwig proposed to take care of it.
julia
>
> thanks,
>
> greg k-h
>
^ permalink raw reply
* linux-next: net/sched/cls_flower.c
From: Mark Brown @ 2017-10-17 10:15 UTC (permalink / raw)
To: David Miller, Networking, Or Gerlitz, Roi Dayan, Jiri Pirko
Cc: Linux-Next Mailing List, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 1616 bytes --]
Hi all,
After merging the net-next tree, today's linux-next build
(x86_allmodconfig) failed like this:
/home/broonie/tmpfs/next/net/sched/cls_flower.c: In function 'fl_hw_destroy_filter':
/home/broonie/tmpfs/next/net/sched/cls_flower.c:208:12: error: 'struct tc_cls_flower_offload' has no member named 'egress_dev'
cls_flower.egress_dev = f->hw_dev != tp->q->dev_queue->dev;
^
/home/broonie/tmpfs/next/net/sched/cls_flower.c:208:27: error: 'struct cls_fl_filter' has no member named 'hw_dev'
cls_flower.egress_dev = f->hw_dev != tp->q->dev_queue->dev;
^
/home/broonie/tmpfs/next/net/sched/cls_flower.c: In function 'fl_hw_update_stats':
/home/broonie/tmpfs/next/net/sched/cls_flower.c:270:12: error: 'struct tc_cls_flower_offload' has no member named 'egress_dev'
cls_flower.egress_dev = f->hw_dev != tp->q->dev_queue->dev;
^
/home/broonie/tmpfs/next/net/sched/cls_flower.c:270:27: error: 'struct cls_fl_filter' has no member named 'hw_dev'
cls_flower.egress_dev = f->hw_dev != tp->q->dev_queue->dev;
^
/home/broonie/tmpfs/next/scripts/Makefile.build:319: recipe for target 'net/sched/cls_flower.o' failed
Caused by commit
7578d7b45ed870b13a8ace57e32feaed623c2a94 ("net/sched: cls_flower: Set egress_dev mark when calling into the HW driver")
interacting with
7578d7b45ed870b1 ("net: sched: remove unused tcf_exts_get_dev helper and cls_flower->egress_dev")
both in the net-next tree. Falling back to previous net-next trees
introduced other issues so I reverted that commit for today.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 1/3] dt-bindings: net: sh_eth: add R-Car Gen[12] fallback compatibility strings
From: Sergei Shtylyov @ 2017-10-17 10:14 UTC (permalink / raw)
To: Simon Horman, David Miller; +Cc: Magnus Damm, netdev, linux-renesas-soc
In-Reply-To: <20171017074747.24159-2-horms+renesas@verge.net.au>
Hello!
On 10/17/2017 10:47 AM, Simon Horman wrote:
> Add fallback compatibility strings for R-Car Gen 1 and 2.
>
> In the case of Renesas R-Car hardware we know that there are generations of
> SoCs, f.e. Gen 1 and 2. But beyond that its not clear what the relationship
> between IP blocks might be. For example, I believe that r8a7790 is older
> than r8a7791 but that doesn't imply that the latter is a descendant of the
> former or vice versa.
>
> We can, however, by examining the documentation and behaviour of the
> hardware at run-time observe that the current driver implementation appears
> to be compatible with the IP blocks on SoCs within a given generation.
>
> For the above reasons and convenience when enabling new SoCs a
> per-generation fallback compatibility string scheme being adopted for
> drivers for Renesas SoCs.
>
> Note that R-Car Gen2 and RZ/G1 have many compatible IP blocks. The
> approach that has been consistently taken for other IP blocks is to name
> common code, compatibility strings and so on after Rcar Gen2.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> ---
> Documentation/devicetree/bindings/net/sh_eth.txt | 14 ++++++++++++--
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/sh_eth.txt b/Documentation/devicetree/bindings/net/sh_eth.txt
> index 0115c85a2425..48cab94dd056 100644
> --- a/Documentation/devicetree/bindings/net/sh_eth.txt
> +++ b/Documentation/devicetree/bindings/net/sh_eth.txt
> @@ -4,7 +4,8 @@ This file provides information on what the device node for the SH EtherMAC
> interface contains.
>
> Required properties:
> -- compatible: "renesas,gether-r8a7740" if the device is a part of R8A7740 SoC.
> +- compatible: Must contain one or more of the following:
> + "renesas,gether-r8a7740" if the device is a part of R8A7740 SoC.
> "renesas,ether-r8a7743" if the device is a part of R8A7743 SoC.
> "renesas,ether-r8a7745" if the device is a part of R8A7745 SoC.
> "renesas,ether-r8a7778" if the device is a part of R8A7778 SoC.
> @@ -14,6 +15,14 @@ Required properties:
> "renesas,ether-r8a7793" if the device is a part of R8A7793 SoC.
> "renesas,ether-r8a7794" if the device is a part of R8A7794 SoC.
> "renesas,ether-r7s72100" if the device is a part of R7S72100 SoC.
> + "renesas,rcar-gen1-ether" for a generic R-Car Gen1 device.
> + "renesas,rcar-gen2-ether" for a generic R-Car Gen2 or RZ/G1
> + device.
> +
> + When compatible with the generic version nodes must list
> + the SoC-specific version corresponding to the platform
> + first followed by the generic version.
> +
The original text uses the different indentation, tab and then spaces),
while you use only spaces here (but not above).
> - reg: offset and length of (1) the E-DMAC/feLic register block (required),
> (2) the TSU register block (optional).
> - interrupts: interrupt specifier for the sole interrupt.
> @@ -36,7 +45,8 @@ Optional properties:
> Example (Lager board):
>
> ethernet@ee700000 {
> - compatible = "renesas,ether-r8a7790";
> + compatible = "renesas,ether-r8a7790",
> + "renesas,rcar-gen2-ether";
Again, using one more tab seems possible here...
> reg = <0 0xee700000 0 0x400>;
> interrupt-parent = <&gic>;
> interrupts = <0 162 IRQ_TYPE_LEVEL_HIGH>;
>
MBR, Sergei
^ permalink raw reply
* Re: [PATCH net v2] bpf: disallow arithmetic operations on context pointer
From: Edward Cree @ 2017-10-17 10:14 UTC (permalink / raw)
To: Jakub Kicinski, netdev; +Cc: oss-drivers, alexei.starovoitov, daniel
In-Reply-To: <20171016181655.16366-1-jakub.kicinski@netronome.com>
On 16/10/17 19:16, Jakub Kicinski wrote:
> Commit f1174f77b50c ("bpf/verifier: rework value tracking")
> removed the crafty selection of which pointer types are
> allowed to be modified. This is OK for most pointer types
> since adjust_ptr_min_max_vals() will catch operations on
> immutable pointers. One exception is PTR_TO_CTX which is
> now allowed to be offseted freely.
>
> The intent of aforementioned commit was to allow context
> access via modified registers. The offset passed to
> ->is_valid_access() verifier callback has been adjusted
> by the value of the variable offset.
>
> What is missing, however, is taking the variable offset
> into account when the context register is used. Or in terms
> of the code adding the offset to the value passed to the
> ->convert_ctx_access() callback. This leads to the following
> eBPF user code:
>
> r1 += 68
> r0 = *(u32 *)(r1 + 8)
> exit
>
> being translated to this in kernel space:
>
> 0: (07) r1 += 68
> 1: (61) r0 = *(u32 *)(r1 +180)
> 2: (95) exit
>
> Offset 8 is corresponding to 180 in the kernel, but offset
> 76 is valid too. Verifier will "accept" access to offset
> 68+8=76 but then "convert" access to offset 8 as 180.
> Effective access to offset 248 is beyond the kernel context.
> (This is a __sk_buff example on a debug-heavy kernel -
> packet mark is 8 -> 180, 76 would be data.)
>
> Dereferencing the modified context pointer is not as easy
> as dereferencing other types, because we have to translate
> the access to reading a field in kernel structures which is
> usually at a different offset and often of a different size.
> To allow modifying the pointer we would have to make sure
> that given eBPF instruction will always access the same
> field or the fields accessed are "compatible" in terms of
> offset and size...
>
> Disallow dereferencing modified context pointers and add
> to selftests the test case described here.
>
> Fixes: f1174f77b50c ("bpf/verifier: rework value tracking")
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> ---
> Dave, a merge note - in net-next this will need env to be passed
> to verbose().
>
> v2:
> - spell dereference correctly.
>
> kernel/bpf/verifier.c | 8 ++++++--
> tools/testing/selftests/bpf/test_verifier.c | 14 ++++++++++++++
> 2 files changed, 20 insertions(+), 2 deletions(-)
Acked-by: Edward Cree <ecree@solarflare.com>
^ permalink raw reply
* Re: [PATCH v2 00/15] make structure field, function arguments and structures const
From: Greg KH @ 2017-10-17 10:12 UTC (permalink / raw)
To: Bhumika Goyal
Cc: julia.lawall, rjw, lenb, alexander.shishkin, jic23, knaack.h,
lars, pmeerw, dledford, sean.hefty, hal.rosenstock, hch, sagi,
kishon, bhelgaas, nab, balbi, laurent.pinchart, jlbec, ccaulfie,
teigland, mfasheh, linux-acpi, linux-kernel, linux-iio,
linux-rdma, netdev, linux-nvme, linux-pci, linux-scsi,
target-devel, linux-usb, cluster-devel, ocfs2-devel
In-Reply-To: <1508167134-6243-1-git-send-email-bhumirks@gmail.com>
On Mon, Oct 16, 2017 at 05:18:39PM +0200, Bhumika Goyal wrote:
> Make the ci_type field and some function arguments as const. After this
> change, make config_item_type structures as const.
>
> * Changes in v2- Combine all the followup patches and the constification
> patches into a series.
Who do you want to take these patches? If you want, I can take them
through my driver-core tree, which has done other configfs stuff like
this in the past.
thanks,
greg k-h
^ permalink raw reply
* [PATCH] net: export netdev_txq_to_tc to allow sch_mqprio to compile as module
From: Henrik Austad @ 2017-10-17 10:10 UTC (permalink / raw)
To: netdev
Cc: David S . Miller, Eric Dumazet, Daniel Borkmann, David Ahern,
Alexander Duyck, Willem de Bruijn, John Fastabend, tcharding,
linux-kernel, Henrik Austad, Jesus Sanchez-Palencia
In commit 32302902ff09 ("mqprio: Reserve last 32 classid values for HW
traffic classes and misc IDs") sch_mqprio started using netdev_txq_to_tc
to find the correct tc instead of dev->tc_to_txq[]
However, when mqprio is compiled as a module, it cannot resolve the
symbol, leading to this error:
ERROR: "netdev_txq_to_tc" [net/sched/sch_mqprio.ko] undefined!
This adds an EXPORT_SYMBOL() since the other user in the kernel
(netif_set_xps_queue) is also EXPORT_SYMBOL() (and not _GPL) or in a
sysfs-callback.
Cc: Alexander Duyck <alexander.h.duyck@intel.com>
Cc: Jesus Sanchez-Palencia <jesus.sanchez-palencia@intel.com>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Henrik Austad <haustad@cisco.com>
---
net/core/dev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/core/dev.c b/net/core/dev.c
index fcddccb..d2b20e7 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2040,6 +2040,7 @@ int netdev_txq_to_tc(struct net_device *dev, unsigned int txq)
return 0;
}
+EXPORT_SYMBOL(netdev_txq_to_tc);
#ifdef CONFIG_XPS
static DEFINE_MUTEX(xps_map_mutex);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net 0/3] bonding: void calling rtmsg_ifinfo for netlink notifications
From: Jiri Pirko @ 2017-10-17 9:59 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, davem
In-Reply-To: <cover.1508233044.git.lucien.xin@gmail.com>
Tue, Oct 17, 2017 at 11:39:38AM CEST, lucien.xin@gmail.com wrote:
>It's better to send notifications to userspace by the events
>in rtnetlink_event, instead of calling rtmsg_ifinfo directly.
>
>This patcheset is to remove rtmsg_ifinfo called in bonding,
>the notifications can be handled by NETDEV_CHANGEUPPER and
>NETDEV_CHANGELOWERSTATE events in rtnetlink_event.
>
>It could also fix some redundant notifications from bonding.
This should go to net-next.
>
>Xin Long (3):
> bonding: remove rtmsg_ifinfo called in bond_master_upper_dev_link
> rtnetlink: bring NETDEV_CHANGELOWERSTATE event process back to
> rtnetlink_event
> bonding: remove rtmsg_ifinfo called after bond_lower_state_changed
>
> drivers/net/bonding/bond_main.c | 11 +++--------
> include/net/bonding.h | 4 ----
> net/core/rtnetlink.c | 2 +-
> 3 files changed, 4 insertions(+), 13 deletions(-)
>
>--
>2.1.0
>
^ permalink raw reply
* Re: Linux 4.12+ memory leak on router with i40e NICs
From: Paweł Staszewski @ 2017-10-17 9:48 UTC (permalink / raw)
To: Alexander Duyck
Cc: Pavlos Parissis, Anders K. Pedersen | Cohaesio,
netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
alexander.h.duyck@intel.com
In-Reply-To: <310ce203-0d65-bdf4-d9e4-897a349b3277@itcare.pl>
W dniu 2017-10-17 o 02:44, Paweł Staszewski pisze:
>
>
> W dniu 2017-10-17 o 01:56, Alexander Duyck pisze:
>> On Mon, Oct 16, 2017 at 4:34 PM, Paweł Staszewski
>> <pstaszewski@itcare.pl> wrote:
>>>
>>> W dniu 2017-10-16 o 18:26, Paweł Staszewski pisze:
>>>
>>>>
>>>> W dniu 2017-10-16 o 13:20, Pavlos Parissis pisze:
>>>>> On 15/10/2017 02:58 πμ, Alexander Duyck wrote:
>>>>>> Hi Pawel,
>>>>>>
>>>>>> To clarify is that Dave Miller's tree or Linus's that you are
>>>>>> talking
>>>>>> about? If it is Dave's tree how long ago was it you pulled it
>>>>>> since I
>>>>>> think the fix was just pushed by Jeff Kirsher a few days ago.
>>>>>>
>>>>>> The issue should be fixed in the following commit:
>>>>>>
>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/drivers/net/ethernet/intel/i40e/i40e_txrx.c?id=2b9478ffc550f17c6cd8c69057234e91150f5972
>>>>>>
>>>>>>
>>>>> Do you know when it is going to be available on net-next and
>>>>> linux-stable
>>>>> repos?
>>>>>
>>>>> Cheers,
>>>>> Pavlos
>>>>>
>>>>>
>>>> I will make some tests today night with "net" git tree where this
>>>> patch is
>>>> included.
>>>> Starting from 0:00 CET
>>>> :)
>>>>
>>>>
>>> Upgraded and looks like problem is not solved with that patch
>>> Currently running system with
>>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/
>>> kernel
>>>
>>> Still about 0.5GB of memory is leaking somewhere
>>>
>>> Also can confirm that the latest kernel where memory is not leaking
>>> (with
>>> use i40e driver intel 710 cards) is 4.11.12
>>> With kernel 4.11.12 - after hour no change in memory usage.
>>>
>>> also checked that with ixgbe instead of i40e with same net.git
>>> kernel there
>>> is no memleak - after hour same memory usage - so for 100% this is i40e
>>> driver problem.
>> So how long was the run to get the .5GB of memory leaking?
> 1 hour
>
>>
>> Also is there any chance of you being able to bisect to determine
>> where the memory leak was introduced since as you pointed out it
>> didn't exist in 4.11.12 so odds are it was introduced somewhere
>> between 4.11 and the latest kernel release.
> Can be hard cause currently need to back to 4.11.12 - this is
> production host/router
> Will try to find some free/test router for tests/bicects with i40e
> driver (intel 710 cards)
>
>>
>> Thanks.
>>
>> - Alex
>>
>
>
Also forgoto to add errors for i40e when driver initialize:
[ 15.760569] i40e 0000:02:00.1: Error I40E_AQ_RC_ENOSPC adding RX
filters on PF, promiscuous mode forced on
[ 16.365587] i40e 0000:03:00.3: Error I40E_AQ_RC_ENOSPC adding RX
filters on PF, promiscuous mode forced on
[ 16.367686] i40e 0000:02:00.2: Error I40E_AQ_RC_ENOSPC adding RX
filters on PF, promiscuous mode forced on
[ 16.368816] i40e 0000:03:00.0: Error I40E_AQ_RC_ENOSPC adding RX
filters on PF, promiscuous mode forced on
[ 16.369877] i40e 0000:03:00.2: Error I40E_AQ_RC_ENOSPC adding RX
filters on PF, promiscuous mode forced on
[ 16.370941] i40e 0000:02:00.3: Error I40E_AQ_RC_ENOSPC adding RX
filters on PF, promiscuous mode forced on
[ 16.372005] i40e 0000:02:00.0: Error I40E_AQ_RC_ENOSPC adding RX
filters on PF, promiscuous mode forced on
[ 16.373029] i40e 0000:03:00.1: Error I40E_AQ_RC_ENOSPC adding RX
filters on PF, promiscuous mode forced on
some params that are set for this nic's
ip link set up dev $i
ethtool -A $i autoneg off rx off tx off
ethtool -G $i rx 1024 tx 2048
ip link set $i txqueuelen 1000
ethtool -C $i adaptive-rx off adaptive-tx off rx-usecs 512
tx-usecs 128
ethtool -L $i combined 6
#ethtool -N $i rx-flow-hash udp4 sdfn
ethtool -K $i ntuple on
ethtool -K $i gro off
ethtool -K $i tso off
^ permalink raw reply
* [PATCH net 3/3] bonding: remove rtmsg_ifinfo called after bond_lower_state_changed
From: Xin Long @ 2017-10-17 9:39 UTC (permalink / raw)
To: network dev; +Cc: davem, Jiri Pirko
In-Reply-To: <cover.1508233044.git.lucien.xin@gmail.com>
After the patch 'rtnetlink: bring NETDEV_CHANGELOWERSTATE event
process back to rtnetlink_event', bond_lower_state_changed would
generate NETDEV_CHANGEUPPER event which would send a notification
to userspace in rtnetlink_event.
There's no need to call rtmsg_ifinfo to send the notification
any more. So this patch is to remove it from these places after
bond_lower_state_changed.
Besides, after this, rtmsg_ifinfo is not needed to be exported.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
include/net/bonding.h | 4 ----
net/core/rtnetlink.c | 1 -
2 files changed, 5 deletions(-)
diff --git a/include/net/bonding.h b/include/net/bonding.h
index b2e6865..1b7631c 100644
--- a/include/net/bonding.h
+++ b/include/net/bonding.h
@@ -330,7 +330,6 @@ static inline void bond_set_active_slave(struct slave *slave)
slave->backup = 0;
bond_queue_slave_event(slave);
bond_lower_state_changed(slave);
- rtmsg_ifinfo(RTM_NEWLINK, slave->dev, 0, GFP_ATOMIC);
}
}
@@ -340,7 +339,6 @@ static inline void bond_set_backup_slave(struct slave *slave)
slave->backup = 1;
bond_queue_slave_event(slave);
bond_lower_state_changed(slave);
- rtmsg_ifinfo(RTM_NEWLINK, slave->dev, 0, GFP_ATOMIC);
}
}
@@ -353,7 +351,6 @@ static inline void bond_set_slave_state(struct slave *slave,
slave->backup = slave_state;
if (notify) {
bond_lower_state_changed(slave);
- rtmsg_ifinfo(RTM_NEWLINK, slave->dev, 0, GFP_ATOMIC);
bond_queue_slave_event(slave);
slave->should_notify = 0;
} else {
@@ -385,7 +382,6 @@ static inline void bond_slave_state_notify(struct bonding *bond)
bond_for_each_slave(bond, tmp, iter) {
if (tmp->should_notify) {
bond_lower_state_changed(tmp);
- rtmsg_ifinfo(RTM_NEWLINK, tmp->dev, 0, GFP_ATOMIC);
tmp->should_notify = 0;
}
}
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 24cb403..1574ab5 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -2910,7 +2910,6 @@ void rtmsg_ifinfo(int type, struct net_device *dev, unsigned int change,
{
rtmsg_ifinfo_event(type, dev, change, rtnl_get_event(0), flags);
}
-EXPORT_SYMBOL(rtmsg_ifinfo);
static int nlmsg_populate_fdb_fill(struct sk_buff *skb,
struct net_device *dev,
--
2.1.0
^ permalink raw reply related
* [PATCH net 2/3] rtnetlink: bring NETDEV_CHANGELOWERSTATE event process back to rtnetlink_event
From: Xin Long @ 2017-10-17 9:39 UTC (permalink / raw)
To: network dev; +Cc: davem, Jiri Pirko
In-Reply-To: <cover.1508233044.git.lucien.xin@gmail.com>
This patch is to bring NETDEV_CHANGELOWERSTATE event process back
to rtnetlink_event so that bonding could use it instead of calling
rtmsg_ifinfo to send a notification to userspace after netdev lower
state is changed in the later patch.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/core/rtnetlink.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 5ace489..24cb403 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -4292,6 +4292,7 @@ static int rtnetlink_event(struct notifier_block *this, unsigned long event, voi
case NETDEV_CHANGEUPPER:
case NETDEV_RESEND_IGMP:
case NETDEV_CHANGEINFODATA:
+ case NETDEV_CHANGELOWERSTATE:
case NETDEV_CHANGE_TX_QUEUE_LEN:
rtmsg_ifinfo_event(RTM_NEWLINK, dev, 0, rtnl_get_event(event),
GFP_KERNEL);
--
2.1.0
^ permalink raw reply related
* [PATCH net 1/3] bonding: remove rtmsg_ifinfo called in bond_master_upper_dev_link
From: Xin Long @ 2017-10-17 9:39 UTC (permalink / raw)
To: network dev; +Cc: davem, Jiri Pirko
In-Reply-To: <cover.1508233044.git.lucien.xin@gmail.com>
Since commit 42e52bf9e3ae ("net: add netnotifier event for upper device
change"), netdev_master_upper_dev_link has generated NETDEV_CHANGEUPPER
event which would send a notification to userspace in rtnetlink_event.
There's no need to call rtmsg_ifinfo to send the notification any more.
So this patch is to remove it from bond_master_upper_dev_link as well
as bond_upper_dev_unlink to avoid the redundant notifications.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
drivers/net/bonding/bond_main.c | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index c99dc59..ba75014 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1220,22 +1220,17 @@ static enum netdev_lag_tx_type bond_lag_tx_type(struct bonding *bond)
static int bond_master_upper_dev_link(struct bonding *bond, struct slave *slave)
{
struct netdev_lag_upper_info lag_upper_info;
- int err;
lag_upper_info.tx_type = bond_lag_tx_type(bond);
- err = netdev_master_upper_dev_link(slave->dev, bond->dev, slave,
- &lag_upper_info);
- if (err)
- return err;
- rtmsg_ifinfo(RTM_NEWLINK, slave->dev, IFF_SLAVE, GFP_KERNEL);
- return 0;
+
+ return netdev_master_upper_dev_link(slave->dev, bond->dev, slave,
+ &lag_upper_info);
}
static void bond_upper_dev_unlink(struct bonding *bond, struct slave *slave)
{
netdev_upper_dev_unlink(slave->dev, bond->dev);
slave->dev->flags &= ~IFF_SLAVE;
- rtmsg_ifinfo(RTM_NEWLINK, slave->dev, IFF_SLAVE, GFP_KERNEL);
}
static struct slave *bond_alloc_slave(struct bonding *bond)
--
2.1.0
^ permalink raw reply related
* [PATCH net 0/3] bonding: void calling rtmsg_ifinfo for netlink notifications
From: Xin Long @ 2017-10-17 9:39 UTC (permalink / raw)
To: network dev; +Cc: davem, Jiri Pirko
It's better to send notifications to userspace by the events
in rtnetlink_event, instead of calling rtmsg_ifinfo directly.
This patcheset is to remove rtmsg_ifinfo called in bonding,
the notifications can be handled by NETDEV_CHANGEUPPER and
NETDEV_CHANGELOWERSTATE events in rtnetlink_event.
It could also fix some redundant notifications from bonding.
Xin Long (3):
bonding: remove rtmsg_ifinfo called in bond_master_upper_dev_link
rtnetlink: bring NETDEV_CHANGELOWERSTATE event process back to
rtnetlink_event
bonding: remove rtmsg_ifinfo called after bond_lower_state_changed
drivers/net/bonding/bond_main.c | 11 +++--------
include/net/bonding.h | 4 ----
net/core/rtnetlink.c | 2 +-
3 files changed, 4 insertions(+), 13 deletions(-)
--
2.1.0
^ permalink raw reply
* Re: [PATCH net-next 0/4] bpf: move context info out of the verifier
From: Daniel Borkmann @ 2017-10-17 9:39 UTC (permalink / raw)
To: Jakub Kicinski, netdev; +Cc: oss-drivers, alexei.starovoitov
In-Reply-To: <20171016234056.1964-1-jakub.kicinski@netronome.com>
On 10/17/2017 01:40 AM, Jakub Kicinski wrote:
> Hi!
>
> Daniel pointed out during the review of my previous patchset that
> the knowledge about context doesn't really belong directly in the
> verifier. This patch set takes a bit of a drastic approach to
> move the info out of there. I want to be able to use different
> set of verifier_ops for program analysis. To do that, I have
> to first move the test_run callback to a separate structure. Then
> verifier ops can be declared in the verifier directly and
> different sets can be picked for verification vs analysis.
Looks great, thanks for following up on this!
^ permalink raw reply
* Re: [PATCH net-next 4/4] bpf: allow access to skb->len from offloads
From: Daniel Borkmann @ 2017-10-17 9:38 UTC (permalink / raw)
To: Jakub Kicinski, netdev; +Cc: oss-drivers, alexei.starovoitov
In-Reply-To: <20171016234056.1964-5-jakub.kicinski@netronome.com>
On 10/17/2017 01:40 AM, Jakub Kicinski wrote:
> Since we are now doing strict checking of what offloads
> may access, make sure skb->len is on that list.
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
^ permalink raw reply
* Re: [PATCH net-next 3/4] bpf: move knowledge about post-translation offsets out of verifier
From: Daniel Borkmann @ 2017-10-17 9:38 UTC (permalink / raw)
To: Jakub Kicinski, netdev; +Cc: oss-drivers, alexei.starovoitov
In-Reply-To: <20171016234056.1964-4-jakub.kicinski@netronome.com>
On 10/17/2017 01:40 AM, Jakub Kicinski wrote:
> Use the fact that verifier ops are now separate from program
> ops to define a separate set of callbacks for verification of
> already translated programs.
>
> Since we expect the analyzer ops to be defined only for
> a small subset of all program types initialize their array
> by hand (don't use linux/bpf_types.h).
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
^ permalink raw reply
* Re: [PATCH net-next 2/4] bpf: remove the verifier ops from program structure
From: Daniel Borkmann @ 2017-10-17 9:38 UTC (permalink / raw)
To: Jakub Kicinski, netdev; +Cc: oss-drivers, alexei.starovoitov
In-Reply-To: <20171016234056.1964-3-jakub.kicinski@netronome.com>
On 10/17/2017 01:40 AM, Jakub Kicinski wrote:
> Since the verifier ops don't have to be associated with
> the program for its entire lifetime we can move it to
> verifier's struct bpf_verifier_env.
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
^ permalink raw reply
* Re: [PATCH net-next 1/4] bpf: split verifier and program ops
From: Daniel Borkmann @ 2017-10-17 9:37 UTC (permalink / raw)
To: Jakub Kicinski, netdev; +Cc: oss-drivers, alexei.starovoitov
In-Reply-To: <20171016234056.1964-2-jakub.kicinski@netronome.com>
On 10/17/2017 01:40 AM, Jakub Kicinski wrote:
> struct bpf_verifier_ops contains both verifier ops and operations
> used later during program's lifetime (test_run). Split the runtime
> ops into a different structure.
>
> BPF_PROG_TYPE() will now append ## _prog_ops or ## _verifier_ops
> to the names.
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
^ permalink raw reply
* Re: [PATCH] wireless: qtnfmac: Convert timers to use timer_setup()
From: Sergey Matyukevich @ 2017-10-17 8:39 UTC (permalink / raw)
To: Kees Cook
Cc: Kalle Valo, Igor Mitsyanko, Avinash Patil, Sergey Matyukevich,
Kamlesh Rath, linux-wireless, netdev, linux-kernel
In-Reply-To: <20171016233622.GA101550@beast>
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
>
> Cc: Igor Mitsyanko <imitsyanko@quantenna.com>
> Cc: Avinash Patil <avinashp@quantenna.com>
> Cc: Sergey Matyukevich <smatyukevich@quantenna.com>
> Cc: Kalle Valo <kvalo@codeaurora.org>
> Cc: Kamlesh Rath <krath@quantenna.com>
> Cc: linux-wireless@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> drivers/net/wireless/quantenna/qtnfmac/cfg80211.c | 7 +++----
> drivers/net/wireless/quantenna/qtnfmac/core.c | 2 +-
> 2 files changed, 4 insertions(+), 5 deletions(-)
Reviewed-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
Thanks!
Sergey
^ permalink raw reply
* Re: [PATCH v2 07/15] usb: gadget: configfs: make config_item_type const
From: Felipe Balbi @ 2017-10-17 8:31 UTC (permalink / raw)
To: Bhumika Goyal, julia.lawall-L2FTfq7BK8M,
rjw-LthD3rsA81gm4RdzfppkhA, lenb-DgEjT+Ai2ygdnm+yROfE0A,
alexander.shishkin-VuQAYsv1563Yd54FQh9/CA,
jic23-DgEjT+Ai2ygdnm+yROfE0A, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
dledford-H+wXaHxf7aLQT0dZR+AlfA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w, hch-jcswGhMUV9g,
sagi-NQWnxTmZq1alnMjI0IkVqw, kishon-l0cyMroinI0,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, nab-IzHhD5pYlfBP7FQvKIMDCQ,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw,
jlbec-aKy9MeLSZ9dg9hUCZPvPmw, ccaulfie-H+wXaHxf7aLQT0dZR+AlfA,
teigland-H+wXaHxf7aLQT0dZR+AlfA, mfasheh-rOS7oXVqrJRBDgjK7y7TUQ,
linux-acpi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-scsi-u79uwXL29TY76Z2rM5mHXA,
target-devel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
Cc: Bhumika Goyal
In-Reply-To: <1508167134-6243-8-git-send-email-bhumirks-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 470 bytes --]
Bhumika Goyal <bhumirks-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> Make config_item_type structures const as they are either passed to a
> function having the argument as const or stored in the const "ci_type"
> field of a config_item structure.
>
> Done using Coccinelle.
>
> Signed-off-by: Bhumika Goyal <bhumirks-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Acked-by: Felipe Balbi <felipe.balbi-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [PATCH v2 02/15] usb: gadget: make config_item_type structures const
From: Felipe Balbi @ 2017-10-17 8:30 UTC (permalink / raw)
To: Bhumika Goyal, julia.lawall-L2FTfq7BK8M,
rjw-LthD3rsA81gm4RdzfppkhA, lenb-DgEjT+Ai2ygdnm+yROfE0A,
alexander.shishkin-VuQAYsv1563Yd54FQh9/CA,
jic23-DgEjT+Ai2ygdnm+yROfE0A, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
dledford-H+wXaHxf7aLQT0dZR+AlfA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w, hch-jcswGhMUV9g,
sagi-NQWnxTmZq1alnMjI0IkVqw, kishon-l0cyMroinI0,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, nab-IzHhD5pYlfBP7FQvKIMDCQ,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw,
jlbec-aKy9MeLSZ9dg9hUCZPvPmw, ccaulfie-H+wXaHxf7aLQT0dZR+AlfA,
teigland-H+wXaHxf7aLQT0dZR+AlfA, mfasheh-rOS7oXVqrJRBDgjK7y7TUQ,
linux-acpi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-scsi-u79uwXL29TY76Z2rM5mHXA,
target-devel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
Cc: Bhumika Goyal
In-Reply-To: <1508167134-6243-3-git-send-email-bhumirks-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 575 bytes --]
Hi,
Bhumika Goyal <bhumirks-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> Make these structures const as they are only passed to the const
> argument of the functions config_{group/item}_init_type_name.
>
> Signed-off-by: Bhumika Goyal <bhumirks-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> * Changes in v2- Combine all the followup patches and the constification
> patches into a series.
I'm assuming this depends on patch 1 of the series. In that case:
Acked-by: Felipe Balbi <felipe.balbi-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 1/3] dt-bindings: net: sh_eth: add R-Car Gen[12] fallback compatibility strings
From: Geert Uytterhoeven @ 2017-10-17 8:22 UTC (permalink / raw)
To: Simon Horman
Cc: David Miller, Sergei Shtylyov, Magnus Damm,
netdev@vger.kernel.org, Linux-Renesas
In-Reply-To: <20171017074747.24159-2-horms+renesas@verge.net.au>
On Tue, Oct 17, 2017 at 9:47 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Add fallback compatibility strings for R-Car Gen 1 and 2.
>
> In the case of Renesas R-Car hardware we know that there are generations of
> SoCs, f.e. Gen 1 and 2. But beyond that its not clear what the relationship
it's
> between IP blocks might be. For example, I believe that r8a7790 is older
> than r8a7791 but that doesn't imply that the latter is a descendant of the
> former or vice versa.
>
> We can, however, by examining the documentation and behaviour of the
> hardware at run-time observe that the current driver implementation appears
> to be compatible with the IP blocks on SoCs within a given generation.
>
> For the above reasons and convenience when enabling new SoCs a
> per-generation fallback compatibility string scheme being adopted for
is being adopted?
> drivers for Renesas SoCs.
>
> Note that R-Car Gen2 and RZ/G1 have many compatible IP blocks. The
> approach that has been consistently taken for other IP blocks is to name
> common code, compatibility strings and so on after Rcar Gen2.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
^ permalink raw reply
* Re: [PATCH net-next 3/3] net: sh_eth: implement R-Car Gen[12] fallback compatibility strings
From: Geert Uytterhoeven @ 2017-10-17 8:21 UTC (permalink / raw)
To: Simon Horman
Cc: David Miller, Sergei Shtylyov, Magnus Damm,
netdev@vger.kernel.org, Linux-Renesas
In-Reply-To: <20171017074747.24159-4-horms+renesas@verge.net.au>
On Tue, Oct 17, 2017 at 9:47 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Implement fallback compatibility strings for R-Car Gen 1 and 2.
>
> In the case of Renesas R-Car hardware we know that there are generations of
> SoCs, f.e. Gen 1 and 2. But beyond that its not clear what the relationship
> between IP blocks might be. For example, I believe that r8a7790 is older
> than r8a7791 but that doesn't imply that the latter is a descendant of the
> former or vice versa.
>
> We can, however, by examining the documentation and behaviour of the
> hardware at run-time observe that the current driver implementation appears
> to be compatible with the IP blocks on SoCs within a given generation.
>
> For the above reasons and convenience when enabling new SoCs a
> per-generation fallback compatibility string scheme being adopted for
is being adopted?
> drivers for Renesas SoCs.
>
> Note that R-Car Gen2 and RZ/G1 have many compatible IP blocks. The
> approach that has been consistently taken for other IP blocks is to name
> common code, compatibility strings and so on after Rcar Gen2.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
^ 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