Al Viro | 18 Apr 04:38 2014
Picon

Re: panic in do_last()

On Thu, Apr 17, 2014 at 07:16:30PM -0700, Lin Ming wrote:
> (gdb) list *do_last+0x7d2
> 0xffffffff811095a5 is in do_last (/home/mlin/linux/fs/namei.c:3036).
> 3031 if ((open_flag & O_CREAT) && d_is_dir(nd->path.dentry))
> 3032            goto out;
> 3033 error = -ENOTDIR;
> 3034 if ((nd->flags & LOOKUP_DIRECTORY) && !d_can_lookup(nd->path.dentry))
> 3035            goto out;
> 3036 if (!S_ISREG(nd->inode->i_mode))
> 3037            will_truncate = false;

Aha, so my guess in another posting was correct.  OK...

So it's not about RCU case at all - if dentry changes under us
in lazy mode, we'll simply fail when we get to checking d_seq.  It's
non-lazy case + transition from negative to positive that causes the
trouble.

Another piece of breakage in there is should_follow_link() directly
afterwards - there the problem is with false negatives.  I.e. we
see new dentry->d_inode, but not the new dentry->d_flags.

I wonder if the right fix would be simply
	if (!inode || d_is_negative(dentry))
bailing out unless both updates are seen.  Probably cheaper than any
games with barriers...

Comments?
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
(Continue reading)

Lin Ming | 18 Apr 03:14 2014
Picon

panic in do_last()

Hi Dave,

I tried to reproduce bug "BUG at mm/filemap.c:202!"
https://lkml.org/lkml/2014/4/15/577 with the attached programs.
I can't reproduce it, but it triggered another bug related to commit  b18825a7c.

commit b18825a7c8e37a7cf6abb97a12a6ad71af160de7
Author: David Howells <dhowells <at> redhat.com>
Date:   Thu Sep 12 19:22:53 2013 +0100

    VFS: Put a small type field into struct dentry::d_flags

