This is the start of the stable review cycle for the 3.16.5 release.
There are 26 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Thu Oct 9 23:18:40 UTC 2014.
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.0/stable-review/patch-3.16.5-rc1.gz
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 3.16.5-rc1
Andrew Hunter <[email protected]>
jiffies: Fix timeval conversion to jiffies
Hans Verkuil <[email protected]>
media: vb2: fix VBI/poll regression
Mel Gorman <[email protected]>
mm: numa: Do not mark PTEs pte_numa when splitting huge pages
Waiman Long <[email protected]>
mm, thp: move invariant bug check out of loop in __split_huge_page_map
Bruno Prémont <[email protected]>
vgaarb: Don't default exclusively to first video device with mem+io
Bruno Prémont <[email protected]>
x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()
Hans de Goede <[email protected]>
uas: Add missing le16_to_cpu calls to asm1051 / asm1053 usb-id check
Hans de Goede <[email protected]>
uas: Disable uas on ASM1051 devices
Hans de Goede <[email protected]>
uas: Log a warning when we cannot use uas because the hcd lacks streams
Hans de Goede <[email protected]>
uas: Only complain about missing sg if all other checks succeed
Steven Rostedt (Red Hat) <[email protected]>
ring-buffer: Fix infinite spin in reading buffer
Josh Triplett <[email protected]>
init/Kconfig: Fix HAVE_FUTEX_CMPXCHG to not break up the EXPERT menu
Steve French <[email protected]>
Fix problem recognizing symlinks
Chris Wilson <[email protected]>
drm/i915: Flush the PTEs after updating them before suspend
NeilBrown <[email protected]>
md/raid5: disable 'DISCARD' by default due to safety concerns.
Rafael J. Wysocki <[email protected]>
cpufreq: pcc-cpufreq: Fix wait_event() under spinlock
Arnd Bergmann <[email protected]>
cpufreq: integrator: fix integrator_cpufreq_remove return type
Aaron Lu <[email protected]>
ACPI / i915: Update the condition to ignore firmware backlight change request
Alexandru M Stan <[email protected]>
i2c: rk3x: fix 0 length write transfers
Andy Gross <[email protected]>
i2c: qup: Fix order of runtime pm initialization
Mel Gorman <[email protected]>
mm: migrate: Close race between migration completion and mprotect
Johannes Weiner <[email protected]>
mm: memcontrol: do not iterate uninitialized memcgs
Peter Zijlstra <[email protected]>
perf: fix perf bug in fork()
Xiubo Li <[email protected]>
ASoC: core: fix possible ZERO_SIZE_PTR pointer dereferencing error.
Stefan Kristiansson <[email protected]>
ASoC: ssm2602: do not hardcode type to SSM2602
Jan Kara <[email protected]>
udf: Avoid infinite loop when processing indirect ICBs
-------------
Diffstat:
Makefile | 4 +-
arch/ia64/pci/fixup.c | 4 +-
arch/x86/include/asm/vga.h | 6 ---
arch/x86/pci/fixup.c | 3 +-
drivers/cpufreq/integrator-cpufreq.c | 4 +-
drivers/cpufreq/pcc-cpufreq.c | 2 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 14 ++++++-
drivers/gpu/drm/i915/intel_opregion.c | 16 +++++---
drivers/gpu/vga/vgaarb.c | 38 +++++++++++++++++-
drivers/i2c/busses/i2c-qup.c | 12 ++++--
drivers/i2c/busses/i2c-rk3x.c | 2 +-
drivers/md/raid5.c | 18 ++++++++-
drivers/media/v4l2-core/videobuf2-core.c | 15 ++++++-
drivers/usb/storage/uas-detect.h | 67 ++++++++++++++++++++------------
drivers/video/fbdev/efifb.c | 39 -------------------
fs/cifs/smb1ops.c | 2 +-
fs/cifs/smb2maperror.c | 2 +
fs/udf/inode.c | 35 ++++++++++-------
include/linux/jiffies.h | 12 ------
include/media/videobuf2-core.h | 4 ++
init/Kconfig | 1 +
kernel/events/core.c | 4 +-
kernel/fork.c | 5 ++-
kernel/time.c | 54 +++++++++++++------------
kernel/trace/ring_buffer.c | 2 +-
mm/huge_memory.c | 11 ++++--
mm/memcontrol.c | 36 ++++++++++++++---
mm/migrate.c | 5 ++-
sound/soc/codecs/ssm2602.c | 2 +-
sound/soc/soc-core.c | 2 +-
30 files changed, 260 insertions(+), 161 deletions(-)
3.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <[email protected]>
commit d62dbf77f7dfaa6fb455b4b9828069a11965929c upstream.
When building this driver as a module, we get a helpful warning
about the return type:
drivers/cpufreq/integrator-cpufreq.c:232:2: warning: initialization from incompatible pointer type
.remove = __exit_p(integrator_cpufreq_remove),
If the remove callback returns void, the caller gets an undefined
value as it expects an integer to be returned. This fixes the
problem by passing down the value from cpufreq_unregister_driver.
Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/cpufreq/integrator-cpufreq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/cpufreq/integrator-cpufreq.c
+++ b/drivers/cpufreq/integrator-cpufreq.c
@@ -213,9 +213,9 @@ static int __init integrator_cpufreq_pro
return cpufreq_register_driver(&integrator_driver);
}
-static void __exit integrator_cpufreq_remove(struct platform_device *pdev)
+static int __exit integrator_cpufreq_remove(struct platform_device *pdev)
{
- cpufreq_unregister_driver(&integrator_driver);
+ return cpufreq_unregister_driver(&integrator_driver);
}
static const struct of_device_id integrator_cpufreq_match[] = {
3.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <[email protected]>
commit 43508be512661c905d0320ee73e0b65ef36d2459 upstream.
So that an user who wants to use uas can see why he is not getting uas.
Also move the check down so that we don't warn if there are other reasons
why uas cannot work.
Signed-off-by: Hans de Goede <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/storage/uas-detect.h | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
--- a/drivers/usb/storage/uas-detect.h
+++ b/drivers/usb/storage/uas-detect.h
@@ -64,9 +64,6 @@ static int uas_use_uas_driver(struct usb
if (flags & US_FL_IGNORE_UAS)
return 0;
- if (udev->speed >= USB_SPEED_SUPER && !hcd->can_do_streams)
- return 0;
-
alt = uas_find_uas_alt_setting(intf);
if (alt < 0)
return 0;
@@ -84,5 +81,14 @@ static int uas_use_uas_driver(struct usb
return 0;
}
+ if (udev->speed >= USB_SPEED_SUPER && !hcd->can_do_streams) {
+ dev_warn(&udev->dev,
+ "USB controller %s does not support streams, which are required by the UAS driver.\n",
+ hcd_to_bus(hcd)->bus_name);
+ dev_warn(&udev->dev,
+ "Please try an other USB controller if you wish to use UAS.\n");
+ return 0;
+ }
+
return 1;
}
3.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrew Hunter <[email protected]>
commit d78c9300c51d6ceed9f6d078d4e9366f259de28c upstream.
timeval_to_jiffies tried to round a timeval up to an integral number
of jiffies, but the logic for doing so was incorrect: intervals
corresponding to exactly N jiffies would become N+1. This manifested
itself particularly repeatedly stopping/starting an itimer:
setitimer(ITIMER_PROF, &val, NULL);
setitimer(ITIMER_PROF, NULL, &val);
would add a full tick to val, _even if it was exactly representable in
terms of jiffies_ (say, the result of a previous rounding.) Doing
this repeatedly would cause unbounded growth in val. So fix the math.
Here's what was wrong with the conversion: we essentially computed
(eliding seconds)
jiffies = usec * (NSEC_PER_USEC/TICK_NSEC)
by using scaling arithmetic, which took the best approximation of
NSEC_PER_USEC/TICK_NSEC with denominator of 2^USEC_JIFFIE_SC =
x/(2^USEC_JIFFIE_SC), and computed:
jiffies = (usec * x) >> USEC_JIFFIE_SC
and rounded this calculation up in the intermediate form (since we
can't necessarily exactly represent TICK_NSEC in usec.) But the
scaling arithmetic is a (very slight) *over*approximation of the true
value; that is, instead of dividing by (1 usec/ 1 jiffie), we
effectively divided by (1 usec/1 jiffie)-epsilon (rounding
down). This would normally be fine, but we want to round timeouts up,
and we did so by adding 2^USEC_JIFFIE_SC - 1 before the shift; this
would be fine if our division was exact, but dividing this by the
slightly smaller factor was equivalent to adding just _over_ 1 to the
final result (instead of just _under_ 1, as desired.)
In particular, with HZ=1000, we consistently computed that 10000 usec
was 11 jiffies; the same was true for any exact multiple of
TICK_NSEC.
We could possibly still round in the intermediate form, adding
something less than 2^USEC_JIFFIE_SC - 1, but easier still is to
convert usec->nsec, round in nanoseconds, and then convert using
time*spec*_to_jiffies. This adds one constant multiplication, and is
not observably slower in microbenchmarks on recent x86 hardware.
Tested: the following program:
int main() {
struct itimerval zero = {{0, 0}, {0, 0}};
/* Initially set to 10 ms. */
struct itimerval initial = zero;
initial.it_interval.tv_usec = 10000;
setitimer(ITIMER_PROF, &initial, NULL);
/* Save and restore several times. */
for (size_t i = 0; i < 10; ++i) {
struct itimerval prev;
setitimer(ITIMER_PROF, &zero, &prev);
/* on old kernels, this goes up by TICK_USEC every iteration */
printf("previous value: %ld %ld %ld %ld\n",
prev.it_interval.tv_sec, prev.it_interval.tv_usec,
prev.it_value.tv_sec, prev.it_value.tv_usec);
setitimer(ITIMER_PROF, &prev, NULL);
}
return 0;
}
Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Paul Turner <[email protected]>
Cc: Richard Cochran <[email protected]>
Cc: Prarit Bhargava <[email protected]>
Reviewed-by: Paul Turner <[email protected]>
Reported-by: Aaron Jacobs <[email protected]>
Signed-off-by: Andrew Hunter <[email protected]>
[jstultz: Tweaked to apply to 3.17-rc]
Signed-off-by: John Stultz <[email protected]>
[bwh: Backported to 3.16: adjust filename]
Signed-off-by: Ben Hutchings <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/linux/jiffies.h | 12 ----------
kernel/time.c | 54 ++++++++++++++++++++++++++----------------------
2 files changed, 30 insertions(+), 36 deletions(-)
--- a/include/linux/jiffies.h
+++ b/include/linux/jiffies.h
@@ -258,23 +258,11 @@ extern unsigned long preset_lpj;
#define SEC_JIFFIE_SC (32 - SHIFT_HZ)
#endif
#define NSEC_JIFFIE_SC (SEC_JIFFIE_SC + 29)
-#define USEC_JIFFIE_SC (SEC_JIFFIE_SC + 19)
#define SEC_CONVERSION ((unsigned long)((((u64)NSEC_PER_SEC << SEC_JIFFIE_SC) +\
TICK_NSEC -1) / (u64)TICK_NSEC))
#define NSEC_CONVERSION ((unsigned long)((((u64)1 << NSEC_JIFFIE_SC) +\
TICK_NSEC -1) / (u64)TICK_NSEC))
-#define USEC_CONVERSION \
- ((unsigned long)((((u64)NSEC_PER_USEC << USEC_JIFFIE_SC) +\
- TICK_NSEC -1) / (u64)TICK_NSEC))
-/*
- * USEC_ROUND is used in the timeval to jiffie conversion. See there
- * for more details. It is the scaled resolution rounding value. Note
- * that it is a 64-bit value. Since, when it is applied, we are already
- * in jiffies (albit scaled), it is nothing but the bits we will shift
- * off.
- */
-#define USEC_ROUND (u64)(((u64)1 << USEC_JIFFIE_SC) - 1)
/*
* The maximum jiffie value is (MAX_INT >> 1). Here we translate that
* into seconds. The 64-bit case will overflow if we are not careful,
--- a/kernel/time.c
+++ b/kernel/time.c
@@ -496,17 +496,20 @@ EXPORT_SYMBOL(usecs_to_jiffies);
* that a remainder subtract here would not do the right thing as the
* resolution values don't fall on second boundries. I.e. the line:
* nsec -= nsec % TICK_NSEC; is NOT a correct resolution rounding.
+ * Note that due to the small error in the multiplier here, this
+ * rounding is incorrect for sufficiently large values of tv_nsec, but
+ * well formed timespecs should have tv_nsec < NSEC_PER_SEC, so we're
+ * OK.
*
* Rather, we just shift the bits off the right.
*
* The >> (NSEC_JIFFIE_SC - SEC_JIFFIE_SC) converts the scaled nsec
* value to a scaled second value.
*/
-unsigned long
-timespec_to_jiffies(const struct timespec *value)
+static unsigned long
+__timespec_to_jiffies(unsigned long sec, long nsec)
{
- unsigned long sec = value->tv_sec;
- long nsec = value->tv_nsec + TICK_NSEC - 1;
+ nsec = nsec + TICK_NSEC - 1;
if (sec >= MAX_SEC_IN_JIFFIES){
sec = MAX_SEC_IN_JIFFIES;
@@ -517,6 +520,13 @@ timespec_to_jiffies(const struct timespe
(NSEC_JIFFIE_SC - SEC_JIFFIE_SC))) >> SEC_JIFFIE_SC;
}
+
+unsigned long
+timespec_to_jiffies(const struct timespec *value)
+{
+ return __timespec_to_jiffies(value->tv_sec, value->tv_nsec);
+}
+
EXPORT_SYMBOL(timespec_to_jiffies);
void
@@ -533,31 +543,27 @@ jiffies_to_timespec(const unsigned long
}
EXPORT_SYMBOL(jiffies_to_timespec);
-/* Same for "timeval"
+/*
+ * We could use a similar algorithm to timespec_to_jiffies (with a
+ * different multiplier for usec instead of nsec). But this has a
+ * problem with rounding: we can't exactly add TICK_NSEC - 1 to the
+ * usec value, since it's not necessarily integral.
+ *
+ * We could instead round in the intermediate scaled representation
+ * (i.e. in units of 1/2^(large scale) jiffies) but that's also
+ * perilous: the scaling introduces a small positive error, which
+ * combined with a division-rounding-upward (i.e. adding 2^(scale) - 1
+ * units to the intermediate before shifting) leads to accidental
+ * overflow and overestimates.
*
- * Well, almost. The problem here is that the real system resolution is
- * in nanoseconds and the value being converted is in micro seconds.
- * Also for some machines (those that use HZ = 1024, in-particular),
- * there is a LARGE error in the tick size in microseconds.
-
- * The solution we use is to do the rounding AFTER we convert the
- * microsecond part. Thus the USEC_ROUND, the bits to be shifted off.
- * Instruction wise, this should cost only an additional add with carry
- * instruction above the way it was done above.
+ * At the cost of one additional multiplication by a constant, just
+ * use the timespec implementation.
*/
unsigned long
timeval_to_jiffies(const struct timeval *value)
{
- unsigned long sec = value->tv_sec;
- long usec = value->tv_usec;
-
- if (sec >= MAX_SEC_IN_JIFFIES){
- sec = MAX_SEC_IN_JIFFIES;
- usec = 0;
- }
- return (((u64)sec * SEC_CONVERSION) +
- (((u64)usec * USEC_CONVERSION + USEC_ROUND) >>
- (USEC_JIFFIE_SC - SEC_JIFFIE_SC))) >> SEC_JIFFIE_SC;
+ return __timespec_to_jiffies(value->tv_sec,
+ value->tv_usec * NSEC_PER_USEC);
}
EXPORT_SYMBOL(timeval_to_jiffies);
3.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mel Gorman <[email protected]>
commit abc40bd2eeb77eb7c2effcaf63154aad929a1d5f upstream.
This patch reverts 1ba6e0b50b ("mm: numa: split_huge_page: transfer the
NUMA type from the pmd to the pte"). If a huge page is being split due
a protection change and the tail will be in a PROT_NONE vma then NUMA
hinting PTEs are temporarily created in the protected VMA.
VM_RW|VM_PROTNONE
|-----------------|
^
split here
In the specific case above, it should get fixed up by change_pte_range()
but there is a window of opportunity for weirdness to happen. Similarly,
if a huge page is shrunk and split during a protection update but before
pmd_numa is cleared then a pte_numa can be left behind.
Instead of adding complexity trying to deal with the case, this patch
will not mark PTEs NUMA when splitting a huge page. NUMA hinting faults
will not be triggered which is marginal in comparison to the complexity
in dealing with the corner cases during THP split.
Signed-off-by: Mel Gorman <[email protected]>
Acked-by: Rik van Riel <[email protected]>
Acked-by: Kirill A. Shutemov <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
mm/huge_memory.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1782,14 +1782,17 @@ static int __split_huge_page_map(struct
for (i = 0; i < HPAGE_PMD_NR; i++, haddr += PAGE_SIZE) {
pte_t *pte, entry;
BUG_ON(PageCompound(page+i));
+ /*
+ * Note that pmd_numa is not transferred deliberately
+ * to avoid any possibility that pte_numa leaks to
+ * a PROT_NONE VMA by accident.
+ */
entry = mk_pte(page + i, vma->vm_page_prot);
entry = maybe_mkwrite(pte_mkdirty(entry), vma);
if (!pmd_write(*pmd))
entry = pte_wrprotect(entry);
if (!pmd_young(*pmd))
entry = pte_mkold(entry);
- if (pmd_numa(*pmd))
- entry = pte_mknuma(entry);
pte = pte_offset_map(&_pmd, haddr);
BUG_ON(!pte_none(*pte));
set_pte_at(mm, haddr, pte, entry);
3.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans Verkuil <[email protected]>
commit 58d75f4b1ce26324b4d809b18f94819843a98731 upstream.
The recent conversion of saa7134 to vb2 unconvered a poll() bug that
broke the teletext applications alevt and mtt. These applications
expect that calling poll() without having called VIDIOC_STREAMON will
cause poll() to return POLLERR. That did not happen in vb2.
This patch fixes that behavior. It also fixes what should happen when
poll() is called when STREAMON is called but no buffers have been
queued. In that case poll() will also return POLLERR, but only for
capture queues since output queues will always return POLLOUT
anyway in that situation.
This brings the vb2 behavior in line with the old videobuf behavior.
Signed-off-by: Hans Verkuil <[email protected]>
Acked-by: Laurent Pinchart <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/v4l2-core/videobuf2-core.c | 15 +++++++++++++--
include/media/videobuf2-core.h | 4 ++++
2 files changed, 17 insertions(+), 2 deletions(-)
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -967,6 +967,7 @@ static int __reqbufs(struct vb2_queue *q
* to the userspace.
*/
req->count = allocated_buffers;
+ q->waiting_for_buffers = !V4L2_TYPE_IS_OUTPUT(q->type);
return 0;
}
@@ -1014,6 +1015,7 @@ static int __create_bufs(struct vb2_queu
memset(q->plane_sizes, 0, sizeof(q->plane_sizes));
memset(q->alloc_ctx, 0, sizeof(q->alloc_ctx));
q->memory = create->memory;
+ q->waiting_for_buffers = !V4L2_TYPE_IS_OUTPUT(q->type);
}
num_buffers = min(create->count, VIDEO_MAX_FRAME - q->num_buffers);
@@ -1812,6 +1814,7 @@ static int vb2_internal_qbuf(struct vb2_
*/
list_add_tail(&vb->queued_entry, &q->queued_list);
q->queued_count++;
+ q->waiting_for_buffers = false;
vb->state = VB2_BUF_STATE_QUEUED;
if (V4L2_TYPE_IS_OUTPUT(q->type)) {
/*
@@ -2244,6 +2247,7 @@ static int vb2_internal_streamoff(struct
* their normal dequeued state.
*/
__vb2_queue_cancel(q);
+ q->waiting_for_buffers = !V4L2_TYPE_IS_OUTPUT(q->type);
dprintk(3, "successful\n");
return 0;
@@ -2562,9 +2566,16 @@ unsigned int vb2_poll(struct vb2_queue *
}
/*
- * There is nothing to wait for if no buffers have already been queued.
+ * There is nothing to wait for if the queue isn't streaming.
*/
- if (list_empty(&q->queued_list))
+ if (!vb2_is_streaming(q))
+ return res | POLLERR;
+ /*
+ * For compatibility with vb1: if QBUF hasn't been called yet, then
+ * return POLLERR as well. This only affects capture queues, output
+ * queues will always initialize waiting_for_buffers to false.
+ */
+ if (q->waiting_for_buffers)
return res | POLLERR;
if (list_empty(&q->done_list))
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -375,6 +375,9 @@ struct v4l2_fh;
* @streaming: current streaming state
* @start_streaming_called: start_streaming() was called successfully and we
* started streaming.
+ * @waiting_for_buffers: used in poll() to check if vb2 is still waiting for
+ * buffers. Only set for capture queues if qbuf has not yet been
+ * called since poll() needs to return POLLERR in that situation.
* @fileio: file io emulator internal data, used only if emulator is active
* @threadio: thread io internal data, used only if thread is active
*/
@@ -411,6 +414,7 @@ struct vb2_queue {
unsigned int streaming:1;
unsigned int start_streaming_called:1;
+ unsigned int waiting_for_buffers:1;
struct vb2_fileio_data *fileio;
struct vb2_threadio_data *threadio;
3.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <[email protected]>
commit cc4deafc86f75f4e716b37fb4ea3572eb1e49e50 upstream.
Don't complain about controllers without sg support if there are other
reasons why uas cannot be used anyways.
Signed-off-by: Hans de Goede <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/storage/uas-detect.h | 28 ++++++++++------------------
1 file changed, 10 insertions(+), 18 deletions(-)
--- a/drivers/usb/storage/uas-detect.h
+++ b/drivers/usb/storage/uas-detect.h
@@ -9,32 +9,15 @@ static int uas_is_interface(struct usb_h
intf->desc.bInterfaceProtocol == USB_PR_UAS);
}
-static int uas_isnt_supported(struct usb_device *udev)
-{
- struct usb_hcd *hcd = bus_to_hcd(udev->bus);
-
- dev_warn(&udev->dev, "The driver for the USB controller %s does not "
- "support scatter-gather which is\n",
- hcd->driver->description);
- dev_warn(&udev->dev, "required by the UAS driver. Please try an"
- "alternative USB controller if you wish to use UAS.\n");
- return -ENODEV;
-}
-
static int uas_find_uas_alt_setting(struct usb_interface *intf)
{
int i;
- struct usb_device *udev = interface_to_usbdev(intf);
- int sg_supported = udev->bus->sg_tablesize != 0;
for (i = 0; i < intf->num_altsetting; i++) {
struct usb_host_interface *alt = &intf->altsetting[i];
- if (uas_is_interface(alt)) {
- if (!sg_supported)
- return uas_isnt_supported(udev);
+ if (uas_is_interface(alt))
return alt->desc.bAlternateSetting;
- }
}
return -ENODEV;
@@ -92,5 +75,14 @@ static int uas_use_uas_driver(struct usb
if (r < 0)
return 0;
+ if (udev->bus->sg_tablesize == 0) {
+ dev_warn(&udev->dev,
+ "The driver for the USB controller %s does not support scatter-gather which is\n",
+ hcd->driver->description);
+ dev_warn(&udev->dev,
+ "required by the UAS driver. Please try an other USB controller if you wish to use UAS.\n");
+ return 0;
+ }
+
return 1;
}
3.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Waiman Long <[email protected]>
commit f8303c2582b889351e261ff18c4d8eb197a77db2 upstream.
In __split_huge_page_map(), the check for page_mapcount(page) is
invariant within the for loop. Because of the fact that the macro is
implemented using atomic_read(), the redundant check cannot be optimized
away by the compiler leading to unnecessary read to the page structure.
This patch moves the invariant bug check out of the loop so that it will
be done only once. On a 3.16-rc1 based kernel, the execution time of a
microbenchmark that broke up 1000 transparent huge pages using munmap()
had an execution time of 38,245us and 38,548us with and without the
patch respectively. The performance gain is about 1%.
Signed-off-by: Waiman Long <[email protected]>
Acked-by: Kirill A. Shutemov <[email protected]>
Cc: Andrea Arcangeli <[email protected]>
Cc: Mel Gorman <[email protected]>
Cc: Rik van Riel <[email protected]>
Cc: Scott J Norton <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
mm/huge_memory.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1775,6 +1775,8 @@ static int __split_huge_page_map(struct
if (pmd) {
pgtable = pgtable_trans_huge_withdraw(mm, pmd);
pmd_populate(mm, &_pmd, pgtable);
+ if (pmd_write(*pmd))
+ BUG_ON(page_mapcount(page) != 1);
haddr = address;
for (i = 0; i < HPAGE_PMD_NR; i++, haddr += PAGE_SIZE) {
@@ -1784,8 +1786,6 @@ static int __split_huge_page_map(struct
entry = maybe_mkwrite(pte_mkdirty(entry), vma);
if (!pmd_write(*pmd))
entry = pte_wrprotect(entry);
- else
- BUG_ON(page_mapcount(page) != 1);
if (!pmd_young(*pmd))
entry = pte_mkold(entry);
if (pmd_numa(*pmd))
3.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <[email protected]>
commit a9c54caa456dccba938005f6479892b589975e6a upstream.
There are a large numbers of issues with ASM1051 devices in uas mode:
1) They do not support REPORT SUPPORTED OPERATION CODES
2) They use out of spec 8 byte status iu-s when they have no sense data,
switching to normal 16 byte status iu-s when they do have sense data.
3) They hang / crash when combined with some disks, e.g. a Crucial M500 ssd.
4) They hang / crash when stressed (through e.g. sg_reset --bus) with disks
with which then normally do work (once 1 & 2 are worked around).
Where as in BOT mode they appear to work fine, so the best way forward with
these devices is to just blacklist them for uas usage.
Unfortunately this is easier said then done. as older versions of the ASM1053
(which works fine) use the same usb-id as the ASM1051.
When connected over USB-3 the 2 can be told apart by the number of streams
they support. So this patch adds some less then pretty code to disable uas for
the ASM1051. When connected over USB-2, simply disable uas alltogether for
devices with the shared usb-id.
Cc: [email protected] # 3.16
Signed-off-by: Hans de Goede <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/storage/uas-detect.h | 27 +++++++++++++++++++++++----
1 file changed, 23 insertions(+), 4 deletions(-)
--- a/drivers/usb/storage/uas-detect.h
+++ b/drivers/usb/storage/uas-detect.h
@@ -59,10 +59,6 @@ static int uas_use_uas_driver(struct usb
unsigned long flags = id->driver_info;
int r, alt;
- usb_stor_adjust_quirks(udev, &flags);
-
- if (flags & US_FL_IGNORE_UAS)
- return 0;
alt = uas_find_uas_alt_setting(intf);
if (alt < 0)
@@ -72,6 +68,29 @@ static int uas_use_uas_driver(struct usb
if (r < 0)
return 0;
+ /*
+ * ASM1051 and older ASM1053 devices have the same usb-id, and UAS is
+ * broken on the ASM1051, use the number of streams to differentiate.
+ * New ASM1053-s also support 32 streams, but have a different prod-id.
+ */
+ if (udev->descriptor.idVendor == 0x174c &&
+ udev->descriptor.idProduct == 0x55aa) {
+ if (udev->speed < USB_SPEED_SUPER) {
+ /* No streams info, assume ASM1051 */
+ flags |= US_FL_IGNORE_UAS;
+ } else if (usb_ss_max_streams(&eps[1]->ss_ep_comp) == 32) {
+ flags |= US_FL_IGNORE_UAS;
+ }
+ }
+
+ usb_stor_adjust_quirks(udev, &flags);
+
+ if (flags & US_FL_IGNORE_UAS) {
+ dev_warn(&udev->dev,
+ "UAS is blacklisted for this device, using usb-storage instead\n");
+ return 0;
+ }
+
if (udev->bus->sg_tablesize == 0) {
dev_warn(&udev->dev,
"The driver for the USB controller %s does not support scatter-gather which is\n",
3.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <[email protected]>
commit a79e5bc53a9519202dfad7d916761601fcbf8db1 upstream.
Reported-by: kbuild test robot <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/storage/uas-detect.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/usb/storage/uas-detect.h
+++ b/drivers/usb/storage/uas-detect.h
@@ -73,8 +73,8 @@ static int uas_use_uas_driver(struct usb
* broken on the ASM1051, use the number of streams to differentiate.
* New ASM1053-s also support 32 streams, but have a different prod-id.
*/
- if (udev->descriptor.idVendor == 0x174c &&
- udev->descriptor.idProduct == 0x55aa) {
+ if (le16_to_cpu(udev->descriptor.idVendor) == 0x174c &&
+ le16_to_cpu(udev->descriptor.idProduct) == 0x55aa) {
if (udev->speed < USB_SPEED_SUPER) {
/* No streams info, assume ASM1051 */
flags |= US_FL_IGNORE_UAS;
3.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steve French <[email protected]>
commit 19e81573fca7b87ced7701e01ba164b968d929bd upstream.
Changeset eb85d94bd introduced a problem where if a cifs open
fails during query info of a file we
will still try to close the file (happens with certain types
of reparse points) even though the file handle is not valid.
In addition for SMB2/SMB3 we were not mapping the return code returned
by Windows when trying to open a file (like a Windows NFS symlink)
which is a reparse point.
Signed-off-by: Steve French <[email protected]>
Reviewed-by: Pavel Shilovsky <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/cifs/smb1ops.c | 2 +-
fs/cifs/smb2maperror.c | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
--- a/fs/cifs/smb1ops.c
+++ b/fs/cifs/smb1ops.c
@@ -586,7 +586,7 @@ cifs_query_path_info(const unsigned int
tmprc = CIFS_open(xid, &oparms, &oplock, NULL);
if (tmprc == -EOPNOTSUPP)
*symlink = true;
- else
+ else if (tmprc == 0)
CIFSSMBClose(xid, tcon, fid.netfid);
}
--- a/fs/cifs/smb2maperror.c
+++ b/fs/cifs/smb2maperror.c
@@ -256,6 +256,8 @@ static const struct status_to_posix_erro
{STATUS_DLL_MIGHT_BE_INCOMPATIBLE, -EIO,
"STATUS_DLL_MIGHT_BE_INCOMPATIBLE"},
{STATUS_STOPPED_ON_SYMLINK, -EOPNOTSUPP, "STATUS_STOPPED_ON_SYMLINK"},
+ {STATUS_IO_REPARSE_TAG_NOT_HANDLED, -EOPNOTSUPP,
+ "STATUS_REPARSE_NOT_HANDLED"},
{STATUS_DEVICE_REQUIRES_CLEANING, -EIO,
"STATUS_DEVICE_REQUIRES_CLEANING"},
{STATUS_DEVICE_DOOR_OPEN, -EIO, "STATUS_DEVICE_DOOR_OPEN"},
3.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Josh Triplett <[email protected]>
commit 62b4d2041117f35ab2409c9f5c4b8d3dc8e59d0f upstream.
commit 03b8c7b623c80af264c4c8d6111e5c6289933666 ("futex: Allow
architectures to skip futex_atomic_cmpxchg_inatomic() test") added the
HAVE_FUTEX_CMPXCHG symbol right below FUTEX. This placed it right in
the middle of the options for the EXPERT menu. However,
HAVE_FUTEX_CMPXCHG does not depend on EXPERT or FUTEX, so Kconfig stops
placing items in the EXPERT menu, and displays the remaining several
EXPERT items (starting with EPOLL) directly in the General Setup menu.
Since both users of HAVE_FUTEX_CMPXCHG only select it "if FUTEX", make
HAVE_FUTEX_CMPXCHG itself depend on FUTEX. With this change, the
subsequent items display as part of the EXPERT menu again; the EMBEDDED
menu now appears as the next top-level item in the General Setup menu,
which makes General Setup much shorter and more usable.
Signed-off-by: Josh Triplett <[email protected]>
Acked-by: Randy Dunlap <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
init/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1432,6 +1432,7 @@ config FUTEX
config HAVE_FUTEX_CMPXCHG
bool
+ depends on FUTEX
help
Architectures should select this if futex_atomic_cmpxchg_inatomic()
is implemented and always working. This removes a couple of runtime
3.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johannes Weiner <[email protected]>
commit 2f7dd7a4100ad4affcb141605bef178ab98ccb18 upstream.
The cgroup iterators yield css objects that have not yet gone through
css_online(), but they are not complete memcgs at this point and so the
memcg iterators should not return them. Commit d8ad30559715 ("mm/memcg:
iteration skip memcgs not yet fully initialized") set out to implement
exactly this, but it uses CSS_ONLINE, a cgroup-internal flag that does
not meet the ordering requirements for memcg, and so the iterator may
skip over initialized groups, or return partially initialized memcgs.
The cgroup core can not reasonably provide a clear answer on whether the
object around the css has been fully initialized, as that depends on
controller-specific locking and lifetime rules. Thus, introduce a
memcg-specific flag that is set after the memcg has been initialized in
css_online(), and read before mem_cgroup_iter() callers access the memcg
members.
Signed-off-by: Johannes Weiner <[email protected]>
Cc: Tejun Heo <[email protected]>
Acked-by: Michal Hocko <[email protected]>
Cc: Hugh Dickins <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
mm/memcontrol.c | 36 +++++++++++++++++++++++++++++++-----
1 file changed, 31 insertions(+), 5 deletions(-)
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -292,6 +292,9 @@ struct mem_cgroup {
/* vmpressure notifications */
struct vmpressure vmpressure;
+ /* css_online() has been completed */
+ int initialized;
+
/*
* the counter to account for mem+swap usage.
*/
@@ -1106,10 +1109,21 @@ skip_node:
* skipping css reference should be safe.
*/
if (next_css) {
- if ((next_css == &root->css) ||
- ((next_css->flags & CSS_ONLINE) &&
- css_tryget_online(next_css)))
- return mem_cgroup_from_css(next_css);
+ struct mem_cgroup *memcg = mem_cgroup_from_css(next_css);
+
+ if (next_css == &root->css)
+ return memcg;
+
+ if (css_tryget_online(next_css)) {
+ /*
+ * Make sure the memcg is initialized:
+ * mem_cgroup_css_online() orders the the
+ * initialization against setting the flag.
+ */
+ if (smp_load_acquire(&memcg->initialized))
+ return memcg;
+ css_put(next_css);
+ }
prev_css = next_css;
goto skip_node;
@@ -6277,6 +6291,7 @@ mem_cgroup_css_online(struct cgroup_subs
{
struct mem_cgroup *memcg = mem_cgroup_from_css(css);
struct mem_cgroup *parent = mem_cgroup_from_css(css->parent);
+ int ret;
if (css->id > MEM_CGROUP_ID_MAX)
return -ENOSPC;
@@ -6313,7 +6328,18 @@ mem_cgroup_css_online(struct cgroup_subs
}
mutex_unlock(&memcg_create_mutex);
- return memcg_init_kmem(memcg, &memory_cgrp_subsys);
+ ret = memcg_init_kmem(memcg, &memory_cgrp_subsys);
+ if (ret)
+ return ret;
+
+ /*
+ * Make sure the memcg is initialized: mem_cgroup_iter()
+ * orders reading memcg->initialized against its callers
+ * reading the memcg members.
+ */
+ smp_store_release(&memcg->initialized, 1);
+
+ return 0;
}
/*
3.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Rafael J. Wysocki" <[email protected]>
commit e65b5ddba84634f31d42dfd86013f4c6be5e9e32 upstream.
Fix the following bug introduced by commit 8fec051eea73 (cpufreq:
Convert existing drivers to use cpufreq_freq_transition_{begin|end})
that forgot to move the spin_lock() in pcc_cpufreq_target() past
cpufreq_freq_transition_begin() which calls wait_event():
BUG: sleeping function called from invalid context at drivers/cpufreq/cpufreq.c:370
in_atomic(): 1, irqs_disabled(): 0, pid: 2636, name: modprobe
Preemption disabled at:[<ffffffffa04d74d7>] pcc_cpufreq_target+0x27/0x200 [pcc_cpufreq]
[ 51.025044]
CPU: 57 PID: 2636 Comm: modprobe Tainted: G E 3.17.0-default #7
Hardware name: Hewlett-Packard ProLiant DL980 G7, BIOS P66 07/07/2010
00000000ffffffff ffff88026c46b828 ffffffff81589dbd 0000000000000000
ffff880037978090 ffff88026c46b848 ffffffff8108e1df ffff880037978090
0000000000000000 ffff88026c46b878 ffffffff8108e298 ffff88026d73ec00
Call Trace:
[<ffffffff81589dbd>] dump_stack+0x4d/0x90
[<ffffffff8108e1df>] ___might_sleep+0x10f/0x180
[<ffffffff8108e298>] __might_sleep+0x48/0xd0
[<ffffffff8145b905>] cpufreq_freq_transition_begin+0x75/0x140 drivers/cpufreq/cpufreq.c:370 wait_event(policy->transition_wait, !policy->transition_ongoing);
[<ffffffff8108fc99>] ? preempt_count_add+0xb9/0xc0
[<ffffffffa04d7513>] pcc_cpufreq_target+0x63/0x200 [pcc_cpufreq] drivers/cpufreq/pcc-cpufreq.c:207 spin_lock(&pcc_lock);
[<ffffffff810e0d0f>] ? update_ts_time_stats+0x7f/0xb0
[<ffffffff8145be55>] __cpufreq_driver_target+0x85/0x170
[<ffffffff8145e4c8>] od_check_cpu+0xa8/0xb0
[<ffffffff8145ef10>] dbs_check_cpu+0x180/0x1d0
[<ffffffff8145f310>] cpufreq_governor_dbs+0x3b0/0x720
[<ffffffff8145ebe3>] od_cpufreq_governor_dbs+0x33/0xe0
[<ffffffff814593d9>] __cpufreq_governor+0xa9/0x210
[<ffffffff81459fb2>] cpufreq_set_policy+0x1e2/0x2e0
[<ffffffff8145a6cc>] cpufreq_init_policy+0x8c/0x110
[<ffffffff8145c9a0>] ? cpufreq_update_policy+0x1b0/0x1b0
[<ffffffff8108fb99>] ? preempt_count_sub+0xb9/0x100
[<ffffffff8145c6c6>] __cpufreq_add_dev+0x596/0x6b0
[<ffffffffa016c608>] ? pcc_cpufreq_probe+0x4b4/0x4b4 [pcc_cpufreq]
[<ffffffff8145c7ee>] cpufreq_add_dev+0xe/0x10
[<ffffffff81408e81>] subsys_interface_register+0xc1/0xf0
[<ffffffff8108fb99>] ? preempt_count_sub+0xb9/0x100
[<ffffffff8145b3d7>] cpufreq_register_driver+0x117/0x2a0
[<ffffffffa016c65d>] pcc_cpufreq_init+0x55/0x9f8 [pcc_cpufreq]
[<ffffffffa016c608>] ? pcc_cpufreq_probe+0x4b4/0x4b4 [pcc_cpufreq]
[<ffffffff81000298>] do_one_initcall+0xc8/0x1f0
[<ffffffff811a731d>] ? __vunmap+0x9d/0x100
[<ffffffff810eb9a0>] do_init_module+0x30/0x1b0
[<ffffffff810edfa6>] load_module+0x686/0x710
[<ffffffff810ebb20>] ? do_init_module+0x1b0/0x1b0
[<ffffffff810ee1db>] SyS_init_module+0x9b/0xc0
[<ffffffff8158f7a9>] system_call_fastpath+0x16/0x1b
Fixes: 8fec051eea73 (cpufreq: Convert existing drivers to use cpufreq_freq_transition_{begin|end})
Reported-and-tested-by: Mike Galbraith <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/cpufreq/pcc-cpufreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/cpufreq/pcc-cpufreq.c
+++ b/drivers/cpufreq/pcc-cpufreq.c
@@ -204,7 +204,6 @@ static int pcc_cpufreq_target(struct cpu
u32 input_buffer;
int cpu;
- spin_lock(&pcc_lock);
cpu = policy->cpu;
pcc_cpu_data = per_cpu_ptr(pcc_cpu_info, cpu);
@@ -216,6 +215,7 @@ static int pcc_cpufreq_target(struct cpu
freqs.old = policy->cur;
freqs.new = target_freq;
cpufreq_freq_transition_begin(policy, &freqs);
+ spin_lock(&pcc_lock);
input_buffer = 0x1 | (((target_freq * 100)
/ (ioread32(&pcch_hdr->nominal) * 1000)) << 8);
3.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: NeilBrown <[email protected]>
commit 8e0e99ba64c7ba46133a7c8a3e3f7de01f23bd93 upstream.
It has come to my attention (thanks Martin) that 'discard_zeroes_data'
is only a hint. Some devices in some cases don't do what it
says on the label.
The use of DISCARD in RAID5 depends on reads from discarded regions
being predictably zero. If a write to a previously discarded region
performs a read-modify-write cycle it assumes that the parity block
was consistent with the data blocks. If all were zero, this would
be the case. If some are and some aren't this would not be the case.
This could lead to data corruption after a device failure when
data needs to be reconstructed from the parity.
As we cannot trust 'discard_zeroes_data', ignore it by default
and so disallow DISCARD on all raid4/5/6 arrays.
As many devices are trustworthy, and as there are benefits to using
DISCARD, add a module parameter to over-ride this caution and cause
DISCARD to work if discard_zeroes_data is set.
If a site want to enable DISCARD on some arrays but not on others they
should select DISCARD support at the filesystem level, and set the
raid456 module parameter.
raid456.devices_handle_discard_safely=Y
As this is a data-safety issue, I believe this patch is suitable for
-stable.
DISCARD support for RAID456 was added in 3.7
Cc: Shaohua Li <[email protected]>
Cc: "Martin K. Petersen" <[email protected]>
Cc: Mike Snitzer <[email protected]>
Cc: Heinz Mauelshagen <[email protected]>
Acked-by: Martin K. Petersen <[email protected]>
Acked-by: Mike Snitzer <[email protected]>
Fixes: 620125f2bf8ff0c4969b79653b54d7bcc9d40637
Signed-off-by: NeilBrown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/md/raid5.c | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -64,6 +64,10 @@
#define cpu_to_group(cpu) cpu_to_node(cpu)
#define ANY_GROUP NUMA_NO_NODE
+static bool devices_handle_discard_safely = false;
+module_param(devices_handle_discard_safely, bool, 0644);
+MODULE_PARM_DESC(devices_handle_discard_safely,
+ "Set to Y if all devices in each array reliably return zeroes on reads from discarded regions");
static struct workqueue_struct *raid5_wq;
/*
* Stripe cache
@@ -6208,7 +6212,7 @@ static int run(struct mddev *mddev)
mddev->queue->limits.discard_granularity = stripe;
/*
* unaligned part of discard request will be ignored, so can't
- * guarantee discard_zerors_data
+ * guarantee discard_zeroes_data
*/
mddev->queue->limits.discard_zeroes_data = 0;
@@ -6233,6 +6237,18 @@ static int run(struct mddev *mddev)
!bdev_get_queue(rdev->bdev)->
limits.discard_zeroes_data)
discard_supported = false;
+ /* Unfortunately, discard_zeroes_data is not currently
+ * a guarantee - just a hint. So we only allow DISCARD
+ * if the sysadmin has confirmed that only safe devices
+ * are in use by setting a module parameter.
+ */
+ if (!devices_handle_discard_safely) {
+ if (discard_supported) {
+ pr_info("md/raid456: discard support disabled due to uncertainty.\n");
+ pr_info("Set raid456.devices_handle_discard_safely=Y to override.\n");
+ }
+ discard_supported = false;
+ }
}
if (discard_supported &&
3.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chris Wilson <[email protected]>
commit 91e56499304f3d612053a9cf17f350868182c7d8 upstream.
As we use WC updates of the PTE, we are responsible for notifying the
hardware when to flush its TLBs. Do so after we zap all the PTEs before
suspend (and the BIOS tries to read our GTT).
Fixes a regression from
commit 828c79087cec61eaf4c76bb32c222fbe35ac3930
Author: Ben Widawsky <[email protected]>
Date: Wed Oct 16 09:21:30 2013 -0700
drm/i915: Disable GGTT PTEs on GEN6+ suspend
that survived and continue to cause harm even after
commit e568af1c626031925465a5caaab7cca1303d55c7
Author: Daniel Vetter <[email protected]>
Date: Wed Mar 26 20:08:20 2014 +0100
drm/i915: Undo gtt scratch pte unmapping again
v2: Trivial rebase.
v3: Fixes requires pointer dances.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82340
Tested-by: [email protected]
Signed-off-by: Chris Wilson <[email protected]>
Cc: Takashi Iwai <[email protected]>
Cc: Paulo Zanoni <[email protected]>
Cc: Todd Previte <[email protected]>
Cc: Daniel Vetter <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1297,6 +1297,16 @@ void i915_check_and_clear_faults(struct
POSTING_READ(RING_FAULT_REG(&dev_priv->ring[RCS]));
}
+static void i915_ggtt_flush(struct drm_i915_private *dev_priv)
+{
+ if (INTEL_INFO(dev_priv->dev)->gen < 6) {
+ intel_gtt_chipset_flush();
+ } else {
+ I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
+ POSTING_READ(GFX_FLSH_CNTL_GEN6);
+ }
+}
+
void i915_gem_suspend_gtt_mappings(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -1313,6 +1323,8 @@ void i915_gem_suspend_gtt_mappings(struc
dev_priv->gtt.base.start,
dev_priv->gtt.base.total,
true);
+
+ i915_ggtt_flush(dev_priv);
}
void i915_gem_restore_gtt_mappings(struct drm_device *dev)
@@ -1365,7 +1377,7 @@ void i915_gem_restore_gtt_mappings(struc
gen6_write_pdes(container_of(vm, struct i915_hw_ppgtt, base));
}
- i915_gem_chipset_flush(dev);
+ i915_ggtt_flush(dev_priv);
}
int i915_gem_gtt_prepare_object(struct drm_i915_gem_object *obj)
3.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Steven Rostedt (Red Hat)" <[email protected]>
commit 24607f114fd14f2f37e3e0cb3d47bce96e81e848 upstream.
Commit 651e22f2701b "ring-buffer: Always reset iterator to reader page"
fixed one bug but in the process caused another one. The reset is to
update the header page, but that fix also changed the way the cached
reads were updated. The cache reads are used to test if an iterator
needs to be updated or not.
A ring buffer iterator, when created, disables writes to the ring buffer
but does not stop other readers or consuming reads from happening.
Although all readers are synchronized via a lock, they are only
synchronized when in the ring buffer functions. Those functions may
be called by any number of readers. The iterator continues down when
its not interrupted by a consuming reader. If a consuming read
occurs, the iterator starts from the beginning of the buffer.
The way the iterator sees that a consuming read has happened since
its last read is by checking the reader "cache". The cache holds the
last counts of the read and the reader page itself.
Commit 651e22f2701b changed what was saved by the cache_read when
the rb_iter_reset() occurred, making the iterator never match the cache.
Then if the iterator calls rb_iter_reset(), it will go into an
infinite loop by checking if the cache doesn't match, doing the reset
and retrying, just to see that the cache still doesn't match! Which
should never happen as the reset is suppose to set the cache to the
current value and there's locks that keep a consuming reader from
having access to the data.
Fixes: 651e22f2701b "ring-buffer: Always reset iterator to reader page"
Signed-off-by: Steven Rostedt <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/trace/ring_buffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -3375,7 +3375,7 @@ static void rb_iter_reset(struct ring_bu
iter->head = cpu_buffer->reader_page->read;
iter->cache_reader_page = iter->head_page;
- iter->cache_read = iter->head;
+ iter->cache_read = cpu_buffer->read;
if (iter->head)
iter->read_stamp = cpu_buffer->read_stamp;
3.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexandru M Stan <[email protected]>
commit cf27020d2f253bac6457d6833b97141030f0122a upstream.
i2cdetect -q was broken (everything was a false positive, and no transfers were
actually being sent over i2c). The way it works is by sending a 0 length write
request and checking for NACK. This patch fixes the 0 length writes and actually
sends them.
Reported-by: Doug Anderson <[email protected]>
Signed-off-by: Alexandru M Stan <[email protected]>
Tested-by: Doug Anderson <[email protected]>
Tested-by: Max Schwarz <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/i2c/busses/i2c-rk3x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/i2c/busses/i2c-rk3x.c
+++ b/drivers/i2c/busses/i2c-rk3x.c
@@ -238,7 +238,7 @@ static void rk3x_i2c_fill_transmit_buf(s
for (i = 0; i < 8; ++i) {
val = 0;
for (j = 0; j < 4; ++j) {
- if (i2c->processed == i2c->msg->len)
+ if ((i2c->processed == i2c->msg->len) && (cnt != 0))
break;
if (i2c->processed == 0 && cnt == 0)
3.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Gross <[email protected]>
commit 86b59bbfae2a895aa26b3d15f31b1a705dbfede1 upstream.
The runtime pm calls need to be done before populating the children via the
i2c_add_adapter call. If this is not done, a child can run into issues trying
to do i2c read/writes due to the pm_runtime_sync failing.
Signed-off-by: Andy Gross <[email protected]>
Reviewed-by: Felipe Balbi <[email protected]>
Acked-by: Bjorn Andersson <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/i2c/busses/i2c-qup.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -670,16 +670,20 @@ static int qup_i2c_probe(struct platform
qup->adap.dev.of_node = pdev->dev.of_node;
strlcpy(qup->adap.name, "QUP I2C adapter", sizeof(qup->adap.name));
- ret = i2c_add_adapter(&qup->adap);
- if (ret)
- goto fail;
-
pm_runtime_set_autosuspend_delay(qup->dev, MSEC_PER_SEC);
pm_runtime_use_autosuspend(qup->dev);
pm_runtime_set_active(qup->dev);
pm_runtime_enable(qup->dev);
+
+ ret = i2c_add_adapter(&qup->adap);
+ if (ret)
+ goto fail_runtime;
+
return 0;
+fail_runtime:
+ pm_runtime_disable(qup->dev);
+ pm_runtime_set_suspended(qup->dev);
fail:
qup_i2c_disable_clocks(qup);
return ret;
3.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Kara <[email protected]>
commit c03aa9f6e1f938618e6db2e23afef0574efeeb65 upstream.
We did not implement any bound on number of indirect ICBs we follow when
loading inode. Thus corrupted medium could cause kernel to go into an
infinite loop, possibly causing a stack overflow.
Fix the possible stack overflow by removing recursion from
__udf_read_inode() and limit number of indirect ICBs we follow to avoid
infinite loops.
Signed-off-by: Jan Kara <[email protected]>
Cc: Chuck Ebbert <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/udf/inode.c | 35 +++++++++++++++++++++--------------
1 file changed, 21 insertions(+), 14 deletions(-)
--- a/fs/udf/inode.c
+++ b/fs/udf/inode.c
@@ -1271,13 +1271,22 @@ update_time:
return 0;
}
+/*
+ * Maximum length of linked list formed by ICB hierarchy. The chosen number is
+ * arbitrary - just that we hopefully don't limit any real use of rewritten
+ * inode on write-once media but avoid looping for too long on corrupted media.
+ */
+#define UDF_MAX_ICB_NESTING 1024
+
static void __udf_read_inode(struct inode *inode)
{
struct buffer_head *bh = NULL;
struct fileEntry *fe;
uint16_t ident;
struct udf_inode_info *iinfo = UDF_I(inode);
+ unsigned int indirections = 0;
+reread:
/*
* Set defaults, but the inode is still incomplete!
* Note: get_new_inode() sets the following on a new inode:
@@ -1314,28 +1323,26 @@ static void __udf_read_inode(struct inod
ibh = udf_read_ptagged(inode->i_sb, &iinfo->i_location, 1,
&ident);
if (ident == TAG_IDENT_IE && ibh) {
- struct buffer_head *nbh = NULL;
struct kernel_lb_addr loc;
struct indirectEntry *ie;
ie = (struct indirectEntry *)ibh->b_data;
loc = lelb_to_cpu(ie->indirectICB.extLocation);
- if (ie->indirectICB.extLength &&
- (nbh = udf_read_ptagged(inode->i_sb, &loc, 0,
- &ident))) {
- if (ident == TAG_IDENT_FE ||
- ident == TAG_IDENT_EFE) {
- memcpy(&iinfo->i_location,
- &loc,
- sizeof(struct kernel_lb_addr));
- brelse(bh);
- brelse(ibh);
- brelse(nbh);
- __udf_read_inode(inode);
+ if (ie->indirectICB.extLength) {
+ brelse(bh);
+ brelse(ibh);
+ memcpy(&iinfo->i_location, &loc,
+ sizeof(struct kernel_lb_addr));
+ if (++indirections > UDF_MAX_ICB_NESTING) {
+ udf_err(inode->i_sb,
+ "too many ICBs in ICB hierarchy"
+ " (max %d supported)\n",
+ UDF_MAX_ICB_NESTING);
+ make_bad_inode(inode);
return;
}
- brelse(nbh);
+ goto reread;
}
}
brelse(ibh);
3.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mel Gorman <[email protected]>
commit d3cb8bf6081b8b7a2dabb1264fe968fd870fa595 upstream.
A migration entry is marked as write if pte_write was true at the time the
entry was created. The VMA protections are not double checked when migration
entries are being removed as mprotect marks write-migration-entries as
read. It means that potentially we take a spurious fault to mark PTEs write
again but it's straight-forward. However, there is a race between write
migrations being marked read and migrations finishing. This potentially
allows a PTE to be write that should have been read. Close this race by
double checking the VMA permissions using maybe_mkwrite when migration
completes.
[[email protected]: use maybe_mkwrite]
Signed-off-by: Mel Gorman <[email protected]>
Acked-by: Rik van Riel <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
mm/migrate.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -146,8 +146,11 @@ static int remove_migration_pte(struct p
pte = pte_mkold(mk_pte(new, vma->vm_page_prot));
if (pte_swp_soft_dirty(*ptep))
pte = pte_mksoft_dirty(pte);
+
+ /* Recheck VMA as permissions can change since migration started */
if (is_write_migration_entry(entry))
- pte = pte_mkwrite(pte);
+ pte = maybe_mkwrite(pte, vma);
+
#ifdef CONFIG_HUGETLB_PAGE
if (PageHuge(new)) {
pte = pte_mkhuge(pte);
3.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Zijlstra <[email protected]>
commit 6c72e3501d0d62fc064d3680e5234f3463ec5a86 upstream.
Oleg noticed that a cleanup by Sylvain actually uncovered a bug; by
calling perf_event_free_task() when failing sched_fork() we will not yet
have done the memset() on ->perf_event_ctxp[] and will therefore try and
'free' the inherited contexts, which are still in use by the parent
process. This is bad..
Suggested-by: Oleg Nesterov <[email protected]>
Reported-by: Oleg Nesterov <[email protected]>
Reported-by: Sylvain 'ythier' Hitier <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Cc: Ingo Molnar <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/events/core.c | 4 +++-
kernel/fork.c | 5 +++--
2 files changed, 6 insertions(+), 3 deletions(-)
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -7921,8 +7921,10 @@ int perf_event_init_task(struct task_str
for_each_task_context_nr(ctxn) {
ret = perf_event_init_context(child, ctxn);
- if (ret)
+ if (ret) {
+ perf_event_free_task(child);
return ret;
+ }
}
return 0;
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1326,7 +1326,7 @@ static struct task_struct *copy_process(
goto bad_fork_cleanup_policy;
retval = audit_alloc(p);
if (retval)
- goto bad_fork_cleanup_policy;
+ goto bad_fork_cleanup_perf;
/* copy all the process information */
retval = copy_semundo(clone_flags, p);
if (retval)
@@ -1525,8 +1525,9 @@ bad_fork_cleanup_semundo:
exit_sem(p);
bad_fork_cleanup_audit:
audit_free(p);
-bad_fork_cleanup_policy:
+bad_fork_cleanup_perf:
perf_event_free_task(p);
+bad_fork_cleanup_policy:
#ifdef CONFIG_NUMA
mpol_put(p->mempolicy);
bad_fork_cleanup_threadgroup_lock:
3.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xiubo Li <[email protected]>
commit 6596aa047b624aeec2ea321962cfdecf9953a383 upstream.
Since we cannot make sure the 'params->num_regs' will always be none
zero here, and then if it equals to zero, the kmemdup() will return
ZERO_SIZE_PTR, which equals to ((void *)16).
So this patch fix this with just doing the zero check before calling
kmemdup().
Signed-off-by: Xiubo Li <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/soc/soc-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -3181,7 +3181,7 @@ int snd_soc_bytes_put(struct snd_kcontro
unsigned int val, mask;
void *data;
- if (!component->regmap)
+ if (!component->regmap || !params->num_regs)
return -EINVAL;
len = params->num_regs * component->val_bytes;
3.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefan Kristiansson <[email protected]>
commit fe2a08b3bf1a6e35c00e18843bc19aa1778432c3 upstream.
The correct type (SSM2602/SSM2603/SSM2604) is passed down
from the ssm2602_spi_probe()/ssm2602_spi_probe() functions,
so use that instead of hardcoding it to SSM2602 in
ssm2602_probe().
Fixes: c924dc68f737 ("ASoC: ssm2602: Split SPI and I2C code into different modules")
Signed-off-by: Stefan Kristiansson <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Acked-by: Lars-Peter Clausen <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/soc/codecs/ssm2602.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/sound/soc/codecs/ssm2602.c
+++ b/sound/soc/codecs/ssm2602.c
@@ -647,7 +647,7 @@ int ssm2602_probe(struct device *dev, en
return -ENOMEM;
dev_set_drvdata(dev, ssm2602);
- ssm2602->type = SSM2602;
+ ssm2602->type = type;
ssm2602->regmap = regmap;
return snd_soc_register_codec(dev, &soc_codec_dev_ssm2602,
On 10/07/2014 04:19 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.16.5 release.
> There are 26 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu Oct 9 23:18:40 UTC 2014.
> Anything received after that time might be too late.
>
Build results:
total: 136 pass: 136 fail: 0
Qemu tests:
total: 30 pass: 30 fail: 0
Details are available at http://server.roeck-us.net:8010/builders.
Guenter
On Tue, Oct 07, 2014 at 07:47:13PM -0700, Guenter Roeck wrote:
> On 10/07/2014 04:19 PM, Greg Kroah-Hartman wrote:
> >This is the start of the stable review cycle for the 3.16.5 release.
> >There are 26 patches in this series, all will be posted as a response
> >to this one. If anyone has any issues with these being applied, please
> >let me know.
> >
> >Responses should be made by Thu Oct 9 23:18:40 UTC 2014.
> >Anything received after that time might be too late.
> >
>
> Build results:
> total: 136 pass: 136 fail: 0
> Qemu tests:
> total: 30 pass: 30 fail: 0
>
> Details are available at http://server.roeck-us.net:8010/builders.
Wonderful, thanks for testing all 3 of these and letting me know.
greg k-h
At Tue, 7 Oct 2014 21:48:04 -0700,
Greg Kroah-Hartman wrote:
>
> On Tue, Oct 07, 2014 at 07:47:13PM -0700, Guenter Roeck wrote:
> > On 10/07/2014 04:19 PM, Greg Kroah-Hartman wrote:
> > >This is the start of the stable review cycle for the 3.16.5 release.
> > >There are 26 patches in this series, all will be posted as a response
> > >to this one. If anyone has any issues with these being applied, please
> > >let me know.
> > >
> > >Responses should be made by Thu Oct 9 23:18:40 UTC 2014.
> > >Anything received after that time might be too late.
> > >
> >
> > Build results:
> > total: 136 pass: 136 fail: 0
> > Qemu tests:
> > total: 30 pass: 30 fail: 0
> >
> > Details are available at http://server.roeck-us.net:8010/builders.
>
> Wonderful, thanks for testing all 3 of these and letting me know.
Plus, all these kernels passed my test.
- Test Cases:
- Build this kernel.
- Boot this kernel.
- Build the latest mainline kernel with this kernel.
- Test Tool:
https://github.com/satoru-takeuchi/test-linux-stable
- Test Result (kernel .config, ktest config and test log):
http://satoru-takeuchi.org/test-linux-stable/results/<version>-<test datetime>.tar.xz
- Build Environment:
- OS: Debian Jessy x86_64
- CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
- memory: 8GB
- Test Target Environment:
- Debian Jessy x86_64 (KVM guest on the Build Environment)
- # of vCPU: 2
- memory: 2GB
Thanks,
Satoru
On Wed, Oct 08, 2014 at 09:39:50PM +0900, Satoru Takeuchi wrote:
> At Tue, 7 Oct 2014 21:48:04 -0700,
> Greg Kroah-Hartman wrote:
> >
> > On Tue, Oct 07, 2014 at 07:47:13PM -0700, Guenter Roeck wrote:
> > > On 10/07/2014 04:19 PM, Greg Kroah-Hartman wrote:
> > > >This is the start of the stable review cycle for the 3.16.5 release.
> > > >There are 26 patches in this series, all will be posted as a response
> > > >to this one. If anyone has any issues with these being applied, please
> > > >let me know.
> > > >
> > > >Responses should be made by Thu Oct 9 23:18:40 UTC 2014.
> > > >Anything received after that time might be too late.
> > > >
> > >
> > > Build results:
> > > total: 136 pass: 136 fail: 0
> > > Qemu tests:
> > > total: 30 pass: 30 fail: 0
> > >
> > > Details are available at http://server.roeck-us.net:8010/builders.
> >
> > Wonderful, thanks for testing all 3 of these and letting me know.
>
> Plus, all these kernels passed my test.
>
> - Test Cases:
> - Build this kernel.
> - Boot this kernel.
> - Build the latest mainline kernel with this kernel.
>
> - Test Tool:
> https://github.com/satoru-takeuchi/test-linux-stable
>
> - Test Result (kernel .config, ktest config and test log):
> http://satoru-takeuchi.org/test-linux-stable/results/<version>-<test datetime>.tar.xz
>
> - Build Environment:
> - OS: Debian Jessy x86_64
> - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
> - memory: 8GB
>
> - Test Target Environment:
> - Debian Jessy x86_64 (KVM guest on the Build Environment)
> - # of vCPU: 2
> - memory: 2GB
Glad to hear it, I was worried about 3.14, thanks for testing and
verifying I didn't mess anything up.
greg k-h
On Wed, Oct 08, 2014 at 06:32:52AM -0700, Greg Kroah-Hartman wrote:
> On Wed, Oct 08, 2014 at 09:39:50PM +0900, Satoru Takeuchi wrote:
> > At Tue, 7 Oct 2014 21:48:04 -0700,
> > Greg Kroah-Hartman wrote:
> > >
> > > On Tue, Oct 07, 2014 at 07:47:13PM -0700, Guenter Roeck wrote:
> > > > On 10/07/2014 04:19 PM, Greg Kroah-Hartman wrote:
> > > > >This is the start of the stable review cycle for the 3.16.5 release.
> > > > >There are 26 patches in this series, all will be posted as a response
> > > > >to this one. If anyone has any issues with these being applied, please
> > > > >let me know.
> > > > >
> > > > >Responses should be made by Thu Oct 9 23:18:40 UTC 2014.
> > > > >Anything received after that time might be too late.
> > > > >
> > > >
> > > > Build results:
> > > > total: 136 pass: 136 fail: 0
> > > > Qemu tests:
> > > > total: 30 pass: 30 fail: 0
> > > >
> > > > Details are available at http://server.roeck-us.net:8010/builders.
> > >
> > > Wonderful, thanks for testing all 3 of these and letting me know.
> >
> > Plus, all these kernels passed my test.
> >
> > - Test Cases:
> > - Build this kernel.
> > - Boot this kernel.
> > - Build the latest mainline kernel with this kernel.
> >
> > - Test Tool:
> > https://github.com/satoru-takeuchi/test-linux-stable
> >
> > - Test Result (kernel .config, ktest config and test log):
> > http://satoru-takeuchi.org/test-linux-stable/results/<version>-<test datetime>.tar.xz
> >
> > - Build Environment:
> > - OS: Debian Jessy x86_64
> > - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
> > - memory: 8GB
> >
> > - Test Target Environment:
> > - Debian Jessy x86_64 (KVM guest on the Build Environment)
> > - # of vCPU: 2
> > - memory: 2GB
>
> Glad to hear it, I was worried about 3.14, thanks for testing and
> verifying I didn't mess anything up.
>
Anything special to be worried about for 3.14.20 that might warrant
further / special testing ?
FWIW, I merged 3.14.19 into our target kernel. It does pass smoketest ;-).
Guenter
On Wed, Oct 08, 2014 at 08:49:47AM -0700, Guenter Roeck wrote:
> On Wed, Oct 08, 2014 at 06:32:52AM -0700, Greg Kroah-Hartman wrote:
> > On Wed, Oct 08, 2014 at 09:39:50PM +0900, Satoru Takeuchi wrote:
> > > At Tue, 7 Oct 2014 21:48:04 -0700,
> > > Greg Kroah-Hartman wrote:
> > > >
> > > > On Tue, Oct 07, 2014 at 07:47:13PM -0700, Guenter Roeck wrote:
> > > > > On 10/07/2014 04:19 PM, Greg Kroah-Hartman wrote:
> > > > > >This is the start of the stable review cycle for the 3.16.5 release.
> > > > > >There are 26 patches in this series, all will be posted as a response
> > > > > >to this one. If anyone has any issues with these being applied, please
> > > > > >let me know.
> > > > > >
> > > > > >Responses should be made by Thu Oct 9 23:18:40 UTC 2014.
> > > > > >Anything received after that time might be too late.
> > > > > >
> > > > >
> > > > > Build results:
> > > > > total: 136 pass: 136 fail: 0
> > > > > Qemu tests:
> > > > > total: 30 pass: 30 fail: 0
> > > > >
> > > > > Details are available at http://server.roeck-us.net:8010/builders.
> > > >
> > > > Wonderful, thanks for testing all 3 of these and letting me know.
> > >
> > > Plus, all these kernels passed my test.
> > >
> > > - Test Cases:
> > > - Build this kernel.
> > > - Boot this kernel.
> > > - Build the latest mainline kernel with this kernel.
> > >
> > > - Test Tool:
> > > https://github.com/satoru-takeuchi/test-linux-stable
> > >
> > > - Test Result (kernel .config, ktest config and test log):
> > > http://satoru-takeuchi.org/test-linux-stable/results/<version>-<test datetime>.tar.xz
> > >
> > > - Build Environment:
> > > - OS: Debian Jessy x86_64
> > > - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
> > > - memory: 8GB
> > >
> > > - Test Target Environment:
> > > - Debian Jessy x86_64 (KVM guest on the Build Environment)
> > > - # of vCPU: 2
> > > - memory: 2GB
> >
> > Glad to hear it, I was worried about 3.14, thanks for testing and
> > verifying I didn't mess anything up.
> >
> Anything special to be worried about for 3.14.20 that might warrant
> further / special testing ?
If it boots, it's good :)
> FWIW, I merged 3.14.19 into our target kernel. It does pass smoketest ;-).
Good, I merged a bunch of mm patches that Mel backported for 3.12. I
have more to do, was doing them in batches to try to make bisection
easier if problems show up.
thanks,
greg k-h
On 10/07/2014 05:19 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.16.5 release.
> There are 26 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu Oct 9 23:18:40 UTC 2014.
> 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.0/stable-review/patch-3.16.5-rc1.gz
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Samsung Research America (Silicon Valley)
[email protected] | (970) 217-8978
On Wed, Oct 08, 2014 at 02:05:22PM -0600, Shuah Khan wrote:
> On 10/07/2014 05:19 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.16.5 release.
> > There are 26 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Thu Oct 9 23:18:40 UTC 2014.
> > 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.0/stable-review/patch-3.16.5-rc1.gz
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
>
> Compiled and booted on my test system. No dmesg regressions.
Thanks for testing all of these and letting me know.
greg k-h