Commit Graph

812570 Commits

Author SHA1 Message Date
Linus Torvalds 2d28e01dca Merge branch 'akpm' (patches from Andrew)
Merge misc fixes from Andrew Morton:
 "2 fixes"

* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
  hugetlbfs: fix races and page leaks during migration
  kasan: turn off asan-stack for clang-8 and earlier
2019-03-01 09:04:59 -08:00
Mike Kravetz cb6acd01e2 hugetlbfs: fix races and page leaks during migration
hugetlb pages should only be migrated if they are 'active'.  The
routines set/clear_page_huge_active() modify the active state of hugetlb
pages.

When a new hugetlb page is allocated at fault time, set_page_huge_active
is called before the page is locked.  Therefore, another thread could
race and migrate the page while it is being added to page table by the
fault code.  This race is somewhat hard to trigger, but can be seen by
strategically adding udelay to simulate worst case scheduling behavior.
Depending on 'how' the code races, various BUG()s could be triggered.

To address this issue, simply delay the set_page_huge_active call until
after the page is successfully added to the page table.

Hugetlb pages can also be leaked at migration time if the pages are
associated with a file in an explicitly mounted hugetlbfs filesystem.
For example, consider a two node system with 4GB worth of huge pages
available.  A program mmaps a 2G file in a hugetlbfs filesystem.  It
then migrates the pages associated with the file from one node to
another.  When the program exits, huge page counts are as follows:

  node0
  1024    free_hugepages
  1024    nr_hugepages

  node1
  0       free_hugepages
  1024    nr_hugepages

  Filesystem                         Size  Used Avail Use% Mounted on
  nodev                              4.0G  2.0G  2.0G  50% /var/opt/hugepool

That is as expected.  2G of huge pages are taken from the free_hugepages
counts, and 2G is the size of the file in the explicitly mounted
filesystem.  If the file is then removed, the counts become:

  node0
  1024    free_hugepages
  1024    nr_hugepages

  node1
  1024    free_hugepages
  1024    nr_hugepages

  Filesystem                         Size  Used Avail Use% Mounted on
  nodev                              4.0G  2.0G  2.0G  50% /var/opt/hugepool

Note that the filesystem still shows 2G of pages used, while there
actually are no huge pages in use.  The only way to 'fix' the filesystem
accounting is to unmount the filesystem

If a hugetlb page is associated with an explicitly mounted filesystem,
this information in contained in the page_private field.  At migration
time, this information is not preserved.  To fix, simply transfer
page_private from old to new page at migration time if necessary.

There is a related race with removing a huge page from a file and
migration.  When a huge page is removed from the pagecache, the
page_mapping() field is cleared, yet page_private remains set until the
page is actually freed by free_huge_page().  A page could be migrated
while in this state.  However, since page_mapping() is not set the
hugetlbfs specific routine to transfer page_private is not called and we
leak the page count in the filesystem.

To fix that, check for this condition before migrating a huge page.  If
the condition is detected, return EBUSY for the page.

Link: http://lkml.kernel.org/r/74510272-7319-7372-9ea6-ec914734c179@oracle.com
Link: http://lkml.kernel.org/r/20190212221400.3512-1-mike.kravetz@oracle.com
Fixes: bcc5422230 ("mm: hugetlb: introduce page_huge_active")
Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: <stable@vger.kernel.org>
[mike.kravetz@oracle.com: v2]
  Link: http://lkml.kernel.org/r/7534d322-d782-8ac6-1c8d-a8dc380eb3ab@oracle.com
[mike.kravetz@oracle.com: update comment and changelog]
  Link: http://lkml.kernel.org/r/420bcfd6-158b-38e4-98da-26d0cd85bd01@oracle.com
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-03-01 09:02:33 -08:00
Arnd Bergmann 6baec880d7 kasan: turn off asan-stack for clang-8 and earlier
Building an arm64 allmodconfig kernel with clang results in over 140
warnings about overly large stack frames, the worst ones being:

  drivers/gpu/drm/panel/panel-sitronix-st7789v.c:196:12: error: stack frame size of 20224 bytes in function 'st7789v_prepare'
  drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c:196:12: error: stack frame size of 13120 bytes in function 'td028ttec1_panel_enable'
  drivers/usb/host/max3421-hcd.c:1395:1: error: stack frame size of 10048 bytes in function 'max3421_spi_thread'
  drivers/net/wan/slic_ds26522.c:209:12: error: stack frame size of 9664 bytes in function 'slic_ds26522_probe'
  drivers/crypto/ccp/ccp-ops.c:2434:5: error: stack frame size of 8832 bytes in function 'ccp_run_cmd'
  drivers/media/dvb-frontends/stv0367.c:1005:12: error: stack frame size of 7840 bytes in function 'stv0367ter_algo'

None of these happen with gcc today, and almost all of these are the
result of a single known issue in llvm.  Hopefully it will eventually
get fixed with the clang-9 release.

In the meantime, the best idea I have is to turn off asan-stack for
clang-8 and earlier, so we can produce a kernel that is safe to run.

I have posted three patches that address the frame overflow warnings
that are not addressed by turning off asan-stack, so in combination with
this change, we get much closer to a clean allmodconfig build, which in
turn is necessary to do meaningful build regression testing.

It is still possible to turn on the CONFIG_ASAN_STACK option on all
versions of clang, and it's always enabled for gcc, but when
CONFIG_COMPILE_TEST is set, the option remains invisible, so
allmodconfig and randconfig builds (which are normally done with a
forced CONFIG_COMPILE_TEST) will still result in a mostly clean build.

Link: http://lkml.kernel.org/r/20190222222950.3997333-1-arnd@arndb.de
Link: https://bugs.llvm.org/show_bug.cgi?id=38809
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Qian Cai <cai@lca.pw>
Reviewed-by: Mark Brown <broonie@kernel.org>
Acked-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Kostya Serebryany <kcc@google.com>
Cc: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-03-01 09:02:33 -08:00
Linus Torvalds 6357c8127b drm amdgfx, bochs and one core fix
-----BEGIN PGP SIGNATURE-----
 
 iQIcBAABAgAGBQJceMUnAAoJEAx081l5xIa+n40P/iFOvzFXDdCaEf21XNdtH1Jk
 gjMBeMwxKdrQCsknaQhADtX/IwoSoUyu50jRhkdTQrhCwprkFFnq3LBt11QmYv/k
 Wj94D0yjIQAgnt+/rXi8ZKvH+MDZxmwGR+l9gRfKLywtreNaeLqjn875wkhzy6mB
 DgyfB4Xuyrpgg9K0yDbVdSQrxmHJuEx3VYVF/tvbL8HLFbxjhP2PV3eYhNxGC9Kj
 Ft1ulGZCfT8xQnxc1n/Bb+CHkQX9ZH2sVv8uezkaItEA7okboU71RCkMd5MjZ4AD
 HcmJEEpYv2dJPdGpnjrn2xfHKB/HEnBaGeFAIsfmhat5paYh7DV9gATFwQ8ZcCQ8
 HzX5/nD7rFA8G9gGjjVXYzCgX6egNtY6Oj35/IHfFJnKoqLeJvv7qkpX4OMUdcP8
 dB5TR+S6bD1VCDj6Wi7lFfA9uRBkpLbyDUhDnFS/fKvD0Ecw/BopwRnhTPn+lqtA
 50//WT5QZGQ+aRzzSxlIyfXJAyZBT2lr09r97G5noE0bal5iT8pc0xRiz6EHVrAd
 y9J2yLOpLrPym1av5RB5Nnj7Pohup9WPf29T7T5XbQ8kxuk+sK5EJt8NqD8KIyU6
 3RUG3cWlJGlWmX+V9GiMV/DnrfSZMnif0HUhxCxsDPmI0BHbQ3kn8vWtw9SAbHN2
 nFe8B5Ok057cb3FR8uYC
 =TtJZ
 -----END PGP SIGNATURE-----

Merge tag 'drm-fixes-2019-03-01' of git://anongit.freedesktop.org/drm/drm

Pull drm fixes from Dave Airlie:
 "Three final fixes, one for a feature that is new in this kernel, one
  bochs fix for qemu riscv and one atomic modesetting fix.

  I've left a few of the other late fixes until next as I didn't want to
  throw in anything that wasn't really necessary"

* tag 'drm-fixes-2019-03-01' of git://anongit.freedesktop.org/drm/drm:
  drm/bochs: Fix the ID mismatch error
  drm: Block fb changes for async plane updates
  drm/amd/display: Use vrr friendly pageflip throttling in DC.
2019-03-01 08:44:11 -08:00
Linus Torvalds bf23aba194 A few more MIPS fixes:
- Fix 16b cmpxchg() operations which could erroneously fail if bits 15:8
   of the old value are non-zero. In practice I'm not aware of any actual
   users of 16b cmpxchg() on MIPS, but this fixes the support for it was
   was introduced in v4.13.
 
 - Provide a struct device to dma_alloc_coherent for Lantiq XWAY systems
   with a "Voice MIPS Macro Core" (VMMC) device.
 
 - Provide DMA masks for BCM63xx ethernet devices, fixing a regression
   introduced in v4.19.
 
 - Fix memblock reservation for the kernel when the system has a non-zero
   PHYS_OFFSET, correcting the memblock conversion performed in v4.20.
 -----BEGIN PGP SIGNATURE-----
 
 iIsEABYIADMWIQRgLjeFAZEXQzy86/s+p5+stXUA3QUCXHhqjBUccGF1bC5idXJ0
 b25AbWlwcy5jb20ACgkQPqefrLV1AN3ZaAD/SFgi3dS9bSWhDhiy83llLaWiCGPb
 i09uzo3rpWoKSwQBAIwLEfmaHz/sYdliKRlE13uaxYWzwaN+VHXIPjlzbYMB
 =cDlO
 -----END PGP SIGNATURE-----

