- 28 5月, 2016 14 次提交
-
-
由 Al Viro 提交于
smack ->d_instantiate() uses ->setxattr(), so to be able to call it before we'd hashed the new dentry and attached it to inode, we need ->setxattr() instances getting the inode as an explicit argument rather than obtaining it from dentry. Similar change for ->getxattr() had been done in commit ce23e640. Unlike ->getxattr() (which is used by both selinux and smack instances of ->d_instantiate()) ->setxattr() is used only by smack one and unfortunately it got missed back then. Reported-by: NSeung-Woo Kim <sw0312.kim@samsung.com> Tested-by: NCasey Schaufler <casey@schaufler-ca.com> Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
由 Manfred Schlaegl 提交于
Pwm config may sleep so defer it using a worker. On a Freescale i.MX53 based board we ran into "BUG: scheduling while atomic" because input_inject_event locks interrupts, but imx_pwm_config_v2 sleeps. Tested on Freescale i.MX53 SoC with 4.6.0. Signed-off-by: NManfred Schlaegl <manfred.schlaegl@gmx.at> Cc: stable@vger.kernel.org Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Pavel Rojtberg 提交于
added the according id and incresed XPAD_PKT_LEN to 64 as the elite controller sends at least 33 byte messages [1]. Verified to be working by [2]. [1]: https://franticrain.github.io/sniffs/XboxOneSniff.html [2]: https://github.com/paroj/xpad/issues/23Signed-off-by: NPierre-Loup A. Griffais <eduke32@plagman.net> Signed-off-by: NPavel Rojtberg <rojtberg@gmail.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Pavel Rojtberg 提交于
Signed-off-by: NPierre-Loup A. Griffais <eduke32@plagman.net> Signed-off-by: NThomas Debesse <dev@illwieckz.net> Signed-off-by: Naronschatz <aronschatz@aselabs.com> Signed-off-by: NPavel Rojtberg <rojtberg@gmail.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Cameron Gutman 提交于
After initially connecting a wired Xbox 360 controller or sending it a command to change LEDs, a status/response packet is interpreted as controller input. This causes the state of buttons represented in byte 2 of the controller data packet to be incorrect until the next valid input packet. Wireless Xbox 360 controllers are not affected. Writing a new value to the LED device while holding the Start button and running jstest is sufficient to reproduce this bug. An event will come through with the Start button released. Xboxdrv also won't attempt to read controller input from a packet where byte 0 is non-zero. It also checks that byte 1 is 0x14, but that value differs between wired and wireless controllers and this code is shared by both. I think just checking byte 0 is enough to eliminate unwanted packets. The following are some examples of 3-byte status packets I saw: 01 03 02 02 03 00 03 03 03 08 03 00 Signed-off-by: NCameron Gutman <aicommander@gmail.com> Signed-off-by: NPavel Rojtberg <rojtberg@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Pavel Rojtberg 提交于
otherwise we lose ff commands: https://github.com/paroj/xpad/issues/27Signed-off-by: NPavel Rojtberg <rojtberg@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Arnd Bergmann 提交于
Most users of IS_ERR_VALUE() in the kernel are wrong, as they pass an 'int' into a function that takes an 'unsigned long' argument. This happens to work because the type is sign-extended on 64-bit architectures before it gets converted into an unsigned type. However, anything that passes an 'unsigned short' or 'unsigned int' argument into IS_ERR_VALUE() is guaranteed to be broken, as are 8-bit integers and types that are wider than 'unsigned long'. Andrzej Hajda has already fixed a lot of the worst abusers that were causing actual bugs, but it would be nice to prevent any users that are not passing 'unsigned long' arguments. This patch changes all users of IS_ERR_VALUE() that I could find on 32-bit ARM randconfig builds and x86 allmodconfig. For the moment, this doesn't change the definition of IS_ERR_VALUE() because there are probably still architecture specific users elsewhere. Almost all the warnings I got are for files that are better off using 'if (err)' or 'if (err < 0)'. The only legitimate user I could find that we get a warning for is the (32-bit only) freescale fman driver, so I did not remove the IS_ERR_VALUE() there but changed the type to 'unsigned long'. For 9pfs, I just worked around one user whose calling conventions are so obscure that I did not dare change the behavior. I was using this definition for testing: #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \ unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO)) which ends up making all 16-bit or wider types work correctly with the most plausible interpretation of what IS_ERR_VALUE() was supposed to return according to its users, but also causes a compile-time warning for any users that do not pass an 'unsigned long' argument. I suggested this approach earlier this year, but back then we ended up deciding to just fix the users that are obviously broken. After the initial warning that caused me to get involved in the discussion (fs/gfs2/dir.c) showed up again in the mainline kernel, Linus asked me to send the whole thing again. [ Updated the 9p parts as per Al Viro - Linus ] Signed-off-by: NArnd Bergmann <arnd@arndb.de> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Andrew Morton <akpm@linux-foundation.org> Link: https://lkml.org/lkml/2016/1/7/363 Link: https://lkml.org/lkml/2016/5/27/486 Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> # For nvmem part Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Rajneesh Bhardwaj 提交于
This patch adds the Power Management Controller driver as a PCI driver for Intel Core SoC architecture. This driver can utilize debugging capabilities and supported features as exposed by the Power Management Controller. Please refer to the below specification for more details on PMC features. http://www.intel.in/content/www/in/en/chipsets/100-series-chipset-datasheet-vol-2.html The current version of this driver exposes SLP_S0_RESIDENCY counter. This counter can be used for detecting fragile SLP_S0 signal related failures and take corrective actions when PCH SLP_S0 signal is not asserted after kernel freeze as part of suspend to idle flow (echo freeze > /sys/power/state). Intel Platform Controller Hub (PCH) asserts SLP_S0 signal when it detects favorable conditions to enter its low power mode. As a pre-requisite the SoC should be in deepest possible Package C-State and devices should be in low power mode. For example, on Skylake SoC the deepest Package C-State is Package C10 or PC10. Suspend to idle flow generally leads to PC10 state but PC10 state may not be sufficient for realizing the platform wide power potential which SLP_S0 signal assertion can provide. SLP_S0 signal is often connected to the Embedded Controller (EC) and the Power Management IC (PMIC) for other platform power management related optimizations. In general, SLP_S0 assertion == PC10 + PCH low power mode + ModPhy Lanes power gated + PLL Idle. As part of this driver, a mechanism to read the SLP_S0_RESIDENCY is exposed as an API and also debugfs features are added to indicate SLP_S0 signal assertion residency in microseconds. echo freeze > /sys/power/state wake the system cat /sys/kernel/debug/pmc_core/slp_s0_residency_usec Signed-off-by: NRajneesh Bhardwaj <rajneesh.bhardwaj@intel.com> Signed-off-by: NVishwanath Somayaji <vishwanath.somayaji@intel.com> Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
-
由 Gabriele Mazzotta 提交于
Some BIOSes unconditionally send an ACPI notification to RBTN when the system is resuming from suspend. This makes dell-rbtn send an input event to userspace as if a function key was pressed. Prevent this by ignoring all the notifications received while the device is suspended. Link: https://bugzilla.kernel.org/show_bug.cgi?id=106031Signed-off-by: NGabriele Mazzotta <gabriele.mzt@gmail.com> Tested-by: NAlex Hung <alex.hung@canonical.com> Reviewed-by: NPali Rohár <pali.rohar@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
-
由 Marco Trevisan (Treviño) 提交于
Override default LED class suspend/resume handles, by keeping track of the brightness level before suspending so that it can be automatically restored on resume by calling default resume handler. Signed-off-by: NMarco Trevisan (Treviño) <mail@3v1n0.net> Acked-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
-
由 Rasmus Villemoes 提交于
aux0_show and aux1_show consists of almost identical code. Pull that into a common helper and make them thin wrappers. Similarly for _store. Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
-
由 Oleksij Rempel 提交于
Asus Zenbook ux31a is providing ACPI0008 interface for ALS (Ambient Light Sensor), which is accessible for OS => Win 7. This sensor can be used with iio/acpi-als driver. Since it is disabled by default, we should use asus-wmi interface to enable it. Signed-off-by: NOleksij Rempel <linux@rempel-privat.de> Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
-
由 Arnd Bergmann 提交于
My patch to the ideapad-laptop driver to get the ESC key working on the Yoga 1170 (Yoga 3) failed to do the same for the following model, the Lenovo Yoga 700. Denis Gordienko managed to get it working by adding another GUID for the new WMI interface. I have adapted his patch to normal coding style and simplified it a bit for inclusion, but this patch is currently untested. Link: https://forums.lenovo.com/t5/Lenovo-Yoga-Series-Notebooks/YOGA-3-14-How-to-reclaim-my-Esc-key-and-permanently-disable/m-p/3317499Signed-off-by: NArnd Bergmann <arnd@arndb.de> Tested-by: NDenis Gordienko <denis.gordienko.mail@gmail.com> [dvhart: Whitespace cleanup, static const char *const array declaration] Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
-
由 Andy Shevchenko 提交于
Microsoft Surface Book has a tablet mode button. Print another message once on this event instead of repeating "Unknown event...". Unfortunately, proper support involves the _DSM method, which is not a discoverable interface. Just print a warning for now. Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
-
- 27 5月, 2016 7 次提交
-
-
由 Wolfram Sang 提交于
I stumbled multiple times over 'return_i2c_dev', especially before the actual 'return res'. It makes the code hard to read, so reanme the function to 'put_i2c_dev' which also better matches 'get_free_i2c_dev'. Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Andrew Morton 提交于
gcc-4.4 and thereabouts has issues with initializers of anonymous unions, and it generates the following warnings: drivers/pinctrl/intel/pinctrl-baytrail.c:413: error: unknown field 'simple_funcs' specified in initializer drivers/pinctrl/intel/pinctrl-baytrail.c:413: warning: missing braces around initializer drivers/pinctrl/intel/pinctrl-baytrail.c:413: warning: (near initialization for 'byt_score_groups[0].<anonymous>') drivers/pinctrl/intel/pinctrl-baytrail.c:415: error: unknown field 'simple_funcs' specified in initializer drivers/pinctrl/intel/pinctrl-baytrail.c:417: error: unknown field 'simple_funcs' specified in initializer ... Work around this. Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com> Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Erico Nunes 提交于
i2c-dev had never moved away from the older register_chrdev interface to implement its char device registration. The register_chrdev API has the limitation of enabling only up to 256 i2c-dev busses to exist. Large platforms with lots of i2c devices (i.e. pluggable transceivers) with dedicated busses may have to exceed that limit. In particular, there are also platforms making use of the i2c bus multiplexing API, which instantiates a virtual bus for each possible multiplexed selection. This patch removes the register_chrdev usage and replaces it with the less old cdev API, which takes away the 256 i2c-dev bus limitation. It should not have any other impact for i2c bus drivers or user space. This patch has been tested on qemu x86 and qemu powerpc platforms with the aid of a module which adds and removes 5000 virtual i2c busses, as well as validated on an existing powerpc hardware platform which makes use of the i2c bus multiplexing API. i2c-dev busses with device minor numbers larger than 256 have also been validated to work with the existing i2c-tools. Signed-off-by: NErico Nunes <erico.nunes@datacom.ind.br> [wsa: kept includes sorted] Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Marc Gonzalez 提交于
The ARCH name was changed during the review process of the mach, and this driver was forgotten to be converted. Fix it now. http://article.gmane.org/gmane.linux.ports.arm.kernel/456331Signed-off-by: NMarc Gonzalez <marc_gonzalez@sigmadesigns.com> [wsa: updated commit message slightly] Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Ludovic Desroches 提交于
When the DMA configuration fails, there is a log reporting that we can't use DMA and indicating the error number. When booting the kernel, it is annoying to see this error number. Moreover, people can think something is going wrong. It is not the case, it means that DMA can't be used but it doesn't prevent to use i2c. Signed-off-by: NLudovic Desroches <ludovic.desroches@atmel.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Geert Uytterhoeven 提交于
If NO_DMA=y: drivers/built-in.o: In function `rcar_i2c_dma_unmap': i2c-rcar.c:(.text+0x6f06c6): undefined reference to `bad_dma_ops' drivers/built-in.o: In function `rcar_i2c_dma': i2c-rcar.c:(.text+0x6f07e2): undefined reference to `bad_dma_ops' i2c-rcar.c:(.text+0x6f0838): undefined reference to `bad_dma_ops' Add a dependency on HAS_DMA to fix this. Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org> Acked-by: NNiklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Niklas Söderlund 提交于
New drivers should not use dma_request_slave_channel_reason() but dma_request_chan(). The former is a macro to the later so this change do not effect the driver in any way. Reported-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NNiklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 26 5月, 2016 12 次提交
-
-
由 Dan Carpenter 提交于
"apd" was intended here instead of "init". Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NJean Delvare <jdelvare@suse.de>
-
由 Wenyou Yang 提交于
This reverts commit 5ddc7bd4 ("mtd: atmel_nand: Support variable RB_EDGE interrupts") Because for current SoCs, the RB_EDGE3(i.e. bit 27) of HSMC_SR register does not exist, the RB_EDGE0 (i.e. bit 24) is the ready/busy line edge status bit. It is a datasheet bug. Cc: <stable@vger.kernel.org> Fixes: commit 5ddc7bd4 ("mtd: atmel_nand: Support variable RB_EDGE interrupts") Signed-off-by: NWenyou Yang <wenyou.yang@atmel.com> Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
-
由 Ilya Dryomov 提交于
... with a wrapper around maybe_request_map() - no need for two osdmap-specific functions. Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
-
由 Ilya Dryomov 提交于
For map check, we are going to need to send CEPH_MSG_MON_GET_VERSION messages asynchronously and get a callback on completion. Refactor MON client to allow firing off generic requests asynchronously and add an async variant of ceph_monc_get_version(). ceph_monc_do_statfs() is switched over and remains sync. Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
-
由 Ilya Dryomov 提交于
This adds support and switches rbd to a new, more reliable version of watch/notify protocol. As with the OSD client update, this is mostly about getting the right structures linked into the right places so that reconnects are properly sent when needed. watch/notify v2 also requires sending regular pings to the OSDs - send_linger_ping(). A major change from the old watch/notify implementation is the introduction of ceph_osd_linger_request - linger requests no longer piggy back on ceph_osd_request. ceph_osd_event has been merged into ceph_osd_linger_request. All the details are now hidden within libceph, the interface consists of a simple pair of watch/unwatch functions and ceph_osdc_notify_ack(). ceph_osdc_watch() does return ceph_osd_linger_request, but only to keep the lifetime management simple. ceph_osdc_notify_ack() accepts an optional data payload, which is relayed back to the notifier. Portions of this patch are loosely based on work by Douglas Fuller <dfuller@redhat.com> and Mike Christie <michaelc@cs.wisc.edu>. Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
-
由 Ilya Dryomov 提交于
Introduce __rbd_dev_header_unwatch_sync(), which doesn't flush notify callbacks. This is for the new rados_watcherrcb_t, which would be called from a notify callback. Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
-
由 Ilya Dryomov 提交于
finish_read(), its only user, uses it to get to hdr.data_len, which is what ->r_result is set to on success. This gains us the ability to safely call callbacks from contexts other than reply, e.g. map check. Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
-
由 Ilya Dryomov 提交于
The crux of this is getting rid of ceph_osdc_build_request(), so that MOSDOp can be encoded not before but after calc_target() calculates the actual target. Encoding now happens within ceph_osdc_start_request(). Also nuked is the accompanying bunch of pointers into the encoded buffer that was used to update fields on each send - instead, the entire front is re-encoded. If we want to support target->name_len != base->name_len in the future, there is no other way, because oid is surrounded by other fields in the encoded buffer. Encoding OSD ops and adding data items to the request message were mixed together in osd_req_encode_op(). While we want to re-encode OSD ops, we don't want to add duplicate data items to the message when resending, so all call to ceph_osdc_msg_data_add() are factored out into a new setup_request_data(). Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
-
由 Ilya Dryomov 提交于
Switch to ceph_object_id and use ceph_oid_aprintf() instead of a bare const char *. This reduces noise in rbd_dev_header_name(). Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
-
由 Ilya Dryomov 提交于
Currently ceph_object_id can hold object names of up to 100 (CEPH_MAX_OID_NAME_LEN) characters. This is enough for all use cases, expect one - long rbd image names: - a format 1 header is named "<imgname>.rbd" - an object that points to a format 2 header is named "rbd_id.<imgname>" We operate on these potentially long-named objects during rbd map, and, for format 1 images, during header refresh. (A format 2 header name is a small system-generated string.) Lift this 100 character limit by making ceph_object_id be able to point to an externally-allocated string. Apart from being able to work with almost arbitrarily-long named objects, this allows us to reduce the size of ceph_object_id from >100 bytes to 64 bytes. Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
-
由 Ilya Dryomov 提交于
The size of ->r_request and ->r_reply messages depends on the size of the object name (ceph_object_id), while the size of ceph_osd_request is fixed. Move message allocation into a separate function that would have to be called after ceph_object_id and ceph_object_locator (which is also going to become variable in size with RADOS namespaces) have been filled in: req = ceph_osdc_alloc_request(...); <fill in req->r_base_oid> <fill in req->r_base_oloc> ceph_osdc_alloc_messages(req); Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
-
由 Ilya Dryomov 提交于
By the time we get to checking for_each_obj_request_safe(img_request) terminating condition, all obj_requests may be complete and img_request ref, that rbd_img_request_submit() takes away from its caller, may be put. Moving the next_obj_request cursor is then a use-after-free on img_request. It's totally benign, as the value that's read is never used, but I think it's still worth fixing. Cc: Alex Elder <elder@linaro.org> Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
-
- 25 5月, 2016 3 次提交
-
-
由 Jeff Mahoney 提交于
The DRM_AMD_ACP option doesn't have any dependencies and selects MFD_CORE, which results in MFD_CORE=y. Since the code is only called from DRM_AMDGPU, it should depend on it. Adding the dependency results in MFD_CORE being selected as a module again if amdgpu is also a module. Signed-off-by: NJeff Mahoney <jeffm@suse.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Mario Kleiner 提交于
When porting the hdmi deep color detection code from radeon-kms to amdgpu-kms apparently some kind of copy and paste error happened, attaching an else branch to the wrong if statement. The result is that hdmi deep color mode is always disabled, regardless of gpu and display capabilities and user wishes, as the code mistakenly thinks that the display doesn't provide the required max_tmds_clock limit and falls back to 8 bpc. This patch fixes deep color support, as tested on a R9 380 Tonga Pro + suitable display, and should be backported to all kernels with amdgpu-kms support. Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com> Cc: stable@vger.kernel.org Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Monk Liu 提交于
Using wrong counter for walking fences. Fixes a crash when unloading the driver. Signed-off-by: NMonk Liu <Monk.Liu@amd.com> Reviewed-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 24 5月, 2016 4 次提交
-
-
由 Jiri Kosina 提交于
bch_gc_thread() doesn't mark itself freezable, so calling try_to_freeze() in its context is just an expensive no-op. Signed-off-by: NJiri Kosina <jkosina@suse.cz> Signed-off-by: NJens Axboe <axboe@fb.com>
-
由 Jiri Kosina 提交于
bch_allocator_thread() is calling try_to_freeze(), but that's just an expensive no-op given the fact that the thread is not marked freezable. Bucket allocator has to be up and running to the very last stages of the suspend, as the bcache I/O that's in flight (think of writing an hibernation image to a swap device served by bcache). Signed-off-by: NJiri Kosina <jkosina@suse.cz> Signed-off-by: NJens Axboe <axboe@fb.com>
-
由 Jiri Kosina 提交于
bch_writeback_thread() is calling try_to_freeze(), but that's just an expensive no-op given the fact that the thread is not marked freezable. I/O helper kthreads, exactly such as the bcache writeback thread, actually shouldn't be freezable, because they are potentially necessary for finalizing the image write-out. Signed-off-by: NJiri Kosina <jkosina@suse.cz> Signed-off-by: NJens Axboe <axboe@fb.com>
-
由 Richard Weinberger 提交于
Ezequiel reported that he's facing UBI going into read-only mode after power cut. It turned out that this behavior happens only when updating a static volume is interrupted and Fastmap is used. A possible trace can look like: ubi0 warning: ubi_io_read_vid_hdr [ubi]: no VID header found at PEB 2323, only 0xFF bytes ubi0 warning: ubi_eba_read_leb [ubi]: switch to read-only mode CPU: 0 PID: 833 Comm: ubiupdatevol Not tainted 4.6.0-rc2-ARCH #4 Hardware name: SAMSUNG ELECTRONICS CO., LTD. 300E4C/300E5C/300E7C/NP300E5C-AD8AR, BIOS P04RAP 10/15/2012 0000000000000286 00000000eba949bd ffff8800c45a7b38 ffffffff8140d841 ffff8801964be000 ffff88018eaa4800 ffff8800c45a7bb8 ffffffffa003abf6 ffffffff850e2ac0 8000000000000163 ffff8801850e2ac0 ffff8801850e2ac0 Call Trace: [<ffffffff8140d841>] dump_stack+0x63/0x82 [<ffffffffa003abf6>] ubi_eba_read_leb+0x486/0x4a0 [ubi] [<ffffffffa00453b3>] ubi_check_volume+0x83/0xf0 [ubi] [<ffffffffa0039d97>] ubi_open_volume+0x177/0x350 [ubi] [<ffffffffa00375d8>] vol_cdev_open+0x58/0xb0 [ubi] [<ffffffff8124b08e>] chrdev_open+0xae/0x1d0 [<ffffffff81243bcf>] do_dentry_open+0x1ff/0x300 [<ffffffff8124afe0>] ? cdev_put+0x30/0x30 [<ffffffff81244d36>] vfs_open+0x56/0x60 [<ffffffff812545f4>] path_openat+0x4f4/0x1190 [<ffffffff81256621>] do_filp_open+0x91/0x100 [<ffffffff81263547>] ? __alloc_fd+0xc7/0x190 [<ffffffff812450df>] do_sys_open+0x13f/0x210 [<ffffffff812451ce>] SyS_open+0x1e/0x20 [<ffffffff81a99e32>] entry_SYSCALL_64_fastpath+0x1a/0xa4 UBI checks static volumes for data consistency and reads the whole volume upon first open. If the volume is found erroneous users of UBI cannot read from it, but another volume update is possible to fix it. The check is performed by running ubi_eba_read_leb() on every allocated LEB of the volume. For static volumes ubi_eba_read_leb() computes the checksum of all data stored in a LEB. To verify the computed checksum it has to read the LEB's volume header which stores the original checksum. If the volume header is not found UBI treats this as fatal internal error and switches to RO mode. If the UBI device was attached via a full scan the assumption is correct, the volume header has to be present as it had to be there while scanning to get known as mapped. If the attach operation happened via Fastmap the assumption is no longer correct. When attaching via Fastmap UBI learns the mapping table from Fastmap's snapshot of the system state and not via a full scan. It can happen that a LEB got unmapped after a Fastmap was written to the flash. Then UBI can learn the LEB still as mapped and accessing it returns only 0xFF bytes. As UBI is not a FTL it is allowed to have mappings to empty PEBs, it assumes that the layer above takes care of LEB accounting and referencing. UBIFS does so using the LEB property tree (LPT). For static volumes UBI blindly assumes that all LEBs are present and therefore special actions have to be taken. The described situation can happen when updating a static volume is interrupted, either by a user or a power cut. The volume update code first unmaps all LEBs of a volume and then writes LEB by LEB. If the sequence of operations is interrupted UBI detects this either by the absence of LEBs, no volume header present at scan time, or corrupted payload, detected via checksum. In the Fastmap case the former method won't trigger as no scan happened and UBI automatically thinks all LEBs are present. Only by reading data from a LEB it detects that the volume header is missing and incorrectly treats this as fatal error. To deal with the situation ubi_eba_read_leb() from now on checks whether we attached via Fastmap and handles the absence of a volume header like a data corruption error. This way interrupted static volume updates will correctly get detected also when Fastmap is used. Cc: <stable@vger.kernel.org> Reported-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar> Tested-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: NRichard Weinberger <richard@nod.at>
-