headers
Alex Kelly | 1 Aug 2012 04:23
Picon
Gravatar

[PATCH 1/2] Moved core dump functionality into its own file

This was done in preparation for making core dump functionality optional.

The variable "suid_dumpable" and associated functions are left in fs/exec.c
because they're used elsewhere, such as in ptrace.

Signed-off-by: Alex Kelly <alex.page.kelly <at> gmail.com>
Reviewed-by: Josh Triplett <josh <at> joshtriplett.org>
---
 fs/Makefile           |   2 +-
 fs/coredump.c         | 684 ++++++++++++++++++++++++++++++++++++++++++++++++++
 fs/exec.c             | 642 +---------------------------------------------
 include/linux/sched.h |   1 +
 4 files changed, 687 insertions(+), 642 deletions(-)
 create mode 100644 fs/coredump.c

diff --git a/fs/Makefile b/fs/Makefile
index 2fb9779..8938f82 100644
--- a/fs/Makefile
+++ b/fs/Makefile
 <at>  <at>  -11,7 +11,7  <at>  <at>  obj-y :=	open.o read_write.o file_table.o super.o \
 		attr.o bad_inode.o file.o filesystems.o namespace.o \
 		seq_file.o xattr.o libfs.o fs-writeback.o \
 		pnode.o drop_caches.o splice.o sync.o utimes.o \
-		stack.o fs_struct.o statfs.o
+		stack.o fs_struct.o statfs.o coredump.o

 ifeq ($(CONFIG_BLOCK),y)
 obj-y +=	buffer.o bio.o block_dev.o direct-io.o mpage.o ioprio.o
diff --git a/fs/coredump.c b/fs/coredump.c
new file mode 100644
(Continue reading)

Permalink | Reply | 2 comments |
headers
Paul E. McKenney | 1 Aug 2012 19:15
Picon

Re: [dm-devel] [PATCH 2/3] Introduce percpu rw semaphores

