Linux 4.7-rc1

Linux 4.7-rc1

[Linus Torvalds]

Usually I close the merge window on a Sunday afternoon, but I've been
known to be annoyed with stragglers and close things a day early. This
time, to spice things up, I decided to just release on Sunday morning
instead.

[ And yes, before you ask , my life really is boring if this is
"spicing things up" ]

The morning release is partly because I don't have anything I know of
pending (and if there was somebody who was planning on sending their
last-minute changes five minutes before the usual afternoon release, I
really can't be bothered to care). And partly because I think it's
been a fine merge window, and we have plenty of new code to close it
with.

And I'm not saying that because the 4.7 merge window is particularly
large - it looks pretty normal, and decidedly smaller then 4.6 was.
But we have all the usual driver updates, but this time around we have
a fairly big change to the vfs layer that allows filesystems (if they
buy into it) to do readdir() and path component lookup in parallel
within the same directory.

That's probably the biggest conceptual vfs change we've had since we
started doing cached pathname lookups using RCU.

That said, the actual *code* changes for that all are fairly small,
and are dwarfed by all the usual driver updates. In fact, none of the
filesystem updates even show up on the default "dirstat" statistics
(because git dirstat by default cuts off showing things at 3%).  So
when it comes to the bulk of the work, we have the usual distribution:
about two thirds drivers (gpu and network drivers dominate, but it's
all over) and the rest is mostly arch updates, documentation,
networking, and "misc" (which is where the vfs changes are hiding).

While this isn't a huge release, it's certainly big enough that even
the shortlog is much too big to post or read to get an overview, so
appended is my normal mergelog summary. And as such, remember that the
people credited are the people I pull the changes from, which is not
necessarily at all the people who actually wrote the code.

Just to give people a sense of the disparity between the maintainer
list below and the number of people submitting patches, there are
about 1400 authors in total for the stuff that came in during the
merge window.

Anyway, enough blathering. Go out and test. And in particular, if
you're a low-level filesystem person, or involved in other ways in
path component lookup (security layer etc), go check that everything
looks ok, and if your filesystem isn't one that does parallel lookups
or readdirs yet (because locking issues), take a look at that too.

            Linus

---

Al Viro (12):
  parallel filesystem directory handling update
  cifs xattr updates
  'struct path' constification update
  vfs cleanups
  remaining vfs xattr work
  cifs iovec cleanups
  parallel lookup fixups
  iov_iter cleanups
  misc vfs cleanups
  vfs xattr regression fixes
  vfs iov_iter regression fix
  vfs fixes

Alex Williamson (1):
  VFIO updates

Alexandre Belloni (1):
  RTC updates

Andrew Morton (5):
  updates
  more updates
  yet more updates
  fixes
  misc updates and fixes

Anna Schumaker (1):
  NFS client updates

Arnd Bergmann (10):
  ARM SoC cleanups and fixes
  ARM SoC platform updates
  ARM SoC 64-bit changes
  ARM DT updates
  ARM 64-bit DT updates
  ARM SoC defconfig updates
  ARM SoC driver updates
  asm-generic cleanup
  ARM SoC late DT updates
  ARM SoC fixes

Bjorn Andersson (2):
  rpmsg updates
  remoteproc updates

Bjorn Helgaas (1):
  PCI updates

Bob Peterson (1):
  GFS2 updates

Borislav Petkov (1):
  EDAC updates

Brian Norris (2):
  MTD updates
  MTD fixes

Bruce Fields (1):
  nfsd updates

Chris Mason (2):
  btrfs updates
  btrfs cleanups and fixes

Chris Metcalf (1):
  arch/tile updates

Corey Minyard (1):
  IPMI updates

Dan Williams (1):
  libnvdimm updates

Darren Hart (1):
  x86 platform driver updates

Dave Airlie (3):
  drm updates
  header warning fix
  drm fixes

Dave Chinner (1):
  xfs updates

Dave Kleikamp (1):
  jfs updates

David Miller (3):
  networking updates
  networking fixes and more updates
  sparc updates

David Vrabel (1):
  xen bug fixes

David Woodhouse (1):
  intel IOMMU updates

Dmitry Torokhov (2):
  input updates
  more input subsystem updates

Doug Ledford (2):
  rdma updates
  more rdma updates

Geert Uytterhoeven (1):
  m68k updates

George Spelvin (1):
  string hash improvements

Greg KH (5):
  tty and serial driver updates
  USB updates
  char / misc driver updates
  driver core updates
  staging and IIO driver updates

Greg Ungerer (1):
  m68knommu update

Guenter Roeck (1):
  hwmon updates

Helge Deller (1):
  parisc updates

Herbert Xu (2):
  crypto update
  crypto fix

Ingo Molnar (19):
  core/lib update
  RCU updates
  core signal updates
  EFI updates
  locking changes
  support for killable rwsems
  perf updates
  RAS updates
  scheduler updates
  x86 asm updates
  x86 boot updates
  x86-64 defconfig update
  x86 cleanup
  x86 debug cleanup
  x86 platform updates
  objtool build fix
  perf updates
  scheduler fixes
  x86 fixes

Jacek Anaszewski (1):
  LED updates

Jaegeuk Kim (1):
  f2fs updates

James Bottomley (1):
  SCSI updates

James Hogan (1):
  metag architecture updates

James Morris (3):
  security subsystem updates
  more security subsystem updates
  Yama locking fix

Jan Kara (1):
  UDF fixes

Jassi Brar (1):
  mailbox updates

Jean Delvare (1):
  hwmon fixlets

Jens Axboe (3):
  core block layer updates
  block driver updates
  block fixes

Jiri Kosina (3):
  trivial tree updates
  livepatching updates
  HID updates

Joerg Roedel (1):
  IOMMU updates

Jon Corbet (1):
  Documentation updates

Konrad Rzeszutek Wilk (1):
  iscsi_ibft updates

Lee Jones (1):
  MFD updates

Ley Foon Tan (1):
  nios2 update

Linus Walleij (2):
  GPIO updates
  pin control updates

Mark Brown (4):
  regmap updates
  regulator updates
  regulator fix
  spi updates

Martin Schwidefsky (1):
  s390 updates

Mauro Carvalho Chehab (1):
  media updates

Michael Ellerman (1):
  powerpc updates

Michael Tsirkin (1):
  virtio updates

Michal Marek (3):
  kbuild updates
  kconfig update
  misc kbuild updates

Michal Simek (1):
  Microblaze updates

Mike Snitzer (1):
  device mapper updates

Miklos Szeredi (1):
  overlayfs update

Nicholas Bellinger (1):
  SCSI target updates

Olof Johansson (1):
  chrome platform updates

Paolo Bonzini (1):
  KVM updates

Paul Moore (1):
  audit updates

Radim Krčmář (1):
  second batch of KVM updates

Rafael Wysocki (5):
  power management updates
  ACPI updates
  device properties update
  more power management updates
  ACPI fix

Ralf Baechle (2):
  MIPS updates
  more MIPS updates

Richard Weinberger (2):
  UBI/UBIFS updates
  UML updates

Rob Herring (1):
  devicetree updates

Ross Zwisler (1):
  DAX locking updates

Russell King (1):
  ARM updates

Sage Weil (1):
  Ceph updates

Sebastian Reichel (2):
  HSI updates
  power supply and reset updates

Shaohua Li (1):
  MD updates

Shuah Khan (1):
  kselftest updates

Stephen Boyd (1):
  clk updates

Steve French (2):
  cifs updates
  cifs fixes

Steven Rostedt (5):
  tracing ring-buffer fixes
  tracing updates
  localmodconfig updates
  motr tracing updates
  tracing fix

Takashi Iwai (2):
  sound updates
  more sound updates

Ted Ts'o (1):
  ext4 updates

Tejun Heo (3):
  libata updates
  libata ZAC support
  libata sata_dwc_460ex updates

Thierry Reding (1):
  pwm updates

Thomas Gleixner (2):
  timer updates
  irq updates

Tomi Valkeinen (1):
  fbdev updates

Tony Luck (1):
  ia64 updates

Ulf Hansson (2):
  MMC updates
  MMC fixes

Vineet Gupta (1):
  ARC updates

Vinod Koul (1):
  dmaengine updates

Vishal Verma (1):
  misc DAX updates

Will Deacon (2):
  arm64 updates
  arm64 perf updates

Wim Van Sebroeck (1):
  watchdog updates

Wolfram Sang (3):
  i2c updates
  more i2c updates
  i2c fix

Zhang Rui (1):
  thermal management updates

Re: Linux 4.7-rc1

[Al Viro]

On Sun, May 29, 2016 at 10:00:25AM -0700, Linus Torvalds wrote:

> Anyway, enough blathering. Go out and test. And in particular, if
> you're a low-level filesystem person, or involved in other ways in
> path component lookup (security layer etc), go check that everything
> looks ok, and if your filesystem isn't one that does parallel lookups
> or readdirs yet (because locking issues), take a look at that too.

Um...  Unlike readdir, which is an opt-in precisely because more state
is involved, lookups are *not* - they are not even opt-out.  They are
done in parallel with each other, period.  Out-of-tree filesystems will
need to audit their ->lookup() instances, of course, but everything
in-tree should be finished in that respect.

lookup/lookup has only one kind of exclusion - no lookups on the same name
in the same directory happening in parallel.  lookup/(directory modifiers) is
still there, of course.  So is readdir/modifiers and modifiers/modifiers.
What is fs-dependent (for now) is lookup/readdir and readdir/readdir.
The latter has per-struct-file exclusion in all cases; if we are using
->iterate_shared(), that's all there is.  If ->iterate() is still being
used, we get lookup/readdir and readdir/readdir exclusion, as we used to.

linux-next: stats (Was: Linux 4.7-rc1)

[Stephen Rothwell]

Hi all,

I have been a bit remiss in publishing these stats and maybe that has
lead to the current lower result for commits in linux-next before the
merge window opened ...

As usual, the executive friendly graph is at
http://neuling.org/linux-next-size.html :-)

(No merge commits counted, next-20160516 was the first linux-next after
the merge window opened.)

Commits in v4.7-rc1 (relative to v4.6):            10707
Commits in next-20160516:                          10067
Commits with the same SHA1:                         9073
Commits with the same patch_id:                      497 (1)
Commits with the same subject line:                   64 (1)

(1) not counting those in the lines above.

So commits in -rc1 that were in next-20160516:      9634 89%

Some breakdown of the list of extra commits (relative to next-20160516)
in -rc1:

Top ten first word of commit summary:

    171 drm
     73 kvm
     67 ib
     49 mips
     47 net
     38 libceph
     34 perf
     30 ceph
     29 mm
     22 xfs

Top ten authors:

     44 bskeggs@redhat.com
     40 idryomov@gmail.com
     30 zyan@redhat.com
     29 andre.przywara@arm.com
     22 emil.l.velikov@gmail.com
     22 andrea.gelmini@gelma.net
     21 chuck.lever@oracle.com
     19 jack@suse.cz
     16 tom@herbertland.com
     16 jlayton@poochiereds.net

Top ten commiters:

    142 davem@davemloft.net
     82 dledford@redhat.com
     72 torvalds@linux-foundation.org
     71 idryomov@gmail.com
     61 anna.schumaker@netapp.com
     59 christoffer.dall@linaro.org
     59 alexander.deucher@amd.com
     58 ralf@linux-mips.org
     51 bskeggs@redhat.com
     31 acme@redhat.com

There are also 435 commits in next-20160516 that didn't make it into
v4.7-rc1.

Top ten first word of commit summary:

     57 tpm
     39 coresight
     32 rdma
     27 lightnvm
     23 ib
     19 arm
     17 btrfs
     14 mm
     13 asoc
      9 xen

Top ten authors:

     34 mathieu.poirier@linaro.org
     34 christophe.ricard@gmail.com
     28 akpm@linux-foundation.org
     26 paulmck@linux.vnet.ibm.com
     16 mustafa.ismail@intel.com
     15 shannon.zhao@linaro.org
     15 m@bjorling.me
     15 jbacik@fb.com
     13 dean.luick@intel.com
     11 arnd@arndb.de

Some of Andrew's patches are fixes for other patches in his tree (and
have been merged into those).

