Re: [PATCH 86/87] fs: switch timespec64 fields in inode to discrete integers

[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 to argue that any application needs that sort of
> timestamp resolution, at least with contemporary hardware. 
> 
> Doing that would mean that tests that store specific values in the
> atime/mtime and expect to be able to fetch exactly that value back would
> break though, so we'd have to be OK with that if we want to try it. The
> good news is that it's relatively easy to experiment with new ways to
> store timestamps with these wrappers in place.

The reason why we store 1ns granularity in ext4's on-disk format (and
accept that we only support times only a couple of centuries into the
future, as opposed shooting for an on-disk format good for several
millennia :-), was in case there was userspace that might try to store
a very fine-grained timestamp and want to be able to get it back
bit-for-bit identical.

For example, what if someone was trying to implement some kind of
steganographic scheme where they going store a secret message (or more
likely, a 256-bit AES key) in the nanosecond fields of the file's
{c,m,a,cr}time timestamps, "hiding in plain sight".  Not that I think
that we have to support something like that, since the field is for
*timestamps* not cryptographic bits, so if we break someone who is
doing that, do we care?

I don't think anyone will complain about breaking the userspace API
--- especially since if, say, the CIA was using this for their spies'
drop boxes, they probably wouldn't want to admit it.  :-)

- Ted

Re: [PATCH v2 3/3] treewide: use get_random_u32_between() when possible

[Theodore Ts'o]

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 descriptive of what the function does. Is there one
> >you like second best? Or are you convinced they're all much much much
> >worse than "inclusive" that they shouldn't be considered?
> 
> Right, I don't think any are sufficiently descriptive. "Incluisve"
> with two arguments seems unambiguous and complete to me. :)

The problem with "between", "ranged", "spanning" is that they don't
tell the reader whether we're dealing with an "open interval" or a
"closed interval".  They are just different ways of saying that it's a
range between, say, 0 and 20.  But it doesn't tell you whether it
includes 0 or 20 or not.

The only way I can see for making it ambiguous is either to use the
terminology "closed interval" or "inclusive".  And "open" and "closed"
can have other meanings, so get_random_u32_inclusive() is going to be
less confusing than get_random_u32_closed().

Cheers,

- Ted

Re: [PATCH v1 0/5] convert tree to get_random_u32_{below,above,between}()

[Theodore Ts'o]

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 touch. I just wish that people didn't pipe up with
> > > the tree wide changes right after the merge window. Feels like the
> > > worst possible timing.  
> > 
> > Oh, if the timing is what makes this especially worrisome, I have
> > no qualms about rebasing much later, and reposting this series then.
> > I'll do that.
> 
> Cool, thanks! I promise to not be grumpy if you repost around rc6 :)

One way of making things less painful for the stable branch and for
the upstream branch is to *add* new helpers instead of playing
replacement games like s/prandom_u32_max/get_random_u32_below/.  This
is what causes the patch conflict problems.

One advantage of at least adding the new functions to the stable
branches, even if we don't do the wholesale replacement, is that it
makes it much less likely that a backported patch, which uses the new
API, won't fail to compile --- and of course, the major headache case
is one where it's not noticed at first because it didn't get picked up
in people's test compiles until after the Linux x.y.z release has been
pushed out.

Whether it's worth doing the wholesale replacement is a different
question, but separating "add the new functions with one or two use
cases so the functions are actulaly _used_" from the "convert the
world to use the new functions" from the "remove the old functions",
might life easier.

- Ted

Re: [PATCH] random: remove CONFIG_ARCH_RANDOM and "nordrand"

[Theodore Ts'o]

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 was there was that there were some rather extreme
tin-foil-hatters who believed that if (the completely unavailable to
the public for auditing) RDRAND implementation *were* malicious *and*
the microcode had access to the register file and/or the instruction
pipeline, then in theory, a malicious CPU could subvert how the RDRAND
is mixed into the getrandom output to force a particular output.

Personally, I've always considered it to be insane, since a much
easier way to compromise a CPU would be to drop a Minix system hidden
into the CPU running a web server that had massive security bugs in it
that were only discovered years later.  And if you don't trust the CPU
manufacture to that extent, you should probably simply not use CPU's
from that manufacturer.  :-)

