[PATCH 3.10 00/11] 3.10.88-stable review

[PATCH 3.10 00/11] 3.10.88-stable review

[Greg Kroah-Hartman]

This is the start of the stable review cycle for the 3.10.88 release.
There are 11 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 Sun Sep 13 22:45:08 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.88-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.88-rc1

Yann Droneaud <ydroneaud@opteya.com>
    arm64/mm: Remove hack in mmap randomize layout

Horia Geant? <horia.geanta@freescale.com>
    crypto: caam - fix memory corruption in ahash_final_ctx

Bart Van Assche <bart.vanassche@sandisk.com>
    libfc: Fix fc_fcp_cleanup_each_cmd()

Alex Deucher <alexander.deucher@amd.com>
    drm/radeon: add new OLAND pci id

Michael Walle <michael@walle.cc>
    EDAC, ppc4xx: Access mci->csrows array elements properly

Richard Weinberger <richard@nod.at>
    localmodconfig: Use Kbuild files too

Joe Thornber <ejt@redhat.com>
    dm thin metadata: delete btrees when releasing metadata snapshot

Peter Zijlstra <peterz@infradead.org>
    perf: Fix fasync handling on inherited events

Wanpeng Li <wanpeng.li@hotmail.com>
    mm/hwpoison: fix page refcount of unknown non LRU page

Manfred Spraul <manfred@colorfullife.com>
    ipc/sem.c: update/correct memory barriers

Herton R. Krzesinski <herton@redhat.com>
    ipc,sem: fix use after free on IPC_RMID after a task using same semaphore set exits


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

Diffstat:

 Makefile                             |  4 ++--
 arch/arm64/mm/mmap.c                 | 12 ++--------
 drivers/crypto/caam/caamhash.c       |  7 +++---
 drivers/edac/ppc4xx_edac.c           |  2 +-
 drivers/md/dm-thin-metadata.c        |  4 ++--
 drivers/scsi/libfc/fc_fcp.c          | 19 ++++++++++++++--
 include/drm/drm_pciids.h             |  1 +
 ipc/sem.c                            | 43 +++++++++++++++++++++++++++++-------
 kernel/events/core.c                 | 12 ++++++++--
 mm/memory-failure.c                  |  2 ++
 scripts/kconfig/streamline_config.pl |  2 +-
 11 files changed, 77 insertions(+), 31 deletions(-)

[PATCH 3.10 01/11] ipc,sem: fix use after free on IPC_RMID after a task using same semaphore set exits

[Greg Kroah-Hartman]

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

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

From: "Herton R. Krzesinski" <herton@redhat.com>

commit 602b8593d2b4138c10e922eeaafe306f6b51817b upstream.

The current semaphore code allows a potential use after free: in
exit_sem we may free the task's sem_undo_list while there is still
another task looping through the same semaphore set and cleaning the
sem_undo list at freeary function (the task called IPC_RMID for the same
semaphore set).

