Re: REGRESSION: lockdep warning triggered by 15b9ce7ecd: virtio_balloon: stay awake while adjusting balloon

On Wed, Jan 10, 2024 at 03:11:01AM -0500, Michael S. Tsirkin wrote: > On Mon, Jan 08, 2024 at 04:50:15PM -0500, Theodore Ts'o wrote: > > Hi, while doing final testing before sending a pull request, I merged > > in linux-next, and commit 5b9ce7ecd7: virtio_balloon: stay awake whil

REGRESSION: lockdep warning triggered by 15b9ce7ecd: virtio_balloon: stay awake while adjusting balloon

Hi, while doing final testing before sending a pull request, I merged in linux-next, and commit 5b9ce7ecd7: virtio_balloon: stay awake while adjusting balloon seems to be causing a lockdep warning (see attached) when running gce-xfstests on a Google Compute Engine e2 VM. I was not able to trigger

Maintainers / Kernel Summit 2021 planning kick-off

[ Feel free to forward this to other Linux kernel mailing lists as appropriate -- Ted ] This year, the Maintainers and Kernel Summit is currently planned to be held in Dublin, Ireland, September 27 -- 29th. Of course, this is subject to change depending on how much progress the world makes

Re: [PATCH v2 3/6] kunit: ext4: adhear to KUNIT formatting standard

On Wed, Apr 14, 2021 at 04:58:06AM -0400, Nico Pache wrote: > Drop 'S' from end of CONFIG_EXT4_KUNIT_TESTS inorder to adhear to the KUNIT > *_KUNIT_TEST config name format. Another spelling nit, that should be "in order". This will break people who have existing .kunitconfig files, but if we are

Re: [PATCH v2 0/6] kunit: Fix formatting of KUNIT tests to meet the standard

On Wed, Apr 14, 2021 at 04:58:03AM -0400, Nico Pache wrote: > There are few instances of KUNIT tests that are not properly defined. > This commit focuses on correcting these issues to match the standard > defined in the Documentation. The word "standard" seems to be over-stating things. The

Re: [PATCH] fs/ext4: prevent the CPU from being 100% occupied in ext4_mb_discard_group_preallocations

On Sun, Apr 18, 2021 at 06:28:34PM +0800, Wen Yang wrote: > The kworker has occupied 100% of the CPU for several days: > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 68086 root 20 0 00 0 R 100.0 0.0 9718:18 kworker/u64:11 > > > > The thread that references this pa

Re: [PATCH 00/13] [RFC] Rust support

On Fri, Apr 16, 2021 at 02:07:49PM +0100, Wedson Almeida Filho wrote: > On Fri, Apr 16, 2021 at 01:24:23PM +0200, Peter Zijlstra wrote: > > On Wed, Apr 14, 2021 at 08:45:51PM +0200, oj...@kernel.org wrote: > > > - Featureful language: sum types, pattern matching, generics, > > > RAII,

Re: [PATCH] ext4: add a configurable parameter to prevent endless loop in ext4_mb_discard_group_p

On Sun, Apr 11, 2021 at 03:45:01AM +0800, Wen Yang wrote: > At this time, some logs are lost. It is suspected that the hard disk itself > is faulty. If you have a kernel crash dump, that means you can extract out the dmesg buffer, correct? Is there any I/O error messages in the kernel log? What

Re: [PATCH 0/8] EXT4: Trivial typo fixes

On Sat, Mar 27, 2021 at 04:00:04PM +0530, Bhaskar Chowdhury wrote: > This patch series fixed few mundane typos in the below specific files. > > Bhaskar Chowdhury (8): > EXT4: migrate.c: Fixed few typos > EXT4: namei.c: Fixed a typo > EXT4: inline.c: A typo fixed > Fix a typo > EXT4:

Re: [PATCH -next] ext4: fix error return code in ext4_fc_perform_commit()

On Thu, Apr 08, 2021 at 03:00:33PM +0800, Xu Yihang wrote: > In case of if not ext4_fc_add_tlv branch, an error return code is missing. > > Fixes: aa75f4d3daae ("ext4: main fast-commit commit path") > Reported-by: Hulk Robot > Signed-off-by: Xu Yihang Thanks, applied.

Re: [PATCH v3] ext4: Fix ext4_error_err save negative errno into superblock

On Tue, Apr 06, 2021 at 10:53:31AM +0800, Ye Bin wrote: > As write_mmp_block return 1 when buffer isn't uptodate, return -EIO is > more appropriate. > > Fixes: 54d3adbc29f0 ("ext4: save all error info in save_error_info() and drop > ext4_set_errno()") > Reported-by: Liu Zhi Qiang >

Re: [RFC] ext4: Fix fs can't panic when abort by user

On Fri, Apr 09, 2021 at 05:28:54PM -0400, Theodore Ts'o wrote: > I'll apply the patch with a modified commit description to warn of > this particular change in behavior. Applied with the following commit description: ext4: always panic when errors=panic is specified Before

