- 07 Mar, 2021 40 commits
-
-
Greg Kroah-Hartman authored
Tested-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
Jason Self <jason@bluehome.net> Tested-by:
Florian Fainelli <f.fainelli@gmail.com> Tested-by:
Hulk Robot <hulkci@huawei.com> Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Link: https://lore.kernel.org/r/20210305120903.276489876@linuxfoundation.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Pali Rohár authored
[ Upstream commit 426c6cbc ] The workaround for VSOL V2801F brand based GPON SFP modules added in commit 0d035bed ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround") works only for IDs added explicitly to the list. Since there are rebranded modules where OEM vendors put different strings into the vendor name field, we cannot base workaround on IDs only. Moreover the issue which the above mentioned commit tried to work around is generic not only to VSOL based modules, but rather to all GPON modules based on Realtek RTL8672 and RTL9601C chips. These include at least the following GPON modules: * V-SOL V2801F * C-Data FD511GX-RM0 * OPTON GP801R * BAUDCOM BD-1234-SFM * CPGOS03-0490 v2.0 * Ubiquiti U-Fiber Instant * EXOT EGS1 These Realtek chips have broken EEPROM emulator which for N-byte read operation returns just the first byte of EEPROM data, followed by N-1 zeros. Introduce a new function, sfp_id_needs_byte_io(), which detects SFP modules with broken EEPROM emulator based on N-1 zeros and switch to 1 byte EEPROM reading operation. Function sfp_i2c_read() now always uses single byte reading when it is required and when function sfp_hwmon_probe() detects single byte access, it disables registration of hwmon device, because in this case we cannot reliably and atomically read 2 bytes as is required by the standard for retrieving values from diagnostic area. (These Realtek chips are broken in a way that violates SFP standards for diagnostic interface. Kernel in this case simply cannot do anything less of skipping registration of the hwmon interface.) This patch fixes reading of EEPROM content from SFP modules based on Realtek RTL8672 and RTL9601C chips. Diagnostic interface of EEPROM stays broken and cannot be fixed. Fixes: 0d035bed ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround") Co-developed-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
Pali Rohár <pali@kernel.org> Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Russell King authored
[ Upstream commit 0d035bed ] Add a workaround for the detection of VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 GPON module which CarlitoxxPro states needs single byte I2C reads to the EEPROM. Pali Rohár reports that he also has a CarlitoxxPro-based V2801F module, which reports a manufacturer of "OEM". This manufacturer can't be matched as it appears in many different modules, so also match the part number too. Reported-by:
Thomas Schreiber <tschreibe@gmail.com> Reported-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Takashi Iwai authored
commit 26af1772 upstream. There is another MSI board (1462:cc34) that has dual Realtek codecs, and we need to apply the existing quirk for fixing the conflicts of Master control. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=211743 Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210303142346.28182-1-tiwai@suse.de Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Werner Sembach authored
commit 73e7161e upstream. This adds a new SND_PCI_QUIRK(...) and applies it to the Intel NUC 10 devices. This fixes the issue of the devices not having audio input and output on the headset jack because the kernel does not recognize when something is plugged in. The new quirk was inspired by the quirk for the Intel NUC 8 devices, but it turned out that the NUC 10 uses another pin. This information was acquired by black box testing likely pins. Co-developed-by:
Eckhart Mohr <e.mohr@tuxedocomputers.com> Signed-off-by:
Werner Sembach <wse@tuxedocomputers.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210302180414.23194-1-wse@tuxedocomputers.com Signed-off-by:
-
Eckhart Mohr authored
commit 48698c97 upstream. This applies a SND_PCI_QUIRK(...) to the Clevo NH55RZQ barebone. This fixes the issue of the device not recognizing a pluged in microphone. The device has both, a microphone only jack, and a speaker + microphone combo jack. The combo jack already works. The microphone-only jack does not recognize when a device is pluged in without this patch. Signed-off-by:
-
Sakari Ailus authored
commit fb18802a upstream. When an IOCTL with argument size larger than 128 that also used array arguments were handled, two memory allocations were made but alas, only the latter one of them was released. This happened because there was only a single local variable to hold such a temporary allocation. Fix this by adding separate variables to hold the pointers to the temporary allocations. Reported-by:
Arnd Bergmann <arnd@kernel.org> Reported-by: syzbot+1115e79c8df6472c612b@syzkaller.appspotmail.com Fixes: d14e6d76 ("[media] v4l: Add multi-planar ioctl handling code") Cc: stable@vger.kernel.org Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by:
-
Linus Torvalds authored
commit d7fe75cb upstream. The ICANON case is a bit messy, since it has to look for the line ending, and has special code to then suppress line ending characters if they match the __DISABLED_CHAR. So it actually looks up the line ending even past the point where it knows it won't copy it to the result buffer. That said, apart from all those odd legacy N_TTY ICANON cases, the actual "should we continue copying" logic isn't really all that complicated or different from the non-canon case. In fact, the lack of "wait for at least N characters" arguably makes the repeat case slightly simpler. It really just boils down to "there's more of the line to be copied". So add the necessarily trivial logic, and now the N_TTY case will give long result lines even when in canon mode. Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Linus Torvalds authored
commit 15ea8ae8 upstream. With the conversion to do the tty ldisc read operations in small chunks, the n_tty line discipline became noticeably slower for throughput oriented loads, because rather than read things in up to 2kB chunks, it would return at most 64 bytes per read() system call. The cost is mainly all in the "do system calls over and over", not really in the new "copy to an extra kernel buffer". This can be fixed by teaching the n_tty line discipline about the "cookie continuation" model, which the chunking code supports because things like hdlc need to be able to handle packets up to 64kB in size. Doing that doesn't just get us back to the old performace, but to much better performance: my stupid "copy 10MB of data over a pty" test program is now almost twice as fast as it used to be (going down from 0.1s to 0.054s). This is entirely because it now creates maximal chunks (which happens to be "one byte less than one page" due to how we do the circular tty buffers). NOTE! This case only handles the simpler non-icanon case, which is the one where people may care about throughput. I'm going to do the icanon case later too, because while performance isn't a major issue for that, there may be programs that think they'll always get a full line and don't like the 64-byte chunking for that reason. Such programs are arguably buggy (signals etc can cause random partial results from tty reads anyway), and good programs will handle such partial reads, but expecting everybody to write "good programs" has never been a winning policy for the kernel.. Signed-off-by:
-
Linus Torvalds authored
commit 64a69892 upstream. Back when the line disciplines did their own direct user accesses, they had to deal with the data copy possibly failing in the middle. Now that the user copy is done by the tty_io.c code, that failure case no longer exists. Remove the left-over error handling code that cannot trigger. Signed-off-by:
-
Linus Torvalds authored
commit ddc5fda7 upstream. In commit "tty: implement read_iter", I left the read_iter conversion of the hung up tty case alone, because I incorrectly thought it didn't matter. Jiri showed me the errors of my ways, and pointed out the problems with that incomplete conversion. Fix it all up. Reported-by:
Jiri Slaby <jirislaby@kernel.org> Signed-off-by:
-
Linus Torvalds authored
commit e71a8d5c upstream. When I converted the tty_ldisc_ops 'read()' function to take a kernel pointer, I was a bit too aggressive about the ldisc returning EOVERFLOW. Yes, we want to have EOVERFLOW override any partially read data (because the whole point is that the buffer was too small for the whole packet, and we don't want to see partial packets), but it shouldn't override a previous EFAULT. And in fact, it really is just EOVERFLOW that is special and should throw away any partially read data, not "any error". Admittedly EOVERFLOW is currently the only one that can happen for a continuation read - and if the first read iteration returns an error we won't have this issue. So this is more of a technicality, but let's just make the intent very explicit, and re-organize the error handling a bit so that this is all clearer. Reported-by:
-
Ananth N Mavinakayanahalli authored
commit 718aae91 upstream. We currently just percolate the return value from analyze_instr() to the caller of emulate_step(), especially if it is a -1. For one particular case (opcode = 4) for instructions that aren't currently emulated, we are returning 'should not be single-stepped' while we should have returned 0 which says 'did not emulate, may have to single-step'. Fixes: 930d6288 ("powerpc: sstep: Add support for maddhd, maddhdu, maddld instructions") Signed-off-by:
Ananth N Mavinakayanahalli <ananth@linux.ibm.com> Suggested-by:
Michael Ellerman <mpe@ellerman.id.au> Tested-by:
Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Reviewed-by:
Sandipan Das <sandipan@linux.ibm.com> Signed-off-by:
-
Ananth N Mavinakayanahalli authored
commit 8813ff49 upstream. We currently unconditionally try to emulate newer instructions on older Power versions that could cause issues. Gate it. Fixes: 350779a2 ("powerpc: Handle most loads and stores in instruction emulation code") Signed-off-by:
-
Jens Axboe authored
commit caf6912f upstream. We're not factoring in the start of the file for where to write and read the swapfile, which leads to very unfortunate side effects of writing where we should not be... Fixes: dd6bd0d9 ("swap: use bdev_read_page() / bdev_write_page()") Signed-off-by:
Jens Axboe <axboe@kernel.dk> Cc: Anthony Iliopoulos <ailiop@suse.com> Signed-off-by:
-
Souptick Joarder authored
commit cca21000 upstream. Kernel test robot throws below warning -> >> drivers/remoteproc/mtk_scp.c:755:37: warning: unused variable >> 'mt8183_of_data' [-Wunused-const-variable] static const struct mtk_scp_of_data mt8183_of_data = { ^ >> drivers/remoteproc/mtk_scp.c:765:37: warning: unused variable >> 'mt8192_of_data' [-Wunused-const-variable] static const struct mtk_scp_of_data mt8192_of_data = { ^ As suggested by Bjorn, there's no harm in just dropping the of_match_ptr() wrapping of mtk_scp_of_match in the definition of mtk_scp_driver and we avoid this whole problem. Reported-by:
kernel test robot <lkp@intel.com> Suggested-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
Souptick Joarder <jrdr.linux@gmail.com> Link: https://lore.kernel.org/r/1606513855-21130-1-git-send-email-jrdr.linux@gmail.com Signed-off-by:
-
Rokudo Yan authored
commit 23959281 upstream. There exists multiple path may do zram compaction concurrently. 1. auto-compaction triggered during memory reclaim 2. userspace utils write zram<id>/compaction node So, multiple threads may call zs_shrinker_scan/zs_compact concurrently. But pages_compacted is a per zsmalloc pool variable and modification of the variable is not serialized(through under class->lock). There are two issues here: 1. the pages_compacted may not equal to total number of pages freed(due to concurrently add). 2. zs_shrinker_scan may not return the correct number of pages freed(issued by current shrinker). The fix is simple: 1. account the number of pages freed in zs_compact locally. 2. use actomic variable pages_compacted to accumulate total number. Link: https://lkml.kernel.org/r/20210202122235.26885-1-wu-yan@tcl.com Fixes: 860c707d ("zsmalloc: account the number of compacted pages") Signed-off-by:
Rokudo Yan <wu-yan@tcl.com> Cc: Minchan Kim <minchan@kernel.org> Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Juergen Gross authored
commit 88221399 upstream. Since commit 9e2369c0 ("xen: add helpers to allocate unpopulated memory") foreign mappings are using guest physical addresses allocated via ZONE_DEVICE functionality. This will result in problems for the case of no balloon memory hotplug being configured, as the p2m list will only cover the initial memory size of the domain. Any ZONE_DEVICE allocated address will be outside the p2m range and thus a mapping can't be established with that memory address. Fix that by extending the p2m size for that case. At the same time add a check for a to be created mapping to be within the p2m limits in order to detect errors early. While changing a comment, remove some 32-bit leftovers. This is XSA-369. Fixes: 9e2369c0 ("xen: add helpers to allocate unpopulated memory") Cc: <stable@vger.kernel.org> # 5.9 Reported-by:
Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Signed-off-by:
Juergen Gross <jgross@suse.com> Reviewed-by:
Jan Beulich <jbeulich@suse.com> Signed-off-by:
-
Jan Beulich authored
commit 2991397d upstream. Commit 3194a174 ("xen-netback: don't "handle" error by BUG()") dropped respective a BUG_ON() without noticing that with this the variable's value wouldn't be consumed anymore. With gnttab_set_map_op() setting all status fields to a non-zero value, in case of an error no slot should have a status of GNTST_okay (zero). This is part of XSA-367. Cc: <stable@vger.kernel.org> Reported-by:
-
Jan Beulich authored
commit 8310b77b upstream. Bailing immediately from set_foreign_p2m_mapping() upon a p2m updating error leaves the full batch in an ambiguous state as far as the caller is concerned. Instead flags respective slots as bad, unmapping what was mapped there right away. HYPERVISOR_grant_table_op()'s return value and the individual unmap slots' status fields get used only for a one-time - there's not much we can do in case of a failure. Note that there's no GNTST_enomem or alike, so GNTST_general_error gets used. The map ops' handle fields get overwritten just to be on the safe side. This is part of XSA-367. Cc: <stable@vger.kernel.org> Signed-off-by:
-
Chris Leech authored
commit f9dbdf97 upstream. Open-iSCSI sends passthrough PDUs over netlink, but the kernel should be verifying that the provided PDU header and data lengths fall within the netlink message to prevent accessing beyond that in memory. Cc: stable@vger.kernel.org Reported-by:
Adam Nichols <adam@grimm-co.com> Reviewed-by:
Lee Duncan <lduncan@suse.com> Reviewed-by:
Mike Christie <michael.christie@oracle.com> Signed-off-by:
Chris Leech <cleech@redhat.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Chris Leech authored
commit ec98ea70 upstream. As the iSCSI parameters are exported back through sysfs, it should be enforcing that they never are more than PAGE_SIZE (which should be more than enough) before accepting updates through netlink. Change all iSCSI sysfs attributes to use sysfs_emit(). Cc: stable@vger.kernel.org Reported-by:
-
Lee Duncan authored
commit 688e8128 upstream. Protect the iSCSI transport handle, available in sysfs, by requiring CAP_SYS_ADMIN to read it. Also protect the netlink socket by restricting reception of messages to ones sent with CAP_SYS_ADMIN. This disables normal users from being able to end arbitrary iSCSI sessions. Cc: stable@vger.kernel.org Reported-by:
-
Hans de Goede authored
[ Upstream commit c58947af ] The Acer One S1002 tablet is using an analog mic on IN1 and has its jack-detect connected to JD2_IN4N, instead of using the default IN3 for its internal mic and JD1_IN4P for jack-detect. Note it is also using AIF2 instead of AIF1 which is somewhat unusual, this is correctly advertised in the ACPI CHAN package, so the speakers do work without the quirk. Add a quirk for the mic and jack-detect settings. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20210216213555.36555-5-hdegoede@redhat.com Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Hans de Goede authored
[ Upstream commit df8359c5 ] Add a DMI quirk for the Jumper EZpad 7 tablet, this tablet has a jack-detect switch which reads 1/high when a jack is inserted, rather then using the standard active-low setup which most jack-detect switches use. All other settings are using the defaults. Add a DMI-quirk setting the defaults + the BYT_RT5651_JD_NOT_INV flags for this. Signed-off-by:
-
Hans de Goede authored
[ Upstream commit e1317cc9 ] The Voyo Winpad A15 tablet uses a Bay Trail (non CR) SoC, so it is using SSP2 (AIF1) and it mostly works with the defaults. But instead of using DMIC1 it is using an analog mic on IN1, add a quirk for this. Signed-off-by:
-
Hans de Goede authored
[ Upstream commit bdea43fc ] The Estar Beauty HD MID 7316R tablet almost fully works with out default settings. The only problem is that it has only 1 speaker so any sounds only playing on the right channel get lost. Add a quirk for this model using the default settings + MONO_SPEAKER. Signed-off-by:
-
Juri Lelli authored
[ Upstream commit 156ec6f4 ] Hung tasks and RCU stall cases were reported on systems which were not 100% busy. Investigation of such unexpected cases (no sign of potential starvation caused by tasks hogging the system) pointed out that the periodic sched tick timer wasn't serviced anymore after a certain point and that caused all machinery that depends on it (timers, RCU, etc.) to stop working as well. This issues was however only reproducible if HRTICK was enabled. Looking at core dumps it was found that the rbtree of the hrtimer base used also for the hrtick was corrupted (i.e. next as seen from the base root and actual leftmost obtained by traversing the tree are different). Same base is also used for periodic tick hrtimer, which might get "lost" if the rbtree gets corrupted. Much alike what described in commit 1f71addd ("tick/sched: Do not mess with an enqueued hrtimer") there is a race window between hrtimer_set_expires() in hrtick_start and hrtimer_start_expires() in __hrtick_restart() in which the former might be operating on an already queued hrtick hrtimer, which might lead to corruption of the base. Use hrtick_start() (which removes the timer before enqueuing it back) to ensure hrtick hrtimer reprogramming is entirely guarded by the base lock, so that no race conditions can occur. Signed-off-by:
Juri Lelli <juri.lelli@redhat.com> Signed-off-by:
Luis Claudio R. Goncalves <lgoncalv@redhat.com> Signed-off-by:
Daniel Bristot de Oliveira <bristot@redhat.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by:
Ingo Molnar <mingo@kernel.org> Link: https://lkml.kernel.org/r/20210208073554.14629-2-juri.lelli@redhat.com Signed-off-by:
-
John David Anglin authored
[ Upstream commit 31680c1d ] Bump 64-bit IRQ stack size to 64 KB. I had a kernel IRQ stack overflow on the mx3210 debian buildd machine. This patch increases the 64-bit IRQ stack size to 64 KB. The 64-bit stack size needs to be larger than the 32-bit stack size since registers are twice as big. Signed-off-by:
John David Anglin <dave.anglin@bell.net> Signed-off-by:
Helge Deller <deller@gmx.de> Signed-off-by:
-
Rander Wang authored
[ Upstream commit f88dcb9b ] Current driver create DMIC dai based on quirk for each platforms, so we need to add quirk for new platforms. Now driver reports DMIC number to machine driver and machine driver can create DMIC dai based on this information. The old check is reserved for some platforms may be failed to set the DMIC number in BIOS. Reviewed-by:
Bard Liao <bard.liao@intel.com> Signed-off-by:
Rander Wang <rander.wang@intel.com> Signed-off-by:
-
Pierre-Louis Bossart authored
[ Upstream commit 8caf37e2 ] Use the same style for all quirks to avoid misses and errors Signed-off-by:
Guennadi Liakhovetski <guennadi.liakhovetski@intel.com> Reviewed-by:
Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20210208233336.59449-3-pierre-louis.bossart@linux.intel.com Signed-off-by:
-
Jim Mattson authored
[ Upstream commit b3c3361f ] Cascade Lake Xeon parts have the same model number as Skylake Xeon parts, so they are tagged with the intel_pebs_isolation quirk. However, as with Skylake Xeon H0 stepping parts, the PEBS isolation issue is fixed in all microcode versions. Add the Cascade Lake Xeon steppings (5, 6, and 7) to the isolation_ucodes[] table so that these parts benefit from Andi's optimization in commit 9b545c04 ("perf/x86/kvm: Avoid unnecessary work in guest filtering"). Signed-off-by:
Jim Mattson <jmattson@google.com> Signed-off-by:
Andi Kleen <ak@linux.intel.com> Link: https://lkml.kernel.org/r/20210205191324.2889006-1-jmattson@google.com Signed-off-by:
-
Josef Bacik authored
[ Upstream commit 4f4317c1 ] While doing error injection I would sometimes get a corrupt file system. This is because I was injecting errors at btrfs_search_slot, but would only do it one time per stack. This uncovered a problem in commit_fs_roots, where if we get an error we would just break. However we're in a nested loop, the first loop being a loop to find all the dirty fs roots, and then subsequent root updates would succeed clearing the error value. This isn't likely to happen in real scenarios, however we could potentially get a random ENOMEM once and then not again, and we'd end up with a corrupted file system. Fix this by moving the error checking around a bit to the main loop, as this is the only place where something will fail, and return the error as soon as it occurs. With this patch my reproducer no longer corrupts the file system. Signed-off-by:
Josef Bacik <josef@toxicpanda.com> Reviewed-by:
David Sterba <dsterba@suse.com> Signed-off-by:
-
Hans de Goede authored
[ Upstream commit 8ade6d8b ] Some Bay Trail systems: 1. Use a non CR version of the Bay Trail SoC 2. Contain at least 6 interrupt resources so that the platform_get_resource(pdev, IORESOURCE_IRQ, 5) check to workaround non CR systems which list their IPC IRQ at index 0 despite being non CR does not work 3. Despite 1. and 2. still have their IPC IRQ at index 0 rather then 5 Add a DMI quirk table to check for the few known models with this issue, so that the right IPC IRQ index is used on these systems. Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by:
-
Chao Leng authored
[ Upstream commit 70a99574 ] If reconnect failed after start io queues, the queues will be unquiesced and new requests continue to be delivered. Reconnection error handling process directly free queues without cancel suspend requests. The suppend request will time out, and then crash due to use the queue after free. Add sync queues and cancel suppend requests for reconnection error handling. Signed-off-by:
Chao Leng <lengchao@huawei.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Chao Leng authored
[ Upstream commit 958dc1d3 ] A crash happens when inject failed reconnection. If reconnect failed after start io queues, the queues will be unquiesced and new requests continue to be delivered. Reconnection error handling process directly free queues without cancel suspend requests. The suppend request will time out, and then crash due to use the queue after free. Add sync queues and cancel suppend requests for reconnection error handling. Signed-off-by:
-
Chao Leng authored
[ Upstream commit 25479069 ] Add nvme_cancel_tagset and nvme_cancel_admin_tagset for tear down and reconnection error handling. Signed-off-by:
-
Chao Yu authored
[ Upstream commit 46085f37 ] fsstress + fault injection test case reports a warning message as below: WARNING: CPU: 13 PID: 6226 at fs/inode.c:361 inc_nlink+0x32/0x40 Call Trace: f2fs_init_inode_metadata+0x25c/0x4a0 [f2fs] f2fs_add_inline_entry+0x153/0x3b0 [f2fs] f2fs_add_dentry+0x75/0x80 [f2fs] f2fs_do_add_link+0x108/0x160 [f2fs] f2fs_rename2+0x6ab/0x14f0 [f2fs] vfs_rename+0x70c/0x940 do_renameat2+0x4d8/0x4f0 __x64_sys_renameat2+0x4b/0x60 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Following race case can cause this: Thread A Kworker - f2fs_rename - f2fs_create_whiteout - __f2fs_tmpfile - f2fs_i_links_write - f2fs_mark_inode_dirty_sync - mark_inode_dirty_sync - writeback_single_inode - __writeback_single_inode - spin_lock(&inode->i_lock) - inode->i_state |= I_LINKABLE - inode->i_state &= ~dirty - spin_unlock(&inode->i_lock) - f2fs_add_link - f2fs_do_add_link - f2fs_add_dentry - f2fs_add_inline_entry - f2fs_init_inode_metadata - f2fs_i_links_write - inc_nlink - WARN_ON(!(inode->i_state & I_LINKABLE)) Fix to add i_lock to avoid i_state update race condition. Signed-off-by:
Chao Yu <yuchao0@huawei.com> Signed-off-by:
Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by:
-
Jaegeuk Kim authored
[ Upstream commit 632faca7 ] If we have large section/zone, unallocated segment makes them corrupted. E.g., - Pinned file: -1 119304647 119304647 - ATGC data: -1 119304647 119304647 Reviewed-by:
-
Ricardo Ribalda authored
[ Upstream commit 7532dad6 ] Avoid an underflow while calculating the number of inputs for entities with zero pads. Signed-off-by:
Ricardo Ribalda <ribalda@chromium.org> Signed-off-by:
-
