1. Jan 06, 2018
    • James Chapman's avatar
      l2tp: remove configurable payload offset · 900631ee
      James Chapman authored
      
      
      If L2TP_ATTR_OFFSET is set to a non-zero value in L2TPv3 tunnels, it
      results in L2TPv3 packets being transmitted which might not be
      compliant with the L2TPv3 RFC. This patch has l2tp ignore the offset
      setting and send all packets with no offset.
      
      In more detail:
      
      L2TPv2 supports a variable offset from the L2TPv2 header to the
      payload. The offset value is indicated by an optional field in the
      L2TP header.  Our L2TP implementation already detects the presence of
      the optional offset and skips that many bytes when handling data
      received packets. All transmitted packets are always transmitted with
      no offset.
      
      L2TPv3 has no optional offset field in the L2TPv3 packet
      header. Instead, L2TPv3 defines optional fields in a "Layer-2 Specific
      Sublayer". At the time when the original L2TP code was written, there
      was talk at IETF of offset being implemented in a new Layer-2 Specific
      Sublayer. A L2TP_ATTR_OFFSET netlink attribute was added so that this
      offset could be configured and the intention was to allow it to be
      also used to set the tx offset for L2TPv2. However, no L2TPv3 offset
      was ever specified and the L2TP_ATTR_OFFSET parameter was forgotten
      about.
      
      Setting L2TP_ATTR_OFFSET results in L2TPv3 packets being transmitted
      with the specified number of bytes padding between L2TPv3 header and
      payload. This is not compliant with L2TPv3 RFC3931. This change
      removes the configurable offset altogether while retaining
      L2TP_ATTR_OFFSET for backwards compatibility. Any L2TP_ATTR_OFFSET
      value is ignored.
      
      Signed-off-by: default avatarJames Chapman <jchapman@katalix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      900631ee
    • James Chapman's avatar
      l2tp: revert "l2tp: fix missing print session offset info" · de3b58bc
      James Chapman authored
      Revert commit 820da535
      
       ("l2tp: fix missing print session offset
      info").  The peer_offset parameter is removed.
      
      Signed-off-by: default avatarJames Chapman <jchapman@katalix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      de3b58bc
    • James Chapman's avatar
      l2tp: revert "l2tp: add peer_offset parameter" · 863def15
      James Chapman authored
      Revert commit f15bc54e
      
       ("l2tp: add peer_offset parameter"). This
      is removed because it is adding another configurable offset and
      configurable offsets are being removed.
      
      Signed-off-by: default avatarJames Chapman <jchapman@katalix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      863def15
  2. Jan 05, 2018
  3. Jan 04, 2018
    • Peter Große's avatar
      mac80211: Fix setting TX power on monitor interfaces · 3a3713ec
      Peter Große authored
      
      
      Instead of calling ieee80211_recalc_txpower on monitor interfaces
      directly, call it using the virtual monitor interface, if one exists.
      
      In case of a single monitor interface given, reject setting TX power,
      if no virtual monitor interface exists.
      
      That being checked, don't warn in ieee80211_bss_info_change_notify,
      after setting TX power on a monitor interface.
      
      Fixes warning:
      ------------[ cut here ]------------
       WARNING: CPU: 0 PID: 2193 at net/mac80211/driver-ops.h:167
       ieee80211_bss_info_change_notify+0x111/0x190 Modules linked in: uvcvideo
       videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core
      rndis_host cdc_ether usbnet mii tp_smapi(O) thinkpad_ec(O) ohci_hcd vboxpci(O)
       vboxnetadp(O) vboxnetflt(O) v boxdrv(O) x86_pkg_temp_thermal kvm_intel kvm
       irqbypass iwldvm iwlwifi ehci_pci ehci_hcd tpm_tis tpm_tis_core tpm CPU: 0
       PID: 2193 Comm: iw Tainted: G           O    4.12.12-gentoo #2 task:
       ffff880186fd5cc0 task.stack: ffffc90001b54000 RIP:
       0010:ieee80211_bss_info_change_notify+0x111/0x190 RSP: 0018:ffffc90001b57a10
       EFLAGS: 00010246 RAX: 0000000000000006 RBX: ffff8801052ce840 RCX:
       0000000000000064 RDX: 00000000fffffffc RSI: 0000000000040000 RDI:
       ffff8801052ce840 RBP: ffffc90001b57a38 R08: 0000000000000062 R09:
       0000000000000000 R10: ffff8802144b5000 R11: ffff880049dc4614 R12:
       0000000000040000 R13: 0000000000000064 R14: ffff8802105f0760 R15:
       ffffc90001b57b48 FS:  00007f92644b4580(0000) GS:ffff88021e200000(0000)
       knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 00007f9263c109f0 CR3: 00000001df850000 CR4: 00000000000406f0
       Call Trace:
        ieee80211_recalc_txpower+0x33/0x40
        ieee80211_set_tx_power+0x40/0x180
        nl80211_set_wiphy+0x32e/0x950
      
      Reported-by: default avatarPeter Große <pegro@friiks.de>
      Signed-off-by: default avatarPeter Große <pegro@friiks.de>
      
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      3a3713ec
    • David S. Miller's avatar
      Merge branch 'nfp-flower-repr-link-state' · 4b24dd80
      David S. Miller authored
      
      
      Jakub Kicinski says:
      
      ====================
      nfp: flower: repr link state
      
      Dirk says:
      
      This series provides two updates towards the link state of reprs in
      the flower nfp app.
      
      Patch #1 improves the way link state is reported for reprs. Instead of
      starting with an assumed 'UP' state, always assume the link state is
      'DOWN' and then modify this only on events received from firmware.
      
      Patch #2 adds a new nfp_app hook, repr_preclean. This callback is
      executed before reprs are removed from the app context and is executed
      per repr.
      
      Patch #3 implements the new REIFY control message, used to indicate
      when reprs are created and destroyed. Firmware uses these messages
      to prevent communication about any particular port when the driver
      doesn't know about the repr yet or anymore.
      ====================
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4b24dd80
    • Dirk van der Merwe's avatar
      nfp: flower: implement the PORT_REIFY message · d2c2928d
      Dirk van der Merwe authored
      
      
      The PORT_REIFY message indicates whether reprs have been created or
      when they are about to be destroyed. This is necessary so firmware
      can know which state the driver is in, e.g. the firmware will not send
      any control messages related to ports when the reprs are destroyed.
      
      This prevents nuisance warning messages printed whenever the firmware
      sends updates for non-existent reprs.
      
      Signed-off-by: default avatarDirk van der Merwe <dirk.vandermerwe@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d2c2928d
    • Dirk van der Merwe's avatar
      nfp: add repr_preclean callback · 0f084791
      Dirk van der Merwe authored
      
      
      Just before a repr is cleaned up, we give the app a chance to perform
      some preclean configuration while the reprs pointer is still configured
      for the app.
      
      Signed-off-by: default avatarDirk van der Merwe <dirk.vandermerwe@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0f084791
    • Dirk van der Merwe's avatar
      nfp: flower: obtain repr link state only from firmware · c6d20ab4
      Dirk van der Merwe authored
      
      
      Instead of starting up reprs assuming that there is link, only respond
      to the link state reported by firmware.
      
      Furthermore, ensure link is down after repr netdevs are created.
      
      Signed-off-by: default avatarDirk van der Merwe <dirk.vandermerwe@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c6d20ab4
    • Andrew Lunn's avatar
      net: mdio: Only perform gpio reset for PHYs · ee7e16b6
      Andrew Lunn authored
      Ethernet switch on the MDIO bus have historically performed their own
      handling of the GPIO reset line. The resent patch to have the MDIO
      core handle the reset has broken the switch drivers, in that they
      cannot claim the GPIO. Some switch drivers need more control over the
      GPIO line than what the MDIO core provides. So restore the historical
      behaviour by only performing a reset of PHYs, not switches.
      
      Fixes: bafbdd52
      
       ("phylib: Add device reset GPIO support")
      Reported-by: default avatarSean Wang <sean.wang@mediatek.com>
      Signed-off-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Tested-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ee7e16b6
    • David S. Miller's avatar
      Merge branch 'net-Resolve-races-in-phy-accessors' · 318ff60e
      David S. Miller authored
      
      
      Russell King says:
      
      ====================
      Resolve races in phy accessors
      
      This series resolves races with various accesses to PHY registers.
      The first five patches are necessary before we add phylink support
      to mvneta, the remaining three are merely cleanups for unobserved
      races, and hence are less critical.
      
      There are two possible classes of races that can occur: where we
      write to a page register that changes the meaning of a group of
      other registers, and where we read-modify-write a register.
      
      Resolve these races by performing the accesses under the mdio bus
      lock, ensuring that no other user can access the bus while the
      series of atomic operations are being performed.
      
      These patches have been posted before, and have been modified
      along the lines of previous feedback:
      
      - The third patch was originally reviewed by Florian, but as I've
        added __phy_modify() to it, I've removed that attributation.
      - Included generic page-based accessors as suggested last time
        around.
      - Since we have the unlocked __phy_modify() in this patch series,
        it is sensible to include the changes for this to marvell.c -
        these accessors have to change anyway to avoid deadlocks on the
        mdio bus lock.
      
      I haven't been able to test the at803x.c changes yet beyond compile
      testing - although I do have systems with an ar8035 PHY.  However,
      they should be straight forward to review.
      
      This is targetted for net-next because the races have not been
      found in existing drivers, but have been observed with phylink
      integrated into mvneta - that's not to say that the races do not
      exist today, they are just unobserved (probably through lack of
      rigorous enough testing.)  The race provoking condition is detailed
      in patch 5.
      ====================
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      318ff60e
    • Russell King's avatar
      net: phy: convert read-modify-write to phy_modify() · fea23fb5
      Russell King authored
      
      
      Convert read-modify-write sequences in at803x, Marvell and core phylib
      to use phy_modify() to ensure safety.
      
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fea23fb5
    • Russell King's avatar
      net: phy: add phy_modify() accessor · 2b74e5be
      Russell King authored
      
      
      Add phy_modify() convenience accessor to complement the mdiobus
      counterpart.
      
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2b74e5be
    • Russell King's avatar
      net: phy: marvell: fix paged access races · 424ca4c5
      Russell King authored
      
      
      For paged accesses to be truely safe, we need to hold the bus lock to
      prevent anyone else gaining access to the registers while we modify
      them.
      
      The phydev->lock mutex does not do this: userspace via the MII ioctl
      can still sneak in and read or write any register while we are on a
      different page, and the suspend/resume methods can be called by a
      thread different to the thread polling the phy status.
      
      Races have been observed with mvneta on SolidRun Clearfog with phylink,
      particularly between the phylib worker reading the PHYs status, and
      the thread resuming mvneta, calling phy_start() which then calls
      through to m88e1121_config_aneg_rgmii_delays(), which tries to
      read-modify-write the MSCR register:
      
      	CPU0			CPU1
      	marvell_read_status_page()
      	marvell_set_page(phydev, MII_MARVELL_FIBER_PAGE)
      	...
      				m88e1121_config_aneg_rgmii_delays()
      				set_page(MII_MARVELL_MSCR_PAGE)
      				phy_read(phydev, MII_88E1121_PHY_MSCR_REG)
      	marvell_set_page(phydev, MII_MARVELL_COPPER_PAGE);
      	...
      				phy_write(phydev, MII_88E1121_PHY_MSCR_REG)
      
      The result of this is we end up writing the copper page register 21,
      which causes the copper PHY to be disabled, and the link partner sees
      the link immediately go down.
      
      Solve this by taking the bus lock instead of the PHY lock, thereby
      preventing other accesses to the PHY while we are accessing other PHY
      pages.
      
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      424ca4c5
    • Russell King's avatar
      net: phy: add paged phy register accessors · 78ffc4ac
      Russell King authored
      
      
      Add a set of paged phy register accessors which are inherently safe in
      their design against other accesses interfering with the paged access.
      
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      78ffc4ac
    • Russell King's avatar
      net: phy: add unlocked accessors · 788f9933
      Russell King authored
      
      
      Add unlocked versions of the bus accessors, which allows access to the
      bus with all the tracing. These accessors validate that the bus mutex
      is held, which is a basic requirement for all mii bus accesses.
      
      Also added is a read-modify-write unlocked accessor with the same
      locking requirements.
      
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      788f9933
    • Russell King's avatar
      net: phy: use unlocked accessors for indirect MMD accesses · 1b2dea2e
      Russell King authored
      
      
      Use unlocked accessors for indirect MMD accesses to clause 22 PHYs.
      This permits tracing of these accesses.
      
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1b2dea2e
    • Russell King's avatar
      net: mdiobus: add unlocked accessors · 34dc08e4
      Russell King authored
      
      
      Add unlocked versions of the bus accessors, which allows access to the
      bus with all the tracing. These accessors validate that the bus mutex
      is held, which is a basic requirement for all mii bus accesses.
      
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      34dc08e4
  4. Jan 03, 2018