On Thu, Feb 13, 2025 at 11:21:22AM +0530, Venkat Rao Bagalkote wrote:
> Greetings!!!
>
> I am observing kernel OOPs, while running FStests generic/451 on EXT4 with
> linux-next kernel(next-20250212) on IBM Power Servers.
I'm running daily spinnner tests on the fs-next branch on the
linux-next tre
simpler, and it improves
> performance due to eliminating the crypto API overhead.
>
> Reviewed-by: Ard Biesheuvel
> Signed-off-by: Eric Biggers
Acked-by: Theodore Ts'o
formance due to eliminating the crypto API overhead.
>
> Reviewed-by: Ard Biesheuvel
> Signed-off-by: Eric Biggers
Acked-by: Theodore Ts'o
Thanks for the cleanup!
simpler, and it improves
> performance due to eliminating the crypto API overhead.
>
> Reviewed-by: Ard Biesheuvel
> Signed-off-by: Eric Biggers
Acked-by: Theodore Ts'o
On Thu, Sep 28, 2023 at 01:40:55PM -0400, Jeff Layton wrote:
>
> Correct. We'd lose some fidelity in currently stored timestamps, but as
> Linus and Ted pointed out, anything below ~100ns granularity is
> effectively just noise, as that's the floor overhead for calling into
> the kernel. It's hard
On Wed, Nov 16, 2022 at 04:47:27PM -0800, Kees Cook wrote:
> >> > - between
> >> > - ranged
> >> > - spanning
> >> >
> >> > https://www.thefreedictionary.com/List-of-prepositions.htm
> >> > - amid
> >> >
> >> > Sigh, names.
> >>
> >> I think "inclusive" is best.
> >
> >I find it not very descrip
On Fri, Oct 21, 2022 at 11:03:22PM -0700, Jakub Kicinski wrote:
> On Sat, 22 Oct 2022 07:47:06 +0200 Jason A. Donenfeld wrote:
> > On Fri, Oct 21, 2022 at 10:32:42PM -0700, Jakub Kicinski wrote:
> > > But whatever. I mean - hopefully there aren't any conflicts in the ~50
> > > networking files you
On Tue, Jul 05, 2022 at 09:01:21PM +0200, Jason A. Donenfeld wrote:
> Later the thinking evolved. With a properly designed RNG, using RDRAND
> values alone won't harm anything, even if the outputs are malicious.
I personally think it's totally fine to remove nordrand. However, the
reason why it w
nes of code. :-)
- Ted
>From ef3130d1b0b8ca769252d6a722a2e59a00141383 Mon Sep 17 00:00:00 2001
From: Theodore Ts'o
Date: Fri, 2 Jul 2021 18:05:03 -0400
Subject: [PATCH] ext4: inline jbd2_journal_[un]register_shrinker()
The function jbd2_journal_
On Sat, Jul 03, 2021 at 11:37:07AM +0800, Zhang Yi wrote:
> I check the ocfs2 code, if we register shrinker here,
> __ocfs2_recovery_thread()->
> ocfs2_recover_node() seems will register and unregister a lot of unnecessary
> shrinkers. It depends on the lifetime of the shrinker and the journal,
>
On Sat, Jul 03, 2021 at 11:05:07AM +0800, Zhang Yi wrote:
>
> Originally, I want to add this shrinker as a optional feature for jbd2 because
> only ext4 use it now and I'm not sure does ocfs2 needs this feature. So I
> export
> jbd2_journal_[un]register_shrinker(), ext4 could invoke them individu
On Fri, Jul 02, 2021 at 12:11:54PM -0400, Theodore Ts'o wrote:
> So it probably makes more sense to keep jbd2_journal_unregister_shrinker()
> in jbd2_destroy_journal(), since arguably the fact that we are using a
> shrinker is an internal implementation detail, and the users of
On Fri, Jul 02, 2021 at 09:52:13PM +0800, Zhang Yi wrote:
>
> Sorry about not catching this problem, this fix is not format corrected,
> if you think this fix is OK, I can send a patch after test.
The issue I see with your approach, which removes the
jbd2_journal_unregister_shrinker() call from j
On Fri, Jul 02, 2021 at 05:38:10PM +0800, Guoqing Jiang wrote:
>
>
> I guess the problem is j_jh_shrink_count was destroyed in ext4_put_super _>
> jbd2_journal_unregister_shrinker
> which is before the path ext4_put_super -> jbd2_journal_destroy ->
> jbd2_log_do_checkpoint to call
> percpu_count
On Wed, Jan 04, 2017 at 11:32:42AM +0530, Chandan Rajendra wrote:
> On Wednesday, January 04, 2017 04:18:08 PM Anton Blanchard wrote:
> > I'm consistently seeing ext4 filesystem corruption using a mainline
> > kernel. It doesn't take much to trigger it - download a ppc64le Ubuntu
> > cloud image, b
On Thu, Nov 03, 2016 at 01:32:33PM -0600, Andreas Dilger wrote:
> On Nov 3, 2016, at 3:14 AM, Chandan Rajendra
> wrote:
> >
> > 'border' variable is set to a value of 2 times the block size of the
> > underlying filesystem. With 64k block size, the resulting value won't
> > fit into a 16-bit var
ug
fix, and anyway this is pretty much a zero-risk patch. Thanks!!
- Ted
>From c3638c5a50de0d360210205625df2ab49508f6d3 Mon Sep 17 00:00:00 2001
From: Theodore Ts'o <[EMAIL PROTECTED]>
Date: Tue, 11 Mar 2008 22:37:27 -0400
Subject: [PATCH] pp
17 matches
Mail list logo
