1. 20 May, 2017 33 commits
  2. 14 May, 2017 7 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.11.1 · 4c71e91a
      Greg Kroah-Hartman authored
      4c71e91a
    • Ilya Dryomov's avatar
      block: get rid of blk_integrity_revalidate() · 0873ab02
      Ilya Dryomov authored
      commit 19b7ccf8 upstream.
      
      Commit 25520d55 ("block: Inline blk_integrity in struct gendisk")
      introduced blk_integrity_revalidate(), which seems to assume ownership
      of the stable pages flag and unilaterally clears it if no blk_integrity
      profile is registered:
      
          if (bi->profile)
                  disk->queue->backing_dev_info->capabilities |=
                          BDI_CAP_STABLE_WRITES;
          else
                  disk->queue->backing_dev_info->capabilities &=
                          ~BDI_CAP_STABLE_WRITES;
      
      It's called from revalidate_disk() and rescan_partitions(), making it
      impossible to enable stable pages for drivers that support partitions
      and don't use blk_integrity: while the call in revalidate_disk() can be
      trivially worked around (see zram, which doesn't support partitions and
      hence gets away with zram_revalidate_disk()), rescan_partitions() can
      be triggered from userspace at any time.  This breaks rbd, where the
      ceph messenger is responsible for generating/verifying CRCs.
      
      Since blk_integrity_{un,}register() "must" be used for (un)registering
      the integrity profile with the block layer, move BDI_CAP_STABLE_WRITES
      setting there.  This way drivers that call blk_integrity_register() and
      use integrity infrastructure won't interfere with drivers that don't
      but still want stable pages.
      
      Fixes: 25520d55 ("block: Inline blk_integrity in struct gendisk")
      Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Mike Snitzer <snitzer@redhat.com>
      Tested-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0873ab02
    • Boris Ostrovsky's avatar
      xen: Revert commits da72ff5b and 72a9b186 · 3ed024e2
      Boris Ostrovsky authored
      commit 84d582d2 upstream.
      
      Recent discussion (http://marc.info/?l=xen-devel&m=149192184523741)
      established that commit 72a9b186 ("xen: Remove event channel
      notification through Xen PCI platform device") (and thus commit
      da72ff5b ("partially revert "xen: Remove event channel
      notification through Xen PCI platform device"")) are unnecessary and,
      in fact, prevent HVM guests from booting on Xen releases prior to 4.0
      
      Therefore we revert both of those commits.
      
      The summary of that discussion is below:
      
        Here is the brief summary of the current situation:
      
        Before the offending commit (72a9b186):
      
        1) INTx does not work because of the reset_watches path.
        2) The reset_watches path is only taken if you have Xen > 4.0
        3) The Linux Kernel by default will use vector inject if the hypervisor
           support. So even INTx does not work no body running the kernel with
           Xen > 4.0 would notice. Unless he explicitly disabled this feature
           either in the kernel or in Xen (and this can only be disabled by
           modifying the code, not user-supported way to do it).
      
        After the offending commit (+ partial revert):
      
        1) INTx is no longer support for HVM (only for PV guests).
        2) Any HVM guest The kernel will not boot on Xen < 4.0 which does
           not have vector injection support. Since the only other mode
           supported is INTx which.
      
        So based on this summary, I think before commit (72a9b186) we were
        in much better position from a user point of view.
      Signed-off-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Reviewed-by: default avatarJuergen Gross <jgross@suse.com>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: x86@kernel.org
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Stefano Stabellini <sstabellini@kernel.org>
      Cc: Julien Grall <julien.grall@arm.com>
      Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Ross Lagerwall <ross.lagerwall@citrix.com>
      Cc: xen-devel@lists.xenproject.org
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-pci@vger.kernel.org
      Cc: Anthony Liguori <aliguori@amazon.com>
      Cc: KarimAllah Ahmed <karahmed@amazon.de>
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3ed024e2
    • Stefano Stabellini's avatar
      xen/arm,arm64: fix xen_dma_ops after 815dd187 "Consolidate get_dma_ops..." · 5e25479e
      Stefano Stabellini authored
      commit e0586326 upstream.
      
      The following commit:
      
        commit 815dd187
        Author: Bart Van Assche <bart.vanassche@sandisk.com>
        Date:   Fri Jan 20 13:04:04 2017 -0800
      
            treewide: Consolidate get_dma_ops() implementations
      
      rearranges get_dma_ops in a way that xen_dma_ops are not returned when
      running on Xen anymore, dev->dma_ops is returned instead (see
      arch/arm/include/asm/dma-mapping.h:get_arch_dma_ops and
      include/linux/dma-mapping.h:get_dma_ops).
      
      Fix the problem by storing dev->dma_ops in dev_archdata, and setting
      dev->dma_ops to xen_dma_ops. This way, xen_dma_ops is returned naturally
      by get_dma_ops. The Xen code can retrieve the original dev->dma_ops from
      dev_archdata when needed. It also allows us to remove __generic_dma_ops
      from common headers.
      Signed-off-by: default avatarStefano Stabellini <sstabellini@kernel.org>
      Tested-by: default avatarJulien Grall <julien.grall@arm.com>
      Suggested-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Reviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      CC: linux@armlinux.org.uk
      CC: catalin.marinas@arm.com
      CC: will.deacon@arm.com
      CC: boris.ostrovsky@oracle.com
      CC: jgross@suse.com
      CC: Julien Grall <julien.grall@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5e25479e
    • Jin Qian's avatar
      f2fs: sanity check segment count · c7f765b5
      Jin Qian authored
      commit b9dd4618 upstream.
      
      F2FS uses 4 bytes to represent block address. As a result, supported
      size of disk is 16 TB and it equals to 16 * 1024 * 1024 / 2 segments.
      Signed-off-by: default avatarJin Qian <jinqian@google.com>
      Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c7f765b5
    • Jon Mason's avatar
      net: mdio-mux: bcm-iproc: call mdiobus_free() in error path · 275e2edb
      Jon Mason authored
      [ Upstream commit 922c60e8 ]
      
      If an error is encountered in mdio_mux_init(), the error path will call
      mdiobus_free().  Since mdiobus_register() has been called prior to
      mdio_mux_init(), the bus->state will not be MDIOBUS_UNREGISTERED.  This
      causes a BUG_ON() in mdiobus_free().  To correct this issue, add an
      error path for mdio_mux_init() which calls mdiobus_unregister() prior to
      mdiobus_free().
      Signed-off-by: default avatarJon Mason <jon.mason@broadcom.com>
      Fixes: 98bc865a ("net: mdio-mux: Add MDIO mux driver for iProc SoCs")
      Acked-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      275e2edb
    • Daniel Borkmann's avatar
      bpf: don't let ldimm64 leak map addresses on unprivileged · ced12308
      Daniel Borkmann authored
      [ Upstream commit 0d0e5769 ]
      
      The patch fixes two things at once:
      
      1) It checks the env->allow_ptr_leaks and only prints the map address to
         the log if we have the privileges to do so, otherwise it just dumps 0
         as we would when kptr_restrict is enabled on %pK. Given the latter is
         off by default and not every distro sets it, I don't want to rely on
         this, hence the 0 by default for unprivileged.
      
      2) Printing of ldimm64 in the verifier log is currently broken in that
         we don't print the full immediate, but only the 32 bit part of the
         first insn part for ldimm64. Thus, fix this up as well; it's okay to
         access, since we verified all ldimm64 earlier already (including just
         constants) through replace_map_fd_with_map_ptr().
      
      Fixes: 1be7f75d ("bpf: enable non-root eBPF programs")
      Fixes: cbd35700 ("bpf: verifier (add ability to receive verification log)")
      Reported-by: default avatarJann Horn <jannh@google.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ced12308