LARRY | 1 Sep 19:15 2014

RE


 I won 108million pounds in Euromillion lottery March this year and i have
decided to give out 1.5million pounds globally to 5 recipients as the Google
Management sent us your email yesterday as our second recipient.Kindly Reply
Name,Country,Occupation and Phone for further instructions, see news headline
http://www.bbc.com/news/uk-england-london-26627075

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

LARRY | 1 Sep 19:15 2014

RE


 I won 108million pounds in Euromillion lottery March this year and i have
decided to give out 1.5million pounds globally to 5 recipients as the Google
Management sent us your email yesterday as our second recipient.Kindly Reply
Name,Country,Occupation and Phone for further instructions, see news headline
http://www.bbc.com/news/uk-england-london-26627075

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

LARRY | 1 Sep 19:14 2014

RE


 I won 108million pounds in Euromillion lottery March this year and i have
decided to give out 1.5million pounds globally to 5 recipients as the Google
Management sent us your email yesterday as our second recipient.Kindly Reply
Name,Country,Occupation and Phone for further instructions, see news headline
http://www.bbc.com/news/uk-england-london-26627075

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

LARRY | 1 Sep 12:03 2014

RE


 I won 108million pounds in Euromillion lottery March this year and i have
decided to give out 1.5million pounds globally to 5 recipients as the Google
Management sent us your email yesterday as our second recipient.Kindly Reply
Name,Country,Occupation and Phone for further instructions, see news headline
http://www.bbc.com/news/uk-england-london-26627075

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

Jeff Layton | 31 Aug 02:12 2014
Picon

[GIT PULL] please pull file locking changes for v3.17 (pile #3)

The following changes since commit 5317821c08533e5f42f974e4e68e092beaf099b1:

  Merge branch 'for-3.17-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata
(2014-08-21 14:26:27 -0700)

are available in the git repository at:

  git://git.samba.org/jlayton/linux.git tags/locks-v3.17-3

for you to fetch changes up to e0b760ff71be168d4e623f7c3612e98902ab93e9:

  locks: pass correct "before" pointer to locks_unlink_lock in generic_add_lease (2014-08-22 09:58:22 -0400)

----------------------------------------------------------------

Just a bugfix for a bug that crept in to v3.15. It's in a rather rare
error path, and I'm not aware of anyone having hit it, but it's worth
fixing for v3.17.

----------------------------------------------------------------
Jeff Layton (1):
      locks: pass correct "before" pointer to locks_unlink_lock in generic_add_lease

 fs/locks.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--

-- 
Jeff Layton <jlayton <at> poochiereds.net>
Maxim Patlasov | 29 Aug 12:41 2014

Re: [PATCH v1 5/9] block: loop: convert to blk-mq

On 8/28/14, Zach Brown<zab <at> zabbo.net>  wrote:

> On Wed, Aug 27, 2014 at 09:19:36PM +0400, Maxim Patlasov wrote:
>> On 08/27/2014 08:29 PM, Benjamin LaHaise wrote:
>>> On Wed, Aug 27, 2014 at 08:08:59PM +0400, Maxim Patlasov wrote:
>>> ...
>>>> 1) /dev/loop0 of 3.17.0-rc1 with Ming's patches applied -- 11K iops
>>>> 2) the same as above, but call loop_queue_work() directly from
>>>> loop_queue_rq() -- 270K iops
>>>> 3) /dev/nullb0 of 3.17.0-rc1 -- 380K iops
>>>>
>>>> Taking into account so big difference (11K vs. 270K), would it be
>>>> worthy
>>>> to implement pure non-blocking version of aio_kernel_submit() returning
>>>> error if blocking needed? Then loop driver (or any other in-kernel
>>>> user)
>>>> might firstly try that non-blocking submit as fast-path, and, only if
>>>> it's failed, fall back to queueing.
>>> What filesystem is the backing file for loop0 on?  O_DIRECT access as
>>> Ming's patches use should be non-blocking, and if not, that's something
>>> to fix.
>> I used loop0 directly on top of null_blk driver (because my goal was to
>> measure the overhead of processing requests in a separate thread).
> The relative overhead while doing nothing else.  While zooming way down
> in to micro benchmarks is fun and all, testing on an fs on brd might be
> more representitive and so more compelling.

The measurements on an fs on brd are even more outrageous (the same fio 
script I posted a few messages above):

(Continue reading)

Francis Moreau | 28 Aug 16:22 2014
Picon

Can't rmdir an empty directory when using overlayfs

Hello,

I've a weird problem when using overlayfs.

The version I'm using is quite old, it's v12 on top of a 3.4 kernel. I
guess the patches are coming from:

http://git.kernel.org/cgit/linux/kernel/git/apw/overlayfs.git/log/?h=overlayfs.v12apw1

Sorry if the version is old but I'm stick with 3.4 and v12 seems the
latest version available for this kernel.

My problem is that I can't rmdir an empty directory, it fails with
'device or resource busy'.

This directory is created by an application and is used to mount a block
device. Once the job is finished the block device is unmounted and
finally app tries to rmdir it.

The directory doesn't seem to be a mountpoint (anymore). Looking in
/proc/mounts confirm this.

I tried to trace what's going on in the kernel when calling the syscall
'rmdir' and found that it's currently failing in vfs_rmdir() when
testing for that particular condition:

 error = -EBUSY;
 if (d_mountpoint(dentry))
         goto out;

