3,3 +571,34 @@ config RANDOM_TRUST_CPU
has not installed a hidden back door to compromise the CPU's
random number generation facilities. This can also be configured
at boot with "random.trust_cpu=on/off".
+
+config RANDOM_BLOCK
+ bool "Block if getrandom is cal
On Sat, Sep 14, 2019 at 06:10:47PM -0700, Linus Torvalds wrote:
> > We could return 0 for success, and yet "the best we
> > can do" could be really terrible.
>
> Yes. Which is why we should warn.
I'm all in favor of warning. But people might just ignore the
warning. We warn today about systemd
On Sat, Sep 14, 2019 at 03:32:46PM -0700, Linus Torvalds wrote:
> > Worse, it won't even accomplish something against an obstinant
> > programmers. Someone who is going to change their program to sleep
> > loop waiting for getrandom(2) to not return with an error can just as
> > easily check for
On Sat, Sep 14, 2019 at 11:11:26PM +0200, Ahmed S. Darwish wrote:
> > > I've sent an RFC patch at [1].
> > >
> > > [1] https://lkml.kernel.org/r/20190914122500.GA1425@darwi-home-pc
> >
> > Looks reasonable to me. Except I'd just make it simpler and make it a
> > big WARN_ON_ONCE(), which is a lot
On Sat, Sep 14, 2019 at 11:25:09AM +0200, Ahmed S. Darwish wrote:
> Unfortunately, it only made the early fast init faster, but didn't fix
> the normal crng init blockage :-(
Yeah, I see why; the original goal was to do the fast init so that
using /dev/urandom, even before we were fully
At the Maintainer's Summit yesterday, we created a new mailing list:
workfl...@vger.kernel.org, where various Maintainers can share their
workflows for handling patch review, collection, testing, and
submission.
We will also be discussing what requirements should be for
infrastructure that will
On Thu, Sep 12, 2019 at 05:44:21AM +0200, Ahmed S. Darwish wrote:
> > People have suggested adding a new getrandom flag,
> > GRND_I_KNOW_THIS_IS_INSECURE,
> > or some such, which wouldn't block and would return "best efforts"
> > randomness. I haven't been super enthusiastic about such a flag
>
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));
>
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 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
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 Fri, Sep 06, 2019 at 02:58:07PM +0100, Colin King wrote:
> From: Colin Ian King
>
> Don't populate the array 'token' on the stack but instead make it
> static const. Makes the object code smaller by 234 bytes.
>
> Before:
>text data bss dec hex filename
>5371
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
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 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 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 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 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 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
#syz invalid
This has already been fixed in the latest linux-next
On Thu, Aug 29, 2019 at 06:11:35PM -0700, Andy Lutomirski wrote:
> This series also removes the blocking pool and makes /dev/random
> work just like getentropy(..., 0) and makes GRND_RANDOM a no-op. I
> believe that Linux's blocking pool has outlived its usefulness.
> Linux's CRNG generates
On Thu, Aug 29, 2019 at 06:03:57PM +0800, Hsin-Yi Wang wrote:
> On Thu, Aug 29, 2019 at 1:36 AM Kees Cook wrote:
> >
> > Can this please be a boot param (with the default controlled by the
> > CONFIG)? See how CONFIG_RANDOM_TRUST_CPU is wired up...
> >
>
> Currently rng-seed read and added in
On Wed, Aug 28, 2019 at 05:19:17PM +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 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 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 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 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,
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 Thu, Aug 15, 2019 at 09:11:51AM -0700, Ayush Ranjan wrote:
> This commit aims to fix the following issues in ext4 documentation:
> - Flexible block group docs said that the aim was to group block
> metadata together instead of block group metadata.
> - The documentation consistly uses
On Wed, Aug 14, 2019 at 12:54:08PM +0300, Rakesh Pandit wrote:
> Really enable warning when CONFIG_EXT4_DEBUG is set and fix missing
> first argument. This was introduced in commit ff95ec22cd7f ("ext4:
> add warning to ext4_convert_unwritten_extents_endio") and splitting
> extents inside endio
On Thu, Aug 22, 2019 at 03:15:22PM +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 Thu, Aug 22, 2019 at 03:37:43PM +0900, Austin Kim wrote:
> __es_insert_extent() never returns -EINVAL after BUG is executed.
> So remove unreachable code.
> ---
> fs/ext4/extents_status.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/fs/ext4/extents_status.c
On Wed, Aug 21, 2019 at 02:10:13PM +0200, Enrico Weigelt, metux IT consult
wrote:
>
> > We certainly don't talk about "inheritance" when we talk about
> > maintainers and sub-maintainers.
>
> What's the exact definition of the term "sub-maintainer" ?
>
> Somebody who's maintaining some defined
On Wed, Aug 21, 2019 at 09:39:28AM +0300, Ard Biesheuvel wrote:
>
> Whether to trust the firmware provided entropy is a policy decision,
> and typically, we try to avoid dictating policy in the kernel, and
> instead, we try to provide a sane default but give the user control
> over it.
>
> So 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 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 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
On Tue, Aug 13, 2019 at 10:30:34AM -0700, Linus Torvalds wrote:
>
> I suspect the only actual _valid_ use in the kernel for a time zone
> setting is likely for RTC clock setting, but even that isn't really
> "global", as much as "per RTC".
As I recall (and I may or may not have been original for
On Mon, Aug 05, 2019 at 11:44:19PM +0100, Colin King wrote:
> From: Colin Ian King
>
> Currently when the call to ext4_htree_store_dirent fails the error return
> variable 'ret' is is not being set to the error code and variable count is
> instead, hence the error code is not being returned.
On Sat, Aug 03, 2019 at 11:30:22AM +0200, Arnd Bergmann wrote:
>
> I see in the ext4 code that we always try to expand i_extra_size
> to s_want_extra_isize in ext4_mark_inode_dirty(), and that
> s_want_extra_isize is always at least s_min_extra_isize, so
> we constantly try to expand the inode
On Fri, Aug 02, 2019 at 09:00:52PM +0200, Arnd Bergmann wrote:
>
> I must have misunderstood what the field says. I expected that
> with s_min_extra_isize set beyond the nanosecond fields, there
> would be a guarantee that all inodes have at least as many
> extra bytes already allocated. What
On Fri, Aug 02, 2019 at 12:39:41PM +0200, Arnd Bergmann wrote:
> Is it correct to assume that this kind of file would have to be
> created using the ext3.ko file system implementation that was
> removed in linux-4.3, but not usiing ext2.ko or ext4.ko (which
> would always set the extended
On Thu, Aug 01, 2019 at 12:18:28PM -0700, Deepa Dinamani wrote:
> > Say you have a filesystem with s_inode_size > 128 where not all of the
> > ondisk inodes have been upgraded to i_extra_isize > 0 and therefore
> > don't support nanoseconds or times beyond 2038. I think this happens on
> > ext3
On Sat, Jul 27, 2019 at 08:44:23AM +1000, Dave Chinner wrote:
> >
> > This looks like something that could hit every file systems, so
> > shouldn't we fix this in common code? We could also look into
> > just using memalloc_nofs_save for the page cache allocation path
> > instead of the
On Wed, Jul 24, 2019 at 01:09:28PM -0700, David Miller wrote:
> From: Eric Biggers
> Date: Wed, 24 Jul 2019 11:37:12 -0700
>
> > We can argue about what words to use to describe this situation, but
> > it doesn't change the situation itself.
>
> And we should argue about those words because it
On Mon, Jul 22, 2019 at 5:13 PM Qian Cai wrote:
>
> On Fri, 2019-07-19 at 17:47 -0400, Qian Cai wrote:
> > On Thu, 2019-07-18 at 16:29 -0700, David Miller wrote:
> > > From: Qian Cai
> > > Date: Thu, 18 Jul 2019 19:26:47 -0400
> > >
> > > >
> > > >
> > > > > On Jul 18, 2019, at 5:21 PM, Bill
On Wed, Jul 03, 2019 at 04:16:54PM +0800, Shi Siyuan wrote:
> From: shisiyuan
>
> Remove unnecessary error check in ext4_file_write_iter(),
> because this check will be done in upcoming later function --
> ext4_write_checks() -> generic_write_checks()
>
> Change-Id:
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 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 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 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 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 Wed, Jul 3, 2019 at 10:03 AM Brian Vazquez wrote:
>
> This introduces a new command to retrieve a variable number of entries
> from a bpf map wrapping the existing bpf methods:
> map_get_next_key and map_lookup_elem
>
> To start dumping the map from the beginning you must specify NULL as
> the
to change, this code would need
> to be updated too.
>
> Co-authored-by: Iago López Galeiras
> Signed-off-by: Alban Crequy
> Signed-off-by: Iago López Galeiras
>
> ---
>
> Changes since v1:
> - add netns_dev (review from Alexei)
>
> Changes since v2:
> - repla
~~
> | sys_bpf
>
> Signed-off-by: Vineet Gupta
Acked-by: Yonghong Song
> ---
> v1 -> v2
> - Only add syscall nr for ARC, as asm-generic won't work with arm/sh [Y
> Song]
> ---
> tools/lib/bpf/bpf.c | 2 ++
> 1 file changed, 2 insertions(+)
&
On Thu, Mar 7, 2019 at 10:12 PM Bo YU wrote:
>
> Sparse warning below:
>
> sudo make C=2 CF=-D__CHECK_ENDIAN__ M=net/bpf/
> CHECK net/bpf//test_run.c
> net/bpf//test_run.c:19:77: warning: Using plain integer as NULL pointer
> ./include/linux/bpf-cgroup.h:295:77: warning: Using plain integer as
On Wed, Mar 06, 2019 at 01:25:17PM +0100, Thomas Gleixner wrote:
> > It's been 25 years since Linux added support for ELF. Can we just
> > delete the a.out support entirely now? According to the Linux-ELF HOWTO,
> > support was added in 1.1.52 (August 1994). It's pretty much necromancy
> > at
(Adding linux-mm and moving linux-ext4 and linux-kernel to the bcc
list...)
On Mon, Mar 04, 2019 at 05:02:55PM +0100, Pavel Machek wrote:
>
> This happened on trying to sync filesystems with unison:
>
> Any ideas?
>
> Should I be forcing fsck soon?
>
On Tue, Feb 26, 2019 at 05:35:04PM +0100, Jan Kara wrote:
> On Wed 27-02-19 00:07:27, Liu Song wrote:
> > In jbd2_get_transaction, a new transaction is initialized,
> > and set to the j_running_transaction. No need for a return
> > value, so remove it.
> > Also, adjust some comments to match the
On Wed, Feb 27, 2019 at 10:58:50AM +0100, Dmitry Vyukov wrote:
> Peter, Ingo, do you have any updates on the
> perf_event_open/sched_setattr stalls? This bug cause assorted hangs
> throughout kernel and so is nasty.
>
> syzkaller tries to remove all syscalls from reproducers one-by-one.
> Somehow
TL;DR: This doesn't appear to be ext4 specific, and seems to involve
an unholy combination of the perf_event_open(2) and sendfile(2) system
calls.
On Mon, Feb 25, 2019 at 10:50:05PM -0800, syzbot wrote:
> syzbot found the following crash on:
>
> HEAD commit:8a61716ff2ab Merge tag
On Thu, Feb 21, 2019 at 07:24:14PM +, Bernd Edlinger wrote:
>
> My observation, with a previous attempt (v3) of my patch is that a system
> where only interrupt randomness is available it takes typically 2 minutes
> to accomplish the initial seeding of the CRNG, if from there one has to
>
On Thu, Feb 21, 2019 at 07:34:15AM -0800, Luis Chamberlain wrote:
> On Sat, Feb 16, 2019 at 01:28:35PM -0500, Theodore Y. Ts'o wrote:
> > The block/*, loop/* and scsi/* tests in blktests do seem to be in
> > pretty good shape. The nvme, nvmeof, and srp tests are *definitely*
&g
On Mon, Feb 04, 2019 at 01:17:43PM +0300, Konstantin Khlebnikov wrote:
> This is useful for moving journal thread into cgroup or
> for tracing it with ftrace/perf/blktrace.
>
> For now the only way is `pgrep jbd2/$DISK` but this is not reliable:
> name may be longer than "comm" limit and any task
On Mon, Jan 14, 2019 at 12:00:45PM +0100, Geert Uytterhoeven wrote:
> All other configuration options for the ext* family of file systems use
> "Ext%u" instead of "EXT%u".
>
> Fixes: 6ba495e9259cd9a0 ("ext4: Add configurable run-time mballoc debugging")
> Signed-off-by: Geert Uytterhoeven
On Mon, Jan 14, 2019 at 09:39:44PM +0100, Mathieu Malaterre wrote:
> There is a plan to build the kernel with -Wimplicit-fallthrough and
> these places in the code produced warnings (W=1). Fix them up.
>
> This commit remove the following warnings:
>
> fs/ext4/indirect.c:1182:6: warning: this
On Mon, Jan 14, 2019 at 09:39:43PM +0100, Mathieu Malaterre wrote:
> There is a plan to build the kernel with -Wimplicit-fallthrough and
> these places in the code produced warnings (W=1). Fix them up.
>
> This commit remove the following warnings:
>
> fs/ext4/hash.c:233:15: warning: this
Hi Brend,
I've been looking at your patch, and as far as the core part of what
you're patching, I think this patch below is a conceptually simpler
way of fixing the original core problem. Please take a look and let
me know what you think.
There are some other auxiliary things that your patch is
On Thu, Feb 14, 2019 at 06:48:22PM -0800, James Bottomley wrote:
> Well, we differ on the value of running regression tests, then. The
> whole point of a test infrastructure is that it's simple to run 'make
> check' in autoconf parlance. xfstests does provide a useful baseline
> set of
On Fri, Feb 15, 2019 at 01:58:20PM +, Bernd Edlinger wrote:
> Reading from /dev/random may return data while the getrandom
> syscall is still blocking.
>
> Those bytes are not yet cryptographically secure.
>
> The first byte from /dev/random can have as little
> as 8 bits entropy estimation.
On Fri, Feb 15, 2019 at 02:03:06PM -0800, Sultan Alsawaf wrote:
> All users of the struct entropy_store spinlock use the irqsave spinlock
> variant.
> Spinlock users of the same lock should use be consistent in their use of a
> certain spinlock primitive, which makes add_interrupt_randomness()'s
On Fri, Feb 15, 2019 at 06:59:48PM +0200, Meelis Roos wrote:
> The result of the bisection is
> [88dbcbb3a4847f5e6dfeae952d3105497700c128] blkdev: avoid migration stalls for
> blkdev pages
>
> Is that result relevant for the problem or should I continue bisecting
> between 4.20.0 and the so far
The following changes since commit 49a57857aeea06ca831043acbb0fa5e0f50602fd:
Linux 5.0-rc3 (2019-01-21 13:14:44 +1300)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
tags/ext4_for_linus_stable
for you to fetch changes up to
On Fri, Feb 08, 2019 at 08:14:45AM -0500, Prarit Bhargava wrote:
>
> Yes, that's exactly the case. During early boot we initialize the boot cpu's
> stack canary at arch/x86/include/asm/stackprotector.h:75 which is well before
> the random driver is initialized. The same code is called for all
On Thu, Feb 07, 2019 at 12:28:09PM +0100, Greg KH wrote:
> > > These are very useful in fixing esp. first-bootup delays of VMs due to
> > > entropy starvation.
> > >
> > >
> > > commit 39a8883a2b989d1d21bd8dd99f5557f0c5e89694
> > > Author: Theodore Ts'o
> > > Date: Tue Jul 17 18:24:27 2018
On Mon, Feb 4, 2019 at 9:49 AM Stanislav Fomichev wrote:
>
> On 02/01, Dmitry Vyukov wrote:
> > Hello,
> >
> > The following program leads to an unkillable process that eats CPU in
> > an infinite loop in BPF_PROG_TEST_RUN syscall. But kernel does not
> > self-detect cpu/rcu/task stalls either.
On Sun, Feb 03, 2019 at 08:09:37AM -0500, Prarit Bhargava wrote:
> Ted, the bug I'm trying to fix is the warning:
>
> random: get_random_bytes called from start_kernel+0x8e/0x587 with crng_init=0
>
> during early boot. Even with the kernel parameter the warning appears.
Sometimes the warnings
On Fri, Feb 01, 2019 at 01:08:31PM -0500, Prarit Bhargava wrote:
> After 43838a23a05f ("random: fix crng_ready() test") early boot calls to
> get_random_bytes() will warn on x86 because the crng is not initialized.
> For example,
>
> random: get_random_bytes called from start_kernel+0x8e/0x587
On Thu, Jan 24, 2019 at 10:29:50AM -0800, Eric Biggers wrote:
>
> Hi Ted, that sounds good to me. I assume you know how to get that set up?
> Also, should I go ahead and send a patch that adds myself to the MAINTAINERS
> file?
I have the request to the git.kernel.org folks and the edits to the
On Thu, Jan 10, 2019 at 05:01:17PM -0800, Eric Biggers wrote:
>
> Indeed, Chandan Rajendra sent out a new version of the patch which fixes the
> problem (by removing the 'select BLOCK' from fs/ubifs/Kconfig), but it never
> made it into the fscrypt tree and hence never made it into linux-next.
>
On Mon, Jan 21, 2019 at 03:51:58PM -0800, Darrick J. Wong wrote:
>
> I disagree with upending 13 years of established precedent for user
> visible behavior. We possibly could've pulled this off ten years ago,
> but it's wy too late now. Too much work, too little gain.
I remember the
On Mon, Jan 21, 2019 at 05:26:42PM +0100, Greg Kroah-Hartman wrote:
> By default, the kernel will automatically load the module of any line
> dicipline that is asked for. As this sometimes isn't the safest thing
> to do, provide a sysctl to disable this feature.
>
> By default, we
On Fri, Jan 18, 2019 at 05:14:38PM +0100, Jann Horn wrote:
> Multiple filesystems can already return EFSCORRUPTED errors to userspace;
> however, so far, definitions of EFSCORRUPTED were in filesystem-private
> headers.
>
> I wanted to use EUCLEAN to indicate data corruption in the VFS layer;
>
On Wed, Jan 09, 2019 at 07:51:11AM +, Yang, Shunyong wrote:
> Hi, Vinod,
> Thanks for your information. I will check with our IT.
> Shunyong.
The usual answer is generally over-enthuastic application of anti-SPAM
techniques, especially DMARC, which is fundamentally mailing-list hostile.
On Sun, Jan 06, 2019 at 09:20:07AM -0800, Eric Biggers wrote:
> Hi Ted, that tag is still on an old commit. Probably you forgot to push.
My scripts check to see that it was right (at least from my view of
git.kernel.org) before it generates the push. I just checked and it's
correct now, and I
The following changes since commit 7beb01f74415c56f5992922b5b902b45d365e694:
f2fs: clean up f2fs_sb_has_##feature_name (2018-11-26 15:53:55 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/fscrypt.git
tags/fscrypt_for_linus
for you to
The following changes since commit 18f2c4fcebf2582f96cbd5f2238f4f354a0e4847:
ext4: check for shutdown and r/o file system in ext4_write_inode()
(2018-12-19 14:36:58 -0500)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
On 2019/1/1 9:22, dann frazier wrote:
On Mon, Nov 26, 2018 at 06:43:00PM +, Salil Mehta wrote:
From: Peng Li
Port 0/1 of HiP08 supports 10G and 25G. This patch adds a
change to configure NIC port speed same as that of optical
module(SFP/QFSP). Driver gets the optical module speed and
On Sat, Dec 29, 2018 at 03:37:21AM +0100, Dominique Martinet wrote:
> > Are there going to be cases where a process or a thread will sometimes
> > want the 64-bit interface, and sometimes want the 32-bit interface?
> > Or is it always going to be one or the other? I wonder if we could
> > simply
On Fri, Dec 28, 2018 at 11:18:18AM +, Peter Maydell wrote:
> In general inodes and offsets start from 0 and work up --
> so almost all of the time they don't actually overflow.
> The problem with ext4 directory hash "offsets" is that they
> overflow all the time and immediately, so instead of
+---+ .:\:\:/:/:.
| PLEASE DO NOT |:.:\:\:/:/:.:
| FEED THE TROLLS | :=.' - - '.=:
| | '=(\ 9 9 /)='
| Thank you,
The following changes since commit 2e6e902d185027f8e3cb8b7305238f7e35d6a436:
Linux 4.20-rc4 (2018-11-25 14:19: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
for you to fetch changes up to
On Sat, Dec 22, 2018 at 08:10:07PM -0800, Matthew Wilcox wrote:
> Pretty much every file format has the ability to put arbitrary blocks
> of information into a file somewhere the tools which don't know about
> it will skip it. For example, ZIP "includes an extra field facility
> within file
On Sat, Dec 22, 2018 at 02:47:22PM -0800, Linus Torvalds wrote:
> So I want to understand why this was made a filesystem operation in
> the first place. What's fs-specific about this implementation?
These are the things which are fs-specific.
*) We have to splice into the file system's readpage
On Fri, Dec 21, 2018 at 11:13:07AM -0800, Linus Torvalds wrote:
>
> I do agree that your particular model is pretty damn broken in lots of ways.
>
> Why is it filesystem specific? If the whole point is that the file
> itself has its own verification data (which I like), then I don't see
> why
On Fri, Dec 21, 2018 at 07:53:54AM -0800, Matthew Wilcox wrote:
> In contrast to "we'll just fix it up later" (which usually applies
> to in-kernel interfaces), we have a policy of not breaking userspace,
> so accepting this interface means setting it in stone. We should get
> it right.
I'm not
On Thu, Dec 20, 2018 at 11:04:47PM -0800, Christoph Hellwig wrote:
> Ted, I think you know yourself this isn't true. Whenever we added
> useful interface to one of the major file systems we had other pick
> it up, and that is a good thing because the last thing we need is
> fragmentation of
On Thu, Dec 20, 2018 at 08:35:52AM +1100, Dave Chinner wrote:
>
> The file has to be written before it has been protected, which means
> it may very well have user space allocated beyond EOF before the
> merkle tree needs to be written.
Sure, and every file system knows how to truncate a file.
On Wed, Dec 19, 2018 at 01:19:53PM +1100, Dave Chinner wrote:
> Putting metadata in user files beyond EOF doesn't work with XFS's
> post-EOF speculative allocation algorithms.
>
> i.e. Filesystem design/algorithms often assume that the region
> beyond EOF in user files is a write-only region.
On Mon, Dec 17, 2018 at 12:00:39PM -0800, Darrick J. Wong wrote:
> FWIW, if I were (hypothetically) working on an xfs implementation, I
> likely would have settled on passing a reference to a merkle tree
> through a (fd, length) pair, because that allows us plenty of options
> on the back end:
>
201 - 300 of 3865 matches
Mail list logo
