Re: [PATCH 3.10 14/46] d_walk() might skip too much

Re: [PATCH 3.10 14/46] d_walk() might skip too much

[Jari Ruusu]

My understanding is that this patch is trying to fix bugs in this commit:

https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-3.10.y&id=5f03ac13d87590b0ee879c77e68df63a3d9b3e07

The 3.10.y branch applied the original patch to three different places.
Quote from original commit: "As we only have try_to_ascend() and not
d_walk(), apply this change to all callers of try_to_ascend()"

Shouldn't this "d_walk() might skip too much" fix to 3.10.y branch be
applied to all three places too?

-- 
Jari Ruusu  4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD  ACDF F073 3C80 8132 F189

Re: [PATCH 3.10 14/46] d_walk() might skip too much

[Jari Ruusu]

When Al Viro's VFS deadlock fix "deal with deadlock in d_walk()" was
backported to 3.10.y 3.4.y and 3.2.y stable kernel brances, the deadlock fix
was copied to 3 different places. Later, a bug in that code was discovered.
Al Viro's fix involved fixing only one part of code in mainline kernel. That
fix is called "d_walk() might skip too much".

3.10.y 3.4.y and 3.2.y stable kernel brances need that later fix copied to 3
different places. Greg Kroah-Hartman included Al Viro's "d_walk() might skip
too much" fix only once in 3.10.80 kernel, leaving 2 more places without a
fix.

The patch below was not written by me. I only applied Al Viro's "d_walk()
might skip too much" fix 2 more times to 3.10.80 kernel, and cheched that
the fixes went to correct places. With this patch applied, all 3 places that
I am aware of 3.10.y stable branch are now fixed.

Signed-off-by: Jari Ruusu <jariruusu@users.sourceforge.net>

--- linux-3.10.80/fs/dcache.c.OLD	2015-06-11 19:22:31.000000000 +0300
+++ linux-3.10.80/fs/dcache.c	2015-06-11 19:32:59.000000000 +0300
@@ -1053,13 +1053,13 @@
 		/* might go back up the wrong parent if we have had a rename. */
 		if (!locked && read_seqretry(&rename_lock, seq))
 			goto rename_retry;
-		next = child->d_child.next;
-		while (unlikely(child->d_flags & DCACHE_DENTRY_KILLED)) {
+		/* go into the first sibling still alive */
+		do {
+			next = child->d_child.next;
 			if (next == &this_parent->d_subdirs)
 				goto ascend;
 			child = list_entry(next, struct dentry, d_child);
-			next = next->next;
-		}
+		} while (unlikely(child->d_flags & DCACHE_DENTRY_KILLED));
 		rcu_read_unlock();
 		goto resume;
 	}
@@ -2977,13 +2977,13 @@
 		/* might go back up the wrong parent if we have had a rename. */
 		if (!locked && read_seqretry(&rename_lock, seq))
 			goto rename_retry;
-		next = child->d_child.next;
-		while (unlikely(child->d_flags & DCACHE_DENTRY_KILLED)) {
+		/* go into the first sibling still alive */
+		do {
+			next = child->d_child.next;
 			if (next == &this_parent->d_subdirs)
 				goto ascend;
 			child = list_entry(next, struct dentry, d_child);
-			next = next->next;
-		}
+		} while (unlikely(child->d_flags & DCACHE_DENTRY_KILLED));
 		rcu_read_unlock();
 		goto resume;
 	}

-- 
Jari Ruusu  4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD  ACDF F073 3C80 8132 F189

Re: [PATCH 3.10 14/46] d_walk() might skip too much

[Willy Tarreau]

Hi Jari,

On Sat, Jun 13, 2015 at 07:01:31PM +0300, Jari Ruusu wrote:
> When Al Viro's VFS deadlock fix "deal with deadlock in d_walk()" was
> backported to 3.10.y 3.4.y and 3.2.y stable kernel brances, the deadlock fix
> was copied to 3 different places. Later, a bug in that code was discovered.
> Al Viro's fix involved fixing only one part of code in mainline kernel. That
> fix is called "d_walk() might skip too much".
> 
> 3.10.y 3.4.y and 3.2.y stable kernel brances need that later fix copied to 3
> different places. Greg Kroah-Hartman included Al Viro's "d_walk() might skip
> too much" fix only once in 3.10.80 kernel, leaving 2 more places without a
> fix.
> 
> The patch below was not written by me. I only applied Al Viro's "d_walk()
> might skip too much" fix 2 more times to 3.10.80 kernel, and cheched that
> the fixes went to correct places. With this patch applied, all 3 places that
> I am aware of 3.10.y stable branch are now fixed.
> 
> Signed-off-by: Jari Ruusu <jariruusu@users.sourceforge.net>

