Sergei Antonov | 26 Mar 03:06 2015
Picon

Re: [PATCH 2.6 to 4.0] hfsplus: fix B-tree corruption after insertion at position 0

On 19 March 2015 at 18:40, Hin-Tak Leung <htl10 <at> users.sourceforge.net> wrote:
>>> Also, the logic of hfs_brec_insert() in the plain hfs (without +) driver in
>>> fs/hfs/brec.c is essentially the same, so I believe there is the need of another
>>> similiar patch for that also. Can you provide that also?
>>
>>No. The original HFS is very old. The only reasonable purpose of its
>>implementation in Linux IMO is to read data from old disks. Read-only
>>mode that is.
>
> I don't think it is right to dictate how users should use their linux box.
> On the whole we should only stop fixing bugs if we are going
> to deprecate hfs (and subsequently remove it). Also, there is some value
> in keeping two file systems which are code-wise very similar in sync.
>
> If you cannot find the time, but otherwise have no objection, I'd be happy to
> spend the time to prepare the patch, and add your signed-off on it?

Of course, I have no objections. But, please, do not add me in
signed-off-by. Because signed-off-by implies some responsibility, and
I do not want to have one for hfs.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Boqun Feng | 25 Mar 19:45 2015
Picon

[PATCH v2] vfs: avoid recopying file names in getname_flags

In the current implementation of getname_flags, a file name in the
user-space will be recopied if it takes more space that
EMBEDDED_NAME_MAX, however, at this moment, EMBEDDED_NAME_MAX bytes of
the file name are already copied into kernel address space, the only
reason why the recopy is needed is that "kname", which points to the
string of the file name, needs to be relocated.

And the recopy can be avoided if we change the memory layout of the
`names_cachep` allocation. By putting `struct filename` at the tail of
the allocation instead of the head, relocation of kname is avoided.
Once putting the struct at the tail, each byte in the user space will be
copied only one time, so the recopy is avoided.

Of course, other functions aware of the layout of the `names_cachep`
allocation, i.e., getname_kernel and putname also need to be modified to
adapt to the new layout.

Since we change the layout of `names_cachep` allocation, in order to
figure out whether kname and the struct are separate, we now need to
check whether the file name string starts at the address
EMBEDDED_NAME_MAX bytes before the address of the struct.  As a result,
`iname`, which points the end of `struct filename`, is not needed
anymore.

Signed-off-by: Boqun Feng <boqun.feng <at> gmail.com>
---
v1 --> v2:
Rebase the patch onto the for-next branch of Al's vfs repo.

 fs/namei.c         | 45 ++++++++++++++++++++++++++++-----------------
(Continue reading)

Boaz Harrosh | 25 Mar 14:34 2015

[PATCH 0/3 v4] dax: some dax fixes and cleanups

Hi

[v4] dax: some dax fixes and cleanups
* First patch fixed according to Andrew's comments. Thanks Andrew.
  1st and 2nd patch can go into current Kernel as they fix something
  that was merged this release.
* Added a new patch to fix up splice in the dax case, and cleanup.
  This one can wait for 4.1 (Also the first two not that anyone uses dax
  in production.)
* DAX freeze is not fixed yet. As we have more problems then I originally
  hoped for, as pointed out by Dave.
  (Just as a referance I'm sending a NO-GOOD additional patch to show what
   is not good enough to do. Was the RFC of [v3])
* Not re-posting the xfstest Dave please pick this up (It already found bugs
  in none dax FSs)

[v3] dax: Fix mmap-write not updating c/mtime
* I'm re-posting the two DAX patches that fix the mmap-write after read
  problem with DAX. (No changes since [v2])
* I'm also posting a 3rd RFC patch to address what Jan said about fs_freeze
  and making mapping read-only. 
  Jan Please review and see if this is what you meant.

[v2]
Jan Kara has pointed out that if we add the
sb_start/end_pagefault pair in the new pfn_mkwrite we
are then fixing another bug where: A user could start
writing to the page while filesystem is frozen.

[v1]
(Continue reading)

hujianyang | 25 Mar 14:00 2015

[PATCH RFC] ubifs: introduce an ioctl to get UBIFS files compressed size

As discussed in last mail, I don't think record compressed size in
*ubifs_ino_inode* could suffer power cut easily, rebuild the records
of each file may increase the mount time and we may need to write
more meta data to keep the consistency of compressed size. And I
don't think *fiemap* is a good interface either, because it is can't
report compressed size at present.

http://lists.infradead.org/pipermail/linux-mtd/2015-February/057978.html

So I tried another way, introduce a new ioctl which scan the tnc_tree
to get the compressed size in each *ubifs_data_node* of the request
file.

Similar with:
https://patchwork.kernel.org/patch/117782/

But This isn't a good solution in performance side. Just want to show
my code to push the achievement of this feature.

