- 17 May, 2015 13 commits
-
-
Tejun Heo authored
commit 464d1387 upstream. mm/page-writeback.c has several places where 1 is added to the divisor to prevent division by zero exceptions; however, if the original divisor is equivalent to -1, adding 1 leads to division by zero. There are three places where +1 is used for this purpose - one in pos_ratio_polynom() and two in bdi_position_ratio(). The second one in bdi_position_ratio() actually triggered div-by-zero oops on a machine running a 3.10 kernel. The divisor is x_intercept - bdi_setpoint + 1 == span + 1 span is confirmed to be (u32)-1. It isn't clear how it ended up that but it could be from write bandwidth calculation underflow fixed by c72efb65 ("writeback: fix possible underflow in write bandwidth calculation"). At any rate, +1 isn't a proper protection against div-by-zero. This patch converts all +1 protections to |1. Note that bdi_update_dirty_ratelimit() was already using |1 before this patch. Signed-off-by:
Tejun Heo <tj@kernel.org> Reviewed-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Al Viro authored
commit f15133df upstream. path_openat() jumps to the wrong place after do_tmpfile() - it has already done path_cleanup() (as part of path_lookupat() called by do_tmpfile()), so doing that again can lead to double fput(). Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Naoya Horiguchi authored
commit 09789e5d upstream. Currently memory_failure() calls shake_page() to sweep pages out from pcplists only when the victim page is 4kB LRU page or thp head page. But we should do this for a thp tail page too. Consider that a memory error hits a thp tail page whose head page is on a pcplist when memory_failure() runs. Then, the current kernel skips shake_pages() part, so hwpoison_user_mappings() returns without calling split_huge_page() nor try_to_unmap() because PageLRU of the thp head is still cleared due to the skip of shake_page(). As a result, me_huge_page() runs for the thp, which is broken behavior. One effect is a leak of the thp. And another is to fail to isolate the memory error, so later access to the error address causes another MCE, which kills the processes which used the thp. This patch fixes this problem by calling shake_page() for thp tail case. Fixes: 385de357 ("thp: allow a hwpoisoned head page to be put back to LRU") Signed-off-by:
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Reviewed-by:
Andi Kleen <ak@linux.intel.com> Acked-by:
Dean Nelson <dnelson@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Cc: Jin Dongming <jin.dongming@np.css.fujitsu.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Eric W. Biederman authored
commit 7e96c1b0 upstream. This fixes a dumb bug in fs_fully_visible that allows proc or sys to be mounted if there is a bind mount of part of /proc/ or /sys/ visible. Reported-by:
Eric Windisch <ewindisch@docker.com> Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
Johan Hovold authored
commit 483d8211 upstream. Unregister GPIOs requested through sysfs at chip remove to avoid leaking the associated memory and sysfs entries. The stale sysfs entries prevented the gpio numbers from being exported when the gpio range was later reused (e.g. at device reconnect). This also fixes the related module-reference leak. Note that kernfs makes sure that any on-going sysfs operations finish before the class devices are unregistered and that further accesses fail. The chip exported flag is used to prevent gpiod exports during removal. This also makes it harder to trigger, but does not fix, the related race between gpiochip_remove and export_store, which is really a race with gpiod_request that needs to be addressed separately. Also note that this would prevent the crashes (e.g. NULL-dereferences) at reconnect that affects pre-3.18 kernels, as well as use-after-free on operations on open attribute files on pre-3.14 kernels (prior to kernfs). Fixes: d8f388d8 ("gpio: sysfs interface") Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Jason Gunthorpe authored
commit 28521440 upstream. When accepting a new IPv4 connect to an IPv6 socket, the CMA tries to canonize the address family to IPv4, but does not properly process the listening sockaddr to get the listening port, and does not properly set the address family of the canonized sockaddr. Fixes: e51060f0 ("IB: IP address based RDMA connection manager") Reported-By:
Yotam Kenneth <yotamke@mellanox.com> Signed-off-by:
Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Tested-by:
Haggai Eran <haggaie@mellanox.com> Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Ryusuke Konishi authored
commit d8fd150f upstream. The range check for b-tree level parameter in nilfs_btree_root_broken() is wrong; it accepts the case of "level == NILFS_BTREE_LEVEL_MAX" even though the level is limited to values in the range of 0 to (NILFS_BTREE_LEVEL_MAX - 1). Since the level parameter is read from storage device and used to index nilfs_btree_path array whose element count is NILFS_BTREE_LEVEL_MAX, it can cause memory overrun during btree operations if the boundary value is set to the level parameter on device. This fixes the broken sanity check and adds a comment to clarify that the upper bound NILFS_BTREE_LEVEL_MAX is exclusive. Signed-off-by:
Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp> Signed-off-by:
-
Gregory CLEMENT authored
commit 489405fe upstream. While setting the time, the RTC TIME register should not be accessed. However due to hardware constraints, setting the RTC time involves sleeping during 100ms. This sleep was done outside the critical section protected by the spinlock, so it was possible to read the RTC TIME register and get an incorrect value. This patch introduces a mutex for protecting the RTC TIME access, unlike the spinlock it is allowed to sleep in a critical section protected by a mutex. The RTC STATUS register can still be used from the interrupt handler but it has no effect on setting the time. Signed-off-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Acked-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Acked-by:
Andrew Lunn <andrew@lunn.ch> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
-
Junxiao Bi authored
commit b1432a2a upstream. There is a race window in dlm_get_lock_resource(), which may return a lock resource which has been purged. This will cause the process to hang forever in dlmlock() as the ast msg can't be handled due to its lock resource not existing. dlm_get_lock_resource { ... spin_lock(&dlm->spinlock); tmpres = __dlm_lookup_lockres_full(dlm, lockid, namelen, hash); if (tmpres) { spin_unlock(&dlm->spinlock); >>>>>>>> race window, dlm_run_purge_list() may run and purge the lock resource spin_lock(&tmpres->spinlock); ... spin_unlock(&tmpres->spinlock); } } Signed-off-by:
Junxiao Bi <junxiao.bi@oracle.com> Cc: Joseph Qi <joseph.qi@huawei.com> Cc: Mark Fasheh <mfasheh@suse.com> Cc: Joel Becker <jlbec@evilplan.org> Signed-off-by:
-
Witold Szczeponik authored
commit 622532bb upstream. Commit eec15edb (ACPI / PNP: use device ID list for PNPACPI device enumeration) changed the way how ACPI devices are enumerated and when they are added to the PNP bus. However, it broke the sound card support on (at least) a vintage IBM ThinkPad 600E: with said commit applied, two of the necessary "CSC01xx" devices are not added to the PNP bus and hence can not be found during the initialization of the "snd-cs4236" module. As a consequence, loading "snd-cs4236" causes null pointer exceptions. The attached patch fixes the problem end re-enables sound on the IBM ThinkPad 600E. Fixes: eec15edb (ACPI / PNP: use device ID list for PNPACPI device enumeration) Signed-off-by:
Witold Szczeponik <Witold.Szczeponik@gmx.net> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Jiang Liu authored
commit 2c62e849 upstream. An IO port or MMIO resource assigned to a PCI host bridge may be consumed by the host bridge itself or available to its child bus/devices. The ACPI specification defines a bit (Producer/Consumer) to tell whether the resource is consumed by the host bridge itself, but firmware hasn't used that bit consistently, so we can't rely on it. Before commit 593669c2 ("x86/PCI/ACPI: Use common ACPI resource interfaces to simplify implementation"), arch/x86/pci/acpi.c ignored all IO port resources defined by acpi_resource_io and acpi_resource_fixed_io to filter out IO ports consumed by the host bridge itself. Commit 593669c2 ("x86/PCI/ACPI: Use common ACPI resource interfaces to simplify implementation") started accepting all IO port and MMIO resources, which caused a regression that IO port resources consumed by the host bridge itself became available to its child devices. Then commit 63f1789e ("x86/PCI/ACPI: Ignore resources consumed by host bridge itself") ignored resources consumed by the host bridge itself by checking the IORESOURCE_WINDOW flag, which accidently removed MMIO resources defined by acpi_resource_memory24, acpi_resource_memory32 and acpi_resource_fixed_memory32. On x86 and IA64 platforms, all IO port and MMIO resources are assumed to be available to child bus/devices except one special case: IO port [0xCF8-0xCFF] is consumed by the host bridge itself to access PCI configuration space. So explicitly filter out PCI CFG IO ports[0xCF8-0xCFF]. This solution will also ease the way to consolidate ACPI PCI host bridge common code from x86, ia64 and ARM64. Related ACPI table are archived at: https://bugzilla.kernel.org/show_bug.cgi?id=94221 Related discussions at: http://patchwork.ozlabs.org/patch/461633/ https://lkml.org/lkml/2015/3/29/304 Fixes: 63f1789e (Ignore resources consumed by host bridge itself) Reported-by:
Bernhard Thaler <bernhard.thaler@wvnet.at> Signed-off-by:
Jiang Liu <jiang.liu@linux.intel.com> Reviewed-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Chris Bainbridge authored
commit 3349fb64 upstream. Commit 7bc5a2ba 'ACPI: Support _OSI("Darwin") correctly' caused the MacBook firmware to expose the SBS, resulting in intermittent hangs of several minutes on boot, and failure to detect or report the battery. Fix this by adding a 5 us delay to the start of each SMBUS transaction. This timing is the result of experimentation - hangs were observed with 3 us but never with 5 us. Fixes: 7bc5a2ba 'ACPI: Support _OSI("Darwin") correctly' Link: https://bugzilla.kernel.org/show_bug.cgi?id=94651Signed-off-by:
Chris Bainbridge <chris.bainbridge@gmail.com> Cc: 3.18+ <stable@vger.kernel.org> # 3.18+ [ rjw: Subject and changelog ] Signed-off-by:
-
Tahsin Erdogan authored
commit e8a4a269 upstream. A spinlock is regarded as contended when there is at least one waiter. Currently, the code that checks whether there are any waiters rely on tail value being greater than head. However, this is not true if tail reaches the max value and wraps back to zero, so arch_spin_is_contended() incorrectly returns 0 (not contended) when tail is smaller than head. The original code (before regression) handled this case by casting the (tail - head) to an unsigned value. This change simply restores that behavior. Fixes: d6abfdb2 ("x86/spinlocks/paravirt: Fix memory corruption on unlock") Signed-off-by:
Tahsin Erdogan <tahsin@google.com> Cc: peterz@infradead.org Cc: Waiman.Long@hp.com Cc: borntraeger@de.ibm.com Cc: oleg@redhat.com Cc: raghavendra.kt@linux.vnet.ibm.com Link: http://lkml.kernel.org/r/1430799331-20445-1-git-send-email-tahsin@google.comSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
- 13 May, 2015 27 commits
-
-
Greg Kroah-Hartman authored
-
K. Y. Srinivasan authored
commit 73cffdb6 upstream. Don't wait after sending request for offers to the host. This wait is unnecessary and simply adds 5 seconds to the boot time. Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Thomas Hebb authored
commit db579e76 upstream. On Mac OS X, HFS+ extended attributes are not namespaced. Since we want to be compatible with OS X filesystems and yet still support the Linux namespacing system, the hfsplus driver implements a special "osx" namespace that is reported for any attribute that is not namespaced on-disk. However, the current code for getting and setting these unprefixed attributes is broken. hfsplus_osx_setattr() and hfsplus_osx_getattr() are passed names that have already had their "osx." prefixes stripped by the generic functions. The functions first, quite correctly, check those names to make sure that they aren't prefixed with a known namespace, which would allow namespace access restrictions to be bypassed. However, the functions then prepend "osx." to the name they're given before passing it on to hfsplus_getattr() and hfsplus_setattr(). Not only does this cause the "osx." prefix to be stored on-disk, defeating its purpose, it also breaks the check for the special "com.apple.FinderInfo" attribute, which is reported for all files, and as a consequence makes some userspace applications (e.g. GNU patch) fail even when extended attributes are not otherwise in use. There are five commits which have touched this particular code: 127e5f5a ("hfsplus: rework functionality of getting, setting and deleting of extended attributes") b168fff7 ("hfsplus: use xattr handlers for removexattr") bf29e886 ("hfsplus: correct usage of HFSPLUS_ATTR_MAX_STRLEN for non-English attributes") fcacbd95e121 ("fs/hfsplus: move xattr_name allocation in hfsplus_getxattr()") ec1bbd346f18 ("fs/hfsplus: move xattr_name allocation in hfsplus_setxattr()") The first commit creates the functions to begin with. The namespace is prepended by the original code, which I believe was correct at the time, since hfsplus_?etattr() stripped the prefix if found. The second commit removes this behavior from hfsplus_?etattr() and appears to have been intended to also remove the prefixing from hfsplus_osx_?etattr(). However, what it actually does is remove a necessary strncpy() call completely, breaking the osx namespace entirely. The third commit re-adds the strncpy() call as it was originally, but doesn't mention it in its commit message. The final two commits refactor the code and don't affect its functionality. This commit does what b168fff7 attempted to do (prevent the prefix from being added), but does it properly, instead of passing in an empty buffer (which is what b168fff7 actually did). Fixes: b168fff7 ("hfsplus: use xattr handlers for removexattr") Signed-off-by:
Thomas Hebb <tommyhebb@gmail.com> Cc: Hin-Tak Leung <htl10@users.sourceforge.net> Cc: Sergei Antonov <saproj@gmail.com> Cc: Anton Altaparmakov <anton@tuxera.com> Cc: Fabian Frederick <fabf@skynet.be> Cc: Christian Kujau <lists@nerdbynature.de> Cc: Christoph Hellwig <hch@infradead.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Viacheslav Dubeyko <slava@dubeyko.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Christian König authored
commit c29c0876 upstream. Otherwise the change isn't atomic. Signed-off-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Christian König authored
commit 48afbd70 upstream. Otherwise it is possible that we will have page table corruption if we change a BOs address multiple times. Signed-off-by:
-
Christian König authored
commit 26d4d129 upstream. If we unmap BOs before releasing them them the intervall tree locks up because we try to remove an entry not inside the tree. Based on a patch from Michel Dänzer. Signed-off-by:
-
Alex Deucher authored
commit cd17e02f upstream. Seems to have problems with high mclks. bug: https://bugs.freedesktop.org/show_bug.cgi?id=76490Signed-off-by:
-
Alex Deucher authored
commit 7fe04d6f upstream. Fixes display problems with some monitors when audio is not enabled. Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=89505 https://bugzilla.kernel.org/show_bug.cgi?id=94171 Plus several reports on IRC. Signed-off-by:
-
Michel Dänzer authored
commit b421ed15 upstream. The number of relocs is passed in by userspace and can be large. It has been observed to cause kcalloc failures in the wild. Reviewed-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
-
Alex Deucher authored
commit 38aef154 upstream. Selectively enable which packets we send based on monitor caps. Signed-off-by:
-
Alex Deucher authored
commit 0f55db36 upstream. Otherwise the driver may try and send audio which may confuse the monitor. v2: set pin to NULL if no audio v3: avoid crash with analog encoders Signed-off-by:
-
Alex Deucher authored
commit 362ff251 upstream. Don't enable the audio and avi infoframes and audio stream until all the state is set up. Signed-off-by:
-
Alex Deucher authored
commit 12428327 upstream. It's mostly duplicated with evergreen_dp_enable. This is a prerequisite for fix implemented in another patch. Signed-off-by:
-
Alex Deucher authored
commit 304f07e9 upstream. Set the line first, then enable the stream. May fix pink line problems on some displays. Signed-off-by:
-
Christoph Hellwig authored
commit 579d69bc upstream. The 3w-sas driver needs to tear down the dma mappings before returning the command to the midlayer, as there is no guarantee the sglist and count are valid after that point. Also remove the dma mapping helpers which have another inherent race due to the request_id index. Signed-off-by:
Christoph Hellwig <hch@lst.de> Reported-by:
Torsten Luettgert <ml-lkml@enda.eu> Tested-by:
Bernd Kardatzki <Bernd.Kardatzki@med.uni-tuebingen.de> Acked-by:
Adam Radford <aradford@gmail.com> Signed-off-by:
James Bottomley <JBottomley@Odin.com> Signed-off-by:
-
Christoph Hellwig authored
commit 118c855b upstream. The 3w-9xxx driver needs to tear down the dma mappings before returning the command to the midlayer, as there is no guarantee the sglist and count are valid after that point. Also remove the dma mapping helpers which have another inherent race due to the request_id index. Signed-off-by:
-
Christoph Hellwig authored
commit 9cd95546 upstream. The 3w-xxxx driver needs to tear down the dma mappings before returning the command to the midlayer, as there is no guarantee the sglist and count are valid after that point. Also remove the dma mapping helpers which have another inherent race due to the request_id index. Signed-off-by:
-
Mike Christie authored
commit 35e9a9f9 upstream. This works around a issue with qnap iscsi targets not handling large IOs very well. The target returns: VPD INQUIRY: Block limits page (SBC) Maximum compare and write length: 1 blocks Optimal transfer length granularity: 1 blocks Maximum transfer length: 4294967295 blocks Optimal transfer length: 4294967295 blocks Maximum prefetch, xdread, xdwrite transfer length: 0 blocks Maximum unmap LBA count: 8388607 Maximum unmap block descriptor count: 1 Optimal unmap granularity: 16383 Unmap granularity alignment valid: 0 Unmap granularity alignment: 0 Maximum write same length: 0xffffffff blocks Maximum atomic transfer length: 0 Atomic alignment: 0 Atomic transfer length granularity: 0 and it is *sometimes* able to handle at least one IO of size up to 8 MB. We have seen in traces where it will sometimes work, but other times it looks like it fails and it looks like it returns failures if we send multiple large IOs sometimes. Also it looks like it can return 2 different errors. It will sometimes send iscsi reject errors indicating out of resources or it will send invalid cdb illegal requests check conditions. And then when it sends iscsi rejects it does not seem to handle retries when there are command sequence holes, so I could not just add code to try and gracefully handle that error code. The problem is that we do not have a good contact for the company, so we are not able to determine under what conditions it returns which error and why it sometimes works. So, this patch just adds a new black list flag to set targets like this to the old max safe sectors of 1024. The max_hw_sectors changes added in 3.19 caused this regression, so I also ccing stable. Reported-by:
Christian Hesse <list@eworm.de> Signed-off-by:
Mike Christie <michaelc@cs.wisc.edu> Reviewed-by:
-
Davide Italiano authored
commit 280227a7 upstream. fallocate() checks that the file is extent-based and returns EOPNOTSUPP in case is not. Other tasks can convert from and to indirect and extent so it's safe to check only after grabbing the inode mutex. Signed-off-by:
Davide Italiano <dccitaliano@gmail.com> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
Lukas Czerner authored
commit d2dc317d upstream. Currently it is possible to lose whole file system block worth of data when we hit the specific interaction with unwritten and delayed extents in status extent tree. The problem is that when we insert delayed extent into extent status tree the only way to get rid of it is when we write out delayed buffer. However there is a limitation in the extent status tree implementation so that when inserting unwritten extent should there be even a single delayed block the whole unwritten extent would be marked as delayed. At this point, there is no way to get rid of the delayed extents, because there are no delayed buffers to write out. So when a we write into said unwritten extent we will convert it to written, but it still remains delayed. When we try to write into that block later ext4_da_map_blocks() will set the buffer new and delayed and map it to invalid block which causes the rest of the block to be zeroed loosing already written data. For now we can fix this by simply not allowing to set delayed status on written extent in the extent status tree. Also add WARN_ON() to make sure that we notice if this happens in the future. This problem can be easily reproduced by running the following xfs_io. xfs_io -f -c "pwrite -S 0xaa 4096 2048" \ -c "falloc 0 131072" \ -c "pwrite -S 0xbb 65536 2048" \ -c "fsync" /mnt/test/fff echo 3 > /proc/sys/vm/drop_caches xfs_io -c "pwrite -S 0xdd 67584 2048" /mnt/test/fff This can be theoretically also reproduced by at random by running fsx, but it's not very reliable, though on machines with bigger page size (like ppc) this can be seen more often (especially xfstest generic/127) Signed-off-by:
Lukas Czerner <lczerner@redhat.com> Signed-off-by:
-
Hans de Goede authored
commit 8e779c6c upstream. Testing has shown that ASM1053 devices do not work properly with transfers larger than 240 sectors, so set max_sectors to 240 on these. Reported-by:
Steve Bangert <sbangert@frontier.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Tested-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Hans de Goede authored
commit ee136af4 upstream. The usb-storage driver sets max_sectors = 240 in its scsi-host template, for uas we do not want to do that for all devices, but testing has shown that some devices need it. This commit adds a US_FL_MAX_SECTORS_240 flag for such devices, and implements support for it in uas.c, while at it it also adds support for US_FL_MAX_SECTORS_64 to uas.c. Signed-off-by:
-
Hans de Goede authored
commit a5011d44 upstream. uas_use_uas_driver may set some US_FL_foo flags during detection, currently these are stored in a local variable and then throw away, but these may be of interest to the caller, so add an extra parameter to (optionally) return the detected flags, and use this in the uas driver. Signed-off-by:
-
Ilya Dryomov authored
commit 082a75da upstream. When we end I/O struct request with error, we need to pass obj_request->length as @nr_bytes so that the entire obj_request worth of bytes is completed. Otherwise block layer ends up confused and we trip on rbd_assert(more ^ (which == img_request->obj_request_count)); in rbd_img_obj_callback() due to more being true no matter what. We already do it in most cases but we are missing some, in particular those where we don't even get a chance to submit any obj_requests, due to an early -ENOMEM for example. A number of obj_request->xferred assignments seem to be redundant but I haven't touched any of obj_request->xferred stuff to keep this small and isolated. Cc: Alex Elder <elder@linaro.org> Reported-by:
Shawn Edwards <lesser.evil@gmail.com> Reviewed-by:
Sage Weil <sage@redhat.com> Signed-off-by:
Ilya Dryomov <idryomov@gmail.com> Signed-off-by:
-
Ludovic Desroches authored
commit a8d4e016 upstream. Maxburst was not set when doing the dma slave configuration. This value is checked by the recently introduced xdmac. It causes an error when doing the slave configuration and so prevents from using dma. Signed-off-by:
Ludovic Desroches <ludovic.desroches@atmel.com> Acked-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
-
Chris Bainbridge authored
commit 61f8ff69 upstream. Commit 9faf6136 (ACPI / SBS: Disable smart battery manager on Apple) introduced a regression disabling the SBS battery manager. The battery manager should be marked as present when acpi_manager_get_info() returns 0. Fixes: 9faf6136 (ACPI / SBS: Disable smart battery manager on Apple) Signed-off-by:
-
Omar Sandoval authored
commit 909e26dc upstream. Whenever the check for a send in progress introduced in commit 521e0546 (btrfs: protect snapshots from deleting during send) is hit, we return without unlocking inode->i_mutex. This is easy to see with lockdep enabled: [ +0.000059] ================================================ [ +0.000028] [ BUG: lock held when returning to user space! ] [ +0.000029] 4.0.0-rc5-00096-g3c435c1e #93 Not tainted [ +0.000026] ------------------------------------------------ [ +0.000029] btrfs/211 is leaving the kernel with locks still held! [ +0.000029] 1 lock held by btrfs/211: [ +0.000023] #0: (&type->i_mutex_dir_key){+.+.+.}, at: [<ffffffff8135b8df>] btrfs_ioctl_snap_destroy+0x2df/0x7a0 Make sure we unlock it in the error path. Reviewed-by:
Filipe Manana <fdmanana@suse.com> Reviewed-by:
David Sterba <dsterba@suse.cz> Signed-off-by:
Omar Sandoval <osandov@osandov.com> Signed-off-by:
Chris Mason <clm@fb.com> Signed-off-by:
-