Next time, please don't forget to mention the mainline commit IDs in
addition to the message subjects, it helps a lot. The IDs from the
stable branches are less important since it's generally quite easy
to find them thanks to the mainline ID which appears in the message.
Just for reference :

  - ca5358e ("deal with deadlock in d_walk()")
  - 2159184 ("d_walk() might skip too much")

Thanks,
Willy

Re: [PATCH 3.10 14/46] d_walk() might skip too much

[Greg Kroah-Hartman]

On Sat, Jun 13, 2015 at 07:11:18PM +0200, Willy Tarreau wrote:
> Hi Jari,
> 
> On Sat, Jun 13, 2015 at 07:01:31PM +0300, Jari Ruusu wrote:
> > When Al Viro's VFS deadlock fix "deal with deadlock in d_walk()" was
> > backported to 3.10.y 3.4.y and 3.2.y stable kernel brances, the deadlock fix
> > was copied to 3 different places. Later, a bug in that code was discovered.
> > Al Viro's fix involved fixing only one part of code in mainline kernel. That
> > fix is called "d_walk() might skip too much".
> > 
> > 3.10.y 3.4.y and 3.2.y stable kernel brances need that later fix copied to 3
> > different places. Greg Kroah-Hartman included Al Viro's "d_walk() might skip
> > too much" fix only once in 3.10.80 kernel, leaving 2 more places without a
> > fix.
> > 
> > The patch below was not written by me. I only applied Al Viro's "d_walk()
> > might skip too much" fix 2 more times to 3.10.80 kernel, and cheched that
> > the fixes went to correct places. With this patch applied, all 3 places that
> > I am aware of 3.10.y stable branch are now fixed.
> > 
> > Signed-off-by: Jari Ruusu <jariruusu@users.sourceforge.net>
> 
> Next time, please don't forget to mention the mainline commit IDs in
> addition to the message subjects, it helps a lot. The IDs from the
> stable branches are less important since it's generally quite easy
> to find them thanks to the mainline ID which appears in the message.
> Just for reference :
> 
>   - ca5358e ("deal with deadlock in d_walk()")
>   - 2159184 ("d_walk() might skip too much")

I would much rather just include the "real" upstream patches, instead of
an odd backport.

Jari, can you just backport the above referenced patches instead and
provide those backports?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3.10 14/46] d_walk() might skip too much

[Jari Ruusu]

On 6/19/15, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> I would much rather just include the "real" upstream patches, instead of
> an odd backport.
>
> Jari, can you just backport the above referenced patches instead and
> provide those backports?

I won't do that, sorry. It is more complicated than you think. It would
involve backporting more VFS-re-write-patch-bombs than would be acceptable
to stable kernel branch. Above mentioned d_walk() function that Al Viro
modified in mainline don't even exist in 3.10.y and older brances.

My understanding is that complete backport of above mentioned "deal with
deadlock in d_walk()" and "d_walk() might skip too much" patches to 3.10.y
branch is to apply all these patches:

(a) backport of "deal with deadlock in d_walk()", by Ben Hutchings
(b) dcache: Fix locking bugs in backported "deal with deadlock in d_walk()"
(c) Al Viro's "d_walk() might skip too much" applied THREE times.

Of those, you merged (a) and (b) to 3.10.76 stable, and one copy of (c) to
3.10.80 stable.

The problem is that you didn't realize that "deal with deadlock in d_walk()"
was applied to three different places in Ben Hutchings' backport, and that
latest Al Viro's fix had to be also applied to three different places.
Considering the sh*t that you have to deal with, nobody is blaming you for
that mistake.

I am asking that you apply Al Viro's original "d_walk() might skip too much"
patch TWO more times to 3.10.y stable branch. On both times, your patch tool
will find the correct place of source file to modify, but with different
offsets each time.

-- 
Jari Ruusu  4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD  ACDF F073 3C80 8132 F189
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3.10 14/46] d_walk() might skip too much

