2014-06-08 18:52:30

by Linus Torvalds

[permalink] [raw]
Subject: Linux 3.15 .. and continuation of merge window

So I ended up doing an rc8 because I was a bit worried about some
last-minute dcache fixes, but it turns out that nobody seemed to even
notice those. We did have other issues during the week, though, so it
was just as well. The futex fixes and cleanups may stand out, but as
usual there's various other random fixes since rc8 in there too:
mainly drivers (drm, networking, sound, usb etc), networking,
scheduling and perf tooling.

But it's all been fairly small and quiet, which *may* of course be due
to the fact that last week was also the first week of the merge window
for 3.16. That might have distracted some developers. I'm not entirely
convinced I liked the overlap, but it seemed to work ok, and unless
people scream really loudly ("Please don't _ever_ do that again") and
give good reasons for doing so, I might end up doing that overlapping
merge window in the future too if it ends up helping out with some
particular timing issue.

That said, I also don't think it was such a wonderful experience that
I'd want to necessarily do the overlap every time, without a good
specific reason for doing so. It was kind of nice being productive
during the last week or rc (which is usually quite boring and dead),
but I think it might be a distraction when people should be worrying
about the stability of the rc.

Of course, maybe the overlap ends up meaning that we get less noise
during the last week of stabilization, and it actually helps. It could
go either way. I'd be interested to hear what people thought, although
I _suspect_ most people don't feel strongly either way.

Anyway, with 3.15 released, my "master" branch has already merged the
work in my "next" branch on my local machine, and I'll be
decommissioning the "next" branch once I push that all out. After
that, any future merge window work will happen on "master", and we'll
be back to the normal single-branch model for my tree.

Linus

---

Alan Stern (1):
USB: Avoid runtime suspend loops for HCDs that can't handle suspend/resume

Aleksander Morgado (3):
net: qmi_wwan: add Netgear AirCard 341U
net: qmi_wwan: add additional Sierra Wireless QMI devices
net: qmi_wwan: interface #11 in Sierra Wireless MC73xx is not QMI

Alex Deucher (1):
drm/radeon/dpm: resume fixes for some systems

Alexej Starschenko (1):
USB: serial: option: add support for Novatel E371 PCIe card

Andrey Ryabinin (1):
mm: rmap: fix use-after-free in __put_anon_vma

Andy Lutomirski (1):
x86, vdso: Fix an OOPS accessing the HPET mapping w/o an HPET

Bart De Schuymer (1):
ebtables: Update MAINTAINERS entry.

Ben Hutchings (2):
Staging: speakup: Move pasting into a work item
Staging: speakup: Update __speakup_paste_selection() tty
(ab)usage to match vt

Bjørn Mork (1):
usb: cdc-wdm: export cdc-wdm uapi header

Christian König (3):
drm/radeon: fix vm buffer size estimation
drm/radeon: sync page table updates
drm/radeon: use the CP DMA on CIK

Dan Carpenter (1):
qlcnic: info leak in qlcnic_dcb_peer_app_info()

Dave Young (2):
x86/efi: earlyprintk=efi,keep fix
x86/efi: Do not export efi runtime map in case old map

Dirk Brandewie (3):
intel_pstate: Remove C0 tracking
intel_pstate: Correct rounding in busy calculation
intel_pstate: add sample time scaling

Doug Smythies (1):
intel_pstate: Improve initial busy calculation

Emmanuel Grumbach (1):
iwlwifi: mvm: disable beacon filtering

Eric Dumazet (1):
net: fix inet_getid() and ipv6_select_ident() bugs

Eric W. Biederman (1):
netlink: Only check file credentials for implicit destinations

Filipe Manana (1):
Btrfs: send, fix corrupted path strings for long paths

George McCollister (1):
USB: ftdi_sio: add NovaTech OrionLXm product ID

Greg Kroah-Hartman (1):
USB: cdc-wdm: properly include types.h

Ian Abbott (1):
staging: comedi: ni_daq_700: add mux settling delay

Igor Mammedov (3):
x86: Fix list/memory corruption on CPU hotplug
x86/smpboot: Log error on secondary CPU wakeup failure at ERR level
x86/smpboot: Initialize secondary CPU only if master CPU will wait for it

Ivan Mikhaylov (2):
emac: add missing support of 10mbit in emac/rgmii
emac: aggregation of v1-2 PLB errors for IER register

Jack Morgenstein (1):
net/mlx4_core: Reset RoCE VF gids when guest driver goes down

Jean Delvare (1):
net: ec_bhf: Add runtime dependencies

Jianyu Zhan (1):
kernfs: move the last knowledge of sysfs out from kernfs

Jiri Pirko (1):
team: fix mtu setting

Johan Hovold (1):
USB: io_ti: fix firmware download on big-endian machines (part 2)

Jon Maxwell (1):
bridge: notify user space after fdb update

Kirill Tkhai (1):
sched/dl: Fix race in dl_task_timer()

Kristian Evensen (1):
ipheth: Add support for iPad 2 and iPad 3

Leon Yu (1):
net: filter: fix possible memory leak in __sk_prepare_filter()

Linus Torvalds (2):
Revert "x86/smpboot: Initialize secondary CPU only if master CPU
will wait for it"
Linux 3.15

Marek Lindner (1):
batman-adv: fix NULL pointer dereferences

Martin K. Petersen (1):
libata: Blacklist queued trim for Crucial M500

Masami Hiramatsu (2):
perf probe: Fix a segfault if asked for variable it doesn't find
perf probe: Fix perf probe to find correct variable DIE

Mathias Nyman (2):
usb: pci-quirks: Prevent Sony VAIO t-series from switching usb ports
xhci: delete endpoints from bandwidth list before freeing whole device

Matt Fleming (1):
x86/boot: EFI_MIXED should not prohibit loading above 4G

Michal Schmidt (1):
netlink: rate-limit leftover bytes warning and print process name

Naoya Horiguchi (1):
mm: add !pte_present() check on existing hugetlb_entry callbacks

NeilBrown (2):
md: always set MD_RECOVERY_INTR when aborting a reshape or other "resync".
md: always set MD_RECOVERY_INTR when interrupting a reshape thread.

Nicholas Bellinger (4):
iser-target: Add missing target_put_sess_cmd for ImmedateData failure
iser-target: Fix multi network portal shutdown regression
target: Allow READ_CAPACITY opcode in ALUA Standby access state
target: Fix alua_access_state attribute OOPs for un-configured devices

Nikolay Aleksandrov (1):
net: fix wrong mac_len calculation for vlans

Oliver Hartkopp (1):
can: only rename enabled led triggers when changing the netdev name

Peter Christensen (1):
ipvs: Fix panic due to non-linear skb

Richard Weinberger (1):
sched: Fix sched_policy < 0 comparison

Roland Dreier (1):
iscsi-target: Fix wrong buffer / buffer overrun in
iscsi_change_param_value()

Roman Gushchin (1):
sched/fair: Fix tg_set_cfs_bandwidth() deadlock on rq->lock

Ronan Marquet (1):
ALSA: hda/realtek - Correction of fixup codes for PB V7900 laptop

Rusty Russell (1):
speakup: fix incorrect perms on speakup_acntsa.c

Samuel Ortiz (1):
Bluetooth: Fix L2CAP LE debugfs entries permissions

Sean MacLennan (1):
staging: r8192e_pci: fix htons error

Sebastian Ott (1):
percpu-refcount: fix usage of this_cpu_ops

Sergei Antonov (1):
drm/crtc-helper: skip locking checks in panicking path

Steven Rostedt (1):
sched/numa: Fix use of spin_{un}lock_irq() when interrupts are disabled

Takashi Iwai (2):
ALSA: hda/analog - Fix silent output on ASUS A8JN
ALSA: hda/realtek - Fix COEF widget NID for ALC260 replacer fixup

