Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1575633 > unrolled thread

[PATCH 4.4 00/29] 4.4.48-stable review

Started byGreg Kroah-Hartman <gregkh@linuxfoundation.org>
First post2017-02-07 13:50 +0100
Last post2017-02-08 21:10 +0100
Articles 7 on this page of 27 — 4 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH 4.4 00/29] 4.4.48-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-07 13:50 +0100
    [PATCH 4.4 23/29] USB: serial: qcserial: add Dell DW5570 QDL Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-07 13:50 +0100
    [PATCH 4.4 13/29] svcrpc: fix oops in absence of krb5 module Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-07 13:50 +0100
    [PATCH 4.4 07/29] perf/core: Fix PERF_RECORD_MMAP2 prot/flags for anonymous memory Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-07 13:50 +0100
    [PATCH 4.4 29/29] base/memory, hotplug: fix a kernel oops in show_valid_zones() Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-07 13:50 +0100
    [PATCH 4.4 20/29] percpu-refcount: fix reference leak during percpu-atomic transition Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-07 13:50 +0100
    [PATCH 4.4 18/29] can: bcm: fix hrtimer/tasklet termination in bcm op removal Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-07 13:50 +0100
    [PATCH 4.4 24/29] USB: serial: pl2303: add ATEN device ID Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-07 13:50 +0100
    [PATCH 4.4 08/29] ata: sata_mv:- Handle return value of devm_ioremap. Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-07 13:50 +0100
    [PATCH 4.4 11/29] powerpc: Add missing error check to prom_find_boot_cpu() Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-07 13:50 +0100
    [PATCH 4.4 21/29] HID: wacom: Fix poor prox handling in wacom_pl_irq Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-07 13:50 +0100
    [PATCH 4.4 03/29] drm/nouveau/disp/gt215: Fix HDA ELD handling (thus, HDMI audio) on gt215 Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-07 13:50 +0100
    [PATCH 4.4 28/29] x86/irq: Make irq activate operations symmetric Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-07 13:50 +0100
    [PATCH 4.4 02/29] ext4: validate s_first_meta_bg at mount time Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-07 13:50 +0100
    [PATCH 4.4 15/29] cifs: initialize file_info_lock Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-07 13:50 +0100
    [PATCH 4.4 26/29] usb: gadget: f_fs: Assorted buffer overflow checks. Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-07 13:50 +0100
    [PATCH 4.4 04/29] drm/nouveau/nv1a,nv1f/disp: fix memory clock rate retrieval Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-07 13:50 +0100
    [PATCH 4.4 01/29] PCI/ASPM: Handle PCI-to-PCIe bridges as roots of PCIe hierarchies Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-07 14:00 +0100
    [PATCH 4.4 14/29] zswap: disable changing params if init fails Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-07 14:00 +0100
    [PATCH 4.4 16/29] mm/memory_hotplug.c: check start_pfn in test_pages_in_a_zone() Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-07 14:00 +0100
    [PATCH 4.4 12/29] NFSD: Fix a null reference case in find_or_create_lock_stateid() Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-07 14:00 +0100
    [PATCH 4.4 19/29] mmc: sdhci: Ignore unexpected CARD_INT interrupts Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-07 14:00 +0100
    Re: [PATCH 4.4 00/29] 4.4.48-stable review Shuah Khan <shuahkh@osg.samsung.com> - 2017-02-07 17:00 +0100
    Re: [PATCH 4.4 00/29] 4.4.48-stable review Guenter Roeck <linux@roeck-us.net> - 2017-02-07 22:50 +0100
    Re: [PATCH 4.4 00/29] 4.4.48-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-08 07:40 +0100
      Re: [PATCH 4.4 00/29] 4.4.48-stable review Kevin Hilman <khilman@baylibre.com> - 2017-02-08 20:50 +0100
        Re: [PATCH 4.4 00/29] 4.4.48-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-08 21:10 +0100

