- Jun 12, 2017
-
-
LCPD Auto Merger authored
TI-Feature: ti_linux_base_rt TI-Tree: git@git.ti.com:ti-linux-kernel/ti-linux-kernel.git TI-Branch: ti-linux-4.9.y * 'ti-linux-4.9.y' of git.ti.com:ti-linux-kernel/ti-linux-kernel: HACK: input: touchscreen: edt-ft5x06: fix driver autoprobing Signed-off-by:LCPD Auto Merger <lcpd_integration@list.ti.com>
-
LCPD Auto Merger authored
Merge branch 'audio-display-ti-linux-4.9.y' of git.ti.com:~darrene/ti-linux-kernel/audio-display-linux-feature-tree into ti-linux-4.9.y TI-Feature: audio-display TI-Tree: git@git.ti.com:~darrene/ti-linux-kernel/audio-display-linux-feature-tree.git TI-Branch: audio-display-ti-linux-4.9.y * 'audio-display-ti-linux-4.9.y' of git.ti.com:~darrene/ti-linux-kernel/audio-display-linux-feature-tree: HACK: input: touchscreen: edt-ft5x06: fix driver autoprobing Signed-off-by: -
Felipe Balbi authored
Because with OF we can pass more specific compatible flags (such as edt-ft5306) instead of generic edt-ft5x06, when i2c-core's of_i2c_register_devices() tries to request_module(), it'll request it with a non-existent specific module alias. In order to have this driver autoprobing again, we just need to add missing MODULE_ALIAS() entries to edt-ft5x06 driver. Thanks to Dmitry for noticing that it actually should autoprobe even with of_device_id. This patch is marked as a "HACK" since this is not acceptable upstream and a solution is still being debated here: https://lkml.org/lkml/2015/9/9/422 Signed-off-by:
Felipe Balbi <balbi@ti.com> [fcooper@ti.com: tweaked to add support FT5506] Signed-off-by:
Franklin S Cooper Jr <fcooper@ti.com> Signed-off-by:
Sekhar Nori <nsekhar@ti.com> Signed-off-by:
Jyri Sarha <jsarha@ti.com>
-
- Jun 09, 2017
-
-
LCPD Auto Merger authored
TI-Feature: ti_linux_base_rt TI-Tree: git@git.ti.com:ti-linux-kernel/ti-linux-kernel.git TI-Branch: ti-linux-4.9.y * 'ti-linux-4.9.y' of git.ti.com:ti-linux-kernel/ti-linux-kernel: remoteproc/pruss: update pruss_get() to retrieve a PRUSS id remoteproc/pruss: add instance id to each PRUSS data Signed-off-by: -
git://git.ti.com/rpmsg/rpmsgLCPD Auto Merger authored
TI-Feature: rpmsg TI-Tree: git://git.ti.com/rpmsg/rpmsg.git TI-Branch: rpmsg-ti-linux-4.9.y-intg * 'rpmsg-ti-linux-4.9.y-intg' of git://git.ti.com/rpmsg/rpmsg : remoteproc/pruss: update pruss_get() to retrieve a PRUSS id remoteproc/pruss: add instance id to each PRUSS data Signed-off-by:
-
git://git.ti.com/rpmsg/rpmsgSuman Anna authored
The PRU Ethernet driver is fixed up during the merge to account for the changed function signature during the merge. Signed-off-by:Suman Anna <s-anna@ti.com>
-
- Jun 08, 2017
-
-
git://git.ti.com/rpmsg/remoteprocSuman Anna authored
Pull in the updated remoteproc feature branch that provides an updated PRUSS driver to provide a PRUSS instance id back to the PRU client/user drivers. * 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc : remoteproc/pruss: update pruss_get() to retrieve a PRUSS id remoteproc/pruss: add instance id to each PRUSS data Signed-off-by:
-
LCPD Auto Merger authored
TI-Feature: ti_linux_base_rt TI-Tree: git@git.ti.com:ti-linux-kernel/ti-linux-kernel.git TI-Branch: ti-linux-4.9.y * 'ti-linux-4.9.y' of git.ti.com:ti-linux-kernel/ti-linux-kernel: crypto: omap-sham: Verify page zone of scatterlists before starting DMA Signed-off-by: -
LCPD Auto Merger authored
Merge branch 'platform-ti-linux-4.9.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree into ti-linux-4.9.y TI-Feature: platform_base TI-Tree: git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree.git TI-Branch: platform-ti-linux-4.9.y * 'platform-ti-linux-4.9.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree : crypto: omap-sham: Verify page zone of scatterlists before starting DMA Signed-off-by:
-
Tero Kristo authored
-
Tero Kristo authored
In certain platforms like DRA7xx having memory > 2GB with LPAE enabled has a constraint that DMA can be done with the initial 2GB and marks it as ZONE_DMA. But openssl when used with cryptodev does not make sure that input buffer is DMA capable. So, adding a check to verify if the input buffer is capable of DMA. Signed-off-by:
Tero Kristo <t-kristo@ti.com> Reported-by:
Aparna Balasubramanian <aparnab@ti.com> Reviewed-by:
Lokesh Vutla <lokeshvutla@ti.com>
-
- Jun 07, 2017
-
-
LCPD Auto Merger authored
Merge branch 'linux-4.9.y-rt' of https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel into ti-rt-linux-4.9.y TI-Feature: linux_rt-4-9 TI-Tree: https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git TI-Branch: linux-4.9.y-rt * 'linux-4.9.y-rt' of https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel : v4.9.30-rt21 sched: Remove TASK_ALL sched: Prevent task state corruption by spurious lock wakeup Signed-off-by:
-
LCPD Auto Merger authored
TI-Feature: ti_linux_base_rt TI-Tree: git@git.ti.com:ti-linux-kernel/ti-linux-kernel.git TI-Branch: ti-linux-4.9.y * 'ti-linux-4.9.y' of git.ti.com:ti-linux-kernel/ti-linux-kernel: usb: musb: don't mark of_dev_auxdata as initdata Signed-off-by: -
LCPD Auto Merger authored
Merge branch 'connectivity-ti-linux-4.9.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel into ti-linux-4.9.y TI-Feature: connectivity TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git TI-Branch: connectivity-ti-linux-4.9.y * 'connectivity-ti-linux-4.9.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel : usb: musb: don't mark of_dev_auxdata as initdata Signed-off-by:
-
Arnd Bergmann authored
commit 9f41ebfb upstream. The probe function is not __init since it can be called for deferred probing or when unbinding/rebinding the device, and therefore it must not reference objects in __initdata, as pointed out by this link time warning: WARNING: drivers/usb/musb/da8xx.o(.text+0x9d4): Section mismatch in reference from the function da8xx_probe() to the (unknown reference) .init.data:(unknown) This removes the annotation. Reported-by:
Olof's autobuilder <olof@lixom.net> Fixes: d6299b6e ("usb: musb: Add support of CPPI 4.1 DMA controller to DA8xx") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
LCPD Auto Merger authored
TI-Feature: ti_linux_base_rt TI-Tree: git@git.ti.com:ti-linux-kernel/ti-linux-kernel.git TI-Branch: ti-linux-4.9.y * 'ti-linux-4.9.y' of git.ti.com:ti-linux-kernel/ti-linux-kernel: (94 commits) Linux 4.9.31 xfs: Fix off-by-in in loop termination in xfs_find_get_desired_pgoff() xfs: fix unaligned access in xfs_btree_visit_blocks xfs: avoid mount-time deadlock in CoW extent recovery xfs: xfs_trans_alloc_empty xfs: bad assertion for delalloc an extent that start at i_size xfs: BMAPX shouldn't barf on inline-format directories xfs: fix indlen accounting error on partial delalloc conversion xfs: fix use-after-free in xfs_finish_page_writeback xfs: reserve enough blocks to handle btree splits when remapping xfs: wait on new inodes during quotaoff dquot release xfs: update ag iterator to support wait on new inodes xfs: support ability to wait on new inodes xfs: fix up quotacheck buffer list error handling xfs: prevent multi-fsb dir readahead from reading random blocks xfs: handle array index overrun in xfs_dir2_leaf_readbuf() xfs: fix integer truncation in xfs_bmap_remap_alloc xfs: drop iolock from reclaim context to appease lockdep xfs: actually report xattr extents via iomap xfs: fix over-copying of getbmap parameters from userspace ... Signed-off-by: -
LCPD Auto Merger authored
Merge tag 'v4.9.31' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into ti-linux-4.9.y This is the 4.9.31 stable release * tag 'v4.9.31' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable : (94 commits) Linux 4.9.31 xfs: Fix off-by-in in loop termination in xfs_find_get_desired_pgoff() xfs: fix unaligned access in xfs_btree_visit_blocks xfs: avoid mount-time deadlock in CoW extent recovery xfs: xfs_trans_alloc_empty xfs: bad assertion for delalloc an extent that start at i_size xfs: BMAPX shouldn't barf on inline-format directories xfs: fix indlen accounting error on partial delalloc conversion xfs: fix use-after-free in xfs_finish_page_writeback xfs: reserve enough blocks to handle btree splits when remapping xfs: wait on new inodes during quotaoff dquot release xfs: update ag iterator to support wait on new inodes xfs: support ability to wait on new inodes xfs: fix up quotacheck buffer list error handling xfs: prevent multi-fsb dir readahead from reading random blocks xfs: handle array index overrun in xfs_dir2_leaf_readbuf() xfs: fix integer truncation in xfs_bmap_remap_alloc xfs: drop iolock from reclaim context to appease lockdep xfs: actually report xattr extents via iomap xfs: fix over-copying of getbmap parameters from userspace ... Signed-off-by:
-
Greg Kroah-Hartman authored
-
Jan Kara authored
commit d7fd2425 upstream. There is an off-by-one error in loop termination conditions in xfs_find_get_desired_pgoff() since 'end' may index a page beyond end of desired range if 'endoff' is page aligned. It doesn't have any visible effects but still it is good to fix it. Signed-off-by:
Jan Kara <jack@suse.cz> Reviewed-by:
Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by:
-
Eric Sandeen authored
commit a4d768e7 upstream. This structure copy was throwing unaligned access warnings on sparc64: Kernel unaligned access at TPC[1043c088] xfs_btree_visit_blocks+0x88/0xe0 [xfs] xfs_btree_copy_ptrs does a memcpy, which avoids it. Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Reviewed-by:
-
Darrick J. Wong authored
commit 3ecb3ac7 upstream. If a malicious user corrupts the refcount btree to cause a cycle between different levels of the tree, the next mount attempt will deadlock in the CoW recovery routine while grabbing buffer locks. We can use the ability to re-grab a buffer that was previous locked to a transaction to avoid deadlocks, so do that here. Signed-off-by:
Brian Foster <bfoster@redhat.com> Signed-off-by:
-
Christoph Hellwig authored
This is a partial cherry-pick of commit e89c0413 ("xfs: implement the GETFSMAP ioctl"), which also adds this helper, and a great example of why feature patches should be properly split into their parts. Signed-off-by:
Christoph Hellwig <hch@lst.de>
-
Zorro Lang authored
commit 892d2a5f upstream. By run fsstress long enough time enough in RHEL-7, I find an assertion failure (harder to reproduce on linux-4.11, but problem is still there): XFS: Assertion failed: (iflags & BMV_IF_DELALLOC) != 0, file: fs/xfs/xfs_bmap_util.c The assertion is in xfs_getbmap() funciton: if (map[i].br_startblock == DELAYSTARTBLOCK && --> map[i].br_startoff <= XFS_B_TO_FSB(mp, XFS_ISIZE(ip))) ASSERT((iflags & BMV_IF_DELALLOC) != 0); When map[i].br_startoff == XFS_B_TO_FSB(mp, XFS_ISIZE(ip)), the startoff is just at EOF. But we only need to make sure delalloc extents that are within EOF, not include EOF. Signed-off-by:
Zorro Lang <zlang@redhat.com> Reviewed-by:
-
Darrick J. Wong authored
commit 6eadbf4c upstream. When we're fulfilling a BMAPX request, jump out early if the data fork is in local format. This prevents us from hitting a debugging check in bmapi_read and barfing errors back to userspace. The on-disk extent count check later isn't sufficient for IF_DELALLOC mode because da extents are in memory and not on disk. Signed-off-by:
-
Brian Foster authored
commit 0daaecac upstream. The delalloc -> real block conversion path uses an incorrect calculation in the case where the middle part of a delalloc extent is being converted. This is documented as a rare situation because XFS generally attempts to maximize contiguity by converting as much of a delalloc extent as possible. If this situation does occur, the indlen reservation for the two new delalloc extents left behind by the conversion of the middle range is calculated and compared with the original reservation. If more blocks are required, the delta is allocated from the global block pool. This delta value can be characterized as the difference between the new total requirement (temp + temp2) and the currently available reservation minus those blocks that have already been allocated (startblockval(PREV.br_startblock) - allocated). The problem is that the current code does not account for previously allocated blocks correctly. It subtracts the current allocation count from the (new - old) delta rather than the old indlen reservation. This means that more indlen blocks than have been allocated end up stashed in the remaining extents and free space accounting is broken as a result. Fix up the calculation to subtract the allocated block count from the original extent indlen and thus correctly allocate the reservation delta based on the difference between the new total requirement and the unused blocks from the original reservation. Also remove a bogus assert that contradicts the fact that the new indlen reservation can be larger than the original indlen reservation. Signed-off-by:
-
Eryu Guan authored
commit 161f55ef upstream. Commit 28b783e4 ("xfs: bufferhead chains are invalid after end_page_writeback") fixed one use-after-free issue by pre-calculating the loop conditionals before calling bh->b_end_io() in the end_io processing loop, but it assigned 'next' pointer before checking end offset boundary & breaking the loop, at which point the bh might be freed already, and caused use-after-free. This is caught by KASAN when running fstests generic/127 on sub-page block size XFS. [ 2517.244502] run fstests generic/127 at 2017-04-27 07:30:50 [ 2747.868840] ================================================================== [ 2747.876949] BUG: KASAN: use-after-free in xfs_destroy_ioend+0x3d3/0x4e0 [xfs] at addr ffff8801395ae698 ... [ 2747.918245] Call Trace: [ 2747.920975] dump_stack+0x63/0x84 [ 2747.924673] kasan_object_err+0x21/0x70 [ 2747.928950] kasan_report+0x271/0x530 [ 2747.933064] ? xfs_destroy_ioend+0x3d3/0x4e0 [xfs] [ 2747.938409] ? end_page_writeback+0xce/0x110 [ 2747.943171] __asan_report_load8_noabort+0x19/0x20 [ 2747.948545] xfs_destroy_ioend+0x3d3/0x4e0 [xfs] [ 2747.953724] xfs_end_io+0x1af/0x2b0 [xfs] [ 2747.958197] process_one_work+0x5ff/0x1000 [ 2747.962766] worker_thread+0xe4/0x10e0 [ 2747.966946] kthread+0x2d3/0x3d0 [ 2747.970546] ? process_one_work+0x1000/0x1000 [ 2747.975405] ? kthread_create_on_node+0xc0/0xc0 [ 2747.980457] ? syscall_return_slowpath+0xe6/0x140 [ 2747.985706] ? do_page_fault+0x30/0x80 [ 2747.989887] ret_from_fork+0x2c/0x40 [ 2747.993874] Object at ffff8801395ae690, in cache buffer_head size: 104 [ 2748.001155] Allocated: [ 2748.003782] PID = 8327 [ 2748.006411] save_stack_trace+0x1b/0x20 [ 2748.010688] save_stack+0x46/0xd0 [ 2748.014383] kasan_kmalloc+0xad/0xe0 [ 2748.018370] kasan_slab_alloc+0x12/0x20 [ 2748.022648] kmem_cache_alloc+0xb8/0x1b0 [ 2748.027024] alloc_buffer_head+0x22/0xc0 [ 2748.031399] alloc_page_buffers+0xd1/0x250 [ 2748.035968] create_empty_buffers+0x30/0x410 [ 2748.040730] create_page_buffers+0x120/0x1b0 [ 2748.045493] __block_write_begin_int+0x17a/0x1800 [ 2748.050740] iomap_write_begin+0x100/0x2f0 [ 2748.055308] iomap_zero_range_actor+0x253/0x5c0 [ 2748.060362] iomap_apply+0x157/0x270 [ 2748.064347] iomap_zero_range+0x5a/0x80 [ 2748.068624] iomap_truncate_page+0x6b/0xa0 [ 2748.073227] xfs_setattr_size+0x1f7/0xa10 [xfs] [ 2748.078312] xfs_vn_setattr_size+0x68/0x140 [xfs] [ 2748.083589] xfs_file_fallocate+0x4ac/0x820 [xfs] [ 2748.088838] vfs_fallocate+0x2cf/0x780 [ 2748.093021] SyS_fallocate+0x48/0x80 [ 2748.097006] do_syscall_64+0x18a/0x430 [ 2748.101186] return_from_SYSCALL_64+0x0/0x6a [ 2748.105948] Freed: [ 2748.108189] PID = 8327 [ 2748.110816] save_stack_trace+0x1b/0x20 [ 2748.115093] save_stack+0x46/0xd0 [ 2748.118788] kasan_slab_free+0x73/0xc0 [ 2748.122969] kmem_cache_free+0x7a/0x200 [ 2748.127247] free_buffer_head+0x41/0x80 [ 2748.131524] try_to_free_buffers+0x178/0x250 [ 2748.136316] xfs_vm_releasepage+0x2e9/0x3d0 [xfs] [ 2748.141563] try_to_release_page+0x100/0x180 [ 2748.146325] invalidate_inode_pages2_range+0x7da/0xcf0 [ 2748.152087] xfs_shift_file_space+0x37d/0x6e0 [xfs] [ 2748.157557] xfs_collapse_file_space+0x49/0x120 [xfs] [ 2748.163223] xfs_file_fallocate+0x2a7/0x820 [xfs] [ 2748.168462] vfs_fallocate+0x2cf/0x780 [ 2748.172642] SyS_fallocate+0x48/0x80 [ 2748.176629] do_syscall_64+0x18a/0x430 [ 2748.180810] return_from_SYSCALL_64+0x0/0x6a Fixed it by checking on offset against end & breaking out first, dereference bh only if there're still bufferheads to process. Signed-off-by:
Eryu Guan <eguan@redhat.com> Reviewed-by:
-
Darrick J. Wong authored
commit fe0be23e upstream. In xfs_reflink_end_cow, we erroneously reserve only enough blocks to handle adding 1 extent. This is problematic if we fragment free space, have to do CoW, and then have to perform multiple bmap btree expansions. Furthermore, the BUI recovery routine doesn't reserve /any/ blocks to handle btree splits, so log recovery fails after our first error causes the filesystem to go down. Therefore, refactor the transaction block reservation macros until we have a macro that works for our deferred (re)mapping activities, and fix both problems by using that macro. With 1k blocks we can hit this fairly often in g/187 if the scratch fs is big enough. Signed-off-by:
-
Brian Foster authored
commit e20c8a51 upstream. The quotaoff operation has a race with inode allocation that results in a livelock. An inode allocation that occurs before the quota status flags are updated acquires the appropriate dquots for the inode via xfs_qm_vop_dqalloc(). It then inserts the XFS_INEW inode into the perag radix tree, sometime later attaches the dquots to the inode and finally clears the XFS_INEW flag. Quotaoff expects to release the dquots from all inodes in the filesystem via xfs_qm_dqrele_all_inodes(). This invokes the AG inode iterator, which skips inodes in the XFS_INEW state because they are not fully constructed. If the scan occurs after dquots have been attached to an inode, but before XFS_INEW is cleared, the newly allocated inode will continue to hold a reference to the applicable dquots. When quotaoff invokes xfs_qm_dqpurge_all(), the reference count of those dquot(s) remain elevated and the dqpurge scan spins indefinitely. To address this problem, update the xfs_qm_dqrele_all_inodes() scan to wait on inodes marked on the XFS_INEW state. We wait on the inodes explicitly rather than skip and retry to avoid continuous retry loops due to a parallel inode allocation workload. Since quotaoff updates the quota state flags and uses a synchronous transaction before the dqrele scan, and dquots are attached to inodes after radix tree insertion iff quota is enabled, one INEW waiting pass through the AG guarantees that the scan has processed all inodes that could possibly hold dquot references. Reported-by:
-
Brian Foster authored
commit ae2c4ac2 upstream. The AG inode iterator currently skips new inodes as such inodes are inserted into the inode radix tree before they are fully constructed. Certain contexts require the ability to wait on the construction of new inodes, however. The fs-wide dquot release from the quotaoff sequence is an example of this. Update the AG inode iterator to support the ability to wait on inodes flagged with XFS_INEW upon request. Create a new xfs_inode_ag_iterator_flags() interface and support a set of iteration flags to modify the iteration behavior. When the XFS_AGITER_INEW_WAIT flag is set, include XFS_INEW flags in the radix tree inode lookup and wait on them before the callback is executed. Signed-off-by:
-
Brian Foster authored
commit 756baca2 upstream. Inodes that are inserted into the perag tree but still under construction are flagged with the XFS_INEW bit. Most contexts either skip such inodes when they are encountered or have the ability to handle them. The runtime quotaoff sequence introduces a context that must wait for construction of such inodes to correctly ensure that all dquots in the fs are released. In anticipation of this, support the ability to wait on new inodes. Wake the appropriate bit when XFS_INEW is cleared. Signed-off-by:
-
Brian Foster authored
commit 20e8a063 upstream. The quotacheck error handling of the delwri buffer list assumes the resident buffers are locked and doesn't clear the _XBF_DELWRI_Q flag on the buffers that are dequeued. This can lead to assert failures on buffer release and possibly other locking problems. Move this code to a delwri queue cancel helper function to encapsulate the logic required to properly release buffers from a delwri queue. Update the helper to clear the delwri queue flag and call it from quotacheck. Signed-off-by:
-
Brian Foster authored
commit cb52ee33 upstream. Directory block readahead uses a complex iteration mechanism to map between high-level directory blocks and underlying physical extents. This mechanism attempts to traverse the higher-level dir blocks in a manner that handles multi-fsb directory blocks and simultaneously maintains a reference to the corresponding physical blocks. This logic doesn't handle certain (discontiguous) physical extent layouts correctly with multi-fsb directory blocks. For example, consider the case of a 4k FSB filesystem with a 2 FSB (8k) directory block size and a directory with the following extent layout: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..7]: 88..95 0 (88..95) 8 1: [8..15]: 80..87 0 (80..87) 8 2: [16..39]: 168..191 0 (168..191) 24 3: [40..63]: 5242952..5242975 1 (72..95) 24 Directory block 0 spans physical extents 0 and 1, dirblk 1 lies entirely within extent 2 and dirblk 2 spans extents 2 and 3. Because extent 2 is larger than the directory block size, the readahead code erroneously assumes the block is contiguous and issues a readahead based on the physical mapping of the first fsb of the dirblk. This results in read verifier failure and a spurious corruption or crc failure, depending on the filesystem format. Further, the subsequent readahead code responsible for walking through the physical table doesn't correctly advance the physical block reference for dirblk 2. Instead of advancing two physical filesystem blocks, the first iteration of the loop advances 1 block (correctly), but the subsequent iteration advances 2 more physical blocks because the next physical extent (extent 3, above) happens to cover more than dirblk 2. At this point, the higher-level directory block walking is completely off the rails of the actual physical layout of the directory for the respective mapping table. Update the contiguous dirblock logic to consider the current offset in the physical extent to avoid issuing directory readahead to unrelated blocks. Also, update the mapping table advancing code to consider the current offset within the current dirblock to avoid advancing the mapping reference too far beyond the dirblock. Signed-off-by:
-
Eric Sandeen authored
commit 023cc840 upstream. Carlos had a case where "find" seemed to start spinning forever and never return. This was on a filesystem with non-default multi-fsb (8k) directory blocks, and a fragmented directory with extents like this: 0:[0,133646,2,0] 1:[2,195888,1,0] 2:[3,195890,1,0] 3:[4,195892,1,0] 4:[5,195894,1,0] 5:[6,195896,1,0] 6:[7,195898,1,0] 7:[8,195900,1,0] 8:[9,195902,1,0] 9:[10,195908,1,0] 10:[11,195910,1,0] 11:[12,195912,1,0] 12:[13,195914,1,0] ... i.e. the first extent is a contiguous 2-fsb dir block, but after that it is fragmented into 1 block extents. At the top of the readdir path, we allocate a mapping array which (for this filesystem geometry) can hold 10 extents; see the assignment to map_info->map_size. During readdir, we are therefore able to map extents 0 through 9 above into the array for readahead purposes. If we count by 2, we see that the last mapped index (9) is the first block of a 2-fsb directory block. At the end of xfs_dir2_leaf_readbuf() we have 2 loops to fill more readahead; the outer loop assumes one full dir block is processed each loop iteration, and an inner loop that ensures that this is so by advancing to the next extent until a full directory block is mapped. The problem is that this inner loop may step past the last extent in the mapping array as it tries to reach the end of the directory block. This will read garbage for the extent length, and as a result the loop control variable 'j' may become corrupted and never fail the loop conditional. The number of valid mappings we have in our array is stored in map->map_valid, so stop this inner loop based on that limit. There is an ASSERT at the top of the outer loop for this same condition, but we never made it out of the inner loop, so the ASSERT never fired. Huge appreciation for Carlos for debugging and isolating the problem. Debugged-and-analyzed-by:
Carlos Maiolino <cmaiolino@redhat.com> Signed-off-by:
Bill O'Donnell <billodo@redhat.com> Reviewed-by:
-
Christoph Hellwig authored
commit 52813fb1 upstream. bno should be a xfs_fsblock_t, which is 64-bit wides instead of a xfs_aglock_t, which truncates the value to 32 bits. Signed-off-by:
-
Brian Foster authored
commit 3b4683c2 upstream. Lockdep complains about use of the iolock in inode reclaim context because it doesn't understand that reclaim has the last reference to the inode, and thus an iolock->reclaim->iolock deadlock is not possible. The iolock is technically not necessary in xfs_inactive() and was only added to appease an assert in xfs_free_eofblocks(), which can be called from other non-reclaim contexts. Therefore, just kill the assert and drop the use of the iolock from reclaim context to quiet lockdep. Signed-off-by:
-
Darrick J. Wong authored
commit 84358536 upstream. Apparently FIEMAP for xattrs has been broken since we switched to the iomap backend because of an incorrect check for xattr presence. Also fix the broken locking. Signed-off-by:
-
Darrick J. Wong authored
commit be6324c0 upstream. In xfs_ioc_getbmap, we should only copy the fields of struct getbmap from userspace, or else we end up copying random stack contents into the kernel. struct getbmap is a strict subset of getbmapx, so a partial structure copy should work fine. Signed-off-by:
-
Brian Foster authored
commit 696a5620 upstream. The log covering background task used to be part of the xfssyncd workqueue. That workqueue was removed as of commit 5889608d ("xfs: syncd workqueue is no more") and the associated work item scheduled to the xfs-log wq. The latter is used for log buffer I/O completion. Since xfs_log_worker() can invoke a log flush, a deadlock is possible between the xfs-log and xfs-cil workqueues. Consider the following codepath from xfs_log_worker(): xfs_log_worker() xfs_log_force() _xfs_log_force() xlog_cil_force() xlog_cil_force_lsn() xlog_cil_push_now() flush_work() The above is in xfs-log wq context and blocked waiting on the completion of an xfs-cil work item. Concurrently, the cil push in progress can end up blocked here: xlog_cil_push_work() xlog_cil_push() xlog_write() xlog_state_get_iclog_space() xlog_wait(&log->l_flush_wait, ...) The above is in xfs-cil context waiting on log buffer I/O completion, which executes in xfs-log wq context. In this scenario both workqueues are deadlocked waiting on eachother. Add a new workqueue specifically for the high level log covering and ail pushing worker, as was the case prior to commit 5889608d. Diagnosed-by:
David Jeffery <djeffery@redhat.com> Signed-off-by:
-
Darrick J. Wong authored
commit bf9216f9 upstream. Fix a memory exposure problems in inumbers where we allocate an array of structures with holes, fail to zero the holes, then blindly copy the kernel memory contents (junk and all) into userspace. Signed-off-by:
-
Darrick J. Wong authored
commit 78420281 upstream. The inline directory verifiers should be called on the inode fork data, which means after iformat_local on the read side, and prior to ifork_flush on the write side. This makes the fork verifier more consistent with the way buffer verifiers work -- i.e. they will operate on the memory buffer that the code will be reading and writing directly. Furthermore, revise the verifier function to return -EFSCORRUPTED so that we don't flood the logs with corruption messages and assert notices. This has been a particular problem with xfs/348, which triggers the XFS_WANT_CORRUPTED_RETURN assertions, which halts the kernel when CONFIG_XFS_DEBUG=y. Disk corruption isn't supposed to do that, at least not in a verifier. Reviewed-by:
-
