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 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 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 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 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 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 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 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 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 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 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
#syz invalid
This has already been fixed in the latest linux-next
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
>
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 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
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 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 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
getrandom() has been created as a new and more secure interface for
pseudorandom data requests. Unlike /dev/urandom, it unconditionally
blocks until the entropy pool has been properly initialized.
While getrandom() has no guaranteed upper bound for its waiting time,
user-space has been abusing
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
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 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 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 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 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
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
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:
>
>
>
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 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 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 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 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 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 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 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 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 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 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 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)
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 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.
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 track early
>
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 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
[ 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 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 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 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 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 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
#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
5b8b9d0c6d0e0f1993c6c56deaf9646942c49d94
#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/tytso/ext4.git
5749fe5af3db176659978718ddaecebb450cdb6b
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.
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
&
On Sun, May 03, 2020 at 10:06:47PM +0200, Christophe JAILLET wrote:
> s/extnets/extents/
>
> Signed-off-by: Christophe JAILLET
Thanks, applied.
- Ted
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
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
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 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, 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, 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
The following changes since commit 4f2f76f751433908364ccff82f437a57d0e6e9b7:
ext4: fix fencepost error in check for inode count overflow during resize
(2018-05-25 12:51:25 -0400)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
On Tue, Jun 26, 2018 at 07:54:53PM +0900, Tetsuo Handa wrote:
> I hope we can accept NOW either "reviving linux-next.git" or "allowing debug
> printk()
> patches for linux.git". For example, "INFO: task hung in __sb_start_write"
> got 900
> crashes in 81 days but still unable to find a
On Tue, Jun 26, 2018 at 07:54:06PM +0800, GaoMing wrote:
> for example, 1708 inodes every group,3 block groups, bitmap bytes are
> 1708/8=213.5 when the inode bitmap has some errors, e2fsprogs cannot fix it
>
> Signed-off-by: GaoMing
File systems like this should not exist. Can you please
On Thu, Jun 28, 2018 at 01:40:30AM +, Gaoming (ming, consumer BG) wrote:
> Hi tytso,
>
> I have checked that make_ext4fs code was deleted o Jun 21th 2018 on master
> branch of /system/extras repository.
> e.g.
> https://android-review.googlesource.com/c/platform/system/extras/+/708003
On Thu, Jun 28, 2018 at 07:56:59AM +, Gaoming (ming, consumer BG) wrote:
> You see, Inodes per group is 1708,which is illegal as you said.
>
> So, the problem exists a long time until Jun 21th 2018.
>
> You complained the problem in 2011, they do not fix it till 2018.
> Just as
> I
On Thu, Jun 28, 2018 at 05:37:15PM -0500, Steve French wrote:
> Ronnie brought up an interesting point about the problems consistently
> configuring file systems (or any Linux module for that matter) so that
> reboot doesn't wipe away security or performance tuning changes.
In general it's
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;
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
On Wed, May 23, 2018 at 06:22:56PM -0500, Eric W. Biederman wrote:
>
> Very slowly the work has been progressing to ensure the vfs has the
> necessary support for mounting filesystems without privilege.
What's the thinking behind how system administrators and/or file
systems would configure
the core-api Documentation and there are
> > people looking there to find answers how to use a specific API.
> >
> > Cc: "Darrick J. Wong"
> > Cc: David Sterba
> > Requested-by: "Theodore Y. Ts'o"
> > Signed-off-by: Michal Hocko
>
> Yay, Documentation! :)
Indeed, many thanks!!!
- Ted
On Fri, Jun 15, 2018 at 06:51:08PM +0800, Sig Shen wrote:
> FALLOC_FL_NO_HIDE_STALE flag must be set if user want to issue
> a discard request for block devices. But vfs_fallocate() will
> return with an error -EOPNOTSUPP indicating lack of support
> if this flag is set.
>
> fix it by allowing
On Mon, Jun 18, 2018 at 09:30:50PM +0100, David Howells wrote:
>
> The fscontext code *requires* you to parse the parameters *before* any attempt
> to access the superblock is made. Note that this will actually be a problem
> for, say, ext4 which passes a text string stored in the superblock
On Fri, Jun 29, 2018 at 02:06:03AM +, Gaoming (ming, consumer BG) wrote:
> We use usual inode size, it is 256 bytes.
>
> Yes, this commit is in my repository.
> But there is a bug in this patch.
>
> Let me show you,
> Here is the bug: " return ALIGN(inodes, (info.block_size /
On Sat, Jun 30, 2018 at 01:26:43AM +, Gaoming (ming, consumer BG) wrote:
> Yes, it is caused by using 1024 blocksize.
> It is historical problem, and I have to admit that's not good idea. I don't
> know why somebody choose it some years before.
> It has been corrected two years before or
On Mon, Jul 02, 2018 at 09:34:28AM +, Gaoming (ming, consumer BG) wrote:
> I got it. You hate make_ext4fs, and me too.
> You don't like to merge this patch in upstream e2fsprogs to resolve the bug
> of make_ext4fs.
>
> Of course we will fix the bug on our ancient devices, we have to .
> If
On Fri, Jun 29, 2018 at 01:36:35PM -0600, Jon Derrick wrote:
> This patch attempts to close a hole leading to a BUG seen with hot
> removals during writes [1].
>
> A block device (NVME namespace in this test case) is formatted to EXT4
> without partitions. It's mounted and write I/O is run to a
On Tue, Jul 03, 2018 at 12:58:48AM +, Gaoming (ming, consumer BG) wrote:
> And can you help me understand *why* such a choice was made?
> -if there is such a problem in your devices, how will you do? Is there
> any other choice?
> - of course, you cannot format the partition.
You
On Tue, Jul 03, 2018 at 12:11:18PM +0800, Yang Shi wrote:
> direct reclaim doesn't write out filesystem page, only kswapd could do
> it. So, if the call comes from direct reclaim, it is definitely a bug.
>
> And, Mel Gormane also mentioned "Ultimately, this will be a BUG_ON." In
> commit
On Tue, Jul 03, 2018 at 11:15:21AM +, Gaoming (ming, consumer BG) wrote:
>
> You misunderstand my question. Why was the choice of a blocksize of
> 1024 made?
>
> -some one choose, not me . I guess they want get more inodes in 20M
> filesystem.
That can't be the explanation.
I just
On Fri, Jul 27, 2018 at 12:26:25PM -0700, Sodagudi Prasad wrote:
> On 2018-07-26 18:04, Sodagudi Prasad wrote:
> > Hi All,
> >
>
> +linux-kernel@vger.kernel.org list.
>
> Hi All,
>
> Observing the following issue with one of the partition on android device
> with 4.14.56 kernel. When I try to
More generally, stupid question, but does Android *really* need to
have debugfs mounted? And if so, can we figure out what facilities
that are needed and can we find some other way of meeting those
requirements?
- Ted
On Fri, Jul 27, 2018 at 04:11:03PM -0400, Steven Rostedt wrote:
> That said, I would assume that
> other Android utilities are using other debugfs files for system
> status and such.
Yeah, I know we probably have lost the "debugfs is only for debugging
and has no place in a production system"
On Fri, Jul 27, 2018 at 03:05:43PM -0700, Sandeep Patil wrote:
> On Fri, Jul 27, 2018 at 04:21:14PM -0400, Theodore Y. Ts'o wrote:
> > On Fri, Jul 27, 2018 at 04:11:03PM -0400, Steven Rostedt wrote:
> > > That said, I would assume that
> > > other Android utilities ar
On Fri, Jul 27, 2018 at 01:34:31PM -0700, Sodagudi Prasad wrote:
> > The error should be pretty clear: "Inode table for bg 0 marked as
> > needing zeroing". That should never happen.
>
> Can you provide any debug patch to detect when this corruption is happening?
> Source of this corruption and
The following changes since commit 1e4b044d22517cae7047c99038abb23243ca:
Linux 4.18-rc4 (2018-07-08 16:34:02 -0700)
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 changes up to
On Thu, Jul 26, 2018 at 12:43:23PM -0500, Gustavo A. R. Silva wrote:
> Make use of the swap macro and remove unnecessary variable *tmp*.
> This makes the code easier to read and maintain.
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva
Thanks,
Hey Jeremy,
I think you are also going to be changing the 1/3 patch from the
original patch series that this was part of. That's correct, right?
It would be easier for me if you could simply make all of the
revisions you plan to make for the patch series, and then upload a
full v2 of the entire
On Mon, Jul 30, 2018 at 02:46:59PM -0400, Jeremy Cline wrote:
> I dropped patch 1/3 and 2/3 from the original series because they can
> both be covered by some sanitation in fs/quota/quota.c, so the this is
> only patch from the v1 series that should be applied.
>
> Sorry for not being more
On Mon, Jul 30, 2018 at 12:49:38PM -0700, Matthew Wilcox wrote:
> > That said, people have wanted these kinds of extended error
> > descriptors forever, and the reason we haven't added them is that it
> > generally is more pain than it is necessarily worth. I'm not actually
> > at all convinced
On Mon, Jul 30, 2018 at 04:58:49PM -0700, Matthew Wilcox wrote:
>
> Way to poison the well by calling it VMS-style error reporting! As I
> understand it though, VMS reported errors in English with an error code
> that could be looked up in The Wall of documentation. I'd see David's
> proposal
On Sat, May 26, 2018 at 07:12:49PM +0200, Dmitry Vyukov wrote:
>
> I don't see that "some kind of machine learning or expert system
> evaluation" is feasible. At least not in short/mid-term. There are
> innocently-looking bugs that actually turn out to be very bad, and
> there are badly looking
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
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
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
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
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
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
601 - 700 of 886 matches
Mail list logo
