* [PATCH 3.4 01/19] Input: elantech - deal with clickpads reporting right button events
2014-07-04 22:15 [PATCH 3.4 00/19] 3.4.97-stable review Greg Kroah-Hartman
@ 2014-07-04 22:15 ` Greg Kroah-Hartman
2014-07-04 22:15 ` [PATCH 3.4 02/19] PCI: Add new ID for Intel GPU "spurious interrupt" quirk Greg Kroah-Hartman
` (18 subsequent siblings)
19 siblings, 0 replies; 26+ messages in thread
From: Greg Kroah-Hartman @ 2014-07-04 22:15 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Hans de Goede, Dmitry Torokhov
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <hdegoede@redhat.com>
commit cd9e83e2754465856097f31c7ab933ce74c473f8 upstream.
At least the Dell Vostro 5470 elantech *clickpad* reports right button
clicks when clicked in the right bottom area:
https://bugzilla.redhat.com/show_bug.cgi?id=1103528
This is different from how (elantech) clickpads normally operate, normally
no matter where the user clicks on the pad the pad always reports a left
button event, since there is only 1 hardware button beneath the path.
It looks like Dell has put 2 buttons under the pad, one under each bottom
corner, causing this.
Since this however still clearly is a real clickpad hardware-wise, we still
want to report it as such to userspace, so that things like finger movement
in the bottom area can be properly ignored as it should be on clickpads.
So deal with this weirdness by simply mapping a right click to a left click
on elantech clickpads. As an added advantage this is something which we can
simply do on all elantech clickpads, so no need to add special quirks for
this weird model.
Reported-and-tested-by: Elder Marco <eldermarco@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/input/mouse/elantech.c | 22 ++++++++++++++++++----
1 file changed, 18 insertions(+), 4 deletions(-)
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -472,8 +472,15 @@ static void elantech_report_absolute_v3(
input_report_key(dev, BTN_TOOL_FINGER, fingers == 1);
input_report_key(dev, BTN_TOOL_DOUBLETAP, fingers == 2);
input_report_key(dev, BTN_TOOL_TRIPLETAP, fingers == 3);
- input_report_key(dev, BTN_LEFT, packet[0] & 0x01);
- input_report_key(dev, BTN_RIGHT, packet[0] & 0x02);
+
+ /* For clickpads map both buttons to BTN_LEFT */
+ if (etd->fw_version & 0x001000) {
+ input_report_key(dev, BTN_LEFT, packet[0] & 0x03);
+ } else {
+ input_report_key(dev, BTN_LEFT, packet[0] & 0x01);
+ input_report_key(dev, BTN_RIGHT, packet[0] & 0x02);
+ }
+
input_report_abs(dev, ABS_PRESSURE, pres);
input_report_abs(dev, ABS_TOOL_WIDTH, width);
@@ -483,10 +490,17 @@ static void elantech_report_absolute_v3(
static void elantech_input_sync_v4(struct psmouse *psmouse)
{
struct input_dev *dev = psmouse->dev;
+ struct elantech_data *etd = psmouse->private;
unsigned char *packet = psmouse->packet;
- input_report_key(dev, BTN_LEFT, packet[0] & 0x01);
- input_report_key(dev, BTN_RIGHT, packet[0] & 0x02);
+ /* For clickpads map both buttons to BTN_LEFT */
+ if (etd->fw_version & 0x001000) {
+ input_report_key(dev, BTN_LEFT, packet[0] & 0x03);
+ } else {
+ input_report_key(dev, BTN_LEFT, packet[0] & 0x01);
+ input_report_key(dev, BTN_RIGHT, packet[0] & 0x02);
+ }
+
input_mt_report_pointer_emulation(dev, true);
input_sync(dev);
}
^ permalink raw reply [flat|nested] 26+ messages in thread* [PATCH 3.4 02/19] PCI: Add new ID for Intel GPU "spurious interrupt" quirk
2014-07-04 22:15 [PATCH 3.4 00/19] 3.4.97-stable review Greg Kroah-Hartman
2014-07-04 22:15 ` [PATCH 3.4 01/19] Input: elantech - deal with clickpads reporting right button events Greg Kroah-Hartman
@ 2014-07-04 22:15 ` Greg Kroah-Hartman
2014-07-04 22:15 ` [PATCH 3.4 03/19] PCI: Fix incorrect vgaarb conditional in WARN_ON() Greg Kroah-Hartman
` (17 subsequent siblings)
19 siblings, 0 replies; 26+ messages in thread
From: Greg Kroah-Hartman @ 2014-07-04 22:15 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Thomas Jarosch, Bjorn Helgaas
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Jarosch <thomas.jarosch@intra2net.com>
commit 7c82126a94e69bbbac586f0249e7ef11e681246c upstream.
After a CPU upgrade while keeping the same mainboard, we faced "spurious
interrupt" problems again.
It turned out that the new CPU also featured a new GPU with a different PCI
ID.
Add this PCI ID to the quirk table. Probably all other Intel GPU PCI IDs
are affected, too, but I don't want to add them without a test system.
See f67fd55fa96f ("PCI: Add quirk for still enabled interrupts on Intel
Sandy Bridge GPUs") for some history.
[bhelgaas: add f67fd55fa96f reference, stable tag]
Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/pci/quirks.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -2921,6 +2921,7 @@ static void __devinit disable_igfx_irq(s
}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0102, disable_igfx_irq);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x010a, disable_igfx_irq);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0152, disable_igfx_irq);
static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f,
struct pci_fixup *end)
^ permalink raw reply [flat|nested] 26+ messages in thread* [PATCH 3.4 03/19] PCI: Fix incorrect vgaarb conditional in WARN_ON()
2014-07-04 22:15 [PATCH 3.4 00/19] 3.4.97-stable review Greg Kroah-Hartman
2014-07-04 22:15 ` [PATCH 3.4 01/19] Input: elantech - deal with clickpads reporting right button events Greg Kroah-Hartman
2014-07-04 22:15 ` [PATCH 3.4 02/19] PCI: Add new ID for Intel GPU "spurious interrupt" quirk Greg Kroah-Hartman
@ 2014-07-04 22:15 ` Greg Kroah-Hartman
2014-07-04 22:15 ` [PATCH 3.4 04/19] recordmcount/MIPS: Fix possible incorrect mcount_loc table entries in modules Greg Kroah-Hartman
` (16 subsequent siblings)
19 siblings, 0 replies; 26+ messages in thread
From: Greg Kroah-Hartman @ 2014-07-04 22:15 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Bjorn Helgaas, Yinghai Lu,
David Airlie
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bjorn Helgaas <bhelgaas@google.com>
commit 67ebd8140dc8923c65451fa0f6a8eee003c4dcd3 upstream.
3448a19da479 "vgaarb: use bridges to control VGA routing where possible"
added the "flags & PCI_VGA_STATE_CHANGE_DECODES" condition to an existing
WARN_ON(), but used bitwise AND (&) instead of logical AND (&&), so the
condition is never true. Replace with logical AND.
Found by Coverity (CID 142811).
Fixes: 3448a19da479 "vgaarb: use bridges to control VGA routing where possible"
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Acked-by: David Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/pci/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3610,7 +3610,7 @@ int pci_set_vga_state(struct pci_dev *de
u16 cmd;
int rc;
- WARN_ON((flags & PCI_VGA_STATE_CHANGE_DECODES) & (command_bits & ~(PCI_COMMAND_IO|PCI_COMMAND_MEMORY)));
+ WARN_ON((flags & PCI_VGA_STATE_CHANGE_DECODES) && (command_bits & ~(PCI_COMMAND_IO|PCI_COMMAND_MEMORY)));
/* ARCH specific VGA enables */
rc = pci_set_vga_state_arch(dev, decode, command_bits, flags);
^ permalink raw reply [flat|nested] 26+ messages in thread* [PATCH 3.4 04/19] recordmcount/MIPS: Fix possible incorrect mcount_loc table entries in modules
2014-07-04 22:15 [PATCH 3.4 00/19] 3.4.97-stable review Greg Kroah-Hartman
` (2 preceding siblings ...)
2014-07-04 22:15 ` [PATCH 3.4 03/19] PCI: Fix incorrect vgaarb conditional in WARN_ON() Greg Kroah-Hartman
@ 2014-07-04 22:15 ` Greg Kroah-Hartman
2014-07-04 22:15 ` [PATCH 3.4 05/19] MIPS: MSC: Prevent out-of-bounds writes to MIPS SC ioremapd region Greg Kroah-Hartman
` (15 subsequent siblings)
19 siblings, 0 replies; 26+ messages in thread
From: Greg Kroah-Hartman @ 2014-07-04 22:15 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Alex Smith, linux-mips, Ralf Baechle
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Smith <alex.smith@imgtec.com>
commit 91ad11d7cc6f4472ebf177a6252fbf0fd100d798 upstream.
On MIPS calls to _mcount in modules generate 2 instructions to load
the _mcount address (and therefore 2 relocations). The mcount_loc
table should only reference the first of these, so the second is
filtered out by checking the relocation offset and ignoring ones that
immediately follow the previous one seen.
However if a module has an _mcount call at offset 0, the second
relocation would not be filtered out due to old_r_offset == 0
being taken to mean that the current relocation is the first one
seen, and both would end up in the mcount_loc table.
This results in ftrace_make_nop() patching both (adjacent)
instructions to branches over the _mcount call sequence like so:
0xffffffffc08a8000: 04 00 00 10 b 0xffffffffc08a8014
0xffffffffc08a8004: 04 00 00 10 b 0xffffffffc08a8018
0xffffffffc08a8008: 2d 08 e0 03 move at,ra
...
The second branch is in the delay slot of the first, which is
defined to be unpredictable - on the platform on which this bug was
encountered, it triggers a reserved instruction exception.
Fix by initializing old_r_offset to ~0 and using that instead of 0
to determine whether the current relocation is the first seen.
Signed-off-by: Alex Smith <alex.smith@imgtec.com>
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/7098/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
scripts/recordmcount.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/scripts/recordmcount.h
+++ b/scripts/recordmcount.h
@@ -163,11 +163,11 @@ static int mcount_adjust = 0;
static int MIPS_is_fake_mcount(Elf_Rel const *rp)
{
- static Elf_Addr old_r_offset;
+ static Elf_Addr old_r_offset = ~(Elf_Addr)0;
Elf_Addr current_r_offset = _w(rp->r_offset);
int is_fake;
- is_fake = old_r_offset &&
+ is_fake = (old_r_offset != ~(Elf_Addr)0) &&
(current_r_offset - old_r_offset == MIPS_FAKEMCOUNT_OFFSET);
old_r_offset = current_r_offset;
^ permalink raw reply [flat|nested] 26+ messages in thread* [PATCH 3.4 05/19] MIPS: MSC: Prevent out-of-bounds writes to MIPS SC ioremapd region
2014-07-04 22:15 [PATCH 3.4 00/19] 3.4.97-stable review Greg Kroah-Hartman
` (3 preceding siblings ...)
2014-07-04 22:15 ` [PATCH 3.4 04/19] recordmcount/MIPS: Fix possible incorrect mcount_loc table entries in modules Greg Kroah-Hartman
@ 2014-07-04 22:15 ` Greg Kroah-Hartman
2014-07-04 22:15 ` [PATCH 3.4 06/19] UBIFS: Remove incorrect assertion in shrink_tnc() Greg Kroah-Hartman
` (14 subsequent siblings)
19 siblings, 0 replies; 26+ messages in thread
From: Greg Kroah-Hartman @ 2014-07-04 22:15 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Markos Chandras, James Hogan,
linux-mips, Ralf Baechle
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Markos Chandras <markos.chandras@imgtec.com>
commit ab6c15bc6620ebe220970cc040b29bcb2757f373 upstream.
Previously, the lower limit for the MIPS SC initialization loop was
set incorrectly allowing one extra loop leading to writes
beyond the MSC ioremap'd space. More precisely, the value of the 'imp'
in the last loop increased beyond the msc_irqmap_t boundaries and
as a result of which, the 'n' variable was loaded with an incorrect
value. This value was used later on to calculate the offset in the
MSC01_IC_SUP which led to random crashes like the following one:
CPU 0 Unable to handle kernel paging request at virtual address e75c0200,
epc == 8058dba4, ra == 8058db90
[...]
Call Trace:
[<8058dba4>] init_msc_irqs+0x104/0x154
[<8058b5bc>] arch_init_irq+0xd8/0x154
[<805897b0>] start_kernel+0x220/0x36c
Kernel panic - not syncing: Attempted to kill the idle task!
This patch fixes the problem
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Reviewed-by: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/7118/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/mips/kernel/irq-msc01.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/mips/kernel/irq-msc01.c
+++ b/arch/mips/kernel/irq-msc01.c
@@ -131,7 +131,7 @@ void __init init_msc_irqs(unsigned long
board_bind_eic_interrupt = &msc_bind_eic_interrupt;
- for (; nirq >= 0; nirq--, imp++) {
+ for (; nirq > 0; nirq--, imp++) {
int n = imp->im_irq;
switch (imp->im_type) {
^ permalink raw reply [flat|nested] 26+ messages in thread* [PATCH 3.4 06/19] UBIFS: Remove incorrect assertion in shrink_tnc()
2014-07-04 22:15 [PATCH 3.4 00/19] 3.4.97-stable review Greg Kroah-Hartman
` (4 preceding siblings ...)
2014-07-04 22:15 ` [PATCH 3.4 05/19] MIPS: MSC: Prevent out-of-bounds writes to MIPS SC ioremapd region Greg Kroah-Hartman
@ 2014-07-04 22:15 ` Greg Kroah-Hartman
2014-07-04 22:15 ` [PATCH 3.4 07/19] watchdog: sp805: Set watchdog_device->timeout from ->set_timeout() Greg Kroah-Hartman
` (13 subsequent siblings)
19 siblings, 0 replies; 26+ messages in thread
From: Greg Kroah-Hartman @ 2014-07-04 22:15 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, hujianyang, Artem Bityutskiy
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: hujianyang <hujianyang@huawei.com>
commit 72abc8f4b4e8574318189886de627a2bfe6cd0da upstream.
I hit the same assert failed as Dolev Raviv reported in Kernel v3.10
shows like this:
[ 9641.164028] UBIFS assert failed in shrink_tnc at 131 (pid 13297)
[ 9641.234078] CPU: 1 PID: 13297 Comm: mmap.test Tainted: G O 3.10.40 #1
[ 9641.234116] [<c0011a6c>] (unwind_backtrace+0x0/0x12c) from [<c000d0b0>] (show_stack+0x20/0x24)
[ 9641.234137] [<c000d0b0>] (show_stack+0x20/0x24) from [<c0311134>] (dump_stack+0x20/0x28)
[ 9641.234188] [<c0311134>] (dump_stack+0x20/0x28) from [<bf22425c>] (shrink_tnc_trees+0x25c/0x350 [ubifs])
[ 9641.234265] [<bf22425c>] (shrink_tnc_trees+0x25c/0x350 [ubifs]) from [<bf2245ac>] (ubifs_shrinker+0x25c/0x310 [ubifs])
[ 9641.234307] [<bf2245ac>] (ubifs_shrinker+0x25c/0x310 [ubifs]) from [<c00cdad8>] (shrink_slab+0x1d4/0x2f8)
[ 9641.234327] [<c00cdad8>] (shrink_slab+0x1d4/0x2f8) from [<c00d03d0>] (do_try_to_free_pages+0x300/0x544)
[ 9641.234344] [<c00d03d0>] (do_try_to_free_pages+0x300/0x544) from [<c00d0a44>] (try_to_free_pages+0x2d0/0x398)
[ 9641.234363] [<c00d0a44>] (try_to_free_pages+0x2d0/0x398) from [<c00c6a60>] (__alloc_pages_nodemask+0x494/0x7e8)
[ 9641.234382] [<c00c6a60>] (__alloc_pages_nodemask+0x494/0x7e8) from [<c00f62d8>] (new_slab+0x78/0x238)
[ 9641.234400] [<c00f62d8>] (new_slab+0x78/0x238) from [<c031081c>] (__slab_alloc.constprop.42+0x1a4/0x50c)
[ 9641.234419] [<c031081c>] (__slab_alloc.constprop.42+0x1a4/0x50c) from [<c00f80e8>] (kmem_cache_alloc_trace+0x54/0x188)
[ 9641.234459] [<c00f80e8>] (kmem_cache_alloc_trace+0x54/0x188) from [<bf227908>] (do_readpage+0x168/0x468 [ubifs])
[ 9641.234553] [<bf227908>] (do_readpage+0x168/0x468 [ubifs]) from [<bf2296a0>] (ubifs_readpage+0x424/0x464 [ubifs])
[ 9641.234606] [<bf2296a0>] (ubifs_readpage+0x424/0x464 [ubifs]) from [<c00c17c0>] (filemap_fault+0x304/0x418)
[ 9641.234638] [<c00c17c0>] (filemap_fault+0x304/0x418) from [<c00de694>] (__do_fault+0xd4/0x530)
[ 9641.234665] [<c00de694>] (__do_fault+0xd4/0x530) from [<c00e10c0>] (handle_pte_fault+0x480/0xf54)
[ 9641.234690] [<c00e10c0>] (handle_pte_fault+0x480/0xf54) from [<c00e2bf8>] (handle_mm_fault+0x140/0x184)
[ 9641.234716] [<c00e2bf8>] (handle_mm_fault+0x140/0x184) from [<c0316688>] (do_page_fault+0x150/0x3ac)
[ 9641.234737] [<c0316688>] (do_page_fault+0x150/0x3ac) from [<c000842c>] (do_DataAbort+0x3c/0xa0)
[ 9641.234759] [<c000842c>] (do_DataAbort+0x3c/0xa0) from [<c0314e38>] (__dabt_usr+0x38/0x40)
After analyzing the code, I found a condition that may cause this failed
in correct operations. Thus, I think this assertion is wrong and should be
removed.
Suppose there are two clean znodes and one dirty znode in TNC. So the
per-filesystem atomic_t @clean_zn_cnt is (2). If commit start, dirty_znode
is set to COW_ZNODE in get_znodes_to_commit() in case of potentially ops
on this znode. We clear COW bit and DIRTY bit in write_index() without
@tnc_mutex locked. We don't increase @clean_zn_cnt in this place. As the
comments in write_index() shows, if another process hold @tnc_mutex and
dirty this znode after we clean it, @clean_zn_cnt would be decreased to (1).
We will increase @clean_zn_cnt to (2) with @tnc_mutex locked in
free_obsolete_znodes() to keep it right.
If shrink_tnc() performs between decrease and increase, it will release
other 2 clean znodes it holds and found @clean_zn_cnt is less than zero
(1 - 2 = -1), then hit the assertion. Because free_obsolete_znodes() will
soon correct @clean_zn_cnt and no harm to fs in this case, I think this
assertion could be removed.
2 clean zondes and 1 dirty znode, @clean_zn_cnt == 2
Thread A (commit) Thread B (write or others) Thread C (shrinker)
->write_index
->clear_bit(DIRTY_NODE)
->clear_bit(COW_ZNODE)
@clean_zn_cnt == 2
->mutex_locked(&tnc_mutex)
->dirty_cow_znode
->!ubifs_zn_cow(znode)
->!test_and_set_bit(DIRTY_NODE)
->atomic_dec(&clean_zn_cnt)
->mutex_unlocked(&tnc_mutex)
@clean_zn_cnt == 1
->mutex_locked(&tnc_mutex)
->shrink_tnc
->destroy_tnc_subtree
->atomic_sub(&clean_zn_cnt, 2)
->ubifs_assert <- hit
->mutex_unlocked(&tnc_mutex)
@clean_zn_cnt == -1
->mutex_lock(&tnc_mutex)
->free_obsolete_znodes
->atomic_inc(&clean_zn_cnt)
->mutux_unlock(&tnc_mutex)
@clean_zn_cnt == 0 (correct after shrink)
Signed-off-by: hujianyang <hujianyang@huawei.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ubifs/shrinker.c | 1 -
1 file changed, 1 deletion(-)
--- a/fs/ubifs/shrinker.c
+++ b/fs/ubifs/shrinker.c
@@ -128,7 +128,6 @@ static int shrink_tnc(struct ubifs_info
freed = ubifs_destroy_tnc_subtree(znode);
atomic_long_sub(freed, &ubifs_clean_zn_cnt);
atomic_long_sub(freed, &c->clean_zn_cnt);
- ubifs_assert(atomic_long_read(&c->clean_zn_cnt) >= 0);
total_freed += freed;
znode = zprev;
}
^ permalink raw reply [flat|nested] 26+ messages in thread* [PATCH 3.4 07/19] watchdog: sp805: Set watchdog_device->timeout from ->set_timeout()
2014-07-04 22:15 [PATCH 3.4 00/19] 3.4.97-stable review Greg Kroah-Hartman
` (5 preceding siblings ...)
2014-07-04 22:15 ` [PATCH 3.4 06/19] UBIFS: Remove incorrect assertion in shrink_tnc() Greg Kroah-Hartman
@ 2014-07-04 22:15 ` Greg Kroah-Hartman
2014-07-04 22:15 ` [PATCH 3.4 08/19] IB/qib: Fix port in pkey change event Greg Kroah-Hartman
` (12 subsequent siblings)
19 siblings, 0 replies; 26+ messages in thread
From: Greg Kroah-Hartman @ 2014-07-04 22:15 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Arun Ramamurthy, Viresh Kumar,
Guenter Roeck, Wim Van Sebroeck
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Viresh Kumar <viresh.kumar@linaro.org>
commit 938626d96a3ffb9eb54552bb0d3a4f2b30ffdeb0 upstream.
Implementation of ->set_timeout() is supposed to set 'timeout' field of 'struct
watchdog_device' passed to it. sp805 was rather setting this in a local
variable. Fix it.
Reported-by: Arun Ramamurthy <arun.ramamurthy@broadcom.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/watchdog/sp805_wdt.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/drivers/watchdog/sp805_wdt.c
+++ b/drivers/watchdog/sp805_wdt.c
@@ -62,7 +62,6 @@
* @adev: amba device structure of wdt
* @status: current status of wdt
* @load_val: load value to be set for current timeout
- * @timeout: current programmed timeout
*/
struct sp805_wdt {
spinlock_t lock;
@@ -73,7 +72,6 @@ struct sp805_wdt {
#define WDT_BUSY 0
#define WDT_CAN_BE_CLOSED 1
unsigned int load_val;
- unsigned int timeout;
};
/* local variables */
@@ -101,7 +99,7 @@ static void wdt_setload(unsigned int tim
spin_lock(&wdt->lock);
wdt->load_val = load;
/* roundup timeout to closest positive integer value */
- wdt->timeout = div_u64((load + 1) * 2 + (rate / 2), rate);
+ wdd->timeout = div_u64((load + 1) * 2 + (rate / 2), rate);
spin_unlock(&wdt->lock);
}
^ permalink raw reply [flat|nested] 26+ messages in thread* [PATCH 3.4 08/19] IB/qib: Fix port in pkey change event
2014-07-04 22:15 [PATCH 3.4 00/19] 3.4.97-stable review Greg Kroah-Hartman
` (6 preceding siblings ...)
2014-07-04 22:15 ` [PATCH 3.4 07/19] watchdog: sp805: Set watchdog_device->timeout from ->set_timeout() Greg Kroah-Hartman
@ 2014-07-04 22:15 ` Greg Kroah-Hartman
2014-07-04 22:15 ` [PATCH 3.4 09/19] IB/ipath: Translate legacy diagpkt into newer extended diagpkt Greg Kroah-Hartman
` (11 subsequent siblings)
19 siblings, 0 replies; 26+ messages in thread
From: Greg Kroah-Hartman @ 2014-07-04 22:15 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Alex Estrin, Dennis Dalessandro,
Mike Marciniszyn, Roland Dreier
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mike Marciniszyn <mike.marciniszyn@intel.com>
commit 911eccd284d13d78c92ec4f1f1092c03457d732a upstream.
The code used a literal 1 in dispatching an IB_EVENT_PKEY_CHANGE.
As of the dual port qib QDR card, this is not necessarily correct.
Change to use the port as specified in the call.
Reported-by: Alex Estrin <alex.estrin@intel.com>
Reviewed-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/hw/qib/qib_mad.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/infiniband/hw/qib/qib_mad.c
+++ b/drivers/infiniband/hw/qib/qib_mad.c
@@ -1005,7 +1005,7 @@ static int set_pkeys(struct qib_devdata
event.event = IB_EVENT_PKEY_CHANGE;
event.device = &dd->verbs_dev.ibdev;
- event.element.port_num = 1;
+ event.element.port_num = port;
ib_dispatch_event(&event);
}
return 0;
^ permalink raw reply [flat|nested] 26+ messages in thread* [PATCH 3.4 09/19] IB/ipath: Translate legacy diagpkt into newer extended diagpkt
2014-07-04 22:15 [PATCH 3.4 00/19] 3.4.97-stable review Greg Kroah-Hartman
` (7 preceding siblings ...)
2014-07-04 22:15 ` [PATCH 3.4 08/19] IB/qib: Fix port in pkey change event Greg Kroah-Hartman
@ 2014-07-04 22:15 ` Greg Kroah-Hartman
2014-07-04 22:15 ` [PATCH 3.4 10/19] IB/srp: Fix a sporadic crash triggered by cable pulling Greg Kroah-Hartman
` (10 subsequent siblings)
19 siblings, 0 replies; 26+ messages in thread
From: Greg Kroah-Hartman @ 2014-07-04 22:15 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Rickard Strandqvist, Mike Marciniszyn,
Dennis Dalessandro, Roland Dreier
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dennis Dalessandro <dennis.dalessandro@intel.com>
commit 7e6d3e5c70f13874fb06e6b67696ed90ce79bd48 upstream.
This patch addresses an issue where the legacy diagpacket is sent in
from the user, but the driver operates on only the extended
diagpkt. This patch specifically initializes the extended diagpkt
based on the legacy packet.
Reported-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/hw/ipath/ipath_diag.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/infiniband/hw/ipath/ipath_diag.c
+++ b/drivers/infiniband/hw/ipath/ipath_diag.c
@@ -346,6 +346,10 @@ static ssize_t ipath_diagpkt_write(struc
ret = -EFAULT;
goto bail;
}
+ dp.len = odp.len;
+ dp.unit = odp.unit;
+ dp.data = odp.data;
+ dp.pbc_wd = 0;
} else {
ret = -EINVAL;
goto bail;
^ permalink raw reply [flat|nested] 26+ messages in thread* [PATCH 3.4 10/19] IB/srp: Fix a sporadic crash triggered by cable pulling
2014-07-04 22:15 [PATCH 3.4 00/19] 3.4.97-stable review Greg Kroah-Hartman
` (8 preceding siblings ...)
2014-07-04 22:15 ` [PATCH 3.4 09/19] IB/ipath: Translate legacy diagpkt into newer extended diagpkt Greg Kroah-Hartman
@ 2014-07-04 22:15 ` Greg Kroah-Hartman
2014-07-04 22:15 ` [PATCH 3.4 11/19] IB/umad: Fix error handling Greg Kroah-Hartman
` (9 subsequent siblings)
19 siblings, 0 replies; 26+ messages in thread
From: Greg Kroah-Hartman @ 2014-07-04 22:15 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sagi Grimberg, Bart Van Assche,
Roland Dreier
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bart Van Assche <bvanassche@acm.org>
commit 024ca90151f5e4296d30f72c13ff9a075e23c9ec upstream.
Avoid that the loops that iterate over the request ring can encounter
a pointer to a SCSI command in req->scmnd that is no longer associated
with that request. If the function srp_unmap_data() is invoked twice
for a SCSI command that is not in flight then that would cause
ib_fmr_pool_unmap() to be invoked with an invalid pointer as argument,
resulting in a kernel oops.
Reported-by: Sagi Grimberg <sagig@mellanox.com>
Reference: http://thread.gmane.org/gmane.linux.drivers.rdma/19068/focus=19069
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Sagi Grimberg <sagig@mellanox.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/ulp/srp/ib_srp.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/infiniband/ulp/srp/ib_srp.c
+++ b/drivers/infiniband/ulp/srp/ib_srp.c
@@ -1371,6 +1371,12 @@ err_unmap:
err_iu:
srp_put_tx_iu(target, iu, SRP_IU_CMD);
+ /*
+ * Avoid that the loops that iterate over the request ring can
+ * encounter a dangling SCSI command pointer.
+ */
+ req->scmnd = NULL;
+
spin_lock_irqsave(&target->lock, flags);
list_add(&req->list, &target->free_reqs);
^ permalink raw reply [flat|nested] 26+ messages in thread* [PATCH 3.4 11/19] IB/umad: Fix error handling
2014-07-04 22:15 [PATCH 3.4 00/19] 3.4.97-stable review Greg Kroah-Hartman
` (9 preceding siblings ...)
2014-07-04 22:15 ` [PATCH 3.4 10/19] IB/srp: Fix a sporadic crash triggered by cable pulling Greg Kroah-Hartman
@ 2014-07-04 22:15 ` Greg Kroah-Hartman
2014-07-04 22:15 ` [PATCH 3.4 12/19] IB/umad: Fix use-after-free on close Greg Kroah-Hartman
` (8 subsequent siblings)
19 siblings, 0 replies; 26+ messages in thread
From: Greg Kroah-Hartman @ 2014-07-04 22:15 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Bart Van Assche, Yann Droneaud,
Roland Dreier
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bart Van Assche <bvanassche@acm.org>
commit 8ec0a0e6b58218bdc1db91dd70ebfcd6ad8dd6cd upstream.
Avoid leaking a kref count in ib_umad_open() if port->ib_dev == NULL
or if nonseekable_open() fails.
Avoid leaking a kref count, that sm_sem is kept down and also that the
IB_PORT_SM capability mask is not cleared in ib_umad_sm_open() if
nonseekable_open() fails.
Since container_of() never returns NULL, remove the code that tests
whether container_of() returns NULL.
Moving the kref_get() call from the start of ib_umad_*open() to the
end is safe since it is the responsibility of the caller of these
functions to ensure that the cdev pointer remains valid until at least
when these functions return.
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
[ydroneaud@opteya.com: rework a bit to reduce the amount of code changed]
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
[ nonseekable_open() can't actually fail, but.... - Roland ]
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/core/user_mad.c | 49 ++++++++++++++++++++-----------------
1 file changed, 27 insertions(+), 22 deletions(-)
--- a/drivers/infiniband/core/user_mad.c
+++ b/drivers/infiniband/core/user_mad.c
@@ -780,27 +780,19 @@ static int ib_umad_open(struct inode *in
{
struct ib_umad_port *port;
struct ib_umad_file *file;
- int ret;
+ int ret = -ENXIO;
port = container_of(inode->i_cdev, struct ib_umad_port, cdev);
- if (port)
- kref_get(&port->umad_dev->ref);
- else
- return -ENXIO;
mutex_lock(&port->file_mutex);
- if (!port->ib_dev) {
- ret = -ENXIO;
+ if (!port->ib_dev)
goto out;
- }
+ ret = -ENOMEM;
file = kzalloc(sizeof *file, GFP_KERNEL);
- if (!file) {
- kref_put(&port->umad_dev->ref, ib_umad_release_dev);
- ret = -ENOMEM;
+ if (!file)
goto out;
- }
mutex_init(&file->mutex);
spin_lock_init(&file->send_lock);
@@ -814,6 +806,13 @@ static int ib_umad_open(struct inode *in
list_add_tail(&file->port_list, &port->file_list);
ret = nonseekable_open(inode, filp);
+ if (ret) {
+ list_del(&file->port_list);
+ kfree(file);
+ goto out;
+ }
+
+ kref_get(&port->umad_dev->ref);
out:
mutex_unlock(&port->file_mutex);
@@ -880,10 +879,6 @@ static int ib_umad_sm_open(struct inode
int ret;
port = container_of(inode->i_cdev, struct ib_umad_port, sm_cdev);
- if (port)
- kref_get(&port->umad_dev->ref);
- else
- return -ENXIO;
if (filp->f_flags & O_NONBLOCK) {
if (down_trylock(&port->sm_sem)) {
@@ -898,17 +893,27 @@ static int ib_umad_sm_open(struct inode
}
ret = ib_modify_port(port->ib_dev, port->port_num, 0, &props);
- if (ret) {
- up(&port->sm_sem);
- goto fail;
- }
+ if (ret)
+ goto err_up_sem;
filp->private_data = port;
- return nonseekable_open(inode, filp);
+ ret = nonseekable_open(inode, filp);
+ if (ret)
+ goto err_clr_sm_cap;
+
+ kref_get(&port->umad_dev->ref);
+
+ return 0;
+
+err_clr_sm_cap:
+ swap(props.set_port_cap_mask, props.clr_port_cap_mask);
+ ib_modify_port(port->ib_dev, port->port_num, 0, &props);
+
+err_up_sem:
+ up(&port->sm_sem);
fail:
- kref_put(&port->umad_dev->ref, ib_umad_release_dev);
return ret;
}
^ permalink raw reply [flat|nested] 26+ messages in thread* [PATCH 3.4 12/19] IB/umad: Fix use-after-free on close
2014-07-04 22:15 [PATCH 3.4 00/19] 3.4.97-stable review Greg Kroah-Hartman
` (10 preceding siblings ...)
2014-07-04 22:15 ` [PATCH 3.4 11/19] IB/umad: Fix error handling Greg Kroah-Hartman
@ 2014-07-04 22:15 ` Greg Kroah-Hartman
2014-07-04 22:15 ` [PATCH 3.4 13/19] nfsd4: fix FREE_STATEID lockowner leak Greg Kroah-Hartman
` (7 subsequent siblings)
19 siblings, 0 replies; 26+ messages in thread
From: Greg Kroah-Hartman @ 2014-07-04 22:15 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Bart Van Assche, Yann Droneaud,
Roland Dreier
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bart Van Assche <bvanassche@acm.org>
commit 60e1751cb52cc6d1ae04b6bd3c2b96e770b5823f upstream.
Avoid that closing /dev/infiniband/umad<n> or /dev/infiniband/issm<n>
triggers a use-after-free. __fput() invokes f_op->release() before it
invokes cdev_put(). Make sure that the ib_umad_device structure is
freed by the cdev_put() call instead of f_op->release(). This avoids
that changing the port mode from IB into Ethernet and back to IB
followed by restarting opensmd triggers the following kernel oops:
general protection fault: 0000 [#1] PREEMPT SMP
RIP: 0010:[<ffffffff810cc65c>] [<ffffffff810cc65c>] module_put+0x2c/0x170
Call Trace:
[<ffffffff81190f20>] cdev_put+0x20/0x30
[<ffffffff8118e2ce>] __fput+0x1ae/0x1f0
[<ffffffff8118e35e>] ____fput+0xe/0x10
[<ffffffff810723bc>] task_work_run+0xac/0xe0
[<ffffffff81002a9f>] do_notify_resume+0x9f/0xc0
[<ffffffff814b8398>] int_signal+0x12/0x17
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=75051
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Yann Droneaud <ydroneaud@opteya.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/core/user_mad.c | 30 +++++++++++++++++++-----------
1 file changed, 19 insertions(+), 11 deletions(-)
--- a/drivers/infiniband/core/user_mad.c
+++ b/drivers/infiniband/core/user_mad.c
@@ -98,7 +98,7 @@ struct ib_umad_port {
struct ib_umad_device {
int start_port, end_port;
- struct kref ref;
+ struct kobject kobj;
struct ib_umad_port port[0];
};
@@ -134,14 +134,18 @@ static DECLARE_BITMAP(dev_map, IB_UMAD_M
static void ib_umad_add_one(struct ib_device *device);
static void ib_umad_remove_one(struct ib_device *device);
-static void ib_umad_release_dev(struct kref *ref)
+static void ib_umad_release_dev(struct kobject *kobj)
{
struct ib_umad_device *dev =
- container_of(ref, struct ib_umad_device, ref);
+ container_of(kobj, struct ib_umad_device, kobj);
kfree(dev);
}
+static struct kobj_type ib_umad_dev_ktype = {
+ .release = ib_umad_release_dev,
+};
+
static int hdr_size(struct ib_umad_file *file)
{
return file->use_pkey_index ? sizeof (struct ib_user_mad_hdr) :
@@ -812,7 +816,7 @@ static int ib_umad_open(struct inode *in
goto out;
}
- kref_get(&port->umad_dev->ref);
+ kobject_get(&port->umad_dev->kobj);
out:
mutex_unlock(&port->file_mutex);
@@ -851,7 +855,7 @@ static int ib_umad_close(struct inode *i
mutex_unlock(&file->port->file_mutex);
kfree(file);
- kref_put(&dev->ref, ib_umad_release_dev);
+ kobject_put(&dev->kobj);
return 0;
}
@@ -902,7 +906,7 @@ static int ib_umad_sm_open(struct inode
if (ret)
goto err_clr_sm_cap;
- kref_get(&port->umad_dev->ref);
+ kobject_get(&port->umad_dev->kobj);
return 0;
@@ -932,7 +936,7 @@ static int ib_umad_sm_close(struct inode
up(&port->sm_sem);
- kref_put(&port->umad_dev->ref, ib_umad_release_dev);
+ kobject_put(&port->umad_dev->kobj);
return ret;
}
@@ -1000,6 +1004,7 @@ static int find_overflow_devnum(void)
}
static int ib_umad_init_port(struct ib_device *device, int port_num,
+ struct ib_umad_device *umad_dev,
struct ib_umad_port *port)
{
int devnum;
@@ -1032,6 +1037,7 @@ static int ib_umad_init_port(struct ib_d
cdev_init(&port->cdev, &umad_fops);
port->cdev.owner = THIS_MODULE;
+ port->cdev.kobj.parent = &umad_dev->kobj;
kobject_set_name(&port->cdev.kobj, "umad%d", port->dev_num);
if (cdev_add(&port->cdev, base, 1))
goto err_cdev;
@@ -1050,6 +1056,7 @@ static int ib_umad_init_port(struct ib_d
base += IB_UMAD_MAX_PORTS;
cdev_init(&port->sm_cdev, &umad_sm_fops);
port->sm_cdev.owner = THIS_MODULE;
+ port->sm_cdev.kobj.parent = &umad_dev->kobj;
kobject_set_name(&port->sm_cdev.kobj, "issm%d", port->dev_num);
if (cdev_add(&port->sm_cdev, base, 1))
goto err_sm_cdev;
@@ -1143,7 +1150,7 @@ static void ib_umad_add_one(struct ib_de
if (!umad_dev)
return;
- kref_init(&umad_dev->ref);
+ kobject_init(&umad_dev->kobj, &ib_umad_dev_ktype);
umad_dev->start_port = s;
umad_dev->end_port = e;
@@ -1151,7 +1158,8 @@ static void ib_umad_add_one(struct ib_de
for (i = s; i <= e; ++i) {
umad_dev->port[i - s].umad_dev = umad_dev;
- if (ib_umad_init_port(device, i, &umad_dev->port[i - s]))
+ if (ib_umad_init_port(device, i, umad_dev,
+ &umad_dev->port[i - s]))
goto err;
}
@@ -1163,7 +1171,7 @@ err:
while (--i >= s)
ib_umad_kill_port(&umad_dev->port[i - s]);
- kref_put(&umad_dev->ref, ib_umad_release_dev);
+ kobject_put(&umad_dev->kobj);
}
static void ib_umad_remove_one(struct ib_device *device)
@@ -1177,7 +1185,7 @@ static void ib_umad_remove_one(struct ib
for (i = 0; i <= umad_dev->end_port - umad_dev->start_port; ++i)
ib_umad_kill_port(&umad_dev->port[i]);
- kref_put(&umad_dev->ref, ib_umad_release_dev);
+ kobject_put(&umad_dev->kobj);
}
static char *umad_devnode(struct device *dev, umode_t *mode)
^ permalink raw reply [flat|nested] 26+ messages in thread* [PATCH 3.4 13/19] nfsd4: fix FREE_STATEID lockowner leak
2014-07-04 22:15 [PATCH 3.4 00/19] 3.4.97-stable review Greg Kroah-Hartman
` (11 preceding siblings ...)
2014-07-04 22:15 ` [PATCH 3.4 12/19] IB/umad: Fix use-after-free on close Greg Kroah-Hartman
@ 2014-07-04 22:15 ` Greg Kroah-Hartman
2014-07-04 22:15 ` [PATCH 3.4 14/19] nfsd: getattr for FATTR4_WORD0_FILES_AVAIL needs the statfs buffer Greg Kroah-Hartman
` (6 subsequent siblings)
19 siblings, 0 replies; 26+ messages in thread
From: Greg Kroah-Hartman @ 2014-07-04 22:15 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jeff Layton, J. Bruce Fields
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: "J. Bruce Fields" <bfields@redhat.com>
commit 48385408b45523d9a432c66292d47ef43efcbb94 upstream.
27b11428b7de ("nfsd4: remove lockowner when removing lock stateid")
introduced a memory leak.
Reported-by: Jeff Layton <jeff.layton@primarydata.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/nfsd/nfs4state.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -3485,7 +3485,7 @@ nfsd4_free_lock_stateid(struct nfs4_ol_s
* correspondance, and we have to delete the lockowner when we
* delete the lock stateid:
*/
- unhash_lockowner(lo);
+ release_lockowner(lo);
return nfs_ok;
}
^ permalink raw reply [flat|nested] 26+ messages in thread* [PATCH 3.4 14/19] nfsd: getattr for FATTR4_WORD0_FILES_AVAIL needs the statfs buffer
2014-07-04 22:15 [PATCH 3.4 00/19] 3.4.97-stable review Greg Kroah-Hartman
` (12 preceding siblings ...)
2014-07-04 22:15 ` [PATCH 3.4 13/19] nfsd4: fix FREE_STATEID lockowner leak Greg Kroah-Hartman
@ 2014-07-04 22:15 ` Greg Kroah-Hartman
2014-07-04 22:15 ` [PATCH 3.4 15/19] powerpc/pseries: Fix overwritten PE state Greg Kroah-Hartman
` (5 subsequent siblings)
19 siblings, 0 replies; 26+ messages in thread
From: Greg Kroah-Hartman @ 2014-07-04 22:15 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Christoph Hellwig, J. Bruce Fields
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christoph Hellwig <hch@lst.de>
commit 12337901d654415d9f764b5f5ba50052e9700f37 upstream.
Note nobody's ever noticed because the typical client probably never
requests FILES_AVAIL without also requesting something else on the list.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/nfsd/nfs4xdr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/nfsd/nfs4xdr.c
+++ b/fs/nfsd/nfs4xdr.c
@@ -2032,8 +2032,8 @@ nfsd4_encode_fattr(struct svc_fh *fhp, s
err = vfs_getattr(exp->ex_path.mnt, dentry, &stat);
if (err)
goto out_nfserr;
- if ((bmval0 & (FATTR4_WORD0_FILES_FREE | FATTR4_WORD0_FILES_TOTAL |
- FATTR4_WORD0_MAXNAME)) ||
+ if ((bmval0 & (FATTR4_WORD0_FILES_AVAIL | FATTR4_WORD0_FILES_FREE |
+ FATTR4_WORD0_FILES_TOTAL | FATTR4_WORD0_MAXNAME)) ||
(bmval1 & (FATTR4_WORD1_SPACE_AVAIL | FATTR4_WORD1_SPACE_FREE |
FATTR4_WORD1_SPACE_TOTAL))) {
err = vfs_statfs(&path, &statfs);
^ permalink raw reply [flat|nested] 26+ messages in thread* [PATCH 3.4 15/19] powerpc/pseries: Fix overwritten PE state
2014-07-04 22:15 [PATCH 3.4 00/19] 3.4.97-stable review Greg Kroah-Hartman
` (13 preceding siblings ...)
2014-07-04 22:15 ` [PATCH 3.4 14/19] nfsd: getattr for FATTR4_WORD0_FILES_AVAIL needs the statfs buffer Greg Kroah-Hartman
@ 2014-07-04 22:15 ` Greg Kroah-Hartman
2014-07-04 22:15 ` [PATCH 3.4 16/19] powerpc: fix typo CONFIG_PMAC Greg Kroah-Hartman
` (4 subsequent siblings)
19 siblings, 0 replies; 26+ messages in thread
From: Greg Kroah-Hartman @ 2014-07-04 22:15 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Joe Perches, Gavin Shan,
Benjamin Herrenschmidt
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gavin Shan <gwshan@linux.vnet.ibm.com>
commit 54f112a3837d4e7532bbedbbbf27c0de277be510 upstream.
In pseries_eeh_get_state(), EEH_STATE_UNAVAILABLE is always
overwritten by EEH_STATE_NOT_SUPPORT because of the missed
"break" there. The patch fixes the issue.
Reported-by: Joe Perches <joe@perches.com>
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/platforms/pseries/eeh_pseries.c | 1 +
1 file changed, 1 insertion(+)
--- a/arch/powerpc/platforms/pseries/eeh_pseries.c
+++ b/arch/powerpc/platforms/pseries/eeh_pseries.c
@@ -319,6 +319,7 @@ static int pseries_eeh_get_state(struct
} else {
result = EEH_STATE_NOT_SUPPORT;
}
+ break;
default:
result = EEH_STATE_NOT_SUPPORT;
}
^ permalink raw reply [flat|nested] 26+ messages in thread* [PATCH 3.4 16/19] powerpc: fix typo CONFIG_PMAC
2014-07-04 22:15 [PATCH 3.4 00/19] 3.4.97-stable review Greg Kroah-Hartman
` (14 preceding siblings ...)
2014-07-04 22:15 ` [PATCH 3.4 15/19] powerpc/pseries: Fix overwritten PE state Greg Kroah-Hartman
@ 2014-07-04 22:15 ` Greg Kroah-Hartman
2014-07-04 22:15 ` [PATCH 3.4 17/19] powerpc: fix typo CONFIG_PPC_CPU Greg Kroah-Hartman
` (3 subsequent siblings)
19 siblings, 0 replies; 26+ messages in thread
From: Greg Kroah-Hartman @ 2014-07-04 22:15 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Paul Bolle, Benjamin Herrenschmidt
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Bolle <pebolle@tiscali.nl>
commit 6e0fdf9af216887e0032c19d276889aad41cad00 upstream.
Commit b0d278b7d3ae ("powerpc/perf_event: Reduce latency of calling
perf_event_do_pending") added a check for CONFIG_PMAC were a check for
CONFIG_PPC_PMAC was clearly intended.
Fixes: b0d278b7d3ae ("powerpc/perf_event: Reduce latency of calling perf_event_do_pending")
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/kernel/time.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -496,7 +496,7 @@ void timer_interrupt(struct pt_regs * re
__get_cpu_var(irq_stat).timer_irqs++;
-#if defined(CONFIG_PPC32) && defined(CONFIG_PMAC)
+#if defined(CONFIG_PPC32) && defined(CONFIG_PPC_PMAC)
if (atomic_read(&ppc_n_lost_interrupts) != 0)
do_IRQ(regs);
#endif
^ permalink raw reply [flat|nested] 26+ messages in thread* [PATCH 3.4 17/19] powerpc: fix typo CONFIG_PPC_CPU
2014-07-04 22:15 [PATCH 3.4 00/19] 3.4.97-stable review Greg Kroah-Hartman
` (15 preceding siblings ...)
2014-07-04 22:15 ` [PATCH 3.4 16/19] powerpc: fix typo CONFIG_PMAC Greg Kroah-Hartman
@ 2014-07-04 22:15 ` Greg Kroah-Hartman
2014-07-04 22:15 ` [PATCH 3.4 18/19] ptrace,x86: force IRET path after a ptrace_stop() Greg Kroah-Hartman
` (2 subsequent siblings)
19 siblings, 0 replies; 26+ messages in thread
From: Greg Kroah-Hartman @ 2014-07-04 22:15 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Paul Bolle, Benjamin Herrenschmidt
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Bolle <pebolle@tiscali.nl>
commit b69a1da94f3d1589d1942b5d1b384d8cfaac4500 upstream.
Commit cd64d1697cf0 ("powerpc: mtmsrd not defined") added a check for
CONFIG_PPC_CPU were a check for CONFIG_PPC_FPU was clearly intended.
Fixes: cd64d1697cf0 ("powerpc: mtmsrd not defined")
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/lib/sstep.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -1395,7 +1395,7 @@ int __kprobes emulate_step(struct pt_reg
regs->gpr[rd] = byterev_4(val);
goto ldst_done;
-#ifdef CONFIG_PPC_CPU
+#ifdef CONFIG_PPC_FPU
case 535: /* lfsx */
case 567: /* lfsux */
if (!(regs->msr & MSR_FP))
^ permalink raw reply [flat|nested] 26+ messages in thread* [PATCH 3.4 18/19] ptrace,x86: force IRET path after a ptrace_stop()
2014-07-04 22:15 [PATCH 3.4 00/19] 3.4.97-stable review Greg Kroah-Hartman
` (16 preceding siblings ...)
2014-07-04 22:15 ` [PATCH 3.4 17/19] powerpc: fix typo CONFIG_PPC_CPU Greg Kroah-Hartman
@ 2014-07-04 22:15 ` Greg Kroah-Hartman
2014-07-04 22:15 ` [PATCH 3.4 19/19] tracing: Fix syscall_*regfunc() vs copy_process() race Greg Kroah-Hartman
2014-07-05 5:39 ` [PATCH 3.4 00/19] 3.4.97-stable review Guenter Roeck
19 siblings, 0 replies; 26+ messages in thread
From: Greg Kroah-Hartman @ 2014-07-04 22:15 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Tejun Heo, Andy Lutomirski,
Oleg Nesterov, Linus Torvalds
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tejun Heo <tj@kernel.org>
commit b9cd18de4db3c9ffa7e17b0dc0ca99ed5aa4d43a upstream.
The 'sysret' fastpath does not correctly restore even all regular
registers, much less any segment registers or reflags values. That is
very much part of why it's faster than 'iret'.
Normally that isn't a problem, because the normal ptrace() interface
catches the process using the signal handler infrastructure, which
always returns with an iret.
However, some paths can get caught using ptrace_event() instead of the
signal path, and for those we need to make sure that we aren't going to
return to user space using 'sysret'. Otherwise the modifications that
may have been done to the register set by the tracer wouldn't
necessarily take effect.
Fix it by forcing IRET path by setting TIF_NOTIFY_RESUME from
arch_ptrace_stop_needed() which is invoked from ptrace_stop().
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Andy Lutomirski <luto@amacapital.net>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/include/asm/ptrace.h | 16 ++++++++++++++++
include/linux/ptrace.h | 3 +++
2 files changed, 19 insertions(+)
--- a/arch/x86/include/asm/ptrace.h
+++ b/arch/x86/include/asm/ptrace.h
@@ -286,6 +286,22 @@ static inline unsigned long regs_get_ker
#define ARCH_HAS_USER_SINGLE_STEP_INFO
+/*
+ * When hitting ptrace_stop(), we cannot return using SYSRET because
+ * that does not restore the full CPU state, only a minimal set. The
+ * ptracer can change arbitrary register values, which is usually okay
+ * because the usual ptrace stops run off the signal delivery path which
+ * forces IRET; however, ptrace_event() stops happen in arbitrary places
+ * in the kernel and don't force IRET path.
+ *
+ * So force IRET path after a ptrace stop.
+ */
+#define arch_ptrace_stop_needed(code, info) \
+({ \
+ set_thread_flag(TIF_NOTIFY_RESUME); \
+ false; \
+})
+
struct user_desc;
extern int do_get_thread_area(struct task_struct *p, int idx,
struct user_desc __user *info);
--- a/include/linux/ptrace.h
+++ b/include/linux/ptrace.h
@@ -379,6 +379,9 @@ static inline void user_single_step_sigi
* calling arch_ptrace_stop() when it would be superfluous. For example,
* if the thread has not been back to user mode since the last stop, the
* thread state might indicate that nothing needs to be done.
+ *
+ * This is guaranteed to be invoked once before a task stops for ptrace and
+ * may include arch-specific operations necessary prior to a ptrace stop.
*/
#define arch_ptrace_stop_needed(code, info) (0)
#endif
^ permalink raw reply [flat|nested] 26+ messages in thread* [PATCH 3.4 19/19] tracing: Fix syscall_*regfunc() vs copy_process() race
2014-07-04 22:15 [PATCH 3.4 00/19] 3.4.97-stable review Greg Kroah-Hartman
` (17 preceding siblings ...)
2014-07-04 22:15 ` [PATCH 3.4 18/19] ptrace,x86: force IRET path after a ptrace_stop() Greg Kroah-Hartman
@ 2014-07-04 22:15 ` Greg Kroah-Hartman
2014-07-05 5:39 ` [PATCH 3.4 00/19] 3.4.97-stable review Guenter Roeck
19 siblings, 0 replies; 26+ messages in thread
From: Greg Kroah-Hartman @ 2014-07-04 22:15 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Frederic Weisbecker, Paul E. McKenney,
Oleg Nesterov, Steven Rostedt
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Oleg Nesterov <oleg@redhat.com>
commit 4af4206be2bd1933cae20c2b6fb2058dbc887f7c upstream.
syscall_regfunc() and syscall_unregfunc() should set/clear
TIF_SYSCALL_TRACEPOINT system-wide, but do_each_thread() can race
with copy_process() and miss the new child which was not added to
the process/thread lists yet.
Change copy_process() to update the child's TIF_SYSCALL_TRACEPOINT
under tasklist.
Link: http://lkml.kernel.org/p/20140413185854.GB20668@redhat.com
Fixes: a871bd33a6c0 "tracing: Add syscall tracepoints"
Acked-by: Frederic Weisbecker <fweisbec@gmail.com>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/trace/syscall.h | 15 +++++++++++++++
kernel/fork.c | 2 ++
2 files changed, 17 insertions(+)
--- a/include/trace/syscall.h
+++ b/include/trace/syscall.h
@@ -4,6 +4,7 @@
#include <linux/tracepoint.h>
#include <linux/unistd.h>
#include <linux/ftrace_event.h>
+#include <linux/thread_info.h>
#include <asm/ptrace.h>
@@ -54,4 +55,18 @@ int perf_sysexit_enable(struct ftrace_ev
void perf_sysexit_disable(struct ftrace_event_call *call);
#endif
+#if defined(CONFIG_TRACEPOINTS) && defined(CONFIG_HAVE_SYSCALL_TRACEPOINTS)
+static inline void syscall_tracepoint_update(struct task_struct *p)
+{
+ if (test_thread_flag(TIF_SYSCALL_TRACEPOINT))
+ set_tsk_thread_flag(p, TIF_SYSCALL_TRACEPOINT);
+ else
+ clear_tsk_thread_flag(p, TIF_SYSCALL_TRACEPOINT);
+}
+#else
+static inline void syscall_tracepoint_update(struct task_struct *p)
+{
+}
+#endif
+
#endif /* _TRACE_SYSCALL_H */
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1441,7 +1441,9 @@ static struct task_struct *copy_process(
total_forks++;
spin_unlock(¤t->sighand->siglock);
+ syscall_tracepoint_update(p);
write_unlock_irq(&tasklist_lock);
+
proc_fork_connector(p);
cgroup_post_fork(p);
if (clone_flags & CLONE_THREAD)
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH 3.4 00/19] 3.4.97-stable review
2014-07-04 22:15 [PATCH 3.4 00/19] 3.4.97-stable review Greg Kroah-Hartman
` (18 preceding siblings ...)
2014-07-04 22:15 ` [PATCH 3.4 19/19] tracing: Fix syscall_*regfunc() vs copy_process() race Greg Kroah-Hartman
@ 2014-07-05 5:39 ` Guenter Roeck
2014-07-05 6:53 ` Satoru Takeuchi
2014-07-05 17:46 ` Greg Kroah-Hartman
19 siblings, 2 replies; 26+ messages in thread
From: Guenter Roeck @ 2014-07-05 5:39 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, satoru.takeuchi, shuah.kh, stable
On 07/04/2014 03:15 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.4.97 release.
> There are 19 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun Jul 6 22:14:29 UTC 2014.
> Anything received after that time might be too late.
>
Build results:
total: 137 pass: 111 skipped: 20 fail: 6
Failed builds:
alpha:allmodconfig
arm:spear6xx_defconfig
score:defconfig
sparc64:allmodconfig
unicore32:defconfig
xtensa:allmodconfi
Qemu tests all passed.
Results are as expected.
Details are available at http://server.roeck-us.net:8010/builders.
Guenter
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH 3.4 00/19] 3.4.97-stable review
2014-07-05 5:39 ` [PATCH 3.4 00/19] 3.4.97-stable review Guenter Roeck
@ 2014-07-05 6:53 ` Satoru Takeuchi
2014-07-05 17:47 ` Greg Kroah-Hartman
2014-07-05 17:46 ` Greg Kroah-Hartman
1 sibling, 1 reply; 26+ messages in thread
From: Satoru Takeuchi @ 2014-07-05 6:53 UTC (permalink / raw)
To: Guenter Roeck
Cc: Greg Kroah-Hartman, linux-kernel, torvalds, akpm, satoru.takeuchi,
shuah.kh, stable
At Fri, 04 Jul 2014 22:39:01 -0700,
Guenter Roeck wrote:
>
> On 07/04/2014 03:15 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.4.97 release.
> > There are 19 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sun Jul 6 22:14:29 UTC 2014.
> > Anything received after that time might be too late.
> >
>
> Build results:
> total: 137 pass: 111 skipped: 20 fail: 6
> Failed builds:
> alpha:allmodconfig
> arm:spear6xx_defconfig
> score:defconfig
> sparc64:allmodconfig
> unicore32:defconfig
> xtensa:allmodconfi
>
> Qemu tests all passed.
>
> Results are as expected.
>
> Details are available at http://server.roeck-us.net:8010/builders.
This kernel 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
Satoru
>
> Guenter
>
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH 3.4 00/19] 3.4.97-stable review
2014-07-05 6:53 ` Satoru Takeuchi
@ 2014-07-05 17:47 ` Greg Kroah-Hartman
0 siblings, 0 replies; 26+ messages in thread
From: Greg Kroah-Hartman @ 2014-07-05 17:47 UTC (permalink / raw)
To: Satoru Takeuchi
Cc: Guenter Roeck, linux-kernel, torvalds, akpm, shuah.kh, stable
On Sat, Jul 05, 2014 at 03:53:09PM +0900, Satoru Takeuchi wrote:
> At Fri, 04 Jul 2014 22:39:01 -0700,
> Guenter Roeck wrote:
> >
> > On 07/04/2014 03:15 PM, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 3.4.97 release.
> > > There are 19 patches in this series, all will be posted as a response
> > > to this one. If anyone has any issues with these being applied, please
> > > let me know.
> > >
> > > Responses should be made by Sun Jul 6 22:14:29 UTC 2014.
> > > Anything received after that time might be too late.
> > >
> >
> > Build results:
> > total: 137 pass: 111 skipped: 20 fail: 6
> > Failed builds:
> > alpha:allmodconfig
> > arm:spear6xx_defconfig
> > score:defconfig
> > sparc64:allmodconfig
> > unicore32:defconfig
> > xtensa:allmodconfi
> >
> > Qemu tests all passed.
> >
> > Results are as expected.
> >
> > Details are available at http://server.roeck-us.net:8010/builders.
>
> This kernel 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
Great, thanks for testing and letting me know.
greg k-h
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH 3.4 00/19] 3.4.97-stable review
2014-07-05 5:39 ` [PATCH 3.4 00/19] 3.4.97-stable review Guenter Roeck
2014-07-05 6:53 ` Satoru Takeuchi
@ 2014-07-05 17:46 ` Greg Kroah-Hartman
2014-07-05 17:48 ` Greg Kroah-Hartman
1 sibling, 1 reply; 26+ messages in thread
From: Greg Kroah-Hartman @ 2014-07-05 17:46 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-kernel, torvalds, akpm, satoru.takeuchi, shuah.kh, stable
On Fri, Jul 04, 2014 at 10:39:01PM -0700, Guenter Roeck wrote:
> On 07/04/2014 03:15 PM, Greg Kroah-Hartman wrote:
> >This is the start of the stable review cycle for the 3.4.97 release.
> >There are 19 patches in this series, all will be posted as a response
> >to this one. If anyone has any issues with these being applied, please
> >let me know.
> >
> >Responses should be made by Sun Jul 6 22:14:29 UTC 2014.
> >Anything received after that time might be too late.
> >
>
> Build results:
> total: 137 pass: 111 skipped: 20 fail: 6
111 skipped? Did you add a bunch more targets? Why skip them?
thanks for testing,
greg k-h
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH 3.4 00/19] 3.4.97-stable review
2014-07-05 17:46 ` Greg Kroah-Hartman
@ 2014-07-05 17:48 ` Greg Kroah-Hartman
2014-07-05 18:26 ` Guenter Roeck
0 siblings, 1 reply; 26+ messages in thread
From: Greg Kroah-Hartman @ 2014-07-05 17:48 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-kernel, torvalds, akpm, satoru.takeuchi, shuah.kh, stable
On Sat, Jul 05, 2014 at 10:46:46AM -0700, Greg Kroah-Hartman wrote:
> On Fri, Jul 04, 2014 at 10:39:01PM -0700, Guenter Roeck wrote:
> > On 07/04/2014 03:15 PM, Greg Kroah-Hartman wrote:
> > >This is the start of the stable review cycle for the 3.4.97 release.
> > >There are 19 patches in this series, all will be posted as a response
> > >to this one. If anyone has any issues with these being applied, please
> > >let me know.
> > >
> > >Responses should be made by Sun Jul 6 22:14:29 UTC 2014.
> > >Anything received after that time might be too late.
> > >
> >
> > Build results:
> > total: 137 pass: 111 skipped: 20 fail: 6
>
> 111 skipped? Did you add a bunch more targets? Why skip them?
Doh, that is 20 skipped, nevermind...
But, in looking at your site, it seems that there are always at least 7
that are "skipped", for all kernel versions. Why?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH 3.4 00/19] 3.4.97-stable review
2014-07-05 17:48 ` Greg Kroah-Hartman
@ 2014-07-05 18:26 ` Guenter Roeck
0 siblings, 0 replies; 26+ messages in thread
From: Guenter Roeck @ 2014-07-05 18:26 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, satoru.takeuchi, shuah.kh, stable
On 07/05/2014 10:48 AM, Greg Kroah-Hartman wrote:
> On Sat, Jul 05, 2014 at 10:46:46AM -0700, Greg Kroah-Hartman wrote:
>> On Fri, Jul 04, 2014 at 10:39:01PM -0700, Guenter Roeck wrote:
>>> On 07/04/2014 03:15 PM, Greg Kroah-Hartman wrote:
>>>> This is the start of the stable review cycle for the 3.4.97 release.
>>>> There are 19 patches in this series, all will be posted as a response
>>>> to this one. If anyone has any issues with these being applied, please
>>>> let me know.
>>>>
>>>> Responses should be made by Sun Jul 6 22:14:29 UTC 2014.
>>>> Anything received after that time might be too late.
>>>>
>>>
>>> Build results:
>>> total: 137 pass: 111 skipped: 20 fail: 6
>>
>> 111 skipped? Did you add a bunch more targets? Why skip them?
>
> Doh, that is 20 skipped, nevermind...
>
> But, in looking at your site, it seems that there are always at least 7
> that are "skipped", for all kernel versions. Why?
>
lowest 'skipped' value is actually 4, for 3.14.
'skipped' means that a configuration does not apply for this kernel version.
As I am adding more recent configurations, the number of 'skipped' builds
gets larger for older kernels. Similar, as configurations are dropped
from newer kernels, the number gets larger for newer kernels as well.
I'll see if I can change the output and not display the 'skipped' value
in the final summary; it doesn't really provide value and just creates
confusion.
Guenter
^ permalink raw reply [flat|nested] 26+ messages in thread