For example, with a test program [1] running which keeps forking a lot
of processes (which then do a semop call with SEM_UNDO flag), and with
the parent right after removing the semaphore set with IPC_RMID, and a
kernel built with CONFIG_SLAB, CONFIG_SLAB_DEBUG and
CONFIG_DEBUG_SPINLOCK, you can easily see something like the following
in the kernel log:

   Slab corruption (Not tainted): kmalloc-64 start=ffff88003b45c1c0, len=64
   000: 6b 6b 6b 6b 6b 6b 6b 6b 00 6b 6b 6b 6b 6b 6b 6b  kkkkkkkk.kkkkkkk
   010: ff ff ff ff 6b 6b 6b 6b ff ff ff ff ff ff ff ff  ....kkkk........
   Prev obj: start=ffff88003b45c180, len=64
   000: 00 00 00 00 ad 4e ad de ff ff ff ff 5a 5a 5a 5a  .....N......ZZZZ
   010: ff ff ff ff ff ff ff ff c0 fb 01 37 00 88 ff ff  ...........7....
   Next obj: start=ffff88003b45c200, len=64
   000: 00 00 00 00 ad 4e ad de ff ff ff ff 5a 5a 5a 5a  .....N......ZZZZ
   010: ff ff ff ff ff ff ff ff 68 29 a7 3c 00 88 ff ff  ........h).<....
   BUG: spinlock wrong CPU on CPU#2, test/18028
   general protection fault: 0000 [#1] SMP
   Modules linked in: 8021q mrp garp stp llc nf_conntrack_ipv4 nf_defrag_ipv4 ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables binfmt_misc ppdev input_leds joydev parport_pc parport floppy serio_raw virtio_balloon virtio_rng virtio_console virtio_net iosf_mbi crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcspkr qxl ttm drm_kms_helper drm snd_hda_codec_generic i2c_piix4 snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd soundcore crc32c_intel virtio_pci virtio_ring virtio pata_acpi ata_generic [last unloaded: speedstep_lib]
   CPU: 2 PID: 18028 Comm: test Not tainted 4.2.0-rc5+ #1
   Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.8.1-20150318_183358- 04/01/2014
   RIP: spin_dump+0x53/0xc0
   Call Trace:
     spin_bug+0x30/0x40
     do_raw_spin_unlock+0x71/0xa0
     _raw_spin_unlock+0xe/0x10
     freeary+0x82/0x2a0
     ? _raw_spin_lock+0xe/0x10
     semctl_down.clone.0+0xce/0x160
     ? __do_page_fault+0x19a/0x430
     ? __audit_syscall_entry+0xa8/0x100
     SyS_semctl+0x236/0x2c0
     ? syscall_trace_leave+0xde/0x130
     entry_SYSCALL_64_fastpath+0x12/0x71
   Code: 8b 80 88 03 00 00 48 8d 88 60 05 00 00 48 c7 c7 a0 2c a4 81 31 c0 65 8b 15 eb 40 f3 7e e8 08 31 68 00 4d 85 e4 44 8b 4b 08 74 5e <45> 8b 84 24 88 03 00 00 49 8d 8c 24 60 05 00 00 8b 53 04 48 89
   RIP  [<ffffffff810d6053>] spin_dump+0x53/0xc0
    RSP <ffff88003750fd68>
   ---[ end trace 783ebb76612867a0 ]---
   NMI watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [test:18053]
   Modules linked in: 8021q mrp garp stp llc nf_conntrack_ipv4 nf_defrag_ipv4 ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables binfmt_misc ppdev input_leds joydev parport_pc parport floppy serio_raw virtio_balloon virtio_rng virtio_console virtio_net iosf_mbi crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcspkr qxl ttm drm_kms_helper drm snd_hda_codec_generic i2c_piix4 snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd soundcore crc32c_intel virtio_pci virtio_ring virtio pata_acpi ata_generic [last unloaded: speedstep_lib]
   CPU: 3 PID: 18053 Comm: test Tainted: G      D         4.2.0-rc5+ #1
   Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.8.1-20150318_183358- 04/01/2014
   RIP: native_read_tsc+0x0/0x20
   Call Trace:
     ? delay_tsc+0x40/0x70
     __delay+0xf/0x20
     do_raw_spin_lock+0x96/0x140
     _raw_spin_lock+0xe/0x10
     sem_lock_and_putref+0x11/0x70
     SYSC_semtimedop+0x7bf/0x960
     ? handle_mm_fault+0xbf6/0x1880
     ? dequeue_task_fair+0x79/0x4a0
     ? __do_page_fault+0x19a/0x430
     ? kfree_debugcheck+0x16/0x40
     ? __do_page_fault+0x19a/0x430
     ? __audit_syscall_entry+0xa8/0x100
     ? do_audit_syscall_entry+0x66/0x70
     ? syscall_trace_enter_phase1+0x139/0x160
     SyS_semtimedop+0xe/0x10
     SyS_semop+0x10/0x20
     entry_SYSCALL_64_fastpath+0x12/0x71
   Code: 47 10 83 e8 01 85 c0 89 47 10 75 08 65 48 89 3d 1f 74 ff 7e c9 c3 0f 1f 44 00 00 55 48 89 e5 e8 87 17 04 00 66 90 c9 c3 0f 1f 00 <55> 48 89 e5 0f 31 89 c1 48 89 d0 48 c1 e0 20 89 c9 48 09 c8 c9
   Kernel panic - not syncing: softlockup: hung tasks

I wasn't able to trigger any badness on a recent kernel without the
proper config debugs enabled, however I have softlockup reports on some
kernel versions, in the semaphore code, which are similar as above (the
scenario is seen on some servers running IBM DB2 which uses semaphore
syscalls).

The patch here fixes the race against freeary, by acquiring or waiting
on the sem_undo_list lock as necessary (exit_sem can race with freeary,
while freeary sets un->semid to -1 and removes the same sem_undo from
list_proc or when it removes the last sem_undo).

After the patch I'm unable to reproduce the problem using the test case
[1].

[1] Test case used below:

    #include <stdio.h>
    #include <sys/types.h>
    #include <sys/ipc.h>
    #include <sys/sem.h>
    #include <sys/wait.h>
    #include <stdlib.h>
    #include <time.h>
    #include <unistd.h>
    #include <errno.h>

    #define NSEM 1
    #define NSET 5

    int sid[NSET];

    void thread()
    {
            struct sembuf op;
            int s;
            uid_t pid = getuid();

            s = rand() % NSET;
            op.sem_num = pid % NSEM;
            op.sem_op = 1;
            op.sem_flg = SEM_UNDO;

            semop(sid[s], &op, 1);
            exit(EXIT_SUCCESS);
    }

    void create_set()
    {
            int i, j;
            pid_t p;
            union {
                    int val;
                    struct semid_ds *buf;
                    unsigned short int *array;
                    struct seminfo *__buf;
            } un;

            /* Create and initialize semaphore set */
            for (i = 0; i < NSET; i++) {
                    sid[i] = semget(IPC_PRIVATE , NSEM, 0644 | IPC_CREAT);
                    if (sid[i] < 0) {
                            perror("semget");
                            exit(EXIT_FAILURE);
                    }
            }
            un.val = 0;
            for (i = 0; i < NSET; i++) {
                    for (j = 0; j < NSEM; j++) {
                            if (semctl(sid[i], j, SETVAL, un) < 0)
                                    perror("semctl");
                    }
            }

            /* Launch threads that operate on semaphore set */
            for (i = 0; i < NSEM * NSET * NSET; i++) {
                    p = fork();
                    if (p < 0)
                            perror("fork");
                    if (p == 0)
                            thread();
            }

            /* Free semaphore set */
            for (i = 0; i < NSET; i++) {
                    if (semctl(sid[i], NSEM, IPC_RMID))
                            perror("IPC_RMID");
            }

            /* Wait for forked processes to exit */
            while (wait(NULL)) {
                    if (errno == ECHILD)
                            break;
            };
    }

    int main(int argc, char **argv)
    {
            pid_t p;

            srand(time(NULL));

            while (1) {
                    p = fork();
                    if (p < 0) {
                            perror("fork");
                            exit(EXIT_FAILURE);
                    }
                    if (p == 0) {
                            create_set();
                            goto end;
                    }

                    /* Wait for forked processes to exit */
                    while (wait(NULL)) {
                            if (errno == ECHILD)
                                    break;
                    };
            }
    end:
            return 0;
    }

[akpm@linux-foundation.org: use normal comment layout]
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
Acked-by: Manfred Spraul <manfred@colorfullife.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Rafael Aquini <aquini@redhat.com>
CC: Aristeu Rozanski <aris@redhat.com>
Cc: David Jeffery <djeffery@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

---
 ipc/sem.c |   23 +++++++++++++++++------
 1 file changed, 17 insertions(+), 6 deletions(-)

--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -2049,17 +2049,28 @@ void exit_sem(struct task_struct *tsk)
 		rcu_read_lock();
 		un = list_entry_rcu(ulp->list_proc.next,
 				    struct sem_undo, list_proc);
-		if (&un->list_proc == &ulp->list_proc)
-			semid = -1;
-		 else
-			semid = un->semid;
+		if (&un->list_proc == &ulp->list_proc) {
+			/*
+			 * We must wait for freeary() before freeing this ulp,
+			 * in case we raced with last sem_undo. There is a small
+			 * possibility where we exit while freeary() didn't
+			 * finish unlocking sem_undo_list.
+			 */
+			spin_unlock_wait(&ulp->lock);
+			rcu_read_unlock();
+			break;
+		}
+		spin_lock(&ulp->lock);
+		semid = un->semid;
+		spin_unlock(&ulp->lock);
 
+		/* exit_sem raced with IPC_RMID, nothing to do */
 		if (semid == -1) {
 			rcu_read_unlock();
-			break;
+			continue;
 		}
 
-		sma = sem_obtain_object_check(tsk->nsproxy->ipc_ns, un->semid);
+		sma = sem_obtain_object_check(tsk->nsproxy->ipc_ns, semid);
 		/* exit_sem raced with IPC_RMID, nothing to do */
 		if (IS_ERR(sma)) {
 			rcu_read_unlock();

[PATCH 3.10 02/11] ipc/sem.c: update/correct memory barriers

[Greg Kroah-Hartman]

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

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

From: Manfred Spraul <manfred@colorfullife.com>

commit 3ed1f8a99d70ea1cd1508910eb107d0edcae5009 upstream.

sem_lock() did not properly pair memory barriers:

!spin_is_locked() and spin_unlock_wait() are both only control barriers.
The code needs an acquire barrier, otherwise the cpu might perform read
operations before the lock test.

As no primitive exists inside <include/spinlock.h> and since it seems
noone wants another primitive, the code creates a local primitive within
ipc/sem.c.

With regards to -stable:

The change of sem_wait_array() is a bugfix, the change to sem_lock() is a
nop (just a preprocessor redefinition to improve the readability).  The
bugfix is necessary for all kernels that use sem_wait_array() (i.e.:
starting from 3.10).

Signed-off-by: Manfred Spraul <manfred@colorfullife.com>
Reported-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Kirill Tkhai <ktkhai@parallels.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>
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>

---
 ipc/sem.c |   20 ++++++++++++++++++--
 1 file changed, 18 insertions(+), 2 deletions(-)

--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -253,6 +253,16 @@ static void sem_rcu_free(struct rcu_head
 }
 
 /*
+ * spin_unlock_wait() and !spin_is_locked() are not memory barriers, they
+ * are only control barriers.
+ * The code must pair with spin_unlock(&sem->lock) or
+ * spin_unlock(&sem_perm.lock), thus just the control barrier is insufficient.
+ *
+ * smp_rmb() is sufficient, as writes cannot pass the control barrier.
+ */
+#define ipc_smp_acquire__after_spin_is_unlocked()	smp_rmb()
+
+/*
  * Wait until all currently ongoing simple ops have completed.
  * Caller must own sem_perm.lock.
  * New simple ops cannot start, because simple ops first check
@@ -275,6 +285,7 @@ static void sem_wait_array(struct sem_ar
 		sem = sma->sem_base + i;
 		spin_unlock_wait(&sem->lock);
 	}
+	ipc_smp_acquire__after_spin_is_unlocked();
 }
 
 /*
@@ -326,8 +337,13 @@ static inline int sem_lock(struct sem_ar
 
 		/* Then check that the global lock is free */
 		if (!spin_is_locked(&sma->sem_perm.lock)) {
-			/* spin_is_locked() is not a memory barrier */
-			smp_mb();
+			/*
+			 * We need a memory barrier with acquire semantics,
+			 * otherwise we can race with another thread that does:
+			 *	complex_count++;
+			 *	spin_unlock(sem_perm.lock);
+			 */
+			ipc_smp_acquire__after_spin_is_unlocked();
 
 			/* Now repeat the test of complex_count:
 			 * It can't change anymore until we drop sem->lock.

[PATCH 3.10 03/11] mm/hwpoison: fix page refcount of unknown non LRU page

[Greg Kroah-Hartman]

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

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

From: Wanpeng Li <wanpeng.li@hotmail.com>

commit 4f32be677b124a49459e2603321c7a5605ceb9f8 upstream.

After trying to drain pages from pagevec/pageset, we try to get reference
count of the page again, however, the reference count of the page is not
reduced if the page is still not on LRU list.

Fix it by adding the put_page() to drop the page reference which is from
__get_any_page().

Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
Acked-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.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>

---
 mm/memory-failure.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1473,6 +1473,8 @@ static int get_any_page(struct page *pag
 		 */
 		ret = __get_any_page(page, pfn, 0);
 		if (!PageLRU(page)) {
+			/* Drop page reference which is from __get_any_page() */
+			put_page(page);
 			pr_info("soft_offline: %#lx: unknown non LRU page type %lx\n",
 				pfn, page->flags);
 			return -EIO;

[PATCH 3.10 04/11] perf: Fix fasync handling on inherited events

[Greg Kroah-Hartman]

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

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

From: Peter Zijlstra <peterz@infradead.org>

commit fed66e2cdd4f127a43fd11b8d92a99bdd429528c upstream.

Vince reported that the fasync signal stuff doesn't work proper for
inherited events. So fix that.

Installing fasync allocates memory and sets filp->f_flags |= FASYNC,
which upon the demise of the file descriptor ensures the allocation is
freed and state is updated.

Now for perf, we can have the events stick around for a while after the
original FD is dead because of references from child events. So we
cannot copy the fasync pointer around. We can however consistently use
the parent's fasync, as that will be updated.

Reported-and-Tested-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Arnaldo Carvalho deMelo <acme@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: eranian@google.com
Link: http://lkml.kernel.org/r/1434011521.1495.71.camel@twins
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 kernel/events/core.c |   12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -3993,12 +3993,20 @@ static const struct file_operations perf
  * to user-space before waking everybody up.
  */
 
+static inline struct fasync_struct **perf_event_fasync(struct perf_event *event)
+{
+	/* only the parent has fasync state */
+	if (event->parent)
+		event = event->parent;
+	return &event->fasync;
+}
+
 void perf_event_wakeup(struct perf_event *event)
 {
 	ring_buffer_wakeup(event);
 
 	if (event->pending_kill) {
-		kill_fasync(&event->fasync, SIGIO, event->pending_kill);
+		kill_fasync(perf_event_fasync(event), SIGIO, event->pending_kill);
 		event->pending_kill = 0;
 	}
 }
@@ -5153,7 +5161,7 @@ static int __perf_event_overflow(struct
 	else
 		perf_event_output(event, data, regs);
 
-	if (event->fasync && event->pending_kill) {
+	if (*perf_event_fasync(event) && event->pending_kill) {
 		event->pending_wakeup = 1;
 		irq_work_queue(&event->pending);
 	}

[PATCH 3.10 05/11] dm thin metadata: delete btrees when releasing metadata snapshot

[Greg Kroah-Hartman]

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

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

From: Joe Thornber <ejt@redhat.com>

commit 7f518ad0a212e2a6fd68630e176af1de395070a7 upstream.

The device details and mapping trees were just being decremented
before.  Now btree_del() is called to do a deep delete.

Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/md/dm-thin-metadata.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/md/dm-thin-metadata.c
+++ b/drivers/md/dm-thin-metadata.c
@@ -1281,8 +1281,8 @@ static int __release_metadata_snap(struc
 		return r;
 
 	disk_super = dm_block_data(copy);
-	dm_sm_dec_block(pmd->metadata_sm, le64_to_cpu(disk_super->data_mapping_root));
-	dm_sm_dec_block(pmd->metadata_sm, le64_to_cpu(disk_super->device_details_root));
+	dm_btree_del(&pmd->info, le64_to_cpu(disk_super->data_mapping_root));
+	dm_btree_del(&pmd->details_info, le64_to_cpu(disk_super->device_details_root));
 	dm_sm_dec_block(pmd->metadata_sm, held_root);
 
 	return dm_tm_unlock(pmd->tm, copy);

[PATCH 3.10 06/11] localmodconfig: Use Kbuild files too

[Greg Kroah-Hartman]

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

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

From: Richard Weinberger <richard@nod.at>

commit c0ddc8c745b7f89c50385fd7aa03c78dc543fa7a upstream.

In kbuild it is allowed to define objects in files named "Makefile"
and "Kbuild".
Currently localmodconfig reads objects only from "Makefile"s and misses
modules like nouveau.

Link: http://lkml.kernel.org/r/1437948415-16290-1-git-send-email-richard@nod.at

Reported-and-tested-by: Leonidas Spyropoulos <artafinde@gmail.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 scripts/kconfig/streamline_config.pl |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/scripts/kconfig/streamline_config.pl
+++ b/scripts/kconfig/streamline_config.pl
@@ -137,7 +137,7 @@ my $ksource = ($ARGV[0] ? $ARGV[0] : '.'
 my $kconfig = $ARGV[1];
 my $lsmod_file = $ENV{'LSMOD'};
 
-my @makefiles = `find $ksource -name Makefile 2>/dev/null`;
+my @makefiles = `find $ksource -name Makefile -or -name Kbuild 2>/dev/null`;
 chomp @makefiles;
 
 my %depends;

[PATCH 3.10 07/11] EDAC, ppc4xx: Access mci->csrows array elements properly

[Greg Kroah-Hartman]

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

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

From: Michael Walle <michael@walle.cc>

commit 5c16179b550b9fd8114637a56b153c9768ea06a5 upstream.

The commit

  de3910eb79ac ("edac: change the mem allocation scheme to
		 make Documentation/kobject.txt happy")

changed the memory allocation for the csrows member. But ppc4xx_edac was
forgotten in the patch. Fix it.

Signed-off-by: Michael Walle <michael@walle.cc>
Cc: linux-edac <linux-edac@vger.kernel.org>
Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Link: http://lkml.kernel.org/r/1437469253-8611-1-git-send-email-michael@walle.cc
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/edac/ppc4xx_edac.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/edac/ppc4xx_edac.c
+++ b/drivers/edac/ppc4xx_edac.c
@@ -921,7 +921,7 @@ static int ppc4xx_edac_init_csrows(struc
 	 */
 
 	for (row = 0; row < mci->nr_csrows; row++) {
-		struct csrow_info *csi = &mci->csrows[row];
+		struct csrow_info *csi = mci->csrows[row];
 
 		/*
 		 * Get the configuration settings for this

[PATCH 3.10 08/11] drm/radeon: add new OLAND pci id

[Greg Kroah-Hartman]

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

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

From: Alex Deucher <alexander.deucher@amd.com>

commit e037239e5e7b61007763984aa35a8329596d8c88 upstream.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 include/drm/drm_pciids.h |    1 +
 1 file changed, 1 insertion(+)

--- a/include/drm/drm_pciids.h
+++ b/include/drm/drm_pciids.h
@@ -150,6 +150,7 @@
 	{0x1002, 0x6610, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_OLAND|RADEON_NEW_MEMMAP}, \
 	{0x1002, 0x6611, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_OLAND|RADEON_NEW_MEMMAP}, \
 	{0x1002, 0x6613, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_OLAND|RADEON_NEW_MEMMAP}, \
+	{0x1002, 0x6617, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_OLAND|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
 	{0x1002, 0x6620, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_OLAND|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
 	{0x1002, 0x6621, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_OLAND|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
 	{0x1002, 0x6623, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_OLAND|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \

[PATCH 3.10 09/11] libfc: Fix fc_fcp_cleanup_each_cmd()

[Greg Kroah-Hartman]

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

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

From: Bart Van Assche <bart.vanassche@sandisk.com>

commit 8f2777f53e3d5ad8ef2a176a4463a5c8e1a16431 upstream.

Since fc_fcp_cleanup_cmd() can sleep this function must not
be called while holding a spinlock. This patch avoids that
fc_fcp_cleanup_each_cmd() triggers the following bug:

BUG: scheduling while atomic: sg_reset/1512/0x00000202
1 lock held by sg_reset/1512:
 #0:  (&(&fsp->scsi_pkt_lock)->rlock){+.-...}, at: [<ffffffffc0225cd5>] fc_fcp_cleanup_each_cmd.isra.21+0xa5/0x150 [libfc]
Preemption disabled at:[<ffffffffc0225cd5>] fc_fcp_cleanup_each_cmd.isra.21+0xa5/0x150 [libfc]
Call Trace:
 [<ffffffff816c612c>] dump_stack+0x4f/0x7b
 [<ffffffff810828bc>] __schedule_bug+0x6c/0xd0
 [<ffffffff816c87aa>] __schedule+0x71a/0xa10
 [<ffffffff816c8ad2>] schedule+0x32/0x80
 [<ffffffffc0217eac>] fc_seq_set_resp+0xac/0x100 [libfc]
 [<ffffffffc0218b11>] fc_exch_done+0x41/0x60 [libfc]
 [<ffffffffc0225cff>] fc_fcp_cleanup_each_cmd.isra.21+0xcf/0x150 [libfc]
 [<ffffffffc0225f43>] fc_eh_device_reset+0x1c3/0x270 [libfc]
 [<ffffffff814a2cc9>] scsi_try_bus_device_reset+0x29/0x60
 [<ffffffff814a3908>] scsi_ioctl_reset+0x258/0x2d0
 [<ffffffff814a2650>] scsi_ioctl+0x150/0x440
 [<ffffffff814b3a9d>] sd_ioctl+0xad/0x120
 [<ffffffff8132f266>] blkdev_ioctl+0x1b6/0x810
 [<ffffffff811da608>] block_ioctl+0x38/0x40
 [<ffffffff811b4e08>] do_vfs_ioctl+0x2f8/0x530
 [<ffffffff811b50c1>] SyS_ioctl+0x81/0xa0
 [<ffffffff816cf8b2>] system_call_fastpath+0x16/0x7a

Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Signed-off-by: Vasu Dev <vasu.dev@intel.com>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/scsi/libfc/fc_fcp.c |   19 +++++++++++++++++--
 1 file changed, 17 insertions(+), 2 deletions(-)

--- a/drivers/scsi/libfc/fc_fcp.c
+++ b/drivers/scsi/libfc/fc_fcp.c
@@ -1039,11 +1039,26 @@ restart:
 		fc_fcp_pkt_hold(fsp);
 		spin_unlock_irqrestore(&si->scsi_queue_lock, flags);
 
-		if (!fc_fcp_lock_pkt(fsp)) {
+		spin_lock_bh(&fsp->scsi_pkt_lock);
+		if (!(fsp->state & FC_SRB_COMPL)) {
+			fsp->state |= FC_SRB_COMPL;
+			/*
+			 * TODO: dropping scsi_pkt_lock and then reacquiring
+			 * again around fc_fcp_cleanup_cmd() is required,
+			 * since fc_fcp_cleanup_cmd() calls into
+			 * fc_seq_set_resp() and that func preempts cpu using
+			 * schedule. May be schedule and related code should be
+			 * removed instead of unlocking here to avoid scheduling
+			 * while atomic bug.
+			 */
+			spin_unlock_bh(&fsp->scsi_pkt_lock);
+
 			fc_fcp_cleanup_cmd(fsp, error);
+
+			spin_lock_bh(&fsp->scsi_pkt_lock);
 			fc_io_compl(fsp);
-			fc_fcp_unlock_pkt(fsp);
 		}
+		spin_unlock_bh(&fsp->scsi_pkt_lock);
 
 		fc_fcp_pkt_release(fsp);
 		spin_lock_irqsave(&si->scsi_queue_lock, flags);

[PATCH 3.10 10/11] crypto: caam - fix memory corruption in ahash_final_ctx

[Greg Kroah-Hartman]

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

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

From: Horia Geant? <horia.geanta@freescale.com>

commit b310c178e6d897f82abb9da3af1cd7c02b09f592 upstream.

When doing pointer operation for accessing the HW S/G table,
a value representing number of entries (and not number of bytes)
must be used.

Fixes: 045e36780f115 ("crypto: caam - ahash hmac support")
Signed-off-by: Horia Geant? <horia.geanta@freescale.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/crypto/caam/caamhash.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

--- a/drivers/crypto/caam/caamhash.c
+++ b/drivers/crypto/caam/caamhash.c
@@ -895,13 +895,14 @@ static int ahash_final_ctx(struct ahash_
 			  state->buflen_1;
 	u32 *sh_desc = ctx->sh_desc_fin, *desc;
 	dma_addr_t ptr = ctx->sh_desc_fin_dma;
-	int sec4_sg_bytes;
+	int sec4_sg_bytes, sec4_sg_src_index;
 	int digestsize = crypto_ahash_digestsize(ahash);
 	struct ahash_edesc *edesc;
 	int ret = 0;
 	int sh_len;
 
-	sec4_sg_bytes = (1 + (buflen ? 1 : 0)) * sizeof(struct sec4_sg_entry);
+	sec4_sg_src_index = 1 + (buflen ? 1 : 0);
+	sec4_sg_bytes = sec4_sg_src_index * sizeof(struct sec4_sg_entry);
 
 	/* allocate space for base edesc and hw desc commands, link tables */
 	edesc = kmalloc(sizeof(struct ahash_edesc) + DESC_JOB_IO_LEN +
@@ -928,7 +929,7 @@ static int ahash_final_ctx(struct ahash_
 	state->buf_dma = try_buf_map_to_sec4_sg(jrdev, edesc->sec4_sg + 1,
 						buf, state->buf_dma, buflen,
 						last_buflen);
-	(edesc->sec4_sg + sec4_sg_bytes - 1)->len |= SEC4_SG_LEN_FIN;
+	(edesc->sec4_sg + sec4_sg_src_index - 1)->len |= SEC4_SG_LEN_FIN;
 
 	append_seq_in_ptr(desc, edesc->sec4_sg_dma, ctx->ctx_len + buflen,
 			  LDST_SGF);

[PATCH 3.10 11/11] arm64/mm: Remove hack in mmap randomize layout

[Greg Kroah-Hartman]

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

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

From: Yann Droneaud <ydroneaud@opteya.com>

commit d6c763afab142a85e4770b4bc2a5f40f256d5c5d upstream.

Since commit 8a0a9bd4db63 ('random: make get_random_int() more
random'), get_random_int() returns a random value for each call,
so comment and hack introduced in mmap_rnd() as part of commit
1d18c47c735e ('arm64: MMU fault handling and page table management')
are incorrects.

Commit 1d18c47c735e seems to use the same hack introduced by
commit a5adc91a4b44 ('powerpc: Ensure random space between stack
and mmaps'), latter copied in commit 5a0efea09f42 ('sparc64: Sharpen
address space randomization calculations.').

But both architectures were cleaned up as part of commit
fa8cbaaf5a68 ('powerpc+sparc64/mm: Remove hack in mmap randomize
layout') as hack is no more needed since commit 8a0a9bd4db63.

So the present patch removes the comment and the hack around
get_random_int() on AArch64's mmap_rnd().

Cc: David S. Miller <davem@davemloft.net>
Cc: Anton Blanchard <anton@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Will Deacon <will.deacon@arm.com>
Acked-by: Dan McGee <dpmcgee@gmail.com>
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Cc: Matthias Brugger <mbrugger@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/arm64/mm/mmap.c |   12 ++----------
 1 file changed, 2 insertions(+), 10 deletions(-)

--- a/arch/arm64/mm/mmap.c
+++ b/arch/arm64/mm/mmap.c
@@ -47,22 +47,14 @@ static int mmap_is_legacy(void)
 	return sysctl_legacy_va_layout;
 }
 
-/*
- * Since get_random_int() returns the same value within a 1 jiffy window, we
- * will almost always get the same randomisation for the stack and mmap
- * region. This will mean the relative distance between stack and mmap will be
- * the same.
- *
- * To avoid this we can shift the randomness by 1 bit.
- */
 static unsigned long mmap_rnd(void)
 {
 	unsigned long rnd = 0;
 
 	if (current->flags & PF_RANDOMIZE)
-		rnd = (long)get_random_int() & (STACK_RND_MASK >> 1);
+		rnd = (long)get_random_int() & STACK_RND_MASK;
 
-	return rnd << (PAGE_SHIFT + 1);
+	return rnd << PAGE_SHIFT;
 }
 
 static unsigned long mmap_base(void)

Re: [PATCH 3.10 00/11] 3.10.88-stable review

[Shuah Khan]

On 09/11/2015 04:48 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.10.88 release.
> There are 11 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 Sun Sep 13 22:45:08 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.88-rc1.gz
> and the diffstat can be found below.
> 

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

thanks,
-- Shuah


-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shuahkh@osg.samsung.com | (970) 217-8978

Re: [PATCH 3.10 00/11] 3.10.88-stable review

[Guenter Roeck]

On 09/11/2015 03:48 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.10.88 release.
> There are 11 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 Sun Sep 13 22:45:08 UTC 2015.
> Anything received after that time might be too late.
>

Build results:
	total: 122 pass: 122 fail: 0
Qemu test results:
	total: 70 pass: 70 fail: 0

Details are available at http://server.roeck-us.net:8010/builders.

Guenter

Re: [PATCH 3.10 00/11] 3.10.88-stable review

[Sudip Mukherjee]

On Fri, Sep 11, 2015 at 03:48:59PM -0700, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.10.88 release.
> There are 11 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 Sun Sep 13 22:45:08 UTC 2015.
> Anything received after that time might be too late.
Compiled and booted on x86_32. No errors in dmesg.

cross_compiled with allmodconfig:

i386 - pass
x86_64 - pass
alphacheck - pass
arm - pass
cris - failed
m68k - pass
mips - pass
powerpc - pass
s390 - failed
sparc - pass
sparc64 - pass
tile - failed
tilegx - failed
xtensa - failed

build report at https://travis-ci.org/sudipm-mukherjee/parport/builds/79959776

regards
sudip

Re: [PATCH 3.10 00/11] 3.10.88-stable review

[Greg Kroah-Hartman]

On Sat, Sep 12, 2015 at 12:56:03PM +0530, Sudip Mukherjee wrote:
> On Fri, Sep 11, 2015 at 03:48:59PM -0700, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.10.88 release.
> > There are 11 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 Sun Sep 13 22:45:08 UTC 2015.
> > Anything received after that time might be too late.
> Compiled and booted on x86_32. No errors in dmesg.
> 
> cross_compiled with allmodconfig:
> 
> i386 - pass
> x86_64 - pass
> alphacheck - pass
> arm - pass
> cris - failed

Is this expected?

> m68k - pass
> mips - pass
> powerpc - pass
> s390 - failed

Is this expected?

> sparc - pass
> sparc64 - pass
> tile - failed
> tilegx - failed
> xtensa - failed

Are these all new failures?

thanks,

greg k-h

Re: [PATCH 3.10 00/11] 3.10.88-stable review

[Max Filippov]

On Sat, Sep 12, 2015 at 6:55 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Sat, Sep 12, 2015 at 12:56:03PM +0530, Sudip Mukherjee wrote:
>> On Fri, Sep 11, 2015 at 03:48:59PM -0700, Greg Kroah-Hartman wrote:
>> > This is the start of the stable review cycle for the 3.10.88 release.
>> > There are 11 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 Sun Sep 13 22:45:08 UTC 2015.
>> > Anything received after that time might be too late.
>> Compiled and booted on x86_32. No errors in dmesg.
>>
>> cross_compiled with allmodconfig:
...
>> xtensa - failed
>
> Are these all new failures?

Build log says

/home/travis/local/gcc-4.9.0-nolibc/xtensa-linux/bin/xtensa-linux-objcopy:
Unable to change endianness of input file(s)
make[2]: *** [arch/xtensa/boot/boot-elf/Image.o] Error 1

which looks like misconfigured toolchain.

-- 
Thanks.
-- Max

Re: [PATCH 3.10 00/11] 3.10.88-stable review

[Sudip Mukherjee]

On Sat, Sep 12, 2015 at 07:22:39PM +0300, Max Filippov wrote:
> On Sat, Sep 12, 2015 at 6:55 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Sat, Sep 12, 2015 at 12:56:03PM +0530, Sudip Mukherjee wrote:
> >> On Fri, Sep 11, 2015 at 03:48:59PM -0700, Greg Kroah-Hartman wrote:
> >> > This is the start of the stable review cycle for the 3.10.88 release.
> >> > There are 11 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 Sun Sep 13 22:45:08 UTC 2015.
> >> > Anything received after that time might be too late.
> >> Compiled and booted on x86_32. No errors in dmesg.
> >>
> >> cross_compiled with allmodconfig:
> ...
> >> xtensa - failed
> >
> > Are these all new failures?
> 
> Build log says
> 
> /home/travis/local/gcc-4.9.0-nolibc/xtensa-linux/bin/xtensa-linux-objcopy:
> Unable to change endianness of input file(s)
> make[2]: *** [arch/xtensa/boot/boot-elf/Image.o] Error 1
> 
> which looks like misconfigured toolchain.
But the same script and same toolchain compiles properly for 4.1.7-rc1,
3.14.52-rc1 and also works for Linus tree (last tested yesterday
morning). I will see what has changed between 3.10 and 3.14 so that it
doesnot work for 3.10 but works for 3.14.

regards
sudip

Re: [PATCH 3.10 00/11] 3.10.88-stable review

[Guenter Roeck]

On 09/12/2015 10:36 AM, Sudip Mukherjee wrote:
> On Sat, Sep 12, 2015 at 07:22:39PM +0300, Max Filippov wrote:
>> On Sat, Sep 12, 2015 at 6:55 PM, Greg Kroah-Hartman
>> <gregkh@linuxfoundation.org> wrote:
>>> On Sat, Sep 12, 2015 at 12:56:03PM +0530, Sudip Mukherjee wrote:
>>>> On Fri, Sep 11, 2015 at 03:48:59PM -0700, Greg Kroah-Hartman wrote:
>>>>> This is the start of the stable review cycle for the 3.10.88 release.
>>>>> There are 11 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 Sun Sep 13 22:45:08 UTC 2015.
>>>>> Anything received after that time might be too late.
>>>> Compiled and booted on x86_32. No errors in dmesg.
>>>>
>>>> cross_compiled with allmodconfig:
>> ...
>>>> xtensa - failed
>>>
>>> Are these all new failures?
>>
>> Build log says
>>
>> /home/travis/local/gcc-4.9.0-nolibc/xtensa-linux/bin/xtensa-linux-objcopy:
>> Unable to change endianness of input file(s)
>> make[2]: *** [arch/xtensa/boot/boot-elf/Image.o] Error 1
>>
>> which looks like misconfigured toolchain.
> But the same script and same toolchain compiles properly for 4.1.7-rc1,
> 3.14.52-rc1 and also works for Linus tree (last tested yesterday
> morning). I will see what has changed between 3.10 and 3.14 so that it
> doesnot work for 3.10 but works for 3.14.
>

The question here is if this is a new failure in 3.10, not if it has been
fixed in a later kernel version.

For my part I used to report such persistent failures. However, I find it
useless and even confusing to report "yep, still fails", unless there is
a plan to fix it, so I don't do that anymore. Otherwise it is just a waste
of test resources, and it makes it difficult to understand the test summary.

If I _do_ report such failures, I track down the cause and the fix, and ask
the branch maintainer to apply the necessary patch(es).

Guenter

Re: [PATCH 3.10 00/11] 3.10.88-stable review

[Sudip Mukherjee]

On Sat, Sep 12, 2015 at 10:51:44AM -0700, Guenter Roeck wrote:
> On 09/12/2015 10:36 AM, Sudip Mukherjee wrote:
> >On Sat, Sep 12, 2015 at 07:22:39PM +0300, Max Filippov wrote:
> >>On Sat, Sep 12, 2015 at 6:55 PM, Greg Kroah-Hartman
> >><gregkh@linuxfoundation.org> wrote:
> >>>On Sat, Sep 12, 2015 at 12:56:03PM +0530, Sudip Mukherjee wrote:
> >>>>On Fri, Sep 11, 2015 at 03:48:59PM -0700, Greg Kroah-Hartman wrote:
<snip>
> >>>>
> >>>>cross_compiled with allmodconfig:
> >>...
> >>>>xtensa - failed
> >>>
> >>>Are these all new failures?
> >>
> >>Build log says
> >>
> >>/home/travis/local/gcc-4.9.0-nolibc/xtensa-linux/bin/xtensa-linux-objcopy:
> >>Unable to change endianness of input file(s)
> >>make[2]: *** [arch/xtensa/boot/boot-elf/Image.o] Error 1
> >>
> >>which looks like misconfigured toolchain.
> >But the same script and same toolchain compiles properly for 4.1.7-rc1,
> >3.14.52-rc1 and also works for Linus tree (last tested yesterday
> >morning). I will see what has changed between 3.10 and 3.14 so that it
> >doesnot work for 3.10 but works for 3.14.
> >
> 
> The question here is if this is a new failure in 3.10, not if it has been
> fixed in a later kernel version.
> 
> For my part I used to report such persistent failures. However, I find it
> useless and even confusing to report "yep, still fails", unless there is
> a plan to fix it, so I don't do that anymore. Otherwise it is just a waste
> of test resources, and it makes it difficult to understand the test summary.
> 
> If I _do_ report such failures, I track down the cause and the fix, and ask
> the branch maintainer to apply the necessary patch(es).
I am trying to do the same with linux-next now. And as you suggested in
another reply just tried a clean build with 3.10.87 and that also failed.
I will find out the fix which caused it to build properly for 3.14 for
me.

regards
sudip

Re: [PATCH 3.10 00/11] 3.10.88-stable review

[Sudip Mukherjee]

On Sat, Sep 12, 2015 at 07:22:39PM +0300, Max Filippov wrote:
> On Sat, Sep 12, 2015 at 6:55 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Sat, Sep 12, 2015 at 12:56:03PM +0530, Sudip Mukherjee wrote:
> >> On Fri, Sep 11, 2015 at 03:48:59PM -0700, Greg Kroah-Hartman wrote:
> >> > This is the start of the stable review cycle for the 3.10.88 release.
> >> > There are 11 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 Sun Sep 13 22:45:08 UTC 2015.
> >> > Anything received after that time might be too late.
> >> Compiled and booted on x86_32. No errors in dmesg.
> >>
> >> cross_compiled with allmodconfig:
> ...
> >> xtensa - failed
> >
> > Are these all new failures?
> 
> Build log says
> 
> /home/travis/local/gcc-4.9.0-nolibc/xtensa-linux/bin/xtensa-linux-objcopy:
> Unable to change endianness of input file(s)
> make[2]: *** [arch/xtensa/boot/boot-elf/Image.o] Error 1
> 
> which looks like misconfigured toolchain.

With same toolchain and same script upstream commit
123f15e669d5a5a2e2f260ba4a5fc2efd93df20e solves the problem. Tested
after applying it on v3.10.88.

Greg - This will apply directly, backporting not required. Do you want
me to send to you and stable (for 3.10.89) or will you pick it up?

BTW, git bisect is just awesome. I didn't know before that I can use a
test script and it will automatically bisect and test. My sunday not
spoiled yet got the result. :)

regards
sudip

Re: [PATCH 3.10 00/11] 3.10.88-stable review

[Greg Kroah-Hartman]

On Mon, Sep 14, 2015 at 02:31:51PM +0530, Sudip Mukherjee wrote:
> On Sat, Sep 12, 2015 at 07:22:39PM +0300, Max Filippov wrote:
> > On Sat, Sep 12, 2015 at 6:55 PM, Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> > > On Sat, Sep 12, 2015 at 12:56:03PM +0530, Sudip Mukherjee wrote:
> > >> On Fri, Sep 11, 2015 at 03:48:59PM -0700, Greg Kroah-Hartman wrote:
> > >> > This is the start of the stable review cycle for the 3.10.88 release.
> > >> > There are 11 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 Sun Sep 13 22:45:08 UTC 2015.
> > >> > Anything received after that time might be too late.
> > >> Compiled and booted on x86_32. No errors in dmesg.
> > >>
> > >> cross_compiled with allmodconfig:
> > ...
> > >> xtensa - failed
> > >
> > > Are these all new failures?
> > 
> > Build log says
> > 
> > /home/travis/local/gcc-4.9.0-nolibc/xtensa-linux/bin/xtensa-linux-objcopy:
> > Unable to change endianness of input file(s)
> > make[2]: *** [arch/xtensa/boot/boot-elf/Image.o] Error 1
> > 
> > which looks like misconfigured toolchain.
> 
> With same toolchain and same script upstream commit
> 123f15e669d5a5a2e2f260ba4a5fc2efd93df20e solves the problem. Tested
> after applying it on v3.10.88.
> 
> Greg - This will apply directly, backporting not required. Do you want
> me to send to you and stable (for 3.10.89) or will you pick it up?

Now applied, sorry I missed this before now.

greg k-h

Re: [PATCH 3.10 00/11] 3.10.88-stable review

[Sudip Mukherjee]

On Sat, Sep 12, 2015 at 08:55:45AM -0700, Greg Kroah-Hartman wrote:
> On Sat, Sep 12, 2015 at 12:56:03PM +0530, Sudip Mukherjee wrote:
> > On Fri, Sep 11, 2015 at 03:48:59PM -0700, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 3.10.88 release.
> > > There are 11 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 Sun Sep 13 22:45:08 UTC 2015.
> > > Anything received after that time might be too late.
> > Compiled and booted on x86_32. No errors in dmesg.
> > 
> > cross_compiled with allmodconfig:
> > 
> > cris - failed
> 
> Is this expected?
> 
> > s390 - failed
> 
> Is this expected?
> 
> > xtensa - failed
> 
> Are these all new failures?
Not sure. I just completed this test setup and testing stable for the
first time. Anyways, I will try to find out the fix and if that is
already in Linus tree I will send that to you before your next release.

regards
sudip

Re: [PATCH 3.10 00/11] 3.10.88-stable review

[Guenter Roeck]

On 09/12/2015 08:55 AM, Greg Kroah-Hartman wrote:
> On Sat, Sep 12, 2015 at 12:56:03PM +0530, Sudip Mukherjee wrote:
>> On Fri, Sep 11, 2015 at 03:48:59PM -0700, Greg Kroah-Hartman wrote:
>>> This is the start of the stable review cycle for the 3.10.88 release.
>>> There are 11 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 Sun Sep 13 22:45:08 UTC 2015.
>>> Anything received after that time might be too late.
>> Compiled and booted on x86_32. No errors in dmesg.
>>
>> cross_compiled with allmodconfig:
>>
>> i386 - pass
>> x86_64 - pass
>> alphacheck - pass
>> arm - pass
>> cris - failed
>
> Is this expected?
>
I don't test this one.

>> m68k - pass
>> mips - pass
>> powerpc - pass
>> s390 - failed
>
> Is this expected?
>
Yes.

>> sparc - pass
>> sparc64 - pass
>> tile - failed
>> tilegx - failed

Yes. Looks like it was fixed somewhere between 3.11 and 3.13,
though I did not track down the commit.

>> xtensa - failed
>

xtensa:allmodconfig builds for me, using my own toolchain.
I see that kind of failure if I build for one endianness,
then for the other, without cleaning up in between.

Guenter

> Are these all new failures?
>
> thanks,
>
> greg k-h
>