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


Groups > linux.kernel > #1223148 > unrolled thread

[PATCH 3.10 00/11] 3.10.88-stable review

Started byGreg Kroah-Hartman <gregkh@linuxfoundation.org>
First post2015-09-12 00:50 +0200
Last post2015-09-12 19:50 +0200
Articles 20 on this page of 22 — 5 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH 3.10 00/11] 3.10.88-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-09-12 00:50 +0200
    [PATCH 3.10 10/11] crypto: caam - fix memory corruption in ahash_final_ctx Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-09-12 00:50 +0200
    [PATCH 3.10 03/11] mm/hwpoison: fix page refcount of unknown non LRU page Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-09-12 01:20 +0200
    [PATCH 3.10 04/11] perf: Fix fasync handling on inherited events Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-09-12 01:20 +0200
    [PATCH 3.10 09/11] libfc: Fix fc_fcp_cleanup_each_cmd() Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-09-12 01:20 +0200
    [PATCH 3.10 06/11] localmodconfig: Use Kbuild files too Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-09-12 01:20 +0200
    [PATCH 3.10 02/11] ipc/sem.c: update/correct memory barriers Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-09-12 01:20 +0200
    [PATCH 3.10 08/11] drm/radeon: add new OLAND pci id Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-09-12 01:20 +0200
    [PATCH 3.10 05/11] dm thin metadata: delete btrees when releasing metadata snapshot Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-09-12 01:20 +0200
    [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 <gregkh@linuxfoundation.org> - 2015-09-12 01:20 +0200
    Re: [PATCH 3.10 00/11] 3.10.88-stable review Shuah Khan <shuahkh@osg.samsung.com> - 2015-09-12 03:10 +0200
    Re: [PATCH 3.10 00/11] 3.10.88-stable review Guenter Roeck <linux@roeck-us.net> - 2015-09-12 06:30 +0200
    Re: [PATCH 3.10 00/11] 3.10.88-stable review Sudip Mukherjee <sudipm.mukherjee@gmail.com> - 2015-09-12 09:30 +0200
      Re: [PATCH 3.10 00/11] 3.10.88-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-09-12 18:00 +0200
        Re: [PATCH 3.10 00/11] 3.10.88-stable review Max Filippov <jcmvbkbc@gmail.com> - 2015-09-12 18:30 +0200
          Re: [PATCH 3.10 00/11] 3.10.88-stable review Sudip Mukherjee <sudipm.mukherjee@gmail.com> - 2015-09-12 19:40 +0200
            Re: [PATCH 3.10 00/11] 3.10.88-stable review Guenter Roeck <linux@roeck-us.net> - 2015-09-12 20:00 +0200
              Re: [PATCH 3.10 00/11] 3.10.88-stable review Sudip Mukherjee <sudipm.mukherjee@gmail.com> - 2015-09-12 20:20 +0200
          Re: [PATCH 3.10 00/11] 3.10.88-stable review Sudip Mukherjee <sudipm.mukherjee@gmail.com> - 2015-09-14 11:10 +0200
            Re: [PATCH 3.10 00/11] 3.10.88-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-09-21 06:40 +0200
        Re: [PATCH 3.10 00/11] 3.10.88-stable review Sudip Mukherjee <sudipm.mukherjee@gmail.com> - 2015-09-12 19:50 +0200
        Re: [PATCH 3.10 00/11] 3.10.88-stable review Guenter Roeck <linux@roeck-us.net> - 2015-09-12 19:50 +0200

Page 1 of 2  [1] 2  Next page →


#1223148 — [PATCH 3.10 00/11] 3.10.88-stable review

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2015-09-12 00:50 +0200
Subject[PATCH 3.10 00/11] 3.10.88-stable review
Message-ID<q7FiN-75P-3@gated-at.bofh.it>
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(-)


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]


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

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2015-09-12 00:50 +0200
Subject[PATCH 3.10 10/11] crypto: caam - fix memory corruption in ahash_final_ctx
Message-ID<q7FiO-75P-29@gated-at.bofh.it>
In reply to#1223148
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);


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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


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

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2015-09-12 01:20 +0200
Subject[PATCH 3.10 03/11] mm/hwpoison: fix page refcount of unknown non LRU page
Message-ID<q7FLP-7Un-1@gated-at.bofh.it>
In reply to#1223148
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;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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


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

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2015-09-12 01:20 +0200
Subject[PATCH 3.10 04/11] perf: Fix fasync handling on inherited events
Message-ID<q7FLP-7Un-7@gated-at.bofh.it>
In reply to#1223148
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);
 	}


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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


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

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2015-09-12 01:20 +0200
Subject[PATCH 3.10 09/11] libfc: Fix fc_fcp_cleanup_each_cmd()
Message-ID<q7FLQ-7Un-11@gated-at.bofh.it>
In reply to#1223148
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);


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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


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

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2015-09-12 01:20 +0200
Subject[PATCH 3.10 06/11] localmodconfig: Use Kbuild files too
Message-ID<q7FLR-7Un-47@gated-at.bofh.it>
In reply to#1223148
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;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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


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

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2015-09-12 01:20 +0200
Subject[PATCH 3.10 02/11] ipc/sem.c: update/correct memory barriers
Message-ID<q7FLR-7Un-37@gated-at.bofh.it>
In reply to#1223148
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.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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


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

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2015-09-12 01:20 +0200
Subject[PATCH 3.10 08/11] drm/radeon: add new OLAND pci id
Message-ID<q7FLR-7Un-45@gated-at.bofh.it>
In reply to#1223148
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}, \


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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


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

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2015-09-12 01:20 +0200
Subject[PATCH 3.10 05/11] dm thin metadata: delete btrees when releasing metadata snapshot
Message-ID<q7FLR-7Un-55@gated-at.bofh.it>
In reply to#1223148
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);


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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


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

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2015-09-12 01:20 +0200
Subject[PATCH 3.10 01/11] ipc,sem: fix use after free on IPC_RMID after a task using same semaphore set exits
Message-ID<q7FLS-7Un-61@gated-at.bofh.it>
In reply to#1223148
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();


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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