On Mon, Jul 30, 2012 at 08:00:19PM -0400, Mikulas Patocka wrote:
> 
> 
> On Mon, 30 Jul 2012, Paul E. McKenney wrote:
> 
> > On Sun, Jul 29, 2012 at 01:13:34AM -0400, Mikulas Patocka wrote:
> > > On Sat, 28 Jul 2012, Eric Dumazet wrote:
> > > > On Sat, 2012-07-28 at 12:41 -0400, Mikulas Patocka wrote:
> > 
> > [ . . . ]
> > 
> > > > (bdev->bd_block_size should be read exactly once )
> > > 
> > > Rewrite all direct and non-direct io code so that it reads block size just 
> > > once ...
> > 
> > For whatever it is worth, the 3.5 Linux kernel only has about ten mentions
> > of bd_block_size, at least according to cscope.
> 
> plus 213 uses of i_blkbits (which is derived directly from bd_block_size). 
> 45 of them is in fs/*.c and mm/*.c

At least it is only hundreds rather than thousands!  ;-)

							Thanx, Paul

--
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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tino Reichardt | 1 Aug 2012 22:08
Picon

Re: [Jfs-discussion] [PATCH] fs/jfs: TRIM support for JFS Filesystem

* Tino Reichardt <list-linux-fsdevel <at> mcmilk.de> wrote:
> * Dave Kleikamp <dave.kleikamp <at> oracle.com> wrote:
> > On 07/28/2012 06:08 AM, Tino Reichardt wrote:
> > > * Tino Reichardt <list-linux-fsdevel <at> mcmilk.de> wrote:
> > >> > This patch adds support for the two linux interfaces of the discard/TRIM
> > >> > command for SSD devices and sparse/thinly-provisioned LUNs.
> > > Fixed a problem when setting minlen in jfs_ioc_trim().

Oops, setting minlen in jfs_ioc_trim() was again wrong :/

I changed this
if (minlen < 0)
	minlen = 1;

to this:
if (minlen <= 0)
	minlen = 1;

This is important, since fstrim() sets it to zero.

Fully working patch is located here:
http://www.mcmilk.de/projects/jfs-trim/linux-tree/jfs-trim-2012-08-01_v2.diff

Signed-off-by: Tino Reichardt <list-jfs <at> mcmilk.de>

--

-- 
regards, TR
--
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)

Permalink | Reply | 1 comment |
headers
Mikulas Patocka | 1 Aug 2012 22:09
Picon
Favicon

[PATCH 4/3] Introduce percpu rw semaphores


On Sun, 29 Jul 2012, Eric Dumazet wrote:

> On Sun, 2012-07-29 at 12:10 +0200, Eric Dumazet wrote:
> 
> > You can probably design something needing no more than 4 bytes per cpu,
> > and this thing could use non locked operations as bonus.
> > 
> > like the following ...
> 
> Coming back from my bike ride, here is a more polished version with
> proper synchronization/ barriers.

Hi Eric

I reworked your patch (it should be applied after my previous patch 3/3). 
I replaced the rw-semaphore with a mutex. Instead of two pointers, I 
changed it to one pointer and one bool variable.

I removed the barriers next to rcu (because, rcu works as a barrier) and 
added a barrier when decrementing the percpu variable and when waiting for 
percpu_count to be zero.

I tested performance of all implementation:
30.2s with no lock at all
32.2s with global rw-lock
30.6s with per-cpu rw-lock (my original implementation and Eric Dumazet's 
implementation make no difference)

Mikulas
(Continue reading)

Permalink | Reply | 24 comments |
headers
Cody P Schafer | 2 Aug 2012 01:16
Picon
Gravatar

Re: [BUG] NTFS code doesn't sanitize folder names sufficiently


> The solution to this would be to disallow creation of files and
> folders on NTFS drives containing illegal characters.

Illegal characters with respect to Windows & the like are different 
from Illegal characters with respect to the NTFS filesystem structure.

Looking at ntfs-3g(8) [yes, I'm aware that is a different driver that 
this bug is about], the section on Windows Filename Compatability says 
this:

       [...] all characters are
       allowed except '/' and '\0'. This is perfectly legal on Windows, 
though some application may get
       confused. The option windows_names may be used to apply Windows 
restrictions to new file names.

To recap: no data will be lost due to using '\' in filenames. Some 
operating systems just may not be capable off accessing it.

--
Cody

--
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
Permalink | Reply | 0 comments |
headers
Jens Axboe | 2 Aug 2012 09:51
Picon

Re: [PATCH 1/2 V1] [PATCH] fs/block-dev.c:fix performance regression in O_DIRECT writes to md block devices

On 08/02/2012 08:48 AM, majianpeng wrote:
> On 2012-07-17 11:04 NeilBrown <neilb <at> suse.de> Wrote:
>> On Mon, 16 Jul 2012 14:22:03 +0800 majianpeng <majianpeng <at> gmail.com> wrote:
>>
>>> For regular file, write operaion used blk_plug function.But for block
>>> file,write operation did not use blk_plug.
>>> This patch is also for write-cache mode for block-device.
>>>
>>> Signed-off-by: Jianpeng Ma <majianpeng <at> gmail.com>
>>
>> Reviewed-by: NeilBrown <neilb <at> suse.de>
>>
>> Will you take this Jens?  Though mail to you seem to be bouncing:
>>
>> <axboe <at> fusionio.com>: host mail.fusionio.com[10.101.1.19] said: 554 5.4.6 Hop
>>    count exceeded - possible mail loop (in reply to end of DATA command)
>>
>> so I'm not sure you'll even see this :-(
>>
>> NeilBrown
>>
>>> ---
>>>  fs/block_dev.c |    3 +++
>>>  1 files changed, 3 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/fs/block_dev.c b/fs/block_dev.c
>>> index c2bbe1f..cf10778 100644
>>> --- a/fs/block_dev.c
>>> +++ b/fs/block_dev.c
>>>  <at>  <at>  -1579,9 +1579,11  <at>  <at>  ssize_t blkdev_aio_write(struct kiocb *iocb, const struct iovec *iov,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joel Becker | 2 Aug 2012 09:57

Re: [RFC PATCH] ocfs2: don't depend on DCACHE_DISCONNECTED

On Tue, Jul 31, 2012 at 06:33:23PM -0400, J. Bruce Fields wrote:
> From: "J. Bruce Fields" <bfields <at> redhat.com>
> 
> XXX: I don't understand this code, but I also can't see how it can be
> right as is: a dentry marked DCACHE_DISCONNECTED can in fact be a
> fully-connected member of the dcache.  Is IS_ROOT() the right check
> instead?
> 
> Signed-off-by: J. Bruce Fields <bfields <at> redhat.com>

NAK.  DISCONNECTED is cleared when the dentry is materialized.

Here's the context.  When an ocfs2 dentry is discoverable via the tree
(lookup or splicing an alias), we hold a cluster lock (the "dentry
lock").  This is why we override d_move(), to make sure that state is
kept sane.  That way, other nodes can communicate unlink to this node.
They notify our node via the locking system, which does a
d_delete()+dput(), which sets DISCONNECTED.  When the dentry gets its
final put, we can properly accept an empty lock.

Joel

--

-- 

"The one important thing i have learned over the years is the
 difference between taking one's work seriously and taking one's self
 seriously.  The first is imperative and the second is disastrous."
	-Margot Fonteyn

			http://www.jlbec.org/
(Continue reading)

Permalink | Reply | 4 comments |
headers
J. Bruce Fields | 2 Aug 2012 14:59

Re: [RFC PATCH] ocfs2: don't depend on DCACHE_DISCONNECTED

On Thu, Aug 02, 2012 at 12:57:44AM -0700, Joel Becker wrote:
> On Tue, Jul 31, 2012 at 06:33:23PM -0400, J. Bruce Fields wrote:
> > From: "J. Bruce Fields" <bfields <at> redhat.com>
> > 
> > XXX: I don't understand this code, but I also can't see how it can be
> > right as is: a dentry marked DCACHE_DISCONNECTED can in fact be a
> > fully-connected member of the dcache.  Is IS_ROOT() the right check
> > instead?
> > 
> > Signed-off-by: J. Bruce Fields <bfields <at> redhat.com>
> 
> NAK.  DISCONNECTED is cleared when the dentry is materialized.

Are you sure?  ocfs2 uses d_splice_alias in its lookup method, which
doesn't clear DISCONNECTED.

(d_materialise_unique does something similar to d_splice_alias and also
clears DISCONNECTED.  However, I'm almost certain that's a bug in
d_materialise_unique.  The export code connects a
looked-up-by-filehandle directory by doing lookups in parents one step
at a time up to the root, only clearing DISCONNECTED once we know that
the dentry is connected all the way up to the root.  Clearing
DISCONNECTED as soon as a single dentry is connected to parents will
lead to bugs.)

> Here's the context.  When an ocfs2 dentry is discoverable via the tree
> (lookup or splicing an alias), we hold a cluster lock (the "dentry
> lock").  This is why we override d_move(), to make sure that state is
> kept sane.  That way, other nodes can communicate unlink to this node.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Eric Paris | 2 Aug 2012 20:34
Picon
Favicon

Re: Oops in audit_copy_inode

I believe this was already found and fixed:

https://lkml.org/lkml/2012/7/25/259

Which was pulled by Linus in:

3134f37e931d75931bdf6d4eacd82a3fd26eca7c

-Eric

On Wed, 2012-08-01 at 18:11 +0200, Miklos Szeredi wrote:
> Hi Peter,
> 
> Thanks for the report.
> 
> Here's a patch.  I haven't tested it but I'm pretty confident that it
> fixes the bug.
> 
> Thanks,
> Miklos
> 
> 
> Subject: vfs: fix audit_inode on negative dentry
> From: Miklos Szeredi <mszeredi <at> suse.cz>
> 
> Peter Moody reported an oops in audit_copy_inode() and bisected it to commit
> 7157486541 (vfs: do_last(): common slow lookup).
> 
> The problem is that audit_inode() in do_last() is called with a negative dentry.
>
(Continue reading)

Permalink | Reply | 1 comment |

Gmane