Re: [RFC] ext4: Fix fs can't panic when abort by user

On Thu, Apr 01, 2021 at 04:19:03PM +0800, Ye Bin wrote: > Test steps: > 1. mount /dev/sda -o errors=panic test > 2. mount /dev/sda -o remount,ro test > 3. mount /dev/sda -o remount,abort test > > Before 014c9caa29d3 not been merged there will trigger panic. But > 014c9caa29d3 change this

Re: [PATCH] ext4: Delete redundant uptodate check for buffer

calling set_buffer_uptodate and > > delete it. > > > > Cc: "Theodore Ts'o" > > Cc: Andreas Dilger > > Signed-off-by: Yang Guo > > Signed-off-by: Shaokun Zhang > > --- > > fs/ext4/inode.c | 6 ++ > > 1 file changed, 2 insertions(+), 4 de

Re: [PATCH 03/17] bit_spinlock: Prepare for split_locks

On Fri, Apr 09, 2021 at 03:35:55PM +0100, Matthew Wilcox wrote: > > This changes the function signature for bit_spin_lock(), if I'm > > reading this correctly. Hence, this is going to break git > > bisectability; was this patch series separated out for easy of review, > > and you were planning on

Re: [PATCH 03/17] bit_spinlock: Prepare for split_locks

On Fri, Apr 09, 2021 at 03:51:17AM +0100, Matthew Wilcox (Oracle) wrote: > Make bit_spin_lock() and variants variadic to help with the transition. > The split_lock parameter will become mandatory at the end of the series. > Also add bit_spin_lock_nested() and bit_spin_unlock_assign() which will >

Re: [PATCH] ext4: Fix bug on in ext4_es_cache_extent as ext4_split_extent_at failed

On Wed, Apr 07, 2021 at 09:41:57AM +0800, yebin wrote: > > > If call ext4_ext_insert_extent failed but new extent already inserted, we > > > just > > > update "ex->ee_len = orig_ex.ee_len", this will lead to extent overlap, > > > then > > > cause bug on when cache extent. > > How did this happen

Re: KCSAN: data-race in __jbd2_journal_file_buffer / jbd2_journal_dirty_metadata

On Tue, Apr 06, 2021 at 02:32:33PM +0200, Jan Kara wrote: > And the comment explains, why we do this unreliable check. Again, if we > wanted to silence KCSAN, we could use data_race() macro but AFAIU Ted isn't > very fond of that annotation. I'm not fond of the data_race macro, but I like bogus

Re: [PATCH] ext4: Fix bug on in ext4_es_cache_extent as ext4_split_extent_at failed