Top ten commiters:

     82 sfr@canb.auug.org.au
     59 jarkko.sakkinen@linux.intel.com
     55 leon@kernel.org
     40 mathieu.poirier@linaro.org
     32 paulmck@linux.vnet.ibm.com
     28 m@bjorling.me
     16 steven@ubuntu-virtualbox.(none)
     15 sstabellini@kernel.org
     15 dsterba@suse.com
     13 broonie@kernel.org

Those commits by me are from the quilt series (mainly Andrew's mmotm
tree).

-- 
Cheers,
Stephen Rothwell

Let me know about regressions in 4.7 (was: Re: Linux 4.7-rc1)

[Thorsten Leemhuis]

On 29.05.2016 19:00, Linus Torvalds wrote:
> […] Anyway, enough blathering. Go out and test. […]

And if you find any regressions in 4.7 pre-releases let me know via
regressions@leemhuis.info I'll try to compile them into a list and post
it on LKML once a week similar to how Rafael did it until a few years
ago. My plan is to do it for 4.7 and maybe 4.8. Don't expect me to do it
for the next few years or so, as I fear kernel regression tracking
might turn out to be quite a lot of work -- and it's work I'll be doing
in my spare time for fun, just because I think someone should do it.

I'll keep my eyes open on LKML and will run a bugzilla query now and
then to find regressions on my own. But you know how it is: it's easy to
miss a mail and there are a few other places where regressions get
reported to, so please forward/bounce them to me or drop me a line if
you see something which should be tracked. Be warned, I also might
encourage users to show up on the right mailing lists to get in contact
with developers that might be responsible for the regression in
question, to hopefully get the regression fixed in the end.