[Greg Kroah-Hartman]

On Sat, Jun 20, 2015 at 10:41:14AM +0300, Jari Ruusu wrote:
> On 6/19/15, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > I would much rather just include the "real" upstream patches, instead of
> > an odd backport.
> >
> > Jari, can you just backport the above referenced patches instead and
> > provide those backports?
> 
> I won't do that, sorry. It is more complicated than you think. It would
> involve backporting more VFS-re-write-patch-bombs than would be acceptable
> to stable kernel branch. Above mentioned d_walk() function that Al Viro
> modified in mainline don't even exist in 3.10.y and older brances.
> 
> My understanding is that complete backport of above mentioned "deal with
> deadlock in d_walk()" and "d_walk() might skip too much" patches to 3.10.y
> branch is to apply all these patches:
> 
> (a) backport of "deal with deadlock in d_walk()", by Ben Hutchings
> (b) dcache: Fix locking bugs in backported "deal with deadlock in d_walk()"
> (c) Al Viro's "d_walk() might skip too much" applied THREE times.
> 
> Of those, you merged (a) and (b) to 3.10.76 stable, and one copy of (c) to
> 3.10.80 stable.
> 
> The problem is that you didn't realize that "deal with deadlock in d_walk()"
> was applied to three different places in Ben Hutchings' backport, and that
> latest Al Viro's fix had to be also applied to three different places.
> Considering the sh*t that you have to deal with, nobody is blaming you for
> that mistake.
> 
> I am asking that you apply Al Viro's original "d_walk() might skip too much"
> patch TWO more times to 3.10.y stable branch. On both times, your patch tool
> will find the correct place of source file to modify, but with different
> offsets each time.

That's insane, and not how my tools work :(

Can you provide the needed backport?  If it was in an earlier email in
this series, sorry, it's long gone from my mailbox, can you resend it?

thanks,

greg k-h

Re: [PATCH 3.10 14/46] d_walk() might skip too much

[Willy Tarreau]

On Fri, Jun 26, 2015 at 05:52:16PM -0700, Greg Kroah-Hartman wrote:
> On Sat, Jun 20, 2015 at 10:41:14AM +0300, Jari Ruusu wrote:
> > On 6/19/15, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > > I would much rather just include the "real" upstream patches, instead of
> > > an odd backport.
> > >
> > > Jari, can you just backport the above referenced patches instead and
> > > provide those backports?
> > 
> > I won't do that, sorry. It is more complicated than you think. It would
> > involve backporting more VFS-re-write-patch-bombs than would be acceptable
> > to stable kernel branch. Above mentioned d_walk() function that Al Viro
> > modified in mainline don't even exist in 3.10.y and older brances.
> > 
> > My understanding is that complete backport of above mentioned "deal with
> > deadlock in d_walk()" and "d_walk() might skip too much" patches to 3.10.y
> > branch is to apply all these patches:
> > 
> > (a) backport of "deal with deadlock in d_walk()", by Ben Hutchings
> > (b) dcache: Fix locking bugs in backported "deal with deadlock in d_walk()"
> > (c) Al Viro's "d_walk() might skip too much" applied THREE times.
> > 
> > Of those, you merged (a) and (b) to 3.10.76 stable, and one copy of (c) to
> > 3.10.80 stable.
> > 
> > The problem is that you didn't realize that "deal with deadlock in d_walk()"
> > was applied to three different places in Ben Hutchings' backport, and that
> > latest Al Viro's fix had to be also applied to three different places.
> > Considering the sh*t that you have to deal with, nobody is blaming you for
> > that mistake.
> > 
> > I am asking that you apply Al Viro's original "d_walk() might skip too much"
> > patch TWO more times to 3.10.y stable branch. On both times, your patch tool
> > will find the correct place of source file to modify, but with different
> > offsets each time.
> 
> That's insane, and not how my tools work :(

No but I think it's just the patch command who found the proper location
because the context was identical. That's what happens to me all the time
with very old kernels, which is the reason why I must absolutely build
them before the preview otherwise I'm sure to deliver something that
doesn't even build :-)

> Can you provide the needed backport?  If it was in an earlier email in
> this series, sorry, it's long gone from my mailbox, can you resend it?

