[git pull] vfs.git part 5

[git pull] vfs.git part 5

[Al Viro]

	A fairly self-contained series - hunting down open-coded memdup_user()
and memdup_user_nul() instances.

	That's probably it for today; again, I apologize for the amount of
pull requests, but the tree topology is really nasty this cycle.  And these
were actually the simple bits...

The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6:

  Linux 4.12-rc1 (2017-05-13 13:19:49 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.memdup_user

for you to fetch changes up to e4448ed87ccdbacb74871736f63220642242b32f:

  bpf: don't open-code memdup_user() (2017-06-30 02:04:11 -0400)

----------------------------------------------------------------
Al Viro (9):
      sel_write_validatetrans(): don't open-code memdup_user_nul()
      ima_write_policy(): don't open-code memdup_user_nul()
      xfrm_user_policy(): don't open-code memdup_user()
      irda: don't open-code memdup_user()
      do_ipv6_setsockopt(): don't open-code memdup_user()
      do_ip_setsockopt(): don't open-code memdup_user()
      ethtool: don't open-code memdup_user()
      kimage_file_prepare_segments(): don't open-code memdup_user()
      bpf: don't open-code memdup_user()

 kernel/bpf/syscall.c            | 45 ++++++++++++++------------------------
 kernel/kexec_file.c             | 14 ++++--------
 net/core/ethtool.c              | 20 ++++++-----------
 net/ipv4/ip_sockglue.c          | 20 ++++++-----------
 net/ipv6/ipv6_sockglue.c        | 11 +++-------
 net/irda/af_irda.c              | 48 +++++++++++------------------------------
 net/xfrm/xfrm_state.c           | 11 +++-------
 security/integrity/ima/ima_fs.c | 13 ++++-------
 security/selinux/selinuxfs.c    | 12 +++++------
 9 files changed, 59 insertions(+), 135 deletions(-)

Re: [git pull] vfs.git part 5

[Linus Torvalds]

On Wed, Jul 5, 2017 at 12:15 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
>         That's probably it for today; again, I apologize for the amount of
> pull requests, but the tree topology is really nasty this cycle.

There is *no* reason to apologize.

Really - I *much* rather do five separate pull requests where each
pull has a stated reason and target, than do one big mixed-up one.

The "git pull" itself is the least of my problems: it usually takes a
couple of seconds at most, and doing one or five of them doesn't
matter much.

Yes, five of them does slow me down a bit, because I do the "make
allmodconfig" build in between each, but it's not really any more
_work_.

And in fact, smaller and well-defined pull requests make it _so_ much
easier for me to go over and review the thing, and tends to make any
possible conflicts easier to handle too, so I much prefer them this
way.

Because for me, the real job and effort really has nothing to do with
the "git pull" part. It's me looking at *what* I pull that is the real
job, and having that split up logically just makes everything better
for me.

So I heartily encourage everybody to do topic branches - at least when
it is stuff where I care and review. It really does make life better
for me, and I think the real upside is that it also makes for better
kernel development in general when people have that model of trying to
keep separate development threads separate.

Now, there are exceptions, of course. When it comes to tons of
drivers, I really don't want to see fifty pull requests for different
areas of drivers, and I'm really happy that Greg only splits things
out along the really big/broad strokes - because I'm not going to
review individual drivers *anyway*. So it's not like I want to see
_all_ the nitty-gritty details of different development threads. The
big submaintainers (Greg, Davem, etc) do a lot of that aggregation,
and I end up relying on them to just DTRT.

But I really do love seeing the x86 -tip tree send me stuff as 20+
different pull requests for different areas, and merging the ARM
changes has gone from being painful to being no trouble at all, and I
really like seeing the work come in as multiple clear different
branches. It just makes me feel better about the whole maintenance
cycle of the code, even outside of the "easier for me to get an
overview of what is going on".

So yes, getting the VFS code as five different pull requests means
that it takes me longer to merge, but it's literally "longer but
easier", so I'm not at all complaining.

Of course, I say that right now, when I have so far actually only
merged the first of the five pull requests (despite me _replying_ to
the fifth one).  It's going through the build motions right now, and
I'm starting to look at the other ones while that finishes.

So maybe in half an hour you'll get an angry email from me where I
bitch about how horrible pull request #2 was ;)

                Linus

Re: [git pull] vfs.git part 5

[Al Viro]

On Wed, Jul 05, 2017 at 01:33:52PM -0700, Linus Torvalds wrote:
> On Wed, Jul 5, 2017 at 12:15 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> >         That's probably it for today; again, I apologize for the amount of
                            ^^^^^^^^^^^^
> > pull requests, but the tree topologydd is really nasty this cycle.
 
> There is *no* reason to apologize.
> 
> Really - I *much* rather do five separate pull requests where each
> pull has a stated reason and target, than do one big mixed-up one.

Well...  There's another ten or so left.  I can certainly do them
one by one (and will probably have to - the graph is eye-watering
and personally I would hate to have to review it in one go, especially
since there's a couple of places where one branch is pulled in the
middle of another), but I wonder if you'll start cursing the number
of pull requests by the end of it...