Merge tag 'mips_fixes_5.0_4' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux

Pull MIPS fixes from Paul Burton:
 "A few more MIPS fixes:

   - Fix 16b cmpxchg() operations which could erroneously fail if bits
     15:8 of the old value are non-zero. In practice I'm not aware of
     any actual users of 16b cmpxchg() on MIPS, but this fixes the
     support for it was was introduced in v4.13.

   - Provide a struct device to dma_alloc_coherent for Lantiq XWAY
     systems with a "Voice MIPS Macro Core" (VMMC) device.

   - Provide DMA masks for BCM63xx ethernet devices, fixing a regression
     introduced in v4.19.

   - Fix memblock reservation for the kernel when the system has a
     non-zero PHYS_OFFSET, correcting the memblock conversion performed
     in v4.20"

* tag 'mips_fixes_5.0_4' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux:
  MIPS: fix memory setup for platforms with PHYS_OFFSET != 0
  MIPS: BCM63XX: provide DMA masks for ethernet devices
  MIPS: lantiq: pass struct device to DMA API functions
  MIPS: fix truncation in __cmpxchg_small for short values
2019-02-28 15:33:10 -08:00
Linus Torvalds 3eb07d206d orangefs: remove two un-needed BUG_ONs
-----BEGIN PGP SIGNATURE-----
 
 iQIcBAABAgAGBQJcbwzZAAoJEM9EDqnrzg2++wsP/2T50hqUrotklzw86+cCf8cE
 ZmODCkXTC3b7ltwdIsjr0xMcJwDGOSPXA0+uUpwdT/4/3Aoz9/bKl05e1kPXpTUV
 BKALU4nyPgnF0i1tHxtt+UzU3k46zhWTfuZpCFFlrLh/iXrOte3Ypmdekh7ZsVv3
 /hhBlbeH7nFTq9TUZQXBeREoiHXhq7KIjml86Zu2KpaCgrpHPPieLv2zY5V4ulfF
 3Emw/PYtleEjfitswZiYwDiM8CtE02c02Ubjng/viyL+GnOy9URohizLyYV8j+h6
 te8gmTderF6MbXMFoHBn411PhapQVsn0JhS+Xzhtt9FEer1R1b1DCT5T9KPVng8Y
 0+I8JgpV6olJjenGp9GJZ1NNymzZcI48M/j96b/2oIIijDKUejVBxnfLtEGFl0Ca
 voEjjJXqSRX8fiKcbmqadjq6o9kgy/xUZP9I2xPx7t6zAwpB3yzRzAkDHyPX9s4+
 yFzqiVlcg+yUTIjlH28KNqH2KHgiltvLebkHkdL8YgbyJFVepnKaW5R3tNTvXuJD
 7Gg6/7TwKtdbfc+soBxQKlOWTKX+OJT5IyRxaFqvjAlLG3VKTcnhD1JxDOzMoFDR
 Ye7iqsUt3HoZbVRsyr+l+Sfy1mScRuSyy4OUvMNObgeH8OmBCx8V4Cynaxx1YKXf
 IxQi2iLMDo/qTGkdS6k3
 =1QBd
 -----END PGP SIGNATURE-----

Merge tag 'for-linus-5.0-ofs1' of git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linux

Pull orangefs fixlet from Mike Marshall:
 "Remove two un-needed BUG_ONs"

* tag 'for-linus-5.0-ofs1' of git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linux:
  orangefs: remove two un-needed BUG_ONs...
2019-02-28 15:22:59 -08:00
Linus Torvalds 3a8ed368fc MMC core:
- Fix NULL ptr crash for a special test case
  - Align max segment size with logical block size to prevent bugs in
    v5.1-rc1.
 MMC host:
  - cqhci: Minor fixes
  - tmio: Prevent interrupt storm
  - tmio: Fixup SD/MMC card initialization
  - spi: Allow card to be detected during probe
  - sdhci-esdhc-imx: Fixup fix for ERR004536
 -----BEGIN PGP SIGNATURE-----
 
 iQJLBAABCgA1FiEEugLDXPmKSktSkQsV/iaEJXNYjCkFAlx37bkXHHVsZi5oYW5z
 c29uQGxpbmFyby5vcmcACgkQ/iaEJXNYjCkaiQ//YvZnvb53gzrtUSIooF5unN9V
 EdwEjktonM9L60PolyUBksVWlHcALV7jCTuDxXRBsUgB98LIj7gwDLhbgatPFbV3
 dlCYY2EXW4IYvyfgAFQJ7hd9OalZftCrqvVU1T0sfetYhdP/um5cwQ2yxt/GjhTz
 fXbAjN4Gmn1PQheH9V1KM48EvNuotTsmrERbmFbrdDzWq8WV167A0nXd689qsd5G
 rkoL82/CcmfbnVOlDUyaYP/6YCRy+pJyTCoKinU49UHImsUvxebL2Ow3B+sp//eR
 I7t/ywpkoBvmKesQd4wPYFgobX0F6r7bFFlWQLqYmKtRNbZEPcpbchbUpqEr5npL
 rkRv4k5eg8iivmwfJH9i87A7fFsVE57iBzm8TS3dIseuGZsHCZlD6V+L5VJbTkex
 BSDVMETtugLTwGfwdjC+JHwbLIyAQMai+uMNJrZ3S93Bzlheqqhb7SaOx+J1fMx8
 ij8YKNTBf8Xo1BhnQPQbpIzOkbtzgtGfsjWVWrZygKDb5BL4IReqeUeyXPUMbCFO
 +cIKe9SuFdK95nCTT9QuOmFvHY6oNaJSjW5NtDzcTPPYZ0yWjxbOcfep6o0Lp131
 oIr2oF0jZdHiYZNCqk4HL1JBfsgG1Rb93H3ohHdux9zAZsRAv/VtQ125NTlCI/lT
 UgXNyLmZplXf4fiQa7Q=
 =82mm
 -----END PGP SIGNATURE-----

Merge tag 'mmc-v5.0-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc

Pull MMC fixes from Ulf Hansson:
 "MMC core:
   - Fix NULL ptr crash for a special test case
   - Align max segment size with logical block size to prevent bugs in
     v5.1-rc1.

  MMC host:
   - cqhci: Minor fixes
   - tmio: Prevent interrupt storm
   - tmio: Fixup SD/MMC card initialization
   - spi: Allow card to be detected during probe
   - sdhci-esdhc-imx: Fixup fix for ERR004536"

* tag 'mmc-v5.0-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc:
  mmc: sdhci-esdhc-imx: correct the fix of ERR004536
  mmc: core: align max segment size with logical block size
  mmc: cqhci: Fix a tiny potential memory leak on error condition
  mmc: cqhci: fix space allocated for transfer descriptor
  mmc: core: Fix NULL ptr crash from mmc_should_fail_request
  mmc: tmio: fix access width of Block Count Register
  mmc: tmio_mmc_core: don't claim spurious interrupts
  mmc: spi: Fix card detection during probe
2019-02-28 09:18:07 -08:00
Linus Torvalds 3f25a5990d Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
Pull crypto fixes from Herbert Xu:
 "This fixes a compiler warning introduced by a previous fix, as well as
  two crash bugs on ARM"

* 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
  crypto: sha512/arm - fix crash bug in Thumb2 build
  crypto: sha256/arm - fix crash bug in Thumb2 build
  crypto: ccree - add missing inline qualifier
2019-02-28 09:05:18 -08:00
Greg Kroah-Hartman 8ed0579c12 kvm: properly check debugfs dentry before using it
debugfs can now report an error code if something went wrong instead of
just NULL.  So if the return value is to be used as a "real" dentry, it
needs to be checked if it is an error before dereferencing it.

