aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2018-11-09usb: typec: ucsi: add support for Cypress CCGxAjay Gupta3-0/+319
Latest NVIDIA GPU cards have a Cypress CCGx Type-C controller over I2C interface. This UCSI I2C driver uses I2C bus driver interface for communicating with Type-C controller. Signed-off-by: Ajay Gupta <[email protected]> Acked-by: Heikki Krogerus <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-11-09serial: sh-sci: Fix could not remove dev_attr_rx_fifo_timeoutYoshihiro Shimoda1-2/+2
This patch fixes an issue that the sci_remove() could not remove dev_attr_rx_fifo_timeout because uart_remove_one_port() set the port->port.type to PORT_UNKNOWN. Reported-by: Hiromitsu Yamasaki <[email protected]> Fixes: 5d23188a473d ("serial: sh-sci: make RX FIFO parameters tunable via sysfs") Cc: <[email protected]> # v4.11+ Signed-off-by: Yoshihiro Shimoda <[email protected]> Reviewed-by: Ulrich Hecht <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-11-09drm/dp_mst: Check if primary mstb is nullStanislav Lisovskiy1-0/+3
Unfortunately drm_dp_get_mst_branch_device which is called from both drm_dp_mst_handle_down_rep and drm_dp_mst_handle_up_rep seem to rely on that mgr->mst_primary is not NULL, which seem to be wrong as it can be cleared with simultaneous mode set, if probing fails or in other case. mgr->lock mutex doesn't protect against that as it might just get assigned to NULL right before, not simultaneously. There are currently bugs 107738, 108616 bugs which crash in drm_dp_get_mst_branch_device, caused by this issue. v2: Refactored the code, as it was nicely noticed. Fixed Bugzilla bug numbers(second was 108616, but not 108816) and added links. [changed title and added stable cc] Signed-off-by: Lyude Paul <[email protected]> Signed-off-by: Stanislav Lisovskiy <[email protected]> Cc: [email protected] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108616 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107738 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-11-09i2c: nvidia-gpu: make pm_ops staticWolfram Sang1-1/+1
sparse rightfully says: warning: symbol 'gpu_i2c_driver_pm' was not declared. Should it be static? Signed-off-by: Wolfram Sang <[email protected]>
2018-11-09i2c: add i2c bus driver for NVIDIA GPUAjay Gupta5-0/+403
Latest NVIDIA GPU card has USB Type-C interface. There is a Type-C controller which can be accessed over I2C. This driver adds I2C bus driver to communicate with Type-C controller. I2C client driver will be part of USB Type-C UCSI driver. Signed-off-by: Ajay Gupta <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> [wsa: kept Makefile sorting] Signed-off-by: Wolfram Sang <[email protected]>
2018-11-09ext4: missing !bh check in ext4_xattr_inode_write()Vasily Averin1-0/+6
According to Ted Ts'o ext4_getblk() called in ext4_xattr_inode_write() should not return bh = NULL The only time that bh could be NULL, then, would be in the case of something really going wrong; a programming error elsewhere (perhaps a wild pointer dereference) or I/O error causing on-disk file system corruption (although that would be highly unlikely given that we had *just* allocated the blocks and so the metadata blocks in question probably would still be in the cache). Fixes: e50e5129f384 ("ext4: xattr-in-inode support") Signed-off-by: Vasily Averin <[email protected]> Signed-off-by: Theodore Ts'o <[email protected]> Cc: [email protected] # 4.13
2018-11-09i2c: qcom-geni: Fix runtime PM mismatch with child devicesStephen Boyd1-7/+8
We need to enable runtime PM on this i2c controller before populating child devices with i2c_add_adapter(). Otherwise, if a child device uses runtime PM and stays runtime PM enabled we'll get the following warning at boot. Enabling runtime PM for inactive device (a98000.i2c) with active children [...] Call trace: pm_runtime_enable+0xd8/0xf8 geni_i2c_probe+0x440/0x460 platform_drv_probe+0x74/0xc8 [...] Let's move the runtime PM enabling and setup to before we add the adapter, so that this device can respond to runtime PM requests from children. Fixes: 37692de5d523 ("i2c: i2c-qcom-geni: Add bus driver for the Qualcomm GENI I2C controller") Signed-off-by: Stephen Boyd <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-11-09MAINTAINERS: Add entry for i2c-omap driverVignesh R1-0/+8
Add separate entry for i2c-omap and add my name as maintainer for this driver. Signed-off-by: Vignesh R <[email protected]> Acked-by: Tony Lindgren <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-11-09i2c: omap: Enable for ARCH_K3Vignesh R1-1/+1
Allow I2C_OMAP to be built for K3 platforms. Signed-off-by: Vignesh R <[email protected]> Reviewed-by: Grygorii Strashko <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-11-09dt-bindings: i2c: omap: Add new compatible for AM654 SoCsVignesh R1-2/+6
AM654 SoCs have same I2C IP as OMAP SoCs. Add new compatible to handle AM654 SoCs. While at that reformat the existing compatible list for older SoCs to list one valid compatible per line. Signed-off-by: Vignesh R <[email protected]> Reviewed-by: Rob Herring <[email protected]> Reviewed-by: Grygorii Strashko <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-11-09xen: remove size limit of privcmd-buf mapping interfaceJuergen Gross1-18/+4
Currently the size of hypercall buffers allocated via /dev/xen/hypercall is limited to a default of 64 memory pages. For live migration of guests this might be too small as the page dirty bitmask needs to be sized according to the size of the guest. This means migrating a 8GB sized guest is already exhausting the default buffer size for the dirty bitmap. There is no sensible way to set a sane limit, so just remove it completely. The device node's usage is limited to root anyway, so there is no additional DOS scenario added by allowing unlimited buffers. While at it make the error path for the -ENOMEM case a little bit cleaner by setting n_pages to the number of successfully allocated pages instead of the target size. Fixes: c51b3c639e01f2 ("xen: add new hypercall buffer mapping device") Cc: <[email protected]> #4.18 Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2018-11-09xen: fix xen_qlock_wait()Juergen Gross1-6/+8
Commit a856531951dc80 ("xen: make xen_qlock_wait() nestable") introduced a regression for Xen guests running fully virtualized (HVM or PVH mode). The Xen hypervisor wouldn't return from the poll hypercall with interrupts disabled in case of an interrupt (for PV guests it does). So instead of disabling interrupts in xen_qlock_wait() use a nesting counter to avoid calling xen_clear_irq_pending() in case xen_qlock_wait() is nested. Fixes: a856531951dc80 ("xen: make xen_qlock_wait() nestable") Cc: [email protected] Reported-by: Sander Eikelenboom <[email protected]> Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Tested-by: Sander Eikelenboom <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2018-11-09fuse: fix use-after-free in fuse_direct_IO()Lukas Czerner1-1/+3
In async IO blocking case the additional reference to the io is taken for it to survive fuse_aio_complete(). In non blocking case this additional reference is not needed, however we still reference io to figure out whether to wait for completion or not. This is wrong and will lead to use-after-free. Fix it by storing blocking information in separate variable. This was spotted by KASAN when running generic/208 fstest. Signed-off-by: Lukas Czerner <[email protected]> Reported-by: Zorro Lang <[email protected]> Signed-off-by: Miklos Szeredi <[email protected]> Fixes: 744742d692e3 ("fuse: Add reference counting for fuse_io_priv") Cc: <[email protected]> # v4.6
2018-11-09fuse: fix possibly missed wake-up after abortMiklos Szeredi1-3/+9
In current fuse_drop_waiting() implementation it's possible that fuse_wait_aborted() will not be woken up in the unlikely case that fuse_abort_conn() + fuse_wait_aborted() runs in between checking fc->connected and calling atomic_dec(&fc->num_waiting). Do the atomic_dec_and_test() unconditionally, which also provides the necessary barrier against reordering with the fc->connected check. The explicit smp_mb() in fuse_wait_aborted() is not actually needed, since the spin_unlock() in fuse_abort_conn() provides the necessary RELEASE barrier after resetting fc->connected. However, this is not a performance sensitive path, and adding the explicit barrier makes it easier to document. Signed-off-by: Miklos Szeredi <[email protected]> Fixes: b8f95e5d13f5 ("fuse: umount should wait for all requests") Cc: <[email protected]> #v4.19
2018-11-09fuse: fix leaked notify replyMiklos Szeredi1-1/+3
fuse_request_send_notify_reply() may fail if the connection was reset for some reason (e.g. fs was unmounted). Don't leak request reference in this case. Besides leaking memory, this resulted in fc->num_waiting not being decremented and hence fuse_wait_aborted() left in a hanging and unkillable state. Fixes: 2d45ba381a74 ("fuse: add retrieve request") Fixes: b8f95e5d13f5 ("fuse: umount should wait for all requests") Reported-and-tested-by: [email protected] Signed-off-by: Miklos Szeredi <[email protected]> Cc: <[email protected]> #v2.6.36
2018-11-09block: make sure writesame bio is aligned with logical block sizeMing Lei1-1/+1
Obviously the created writesame bio has to be aligned with logical block size, and use bio_allowed_max_sectors() to retrieve this number. Cc: [email protected] Cc: Mike Snitzer <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Xiao Ni <[email protected]> Cc: Mariusz Dabrowski <[email protected]> Fixes: b49a0871be31a745b2ef ("block: remove split code in blkdev_issue_{discard,write_same}") Tested-by: Rui Salvaterra <[email protected]> Signed-off-by: Ming Lei <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2018-11-09block: cleanup __blkdev_issue_discard()Ming Lei1-17/+6
Cleanup __blkdev_issue_discard() a bit: - remove local variable of 'end_sect' - remove code block of 'fail' Cc: Mike Snitzer <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Xiao Ni <[email protected]> Cc: Mariusz Dabrowski <[email protected]> Tested-by: Rui Salvaterra <[email protected]> Signed-off-by: Ming Lei <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2018-11-09block: make sure discard bio is aligned with logical block sizeMing Lei3-3/+13
Obviously the created discard bio has to be aligned with logical block size. This patch introduces the helper of bio_allowed_max_sectors() for this purpose. Cc: [email protected] Cc: Mike Snitzer <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Xiao Ni <[email protected]> Cc: Mariusz Dabrowski <[email protected]> Fixes: 744889b7cbb56a6 ("block: don't deal with discard limit in blkdev_issue_discard()") Fixes: a22c4d7e34402cc ("block: re-add discard_granularity and alignment checks") Reported-by: Rui Salvaterra <[email protected]> Tested-by: Rui Salvaterra <[email protected]> Signed-off-by: Ming Lei <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2018-11-09Revert "nvmet-rdma: use a private workqueue for delete"Christoph Hellwig1-15/+4
This reverts commit 2acf70ade79d26b97611a8df52eb22aa33814cd4. The commit never really fixed the intended issue and caused all kinds of other issues, including a use before initialization. Suggested-by: Sagi Grimberg <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2018-11-09nvme: make sure ns head inherits underlying device limitsSagi Grimberg2-1/+4
Whenever we update ns_head info, we need to make sure it is still compatible with all underlying backing devices because although nvme multipath doesn't have any explicit use of these limits, other devices can still be stacked on top of it which may rely on the underlying limits. Start with unlimited stacking limits, and every info update iterate over siblings and adjust queue limits. Signed-off-by: Sagi Grimberg <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2018-11-09nvmet: don't try to add ns to p2p map unless it actually uses itSagi Grimberg1-1/+1
Even without CONFIG_P2PDMA this results in a error print: nvmet: no peer-to-peer memory is available that's supported by rxe0 and /dev/nullb0 Fixes: c6925093d0b2 ("nvmet: Optionally use PCI P2P memory") Signed-off-by: Sagi Grimberg <[email protected]> Reviewed-by: Logan Gunthorpe <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2018-11-09Merge tag 's390-4.20-2' of ↵Linus Torvalds31-93/+175
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Martin Schwidefsky: - A fix for the pgtable_bytes misaccounting on s390. The patch changes common code part in regard to page table folding and adds extra checks to mm_[inc|dec]_nr_[pmds|puds]. - Add FORCE for all build targets using if_changed - Use non-loadable phdr for the .vmlinux.info section to avoid a segment overlap that confuses kexec - Cleanup the attribute definition for the diagnostic sampling - Increase stack size for CONFIG_KASAN=y builds - Export __node_distance to fix a build error - Correct return code of a PMU event init function - An update for the default configs * tag 's390-4.20-2' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/perf: Change CPUM_CF return code in event init function s390: update defconfigs s390/mm: Fix ERROR: "__node_distance" undefined! s390/kasan: increase instrumented stack size to 64k s390/cpum_sf: Rework attribute definition for diagnostic sampling s390/mm: fix mis-accounting of pgtable_bytes mm: add mm_pxd_folded checks to pgtable_bytes accounting functions mm: introduce mm_[p4d|pud|pmd]_folded mm: make the __PAGETABLE_PxD_FOLDED defines non-empty s390: avoid vmlinux segments overlap s390/vdso: add missing FORCE to build targets s390/decompressor: add missing FORCE to build targets
2018-11-09gfs2: Fix metadata read-ahead during truncate (2)Andreas Gruenbacher1-4/+10
The previous attempt to fix for metadata read-ahead during truncate was incorrect: for files with a height > 2 (1006989312 bytes with a block size of 4096 bytes), read-ahead requests were not being issued for some of the indirect blocks discovered while walking the metadata tree, leading to significant slow-downs when deleting large files. Fix that. In addition, only issue read-ahead requests in the first pass through the meta-data tree, while deallocating data blocks. Fixes: c3ce5aa9b0 ("gfs2: Fix metadata read-ahead during truncate") Cc: [email protected] # v4.16+ Signed-off-by: Andreas Gruenbacher <[email protected]>
2018-11-09gfs2: Put bitmap buffers in put_superAndreas Gruenbacher1-1/+2
gfs2_put_super calls gfs2_clear_rgrpd to destroy the gfs2_rgrpd objects attached to the resource group glocks. That function should release the buffers attached to the gfs2_bitmap objects (bi_bh), but the call to gfs2_rgrp_brelse for doing that is missing. When gfs2_releasepage later runs across these buffers which are still referenced, it refuses to free them. This causes the pages the buffers are attached to to remain referenced as well. With enough mount/unmount cycles, the system will eventually run out of memory. Fix this by adding the missing call to gfs2_rgrp_brelse in gfs2_clear_rgrpd. (Also fix a gfs2_rgrp_relse -> gfs2_rgrp_brelse typo in a comment.) Fixes: 39b0f1e92908 ("GFS2: Don't brelse rgrp buffer_heads every allocation") Cc: [email protected] # v4.2+ Signed-off-by: Andreas Gruenbacher <[email protected]>
2018-11-09MAINTAINERS: Add tree link for Intel pin control driverAndy Shevchenko1-0/+1
Intel pin control driver gets its own tree. Update MAINTAINERS accordingly. Signed-off-by: Andy Shevchenko <[email protected]> Acked-by: Mika Westerberg <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2018-11-09crypto: user - Zeroize whole structure given to user spaceCorentin Labbe1-0/+21
For preventing uninitialized data to be given to user-space (and so leak potential useful data), the crypto_stat structure must be correctly initialized. Reported-by: Dan Carpenter <[email protected]> Fixes: cac5818c25d0 ("crypto: user - Implement a generic crypto statistics") Signed-off-by: Corentin Labbe <[email protected]> [EB: also fix it in crypto_reportstat_one()] [EB: use sizeof(var) rather than sizeof(type)] Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2018-11-09crypto: user - fix leaking uninitialized memory to userspaceEric Biggers1-9/+9
All bytes of the NETLINK_CRYPTO report structures must be initialized, since they are copied to userspace. The change from strncpy() to strlcpy() broke this. As a minimal fix, change it back. Fixes: 4473710df1f8 ("crypto: user - Prepare for CRYPTO_MAX_ALG_NAME expansion") Cc: <[email protected]> # v4.12+ Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2018-11-09crypto: simd - correctly take reqsize of wrapped skcipher into accountArd Biesheuvel1-2/+3
The simd wrapper's skcipher request context structure consists of a single subrequest whose size is taken from the subordinate skcipher. However, in simd_skcipher_init(), the reqsize that is retrieved is not from the subordinate skcipher but from the cryptd request structure, whose size is completely unrelated to the actual wrapped skcipher. Reported-by: Qian Cai <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Tested-by: Qian Cai <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2018-11-09crypto: hisilicon - Fix reference after free of memories on error pathJohn Garry1-10/+11
coccicheck currently warns of the following issues in the driver: drivers/crypto/hisilicon/sec/sec_algs.c:864:51-66: ERROR: reference preceded by free on line 812 drivers/crypto/hisilicon/sec/sec_algs.c:864:40-49: ERROR: reference preceded by free on line 813 drivers/crypto/hisilicon/sec/sec_algs.c:861:8-24: ERROR: reference preceded by free on line 814 drivers/crypto/hisilicon/sec/sec_algs.c:860:41-51: ERROR: reference preceded by free on line 815 drivers/crypto/hisilicon/sec/sec_algs.c:867:7-18: ERROR: reference preceded by free on line 816 It would appear than on certain error paths that we may attempt reference- after-free some memories. This patch fixes those issues. The solution doesn't look perfect, but having same memories free'd possibly from separate functions makes it tricky. Fixes: 915e4e8413da ("crypto: hisilicon - SEC security accelerator driver") Reviewed-by: Jonathan Cameron <[email protected]> Cc: <[email protected]> Signed-off-by: John Garry <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2018-11-09crypto: hisilicon - Fix NULL dereference for same dst and srcJohn Garry1-4/+6
When the source and destination addresses for the cipher are the same, we will get a NULL dereference from accessing the split destination scatterlist memories, as shown: [ 56.565719] tcrypt: [ 56.565719] testing speed of async ecb(aes) (hisi_sec_aes_ecb) encryption [ 56.574683] tcrypt: test 0 (128 bit key, 16 byte blocks): [ 56.587585] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 56.596361] Mem abort info: [ 56.599151] ESR = 0x96000006 [ 56.602196] Exception class = DABT (current EL), IL = 32 bits [ 56.608105] SET = 0, FnV = 0 [ 56.611149] EA = 0, S1PTW = 0 [ 56.614280] Data abort info: [ 56.617151] ISV = 0, ISS = 0x00000006 [ 56.620976] CM = 0, WnR = 0 [ 56.623930] user pgtable: 4k pages, 48-bit VAs, pgdp = (____ptrval____) [ 56.630533] [0000000000000000] pgd=0000041fc7e4d003, pud=0000041fcd9bf003, pmd=0000000000000000 [ 56.639224] Internal error: Oops: 96000006 [#1] PREEMPT SMP [ 56.644782] Modules linked in: tcrypt(+) [ 56.648695] CPU: 21 PID: 2326 Comm: insmod Tainted: G W 4.19.0-rc6-00001-g3fabfb8-dirty #716 [ 56.658420] Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon D05 IT17 Nemo 2.0 RC0 10/05/2018 [ 56.667537] pstate: 20000005 (nzCv daif -PAN -UAO) [ 56.672322] pc : sec_alg_skcipher_crypto+0x318/0x748 [ 56.677274] lr : sec_alg_skcipher_crypto+0x178/0x748 [ 56.682224] sp : ffff0000118e3840 [ 56.685525] x29: ffff0000118e3840 x28: ffff841fbb3f8118 [ 56.690825] x27: 0000000000000000 x26: 0000000000000000 [ 56.696125] x25: ffff841fbb3f8080 x24: ffff841fbadc0018 [ 56.701425] x23: ffff000009119000 x22: ffff841fbb24e280 [ 56.706724] x21: ffff841ff212e780 x20: ffff841ff212e700 [ 56.712023] x19: 0000000000000001 x18: ffffffffffffffff [ 56.717322] x17: 0000000000000000 x16: 0000000000000000 [ 56.722621] x15: ffff0000091196c8 x14: 72635f7265687069 [ 56.727920] x13: 636b735f676c615f x12: ffff000009119940 [ 56.733219] x11: 0000000000000000 x10: 00000000006080c0 [ 56.738519] x9 : 0000000000000000 x8 : ffff841fbb24e480 [ 56.743818] x7 : ffff841fbb24e500 x6 : ffff841ff00cdcc0 [ 56.749117] x5 : 0000000000000010 x4 : 0000000000000000 [ 56.754416] x3 : ffff841fbb24e380 x2 : ffff841fbb24e480 [ 56.759715] x1 : 0000000000000000 x0 : ffff000008f682c8 [ 56.765016] Process insmod (pid: 2326, stack limit = 0x(____ptrval____)) [ 56.771702] Call trace: [ 56.774136] sec_alg_skcipher_crypto+0x318/0x748 [ 56.778740] sec_alg_skcipher_encrypt+0x10/0x18 [ 56.783259] test_skcipher_speed+0x2a0/0x700 [tcrypt] [ 56.788298] do_test+0x18f8/0x48c8 [tcrypt] [ 56.792469] tcrypt_mod_init+0x60/0x1000 [tcrypt] [ 56.797161] do_one_initcall+0x5c/0x178 [ 56.800985] do_init_module+0x58/0x1b4 [ 56.804721] load_module+0x1da4/0x2150 [ 56.808456] __se_sys_init_module+0x14c/0x1e8 [ 56.812799] __arm64_sys_init_module+0x18/0x20 [ 56.817231] el0_svc_common+0x60/0xe8 [ 56.820880] el0_svc_handler+0x2c/0x80 [ 56.824615] el0_svc+0x8/0xc [ 56.827483] Code: a94c87a3 910b2000 f87b7842 f9004ba2 (b87b7821) [ 56.833564] ---[ end trace 0f63290590e93d94 ]--- Segmentation fault Fix this by only accessing these memories when we have different src and dst. Fixes: 915e4e8413da ("crypto: hisilicon - SEC security accelerator driver") Reviewed-by: Jonathan Cameron <[email protected]> Cc: <[email protected]> Signed-off-by: John Garry <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2018-11-09x86/xen: fix pv bootJuergen Gross2-6/+32
Commit 9da3f2b7405440 ("x86/fault: BUG() when uaccess helpers fault on kernel addresses") introduced a regression for booting Xen PV guests. Xen PV guests are using __put_user() and __get_user() for accessing the p2m map (physical to machine frame number map) as accesses might fail in case of not populated areas of the map. With above commit using __put_user() and __get_user() for accessing kernel pages is no longer valid. So replace the Xen hack by adding appropriate p2m access functions using the default fixup handler. Fixes: 9da3f2b7405440 ("x86/fault: BUG() when uaccess helpers fault on kernel addresses") Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Andrew Cooper <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2018-11-08net: smsc95xx: Fix MTU rangeStefan Wahren1-0/+2
The commit f77f0aee4da4 ("net: use core MTU range checking in USB NIC drivers") introduce a common MTU handling for usbnet. But it's missing the necessary changes for smsc95xx. So set the MTU range accordingly. This patch has been tested on a Raspberry Pi 3. Fixes: f77f0aee4da4 ("net: use core MTU range checking in USB NIC drivers") Signed-off-by: Stefan Wahren <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-11-08net: stmmac: Fix RX packet size > 8191Thor Thayer4-4/+5
Ping problems with packets > 8191 as shown: PING 192.168.1.99 (192.168.1.99) 8150(8178) bytes of data. 8158 bytes from 192.168.1.99: icmp_seq=1 ttl=64 time=0.669 ms wrong data byte 8144 should be 0xd0 but was 0x0 16 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f %< ---------------snip-------------------------------------- 8112 b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf 8144 0 0 0 0 d0 d1 ^^^^^^^ Notice the 4 bytes of 0 before the expected byte of d0. Databook notes that the RX buffer must be a multiple of 4/8/16 bytes [1]. Update the DMA Buffer size define to 8188 instead of 8192. Remove the -1 from the RX buffer size allocations and use the new DMA Buffer size directly. [1] Synopsys DesignWare Cores Ethernet MAC Universal v3.70a [section 8.4.2 - Table 8-24] Tested on SoCFPGA Stratix10 with ping sweep from 100 to 8300 byte packets. Fixes: 286a83721720 ("stmmac: add CHAINED descriptor mode support (V4)") Suggested-by: Jose Abreu <[email protected]> Signed-off-by: Thor Thayer <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-11-08Merge branch 'qed-Slowpath-Queue-bug-fixes'David S. Miller9-43/+89
Denis Bolotin says: ==================== qed: Slowpath Queue bug fixes This patch series fixes several bugs in the SPQ mechanism. It deals with SPQ entries management, preventing resource leaks, memory corruptions and handles error cases throughout the driver. Please consider applying to net. ==================== Signed-off-by: David S. Miller <[email protected]>
2018-11-08qed: Fix potential memory corruptionSagiv Ozeri1-7/+5
A stuck ramrod should be deleted from the completion_pending list, otherwise it will be added again in the future and corrupt the list. Return error value to inform that ramrod is stuck and should be deleted. Signed-off-by: Sagiv Ozeri <[email protected]> Signed-off-by: Denis Bolotin <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-11-08qed: Fix SPQ entries not returned to pool in error flowsDenis Bolotin8-15/+45
qed_sp_destroy_request() API was added for SPQ users that need to free/return the entry they acquired in their error flows. Signed-off-by: Denis Bolotin <[email protected]> Signed-off-by: Michal Kalderon <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-11-08qed: Fix blocking/unlimited SPQ entries leakDenis Bolotin2-27/+33
When there are no SPQ entries left in the free_pool, new entries are allocated and are added to the unlimited list. When an entry in the pool is available, the content is copied from the original entry, and the new entry is sent to the device. qed_spq_post() is not aware of that, so the additional entry is stored in the original entry as p_post_ent, which can later be returned to the pool. Signed-off-by: Denis Bolotin <[email protected]> Signed-off-by: Michal Kalderon <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-11-08qed: Fix memory/entry leak in qed_init_sp_request()Denis Bolotin1-2/+14
Free the allocated SPQ entry or return the acquired SPQ entry to the free list in error flows. Signed-off-by: Denis Bolotin <[email protected]> Signed-off-by: Michal Kalderon <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-11-08inet: frags: better deal with smp racesEric Dumazet1-14/+15
Multiple cpus might attempt to insert a new fragment in rhashtable, if for example RPS is buggy, as reported by 배석진 in https://patchwork.ozlabs.org/patch/994601/ We use rhashtable_lookup_get_insert_key() instead of rhashtable_insert_fast() to let cpus losing the race free their own inet_frag_queue and use the one that was inserted by another cpu. Fixes: 648700f76b03 ("inet: frags: use rhashtables for reassembly units") Signed-off-by: Eric Dumazet <[email protected]> Reported-by: 배석진 <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-11-08net: hns3: bugfix for not checking return valueHuazhong Tan1-1/+2
hns3_reset_notify_init_enet() only return error early if the return value of hns3_restore_vlan() is not 0. This patch adds checking for the return value of hns3_restore_vlan. Fixes: 7fa6be4fd2f6 ("net: hns3: fix incorrect return value/type of some functions") Signed-off-by: Huazhong Tan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-11-08Merge tag 'xfs-4.20-fixes-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linuxLinus Torvalds3-4/+11
Pull xfs fixes from Darrick Wong: - fix incorrect dropping of error code from bmap - print buffer offsets instead of useless hashed pointers when dumping corrupt metadata - fix integer overflow in attribute verifier * tag 'xfs-4.20-fixes-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux: xfs: fix overflow in xfs_attr3_leaf_verify xfs: print buffer offsets when dumping corrupt buffers xfs: Fix error code in 'xfs_ioc_getbmap()'
2018-11-08Merge tag 'led-fixes-for-4.20-rc2' of ↵Linus Torvalds2-21/+10
git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds Pull LED fixes from Jacek Anaszewski: "All three fixes are related to the newly added pattern trigger: - remove mutex_lock() from timer callback, which would trigger problems related to sleeping in atomic context, the removal is harmless since mutex protection turned out to be redundant in this case - fix pattern parsing to properly handle intervals with brightness == 0 - fix typos in the ABI documentation" * tag 'led-fixes-for-4.20-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds: Documentation: ABI: led-trigger-pattern: Fix typos leds: trigger: Fix sleeping function called from invalid context Fix pattern handling optimalization
2018-11-08Merge tag 'sound-4.20-rc2' of ↵Linus Torvalds2-2/+5
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "Two small regression fixes for HD-audio: one about vga_switcheroo and runtime PM, and another about Oops on some Thinkpads" * tag 'sound-4.20-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ALSA: hda - Fix incorrect clearance of thinkpad_acpi hooks vga_switcheroo: Fix missing gpu_bound call at audio client registration
2018-11-08of, numa: Validate some distance map rulesJohn Garry1-2/+7
Currently the NUMA distance map parsing does not validate the distance table for the distance-matrix rules 1-2 in [1]. However the arch NUMA code may enforce some of these rules, but not all. Such is the case for the arm64 port, which does not enforce the rule that the distance between separates nodes cannot equal LOCAL_DISTANCE. The patch adds the following rules validation: - distance of node to self equals LOCAL_DISTANCE - distance of separate nodes > LOCAL_DISTANCE This change avoids a yet-unresolved crash reported in [2]. A note on dealing with symmetrical distances between nodes: Validating symmetrical distances between nodes is difficult. If it were mandated in the bindings that every distance must be recorded in the table, then it would be easy. However, it isn't. In addition to this, it is also possible to record [b, a] distance only (and not [a, b]). So, when processing the table for [b, a], we cannot assert that current distance of [a, b] != [b, a] as invalid, as [a, b] distance may not be present in the table and current distance would be default at REMOTE_DISTANCE. As such, we maintain the policy that we overwrite distance [a, b] = [b, a] for b > a. This policy is different to kernel ACPI SLIT validation, which allows non-symmetrical distances (ACPI spec SLIT rules allow it). However, the distance debug message is dropped as it may be misleading (for a distance which is later overwritten). Some final notes on semantics: - It is implied that it is the responsibility of the arch NUMA code to reset the NUMA distance map for an error in distance map parsing. - It is the responsibility of the FW NUMA topology parsing (whether OF or ACPI) to enforce NUMA distance rules, and not arch NUMA code. [1] Documents/devicetree/bindings/numa.txt [2] https://www.spinics.net/lists/arm-kernel/msg683304.html Cc: [email protected] # 4.7 Signed-off-by: John Garry <[email protected]> Acked-by: Will Deacon <[email protected]> Signed-off-by: Rob Herring <[email protected]>
2018-11-08of/device: Really only set bus DMA mask when appropriateRobin Murphy1-1/+3
of_dma_configure() was *supposed* to be following the same logic as acpi_dma_configure() and only setting bus_dma_mask if some range was specified by the firmware. However, it seems that subtlety got lost in the process of fitting it into the differently-shaped control flow, and as a result the force_dma==true case ends up always setting the bus mask to the 32-bit default, which is not what anyone wants. Make sure we only touch it if the DT actually said so. Fixes: 6c2fb2ea7636 ("of/device: Set bus DMA mask as appropriate") Reported-by: Aaro Koskinen <[email protected]> Reported-by: Jean-Philippe Brucker <[email protected]> Tested-by: Aaro Koskinen <[email protected]> Tested-by: John Stultz <[email protected]> Tested-by: Geert Uytterhoeven <[email protected]> Tested-by: Robert Richter <[email protected]> Signed-off-by: Robin Murphy <[email protected]> Signed-off-by: Rob Herring <[email protected]>
2018-11-08clk: meson: axg: mark fdiv2 and fdiv3 as criticalJerome Brunet1-0/+13
Similar to gxbb and gxl platforms, axg SCPI Cortex-M co-processor uses the fdiv2 and fdiv3 to, among other things, provide the cpu clock. Until clock hand-off mechanism makes its way to CCF and the generic SCPI claims platform specific clocks, these clocks must be marked as critical to make sure they are never disabled when needed by the co-processor. Fixes: 05f814402d61 ("clk: meson: add fdiv clock gates") Signed-off-by: Jerome Brunet <[email protected]> Acked-by: Neil Armstrong <[email protected]> Signed-off-by: Stephen Boyd <[email protected]>
2018-11-08clk: meson-gxbb: set fclk_div3 as CLK_IS_CRITICALChristian Hewitt1-0/+12
On the Khadas VIM2 (GXM) and LePotato (GXL) board there are problems with reboot; e.g. a ~60 second delay between issuing reboot and the board power cycling (and in some OS configurations reboot will fail and require manual power cycling). Similar to 'commit c987ac6f1f088663b6dad39281071aeb31d450a8 ("clk: meson-gxbb: set fclk_div2 as CLK_IS_CRITICAL")' the SCPI Cortex-M4 Co-Processor seems to depend on FCLK_DIV3 being operational. Until commit 05f814402d6174369b3b29832cbb5eb5ed287059 ("clk: meson: add fdiv clock gates"), this clock was modeled and left on by the bootloader. We don't have precise documentation about the SCPI Co-Processor and its clock requirement so we are learning things the hard way. Marking this clock as critical solves the problem but it should not be viewed as final solution. Ideally, the SCPI driver should claim these clocks. We also depends on some clock hand-off mechanism making its way to CCF, to make sure the clock stays on between its registration and the SCPI driver probe. Fixes: 05f814402d61 ("clk: meson: add fdiv clock gates") Signed-off-by: Christian Hewitt <[email protected]> Signed-off-by: Jerome Brunet <[email protected]> Signed-off-by: Stephen Boyd <[email protected]>
2018-11-08arm64: memblock: don't permit memblock resizing until linear mapping is upArd Biesheuvel2-2/+2
Bhupesh reports that having numerous memblock reservations at early boot may result in the following crash: Unable to handle kernel paging request at virtual address ffff80003ffe0000 ... Call trace: __memcpy+0x110/0x180 memblock_add_range+0x134/0x2e8 memblock_reserve+0x70/0xb8 memblock_alloc_base_nid+0x6c/0x88 __memblock_alloc_base+0x3c/0x4c memblock_alloc_base+0x28/0x4c memblock_alloc+0x2c/0x38 early_pgtable_alloc+0x20/0xb0 paging_init+0x28/0x7f8 This is caused by the fact that we permit memblock resizing before the linear mapping is up, and so the memblock_reserved() array is moved into memory that is not mapped yet. So let's ensure that this crash can no longer occur, by deferring to call to memblock_allow_resize() to after the linear mapping has been created. Reported-by: Bhupesh Sharma <[email protected]> Acked-by: Will Deacon <[email protected]> Tested-by: Marc Zyngier <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Catalin Marinas <[email protected]>
2018-11-08ARM: cpuidle: Convert to use cpuidle_register|unregister()Ulf Hansson1-27/+3
The only reason that remains, to why the ARM cpuidle driver calls cpuidle_register_driver(), is to avoid printing an error message in case another driver already have been registered for the CPU. This seems a bit silly, but more importantly, if that is a common scenario, perhaps we should change cpuidle_register() accordingly instead. In either case, let's consolidate the code, by converting to use cpuidle_register|unregister(), which also avoids the unnecessary allocation of the struct cpuidle_device. Signed-off-by: Ulf Hansson <[email protected]> Reviewed-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Daniel Lezcano <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2018-11-08ARM: cpuidle: Don't register the driver when back-end init returns -ENXIOUlf Hansson1-12/+10
There's no point to register the cpuidle driver for the current CPU, when the initialization of the arch specific back-end data fails by returning -ENXIO. Instead, let's re-order the sequence to its original flow, by first trying to initialize the back-end part and then act accordingly on the returned error code. Additionally, let's print the error message, no matter of what error code that was returned. Fixes: a0d46a3dfdc3 (ARM: cpuidle: Register per cpuidle device) Signed-off-by: Ulf Hansson <[email protected]> Reviewed-by: Daniel Lezcano <[email protected]> Cc: 4.19+ <[email protected]> # v4.19+ Signed-off-by: Rafael J. Wysocki <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.