1. 01 7月, 2018 1 次提交
    • S
      PCI: Enable PASID only if entire path supports End-End TLP prefixes · 7ce3f912
      Sinan Kaya 提交于
      A PCIe endpoint carries the process address space identifier (PASID) in
      the TLP prefix as part of the memory read/write transaction. The address
      information in the TLP is relevant only for a given PASID context.
      
      An IOMMU takes PASID value and the address information from the
      TLP to look up the physical address in the system.
      
      PASID is an End-End TLP Prefix (PCIe r4.0, sec 6.20).  Sec 2.2.10.2 says
      
        It is an error to receive a TLP with an End-End TLP Prefix by a
        Receiver that does not support End-End TLP Prefixes. A TLP in
        violation of this rule is handled as a Malformed TLP. This is a
        reported error associated with the Receiving Port (see Section 6.2).
      
      Prevent error condition by proactively requiring End-End TLP prefix to be
      supported on the entire data path between the endpoint and the root port
      before enabling PASID.
      Signed-off-by: NSinan Kaya <okaya@codeaurora.org>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      7ce3f912
  2. 16 6月, 2018 3 次提交
  3. 15 6月, 2018 5 次提交
  4. 14 6月, 2018 3 次提交
    • C
      blk-mq: remove blk_mq_tagset_iter · e6c3456a
      Christoph Hellwig 提交于
      Unused now that nvme stopped using it.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NJens Axboe <axboe@kernel.dk>
      e6c3456a
    • C
      blk-mq: don't time out requests again that are in the timeout handler · da661267
      Christoph Hellwig 提交于
      We can currently call the timeout handler again on a request that has
      already been handed over to the timeout handler.  Prevent that with a new
      flag.
      
      Fixes: 12f5b931 ("blk-mq: Remove generation seqeunce")
      Reported-by: NAndrew Randrianasulu <randrianasulu@gmail.com>
      Tested-by: NAndrew Randrianasulu <randrianasulu@gmail.com>
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      da661267
    • L
      Kbuild: rename CC_STACKPROTECTOR[_STRONG] config variables · 050e9baa
      Linus Torvalds 提交于
      The changes to automatically test for working stack protector compiler
      support in the Kconfig files removed the special STACKPROTECTOR_AUTO
      option that picked the strongest stack protector that the compiler
      supported.
      
      That was all a nice cleanup - it makes no sense to have the AUTO case
      now that the Kconfig phase can just determine the compiler support
      directly.
      
      HOWEVER.
      
      It also meant that doing "make oldconfig" would now _disable_ the strong
      stackprotector if you had AUTO enabled, because in a legacy config file,
      the sane stack protector configuration would look like
      
        CONFIG_HAVE_CC_STACKPROTECTOR=y
        # CONFIG_CC_STACKPROTECTOR_NONE is not set
        # CONFIG_CC_STACKPROTECTOR_REGULAR is not set
        # CONFIG_CC_STACKPROTECTOR_STRONG is not set
        CONFIG_CC_STACKPROTECTOR_AUTO=y
      
      and when you ran this through "make oldconfig" with the Kbuild changes,
      it would ask you about the regular CONFIG_CC_STACKPROTECTOR (that had
      been renamed from CONFIG_CC_STACKPROTECTOR_REGULAR to just
      CONFIG_CC_STACKPROTECTOR), but it would think that the STRONG version
      used to be disabled (because it was really enabled by AUTO), and would
      disable it in the new config, resulting in:
      
        CONFIG_HAVE_CC_STACKPROTECTOR=y
        CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
        CONFIG_CC_STACKPROTECTOR=y
        # CONFIG_CC_STACKPROTECTOR_STRONG is not set
        CONFIG_CC_HAS_SANE_STACKPROTECTOR=y
      
      That's dangerously subtle - people could suddenly find themselves with
      the weaker stack protector setup without even realizing.
      
      The solution here is to just rename not just the old RECULAR stack
      protector option, but also the strong one.  This does that by just
      removing the CC_ prefix entirely for the user choices, because it really
      is not about the compiler support (the compiler support now instead
      automatially impacts _visibility_ of the options to users).
      
      This results in "make oldconfig" actually asking the user for their
      choice, so that we don't have any silent subtle security model changes.
      The end result would generally look like this:
      
        CONFIG_HAVE_CC_STACKPROTECTOR=y
        CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
        CONFIG_STACKPROTECTOR=y
        CONFIG_STACKPROTECTOR_STRONG=y
        CONFIG_CC_HAS_SANE_STACKPROTECTOR=y
      
      where the "CC_" versions really are about internal compiler
      infrastructure, not the user selections.
      Acked-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      050e9baa
  5. 13 6月, 2018 2 次提交
    • K
      mm: Introduce kvcalloc() · 1c542f38
      Kees Cook 提交于
      The kv*alloc()-family was missing kvcalloc(). Adding this allows for
      2-argument multiplication conversions of kvzalloc(a * b, ...) into
      kvcalloc(a, b, ...).
      Signed-off-by: NKees Cook <keescook@chromium.org>
      1c542f38
    • P
      netfilter: fix null-ptr-deref in nf_nat_decode_session · 155fb5c5
      Prashant Bhole 提交于
      Add null check for nat_hook in nf_nat_decode_session()
      
      [  195.648098] UBSAN: Undefined behaviour in ./include/linux/netfilter.h:348:14
      [  195.651366] BUG: KASAN: null-ptr-deref in __xfrm_policy_check+0x208/0x1d70
      [  195.653888] member access within null pointer of type 'struct nf_nat_hook'
      [  195.653896] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.17.0-rc6+ #5
      [  195.656320] Read of size 8 at addr 0000000000000008 by task ping/2469
      [  195.658715] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
      [  195.658721] Call Trace:
      [  195.661087]
      [  195.669341]  <IRQ>
      [  195.670574]  dump_stack+0xc6/0x150
      [  195.672156]  ? dump_stack_print_info.cold.0+0x1b/0x1b
      [  195.674121]  ? ubsan_prologue+0x31/0x92
      [  195.676546]  ubsan_epilogue+0x9/0x49
      [  195.678159]  handle_null_ptr_deref+0x11a/0x130
      [  195.679800]  ? sprint_OID+0x1a0/0x1a0
      [  195.681322]  __ubsan_handle_type_mismatch_v1+0xd5/0x11d
      [  195.683146]  ? ubsan_prologue+0x92/0x92
      [  195.684642]  __xfrm_policy_check+0x18ef/0x1d70
      [  195.686294]  ? rt_cache_valid+0x118/0x180
      [  195.687804]  ? __xfrm_route_forward+0x410/0x410
      [  195.689463]  ? fib_multipath_hash+0x700/0x700
      [  195.691109]  ? kvm_sched_clock_read+0x23/0x40
      [  195.692805]  ? pvclock_clocksource_read+0xf6/0x280
      [  195.694409]  ? graph_lock+0xa0/0xa0
      [  195.695824]  ? pvclock_clocksource_read+0xf6/0x280
      [  195.697508]  ? pvclock_read_flags+0x80/0x80
      [  195.698981]  ? kvm_sched_clock_read+0x23/0x40
      [  195.700347]  ? sched_clock+0x5/0x10
      [  195.701525]  ? sched_clock_cpu+0x18/0x1a0
      [  195.702846]  tcp_v4_rcv+0x1d32/0x1de0
      [  195.704115]  ? lock_repin_lock+0x70/0x270
      [  195.707072]  ? pvclock_read_flags+0x80/0x80
      [  195.709302]  ? tcp_v4_early_demux+0x4b0/0x4b0
      [  195.711833]  ? lock_acquire+0x195/0x380
      [  195.714222]  ? ip_local_deliver_finish+0xfc/0x770
      [  195.716967]  ? raw_rcv+0x2b0/0x2b0
      [  195.718856]  ? lock_release+0xa00/0xa00
      [  195.720938]  ip_local_deliver_finish+0x1b9/0x770
      [...]
      
      Fixes: 2c205dd3 ("netfilter: add struct nf_nat_hook and use it")
      Signed-off-by: NPrashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
      Acked-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      155fb5c5
  6. 12 6月, 2018 2 次提交
  7. 11 6月, 2018 1 次提交
  8. 10 6月, 2018 1 次提交
  9. 08 6月, 2018 22 次提交