- Ted

Re: [powerpc][5.13.0-next-20210701] Kernel crash while running ltp(chdir01) tests

[Theodore Ts'o]

On Sat, Jul 03, 2021 at 12:55:09PM +0800, Zhang Yi wrote:
> Yeah, it sounds good to me. Do you want me to send the fix patch, or you
> modify your commit 8f9e16badb8fd in another email directly?

I've gone ahead and made the changes; what do you think?

I like how it also removes 40 lines 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_unregister_shrinker() was getting called
twice when the file system was getting unmounted.  On Power and ARM
platforms this was causing kernel crash when unmounting the file
system, when a percpu_counter was destroyed twice.

Fix this by removing jbd2_journal_[un]register_shrinker() functions,
and inlining the shrinker setup and teardown into
journal_init_common() and jbd2_journal_destroy().  This means that
ext4 and ocfs2 now no longer need to know about registering and
unregistering jbd2's shrinker.

Also, while we're at it, rename the percpu counter from
j_jh_shrink_count to j_checkpoint_jh_count, since this makes it
clearer what this counter is intended to track.

Fixes: 4ba3fcdde7e3 ("jbd2,ext4: add a shrinker to release checkpointed 
buffers")
Reported-by: Sachin Sant 
Reported-by: Jon Hunter 
Signed-off-by: Theodore Ts'o 
---
 fs/ext4/super.c  |   8 ---
 fs/jbd2/checkpoint.c |   4 +-
 fs/jbd2/journal.c| 148 +--
 include/linux/jbd2.h |   6 +-
 4 files changed, 63 insertions(+), 103 deletions(-)

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index b8ff0399e171..dfa09a277b56 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -1184,7 +1184,6 @@ static void ext4_put_super(struct super_block *sb)
ext4_unregister_sysfs(sb);
 
if (sbi->s_journal) {
-   jbd2_journal_unregister_shrinker(sbi->s_journal);
aborted = is_journal_aborted(sbi->s_journal);
err = jbd2_journal_destroy(sbi->s_journal);
sbi->s_journal = NULL;
@@ -5176,7 +5175,6 @@ static int ext4_fill_super(struct super_block *sb, void 
*data, int silent)
sbi->s_ea_block_cache = NULL;
 
if (sbi->s_journal) {
-   jbd2_journal_unregister_shrinker(sbi->s_journal);
jbd2_journal_destroy(sbi->s_journal);
sbi->s_journal = NULL;
}
@@ -5502,12 +5500,6 @@ static int ext4_load_journal(struct super_block *sb,
ext4_commit_super(sb);
}
 
-   err = jbd2_journal_register_shrinker(journal);
-   if (err) {
-   EXT4_SB(sb)->s_journal = NULL;
-   goto err_out;
-   }
-
return 0;
 
 err_out:
diff --git a/fs/jbd2/checkpoint.c b/fs/jbd2/checkpoint.c
index 51d1eb2ffeb9..746132998c57 100644
--- a/fs/jbd2/checkpoint.c
+++ b/fs/jbd2/checkpoint.c
@@ -701,7 +701,7 @@ int __jbd2_journal_remove_checkpoint(struct journal_head 
*jh)
 
__buffer_unlink(jh);
jh->b_cp_transaction = NULL;
-   percpu_counter_dec(>j_jh_shrink_count);
+   percpu_counter_dec(>j_checkpoint_jh_count);
jbd2_journal_put_journal_head(jh);
 
/* Is this transaction empty? */
@@ -764,7 +764,7 @@ void __jbd2_journal_insert_checkpoint(struct journal_head 
*jh,
jh->b_cpnext->b_cpprev = jh;
}
transaction->t_checkpoint_list = jh;
-   percpu_counter_inc(>t_journal->j_jh_shrink_count);
+   percpu_counter_inc(>t_journal->j_checkpoint_jh_count);
 }
 
 /*
diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
index 152880c298ca..8a9c94dd3599 100644
--- a/fs/jbd2/journal.c
+++ b/fs/jbd2/journal.c
@@ -1283,6 +1283,48 @@ static int jbd2_min_tag_size(void)
return sizeof(journal_block_tag_t) - 4;
 }
 
+/**
+ * jbd2_journal_shrink_scan()
+ *
+ * Scan the checkpointed buffer on the checkpoint list and release the
+ * journal_head.
+ */
+static unsigned long jbd2_journal_shrink_scan(struct shrinker *shrink,
+ struct shrink_control *sc)
+{
+   journal_t *journal = container_of(shrink, journal_t, j_shrinker);
+   unsigned long nr_to_scan = sc->nr_to_scan;
+   unsigned long nr_shrunk;
+   unsigned long count;
+
+   count = percpu_counter_read_positive(>j_checkpoint_jh_count);
+   trace_jbd2_shrink_scan_enter(journal, sc->nr_to_scan, count);
+
+   nr_shrunk = jbd2_journal_shrink_checkpoint_list(journal, _to_scan);
+
+   count = percpu_counter_read_positive(>j_checkpoint_jh_count);
+   trace_jbd2_shrink_scan_exit(journal, nr_to_scan, nr_shrunk, count);
+
+   return nr_shrunk;
+}
+
+/**
+ * jbd2_journal_shrink_count()
+ *
+ * Count the number of checkpoint buffers on the checkpoint list.
+ */
+static unsigned long jbd2_journal_shrink_count(str

Re: [powerpc][5.13.0-next-20210701] Kernel crash while running ltp(chdir01) tests

[Theodore Ts'o]

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, 
> because of
> the jbd2_journal_destroy() destroy everything, it not a simple undo of
> jbd2_load_journal(), so it's not easy to add shrinker properly. But it doesn't
> seems like a real problem, just curious.

ocfs2_recover_node() only gets called for nodes that need recovery ---
that is, when an ocfs2 server has crashed, then it becomes necessary
to replay that node's journal before that node's responsibilities can
be taken over by another server.  So it doesn't get called that
frequently --- and when it is needed, the fact that we need to read
the journal, and replay its entries, the cost in comparison for
registering and unregistering the shrinker is going to be quite cheap.

Cheers,

- Ted

Re: [powerpc][5.13.0-next-20210701] Kernel crash while running ltp(chdir01) tests

[Theodore Ts'o]

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 individually.

The reason why bdev_try_to_free_page() callback was needed for ext4
--- namely so there was a way to release checkpointed buffers under
memory pressure --- also exists for ocfs2.  It was probably true that
in most deployments of ocfs2, they weren't running with super-tight
memory availability, so it may not have been necessary the same way
that it might be necessary, say, if ext4 was being used on a Rasberry
Pi.  :-)

> And one more thing we to could do is rename the 'j_jh_shrink_count' to 
> something
> like 'j_checkpoint_jh_count' because we always init it no matter we register 
> the
> shrinker or not later.

That makes sense.

In fact, unless I'm mistaken, I don't think it's legal to call
percpu_counter_{inc,dec} if the shrinker isn't initialized.  So for
ocfs2, if we didn't initialize percpu_counter, when
__jbd2_journal_insert_checkpoint() tries to call percpu_counter_inc(),
I believe things would potentially go *boom* on some implementations
of the percpu counter (e.g., on Power and ARM).  So not only would it
not hurt to register the shrinker for ocfs2, I think it's required.

So yeah, let's rename it to something like j_checkpoint_jh_count, and
then let's inline jbd2_journal_[un]register_shrinker() in
journal_init_common() and jbd2_journal_unregister_shrinker().

What do you think?

- Ted

Re: [powerpc][5.13.0-next-20210701] Kernel crash while running ltp(chdir01) tests

[Theodore Ts'o]

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 jbd2
> ideally shouldn't need to be expected to know they have unregister
> jbd2's shirnkers.
> 
> Similarly, perhaps we should be moving jbd2_journal_register_shirnker()
> into jbd2_journal_init_common().  We can un-export the register and
> unshrink register functions, and declare them as static functions internal
> to fs/jbd2/journal.c.
> 
> What do you think?

Like this...

commit 8f9e16badb8fda3391e03146a47c93e76680efaf
Author: Theodore Ts'o 
Date:   Fri Jul 2 18:05:03 2021 -0400

ext4: fix doubled call to jbd2_journal_unregister_shrinker()

On Power and ARM platforms this was causing kernel crash when
unmounting the file system, due to a percpu_counter getting destroyed
twice.

Fix this by cleaning how the jbd2 shrinker is initialized and
uninitiazed by making it solely the responsibility of
fs/jbd2/journal.c.

Fixes: 4ba3fcdde7e3 ("jbd2,ext4: add a shrinker to release checkpointed 
buffers")
    Reported-by: Sachin Sant 
Signed-off-by: Theodore Ts'o 

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index b8ff0399e171..dfa09a277b56 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -1184,7 +1184,6 @@ static void ext4_put_super(struct super_block *sb)
ext4_unregister_sysfs(sb);
 
if (sbi->s_journal) {
-   jbd2_journal_unregister_shrinker(sbi->s_journal);
aborted = is_journal_aborted(sbi->s_journal);
err = jbd2_journal_destroy(sbi->s_journal);
sbi->s_journal = NULL;
@@ -5176,7 +5175,6 @@ static int ext4_fill_super(struct super_block *sb, void 
*data, int silent)
sbi->s_ea_block_cache = NULL;
 
if (sbi->s_journal) {
-   jbd2_journal_unregister_shrinker(sbi->s_journal);
jbd2_journal_destroy(sbi->s_journal);
sbi->s_journal = NULL;
}
@@ -5502,12 +5500,6 @@ static int ext4_load_journal(struct super_block *sb,
ext4_commit_super(sb);
}
 
-   err = jbd2_journal_register_shrinker(journal);
-   if (err) {
-   EXT4_SB(sb)->s_journal = NULL;
-   goto err_out;
-   }
-
return 0;
 
 err_out:
diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
index 152880c298ca..2595703aca51 100644
--- a/fs/jbd2/journal.c
+++ b/fs/jbd2/journal.c
@@ -99,6 +99,8 @@ EXPORT_SYMBOL(jbd2_journal_begin_ordered_truncate);
 EXPORT_SYMBOL(jbd2_inode_cache);
 
 static int jbd2_journal_create_slab(size_t slab_size);
+static int jbd2_journal_register_shrinker(journal_t *journal);
+static void jbd2_journal_unregister_shrinker(journal_t *journal);
 
 #ifdef CONFIG_JBD2_DEBUG
 void __jbd2_debug(int level, const char *file, const char *func,
@@ -2043,7 +2045,8 @@ int jbd2_journal_load(journal_t *journal)
goto recovery_error;
 
journal->j_flags |= JBD2_LOADED;
-   return 0;
+
+   return jbd2_journal_register_shrinker(journal);
 
 recovery_error:
printk(KERN_WARNING "JBD2: recovery failed\n");
@@ -2099,7 +2102,7 @@ static unsigned long jbd2_journal_shrink_count(struct 
shrinker *shrink,
  * Init a percpu counter to record the checkpointed buffers on the checkpoint
  * list and register a shrinker to release their journal_head.
  */
-int jbd2_journal_register_shrinker(journal_t *journal)
+static int jbd2_journal_register_shrinker(journal_t *journal)
 {
int err;
 
@@ -2122,7 +2125,6 @@ int jbd2_journal_register_shrinker(journal_t *journal)
 
return 0;
 }
-EXPORT_SYMBOL(jbd2_journal_register_shrinker);
 
 /**
  * jbd2_journal_unregister_shrinker()
@@ -2130,12 +2132,13 @@ EXPORT_SYMBOL(jbd2_journal_register_shrinker);
  *
  * Unregister the checkpointed buffer shrinker and destroy the percpu counter.
  */
-void jbd2_journal_unregister_shrinker(journal_t *journal)
+static void jbd2_journal_unregister_shrinker(journal_t *journal)
 {
-   percpu_counter_destroy(>j_jh_shrink_count);
-   unregister_shrinker(>j_shrinker);
+   if (journal->j_shrinker.flags & SHRINKER_REGISTERED) {
+   percpu_counter_destroy(>j_jh_shrink_count);
+   unregister_shrinker(>j_shrinker);
+   }
 }
-EXPORT_SYMBOL(jbd2_journal_unregister_shrinker);
 
 /**
  * jbd2_journal_destroy() - Release a journal_t structure.
diff --git a/include/linux/jbd2.h b/include/linux/jbd2.h
index 6cc035321562..632afbe4b18f 100644
--- a/include/linux/jbd2.h
+++ b/include/linux/jbd2.h
@@ -1556,8 +1556,6 @@ extern int   jbd2_journal_set_features
   (journal_t *, unsigned long, unsigned long, unsigned long);
 extern void   jbd2_jo

Re: [powerpc][5.13.0-next-20210701] Kernel crash while running ltp(chdir01) tests

[Theodore Ts'o]

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 jbd2_destsroy_journal(),
is that means that *all* callers of jbd2_destroy_journal now have to
be responsible for calling jbd2_journal_unregister_shrinker() --- and
there a number of call sites to jbd2_journal_unregister_shrinker():

fs/ext4/super.c:err = jbd2_journal_destroy(sbi->s_journal);
fs/ext4/super.c:jbd2_journal_destroy(sbi->s_journal);
fs/ext4/super.c:jbd2_journal_destroy(journal);
fs/ext4/super.c:jbd2_journal_destroy(journal);
fs/ext4/super.c:jbd2_journal_destroy(journal);
fs/ocfs2/journal.c: if (!jbd2_journal_destroy(journal->j_journal) && 
!status) {
fs/ocfs2/journal.c: jbd2_journal_destroy(journal);
fs/ocfs2/journal.c: jbd2_journal_destroy(journal);

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 jbd2
ideally shouldn't need to be expected to know they have unregister
jbd2's shirnkers.

Similarly, perhaps we should be moving jbd2_journal_register_shirnker()
into jbd2_journal_init_common().  We can un-export the register and
unshrink register functions, and declare them as static functions internal
to fs/jbd2/journal.c.

What do you think?

- Ted

Re: [powerpc][5.13.0-next-20210701] Kernel crash while running ltp(chdir01) tests

[Theodore Ts'o]

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_counter_dec(>j_jh_shrink_count).
> 
> And since jbd2_journal_unregister_shrinker is already called inside
> jbd2_journal_destroy, does it make sense
> to do this?
> 
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -1176,7 +1176,6 @@ static void ext4_put_super(struct super_block *sb)
>     ext4_unregister_sysfs(sb);
> 
>     if (sbi->s_journal) {
> -   jbd2_journal_unregister_shrinker(sbi->s_journal);
>     aborted = is_journal_aborted(sbi->s_journal);
>     err = jbd2_journal_destroy(sbi->s_journal);
>     sbi->s_journal = NULL;

Good catch.  There's another place where we call
jbd2_journal_unregister_shrinker(), in the failure path for
ext4_fill_super().

- Ted

P.S.  Whatever outgoing mailer you are using, it's not preserving TAB
characters correctly.  You might want to look into that before trying
to submit a patch.

Re: ext4 filesystem corruption with 4.10-rc2 on ppc64le

[Theodore Ts'o]

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, boot it in KVM and run:
> > 
> > sudo apt-get update
> > sudo apt-get dist-upgrade
> > sudo reboot
> > 
> > And it never makes it back up, dying with rather severe filesystem
> > corruption.
> 
> The patch at https://patchwork.kernel.org/patch/9488235/ should fix the
> bug.

It looks like this patch is already queued up on the "for-linus"
branch on the linux-block.git tree.

Chandra, thanks for pointing this out!  I had missed your e-mail from
Christmas day, and it was on my todo list to figure out why I was
seeing lots of 1k block regressions on gce-xfstests post-merge window
that wasn't showing up on the ext4.git tree before I sent my pull
request to Linus.

Jens, could you expedite a pull request to Linus?  This is affecting
ext4 on 1k block file systems on x86/x86_64, so this is not a ppc-only
regression.  

Anton or Chandan, could you do me a favor and verify whether or not
64k block sizes are working for you on ppcle on ext4 by running
xfstests?  Light duty testing works for me but when I stress ext4 with
pagesize==blocksize on ppcle64 via xfstests, it blows up.  I suspect
(but am not sure) it's due to (non-upstream) device driver issues, and
a verification that you can run xfstests on your ppcle64 systems using
standard upstream device drivers would be very helpful, since I don't
have easy console access on the machines I have access to at $WORK.  :-(

And of course, if there are still blocksize==pagesize issues on ext4
on ppc64le, it would be good to know that too.

Many thanks!!
- Ted

P.S.  And for those people who are doing storage work, let me put in a
plug for "gce-xfstests full".  It's cheap and finds lots of problems
before I and others have to.  And if the $1.50 USD is the problem, let
me know and I'll try to work something out.  :-) :-)

Re: [PATCH] ext4: ext4_mb_mark_free_simple: Fix integer value truncation

[Theodore Ts'o]

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 variable. Hence this commit changes the data type of
> > 'border' to 'unsigned int'.
> > 
> > Signed-off-by: Chandan Rajendra 
> 
> Reviewed-by: Andreas Dilger 

Applied, with a change in the commit summary:

ext4: fix mballoc breakage with 64k block size

Many thanks!!

- Ted

[PATCH] ppc: Export empty_zero_page

[Theodore Ts'o]

Hi,

Stephen Rothwell discovered this issue in the linux-next tree:

Today's powerpc allmodconfig build of linux-next failed with:

ERROR: empty_zero_page [fs/ext4/ext4dev.ko] undefined!

This is because commit dde5f2130096f8469eb1aa1ad250cd2a39fee3f5 (ext4:
ENOSPC error handling for writing to an uninitialized extent) uses
ZERO_PAGE() which on powerpc uses empty_zero_page which is not
EXPORT_SYMBOLed on powerpc.  I have reverted that commit and a later
one (1ae53f35fea49a9013353078e019469551d2ad74 ext4: zero out
small extents when writing to prealloc area.) which depended on it.

Any chance you could get this pushed to Linus ASAP?  It would be nice if
this could get pushed before the merge window, since it could be argued
that rationalizing whether or not empty_zero_page is exported is a bug
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] ppc: Export empty_zero_page

The empty_zero_page symbol is exported by most other architectures
(s390, ia64, x86, um), and an upcoming ext4 patch needs it because
ZERO_PAGE() references empty_zero_page, and we need it to zero out an
unitialized extents in ext4 files.

Signed-off-by: Theodore Ts'o [EMAIL PROTECTED]
---
 arch/ppc/kernel/ppc_ksyms.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/ppc/kernel/ppc_ksyms.c b/arch/ppc/kernel/ppc_ksyms.c
index c353502..418203e 100644
--- a/arch/ppc/kernel/ppc_ksyms.c
+++ b/arch/ppc/kernel/ppc_ksyms.c
@@ -60,6 +60,7 @@ long long __ashrdi3(long long, int);
 long long __ashldi3(long long, int);
 long long __lshrdi3(long long, int);
 
+EXPORT_SYMBOL(empty_zero_page);
 EXPORT_SYMBOL(clear_pages);
 EXPORT_SYMBOL(clear_user_page);
 EXPORT_SYMBOL(transfer_to_handler);
-- 
1.5.4.1.144.gdfee-dirty

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev