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

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 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 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: [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 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: 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] 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: 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] 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: 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 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 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: bug-introducing patches

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

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

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

Re: bug-introducing patches

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

Re: [PATCH 1/3] random: Fix whitespace pre random-bytes work

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

Re: [PATCH 2/3] random: Return nbytes filled from hw RNG

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

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

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

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

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)

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

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

Re: [Ksummit-discuss] bug-introducing patches

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

Re: [Ksummit-discuss] bug-introducing patches

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

Re: [PATCH 4.9 75/95] random: set up the NUMA crng instances after the CRNG is fully initialized

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=152472466201090=2 More testing, either before or after merging, would be greatly appreciated. One of the challenges is that there

[GIT PULL] /dev/random fixes for 4.17-rc3

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

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

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

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

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

Re: random: GFP_KERNEL from irq context

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

Re: Linux 4.17.0-rc2 - WARNING: inconsistent lock state

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

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

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

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

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

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

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,

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

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?

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

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

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

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

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

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:

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

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

Re: serial: custom baud rate

On Thu, May 03, 2018 at 06:09:13PM +0530, Muni Sekhar wrote: > Hi All, > > From include/asm-generic/termbits.h , I see baudrate can be one of the > standard values: 50, 75, 110, 134, 150, 200, 300, 600, 1200, 1800, > 2400, 4800, 9600, 19200, 38400, 57600, 115200, 230400, 460800, 50, > 576000,

Re: [Ksummit-discuss] bug-introducing patches

On Thu, May 03, 2018 at 02:08:51PM +0300, Jani Nikula wrote: > On Tue, 01 May 2018, "Theodore Y. Ts'o" <ty...@mit.edu> wrote: > > Post -rc3 or -rc4, in my opinion bug fixes should wait until the next > > merge window before they get merged at all. > > What a

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

On Fri, May 04, 2018 at 09:07:37AM +1000, Tobin C. Harding wrote: > Currently if an attempt is made to print a pointer before there is > enough entropy then '(ptrval)' is printed. This makes debugging > stack traces during early boot difficult. > > It was observed that we can relax the

[GIT PULL] ext4 fixes for 4.17-rc3

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

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

On Tue, Jul 03, 2018 at 10:05:04AM -0700, Yang Shi wrote: > I'm not sure if it is a good choice to let filesystem handle such vital VM > regression. IMHO, writing out filesystem page from direct reclaim context is > a vital VM bug. It means something is definitely wrong in VM. It should > never

Re: [PATCH] tracing: do not leak kernel addresses

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

Re: Remounting filesystem read-only

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

Re: [PATCH] ext4: Convert int to vm_fault_t type

On Wed, Aug 01, 2018 at 09:13:19AM -0700, Matthew Wilcox wrote: > On Wed, Aug 01, 2018 at 12:06:18PM -0400, Theodore Y. Ts'o wrote: > > On Wed, Aug 01, 2018 at 10:38:30AM -0400, Theodore Y. Ts'o wrote: > > > I'm going to drop the whole ext4 changes for vm_fault_t for this > &g

Re: [PATCH] ext4: Convert int to vm_fault_t type

On Wed, Aug 01, 2018 at 10:38:30AM -0400, Theodore Y. Ts'o wrote: > I'm going to drop the whole ext4 changes for vm_fault_t for this > cycle, and I'll let you try to fix it up properly for the next cycle. Here's the fixed up commit that I'm going to drop since you plan to be making c

Re: [PATCH] ext4: Convert int to vm_fault_t type

On Wed, Aug 01, 2018 at 06:56:39PM +0530, Souptick Joarder wrote: > As caller of block_page_mkwrite() are - > fs/ext4/inode.c > fs/nilfs2/file.c > > I will merge both changes in a single patch and send it. Note that it's *important* for ext4 that we know what kind of error was returned by the

Re: [PATCH 1/5] vfs: syscall: Add fsinfo() to query filesystem information

On Wed, Aug 01, 2018 at 05:14:01PM +0100, David Howells wrote: > > Some attributes (such as the servers backing a network filesystem) can have > multiple values. These can be enumerated by setting params->Nth and > params->Mth to 0, 1, ... until ENODATA is returned. How does the caller know

[GIT PULL] random fixes for 4.18-rc7

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

Re: [PATCH 36/38] vfs: Add a sample program for the new mount API [ver #10]

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

Re: [PATCH v2] ext4: mballoc: Fix spectre gadget in ext4_mb_regular_allocator

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

Re: [PATCH v2] ext4: mballoc: Fix spectre gadget in ext4_mb_regular_allocator

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

Re: [PATCH 36/38] vfs: Add a sample program for the new mount API [ver #10]

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

Re: [PATCH v2] ext4: use swap macro in mext_page_double_lock

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,

Re: [PATCH] ext4/mballoc: Remove unneeded variable "err"

On Sat, Aug 04, 2018 at 07:04:56PM +0800, zhong jiang wrote: > The err is not used after initalization. So just remove the variable. > > Signed-off-by: zhong jiang I'll apply this patch, but how did you generate the diff? The function name here is all wrong: > diff --git a/fs/ext4/mballoc.c

Re: [PATCH] ext4/mballoc: Remove unneeded variable "err"

On Sun, Aug 05, 2018 at 08:59:33PM +0800, zhong jiang wrote: > I create the diff in this patch again ,but get the same result . > the git version is git version 1.7.12.4 but I create the diff in > git version 1.8.3.1. It shows the correct function name. Ah, OK, so it was a git bug. Whew!

Re: [PATCH v2] ext4: mballoc: Fix spectre gadget in ext4_mb_regular_allocator

On Mon, Jul 30, 2018 at 06:07:47PM +, Jeremy Cline wrote: > 'ac->ac_g_ex.fe_len' is a user-controlled value which is used in the > derivation of 'ac->ac_2order'. 'ac->ac_2order', in turn, is used to > index arrays which makes it a potential spectre gadget. Fix this by > sanitizing the value

Re: [PATCH] Improve code readability

On Tue, Jul 31, 2018 at 02:15:15PM +0800, Liu Song wrote: > Merge the duplicated complex conditions to improve code readability. > > Signed-off-by: Liu Song > Reviewed-by: Jiang Biao Thanks, applied. - Ted

Re: [PATCH] ext4: Convert int to vm_fault_t type

On Sat, Jul 28, 2018 at 02:20:00PM +0530, Souptick Joarder wrote: > Use new return type vm_fault_t for ext4_page_mkwrite > handler and block_page_mkwrite_return. > > Signed-off-by: Souptick Joarder FYI, this patch was very sloppy, and didn't do the right thing. That's because of how you messed

Re: Remounting filesystem read-only

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

Re: [PATCH] tracing: do not leak kernel addresses

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"

Re: [PATCH] tracing: do not leak kernel addresses

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

Re: [PATCH 4.14 222/246] ext4: fix check to prevent initializing reserved inodes

On Wed, Aug 08, 2018 at 07:28:45AM +0200, Greg Kroah-Hartman wrote: > On Wed, Aug 08, 2018 at 12:17:30AM +0200, Matthias Schiffer wrote: > > On 08/01/2018 06:52 PM, Greg Kroah-Hartman wrote: > > > 4.14-stable review patch. If anyone has any objections, please let me > > > know. > > > > It seems

[GIT PULL] ext4 updates for 4.19

The following changes since commit 5012284700775a4e6e3fbe7eac4c543c4874b559: ext4: fix check to prevent initializing reserved inodes (2018-07-29 15:34:00 -0400) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git tags/ext4_for_linus for

Re: linux-next: build warnings from Linus' tree

On Mon, Aug 20, 2018 at 08:13:23AM +1000, Stephen Rothwell wrote: > fs/ext4/super.c: In function '__save_error_info': > fs/ext4/super.c:344:2: warning: 'strncpy' specified bound 32 equals > destination size [-Wstringop-truncation] > strncpy(es->s_last_error_func, func,

Re: linux-next: build warnings from Linus' tree

On Mon, Aug 20, 2018 at 03:33:19AM +0200, Adam Borowski wrote: > Valid uses of strncpy() do exist (such as SCSI structs), but those deal with > fixed-width fields. Thus, gcc is right for warning for at least some of > misuse of strncpy() for C strings. The function wasn't designed for them. The

Re: [PATCH] random: fix rdrand mix-in

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

Re: [PATCH] drivers/char/random.c: fix uninitialized value warning

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

Re: bug-introducing patches

On Sun, Jul 15, 2018 at 10:54:03AM +0200, Greg KH wrote: > Pavel, I "love" how you fail to point out that you are responding to a 2 > month old thread :( And apologies for releasing some ancient messages that were caught in the ksummit-discuss's moderation queue. I hadn't been paying attention

Re: Does /dev/urandom now block until initialised ?

On Mon, Jul 23, 2018 at 12:11:12PM -0400, Jeffrey Walton wrote: > > I believe Stephan Mueller wrote up the weakness a couple of years ago. > He's the one who explained the interactions to me. Mueller was even > cited at https://github.com/systemd/systemd/issues/4167. Stephan had a lot of

Re: [PATCH] ext4: remove abnormal set for I_DATA_SEM subclass

On Mon, Jul 23, 2018 at 10:48:37AM +0900, 이준일/연구원/MC연구소 BSP실 BSP6팀(junil0814@lge.com) wrote: > Then, I have a question. > quotactl() doesn't have case only to set limits flag, the routine to set > the DQUOT_LIMITS_ENABLED flag is under dquot_enable() function. > According to this logic, if

Re: no public email address excluding Gmail

On Wed, Jul 25, 2018 at 03:25:07PM +0800, 张宁 wrote: > Hi, everyone > > I notice each developer in this email list has a company email address > or Gmail, or maybe selfhosted email. > > last night I have tried my outlook.com, yahoo.com, QQ.com email, all > of them are rejected by mechine. There

Re: [PATCH] random: Remove preempt disabled region

On Wed, Jul 11, 2018 at 04:37:21PM +0200, Sebastian Andrzej Siewior wrote: > From: Ingo Molnar > > No need to keep preemption disabled across the whole function. > > mix_pool_bytes() uses a spin_lock() to protect the pool and there are > other places like write_pool() whhich invoke

Re: [PATCH] ext4: use swap macro in mext_page_double_lock

On Mon, Jul 09, 2018 at 08:16:00AM -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. Also, reduces the > stack usage. > > This code was detected with the help of Coccinelle. > > Signed-off-by:

Re: [PATCH] fs: ext4: use new return type vm_fault_t

On Sat, Jul 07, 2018 at 04:00:30PM +0530, Souptick Joarder wrote: > Use new return type vm_fault_t for fault handler > ext4_filemap_fault. > > Signed-off-by: Souptick Joarder Thanks, applied. - Ted

Re: [PATCH] ext4: remove abnormal set for I_DATA_SEM subclass

On Mon, Jul 09, 2018 at 04:58:28PM +0900, Junil Lee wrote: > The -EBUSY return value of dquot_enable() function means that just > want to update flags. If some users make a duplicate request to update > flags, lockdep could catch the false positive casued by needing to > allocate a quota block

Re: [PATCH] ext4: fix warning message to output correct type.

On Fri, Jul 13, 2018 at 06:15:47PM +0900, Junichi Uekawa wrote: > Output the warning message before we clobber type and be -1 all the time. > The error message would now be > > [1.519791] EXT4-fs warning (device vdb): ext4_enable_quotas:5402: > Failed to enable quota tracking (type=0,

Maintainer / Kernel Summit 2018 planning kick-off

[ Feel free to forward this to other Linux kernel mailing lists as appropriate -- Ted ] This year, the Maintainer and Kernel Summit will be in Vancouver, B.C., November 12th -- 15th. The Maintainer's summit will be held on Monday, November 12th, in Vancouver, immediately before the Linux

Re: linux-next test error

On Wed, Sep 05, 2018 at 03:20:16PM +0530, Souptick Joarder wrote: > > "fs: convert return type int to vm_fault_t" is still under > review/discusson and not yet merge > into linux-next. I am not seeing it into linux-next tree.Can you > please share the commit id ? It's at:

[GIT PULL] random fixes for 4.19-rc3

The following changes since commit 9a47249d444d344051c7c0e909fad0e88515a5c2: random: Make crng state queryable (2018-08-02 17:33:06 -0400) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random.git tags/for_linus for you to fetch changes up to

Re: linux-next test error

P.S. This is the second time the vm_fualt_t change has broken things. The first time, when it went through the ext4 tree, I NACK'ed it after a 60 seconds smoke test showed it was broken. This time it went through the mm tree... In the future, even for "trivial" changes, could you *please* run

Re: Widespread crashes in next-20180906

On Thu, Sep 06, 2018 at 06:45:15AM -0700, Guenter Roeck wrote: > Build results: > total: 134 pass: 133 fail: 1 > Failed builds: > sparc32:allmodconfig > Qemu test results: > total: 311 pass: 76 fail: 235 > Failed builds: > > > Error message is always something like > >

Re: linux-next test error

On Thu, Sep 06, 2018 at 05:56:31PM +0530, Souptick Joarder wrote: > > Yes, I'd start with converting ext4_page_mkwrite() - that should be pretty > > straightforward - and we can leave block_page_mkwrite() as is for now. I > > don't think allocating other VM_FAULT_ codes is going to cut it as > >

Re: possible deadlock in ext4_evict_inode

On Thu, Sep 06, 2018 at 09:41:04AM -0700, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit:b36fdc6853a3 Merge tag 'gpio-v4.19-2' of git://git.kernel... > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=1716bc9e40 >

Re: Widespread crashes in next-20180906

On Thu, Sep 06, 2018 at 03:13:23PM +0100, Matt Hart wrote: > On 6 September 2018 at 15:04, Theodore Y. Ts'o wrote: > > On Thu, Sep 06, 2018 at 06:45:15AM -0700, Guenter Roeck wrote: > >> Build results: > >> total: 134 pass: 133 fail: 1 > > Do you build

Re: POSIX violation by writeback error

On Wed, Sep 05, 2018 at 04:09:42PM +0800, 焦晓冬 wrote: > Well, since the reader application and the writer application are reading > a same file, they are indeed related. The reader here is expecting > to read the lasted data the writer offers, not any data available. The > reader is surely not

Re: [Bisect] ext4_validate_inode_bitmap:98: comm stress-ng: Corrupt inode bitmap

On Fri, Jul 06, 2018 at 11:43:24AM -0600, dann frazier wrote: > Hi, > We're seeing a regression triggered by the stress-ng[*] "chdir" test > that I've bisected to: > > 044e6e3d74a3 ext4: don't update checksum of new initialized bitmaps > > So far we've only seen failures on servers based on

[GIT PULL] ext4 fixes for 4.18

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

Re: [PATCH 24/32] vfs: syscall: Add fsopen() to prepare for superblock creation [ver #9]

On Thu, Jul 12, 2018 at 10:26:37PM +0100, David Howells wrote: > The problem is that there's more than one actual "open" involved. > > fd = fsopen("ext4");<--- #1 > whatever_interface(fd, "s /dev/sda1"); > whatever_interface(fd, "o

Re: [PATCH 24/32] vfs: syscall: Add fsopen() to prepare for superblock creation [ver #9]

On Thu, Jul 12, 2018 at 11:54:41PM +0100, David Howells wrote: > > Would that mean then that doing: > > mount /dev/sda3 /a > mount /dev/sda3 /b > > would then fail on the second command because /dev/sda3 is already open > exclusively? Good point. One workaround would be to require

Re: [Bisect] ext4_validate_inode_bitmap:98: comm stress-ng: Corrupt inode bitmap

> > Review console log and on each run I have filesystem rebuild. The problem > is that mke2fs I am using is 1.44.3-rc2. I am now reseting the environment > and re-test. > Could it be that you saw the error in ext4_validate_block_bitmap()? The patch which I sent Dann only fixed the problem for

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

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

Re: ext4 ignoring rootfs default mount options

On Wed, Mar 07, 2018 at 02:13:24PM -0500, Lennart Sorensen wrote: > > Trying to use tune2fs -E mount_opts to set some default options, and > can't figure out how to enter two options at once. > > ... > > Sure in this case I can set one with -o and the other with -E, but in > general there seems

Re: ext4 ignoring rootfs default mount options

On Tue, Mar 06, 2018 at 02:03:15PM -0500, Lennart Sorensen wrote: > While switching a system from using ext3 to ext4 (It's about time) I > discovered that setting default options for the filesystem using tune2fs > -o doesn't work for the root filesystem when mounted by the kernel itself. >

Re: [RFC v2 03/83] Add super.h.

On Thu, Mar 15, 2018 at 09:38:29PM +0100, Arnd Bergmann wrote: > > You could also have a resolution of less than a nanosecond. Note > that today, the file time stamps generated by the kernel are in > jiffies resolution, so at best one millisecond. However, most modern > file systems go with the

Re: [RFC v2 00/83] NOVA: a new file system for persistent memory

FYI, your patch set doesn't even compile for me without these fixups. I'm not sure why you were trying to declare inline functions in a header file without the function body? - Ted diff --git a/fs/nova/balloc.c b/fs/nova/balloc.c index

Re: ext4 ignoring rootfs default mount options

On Wed, Mar 07, 2018 at 10:14:28AM -0500, Lennart Sorensen wrote: > > But delalloc is the default for ext4, so a filesystem mounted with > nodelalloc ought to show that in /proc/mounts as far as I am concerned. > The comment in the code says anything that is different than the global > defaults

<    1   2   3   4   5   6   7   8   9   >