This is now happening because of ff9fb72bc0 ("debugfs: return error
values, not NULL").  syzbot has found a way to trigger multiple debugfs
files attempting to be created, which fails, and then the error code
gets passed to dentry_path_raw() which obviously does not like it.

Reported-by: Eric Biggers <ebiggers@kernel.org>
Reported-and-tested-by: syzbot+7857962b4d45e602b8ad@syzkaller.appspotmail.com
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: kvm@vger.kernel.org
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-02-28 08:57:32 -08:00
BOUGH CHEN e30be063d6 mmc: sdhci-esdhc-imx: correct the fix of ERR004536
Commit 18094430d6 ("mmc: sdhci-esdhc-imx: add ADMA Length
Mismatch errata fix") involve the fix of ERR004536, but the
fix is incorrect. Double confirm with IC, need to clear the
bit 7 of register 0x6c rather than set this bit 7.
Here is the definition of bit 7 of 0x6c:
    0: enable the new IC fix for ERR004536
    1: do not use the IC fix, keep the same as before

Find this issue on i.MX845s-evk board when enable CMDQ, and
let system in heavy loading.

root@imx8mmevk:~# dd if=/dev/mmcblk2 of=/dev/null bs=1M &
root@imx8mmevk:~# memtester 1000M > /dev/zero &
root@imx8mmevk:~# [  139.897220] mmc2: cqhci: timeout for tag 16
[  139.901417] mmc2: cqhci: ============ CQHCI REGISTER DUMP ===========
[  139.907862] mmc2: cqhci: Caps:      0x0000310a | Version:  0x00000510
[  139.914311] mmc2: cqhci: Config:    0x00001001 | Control:  0x00000000
[  139.920753] mmc2: cqhci: Int stat:  0x00000000 | Int enab: 0x00000006
[  139.927193] mmc2: cqhci: Int sig:   0x00000006 | Int Coal: 0x00000000
[  139.933634] mmc2: cqhci: TDL base:  0x7809c000 | TDL up32: 0x00000000
[  139.940073] mmc2: cqhci: Doorbell:  0x00030000 | TCN:      0x00000000
[  139.946518] mmc2: cqhci: Dev queue: 0x00010000 | Dev Pend: 0x00010000
[  139.952967] mmc2: cqhci: Task clr:  0x00000000 | SSC1:     0x00011000
[  139.959411] mmc2: cqhci: SSC2:      0x00000001 | DCMD rsp: 0x00000000
[  139.965857] mmc2: cqhci: RED mask:  0xfdf9a080 | TERRI:    0x00000000
[  139.972308] mmc2: cqhci: Resp idx:  0x0000002e | Resp arg: 0x00000900
[  139.978761] mmc2: sdhci: ============ SDHCI REGISTER DUMP ===========
[  139.985214] mmc2: sdhci: Sys addr:  0xb2c19000 | Version:  0x00000002
[  139.991669] mmc2: sdhci: Blk size:  0x00000200 | Blk cnt:  0x00000400
[  139.998127] mmc2: sdhci: Argument:  0x40110400 | Trn mode: 0x00000033
[  140.004618] mmc2: sdhci: Present:   0x01088a8f | Host ctl: 0x00000030
[  140.011113] mmc2: sdhci: Power:     0x00000002 | Blk gap:  0x00000080
[  140.017583] mmc2: sdhci: Wake-up:   0x00000008 | Clock:    0x0000000f
[  140.024039] mmc2: sdhci: Timeout:   0x0000008f | Int stat: 0x00000000
[  140.030497] mmc2: sdhci: Int enab:  0x107f4000 | Sig enab: 0x107f4000
[  140.036972] mmc2: sdhci: AC12 err:  0x00000000 | Slot int: 0x00000502
[  140.043426] mmc2: sdhci: Caps:      0x07eb0000 | Caps_1:   0x8000b407
[  140.049867] mmc2: sdhci: Cmd:       0x00002c1a | Max curr: 0x00ffffff
[  140.056314] mmc2: sdhci: Resp[0]:   0x00000900 | Resp[1]:  0xffffffff
[  140.062755] mmc2: sdhci: Resp[2]:   0x328f5903 | Resp[3]:  0x00d00f00
[  140.069195] mmc2: sdhci: Host ctl2: 0x00000008
[  140.073640] mmc2: sdhci: ADMA Err:  0x00000007 | ADMA Ptr: 0x7809c108
[  140.080079] mmc2: sdhci: ============================================
[  140.086662] mmc2: running CQE recovery

Fixes: 18094430d6 ("mmc: sdhci-esdhc-imx: add ADMA Length Mismatch errata fix")
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-02-28 12:18:31 +01:00
Alistair Francis 17fb465f16 drm/bochs: Fix the ID mismatch error
When running RISC-V QEMU with the Bochs device attached via PCIe the
probe of the Bochs device fails with:
    [drm:bochs_hw_init] *ERROR* ID mismatch

This was introduced by this commit:
    7780eb9ce8 bochs: convert to drm_dev_register

To fix the error we ensure that pci_enable_device() is called before
bochs_load().

Fixes: 7780eb9ce8 ("bochs: convert to drm_dev_register")
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Reported-by: David Abdurachmanov <david.abdurachmanov@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20190221003231.31625-1-alistair.francis@wdc.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2019-02-28 14:05:33 +10:00
Nicholas Kazlauskas 2216322919 drm: Block fb changes for async plane updates
The prepare_fb call always happens on new_plane_state.

The drm_atomic_helper_cleanup_planes checks to see if
plane state pointer has changed when deciding to call cleanup_fb on
either the new_plane_state or the old_plane_state.

For a non-async atomic commit the state pointer is swapped, so this
helper calls prepare_fb on the new_plane_state and cleanup_fb on the
old_plane_state. This makes sense, since we want to prepare the
framebuffer we are going to use and cleanup the the framebuffer we are
no longer using.

For the async atomic update helpers this differs. The async atomic
update helpers perform in-place updates on the existing state. They call
drm_atomic_helper_cleanup_planes but the state pointer is not swapped.
This means that prepare_fb is called on the new_plane_state and
cleanup_fb is called on the new_plane_state (not the old).

In the case where old_plane_state->fb == new_plane_state->fb then
there should be no behavioral difference between an async update
and a non-async commit. But there are issues that arise when
old_plane_state->fb != new_plane_state->fb.

The first is that the new_plane_state->fb is immediately cleaned up
after it has been prepared, so we're using a fb that we shouldn't
be.

The second occurs during a sequence of async atomic updates and
non-async regular atomic commits. Suppose there are two framebuffers
being interleaved in a double-buffering scenario, fb1 and fb2:

- Async update, oldfb = NULL, newfb = fb1, prepare fb1, cleanup fb1
- Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb2
- Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2

We call cleanup_fb on fb2 twice in this example scenario, and any
further use will result in use-after-free.

The simple fix to this problem is to block framebuffer changes
in the drm_atomic_helper_async_check function for now.

v2: Move check by itself, add a FIXME (Daniel)

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Cc: <stable@vger.kernel.org> # v4.14+
Fixes: fef9df8b59 ("drm/atomic: initial support for asynchronous plane update")
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Acked-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Link: https://patchwork.freedesktop.org/patch/275364/
Signed-off-by: Dave Airlie <airlied@redhat.com>
2019-02-28 14:05:30 +10:00
Thomas Bogendoerfer e0bf304e4a
MIPS: fix memory setup for platforms with PHYS_OFFSET != 0
For platforms, which use a PHYS_OFFSET != 0, symbol _end also
contains that offset. So when calling memblock_reserve() for
reserving kernel the size argument needs to be adjusted.

Fixes: bcec54bf31 ("mips: switch to NO_BOOTMEM")
Acked-by: Mike Rapoport <rppt@linux.ibm.com>
Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de>
Signed-off-by: Paul Burton <paul.burton@mips.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: James Hogan <jhogan@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
Cc: stable@vger.kernel.org # v4.20+
2019-02-27 18:49:29 -08:00
Dave Airlie 90b5e58ebe Merge branch 'drm-fixes-5.0' of git://people.freedesktop.org/~agd5f/linux into drm-fixes
Fix for variable refresh rate stuttering

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190227192115.14597-1-alexander.deucher@amd.com
2019-02-28 12:40:17 +10:00
Jann Horn 0a1d52994d mm: enforce min addr even if capable() in expand_downwards()
security_mmap_addr() does a capability check with current_cred(), but
we can reach this code from contexts like a VFS write handler where
current_cred() must not be used.

This can be abused on systems without SMAP to make NULL pointer
dereferences exploitable again.

Fixes: 8869477a49 ("security: protect from stack expansion into low vm addresses")
Cc: stable@kernel.org
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-02-27 17:27:02 -08:00
Mario Kleiner d63716658a drm/amd/display: Use vrr friendly pageflip throttling in DC.
In VRR mode, keep track of the vblank count of the last
completed pageflip in amdgpu_crtc->last_flip_vblank, as
recorded in the pageflip completion handler after each
completed flip.

Use that count to prevent mmio programming a new pageflip
within the same vblank in which the last pageflip completed,
iow. to throttle pageflips to at most one flip per video
frame, while at the same time allowing to request a flip
not only before start of vblank, but also anywhere within
vblank.

The old logic did the same, and made sense for regular fixed
refresh rate flipping, but in vrr mode it prevents requesting
a flip anywhere inside the possibly huge vblank, thereby
reducing framerate in vrr mode instead of improving it, by
delaying a slightly delayed flip requests up to a maximum
vblank duration + 1 scanout duration. This would limit VRR
usefulness to only help applications with a very high GPU
demand, which can submit the flip request before start of
vblank, but then have to wait long for fences to complete.

With this method a flip can be both requested and - after
fences have completed - executed, ie. it doesn't matter if
the request (amdgpu_dm_do_flip()) gets delayed until deep
into the extended vblank due to cpu execution delays. This
also allows clients which want to regulate framerate within
the vrr range a much more fine-grained control of flip timing,
a feature that might be useful for video playback, and is
very useful for neuroscience/vision research applications.

In regular non-VRR mode, retain the old flip submission
behavior. This to keep flip scheduling for fullscreen X11/GLX
OpenGL clients intact, if they use the GLX_OML_sync_control
extensions glXSwapBufferMscOML(, ..., target_msc,...) function
with a specific target_msc target vblank count.

glXSwapBuffersMscOML() or DRI3/Present PresentPixmap() will
not flip at the proper target_msc for a non-zero target_msc
if VRR mode is active with this patch. They'd often flip one
frame too early. However, this limitation should not matter
much in VRR mode, as scheduling based on vblank counts is
pretty futile/unusable under variable refresh duration
anyway, so no real extra harm is done.

Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-27 13:55:09 -05:00
Ming Lei c53336c8f5 mmc: core: align max segment size with logical block size
Logical block size is the lowest possible block size that the storage
device can address. Max segment size is often related with controller's
DMA capability. And it is reasonable to align max segment size with
logical block size.

SDHCI sets un-aligned max segment size, and causes ADMA error, so
fix it by aligning max segment size with logical block size.

Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Naresh Kamboju <naresh.kamboju@linaro.org>
Cc: Faiz Abbas <faiz_abbas@ti.com>
Cc: linux-block@vger.kernel.org
Signed-off-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-02-27 18:01:25 +01:00
Alamy Liu d07e9fadf3 mmc: cqhci: Fix a tiny potential memory leak on error condition
Free up the allocated memory in the case of error return

The value of mmc_host->cqe_enabled stays 'false'. Thus, cqhci_disable
(mmc_cqe_ops->cqe_disable) won't be called to free the memory.  Also,
cqhci_disable() seems to be designed to disable and free all resources, not
suitable to handle this corner case.

Fixes: a4080225f5 ("mmc: cqhci: support for command queue enabled host")
Signed-off-by: Alamy Liu <alamy.liu@gmail.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-02-27 15:06:45 +01:00
Alamy Liu 27ec9dc17c mmc: cqhci: fix space allocated for transfer descriptor
There is not enough space being allocated when DCMD is disabled.

CQE_DCMD is not necessary to be enabled when CQE is enabled.
(Software could halt CQE to send command)

In the case that CQE_DCMD is not enabled, it still needs to allocate
space for data transfer. For instance:
  CQE_DCMD is enabled:  31 slots space (one slot used by DCMD)
  CQE_DCMD is disabled: 32 slots space

Fixes: a4080225f5 ("mmc: cqhci: support for command queue enabled host")
Signed-off-by: Alamy Liu <alamy.liu@gmail.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-02-27 15:06:31 +01:00
Ritesh Harjani e5723f95d6 mmc: core: Fix NULL ptr crash from mmc_should_fail_request
In case of CQHCI, mrq->cmd may be NULL for data requests (non DCMD).
In such case mmc_should_fail_request is directly dereferencing
mrq->cmd while cmd is NULL.
Fix this by checking for mrq->cmd pointer.

Fixes: 72a5af554d ("mmc: core: Add support for handling CQE requests")
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-02-27 10:00:17 +01:00
Takeshi Saito 5603731a15 mmc: tmio: fix access width of Block Count Register
In R-Car Gen2 or later, the maximum number of transfer blocks are
changed from 0xFFFF to 0xFFFFFFFF. Therefore, Block Count Register
should use iowrite32().

If another system (U-boot, Hypervisor OS, etc) uses bit[31:16], this
value will not be cleared. So, SD/MMC card initialization fails.

So, check for the bigger register and use apropriate write. Also, mark
the register as extended on Gen2.

Signed-off-by: Takeshi Saito <takeshi.saito.xv@renesas.com>
[wsa: use max_blk_count in if(), add Gen2, update commit message]
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: stable@kernel.org
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
[Ulf: Fixed build error]
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-02-26 10:01:49 +01:00
Jonas Gorski 18836b48eb
MIPS: BCM63XX: provide DMA masks for ethernet devices
The switch to the generic dma ops made dma masks mandatory, breaking
devices having them not set. In case of bcm63xx, it broke ethernet with
the following warning when trying to up the device:

[    2.633123] ------------[ cut here ]------------
[    2.637949] WARNING: CPU: 0 PID: 325 at ./include/linux/dma-mapping.h:516 bcm_enetsw_open+0x160/0xbbc
[    2.647423] Modules linked in: gpio_button_hotplug
[    2.652361] CPU: 0 PID: 325 Comm: ip Not tainted 4.19.16 #0
[    2.658080] Stack : 80520000 804cd3ec 00000000 00000000 804ccc00 87085bdc 87d3f9d4 804f9a17
[    2.666707]         8049cf18 00000145 80a942a0 00000204 80ac0000 10008400 87085b90 eb3d5ab7
[    2.675325]         00000000 00000000 80ac0000 000022b0 00000000 00000000 00000007 00000000
[    2.683954]         0000007a 80500000 0013b381 00000000 80000000 00000000 804a1664 80289878
[    2.692572]         00000009 00000204 80ac0000 00000200 00000002 00000000 00000000 80a90000
[    2.701191]         ...
[    2.703701] Call Trace:
[    2.706244] [<8001f3c8>] show_stack+0x58/0x100
[    2.710840] [<800336e4>] __warn+0xe4/0x118
[    2.715049] [<800337d4>] warn_slowpath_null+0x48/0x64
[    2.720237] [<80289878>] bcm_enetsw_open+0x160/0xbbc
[    2.725347] [<802d1d4c>] __dev_open+0xf8/0x16c
[    2.729913] [<802d20cc>] __dev_change_flags+0x100/0x1c4
[    2.735290] [<802d21b8>] dev_change_flags+0x28/0x70
[    2.740326] [<803539e0>] devinet_ioctl+0x310/0x7b0
[    2.745250] [<80355fd8>] inet_ioctl+0x1f8/0x224
[    2.749939] [<802af290>] sock_ioctl+0x30c/0x488
[    2.754632] [<80112b34>] do_vfs_ioctl+0x740/0x7dc
[    2.759459] [<80112c20>] ksys_ioctl+0x50/0x94
[    2.763955] [<800240b8>] syscall_common+0x34/0x58
[    2.768782] ---[ end trace fb1a6b14d74e28b6 ]---
[    2.773544] bcm63xx_enetsw bcm63xx_enetsw.0: cannot allocate rx ring 512

Fix this by adding appropriate DMA masks for the platform devices.

Fixes: f8c55dc6e8 ("MIPS: use generic dma noncoherent ops for simple noncoherent platforms")
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Paul Burton <paul.burton@mips.com>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: James Hogan <jhogan@kernel.org>
Cc: stable@vger.kernel.org # v4.19+
2019-02-25 12:56:39 -08:00
David Howells 7d762d6914 afs: Fix manually set volume location server list
When a cell with a volume location server list is added manually by
echoing the details into /proc/net/afs/cells, a record is added but the
flag saying it has been looked up isn't set.

This causes the VL server rotation code to wait forever, with the top of
/proc/pid/stack looking like:

	afs_select_vlserver+0x3a6/0x6f3
	afs_vl_lookup_vldb+0x4b/0x92
	afs_create_volume+0x25/0x1b9
	...

with the thread stuck in afs_start_vl_iteration() waiting for
AFS_CELL_FL_NO_LOOKUP_YET to be cleared.

Fix this by clearing AFS_CELL_FL_NO_LOOKUP_YET when setting up a record
if that record's details were supplied manually.

Fixes: 0a5143f2f8 ("afs: Implement VL server rotation")
Reported-by: Dave Botsch <dwb7@cornell.edu>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-02-25 11:59:07 -08:00
Darrick J. Wong 29b00e6099 tmpfs: fix uninitialized return value in shmem_link
When we made the shmem_reserve_inode call in shmem_link conditional, we
forgot to update the declaration for ret so that it always has a known
value.  Dan Carpenter pointed out this deficiency in the original patch.

Fixes: 1062af920c ("tmpfs: fix link accounting when a tmpfile is linked in")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Hugh Dickins <hughd@google.com>
Cc: Matej Kupljen <matej.kupljen@gmail.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-02-25 11:49:22 -08:00
Linus Torvalds 53a41cb7ed Revert "x86/fault: BUG() when uaccess helpers fault on kernel addresses"
This reverts commit 9da3f2b740.

It was well-intentioned, but wrong.  Overriding the exception tables for
instructions for random reasons is just wrong, and that is what the new
code did.

It caused problems for tracing, and it caused problems for strncpy_from_user(),
because the new checks made perfectly valid use cases break, rather than
catch things that did bad things.

Unchecked user space accesses are a problem, but that's not a reason to
add invalid checks that then people have to work around with silly flags
(in this case, that 'kernel_uaccess_faults_ok' flag, which is just an
odd way to say "this commit was wrong" and was sprinked into random
places to hide the wrongness).

The real fix to unchecked user space accesses is to get rid of the
special "let's not check __get_user() and __put_user() at all" logic.
Make __{get|put}_user() be just aliases to the regular {get|put}_user()
functions, and make it impossible to access user space without having
the proper checks in places.

The raison d'être of the special double-underscore versions used to be
that the range check was expensive, and if you did multiple user
accesses, you'd do the range check up front (like the signal frame
handling code, for example).  But SMAP (on x86) and PAN (on ARM) have
made that optimization pointless, because the _real_ expense is the "set
CPU flag to allow user space access".

Do let's not break the valid cases to catch invalid cases that shouldn't
even exist.

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Kees Cook <keescook@chromium.org>
Cc: Tobin C. Harding <tobin@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Jann Horn <jannh@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-02-25 09:10:51 -08:00
Sergei Shtylyov 5c27ff5db1 mmc: tmio_mmc_core: don't claim spurious interrupts
I have encountered an interrupt storm during the eMMC chip probing (and
the chip finally didn't get detected).  It turned out that U-Boot left
the DMAC interrupts enabled while the Linux driver  didn't use those.
The SDHI driver's interrupt handler somehow assumes that, even if an
SDIO interrupt didn't happen, it should return IRQ_HANDLED.  I think
that if none of the enabled interrupts happened and got handled, we
should return IRQ_NONE -- that way the kernel IRQ code recoginizes
a spurious interrupt and masks it off pretty quickly...

Fixes: 7729c7a232 ("mmc: tmio: Provide separate interrupt handlers")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-02-25 17:25:13 +01:00
Jonathan Neuschäfer c9bd505dbd mmc: spi: Fix card detection during probe
When using the mmc_spi driver with a card-detect pin, I noticed that the
card was not detected immediately after probe, but only after it was
unplugged and plugged back in (and the CD IRQ fired).

The call tree looks something like this:

mmc_spi_probe
  mmc_add_host
    mmc_start_host
      _mmc_detect_change
        mmc_schedule_delayed_work(&host->detect, 0)
          mmc_rescan
            host->bus_ops->detect(host)
              mmc_detect
                _mmc_detect_card_removed
                  host->ops->get_cd(host)
                    mmc_gpio_get_cd -> -ENOSYS (ctx->cd_gpio not set)
  mmc_gpiod_request_cd
    ctx->cd_gpio = desc

To fix this issue, call mmc_detect_change after the card-detect GPIO/IRQ
is registered.

Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-02-25 15:40:36 +01:00
Linus Torvalds 5908e6b738 Linux 5.0-rc8 2019-02-24 16:46:45 -08:00
Linus Torvalds c3619a482e Bug fixes.
-----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.22 (GNU/Linux)
 
 iQEcBAABAgAGBQJcclOnAAoJEL/70l94x66DAjIH/28XLAkaAtJIsm4nTy3sb6nC
 UC7suhEEst4zyRCzUlMdeaMkuWJitx5Bun0x9k5uYvMXqmndXcGq3wLmrRhOY2u2
 iN1myLESOn0+lubVcK/+ht2rat2AO9XqpOKPojBRs/c6MW1UAIJIPKly/ls1++Ee
 TmdIKrgqGgE5Ywx4ObvXBDOeWSKUwxqqNi7FUkWpACJckvmQoKJX0Hre5ICW6lom
 +yUBC1rR9apMLTe2QIW2kBZ9JTKCX0aErdmnLXlyZbFOOk0udzNaDy+kXSs7w9Bk
 tu8biO7xBNJrcR5e+fEipVFIdN9au0aM5pJWq9s4yeqSnDKB1FRekoJj5yvTqus=
 =1GQR
 -----END PGP SIGNATURE-----

Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm

Pull KVM fixes from Paolo Bonzini:
 "Bug fixes"

* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
  KVM: MMU: record maximum physical address width in kvm_mmu_extended_role
  kvm: x86: Return LA57 feature based on hardware capability
  x86/kvm/mmu: fix switch between root and guest MMUs
  s390: vsie: Use effective CRYCBD.31 to check CRYCBD validity
2019-02-24 09:47:07 -08:00
Linus Torvalds c4eb1e1852 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
Pull networking fixes from David Miller:
 "Hopefully the last pull request for this release. Fingers crossed:

   1) Only refcount ESP stats on full sockets, from Martin Willi.

   2) Missing barriers in AF_UNIX, from Al Viro.

   3) RCU protection fixes in ipv6 route code, from Paolo Abeni.

   4) Avoid false positives in untrusted GSO validation, from Willem de
      Bruijn.

   5) Forwarded mesh packets in mac80211 need more tailroom allocated,
      from Felix Fietkau.

   6) Use operstate consistently for linkup in team driver, from George
      Wilkie.

   7) ThunderX bug fixes from Vadim Lomovtsev. Mostly races between VF
      and PF code paths.

   8) Purge ipv6 exceptions during netdevice removal, from Paolo Abeni.

   9) nfp eBPF code gen fixes from Jiong Wang.

  10) bnxt_en firmware timeout fix from Michael Chan.

  11) Use after free in udp/udpv6 error handlers, from Paolo Abeni.

  12) Fix a race in x25_bind triggerable by syzbot, from Eric Dumazet"

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (65 commits)
  net: phy: realtek: Dummy IRQ calls for RTL8366RB
  tcp: repaired skbs must init their tso_segs
  net/x25: fix a race in x25_bind()
  net: dsa: Remove documentation for port_fdb_prepare
  Revert "bridge: do not add port to router list when receives query with source 0.0.0.0"
  selftests: fib_tests: sleep after changing carrier. again.
  net: set static variable an initial value in atl2_probe()
  net: phy: marvell10g: Fix Multi-G advertisement to only advertise 10G
  bpf, doc: add bpf list as secondary entry to maintainers file
  udp: fix possible user after free in error handler
  udpv6: fix possible user after free in error handler
  fou6: fix proto error handler argument type
  udpv6: add the required annotation to mib type
  mdio_bus: Fix use-after-free on device_register fails
  net: Set rtm_table to RT_TABLE_COMPAT for ipv6 for tables > 255
  bnxt_en: Wait longer for the firmware message response to complete.
  bnxt_en: Fix typo in firmware message timeout logic.
  nfp: bpf: fix ALU32 high bits clearance bug
  nfp: bpf: fix code-gen bug on BPF_ALU | BPF_XOR | BPF_K
  Documentation: networking: switchdev: Update port parent ID section
  ...
