linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: manual merge of the vfs tree with the  tree
@ 2009-05-22  1:23 Stephen Rothwell
  2009-05-24 22:03 ` Frederic Weisbecker
  0 siblings, 1 reply; 16+ messages in thread
From: Stephen Rothwell @ 2009-05-22  1:23 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-next, linux-kernel, Christoph Hellwig, Frederic Weisbecker

Hi Al,

Today's linux-next merge of the vfs tree got a conflict in
fs/reiserfs/super.c between commit
d38705358bf6f5ab82348d0c6ee8039cea20ce6b ("reiserfs: kill-the-BKL") from
the reiserfs-bkl tree and commit 8123178eb9ca12cde31a95170746e15a79528a62
("push BKL down into ->put_super") from the vfs tree.

OK, I am not sure what is needed here, so I combined both (see below).  I
can carry this fixup as necessary.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc fs/reiserfs/super.c
index b301f7d,90dcb7b..0000000
--- a/fs/reiserfs/super.c
+++ b/fs/reiserfs/super.c
@@@ -468,13 -465,11 +465,18 @@@ static void reiserfs_put_super(struct s
  	struct reiserfs_transaction_handle th;
  	th.t_trans_id = 0;
  
+ 	lock_kernel();
+ 
 +	/*
 +	 * We didn't need to explicitly lock here before, because put_super
 +	 * is called with the bkl held.
 +	 * Now that we have our own lock, we must explicitly lock.
 +	 */
 +	reiserfs_write_lock(s);
 +
+ 	if (s->s_dirt)
+ 		reiserfs_write_super(s);
+ 
  	/* change file system state to current state if it was mounted with read-write permissions */
  	if (!(s->s_flags & MS_RDONLY)) {
  		if (!journal_begin(&th, s, 10)) {

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: linux-next: manual merge of the vfs tree with the  tree
  2009-05-22  1:23 linux-next: manual merge of the vfs tree with the tree Stephen Rothwell
@ 2009-05-24 22:03 ` Frederic Weisbecker
  2009-05-24 22:07   ` Christoph Hellwig
  2009-05-25  6:50   ` Stephen Rothwell
  0 siblings, 2 replies; 16+ messages in thread
From: Frederic Weisbecker @ 2009-05-24 22:03 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Al Viro, linux-next, linux-kernel, Christoph Hellwig