Yes it was in the thread earlier this month. I'm appending it below. The
following commits were referred to :
  - ca5358e ("deal with deadlock in d_walk()")                                  
  - 2159184 ("d_walk() might skip too much")                                    

Regards,
Willy

Date:	Sat, 13 Jun 2015 19:01:31 +0300
Subject: Re: [PATCH 3.10 14/46] d_walk() might skip too much
From: Jari Ruusu <jariruusu@users.sourceforge.net>

When Al Viro's VFS deadlock fix "deal with deadlock in d_walk()" was
backported to 3.10.y 3.4.y and 3.2.y stable kernel brances, the deadlock fix
was copied to 3 different places. Later, a bug in that code was discovered.
Al Viro's fix involved fixing only one part of code in mainline kernel. That
fix is called "d_walk() might skip too much".

3.10.y 3.4.y and 3.2.y stable kernel brances need that later fix copied to 3
different places. Greg Kroah-Hartman included Al Viro's "d_walk() might skip
too much" fix only once in 3.10.80 kernel, leaving 2 more places without a
fix.

The patch below was not written by me. I only applied Al Viro's "d_walk()
might skip too much" fix 2 more times to 3.10.80 kernel, and cheched that
the fixes went to correct places. With this patch applied, all 3 places that
I am aware of 3.10.y stable branch are now fixed.

Signed-off-by: Jari Ruusu <jariruusu@users.sourceforge.net>

--- linux-3.10.80/fs/dcache.c.OLD	2015-06-11 19:22:31.000000000 +0300
+++ linux-3.10.80/fs/dcache.c	2015-06-11 19:32:59.000000000 +0300
@@ -1053,13 +1053,13 @@
 		/* might go back up the wrong parent if we have had a rename. */
 		if (!locked && read_seqretry(&rename_lock, seq))
 			goto rename_retry;
-		next = child->d_child.next;
-		while (unlikely(child->d_flags & DCACHE_DENTRY_KILLED)) {
+		/* go into the first sibling still alive */
+		do {
+			next = child->d_child.next;
 			if (next == &this_parent->d_subdirs)
 				goto ascend;
 			child = list_entry(next, struct dentry, d_child);
-			next = next->next;
-		}
+		} while (unlikely(child->d_flags & DCACHE_DENTRY_KILLED));
 		rcu_read_unlock();
 		goto resume;
 	}
@@ -2977,13 +2977,13 @@
 		/* might go back up the wrong parent if we have had a rename. */
 		if (!locked && read_seqretry(&rename_lock, seq))
 			goto rename_retry;
-		next = child->d_child.next;
-		while (unlikely(child->d_flags & DCACHE_DENTRY_KILLED)) {
+		/* go into the first sibling still alive */
+		do {
+			next = child->d_child.next;
 			if (next == &this_parent->d_subdirs)
 				goto ascend;
 			child = list_entry(next, struct dentry, d_child);
-			next = next->next;
-		}
+		} while (unlikely(child->d_flags & DCACHE_DENTRY_KILLED));
 		rcu_read_unlock();
 		goto resume;
 	}

Re: [PATCH 3.10 14/46] d_walk() might skip too much

[Greg Kroah-Hartman]