Page 2 of 2 — ← Prev page 1 [2]


#1575658 — [PATCH 4.4 12/29] NFSD: Fix a null reference case in find_or_create_lock_stateid()

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2017-02-07 14:00 +0100
Subject[PATCH 4.4 12/29] NFSD: Fix a null reference case in find_or_create_lock_stateid()
Message-ID<t8dxg-2Y8-17@gated-at.bofh.it>
In reply to#1575633
4.4-stable review patch.  If anyone has any objections, please let me know.

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

From: Kinglong Mee <kinglongmee@gmail.com>

commit d19fb70dd68c4e960e2ac09b0b9c79dfdeefa726 upstream.

nfsd assigns the nfs4_free_lock_stateid to .sc_free in init_lock_stateid().

If nfsd doesn't go through init_lock_stateid() and put stateid at end,
there is a NULL reference to .sc_free when calling nfs4_put_stid(ns).

This patch let the nfs4_stid.sc_free assignment to nfs4_alloc_stid().

Fixes: 356a95ece7aa "nfsd: clean up races in lock stateid searching..."
Signed-off-by: Kinglong Mee <kinglongmee@gmail.com>
Reviewed-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/nfsd/nfs4layouts.c |    5 +++--
 fs/nfsd/nfs4state.c   |   19 ++++++++-----------
 fs/nfsd/state.h       |    4 ++--
 3 files changed, 13 insertions(+), 15 deletions(-)

--- a/fs/nfsd/nfs4layouts.c
+++ b/fs/nfsd/nfs4layouts.c
@@ -189,10 +189,11 @@ nfsd4_alloc_layout_stateid(struct nfsd4_
 	struct nfs4_layout_stateid *ls;
 	struct nfs4_stid *stp;
 
-	stp = nfs4_alloc_stid(cstate->clp, nfs4_layout_stateid_cache);
+	stp = nfs4_alloc_stid(cstate->clp, nfs4_layout_stateid_cache,
+					nfsd4_free_layout_stateid);
 	if (!stp)
 		return NULL;
-	stp->sc_free = nfsd4_free_layout_stateid;
+
 	get_nfs4_file(fp);
 	stp->sc_file = fp;
 
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -553,8 +553,8 @@ out:
 	return co;
 }
 