On Fri, May 22, 2009 at 11:23:26AM +1000, Stephen Rothwell wrote:
> Hi Al,
> 
> Today's linux-next merge of the vfs tree got a conflict in
> fs/reiserfs/super.c between commit
> d38705358bf6f5ab82348d0c6ee8039cea20ce6b ("reiserfs: kill-the-BKL") from
> the reiserfs-bkl tree and commit 8123178eb9ca12cde31a95170746e15a79528a62
> ("push BKL down into ->put_super") from the vfs tree.
> 
> OK, I am not sure what is needed here, so I combined both (see below).  I
> can carry this fixup as necessary.
> 
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> 
> diff --cc fs/reiserfs/super.c
> index b301f7d,90dcb7b..0000000
> --- a/fs/reiserfs/super.c
> +++ b/fs/reiserfs/super.c
> @@@ -468,13 -465,11 +465,18 @@@ static void reiserfs_put_super(struct s
>   	struct reiserfs_transaction_handle th;
>   	th.t_trans_id = 0;
>   
> + 	lock_kernel();
> + 
>  +	/*
>  +	 * We didn't need to explicitly lock here before, because put_super
>  +	 * is called with the bkl held.
>  +	 * Now that we have our own lock, we must explicitly lock.
>  +	 */
>  +	reiserfs_write_lock(s);


Hi Stephen,


I'm not sure how this conflict look like.
But yeah, you need both.

The write lock, which was the bkl before, has been placed explicitly
since the write lock is a mutex and the locking does not depend anymore
on the bkl.

I also think the bkl pushdown in reiserfs is not needed, since it now
protects itself from concurrent reiserfs_put_super() using its own lock.
But although it is not needed, it should be removed in a separate commit.

So for now, IMO you have the right fix. The end result should be:

static void reiserfs_put_super(struct super_block *s)
{
	struct reiserfs_transaction_handle th;
	th.t_trans_id = 0;

	lock_kernel();
	/*
	 * We didn't need to explicitly lock here before, because put_super
	 * is called with the bkl held.
	 * Now that we have our own lock, we must explicitly lock.
	 */
	reiserfs_write_lock(s);

	[...]

	reiserfs_write_unlock(s);
	mutex_destroy(&REISERFS_SB(s)->lock);
	kfree(s->s_fs_info);
	s->s_fs_info = NULL;

	unlock_kernel();
}




> + 	if (s->s_dirt)
> + 		reiserfs_write_super(s);



But this part seems to solve another conflict, right?
I'm not sure about it.


Frederic.


> + 
>   	/* change file system state to current state if it was mounted with read-write permissions */
>   	if (!(s->s_flags & MS_RDONLY)) {
>   		if (!journal_begin(&th, s, 10)) {

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: linux-next: manual merge of the vfs tree with the  tree
  2009-05-24 22:03 ` Frederic Weisbecker
@ 2009-05-24 22:07   ` Christoph Hellwig
  2009-05-25 17:10     ` Frederic Weisbecker
  2009-05-25  6:50   ` Stephen Rothwell
  1 sibling, 1 reply; 16+ messages in thread
From: Christoph Hellwig @ 2009-05-24 22:07 UTC (permalink / raw)
  To: Frederic Weisbecker
  Cc: Stephen Rothwell, Al Viro, linux-next, linux-kernel, Christoph Hellwig

On Mon, May 25, 2009 at 12:03:38AM +0200, Frederic Weisbecker wrote:
> > + 	if (s->s_dirt)
> > + 		reiserfs_write_super(s);
> 
> 
> 
> But this part seems to solve another conflict, right?
> I'm not sure about it.

Yes, different one.  Previously the VFS called ->write_super just before
->put_super.  Now any left over writeback needs to be dealt with by
the filesystem.  For now I have added a call to the write_super method
to all filesystems, but most likely this can be removed later after
an audit by someone who knows the filesystem.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: linux-next: manual merge of the vfs tree with the  tree
  2009-05-24 22:03 ` Frederic Weisbecker
  2009-05-24 22:07   ` Christoph Hellwig
@ 2009-05-25  6:50   ` Stephen Rothwell
  1 sibling, 0 replies; 16+ messages in thread
From: Stephen Rothwell @ 2009-05-25  6:50 UTC (permalink / raw)
  To: Frederic Weisbecker; +Cc: Al Viro, linux-next, linux-kernel, Christoph Hellwig

[-- Attachment #1: Type: text/plain, Size: 485 bytes --]

Hi Frederic,

On Mon, 25 May 2009 00:03:38 +0200 Frederic Weisbecker <fweisbec@gmail.com> wrote:
>
> So for now, IMO you have the right fix. The end result should be:

Thanks for the confirmation.

> > + 	if (s->s_dirt)
> > + 		reiserfs_write_super(s);
> 
> But this part seems to solve another conflict, right?
> I'm not sure about it.

See Christoph's reply.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: linux-next: manual merge of the vfs tree with the  tree
  2009-05-24 22:07   ` Christoph Hellwig
@ 2009-05-25 17:10     ` Frederic Weisbecker
  0 siblings, 0 replies; 16+ messages in thread
From: Frederic Weisbecker @ 2009-05-25 17:10 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: Stephen Rothwell, Al Viro, linux-next, linux-kernel

On Mon, May 25, 2009 at 12:07:47AM +0200, Christoph Hellwig wrote:
> On Mon, May 25, 2009 at 12:03:38AM +0200, Frederic Weisbecker wrote:
> > > + 	if (s->s_dirt)
> > > + 		reiserfs_write_super(s);
> > 
> > 
> > 
> > But this part seems to solve another conflict, right?
> > I'm not sure about it.
> 
> Yes, different one.  Previously the VFS called ->write_super just before
> ->put_super.  Now any left over writeback needs to be dealt with by
> the filesystem.  For now I have added a call to the write_super method
> to all filesystems, but most likely this can be removed later after
> an audit by someone who knows the filesystem.
>

Ok. Thanks for the clarification. So Stephen's fix seems to be
correct.

Thanks.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* linux-next: manual merge of the vfs tree with the  tree
@ 2015-06-05  5:46 mpe@ellerman.id.au
  0 siblings, 0 replies; 16+ messages in thread
From: mpe@ellerman.id.au @ 2015-06-05  5:46 UTC (permalink / raw)
  To: Al Viro, J. Bruce Fields; +Cc: linux-next, linux-kernel, Kinglong Mee

Hi Al,

Today's linux-next merge of the vfs tree got a conflict in fs/namei.c between
commit 890458a43dbd ("path: New helpers path_get_pin/path_put_unpin for path
pin") from the nfsd tree and commit 894bc8c4662b ("namei: remove restrictions
on nesting depth") from the vfs tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

cheers

diff --cc fs/namei.c
index d41a29efca67,2dad0eaf91d3..000000000000
--- a/fs/namei.c
+++ b/fs/namei.c
@@@ -492,32 -492,7 +492,33 @@@ void path_put(const struct path *path
  }
  EXPORT_SYMBOL(path_put);
  
 +/**
 + * path_get_pin - get a reference to a path's dentry
 + *                and pin to path's vfsmnt
 + * @path: path to get the reference to
 + * @p: the fs_pin pin to vfsmnt
 + */
 +void path_get_pin(struct path *path, struct fs_pin *p)
 +{
 +	dget(path->dentry);
 +	pin_insert_group(p, path->mnt, NULL);
 +}
 +EXPORT_SYMBOL(path_get_pin);
 +
 +/**
 + * path_put_unpin - put a reference to a path's dentry
 + *                  and remove pin to path's vfsmnt
 + * @path: path to put the reference to
 + * @p: the fs_pin removed from vfsmnt
 + */
 +void path_put_unpin(struct path *path, struct fs_pin *p)
 +{
 +	dput(path->dentry);
 +	pin_remove(p);
 +}
 +EXPORT_SYMBOL(path_put_unpin);
 +
+ #define EMBEDDED_LEVELS 2
  struct nameidata {
  	struct path	path;
  	struct qstr	last;

^ permalink raw reply	[flat|nested] 16+ messages in thread

* linux-next: manual merge of the vfs tree with the  tree
@ 2014-05-29  3:25 Stephen Rothwell
  0 siblings, 0 replies; 16+ messages in thread
From: Stephen Rothwell @ 2014-05-29  3:25 UTC (permalink / raw)
  To: Al Viro, Trond Myklebust
  Cc: linux-next, linux-kernel, Christoph Hellwig,
	Weston Andros Adamson, Anna Schumaker

[-- Attachment #1: Type: text/plain, Size: 5762 bytes --]

Hi Al,

Today's linux-next merge of the vfs tree got a conflict in
fs/nfs/direct.c between commit fab5fc25d230 ("nfs: remove
->read_pageio_init from rpc ops") and possibly others from the nfs tree
and commits 619d30b4b8c4 ("convert the guts of nfs_direct_IO() to
iov_iter"), a6cbcd4a4a85 ("get rid of pointless iov_length() in
->direct_IO()") and 91f79c43d1b5 ("new helper:
iov_iter_get_pages_alloc()") from the vfs tree.

I fixed it up (I hope - see below) and can carry the fix as necessary
(no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc fs/nfs/direct.c
index 4ad7bc388679,b122fe21fea0..000000000000
--- a/fs/nfs/direct.c
+++ b/fs/nfs/direct.c
@@@ -414,60 -322,37 +414,37 @@@ static const struct nfs_pgio_completion
   * handled automatically by nfs_direct_read_result().  Otherwise, if
   * no requests have been sent, just return an error.
   */
- static ssize_t nfs_direct_read_schedule_segment(struct nfs_pageio_descriptor *desc,
- 						const struct iovec *iov,
- 						loff_t pos, bool uio)
- {
- 	struct nfs_direct_req *dreq = desc->pg_dreq;
- 	struct nfs_open_context *ctx = dreq->ctx;
- 	struct inode *inode = ctx->dentry->d_inode;
- 	unsigned long user_addr = (unsigned long)iov->iov_base;
- 	size_t count = iov->iov_len;
- 	size_t rsize = NFS_SERVER(inode)->rsize;
- 	unsigned int pgbase;
- 	int result;
- 	ssize_t started = 0;
- 	struct page **pagevec = NULL;
- 	unsigned int npages;
- 
- 	do {
- 		size_t bytes;
- 		int i;
  
- 		pgbase = user_addr & ~PAGE_MASK;
- 		bytes = min(max_t(size_t, rsize, PAGE_SIZE), count);
+ static ssize_t nfs_direct_read_schedule_iovec(struct nfs_direct_req *dreq,
+ 					      struct iov_iter *iter,
+ 					      loff_t pos)
+ {
+ 	struct nfs_pageio_descriptor desc;
+ 	struct inode *inode = dreq->inode;
+ 	ssize_t result = -EINVAL;
+ 	size_t requested_bytes = 0;
+ 	size_t rsize = max_t(size_t, NFS_SERVER(inode)->rsize, PAGE_SIZE);
  
- 		result = -ENOMEM;
- 		npages = nfs_page_array_len(pgbase, bytes);
- 		if (!pagevec)
- 			pagevec = kmalloc(npages * sizeof(struct page *),
- 					  GFP_KERNEL);
- 		if (!pagevec)
- 			break;
- 		if (uio) {
- 			down_read(&current->mm->mmap_sem);
- 			result = get_user_pages(current, current->mm, user_addr,
- 					npages, 1, 0, pagevec, NULL);
- 			up_read(&current->mm->mmap_sem);
- 			if (result < 0)
- 				break;
- 		} else {
- 			WARN_ON(npages != 1);
- 			result = get_kernel_page(user_addr, 1, pagevec);
- 			if (WARN_ON(result != 1))
- 				break;
- 		}
 -	NFS_PROTO(dreq->inode)->read_pageio_init(&desc, dreq->inode,
++	nfs_pageio_init_read(&desc, dreq->inode, false,
+ 			     &nfs_direct_read_completion_ops);
+ 	get_dreq(dreq);
+ 	desc.pg_dreq = dreq;
+ 	atomic_inc(&inode->i_dio_count);
  
- 		if ((unsigned)result < npages) {
- 			bytes = result * PAGE_SIZE;
- 			if (bytes <= pgbase) {
- 				nfs_direct_release_pages(pagevec, result);
- 				break;
- 			}
- 			bytes -= pgbase;
- 			npages = result;
- 		}
+ 	while (iov_iter_count(iter)) {
+ 		struct page **pagevec;
+ 		size_t bytes;
+ 		size_t pgbase;
+ 		unsigned npages, i;
  
+ 		result = iov_iter_get_pages_alloc(iter, &pagevec, 
+ 						  rsize, &pgbase);
+ 		if (result < 0)
+ 			break;
+ 	
+ 		bytes = result;
+ 		iov_iter_advance(iter, bytes);
+ 		npages = (result + pgbase + PAGE_SIZE - 1) / PAGE_SIZE;
  		for (i = 0; i < npages; i++) {
  			struct nfs_page *req;
  			unsigned int req_len = min_t(size_t, bytes, PAGE_SIZE - pgbase);
@@@ -965,24 -719,58 +813,57 @@@ static ssize_t nfs_direct_write_schedul
  	struct inode *inode = dreq->inode;
  	ssize_t result = 0;
  	size_t requested_bytes = 0;
- 	unsigned long seg;
+ 	size_t wsize = max_t(size_t, NFS_SERVER(inode)->wsize, PAGE_SIZE);
  
 -	NFS_PROTO(inode)->write_pageio_init(&desc, inode, FLUSH_COND_STABLE,
 +	nfs_pageio_init_write(&desc, inode, FLUSH_COND_STABLE, false,
  			      &nfs_direct_write_completion_ops);
  	desc.pg_dreq = dreq;
  	get_dreq(dreq);
  	atomic_inc(&inode->i_dio_count);
  
- 	NFS_I(dreq->inode)->write_io += iov_length(iov, nr_segs);
- 	for (seg = 0; seg < nr_segs; seg++) {
- 		const struct iovec *vec = &iov[seg];
- 		result = nfs_direct_write_schedule_segment(&desc, vec, pos, uio);
+ 	NFS_I(inode)->write_io += iov_iter_count(iter);
+ 	while (iov_iter_count(iter)) {
+ 		struct page **pagevec;
+ 		size_t bytes;
+ 		size_t pgbase;
+ 		unsigned npages, i;
+ 
+ 		result = iov_iter_get_pages_alloc(iter, &pagevec, 
+ 						  wsize, &pgbase);
  		if (result < 0)
  			break;
- 		requested_bytes += result;
- 		if ((size_t)result < vec->iov_len)
+ 
+ 		bytes = result;
+ 		iov_iter_advance(iter, bytes);
+ 		npages = (result + pgbase + PAGE_SIZE - 1) / PAGE_SIZE;
+ 		for (i = 0; i < npages; i++) {
+ 			struct nfs_page *req;
+ 			unsigned int req_len = min_t(size_t, bytes, PAGE_SIZE - pgbase);
+ 
 -			req = nfs_create_request(dreq->ctx, inode,
 -						 pagevec[i],
++			req = nfs_create_request(dreq->ctx, pagevec[i], NULL,
+ 						 pgbase, req_len);
+ 			if (IS_ERR(req)) {
+ 				result = PTR_ERR(req);
+ 				break;
+ 			}
+ 			nfs_lock_request(req);
+ 			req->wb_index = pos >> PAGE_SHIFT;
+ 			req->wb_offset = pos & ~PAGE_MASK;
+ 			if (!nfs_pageio_add_request(&desc, req)) {
+ 				result = desc.pg_error;
+ 				nfs_unlock_and_release_request(req);
+ 				break;
+ 			}
+ 			pgbase = 0;
+ 			bytes -= req_len;
+ 			requested_bytes += req_len;
+ 			pos += req_len;
+ 			dreq->bytes_left -= req_len;
+ 		}
+ 		nfs_direct_release_pages(pagevec, npages);
+ 		kvfree(pagevec);
+ 		if (result < 0)
  			break;
- 		pos += vec->iov_len;
  	}
  	nfs_pageio_complete(&desc);
  

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* linux-next: manual merge of the vfs tree with the  tree
@ 2012-09-24  1:45 Stephen Rothwell
  0 siblings, 0 replies; 16+ messages in thread
From: Stephen Rothwell @ 2012-09-24  1:45 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 481 bytes --]

Hi Al,

Today's linux-next merge of the vfs tree got a conflict in
kernel/events/core.c between commit a6fa941d94b4 ("perf_event: Switch to
internal refcount, fix race with close()") from Linus' and the vfs trees
and commit 19ba95358327 ("switch simple cases of fget_light to fdget")
from the vfs tree.

I just used the vfs tree version and can carry the fix as necessary (no
action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: linux-next: manual merge of the vfs tree with the  tree
  2009-06-09  6:58 ` Miklos Szeredi
@ 2009-06-09  7:27   ` Stephen Rothwell
  0 siblings, 0 replies; 16+ messages in thread
From: Stephen Rothwell @ 2009-06-09  7:27 UTC (permalink / raw)
  To: Miklos Szeredi; +Cc: viro, linux-next, linux-kernel, tj, vapier

[-- Attachment #1: Type: text/plain, Size: 376 bytes --]

HI Miklos,

On Tue, 09 Jun 2009 08:58:04 +0200 Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> Hmm, looks like that CUSE_SUPER_MAGIC is an unused remnant from an
> earlier version of the CUSE patchset.  I'll fix that up in the fuse
> tree.

Excellent, thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: linux-next: manual merge of the vfs tree with the  tree
  2009-06-09  1:08 Stephen Rothwell
@ 2009-06-09  6:58 ` Miklos Szeredi
  2009-06-09  7:27   ` Stephen Rothwell
  0 siblings, 1 reply; 16+ messages in thread
From: Miklos Szeredi @ 2009-06-09  6:58 UTC (permalink / raw)
  To: sfr; +Cc: viro, linux-next, linux-kernel, tj, miklos, vapier

On Tue, 9 Jun 2009, Stephen Rothwell wrote:
> Today's linux-next merge of the vfs tree got a conflict in
> include/linux/magic.h between commit
> 81ebac1be35a2c2fe1f4d3810a8e57d315600a32 ("CUSE: implement CUSE -
> Character device in Userspace") from the fuse tree and commit
> 5b88aed76b5a1470ec9705c03cf3f0480c018513 ("linux/magic.h: move cramfs
> magic out of cramfs_fs.h") from the vfs tree.

Hmm, looks like that CUSE_SUPER_MAGIC is an unused remnant from an
earlier version of the CUSE patchset.  I'll fix that up in the fuse
tree.

Thanks,
Miklos

> 
> Just overlapping additions.  I fixed it up (see below) and can carry the
> fix as necessary.
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> 
> diff --cc include/linux/magic.h
> index 4596c9e,192f980..0000000
> --- a/include/linux/magic.h
> +++ b/include/linux/magic.h
> @@@ -3,11 -3,12 +3,13 @@@
>   
>   #define ADFS_SUPER_MAGIC	0xadf5
>   #define AFFS_SUPER_MAGIC	0xadff
>  -#define AFS_SUPER_MAGIC                0x5346414F
>  +#define AFS_SUPER_MAGIC		0x5346414F
>   #define AUTOFS_SUPER_MAGIC	0x0187
>   #define CODA_SUPER_MAGIC	0x73757245
> + #define CRAMFS_MAGIC		0x28cd3d45	/* some random number */
> + #define CRAMFS_MAGIC_WEND	0x453dcd28	/* magic number with the wrong endianess */
>  -#define DEBUGFS_MAGIC          0x64626720
>  +#define CUSE_SUPER_MAGIC	0x43555345
>  +#define DEBUGFS_MAGIC		0x64626720
>   #define SYSFS_MAGIC		0x62656572
>   #define SECURITYFS_MAGIC	0x73636673
>   #define TMPFS_MAGIC		0x01021994
> 

^ permalink raw reply	[flat|nested] 16+ messages in thread

* linux-next: manual merge of the vfs tree with the  tree
@ 2009-06-09  1:08 Stephen Rothwell
  2009-06-09  6:58 ` Miklos Szeredi
  0 siblings, 1 reply; 16+ messages in thread
From: Stephen Rothwell @ 2009-06-09  1:08 UTC (permalink / raw)
  To: Al Viro
  Cc: linux-next, linux-kernel, Tejun Heo, Miklos Szeredi, Mike Frysinger

Hi Al,

Today's linux-next merge of the vfs tree got a conflict in
include/linux/magic.h between commit
81ebac1be35a2c2fe1f4d3810a8e57d315600a32 ("CUSE: implement CUSE -
Character device in Userspace") from the fuse tree and commit
5b88aed76b5a1470ec9705c03cf3f0480c018513 ("linux/magic.h: move cramfs
magic out of cramfs_fs.h") from the vfs tree.

Just overlapping additions.  I fixed it up (see below) and can carry the
fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc include/linux/magic.h
index 4596c9e,192f980..0000000
--- a/include/linux/magic.h
+++ b/include/linux/magic.h
@@@ -3,11 -3,12 +3,13 @@@
  
  #define ADFS_SUPER_MAGIC	0xadf5
  #define AFFS_SUPER_MAGIC	0xadff
 -#define AFS_SUPER_MAGIC                0x5346414F
 +#define AFS_SUPER_MAGIC		0x5346414F
  #define AUTOFS_SUPER_MAGIC	0x0187
  #define CODA_SUPER_MAGIC	0x73757245
+ #define CRAMFS_MAGIC		0x28cd3d45	/* some random number */
+ #define CRAMFS_MAGIC_WEND	0x453dcd28	/* magic number with the wrong endianess */
 -#define DEBUGFS_MAGIC          0x64626720
 +#define CUSE_SUPER_MAGIC	0x43555345
 +#define DEBUGFS_MAGIC		0x64626720
  #define SYSFS_MAGIC		0x62656572
  #define SECURITYFS_MAGIC	0x73636673
  #define TMPFS_MAGIC		0x01021994

^ permalink raw reply	[flat|nested] 16+ messages in thread

* linux-next: manual merge of the vfs tree with the  tree
@ 2009-05-13  2:20 Stephen Rothwell
  0 siblings, 0 replies; 16+ messages in thread
From: Stephen Rothwell @ 2009-05-13  2:20 UTC (permalink / raw)
  To: Al Viro, Theodore Ts'o; +Cc: linux-next, Christoph Hellwig

Hi Al, Ted,

Today's linux-next merge of the vfs tree got a conflict in
fs/ext4/super.c between commit 4916bd42cb4e27118d2ab97eb014a2ef84705a56
("ext4: Use separate super_operations structure for no_journal
filesystems") from the ext4 tree and commit
77fe0742eed6c4d18198877fd330a3578b78410d ("->write_super lock_super
pushdown") from the vfs tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.

Ted, there may however be more interactions between the changes in the
vfs tree and some of the changes you have done for ext4 ...

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc fs/ext4/super.c
index dc34ed3,d789833..0000000
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@@ -3303,11 -3268,30 +3306,18 @@@ int ext4_force_commit(struct super_bloc
  	return ret;
  }
  
- static void ext4_write_super(struct super_block *sb)
 -/*
 - * Ext4 always journals updates to the superblock itself, so we don't
 - * have to propagate any other updates to the superblock on disk at this
 - * point.  (We can probably nuke this function altogether, and remove
 - * any mention to sb->s_dirt in all of fs/ext4; eventual cleanup...)
 - */
+ static void ext4_write_super_locked(struct super_block *sb)
  {
 -	if (EXT4_SB(sb)->s_journal) {
 -		if (mutex_trylock(&sb->s_lock) != 0)
 -			BUG();
 -		sb->s_dirt = 0;
 -	} else {
 -		ext4_commit_super(sb, EXT4_SB(sb)->s_es, 1);
 -	}
 +	ext4_commit_super(sb, 1);
  }
  
+ static void ext4_write_super(struct super_block *sb)
+ {
+ 	lock_super(sb);
+ 	ext4_write_super_locked(sb);
+ 	unlock_super(sb);
+ }
+ 
  static int ext4_sync_fs(struct super_block *sb, int wait)
  {
  	int ret = 0;

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: linux-next: manual merge of the vfs tree with the  tree
  2009-05-08 17:50   ` Al Viro
@ 2009-05-09 16:58     ` Miklos Szeredi
  0 siblings, 0 replies; 16+ messages in thread
From: Miklos Szeredi @ 2009-05-09 16:58 UTC (permalink / raw)
  To: viro; +Cc: miklos, sfr, linux-next, hch, tj

On Fri, 8 May 2009, Al Viro wrote:
> > Al, would it make sense to merge the fuse tree into the vfs tree at
> > some point to fix the conflict permanently?
> 
> Hmm...  Doable, of course, but I really wonder if that's the right
> way to deal with this one.  The thing is, looking at the current VFS
> tree I see very few places where FUSE gets called with BKL (essentially,
> ->get_sb(), ->remount_fs()) and ->...ioctl()).  ->remount_fs() is absolutely
> locking-agnostic there and ->get_sb(), ->put_super() and ->umount_begin()
> are all serialized per superblock.  And for data structures that are
> not per-superblock FUSE doesn't rely on BKL in any of those, AFAICT.

That's correct.

> If you can ACK that, we could simply leave FUSE out of all the "push
> BKL down into get_sb/umount_begin/put_super/remount_fs" series.

Okay.

Thanks,
Miklos

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: linux-next: manual merge of the vfs tree with the  tree
  2009-05-08 13:40 ` Miklos Szeredi
@ 2009-05-08 17:50   ` Al Viro
  2009-05-09 16:58     ` Miklos Szeredi
  0 siblings, 1 reply; 16+ messages in thread
From: Al Viro @ 2009-05-08 17:50 UTC (permalink / raw)
  To: Miklos Szeredi; +Cc: sfr, linux-next, hch, tj

On Fri, May 08, 2009 at 03:40:49PM +0200, Miklos Szeredi wrote:
> On Fri, 8 May 2009, Stephen Rothwell wrote:
> > Today's linux-next merge of the vfs tree got a conflict in
> > fs/fuse/inode.c between commit a325f9b92273d6c64ec56167905b951b9827ec33
> > ("fuse: update fuse_conn_init() and separate out fuse_conn_kill()") from
> > the fuse tree and commit 4225d95ddb751e09da0c145b58549da95ba13e3a ("push
> > BKL down into ->put_super") from the vfs tree.
> > 
> > I fixed it up (see below - please check) and can carry the fix as
> > necessary.
> 
> The fixup looks good.
> 
> Al, would it make sense to merge the fuse tree into the vfs tree at
> some point to fix the conflict permanently?

Hmm...  Doable, of course, but I really wonder if that's the right
way to deal with this one.  The thing is, looking at the current VFS
tree I see very few places where FUSE gets called with BKL (essentially,
->get_sb(), ->remount_fs()) and ->...ioctl()).  ->remount_fs() is absolutely
locking-agnostic there and ->get_sb(), ->put_super() and ->umount_begin()
are all serialized per superblock.  And for data structures that are
not per-superblock FUSE doesn't rely on BKL in any of those, AFAICT.

If you can ACK that, we could simply leave FUSE out of all the "push
BKL down into get_sb/umount_begin/put_super/remount_fs" series.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: linux-next: manual merge of the vfs tree with the  tree
  2009-05-08  4:44 Stephen Rothwell
@ 2009-05-08 13:40 ` Miklos Szeredi
  2009-05-08 17:50   ` Al Viro
  0 siblings, 1 reply; 16+ messages in thread
From: Miklos Szeredi @ 2009-05-08 13:40 UTC (permalink / raw)
  To: sfr; +Cc: viro, linux-next, hch, tj, miklos

On Fri, 8 May 2009, Stephen Rothwell wrote:
> Today's linux-next merge of the vfs tree got a conflict in
> fs/fuse/inode.c between commit a325f9b92273d6c64ec56167905b951b9827ec33
> ("fuse: update fuse_conn_init() and separate out fuse_conn_kill()") from
> the fuse tree and commit 4225d95ddb751e09da0c145b58549da95ba13e3a ("push
> BKL down into ->put_super") from the vfs tree.
> 
> I fixed it up (see below - please check) and can carry the fix as
> necessary.

The fixup looks good.

Al, would it make sense to merge the fuse tree into the vfs tree at
some point to fix the conflict permanently?

If so, please pull from

  git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git cuse

to receive the following changes.

Thanks,
Miklos
----

Miklos Szeredi (11):
      fuse: destroy bdi on error
      fuse: use struct path in release structure
      fuse: clean up fuse_write_fill()
      fuse: prepare fuse_direct_io() for CUSE
      fuse: add members to struct fuse_file
      fuse: don't use inode in helpers called by fuse_direct_io()
      fuse: clean up args in fuse_finish_open() and fuse_release_fill()
      fuse: create fuse_do_open() helper for CUSE
      fuse: don't use inode in fuse_sync_release()
      fuse: don't use inode in fuse_do_ioctl() helper
      fuse: don't use inode in fuse_file_poll

Tejun Heo (4):
      fuse: misc cleanups
      fuse: update fuse_conn_init() and separate out fuse_conn_kill()
      fuse: export symbols to be used by CUSE
      CUSE: implement CUSE - Character device in Userspace

---
 fs/Kconfig            |   10 +
 fs/fuse/Makefile      |    1 +
 fs/fuse/cuse.c        |  610 +++++++++++++++++++++++++++++++++++++++++++++++++
 fs/fuse/dev.c         |   15 +-
 fs/fuse/dir.c         |   33 +--
 fs/fuse/file.c        |  346 ++++++++++++++++------------
 fs/fuse/fuse_i.h      |   47 +++-
 fs/fuse/inode.c       |  117 ++++++----
 include/linux/fuse.h  |   31 +++
 include/linux/magic.h |    5 +-
 10 files changed, 983 insertions(+), 232 deletions(-)
 create mode 100644 fs/fuse/cuse.c

^ permalink raw reply	[flat|nested] 16+ messages in thread

* linux-next: manual merge of the vfs tree with the  tree
@ 2009-05-08  4:44 Stephen Rothwell
  2009-05-08 13:40 ` Miklos Szeredi
  0 siblings, 1 reply; 16+ messages in thread
From: Stephen Rothwell @ 2009-05-08  4:44 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-next, Christoph Hellwig, Tejun Heo, Miklos Szeredi

Hi Al,

Today's linux-next merge of the vfs tree got a conflict in
fs/fuse/inode.c between commit a325f9b92273d6c64ec56167905b951b9827ec33
("fuse: update fuse_conn_init() and separate out fuse_conn_kill()") from
the fuse tree and commit 4225d95ddb751e09da0c145b58549da95ba13e3a ("push
BKL down into ->put_super") from the vfs tree.

I fixed it up (see below - please check) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc fs/fuse/inode.c
index d8673cc,31a9720..0000000
--- a/fs/fuse/inode.c
+++ b/fs/fuse/inode.c
@@@ -295,17 -297,10 +298,21 @@@ void fuse_conn_kill(struct fuse_conn *f
  	list_del(&fc->entry);
  	fuse_ctl_remove_conn(fc);
  	mutex_unlock(&fuse_mutex);
 -	bdi_destroy(&fc->bdi);
 +	fuse_bdi_destroy(fc);
 +}
 +EXPORT_SYMBOL_GPL(fuse_conn_kill);
 +
 +static void fuse_put_super(struct super_block *sb)
 +{
 +	struct fuse_conn *fc = get_fuse_conn_super(sb);
 +
++	lock_kernel();
++
 +	fuse_send_destroy(fc);
 +	fuse_conn_kill(fc);
  	fuse_conn_put(fc);
+ 
+ 	unlock_kernel();
  }
  
  static void convert_fuse_statfs(struct kstatfs *stbuf, struct fuse_kstatfs *attr)

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2015-06-05  5:46 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-05-22  1:23 linux-next: manual merge of the vfs tree with the tree Stephen Rothwell
2009-05-24 22:03 ` Frederic Weisbecker
2009-05-24 22:07   ` Christoph Hellwig
2009-05-25 17:10     ` Frederic Weisbecker
2009-05-25  6:50   ` Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2015-06-05  5:46 mpe@ellerman.id.au
2014-05-29  3:25 Stephen Rothwell
2012-09-24  1:45 Stephen Rothwell
2009-06-09  1:08 Stephen Rothwell
2009-06-09  6:58 ` Miklos Szeredi
2009-06-09  7:27   ` Stephen Rothwell
2009-05-13  2:20 Stephen Rothwell
2009-05-08  4:44 Stephen Rothwell
2009-05-08 13:40 ` Miklos Szeredi
2009-05-08 17:50   ` Al Viro
2009-05-09 16:58     ` Miklos Szeredi

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).