Thomas Gleixner (4):
futex-prevent-requeue-pi-on-same-futex.patch futex: Forbid uaddr
== uaddr2 in futex_requeue(..., requeue_pi=1)
futex: Validate atomic acquisition in futex_lock_pi_atomic()
futex: Always cleanup owner tid in unlock_pi
futex: Make lookup_pi_state more robust

Toshiaki Makita (1):
bridge: Prevent insertion of FDB entry with disallowed vlan

Yinghai Lu (1):
x86: irq: Get correct available vectors for cpu disable

Yuchung Cheng (1):
tcp: fix cwnd undo on DSACK in F-RTO


2014-06-09 03:31:10

by J. R. Okajima

[permalink] [raw]
Subject: Re: Linux 3.15 .. and continuation of merge window


Linus Torvalds:
> So I ended up doing an rc8 because I was a bit worried about some
> last-minute dcache fixes, but it turns out that nobody seemed to even
> notice those. We did have other issues during the week, though, so it
:::

I am afraid there is a problem in dcache. Please read
http://marc.info/?l=linux-fsdevel&m=140214911608925&w=2


For 3.16, please consider these patches.

- for vfs
[PATCH v2] vfs: get_next_ino(), never inum=0
http://marc.info/?l=linux-fsdevel&m=140128600801771&w=2

- for tmpfs
[RFC PATCH v4 0/2] tmpfs: manage the inode-number by IDR (performance measure)
http://marc.info/?l=linux-fsdevel&m=140197128021025&w=2
[RFC PATCH v4 1/2] tmpfs: manage the inode-number by IDR, signed int inum
http://marc.info/?l=linux-fsdevel&m=140197128321029&w=2
[RFC PATCH v4 2/2] tmpfs: refine a file handle for NFS-exporting
http://marc.info/?l=linux-fsdevel&m=140197128121026&w=2


J. R. Okajima

2014-06-11 01:10:40

by Al Viro

[permalink] [raw]
Subject: Re: Linux 3.15 .. and continuation of merge window

On Mon, Jun 09, 2014 at 12:30:34PM +0900, J. R. Okajima wrote:
>
> Linus Torvalds:
> > So I ended up doing an rc8 because I was a bit worried about some
> > last-minute dcache fixes, but it turns out that nobody seemed to even
> > notice those. We did have other issues during the week, though, so it
> :::
>
> I am afraid there is a problem in dcache. Please read
> http://marc.info/?l=linux-fsdevel&m=140214911608925&w=2

There is a problem, all right, but your fix doesn't really fix it - just
narrows the race window ;-/ I would really like to detach the bugger
as soon as __dentry_kill() removes it from the list of children, but
unfortunately NFS wants it to be still valid in ->d_iput() (BTW,
nfs_can_unlink() is doing something very odd -
parent = dget_parent(dentry);
if (parent == NULL)
goto out_free;
is pointless, since dget_parent() never returns NULL; what was that
check trying to accomplish?)

Your scenario isn't feasible as described, but something similar can
happen with *two* shrinkers racing - dirB might've ended up on one list,
with fileC looked up a bit later, ending up on another list right after
that. So the problem is real; unfortunately, DCACHE_DENTRY_KILLED might
have appeared right after we'd dropped ->d_lock.

So I suspect that the right fix is a bit trickier - in addition to check
on the fast path (i.e. when trylock gets us the lock on parent), we need
to
* get rcu_read_lock() before dropping ->d_lock.
* check if dentry is already doomed right after taking rcu_read_lock();
if not, any value we might see in ->d_parent afterwards will point to object
not freed until we drop rcu_read_lock.

IOW, something like the delta below. Comments?

PS: apologies for being MIA; caught some crap, spent the last week being
very unhappy ;-/ I'll send a pull request tomorrow morning.

