--- /dev/null
+From 3b7a45e5ba85dc79c7714edd9eee9aaed730cd6b Mon Sep 17 00:00:00 2001
+From: Joe Handzik <joseph.t.handzik@hp.com>
+Date: Thu, 8 May 2014 14:27:24 -0500
+Subject: hpsa: add new Smart Array PCI IDs (May 2014)
+
+From: Joe Handzik <joseph.t.handzik@hp.com>
+
+commit 3b7a45e5ba85dc79c7714edd9eee9aaed730cd6b upstream.
+
+Signed-off-by: Scott Teel <scott.teel@hp.com>
+Signed-off-by: Joe Handzik <joseph.t.handzik@hp.com>
+Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/hpsa.c | 12 ++++++++++++
+ 1 file changed, 12 insertions(+)
+
+--- a/drivers/scsi/hpsa.c
++++ b/drivers/scsi/hpsa.c
+@@ -115,9 +115,15 @@ static const struct pci_device_id hpsa_p
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21C3},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21C4},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21C5},
++ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21C6},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21C7},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21C8},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21C9},
++ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21CA},
++ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21CB},
++ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21CC},
++ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21CD},
++ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21CE},
+ {PCI_VENDOR_ID_HP_3PAR, 0x0075, 0x1590, 0x0076},
+ {PCI_VENDOR_ID_HP_3PAR, 0x0075, 0x1590, 0x0087},
+ {PCI_VENDOR_ID_HP_3PAR, 0x0075, 0x1590, 0x007D},
+@@ -165,9 +171,15 @@ static struct board_type products[] = {
+ {0x21C3103C, "Smart Array", &SA5_access},
+ {0x21C4103C, "Smart Array", &SA5_access},
+ {0x21C5103C, "Smart Array", &SA5_access},
++ {0x21C6103C, "Smart Array", &SA5_access},
+ {0x21C7103C, "Smart Array", &SA5_access},
+ {0x21C8103C, "Smart Array", &SA5_access},
+ {0x21C9103C, "Smart Array", &SA5_access},
++ {0x21CA103C, "Smart Array", &SA5_access},
++ {0x21CB103C, "Smart Array", &SA5_access},
++ {0x21CC103C, "Smart Array", &SA5_access},
++ {0x21CD103C, "Smart Array", &SA5_access},
++ {0x21CE103C, "Smart Array", &SA5_access},
+ {0x00761590, "HP Storage P1224 Array Controller", &SA5_access},
+ {0x00871590, "HP Storage P1224e Array Controller", &SA5_access},
+ {0x007D1590, "HP Storage P1228 Array Controller", &SA5_access},
--- /dev/null
+From bde92cf455a03a91badb7046855592d8c008e929 Mon Sep 17 00:00:00 2001
+From: Don Zickus <dzickus@redhat.com>
+Date: Mon, 23 Jun 2014 13:22:03 -0700
+Subject: kernel/watchdog.c: remove preemption restrictions when restarting lockup detector
+
+From: Don Zickus <dzickus@redhat.com>
+
+commit bde92cf455a03a91badb7046855592d8c008e929 upstream.
+
+Peter Wu noticed the following splat on his machine when updating
+/proc/sys/kernel/watchdog_thresh:
+
+ BUG: sleeping function called from invalid context at mm/slub.c:965
+ in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: init
+ 3 locks held by init/1:
+ #0: (sb_writers#3){.+.+.+}, at: [<ffffffff8117b663>] vfs_write+0x143/0x180
+ #1: (watchdog_proc_mutex){+.+.+.}, at: [<ffffffff810e02d3>] proc_dowatchdog+0x33/0x110
+ #2: (cpu_hotplug.lock){.+.+.+}, at: [<ffffffff810589c2>] get_online_cpus+0x32/0x80
+ Preemption disabled at:[<ffffffff810e0384>] proc_dowatchdog+0xe4/0x110
+
+ CPU: 0 PID: 1 Comm: init Not tainted 3.16.0-rc1-testing #34
+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
+ Call Trace:
+ dump_stack+0x4e/0x7a
+ __might_sleep+0x11d/0x190
+ kmem_cache_alloc_trace+0x4e/0x1e0
+ perf_event_alloc+0x55/0x440
+ perf_event_create_kernel_counter+0x26/0xe0
+ watchdog_nmi_enable+0x75/0x140
+ update_timers_all_cpus+0x53/0xa0
+ proc_dowatchdog+0xe4/0x110
+ proc_sys_call_handler+0xb3/0xc0
+ proc_sys_write+0x14/0x20
+ vfs_write+0xad/0x180
+ SyS_write+0x49/0xb0
+ system_call_fastpath+0x16/0x1b
+ NMI watchdog: disabled (cpu0): hardware events not enabled
+
+What happened is after updating the watchdog_thresh, the lockup detector
+is restarted to utilize the new value. Part of this process involved
+disabling preemption. Once preemption was disabled, perf tried to
+allocate a new event (as part of the restart). This caused the above
+BUG_ON as you can't sleep with preemption disabled.
+
+The preemption restriction seemed agressive as we are not doing anything
+on that particular cpu, but with all the online cpus (which are
+protected by the get_online_cpus lock). Remove the restriction and the
+BUG_ON goes away.
+
+Signed-off-by: Don Zickus <dzickus@redhat.com>
+Acked-by: Michal Hocko <mhocko@suse.cz>
+Reported-by: Peter Wu <peter@lekensteyn.nl>
+Tested-by: Peter Wu <peter@lekensteyn.nl>
+Acked-by: David Rientjes <rientjes@google.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/watchdog.c | 2 --
+ 1 file changed, 2 deletions(-)
+
+--- a/kernel/watchdog.c
++++ b/kernel/watchdog.c
+@@ -527,10 +527,8 @@ static void update_timers_all_cpus(void)
+ int cpu;
+
+ get_online_cpus();
+- preempt_disable();
+ for_each_online_cpu(cpu)
+ update_timers(cpu);
+- preempt_enable();
+ put_online_cpus();
+ }
+
--- /dev/null
+From b7dfa8895f64ffa371d0ed09c1d1ba8c6e19b956 Mon Sep 17 00:00:00 2001
+From: Yann Droneaud <ydroneaud@opteya.com>
+Date: Mon, 5 May 2014 19:35:26 +0200
+Subject: RDMA/cxgb4: add missing padding at end of struct c4iw_alloc_ucontext_resp
+
+From: Yann Droneaud <ydroneaud@opteya.com>
+
+commit b7dfa8895f64ffa371d0ed09c1d1ba8c6e19b956 upstream.
+
+The i386 ABI disagrees with most other ABIs regarding alignment of
+data types larger than 4 bytes: on most ABIs a padding must be added
+at end of the structures, while it is not required on i386.
+
+So for most ABI struct c4iw_alloc_ucontext_resp gets implicitly padded
+to be aligned on a 8 bytes multiple, while for i386, such padding is
+not added.
+
+The tool pahole can be used to find such implicit padding:
+
+ $ pahole --anon_include \
+ --nested_anon_include \
+ --recursive \
+ --class_name c4iw_alloc_ucontext_resp \
+ drivers/infiniband/hw/cxgb4/iw_cxgb4.o
+
+Then, structure layout can be compared between i386 and x86_64:
+
+# +++ obj-i386/drivers/infiniband/hw/cxgb4/iw_cxgb4.o.pahole.txt 2014-03-28 11:43:05.547432195 +0100
+# --- obj-x86_64/drivers/infiniband/hw/cxgb4/iw_cxgb4.o.pahole.txt 2014-03-28 10:55:10.990133017 +0100
+# @@ -2,9 +2,8 @@ struct c4iw_alloc_ucontext_resp {
+# __u64 status_page_key; /* 0 8 */
+# __u32 status_page_size; /* 8 4 */
+#
+# - /* size: 12, cachelines: 1, members: 2 */
+# - /* last cacheline: 12 bytes */
+# + /* size: 16, cachelines: 1, members: 2 */
+# + /* padding: 4 */
+# + /* last cacheline: 16 bytes */
+# };
+
+This ABI disagreement will make an x86_64 kernel try to write past the
+buffer provided by an i386 binary.
+
+When boundary check will be implemented, the x86_64 kernel will refuse
+to write past the i386 userspace provided buffer and the uverbs will
+fail.
+
+If the structure is on a page boundary and the next page is not
+mapped, ib_copy_to_udata() will fail and the uverb will fail.
+
+Additionally, as reported by Dan Carpenter, without the implicit
+padding being properly cleared, an information leak would take place
+in most architectures.
+
+This patch adds an explicit padding to struct c4iw_alloc_ucontext_resp,
+and, like 92b0ca7cb149 ("IB/mlx5: Fix stack info leak in
+mlx5_ib_alloc_ucontext()"), makes function c4iw_alloc_ucontext()
+not writting this padding field to userspace. This way, x86_64 kernel
+will be able to write struct c4iw_alloc_ucontext_resp as expected by
+unpatched and patched i386 libcxgb4.
+
+Link: http://marc.info/?i=cover.1399309513.git.ydroneaud@opteya.com
+Link: http://marc.info/?i=1395848977.3297.15.camel@localhost.localdomain
+Link: http://marc.info/?i=20140328082428.GH25192@mwanda
+Cc: <stable@vger.kernel.org>
+Fixes: 05eb23893c2c ("cxgb4/iw_cxgb4: Doorbell Drop Avoidance Bug Fixes")
+Reported-by: Yann Droneaud <ydroneaud@opteya.com>
+Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
+Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
+Acked-by: Steve Wise <swise@opengridcomputing.com>
+Signed-off-by: Roland Dreier <roland@purestorage.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/infiniband/hw/cxgb4/provider.c | 5 +++--
+ drivers/infiniband/hw/cxgb4/user.h | 1 +
+ 2 files changed, 4 insertions(+), 2 deletions(-)
+
+--- a/drivers/infiniband/hw/cxgb4/provider.c
++++ b/drivers/infiniband/hw/cxgb4/provider.c
+@@ -122,7 +122,7 @@ static struct ib_ucontext *c4iw_alloc_uc
+ INIT_LIST_HEAD(&context->mmaps);
+ spin_lock_init(&context->mmap_lock);
+
+- if (udata->outlen < sizeof(uresp)) {
++ if (udata->outlen < sizeof(uresp) - sizeof(uresp.reserved)) {
+ if (!warned++)
+ pr_err(MOD "Warning - downlevel libcxgb4 (non-fatal), device status page disabled.");
+ rhp->rdev.flags |= T4_STATUS_PAGE_DISABLED;
+@@ -140,7 +140,8 @@ static struct ib_ucontext *c4iw_alloc_uc
+ context->key += PAGE_SIZE;
+ spin_unlock(&context->mmap_lock);
+
+- ret = ib_copy_to_udata(udata, &uresp, sizeof(uresp));
++ ret = ib_copy_to_udata(udata, &uresp,
++ sizeof(uresp) - sizeof(uresp.reserved));
+ if (ret)
+ goto err_mm;
+
+--- a/drivers/infiniband/hw/cxgb4/user.h
++++ b/drivers/infiniband/hw/cxgb4/user.h
+@@ -75,5 +75,6 @@ struct c4iw_create_qp_resp {
+ struct c4iw_alloc_ucontext_resp {
+ __u64 status_page_key;
+ __u32 status_page_size;
++ __u32 reserved; /* explicit padding (optional for i386) */
+ };
+ #endif
--- /dev/null
+From b6f04d3d21458818073a2f5af5339f958864bf71 Mon Sep 17 00:00:00 2001
+From: Yann Droneaud <ydroneaud@opteya.com>
+Date: Mon, 5 May 2014 19:33:23 +0200
+Subject: RDMA/cxgb4: Add missing padding at end of struct c4iw_create_cq_resp
+
+From: Yann Droneaud <ydroneaud@opteya.com>
+
+commit b6f04d3d21458818073a2f5af5339f958864bf71 upstream.
+
+The i386 ABI disagrees with most other ABIs regarding alignment of
+data types larger than 4 bytes: on most ABIs a padding must be added
+at end of the structures, while it is not required on i386.
+
+So for most ABI struct c4iw_create_cq_resp gets implicitly padded
+to be aligned on a 8 bytes multiple, while for i386, such padding
+is not added.
+
+The tool pahole can be used to find such implicit padding:
+
+ $ pahole --anon_include \
+ --nested_anon_include \
+ --recursive \
+ --class_name c4iw_create_cq_resp \
+ drivers/infiniband/hw/cxgb4/iw_cxgb4.o
+
+Then, structure layout can be compared between i386 and x86_64:
+
+# +++ obj-i386/drivers/infiniband/hw/cxgb4/iw_cxgb4.o.pahole.txt 2014-03-28 11:43:05.547432195 +0100
+# --- obj-x86_64/drivers/infiniband/hw/cxgb4/iw_cxgb4.o.pahole.txt 2014-03-28 10:55:10.990133017 +0100
+# @@ -14,9 +13,8 @@ struct c4iw_create_cq_resp {
+# __u32 size; /* 28 4 */
+# __u32 qid_mask; /* 32 4 */
+#
+# - /* size: 36, cachelines: 1, members: 6 */
+# - /* last cacheline: 36 bytes */
+# + /* size: 40, cachelines: 1, members: 6 */
+# + /* padding: 4 */
+# + /* last cacheline: 40 bytes */
+# };
+
+This ABI disagreement will make an x86_64 kernel try to write past the
+buffer provided by an i386 binary.
+
+When boundary check will be implemented, the x86_64 kernel will refuse
+to write past the i386 userspace provided buffer and the uverbs will
+fail.
+
+If the structure is on a page boundary and the next page is not
+mapped, ib_copy_to_udata() will fail and the uverb will fail.
+
+This patch adds an explicit padding at end of structure
+c4iw_create_cq_resp, and, like 92b0ca7cb149 ("IB/mlx5: Fix stack info
+leak in mlx5_ib_alloc_ucontext()"), makes function c4iw_create_cq()
+not writting this padding field to userspace. This way, x86_64 kernel
+will be able to write struct c4iw_create_cq_resp as expected by
+unpatched and patched i386 libcxgb4.
+
+Link: http://marc.info/?i=cover.1399309513.git.ydroneaud@opteya.com
+Fixes: cfdda9d764362 ("RDMA/cxgb4: Add driver for Chelsio T4 RNIC")
+Fixes: e24a72a3302a6 ("RDMA/cxgb4: Fix four byte info leak in c4iw_create_cq()")
+Cc: Dan Carpenter <dan.carpenter@oracle.com>
+Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
+Acked-by: Steve Wise <swise@opengridcomputing.com>
+Signed-off-by: Roland Dreier <roland@purestorage.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/infiniband/hw/cxgb4/cq.c | 4 ++--
+ drivers/infiniband/hw/cxgb4/user.h | 1 +
+ 2 files changed, 3 insertions(+), 2 deletions(-)
+
+--- a/drivers/infiniband/hw/cxgb4/cq.c
++++ b/drivers/infiniband/hw/cxgb4/cq.c
+@@ -940,7 +940,6 @@ struct ib_cq *c4iw_create_cq(struct ib_d
+ if (!mm2)
+ goto err4;
+
+- memset(&uresp, 0, sizeof(uresp));
+ uresp.qid_mask = rhp->rdev.cqmask;
+ uresp.cqid = chp->cq.cqid;
+ uresp.size = chp->cq.size;
+@@ -951,7 +950,8 @@ struct ib_cq *c4iw_create_cq(struct ib_d
+ uresp.gts_key = ucontext->key;
+ ucontext->key += PAGE_SIZE;
+ spin_unlock(&ucontext->mmap_lock);
+- ret = ib_copy_to_udata(udata, &uresp, sizeof uresp);
++ ret = ib_copy_to_udata(udata, &uresp,
++ sizeof(uresp) - sizeof(uresp.reserved));
+ if (ret)
+ goto err5;
+
+--- a/drivers/infiniband/hw/cxgb4/user.h
++++ b/drivers/infiniband/hw/cxgb4/user.h
+@@ -48,6 +48,7 @@ struct c4iw_create_cq_resp {
+ __u32 cqid;
+ __u32 size;
+ __u32 qid_mask;
++ __u32 reserved; /* explicit padding (optional for i386) */
+ };
+
+
--- /dev/null
+From 65b302ad31b02b0790417f4e65833af494cb35ce Mon Sep 17 00:00:00 2001
+From: Christoph Jaeger <christophjaeger@linux.com>
+Date: Mon, 21 Apr 2014 17:02:42 +0200
+Subject: RDMA/cxgb4: Fix memory leaks in c4iw_alloc() error paths
+
+From: Christoph Jaeger <christophjaeger@linux.com>
+
+commit 65b302ad31b02b0790417f4e65833af494cb35ce upstream.
+
+c4iw_alloc() bails out without freeing the storage that 'devp' points to.
+
+Picked up by Coverity - CID 1204241.
+
+Fixes: fa658a98a2 ("RDMA/cxgb4: Use the BAR2/WC path for kernel QPs and T5 devices")
+Signed-off-by: Christoph Jaeger <christophjaeger@linux.com>
+Acked-by: Steve Wise <swise@opengridcomputing.com>
+Signed-off-by: Roland Dreier <roland@purestorage.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/infiniband/hw/cxgb4/device.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/infiniband/hw/cxgb4/device.c
++++ b/drivers/infiniband/hw/cxgb4/device.c
+@@ -736,6 +736,7 @@ static struct c4iw_dev *c4iw_alloc(const
+ pci_resource_len(devp->rdev.lldi.pdev, 2));
+ if (!devp->rdev.bar2_kva) {
+ pr_err(MOD "Unable to ioremap BAR2\n");
++ ib_dealloc_device(&devp->ibdev);
+ return ERR_PTR(-EINVAL);
+ }
+ } else if (ocqp_supported(infop)) {
+@@ -747,6 +748,7 @@ static struct c4iw_dev *c4iw_alloc(const
+ devp->rdev.lldi.vr->ocq.size);
+ if (!devp->rdev.oc_mw_kva) {
+ pr_err(MOD "Unable to ioremap onchip mem\n");
++ ib_dealloc_device(&devp->ibdev);
+ return ERR_PTR(-EINVAL);
+ }
+ }
recordmcount-mips-fix-possible-incorrect-mcount_loc-table-entries-in-modules.patch
revert-mips-save-restore-msa-context-around-signals.patch
mips-msc-prevent-out-of-bounds-writes-to-mips-sc-ioremap-d-region.patch
+hpsa-add-new-smart-array-pci-ids-may-2014.patch
+ubifs-fix-an-mmap-and-fsync-race-condition.patch
+ubifs-remove-incorrect-assertion-in-shrink_tnc.patch
+rdma-cxgb4-fix-memory-leaks-in-c4iw_alloc-error-paths.patch
+rdma-cxgb4-add-missing-padding-at-end-of-struct-c4iw_create_cq_resp.patch
+rdma-cxgb4-add-missing-padding-at-end-of-struct-c4iw_alloc_ucontext_resp.patch
+watchdog-sp805-set-watchdog_device-timeout-from-set_timeout.patch
+watchdog-ath79_wdt-avoid-spurious-restarts-on-ar934x.patch
+watchdog-kempld-wdt-use-the-correct-value-when-configuring-the-prescaler-with-the-watchdog.patch
+kernel-watchdog.c-remove-preemption-restrictions-when-restarting-lockup-detector.patch
--- /dev/null
+From 691a7c6f28ac90cccd0dbcf81348ea90b211bdd0 Mon Sep 17 00:00:00 2001
+From: hujianyang <hujianyang@huawei.com>
+Date: Wed, 30 Apr 2014 14:06:06 +0800
+Subject: UBIFS: fix an mmap and fsync race condition
+
+From: hujianyang <hujianyang@huawei.com>
+
+commit 691a7c6f28ac90cccd0dbcf81348ea90b211bdd0 upstream.
+
+There is a race condition in UBIFS:
+
+Thread A (mmap) Thread B (fsync)
+
+->__do_fault ->write_cache_pages
+ -> ubifs_vm_page_mkwrite
+ -> budget_space
+ -> lock_page
+ -> release/convert_page_budget
+ -> SetPagePrivate
+ -> TestSetPageDirty
+ -> unlock_page
+ -> lock_page
+ -> TestClearPageDirty
+ -> ubifs_writepage
+ -> do_writepage
+ -> release_budget
+ -> ClearPagePrivate
+ -> unlock_page
+ -> !(ret & VM_FAULT_LOCKED)
+ -> lock_page
+ -> set_page_dirty
+ -> ubifs_set_page_dirty
+ -> TestSetPageDirty (set page dirty without budgeting)
+ -> unlock_page
+
+This leads to situation where we have a diry page but no budget allocated for
+this page, so further write-back may fail with -ENOSPC.
+
+In this fix we return from page_mkwrite without performing unlock_page. We
+return VM_FAULT_LOCKED instead. After doing this, the race above will not
+happen.
+
+Signed-off-by: hujianyang <hujianyang@huawei.com>
+Tested-by: Laurence Withers <lwithers@guralp.com>
+Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ubifs/file.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/fs/ubifs/file.c
++++ b/fs/ubifs/file.c
+@@ -1525,8 +1525,7 @@ static int ubifs_vm_page_mkwrite(struct
+ }
+
+ wait_for_stable_page(page);
+- unlock_page(page);
+- return 0;
++ return VM_FAULT_LOCKED;
+
+ out_unlock:
+ unlock_page(page);
--- /dev/null
+From 72abc8f4b4e8574318189886de627a2bfe6cd0da Mon Sep 17 00:00:00 2001
+From: hujianyang <hujianyang@huawei.com>
+Date: Sat, 31 May 2014 11:39:32 +0800
+Subject: UBIFS: Remove incorrect assertion in shrink_tnc()
+
+From: hujianyang <hujianyang@huawei.com>
+
+commit 72abc8f4b4e8574318189886de627a2bfe6cd0da upstream.
+
+I hit the same assert failed as Dolev Raviv reported in Kernel v3.10
+shows like this:
+
+[ 9641.164028] UBIFS assert failed in shrink_tnc at 131 (pid 13297)
+[ 9641.234078] CPU: 1 PID: 13297 Comm: mmap.test Tainted: G O 3.10.40 #1
+[ 9641.234116] [<c0011a6c>] (unwind_backtrace+0x0/0x12c) from [<c000d0b0>] (show_stack+0x20/0x24)
+[ 9641.234137] [<c000d0b0>] (show_stack+0x20/0x24) from [<c0311134>] (dump_stack+0x20/0x28)
+[ 9641.234188] [<c0311134>] (dump_stack+0x20/0x28) from [<bf22425c>] (shrink_tnc_trees+0x25c/0x350 [ubifs])
+[ 9641.234265] [<bf22425c>] (shrink_tnc_trees+0x25c/0x350 [ubifs]) from [<bf2245ac>] (ubifs_shrinker+0x25c/0x310 [ubifs])
+[ 9641.234307] [<bf2245ac>] (ubifs_shrinker+0x25c/0x310 [ubifs]) from [<c00cdad8>] (shrink_slab+0x1d4/0x2f8)
+[ 9641.234327] [<c00cdad8>] (shrink_slab+0x1d4/0x2f8) from [<c00d03d0>] (do_try_to_free_pages+0x300/0x544)
+[ 9641.234344] [<c00d03d0>] (do_try_to_free_pages+0x300/0x544) from [<c00d0a44>] (try_to_free_pages+0x2d0/0x398)
+[ 9641.234363] [<c00d0a44>] (try_to_free_pages+0x2d0/0x398) from [<c00c6a60>] (__alloc_pages_nodemask+0x494/0x7e8)
+[ 9641.234382] [<c00c6a60>] (__alloc_pages_nodemask+0x494/0x7e8) from [<c00f62d8>] (new_slab+0x78/0x238)
+[ 9641.234400] [<c00f62d8>] (new_slab+0x78/0x238) from [<c031081c>] (__slab_alloc.constprop.42+0x1a4/0x50c)
+[ 9641.234419] [<c031081c>] (__slab_alloc.constprop.42+0x1a4/0x50c) from [<c00f80e8>] (kmem_cache_alloc_trace+0x54/0x188)
+[ 9641.234459] [<c00f80e8>] (kmem_cache_alloc_trace+0x54/0x188) from [<bf227908>] (do_readpage+0x168/0x468 [ubifs])
+[ 9641.234553] [<bf227908>] (do_readpage+0x168/0x468 [ubifs]) from [<bf2296a0>] (ubifs_readpage+0x424/0x464 [ubifs])
+[ 9641.234606] [<bf2296a0>] (ubifs_readpage+0x424/0x464 [ubifs]) from [<c00c17c0>] (filemap_fault+0x304/0x418)
+[ 9641.234638] [<c00c17c0>] (filemap_fault+0x304/0x418) from [<c00de694>] (__do_fault+0xd4/0x530)
+[ 9641.234665] [<c00de694>] (__do_fault+0xd4/0x530) from [<c00e10c0>] (handle_pte_fault+0x480/0xf54)
+[ 9641.234690] [<c00e10c0>] (handle_pte_fault+0x480/0xf54) from [<c00e2bf8>] (handle_mm_fault+0x140/0x184)
+[ 9641.234716] [<c00e2bf8>] (handle_mm_fault+0x140/0x184) from [<c0316688>] (do_page_fault+0x150/0x3ac)
+[ 9641.234737] [<c0316688>] (do_page_fault+0x150/0x3ac) from [<c000842c>] (do_DataAbort+0x3c/0xa0)
+[ 9641.234759] [<c000842c>] (do_DataAbort+0x3c/0xa0) from [<c0314e38>] (__dabt_usr+0x38/0x40)
+
+After analyzing the code, I found a condition that may cause this failed
+in correct operations. Thus, I think this assertion is wrong and should be
+removed.
+
+Suppose there are two clean znodes and one dirty znode in TNC. So the
+per-filesystem atomic_t @clean_zn_cnt is (2). If commit start, dirty_znode
+is set to COW_ZNODE in get_znodes_to_commit() in case of potentially ops
+on this znode. We clear COW bit and DIRTY bit in write_index() without
+@tnc_mutex locked. We don't increase @clean_zn_cnt in this place. As the
+comments in write_index() shows, if another process hold @tnc_mutex and
+dirty this znode after we clean it, @clean_zn_cnt would be decreased to (1).
+We will increase @clean_zn_cnt to (2) with @tnc_mutex locked in
+free_obsolete_znodes() to keep it right.
+
+If shrink_tnc() performs between decrease and increase, it will release
+other 2 clean znodes it holds and found @clean_zn_cnt is less than zero
+(1 - 2 = -1), then hit the assertion. Because free_obsolete_znodes() will
+soon correct @clean_zn_cnt and no harm to fs in this case, I think this
+assertion could be removed.
+
+2 clean zondes and 1 dirty znode, @clean_zn_cnt == 2
+
+Thread A (commit) Thread B (write or others) Thread C (shrinker)
+->write_index
+ ->clear_bit(DIRTY_NODE)
+ ->clear_bit(COW_ZNODE)
+
+ @clean_zn_cnt == 2
+ ->mutex_locked(&tnc_mutex)
+ ->dirty_cow_znode
+ ->!ubifs_zn_cow(znode)
+ ->!test_and_set_bit(DIRTY_NODE)
+ ->atomic_dec(&clean_zn_cnt)
+ ->mutex_unlocked(&tnc_mutex)
+
+ @clean_zn_cnt == 1
+ ->mutex_locked(&tnc_mutex)
+ ->shrink_tnc
+ ->destroy_tnc_subtree
+ ->atomic_sub(&clean_zn_cnt, 2)
+ ->ubifs_assert <- hit
+ ->mutex_unlocked(&tnc_mutex)
+
+ @clean_zn_cnt == -1
+->mutex_lock(&tnc_mutex)
+->free_obsolete_znodes
+ ->atomic_inc(&clean_zn_cnt)
+->mutux_unlock(&tnc_mutex)
+
+ @clean_zn_cnt == 0 (correct after shrink)
+
+Signed-off-by: hujianyang <hujianyang@huawei.com>
+Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ubifs/shrinker.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/fs/ubifs/shrinker.c
++++ b/fs/ubifs/shrinker.c
+@@ -128,7 +128,6 @@ static int shrink_tnc(struct ubifs_info
+ freed = ubifs_destroy_tnc_subtree(znode);
+ atomic_long_sub(freed, &ubifs_clean_zn_cnt);
+ atomic_long_sub(freed, &c->clean_zn_cnt);
+- ubifs_assert(atomic_long_read(&c->clean_zn_cnt) >= 0);
+ total_freed += freed;
+ znode = zprev;
+ }
--- /dev/null
+From 23afeb613ec0e10aecfae7838a14d485db62ac52 Mon Sep 17 00:00:00 2001
+From: Gabor Juhos <juhosg@openwrt.org>
+Date: Wed, 16 Apr 2014 11:34:41 +0200
+Subject: watchdog: ath79_wdt: avoid spurious restarts on AR934x
+
+From: Gabor Juhos <juhosg@openwrt.org>
+
+commit 23afeb613ec0e10aecfae7838a14d485db62ac52 upstream.
+
+On some AR934x based systems, where the frequency of
+the AHB bus is relatively high, the built-in watchdog
+causes a spurious restart when it gets enabled.
+
+The possible cause of these restarts is that the timeout
+value written into the TIMER register does not reaches
+the hardware in time.
+
+Add an explicit delay into the ath79_wdt_enable function
+to avoid the spurious restarts.
+
+Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
+Reviewed-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/watchdog/ath79_wdt.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+--- a/drivers/watchdog/ath79_wdt.c
++++ b/drivers/watchdog/ath79_wdt.c
+@@ -20,6 +20,7 @@
+ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+ #include <linux/bitops.h>
++#include <linux/delay.h>
+ #include <linux/errno.h>
+ #include <linux/fs.h>
+ #include <linux/io.h>
+@@ -90,6 +91,15 @@ static inline void ath79_wdt_keepalive(v
+ static inline void ath79_wdt_enable(void)
+ {
+ ath79_wdt_keepalive();
++
++ /*
++ * Updating the TIMER register requires a few microseconds
++ * on the AR934x SoCs at least. Use a small delay to ensure
++ * that the TIMER register is updated within the hardware
++ * before enabling the watchdog.
++ */
++ udelay(2);
++
+ ath79_wdt_wr(WDOG_REG_CTRL, WDOG_CTRL_ACTION_FCR);
+ /* flush write */
+ ath79_wdt_rr(WDOG_REG_CTRL);
--- /dev/null
+From a9e0436b303e94ba57d3bd4b1fcbeaa744b7ebeb Mon Sep 17 00:00:00 2001
+From: gundberg <per.gundberg@icomera.com>
+Date: Thu, 24 Apr 2014 15:49:19 +0200
+Subject: watchdog: kempld-wdt: Use the correct value when configuring the prescaler with the watchdog
+
+From: gundberg <per.gundberg@icomera.com>
+
+commit a9e0436b303e94ba57d3bd4b1fcbeaa744b7ebeb upstream.
+
+Use the prescaler index, rather than its value, to configure the watchdog.
+This will prevent a mismatch with the prescaler used to calculate the cycles.
+
+Signed-off-by: Per Gundberg <per.gundberg@icomera.com>
+Reviewed-by: Guenter Roeck <linux@roeck-us.net>
+Reviewed-by: Michael Brunner <michael.brunner@kontron.com>
+Tested-by: Michael Brunner <michael.brunner@kontron.com>
+Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/watchdog/kempld_wdt.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/watchdog/kempld_wdt.c
++++ b/drivers/watchdog/kempld_wdt.c
+@@ -162,7 +162,7 @@ static int kempld_wdt_set_stage_timeout(
+ kempld_get_mutex(pld);
+ stage_cfg = kempld_read8(pld, KEMPLD_WDT_STAGE_CFG(stage->id));
+ stage_cfg &= ~STAGE_CFG_PRESCALER_MASK;
+- stage_cfg |= STAGE_CFG_SET_PRESCALER(prescaler);
++ stage_cfg |= STAGE_CFG_SET_PRESCALER(PRESCALER_21);
+ kempld_write8(pld, KEMPLD_WDT_STAGE_CFG(stage->id), stage_cfg);
+ kempld_write32(pld, KEMPLD_WDT_STAGE_TIMEOUT(stage->id),
+ stage_timeout);
--- /dev/null
+From 938626d96a3ffb9eb54552bb0d3a4f2b30ffdeb0 Mon Sep 17 00:00:00 2001
+From: Viresh Kumar <viresh.kumar@linaro.org>
+Date: Thu, 15 May 2014 10:01:59 +0530
+Subject: watchdog: sp805: Set watchdog_device->timeout from ->set_timeout()
+
+From: Viresh Kumar <viresh.kumar@linaro.org>
+
+commit 938626d96a3ffb9eb54552bb0d3a4f2b30ffdeb0 upstream.
+
+Implementation of ->set_timeout() is supposed to set 'timeout' field of 'struct
+watchdog_device' passed to it. sp805 was rather setting this in a local
+variable. Fix it.
+
+Reported-by: Arun Ramamurthy <arun.ramamurthy@broadcom.com>
+Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
+Reviewed-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/watchdog/sp805_wdt.c | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+--- a/drivers/watchdog/sp805_wdt.c
++++ b/drivers/watchdog/sp805_wdt.c
+@@ -59,7 +59,6 @@
+ * @adev: amba device structure of wdt
+ * @status: current status of wdt
+ * @load_val: load value to be set for current timeout
+- * @timeout: current programmed timeout
+ */
+ struct sp805_wdt {
+ struct watchdog_device wdd;
+@@ -68,7 +67,6 @@ struct sp805_wdt {
+ struct clk *clk;
+ struct amba_device *adev;
+ unsigned int load_val;
+- unsigned int timeout;
+ };
+
+ static bool nowayout = WATCHDOG_NOWAYOUT;
+@@ -98,7 +96,7 @@ static int wdt_setload(struct watchdog_d
+ spin_lock(&wdt->lock);
+ wdt->load_val = load;
+ /* roundup timeout to closest positive integer value */
+- wdt->timeout = div_u64((load + 1) * 2 + (rate / 2), rate);
++ wdd->timeout = div_u64((load + 1) * 2 + (rate / 2), rate);
+ spin_unlock(&wdt->lock);
+
+ return 0;
projects / thirdparty / kernel / stable-queue.git / commitdiff
