aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
* iio:st_sensors: Fix oops when probing SPI devicesAlban Bedel2018-12-114-2/+3
| | | | | | | | | | | | | | | | | In SPI mode the transfer buffer is locked with a mutex. However this mutex is only initilized after the probe, but some transfer needs to be done in the probe. To fix this bug we move the mutex initialization at the beginning of the device probe. Signed-off-by: Alban Bedel <alban.bedel@avionic-design.de> Acked-by: Denis Ciocca <denis.ciocca@st.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Moyster <oysterized@gmail.com> omitted pressure driver changes (missing in this kernel)
* iio: sensors-core: st: Clean-up error handling in st_sensors_read_axis_data()Lee Jones2018-12-111-5/+3
| | | | | | | Gets rid of those unnecessary gotos. Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio: sensors-core: st: Clean-up error handling in st_sensors_init_sensor()Lee Jones2018-12-111-5/+4
| | | | | | | | | Strip out all those unnecessary gotos and just return the error right away. Aids to simplicity and reduces code. Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio:st_sensors: Use iio_push_to_buffers_with_timestamp()Lars-Peter Clausen2018-12-111-5/+2
| | | | | | | | Makes the code a bit shorter and less ugly. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Cc: Denis Ciocca <denis.ciocca@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio: sensors-core: st: Clean-up error handling in st_sensors_read_info_raw()Lee Jones2018-12-111-7/+4
| | | | | | | Saving a few lines of code. Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio: sensors-core: st: Allow full-scale to be an optional featureLee Jones2018-12-111-4/+7
| | | | | | | | | | | | Some chips either don't support it or fail to provide adequate documentation, so sometimes it's impossible to enable the feature even if it is supported. Signed-off-by: Lee Jones <lee.jones@linaro.org> Acked-by: Denis Ciocca <denis.ciocca@st.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Moyster <oysterized@gmail.com> omitted pressure driver changes (missing in this kernel)
* iio: sensors-core: st: Support sensors which don't have a Data Ready pinLee Jones2018-12-111-11/+22
| | | | | | | | | | | Not all ST's sensors support data ready, so let's make the declaration of one conditional. Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Moyster <oysterized@gmail.com> omitted pressure drive changes (missing in this kernel)
* iio: st_sensors: announce registered sensorsLinus Walleij2018-12-113-0/+9
| | | | | | | | | | | | | | It is pretty helpful to know already from dmesg that a certain device is successfully registered, instead of having to browse sysfs to see if it's actually there. Cc: Lee Jones <lee.jones@linaro.org> Cc: Denis CIOCCA <denis.ciocca@st.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Moyster <oysterized@gmail.com> omitted pressure driver changes (missing in this kernel)
* iio: imu: st_lsm6dsx: fix typo in gyro sensitivity definitionLorenzo Bianconi2018-12-111-3/+3
| | | | | | Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@st.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Moyster <oysterized@gmail.com>
* iio:accel: Register buffer also without specific triggerDenis CIOCCA2018-12-111-9/+8
| | | | | | | This patch fix buffer registration that allows to use generic IIO trigger. Signed-off-by: Denis Ciocca <denis.ciocca@st.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio: accel-core: st: Clean up error handling in probe()Lee Jones2018-12-111-9/+10
| | | | | | | | | Reduce the amount of those unnecessary goto calls, as in most cases we can simply return immediately. We also only call for the IRQ number once and use that value throughout. Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio: accel: st_accel: Use devm_iio_device_allocSachin Kamat2018-12-113-23/+8
| | | | | | | | Using devm_iio_device_alloc makes code simpler. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Cc: Denis Ciocca <denis.ciocca@st.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio: Added ST-sensors platform data to select the DRDY interrupt pinDenis CIOCCA2018-12-1114-33/+106
| | | | | | | | | | | This patch add support to redirect the DRDY interrupt on INT1 or INT2 on accelerometer and pressure sensors. Signed-off-by: Denis Ciocca <denis.ciocca@st.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Moyster <oysterized@gmail.com> omitted pressure drivers changes (missing on this kernel)
* iio:common: Removed stuff macros, added num_data_channels on st_sensors ↵Denis CIOCCA2018-12-116-33/+75
| | | | | | | | | | | | | | struct and added support on one-shot sysfs reads to 3 byte channel This patch introduce num_data_channels variable on st_sensors struct to manage different type of channels (size or number) in st_sensors_get_buffer_element function. Removed ST_SENSORS_NUMBER_DATA_CHANNELS and ST_SENSORS_BYTE_FOR_CHANNEL and used struct iio_chan_spec const *ch to catch data. Added 3 byte channel data support on one-shot reads. Signed-off-by: Denis Ciocca <denis.ciocca@st.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio:common: ST_SENSORS_LSM_CHANNELS macro changedDenis CIOCCA2018-12-114-44/+69
| | | | | Signed-off-by: Denis Ciocca <denis.ciocca@st.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* mm: vmpressure.c mismergeMoyster2018-12-111-1/+1
|
* arm, pm, vmpressure: add missing slab.h includesTejun Heo2018-12-113-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | arch/arm/mach-tegra/pm.c, kernel/power/console.c and mm/vmpressure.c were somehow getting slab.h indirectly through cgroup.h which in turn was getting it indirectly through xattr.h. A scheduled cgroup change drops xattr.h inclusion from cgroup.h and breaks compilation of these three files. Add explicit slab.h includes to the three files. A pending cgroup patch depends on this change and it'd be great if this can be routed through cgroup/for-3.14-fixes branch. Signed-off-by: Tejun Heo <tj@kernel.org> Acked-by: Stephen Warren <swarren@wwwdotorg.org> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: linux-tegra@vger.kernel.org Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: linux-pm@vger.kernel.org Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Michal Hocko <mhocko@suse.cz> Cc: Balbir Singh <bsingharora@gmail.com> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: cgroups@vger.kernel.org Signed-off-by: Joe Maples <joe@frap129.org>
* mm: vmpressure: dynamic window sizing.Martijn Coenen2018-12-113-34/+135
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The window size used for calculating vm pressure events was previously fixed at 512 pages. The window size has a big impact on the rate of notifications sent off to userspace, in particular when using the "low" level. On machines with a lot of memory, the current value is likely excessive. On the other hand, if the window size is too big, we might delay memory pressure events for too long, especially at critical levels of memory pressure. This patch attempts to address that problem with two changes. The first change is to calculate the window size based on the machine size, quite similar to how the vm watermarks are being calculated. This reduces the chance of false positives at any pressure level. Using the machine size only makes sense on the root cgroup though; for non-root cgroups, their hard memory limit is used to calculate the window size. If no hard memory limit is set, we fall back to the default window size that was previously used. The second change is based on an idea from Johannes Weiner, to only report medium and low pressure levels for every X windows that we scan. This reduces the frequency with which we report low/medium pressure levels, but at the same time will still report critical memory pressure immediately. Change-Id: Ieffca055b2fb6aa27ae0179e0a588e6fcb173a61 Signed-off-by: Martijn Coenen <maco@google.com>
* defconfig: regen for sdfat and new ram_consoleMoyster2018-12-021-19/+23
|
* sdfat: merge v2.0.8Moyster2018-12-026-66/+101
|
* fs: sdfat: Add -lineage extraversion to SDFAT_VERSIONPaul Keith2018-12-021-1/+1
| | | | | | | * It has diverged enough to add this to differentiate it Change-Id: I5e43ee01c785acbc5292c6c115a4e083eeeb36a6 Signed-off-by: Paul Keith <javelinanddart@gmail.com>
* fs: sdfat: Add MODULE_ALIAS_FS for supported filesystemsPaul Keith2018-12-021-0/+3
| | | | | | | * This is the proper thing to do for filesystem drivers Change-Id: I109b201d85e324cc0a72c3fcd09df4a3e1703042 Signed-off-by: Paul Keith <javelinanddart@gmail.com>
* fs: sdfat: Add config option to register sdFAT for VFATPaul Keith2018-12-022-0/+52
| | | | | Change-Id: I72ba7a14b56175535884390e8601960b5d8ed1cf Signed-off-by: Paul Keith <javelinanddart@gmail.com>
* fs: sdfat: Add config option to register sdFAT for exFATPaul Keith2018-12-022-1/+32
| | | | | Change-Id: Id57abf0a4bd0b433fecc622eecb383cd4ea29d17 Signed-off-by: Paul Keith <javelinanddart@gmail.com>
* fs: sdfat: Fix compilation for 32-bit targetsPaul Keith2018-12-021-1/+4
| | | | Change-Id: I9a9f3e253001bfbb3a209bd16d2741c95c99f46b
* fs: sdfat: Update to driver version 2.0.6Bruno Martins2018-12-0219-519/+555
| | | | | | * From Samsung package version: G960USQU1ARBG Change-Id: Ia4ba42dbd088701c23c09fbb4ba97a5654e19011
* fs: sdfat: Fix compilation without debuggingPaul Keith2018-12-022-0/+6
| | | | | | | * And make WARNON debugging optional Change-Id: Id59e908c8a60ded1238d3fd010f3d96cdde95f40 Signed-off-by: Paul Keith <javelinanddart@gmail.com>
* fs: sdfat: Fix compilation on Linux 3.4Paul Keith2018-12-021-0/+4
| | | | | Change-Id: I3a500f03f399abc9af9586e80419d75aca5b4320 Signed-off-by: Paul Keith <javelinanddart@gmail.com>
* fs: Import sdFAT driverBruno Martins2018-12-0229-0/+21545
| | | | | | | | * Samsung driver version 1.4.16 * From Samsung package version: G950FXXU1CRAP Change-Id: I0a0f7365d432f0e006ecc6ca0d305008cc44444c
* ext4: avoid running out of journal credits when appending to an inline fileTheodore Ts'o2018-12-023-56/+3
| | | | | | | | | | | | | | | | | | commit 8bc1379b82b8e809eef77a9fedbb75c6c297be19 upstream. Use a separate journal transaction if it turns out that we need to convert an inline file to use an data block. Otherwise we could end up failing due to not having journal credits. This addresses CVE-2018-10883. https://bugzilla.kernel.org/show_bug.cgi?id=200071 Signed-off-by: Theodore Ts'o <tytso@mit.edu> [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Greg Hackmann <ghackmann@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ext4: add more inode number paranoia checksTheodore Ts'o2018-12-023-6/+7
| | | | | | | | | | | | | | | | | | | | commit c37e9e013469521d9adb932d17a1795c139b36db upstream. If there is a directory entry pointing to a system inode (such as a journal inode), complain and declare the file system to be corrupted. Also, if the superblock's first inode number field is too small, refuse to mount the file system. This addresses CVE-2018-10882. https://bugzilla.kernel.org/show_bug.cgi?id=200069 Signed-off-by: Theodore Ts'o <tytso@mit.edu> [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Greg Hackmann <ghackmann@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ext4: never move the system.data xattr out of the inode bodyTheodore Ts'o2018-12-021-0/+5
| | | | | | | | | | | | | | | | | | | commit 8cdb5240ec5928b20490a2bb34cb87e9a5f40226 upstream. When expanding the extra isize space, we must never move the system.data xattr out of the inode body. For performance reasons, it doesn't make any sense, and the inline data implementation assumes that system.data xattr is never in the external xattr block. This addresses CVE-2018-10880 https://bugzilla.kernel.org/show_bug.cgi?id=200005 Signed-off-by: Theodore Ts'o <tytso@mit.edu> [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Greg Hackmann <ghackmann@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ext4: always verify the magic number in xattr blocksTheodore Ts'o2018-12-021-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | commit 513f86d73855ce556ea9522b6bfd79f87356dc3a upstream. If there an inode points to a block which is also some other type of metadata block (such as a block allocation bitmap), the buffer_verified flag can be set when it was validated as that other metadata block type; however, it would make a really terrible external attribute block. The reason why we use the verified flag is to avoid constantly reverifying the block. However, it doesn't take much overhead to make sure the magic number of the xattr block is correct, and this will avoid potential crashes. This addresses CVE-2018-10879. https://bugzilla.kernel.org/show_bug.cgi?id=200001 Signed-off-by: Theodore Ts'o <tytso@mit.edu> Reviewed-by: Andreas Dilger <adilger@dilger.ca> Cc: stable@kernel.org [ghackmann@google.com: 3.18 backport: adjust context] Signed-off-by: Greg Hackmann <ghackmann@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ext4: add corruption check in ext4_xattr_set_entry()Theodore Ts'o2018-12-021-8/+14
| | | | | | | | | | | | | | | | | | | | | | commit 5369a762c882c0b6e9599e4ebbb3a9ba9eee7e2d upstream. In theory this should have been caught earlier when the xattr list was verified, but in case it got missed, it's simple enough to add check to make sure we don't overrun the xattr buffer. This addresses CVE-2018-10879. https://bugzilla.kernel.org/show_bug.cgi?id=200001 Signed-off-by: Theodore Ts'o <tytso@mit.edu> Reviewed-by: Andreas Dilger <adilger@dilger.ca> [bwh: Backported to 3.16: - Add inode parameter to ext4_xattr_set_entry() and update callers - Return -EIO instead of -EFSCORRUPTED on error - Adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Greg Hackmann <ghackmann@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ext4: fix false negatives *and* false positives in ext4_check_descriptors()Theodore Ts'o2018-12-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | commit 44de022c4382541cebdd6de4465d1f4f465ff1dd upstream. Ext4_check_descriptors() was getting called before s_gdb_count was initialized. So for file systems w/o the meta_bg feature, allocation bitmaps could overlap the block group descriptors and ext4 wouldn't notice. For file systems with the meta_bg feature enabled, there was a fencepost error which would cause the ext4_check_descriptors() to incorrectly believe that the block allocation bitmap overlaps with the block group descriptor blocks, and it would reject the mount. Fix both of these problems. Signed-off-by: Theodore Ts'o <tytso@mit.edu> [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Greg Hackmann <ghackmann@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ext4: always check block group bounds in ext4_init_block_bitmap()Theodore Ts'o2018-12-021-7/+3
| | | | | | | | | | | | | | | | commit 819b23f1c501b17b9694325471789e6b5cc2d0d2 upstream. Regardless of whether the flex_bg feature is set, we should always check to make sure the bits we are setting in the block bitmap are within the block group bounds. https://bugzilla.kernel.org/show_bug.cgi?id=199865 Signed-off-by: Theodore Ts'o <tytso@mit.edu> [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Greg Hackmann <ghackmann@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ext4: fix check to prevent initializing reserved inodesTheodore Ts'o2018-12-022-8/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 5012284700775a4e6e3fbe7eac4c543c4874b559 upstream. Commit 8844618d8aa7: "ext4: only look at the bg_flags field if it is valid" will complain if block group zero does not have the EXT4_BG_INODE_ZEROED flag set. Unfortunately, this is not correct, since a freshly created file system has this flag cleared. It gets almost immediately after the file system is mounted read-write --- but the following somewhat unlikely sequence will end up triggering a false positive report of a corrupted file system: mkfs.ext4 /dev/vdc mount -o ro /dev/vdc /vdc mount -o remount,rw /dev/vdc Instead, when initializing the inode table for block group zero, test to make sure that itable_unused count is not too large, since that is the case that will result in some or all of the reserved inodes getting cleared. This fixes the failures reported by Eric Whiteney when running generic/230 and generic/231 in the the nojournal test case. Fixes: 8844618d8aa7 ("ext4: only look at the bg_flags field if it is valid") Reported-by: Eric Whitney <enwlinux@gmail.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu> [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Greg Hackmann <ghackmann@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ext4: only look at the bg_flags field if it is validTheodore Ts'o2018-12-024-6/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 8844618d8aa7a9973e7b527d038a2a589665002c upstream. The bg_flags field in the block group descripts is only valid if the uninit_bg or metadata_csum feature is enabled. We were not consistently looking at this field; fix this. Also block group #0 must never have uninitialized allocation bitmaps, or need to be zeroed, since that's where the root inode, and other special inodes are set up. Check for these conditions and mark the file system as corrupted if they are detected. This addresses CVE-2018-10876. https://bugzilla.kernel.org/show_bug.cgi?id=199403 Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org [bwh: Backported to 3.16: - ext4_read_block_bitmap_nowait() and ext4_read_inode_bitmap() return a pointer (NULL on error) instead of an error code - Open-code sb_rdonly() - Adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> [ghackmann@google.com: forward-port to 3.18: adjust context] Signed-off-by: Greg Hackmann <ghackmann@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* defconfig: build with CONFIG_MAGIC_SYSRQMoyster2018-12-021-1/+1
| | | | fixes : [ 206.299213]<1> (1)[1:init]android_reboot: Failed to open sysrq-trigger.
* sysrq: Emergency Remount R/O in reverse orderAmir Goldstein2018-12-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change fixes a problem where reboot on Android panics the kernel almost every time when file systems are mounted over loop devices. Android reboot command does: - sync - echo u > /proc/sysrq-trigger - syscall_reboot The problem is with sysrq emergency remount R/O trying to remount-ro in wrong order. since /data is re-mounted ro before loop devices, loop device remount-ro fails to flush the journal and panics the kernel: EXT4-fs (loop0): Remounting filesystem read-only EXT4-fs (loop0): previous I/O error to superblock detected loop: Write error at byte offset 0, length 4096. Buffer I/O error on device loop0, logical block 0 lost page write due to I/O error on loop0 Kernel panic - not syncing: EXT4-fs panic from previous error The fix is quite simple. In do_emergency_remount(), use list_for_each_entry_reverse() on sb list instead of list_for_each_entry(). It makes a lot of sense to umount the file systems in reverse order in which they were added to sb list. Change-Id: I4370e39b5873bd16ade5d5f9ddb2704beb02a2bb Signed-off-by: Amir Goldstein <amir@cellrox.com> Acked-by: Oren Laadan <orenl@cellrox.com>
* ext4: don't mark mmp buffer head dirtyLi Dongyang2018-12-021-1/+0
| | | | | | | | | | | | | | | | | | | | commit fe18d649891d813964d3aaeebad873f281627fbc upstream. Marking mmp bh dirty before writing it will make writeback pick up mmp block later and submit a write, we don't want the duplicate write as kmmpd thread should have full control of reading and writing the mmp block. Another reason is we will also have random I/O error on the writeback request when blk integrity is enabled, because kmmpd could modify the content of the mmp block(e.g. setting new seq and time) while the mmp block is under I/O requested by writeback. Signed-off-by: Li Dongyang <dongyangli@ddn.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Reviewed-by: Andreas Dilger <adilger@dilger.ca> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ext4: fix online resize's handling of a too-small final block groupTheodore Ts'o2018-12-021-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | commit f0a459dec5495a3580f8d784555e6f8f3bf7f263 upstream. Avoid growing the file system to an extent so that the last block group is too small to hold all of the metadata that must be stored in the block group. This problem can be triggered with the following reproducer: umount /mnt mke2fs -F -m0 -b 4096 -t ext4 -O resize_inode,^has_journal \ -E resize=1073741824 /tmp/foo.img 128M mount /tmp/foo.img /mnt truncate --size 1708M /tmp/foo.img resize2fs /dev/loop0 295400 umount /mnt e2fsck -fy /tmp/foo.img Reported-by: Torsten Hilbrich <torsten.hilbrich@secunet.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ext4: recalucate superblock checksum after updating free blocks/inodesTheodore Ts'o2018-12-021-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 4274f516d4bc50648a4d97e4f67ecbd7b65cde4a upstream. When mounting the superblock, ext4_fill_super() calculates the free blocks and free inodes and stores them in the superblock. It's not strictly necessary, since we don't use them any more, but it's nice to keep them roughly aligned to reality. Since it's not critical for file system correctness, the code doesn't call ext4_commit_super(). The problem is that it's in ext4_commit_super() that we recalculate the superblock checksum. So if we're not going to call ext4_commit_super(), we need to call ext4_superblock_csum_set() to make sure the superblock checksum is consistent. Most of the time, this doesn't matter, since we end up calling ext4_commit_super() very soon thereafter, and definitely by the time the file system is unmounted. However, it doesn't work in this sequence: mke2fs -Fq -t ext4 /dev/vdc 128M mount /dev/vdc /vdc cp xfstests/git-versions /vdc godown /vdc umount /vdc mount /dev/vdc tune2fs -l /dev/vdc With this commit, the "tune2fs -l" no longer fails. Reported-by: Chengguang Xu <cgxu519@gmx.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ext4: avoid divide by zero fault when deleting corrupted inline directoriesTheodore Ts'o2018-12-022-12/+12
| | | | | | | | | | | | | | | | | | | | | | | commit 4d982e25d0bdc83d8c64e66fdeca0b89240b3b85 upstream. A specially crafted file system can trick empty_inline_dir() into reading past the last valid entry in a inline directory, and then run into the end of xattr marker. This will trigger a divide by zero fault. Fix this by using the size of the inline directory instead of dir->i_size. Also clean up error reporting in __ext4_check_dir_entry so that the message is clearer and more understandable --- and avoids the division by zero trap if the size passed in is zero. (I'm not sure why we coded it that way in the first place; printing offset % size is actually more confusing and less useful.) https://bugzilla.kernel.org/show_bug.cgi?id=200933 Signed-off-by: Theodore Ts'o <tytso@mit.edu> Reported-by: Wen Xu <wen.xu@gatech.edu> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ext4: reset error code in ext4_find_entry in fallbackEric Sandeen2018-12-021-0/+1
| | | | | | | | | | | | | | | | | | commit f39b3f45dbcb0343822cce31ea7636ad66e60bc2 upstream. When ext4_find_entry() falls back to "searching the old fashioned way" due to a corrupt dx dir, it needs to reset the error code to NULL so that the nonstandard ERR_BAD_DX_DIR code isn't returned to userspace. https://bugzilla.kernel.org/show_bug.cgi?id=199947 Reported-by: Anatoly Trosinenko <anatoly.trosinenko@yandex.com> Reviewed-by: Andreas Dilger <adilger@dilger.ca> Signed-off-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ext4: add more mount time checks of the superblockTheodore Ts'o2018-12-021-11/+26
| | | | | | | | | | | | | | | | commit bfe0a5f47ada40d7984de67e59a7d3390b9b9ecc upstream. The kernel's ext4 mount-time checks were more permissive than e2fsprogs's libext2fs checks when opening a file system. The superblock is considered too insane for debugfs or e2fsck to operate on it, the kernel has no business trying to mount it. This will make file system fuzzing tools work harder, but the failure cases that they find will be more useful and be easier to evaluate. Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ext4: clear i_data in ext4_inode_info when removing inline dataTheodore Ts'o2018-12-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 6e8ab72a812396996035a37e5ca4b3b99b5d214b upstream. When converting from an inode from storing the data in-line to a data block, ext4_destroy_inline_data_nolock() was only clearing the on-disk copy of the i_blocks[] array. It was not clearing copy of the i_blocks[] in ext4_inode_info, in i_data[], which is the copy actually used by ext4_map_blocks(). This didn't matter much if we are using extents, since the extents header would be invalid and thus the extents could would re-initialize the extents tree. But if we are using indirect blocks, the previous contents of the i_blocks array will be treated as block numbers, with potentially catastrophic results to the file system integrity and/or user data. This gets worse if the file system is using a 1k block size and s_first_data is zero, but even without this, the file system can get quite badly corrupted. This addresses CVE-2018-10881. https://bugzilla.kernel.org/show_bug.cgi?id=200015 Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ext4: make sure bitmaps and the inode table don't overlap with bg descriptorsTheodore Ts'o2018-12-021-0/+25
| | | | | | | | | | | | | | | commit 77260807d1170a8cf35dbb06e07461a655f67eee upstream. It's really bad when the allocation bitmaps and the inode table overlap with the block group descriptors, since it causes random corruption of the bg descriptors. So we really want to head those off at the pass. https://bugzilla.kernel.org/show_bug.cgi?id=199865 Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ext4: fix fencepost error in check for inode count overflow during resizeJan Kara2018-12-021-1/+1
| | | | | | | | | | | | | | | | | commit 4f2f76f751433908364ccff82f437a57d0e6e9b7 upstream. ext4_resize_fs() has an off-by-one bug when checking whether growing of a filesystem will not overflow inode count. As a result it allows a filesystem with 8192 inodes per group to grow to 64TB which overflows inode count to 0 and makes filesystem unusable. Fix it. Cc: stable@vger.kernel.org Fixes: 3f8a6411fbada1fa482276591e037f3b1adcf55b Reported-by: Jaco Kroon <jaco@uls.co.za> Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Reviewed-by: Andreas Dilger <adilger@dilger.ca> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ext4: update mtime in ext4_punch_hole even if no blocks are releasedLukas Czerner2018-12-021-18/+18
| | | | | | | | | | | | | | | | | commit eee597ac931305eff3d3fd1d61d6aae553bc0984 upstream. Currently in ext4_punch_hole we're going to skip the mtime update if there are no actual blocks to release. However we've actually modified the file by zeroing the partial block so the mtime should be updated. Moreover the sync and datasync handling is skipped as well, which is also wrong. Fix it. Signed-off-by: Lukas Czerner <lczerner@redhat.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Reported-by: Joe Habermann <joe.habermann@quantum.com> Cc: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>