On Sat, Jun 27, 2015 at 07:56:19AM +0200, Willy Tarreau wrote:
> On Fri, Jun 26, 2015 at 05:52:16PM -0700, Greg Kroah-Hartman wrote:
> > On Sat, Jun 20, 2015 at 10:41:14AM +0300, Jari Ruusu wrote:
> > > On 6/19/15, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > > > I would much rather just include the "real" upstream patches, instead of
> > > > an odd backport.
> > > >
> > > > Jari, can you just backport the above referenced patches instead and
> > > > provide those backports?
> > > 
> > > I won't do that, sorry. It is more complicated than you think. It would
> > > involve backporting more VFS-re-write-patch-bombs than would be acceptable
> > > to stable kernel branch. Above mentioned d_walk() function that Al Viro
> > > modified in mainline don't even exist in 3.10.y and older brances.
> > > 
> > > My understanding is that complete backport of above mentioned "deal with
> > > deadlock in d_walk()" and "d_walk() might skip too much" patches to 3.10.y
> > > branch is to apply all these patches:
> > > 
> > > (a) backport of "deal with deadlock in d_walk()", by Ben Hutchings
> > > (b) dcache: Fix locking bugs in backported "deal with deadlock in d_walk()"
> > > (c) Al Viro's "d_walk() might skip too much" applied THREE times.
> > > 
> > > Of those, you merged (a) and (b) to 3.10.76 stable, and one copy of (c) to
> > > 3.10.80 stable.
> > > 
> > > The problem is that you didn't realize that "deal with deadlock in d_walk()"
> > > was applied to three different places in Ben Hutchings' backport, and that
> > > latest Al Viro's fix had to be also applied to three different places.
> > > Considering the sh*t that you have to deal with, nobody is blaming you for
> > > that mistake.
> > > 
> > > I am asking that you apply Al Viro's original "d_walk() might skip too much"
> > > patch TWO more times to 3.10.y stable branch. On both times, your patch tool
> > > will find the correct place of source file to modify, but with different
> > > offsets each time.
> > 
> > That's insane, and not how my tools work :(
> 
> No but I think it's just the patch command who found the proper location
> because the context was identical. That's what happens to me all the time
> with very old kernels, which is the reason why I must absolutely build
> them before the preview otherwise I'm sure to deliver something that
> doesn't even build :-)
> 
> > Can you provide the needed backport?  If it was in an earlier email in
> > this series, sorry, it's long gone from my mailbox, can you resend it?
> 
> Yes it was in the thread earlier this month. I'm appending it below. The
> following commits were referred to :
>   - ca5358e ("deal with deadlock in d_walk()")                                  
>   - 2159184 ("d_walk() might skip too much")                                    

Ok, that's a mess, thanks for clearing it up for me, I've now included
this in the 3.10-stable kernel.

greg k-h

Re: [PATCH 3.10 14/46] d_walk() might skip too much

[Jari Ruusu]

On 6/27/15, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> That's insane, and not how my tools work :(

I asked you to do that apply-patch-two-more-times thing because I
assumed that you trust Al Viro's Signed-off-by more than you trust
my Signed-off-by.

> Can you provide the needed backport?  If it was in an earlier email in
> this series, sorry, it's long gone from my mailbox, can you resend it?

Willy Tarreau re-posted that patch to you yesterday.
No need for me to repeat that here.

-- 
Jari Ruusu  4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD  ACDF F073 3C80 8132 F189

[PATCH 3.10 00/46] 3.10.80-stable review

[Greg Kroah-Hartman]

This is the start of the stable review cycle for the 3.10.80 release.
There are 46 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Fri Jun  5 06:33:14 UTC 2015.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
	kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.10.80-rc1.gz
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Linux 3.10.80-rc1

Andrew Morton <akpm@linux-foundation.org>
    fs/binfmt_elf.c:load_elf_binary(): return -EINVAL on zero-length mappings

Sasha Levin <sasha.levin@oracle.com>
    vfs: read file_handle only once in handle_to_path

Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    ACPI / init: Fix the ordering of acpi_reserve_resources()

Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Input: elantech - fix semi-mt protocol for v3 HW

Larry Finger <Larry.Finger@lwfinger.net>
    rtlwifi: rtl8192cu: Fix kernel deadlock

NeilBrown <neilb@suse.de>
    md/raid5: don't record new size if resize_stripes fails.

Scott Mayhew <smayhew@redhat.com>
    svcrpc: fix potential GSSX_ACCEPT_SEC_CONTEXT decoding failures

Russell King <rmk+kernel@arm.linux.org.uk>
    ARM: fix missing syscall trace exit

Philippe Reynes <tremyfr@gmail.com>
    ARM: dts: imx27: only map 4 Kbyte for fec registers

Harald Freudenberger <freude@linux.vnet.ibm.com>
    crypto: s390/ghash - Fix incorrect ghash icv buffer handling.

Scott Branden <sbranden@broadcom.com>
    rt2x00: add new rt2800usb device DWA 130

Gabriele Mazzotta <gabriele.mzt@gmail.com>
    libata: Ignore spurious PHY event on LPM policy change

Gabriele Mazzotta <gabriele.mzt@gmail.com>
    libata: Add helper to determine when PHY events should be ignored

Eryu Guan <guaneryu@gmail.com>
    ext4: check for zero length extent explicitly

Dmitry Monakhov <dmonakhov@openvz.org>
    ext4: convert write_begin methods to stable_page_writes semantics