2019-02-24 09:28:26 -08:00
Linus Walleij 4c8e0459b5 net: phy: realtek: Dummy IRQ calls for RTL8366RB
This fixes a regression introduced by
commit 0d2e778e38
"net: phy: replace PHY_HAS_INTERRUPT with a check for
config_intr and ack_interrupt".

This assumes that a PHY cannot trigger interrupt unless
it has .config_intr() or .ack_interrupt() implemented.
A later patch makes the code assume both need to be
implemented for interrupts to be present.

But this PHY (which is inside a DSA) will happily
fire interrupts without either callback.

Implement dummy callbacks for .config_intr() and
.ack_interrupt() in the phy header to fix this.

Tested on the RTL8366RB on D-Link DIR-685.

Fixes: 0d2e778e38 ("net: phy: replace PHY_HAS_INTERRUPT with a check for config_intr and ack_interrupt")
Cc: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-23 18:45:28 -08:00
Eric Dumazet bf50b606cf tcp: repaired skbs must init their tso_segs
syzbot reported a WARN_ON(!tcp_skb_pcount(skb))
in tcp_send_loss_probe() [1]

This was caused by TCP_REPAIR sent skbs that inadvertenly
were missing a call to tcp_init_tso_segs()

[1]
WARNING: CPU: 1 PID: 0 at net/ipv4/tcp_output.c:2534 tcp_send_loss_probe+0x771/0x8a0 net/ipv4/tcp_output.c:2534
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.0.0-rc7+ #77
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
 <IRQ>
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x172/0x1f0 lib/dump_stack.c:113
 panic+0x2cb/0x65c kernel/panic.c:214
 __warn.cold+0x20/0x45 kernel/panic.c:571
 report_bug+0x263/0x2b0 lib/bug.c:186
 fixup_bug arch/x86/kernel/traps.c:178 [inline]
 fixup_bug arch/x86/kernel/traps.c:173 [inline]
 do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:271
 do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:290
 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:973
