On Fri, Oct 02, 2020 at 03:39:35PM +, Van Leeuwen, Pascal wrote:
> > Then your company can not contribute in Linux kernel development, as
> > this is obviously not allowed by such a footer.
> >
> Interesting, this has never been raised as a problem until today ...
> Going back through my mail
On Mon, Aug 03, 2020 at 05:02:11PM -0600, Jens Axboe wrote:
> ext4 uses generic_file_read_iter(), which already supports this.
>
> Cc: Theodore Ts'o
> Signed-off-by: Jens Axboe
Applied, thanks. (And apologies for the delay.)
- Ted
On Sat, Aug 22, 2020 at 05:04:35PM +0530, Ritesh Harjani wrote:
> Refactor ext4_overwrite_io() to take struct ext4_map_blocks
> as it's function argument with m_lblk and m_len filled
> from caller
>
> There should be no functionality change in this patch.
>
> Signed-off-by: Ritesh Harjani
> ---
On Sat, Aug 29, 2020 at 10:54:02AM +0800, Dinghao Liu wrote:
> When ext4_journal_get_write_access() fails, we should
> terminate the execution flow and release n_group_desc,
> iloc.bh, dind and gdb_bh.
>
> Signed-off-by: Dinghao Liu
Thanks, applied.
- Ted
On Fri, Sep 18, 2020 at 10:36:35AM +0530, Ritesh Harjani wrote:
> In case if the file already has underlying blocks/extents allocated
> then we don't need to start a journal txn and can directly return
> the underlying mapping. Currently ext4_iomap_begin() is used by
> both DAX & DIO path. We can
On Thu, Sep 24, 2020 at 11:08:59AM +0200, Jan Kara wrote:
> On Tue 22-09-20 09:24:56, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > ext4_unregister_sysfs() only deletes the kobject. The reference to it
> > needs to be put separately, like ext4_put_super() does.
> >
> > This addresses the
On Wed, Sep 23, 2020 at 01:12:31AM +0800, Hui Su wrote:
> the struct name was modified long ago, but the comment still
> use struct handle_s.
>
> Signed-off-by: Hui Su
Tnanks, applied. I updated the commit summary to be:
jbd2: fix the comment of struct jbd2_journal_handle
On Wed, Oct 07, 2020 at 01:14:24PM -0700, Josh Triplett wrote:
>
> That sounds like a conversation that would have been a lot more
> interesting and enjoyable if it hadn't started with "can we shoot it in
> the head", and continued with the notion that anything other than
> e2fsprogs making
On Thu, Oct 08, 2020 at 03:22:59PM -0700, Josh Triplett wrote:
>
> I wasn't trying to make a *new* general principle or policy. I was under
> the impression that this *was* the policy, because it never occurred to
> me that it could be otherwise. It seemed like a natural aspect of the
>
On Wed, Sep 16, 2020 at 07:09:41AM +0800, Ming Lei wrote:
> > The problem is it's a bit tricky to revert 568f27006577, since there
> > is a merge conflict in blk_kick_flush(). I attempted to do the bisect
> > manually here, but it's clearly not right since the kernel is not
> > booting after the
On Thu, Sep 17, 2020 at 10:20:51AM +0800, Ming Lei wrote:
>
> Obviously there is other more serious issue, since 568f27006577 is
> completely reverted in your test, and you still see list corruption
> issue.
>
> So I'd suggest to find the big issue first. Once it is fixed, maybe
> everything
On Fri, Aug 21, 2020 at 03:26:35PM -0600, Jens Axboe wrote:
> >>> Resending this one, as I've been carrying it privately since May. The
> >>> necessary bits are now upstream (and XFS/btrfs equiv changes as well),
> >>> please consider this one for 5.9. Thanks!
> >>
> >> The necessary commit only
On Thu, Sep 03, 2020 at 11:55:28PM -0400, Theodore Y. Ts'o wrote:
> Worse, right now, -rc1 and -rc2 is causing random crashes in my
> gce-xfstests framework. Sometimes it happens before we've run even a
> single xfstests; sometimes it happens after we have successfully
> c
On Tue, Sep 15, 2020 at 03:33:03PM +0800, Ming Lei wrote:
> Hi Theodore,
>
> On Tue, Sep 15, 2020 at 12:45:19AM -0400, Theodore Y. Ts'o wrote:
> > On Thu, Sep 03, 2020 at 11:55:28PM -0400, Theodore Y. Ts'o wrote:
> > > Worse, right now, -rc1 and -rc2 is causing random
On Tue, Oct 27, 2020 at 01:53:31AM +0100, Edward Shishkin wrote:
> > > reiser4progs 1.1.x Software Framework Release Number (SFRN) 4.0.1 file
> > > system utilities should not be used to check/fix media formatted 'a
> > > priori' in SFRN 4.0.2 and vice-versa.
> >
> > Honestly, this is the first
On Tue, Oct 27, 2020 at 10:51:27AM +0100, Mauro Carvalho Chehab wrote:
> The kernel-doc markup that documents _fc_replay_callback is
> missing an asterisk, causing this warning:
>
> ../include/linux/jbd2.h:1271: warning: Function parameter or member
> 'j_fc_replay_callback' not described
On Wed, Oct 28, 2020 at 08:57:03AM +0530, Ritesh Harjani wrote:
>
> Well, I too noticed this yesterday while I was testing xfstests -g swap.
> Those tests were returning _notrun, hence that could be the reason why
> it didn't get notice in XFSTESTing from Ted.
Yeah, one of the things I discussed
On Thu, Dec 10, 2020 at 09:09:51AM +0100, Dmitry Vyukov wrote:
> > * [new tag] ext4-for-linus-5.8-rc1-2 ->
> > ext4-for-linus-5.8-rc1-2
> > ! [rejected] ext4_for_linus -> ext4_for_linus
> > (would clobber existing tag)
>
> Interesting. First time
On Tue, Dec 08, 2020 at 11:33:11PM -0800, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:15ac8fdb Add linux-next specific files for 20201207
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=1125c92350
> kernel
On Tue, Dec 22, 2020 at 12:28:53PM +0100, Jan Kara wrote:
> > Fix e810c942a325 ("ext4: save error info to sb through journal if
> > available")
> > by flushing work as part of rollback.
>
> Thanks for having a look. I don't think the fix is quite correct though. The
> flush_work() should be at
The following changes since commit 418baf2c28f3473039f2f7377760bd8f6897ae18:
Linux 5.10-rc5 (2020-11-22 15:36:08 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
tags/ext4_for_linus
for you to fetch changes up to
On Wed, Dec 23, 2020 at 10:12:54PM +0800, Zheng Yongjun wrote:
> Signed-off-by: Zheng Yongjun
Why is mutex_init() too late? We only take the mutex after we
mounting an ext4 file system, and that can't happen until ext4_init_fs
is called.
- Ted
>
On Thu, Dec 17, 2020 at 03:04:32PM +, Satya Tangirala wrote:
> This patch series adds support for metadata encryption to F2FS using
> blk-crypto.
Is there a companion patch series needed so that f2fstools can
check/repair a file system with metadata encryption enabled?
On Tue, Dec 01, 2020 at 04:13:01PM +0100, Richard Weinberger wrote:
> As soon the first file is opened, ext4 samples the mountpoint
> of the filesystem in 64 bytes of the super block.
> It does so using strlcpy(), this means that the remaining bytes
> in the super block string buffer are
On Thu, Dec 17, 2020 at 08:51:14PM +, Satya Tangirala wrote:
> On Thu, Dec 17, 2020 at 01:08:49PM -0500, Theodore Y. Ts'o wrote:
> > On Thu, Dec 17, 2020 at 03:04:32PM +, Satya Tangirala wrote:
> > > This patch series adds support for metadata encryption to F2FS usin
(Dropping off-topic lists)
On Mon, Dec 14, 2020 at 03:37:37PM +0100, Dmitry Vyukov wrote:
> > It's going to make everyone else's tags who pull from ext4.git messy,
> > though, with gobs of tags that probably won't be of use to them. It
> > does avoid the need to use git fetch --tags --force, and
On Thu, Nov 12, 2020 at 05:33:24PM +0800, Kang Wenlin wrote:
> From: Wenlin Kang
>
> The strncpy() function may create a unterminated string,
> use strscpy_pad() instead.
>
> This fixes the following warning:
>
> fs/ext4/super.c: In function '__save_error_info':
> fs/ext4/super.c:349:2:
On Fri, Nov 20, 2020 at 12:28:32PM -0600, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of just letting the code
> fall through to the next case.
>
> Link:
On Fri, Dec 11, 2020 at 02:54:24PM +0800, chenle...@gmail.com wrote:
> From: Lei Chen
>
> ext4_bio_write_page does not need wbc parameter, since its parameter
> io contains the io_wbc field. The io::io_wbc is initialized by
> ext4_io_submit_init which is called in ext4_writepages and
>
On Thu, Oct 22, 2020 at 04:52:52PM -0700, Brendan Higgins wrote:
> So you, me, Luis, David, and a whole bunch of other people have been
> thinking about this problem for a while. What if we just put
> kunitconfig fragments in directories along side the test files they
> enable?
>
> For example,
On Sun, Oct 25, 2020 at 04:44:38AM +, Matthew Wilcox wrote:
> @@ -3068,6 +3069,12 @@ static int submit_bh_wbc(int op, int op_flags, struct
> buffer_head *bh,
> }
>
> submit_bio(bio);
> +}
> +
> +static int submit_bh_wbc(int op, int op_flags, struct buffer_head *bh,
> +
On Mon, Nov 16, 2020 at 11:18:08AM +0100, Mauro Carvalho Chehab wrote:
> Kernel-doc markup should use this format:
> identifier - description
>
> They should not have any type before that, as otherwise
> the parser won't do the right thing.
>
> Also, some identifiers have different names
The following changes since commit 52d1998d09af92d44ffce7454637dd3fd1afdc7d:
Merge tag 'fscrypt-for-linus' of
git://git.kernel.org/pub/scm/fs/fscrypt/fscrypt (2020-11-10 10:05:37 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
On Wed, Oct 21, 2020 at 02:16:56PM -0700, Randy Dunlap wrote:
> On 10/21/20 2:15 PM, Brendan Higgins wrote:
> > On Tue, Oct 20, 2020 at 12:37 AM Geert Uytterhoeven
> > wrote:
> >>
> >> EXT4_KUNIT_TESTS selects EXT4_FS, thus enabling an optional feature the
> >> user may not want to enable. Fix
On Wed, Oct 21, 2020 at 04:07:15PM -0700, Randy Dunlap wrote:
> > I'm don't particularly care how this gets achieved, but please think
> > about how to make it easy for a kernel developer to run a specific set
> > of subsystem unit tests. (In fact, being able to do something like
> > "kunit.py
The following changes since commit a1b8638ba1320e6684aa98233c15255eb803fac7:
Linux 5.9-rc7 (2020-09-27 14:38:10 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
tags/ext4_for_linus
for you to fetch changes up to
The following changes since commit 09162bc32c880a791c6c0668ce0745cf7958f576:
Linux 5.10-rc4 (2020-11-15 16:44:31 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
tags/ext4_for_linus_fixes2
for you to fetch changes up to
On Tue, Nov 17, 2020 at 04:03:14AM +, Daniel Rosenberg wrote:
> This shifts the responsibility of setting up dentry operations from
> fscrypt to the individual filesystems, allowing them to have their own
> operations while still setting fscrypt's d_revalidate as appropriate.
>
> Most
What is the expected use case for Direct I/O using fscrypt? This
isn't a problem which is unique to fscrypt, but one of the really
unfortunate aspects of the DIO interface is the silent fallback to
buffered I/O. We've lived with this because DIO goes back decades,
and the original use case was
On Tue, Nov 17, 2020 at 04:03:13AM +, Daniel Rosenberg wrote:
> This adds a function to set dentry operations at lookup time that will
> work for both encrypted filenames and casefolded filenames.
>
> A filesystem that supports both features simultaneously can use this
> function during
On Tue, Nov 17, 2020 at 09:04:11AM -0800, Jaegeuk Kim wrote:
>
> I'd like to pick this patch series in f2fs/dev for -next, so please let me
> know
> if you have any concern.
No concern for me as far as ext4 is concerned, thanks!
- Ted
On Tue, Nov 17, 2020 at 10:23:58AM -0800, Linus Torvalds wrote:
> On Mon, Nov 16, 2020 at 10:35 AM Mimi Zohar wrote:
> >
> > We need to differentiate between signed files, which by definition are
> > immutable, and those that are mutable. Appending to a mutable file,
> > for example, would
On Mon, Nov 09, 2020 at 08:10:07PM +0100, Michal Suchanek wrote:
> Hello,
>
> after the tristate dax option change some applications fail to detect
> pmem devices because the dax option no longer shows in mtab when device
> is mounted with -o dax.
Which applications? Name them.
We *really*
One note... I'll double check, but on my XPS 13 9380, as I recall, I
have to manually disable autosuspend on all of the XHCI controllers
and internal hubs after running "powertop --auto-tune", or else any
external mouse attached to said USB device will be dead to the world
for 2-3 seconds if the
On Mon, Nov 30, 2020 at 04:15:23PM +0100, Jason A. Donenfeld wrote:
> I am willing to maintain random.c and have intentions to have a
> formally verified RNG. I've mentioned this to Ted before.
>
> But I think Ted's reluctance to not accept the recent patches sent to
> this list is mostly
On Thu, Dec 03, 2020 at 12:43:52AM +0100, Vlastimil Babka wrote:
>
> there was a bit of debate on Twitter about this, so I thought I would bring it
> here. Imagine a scenario where patch sits as a commit in -next and there's a
> bug
> report or fix, possibly by a bot or with some static
On Thu, Dec 03, 2020 at 08:18:23AM +0200, Amir Goldstein wrote:
> Here is a recent example, where during patch review, I requested NOT to
> include
> any stable backport triggers [1]:
> "...We should consider sending this to stable, but maybe let's merge
> first and let it
> run in master for a
On Fri, Dec 04, 2020 at 02:59:35PM +, David Howells wrote:
> Hi Chuck, Bruce,
>
> Why is gss_krb5_crypto.c using an auxiliary cipher? For reference, the
> gss_krb5_aes_encrypt() code looks like the attached.
>
> From what I can tell, in AES mode, the difference between the main cipher and
>
On Mon, Nov 30, 2020 at 02:22:22PM -0800, 'Brendan Higgins' via KUnit
Development wrote:
>
> Looks good to me. I would definitely like to pick this up. But yeah,
> in order to pick up 2/2 we will need an ack from either Ted or Iurii.
>
> Ted seems to be busy right now, so I think I will just
On Mon, Nov 16, 2020 at 11:11:50AM +0530, Arpitha Raghunandan wrote:
> Modify fs/ext4/inode-test.c to use the parameterized testing
> feature of KUnit.
>
> Signed-off-by: Arpitha Raghunandan <98.a...@gmail.com>
> Signed-off-by: Marco Elver
Acked-by: Theodore Ts'o
On Tue, Nov 17, 2020 at 02:07:06PM +, Satya Tangirala wrote:
> From: Eric Biggers
>
> Wire up ext4 with fscrypt direct I/O support. Direct I/O with fscrypt is
> only supported through blk-crypto (i.e. CONFIG_BLK_INLINE_ENCRYPTION must
> have been enabled, the 'inlinecrypt' mount option must
On Thu, Oct 15, 2020 at 03:26:28PM +0200, Alexander Lochmann wrote:
> Hi folks,
>
> I've updated the lock documentation according to our finding for
> transaction_t.
> Does this patch look good to you?
I updated the annotations to match with the local usage, e.g:
* When commit was
On Wed, Oct 21, 2020 at 12:25:03PM +0200, Jan Kara wrote:
> On Tue 20-10-20 16:22:01, Xianting Tian wrote:
> > bv_page can't be NULL in a valid bio_vec, so we can remove the NULL check,
> > as we did in other places when calling bio_for_each_segment_all() to go
> > through all bio_vec of a bio.
>
On Wed, Oct 21, 2020 at 02:23:26PM +0100, Colin King wrote:
> From: Colin Ian King
>
> Variable ex is assigned a variable that is not being read, the assignment
> is redundant and can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King
Thanks, applied.
On Thu, Dec 03, 2020 at 03:38:40PM +0100, Alexander Lochmann wrote:
>
>
> On 03.12.20 15:04, Theodore Y. Ts'o wrote:
> > On Thu, Oct 15, 2020 at 03:26:28PM +0200, Alexander Lochmann wrote:
> > > Hi folks,
> > >
> > > I've updated the l
On Fri, Oct 30, 2020 at 10:24:35AM +0800, Chao Yu wrote:
> include/trace/events/ext4.h belongs to ext4 module, add the file path into
> ext4 entry in MAINTAINERS.
>
> Signed-off-by: Chao Yu
Thanks, applied.
- Ted
(Resent with missing cc's, sorry.)
The following changes since commit 3cea11cd5e3b00d91caf0b4730194039b45c5891:
Linux 5.10-rc2 (2020-11-01 14:43:51 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
tags/ext4_for_linus_cleanups
for
On Tue, Sep 03, 2019 at 09:18:44AM -0700, Deepa Dinamani wrote:
>
> This prints a warning for each inode that doesn't extend limits beyond
> 2038. It is rate limited by the ext4_warning_inode().
> Looks like your filesystem has inodes that cannot be extended.
> We could use a different rate limit
On Tue, Sep 03, 2019 at 06:50:24AM -0700, Christoph Hellwig wrote:
> On Tue, Sep 03, 2019 at 02:48:32PM +0100, Al Viro wrote:
> > Not sure what would be the best way to do it... I don't mind breaking
> > the out-of-tree modules, whatever their license is; what I would rather
> > avoid is _quiet_
On Tue, Sep 03, 2019 at 02:31:06PM -0700, Deepa Dinamani wrote:
> > We need to drop this commit (ext4: Initialize timestamps limits), or
> > at least the portion which adds the call to the EXT4_INODE_SET_XTIME
> > macro in ext4.h.
>
> As Arnd said, I think this can be fixed by warning only when
On Tue, Sep 03, 2019 at 11:48:14PM +0200, Arnd Bergmann wrote:
> I think the warning as it was intended makes sense, the idea
> was never to warn on every inode update for file systems that
> cannot handle future dates, only to warn when we
>
> a) try to set a future date
> b) fail to do that
On Tue, Sep 03, 2019 at 03:47:54PM -0700, Deepa Dinamani wrote:
> > > diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> > > index 9e3ae3be3de9..5a971d1b6d5e 100644
> > > --- a/fs/ext4/ext4.h
> > > +++ b/fs/ext4/ext4.h
> > > @@ -835,7 +835,9 @@ do {
> > > \
> > >
On Tue, Sep 03, 2019 at 09:50:09PM -0700, Deepa Dinamani wrote:
> If we don't care to warn about the timestamps that are clamped in
> memory, maybe we could just warn when they are being written out.
> Would something like this be more acceptable? I would also remove the
> warning in ext4.h. I
On Wed, Sep 04, 2019 at 03:36:28PM +0800, zhao.ha...@zte.com.cn wrote:
> fix compiler error in ext4.hfs/ext4/ext4.h:30:27: fatal error:
> linux/version.h: No such file or directorySigned-off-by: Zhao Hang
> --- fs/ext4/ext4.h | 1 - 1 file changed, 1
> deletion(-)diff --git a/fs/ext4/ext4.h
e and Mathematics
> Business Minor | Gies College of Business
>
>
> On Fri, Aug 23, 2019 at 8:48 AM Theodore Y. Ts'o wrote:
> >
> > On Thu, Aug 15, 2019 at 09:11:51AM -0700, Ayush Ranjan wrote:
> > > This commit aims to fix the following issues in ext4 document
On Fri, Aug 23, 2019 at 04:41:59PM +0100, Will Deacon wrote:
>
> Given that these aren't functional changes, I've kept Ted's ack from v9
> and I'll queue these via arm64 assuming they pass testing.
>
> Ted -- please shout if you're not happy about that, and I'll drop the
> series.
That's fine,
On Fri, Aug 23, 2019 at 10:47:34AM +0800, Shaokun Zhang wrote:
> From: Yang Guo
>
> @es_stats_cache_hits and @es_stats_cache_misses are accessed frequently in
> ext4_es_lookup_extent function, it would influence the ext4 read/write
> performance in NUMA system.
> Let's optimize it using
On Sun, Aug 25, 2019 at 10:28:03AM -0700, Eric Biggers wrote:
> This patch is causing the following. Probably because there's no calls to
> percpu_counter_destroy() for the new counters?
Yeah, I noticed this from my test runs last night as well. It looks
like original patch was never tested
On Mon, Aug 26, 2019 at 04:24:20PM +0800, Shaokun Zhang wrote:
> > The other problem with this patch is that it initializes
> > es_stats_cache_hits and es_stats_cache_miesses too late. They will
> > get used when the journal inode is loaded. This is mostly harmless,
>
> I have checked it again,
On Mon, Aug 19, 2019 at 03:16:04PM +0800, Hsin-Yi Wang wrote:
> Introducing a chosen node, rng-seed, which is an entropy that can be
> passed to kernel called very early to increase initial device
> randomness. Bootloader should provide this entropy and the value is
> read from /chosen/rng-seed in
On Tue, Aug 20, 2019 at 03:56:24PM +0200, Sebastian Duda wrote:
>
> so the status of the files is inherited from the subsystem `INPUT MULTITOUCH
> (MT) PROTOCOL`?
>
> Is it the same with the subsystem `NOKIA N900 POWER SUPPLY DRIVERS`
> (respectively `POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS`)?
On Thu, Aug 15, 2019 at 03:22:45PM +0200, Arnd Bergmann wrote:
> If 64-bit Windows relies on a working EFI RTC implementation, we could
> decide to leave the driver enabled on 64-bit and only disable it for
> 32-bit EFI. That way, future distros would no longer have to worry about
> the localtime
e:
> >> On 8/24/20 4:56 AM, Jens Axboe wrote:
> >>> On 8/22/20 9:48 AM, Jens Axboe wrote:
> >>>> On 8/22/20 8:33 AM, Theodore Y. Ts'o wrote:
> >>>>> On Fri, Aug 21, 2020 at 03:26:35PM -0600, Jens Axboe wrote:
> &g
On Sat, Apr 25, 2020 at 02:16:24AM +0900, kyoungho koo wrote:
> I have found double typed comments "the the". So i modified it to
> one "the"
>
> Signed-off-by: kyoungho koo
Thanks, applied; apologies for this falling through the cracks!
- Ted
Looking at what the stress-ng fiemap workload is doing, and
it's interesting.
It is running 4 processes which are calling FIEMAP on a particular
file in a loop, with a 25ms sleep every 64 times. And then there is a
fifth process which is randomly writing to the file and calling
punch_hole to
On Mon, Aug 03, 2020 at 05:02:11PM -0600, Jens Axboe wrote:
> ext4 uses generic_file_read_iter(), which already supports this.
>
> Cc: Theodore Ts'o
> Signed-off-by: Jens Axboe
>
> ---
>
> Resending this one, as I've been carrying it privately since May. The
> necessary bits are now upstream
On Mon, Aug 10, 2020 at 02:21:58AM +, Xu Wang wrote:
> seq_puts is a lot cheaper than seq_printf, so use that to print
> literal strings.
>
> Signed-off-by: Xu Wang
Applied, thanks.
- Ted
On Thu, Sep 17, 2020 at 07:58:59PM -0700, Eric Biggers wrote:
> On Thu, Sep 17, 2020 at 10:05:35PM -0400, Sasha Levin wrote:
> > From: Theodore Ts'o
> >
> > [ Upstream commit 244adf6426ee31a83f397b700d964cff12a247d3 ]
> >
> > This fixes the direct I/O versus writeback race which can reveal
On Tue, Sep 15, 2020 at 09:50:13PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> On big endian CPUs, the ChaCha20-based CRNG is using the wrong
> endianness for the ChaCha20 constants.
>
> This doesn't matter cryptographically, but technically it means it's not
> ChaCha20 anymore. Fix it
On Thu, Sep 24, 2020 at 08:59:01AM +0800, Ming Lei wrote:
>
> The list corruption issue can be reproduced on kvm/qumu guest too when
> running xfstests(ext4) generic/038.
>
> However, the issue may become not reproduced when adding or removing memory
> debug options, such as adding KASAN.
Can
On Fri, Sep 04, 2020 at 02:46:53PM +0530, Ritesh Harjani wrote:
> After moving ext4's bmap to iomap interface, swapon functionality
> on files created using fallocate (which creates unwritten extents) are
> failing. This is since iomap_bmap interface returns 0 for unwritten
> extents and thus
On Thu, Sep 24, 2020 at 10:33:45AM -0400, Theodore Y. Ts'o wrote:
> HOWEVER, thanks to a hint from a colleague at $WORK, and realizing
> that one of the stack traces had virtio balloon in the trace, I
> realized that when I switched the GCE VM type from e1-standard-2 to
> n1-standard
On Wed, Oct 28, 2020 at 05:08:20AM +, Daniel Rosenberg wrote:
> This switches ext4 over to the generic support provided in libfs.
>
> Since casefolded dentries behave the same in ext4 and f2fs, we decrease
> the maintenance burden by unifying them, and any optimizations will
> immediately
The following changes since commit 96485e4462604744d66bf4301557d996d80b85eb:
Merge tag 'ext4_for_linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 (2020-10-22 10:31:08
-0700)
are available in the Git repository at:
On Fri, Sep 25, 2020 at 02:18:48PM -0700, Shakeel Butt wrote:
>
> Yes, you are right. Let's first get this patch tested and after
> confirmation we can update the commit message.
Thanks Shakeel! I've tested your patch, as well as reverting the
three commits that Linus had suggested, and both
On Mon, Jul 15, 2019 at 08:56:25PM +0200, Enrico Weigelt, metux IT consult
wrote:
> On 15.07.19 14:28, Masahiro Yamada wrote:
>
> >> The rule file contains a rule for creating debian/control and
> >> other metadata - this is done similar to the 'deb-pkg' make rule,
> >>
On Tue, Jul 16, 2019 at 05:58:49PM +0900, Masahiro Yamada wrote:
> I want debian/ to be kept as a drop-in directory
> for packagers, without replacing the upstream debian/rules.
>
> If a check-in source file is modified in anyway,
> scripts/setlocalversion would set -dirty flag,
> which I want to
On Tue, Jul 16, 2019 at 08:13:24PM +0200, Ingo Molnar wrote:
>
> * Thomas Gleixner wrote:
>
> > On Tue, 16 Jul 2019, Ingo Molnar wrote:
> >
> > >
> > > * Thomas Gleixner wrote:
> > >
> > > > The gold linker has known issues of failing the build in random and
> > > > predictible ways. H.J.
On Wed, Jul 17, 2019 at 12:25:14AM +0200, Thomas Gleixner wrote:
> > It's been my default system linker for years and I've had very few issues
> > with it and it's a big improvement when linking with LTO
>
> I understand, but the fact that you need to turn off config options in
> order to build a
On Wed, Jul 17, 2019 at 04:16:39PM +0200, Enrico Weigelt, metux IT consult
wrote:
>
> > In practice, that's not going to be a problem for most distributions.
> > The traditional way Debian-derived systems have done builds is
> > completely outside of git. So there will be a
On Tue, Sep 17, 2019 at 09:33:40AM +0200, Martin Steigerwald wrote:
> Willy Tarreau - 17.09.19, 07:24:38 CEST:
> > On Mon, Sep 16, 2019 at 06:46:07PM -0700, Matthew Garrett wrote:
> > > >Well, the patch actually made getrandom() return en error too, but
> > > >you seem more interested in the
(Adding linux-api since this patch proposes an API change; both by
changing the existing behavior, and adding new flags and possibly a
new system call.)
On Wed, Sep 18, 2019 at 04:57:58PM -0700, Linus Torvalds wrote:
> On Wed, Sep 18, 2019 at 2:17 PM Ahmed S. Darwish wrote:
> >
> > Since Linux
Hi Sandro,
It's not mentioned in the process documentation (but maybe we should
add this), is that it's up to individual maintainers about whether or
not whitespace cleanups are accepted outside of the staging tree.
That's because whitespace cleanups are a great "training wheel" for
newbies who
On Tue, Sep 10, 2019 at 06:21:07AM +0200, Ahmed S. Darwish wrote:
>
> The commit b03755ad6f33 (ext4: make __ext4_get_inode_loc plug), [1]
> which was merged in v5.3-rc1, *always* leads to a blocked boot on my
> system due to low entropy.
>
> The hardware is not a VM: it's a Thinkpad E480
On Tue, Sep 10, 2019 at 07:21:54PM +0100, Linus Torvalds wrote:
> On Tue, Sep 10, 2019 at 6:33 PM Ahmed S. Darwish wrote:
> >
> > While gnome-session is obviously at fault here by requiring
> > *blocking* randomness at the boot path, it's still not requesting
> > much, just (5 * 16) bytes to be
On Wed, Sep 11, 2019 at 06:00:19PM +0100, Linus Torvalds wrote:
> [0.231255] random: get_random_bytes called from
> start_kernel+0x323/0x4f5 with crng_init=0
>
> and that's this code:
>
> add_latent_entropy();
> add_device_randomness(command_line, strlen(command_line));
>
Thanks, I've applied this patch series.
- Ted
.404144-1-ira.we...@intel.com/
>
> To: linux-e...@vger.kernel.org
> To: Andreas Dilger
> To: "Theodore Y. Ts'o"
> To: Jan Kara
> To: Eric Biggers
Thanks, applied to the ext4-dax branch.
- Ted
On Mon, May 25, 2020 at 09:39:40PM +0200, Jan (janneke) Nieuwenhuizen wrote:
> The Hurd gained[0] support for moving the translator and author
> fields out of the inode and into the "gnu.*" xattr namespace.
>
> In anticipation of that, an xattr INDEX was reserved[1]. The Hurd has
> now been
On Thu, May 28, 2020 at 10:54:41PM -0400, Theodore Y. Ts'o wrote:
>
> Thanks, applied to the ext4-dax branch.
>
I spoke too soon. While I tried merging with the ext4.git dev branch,
a merge conflict made me look closer and I realize I needed to make
the following changes (see diff bet
501 - 600 of 886 matches
Mail list logo