Ludovic Desroches <ludovic.desroches@atmel.com>
    mmc: atmel-mci: fix bad variable type for clkdiv

Anton Blanchard <anton@samba.org>
    powerpc: Align TOC to 256 bytes

Krzysztof Opasiak <k.opasiak@samsung.com>
    usb: gadget: configfs: Fix interfaces array NULL-termination

Hans de Goede <hdegoede@redhat.com>
    usb-storage: Add NO_WP_DETECT quirk for Lacie 059f:0651 devices

Mark Edwards <sonofaforester@gmail.com>
    USB: cp210x: add ID for KCF Technologies PRN device

Jason A. Donenfeld <Jason@zx2c4.com>
    USB: pl2303: Remove support for Samsung I330

Jason A. Donenfeld <Jason@zx2c4.com>
    USB: visor: Match I330 phone more precisely

Joe Lawrence <joe.lawrence@stratus.com>
    xhci: gracefully handle xhci_irq dead device

Mathias Nyman <mathias.nyman@linux.intel.com>
    xhci: Solve full event ring by increasing TRBS_PER_SEGMENT to 256

Mathias Nyman <mathias.nyman@linux.intel.com>
    xhci: fix isoc endpoint dequeue from advancing too far on transaction error

Andy Grover <agrover@redhat.com>
    target/pscsi: Don't leak scsi_host if hba is VIRTUAL_HOST

Zidan Wang <zidan.wang@freescale.com>
    ASoC: wm8994: correct BCLK DIV 348 to 384

Zidan Wang <zidan.wang@freescale.com>
    ASoC: wm8960: fix "RINPUT3" audio route error

Vasily Khoruzhick <anarsoul@gmail.com>
    ASoC: uda1380: Avoid accessing i2c bus when codec is disabled

Axel Lin <axel.lin@ingics.com>
    ASoC: mc13783: Fix wrong mask value used in mc13xxx_reg_rmw() calls

Takashi Iwai <tiwai@suse.de>
    ALSA: hda - Add headphone quirk for Lifebook E752

David Henningsson <david.henningsson@canonical.com>
    ALSA: hda - Add Conexant codecs CX20721, CX20722, CX20723 and CX20724

Al Viro <viro@zeniv.linux.org.uk>
    d_walk() might skip too much

Jan Kara <jack@suse.cz>
    lib: Fix strnlen_user() to not touch memory after specified maximum

Chris Lesiak <chris.lesiak@licor.com>
    hwmon: (ntc_thermistor) Ensure iio channel is of type IIO_VOLTAGE

Ilya Dryomov <idryomov@gmail.com>
    libceph: request a new osdmap if lingering request maps to no osd

Rusty Russell <rusty@rustcorp.com.au>
    lguest: fix out-by-one error in address checking.

Sasha Levin <sasha.levin@oracle.com>
    fs, omfs: add NULL terminator in the end up the token list

Paolo Bonzini <pbonzini@redhat.com>
    KVM: MMU: fix CR4.SMEP=1, CR0.WP=0 with shadow pages

Junling Zheng <zhengjunling@huawei.com>
    net: socket: Fix the wrong returns for recvmsg and sendmsg

Kirill A. Shutemov <kirill@shutemov.name>
    kernel: use the gnu89 standard explicitly

Behan Webster <behanw@converseincode.com>
    staging, rtl8192e, LLVMLinux: Remove unused inline prototype

Arnd Bergmann <arnd@arndb.de>
    staging: rtl8712, rtl8712: avoid lots of build warnings

Behan Webster <behanw@converseincode.com>
    staging, rtl8192e, LLVMLinux: Change extern inline to static inline

Jan-Simon Möller <dl9pf@gmx.de>
    drm/i915: Fix declaration of intel_gmbus_{is_forced_bit/is_port_falid}

Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    staging: wlags49_h2: fix extern inline functions


-------------