RIP: 0010:tcp_send_loss_probe+0x771/0x8a0 net/ipv4/tcp_output.c:2534
Code: 88 fc ff ff 4c 89 ef e8 ed 75 c8 fb e9 c8 fc ff ff e8 43 76 c8 fb e9 63 fd ff ff e8 d9 75 c8 fb e9 94 f9 ff ff e8 bf 03 91 fb <0f> 0b e9 7d fa ff ff e8 b3 03 91 fb 0f b6 1d 37 43 7a 03 31 ff 89
RSP: 0018:ffff8880ae907c60 EFLAGS: 00010206
RAX: ffff8880a989c340 RBX: 0000000000000000 RCX: ffffffff85dedbdb
RDX: 0000000000000100 RSI: ffffffff85dee0b1 RDI: 0000000000000005
RBP: ffff8880ae907c90 R08: ffff8880a989c340 R09: ffffed10147d1ae1
R10: ffffed10147d1ae0 R11: ffff8880a3e8d703 R12: ffff888091b90040
R13: ffff8880a3e8d540 R14: 0000000000008000 R15: ffff888091b90860
 tcp_write_timer_handler+0x5c0/0x8a0 net/ipv4/tcp_timer.c:583
 tcp_write_timer+0x10e/0x1d0 net/ipv4/tcp_timer.c:607
 call_timer_fn+0x190/0x720 kernel/time/timer.c:1325
 expire_timers kernel/time/timer.c:1362 [inline]
 __run_timers kernel/time/timer.c:1681 [inline]
 __run_timers kernel/time/timer.c:1649 [inline]
 run_timer_softirq+0x652/0x1700 kernel/time/timer.c:1694
 __do_softirq+0x266/0x95a kernel/softirq.c:292
 invoke_softirq kernel/softirq.c:373 [inline]
 irq_exit+0x180/0x1d0 kernel/softirq.c:413
 exiting_irq arch/x86/include/asm/apic.h:536 [inline]
 smp_apic_timer_interrupt+0x14a/0x570 arch/x86/kernel/apic/apic.c:1062
 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:807
 </IRQ>
RIP: 0010:native_safe_halt+0x2/0x10 arch/x86/include/asm/irqflags.h:58
Code: ff ff ff 48 89 c7 48 89 45 d8 e8 59 0c a1 fa 48 8b 45 d8 e9 ce fe ff ff 48 89 df e8 48 0c a1 fa eb 82 90 90 90 90 90 90 fb f4 <c3> 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 f4 c3 90 90 90 90 90 90
RSP: 0018:ffff8880a98afd78 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff13
RAX: 1ffffffff1125061 RBX: ffff8880a989c340 RCX: 0000000000000000
RDX: dffffc0000000000 RSI: 0000000000000001 RDI: ffff8880a989cbbc
RBP: ffff8880a98afda8 R08: ffff8880a989c340 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001
R13: ffffffff889282f8 R14: 0000000000000001 R15: 0000000000000000
 arch_cpu_idle+0x10/0x20 arch/x86/kernel/process.c:555
 default_idle_call+0x36/0x90 kernel/sched/idle.c:93
 cpuidle_idle_call kernel/sched/idle.c:153 [inline]
 do_idle+0x386/0x570 kernel/sched/idle.c:262
 cpu_startup_entry+0x1b/0x20 kernel/sched/idle.c:353
 start_secondary+0x404/0x5c0 arch/x86/kernel/smpboot.c:271
 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243
Kernel Offset: disabled
Rebooting in 86400 seconds..

