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 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 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 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 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,
> +
> For example, we could add a file to fs/ext4/kunitconfig which contains:
>
> CONFIG_EXT4_FS=y
> CONFIG_EXT4_KUNIT_TESTS=y
>
> We could do something similar in fs/jdb2, etc.
>
> Obviously some logically separate KUnit tests (different maintainers,
> different Kconfig
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
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
rticular request is to keep what
needs to be placed in .kunitconfig to a small and reasonable set.
Per Documentation/dev-tools/kunit, we start by:
cd $PATH_TO_LINUX_REPO
cp arch/um/configs/kunit_defconfig .kunitconfig
we're then supposed to add whatever Kunit tests we wan
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, 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 Tue, Oct 06, 2020 at 07:40:05PM -0700, Dan Williams wrote:
> On Tue, Oct 6, 2020 at 4:09 PM Ralph Campbell wrote:
> >
> > There are several places where ZONE_DEVICE struct pages assume a reference
> > count == 1 means the page is idle and free. Instead of open coding this,
> > add a helper
On Wed, Oct 07, 2020 at 01:03:04AM -0700, Josh Triplett wrote:
> > But can we *please* take your custom tool out back and shoot it in the
> > head?
>
> Nope. As mentioned, this isn't about creating ext4 filesystem images,
> and it isn't even remotely similar to mke2fs.
Can you please tell us
On Mon, Oct 05, 2020 at 10:03:06PM -0700, Josh Triplett wrote:
>
> I'm not trying to create a problem here; I'm trying to address a whole
> family of problems. I was generally under the impression that mounting
> existing root filesystems fell under the scope of the kernel<->userspace
> or
On Mon, Oct 05, 2020 at 07:51:10PM -0700, Darrick J. Wong wrote:
> > > Could /somebody/ please document the ondisk format changes that are
> > > associated with this feature?
> >
> > I pretty much had to sort it out by looking at a combination of
> > e2fsprogs and the kernel, and a lot of
On Mon, Oct 05, 2020 at 10:36:39AM -0700, Darrick J. Wong wrote:
> > Commit e7bfb5c9bb3d ("ext4: handle add_system_zone() failure in
> > ext4_setup_system_zone()") breaks mounting of read-only ext4 filesystems
> > with intentionally overlapping bitmap blocks.
> >
> > On an always-read-only
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 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 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 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 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 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 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 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 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 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 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 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 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
- Ted
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 5.9.0-rc4 Kernel Configuration
#
CONFIG_CC_VERSION_TEXT="gcc (Debian 10.2.0-7) 10.2.0"
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=100200
CONFIG_LD_VERSION=23500
CONFIG_CLANG_VERSION=0
CONFIG_CC_CAN_LINK
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 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 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
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 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
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 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
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 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 Wed, Jul 01, 2020 at 09:12:31AM +1000, Dave Airlie wrote:
>
> What timezone are the conferences being held in? It impacts on what I
> can attend quite heavily :-)
When you register for the Linux Plumbers Conference, there will be an
opportunity for you to indicate your timezone preferences.
So far, we have received 5 techinical topic submissions for the Kernel
Summit; thanks to those who have submitted. If you have some
additional ideas of technical topics you'd like to discuss at the
Kernel Summit, please submit them this week. For details on how to
proposal a topic for the Kernel
The following changes since commit 6b8ed62008a49751fc71fefd2a4f89202a7c2d4d:
ext4: avoid unnecessary transaction starts during writeback (2020-06-03
23:16:56 -0400)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
On Fri, May 29, 2020 at 10:39:39AM +0200, Jan Nieuwenhuizen wrote:
> Theodore Y. Ts'o writes:
>
> Hello!
>
> > 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
&
#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
5749fe5af3db176659978718ddaecebb450cdb6b
#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
5b8b9d0c6d0e0f1993c6c56deaf9646942c49d94
#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
5b8b9d0c6d0e0f1993c6c56deaf9646942c49d94
change since v3:
No code changes.
Update commit message to reflect info given by Mario at dell.
Is there anything more i have to do for the patches that were reviewed
or will they be picked up by the maintainers?
Thanks
Y Paritcher (3):
platform/x86: dell-wmi: add new backlight
and will be handled by acpi-video
Signed-off-by: Y Paritcher
---
drivers/platform/x86/dell-wmi.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index c25a4286d766..0b2edfe2767d 100644
--- a/drivers/platform/x86/dell-wmi.c
+++ b
means and add it to bios_to_linux_keycode.
Signed-off-by: Y Paritcher
---
drivers/platform/x86/dell-wmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index e3bc2601e631..bbdb3e860892 100644
--- a/drivers
when
pressing the Fn-lock key on a Dell Inspiron 5593:
dell_wmi: Unknown WMI event type 0x12
dell_wmi: Unknown key with type 0x0012 and code 0xe035 pressed
This is consistent with the behavior for the Fn-lock key
elsewhere in this file.
Signed-off-by: Y Paritcher
---
drivers/platform/x86/dell
.
Overall I am trying to get useless data (to me) out of my syslog
by documenting the correct scancode/keycode mappings
Y Paritcher (3):
platform/x86: dell-wmi: add new backlight events
platform/x86: dell-wmi: add new keymap type 0x0012
platform/x86: dell-wmi: add new dmi mapping for keycode
.
Signed-off-by: Y Paritcher
---
drivers/platform/x86/dell-wmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index e3bc2601e631..bbdb3e860892 100644
--- a/drivers/platform/x86/dell-wmi.c
+++ b/drivers/platform
when
pressing the Fn-lock key on a Dell Inspiron 5593:
dell_wmi: Unknown WMI event type 0x12
dell_wmi: Unknown key with type 0x0012 and code 0xe035 pressed
This is consistent with the behavior for the Fn-lock key
elsewhere in this file.
Signed-off-by: Y Paritcher
---
drivers/platform/x86/dell
and will be handled by acpi-video
Signed-off-by: Y Paritcher
---
drivers/platform/x86/dell-wmi.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index c25a4286d766..0b2edfe2767d 100644
--- a/drivers/platform/x86/dell-wmi.c
+++ b
and will be handled by acpi-video
Signed-off-by: Y Paritcher
---
drivers/platform/x86/dell-wmi.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index c25a4286d766..0b2edfe2767d 100644
--- a/drivers/platform/x86/dell-wmi.c
+++ b
when
pressing the Fn-lock key on a Dell Inspiron 5593:
dell_wmi: Unknown WMI event type 0x12
dell_wmi: Unknown key with type 0x0012 and code 0xe035 pressed
This is consistent with the behavior for the Fn-lock key
elsewhere in this file.
Signed-off-by: Y Paritcher
---
drivers/platform/x86/dell
on the extended data
can be added.
messages of type:
firmware scancode 0xXX maps to unrecognized keycode 0x
are from unknown keycodes in the DMI table and should be added
to bios_to_linux_keycode to allow them to be processed.
Y Paritcher (3):
platform/x86: dell-wmi: add new backlight events
table, for which the
corosponding keys are not known.
Now when a user will encounter this key, a proper message wil be printed:
dell_wmi: Unknown key with type 0x and code 0x pressed
This will then allow the key to be identified properly.
Signed-off-by: Y Paritcher
---
drivers
On 6/8/20 8:26 PM, mario.limoncie...@dell.com wrote:
>> -Original Message-
>> From: Pali Rohár
>> Sent: Monday, June 8, 2020 6:33 PM
>> To: Y Paritcher
>> Cc: linux-kernel@vger.kernel.org; platform-driver-...@vger.kernel.org;
>> Matthew Garrett; Limon
On 6/8/20 7:55 PM, Pali Rohár wrote:
> Hello!
>
> On Monday 08 June 2020 16:27:10 Randy Dunlap wrote:
>> Hi--
>>
>> On 6/8/20 4:05 PM, Y Paritcher wrote:
>>> Increase length of bios_to_linux_keycode to 2 bytes (the true size of a
>>> keycode) to
On 6/8/20 6:00 PM, mario.limoncie...@dell.com wrote:
>>
>> this is the WMI event from pressing the Fn lock key.
>> this indicates which mode it is switching to.
>>
>> this changes if the default for pressing the F[1-12] should be Function or
>> media.
>> the scancodes of the Fn keys are properly
On 6/8/20 4:36 PM, mario.limoncie...@dell.com wrote:
>> -Original Message-
>> From: Y Paritcher
>> Sent: Monday, June 8, 2020 3:13 PM
>> To: Limonciello, Mario
>> Cc: linux-kernel@vger.kernel.org; platform-driver-...@vger.kernel.org;
>> mj...@srcf.ucam
On 6/8/20 11:40 AM, mario.limoncie...@dell.com wrote:
>> -Original Message-
>> From: platform-driver-x86-ow...@vger.kernel.org > ow...@vger.kernel.org> On Behalf Of Y Paritcher
>> Sent: Sunday, June 7, 2020 11:22 PM
>> Cc: linux-kernel@vger.kernel.org; platf
On 6/8/20 4:50 AM, Pali Rohár wrote:
> Hello!
>
> On Monday 08 June 2020 00:22:25 Y Paritcher wrote:
>> Ignore events with a type of 0x0012 and a code of 0xe035,
>> this silences the following messages being logged when
>> pressing the Fn-lock key on a Dell Inspiron
On 6/8/20 11:46 AM, mario.limoncie...@dell.com wrote:
>> -Original Message-
>> From: platform-driver-x86-ow...@vger.kernel.org > ow...@vger.kernel.org> On Behalf Of Pali Rohár
>> Sent: Monday, June 8, 2020 4:00 AM
>> To: Y Paritcher
>> Cc: linux-ker
On 6/8/20 11:30 AM, mario.limoncie...@dell.com wrote:
>> -Original Message-
>> From: platform-driver-x86-ow...@vger.kernel.org > ow...@vger.kernel.org> On Behalf Of Pali Rohár
>> Sent: Monday, June 8, 2020 3:35 AM
>> To: Y Paritcher
>> Cc: linux-ker
keycode 0x
Signed-off-by: Y Paritcher
---
drivers/platform/x86/dell-wmi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index f37e7e9093c2..5ef716e3034f 100644
--- a/drivers/platform/x86/dell-wmi.c
+++ b
add new backlight events with a type of 0x0010 and a code of 0x57 / 0x58,
add a new keymap type table 0x0012 for keycode of 0xe035 from the Fn-lock
key
extend bios_to_linux_keycode to 2 bytes to allow for a new keycode 0x
Y Paritcher (3):
platform/x86: dell-wmi: add new backlight events
Ignore events with a type of 0x0010 and a code of 0x57 / 0x58,
this silences the following messages being logged on a
Dell Inspiron 5593:
dell_wmi: Unknown key with type 0x0010 and code 0x0057 pressed
dell_wmi: Unknown key with type 0x0010 and code 0x0058 pressed
Signed-off-by: Y Paritcher
Ignore events with a type of 0x0012 and a code of 0xe035,
this silences the following messages being logged when
pressing the Fn-lock key on a Dell Inspiron 5593:
dell_wmi: Unknown WMI event type 0x12
dell_wmi: Unknown key with type 0x0012 and code 0xe035 pressed
Signed-off-by: Y Paritcher
The following changes since commit 0e698dfa282211e414076f9dc7e83c1c288314fd:
Linux 5.7-rc4 (2020-05-03 14:56:04 -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
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
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
.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
Thanks, I've applied this patch series.
- Ted
On Sun, May 03, 2020 at 10:06:47PM +0200, Christophe JAILLET wrote:
> s/extnets/extents/
>
> Signed-off-by: Christophe JAILLET
Thanks, applied.
- Ted
[ Feel free to forward this to other Linux kernel mailing lists as
appropriate -- Ted ]
This year, the Maintainers and Kernel Summit will NOT be held in
Halifax, August 25 -- 28th, as a result of the COVID-19 pandemic.
Instead, we will be pursuing a virtual conference format for both the
On Thu, Apr 23, 2020 at 01:09:27PM +0800, Xiyu Yang wrote:
> ext4_orphan_get() invokes ext4_read_inode_bitmap(), which returns a
> reference of the specified buffer_head object to "bitmap_bh" with
> increased refcnt.
>
> When ext4_orphan_get() returns, local variable "bitmap_bh" becomes
>
On Mon, Apr 20, 2020 at 12:29:18PM +0800, Jason Yan wrote:
> Fix the following coccicheck warning:
>
> fs/ext4/extents_status.c:1057:5-28: WARNING: Comparison to bool
> fs/ext4/inode.c:2314:18-24: WARNING: Comparison to bool
>
> Signed-off-by: Jason Yan
Applied, thanks.
On Mon, May 11, 2020 at 03:14:38PM +0200, Anders Roxell wrote:
> This makes it easier to enable all KUnit fragments.
>
> Adding 'if !KUNIT_ALL_TESTS' so individual tests can not be turned off.
> Therefore if KUNIT_ALL_TESTS is enabled that will hide the prompt in
> menuconfig.
>
> Reviewed-by:
On Thu, Oct 17, 2019 at 05:43:07PM -0700, Brendan Higgins wrote:
> > +config SECURITY_APPARMOR_TEST
> > + bool "Build KUnit tests for policy_unpack.c"
> > + default n
> > + depends on KUNIT && SECURITY_APPARMOR
>
> Ted, here is an example where doing select on direct dependencies is
>
On Mon, Oct 14, 2019 at 01:51:15PM +0100, Catalin Marinas wrote:
> In your case, CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF=y, so it disables itself
> irrespective of the pool size and trips over the bug. Even with default
> off, it still involves the clean-up since kmemleak needs to tr
On Mon, Oct 14, 2019 at 08:03:14AM +0100, Catalin Marinas wrote:
> Thanks for the report. I have a fix already:
>
> http://lkml.kernel.org/r/20191004134624.46216-1-catalin.mari...@arm.com
>
> I was hoping Andrew had sent it to Linus before -rc3 but it doesn't seem
> to be in mainline yet.
Commit c566586818 ("mm: kmemleak: use the memory pool for early
allocations") causes my test kernels to fail to boot on using both kvm
and using Google Compute Engine. A git bisect localized it to
c566586818, and I confirmed by test building v5.4-rc3, which failed as
above using KVM. When I
On Sun, Oct 06, 2019 at 08:21:03PM +0200, Pavel Machek wrote:
> Even without cycle counter... if we _know_ we are trying to generate
> entropy and have MMC available, we don't care about power and
> performance.
>
> So we can just...
>
>issue read request on MMC
>while (!interrupt_done)
On Wed, Oct 02, 2019 at 06:55:33PM +0200, Kurt Roeckx wrote:
>
> But it seems people are now thinking about breaking getrandom() too,
> to let it return data when it's not initialized by default. Please
> don't.
"It's complicated"
The problem is that whether a CRNG can be considered secure is a
On Tue, Oct 01, 2019 at 06:15:02PM +0200, Ahmed S. Darwish wrote:
>
> Using the "ent" tool, [2] also used to test randomness in the Stephen
> Müller LRNG paper, on a 50-byte file, produced the following
> results:
The "ent" tool is really, really useless. If you take any CRNG, even
On Sun, Sep 29, 2019 at 11:37:06PM -0400, Theodore Y. Ts'o wrote:
> I'm OK with this as a starting point. If a jitter entropy system
> allow us to get pass this logjam, let's do it. At least for the x86
> architecture, it will be security through obscurity. And if the
>
On Sun, Sep 29, 2019 at 06:16:33PM -0700, Linus Torvalds wrote:
>
> - or just say "hey, a lot of people find jitter entropy reasonable,
> so let's just try this".
>
I'm OK with this as a starting point. If a jitter entropy system
allow us to get pass this logjam, let's do it. At least for
On Wed, Sep 25, 2019 at 05:18:54PM +1000, Dave Chinner wrote:
> > > ANd, really such strict writebehind behaviour is going to cause all
> > > sorts of unintended problesm with filesystems because there will be
> > > adverse interactions with delayed allocation. We need a substantial
> > > amount
On Fri, Sep 20, 2019 at 03:23:58AM +0500, Alexander E. Patrakov wrote:
> OTOH, I thought that at least part of the real entropy, if it exists, comes
> from the interference of the CPU's memory accesses with the refresh cycles
> that are clocked from an independent oscillator.
That's not a valid
On Thu, Sep 19, 2019 at 08:50:15AM -0700, Linus Torvalds wrote:
> .. btw, instead of bad workarounds for a theoretical attack, here's
> something that should add actual *practical* real value: use the time
> of day (whether from an RTC device, or from ntp) to add noise to the
> random pool.
On Thu, Sep 19, 2019 at 08:20:57AM -0700, Linus Torvalds wrote:
> And unlike your theoretical state extension attack, I can point you to
> black hat presentations that literally talk about using the fact that
> we delay m,ixing in the input pull hash to know what's going on:
>
>
>
The following changes since commit d45331b00ddb179e291766617259261c112db872:
Linux 5.3-rc4 (2019-08-11 13:26:41 -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
(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
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
On Mon, Sep 16, 2019 at 09:17:10AM -0700, Linus Torvalds wrote:
> So the semantics that getrandom() should have had are:
>
> getrandom(0) - just give me reasonable random numbers for any of a
> million non-strict-long-term-security use (ie the old urandom)
>
> - the nonblocking flag makes
On Sun, Sep 15, 2019 at 08:40:30PM -0700, Linus Torvalds wrote:
> On Sun, Sep 15, 2019 at 8:23 PM Theodore Y. Ts'o wrote:
> >
> > But not blocking is *precisely* what lead us to weak keys in network
> > devices that were sold by the millions to users in their printers,
On Sun, Sep 15, 2019 at 10:02:18AM -0700, Linus Torvalds wrote:
> But on a PC, we can _almost_ guarantee entropy. Even with a golden
> image, we do mix in:
>
> - timestamp counter on every device interrupt (but "device interrupt"
> doesn't include things like the local CPU timer, so it really
On Sun, Sep 15, 2019 at 06:48:34PM -0700, Vito Caputo wrote:
> > A small note here, especially after I've just read the commit log of
> > 72dbcf721566 ('Revert ext4: "make __ext4_get_inode_loc plug"'), which
> > unfairly blames systemd there.
...
> > What blocked the system boot was
101 - 200 of 3865 matches
Mail list logo