Diffstat:

 Makefile                                        | 10 ++++----
 arch/arm/boot/dts/imx27.dtsi                    |  2 +-
 arch/arm/kernel/entry-common.S                  |  4 +++-
 arch/powerpc/kernel/vmlinux.lds.S               |  1 +
 arch/s390/crypto/ghash_s390.c                   | 25 +++++++++----------
 arch/x86/kvm/mmu.c                              |  2 +-
 drivers/acpi/osl.c                              |  6 ++---
 drivers/ata/libahci.c                           |  3 +--
 drivers/ata/libata-core.c                       | 32 +++++++++++++++++++++++++
 drivers/ata/libata-eh.c                         |  3 +++
 drivers/gpu/drm/i915/i915_drv.h                 |  4 ++--
 drivers/hwmon/ntc_thermistor.c                  |  9 +++++++
 drivers/input/mouse/elantech.c                  |  2 +-
 drivers/lguest/core.c                           |  2 +-
 drivers/md/raid5.c                              |  3 ++-
 drivers/mmc/host/atmel-mci.c                    |  9 +++++--
 drivers/net/wireless/rt2x00/rt2800usb.c         |  1 +
 drivers/net/wireless/rtlwifi/usb.c              |  2 +-
 drivers/staging/rtl8187se/ieee80211/ieee80211.h |  4 ++--
 drivers/staging/rtl8192e/rtllib.h               |  5 ++--
 drivers/staging/rtl8192e/rtllib_softmac.c       |  2 +-
 drivers/staging/rtl8192u/ieee80211/ieee80211.h  | 10 ++++----
 drivers/staging/rtl8712/ieee80211.h             |  4 ++--
 drivers/staging/wlags49_h2/wl_internal.h        |  4 ++--
 drivers/target/target_core_pscsi.c              |  3 +++
 drivers/target/target_core_pscsi.h              |  1 +
 drivers/usb/gadget/configfs.c                   |  1 +
 drivers/usb/host/xhci-ring.c                    |  7 +++++-
 drivers/usb/host/xhci.h                         |  2 +-
 drivers/usb/serial/cp210x.c                     |  1 +
 drivers/usb/serial/pl2303.c                     |  1 -
 drivers/usb/serial/pl2303.h                     |  4 ----
 drivers/usb/serial/visor.c                      |  2 +-
 drivers/usb/storage/unusual_devs.h              |  7 ++++++
 fs/binfmt_elf.c                                 |  2 +-
 fs/dcache.c                                     |  8 +++----
 fs/ext4/extents.c                               |  2 +-
 fs/ext4/inode.c                                 |  5 ++--
 fs/fhandle.c                                    |  5 ++--
 fs/omfs/inode.c                                 |  3 ++-
 include/linux/libata.h                          | 10 ++++++++
 lib/strnlen_user.c                              |  3 ++-
 net/ceph/osd_client.c                           | 31 +++++++++++++++---------
 net/socket.c                                    | 24 ++++++++-----------
 net/sunrpc/auth_gss/gss_rpc_xdr.c               | 23 ++++++++++++------
 sound/pci/hda/patch_conexant.c                  | 12 ++++++++++
 sound/pci/hda/patch_realtek.c                   |  1 +
 sound/soc/codecs/mc13783.c                      |  4 ++--
 sound/soc/codecs/uda1380.c                      |  2 +-
 sound/soc/codecs/wm8960.c                       |  2 +-
 sound/soc/codecs/wm8994.c                       |  2 +-
 51 files changed, 212 insertions(+), 105 deletions(-)

[PATCH 3.10 14/46] d_walk() might skip too much

[Greg Kroah-Hartman]

3.10-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Al Viro <viro@zeniv.linux.org.uk>

commit 2159184ea01e4ae7d15f2017e296d4bc82d5aeb0 upstream.

when we find that a child has died while we'd been trying to ascend,
we should go into the first live sibling itself, rather than its sibling.

Off-by-one in question had been introduced in "deal with deadlock in
d_walk()" and the fix needs to be backported to all branches this one
has been backported to.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/dcache.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -1179,13 +1179,13 @@ ascend:
 		/* might go back up the wrong parent if we have had a rename. */
 		if (!locked && read_seqretry(&rename_lock, seq))
 			goto rename_retry;
-		next = child->d_child.next;
-		while (unlikely(child->d_flags & DCACHE_DENTRY_KILLED)) {
+		/* go into the first sibling still alive */
+		do {
+			next = child->d_child.next;
 			if (next == &this_parent->d_subdirs)
 				goto ascend;
 			child = list_entry(next, struct dentry, d_child);
-			next = next->next;
-		}
+		} while (unlikely(child->d_flags & DCACHE_DENTRY_KILLED));
 		rcu_read_unlock();
 		goto resume;
 	}