1. 07 Feb, 2018 3 commits
  2. 03 Feb, 2018 1 commit
    • Linus Torvalds's avatar
      pinctrl: remove include file from <linux/device.h> · 23c35f48
      Linus Torvalds authored
      
      
      When pulling the recent pinctrl merge, I was surprised by how a
      pinctrl-only pull request ended up rebuilding basically the whole
      kernel.
      
      The reason for that ended up being that <linux/device.h> included
      <linux/pinctrl/devinfo.h>, so any change to that file ended up causing
      pretty much every driver out there to be rebuilt.
      
      The reason for that was because 'struct device' has this in it:
      
          #ifdef CONFIG_PINCTRL
              struct dev_pin_info     *pins;
          #endif
      
      but we already avoid header includes for these kinds of things in that
      header file, preferring to just use a forward-declaration of the
      structure instead.  Exactly to avoid this kind of header dependency.
      
      Since some drivers seem to expect that <linux/pinctrl/devinfo.h> header
      to come in automatically, move the include to <linux/pinctrl/pinctrl.h>
      instead.  It might be better to just make the includes more targeted,
      but I'm not going to review every driver.
      
      It would definitely be good to have a tool for finding and minimizing
      header dependencies automatically - or at least help with them.  Right
      now we almost certainly end up having way too many of these things, and
      it's hard to test every single configuration.
      
      FWIW, you can get a sense of the "hotness" of a header file with something
      like this after doing a full build:
      
          find . -name '.*.o.cmd' -print0 |
              xargs -0 tail --lines=+2 |
              grep -v 'wildcard ' |
              tr ' \\' '\n' |
              sort | uniq -c | sort -n | less -S
      
      which isn't exact (there are other things in those '*.o.cmd' than just
      the dependencies, and the "--lines=+2" only removes the header), but
      might a useful approximation.
      
      With this patch, <linux/pinctrl/devinfo.h> drops to "only" having 833
      users in the current x86-64 allmodconfig.  In contrast, <linux/device.h>
      has 14857 build files including it directly or indirectly.
      
      Of course, the headers that absolutely _everybody_ includes (things like
      <linux/types.h> etc) get a score of 23000+.
      
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      23c35f48
  3. 02 Feb, 2018 3 commits
  4. 01 Feb, 2018 31 commits
  5. 31 Jan, 2018 2 commits
    • Jeff Layton's avatar
      iversion: make inode_cmp_iversion{+raw} return bool instead of s64 · c0cef30e
      Jeff Layton authored
      
      
      As Linus points out:
      
          The inode_cmp_iversion{+raw}() functions are pure and utter crap.
      
          Why?
      
          You say that they return 0/negative/positive, but they do so in a
          completely broken manner. They return that ternary value as the
          sequence number difference in a 's64', which means that if you
          actually care about that ternary value, and do the *sane* thing that
          the kernel-doc of the function implies is the right thing, you would
          do
      
              int cmp = inode_cmp_iversion(inode, old);
              if (cmp < 0 ...
      
          and as a result you get code that looks sane, but that doesn't
          actually *WORK* right.
      
      Since none of the callers actually care about the ternary value here,
      convert the inode_cmp_iversion{+raw} functions to just return a boolean
      value (false for matching, true for non-matching).
      
      This matches the existing use of these functions just fine, and makes it
      simple to convert them to return a ternary value in the future if we
      grow callers that need it.
      
      With this change we can also reimplement inode_cmp_iversion in a simpler
      way using inode_peek_iversion.
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c0cef30e
    • Ming Lei's avatar
      blk-mq: introduce BLK_STS_DEV_RESOURCE · 86ff7c2a
      Ming Lei authored
      
      
      This status is returned from driver to block layer if device related
      resource is unavailable, but driver can guarantee that IO dispatch
      will be triggered in future when the resource is available.
      
      Convert some drivers to return BLK_STS_DEV_RESOURCE.  Also, if driver
      returns BLK_STS_RESOURCE and SCHED_RESTART is set, rerun queue after
      a delay (BLK_MQ_DELAY_QUEUE) to avoid IO stalls.  BLK_MQ_DELAY_QUEUE is
      3 ms because both scsi-mq and nvmefc are using that magic value.
      
      If a driver can make sure there is in-flight IO, it is safe to return
      BLK_STS_DEV_RESOURCE because:
      
      1) If all in-flight IOs complete before examining SCHED_RESTART in
      blk_mq_dispatch_rq_list(), SCHED_RESTART must be cleared, so queue
      is run immediately in this case by blk_mq_dispatch_rq_list();
      
      2) if there is any in-flight IO after/when examining SCHED_RESTART
      in blk_mq_dispatch_rq_list():
      - if SCHED_RESTART isn't set, queue is run immediately as handled in 1)
      - otherwise, this request will be dispatched after any in-flight IO is
        completed via blk_mq_sched_restart()
      
      3) if SCHED_RESTART is set concurently in context because of
      BLK_STS_RESOURCE, blk_mq_delay_run_hw_queue() will cover the above two
      cases and make sure IO hang can be avoided.
      
      One invariant is that queue will be rerun if SCHED_RESTART is set.
      Suggested-by: default avatarJens Axboe <axboe@kernel.dk>
      Tested-by: default avatarLaurence Oberman <loberman@redhat.com>
      Signed-off-by: default avatarMing Lei <ming.lei@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      86ff7c2a