Re: [PATCH 1/2] fs: ext4: use BUG_ON if writepage call comes from direct reclaim

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

Re: 答复: 答复: 答复: 答复: 答复: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices

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

Re: 答复: 答复: 答复: 答复: 答复: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices

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

Re: [PATCH] ext4: Check superblock mapped prior to committing

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

Re: [PATCH] ext4: Check superblock mapped prior to committing

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

Re: 答复: 答复: 答复: 答复: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices

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

Re: 答复: 答复: 答复: 答复: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices

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

Re: 答复: 答复: 答复: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices

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

Re: 答复: 答复: 答复: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices

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

Re: 答复: 答复: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices

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 /

Re: 答复: 答复: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices

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 /

Re: config files and how to have persistent Linux kernel Driver/File System configuration info saved

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

Re: config files and how to have persistent Linux kernel Driver/File System configuration info saved

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

Re: 答复: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices

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

Re: 答复: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices

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

Re: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices

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

Re: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices

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

Re: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices

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

Re: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices

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

Re: what trees/branches to test on syzbot

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

Re: what trees/branches to test on syzbot

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

Re: [PATCH 00/32] VFS: Introduce filesystem context [ver #8]

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

Re: [PATCH 00/32] VFS: Introduce filesystem context [ver #8]

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

Re: [PATCH] vfs: Support FALLOC_FL_NO_HIDE_STALE flag with fallocate

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

Re: [PATCH] vfs: Support FALLOC_FL_NO_HIDE_STALE flag with fallocate

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

Re: Bugs involving maliciously crafted file system

On Mon, Jun 11, 2018 at 03:07:24PM +0200, Dmitry Vyukov wrote: > > These can't be weaponized to execute code, but if a BUG_ON is > triggerable over a network, or from VM guest, then it's likely more > critical than a local code execution. That's why I am saying that > automated evaluation is

Re: Bugs involving maliciously crafted file system

On Mon, Jun 11, 2018 at 03:07:24PM +0200, Dmitry Vyukov wrote: > > These can't be weaponized to execute code, but if a BUG_ON is > triggerable over a network, or from VM guest, then it's likely more > critical than a local code execution. That's why I am saying that > automated evaluation is

Re: what trees/branches to test on syzbot

On Sun, Jun 10, 2018 at 08:11:05AM +0200, Dmitry Vyukov wrote: > > The set of trees where a crash happened is visible on dashboard, so > one can see if it's only linux-next or whole set of trees. Potentially > syzbot can act differently depending on this predicate, but I don't > see what should

Re: what trees/branches to test on syzbot

On Sun, Jun 10, 2018 at 08:11:05AM +0200, Dmitry Vyukov wrote: > > The set of trees where a crash happened is visible on dashboard, so > one can see if it's only linux-next or whole set of trees. Potentially > syzbot can act differently depending on this predicate, but I don't > see what should

Re: what trees/branches to test on syzbot

On Sat, Jun 09, 2018 at 03:17:21PM -0700, Linus Torvalds wrote: > I think it would be lovely to get linux-next back eventually, but it > sounds like it's just too noisy right now, and yes, we should have a > baseline for the standard tree first. > > But once there's a "this is known for the

Re: what trees/branches to test on syzbot

On Sat, Jun 09, 2018 at 03:17:21PM -0700, Linus Torvalds wrote: > I think it would be lovely to get linux-next back eventually, but it > sounds like it's just too noisy right now, and yes, we should have a > baseline for the standard tree first. > > But once there's a "this is known for the

Re: building in 32bit chroot on x86_64 host broken

On Sat, Jun 09, 2018 at 09:23:55PM +0900, Masahiro Yamada wrote: > Just a note. > > In case of cross-compiling, not only ARCH but also CROSS_COMPILE > must be passed when you do "make *config". Sure, what was being discussed was people who build 32-bit x86 kernels on a 64-bit platform. I do

Re: building in 32bit chroot on x86_64 host broken

On Sat, Jun 09, 2018 at 09:23:55PM +0900, Masahiro Yamada wrote: > Just a note. > > In case of cross-compiling, not only ARCH but also CROSS_COMPILE > must be passed when you do "make *config". Sure, what was being discussed was people who build 32-bit x86 kernels on a 64-bit platform. I do

Re: [PATCH v6 0/4] enable early printing of hashed pointers

On Thu, Jun 07, 2018 at 09:31:04AM +1000, Tobin C. Harding wrote: > > I'm also happy to take the whole patch series through the random tree > > if everyone else is OK with it. > > Looks like every one is happy (or silent) now Ted, can you please take > this version through your tree. Ok, it's

Re: [PATCH v6 0/4] enable early printing of hashed pointers

On Thu, Jun 07, 2018 at 09:31:04AM +1000, Tobin C. Harding wrote: > > I'm also happy to take the whole patch series through the random tree > > if everyone else is OK with it. > > Looks like every one is happy (or silent) now Ted, can you please take > this version through your tree. Ok, it's

Re: [GIT PULL] fscrypt updates for 4.18

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

Re: [GIT PULL] fscrypt updates for 4.18

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

Re: [GIT PULL] fscrypt updates for 4.18

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

Re: [GIT PULL] fscrypt updates for 4.18

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

Re: [GIT PULL] fscrypt updates for 4.18

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

Re: [GIT PULL] fscrypt updates for 4.18

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

Re: [GIT PULL] fscrypt updates for 4.18

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

Re: [GIT PULL] fscrypt updates for 4.18

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

[GIT PULL] fscrypt updates for 4.18

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

[GIT PULL] fscrypt updates for 4.18

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

[GIT PULL] ext4 updates for 4.18

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

[GIT PULL] ext4 updates for 4.18

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

Re: [PATCH] ext4: prefer strlcpy to strncpy

On Mon, May 28, 2018 at 11:21:53PM -0700, Nick Desaulniers wrote: > Fixes a stringop-truncation warning from gcc-8. > > Signed-off-by: Nick Desaulniers I'll note that the ext4 superblock fields are *not* guaranteed to be NULL terminated. Code that references them must, and do, deal with this

Re: [PATCH] ext4: prefer strlcpy to strncpy

On Mon, May 28, 2018 at 11:21:53PM -0700, Nick Desaulniers wrote: > Fixes a stringop-truncation warning from gcc-8. > > Signed-off-by: Nick Desaulniers I'll note that the ext4 superblock fields are *not* guaranteed to be NULL terminated. Code that references them must, and do, deal with this

Re: PostgreSQL licensed code on Linux

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[], > >

Re: PostgreSQL licensed code on Linux

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[], > >

Re: [PATCH] x86, random: Fix get_random_bytes() warning in x86 start_kernel

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

Re: [PATCH] x86, random: Fix get_random_bytes() warning in x86 start_kernel

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

Re: Can I use 'signed -off-by' to define maintainers' workload?

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

Re: Can I use 'signed -off-by' to define maintainers' workload?

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

Re: [PATCH v6 0/4] enable early printing of hashed pointers

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

Re: [PATCH v6 0/4] enable early printing of hashed pointers

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

Re: Bugs involving maliciously crafted file system

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

Re: Bugs involving maliciously crafted file system

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

Re: [PATCH] doc: document scope NOFS, NOIO APIs

ere is no mention in the core-api Documentation and there are > > people looking there to find answers how to use a specific API. > > > > Cc: "Darrick J. Wong" <darrick.w...@oracle.com> > > Cc: David Sterba <dste...@suse.cz> > > Requested-by: "Th

Re: [PATCH] doc: document scope NOFS, NOIO APIs

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

Re: [REVIEW][PATCH 0/6] Wrapping up the vfs support for unprivileged mounts

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

Re: [REVIEW][PATCH 0/6] Wrapping up the vfs support for unprivileged mounts

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

Re: Bugs involving maliciously crafted file system

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

Re: Bugs involving maliciously crafted file system

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

Bugs involving maliciously crafted file system

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;

Bugs involving maliciously crafted file system

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;

Re: [PATCH] ext4: report delalloc reserve as non-free in statfs mangled by project quota

On Fri, Feb 02, 2018 at 01:40:05PM +0300, Konstantin Khlebnikov wrote: > This reserved space isn't committed yet but cannot be used for allocations. > For userspace it has no difference from used space. XFS already does this. > > Signed-off-by: Konstantin Khlebnikov >

Re: [PATCH] ext4: report delalloc reserve as non-free in statfs mangled by project quota

On Fri, Feb 02, 2018 at 01:40:05PM +0300, Konstantin Khlebnikov wrote: > This reserved space isn't committed yet but cannot be used for allocations. > For userspace it has no difference from used space. XFS already does this. > > Signed-off-by: Konstantin Khlebnikov > Fixes: 689c958cbe6b ("ext4:

Re: [PATCH] ext4: Remove unnecessary NULL checks in ext4.

On Tue, Feb 06, 2018 at 07:15:30PM +0800, Sean Fu wrote: > NULL check is done in kmem_cache_destroy. So remove NULL checks in ext4. > > Signed-off-by: Sean Fu Thanks, applied. I clarified the patch summary to be: ext4: remove NULL check before calling

Re: [PATCH] ext4: Remove unnecessary NULL checks in ext4.

On Tue, Feb 06, 2018 at 07:15:30PM +0800, Sean Fu wrote: > NULL check is done in kmem_cache_destroy. So remove NULL checks in ext4. > > Signed-off-by: Sean Fu Thanks, applied. I clarified the patch summary to be: ext4: remove NULL check before calling kmem_cache_destroy()

Re: [PATCH] jbd2: remove the conditional test

On Mon, Feb 05, 2018 at 10:24:39PM +0800, Wang Long wrote: > kmem_cache_destroy already handles null pointers, so we can remove the > conditional test entirely. > > This patch also set NULL after the kmem_cache_destroy in function > jbd2_journal_destroy_handle_cache. > > Signed-off-by: Wang Long

Re: [PATCH] jbd2: remove the conditional test

On Mon, Feb 05, 2018 at 10:24:39PM +0800, Wang Long wrote: > kmem_cache_destroy already handles null pointers, so we can remove the > conditional test entirely. > > This patch also set NULL after the kmem_cache_destroy in function > jbd2_journal_destroy_handle_cache. > > Signed-off-by: Wang Long

Re: [PATCH] fscrypt: use unbound workqueue for decryption

On Fri, Apr 20, 2018 at 04:30:02PM -0700, Eric Biggers wrote: > Improve fscrypt read performance by switching the decryption workqueue > from bound to unbound. With the bound workqueue, when multiple bios > completed on the same CPU, they were decrypted on that same CPU. But > with the unbound

Re: [PATCH] fscrypt: use unbound workqueue for decryption

On Fri, Apr 20, 2018 at 04:30:02PM -0700, Eric Biggers wrote: > Improve fscrypt read performance by switching the decryption workqueue > from bound to unbound. With the bound workqueue, when multiple bios > completed on the same CPU, they were decrypted on that same CPU. But > with the unbound

Re: random: Wake up writers when random pools are zapped

On Fri, May 18, 2018 at 02:57:36PM +0800, Herbert Xu wrote: > As it is when the pool is zapped with RNDCLEARPOOL writers are > not woken up and therefore the pool may remain in the empty state > indefinitely. > > This patch wakes them up unless the write threshold is set to zero. > >

Re: random: Wake up writers when random pools are zapped

On Fri, May 18, 2018 at 02:57:36PM +0800, Herbert Xu wrote: > As it is when the pool is zapped with RNDCLEARPOOL writers are > not woken up and therefore the pool may remain in the empty state > indefinitely. > > This patch wakes them up unless the write threshold is set to zero. > >

Re: Linux messages full of `random: get_random_u32 called from`

On Fri, May 18, 2018 at 10:56:18PM +, Trent Piepho wrote: > > I feel like "fix" might overstate the result a bit. > > This ends up taking a full second to make each UUID. Having gone to > great effort to make an iMX25 complete userspace startup in 250 ms, a > full second, per UUID, in early

Re: Linux messages full of `random: get_random_u32 called from`

On Fri, May 18, 2018 at 10:56:18PM +, Trent Piepho wrote: > > I feel like "fix" might overstate the result a bit. > > This ends up taking a full second to make each UUID. Having gone to > great effort to make an iMX25 complete userspace startup in 250 ms, a > full second, per UUID, in early

Re: Linux messages full of `random: get_random_u32 called from`

On Fri, May 18, 2018 at 01:27:03AM +, Trent Piepho wrote: > > I've hit this on an embedded system. mke2fs hangs trying to format a > persistent writable filesystem, which is where the random seed to > initialize the kernel entropy pool would be stored, because it wants 16 > bytes of

Re: Linux messages full of `random: get_random_u32 called from`

On Fri, May 18, 2018 at 01:27:03AM +, Trent Piepho wrote: > > I've hit this on an embedded system. mke2fs hangs trying to format a > persistent writable filesystem, which is where the random seed to > initialize the kernel entropy pool would be stored, because it wants 16 > bytes of

Re: [PATCH 1/5] random: fix crng_ready() test

On Thu, May 17, 2018 at 08:01:04AM +0200, Christophe LEROY wrote: > > On a powerpc embedded board which has an mpc8xx processor running at 133Mhz, > I now get the startup done in more than 7 minutes instead of 30 seconds. > This is due to the webserver blocking on read on /dev/random until we get

Re: [PATCH 1/5] random: fix crng_ready() test

On Thu, May 17, 2018 at 08:01:04AM +0200, Christophe LEROY wrote: > > On a powerpc embedded board which has an mpc8xx processor running at 133Mhz, > I now get the startup done in more than 7 minutes instead of 30 seconds. > This is due to the webserver blocking on read on /dev/random until we get

Re: [PATCH 1/5] random: fix crng_ready() test

On Wed, May 16, 2018 at 05:07:08PM -0700, Srivatsa S. Bhat wrote: > > On a Photon OS VM running on VMware ESXi, this patch causes a boot speed > regression of 5 minutes :-( [ The VM doesn't have haveged or rng-tools > (rngd) installed. ] > > [1.420246] EXT4-fs (sda2): re-mounted. Opts:

Re: [PATCH 1/5] random: fix crng_ready() test

On Wed, May 16, 2018 at 05:07:08PM -0700, Srivatsa S. Bhat wrote: > > On a Photon OS VM running on VMware ESXi, this patch causes a boot speed > regression of 5 minutes :-( [ The VM doesn't have haveged or rng-tools > (rngd) installed. ] > > [1.420246] EXT4-fs (sda2): re-mounted. Opts:

Re: [PATCH 1/2] random: Omit double-printing ratelimit messages

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

Re: [PATCH 1/2] random: Omit double-printing ratelimit messages

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

Re: [PATCH v3] ext4: handle errors on ext4_commit_super

On Mon, Apr 23, 2018 at 08:46:26AM -0600, Jaegeuk Kim wrote: > When remounting ext4 from ro to rw, currently it allows its transition, > even if ext4_commit_super() returns EIO. Even worse thing is, after that, > fs/buffer complains buffer dirty bits like: > > Call trace: > []

Re: [PATCH v3] ext4: handle errors on ext4_commit_super

On Mon, Apr 23, 2018 at 08:46:26AM -0600, Jaegeuk Kim wrote: > When remounting ext4 from ro to rw, currently it allows its transition, > even if ext4_commit_super() returns EIO. Even worse thing is, after that, > fs/buffer complains buffer dirty bits like: > > Call trace: > []

Re: Fixing Linux getrandom() in stable

(Quoting somewhat out of order) On Sun, May 13, 2018 at 09:23:39PM +, Thorsten Glaser wrote: > > It’s also no solution for the arc4random API… seems like a cultural > clash (BSD expectations vs. what Linux can actually deliver). It's instructive to look how OpenBSD solves this problem.

Re: Fixing Linux getrandom() in stable

(Quoting somewhat out of order) On Sun, May 13, 2018 at 09:23:39PM +, Thorsten Glaser wrote: > > It’s also no solution for the arc4random API… seems like a cultural > clash (BSD expectations vs. what Linux can actually deliver). It's instructive to look how OpenBSD solves this problem.

Re: [RFC v2 3/4] ext4: add verifier check for symlink with append/immutable flags

On Fri, May 11, 2018 at 11:12:18PM +0200, Jan Kara wrote: > On Thu 10-05-18 16:13:58, Luis R. Rodriguez wrote: > > The Linux VFS does not allow a way to set append/immuttable > > attributes to symlinks, this is just not possible. If this is > > detected inform the user as the filesystem must be

Re: [RFC v2 3/4] ext4: add verifier check for symlink with append/immutable flags

On Fri, May 11, 2018 at 11:12:18PM +0200, Jan Kara wrote: > On Thu 10-05-18 16:13:58, Luis R. Rodriguez wrote: > > The Linux VFS does not allow a way to set append/immuttable > > attributes to symlinks, this is just not possible. If this is > > detected inform the user as the filesystem must be

Re: [PATCH v2] fs: ext4: Adding new return type vm_fault_t

On Thu, May 10, 2018 at 08:11:36PM +0530, Souptick Joarder wrote: > Use new return type vm_fault_t for fault handler. For now, > this is just documenting that the function returns a > VM_FAULT value rather than an errno. Once all instances are > converted, vm_fault_t will become a distinct type. >

Re: [PATCH v2] fs: ext4: Adding new return type vm_fault_t

On Thu, May 10, 2018 at 08:11:36PM +0530, Souptick Joarder wrote: > Use new return type vm_fault_t for fault handler. For now, > this is just documenting that the function returns a > VM_FAULT value rather than an errno. Once all instances are > converted, vm_fault_t will become a distinct type. >

Re: [PATCH 1/2] random: Omit double-printing ratelimit messages

On Thu, May 10, 2018 at 08:50:07PM +0100, Dmitry Safonov wrote: > random uses __ratelimit() which calls ___ratelimit() with a function > name. Depending on !RATELIMIT_MSG_ON_RELEASE it prints how many > messages were suppressed every ratelimit interval (1 second for random) > and flushes

Re: [PATCH 1/2] random: Omit double-printing ratelimit messages

On Thu, May 10, 2018 at 08:50:07PM +0100, Dmitry Safonov wrote: > random uses __ratelimit() which calls ___ratelimit() with a function > name. Depending on !RATELIMIT_MSG_ON_RELEASE it prints how many > messages were suppressed every ratelimit interval (1 second for random) > and flushes

Re: [PATCH 1/2] random: Omit double-printing ratelimit messages

On Thu, May 10, 2018 at 07:37:40PM +0100, Dmitry Safonov wrote: > > Ok, then what's the purpose of those messages? > :pr_notice("random: %d get_random_xx warning(s) missed " > : "due to ratelimiting\n", > : unseeded_warning.missed); > :

Re: [PATCH 1/2] random: Omit double-printing ratelimit messages

On Thu, May 10, 2018 at 07:37:40PM +0100, Dmitry Safonov wrote: > > Ok, then what's the purpose of those messages? > :pr_notice("random: %d get_random_xx warning(s) missed " > : "due to ratelimiting\n", > : unseeded_warning.missed); > :

Re: [PATCH 1/2] random: Omit double-printing ratelimit messages

On Thu, May 10, 2018 at 01:52:10PM +0100, Dmitry Safonov wrote: > Currently "suppressed" messages will be printed once in a second for > unseeded/urandom warnings, but there is already custom message which > says how many warnings are missing. So, let's skip suppressed messages > until crng_init

<    1   2   3   4   5   6   7   8   9   >