1. 02 Nov, 2017 1 commit
    • Greg Kroah-Hartman's avatar
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman authored
      Many source files in the tree are missing licensing information, which
      makes it harder for compliance tools to determine the correct license.
      
      By default all files without license information are under the default
      license of the kernel, which is GPL version 2.
      
      Update the files which contain no license information with the 'GPL-2.0'
      SPDX license identifier.  The SPDX identifier is a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.
      
      How this work was done:
      
      Patches were generated and checked against linux-4.14-rc6 for a subset of
      the use cases:
       - file had no licensing information it it.
       - file was a */uapi/* one with no licensing information in it,
       - file was a */uapi/* one with existing licensing information,
      
      Further patches will be generated in subsequent months to fix up cases
      where non-standard license headers were used, and references to license
      had to be inferred by heuristics based on keywords.
      
      The analysis to determine which SPDX License Identifier to be applied to
      a file was done in a spreadsheet of side by side results from of the
      output of two independent scanners (ScanCode & Windriver) producing SPDX
      tag:value files created by Philippe Ombredanne.  Philippe prepared the
      base worksheet, and did an initial spot review of a few 1000 files.
      
      The 4.13 kernel was the starting point of the analysis with 60,537 files
      assessed.  Kate Stewart did a file by file comparison of the scanner
      results in the spreadsheet to determine which SPDX license identifier(s)
      to be applied to the file. She confirmed any determination that was not
      immediately clear with lawyers working with the Linux Foundation.
      
      Criteria used to select files for SPDX license identifier tagging was:
       - Files considered eligible had to be source code files.
       - Make and config files were included as candidates if they contained >5
         lines of source
       - File already had some variant of a license header in it (even if <5
         lines).
      
      All documentation files were explicitly excluded.
      
      The following heuristics were used to determine which SPDX license
      identifiers to apply.
      
       - when both scanners couldn't find any license traces, file was
         considered to have no license information in it, and the top level
         COPYING file license applied.
      
         For non */uapi/* files that summary was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0                                              11139
      
         and resulted in the first patch in this series.
      
         If that file was a */uapi/* path one, it was "GPL-2.0 WITH
         Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0 WITH Linux-syscall-note                        930
      
         and resulted in the second patch in this series.
      
       - if a file had some form of licensing information in it, and was one
         of the */uapi/* ones, it was denoted with the Linux-syscall-note if
         any GPL family license was found in the file or had no licensing in
         it (per prior point).  Results summary:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|------
         GPL-2.0 WITH Linux-syscall-note                       270
         GPL-2.0+ WITH Linux-syscall-note                      169
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
         LGPL-2.1+ WITH Linux-syscall-note                      15
         GPL-1.0+ WITH Linux-syscall-note                       14
         ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
         LGPL-2.0+ WITH Linux-syscall-note                       4
         LGPL-2.1 WITH Linux-syscall-note                        3
         ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
         ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1
      
         and that resulted in the third patch in this series.
      
       - when the two scanners agreed on the detected license(s), that became
         the concluded license(s).
      
       - when there was disagreement between the two scanners (one detected a
         license but the other didn't, or they both detected different
         licenses) a manual inspection of the file occurred.
      
       - In most cases a manual inspection of the information in the file
         resulted in a clear resolution of the license that should apply (and
         which scanner probably needed to revisit its heuristics).
      
       - When it was not immediately clear, the license identifier was
         confirmed with lawyers working with the Linux Foundation.
      
       - If there was any question as to the appropriate license identifier,
         the file was flagged for further research and to be revisited later
         in time.
      
      In total, over 70 hours of logged manual review was done on the
      spreadsheet to determine the SPDX license identifiers to apply to the
      source files by Kate, Philippe, Thomas and, in some cases, confirmation
      by lawyers working with the Linux Foundation.
      
      Kate also obtained a third independent scan of the 4.13 code base from
      FOSSology, and compared selected files where the other two scanners
      disagreed against that SPDX file, to see if there was new insights.  The
      Windriver scanner is based on an older version of FOSSology in part, so
      they are related.
      
      Thomas did random spot checks in about 500 files from the spreadsheets
      for the uapi headers and agreed with SPDX license identifier in the
      files he inspected. For the non-uapi files Thomas did random spot checks
      in about 15000 files.
      
      In initial set of patches against 4.14-rc6, 3 files were found to have
      copy/paste license identifier errors, and have been fixed to reflect the
      correct identifier.
      
      Additionally Philippe spent 10 hours this week doing a detailed manual
      inspection and review of the 12,461 patched files from the initial patch
      version early this week with:
       - a full scancode scan run, collecting the matched texts, detected
         license ids and scores
       - reviewing anything where there was a license detected (about 500+
         files) to ensure that the applied SPDX license was correct
       - reviewing anything where there was no detection but the patch license
         was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
         SPDX license was correct
      
      This produced a worksheet with 20 files needing minor correction.  This
      worksheet was then exported into 3 different .csv files for the
      different types of files to be modified.
      
      These .csv files were then reviewed by Greg.  Thomas wrote a script to
      parse the csv files and add the proper SPDX tag to the file, in the
      format that the file expected.  This script was further refined by Greg
      based on the output to detect more types of files automatically and to
      distinguish between header and source .c files (which need different
      comment types.)  Finally Greg ran the script using the .csv files to
      generate the patches.
      Reviewed-by: 's avatarKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: 's avatarPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: 's avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2441318
  2. 25 Oct, 2017 1 commit
    • Mark Rutland's avatar
      locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns... · 6aa7de05
      Mark Rutland authored
      locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns to READ_ONCE()/WRITE_ONCE()
      
      Please do not apply this to mainline directly, instead please re-run the
      coccinelle script shown below and apply its output.
      
      For several reasons, it is desirable to use {READ,WRITE}_ONCE() in
      preference to ACCESS_ONCE(), and new code is expected to use one of the
      former. So far, there's been no reason to change most existing uses of
      ACCESS_ONCE(), as these aren't harmful, and changing them results in
      churn.
      
      However, for some features, the read/write distinction is critical to
      correct operation. To distinguish these cases, separate read/write
      accessors must be used. This patch migrates (most) remaining
      ACCESS_ONCE() instances to {READ,WRITE}_ONCE(), using the following
      coccinelle script:
      
      ----
      // Convert trivial ACCESS_ONCE() uses to equivalent READ_ONCE() and
      // WRITE_ONCE()
      
      // $ make coccicheck COCCI=/home/mark/once.cocci SPFLAGS="--include-headers" MODE=patch
      
      virtual patch
      
      @ depends on patch @
      expression E1, E2;
      @@
      
      - ACCESS_ONCE(E1) = E2
      + WRITE_ONCE(E1, E2)
      
      @ depends on patch @
      expression E;
      @@
      
      - ACCESS_ONCE(E)
      + READ_ONCE(E)
      ----
      Signed-off-by: 's avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: 's avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: davem@davemloft.net
      Cc: linux-arch@vger.kernel.org
      Cc: mpe@ellerman.id.au
      Cc: shuah@kernel.org
      Cc: snitzer@redhat.com
      Cc: thor.thayer@linux.intel.com
      Cc: tj@kernel.org
      Cc: viro@zeniv.linux.org.uk
      Cc: will.deacon@arm.com
      Link: http://lkml.kernel.org/r/1508792849-3115-19-git-send-email-paulmck@linux.vnet.ibm.comSigned-off-by: 's avatarIngo Molnar <mingo@kernel.org>
      6aa7de05
  3. 05 Oct, 2017 1 commit
    • Kees Cook's avatar
      timer: Remove init_timer_on_stack() in favor of timer_setup_on_stack() · 9c6c273a
      Kees Cook authored
      Remove uses of init_timer_on_stack() with open-coded function and data
      assignments that could be expressed using timer_setup_on_stack(). Several
      were removed from the stack entirely since there was a one-to-one mapping
      of parent structure to timer, those are switched to using timer_setup()
      instead. All related callbacks were adjusted to use from_timer().
      Signed-off-by: 's avatarKees Cook <keescook@chromium.org>
      Signed-off-by: 's avatarThomas Gleixner <tglx@linutronix.de>
      Cc: linux-mips@linux-mips.org
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Sebastian Reichel <sre@kernel.org>
      Cc: Kalle Valo <kvalo@qca.qualcomm.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Wim Van Sebroeck <wim@iguana.be>
      Cc: linux1394-devel@lists.sourceforge.net
      Cc: Chris Metcalf <cmetcalf@mellanox.com>
      Cc: linux-s390@vger.kernel.org
      Cc: linux-wireless@vger.kernel.org
      Cc: "James E.J. Bottomley" <jejb@linux.vnet.ibm.com>
      Cc: linux-scsi@vger.kernel.org
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Ursula Braun <ubraun@linux.vnet.ibm.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Cc: Harish Patil <harish.patil@cavium.com>
      Cc: Stephen Boyd <sboyd@codeaurora.org>
      Cc: Michael Reed <mdr@sgi.com>
      Cc: Manish Chopra <manish.chopra@cavium.com>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: linux-pm@vger.kernel.org
      Cc: Lai Jiangshan <jiangshanlai@gmail.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Julian Wiedmann <jwi@linux.vnet.ibm.com>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Mark Gross <mark.gross@intel.com>
      Cc: linux-watchdog@vger.kernel.org
      Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: netdev@vger.kernel.org
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
      Link: https://lkml.kernel.org/r/1507159627-127660-4-git-send-email-keescook@chromium.org
      9c6c273a
  4. 16 Jun, 2017 2 commits
    • Johannes Berg's avatar
      networking: make skb_push & __skb_push return void pointers · d58ff351
      Johannes Berg authored
      It seems like a historic accident that these return unsigned char *,
      and in many places that means casts are required, more often than not.
      
      Make these functions return void * and remove all the casts across
      the tree, adding a (u8 *) cast only where the unsigned char pointer
      was used directly, all done with the following spatch:
      
          @@
          expression SKB, LEN;
          typedef u8;
          identifier fn = { skb_push, __skb_push, skb_push_rcsum };
          @@
          - *(fn(SKB, LEN))
          + *(u8 *)fn(SKB, LEN)
      
          @@
          expression E, SKB, LEN;
          identifier fn = { skb_push, __skb_push, skb_push_rcsum };
          type T;
          @@
          - E = ((T *)(fn(SKB, LEN)))
          + E = fn(SKB, LEN)
      
          @@
          expression SKB, LEN;
          identifier fn = { skb_push, __skb_push, skb_push_rcsum };
          @@
          - fn(SKB, LEN)[0]
          + *(u8 *)fn(SKB, LEN)
      
      Note that the last part there converts from push(...)[0] to the
      more idiomatic *(u8 *)push(...).
      Signed-off-by: 's avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      d58ff351
    • Johannes Berg's avatar
      networking: introduce and use skb_put_data() · 59ae1d12
      Johannes Berg authored
      A common pattern with skb_put() is to just want to memcpy()
      some data into the new space, introduce skb_put_data() for
      this.
      
      An spatch similar to the one for skb_put_zero() converts many
      of the places using it:
      
          @@
          identifier p, p2;
          expression len, skb, data;
          type t, t2;
          @@
          (
          -p = skb_put(skb, len);
          +p = skb_put_data(skb, data, len);
          |
          -p = (t)skb_put(skb, len);
          +p = skb_put_data(skb, data, len);
          )
          (
          p2 = (t2)p;
          -memcpy(p2, data, len);
          |
          -memcpy(p, data, len);
          )
      
          @@
          type t, t2;
          identifier p, p2;
          expression skb, data;
          @@
          t *p;
          ...
          (
          -p = skb_put(skb, sizeof(t));
          +p = skb_put_data(skb, data, sizeof(t));
          |
          -p = (t *)skb_put(skb, sizeof(t));
          +p = skb_put_data(skb, data, sizeof(t));
          )
          (
          p2 = (t2)p;
          -memcpy(p2, data, sizeof(*p));
          |
          -memcpy(p, data, sizeof(*p));
          )
      
          @@
          expression skb, len, data;
          @@
          -memcpy(skb_put(skb, len), data, len);
          +skb_put_data(skb, data, len);
      
      (again, manually post-processed to retain some comments)
      Reviewed-by: 's avatarStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: 's avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      59ae1d12
  5. 23 Mar, 2017 1 commit
  6. 28 Feb, 2017 1 commit
  7. 14 Feb, 2017 1 commit
  8. 03 Nov, 2016 2 commits
    • Stefan Richter's avatar
      firewire: net: fix fragmented datagram_size off-by-one · e9300a4b
      Stefan Richter authored
      RFC 2734 defines the datagram_size field in fragment encapsulation
      headers thus:
      
          datagram_size:  The encoded size of the entire IP datagram.  The
          value of datagram_size [...] SHALL be one less than the value of
          Total Length in the datagram's IP header (see STD 5, RFC 791).
      
      Accordingly, the eth1394 driver of Linux 2.6.36 and older set and got
      this field with a -/+1 offset:
      
          ether1394_tx() /* transmit */
              ether1394_encapsulate_prep()
                  hdr->ff.dg_size = dg_size - 1;
      
          ether1394_data_handler() /* receive */
              if (hdr->common.lf == ETH1394_HDR_LF_FF)
                  dg_size = hdr->ff.dg_size + 1;
              else
                  dg_size = hdr->sf.dg_size + 1;
      
      Likewise, I observe OS X 10.4 and Windows XP Pro SP3 to transmit 1500
      byte sized datagrams in fragments with datagram_size=1499 if link
      fragmentation is required.
      
      Only firewire-net sets and gets datagram_size without this offset.  The
      result is lacking interoperability of firewire-net with OS X, Windows
      XP, and presumably Linux' eth1394.  (I did not test with the latter.)
      For example, FTP data transfers to a Linux firewire-net box with max_rec
      smaller than the 1500 bytes MTU
        - from OS X fail entirely,
        - from Win XP start out with a bunch of fragmented datagrams which
          time out, then continue with unfragmented datagrams because Win XP
          temporarily reduces the MTU to 576 bytes.
      
      So let's fix firewire-net's datagram_size accessors.
      
      Note that firewire-net thereby loses interoperability with unpatched
      firewire-net, but only if link fragmentation is employed.  (This happens
      with large broadcast datagrams, and with large datagrams on several
      FireWire CardBus cards with smaller max_rec than equivalent PCI cards,
      and it can be worked around by setting a small enough MTU.)
      
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      e9300a4b
    • Stefan Richter's avatar
      firewire: net: guard against rx buffer overflows · 667121ac
      Stefan Richter authored
      The IP-over-1394 driver firewire-net lacked input validation when
      handling incoming fragmented datagrams.  A maliciously formed fragment
      with a respectively large datagram_offset would cause a memcpy past the
      datagram buffer.
      
      So, drop any packets carrying a fragment with offset + length larger
      than datagram_size.
      
      In addition, ensure that
        - GASP header, unfragmented encapsulation header, or fragment
          encapsulation header actually exists before we access it,
        - the encapsulated datagram or fragment is of nonzero size.
      Reported-by: 's avatarEyal Itkin <eyal.itkin@gmail.com>
      Reviewed-by: 's avatarEyal Itkin <eyal.itkin@gmail.com>
      Fixes: CVE 2016-8633
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      667121ac
  9. 30 Oct, 2016 1 commit
    • Stefan Richter's avatar
      firewire: net: really fix maximum possible MTU · 357f4aae
      Stefan Richter authored
      The maximum unicast datagram size /without/ link fragmentation is
      4096 - 4 = 4092 (max IEEE 1394 async payload size at >= S800 bus speed,
      minus unfragmented encapssulation header).  Max broadcast datagram size
      without fragmentation is 8 bytes less than that (due to GASP header).
      
      The maximum datagram size /with/ link fragmentation is 0xfff = 4095
      for unicast and broadcast.  This is because the RFC 2734 fragment
      encapsulation header field for datagram size is only 12 bits wide.
      
      Fixes: 5d48f00d('firewire: net: fix maximum possible MTU')
      Signed-off-by: 's avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      357f4aae
  10. 26 Oct, 2016 2 commits
    • Stefan Richter's avatar
      firewire: net: set initial MTU = 1500 unconditionally, fix IPv6 on some CardBus cards · 89ab88b0
      Stefan Richter authored
      firewire-net, like the older eth1394 driver, reduced the initial MTU to
      less than 1500 octets if the local link layer controller's asynchronous
      packet reception limit was lower.
      
      This is bogus, since this reception limit does not have anything to do
      with the transmission limit.  Neither did this reduction affect the TX
      path positively, nor could it prevent link fragmentation at the RX path.
      
      Many FireWire CardBus cards have a max_rec of 9, causing an initial MTU
      of 1024 - 16 = 1008.  RFC 2734 and RFC 3146 allow a minimum max_rec = 8,
      which would result in an initial MTU of 512 - 16 = 496.  On such cards,
      IPv6 could only be employed if the MTU was manually increased to 1280 or
      more, i.e. IPv6 would not work without intervention from userland.
      
      We now always initialize the MTU to 1500, which is the default according
      to RFC 2734 and RFC 3146.
      
      On a VIA VT6316 based CardBus card which was affected by this, changing
      the MTU from 1008 to 1500 also increases TX bandwidth by 6 %.
      RX remains unaffected.
      
      CC: netdev@vger.kernel.org
      CC: linux1394-devel@lists.sourceforge.net
      CC: Jarod Wilson <jarod@redhat.com>
      Signed-off-by: 's avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      89ab88b0
    • Stefan Richter's avatar
      firewire: net: fix maximum possible MTU · 5d48f00d
      Stefan Richter authored
      Commit b3e3893e ("net: use core MTU range checking in misc drivers")
      mistakenly introduced an upper limit for firewire-net's MTU based on the
      local link layer controller's reception capability.  Revert this.  Neither
      RFC 2734 nor our implementation impose any particular upper limit.
      
      Actually, to be on the safe side and to make the code explicit, set
      ETH_MAX_MTU = 65535 as upper limit now.
      
      (I replaced sizeof(struct rfc2734_header) by the equivalent
      RFC2374_FRAG_HDR_SIZE in order to avoid distracting long/int conversions.)
      
      Fixes: b3e3893e('net: use core MTU range checking in misc drivers')
      CC: netdev@vger.kernel.org
      CC: linux1394-devel@lists.sourceforge.net
      CC: Jarod Wilson <jarod@redhat.com>
      Signed-off-by: 's avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      Acked-by: 's avatarJarod Wilson <jarod@redhat.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      5d48f00d
  11. 20 Oct, 2016 1 commit
    • Jarod Wilson's avatar
      net: use core MTU range checking in misc drivers · b3e3893e
      Jarod Wilson authored
      firewire-net:
      - set min/max_mtu
      - remove fwnet_change_mtu
      
      nes:
      - set max_mtu
      - clean up nes_netdev_change_mtu
      
      xpnet:
      - set min/max_mtu
      - remove xpnet_dev_change_mtu
      
      hippi:
      - set min/max_mtu
      - remove hippi_change_mtu
      
      batman-adv:
      - set max_mtu
      - remove batadv_interface_change_mtu
      - initialization is a little async, not 100% certain that max_mtu is set
        in the optimal place, don't have hardware to test with
      
      rionet:
      - set min/max_mtu
      - remove rionet_change_mtu
      
      slip:
      - set min/max_mtu
      - streamline sl_change_mtu
      
      um/net_kern:
      - remove pointless ndo_change_mtu
      
      hsi/clients/ssi_protocol:
      - use core MTU range checking
      - remove now redundant ssip_pn_set_mtu
      
      ipoib:
      - set a default max MTU value
      - Note: ipoib's actual max MTU can vary, depending on if the device is in
        connected mode or not, so we'll just set the max_mtu value to the max
        possible, and let the ndo_change_mtu function continue to validate any new
        MTU change requests with checks for CM or not. Note that ipoib has no
        min_mtu set, and thus, the network core's mtu > 0 check is the only lower
        bounds here.
      
      mptlan:
      - use net core MTU range checking
      - remove now redundant mpt_lan_change_mtu
      
      fddi:
      - min_mtu = 21, max_mtu = 4470
      - remove now redundant fddi_change_mtu (including export)
      
      fjes:
      - min_mtu = 8192, max_mtu = 65536
      - The max_mtu value is actually one over IP_MAX_MTU here, but the idea is to
        get past the core net MTU range checks so fjes_change_mtu can validate a
        new MTU against what it supports (see fjes_support_mtu in fjes_hw.c)
      
      hsr:
      - min_mtu = 0 (calls ether_setup, max_mtu is 1500)
      
      f_phonet:
      - min_mtu = 6, max_mtu = 65541
      
      u_ether:
      - min_mtu = 14, max_mtu = 15412
      
      phonet/pep-gprs:
      - min_mtu = 576, max_mtu = 65530
      - remove redundant gprs_set_mtu
      
      CC: netdev@vger.kernel.org
      CC: linux-rdma@vger.kernel.org
      CC: Stefan Richter <stefanr@s5r6.in-berlin.de>
      CC: Faisal Latif <faisal.latif@intel.com>
      CC: linux-rdma@vger.kernel.org
      CC: Cliff Whickman <cpw@sgi.com>
      CC: Robin Holt <robinmholt@gmail.com>
      CC: Jes Sorensen <jes@trained-monkey.org>
      CC: Marek Lindner <mareklindner@neomailbox.ch>
      CC: Simon Wunderlich <sw@simonwunderlich.de>
      CC: Antonio Quartulli <a@unstable.cc>
      CC: Sathya Prakash <sathya.prakash@broadcom.com>
      CC: Chaitra P B <chaitra.basappa@broadcom.com>
      CC: Suganath Prabu Subramani <suganath-prabu.subramani@broadcom.com>
      CC: MPT-FusionLinux.pdl@broadcom.com
      CC: Sebastian Reichel <sre@kernel.org>
      CC: Felipe Balbi <balbi@kernel.org>
      CC: Arvid Brodin <arvid.brodin@alten.se>
      CC: Remi Denis-Courmont <courmisch@gmail.com>
      Signed-off-by: 's avatarJarod Wilson <jarod@redhat.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      b3e3893e
  12. 09 Oct, 2016 1 commit
  13. 04 May, 2016 1 commit
  14. 22 Mar, 2016 2 commits
  15. 07 Nov, 2015 1 commit
    • Mel Gorman's avatar
      mm, page_alloc: distinguish between being unable to sleep, unwilling to sleep... · d0164adc
      Mel Gorman authored
      mm, page_alloc: distinguish between being unable to sleep, unwilling to sleep and avoiding waking kswapd
      
      __GFP_WAIT has been used to identify atomic context in callers that hold
      spinlocks or are in interrupts.  They are expected to be high priority and
      have access one of two watermarks lower than "min" which can be referred
      to as the "atomic reserve".  __GFP_HIGH users get access to the first
      lower watermark and can be called the "high priority reserve".
      
      Over time, callers had a requirement to not block when fallback options
      were available.  Some have abused __GFP_WAIT leading to a situation where
      an optimisitic allocation with a fallback option can access atomic
      reserves.
      
      This patch uses __GFP_ATOMIC to identify callers that are truely atomic,
      cannot sleep and have no alternative.  High priority users continue to use
      __GFP_HIGH.  __GFP_DIRECT_RECLAIM identifies callers that can sleep and
      are willing to enter direct reclaim.  __GFP_KSWAPD_RECLAIM to identify
      callers that want to wake kswapd for background reclaim.  __GFP_WAIT is
      redefined as a caller that is willing to enter direct reclaim and wake
      kswapd for background reclaim.
      
      This patch then converts a number of sites
      
      o __GFP_ATOMIC is used by callers that are high priority and have memory
        pools for those requests. GFP_ATOMIC uses this flag.
      
      o Callers that have a limited mempool to guarantee forward progress clear
        __GFP_DIRECT_RECLAIM but keep __GFP_KSWAPD_RECLAIM. bio allocations fall
        into this category where kswapd will still be woken but atomic reserves
        are not used as there is a one-entry mempool to guarantee progress.
      
      o Callers that are checking if they are non-blocking should use the
        helper gfpflags_allow_blocking() where possible. This is because
        checking for __GFP_WAIT as was done historically now can trigger false
        positives. Some exceptions like dm-crypt.c exist where the code intent
        is clearer if __GFP_DIRECT_RECLAIM is used instead of the helper due to
        flag manipulations.
      
      o Callers that built their own GFP flags instead of starting with GFP_KERNEL
        and friends now also need to specify __GFP_KSWAPD_RECLAIM.
      
      The first key hazard to watch out for is callers that removed __GFP_WAIT
      and was depending on access to atomic reserves for inconspicuous reasons.
      In some cases it may be appropriate for them to use __GFP_HIGH.
      
      The second key hazard is callers that assembled their own combination of
      GFP flags instead of starting with something like GFP_KERNEL.  They may
      now wish to specify __GFP_KSWAPD_RECLAIM.  It's almost certainly harmless
      if it's missed in most cases as other activity will wake kswapd.
      Signed-off-by: 's avatarMel Gorman <mgorman@techsingularity.net>
      Acked-by: 's avatarVlastimil Babka <vbabka@suse.cz>
      Acked-by: 's avatarMichal Hocko <mhocko@suse.com>
      Acked-by: 's avatarJohannes Weiner <hannes@cmpxchg.org>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Vitaly Wool <vitalywool@gmail.com>
      Cc: Rik van Riel <riel@redhat.com>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      d0164adc
  16. 05 Nov, 2015 3 commits
    • Stefan Richter's avatar
      firewire: ohci: propagate return code from soft_reset to probe and resume · a354cf00
      Stefan Richter authored
      software_reset() may fail
        - due to unresponsive chip with -EBUSY (-16), or
        - due to ejected or unseated card with -ENODEV (-19).
      Let the PCI probe and resume routines log the actual error code instead
      of hardwired -EBUSY.
      Signed-off-by: 's avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      a354cf00
    • Amitoj Kaur Chawla's avatar
      firewire: nosy: Replace timeval with timespec64 · 2ae4b6b2
      Amitoj Kaur Chawla authored
      32 bit systems using 'struct timeval' will break in the year 2038, so
      we replace the code appropriately. However, this driver is not broken
      in 2038 since we are using only the microseconds portion of the
      current time.
      
      This patch replaces timeval with timespec64.
      Signed-off-by: 's avatarAmitoj Kaur Chawla <amitoj1606@gmail.com>
      Reviewed-by: 's avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: 's avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      2ae4b6b2
    • Stefan Richter's avatar
      firewire: ohci: fix JMicron JMB38x IT context discovery · 100ceb66
      Stefan Richter authored
      Reported by Clifford and Craig for JMicron OHCI-1394 + SDHCI combo
      controllers:  Often or even most of the time, the controller is
      initialized with the message "added OHCI v1.10 device as card 0, 4 IR +
      0 IT contexts, quirks 0x10".  With 0 isochronous transmit DMA contexts
      (IT contexts), applications like audio output are impossible.
      
      However, OHCI-1394 demands that at least 4 IT contexts are implemented
      by the link layer controller, and indeed JMicron JMB38x do implement
      four of them.  Only their IsoXmitIntMask register is unreliable at early
      access.
      
      With my own JMB381 single function controller I found:
        - I can reproduce the problem with a lower probability than Craig's.
        - If I put a loop around the section which clears and reads
          IsoXmitIntMask, then either the first or the second attempt will
          return the correct initial mask of 0x0000000f.  I never encountered
          a case of needing more than a second attempt.
        - Consequently, if I put a dummy reg_read(...IsoXmitIntMaskSet)
          before the first write, the subsequent read will return the correct
          result.
        - If I merely ignore a wrong read result and force the known real
          result, later isochronous transmit DMA usage works just fine.
      
      So let's just fix this chip bug up by the latter method.  Tested with
      JMB381 on kernel 3.13 and 4.3.
      
      Since OHCI-1394 generally requires 4 IT contexts at a minium, this
      workaround is simply applied whenever the initial read of IsoXmitIntMask
      returns 0, regardless whether it's a JMicron chip or not.  I never heard
      of this issue together with any other chip though.
      
      I am not 100% sure that this fix works on the OHCI-1394 part of JMB380
      and JMB388 combo controllers exactly the same as on the JMB381 single-
      function controller, but so far I haven't had a chance to let an owner
      of a combo chip run a patched kernel.
      
      Strangely enough, IsoRecvIntMask is always reported correctly, even
      though it is probed right before IsoXmitIntMask.
      
      Reported-by: Clifford Dunn
      Reported-by: 's avatarCraig Moore <craig.moore@qenos.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      100ceb66
  17. 01 Jun, 2015 1 commit
  18. 02 Mar, 2015 1 commit
  19. 02 Feb, 2015 1 commit
  20. 31 Jan, 2015 1 commit
    • Stefan Richter's avatar
      firewire: sbp2: remove redundant check for bidi command · 1f95f8c9
      Stefan Richter authored
      [Bart van Asche:]  SCSI core never sets cmd->sc_data_direction to
      DMA_BIDIRECTIONAL; scsi_bidi_cmnd(cmd) should be used instead to
      test for a bidirectional command.
      
      [Christoph Hellwig:]  Bidirectional commands won't ever be queued
      anyway, unless a LLD or transport driver sets QUEUE_FLAG_BIDI.
      
      So, simply remove the respective queuecommand check in the SBP-2
      transport driver.
      Signed-off-by: 's avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      1f95f8c9
  21. 22 Jan, 2015 1 commit
  22. 10 Dec, 2014 4 commits
    • Stefan Richter's avatar
      firewire: sbp2: replace card lock by target lock · d737d7da
      Stefan Richter authored
      firewire-core uses fw_card.lock to protect topology data and transaction
      data.  firewire-sbp2 uses fw_card.lock for entirely unrelated purposes.
      
      Introduce a sbp2_target.lock to firewire-sbp2 and replace all
      fw_card.lock uses in the driver.  fw_card.lock is now entirely private
      to firewire-core.  This has no immediate advantage apart from making it
      clear in the code that firewire-sbp2 does not interact with the core
      via the core lock.
      Signed-off-by: 's avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      d737d7da
    • Stefan Richter's avatar
      firewire: sbp2: replace some spin_lock_irqsave by spin_lock_irq · 8e045a31
      Stefan Richter authored
      Users of card->lock        Calling context
      ------------------------------------------------------------------------
      sbp2_status_write          AR-req handler, tasklet
      complete_transaction       AR-resp or AT-req handler, tasklet
      sbp2_send_orb              among else scsi host .queuecommand, which may
                                 be called in some sort of atomic context
      sbp2_cancel_orbs           sbp2_send_management_orb/
                                     sbp2_{login,reconnect,remove},
                                     worklet or process
                                 sbp2_scsi_abort, scsi eh thread
      sbp2_allow_block           sbp2_login, worklet
      sbp2_conditionally_block   among else complete_command_orb, tasklet
      sbp2_conditionally_unblock sbp2_{login,reconnect}, worklet
      sbp2_unblock               sbp2_{login,remove}, worklet or process
      
      Drop the IRQ flags saving from sbp2_cancel_orbs,
      sbp2_conditionally_unblock, and sbp2_unblock.
      It was already omitted in sbp2_allow_block.
      Signed-off-by: 's avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      8e045a31
    • Stefan Richter's avatar
      firewire: sbp2: protect a reference counter properly · 0765cbd3
      Stefan Richter authored
      The assertion in the comment in sbp2_allow_block() is no longer true.
      Or maybe it never was true.  At least now, the sole caller of
      sbp2_allow_block(), sbp2_login, can run concurrently to one of
      sbp2_unblock()'s callers, sbp2_remove.
      
      sbp2_login is performed by sbp2_logical_unit.work.
      sbp2_remove is performed by fw_device.work.
      sbp2_remove cancels sbp2_logical_unit.work, but only after it called
      sbp2_unblock.
      Signed-off-by: 's avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      0765cbd3
    • Stefan Richter's avatar
      firewire: core: document fw_csr_string's truncation of long strings · 0238507b
      Stefan Richter authored
      fw_csr_string() truncates and terminates target strings like strlcpy()
      does.  Unlike strlcpy(), it returns the target strlen, not the source
      strlen, hence users of fw_csr_string() are unable to detect truncation.
      
      Point this behavior out in the kerneldoc comment.
      Signed-off-by: 's avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      Reviewed-by: 's avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      0238507b
  23. 19 Nov, 2014 1 commit
  24. 14 Nov, 2014 1 commit
    • Stefan Richter's avatar
      firewire: cdev: prevent kernel stack leaking into ioctl arguments · eaca2d8e
      Stefan Richter authored
      Found by the UC-KLEE tool:  A user could supply less input to
      firewire-cdev ioctls than write- or write/read-type ioctl handlers
      expect.  The handlers used data from uninitialized kernel stack then.
      
      This could partially leak back to the user if the kernel subsequently
      generated fw_cdev_event_'s (to be read from the firewire-cdev fd)
      which notably would contain the _u64 closure field which many of the
      ioctl argument structures contain.
      
      The fact that the handlers would act on random garbage input is a
      lesser issue since all handlers must check their input anyway.
      
      The fix simply always null-initializes the entire ioctl argument buffer
      regardless of the actual length of expected user input.  That is, a
      runtime overhead of memset(..., 40) is added to each firewirew-cdev
      ioctl() call.  [Comment from Clemens Ladisch:  This part of the stack is
      most likely to be already in the cache.]
      
      Remarks:
        - There was never any leak from kernel stack to the ioctl output
          buffer itself.  IOW, it was not possible to read kernel stack by a
          read-type or write/read-type ioctl alone; the leak could at most
          happen in combination with read()ing subsequent event data.
        - The actual expected minimum user input of each ioctl from
          include/uapi/linux/firewire-cdev.h is, in bytes:
          [0x00] = 32, [0x05] =  4, [0x0a] = 16, [0x0f] = 20, [0x14] = 16,
          [0x01] = 36, [0x06] = 20, [0x0b] =  4, [0x10] = 20, [0x15] = 20,
          [0x02] = 20, [0x07] =  4, [0x0c] =  0, [0x11] =  0, [0x16] =  8,
          [0x03] =  4, [0x08] = 24, [0x0d] = 20, [0x12] = 36, [0x17] = 12,
          [0x04] = 20, [0x09] = 24, [0x0e] =  4, [0x13] = 40, [0x18] =  4.
      Reported-by: 's avatarDavid Ramos <daramos@stanford.edu>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: 's avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      eaca2d8e
  25. 23 Jul, 2014 1 commit
    • Stefan Richter's avatar
      firewire: ohci: disable MSI for VIA VT6315 again · d584a662
      Stefan Richter authored
      Revert half of commit d151f985:  If isochronous I/O is attempted with
      packets larget than 1 kByte, VIA VT6315 rev 01 immediately stops to generate
      any interrupts if MSI are used.  Fix this by going back to legacy interrupts.
      [Thread "Isochronous streaming with VT6315 OHCI",
      http://marc.info/?t=139049641500003]
      
      With smaller packets, the loss of IRQs happens too but only very rarely ---
      rarely eneough that it was not yet possible for me to determine whether
      QUIRK_NO_MSI is an actual fix for this rare variation of this chip bug.
      
      I am keeping QUIRK_CYCLE_TIMER off of VT6315 rev >= 1 because this has been
      verified by myself with certainty.  On the other hand, I am also keeping
      QUIRK_CYCLE_TIMER on for VT6315 rev 0 because I don't know at this time
      whether this revision accesses Cycle Timer non-atomically like most of the
      other VIA OHCIs are known to do.
      Reported-by: 's avatarRémy Bruno <remy-fw@remy.trinnov.com>
      Signed-off-by: 's avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      d584a662
  26. 15 Jul, 2014 1 commit
    • Tom Gundersen's avatar
      net: set name_assign_type in alloc_netdev() · c835a677
      Tom Gundersen authored
      Extend alloc_netdev{,_mq{,s}}() to take name_assign_type as argument, and convert
      all users to pass NET_NAME_UNKNOWN.
      
      Coccinelle patch:
      
      @@
      expression sizeof_priv, name, setup, txqs, rxqs, count;
      @@
      
      (
      -alloc_netdev_mqs(sizeof_priv, name, setup, txqs, rxqs)
      +alloc_netdev_mqs(sizeof_priv, name, NET_NAME_UNKNOWN, setup, txqs, rxqs)
      |
      -alloc_netdev_mq(sizeof_priv, name, setup, count)
      +alloc_netdev_mq(sizeof_priv, name, NET_NAME_UNKNOWN, setup, count)
      |
      -alloc_netdev(sizeof_priv, name, setup)
      +alloc_netdev(sizeof_priv, name, NET_NAME_UNKNOWN, setup)
      )
      
      v9: move comments here from the wrong commit
      Signed-off-by: 's avatarTom Gundersen <teg@jklm.no>
      Reviewed-by: 's avatarDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      c835a677
  27. 13 Jul, 2014 1 commit
    • Geert Uytterhoeven's avatar
      firewire: IEEE 1394 (FireWire) support should depend on HAS_DMA · 655fc39b
      Geert Uytterhoeven authored
      Commit b3d681a4 ("firewire: Use
      COMPILE_TEST for build testing") added COMPILE_TEST as an alternative
      dependency for the purpose of build testing the firewire core.
      However, this bypasses all other implicit dependencies assumed by PCI,
      like HAS_DMA.
      
      If NO_DMA=y:
      
          drivers/built-in.o: In function `fw_iso_buffer_destroy':
          (.text+0x36a096): undefined reference to `dma_unmap_page'
          drivers/built-in.o: In function `fw_iso_buffer_map_dma':
          (.text+0x36a164): undefined reference to `dma_map_page'
          drivers/built-in.o: In function `fw_iso_buffer_map_dma':
          (.text+0x36a172): undefined reference to `dma_mapping_error'
          drivers/built-in.o: In function `sbp2_send_management_orb':
          sbp2.c:(.text+0x36c6b4): undefined reference to `dma_map_single'
          sbp2.c:(.text+0x36c6c8): undefined reference to `dma_mapping_error'
          sbp2.c:(.text+0x36c772): undefined reference to `dma_map_single'
          sbp2.c:(.text+0x36c786): undefined reference to `dma_mapping_error'
          sbp2.c:(.text+0x36c854): undefined reference to `dma_unmap_single'
          sbp2.c:(.text+0x36c872): undefined reference to `dma_unmap_single'
          drivers/built-in.o: In function `sbp2_map_scatterlist':
          sbp2.c:(.text+0x36ccbc): undefined reference to `scsi_dma_map'
          sbp2.c:(.text+0x36cd36): undefined reference to `dma_map_single'
          sbp2.c:(.text+0x36cd4e): undefined reference to `dma_mapping_error'
          sbp2.c:(.text+0x36cd84): undefined reference to `scsi_dma_unmap'
          drivers/built-in.o: In function `sbp2_unmap_scatterlist':
          sbp2.c:(.text+0x36cda6): undefined reference to `scsi_dma_unmap'
          sbp2.c:(.text+0x36cdc6): undefined reference to `dma_unmap_single'
          drivers/built-in.o: In function `complete_command_orb':
          sbp2.c:(.text+0x36d6ac): undefined reference to `dma_unmap_single'
          drivers/built-in.o: In function `sbp2_scsi_queuecommand':
          sbp2.c:(.text+0x36d8e0): undefined reference to `dma_map_single'
          sbp2.c:(.text+0x36d8f6): undefined reference to `dma_mapping_error'
      
      Add an explicit dependency on HAS_DMA to fix this.
      Signed-off-by: 's avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Reviewed-by: 's avatarJean Delvare <jdelvare@suse.de>
      Signed-off-by: 's avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      655fc39b
  28. 12 Jun, 2014 1 commit
  29. 29 May, 2014 2 commits
  30. 26 May, 2014 1 commit
    • Takashi Sakamoto's avatar
      ALSA: firewire/bebob: Add a workaround for M-Audio special Firewire series · 9b1ee0b2
      Takashi Sakamoto authored
      In post commit, a quirk of this firmware about transactions is reported.
      This commit apply a workaround for this quirk.
      
      They often fail transactions due to gap_count mismatch. This state is changed
      by generating bus reset.
      
      The fw_schedule_bus_reset() is an exported symbol in firewire-core. But there
      are no header for public. This commit moves its prototype from
      drivers/firewire/core.h to include/linux/firewire.h.
      
      This mismatch still affects bus management before generating this bus reset.
      It still takes a time to call driver's probe() because transactions are still
      often failed.
      Signed-off-by: 's avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: 's avatarTakashi Iwai <tiwai@suse.de>
      9b1ee0b2