(Continue reading)

Xue jiufei | 28 Aug 13:40 2014

A deadlock when direct memory reclaim in network filesystem

Hi all,
We found there may exist a deadlock during direct memory reclaim in
network filesystem.
Here's one example in ocfs2, maybe other network filesystems has
this problems too.

1)Receiving a connect message from other nodes, Node queued
o2net_listen_work.
2)o2net_wq processed this work and try to allocate memory for a
new socket.
3)Syetem has no more memory, it would do direct memory reclaim
and trigger the inode cleanup. That inode being cleaned up is
happened to be ocfs2 inode, so call evict()->ocfs2_evict_inode()
->ocfs2_drop_lock()->dlmunlock()->o2net_send_message_vec(),
and wait for the response.
4)tcp layer received the response, call o2net_data_ready() and
queue sc_rx_work, waiting o2net_wq to process this work.
5)o2net_wq is a single thread workqueue, it process the work one by
one. Right now is is still doing o2net_listen_work and cannot handle
sc_rx_work. so we deadlock.

To avoid deadlock like this, caller should perform a GFP_NOFS
allocation attempt(see the comments of shrink_dcache_memory and
shrink_icache_memory).
However, in the situation I described above, it is impossible to
add GFP_NOFS flag unless we modify the socket create interface.

To fix this deadlock, we would not like to shrink inode and dentry
slab during direct memory reclaim. Kswapd would do this job for us.
So we want to force add __GFP_FS when call
(Continue reading)

rtg.canonical | 27 Aug 21:51 2014
Picon

[PATCH 3.17-rc2] fs: namespace: suppress 'may be used uninitialized' warnings

From: Tim Gardner <tim.gardner <at> canonical.com>

The gcc version 4.9.1 compiler complains Even though it isn't possible for
these variables to not get initialized before they are used.

fs/namespace.c: In function ‘SyS_mount’:
fs/namespace.c:2720:8: warning: ‘kernel_dev’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  ret = do_mount(kernel_dev, kernel_dir->name, kernel_type, flags,
        ^
fs/namespace.c:2699:8: note: ‘kernel_dev’ was declared here
  char *kernel_dev;
        ^
fs/namespace.c:2720:8: warning: ‘kernel_type’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  ret = do_mount(kernel_dev, kernel_dir->name, kernel_type, flags,
        ^
fs/namespace.c:2697:8: note: ‘kernel_type’ was declared here
  char *kernel_type;
        ^
Cc: Alexander Viro <viro <at> zeniv.linux.org.uk>
Signed-off-by: Tim Gardner <tim.gardner <at> canonical.com>
---
 fs/namespace.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/namespace.c b/fs/namespace.c
index 20232e4..8681260 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
 <at>  <at>  -2694,9 +2694,9  <at>  <at>  SYSCALL_DEFINE5(mount, char __user *, dev_name, char __user *, dir_name,
 		char __user *, type, unsigned long, flags, void __user *, data)
(Continue reading)

Boaz Harrosh | 27 Aug 17:22 2014

[PATCHSET 0/5 v2] brd: partition fixes

Jens Hi

What do you intend to do with these fixes? These are real bugs on devices
shipped for a while now. I think they need to go into current 3.17-rcX Kernel.

If not then lets please put them in for-next
[This set is for linux-block.git/for-next, tell me if you need one ontop
 of for-linus]

[v2]
Based on Jens's linux-next [30e996a] incorporating the brd patch by Dmitry Monakhov.
Dmitry has introduced a new part_show parameter, this parameter is now removed
and we always "part_show=1".
Scripts that did part_show=1 will work just the same but will display a
message in logs. This is harmless. (And scripts can be modified to
remove this parameter)

[v1]
Current situation is that any attempt to use partitions with brd device would
create the partition but then any use will trash the data.

See: http://www.spinics.net/lists/linux-scsi/msg76737.html

So these patches fixes up all the problems we saw with the code, but not sacrificing
any of the old fixtures. See [patch 4/5] for more explanations.

list of patches:
[PATCH 1/5] axonram: Fix bug in direct_access
[PATCH 2/5] Change direct_access calling convention

(Continue reading)

Anton Altaparmakov | 26 Aug 15:22 2014
Picon
Picon

Bug in __generic_file_write_iter()?

Hi Al,

I have been looking at __generic_file_write_iter() and think I may have found a bug when O_DIRECT is
enabled and the write falls through to generic_perform_write() after the
generic_file_direct_write() and then the filemap_write_and_wait_range() fails for some reason.

The relevant code is:

	status = generic_perform_write(file, from, pos);
	[...]
	iocb->ki_pos = pos + status;
	[...]
	err = filemap_write_and_wait_range(file->f_mapping, pos, endbyte);
	if (err == 0) {
		written += status;

Now consider the case where filemap_write_and_wait_range() returned an error.

In that case we return with iocb->ki_pos already advanced to "pos + status" when in fact (some of) the write
to disk actually failed.

We then end up returning "written" which does not include "status" in its value but we set file->f_pos to
iocb->ki_pos in the write() system call (via file_pos_write(f.file, pos); where "pos" was set to iocb->ki_pos).

Now imagine a userspace application doing a simple write loop:

	do {
		written = write(f, buf, bytes);
		buf += written;
		[...]
(Continue reading)


Gmane