Fixes: 79861919b8 ("tcp: fix TCP_REPAIR xmit queue setup")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Cc: Andrey Vagin <avagin@openvz.org>
Cc: Soheil Hassas Yeganeh <soheil@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-23 18:43:25 -08:00
Eric Dumazet 797a22bd52 net/x25: fix a race in x25_bind()
syzbot was able to trigger another soft lockup [1]

I first thought it was the O(N^2) issue I mentioned in my
prior fix (f657d22ee1f "net/x25: do not hold the cpu
too long in x25_new_lci()"), but I eventually found
that x25_bind() was not checking SOCK_ZAPPED state under
socket lock protection.

This means that multiple threads can end up calling
x25_insert_socket() for the same socket, and corrupt x25_list

[1]
watchdog: BUG: soft lockup - CPU#0 stuck for 123s! [syz-executor.2:10492]
Modules linked in:
irq event stamp: 27515
hardirqs last  enabled at (27514): [<ffffffff81006673>] trace_hardirqs_on_thunk+0x1a/0x1c
hardirqs last disabled at (27515): [<ffffffff8100668f>] trace_hardirqs_off_thunk+0x1a/0x1c
softirqs last  enabled at (32): [<ffffffff8632ee73>] x25_get_neigh+0xa3/0xd0 net/x25/x25_link.c:336
softirqs last disabled at (34): [<ffffffff86324bc3>] x25_find_socket+0x23/0x140 net/x25/af_x25.c:341
CPU: 0 PID: 10492 Comm: syz-executor.2 Not tainted 5.0.0-rc7+ #88
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:__sanitizer_cov_trace_pc+0x4/0x50 kernel/kcov.c:97
Code: f4 ff ff ff e8 11 9f ea ff 48 c7 05 12 fb e5 08 00 00 00 00 e9 c8 e9 ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 55 48 89 e5 <48> 8b 75 08 65 48 8b 04 25 40 ee 01 00 65 8b 15 38 0c 92 7e 81 e2
RSP: 0018:ffff88806e94fc48 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff13
RAX: 1ffff1100d84dac5 RBX: 0000000000000001 RCX: ffffc90006197000
RDX: 0000000000040000 RSI: ffffffff86324bf3 RDI: ffff88806c26d628
RBP: ffff88806e94fc48 R08: ffff88806c1c6500 R09: fffffbfff1282561
R10: fffffbfff1282560 R11: ffffffff89412b03 R12: ffff88806c26d628
R13: ffff888090455200 R14: dffffc0000000000 R15: 0000000000000000
FS:  00007f3a107e4700(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f3a107e3db8 CR3: 00000000a5544000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 __x25_find_socket net/x25/af_x25.c:327 [inline]
 x25_find_socket+0x7d/0x140 net/x25/af_x25.c:342
 x25_new_lci net/x25/af_x25.c:355 [inline]
 x25_connect+0x380/0xde0 net/x25/af_x25.c:784
 __sys_connect+0x266/0x330 net/socket.c:1662
 __do_sys_connect net/socket.c:1673 [inline]
 __se_sys_connect net/socket.c:1670 [inline]
 __x64_sys_connect+0x73/0xb0 net/socket.c:1670
 do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457e29
Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f3a107e3c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457e29
RDX: 0000000000000012 RSI: 0000000020000200 RDI: 0000000000000005
RBP: 000000000073c040 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f3a107e46d4
R13: 00000000004be362 R14: 00000000004ceb98 R15: 00000000ffffffff
Sending NMI from CPU 0 to CPUs 1:
NMI backtrace for cpu 1
CPU: 1 PID: 10493 Comm: syz-executor.3 Not tainted 5.0.0-rc7+ #88
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:__read_once_size include/linux/compiler.h:193 [inline]
RIP: 0010:queued_write_lock_slowpath+0x143/0x290 kernel/locking/qrwlock.c:86
Code: 4c 8d 2c 01 41 83 c7 03 41 0f b6 45 00 41 38 c7 7c 08 84 c0 0f 85 0c 01 00 00 8b 03 3d 00 01 00 00 74 1a f3 90 41 0f b6 55 00 <41> 38 d7 7c eb 84 d2 74 e7 48 89 df e8 cc aa 4e 00 eb dd be 04 00
RSP: 0018:ffff888085c47bd8 EFLAGS: 00000206
RAX: 0000000000000300 RBX: ffffffff89412b00 RCX: 1ffffffff1282560
RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff89412b00
RBP: ffff888085c47c70 R08: 1ffffffff1282560 R09: fffffbfff1282561
R10: fffffbfff1282560 R11: ffffffff89412b03 R12: 00000000000000ff
R13: fffffbfff1282560 R14: 1ffff11010b88f7d R15: 0000000000000003
FS:  00007fdd04086700(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fdd04064db8 CR3: 0000000090be0000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 queued_write_lock include/asm-generic/qrwlock.h:104 [inline]
 do_raw_write_lock+0x1d6/0x290 kernel/locking/spinlock_debug.c:203
 __raw_write_lock_bh include/linux/rwlock_api_smp.h:204 [inline]
 _raw_write_lock_bh+0x3b/0x50 kernel/locking/spinlock.c:312
 x25_insert_socket+0x21/0xe0 net/x25/af_x25.c:267
 x25_bind+0x273/0x340 net/x25/af_x25.c:703
 __sys_bind+0x23f/0x290 net/socket.c:1481
 __do_sys_bind net/socket.c:1492 [inline]
 __se_sys_bind net/socket.c:1490 [inline]
 __x64_sys_bind+0x73/0xb0 net/socket.c:1490
 do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457e29

Fixes: 90c27297a9 ("X.25 remove bkl in bind")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: andrew hendry <andrew.hendry@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-23 18:41:06 -08:00
Hauke Mehrtens 99407d8fa3 net: dsa: Remove documentation for port_fdb_prepare
This callback was removed some time ago, also remove the documentation.

Fixes: 1b6dd556c3 ("net: dsa: Remove prepare phase for FDB")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-23 18:38:00 -08:00
Hangbin Liu 278e2148c0 Revert "bridge: do not add port to router list when receives query with source 0.0.0.0"
This reverts commit 5a2de63fd1 ("bridge: do not add port to router list
when receives query with source 0.0.0.0") and commit 0fe5119e26 ("net:
bridge: remove ipv6 zero address check in mcast queries")

The reason is RFC 4541 is not a standard but suggestive. Currently we
will elect 0.0.0.0 as Querier if there is no ip address configured on
bridge. If we do not add the port which recives query with source
0.0.0.0 to router list, the IGMP reports will not be about to forward
to Querier, IGMP data will also not be able to forward to dest.

As Nikolay suggested, revert this change first and add a boolopt api
to disable none-zero election in future if needed.

Reported-by: Linus Lüssing <linus.luessing@c0d3.blue>
Reported-by: Sebastian Gottschall <s.gottschall@newmedia-net.de>
Fixes: 5a2de63fd1 ("bridge: do not add port to router list when receives query with source 0.0.0.0")
Fixes: 0fe5119e26 ("net: bridge: remove ipv6 zero address check in mcast queries")
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Acked-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-23 18:36:06 -08:00
Thadeu Lima de Souza Cascardo af548a27b1 selftests: fib_tests: sleep after changing carrier. again.
Just like commit e2ba732a16 ("selftests: fib_tests: sleep after
changing carrier"), wait one second to allow linkwatch to propagate the
carrier change to the stack.

There are two sets of carrier tests. The first slept after the carrier
was set to off, and when the second set ran, it was likely that the
linkwatch would be able to run again without much delay, reducing the
likelihood of a race. However, if you run 'fib_tests.sh -t carrier' on a
loop, you will quickly notice the failures.

Sleeping on the second set of tests make the failures go away.

Cc: David Ahern <dsahern@gmail.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Reviewed-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-23 18:34:20 -08:00
Mao Wenan 4593403fa5 net: set static variable an initial value in atl2_probe()
cards_found is a static variable, but when it enters atl2_probe(),
cards_found is set to zero, the value is not consistent with last probe,
so next behavior is not our expect.

Signed-off-by: Mao Wenan <maowenan@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-23 13:47:13 -08:00
Maxime Chevallier 61a65d32fe net: phy: marvell10g: Fix Multi-G advertisement to only advertise 10G
Some Marvell Alaska PHYs support 2.5G, 5G and 10G BaseT links. Their
default behaviour is to advertise all of these modes, but at the moment,
only 10GBaseT is supported. To prevent link partners from establishing
link at that speed, clear these modes upon configuring aneg parameters.

Fixes: 20b2af32ff ("net: phy: add Marvell Alaska X 88X3310 10Gigabit PHY support")
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reported-by: Russell King <linux@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-23 13:27:51 -08:00
Linus Torvalds e60b5f79bd powerpc fixes for 5.0 #6
One fix for an oops when using SRIOV, introduced by the recent changes to
 support compound IOMMU groups.
 
 Thanks to:
   Alexey Kardashevskiy.
 -----BEGIN PGP SIGNATURE-----
 
 iQIcBAABAgAGBQJccT61AAoJEFHr6jzI4aWAAOkQAIVB3i5EDXhiIVUam/YsqlUk
 glEh6a3zmgt8p+zBXlpGW5UULuHC0sx7T1LDGMye+AZ9sXpkK2DzwkwJdNjBMQ8v
 xhH4e4znAhncgRZO92JkrG9Ag4VQuQVLMelhuUcLxF5ybH1+C3ZxSHrMPI7kdiG4
 8un4Og26ixDPcgylLg6tbCeeCr/IjoqZBhyKvwEUjQIY2jM/J/E7zzBEfSRtPlGW
 5jLgfJykEDp9Ta+E4+6+/UtuvbKUOX+xG3j7v7/RBMP0hu7L/naYT3nhoy25Hili
 BXfsNJrLTiQXOCfJZExvqq494Vb4dMwlF4J+45gsBBFUplmZ70g9kSmUKhLtKAtr
 /bfXRKYK9rRigyLHgTRmTbvbX4CkY6C6IgKJem68tWop6QRMazbc8Ea25eqjMESc
 neP7kpZABXJzwLDxP9TS2LjXEcVneR7eIhj7WDY3rrDL/+6YGhVfFKAE+P/Z0THO
 ahPO+EAKQirX127TJZXiL8nkJkU+R4/oKjkF6AsLi2xsLb83cEodABLUpH2xqJCn
 f8JA2gsIjZq3FE+foNpH4i+HVwV3PFFDhNBauZFXtj9hVHt4cuTk1SaIvQohfDCj
 RChHh90MT+u+q1cffeLX/WbjjuJbcxHqF1K1O4SZNN8IfIBVaAXXerbba1KOoIWB
 CG6BfAYQiJ6CBu8QhKYo
 =NBtz
 -----END PGP SIGNATURE-----

Merge tag 'powerpc-5.0-6' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux

Pull powerpc fix from Michael Ellerman:
 "One fix for an oops when using SRIOV, introduced by the recent changes
  to support compound IOMMU groups.

  Thanks to Alexey Kardashevskiy"

* tag 'powerpc-5.0-6' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
  powerpc/powernv/sriov: Register IOMMU groups for VFs
2019-02-23 11:13:50 -08:00
Linus Torvalds 6089a91fc0 SCSI fixes on 20190222
Four small fixes: three in drivers and one in the core.  The core fix
 is also minor in scope since the bug it fixes is only known to affect
 systems using SCSI reservations.  Of the driver bugs, the libsas one
 is the most major because it can lead to multiple disks on the same
 expander not being exposed.
 
 Signed-off-by: James E.J. Bottomley <jejb@linux.ibm.com>
 -----BEGIN PGP SIGNATURE-----
 
 iJwEABMIAEQWIQTnYEDbdso9F2cI+arnQslM7pishQUCXHC4uSYcamFtZXMuYm90
 dG9tbGV5QGhhbnNlbnBhcnRuZXJzaGlwLmNvbQAKCRDnQslM7pishfYwAP9zX676
 svxUeEQLLyMLXmGyDZ5um8ne8VDAzXDIrkS06gEAhKju7hb7jYvt0pf3jj+utS+v
 KXtT8CpMuj+cffeVXng=
 =OkZL
 -----END PGP SIGNATURE-----

Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi

Pull SCSI fixes from James Bottomley:
 "Four small fixes: three in drivers and one in the core.

  The core fix is also minor in scope since the bug it fixes is only
  known to affect systems using SCSI reservations. Of the driver bugs,
  the libsas one is the most major because it can lead to multiple disks
  on the same expander not being exposed"

* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
  scsi: core: reset host byte in DID_NEXUS_FAILURE case
  scsi: libsas: Fix rphy phy_identifier for PHYs with end devices attached
  scsi: sd_zbc: Fix sd_zbc_report_zones() buffer allocation
  scsi: libiscsi: Fix race between iscsi_xmit_task and iscsi_complete_task
2019-02-23 09:48:01 -08:00
David S. Miller ea34a00364 Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf
Daniel Borkmann says:

====================
pull-request: bpf 2019-02-23

The following pull-request contains BPF updates for your *net* tree.

The main changes are:

1) Fix a bug in BPF's LPM deletion logic to match correct prefix
   length, from Alban.

2) Fix AF_XDP teardown by not destroying umem prematurely as it
   is still needed till all outstanding skbs are freed, from Björn.

3) Fix unkillable BPF_PROG_TEST_RUN under preempt kernel by checking
   signal_pending() outside need_resched() condition which is never
   triggered there, from Stanislav.

4) Fix two nfp JIT bugs, one in code emission for K-based xor, and
   another one to explicitly clear upper bits in alu32, from Jiong.

5) Add bpf list address to maintainers file, from Daniel.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-22 20:45:38 -08:00
Linus Torvalds cb268d8069 Merge branch 'fixes-v5.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security
Pull keys fixes from James Morris:
 "Two fixes from Eric Biggers"

