request for stable inclusion

request for stable inclusion

[CAI Qian]

This is to request to apply the below commit for the stable releases
in order to fix a regression introduced by 055388a (xfs: dynamic
speculative EOF preallocation) that caused fsync() took long time during
the sparse file testing.

For stable-3.4 and stable-3.8, it can be applied as it is. For stable-3.0,
please see the below patch which fixed the context and used xfs_bmapi()
instead of xfs_bmapi_read() which yet in the tree. Also tested on the
stable-3.0 to confirmed the original fsync() slowness regression is now
gone. Please review and ACK.

>From a1e16c26660b301cc8423185924cf1b0b16ea92b Mon Sep 17 00:00:00 2001
From: Dave Chinner <dchinner@redhat.com>
Date: Mon, 11 Feb 2013 16:05:01 +1100
Subject: [PATCH] xfs: limit speculative prealloc size on sparse files

Speculative preallocation based on the current file size works well
for contiguous files, but is sub-optimal for sparse files where the
EOF preallocation can fill holes and result in large amounts of
zeros being written when it is not necessary.

The algorithm is modified to prevent EOF speculative preallocation
from triggering larger allocations on IO patterns of
truncate--to-zero-seek-write-seek-write-....  which results in
non-sparse files for large files. This, unfortunately, is the way cp
now behaves when copying sparse files and so needs to be fixed.

What this code does is that it looks at the existing extent adjacent
to the current EOF and if it determines that it is a hole we disable
speculative preallocation altogether. To avoid the next write from
doing a large prealloc, it takes the size of subsequent
preallocations from the current size of the existing EOF extent.
IOWs, if you leave a hole in the file, it resets preallocation
behaviour to the same as if it was a zero size file.

Example new behaviour:

$ xfs_io -f -c "pwrite 0 31m" \
            -c "pwrite 33m 1m" \
            -c "pwrite 128m 1m" \
            -c "fiemap -v" /mnt/scratch/blah
wrote 32505856/32505856 bytes at offset 0
31 MiB, 7936 ops; 0.0000 sec (1.608 GiB/sec and 421432.7439 ops/sec)
wrote 1048576/1048576 bytes at offset 34603008
1 MiB, 256 ops; 0.0000 sec (1.462 GiB/sec and 383233.5329 ops/sec)
wrote 1048576/1048576 bytes at offset 134217728
1 MiB, 256 ops; 0.0000 sec (1.719 GiB/sec and 450704.2254 ops/sec)
/mnt/scratch/blah:
 EXT: FILE-OFFSET      BLOCK-RANGE      TOTAL FLAGS
   0: [0..65535]:      96..65631        65536   0x0
   1: [65536..67583]:  hole              2048
   2: [67584..69631]:  67680..69727      2048   0x0
   3: [69632..262143]: hole             192512
   4: [262144..264191]: 262240..264287    2048   0x1

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
Signed-off-by: CAI Qian <caiqian@redhat.com>

diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
index 091d82b..c5a377c 100644
--- a/fs/xfs/xfs_iomap.c
+++ b/fs/xfs/xfs_iomap.c
@@ -321,6 +321,63 @@ xfs_iomap_eof_want_preallocate(
 }
 
 /*
+ * Determine the initial size of the preallocation. We are beyond the current
+ * EOF here, but we need to take into account whether this is a sparse write or
+ * an extending write when determining the preallocation size.  Hence we need to
+ * look up the extent that ends at the current write offset and use the result
+ * to determine the preallocation size.
+ *
+ * If the extent is a hole, then preallocation is essentially disabled.
+ * Otherwise we take the size of the preceeding data extent as the basis for the
+ * preallocation size. If the size of the extent is greater than half the
+ * maximum extent length, then use the current offset as the basis. This ensures
+ * that for large files the preallocation size always extends to MAXEXTLEN
+ * rather than falling short due to things like stripe unit/width alignment of
+ * real extents.
+ */
+STATIC int
+xfs_iomap_eof_prealloc_initial_size(
+	struct xfs_mount	*mp,
+	struct xfs_inode	*ip,
+	xfs_off_t		offset,
+	xfs_bmbt_irec_t		*imap,
+	int			nimaps)
+{
+	xfs_fileoff_t   start_fsb;
+	int		imaps = 1;
+	int		error;
+
+	ASSERT(nimaps >= imaps);
+
+	/* if we are using a specific prealloc size, return now */
+	if (mp->m_flags & XFS_MOUNT_DFLT_IOSIZE)
+		return 0;
+
+	/*
+	 * As we write multiple pages, the offset will always align to the
+	 * start of a page and hence point to a hole at EOF. i.e. if the size is
+	 * 4096 bytes, we only have one block at FSB 0, but XFS_B_TO_FSB(4096)
+	 * will return FSB 1. Hence if there are blocks in the file, we want to
+	 * point to the block prior to the EOF block and not the hole that maps
+	 * directly at @offset.
+	 */
+	start_fsb = XFS_B_TO_FSB(mp, offset);
+	if (start_fsb)
+		start_fsb--;
+	error = xfs_bmapi(NULL, ip, start_fsb, 1, XFS_BMAPI_ENTIRE, NULL, 0,
+			imap, &imaps, NULL);
+	if (error)
+		return 0;
+
+	ASSERT(imaps == 1);
+	if (imap[0].br_startblock == HOLESTARTBLOCK)
+		return 0;
+	if (imap[0].br_blockcount <= (MAXEXTLEN >> 1))
+		return imap[0].br_blockcount;
+	return XFS_B_TO_FSB(mp, offset);
+}
+
+/*
  * If we don't have a user specified preallocation size, dynamically increase
  * the preallocation size as the size of the file grows. Cap the maximum size
  * at a single extent or less if the filesystem is near full. The closer the
@@ -329,20 +386,19 @@ xfs_iomap_eof_want_preallocate(
 STATIC xfs_fsblock_t
 xfs_iomap_prealloc_size(
 	struct xfs_mount	*mp,
-	struct xfs_inode	*ip)
+	struct xfs_inode	*ip,
+	xfs_off_t		offset,
+	struct xfs_bmbt_irec	*imap,
+	int			nimaps)
 {
 	xfs_fsblock_t		alloc_blocks = 0;
 
-	if (!(mp->m_flags & XFS_MOUNT_DFLT_IOSIZE)) {
+	alloc_blocks = xfs_iomap_eof_prealloc_initial_size(mp, ip, offset,
+							   imap, nimaps);
+	if (alloc_blocks > 0) {
 		int shift = 0;
 		int64_t freesp;
 
-		/*
-		 * rounddown_pow_of_two() returns an undefined result
-		 * if we pass in alloc_blocks = 0. Hence the "+ 1" to
-		 * ensure we always pass in a non-zero value.
-		 */
-		alloc_blocks = XFS_B_TO_FSB(mp, ip->i_size) + 1;
 		alloc_blocks = XFS_FILEOFF_MIN(MAXEXTLEN,
 					rounddown_pow_of_two(alloc_blocks));
 
