Re: [PATCH] ext4: add a configurable parameter to prevent endless loop in ext4_mb_discard_group_p

On Apr 8, 2021, at 12:50 PM, Wen Yang wrote: > > Hi Ritesh and Andreas, > > Thank you for your reply. Since there is still a faulty machine, we have > analyzed it again and found it is indeed a very special case: > > > crash> struct ext4_group_info 8813bb5f72d0 > struct ext4_group_info {

Re: [PATCH] ext4: add a configurable parameter to prevent endless loop in ext4_mb_discard_group_preallocations

On Apr 7, 2021, at 5:16 AM, riteshh wrote: > > On 21/04/07 03:01PM, Wen Yang wrote: >> From: Wen Yang >> >> The kworker has occupied 100% of the CPU for several days: >> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND >> 68086 root 20 0 00 0 R 100.0 0.0 9718:18

Re: [PATCH v2] ext4: Fix ext4_error_err save negative errno into superblock

On Apr 1, 2021, at 1:40 AM, Ye Bin wrote: > > As read_mmp_block return 1 when failed. read_mmp_block return -EIO when buffer > isn't uptodate. Thank you for this second patch. Unfortunately, the commit message is still confusing/incorrect because it references read_mmp_block() in the first

Re: [PATCH] ext4: Fix ext4_error_err save negative errno into superblock

On Apr 1, 2021, at 1:22 AM, Ye Bin wrote: > > As read_mmp_block return 1 when failed, so just pass retval to > save_error_info. Thank you for submitting this patch, but it should not be accepted. The commit message is confusing, since the code being changed relates to retval from

Re: [PATCH v2 1/2] ext4: Handle casefolding with encryption

kwards compatible > with existing ext4 filesystems. > > Signed-off-by: Daniel Rosenberg Reviewed-by: Andreas Dilger Cheers, Andreas signature.asc Description: Message signed with OpenPGP

Re: [PATCH 1/2] ext4: Handle casefolding with encryption

On Feb 18, 2021, at 4:21 PM, Daniel Rosenberg wrote: > > On Wed, Feb 17, 2021 at 2:48 PM Andreas Dilger wrote: >> >> On Feb 17, 2021, at 9:08 AM, Theodore Ts'o wrote: >>> >>> The problem is in how the space after the filename in a directory is >>

Re: [RFC] Better page cache error handling

On Feb 24, 2021, at 6:41 AM, Matthew Wilcox wrote: > > On Wed, Feb 24, 2021 at 01:38:48PM +0100, Jan Kara wrote: >>> We allocate a page and try to read it. 29 threads pile up waiting >>> for the page lock in filemap_update_page(). The error returned by the >>> original I/O is shared between

Re: [PATCH v2] vfs: prevent copy_file_range to copy across devices

On Feb 17, 2021, at 1:08 AM, Amir Goldstein wrote: > > You are missing my point. > Never mind which server. The server does not *need* to rely on > vfs_copy_file_range() to copy files from XFS to ext4. > The server is very capable of implementing the fallback generic copy > in case source/target

Re: [PATCH 1/2] ext4: Handle casefolding with encryption

On Feb 17, 2021, at 9:08 AM, Theodore Ts'o wrote: > > On Tue, Feb 16, 2021 at 08:01:11PM -0800, Daniel Rosenberg wrote: >> I'm not sure what the conflict is, at least format-wise. Naturally, >> there would need to be some work to reconcile the two patches, but my >> patch only alters the format

Re: [PATCH v2] vfs: prevent copy_file_range to copy across devices

On Feb 16, 2021, at 6:51 AM, Amir Goldstein wrote: >> >>> This is easy to solve with a flag COPY_FILE_SPLICE (or something) that >>> is internal to kernel users. >>> >>> FWIW, you may want to look at the loop in ovl_copy_up_data() >>> for improvements to nfsd_copy_file_range(). >>> >>> We can

Re: [PATCH 1/2] ext4: Handle casefolding with encryption

On Feb 9, 2021, at 4:22 PM, Theodore Ts'o wrote: > > On Wed, Feb 03, 2021 at 11:31:28AM -0500, Theodore Ts'o wrote: >> On Wed, Feb 03, 2021 at 03:55:06AM -0700, Andreas Dilger wrote: >>> >>> It looks like this change will break the dirdata feature, which is simi

Re: [PATCH v2] ext4: Enable code path when DX_DEBUG is set

On Feb 1, 2021, at 11:41 AM, Vinicius Tinti wrote: > > On Mon, Feb 1, 2021 at 2:13 PM Theodore Ts'o wrote: >> >> On Mon, Feb 01, 2021 at 01:15:29PM -0300, Vinicius Tinti wrote: >>> On Mon, Feb 1, 2021 at 9:49 AM Christoph Hellwig wrote: DX_DEBUG is completely dead code, so either

Re: [PATCH] ext4: Remove unreachable code

On Jan 29, 2021, at 11:58 AM, Vinicius Tinti wrote: > > By enabling -Wunreachable-code-aggressive on Clang the following code > paths are unreachable. > > Commit dd73b5d5cb67 ("ext4: convert dx_probe() to use the ERR_PTR > convention") > Commit ac27a0ec112a ("[PATCH] ext4: initial copy of files

Re: Getting a new fs in the kernel

On Jan 26, 2021, at 09:25, Amy Parker wrote: > > Kernel development newcomer here. I've begun creating a concept for a > new filesystem, and ideally once it's completed, rich, and stable I'd > try to get it into the kernel. Hello Amy, and welcome. I guess the first question to ask is what

Re: [PATCH] ext4: Remove expensive flush on fast commit

On Tue, Jan 5, 2021 at 5:32 PM Daejun Park wrote: > > In the fast commit, it adds REQ_FUA and REQ_PREFLUSH on each fast commit > block when barrier is enabled. However, in recovery phase, ext4 compares > CRC value in the tail. So it is sufficient adds REQ_FUA and REQ_PREFLUSH > on the block that

Re: [PATCH] ext4: Don't leak old mountpoint samples

On Dec 17, 2020, at 11:27 AM, Theodore Y. Ts'o wrote: > > On Tue, Dec 01, 2020 at 04:13:01PM +0100, Richard Weinberger wrote: >> As soon the first file is opened, ext4 samples the mountpoint >> of the filesystem in 64 bytes of the super block. >> It does so using strlcpy(), this means that the

Re: [PATCH 1/2] uapi: fix statx attribute value overlap for DAX & MOUNT_ROOT

On Dec 1, 2020, at 10:44 AM, Eric Sandeen wrote: > > On 12/1/20 11:32 AM, Darrick J. Wong wrote: >> On Tue, Dec 01, 2020 at 10:57:11AM -0600, Eric Sandeen wrote: >>> STATX_ATTR_MOUNT_ROOT and STATX_ATTR_DAX got merged with the same value, >>> so one of them needs fixing. Move STATX_ATTR_DAX. >>>

Re: UAPI value collision: STATX_ATTR_MOUNT_ROOT vs STATX_ATTR_DAX

On Nov 25, 2020, at 12:26 PM, Miklos Szeredi wrote: > > On Wed, Nov 25, 2020 at 5:57 PM David Howells wrote: >> >> Hi Linus, Miklos, Ira, >> >> It seems that two patches that got merged in the 5.8 merge window collided >> and >> no one noticed until now: >> >> 80340fe3605c0 (Miklos Szeredi

Re: [PATCH v2] fs/aio.c: Cosmetic

On Nov 2, 2020, at 2:58 PM, Alejandro Colomar wrote: > Changes: > - Consistently use 'unsigned int', instead of 'unsigned'. > - Add a blank line after variable declarations. > - Move variable declarations to the top of functions. > - Add a blank line at the top of functions if there are no

Re: ext4 regression in v5.9-rc2 from e7bfb5c9bb3d on ro fs with overlapped bitmaps

On Oct 8, 2020, at 1:12 PM, Josh Triplett wrote: > > On Wed, Oct 07, 2020 at 08:57:12PM -0600, Andreas Dilger wrote: >> On Oct 7, 2020, at 2:14 PM, Josh Triplett wrote: >>> If those aren't the right way to express that, I could potentially >>> adapt. I had a simi

Re: ext4 regression in v5.9-rc2 from e7bfb5c9bb3d on ro fs with overlapped bitmaps

On Oct 7, 2020, at 2:14 PM, Josh Triplett wrote: > If those aren't the right way to express that, I could potentially > adapt. I had a similar such conversation on linux-ext4 already (about > inline data with 128-bit inodes), which led to me choosing to abandon > 128-byte inodes rather than try

Re: [PATCH] [v2] ext4: Fix error handling code in add_new_gdb

r error conditions in this function and didn't see any similar problems. Reviewed-by: Andreas Dilger > --- > > Changelog: > > v2: - Remove changes to ext4_handle_dirty_super()'s > error handling path. > --- > fs/ext4/resize.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deleti

Re: [PATCH v4 1/3] io_uring: use an enumeration for io_uring_register(2) opcodes

On Aug 26, 2020, at 1:43 PM, Kees Cook wrote: > > On Thu, Aug 13, 2020 at 05:32:52PM +0200, Stefano Garzarella wrote: >> The enumeration allows us to keep track of the last >> io_uring_register(2) opcode available. >> >> Behaviour and opcodes names don't change. >> >> Signed-off-by: Stefano

Re: [PATCH 9/9] iomap: Change calling convention for zeroing

On Aug 24, 2020, at 9:26 PM, Matthew Wilcox wrote: > > On Tue, Aug 25, 2020 at 10:27:35AM +1000, Dave Chinner wrote: >>> do { >>> - unsigned offset, bytes; >>> - >>> - offset = offset_in_page(pos); >>> - bytes = min_t(loff_t, PAGE_SIZE - offset, count); >>> +

Re: [PATCH] ext4: move buffer_mapped() to proper position

> On Aug 7, 2020, at 2:02 PM, ty...@mit.edu wrote: > > Thanks, applied, although I rewrote the commit description to make it > be a bit more clearer: > >fs: prevent BUG_ON in submit_bh_wbc() > >If a device is hot-removed --- for example, when a physical device is >unplugged from

Re: [PATCH v2 3/3] ext4: add needed paramter to ext4_mb_discard_preallocations trace

On Aug 4, 2020, at 7:02 PM, brookxu wrote: > > Add the needed value to ext4_mb_discard_preallocations trace, so > we can more easily observe the requested number of trim. > > Signed-off-by: Chunguang Xu IMHO, this should be part of the previous patch that is changing the API for

Re: [PATCH v2 2/3] ext4: limit the length of per-inode prealloc list

On Aug 4, 2020, at 7:02 PM, brookxu wrote: > > In the scenario of writing sparse files, the Per-inode prealloc list may > be very long, resulting in high overhead for ext4_mb_use_preallocated(). > To circumvent this problem, we limit the maximum length of per-inode > prealloc list to 512 and

Re: [PATCH v2 1/3] ext4: reorganize if statement of ext4_mb_release_context()

On Aug 4, 2020, at 7:01 PM, brookxu wrote: > > Reorganize the if statement of ext4_mb_release_context(), make it > easier to read. > > Signed-off-by: Chunguang Xu Reviewed-by: Andreas Dilger > --- > fs/ext4/mballoc.c | 27 +-- > 1 file chang

Re: [PATCH 0/3] readfile(2): a new syscall to make open/read/close faster

On Jul 4, 2020, at 8:46 PM, Jan Ziak <0xe2.0x9a.0...@gmail.com> wrote: > > On Sun, Jul 5, 2020 at 4:16 AM Matthew Wilcox wrote: >> >> On Sun, Jul 05, 2020 at 04:06:22AM +0200, Jan Ziak wrote: >>> Hello >>> >>> At first, I thought that the proposed system call is capable of >>> reading

Re: [PATCH] checkpatch/coding-style: Allow 100 column lines

On May 29, 2020, at 5:12 PM, Joe Perches wrote: > > Change the maximum allowed line length to 100 from 80. What is the benefit/motivation for changing this? The vast majority of files are wrapped at 80 columns, and if some files start being wrapped at 100 columns they will either display

Re: [PATCH V4 7/8] fs/ext4: Introduce DAX inode flag

with the > exception of if VERITY or ENCRYPT is set. > > Disallow setting VERITY or ENCRYPT if DAX is set. > > Finally, on regular files, flag the inode to not be cached to facilitate > changing S_DAX on the next creation of the inode. > > Signed-off-by: Ira Weiny Reviewed

Re: [PATCH V3 7/8] fs/ext4: Introduce DAX inode flag

On May 20, 2020, at 2:55 PM, Darrick J. Wong wrote: > On Wed, May 20, 2020 at 01:02:42PM -0700, Ira Weiny wrote: >> On Wed, May 20, 2020 at 01:26:44PM -0600, Andreas Dilger wrote: >>> On May 19, 2020, at 11:57 PM, ira.we...@intel.com wrote: >>>> >>>&

Re: [PATCH V3 7/8] fs/ext4: Introduce DAX inode flag

On May 19, 2020, at 11:57 PM, ira.we...@intel.com wrote: > > From: Ira Weiny > > Add a flag to preserve FS_XFLAG_DAX in the ext4 inode. > > Set the flag to be user visible and changeable. Set the flag to be > inherited. Allow applications to change the flag at any time with the > exception

Re: [PATCH] ext4: Reduce ext4 timestamp warnings

in favor of a severely rare-limited warning in the actual case that Y2038 timestamps cannot be stored, but the current message is too verbose for now and I agree it is better to remove it while discussions on the best solution are underway. Reviewed-by: Andreas Dilger > --- > fs/ext4/ext4.h |

Re: "beyond 2038" warnings from loopback mount is noisy

On Sep 3, 2019, at 12:15 PM, Qian Cai wrote: > > On Tue, 2019-09-03 at 09:36 -0700, Deepa Dinamani wrote: >> We might also want to consider updating the file system the LTP is >> being run on here. > > It simply format (mkfs.ext4) a loop back device on ext4 with the kernel. > >

Re: [PATCH 09/20] ext4: Initialize timestamps limits

On Aug 3, 2019, at 2:24 PM, Arnd Bergmann wrote: > > On Sat, Aug 3, 2019 at 6:03 PM Theodore Y. Ts'o wrote: >> >> 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

Re: [PATCH] ext4: Fix deadlock on page reclaim

On Jul 26, 2019, at 8:59 PM, Damien Le Moal wrote: > > On 2019/07/27 7:55, Theodore Y. Ts'o wrote: >> 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

Re: [PATCH] mbcache: Speed up cache entry creation

On Jul 23, 2019, at 10:01 PM, Sultan Alsawaf wrote: > > On Tue, Jul 23, 2019 at 10:56:05AM -0600, Andreas Dilger wrote: >> Do you have any kind of performance metrics that show this is an actual >> improvement in performance? This would be either macro-level bench

Re: [PATCH] ext4: Fix deadlock on page reclaim

On Jul 25, 2019, at 5:54 AM, Christoph Hellwig wrote: > > On Thu, Jul 25, 2019 at 06:33:58PM +0900, Damien Le Moal wrote: >> +gfp_t gfp_mask; >> + >> switch (ext4_inode_journal_mode(inode)) { >> case EXT4_INODE_ORDERED_DATA_MODE: >> case EXT4_INODE_WRITEBACK_DATA_MODE: >> @@

Re: [PATCH] mbcache: Speed up cache entry creation

On Jul 22, 2019, at 11:35 PM, Sultan Alsawaf wrote: > > From: Sultan Alsawaf > > In order to prevent redundant entry creation by racing against itself, > mb_cache_entry_create scans through a hash-list of all current entries > in order to see if another allocation for the requested new entry

Re: [PATCH v4 0/7] vfs: make immutable files actually immutable

On Jun 25, 2019, at 12:03 PM, Darrick J. Wong wrote: > > On Tue, Jun 25, 2019 at 03:36:31AM -0700, Christoph Hellwig wrote: >> On Fri, Jun 21, 2019 at 04:56:50PM -0700, Darrick J. Wong wrote: >>> Hi all, >>> >>> The chattr(1) manpage has this to say about the immutable bit that >>> system

Re: [PATCH] ext4: remove unnecessary gotos in ext4_xattr_set_entry

On May 31, 2019, at 6:10 AM, Pavel Tikhomirov wrote: > > In the "out" label we only iput old/new_ea_inode-s, in all these places > these variables are always NULL so there is no point in goto to "out". > > Signed-off-by: Pavel Tikhomirov I'm not a fan of changes like this, since it adds

Re: [PATCH v2] ext4: fix use-after-free in dx_release()

ee_fill_tree+0x2d4/0x300 > ext4_readdir+0x244/0x6f8 > iterate_dir+0xbc/0x160 > SyS_getdents64+0x94/0x174 > > Signed-off-by: Sahitya Tummala Reviewed-by: Andreas Dilger > --- > v2: > add a comment in dx_release() > > fs/ext4/namei.c | 5 - > 1 file changed, 4

Re: [PATCH] ext4: fix use-after-free in dx_release()

se to include a comment like: /* save local copy, "info" may be freed after brelse() */ Looks fine otherwise. Reviewed-by: Andreas Dilger > --- > fs/ext4/namei.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/fs/ext4/namei.c b/fs/ext

Re: [RFC][PATCHSET] sorting out RCU-delayed stuff in ->destroy_inode()

> On Apr 29, 2019, at 10:26 PM, Al Viro wrote: > > On Mon, Apr 29, 2019 at 10:18:04PM -0600, Andreas Dilger wrote: >>> >>> void*i_private; /* fs or device private pointer */ >>> + void (*free_inode)(struct inode *); >> >

Re: [RFC][PATCHSET] sorting out RCU-delayed stuff in ->destroy_inode()

On Apr 29, 2019, at 9:09 PM, Al Viro wrote: > > On Tue, Apr 16, 2019 at 11:01:16AM -0700, Linus Torvalds wrote: >> >> I only skimmed through the actual filesystem (and one networking) >> patches, but they looked like trivial conversions to a better >> interface. > > ... except that this

Re: [PATCH v2] ext4: cond_resched in work-heavy group loops

ismel Kumykov Reviewed-by: Andreas Dilger > --- > v2: > - a few other places that in testing showed to be slow > > fs/ext4/block_validity.c | 1 + > fs/ext4/mballoc.c| 2 ++ > 2 files changed, 3 insertions(+) > > diff --git a/fs/ext4/block_validity.c b/fs/ext4/

Re: [PATCH v2] ext4: fix use-after-free race with debug_want_extra_isize

eported-by: syzbot+f584efa0ac7213c22...@syzkaller.appspotmail.com > Reviewed-by: Jan Kara > Signed-off-by: Barret Rhoden > Cc: sta...@vger.kernel.org # 4.14.111 Reviewed-by: Andreas Dilger > --- > > - Updated tags > > Thanks

Re: [PATCH] jbd2: do not start commit when t_updates does not back to zero

On Mar 29, 2019, at 3:25 PM, Jan Kara wrote: > > On Sun 24-03-19 11:38:35, Liu Song wrote: >> When t_updates back to zero, it guaranteed wake up process which >> waiting on j_wait_updates. If we triggered a commit start without >> considered t_updates, the commit thread wakes up and find

Re: [PATCH] ext4: use BUG() instead of BUG_ON(1)

On Mar 25, 2019, at 12:14 PM, Darrick J. Wong wrote: > > On Mon, Mar 25, 2019 at 02:00:25PM +0100, Arnd Bergmann wrote: >> BUG_ON(1) leads to bogus warnings from clang when >> CONFIG_PROFILE_ANNOTATED_BRANCHES is set: >> >> fs/ext4/inode.c:544:4: error: variable 'retval' is used uninitialized

Re: [PATCH 2/4] Expose O_PATHSTATIC to userspace

On Feb 12, 2019, at 7:54 AM, demioben...@gmail.com wrote: > > From: "Demi M. Obenour" > > This adds the file open flag O_PATHSTATIC, which ensures that symbolic > links are *never* followed, even in path components other than the last. > This is distinct from O_NOFOLLOW, which only prevents

Re: [PATCH 2/2] ext4: annotate implicit fall throughs

] > fs/ext4/indirect.c:1440:6: warning: this statement may fall through > [-Wimplicit-fallthrough=] > > Signed-off-by: Mathieu Malaterre Reviewed-by: Andreas Dilger > --- > fs/ext4/indirect.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/fs/ext4/indirec

Re: [PATCH 1/2] ext4: annotate implicit fall throughs

warning: this statement may fall through > [-Wimplicit-fallthrough=] > fs/ext4/hash.c:246:15: warning: this statement may fall through > [-Wimplicit-fallthrough=] > > Signed-off-by: Mathieu Malaterre Reviewed-by: Andreas Dilger > --- > fs/ext4/hash.c | 2 ++ > 1 file ch

Re: Preserving a rev 0.0 ext2 filesystem

On Jan 12, 2019, at 2:43 AM, Geert Uytterhoeven wrote: > > Hi Ted, > > I'm still regularly using a Linux rev 0.0 ext2 filesystem as a ramdisk > on m68k, containing mid-90's binaries, from right after the a.out-to-ELF > transition, so I notice if someone breaks old syscall support. > >

Re: [Qemu-devel] d_off field in struct dirent and 32-on-64 emulation

On Dec 28, 2018, at 4:18 AM, Peter Maydell wrote: > > On Fri, 28 Dec 2018 at 00:23, Andreas Dilger wrote: >> On Dec 27, 2018, at 10:41 AM, Peter Maydell wrote: >>> As you note, this causes breakage for userspace programs which >>> need to implement an API/ABI wit

Re: [Qemu-devel] d_off field in struct dirent and 32-on-64 emulation

On Dec 27, 2018, at 10:41 AM, Peter Maydell wrote: > > On Thu, 27 Dec 2018 at 17:19, Florian Weimer wrote: >> We have a bit of an interesting problem with respect to the d_off >> field in struct dirent. >> >> When running a 64-bit kernel on certain file systems, notably ext4, >> this field

Re: [PATCH v2 5/5] nfs: don't clear STATX_ATIME from result_mask

On Oct 20, 2018, at 11:46 AM, Trond Myklebust wrote: > > On Fri, 2018-10-19 at 22:48 +0200, Miklos Szeredi wrote: >> On Fri, Oct 19, 2018 at 8:14 PM, Trond Myklebust >> wrote: >>> On Fri, 2018-10-19 at 19:46 +0200, Miklos Szeredi wrote: How is it then that only STATX_ATIME is cleared and

Re: [PATCH v2 5/5] nfs: don't clear STATX_ATIME from result_mask

On Oct 20, 2018, at 11:46 AM, Trond Myklebust wrote: > > On Fri, 2018-10-19 at 22:48 +0200, Miklos Szeredi wrote: >> On Fri, Oct 19, 2018 at 8:14 PM, Trond Myklebust >> wrote: >>> On Fri, 2018-10-19 at 19:46 +0200, Miklos Szeredi wrote: How is it then that only STATX_ATIME is cleared and

Re: [PATCH] ext4: remove code duplication in update_ind/bind/tind_extent_range

, though I'd suggest a couple of very minor style changes (inline). You can add to the resubmitted patch: Reviewed-by: Andreas Dilger > Signed-off-by: Vasily Averin > --- > fs/ext4/migrate.c | 111 ++ > 1 file changed, 23 insertions(+), 8

Re: [PATCH] ext4: remove code duplication in update_ind/bind/tind_extent_range

, though I'd suggest a couple of very minor style changes (inline). You can add to the resubmitted patch: Reviewed-by: Andreas Dilger > Signed-off-by: Vasily Averin > --- > fs/ext4/migrate.c | 111 ++ > 1 file changed, 23 insertions(+), 8

Re: [PATCH v2 11/11] ext4: access to uninitialized bh fields in ext4_xattr_set_handle()

On Oct 30, 2018, at 9:39 PM, Vasily Averin wrote: > > On 10/31/2018 04:30 AM, Andreas Dilger wrote: >> Could you please explain your statement below that on-stack >> initialization does not zero unspecified fields? According >> to documents I found, for example: &g

Re: [PATCH v2 11/11] ext4: access to uninitialized bh fields in ext4_xattr_set_handle()

On Oct 30, 2018, at 9:39 PM, Vasily Averin wrote: > > On 10/31/2018 04:30 AM, Andreas Dilger wrote: >> Could you please explain your statement below that on-stack >> initialization does not zero unspecified fields? According >> to documents I found, for example: &g

Re: in_compat_syscall() returns from kernel thread for X86_32.

On Oct 18, 2018, at 11:26 AM, Andy Lutomirski wrote: > > On Wed, Oct 17, 2018 at 9:36 PM NeilBrown wrote: >> >> On Wed, Oct 17 2018, Andy Lutomirski wrote: >> >>> On Wed, Oct 17, 2018 at 6:48 PM NeilBrown wrote: Was: Re: [tip:x86/asm] x86/entry: Rename is_{ia32,x32}_task()

Re: in_compat_syscall() returns from kernel thread for X86_32.

On Oct 18, 2018, at 11:26 AM, Andy Lutomirski wrote: > > On Wed, Oct 17, 2018 at 9:36 PM NeilBrown wrote: >> >> On Wed, Oct 17 2018, Andy Lutomirski wrote: >> >>> On Wed, Oct 17, 2018 at 6:48 PM NeilBrown wrote: Was: Re: [tip:x86/asm] x86/entry: Rename is_{ia32,x32}_task()

Re: [PATCH v2 6/5] statx: add STATX_RESULT_MASK flag

On Oct 19, 2018, at 11:42 AM, Miklos Szeredi wrote: >>> +#define STATX_RESULT_MASK STATX__RESERVED >> >> Please don't use that bit. > > Using it internally is perfectly harmless. If we'll need to extend > statx in the future and make use of this flag externally, then we can > easily move the

Re: [PATCH v2 6/5] statx: add STATX_RESULT_MASK flag

On Oct 19, 2018, at 11:42 AM, Miklos Szeredi wrote: >>> +#define STATX_RESULT_MASK STATX__RESERVED >> >> Please don't use that bit. > > Using it internally is perfectly harmless. If we'll need to extend > statx in the future and make use of this flag externally, then we can > easily move the

Re: [PATCH v2 1/5] orangefs: fix request_mask misuse

On Oct 19, 2018, at 6:20 AM, Miklos Szeredi wrote: > > Orangefs only handles STATX_BASIC_STATS in its getattr implementation, so > mask off all other flags. Not doing so results in statx(2) forcing a > refresh of cached attributes on any other requested flag (i.e. STATX_BTIME > currently) due

Re: [PATCH v2 1/5] orangefs: fix request_mask misuse

On Oct 19, 2018, at 6:20 AM, Miklos Szeredi wrote: > > Orangefs only handles STATX_BASIC_STATS in its getattr implementation, so > mask off all other flags. Not doing so results in statx(2) forcing a > refresh of cached attributes on any other requested flag (i.e. STATX_BTIME > currently) due

Re: [PATCH 2/3] uapi: get rid of STATX_ALL

On Oct 18, 2018, at 7:11 AM, Miklos Szeredi wrote: > > Constants of the *_ALL type can be actively harmful due to the fact that > developers will usually fail to consider the possible effects of future > changes to the definition. > > Remove STATX_ALL from the uapi, while no damage has been

Re: [PATCH 2/3] uapi: get rid of STATX_ALL

On Oct 18, 2018, at 7:11 AM, Miklos Szeredi wrote: > > Constants of the *_ALL type can be actively harmful due to the fact that > developers will usually fail to consider the possible effects of future > changes to the definition. > > Remove STATX_ALL from the uapi, while no damage has been

Re: [PATCH 3/3] statx: add STATX_ATTRIBUTES flag

t;got" stx_attributes or not. So for now we can just deal with > this flag in the generic code. > > Signed-off-by: Miklos Szeredi > Cc: David Howells > Cc: Michael Kerrisk Reviewed-by: Andreas Dilger > --- > fs/stat.c | 3 +++ > include/uapi/

Re: [PATCH 3/3] statx: add STATX_ATTRIBUTES flag

t;got" stx_attributes or not. So for now we can just deal with > this flag in the generic code. > > Signed-off-by: Miklos Szeredi > Cc: David Howells > Cc: Michael Kerrisk Reviewed-by: Andreas Dilger > --- > fs/stat.c | 3 +++ > include/uapi/

Re: [PATCH 2/3] uapi: get rid of STATX_ALL

> On Oct 18, 2018, at 7:15 AM, Florian Weimer wrote: > > * Miklos Szeredi: > >> #define STATX__RESERVED 0x8000U /* Reserved for future >> struct statx expansion */ > > What about this? Isn't it similar to STATX_ALL in the sense that we > don't know yet what it will

Re: [PATCH 2/3] uapi: get rid of STATX_ALL

> On Oct 18, 2018, at 7:15 AM, Florian Weimer wrote: > > * Miklos Szeredi: > >> #define STATX__RESERVED 0x8000U /* Reserved for future >> struct statx expansion */ > > What about this? Isn't it similar to STATX_ALL in the sense that we > don't know yet what it will

Re: [PATCH] ext4: direct return when jinode allocate failed

> On Oct 16, 2018, at 8:26 PM, liu.son...@zte.com.cn wrote: > >> On Tue, Oct 16, 2018 at 10:55:26PM +0800, fishland wrote: >>> The jinode does not need protected by *i_lock*, we can return >>> directly if memory allocation fails. >>> >> >> I don't see anything wrong with this patch, but at the

Re: [PATCH] ext4: direct return when jinode allocate failed

> On Oct 16, 2018, at 8:26 PM, liu.son...@zte.com.cn wrote: > >> On Tue, Oct 16, 2018 at 10:55:26PM +0800, fishland wrote: >>> The jinode does not need protected by *i_lock*, we can return >>> directly if memory allocation fails. >>> >> >> I don't see anything wrong with this patch, but at the

Re: statx(2) API and documentation

On Oct 17, 2018, at 1:04 PM, Miklos Szeredi wrote: > > On Wed, Oct 17, 2018 at 8:45 PM, Andreas Dilger wrote: >> On Oct 17, 2018, at 12:24 PM, Miklos Szeredi wrote: >>> >>> I'm trying to implement statx for fuse and ran into the following issues: >>>

Re: statx(2) API and documentation

On Oct 17, 2018, at 1:04 PM, Miklos Szeredi wrote: > > On Wed, Oct 17, 2018 at 8:45 PM, Andreas Dilger wrote: >> On Oct 17, 2018, at 12:24 PM, Miklos Szeredi wrote: >>> >>> I'm trying to implement statx for fuse and ran into the following issues: >>>

Re: statx(2) API and documentation

On Oct 17, 2018, at 12:24 PM, Miklos Szeredi wrote: > > I'm trying to implement statx for fuse and ran into the following issues: > > - Need a STATX_ATTRIBUTES bit, so that userspace can explicitly ask > for stx_attribute; otherwise if querying has non-zero cost, then > filesystem cannot do it

Re: statx(2) API and documentation

On Oct 17, 2018, at 12:24 PM, Miklos Szeredi wrote: > > I'm trying to implement statx for fuse and ran into the following issues: > > - Need a STATX_ATTRIBUTES bit, so that userspace can explicitly ask > for stx_attribute; otherwise if querying has non-zero cost, then > filesystem cannot do it

Re: Future of dosfstools project (FAT)

On Sep 29, 2018, at 2:40 AM, Pali Rohár wrote: > > Hi! > > Last year I did some research how Windows and Linux tools handle FAT > labels (boot sector vs root directory) and proposed some unification. > More in thread: https://www.spinics.net/lists/kernel/msg2640891.html > > My proposed change

Re: Future of dosfstools project (FAT)

On Sep 29, 2018, at 2:40 AM, Pali Rohár wrote: > > Hi! > > Last year I did some research how Windows and Linux tools handle FAT > labels (boot sector vs root directory) and proposed some unification. > More in thread: https://www.spinics.net/lists/kernel/msg2640891.html > > My proposed change

Re: [PATCH 1/3] ext4: super: Fix spectre gadget in ext4_quota_on

> On Jul 27, 2018, at 11:46 AM, Josh Poimboeuf wrote: > > On Fri, Jul 27, 2018 at 04:23:55PM +, Jeremy Cline wrote: >> 'type' is a user-controlled value used to index into 's_qf_names', which >> can be used in a Spectre v1 attack. Clamp 'type' to the size of the >> array to avoid a

Re: [PATCH 1/3] ext4: super: Fix spectre gadget in ext4_quota_on

> On Jul 27, 2018, at 11:46 AM, Josh Poimboeuf wrote: > > On Fri, Jul 27, 2018 at 04:23:55PM +, Jeremy Cline wrote: >> 'type' is a user-controlled value used to index into 's_qf_names', which >> can be used in a Spectre v1 attack. Clamp 'type' to the size of the >> array to avoid a

Re: Why inode number is zero in writeback?

On Jul 25, 2018, at 6:01 AM, Ilya Plenne wrote: > > I'm researching linux kernel. Right now only for v3.10.61, it's just > proof of concept. > > I need to pass-through some hints to hardware about what kind of data > in particular WRITE\READ operation. E.g. read inodes bitmap or write > journal

Re: Why inode number is zero in writeback?

On Jul 25, 2018, at 6:01 AM, Ilya Plenne wrote: > > I'm researching linux kernel. Right now only for v3.10.61, it's just > proof of concept. > > I need to pass-through some hints to hardware about what kind of data > in particular WRITE\READ operation. E.g. read inodes bitmap or write > journal

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

On Jun 29, 2018, at 1:36 PM, 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 file, then

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

On Jun 29, 2018, at 1:36 PM, 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 file, then

Re: [PATCH 10/10] Dynamic fault injection

On May 18, 2018, at 1:10 PM, Kent Overstreet <kent.overstr...@gmail.com> wrote: > > On Fri, May 18, 2018 at 01:05:20PM -0600, Andreas Dilger wrote: >> On May 18, 2018, at 1:49 AM, Kent Overstreet <kent.overstr...@gmail.com> >> wrote: >>> >>&

Re: [PATCH 10/10] Dynamic fault injection

On May 18, 2018, at 1:10 PM, Kent Overstreet wrote: > > On Fri, May 18, 2018 at 01:05:20PM -0600, Andreas Dilger wrote: >> On May 18, 2018, at 1:49 AM, Kent Overstreet >> wrote: >>> >>> Signed-off-by: Kent Overstreet >> >> I agree with C

Re: [PATCH 10/10] Dynamic fault injection

On May 18, 2018, at 1:49 AM, Kent Overstreet wrote: > > Signed-off-by: Kent Overstreet I agree with Christoph that even if there was some explanation in the cover letter, there should be something at least as good in the patch itself. The

Re: [PATCH 10/10] Dynamic fault injection

On May 18, 2018, at 1:49 AM, Kent Overstreet wrote: > > Signed-off-by: Kent Overstreet I agree with Christoph that even if there was some explanation in the cover letter, there should be something at least as good in the patch itself. The cover letter is not saved, but the commit stays around

Re: copy_file_range and user space tools to do copy fastest

On Apr 27, 2018, at 5:41 PM, Eric Biggers <ebigge...@gmail.com> wrote: > > On Fri, Apr 27, 2018 at 01:45:40PM -0600, Andreas Dilger wrote: >> On Apr 27, 2018, at 12:25 PM, Steve French <smfre...@gmail.com> wrote: >>> >>> Are there any user space t

Re: copy_file_range and user space tools to do copy fastest

On Apr 27, 2018, at 5:41 PM, Eric Biggers wrote: > > On Fri, Apr 27, 2018 at 01:45:40PM -0600, Andreas Dilger wrote: >> On Apr 27, 2018, at 12:25 PM, Steve French wrote: >>> >>> Are there any user space tools (other than our test tools and xfs_io >>> etc

Re: copy_file_range and user space tools to do copy fastest

On Apr 27, 2018, at 12:25 PM, Steve French wrote: > > Are there any user space tools (other than our test tools and xfs_io > etc.) that support copy_file_range? Looks like at least cp and rsync > and dd don't. That syscall which now has been around a couple years, > and was

Re: copy_file_range and user space tools to do copy fastest

On Apr 27, 2018, at 12:25 PM, Steve French wrote: > > Are there any user space tools (other than our test tools and xfs_io > etc.) that support copy_file_range? Looks like at least cp and rsync > and dd don't. That syscall which now has been around a couple years, > and was reminded about at

Re: [PATCH] vfs: Undo an overly zealous MS_RDONLY -> SB_RDONLY conversion

On Apr 20, 2018, at 11:03 AM, Linus Torvalds wrote: > > On Fri, Apr 20, 2018 at 5:35 AM, David Howells wrote: >> In do_mount() when the MS_* flags are being converted to MNT_* flags, >> MS_RDONLY got accidentally convered to SB_RDONLY. > >

Re: [PATCH] vfs: Undo an overly zealous MS_RDONLY -> SB_RDONLY conversion

On Apr 20, 2018, at 11:03 AM, Linus Torvalds wrote: > > On Fri, Apr 20, 2018 at 5:35 AM, David Howells wrote: >> In do_mount() when the MS_* flags are being converted to MNT_* flags, >> MS_RDONLY got accidentally convered to SB_RDONLY. > > Applied. > > I guess they have the same value (1).

Re: [PATCH 2/6] statfs: use << to align with fs header

On Apr 13, 2018, at 10:11 AM, Christian Brauner wrote: > > Consistenly use << to define ST_* constants. This also aligns them with > their MS_* counterparts in fs.h IMHO, using (1 << 10) makes the code harder to debug. If you see a field in a structure like

Re: [PATCH 2/6] statfs: use << to align with fs header

On Apr 13, 2018, at 10:11 AM, Christian Brauner wrote: > > Consistenly use << to define ST_* constants. This also aligns them with > their MS_* counterparts in fs.h IMHO, using (1 << 10) makes the code harder to debug. If you see a field in a structure like 0x8354, it is non-trivial to map

  1   2   3   4   5   6   7   8   9   10   >