* 'fixes-v5.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security:
  KEYS: always initialize keyring_index_key::desc_len
  KEYS: user: Align the payload buffer
2019-02-22 17:48:50 -08:00
Linus Torvalds ef4edb3ed8 Power management fixes for final 5.0
- Use hrtimer_try_to_cancel() instead of hrtimer_cancel() in the
    PM-runtime framework to avoid a possible timer-related deadlock
    introduced recently (Vincent Guittot).
 
  - Reorder the scmi-cpufreq driver code to avoid accessing memory
    that has just been freed (Yangtao Li).
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2
 
 iQIcBAABCAAGBQJcb8D1AAoJEILEb/54YlRxeUsP/2MefwrqcqSGpsbmH2V3vBBa
 RP6La5u8+ZYJiCSi0uvwgWy6UXuvRMIE9W6nl2+b4V+AQZcvo5KYvbRFbE12U2JI
 maYEBrgqNFjxECfSmkizAKg33kEaKLxTiK6lQ973kHnkMQ/HyZfdHuNuzkIOViRv
 hc8ceJi90ojlrTGpwFeV/Kl3L9LvFjkN1GdNTM4GEdJNAkcKz0VFYDhwThcHVY2A
 KyWxBoHUre+ORnv8Z+MFtV3CXrZQZFFNvl1X2CcHksgZDXiEaWolQ/u/kEnb17Xb
 a9wzdo+vDtwCRx7MHK3cneukAmcRlareQFgr+FFA+eo3kTfJteV+iFnYNxnO2pg6
 CtJ33xlaaEfNbuMZuSL4H9cJmmyF5NNoOLtvocWHGZSu6fKTUTalTxuXffZSUacE
 alYlveyxK7s9o+7WcfW2VyGLsYg60pWe2Suws0vKZhmbZNl/KCRgVHTGbZ9PiHK3
 bgvlTA0vzvdNjs7BebedpyRhu69nuhZ7TSLGWW0Q2vOTeMVtabx5mRGgZMq/MA7U
 qIte4pi/LyC6UOxPG9Y8IFgZfhbQ0qmCs0TvMCxeZxqnR4bFYCILl2GUCKXS+csy
 4GmRMV+Bi+4fmdJFUCCnfhAUAKGs535m9sA8pKHy3L+8XC2JiaOunrfHXc693P3B
 7naqbmFx4Ezl+Dxs6yGd
 =7rW+
 -----END PGP SIGNATURE-----

Merge tag 'pm-5.0' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

Pull power management fixes from Rafael Wysocki:
 "These fix a regression in the PM-runtime framework introduced by the
  recent switch-over of it to using hrtimers and a use-after-free
  introduced by one of the recent changes in the scmi-cpufreq driver.

  Specifics:

   - Use hrtimer_try_to_cancel() instead of hrtimer_cancel() in the
     PM-runtime framework to avoid a possible timer-related deadlock
     introduced recently (Vincent Guittot).

   - Reorder the scmi-cpufreq driver code to avoid accessing memory that
     has just been freed (Yangtao Li)"

* tag 'pm-5.0' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  PM-runtime: Fix deadlock when canceling hrtimer
  cpufreq: scmi: Fix use-after-free in scmi_cpufreq_exit()
2019-02-22 17:46:30 -08:00
Linus Torvalds 9053d2db8b ARM: SoC fixes for 5.0
Only a handful of device tree fixes, all simple enough:
 
 NVIDIA Tegra:
  - Fix a regression for booting on chromebooks
 
 TI OMAP:
  - Two fixes PHY mode on am335x reference boards
 
 Marvell mvebu:
  - A regression fix for Armada XP NAND flash controllers
  - An incorrect reset signal on the clearfog board
 
 Signed-off-by: Arnd Bergmann <arnd@arndb.de>
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2
 
 iQIcBAABCAAGBQJccHWeAAoJEGCrR//JCVInLQAQAIKQEEQXxPn1fnXH5oH7n/Yn
 aALv0zoRKx5ybgQvp15hkdD/H7AUt01ADopCvgOxh0EkheIOEZdtb/FCaRPzaYhC
 TrrZhqI6+w0rcMwUzpaDU+90/rxkh6oeIs95lfTkHaZV0ZdbWqwwvX/JuQcPJOh2
 tQXwfNMv4WZetvAFrJHr9L+7/CebgQaOe/Me78wq/bjKEROShaF6j6lQMTeZwX6C
 Jp75cI5gCktqg4ZDQ2NEE8O9Tng4uzIpoVlCptFc38XGKnRZMexZZlZWpMwTeQg1
 QmNmyTal6gbY5tDs3AGg3diSPFQ1nwUiMk2pWvGkkRo5hkNP80lNCouu8F99r/Ub
 QoPRcKzGyBwLj0MwpHBoO5gI1X4mgfZDpL71SdS81p8q3rpnt/W2HU+CTAgnEpAi
 aILCMmRzes3jpNHREUQc5X3dTwfHW8MBW/Bia6XnidqmUw5GoRq+98rCOKFpg2HQ
 m68yDZlOq2odATmaa4xASVfTwccm8jIyQwZVWFPLyekZ9kzMcdYmAI7lGGofJAbg
 SkRXDHsAQ21pDoUZY3C0lE49kPKoTNrt4bsihG0I3hM09moF6ryqmymgAy82mzsD
 e/ZVG2w1E0CS4vKjKq7BEof3PZ6wSdfaYOFzS7v9bXAeBSdRVE/qjzi/aBgAKD8J
 KpDRnh2huOMvPTO5bDKC
 =nXrB
 -----END PGP SIGNATURE-----