@@ -401,7 +457,6 @@ xfs_iomap_write_delay(
 	extsz = xfs_get_extsz_hint(ip);
 	offset_fsb = XFS_B_TO_FSBT(mp, offset);
 
-
 	error = xfs_iomap_eof_want_preallocate(mp, ip, offset, count,
 				imap, XFS_WRITE_IMAPS, &prealloc);
 	if (error)
@@ -409,7 +464,10 @@ xfs_iomap_write_delay(
 
 retry:
 	if (prealloc) {
-		xfs_fsblock_t	alloc_blocks = xfs_iomap_prealloc_size(mp, ip);
+		xfs_fsblock_t	alloc_blocks;
+
+		alloc_blocks = xfs_iomap_prealloc_size(mp, ip, offset, imap,
+						       XFS_WRITE_IMAPS);
 
 		aligned_offset = XFS_WRITEIO_ALIGN(mp, (offset + count - 1));
 		ioalign = XFS_B_TO_FSBT(mp, aligned_offset);

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: request for stable inclusion

[Dave Chinner]

On Mon, Mar 04, 2013 at 03:52:34AM -0500, CAI Qian wrote:
> This is to request to apply the below commit for the stable releases
> in order to fix a regression introduced by 055388a (xfs: dynamic
> speculative EOF preallocation) that caused fsync() took long time during
> the sparse file testing.
> 
> For stable-3.4 and stable-3.8, it can be applied as it is. For stable-3.0,
> please see the below patch which fixed the context and used xfs_bmapi()
> instead of xfs_bmapi_read() which yet in the tree. Also tested on the
> stable-3.0 to confirmed the original fsync() slowness regression is now
> gone. Please review and ACK.

I've already said no to -stable in another discussion thread, and
that discussion has not yet played out. please do not try to preempt
any discussion by sending patches to @stable before it is even
decided if it is something we *need* to fix in 2 year old kernels.
Yes, you have input into the discussion, but please do not take it
upon yourself to determine what should be backported to -stable and
what shouldn't be - that is for the subsystem maintainers to decide.

FWIW, is your memory so short that you don't remember what happened
a couple of weeks ago with the last XFS bugfix backport you
requested directly to @stable and was accepted based on "it applies
and builds, so it's OK?" i.e. without proper review, discussion or
testing?

That's right - it caused a major functional regression and that
wasted a heap of time for quite a few people in sorting it out.

So right now this request gets a big, fat, loud NACK from me while
the aforementioned discussion takes place.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: request for stable inclusion

[Ben Myers]

Hi CAI,
   
On Tue, Mar 05, 2013 at 09:11:00AM +1100, Dave Chinner wrote:
> On Mon, Mar 04, 2013 at 03:52:34AM -0500, CAI Qian wrote:
> > This is to request to apply the below commit for the stable releases
> > in order to fix a regression introduced by 055388a (xfs: dynamic
> > speculative EOF preallocation) that caused fsync() took long time during
> > the sparse file testing.
> > 
> > For stable-3.4 and stable-3.8, it can be applied as it is. For stable-3.0,
> > please see the below patch which fixed the context and used xfs_bmapi()
> > instead of xfs_bmapi_read() which yet in the tree. Also tested on the
> > stable-3.0 to confirmed the original fsync() slowness regression is now
> > gone. Please review and ACK.
> 
> I've already said no to -stable in another discussion thread, and
> that discussion has not yet played out. please do not try to preempt
> any discussion by sending patches to @stable before it is even
> decided if it is something we *need* to fix in 2 year old kernels.
> Yes, you have input into the discussion, but please do not take it
> upon yourself to determine what should be backported to -stable and
> what shouldn't be - that is for the subsystem maintainers to decide.
> 
> FWIW, is your memory so short that you don't remember what happened
> a couple of weeks ago with the last XFS bugfix backport you
> requested directly to @stable and was accepted based on "it applies
> and builds, so it's OK?" i.e. without proper review, discussion or
> testing?
> 
> That's right - it caused a major functional regression and that
> wasted a heap of time for quite a few people in sorting it out.
> 
> So right now this request gets a big, fat, loud NACK from me while
> the aforementioned discussion takes place.

I appreciate that you've been willing to do the legwork on this.  That's really
nice work, but I agree with Dave that it needs a closer look before we request
that it be picked up in -stable.  Lets get this reviewed and tested on
xfs@oss.sgi.com before bringing it to the attention of the -stable folk.  We
can continue to work through this in the other thread.  Thanks for spending the
time!  ;)

Regards,
	Ben

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Request for stable inclusion

[Kai-Heng Feng]

Hi,

Please include commit ("6cecdf7a161d drm/dp/mst: save vcpi with
payloads") to Stable tree.

In commit ("bb08c04dc867 drm/dp/mst: fix kernel oops when turning off
secondary monitor"), variable "mgr->payloads[i].vcpi" won't get update
without this patch.

bb08c04dc867 was backported to v3.18+, so this patch is also needed by v3.18+.

Thanks.

Re: Request for stable inclusion

[Greg KH]

On Thu, Oct 19, 2017 at 04:58:44PM +0800, Kai-Heng Feng wrote:
> Hi,
> 
> Please include commit ("6cecdf7a161d drm/dp/mst: save vcpi with
> payloads") to Stable tree.
> 
> In commit ("bb08c04dc867 drm/dp/mst: fix kernel oops when turning off
> secondary monitor"), variable "mgr->payloads[i].vcpi" won't get update
> without this patch.
> 
> bb08c04dc867 was backported to v3.18+, so this patch is also needed by v3.18+.

What stable tree(s) do you think this should be applied to?  If it
hasn't already been applied, odds are there was something preventing it
from going there (build error, or it doesn't apply?)

Do you have working backported versions?

thanks,

greg k-h

Re: Request for stable inclusion

[Greg KH]

On Thu, Oct 19, 2017 at 05:24:27PM +0800, Kai Heng Feng wrote:
> 
> 
> > On 19 Oct 2017, at 5:11 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > 
> > On Thu, Oct 19, 2017 at 04:58:44PM +0800, Kai-Heng Feng wrote:
> >> Hi,
> >> 
> >> Please include commit ("6cecdf7a161d drm/dp/mst: save vcpi with
> >> payloads") to Stable tree.
> >> 
> >> In commit ("bb08c04dc867 drm/dp/mst: fix kernel oops when turning off
> >> secondary monitor"), variable "mgr->payloads[i].vcpi" won't get update
> >> without this patch.
> >> 
> >> bb08c04dc867 was backported to v3.18+, so this patch is also needed by v3.18+.
> > 
> > What stable tree(s) do you think this should be applied to?  If it
> > hasn't already been applied, odds are there was something preventing it
> > from going there (build error, or it doesn't apply?)
> > 
> > Do you have working backported versions?
> 
> It should be applied to both v3.18 and v4.4. It can be cleanly cherry-picked into both linux-3.18.y and linux-4.4.y.
> 
> The patch doesn’t CC to stable, I think that’s why it didn’t get applied to stable kernels.

Ah, my appologies, I was looking at the wrong one in your email above.

> I can’t say for v3.18, but I can confirm that on v4.4, this patch is required to fix MST issue.

Now queued up, thanks.

greg k-h

Request for stable inclusion

[Thomas Gleixner]

Hi!

I forgot to tag the following two commits for stable:

dea1d0f5f128 ("smp/hotplug: Replace BUG_ON and react useful")
9cd4f1a4e7a8 ("smp/hotplug: Move unparking of percpu threads to the control CPU")

Can you please pick them up?

Sorry for the inconveniance.

      Thomas

Re: Request for stable inclusion

[Greg KH]

On Thu, Jul 20, 2017 at 04:07:44PM +0200, Thomas Gleixner wrote:
> Hi!
> 
> I forgot to tag the following two commits for stable:
> 
> dea1d0f5f128 ("smp/hotplug: Replace BUG_ON and react useful")
> 9cd4f1a4e7a8 ("smp/hotplug: Move unparking of percpu threads to the control CPU")
> 
> Can you please pick them up?

Sure, but for what kernel tree(s)?

thanks,

greg k-h

Re: Request for stable inclusion

[Thomas Gleixner]

On Thu, 20 Jul 2017, Greg KH wrote:

> On Thu, Jul 20, 2017 at 04:07:44PM +0200, Thomas Gleixner wrote:
> > Hi!
> > 
> > I forgot to tag the following two commits for stable:
> > 
> > dea1d0f5f128 ("smp/hotplug: Replace BUG_ON and react useful")
> > 9cd4f1a4e7a8 ("smp/hotplug: Move unparking of percpu threads to the control CPU")
> > 
> > Can you please pick them up?
> 
> Sure, but for what kernel tree(s)?

Fixes: 8df3e07e7f21 ("cpu/hotplug: Let upcoming cpu bring itself fully up")

# git describe --contains 8df3e07e7f21
v4.6-rc1~150^2~6

dea1d0f5f128 fixes 9cd4f1a4e7a8

Thanks,

	tglx

Re: Request for stable inclusion

[Greg KH]

On Thu, Jul 20, 2017 at 04:07:44PM +0200, Thomas Gleixner wrote:
> Hi!
> 
> I forgot to tag the following two commits for stable:
> 
> dea1d0f5f128 ("smp/hotplug: Replace BUG_ON and react useful")
> 9cd4f1a4e7a8 ("smp/hotplug: Move unparking of percpu threads to the control CPU")
> 
> Can you please pick them up?
> 

These applied to 4.12-stable, but not 4.9-stable, and I think they need
to go there too, right?  If so, can you provide backports?

thanks,

greg k-h

Re: Request for stable inclusion

[Thomas Gleixner]

On Tue, 25 Jul 2017, Greg KH wrote:
> On Thu, Jul 20, 2017 at 04:07:44PM +0200, Thomas Gleixner wrote:
> > Hi!
> > 
> > I forgot to tag the following two commits for stable:
> > 
> > dea1d0f5f128 ("smp/hotplug: Replace BUG_ON and react useful")
> > 9cd4f1a4e7a8 ("smp/hotplug: Move unparking of percpu threads to the control CPU")
> > 
> > Can you please pick them up?
> > 
> 
> These applied to 4.12-stable, but not 4.9-stable, and I think they need
> to go there too, right?  If so, can you provide backports?

Sure. Backport for 9cd4f1a4e7a8 below. dea1d0f5f128 then applies on top.

Thanks,

	tglx

8<---------------
From: Thomas Gleixner <tglx@linutronix.de>
Date: Tue Jul 4 22:20:23 2017 +0200
Subject: smp/hotplug: Move unparking of percpu threads to the control CPU

Upstream commit 9cd4f1a4e7a858849e889a081a99adff83e08e4c

Vikram reported the following backtrace:
    
   BUG: scheduling while atomic: swapper/7/0/0x00000002
   CPU: 7 PID: 0 Comm: swapper/7 Not tainted 4.9.32-perf+ #680
   schedule
   schedule_hrtimeout_range_clock
   schedule_hrtimeout
   wait_task_inactive
   __kthread_bind_mask
   __kthread_bind
   __kthread_unpark
   kthread_unpark
   cpuhp_online_idle
   cpu_startup_entry
   secondary_start_kernel

He analyzed correctly that a parked cpu hotplug thread of an offlined CPU
was still on the runqueue when the CPU came back online and tried to unpark
it. This causes the thread which invoked kthread_unpark() to call
wait_task_inactive() and subsequently schedule() with preemption disabled.
His proposed workaround was to "make sure" that a parked thread has
scheduled out when the CPU goes offline, so the situation cannot happen.

But that's still wrong because the root cause is not the fact that the
percpu thread is still on the runqueue and neither that preemption is
disabled, which could be simply solved by enabling preemption before
calling kthread_unpark().

The real issue is that the calling thread is the idle task of the upcoming
CPU, which is not supposed to call anything which might sleep.  The moron,
who wrote that code, missed completely that kthread_unpark() might end up
in schedule().

The solution is simpler than expected. The thread which controls the
hotplug operation is waiting for the CPU to call complete() on the hotplug
state completion. So the idle task of the upcoming CPU can set its state to
CPUHP_AP_ONLINE_IDLE and invoke complete(). This in turn wakes the control
task on a different CPU, which then can safely do the unpark and kick the
now unparked hotplug thread of the upcoming CPU to complete the bringup to
the final target state.

Control CPU                     AP

bringup_cpu();
  __cpu_up()  ------------>
                                bringup_ap();
  bringup_wait_for_ap()
    wait_for_completion();
                                cpuhp_online_idle();
                <------------    complete();
    unpark(AP->stopper);
    unpark(AP->hotplugthread);
                                while(1)
                                  do_idle();
    kick(AP->hotplugthread);
    wait_for_completion();      hotplug_thread()
                                  run_online_callbacks();
                                  complete();

Fixes: 8df3e07e7f21 ("cpu/hotplug: Let upcoming cpu bring itself fully up")
Reported-by: Vikram Mulukutla <markivx@codeaurora.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Cc: Sebastian Sewior <bigeasy@linutronix.de>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Tejun Heo <tj@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1707042218020.2131@nanos
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

---
 kernel/cpu.c |   37 +++++++++++++++++++------------------
 1 file changed, 19 insertions(+), 18 deletions(-)

--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -410,11 +410,25 @@ static int notify_online(unsigned int cp
 	return 0;
 }
 
+static void __cpuhp_kick_ap_work(struct cpuhp_cpu_state *st);
+
 static int bringup_wait_for_ap(unsigned int cpu)
 {
 	struct cpuhp_cpu_state *st = per_cpu_ptr(&cpuhp_state, cpu);
 
+	/* Wait for the CPU to reach CPUHP_AP_ONLINE_IDLE */
 	wait_for_completion(&st->done);
+	BUG_ON(!cpu_online(cpu));
+
+	/* Unpark the stopper thread and the hotplug thread of the target cpu */
+	stop_machine_unpark(cpu);
+	kthread_unpark(st->thread);
+
+	/* Should we go further up ? */
+	if (st->target > CPUHP_AP_ONLINE_IDLE) {
+		__cpuhp_kick_ap_work(st);
+		wait_for_completion(&st->done);
+	}
 	return st->result;
 }
 
@@ -437,9 +451,7 @@ static int bringup_cpu(unsigned int cpu)
 		cpu_notify(CPU_UP_CANCELED, cpu);
 		return ret;
 	}
-	ret = bringup_wait_for_ap(cpu);
-	BUG_ON(!cpu_online(cpu));
-	return ret;
+	return bringup_wait_for_ap(cpu);
 }
 
 /*
@@ -974,31 +986,20 @@ void notify_cpu_starting(unsigned int cp
 }
 
 /*
- * Called from the idle task. We need to set active here, so we can kick off
- * the stopper thread and unpark the smpboot threads. If the target state is
- * beyond CPUHP_AP_ONLINE_IDLE we kick cpuhp thread and let it bring up the
- * cpu further.
+ * Called from the idle task. Wake up the controlling task which brings the
+ * stopper and the hotplug thread of the upcoming CPU up and then delegates
+ * the rest of the online bringup to the hotplug thread.
  */
 void cpuhp_online_idle(enum cpuhp_state state)
 {
 	struct cpuhp_cpu_state *st = this_cpu_ptr(&cpuhp_state);
-	unsigned int cpu = smp_processor_id();
 
 	/* Happens for the boot cpu */
 	if (state != CPUHP_AP_ONLINE_IDLE)
 		return;
 
 	st->state = CPUHP_AP_ONLINE_IDLE;
-
-	/* Unpark the stopper thread and the hotplug thread of this cpu */
-	stop_machine_unpark(cpu);
-	kthread_unpark(st->thread);
-
-	/* Should we go further up ? */
-	if (st->target > CPUHP_AP_ONLINE_IDLE)
-		__cpuhp_kick_ap_work(st);
-	else
-		complete(&st->done);
+	complete(&st->done);
 }
 
 /* Requires cpu_add_remove_lock to be held */

Re: Request for stable inclusion

[Greg KH]

On Wed, Jul 26, 2017 at 10:25:24AM +0200, Thomas Gleixner wrote:
> On Tue, 25 Jul 2017, Greg KH wrote:
> > On Thu, Jul 20, 2017 at 04:07:44PM +0200, Thomas Gleixner wrote:
> > > Hi!
> > > 
> > > I forgot to tag the following two commits for stable:
> > > 
> > > dea1d0f5f128 ("smp/hotplug: Replace BUG_ON and react useful")
> > > 9cd4f1a4e7a8 ("smp/hotplug: Move unparking of percpu threads to the control CPU")
> > > 
> > > Can you please pick them up?
> > > 
> > 
> > These applied to 4.12-stable, but not 4.9-stable, and I think they need
> > to go there too, right?  If so, can you provide backports?
> 
> Sure. Backport for 9cd4f1a4e7a8 below. dea1d0f5f128 then applies on top.

Thanks, now queued up.

greg k-h

request for stable inclusion

[Or Gerlitz]

Hi Dave,

Could you please push to -stable the UAR patch (below), it allows mlx4
to run on PPC systems without hacking PCI BAR sizes. The patch
introduced small regression for people that do prefer to run non
modified VF drivers with modified host driver, and hence should be
accompanied by the  backward compatibility (below too)

76e39cc net/mlx4_core: Fix backward compatibility on VFs
85743f1 net/mlx4_core: Set UAR page size to 4KB regardless of system page size

Thanks,

Or.

request for stable inclusion

[Or Gerlitz]

Hi Dave,

Commit 9293267 "net/mlx4_core: Capping number of requested MSIXs to 
MAX_MSIX"  fixes a bug under which the driver doesn't really starts over 
a machine with > 32 cores.

The bug was introduced in 4.2-rc1 but the fix missed 4.2 -- could you 
please push it to 4.2 -stable?

If you prefer that we will submit it directly there, fine too.

thanks,

Or.

Re: request for stable inclusion

[David Miller]

From: Or Gerlitz <ogerlitz@mellanox.com>
Date: Wed, 16 Sep 2015 09:41:40 +0300

> Hi Dave,
> 
> Commit 9293267 "net/mlx4_core: Capping number of requested MSIXs to
> MAX_MSIX" fixes a bug under which the driver doesn't really starts
> over a machine with > 32 cores.
> 
> The bug was introduced in 4.2-rc1 but the fix missed 4.2 -- could you
> please push it to 4.2 -stable?

Queued up, thanks.

Request for stable inclusion

[Thomas Gleixner]

Hi,

commit b20a774495671f037e7160ea2ce8789af6b61533
Author: David Ertman <davidx.m.ertman@intel.com>
Date:   Tue Mar 25 04:27:55 2014 +0000

    e1000e: Fix no connectivity when driver loaded with cable out

fixes an issue which affects quite some of the newer Laptops and also
Desktops (e.g. AOI-PCs) which are based on mobile chipsets.

I don't know how far this reaches back, but at least the 3.13 and 3.14
kernels need this fix. Jeff, David, can you tell?

Please consider for inclusion.

Thanks,

	tglx

RE: Request for stable inclusion

[Ertman, DavidX M]

> -----Original Message-----
> From: Thomas Gleixner [mailto:tglx@linutronix.de]
> Sent: Wednesday, April 30, 2014 12:04 PM
> To: stable@vger.kernel.org
> Cc: Kirsher, Jeffrey T; Ertman, DavidX M; netdev@vger.kernel.org
> Subject: Request for stable inclusion
> 
> Hi,
> 
> commit b20a774495671f037e7160ea2ce8789af6b61533
> Author: David Ertman <davidx.m.ertman@intel.com>
> Date:   Tue Mar 25 04:27:55 2014 +0000
> 
>     e1000e: Fix no connectivity when driver loaded with cable out
> 
> fixes an issue which affects quite some of the newer Laptops and also
> Desktops (e.g. AOI-PCs) which are based on mobile chipsets.
> 
> I don't know how far this reaches back, but at least the 3.13 and 3.14
> kernels need this fix. Jeff, David, can you tell?
> 
> Please consider for inclusion.
> 
> Thanks,
> 
> 	tglx

The commit that caused the issue went into net-next on June 21, 2013.  So at least 3.11 and forward, and probably 3.10.

Dave Ertman

RE: Request for stable inclusion

[Eric Dumazet]

On Wed, 2014-04-30 at 19:40 +0000, Ertman, DavidX M wrote:

> The commit that caused the issue went into net-next on June 21, 2013.  So at least 3.11 and forward, and probably 3.10.

There is a way to know exactly the cut point :

$ git describe --contains da1e2046e5
v3.12-rc1~132^2~445^2~6

RE: Request for stable inclusion

[Thomas Gleixner]

On Wed, 30 Apr 2014, Eric Dumazet wrote:

> On Wed, 2014-04-30 at 19:40 +0000, Ertman, DavidX M wrote:
> 
> > The commit that caused the issue went into net-next on June 21, 2013.  So at least 3.11 and forward, and probably 3.10.
> 
> There is a way to know exactly the cut point :
> 
> $ git describe --contains da1e2046e5
> v3.12-rc1~132^2~445^2~6

So 3.12+ is affected.

RE: Request for stable inclusion

[Ertman, DavidX M]

> -----Original Message-----
> From: Thomas Gleixner [mailto:tglx@linutronix.de]
> Sent: Wednesday, April 30, 2014 1:37 PM
> To: Eric Dumazet
> Cc: Ertman, DavidX M; stable@vger.kernel.org; Kirsher, Jeffrey T;
> netdev@vger.kernel.org
> Subject: RE: Request for stable inclusion
> 
> On Wed, 30 Apr 2014, Eric Dumazet wrote:
> 
> > On Wed, 2014-04-30 at 19:40 +0000, Ertman, DavidX M wrote:
> >
> > > The commit that caused the issue went into net-next on June 21, 2013.
> So at least 3.11 and forward, and probably 3.10.
> >
> > There is a way to know exactly the cut point :
> >
> > $ git describe --contains da1e2046e5
> > v3.12-rc1~132^2~445^2~6
> 
> So 3.12+ is affected.

Yes, sorry about that.  I was looking at when it got committed into an internal queue as opposed to taken into Linus's tree.  Silly mistake.

Dave Ertman

Re: Request for stable inclusion

[Jiri Slaby]

On 04/30/2014 09:03 PM, Thomas Gleixner wrote:
> Hi,
> 
> commit b20a774495671f037e7160ea2ce8789af6b61533
> Author: David Ertman <davidx.m.ertman@intel.com>
> Date:   Tue Mar 25 04:27:55 2014 +0000
> 
>     e1000e: Fix no connectivity when driver loaded with cable out

Now applied to 3.12. Thanks.

-- 
js
suse labs

Re: Request for stable inclusion

[Greg KH]

On Wed, Apr 30, 2014 at 09:03:36PM +0200, Thomas Gleixner wrote:
> Hi,
> 
> commit b20a774495671f037e7160ea2ce8789af6b61533
> Author: David Ertman <davidx.m.ertman@intel.com>
> Date:   Tue Mar 25 04:27:55 2014 +0000
> 
>     e1000e: Fix no connectivity when driver loaded with cable out
> 
> fixes an issue which affects quite some of the newer Laptops and also
> Desktops (e.g. AOI-PCs) which are based on mobile chipsets.
> 
> I don't know how far this reaches back, but at least the 3.13 and 3.14
> kernels need this fix. Jeff, David, can you tell?

Now applied to 3.14-stable, thanks.

greg k-h

request for stable inclusion

[Yijing Wang]

Hi Greg, Jiri or Liang Li

384e301e3519599b000c1a2ecd938b533fc15d85
pch_uart: fix a deadlock when pch_uart as console

This looks applicable to stable-3.4, and it
was built successful for me. What do you think?

Thanks!
Yijing.

request for stable inclusion

[Yijing Wang]

Hi Greg, Jiri or Liang Li

384e301e3519599b000c1a2ecd938b533fc15d85
pch_uart: fix a deadlock when pch_uart as console

This looks applicable to stable-3.4, and it
was built successful for me. What do you think?

Thanks!
Yijing.

Re: request for stable inclusion

[Luis Henriques]

Yijing Wang <wangyijing@huawei.com> writes:

> Hi Greg, Jiri or Liang Li
>
> 384e301e3519599b000c1a2ecd938b533fc15d85
> pch_uart: fix a deadlock when pch_uart as console
>
> This looks applicable to stable-3.4, and it
> was built successful for me. What do you think?
>
> Thanks!
> Yijing.
>
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

I'm queuing it for the 3.5 as well.

Also, this seems to be applicable to older kernels as well.

Cheers,
-- 
Luis

Re: request for stable inclusion

[Luis Henriques]

Yijing Wang <wangyijing@huawei.com> writes:

> Hi Greg, Jiri or Liang Li
>
> 384e301e3519599b000c1a2ecd938b533fc15d85
> pch_uart: fix a deadlock when pch_uart as console
>
> This looks applicable to stable-3.4, and it
> was built successful for me. What do you think?
>
> Thanks!
> Yijing.
>
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

I'm queuing it for the 3.5 as well.

Also, this seems to be applicable to older kernels as well.

Cheers,
-- 
Luis

Re: request for stable inclusion

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 435 bytes --]

On Fri, 2013-06-28 at 17:04 +0800, Yijing Wang wrote:
> Hi Greg, Jiri or Liang Li
> 
> 384e301e3519599b000c1a2ecd938b533fc15d85
> pch_uart: fix a deadlock when pch_uart as console
> 
> This looks applicable to stable-3.4, and it
> was built successful for me. What do you think?

I've queued this up for 3.2 as well, thanks.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

request for stable inclusion

[CAI Qian]

Hello David,

9c13cb8bb477a83b9a3c9e5a5478a4e21294a760
tg3: Avoid null pointer dereference in tg3_interrupt in netconsole mode

daf3ec688e057f6060fb9bb0819feac7a8bbf45c
tg3: Fix crc errors on jumbo frame receive

The above 2 commits looks like missing from the stable and the netdev
stable queues. It was observed that the above issues can be reproduced in
a kernel that as old as a 2.6.32-based fedora kernel, so I'd like to request
to include them for 3.0.y, 3.4.y and 3.7.y.

1e47ee8367babe6a5e8adf44a714c7086657b87e
netfilter: nf_conntrack: fix BUG_ON while removing nf_conntrack with netns

This one looks like a candidate for 3.7-stable but also missing from the
queues. Do you agree?

Regards,
CAI Qian

Re: request for stable inclusion

[David Miller]

From: CAI Qian <caiqian@redhat.com>
Date: Wed, 30 Jan 2013 01:16:15 -0500 (EST)

> 9c13cb8bb477a83b9a3c9e5a5478a4e21294a760
> tg3: Avoid null pointer dereference in tg3_interrupt in netconsole mode
> 
> daf3ec688e057f6060fb9bb0819feac7a8bbf45c
> tg3: Fix crc errors on jumbo frame receive
> 
> The above 2 commits looks like missing from the stable and the netdev
> stable queues. It was observed that the above issues can be reproduced in
> a kernel that as old as a 2.6.32-based fedora kernel, so I'd like to request
> to include them for 3.0.y, 3.4.y and 3.7.y.

Done.

> 1e47ee8367babe6a5e8adf44a714c7086657b87e
> netfilter: nf_conntrack: fix BUG_ON while removing nf_conntrack with netns
> 
> This one looks like a candidate for 3.7-stable but also missing from the
> queues. Do you agree?

This has already been merged.