Any test or any advisement is welcomed.

Thanks everyone~!

Signed-off-by: hujianyang <hujianyang <at> huawei.com>
---
 fs/ubifs/ioctl.c |   61 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 fs/ubifs/ubifs.h |    2 +
 2 files changed, 63 insertions(+), 0 deletions(-)

diff --git a/fs/ubifs/ioctl.c b/fs/ubifs/ioctl.c
(Continue reading)

Dave Chinner | 24 Mar 11:50 2015

[PATCH 0/8 v2] xfs: DAX support

Hi folks,

This is an updated version of the XFS DAX support patchset. It was
first posted here:

http://oss.sgi.com/pipermail/xfs/2015-March/040804.html

This version of the patchset sits on top of the current for-next
branch of the XFS dev tree.

The series has grown slightly as a result of the first round of
reviews. The initial patch is a new patch that reworks the new XFS
mmap lock to nest correctly inside freeze notifications, as noticed
and requested by Jan Kara.

The second patch has been updated to move unwritten extent
conversion back into do_dax_fault so the completion function does
not need ot be passed around any further.

The third patch is also a new patch, derived from Willy's patch to
allow ext4 to correctly nest locking and freeze operations during
page faults. I gutted that patch down to the bare infrastructure
that was necessary for XFS, and havent included any of the ext4
changes because the unwritten extent conversion problems are dealt
with by the previous patch.

The rest of the patch set is updating the XFS support to use the new
infrastructure and changed mmap locking order via __dax_fault. Most
of the changes fall in the file operations patch (patch 5). 

(Continue reading)

Sergei Antonov | 24 Mar 05:52 2015
Picon

[PATCH v2] hfsplus: fix expand when not enough available space

v1->v2
* Description clarified.

Fix a bug which is reproduced as follows. Create a file:
 echo abc > test_file
Try to expand the file beyond available space:
 truncate --size=<size exceeding available space> test_file
Since HFS+ does not support file size > allocated size, truncate should fail.
However, it ends successfully. The driver returns success despite having been
unable to allocate the requested space for the file. Also filesystem check finds
an error:
 Checking catalog file.
 Incorrect size for file test_file
 (It should be 469094400 instead of 1000000000)

Add a piece of code analogous to code in the fat driver.
Now a proper error is returned and filesystem remains consistent.

Cc: Andrew Morton <akpm <at> linux-foundation.org>
Cc: Vyacheslav Dubeyko <slava <at> dubeyko.com>
Cc: Hin-Tak Leung <htl10 <at> users.sourceforge.net>
Cc: Anton Altaparmakov <aia21 <at> cam.ac.uk>
Cc: Al Viro <viro <at> zeniv.linux.org.uk>
Cc: Christoph Hellwig <hch <at> infradead.org>
Cc: Sougata Santra <sougata <at> tuxera.com>
Signed-off-by: Sergei Antonov <saproj <at> gmail.com>
---
 fs/hfsplus/inode.c | 6 ++++++
 1 file changed, 6 insertions(+)

(Continue reading)

Wanpeng Li | 24 Mar 03:20 2015
Picon

[PATCH v3 1/2] f2fs: enable inline data by default

Enable inline_data feature by default since it brings us better
performance and space utilization and now has already stable.
Add another option noinline_data to disable it during mount.

Suggested-by: Jaegeuk Kim <jaegeuk <at> kernel.org>
Suggested-by: Chao Yu <chao2.yu <at> samsung.com>
Signed-off-by: Wanpeng Li <wanpeng.li <at> linux.intel.com>
---
v2 -> v3:
 * reuse F2FS_MOUNT_INLINE_DATA
 * fix show both options "inline_data,noinline_data" in ->show_options
v1 -> v2:
 * retain inline_data option and enable it by default
 * add another noinline_data option

 Documentation/filesystems/f2fs.txt | 2 ++
 fs/f2fs/super.c                    | 8 ++++++++
 2 files changed, 10 insertions(+)

diff --git a/Documentation/filesystems/f2fs.txt b/Documentation/filesystems/f2fs.txt
index 48e2123..e9e750e 100644
--- a/Documentation/filesystems/f2fs.txt
+++ b/Documentation/filesystems/f2fs.txt
 <at>  <at>  -144,6 +144,8  <at>  <at>  extent_cache           Enable an extent cache based on rb-tree, it can cache
                        as many as extent which map between contiguous logical
                        address and physical address per inode, resulting in
                        increasing the cache hit ratio.
+noinline_data          Disable the inline data feature, inline data feature is
+                       enabled by default.

(Continue reading)

Sanidhya Kashyap | 23 Mar 23:32 2015
Picon

missing MS_RDONLY check in fsync

Hello everyone,

We've been cross checking various file systems for the general
inconsistencies and we have a question about the check of MS_RDONLY
during fsync.

