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 {
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 kworker/u64
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 usag
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 write_mmp_bloc
y, the change is backwards compatible
> with existing ext4 filesystems.
>
> Signed-off-by: Daniel Rosenberg
Reviewed-by: Andreas Dilger
Cheers, Andreas
signature.asc
Description: Message signed with OpenPGP
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
&g
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 all
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
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 f
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 m
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, whi
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 ki
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
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 wou
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
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
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.
>>>
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
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 declara
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
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 to
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(+)
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 Gar
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);
>>> +
> 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 pci
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 ext4_discard_p
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 allo
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
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 *multiple
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 poorly
th 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
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:
>>>>
>>>>
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 of
;d be 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
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.
>
> CONFIG_EXT4_FS=m
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 ext4_mark_inode
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
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 benchmarks
>
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:
>> @@ -4
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 ha
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 admini
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 potent
0
> ext4_htree_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 f
bably makes
sense 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/n
> 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 *);
>>
>&g
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 callbac
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/
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
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 t_update
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
>
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 syml
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/indirect.c b/fs
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
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.
>
> Recently
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
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 uses
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 no
, 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(
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
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() to
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 i
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 to
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 done
"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/
> 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 mean?
> 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
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:
>>
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 w
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 f
> 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 speculati
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
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
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 Chri
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
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
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 th
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). Ho
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 thi
On Apr 6, 2018, at 5:41 AM, Sayan Ghosh wrote:
>
> Hi all,
>
> The following series of patches aim to store a file with a graded
> information. Consider a scenario of video indexing for learning
> programme where some of the portions of the video is annotated and
> important than other portions,
On Mar 15, 2018, at 11:51 AM, Andiry Xu wrote:
>
> On Thu, Mar 15, 2018 at 2:05 AM, Arnd Bergmann wrote:
>> On Thu, Mar 15, 2018 at 7:11 AM, Andiry Xu wrote:
>>> On Wed, Mar 14, 2018 at 9:54 PM, Darrick J. Wong
>>> wrote:
On Sat, Mar 10, 2018 at 10:17:44AM -0800, Andiry Xu wrote:
>>
On Mar 1, 2018, at 4:37 PM, Rasmus Villemoes wrote:
>
> There are quite a few callers of seq_open that could be simplified by
> setting the ->private member via the seq_open call instead of fetching
> file->private_data afterwards.
>
> Signed-off-by: Rasmus Villemoes
> ---
> I've just included
On Mar 1, 2018, at 9:04 AM, Theodore Ts'o wrote:
> This doesn't seem to make sense; the PC is where we are currently
> executing, and LR is the "Link Register" where the flow of control
> will be returning after the current function returns, right? Well,
> dx_probe should *not* be returning to _
On Dec 29, 2017, at 9:15 PM, Theodore Ts'o wrote:
>
> On Fri, Dec 29, 2017 at 11:17:54PM +0100, Philippe Ombredanne wrote:
>>> As far as I know, none of the licenses explicitly say
>>> copyright license must be on each file. Just that the distribution of
>>> source must include the copyright and
On Dec 14, 2017, at 3:00 PM, Krzysztof Opasiak wrote:
>
> Add rlimit-events calls to file descriptors management
> code to allow tracing of FD usage.
>
> This allows userspace process (monitor) to get notification when
> other process (subject) uses given amount of file descriptors.
>
> This ca
[remove stable@ as this is not really a stable patch]
On Dec 14, 2017, at 7:30 AM, Yan, Zheng wrote:
>
> On Thu, Dec 14, 2017 at 9:43 PM, Jan Kara wrote:
>> On Thu 14-12-17 18:55:27, Yan, Zheng wrote:
>>> We recently got an Oops report:
>>>
>>> BUG: unable to handle kernel NULL pointer derefer
> On Dec 6, 2017, at 17:49, Ingo Molnar wrote:
>
> This exposes some waitqueue internals, but AFAICS the FUSE code already does
> a
> similar trick with fiq->waitq.lock so there's precedent.
What about waitqueue_lock() and waitqueue_unlock() helpers that
lock and unlock, to avoid exposing the
f the large EA inode feature is not set.
>
> This makes my old VM boot again.
>
> Fixes: dbb3c27f5b91c4 (ext4: change fast symlink test to not rely ...)
> Signed-off-by: Andi Kleen
Reviewed-by: Andreas Dilger
> ---
> fs/ext4/inode.c | 9 +
> 1 file changed, 9
On Nov 24, 2017, at 9:51 AM, Andi Kleen wrote:
>
>> We checked old kernels, and old e2fsprogs, and didn't see any cases
>> where fast (<= 60 chars) symlinks were created using external blocks.
>> It seems that _something_ did create them, and it would be good to
>> figure that out so we can deter
On Nov 23, 2017, at 7:04 PM, Andi Kleen wrote:
>
>> As a workaround, you could delete and recreate the symlink with the new
>
> I revert the patch for now. Everything seems to work.
>
>> kernel to create a proper fast symlink. It would be useful to scan
>> the image to see if there are other s
On Nov 23, 2017, at 6:16 PM, Matthew Wilcox wrote:
>
> Here's the current state of the documentation for the XArray. Suggestions
> for improvement gratefully received.
>
> ==
> XArray
> ==
>
> Overview
>
>
> The XArray is an array of ULONG_MAX entries. Each entry can be eith
On Nov 23, 2017, at 4:31 PM, Andi Kleen wrote:
>
> On Thu, Nov 23, 2017 at 05:23:17PM -0500, Theodore Ts'o wrote:
>> On Thu, Nov 23, 2017 at 12:33:30PM -0800, Andi Kleen wrote:
>>>
>>> I have an older qemu VM image that i sometimes use for testing. It
>>> stopped booting with 4.13-4.14 because i
On Nov 7, 2017, at 4:59 AM, Jan Kara wrote:
> On Mon 06-11-17 10:47:08, Davidlohr Bueso wrote:
>> +/*
>> + * Serialize dlist->used_lists such that a 0->1 transition is not
>> + * missed by another thread checking if any of the dlock lists are
>> + * used.
>> + *
>> + * CPU0
On Oct 21, 2017, at 7:39 AM, Nicolas Belouin wrote:
>
> Fix an issue making trusted xattr world readable and other
> cap_sys_admin only
>
> Signed-off-by: Nicolas Belouin
> ---
> fs/hfsplus/xattr.c | 2 +-
> fs/jfs/xattr.c | 5 ++---
> 2 files changed, 3 insertions(+), 4 deletions(-)
>
> dif
On Oct 2, 2017, at 10:58 PM, Konstantin Khlebnikov
wrote:
>
> On 02.10.2017 22:54, Linus Torvalds wrote:
>> On Mon, Oct 2, 2017 at 2:54 AM, Konstantin Khlebnikov
>> wrote:
>>>
>>> This patch implements write-behind policy which tracks sequential writes
>>> and starts background writeback when
On Sep 14, 2017, at 9:04 AM, ChunYu Wang wrote:
>
> Hi GeneBlue,
>
> Thanks for this reporting, do you have any logs related to the bug and
> could find the syscalls enabled for fuzzing during triggering this
> bug? I do not think it is not reproducible, but first, it needs some
> inspections ma
On Sep 7, 2017, at 3:13 PM, Ross Zwisler wrote:
>
> On Thu, Sep 07, 2017 at 01:54:45PM -0700, Dan Williams wrote:
>> On Wed, Sep 6, 2017 at 10:07 AM, Ross Zwisler
>> wrote:
>>> On Tue, Sep 05, 2017 at 09:12:35PM -0500, Eric Sandeen wrote:
On 9/5/17 5:35 PM, Ross Zwisler wrote:
> The ori
On Sep 5, 2017, at 4:35 PM, Ross Zwisler wrote:
>
> If an inode has inline data it is currently prevented from using DAX by a
> check in ext4_should_use_dax(). When the inode grows inline data via
> ext4_create_inline_data() or removes its inline data via
> ext4_destroy_inline_data_nolock(), the
On Sep 6, 2017, at 6:46 AM, Wolfgang Walter wrote:
>
> Am Montag, 28. November 2016, 12:26:38 schrieb Wolfgang Walter:
>> Am Mittwoch, 23. November 2016, 16:40:07 schrieb Andreas Dilger:
>>> Stepping back a bit - does this problem only happen with an external
>>> j
On Sep 5, 2017, at 3:06 PM, Jaegeuk Kim wrote:
>
> This patch fixes bavail and bfree finally.
>
> longf_bfree;/* free blocks in fs */
> longf_bavail; /* free blocks avail to non-superuser */
>
> So, bfree represents all the reserved blocks, while bavail does the space only
> visib
On Aug 31, 2017, at 3:46 PM, Dave Kleikamp wrote:
>
> jfs had previously avoided the use of MAX_LFS_FILESIZE because it hadn't
> accounted for the whole 32-bit index range on 32-bit systems. That has
> been fixed, so we can simplify the code now.
>
> Suggested by Andreas
1 - 100 of 654 matches
Mail list logo