#1223280

FromShuah Khan <shuahkh@osg.samsung.com>
Date2015-09-12 03:10 +0200
Message-ID<q7Hui-1Yb-11@gated-at.bofh.it>
In reply to#1223148
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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


#1223298

FromGuenter Roeck <linux@roeck-us.net>
Date2015-09-12 06:30 +0200
Message-ID<q7KBP-6za-7@gated-at.bofh.it>
In reply to#1223148
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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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


#1223328

FromSudip Mukherjee <sudipm.mukherjee@gmail.com>
Date2015-09-12 09:30 +0200
Message-ID<q7Nq1-27A-5@gated-at.bofh.it>
In reply to#1223148
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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


#1223426

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2015-09-12 18:00 +0200
Message-ID<q7VnA-4Zv-17@gated-at.bofh.it>
In reply to#1223328
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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


#1223429

FromMax Filippov <jcmvbkbc@gmail.com>
Date2015-09-12 18:30 +0200
Message-ID<q7VQC-5MF-11@gated-at.bofh.it>
In reply to#1223426
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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


#1223431

FromSudip Mukherjee <sudipm.mukherjee@gmail.com>
Date2015-09-12 19:40 +0200
Message-ID<q7WWm-7ke-13@gated-at.bofh.it>
In reply to#1223429
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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


#1223447

FromGuenter Roeck <linux@roeck-us.net>
Date2015-09-12 20:00 +0200
Message-ID<q7XfH-7HJ-1@gated-at.bofh.it>
In reply to#1223431
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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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


#1223448

FromSudip Mukherjee <sudipm.mukherjee@gmail.com>
Date2015-09-12 20:20 +0200
Message-ID<q7Xz3-8l6-5@gated-at.bofh.it>
In reply to#1223447
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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


#1223957

FromSudip Mukherjee <sudipm.mukherjee@gmail.com>
Date2015-09-14 11:10 +0200
Message-ID<q8xVV-1GG-43@gated-at.bofh.it>
In reply to#1223429
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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


#1229025

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2015-09-21 06:40 +0200
Message-ID<qb13s-4sC-23@gated-at.bofh.it>
In reply to#1223957
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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


Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel


csiph-web