linux-next: manual merge of the block tree with the vfs tree
Hi all,
Today's linux-next merge of the block tree got a conflict in:
Documentation/filesystems/porting.rst
between commit:
14e43bf43561 ("vfs: don't unnecessarily clone write access for writable fds")
from the vfs tree and commits:
9b2e0016d04c ("bvec/iter: disallow zero-length segment bvecs")
c42bca92be92 ("bio: don't copy bvec for direct IO")
from the block tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc Documentation/filesystems/porting.rst
index c2161de0f4ef,1f8cf8e10b34..
--- a/Documentation/filesystems/porting.rst
+++ b/Documentation/filesystems/porting.rst
@@@ -872,5 -870,14 +872,21 @@@ its result is kern_unmount() or kern_un
**mandatory**
+mnt_want_write_file() can now only be paired with mnt_drop_write_file(),
+whereas previously it could be paired with mnt_drop_write() as well.
++
++---
++
++**mandatory**
++
+ zero-length bvec segments are disallowed, they must be filtered out before
+ passed on to an iterator.
+
+ ---
+
+ **mandatory**
+
+ For bvec based itererators bio_iov_iter_get_pages() now doesn't copy bvecs but
+ uses the one provided. Anyone issuing kiocb-I/O should ensure that the bvec
and
+ page references stay until I/O has completed, i.e. until ->ki_complete() has
+ been called or returned with non -EIOCBQUEUED code.
pgpLLotw8Lol4.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the block tree with the vfs tree
On 5/29/18 3:40 PM, Stephen Rothwell wrote: > Hi Jens, > > On Tue, 29 May 2018 08:22:43 -0600 Jens Axboe wrote: >> >> On 5/29/18 2:12 AM, Christoph Hellwig wrote: >>> Meh. Do we really need these switch to octal patches to start >>> with? I mean, I personally prefer octal, but just switching around >>> in random code that isn't otherwise changed creates nothing but churn. >> >> This is exactly why I hesitated doing it, I knew it would end up >> with conflicts. The main reason was to get rid of the inconsistency, >> since we had a fair mix of octal and symbolic names. > > But the conflicts are all trivial ... Yep, that certainly does help. -- Jens Axboe
Re: linux-next: manual merge of the block tree with the vfs tree
Hi Jens, On Tue, 29 May 2018 08:22:43 -0600 Jens Axboe wrote: > > On 5/29/18 2:12 AM, Christoph Hellwig wrote: > > Meh. Do we really need these switch to octal patches to start > > with? I mean, I personally prefer octal, but just switching around > > in random code that isn't otherwise changed creates nothing but churn. > > This is exactly why I hesitated doing it, I knew it would end up > with conflicts. The main reason was to get rid of the inconsistency, > since we had a fair mix of octal and symbolic names. But the conflicts are all trivial ... -- Cheers, Stephen Rothwell pgpABYiilCSMK.pgp Description: OpenPGP digital signature
Re: linux-next: manual merge of the block tree with the vfs tree
On 5/29/18 2:12 AM, Christoph Hellwig wrote: > Meh. Do we really need these switch to octal patches to start > with? I mean, I personally prefer octal, but just switching around > in random code that isn't otherwise changed creates nothing but churn. This is exactly why I hesitated doing it, I knew it would end up with conflicts. The main reason was to get rid of the inconsistency, since we had a fair mix of octal and symbolic names. -- Jens Axboe
Re: linux-next: manual merge of the block tree with the vfs tree
Meh. Do we really need these switch to octal patches to start
with? I mean, I personally prefer octal, but just switching around
in random code that isn't otherwise changed creates nothing but churn.
On Tue, May 29, 2018 at 02:33:57PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the block tree got a conflict in:
>
> drivers/block/DAC960.c
>
> between commit:
>
> 3f3942aca6da ("proc: introduce proc_create_single{,_data}")
>
> from the vfs tree and commit:
>
> 5657a819a8d9 ("block drivers/block: Use octal not symbolic permissions")
>
> from the block tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/block/DAC960.c
> index 6918c3d9482e,7c3887a7e534..
> --- a/drivers/block/DAC960.c
> +++ b/drivers/block/DAC960.c
> @@@ -6553,11 -6587,9 +6548,11 @@@ static void DAC960_CreateProcEntries(DA
>"c%d", Controller->ControllerNumber);
> ControllerProcEntry = proc_mkdir(Controller->ControllerName,
>DAC960_ProcDirectoryEntry);
> -proc_create_data("initial_status", 0, ControllerProcEntry,
> &dac960_initial_status_proc_fops, Controller);
> -proc_create_data("current_status", 0, ControllerProcEntry,
> &dac960_current_status_proc_fops, Controller);
> +proc_create_single_data("initial_status", 0, ControllerProcEntry,
> +dac960_initial_status_proc_show, Controller);
> +proc_create_single_data("current_status", 0, ControllerProcEntry,
> +dac960_current_status_proc_show, Controller);
> - proc_create_data("user_command", S_IWUSR | S_IRUSR,
> ControllerProcEntry, &dac960_user_command_proc_fops, Controller);
> + proc_create_data("user_command", 0600, ControllerProcEntry,
> &dac960_user_command_proc_fops, Controller);
> Controller->ControllerProcEntry = ControllerProcEntry;
> }
>
---end quoted text---
linux-next: manual merge of the block tree with the vfs tree
Hi all,
Today's linux-next merge of the block tree got a conflict in:
drivers/block/drbd/drbd_main.c
between commit:
004fd11db1d6 ("drbd: switch to proc_create_single")
from the vfs tree and commit:
5657a819a8d9 ("block drivers/block: Use octal not symbolic permissions")
from the block tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/block/drbd/drbd_main.c
index c2d154faac02,e6ec831ad472..
--- a/drivers/block/drbd/drbd_main.c
+++ b/drivers/block/drbd/drbd_main.c
@@@ -3010,8 -3010,7 +3010,8 @@@ static int __init drbd_init(void
goto fail;
err = -ENOMEM;
- drbd_proc = proc_create_single("drbd", S_IFREG | S_IRUGO , NULL,
- drbd_proc = proc_create_data("drbd", S_IFREG | 0444 , NULL,
&drbd_proc_fops, NULL);
++ drbd_proc = proc_create_single("drbd", S_IFREG | 0444 , NULL,
+ drbd_seq_show);
if (!drbd_proc) {
pr_err("unable to register proc file\n");
goto fail;
pgpl1YdX4Kt7T.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the block tree with the vfs tree
Hi all,
Today's linux-next merge of the block tree got a conflict in:
drivers/block/DAC960.c
between commit:
3f3942aca6da ("proc: introduce proc_create_single{,_data}")
from the vfs tree and commit:
5657a819a8d9 ("block drivers/block: Use octal not symbolic permissions")
from the block tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/block/DAC960.c
index 6918c3d9482e,7c3887a7e534..
--- a/drivers/block/DAC960.c
+++ b/drivers/block/DAC960.c
@@@ -6553,11 -6587,9 +6548,11 @@@ static void DAC960_CreateProcEntries(DA
"c%d", Controller->ControllerNumber);
ControllerProcEntry = proc_mkdir(Controller->ControllerName,
DAC960_ProcDirectoryEntry);
- proc_create_data("initial_status", 0, ControllerProcEntry,
&dac960_initial_status_proc_fops, Controller);
- proc_create_data("current_status", 0, ControllerProcEntry,
&dac960_current_status_proc_fops, Controller);
+ proc_create_single_data("initial_status", 0, ControllerProcEntry,
+ dac960_initial_status_proc_show, Controller);
+ proc_create_single_data("current_status", 0, ControllerProcEntry,
+ dac960_current_status_proc_show, Controller);
- proc_create_data("user_command", S_IWUSR | S_IRUSR,
ControllerProcEntry, &dac960_user_command_proc_fops, Controller);
+ proc_create_data("user_command", 0600, ControllerProcEntry,
&dac960_user_command_proc_fops, Controller);
Controller->ControllerProcEntry = ControllerProcEntry;
}
pgpaqkplpnzMA.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the block tree with the vfs tree
Hi all,
On Thu, 2 Feb 2017 13:44:07 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the block tree got a conflict in:
>
> drivers/block/nbd.c
>
> between commit:
>
> c9f2b6aeb922 ("[nbd] pass iov_iter to nbd_xmit()")
>
> from the vfs tree and commit:
>
> 09fc54ccc427 ("nbd: move request validity checking into nbd_send_cmd")
> aebf526b53ae ("block: fold cmd_type into the REQ_OP_ space")
>
> from the block tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/block/nbd.c
> index 48132b0530fe,0be84a3cb6d7..
> --- a/drivers/block/nbd.c
> +++ b/drivers/block/nbd.c
> @@@ -265,17 -275,32 +262,32 @@@ static int nbd_send_cmd(struct nbd_devi
> u32 type;
> u32 tag = blk_mq_unique_tag(req);
>
> +iov_iter_kvec(&from, WRITE | ITER_KVEC, &iov, 1, sizeof(request));
> +
> - if (req_op(req) == REQ_OP_DISCARD)
> + switch (req_op(req)) {
> + case REQ_OP_DISCARD:
> type = NBD_CMD_TRIM;
> - else if (req_op(req) == REQ_OP_FLUSH)
> + break;
> + case REQ_OP_FLUSH:
> type = NBD_CMD_FLUSH;
> - else if (rq_data_dir(req) == WRITE)
> + break;
> + case REQ_OP_WRITE:
> type = NBD_CMD_WRITE;
> - else
> + break;
> + case REQ_OP_READ:
> type = NBD_CMD_READ;
> + break;
> + default:
> + return -EIO;
> + }
> +
> + if (rq_data_dir(req) == WRITE &&
> + (nbd->flags & NBD_FLAG_READ_ONLY)) {
> + dev_err_ratelimited(disk_to_dev(nbd->disk),
> + "Write on read-only\n");
> + return -EIO;
> + }
>
> -memset(&request, 0, sizeof(request));
> -request.magic = htonl(NBD_REQUEST_MAGIC);
> request.type = htonl(type);
> if (type != NBD_CMD_FLUSH) {
> request.from = cpu_to_be64((u64)blk_rq_pos(req) << 9);
This is now a conflict between the vfs tree and Linus' tree.
--
Cheers,
Stephen Rothwell
linux-next: manual merge of the block tree with the vfs tree
Hi Jens,
Today's linux-next merge of the block tree got a conflict in:
drivers/block/nbd.c
between commit:
c9f2b6aeb922 ("[nbd] pass iov_iter to nbd_xmit()")
from the vfs tree and commit:
09fc54ccc427 ("nbd: move request validity checking into nbd_send_cmd")
aebf526b53ae ("block: fold cmd_type into the REQ_OP_ space")
from the block tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/block/nbd.c
index 48132b0530fe,0be84a3cb6d7..
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@@ -265,17 -275,32 +262,32 @@@ static int nbd_send_cmd(struct nbd_devi
u32 type;
u32 tag = blk_mq_unique_tag(req);
+ iov_iter_kvec(&from, WRITE | ITER_KVEC, &iov, 1, sizeof(request));
+
- if (req_op(req) == REQ_OP_DISCARD)
+ switch (req_op(req)) {
+ case REQ_OP_DISCARD:
type = NBD_CMD_TRIM;
- else if (req_op(req) == REQ_OP_FLUSH)
+ break;
+ case REQ_OP_FLUSH:
type = NBD_CMD_FLUSH;
- else if (rq_data_dir(req) == WRITE)
+ break;
+ case REQ_OP_WRITE:
type = NBD_CMD_WRITE;
- else
+ break;
+ case REQ_OP_READ:
type = NBD_CMD_READ;
+ break;
+ default:
+ return -EIO;
+ }
+
+ if (rq_data_dir(req) == WRITE &&
+ (nbd->flags & NBD_FLAG_READ_ONLY)) {
+ dev_err_ratelimited(disk_to_dev(nbd->disk),
+ "Write on read-only\n");
+ return -EIO;
+ }
- memset(&request, 0, sizeof(request));
- request.magic = htonl(NBD_REQUEST_MAGIC);
request.type = htonl(type);
if (type != NBD_CMD_FLUSH) {
request.from = cpu_to_be64((u64)blk_rq_pos(req) << 9);
Re: linux-next: manual merge of the block tree with the vfs tree
On Mon, Dec 12, 2016 at 9:31 AM, Stephen Rothwell wrote:
> Hi Jens,
>
> Today's linux-next merge of the block tree got a conflict in:
>
> fs/logfs/dev_bdev.c
>
> between commit:
>
> 6b4fbde3b979 ("logfs: remove from tree")
>
> from the vfs tree and commitis:
>
> 3a83f4677539 ("block: bio: pass bvec table to bio_init()")
> 739a9975468c ("fs: logfs: convert to bio_add_page() in sync_request()")
> d4f98a89f9cd ("fs: logfs: use bio_add_page() in __bdev_writeseg()")
> c12484367865 ("fs: logfs: use bio_add_page() in do_erase()")
> 05aea81b4bc9 ("fs: logfs: remove unnecesary check")
>
> from the block tree.
>
> I fixed it up (I removed the file) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging. You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
Looks every time the logfs changes have been posted in fsdev mail list.
--
Ming Lei
Re: linux-next: manual merge of the block tree with the vfs tree
On Mon, Dec 12, 2016 at 12:31:40PM +1100, Stephen Rothwell wrote: > Al: that vfs tree commit has a bad email address for Christoph in it :-( Gyah... OK, will fix (the bulk of the diff, of course, had been regenerated while commit message came from his old mail; unfortunately, it had been long gone from my mailbox, so I'd picked it from archives and completely missed the mangled address).
linux-next: manual merge of the block tree with the vfs tree
Hi Jens,
Today's linux-next merge of the block tree got a conflict in:
fs/logfs/dev_bdev.c
between commit:
6b4fbde3b979 ("logfs: remove from tree")
from the vfs tree and commitis:
3a83f4677539 ("block: bio: pass bvec table to bio_init()")
739a9975468c ("fs: logfs: convert to bio_add_page() in sync_request()")
d4f98a89f9cd ("fs: logfs: use bio_add_page() in __bdev_writeseg()")
c12484367865 ("fs: logfs: use bio_add_page() in do_erase()")
05aea81b4bc9 ("fs: logfs: remove unnecesary check")
from the block tree.
I fixed it up (I removed the file) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
Al: that vfs tree commit has a bad email address for Christoph in it :-(
--
Cheers,
Stephen Rothwell
linux-next: manual merge of the block tree with the vfs tree
Hi Jens,
Today's linux-next merge of the block tree got a conflict in
fs/configfs/configfs_internal.h between commit 22dc94f27d4b ("configfs:
configfs_create() init callback is never NULL and it never fails") from
the vfs tree and commit b4caecd48005 ("fs: introduce
f_op->mmap_capabilities for nommu mmap support") from the block tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc fs/configfs/configfs_internal.h
index 865e41983611,a315677e44d3..
--- a/fs/configfs/configfs_internal.h
+++ b/fs/configfs/configfs_internal.h
@@@ -69,9 -69,7 +69,7 @@@ extern struct kmem_cache *configfs_dir_
extern int configfs_is_root(struct config_item *item);
extern struct inode * configfs_new_inode(umode_t mode, struct configfs_dirent
*, struct super_block *);
-extern int configfs_create(struct dentry *, umode_t mode, int (*init)(struct
inode *));
+extern int configfs_create(struct dentry *, umode_t mode, void (*init)(struct
inode *));
- extern int configfs_inode_init(void);
- extern void configfs_inode_exit(void);
extern int configfs_create_file(struct config_item *, const struct
configfs_attribute *);
extern int configfs_make_dirent(struct configfs_dirent *,
pgpZ3rJknX6LV.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the block tree with the vfs tree
On Sun, Feb 01, 2015 at 05:56:19AM +, Al Viro wrote:
> FWIW, there's an interesting question about the second commit in there -
> what do we want vfs_iter_{read,write}() to do with *iter in case if it
> has hit this:
> if (ret == -EIOCBQUEUED)
> ret = wait_on_sync_kiocb(&kiocb);
>
> Do we require ->read_iter() and ->write_iter() on sync kiocb to do all
> advancing the iter before returning -EIOCBQUEUED? What's more, do we
> ever want to have it returned on sync kiocb? IOW, is there any point
> in having that wait in callers?
See my "[RFC] split struct kiocb" series to sort out that mess. For
now none of the callers relies on the iov_iter being advances, so until
then we can simply ignore that problem until then.
> I'm not sure if ep_io() and ep_aio_rwtail() + wait for completion are
> eqiuvalent; ep_read/ep_write are very easy to turn into sync side of
> ->read_iter/->write_iter and if that's equivalent to ep_aio_read/ep_aio_write
> on sync kiocb + waiting for completion, we are fine.
They are very similar, and yes thet should be moved to iter version of
the methods. I actually started that but then ran into problems with
the aio core that needed addressing first.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the block tree with the vfs tree
On Thu, Jan 29, 2015 at 05:15:55AM +, Al Viro wrote:
> On Wed, Jan 28, 2015 at 06:11:02PM +0100, Christoph Hellwig wrote:
> > On Tue, Jan 27, 2015 at 04:54:22AM +, Al Viro wrote:
> > > I don't mind opening a never-rebased branch for generic iov_iter-related
> > > stuff;
> > > if you prefer to handle it that way - just tell. The first two patches
> > > from that series would definitely go there; as for the rest... no
> > > preferences
> > > here.
> >
> > It might make sense to just keep the VFS patches in your tree.
> > The target ones also are something I'd prefer if it goes through Nic
> > with additional review. In addition they aren't really critical,
> > so if you merge the prep patches now we can feed the rest through
> > the proper trees in the .21 merge window.
>
> Done. The first two are in #iov_iter now (merged into #for-next), the
> rest is dropped. And #iov_iter is in never-rebased mode, so feel free
> to pull it wherever you need it.
FWIW, there's an interesting question about the second commit in there -
what do we want vfs_iter_{read,write}() to do with *iter in case if it
has hit this:
if (ret == -EIOCBQUEUED)
ret = wait_on_sync_kiocb(&kiocb);
Do we require ->read_iter() and ->write_iter() on sync kiocb to do all
advancing the iter before returning -EIOCBQUEUED? What's more, do we
ever want to have it returned on sync kiocb? IOW, is there any point
in having that wait in callers?
Note that there are _very_ few drivers that ever do that; fs/direct_io.c,
for example, will wait for completion in case of sync kiocb. AFAICS,
there are exactly two drivers like that: drivers/usb/gadget/legacy/inode.c
and drivers/usb/gadget/function/f_fs.c. And the latter is very easy to
convert to "waits in case of sync kiocb" - there already are two codepaths
({read,write} and aio_{read,write}) and it's trivial to teach the sync
path to deal with arbitrary iov_iter, with aio side of things doing the
sync variant in case of sync kiocb. Cheaper, as well, since we don't need
to copy iovec, etc.
I'm not sure if ep_io() and ep_aio_rwtail() + wait for completion are
eqiuvalent; ep_read/ep_write are very easy to turn into sync side of
->read_iter/->write_iter and if that's equivalent to ep_aio_read/ep_aio_write
on sync kiocb + waiting for completion, we are fine.
Comments?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the block tree with the vfs tree
On Wed, Jan 28, 2015 at 06:11:02PM +0100, Christoph Hellwig wrote: > On Tue, Jan 27, 2015 at 04:54:22AM +, Al Viro wrote: > > I don't mind opening a never-rebased branch for generic iov_iter-related > > stuff; > > if you prefer to handle it that way - just tell. The first two patches > > from that series would definitely go there; as for the rest... no > > preferences > > here. > > It might make sense to just keep the VFS patches in your tree. > The target ones also are something I'd prefer if it goes through Nic > with additional review. In addition they aren't really critical, > so if you merge the prep patches now we can feed the rest through > the proper trees in the .21 merge window. Done. The first two are in #iov_iter now (merged into #for-next), the rest is dropped. And #iov_iter is in never-rebased mode, so feel free to pull it wherever you need it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the block tree with the vfs tree
On Tue, Jan 27, 2015 at 04:54:22AM +, Al Viro wrote: > I don't mind opening a never-rebased branch for generic iov_iter-related > stuff; > if you prefer to handle it that way - just tell. The first two patches > from that series would definitely go there; as for the rest... no preferences > here. It might make sense to just keep the VFS patches in your tree. The target ones also are something I'd prefer if it goes through Nic with additional review. In addition they aren't really critical, so if you merge the prep patches now we can feed the rest through the proper trees in the .21 merge window. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the block tree with the vfs tree
On Mon, Jan 26, 2015 at 09:00:18PM -0700, Jens Axboe wrote:
> On 01/26/2015 08:57 PM, Stephen Rothwell wrote:
> >Hi Jens,
> >
> >Today's linux-next merge of the block tree got a conflict in
> >drivers/block/loop.c between commit c2ca80413553 ("loop: convert to
> >vfs_iter_read/write") from the vfs tree and commit b5dd2f6047ca
> >("block: loop: improve performance via blk-mq") and several others from
> >the block tree.
> >
> >I have no idea how fixed it up so I just used the version of the file
> >from the block tree (its been there a while). Please have a chat and
> >figure out how to combine these two large changes.
>
> Why isn't the loop patch in the block tree? That'd avoid such
> incidents. We could add a dependency for the required VFS patch.
I don't mind opening a never-rebased branch for generic iov_iter-related stuff;
if you prefer to handle it that way - just tell. The first two patches
from that series would definitely go there; as for the rest... no preferences
here.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the block tree with the vfs tree
On 01/26/2015 08:57 PM, Stephen Rothwell wrote:
Hi Jens,
Today's linux-next merge of the block tree got a conflict in
drivers/block/loop.c between commit c2ca80413553 ("loop: convert to
vfs_iter_read/write") from the vfs tree and commit b5dd2f6047ca
("block: loop: improve performance via blk-mq") and several others from
the block tree.
I have no idea how fixed it up so I just used the version of the file
from the block tree (its been there a while). Please have a chat and
figure out how to combine these two large changes.
Why isn't the loop patch in the block tree? That'd avoid such incidents.
We could add a dependency for the required VFS patch.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the block tree with the vfs tree
Hi Jens,
Today's linux-next merge of the block tree got a conflict in
drivers/block/loop.c between commit c2ca80413553 ("loop: convert to
vfs_iter_read/write") from the vfs tree and commit b5dd2f6047ca
("block: loop: improve performance via blk-mq") and several others from
the block tree.
I have no idea how fixed it up so I just used the version of the file
from the block tree (its been there a while). Please have a chat and
figure out how to combine these two large changes.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgptwWq_KjQ1f.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the block tree with the vfs tree
Hi Jens,
Today's linux-next merge of the block tree got a conflict in
drivers/block/drbd/drbd_proc.c between commit 4dfac87dca02 ("procfs: new
helper - PDE_DATA(inode)") from the vfs tree and commit 193d01532a73
("drbd: add module_put() on error path in drbd_proc_open()") from the
block tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/block/drbd/drbd_proc.c
index 928adb8,30fe0a5..000
--- a/drivers/block/drbd/drbd_proc.c
+++ b/drivers/block/drbd/drbd_proc.c
@@@ -313,8 -313,14 +313,14 @@@ static int drbd_seq_show(struct seq_fil
static int drbd_proc_open(struct inode *inode, struct file *file)
{
- if (try_module_get(THIS_MODULE))
- return single_open(file, drbd_seq_show, PDE_DATA(inode));
+ int err;
+
+ if (try_module_get(THIS_MODULE)) {
- err = single_open(file, drbd_seq_show, PDE(inode)->data);
++ err = single_open(file, drbd_seq_show, PDE_DATA(inode));
+ if (err)
+ module_put(THIS_MODULE);
+ return err;
+ }
return -ENODEV;
}
pgpcBMRR5uYTC.pgp
Description: PGP signature
