On Wed, Oct 31, 2018 at 10:12:27PM +0300, Vasily Averin wrote:
> Fixes bfe0a5f47ada ("ext4: add more mount time checks of the superblock") #
> 4.18
>
> Signed-off-by: Vasily Averin
> ---
> fs/ext4/super.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/fs/ext4/super.
On Wed, Oct 31, 2018 at 10:12:35PM +0300, Vasily Averin wrote:
> Fixes c8585c6fcaf2 ("ext4: fix races between changing inode journal ...") #
> 4.7
>
> cc: Daeho Jeong
> Signed-off-by: Vasily Averin
Thanks, applied.
- Ted
On Wed, Oct 31, 2018 at 10:12:43PM +0300, Vasily Averin wrote:
> Fixes dec214d00e0d ("ext4: xattr inode deduplication") # 4.13
>
> Signed-off-by: Vasily Averin
Thanks, applied. I used the description line:
ext4: fix buffer leak in ext4_xattr_get_block() on error path
On Wed, Oct 31, 2018 at 10:12:52PM +0300, Vasily Averin wrote:
> bs.bh was taken in previous ext4_xattr_block_find() call,
> it should be released before re-using
>
> Fixes 7e01c8e5420b ("ext3/4: fix uninitialized bs in ...") # 2.6.26
> cc: Tiger Yang
>
> Signed-off-by: Vasily Averin
Thanks, a
On Wed, Nov 07, 2018 at 02:50:16PM +0100, Jan Kara wrote:
> On Wed 31-10-18 22:13:00, Vasily Averin wrote:
> > Fixes 3f2571c1f91f ("ext4: factor out xattr moving")
> > cc: Jan Kara
> > however issue was present in original ext4_expand_extra_isize_ea()
> > Fixes 6dd4ee7cab7e ("ext4: Expand extra_in
On Sun, Nov 04, 2018 at 08:29:39PM +0300, Vasily Averin wrote:
> ext4_getblk() called with map_flags=0 can return NULL,
> it can lead to oops on bh dereferemce
>
> Fixes e50e5129f384 ("ext4: xattr-in-inode support")
> Cc: sta...@kernel.org # 4.13
>
> Signed-off-by: Vasily Averin
> ---
> fs/ext4
On Tue, Nov 06, 2018 at 02:16:27PM -0800, Olof Johansson wrote:
>
> Olof Johansson (arm-soc)
> Arnd Bergmann (arm-soc)
> Kevin Hilman (arm-soc)
> Mike Turquette (clk)
> Stephen Boyd (clk)
> Linus Walleij (pinctrl + more)
> Mike Brown (gpio/regmap + more)
Could the poeple listed on this list pleas
On Wed, Nov 07, 2018 at 09:35:09AM -0800, Olof Johansson wrote:
>
> Tuesday afternoon looks least conflict-y when I squint at the
> schedule, or Thursday afternoon (but ideally not overlapping with
> Daniel's DRM/gitlab session).
I've posted a draft schedule, so why don't we move the conversation
On Wed, Nov 07, 2018 at 10:47:24AM -0800, Olof Johansson wrote:
>
> Can we have 3pm-3:30pm on Thursday? It seems relatively low on
> embedded-related conflicts and at 3 people would have time to migrate
> from Daniel Vetter's gitlab talk if needed.
I'd really like to keep the slots all 45 minute
On Fri, Nov 02, 2018 at 12:04:46PM +0100, Rasmus Villemoes wrote:
> This field is never used, might as well remove it.
>
> Signed-off-by: Rasmus Villemoes
Thanks, applied.
- Ted
On Fri, Nov 02, 2018 at 12:04:47PM +0100, Rasmus Villemoes wrote:
> Since the definition of struct crng_state is private to random.c, and
> primary_crng is neither declared or used elsewhere, there's no reason
> for that symbol to have external linkage.
>
> Signed-off-by: Rasmus Villemoes
Thanks
On Fri, Nov 02, 2018 at 12:04:45PM +0100, Rasmus Villemoes wrote:
> Never modified, might as well be put in .rodata.
>
> Signed-off-by: Rasmus Villemoes
Thanks, applied.
- Ted
On Wed, Nov 07, 2018 at 05:06:08PM -0800, Vito Caputo wrote:
> In reading the news today, I stumbled across an article talking about a
> $20 "linux-based distro" app for Windows 10.
>
> This is just a bundled userspace for WSL, there is no actual Linux in
> this thing, yet the trademarked Linux na
On Wed, Oct 31, 2018 at 10:13:09PM +0300, Vasily Averin wrote:
> Fixes de05ca852679 ("ext4: move call to ext4_error() into ...") # 4.17
>
> Signed-off-by: Vasily Averin
Thanks, applied. I used the commit description:
ext4: fix buffer leak in ext4_expand_extra_isize_ea() on error path
On Wed, Nov 07, 2018 at 08:30:17PM +0300, Vasily Averin wrote:
> Fixes dc6982ff4db1 ("ext4: refactor code to read directory blocks ...")
> Cc: sta...@kernel.org # 3.9
>
> Signed-off-by: Vasily Averin
Thanks, applied. I used the commit description:
ext4: fix buffer leak in __ext4_read_dirbl
On Thu, Nov 08, 2018 at 09:46:30AM +0300, Vasily Averin wrote:
> diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
> index 0b9688683526..415f73d4c9e6 100644
> --- a/fs/ext4/xattr.c
> +++ b/fs/ext4/xattr.c
> @@ -1384,6 +1384,12 @@ static int ext4_xattr_inode_write(handle_t *handle,
> struct inode *ea_
On Thu, Nov 08, 2018 at 04:05:17PM +0100, Peter Zijlstra wrote:
> On Thu, Nov 08, 2018 at 07:49:20AM -0700, Jonathan Corbet wrote:
> > Might it be worth asking Ted for a kernel summit slot to talk about this
> > next week?
>
> Ah, on that, let me complain :-)
>
> My plumbers schedule is already 1
On Thu, Nov 08, 2018 at 09:33:47AM -0700, Jonathan Corbet wrote:
>
> > I thought there was a slot already scheduled on the refereed track,
> > "Towards a Linux Kernel Mainainer Handbook" (Tuesday at 4:45pm) for
> > this purpose?
>
> My expectation is that this will be an actual talk; it seemed ru
On Thu, Nov 08, 2018 at 09:19:33AM -0800, Dan Williams wrote:
>
> I know at least StGit mail does not grok that "#"notation. I've
> stopped using it in favor of a "Fixes:" tag. I would think "Fixes:" is
> preferred over "# " if only because it can be used to track
> fixes to commits that have been
On Thu, Nov 08, 2018 at 06:00:59PM +, mario.limoncie...@dell.com wrote:
> > Sortly after 12:30am US/Eastern, I got a low power warning on my
> > system, and the battery power had dropped below 10%. Apparently the
> > laptop was not accepting any charge any more. I tried doing a suspend
> > to
On Thu, Oct 11, 2018 at 07:14:30AM -0700, h...@zytor.com wrote:
> >
> >I mean - what is the baud rate of a pty ?
>
> Whatever the master wants it to be...
I think Alan's point is that it is highly unlikely you would be able
to push the equivalent of 4 gbps through a PTY layer. The TTY later
was
On Thu, Oct 11, 2018 at 03:54:21PM -0700, Kees Cook wrote:
> Right now rand_initialize() is run as an early_initcall(), but it only
> depends on timekeeping_init() (for mixing ktime_get_real() into the
> pools). However, the call to boot_init_stack_canary() for stack canary
> initialization runs ea
On Fri, Oct 12, 2018 at 10:42:39AM +0200, Arnd Bergmann wrote:
> I wonder if mixing in ktime_get_real() is flawed to start with:
> This depends on read_persistent_clock64() actually returning
> a meaningful time, but in many cases it does not; x86 being
> a notable exception.
>
> We have three way
On Tue, Sep 11, 2018 at 01:02:00PM +, mario.limoncie...@dell.com wrote:
> > I tried 9370 and it detects the adapter correctly. IIRC I did the same
> > for 5530 and it worked as well.
>
> Thanks for confirming that. Hopefully the same change can be ported to PD
> controller
> firmware then on
On Wed, Oct 31, 2018 at 12:57:37AM +0300, Vasily Averin wrote:
> currently bh is set to NULL only during first iteration of for cycle,
> then this pointer is not cleared after end of using.
> Therefore rollback after errors can lead to extra brelse(bh) call,
> decrements bh counter and later trigge
On Wed, Oct 31, 2018 at 12:57:45AM +0300, Vasily Averin wrote:
> Fixes 33afdcc5402d ("ext4: add a function which sets up group blocks ...") #
> 3.3
>
> Signed-off-by: Vasily Averin
Thanks, applied. I adjusted the patch summary:
ext4: add missing brelse() in set_flexbg_block_bitmap()'s err
On Wed, Oct 31, 2018 at 12:57:55AM +0300, Vasily Averin wrote:
> gdb_bh must be released in case of errors before update of s_group_desc
> but it must not be released after update of group descriptors
> because in this case bh can be used later.
>
> Fixes 01f795f9e0d6 ("ext4: add online resizing s
On Wed, Oct 31, 2018 at 12:58:03AM +0300, Vasily Averin wrote:
> bh was not released after error in ext4_journal_get_write_access()
>
> Fixes ac27a0ec112a ("ext4: initial copy of files from ext3") # 2.6.19
>
> Signed-off-by: Vasily Averin
Thanks, applied. I fixed up the commit description and
On Tue, Oct 23, 2018 at 02:42:03AM -0700, syzbot wrote:
> syzbot has found a reproducer for the following crash on:
>
> HEAD commit:ca9eb48fe01f Merge tag 'regulator-v5.0' of git://git.kerne..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=11a6093940
On Tue, Oct 23, 2018 at 04:22:54PM +0200, Rainer Fiebig wrote:
>
> And whether that CoC does come with a political agenda or is just being
> *perceived* so, is irrelevant: the perception *is* the reality. And by
> embracing this CoC, Linux is now being perceived as also supporting the
> agenda
On Tue, Oct 23, 2018 at 09:19:53PM +0100, Phillip Potter wrote:
> diff --git a/include/linux/file_type.h b/include/linux/file_type.h
Shouldn't this be in include/uapi/linux/fs_types.h?
One of things which must be made crystal clear is these definitions
MUST NOT ever change. It would break the Us
On Wed, Oct 24, 2018 at 12:47:57PM +1100, NeilBrown wrote:
>
> I doubt it was copied - more likely independent evolution.
> But on reflection, I see that it is probably reasonable that it
> shouldn't be used this way - or at all in this context.
> I'll try to understand what the issues really are
On Wed, Oct 24, 2018 at 09:15:34AM -0400, Theodore Y. Ts'o wrote:
> At least for ext4, the primary problem is that we want to use a 64-bit
> telldir/seekdir cookie if all 64-bits will make it to user space, and
> a 32-bit telldir cookie if only 32 bits will make it userspace. This
The following changes since commit 17b57b1883c1285f3d0dc2266e8f79286a7bef38:
Linux 4.19-rc6 (2018-09-30 07:15:35 -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 33458eaba4dfe778a4
On Thu, Oct 25, 2018 at 08:05:40AM -0700, Bart Van Assche wrote:
> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> index fc9129d5909e..0ef275fe526c 100644
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -1383,6 +1383,10 @@ static void __queue_work(int cpu, struct
> workqueue_stru
On Thu, Oct 25, 2018 at 09:59:38PM +0200, Johannes Berg wrote:
> > So, thinking about this more, can you guarantee (somehow) that the
> > workqueue is empty at this point?
>
> (I hadn't looked at the code then - obviously that's guaranteed)
We can guarantee it from someone who is looking at the c
On Thu, Oct 25, 2018 at 03:39:01PM -0400, Eric S. Raymond wrote:
>
> Under Jacobsen vs. Katzer (535 f 3d 1373 fed cir 2008) authors of
> GPLed software have a specific right to relief (including injunctive
> relief) against misappropriation of their software. That ruling (which
> was the case of f
#syz dup: general protection fault in rb_erase
The fix for this is already in Linux's tree (merged on October 24th).
On Sat, Oct 20, 2018 at 03:14:20PM -0400, jonsm...@gmail.com wrote:
>
> Which is why the lawyers need to go over this document and I haven't
> seen anything posted from them. In the same vein Mauro is concerned
> that the way this is code is written it is a binding contract in
> Brazil.
My unders
On Sun, Oct 21, 2018 at 11:26:08PM +0100, Josh Triplett wrote:
> On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote:
> > I call on you, Greg:
> > - to abandon this divisive attempt to impose a "Code of Conduct"
> > - to revert 8a104f8b5867c68
> > - to return to your core competence of bui
Neil,
I disagree with your framing, and thus your analysis, and thus your
proposed solution.
On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote:
> If, for example, Linus or Andrew said "if you cannot work with any given
> maintainer, I will consider your patch directly, but you need to poi
On Tue, Oct 23, 2018 at 03:25:08PM +1100, NeilBrown wrote:
>
> Yes, you could, and you can. But if it was Linus who was behaving
> inappropriately, where did you go then? This is why I think whatever
> "code" we have should be overtly a statement Linus makes about his
> behaviour, in the first i
[ This pull request was originally intended for 4.19-rc4, but some
testing hiccups delayed my sending this earlier. Given Linus's
comments, I'm not sure whether PULL requests should be going to Linus
or Greg, so I'm sending it to both. -- Ted ]
The following changes since commit 863c37fcb1
On Tue, Jul 17, 2018 at 09:26:00AM -0700, Linus Torvalds wrote:
> On Tue, Jul 17, 2018 at 6:54 AM Arnd Bergmann wrote:
> >
> > The newly added arch_get_random_int() call was done incorrectly,
> > using the output only if rdrand hardware was /not/ available. The
> > compiler points out that the dat
On Wed, Jul 18, 2018 at 10:11:52AM +0300, Constantine Shulyupin wrote:
> Local variable t should be initialized by arch_get_random_int.
> Actually on failure of arch_get_random_int, value is not used.
> So, just keep the build clean with less warnings.
>
> warning:
> drivers/char/random.c: In func
On Wed, May 23, 2018 at 01:01:59PM -0500, Eric Sandeen wrote:
>
> What I'm personally hung up on are the bugs where the "exploit" involves
> merely
> mounting a crafted filesystem that in reality would never (until the heat
> death
> of the universe) corrupt itself into that state on its own; it
On Thu, May 24, 2018 at 10:49:31AM +1000, Dave Chinner wrote:
>
> We've learnt this lesson the hard way over and over again: don't
> parse untrusted input in privileged contexts. How many times do we
> have to make the same mistakes before people start to learn from
> them?
Good question. For ho
On Wed, Apr 04, 2018 at 04:30:18AM +, Matthew Garrett wrote:
> What I'm afraid of is this turning into a "security" feature that ends up
> being circumvented in most scenarios where it's currently deployed - eg,
> module signatures are mostly worthless in the non-lockdown case because you
> can
The commit 5149cbac4235: "locking/rwsem: Add DEBUG_RWSEMS to look for
lock/unlock emismatches" (newly added in this merge window) will cause
xfstests tests failures in generic/068 for all file systems.
This is because the freeze and thaw ioctls, by design, are run in
different processes. It looks
The following changes since commit 4a3928c6f8a53fa1aed28ccba227742486e8ddcb:
Linux 4.16-rc3 (2018-02-25 18:50:41 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random.git
tags/random_for_linus
for you to fetch changes up to 5e747dd9be54be
On Wed, Apr 04, 2018 at 03:02:33PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Apr 04, 2018 at 08:57:43AM -0400, Theodore Y. Ts'o wrote:
> > On Wed, Apr 04, 2018 at 04:30:18AM +, Matthew Garrett wrote:
> > > What I'm afraid of is this turning into a "security&
The following changes since commit 7928b2cbe55b2a410a0f5c1f154610059c57b1b2:
Linux 4.16-rc1 (2018-02-11 15:04:29 -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 e40ff213898502d299
On Wed, Apr 04, 2018 at 02:33:37PM +0100, David Howells wrote:
> Theodore Y. Ts'o wrote:
>
> > Whoa. Why doesn't lockdown prevent kexec? Put another away, why
> > isn't this a problem for people who are fearful that Linux could be
> > used as part o
On Wed, Apr 04, 2018 at 10:37:26AM -0400, Waiman Long wrote:
> The commit 8c5db92a705d ("locking/rwsem: Add DEBUG_RWSEMS to look for
> lock/unlock mismatches") causes a warning in ext4 fstests due to the
> fact that the freeze and thaw ioctls, by design, are run in different
> processes.
While tru
On Wed, Apr 04, 2018 at 12:35:04PM -0700, Matthew Wilcox wrote:
> On Wed, Apr 04, 2018 at 09:24:05PM +0200, Dmitry Vyukov wrote:
> > On Tue, Apr 3, 2018 at 4:01 AM, syzbot
> > wrote:
> > > DEBUG_LOCKS_WARN_ON(sem->owner != get_current())
> > > WARNING: CPU: 1 PID: 4441 at kernel/locking/rwsem.c:13
On Tue, Mar 27, 2018 at 04:51:08PM +0300, Ilya Smith wrote:
> > /dev/[u]random is not sufficient?
>
> Using /dev/[u]random makes 3 syscalls - open, read, close. This is a
> performance
> issue.
You may want to take a look at the getrandom(2) system call, which is
the recommended way getting secu
On Thu, Apr 26, 2018 at 03:53:58PM +0900, Tetsuo Handa wrote:
> Oh, pull request was already sent. Should be merged shortly.
>
> https://marc.info/?l=linux-kernel&m=152472466201090&w=2
More testing, either before or after merging, would be greatly
appreciated. One of the challenges is that there
On Thu, Apr 26, 2018 at 08:17:34AM -0700, Sultan Alsawaf wrote:
> > Hmm, can you let the boot hang for a while? It should continue after
> > a few minutes if you wait long enough, but wait a minute or two, then
> > give it entropy so the boot can continue. Then can you use
> > "systemd-analyze bl
On Thu, Apr 26, 2018 at 10:28:13AM -0600, Jens Axboe wrote:
> during boot. We end up doing the numa_crng_init() from interrupt context,
> which
> makes things unhappy since you do GFP_KERNEL | __GFP_NOFAIL allocations from
> there.
I've already sent a pull request to Linux to fix this; see the
ra
On Thu, Apr 26, 2018 at 01:22:02PM -0700, Sultan Alsawaf wrote:
>
> Also, regardless of what's hanging on CRNG init, CRNG should be able to init
> on its own in a timely
> manner without the need for user-provided entropy. Userspace was working fine
> before the recent CRNG
> kernel changes, so
On Thu, Apr 26, 2018 at 10:47:49PM +0200, Christian Brauner wrote:
>
> We have observed a similiar problem with libvirt. As soon as entropy is
> provided the boot finishes otherwise it hangs for a long time.
> This is not happening with v4.17-rc1 afaict.
For libvirt there is at least an easy wor
On Wed, Apr 25, 2018 at 08:44:04AM -0600, Shuah Khan wrote:
> I am seeing the following on my system with 4.17-rc2. Probably in 4.17-rc1
> as well.
>
> Something to be concerned about. Is this related to
> Commit: a45403b51582a87872927a3e0fc0a389c26867f1
> ext4: always initialize the crc32c checks
On Fri, Apr 27, 2018 at 05:38:52PM +0200, Jason A. Donenfeld wrote:
>
> Please correct me if I'm wrong, but my present understanding of this
> is that crng readiness used to be broken, meaning people would have a
> seeded rng without it actually being seeded. You fixed this bug, and
> now people a
On Fri, Apr 27, 2018 at 03:57:35PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.107 release.
The kernel.org page currently lists 3.18 as EOL. I assume we released
an update for Spectre/Meltdown after we declared it end of life, but I
was surprised t
On Thu, Apr 26, 2018 at 10:20:44PM -0700, Sultan Alsawaf wrote:
>
> I noted at least 20,000 mmc interrupts before I intervened in the boot
> process to provide entropy
> myself. That's just for mmc, so I'm sure there were even more interrupts
> elsewhere. Is 20k+ interrupts
> really not sufficie
The following changes since commit e40ff213898502d299351cc2fe1e350cd186f0d3:
ext4: force revalidation of directory pointer after seekdir(2) (2018-04-01
23:21:03 -0400)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
tags/for_linus_stable
On Sun, Apr 29, 2018 at 11:30:57AM -0700, Sultan Alsawaf wrote:
>
> Mind you, this laptop has a 45W CPU, so power savings were definitely not
> considered in its design. Do you have any machines that can provide enough
> boot entropy to satisfy crng init without requiring user-provided entropy?
M
On Sun, Apr 29, 2018 at 01:20:33PM -0700, Sultan Alsawaf wrote:
> On Sun, Apr 29, 2018 at 08:41:01PM +0200, Pavel Machek wrote:
> > Umm. No. https://www.youtube.com/watch?v=xneBjc8z0DE
>
> Okay, but /dev/urandom isn't a solution to this problem because it isn't
> usable
> until crng init is compl
On Sun, Apr 29, 2018 at 03:49:28PM -0700, Sultan Alsawaf wrote:
> On Mon, Apr 30, 2018 at 12:43:48AM +0200, Jason A. Donenfeld wrote:
> > > - if ((fast_pool->count < 64) &&
> > > - !time_after(now, fast_pool->last + HZ))
> > > - return;
> > > -
> >
> > I suspect you s
On Sun, Apr 29, 2018 at 07:07:29PM -0400, Dave Jones wrote:
> > Why do we continue to print this stuff out when crng_init=1 though ?
>
> answering my own question, I think.. This is a tristate, and we need it
> to be >1 to be quiet, which doesn't happen until..
>
> > [ 165.806247] random: crng
On Sun, Apr 29, 2018 at 09:34:45PM -0700, Sultan Alsawaf wrote:
>
> What about abusing high-resolution timers to get entropy? Since hrtimers can't
> make guarantees down to the nanosecond, there's always a skew between the
> requested expiry time and the actual expiry time.
>
> Please see the att
On Tue, May 01, 2018 at 06:52:47AM -0500, Justin Forbes wrote:
>
> We have also had reports that Fedora users are seeing this on Google
> Compute Engine.
Can you reproduce this yourself? If so, could you confirm that
removing the dracut-fips package makes the problem go away for you?
Thanks,
On Tue, May 01, 2018 at 04:38:21PM +, Sasha Levin wrote:
> - A merge window commit spent 50% more days, on average, in -next than a -rc
>commit.
So it *used* to be the case that after the merge window, I would queue
up bug fixes for the next merge window. Greg K-H pushed for me to
send t
On Tue, May 01, 2018 at 08:00:21PM +, Sasha Levin wrote:
>
> Yes, linux-next users want it fixed *now* and I completely agree it
> should be done that way, but the fix should not be immediately pushed to
> Linus as well.
I should have linux-head/linux-rc said testers, sorry. The fact that
we
On Tue, May 01, 2018 at 05:35:56PM -0500, Justin Forbes wrote:
>
> I have not reproduced in GCE myself. We did get some confirmation
> that removing dracut-fips does make the problem less dire (but I
> wouldn't call a 4 minute boot a win, but booting in 4 minutes is
> better than not booting at a
On Wed, May 02, 2018 at 09:33:38AM +1000, Tobin C. Harding wrote:
> There are a couple of whitespace issues around the function
> get_random_bytes_arch(). In preparation for patching this function
> let's clean them up.
>
> Signed-off-by: Tobin C. Harding
Acked-by: Theodore Ts'o
> ---
> driv
On Wed, May 02, 2018 at 09:33:39AM +1000, Tobin C. Harding wrote:
> Currently the function get_random_bytes_arch() has return value 'void'.
> If the hw RNG fails we currently fall back to using get_random_bytes().
> This defeats the purpose of requesting random material from the hw RNG
> in the fir
On Tue, May 01, 2018 at 05:43:17PM -0700, Sultan Alsawaf wrote:
>
> I've attached what I think is a reasonable stopgap solution until this is
> actually fixed. If you're willing to revert the CVE-2018-1108 patches
> completely, then I don't think you'll mind using this patch in the meantime.
I wo
On Wed, May 02, 2018 at 07:09:11AM -0500, Justin Forbes wrote:
> Yes, Fedora libgcrypt is carrying a patch which makes it particularly
> painful for us, we have reached out to the libgcrypt maintainer to
> follow up on that end. But as I said before, even without that code
> path (no dracut-fips) w
On Wed, May 02, 2018 at 10:49:34AM -0700, Laura Abbott wrote:
>
> It is a Fedora patch we're carrying
> https://src.fedoraproject.org/rpms/libgcrypt/blob/master/f/libgcrypt-1.6.2-fips-ctor.patch#_23
> so yes, it is a Fedora specific use case.
> From talking to the libgcrypt team, this is a FIPS mo
On Wed, May 02, 2018 at 10:41:56PM +0200, Geert Uytterhoeven wrote:
>
> Between v4.17-rc1 and v4.17-rc3, there are 660 non-merge commits, of which
> - 245 carry a Fixes tag,
> - 196 carry a CC stable,
> - 395 contain the string "fix".
> (non-mutually exclusive)
>
> That leaves us with 200 c
On Thu, May 03, 2018 at 11:05:50AM +0900, Mark Brown wrote:
> On Wed, May 02, 2018 at 07:46:34PM +, Sasha Levin wrote:
>
> > As you said, the regression should be fixed "asap", not "immediately".
> > It should go through some sort of review and testing the maintainers are
> > happy with, but u
On Mon, May 28, 2018 at 11:46:38AM +1000, Tobin C. Harding wrote:
>
> During the versions of this set I have been totally confused about which
> patches go through which tree. This version again puts all 4 patches
> together in the hope they will go through Andrew's tree.
I'm also happy to take
On Mon, May 28, 2018 at 01:31:56PM +0800, xin tan wrote:
>
> 1) Do all the maintainers in the path from the author of the commits
> to the mainline repository sign their name?
No.
> 3) If the answer is no, why do some maintainers sign their names, and
> some do not? Is it because these maintaine
On Tue, May 29, 2018 at 11:01:07AM -0400, Prarit Bhargava wrote:
> Kees, in early boot no pool is available so the stack canary is initialized
> from
> the TSC. Later in boot, the stack canary will use the the crng.
>
> ie) in early boot only TSC is okay, and late boot (when crng_ready() is true
On Tue, May 29, 2018 at 03:26:43PM -0400, Kent Overstreet wrote:
> > That seems to indicate that we've had already PostgreSQL licensed code on
> > Linux since Kent's addition of bcache to Linux in 2013. The portion of code
> > is rather small though, to me it seems to cover only crc_table[],
> > bc
The following changes since commit 75bc37fefc4471e718ba8e651aa74673d4e0a9eb:
Linux 4.17-rc4 (2018-05-06 16:57:38 -1000)
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 4f2f76f75143390836
The following changes since commit 75bc37fefc4471e718ba8e651aa74673d4e0a9eb:
Linux 4.17-rc4 (2018-05-06 16:57:38 -1000)
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 fetch changes up to 4f2f76f75143
On Tue, Jun 05, 2018 at 05:13:35PM +0200, Richard Weinberger wrote:
> > Add bunch of cleanups, and add support for the Speck128/256
> > algorithms. Yes, Speck is contrversial, but the intention is to use
> > them only for the lowest end Android devices, where the alternative
> > *really* is no enc
On Tue, Jun 05, 2018 at 06:10:24PM +0200, Richard Weinberger wrote:
> That's the question. I understand the use case, but I fear attack scenarios
> where someone manages to downgrade the crypto of my phone.
> This is why I was asking whether Android tells me whether Speck is used or
> not.
> "it d
On Tue, Jun 05, 2018 at 07:05:52PM +0200, Richard Weinberger wrote:
> > An attack scenario where someone manages to downgrade the crypto of
> > your phone would require replacing your kernel and your /system
> > partition --- at which point, you've got other problems. :-)
>
> This means Speck is
On Tue, Jun 05, 2018 at 01:22:41PM -0700, Linus Torvalds wrote:
>
> You have the tag *message* for fscrypt, but then the commit it points
> to has nothing to do with fscrypt.
>
> I think you tagged the wrong branch.
Yeah, sorry. I used git shortlog when I was examining the branch to
compose the
On Wed, May 16, 2018 at 04:46:13PM +0100, Dmitry Safonov wrote:
> > Yeah, but what you print is not total sum, it's since the last
> > interval because without mentioned flag ___ratelimit() will flush
> > missed counter and print "suppressed" message. They might even
> > double if say other procce
On Tue, Apr 24, 2018 at 10:27:12AM -0600, Michal Hocko wrote:
> fs/ext4/xattr.c
>
> What to do about this? Well, there are two things. Firstly, it would be
> really great to double check whether the GFP_NOFS is really needed. I
> cannot judge that because I am not familiar with the code.
*Most* o
On Wed, Apr 25, 2018 at 09:46:42AM +0900, Tetsuo Handa wrote:
> Theodore Ts\'o wrote:
> > We can do a sleeping allocation from an irq context when CONFIG_NUMA
> > is enabled. Fix this by initializing the NUMA crng instances in a
> > workqueue.
>
> Offloading to workqueue context itself would be O
Does this help on your system?
- Ted
commit 4e00b339e264802851aff8e73cde7d24b57b18ce
Author: Theodore Ts'o
Date: Wed Apr 25 01:12:32 2018 -0400
random: rate limit unseeded randomness warnings
On systems without sufficient boot rando
On Wed, Apr 25, 2018 at 09:11:08PM -0700, Sultan Alsawaf wrote:
> I noticed "systems without sufficient boot randomness" and would like to add
> to this.
>
> With the changes to /dev/random going from 4.16.3 to 4.16.4, my low-spec
> Chromebook does not reach
> the login screen upon boot (it stay
The following changes since commit d848e5f8e1ebdb227d045db55fe4f825e82965fa:
random: add new ioctl RNDRESEEDCRNG (2018-04-14 11:59:31 -0400)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random.git
tags/random_for_linus_stable
for you to fetch
On Wed, Apr 25, 2018 at 10:05:55PM -0700, Sultan Alsawaf wrote:
>
> Correct, I'm running Xubuntu 18.04 with my own kernel based off linux-stable.
>
Hmm, can you let the boot hang for a while? It should continue after
a few minutes if you wait long enough, but wait a minute or two, then
give it e
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 ac
201 - 300 of 559 matches
Mail list logo