We know that the vfs layer does not check for MS_RDONLY for fsync and
this is confirmed by the ubifs where they have explicitly mentioned
about this (commit - 3b2f9a019e655f3407e4e69cdbaf8b75699b79a4 )

"""
    if (c->ro_mount)
        /*
         * For some really strange reasons VFS does not filter out
         * 'fsync()' for R/O mounted file-systems as per 2.6.39.
         */
"""

And there is a comment in include/linux/fs.h file (line: 1688)  about
the MS_RDONLY flag: (commit - bbc1096ad8e9875a025bbcf012605da49129e8b8
):

""""
* Exception: MS_RDONLY is always applied to the entire file system.
*
* Unfortunately, it is possible to change a filesystems flags with it mounted
* with files in use. This means that all of the inodes will not have their
* i_flags updated. Hence, i_flags no longer inherit the superblock mount
* flags, so these have to be checked separately. -- rmk <at> arm.uk.linux.org */

(Continue reading)

Viacheslav Dubeyko | 23 Mar 19:16 2015

Re: [PATCH] hfsplus: fix expand when not enough available space

On Mon, 2015-03-23 at 18:00 +0000, Hin-Tak Leung wrote:
> ------------------------------
> >
> >To be honest, I am not fully understand what is the case of the fix. As
> >a result, I can understand correctness of the fix. Could you describe
> >the issue and the fix in more details? Could you provide more clear
> >description of the use-case of such issue? Anyway, this fix requires in
> >more clear and detailed description.
> 
> Acked-by: Hin-Tak Leung <htl10 <at> users.sourceforge.net>
> 
> I think I understand the description, though I have not checked
> the code itself in detail (and the fat driver origin). The use
> of 'truncate' to illustrate the problem is a bit unfortunate,
> as the issue is not about making a file smaller, but larger,
> e.g. seek'ing beyond the end of a file
> to expand it. It should fail if one seeks too far
> and try to create a very large file, but it currently does
> not fail (or so it says), but results in an inconsistent file system.
> 
> Hope this helps.
> 

Description of the fix needs in correction because current description
doesn't provide enough details for clear understanding of the issue and
the fix. Currently, it's hard to realize the fix, from my point of view.

Thanks,
Vyacheslav Dubeyko.

(Continue reading)

Changwoo Min | 23 Mar 16:33 2015
Picon

[PATCH] hfsplus: hfsplus_file_fsync() does not check for return value of sync_inode_metadata()

hfsplus_file_fsync() siliently ignores the return value of sync_inode_metadata(). 
If an error occurs at sync_inode_metadata() and subsequent updates of other file
system metadata (b-trees) succeed, file system metadata will be inconsistent. 

Signed-off-by: Changwoo Min <changwoo.m <at> gmail.com>
---
 fs/hfsplus/inode.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/fs/hfsplus/inode.c b/fs/hfsplus/inode.c
index 0cf786f..9444719 100644
--- a/fs/hfsplus/inode.c
+++ b/fs/hfsplus/inode.c
 <at>  <at>  -286,7 +286,11  <at>  <at>  int hfsplus_file_fsync(struct file *file, loff_t start, loff_t end,
 	/*
 	 * Sync inode metadata into the catalog and extent trees.
 	 */
-	sync_inode_metadata(inode, 1);
+	error = sync_inode_metadata(inode, 1);
+	if (error) {
+		mutex_unlock(&inode->i_mutex);
+		return error;
+	}

 	/*
 	 * And explicitly write out the btrees.
--

-- 
1.9.1

--
(Continue reading)

Boaz Harrosh | 23 Mar 13:47 2015

[PATCH 0/3 v3] dax: Fix mmap-write not updating c/mtime

Hi

[v3]
* I'm re-posting the two DAX patches that fix the mmap-write after read
  problem with DAX. (No changes since [v2])
* I'm also posting a 3rd RFC patch to address what Jan said about fs_freeze
  and making mapping read-only. 
  Jan Please review and see if this is what you meant.

[v2]
Jan Kara has pointed out that if we add the
sb_start/end_pagefault pair in the new pfn_mkwrite we
are then fixing another bug where: A user could start
writing to the page while filesystem is frozen.

[v1]
The main problem is that current mm/memory.c will no call us with page_mkwrite
if we do not have an actual page mapping, which is what DAX uses.
The solution presented here introduces a new pfn_mkwrite to solve this problem.
Please see patch-2 for details.

I've been running with this patch for 4 month both HW and VMs with no apparent
danger, but see patch-1 I played it safe.

I am also posting an xfstest 080 that demonstrate this problem, I believe
that also some git operations (can't remember which) suffer from this problem.
Actually Eryu Guan found that this test fails on some other FS as well.

List of patches:
  [PATCH 1/3] mm: New pfn_mkwrite same as page_mkwrite for VM_PFNMAP
(Continue reading)


Gmane