[  216.673863] BUG: unable to handle kernel NULL pointer dereference
at           (null)
[  216.674235] IP: [<ffffffff81108961>] do_last.isra.44+0x7d2/0x9ea
[  216.674487] PGD 3d3f0067 PUD 3c82a067 PMD 0
[  216.674853] Oops: 0000 [#1] SMP
[  216.675126] Modules linked in:
[  216.675324] CPU: 1 PID: 30121 Comm: test Not tainted 3.15.0-rc1 #14
[  216.675501] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS Bochs 01/01/2011
[  216.675709] task: ffff88003d1788c0 ti: ffff88003ca84000 task.ti:
ffff88003ca84000
[  216.675906] RIP: 0010:[<ffffffff81108961>]  [<ffffffff81108961>]
do_last.isra.44+0x7d2/0x9ea
[  216.676195] RSP: 0018:ffff88003ca85cf8  EFLAGS: 00010246
[  216.676356] RAX: 0000000000000000 RBX: ffff88003ca85e40 RCX: 0000000000000020
[  216.676547] RDX: 000060ffc00002c0 RSI: 0000000000000101 RDI: ffff88003ca85e40
[  216.676737] RBP: ffff88003ca85d98 R08: ffff88003ca062d0 R09: ffff88003ca062d0
[  216.676933] R10: 2f2f2f2f2f2f2f2f R11: ffffffff81108817 R12: ffff88003ca85dd8
(Continue reading)

Hin-Tak Leung | 17 Apr 21:30 2014
Picon

[PATCH 0/3] hfsplus: fix series for non-english names and attributes

From: Hin-Tak Leung <htl10 <at> users.sourceforge.net>

This is a series of 3 patches which corrects issues in HFS+
concerning the use of non-english file names and attributes.
Names and attributes are stored internally as UTF-16 units up to a
fixed maximum size, and convert to and from user-representation by NLS.
The code incorrectly assume that NLS string lengths are equal
to unicode lengths, which is only true for English ascii usage.

This is largely a repost (with some editing/formatting to the messages) of the
earlier 4-patch series, as the original 4th patch
"hfsplus: fixes error propagation of hfsplus_asc2uni" is no longer needed.
The 4th patch is functionally identical to "hfsplus: fix longname handling"
from Sougata Santra posted a few weeks ago.

Patch 1 differs from the single patch sent to Andrew Morton by one
kzalloc to kmalloc change, as the kzalloc is not needed on examination.

The others only differ from the previous series of 4 posted to fs-devel
by editing/formatting and additions of CC's of the commit messages
- there is no code change.

Hin-Tak Leung (3):
  hfsplus: fixes worst-case unicode to char conversion of file names and
    attributes
  hfsplus: correct usage of HFSPLUS_ATTR_MAX_STRLEN for non-English
    attributes
  hfsplus: remove unused routine hfsplus_attr_build_key_uni

 fs/hfsplus/attributes.c     | 36 ++++----------------------------
(Continue reading)

Lukas Czerner | 17 Apr 15:30 2014
Picon

[PATCH] fallocate.2: Document FALLOC_FL_ZERO_RANGE

FALLOC_FL_ZERO_RANGE was added in Linux 3.14,
for zeroing ranges in the allocated space in a file.

Signed-off-by: Lukas Czerner <lczerner <at> redhat.com>
---
 man2/fallocate.2 | 41 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 41 insertions(+)

diff --git a/man2/fallocate.2 b/man2/fallocate.2
index b31bbde..df31782 100644
--- a/man2/fallocate.2
+++ b/man2/fallocate.2
 <at>  <at>  -124,6 +124,45  <at>  <at>  Btrfs (since Linux 3.7)
 .IP *
 tmpfs (since Linux 3.5)
 .\" commit 83e4fa9c16e4af7122e31be3eca5d57881d236fe
+.SS Zeroing file space
+Specifying
+.BR FALLOC_FL_ZERO_RANGE
+flag (available since Linux 3.14) in
+.I mode
+zeroes space in the byte range starting at
+.I offset
+and continuing for
+.I len
+bytes.
+Within the specified range, blocks are preallocated for the regions
+that span the holes in the file. After a successful call,
+subsequent reads from this range will return zeroes.
+
(Continue reading)

Namjae Jeon | 17 Apr 00:35 2014

[PATCH] xfstests: fsstress: remove duplicate COLLAPSE_RANGE flags

From: Namjae Jeon <namjae.jeon <at> samsung.com>

Remove duplicate COLLAPSE_RANGE flags

Signed-off-by: Namjae Jeon <namjae.jeon <at> samsung.com>
Signed-off-by: Ashish Sangwan <a.sangwan <at> samsung.com>
---
 ltp/fsstress.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/ltp/fsstress.c b/ltp/fsstress.c
index 1eec11a..29fc250 100644
--- a/ltp/fsstress.c
+++ b/ltp/fsstress.c
 <at>  <at>  -2176,7 +2176,6  <at>  <at>  struct print_flags falloc_flags [] = {
 	{ FALLOC_FL_NO_HIDE_STALE, "NO_HIDE_STALE"},
 	{ FALLOC_FL_COLLAPSE_RANGE, "COLLAPSE_RANGE"},
 	{ FALLOC_FL_ZERO_RANGE, "ZERO_RANGE"},
-	{ FALLOC_FL_COLLAPSE_RANGE, "COLLAPSE_RANGE"},
 	{ -1, NULL}
 };

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

Phillip Susi | 16 Apr 04:01 2014

Tracking actual disk write sources instead of flush thread


A lot of disk writes, especially when they are small individual files
being written by several different processes, are hidden behind the
flush thread.  Is there no way to properly track the process actually
responsible for the IO, even when it is the flush thread that
initiates the writeout?

isabelle | 15 Apr 21:47 2014
Picon

spende /Donation

Hallo
Wenn ich diese Nachricht zu senden wollte, ist dies nicht einfach Zufall. Dies ist, weil Ihre e-Mail vom
elektronischen Roboter gesichert meine WX.7AR BW ausgewählt wurde.
Zunächst möchte ich mich für dieses Eindringen in Ihr Leben zu entschuldigen, obwohl ich zugeben, dass
es mir sehr wichtig. Ich bin Isabelle Vasudev. Ich leide an Krebs im Hals seit nun mehr als 3 Jahre und eine
halbe und es leider, mein Arzt hat gerade informiert mich, dass ich bin voller unheilbar und, dass meine
Tage, wegen meinen etwas gezählt sind abgebaut Zustand. Ich bin eine Witwe und ich habe keine Kind, das
ich beginne zu bedauern.
In der Tat ist der Grund, warum ich Sie kontaktieren bin, möchte ich einen Teil von meinem Grundstück zu
spenden, weil ich niemand, wer die Erben konnte. Ich habe fast mein ganzes Zeug, darunter ein Unternehmen
der Export von Holz, Gummi und Stahl-Industrie in Afrika, wo ich wohne nun mehr 10 Jahren, verkauft. Ein
großer Teil der Gelder gesammelt wurde mit unterschiedlichen Verbänden humanitären Charakter
überall in der Welt, aber besonders hier in Afrika bezahlt.
Im Hinblick auf den Rest der Summe genau in Höhe von 750.000, 00euros (sieben hundert und fünfzig tausend
Euro) auf eine gesperrte Mitarbeiter-Account, meine letzte wünschen würde Sie es spenden, so dass Sie
in Ihrer Branche und vor allem den humanitären investieren können. Ich bin ganz bewusst was ich zu tun
beabsichtigen, und ich denke, trotz der Tatsache, die wir nicht wissen, werdet ihr diese Summe gut
nutzen. Ich bitte Sie, bitte dieses Erbe zu akzeptieren, ohne jedoch Fragen Sie alles, was in
zurückgeben wenn es nicht immer denken, gutes zu tun, um dich herum, was ich nicht getan habe, in meiner Existenz.
Das heißt, wird auf einer verantwortlichen Person und besonders gutem Glauben fallen zu lassen
beruhigt, ich möchte bitten, dass Sie bitte mich bei den meisten schnell kontaktieren, um weitere
Erklärung über die Gründe für meine Geste und den Verlauf der Dinge zu geben. Bitte kontaktieren Sie
mich so bald wie möglich, wenn Sie mein Angebot akzeptieren.
Gott möge mit dir sein!
Ich fordere Sie auf, mich über meine persönliche e-Mail-Adresse zu kontaktieren:
Isabelle.claude654 <at> laposte.net
Der Frieden und Barmherzigkeit Gottes möge mit dir sein.
Mrs Isabelle

--
(Continue reading)

Amit Sahrawat | 15 Apr 09:54 2014
Picon

Ext4: deadlock occurs when running fsstress and ENOSPC errors are seen.

Initially in normal write path, when the disk was almost full – we got
hung for the ‘sync’ because the flusher (which is busy in the
writepages is not responding). Before the hung task, we also found the
logs like:

EXT4-fs error (device sda1): ext4_mb_generate_buddy:742: group 1493, 0
clusters in bitmap, 58339 in gd
EXT4-fs error (device sda1): ext4_mb_generate_buddy:742: group 1000, 0
clusters in bitmap, 3 in gd
EXT4-fs error (device sda1): ext4_mb_generate_buddy:742: group 1425, 0
clusters in bitmap, 1 in gd
JBD2: Spotted dirty metadata buffer (dev = sda1, blocknr = 0). There's
a risk of filesystem corruption in case of system crash.
JBD2: Spotted dirty metadata buffer (dev = sda1, blocknr = 0). There's
a risk of filesystem corruption in case of system crash.

EXT4-fs (sda1): error count: 58
EXT4-fs (sda1): initial error at 607: ext4_mb_generate_buddy:742
EXT4-fs (sda1): last error at 58: ext4_mb_generate_buddy:742

When we analysed the problem, it occurred from the writepages path in ext4.
This is because of the difference in the free blocks reported by
cluster bitmap and the number of free blocks reported by group
descriptor.
During ext4_fill_super, ext4 calculates the number of free blocks by
reading all the descriptors in function ext4_count_free_clusters and
store it in percpu counter s_freeclusters_counter.
ext4_count_free_clusters:
desc_count = 0;
for (i = 0; i < ngroups; i++) {
(Continue reading)

Hin-Tak Leung | 15 Apr 06:20 2014
Picon

[PATCH 1/4] hfsplus: fixes worst-case unicode to char conversion of file names and attributes

From: Hin-Tak Leung <htl10 <at> users.sourceforge.net>

The HFS Plus Volume Format specification (TN1150) states that
file names are stored internally as a maximum of 255 unicode
characters, as defined by The Unicode Standard, Version 2.0
[Unicode, Inc. ISBN 0-201-48345-9]. File names are converted by
the NLS system on Linux before presented to the user.

255 CJK characters converts to UTF-8 with 1 unicode character
to up to 3 bytes, and to GB18030 with 1 unicode character to
up to 4 bytes. Thus, trying in a UTF-8 locale to list files
with names of more than 85 CJK characters results in:

    $ ls /mnt
    ls: reading directory /mnt: File name too long

The receiving buffer to hfsplus_uni2asc() needs to be 255 x
NLS_MAX_CHARSET_SIZE bytes, not 255 bytes as the code has always been.

Similar consideration applies to attributes, which are stored
internally as a maximum of 127 UTF-16BE units. See XNU source for
an up-to-date reference on attributes.

Strictly speaking, the maximum value of NLS_MAX_CHARSET_SIZE = 6
is not attainable in the case of conversion to UTF-8, as going
beyond 3 bytes requires the use of surrogate pairs, i.e. consuming
two input units.

Thanks Anton Altaparmakov for reviewing an earlier version of
this change.
(Continue reading)

Pedro Fonseca | 14 Apr 20:24 2014

Data races in generic_fillattr()

Hi,

I've noticed that the function generic_fillattr() (fs/stat.c) in 
involved in multiple data races. Initially I reported this problem on 
the ext4 mailing list but it seems to be more general to the VFS layer.

Because of limited locking, when the inodes are updated and a stat() 
system call is concurrently executed, several 64-bit fields (e.g., 
atime, mtime, ctime, blocks) can potentially get incorrect values on 
32-bit architectures. In addition, it seems that it can also cause 
inconsistencies between the "blocks" field and the "size" field.

I would be glad if you could have a look at this problem and let me know 
if it's going to be fixed.

Thanks,
Pedro
--
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

Stef Bon | 14 Apr 14:05 2014
Picon

[fuse-devel][PATCH v2 03/4] Enable fsnotify: add opcode and fsnotify struct fuse.h.

Add the FUSE_FSNOTIFY opcode and fsnotify struct to the fuse include file.

Signed-off-by: Stef Bon <stefbon <at> gmail.com>
diff --git a/include/uapi/linux/fuse.h.orig b/include/uapi/linux/fuse.h
index 60bb2f9..c370ac4 100644
--- a/include/uapi/linux/fuse.h.orig
+++ b/include/uapi/linux/fuse.h
 <at>  <at>  -343,6 +343,8  <at>  <at>  enum fuse_opcode {
        FUSE_BATCH_FORGET  = 42,
        FUSE_FALLOCATE     = 43,
        FUSE_READDIRPLUS   = 44,
+       FUSE_FSNOTIFY      = 45,
+

        /* CUSE specific operations */
        CUSE_INIT          = 4096,
 <at>  <at>  -685,6 +687,10  <at>  <at>  struct fuse_direntplus {
 #define FUSE_DIRENTPLUS_SIZE(d) \
        FUSE_DIRENT_ALIGN(FUSE_NAME_OFFSET_DIRENTPLUS + (d)->dirent.namelen)

+struct fuse_fsnotify_in {
+       uint64_t        mask;
+};
+
 struct fuse_notify_inval_inode_out {
        uint64_t        ino;
        int64_t         off;
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)


Gmane