Merge tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc

Pull ARM SoC fixes from Arnd Bergmann:
 "Only a handful of device tree fixes, all simple enough:

  NVIDIA Tegra:
   - Fix a regression for booting on chromebooks

  TI OMAP:
   - Two fixes PHY mode on am335x reference boards

  Marvell mvebu:
   - A regression fix for Armada XP NAND flash controllers
   - An incorrect reset signal on the clearfog board"

* tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc:
  ARM: tegra: Restore DT ABI on Tegra124 Chromebooks
  ARM: dts: am335x-evm: Fix PHY mode for ethernet
  ARM: dts: am335x-evmsk: Fix PHY mode for ethernet
  arm64: dts: clearfog-gt-8k: fix SGMII PHY reset signal
  ARM: dts: armada-xp: fix Armada XP boards NAND description
2019-02-22 16:48:37 -08:00
Linus Torvalds 2cc63b3900 ARC fixes for 5.0 final
- Fix memcpy to prevent prefetchw beyond end of buffer [Eugeniy]
 
  - Enable unaligned access early to prevent exceptions given newer gcc
    code gen [Eugeniy]
 
  - Tighten up uboot arg checking to prevent false negatives and also
    allow both jtag and bootloading to coexist w/o config option as
    needed by kernelCi folks [Eugeniy]
 
  - Set slab alignment to 8 for ARC to avoid the atomic64_t unalign [Alexey]
 
  - Disable regfile auto save on interrupts on HSDK platform due to a
    silicon issue  [Vineet]
 
  - Avoid HS38x boot printing crash by not reading HS48x only reg [Vineet]
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABAgAGBQJccDKEAAoJEGnX8d3iisJeqAoQAIM753GmJMXJeeaDm8wxUkvF
 1NThcBekh2IrEEesCD8HBaCuegTXGJ8eNCkGBtgxUBisQvixRDCge1r18SXdVWRR
 lz3+VoRbiqe4vNZfXJJZQj09/gOIjL7sZQX7NIAk/YDJ4mdhID0yEULE0cKxPkp3
 w3AsCi6x7Umt9nbH06mPV8b71mT77MaNGpTYmx7cvc8FX/rXfh7C7QUgBDeU2201
 3F3tHiJqR+gBu/kwEVTOuG+wJ3sUy8Yi/Qungv6Lkk3rm4bcimBqB8MaJAqB8fPV
 H3rGTgz9eH6p7SERqdSPvO92x5vw/eh9reg0/K3gmHOI0i3gaiUNhxcZwhu2rqZC
 45JkfrRPbLj11uaUTB07BqYck/5SaHugyu6tCtA+khkCigND8RWwJRBAc25VCsJ1
 9ywIc/6eGbfSyOT1Elit6tf1/SpKap63VoXtNmfdEWvCoW4tAVvR6uhi8DcnSlJJ
 5vqYRZUom5IQ7YrAaXQ7VqAq61H7ZA6XSklQs+0w2pqL0YND9W1ryETIw3lraOCh
 3O2V7nETXjTvnEkxovbQ5C2GwIvURN4RtckdgiXCS3MG3OsGMEWDZFdr0kGffZAO
 SAXn8poO522cglIR8o4GwyE1EATQbQ3zuavDq5zuB//VNHdcgODN18zkqel2A5Wr
 AY85YAxbPx05PMRnAwRx
 =cNCN
 -----END PGP SIGNATURE-----

Merge tag 'arc-5.0-final' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc

Pull ARC fixes from Vineet Gupta:
 "Fixes for ARC for 5.0, bunch of those are stable fodder anyways so
  sooner the better.

   - Fix memcpy to prevent prefetchw beyond end of buffer [Eugeniy]

   - Enable unaligned access early to prevent exceptions given newer gcc
     code gen [Eugeniy]

   - Tighten up uboot arg checking to prevent false negatives and also
     allow both jtag and bootloading to coexist w/o config option as
     needed by kernelCi folks [Eugeniy]

   - Set slab alignment to 8 for ARC to avoid the atomic64_t unalign
     [Alexey]

   - Disable regfile auto save on interrupts on HSDK platform due to a
     silicon issue [Vineet]

   - Avoid HS38x boot printing crash by not reading HS48x only reg
     [Vineet]"

* tag 'arc-5.0-final' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc:
  ARCv2: don't assume core 0x54 has dual issue
  ARC: define ARCH_SLAB_MINALIGN = 8
  ARC: enable uboot support unconditionally
  ARC: U-boot: check arguments paranoidly
  ARCv2: support manual regfile save on interrupts
  ARC: uacces: remove lp_start, lp_end from clobber list
  ARC: fix actionpoints configuration detection
  ARCv2: lib: memcpy: fix doing prefetchw outside of buffer
  ARCv2: Enable unaligned access in early ASM code
2019-02-22 16:31:26 -08:00
Daniel Borkmann b4b8bb69c1 bpf, doc: add bpf list as secondary entry to maintainers file
We recently created a bpf@vger.kernel.org list (https://lore.kernel.org/bpf/)
for BPF related discussions, originally in context of BPF track at LSF/MM
for topic discussions. It's *optional* but *desirable* to keep it in Cc for
BPF related kernel/loader/llvm/tooling threads, meaning also infrastructure
like llvm that sits on top of kernel but is crucial to BPF. In any case,
netdev with it's bpf delegate is *as-is* today primary list for patches, so
nothing changes in the workflow. Main purpose is to have some more awareness
for the bpf@vger.kernel.org list that folks can Cc for BPF specific topics.

Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-02-23 01:22:32 +01:00
Linus Torvalds 8456e98e18 Merge branch 'parisc-5.0-1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux
Pull parisc fixes from Helge Deller:
 "Fix ptrace syscall number modification which has been broken since
  kernel v4.5 and provide alternative email addresses for the remaining
  users of the retired parisc-linux.org email domain"

* 'parisc-5.0-1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
  CREDITS/MAINTAINERS: Retire parisc-linux.org email domain
  parisc: Fix ptrace syscall number modification
2019-02-22 16:12:01 -08:00
Linus Torvalds 77dc1181d8 Kbuild fixes for v5.0 (2nd)
- fix scripts/kallsyms.c to correctly check too long symbol names
 
  - fix sh build error for the combination of CONFIG_OF_EARLY_FLATTREE=y
    and CONFIG_USE_BUILTIN_DTB=n
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABAgAGBQJcb0FKAAoJED2LAQed4NsGuwcP/2GhoN/whRUpC2LkrsAbkPuy
 Ad/ySgwRROUHeLuSQqxFqOIvnkWYwsCRrA/jNzXalapB66iYVAKWupVniuFkv8Lj
 TIqXOu3qJfpg63l77GgO87L/ZVxiyWxEH3XEvxFlARQCZEk9nwiTkXD8bVt37xwP
 P46RVUQyvS8diUKjS6EO3I74cmBXDDigSzzzJTL6F8GgaGEv8mSMv6pU86CxLSpx
 +X8U/1HR3hHsxOH5oYlFY6RVv/f071YtOVdqgTU5OMWQ7R8iaGOy0eJBaDsl4HGx
 oNYQhvLs7TN4BT6ubVcNliSqp0SwccSGA0nQkSVS78YvYVF9mIDsmH673kfN5pFT
 TYR+LSW8AnWvpQJ7PyJtyKSCD9MEMsi4viAnW/2f1VxCGRV84+A3DotIKekJLa1A
 8uuYbOBqKi5LCBY1Vo8LOlG+epw21AsCqHrot73J4u8nkiK3YZdq4zkV4pnb1B49
 NLXs1pJIG4Tzu06EOK1iOO5Y76fSCV6/5FfqFwP87hyfTtQU1FG1bsivuXccu/hV
 yrUaHdpDRltechPLhN4js8I5zhZTZVZsthn6lITBPcEOmeCbNgIShIdjFIgnqyTr
 OQNznQPNt8iOzsC1aaZ0hOpCcE8Hk1RmObEF+xA5i8k5oinAxPX6loTeW7sIY5OP
 0Pt9FJQ87Q62+jpX0/jp
 =m7U7
 -----END PGP SIGNATURE-----

Merge tag 'kbuild-fixes-v5.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild

Pull more Kbuild fixes from Masahiro Yamada:

 - fix scripts/kallsyms.c to correctly check too long symbol names

 - fix sh build error for the combination of CONFIG_OF_EARLY_FLATTREE=y
   and CONFIG_USE_BUILTIN_DTB=n

* tag 'kbuild-fixes-v5.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
  sh: fix build error for invisible CONFIG_BUILTIN_DTB_SOURCE
  kallsyms: Handle too long symbols in kallsyms.c
2019-02-22 16:09:55 -08:00
David S. Miller 40e8f0b42f Merge branch 'udp-a-few-fixes'
Paolo Abeni says:

====================
udp: a few fixes

This series includes some UDP-related fixlet. All this stuff has been
pointed out by the sparse tool. The first two patches are just annotation
related, while the last 2 cover some very unlikely races.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-22 16:05:12 -08:00
Paolo Abeni 92b9536423 udp: fix possible user after free in error handler
Similar to the previous commit, this addresses the same issue for
ipv4: use a single fetch operation and use the correct rcu
annotation.

Fixes: e7cc082455 ("udp: Support for error handlers of tunnels with arbitrary destination port")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Acked-by: Stefano Brivio <sbrivio@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-22 16:05:11 -08:00