* Re: [RFC net-next] sfp/phylink: move module EEPROM ethtool access into netdev core ethtool
From: Andrew Lunn @ 2017-12-17 18:29 UTC (permalink / raw)
To: Russell King; +Cc: Florian Fainelli, David S. Miller, netdev
In-Reply-To: <E1eQaEt-000329-8b@rmk-PC.armlinux.org.uk>
On Sun, Dec 17, 2017 at 02:48:27PM +0000, Russell King wrote:
> Provide a pointer to the SFP bus in struct net_device, so that the
> ethtool module EEPROM methods can access the SFP directly, rather
> than needing every user to provide a hook for it.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> Questions:
> 1. Is it worth adding a pointer to struct net_device for these two
> methods, rather than having multiple duplicate veneers to vector
> the ethtool module EEPROM ioctls through to the SFP bus layer?
>
> 2. Should this allow network/phy drivers to override the default -
> the code is currently structured to allow phy drivers to override
> network drivers implementations, which seems the wrong way around.
Hi Russell
Looking at drivers which implement reading the EEPROM, very few of
them expose the i2c bus, as a linux i2c bus. They seem to send
commands off to the firmware, and have it return a block of data. So
converting to using the generic SFP code is not going to be too easy.
Probably a low hanging fruit is to expose a few library like functions
for parsing the EEPROM data. As you said, there seems to be a few bugs
in the drivers with respect to actually interpreting the data. So
having one central implementation, without bugs, would be good.
Rather than adding the sfp bus to net_device, i think phylink will get
more use. And the default implementation of these methods can look at
the phylink to see if there is an sfp device. We are unlikely to be
able to replace phydev with phylink, but maybe all new 10Gbps PHY and
fibre modules not hidden behind firmware could use phylink? So having
phylink in net_device could make sense. There has been a move to
remove phydev from the drivers private structure and use the one in
net_device. Maybe we should do the same for phylink?
Andrew
^ permalink raw reply
* Re: [PATCH] openvswitch: Trim off padding before L3 conntrack processing
From: Pravin Shelar @ 2017-12-17 19:22 UTC (permalink / raw)
To: Ed Swierk
Cc: ovs-dev, Linux Kernel Network Developers, Lance Richardson,
Benjamin Warren, Keith Holleman
In-Reply-To: <CAO_EM_mDa17fQx+--RDSyr1_qKSW7ZKxtt+p3J9yt23F8m_F1w@mail.gmail.com>
On Thu, Dec 14, 2017 at 12:05 PM, Ed Swierk <eswierk@skyportsystems.com> wrote:
> On Wed, Dec 13, 2017 at 4:58 PM, Pravin Shelar <pshelar@ovn.org> wrote:
>> On Tue, Dec 12, 2017 at 8:17 AM, Ed Swierk <eswierk@skyportsystems.com> wrote:
>>> A short IPv4 packet may have up to 6 bytes of padding following the IP
>>> payload when received on an Ethernet device.
>>>
>>> In the normal IPv4 receive path, ip_rcv() trims the packet to
>>> ip_hdr->tot_len before invoking NF_INET_PRE_ROUTING hooks (including
>>> conntrack). Then any subsequent L3+ processing steps, like
>>> nf_checksum(), use skb->len as the length of the packet, rather than
>>> referring back to ip_hdr->tot_len. In the IPv6 receive path, ip6_rcv()
>>> does the same using ipv6_hdr->payload_len.
>>>
>>> In the OVS conntrack receive path, this trimming does not occur, so
>>> the checksum verification in tcp_header() fails, printing "nf_ct_tcp:
>>> bad TCP checksum". Extra zero bytes don't affect the checksum, but the
>>> length in the IP pseudoheader does. That length is based on skb->len,
>>> and without trimming, it doesn't match the length the sender used when
>>> computing the checksum.
>>>
>>> With this change, OVS conntrack trims IPv4 and IPv6 packets prior to
>>> L3 processing.
>>>
>>> Signed-off-by: Ed Swierk <eswierk@skyportsystems.com>
>>> ---
>>> net/openvswitch/conntrack.c | 17 +++++++++++++++++
>>> 1 file changed, 17 insertions(+)
>>>
>>> diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
>>> index d558e882ca0c..3a7c9215c431 100644
>>> --- a/net/openvswitch/conntrack.c
>>> +++ b/net/openvswitch/conntrack.c
>>> @@ -1105,12 +1105,29 @@ int ovs_ct_execute(struct net *net, struct sk_buff *skb,
>>> const struct ovs_conntrack_info *info)
>>> {
>>> int nh_ofs;
>>> + unsigned int nh_len;
>>> int err;
>>>
>>> /* The conntrack module expects to be working at L3. */
>>> nh_ofs = skb_network_offset(skb);
>>> skb_pull_rcsum(skb, nh_ofs);
>>>
>>> + /* Trim to L3 length since nf_checksum() doesn't expect padding. */
>> Can you explore if nf_checksum can be changed to avoid the padding?
>
> The nf_ip_checksum() and nf_ip6_checksum() helper functions can easily
> be changed to avoid the padding.
>
> My worry is that conntrack is just one of many netfilter hooks that
> perform L3+ processing, and may assume that once skb->data points to
> the L3 header, skb->len reflects the length of the L3 header and
> payload. For example, in nf_conntrack_ftp.c, help() uses skb->len to
> determine the length of the FTP payload and the TCP sequence number of
> the next packet; this would be thrown off by lower-layer padding.
>
> br_netfilter, a cousin of OVS, has always preserved this
> assumption--like ip_rcv() and ip6_rcv(), br_validate_ipv4() and
> br_validate_ipv6() trim the skb to the L3 length before they invoke
> NF_INET_PRE_ROUTING hooks. Modifying OVS to fit the mold seems more
> straightforward than changing this assumption.
>
we could avoid extra processing in fast path, thats why I wanted to
explore this, But if it is too complex, I am fine with this patch.
>>> + switch (skb->protocol) {
>>> + case htons(ETH_P_IP):
>>> + nh_len = ntohs(ip_hdr(skb)->tot_len);
>>> + break;
>>> + case htons(ETH_P_IPV6):
>>> + nh_len = ntohs(ipv6_hdr(skb)->payload_len)
>>> + + sizeof(struct ipv6hdr);
>>> + break;
>>> + default:
>>> + nh_len = skb->len;
>>> + }
>>> + err = pskb_trim_rcsum(skb, nh_len);
>>> + if (err)
>>> + return err;
>>> +
>> In case of error skb needs to be freed.
>
> Thanks, I will fix this.
>
> --Ed
^ permalink raw reply
* Re: [PATCH] openvswitch: Trim off padding before L3 conntrack processing
From: Pravin Shelar @ 2017-12-17 19:22 UTC (permalink / raw)
To: Ed Swierk
Cc: ovs-dev, Linux Kernel Network Developers, Lance Richardson,
Benjamin Warren, Keith Holleman
In-Reply-To: <CAO_EM_mDa17fQx+--RDSyr1_qKSW7ZKxtt+p3J9yt23F8m_F1w@mail.gmail.com>
On Thu, Dec 14, 2017 at 12:05 PM, Ed Swierk <eswierk@skyportsystems.com> wrote:
> On Wed, Dec 13, 2017 at 4:58 PM, Pravin Shelar <pshelar@ovn.org> wrote:
>> On Tue, Dec 12, 2017 at 8:17 AM, Ed Swierk <eswierk@skyportsystems.com> wrote:
>>> A short IPv4 packet may have up to 6 bytes of padding following the IP
>>> payload when received on an Ethernet device.
>>>
>>> In the normal IPv4 receive path, ip_rcv() trims the packet to
>>> ip_hdr->tot_len before invoking NF_INET_PRE_ROUTING hooks (including
>>> conntrack). Then any subsequent L3+ processing steps, like
>>> nf_checksum(), use skb->len as the length of the packet, rather than
>>> referring back to ip_hdr->tot_len. In the IPv6 receive path, ip6_rcv()
>>> does the same using ipv6_hdr->payload_len.
>>>
>>> In the OVS conntrack receive path, this trimming does not occur, so
>>> the checksum verification in tcp_header() fails, printing "nf_ct_tcp:
>>> bad TCP checksum". Extra zero bytes don't affect the checksum, but the
>>> length in the IP pseudoheader does. That length is based on skb->len,
>>> and without trimming, it doesn't match the length the sender used when
>>> computing the checksum.
>>>
>>> With this change, OVS conntrack trims IPv4 and IPv6 packets prior to
>>> L3 processing.
>>>
>>> Signed-off-by: Ed Swierk <eswierk@skyportsystems.com>
>>> ---
>>> net/openvswitch/conntrack.c | 17 +++++++++++++++++
>>> 1 file changed, 17 insertions(+)
>>>
>>> diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
>>> index d558e882ca0c..3a7c9215c431 100644
>>> --- a/net/openvswitch/conntrack.c
>>> +++ b/net/openvswitch/conntrack.c
>>> @@ -1105,12 +1105,29 @@ int ovs_ct_execute(struct net *net, struct sk_buff *skb,
>>> const struct ovs_conntrack_info *info)
>>> {
>>> int nh_ofs;
>>> + unsigned int nh_len;
>>> int err;
>>>
>>> /* The conntrack module expects to be working at L3. */
>>> nh_ofs = skb_network_offset(skb);
>>> skb_pull_rcsum(skb, nh_ofs);
>>>
>>> + /* Trim to L3 length since nf_checksum() doesn't expect padding. */
>> Can you explore if nf_checksum can be changed to avoid the padding?
>
> The nf_ip_checksum() and nf_ip6_checksum() helper functions can easily
> be changed to avoid the padding.
>
> My worry is that conntrack is just one of many netfilter hooks that
> perform L3+ processing, and may assume that once skb->data points to
> the L3 header, skb->len reflects the length of the L3 header and
> payload. For example, in nf_conntrack_ftp.c, help() uses skb->len to
> determine the length of the FTP payload and the TCP sequence number of
> the next packet; this would be thrown off by lower-layer padding.
>
> br_netfilter, a cousin of OVS, has always preserved this
> assumption--like ip_rcv() and ip6_rcv(), br_validate_ipv4() and
> br_validate_ipv6() trim the skb to the L3 length before they invoke
> NF_INET_PRE_ROUTING hooks. Modifying OVS to fit the mold seems more
> straightforward than changing this assumption.
>
we could avoid extra processing in fast path, thats why I wanted to
explore this, But if it is too complex, I am fine with this patch.
>>> + switch (skb->protocol) {
>>> + case htons(ETH_P_IP):
>>> + nh_len = ntohs(ip_hdr(skb)->tot_len);
>>> + break;
>>> + case htons(ETH_P_IPV6):
>>> + nh_len = ntohs(ipv6_hdr(skb)->payload_len)
>>> + + sizeof(struct ipv6hdr);
>>> + break;
>>> + default:
>>> + nh_len = skb->len;
>>> + }
>>> + err = pskb_trim_rcsum(skb, nh_len);
>>> + if (err)
>>> + return err;
>>> +
>> In case of error skb needs to be freed.
>
> Thanks, I will fix this.
>
> --Ed
^ permalink raw reply
* Re: [RFC net-next] sfp/phylink: move module EEPROM ethtool access into netdev core ethtool
From: Russell King - ARM Linux @ 2017-12-17 19:26 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Florian Fainelli, David S. Miller, netdev
In-Reply-To: <20171217182922.GB29596@lunn.ch>
On Sun, Dec 17, 2017 at 07:29:22PM +0100, Andrew Lunn wrote:
> On Sun, Dec 17, 2017 at 02:48:27PM +0000, Russell King wrote:
> > Provide a pointer to the SFP bus in struct net_device, so that the
> > ethtool module EEPROM methods can access the SFP directly, rather
> > than needing every user to provide a hook for it.
> >
> > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > ---
> > Questions:
> > 1. Is it worth adding a pointer to struct net_device for these two
> > methods, rather than having multiple duplicate veneers to vector
> > the ethtool module EEPROM ioctls through to the SFP bus layer?
> >
> > 2. Should this allow network/phy drivers to override the default -
> > the code is currently structured to allow phy drivers to override
> > network drivers implementations, which seems the wrong way around.
>
> Hi Russell
>
> Looking at drivers which implement reading the EEPROM, very few of
> them expose the i2c bus, as a linux i2c bus. They seem to send
> commands off to the firmware, and have it return a block of data. So
> converting to using the generic SFP code is not going to be too easy.
>
> Probably a low hanging fruit is to expose a few library like functions
> for parsing the EEPROM data. As you said, there seems to be a few bugs
> in the drivers with respect to actually interpreting the data. So
> having one central implementation, without bugs, would be good.
>
> Rather than adding the sfp bus to net_device, i think phylink will get
> more use. And the default implementation of these methods can look at
> the phylink to see if there is an sfp device.
You can't layer phylink on top of phylib on top of phylink for the
situation where we have a SFP cage connected to a PHY - that's the
problem.
SFP needs to know what is happening with the net device, and when
to enable or disable the laser, and although there's notifiers for
the netdev up/down, using that is far from ideal in this case - to
do so, SFP would need the reverse phandle in DT so it knows which
network device its associated with. I've already been there with
a previous iteration of the SFP code.
> We are unlikely to be
> able to replace phydev with phylink, but maybe all new 10Gbps PHY and
> fibre modules not hidden behind firmware could use phylink? So having
> phylink in net_device could make sense. There has been a move to
> remove phydev from the drivers private structure and use the one in
> net_device. Maybe we should do the same for phylink?
I would suggest you read the patch that adds SFP support to the 88x3310
PHY driver - that case makes no use of phylink. As I mention above,
it's not possible to layer phylink on top of phylib. Not only would
that lead to nested locks, but phy drivers do not have the knowledge
necessary to know when to make various phylink calls, as phylib
drivers have no clue when the network device comes up/goes down for
example.
--
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 bpf-next 00/13] bpf: introduce function calls
From: Daniel Borkmann @ 2017-12-17 19:38 UTC (permalink / raw)
To: Alexei Starovoitov, David S . Miller
Cc: John Fastabend, Edward Cree, Jakub Kicinski, netdev, kernel-team
In-Reply-To: <20171215015517.409513-1-ast@kernel.org>
On 12/15/2017 02:55 AM, Alexei Starovoitov wrote:
> First of all huge thank you to Daniel, John, Jakub, Edward and others who
> reviewed multiple iterations of this patch set over the last many months
> and to Dave and others who gave critical feedback during netconf/netdev.
>
> The patch is solid enough and we thought through numerous corner cases,
> but it's not the end. More followups with code reorg and features to follow.
>
> TLDR: Allow arbitrary function calls from bpf function to another bpf function.
>
> Since the beginning of bpf all bpf programs were represented as a single function
> and program authors were forced to use always_inline for all functions
> in their C code. That was causing llvm to unnecessary inflate the code size
> and forcing developers to move code to header files with little code reuse.
>
> With a bit of additional complexity teach verifier to recognize
> arbitrary function calls from one bpf function to another as long as
> all of functions are presented to the verifier as a single bpf program.
> Extended program layout:
> ..
> r1 = .. // arg1
> r2 = .. // arg2
> call pc+1 // function call pc-relative
> exit
> .. = r1 // access arg1
> .. = r2 // access arg2
> ..
> call pc+20 // second level of function call
> ...
>
> It allows for better optimized code and finally allows to introduce
> the core bpf libraries that can be reused in different projects,
> since programs are no longer limited by single elf file.
> With function calls bpf can be compiled into multiple .o files.
>
> This patch is the first step. It detects programs that contain
> multiple functions and checks that calls between them are valid.
> It splits the sequence of bpf instructions (one program) into a set
> of bpf functions that call each other. Calls to only known
> functions are allowed. Since all functions are presented to
> the verifier at once conceptually it is 'static linking'.
>
> Future plans:
> - introduce BPF_PROG_TYPE_LIBRARY and allow a set of bpf functions
> to be loaded into the kernel that can be later linked to other
> programs with concrete program types. Aka 'dynamic linking'.
>
> - introduce function pointer type and indirect calls to allow
> bpf functions call other dynamically loaded bpf functions while
> the caller bpf function is already executing. Aka 'runtime linking'.
> This will be more generic and more flexible alternative
> to bpf_tail_calls.
>
> FAQ:
> Q: Interpreter and JIT changes mean that new instruction is introduced ?
> A: No. The call instruction technically stays the same. Now it can call
> both kernel helpers and other bpf functions.
> Calling convention stays the same as well.
> From uapi point of view the call insn got new 'relocation' BPF_PSEUDO_CALL
> similar to BPF_PSEUDO_MAP_FD 'relocation' of bpf_ldimm64 insn.
>
> Q: What had to change on LLVM side?
> A: Trivial LLVM patch to allow calls was applied to upcoming 6.0 release:
> https://reviews.llvm.org/rL318614
> with few bugfixes as well.
> Make sure to build the latest llvm to have bpf_call support.
>
> More details in the patches.
Series applied to bpf-next, thanks Alexei!
^ permalink raw reply
* Re: [PATCH bpf-next] libbpf: fix Makefile exit code if libelf not found
From: Daniel Borkmann @ 2017-12-17 19:41 UTC (permalink / raw)
To: Jakub Kicinski, netdev; +Cc: oss-drivers, alexei.starovoitov
In-Reply-To: <20171216001930.21836-1-jakub.kicinski@netronome.com>
On 12/16/2017 01:19 AM, Jakub Kicinski wrote:
> /bin/sh's exit does not recognize -1 as a number, leading to
> the following error message:
>
> /bin/sh: 1: exit: Illegal number: -1
>
> Use 1 as the exit code.
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com>
Applied to bpf-next, thanks Jakub!
^ permalink raw reply
* Re: [PATCH bpf-next] nfp: set flags in the correct member of netdev_bpf
From: Daniel Borkmann @ 2017-12-17 19:43 UTC (permalink / raw)
To: Jakub Kicinski, netdev; +Cc: oss-drivers, alexei.starovoitov
In-Reply-To: <20171216002913.22278-1-jakub.kicinski@netronome.com>
On 12/16/2017 01:29 AM, Jakub Kicinski wrote:
> netdev_bpf.flags is the input member for installing the program.
> netdev_bpf.prog_flags is the output member for querying. Set
> the correct one on query.
>
> Fixes: 92f0292b35a0 ("net: xdp: report flags program was installed with on query")
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com>
Yep, netdevsim had this correct. :) Applied to bpf-next, thanks Jakub!
^ permalink raw reply
* Re: [PATCH] trace: reenable preemption if we modify the ip
From: Daniel Borkmann @ 2017-12-17 19:49 UTC (permalink / raw)
To: Josef Bacik, netdev, mhiramat, ast, darrick.wong, linux-kernel
Cc: Josef Bacik
In-Reply-To: <1513392177-10298-1-git-send-email-josef@toxicpanda.com>
On 12/16/2017 03:42 AM, Josef Bacik wrote:
> From: Josef Bacik <jbacik@fb.com>
>
> Things got moved around between the original bpf_override_return patches
> and the final version, and now the ftrace kprobe dispatcher assumes if
> you modified the ip that you also enabled preemption. Make a comment of
> this and enable preemption, this fixes the lockdep splat that happened
> when using this feature.
>
> Signed-off-by: Josef Bacik <jbacik@fb.com>
Applied to bpf-next with Fixes tag, thanks Josef.
^ permalink raw reply
* pull-request: bpf 2017-12-17
From: Daniel Borkmann @ 2017-12-17 20:06 UTC (permalink / raw)
To: davem; +Cc: daniel, ast, netdev
Hi David,
The following pull-request contains BPF updates for your *net* tree.
The main changes are:
1) Fix a corner case in generic XDP where we have non-linear skbs
but enough tailroom in the skb to not miss to linearizing there,
from Song.
2) Fix BPF JIT bugs in s390x and ppc64 to not recache skb data when
BPF context is not skb, from Daniel.
3) Fix a BPF JIT bug in sparc64 where recaching skb data after helper
call would use the wrong register for the skb, from Daniel.
Please consider pulling these changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
Thanks a lot!
----------------------------------------------------------------
The following changes since commit 8c8f67a46f2bf33556ad12a1971734047b60831a:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf (2017-12-13 17:30:04 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
for you to fetch changes up to c1b08ebe5003ae291470cb6e26923628ab19606f:
Merge branch 'bpf-jit-fixes' (2017-12-15 09:19:37 -0800)
----------------------------------------------------------------
Alexei Starovoitov (1):
Merge branch 'bpf-jit-fixes'
Daniel Borkmann (5):
bpf, s390x: do not reload skb pointers in non-skb context
bpf, ppc64: do not reload skb pointers in non-skb context
bpf: guarantee r1 to be ctx in case of bpf_helper_changes_pkt_data
bpf, sparc: fix usage of wrong reg for load_skb_regs after call
bpf: add test case for ld_abs and helper changing pkt data
Song Liu (1):
xdp: linearize skb in netif_receive_generic_xdp()
arch/powerpc/net/bpf_jit_comp64.c | 6 ++--
arch/s390/net/bpf_jit_comp.c | 11 ++++----
arch/sparc/net/bpf_jit_comp_64.c | 6 ++--
kernel/bpf/verifier.c | 6 ++++
lib/test_bpf.c | 43 +++++++++++++++++++++++++++++
net/core/dev.c | 2 +-
tools/testing/selftests/bpf/test_verifier.c | 24 ++++++++++++++++
7 files changed, 87 insertions(+), 11 deletions(-)
^ permalink raw reply
* [PATCH] net: ibm: emac: support RGMII-[RX|TX]ID phymode
From: Christian Lamparter @ 2017-12-17 21:51 UTC (permalink / raw)
To: netdev; +Cc: David S . Miller, Andrew Lunn, Christophe Jaillet
The RGMII spec allows compliance for devices that implement an internal
delay on TXC and/or RXC inside the transmitter. This patch adds the
necessary RGMII_[RX|TX]ID mode code to handle such PHYs with the
emac driver.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
---
drivers/net/ethernet/ibm/emac/core.c | 3 +++
drivers/net/ethernet/ibm/emac/emac.h | 3 +++
drivers/net/ethernet/ibm/emac/rgmii.c | 9 +++++++++
3 files changed, 15 insertions(+)
diff --git a/drivers/net/ethernet/ibm/emac/core.c b/drivers/net/ethernet/ibm/emac/core.c
index 7feff2450ed6..820173bee168 100644
--- a/drivers/net/ethernet/ibm/emac/core.c
+++ b/drivers/net/ethernet/ibm/emac/core.c
@@ -201,6 +201,9 @@ static inline int emac_phy_supports_gige(int phy_mode)
{
return phy_mode == PHY_MODE_GMII ||
phy_mode == PHY_MODE_RGMII ||
+ phy_mode == PHY_MODE_RGMII_ID ||
+ phy_mode == PHY_MODE_RGMII_RXID ||
+ phy_mode == PHY_MODE_RGMII_TXID ||
phy_mode == PHY_MODE_SGMII ||
phy_mode == PHY_MODE_TBI ||
phy_mode == PHY_MODE_RTBI;
diff --git a/drivers/net/ethernet/ibm/emac/emac.h b/drivers/net/ethernet/ibm/emac/emac.h
index 5afcc27ceebb..8c6d2af7281b 100644
--- a/drivers/net/ethernet/ibm/emac/emac.h
+++ b/drivers/net/ethernet/ibm/emac/emac.h
@@ -112,6 +112,9 @@ struct emac_regs {
#define PHY_MODE_RMII PHY_INTERFACE_MODE_RMII
#define PHY_MODE_SMII PHY_INTERFACE_MODE_SMII
#define PHY_MODE_RGMII PHY_INTERFACE_MODE_RGMII
+#define PHY_MODE_RGMII_ID PHY_INTERFACE_MODE_RGMII_ID
+#define PHY_MODE_RGMII_RXID PHY_INTERFACE_MODE_RGMII_RXID
+#define PHY_MODE_RGMII_TXID PHY_INTERFACE_MODE_RGMII_TXID
#define PHY_MODE_TBI PHY_INTERFACE_MODE_TBI
#define PHY_MODE_GMII PHY_INTERFACE_MODE_GMII
#define PHY_MODE_RTBI PHY_INTERFACE_MODE_RTBI
diff --git a/drivers/net/ethernet/ibm/emac/rgmii.c b/drivers/net/ethernet/ibm/emac/rgmii.c
index c4a1ac38bba8..7963adffbb1c 100644
--- a/drivers/net/ethernet/ibm/emac/rgmii.c
+++ b/drivers/net/ethernet/ibm/emac/rgmii.c
@@ -55,6 +55,9 @@ static inline int rgmii_valid_mode(int phy_mode)
return phy_mode == PHY_MODE_GMII ||
phy_mode == PHY_MODE_MII ||
phy_mode == PHY_MODE_RGMII ||
+ phy_mode == PHY_MODE_RGMII_ID ||
+ phy_mode == PHY_MODE_RGMII_RXID ||
+ phy_mode == PHY_MODE_RGMII_TXID ||
phy_mode == PHY_MODE_TBI ||
phy_mode == PHY_MODE_RTBI;
}
@@ -63,6 +66,9 @@ static inline const char *rgmii_mode_name(int mode)
{
switch (mode) {
case PHY_MODE_RGMII:
+ case PHY_MODE_RGMII_ID:
+ case PHY_MODE_RGMII_RXID:
+ case PHY_MODE_RGMII_TXID:
return "RGMII";
case PHY_MODE_TBI:
return "TBI";
@@ -81,6 +87,9 @@ static inline u32 rgmii_mode_mask(int mode, int input)
{
switch (mode) {
case PHY_MODE_RGMII:
+ case PHY_MODE_RGMII_ID:
+ case PHY_MODE_RGMII_RXID:
+ case PHY_MODE_RGMII_TXID:
return RGMII_FER_RGMII(input);
case PHY_MODE_TBI:
return RGMII_FER_TBI(input);
--
2.15.1
^ permalink raw reply related
* Re: Linux 4.14 - regression: broken tun/tap / bridge network with virtio - bisected
From: Willem de Bruijn @ 2017-12-17 22:33 UTC (permalink / raw)
To: Andreas Hartmann
Cc: Michal Kubecek, Jason Wang, David Miller, Network Development
In-Reply-To: <c2044fb8-a2ce-241f-b1ce-054ac70a327d@01019freenet.de>
On Fri, Dec 15, 2017 at 1:05 AM, Andreas Hartmann
<andihartmann@01019freenet.de> wrote:
> On 12/14/2017 at 11:17 PM Willem de Bruijn wrote:
>>>> Well, the patch does not fix hanging VMs, which have been shutdown and
>>>> can't be killed any more.
>>>> Because of the stack trace
>>>>
>>>> [<ffffffffc0d0e3c5>] vhost_net_ubuf_put_and_wait+0x35/0x60 [vhost_net]
>>>> [<ffffffffc0d0f264>] vhost_net_ioctl+0x304/0x870 [vhost_net]
>>>> [<ffffffff9b25460f>] do_vfs_ioctl+0x8f/0x5c0
>>>> [<ffffffff9b254bb4>] SyS_ioctl+0x74/0x80
>>>> [<ffffffff9b00365b>] do_syscall_64+0x5b/0x100
>>>> [<ffffffff9b78e7ab>] entry_SYSCALL64_slow_path+0x25/0x25
>>>> [<ffffffffffffffff>] 0xffffffffffffffff
>>>>
>>>> I was hoping, that the problems could be related - but that seems not to
>>>> be true.
>>>
>>> However, it turned out, that reverting the complete patchset "Remove UDP
>>> Fragmentation Offload support" prevent hanging qemu processes.
>>
>> That implies a combination of UFO and vhost zerocopy. Disabling
>> experimental_zcopytx in vhost_net will probably work around the bug
>> then.
I have been able to reproduce the hang by sending a UFO packet
between two guests running v4.13 on a host running v4.15-rc1.
The vhost_net_ubuf_ref refcount indeed hits overflow (-1) from
vhost_zerocopy_callback being called for each segment of a
segmented UFO skb. This refcount is decremented then on each
segment, but incremented only once for the entire UFO skb.
Before v4.14, these packets would be converted in skb_segment to
regular copy packets with skb_orphan_frags and the callback function
called once at this point. v4.14 added support for reference counted
zerocopy skb that can pass through skb_orphan_frags unmodified and
have their zerocopy state safely cloned with skb_zerocopy_clone.
The call to skb_zerocopy_clone must come after skb_orphan_frags
to limit cloning of this state to those skbs that can do so safely.
Please try a host with the following patch. This fixes it for me. I intend to
send it to net.
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index a592ca025fc4..d2d985418819 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -3654,8 +3654,6 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb,
skb_shinfo(nskb)->tx_flags |= skb_shinfo(head_skb)->tx_flags &
SKBTX_SHARED_FRAG;
- if (skb_zerocopy_clone(nskb, head_skb, GFP_ATOMIC))
- goto err;
while (pos < offset + len) {
if (i >= nfrags) {
@@ -3681,6 +3679,8 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb,
if (unlikely(skb_orphan_frags(frag_skb, GFP_ATOMIC)))
goto err;
+ if (skb_zerocopy_clone(nskb, frag_skb, GFP_ATOMIC))
+ goto err;
*nskb_frag = *frag;
__skb_frag_ref(nskb_frag);
This is relatively inefficient, as it calls skb_zerocopy_clone for each frag
in the frags[] array. I will follow-up with a patch to net-next that only
checks once per skb:
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 466581cf4cdc..a293a33604ec 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -3662,7 +3662,8 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb,
skb_shinfo(nskb)->tx_flags |= skb_shinfo(head_skb)->tx_flags &
SKBTX_SHARED_FRAG;
- if (skb_zerocopy_clone(nskb, head_skb, GFP_ATOMIC))
+ if (skb_orphan_frags(frag_skb, GFP_ATOMIC) ||
+ skb_zerocopy_clone(nskb, frag_skb, GFP_ATOMIC))
goto err;
while (pos < offset + len) {
@@ -3676,6 +3677,11 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb,
BUG_ON(!nfrags);
+ if (skb_orphan_frags(frag_skb, GFP_ATOMIC) ||
+ skb_zerocopy_clone(nskb, frag_skb,
+ GFP_ATOMIC))
+ goto err;
+
list_skb = list_skb->next;
}
@@ -3687,9 +3693,6 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb,
goto err;
}
- if (unlikely(skb_orphan_frags(frag_skb, GFP_ATOMIC)))
- goto err;
-
I'll also send to net-next
(1) a patch to convert its vhost_net_ ubuf_ref refcnt to refcount_t
(2) a path to skb_zerocopy_clone to warn on clone if not
sock_zerocopy_callback
> I already tested it w/ options vhost_net experimental_zcopytx=0 - but
> this didn't "resolve" anything. See
> https://www.mail-archive.com/netdev@vger.kernel.org/msg203197.html
>
> Therefore, I think your following thoughts are lapsed unfortunately,
> aren't they?
That experiment was perhaps run before commit 0c19f846d582 ("net:
accept UFO datagrams from tuntap and packet") and hit the other UFO
bug.
^ permalink raw reply related
* [PATCH 0/3] kallsyms: don't leak address
From: Tobin C. Harding @ 2017-12-17 23:53 UTC (permalink / raw)
To: kernel-hardening
Cc: Tobin C. Harding, Steven Rostedt, Tycho Andersen, Linus Torvalds,
Kees Cook, Andrew Morton, Daniel Borkmann, Masahiro Yamada,
Alexei Starovoitov, linux-kernel, Network Development
This set plugs a kernel address leak that occurs if kallsyms symbol
look up fails. This set was prompted by a leaking address found using
scripts/leaking_addresses.pl on a PowerPC machine in the wild.
Patch set does not change behaviour when KALLSYMS is not defined
(suggested by Linus).
RFC has been in flight for 3 weeks with no negative response.
Patch 1 - return error code if symbol look up fails.
Patch 2 - print <no-symbol> to buffer if symbol look up returns an error.
Patch 3 - maintain current behaviour in ftrace.
Patch 3 (the ftrace stuff) is untested.
thanks,
Tobin.
Tobin C. Harding (3):
kallsyms: don't leak address when symbol not found
vsprintf: print <no-symbol> if symbol not found
trace: print address if symbol not found
include/linux/kernel.h | 2 ++
kernel/kallsyms.c | 6 ++++--
kernel/trace/trace.h | 24 ++++++++++++++++++++++++
kernel/trace/trace_events_hist.c | 6 +++---
lib/vsprintf.c | 18 +++++++++++++++---
5 files changed, 48 insertions(+), 8 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 1/3] kallsyms: don't leak address when symbol not found
From: Tobin C. Harding @ 2017-12-17 23:53 UTC (permalink / raw)
To: kernel-hardening
Cc: Tobin C. Harding, Steven Rostedt, Tycho Andersen, Linus Torvalds,
Kees Cook, Andrew Morton, Daniel Borkmann, Masahiro Yamada,
Alexei Starovoitov, linux-kernel, Network Development
In-Reply-To: <1513554812-13014-1-git-send-email-me@tobin.cc>
Currently if kallsyms_lookup() fails to find the symbol then the address
is printed. This potentially leaks sensitive information. Instead of
printing the address we can return an error, giving the calling code the
option to print the address or print some sanitized message.
Return error instead of printing address to argument buffer. Leave
buffer in a sane state.
Signed-off-by: Tobin C. Harding <me@tobin.cc>
---
kernel/kallsyms.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index d5fa4116688a..23b9336c1461 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -394,8 +394,10 @@ static int __sprint_symbol(char *buffer, unsigned long address,
address += symbol_offset;
name = kallsyms_lookup(address, &size, &offset, &modname, buffer);
- if (!name)
- return sprintf(buffer, "0x%lx", address - symbol_offset);
+ if (!name) {
+ buffer[0] = '\0';
+ return -1;
+ }
if (name != buffer)
strcpy(buffer, name);
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] vsprintf: print <no-symbol> if symbol not found
From: Tobin C. Harding @ 2017-12-17 23:53 UTC (permalink / raw)
To: kernel-hardening
Cc: Tobin C. Harding, Steven Rostedt, Tycho Andersen, Linus Torvalds,
Kees Cook, Andrew Morton, Daniel Borkmann, Masahiro Yamada,
Alexei Starovoitov, linux-kernel, Network Development
In-Reply-To: <1513554812-13014-1-git-send-email-me@tobin.cc>
Depends on: commit bd6b239cdbb2 ("kallsyms: don't leak address when
symbol not found")
Currently vsprintf for specifiers %p[SsB] relies on the behaviour of
kallsyms (sprint_symbol()) and prints the actual address if a symbol is
not found. Previous patch changes this behaviour so tha sprint_symbol()
returns an error if symbol not found. With this patch in place we can
print a sanitized message '<no-symbol>' instead of leaking the address.
Print '<no-symbol>' for printk specifier %s[sSB] if no symbol is found.
Signed-off-by: Tobin C. Harding <me@tobin.cc>
---
include/linux/kernel.h | 2 ++
lib/vsprintf.c | 18 +++++++++++++++---
2 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index ce51455e2adf..89e8ce79c2d1 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -460,6 +460,8 @@ char *kvasprintf(gfp_t gfp, const char *fmt, va_list args);
extern __printf(2, 0)
const char *kvasprintf_const(gfp_t gfp, const char *fmt, va_list args);
+extern int string_is_no_symbol(const char *s);
+
extern __scanf(2, 3)
int sscanf(const char *, const char *, ...);
extern __scanf(2, 0)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 01c3957b2de6..c112b0980ead 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -667,6 +667,8 @@ char *bdev_name(char *buf, char *end, struct block_device *bdev,
}
#endif
+#define PRINTK_NO_SYMBOL_STR "<no-symbol>"
+
static noinline_for_stack
char *symbol_string(char *buf, char *end, void *ptr,
struct printf_spec spec, const char *fmt)
@@ -674,6 +676,7 @@ char *symbol_string(char *buf, char *end, void *ptr,
unsigned long value;
#ifdef CONFIG_KALLSYMS
char sym[KSYM_SYMBOL_LEN];
+ int ret;
#endif
if (fmt[1] == 'R')
@@ -682,11 +685,14 @@ char *symbol_string(char *buf, char *end, void *ptr,
#ifdef CONFIG_KALLSYMS
if (*fmt == 'B')
- sprint_backtrace(sym, value);
+ ret = sprint_backtrace(sym, value);
else if (*fmt != 'f' && *fmt != 's')
- sprint_symbol(sym, value);
+ ret = sprint_symbol(sym, value);
else
- sprint_symbol_no_offset(sym, value);
+ ret = sprint_symbol_no_offset(sym, value);
+
+ if (ret == -1)
+ strcpy(sym, PRINTK_NO_SYMBOL_STR);
return string(buf, end, sym, spec);
#else
@@ -694,6 +700,12 @@ char *symbol_string(char *buf, char *end, void *ptr,
#endif
}
+int string_is_no_symbol(const char *s)
+{
+ return !!strstr(s, PRINTK_NO_SYMBOL_STR);
+}
+EXPORT_SYMBOL(string_is_no_symbol);
+
static noinline_for_stack
char *resource_string(char *buf, char *end, struct resource *res,
struct printf_spec spec, const char *fmt)
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] trace: print address if symbol not found
From: Tobin C. Harding @ 2017-12-17 23:53 UTC (permalink / raw)
To: kernel-hardening
Cc: Tobin C. Harding, Steven Rostedt, Tycho Andersen, Linus Torvalds,
Kees Cook, Andrew Morton, Daniel Borkmann, Masahiro Yamada,
Alexei Starovoitov, linux-kernel, Network Development
In-Reply-To: <1513554812-13014-1-git-send-email-me@tobin.cc>
Fixes behaviour modified by: commit bd6b239cdbb2 ("kallsyms: don't leak
address when symbol not found")
Previous patch changed behaviour of kallsyms function sprint_symbol() to
return an error code instead of printing the address if a symbol was not
found. Ftrace relies on the original behaviour. We should not break
tracing when applying the previous patch. We can maintain the original
behaviour by checking the return code on calls to sprint_symbol() and
friends.
Check return code and print actual address on error (i.e symbol not
found).
Signed-off-by: Tobin C. Harding <me@tobin.cc>
---
kernel/trace/trace.h | 24 ++++++++++++++++++++++++
kernel/trace/trace_events_hist.c | 6 +++---
2 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 2a6d0325a761..881b1a577d75 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -1814,4 +1814,28 @@ static inline void trace_event_eval_update(struct trace_eval_map **map, int len)
extern struct trace_iterator *tracepoint_print_iter;
+static inline int
+trace_sprint_symbol(char *buffer, unsigned long address)
+{
+ int ret;
+
+ ret = sprint_symbol(buffer, address);
+ if (ret == -1)
+ ret = sprintf(buffer, "0x%lx", address);
+
+ return ret;
+}
+
+static inline int
+trace_sprint_symbol_no_offset(char *buffer, unsigned long address)
+{
+ int ret;
+
+ ret = sprint_symbol_no_offset(buffer, address);
+ if (ret == -1)
+ ret = sprintf(buffer, "0x%lx", address);
+
+ return ret;
+}
+
#endif /* _LINUX_KERNEL_TRACE_H */
diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c
index 1e1558c99d56..3e28522a76f4 100644
--- a/kernel/trace/trace_events_hist.c
+++ b/kernel/trace/trace_events_hist.c
@@ -982,7 +982,7 @@ static void hist_trigger_stacktrace_print(struct seq_file *m,
return;
seq_printf(m, "%*c", 1 + spaces, ' ');
- sprint_symbol(str, stacktrace_entries[i]);
+ trace_sprint_symbol_addr(str, stacktrace_entries[i]);
seq_printf(m, "%s\n", str);
}
}
@@ -1014,12 +1014,12 @@ hist_trigger_entry_print(struct seq_file *m,
seq_printf(m, "%s: %llx", field_name, uval);
} else if (key_field->flags & HIST_FIELD_FL_SYM) {
uval = *(u64 *)(key + key_field->offset);
- sprint_symbol_no_offset(str, uval);
+ trace_sprint_symbol_no_offset(str, uval);
seq_printf(m, "%s: [%llx] %-45s", field_name,
uval, str);
} else if (key_field->flags & HIST_FIELD_FL_SYM_OFFSET) {
uval = *(u64 *)(key + key_field->offset);
- sprint_symbol(str, uval);
+ trace_sprint_symbol(str, uval);
seq_printf(m, "%s: [%llx] %-55s", field_name,
uval, str);
} else if (key_field->flags & HIST_FIELD_FL_EXECNAME) {
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 2/3] vsprintf: print <no-symbol> if symbol not found
From: Joe Perches @ 2017-12-18 0:04 UTC (permalink / raw)
To: Tobin C. Harding, kernel-hardening
Cc: Steven Rostedt, Tycho Andersen, Linus Torvalds, Kees Cook,
Andrew Morton, Daniel Borkmann, Masahiro Yamada,
Alexei Starovoitov, linux-kernel, Network Development
In-Reply-To: <1513554812-13014-3-git-send-email-me@tobin.cc>
On Mon, 2017-12-18 at 10:53 +1100, Tobin C. Harding wrote:
> Depends on: commit bd6b239cdbb2 ("kallsyms: don't leak address when
> symbol not found")
>
> Currently vsprintf for specifiers %p[SsB] relies on the behaviour of
> kallsyms (sprint_symbol()) and prints the actual address if a symbol is
> not found. Previous patch changes this behaviour so tha sprint_symbol()
tha->that
> returns an error if symbol not found. With this patch in place we can
> print a sanitized message '<no-symbol>' instead of leaking the address.
>
> Print '<no-symbol>' for printk specifier %s[sSB] if no symbol is found.
%s->%ps
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
[]
> @@ -460,6 +460,8 @@ char *kvasprintf(gfp_t gfp, const char *fmt, va_list args);
> extern __printf(2, 0)
> const char *kvasprintf_const(gfp_t gfp, const char *fmt, va_list args);
>
> +extern int string_is_no_symbol(const char *s);
> +
[]
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
>
> +#define PRINTK_NO_SYMBOL_STR "<no-symbol>"
"<symbol unavailable>" ? "not found"?
[]
> +int string_is_no_symbol(const char *s)
> +{
> + return !!strstr(s, PRINTK_NO_SYMBOL_STR);
> +}
> +EXPORT_SYMBOL(string_is_no_symbol);
Why should string_is_no_symbol be exported?
^ permalink raw reply
* [trivial PATCH] treewide: Align function definition open/close braces
From: Joe Perches @ 2017-12-18 0:28 UTC (permalink / raw)
To: Jiri Kosina, Linus Torvalds
Cc: linux-rtc, alsa-devel, linuxppc-dev, linux-scsi, netdev,
acpi4asus-user, linux-wireless, linux-kernel, dri-devel,
platform-driver-x86, linux-xfs, linux-acpi, linux-audit, amd-gfx,
linux-fsdevel, MPT-FusionLinux.pdl, ocfs2-devel, linux-media
Some functions definitions have either the initial open brace and/or
the closing brace outside of column 1.
Move those braces to column 1.
This allows various function analyzers like gnu complexity to work
properly for these modified functions.
Miscellanea:
o Remove extra trailing ; and blank line from xfs_agf_verify
Signed-off-by: Joe Perches <joe@perches.com>
---
git diff -w shows no difference other than the above 'Miscellanea'
(this is against -next, but it applies against Linus' tree
with a couple offsets)
arch/x86/include/asm/atomic64_32.h | 2 +-
drivers/acpi/custom_method.c | 2 +-
drivers/acpi/fan.c | 2 +-
drivers/gpu/drm/amd/display/dc/core/dc.c | 2 +-
drivers/media/i2c/msp3400-kthreads.c | 2 +-
drivers/message/fusion/mptsas.c | 2 +-
drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c | 2 +-
drivers/net/wireless/ath/ath9k/xmit.c | 2 +-
drivers/platform/x86/eeepc-laptop.c | 2 +-
drivers/rtc/rtc-ab-b5ze-s3.c | 2 +-
drivers/scsi/dpt_i2o.c | 2 +-
drivers/scsi/sym53c8xx_2/sym_glue.c | 2 +-
fs/locks.c | 2 +-
fs/ocfs2/stack_user.c | 2 +-
fs/xfs/libxfs/xfs_alloc.c | 5 ++---
fs/xfs/xfs_export.c | 2 +-
kernel/audit.c | 6 +++---
kernel/trace/trace_printk.c | 4 ++--
lib/raid6/sse2.c | 14 +++++++-------
sound/soc/fsl/fsl_dma.c | 2 +-
20 files changed, 30 insertions(+), 31 deletions(-)
diff --git a/arch/x86/include/asm/atomic64_32.h b/arch/x86/include/asm/atomic64_32.h
index 97c46b8169b7..d4d4883080fa 100644
--- a/arch/x86/include/asm/atomic64_32.h
+++ b/arch/x86/include/asm/atomic64_32.h
@@ -122,7 +122,7 @@ static inline long long atomic64_read(const atomic64_t *v)
long long r;
alternative_atomic64(read, "=&A" (r), "c" (v) : "memory");
return r;
- }
+}
/**
* atomic64_add_return - add and return
diff --git a/drivers/acpi/custom_method.c b/drivers/acpi/custom_method.c
index c68e72414a67..e967c1173ba3 100644
--- a/drivers/acpi/custom_method.c
+++ b/drivers/acpi/custom_method.c
@@ -94,7 +94,7 @@ static void __exit acpi_custom_method_exit(void)
{
if (cm_dentry)
debugfs_remove(cm_dentry);
- }
+}
module_init(acpi_custom_method_init);
module_exit(acpi_custom_method_exit);
diff --git a/drivers/acpi/fan.c b/drivers/acpi/fan.c
index 6cf4988206f2..3563103590c6 100644
--- a/drivers/acpi/fan.c
+++ b/drivers/acpi/fan.c
@@ -219,7 +219,7 @@ fan_set_cur_state(struct thermal_cooling_device *cdev, unsigned long state)
return fan_set_state_acpi4(device, state);
else
return fan_set_state(device, state);
- }
+}
static const struct thermal_cooling_device_ops fan_cooling_ops = {
.get_max_state = fan_get_max_state,
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c b/drivers/gpu/drm/amd/display/dc/core/dc.c
index d1488d5ee028..1e0d1e7c5324 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -461,7 +461,7 @@ static void disable_dangling_plane(struct dc *dc, struct dc_state *context)
******************************************************************************/
struct dc *dc_create(const struct dc_init_data *init_params)
- {
+{
struct dc *dc = kzalloc(sizeof(*dc), GFP_KERNEL);
unsigned int full_pipe_count;
diff --git a/drivers/media/i2c/msp3400-kthreads.c b/drivers/media/i2c/msp3400-kthreads.c
index 4dd01e9f553b..dc6cb8d475b3 100644
--- a/drivers/media/i2c/msp3400-kthreads.c
+++ b/drivers/media/i2c/msp3400-kthreads.c
@@ -885,7 +885,7 @@ static int msp34xxg_modus(struct i2c_client *client)
}
static void msp34xxg_set_source(struct i2c_client *client, u16 reg, int in)
- {
+{
struct msp_state *state = to_state(i2c_get_clientdata(client));
int source, matrix;
diff --git a/drivers/message/fusion/mptsas.c b/drivers/message/fusion/mptsas.c
index 345f6035599e..69a62d23514b 100644
--- a/drivers/message/fusion/mptsas.c
+++ b/drivers/message/fusion/mptsas.c
@@ -2968,7 +2968,7 @@ mptsas_exp_repmanufacture_info(MPT_ADAPTER *ioc,
mutex_unlock(&ioc->sas_mgmt.mutex);
out:
return ret;
- }
+}
static void
mptsas_parse_device_info(struct sas_identify *identify,
diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c b/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c
index 3dd973475125..0ea141ece19e 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c
@@ -603,7 +603,7 @@ static struct uni_table_desc *nx_get_table_desc(const u8 *unirom, int section)
static int
netxen_nic_validate_header(struct netxen_adapter *adapter)
- {
+{
const u8 *unirom = adapter->fw->data;
struct uni_table_desc *directory = (struct uni_table_desc *) &unirom[0];
u32 fw_file_size = adapter->fw->size;
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index bd438062a6db..baedc7186b10 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -196,7 +196,7 @@ ath_tid_pull(struct ath_atx_tid *tid)
}
return skb;
- }
+}
static struct sk_buff *ath_tid_dequeue(struct ath_atx_tid *tid)
{
diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c
index 5a681962899c..4c38904a8a32 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -492,7 +492,7 @@ static void eeepc_platform_exit(struct eeepc_laptop *eeepc)
* potentially bad time, such as a timer interrupt.
*/
static void tpd_led_update(struct work_struct *work)
- {
+{
struct eeepc_laptop *eeepc;
eeepc = container_of(work, struct eeepc_laptop, tpd_led_work);
diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c
index a319bf1e49de..ef5c16dfabfa 100644
--- a/drivers/rtc/rtc-ab-b5ze-s3.c
+++ b/drivers/rtc/rtc-ab-b5ze-s3.c
@@ -648,7 +648,7 @@ static int abb5zes3_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alarm)
ret);
return ret;
- }
+}
/* Enable or disable battery low irq generation */
static inline int _abb5zes3_rtc_battery_low_irq_enable(struct regmap *regmap,
diff --git a/drivers/scsi/dpt_i2o.c b/drivers/scsi/dpt_i2o.c
index fd172b0890d3..a00d822e3142 100644
--- a/drivers/scsi/dpt_i2o.c
+++ b/drivers/scsi/dpt_i2o.c
@@ -3524,7 +3524,7 @@ static int adpt_i2o_systab_send(adpt_hba* pHba)
#endif
return ret;
- }
+}
/*============================================================================
diff --git a/drivers/scsi/sym53c8xx_2/sym_glue.c b/drivers/scsi/sym53c8xx_2/sym_glue.c
index 791a2182de53..7320d5fe4cbc 100644
--- a/drivers/scsi/sym53c8xx_2/sym_glue.c
+++ b/drivers/scsi/sym53c8xx_2/sym_glue.c
@@ -1393,7 +1393,7 @@ static struct Scsi_Host *sym_attach(struct scsi_host_template *tpnt, int unit,
scsi_host_put(shost);
return NULL;
- }
+}
/*
diff --git a/fs/locks.c b/fs/locks.c
index 21b4dfa289ee..d2399d001afe 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -559,7 +559,7 @@ static const struct lock_manager_operations lease_manager_ops = {
* Initialize a lease, use the default lock manager operations
*/
static int lease_init(struct file *filp, long type, struct file_lock *fl)
- {
+{
if (assign_type(fl, type) != 0)
return -EINVAL;
diff --git a/fs/ocfs2/stack_user.c b/fs/ocfs2/stack_user.c
index dae9eb7c441e..d2fb97b173da 100644
--- a/fs/ocfs2/stack_user.c
+++ b/fs/ocfs2/stack_user.c
@@ -398,7 +398,7 @@ static int ocfs2_control_do_setnode_msg(struct file *file,
static int ocfs2_control_do_setversion_msg(struct file *file,
struct ocfs2_control_message_setv *msg)
- {
+{
long major, minor;
char *ptr = NULL;
struct ocfs2_control_private *p = file->private_data;
diff --git a/fs/xfs/libxfs/xfs_alloc.c b/fs/xfs/libxfs/xfs_alloc.c
index 0da80019a917..217108f765d5 100644
--- a/fs/xfs/libxfs/xfs_alloc.c
+++ b/fs/xfs/libxfs/xfs_alloc.c
@@ -2401,7 +2401,7 @@ static bool
xfs_agf_verify(
struct xfs_mount *mp,
struct xfs_buf *bp)
- {
+{
struct xfs_agf *agf = XFS_BUF_TO_AGF(bp);
if (xfs_sb_version_hascrc(&mp->m_sb)) {
@@ -2449,8 +2449,7 @@ xfs_agf_verify(
be32_to_cpu(agf->agf_refcount_level) > XFS_BTREE_MAXLEVELS))
return false;
- return true;;
-
+ return true;
}
static void
diff --git a/fs/xfs/xfs_export.c b/fs/xfs/xfs_export.c
index fe1bfee35898..7d5c355d78b5 100644
--- a/fs/xfs/xfs_export.c
+++ b/fs/xfs/xfs_export.c
@@ -122,7 +122,7 @@ xfs_nfs_get_inode(
struct super_block *sb,
u64 ino,
u32 generation)
- {
+{
xfs_mount_t *mp = XFS_M(sb);
xfs_inode_t *ip;
int error;
diff --git a/kernel/audit.c b/kernel/audit.c
index 227db99b0f19..d97e8f0f73ca 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -443,15 +443,15 @@ static int audit_set_failure(u32 state)
* Drop any references inside the auditd connection tracking struct and free
* the memory.
*/
- static void auditd_conn_free(struct rcu_head *rcu)
- {
+static void auditd_conn_free(struct rcu_head *rcu)
+{
struct auditd_connection *ac;
ac = container_of(rcu, struct auditd_connection, rcu);
put_pid(ac->pid);
put_net(ac->net);
kfree(ac);
- }
+}
/**
* auditd_set - Set/Reset the auditd connection state
diff --git a/kernel/trace/trace_printk.c b/kernel/trace/trace_printk.c
index ad1d6164e946..50f44b7b2b32 100644
--- a/kernel/trace/trace_printk.c
+++ b/kernel/trace/trace_printk.c
@@ -196,7 +196,7 @@ struct notifier_block module_trace_bprintk_format_nb = {
};
int __trace_bprintk(unsigned long ip, const char *fmt, ...)
- {
+{
int ret;
va_list ap;
@@ -214,7 +214,7 @@ int __trace_bprintk(unsigned long ip, const char *fmt, ...)
EXPORT_SYMBOL_GPL(__trace_bprintk);
int __ftrace_vbprintk(unsigned long ip, const char *fmt, va_list ap)
- {
+{
if (unlikely(!fmt))
return 0;
diff --git a/lib/raid6/sse2.c b/lib/raid6/sse2.c
index 1d2276b007ee..8191e1d0d2fb 100644
--- a/lib/raid6/sse2.c
+++ b/lib/raid6/sse2.c
@@ -91,7 +91,7 @@ static void raid6_sse21_gen_syndrome(int disks, size_t bytes, void **ptrs)
static void raid6_sse21_xor_syndrome(int disks, int start, int stop,
size_t bytes, void **ptrs)
- {
+{
u8 **dptr = (u8 **)ptrs;
u8 *p, *q;
int d, z, z0;
@@ -200,9 +200,9 @@ static void raid6_sse22_gen_syndrome(int disks, size_t bytes, void **ptrs)
kernel_fpu_end();
}
- static void raid6_sse22_xor_syndrome(int disks, int start, int stop,
+static void raid6_sse22_xor_syndrome(int disks, int start, int stop,
size_t bytes, void **ptrs)
- {
+{
u8 **dptr = (u8 **)ptrs;
u8 *p, *q;
int d, z, z0;
@@ -265,7 +265,7 @@ static void raid6_sse22_gen_syndrome(int disks, size_t bytes, void **ptrs)
asm volatile("sfence" : : : "memory");
kernel_fpu_end();
- }
+}
const struct raid6_calls raid6_sse2x2 = {
raid6_sse22_gen_syndrome,
@@ -366,9 +366,9 @@ static void raid6_sse24_gen_syndrome(int disks, size_t bytes, void **ptrs)
kernel_fpu_end();
}
- static void raid6_sse24_xor_syndrome(int disks, int start, int stop,
+static void raid6_sse24_xor_syndrome(int disks, int start, int stop,
size_t bytes, void **ptrs)
- {
+{
u8 **dptr = (u8 **)ptrs;
u8 *p, *q;
int d, z, z0;
@@ -471,7 +471,7 @@ static void raid6_sse24_gen_syndrome(int disks, size_t bytes, void **ptrs)
}
asm volatile("sfence" : : : "memory");
kernel_fpu_end();
- }
+}
const struct raid6_calls raid6_sse2x4 = {
diff --git a/sound/soc/fsl/fsl_dma.c b/sound/soc/fsl/fsl_dma.c
index 0c11f434a374..ec619f51d336 100644
--- a/sound/soc/fsl/fsl_dma.c
+++ b/sound/soc/fsl/fsl_dma.c
@@ -879,7 +879,7 @@ static const struct snd_pcm_ops fsl_dma_ops = {
};
static int fsl_soc_dma_probe(struct platform_device *pdev)
- {
+{
struct dma_object *dma;
struct device_node *np = pdev->dev.of_node;
struct device_node *ssi_np;
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* pull-request: bpf-next 2017-12-18
From: Daniel Borkmann @ 2017-12-18 0:33 UTC (permalink / raw)
To: davem; +Cc: daniel, ast, netdev
Hi David,
The following pull-request contains BPF updates for your *net-next* tree.
The main changes are:
1) Allow arbitrary function calls from one BPF function to another BPF function.
As of today when writing BPF programs, __always_inline had to be used in
the BPF C programs for all functions, unnecessarily causing LLVM to inflate
code size. Handle this more naturally with support for BPF to BPF calls
such that this __always_inline restriction can be overcome. As a result,
it allows for better optimized code and finally enables to introduce core
BPF libraries in the future that can be reused out of different projects.
x86 and arm64 JIT support was added as well, from Alexei.
2) Add infrastructure for tagging functions as error injectable and allow for
BPF to return arbitrary error values when BPF is attached via kprobes on
those. This way of injecting errors generically eases testing and debugging
without having to recompile or restart the kernel. Tags for opting-in for
this facility are added with BPF_ALLOW_ERROR_INJECTION(), from Josef.
3) For BPF offload via nfp JIT, add support for bpf_xdp_adjust_head() helper
call for XDP programs. First part of this work adds handling of BPF
capabilities included in the firmware, and the later patches add support
to the nfp verifier part and JIT as well as some small optimizations,
from Jakub.
4) The bpftool now also gets support for basic cgroup BPF operations such
as attaching, detaching and listing current BPF programs. As a requirement
for the attach part, bpftool can now also load object files through
'bpftool prog load'. This reuses libbpf which we have in the kernel tree
as well. bpftool-cgroup man page is added along with it, from Roman.
5) Back then commit e87c6bc3852b ("bpf: permit multiple bpf attachments for
a single perf event") added support for attaching multiple BPF programs
to a single perf event. Given they are configured through perf's ioctl()
interface, the interface has been extended with a PERF_EVENT_IOC_QUERY_BPF
command in this work in order to return an array of one or multiple BPF
prog ids that are currently attached, from Yonghong.
6) Various minor fixes and cleanups to the bpftool's Makefile as well
as a new 'uninstall' and 'doc-uninstall' target for removing bpftool
itself or prior installed documentation related to it, from Quentin.
7) Add CONFIG_CGROUP_BPF=y to the BPF kernel selftest config file which is
required for the test_dev_cgroup test case to run, from Naresh.
8) Fix reporting of XDP prog_flags for nfp driver, from Jakub.
9) Fix libbpf's exit code from the Makefile when libelf was not found in
the system, also from Jakub.
Please consider pulling these changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
Thanks a lot!
----------------------------------------------------------------
The following changes since commit 62cd277039a3413604f486f0ca87faec810d7bb7:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next (2017-12-08 10:48:25 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
for you to fetch changes up to 46df3d209db080395a98fc0875bd05e45e8f44e0:
trace: reenable preemption if we modify the ip (2017-12-17 20:47:32 +0100)
----------------------------------------------------------------
Alexei Starovoitov (14):
Merge branch 'bpf-tracing-multiprog-tp-query'
Merge branch 'bpf-override-return'
bpf: introduce function calls (function boundaries)
bpf: introduce function calls (verification)
selftests/bpf: add verifier tests for bpf_call
bpf: teach verifier to recognize zero initialized stack
selftests/bpf: add tests for stack_zero tracking
libbpf: add support for bpf_call
selftests/bpf: add bpf_call test
selftests/bpf: add xdp noinline test
bpf: add support for bpf_call to interpreter
bpf: fix net.core.bpf_jit_enable race
bpf: x64: add JIT support for multi-function programs
bpf: arm64: add JIT support for multi-function programs
Daniel Borkmann (5):
Merge branch 'bpf-bpftool-makefile-cleanups'
Merge branch 'bpf-bpftool-cgroup-ops'
Merge branch 'bpf-nfp-jit-adjust-head-support'
selftests/bpf: additional bpf_call tests
Merge branch 'bpf-to-bpf-function-calls'
Jakub Kicinski (8):
nfp: add nfp_cpp_area_size() accessor
nfp: bpf: prepare for parsing BPF FW capabilities
nfp: bpf: prepare for call support
nfp: bpf: add basic support for adjust head call
nfp: bpf: optimize the adjust_head calls in trivial cases
nfp: bpf: correct printk formats for size_t
libbpf: fix Makefile exit code if libelf not found
nfp: set flags in the correct member of netdev_bpf
Josef Bacik (6):
add infrastructure for tagging functions as error injectable
btrfs: make open_ctree error injectable
bpf: add a bpf_override_function helper
samples/bpf: add a test for bpf_override_return
btrfs: allow us to inject errors at io_ctl_init
trace: reenable preemption if we modify the ip
Naresh Kamboju (1):
selftests: bpf: Adding config fragment CONFIG_CGROUP_BPF=y
Quentin Monnet (2):
tools: bpftool: harmonise Makefile and Documentation/Makefile
tools: bpftool: create "uninstall", "doc-uninstall" make targets
Roman Gushchin (4):
libbpf: add ability to guess program type based on section name
libbpf: prefer global symbols as bpf program name source
bpftool: implement prog load command
bpftool: implement cgroup bpf operations
Yonghong Song (3):
bpf/tracing: allow user space to query prog array on the same tp
bpf/tracing: add a bpf test for new ioctl query interface
bpf/tracing: fix kernel/events/core.c compilation error
arch/Kconfig | 3 +
arch/arm/net/bpf_jit_32.c | 2 +-
arch/arm64/net/bpf_jit_comp.c | 70 +-
arch/mips/net/ebpf_jit.c | 2 +-
arch/powerpc/net/bpf_jit_comp64.c | 2 +-
arch/s390/net/bpf_jit_comp.c | 2 +-
arch/sparc/net/bpf_jit_comp_64.c | 2 +-
arch/x86/Kconfig | 1 +
arch/x86/include/asm/kprobes.h | 4 +
arch/x86/include/asm/ptrace.h | 5 +
arch/x86/kernel/kprobes/ftrace.c | 14 +
arch/x86/net/bpf_jit_comp.c | 49 +-
drivers/net/ethernet/netronome/nfp/bpf/fw.h | 54 +
drivers/net/ethernet/netronome/nfp/bpf/jit.c | 107 ++
drivers/net/ethernet/netronome/nfp/bpf/main.c | 115 ++
drivers/net/ethernet/netronome/nfp/bpf/main.h | 30 +
drivers/net/ethernet/netronome/nfp/bpf/offload.c | 2 +
drivers/net/ethernet/netronome/nfp/bpf/verifier.c | 70 +
drivers/net/ethernet/netronome/nfp/nfp_asm.h | 2 +
.../net/ethernet/netronome/nfp/nfp_net_common.c | 2 +-
.../net/ethernet/netronome/nfp/nfpcore/nfp_cpp.h | 1 +
.../ethernet/netronome/nfp/nfpcore/nfp_cppcore.c | 11 +
fs/btrfs/disk-io.c | 2 +
fs/btrfs/free-space-cache.c | 2 +
include/asm-generic/vmlinux.lds.h | 10 +
include/linux/bpf.h | 18 +
include/linux/bpf_verifier.h | 45 +-
include/linux/filter.h | 16 +-
include/linux/kprobes.h | 1 +
include/linux/module.h | 5 +
include/linux/trace_events.h | 7 +
include/uapi/linux/bpf.h | 13 +-
include/uapi/linux/perf_event.h | 22 +
kernel/bpf/core.c | 128 +-
kernel/bpf/disasm.c | 8 +-
kernel/bpf/syscall.c | 3 +-
kernel/bpf/verifier.c | 1122 +++++++++++---
kernel/events/core.c | 10 +
kernel/kprobes.c | 163 ++
kernel/module.c | 6 +-
kernel/trace/Kconfig | 11 +
kernel/trace/bpf_trace.c | 58 +
kernel/trace/trace_kprobe.c | 64 +-
kernel/trace/trace_probe.h | 12 +
samples/bpf/Makefile | 4 +
samples/bpf/test_override_return.sh | 15 +
samples/bpf/tracex7_kern.c | 16 +
samples/bpf/tracex7_user.c | 28 +
tools/bpf/bpftool/Documentation/Makefile | 30 +-
tools/bpf/bpftool/Documentation/bpftool-cgroup.rst | 118 ++
tools/bpf/bpftool/Documentation/bpftool-map.rst | 2 +-
tools/bpf/bpftool/Documentation/bpftool-prog.rst | 12 +-
tools/bpf/bpftool/Documentation/bpftool.rst | 8 +-
tools/bpf/bpftool/Makefile | 61 +-
tools/bpf/bpftool/cgroup.c | 307 ++++
tools/bpf/bpftool/common.c | 71 +-
tools/bpf/bpftool/main.c | 3 +-
tools/bpf/bpftool/main.h | 2 +
tools/bpf/bpftool/prog.c | 29 +-
tools/include/uapi/linux/bpf.h | 13 +-
tools/include/uapi/linux/perf_event.h | 22 +
tools/lib/bpf/Makefile | 4 +-
tools/lib/bpf/bpf.h | 2 +-
tools/lib/bpf/libbpf.c | 199 ++-
tools/scripts/Makefile.include | 1 +
tools/testing/selftests/bpf/Makefile | 12 +-
tools/testing/selftests/bpf/bpf_helpers.h | 3 +-
tools/testing/selftests/bpf/config | 1 +
tools/testing/selftests/bpf/test_l4lb_noinline.c | 473 ++++++
tools/testing/selftests/bpf/test_progs.c | 228 ++-
tools/testing/selftests/bpf/test_tracepoint.c | 26 +
tools/testing/selftests/bpf/test_verifier.c | 1624 +++++++++++++++++++-
tools/testing/selftests/bpf/test_xdp_noinline.c | 833 ++++++++++
73 files changed, 6071 insertions(+), 352 deletions(-)
create mode 100644 drivers/net/ethernet/netronome/nfp/bpf/fw.h
create mode 100755 samples/bpf/test_override_return.sh
create mode 100644 samples/bpf/tracex7_kern.c
create mode 100644 samples/bpf/tracex7_user.c
create mode 100644 tools/bpf/bpftool/Documentation/bpftool-cgroup.rst
create mode 100644 tools/bpf/bpftool/cgroup.c
create mode 100644 tools/testing/selftests/bpf/test_l4lb_noinline.c
create mode 100644 tools/testing/selftests/bpf/test_tracepoint.c
create mode 100644 tools/testing/selftests/bpf/test_xdp_noinline.c
^ permalink raw reply
* Re: [PATCH 2/3] vsprintf: print <no-symbol> if symbol not found
From: Tobin C. Harding @ 2017-12-18 1:04 UTC (permalink / raw)
To: Joe Perches
Cc: kernel-hardening, Steven Rostedt, Tycho Andersen, Linus Torvalds,
Kees Cook, Andrew Morton, Daniel Borkmann, Masahiro Yamada,
Alexei Starovoitov, linux-kernel, Network Development
In-Reply-To: <1513555454.31581.43.camel@perches.com>
On Sun, Dec 17, 2017 at 04:04:14PM -0800, Joe Perches wrote:
> On Mon, 2017-12-18 at 10:53 +1100, Tobin C. Harding wrote:
> > Depends on: commit bd6b239cdbb2 ("kallsyms: don't leak address when
> > symbol not found")
> >
> > Currently vsprintf for specifiers %p[SsB] relies on the behaviour of
> > kallsyms (sprint_symbol()) and prints the actual address if a symbol is
> > not found. Previous patch changes this behaviour so tha sprint_symbol()
>
> tha->that
>
> > returns an error if symbol not found. With this patch in place we can
> > print a sanitized message '<no-symbol>' instead of leaking the address.
> >
> > Print '<no-symbol>' for printk specifier %s[sSB] if no symbol is found.
>
> %s->%ps
>
> > diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> []
> > @@ -460,6 +460,8 @@ char *kvasprintf(gfp_t gfp, const char *fmt, va_list args);
> > extern __printf(2, 0)
> > const char *kvasprintf_const(gfp_t gfp, const char *fmt, va_list args);
> >
> > +extern int string_is_no_symbol(const char *s);
> > +
> []
> > diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> >
> > +#define PRINTK_NO_SYMBOL_STR "<no-symbol>"
>
> "<symbol unavailable>" ? "not found"?
<symbol not found>?
> []
>
> > +int string_is_no_symbol(const char *s)
> > +{
> > + return !!strstr(s, PRINTK_NO_SYMBOL_STR);
> > +}
> > +EXPORT_SYMBOL(string_is_no_symbol);
>
> Why should string_is_no_symbol be exported?
I ummed and ahhed about this. By your comment I'm guessing I made the
wrong choice. The idea behind exporting the symbol was so users of
vsprintf could have a way to see if the symbol was found or not without
having to know what string was actually printed.
I'll remove it for v3 and implement your other suggestions.
thanks for the review,
Tobin.
^ permalink raw reply
* RE: [patch iproute2] tc: fix command "tc actions del" hang issue
From: Chris Mi @ 2017-12-18 1:41 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev@vger.kernel.org, jiri@resnulli.us
In-Reply-To: <20171214211658.40eb8290@xeon-e3>
> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Friday, December 15, 2017 1:17 PM
> To: Chris Mi <chrism@mellanox.com>
> Cc: netdev@vger.kernel.org; jiri@resnulli.us
> Subject: Re: [patch iproute2] tc: fix command "tc actions del" hang issue
>
> On Thu, 14 Dec 2017 18:09:00 +0900
> Chris Mi <chrism@mellanox.com> wrote:
>
> > If command is RTM_DELACTION, a non-NULL pointer is passed to rtnl_talk().
> > Then flag NLM_F_ACK is not set on n->nlmsg_flags and netlink_ack()
> > will not be called. Command tc will wait for the reply for ever.
> >
> > Fixes: 86bf43c7c2fd ("lib/libnetlink: update rtnl_talk to support
> > malloc buff at run time")
> > Signed-off-by: Chris Mi <chrism@mellanox.com>
> > Reviewed-by: Jiri Pirko <jiri@mellanox.com>
>
> Thanks for fixing this.
> Applied, but please don't linewrap the fixes tag.
Thank for fixing it. I'll pay attention to it next time.
^ permalink raw reply
* Re: [PATCH net] net: bridge: fix early call to br_stp_change_bridge_id
From: Toshiaki Makita @ 2017-12-18 2:24 UTC (permalink / raw)
To: Nikolay Aleksandrov, netdev; +Cc: bridge, roopa, avagin, davem
In-Reply-To: <1513423896-30294-1-git-send-email-nikolay@cumulusnetworks.com>
On 2017/12/16 20:31, Nikolay Aleksandrov wrote:
> The early call to br_stp_change_bridge_id in bridge's newlink can cause
> a memory leak if an error occurs during the newlink because the fdb
> entries are not cleaned up if a different lladdr was specified, also
> another minor issue is that it generates fdb notifications with
> ifindex = 0. To remove this special case the call is done after netdev
> register and we cleanup any bridge fdb entries on changelink error.
> That also doesn't slow down normal bridge removal, alternative is to call
> it in its ndo_uninit.
...
> Fixes: a4b816d8ba1c ("bridge: Change local fdb entries whenever mac address of bridge device changes")
> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
> ---
> Consequently this also would fix the null ptr deref due to the rhashtable
> not being initialized in net-next when br_stp_change_bridge_id is called.
>
> Toshiaki, any reason you called br_stp_change_bridge_id before
> register_netdevice when you introduced it in 30313a3d5794 ?
Thank you for taking care of this.
It's my bad. I just missed the problem.
> net/bridge/br_netlink.c | 14 +++++++++-----
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
> index d0ef0a8e8831..b0362cadb7c8 100644
> --- a/net/bridge/br_netlink.c
> +++ b/net/bridge/br_netlink.c
> @@ -1262,19 +1262,23 @@ static int br_dev_newlink(struct net *src_net, struct net_device *dev,
...
> err = br_changelink(dev, tb, data, extack);
> - if (err)
> + if (err) {
> + /* clean possible fdbs from br_stp_change_bridge_id above */
> + br_fdb_delete_by_port(br, NULL, 0, 1);
Don't we need to call br_dev_delete (br_link_ops.dellink) after
successful register instead of br_fdb_delete?
Particularly I'm wondering if not calling br_sysfs_delbr() is ok or not.
--
Toshiaki Makita
^ permalink raw reply
* [Patch v2] net: phy: marvell: Limit 88m1101 autoneg errata to 88E1145 as well.
From: Zhao Qiang @ 2017-12-18 2:26 UTC (permalink / raw)
To: davem; +Cc: netdev, Zhao Qiang
88E1145 also need this autoneg errata.
Fixes: f2899788353c ("net: phy: marvell: Limit errata to 88m1101")
Signed-off-by: Zhao Qiang <qiang.zhao@nxp.com>
---
Changes for v2
- modify the commit msg in a proper way.
drivers/net/phy/marvell.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 4d02b27..a3f456b 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -2069,7 +2069,7 @@ static int m88e1510_probe(struct phy_device *phydev)
.flags = PHY_HAS_INTERRUPT,
.probe = marvell_probe,
.config_init = &m88e1145_config_init,
- .config_aneg = &marvell_config_aneg,
+ .config_aneg = &m88e1101_config_aneg,
.read_status = &genphy_read_status,
.ack_interrupt = &marvell_ack_interrupt,
.config_intr = &marvell_config_intr,
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] net: phy: xgene: disable clk on error paths
From: Quan Nguyen @ 2017-12-18 3:12 UTC (permalink / raw)
To: Alexey Khoroshilov
Cc: Iyappan Subramanian, Keyur Chudgar, netdev, linux-kernel,
ldv-project
In-Reply-To: <1513374759-21384-1-git-send-email-khoroshilov@ispras.ru>
On Sat, Dec 16, 2017 at 4:52 AM, Alexey Khoroshilov
<khoroshilov@ispras.ru> wrote:
>
> There are several error paths in xgene_mdio_probe(),
> where clk is left undisabled. The patch fixes them.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
> ---
> drivers/net/phy/mdio-xgene.c | 21 +++++++++++++++------
> 1 file changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/phy/mdio-xgene.c b/drivers/net/phy/mdio-xgene.c
> index bfd3090fb055..07c6048200c6 100644
> --- a/drivers/net/phy/mdio-xgene.c
> +++ b/drivers/net/phy/mdio-xgene.c
> @@ -194,8 +194,11 @@ static int xgene_mdio_reset(struct xgene_mdio_pdata *pdata)
> }
>
> ret = xgene_enet_ecc_init(pdata);
> - if (ret)
> + if (ret) {
> + if (pdata->dev->of_node)
> + clk_disable_unprepare(pdata->clk);
> return ret;
> + }
> xgene_gmac_reset(pdata);
>
> return 0;
> @@ -388,8 +391,10 @@ static int xgene_mdio_probe(struct platform_device *pdev)
> return ret;
>
> mdio_bus = mdiobus_alloc();
> - if (!mdio_bus)
> - return -ENOMEM;
> + if (!mdio_bus) {
> + ret = -ENOMEM;
> + goto out_clk;
> + }
>
> mdio_bus->name = "APM X-Gene MDIO bus";
>
> @@ -418,7 +423,7 @@ static int xgene_mdio_probe(struct platform_device *pdev)
> mdio_bus->phy_mask = ~0;
> ret = mdiobus_register(mdio_bus);
> if (ret)
> - goto out;
> + goto out_mdiobus;
>
> acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_HANDLE(dev), 1,
> acpi_register_phy, NULL, mdio_bus, NULL);
> @@ -426,16 +431,20 @@ static int xgene_mdio_probe(struct platform_device *pdev)
> }
>
> if (ret)
> - goto out;
> + goto out_mdiobus;
>
> pdata->mdio_bus = mdio_bus;
> xgene_mdio_status = true;
>
> return 0;
>
> -out:
> +out_mdiobus:
> mdiobus_free(mdio_bus);
>
> +out_clk:
> + if (dev->of_node)
> + clk_disable_unprepare(pdata->clk);
> +
> return ret;
> }
>
Acked.
^ permalink raw reply
* Re: [PATCH net-next v6 2/2] net: ethernet: socionext: add AVE ethernet driver
From: Kunihiko Hayashi @ 2017-12-18 3:51 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, andrew-g2DYL2Zd6BY,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A,
masami.hiramatsu-QSEj5FYQhm4dnm+yROfE0A,
jaswinder.singh-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <20171215.125749.1752831437819486183.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Hello David,
On Fri, 15 Dec 2017 12:57:49 -0500 David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote:
> From: Kunihiko Hayashi <hayashi.kunihiko-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
> Date: Thu, 14 Dec 2017 19:05:10 +0900
>
> > +static void ave_desc_write(struct net_device *ndev, enum desc_id id,
> > + int entry, int offset, u32 val)
> > +{
> > + struct ave_private *priv = netdev_priv(ndev);
> > + u32 addr = (id == AVE_DESCID_TX) ? priv->tx.daddr : priv->rx.daddr;
>
> Please always order local variables from longest to shortest line.
>
> Audit your entire submission for this issue, thank you.
I see. I'll fix the order of local variables.
> > + ret = register_netdev(ndev);
> > + if (ret) {
> > + dev_err(dev, "failed to register netdevice\n");
> > + goto out_del_napi;
> > + }
> > +
> > + platform_set_drvdata(pdev, ndev);
>
> You must make all software state settings before reigster_netdev() is
> invoked.
>
> At the exact moment you call register_netdev(), your device can be
> brought up, interrupts processed, PHY state changes made, etc.
>
> So you must put this platform_set_drvdata() before the
> register_netdev() call.
>
> Generally speaking, register_netdev() must always be the last state
> modification done by your probe routine.
Indeed. It's not good to invoke register_netdev() with all software
initialization not completed. I'll move register_netdev() after
all initialization.
Thank you,
---
Best Regards,
Kunihiko Hayashi
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [net-next] phylib: Add device reset GPIO support causes DSA MT7530 acquires reset-gpios fails
From: Sean Wang @ 2017-12-18 4:01 UTC (permalink / raw)
To: Andrew Lunn
Cc: sergei.shtylyov, f.fainelli, vivien.didelot, davem, netdev,
linux-kernel, linux-mediatek, richard.leitner, geert+renesas
In-Reply-To: <20171215101014.GB4213@lunn.ch>
On Fri, 2017-12-15 at 11:10 +0100, Andrew Lunn wrote:
> On Fri, Dec 15, 2017 at 02:55:03PM +0800, Sean Wang wrote:
> > Hi Sergei,
> >
> > Recently I found the patch commit bafbdd527d56 (phylib: Add device reset
> > GPIO support) would have the impact on MT7530 driver. Which causes the
> > DSA MT7530 device (it's the child node under mdio bus) gets the
> > reset-gpios fails because the same GPIO seems already be held in the
> > earlier mdiobus_register_device call patched through the commit.
> >
> > do you have any idea how the commits also considers DSA case ?
> >
> > I guessed the DSA lan9303, mv88e8 switch should have the same issue
> > since they have the same GPIO name as mdiobus_register_device required.
>
> Hi Sean
>
> Ah, not good :-(
>
> I _think_ for the mv88e6xxx, we can remove the gpio reset code from
> the driver, and let the mdio core do it. I need to test to be sure.
>
> Would that work for you?
>
> Andrew
>
It probably can't. Because before the GPIO line is manipulated to reset,
certain power control should be handled such as power sources from
external PMIC to let devices actually enter the proper state.
So, I thought the kind of reset should be better controlled by the
specific driver, not by generic core.
Sean
^ 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