- 29 Aug, 2016 2 commits
-
-
Anton Blanchard authored
BugLink: http://bugs.launchpad.net/bugs/1613295 With the recent change to enable_kernel_vsx(), we no longer need to call enable_kernel_fp() and enable_kernel_altivec(). Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> (cherry picked from commit 1552cd70) Signed-off-by:
Tim Gardner <tim.gardner@canonical.com> Acked-by:
Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Signed-off-by:
Kamal Mostafa <kamal@canonical.com>
-
Stephan Mueller authored
BugLink: http://bugs.launchpad.net/bugs/1613295 Commit 28856a9e missed the addition of the crypto/xts.h include file for different architecture-specific AES implementations. Signed-off-by:
Stephan Mueller <smueller@chronox.de> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> (cherry picked from commit 49abc0d2) Signed-off-by:
-
- 24 Aug, 2016 2 commits
-
-
Alan Stern authored
BugLink: https://bugs.launchpad.net/bugs/1616318 The USB core contains a bug that can show up when a USB-3 host controller is removed. If the primary (USB-2) hcd structure is released before the shared (USB-3) hcd, the core will try to do a double-free of the common bandwidth_mutex. The problem was described in graphical form by Chung-Geol Kim, who first reported it: ================================================= At *remove USB(3.0) Storage sequence <1> --> <5> ((Problem Case)) ================================================= VOLD ------------------------------------|------------ (uevent) ________|_________ |<1> | |dwc3_otg_sm_work | |usb_put_hcd | |peer_hcd(kref=2)| |__________________| ________|_________ |<2> | |New USB BUS #2 | | | |peer_hcd(kref=1) | | | --(Link)-bandXX_mutex| | |__________________| | ___________________ | |<3> | | |dwc3_otg_sm_work | | |usb_put_hcd | | |primary_hcd(kref=1)| | |___________________| | _________|_________ | |<4> | | |New USB BUS #1 | | |hcd_release | | |primary_hcd(kref=0)| | | | | |bandXX_mutex(free) |<- |___________________| (( VOLD )) ______|___________ |<5> | | SCSI | |usb_put_hcd | |peer_hcd(kref=0) | |*hcd_release | |bandXX_mutex(free*)|<- double free |__________________| ================================================= This happens because hcd_release() frees the bandwidth_mutex whenever it sees a primary hcd being released (which is not a very good idea in any case), but in the course of releasing the primary hcd, it changes the pointers in the shared hcd in such a way that the shared hcd will appear to be primary when it gets released. This patch fixes the problem by changing hcd_release() so that it deallocates the bandwidth_mutex only when the _last_ hcd structure referencing it is released. The patch also removes an unnecessary test, so that when an hcd is released, both the shared_hcd and primary_hcd pointers in the hcd's peer will be cleared. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Reported-by:
Chung-Geol Kim <chunggeol.kim@samsung.com> Tested-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit ab2a4bf8) Signed-off-by:
AceLan Kao <acelan.kao@canonical.com> Acked-by:
Andy Whitcroft <apw@canonical.com> Acked-by:
Christopher Arges <chris.j.arges@canonical.com> Signed-off-by:
-
Gabriel Krisman Bertazi authored
BugLink: http://bugs.launchpad.net/bugs/1602724 When nvme_delete_queue fails in the first pass of the nvme_disable_io_queues() loop, we return early, failing to suspend all of the IO queues. Later, on the nvme_pci_disable path, this causes us to disable MSI without actually having freed all the IRQs, which triggers the BUG_ON in free_msi_irqs(), as show below. This patch refactors nvme_disable_io_queues to suspend all queues before start submitting delete queue commands. This way, we ensure that we have at least returned every IRQ before continuing with the removal path. [ 487.529200] kernel BUG at ../drivers/pci/msi.c:368! cpu 0x46: Vector: 700 (Program Check) at [c0000078c5b83650] pc: c000000000627a50: free_msi_irqs+0x90/0x200 lr: c000000000627a40: free_msi_irqs+0x80/0x200 sp: c0000078c5b838d0 msr: 9000000100029033 current = 0xc0000078c5b40000 paca = 0xc000000002bd7600 softe: 0 irq_happened: 0x01 pid = 1376, comm = kworker/70:1H kernel BUG at ../drivers/pci/msi.c:368! Linux version 4.7.0.mainline+ (root@iod76) (gcc version 5.3.1 20160413 (Ubuntu/IBM 5.3.1-14ubuntu2.1) ) #104 SMP Fri Jul 29 09:20:17 CDT 2016 enter ? for help [c0000078c5b83920] d0000000363b0cd8 nvme_dev_disable+0x208/0x4f0 [nvme] [c0000078c5b83a10] d0000000363b12a4 nvme_timeout+0xe4/0x250 [nvme] [c0000078c5b83ad0] c0000000005690e4 blk_mq_rq_timed_out+0x64/0x110 [c0000078c5b83b40] c00000000056c930 bt_for_each+0x160/0x170 [c0000078c5b83bb0] c00000000056d928 blk_mq_queue_tag_busy_iter+0x78/0x110 [c0000078c5b83c00] c0000000005675d8 blk_mq_timeout_work+0xd8/0x1b0 [c0000078c5b83c50] c0000000000e8cf0 process_one_work+0x1e0/0x590 [c0000078c5b83ce0] c0000000000e9148 worker_thread+0xa8/0x660 [c0000078c5b83d80] c0000000000f2090 kthread+0x110/0x130 [c0000078c5b83e30] c0000000000095f0 ret_from_kernel_thread+0x5c/0x6c Signed-off-by:
Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com> Cc: Brian King <brking@linux.vnet.ibm.com> Cc: Keith Busch <keith.busch@intel.com> Cc: linux-nvme@lists.infradead.org Signed-off-by:
Jens Axboe <axboe@fb.com> (cherry picked from commit c21377f8) Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
-
- 23 Aug, 2016 14 commits
-
-
John Johansen authored
change_hat using probing to find and transition to the first available hat. Hats missing as part of this probe are expected and should not be logged except in complain mode. BugLink: http://bugs.launchpad.net/bugs/1615893Signed-off-by:
John Johansen <john.johansen@canonical.com> Acked-by:
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1615892Signed-off-by:
-
John Johansen authored
when viewing a stack involving unconfined from across a ns boundary the mode is reported as mixed. Eg. lxc-container-default//&:lxdns1://unconfined (mixed) This is because the unconfined profile is in the special unconfined mode. Which will result in a (mixed) mode for any stack with profiles in enforcing or complain mode. This can however lead to confusion as to what mode is being used as mixed is also used for enforcing stacked with complain. Since unconfined doesn't affect the stack just special case it. BugLink: http://bugs.launchpad.net/bugs/1615890Signed-off-by:
-
John Johansen authored
the policy_lock parameter is a one way switch that prevents policy from being further modified. Unfortunately some of the module parameters can effectively modify policy by turning off enforcement. split policy_admin_capable into a view check and a full admin check, and update the admin check to test the policy_lock parameter. BugLink: http://bugs.launchpad.net/bugs/1615895Signed-off-by:
-
John Johansen authored
the vec_unique path for large vectors is broken, leading to oopses when a file handle is shared between 8 different security domains, and then a profile replacement/removal causing a label invalidation (ie. not all replacements) is done. BugLink: http://bugs.launchpad.net/bugs/1579135Signed-off-by:
-
John Johansen authored
If the result of a merge/update/parse is a vec with a single entry we should not be returning a reference label, but just the label it self. BugLink: http://bugs.launchpad.net/bugs/1615889Signed-off-by:
-
John Johansen authored
When the ns hierarchy a//foo and b//foo are compared the are incorrectly identified as being the same as they have the same depth and the same basename. Instead make sure to compare the full hname to distinguish this case. BugLink: http://bugs.launchpad.net/bugs/1615887Signed-off-by:
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1592547 If unpack_dfa() returns NULL due to the dfa not being present, profile_unpack() is not checking if the dfa is not present (NULL). Signed-off-by:
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1615885Signed-off-by:
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1615882Signed-off-by:
-
John Johansen authored
The label build for onexec when crossing a namespace boundry is not quite correct. The label needs to be built per profile and not based on the whole label because the onexec transition only applies to profiles within the ns. Where merging against the label could include profile that are transitioned via the profile_transition callback and should not be in the final label. BugLink: http://bugs.launchpad.net/bugs/1615881Signed-off-by:
-
John Johansen authored
For the purposes of inherit we should be treating a profile/label transition to its replacement as if the replacement is the profile/label. So make the comparison based off of the label proxy, not the label itself. BugLink: http://bugs.launchpad.net/bugs/1615880Signed-off-by:
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1593874Signed-off-by:
-
John Johansen authored
The comparing the proxy pointer, not the address of the labels proxy pointer. BugLink: http://bugs.launchpad.net/bugs/1615878Signed-off-by:
-
- 22 Aug, 2016 22 commits
-
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1615620Signed-off-by:
-
Ben Hutchings authored
BugLink: http://bugs.launchpad.net/bugs/1615620 commit b8612e51 upstream. Signing a module should only make it trusted by the specific kernel it was built for, not anything else. If a module signing key is used for multiple ABI-incompatible kernels, the modules need to include enough version information to distinguish them. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
Ben Hutchings authored
BugLink: http://bugs.launchpad.net/bugs/1615620 commit bca014ca upstream. Signing a module should only make it trusted by the specific kernel it was built for, not anything else. Loading a signed module meant for a kernel with a different ABI could have interesting effects. Therefore, treat all signatures as invalid when a module is force-loaded. Signed-off-by:
-
Mike Snitzer authored
BugLink: http://bugs.launchpad.net/bugs/1615620 commit 99f3c90d upstream. When the corrupt_bio_byte feature was introduced it caused READ bios to no longer be errored with -EIO during the down_interval. This had to do with the complexity of needing to submit READs if the corrupt_bio_byte feature was used. Fix it so READ bios are properly errored with -EIO; doing so early in flakey_map() as long as there isn't a match for the corrupt_bio_byte feature. Fixes: a3998799 ("dm flakey: add corrupt_bio_byte feature") Reported-by:
Akira Hayakawa <ruby.wktk@gmail.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
-
Alim Akhtar authored
BugLink: http://bugs.launchpad.net/bugs/1615620 commit 70c96dfa upstream. As per code flow s3c_rtc_setfreq() will get called with rtc clock disabled and in set_freq we perform h/w registers read/write, which results in a kernel crash on exynos7 platform while probing rtc driver. Below is code flow: s3c_rtc_probe() clk_prepare_enable(info->rtc_clk) // rtc clock enabled s3c_rtc_gettime() // will enable clk if not done, and disable it upon exit s3c_rtc_setfreq() //then this will be called with clk disabled This patch take cares of such issue by adding s3c_rtc_{enable/disable}_clk in s3c_rtc_setfreq(). Fixes: 24e14554 ("drivers/rtc/rtc-s3c.c: delete duplicate clock control") Signed-off-by:
Alim Akhtar <alim.akhtar@samsung.com> Reviewed-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Reviewed-by:
Pankaj Dubey <pankaj.dubey@samsung.com> Tested-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by:
-
Lv Zheng authored
BugLink: http://bugs.launchpad.net/bugs/1615620 commit e1191bd4 upstream. A regression is caused by the following commit: Commit: 02b771b6 Subject: ACPI / EC: Fix an issue caused by the serialized _Qxx evaluations In this commit, using system workqueue causes that the maximum parallel executions of _Qxx can exceed 255. This violates the method reentrancy limit in ACPICA and generates the following error log: ACPI Error: Method reached maximum reentrancy limit (255) (20150818/dsmethod-341) This patch creates a seperate workqueue and limits the number of parallel _Qxx evaluations down to a configurable value (can be tuned against number of online CPUs). Since EC events are handled after driver probe, we can create the workqueue in acpi_ec_init(). Fixes: 02b771b6 (ACPI / EC: Fix an issue caused by the serialized _Qxx evaluations) Link: https://bugzilla.kernel.org/show_bug.cgi?id=135691Reported-and-tested-by:
Helen Buus <ubuntu@hbuus.com> Signed-off-by:
Lv Zheng <lv.zheng@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Andy Shevchenko authored
BugLink: http://bugs.launchpad.net/bugs/1615620 commit bb275705 upstream. On Intel Merrifield platform several PCI devices have a bogus configuration, i.e. the IRQ0 had been assigned to few of them. These are PCI root bridge, eMMC0, HS UART common registers, PWM, and HDMI. The actual interrupt line can be allocated to one device exclusively, in our case to eMMC0, the rest should cope without it and basically known drivers for them are not using interrupt line at all. Rework IRQ0 workaround, which was previously done to avoid conflict between eMMC0 and HS UART common registers, to behave differently based on the device in question, i.e. allocate interrupt line to eMMC0, but silently skip interrupt allocation for the rest except HS UART common registers which are not used anyway. With this rework IOSF MBI driver in particular would be used. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Fixes: 39d9b77b ("x86/pci/intel_mid_pci: Work around for IRQ0 assignment") Link: http://lkml.kernel.org/r/1465842481-136852-1-git-send-email-andriy.shevchenko@linux.intel.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Chris Blake authored
BugLink: http://bugs.launchpad.net/bugs/1615620 commit 9ac0108c upstream. Similar to the AR93xx series, the AR94xx and the Qualcomm QCA988x also have the same quirk for the Bus Reset. Fixes: c3e59ee4 ("PCI: Mark Atheros AR93xx to avoid bus reset") Signed-off-by:
Chris Blake <chrisrblake93@gmail.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Huacai Chen authored
BugLink: http://bugs.launchpad.net/bugs/1615620 commit 3ef06653 upstream. At first, we prefer to use mips clockevent device, so we decrease the rating of hpet clockevent device. For hpet, if HPET_MIN_PROG_DELTA (minimum delta of hpet programming) is too small and HPET_MIN_CYCLES (threshold of -ETIME checking) is too large, then hpet_next_event() can easily return -ETIME. After commit c6eb3f70 ("hrtimer: Get rid of hrtimer softirq") this will cause a RCU stall. So, HPET_MIN_PROG_DELTA must be sufficient that we don't re-trip the -ETIME check -- if we do, we will return -ETIME, forward the next event time, try to set it, return -ETIME again, and basically lock the system up. Meanwhile, HPET_MIN_CYCLES doesn't need to be too large, 16 cycles is enough. This solution is similar to commit f9eccf24 ("clocksource/drivers /vt8500: Increase the minimum delta"). By the way, this patch ensures hpet count/compare to be 32-bit long. Signed-off-by:
Huacai Chen <chenhc@lemote.com> Cc: John Crispin <john@phrozen.org> Cc: Steven J . Hill <Steven.Hill@imgtec.com> Cc: Fuxin Zhang <zhangfx@lemote.com> Cc: Zhangjin Wu <wuzhangjin@gmail.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13819/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Huacai Chen authored
BugLink: http://bugs.launchpad.net/bugs/1615620 commit 07d69579 upstream. Don't register r4k sched clock when CPUFREQ enabled because sched clock need a constant frequency. Signed-off-by:
-
Matt Redfearn authored
BugLink: http://bugs.launchpad.net/bugs/1615620 commit 4f53989b upstream. Commit a168b8f1 ("MIPS: mm: Add MIPS R6 instruction encodings") added an incorrect definition of the redefined MIPSr6 cache instruction. Executing any kernel code including this instuction results in a reserved instruction exception and kernel panic. Fix the instruction definition. Fixes: a168b8f1Signed-off-by:
Matt Redfearn <matt.redfearn@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/13663/Signed-off-by:
-
Trond Myklebust authored
BugLink: http://bugs.launchpad.net/bugs/1615620 commit db1bb44c upstream. We're always tracing IPv4 or IPv6 addresses, so we can save a lot of space on the ringbuffer by allocating the correct sockaddr size. Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Fixes: 83a712e0 "sunrpc: add some tracepoints around ..." Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
KT Liao authored
BugLink: http://bugs.launchpad.net/bugs/1615620 commit 2de4fcc6 upstream. Some ASUS laptops were shipped with touchpads that require to be woken up first, before trying to switch them into absolute reporting mode, otherwise touchpad would fail to work while flooding the logs with: elan_i2c i2c-ELAN1000:00: invalid report id data (1) Among affected devices are Asus E202SA, N552VW, X456UF, UX305CA, and others. We detect such devices by checking the IC type and product ID numbers and adjusting order of operations accordingly. Signed-off-by:
KT Liao <kt.liao@emc.com.tw> Reported-by:
Chris Chiu <chiu@endlessm.com> Reported-by:
Vlad Glagolev <stealth@vaygr.net> Tested-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Nicholas Bellinger authored
BugLink: http://bugs.launchpad.net/bugs/1615620 commit 410c29df upstream. If a Simple command is sent with a failure, target_setup_cmd_from_cdb returns with TCM_UNSUPPORTED_SCSI_OPCODE or TCM_INVALID_CDB_FIELD. So in the cases where target_setup_cmd_from_cdb returns an error, we never get far enough to call target_execute_cmd to increment simple_cmds. Since simple_cmds isn't incremented, the result of the failure from target_setup_cmd_from_cdb causes transport_generic_request_failure to decrement simple_cmds, due to call to transport_complete_task_attr. With this dev->simple_cmds or dev->dev_ordered_sync is now -1, not 0. So when a subsequent command with an Ordered Task is sent, it causes a hang, since dev->simple_cmds is at -1. Tested-by:
Bryant G. Ly <bryantly@linux.vnet.ibm.com> Signed-off-by:
Michael Cyr <mikecyr@linux.vnet.ibm.com> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Mike Christie authored
BugLink: http://bugs.launchpad.net/bugs/1615620 commit ea263c7f upstream. max_discard_sectors only 32bits, and some non scsi backend devices will set this to the max 0xffffffff, so we can end up overflowing during the max_unmap_lba_count calculation. This fixes a regression caused by my patch: commit 8a9ebe71 Author: Mike Christie <mchristi@redhat.com> Date: Mon Jan 18 14:09:27 2016 -0600 target: Fix WRITE_SAME/DISCARD conversion to linux 512b sectors which can result in extra discards being sent to due the overflow causing max_unmap_lba_count to be smaller than what the backing device can actually support. Signed-off-by:
Mike Christie <mchristi@redhat.com> Reviewed-by:
Bart Van Assche <bart.vanassche@sandisk.com> Signed-off-by:
-
Nicholas Bellinger authored
BugLink: http://bugs.launchpad.net/bugs/1615620 commit 064cdd2d upstream. This patch fixes a race in iscsit_release_commands_from_conn() -> iscsit_free_cmd() -> transport_generic_free_cmd() + wait_for_tasks=1, where CMD_T_FABRIC_STOP could end up being set after the final kref_put() is called from core_tmr_abort_task() context. This results in transport_generic_free_cmd() blocking indefinately on se_cmd->cmd_wait_comp, because the target_release_cmd_kref() check for CMD_T_FABRIC_STOP returns false. To address this bug, make iscsit_release_commands_from_conn() do list_splice and set CMD_T_FABRIC_STOP early while holding iscsi_conn->cmd_lock. Also make iscsit_aborted_task() only remove iscsi_cmd_t if CMD_T_FABRIC_STOP has not already been set. Finally in target_release_cmd_kref(), only honor fabric_stop if CMD_T_ABORTED has been set. Cc: Mike Christie <mchristi@redhat.com> Cc: Quinn Tran <quinn.tran@qlogic.com> Cc: Himanshu Madhani <himanshu.madhani@qlogic.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Hannes Reinecke <hare@suse.de> Tested-by:
-
Nicholas Bellinger authored
BugLink: http://bugs.launchpad.net/bugs/1615620 commit 5e2c956b upstream. During transport_generic_free_cmd() with a concurrent TMR ABORT_TASK and shutdown CMD_T_FABRIC_STOP bit set, the caller will be blocked on se_cmd->cmd_wait_stop completion until the final kref_put() -> target_release_cmd_kref() has been invoked to call complete(). However, when ABORT_TASK is completed with FUNCTION_COMPLETE in core_tmr_abort_task(), the aborted se_cmd will have already been removed from se_sess->sess_cmd_list via list_del_init(). This results in target_release_cmd_kref() hitting the legacy list_empty() == true check, invoking ->release_cmd() but skipping complete() to wakeup se_cmd->cmd_wait_stop blocked earlier in transport_generic_free_cmd() code. To address this bug, it's safe to go ahead and drop the original list_empty() check so that fabric_stop invokes the complete() as expected, since list_del_init() can safely be used on a empty list. Cc: Mike Christie <mchristi@redhat.com> Cc: Quinn Tran <quinn.tran@qlogic.com> Cc: Himanshu Madhani <himanshu.madhani@qlogic.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Hannes Reinecke <hare@suse.de> Tested-by:
-
Nicholas Bellinger authored
BugLink: http://bugs.launchpad.net/bugs/1615620 commit dff0ca9e upstream. If a command with a Simple task attribute is failed due to a Unit Attention, then a subsequent command with an Ordered task attribute will hang forever. The reason for this is that the Unit Attention status is checked for in target_setup_cmd_from_cdb, before the call to target_execute_cmd, which calls target_handle_task_attr, which in turn increments dev->simple_cmds. However, transport_generic_request_failure still calls transport_complete_task_attr, which will decrement dev->simple_cmds. In this case, simple_cmds is now -1. So when a command with the Ordered task attribute is sent, target_handle_task_attr sees that dev->simple_cmds is not 0, so it decides it can't execute the command until all the (nonexistent) Simple commands have completed. Reported-by:
-
Feng Li authored
BugLink: http://bugs.launchpad.net/bugs/1615620 commit 8abc718d upstream. In MC/S scenario, the conn->sess has been set NULL in iscsi_login_non_zero_tsih_s1 when the second connection comes here, then kernel panic. The conn->sess will be assigned in iscsi_login_non_zero_tsih_s2. So we should check whether it's NULL before calling. Signed-off-by:
Feng Li <lifeng1519@gmail.com> Tested-by:
Sumit Rai <sumit.rai@calsoftinc.com> Signed-off-by:
-
Iosif Harutyunov authored
BugLink: http://bugs.launchpad.net/bugs/1615620 commit 714fb87e upstream. Install the UBI device object before we arm sysfs. Otherwise udev tries to read sysfs attributes before UBI is ready and udev rules will not match. Signed-off-by:
Iosif Harutyunov <iharutyunov@sonicwall.com> [rw: massaged commit message] Signed-off-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
-
Richard Weinberger authored
BugLink: http://bugs.launchpad.net/bugs/1615620 commit bc743f34 upstream. We cannot use ubi_* logging functions before the UBI object is initialized. Fixes: 32608703 ("UBI: Extend UBI layer debug/messaging capabilities") Signed-off-by:
-
Richard Weinberger authored
BugLink: http://bugs.launchpad.net/bugs/1615620 commit 4946784b upstream. When the volume resize operation shrinks a volume, LEBs will be unmapped. Since unmapping will not erase these LEBs immediately we have to wait for that operation to finish. Otherwise in case of a power cut right after writing the new volume table the UBI attach process can find more LEBs than the volume table knows. This will render the UBI image unattachable. Fix this issue by waiting for erase to complete and write the new volume table afterward. Reported-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Reviewed-by:
-
