Re: [f2fs-dev] Proposal: Yet another possible fs-verity interface

On Thu, Feb 7, 2019 at 8:10 AM Theodore Y. Ts'o wrote: > > After doing a lot of thinking and conferring with the other fs-verity > developers, our current thinking is to simply move the Merkle tree > creation into the kernel. The upside of doing this is it completely > bypasses all of the

Re: [f2fs-dev] [PATCH v2] fs: Fix page_mkwrite off-by-one errors

On Fri, Nov 29, 2019 at 6:21 AM Andreas Gruenbacher wrote: > > +/** > + * page_mkwrite_check_truncate - check if page was truncated > + * @page: the page to check > + * @inode: the inode to check the page against > + * > + * Returns the number of bytes in the page up to EOF, > + * or -EFAULT if

Re: [f2fs-dev] [GIT PULL] f2fs for 5.6-rc6

On Wed, Mar 11, 2020 at 10:35 AM Jaegeuk Kim wrote: > > I actually merged the last three patches which were introduced yesterday. > > Others were merged over a week ago. No, three were done just before you sent the pull request, and then seven others were done yesterday. Yes, the rest were a

Re: [f2fs-dev] [GIT PULL] f2fs for 5.6-rc6

On Wed, Mar 11, 2020 at 9:27 AM Jaegeuk Kim wrote: > > Sorry for late pull request. Could you please consider this? I pulled this, and then immediately unpulled. Most (all?) of the commits have been committed basically minutes before you sent the pull request. That's simply not acceptable. Not

Re: [f2fs-dev] [GIT PULL] zstd changes for v5.16

On Wed, Nov 10, 2021 at 10:47 AM Nick Terrell wrote: > > I just wanted to make sure that you’ve received my pull request. I’m a newbie > here, so I want to make sure I’m not making a stupid mistake that means you’ve > missed my message. I’d hate for this PR to not even be considered for merging >

Re: [f2fs-dev] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

On Mon, Feb 28, 2022 at 12:29 PM Johannes Berg wrote: > > If we're willing to change the API for the macro, we could do > > list_for_each_entry(type, pos, head, member) > > and then actually take advantage of -Wshadow? See my reply to Willy. There is no way -Wshadow will ever happen. I

Re: [f2fs-dev] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

On Mon, Feb 28, 2022 at 12:16 PM Matthew Wilcox wrote: > > Then we can never use -Wshadow ;-( I'd love to be able to turn it on; > it catches real bugs. Oh, we already can never use -Wshadow regardless of things like this. That bridge hasn't just been burned, it never existed in the first

Re: [f2fs-dev] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

On Mon, Feb 28, 2022 at 11:56 AM Linus Torvalds wrote: > > I do wish we could actually poison the 'pos' value after the loop > somehow - but clearly the "might be uninitialized" I was hoping for > isn't the way to do it. Side note: we do need *some* way to do it. Because

Re: [f2fs-dev] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

On Mon, Feb 28, 2022 at 4:45 PM Linus Torvalds wrote: > > Yeah, except that's ugly beyond belief, plus it's literally not what > we do in the kernel. (Of course, I probably shouldn't have used 'min()' as an example, because that is actually one of the few places where we do exactly th

Re: [f2fs-dev] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

On Mon, Feb 28, 2022 at 1:47 PM Jakob Koschel wrote: > > The goal of this is to get compiler warnings right? This would indeed be > great. Yes, so I don't mind having a one-time patch that has been gathered using some automated checker tool, but I don't think that works from a long-term

Re: [f2fs-dev] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

On Mon, Feb 28, 2022 at 3:26 PM Matthew Wilcox wrote: > > #define ___PASTE(a, b) a##b > #define __PASTE(a, b) ___PASTE(a, b) > #define _min(a, b, u) ({ \ Yeah, except that's ugly beyond belief, plus it's literally not what we do in the kernel. Really. The "-Wshadow doesn't work on the

Re: [f2fs-dev] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

On Mon, Feb 28, 2022 at 4:38 PM Segher Boessenkool wrote: > > In C its scope is the rest of the declaration and the entire loop, not > anything after it. This was the same in C++98 already, btw (but in > pre-standard versions of C++ things were like you remember, yes, and it > was painful).

Re: [f2fs-dev] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

On Mon, Feb 28, 2022 at 12:10 PM Linus Torvalds wrote: > > We can do > > typeof(pos) pos > > in the 'for ()' loop, and never use __iter at all. > > That means that inside the for-loop, we use a _different_ 'pos' than outside. The thing that makes me th

Re: [f2fs-dev] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

On Tue, Mar 1, 2022 at 11:06 AM Linus Torvalds wrote: > > So instead of that simple "if (!entry)", we'd effectively have to > continue to use something that still works with the old world order > (ie that "if (list_entry_is_head())" model). Just to prove my

Re: [f2fs-dev] [PATCH 6/6] treewide: remove check of list iterator against head past the loop body

So looking at this patch, I really reacted to the fact that quite often the "use outside the loop" case is all kinds of just plain unnecessary, but _used_ to be a convenience feature. I'll just quote the first chunk in it's entirely as an example - not because I think this chunk is particularly

Re: [f2fs-dev] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

On Tue, Mar 1, 2022 at 2:58 PM David Laight wrote: > > Can it be resolved by making: > #define list_entry_is_head(pos, head, member) ((pos) == NULL) > and double-checking that it isn't used anywhere else (except in > the list macros themselves). Well, yes, except for the fact that then the name

Re: [f2fs-dev] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

On Tue, Mar 1, 2022 at 3:19 PM David Laight wrote: > > Having said that there are so few users of list_entry_is_head() > it is reasonable to generate two new names. Well, the problem is that the users of list_entry_is_head() may be few - but there are a number of _other_ ways to check "was that

Re: [f2fs-dev] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

On Mon, Feb 28, 2022 at 2:29 PM James Bottomley wrote: > > However, if the desire is really to poison the loop variable then we > can do > > #define list_for_each_entry(pos, head, member) \ > for (pos = list_first_entry(head, typeof(*pos), member);\ >

Re: [f2fs-dev] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

On Tue, Mar 1, 2022 at 10:14 AM Kees Cook wrote: > > The first big glitch with -Wshadow was with shadowed global variables. > GCC 4.8 fixed that, but it still yells about shadowed functions. What > _almost_ works is -Wshadow=local. Heh. Yeah, I just have long memories of "-Wshadow was a

Re: [f2fs-dev] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

On Wed, Mar 2, 2022 at 12:07 PM Kees Cook wrote: > > I've long wanted to change kfree() to explicitly set pointers to NULL on > free. https://github.com/KSPP/linux/issues/87 We've had this discussion with the gcc people in the past, and gcc actually has some support for it, but it's sadly tied

Re: [f2fs-dev] [GIT PULL] f2fs for 5.18

On Tue, Mar 22, 2022 at 10:37 AM Waiman Long wrote: > > AFAICS, the read-unfair rwsem code is created to resolve a potential > lock starvation problem that they found on linux-5.10.y stable tree. I > believe I have fixed that in the v5.11 kernel, see commit 2f06f702925 > ("locking/rwsem: Prevent

Re: [f2fs-dev] [GIT PULL] f2fs for 5.18

On Mon, Mar 21, 2022 at 1:39 PM Jaegeuk Kim wrote: > > In this cycle, f2fs has some performance improvements for Android workloads > such > as using read-unfair rwsems [...] I've pulled this, but that read-unfair rwsem code looks incredibly dodgy. Doing your own locking is always a bad sign,

Re: [f2fs-dev] [GIT PULL] f2fs for 5.18

On Tue, Mar 22, 2022 at 5:34 PM Tim Murray wrote: > > AFAICT, what's happening is that rwsem_down_read_slowpath > modifies sem->count to indicate that there's a pending reader while > f2fs_ckpt holds the write lock, and when f2fs_ckpt releases the write > lock, it wakes pending readers and hands

Re: [f2fs-dev] [GIT PULL] f2fs for 5.18

On Wed, Mar 23, 2022 at 9:26 AM Jaegeuk Kim wrote: > > OTOH, I was suspecting the major contetion would be > f2fs_lock_op -> f2fs_down_read(>cp_rwsem); > , which was used for most of filesystem operations. Very possible, I was just looking at a random one in f2fs/file.c obviously with no

Re: [f2fs-dev] [PATCH] unicode: clean up the Kconfig symbol confusion

On Tue, Jan 18, 2022 at 8:56 AM Christoph Hellwig wrote: > > Note that a lot of the IS_ENALBED() checks could be turned from cpp > statements into normal ifs, but this change is intended to be fairly > mechanic, so that should be cleaned up later. Yeah, that patch looks uglier than what I would

Re: [f2fs-dev] [PATCH] f2fs: Fix f2fs_truncate_partial_nodes ftrace event

On Tue, Mar 28, 2023 at 5:36 PM Jaegeuk Kim wrote: > > Thanks for heads-up. I sent a pull request having the above patch to Linus. .. and it's merged now. Linus ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net

Re: [f2fs-dev] [PATCH 0/5] Add the test_dummy_encryption key on-demand

On Tue, Feb 7, 2023 at 10:21 PM Eric Biggers wrote: > > I was going back and forth between this solution and instead having ext4 > and f2fs call fscrypt_destroy_keyring() on ->fill_super failure. (Or > using Linus's suggestion of adding the test dummy key as the very last > step of

Re: [f2fs-dev] [GIT PULL] f2fs updates for v4.2

On Wed, Jun 24, 2015 at 1:25 PM, Jaegeuk Kim jaeg...@kernel.org wrote: New features are: o per-file encryption (e.g., ext4) The new encrypted symlinks needed fixups for the changes that happened meanwhile to the symlink handling. I did all that in my merge, and I *think* I got it all right,

Re: [f2fs-dev] [PATCH 04/21] fs: Replace CURRENT_TIME with current_fs_time() for inode timestamps

On Wed, Jun 8, 2016 at 10:04 PM, Deepa Dinamani wrote: > CURRENT_TIME macro is not appropriate for filesystems as it > doesn't use the right granularity for filesystem timestamps. > Use current_fs_time() instead. Again - using the inode instead fo the syuperblock in tghis

Re: [f2fs-dev] [PATCH 04/21] fs: Replace CURRENT_TIME with current_fs_time() for inode timestamps

On Thu, Jun 9, 2016 at 1:38 PM, Deepa Dinamani wrote: > > 1. There are a few link, rename functions which assign times like this: > > - inode->i_ctime = dir->i_ctime = dir->i_mtime = CURRENT_TIME; > + inode->i_ctime = dir->i_ctime = dir->i_mtime = >

Re: [f2fs-dev] [PATCH v2 00/24] Delete CURRENT_TIME and CURRENT_TIME_SEC macros

On Sun, Jun 19, 2016 at 5:26 PM, Deepa Dinamani wrote: > The series is aimed at getting rid of CURRENT_TIME and CURRENT_TIME_SEC > macros. This version now looks ok to me. I do have a comment (or maybe just a RFD) for future work. It does strike me that once we

Re: [f2fs-dev] [GIT PULL] f2fs updates for v4.6

On Thu, Mar 17, 2016 at 5:58 PM, Jaegeuk Kim wrote: > > Note that, I did cherry-pick one patch and add another patch to resolve the > conflict against recent crypto changes. *please* don't do things like this! Now I have a conflict _anyway_, and because you added extra

Re: [f2fs-dev] [GIT PULL] f2fs updates for v4.6

On Thu, Mar 17, 2016 at 7:32 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: \> > Then later, you add the Makefile and Kconfig rules to start building > the files, but still nothing *uses* it. > > And then, after that, you have one commit that removes the old code

Re: [f2fs-dev] [GIT PULL] f2fs updates for v4.6

On Sun, Mar 20, 2016 at 3:58 PM, Jaegeuk Kim wrote: > > I made another pull request which removes the previous wrong commits and adds > a single commit to migrate the f2fs crypto into fs/crypto. Ok, merged. Please double-check the end result, but since most of the skcipher

Re: [f2fs-dev] [GIT PULL] f2fs updates for v4.6

Good catch, Eric. While waiting for explanations, I've committed the change to move back to just the page index. On Sat, Mar 26, 2016 at 6:47 AM, Eric Biggers wrote: > > Another question about the choice of IV. If the page index in CPU order is > (supposed to be) used as

Re: [f2fs-dev] [GIT PULL] f2fs updates for v4.6

On Sat, Mar 26, 2016 at 1:00 PM, Jaegeuk Kim wrote: > > After then, as Dave suggested, we needed to move the crypto libraries into > common fs/crypto, so that other filesystems can support that in common sense. > > Please check the below threads about this history. >

Re: [f2fs-dev] [GIT PULL] f2fs updates for v4.6

On Sat, Mar 26, 2016 at 1:41 PM, Theodore Ts'o wrote: > >> I also wonder if the xts_tweak should perhaps have both the page >> offset _and_ the inode number in it. Both ext4 and f2fs specify that >> xts tweak size to be 16 bytes, and right now fill the last 8 bytes >> with zero.

Re: [f2fs-dev] [GIT PULL] f2fs fixes for v4.6-rc3

On Sun, Apr 3, 2016 at 10:21 PM, Jaegeuk Kim wrote: > > Could you please pull the below commits for v4.6-rc3? Pulled, but.. > git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git > tags/f2fs-for-linus .. the above is a tag, but it's not signed, nor even

Re: [f2fs-dev] [GIT PULL] f2fs update for 4.10

On Mon, Dec 12, 2016 at 2:15 PM, Jaegeuk Kim wrote: > > Could you please consider this pull request? Pulled. Mind double-checking my resolution wrt commit 70fd76140a6c ("block,fs: use REQ_* flags directly")? Linus

Re: [f2fs-dev] [GIT PULL] f2fs update for 4.10

On Wed, Dec 14, 2016 at 11:18 AM, Jaegeuk Kim wrote: > > BTW, I just downloaded mainline, and tried to build a debian package but > failed due to missing Documentation/Changes. > > I've found out that it was renamed by commit 186128f753 > ("docs-rst: add documents to

Re: [f2fs-dev] [GIT PULL] f2fs update for 4.18-rc1

On Mon, Jun 11, 2018 at 9:52 AM Jaegeuk Kim wrote: > > Eric Biggers (4): > f2fs: call unlock_new_inode() before d_instantiate() Btw, in my merge, this got superseded by commit 1e2e547a93a00ebc2158 ("do d_instantiate/unlock_new_inode combinations safely"), because the ordering of that

Re: [f2fs-dev] [GIT PULL] f2fs update for 4.18-rc1

On Mon, Jun 11, 2018 at 9:52 AM Jaegeuk Kim wrote: > > In order to avoid old MM bug [1], we decided not to use __GFP_ZERO > for the mapping for node and meta page caches. > > [1] https://lkml.org/lkml/2018/4/8/661 Hmm. The patch there looks correct, and anybody who relies on slab constructors is

Re: [f2fs-dev] [GIT PULL] f2fs update for 4.18-rc1

On Mon, Jun 11, 2018 at 10:40 AM Jaegeuk Kim wrote: > > Heh, I forgot to link the latest results. The MM fix was merged by: Ahh. Different fix. I did check that that original patch you mentioned wasn't merged, and didn't react to the other patches. Thanks, Linus

Re: [f2fs-dev] [GIT PULL] f2fs update for 4.18-rc1

On Mon, Jun 11, 2018 at 11:21 AM Matthew Wilcox wrote: > > Argh, you used my Outlook email address, so you get top-posting Hey, I think it's what you uise for your commit messages, I think that's where I got it from.. > The radix tree does rely on constructors still. One of the things on my

Re: [f2fs-dev] [GIT PULL] f2fs update for 4.20-rc1

On Wed, Oct 24, 2018 at 3:05 AM Jaegeuk Kim wrote: > > git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git > tags/f2fs-for-4.20-rc1 Pulled, Linus ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net

Re: [f2fs-dev] [PATCH v2 01/12] fs-verity: add a documentation file

On Fri, Dec 21, 2018 at 8:20 PM Theodore Y. Ts'o wrote: > > On Fri, Dec 21, 2018 at 11:13:07AM -0800, Linus Torvalds wrote: > > > > In other words: either the model is that the file *itself* contains > > its own merkle tree that validates the file, or it isn't. You ca

Re: [f2fs-dev] [PATCH v2 01/12] fs-verity: add a documentation file

On Fri, Dec 21, 2018 at 7:47 AM Theodore Y. Ts'o wrote: > > Linus --- we're going round and round, and I don't think this is > really a technical dispute at this point, but rather an aesthetics > one. Grr. So honestly, I personally *like* the model of "the file contains its own validation data"

Re: [f2fs-dev] Proposal: A new fs-verity interface

On Fri, Jan 25, 2019 at 10:25 AM Dave Chinner wrote: > > So it's still "file data" that the filesystem has to magically > transform into hidden metadata in some manner. What writes the > merkel tree into a file, and why can't it just write it direct to > the filesystem rather than having to use

Re: [f2fs-dev] Proposal: A new fs-verity interface

On Fri, Jan 25, 2019 at 12:22 PM Theodore Y. Ts'o wrote: > > > > I understand that you don't want to load the whole merkle tree into > > memory, and that is the reason that you want to point to some "stable > > on disk" area, but the hole punching does seem to be a particularly > > nasty part of

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

On Thu, 28 Sept 2023 at 14:28, Theodore Ts'o wrote: > > 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. :-) Well, you will find that real apps do

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

On Thu, 28 Sept 2023 at 20:50, Amir Goldstein wrote: > > OTOH, it is perfectly fine if the vfs wants to stop providing sub 100ns > services to filesystems. It's just going to be the fs problem and the > preserved pre-historic/fine-grained time on existing files would only > need to be provided in

Re: [f2fs-dev] [GIT PULL] f2fs update for 6.8-rc1

On Thu, 11 Jan 2024 at 10:28, Jaegeuk Kim wrote: > > git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git > tags/f2fs-for-6.8-rc1 Hmm. I got a somewhat confusing conflict in f2fs_rename(). And honestly, I really don't know what the right resolution is. What I ended up with was

Re: [f2fs-dev] [GIT PULL] f2fs update for 6.8-rc1

On Thu, 11 Jan 2024 at 23:12, Al Viro wrote: > > Where would you end up with old_dir_page != NULL and old_dir_entry == NULL? D'oh. You are of course right, and I missed that connection. Happily my merge still works, just isn't as minimal as yours. I see that Jaegeuk already posted the patch

Re: [f2fs-dev] [PATCH v6 0/9] Support negative dentries on case-insensitive ext4 and f2fs

On Thu, 23 Nov 2023 at 07:57, Gabriel Krisman Bertazi wrote: > > The problem I found with that approach, which I originally tried, was > preventing concurrent lookups from racing with the invalidation and > creating more 'case-sensitive' negative dentries. Did I miss a way to > synchronize with

Re: [f2fs-dev] [PATCH v6 0/9] Support negative dentries on case-insensitive ext4 and f2fs

On Wed, 22 Nov 2023 at 13:19, Al Viro wrote: > > The serious gap, AFAICS, is the interplay with open-by-fhandle. So I'm obviously not a fan of igncase filesystems, but I don't think this series actually changes any of that. > It's not unfixable, but we need to figure out what to do when >

Re: [f2fs-dev] [PATCH v6 0/9] Support negative dentries on case-insensitive ext4 and f2fs

On Mon, 20 Nov 2023 at 07:06, Christian Brauner wrote: > > My current understanding is that core dcache stuff is usually handled by > Al. And he's got a dcache branches sitting in his tree. > > So this isn't me ignoring you in any way. My hands are tied and so I > can't sort this out for you

Re: [f2fs-dev] [PATCH v6 0/9] Support negative dentries on case-insensitive ext4 and f2fs

On Mon, 20 Nov 2023 at 18:29, Linus Torvalds wrote: > > It's a bit complicated, yes. But no, doing things one unicode > character at a time is just bad bad bad. Put another way: the _point_ of UTF-8 is that ASCII is still ASCII. It's literally why UTF-8 doesn't suck. So you can stil

Re: [f2fs-dev] [PATCH v6 0/9] Support negative dentries on case-insensitive ext4 and f2fs

On Mon, 20 Nov 2023 at 18:03, Theodore Ts'o wrote: > > On Mon, Nov 20, 2023 at 10:07:51AM -0800, Linus Torvalds wrote: > > I'm looking at things like > > generic_ci_d_compare(), and it hurts to see the mindless "let's do > > lookups and compares one utf8 characte