aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2022-02-26serial: 8250: Fix race condition in RTS-after-send handlingUwe Kleine-König1-0/+12
Set em485->active_timer = NULL isn't always enough to take out the stop timer. While there is a check that it acts in the right state (i.e. waiting for RTS-after-send to pass after sending some chars) but the following might happen: - CPU1: some chars send, shifter becomes empty, stop tx timer armed - CPU0: more chars send before RTS-after-send expired - CPU0: shifter empty irq, port lock taken - CPU1: tx timer triggers, waits for port lock - CPU0: em485->active_timer = &em485->stop_tx_timer, hrtimer_start(), releases lock() - CPU1: get lock, see em485->active_timer == &em485->stop_tx_timer, tear down RTS too early This fix bases on research done by Steffen Trumtrar. Fixes: b86f86e8e7c5 ("serial: 8250: fix potential deadlock in rs485-mode") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20220215160236.344236-1-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-26tty: serial: meson: Added S4 SOC compatibilityYu Tu1-0/+4
Make UART driver compatible with S4 SOC UART. Signed-off-by: Yu Tu <yu.tu@amlogic.com> Link: https://lore.kernel.org/r/20220225073922.3947-7-yu.tu@amlogic.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-26tty: serial: meson: The system stuck when you run the stty command on the console to change the baud rateYu Tu1-0/+5
Start the console and run the following commands in turn: stty -F /dev/ttyAML0 115200 and stty -F /dev/ttyAML0 921600. The system will stuck. Signed-off-by: Yu Tu <yu.tu@amlogic.com> Link: https://lore.kernel.org/r/20220225073922.3947-6-yu.tu@amlogic.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-26tty: serial: meson: Make some bit of the REG5 register writableYu Tu1-2/+2
Make the internal clock source mux and divider writeable, allowing the uart to deviate from the settings intially applied by the ROMCode and using the most appropriate clocks. Signed-off-by: Yu Tu <yu.tu@amlogic.com> Link: https://lore.kernel.org/r/20220225073922.3947-5-yu.tu@amlogic.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-26tty: serial: meson: Describes the calculation of the UART baud rate clock using a clock frameYu Tu1-49/+139
Using the common Clock code to describe the UART baud rate clock makes it easier for the UART driver to be compatible with the baud rate requirements of the UART IP on different meson chips. Signed-off-by: Yu Tu <yu.tu@amlogic.com> Link: https://lore.kernel.org/r/20220225073922.3947-4-yu.tu@amlogic.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-26tty: serial: meson: Use devm_ioremap_resource to get register mapped memoryYu Tu1-9/+1
Replace devm_request_mem_region and devm_ioremap with devm_ioremap_resource to make the code cleaner. Reviewed-by: Jiri Slaby <jirislaby@kernel.org> Signed-off-by: Yu Tu <yu.tu@amlogic.com> Link: https://lore.kernel.org/r/20220225073922.3947-3-yu.tu@amlogic.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-26tty: serial: meson: Move request the register region to probeYu Tu1-18/+14
This simplifies resetting the UART controller during probe and will make it easier to integrate the common clock code which will require the registers at probe time as well. Reviewed-by: Jiri Slaby <jirislaby@kernel.org> Signed-off-by: Yu Tu <yu.tu@amlogic.com> Link: https://lore.kernel.org/r/20220225073922.3947-2-yu.tu@amlogic.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-25drm/i915: apply PM_EARLY for non-GTT mappable objectsMatthew Auld1-0/+11
On DG2 we allow objects that are smaller than the min_page_size, under the premise that these are never mapped by the GTT, like with the paging structures. Currently the suspend-resume path will try to map such objects through the migration vm, which hits: [ 560.529217] kernel BUG at drivers/gpu/drm/i915/gt/intel_migrate.c:431! [ 560.536081] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 560.541629] CPU: 4 PID: 2062 Comm: rtcwake Tainted: G W 5.17.0-rc5-demarchi+ #175 [ 560.550716] Hardware name: Intel Corporation CoffeeLake Client Platform/CoffeeLake S UDIMM RVP, BIOS CNLSFWR1.R00.X220.B00.2103302221 03/30/2021 [ 560.563627] RIP: 0010:emit_pte+0x2e7/0x380 [i915] [ 560.568665] Code: ee 02 48 89 69 04 83 c6 05 83 c0 05 39 f0 0f 4f c6 48 8b 73 08 39 d0 0f 4f c2 44 89 f2 4c 8d 4a ff 49 85 f1 0f 84 62 fe ff ff <0f> 0b 48 c7 03 00 00 00 00 4d 89 c6 8b 01 48 29 ce 48 8d 57 0c 48 [ 560.587691] RSP: 0018:ffffc9000104f8a0 EFLAGS: 00010206 [ 560.592906] RAX: 0000000000000040 RBX: ffffc9000104f908 RCX: ffffc900025114d0 [ 560.600024] RDX: 0000000000010000 RSI: 00000003f9fe2000 RDI: ffffc900025114dc [ 560.607458] RBP: 0000000001840000 R08: ffff88810f335540 R09: 000000000000ffff [ 560.614865] R10: 000000000000081b R11: 0000000000000001 R12: 000000000000081b [ 560.622300] R13: 0000000000000000 R14: 0000000000010000 R15: ffff888107c3e240 [ 560.629716] FS: 00007f5b7c086580(0000) GS:ffff88846dc00000(0000) knlGS:0000000000000000 [ 560.638090] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 560.644132] CR2: 00007f3ab0a133a8 CR3: 000000010a43e003 CR4: 00000000003706e0 [ 560.651590] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 560.659002] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 560.666438] Call Trace: [ 560.668885] <TASK> [ 560.670983] intel_context_migrate_copy+0x1b1/0x4c0 [i915] [ 560.676794] __i915_ttm_move+0x628/0x790 [i915] [ 560.681704] ? dma_resv_iter_next+0x8f/0xb0 [ 560.686223] ? dma_resv_iter_first+0xe5/0x140 [ 560.690894] ? i915_deps_add_resv+0x4b/0x110 [i915] [ 560.696147] ? dma_resv_reserve_shared+0x161/0x310 [ 560.701228] i915_gem_obj_copy_ttm+0x10f/0x220 [i915] [ 560.706650] i915_ttm_backup+0x191/0x2f0 [i915] [ 560.711558] i915_gem_process_region+0x266/0x3b0 [i915] [ 560.717153] ? verify_cpu+0xf0/0x100 [ 560.721040] ? pci_pm_resume_early+0x20/0x20 [ 560.725603] i915_ttm_backup_region+0x47/0x70 [i915] [ 560.730927] i915_gem_backup_suspend+0x141/0x170 [i91 For now let's just force the memcpy path for such objects during suspend-resume. Fixes: 00e27ad85bc9 ("drm/i915/migrate: add acceleration support for DG2") Reported-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220225103443.225228-1-matthew.auld@intel.com
2022-02-25Merge branch 'small-fixes-for-mctp'Jakub Kicinski2-7/+8
Matt Johnston says: ==================== Small fixes for MCTP This series has 3 fixes for MCTP. ==================== Link: https://lore.kernel.org/r/20220225053938.643605-1-matt@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-02-25mctp i2c: Fix hard head TX bounds length checkMatt Johnston1-2/+3
We should be testing the length before fitting into the u8 byte_count. This is just a sanity check, the MCTP stack should have limited to MTU which is checked, and we check consistency later in mctp_i2c_xmit(). Found by Smatch mctp_i2c_header_create() warn: impossible condition '(hdr->byte_count > 255) => (0-255 > 255)' Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-02-25mctp i2c: Fix potential use-after-freeMatt Johnston1-1/+1
The skb is handed off to netif_rx() which may free it. Found by Smatch. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-02-25mctp: Avoid warning if unregister notifies twiceMatt Johnston1-4/+4
Previously if an unregister notify handler ran twice (waiting for netdev to be released) it would print a warning in mctp_unregister() every subsequent time the unregister notify occured. Instead we only need to worry about the case where a mctp_ptr is set on an unknown device type. Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-02-25stmmac: intel: Enable 2.5Gbps for Intel AlderLake-SWong Vee Khee1-2/+1
Intel AlderLake-S platform is capable of running on 2.5GBps link speed. This patch enables 2.5Gbps link speed on AlderLake-S platform. Signed-off-by: Wong Vee Khee <vee.khee.wong@linux.intel.com> Link: https://lore.kernel.org/r/20220225023325.474242-1-vee.khee.wong@linux.intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-02-25net: dsa: qca8k: return with -EINVAL on invalid portColin Ian King1-0/+1
Currently an invalid port throws a WARN_ON warning however invalid uninitialized values in reg and cpu_port_index are being used later on. Fix this by returning -EINVAL for an invalid port value. Addresses clang-scan warnings: drivers/net/dsa/qca8k.c:1981:3: warning: 2nd function call argument is an uninitialized value [core.CallAndMessage] drivers/net/dsa/qca8k.c:1999:9: warning: 2nd function call argument is an uninitialized value [core.CallAndMessage] Fixes: 7544b3ff745b ("net: dsa: qca8k: move pcs configuration") Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Link: https://lore.kernel.org/r/20220224220557.147075-1-colin.i.king@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-02-25ext4: add extra check in ext4_mb_mark_bb() to prevent against possible corruptionRitesh Harjani1-0/+8
This patch adds an extra checks in ext4_mb_mark_bb() function to make sure we mark & report error if we were to mark/clear any of the critical FS metadata specific bitmaps (&bail out) to prevent from any accidental corruption. Suggested-by: Jan Kara <jack@suse.cz> Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/53cbb6f2573db162a57f935365050d8b1df202ee.1644992610.git.riteshh@linux.ibm.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2022-02-25ext4: add strict range checks while freeing blocksRitesh Harjani1-13/+3
Currently ext4_mb_clear_bb() & ext4_group_add_blocks() only checks whether the given block ranges (which is to be freed) belongs to any FS metadata blocks or not, of the block's respective block group. But to detect any FS error early, it is better to add more strict checkings in those functions which checks whether the given blocks belongs to any critical FS metadata or not within system-zone. Suggested-by: Jan Kara <jack@suse.cz> Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/ddd9143d064774e32d6364a99667817c6e8bfdc0.1644992610.git.riteshh@linux.ibm.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2022-02-25ext4: add ext4_sb_block_valid() refactored out of ext4_inode_block_valid()Ritesh Harjani2-9/+20
This API will be needed at places where we don't have an inode for e.g. while freeing blocks in ext4_group_add_blocks() Suggested-by: Jan Kara <jack@suse.cz> Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com> Link: https://lore.kernel.org/r/dd34a236543ad5ae7123eeebe0cb69e6bdd44f34.1644992610.git.riteshh@linux.ibm.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2022-02-25ext4: no need to test for block bitmap bits in ext4_mb_mark_bb()Ritesh Harjani1-1/+1
We don't need the return value of mb_test_and_clear_bits() in ext4_mb_mark_bb() So simply use mb_clear_bits() instead. Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/a971935306dafb124da0193c7dad1aa485210b62.1644992610.git.riteshh@linux.ibm.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2022-02-25ext4: rename ext4_set_bits to mb_set_bitsRitesh Harjani3-10/+10
ext4_set_bits() should actually be mb_set_bits() for uniform API naming convention. This is via below cmd - grep -nr "ext4_set_bits" fs/ext4/ | cut -d ":" -f 1 | xargs sed -i 's/ext4_set_bits/mb_set_bits/g' Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/f1f6ece1405b76a7a987e9145d1adfaf71e30695.1644992610.git.riteshh@linux.ibm.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2022-02-25ext4: use in_range() for range checking in ext4_fc_replay_check_excludedRitesh Harjani1-2/+2
Instead of open coding it, use in_range() function instead. Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/8e5526ef14150778871ac7c937c8993c6a09cd3e.1644992610.git.riteshh@linux.ibm.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2022-02-25ext4: refactor ext4_free_blocks() to pull out ext4_mb_clear_bb()Ritesh Harjani1-78/+102
ext4_free_blocks() function became too long and confusing, this patch just pulls out the ext4_mb_clear_bb() function logic from it which clears the block bitmap and frees it. No functionality change in this patch Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/22c30fbb26ba409cf8aa5f0c7912970272c459e8.1644992610.git.riteshh@linux.ibm.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2022-02-25ext4: fix ext4_mb_mark_bb() with flex_bg with fast_commitRitesh Harjani1-54/+75
In case of flex_bg feature (which is by default enabled), extents for any given inode might span across blocks from two different block group. ext4_mb_mark_bb() only reads the buffer_head of block bitmap once for the starting block group, but it fails to read it again when the extent length boundary overflows to another block group. Then in this below loop it accesses memory beyond the block group bitmap buffer_head and results into a data abort. for (i = 0; i < clen; i++) if (!mb_test_bit(blkoff + i, bitmap_bh->b_data) == !state) already++; This patch adds this functionality for checking block group boundary in ext4_mb_mark_bb() and update the buffer_head(bitmap_bh) for every different block group. w/o this patch, I was easily able to hit a data access abort using Power platform. <...> [ 74.327662] EXT4-fs error (device loop3): ext4_mb_generate_buddy:1141: group 11, block bitmap and bg descriptor inconsistent: 21248 vs 23294 free clusters [ 74.533214] EXT4-fs (loop3): shut down requested (2) [ 74.536705] Aborting journal on device loop3-8. [ 74.702705] BUG: Unable to handle kernel data access on read at 0xc00000005e980000 [ 74.703727] Faulting instruction address: 0xc0000000007bffb8 cpu 0xd: Vector: 300 (Data Access) at [c000000015db7060] pc: c0000000007bffb8: ext4_mb_mark_bb+0x198/0x5a0 lr: c0000000007bfeec: ext4_mb_mark_bb+0xcc/0x5a0 sp: c000000015db7300 msr: 800000000280b033 dar: c00000005e980000 dsisr: 40000000 current = 0xc000000027af6880 paca = 0xc00000003ffd5200 irqmask: 0x03 irq_happened: 0x01 pid = 5167, comm = mount <...> enter ? for help [c000000015db7380] c000000000782708 ext4_ext_clear_bb+0x378/0x410 [c000000015db7400] c000000000813f14 ext4_fc_replay+0x1794/0x2000 [c000000015db7580] c000000000833f7c do_one_pass+0xe9c/0x12a0 [c000000015db7710] c000000000834504 jbd2_journal_recover+0x184/0x2d0 [c000000015db77c0] c000000000841398 jbd2_journal_load+0x188/0x4a0 [c000000015db7880] c000000000804de8 ext4_fill_super+0x2638/0x3e10 [c000000015db7a40] c0000000005f8404 get_tree_bdev+0x2b4/0x350 [c000000015db7ae0] c0000000007ef058 ext4_get_tree+0x28/0x40 [c000000015db7b00] c0000000005f6344 vfs_get_tree+0x44/0x100 [c000000015db7b70] c00000000063c408 path_mount+0xdd8/0xe70 [c000000015db7c40] c00000000063c8f0 sys_mount+0x450/0x550 [c000000015db7d50] c000000000035770 system_call_exception+0x4a0/0x4e0 [c000000015db7e10] c00000000000c74c system_call_common+0xec/0x250 Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/2609bc8f66fc15870616ee416a18a3d392a209c4.1644992609.git.riteshh@linux.ibm.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2022-02-25ext4: correct cluster len and clusters changed accounting in ext4_mb_mark_bbRitesh Harjani1-7/+12
ext4_mb_mark_bb() currently wrongly calculates cluster len (clen) and flex_group->free_clusters. This patch fixes that. Identified based on code review of ext4_mb_mark_bb() function. Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/a0b035d536bafa88110b74456853774b64c8ac40.1644992609.git.riteshh@linux.ibm.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2022-02-25jbd2: remove CONFIG_JBD2_DEBUG to update t_max_waitRitesh Harjani1-4/+3
CONFIG_JBD2_DEBUG and jbd2_journal_enable_debug knobs were added in update_t_max_wait(), since earlier it used to take a spinlock for updating t_max_wait, which could cause a bottleneck while starting a txn (start_this_handle()). Since in previous patch, we have killed t_handle_lock completely, we could get rid of this debug config and knob to let t_max_wait be updated by default again. Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/ad7319a601fd501079310747ce87d908e0944763.1644992076.git.riteshh@linux.ibm.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2022-02-25jbd2: kill t_handle_lock transaction spinlockRitesh Harjani2-22/+9
This patch kills t_handle_lock transaction spinlock completely from jbd2. To explain the reasoning, currently there were three sites at which this spinlock was used. 1. jbd2_journal_wait_updates() a. Based on careful code review it can be seen that, we don't need this lock here. This is since we wait for any currently ongoing updates based on a atomic variable t_updates. And we anyway don't take any t_handle_lock while in stop_this_handle(). i.e. write_lock(&journal->j_state_lock() jbd2_journal_wait_updates() stop_this_handle() while (atomic_read(txn->t_updates) { | DEFINE_WAIT(wait); | prepare_to_wait(); | if (atomic_read(txn->t_updates) if (atomic_dec_and_test(txn->t_updates)) write_unlock(&journal->j_state_lock); schedule(); wake_up() write_lock(&journal->j_state_lock); finish_wait(); } txn->t_state = T_COMMIT write_unlock(&journal->j_state_lock); b. Also note that between atomic_inc(&txn->t_updates) in start_this_handle() and jbd2_journal_wait_updates(), the synchronization happens via read_lock(journal->j_state_lock) in start_this_handle(); 2. jbd2_journal_extend() a. jbd2_journal_extend() is called with the handle of each process from task_struct. So no lock required in updating member fields of handle_t b. For member fields of h_transaction, all updates happens only via atomic APIs (which is also within read_lock()). So, no need of this transaction spinlock. 3. update_t_max_wait() Based on Jan suggestion, this can be carefully removed using atomic cmpxchg API. Note that there can be several processes which are waiting for a new transaction to be allocated and started. For doing this only one process will succeed in taking write_lock() and allocating a new txn. After that all of the process will be updating the t_max_wait (max transaction wait time). This can be done via below method w/o taking any locks using atomic cmpxchg. For more details refer [1] new = get_new_val(); old = READ_ONCE(ptr->max_val); while (old < new) old = cmpxchg(&ptr->max_val, old, new); [1]: https://lwn.net/Articles/849237/ Suggested-by: Jan Kara <jack@suse.cz> Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/d89e599658b4a1f3893a48c6feded200073037fc.1644992076.git.riteshh@linux.ibm.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2022-02-25jbd2: fix use-after-free of transaction_t raceRitesh Harjani1-16/+25
jbd2_journal_wait_updates() is called with j_state_lock held. But if there is a commit in progress, then this transaction might get committed and freed via jbd2_journal_commit_transaction() -> jbd2_journal_free_transaction(), when we release j_state_lock. So check for journal->j_running_transaction everytime we release and acquire j_state_lock to avoid use-after-free issue. Link: https://lore.kernel.org/r/948c2fed518ae739db6a8f7f83f1d58b504f87d0.1644497105.git.ritesh.list@gmail.com Fixes: 4f98186848707f53 ("jbd2: refactor wait logic for transaction updates into a common function") Cc: stable@kernel.org Reported-and-tested-by: syzbot+afa2ca5171d93e44b348@syzkaller.appspotmail.com Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2022-02-25ext4: fix remount with 'abort' optionLukas Czerner1-8/+21
After commit 6e47a3cc68fc ("ext4: get rid of super block and sbi from handle_mount_ops()") the 'abort' options stopped working. This is because we're using ctx_set_mount_flags() helper that's expecting an argument with the appropriate bit set, but instead got EXT4_MF_FS_ABORTED which is a bit position. ext4_set_mount_flag() is using set_bit() while ctx_set_mount_flags() was using bitwise OR. Create a separate helper ctx_set_mount_flag() to handle setting the mount_flags correctly. While we're at it clean up the EXT4_SET_CTX macros so that we're only creating helpers that we actually use to avoid warnings. Fixes: 6e47a3cc68fc ("ext4: get rid of super block and sbi from handle_mount_ops()") Signed-off-by: Lukas Czerner <lczerner@redhat.com> Cc: Ye Bin <yebin10@huawei.com> Reviewed-by: Eric Sandeen <sandeen@redhat.com> Tested-by: Gabriel Krisman Bertazi <krisman@collabora.com> Link: https://lore.kernel.org/r/20220201131345.77591-1-lczerner@redhat.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2022-02-25xtensa: Implement "current_stack_pointer"Kees Cook4-6/+8
To follow the existing per-arch conventions replace open-coded uses of asm "sp" as "current_stack_pointer". This will let it be used in non-arch places (like HARDENED_USERCOPY). Cc: Chris Zankel <chris@zankel.net> Cc: Marc Zyngier <maz@kernel.org> Cc: linux-xtensa@linux-xtensa.org Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: Max Filippov <jcmvbkbc@gmail.com> Link: https://lore.kernel.org/lkml/CAMo8BfJFJE-n3=AF+pb9_6oF3gzxX7a+7aBrASHjjNX5byqDqw@mail.gmail.com
2022-02-25usercopy: Check valid lifetime via stack depthKees Cook8-2/+36
One of the things that CONFIG_HARDENED_USERCOPY sanity-checks is whether an object that is about to be copied to/from userspace is overlapping the stack at all. If it is, it performs a number of inexpensive bounds checks. One of the finer-grained checks is whether an object crosses stack frames within the stack region. Doing this on x86 with CONFIG_FRAME_POINTER was cheap/easy. Doing it with ORC was deemed too heavy, and was left out (a while ago), leaving the courser whole-stack check. The LKDTM tests USERCOPY_STACK_FRAME_TO and USERCOPY_STACK_FRAME_FROM try to exercise these cross-frame cases to validate the defense is working. They have been failing ever since ORC was added (which was expected). While Muhammad was investigating various LKDTM failures[1], he asked me for additional details on them, and I realized that when exact stack frame boundary checking is not available (i.e. everything except x86 with FRAME_POINTER), it could check if a stack object is at least "current depth valid", in the sense that any object within the stack region but not between start-of-stack and current_stack_pointer should be considered unavailable (i.e. its lifetime is from a call no longer present on the stack). Introduce ARCH_HAS_CURRENT_STACK_POINTER to track which architectures have actually implemented the common global register alias. Additionally report usercopy bounds checking failures with an offset from current_stack_pointer, which may assist with diagnosing failures. The LKDTM USERCOPY_STACK_FRAME_TO and USERCOPY_STACK_FRAME_FROM tests (once slightly adjusted in a separate patch) pass again with this fixed. [1] https://github.com/kernelci/kernelci-project/issues/84 Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: linux-mm@kvack.org Reported-by: Muhammad Usama Anjum <usama.anjum@collabora.com> Signed-off-by: Kees Cook <keescook@chromium.org> --- v1: https://lore.kernel.org/lkml/20220216201449.2087956-1-keescook@chromium.org v2: https://lore.kernel.org/lkml/20220224060342.1855457-1-keescook@chromium.org v3: https://lore.kernel.org/lkml/20220225173345.3358109-1-keescook@chromium.org v4: - improve commit log (akpm)
2022-02-25rtla/osnoise: Fix error message when failing to enable trace instanceDaniel Bristot de Oliveira1-1/+1
When a trace instance creation fails, tools are printing: Could not enable -> osnoiser <- tracer for tracing Print the actual (and correct) name of the tracer it fails to enable. Link: https://lkml.kernel.org/r/53ef0582605af91eca14b19dba9fc9febb95d4f9.1645206561.git.bristot@kernel.org Fixes: b1696371d865 ("rtla: Helper functions for rtla") Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Daniel Bristot de Oliveira <bristot@kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2022-02-25rtla/osnoise: Free params at the exitDaniel Bristot de Oliveira1-0/+1
The variable that stores the parsed command line arguments are not being free()d at the rtla osnoise top exit path. Free params variable before exiting. Link: https://lkml.kernel.org/r/0be31d8259c7c53b98a39769d60cfeecd8421785.1645206561.git.bristot@kernel.org Fixes: 1eceb2fc2ca5 ("rtla/osnoise: Add osnoise top mode") Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Daniel Bristot de Oliveira <bristot@kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2022-02-25rtla/hist: Make -E the short version of --entriesDaniel Bristot de Oliveira4-12/+12
Currently, --entries uses -e as the short version in the hist mode of timerlat and osnoise tools. But as -e is already used to enable events on trace sessions by other tools, thus let's keep it available for the same usage for all rtla tools. Make -E the short version of --entries for hist mode on all tools. Note: rtla was merged in this merge window, so rtla was not released yet. Link: https://lkml.kernel.org/r/5dbf0cbe7364d3a05e708926b41a097c59a02b1e.1645206561.git.bristot@kernel.org Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Daniel Bristot de Oliveira <bristot@kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2022-02-25tracing: Fix selftest config check for function graph start up testChristophe Leroy1-4/+2
CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS is required to test direct tramp. Link: https://lkml.kernel.org/r/bdc7e594e13b0891c1d61bc8d56c94b1890eaed7.1640017960.git.christophe.leroy@csgroup.eu Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2022-02-25tracefs: Set the group ownership in apply_options() not parse_options()Steven Rostedt (Google)1-2/+3
Al Viro brought it to my attention that the dentries may not be filled when the parse_options() is called, causing the call to set_gid() to possibly crash. It should only be called if parse_options() succeeds totally anyway. He suggested the logical place to do the update is in apply_options(). Link: https://lore.kernel.org/all/20220225165219.737025658@goodmis.org/ Link: https://lkml.kernel.org/r/20220225153426.1c4cab6b@gandalf.local.home Cc: stable@vger.kernel.org Acked-by: Al Viro <viro@zeniv.linux.org.uk> Reported-by: Al Viro <viro@zeniv.linux.org.uk> Fixes: 48b27b6b5191 ("tracefs: Set all files to the same group ownership as the mount option") Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2022-02-25clk: Mark clk_core_evict_parent_cache_subtree() 'target' constStephen Boyd1-1/+1
Clarify that the 'target' clk isn't being modified, instead it's being searched for. Mark it const so the function can't modify it. Signed-off-by: Stephen Boyd <sboyd@kernel.org> Link: https://lore.kernel.org/r/20220217220554.2711696-3-sboyd@kernel.org
2022-02-25clk: Mark 'all_lists' as constStephen Boyd1-2/+2
This list array doesn't change at runtime. Mark it const to move to RO memory. Signed-off-by: Stephen Boyd <sboyd@kernel.org> Link: https://lore.kernel.org/r/20220217220554.2711696-2-sboyd@kernel.org
2022-02-25clk: pistachio: Declare mux table as const u32[]Jonathan Neuschäfer1-1/+1
Now that clk_register_mux_table takes a const u32 *, we can declare the mux table as const u32[]. Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Link: https://lore.kernel.org/r/20220205103613.1216218-8-j.neuschaefer@gmx.net Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-02-25clk: qcom: Declare mux table as const u32[]Jonathan Neuschäfer1-1/+1
Now that clk_register_mux_table takes a const u32 *, we can declare the mux tables as const u32[]. Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Link: https://lore.kernel.org/r/20220205103613.1216218-7-j.neuschaefer@gmx.net Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-02-25clk: mmp: Declare mux tables as const u32[]Jonathan Neuschäfer1-2/+2
Now that clk_register_mux_table takes a const u32 *, we can declare the mux tables as const u32[]. Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Link: https://lore.kernel.org/r/20220205103613.1216218-6-j.neuschaefer@gmx.net Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-02-25clk: hisilicon: Remove unnecessary cast of mux table to u32 *Jonathan Neuschäfer1-1/+1
Now that clk_register_mux_table takes a const u32 *, we don't need the cast anymore. Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Link: https://lore.kernel.org/r/20220205103613.1216218-5-j.neuschaefer@gmx.net Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-02-25clk: mux: Declare u32 *table parameter as constJonathan Neuschäfer2-11/+11
The elements of the table are never modified in clk-mux.c. To make this clear to clock drivers, declare the parameter as const u32 *table. Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Link: https://lore.kernel.org/r/20220205103613.1216218-4-j.neuschaefer@gmx.net Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-02-25clk: nxp: Declare mux table parameter as const u32 *Jonathan Neuschäfer1-1/+1
lpc18xx_fill_parent_names's "id" parameter isn't used for writing, so let's make it const. Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Link: https://lore.kernel.org/r/20220205103613.1216218-3-j.neuschaefer@gmx.net Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-02-25clk: nxp: Remove unused variableJonathan Neuschäfer1-2/+1
GCC warns: > ../drivers/clk/nxp/clk-lpc18xx-cgu.c: In function ‘lpc18xx_pll1_recalc_rate’: > ../drivers/clk/nxp/clk-lpc18xx-cgu.c:460:13: warning: variable ‘stat’ set but not used [-Wunused-but-set-variable] > 460 | u32 stat, ctrl; > | ^~~~ Get rid of the (apparently) useless read from the PLL1_STAT register and the declaration of stat. Reported-by: kernel test robot <lkp@intel.com> Fixes: b04e0b8fd5443 ("clk: add lpc18xx cgu clk driver") Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Link: https://lore.kernel.org/r/20220205103613.1216218-2-j.neuschaefer@gmx.net Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-02-25selftests/rtc: continuously read RTC in a loop for 30sMateusz Jończyk2-1/+67
Some problems with reading the RTC time may happen rarely, for example while the RTC is updating. So read the RTC many times to catch these problems. For example, a previous attempt for my commit ea6fa4961aab ("rtc: mc146818-lib: fix RTC presence check") was incorrect and would have triggered this selftest. To avoid the risk of damaging the hardware, wait 11ms before consecutive reads. In rtc_time_to_timestamp I copied values manually instead of casting - just to be on the safe side. The 11ms wait period was chosen so that it is not a divisor of 1000ms. Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Shuah Khan <shuah@kernel.org> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-02-25NFS: Use of mapping_set_error() results in spurious errorsTrond Myklebust1-1/+4
The use of mapping_set_error() in conjunction with calls to filemap_check_errors() is problematic because every error gets reported as either an EIO or an ENOSPC by filemap_check_errors() in functions such as filemap_write_and_wait() or filemap_write_and_wait_range(). In almost all cases, we prefer to use the more nuanced wb errors. Fixes: b8946d7bfb94 ("NFS: Revalidate the file mapping on all fatal writeback errors") Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
2022-02-25NFS: Clean up NFSv4.2 xattrsTrond Myklebust3-12/+18
Add a helper for the xattr mask so that we can get rid of the inlined ifdefs. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
2022-02-25NFS: Remove unnecessary XATTR cache invalidation in nfs_fhget()Trond Myklebust1-2/+0
We should never expect the 'xattr_cache' to be non-null in that case, hence nfs_set_cache_invalid() is just going to optimise it away. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
2022-02-25NFS: NFSv2/v3 clients should never be setting NFS_CAP_XATTRTrond Myklebust2-0/+2
Ensure that we always initialise the 'xattr_support' field in struct nfs_fsinfo, so that nfs_server_set_fsinfo() doesn't declare our NFSv2/v3 client to be capable of supporting the NFSv4.2 xattr protocol by setting the NFS_CAP_XATTR capability. This configuration can cause nfs_do_access() to set access mode bits that are unsupported by the NFSv3 ACCESS call, which may confuse spec-compliant servers. Reported-by: Olga Kornievskaia <kolga@netapp.com> Fixes: b78ef845c35d ("NFSv4.2: query the server for extended attribute support") Cc: stable@vger.kernel.org Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
2022-02-25NFS: Remove unused flag NFS_INO_REVAL_PAGECACHETrond Myklebust3-5/+2
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
2022-02-25NFS: Replace last uses of NFS_INO_REVAL_PAGECACHETrond Myklebust3-19/+15
Now that we have more fine grained attribute revalidation, let's just get rid of NFS_INO_REVAL_PAGECACHE. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.