LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: David Miller <davem@davemloft.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	sfr@canb.auug.org.au, netdev@vger.kernel.org,
	linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
	hch@lst.de, ying.xue@windriver.com, Felipe Balbi <balbi@ti.com>,
	Alan Stern <stern@rowland.harvard.edu>,
	linux-usb@vger.kernel.org
Subject: Re: linux-next: manual merge of the net-next tree with the vfs tree
Date: Fri, 13 Mar 2015 03:56:09 +0000	[thread overview]
Message-ID: <20150313035609.GO29656@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20150312.232426.1464986797003264151.davem@davemloft.net>

On Thu, Mar 12, 2015 at 11:24:26PM -0400, David Miller wrote:
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 13 Mar 2015 13:15:43 +1100
> 
> > Today's linux-next merge of the net-next tree got a conflict in
> > net/socket.c between commits 005139a14660 ("fs: remove ki_nbytes") and
> > e9eab93cc2dc ("fs: don't allow to complete sync iocbs through
> > aio_complete") from the vfs tree and commit 1b784140474e ("net: Remove
> > iocb argument from sendmsg and recvmsg") from the net-next tree.
> > 
> > I fixed it up (mainly using the net-next version - see below) and can
> > carry the fix as necessary (no action is required).
> 
> Al, how do you want to resolve this?

Hmm...  I could backmerge 1b784140474e4fc94281a49e96c67d29df0efbde into
vfs.git#for-next, of course, but you've got quite a pile of stuff in front
of it...  FWIW, the conflict resolution proposed by Stephen is correct;
the question is what should go into which tree.

Actually, prereqs of the commit in question on vfs.git side are mostly
-stable fodder; all it really needs is vfs.git#gadget and I was planning
to send that to Linus - fixes for leaks and use-after-free in gadgetfs
that had been there since forever, plus fixes for regression since 3.18
(->f_op flipping that had always been fishy and outright broke when we
started to FMODE_CAN_READ/FMODE_CAN_WRITE).  USB folks seem to be OK
with it.  Christoph's patch isn't a regression fix, but seeing that it's
(a) trivial and (b) ends up causing merge headache...  Maybe it would
make sense to pull it into mainline and resolve the conflict on backmerge
from mainline to net-next.  Linus?  I've pushed that (gadget + ki_nbytes)
into vfs.git#for-linus-2; would you be OK with pulling that?

It's on
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus-2

Shortlog:
Al Viro (8):
      new helper: dup_iter()
      move iov_iter.c from mm/ to lib/
      gadget/function/f_fs.c: close leaks
      gadget/function/f_fs.c: use put iov_iter into io_data
      gadget/function/f_fs.c: switch to ->{read,write}_iter()
      gadgetfs: use-after-free in ->aio_read()
      gadget: switch ep_io_operations to ->read_iter/->write_iter
      gadgetfs: get rid of flipping ->f_op in ep_config()

Alan Stern (1):
      gadgetfs: really get rid of switching ->f_op

Christoph Hellwig (1):
      fs: remove ki_nbytes

Diffstat:
 drivers/usb/gadget/function/f_fs.c | 204 +++++++---------
 drivers/usb/gadget/legacy/inode.c  | 466 +++++++++++++++----------------------
 fs/aio.c                           |  34 +--
 fs/ceph/file.c                     |   2 +-
 fs/nfs/direct.c                    |   2 +-
 fs/ocfs2/file.c                    |   8 +-
 fs/read_write.c                    |   8 -
 fs/udf/file.c                      |   2 +-
 include/linux/aio.h                |   1 -
 include/linux/uio.h                |   2 +
 kernel/printk/printk.c             |   2 +-
 lib/Makefile                       |   2 +-
 {mm => lib}/iov_iter.c             |  15 ++
 mm/Makefile                        |   2 +-
 mm/page_io.c                       |   1 -
 net/socket.c                       |   6 +-
 16 files changed, 319 insertions(+), 438 deletions(-)
 rename {mm => lib}/iov_iter.c (97%)

  reply	other threads:[~2015-03-13  3:56 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-13  2:15 Stephen Rothwell
2015-03-13  3:24 ` David Miller
2015-03-13  3:56   ` Al Viro [this message]
2015-03-13  4:38     ` Stephen Rothwell
2015-03-13 16:37       ` Al Viro
2015-03-13  4:52     ` David Miller
  -- strict thread matches above, loose matches on Subject: below --
2018-05-17  1:34 Stephen Rothwell
2018-05-17  6:47 ` Christoph Hellwig
2018-01-25  6:41 Stephen Rothwell
2018-01-09 23:34 Stephen Rothwell
2017-12-08  0:33 Stephen Rothwell
2017-04-07  0:22 Stephen Rothwell
2015-03-30  3:24 Stephen Rothwell
2015-03-30  3:08 Stephen Rothwell
2014-11-25  2:42 Stephen Rothwell
2014-11-25 11:23 ` Marcelo Ricardo Leitner
2014-11-25 15:56   ` Pablo Neira Ayuso
2012-09-05  2:02 Stephen Rothwell
2012-09-05  4:55 ` Masatake YAMATO

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150313035609.GO29656@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=balbi@ti.com \
    --cc=davem@davemloft.net \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    --cc=stern@rowland.harvard.edu \
    --cc=torvalds@linux-foundation.org \
    --cc=ying.xue@windriver.com \
    --subject='Re: linux-next: manual merge of the net-next tree with the vfs tree' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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