aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2018-06-28Merge tag 'mtd/fixes-for-4.18-rc3' of git://git.infradead.org/linux-mtdLinus Torvalds7-25/+61
Pull mtd fixes from Boris Brezillon: "NAND fixes: - add a quirk for a bunch of broken Macronix chips - fix nand_block_bad() when chip->ecc.read_oob() returns a positive value encoding the number of bitflips - fix OOB handling in the MXC driver fo V2.1 controllers - flag the ONFI_FEATURE_ON_DIE_ECC as supported in the Micron driver - hardcode clk rate in the denali_dt driver to address a bad DT representation (the proper fix will be queued for 4.19) SPI NOR fixes: - add an ULL constant to some ID definitions so that the ID is not truncated on 32-bit platforms MTD fixes: - fix the sector unlocking logic in the CFI driver" * tag 'mtd/fixes-for-4.18-rc3' of git://git.infradead.org/linux-mtd: mtd: rawnand: denali_dt: set clk_x_rate to 200 MHz unconditionally mtd: dataflash: Use ULL suffix for 64-bit constants mtd: cfi_cmdset_0002: Avoid walking all chips when unlocking. mtd: cfi_cmdset_0002: Fix unlocking requests crossing a chip boudary mtd: cfi_cmdset_0002: fix SEGV unlocking multiple chips mtd: cfi_cmdset_0002: Use right chip in do_ppb_xxlock() mtd: rawnand: All AC chips have a broken GET_FEATURES(TIMINGS). mtd: rawnand: fix return value check for bad block status mtd: rawnand: mxc: set spare area size register explicitly mtd: rawnand: micron: add ONFI_FEATURE_ON_DIE_ECC to supported features
2018-06-28Merge branch 'akpm' (patches from Andrew)Linus Torvalds9-8/+38
Merge fixes from Andrew Morton: "7 fixes" * emailed patches from Andrew Morton <[email protected]>: proc: add Alexey to MAINTAINERS kasan: depend on CONFIG_SLUB_DEBUG include/linux/dax.h: dax_iomap_fault() returns vm_fault_t x86/e820: put !E820_TYPE_RAM regions into memblock.reserved slub: fix failure when we delete and create a slab cache Revert mm/vmstat.c: fix vmstat_update() preemption BUG lib/percpu_ida.c: don't do alloc from per-CPU list if there is none
2018-06-28proc: add Alexey to MAINTAINERSAlexey Dobriyan1-0/+9
I know I'll regret it. Link: http://lkml.kernel.org/r/20180627194840.GA18113@avx2 Signed-off-by: Alexey Dobriyan <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-06-28kasan: depend on CONFIG_SLUB_DEBUGJason A. Donenfeld1-0/+1
KASAN depends on having access to some of the accounting that SLUB_DEBUG does; without it, there are immediate crashes [1]. So, the natural thing to do is to make KASAN select SLUB_DEBUG. [1] http://lkml.kernel.org/r/CAHmME9rtoPwxUSnktxzKso14iuVCWT7BE_-_8PAC=pGw1iJnQg@mail.gmail.com Link: http://lkml.kernel.org/r/[email protected] Fixes: f9e13c0a5a33 ("slab, slub: skip unnecessary kasan_cache_shutdown()") Signed-off-by: Jason A. Donenfeld <[email protected]> Acked-by: Michal Hocko <[email protected]> Reviewed-by: Shakeel Butt <[email protected]> Acked-by: Christoph Lameter <[email protected]> Cc: Shakeel Butt <[email protected]> Cc: David Rientjes <[email protected]> Cc: Pekka Enberg <[email protected]> Cc: Joonsoo Kim <[email protected]> Cc: Andrey Ryabinin <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-06-28include/linux/dax.h: dax_iomap_fault() returns vm_fault_tSouptick Joarder1-1/+1
Commit 1c8f422059ae ("mm: change return type to vm_fault_t") missed a conversion. It's not a big problem at present because mainline is still using typedef int vm_fault_t; Fixes: 1c8f422059ae ("mm: change return type to vm_fault_t") Link: http://lkml.kernel.org/r/20180620172046.GA27894@jordon-HP-15-Notebook-PC Signed-off-by: Souptick Joarder <[email protected]> Reviewed-by: Andrew Morton <[email protected]> Cc: Matthew Wilcox <[email protected]> Cc: Dan Williams <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-06-28x86/e820: put !E820_TYPE_RAM regions into memblock.reservedNaoya Horiguchi1-3/+12
There is a kernel panic that is triggered when reading /proc/kpageflags on the kernel booted with kernel parameter 'memmap=nn[KMG]!ss[KMG]': BUG: unable to handle kernel paging request at fffffffffffffffe PGD 9b20e067 P4D 9b20e067 PUD 9b210067 PMD 0 Oops: 0000 [#1] SMP PTI CPU: 2 PID: 1728 Comm: page-types Not tainted 4.17.0-rc6-mm1-v4.17-rc6-180605-0816-00236-g2dfb086ef02c+ #160 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.fc28 04/01/2014 RIP: 0010:stable_page_flags+0x27/0x3c0 Code: 00 00 00 0f 1f 44 00 00 48 85 ff 0f 84 a0 03 00 00 41 54 55 49 89 fc 53 48 8b 57 08 48 8b 2f 48 8d 42 ff 83 e2 01 48 0f 44 c7 <48> 8b 00 f6 c4 01 0f 84 10 03 00 00 31 db 49 8b 54 24 08 4c 89 e7 RSP: 0018:ffffbbd44111fde0 EFLAGS: 00010202 RAX: fffffffffffffffe RBX: 00007fffffffeff9 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000202 RDI: ffffed1182fff5c0 RBP: ffffffffffffffff R08: 0000000000000001 R09: 0000000000000001 R10: ffffbbd44111fed8 R11: 0000000000000000 R12: ffffed1182fff5c0 R13: 00000000000bffd7 R14: 0000000002fff5c0 R15: ffffbbd44111ff10 FS: 00007efc4335a500(0000) GS:ffff93a5bfc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: fffffffffffffffe CR3: 00000000b2a58000 CR4: 00000000001406e0 Call Trace: kpageflags_read+0xc7/0x120 proc_reg_read+0x3c/0x60 __vfs_read+0x36/0x170 vfs_read+0x89/0x130 ksys_pread64+0x71/0x90 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7efc42e75e23 Code: 09 00 ba 9f 01 00 00 e8 ab 81 f4 ff 66 2e 0f 1f 84 00 00 00 00 00 90 83 3d 29 0a 2d 00 00 75 13 49 89 ca b8 11 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 34 c3 48 83 ec 08 e8 db d3 01 00 48 89 04 24 According to kernel bisection, this problem became visible due to commit f7f99100d8d9 ("mm: stop zeroing memory during allocation in vmemmap") which changes how struct pages are initialized. Memblock layout affects the pfn ranges covered by node/zone. Consider that we have a VM with 2 NUMA nodes and each node has 4GB memory, and the default (no memmap= given) memblock layout is like below: MEMBLOCK configuration: memory size = 0x00000001fff75c00 reserved size = 0x000000000300c000 memory.cnt = 0x4 memory[0x0] [0x0000000000001000-0x000000000009efff], 0x000000000009e000 bytes on node 0 flags: 0x0 memory[0x1] [0x0000000000100000-0x00000000bffd6fff], 0x00000000bfed7000 bytes on node 0 flags: 0x0 memory[0x2] [0x0000000100000000-0x000000013fffffff], 0x0000000040000000 bytes on node 0 flags: 0x0 memory[0x3] [0x0000000140000000-0x000000023fffffff], 0x0000000100000000 bytes on node 1 flags: 0x0 ... If you give memmap=1G!4G (so it just covers memory[0x2]), the range [0x100000000-0x13fffffff] is gone: MEMBLOCK configuration: memory size = 0x00000001bff75c00 reserved size = 0x000000000300c000 memory.cnt = 0x3 memory[0x0] [0x0000000000001000-0x000000000009efff], 0x000000000009e000 bytes on node 0 flags: 0x0 memory[0x1] [0x0000000000100000-0x00000000bffd6fff], 0x00000000bfed7000 bytes on node 0 flags: 0x0 memory[0x2] [0x0000000140000000-0x000000023fffffff], 0x0000000100000000 bytes on node 1 flags: 0x0 ... This causes shrinking node 0's pfn range because it is calculated by the address range of memblock.memory. So some of struct pages in the gap range are left uninitialized. We have a function zero_resv_unavail() which does zeroing the struct pages within the reserved unavailable range (i.e. memblock.memory && !memblock.reserved). This patch utilizes it to cover all unavailable ranges by putting them into memblock.reserved. Link: http://lkml.kernel.org/r/[email protected] Fixes: f7f99100d8d9 ("mm: stop zeroing memory during allocation in vmemmap") Signed-off-by: Naoya Horiguchi <[email protected]> Tested-by: Oscar Salvador <[email protected]> Tested-by: "Herton R. Krzesinski" <[email protected]> Acked-by: Michal Hocko <[email protected]> Reviewed-by: Pavel Tatashin <[email protected]> Cc: Steven Sistare <[email protected]> Cc: Daniel Jordan <[email protected]> Cc: Matthew Wilcox <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-06-28slub: fix failure when we delete and create a slab cacheMikulas Patocka3-1/+14
In kernel 4.17 I removed some code from dm-bufio that did slab cache merging (commit 21bb13276768: "dm bufio: remove code that merges slab caches") - both slab and slub support merging caches with identical attributes, so dm-bufio now just calls kmem_cache_create and relies on implicit merging. This uncovered a bug in the slub subsystem - if we delete a cache and immediatelly create another cache with the same attributes, it fails because of duplicate filename in /sys/kernel/slab/. The slub subsystem offloads freeing the cache to a workqueue - and if we create the new cache before the workqueue runs, it complains because of duplicate filename in sysfs. This patch fixes the bug by moving the call of kobject_del from sysfs_slab_remove_workfn to shutdown_cache. kobject_del must be called while we hold slab_mutex - so that the sysfs entry is deleted before a cache with the same attributes could be created. Running device-mapper-test-suite with: dmtest run --suite thin-provisioning -n /commit_failure_causes_fallback/ triggered: Buffer I/O error on dev dm-0, logical block 1572848, async page read device-mapper: thin: 253:1: metadata operation 'dm_pool_alloc_data_block' failed: error = -5 device-mapper: thin: 253:1: aborting current metadata transaction sysfs: cannot create duplicate filename '/kernel/slab/:a-0000144' CPU: 2 PID: 1037 Comm: kworker/u48:1 Not tainted 4.17.0.snitm+ #25 Hardware name: Supermicro SYS-1029P-WTR/X11DDW-L, BIOS 2.0a 12/06/2017 Workqueue: dm-thin do_worker [dm_thin_pool] Call Trace: dump_stack+0x5a/0x73 sysfs_warn_dup+0x58/0x70 sysfs_create_dir_ns+0x77/0x80 kobject_add_internal+0xba/0x2e0 kobject_init_and_add+0x70/0xb0 sysfs_slab_add+0xb1/0x250 __kmem_cache_create+0x116/0x150 create_cache+0xd9/0x1f0 kmem_cache_create_usercopy+0x1c1/0x250 kmem_cache_create+0x18/0x20 dm_bufio_client_create+0x1ae/0x410 [dm_bufio] dm_block_manager_create+0x5e/0x90 [dm_persistent_data] __create_persistent_data_objects+0x38/0x940 [dm_thin_pool] dm_pool_abort_metadata+0x64/0x90 [dm_thin_pool] metadata_operation_failed+0x59/0x100 [dm_thin_pool] alloc_data_block.isra.53+0x86/0x180 [dm_thin_pool] process_cell+0x2a3/0x550 [dm_thin_pool] do_worker+0x28d/0x8f0 [dm_thin_pool] process_one_work+0x171/0x370 worker_thread+0x49/0x3f0 kthread+0xf8/0x130 ret_from_fork+0x35/0x40 kobject_add_internal failed for :a-0000144 with -EEXIST, don't try to register things with the same name in the same directory. kmem_cache_create(dm_bufio_buffer-16) failed with error -17 Link: http://lkml.kernel.org/r/alpine.LRH.2.02.1806151817130.6333@file01.intranet.prod.int.rdu2.redhat.com Signed-off-by: Mikulas Patocka <[email protected]> Reported-by: Mike Snitzer <[email protected]> Tested-by: Mike Snitzer <[email protected]> Cc: Christoph Lameter <[email protected]> Cc: Pekka Enberg <[email protected]> Cc: David Rientjes <[email protected]> Cc: Joonsoo Kim <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-06-28Revert mm/vmstat.c: fix vmstat_update() preemption BUGSebastian Andrzej Siewior1-2/+0
Revert commit c7f26ccfb2c3 ("mm/vmstat.c: fix vmstat_update() preemption BUG"). Steven saw a "using smp_processor_id() in preemptible" message and added a preempt_disable() section around it to keep it quiet. This is not the right thing to do it does not fix the real problem. vmstat_update() is invoked by a kworker on a specific CPU. This worker it bound to this CPU. The name of the worker was "kworker/1:1" so it should have been a worker which was bound to CPU1. A worker which can run on any CPU would have a `u' before the first digit. smp_processor_id() can be used in a preempt-enabled region as long as the task is bound to a single CPU which is the case here. If it could run on an arbitrary CPU then this is the problem we have an should seek to resolve. Not only this smp_processor_id() must not be migrated to another CPU but also refresh_cpu_vm_stats() which might access wrong per-CPU variables. Not to mention that other code relies on the fact that such a worker runs on one specific CPU only. Therefore revert that commit and we should look instead what broke the affinity mask of the kworker. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Sebastian Andrzej Siewior <[email protected]> Cc: Steven J. Hill <[email protected]> Cc: Tejun Heo <[email protected]> Cc: Vlastimil Babka <[email protected]> Cc: Thomas Gleixner <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-06-28lib/percpu_ida.c: don't do alloc from per-CPU list if there is noneSebastian Andrzej Siewior1-1/+1
In commit 804209d8a009 ("lib/percpu_ida.c: use _irqsave() instead of local_irq_save() + spin_lock") I inlined alloc_local_tag() and mixed up the >= check from percpu_ida_alloc() with the one in alloc_local_tag(). Don't alloc from per-CPU freelist if ->nr_free is zero. Link: http://lkml.kernel.org/r/[email protected] Fixes: 804209d8a009 ("lib/percpu_ida.c: use _irqsave() instead of local_irq_save() + spin_lock") Signed-off-by: Sebastian Andrzej Siewior <[email protected]> Reported-by: David Disseldorp <[email protected]> Tested-by: David Disseldorp <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Nicholas Bellinger <[email protected]> Cc: Shaohua Li <[email protected]> Cc: Kent Overstreet <[email protected]> Cc: Matthew Wilcox <[email protected]> Cc: Jens Axboe <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-06-28Revert changes to convert to ->poll_mask() and aio IOCB_CMD_POLLLinus Torvalds80-450/+301
The poll() changes were not well thought out, and completely unexplained. They also caused a huge performance regression, because "->poll()" was no longer a trivial file operation that just called down to the underlying file operations, but instead did at least two indirect calls. Indirect calls are sadly slow now with the Spectre mitigation, but the performance problem could at least be largely mitigated by changing the "->get_poll_head()" operation to just have a per-file-descriptor pointer to the poll head instead. That gets rid of one of the new indirections. But that doesn't fix the new complexity that is completely unwarranted for the regular case. The (undocumented) reason for the poll() changes was some alleged AIO poll race fixing, but we don't make the common case slower and more complex for some uncommon special case, so this all really needs way more explanations and most likely a fundamental redesign. [ This revert is a revert of about 30 different commits, not reverted individually because that would just be unnecessarily messy - Linus ] Cc: Al Viro <[email protected]> Cc: Christoph Hellwig <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-06-28arm64: dts: hikey960: Define wl1837 power capabilitiesoscardagrach1-0/+2
These properties are required for compatibility with runtime PM. Without these properties, MMC host controller will not be aware of power capabilities. When the wlcore driver attempts to power on the device, it will erroneously fail with -EACCES. This fixes a regression found here: https://lkml.org/lkml/2018/6/12/930 Fixes: 60f36637bbbd ("wlcore: sdio: allow pm to handle sdio power") Signed-off-by: Ryan Grachek <[email protected]> Tested-by: John Stultz <[email protected]> Acked-by: John Stultz <[email protected]> Tested-by: Valentin Schneider <[email protected]> Signed-off-by: Wei Xu <[email protected]>
2018-06-28arm64: dts: hikey: Define wl1835 power capabilitiesoscardagrach1-0/+2
These properties are required for compatibility with runtime PM. Without these properties, MMC host controller will not be aware of power capabilities. When the wlcore driver attempts to power on the device, it will erroneously fail with -EACCES. Fixes: 60f36637bbbd ("wlcore: sdio: allow pm to handle sdio power") Signed-off-by: Ryan Grachek <[email protected]> Tested-by: John Stultz <[email protected]> Acked-by: John Stultz <[email protected]> Signed-off-by: Wei Xu <[email protected]>
2018-06-28block: Fix cloning of requests with a special payloadBart Van Assche1-0/+4
This patch avoids that removing a path controlled by the dm-mpath driver while mkfs is running triggers the following kernel bug: kernel BUG at block/blk-core.c:3347! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 20 PID: 24369 Comm: mkfs.ext4 Not tainted 4.18.0-rc1-dbg+ #2 RIP: 0010:blk_end_request_all+0x68/0x70 Call Trace: <IRQ> dm_softirq_done+0x326/0x3d0 [dm_mod] blk_done_softirq+0x19b/0x1e0 __do_softirq+0x128/0x60d irq_exit+0x100/0x110 smp_call_function_single_interrupt+0x90/0x330 call_function_single_interrupt+0xf/0x20 </IRQ> Fixes: f9d03f96b988 ("block: improve handling of the magic discard payload") Reviewed-by: Ming Lei <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Acked-by: Mike Snitzer <[email protected]> Signed-off-by: Bart Van Assche <[email protected]> Cc: Hannes Reinecke <[email protected]> Cc: Johannes Thumshirn <[email protected]> Cc: <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2018-06-28parisc: Wire up io_pgetevents syscallHelge Deller2-1/+3
Signed-off-by: Helge Deller <[email protected]>
2018-06-28parisc: Default to 4 SMP CPUsHelge Deller1-1/+1
I haven't seen any real SMP machine yet with > 4 CPUs (we don't suport SuperDomes yet), so reducing the default maximum number of CPUs may speed up various bitop functions which depend on number of CPUs in the system. bload-o-meter on a typical 64-bit kernel shows: Data: add/remove: 0/0 grow/shrink: 0/10 up/down: 0/-3724 (-3724) Total: Before=1910404, After=1906680, chg -0.19% Code: add/remove: 0/2 grow/shrink: 42/38 up/down: 2320/-3500 (-1180) Total: Before=11053099, After=11051919, chg -0.01% Signed-off-by: Helge Deller <[email protected]>
2018-06-28parisc: Convert printk(KERN_LEVEL) to pr_lvl()Andy Shevchenko1-16/+9
Convert printk(KERN_LEVEL) type of calls to pr_lvl() macros. While here, - convert printk() to pr_info() - join back string literal to be on one line - use %*phN (note, it gives 1 byte more for sake of simplicity) Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Helge Deller <[email protected]>
2018-06-28parisc: Mark 16kB and 64kB page sizes BROKENHelge Deller1-2/+2
A full boot only succeeds with 4kB page sizes currently. For 16kB and 64kB page size support somone needs to fix the LBA PCI code at least, so mark those broken for now. Signed-off-by: Helge Deller <[email protected]>
2018-06-28parisc: Drop struct sigaction from not exported header fileHelge Deller1-8/+0
This header file isn't exported to userspace, so there is no benefit in defining struct sigaction for userspace here. Signed-off-by: Helge Deller <[email protected]>
2018-06-28nvme-rdma: fix possible double free of controller async event bufferSagi Grimberg1-2/+5
If reconnect/reset failed where the controller async event buffer was freed, we might end up freeing it again as we call nvme_rdma_destroy_admin_queue again in the remove path. Given that the sequence is guaranteed to serialize by .ctrl_stop, we simply set ctrl->async_event_sqe.data to NULL and don't free it in future visits. Reported-by: Max Gurtovoy <[email protected]> Tested-by: Max Gurtovoy <[email protected]> Signed-off-by: Sagi Grimberg <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
2018-06-28kconfig: loop boundary condition fixJerry James1-1/+1
If buf[-1] just happens to hold the byte 0x0A, then nread can wrap around to (size_t)-1, leading to invalid memory accesses. This has caused segmentation faults when trying to build the latest kernel snapshots for i686 in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1592374 Signed-off-by: Jerry James <[email protected]> [[email protected]: reformatted patch for submission] Signed-off-by: Alexander Ploumistos <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2018-06-28kbuild: reword help of LD_DEAD_CODE_DATA_ELIMINATIONMasahiro Yamada1-4/+3
Since commit 5d20ee3192a5 ("kbuild: Allow LD_DEAD_CODE_DATA_ELIMINATION to be selectable if enabled"), HAVE_LD_DEAD_CODE_DATA_ELIMINATION is supposed to be selected by architectures that are capable of this functionality. LD_DEAD_CODE_DATA_ELIMINATION is now users' selection. Update the help message. Signed-off-by: Masahiro Yamada <[email protected]>
2018-06-28kconfig: handle P_SYMBOL in print_symbol()Dirk Gouders2-0/+7
Each symbol has a property of type P_SYMBOL since commit 59e89e3ddf85 (kconfig: save location of config symbols). Handle those properties in print_symbol(). Further, place a pointer to print_symbol() in the comment above the list of known property type. Signed-off-by: Dirk Gouders <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2018-06-28vt: unicode fallback for scrollbackNicolas Pitre3-4/+32
There is currently no provision for scrollback content in the core code, leaving that to backend video drivers where this can be highly optimized. There is currently no common method for those drivers to tell the core what part of the scrollback is actually displayed and what size the scrollback buffer is either. Because of that, the unicode screen buffer has no provision for any scrollback. At least we can provide backtranslated glyph values when the scrollback is active which should be plenty good enough for now. Signed-off-by: Nicolas Pitre <[email protected]> Tested-by: Dave Mielke <[email protected]> Acked-by: Adam Borowski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-06-28vt: introduce unicode mode for /dev/vcsNicolas Pitre3-14/+141
Now that the core vt code knows how to preserve unicode values for each displayed character, it is then possible to let user space access it via /dev/vcs*. Unicode characters are presented as 32 bit values in native endianity via the /dev/vcsu* devices, mimicking the simple /dev/vcs* devices. Unicode with attributes (similarly to /dev/vcsa*) is not supported at the moment. Data is available only as long as the console is in UTF-8 mode. ENODATA is returned otherwise. This was tested with the latest development version (to become version 5.7) of BRLTTY. Amongst other things, this allows ⠋⠕⠗ ⠞⠓⠊⠎ ⠃⠗⠁⠊⠇⠇⠑⠀⠞⠑⠭⠞⠀to appear directly on braille displays regardless of the console font being used. Signed-off-by: Nicolas Pitre <[email protected]> Tested-by: Dave Mielke <[email protected]> Acked-by: Adam Borowski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-06-28vt: preserve unicode values corresponding to screen charactersNicolas Pitre2-11/+211
The vt code translates UTF-8 strings into glyph index values and stores those glyph values directly in the screen buffer. Because there can only be at most 512 glyphs, it is impossible to represent most unicode characters, in which case a default glyph (often '?') is displayed instead. The original unicode value is then lost. This patch implements the basic screen buffer handling to preserve unicode values alongside corresponding display glyphs. It is not activated by default, meaning that people not relying on that functionality won't get the implied overhead. Signed-off-by: Nicolas Pitre <[email protected]> Tested-by: Dave Mielke <[email protected]> Acked-by: Adam Borowski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-06-28vt: prevent leaking uninitialized data to userspace via /dev/vcs*Alexander Potapenko1-2/+2
KMSAN reported an infoleak when reading from /dev/vcs*: BUG: KMSAN: kernel-infoleak in vcs_read+0x18ba/0x1cc0 Call Trace: ... kmsan_copy_to_user+0x7a/0x160 mm/kmsan/kmsan.c:1253 copy_to_user ./include/linux/uaccess.h:184 vcs_read+0x18ba/0x1cc0 drivers/tty/vt/vc_screen.c:352 __vfs_read+0x1b2/0x9d0 fs/read_write.c:416 vfs_read+0x36c/0x6b0 fs/read_write.c:452 ... Uninit was created at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:279 kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:189 kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:315 __kmalloc+0x13a/0x350 mm/slub.c:3818 kmalloc ./include/linux/slab.h:517 vc_allocate+0x438/0x800 drivers/tty/vt/vt.c:787 con_install+0x8c/0x640 drivers/tty/vt/vt.c:2880 tty_driver_install_tty drivers/tty/tty_io.c:1224 tty_init_dev+0x1b5/0x1020 drivers/tty/tty_io.c:1324 tty_open_by_driver drivers/tty/tty_io.c:1959 tty_open+0x17b4/0x2ed0 drivers/tty/tty_io.c:2007 chrdev_open+0xc25/0xd90 fs/char_dev.c:417 do_dentry_open+0xccc/0x1440 fs/open.c:794 vfs_open+0x1b6/0x2f0 fs/open.c:908 ... Bytes 0-79 of 240 are uninitialized Consistently allocating |vc_screenbuf| with kzalloc() fixes the problem Reported-by: [email protected] Signed-off-by: Alexander Potapenko <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-06-28serdev: fix memleak on module unloadJohan Hovold1-0/+1
Make sure to free all resources associated with the ida on module exit. Fixes: cd6484e1830b ("serdev: Introduce new bus for serial attached devices") Cc: stable <[email protected]> # 4.11 Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-06-28serial: 8250_pci: Remove stalled entries in blacklistAndy Shevchenko1-2/+0
After the commit 7d8905d06405 ("serial: 8250_pci: Enable device after we check black list") pure serial multi-port cards, such as CH355, got blacklisted and thus not being enumerated anymore. Previously, it seems, blacklisting them was on purpose to shut up pciserial_init_one() about record duplication. So, remove the entries from blacklist in order to get cards enumerated. Fixes: 7d8905d06405 ("serial: 8250_pci: Enable device after we check black list") Reported-by: Matt Turner <[email protected]> Cc: Sergej Pupykin <[email protected]> Cc: Alexandr Petrenko <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-and-Tested-by: Matt Turner <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-06-28n_tty: Access echo_* variables carefully.Tetsuo Handa1-18/+24
syzbot is reporting stalls at __process_echoes() [1]. This is because since ldata->echo_commit < ldata->echo_tail becomes true for some reason, the discard loop is serving as almost infinite loop. This patch tries to avoid falling into ldata->echo_commit < ldata->echo_tail situation by making access to echo_* variables more carefully. Since reset_buffer_flags() is called without output_lock held, it should not touch echo_* variables. And omit a call to reset_buffer_flags() from n_tty_open() by using vzalloc(). Since add_echo_byte() is called without output_lock held, it needs memory barrier between storing into echo_buf[] and incrementing echo_head counter. echo_buf() needs corresponding memory barrier before reading echo_buf[]. Lack of handling the possibility of not-yet-stored multi-byte operation might be the reason of falling into ldata->echo_commit < ldata->echo_tail situation, for if I do WARN_ON(ldata->echo_commit == tail + 1) prior to echo_buf(ldata, tail + 1), the WARN_ON() fires. Also, explicitly masking with buffer for the former "while" loop, and use ldata->echo_commit > tail for the latter "while" loop. [1] https://syzkaller.appspot.com/bug?id=17f23b094cd80df750e5b0f8982c521ee6bcbf40 Signed-off-by: Tetsuo Handa <[email protected]> Reported-by: syzbot <[email protected]> Cc: Peter Hurley <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-06-28n_tty: Fix stall at n_tty_receive_char_special().Tetsuo Handa1-5/+8
syzbot is reporting stalls at n_tty_receive_char_special() [1]. This is because comparison is not working as expected since ldata->read_head can change at any moment. Mitigate this by explicitly masking with buffer size when checking condition for "while" loops. [1] https://syzkaller.appspot.com/bug?id=3d7481a346958d9469bebbeb0537d5f056bdd6e8 Signed-off-by: Tetsuo Handa <[email protected]> Reported-by: syzbot <[email protected]> Fixes: bc5a5e3f45d04784 ("n_tty: Don't wrap input buffer indices at buffer size") Cc: stable <[email protected]> Cc: Peter Hurley <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-06-28serial: xuartps: remove unnecessary register writeHelmut Grohne1-2/+0
This writel writes the exact same value as the previous writel and is thus unnecessary. It accidentally became unnecessary in e3538c37ee38 ("tty: xuartps: Beautify read-modify writes"), but the new behaviour is now expected. Link: https://www.spinics.net/lists/linux-serial/msg23168.html Signed-off-by: Helmut Grohne <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-06-28serial: xuartps: reduce hardware TX race conditionHelmut Grohne1-12/+7
After sending data to the uart, the driver was waiting until the TX FIFO was empty (for every single char written). After that, TX was disabled by writing the original TX state to the status register. At that time however, the state machine could still be shifting characters. Not waiting can result in strange hardware states, especially when coupled with calls to cdns_uart_set_termios, whose symptom generally is garbage characters being received from uart or a hang. According to UG585, the TACTIVE bit of the channel status register indicates the shifter operation and we should be waiting for that bit to clear. Sending characters does not require the TX FIFO to be empty, but merely to not be full. So cdns_uart_console_putchar is updated accordingly. During tests with an instrumented kernel and an oscilloscope, we could determine that the chance of a race is reduced by this patch. It is not removed entirely. On the oscilloscope, one can see that disabling the transmitter early can result in the transmission hanging in the middle of a character for a tiny duration. This hiccup is enough to desynchronize with a remote device for a sequence of characters until a data bit doesn't match the start or stop bits anymore. Link: https://www.spinics.net/lists/linux-serial/msg23156.html Link: https://www.spinics.net/lists/linux-serial/msg26139.html Signed-off-by: Helmut Grohne <[email protected]> Acked-by: Sören Brinkmann <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-06-28serial: xuartps: fix typo in cdns_uart_startupHelmut Grohne1-1/+1
The bit mask changes in commit 6e14f7c1f2c2 ("tty: xuartps: Improve startup function") doesn't do what the commit message advertises. The original behaviour was clearing the RX_DIS bit, but due to missing ~, that bit is now the only bit kept. Currently, the regression is harmless, because the previous write to the control register sets it to TXRST | RXRST. Thus the RX_DIS bit is previously cleared. The *RST bits are cleared by the hardware, so this commit does not currently change behaviour, but makes future changes less risky. Link: https://www.spinics.net/lists/linux-serial/msg23157.html Signed-off-by: Helmut Grohne <[email protected]> Fixes: 6e14f7c1f2c2 ("tty: xuartps: Improve startup function") Reviewed-by: Sören Brinkmann <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-06-28drivers/tty: add error handling for pcmcia_loop_configZhouyang Jia1-2/+4
When pcmcia_loop_config fails, the lack of error-handling code may cause unexpected results. This patch adds error-handling code after calling pcmcia_loop_config. Signed-off-by: Zhouyang Jia <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-06-28serial: 8250_omap: Add support for AM654 UART controllerNishanth Menon1-0/+1
AM654 uses a UART controller that is compatible (partially) with existing 8250 UART, however, has a few differences with respect to DMA support and control paths. Introduce a base definition that allows us to build up the differences in follow on patches. Cc: Sekhar Nori <[email protected]> Cc: Vignesh R <[email protected]> Signed-off-by: Nishanth Menon <[email protected]> Acked-by: Tony Lindgren <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-06-28dt-bindings: serial: 8250_omap: Add compatible for AM654 UART controllerNishanth Menon1-0/+1
AM654 uses a UART controller that is only partially compatible with existing 8250 UART. UART DMA integration is substantially different and even a match against standard 8250 or omap4 would result in non-working UART once DMA is enabled by default. Introduce a specific compatible to help build up the differences in follow on patches. Cc: Sekhar Nori <[email protected]> Cc: Vignesh R <[email protected]> Signed-off-by: Nishanth Menon <[email protected]> Acked-by: Rob Herring <[email protected]> Acked-by: Tony Lindgren <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-06-28atomic/tty: Fix up atomic abuse in ldsemPeter Zijlstra2-49/+37
Mark found ldsem_cmpxchg() needed an (atomic_long_t *) cast to keep working after making the atomic_long interface type safe. Needing casts is bad form, which made me look at the code. There are no ld_semaphore::count users outside of these functions so there is no reason why it can not be an atomic_long_t in the first place, obviating the need for this cast. That also ensures the loads use atomic_long_read(), which implies (at least) READ_ONCE() in order to guarantee single-copy-atomic loads. When using atomic_long_try_cmpxchg() the ldsem_cmpxchg() wrapper gets very thin (the only difference is not changing *old on success, which most callers don't seem to care about). So rework the whole thing to use atomic_long_t and its accessors directly. While there, fixup all the horrible comment styles. Cc: Peter Hurley <[email protected]> Reported-by: Mark Rutland <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Acked-by: Mark Rutland <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-06-28tty: serial: exar: generalize RS485 setupDaniel Golle1-13/+25
Move the non-board-specific part of the RS485 initialization from iot2040_rs485_config function to a new generic function used also for other boards. This allows using TIOCGRS485 and TIOCSRS485 on boards (such as mPCIe serial IO modules) which are hard-wired to RS485 or have jumpers for their configurations. Signed-off-by: Daniel Golle <[email protected]> Reviewed-by: Jan Kiszka <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-06-28serdev: add controller runtime PM supportJohan Hovold1-3/+30
Add support for controller runtime power management to serdev core. This is needed to allow slave drivers to manage the runtime PM state of the underlying serial controller when its driver, in turn, implements more aggressive runtime power management (e.g. using autosuspend). For some applications, for example, where loss off initial data after a remote-wakeup event is acceptable or where rx is not used at all, aggressive serial controller runtime PM may be used without further involvement of the slave driver. But when this is not the case, the slave driver must be able to indicate when incoming data is expected in order to avoid data loss. To facilitate the common case, where the serial controller power state is active whenever the port is open (which is the case with just about every serial driver), and where data loss is not acceptable and cannot even be prevented by explicit controller runtime power management, an RPM reference is taken in serdev open and put again at close. This reference can later be balanced by any serdev driver which wants and/or can handle aggressive controller runtime PM. Note that the .ignore_children flag is set for the serdev controller to allow the underlying hardware to idle when no I/O is expected, regardless of the slave device RPM state. Acked-by: Tony Lindgren <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Acked-by: Rob Herring <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-06-28serial: pxa: Fix an error handling path in 'serial_pxa_probe()'Christophe JAILLET1-1/+2
If port.line is out of range, we still need to release some resources, or we will leak them. Fixes: afc7851fab83 ("serial: pxa: Fix out-of-bounds access through serial port index") Signed-off-by: Christophe JAILLET <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-06-28serial: max310x: Check the clock readinessJan Kundrát1-4/+10
This chip has a diagnostics status bit informing about the state and stability of the clock subsystem. According to the datasheet (STSint register, bit 5, ClockReady), this bit works with the crystal oscillator, but even without the PLL. Therefore: - ensure that the clock check is done even when PLL is not active - warn when the chip thinks that the clock is not ready yet There are HW features which would let us wait asynchronously (there's a maskable IRQ for that bit), but I think that even this simple check is a net improvement. It would have saved me two days of debugging :). Signed-off-by: Jan Kundrát <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-06-28tty: use 64-bit timstampArnd Bergmann1-14/+5
The automated VFS conversion to timespec64 has left one caller of the deprecated get_seconds() function in the tty driver, this cleans it up to call ktime_get_real_seconds() instead, fixing the possible overflow. Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-06-28tty: serial: imx: correct dma cookie statusRobin Gong1-1/+1
Correct to check the right rx dma cookie status in spit of it works because only one cookie is running in the current sdma. But it will not once sdma driver support multi cookies running based on virt-dma. Signed-off-by: Robin Gong <[email protected]> Reviewed-by: Sascha Hauer <[email protected]> Acked-by: Uwe Kleine-König <[email protected]> Tested-by: Lucas Stach <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-06-28dt-bindings: serial: imx: clarify rs485 support usageBaruch Siach1-1/+5
The i.MX UART peripheral uses the RST_B signal as input, and CTS_B as output. This is just like the DCE role in RS-232. This is true regardless of the "DTE mode" setting of this peripheral. As a result, rs485 support hardware must use the CTS_B signal to control the RS-485 transceiver. This is in contrast to generic rs485 kernel code, documentation, and DT property names that consistently refer to the RTS as transceiver control signal. Add a note in the DT binding document about that, to reduce the confusion somewhat. Signed-off-by: Baruch Siach <[email protected]> Acked-by: Uwe Kleine-König <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-06-28serial: imx: fix comment about UCR2_SRST and its handling for shadowingUwe Kleine-König1-1/+2
Initially when register shadowing was introduced (commit 3a0ab62f43de ("serial: imx: implement shadow registers for UCRx and UFCR")) the logic to handle UCR2_SRST was wrong but documented consistently. Later the handling was fixed, but the comment was not. This change makes up leeway for the latter. Fixes: 0aa821d846c0 ("serial: imx: fix cached UCR2 read on software reset") Signed-off-by: Uwe Kleine-König <[email protected]> Reviewed-by: Stefan Agner <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-06-28swiotlb: export swiotlb_dma_opsChristoph Hellwig1-0/+1
For architectures that do not use per-device dma ops we need to export the dma_map_ops structure returned from get_arch_dma_ops(). Fixes: 10314e09 ("riscv: add swiotlb support") Signed-off-by: Christoph Hellwig <[email protected]> Reported-by: Andreas Schwab <[email protected]>
2018-06-28Merge tag 'usb-serial-4.18-rc3' of ↵Greg Kroah-Hartman1-0/+14
https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus Johan writes: USB-serial fixes for v4.18-rc3 Here are bunch of new device ids for cp210x. All have been in linux-next with no reported issues. Signed-off-by: Johan Hovold <[email protected]>
2018-06-28Btrfs: fix mount failure when qgroup rescan is in progressFilipe Manana1-3/+10
If a power failure happens while the qgroup rescan kthread is running, the next mount operation will always fail. This is because of a recent regression that makes qgroup_rescan_init() incorrectly return -EINVAL when we are mounting the filesystem (through btrfs_read_qgroup_config()). This causes the -EINVAL error to be returned regardless of any qgroup flags being set instead of returning the error only when neither of the flags BTRFS_QGROUP_STATUS_FLAG_RESCAN nor BTRFS_QGROUP_STATUS_FLAG_ON are set. A test case for fstests follows up soon. Fixes: 9593bf49675e ("btrfs: qgroup: show more meaningful qgroup_rescan_init error message") Signed-off-by: Filipe Manana <[email protected]> Reviewed-by: Qu Wenruo <[email protected]> Signed-off-by: David Sterba <[email protected]>
2018-06-28Btrfs: fix regression in btrfs_page_mkwrite() from vm_fault_t conversionChris Mason1-1/+2
The vm_fault_t conversion commit introduced a ret2 variable for tracking the integer return values from internal btrfs functions. It was sometimes returning VM_FAULT_LOCKED for pages that were actually invalid and had been removed from the radix. Something like this: ret2 = btrfs_delalloc_reserve_space() // returns zero on success lock_page(page) if (page->mapping != inode->i_mapping) goto out_unlock; ... out_unlock: if (!ret2) { ... return VM_FAULT_LOCKED; } This ends up triggering this WARNING in btrfs_destroy_inode() WARN_ON(BTRFS_I(inode)->block_rsv.size); xfstests generic/095 was able to reliably reproduce the errors. Since out_unlock: is only used for errors, this fix moves it below the if (!ret2) check we use to return VM_FAULT_LOCKED for success. Fixes: a528a2415087 (btrfs: change return type of btrfs_page_mkwrite to vm_fault_t) Signed-off-by: Chris Mason <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]>
2018-06-28btrfs: quota: Set rescan progress to (u64)-1 if we hit last leafQu Wenruo1-1/+3
Commit ff3d27a048d9 ("btrfs: qgroup: Finish rescan when hit the last leaf of extent tree") added a new exit for rescan finish. However after finishing quota rescan, we set fs_info->qgroup_rescan_progress to (u64)-1 before we exit through the original exit path. While we missed that assignment of (u64)-1 in the new exit path. The end result is, the quota status item doesn't have the same value. (-1 vs the last bytenr + 1) Although it doesn't affect quota accounting, it's still better to keep the original behavior. Reported-by: Misono Tomohiro <[email protected]> Fixes: ff3d27a048d9 ("btrfs: qgroup: Finish rescan when hit the last leaf of extent tree") Signed-off-by: Qu Wenruo <[email protected]> Reviewed-by: Misono Tomohiro <[email protected]> Signed-off-by: David Sterba <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.