-struct nfs4_stid *nfs4_alloc_stid(struct nfs4_client *cl,
-					 struct kmem_cache *slab)
+struct nfs4_stid *nfs4_alloc_stid(struct nfs4_client *cl, struct kmem_cache *slab,
+				  void (*sc_free)(struct nfs4_stid *))
 {
 	struct nfs4_stid *stid;
 	int new_id;
@@ -570,6 +570,8 @@ struct nfs4_stid *nfs4_alloc_stid(struct
 	idr_preload_end();
 	if (new_id < 0)
 		goto out_free;
+
+	stid->sc_free = sc_free;
 	stid->sc_client = cl;
 	stid->sc_stateid.si_opaque.so_id = new_id;
 	stid->sc_stateid.si_opaque.so_clid = cl->cl_clientid;
@@ -595,15 +597,12 @@ out_free:
 static struct nfs4_ol_stateid * nfs4_alloc_open_stateid(struct nfs4_client *clp)
 {
 	struct nfs4_stid *stid;
-	struct nfs4_ol_stateid *stp;
 
-	stid = nfs4_alloc_stid(clp, stateid_slab);
+	stid = nfs4_alloc_stid(clp, stateid_slab, nfs4_free_ol_stateid);
 	if (!stid)
 		return NULL;
 
-	stp = openlockstateid(stid);
-	stp->st_stid.sc_free = nfs4_free_ol_stateid;
-	return stp;
+	return openlockstateid(stid);
 }
 
 static void nfs4_free_deleg(struct nfs4_stid *stid)
@@ -701,11 +700,10 @@ alloc_init_deleg(struct nfs4_client *clp
 		goto out_dec;
 	if (delegation_blocked(&current_fh->fh_handle))
 		goto out_dec;
-	dp = delegstateid(nfs4_alloc_stid(clp, deleg_slab));
+	dp = delegstateid(nfs4_alloc_stid(clp, deleg_slab, nfs4_free_deleg));
 	if (dp == NULL)
 		goto out_dec;
 
-	dp->dl_stid.sc_free = nfs4_free_deleg;
 	/*
 	 * delegation seqid's are never incremented.  The 4.1 special
 	 * meaning of seqid 0 isn't meaningful, really, but let's avoid
@@ -5396,7 +5394,6 @@ init_lock_stateid(struct nfs4_ol_stateid
 	stp->st_stateowner = nfs4_get_stateowner(&lo->lo_owner);
 	get_nfs4_file(fp);
 	stp->st_stid.sc_file = fp;
-	stp->st_stid.sc_free = nfs4_free_lock_stateid;
 	stp->st_access_bmap = 0;
 	stp->st_deny_bmap = open_stp->st_deny_bmap;
 	stp->st_openstp = open_stp;
@@ -5439,7 +5436,7 @@ find_or_create_lock_stateid(struct nfs4_
 	lst = find_lock_stateid(lo, fi);
 	if (lst == NULL) {
 		spin_unlock(&clp->cl_lock);
-		ns = nfs4_alloc_stid(clp, stateid_slab);
+		ns = nfs4_alloc_stid(clp, stateid_slab, nfs4_free_lock_stateid);
 		if (ns == NULL)
 			return NULL;
 
--- a/fs/nfsd/state.h
+++ b/fs/nfsd/state.h
@@ -583,8 +583,8 @@ extern __be32 nfs4_preprocess_stateid_op
 __be32 nfsd4_lookup_stateid(struct nfsd4_compound_state *cstate,
 		     stateid_t *stateid, unsigned char typemask,
 		     struct nfs4_stid **s, struct nfsd_net *nn);
-struct nfs4_stid *nfs4_alloc_stid(struct nfs4_client *cl,
-		struct kmem_cache *slab);
+struct nfs4_stid *nfs4_alloc_stid(struct nfs4_client *cl, struct kmem_cache *slab,
+				  void (*sc_free)(struct nfs4_stid *));
 void nfs4_unhash_stid(struct nfs4_stid *s);
 void nfs4_put_stid(struct nfs4_stid *s);
 void nfs4_inc_and_copy_stateid(stateid_t *dst, struct nfs4_stid *stid);

[toc] | [prev] | [next] | [standalone]


#1575659 — [PATCH 4.4 19/29] mmc: sdhci: Ignore unexpected CARD_INT interrupts

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2017-02-07 14:00 +0100
Subject[PATCH 4.4 19/29] mmc: sdhci: Ignore unexpected CARD_INT interrupts
Message-ID<t8dxg-2Y8-19@gated-at.bofh.it>
In reply to#1575633
4.4-stable review patch.  If anyone has any objections, please let me know.

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

From: Gabriel Krisman Bertazi <krisman@collabora.co.uk>

commit 161e6d44a5e2d3f85365cb717d60e363171b39e6 upstream.

One of our kernelCI boxes hanged at boot because a faulty eSDHC device
was triggering spurious CARD_INT interrupts for SD cards, causing CMD52
reads, which are not allowed for SD devices.  This adds a sanity check
to the interruption path, preventing that illegal command from getting
sent if the CARD_INT interruption should be disabled.

This quirk allows that particular machine to resume boot despite the
faulty hardware, instead of getting hung dealing with thousands of
mishandled interrupts.

Suggested-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/mmc/host/sdhci.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2629,7 +2629,8 @@ static irqreturn_t sdhci_irq(int irq, vo
 			pr_err("%s: Card is consuming too much power!\n",
 				mmc_hostname(host->mmc));
 
-		if (intmask & SDHCI_INT_CARD_INT) {
+		if ((intmask & SDHCI_INT_CARD_INT) &&
+		    (host->ier & SDHCI_INT_CARD_INT)) {
 			sdhci_enable_sdio_irq_nolock(host, false);
 			host->thread_isr |= SDHCI_INT_CARD_INT;
 			result = IRQ_WAKE_THREAD;

[toc] | [prev] | [next] | [standalone]


#1575816

FromShuah Khan <shuahkh@osg.samsung.com>
Date2017-02-07 17:00 +0100
Message-ID<t8glr-4NN-7@gated-at.bofh.it>
In reply to#1575633
On 02/07/2017 05:45 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.48 release.
> There are 29 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 Thu Feb  9 12:44:43 UTC 2017.
> 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/v4.x/stable-review/patch-4.4.48-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

[toc] | [prev] | [next] | [standalone]


#1576086

FromGuenter Roeck <linux@roeck-us.net>
Date2017-02-07 22:50 +0100
Message-ID<t8lOa-8hG-27@gated-at.bofh.it>
In reply to#1575633
On Tue, Feb 07, 2017 at 01:45:29PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.48 release.
> There are 29 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 Thu Feb  9 12:44:43 UTC 2017.
> Anything received after that time might be too late.
> 

Build results:
	total: 149 pass: 149 fail: 0
Qemu test results:
	total: 115 pass: 115 fail: 0

Details are available at http://kerneltests.org/builders.

Thanks,
Guenter

[toc] | [prev] | [next] | [standalone]


#1576300

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2017-02-08 07:40 +0100
Message-ID<t8u53-5eB-13@gated-at.bofh.it>
In reply to#1575633
On Tue, Feb 07, 2017 at 05:27:32PM -0800, kernelci.org bot wrote:
> stable-rc boot: 517 boots: 0 failed, 498 passed with 19 offline (v4.4.47-30-gcd13c41318b2)

Why is there almost double the number of "passed" systems here compared
to 4.9?

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]


#1576987

FromKevin Hilman <khilman@baylibre.com>
Date2017-02-08 20:50 +0100
Message-ID<t8GpA-4sD-15@gated-at.bofh.it>
In reply to#1576300
Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:

> On Tue, Feb 07, 2017 at 05:27:32PM -0800, kernelci.org bot wrote:
>> stable-rc boot: 517 boots: 0 failed, 498 passed with 19 offline (v4.4.47-30-gcd13c41318b2)
>
> Why is there almost double the number of "passed" systems here compared
> to 4.9?

Mostly because our build systems are backlogged.

We want to reply to your stable review emails within a reasonable amount
of time, so we reply with the results that we've received, even though
some builds may have been delayed and/or some labs have not reported in
their results.

Kevin

[toc] | [prev] | [next] | [standalone]


#1577011

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2017-02-08 21:10 +0100
Message-ID<t8GIW-4OC-33@gated-at.bofh.it>
In reply to#1576987
On Wed, Feb 08, 2017 at 11:40:38AM -0800, Kevin Hilman wrote:
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
> 
> > On Tue, Feb 07, 2017 at 05:27:32PM -0800, kernelci.org bot wrote:
> >> stable-rc boot: 517 boots: 0 failed, 498 passed with 19 offline (v4.4.47-30-gcd13c41318b2)
> >
> > Why is there almost double the number of "passed" systems here compared
> > to 4.9?
> 
> Mostly because our build systems are backlogged.
> 
> We want to reply to your stable review emails within a reasonable amount
> of time, so we reply with the results that we've received, even though
> some builds may have been delayed and/or some labs have not reported in
> their results.

Ah, that makes sense, thanks for letting me know.  And for running this,
it's much appreciated.

greg k-h

[toc] | [prev] | [standalone]


Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel


csiph-web