* [ 01/48] staging:iio:ad7606: Re-add missing scale attribute
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 02/48] Tools: hv: verify origin of netlink connector message Ben Hutchings
` (47 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Lars-Peter Clausen, Jonathan Cameron,
Greg Kroah-Hartman
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lars-Peter Clausen <lars@metafoo.de>
commit 279bf2e57c30c9a4482b2b6ede11b31c41e35e78 upstream.
Commit 50ac23be ("staging:iio:adc:ad7606 add local define for chan_spec
structures.") accidentally removed the scale info_mask flag. This patch
adds it back again.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[bwh: Backported to 3.2:
- info_mask was completely gone rather than set to another flag
- IIO_CHAN_INFO_SCALE_SHARED_BIT was not defined; write it out as a shift]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
--- a/drivers/staging/iio/adc/ad7606_core.c
+++ b/drivers/staging/iio/adc/ad7606_core.c
@@ -241,6 +241,7 @@
.indexed = 1, \
.channel = num, \
.address = num, \
+ .info_mask = (1 << IIO_CHAN_INFO_SCALE_SHARED), \
.scan_index = num, \
.scan_type = IIO_ST('s', 16, 16, 0), \
}
^ permalink raw reply [flat|nested] 78+ messages in thread* [ 02/48] Tools: hv: verify origin of netlink connector message
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
2012-07-01 17:20 ` [ 01/48] staging:iio:ad7606: Re-add missing scale attribute Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 03/48] edac: avoid mce decoding crash after edac driver unloaded Ben Hutchings
` (46 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Olaf Hering, Marcus Meissner,
Sebastian Krahmer, K. Y. Srinivasan, Greg Kroah-Hartman
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Olaf Hering <olaf@aepfle.de>
commit bcc2c9c3fff859e0eb019fe6fec26f9b8eba795c upstream.
The SuSE security team suggested to use recvfrom instead of recv to be
certain that the connector message is originated from kernel.
CVE-2012-2669
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Marcus Meissner <meissner@suse.de>
Signed-off-by: Sebastian Krahmer <krahmer@suse.de>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
tools/hv/hv_kvp_daemon.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index 146fd61..d9834b3 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -701,14 +701,18 @@ int main(void)
pfd.fd = fd;
while (1) {
+ struct sockaddr *addr_p = (struct sockaddr *) &addr;
+ socklen_t addr_l = sizeof(addr);
pfd.events = POLLIN;
pfd.revents = 0;
poll(&pfd, 1, -1);
- len = recv(fd, kvp_recv_buffer, sizeof(kvp_recv_buffer), 0);
+ len = recvfrom(fd, kvp_recv_buffer, sizeof(kvp_recv_buffer), 0,
+ addr_p, &addr_l);
- if (len < 0) {
- syslog(LOG_ERR, "recv failed; error:%d", len);
+ if (len < 0 || addr.nl_pid) {
+ syslog(LOG_ERR, "recvfrom failed; pid:%u error:%d %s",
+ addr.nl_pid, errno, strerror(errno));
close(fd);
return -1;
}
^ permalink raw reply related [flat|nested] 78+ messages in thread* [ 03/48] edac: avoid mce decoding crash after edac driver unloaded
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
2012-07-01 17:20 ` [ 01/48] staging:iio:ad7606: Re-add missing scale attribute Ben Hutchings
2012-07-01 17:20 ` [ 02/48] Tools: hv: verify origin of netlink connector message Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 04/48] hwrng: atmel-rng - fix data valid check Ben Hutchings
` (45 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Chen Gong, Mauro Carvalho Chehab
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chen Gong <gong.chen@linux.intel.com>
commit e35fca4791fcdd43dc1fd769797df40c562ab491 upstream.
Some edac drivers register themselves as mce decoders via
notifier_chain. But in current notifier_chain implementation logic,
it doesn't accept same notifier registered twice. If so, it will be
wrong when adding/removing the element from the list. For example,
on one SandyBridge platform, remove module sb_edac and then trigger
one error, it will hit oops because it has no mce decoder registered
but related notifier_chain still points to an invalid callback
function. Here is an example:
Call Trace:
[<ffffffff8150ef6a>] atomic_notifier_call_chain+0x1a/0x20
[<ffffffff8102b936>] mce_log+0x46/0x180
[<ffffffff8102eaea>] apei_mce_report_mem_error+0x4a/0x60
[<ffffffff812e19d2>] ghes_do_proc+0x192/0x210
[<ffffffff812e2066>] ghes_proc+0x46/0x70
[<ffffffff812e20d8>] ghes_notify_sci+0x48/0x80
[<ffffffff8150ef05>] notifier_call_chain+0x55/0x80
[<ffffffff81076f1a>] __blocking_notifier_call_chain+0x5a/0x80
[<ffffffff812aea11>] ? acpi_os_wait_events_complete+0x23/0x23
[<ffffffff81076f56>] blocking_notifier_call_chain+0x16/0x20
[<ffffffff812ddc4d>] acpi_hed_notify+0x19/0x1b
[<ffffffff812b16bd>] acpi_device_notify+0x19/0x1b
[<ffffffff812beb38>] acpi_ev_notify_dispatch+0x67/0x7f
[<ffffffff812aea3a>] acpi_os_execute_deferred+0x29/0x36
[<ffffffff81069dc2>] process_one_work+0x132/0x450
[<ffffffff8106bbcb>] worker_thread+0x17b/0x3c0
[<ffffffff8106ba50>] ? manage_workers+0x120/0x120
[<ffffffff81070aee>] kthread+0x9e/0xb0
[<ffffffff81514724>] kernel_thread_helper+0x4/0x10
[<ffffffff81070a50>] ? kthread_freezable_should_stop+0x70/0x70
[<ffffffff81514720>] ? gs_change+0x13/0x13
Code: f3 49 89 d4 45 85 ed 4d 89 c6 48 8b 0f 74 48 48 85 c9 75 17 eb 41
0f 1f 80 00 00 00 00 41 83 ed 01 4c 89 f9 74 22 4d 85 ff 74 1d <4c> 8b
79 08 4c 89 e2 48 89 de 48 89 cf ff 11 4d 85 f6 74 04 41
RIP [<ffffffff8150eef6>] notifier_call_chain+0x46/0x80
RSP <ffff88042868fb20>
CR2: ffffffffa01af838
---[ end trace 0100930068e73e6f ]---
BUG: unable to handle kernel paging request at fffffffffffffff8
IP: [<ffffffff810705b0>] kthread_data+0x10/0x20
PGD 1a0d067 PUD 1a0e067 PMD 0
Oops: 0000 [#2] SMP
Only i7core_edac and sb_edac have such issues because they have more
than one memory controller which means they have to register mce
decoder many times.
Signed-off-by: Chen Gong <gong.chen@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
[bwh: Backported to 3.2: drivers call atomic_notifier_chain_{,un}register()
directly]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
--- a/drivers/edac/i7core_edac.c
+++ b/drivers/edac/i7core_edac.c
@@ -1932,12 +1932,6 @@
if (mce->bank != 8)
return NOTIFY_DONE;
-#ifdef CONFIG_SMP
- /* Only handle if it is the right mc controller */
- if (mce->socketid != pvt->i7core_dev->socket)
- return NOTIFY_DONE;
-#endif
-
smp_rmb();
if ((pvt->mce_out + 1) % MCE_LOG_LEN == pvt->mce_in) {
smp_wmb();
@@ -2234,8 +2228,6 @@
if (pvt->enable_scrub)
disable_sdram_scrub_setting(mci);
- atomic_notifier_chain_unregister(&x86_mce_decoder_chain, &i7_mce_dec);
-
/* Disable EDAC polling */
i7core_pci_ctl_release(pvt);
@@ -2336,8 +2328,6 @@
/* DCLK for scrub rate setting */
pvt->dclk_freq = get_dclk_freq();
- atomic_notifier_chain_register(&x86_mce_decoder_chain, &i7_mce_dec);
-
return 0;
fail0:
@@ -2481,8 +2471,10 @@
pci_rc = pci_register_driver(&i7core_driver);
- if (pci_rc >= 0)
+ if (pci_rc >= 0) {
+ atomic_notifier_chain_register(&x86_mce_decoder_chain, &i7_mce_dec);
return 0;
+ }
i7core_printk(KERN_ERR, "Failed to register device with error %d.\n",
pci_rc);
@@ -2498,6 +2490,7 @@
{
debugf2("MC: " __FILE__ ": %s()\n", __func__);
pci_unregister_driver(&i7core_driver);
+ atomic_notifier_chain_unregister(&x86_mce_decoder_chain, &i7_mce_dec);
}
module_init(i7core_init);
--- a/drivers/edac/sb_edac.c
+++ b/drivers/edac/sb_edac.c
@@ -1661,9 +1661,6 @@
debugf0("MC: " __FILE__ ": %s(): mci = %p, dev = %p\n",
__func__, mci, &sbridge_dev->pdev[0]->dev);
- atomic_notifier_chain_unregister(&x86_mce_decoder_chain,
- &sbridge_mce_dec);
-
/* Remove MC sysfs nodes */
edac_mc_del_mc(mci->dev);
@@ -1731,8 +1728,6 @@
goto fail0;
}
- atomic_notifier_chain_register(&x86_mce_decoder_chain,
- &sbridge_mce_dec);
return 0;
fail0:
@@ -1861,8 +1856,10 @@
pci_rc = pci_register_driver(&sbridge_driver);
- if (pci_rc >= 0)
+ if (pci_rc >= 0) {
+ atomic_notifier_chain_register(&x86_mce_decoder_chain, &sbridge_mce_dec);
return 0;
+ }
sbridge_printk(KERN_ERR, "Failed to register device with error %d.\n",
pci_rc);
@@ -1878,6 +1875,7 @@
{
debugf2("MC: " __FILE__ ": %s()\n", __func__);
pci_unregister_driver(&sbridge_driver);
+ atomic_notifier_chain_unregister(&x86_mce_decoder_chain, &sbridge_mce_dec);
}
module_init(sbridge_init);
^ permalink raw reply [flat|nested] 78+ messages in thread* [ 04/48] hwrng: atmel-rng - fix data valid check
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (2 preceding siblings ...)
2012-07-01 17:20 ` [ 03/48] edac: avoid mce decoding crash after edac driver unloaded Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 05/48] staging: r8712u: Add new USB IDs Ben Hutchings
` (44 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Peter Korsgaard, George Pontis,
Nicolas Ferre, Herbert Xu
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Korsgaard <jacmet@sunsite.dk>
commit c475c06f4bb689d6ad87d7512e036d6dface3160 upstream.
Brown paper bag: Data valid is LSB of the ISR (status register), and NOT
of ODATA (current random data word)!
With this, rngtest is a lot happier. Before:
rngtest 3
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions. There is NO warr.
rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 3
rngtest: FIPS 140-2 failures: 997
rngtest: FIPS 140-2(2001-10-10) Monobit: 604
rngtest: FIPS 140-2(2001-10-10) Poker: 996
rngtest: FIPS 140-2(2001-10-10) Runs: 36
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 117
rngtest: input channel speed: (min=622.371; avg=23682.481; max=28224.350)Kibitss
rngtest: FIPS tests speed: (min=12.361; avg=12.718; max=12.861)Mibits/s
rngtest: Program run time: 2331696 microsecondsx
After:
rngtest 3
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions. There is NO warr.
rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 999
rngtest: FIPS 140-2 failures: 1
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 1
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=777.363; avg=43588.270; max=47870.711)Kibitss
rngtest: FIPS tests speed: (min=11.943; avg=12.716; max=12.844)Mibits/s
rngtest: Program run time: 1955282 microseconds
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Reported-by: George Pontis <GPontis@z9.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/char/hw_random/atmel-rng.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/hw_random/atmel-rng.c b/drivers/char/hw_random/atmel-rng.c
index 6289f0e..731c904 100644
--- a/drivers/char/hw_random/atmel-rng.c
+++ b/drivers/char/hw_random/atmel-rng.c
@@ -34,7 +34,7 @@ static int atmel_trng_read(struct hwrng *rng, void *buf, size_t max,
u32 *data = buf;
/* data ready? */
- if (readl(trng->base + TRNG_ODATA) & 1) {
+ if (readl(trng->base + TRNG_ISR) & 1) {
*data = readl(trng->base + TRNG_ODATA);
/*
ensure data ready is only set again AFTER the next data
^ permalink raw reply related [flat|nested] 78+ messages in thread* [ 05/48] staging: r8712u: Add new USB IDs
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (3 preceding siblings ...)
2012-07-01 17:20 ` [ 04/48] hwrng: atmel-rng - fix data valid check Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 06/48] hwmon: (applesmc) Limit key length in warning messages Ben Hutchings
` (43 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Lubomir Schmidt, Larry Finger, Greg Kroah-Hartman
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lubomir Schmidt <gentoo.lubomir@googlemail.com>
commit 3026b0e942c65c65c8fc80d391d004228b52b916 upstream.
There are two new devices for this driver.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/staging/rtl8712/usb_intf.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/rtl8712/usb_intf.c b/drivers/staging/rtl8712/usb_intf.c
index 9bd18e2..69f616c 100644
--- a/drivers/staging/rtl8712/usb_intf.c
+++ b/drivers/staging/rtl8712/usb_intf.c
@@ -102,6 +102,8 @@ static struct usb_device_id rtl871x_usb_id_tbl[] = {
/* - */
{USB_DEVICE(0x20F4, 0x646B)},
{USB_DEVICE(0x083A, 0xC512)},
+ {USB_DEVICE(0x25D4, 0x4CA1)},
+ {USB_DEVICE(0x25D4, 0x4CAB)},
/* RTL8191SU */
/* Realtek */
^ permalink raw reply related [flat|nested] 78+ messages in thread* [ 06/48] hwmon: (applesmc) Limit key length in warning messages
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (4 preceding siblings ...)
2012-07-01 17:20 ` [ 05/48] staging: r8712u: Add new USB IDs Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 07/48] mm: fix slab->page _count corruption when using slub Ben Hutchings
` (42 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: torvalds, akpm, alan, Henrik Rydberg, Guenter Roeck
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Henrik Rydberg <rydberg@euromail.se>
commit ac852edb47b15900886ba2564eeeb13b3b526e3e upstream.
Key lookups may call read_smc() with a fixed-length key string,
and if the lookup fails, trailing stack content may appear in the
kernel log. Fixed with this patch.
Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/hwmon/applesmc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
index f082e48..70d62f5 100644
--- a/drivers/hwmon/applesmc.c
+++ b/drivers/hwmon/applesmc.c
@@ -215,7 +215,7 @@ static int read_smc(u8 cmd, const char *key, u8 *buffer, u8 len)
int i;
if (send_command(cmd) || send_argument(key)) {
- pr_warn("%s: read arg fail\n", key);
+ pr_warn("%.4s: read arg fail\n", key);
return -EIO;
}
@@ -223,7 +223,7 @@ static int read_smc(u8 cmd, const char *key, u8 *buffer, u8 len)
for (i = 0; i < len; i++) {
if (__wait_status(0x05)) {
- pr_warn("%s: read data fail\n", key);
+ pr_warn("%.4s: read data fail\n", key);
return -EIO;
}
buffer[i] = inb(APPLESMC_DATA_PORT);
^ permalink raw reply related [flat|nested] 78+ messages in thread* [ 07/48] mm: fix slab->page _count corruption when using slub
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (5 preceding siblings ...)
2012-07-01 17:20 ` [ 06/48] hwmon: (applesmc) Limit key length in warning messages Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-02 23:46 ` Herton Ronaldo Krzesinski
2012-07-01 17:20 ` [ 08/48] mm: pmd_read_atomic: fix 32bit PAE pmd walk vs pmd_populate SMP race condition Ben Hutchings
` (41 subsequent siblings)
48 siblings, 1 reply; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Pravin B Shelar, Amey Bhide,
Christoph Lameter, Pekka Enberg, Andrea Arcangeli
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pravin B Shelar <pshelar@nicira.com>
commit abca7c4965845924f65d40e0aa1092bdd895e314 upstream.
On arches that do not support this_cpu_cmpxchg_double() slab_lock is used
to do atomic cmpxchg() on double word which contains page->_count. The
page count can be changed from get_page() or put_page() without taking
slab_lock. That corrupts page counter.
Fix it by moving page->_count out of cmpxchg_double data. So that slub
does no change it while updating slub meta-data in struct page.
[akpm@linux-foundation.org: use standard comment layout, tweak comment text]
Reported-by: Amey Bhide <abhide@nicira.com>
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Acked-by: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
include/linux/mm_types.h | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index dad95bd..704a626 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -57,8 +57,18 @@ struct page {
};
union {
+#if defined(CONFIG_HAVE_CMPXCHG_DOUBLE) && \
+ defined(CONFIG_HAVE_ALIGNED_STRUCT_PAGE)
/* Used for cmpxchg_double in slub */
unsigned long counters;
+#else
+ /*
+ * Keep _count separate from slub cmpxchg_double data.
+ * As the rest of the double word is protected by
+ * slab_lock but _count is not.
+ */
+ unsigned counters;
+#endif
struct {
^ permalink raw reply related [flat|nested] 78+ messages in thread* Re: [ 07/48] mm: fix slab->page _count corruption when using slub
2012-07-01 17:20 ` [ 07/48] mm: fix slab->page _count corruption when using slub Ben Hutchings
@ 2012-07-02 23:46 ` Herton Ronaldo Krzesinski
2012-07-02 23:56 ` Herton Ronaldo Krzesinski
2012-07-04 4:36 ` Ben Hutchings
0 siblings, 2 replies; 78+ messages in thread
From: Herton Ronaldo Krzesinski @ 2012-07-02 23:46 UTC (permalink / raw)
To: Ben Hutchings
Cc: linux-kernel, stable, torvalds, akpm, alan, Pravin B Shelar,
Amey Bhide, Christoph Lameter, Pekka Enberg, Andrea Arcangeli
[-- Attachment #1: Type: text/plain, Size: 2576 bytes --]
On Sun, Jul 01, 2012 at 06:20:13PM +0100, Ben Hutchings wrote:
> 3.2-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Pravin B Shelar <pshelar@nicira.com>
>
> commit abca7c4965845924f65d40e0aa1092bdd895e314 upstream.
>
> On arches that do not support this_cpu_cmpxchg_double() slab_lock is used
> to do atomic cmpxchg() on double word which contains page->_count. The
> page count can be changed from get_page() or put_page() without taking
> slab_lock. That corrupts page counter.
>
> Fix it by moving page->_count out of cmpxchg_double data. So that slub
> does no change it while updating slub meta-data in struct page.
Hi,
I got a frozen machine on boot with 3.2.22 proposed patches, bisect
pointed out to this commit (and reverting only this commit on top of
3.2.22 patches confirmed it). So far I was able to reproduce always.
Only happened with an x86_64 kernel, gzipped config attached. Using
earlyprintk=vga, I'm able to see the boot process is stuck just right
after "Memory: ...k available..." message (right before SLUB prints
its initialization message).
>
> [akpm@linux-foundation.org: use standard comment layout, tweak comment text]
> Reported-by: Amey Bhide <abhide@nicira.com>
> Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
> Acked-by: Christoph Lameter <cl@linux.com>
> Cc: Pekka Enberg <penberg@cs.helsinki.fi>
> Cc: Andrea Arcangeli <aarcange@redhat.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> ---
> include/linux/mm_types.h | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index dad95bd..704a626 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -57,8 +57,18 @@ struct page {
> };
>
> union {
> +#if defined(CONFIG_HAVE_CMPXCHG_DOUBLE) && \
> + defined(CONFIG_HAVE_ALIGNED_STRUCT_PAGE)
> /* Used for cmpxchg_double in slub */
> unsigned long counters;
> +#else
> + /*
> + * Keep _count separate from slub cmpxchg_double data.
> + * As the rest of the double word is protected by
> + * slab_lock but _count is not.
> + */
> + unsigned counters;
> +#endif
>
> struct {
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
[]'s
Herton
[-- Attachment #2: config-3.2.21-030221-generic.gz --]
[-- Type: application/octet-stream, Size: 35281 bytes --]
^ permalink raw reply [flat|nested] 78+ messages in thread* Re: [ 07/48] mm: fix slab->page _count corruption when using slub
2012-07-02 23:46 ` Herton Ronaldo Krzesinski
@ 2012-07-02 23:56 ` Herton Ronaldo Krzesinski
2012-07-03 1:17 ` Herton Ronaldo Krzesinski
2012-07-04 4:36 ` Ben Hutchings
1 sibling, 1 reply; 78+ messages in thread
From: Herton Ronaldo Krzesinski @ 2012-07-02 23:56 UTC (permalink / raw)
To: Ben Hutchings
Cc: linux-kernel, stable, torvalds, akpm, alan, Pravin B Shelar,
Amey Bhide, Christoph Lameter, Pekka Enberg, Andrea Arcangeli
On Mon, Jul 02, 2012 at 08:46:12PM -0300, Herton Ronaldo Krzesinski wrote:
> On Sun, Jul 01, 2012 at 06:20:13PM +0100, Ben Hutchings wrote:
> > 3.2-stable review patch. If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Pravin B Shelar <pshelar@nicira.com>
> >
> > commit abca7c4965845924f65d40e0aa1092bdd895e314 upstream.
> >
> > On arches that do not support this_cpu_cmpxchg_double() slab_lock is used
> > to do atomic cmpxchg() on double word which contains page->_count. The
> > page count can be changed from get_page() or put_page() without taking
> > slab_lock. That corrupts page counter.
> >
> > Fix it by moving page->_count out of cmpxchg_double data. So that slub
> > does no change it while updating slub meta-data in struct page.
>
> Hi,
>
> I got a frozen machine on boot with 3.2.22 proposed patches, bisect
> pointed out to this commit (and reverting only this commit on top of
> 3.2.22 patches confirmed it). So far I was able to reproduce always.
>
> Only happened with an x86_64 kernel, gzipped config attached. Using
> earlyprintk=vga, I'm able to see the boot process is stuck just right
> after "Memory: ...k available..." message (right before SLUB prints
> its initialization message).
So, 3.2 didn't have the CONFIG_HAVE_CMPXCHG_DOUBLE and
CONFIG_HAVE_ALIGNED_STRUCT_PAGE defines, it had instead CMPXCHG_DOUBLE
and HAVE_ALIGNED_STRUCT_PAGE is a new logic. So the patch is broken for
3.2 indeed.
>
> >
> > [akpm@linux-foundation.org: use standard comment layout, tweak comment text]
> > Reported-by: Amey Bhide <abhide@nicira.com>
> > Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
> > Acked-by: Christoph Lameter <cl@linux.com>
> > Cc: Pekka Enberg <penberg@cs.helsinki.fi>
> > Cc: Andrea Arcangeli <aarcange@redhat.com>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> > Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> > Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> > ---
> > include/linux/mm_types.h | 10 ++++++++++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> > index dad95bd..704a626 100644
> > --- a/include/linux/mm_types.h
> > +++ b/include/linux/mm_types.h
> > @@ -57,8 +57,18 @@ struct page {
> > };
> >
> > union {
> > +#if defined(CONFIG_HAVE_CMPXCHG_DOUBLE) && \
> > + defined(CONFIG_HAVE_ALIGNED_STRUCT_PAGE)
> > /* Used for cmpxchg_double in slub */
> > unsigned long counters;
> > +#else
> > + /*
> > + * Keep _count separate from slub cmpxchg_double data.
> > + * As the rest of the double word is protected by
> > + * slab_lock but _count is not.
> > + */
> > + unsigned counters;
> > +#endif
> >
> > struct {
> >
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe stable" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
> --
> []'s
> Herton
--
[]'s
Herton
^ permalink raw reply [flat|nested] 78+ messages in thread* Re: [ 07/48] mm: fix slab->page _count corruption when using slub
2012-07-02 23:56 ` Herton Ronaldo Krzesinski
@ 2012-07-03 1:17 ` Herton Ronaldo Krzesinski
2012-07-03 20:19 ` Pravin Shelar
0 siblings, 1 reply; 78+ messages in thread
From: Herton Ronaldo Krzesinski @ 2012-07-03 1:17 UTC (permalink / raw)
To: Ben Hutchings
Cc: linux-kernel, stable, torvalds, akpm, alan, Pravin B Shelar,
Amey Bhide, Christoph Lameter, Pekka Enberg, Andrea Arcangeli
On Mon, Jul 02, 2012 at 08:56:32PM -0300, Herton Ronaldo Krzesinski wrote:
> So, 3.2 didn't have the CONFIG_HAVE_CMPXCHG_DOUBLE and
> CONFIG_HAVE_ALIGNED_STRUCT_PAGE defines, it had instead CMPXCHG_DOUBLE
> and HAVE_ALIGNED_STRUCT_PAGE is a new logic. So the patch is broken for
> 3.2 indeed.
So here is a proposed backport for 3.2, I tested it etc., but please
someone review/ack it as well...
From: Pravin B Shelar <pshelar@nicira.com>
Subject: mm: fix slab->page _count corruption when using slub
commit abca7c4965845924f65d40e0aa1092bdd895e314 upstream.
On arches that do not support this_cpu_cmpxchg_double() slab_lock is used
to do atomic cmpxchg() on double word which contains page->_count. The
page count can be changed from get_page() or put_page() without taking
slab_lock. That corrupts page counter.
Fix it by moving page->_count out of cmpxchg_double data. So that slub
does no change it while updating slub meta-data in struct page.
[akpm@linux-foundation.org: use standard comment layout, tweak comment text]
Reported-by: Amey Bhide <abhide@nicira.com>
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Acked-by: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
[herton: backport to 3.2, use CONFIG_CMPXCHG_DOUBLE]
Signed-off-by: Herton R. Krzesinski <herton@canonical.com>
---
include/linux/mm_types.h | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 5b42f1b..2153639 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -56,8 +56,17 @@ struct page {
};
union {
+#ifdef CONFIG_CMPXCHG_DOUBLE
/* Used for cmpxchg_double in slub */
unsigned long counters;
+#else
+ /*
+ * Keep _count separate from slub cmpxchg_double data.
+ * As the rest of the double word is protected by
+ * slab_lock but _count is not.
+ */
+ unsigned counters;
+#endif
struct {
--
1.7.9.5
--
[]'s
Herton
^ permalink raw reply related [flat|nested] 78+ messages in thread* Re: [ 07/48] mm: fix slab->page _count corruption when using slub
2012-07-03 1:17 ` Herton Ronaldo Krzesinski
@ 2012-07-03 20:19 ` Pravin Shelar
0 siblings, 0 replies; 78+ messages in thread
From: Pravin Shelar @ 2012-07-03 20:19 UTC (permalink / raw)
To: Herton Ronaldo Krzesinski
Cc: Ben Hutchings, linux-kernel, stable, torvalds, akpm, alan,
Amey Bhide, Christoph Lameter, Pekka Enberg, Andrea Arcangeli
Applying just this patch does not solve whole problem. There is
another patch which needs to be backported. Discussion on that is not
concluded yet. so I think we can drop this patch for now.
ref : http://www.vacationhomexchg.com/lists/linux-mm/msg36054.html
Thanks,
Pravin.
On Mon, Jul 2, 2012 at 6:17 PM, Herton Ronaldo Krzesinski
<herton.krzesinski@canonical.com> wrote:
> On Mon, Jul 02, 2012 at 08:56:32PM -0300, Herton Ronaldo Krzesinski wrote:
>> So, 3.2 didn't have the CONFIG_HAVE_CMPXCHG_DOUBLE and
>> CONFIG_HAVE_ALIGNED_STRUCT_PAGE defines, it had instead CMPXCHG_DOUBLE
>> and HAVE_ALIGNED_STRUCT_PAGE is a new logic. So the patch is broken for
>> 3.2 indeed.
>
> So here is a proposed backport for 3.2, I tested it etc., but please
> someone review/ack it as well...
>
> From: Pravin B Shelar <pshelar@nicira.com>
> Subject: mm: fix slab->page _count corruption when using slub
>
> commit abca7c4965845924f65d40e0aa1092bdd895e314 upstream.
>
> On arches that do not support this_cpu_cmpxchg_double() slab_lock is used
> to do atomic cmpxchg() on double word which contains page->_count. The
> page count can be changed from get_page() or put_page() without taking
> slab_lock. That corrupts page counter.
>
> Fix it by moving page->_count out of cmpxchg_double data. So that slub
> does no change it while updating slub meta-data in struct page.
>
> [akpm@linux-foundation.org: use standard comment layout, tweak comment text]
> Reported-by: Amey Bhide <abhide@nicira.com>
> Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
> Acked-by: Christoph Lameter <cl@linux.com>
> Cc: Pekka Enberg <penberg@cs.helsinki.fi>
> Cc: Andrea Arcangeli <aarcange@redhat.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> [herton: backport to 3.2, use CONFIG_CMPXCHG_DOUBLE]
> Signed-off-by: Herton R. Krzesinski <herton@canonical.com>
> ---
> include/linux/mm_types.h | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 5b42f1b..2153639 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -56,8 +56,17 @@ struct page {
> };
>
> union {
> +#ifdef CONFIG_CMPXCHG_DOUBLE
> /* Used for cmpxchg_double in slub */
> unsigned long counters;
> +#else
> + /*
> + * Keep _count separate from slub cmpxchg_double data.
> + * As the rest of the double word is protected by
> + * slab_lock but _count is not.
> + */
> + unsigned counters;
> +#endif
>
> struct {
>
> --
> 1.7.9.5
>
>
> --
> []'s
> Herton
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [ 07/48] mm: fix slab->page _count corruption when using slub
2012-07-02 23:46 ` Herton Ronaldo Krzesinski
2012-07-02 23:56 ` Herton Ronaldo Krzesinski
@ 2012-07-04 4:36 ` Ben Hutchings
1 sibling, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-04 4:36 UTC (permalink / raw)
To: Herton Ronaldo Krzesinski, Pravin Shelar
Cc: linux-kernel, stable, torvalds, akpm, alan, Pravin B Shelar,
Amey Bhide, Christoph Lameter, Pekka Enberg, Andrea Arcangeli
[-- Attachment #1: Type: text/plain, Size: 1365 bytes --]
On Mon, 2012-07-02 at 20:46 -0300, Herton Ronaldo Krzesinski wrote:
> On Sun, Jul 01, 2012 at 06:20:13PM +0100, Ben Hutchings wrote:
> > 3.2-stable review patch. If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Pravin B Shelar <pshelar@nicira.com>
> >
> > commit abca7c4965845924f65d40e0aa1092bdd895e314 upstream.
> >
> > On arches that do not support this_cpu_cmpxchg_double() slab_lock is used
> > to do atomic cmpxchg() on double word which contains page->_count. The
> > page count can be changed from get_page() or put_page() without taking
> > slab_lock. That corrupts page counter.
> >
> > Fix it by moving page->_count out of cmpxchg_double data. So that slub
> > does no change it while updating slub meta-data in struct page.
>
> Hi,
>
> I got a frozen machine on boot with 3.2.22 proposed patches, bisect
> pointed out to this commit (and reverting only this commit on top of
> 3.2.22 patches confirmed it). So far I was able to reproduce always.
[...]
Sorry, I should remember to test with SLUB whenever there's a patch that
touches it! I'll drop this for now, given Pravin's feedback.
Please let me know when this is completely fixed in mainline and ready
to be cherry-picked/backported.
Ben.
--
Ben Hutchings
When in doubt, use brute force. - Ken Thompson
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply [flat|nested] 78+ messages in thread
* [ 08/48] mm: pmd_read_atomic: fix 32bit PAE pmd walk vs pmd_populate SMP race condition
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (6 preceding siblings ...)
2012-07-01 17:20 ` [ 07/48] mm: fix slab->page _count corruption when using slub Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 09/48] thp: avoid atomic64_read in pmd_read_atomic for 32bit PAE Ben Hutchings
` (40 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Andrea Arcangeli, Ulrich Obergfell,
Mel Gorman, Hugh Dickins, Larry Woodman, Petr Matousek,
Rik van Riel
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrea Arcangeli <aarcange@redhat.com>
commit 26c191788f18129af0eb32a358cdaea0c7479626 upstream.
When holding the mmap_sem for reading, pmd_offset_map_lock should only
run on a pmd_t that has been read atomically from the pmdp pointer,
otherwise we may read only half of it leading to this crash.
PID: 11679 TASK: f06e8000 CPU: 3 COMMAND: "do_race_2_panic"
#0 [f06a9dd8] crash_kexec at c049b5ec
#1 [f06a9e2c] oops_end at c083d1c2
#2 [f06a9e40] no_context at c0433ded
#3 [f06a9e64] bad_area_nosemaphore at c043401a
#4 [f06a9e6c] __do_page_fault at c0434493
#5 [f06a9eec] do_page_fault at c083eb45
#6 [f06a9f04] error_code (via page_fault) at c083c5d5
EAX: 01fb470c EBX: fff35000 ECX: 00000003 EDX: 00000100 EBP:
00000000
DS: 007b ESI: 9e201000 ES: 007b EDI: 01fb4700 GS: 00e0
CS: 0060 EIP: c083bc14 ERR: ffffffff EFLAGS: 00010246
#7 [f06a9f38] _spin_lock at c083bc14
#8 [f06a9f44] sys_mincore at c0507b7d
#9 [f06a9fb0] system_call at c083becd
start len
EAX: ffffffda EBX: 9e200000 ECX: 00001000 EDX: 6228537f
DS: 007b ESI: 00000000 ES: 007b EDI: 003d0f00
SS: 007b ESP: 62285354 EBP: 62285388 GS: 0033
CS: 0073 EIP: 00291416 ERR: 000000da EFLAGS: 00000286
This should be a longstanding bug affecting x86 32bit PAE without THP.
Only archs with 64bit large pmd_t and 32bit unsigned long should be
affected.
With THP enabled the barrier() in pmd_none_or_trans_huge_or_clear_bad()
would partly hide the bug when the pmd transition from none to stable,
by forcing a re-read of the *pmd in pmd_offset_map_lock, but when THP is
enabled a new set of problem arises by the fact could then transition
freely in any of the none, pmd_trans_huge or pmd_trans_stable states.
So making the barrier in pmd_none_or_trans_huge_or_clear_bad()
unconditional isn't good idea and it would be a flakey solution.
This should be fully fixed by introducing a pmd_read_atomic that reads
the pmd in order with THP disabled, or by reading the pmd atomically
with cmpxchg8b with THP enabled.
Luckily this new race condition only triggers in the places that must
already be covered by pmd_none_or_trans_huge_or_clear_bad() so the fix
is localized there but this bug is not related to THP.
NOTE: this can trigger on x86 32bit systems with PAE enabled with more
than 4G of ram, otherwise the high part of the pmd will never risk to be
truncated because it would be zero at all times, in turn so hiding the
SMP race.
This bug was discovered and fully debugged by Ulrich, quote:
----
[..]
pmd_none_or_trans_huge_or_clear_bad() loads the content of edx and
eax.
496 static inline int pmd_none_or_trans_huge_or_clear_bad(pmd_t
*pmd)
497 {
498 /* depend on compiler for an atomic pmd read */
499 pmd_t pmdval = *pmd;
// edi = pmd pointer
0xc0507a74 <sys_mincore+548>: mov 0x8(%esp),%edi
...
// edx = PTE page table high address
0xc0507a84 <sys_mincore+564>: mov 0x4(%edi),%edx
...
// eax = PTE page table low address
0xc0507a8e <sys_mincore+574>: mov (%edi),%eax
[..]
Please note that the PMD is not read atomically. These are two "mov"
instructions where the high order bits of the PMD entry are fetched
first. Hence, the above machine code is prone to the following race.
- The PMD entry {high|low} is 0x0000000000000000.
The "mov" at 0xc0507a84 loads 0x00000000 into edx.
- A page fault (on another CPU) sneaks in between the two "mov"
instructions and instantiates the PMD.
- The PMD entry {high|low} is now 0x00000003fda38067.
The "mov" at 0xc0507a8e loads 0xfda38067 into eax.
----
Reported-by: Ulrich Obergfell <uobergfe@redhat.com>
Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Hugh Dickins <hughd@google.com>
Cc: Larry Woodman <lwoodman@redhat.com>
Cc: Petr Matousek <pmatouse@redhat.com>
Cc: Rik van Riel <riel@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
arch/x86/include/asm/pgtable-3level.h | 50 +++++++++++++++++++++++++++++++++
include/asm-generic/pgtable.h | 22 +++++++++++++--
2 files changed, 70 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/pgtable-3level.h b/arch/x86/include/asm/pgtable-3level.h
index effff47..43876f1 100644
--- a/arch/x86/include/asm/pgtable-3level.h
+++ b/arch/x86/include/asm/pgtable-3level.h
@@ -31,6 +31,56 @@ static inline void native_set_pte(pte_t *ptep, pte_t pte)
ptep->pte_low = pte.pte_low;
}
+#define pmd_read_atomic pmd_read_atomic
+/*
+ * pte_offset_map_lock on 32bit PAE kernels was reading the pmd_t with
+ * a "*pmdp" dereference done by gcc. Problem is, in certain places
+ * where pte_offset_map_lock is called, concurrent page faults are
+ * allowed, if the mmap_sem is hold for reading. An example is mincore
+ * vs page faults vs MADV_DONTNEED. On the page fault side
+ * pmd_populate rightfully does a set_64bit, but if we're reading the
+ * pmd_t with a "*pmdp" on the mincore side, a SMP race can happen
+ * because gcc will not read the 64bit of the pmd atomically. To fix
+ * this all places running pmd_offset_map_lock() while holding the
+ * mmap_sem in read mode, shall read the pmdp pointer using this
+ * function to know if the pmd is null nor not, and in turn to know if
+ * they can run pmd_offset_map_lock or pmd_trans_huge or other pmd
+ * operations.
+ *
+ * Without THP if the mmap_sem is hold for reading, the
+ * pmd can only transition from null to not null while pmd_read_atomic runs.
+ * So there's no need of literally reading it atomically.
+ *
+ * With THP if the mmap_sem is hold for reading, the pmd can become
+ * THP or null or point to a pte (and in turn become "stable") at any
+ * time under pmd_read_atomic, so it's mandatory to read it atomically
+ * with cmpxchg8b.
+ */
+#ifndef CONFIG_TRANSPARENT_HUGEPAGE
+static inline pmd_t pmd_read_atomic(pmd_t *pmdp)
+{
+ pmdval_t ret;
+ u32 *tmp = (u32 *)pmdp;
+
+ ret = (pmdval_t) (*tmp);
+ if (ret) {
+ /*
+ * If the low part is null, we must not read the high part
+ * or we can end up with a partial pmd.
+ */
+ smp_rmb();
+ ret |= ((pmdval_t)*(tmp + 1)) << 32;
+ }
+
+ return (pmd_t) { ret };
+}
+#else /* CONFIG_TRANSPARENT_HUGEPAGE */
+static inline pmd_t pmd_read_atomic(pmd_t *pmdp)
+{
+ return (pmd_t) { atomic64_read((atomic64_t *)pmdp) };
+}
+#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
+
static inline void native_set_pte_atomic(pte_t *ptep, pte_t pte)
{
set_64bit((unsigned long long *)(ptep), native_pte_val(pte));
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index e2768f1..6f2b45a 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -445,6 +445,18 @@ static inline int pmd_write(pmd_t pmd)
#endif /* __HAVE_ARCH_PMD_WRITE */
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
+#ifndef pmd_read_atomic
+static inline pmd_t pmd_read_atomic(pmd_t *pmdp)
+{
+ /*
+ * Depend on compiler for an atomic pmd read. NOTE: this is
+ * only going to work, if the pmdval_t isn't larger than
+ * an unsigned long.
+ */
+ return *pmdp;
+}
+#endif
+
/*
* This function is meant to be used by sites walking pagetables with
* the mmap_sem hold in read mode to protect against MADV_DONTNEED and
@@ -458,11 +470,17 @@ static inline int pmd_write(pmd_t pmd)
* undefined so behaving like if the pmd was none is safe (because it
* can return none anyway). The compiler level barrier() is critically
* important to compute the two checks atomically on the same pmdval.
+ *
+ * For 32bit kernels with a 64bit large pmd_t this automatically takes
+ * care of reading the pmd atomically to avoid SMP race conditions
+ * against pmd_populate() when the mmap_sem is hold for reading by the
+ * caller (a special atomic read not done by "gcc" as in the generic
+ * version above, is also needed when THP is disabled because the page
+ * fault can populate the pmd from under us).
*/
static inline int pmd_none_or_trans_huge_or_clear_bad(pmd_t *pmd)
{
- /* depend on compiler for an atomic pmd read */
- pmd_t pmdval = *pmd;
+ pmd_t pmdval = pmd_read_atomic(pmd);
/*
* The barrier will stabilize the pmdval in a register or on
* the stack so that it will stop changing under the code.
^ permalink raw reply related [flat|nested] 78+ messages in thread* [ 09/48] thp: avoid atomic64_read in pmd_read_atomic for 32bit PAE
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (7 preceding siblings ...)
2012-07-01 17:20 ` [ 08/48] mm: pmd_read_atomic: fix 32bit PAE pmd walk vs pmd_populate SMP race condition Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 10/48] nilfs2: ensure proper cache clearing for gc-inodes Ben Hutchings
` (39 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Andrea Arcangeli, Jonathan Nieder,
Ulrich Obergfell, Mel Gorman, Hugh Dickins, Larry Woodman,
Petr Matousek, Rik van Riel, Jan Beulich, KOSAKI Motohiro,
Andrew Jones
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrea Arcangeli <aarcange@redhat.com>
commit e4eed03fd06578571c01d4f1478c874bb432c815 upstream.
In the x86 32bit PAE CONFIG_TRANSPARENT_HUGEPAGE=y case while holding the
mmap_sem for reading, cmpxchg8b cannot be used to read pmd contents under
Xen.
So instead of dealing only with "consistent" pmdvals in
pmd_none_or_trans_huge_or_clear_bad() (which would be conceptually
simpler) we let pmd_none_or_trans_huge_or_clear_bad() deal with pmdvals
where the low 32bit and high 32bit could be inconsistent (to avoid having
to use cmpxchg8b).
The only guarantee we get from pmd_read_atomic is that if the low part of
the pmd was found null, the high part will be null too (so the pmd will be
considered unstable). And if the low part of the pmd is found "stable"
later, then it means the whole pmd was read atomically (because after a
pmd is stable, neither MADV_DONTNEED nor page faults can alter it anymore,
and we read the high part after the low part).
In the 32bit PAE x86 case, it is enough to read the low part of the pmdval
atomically to declare the pmd as "stable" and that's true for THP and no
THP, furthermore in the THP case we also have a barrier() that will
prevent any inconsistent pmdvals to be cached by a later re-read of the
*pmd.
Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
Cc: Jonathan Nieder <jrnieder@gmail.com>
Cc: Ulrich Obergfell <uobergfe@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Hugh Dickins <hughd@google.com>
Cc: Larry Woodman <lwoodman@redhat.com>
Cc: Petr Matousek <pmatouse@redhat.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
Tested-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
arch/x86/include/asm/pgtable-3level.h | 30 +++++++++++++++++-------------
include/asm-generic/pgtable.h | 10 ++++++++++
2 files changed, 27 insertions(+), 13 deletions(-)
diff --git a/arch/x86/include/asm/pgtable-3level.h b/arch/x86/include/asm/pgtable-3level.h
index 43876f1..cb00ccc 100644
--- a/arch/x86/include/asm/pgtable-3level.h
+++ b/arch/x86/include/asm/pgtable-3level.h
@@ -47,16 +47,26 @@ static inline void native_set_pte(pte_t *ptep, pte_t pte)
* they can run pmd_offset_map_lock or pmd_trans_huge or other pmd
* operations.
*
- * Without THP if the mmap_sem is hold for reading, the
- * pmd can only transition from null to not null while pmd_read_atomic runs.
- * So there's no need of literally reading it atomically.
+ * Without THP if the mmap_sem is hold for reading, the pmd can only
+ * transition from null to not null while pmd_read_atomic runs. So
+ * we can always return atomic pmd values with this function.
*
* With THP if the mmap_sem is hold for reading, the pmd can become
- * THP or null or point to a pte (and in turn become "stable") at any
- * time under pmd_read_atomic, so it's mandatory to read it atomically
- * with cmpxchg8b.
+ * trans_huge or none or point to a pte (and in turn become "stable")
+ * at any time under pmd_read_atomic. We could read it really
+ * atomically here with a atomic64_read for the THP enabled case (and
+ * it would be a whole lot simpler), but to avoid using cmpxchg8b we
+ * only return an atomic pmdval if the low part of the pmdval is later
+ * found stable (i.e. pointing to a pte). And we're returning a none
+ * pmdval if the low part of the pmd is none. In some cases the high
+ * and low part of the pmdval returned may not be consistent if THP is
+ * enabled (the low part may point to previously mapped hugepage,
+ * while the high part may point to a more recently mapped hugepage),
+ * but pmd_none_or_trans_huge_or_clear_bad() only needs the low part
+ * of the pmd to be read atomically to decide if the pmd is unstable
+ * or not, with the only exception of when the low part of the pmd is
+ * zero in which case we return a none pmd.
*/
-#ifndef CONFIG_TRANSPARENT_HUGEPAGE
static inline pmd_t pmd_read_atomic(pmd_t *pmdp)
{
pmdval_t ret;
@@ -74,12 +84,6 @@ static inline pmd_t pmd_read_atomic(pmd_t *pmdp)
return (pmd_t) { ret };
}
-#else /* CONFIG_TRANSPARENT_HUGEPAGE */
-static inline pmd_t pmd_read_atomic(pmd_t *pmdp)
-{
- return (pmd_t) { atomic64_read((atomic64_t *)pmdp) };
-}
-#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
static inline void native_set_pte_atomic(pte_t *ptep, pte_t pte)
{
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index 6f2b45a..ff4947b 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -484,6 +484,16 @@ static inline int pmd_none_or_trans_huge_or_clear_bad(pmd_t *pmd)
/*
* The barrier will stabilize the pmdval in a register or on
* the stack so that it will stop changing under the code.
+ *
+ * When CONFIG_TRANSPARENT_HUGEPAGE=y on x86 32bit PAE,
+ * pmd_read_atomic is allowed to return a not atomic pmdval
+ * (for example pointing to an hugepage that has never been
+ * mapped in the pmd). The below checks will only care about
+ * the low part of the pmd with 32bit PAE x86 anyway, with the
+ * exception of pmd_none(). So the important thing is that if
+ * the low part of the pmd is found null, the high part will
+ * be also null or the pmd_none() check below would be
+ * confused.
*/
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
barrier();
^ permalink raw reply related [flat|nested] 78+ messages in thread* [ 10/48] nilfs2: ensure proper cache clearing for gc-inodes
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (8 preceding siblings ...)
2012-07-01 17:20 ` [ 09/48] thp: avoid atomic64_read in pmd_read_atomic for 32bit PAE Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 11/48] mm: correctly synchronize rss-counters at exit/exec Ben Hutchings
` (38 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: torvalds, akpm, alan, Ryusuke Konishi
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
commit fbb24a3a915f105016f1c828476be11aceac8504 upstream.
A gc-inode is a pseudo inode used to buffer the blocks to be moved by
garbage collection.
Block caches of gc-inodes must be cleared every time a garbage collection
function (nilfs_clean_segments) completes. Otherwise, stale blocks
buffered in the caches may be wrongly reused in successive calls of the GC
function.
For user files, this is not a problem because their gc-inodes are
distinguished by a checkpoint number as well as an inode number. They
never buffer different blocks if either an inode number, a checkpoint
number, or a block offset differs.
However, gc-inodes of sufile, cpfile and DAT file can store different data
for the same block offset. Thus, the nilfs_clean_segments function can
move incorrect block for these meta-data files if an old block is cached.
I found this is really causing meta-data corruption in nilfs.
This fixes the issue by ensuring cache clear of gc-inodes and resolves
reported GC problems including checkpoint file corruption, b-tree
corruption, and the following warning during GC.
nilfs_palloc_freev: entry number 307234 already freed.
...
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
Tested-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
fs/nilfs2/gcinode.c | 2 ++
fs/nilfs2/segment.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/fs/nilfs2/gcinode.c b/fs/nilfs2/gcinode.c
index 08a07a2..57ceaf3 100644
--- a/fs/nilfs2/gcinode.c
+++ b/fs/nilfs2/gcinode.c
@@ -191,6 +191,8 @@ void nilfs_remove_all_gcinodes(struct the_nilfs *nilfs)
while (!list_empty(head)) {
ii = list_first_entry(head, struct nilfs_inode_info, i_dirty);
list_del_init(&ii->i_dirty);
+ truncate_inode_pages(&ii->vfs_inode.i_data, 0);
+ nilfs_btnode_cache_clear(&ii->i_btnode_cache);
iput(&ii->vfs_inode);
}
}
diff --git a/fs/nilfs2/segment.c b/fs/nilfs2/segment.c
index 0e72ad6..88e11fb 100644
--- a/fs/nilfs2/segment.c
+++ b/fs/nilfs2/segment.c
@@ -2309,6 +2309,8 @@ nilfs_remove_written_gcinodes(struct the_nilfs *nilfs, struct list_head *head)
if (!test_bit(NILFS_I_UPDATED, &ii->i_state))
continue;
list_del_init(&ii->i_dirty);
+ truncate_inode_pages(&ii->vfs_inode.i_data, 0);
+ nilfs_btnode_cache_clear(&ii->i_btnode_cache);
iput(&ii->vfs_inode);
}
}
^ permalink raw reply related [flat|nested] 78+ messages in thread* [ 11/48] mm: correctly synchronize rss-counters at exit/exec
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (9 preceding siblings ...)
2012-07-01 17:20 ` [ 10/48] nilfs2: ensure proper cache clearing for gc-inodes Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 19:02 ` Hugh Dickins
2012-07-01 17:20 ` [ 12/48] drm/i915: Finish any pending operations on the framebuffer before disabling Ben Hutchings
` (37 subsequent siblings)
48 siblings, 1 reply; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Konstantin Khlebnikov, Markus Trippelsdorf,
Oleg Nesterov, KAMEZAWA Hiroyuki, Hugh Dickins
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Konstantin Khlebnikov <khlebnikov@openvz.org>
commit 4fe7efdbdfb1c7e7a7f31decfd831c0f31d37091 upstream.
do_exit() and exec_mmap() call sync_mm_rss() before mm_release() does
put_user(clear_child_tid) which can update task->rss_stat and thus make
mm->rss_stat inconsistent. This triggers the "BUG:" printk in check_mm().
Let's fix this bug in the safest way, and optimize/cleanup this later.
Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Hugh Dickins <hughd@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[bwh: Backported to 3.2: sync_mm_rss() still takes a struct task_struct *]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -820,10 +820,10 @@
/* Notify parent that we're no longer interested in the old VM */
tsk = current;
old_mm = current->mm;
- sync_mm_rss(tsk, old_mm);
mm_release(tsk, old_mm);
if (old_mm) {
+ sync_mm_rss(tsk, old_mm);
/*
* Make sure that if there is a core dump in progress
* for the old mm, we get out and die instead of going
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -641,6 +641,7 @@
mm_release(tsk, mm);
if (!mm)
return;
+ sync_mm_rss(tsk, mm);
/*
* Serialize with any possible pending coredump.
* We must hold mmap_sem around checking core_state
^ permalink raw reply [flat|nested] 78+ messages in thread* Re: [ 11/48] mm: correctly synchronize rss-counters at exit/exec
2012-07-01 17:20 ` [ 11/48] mm: correctly synchronize rss-counters at exit/exec Ben Hutchings
@ 2012-07-01 19:02 ` Hugh Dickins
2012-07-02 2:01 ` Ben Hutchings
0 siblings, 1 reply; 78+ messages in thread
From: Hugh Dickins @ 2012-07-01 19:02 UTC (permalink / raw)
To: Ben Hutchings
Cc: linux-kernel, stable, torvalds, akpm, alan,
Konstantin Khlebnikov, Markus Trippelsdorf, Oleg Nesterov,
KAMEZAWA Hiroyuki
On Sun, 1 Jul 2012, Ben Hutchings wrote:
> 3.2-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Konstantin Khlebnikov <khlebnikov@openvz.org>
>
> commit 4fe7efdbdfb1c7e7a7f31decfd831c0f31d37091 upstream.
>
> do_exit() and exec_mmap() call sync_mm_rss() before mm_release() does
> put_user(clear_child_tid) which can update task->rss_stat and thus make
> mm->rss_stat inconsistent. This triggers the "BUG:" printk in check_mm().
>
> Let's fix this bug in the safest way, and optimize/cleanup this later.
>
> Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
> Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
> Cc: Oleg Nesterov <oleg@redhat.com>
> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> Cc: Hugh Dickins <hughd@google.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> [bwh: Backported to 3.2: sync_mm_rss() still takes a struct task_struct *]
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
If you or Konstantin or Oleg have done full diligence on this,
to ensure that it is really applicable to 3.2 (not just that
the patch applies without rejects), fair enough.
But I'd be cautious about it: it went through enough alternatives
and revisions that I wouldn't call it trivial; it's easy for me to
imagine that some of the affected paths were actually slightly different
in 3.2 days than they were in 3.4 days; and the disturbing warning that
these mods silence ("BUG: Bad rss-counter state ") did not exist before
3.4 - unless you've ported that too?
That's not to assert that we had no rss problem at all before 3.4,
but we've not heard of any trouble from it. Caution tells me that
this patch might cause more trouble than it's worth.
Hugh
> ---
> --- a/fs/exec.c
> +++ b/fs/exec.c
> @@ -820,10 +820,10 @@
> /* Notify parent that we're no longer interested in the old VM */
> tsk = current;
> old_mm = current->mm;
> - sync_mm_rss(tsk, old_mm);
> mm_release(tsk, old_mm);
>
> if (old_mm) {
> + sync_mm_rss(tsk, old_mm);
> /*
> * Make sure that if there is a core dump in progress
> * for the old mm, we get out and die instead of going
> --- a/kernel/exit.c
> +++ b/kernel/exit.c
> @@ -641,6 +641,7 @@
> mm_release(tsk, mm);
> if (!mm)
> return;
> + sync_mm_rss(tsk, mm);
> /*
> * Serialize with any possible pending coredump.
> * We must hold mmap_sem around checking core_state
>
>
>
^ permalink raw reply [flat|nested] 78+ messages in thread* Re: [ 11/48] mm: correctly synchronize rss-counters at exit/exec
2012-07-01 19:02 ` Hugh Dickins
@ 2012-07-02 2:01 ` Ben Hutchings
2012-07-02 16:46 ` Oleg Nesterov
0 siblings, 1 reply; 78+ messages in thread
From: Ben Hutchings @ 2012-07-02 2:01 UTC (permalink / raw)
To: Hugh Dickins
Cc: linux-kernel, stable, torvalds, akpm, alan,
Konstantin Khlebnikov, Markus Trippelsdorf, Oleg Nesterov,
KAMEZAWA Hiroyuki
[-- Attachment #1: Type: text/plain, Size: 2200 bytes --]
On Sun, 2012-07-01 at 12:02 -0700, Hugh Dickins wrote:
> On Sun, 1 Jul 2012, Ben Hutchings wrote:
>
> > 3.2-stable review patch. If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Konstantin Khlebnikov <khlebnikov@openvz.org>
> >
> > commit 4fe7efdbdfb1c7e7a7f31decfd831c0f31d37091 upstream.
> >
> > do_exit() and exec_mmap() call sync_mm_rss() before mm_release() does
> > put_user(clear_child_tid) which can update task->rss_stat and thus make
> > mm->rss_stat inconsistent. This triggers the "BUG:" printk in check_mm().
> >
> > Let's fix this bug in the safest way, and optimize/cleanup this later.
> >
> > Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
> > Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
> > Cc: Oleg Nesterov <oleg@redhat.com>
> > Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> > Cc: Hugh Dickins <hughd@google.com>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> > Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> > [bwh: Backported to 3.2: sync_mm_rss() still takes a struct task_struct *]
> > Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
>
> If you or Konstantin or Oleg have done full diligence on this,
> to ensure that it is really applicable to 3.2 (not just that
> the patch applies without rejects), fair enough.
I can't claim that, no.
> But I'd be cautious about it: it went through enough alternatives
> and revisions that I wouldn't call it trivial; it's easy for me to
> imagine that some of the affected paths were actually slightly different
> in 3.2 days than they were in 3.4 days; and the disturbing warning that
> these mods silence ("BUG: Bad rss-counter state ") did not exist before
> 3.4 - unless you've ported that too?
No.
> That's not to assert that we had no rss problem at all before 3.4,
> but we've not heard of any trouble from it. Caution tells me that
> this patch might cause more trouble than it's worth.
Then I'll assume this should be dropped unless Konstantin or Oleg speaks
up for it.
Ben.
--
Ben Hutchings
When in doubt, use brute force. - Ken Thompson
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply [flat|nested] 78+ messages in thread* Re: [ 11/48] mm: correctly synchronize rss-counters at exit/exec
2012-07-02 2:01 ` Ben Hutchings
@ 2012-07-02 16:46 ` Oleg Nesterov
2012-07-04 4:31 ` Ben Hutchings
0 siblings, 1 reply; 78+ messages in thread
From: Oleg Nesterov @ 2012-07-02 16:46 UTC (permalink / raw)
To: Ben Hutchings
Cc: Hugh Dickins, linux-kernel, stable, torvalds, akpm, alan,
Konstantin Khlebnikov, Markus Trippelsdorf, KAMEZAWA Hiroyuki
On 07/02, Ben Hutchings wrote:
>
> Then I'll assume this should be dropped unless Konstantin or Oleg speaks
> up for it.
Just in case, I agree with Hugh.
The patch should shut up check_mm() which doesn't exist in 3.2
Oleg.
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [ 11/48] mm: correctly synchronize rss-counters at exit/exec
2012-07-02 16:46 ` Oleg Nesterov
@ 2012-07-04 4:31 ` Ben Hutchings
0 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-04 4:31 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Hugh Dickins, linux-kernel, stable, torvalds, akpm, alan,
Konstantin Khlebnikov, Markus Trippelsdorf, KAMEZAWA Hiroyuki
[-- Attachment #1: Type: text/plain, Size: 408 bytes --]
On Mon, 2012-07-02 at 18:46 +0200, Oleg Nesterov wrote:
> On 07/02, Ben Hutchings wrote:
> >
> > Then I'll assume this should be dropped unless Konstantin or Oleg speaks
> > up for it.
>
> Just in case, I agree with Hugh.
>
> The patch should shut up check_mm() which doesn't exist in 3.2
Thanks; I've dropped this.
Ben.
--
Ben Hutchings
When in doubt, use brute force. - Ken Thompson
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply [flat|nested] 78+ messages in thread
* [ 12/48] drm/i915: Finish any pending operations on the framebuffer before disabling
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (10 preceding siblings ...)
2012-07-01 17:20 ` [ 11/48] mm: correctly synchronize rss-counters at exit/exec Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 13/48] drm/i915: Remove use of the autoreported ringbuffer HEAD position Ben Hutchings
` (36 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Chris Wilson, Francis Leblanc,
Eugeni Dodonov, Daniel Vetter, Timo Aaltonen
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chris Wilson <chris@chris-wilson.co.uk>
Similar to the case where we are changing from one framebuffer to
another, we need to be sure that there are no pending WAIT_FOR_EVENTs on
the pipe for the current framebuffer before switching. If we disable the
pipe, and then try to execute a WAIT_FOR_EVENT it will block
indefinitely and cause a GPU hang.
We attempted to fix this in commit 85345517fe6d4de27b0d6ca19fef9d28ac947c4a
(drm/i915: Retire any pending operations on the old scanout when switching)
for the case of mode switching, but this leaves the condition where we
are switching off the pipe vulnerable.
There still remains the race condition were a display may be unplugged,
switched off by the core, a uevent sent to notify the DDX and the DDX
may issue a WAIT_FOR_EVENT before it processes the uevent. This window
does not exist if the pipe is only switched off in response to the
uevent. Time to make sure that is so...
Reported-by: Francis Leblanc <Francis.Leblanc-Lebeau@verint.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36515
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45413
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
[danvet: fixup spelling in comment, noticed by Eugeni.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit 14667a4bde4361b7ac420d68a2e9e9b9b2df5231)
Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/gpu/drm/i915/intel_display.c | 65 ++++++++++++++++++++++++----------
1 file changed, 46 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 7f90cbd..8580d82 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2187,6 +2187,33 @@ intel_pipe_set_base_atomic(struct drm_crtc *crtc, struct drm_framebuffer *fb,
}
static int
+intel_finish_fb(struct drm_framebuffer *old_fb)
+{
+ struct drm_i915_gem_object *obj = to_intel_framebuffer(old_fb)->obj;
+ struct drm_i915_private *dev_priv = obj->base.dev->dev_private;
+ bool was_interruptible = dev_priv->mm.interruptible;
+ int ret;
+
+ wait_event(dev_priv->pending_flip_queue,
+ atomic_read(&dev_priv->mm.wedged) ||
+ atomic_read(&obj->pending_flip) == 0);
+
+ /* Big Hammer, we also need to ensure that any pending
+ * MI_WAIT_FOR_EVENT inside a user batch buffer on the
+ * current scanout is retired before unpinning the old
+ * framebuffer.
+ *
+ * This should only fail upon a hung GPU, in which case we
+ * can safely continue.
+ */
+ dev_priv->mm.interruptible = false;
+ ret = i915_gem_object_finish_gpu(obj);
+ dev_priv->mm.interruptible = was_interruptible;
+
+ return ret;
+}
+
+static int
intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
struct drm_framebuffer *old_fb)
{
@@ -2224,25 +2251,8 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
return ret;
}
- if (old_fb) {
- struct drm_i915_private *dev_priv = dev->dev_private;
- struct drm_i915_gem_object *obj = to_intel_framebuffer(old_fb)->obj;
-
- wait_event(dev_priv->pending_flip_queue,
- atomic_read(&dev_priv->mm.wedged) ||
- atomic_read(&obj->pending_flip) == 0);
-
- /* Big Hammer, we also need to ensure that any pending
- * MI_WAIT_FOR_EVENT inside a user batch buffer on the
- * current scanout is retired before unpinning the old
- * framebuffer.
- *
- * This should only fail upon a hung GPU, in which case we
- * can safely continue.
- */
- ret = i915_gem_object_finish_gpu(obj);
- (void) ret;
- }
+ if (old_fb)
+ intel_finish_fb(old_fb);
ret = intel_pipe_set_base_atomic(crtc, crtc->fb, x, y,
LEAVE_ATOMIC_MODE_SET);
@@ -3312,6 +3322,23 @@ static void intel_crtc_disable(struct drm_crtc *crtc)
struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
struct drm_device *dev = crtc->dev;
+ /* Flush any pending WAITs before we disable the pipe. Note that
+ * we need to drop the struct_mutex in order to acquire it again
+ * during the lowlevel dpms routines around a couple of the
+ * operations. It does not look trivial nor desirable to move
+ * that locking higher. So instead we leave a window for the
+ * submission of further commands on the fb before we can actually
+ * disable it. This race with userspace exists anyway, and we can
+ * only rely on the pipe being disabled by userspace after it
+ * receives the hotplug notification and has flushed any pending
+ * batches.
+ */
+ if (crtc->fb) {
+ mutex_lock(&dev->struct_mutex);
+ intel_finish_fb(crtc->fb);
+ mutex_unlock(&dev->struct_mutex);
+ }
+
crtc_funcs->dpms(crtc, DRM_MODE_DPMS_OFF);
if (crtc->fb) {
^ permalink raw reply related [flat|nested] 78+ messages in thread* [ 13/48] drm/i915: Remove use of the autoreported ringbuffer HEAD position
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (11 preceding siblings ...)
2012-07-01 17:20 ` [ 12/48] drm/i915: Finish any pending operations on the framebuffer before disabling Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 14/48] e1000e: Disable ASPM L1 on 82574 Ben Hutchings
` (35 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Chris Wilson, Daniel Vetter, Eric Anholt,
Jesse Barnes, Timo Aaltonen
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chris Wilson <chris@chris-wilson.co.uk>
This is a revert of 6aa56062eaba67adfb247cded244fd877329588d.
This was originally introduced to workaround reads of the ringbuffer
registers returning 0 on SandyBridge causing hangs due to ringbuffer
overflow. The root cause here was reads through the GT powerwell require
the forcewake dance, something we only learnt of later. Now it appears
that reading the reported head position from the HWS is returning
garbage, leading once again to hangs.
For example, on q35 the autoreported head reports:
[ 217.975608] head now 00010000, actual 00010000
[ 436.725613] head now 00200000, actual 00200000
[ 462.956033] head now 00210000, actual 00210010
[ 485.501409] head now 00400000, actual 00400020
[ 508.064280] head now 00410000, actual 00410000
[ 530.576078] head now 00600000, actual 00600020
[ 553.273489] head now 00610000, actual 00610018
which appears reasonably sane. In contrast, if we look at snb:
[ 141.970680] head now 00e10000, actual 00008238
[ 141.974062] head now 02734000, actual 000083c8
[ 141.974425] head now 00e10000, actual 00008488
[ 141.980374] head now 032b5000, actual 000088b8
[ 141.980885] head now 03271000, actual 00008950
[ 142.040628] head now 02101000, actual 00008b40
[ 142.180173] head now 02734000, actual 00009050
[ 142.181090] head now 00000000, actual 00000ae0
[ 142.183737] head now 02734000, actual 00009050
In addition, the automatic reporting of the head position is scheduled
to be defeatured in the future. It has no more utility, remove it.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45492
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
(cherry picked from commit 5d031e5b633d910f35e6e0abce94d9d842390006)
Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 14 +-------------
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 62f9ac5..5d369b1 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -301,7 +301,7 @@ static int init_ring_common(struct intel_ring_buffer *ring)
I915_WRITE_CTL(ring,
((ring->size - PAGE_SIZE) & RING_NR_PAGES)
- | RING_REPORT_64K | RING_VALID);
+ | RING_VALID);
/* If the head is still not zero, the ring is dead */
if ((I915_READ_CTL(ring) & RING_VALID) == 0 ||
@@ -1143,18 +1143,6 @@ int intel_wait_ring_buffer(struct intel_ring_buffer *ring, int n)
struct drm_device *dev = ring->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
unsigned long end;
- u32 head;
-
- /* If the reported head position has wrapped or hasn't advanced,
- * fallback to the slow and accurate path.
- */
- head = intel_read_status_page(ring, 4);
- if (head > ring->head) {
- ring->head = head;
- ring->space = ring_space(ring);
- if (ring->space >= n)
- return 0;
- }
trace_i915_ring_wait_begin(ring);
end = jiffies + 3 * HZ;
^ permalink raw reply related [flat|nested] 78+ messages in thread* [ 14/48] e1000e: Disable ASPM L1 on 82574
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (12 preceding siblings ...)
2012-07-01 17:20 ` [ 13/48] drm/i915: Remove use of the autoreported ringbuffer HEAD position Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 15/48] e1000e: Remove special case for 82573/82574 ASPM L1 disablement Ben Hutchings
` (34 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Chris Boot, Wyborny, Carolyn, Nix,
Jeff Pieper, Jeff Kirsher
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chris Boot <bootc@bootc.net>
commit id d4a4206ebbaf48b55803a7eb34e330530d83a889
ASPM on the 82574 causes trouble. Currently the driver disables L0s for
this NIC but only disables L1 if the MTU is >1500. This patch simply
causes L1 to be disabled regardless of the MTU setting.
Signed-off-by: Chris Boot <bootc@bootc.net>
Cc: "Wyborny, Carolyn" <carolyn.wyborny@intel.com>
Cc: Nix <nix@esperi.org.uk>
Link: https://lkml.org/lkml/2012/3/19/362
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
[Jeff Kirsher: Backport to 3.2-3.4 kernels]
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/net/ethernet/intel/e1000e/82571.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/e1000e/82571.c b/drivers/net/ethernet/intel/e1000e/82571.c
index a3e65fd..e556fc3 100644
--- a/drivers/net/ethernet/intel/e1000e/82571.c
+++ b/drivers/net/ethernet/intel/e1000e/82571.c
@@ -2080,8 +2080,9 @@ const struct e1000_info e1000_82574_info = {
| FLAG_HAS_SMART_POWER_DOWN
| FLAG_HAS_AMT
| FLAG_HAS_CTRLEXT_ON_LOAD,
- .flags2 = FLAG2_CHECK_PHY_HANG
+ .flags2 = FLAG2_CHECK_PHY_HANG
| FLAG2_DISABLE_ASPM_L0S
+ | FLAG2_DISABLE_ASPM_L1
| FLAG2_NO_DISABLE_RX,
.pba = 32,
.max_hw_frame_size = DEFAULT_JUMBO,
^ permalink raw reply related [flat|nested] 78+ messages in thread* [ 15/48] e1000e: Remove special case for 82573/82574 ASPM L1 disablement
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (13 preceding siblings ...)
2012-07-01 17:20 ` [ 14/48] e1000e: Disable ASPM L1 on 82574 Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 22:59 ` Jonathan Nieder
2012-07-01 17:20 ` [ 16/48] drm/i915: Do the fallback non-IRQ wait in ring throttle, too Ben Hutchings
` (33 subsequent siblings)
48 siblings, 1 reply; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Chris Boot, Jeff Pieper, Jeff Kirsher
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chris Boot <bootc@bootc.net>
commit 59aed95263bdd0e2b48eb9be5a94346d2d4abf90 upstream.
For the 82573, ASPM L1 gets disabled wholesale so this special-case code
is not required. For the 82574 the previous patch does the same as for
the 82573, disabling L1 on the adapter. Thus, this code is no longer
required and can be removed.
Signed-off-by: Chris Boot <bootc@bootc.net>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/net/ethernet/intel/e1000e/netdev.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index ab4505c..9c4576e 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -5272,14 +5272,6 @@ static int e1000_change_mtu(struct net_device *netdev, int new_mtu)
return -EINVAL;
}
- /* 82573 Errata 17 */
- if (((adapter->hw.mac.type == e1000_82573) ||
- (adapter->hw.mac.type == e1000_82574)) &&
- (max_frame > ETH_FRAME_LEN + ETH_FCS_LEN)) {
- adapter->flags2 |= FLAG2_DISABLE_ASPM_L1;
- e1000e_disable_aspm(adapter->pdev, PCIE_LINK_STATE_L1);
- }
-
while (test_and_set_bit(__E1000_RESETTING, &adapter->state))
usleep_range(1000, 2000);
/* e1000e_down -> e1000e_reset dependent on max_frame_size & mtu */
^ permalink raw reply related [flat|nested] 78+ messages in thread* Re: [ 15/48] e1000e: Remove special case for 82573/82574 ASPM L1 disablement
2012-07-01 17:20 ` [ 15/48] e1000e: Remove special case for 82573/82574 ASPM L1 disablement Ben Hutchings
@ 2012-07-01 22:59 ` Jonathan Nieder
2012-07-02 7:21 ` Chris Boot
0 siblings, 1 reply; 78+ messages in thread
From: Jonathan Nieder @ 2012-07-01 22:59 UTC (permalink / raw)
To: Ben Hutchings
Cc: linux-kernel, stable, torvalds, akpm, alan, Chris Boot,
Jeff Pieper, Jeff Kirsher
Ben Hutchings wrote:
> 3.2-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Chris Boot <bootc@bootc.net>
>
> commit 59aed95263bdd0e2b48eb9be5a94346d2d4abf90 upstream.
This patch still seems both lovely and unnecessary, and I would prefer
that it not be part of 3.2-stable. If I understood the replies before,
it is safe to drop it, right?
Thanks,
Jonathan
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [ 15/48] e1000e: Remove special case for 82573/82574 ASPM L1 disablement
2012-07-01 22:59 ` Jonathan Nieder
@ 2012-07-02 7:21 ` Chris Boot
0 siblings, 0 replies; 78+ messages in thread
From: Chris Boot @ 2012-07-02 7:21 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Ben Hutchings, linux-kernel, stable, torvalds, akpm, alan,
Jeff Pieper, Jeff Kirsher
On 01/07/2012 23:59, Jonathan Nieder wrote:
> Ben Hutchings wrote:
>
>> 3.2-stable review patch. If anyone has any objections, please let me know.
>>
>> ------------------
>>
>> From: Chris Boot <bootc@bootc.net>
>>
>> commit 59aed95263bdd0e2b48eb9be5a94346d2d4abf90 upstream.
> This patch still seems both lovely and unnecessary, and I would prefer
> that it not be part of 3.2-stable. If I understood the replies before,
> it is safe to drop it, right?
My only comment about this would be that I haven't tested it without
both patches, although I can't see why there would necessarily be a
problem with only having one patch and not the other.
HTH,
Chris
--
Chris Boot
bootc@bootc.net
^ permalink raw reply [flat|nested] 78+ messages in thread
* [ 16/48] drm/i915: Do the fallback non-IRQ wait in ring throttle, too.
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (14 preceding siblings ...)
2012-07-01 17:20 ` [ 15/48] e1000e: Remove special case for 82573/82574 ASPM L1 disablement Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 17/48] staging:rts_pstor:Fix possible panic by NULL pointer dereference Ben Hutchings
` (32 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Eric Anholt, Eugeni Dodonov,
Kenneth Graunke, Keith Packard
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Anholt <eric@anholt.net>
commit 7ea29b13e5e3e1e61e612349eb0366efdb6457f3 upstream.
As a workaround for IRQ synchronization issues in the gen7 BLT ring,
we want to turn the two wait functions into polling loops.
Signed-off-by: Eric Anholt <eric@anholt.net>
Tested-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/gpu/drm/i915/i915_gem.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8359dc7..66e0a55 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3309,6 +3309,10 @@ i915_gem_ring_throttle(struct drm_device *dev, struct drm_file *file)
if (ret == 0 && atomic_read(&dev_priv->mm.wedged))
ret = -EIO;
+ } else if (wait_for(i915_seqno_passed(ring->get_seqno(ring),
+ seqno) ||
+ atomic_read(&dev_priv->mm.wedged), 3000)) {
+ ret = -EBUSY;
}
}
^ permalink raw reply related [flat|nested] 78+ messages in thread* [ 17/48] staging:rts_pstor:Fix possible panic by NULL pointer dereference
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (15 preceding siblings ...)
2012-07-01 17:20 ` [ 16/48] drm/i915: Do the fallback non-IRQ wait in ring throttle, too Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 18/48] [media] gspca-core: Fix buffers staying in queued state after a stream_off Ben Hutchings
` (31 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: torvalds, akpm, alan, wwang, Greg Kroah-Hartman
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: wwang <wei_wang@realsil.com.cn>
commit 0d05568ac79bfc595f1eadc3e0fd7a20a45f7b69 upstream.
rtsx_transport.c (rtsx_transfer_sglist_adma_partial):
pointer struct scatterlist *sg, which is mapped in dma_map_sg,
is used as an iterator in later transfer operation. It is corrupted and
passed to dma_unmap_sg, thus causing fatal unmap of some erroneous address.
Fix it by duplicating *sg_ptr for iterating.
Signed-off-by: wwang <wei_wang@realsil.com.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/staging/rts_pstor/rtsx_transport.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/rts_pstor/rtsx_transport.c b/drivers/staging/rts_pstor/rtsx_transport.c
index 4e3d2c1..9b2e5c9 100644
--- a/drivers/staging/rts_pstor/rtsx_transport.c
+++ b/drivers/staging/rts_pstor/rtsx_transport.c
@@ -335,6 +335,7 @@ static int rtsx_transfer_sglist_adma_partial(struct rtsx_chip *chip, u8 card,
int sg_cnt, i, resid;
int err = 0;
long timeleft;
+ struct scatterlist *sg_ptr;
u32 val = TRIG_DMA;
if ((sg == NULL) || (num_sg <= 0) || !offset || !index)
@@ -371,7 +372,7 @@ static int rtsx_transfer_sglist_adma_partial(struct rtsx_chip *chip, u8 card,
sg_cnt = dma_map_sg(&(rtsx->pci->dev), sg, num_sg, dma_dir);
resid = size;
-
+ sg_ptr = sg;
chip->sgi = 0;
/* Usually the next entry will be @sg@ + 1, but if this sg element
* is part of a chained scatterlist, it could jump to the start of
@@ -379,14 +380,14 @@ static int rtsx_transfer_sglist_adma_partial(struct rtsx_chip *chip, u8 card,
* the proper sg
*/
for (i = 0; i < *index; i++)
- sg = sg_next(sg);
+ sg_ptr = sg_next(sg_ptr);
for (i = *index; i < sg_cnt; i++) {
dma_addr_t addr;
unsigned int len;
u8 option;
- addr = sg_dma_address(sg);
- len = sg_dma_len(sg);
+ addr = sg_dma_address(sg_ptr);
+ len = sg_dma_len(sg_ptr);
RTSX_DEBUGP("DMA addr: 0x%x, Len: 0x%x\n",
(unsigned int)addr, len);
@@ -415,7 +416,7 @@ static int rtsx_transfer_sglist_adma_partial(struct rtsx_chip *chip, u8 card,
if (!resid)
break;
- sg = sg_next(sg);
+ sg_ptr = sg_next(sg_ptr);
}
RTSX_DEBUGP("SG table count = %d\n", chip->sgi);
^ permalink raw reply related [flat|nested] 78+ messages in thread* [ 18/48] [media] gspca-core: Fix buffers staying in queued state after a stream_off
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (16 preceding siblings ...)
2012-07-01 17:20 ` [ 17/48] staging:rts_pstor:Fix possible panic by NULL pointer dereference Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 19/48] [media] smsusb: add autodetection support for USB ID 2040:f5a0 Ben Hutchings
` (30 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Hans de Goede, Antonio Ospite,
Mauro Carvalho Chehab
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <hdegoede@redhat.com>
commit af05ef01e9cde84620c6855a8d8ab9c8a1db9009 upstream.
This fixes a regression introduced by commit f7059ea and should be
backported to all supported stable kernels which have this commit.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Antonio Ospite <ospite@studenti.unina.it>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/media/video/gspca/gspca.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/media/video/gspca/gspca.c
+++ b/drivers/media/video/gspca/gspca.c
@@ -1697,7 +1697,7 @@
enum v4l2_buf_type buf_type)
{
struct gspca_dev *gspca_dev = priv;
- int ret;
+ int i, ret;
if (buf_type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
return -EINVAL;
@@ -1728,6 +1728,8 @@
wake_up_interruptible(&gspca_dev->wq);
/* empty the transfer queues */
+ for (i = 0; i < gspca_dev->nframes; i++)
+ gspca_dev->frame[i].v4l2_buf.flags &= ~BUF_ALL_FLAGS;
atomic_set(&gspca_dev->fr_q, 0);
atomic_set(&gspca_dev->fr_i, 0);
gspca_dev->fr_o = 0;
^ permalink raw reply [flat|nested] 78+ messages in thread* [ 19/48] [media] smsusb: add autodetection support for USB ID 2040:f5a0
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (17 preceding siblings ...)
2012-07-01 17:20 ` [ 18/48] [media] gspca-core: Fix buffers staying in queued state after a stream_off Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 20/48] drm/edid: dont return stack garbage from supports_rb Ben Hutchings
` (29 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Michael Krufky, Mauro Carvalho Chehab
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael Krufky <mkrufky@linuxtv.org>
commit 3e1141e2ce5667301a74ca2ef396d9bd5e995f7f upstream.
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/media/dvb/siano/smsusb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/dvb/siano/smsusb.c b/drivers/media/dvb/siano/smsusb.c
index 63c004a..664e460 100644
--- a/drivers/media/dvb/siano/smsusb.c
+++ b/drivers/media/dvb/siano/smsusb.c
@@ -544,6 +544,8 @@ static const struct usb_device_id smsusb_id_table[] __devinitconst = {
.driver_info = SMS1XXX_BOARD_HAUPPAUGE_WINDHAM },
{ USB_DEVICE(0x2040, 0xc0a0),
.driver_info = SMS1XXX_BOARD_HAUPPAUGE_WINDHAM },
+ { USB_DEVICE(0x2040, 0xf5a0),
+ .driver_info = SMS1XXX_BOARD_HAUPPAUGE_WINDHAM },
{ } /* Terminating entry */
};
^ permalink raw reply related [flat|nested] 78+ messages in thread* [ 20/48] drm/edid: dont return stack garbage from supports_rb
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (18 preceding siblings ...)
2012-07-01 17:20 ` [ 19/48] [media] smsusb: add autodetection support for USB ID 2040:f5a0 Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 21/48] drm/nouveau/fbcon: using nv_two_heads is not a good idea Ben Hutchings
` (28 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Daniel Vetter, Adam Jackson, Dave Airlie
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Vetter <daniel.vetter@ffwll.ch>
commit b196a4980ff7bb54db478e2a408dc8b12be15304 upstream.
We need to initialize this to false, because the is_rb callback only
ever sets it to true.
Noticed while reading through the code.
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/gpu/drm/drm_edid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index eb92fe2..5873e48 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -610,7 +610,7 @@ static bool
drm_monitor_supports_rb(struct edid *edid)
{
if (edid->revision >= 4) {
- bool ret;
+ bool ret = false;
drm_for_each_detailed_block((u8 *)edid, is_rb, &ret);
return ret;
}
^ permalink raw reply related [flat|nested] 78+ messages in thread* [ 21/48] drm/nouveau/fbcon: using nv_two_heads is not a good idea
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (19 preceding siblings ...)
2012-07-01 17:20 ` [ 20/48] drm/edid: dont return stack garbage from supports_rb Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 22/48] dm thin: reinstate missing mempool_free in cell_release_singleton Ben Hutchings
` (27 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: torvalds, akpm, alan, Ben Skeggs, Dave Airlie
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ben Skeggs <bskeggs@redhat.com>
commit 9bd0c15fcfb42f6245447c53347d65ad9e72080b upstream.
nv_two_heads() was never meant to be used outside of pre-nv50 code. The
code checks for >= NV_10 for 2 CRTCs, then downgrades a few specific
chipsets to 1 CRTC based on (pci_device & 0x0ff0).
The breakage example seen is on GTX 560Ti, with a pciid of 0x1200, which
gets detected as an NV20 (0x020x) with 1 CRTC by nv_two_heads(), causing
memory corruption because there's actually 2 CRTCs..
This switches fbcon to use the CRTC count directly from the mode_config
structure, which will also fix the same issue on Kepler boards which have
4 CRTCs.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index 153b9a1..1074bc5 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -467,7 +467,7 @@ int nouveau_fbcon_init(struct drm_device *dev)
nfbdev->helper.funcs = &nouveau_fbcon_helper_funcs;
ret = drm_fb_helper_init(dev, &nfbdev->helper,
- nv_two_heads(dev) ? 2 : 1, 4);
+ dev->mode_config.num_crtc, 4);
if (ret) {
kfree(nfbdev);
return ret;
^ permalink raw reply related [flat|nested] 78+ messages in thread* [ 22/48] dm thin: reinstate missing mempool_free in cell_release_singleton
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (20 preceding siblings ...)
2012-07-01 17:20 ` [ 21/48] drm/nouveau/fbcon: using nv_two_heads is not a good idea Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 23/48] ath9k: Fix a WARNING on suspend/resume with IBSS Ben Hutchings
` (26 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Mike Snitzer, Alasdair G Kergon
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mike Snitzer <snitzer@redhat.com>
commit 03aaae7cdc71bc306888440b1f569d463e917b6d upstream.
Fix a significant memory leak inadvertently introduced during
simplification of cell_release_singleton() in commit
6f94a4c45a6f744383f9f695dde019998db3df55 ("dm thin: fix stacked bi_next
usage").
A cell's hlist_del() must be accompanied by a mempool_free().
Use __cell_release() to do this, like before.
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/md/dm-thin.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/md/dm-thin.c b/drivers/md/dm-thin.c
index 213ae32..301db0f 100644
--- a/drivers/md/dm-thin.c
+++ b/drivers/md/dm-thin.c
@@ -279,8 +279,10 @@ static void __cell_release(struct cell *cell, struct bio_list *inmates)
hlist_del(&cell->list);
- bio_list_add(inmates, cell->holder);
- bio_list_merge(inmates, &cell->bios);
+ if (inmates) {
+ bio_list_add(inmates, cell->holder);
+ bio_list_merge(inmates, &cell->bios);
+ }
mempool_free(cell, prison->cell_pool);
}
@@ -303,9 +305,10 @@ static void cell_release(struct cell *cell, struct bio_list *bios)
*/
static void __cell_release_singleton(struct cell *cell, struct bio *bio)
{
- hlist_del(&cell->list);
BUG_ON(cell->holder != bio);
BUG_ON(!bio_list_empty(&cell->bios));
+
+ __cell_release(cell, NULL);
}
static void cell_release_singleton(struct cell *cell, struct bio *bio)
^ permalink raw reply related [flat|nested] 78+ messages in thread* [ 23/48] ath9k: Fix a WARNING on suspend/resume with IBSS
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (21 preceding siblings ...)
2012-07-01 17:20 ` [ 22/48] dm thin: reinstate missing mempool_free in cell_release_singleton Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 24/48] cfg80211: fix potential deadlock in regulatory Ben Hutchings
` (25 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Mohammed Shafi Shajakhan,
Rajkumar Manoharan, John W. Linville
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
commit 2031b4c2b4904f7448ab9e4bc6b9bf16e32709f5 upstream.
this patch is dependent on the patch "cfg80211: fix interface
combinations"
In ath9k currently we have ADHOC interface as a single incompatible
interface. when drv_add_interface is called during resume we got to
consider number of vifs already present in addition to checking the
drivers 'opmode' information about ADHOC. we incorrectly assume
an ADHOC interface is already present. Then we may miss some driver
specific data for the ADHOC interface after resume.
The above mentioned checks can be removed from the driver,
as the patch 'cfg80211: fix interface combinations' ensures that
if an interface type is not advertised by the driver in any of the
interface combinations(via ieee80211_iface_combination) then it shall
be treated as a single incompatible interface. Fixes the following
warning on suspend/resume with ibss interface.
ath: phy0: Cannot create ADHOC interface when other
interfaces already exist.
WARNING: at net/mac80211/driver-ops.h:12
ieee80211_reconfig+0x1882/0x1ca0 [mac80211]()
Hardware name: 2842RK1
wlan2: Failed check-sdata-in-driver check, flags: 0x0
Call Trace:
[<c01361b2>] warn_slowpath_common+0x72/0xa0
[<f8aaa7c2>] ? ieee80211_reconfig+0x1882/0x1ca0
[mac80211]
[<f8aaa7c2>] ? ieee80211_reconfig+0x1882/0x1ca0
[mac80211]
[<c0136283>] warn_slowpath_fmt+0x33/0x40
[<f8aaa7c2>] ieee80211_reconfig+0x1882/0x1ca0 [mac80211]
[<c06c1d1a>] ? mutex_lock_nested+0x23a/0x2f0
[<f8a95097>] ieee80211_resume+0x27/0x70 [mac80211]
[<fd177edf>] wiphy_resume+0x8f/0xa0 [cfg80211]
Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/net/wireless/ath/ath9k/main.c | 9 ---------
1 file changed, 9 deletions(-)
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1486,15 +1486,6 @@
}
}
- if ((ah->opmode == NL80211_IFTYPE_ADHOC) ||
- ((vif->type == NL80211_IFTYPE_ADHOC) &&
- sc->nvifs > 0)) {
- ath_err(common, "Cannot create ADHOC interface when other"
- " interfaces already exist.\n");
- ret = -EINVAL;
- goto out;
- }
-
ath_dbg(common, ATH_DBG_CONFIG,
"Attach a VIF of type: %d\n", vif->type);
^ permalink raw reply [flat|nested] 78+ messages in thread* [ 24/48] cfg80211: fix potential deadlock in regulatory
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (22 preceding siblings ...)
2012-07-01 17:20 ` [ 23/48] ath9k: Fix a WARNING on suspend/resume with IBSS Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 25/48] ath9k: Fix softlockup in AR9485 Ben Hutchings
` (24 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: torvalds, akpm, alan, Eliad Peller, Johannes Berg
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eliad Peller <eliad@wizery.com>
commit fe20b39ec32e975f1054c0b7866c873a954adf05 upstream.
reg_timeout_work() calls restore_regulatory_settings() which
takes cfg80211_mutex.
reg_set_request_processed() already holds cfg80211_mutex
before calling cancel_delayed_work_sync(reg_timeout),
so it might deadlock.
Call the async cancel_delayed_work instead, in order
to avoid the potential deadlock.
This is the relevant lockdep warning:
cfg80211: Calling CRDA for country: XX
======================================================
[ INFO: possible circular locking dependency detected ]
3.4.0-rc5-wl+ #26 Not tainted
-------------------------------------------------------
kworker/0:2/1391 is trying to acquire lock:
(cfg80211_mutex){+.+.+.}, at: [<bf28ae00>] restore_regulatory_settings+0x34/0x418 [cfg80211]
but task is already holding lock:
((reg_timeout).work){+.+...}, at: [<c0059e94>] process_one_work+0x1f0/0x480
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 ((reg_timeout).work){+.+...}:
[<c008fd44>] validate_chain+0xb94/0x10f0
[<c0090b68>] __lock_acquire+0x8c8/0x9b0
[<c0090d40>] lock_acquire+0xf0/0x114
[<c005b600>] wait_on_work+0x4c/0x154
[<c005c000>] __cancel_work_timer+0xd4/0x11c
[<c005c064>] cancel_delayed_work_sync+0x1c/0x20
[<bf28b274>] reg_set_request_processed+0x50/0x78 [cfg80211]
[<bf28bd84>] set_regdom+0x550/0x600 [cfg80211]
[<bf294cd8>] nl80211_set_reg+0x218/0x258 [cfg80211]
[<c03c7738>] genl_rcv_msg+0x1a8/0x1e8
[<c03c6a00>] netlink_rcv_skb+0x5c/0xc0
[<c03c7584>] genl_rcv+0x28/0x34
[<c03c6720>] netlink_unicast+0x15c/0x228
[<c03c6c7c>] netlink_sendmsg+0x218/0x298
[<c03933c8>] sock_sendmsg+0xa4/0xc0
[<c039406c>] __sys_sendmsg+0x1e4/0x268
[<c0394228>] sys_sendmsg+0x4c/0x70
[<c0013840>] ret_fast_syscall+0x0/0x3c
-> #1 (reg_mutex){+.+.+.}:
[<c008fd44>] validate_chain+0xb94/0x10f0
[<c0090b68>] __lock_acquire+0x8c8/0x9b0
[<c0090d40>] lock_acquire+0xf0/0x114
[<c04734dc>] mutex_lock_nested+0x48/0x320
[<bf28b2cc>] reg_todo+0x30/0x538 [cfg80211]
[<c0059f44>] process_one_work+0x2a0/0x480
[<c005a4b4>] worker_thread+0x1bc/0x2bc
[<c0061148>] kthread+0x98/0xa4
[<c0014af4>] kernel_thread_exit+0x0/0x8
-> #0 (cfg80211_mutex){+.+.+.}:
[<c008ed58>] print_circular_bug+0x68/0x2cc
[<c008fb28>] validate_chain+0x978/0x10f0
[<c0090b68>] __lock_acquire+0x8c8/0x9b0
[<c0090d40>] lock_acquire+0xf0/0x114
[<c04734dc>] mutex_lock_nested+0x48/0x320
[<bf28ae00>] restore_regulatory_settings+0x34/0x418 [cfg80211]
[<bf28b200>] reg_timeout_work+0x1c/0x20 [cfg80211]
[<c0059f44>] process_one_work+0x2a0/0x480
[<c005a4b4>] worker_thread+0x1bc/0x2bc
[<c0061148>] kthread+0x98/0xa4
[<c0014af4>] kernel_thread_exit+0x0/0x8
other info that might help us debug this:
Chain exists of:
cfg80211_mutex --> reg_mutex --> (reg_timeout).work
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock((reg_timeout).work);
lock(reg_mutex);
lock((reg_timeout).work);
lock(cfg80211_mutex);
*** DEADLOCK ***
2 locks held by kworker/0:2/1391:
#0: (events){.+.+.+}, at: [<c0059e94>] process_one_work+0x1f0/0x480
#1: ((reg_timeout).work){+.+...}, at: [<c0059e94>] process_one_work+0x1f0/0x480
stack backtrace:
[<c001b928>] (unwind_backtrace+0x0/0x12c) from [<c0471d3c>] (dump_stack+0x20/0x24)
[<c0471d3c>] (dump_stack+0x20/0x24) from [<c008ef70>] (print_circular_bug+0x280/0x2cc)
[<c008ef70>] (print_circular_bug+0x280/0x2cc) from [<c008fb28>] (validate_chain+0x978/0x10f0)
[<c008fb28>] (validate_chain+0x978/0x10f0) from [<c0090b68>] (__lock_acquire+0x8c8/0x9b0)
[<c0090b68>] (__lock_acquire+0x8c8/0x9b0) from [<c0090d40>] (lock_acquire+0xf0/0x114)
[<c0090d40>] (lock_acquire+0xf0/0x114) from [<c04734dc>] (mutex_lock_nested+0x48/0x320)
[<c04734dc>] (mutex_lock_nested+0x48/0x320) from [<bf28ae00>] (restore_regulatory_settings+0x34/0x418 [cfg80211])
[<bf28ae00>] (restore_regulatory_settings+0x34/0x418 [cfg80211]) from [<bf28b200>] (reg_timeout_work+0x1c/0x20 [cfg80211])
[<bf28b200>] (reg_timeout_work+0x1c/0x20 [cfg80211]) from [<c0059f44>] (process_one_work+0x2a0/0x480)
[<c0059f44>] (process_one_work+0x2a0/0x480) from [<c005a4b4>] (worker_thread+0x1bc/0x2bc)
[<c005a4b4>] (worker_thread+0x1bc/0x2bc) from [<c0061148>] (kthread+0x98/0xa4)
[<c0061148>] (kthread+0x98/0xa4) from [<c0014af4>] (kernel_thread_exit+0x0/0x8)
cfg80211: Calling CRDA to update world regulatory domain
cfg80211: World regulatory domain updated:
cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
net/wireless/reg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 15f3474..baf5704 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1389,7 +1389,7 @@ static void reg_set_request_processed(void)
spin_unlock(®_requests_lock);
if (last_request->initiator == NL80211_REGDOM_SET_BY_USER)
- cancel_delayed_work_sync(®_timeout);
+ cancel_delayed_work(®_timeout);
if (need_more_processing)
schedule_work(®_work);
^ permalink raw reply related [flat|nested] 78+ messages in thread* [ 25/48] ath9k: Fix softlockup in AR9485
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (23 preceding siblings ...)
2012-07-01 17:20 ` [ 24/48] cfg80211: fix potential deadlock in regulatory Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 26/48] can: c_can: precedence error in c_can_chip_config() Ben Hutchings
` (23 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Mohammed Shafi Shajakhan, Rolf Offermanns,
John W. Linville
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
commit bcb7ad7bcbef030e6ba71ede1f9866368aca7c99 upstream.
steps to recreate:
load latest ath9k driver with AR9485
stop the network-manager and wpa_supplicant
bring the interface up
Call Trace:
[<ffffffffa0517490>] ? ath_hw_check+0xe0/0xe0 [ath9k]
[<ffffffff812cd1e8>] __const_udelay+0x28/0x30
[<ffffffffa03bae7a>] ar9003_get_pll_sqsum_dvc+0x4a/0x80 [ath9k_hw]
[<ffffffffa05174eb>] ath_hw_pll_work+0x5b/0xe0 [ath9k]
[<ffffffff810744fe>] process_one_work+0x11e/0x470
[<ffffffff8107530f>] worker_thread+0x15f/0x360
[<ffffffff810751b0>] ? manage_workers+0x230/0x230
[<ffffffff81079af3>] kthread+0x93/0xa0
[<ffffffff815fd3a4>] kernel_thread_helper+0x4/0x10
[<ffffffff81079a60>] ? kthread_freezable_should_stop+0x70/0x70
[<ffffffff815fd3a0>] ? gs_change+0x13/0x13
ensure that the PLL-WAR for AR9485/AR9340 is executed only if the STA is
associated (or) IBSS/AP mode had started beaconing. Ideally this WAR
is needed to recover from some rare beacon stuck during stress testing.
Before the STA is associated/IBSS had started beaconing, PLL4(0x1618c)
always seem to have zero even though we had configured PLL3(0x16188) to
query about PLL's locking status. When we keep on polling infinitely PLL4's
8th bit(ie check for PLL locking measurements is done), machine hangs
due to softlockup.
fixes https://bugzilla.redhat.com/show_bug.cgi?id=811142
Reported-by: Rolf Offermanns <rolf.offermanns@gmx.net>
Tested-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/net/wireless/ath/ath9k/main.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index ac41f1e..dac1a27 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -971,6 +971,15 @@ void ath_hw_pll_work(struct work_struct *work)
hw_pll_work.work);
u32 pll_sqsum;
+ /*
+ * ensure that the PLL WAR is executed only
+ * after the STA is associated (or) if the
+ * beaconing had started in interfaces that
+ * uses beacons.
+ */
+ if (!(sc->sc_flags & SC_OP_BEACONS))
+ return;
+
if (AR_SREV_9485(sc->sc_ah)) {
ath9k_ps_wakeup(sc);
^ permalink raw reply related [flat|nested] 78+ messages in thread* [ 26/48] can: c_can: precedence error in c_can_chip_config()
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (24 preceding siblings ...)
2012-07-01 17:20 ` [ 25/48] ath9k: Fix softlockup in AR9485 Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 27/48] ath9k: fix a tx rate duration calculation bug Ben Hutchings
` (22 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Dan Carpenter, Oliver Hartkopp,
Marc Kleine-Budde, David S. Miller
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <dan.carpenter@oracle.com>
commit d9cb9bd63eb27ac19f26a8547128c053f43a5da8 upstream.
(CAN_CTRLMODE_LISTENONLY & CAN_CTRLMODE_LOOPBACK) is (0x02 & 0x01) which
is zero so the condition is never true. The intent here was to test
that both flags were set.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/net/can/c_can/c_can.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index 8dc84d6..86cd532 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -590,8 +590,8 @@ static void c_can_chip_config(struct net_device *dev)
priv->write_reg(priv, &priv->regs->control,
CONTROL_ENABLE_AR);
- if (priv->can.ctrlmode & (CAN_CTRLMODE_LISTENONLY &
- CAN_CTRLMODE_LOOPBACK)) {
+ if ((priv->can.ctrlmode & CAN_CTRLMODE_LISTENONLY) &&
+ (priv->can.ctrlmode & CAN_CTRLMODE_LOOPBACK)) {
/* loopback + silent mode : useful for hot self-test */
priv->write_reg(priv, &priv->regs->control, CONTROL_EIE |
CONTROL_SIE | CONTROL_IE | CONTROL_TEST);
^ permalink raw reply related [flat|nested] 78+ messages in thread* [ 27/48] ath9k: fix a tx rate duration calculation bug
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (25 preceding siblings ...)
2012-07-01 17:20 ` [ 26/48] can: c_can: precedence error in c_can_chip_config() Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 28/48] batman-adv: fix skb->data assignment Ben Hutchings
` (21 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Felix Fietkau, John W. Linville
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felix Fietkau <nbd@openwrt.org>
commit 76591bea9714a58d8924154068c78d702eb2cb17 upstream.
The rate pointer variable for a rate series is used in a loop before it is
initialized. This went unnoticed because it was used earlier for the RTS/CTS
rate. This bug can lead to the wrong PHY type being passed to the
duration calculation function.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/net/wireless/ath/ath9k/xmit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index d59dd01..efb7f00 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -1001,13 +1001,13 @@ static void ath_buf_set_rate(struct ath_softc *sc, struct ath_buf *bf,
}
/* legacy rates */
+ rate = &sc->sbands[tx_info->band].bitrates[rates[i].idx];
if ((tx_info->band == IEEE80211_BAND_2GHZ) &&
!(rate->flags & IEEE80211_RATE_ERP_G))
phy = WLAN_RC_PHY_CCK;
else
phy = WLAN_RC_PHY_OFDM;
- rate = &sc->sbands[tx_info->band].bitrates[rates[i].idx];
info->rates[i].Rate = rate->hw_value;
if (rate->hw_value_short) {
if (rates[i].flags & IEEE80211_TX_RC_USE_SHORT_PREAMBLE)
^ permalink raw reply related [flat|nested] 78+ messages in thread* [ 28/48] batman-adv: fix skb->data assignment
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (26 preceding siblings ...)
2012-07-01 17:20 ` [ 27/48] ath9k: fix a tx rate duration calculation bug Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 29/48] ARM: SAMSUNG: Should check for IS_ERR(clk) instead of NULL Ben Hutchings
` (20 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Antonio Quartulli, David S. Miller
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Antonio Quartulli <ordex@autistici.org>
commit 2c995ff892313009e336ecc8ec3411022f5b1c39 upstream.
skb_linearize(skb) possibly rearranges the skb internal data and then changes
the skb->data pointer value. For this reason any other pointer in the code that
was assigned skb->data before invoking skb_linearise(skb) must be re-assigned.
In the current tt_query message handling code this is not done and therefore, in
case of skb linearization, the pointer used to handle the packet header ends up
in pointing to free'd memory.
This bug was introduced by a73105b8d4c765d9ebfb664d0a66802127d8e4c7
(batman-adv: improved client announcement mechanism)
Signed-off-by: Antonio Quartulli <ordex@autistici.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
[This patch is a backport for kernel versions 3.1 and 3.2 - Antonio]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
net/batman-adv/routing.c | 2 ++
1 file changed, 2 insertions(+)
--- a/net/batman-adv/routing.c
+++ b/net/batman-adv/routing.c
@@ -619,6 +619,8 @@
/* packet needs to be linearized to access the TT changes */
if (skb_linearize(skb) < 0)
goto out;
+ /* skb_linearize() possibly changed skb->data */
+ tt_query = (struct tt_query_packet *)skb->data;
if (is_my_mac(tt_query->dst))
handle_tt_response(bat_priv, tt_query);
^ permalink raw reply [flat|nested] 78+ messages in thread* [ 29/48] ARM: SAMSUNG: Should check for IS_ERR(clk) instead of NULL
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (27 preceding siblings ...)
2012-07-01 17:20 ` [ 28/48] batman-adv: fix skb->data assignment Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 30/48] ath9k_hw: avoid possible infinite loop in ar9003_get_pll_sqsum_dvc Ben Hutchings
` (19 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: torvalds, akpm, alan, Jonghwan Choi, Kukjin Kim
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jonghwan Choi <jhbird.choi@samsung.com>
commit a5d8f4765f0e92ef027492a8cb979c5b8d45f2c3 upstream.
On the error condition clk_get() returns ERR_PTR().
Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
arch/arm/plat-samsung/include/plat/watchdog-reset.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/plat-samsung/include/plat/watchdog-reset.h b/arch/arm/plat-samsung/include/plat/watchdog-reset.h
index f19aff1..bc4db9b 100644
--- a/arch/arm/plat-samsung/include/plat/watchdog-reset.h
+++ b/arch/arm/plat-samsung/include/plat/watchdog-reset.h
@@ -25,7 +25,7 @@ static inline void arch_wdt_reset(void)
__raw_writel(0, S3C2410_WTCON); /* disable watchdog, to be safe */
- if (s3c2410_wdtclk)
+ if (!IS_ERR(s3c2410_wdtclk))
clk_enable(s3c2410_wdtclk);
/* put initial values into count and data */
^ permalink raw reply related [flat|nested] 78+ messages in thread* [ 30/48] ath9k_hw: avoid possible infinite loop in ar9003_get_pll_sqsum_dvc
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (28 preceding siblings ...)
2012-07-01 17:20 ` [ 29/48] ARM: SAMSUNG: Should check for IS_ERR(clk) instead of NULL Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 31/48] iwlwifi: remove log_event debugfs file debugging is disabled Ben Hutchings
` (18 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Mohammed Shafi Shajakhan, Rolf Offermanns,
Sujith Manoharan, Senthil Balasubramanian, John W. Linville
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
commit f18e3c6b67f448ec47b3a5b242789bd3d5644879 upstream.
"ath9k: Fix softlockup in AR9485" with commit id
64bc1239c790e051ff677e023435d770d2ffa174 fixed the reported
issue, yet its better to avoid the possible infinite loop
in ar9003_get_pll_sqsum_dvc by having a timeout as suggested
by ath9k maintainers.
http://www.spinics.net/lists/linux-wireless/msg92126.html.
Based on my testing PLL's locking measurement is done in
~200us (2 iterations).
Cc: Rolf Offermanns <rolf.offermanns@gmx.net>
Cc: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/net/wireless/ath/ath9k/hw.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 7db1890..1c68e56 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -784,13 +784,25 @@ static void ath9k_hw_init_qos(struct ath_hw *ah)
u32 ar9003_get_pll_sqsum_dvc(struct ath_hw *ah)
{
+ struct ath_common *common = ath9k_hw_common(ah);
+ int i = 0;
+
REG_CLR_BIT(ah, PLL3, PLL3_DO_MEAS_MASK);
udelay(100);
REG_SET_BIT(ah, PLL3, PLL3_DO_MEAS_MASK);
- while ((REG_READ(ah, PLL4) & PLL4_MEAS_DONE) == 0)
+ while ((REG_READ(ah, PLL4) & PLL4_MEAS_DONE) == 0) {
+
udelay(100);
+ if (WARN_ON_ONCE(i >= 100)) {
+ ath_err(common, "PLL4 meaurement not done\n");
+ break;
+ }
+
+ i++;
+ }
+
return (REG_READ(ah, PLL3) & SQSUM_DVC_MASK) >> 3;
}
EXPORT_SYMBOL(ar9003_get_pll_sqsum_dvc);
^ permalink raw reply related [flat|nested] 78+ messages in thread* [ 31/48] iwlwifi: remove log_event debugfs file debugging is disabled
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (29 preceding siblings ...)
2012-07-01 17:20 ` [ 30/48] ath9k_hw: avoid possible infinite loop in ar9003_get_pll_sqsum_dvc Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 32/48] ARM: SAMSUNG: Fix for S3C2412 EBI memory mapping Ben Hutchings
` (17 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Johannes Berg, Lekensteyn,
Emmanuel Grumbach, John W. Linville
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johannes Berg <johannes.berg@intel.com>
commit 882b7b7d11d65e8eccce738f1ce97cdfdb998f9f upstream.
When debugging is disabled, the event log functions aren't
functional in the way that the debugfs file expects. This
leads to the debugfs access crashing. Since the event log
functions aren't functional then, remove the debugfs file
when CONFIG_IWLWIFI_DEBUG is not set.
Reported-by: Lekensteyn <lekensteyn@gmail.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
--- a/drivers/net/wireless/iwlwifi/iwl-trans-pcie.c
+++ b/drivers/net/wireless/iwlwifi/iwl-trans-pcie.c
@@ -1777,6 +1777,7 @@
return simple_read_from_buffer(user_buf, count, ppos, buf, pos);
}
+#ifdef CONFIG_IWLWIFI_DEBUG
static ssize_t iwl_dbgfs_log_event_read(struct file *file,
char __user *user_buf,
size_t count, loff_t *ppos)
@@ -1814,6 +1815,7 @@
return count;
}
+#endif
static ssize_t iwl_dbgfs_interrupt_read(struct file *file,
char __user *user_buf,
@@ -1941,7 +1943,9 @@
return ret;
}
+#ifdef CONFIG_IWLWIFI_DEBUG
DEBUGFS_READ_WRITE_FILE_OPS(log_event);
+#endif
DEBUGFS_READ_WRITE_FILE_OPS(interrupt);
DEBUGFS_READ_FILE_OPS(fh_reg);
DEBUGFS_READ_FILE_OPS(rx_queue);
@@ -1957,7 +1961,9 @@
{
DEBUGFS_ADD_FILE(rx_queue, dir, S_IRUSR);
DEBUGFS_ADD_FILE(tx_queue, dir, S_IRUSR);
+#ifdef CONFIG_IWLWIFI_DEBUG
DEBUGFS_ADD_FILE(log_event, dir, S_IWUSR | S_IRUSR);
+#endif
DEBUGFS_ADD_FILE(interrupt, dir, S_IWUSR | S_IRUSR);
DEBUGFS_ADD_FILE(csr, dir, S_IWUSR);
DEBUGFS_ADD_FILE(fh_reg, dir, S_IRUSR);
^ permalink raw reply [flat|nested] 78+ messages in thread* [ 32/48] ARM: SAMSUNG: Fix for S3C2412 EBI memory mapping
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (30 preceding siblings ...)
2012-07-01 17:20 ` [ 31/48] iwlwifi: remove log_event debugfs file debugging is disabled Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 33/48] USB: option: add id for Cellient MEN-200 Ben Hutchings
` (16 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Jose Miguel Goncalves, Kukjin Kim
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jose Miguel Goncalves <jose.goncalves@inov.pt>
commit 3dca938656c7b0ff6b0717a5dde0f5f45e592be5 upstream.
While upgrading the kernel on a S3C2412 based board I've noted
that it was impossible to boot the board with a 2.6.32 or upper
kernel. I've tracked down the problem to the EBI virtual memory
mapping that is in conflict with the IO mapping definition in
arch/arm/mach-s3c24xx/s3c2412.c.
Signed-off-by: Jose Miguel Goncalves <jose.goncalves@inov.pt>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
arch/arm/plat-samsung/include/plat/map-s3c.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/plat-samsung/include/plat/map-s3c.h b/arch/arm/plat-samsung/include/plat/map-s3c.h
index 7d04875..c0c70a8 100644
--- a/arch/arm/plat-samsung/include/plat/map-s3c.h
+++ b/arch/arm/plat-samsung/include/plat/map-s3c.h
@@ -22,7 +22,7 @@
#define S3C24XX_VA_WATCHDOG S3C_VA_WATCHDOG
#define S3C2412_VA_SSMC S3C_ADDR_CPU(0x00000000)
-#define S3C2412_VA_EBI S3C_ADDR_CPU(0x00010000)
+#define S3C2412_VA_EBI S3C_ADDR_CPU(0x00100000)
#define S3C2410_PA_UART (0x50000000)
#define S3C24XX_PA_UART S3C2410_PA_UART
^ permalink raw reply related [flat|nested] 78+ messages in thread* [ 33/48] USB: option: add id for Cellient MEN-200
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (31 preceding siblings ...)
2012-07-01 17:20 ` [ 32/48] ARM: SAMSUNG: Fix for S3C2412 EBI memory mapping Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 34/48] oprofile: perf: use NR_CPUS instead or nr_cpumask_bits for static array Ben Hutchings
` (15 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Dmitry Shmygov, Greg Kroah-Hartman
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dmitry Shmygov <shmygov@rambler.ru>
commit 1e2c4e59d2b8797973471b4a287a43eac12a0f40 upstream.
Add vendor and product ID to option.c driver
for Cellient MEN-200 EVDO Rev.B 450MHz data module.
http://cellient.com
Signed-off-by: Dmitry Shmygov <shmygov@rambler.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/usb/serial/option.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index e668a24..396d968 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -497,6 +497,10 @@ static void option_instat_callback(struct urb *urb);
/* MediaTek products */
#define MEDIATEK_VENDOR_ID 0x0e8d
+/* Cellient products */
+#define CELLIENT_VENDOR_ID 0x2692
+#define CELLIENT_PRODUCT_MEN200 0x9005
+
/* some devices interfaces need special handling due to a number of reasons */
enum option_blacklist_reason {
OPTION_BLACKLIST_NONE = 0,
@@ -1233,6 +1237,7 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE_AND_INTERFACE_INFO(MEDIATEK_VENDOR_ID, 0x00a1, 0xff, 0x02, 0x01) },
{ USB_DEVICE_AND_INTERFACE_INFO(MEDIATEK_VENDOR_ID, 0x00a2, 0xff, 0x00, 0x00) },
{ USB_DEVICE_AND_INTERFACE_INFO(MEDIATEK_VENDOR_ID, 0x00a2, 0xff, 0x02, 0x01) }, /* MediaTek MT6276M modem & app port */
+ { USB_DEVICE(CELLIENT_VENDOR_ID, CELLIENT_PRODUCT_MEN200) },
{ } /* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, option_ids);
^ permalink raw reply related [flat|nested] 78+ messages in thread* [ 34/48] oprofile: perf: use NR_CPUS instead or nr_cpumask_bits for static array
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (32 preceding siblings ...)
2012-07-01 17:20 ` [ 33/48] USB: option: add id for Cellient MEN-200 Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 35/48] drm/i915: Refactor the deferred PM_IIR handling into a single function Ben Hutchings
` (14 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Will Deacon, Matt Fleming,
Russell King - ARM Linux, Robert Richter
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Will Deacon <will.deacon@arm.com>
commit e734568b675c985db2026848fefaac01c22977a5 upstream.
The OProfile perf backend uses a static array to keep track of the
perf events on the system. When compiling with CONFIG_CPUMASK_OFFSTACK=y
&& SMP, nr_cpumask_bits is not a compile-time constant and the build
will fail with:
oprofile_perf.c:28: error: variably modified 'perf_events' at file scope
This patch uses NR_CPUs instead of nr_cpumask_bits for the array
initialisation. If this causes space problems in the future, we can
always move to dynamic allocation for the events array.
Cc: Matt Fleming <matt@console-pimps.org>
Reported-by: Russell King - ARM Linux <linux@arm.linux.org.uk>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Robert Richter <robert.richter@amd.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/oprofile/oprofile_perf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/oprofile/oprofile_perf.c b/drivers/oprofile/oprofile_perf.c
index da14432..efc4b7f 100644
--- a/drivers/oprofile/oprofile_perf.c
+++ b/drivers/oprofile/oprofile_perf.c
@@ -25,7 +25,7 @@ static int oprofile_perf_enabled;
static DEFINE_MUTEX(oprofile_perf_mutex);
static struct op_counter_config *counter_config;
-static struct perf_event **perf_events[nr_cpumask_bits];
+static struct perf_event **perf_events[NR_CPUS];
static int num_counters;
/*
^ permalink raw reply related [flat|nested] 78+ messages in thread* [ 35/48] drm/i915: Refactor the deferred PM_IIR handling into a single function
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (33 preceding siblings ...)
2012-07-01 17:20 ` [ 34/48] oprofile: perf: use NR_CPUS instead or nr_cpumask_bits for static array Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 36/48] drm/i915: rip out the PM_IIR WARN Ben Hutchings
` (13 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: torvalds, akpm, alan, Chris Wilson, Daniel Vetter
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chris Wilson <chris@chris-wilson.co.uk>
commit fc6826d1dcd65f3d1e9a5377678882e4e08f02be upstream.
This function, along with the registers and deferred work hander, are
all shared with SandyBridge, IvyBridge and their variants. So remove the
duplicate code into a single function.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[bwh: Backported to 3.2: adjust context; drop changes for Valley View]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/gpu/drm/i915/i915_irq.c | 70 +++++++++++++++++----------------------
1 file changed, 31 insertions(+), 39 deletions(-)
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -424,6 +424,31 @@
mutex_unlock(&dev_priv->dev->struct_mutex);
}
+static void gen6_queue_rps_work(struct drm_i915_private *dev_priv,
+ u32 pm_iir)
+{
+ unsigned long flags;
+
+ /*
+ * IIR bits should never already be set because IMR should
+ * prevent an interrupt from being shown in IIR. The warning
+ * displays a case where we've unsafely cleared
+ * dev_priv->pm_iir. Although missing an interrupt of the same
+ * type is not a problem, it displays a problem in the logic.
+ *
+ * The mask bit in IMR is cleared by rps_work.
+ */
+
+ spin_lock_irqsave(&dev_priv->rps_lock, flags);
+ WARN(dev_priv->pm_iir & pm_iir, "Missed a PM interrupt\n");
+ dev_priv->pm_iir |= pm_iir;
+ I915_WRITE(GEN6_PMIMR, dev_priv->pm_iir);
+ POSTING_READ(GEN6_PMIMR);
+ spin_unlock_irqrestore(&dev_priv->rps_lock, flags);
+
+ queue_work(dev_priv->wq, &dev_priv->rps_work);
+}
+
static void pch_irq_handler(struct drm_device *dev, u32 pch_iir)
{
drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev->dev_private;
@@ -529,16 +554,8 @@
pch_irq_handler(dev, pch_iir);
}
- if (pm_iir & GEN6_PM_DEFERRED_EVENTS) {
- unsigned long flags;
- spin_lock_irqsave(&dev_priv->rps_lock, flags);
- WARN(dev_priv->pm_iir & pm_iir, "Missed a PM interrupt\n");
- dev_priv->pm_iir |= pm_iir;
- I915_WRITE(GEN6_PMIMR, dev_priv->pm_iir);
- POSTING_READ(GEN6_PMIMR);
- spin_unlock_irqrestore(&dev_priv->rps_lock, flags);
- queue_work(dev_priv->wq, &dev_priv->rps_work);
- }
+ if (pm_iir & GEN6_PM_DEFERRED_EVENTS)
+ gen6_queue_rps_work(dev_priv, pm_iir);
/* should clear PCH hotplug event before clear CPU irq */
I915_WRITE(SDEIIR, pch_iir);
@@ -634,25 +651,8 @@
i915_handle_rps_change(dev);
}
- if (IS_GEN6(dev) && pm_iir & GEN6_PM_DEFERRED_EVENTS) {
- /*
- * IIR bits should never already be set because IMR should
- * prevent an interrupt from being shown in IIR. The warning
- * displays a case where we've unsafely cleared
- * dev_priv->pm_iir. Although missing an interrupt of the same
- * type is not a problem, it displays a problem in the logic.
- *
- * The mask bit in IMR is cleared by rps_work.
- */
- unsigned long flags;
- spin_lock_irqsave(&dev_priv->rps_lock, flags);
- WARN(dev_priv->pm_iir & pm_iir, "Missed a PM interrupt\n");
- dev_priv->pm_iir |= pm_iir;
- I915_WRITE(GEN6_PMIMR, dev_priv->pm_iir);
- POSTING_READ(GEN6_PMIMR);
- spin_unlock_irqrestore(&dev_priv->rps_lock, flags);
- queue_work(dev_priv->wq, &dev_priv->rps_work);
- }
+ if (IS_GEN6(dev) && pm_iir & GEN6_PM_DEFERRED_EVENTS)
+ gen6_queue_rps_work(dev_priv, pm_iir);
/* should clear PCH hotplug event before clear CPU irq */
I915_WRITE(SDEIIR, pch_iir);
^ permalink raw reply [flat|nested] 78+ messages in thread* [ 36/48] drm/i915: rip out the PM_IIR WARN
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (34 preceding siblings ...)
2012-07-01 17:20 ` [ 35/48] drm/i915: Refactor the deferred PM_IIR handling into a single function Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 37/48] drm/i915: Fix eDP blank screen after S3 resume on HP desktops Ben Hutchings
` (12 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: torvalds, akpm, alan, Daniel Vetter, Chris Wilson
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Vetter <daniel.vetter@ffwll.ch>
commit 58bf8062d0b293b8e1028e5b0342082002886bd4 upstream.
After banging my head against this for the past few months, I still
don't see how this could possible race under the premise that once an
irq bit is masked in PM_IMR and reset in PM_IIR it won't show up again
until we unmask it in PM_IMR.
Still, we have reports of this being seen in the wild. Now Bspec has
this little bit of lovely language in the PMIIR register:
Public SNB Docs, Vol3Part2, 2.5.14 "PMIIR":
"For each bit, the IIR can store a second pending interrupt if two or
more of the same interrupt conditions occur before the first condition
is cleared. Upon clearing the interrupt, the IIR bit will momentarily
go low, then return high to indicate there is another interrupt
pending."
Now if we presume that PMIMR only prevent new interrupts from being
queued, we could easily end up masking an interrupt and clearing it,
but the 2nd pending interrupt setting the bit in PMIIR right away
again. Which leads, the next time the irq handler runs, to hitting the
WARN.
Also, no bad side effects of this have ever been reported. And we've
tracked down our issues with the gpu turbo getting stuck to bogus
interrupt generation limits in th RPLIMIT register.
So let's just rip out this WARN as bogus and call it a day. The only
shallow thing here is that this 2-deep irq queue in the hw makes you
wonder how racy the windows irq handler is ...
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42907
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/gpu/drm/i915/i915_irq.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index b1fe0ed..ed3224c 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -412,7 +412,6 @@ static void gen6_queue_rps_work(struct drm_i915_private *dev_priv,
*/
spin_lock_irqsave(&dev_priv->rps_lock, flags);
- WARN(dev_priv->pm_iir & pm_iir, "Missed a PM interrupt\n");
dev_priv->pm_iir |= pm_iir;
I915_WRITE(GEN6_PMIMR, dev_priv->pm_iir);
POSTING_READ(GEN6_PMIMR);
^ permalink raw reply related [flat|nested] 78+ messages in thread* [ 37/48] drm/i915: Fix eDP blank screen after S3 resume on HP desktops
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (35 preceding siblings ...)
2012-07-01 17:20 ` [ 36/48] drm/i915: rip out the PM_IIR WARN Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 38/48] SCSI & usb-storage: add try_rc_10_first flag Ben Hutchings
` (11 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: torvalds, akpm, alan, Takashi Iwai, Daniel Vetter
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <tiwai@suse.de>
commit 6db65cbb941f9d433659bdad02b307f6d94465df upstream.
This patch fixes the problem on some HP desktop machines with eDP
which give blank screens after S3 resume.
It turned out that BLC_PWM_CPU_CTL must be written after
BLC_PWM_CPU_CTL2. Otherwise it doesn't take effect on these
SNB machines.
Tested with 3.5-rc3 kernel.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49233
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/gpu/drm/i915/i915_suspend.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_suspend.c b/drivers/gpu/drm/i915/i915_suspend.c
index 0ede02a..a748e5c 100644
--- a/drivers/gpu/drm/i915/i915_suspend.c
+++ b/drivers/gpu/drm/i915/i915_suspend.c
@@ -740,8 +740,11 @@ static void i915_restore_display(struct drm_device *dev)
if (HAS_PCH_SPLIT(dev)) {
I915_WRITE(BLC_PWM_PCH_CTL1, dev_priv->saveBLC_PWM_CTL);
I915_WRITE(BLC_PWM_PCH_CTL2, dev_priv->saveBLC_PWM_CTL2);
- I915_WRITE(BLC_PWM_CPU_CTL, dev_priv->saveBLC_CPU_PWM_CTL);
+ /* NOTE: BLC_PWM_CPU_CTL must be written after BLC_PWM_CPU_CTL2;
+ * otherwise we get blank eDP screen after S3 on some machines
+ */
I915_WRITE(BLC_PWM_CPU_CTL2, dev_priv->saveBLC_CPU_PWM_CTL2);
+ I915_WRITE(BLC_PWM_CPU_CTL, dev_priv->saveBLC_CPU_PWM_CTL);
I915_WRITE(PCH_PP_ON_DELAYS, dev_priv->savePP_ON_DELAYS);
I915_WRITE(PCH_PP_OFF_DELAYS, dev_priv->savePP_OFF_DELAYS);
I915_WRITE(PCH_PP_DIVISOR, dev_priv->savePP_DIVISOR);
^ permalink raw reply related [flat|nested] 78+ messages in thread* [ 38/48] SCSI & usb-storage: add try_rc_10_first flag
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (36 preceding siblings ...)
2012-07-01 17:20 ` [ 37/48] drm/i915: Fix eDP blank screen after S3 resume on HP desktops Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-02 7:10 ` Hans de Goede
2012-07-01 17:20 ` [ 39/48] PM / Sleep: Prevent waiting forever on asynchronous suspend after abort Ben Hutchings
` (10 subsequent siblings)
48 siblings, 1 reply; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Alan Stern, Hans de Goede,
James E.J. Bottomley, Matthew Dharm, Greg Kroah-Hartman
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alan Stern <stern@rowland.harvard.edu>
commit 6a0bdffa0073857870a4ed1b4489762146359eb4 upstream.
Several bug reports have been received recently for USB mass-storage
devices that don't handle READ CAPACITY(16) commands properly. They
report bogus sizes, in some cases becoming unusable as a result.
The bugs were triggered by commit
09b6b51b0b6c1b9bb61815baf205e4d74c89ff04 (SCSI & usb-storage: add
flags for VPD pages and REPORT LUNS), which caused usb-storage to stop
overriding the SCSI level reported by devices. By default, the sd
driver will try READ CAPACITY(16) first for any device whose level is
above SCSI_SPC_2.
It seems likely that any device large enough to require the use of
READ CAPACITY(16) (i.e., 2 TB or more) would be able to handle READ
CAPACITY(10) commands properly. Indeed, I don't know of any devices
that don't handle READ CAPACITY(10) properly.
Therefore this patch (as1559) adds a new flag telling the sd driver
to try READ CAPACITY(10) before READ CAPACITY(16), and sets this flag
for every USB mass-storage device. If a device really is larger than
2 TB, sd will fall back to READ CAPACITY(16) just as it used to.
This fixes Bugzilla #43391.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Hans de Goede <hdegoede@redhat.com>
CC: "James E.J. Bottomley" <JBottomley@parallels.com>
CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/scsi/sd.c | 2 ++
drivers/usb/storage/scsiglue.c | 6 ++++++
include/scsi/scsi_device.h | 1 +
3 files changed, 9 insertions(+)
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 6f0a4c6..6f72b80 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -1899,6 +1899,8 @@ static int sd_try_rc16_first(struct scsi_device *sdp)
{
if (sdp->host->max_cmd_len < 16)
return 0;
+ if (sdp->try_rc_10_first)
+ return 0;
if (sdp->scsi_level > SCSI_SPC_2)
return 1;
if (scsi_device_protection(sdp))
diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c
index a324a5d..11418da 100644
--- a/drivers/usb/storage/scsiglue.c
+++ b/drivers/usb/storage/scsiglue.c
@@ -202,6 +202,12 @@ static int slave_configure(struct scsi_device *sdev)
if (us->fflags & US_FL_NO_READ_CAPACITY_16)
sdev->no_read_capacity_16 = 1;
+ /*
+ * Many devices do not respond properly to READ_CAPACITY_16.
+ * Tell the SCSI layer to try READ_CAPACITY_10 first.
+ */
+ sdev->try_rc_10_first = 1;
+
/* assume SPC3 or latter devices support sense size > 18 */
if (sdev->scsi_level > SCSI_SPC_2)
us->fflags |= US_FL_SANE_SENSE;
diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
index 6efb2e1..ba96988 100644
--- a/include/scsi/scsi_device.h
+++ b/include/scsi/scsi_device.h
@@ -151,6 +151,7 @@ struct scsi_device {
SD_LAST_BUGGY_SECTORS */
unsigned no_read_disc_info:1; /* Avoid READ_DISC_INFO cmds */
unsigned no_read_capacity_16:1; /* Avoid READ_CAPACITY_16 cmds */
+ unsigned try_rc_10_first:1; /* Try READ_CAPACACITY_10 first */
unsigned is_visible:1; /* is the device visible in sysfs */
DECLARE_BITMAP(supported_events, SDEV_EVT_MAXBITS); /* supported events */
^ permalink raw reply related [flat|nested] 78+ messages in thread* Re: [ 38/48] SCSI & usb-storage: add try_rc_10_first flag
2012-07-01 17:20 ` [ 38/48] SCSI & usb-storage: add try_rc_10_first flag Ben Hutchings
@ 2012-07-02 7:10 ` Hans de Goede
2012-07-02 18:52 ` Linus Torvalds
2012-07-04 4:39 ` Ben Hutchings
0 siblings, 2 replies; 78+ messages in thread
From: Hans de Goede @ 2012-07-02 7:10 UTC (permalink / raw)
To: Ben Hutchings
Cc: linux-kernel, stable, torvalds, akpm, alan, Alan Stern,
James E.J. Bottomley, Matthew Dharm, Greg Kroah-Hartman
Hi,
This patch is a better fix for the issue first fixed by:
"usb-storage: Add 090c:1000 to unusal-devs", so the same applies to
this patch, let me quote my reply to the stable-review for that patch:
"I'm not sure if this is needed with 3.2, it is needed with 3.4 because
recently the usb-storage driver was changed to report the supported
scsi level as reported by the device, rather then always report a
scsi level of 2. This change causes sd.c to try READ_CAPACITY(16)
first, which foobars up not only this one device, but as it turns
out a lot of others too, so we're working on another fix
(and I believe that 3.2 is unaffected)."
So since 3.2 already tries READ_CAPACITY(10) first, this patch is
not needed. It does not harm either, and if the scsi level reporting
change ever finds its way into 3.2 stable (which it should not
IMHO), then this patch will be needed.
Regards,
Hans
On 07/01/2012 07:20 PM, Ben Hutchings wrote:
> 3.2-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Alan Stern <stern@rowland.harvard.edu>
>
> commit 6a0bdffa0073857870a4ed1b4489762146359eb4 upstream.
>
> Several bug reports have been received recently for USB mass-storage
> devices that don't handle READ CAPACITY(16) commands properly. They
> report bogus sizes, in some cases becoming unusable as a result.
>
> The bugs were triggered by commit
> 09b6b51b0b6c1b9bb61815baf205e4d74c89ff04 (SCSI & usb-storage: add
> flags for VPD pages and REPORT LUNS), which caused usb-storage to stop
> overriding the SCSI level reported by devices. By default, the sd
> driver will try READ CAPACITY(16) first for any device whose level is
> above SCSI_SPC_2.
>
> It seems likely that any device large enough to require the use of
> READ CAPACITY(16) (i.e., 2 TB or more) would be able to handle READ
> CAPACITY(10) commands properly. Indeed, I don't know of any devices
> that don't handle READ CAPACITY(10) properly.
>
> Therefore this patch (as1559) adds a new flag telling the sd driver
> to try READ CAPACITY(10) before READ CAPACITY(16), and sets this flag
> for every USB mass-storage device. If a device really is larger than
> 2 TB, sd will fall back to READ CAPACITY(16) just as it used to.
>
> This fixes Bugzilla #43391.
>
> Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> Acked-by: Hans de Goede <hdegoede@redhat.com>
> CC: "James E.J. Bottomley" <JBottomley@parallels.com>
> CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> ---
> drivers/scsi/sd.c | 2 ++
> drivers/usb/storage/scsiglue.c | 6 ++++++
> include/scsi/scsi_device.h | 1 +
> 3 files changed, 9 insertions(+)
>
> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
> index 6f0a4c6..6f72b80 100644
> --- a/drivers/scsi/sd.c
> +++ b/drivers/scsi/sd.c
> @@ -1899,6 +1899,8 @@ static int sd_try_rc16_first(struct scsi_device *sdp)
> {
> if (sdp->host->max_cmd_len < 16)
> return 0;
> + if (sdp->try_rc_10_first)
> + return 0;
> if (sdp->scsi_level > SCSI_SPC_2)
> return 1;
> if (scsi_device_protection(sdp))
> diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c
> index a324a5d..11418da 100644
> --- a/drivers/usb/storage/scsiglue.c
> +++ b/drivers/usb/storage/scsiglue.c
> @@ -202,6 +202,12 @@ static int slave_configure(struct scsi_device *sdev)
> if (us->fflags & US_FL_NO_READ_CAPACITY_16)
> sdev->no_read_capacity_16 = 1;
>
> + /*
> + * Many devices do not respond properly to READ_CAPACITY_16.
> + * Tell the SCSI layer to try READ_CAPACITY_10 first.
> + */
> + sdev->try_rc_10_first = 1;
> +
> /* assume SPC3 or latter devices support sense size > 18 */
> if (sdev->scsi_level > SCSI_SPC_2)
> us->fflags |= US_FL_SANE_SENSE;
> diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
> index 6efb2e1..ba96988 100644
> --- a/include/scsi/scsi_device.h
> +++ b/include/scsi/scsi_device.h
> @@ -151,6 +151,7 @@ struct scsi_device {
> SD_LAST_BUGGY_SECTORS */
> unsigned no_read_disc_info:1; /* Avoid READ_DISC_INFO cmds */
> unsigned no_read_capacity_16:1; /* Avoid READ_CAPACITY_16 cmds */
> + unsigned try_rc_10_first:1; /* Try READ_CAPACACITY_10 first */
> unsigned is_visible:1; /* is the device visible in sysfs */
>
> DECLARE_BITMAP(supported_events, SDEV_EVT_MAXBITS); /* supported events */
>
>
^ permalink raw reply [flat|nested] 78+ messages in thread* Re: [ 38/48] SCSI & usb-storage: add try_rc_10_first flag
2012-07-02 7:10 ` Hans de Goede
@ 2012-07-02 18:52 ` Linus Torvalds
2012-07-02 20:39 ` James Bottomley
2012-07-04 4:39 ` Ben Hutchings
1 sibling, 1 reply; 78+ messages in thread
From: Linus Torvalds @ 2012-07-02 18:52 UTC (permalink / raw)
To: Hans de Goede
Cc: Ben Hutchings, linux-kernel, stable, akpm, alan, Alan Stern,
James E.J. Bottomley, Matthew Dharm, Greg Kroah-Hartman
On Mon, Jul 2, 2012 at 12:10 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>
> So since 3.2 already tries READ_CAPACITY(10) first, this patch is
> not needed. It does not harm either, and if the scsi level reporting
> change ever finds its way into 3.2 stable (which it should not
> IMHO), then this patch will be needed.
Yeah, it should definitely not make it into stable. In fact, I'd
rather remove it from mainline too. The whole idea to do
READ_CAPACITY_16 by default was moronic.
James? Why does the SCSI subsystem always do these idiotic defaults?
We *know* that devices are buggy. Sure, USB storage tends to be
buggier than most, but the whole idea of "let's use the new way of
reporting that gets almost no testing" is just wrong.
I don't think the USB layer should have needed to work around this. I
don't think there should be a "try_10b" flag at all. I think the SCSI
code should just *never* do the 16b version unless it has done the 10b
version first and determined that the size doesn't fit.
And the code already had that logic got the read_10b case. The whole
logic to do 16b by default was crap. It *used* to at least only do it
for disks that were marked as having "protection", now it wants to do
it for anything that should be able to handle it. Which is bogus. The
whole "let's assume devices get it right" mindset is broken.
The mindset should be "let's assume devices are buggy, and be careful".
Linus
^ permalink raw reply [flat|nested] 78+ messages in thread* Re: [ 38/48] SCSI & usb-storage: add try_rc_10_first flag
2012-07-02 18:52 ` Linus Torvalds
@ 2012-07-02 20:39 ` James Bottomley
0 siblings, 0 replies; 78+ messages in thread
From: James Bottomley @ 2012-07-02 20:39 UTC (permalink / raw)
To: Linus Torvalds
Cc: Hans de Goede, Ben Hutchings, linux-kernel, stable, akpm, alan,
Alan Stern, Matthew Dharm, Greg Kroah-Hartman, linux-scsi
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2708 bytes --]
On Mon, 2012-07-02 at 11:52 -0700, Linus Torvalds wrote:
> On Mon, Jul 2, 2012 at 12:10 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> >
> > So since 3.2 already tries READ_CAPACITY(10) first, this patch is
> > not needed. It does not harm either, and if the scsi level reporting
> > change ever finds its way into 3.2 stable (which it should not
> > IMHO), then this patch will be needed.
>
> Yeah, it should definitely not make it into stable. In fact, I'd
> rather remove it from mainline too. The whole idea to do
> READ_CAPACITY_16 by default was moronic.
>
> James? Why does the SCSI subsystem always do these idiotic defaults?
> We *know* that devices are buggy. Sure, USB storage tends to be
> buggier than most, but the whole idea of "let's use the new way of
> reporting that gets almost no testing" is just wrong.
It's not idiotic. It's, unfortunately, required by the standard to
check for protection capable devices. It's been this way for three
years or so. Martin Petersen did extensive testing of devices when we
changed it and doing RC16 first is hedged around by claiming support not
only for SCSI_3 but also for SBC_2 in your INQUIRY data.
The problem seems to be that when all the testing was done, USB was
still always returning SCSI_2 in the inquiry data, but this got changed
to allow pass through of the actual vendor information.
> I don't think the USB layer should have needed to work around this. I
> don't think there should be a "try_10b" flag at all. I think the SCSI
> code should just *never* do the 16b version unless it has done the 10b
> version first and determined that the size doesn't fit.
If we did that, we'd regress on all the enterprise class drives with DIF
and DIX.
> And the code already had that logic got the read_10b case. The whole
> logic to do 16b by default was crap. It *used* to at least only do it
> for disks that were marked as having "protection", now it wants to do
> it for anything that should be able to handle it. Which is bogus. The
> whole "let's assume devices get it right" mindset is broken.
>
> The mindset should be "let's assume devices are buggy, and be careful".
It still is, that's why we did extensive testing three years ago before
changing it.
If you have a solution that doesn't break all the enterprise devices but
works better for USB, I'm listening. I think the best thing might be to
whitelist the scsi revision pass through in USB, so only the UAS devices
which really, really claim to know what they're doing advertise advanced
features.
James
ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥
^ permalink raw reply [flat|nested] 78+ messages in thread* Re: [ 38/48] SCSI & usb-storage: add try_rc_10_first flag
@ 2012-07-02 20:39 ` James Bottomley
0 siblings, 0 replies; 78+ messages in thread
From: James Bottomley @ 2012-07-02 20:39 UTC (permalink / raw)
To: Linus Torvalds
Cc: Hans de Goede, Ben Hutchings, linux-kernel, stable, akpm, alan,
Alan Stern, Matthew Dharm, Greg Kroah-Hartman, linux-scsi
On Mon, 2012-07-02 at 11:52 -0700, Linus Torvalds wrote:
> On Mon, Jul 2, 2012 at 12:10 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> >
> > So since 3.2 already tries READ_CAPACITY(10) first, this patch is
> > not needed. It does not harm either, and if the scsi level reporting
> > change ever finds its way into 3.2 stable (which it should not
> > IMHO), then this patch will be needed.
>
> Yeah, it should definitely not make it into stable. In fact, I'd
> rather remove it from mainline too. The whole idea to do
> READ_CAPACITY_16 by default was moronic.
>
> James? Why does the SCSI subsystem always do these idiotic defaults?
> We *know* that devices are buggy. Sure, USB storage tends to be
> buggier than most, but the whole idea of "let's use the new way of
> reporting that gets almost no testing" is just wrong.
It's not idiotic. It's, unfortunately, required by the standard to
check for protection capable devices. It's been this way for three
years or so. Martin Petersen did extensive testing of devices when we
changed it and doing RC16 first is hedged around by claiming support not
only for SCSI_3 but also for SBC_2 in your INQUIRY data.
The problem seems to be that when all the testing was done, USB was
still always returning SCSI_2 in the inquiry data, but this got changed
to allow pass through of the actual vendor information.
> I don't think the USB layer should have needed to work around this. I
> don't think there should be a "try_10b" flag at all. I think the SCSI
> code should just *never* do the 16b version unless it has done the 10b
> version first and determined that the size doesn't fit.
If we did that, we'd regress on all the enterprise class drives with DIF
and DIX.
> And the code already had that logic got the read_10b case. The whole
> logic to do 16b by default was crap. It *used* to at least only do it
> for disks that were marked as having "protection", now it wants to do
> it for anything that should be able to handle it. Which is bogus. The
> whole "let's assume devices get it right" mindset is broken.
>
> The mindset should be "let's assume devices are buggy, and be careful".
It still is, that's why we did extensive testing three years ago before
changing it.
If you have a solution that doesn't break all the enterprise devices but
works better for USB, I'm listening. I think the best thing might be to
whitelist the scsi revision pass through in USB, so only the UAS devices
which really, really claim to know what they're doing advertise advanced
features.
James
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [ 38/48] SCSI & usb-storage: add try_rc_10_first flag
2012-07-02 20:39 ` James Bottomley
(?)
@ 2012-07-02 22:23 ` Linus Torvalds
2012-07-03 0:41 ` Matthew Wilcox
-1 siblings, 1 reply; 78+ messages in thread
From: Linus Torvalds @ 2012-07-02 22:23 UTC (permalink / raw)
To: James Bottomley
Cc: Hans de Goede, Ben Hutchings, linux-kernel, stable, akpm, alan,
Alan Stern, Matthew Dharm, Greg Kroah-Hartman, linux-scsi
On Mon, Jul 2, 2012 at 1:39 PM, James Bottomley
<jbottomley@parallels.com> wrote:
>
> It's not idiotic. It's, unfortunately, required by the standard to
> check for protection capable devices.
[.. dleted ]
> Martin Petersen did extensive testing of devices when we
> changed it and doing RC16 first is hedged around by claiming support not
> only for SCSI_3 but also for SBC_2 in your INQUIRY data.
Umm. That just smells like BS to me.
The "extensive testing" part was clearly not true, and it seems that
SCSI people sometimes forget that the biggest user (by *far*) is the
USB storage layer.
Also, your protection claim seems to be invalidated by the actual
code. Yes, it checks if the device claims to support protection. But
it *also* says "let's do that 16b command if "scsi_level >
SCSI_SPC_2". So your claim that it hedges around it by looking at the
inquiry data is pure crap. It's simply not true. Just look at the
code:
if (sdp->host->max_cmd_len < 16)
return 0;
if (sdp->try_rc_10_first)
return 0;
if (sdp->scsi_level > SCSI_SPC_2)
return 1;
if (scsi_device_protection(sdp))
return 1;
return 0;
Notice how for high enough scsi_levels, it never even gets to that
scsi_device_protection() check, which does indeed look into protection
data.
So no, I simply don't see the careful testing or the checking that you
claim exists.
Linus
^ permalink raw reply [flat|nested] 78+ messages in thread* Re: [ 38/48] SCSI & usb-storage: add try_rc_10_first flag
2012-07-02 22:23 ` Linus Torvalds
@ 2012-07-03 0:41 ` Matthew Wilcox
2012-07-03 6:18 ` James Bottomley
0 siblings, 1 reply; 78+ messages in thread
From: Matthew Wilcox @ 2012-07-03 0:41 UTC (permalink / raw)
To: Linus Torvalds
Cc: James Bottomley, Hans de Goede, Ben Hutchings, linux-kernel,
stable, akpm, alan, Alan Stern, Matthew Dharm,
Greg Kroah-Hartman, linux-scsi
On Mon, Jul 02, 2012 at 03:23:18PM -0700, Linus Torvalds wrote:
> > Martin Petersen did extensive testing of devices when we
> > changed it and doing RC16 first is hedged around by claiming support not
> > only for SCSI_3 but also for SBC_2 in your INQUIRY data.
>
> Umm. That just smells like BS to me.
>
> The "extensive testing" part was clearly not true, and it seems that
> SCSI people sometimes forget that the biggest user (by *far*) is the
> USB storage layer.
As James said, *at the time*, USB overrode the SBC_2 claims from USB
devices and forced them to be SCSI_2. So no amount of testing we did
would have uncovered this.
> Also, your protection claim seems to be invalidated by the actual
> code. Yes, it checks if the device claims to support protection. But
> it *also* says "let's do that 16b command if "scsi_level >
> SCSI_SPC_2". So your claim that it hedges around it by looking at the
> inquiry data is pure crap. It's simply not true. Just look at the
> code:
I wrote this code ... James' memory is off. What happened is that T10
in their infinite wisdom decided to put things like "supports TRIM" and
"is actually a 4k block size but fakes 512 byte blocks" in the Read
Capacity 16 results. So if we want to support those kinds of things
(and I think we do), then we need to send Read Capacity 16 to devices.
It's not about "enterprise features" at all, but about supporting the
next generation of standard consumer drives. I'm tempted to say the
USB Storage driver needs to go back to the way things were, because I
don't see any other way to fix this.
I have no idea what Windows is doing to support these features. That
might be a fruitful course of investigation.
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [ 38/48] SCSI & usb-storage: add try_rc_10_first flag
2012-07-03 0:41 ` Matthew Wilcox
@ 2012-07-03 6:18 ` James Bottomley
2012-07-03 15:49 ` Alan Stern
0 siblings, 1 reply; 78+ messages in thread
From: James Bottomley @ 2012-07-03 6:18 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Linus Torvalds, Hans de Goede, Ben Hutchings, linux-kernel,
stable, akpm, alan, Alan Stern, Matthew Dharm,
Greg Kroah-Hartman, linux-scsi
On Mon, 2012-07-02 at 18:41 -0600, Matthew Wilcox wrote:
> On Mon, Jul 02, 2012 at 03:23:18PM -0700, Linus Torvalds wrote:
> > > Martin Petersen did extensive testing of devices when we
> > > changed it and doing RC16 first is hedged around by claiming support not
> > > only for SCSI_3 but also for SBC_2 in your INQUIRY data.
> >
> > Umm. That just smells like BS to me.
> >
> > The "extensive testing" part was clearly not true, and it seems that
> > SCSI people sometimes forget that the biggest user (by *far*) is the
> > USB storage layer.
>
> As James said, *at the time*, USB overrode the SBC_2 claims from USB
> devices and forced them to be SCSI_2. So no amount of testing we did
> would have uncovered this.
>
> > Also, your protection claim seems to be invalidated by the actual
> > code. Yes, it checks if the device claims to support protection. But
> > it *also* says "let's do that 16b command if "scsi_level >
> > SCSI_SPC_2". So your claim that it hedges around it by looking at the
> > inquiry data is pure crap. It's simply not true. Just look at the
> > code:
>
> I wrote this code ... James' memory is off.
Yes, sorry about that ... should have looked in the git log instead of
going by memory at 01:00 after a long flight ...
> What happened is that T10
> in their infinite wisdom decided to put things like "supports TRIM" and
> "is actually a 4k block size but fakes 512 byte blocks" in the Read
> Capacity 16 results. So if we want to support those kinds of things
> (and I think we do), then we need to send Read Capacity 16 to devices.
>
> It's not about "enterprise features" at all, but about supporting the
> next generation of standard consumer drives. I'm tempted to say the
> USB Storage driver needs to go back to the way things were, because I
> don't see any other way to fix this.
But anyway, we're stuck ... we have to send RC16 first to support these
features. We did protest to T10 at the time, but to no avail.
> I have no idea what Windows is doing to support these features. That
> might be a fruitful course of investigation.
Hopefully one of the USB people can do this.
I still think a whitelist of USB devices sending proper SCSI level
information in the inquiry might be the best way forward.
James
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [ 38/48] SCSI & usb-storage: add try_rc_10_first flag
2012-07-03 6:18 ` James Bottomley
@ 2012-07-03 15:49 ` Alan Stern
2012-07-03 17:32 ` Matthew Wilcox
0 siblings, 1 reply; 78+ messages in thread
From: Alan Stern @ 2012-07-03 15:49 UTC (permalink / raw)
To: James Bottomley
Cc: Matthew Wilcox, Linus Torvalds, Hans de Goede, Ben Hutchings,
linux-kernel, stable, akpm, alan, Matthew Dharm,
Greg Kroah-Hartman, linux-scsi
On Tue, 3 Jul 2012, James Bottomley wrote:
> > What happened is that T10
> > in their infinite wisdom decided to put things like "supports TRIM" and
> > "is actually a 4k block size but fakes 512 byte blocks" in the Read
> > Capacity 16 results. So if we want to support those kinds of things
> > (and I think we do), then we need to send Read Capacity 16 to devices.
> >
> > It's not about "enterprise features" at all, but about supporting the
> > next generation of standard consumer drives. I'm tempted to say the
> > USB Storage driver needs to go back to the way things were, because I
> > don't see any other way to fix this.
>
> But anyway, we're stuck ... we have to send RC16 first to support these
> features. We did protest to T10 at the time, but to no avail.
Does it have to be sent _first_?
Or would it be okay to send _both_ commands and believe the RC10
capacity rather than the RC16 capacity if they differ?
> > I have no idea what Windows is doing to support these features. That
> > might be a fruitful course of investigation.
>
> Hopefully one of the USB people can do this.
>
> I still think a whitelist of USB devices sending proper SCSI level
> information in the inquiry might be the best way forward.
I'm doubtful. It wouldn't be at all surprising for devices to claim
they support a particular level when in fact they support some but not
all of the required commands. Then what do you do? Put them on the
whitelist because of the commands they support, or leave them off
because of the other ones? What happens later on when you decide to
use more of the required commands?
Alan Stern
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [ 38/48] SCSI & usb-storage: add try_rc_10_first flag
2012-07-03 15:49 ` Alan Stern
@ 2012-07-03 17:32 ` Matthew Wilcox
2012-07-03 19:50 ` Alan Stern
0 siblings, 1 reply; 78+ messages in thread
From: Matthew Wilcox @ 2012-07-03 17:32 UTC (permalink / raw)
To: Alan Stern
Cc: James Bottomley, Linus Torvalds, Hans de Goede, Ben Hutchings,
linux-kernel, stable, akpm, alan, Matthew Dharm,
Greg Kroah-Hartman, linux-scsi
On Tue, Jul 03, 2012 at 11:49:00AM -0400, Alan Stern wrote:
> On Tue, 3 Jul 2012, James Bottomley wrote:
>
> > > What happened is that T10
> > > in their infinite wisdom decided to put things like "supports TRIM" and
> > > "is actually a 4k block size but fakes 512 byte blocks" in the Read
> > > Capacity 16 results. So if we want to support those kinds of things
> > > (and I think we do), then we need to send Read Capacity 16 to devices.
> >
> > But anyway, we're stuck ... we have to send RC16 first to support these
> > features. We did protest to T10 at the time, but to no avail.
>
> Does it have to be sent _first_?
>
> Or would it be okay to send _both_ commands and believe the RC10
> capacity rather than the RC16 capacity if they differ?
I have no problem with doing that (and believing RC16 over RC10 if RC10
claims 0xffffffff, naturally). The problem, as I understand it, is that
some devices crash upon receiving RC16 rather than just returning nonsense.
> > I still think a whitelist of USB devices sending proper SCSI level
> > information in the inquiry might be the best way forward.
>
> I'm doubtful. It wouldn't be at all surprising for devices to claim
> they support a particular level when in fact they support some but not
> all of the required commands. Then what do you do? Put them on the
> whitelist because of the commands they support, or leave them off
> because of the other ones? What happens later on when you decide to
> use more of the required commands?
SCSI has a fairly extensive collection of black/white list flags already
... see scsi_devinfo.[ch].
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [ 38/48] SCSI & usb-storage: add try_rc_10_first flag
2012-07-03 17:32 ` Matthew Wilcox
@ 2012-07-03 19:50 ` Alan Stern
2012-07-03 20:07 ` James Bottomley
0 siblings, 1 reply; 78+ messages in thread
From: Alan Stern @ 2012-07-03 19:50 UTC (permalink / raw)
To: Matthew Wilcox
Cc: James Bottomley, Linus Torvalds, Hans de Goede, Ben Hutchings,
linux-kernel, stable, akpm, alan, Matthew Dharm,
Greg Kroah-Hartman, linux-scsi
On Tue, 3 Jul 2012, Matthew Wilcox wrote:
> On Tue, Jul 03, 2012 at 11:49:00AM -0400, Alan Stern wrote:
> > On Tue, 3 Jul 2012, James Bottomley wrote:
> >
> > > > What happened is that T10
> > > > in their infinite wisdom decided to put things like "supports TRIM" and
> > > > "is actually a 4k block size but fakes 512 byte blocks" in the Read
> > > > Capacity 16 results. So if we want to support those kinds of things
> > > > (and I think we do), then we need to send Read Capacity 16 to devices.
> > >
> > > But anyway, we're stuck ... we have to send RC16 first to support these
> > > features. We did protest to T10 at the time, but to no avail.
> >
> > Does it have to be sent _first_?
> >
> > Or would it be okay to send _both_ commands and believe the RC10
> > capacity rather than the RC16 capacity if they differ?
>
> I have no problem with doing that (and believing RC16 over RC10 if RC10
> claims 0xffffffff, naturally). The problem, as I understand it, is that
> some devices crash upon receiving RC16 rather than just returning nonsense.
No, that's not the problem we're talking about here. While it is true
that some devices crash upon receiving RC16, so far we haven't been
sending RC16 to those devices, so they don't matter for the purposes of
this discussion.
In fact, usb-storage already has a NO_READ_CAPACITY_16 flag. It was
introduced because of a card reader that mistakenly attempts to return
an actual capacity value even when no card is present: It takes the
number of sectors -- which is 0 -- and subtracts 1 as usual. You can
imagine what happens next. :-) That's the only device which
currently has this flag.
The reason for the try_rc_10_first flag is that some devices return
bogus data in response to RC16. Like, an 800 GB device claiming to
have 3 exabytes.
Alan Stern
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [ 38/48] SCSI & usb-storage: add try_rc_10_first flag
2012-07-03 19:50 ` Alan Stern
@ 2012-07-03 20:07 ` James Bottomley
2012-07-03 20:25 ` Alan Stern
2012-07-03 20:35 ` Matthew Wilcox
0 siblings, 2 replies; 78+ messages in thread
From: James Bottomley @ 2012-07-03 20:07 UTC (permalink / raw)
To: Alan Stern
Cc: Matthew Wilcox, Linus Torvalds, Hans de Goede, Ben Hutchings,
linux-kernel, stable, akpm, alan, Matthew Dharm,
Greg Kroah-Hartman, linux-scsi
On Tue, 2012-07-03 at 15:50 -0400, Alan Stern wrote:
> On Tue, 3 Jul 2012, Matthew Wilcox wrote:
>
> > On Tue, Jul 03, 2012 at 11:49:00AM -0400, Alan Stern wrote:
> > > On Tue, 3 Jul 2012, James Bottomley wrote:
> > >
> > > > > What happened is that T10
> > > > > in their infinite wisdom decided to put things like "supports TRIM" and
> > > > > "is actually a 4k block size but fakes 512 byte blocks" in the Read
> > > > > Capacity 16 results. So if we want to support those kinds of things
> > > > > (and I think we do), then we need to send Read Capacity 16 to devices.
> > > >
> > > > But anyway, we're stuck ... we have to send RC16 first to support these
> > > > features. We did protest to T10 at the time, but to no avail.
> > >
> > > Does it have to be sent _first_?
> > >
> > > Or would it be okay to send _both_ commands and believe the RC10
> > > capacity rather than the RC16 capacity if they differ?
> >
> > I have no problem with doing that (and believing RC16 over RC10 if RC10
> > claims 0xffffffff, naturally). The problem, as I understand it, is that
> > some devices crash upon receiving RC16 rather than just returning nonsense.
>
> No, that's not the problem we're talking about here. While it is true
> that some devices crash upon receiving RC16, so far we haven't been
> sending RC16 to those devices, so they don't matter for the purposes of
> this discussion.
>
> In fact, usb-storage already has a NO_READ_CAPACITY_16 flag. It was
> introduced because of a card reader that mistakenly attempts to return
> an actual capacity value even when no card is present: It takes the
> number of sectors -- which is 0 -- and subtracts 1 as usual. You can
> imagine what happens next. :-) That's the only device which
> currently has this flag.
>
> The reason for the try_rc_10_first flag is that some devices return
> bogus data in response to RC16. Like, an 800 GB device claiming to
> have 3 exabytes.
So we could easily send both and only believe RC10 if the device is
under 2TB. However, what about all the extra flags we read out of RC16,
like trim, large sector size and DIF capability? If the device lies
about its capacity, won't we get bogus values for those as well, which
is going to cause other screw ups?
James
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [ 38/48] SCSI & usb-storage: add try_rc_10_first flag
2012-07-03 20:07 ` James Bottomley
@ 2012-07-03 20:25 ` Alan Stern
2012-07-03 20:35 ` Matthew Wilcox
1 sibling, 0 replies; 78+ messages in thread
From: Alan Stern @ 2012-07-03 20:25 UTC (permalink / raw)
To: James Bottomley
Cc: Matthew Wilcox, Linus Torvalds, Hans de Goede, Ben Hutchings,
linux-kernel, stable, akpm, alan, Matthew Dharm,
Greg Kroah-Hartman, linux-scsi
On Wed, 4 Jul 2012, James Bottomley wrote:
> > The reason for the try_rc_10_first flag is that some devices return
> > bogus data in response to RC16. Like, an 800 GB device claiming to
> > have 3 exabytes.
>
> So we could easily send both and only believe RC10 if the device is
> under 2TB.
More precisely, if RC10 indicates the device is under 2 TB then ignore
the RC16 capacity. Or maybe issue a warning if it disagrees with the
RC10 capacity.
> However, what about all the extra flags we read out of RC16,
> like trim, large sector size and DIF capability? If the device lies
> about its capacity, won't we get bogus values for those as well, which
> is going to cause other screw ups?
That seems quite likely. I don't know the answer for any individual
cases, however.
For the greatest safety, I suppose we could disbelieve all the fields
in the RC16 response if the RC16 capacity disagrees with the RC10
capacity and the RC10 capacity is under 2 TB.
Alan Stern
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [ 38/48] SCSI & usb-storage: add try_rc_10_first flag
2012-07-03 20:07 ` James Bottomley
2012-07-03 20:25 ` Alan Stern
@ 2012-07-03 20:35 ` Matthew Wilcox
2012-07-05 21:40 ` Alan Stern
1 sibling, 1 reply; 78+ messages in thread
From: Matthew Wilcox @ 2012-07-03 20:35 UTC (permalink / raw)
To: James Bottomley
Cc: Alan Stern, Linus Torvalds, Hans de Goede, Ben Hutchings,
linux-kernel, stable, akpm, alan, Matthew Dharm,
Greg Kroah-Hartman, linux-scsi
On Wed, Jul 04, 2012 at 12:07:52AM +0400, James Bottomley wrote:
> > The reason for the try_rc_10_first flag is that some devices return
> > bogus data in response to RC16. Like, an 800 GB device claiming to
> > have 3 exabytes.
>
> So we could easily send both and only believe RC10 if the device is
> under 2TB. However, what about all the extra flags we read out of RC16,
> like trim, large sector size and DIF capability? If the device lies
> about its capacity, won't we get bogus values for those as well, which
> is going to cause other screw ups?
I think the necessary algorithm is simpler than that:
Send RC10 (unless the device supports PI, in which case it's probably
enterprisey and well-tested)
Send RC16
If RC10 capacity agrees with RC16 capacity, use extra RC16 data.
(for values of "agrees with" that include the "-1 to use RC16" indicator)
Sure, it's one extra command, but really, who cares?
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [ 38/48] SCSI & usb-storage: add try_rc_10_first flag
2012-07-03 20:35 ` Matthew Wilcox
@ 2012-07-05 21:40 ` Alan Stern
2012-07-06 3:05 ` Matthew Wilcox
0 siblings, 1 reply; 78+ messages in thread
From: Alan Stern @ 2012-07-05 21:40 UTC (permalink / raw)
To: Matthew Wilcox
Cc: James Bottomley, Linus Torvalds, Hans de Goede, Ben Hutchings,
linux-kernel, stable, akpm, alan, Matthew Dharm,
Greg Kroah-Hartman, linux-scsi
On Tue, 3 Jul 2012, Matthew Wilcox wrote:
> I think the necessary algorithm is simpler than that:
>
> Send RC10 (unless the device supports PI, in which case it's probably
> enterprisey and well-tested)
> Send RC16
> If RC10 capacity agrees with RC16 capacity, use extra RC16 data.
> (for values of "agrees with" that include the "-1 to use RC16" indicator)
>
> Sure, it's one extra command, but really, who cares?
Well, some USB devices might care. Right now we don't send RC16 to
them at all because they get RC10 first and it indicates a capacity
below 2 TB.
In the end, usb-storage may be forced to use the NO_READ_CAPACITY_16
flag with all devices except those we can positively identify as a
USB-(S)ATA bridge.
Alan Stern
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [ 38/48] SCSI & usb-storage: add try_rc_10_first flag
2012-07-05 21:40 ` Alan Stern
@ 2012-07-06 3:05 ` Matthew Wilcox
2012-07-06 14:00 ` Alan Stern
0 siblings, 1 reply; 78+ messages in thread
From: Matthew Wilcox @ 2012-07-06 3:05 UTC (permalink / raw)
To: Alan Stern
Cc: James Bottomley, Linus Torvalds, Hans de Goede, Ben Hutchings,
linux-kernel, stable, akpm, alan, Matthew Dharm,
Greg Kroah-Hartman, linux-scsi
On Thu, Jul 05, 2012 at 05:40:45PM -0400, Alan Stern wrote:
> On Tue, 3 Jul 2012, Matthew Wilcox wrote:
>
> > I think the necessary algorithm is simpler than that:
> >
> > Send RC10 (unless the device supports PI, in which case it's probably
> > enterprisey and well-tested)
> > Send RC16
> > If RC10 capacity agrees with RC16 capacity, use extra RC16 data.
> > (for values of "agrees with" that include the "-1 to use RC16" indicator)
> >
> > Sure, it's one extra command, but really, who cares?
>
> Well, some USB devices might care. Right now we don't send RC16 to
> them at all because they get RC10 first and it indicates a capacity
> below 2 TB.
Mmm. I think I forgot a step:
Send RC10 (unless the device supports PI, in which case it's probably
enterprisey and well-tested)
If the device indicates a level < SPC_2, stop here
Send RC16
If RC10 capacity agrees with RC16 capacity, use extra RC16 data.
(for values of "agrees with" that include the "-1 to use RC16" indicator)
> In the end, usb-storage may be forced to use the NO_READ_CAPACITY_16
> flag with all devices except those we can positively identify as a
> USB-(S)ATA bridge.
Is that really an improvement over nobbling the IDENTIFY results to
force SCSI_2?
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [ 38/48] SCSI & usb-storage: add try_rc_10_first flag
2012-07-06 3:05 ` Matthew Wilcox
@ 2012-07-06 14:00 ` Alan Stern
0 siblings, 0 replies; 78+ messages in thread
From: Alan Stern @ 2012-07-06 14:00 UTC (permalink / raw)
To: Matthew Wilcox
Cc: James Bottomley, Linus Torvalds, Hans de Goede, Ben Hutchings,
linux-kernel, stable, akpm, alan, Matthew Dharm,
Greg Kroah-Hartman, linux-scsi
On Thu, 5 Jul 2012, Matthew Wilcox wrote:
> > > Sure, it's one extra command, but really, who cares?
> >
> > Well, some USB devices might care. Right now we don't send RC16 to
> > them at all because they get RC10 first and it indicates a capacity
> > below 2 TB.
>
> Mmm. I think I forgot a step:
>
> Send RC10 (unless the device supports PI, in which case it's probably
> enterprisey and well-tested)
> If the device indicates a level < SPC_2, stop here
> Send RC16
> If RC10 capacity agrees with RC16 capacity, use extra RC16 data.
> (for values of "agrees with" that include the "-1 to use RC16" indicator)
That might or might not work. I don't know for certain, but it's
possible that some USB devices do claim a level > SPC_2 and yet can't
handle RC16. Of course, we can always set the NO_READ_CAPACITY_16
flags for these devices as they crop up.
> > In the end, usb-storage may be forced to use the NO_READ_CAPACITY_16
> > flag with all devices except those we can positively identify as a
> > USB-(S)ATA bridge.
>
> Is that really an improvement over nobbling the IDENTIFY results to
> force SCSI_2?
Yes. There was a good reason for getting rid of that change to the
INQUIRY result (some devices don't like it when the LUN bits are
stuffed into the second byte of each CDB), and I don't want to go back.
Alan Stern
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [ 38/48] SCSI & usb-storage: add try_rc_10_first flag
2012-07-02 7:10 ` Hans de Goede
2012-07-02 18:52 ` Linus Torvalds
@ 2012-07-04 4:39 ` Ben Hutchings
1 sibling, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-04 4:39 UTC (permalink / raw)
To: Hans de Goede
Cc: linux-kernel, stable, torvalds, akpm, alan, Alan Stern,
James E.J. Bottomley, Matthew Dharm, Greg Kroah-Hartman
[-- Attachment #1: Type: text/plain, Size: 1325 bytes --]
On Mon, 2012-07-02 at 09:10 +0200, Hans de Goede wrote:
> Hi,
>
> This patch is a better fix for the issue first fixed by:
> "usb-storage: Add 090c:1000 to unusal-devs", so the same applies to
> this patch, let me quote my reply to the stable-review for that patch:
>
> "I'm not sure if this is needed with 3.2, it is needed with 3.4 because
> recently the usb-storage driver was changed to report the supported
> scsi level as reported by the device, rather then always report a
> scsi level of 2. This change causes sd.c to try READ_CAPACITY(16)
> first, which foobars up not only this one device, but as it turns
> out a lot of others too, so we're working on another fix
> (and I believe that 3.2 is unaffected)."
>
> So since 3.2 already tries READ_CAPACITY(10) first, this patch is
> not needed. It does not harm either, and if the scsi level reporting
> change ever finds its way into 3.2 stable (which it should not
> IMHO), then this patch will be needed.
[...]
Thanks for the explanation. Given this and the subsequent discussion,
I've dropped the patch and assume no changes along these lines will be
needed for 3.2.y. (But that doesn't mean I'll necessarily spot and
filter out any such changes myself.)
Ben.
--
Ben Hutchings
When in doubt, use brute force. - Ken Thompson
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply [flat|nested] 78+ messages in thread
* [ 39/48] PM / Sleep: Prevent waiting forever on asynchronous suspend after abort
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (37 preceding siblings ...)
2012-07-01 17:20 ` [ 38/48] SCSI & usb-storage: add try_rc_10_first flag Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 40/48] x86, cpufeature: Rename X86_FEATURE_DTS to X86_FEATURE_DTHERM Ben Hutchings
` (9 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Mandeep Singh Baines, Rafael J. Wysocki
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mandeep Singh Baines <msb@chromium.org>
commit 1f758b23177d588a71b96ad02990e715949bb82f upstream.
__device_suspend() must always send a completion. Otherwise, parent
devices will wait forever.
Commit 1e2ef05b, "PM: Limit race conditions between runtime PM and
system sleep (v2)", introduced a regression by short-circuiting the
complete_all() for certain error cases.
This patch fixes the bug by always signalling a completion.
Addresses http://crosbug.com/31972
Tested by injecting an abort.
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/base/power/main.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index e0fb5b0..9cb845e 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -1031,7 +1031,7 @@ static int __device_suspend(struct device *dev, pm_message_t state, bool async)
dpm_wait_for_children(dev, async);
if (async_error)
- return 0;
+ goto Complete;
pm_runtime_get_noresume(dev);
if (pm_runtime_barrier(dev) && device_may_wakeup(dev))
@@ -1040,7 +1040,7 @@ static int __device_suspend(struct device *dev, pm_message_t state, bool async)
if (pm_wakeup_pending()) {
pm_runtime_put_sync(dev);
async_error = -EBUSY;
- return 0;
+ goto Complete;
}
device_lock(dev);
@@ -1097,6 +1097,8 @@ static int __device_suspend(struct device *dev, pm_message_t state, bool async)
}
device_unlock(dev);
+
+ Complete:
complete_all(&dev->power.completion);
if (error) {
^ permalink raw reply related [flat|nested] 78+ messages in thread* [ 40/48] x86, cpufeature: Rename X86_FEATURE_DTS to X86_FEATURE_DTHERM
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (38 preceding siblings ...)
2012-07-01 17:20 ` [ 39/48] PM / Sleep: Prevent waiting forever on asynchronous suspend after abort Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 41/48] stable: Allow merging of backports for serious user-visible performance issues Ben Hutchings
` (8 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, H. Peter Anvin, Jean Delvare, Jan Beulich
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: "H. Peter Anvin" <hpa@linux.intel.com>
commit 4ad33411308596f2f918603509729922a1ec4411 upstream.
It makes sense to label "Digital Thermal Sensor" as "DTS", but
unfortunately the string "dts" was already used for "Debug Store", and
/proc/cpuinfo is a user space ABI.
Therefore, rename this to "dtherm".
This conflict went into mainline via the hwmon tree without any x86
maintainer ack, and without any kind of hint in the subject.
a4659053 x86/hwmon: fix initialization of coretemp
Reported-by: Jean Delvare <khali@linux-fr.org>
Link: http://lkml.kernel.org/r/4FE34BCB.5050305@linux.intel.com
Cc: Jan Beulich <JBeulich@suse.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
[bwh: Backported to 3.2: drop the coretemp device table change]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
arch/x86/include/asm/cpufeature.h | 2 +-
arch/x86/kernel/cpu/scattered.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -175,7 +175,7 @@
#define X86_FEATURE_XSAVEOPT (7*32+ 4) /* Optimized Xsave */
#define X86_FEATURE_PLN (7*32+ 5) /* Intel Power Limit Notification */
#define X86_FEATURE_PTS (7*32+ 6) /* Intel Package Thermal Status */
-#define X86_FEATURE_DTS (7*32+ 7) /* Digital Thermal Sensor */
+#define X86_FEATURE_DTHERM (7*32+ 7) /* Digital Thermal Sensor */
/* Virtualization flags: Linux defined, word 8 */
#define X86_FEATURE_TPR_SHADOW (8*32+ 0) /* Intel TPR Shadow */
--- a/arch/x86/kernel/cpu/scattered.c
+++ b/arch/x86/kernel/cpu/scattered.c
@@ -31,7 +31,7 @@
const struct cpuid_bit *cb;
static const struct cpuid_bit __cpuinitconst cpuid_bits[] = {
- { X86_FEATURE_DTS, CR_EAX, 0, 0x00000006, 0 },
+ { X86_FEATURE_DTHERM, CR_EAX, 0, 0x00000006, 0 },
{ X86_FEATURE_IDA, CR_EAX, 1, 0x00000006, 0 },
{ X86_FEATURE_ARAT, CR_EAX, 2, 0x00000006, 0 },
{ X86_FEATURE_PLN, CR_EAX, 4, 0x00000006, 0 },
--- a/drivers/hwmon/coretemp.c
+++ b/drivers/hwmon/coretemp.c
@@ -660,7 +660,7 @@
* sensors. We check this bit only, all the early CPUs
* without thermal sensors will be filtered out.
*/
- if (!cpu_has(c, X86_FEATURE_DTS))
+ if (!cpu_has(c, X86_FEATURE_DTHERM))
return;
if (!pdev) {
^ permalink raw reply [flat|nested] 78+ messages in thread* [ 41/48] stable: Allow merging of backports for serious user-visible performance issues
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (39 preceding siblings ...)
2012-07-01 17:20 ` [ 40/48] x86, cpufeature: Rename X86_FEATURE_DTS to X86_FEATURE_DTHERM Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 42/48] ALSA: hda - Add Realtek ALC280 codec support Ben Hutchings
` (7 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: torvalds, akpm, alan, Mel Gorman, Greg Kroah-Hartman
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mel Gorman <mgorman@suse.de>
commit eb3979f64d25120d60b9e761a4c58f70b1a02f86 upstream.
Distribution kernel maintainers routinely backport fixes for users that
were deemed important but not "something critical" as defined by the
rules. To users of these kernels they are very serious and failing to fix
them reduces the value of -stable.
The problem is that the patches fixing these issues are often subtle and
prone to regressions in other ways and need greater care and attention.
To combat this, these "serious" backports should have a higher barrier
to entry.
This patch relaxes the rules to allow a distribution maintainer to merge
to -stable a backported patch or small series that fixes a "serious"
user-visible performance issue. They should include additional information on
the user-visible bug affected and a link to the bugzilla entry if available.
The same rules about the patch being already in mainline still apply.
Signed-off-by: Mel Gorman <mgorman@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
Documentation/stable_kernel_rules.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/stable_kernel_rules.txt b/Documentation/stable_kernel_rules.txt
index f0ab5cf..4a7b54b 100644
--- a/Documentation/stable_kernel_rules.txt
+++ b/Documentation/stable_kernel_rules.txt
@@ -12,6 +12,12 @@ Rules on what kind of patches are accepted, and which ones are not, into the
marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
security issue, or some "oh, that's not good" issue. In short, something
critical.
+ - Serious issues as reported by a user of a distribution kernel may also
+ be considered if they fix a notable performance or interactivity issue.
+ As these fixes are not as obvious and have a higher risk of a subtle
+ regression they should only be submitted by a distribution kernel
+ maintainer and include an addendum linking to a bugzilla entry if it
+ exists and additional information on the user-visible impact.
- New device IDs and quirks are also accepted.
- No "theoretical race condition" issues, unless an explanation of how the
race can be exploited is also provided.
^ permalink raw reply related [flat|nested] 78+ messages in thread* [ 42/48] ALSA: hda - Add Realtek ALC280 codec support
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (40 preceding siblings ...)
2012-07-01 17:20 ` [ 41/48] stable: Allow merging of backports for serious user-visible performance issues Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 43/48] USB: option: Add USB ID for Novatel Ovation MC551 Ben Hutchings
` (6 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, David Henningsson, Richard Crossley, Takashi Iwai
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Henningsson <david.henningsson@canonical.com>
commit befae82e2906cb7155020876a531b0b8c6c8d8c8 upstream.
This chip looks very similar to ALC269 and ALC27* variants. The bug reporter
has verified that sound was working after this patch had been applied.
BugLink: https://bugs.launchpad.net/bugs/1017017
Tested-by: Richard Crossley <richardcrossley@o2.co.uk>
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 41475ae..a5534b3 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6800,6 +6800,7 @@ static const struct hda_codec_preset snd_hda_preset_realtek[] = {
{ .id = 0x10ec0272, .name = "ALC272", .patch = patch_alc662 },
{ .id = 0x10ec0275, .name = "ALC275", .patch = patch_alc269 },
{ .id = 0x10ec0276, .name = "ALC276", .patch = patch_alc269 },
+ { .id = 0x10ec0280, .name = "ALC280", .patch = patch_alc269 },
{ .id = 0x10ec0861, .rev = 0x100340, .name = "ALC660",
.patch = patch_alc861 },
{ .id = 0x10ec0660, .name = "ALC660-VD", .patch = patch_alc861vd },
^ permalink raw reply related [flat|nested] 78+ messages in thread* [ 43/48] USB: option: Add USB ID for Novatel Ovation MC551
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (41 preceding siblings ...)
2012-07-01 17:20 ` [ 42/48] ALSA: hda - Add Realtek ALC280 codec support Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 44/48] USB: CP210x Add 10 Device IDs Ben Hutchings
` (5 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Forest Bond, Dan Williams, Greg Kroah-Hartman
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Forest Bond <forest.bond@rapidrollout.com>
commit 065b07e7a14676f4138ce4619d229c0be5a74230 upstream.
This device is also known as the Verizon USB551L.
Signed-off-by: Forest Bond <forest.bond@rapidrollout.com>
Acked-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/usb/serial/option.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 396d968..adf8ce7 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -236,6 +236,7 @@ static void option_instat_callback(struct urb *urb);
#define NOVATELWIRELESS_PRODUCT_G1 0xA001
#define NOVATELWIRELESS_PRODUCT_G1_M 0xA002
#define NOVATELWIRELESS_PRODUCT_G2 0xA010
+#define NOVATELWIRELESS_PRODUCT_MC551 0xB001
/* AMOI PRODUCTS */
#define AMOI_VENDOR_ID 0x1614
@@ -738,6 +739,8 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_G1) },
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_G1_M) },
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_G2) },
+ /* Novatel Ovation MC551 a.k.a. Verizon USB551L */
+ { USB_DEVICE_AND_INTERFACE_INFO(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_MC551, 0xff, 0xff, 0xff) },
{ USB_DEVICE(AMOI_VENDOR_ID, AMOI_PRODUCT_H01) },
{ USB_DEVICE(AMOI_VENDOR_ID, AMOI_PRODUCT_H01A) },
^ permalink raw reply related [flat|nested] 78+ messages in thread* [ 44/48] USB: CP210x Add 10 Device IDs
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (42 preceding siblings ...)
2012-07-01 17:20 ` [ 43/48] USB: option: Add USB ID for Novatel Ovation MC551 Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 45/48] xen/netfront: teardown the device before unregistering it Ben Hutchings
` (4 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Craig Shelley, Greg Kroah-Hartman
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Craig Shelley <craig@microtron.org.uk>
commit 3fcc8f96829776cf181918461923d1e3bbb831a2 upstream.
This patch adds 10 device IDs for CP210x based devices from the following manufacturers:
Timewave
Clipsal
Festo
Link Instruments
Signed-off-by: Craig Shelley <craig@microtron.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/usb/serial/cp210x.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index 73d25cd..1e71079 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -93,6 +93,7 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x10C4, 0x814B) }, /* West Mountain Radio RIGtalk */
{ USB_DEVICE(0x10C4, 0x8156) }, /* B&G H3000 link cable */
{ USB_DEVICE(0x10C4, 0x815E) }, /* Helicomm IP-Link 1220-DVM */
+ { USB_DEVICE(0x10C4, 0x815F) }, /* Timewave HamLinkUSB */
{ USB_DEVICE(0x10C4, 0x818B) }, /* AVIT Research USB to TTL */
{ USB_DEVICE(0x10C4, 0x819F) }, /* MJS USB Toslink Switcher */
{ USB_DEVICE(0x10C4, 0x81A6) }, /* ThinkOptics WavIt */
@@ -134,7 +135,13 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x10CE, 0xEA6A) }, /* Silicon Labs MobiData GPRS USB Modem 100EU */
{ USB_DEVICE(0x13AD, 0x9999) }, /* Baltech card reader */
{ USB_DEVICE(0x1555, 0x0004) }, /* Owen AC4 USB-RS485 Converter */
+ { USB_DEVICE(0x166A, 0x0201) }, /* Clipsal 5500PACA C-Bus Pascal Automation Controller */
+ { USB_DEVICE(0x166A, 0x0301) }, /* Clipsal 5800PC C-Bus Wireless PC Interface */
{ USB_DEVICE(0x166A, 0x0303) }, /* Clipsal 5500PCU C-Bus USB interface */
+ { USB_DEVICE(0x166A, 0x0304) }, /* Clipsal 5000CT2 C-Bus Black and White Touchscreen */
+ { USB_DEVICE(0x166A, 0x0305) }, /* Clipsal C-5000CT2 C-Bus Spectrum Colour Touchscreen */
+ { USB_DEVICE(0x166A, 0x0401) }, /* Clipsal L51xx C-Bus Architectural Dimmer */
+ { USB_DEVICE(0x166A, 0x0101) }, /* Clipsal 5560884 C-Bus Multi-room Audio Matrix Switcher */
{ USB_DEVICE(0x16D6, 0x0001) }, /* Jablotron serial interface */
{ USB_DEVICE(0x16DC, 0x0010) }, /* W-IE-NE-R Plein & Baus GmbH PL512 Power Supply */
{ USB_DEVICE(0x16DC, 0x0011) }, /* W-IE-NE-R Plein & Baus GmbH RCM Remote Control for MARATON Power Supply */
@@ -146,7 +153,11 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x1843, 0x0200) }, /* Vaisala USB Instrument Cable */
{ USB_DEVICE(0x18EF, 0xE00F) }, /* ELV USB-I2C-Interface */
{ USB_DEVICE(0x1BE3, 0x07A6) }, /* WAGO 750-923 USB Service Cable */
+ { USB_DEVICE(0x1E29, 0x0102) }, /* Festo CPX-USB */
+ { USB_DEVICE(0x1E29, 0x0501) }, /* Festo CMSP */
{ USB_DEVICE(0x3195, 0xF190) }, /* Link Instruments MSO-19 */
+ { USB_DEVICE(0x3195, 0xF280) }, /* Link Instruments MSO-28 */
+ { USB_DEVICE(0x3195, 0xF281) }, /* Link Instruments MSO-28 */
{ USB_DEVICE(0x413C, 0x9500) }, /* DW700 GPS USB interface */
{ } /* Terminating Entry */
};
^ permalink raw reply related [flat|nested] 78+ messages in thread* [ 45/48] xen/netfront: teardown the device before unregistering it.
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (43 preceding siblings ...)
2012-07-01 17:20 ` [ 44/48] USB: CP210x Add 10 Device IDs Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 46/48] can: flexcan: use be32_to_cpup to handle the value of dt entry Ben Hutchings
` (3 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Ian Campbell, George Shuklin, Ian Campbell,
William Dauchy, David S. Miller
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ian Campbell <Ian.Campbell@citrix.com>
commit 6bc96d047fe32d76ef79f3195c52a542edf7c705 upstream.
Fixes:
[ 15.470311] WARNING: at /local/scratch/ianc/devel/kernels/linux/fs/sysfs/file.c:498 sysfs_attr_ns+0x95/0xa0()
[ 15.470326] sysfs: kobject eth0 without dirent
[ 15.470333] Modules linked in:
[ 15.470342] Pid: 12, comm: xenwatch Not tainted 3.4.0-x86_32p-xenU #93
and
[ 9.150554] BUG: unable to handle kernel paging request at 2b359000
[ 9.150577] IP: [<c1279561>] linkwatch_do_dev+0x81/0xc0
[ 9.150592] *pdpt = 000000002c3c9027 *pde = 0000000000000000
[ 9.150604] Oops: 0002 [#1] SMP
[ 9.150613] Modules linked in:
This is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675190
Reported-by: George Shuklin <george.shuklin@gmail.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Tested-by: William Dauchy <wdauchy@gmail.com>
Cc: 675190@bugs.debian.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/net/xen-netfront.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 2027afe..3089990 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1935,14 +1935,14 @@ static int __devexit xennet_remove(struct xenbus_device *dev)
dev_dbg(&dev->dev, "%s\n", dev->nodename);
- unregister_netdev(info->netdev);
-
xennet_disconnect_backend(info);
- del_timer_sync(&info->rx_refill_timer);
-
xennet_sysfs_delif(info->netdev);
+ unregister_netdev(info->netdev);
+
+ del_timer_sync(&info->rx_refill_timer);
+
free_percpu(info->stats);
free_netdev(info->netdev);
^ permalink raw reply related [flat|nested] 78+ messages in thread* [ 46/48] can: flexcan: use be32_to_cpup to handle the value of dt entry
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (44 preceding siblings ...)
2012-07-01 17:20 ` [ 45/48] xen/netfront: teardown the device before unregistering it Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 47/48] acpi_pad: fix power_saving thread deadlock Ben Hutchings
` (2 subsequent siblings)
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Hui Wang, Shawn Guo, Marc Kleine-Budde
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hui Wang <jason77.wang@gmail.com>
commit 85f2f834e85517307f13e30e630a5fc86f757cb5 upstream.
The freescale arm i.MX series platform can support this driver, and
usually the arm cpu works in the little endian mode by default, while
device tree entry value is stored in big endian format, we should use
be32_to_cpup() to handle them, after modification, it can work well
both on the le cpu and be cpu.
Cc: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Hui Wang <jason77.wang@gmail.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/net/can/flexcan.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -933,12 +933,12 @@
u32 clock_freq = 0;
if (pdev->dev.of_node) {
- const u32 *clock_freq_p;
+ const __be32 *clock_freq_p;
clock_freq_p = of_get_property(pdev->dev.of_node,
"clock-frequency", NULL);
if (clock_freq_p)
- clock_freq = *clock_freq_p;
+ clock_freq = be32_to_cpup(clock_freq_p);
}
if (!clock_freq) {
^ permalink raw reply [flat|nested] 78+ messages in thread* [ 47/48] acpi_pad: fix power_saving thread deadlock
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (45 preceding siblings ...)
2012-07-01 17:20 ` [ 46/48] can: flexcan: use be32_to_cpup to handle the value of dt entry Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 17:20 ` [ 48/48] batman-adv: only drop packets of known wifi clients Ben Hutchings
2012-07-01 19:11 ` [ 00/48] 3.2.22-stable review Ben Hutchings
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: torvalds, akpm, alan, Stuart Hayes, Len Brown
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stuart Hayes <Stuart_Hayes@Dell.com>
commit 5f1601261050251a5ca293378b492a69d590dacb upstream.
The acpi_pad driver can get stuck in destroy_power_saving_task()
waiting for kthread_stop() to stop a power_saving thread. The problem
is that the isolated_cpus_lock mutex is owned when
destroy_power_saving_task() calls kthread_stop(), which waits for a
power_saving thread to end, and the power_saving thread tries to
acquire the isolated_cpus_lock when it calls round_robin_cpu(). This
patch fixes the issue by making round_robin_cpu() use its own mutex.
https://bugzilla.kernel.org/show_bug.cgi?id=42981
Signed-off-by: Stuart Hayes <Stuart_Hayes@Dell.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/acpi/acpi_pad.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
index a43fa1a..1502c502 100644
--- a/drivers/acpi/acpi_pad.c
+++ b/drivers/acpi/acpi_pad.c
@@ -36,6 +36,7 @@
#define ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME "Processor Aggregator"
#define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
static DEFINE_MUTEX(isolated_cpus_lock);
+static DEFINE_MUTEX(round_robin_lock);
static unsigned long power_saving_mwait_eax;
@@ -107,7 +108,7 @@ static void round_robin_cpu(unsigned int tsk_index)
if (!alloc_cpumask_var(&tmp, GFP_KERNEL))
return;
- mutex_lock(&isolated_cpus_lock);
+ mutex_lock(&round_robin_lock);
cpumask_clear(tmp);
for_each_cpu(cpu, pad_busy_cpus)
cpumask_or(tmp, tmp, topology_thread_cpumask(cpu));
@@ -116,7 +117,7 @@ static void round_robin_cpu(unsigned int tsk_index)
if (cpumask_empty(tmp))
cpumask_andnot(tmp, cpu_online_mask, pad_busy_cpus);
if (cpumask_empty(tmp)) {
- mutex_unlock(&isolated_cpus_lock);
+ mutex_unlock(&round_robin_lock);
return;
}
for_each_cpu(cpu, tmp) {
@@ -131,7 +132,7 @@ static void round_robin_cpu(unsigned int tsk_index)
tsk_in_cpu[tsk_index] = preferred_cpu;
cpumask_set_cpu(preferred_cpu, pad_busy_cpus);
cpu_weight[preferred_cpu]++;
- mutex_unlock(&isolated_cpus_lock);
+ mutex_unlock(&round_robin_lock);
set_cpus_allowed_ptr(current, cpumask_of(preferred_cpu));
}
^ permalink raw reply related [flat|nested] 78+ messages in thread* [ 48/48] batman-adv: only drop packets of known wifi clients
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (46 preceding siblings ...)
2012-07-01 17:20 ` [ 47/48] acpi_pad: fix power_saving thread deadlock Ben Hutchings
@ 2012-07-01 17:20 ` Ben Hutchings
2012-07-01 19:11 ` [ 00/48] 3.2.22-stable review Ben Hutchings
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 17:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Marek Lindner, Antonio Quartulli
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marek Lindner <lindner_marek@yahoo.de>
commit 5870adc68fc39d81089f1e80efdf64b97e5c37a1 upstream.
bug introduced with 59b699cdee039d75915c354da06937102d1f9a84
If the source or destination mac address of an ethernet packet
could not be found in the translation table the packet was
dropped if AP isolation was turned on. This behavior would
make it impossible to send broadcast packets over the mesh as
the broadcast address will never enter the translation table.
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
Acked-by: Antonio Quartulli <ordex@autistici.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
net/batman-adv/translation-table.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/batman-adv/translation-table.c b/net/batman-adv/translation-table.c
index a66c2dc..660c40f 100644
--- a/net/batman-adv/translation-table.c
+++ b/net/batman-adv/translation-table.c
@@ -2031,10 +2031,10 @@ bool is_ap_isolated(struct bat_priv *bat_priv, uint8_t *src, uint8_t *dst)
{
struct tt_local_entry *tt_local_entry = NULL;
struct tt_global_entry *tt_global_entry = NULL;
- bool ret = true;
+ bool ret = false;
if (!atomic_read(&bat_priv->ap_isolation))
- return false;
+ goto out;
tt_local_entry = tt_local_hash_find(bat_priv, dst);
if (!tt_local_entry)
@@ -2044,10 +2044,10 @@ bool is_ap_isolated(struct bat_priv *bat_priv, uint8_t *src, uint8_t *dst)
if (!tt_global_entry)
goto out;
- if (_is_ap_isolated(tt_local_entry, tt_global_entry))
+ if (!_is_ap_isolated(tt_local_entry, tt_global_entry))
goto out;
- ret = false;
+ ret = true;
out:
if (tt_global_entry)
^ permalink raw reply related [flat|nested] 78+ messages in thread* Re: [ 00/48] 3.2.22-stable review
2012-07-01 17:20 [ 00/48] 3.2.22-stable review Ben Hutchings
` (47 preceding siblings ...)
2012-07-01 17:20 ` [ 48/48] batman-adv: only drop packets of known wifi clients Ben Hutchings
@ 2012-07-01 19:11 ` Ben Hutchings
48 siblings, 0 replies; 78+ messages in thread
From: Ben Hutchings @ 2012-07-01 19:11 UTC (permalink / raw)
To: linux-kernel; +Cc: stable, torvalds, akpm, alan
[-- Attachment #1: Type: text/plain, Size: 51045 bytes --]
diff --git a/Documentation/stable_kernel_rules.txt b/Documentation/stable_kernel_rules.txt
index 21fd05c..e1f856b 100644
--- a/Documentation/stable_kernel_rules.txt
+++ b/Documentation/stable_kernel_rules.txt
@@ -12,6 +12,12 @@ Rules on what kind of patches are accepted, and which ones are not, into the
marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
security issue, or some "oh, that's not good" issue. In short, something
critical.
+ - Serious issues as reported by a user of a distribution kernel may also
+ be considered if they fix a notable performance or interactivity issue.
+ As these fixes are not as obvious and have a higher risk of a subtle
+ regression they should only be submitted by a distribution kernel
+ maintainer and include an addendum linking to a bugzilla entry if it
+ exists and additional information on the user-visible impact.
- New device IDs and quirks are also accepted.
- No "theoretical race condition" issues, unless an explanation of how the
race can be exploited is also provided.
diff --git a/Makefile b/Makefile
index 7eb465e..fec37c5 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 3
PATCHLEVEL = 2
-SUBLEVEL = 21
-EXTRAVERSION =
+SUBLEVEL = 22
+EXTRAVERSION = -rc1
NAME = Saber-toothed Squirrel
# *DOCUMENTATION*
diff --git a/arch/arm/plat-samsung/include/plat/map-s3c.h b/arch/arm/plat-samsung/include/plat/map-s3c.h
index 7d04875..c0c70a8 100644
--- a/arch/arm/plat-samsung/include/plat/map-s3c.h
+++ b/arch/arm/plat-samsung/include/plat/map-s3c.h
@@ -22,7 +22,7 @@
#define S3C24XX_VA_WATCHDOG S3C_VA_WATCHDOG
#define S3C2412_VA_SSMC S3C_ADDR_CPU(0x00000000)
-#define S3C2412_VA_EBI S3C_ADDR_CPU(0x00010000)
+#define S3C2412_VA_EBI S3C_ADDR_CPU(0x00100000)
#define S3C2410_PA_UART (0x50000000)
#define S3C24XX_PA_UART S3C2410_PA_UART
diff --git a/arch/arm/plat-samsung/include/plat/watchdog-reset.h b/arch/arm/plat-samsung/include/plat/watchdog-reset.h
index 40dbb2b..11b19ea 100644
--- a/arch/arm/plat-samsung/include/plat/watchdog-reset.h
+++ b/arch/arm/plat-samsung/include/plat/watchdog-reset.h
@@ -24,7 +24,7 @@ static inline void arch_wdt_reset(void)
__raw_writel(0, S3C2410_WTCON); /* disable watchdog, to be safe */
- if (s3c2410_wdtclk)
+ if (!IS_ERR(s3c2410_wdtclk))
clk_enable(s3c2410_wdtclk);
/* put initial values into count and data */
diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h
index f3444f7..0c3b775 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -175,7 +175,7 @@
#define X86_FEATURE_XSAVEOPT (7*32+ 4) /* Optimized Xsave */
#define X86_FEATURE_PLN (7*32+ 5) /* Intel Power Limit Notification */
#define X86_FEATURE_PTS (7*32+ 6) /* Intel Package Thermal Status */
-#define X86_FEATURE_DTS (7*32+ 7) /* Digital Thermal Sensor */
+#define X86_FEATURE_DTHERM (7*32+ 7) /* Digital Thermal Sensor */
/* Virtualization flags: Linux defined, word 8 */
#define X86_FEATURE_TPR_SHADOW (8*32+ 0) /* Intel TPR Shadow */
diff --git a/arch/x86/include/asm/pgtable-3level.h b/arch/x86/include/asm/pgtable-3level.h
index effff47..cb00ccc 100644
--- a/arch/x86/include/asm/pgtable-3level.h
+++ b/arch/x86/include/asm/pgtable-3level.h
@@ -31,6 +31,60 @@ static inline void native_set_pte(pte_t *ptep, pte_t pte)
ptep->pte_low = pte.pte_low;
}
+#define pmd_read_atomic pmd_read_atomic
+/*
+ * pte_offset_map_lock on 32bit PAE kernels was reading the pmd_t with
+ * a "*pmdp" dereference done by gcc. Problem is, in certain places
+ * where pte_offset_map_lock is called, concurrent page faults are
+ * allowed, if the mmap_sem is hold for reading. An example is mincore
+ * vs page faults vs MADV_DONTNEED. On the page fault side
+ * pmd_populate rightfully does a set_64bit, but if we're reading the
+ * pmd_t with a "*pmdp" on the mincore side, a SMP race can happen
+ * because gcc will not read the 64bit of the pmd atomically. To fix
+ * this all places running pmd_offset_map_lock() while holding the
+ * mmap_sem in read mode, shall read the pmdp pointer using this
+ * function to know if the pmd is null nor not, and in turn to know if
+ * they can run pmd_offset_map_lock or pmd_trans_huge or other pmd
+ * operations.
+ *
+ * Without THP if the mmap_sem is hold for reading, the pmd can only
+ * transition from null to not null while pmd_read_atomic runs. So
+ * we can always return atomic pmd values with this function.
+ *
+ * With THP if the mmap_sem is hold for reading, the pmd can become
+ * trans_huge or none or point to a pte (and in turn become "stable")
+ * at any time under pmd_read_atomic. We could read it really
+ * atomically here with a atomic64_read for the THP enabled case (and
+ * it would be a whole lot simpler), but to avoid using cmpxchg8b we
+ * only return an atomic pmdval if the low part of the pmdval is later
+ * found stable (i.e. pointing to a pte). And we're returning a none
+ * pmdval if the low part of the pmd is none. In some cases the high
+ * and low part of the pmdval returned may not be consistent if THP is
+ * enabled (the low part may point to previously mapped hugepage,
+ * while the high part may point to a more recently mapped hugepage),
+ * but pmd_none_or_trans_huge_or_clear_bad() only needs the low part
+ * of the pmd to be read atomically to decide if the pmd is unstable
+ * or not, with the only exception of when the low part of the pmd is
+ * zero in which case we return a none pmd.
+ */
+static inline pmd_t pmd_read_atomic(pmd_t *pmdp)
+{
+ pmdval_t ret;
+ u32 *tmp = (u32 *)pmdp;
+
+ ret = (pmdval_t) (*tmp);
+ if (ret) {
+ /*
+ * If the low part is null, we must not read the high part
+ * or we can end up with a partial pmd.
+ */
+ smp_rmb();
+ ret |= ((pmdval_t)*(tmp + 1)) << 32;
+ }
+
+ return (pmd_t) { ret };
+}
+
static inline void native_set_pte_atomic(pte_t *ptep, pte_t pte)
{
set_64bit((unsigned long long *)(ptep), native_pte_val(pte));
diff --git a/arch/x86/kernel/cpu/scattered.c b/arch/x86/kernel/cpu/scattered.c
index c7f64e6..ea6106c 100644
--- a/arch/x86/kernel/cpu/scattered.c
+++ b/arch/x86/kernel/cpu/scattered.c
@@ -31,7 +31,7 @@ void __cpuinit init_scattered_cpuid_features(struct cpuinfo_x86 *c)
const struct cpuid_bit *cb;
static const struct cpuid_bit __cpuinitconst cpuid_bits[] = {
- { X86_FEATURE_DTS, CR_EAX, 0, 0x00000006, 0 },
+ { X86_FEATURE_DTHERM, CR_EAX, 0, 0x00000006, 0 },
{ X86_FEATURE_IDA, CR_EAX, 1, 0x00000006, 0 },
{ X86_FEATURE_ARAT, CR_EAX, 2, 0x00000006, 0 },
{ X86_FEATURE_PLN, CR_EAX, 4, 0x00000006, 0 },
diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
index a43fa1a..1502c502 100644
--- a/drivers/acpi/acpi_pad.c
+++ b/drivers/acpi/acpi_pad.c
@@ -36,6 +36,7 @@
#define ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME "Processor Aggregator"
#define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
static DEFINE_MUTEX(isolated_cpus_lock);
+static DEFINE_MUTEX(round_robin_lock);
static unsigned long power_saving_mwait_eax;
@@ -107,7 +108,7 @@ static void round_robin_cpu(unsigned int tsk_index)
if (!alloc_cpumask_var(&tmp, GFP_KERNEL))
return;
- mutex_lock(&isolated_cpus_lock);
+ mutex_lock(&round_robin_lock);
cpumask_clear(tmp);
for_each_cpu(cpu, pad_busy_cpus)
cpumask_or(tmp, tmp, topology_thread_cpumask(cpu));
@@ -116,7 +117,7 @@ static void round_robin_cpu(unsigned int tsk_index)
if (cpumask_empty(tmp))
cpumask_andnot(tmp, cpu_online_mask, pad_busy_cpus);
if (cpumask_empty(tmp)) {
- mutex_unlock(&isolated_cpus_lock);
+ mutex_unlock(&round_robin_lock);
return;
}
for_each_cpu(cpu, tmp) {
@@ -131,7 +132,7 @@ static void round_robin_cpu(unsigned int tsk_index)
tsk_in_cpu[tsk_index] = preferred_cpu;
cpumask_set_cpu(preferred_cpu, pad_busy_cpus);
cpu_weight[preferred_cpu]++;
- mutex_unlock(&isolated_cpus_lock);
+ mutex_unlock(&round_robin_lock);
set_cpus_allowed_ptr(current, cpumask_of(preferred_cpu));
}
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index c3d2dfc..b96544a 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -869,7 +869,7 @@ static int __device_suspend(struct device *dev, pm_message_t state, bool async)
dpm_wait_for_children(dev, async);
if (async_error)
- return 0;
+ goto Complete;
pm_runtime_get_noresume(dev);
if (pm_runtime_barrier(dev) && device_may_wakeup(dev))
@@ -878,7 +878,7 @@ static int __device_suspend(struct device *dev, pm_message_t state, bool async)
if (pm_wakeup_pending()) {
pm_runtime_put_sync(dev);
async_error = -EBUSY;
- return 0;
+ goto Complete;
}
device_lock(dev);
@@ -926,6 +926,8 @@ static int __device_suspend(struct device *dev, pm_message_t state, bool async)
}
device_unlock(dev);
+
+ Complete:
complete_all(&dev->power.completion);
if (error) {
diff --git a/drivers/char/hw_random/atmel-rng.c b/drivers/char/hw_random/atmel-rng.c
index 0477982..1b5675b 100644
--- a/drivers/char/hw_random/atmel-rng.c
+++ b/drivers/char/hw_random/atmel-rng.c
@@ -34,7 +34,7 @@ static int atmel_trng_read(struct hwrng *rng, void *buf, size_t max,
u32 *data = buf;
/* data ready? */
- if (readl(trng->base + TRNG_ODATA) & 1) {
+ if (readl(trng->base + TRNG_ISR) & 1) {
*data = readl(trng->base + TRNG_ODATA);
/*
ensure data ready is only set again AFTER the next data
diff --git a/drivers/edac/i7core_edac.c b/drivers/edac/i7core_edac.c
index 70ad892..b3ccefa 100644
--- a/drivers/edac/i7core_edac.c
+++ b/drivers/edac/i7core_edac.c
@@ -1932,12 +1932,6 @@ static int i7core_mce_check_error(struct notifier_block *nb, unsigned long val,
if (mce->bank != 8)
return NOTIFY_DONE;
-#ifdef CONFIG_SMP
- /* Only handle if it is the right mc controller */
- if (mce->socketid != pvt->i7core_dev->socket)
- return NOTIFY_DONE;
-#endif
-
smp_rmb();
if ((pvt->mce_out + 1) % MCE_LOG_LEN == pvt->mce_in) {
smp_wmb();
@@ -2234,8 +2228,6 @@ static void i7core_unregister_mci(struct i7core_dev *i7core_dev)
if (pvt->enable_scrub)
disable_sdram_scrub_setting(mci);
- atomic_notifier_chain_unregister(&x86_mce_decoder_chain, &i7_mce_dec);
-
/* Disable EDAC polling */
i7core_pci_ctl_release(pvt);
@@ -2336,8 +2328,6 @@ static int i7core_register_mci(struct i7core_dev *i7core_dev)
/* DCLK for scrub rate setting */
pvt->dclk_freq = get_dclk_freq();
- atomic_notifier_chain_register(&x86_mce_decoder_chain, &i7_mce_dec);
-
return 0;
fail0:
@@ -2481,8 +2471,10 @@ static int __init i7core_init(void)
pci_rc = pci_register_driver(&i7core_driver);
- if (pci_rc >= 0)
+ if (pci_rc >= 0) {
+ atomic_notifier_chain_register(&x86_mce_decoder_chain, &i7_mce_dec);
return 0;
+ }
i7core_printk(KERN_ERR, "Failed to register device with error %d.\n",
pci_rc);
@@ -2498,6 +2490,7 @@ static void __exit i7core_exit(void)
{
debugf2("MC: " __FILE__ ": %s()\n", __func__);
pci_unregister_driver(&i7core_driver);
+ atomic_notifier_chain_unregister(&x86_mce_decoder_chain, &i7_mce_dec);
}
module_init(i7core_init);
diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
index 7a402bf..18a1293 100644
--- a/drivers/edac/sb_edac.c
+++ b/drivers/edac/sb_edac.c
@@ -1661,9 +1661,6 @@ static void sbridge_unregister_mci(struct sbridge_dev *sbridge_dev)
debugf0("MC: " __FILE__ ": %s(): mci = %p, dev = %p\n",
__func__, mci, &sbridge_dev->pdev[0]->dev);
- atomic_notifier_chain_unregister(&x86_mce_decoder_chain,
- &sbridge_mce_dec);
-
/* Remove MC sysfs nodes */
edac_mc_del_mc(mci->dev);
@@ -1731,8 +1728,6 @@ static int sbridge_register_mci(struct sbridge_dev *sbridge_dev)
goto fail0;
}
- atomic_notifier_chain_register(&x86_mce_decoder_chain,
- &sbridge_mce_dec);
return 0;
fail0:
@@ -1861,8 +1856,10 @@ static int __init sbridge_init(void)
pci_rc = pci_register_driver(&sbridge_driver);
- if (pci_rc >= 0)
+ if (pci_rc >= 0) {
+ atomic_notifier_chain_register(&x86_mce_decoder_chain, &sbridge_mce_dec);
return 0;
+ }
sbridge_printk(KERN_ERR, "Failed to register device with error %d.\n",
pci_rc);
@@ -1878,6 +1875,7 @@ static void __exit sbridge_exit(void)
{
debugf2("MC: " __FILE__ ": %s()\n", __func__);
pci_unregister_driver(&sbridge_driver);
+ atomic_notifier_chain_unregister(&x86_mce_decoder_chain, &sbridge_mce_dec);
}
module_init(sbridge_init);
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 3e927ce..a1ee634 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -585,7 +585,7 @@ static bool
drm_monitor_supports_rb(struct edid *edid)
{
if (edid->revision >= 4) {
- bool ret;
+ bool ret = false;
drm_for_each_detailed_block((u8 *)edid, is_rb, &ret);
return ret;
}
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 3e7c478..3e2edc6 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3312,6 +3312,10 @@ i915_gem_ring_throttle(struct drm_device *dev, struct drm_file *file)
if (ret == 0 && atomic_read(&dev_priv->mm.wedged))
ret = -EIO;
+ } else if (wait_for(i915_seqno_passed(ring->get_seqno(ring),
+ seqno) ||
+ atomic_read(&dev_priv->mm.wedged), 3000)) {
+ ret = -EBUSY;
}
}
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index d3820c2..578ddfc 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -424,6 +424,30 @@ static void gen6_pm_rps_work(struct work_struct *work)
mutex_unlock(&dev_priv->dev->struct_mutex);
}
+static void gen6_queue_rps_work(struct drm_i915_private *dev_priv,
+ u32 pm_iir)
+{
+ unsigned long flags;
+
+ /*
+ * IIR bits should never already be set because IMR should
+ * prevent an interrupt from being shown in IIR. The warning
+ * displays a case where we've unsafely cleared
+ * dev_priv->pm_iir. Although missing an interrupt of the same
+ * type is not a problem, it displays a problem in the logic.
+ *
+ * The mask bit in IMR is cleared by rps_work.
+ */
+
+ spin_lock_irqsave(&dev_priv->rps_lock, flags);
+ dev_priv->pm_iir |= pm_iir;
+ I915_WRITE(GEN6_PMIMR, dev_priv->pm_iir);
+ POSTING_READ(GEN6_PMIMR);
+ spin_unlock_irqrestore(&dev_priv->rps_lock, flags);
+
+ queue_work(dev_priv->wq, &dev_priv->rps_work);
+}
+
static void pch_irq_handler(struct drm_device *dev, u32 pch_iir)
{
drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev->dev_private;
@@ -529,16 +553,8 @@ static irqreturn_t ivybridge_irq_handler(DRM_IRQ_ARGS)
pch_irq_handler(dev, pch_iir);
}
- if (pm_iir & GEN6_PM_DEFERRED_EVENTS) {
- unsigned long flags;
- spin_lock_irqsave(&dev_priv->rps_lock, flags);
- WARN(dev_priv->pm_iir & pm_iir, "Missed a PM interrupt\n");
- dev_priv->pm_iir |= pm_iir;
- I915_WRITE(GEN6_PMIMR, dev_priv->pm_iir);
- POSTING_READ(GEN6_PMIMR);
- spin_unlock_irqrestore(&dev_priv->rps_lock, flags);
- queue_work(dev_priv->wq, &dev_priv->rps_work);
- }
+ if (pm_iir & GEN6_PM_DEFERRED_EVENTS)
+ gen6_queue_rps_work(dev_priv, pm_iir);
/* should clear PCH hotplug event before clear CPU irq */
I915_WRITE(SDEIIR, pch_iir);
@@ -634,25 +650,8 @@ static irqreturn_t ironlake_irq_handler(DRM_IRQ_ARGS)
i915_handle_rps_change(dev);
}
- if (IS_GEN6(dev) && pm_iir & GEN6_PM_DEFERRED_EVENTS) {
- /*
- * IIR bits should never already be set because IMR should
- * prevent an interrupt from being shown in IIR. The warning
- * displays a case where we've unsafely cleared
- * dev_priv->pm_iir. Although missing an interrupt of the same
- * type is not a problem, it displays a problem in the logic.
- *
- * The mask bit in IMR is cleared by rps_work.
- */
- unsigned long flags;
- spin_lock_irqsave(&dev_priv->rps_lock, flags);
- WARN(dev_priv->pm_iir & pm_iir, "Missed a PM interrupt\n");
- dev_priv->pm_iir |= pm_iir;
- I915_WRITE(GEN6_PMIMR, dev_priv->pm_iir);
- POSTING_READ(GEN6_PMIMR);
- spin_unlock_irqrestore(&dev_priv->rps_lock, flags);
- queue_work(dev_priv->wq, &dev_priv->rps_work);
- }
+ if (IS_GEN6(dev) && pm_iir & GEN6_PM_DEFERRED_EVENTS)
+ gen6_queue_rps_work(dev_priv, pm_iir);
/* should clear PCH hotplug event before clear CPU irq */
I915_WRITE(SDEIIR, pch_iir);
diff --git a/drivers/gpu/drm/i915/i915_suspend.c b/drivers/gpu/drm/i915/i915_suspend.c
index a1eb83d..f38d196 100644
--- a/drivers/gpu/drm/i915/i915_suspend.c
+++ b/drivers/gpu/drm/i915/i915_suspend.c
@@ -739,8 +739,11 @@ static void i915_restore_display(struct drm_device *dev)
if (HAS_PCH_SPLIT(dev)) {
I915_WRITE(BLC_PWM_PCH_CTL1, dev_priv->saveBLC_PWM_CTL);
I915_WRITE(BLC_PWM_PCH_CTL2, dev_priv->saveBLC_PWM_CTL2);
- I915_WRITE(BLC_PWM_CPU_CTL, dev_priv->saveBLC_CPU_PWM_CTL);
+ /* NOTE: BLC_PWM_CPU_CTL must be written after BLC_PWM_CPU_CTL2;
+ * otherwise we get blank eDP screen after S3 on some machines
+ */
I915_WRITE(BLC_PWM_CPU_CTL2, dev_priv->saveBLC_CPU_PWM_CTL2);
+ I915_WRITE(BLC_PWM_CPU_CTL, dev_priv->saveBLC_CPU_PWM_CTL);
I915_WRITE(PCH_PP_ON_DELAYS, dev_priv->savePP_ON_DELAYS);
I915_WRITE(PCH_PP_OFF_DELAYS, dev_priv->savePP_OFF_DELAYS);
I915_WRITE(PCH_PP_DIVISOR, dev_priv->savePP_DIVISOR);
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 5c1cdb8..6aa7716 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2187,6 +2187,33 @@ intel_pipe_set_base_atomic(struct drm_crtc *crtc, struct drm_framebuffer *fb,
}
static int
+intel_finish_fb(struct drm_framebuffer *old_fb)
+{
+ struct drm_i915_gem_object *obj = to_intel_framebuffer(old_fb)->obj;
+ struct drm_i915_private *dev_priv = obj->base.dev->dev_private;
+ bool was_interruptible = dev_priv->mm.interruptible;
+ int ret;
+
+ wait_event(dev_priv->pending_flip_queue,
+ atomic_read(&dev_priv->mm.wedged) ||
+ atomic_read(&obj->pending_flip) == 0);
+
+ /* Big Hammer, we also need to ensure that any pending
+ * MI_WAIT_FOR_EVENT inside a user batch buffer on the
+ * current scanout is retired before unpinning the old
+ * framebuffer.
+ *
+ * This should only fail upon a hung GPU, in which case we
+ * can safely continue.
+ */
+ dev_priv->mm.interruptible = false;
+ ret = i915_gem_object_finish_gpu(obj);
+ dev_priv->mm.interruptible = was_interruptible;
+
+ return ret;
+}
+
+static int
intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
struct drm_framebuffer *old_fb)
{
@@ -2224,25 +2251,8 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
return ret;
}
- if (old_fb) {
- struct drm_i915_private *dev_priv = dev->dev_private;
- struct drm_i915_gem_object *obj = to_intel_framebuffer(old_fb)->obj;
-
- wait_event(dev_priv->pending_flip_queue,
- atomic_read(&dev_priv->mm.wedged) ||
- atomic_read(&obj->pending_flip) == 0);
-
- /* Big Hammer, we also need to ensure that any pending
- * MI_WAIT_FOR_EVENT inside a user batch buffer on the
- * current scanout is retired before unpinning the old
- * framebuffer.
- *
- * This should only fail upon a hung GPU, in which case we
- * can safely continue.
- */
- ret = i915_gem_object_finish_gpu(obj);
- (void) ret;
- }
+ if (old_fb)
+ intel_finish_fb(old_fb);
ret = intel_pipe_set_base_atomic(crtc, crtc->fb, x, y,
LEAVE_ATOMIC_MODE_SET);
@@ -3312,6 +3322,23 @@ static void intel_crtc_disable(struct drm_crtc *crtc)
struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
struct drm_device *dev = crtc->dev;
+ /* Flush any pending WAITs before we disable the pipe. Note that
+ * we need to drop the struct_mutex in order to acquire it again
+ * during the lowlevel dpms routines around a couple of the
+ * operations. It does not look trivial nor desirable to move
+ * that locking higher. So instead we leave a window for the
+ * submission of further commands on the fb before we can actually
+ * disable it. This race with userspace exists anyway, and we can
+ * only rely on the pipe being disabled by userspace after it
+ * receives the hotplug notification and has flushed any pending
+ * batches.
+ */
+ if (crtc->fb) {
+ mutex_lock(&dev->struct_mutex);
+ intel_finish_fb(crtc->fb);
+ mutex_unlock(&dev->struct_mutex);
+ }
+
crtc_funcs->dpms(crtc, DRM_MODE_DPMS_OFF);
if (crtc->fb) {
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 933e66b..f6613dc 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -306,7 +306,7 @@ static int init_ring_common(struct intel_ring_buffer *ring)
I915_WRITE_CTL(ring,
((ring->size - PAGE_SIZE) & RING_NR_PAGES)
- | RING_REPORT_64K | RING_VALID);
+ | RING_VALID);
/* If the head is still not zero, the ring is dead */
if ((I915_READ_CTL(ring) & RING_VALID) == 0 ||
@@ -1157,18 +1157,6 @@ int intel_wait_ring_buffer(struct intel_ring_buffer *ring, int n)
struct drm_device *dev = ring->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
unsigned long end;
- u32 head;
-
- /* If the reported head position has wrapped or hasn't advanced,
- * fallback to the slow and accurate path.
- */
- head = intel_read_status_page(ring, 4);
- if (head > ring->head) {
- ring->head = head;
- ring->space = ring_space(ring);
- if (ring->space >= n)
- return 0;
- }
trace_i915_ring_wait_begin(ring);
end = jiffies + 3 * HZ;
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index 3a4cc32..cc0801d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -499,7 +499,7 @@ int nouveau_fbcon_init(struct drm_device *dev)
nfbdev->helper.funcs = &nouveau_fbcon_helper_funcs;
ret = drm_fb_helper_init(dev, &nfbdev->helper,
- nv_two_heads(dev) ? 2 : 1, 4);
+ dev->mode_config.num_crtc, 4);
if (ret) {
kfree(nfbdev);
return ret;
diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
index 4c07436..d99aa84 100644
--- a/drivers/hwmon/applesmc.c
+++ b/drivers/hwmon/applesmc.c
@@ -215,7 +215,7 @@ static int read_smc(u8 cmd, const char *key, u8 *buffer, u8 len)
int i;
if (send_command(cmd) || send_argument(key)) {
- pr_warn("%s: read arg fail\n", key);
+ pr_warn("%.4s: read arg fail\n", key);
return -EIO;
}
@@ -223,7 +223,7 @@ static int read_smc(u8 cmd, const char *key, u8 *buffer, u8 len)
for (i = 0; i < len; i++) {
if (__wait_status(0x05)) {
- pr_warn("%s: read data fail\n", key);
+ pr_warn("%.4s: read data fail\n", key);
return -EIO;
}
buffer[i] = inb(APPLESMC_DATA_PORT);
diff --git a/drivers/hwmon/coretemp.c b/drivers/hwmon/coretemp.c
index 427468f..0790c98 100644
--- a/drivers/hwmon/coretemp.c
+++ b/drivers/hwmon/coretemp.c
@@ -660,7 +660,7 @@ static void __cpuinit get_core_online(unsigned int cpu)
* sensors. We check this bit only, all the early CPUs
* without thermal sensors will be filtered out.
*/
- if (!cpu_has(c, X86_FEATURE_DTS))
+ if (!cpu_has(c, X86_FEATURE_DTHERM))
return;
if (!pdev) {
diff --git a/drivers/md/dm-thin.c b/drivers/md/dm-thin.c
index da2f021..532a902 100644
--- a/drivers/md/dm-thin.c
+++ b/drivers/md/dm-thin.c
@@ -288,8 +288,10 @@ static void __cell_release(struct cell *cell, struct bio_list *inmates)
hlist_del(&cell->list);
- bio_list_add(inmates, cell->holder);
- bio_list_merge(inmates, &cell->bios);
+ if (inmates) {
+ bio_list_add(inmates, cell->holder);
+ bio_list_merge(inmates, &cell->bios);
+ }
mempool_free(cell, prison->cell_pool);
}
@@ -312,9 +314,10 @@ static void cell_release(struct cell *cell, struct bio_list *bios)
*/
static void __cell_release_singleton(struct cell *cell, struct bio *bio)
{
- hlist_del(&cell->list);
BUG_ON(cell->holder != bio);
BUG_ON(!bio_list_empty(&cell->bios));
+
+ __cell_release(cell, NULL);
}
static void cell_release_singleton(struct cell *cell, struct bio *bio)
diff --git a/drivers/media/dvb/siano/smsusb.c b/drivers/media/dvb/siano/smsusb.c
index b7d1e3e..fb68805 100644
--- a/drivers/media/dvb/siano/smsusb.c
+++ b/drivers/media/dvb/siano/smsusb.c
@@ -544,6 +544,8 @@ static const struct usb_device_id smsusb_id_table[] __devinitconst = {
.driver_info = SMS1XXX_BOARD_HAUPPAUGE_WINDHAM },
{ USB_DEVICE(0x2040, 0xc0a0),
.driver_info = SMS1XXX_BOARD_HAUPPAUGE_WINDHAM },
+ { USB_DEVICE(0x2040, 0xf5a0),
+ .driver_info = SMS1XXX_BOARD_HAUPPAUGE_WINDHAM },
{ } /* Terminating entry */
};
diff --git a/drivers/media/video/gspca/gspca.c b/drivers/media/video/gspca/gspca.c
index 2ca10df..981501f 100644
--- a/drivers/media/video/gspca/gspca.c
+++ b/drivers/media/video/gspca/gspca.c
@@ -1697,7 +1697,7 @@ static int vidioc_streamoff(struct file *file, void *priv,
enum v4l2_buf_type buf_type)
{
struct gspca_dev *gspca_dev = priv;
- int ret;
+ int i, ret;
if (buf_type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
return -EINVAL;
@@ -1728,6 +1728,8 @@ static int vidioc_streamoff(struct file *file, void *priv,
wake_up_interruptible(&gspca_dev->wq);
/* empty the transfer queues */
+ for (i = 0; i < gspca_dev->nframes; i++)
+ gspca_dev->frame[i].v4l2_buf.flags &= ~BUF_ALL_FLAGS;
atomic_set(&gspca_dev->fr_q, 0);
atomic_set(&gspca_dev->fr_i, 0);
gspca_dev->fr_o = 0;
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index 8dc84d6..86cd532 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -590,8 +590,8 @@ static void c_can_chip_config(struct net_device *dev)
priv->write_reg(priv, &priv->regs->control,
CONTROL_ENABLE_AR);
- if (priv->can.ctrlmode & (CAN_CTRLMODE_LISTENONLY &
- CAN_CTRLMODE_LOOPBACK)) {
+ if ((priv->can.ctrlmode & CAN_CTRLMODE_LISTENONLY) &&
+ (priv->can.ctrlmode & CAN_CTRLMODE_LOOPBACK)) {
/* loopback + silent mode : useful for hot self-test */
priv->write_reg(priv, &priv->regs->control, CONTROL_EIE |
CONTROL_SIE | CONTROL_IE | CONTROL_TEST);
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index e023379..e59d006 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -933,12 +933,12 @@ static int __devinit flexcan_probe(struct platform_device *pdev)
u32 clock_freq = 0;
if (pdev->dev.of_node) {
- const u32 *clock_freq_p;
+ const __be32 *clock_freq_p;
clock_freq_p = of_get_property(pdev->dev.of_node,
"clock-frequency", NULL);
if (clock_freq_p)
- clock_freq = *clock_freq_p;
+ clock_freq = be32_to_cpup(clock_freq_p);
}
if (!clock_freq) {
diff --git a/drivers/net/ethernet/intel/e1000e/82571.c b/drivers/net/ethernet/intel/e1000e/82571.c
index a3e65fd..e556fc3 100644
--- a/drivers/net/ethernet/intel/e1000e/82571.c
+++ b/drivers/net/ethernet/intel/e1000e/82571.c
@@ -2080,8 +2080,9 @@ const struct e1000_info e1000_82574_info = {
| FLAG_HAS_SMART_POWER_DOWN
| FLAG_HAS_AMT
| FLAG_HAS_CTRLEXT_ON_LOAD,
- .flags2 = FLAG2_CHECK_PHY_HANG
+ .flags2 = FLAG2_CHECK_PHY_HANG
| FLAG2_DISABLE_ASPM_L0S
+ | FLAG2_DISABLE_ASPM_L1
| FLAG2_NO_DISABLE_RX,
.pba = 32,
.max_hw_frame_size = DEFAULT_JUMBO,
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index 4e933d1..64d3f98 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -5132,14 +5132,6 @@ static int e1000_change_mtu(struct net_device *netdev, int new_mtu)
return -EINVAL;
}
- /* 82573 Errata 17 */
- if (((adapter->hw.mac.type == e1000_82573) ||
- (adapter->hw.mac.type == e1000_82574)) &&
- (max_frame > ETH_FRAME_LEN + ETH_FCS_LEN)) {
- adapter->flags2 |= FLAG2_DISABLE_ASPM_L1;
- e1000e_disable_aspm(adapter->pdev, PCIE_LINK_STATE_L1);
- }
-
while (test_and_set_bit(__E1000_RESETTING, &adapter->state))
usleep_range(1000, 2000);
/* e1000e_down -> e1000e_reset dependent on max_frame_size & mtu */
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 8b0c2ca..6973620 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -718,13 +718,25 @@ static void ath9k_hw_init_qos(struct ath_hw *ah)
u32 ar9003_get_pll_sqsum_dvc(struct ath_hw *ah)
{
+ struct ath_common *common = ath9k_hw_common(ah);
+ int i = 0;
+
REG_CLR_BIT(ah, PLL3, PLL3_DO_MEAS_MASK);
udelay(100);
REG_SET_BIT(ah, PLL3, PLL3_DO_MEAS_MASK);
- while ((REG_READ(ah, PLL4) & PLL4_MEAS_DONE) == 0)
+ while ((REG_READ(ah, PLL4) & PLL4_MEAS_DONE) == 0) {
+
udelay(100);
+ if (WARN_ON_ONCE(i >= 100)) {
+ ath_err(common, "PLL4 meaurement not done\n");
+ break;
+ }
+
+ i++;
+ }
+
return (REG_READ(ah, PLL3) & SQSUM_DVC_MASK) >> 3;
}
EXPORT_SYMBOL(ar9003_get_pll_sqsum_dvc);
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index f76a814..95437fc 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1042,6 +1042,15 @@ void ath_hw_pll_work(struct work_struct *work)
hw_pll_work.work);
u32 pll_sqsum;
+ /*
+ * ensure that the PLL WAR is executed only
+ * after the STA is associated (or) if the
+ * beaconing had started in interfaces that
+ * uses beacons.
+ */
+ if (!(sc->sc_flags & SC_OP_BEACONS))
+ return;
+
if (AR_SREV_9485(sc->sc_ah)) {
ath9k_ps_wakeup(sc);
@@ -1486,15 +1495,6 @@ static int ath9k_add_interface(struct ieee80211_hw *hw,
}
}
- if ((ah->opmode == NL80211_IFTYPE_ADHOC) ||
- ((vif->type == NL80211_IFTYPE_ADHOC) &&
- sc->nvifs > 0)) {
- ath_err(common, "Cannot create ADHOC interface when other"
- " interfaces already exist.\n");
- ret = -EINVAL;
- goto out;
- }
-
ath_dbg(common, ATH_DBG_CONFIG,
"Attach a VIF of type: %d\n", vif->type);
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 76fd277..c59c592 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -936,13 +936,13 @@ static void ath_buf_set_rate(struct ath_softc *sc, struct ath_buf *bf,
}
/* legacy rates */
+ rate = &sc->sbands[tx_info->band].bitrates[rates[i].idx];
if ((tx_info->band == IEEE80211_BAND_2GHZ) &&
!(rate->flags & IEEE80211_RATE_ERP_G))
phy = WLAN_RC_PHY_CCK;
else
phy = WLAN_RC_PHY_OFDM;
- rate = &sc->sbands[tx_info->band].bitrates[rates[i].idx];
info->rates[i].Rate = rate->hw_value;
if (rate->hw_value_short) {
if (rates[i].flags & IEEE80211_TX_RC_USE_SHORT_PREAMBLE)
diff --git a/drivers/net/wireless/iwlwifi/iwl-trans-pcie.c b/drivers/net/wireless/iwlwifi/iwl-trans-pcie.c
index 5815cf5..4661a64 100644
--- a/drivers/net/wireless/iwlwifi/iwl-trans-pcie.c
+++ b/drivers/net/wireless/iwlwifi/iwl-trans-pcie.c
@@ -1777,6 +1777,7 @@ static ssize_t iwl_dbgfs_rx_queue_read(struct file *file,
return simple_read_from_buffer(user_buf, count, ppos, buf, pos);
}
+#ifdef CONFIG_IWLWIFI_DEBUG
static ssize_t iwl_dbgfs_log_event_read(struct file *file,
char __user *user_buf,
size_t count, loff_t *ppos)
@@ -1814,6 +1815,7 @@ static ssize_t iwl_dbgfs_log_event_write(struct file *file,
return count;
}
+#endif
static ssize_t iwl_dbgfs_interrupt_read(struct file *file,
char __user *user_buf,
@@ -1941,7 +1943,9 @@ static ssize_t iwl_dbgfs_fh_reg_read(struct file *file,
return ret;
}
+#ifdef CONFIG_IWLWIFI_DEBUG
DEBUGFS_READ_WRITE_FILE_OPS(log_event);
+#endif
DEBUGFS_READ_WRITE_FILE_OPS(interrupt);
DEBUGFS_READ_FILE_OPS(fh_reg);
DEBUGFS_READ_FILE_OPS(rx_queue);
@@ -1957,7 +1961,9 @@ static int iwl_trans_pcie_dbgfs_register(struct iwl_trans *trans,
{
DEBUGFS_ADD_FILE(rx_queue, dir, S_IRUSR);
DEBUGFS_ADD_FILE(tx_queue, dir, S_IRUSR);
+#ifdef CONFIG_IWLWIFI_DEBUG
DEBUGFS_ADD_FILE(log_event, dir, S_IWUSR | S_IRUSR);
+#endif
DEBUGFS_ADD_FILE(interrupt, dir, S_IWUSR | S_IRUSR);
DEBUGFS_ADD_FILE(csr, dir, S_IWUSR);
DEBUGFS_ADD_FILE(fh_reg, dir, S_IRUSR);
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 226faab..fc35308 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1922,14 +1922,14 @@ static int __devexit xennet_remove(struct xenbus_device *dev)
dev_dbg(&dev->dev, "%s\n", dev->nodename);
- unregister_netdev(info->netdev);
-
xennet_disconnect_backend(info);
- del_timer_sync(&info->rx_refill_timer);
-
xennet_sysfs_delif(info->netdev);
+ unregister_netdev(info->netdev);
+
+ del_timer_sync(&info->rx_refill_timer);
+
free_percpu(info->stats);
free_netdev(info->netdev);
diff --git a/drivers/oprofile/oprofile_perf.c b/drivers/oprofile/oprofile_perf.c
index da14432..efc4b7f 100644
--- a/drivers/oprofile/oprofile_perf.c
+++ b/drivers/oprofile/oprofile_perf.c
@@ -25,7 +25,7 @@ static int oprofile_perf_enabled;
static DEFINE_MUTEX(oprofile_perf_mutex);
static struct op_counter_config *counter_config;
-static struct perf_event **perf_events[nr_cpumask_bits];
+static struct perf_event **perf_events[NR_CPUS];
static int num_counters;
/*
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 4b63c73..a26a6e9 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -1811,6 +1811,8 @@ static int sd_try_rc16_first(struct scsi_device *sdp)
{
if (sdp->host->max_cmd_len < 16)
return 0;
+ if (sdp->try_rc_10_first)
+ return 0;
if (sdp->scsi_level > SCSI_SPC_2)
return 1;
if (scsi_device_protection(sdp))
diff --git a/drivers/staging/iio/adc/ad7606_core.c b/drivers/staging/iio/adc/ad7606_core.c
index 54423ab..2ee187f 100644
--- a/drivers/staging/iio/adc/ad7606_core.c
+++ b/drivers/staging/iio/adc/ad7606_core.c
@@ -241,6 +241,7 @@ static const struct attribute_group ad7606_attribute_group = {
.indexed = 1, \
.channel = num, \
.address = num, \
+ .info_mask = (1 << IIO_CHAN_INFO_SCALE_SHARED), \
.scan_index = num, \
.scan_type = IIO_ST('s', 16, 16, 0), \
}
diff --git a/drivers/staging/rtl8712/usb_intf.c b/drivers/staging/rtl8712/usb_intf.c
index ec41d38..f4b738f 100644
--- a/drivers/staging/rtl8712/usb_intf.c
+++ b/drivers/staging/rtl8712/usb_intf.c
@@ -102,6 +102,8 @@ static struct usb_device_id rtl871x_usb_id_tbl[] = {
/* - */
{USB_DEVICE(0x20F4, 0x646B)},
{USB_DEVICE(0x083A, 0xC512)},
+ {USB_DEVICE(0x25D4, 0x4CA1)},
+ {USB_DEVICE(0x25D4, 0x4CAB)},
/* RTL8191SU */
/* Realtek */
diff --git a/drivers/staging/rts_pstor/rtsx_transport.c b/drivers/staging/rts_pstor/rtsx_transport.c
index 4e3d2c1..9b2e5c9 100644
--- a/drivers/staging/rts_pstor/rtsx_transport.c
+++ b/drivers/staging/rts_pstor/rtsx_transport.c
@@ -335,6 +335,7 @@ static int rtsx_transfer_sglist_adma_partial(struct rtsx_chip *chip, u8 card,
int sg_cnt, i, resid;
int err = 0;
long timeleft;
+ struct scatterlist *sg_ptr;
u32 val = TRIG_DMA;
if ((sg == NULL) || (num_sg <= 0) || !offset || !index)
@@ -371,7 +372,7 @@ static int rtsx_transfer_sglist_adma_partial(struct rtsx_chip *chip, u8 card,
sg_cnt = dma_map_sg(&(rtsx->pci->dev), sg, num_sg, dma_dir);
resid = size;
-
+ sg_ptr = sg;
chip->sgi = 0;
/* Usually the next entry will be @sg@ + 1, but if this sg element
* is part of a chained scatterlist, it could jump to the start of
@@ -379,14 +380,14 @@ static int rtsx_transfer_sglist_adma_partial(struct rtsx_chip *chip, u8 card,
* the proper sg
*/
for (i = 0; i < *index; i++)
- sg = sg_next(sg);
+ sg_ptr = sg_next(sg_ptr);
for (i = *index; i < sg_cnt; i++) {
dma_addr_t addr;
unsigned int len;
u8 option;
- addr = sg_dma_address(sg);
- len = sg_dma_len(sg);
+ addr = sg_dma_address(sg_ptr);
+ len = sg_dma_len(sg_ptr);
RTSX_DEBUGP("DMA addr: 0x%x, Len: 0x%x\n",
(unsigned int)addr, len);
@@ -415,7 +416,7 @@ static int rtsx_transfer_sglist_adma_partial(struct rtsx_chip *chip, u8 card,
if (!resid)
break;
- sg = sg_next(sg);
+ sg_ptr = sg_next(sg_ptr);
}
RTSX_DEBUGP("SG table count = %d\n", chip->sgi);
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index aa0c43f..35e6b5f 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -93,6 +93,7 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x10C4, 0x814B) }, /* West Mountain Radio RIGtalk */
{ USB_DEVICE(0x10C4, 0x8156) }, /* B&G H3000 link cable */
{ USB_DEVICE(0x10C4, 0x815E) }, /* Helicomm IP-Link 1220-DVM */
+ { USB_DEVICE(0x10C4, 0x815F) }, /* Timewave HamLinkUSB */
{ USB_DEVICE(0x10C4, 0x818B) }, /* AVIT Research USB to TTL */
{ USB_DEVICE(0x10C4, 0x819F) }, /* MJS USB Toslink Switcher */
{ USB_DEVICE(0x10C4, 0x81A6) }, /* ThinkOptics WavIt */
@@ -134,7 +135,13 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x10CE, 0xEA6A) }, /* Silicon Labs MobiData GPRS USB Modem 100EU */
{ USB_DEVICE(0x13AD, 0x9999) }, /* Baltech card reader */
{ USB_DEVICE(0x1555, 0x0004) }, /* Owen AC4 USB-RS485 Converter */
+ { USB_DEVICE(0x166A, 0x0201) }, /* Clipsal 5500PACA C-Bus Pascal Automation Controller */
+ { USB_DEVICE(0x166A, 0x0301) }, /* Clipsal 5800PC C-Bus Wireless PC Interface */
{ USB_DEVICE(0x166A, 0x0303) }, /* Clipsal 5500PCU C-Bus USB interface */
+ { USB_DEVICE(0x166A, 0x0304) }, /* Clipsal 5000CT2 C-Bus Black and White Touchscreen */
+ { USB_DEVICE(0x166A, 0x0305) }, /* Clipsal C-5000CT2 C-Bus Spectrum Colour Touchscreen */
+ { USB_DEVICE(0x166A, 0x0401) }, /* Clipsal L51xx C-Bus Architectural Dimmer */
+ { USB_DEVICE(0x166A, 0x0101) }, /* Clipsal 5560884 C-Bus Multi-room Audio Matrix Switcher */
{ USB_DEVICE(0x16D6, 0x0001) }, /* Jablotron serial interface */
{ USB_DEVICE(0x16DC, 0x0010) }, /* W-IE-NE-R Plein & Baus GmbH PL512 Power Supply */
{ USB_DEVICE(0x16DC, 0x0011) }, /* W-IE-NE-R Plein & Baus GmbH RCM Remote Control for MARATON Power Supply */
@@ -146,7 +153,11 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x1843, 0x0200) }, /* Vaisala USB Instrument Cable */
{ USB_DEVICE(0x18EF, 0xE00F) }, /* ELV USB-I2C-Interface */
{ USB_DEVICE(0x1BE3, 0x07A6) }, /* WAGO 750-923 USB Service Cable */
+ { USB_DEVICE(0x1E29, 0x0102) }, /* Festo CPX-USB */
+ { USB_DEVICE(0x1E29, 0x0501) }, /* Festo CMSP */
{ USB_DEVICE(0x3195, 0xF190) }, /* Link Instruments MSO-19 */
+ { USB_DEVICE(0x3195, 0xF280) }, /* Link Instruments MSO-28 */
+ { USB_DEVICE(0x3195, 0xF281) }, /* Link Instruments MSO-28 */
{ USB_DEVICE(0x413C, 0x9500) }, /* DW700 GPS USB interface */
{ } /* Terminating Entry */
};
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 61d6c31..21a4734 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -235,6 +235,7 @@ static void option_instat_callback(struct urb *urb);
#define NOVATELWIRELESS_PRODUCT_G1 0xA001
#define NOVATELWIRELESS_PRODUCT_G1_M 0xA002
#define NOVATELWIRELESS_PRODUCT_G2 0xA010
+#define NOVATELWIRELESS_PRODUCT_MC551 0xB001
/* AMOI PRODUCTS */
#define AMOI_VENDOR_ID 0x1614
@@ -496,6 +497,10 @@ static void option_instat_callback(struct urb *urb);
/* MediaTek products */
#define MEDIATEK_VENDOR_ID 0x0e8d
+/* Cellient products */
+#define CELLIENT_VENDOR_ID 0x2692
+#define CELLIENT_PRODUCT_MEN200 0x9005
+
/* some devices interfaces need special handling due to a number of reasons */
enum option_blacklist_reason {
OPTION_BLACKLIST_NONE = 0,
@@ -730,6 +735,8 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_G1) },
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_G1_M) },
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_G2) },
+ /* Novatel Ovation MC551 a.k.a. Verizon USB551L */
+ { USB_DEVICE_AND_INTERFACE_INFO(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_MC551, 0xff, 0xff, 0xff) },
{ USB_DEVICE(AMOI_VENDOR_ID, AMOI_PRODUCT_H01) },
{ USB_DEVICE(AMOI_VENDOR_ID, AMOI_PRODUCT_H01A) },
@@ -1227,6 +1234,7 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE_AND_INTERFACE_INFO(MEDIATEK_VENDOR_ID, 0x00a1, 0xff, 0x02, 0x01) },
{ USB_DEVICE_AND_INTERFACE_INFO(MEDIATEK_VENDOR_ID, 0x00a2, 0xff, 0x00, 0x00) },
{ USB_DEVICE_AND_INTERFACE_INFO(MEDIATEK_VENDOR_ID, 0x00a2, 0xff, 0x02, 0x01) }, /* MediaTek MT6276M modem & app port */
+ { USB_DEVICE(CELLIENT_VENDOR_ID, CELLIENT_PRODUCT_MEN200) },
{ } /* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, option_ids);
diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c
index 13b8bcd..3799fa4 100644
--- a/drivers/usb/storage/scsiglue.c
+++ b/drivers/usb/storage/scsiglue.c
@@ -213,6 +213,12 @@ static int slave_configure(struct scsi_device *sdev)
if (us->fflags & US_FL_NO_READ_CAPACITY_16)
sdev->no_read_capacity_16 = 1;
+ /*
+ * Many devices do not respond properly to READ_CAPACITY_16.
+ * Tell the SCSI layer to try READ_CAPACITY_10 first.
+ */
+ sdev->try_rc_10_first = 1;
+
/* assume SPC3 or latter devices support sense size > 18 */
if (sdev->scsi_level > SCSI_SPC_2)
us->fflags |= US_FL_SANE_SENSE;
diff --git a/fs/exec.c b/fs/exec.c
index 160cd2f..fa4dd09 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -820,10 +820,10 @@ static int exec_mmap(struct mm_struct *mm)
/* Notify parent that we're no longer interested in the old VM */
tsk = current;
old_mm = current->mm;
- sync_mm_rss(tsk, old_mm);
mm_release(tsk, old_mm);
if (old_mm) {
+ sync_mm_rss(tsk, old_mm);
/*
* Make sure that if there is a core dump in progress
* for the old mm, we get out and die instead of going
diff --git a/fs/nilfs2/gcinode.c b/fs/nilfs2/gcinode.c
index 08a07a2..57ceaf3 100644
--- a/fs/nilfs2/gcinode.c
+++ b/fs/nilfs2/gcinode.c
@@ -191,6 +191,8 @@ void nilfs_remove_all_gcinodes(struct the_nilfs *nilfs)
while (!list_empty(head)) {
ii = list_first_entry(head, struct nilfs_inode_info, i_dirty);
list_del_init(&ii->i_dirty);
+ truncate_inode_pages(&ii->vfs_inode.i_data, 0);
+ nilfs_btnode_cache_clear(&ii->i_btnode_cache);
iput(&ii->vfs_inode);
}
}
diff --git a/fs/nilfs2/segment.c b/fs/nilfs2/segment.c
index bb24ab6..6f24e67 100644
--- a/fs/nilfs2/segment.c
+++ b/fs/nilfs2/segment.c
@@ -2309,6 +2309,8 @@ nilfs_remove_written_gcinodes(struct the_nilfs *nilfs, struct list_head *head)
if (!test_bit(NILFS_I_UPDATED, &ii->i_state))
continue;
list_del_init(&ii->i_dirty);
+ truncate_inode_pages(&ii->vfs_inode.i_data, 0);
+ nilfs_btnode_cache_clear(&ii->i_btnode_cache);
iput(&ii->vfs_inode);
}
}
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index a03c098..bc00876 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -445,6 +445,18 @@ static inline int pmd_write(pmd_t pmd)
#endif /* __HAVE_ARCH_PMD_WRITE */
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
+#ifndef pmd_read_atomic
+static inline pmd_t pmd_read_atomic(pmd_t *pmdp)
+{
+ /*
+ * Depend on compiler for an atomic pmd read. NOTE: this is
+ * only going to work, if the pmdval_t isn't larger than
+ * an unsigned long.
+ */
+ return *pmdp;
+}
+#endif
+
/*
* This function is meant to be used by sites walking pagetables with
* the mmap_sem hold in read mode to protect against MADV_DONTNEED and
@@ -458,14 +470,30 @@ static inline int pmd_write(pmd_t pmd)
* undefined so behaving like if the pmd was none is safe (because it
* can return none anyway). The compiler level barrier() is critically
* important to compute the two checks atomically on the same pmdval.
+ *
+ * For 32bit kernels with a 64bit large pmd_t this automatically takes
+ * care of reading the pmd atomically to avoid SMP race conditions
+ * against pmd_populate() when the mmap_sem is hold for reading by the
+ * caller (a special atomic read not done by "gcc" as in the generic
+ * version above, is also needed when THP is disabled because the page
+ * fault can populate the pmd from under us).
*/
static inline int pmd_none_or_trans_huge_or_clear_bad(pmd_t *pmd)
{
- /* depend on compiler for an atomic pmd read */
- pmd_t pmdval = *pmd;
+ pmd_t pmdval = pmd_read_atomic(pmd);
/*
* The barrier will stabilize the pmdval in a register or on
* the stack so that it will stop changing under the code.
+ *
+ * When CONFIG_TRANSPARENT_HUGEPAGE=y on x86 32bit PAE,
+ * pmd_read_atomic is allowed to return a not atomic pmdval
+ * (for example pointing to an hugepage that has never been
+ * mapped in the pmd). The below checks will only care about
+ * the low part of the pmd with 32bit PAE x86 anyway, with the
+ * exception of pmd_none(). So the important thing is that if
+ * the low part of the pmd is found null, the high part will
+ * be also null or the pmd_none() check below would be
+ * confused.
*/
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
barrier();
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 5b42f1b..e32f8e8 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -56,8 +56,18 @@ struct page {
};
union {
+#if defined(CONFIG_HAVE_CMPXCHG_DOUBLE) && \
+ defined(CONFIG_HAVE_ALIGNED_STRUCT_PAGE)
/* Used for cmpxchg_double in slub */
unsigned long counters;
+#else
+ /*
+ * Keep _count separate from slub cmpxchg_double data.
+ * As the rest of the double word is protected by
+ * slab_lock but _count is not.
+ */
+ unsigned counters;
+#endif
struct {
diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
index 5591ed5..a8f4b75 100644
--- a/include/scsi/scsi_device.h
+++ b/include/scsi/scsi_device.h
@@ -150,6 +150,7 @@ struct scsi_device {
SD_LAST_BUGGY_SECTORS */
unsigned no_read_disc_info:1; /* Avoid READ_DISC_INFO cmds */
unsigned no_read_capacity_16:1; /* Avoid READ_CAPACITY_16 cmds */
+ unsigned try_rc_10_first:1; /* Try READ_CAPACACITY_10 first */
unsigned is_visible:1; /* is the device visible in sysfs */
DECLARE_BITMAP(supported_events, SDEV_EVT_MAXBITS); /* supported events */
diff --git a/kernel/exit.c b/kernel/exit.c
index 5a8a66e..83fea52 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -641,6 +641,7 @@ static void exit_mm(struct task_struct * tsk)
mm_release(tsk, mm);
if (!mm)
return;
+ sync_mm_rss(tsk, mm);
/*
* Serialize with any possible pending coredump.
* We must hold mmap_sem around checking core_state
diff --git a/net/batman-adv/routing.c b/net/batman-adv/routing.c
index f961cc5..da587ad 100644
--- a/net/batman-adv/routing.c
+++ b/net/batman-adv/routing.c
@@ -619,6 +619,8 @@ int recv_tt_query(struct sk_buff *skb, struct hard_iface *recv_if)
/* packet needs to be linearized to access the TT changes */
if (skb_linearize(skb) < 0)
goto out;
+ /* skb_linearize() possibly changed skb->data */
+ tt_query = (struct tt_query_packet *)skb->data;
if (is_my_mac(tt_query->dst))
handle_tt_response(bat_priv, tt_query);
diff --git a/net/batman-adv/translation-table.c b/net/batman-adv/translation-table.c
index 5f09a57..088af45 100644
--- a/net/batman-adv/translation-table.c
+++ b/net/batman-adv/translation-table.c
@@ -1816,10 +1816,10 @@ bool is_ap_isolated(struct bat_priv *bat_priv, uint8_t *src, uint8_t *dst)
{
struct tt_local_entry *tt_local_entry = NULL;
struct tt_global_entry *tt_global_entry = NULL;
- bool ret = true;
+ bool ret = false;
if (!atomic_read(&bat_priv->ap_isolation))
- return false;
+ goto out;
tt_local_entry = tt_local_hash_find(bat_priv, dst);
if (!tt_local_entry)
@@ -1829,10 +1829,10 @@ bool is_ap_isolated(struct bat_priv *bat_priv, uint8_t *src, uint8_t *dst)
if (!tt_global_entry)
goto out;
- if (_is_ap_isolated(tt_local_entry, tt_global_entry))
+ if (!_is_ap_isolated(tt_local_entry, tt_global_entry))
goto out;
- ret = false;
+ ret = true;
out:
if (tt_global_entry)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index c1c99dd..d57d05b 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1369,7 +1369,7 @@ static void reg_set_request_processed(void)
spin_unlock(®_requests_lock);
if (last_request->initiator == NL80211_REGDOM_SET_BY_USER)
- cancel_delayed_work_sync(®_timeout);
+ cancel_delayed_work(®_timeout);
if (need_more_processing)
schedule_work(®_work);
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 0005bde..5f096a5 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5988,6 +5988,7 @@ static const struct hda_codec_preset snd_hda_preset_realtek[] = {
{ .id = 0x10ec0272, .name = "ALC272", .patch = patch_alc662 },
{ .id = 0x10ec0275, .name = "ALC275", .patch = patch_alc269 },
{ .id = 0x10ec0276, .name = "ALC276", .patch = patch_alc269 },
+ { .id = 0x10ec0280, .name = "ALC280", .patch = patch_alc269 },
{ .id = 0x10ec0861, .rev = 0x100340, .name = "ALC660",
.patch = patch_alc861 },
{ .id = 0x10ec0660, .name = "ALC660-VD", .patch = patch_alc861vd },
diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index 11224ed..323d4d9 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -384,14 +384,18 @@ int main(void)
pfd.fd = fd;
while (1) {
+ struct sockaddr *addr_p = (struct sockaddr *) &addr;
+ socklen_t addr_l = sizeof(addr);
pfd.events = POLLIN;
pfd.revents = 0;
poll(&pfd, 1, -1);
- len = recv(fd, kvp_recv_buffer, sizeof(kvp_recv_buffer), 0);
+ len = recvfrom(fd, kvp_recv_buffer, sizeof(kvp_recv_buffer), 0,
+ addr_p, &addr_l);
- if (len < 0) {
- syslog(LOG_ERR, "recv failed; error:%d", len);
+ if (len < 0 || addr.nl_pid) {
+ syslog(LOG_ERR, "recvfrom failed; pid:%u error:%d %s",
+ addr.nl_pid, errno, strerror(errno));
close(fd);
return -1;
}
--
Ben Hutchings
If you seem to know what you are doing, you'll be given more to do.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply related [flat|nested] 78+ messages in thread