On Thu, Mar 25, 2021 at 10:29:25AM +0800, Ye Bin wrote: > We got follow bug_on: > [130747.323114] kernel BUG at fs/ext4/extents_status.c:762! > [130747.323117] Internal error: Oops - BUG: 0 [#1] SMP > .. > [130747.334329] Call trace: > [130747.334553] ext4_es_cache_extent+0x150/0x168 [ext4] >

Re: [PATCH] jbd2: avoid -Wempty-body warnings

On Tue, Mar 30, 2021 at 05:15:33PM +0200, Jan Kara wrote: > On Mon 22-03-21 11:21:38, Arnd Bergmann wrote: > > From: Arnd Bergmann > > > > Building with 'make W=1' shows a harmless -Wempty-body warning: > > > > fs/jbd2/recovery.c: In function 'fc_do_one_pass': > > fs/jbd2/recovery.c:267:75:

Re: [PATCH v2 2/2] ext4: Optimize match for casefolded encrypted dirs

On Fri, Mar 19, 2021 at 07:34:14AM +, Daniel Rosenberg wrote: > Matching names with casefolded encrypting directories requires > decrypting entries to confirm case since we are case preserving. We can > avoid needing to decrypt if our hash values don't match. > > Signed-off-by: Daniel

Re: [PATCH v2 1/2] ext4: Handle casefolding with encryption

On Fri, Mar 19, 2021 at 07:34:13AM +, Daniel Rosenberg wrote: > This adds support for encryption with casefolding. > > Since the name on disk is case preserving, and also encrypted, we can no > longer just recompute the hash on the fly. Additionally, to avoid > leaking extra information from

Re: [PATCH v3] Updated locking documentation for transaction_t

On Thu, Feb 11, 2021 at 06:14:10PM +0100, Alexander Lochmann wrote: > Some members of transaction_t are allowed to be read without > any lock being held if accessed from the correct context. > We used LockDoc's findings to determine those members. > Each member of them is marked with a short

Re: [PATCH v2] Updated locking documentation for journal_t

On Thu, Feb 11, 2021 at 10:51:55AM +0100, Alexander Lochmann wrote: > Some members of transaction_t are allowed to be read without > any lock being held if consistency doesn't matter. > Based on LockDoc's findings, we extended the locking > documentation of those members. > Each one of them is

Re: [PATCH v8 0/6] Optionally randomize kernel stack offset each syscall

On Thu, Apr 01, 2021 at 01:49:17PM -0700, Roy Yang wrote: > Thanks Ted, Casey and Al Viro. I am sorry for the inconvenience. > > I tried to follow the instructions listed under > https://lore.kernel.org/lkml/20210330205750.428816-1-keesc...@chromium.org/ > using git-send-email > > Thought that

Re: [PATCH] Where we are for this patch?

On Thu, Apr 01, 2021 at 07:48:30PM +, Al Viro wrote: > On Thu, Apr 01, 2021 at 12:17:44PM -0700, Roy Yang wrote: > > Both Android and Chrome OS really want this feature; For > > Container-Optimized OS, we have customers > > interested in the defense too. > > > > Thank you very much. > > > >

Re: [PATCH v5 4/4] fs: unicode: Add utf8 module and a unicode layer

On Mon, Mar 29, 2021 at 10:47:52PM -0700, Eric Biggers wrote: > > Isn't this a user problem? If the modules required to boot are on the > > filesystem itself, you are in trouble. But, if that is the case, your > > rootfs is case-insensitive and you gotta have utf8 as built-in or have > > it in

Re: [Ksummit-discuss] RFC: create mailing list "linux-issues" focussed on issues/bugs and regressions

On Tue, Mar 23, 2021 at 09:57:57AM +0100, Thorsten Leemhuis wrote: > On 22.03.21 22:56, Theodore Ts'o wrote: > > On Mon, Mar 22, 2021 at 08:25:15PM +0100, Thorsten Leemhuis wrote: > >> I agree to the last point and yeah, maybe regressions are the more > >> impor

Re: RFC: create mailing list "linux-issues" focussed on issues/bugs and regressions

On Tue, Mar 23, 2021 at 12:20:25PM -0400, Steven Rostedt wrote: > On Mon, 22 Mar 2021 20:25:15 +0100 > Thorsten Leemhuis wrote: > > > I agree to the last point and yeah, maybe regressions are the more > > important problem we should work on – at least from the perspective of > > kernel

Re: [Ksummit-discuss] RFC: create mailing list "linux-issues" focussed on issues/bugs and regressions

On Mon, Mar 22, 2021 at 08:25:15PM +0100, Thorsten Leemhuis wrote: > I agree to the last point and yeah, maybe regressions are the more > important problem we should work on – at least from the perspective of > kernel development. But from the users perspective (and > reporting-issues.rst is

Re: [GIT PULL] ext4 fixes for v5.12

On Mon, Mar 22, 2021 at 11:10:52PM +1100, Herbert Xu wrote: > Theodore Ts'o wrote: > > > > From: 曹子德(Theodore Y Ts'o) > > "Yue" doesn't seem to match your second character which is usually > romanised as "Tze" in Cantonese, could it be > >

Re: [GIT PULL] ext4 fixes for v5.12

On Mon, Mar 22, 2021 at 11:05:13AM +0800, Gao Xiang wrote: > I think the legel name would be "Zhang Yi" (family name goes first [1]) > according to > The Chinese phonetic alphabet spelling rules for Chinese names [2]. > > Indeed, that is also what the legel name is written in alphabet on our >

Re: [GIT PULL] ext4 fixes for v5.12

On Mon, Mar 22, 2021 at 09:33:54AM +0800, zhangyi (F) wrote: > > I will use my real name "Yi Zhang" next time. > Hi Yi, I think what Linus was suggsting was that if people wanted, they could do something like this in their git commits: From: 曹子德(Theodore Y Ts'o) I don't do this because my

[GIT PULL] ext4 fixes for v5.12

-after-free on failed mount Pan Bian (1): ext4: stop inode update before return Sabyrzhan Tasbolatov (1): fs/ext4: fix integer overflow in s_log_groups_per_flex Shijie Luo (1): ext4: fix potential error in ext4_do_update_inode Theodore Ts'o (1): ext4: initialize ret

Re: ext4: stop inode update before return

On Sun, Jan 17, 2021 at 12:57:32AM -0800, Pan Bian wrote: > The inode update should be stopped before returing the error code. > > Signed-off-by: Pan Bian Thanks, applied. - Ted

Re: [syzbot] KCSAN: data-race in start_this_handle / start_this_handle

On Thu, Mar 11, 2021 at 04:08:30PM +0100, Marco Elver wrote: > If the outcome of the check does not affect correctness and the code is > entirely fault tolerant to the precise value being read, then a > data_race(!journal->j_running_transaction) marking here would be fine. So a very common coding

Re: [RFC] inode.i_opflags - Usage of two different locking schemes

On Fri, Mar 05, 2021 at 04:35:47PM +0100, Alexander Lochmann wrote: > > > On 05.03.21 16:18, Theodore Ts'o wrote: > > 1) I don't see where i_opflags is being read in ipc/mqueue.c at all, > > either with or without i_rwsem. > > > It is read in fs/dcache.c So wh

Re: [RFC] inode.i_opflags - Usage of two different locking schemes

On Fri, Mar 05, 2021 at 02:10:09PM +0100, Alexander Lochmann wrote: > Hi folks, > > I've stumbled across an interesting locking scheme. It's related to struct > inode, more precisely it is an mqueue inode. > Our results show that inode:mqueue.i_opflags is read with i_rwsem being > hold. > In

Re: [PATCH] ext4: fix bh ref count on error paths

On Tue, Mar 02, 2021 at 05:42:31PM +0800, Zhaolong Zhang wrote: > __ext4_journalled_writepage should drop bhs' ref count on error paths > > Signed-off-by: Zhaolong Zhang Thanks, applied. - Ted

Re: [PATCH v2] fs/ext4: fix integer overflow in s_log_groups_per_flex

On Wed, Feb 24, 2021 at 03:58:00PM +0600, Sabyrzhan Tasbolatov wrote: > syzbot found UBSAN: shift-out-of-bounds in ext4_mb_init [1], when > 1 << sbi->s_es->s_log_groups_per_flex is bigger than UINT_MAX, > where sbi->s_mb_prefetch is unsigned integer type. > > 32 is the maximum allowed power of

Re: [RFC PATCH v2 00/13] Add futex2 syscall

On Wed, Mar 03, 2021 at 09:42:06PM -0300, André Almeida wrote: > ** Performance > > - For comparing futex() and futex2() performance, I used the artificial >benchmarks implemented at perf (wake, wake-parallel, hash and >requeue). The setup was 200 runs for each test and using 8, 80,

[GIT PULL] ext4 changes for v5.12

Uytterhoeven (1): ext: EXT4_KUNIT_TESTS should depend on EXT4_FS instead of selecting it Theodore Ts'o (2): ext4: don't try to processed freed blocks until mballoc is initialized ext4: fix potential htree index checksum corruption Vinicius Tinti (1): ext4: factor out htree rep

Re: 5.10 LTS Kernel: 2 or 6 years?

On Fri, Feb 19, 2021 at 12:16:12PM +0100, Greg Kroah-Hartman wrote: > > Great! Can you run 'git bisect' on the 4.14.y stable tree to find the > offending change? To be fair, especially with WiFi bugs, you may need to run for hours or days before you are absolutely sure that a particular

Re: [PATCH 1/2] ext4: Handle casefolding with encryption

On Wed, Feb 17, 2021 at 03:48:39PM -0700, Andreas Dilger wrote: > It would be possible to detect if the encrypted/casefold+dirdata > variant is in use, because the dirdata variant would have the 0x40 > bit set in the file_type byte. It isn't possible to positively > identify the "raw" non-dirdata

Re: [PATCH 1/2] ext4: Handle casefolding with encryption

On Tue, Feb 16, 2021 at 08:01:11PM -0800, Daniel Rosenberg wrote: > I'm not sure what the conflict is, at least format-wise. Naturally, > there would need to be some work to reconcile the two patches, but my > patch only alters the format for directories which are encrypted and > casefolded, which

Re: possible deadlock in dquot_commit

>From: Theodore Ts'o On Fri, Feb 12, 2021 at 12:01:51PM +0100, Dmitry Vyukov wrote: > > > > > > There is a reproducer for 4.19 available on the dashboard. Maybe it will > > > help. > > > I don't why it did not pop up on upstream yet

Re: [PATCH] ext4: add .kunitconfig fragment to enable ext4-specific tests

On Tue, Feb 09, 2021 at 05:32:06PM -0800, Daniel Latypov wrote: > As of [1], we no longer want EXT4_KUNIT_TESTS and others to `select` > their deps. This means it can get harder to get all the right things > selected as we gain more tests w/ more deps over time. > > This patch (and [2]) proposes

Re: [PATCH resend] ext: EXT4_KUNIT_TESTS should depend on EXT4_FS instead of selecting it

On Fri, Jan 22, 2021 at 12:02:34PM +0100, Geert Uytterhoeven wrote: > EXT4_KUNIT_TESTS selects EXT4_FS, thus enabling an optional feature the > user may not want to enable. Fix this by making the test depend on > EXT4_FS instead. > > Fixes: 1cbeab1b242d16fd ("ext4: add kunit test for decoding

Re: possible deadlock in dquot_commit

On Thu, Feb 11, 2021 at 12:47:18PM +0100, Dmitry Vyukov wrote: > > This actually looks problematic: We acquired >i_data_sem/2 (i.e., > > I_DATA_SEM_QUOTA subclass) in ext4_map_blocks() called from > > ext4_block_write_begin(). This suggests that the write has been happening > > directly to the

Re: [PATCH 1/2] ext4: Handle casefolding with encryption

On Tue, Feb 09, 2021 at 08:03:10PM -0700, Andreas Dilger wrote: > Depending on the size of the "escape", it probably makes sense to move > toward having e2fsck migrate from the current mechanism to using dirdata > for all deployments. In the current implementation, tools don't really > know for

Re: [PATCH] ext4: add .kunitconfig fragment to enable ext4-specific tests

On Tue, Feb 09, 2021 at 05:32:06PM -0800, Daniel Latypov wrote: > > After [2]: > $ ./tools/testing/kunit.py run --kunitconfig=fs/ext4/.kunitconfig Any chance that in the future this might become: $ ./tools/testing/kunit.py run --kunitconfig=fs/ext4 Or better yet, syntactic sugar like: $

Re: [PATCH 1/2] ext4: Handle casefolding with encryption

On Wed, Feb 03, 2021 at 11:31:28AM -0500, Theodore Ts'o wrote: > On Wed, Feb 03, 2021 at 03:55:06AM -0700, Andreas Dilger wrote: > > > > It looks like this change will break the dirdata feature, which is similarly > > storing a data field beyond the end of the dirent.

Re: [PATCH 1/2] ext4: Handle casefolding with encryption

On Wed, Feb 03, 2021 at 03:55:06AM -0700, Andreas Dilger wrote: > > It looks like this change will break the dirdata feature, which is similarly > storing a data field beyond the end of the dirent. However, that feature also > provides for flags stored in the high bits of the type field to

Re: [PATCH v3] ext4: Enable code path when DX_DEBUG is set

On Tue, Feb 02, 2021 at 04:28:37PM +, Vinicius Tinti wrote: > Clang with -Wunreachable-code-aggressive is being used to try to find > unreachable code that could cause potential bugs. There is no plan to > enable it by default. > > The following code was detected as unreachable: > >

Re: [PATCH v2] ext4: Change list_for_each* to list_for_each_entry*

On Mon, Jan 11, 2021 at 10:37:26AM +0900, Daejun Park wrote: > In the fast_commit.c, list_for_each* + list_entry can be changed to > list_for_each_entry*. It reduces number of variables and lines. > > Signed-off-by: Daejun Park Thanks, applied. - Ted

Re: [PATCH v2 -next] ext4: use DEFINE_MUTEX() for mutex lock

On Thu, Dec 24, 2020 at 09:22:44PM +0800, Zheng Yongjun wrote: > mutex lock can be initialized automatically with DEFINE_MUTEX() > rather than explicitly calling mutex_init(). > > Signed-off-by: Zheng Yongjun Thanks, applied. - Ted

Re: [PATCH v2] ext4: Enable code path when DX_DEBUG is set

On Mon, Feb 01, 2021 at 07:05:11PM -0300, Vinicius Tinti wrote: > > The goal is to try to detect real bugs. In this instance specifically I > suggested to remove the "if (0) {...}" because it sounded like an > unused code. > > If it is useful it is fine to keep. The trick was that it was unused

Re: [PATCH v2] ext4: Enable code path when DX_DEBUG is set

On Mon, Feb 01, 2021 at 01:16:19PM -0800, Nick Desaulniers wrote: > I agree; Vinicius, my recommendation for -Wunreachable-* with Clang > was to see whether dead code identified by this more aggressive > diagnostic (than -Wunused-function) was to ask maintainers whether > code identified by it was

Re: [PATCH v2] ext4: Enable code path when DX_DEBUG is set

On Mon, Feb 01, 2021 at 03:41:50PM -0300, Vinicius Tinti wrote: > > My goal is to avoid having a dead code. Three options come to mind. > > The first would be to add another #ifdef SOMETHING (suggest a name). > But this doesn't remove the code and someone could enable it by accident. I *really*

Re: [Linux-kernel-mentees] Patches from the future - can checkpatch help?

On Mon, Feb 01, 2021 at 05:50:45PM +0100, Lukas Bulwahn wrote: > > Dwaipayan, there are two ways: > - We build a bot listening to mailing lists and check. I like that > implementation idea for various other checks. > - Stephen Rothwell could include this as a check on linux-next and > inform the

Re: [PATCH v2] ext4: Enable code path when DX_DEBUG is set

On Mon, Feb 01, 2021 at 01:15:29PM -0300, Vinicius Tinti wrote: > On Mon, Feb 1, 2021 at 9:49 AM Christoph Hellwig wrote: > > > > DX_DEBUG is completely dead code, so either kill it off or make it an > > actual CONFIG_* symbol through Kconfig if it seems useful. > > About the unreachable code in

Re: [PATCH v2] ext4: Enable code path when DX_DEBUG is set

On Mon, Feb 01, 2021 at 12:49:24PM +, Christoph Hellwig wrote: > DX_DEBUG is completely dead code, so either kill it off or make it an > actual CONFIG_* symbol through Kconfig if it seems useful. I wouldn't call it completely dead code. If you manually add "#define DX_DEBUG" fs/ext4/namei.c

Re: [RFC PATCH v2 0/4] make jbd2 debug switch per device

On Tue, Jan 26, 2021 at 08:50:02AM +0800, brookxu wrote: > > trace point, eBPF and other hook technologies are better for production > environments. But for pure debugging work, adding hook points feels a bit > heavy. However, your suggestion is very valuable, thank you very much. What feels

Re: Getting a new fs in the kernel

On Tue, Jan 26, 2021 at 07:06:55PM +, Chaitanya Kulkarni wrote: > From what I've seen you can post the long patch-series as an RFC and get the > > discussion started. > > The priority should be ease of review and not the total patch-count. File systems are also complicated enough that it's

Re: [RFC PATCH v2 0/4] make jbd2 debug switch per device

On Sat, Jan 23, 2021 at 08:00:42PM +0800, Chunguang Xu wrote: > On a multi-disk machine, because jbd2 debugging switch is global, this > confuses the logs of multiple disks. It is not easy to distinguish the > logs of each disk and the amount of generated logs is very large. Maybe > a separate

[GIT PULL] ext4 bug fixes for v5.11-rc4

ext4_handle_dirty_super() Theodore Ts'o (1): ext4: don't leak old mountpoint samples Yi Li (1): ext4: use IS_ERR instead of IS_ERR_OR_NULL and set inode null when IS_ERR yangerkun (1): ext4: fix bug for rename with RENAME_WHITEOUT fs/ext4/ext4_jbd2.c | 17 -- fs/ext4/ext4_jbd2.h | 5

Re: [PATCH] ext4: Remove expensive flush on fast commit

On Wed, Jan 06, 2021 at 10:32:42AM +0900, Daejun Park wrote: > In the fast commit, it adds REQ_FUA and REQ_PREFLUSH on each fast commit > block when barrier is enabled. However, in recovery phase, ext4 compares > CRC value in the tail. So it is sufficient adds REQ_FUA and REQ_PREFLUSH > on the

Re: [PATCH] ext4: Fix wrong list_splice in ext4_fc_cleanup

On Wed, Dec 30, 2020 at 06:48:51PM +0900, Daejun Park wrote: > After full/fast commit, entries in staging queue are promoted to main > queue. In ext4_fs_cleanup function, it splice to staging queue to > staging queue. > > Signed-off-by: Daejun Park Thanks, applied.

Re: [PATCH] Use IS_ERR instead of IS_ERR_OR_NULL and set inode null when IS_ERR.

On Wed, Jan 06, 2021 at 02:02:11PM +0100, Jan Kara wrote: > On Wed 30-12-20 11:38:27, Yi Li wrote: > > 1: ext4_iget/ext4_find_extent never returns NULL, use IS_ERR > > instead of IS_ERR_OR_NULL to fix this. > > > > 2: ext4_fc_replay_inode should set the inode to NULL when IS_ERR. > > and go to

Re: Malicious fs images was Re: ext4 regression in v5.9-rc2 from e7bfb5c9bb3d on ro fs with overlapped bitmaps

On Tue, Jan 12, 2021 at 11:28:40PM +0100, Pavel Machek wrote: > > This thread suggested that kernel is _not_ supposed to be robust > against corrupt filesystems (because fsck is not integrated in > kernel). Which was news to me (and I'm not the person that needs > warning in execve

Re: Malicious fs images was Re: ext4 regression in v5.9-rc2 from e7bfb5c9bb3d on ro fs with overlapped bitmaps

On Sun, Jan 10, 2021 at 07:41:02PM +0100, Pavel Machek wrote: > > >From our perspective (and Darrick and I discussed this on this week's > > ext4 video conference, so it represents the ext4 and xfs maintainer's > > position) is that the file system format is different. First, the > > on-disk

Re: Aarch64 EXT4FS inode checksum failures - seems to be weak memory ordering issues

On Thu, Jan 07, 2021 at 01:37:47PM +, Russell King - ARM Linux admin wrote: > > The gcc bugzilla mentions backports into gcc-linaro, but I do not see > > them in my git history. > > So, do we raise the minimum gcc version for the kernel as a whole to 5.1 > or just for aarch64? Russell, Arnd,

Re: Generate the config file for kernel compilation non-interactively in script.

On Fri, Jan 01, 2021 at 12:51:13PM +0800, Hongyi Zhao wrote: > > I want to build the realtime Linux for ROS 2 according to the > guidelines here: > . > > For this purpose, I must enable the rt_preempt

Re: C/C++ Code Reviewer Available

On Wed, Dec 30, 2020 at 11:45:58PM -0800, Robin Rowe wrote: > "Linux kernel's Kroah-Hartman: We're not struggling to get new coders, it's > code review that's the bottleneck", says article at The Register. > > Ok, I've used C++ for 20 years, taught C/C++ at two universities, and > developed

Re: ext4: delete the invalid BUGON in ext4_mb_load_buddy_gfp()

On Mon, Jul 27, 2020 at 09:54:14AM +0800, brookxu wrote: > Delete the invalid BUGON in ext4_mb_load_buddy_gfp(), the previous > code has already judged whether page is NULL. > > Signed-off-by: Chunguang Xu Applied, but I had to manually apply your patch since it was mangled by your mailer. It

Re: INFO: rcu detected stall in ext4_write_checks

On Sun, Jul 14, 2019 at 05:48:00PM +0300, Dmitry Vyukov wrote: > But short term I don't see any other solution than stop testing > sched_setattr because it does not check arguments enough to prevent > system misbehavior. Which is a pity because syzkaller has found some > bad misconfigurations that

[GIT PULL] ext4 updates for 5.3-rc1

of journal_submit_inode_data_buffers Ross Zwisler (3): mm: add filemap_fdatawait_range_keep_errors() jbd2: introduce jbd2_inode dirty range scoping ext4: use jbd2_inode dirty range scoping Theodore Ts'o (7): ext4: enforce the immutable flag on open files ext4: clean up

Re: exfat filesystem

On Tue, Jul 09, 2019 at 08:48:34AM -0700, Matthew Wilcox wrote: > > Interesting analysis. It seems to me that the correct forms would be > observed if someone suitably senior at Microsoft accepted the work from > Valdis and submitted it with their sign-off. KY, how about it? It might be that

Re: Procedure questions - new filesystem driver..

On Tue, Jul 09, 2019 at 04:21:36AM -0700, Matthew Wilcox wrote: > How does > https://www.zdnet.com/article/microsoft-open-sources-its-entire-patent-portfolio/ > change your personal opinion? According to SFC's legal analysis, Microsoft joining the OIN doesn't mean that the eXFAT patents are

Re: Procedure questions - new filesystem driver..

On Mon, Jul 08, 2019 at 08:37:42PM -0400, Valdis Klētnieks wrote: > I have an out-of-tree driver for the exfat file system that I beaten into > shape > for upstreaming. The driver works, and passes sparse and checkpatch (except > for a number of line-too-long complaints). > > Do you want this

Re: INFO: rcu detected stall in ext4_write_checks

On Fri, Jul 05, 2019 at 11:16:31PM -0700, Paul E. McKenney wrote: > I suppose RCU could take the dueling-banjos approach and use increasingly > aggressive scheduler policies itself, up to and including SCHED_DEADLINE, > until it started getting decent forward progress. However, that > sounds like

Re: INFO: rcu detected stall in ext4_write_checks

On Fri, Jul 05, 2019 at 12:10:55PM -0700, Paul E. McKenney wrote: > > Exactly, so although my patch might help for CONFIG_PREEMPT=n, it won't > help in your scenario. But looking at the dmesg from your URL above, > I see the following: I just tested with CONFIG_PREEMPT=n % grep CONFIG_PREEMPT

Re: [PATCH] ext4: replace ktype default_attrs with default_groups

On Wed, May 08, 2019 at 04:07:48PM -0400, Kimberly Brown wrote: > The kobj_type default_attrs field is being replaced by the > default_groups field. Replace the default_attrs field in ext4_sb_ktype > and ext4_feat_ktype with default_groups. Use the ATTRIBUTE_GROUPS macro > to create ext4_groups

Re: ext3/ext4 filesystem corruption under post 5.1.0 kernels

On Mon, Jul 01, 2019 at 02:43:14PM +0200, Geert Uytterhoeven wrote: > Hi Ted, > > Despite this fix having been applied upstream, the kernel prints from > time to time: > > EXT4-fs (sda1): error count since last fsck: 5 > EXT4-fs (sda1): initial error at time 1557931133: >

Re: INFO: rcu detected stall in ext4_write_checks

More details about what is going on. First, it requires root, because one of that is required is using sched_setattr (which is enough to shoot yourself in the foot): sched_setattr(0, {size=0, sched_policy=0x6 /* SCHED_??? */, sched_flags=0, sched_nice=0, sched_priority=0,

Re: INFO: rcu detected stall in ext4_write_checks

The reproducer causes similar rcu stalls when using xfs: RSP: 0018:aae8c0953c58 EFLAGS: 0246 ORIG_RAX: ff13 RAX: 0288 RBX: b05a RCX: aae8c0953d50 RDX: 001c RSI: 001c RDI: dcec41772800 RBP: dcec41772800 R08:

Re: INFO: rcu detected stall in ext4_write_checks

On Wed, Jun 26, 2019 at 10:27:08AM -0700, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit:abf02e29 Merge tag 'pm-5.2-rc6' of git://git.kernel.org/pu.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=1435aaf6a0 >

Re: [PATCH v2 4/7] linux/signal.h: Ignore SIGINFO by default in new tasks

On Tue, Jun 25, 2019 at 07:11:50PM +0300, Arseny Maslennikov wrote: > This matches the behaviour of other Unix-like systems that have SIGINFO > and causes less harm to processes that do not install handlers for this > signal, making the keyboard status character non-fatal for them. > > This is

Re: [PATCH v5 00/18] kunit: introduce KUnit, the Linux kernel unit testing framework

On Fri, Jun 21, 2019 at 08:59:48AM -0600, shuah wrote: > > > ### But wait! Doesn't kselftest support in kernel testing?! > > > > > > > > I think I commented on this before. I agree with the statement that > there is no overlap between Kselftest and KUnit. I would like see this > removed.

Re: [PATCH 1/6] mm/fs: don't allow writes to immutable files

On Mon, Jun 10, 2019 at 09:46:17PM -0700, Darrick J. Wong wrote: > From: Darrick J. Wong > > The chattr manpage has this to say about immutable files: > > "A file with the 'i' attribute cannot be modified: it cannot be deleted > or renamed, no link can be created to this file, most of the

Re: [PATCH v2 3/3] ext4: use jbd2_inode dirty range scoping

On Thu, Jun 20, 2019 at 09:18:39AM -0600, Ross Zwisler wrote: > Use the newly introduced jbd2_inode dirty range scoping to prevent us > from waiting forever when trying to complete a journal transaction. > > Signed-off-by: Ross Zwisler > Reviewed-by: Jan Kara > Cc: sta...@vger.kernel.org

Re: [PATCH v2 2/3] jbd2: introduce jbd2_inode dirty range scoping

On Thu, Jun 20, 2019 at 09:18:38AM -0600, Ross Zwisler wrote: > diff --git a/include/linux/jbd2.h b/include/linux/jbd2.h > index 5c04181b7c6d8..0e0393e7f41a4 100644 > --- a/include/linux/jbd2.h > +++ b/include/linux/jbd2.h > @@ -1397,6 +1413,12 @@ extern int

Re: [PATCH 2/3] jbd2: introduce jbd2_inode dirty range scoping

On Thu, Jun 20, 2019 at 09:09:11AM -0600, Ross Zwisler wrote: > We could definitely keep separate dirty ranges for each of the current and > next transaction. I think the case where you would see a difference would be > if you had multiple transactions in a row which grew the dirty range for a >

Re: [PATCH] ext4: remove redundant assignment to node

On Wed, Jun 19, 2019 at 10:00:06AM +0100, Colin King wrote: > From: Colin Ian King > > Pointer 'node' is assigned a value that is never read, node is > later overwritten when it re-assigned a different value inside > the while-loop. The assignment is redundant and can be removed. > >

Re: [PATCH] ext4: make __ext4_get_inode_loc plug

On Mon, Jun 17, 2019 at 11:57:12PM +0800, jinshui zhang wrote: > From: zhangjs > > If the task is unplugged when called, the inode_readahead_blks may not be > merged, > these will cause small pieces of io, It should be plugged. > > Signed-off-by: zhangjs Thanks, applied. I cleaned up the

Re: [PATCH] ext4: make __ext4_get_inode_loc plug

On Mon, Jun 17, 2019 at 03:11:21PM +0800, Zhangjs Jinshui wrote: > If the task is unplugged when called, the inode_readahead_blks may not be > merged, > these will cause small pieces of io, It should be plugged. > > Signed-off-by: zhangjs This patch is white space damaged. Please see:

Re: PC speaker

On Thu, Jun 13, 2019 at 12:16:37PM -0400, R.F. Burns wrote: > Is it possible to write a kernel module which, when loaded, will blow > the PC speaker? Yes; in fact, it's already been done. See sound/drivers/pcsp/ in the Linux kernel sources. - Ted

Re: [RFC]: Convention for naming syscall revisions

On Thu, Jun 06, 2019 at 05:42:25PM +0200, Christian Brauner wrote: > Hey everyone, > > I hope this is not going to start a trash fire. > > While working on a new clone version I tried to find out what the > current naming conventions for syscall revisions is. I was told and > seemed to be able

Re: [PATCH] ext4: remove unnecessary gotos in ext4_xattr_set_entry

On Fri, May 31, 2019 at 03:46:54PM -0600, Andreas Dilger wrote: > On May 31, 2019, at 6:10 AM, Pavel Tikhomirov > wrote: > > > > In the "out" label we only iput old/new_ea_inode-s, in all these places > > these variables are always NULL so there is no point in goto to "out". > > > >

Re: [PATCH] jbd2: fix typo in comment of journal_submit_inode_data_buffers

On Mon, May 27, 2019 at 10:24:57AM +0200, Jan Kara wrote: > On Sat 25-05-19 17:12:51, Liu Song wrote: > > From: Liu Song > > > > delayed/dealyed > > > > Signed-off-by: Liu Song > > Thanks. You can add: > > Reviewed-by: Jan Kara Applied, thanks. -

  1   2   3   4   5   6   7   8   9   10   >