In case you wonder who I am and if I'm capable of doing what I plan to
do: I have some experience with contributing to open source projects,
as I did quite a few things in the Fedora world ten years ago. Apart
from that I earn my money a technical writer that for more than
ten years now watches kernel development quite closely, because I write
about it for a German publishing company. Use your favorite search
engine if you want to know more (for a few years some of the stuff I
wrote was translated to English and published on
http://www.h-online.com/open/). In the end it means: I'm not a
programmer and until now only read LKML, but I think I know quite well
how things work.

Ohh, and if you wonder why I so crazy and just for fun want to do
regression tracking: In the past few years I gave a bunch of talks about
improvements in the latest Linux kernel versions. During or after those
talks quite often someone complained about regressions in the kernel.
People said there were to many of them, complained that regression they
reported were ignored, or found it hard to find the right place to
report regressions.

Cu, knurd

P.S.: BTW for those that run Fedora releases: I maintain a RPM
repository that provides kernel packages build from recent mainline git
snapshots for recent Fedora releases; the latest stable releases are
available there, too. IOW: you can get everything in those repos to
easily run mainline kernels and check for regressions. Find more details
on https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories

Re: Let me know about regressions in 4.7 (was: Re: Linux 4.7-rc1)

[Pavel Machek]

Hi!

> On 29.05.2016 19:00, Linus Torvalds wrote:
> > [???] Anyway, enough blathering. Go out and test. [???]
> 
> And if you find any regressions in 4.7 pre-releases let me know via
> regressions@leemhuis.info I'll try to compile them into a list and post
> it on LKML once a week similar to how Rafael did it until a few years
> ago. My plan is to do it for 4.7 and maybe 4.8. Don't expect me to do it
> for the next few years or so, as I fear kernel regression tracking
> might turn out to be quite a lot of work -- and it's work I'll be doing
> in my spare time for fun, just because I think someone should do it.

Heh, you are a brave soul :-).

I wonder if it might make sense to set up an alias
(regressions@kernel.org) where these could be cc-ed? Perhaps we get a
next volunteer after you...

									Pavel


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html