diff --git a/fs/dcache.c b/fs/dcache.c
index be2bea8..65ec10f 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -532,10 +532,16 @@ static inline struct dentry *lock_parent(struct dentry *dentry)
struct dentry *parent = dentry->d_parent;
if (IS_ROOT(dentry))
return NULL;
+ if (unlikely((int)dentry->d_lockref.count < 0))
+ return NULL;
if (likely(spin_trylock(&parent->d_lock)))
return parent;
- spin_unlock(&dentry->d_lock);
rcu_read_lock();
+ if (unlikely((int)dentry->d_lockref.count < 0)) {
+ rcu_read_unlock();
+ return NULL;
+ }
+ spin_unlock(&dentry->d_lock);
again:
parent = ACCESS_ONCE(dentry->d_parent);
spin_lock(&parent->d_lock);

2014-06-11 09:33:04

by J. R. Okajima

[permalink] [raw]
Subject: Re: Linux 3.15 .. and continuation of merge window


Al Viro:
> So I suspect that the right fix is a bit trickier - in addition to check
> on the fast path (i.e. when trylock gets us the lock on parent), we need
> to
> * get rcu_read_lock() before dropping ->d_lock.
> * check if dentry is already doomed right after taking rcu_read_lock();
> if not, any value we might see in ->d_parent afterwards will point to object
> not freed until we drop rcu_read_lock.
>
> IOW, something like the delta below. Comments?

I will try testing later.
For now, as a comment before testing, the patch looks weird for me. It
checks d_lockref.count twice during d_lockref.lock held. It must be the
same result, isn't it? Or does it mean that denty can be handled by
lockref_mark_dead() even if d_lockref.lock is held?


J. R. Okajima

2014-06-11 12:30:26

by Al Viro

[permalink] [raw]
Subject: Re: Linux 3.15 .. and continuation of merge window

On Wed, Jun 11, 2014 at 06:32:58PM +0900, J. R. Okajima wrote:
>
> Al Viro:
> > So I suspect that the right fix is a bit trickier - in addition to check
> > on the fast path (i.e. when trylock gets us the lock on parent), we need
> > to
> > * get rcu_read_lock() before dropping ->d_lock.
> > * check if dentry is already doomed right after taking rcu_read_lock();
> > if not, any value we might see in ->d_parent afterwards will point to object
> > not freed until we drop rcu_read_lock.
> >
> > IOW, something like the delta below. Comments?
>
> I will try testing later.
> For now, as a comment before testing, the patch looks weird for me. It
> checks d_lockref.count twice during d_lockref.lock held. It must be the
> same result, isn't it?

Right you are. So what we need is
* check that thing once, as in your variant (I'd still prefer to
check ->d_lockref.count instead of ->d_flags, but it's the same thing being
tested)
* ... and get rcu_read_lock() *before* dropping ->d_lock.

The former guarantees that the address we are doing trylock on would be that
of a live dentry. The latter makes sure that anything assigned to
dentry->d_parent after we drop ->d_lock will not be freed until we drop
rcu_read_lock.

Signed-off-by: Al Viro <[email protected]>
---
diff --git a/fs/dcache.c b/fs/dcache.c
index be2bea8..e99c6f5 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -532,10 +532,12 @@ static inline struct dentry *lock_parent(struct dentry *dentry)
struct dentry *parent = dentry->d_parent;
if (IS_ROOT(dentry))
return NULL;
+ if (unlikely((int)dentry->d_lockref.count < 0))
+ return NULL;
if (likely(spin_trylock(&parent->d_lock)))
return parent;
- spin_unlock(&dentry->d_lock);
rcu_read_lock();
+ spin_unlock(&dentry->d_lock);
again:
parent = ACCESS_ONCE(dentry->d_parent);
spin_lock(&parent->d_lock);

2014-06-11 17:56:10

by J. R. Okajima

[permalink] [raw]
Subject: Re: Linux 3.15 .. and continuation of merge window


Al Viro:
> The former guarantees that the address we are doing trylock on would be that
> of a live dentry. The latter makes sure that anything assigned to
> dentry->d_parent after we drop ->d_lock will not be freed until we drop
> rcu_read_lock.

Although I don't know how to reproduce the problem for the latter case,
I think the patch is good.


J. R. Okajima