[085/251] xhci: fix null pointer dereference on ring_doorbell_for_active_rings

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Oleksij Rempel 

[ Upstream commit d66eaf9f89502971fddcb0de550b01fa6f409d83 ]

in some cases where device is attched to xhci port and do not responding,
for example ath9k_htc with stalled firmware, kernel will
crash on ring_doorbell_for_active_rings.
This patch check if pointer exist before it is used.

This patch should be backported to kernels as old as 2.6.35, that
contain the commit e9df17eb1408cfafa3d1844bfc7f22c7237b31b8 "USB: xhci:
Correct assumptions about number of rings per endpoint"

Signed-off-by: Oleksij Rempel 
Signed-off-by: Sarah Sharp 
Cc: sta...@vger.kernel.org
Signed-off-by: Steven Rostedt 
---
 drivers/usb/host/xhci-ring.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 8848616..21a01ac 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -434,7 +434,7 @@ static void ring_doorbell_for_active_rings(struct xhci_hcd 
*xhci,
 
/* A ring has pending URBs if its TD list is not empty */
if (!(ep->ep_state & EP_HAS_STREAMS)) {
-   if (!(list_empty(>ring->td_list)))
+   if (ep->ring && !(list_empty(>ring->td_list)))
xhci_ring_ep_doorbell(xhci, slot_id, ep_index, 0);
return;
}
-- 
1.7.10.4


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

Re: [GIT PULL 0/5] perf/urgent fixes

[Ingo Molnar]

Hm, after this pull request, 'perf top' started misbehaving on older 
kernels:
 
 
┌─Error:┐
 │The sys_perf_event_open() syscall returned with 22 (Invalid 
argument) for event (cycles).  │
 │/bin/dmesg may provide additional information.
 │
 │No CONFIG_PERF_EVENTS=y kernel support configured?
 │

But:

 $ cat /proc/sys/kernel/perf_event_paranoid 
 -1

The syscall really fails:

 16645 perf_event_open(0x1eb7f00, 0x, 0, 0x, 0) = -1 EINVAL 
(Invalid argument)
 16645 perf_event_open(0x1eb7f00, 0x, 0, 0x, 0) = -1 EINVAL 
(Invalid argument)
 16645 perf_event_open(0x1eb7f00, 0x, 0, 0x, 0) = -1 EINVAL 
(Invalid argument)

Caused by:

 575a9aab0f85 perf tools: Add attr->mmap2 support

We must not force mmap2 support to be present on the kernel side - new 
perf top should work on older kernels just as well.

So I've unpulled the tree for now.

Thanks,

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

RE: [PATCH] hwmon: (ms5637) Add Measurement Specialties MS5637 support

[Markezana, William]

Hi Guenter,

Thank you for your feedback, I will rewrite the drivers for IIO then.

Best regards,

William MARKEZANA
Direct : + 33 (0) 582 082 286
http://www.meas-spec.com


-Message d'origine-
De : Guenter Roeck [mailto:groe...@gmail.com] De la part de Guenter Roeck
Envoyé : mardi 10 septembre 2013 17:21
À : Markezana, William
Cc : kh...@linux-fr.org; lm-sens...@lm-sensors.org; linux-kernel@vger.kernel.org
Objet : Re: [PATCH] hwmon: (ms5637) Add Measurement Specialties MS5637 support

On Tue, Sep 10, 2013 at 05:09:57PM +0200, Markezana, William wrote:
> From: William Markezana 
> 
> hwmon: (ms5637) Add Measurement Specialties MS5637support
> Signed-off-by: William Markezana 

Hi William,

"pressure" is hardly a hardware monitoring attribute. It might make more sense 
to add your driver to the iio subsystem, which already supports at least one 
other pressure sensor.

Thanks,
Guenter

> ---
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig index 
> 55973cd..c4f1c8e 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -954,6 +954,16 @@ config SENSORS_MCP3021
> This driver can also be built as a module.  If so, the module
> will be called mcp3021.
>  
> +config SENSORS_MS5637
> + tristate "Measurement Specialties MS5637 pressure sensors"
> + depends on I2C
> + help
> +   If you say yes here you get support for the Measurement Specialties
> +   MS5637 pressure sensors.
> +
> +   This driver can also be built as a module.  If so, the module
> +   will be called ms5637.
> +
>  config SENSORS_NCT6775
>   tristate "Nuvoton NCT6775F and compatibles"
>   depends on !PPC
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile index 
> ec7cde0..5d8f699 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -110,6 +110,7 @@ obj-$(CONFIG_SENSORS_MAX6650) += max6650.o
>  obj-$(CONFIG_SENSORS_MAX6697)+= max6697.o
>  obj-$(CONFIG_SENSORS_MC13783_ADC)+= mc13783-adc.o
>  obj-$(CONFIG_SENSORS_MCP3021)+= mcp3021.o
> +obj-$(CONFIG_SENSORS_MS5637) += ms5637.o
>  obj-$(CONFIG_SENSORS_NCT6775)+= nct6775.o
>  obj-$(CONFIG_SENSORS_NTC_THERMISTOR) += ntc_thermistor.o
>  obj-$(CONFIG_SENSORS_PC87360)+= pc87360.o
> diff --git a/drivers/hwmon/ms5637.c b/drivers/hwmon/ms5637.c new file 
> mode 100644 index 000..fe2c2df
> --- /dev/null
> +++ b/drivers/hwmon/ms5637.c
> @@ -0,0 +1,302 @@
> +/*
> + * Measurement Specialties MS5637 pressure and temperature sensor 
> +driver
> + *
> + * Copyright (C) 2013 William Markezana 
> +
> + *
> + * This program is free software; you can redistribute it and/or 
> +modify
> + * it under the terms of the GNU General Public License as published 
> +by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* MS5637 Commands */
> +#define MS5637_CONVERT_D1_OSR_4096   (0x48)
> +#define MS5637_CONVERT_D2_OSR_4096   (0x58)
> +#define MS5637_ADC_READ  (0x00)
> +#define MS5637_PROM_READ (0xA0)
> +
> +struct ms5637 {
> + struct device *hwmon_dev;
> + struct mutex lock;
> + bool valid;
> + unsigned long last_update;
> + int temperature;
> + int pressure;
> + unsigned short calibration_words[6];
> + bool got_calibration_words;
> +};
> +
> +static int ms5637_get_calibration_word(struct i2c_client *client,
> + unsigned char address, unsigned short *word) {
> + int ret = 0;
> + ret = i2c_smbus_read_word_swapped(client,
> + MS5637_PROM_READ + (address << 1));
> + if (ret < 0)
> + return ret;
> + *word = (unsigned short)ret & 0x;
> + return 0;
> +}
> +
> +static int ms5637_fill_calibration_words(struct i2c_client *client) {
> + int i, ret = 0;
> + struct ms5637 *ms5637 = i2c_get_clientdata(client);
> +
> + for (i = 0; i < 6; i++) {
> + ret = ms5637_get_calibration_word(client, i+1,
> + >calibration_words[i]);
> + if (ret < 0) {
> + dev_err(>dev,
> + "unable to get calibration word at address 
> %d\n",
> + i+1);
> + return ret;
> + }
> + }
> + return 0;
> +}
> +
> +static int ms5637_get_adc_value(struct i2c_client *client,
> + unsigned int *adc_value)
> +{
> + int ret = 0;
> + unsigned char buf[3];
> + ret = i2c_smbus_read_i2c_block_data(client, MS5637_ADC_READ, 3, buf);

Re: [GIT PULL 0/5] perf/urgent fixes

[Ingo Molnar]

* Arnaldo Carvalho de Melo  wrote:

> From: Arnaldo Carvalho de Melo 
> 
> Hi Ingo,
> 
>   Please consider pulling,
> 
> - Arnaldo
> 
> The following changes since commit 72f4a11d2fb16792f5e5107922652366194cfd66:
> 
>   Merge tag 'perf-urgent-for-mingo' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent 
> (2013-09-06 14:08:08 +0200)
> 
> are available in the git repository at:
> 
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux 
> tags/perf-urgent-for-mingo
> 
> for you to fetch changes up to e08eedca944bd6419c9441012e98e7af14ebd175:
> 
>   perf: Fix up MMAP2 buffer space reservation (2013-09-10 10:42:20 -0300)
> 
> 
> perf/urgent fixes:
> 
> . Handle perf.data files with no tracepoints in 'perf trace', fixing a
>   segfault.
> 
> . Fix up MMAP2 buffer space reservation, a problem that was caught via
>   'perf test' consistency tests.
> 
> . Add attr->mmap2 support in the tools, a patch that should've been merged
>   together with the kernel counterpart:
> 
> 13d7a24 "perf: Add attr->mmap2 attribute to an event".
> 
>   Merging it allowed us to catch the MMAP buffer space reservation problem via
>   'perf test'. From Stephane Eranian.
> 
> . Make sure we can find PERF_SAMPLE_ID in the variable part of PERF_RECORD_
>   ring buffer records in 'perf kvm', where direct manipulation of sample_type
>   was being done.
> 
>   Fixed by making use of the perf_evlist__set_sample_bit() helper and by
>   setting the evlist->id_pos in perf_evlist__open(), from Adrian Hunter.
> 
> Signed-off-by: Arnaldo Carvalho de Melo 
> 
> 
> Adrian Hunter (2):
>   perf evlist: Fix id pos in perf_evlist__open()
>   perf kvm: Fix sample_type manipulation
> 
> Arnaldo Carvalho de Melo (2):
>   perf trace: Handle perf.data files with no tracepoints
>   perf: Fix up MMAP2 buffer space reservation
> 
> Stephane Eranian (1):
>   perf tools: Add attr->mmap2 support
> 
>  kernel/events/core.c   |  1 +
>  tools/perf/builtin-annotate.c  |  1 +
>  tools/perf/builtin-inject.c| 15 ++
>  tools/perf/builtin-kvm.c   | 18 ++--
>  tools/perf/builtin-mem.c   |  1 +
>  tools/perf/builtin-report.c|  1 +
>  tools/perf/builtin-script.c|  1 +
>  tools/perf/tests/perf-record.c | 15 +++---
>  tools/perf/util/build-id.c |  1 +
>  tools/perf/util/event.c| 56 
>  tools/perf/util/event.h| 19 
>  tools/perf/util/evlist.c   | 12 
>  tools/perf/util/evsel.c|  5 ++--
>  tools/perf/util/header.c   |  3 ++
>  tools/perf/util/machine.c  | 53 +-
>  tools/perf/util/machine.h  |  1 +
>  tools/perf/util/map.c  |  8 +-
>  tools/perf/util/map.h  |  8 --
>  tools/perf/util/session.c  | 65 
> --
>  tools/perf/util/tool.h |  1 +
>  20 files changed, 220 insertions(+), 65 deletions(-)

Pulled, thanks Arnaldo!

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

[170/251] hwmon: (adt7470) Fix incorrect return code check

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Curt Brune 

[ Upstream commit 93d783bcca69bfacc8dc739d8a050498402587b5 ]

In adt7470_write_word_data(), which writes two bytes using
i2c_smbus_write_byte_data(), the return codes are incorrectly AND-ed
together when they should be OR-ed together.

The return code of i2c_smbus_write_byte_data() is zero for success.

The upshot is only the first byte was ever written to the hardware.
The 2nd byte was never written out.

I noticed that trying to set the fan speed limits was not working
correctly on my system.  Setting the fan speed limits is the only
code that uses adt7470_write_word_data().  After making the change
the limit settings work and the alarms work also.

Signed-off-by: Curt Brune 
Cc: sta...@vger.kernel.org
Signed-off-by: Guenter Roeck 
Signed-off-by: Steven Rostedt 
---
 drivers/hwmon/adt7470.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwmon/adt7470.c b/drivers/hwmon/adt7470.c
index 54ec8905..034085d 100644
--- a/drivers/hwmon/adt7470.c
+++ b/drivers/hwmon/adt7470.c
@@ -215,7 +215,7 @@ static inline int adt7470_write_word_data(struct i2c_client 
*client, u8 reg,
  u16 value)
 {
return i2c_smbus_write_byte_data(client, reg, value & 0xFF)
-  && i2c_smbus_write_byte_data(client, reg + 1, value >> 8);
+  || i2c_smbus_write_byte_data(client, reg + 1, value >> 8);
 }
 
 static void adt7470_init_client(struct i2c_client *client)
-- 
1.7.10.4


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

[169/251] regmap: Add missing header for !CONFIG_REGMAP stubs

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Mateusz Krawczuk 

[ Upstream commit 49ccc142f9cbc33fdda18e8fa90c1c5b4a79c0ad ]

regmap.h requires linux/err.h if CONFIG_REGMAP is not defined. Without it I get
error.
CC  drivers/media/platform/exynos4-is/fimc-reg.o
In file included from drivers/media/platform/exynos4-is/fimc-reg.c:14:0:
include/linux/regmap.h: In function ‘regmap_write’:
include/linux/regmap.h:525:10: error: ‘EINVAL’ undeclared (first use in 
this function)
include/linux/regmap.h:525:10: note: each undeclared identifier is reported 
only once for each function it appears in

Signed-off-by: Mateusz Krawczuk 
Signed-off-by: Kyungmin Park 
Signed-off-by: Mark Brown 
Cc: sta...@kernel.org
Signed-off-by: Steven Rostedt 
---
 include/linux/regmap.h |1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/regmap.h b/include/linux/regmap.h
index 7f7e00d..519d5f2 100644
--- a/include/linux/regmap.h
+++ b/include/linux/regmap.h
@@ -15,6 +15,7 @@
 
 #include 
 #include 
+#include 
 
 struct module;
 struct device;
-- 
1.7.10.4


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

Re: [f2fs-dev][PATCH] f2fs: optimize fs_lock for better performance

[Gu Zheng]

Hi Jaegeuk, Chao,

On 09/10/2013 08:52 AM, Jaegeuk Kim wrote:

> Hi,
> 
> At first, thank you for the report and please follow the email writing
> rules. :)
> 
> Anyway, I agree to the below issue.
> One thing that I can think of is that we don't need to use the
> spin_lock, since we don't care about the exact lock number, but just
> need to get any not-collided number.

IMHO, just moving sbi->next_lock_num++ before 
mutex_lock(>fs_lock[next_lock])
can avoid unbalance issue mostly.
IMO, the case two or more threads increase sbi->next_lock_num in the same time 
is
really very very little. If you think it is not rigorous, change next_lock_num 
to
atomic one can fix it.
What's your opinion?

Regards,
Gu

> 
> So, how about removing the spin_lock?
> And how about using a random number?

> Thanks,
> 
> 2013-09-06 (금), 09:48 +, Chao Yu:
>> Hi Kim:
>>
>>  I think there is a performance problem: when all sbi->fs_lock is
>> holded, 
>>
>> then all other threads may get the same next_lock value from
>> sbi->next_lock_num in function mutex_lock_op, 
>>
>> and wait to get the same lock at position fs_lock[next_lock], it
>> unbalance the fs_lock usage. 
>>
>> It may lost performance when we do the multithread test.
>>
>>  
>>
>> Here is the patch to fix this problem:
>>
>>  
>>
>> Signed-off-by: Yu Chao 
>>
>> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
>>
>> old mode 100644
>>
>> new mode 100755
>>
>> index 467d42d..983bb45
>>
>> --- a/fs/f2fs/f2fs.h
>>
>> +++ b/fs/f2fs/f2fs.h
>>
>> @@ -371,6 +371,7 @@ struct f2fs_sb_info {
>>
>> struct mutex fs_lock[NR_GLOBAL_LOCKS];  /* blocking FS
>> operations */
>>
>> struct mutex node_write;/* locking node writes
>> */
>>
>> struct mutex writepages;/* mutex for
>> writepages() */
>>
>> +   spinlock_t spin_lock;   /* lock for
>> next_lock_num */
>>
>> unsigned char next_lock_num;/* round-robin global
>> locks */
>>
>> int por_doing;  /* recovery is doing
>> or not */
>>
>> int on_build_free_nids; /* build_free_nids is
>> doing */
>>
>> @@ -533,15 +534,19 @@ static inline void mutex_unlock_all(struct
>> f2fs_sb_info *sbi)
>>
>>  
>>
>>  static inline int mutex_lock_op(struct f2fs_sb_info *sbi)
>>
>>  {
>>
>> -   unsigned char next_lock = sbi->next_lock_num %
>> NR_GLOBAL_LOCKS;
>>
>> +   unsigned char next_lock;
>>
>> int i = 0;
>>
>>  
>>
>> for (; i < NR_GLOBAL_LOCKS; i++)
>>
>> if (mutex_trylock(>fs_lock[i]))
>>
>> return i;
>>
>>  
>>
>> -   mutex_lock(>fs_lock[next_lock]);
>>
>> +   spin_lock(>spin_lock);
>>
>> +   next_lock = sbi->next_lock_num % NR_GLOBAL_LOCKS;
>>
>> sbi->next_lock_num++;
>>
>> +   spin_unlock(>spin_lock);
>>
>> +
>>
>> +   mutex_lock(>fs_lock[next_lock]);
>>
>> return next_lock;
>>
>>  }
>>
>>  
>>
>> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
>>
>> old mode 100644
>>
>> new mode 100755
>>
>> index 75c7dc3..4f27596
>>
>> --- a/fs/f2fs/super.c
>>
>> +++ b/fs/f2fs/super.c
>>
>> @@ -657,6 +657,7 @@ static int f2fs_fill_super(struct super_block *sb,
>> void *data, int silent)
>>
>> mutex_init(>cp_mutex);
>>
>> for (i = 0; i < NR_GLOBAL_LOCKS; i++)
>>
>> mutex_init(>fs_lock[i]);
>>
>> +   spin_lock_init(>spin_lock);
>>
>> mutex_init(>node_write);
>>
>> sbi->por_doing = 0;
>>
>> spin_lock_init(>stat_lock);
>>
>> (END)
>>
>>  
>>
>>
>>
>>
> 


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

[171/251] tracing: Fix fields of struct trace_iterator that are zeroed by mistake

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Andrew Vagin 

[ Upstream commit ed5467da0e369e65b247b99eb6403cb79172bcda ]

tracing_read_pipe zeros all fields bellow "seq". The declaration contains
a comment about that, but it doesn't help.

The first field is "snapshot", it's true when current open file is
snapshot. Looks obvious, that it should not be zeroed.

The second field is "started". It was converted from cpumask_t to
cpumask_var_t (v2.6.28-4983-g4462344), in other words it was
converted from cpumask to pointer on cpumask.

Currently the reference on "started" memory is lost after the first read
from tracing_read_pipe and a proper object will never be freed.

The "started" is never dereferenced for trace_pipe, because trace_pipe
can't have the TRACE_FILE_ANNOTATE options.

Link: 
http://lkml.kernel.org/r/1375463803-3085183-1-git-send-email-ava...@openvz.org

Cc: sta...@vger.kernel.org # 2.6.30
Signed-off-by: Andrew Vagin 
Signed-off-by: Steven Rostedt 
---
 include/linux/ftrace_event.h |4 +++-
 kernel/trace/trace.c |1 +
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index 642928c..86e6806 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -71,6 +71,8 @@ struct trace_iterator {
/* trace_seq for __print_flags() and __print_symbolic() etc. */
struct trace_seqtmp_seq;
 
+   cpumask_var_t   started;
+
/* The below is zeroed out in pipe_read */
struct trace_seqseq;
struct trace_entry  *ent;
@@ -83,7 +85,7 @@ struct trace_iterator {
loff_t  pos;
longidx;
 
-   cpumask_var_t   started;
+   /* All new field here will be zeroed out in pipe_read */
 };
 
 
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index a3e9083..0686c13 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -3542,6 +3542,7 @@ waitagain:
memset(>seq, 0,
   sizeof(struct trace_iterator) -
   offsetof(struct trace_iterator, seq));
+   cpumask_clear(iter->started);
iter->pos = -1;
 
trace_event_read_lock();
-- 
1.7.10.4


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

[164/251] ndisc: Add missing inline to ndisc_addr_option_pad

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Joe Perches 

[ Upstream commit d9d10a30964504af834d8d250a0c76d4ae91eb1e ]

Signed-off-by: Joe Perches 
Signed-off-by: David S. Miller 
Signed-off-by: Steven Rostedt 
---
 include/net/ndisc.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/net/ndisc.h b/include/net/ndisc.h
index 826a541..9761757 100644
--- a/include/net/ndisc.h
+++ b/include/net/ndisc.h
@@ -118,7 +118,7 @@ extern struct ndisc_options *ndisc_parse_options(u8 *opt, 
int opt_len,
  * if RFC 3831 IPv6-over-Fibre Channel is ever implemented it may
  * also need a pad of 2.
  */
-static int ndisc_addr_option_pad(unsigned short type)
+static inline int ndisc_addr_option_pad(unsigned short type)
 {
switch (type) {
case ARPHRD_INFINIBAND: return 2;
-- 
1.7.10.4


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

[168/251] ext4: make sure group number is bumped after a inode allocation race

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Theodore Ts'o 

[ Upstream commit a34eb503742fd25155fd6cff6163daacead9fbc3 ]

When we try to allocate an inode, and there is a race between two
CPU's trying to grab the same inode, _and_ this inode is the last free
inode in the block group, make sure the group number is bumped before
we continue searching the rest of the block groups.  Otherwise, we end
up searching the current block group twice, and we end up skipping
searching the last block group.  So in the unlikely situation where
almost all of the inodes are allocated, it's possible that we will
return ENOSPC even though there might be free inodes in that last
block group.

Signed-off-by: "Theodore Ts'o" 
Cc: sta...@vger.kernel.org
Signed-off-by: Steven Rostedt 
---
 fs/ext4/ialloc.c |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c
index c690ff9..16481bd 100644
--- a/fs/ext4/ialloc.c
+++ b/fs/ext4/ialloc.c
@@ -706,11 +706,8 @@ repeat_in_this_group:
ino = ext4_find_next_zero_bit((unsigned long *)
  inode_bitmap_bh->b_data,
  EXT4_INODES_PER_GROUP(sb), ino);
-   if (ino >= EXT4_INODES_PER_GROUP(sb)) {
-   if (++group == ngroups)
-   group = 0;
-   continue;
-   }
+   if (ino >= EXT4_INODES_PER_GROUP(sb))
+   goto next_group;
if (group == 0 && (ino+1) < EXT4_FIRST_INO(sb)) {
ext4_error(sb, "reserved inode found cleared - "
   "inode=%lu", ino + 1);
@@ -728,6 +725,9 @@ repeat_in_this_group:
goto got; /* we grabbed the inode! */
if (ino < EXT4_INODES_PER_GROUP(sb))
goto repeat_in_this_group;
+next_group:
+   if (++group == ngroups)
+   group = 0;
}
err = -ENOSPC;
goto out;
-- 
1.7.10.4


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

[251/251] target: Fix trailing ASCII space usage in INQUIRY vendor+model

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Nicholas Bellinger 

[ Upstream commit ee60bddba5a5f23e39598195d944aa0eb2d455e5 ]

This patch fixes spc_emulate_inquiry_std() to add trailing ASCII
spaces for INQUIRY vendor + model fields following SPC-4 text:

  "ASCII data fields described as being left-aligned shall have any
   unused bytes at the end of the field (i.e., highest offset) and
   the unused bytes shall be filled with ASCII space characters (20h)."

This addresses a problem with Falconstor NSS multipathing.

Reported-by: Tomas Molota 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Steven Rostedt 
---
 drivers/target/target_core_spc.c |9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/target/target_core_spc.c b/drivers/target/target_core_spc.c
index 6fd434d..290041b 100644
--- a/drivers/target/target_core_spc.c
+++ b/drivers/target/target_core_spc.c
@@ -100,9 +100,12 @@ static int spc_emulate_inquiry_std(struct se_cmd *cmd, 
char *buf)
 
buf[7] = 0x2; /* CmdQue=1 */
 
-   snprintf([8], 8, "LIO-ORG");
-   snprintf([16], 16, "%s", dev->se_sub_dev->t10_wwn.model);
-   snprintf([32], 4, "%s", dev->se_sub_dev->t10_wwn.revision);
+   memcpy([8], "LIO-ORG ", 8);
+   memset([16], 0x20, 16);
+   memcpy([16], dev->se_sub_dev->t10_wwn.model,
+  min_t(size_t, strlen(dev->se_sub_dev->t10_wwn.model), 16));
+   memcpy([32], dev->se_sub_dev->t10_wwn.revision,
+  min_t(size_t, strlen(dev->se_sub_dev->t10_wwn.revision), 4));
buf[4] = 31; /* Set additional length to 31 */
 
return 0;
-- 
1.7.10.4


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

[166/251] Dont attempt to send extended INQUIRY command if skip_vpd_pages is set

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: "Martin K. Petersen" 

[ Upstream commit 7562523e84ddc742fe1f9db8bd76b01acca89f6b ]

If a device has the skip_vpd_pages flag set we should simply fail the
scsi_get_vpd_page() call.

Signed-off-by: Martin K. Petersen 
Acked-by: Alan Stern 
Tested-by: Stuart Foster 
Cc: sta...@vger.kernel.org
Signed-off-by: James Bottomley 
Signed-off-by: Steven Rostedt 
---
 drivers/scsi/scsi.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index 2936b44..5dba497 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -1030,6 +1030,9 @@ int scsi_get_vpd_page(struct scsi_device *sdev, u8 page, 
unsigned char *buf,
 {
int i, result;
 
+   if (sdev->skip_vpd_pages)
+   goto fail;
+
/* Ask for all the pages supported by this device */
result = scsi_vpd_inquiry(sdev, buf, 0, buf_len);
if (result)
-- 
1.7.10.4


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

[162/251] atl1c: Fix misuse of netdev_alloc_skb in refilling rx ring

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Eric Dumazet 

[ Upstream commit 7b70176421993866e616f1cbc4d0dd4054f1bf78 ]

On Mon, 2013-07-29 at 08:30 -0700, Eric Dumazet wrote:
> On Mon, 2013-07-29 at 13:09 +0100, Luis Henriques wrote:
>
> >
> > I confirm that I can't reproduce the issue using this patch.
> >
>
> Thanks, I'll send a polished patch, as this one had an error if
> build_skb() returns NULL (in case sk_buff allocation fails)

Please try the following patch : It should use 2K frags instead of 4K
for normal 1500 mtu

Thanks !

[PATCH] atl1c: use custom skb allocator

We had reports ( https://bugzilla.kernel.org/show_bug.cgi?id=54021 )
that using high order pages for skb allocations is problematic for atl1c

We do not know exactly what the problem is, but we suspect that crossing
4K pages is not well supported by this hardware.

Use a custom allocator, using page allocator and 2K fragments for
optimal stack behavior. We might make this allocator generic
in future kernels.

Signed-off-by: Eric Dumazet 
Cc: Luis Henriques 
Cc: Neil Horman 
Signed-off-by: David S. Miller 
Signed-off-by: Steven Rostedt 
---
 drivers/net/ethernet/atheros/atl1c/atl1c.h  |3 ++
 drivers/net/ethernet/atheros/atl1c/atl1c_main.c |   40 ++-
 2 files changed, 42 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c.h 
b/drivers/net/ethernet/atheros/atl1c/atl1c.h
index b2bf324..0f05565 100644
--- a/drivers/net/ethernet/atheros/atl1c/atl1c.h
+++ b/drivers/net/ethernet/atheros/atl1c/atl1c.h
@@ -520,6 +520,9 @@ struct atl1c_adapter {
struct net_device   *netdev;
struct pci_dev  *pdev;
struct napi_struct  napi;
+   struct page *rx_page;
+   unsigned intrx_page_offset;
+   unsigned intrx_frag_size;
struct atl1c_hwhw;
struct atl1c_hw_stats  hw_stats;
struct mii_if_info  mii;/* MII interface info */
diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c 
b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
index 1bf5bbf..033226b 100644
--- a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
+++ b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
@@ -482,10 +482,15 @@ static int atl1c_set_mac_addr(struct net_device *netdev, 
void *p)
 static void atl1c_set_rxbufsize(struct atl1c_adapter *adapter,
struct net_device *dev)
 {
+   unsigned int head_size;
int mtu = dev->mtu;
 
adapter->rx_buffer_len = mtu > AT_RX_BUF_SIZE ?
roundup(mtu + ETH_HLEN + ETH_FCS_LEN + VLAN_HLEN, 8) : 
AT_RX_BUF_SIZE;
+
+   head_size = SKB_DATA_ALIGN(adapter->rx_buffer_len + NET_SKB_PAD) +
+   SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
+   adapter->rx_frag_size = roundup_pow_of_two(head_size);
 }
 
 static netdev_features_t atl1c_fix_features(struct net_device *netdev,
@@ -953,6 +958,10 @@ static void atl1c_free_ring_resources(struct atl1c_adapter 
*adapter)
kfree(adapter->tpd_ring[0].buffer_info);
adapter->tpd_ring[0].buffer_info = NULL;
}
+   if (adapter->rx_page) {
+   put_page(adapter->rx_page);
+   adapter->rx_page = NULL;
+   }
 }
 
 /**
@@ -1642,6 +1651,35 @@ static inline void atl1c_rx_checksum(struct 
atl1c_adapter *adapter,
skb_checksum_none_assert(skb);
 }
 
+static struct sk_buff *atl1c_alloc_skb(struct atl1c_adapter *adapter)
+{
+   struct sk_buff *skb;
+   struct page *page;
+
+   if (adapter->rx_frag_size > PAGE_SIZE)
+   return netdev_alloc_skb(adapter->netdev,
+   adapter->rx_buffer_len);
+
+   page = adapter->rx_page;
+   if (!page) {
+   adapter->rx_page = page = alloc_page(GFP_ATOMIC);
+   if (unlikely(!page))
+   return NULL;
+   adapter->rx_page_offset = 0;
+   }
+
+   skb = build_skb(page_address(page) + adapter->rx_page_offset,
+   adapter->rx_frag_size);
+   if (likely(skb)) {
+   adapter->rx_page_offset += adapter->rx_frag_size;
+   if (adapter->rx_page_offset >= PAGE_SIZE)
+   adapter->rx_page = NULL;
+   else
+   get_page(page);
+   }
+   return skb;
+}
+
 static int atl1c_alloc_rx_buffer(struct atl1c_adapter *adapter)
 {
struct atl1c_rfd_ring *rfd_ring = >rfd_ring;
@@ -1662,7 +1700,7 @@ static int atl1c_alloc_rx_buffer(struct atl1c_adapter 
*adapter)
while (next_info->flags & ATL1C_BUFFER_FREE) {
rfd_desc = ATL1C_RFD_DESC(rfd_ring, rfd_next_to_use);
 
-   skb = netdev_alloc_skb(adapter->netdev, adapter->rx_buffer_len);
+   skb = atl1c_alloc_skb(adapter);
if (unlikely(!skb)) {
if (netif_msg_rx_err(adapter))
   

[160/251] net_sched: Fix stack info leak in cbq_dump_wrr().

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: "David S. Miller" 

[ Upstream commit a0db856a95a29efb1c23db55c02d9f0ff4f0db48 ]

Make sure the reserved fields, and padding (if any), are
fully initialized.

Based upon a patch by Dan Carpenter and feedback from
Joe Perches.

Signed-off-by: David S. Miller 
Signed-off-by: Steven Rostedt 
---
 net/sched/sch_cbq.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/net/sched/sch_cbq.c b/net/sched/sch_cbq.c
index 611d5e9..823f07f 100644
--- a/net/sched/sch_cbq.c
+++ b/net/sched/sch_cbq.c
@@ -1469,6 +1469,7 @@ static int cbq_dump_wrr(struct sk_buff *skb, struct 
cbq_class *cl)
unsigned char *b = skb_tail_pointer(skb);
struct tc_cbq_wrropt opt;
 
+   memset(, 0, sizeof(opt));
opt.flags = 0;
opt.allot = cl->allot;
opt.priority = cl->priority + 1;
-- 
1.7.10.4


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

[161/251] af_key: more info leaks in pfkey messages

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Dan Carpenter 

[ Upstream commit ff862a4668dd6dba962b1d2d8bd344afa6375683 ]

This is inspired by a5cc68f3d6 "af_key: fix info leaks in notify
messages".  There are some struct members which don't get initialized
and could disclose small amounts of private information.

Acked-by: Mathias Krause 
Signed-off-by: Dan Carpenter 
Acked-by: Steffen Klassert 
Signed-off-by: David S. Miller 
Signed-off-by: Steven Rostedt 
---
 net/key/af_key.c |4 
 1 file changed, 4 insertions(+)

diff --git a/net/key/af_key.c b/net/key/af_key.c
index 34e4185..5c6b2f0 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -2072,6 +2072,7 @@ static int pfkey_xfrm_policy2msg(struct sk_buff *skb, 
const struct xfrm_policy *
pol->sadb_x_policy_type = IPSEC_POLICY_NONE;
}
pol->sadb_x_policy_dir = dir+1;
+   pol->sadb_x_policy_reserved = 0;
pol->sadb_x_policy_id = xp->index;
pol->sadb_x_policy_priority = xp->priority;
 
@@ -3106,7 +3107,9 @@ static int pfkey_send_acquire(struct xfrm_state *x, 
struct xfrm_tmpl *t, struct
pol->sadb_x_policy_exttype = SADB_X_EXT_POLICY;
pol->sadb_x_policy_type = IPSEC_POLICY_IPSEC;
pol->sadb_x_policy_dir = dir+1;
+   pol->sadb_x_policy_reserved = 0;
pol->sadb_x_policy_id = xp->index;
+   pol->sadb_x_policy_priority = xp->priority;
 
/* Set sadb_comb's. */
if (x->id.proto == IPPROTO_AH)
@@ -3494,6 +3497,7 @@ static int pfkey_send_migrate(const struct xfrm_selector 
*sel, u8 dir, u8 type,
pol->sadb_x_policy_exttype = SADB_X_EXT_POLICY;
pol->sadb_x_policy_type = IPSEC_POLICY_IPSEC;
pol->sadb_x_policy_dir = dir + 1;
+   pol->sadb_x_policy_reserved = 0;
pol->sadb_x_policy_id = 0;
pol->sadb_x_policy_priority = 0;
 
-- 
1.7.10.4


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

[165/251] 8139cp: Add dma_mapping_error checking

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Neil Horman 

[ Upstream commit cf3c4c03060b688cbc389ebc5065ebcce5653e96 ]

Self explanitory dma_mapping_error addition to the 8139 driver, based on this:
https://bugzilla.redhat.com/show_bug.cgi?id=947250

It showed several backtraces arising for dma_map_* usage without checking the
return code on the mapping.  Add the check and abort the rx/tx operation if its
failed.  Untested as I have no hardware and the reporter has wandered off, but
seems pretty straightforward.

Signed-off-by: Neil Horman 
CC: "David S. Miller" 
CC: Francois Romieu 
Signed-off-by: David S. Miller 
Signed-off-by: Steven Rostedt 
---
 drivers/net/ethernet/realtek/8139cp.c |   48 ++---
 1 file changed, 45 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/realtek/8139cp.c 
b/drivers/net/ethernet/realtek/8139cp.c
index dd3371b..e933d57 100644
--- a/drivers/net/ethernet/realtek/8139cp.c
+++ b/drivers/net/ethernet/realtek/8139cp.c
@@ -478,7 +478,7 @@ rx_status_loop:
 
while (1) {
u32 status, len;
-   dma_addr_t mapping;
+   dma_addr_t mapping, new_mapping;
struct sk_buff *skb, *new_skb;
struct cp_desc *desc;
const unsigned buflen = cp->rx_buf_sz;
@@ -520,6 +520,13 @@ rx_status_loop:
goto rx_next;
}
 
+   new_mapping = dma_map_single(>pdev->dev, new_skb->data, 
buflen,
+PCI_DMA_FROMDEVICE);
+   if (dma_mapping_error(>pdev->dev, new_mapping)) {
+   dev->stats.rx_dropped++;
+   goto rx_next;
+   }
+
dma_unmap_single(>pdev->dev, mapping,
 buflen, PCI_DMA_FROMDEVICE);
 
@@ -531,12 +538,11 @@ rx_status_loop:
 
skb_put(skb, len);
 
-   mapping = dma_map_single(>pdev->dev, new_skb->data, buflen,
-PCI_DMA_FROMDEVICE);
cp->rx_skb[rx_tail] = new_skb;
 
cp_rx_skb(cp, skb, desc);
rx++;
+   mapping = new_mapping;
 
 rx_next:
cp->rx_ring[rx_tail].opts2 = 0;
@@ -707,6 +713,22 @@ static inline u32 cp_tx_vlan_tag(struct sk_buff *skb)
TxVlanTag | swab16(vlan_tx_tag_get(skb)) : 0x00;
 }
 
+static void unwind_tx_frag_mapping(struct cp_private *cp, struct sk_buff *skb,
+  int first, int entry_last)
+{
+   int frag, index;
+   struct cp_desc *txd;
+   skb_frag_t *this_frag;
+   for (frag = 0; frag+first < entry_last; frag++) {
+   index = first+frag;
+   cp->tx_skb[index] = NULL;
+   txd = >tx_ring[index];
+   this_frag = _shinfo(skb)->frags[frag];
+   dma_unmap_single(>pdev->dev, le64_to_cpu(txd->addr),
+skb_frag_size(this_frag), PCI_DMA_TODEVICE);
+   }
+}
+
 static netdev_tx_t cp_start_xmit (struct sk_buff *skb,
struct net_device *dev)
 {
@@ -740,6 +762,9 @@ static netdev_tx_t cp_start_xmit (struct sk_buff *skb,
 
len = skb->len;
mapping = dma_map_single(>pdev->dev, skb->data, len, 
PCI_DMA_TODEVICE);
+   if (dma_mapping_error(>pdev->dev, mapping))
+   goto out_dma_error;
+
txd->opts2 = opts2;
txd->addr = cpu_to_le64(mapping);
wmb();
@@ -777,6 +802,9 @@ static netdev_tx_t cp_start_xmit (struct sk_buff *skb,
first_len = skb_headlen(skb);
first_mapping = dma_map_single(>pdev->dev, skb->data,
   first_len, PCI_DMA_TODEVICE);
+   if (dma_mapping_error(>pdev->dev, first_mapping))
+   goto out_dma_error;
+
cp->tx_skb[entry] = skb;
entry = NEXT_TX(entry);
 
@@ -790,6 +818,11 @@ static netdev_tx_t cp_start_xmit (struct sk_buff *skb,
mapping = dma_map_single(>pdev->dev,
 skb_frag_address(this_frag),
 len, PCI_DMA_TODEVICE);
+   if (dma_mapping_error(>pdev->dev, mapping)) {
+   unwind_tx_frag_mapping(cp, skb, first_entry, 
entry);
+   goto out_dma_error;
+   }
+
eor = (entry == (CP_TX_RING_SIZE - 1)) ? RingEnd : 0;
 
ctrl = eor | len | DescOwn;
@@ -848,11 +881,16 @@ static netdev_tx_t cp_start_xmit (struct sk_buff *skb,
if (TX_BUFFS_AVAIL(cp) <= (MAX_SKB_FRAGS + 1))
netif_stop_queue(dev);
 
+out_unlock:
spin_unlock_irqrestore(>lock, intr_flags);
 

[167/251] megaraid_sas: megaraid_sas driver init fails in kdump kernel

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: "sumit.sax...@lsi.com" 

[ Upstream commit 6431f5d7c6025f8b007af06ea090de308f7e6881 ]

Problem: When Hardware IOMMU is on, megaraid_sas driver initialization fails
in kdump kernel with LSI MegaRAID controller(device id-0x73).

Actually this issue needs fix in firmware, but for firmware running in field,
this driver fix is proposed to resolve the issue.  At firmware initialization
time, if firmware does not come to ready state, driver will reset the adapter
and retry for firmware transition to ready state unconditionally(not only
executed for kdump kernel).

Signed-off-by: Sumit Saxena 
Signed-off-by: Kashyap Desai 
Cc: sta...@vger.kernel.org
Signed-off-by: James Bottomley 
Signed-off-by: Steven Rostedt 
---
 drivers/scsi/megaraid/megaraid_sas_base.c |   20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index d525297..7593e28 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -3493,11 +3493,21 @@ static int megasas_init_fw(struct megasas_instance 
*instance)
break;
}
 
-   /*
-* We expect the FW state to be READY
-*/
-   if (megasas_transition_to_ready(instance, 0))
-   goto fail_ready_state;
+   if (megasas_transition_to_ready(instance, 0)) {
+   atomic_set(>fw_reset_no_pci_access, 1);
+   instance->instancet->adp_reset
+   (instance, instance->reg_set);
+   atomic_set(>fw_reset_no_pci_access, 0);
+   dev_info(>pdev->dev,
+   "megasas: FW restarted successfully from %s!\n",
+   __func__);
+
+   /*waitting for about 30 second before retry*/
+   ssleep(30);
+
+   if (megasas_transition_to_ready(instance, 0))
+   goto fail_ready_state;
+   }
 
/* Check if MSI-X is supported while in ready state */
msix_enable = (instance->instancet->read_fw_status_reg(reg_set) &
-- 
1.7.10.4


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

[163/251] net_sched: info leak in atm_tc_dump_class()

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Dan Carpenter 

[ Upstream commit 8cb3b9c3642c0263d48f31d525bcee7170eedc20 ]

The "pvc" struct has a hole after pvc.sap_family which is not cleared.

Signed-off-by: Dan Carpenter 
Reviewed-by: Jiri Pirko 
Signed-off-by: David S. Miller 
Signed-off-by: Steven Rostedt 
---
 net/sched/sch_atm.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/net/sched/sch_atm.c b/net/sched/sch_atm.c
index ca8e0a5..1f9c314 100644
--- a/net/sched/sch_atm.c
+++ b/net/sched/sch_atm.c
@@ -605,6 +605,7 @@ static int atm_tc_dump_class(struct Qdisc *sch, unsigned 
long cl,
struct sockaddr_atmpvc pvc;
int state;
 
+   memset(, 0, sizeof(pvc));
pvc.sap_family = AF_ATMPVC;
pvc.sap_addr.itf = flow->vcc->dev ? flow->vcc->dev->number : -1;
pvc.sap_addr.vpi = flow->vcc->vpi;
-- 
1.7.10.4


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

[159/251] ipv6: take rtnl_lock and mark mrt6 table as freed on namespace cleanup

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Hannes Frederic Sowa 

[ Upstream commit 905a6f96a1b18e490a75f810d733ced93c39b0e5 ]

Otherwise we end up dereferencing the already freed net->ipv6.mrt pointer
which leads to a panic (from Srivatsa S. Bhat):

BUG: unable to handle kernel paging request at 882018552020
IP: [] ip6mr_sk_done+0x32/0xb0 [ipv6]
PGD 290a067 PUD 207ffe0067 PMD 207ff1d067 PTE 802018552060
Oops:  [#1] SMP DEBUG_PAGEALLOC
Modules linked in: ebtable_nat ebtables nfs fscache nf_conntrack_ipv4 
nf_defrag_ipv4 ipt_REJECT xt_CHECKSUM iptable_mangle iptable_filter ip_tables 
nfsd lockd nfs_acl exportfs auth_rpcgss autofs4 sunrpc 8021q garp bridge stp 
llc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack 
ip6table_filter
+ip6_tables ipv6 vfat fat vhost_net macvtap macvlan vhost tun kvm_intel kvm 
uinput iTCO_wdt iTCO_vendor_support cdc_ether usbnet mii microcode i2c_i801 
i2c_core lpc_ich mfd_core shpchp ioatdma dca mlx4_core be2net wmi acpi_cpufreq 
mperf ext4 jbd2 mbcache dm_mirror dm_region_hash dm_log dm_mod
CPU: 0 PID: 7 Comm: kworker/u33:0 Not tainted 3.11.0-rc1-ea45e-a #4
Hardware name: IBM  -[8737R2A]-/00Y2738, BIOS -[B2E120RUS-1.20]- 11/30/2012
Workqueue: netns cleanup_net
task: 8810393641c0 ti: 881039366000 task.ti: 881039366000
RIP: 0010:[]  [] ip6mr_sk_done+0x32/0xb0 
[ipv6]
RSP: 0018:881039367bd8  EFLAGS: 00010286
RAX: 881039367fd8 RBX: 882018552000 RCX: dead00200200
RDX:  RSI: 881039367b68 RDI: 881039367b68
RBP: 881039367bf8 R08: 881039367b68 R09: 
R10:  R11:  R12: 882015a7a040
R13: 882014eb89c0 R14: 8820289e2800 R15: 
FS:  () GS:88103fc0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 882018552020 CR3: 01c0b000 CR4: 000407f0
Stack:
 881039367c18 882014eb89c0 882015e28c00 
 881039367c18 a034d9d1 8820289e2800 882014eb89c0
 881039367c58 815bdecb 815bddf2 882014eb89c0
Call Trace:
 [] rawv6_close+0x21/0x40 [ipv6]
 [] inet_release+0xfb/0x220
 [] ? inet_release+0x22/0x220
 [] inet6_release+0x3f/0x50 [ipv6]
 [] sock_release+0x29/0xa0
 [] sk_release_kernel+0x30/0x70
 [] icmpv6_sk_exit+0x3b/0x80 [ipv6]
 [] ops_exit_list+0x39/0x60
 [] cleanup_net+0xfb/0x1a0
 [] process_one_work+0x1da/0x610
 [] ? process_one_work+0x169/0x610
 [] worker_thread+0x120/0x3a0
 [] ? process_one_work+0x610/0x610
 [] kthread+0xee/0x100
 [] ? __init_kthread_worker+0x70/0x70
 [] ret_from_fork+0x7c/0xb0
 [] ? __init_kthread_worker+0x70/0x70
Code: 20 48 89 5d e8 4c 89 65 f0 4c 89 6d f8 66 66 66 66 90 4c 8b 67 30 49 89 
fd e8 db 3c 1e e1 49 8b 9c 24 90 08 00 00 48 85 db 74 06 <4c> 39 6b 20 74 20 bb 
f3 ff ff ff e8 8e 3c 1e e1 89 d8 4c 8b 65
RIP  [] ip6mr_sk_done+0x32/0xb0 [ipv6]
 RSP 
CR2: 882018552020

Reported-by: Srivatsa S. Bhat 
Tested-by: Srivatsa S. Bhat 
Signed-off-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller 
Signed-off-by: Steven Rostedt 
---
 net/ipv6/ip6mr.c |5 +
 1 file changed, 5 insertions(+)

diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index 4532973..964e3ae 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -256,10 +256,12 @@ static void __net_exit ip6mr_rules_exit(struct net *net)
 {
struct mr6_table *mrt, *next;
 
+   rtnl_lock();
list_for_each_entry_safe(mrt, next, >ipv6.mr6_tables, list) {
list_del(>list);
ip6mr_free_table(mrt);
}
+   rtnl_unlock();
fib_rules_unregister(net->ipv6.mr6_rules_ops);
 }
 #else
@@ -286,7 +288,10 @@ static int __net_init ip6mr_rules_init(struct net *net)
 
 static void __net_exit ip6mr_rules_exit(struct net *net)
 {
+   rtnl_lock();
ip6mr_free_table(net->ipv6.mrt6);
+   net->ipv6.mrt6 = NULL;
+   rtnl_unlock();
 }
 #endif
 
-- 
1.7.10.4


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

[245/251] workqueue: cond_resched() after processing each work item

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Tejun Heo 

[ Upstream commit b22ce2785d97423846206cceec4efee0c4afd980 ]

If !PREEMPT, a kworker running work items back to back can hog CPU.
This becomes dangerous when a self-requeueing work item which is
waiting for something to happen races against stop_machine.  Such
self-requeueing work item would requeue itself indefinitely hogging
the kworker and CPU it's running on while stop_machine would wait for
that CPU to enter stop_machine while preventing anything else from
happening on all other CPUs.  The two would deadlock.

Jamie Liu reports that this deadlock scenario exists around
scsi_requeue_run_queue() and libata port multiplier support, where one
port may exclude command processing from other ports.  With the right
timing, scsi_requeue_run_queue() can end up requeueing itself trying
to execute an IO which is asked to be retried while another device has
an exclusive access, which in turn can't make forward progress due to
stop_machine.

Fix it by invoking cond_resched() after executing each work item.

Signed-off-by: Tejun Heo 
Reported-by: Jamie Liu 
Signed-off-by: Steven Rostedt 
References: http://thread.gmane.org/gmane.linux.kernel/1552567
Cc: sta...@vger.kernel.org
--
 kernel/workqueue.c |9 +
 1 file changed, 9 insertions(+)
---
 kernel/workqueue.c |9 +
 1 file changed, 9 insertions(+)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 0352a81..ce44f31 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -2105,6 +2105,15 @@ __acquires(>lock)
dump_stack();
}
 
+   /*
+* The following prevents a kworker from hogging CPU on !PREEMPT
+* kernels, where a requeueing work item waiting for something to
+* happen could deadlock with stop_machine as such work item could
+* indefinitely requeue itself while all other CPUs are trapped in
+* stop_machine.
+*/
+   cond_resched();
+
spin_lock_irq(>lock);
 
/* clear cpu intensive status */
-- 
1.7.10.4


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

[156/251] x86/iommu/vt-d: Expand interrupt remapping quirk to cover x58 chipset

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Neil Horman 

[ Upstream commit 803075dba31c17af110e1d9a915fe7262165b213 ]

Recently we added an early quirk to detect 5500/5520 chipsets
with early revisions that had problems with irq draining with
interrupt remapping enabled:

  commit 03bbcb2e7e292838bb0244f5a7816d194c911d62
  Author: Neil Horman 
  Date:   Tue Apr 16 16:38:32 2013 -0400

  iommu/vt-d: add quirk for broken interrupt remapping on 55XX chipsets

It turns out this same problem is present in the intel X58
chipset as well. See errata 69 here:

  
http://www.intel.com/content/www/us/en/chipsets/x58-express-specification-update.html

This patch extends the pci early quirk so that the chip
devices/revisions specified in the above update are also covered
in the same way:

Signed-off-by: Neil Horman 
Reviewed-by: Jan Beulich 
Acked-by: Donald Dutile 
Cc: Joerg Roedel 
Cc: Andrew Cooper 
Cc: Malcolm Crossley 
Cc: Prarit Bhargava 
Cc: Don Zickus 
Cc: sta...@vger.kernel.org
Link: 
http://lkml.kernel.org/r/1374059639-8631-1-git-send-email-nhor...@tuxdriver.com
Signed-off-by: Steven Rostedt 
[ Small edits. ]
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/early-quirks.c |   14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index 94ab6b9..63bdb29 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -196,15 +196,23 @@ static void __init ati_bugs_contd(int num, int slot, int 
func)
 static void __init intel_remapping_check(int num, int slot, int func)
 {
u8 revision;
+   u16 device;
 
+   device = read_pci_config_16(num, slot, func, PCI_DEVICE_ID);
revision = read_pci_config_byte(num, slot, func, PCI_REVISION_ID);
 
/*
-* Revision 0x13 of this chipset supports irq remapping
-* but has an erratum that breaks its behavior, flag it as such
+* Revision 13 of all triggering devices id in this quirk have
+* a problem draining interrupts when irq remapping is enabled,
+* and should be flagged as broken.  Additionally revisions 0x12
+* and 0x22 of device id 0x3405 has this problem.
 */
if (revision == 0x13)
set_irq_remapping_broken();
+   else if ((device == 0x3405) &&
+   ((revision == 0x12) ||
+(revision == 0x22)))
+   set_irq_remapping_broken();
 
 }
 
@@ -239,6 +247,8 @@ static struct chipset early_qrk[] __initdata = {
  PCI_CLASS_SERIAL_SMBUS, PCI_ANY_ID, 0, ati_bugs_contd },
{ PCI_VENDOR_ID_INTEL, 0x3403, PCI_CLASS_BRIDGE_HOST,
  PCI_BASE_CLASS_BRIDGE, 0, intel_remapping_check },
+   { PCI_VENDOR_ID_INTEL, 0x3405, PCI_CLASS_BRIDGE_HOST,
+ PCI_BASE_CLASS_BRIDGE, 0, intel_remapping_check },
{ PCI_VENDOR_ID_INTEL, 0x3406, PCI_CLASS_BRIDGE_HOST,
  PCI_BASE_CLASS_BRIDGE, 0, intel_remapping_check },
{}
-- 
1.7.10.4


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

[158/251] sysctl net: Keep tcp_syn_retries inside the boundary

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Michal Tesar 

[ Upstream commit 651e92716aaae60fc41b9652f54cb6803896e0da ]

Limit the min/max value passed to the
/proc/sys/net/ipv4/tcp_syn_retries.

Signed-off-by: Michal Tesar 
Signed-off-by: David S. Miller 
Signed-off-by: Steven Rostedt 
---
 net/ipv4/sysctl_net_ipv4.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index 1b5ce96..335f18d 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -35,6 +35,8 @@ static int tcp_adv_win_scale_min = -31;
 static int tcp_adv_win_scale_max = 31;
 static int ip_ttl_min = 1;
 static int ip_ttl_max = 255;
+static int tcp_syn_retries_min = 1;
+static int tcp_syn_retries_max = MAX_TCP_SYNCNT;
 static int ip_ping_group_range_min[] = { 0, 0 };
 static int ip_ping_group_range_max[] = { GID_T_MAX, GID_T_MAX };
 
@@ -277,7 +279,9 @@ static struct ctl_table ipv4_table[] = {
.data   = _tcp_syn_retries,
.maxlen = sizeof(int),
.mode   = 0644,
-   .proc_handler   = proc_dointvec
+   .proc_handler   = proc_dointvec_minmax,
+   .extra1 = _syn_retries_min,
+   .extra2 = _syn_retries_max
},
{
.procname   = "tcp_synack_retries",
-- 
1.7.10.4


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

[157/251] arcnet: cleanup sizeof parameter

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Dan Carpenter 

[ Upstream commit 087d273caf4f7d3f2159256f255f1f432bc84a5b ]

This patch doesn't change the compiled code because ARC_HDR_SIZE is 4
and sizeof(int) is 4, but the intent was to use the header size and not
the sizeof the header size.

Signed-off-by: Dan Carpenter 
Signed-off-by: David S. Miller 
Signed-off-by: Steven Rostedt 
---
 drivers/net/arcnet/arcnet.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/arcnet/arcnet.c b/drivers/net/arcnet/arcnet.c
index a746ba2..a956053 100644
--- a/drivers/net/arcnet/arcnet.c
+++ b/drivers/net/arcnet/arcnet.c
@@ -1007,7 +1007,7 @@ static void arcnet_rx(struct net_device *dev, int bufnum)
 
soft = 
 
-   lp->hw.copy_from_card(dev, bufnum, 0, , sizeof(ARC_HDR_SIZE));
+   lp->hw.copy_from_card(dev, bufnum, 0, , ARC_HDR_SIZE);
if (pkt.hard.offset[0]) {
ofs = pkt.hard.offset[0];
length = 256 - ofs;
-- 
1.7.10.4


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

[151/251] ACPI / battery: Fix parsing _BIX return value

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Lan Tianyu 

[ Upstream commit 016d5baad04269e8559332df05f89bd95b52d6ad ]

The _BIX method returns extended battery info as a package.
According the ACPI spec (ACPI 5, Section 10.2.2.2), the first member
of that package should be "Revision".  However, the current ACPI
battery driver treats the first member as "Power Unit" which should
be the second member.  This causes the result of _BIX return data
parsing to be incorrect.

Fix this by adding a new member called 'revision' to struct
acpi_battery and adding the offsetof() information on it to
extended_info_offsets[] as the first row.

[rjw: Changelog]
Reported-and-tested-by: Jan Hoffmann 
References: http://bugzilla.kernel.org/show_bug.cgi?id=60519
Signed-off-by: Lan Tianyu 
Cc: 2.6.34+ 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Steven Rostedt 
---
 drivers/acpi/battery.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index 7efaeaa..7663df7 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -117,6 +117,7 @@ struct acpi_battery {
struct acpi_device *device;
struct notifier_block pm_nb;
unsigned long update_time;
+   int revision;
int rate_now;
int capacity_now;
int voltage_now;
@@ -359,6 +360,7 @@ static struct acpi_offsets info_offsets[] = {
 };
 
 static struct acpi_offsets extended_info_offsets[] = {
+   {offsetof(struct acpi_battery, revision), 0},
{offsetof(struct acpi_battery, power_unit), 0},
{offsetof(struct acpi_battery, design_capacity), 0},
{offsetof(struct acpi_battery, full_charge_capacity), 0},
-- 
1.7.10.4


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

[154/251] x86, fpu: correct the asm constraints for fxsave, unbreak mxcsr.daz

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: "H.J. Lu" 

[ Upstream commit eaa5a990191d204ba0f9d35dbe5505ec2cdd1460 ]

GCC will optimize mxcsr_feature_mask_init in arch/x86/kernel/i387.c:

memset(_scratch, 0, sizeof(struct i387_fxsave_struct));
asm volatile("fxsave %0" : : "m" (fx_scratch));
mask = fx_scratch.mxcsr_mask;
if (mask == 0)
mask = 0xffbf;

to

memset(_scratch, 0, sizeof(struct i387_fxsave_struct));
asm volatile("fxsave %0" : : "m" (fx_scratch));
mask = 0xffbf;

since asm statement doesn’t say it will update fx_scratch.  As the
result, the DAZ bit will be cleared.  This patch fixes it. This bug
dates back to at least kernel 2.6.12.

Signed-off-by: H. Peter Anvin 
Cc: 
Signed-off-by: Steven Rostedt 
---
 arch/x86/kernel/i387.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/i387.c b/arch/x86/kernel/i387.c
index f250431..6c5a7dc 100644
--- a/arch/x86/kernel/i387.c
+++ b/arch/x86/kernel/i387.c
@@ -132,7 +132,7 @@ static void __cpuinit mxcsr_feature_mask_init(void)
clts();
if (cpu_has_fxsr) {
memset(_scratch, 0, sizeof(struct i387_fxsave_struct));
-   asm volatile("fxsave %0" : : "m" (fx_scratch));
+   asm volatile("fxsave %0" : "+m" (fx_scratch));
mask = fx_scratch.mxcsr_mask;
if (mask == 0)
mask = 0xffbf;
-- 
1.7.10.4


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

[153/251] cgroup: fix umount vs cgroup_cfts_commit() race

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Li Zefan 

[ Upstream commit 084457f284abf6789d90509ee11dae383842b23b ]

cgroup_cfts_commit() uses dget() to keep cgroup alive after cgroup_mutex
is dropped, but dget() won't prevent cgroupfs from being umounted. When
the race happens, vfs will see some dentries with non-zero refcnt while
umount is in process.

Keep running this:
  mount -t cgroup -o blkio xxx /cgroup
  umount /cgroup

And this:
  modprobe cfq-iosched
  rmmod cfs-iosched

After a while, the BUG() in shrink_dcache_for_umount_subtree() may
be triggered:

  BUG: Dentry xxx{i=0,n=blkio.yyy} still in use (1) [umount of cgroup cgroup]

Signed-off-by: Li Zefan 
Signed-off-by: Tejun Heo 
Cc: sta...@vger.kernel.org
Signed-off-by: Steven Rostedt 
---
 kernel/cgroup.c |9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 9cf9102..79e528f 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -2761,13 +2761,17 @@ static void cgroup_cfts_commit(struct cgroup_subsys *ss,
 {
LIST_HEAD(pending);
struct cgroup *cgrp, *n;
+   struct super_block *sb = ss->root->sb;
 
/* %NULL @cfts indicates abort and don't bother if @ss isn't attached */
-   if (cfts && ss->root != ) {
+   if (cfts && ss->root !=  &&
+   atomic_inc_not_zero(>s_active)) {
list_for_each_entry(cgrp, >root->allcg_list, allcg_node) {
dget(cgrp->dentry);
list_add_tail(>cft_q_node, );
}
+   } else {
+   sb = NULL;
}
 
mutex_unlock(_mutex);
@@ -2790,6 +2794,9 @@ static void cgroup_cfts_commit(struct cgroup_subsys *ss,
dput(cgrp->dentry);
}
 
+   if (sb)
+   deactivate_super(sb);
+
mutex_unlock(_cft_mutex);
 }
 
-- 
1.7.10.4


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

[155/251] userns: limit the maximum depth of user_namespace->parent chain

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Oleg Nesterov 

[ Upstream commit 8742f229b635bf1c1c84a3dfe5e47c814c20b5c8 ]

Ensure that user_namespace->parent chain can't grow too much.
Currently we use the hardroded 32 as limit.

Reported-by: Andy Lutomirski 
Signed-off-by: Oleg Nesterov 
Signed-off-by: Linus Torvalds 
Signed-off-by: Steven Rostedt 
---
 include/linux/user_namespace.h |1 +
 kernel/user_namespace.c|4 
 2 files changed, 5 insertions(+)

diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h
index 4e72922..4eea4ce 100644
--- a/include/linux/user_namespace.h
+++ b/include/linux/user_namespace.h
@@ -22,6 +22,7 @@ struct user_namespace {
struct uid_gid_map  gid_map;
struct kref kref;
struct user_namespace   *parent;
+   int level;
kuid_t  owner;
kgid_t  group;
 };
diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
index a74dc5b..5242e83 100644
--- a/kernel/user_namespace.c
+++ b/kernel/user_namespace.c
@@ -39,6 +39,9 @@ int create_user_ns(struct cred *new)
kuid_t owner = new->euid;
kgid_t group = new->egid;
 
+   if (parent_ns->level > 32)
+   return -EUSERS;
+
/*
 * Verify that we can not violate the policy of which files
 * may be accessed that is specified by the root directory,
@@ -62,6 +65,7 @@ int create_user_ns(struct cred *new)
 
kref_init(>kref);
ns->parent = parent_ns;
+   ns->level = parent_ns->level + 1;
ns->owner = owner;
ns->group = group;
 
-- 
1.7.10.4


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

Re: [PATCH] vmpressure: fix divide-by-0 in vmpressure_work_fn

[Anton Vorontsov]

On Fri, Sep 06, 2013 at 10:59:16PM -0700, Hugh Dickins wrote:
> Hit divide-by-0 in vmpressure_work_fn(): checking vmpr->scanned before
> taking the lock is not enough, we must check scanned afterwards too.
> 
> Signed-off-by: Hugh Dickins 
> Cc: sta...@vger.kernel.org

Hm... Just trying to understand this one. I don't see how this can happen,
considering that only one instance of vmpressure_work_fn() supposed to be
running (unlike vmpressure()), and the only place where we zero
vmpr->scanned is vmpressure_work_fn() itself?

> ---
> 
>  mm/vmpressure.c |3 +++
>  1 file changed, 3 insertions(+)
> 
> --- 3.11/mm/vmpressure.c  2013-09-02 13:46:10.0 -0700
> +++ linux/mm/vmpressure.c 2013-09-06 22:43:03.596003080 -0700
> @@ -187,6 +187,9 @@ static void vmpressure_work_fn(struct wo
>   vmpr->reclaimed = 0;
>   spin_unlock(>sr_lock);
>  
> + if (!scanned)
> + return;
> +
>   do {
>   if (vmpressure_event(vmpr, scanned, reclaimed))
>   break;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[152/251] fanotify: info leak in copy_event_to_user()

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Dan Carpenter 

[ Upstream commit de1e0c40aceb9d5bff09c3a3b97b2f1b178af53f ]

The ->reserved field isn't cleared so we leak one byte of stack
information to userspace.

Signed-off-by: Dan Carpenter 
Cc: Eric Paris 
Cc: Al Viro 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Steven Rostedt 
---
 fs/notify/fanotify/fanotify_user.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/notify/fanotify/fanotify_user.c 
b/fs/notify/fanotify/fanotify_user.c
index d438036..b670659 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -116,6 +116,7 @@ static int fill_event_metadata(struct fsnotify_group *group,
metadata->event_len = FAN_EVENT_METADATA_LEN;
metadata->metadata_len = FAN_EVENT_METADATA_LEN;
metadata->vers = FANOTIFY_METADATA_VERSION;
+   metadata->reserved = 0;
metadata->mask = event->mask & FAN_ALL_OUTGOING_EVENTS;
metadata->pid = pid_vnr(event->tgid);
if (unlikely(event->mask & FAN_Q_OVERFLOW))
-- 
1.7.10.4


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

[147/251] zram: destroy all devices on error recovery path in zram_init()

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Jiang Liu 

[ Upstream commit 39a9b8ac9333e4268ecff7da6c9d1ab3823ff243 ]

On error recovery path of zram_init(), it leaks the zram device object
causing the failure. So change create_device() to free allocated
resources on error path.

Signed-off-by: Jiang Liu 
Acked-by: Minchan Kim 
Acked-by: Jerome Marchand 
Cc: sta...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Steven Rostedt 
---
 drivers/staging/zram/zram_drv.c |   15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
index 4322baf..5047bfe 100644
--- a/drivers/staging/zram/zram_drv.c
+++ b/drivers/staging/zram/zram_drv.c
@@ -635,7 +635,7 @@ static const struct block_device_operations zram_devops = {
 
 static int create_device(struct zram *zram, int device_id)
 {
-   int ret = 0;
+   int ret = -ENOMEM;
 
init_rwsem(>lock);
init_rwsem(>init_lock);
@@ -645,7 +645,6 @@ static int create_device(struct zram *zram, int device_id)
if (!zram->queue) {
pr_err("Error allocating disk queue for device %d\n",
device_id);
-   ret = -ENOMEM;
goto out;
}
 
@@ -655,11 +654,9 @@ static int create_device(struct zram *zram, int device_id)
 /* gendisk structure */
zram->disk = alloc_disk(1);
if (!zram->disk) {
-   blk_cleanup_queue(zram->queue);
pr_warn("Error allocating disk structure for device %d\n",
device_id);
-   ret = -ENOMEM;
-   goto out;
+   goto out_free_queue;
}
 
zram->disk->major = zram_major;
@@ -688,11 +685,17 @@ static int create_device(struct zram *zram, int device_id)
_disk_attr_group);
if (ret < 0) {
pr_warn("Error creating sysfs group");
-   goto out;
+   goto out_free_disk;
}
 
zram->init_done = 0;
+   return 0;
 
+out_free_disk:
+   del_gendisk(zram->disk);
+   put_disk(zram->disk);
+out_free_queue:
+   blk_cleanup_queue(zram->queue);
 out:
return ret;
 }
-- 
1.7.10.4


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

[150/251] zram: protect sysfs handler from invalid memory access

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Jiang Liu 

[ Upstream commit 5863e10b441e7ea4b492f930f1be180a97d026f3 ]

Use zram->init_lock to protect access to zram->meta, otherwise it
may cause invalid memory access if zram->meta has been freed by
zram_reset_device().

This issue may be triggered by:
Thread 1:
while true; do cat mem_used_total; done
Thread 2:
while true; do echo 8M > disksize; echo 1 > reset; done

Signed-off-by: Jiang Liu 
Acked-by: Minchan Kim 
Cc: sta...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Steven Rostedt 
---
 drivers/staging/zram/zram_sysfs.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/staging/zram/zram_sysfs.c 
b/drivers/staging/zram/zram_sysfs.c
index edb0ed4..5e07628 100644
--- a/drivers/staging/zram/zram_sysfs.c
+++ b/drivers/staging/zram/zram_sysfs.c
@@ -186,8 +186,10 @@ static ssize_t mem_used_total_show(struct device *dev,
u64 val = 0;
struct zram *zram = dev_to_zram(dev);
 
+   down_read(>init_lock);
if (zram->init_done)
val = zs_get_total_size_bytes(zram->mem_pool);
+   up_read(>init_lock);
 
return sprintf(buf, "%llu\n", val);
 }
-- 
1.7.10.4


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

[146/251] zram: use zram->lock to protect zram_free_page() in swap free notify path

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Jiang Liu 

[ Upstream commit 57ab048532c0d975538cebd4456491b5c34248f4 ]

zram_slot_free_notify() is free-running without any protection from
concurrent operations. So there are race conditions between
zram_bvec_read()/zram_bvec_write() and zram_slot_free_notify(),
and possible consequences include:
1) Trigger BUG_ON(!handle) on zram_bvec_write() side.
2) Access to freed pages on zram_bvec_read() side.
3) Break some fields (bad_compress, good_compress, pages_stored)
   in zram->stats if the swap layer makes concurrently call to
   zram_slot_free_notify().

So enhance zram_slot_free_notify() to acquire writer lock on zram->lock
before calling zram_free_page().

Signed-off-by: Jiang Liu 
Cc: sta...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Steven Rostedt 
---
 drivers/staging/zram/zram_drv.c |2 ++
 drivers/staging/zram/zram_drv.h |5 +++--
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
index 38a1b44..4322baf 100644
--- a/drivers/staging/zram/zram_drv.c
+++ b/drivers/staging/zram/zram_drv.c
@@ -622,7 +622,9 @@ static void zram_slot_free_notify(struct block_device *bdev,
struct zram *zram;
 
zram = bdev->bd_disk->private_data;
+   down_write(>lock);
zram_free_page(zram, index);
+   up_write(>lock);
zram_stat64_inc(zram, >stats.notify_free);
 }
 
diff --git a/drivers/staging/zram/zram_drv.h b/drivers/staging/zram/zram_drv.h
index 572c0b1..a6eb5d9 100644
--- a/drivers/staging/zram/zram_drv.h
+++ b/drivers/staging/zram/zram_drv.h
@@ -92,8 +92,9 @@ struct zram {
void *compress_buffer;
struct table *table;
spinlock_t stat64_lock; /* protect 64-bit stats */
-   struct rw_semaphore lock; /* protect compression buffers and table
-  * against concurrent read and writes */
+   struct rw_semaphore lock; /* protect compression buffers, table,
+  * 32bit stat counters against concurrent
+  * notifications, reads and writes */
struct request_queue *queue;
struct gendisk *disk;
int init_done;
-- 
1.7.10.4


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

Re: [PATCH 3/6] tree-sweep: Include linux/sched.h for might_sleep users

[Ingo Molnar]

* Andi Kleen  wrote:

> On Tue, Sep 10, 2013 at 04:52:12PM -0700, Andrew Morton wrote:
> > On Sat, 31 Aug 2013 20:22:23 +0200 Geert Uytterhoeven 
> >  wrote:
> > 
> > > On Fri, Aug 16, 2013 at 11:17 PM, Andi Kleen  wrote:
> > > > might_sleep is moving from linux/kernel.h to linux/sched.h, so any users
> > > > need to include linux/sched.h
> > > 
> > > Really?  is the worst choice w.r.t. include hell.
> > 
> > Yes.  Mechanically adding sched.h inclusions into .h files will cause
> > problems.
> > 
> > I've had decent success with this sort of thing by adding new,
> > finer-grained headers.  Maybe include/linux/might_sleep.h would be a
> > good starting point to fix whatever it was that this fixed.
> 
> Ok. I'll look into that and send new patches.
> 
> Some of it may be obsolete with Peter's recent preempt work.

The best order from a maintenance and merge POV would be to rebase your 
bits on top of Peter's preempt_count optimization work, which is the more 
comprehensive approach. That allows you to drop the obsolete bits, and 
wait for Peter to pick up your bits.

The two interact so we want to handle them together in any case, in the 
scheduler tree.

Thanks,

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

[144/251] mwifiex: Add missing endian conversion.

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: =?UTF-8?q?Tomasz=20Mo=C5=84?= 

[ Upstream commit 83e612f632c3897be29ef02e0472f6d63e258378 ]

Both type and pkt_len variables are in host endian and these should be in
Little Endian in the payload.

Signed-off-by: Tomasz Moń 
Acked-by: Bing Zhao 
Cc: 
Signed-off-by: John W. Linville 
Signed-off-by: Steven Rostedt 
---
 drivers/net/wireless/mwifiex/sdio.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/mwifiex/sdio.c 
b/drivers/net/wireless/mwifiex/sdio.c
index 82cf0fa..821d9d2 100644
--- a/drivers/net/wireless/mwifiex/sdio.c
+++ b/drivers/net/wireless/mwifiex/sdio.c
@@ -1455,8 +1455,8 @@ static int mwifiex_sdio_host_to_card(struct 
mwifiex_adapter *adapter,
/* Allocate buffer and copy payload */
blk_size = MWIFIEX_SDIO_BLOCK_SIZE;
buf_block_len = (pkt_len + blk_size - 1) / blk_size;
-   *(u16 *) [0] = (u16) pkt_len;
-   *(u16 *) [2] = type;
+   *(__le16 *)[0] = cpu_to_le16((u16)pkt_len);
+   *(__le16 *)[2] = cpu_to_le16(type);
 
/*
 * This is SDIO specific header
-- 
1.7.10.4


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

[143/251] rt2x00: fix stop queue

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Stanislaw Gruszka 

[ Upstream commit e2288b66fe7ff0288382b2af671b4da558b44472 ]

Since we clear QUEUE_STARTED in rt2x00queue_stop_queue(), following
call to rt2x00queue_pause_queue() reduce to noop, i.e we do not
stop queue in mac80211.

To fix that introduce rt2x00queue_pause_queue_nocheck() function,
which will stop queue in mac80211 directly.

Note that rt2x00_start_queue() explicitly set QUEUE_PAUSED bit.

Note also that reordering operations i.e. first call to
rt2x00queue_pause_queue() and then clear QUEUE_STARTED bit, will race
with rt2x00queue_unpause_queue(), so calling ieee80211_stop_queue()
directly is the only available solution to fix the problem without
major rework.

Cc: sta...@vger.kernel.org
Signed-off-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville 
Signed-off-by: Steven Rostedt 
---
 drivers/net/wireless/rt2x00/rt2x00queue.c |   18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/rt2x00/rt2x00queue.c 
b/drivers/net/wireless/rt2x00/rt2x00queue.c
index f7e74a0..cff62c0 100644
--- a/drivers/net/wireless/rt2x00/rt2x00queue.c
+++ b/drivers/net/wireless/rt2x00/rt2x00queue.c
@@ -875,13 +875,8 @@ void rt2x00queue_index_inc(struct queue_entry *entry, enum 
queue_index index)
spin_unlock_irqrestore(>index_lock, irqflags);
 }
 
-void rt2x00queue_pause_queue(struct data_queue *queue)
+void rt2x00queue_pause_queue_nocheck(struct data_queue *queue)
 {
-   if (!test_bit(DEVICE_STATE_PRESENT, >rt2x00dev->flags) ||
-   !test_bit(QUEUE_STARTED, >flags) ||
-   test_and_set_bit(QUEUE_PAUSED, >flags))
-   return;
-
switch (queue->qid) {
case QID_AC_VO:
case QID_AC_VI:
@@ -897,6 +892,15 @@ void rt2x00queue_pause_queue(struct data_queue *queue)
break;
}
 }
+void rt2x00queue_pause_queue(struct data_queue *queue)
+{
+   if (!test_bit(DEVICE_STATE_PRESENT, >rt2x00dev->flags) ||
+   !test_bit(QUEUE_STARTED, >flags) ||
+   test_and_set_bit(QUEUE_PAUSED, >flags))
+   return;
+
+   rt2x00queue_pause_queue_nocheck(queue);
+}
 EXPORT_SYMBOL_GPL(rt2x00queue_pause_queue);
 
 void rt2x00queue_unpause_queue(struct data_queue *queue)
@@ -958,7 +962,7 @@ void rt2x00queue_stop_queue(struct data_queue *queue)
return;
}
 
-   rt2x00queue_pause_queue(queue);
+   rt2x00queue_pause_queue_nocheck(queue);
 
queue->rt2x00dev->ops->lib->stop_queue(queue);
 
-- 
1.7.10.4


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

[149/251] zram: avoid access beyond the zram device

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Jiang Liu 

[ Upstream commit 12a7ad3b810e77137d0caf97a6dd97591e075b30 ]

Function valid_io_request() should verify the entire request are within
the zram device address range. Otherwise it may cause invalid memory
access when accessing/modifying zram->meta->table[index] because the
'index' is out of range. Then it may access non-exist memory, randomly
modify memory belong to other subsystems, which is hard to track down.

Signed-off-by: Jiang Liu 
Cc: sta...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Steven Rostedt 
---
 drivers/staging/zram/zram_drv.c |   17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
index 35b6a44..3a79d70 100644
--- a/drivers/staging/zram/zram_drv.c
+++ b/drivers/staging/zram/zram_drv.c
@@ -466,13 +466,20 @@ out:
  */
 static inline int valid_io_request(struct zram *zram, struct bio *bio)
 {
-   if (unlikely(
-   (bio->bi_sector >= (zram->disksize >> SECTOR_SHIFT)) ||
-   (bio->bi_sector & (ZRAM_SECTOR_PER_LOGICAL_BLOCK - 1)) ||
-   (bio->bi_size & (ZRAM_LOGICAL_BLOCK_SIZE - 1 {
+   u64 start, end, bound;
 
+   /* unaligned request */
+   if (unlikely(bio->bi_sector & (ZRAM_SECTOR_PER_LOGICAL_BLOCK - 1)))
+   return 0;
+   if (unlikely(bio->bi_size & (ZRAM_LOGICAL_BLOCK_SIZE - 1)))
+   return 0;
+
+   start = bio->bi_sector;
+   end = start + (bio->bi_size >> SECTOR_SHIFT);
+   bound = zram->disksize >> SECTOR_SHIFT;
+   /* out of range range */
+   if (unlikely(start >= bound || end >= bound || start > end))
return 0;
-   }
 
/* I/O request is valid */
return 1;
-- 
1.7.10.4


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

[138/251] mac80211: fix duplicate retransmission detection

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Johannes Berg 

[ Upstream commit 6b0f32745dcfba01d7be33acd1b40306c7a914c6 ]

The duplicate retransmission detection code in mac80211
erroneously attempts to do the check for every frame,
even frames that don't have a sequence control field or
that don't use it (QoS-Null frames.)

This is problematic because it causes the code to access
data beyond the end of the SKB and depending on the data
there will drop packets erroneously.

Correct the code to not do duplicate detection for such
frames.

I found this error while testing AP powersave, it lead
to retransmitted PS-Poll frames being dropped entirely
as the data beyond the end of the SKB was always zero.

Cc: sta...@vger.kernel.org [all versions]
Signed-off-by: Johannes Berg 
Signed-off-by: Steven Rostedt 
---
 net/mac80211/rx.c |   10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index bd11c1c..56515ef 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -805,8 +805,14 @@ ieee80211_rx_h_check(struct ieee80211_rx_data *rx)
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)rx->skb->data;
struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(rx->skb);
 
-   /* Drop duplicate 802.11 retransmissions (IEEE 802.11 Chap. 9.2.9) */
-   if (rx->sta && !is_multicast_ether_addr(hdr->addr1)) {
+   /*
+* Drop duplicate 802.11 retransmissions
+* (IEEE 802.11-2012: 9.3.2.10 "Duplicate detection and recovery")
+*/
+   if (rx->skb->len >= 24 && rx->sta &&
+   !ieee80211_is_ctl(hdr->frame_control) &&
+   !ieee80211_is_qos_nullfunc(hdr->frame_control) &&
+   !is_multicast_ether_addr(hdr->addr1)) {
if (unlikely(ieee80211_has_retry(hdr->frame_control) &&
 rx->sta->last_seq_ctrl[rx->seqno_idx] ==
 hdr->seq_ctrl)) {
-- 
1.7.10.4


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

[139/251] mac80211: fix ethtool stats for non-station interfaces

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Johannes Berg 

[ Upstream commit e13bae4f807401729b3f27c7e882a96b8b292809 ]

As reported in https://bugzilla.kernel.org/show_bug.cgi?id=60514,
the station loop never initialises 'sinfo' and therefore adds up
a stack values, leaking stack information (the number of times it
adds values is easily obtained another way.)

Fix this by initialising the sinfo for each station to add.

Cc: sta...@vger.kernel.org
Signed-off-by: Johannes Berg 
Signed-off-by: Steven Rostedt 
---
 net/mac80211/cfg.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index bb8d96b..cf9523e 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -554,6 +554,8 @@ static void ieee80211_get_et_stats(struct wiphy *wiphy,
if (sta->sdata->dev != dev)
continue;
 
+   sinfo.filled = 0;
+   sta_set_sinfo(sta, );
i = 0;
ADD_STA_STATS(sta);
}
-- 
1.7.10.4


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

[148/251] zram: avoid double free in function zram_bvec_write()

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Jiang Liu 

[ Upstream commit 65c484609a3b25c35e4edcd5f2c38f98f5226093 ]

When doing a patial write and the whole page is filled with zero,
zram_bvec_write() will free uncmem twice.

Signed-off-by: Jiang Liu 
Acked-by: Minchan Kim 
Cc: sta...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Steven Rostedt 
---
 drivers/staging/zram/zram_drv.c |2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
index 5047bfe..35b6a44 100644
--- a/drivers/staging/zram/zram_drv.c
+++ b/drivers/staging/zram/zram_drv.c
@@ -327,8 +327,6 @@ static int zram_bvec_write(struct zram *zram, struct 
bio_vec *bvec, u32 index,
 
if (page_zero_filled(uncmem)) {
kunmap_atomic(user_mem);
-   if (is_partial_io(bvec))
-   kfree(uncmem);
zram_stat_inc(>stats.pages_zero);
zram_set_flag(zram, index, ZRAM_ZERO);
ret = 0;
-- 
1.7.10.4


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

[142/251] Bluetooth: Add support for Mediatek Bluetooth device [0e8d:763f]

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: "Cho, Yu-Chen" 

[ Upstream commit 178c059e7640aa8e50213400c6f3dde00189d979 ]

This patch adds support for Mediatek Bluetooth device

T:  Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#=  2 Spd=480  MxCh= 0
D:  Ver= 2.01 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0e8d ProdID=763f Rev= 1.00
S:  Manufacturer=MediaTek
S:  Product=BT
S:  SerialNumber=1.0
C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=450mA
A:  FirstIf#= 0 IfCount= 2 Cls=ff(vend.) Sub=ff Prot=ff
I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=125us
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=125us
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
I:  If#= 1 Alt= 6 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms

Signed-off-by: Cho, Yu-Chen 
Signed-off-by: Gustavo Padovan 
Signed-off-by: John W. Linville 
Signed-off-by: Steven Rostedt 
---
 drivers/bluetooth/btusb.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 30ac56b..2d139a6 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -55,6 +55,9 @@ static struct usb_device_id btusb_table[] = {
/* Apple-specific (Broadcom) devices */
{ USB_VENDOR_AND_INTERFACE_INFO(0x05ac, 0xff, 0x01, 0x01) },
 
+   /* MediaTek MT76x0E */
+   { USB_DEVICE(0x0e8d, 0x763f) },
+
/* Broadcom SoftSailing reporting vendor specific */
{ USB_DEVICE(0x0a5c, 0x21e1) },
 
-- 
1.7.10.4


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

[145/251] zram: avoid invalid memory access in zram_exit()

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Jiang Liu 

[ Upstream commit 6030ea9b35971a4200062f010341ab832e878ac9 ]

Memory for zram->disk object may have already been freed after returning
from destroy_device(zram), then it's unsafe for zram_reset_device(zram)
to access zram->disk again.

We can't solve this bug by flipping the order of destroy_device(zram)
and zram_reset_device(zram), that will cause deadlock issues to the
zram sysfs handler.

So fix it by holding an extra reference to zram->disk before calling
destroy_device(zram).

Signed-off-by: Jiang Liu 
Cc: sta...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Steven Rostedt 
---
 drivers/staging/zram/zram_drv.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
index 6edefde..38a1b44 100644
--- a/drivers/staging/zram/zram_drv.c
+++ b/drivers/staging/zram/zram_drv.c
@@ -771,9 +771,11 @@ static void __exit zram_exit(void)
for (i = 0; i < num_devices; i++) {
zram = _devices[i];
 
+   get_disk(zram->disk);
destroy_device(zram);
if (zram->init_done)
zram_reset_device(zram);
+   put_disk(zram->disk);
}
 
unregister_blkdev(zram_major, "zram");
-- 
1.7.10.4


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

[247/251] drm/i915: ivb: fix edp voltage swing reg val

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Imre Deak 

[ Upstream commit 77fa4cbd5fa389e28419bbe8ac491b5fdd54840d ]

Fix the typo introduced in

commit 1a2eb4604b85c5efb343da8a4dcf41288fcfca85
Author: Keith Packard 
Date:   Wed Nov 16 16:26:07 2011 -0800

drm/i915: Hook up Ivybridge eDP

This fixes eDP link-training failures and cases where all voltage swing
/pre-emphasis levels were tried and failed during clock recovery and -
as a fallback - we go on to do channel equalization with the last voltage
swing/pre-emphasis level which will succeed. Both issues can lead to a
blank screen.

v2:
- improve commit message

CC: sta...@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64880
Tested-by: Jeremy Moles 
Signed-off-by: Imre Deak 
Reviewed-by: Paulo Zanoni 
Signed-off-by: Daniel Vetter 
Signed-off-by: Steven Rostedt 
---
 drivers/gpu/drm/i915/i915_reg.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index bbdb976..9d37a9d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4076,7 +4076,7 @@
 #define EDP_LINK_TRAIN_600MV_0DB_IVB   (0x30 <<22)
 #define EDP_LINK_TRAIN_600MV_3_5DB_IVB (0x36 <<22)
 #define EDP_LINK_TRAIN_800MV_0DB_IVB   (0x38 <<22)
-#define EDP_LINK_TRAIN_800MV_3_5DB_IVB (0x33 <<22)
+#define EDP_LINK_TRAIN_800MV_3_5DB_IVB (0x3e <<22)
 
 /* legacy values */
 #define EDP_LINK_TRAIN_500MV_0DB_IVB   (0x00 <<22)
-- 
1.7.10.4


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

[135/251] iwlwifi: add DELL SKU for 5150 HMC

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Emmanuel Grumbach 

[ Upstream commit a1923f1d4723e5757cefdd60f7c7ab30e472007a ]

This SKU was missing in the list of supported devices

https://bugzilla.kernel.org/show_bug.cgi?id=60577

Cc:  [all versions]
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Johannes Berg 
Signed-off-by: Steven Rostedt 
---
 drivers/net/wireless/iwlwifi/pcie/drv.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/iwlwifi/pcie/drv.c 
b/drivers/net/wireless/iwlwifi/pcie/drv.c
index f4c3500..71e887c 100644
--- a/drivers/net/wireless/iwlwifi/pcie/drv.c
+++ b/drivers/net/wireless/iwlwifi/pcie/drv.c
@@ -132,6 +132,7 @@ static DEFINE_PCI_DEVICE_TABLE(iwl_hw_card_ids) = {
{IWL_PCI_DEVICE(0x423C, 0x1306, iwl5150_abg_cfg)}, /* Half Mini Card */
{IWL_PCI_DEVICE(0x423C, 0x1221, iwl5150_agn_cfg)}, /* Mini Card */
{IWL_PCI_DEVICE(0x423C, 0x1321, iwl5150_agn_cfg)}, /* Half Mini Card */
+   {IWL_PCI_DEVICE(0x423C, 0x1326, iwl5150_abg_cfg)}, /* Half Mini Card */
 
{IWL_PCI_DEVICE(0x423D, 0x1211, iwl5150_agn_cfg)}, /* Mini Card */
{IWL_PCI_DEVICE(0x423D, 0x1311, iwl5150_agn_cfg)}, /* Half Mini Card */
-- 
1.7.10.4


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

[130/251] serial/mxs-auart: increase time to wait for transmitter to become idle

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= 

[ Upstream commit 079a036f4283e2b0e5c26080b8c5112bc0cc1831 ]

Without this patch the driver waits ~1 ms for the UART to become idle. At
115200n8 this time is (theoretically) enough to transfer 11.5 characters
(= 115200 bits/s / (10 Bits/char) * 1ms). As the mxs-auart has a fifo size
of 16 characters the clock is gated too early. The problem is worse for
lower baud rates.

This only happens to really shut down the transmitter in the middle of a
transfer if /dev/ttyAPPx isn't opened in userspace (e.g. by a getty) but
was at least once (because the bootloader doesn't disable the transmitter).

So increase the timeout to 20 ms which should be enough for 9600n8, too.
Moreover skip gating the clock if the timeout is elapsed.

Cc: sta...@vger.kernel.org # v2.6.39+
Signed-off-by: Uwe Kleine-König 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Steven Rostedt 
---
 drivers/tty/serial/mxs-auart.c |   21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index 634be9b..647609d 100644
--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -550,7 +550,7 @@ auart_console_write(struct console *co, const char *str, 
unsigned int count)
struct mxs_auart_port *s;
struct uart_port *port;
unsigned int old_ctrl0, old_ctrl2;
-   unsigned int to = 1000;
+   unsigned int to = 2;
 
if (co->index > MXS_AUART_PORTS || co->index < 0)
return;
@@ -571,18 +571,23 @@ auart_console_write(struct console *co, const char *str, 
unsigned int count)
 
uart_console_write(port, str, count, mxs_auart_console_putchar);
 
-   /*
-* Finally, wait for transmitter to become empty
-* and restore the TCR
-*/
+   /* Finally, wait for transmitter to become empty ... */
while (readl(port->membase + AUART_STAT) & AUART_STAT_BUSY) {
+   udelay(1);
if (!to--)
break;
-   udelay(1);
}
 
-   writel(old_ctrl0, port->membase + AUART_CTRL0);
-   writel(old_ctrl2, port->membase + AUART_CTRL2);
+   /*
+* ... and restore the TCR if we waited long enough for the transmitter
+* to be idle. This might keep the transmitter enabled although it is
+* unused, but that is better than to disable it while it is still
+* transmitting.
+*/
+   if (!(readl(port->membase + AUART_STAT) & AUART_STAT_BUSY)) {
+   writel(old_ctrl0, port->membase + AUART_CTRL0);
+   writel(old_ctrl2, port->membase + AUART_CTRL2);
+   }
 
clk_disable(s->clk);
 }
-- 
1.7.10.4


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

[136/251] ath9k_htc: do some initial hardware configuration

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Oleksij Rempel 

[ Upstream commit dc2a87f519a4d8cb376ab54f22b6b98a943b51ce ]

Currently we configure harwdare and clock, only after
interface start. In this case, if we reload module or
reboot PC without configuring adapter, firmware will freeze.
There is no software way to reset adpter.

This patch add initial configuration and set it in
disabled state, to avoid this freeze. Behaviour of this patch
should be similar to: ifconfig wlan0 up; ifconfig wlan0 down.

Bug: https://github.com/qca/open-ath9k-htc-firmware/issues/1
Tested-by: Bo Shi 
Signed-off-by: Oleksij Rempel 
Cc: 
Signed-off-by: John W. Linville 
Signed-off-by: Steven Rostedt 
---
 drivers/net/wireless/ath/ath9k/htc_drv_init.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c 
b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index 01248b9..4303173 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -824,6 +824,7 @@ static int ath9k_init_device(struct ath9k_htc_priv *priv,
if (error != 0)
goto err_rx;
 
+   ath9k_hw_disable(priv->ah);
 #ifdef CONFIG_MAC80211_LEDS
/* must be initialized before ieee80211_register_hw */
priv->led_cdev.default_trigger = 
ieee80211_create_tpt_led_trigger(priv->hw,
-- 
1.7.10.4


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

[140/251] ixgbe: Fix Tx Hang issue with lldpad on 82598EB

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Jacob Keller 

[ Upstream commit 1eb9ac14c34a948bf1538bfb9034e8ab29099a64 ]

This patch fixes an issue with the 82598EB device, where lldpad is causing Tx
Hangs on the card as soon as it attempts to configure DCB for the device. The
adapter will continually Tx hang and reset in a loop.

Signed-off-by: Jacob Keller 
Cc: Stable 
Tested-by: Phil Schmitt 
Tested-by: Jack Morgan 
Signed-off-by: Jeff Kirsher 
Signed-off-by: David S. Miller 
Signed-off-by: Steven Rostedt 
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_82598.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_82598.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_82598.c
index 87592b4..b3c05de 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_82598.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_82598.c
@@ -108,9 +108,8 @@ s32 ixgbe_dcb_config_tx_desc_arbiter_82598(struct ixgbe_hw 
*hw,
 
/* Enable arbiter */
reg &= ~IXGBE_DPMCS_ARBDIS;
-   /* Enable DFP and Recycle mode */
-   reg |= (IXGBE_DPMCS_TDPAC | IXGBE_DPMCS_TRM);
reg |= IXGBE_DPMCS_TSOEF;
+
/* Configure Max TSO packet size 34KB including payload and headers */
reg |= (0x4 << IXGBE_DPMCS_MTSOS_SHIFT);
 
-- 
1.7.10.4


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

[137/251] nl80211: fix mgmt tx status and testmode reporting for netns

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Michal Kazior 

[ Upstream commit a0ec570f4f69c4cb700d743a915096c2c8f56a99 ]

These two events were sent to the default network
namespace.

This caused AP mode in a non-default netns to not
work correctly. Mgmt tx status was multicasted to
a different (default) netns instead of the one the
AP was in.

Cc: sta...@vger.kernel.org
Signed-off-by: Michal Kazior 
Signed-off-by: Johannes Berg 
Signed-off-by: Steven Rostedt 
---
 net/wireless/nl80211.c |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 1e37dbf..79ad33d 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -5542,12 +5542,14 @@ EXPORT_SYMBOL(cfg80211_testmode_alloc_event_skb);
 
 void cfg80211_testmode_event(struct sk_buff *skb, gfp_t gfp)
 {
+   struct cfg80211_registered_device *rdev = ((void **)skb->cb)[0];
void *hdr = ((void **)skb->cb)[1];
struct nlattr *data = ((void **)skb->cb)[2];
 
nla_nest_end(skb, data);
genlmsg_end(skb, hdr);
-   genlmsg_multicast(skb, 0, nl80211_testmode_mcgrp.id, gfp);
+   genlmsg_multicast_netns(wiphy_net(>wiphy), skb, 0,
+   nl80211_testmode_mcgrp.id, gfp);
 }
 EXPORT_SYMBOL(cfg80211_testmode_event);
 #endif
@@ -8378,7 +8380,8 @@ void nl80211_send_mgmt_tx_status(struct 
cfg80211_registered_device *rdev,
 
genlmsg_end(msg, hdr);
 
-   genlmsg_multicast(msg, 0, nl80211_mlme_mcgrp.id, gfp);
+   genlmsg_multicast_netns(wiphy_net(>wiphy), msg, 0,
+   nl80211_mlme_mcgrp.id, gfp);
return;
 
  nla_put_failure:
-- 
1.7.10.4


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

[128/251] ALSA: compress: fix the return value for SNDRV_COMPRESS_VERSION

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Vinod Koul 

[ Upstream commit a8d30608eaed6cc759b8e2e8a842591f797f ]

the return value of SNDRV_COMPRESS_VERSION always return default -ENOTTY as the
return value was never updated for this call
assign return value from put_user()

Reported-by: Haynes 
CC: sta...@vger.kernel.org
Signed-off-by: Vinod Koul 
Signed-off-by: Takashi Iwai 
Signed-off-by: Steven Rostedt 
---
 sound/core/compress_offload.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/core/compress_offload.c b/sound/core/compress_offload.c
index d5103f7..20f55e2 100644
--- a/sound/core/compress_offload.c
+++ b/sound/core/compress_offload.c
@@ -582,7 +582,7 @@ static long snd_compr_ioctl(struct file *f, unsigned int 
cmd, unsigned long arg)
mutex_lock(>device->lock);
switch (_IOC_NR(cmd)) {
case _IOC_NR(SNDRV_COMPRESS_IOCTL_VERSION):
-   put_user(SNDRV_COMPRESS_VERSION,
+   retval = put_user(SNDRV_COMPRESS_VERSION,
(int __user *)arg) ? -EFAULT : 0;
break;
case _IOC_NR(SNDRV_COMPRESS_GET_CAPS):
-- 
1.7.10.4


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

[132/251] USB: mos7840: fix device-type detection

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Johan Hovold 

[ Upstream commit 40c24f2893ba0ba7df485871f6aac0c197ceef5b ]

Fix race in device-type detection introduced by commit 0eafe4de ("USB:
serial: mos7840: add support for MCS7810 devices") which used a static
variable to hold the device type.

Move type detection to probe and use serial data to store the device
type.

Cc: sta...@vger.kernel.org
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Steven Rostedt 
---
 drivers/usb/serial/mos7840.c |   75 --
 1 file changed, 35 insertions(+), 40 deletions(-)

diff --git a/drivers/usb/serial/mos7840.c b/drivers/usb/serial/mos7840.c
index 2e218ee..ed55ac0 100644
--- a/drivers/usb/serial/mos7840.c
+++ b/drivers/usb/serial/mos7840.c
@@ -191,8 +191,6 @@ enum mos7840_flag {
MOS7840_FLAG_CTRL_BUSY,
 };
 
-static int device_type;
-
 static const struct usb_device_id id_table[] = {
{USB_DEVICE(USB_VENDOR_ID_MOSCHIP, MOSCHIP_DEVICE_ID_7840)},
{USB_DEVICE(USB_VENDOR_ID_MOSCHIP, MOSCHIP_DEVICE_ID_7820)},
@@ -893,18 +891,6 @@ static void mos7840_bulk_out_data_callback(struct urb *urb)
 //
 /*   D R I V E R  T T Y  I N T E R F A C E  F U N C T I O N S   */
 //
-#ifdef MCSSerialProbe
-static int mos7840_serial_probe(struct usb_serial *serial,
-   const struct usb_device_id *id)
-{
-
-   /*need to implement the mode_reg reading and updating\
-  structures usb_serial_ device_type\
-  (i.e num_ports, num_bulkin,bulkout etc) */
-   /* Also we can update the changes  attach */
-   return 1;
-}
-#endif
 
 /*
  * mos7840_open
@@ -2415,38 +2401,48 @@ static int mos7810_check(struct usb_serial *serial)
return 0;
 }
 
-static int mos7840_calc_num_ports(struct usb_serial *serial)
+static int mos7840_probe(struct usb_serial *serial,
+   const struct usb_device_id *id)
 {
-   __u16 data = 0x00;
+   u16 product = serial->dev->descriptor.idProduct;
u8 *buf;
-   int mos7840_num_ports;
+   int device_type;
+
+   if (product == MOSCHIP_DEVICE_ID_7810 ||
+   product == MOSCHIP_DEVICE_ID_7820) {
+   device_type = product;
+   goto out;
+   }
 
buf = kzalloc(VENDOR_READ_LENGTH, GFP_KERNEL);
-   if (buf) {
-   usb_control_msg(serial->dev, usb_rcvctrlpipe(serial->dev, 0),
+   if (!buf)
+   return -ENOMEM;
+
+   usb_control_msg(serial->dev, usb_rcvctrlpipe(serial->dev, 0),
MCS_RDREQ, MCS_RD_RTYPE, 0, GPIO_REGISTER, buf,
VENDOR_READ_LENGTH, MOS_WDR_TIMEOUT);
-   data = *buf;
-   kfree(buf);
-   }
 
-   if (serial->dev->descriptor.idProduct == MOSCHIP_DEVICE_ID_7810 ||
-   serial->dev->descriptor.idProduct == MOSCHIP_DEVICE_ID_7820) {
-   device_type = serial->dev->descriptor.idProduct;
-   } else {
-   /* For a MCS7840 device GPIO0 must be set to 1 */
-   if ((data & 0x01) == 1)
-   device_type = MOSCHIP_DEVICE_ID_7840;
-   else if (mos7810_check(serial))
-   device_type = MOSCHIP_DEVICE_ID_7810;
-   else
-   device_type = MOSCHIP_DEVICE_ID_7820;
-   }
+   /* For a MCS7840 device GPIO0 must be set to 1 */
+   if (buf[0] & 0x01)
+   device_type = MOSCHIP_DEVICE_ID_7840;
+   else if (mos7810_check(serial))
+   device_type = MOSCHIP_DEVICE_ID_7810;
+   else
+   device_type = MOSCHIP_DEVICE_ID_7820;
+
+   kfree(buf);
+out:
+   usb_set_serial_data(serial, (void *)device_type);
+
+   return 0;
+}
+
+static int mos7840_calc_num_ports(struct usb_serial *serial)
+{
+   int device_type = (int)usb_get_serial_data(serial);
+   int mos7840_num_ports;
 
mos7840_num_ports = (device_type >> 4) & 0x000F;
-   serial->num_bulk_in = mos7840_num_ports;
-   serial->num_bulk_out = mos7840_num_ports;
-   serial->num_ports = mos7840_num_ports;
 
return mos7840_num_ports;
 }
@@ -2454,6 +2450,7 @@ static int mos7840_calc_num_ports(struct usb_serial 
*serial)
 static int mos7840_port_probe(struct usb_serial_port *port)
 {
struct usb_serial *serial = port->serial;
+   int device_type = (int)usb_get_serial_data(serial);
struct moschip_port *mos7840_port;
int status;
int pnum;
@@ -2744,9 +2741,7 @@ static struct usb_serial_driver moschip7840_4port_device 
= {
.throttle = mos7840_throttle,
.unthrottle = mos7840_unthrottle,

Re: [PATCH] ARM: DTS: DRA7: Add TPS659038 PMIC nodes

[Keerthy]

On Tuesday 10 September 2013 12:51 AM, Nishanth Menon wrote:

On 08/26/2013 12:36 AM, Keerthy wrote:

The Patch adds nodes for TPS659038 PMIC for DRA7 boards.

It is based on top of:
http://comments.gmane.org/gmane.linux.ports.arm.omap/102459.

Documentation:  Documentation/devicetree/bindings/mfd/palmas.txt
Documentation/devicetree/bindings/regulator/palmas-pmic.txt 


Boot Tested on DRA7 d1 Board.

Signed-off-by: Keerthy 
---
  arch/arm/boot/dts/dra7-evm.dts |  118 
  1 file changed, 118 insertions(+)

Index: linux/arch/arm/boot/dts/dra7-evm.dts
===
--- linux.orig/arch/arm/boot/dts/dra7-evm.dts   2013-08-26 09:57:52.496173554 
+0530
+++ linux/arch/arm/boot/dts/dra7-evm.dts2013-08-26 10:38:44.995414695 
+0530
@@ -93,6 +93,119 @@
pinctrl-names = "default";
pinctrl-0 = <_pins>;
clock-frequency = <40>;
+
+   tps659038: tps659038@58 {
+   compatible = "ti,tps659038";
+   reg = <0x58>;
+
+   tps659038_pmic {
+   compatible = "ti,tps659038-pmic";
+
+   regulators {
+   smps123_reg: smps123 {
+   /* VDD_MPU */
+   regulator-name = "smps123";
+   regulator-min-microvolt = < 
85>;
+   regulator-max-microvolt = 
<125>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   smps45_reg: smps45 {
+   /* VDD_DSPEVE */
+   regulator-name = "smps45";
+   regulator-min-microvolt = < 
85>;
+   regulator-max-microvolt = 
<115>;
+   regulator-boot-on;
+   };
+
+   smps6_reg: smps6 {
+   /* VDD_GPU - over VDD_SMPS6 */
+   regulator-name = "smps6";
+   regulator-min-microvolt = 
<85>;
+   regulator-max-microvolt = 
<1250>;
+   regulator-boot-on;
+   };
+
+   smps7_reg: smps7 {
+   /* CORE_VDD */
+   regulator-name = "smps7";
+   regulator-min-microvolt = 
<85>;
+   regulator-max-microvolt = 
<103>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   smps8_reg: smps8 {
+   /* VDD_IVAHD */
+   regulator-name = "smps8";
+   regulator-min-microvolt = < 
85>;
+   regulator-max-microvolt = 
<125>;
+   regulator-boot-on;
+   };
+
+   smps9_reg: smps9 {
+   /* VDDS1V8 */
+   regulator-name = "smps9";
+   regulator-min-microvolt = 
<180>;
+   regulator-max-microvolt = 
<180>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   ldo1_reg: ldo1 {
+   /* LDO1_OUT --> SDIO  */
+   regulator-name = "ldo1";
+   regulator-min-microvolt = 
<180>;
+   regulator-max-microvolt = 
<330>;
+   regulator-boot-on;
+   };
+
+   ldo2_reg: ldo2 {
+   /* VDD_RTCIO */
+   /* LDO2 -> VDDSHV5, LDO2 also 
goes to CAN_PHY_3V3 */
+

[129/251] serial/mxs-auart: fix race condition in interrupt handler

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= 

[ Upstream commit d970d7fe65adff5efe75b4a73c4ffc9be57089f7 ]

The handler needs to ack the pending events before actually handling them.
Otherwise a new event might come in after it it considered non-pending or
handled and is acked then without being handled. So this event is only
noticed when the next interrupt happens.

Without this patch an i.MX28 based machine running an rt-patched kernel
regularly hangs during boot.

Cc: sta...@vger.kernel.org # v2.6.39+
Signed-off-by: Uwe Kleine-König 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Steven Rostedt 
---
 drivers/tty/serial/mxs-auart.c |   17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index 3a667ee..634be9b 100644
--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -381,11 +381,18 @@ static void mxs_auart_settermios(struct uart_port *u,
 
 static irqreturn_t mxs_auart_irq_handle(int irq, void *context)
 {
-   u32 istatus, istat;
+   u32 istat;
struct mxs_auart_port *s = context;
u32 stat = readl(s->port.membase + AUART_STAT);
 
-   istatus = istat = readl(s->port.membase + AUART_INTR);
+   istat = readl(s->port.membase + AUART_INTR);
+
+   /* ack irq */
+   writel(istat & (AUART_INTR_RTIS
+   | AUART_INTR_TXIS
+   | AUART_INTR_RXIS
+   | AUART_INTR_CTSMIS),
+   s->port.membase + AUART_INTR_CLR);
 
if (istat & AUART_INTR_CTSMIS) {
uart_handle_cts_change(>port, stat & AUART_STAT_CTS);
@@ -404,12 +411,6 @@ static irqreturn_t mxs_auart_irq_handle(int irq, void 
*context)
istat &= ~AUART_INTR_TXIS;
}
 
-   writel(istatus & (AUART_INTR_RTIS
-   | AUART_INTR_TXIS
-   | AUART_INTR_RXIS
-   | AUART_INTR_CTSMIS),
-   s->port.membase + AUART_INTR_CLR);
-
return IRQ_HANDLED;
 }
 
-- 
1.7.10.4


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

[127/251] ARM: 7790/1: Fix deferred mm switch on VIVT processors

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Catalin Marinas 

[ Upstream commit bdae73cd374e28db544fdd9b77de689a36e3c129 ]

As of commit b9d4d42ad9 (ARM: Remove __ARCH_WANT_INTERRUPTS_ON_CTXSW on
pre-ARMv6 CPUs), the mm switching on VIVT processors is done in the
finish_arch_post_lock_switch() function to avoid whole cache flushing
with interrupts disabled. The need for deferred mm switch is stored as a
thread flag (TIF_SWITCH_MM). However, with preemption enabled, we can
have another thread switch before finish_arch_post_lock_switch(). If the
new thread has the same mm as the previous 'next' thread, the scheduler
will not call switch_mm() and the TIF_SWITCH_MM flag won't be set for
the new thread.

This patch moves the switch pending flag to the mm_context_t structure
since this is specific to the mm rather than thread.

Signed-off-by: Catalin Marinas 
Reported-by: Marc Kleine-Budde 
Tested-by: Marc Kleine-Budde 
Cc:  # 3.5+
Signed-off-by: Russell King 
Signed-off-by: Steven Rostedt 
---
 arch/arm/include/asm/mmu.h |2 ++
 arch/arm/include/asm/mmu_context.h |   20 
 arch/arm/include/asm/thread_info.h |1 -
 3 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/arch/arm/include/asm/mmu.h b/arch/arm/include/asm/mmu.h
index 1496565..49122c4 100644
--- a/arch/arm/include/asm/mmu.h
+++ b/arch/arm/include/asm/mmu.h
@@ -7,6 +7,8 @@ typedef struct {
 #ifdef CONFIG_CPU_HAS_ASID
unsigned int id;
raw_spinlock_t id_lock;
+#else
+   int switch_pending;
 #endif
unsigned int kvm_seq;
 } mm_context_t;
diff --git a/arch/arm/include/asm/mmu_context.h 
b/arch/arm/include/asm/mmu_context.h
index 0306bc6..549f1c6 100644
--- a/arch/arm/include/asm/mmu_context.h
+++ b/arch/arm/include/asm/mmu_context.h
@@ -121,7 +121,7 @@ static inline void check_and_switch_context(struct 
mm_struct *mm,
 * on non-ASID CPUs, the old mm will remain valid until the
 * finish_arch_post_lock_switch() call.
 */
-   set_ti_thread_flag(task_thread_info(tsk), TIF_SWITCH_MM);
+   mm->context.switch_pending = 1;
else
cpu_switch_mm(mm->pgd, mm);
 }
@@ -130,9 +130,21 @@ static inline void check_and_switch_context(struct 
mm_struct *mm,
finish_arch_post_lock_switch
 static inline void finish_arch_post_lock_switch(void)
 {
-   if (test_and_clear_thread_flag(TIF_SWITCH_MM)) {
-   struct mm_struct *mm = current->mm;
-   cpu_switch_mm(mm->pgd, mm);
+   struct mm_struct *mm = current->mm;
+
+   if (mm && mm->context.switch_pending) {
+   /*
+* Preemption must be disabled during cpu_switch_mm() as we
+* have some stateful cache flush implementations. Check
+* switch_pending again in case we were preempted and the
+* switch to this mm was already done.
+*/
+   preempt_disable();
+   if (mm->context.switch_pending) {
+   mm->context.switch_pending = 0;
+   cpu_switch_mm(mm->pgd, mm);
+   }
+   preempt_enable_no_resched();
}
 }
 
diff --git a/arch/arm/include/asm/thread_info.h 
b/arch/arm/include/asm/thread_info.h
index af7b0bd..86682b1 100644
--- a/arch/arm/include/asm/thread_info.h
+++ b/arch/arm/include/asm/thread_info.h
@@ -153,7 +153,6 @@ extern int vfp_restore_user_hwstate(struct user_vfp __user 
*,
 #define TIF_MEMDIE 18  /* is terminating due to OOM killer */
 #define TIF_RESTORE_SIGMASK20
 #define TIF_SECCOMP21
-#define TIF_SWITCH_MM  22  /* deferred switch_mm */
 
 #define _TIF_SIGPENDING(1 << TIF_SIGPENDING)
 #define _TIF_NEED_RESCHED  (1 << TIF_NEED_RESCHED)
-- 
1.7.10.4


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

[131/251] USB: mos7840: fix race in register handling

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Johan Hovold 

[ Upstream commit d8a083cc746664916d9d36ed9e4d08a29525f245 ]

Fix race in mos7840_get_reg which unconditionally manipulated the
control urb (which may already be in use) by adding a control-urb busy
flag.

Cc: sta...@vger.kernel.org
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Steven Rostedt 
---
 drivers/usb/serial/mos7840.c |   18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/serial/mos7840.c b/drivers/usb/serial/mos7840.c
index 15cc47d..2e218ee 100644
--- a/drivers/usb/serial/mos7840.c
+++ b/drivers/usb/serial/mos7840.c
@@ -187,6 +187,10 @@
 #define LED_ON_MS  500
 #define LED_OFF_MS 500
 
+enum mos7840_flag {
+   MOS7840_FLAG_CTRL_BUSY,
+};
+
 static int device_type;
 
 static const struct usb_device_id id_table[] = {
@@ -247,6 +251,8 @@ struct moschip_port {
bool led_flag;
struct timer_list led_timer1;   /* Timer for LED on */
struct timer_list led_timer2;   /* Timer for LED off */
+
+   unsigned long flags;
 };
 
 static bool debug;
@@ -507,11 +513,11 @@ static void mos7840_control_callback(struct urb *urb)
/* this urb is terminated, clean up */
dbg("%s - urb shutting down with status: %d", __func__,
status);
-   return;
+   goto out;
default:
dbg("%s - nonzero urb status received: %d", __func__,
status);
-   return;
+   goto out;
}
 
dbg("%s urb buffer size is %d", __func__, urb->actual_length);
@@ -524,6 +530,8 @@ static void mos7840_control_callback(struct urb *urb)
mos7840_handle_new_msr(mos7840_port, regval);
else if (mos7840_port->MsrLsr == 1)
mos7840_handle_new_lsr(mos7840_port, regval);
+out:
+   clear_bit_unlock(MOS7840_FLAG_CTRL_BUSY, _port->flags);
 }
 
 static int mos7840_get_reg(struct moschip_port *mcs, __u16 Wval, __u16 reg,
@@ -534,6 +542,9 @@ static int mos7840_get_reg(struct moschip_port *mcs, __u16 
Wval, __u16 reg,
unsigned char *buffer = mcs->ctrl_buf;
int ret;
 
+   if (test_and_set_bit_lock(MOS7840_FLAG_CTRL_BUSY, >flags))
+   return -EBUSY;
+
dr->bRequestType = MCS_RD_RTYPE;
dr->bRequest = MCS_RDREQ;
dr->wValue = cpu_to_le16(Wval); /* 0 */
@@ -545,6 +556,9 @@ static int mos7840_get_reg(struct moschip_port *mcs, __u16 
Wval, __u16 reg,
 mos7840_control_callback, mcs);
mcs->control_urb->transfer_buffer_length = 2;
ret = usb_submit_urb(mcs->control_urb, GFP_ATOMIC);
+   if (ret)
+   clear_bit_unlock(MOS7840_FLAG_CTRL_BUSY, >flags);
+
return ret;
 }
 
-- 
1.7.10.4


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

[126/251] powerpc/windfarm: Fix noisy slots-fan on Xserve (rm31)

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Aaro Koskinen 

[ Upstream commit fe956a1d4081ce1a959f87df397a15e252201f10 ]

slots-fan on G5 Xserve is always running at full speed with windfarm_rm31
driver, resulting in a very high acoustic noise level. It seems the fan
parameters are incorrect, and have been copied from the Drive Bay fan
(RPM, not present on rm31) of the legacy therm_pm72 driver. This patch
changes the parameters to match the Slots fan (PWM) of therm_pm72. With
the patch, slots-fan speed drops from 99% to 19% during normal use,
and slots-temp settle to ~42'C.

Signed-off-by: Aaro Koskinen 
CC: 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Steven Rostedt 
---
 drivers/macintosh/windfarm_rm31.c |   18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/macintosh/windfarm_rm31.c 
b/drivers/macintosh/windfarm_rm31.c
index 3eca6d4..e13d9fd 100644
--- a/drivers/macintosh/windfarm_rm31.c
+++ b/drivers/macintosh/windfarm_rm31.c
@@ -439,15 +439,15 @@ static void backside_setup_pid(void)
 
 /* Slots fan */
 static const struct wf_pid_param slots_param = {
-   .interval   = 5,
-   .history_len= 2,
-   .gd = 30 << 20,
-   .gp = 5 << 20,
-   .gr = 0,
-   .itarget= 40 << 16,
-   .additive   = 1,
-   .min= 300,
-   .max= 4000,
+   .interval   = 1,
+   .history_len= 20,
+   .gd = 0,
+   .gp = 0,
+   .gr = 0x0010,
+   .itarget= 320,
+   .additive   = 0,
+   .min= 20,
+   .max= 100,
 };
 
 static void slots_fan_tick(void)
-- 
1.7.10.4


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

[246/251] drm/vmwgfx: Split GMR2_REMAP commands if they are to large

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Jakob Bornecrantz 

[ Upstream commit 6e4dcff3adbf25acb87e74500a58e3c07bdec40f ]

This fixes the piglit test texturing/max-texture-size
causing the VM to die due to a too large SVGA command.

Signed-off-by: Jakob Bornecrantz 
Reviewed-by: Biran Paul 
Reviewed-by: Zack Rusin 
Cc: sta...@vger.kernel.org
Signed-off-by: Dave Airlie 
Signed-off-by: Steven Rostedt 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c |   58 +++
 1 file changed, 39 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c
index 21ee782..e1978a2 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c
@@ -29,7 +29,9 @@
 #include "drmP.h"
 #include "ttm/ttm_bo_driver.h"
 
-#define VMW_PPN_SIZE sizeof(unsigned long)
+#define VMW_PPN_SIZE (sizeof(unsigned long))
+/* A future safe maximum remap size. */
+#define VMW_PPN_PER_REMAP ((31 * 1024) / VMW_PPN_SIZE)
 
 static int vmw_gmr2_bind(struct vmw_private *dev_priv,
 struct page *pages[],
@@ -38,43 +40,61 @@ static int vmw_gmr2_bind(struct vmw_private *dev_priv,
 {
SVGAFifoCmdDefineGMR2 define_cmd;
SVGAFifoCmdRemapGMR2 remap_cmd;
-   uint32_t define_size = sizeof(define_cmd) + 4;
-   uint32_t remap_size = VMW_PPN_SIZE * num_pages + sizeof(remap_cmd) + 4;
uint32_t *cmd;
uint32_t *cmd_orig;
+   uint32_t define_size = sizeof(define_cmd) + sizeof(*cmd);
+   uint32_t remap_num = num_pages / VMW_PPN_PER_REMAP + ((num_pages % 
VMW_PPN_PER_REMAP) > 0);
+   uint32_t remap_size = VMW_PPN_SIZE * num_pages + (sizeof(remap_cmd) + 
sizeof(*cmd)) * remap_num;
+   uint32_t remap_pos = 0;
+   uint32_t cmd_size = define_size + remap_size;
uint32_t i;
 
-   cmd_orig = cmd = vmw_fifo_reserve(dev_priv, define_size + remap_size);
+   cmd_orig = cmd = vmw_fifo_reserve(dev_priv, cmd_size);
if (unlikely(cmd == NULL))
return -ENOMEM;
 
define_cmd.gmrId = gmr_id;
define_cmd.numPages = num_pages;
 
+   *cmd++ = SVGA_CMD_DEFINE_GMR2;
+   memcpy(cmd, _cmd, sizeof(define_cmd));
+   cmd += sizeof(define_cmd) / sizeof(*cmd);
+
+   /*
+* Need to split the command if there are too many
+* pages that goes into the gmr.
+*/
+
remap_cmd.gmrId = gmr_id;
remap_cmd.flags = (VMW_PPN_SIZE > sizeof(*cmd)) ?
SVGA_REMAP_GMR2_PPN64 : SVGA_REMAP_GMR2_PPN32;
-   remap_cmd.offsetPages = 0;
-   remap_cmd.numPages = num_pages;
 
-   *cmd++ = SVGA_CMD_DEFINE_GMR2;
-   memcpy(cmd, _cmd, sizeof(define_cmd));
-   cmd += sizeof(define_cmd) / sizeof(uint32);
+   while (num_pages > 0) {
+   unsigned long nr = min(num_pages, (unsigned 
long)VMW_PPN_PER_REMAP);
+
+   remap_cmd.offsetPages = remap_pos;
+   remap_cmd.numPages = nr;
 
-   *cmd++ = SVGA_CMD_REMAP_GMR2;
-   memcpy(cmd, _cmd, sizeof(remap_cmd));
-   cmd += sizeof(remap_cmd) / sizeof(uint32);
+   *cmd++ = SVGA_CMD_REMAP_GMR2;
+   memcpy(cmd, _cmd, sizeof(remap_cmd));
+   cmd += sizeof(remap_cmd) / sizeof(*cmd);
 
-   for (i = 0; i < num_pages; ++i) {
-   if (VMW_PPN_SIZE <= 4)
-   *cmd = page_to_pfn(*pages++);
-   else
-   *((uint64_t *)cmd) = page_to_pfn(*pages++);
+   for (i = 0; i < nr; ++i) {
+   if (VMW_PPN_SIZE <= 4)
+   *cmd = page_to_pfn(*pages++);
+   else
+   *((uint64_t *)cmd) = page_to_pfn(*pages++);
 
-   cmd += VMW_PPN_SIZE / sizeof(*cmd);
+   cmd += VMW_PPN_SIZE / sizeof(*cmd);
+   }
+
+   num_pages -= nr;
+   remap_pos += nr;
}
 
-   vmw_fifo_commit(dev_priv, define_size + remap_size);
+   BUG_ON(cmd != cmd_orig + cmd_size / sizeof(*cmd));
+
+   vmw_fifo_commit(dev_priv, cmd_size);
 
return 0;
 }
-- 
1.7.10.4


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

[125/251] ARM: make vectors page inaccessible from userspace

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Russell King 

[ Upstream commit a5463cd3435475386cbbe7b06e01292ac169d36f ]

If kuser helpers are not provided by the kernel, disable user access to
the vectors page.  With the kuser helpers gone, there is no reason for
this page to be visible to userspace.

Signed-off-by: Russell King 
Signed-off-by: Steven Rostedt 
---
 arch/arm/include/asm/page.h |2 ++
 arch/arm/kernel/process.c   |7 ++-
 arch/arm/mm/mmu.c   |4 
 3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/page.h b/arch/arm/include/asm/page.h
index ecf9019..5c35852 100644
--- a/arch/arm/include/asm/page.h
+++ b/arch/arm/include/asm/page.h
@@ -142,7 +142,9 @@ extern void __cpu_copy_user_highpage(struct page *to, 
struct page *from,
 #define clear_page(page)   memset((void *)(page), 0, PAGE_SIZE)
 extern void copy_page(void *to, const void *from);
 
+#ifdef CONFIG_KUSER_HELPERS
 #define __HAVE_ARCH_GATE_AREA 1
+#endif
 
 #ifdef CONFIG_ARM_LPAE
 #include 
diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index 693b744..427ddbc 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -508,6 +508,7 @@ unsigned long arch_randomize_brk(struct mm_struct *mm)
 }
 
 #ifdef CONFIG_MMU
+#ifdef CONFIG_KUSER_HELPERS
 /*
  * The vectors page is always readable from user space for the
  * atomic helpers and the signal restart code. Insert it into the
@@ -540,9 +541,13 @@ int in_gate_area_no_mm(unsigned long addr)
 {
return in_gate_area(NULL, addr);
 }
+#define is_gate_vma(vma)   ((vma) = _vma)
+#else
+#define is_gate_vma(vma)   0
+#endif
 
 const char *arch_vma_name(struct vm_area_struct *vma)
 {
-   return (vma == _vma) ? "[vectors]" : NULL;
+   return is_gate_vma(vma) ? "[vectors]" : NULL;
 }
 #endif
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 889f3de..50d4aff 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1125,7 +1125,11 @@ static void __init devicemaps_init(struct machine_desc 
*mdesc)
map.pfn = __phys_to_pfn(virt_to_phys(vectors));
map.virtual = 0x;
map.length = PAGE_SIZE;
+#ifdef CONFIG_KUSER_HELPERS
map.type = MT_HIGH_VECTORS;
+#else
+   map.type = MT_LOW_VECTORS;
+#endif
create_mapping();
 
if (!vectors_high()) {
-- 
1.7.10.4


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

[122/251] ARM: use linker magic for vectors and vector stubs

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Russell King 

[ Upstream commit b9b32bf70f2fb710b07c94e13afbc729afe221da ]

Use linker magic to create the vectors and vector stubs: we can tell the
linker to place them at an appropriate VMA, but keep the LMA within the
kernel.  This gets rid of some unnecessary symbol manipulation, and
have the linker calculate the relocations appropriately.

Cc: 
Acked-by: Nicolas Pitre 
Signed-off-by: Russell King 
Signed-off-by: Steven Rostedt 
---
 arch/arm/kernel/entry-armv.S  |   28 ++--
 arch/arm/kernel/vmlinux.lds.S |   17 +
 2 files changed, 27 insertions(+), 18 deletions(-)

diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index a4af8e8..c19779f 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -1035,7 +1035,7 @@ ENDPROC(vector_\name)
 1:
.endm
 
-   .globl  __stubs_start
+   .section .stubs, "ax", %progbits
 __stubs_start:
@ This must be the first word
.word   vector_swi
@@ -1162,24 +1162,16 @@ vector_addrexcptn:
 vector_fiq:
subspc, lr, #4
 
-   .globl  __stubs_end
-__stubs_end:
-
-   .equstubs_offset, __vectors_start + 0x1000 - __stubs_start
-
-   .globl  __vectors_start
+   .section .vectors, "ax", %progbits
 __vectors_start:
-   W(b)vector_rst + stubs_offset
-   W(b)vector_und + stubs_offset
-   W(ldr)  pc, .LCvswi + stubs_offset
-   W(b)vector_pabt + stubs_offset
-   W(b)vector_dabt + stubs_offset
-   W(b)vector_addrexcptn + stubs_offset
-   W(b)vector_irq + stubs_offset
-   W(b)vector_fiq + stubs_offset
-
-   .globl  __vectors_end
-__vectors_end:
+   W(b)vector_rst
+   W(b)vector_und
+   W(ldr)  pc, __vectors_start + 0x1000
+   W(b)vector_pabt
+   W(b)vector_dabt
+   W(b)vector_addrexcptn
+   W(b)vector_irq
+   W(b)vector_fiq
 
.data
 
diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 36ff15b..2f8f92e 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -137,6 +137,23 @@ SECTIONS
. = ALIGN(PAGE_SIZE);
__init_begin = .;
 #endif
+   /*
+* The vectors and stubs are relocatable code, and the
+* only thing that matters is their relative offsets
+*/
+   __vectors_start = .;
+   .vectors 0 : AT(__vectors_start) {
+   *(.vectors)
+   }
+   . = __vectors_start + SIZEOF(.vectors);
+   __vectors_end = .;
+
+   __stubs_start = .;
+   .stubs 0x1000 : AT(__stubs_start) {
+   *(.stubs)
+   }
+   . = __stubs_start + SIZEOF(.stubs);
+   __stubs_end = .;
 
INIT_TEXT_SECTION(8)
.exit.text : {
-- 
1.7.10.4


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

[GIT PULL] battery-2.6.git

[Anton Vorontsov]

Hello Linus,

Please pull battery-2.6 git tree to receive changes prepared for the v3.12
release. Here is what we have:

New drivers:

- APM X-Gene system reboot driver by Feng Kan and Loc Ho (APM).

- Qualcomm MSM reboot/poweroff driver by Abhimanyu Kapur (Codeaurora).

- Texas Instruments BQ24190 charger driver by Mark A. Greer (Animal Creek
  Technologies).

- Texas Instruments TWL4030 MADC battery driver by Lukas Märdian and Marek
  Belisko (Golden Delicious Computers). The driver is used on Freerunner
  GTA04 phones.

Highlighted fixes and improvements:

- Suspend/wakeup logic improvements: power supply objects will block
  system suspend until all power supply events are processed. Thanks to
  Zoran Markovic (Linaro), Arve Hjonnevag and Todd Poynor (Google).

Thanks!

Anton


The following changes since commit c095ba7224d8edc71dcef0d655911399a8bd4a3f:

  Linux 3.11-rc4 (2013-08-04 13:46:46 -0700)

are available in the git repository at:

  git://git.infradead.org/battery-2.6.git tags/for-v3.12

for you to fetch changes up to db15e6312efd537e2deb2cbad110c23f98704a3c:

  rx51_battery: Fix channel number when reading adc value (2013-08-30 17:49:15 
-0700)


Abhimanyu Kapur (1):
  power: reset: Add msm restart support

Andrea Adami (2):
  power supply: collie_battery: Convert to use dev_pm_ops
  power_supply: tosa_battery: Get rid of irq_to_gpio usage

Anton Vorontsov (1):
  bq24190_charger: Workaround SS definition problem on i386 builds

Dan Carpenter (1):
  ab8500-charger: We print an unintended error message

Jingoo Han (1):
  power_supply: Replace strict_strtol() with kstrtol()

Kevin Hilman (1):
  MAINTAINERS: drivers/power: add entry for SmartReflex AVS drivers

Libo Chen (1):
  max8925_power: Fix missing of_node_put

Loc Ho (1):
  power: Add APM X-Gene system reboot driver

Marek Belisko (3):
  rx51_battery: Replace hardcoded channels values.
  power: Add twl4030_madc battery driver.
  rx51_battery: Fix channel number when reading adc value

Mark A. Greer (1):
  bq24190_charger: Add support for TI BQ24190 Battery Charger

Paul Gortmaker (1):
  power_supply: Make goldfish_battery depend on GOLDFISH || COMPILE_TEST

Pawel Moll (1):
  vexpress-poweroff: Should depend on the required infrastructure

Peter Ujfalusi (1):
  twl4030-charger: Fix compiler warning with regulator_enable()

Zoran Markovic (1):
  power_supply: Prevent suspend until power supply events are processed

 .../bindings/power_supply/msm-poweroff.txt |   17 +
 MAINTAINERS|8 +
 drivers/power/Kconfig  |   15 +-
 drivers/power/Makefile |2 +
 drivers/power/ab8500_charger.c |1 +
 drivers/power/bq24190_charger.c| 1549 
 drivers/power/collie_battery.c |2 +-
 drivers/power/max8925_power.c  |1 +
 drivers/power/power_supply_core.c  |   38 +-
 drivers/power/power_supply_sysfs.c |2 +-
 drivers/power/reset/Kconfig|   15 +-
 drivers/power/reset/Makefile   |2 +
 drivers/power/reset/msm-poweroff.c |   73 +
 drivers/power/reset/xgene-reboot.c |  103 ++
 drivers/power/rx51_battery.c   |   14 +-
 drivers/power/tosa_battery.c   |2 +-
 drivers/power/twl4030_charger.c|7 +-
 drivers/power/twl4030_madc_battery.c   |  245 
 include/linux/power/bq24190_charger.h  |   16 +
 include/linux/power/twl4030_madc_battery.h |   39 +
 include/linux/power_supply.h   |3 +
 21 files changed, 2137 insertions(+), 17 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/power_supply/msm-poweroff.txt
 create mode 100644 drivers/power/bq24190_charger.c
 create mode 100644 drivers/power/reset/msm-poweroff.c
 create mode 100644 drivers/power/reset/xgene-reboot.c
 create mode 100644 drivers/power/twl4030_madc_battery.c
 create mode 100644 include/linux/power/bq24190_charger.h
 create mode 100644 include/linux/power/twl4030_madc_battery.h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[124/251] ARM: allow kuser helpers to be removed from the vector page

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Russell King 

[ Upstream commit f6f91b0d9fd971c630cef908dde8fe8795aefbf8 ]

Provide a kernel configuration option to allow the kernel user helpers
to be removed from the vector page, thereby preventing their use with
ROP (return orientated programming) attacks.  This option is only
visible for CPU architectures which natively support all the operations
which kernel user helpers would normally provide, and must be enabled
with caution.

Cc: 
Acked-by: Nicolas Pitre 
Signed-off-by: Russell King 
Signed-off-by: Steven Rostedt 
---
 arch/arm/kernel/entry-armv.S |3 +++
 arch/arm/kernel/traps.c  |   23 ++-
 arch/arm/mm/Kconfig  |   34 ++
 3 files changed, 51 insertions(+), 9 deletions(-)

diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 4c28aff..5492d72 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -795,6 +795,7 @@ ENDPROC(__switch_to)
.endr
.endm
 
+#ifdef CONFIG_KUSER_HELPERS
.align  5
.globl  __kuser_helper_start
 __kuser_helper_start:
@@ -981,6 +982,8 @@ __kuser_helper_version: @ 
0x0ffc
.globl  __kuser_helper_end
 __kuser_helper_end:
 
+#endif
+
  THUMB(.thumb  )
 
 /*
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 366aa93..1392beb 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -807,23 +807,32 @@ void __init trap_init(void)
return;
 }
 
-static void __init kuser_get_tls_init(unsigned long vectors)
+#ifdef CONFIG_KUSER_HELPERS
+static void __init kuser_init(void *vectors)
 {
+   extern char __kuser_helper_start[], __kuser_helper_end[];
+   int kuser_sz = __kuser_helper_end - __kuser_helper_start;
+
+   memcpy(vectors + 0x1000 - kuser_sz, __kuser_helper_start, kuser_sz);
+
/*
 * vectors + 0xfe0 = __kuser_get_tls
 * vectors + 0xfe8 = hardware TLS instruction at 0x0fe8
 */
if (tls_emu || has_tls_reg)
-   memcpy((void *)vectors + 0xfe0, (void *)vectors + 0xfe8, 4);
+   memcpy(vectors + 0xfe0, vectors + 0xfe8, 4);
+}
+#else
+static void __init kuser_init(void *vectors)
+{
 }
+#endif
 
 void __init early_trap_init(void *vectors_base)
 {
unsigned long vectors = (unsigned long)vectors_base;
extern char __stubs_start[], __stubs_end[];
extern char __vectors_start[], __vectors_end[];
-   extern char __kuser_helper_start[], __kuser_helper_end[];
-   int kuser_sz = __kuser_helper_end - __kuser_helper_start;
unsigned i;
 
vectors_page = vectors_base;
@@ -844,12 +853,8 @@ void __init early_trap_init(void *vectors_base)
 */
memcpy((void *)vectors, __vectors_start, __vectors_end - 
__vectors_start);
memcpy((void *)vectors + 0x1000, __stubs_start, __stubs_end - 
__stubs_start);
-   memcpy((void *)vectors + 0x1000 - kuser_sz, __kuser_helper_start, 
kuser_sz);
 
-   /*
-* Do processor specific fixups for the kuser helpers
-*/
-   kuser_get_tls_init(vectors);
+   kuser_init(vectors_base);
 
/*
 * Copy signal return handlers into the vector page, and
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 101b968..8d194df 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -400,24 +400,28 @@ config CPU_32v3
select TLS_REG_EMUL if SMP || !MMU
select NEEDS_SYSCALL_FOR_CMPXCHG if SMP
select CPU_USE_DOMAINS if MMU
+   select NEED_KUSER_HELPERS
 
 config CPU_32v4
bool
select TLS_REG_EMUL if SMP || !MMU
select NEEDS_SYSCALL_FOR_CMPXCHG if SMP
select CPU_USE_DOMAINS if MMU
+   select NEED_KUSER_HELPERS
 
 config CPU_32v4T
bool
select TLS_REG_EMUL if SMP || !MMU
select NEEDS_SYSCALL_FOR_CMPXCHG if SMP
select CPU_USE_DOMAINS if MMU
+   select NEED_KUSER_HELPERS
 
 config CPU_32v5
bool
select TLS_REG_EMUL if SMP || !MMU
select NEEDS_SYSCALL_FOR_CMPXCHG if SMP
select CPU_USE_DOMAINS if MMU
+   select NEED_KUSER_HELPERS
 
 config CPU_32v6
bool
@@ -735,6 +739,7 @@ config CPU_BPREDICT_DISABLE
 
 config TLS_REG_EMUL
bool
+   select NEED_KUSER_HELPERS
help
  An SMP system using a pre-ARMv6 processor (there are apparently
  a few prototypes like that in existence) and therefore access to
@@ -742,11 +747,40 @@ config TLS_REG_EMUL
 
 config NEEDS_SYSCALL_FOR_CMPXCHG
bool
+   select NEED_KUSER_HELPERS
help
  SMP on a pre-ARMv6 processor?  Well OK then.
  Forget about fast user space cmpxchg support.
  It is just not possible.
 
+config NEED_KUSER_HELPERS
+   bool
+
+config KUSER_HELPERS
+   bool "Enable kuser helpers in vector page" if 

[121/251] ARM: move vector stubs

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Russell King 

[ Upstream commit 19accfd373847ac3d10623c5d20f948846299741 ]

Move the machine vector stubs into the page above the vector page,
which we can prevent from being visible to userspace.  Also move
the reset stub, and place the swi vector at a location that the
'ldr' can get to it.

This hides pointers into the kernel which could give valuable
information to attackers, and reduces the number of exploitable
instructions at a fixed address.

Cc: 
Acked-by: Nicolas Pitre 
Signed-off-by: Russell King 
Signed-off-by: Steven Rostedt 
---
 arch/arm/Kconfig |3 ++-
 arch/arm/kernel/entry-armv.S |   50 --
 arch/arm/kernel/traps.c  |4 ++--
 arch/arm/mm/mmu.c|   10 -
 4 files changed, 37 insertions(+), 30 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 589bdba..ca5e665 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -183,7 +183,8 @@ config VECTORS_BASE
default DRAM_BASE if REMAP_VECTORS_TO_RAM
default 0x
help
- The base address of exception vectors.
+ The base address of exception vectors.  This must be two pages
+ in size.
 
 config ARM_PATCH_PHYS_VIRT
bool "Patch physical to virtual translations at runtime" if EMBEDDED
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 9c80c1d..a4af8e8 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -986,9 +986,9 @@ __kuser_helper_end:
 /*
  * Vector stubs.
  *
- * This code is copied to 0x0200 so we can use branches in the
- * vectors, rather than ldr's.  Note that this code must not
- * exceed 0x300 bytes.
+ * This code is copied to 0x1000 so we can use branches in the
+ * vectors, rather than ldr's.  Note that this code must not exceed
+ * a page size.
  *
  * Common stub entry macro:
  *   Enter in IRQ mode, spsr = SVC/USR CPSR, lr = SVC/USR PC
@@ -1037,6 +1037,15 @@ ENDPROC(vector_\name)
 
.globl  __stubs_start
 __stubs_start:
+   @ This must be the first word
+   .word   vector_swi
+
+vector_rst:
+ ARM(  swi SYS_ERROR0  )
+ THUMB(svc #0  )
+ THUMB(nop )
+   b   vector_und
+
 /*
  * Interrupt dispatcher
  */
@@ -1131,6 +1140,16 @@ __stubs_start:
.align  5
 
 /*=
+ * Address exception handler
+ *-
+ * These aren't too critical.
+ * (they're not supposed to happen, and won't happen in 32-bit data mode).
+ */
+
+vector_addrexcptn:
+   b   vector_addrexcptn
+
+/*=
  * Undefined FIQs
  *-
  * Enter in FIQ mode, spsr = ANY CPSR, lr = ANY PC
@@ -1143,35 +1162,14 @@ __stubs_start:
 vector_fiq:
subspc, lr, #4
 
-/*=
- * Address exception handler
- *-
- * These aren't too critical.
- * (they're not supposed to happen, and won't happen in 32-bit data mode).
- */
-
-vector_addrexcptn:
-   b   vector_addrexcptn
-
-/*
- * We group all the following data together to optimise
- * for CPUs with separate I & D caches.
- */
-   .align  5
-
-.LCvswi:
-   .word   vector_swi
-
.globl  __stubs_end
 __stubs_end:
 
-   .equstubs_offset, __vectors_start + 0x200 - __stubs_start
+   .equstubs_offset, __vectors_start + 0x1000 - __stubs_start
 
.globl  __vectors_start
 __vectors_start:
- ARM(  swi SYS_ERROR0  )
- THUMB(svc #0  )
- THUMB(nop )
+   W(b)vector_rst + stubs_offset
W(b)vector_und + stubs_offset
W(ldr)  pc, .LCvswi + stubs_offset
W(b)vector_pabt + stubs_offset
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index a4f84b0..366aa93 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -843,7 +843,7 @@ void __init early_trap_init(void *vectors_base)
 * are visible to the instruction stream.
 */
memcpy((void *)vectors, __vectors_start, __vectors_end - 
__vectors_start);
-   memcpy((void *)vectors + 0x200, __stubs_start, __stubs_end - 
__stubs_start);
+   memcpy((void *)vectors + 0x1000, __stubs_start, __stubs_end - 
__stubs_start);
memcpy((void *)vectors + 0x1000 - kuser_sz, __kuser_helper_start, 
kuser_sz);
 
/*
@@ -858,6 +858,6 @@ void __init early_trap_init(void *vectors_base)
memcpy((void *)(vectors + KERN_SIGRETURN_CODE - CONFIG_VECTORS_BASE),
 

[123/251] ARM: update FIQ support for relocation of vectors

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Russell King 

[ Upstream commit e39e3f3ebfef03450cf7bfa7a974a8c61f7980c8 ]

FIQ should no longer copy the FIQ code into the user visible vector
page.  Instead, it should use the hidden page.  This change makes
that happen.

Cc: 
Acked-by: Nicolas Pitre 
Signed-off-by: Russell King 
Signed-off-by: Steven Rostedt 
---
 arch/arm/kernel/entry-armv.S |3 +++
 arch/arm/kernel/fiq.c|   19 ++-
 2 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index c19779f..4c28aff 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -1162,6 +1162,9 @@ vector_addrexcptn:
 vector_fiq:
subspc, lr, #4
 
+   .globl  vector_fiq_offset
+   .equvector_fiq_offset, vector_fiq
+
.section .vectors, "ax", %progbits
 __vectors_start:
W(b)vector_rst
diff --git a/arch/arm/kernel/fiq.c b/arch/arm/kernel/fiq.c
index 2adda11..25442f4 100644
--- a/arch/arm/kernel/fiq.c
+++ b/arch/arm/kernel/fiq.c
@@ -47,6 +47,11 @@
 #include 
 #include 
 
+#define FIQ_OFFSET ({  \
+   extern void *vector_fiq_offset; \
+   (unsigned)_fiq_offset;   \
+   })
+
 static unsigned long no_fiq_insn;
 
 /* Default reacquire function
@@ -80,13 +85,16 @@ int show_fiq_list(struct seq_file *p, int prec)
 void set_fiq_handler(void *start, unsigned int length)
 {
 #if defined(CONFIG_CPU_USE_DOMAINS)
-   memcpy((void *)0x001c, start, length);
+   void *base = (void *)0x;
 #else
-   memcpy(vectors_page + 0x1c, start, length);
+   void *base = vectors_page;
 #endif
-   flush_icache_range(0x001c, 0x001c + length);
+   unsigned offset = FIQ_OFFSET;
+
+   memcpy(base + offset, start, length);
+   flush_icache_range(0x + offset, 0x + offset + length);
if (!vectors_high())
-   flush_icache_range(0x1c, 0x1c + length);
+   flush_icache_range(offset, offset + length);
 }
 
 int claim_fiq(struct fiq_handler *f)
@@ -144,6 +152,7 @@ EXPORT_SYMBOL(disable_fiq);
 
 void __init init_FIQ(int start)
 {
-   no_fiq_insn = *(unsigned long *)0x001c;
+   unsigned offset = FIQ_OFFSET;
+   no_fiq_insn = *(unsigned long *)(0x + offset);
fiq_start = start;
 }
-- 
1.7.10.4


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

[120/251] ARM: poison memory between kuser helpers

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Russell King 

[ Upstream commit 5b43e7a383d69381ffe53423e46dd0fafae07da3 ]

Poison the memory between each kuser helper.  This ensures that any
branch between the kuser helpers will be appropriately trapped.

Cc: 
Acked-by: Nicolas Pitre 
Signed-off-by: Russell King 
Signed-off-by: Steven Rostedt 
---
 arch/arm/kernel/entry-armv.S |   25 -
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 0f82098..9c80c1d 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -784,6 +784,17 @@ ENDPROC(__switch_to)
 #endif
.endm
 
+   .macro  kuser_pad, sym, size
+   .if (. - \sym) & 3
+   .rept   4 - (. - \sym) & 3
+   .byte   0
+   .endr
+   .endif
+   .rept   (\size - (. - \sym)) / 4
+   .word   0xe7fddef1
+   .endr
+   .endm
+
.align  5
.globl  __kuser_helper_start
 __kuser_helper_start:
@@ -874,18 +885,13 @@ kuser_cmpxchg64_fixup:
 #error "incoherent kernel configuration"
 #endif
 
-   /* pad to next slot */
-   .rept   (16 - (. - __kuser_cmpxchg64)/4)
-   .word   0
-   .endr
-
-   .align  5
+   kuser_pad __kuser_cmpxchg64, 64
 
 __kuser_memory_barrier:@ 0x0fa0
smp_dmb arm
usr_ret lr
 
-   .align  5
+   kuser_pad __kuser_memory_barrier, 32
 
 __kuser_cmpxchg:   @ 0x0fc0
 
@@ -958,13 +964,14 @@ kuser_cmpxchg32_fixup:
 
 #endif
 
-   .align  5
+   kuser_pad __kuser_cmpxchg, 32
 
 __kuser_get_tls:   @ 0x0fe0
ldr r0, [pc, #(16 - 8)] @ read TLS, set in kuser_get_tls_init
usr_ret lr
mrc p15, 0, r0, c13, c0, 3  @ 0x0fe8 hardware TLS code
-   .rep4
+   kuser_pad __kuser_get_tls, 16
+   .rep3
.word   0   @ 0x0ff0 software TLS value, then
.endr   @ pad up to __kuser_helper_version
 
-- 
1.7.10.4


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

[119/251] ARM: poison the vectors page

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Russell King 

[ Upstream commit f928d4f2a86f46b030fa0850385b4391fc2b5918 ]

Fill the empty regions of the vectors page with an exception generating
instruction.  This ensures that any inappropriate branch to the vector
page is appropriately trapped, rather than just encountering some code
to execute.  (The vectors page was filled with zero before, which
corresponds with the "andeq r0, r0, r0" instruction - a no-op.)

Cc: 
Acked-by Nicolas Pitre 
Signed-off-by: Russell King 
Signed-off-by: Steven Rostedt 
---
 arch/arm/kernel/traps.c |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index b0179b8..a4f84b0 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -824,10 +824,20 @@ void __init early_trap_init(void *vectors_base)
extern char __vectors_start[], __vectors_end[];
extern char __kuser_helper_start[], __kuser_helper_end[];
int kuser_sz = __kuser_helper_end - __kuser_helper_start;
+   unsigned i;
 
vectors_page = vectors_base;
 
/*
+* Poison the vectors page with an undefined instruction.  This
+* instruction is chosen to be undefined for both ARM and Thumb
+* ISAs.  The Thumb version is an undefined instruction with a
+* branch back to the undefined instruction.
+*/
+   for (i = 0; i < PAGE_SIZE / sizeof(u32); i++)
+   ((u32 *)vectors_base)[i] = 0xe7fddef1;
+
+   /*
 * Copy the vectors, stubs and kuser helpers (in entry-armv.S)
 * into the vector page, mapped at 0x, and ensure these
 * are visible to the instruction stream.
-- 
1.7.10.4


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

[114/251] USB: serial: ftdi_sio: add more RT Systems ftdi devices

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: "Rick Farina (Zero_Chaos)" 

[ Upstream commit fed1f1ed90bce42ea010e2904cbc04e7b8304940 ]

RT Systems makes many usb serial cables based on the ftdi_sio driver for
programming various amateur radios.  This patch is a full listing of
their current product offerings and should allow these cables to all
be recognized.

Signed-off-by: Rick Farina (Zero_Chaos) 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Steven Rostedt 
---
 drivers/usb/serial/ftdi_sio.c |   31 ---
 drivers/usb/serial/ftdi_sio_ids.h |   34 +-
 2 files changed, 57 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 5c3e249..710302ea 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -741,9 +741,34 @@ static struct usb_device_id id_table_combined [] = {
{ USB_DEVICE(FTDI_VID, FTDI_NDI_AURORA_SCU_PID),
.driver_info = (kernel_ulong_t)_NDI_device_quirk },
{ USB_DEVICE(TELLDUS_VID, TELLDUS_TELLSTICK_PID) },
-   { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_SERIAL_VX7_PID) },
-   { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_CT29B_PID) },
-   { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_RTS01_PID) },
+   { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_S03_PID) },
+   { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_59_PID) },
+   { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_57A_PID) },
+   { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_57B_PID) },
+   { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_29A_PID) },
+   { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_29B_PID) },
+   { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_29F_PID) },
+   { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_62B_PID) },
+   { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_S01_PID) },
+   { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_63_PID) },
+   { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_29C_PID) },
+   { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_81B_PID) },
+   { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_82B_PID) },
+   { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_K5D_PID) },
+   { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_K4Y_PID) },
+   { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_K5G_PID) },
+   { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_S05_PID) },
+   { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_60_PID) },
+   { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_61_PID) },
+   { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_62_PID) },
+   { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_63B_PID) },
+   { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_64_PID) },
+   { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_65_PID) },
+   { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_92_PID) },
+   { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_92D_PID) },
+   { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_W5R_PID) },
+   { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_A5R_PID) },
+   { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_PW1_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_MAXSTREAM_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_PHI_FISCO_PID) },
{ USB_DEVICE(TML_VID, TML_USB_SERIAL_PID) },
diff --git a/drivers/usb/serial/ftdi_sio_ids.h 
b/drivers/usb/serial/ftdi_sio_ids.h
index 1e4bff5..b98e44a 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -808,11 +808,35 @@
 /*
  * RT Systems programming cables for various ham radios
  */
-#define RTSYSTEMS_VID  0x2100  /* Vendor ID */
-#define RTSYSTEMS_SERIAL_VX7_PID   0x9e52  /* Serial converter for VX-7 
Radios using FT232RL */
-#define RTSYSTEMS_CT29B_PID0x9e54  /* CT29B Radio Cable */
-#define RTSYSTEMS_RTS01_PID0x9e57  /* USB-RTS01 Radio Cable */
-
+#define RTSYSTEMS_VID  0x2100  /* Vendor ID */
+#define RTSYSTEMS_USB_S03_PID  0x9001  /* RTS-03 USB to Serial Adapter */
+#define RTSYSTEMS_USB_59_PID   0x9e50  /* USB-59 USB to 8 pin plug */
+#define RTSYSTEMS_USB_57A_PID  0x9e51  /* USB-57A USB to 4pin 3.5mm plug */
+#define RTSYSTEMS_USB_57B_PID  0x9e52  /* USB-57B USB to extended 4pin 3.5mm 
plug */
+#define RTSYSTEMS_USB_29A_PID  0x9e53  /* USB-29A USB to 3.5mm stereo plug */
+#define RTSYSTEMS_USB_29B_PID  0x9e54  /* USB-29B USB to 6 pin mini din */
+#define RTSYSTEMS_USB_29F_PID  0x9e55  /* USB-29F USB to 6 pin modular plug */
+#define RTSYSTEMS_USB_62B_PID  0x9e56  /* USB-62B USB to 8 pin mini din plug*/
+#define RTSYSTEMS_USB_S01_PID  0x9e57  /* USB-RTS01 USB to 3.5 mm stereo plug*/
+#define RTSYSTEMS_USB_63_PID   0x9e58  /* USB-63 USB to 9 pin female*/
+#define RTSYSTEMS_USB_29C_PID  0x9e59  /* USB-29C USB to 4 pin modular plug*/
+#define RTSYSTEMS_USB_81B_PID  0x9e5A  /* USB-81 USB to 8 pin mini din plug*/
+#define RTSYSTEMS_USB_82B_PID  0x9e5B  /* USB-82 USB to 2.5 mm stereo plug*/
+#define RTSYSTEMS_USB_K5D_PID  0x9e5C  /* USB-K5D USB to 8 pin 

[089/251] usb: dwc3: fix wrong bit mask in dwc3_event_type

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Huang Rui 

[ Upstream commit 1974d494dea05ea227cb42f5e918828801e237aa ]

Per dwc3 2.50a spec, the is_devspec bit is used to distinguish the
Device Endpoint-Specific Event or Device-Specific Event (DEVT). If the
bit is 1, the event is represented Device-Specific Event, then use
[7:1] bits as Device Specific Event to marked the type. It has 7 bits,
and we can see the reserved8_31 variable name which means from 8 to 31
bits marked reserved, actually there are 24 bits not 25 bits between
that. And 1 + 7 + 24 = 32, the event size is 4 byes.

So in dwc3_event_type, the bit mask should be:
is_devspec  [0] 1  bit
type[7:1]   7  bits
reserved8_31[31:8]  24 bits

This patch should be backported to kernels as old as 3.2, that contain
the commit 72246da40f3719af3bfd104a2365b32537c27d83 "usb: Introduce
DesignWare USB3 DRD Driver".

Cc: 
Signed-off-by: Huang Rui 
Signed-off-by: Felipe Balbi 
Signed-off-by: Steven Rostedt 
---
 drivers/usb/dwc3/core.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 151eca8..06dffc8 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -728,8 +728,8 @@ struct dwc3 {
 
 struct dwc3_event_type {
u32 is_devspec:1;
-   u32 type:6;
-   u32 reserved8_31:25;
+   u32 type:7;
+   u32 reserved8_31:24;
 } __packed;
 
 #define DWC3_DEPEVT_XFERCOMPLETE   0x01
-- 
1.7.10.4


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

[090/251] usb: dwc3: gadget: dont prevent gadget from being probed if we fail

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Felipe Balbi 

[ Upstream commit cdcedd6981194e511cc206887db661d016069d68 ]

In case we fail our ->udc_start() callback, we
should be ready to accept another modprobe following
the failed one.

We had forgotten to clear dwc->gadget_driver back
to NULL and, because of that, we were preventing
gadget driver modprobe from being retried.

Cc: 
Signed-off-by: Felipe Balbi 
Signed-off-by: Steven Rostedt 
---
 drivers/usb/dwc3/gadget.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 8212dbb..234305a 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1558,6 +1558,7 @@ err1:
__dwc3_gadget_ep_disable(dwc->eps[0]);
 
 err0:
+   dwc->gadget_driver = NULL;
spin_unlock_irqrestore(>lock, flags);
 
return ret;
-- 
1.7.10.4


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

[117/251] radeon kms: do not flush uninitialized hotplug work

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Sergey Senozhatsky 

[ Upstream commit a01c34f72e7cd2624570818f579b5ab464f93de2 ]

Fix a warning from lockdep caused by calling flush_work() for
uninitialized hotplug work. Initialize hotplug_work, audio_work
and reset_work upon successful radeon_irq_kms_init() completion
and thus perform hotplug flush_work only when rdev->irq.installed
is true.

[4.790019] [drm] Loading CEDAR Microcode
[4.790943] r600_cp: Failed to load firmware "radeon/CEDAR_smc.bin"
[4.791152] [drm:evergreen_startup] *ERROR* Failed to load firmware!
[4.791330] radeon :01:00.0: disabling GPU acceleration

[4.792633] INFO: trying to register non-static key.
[4.792792] the code is fine but needs lockdep annotation.
[4.792953] turning off the locking correctness validator.

[4.793114] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 
3.11.0-rc0-dbg-10676-gfe56456-dirty #1816
[4.793314] Hardware name: Acer Aspire 5741G/Aspire 5741G
, BIOS V1.20 02/08/2011
[4.793507]  821fd810 8801530b9a18 8160434e 
0002
[4.794155]  8801530b9ad8 810b8404 8801530b0798 
8801530b
[4.794789]  8801530b9b00 0046 04c0 

[4.795418] Call Trace:
[4.795573]  [] dump_stack+0x4e/0x82
[4.795731]  [] __lock_acquire+0x1a64/0x1d30
[4.795893]  [] ? dev_vprintk_emit+0x50/0x60
[4.796034]  [] lock_acquire+0xa4/0x200
[4.796216]  [] ? flush_work+0x5/0x280
[4.796375]  [] flush_work+0x3d/0x280
[4.796520]  [] ? flush_work+0x5/0x280
[4.796682]  [] ? trace_hardirqs_on_caller+0xfd/0x1c0
[4.796862]  [] ? delay_tsc+0x95/0xf0
[4.797024]  [] radeon_irq_kms_fini+0x2b/0x70
[4.797186]  [] evergreen_init+0x2a9/0x2e0
[4.797347]  [] radeon_device_init+0x5ef/0x700
[4.797511]  [] ? pci_find_capability+0x47/0x50
[4.797672]  [] radeon_driver_load_kms+0x8d/0x150
[4.797843]  [] drm_get_pci_dev+0x166/0x280
[4.798007]  [] ? kfree+0xf5/0x2e0
[4.798168]  [] ? radeon_pci_probe+0x98/0xd0
[4.798329]  [] radeon_pci_probe+0xaa/0xd0
[4.798489]  [] pci_device_probe+0x84/0xe0
[4.798644]  [] driver_probe_device+0x76/0x240
[4.798805]  [] __driver_attach+0x93/0xa0
[4.798948]  [] ? __device_attach+0x40/0x40
[4.799126]  [] bus_for_each_dev+0x6b/0xb0
[4.799272]  [] driver_attach+0x1e/0x20
[4.799434]  [] bus_add_driver+0x1f0/0x280
[4.799596]  [] driver_register+0x74/0x150
[4.799758]  [] __pci_register_driver+0x5d/0x60
[4.799936]  [] ? ttm_init+0x67/0x67
[4.800081]  [] drm_pci_init+0x115/0x130
[4.800243]  [] ? ttm_init+0x67/0x67
[4.800405]  [] radeon_init+0x9c/0xba
[4.800586]  [] do_one_initcall+0xfa/0x150
[4.800746]  [] ? parse_args+0x120/0x330
[4.800909]  [] kernel_init_freeable+0x111/0x191
[4.801052]  [] ? do_early_param+0x88/0x88
[4.801233]  [] ? rest_init+0x140/0x140
[4.801393]  [] kernel_init+0xe/0x180
[4.801556]  [] ret_from_fork+0x7c/0xb0
[4.801718]  [] ? rest_init+0x140/0x140

Signed-off-by: Sergey Senozhatsky 
Signed-off-by: Alex Deucher 
Cc: sta...@vger.kernel.org
Signed-off-by: Steven Rostedt 
---
 drivers/gpu/drm/radeon/radeon_irq_kms.c |9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c 
b/drivers/gpu/drm/radeon/radeon_irq_kms.c
index 443bd49..4bc6be5 100644
--- a/drivers/gpu/drm/radeon/radeon_irq_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c
@@ -243,9 +243,6 @@ int radeon_irq_kms_init(struct radeon_device *rdev)
 {
int r = 0;
 
-   INIT_WORK(>hotplug_work, radeon_hotplug_work_func);
-   INIT_WORK(>audio_work, r600_audio_update_hdmi);
-
spin_lock_init(>irq.lock);
r = drm_vblank_init(rdev->ddev, rdev->num_crtc);
if (r) {
@@ -267,6 +264,10 @@ int radeon_irq_kms_init(struct radeon_device *rdev)
rdev->irq.installed = false;
return r;
}
+
+   INIT_WORK(>hotplug_work, radeon_hotplug_work_func);
+   INIT_WORK(>audio_work, r600_audio_update_hdmi);
+
DRM_INFO("radeon: irq initialized.\n");
return 0;
 }
@@ -286,8 +287,8 @@ void radeon_irq_kms_fini(struct radeon_device *rdev)
rdev->irq.installed = false;
if (rdev->msi_enabled)
pci_disable_msi(rdev->pdev);
+   flush_work_sync(>hotplug_work);
}
-   flush_work_sync(>hotplug_work);
 }
 
 /**
-- 
1.7.10.4


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

[115/251] livelock avoidance in sget()

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Al Viro 

[ Upstream commit acfec9a5a892f98461f52ed5770de99a3e571ae2 ]

Eric Sandeen has found a nasty livelock in sget() - take a mount(2) about
to fail.  The superblock is on ->fs_supers, ->s_umount is held exclusive,
->s_active is 1.  Along comes two more processes, trying to mount the same
thing; sget() in each is picking that superblock, bumping ->s_count and
trying to grab ->s_umount.  ->s_active is 3 now.  Original mount(2)
finally gets to deactivate_locked_super() on failure; ->s_active is 2,
superblock is still ->fs_supers because shutdown will *not* happen until
->s_active hits 0.  ->s_umount is dropped and now we have two processes
chasing each other:
s_active = 2, A acquired ->s_umount, B blocked
A sees that the damn thing is stillborn, does deactivate_locked_super()
s_active = 1, A drops ->s_umount, B gets it
A restarts the search and finds the same superblock.  And bumps it ->s_active.
s_active = 2, B holds ->s_umount, A blocked on trying to get it
... and we are in the earlier situation with A and B switched places.

The root cause, of course, is that ->s_active should not grow until we'd
got MS_BORN.  Then failing ->mount() will have deactivate_locked_super()
shut the damn thing down.  Fortunately, it's easy to do - the key point
is that grab_super() is called only for superblocks currently on ->fs_supers,
so it can bump ->s_count and grab ->s_umount first, then check MS_BORN and
bump ->s_active; we must never increment ->s_count for superblocks past
->kill_sb(), but grab_super() is never called for those.

The bug is pretty old; we would've caught it by now, if not for accidental
exclusion between sget() for block filesystems; the things like cgroup or
e.g. mtd-based filesystems don't have anything of that sort, so they get
bitten.  The right way to deal with that is obviously to fix sget()...

Signed-off-by: Al Viro 
Signed-off-by: Steven Rostedt 
---
 fs/super.c |   25 ++---
 1 file changed, 10 insertions(+), 15 deletions(-)

diff --git a/fs/super.c b/fs/super.c
index 0902cfa..7b6e4e5 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -349,19 +349,19 @@ EXPORT_SYMBOL(deactivate_super);
  * and want to turn it into a full-blown active reference.  grab_super()
  * is called with sb_lock held and drops it.  Returns 1 in case of
  * success, 0 if we had failed (superblock contents was already dead or
- * dying when grab_super() had been called).
+ * dying when grab_super() had been called).  Note that this is only
+ * called for superblocks not in rundown mode (== ones still on ->fs_supers
+ * of their type), so increment of ->s_count is OK here.
  */
 static int grab_super(struct super_block *s) __releases(sb_lock)
 {
-   if (atomic_inc_not_zero(>s_active)) {
-   spin_unlock(_lock);
-   return 1;
-   }
-   /* it's going away */
s->s_count++;
spin_unlock(_lock);
-   /* wait for it to die */
down_write(>s_umount);
+   if ((s->s_flags & MS_BORN) && atomic_inc_not_zero(>s_active)) {
+   put_super(s);
+   return 1;
+   }
up_write(>s_umount);
put_super(s);
return 0;
@@ -493,11 +493,6 @@ retry:
destroy_super(s);
s = NULL;
}
-   down_write(>s_umount);
-   if (unlikely(!(old->s_flags & MS_BORN))) {
-   deactivate_locked_super(old);
-   goto retry;
-   }
return old;
}
}
@@ -691,10 +686,10 @@ restart:
if (hlist_unhashed(>s_instances))
continue;
if (sb->s_bdev == bdev) {
-   if (grab_super(sb)) /* drops sb_lock */
-   return sb;
-   else
+   if (!grab_super(sb))
goto restart;
+   up_write(>s_umount);
+   return sb;
}
}
spin_unlock(_lock);
-- 
1.7.10.4


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

[118/251] x86: Fix /proc/mtrr with base/size more than 44bits

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Yinghai Lu 

[ Upstream commit d5c78673b1b28467354c2c30c3d4f003666ff385 ]

On one sytem that mtrr range is more then 44bits, in dmesg we have
[0.00] MTRR default type: write-back
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-D write-through
[0.00]   E-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 [8000-] mask 3FFF8000 uncachable
[0.00]   1 [3800-38FF] mask 3F00 uncachable
[0.00]   2 [9900-99FF] mask 3F00 write-through
[0.00]   3 [9A00-9AFF] mask 3F00 write-through
[0.00]   4 [381FFA00-381FFBFF] mask 3E00 write-through
[0.00]   5 [381FFC00-381FFC0F] mask 3FF0 write-through
[0.00]   6 [AD00-ADFF] mask 3F00 write-through
[0.00]   7 [BD00-BDFF] mask 3F00 write-through
[0.00]   8 disabled
[0.00]   9 disabled

but /proc/mtrr report wrong:
reg00: base=0x08000 ( 2048MB), size= 2048MB, count=1: uncachable
reg01: base=0x800 (8388608MB), size=1048576MB, count=1: uncachable
reg02: base=0x09900 ( 2448MB), size=   16MB, count=1: write-through
reg03: base=0x09a00 ( 2464MB), size=   16MB, count=1: write-through
reg04: base=0x81ffa00 (8519584MB), size=   32MB, count=1: write-through
reg05: base=0x81ffc00 (8519616MB), size=1MB, count=1: write-through
reg06: base=0x0ad00 ( 2768MB), size=   16MB, count=1: write-through
reg07: base=0x0bd00 ( 3024MB), size=   16MB, count=1: write-through
reg08: base=0x09b00 ( 2480MB), size=   16MB, count=1: write-combining

so bit 44 and bit 45 get cut off.

We have problems in arch/x86/kernel/cpu/mtrr/generic.c::generic_get_mtrr().
1. for base, we miss cast base_lo to 64bit before shifting.
Fix that by adding u64 casting.

2. for size, it only can handle 44 bits aka 32bits + page_shift
Fix that with 64bit mask instead of 32bit mask_lo, then range could be
more than 44bits.
At the same time, we need to update size_or_mask for old cpus that does
support cpuid 0x8008 to get phys_addr. Need to set high 32bits
to all 1s, otherwise will not get correct size for them.

Also fix mtrr_add_page: it should check base and (base + size - 1)
instead of base and size, as base and size could be small but
base + size could bigger enough to be out of boundary. We can
use boot_cpu_data.x86_phys_bits directly to avoid size_or_mask.

So When are we going to have size more than 44bits? that is 16TiB.

after patch we have right ouput:
reg00: base=0x08000 ( 2048MB), size= 2048MB, count=1: uncachable
reg01: base=0x3800 (58720256MB), size=1048576MB, count=1: uncachable
reg02: base=0x09900 ( 2448MB), size=   16MB, count=1: write-through
reg03: base=0x09a00 ( 2464MB), size=   16MB, count=1: write-through
reg04: base=0x381ffa00 (58851232MB), size=   32MB, count=1: write-through
reg05: base=0x381ffc00 (58851264MB), size=1MB, count=1: write-through
reg06: base=0x0ad00 ( 2768MB), size=   16MB, count=1: write-through
reg07: base=0x0bd00 ( 3024MB), size=   16MB, count=1: write-through
reg08: base=0x09b00 ( 2480MB), size=   16MB, count=1: write-combining

-v2: simply checking in mtrr_add_page according to hpa.

[ hpa: This probably wants to go into -stable only after having sat in
  mainline for a bit.  It is not a regression. ]

Signed-off-by: Yinghai Lu 
Link: 
http://lkml.kernel.org/r/1371162815-29931-1-git-send-email-ying...@kernel.org
Cc: 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Steven Rostedt 
---
 arch/x86/kernel/cpu/mtrr/generic.c |   21 +++--
 arch/x86/kernel/cpu/mtrr/main.c|   16 +---
 2 files changed, 20 insertions(+), 17 deletions(-)

diff --git a/arch/x86/kernel/cpu/mtrr/generic.c 
b/arch/x86/kernel/cpu/mtrr/generic.c
index e9fe907..5ac2152 100644
--- a/arch/x86/kernel/cpu/mtrr/generic.c
+++ b/arch/x86/kernel/cpu/mtrr/generic.c
@@ -510,8 +510,9 @@ generic_get_free_region(unsigned long base, unsigned long 
size, int replace_reg)
 static void generic_get_mtrr(unsigned int reg, unsigned long *base,
 unsigned long *size, mtrr_type *type)
 {
-   unsigned int mask_lo, mask_hi, base_lo, base_hi;
-   unsigned int tmp, hi;
+   u32 mask_lo, mask_hi, base_lo, base_hi;
+   unsigned int hi;
+   u64 tmp, mask;
 
/*
 * get_mtrr doesn't need to update mtrr_state, also it could be called
@@ -532,18 +533,18 @@ static void generic_get_mtrr(unsigned int reg, unsigned 
long *base,
rdmsr(MTRRphysBase_MSR(reg), base_lo, base_hi);
 
/* Work out the shifted address mask: */
-   tmp = mask_hi << (32 - PAGE_SHIFT) | 

[116/251] xen/evtchn: avoid a deadlock when unbinding an event channel

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: David Vrabel 

[ Upstream commit 179fbd5a45f0d4034cc6fd37b8d367a3b79663c4 ]

Unbinding an event channel (either with the ioctl or when the evtchn
device is closed) may deadlock because disable_irq() is called with
port_user_lock held which is also locked by the interrupt handler.

Think of the IOCTL_EVTCHN_UNBIND is being serviced, the routine has
just taken the lock, and an interrupt happens. The evtchn_interrupt
is invoked, tries to take the lock and spins forever.

A quick glance at the code shows that the spinlock is a local IRQ
variant. Unfortunately that does not help as "disable_irq() waits for
the interrupt handler on all CPUs to stop running.  If the irq occurs
on another VCPU, it tries to take port_user_lock and can't because
the unbind ioctl is holding it." (from David). Hence we cannot
depend on the said spinlock to protect us. We could make it a system
wide IRQ disable spinlock but there is a better way.

We can piggyback on the fact that the existence of the spinlock is
to make get_port_user() checks be up-to-date. And we can alter those
checks to not depend on the spin lock (as it's protected by u->bind_mutex
in the ioctl) and can remove the unnecessary locking (this is
IOCTL_EVTCHN_UNBIND) path.

In the interrupt handler we cannot use the mutex, but we do not
need it.

"The unbind disables the irq before making the port user stale, so when
you clear it you are guaranteed that the interrupt handler that might
use that port cannot be running." (from David).

Hence this patch removes the spinlock usage on the teardown path
and piggybacks on disable_irq happening before we muck with the
get_port_user() data. This ensures that the interrupt handler will
never run on stale data.

Signed-off-by: David Vrabel 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Steven Rostedt 
[v1: Expanded the commit description a bit]
---
 drivers/xen/evtchn.c |   21 ++---
 1 file changed, 2 insertions(+), 19 deletions(-)

diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c
index b1f60a0..8eb68c9 100644
--- a/drivers/xen/evtchn.c
+++ b/drivers/xen/evtchn.c
@@ -367,18 +367,12 @@ static long evtchn_ioctl(struct file *file,
if (unbind.port >= NR_EVENT_CHANNELS)
break;
 
-   spin_lock_irq(_user_lock);
-
rc = -ENOTCONN;
-   if (get_port_user(unbind.port) != u) {
-   spin_unlock_irq(_user_lock);
+   if (get_port_user(unbind.port) != u)
break;
-   }
 
disable_irq(irq_from_evtchn(unbind.port));
 
-   spin_unlock_irq(_user_lock);
-
evtchn_unbind_from_user(u, unbind.port);
 
rc = 0;
@@ -478,26 +472,15 @@ static int evtchn_release(struct inode *inode, struct 
file *filp)
int i;
struct per_user_data *u = filp->private_data;
 
-   spin_lock_irq(_user_lock);
-
-   free_page((unsigned long)u->ring);
-
for (i = 0; i < NR_EVENT_CHANNELS; i++) {
if (get_port_user(i) != u)
continue;
 
disable_irq(irq_from_evtchn(i));
-   }
-
-   spin_unlock_irq(_user_lock);
-
-   for (i = 0; i < NR_EVENT_CHANNELS; i++) {
-   if (get_port_user(i) != u)
-   continue;
-
evtchn_unbind_from_user(get_port_user(i), i);
}
 
+   free_page((unsigned long)u->ring);
kfree(u->name);
kfree(u);
 
-- 
1.7.10.4


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

[111/251] drm/radeon: improve dac adjust heuristics for legacy pdac

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Alex Deucher 

[ Upstream commit 03ed8cf9b28d886c64c7e705c7bb1a365fd8fb95 ]

Hopefully avoid more quirks in the future due to bogus
vbios dac data.

Signed-off-by: Alex Deucher 
Cc: sta...@vger.kernel.org
Signed-off-by: Steven Rostedt 
---
 drivers/gpu/drm/radeon/radeon_combios.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_combios.c 
b/drivers/gpu/drm/radeon/radeon_combios.c
index 16bd2a2..9a762f9 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -902,8 +902,10 @@ struct radeon_encoder_primary_dac 
*radeon_combios_get_primary_dac_info(struct
dac = RBIOS8(dac_info + 0x3) & 0xf;
p_dac->ps2_pdac_adj = (bg << 8) | (dac);
}
-   /* if the values are all zeros, use the table */
-   if (p_dac->ps2_pdac_adj)
+   /* if the values are zeros, use the table */
+   if ((dac == 0) || (bg == 0))
+   found = 0;
+   else
found = 1;
}
 
-- 
1.7.10.4


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

Re: [PATCH v3] gpio: interrupt consistency check for OF GPIO IRQs

[Joel Fernandes]

On 09/10/2013 04:23 PM, Javier Martinez Canillas wrote:
> On 09/10/2013 09:52 PM, Stephen Warren wrote:
>> On 09/10/2013 07:56 AM, Javier Martinez Canillas wrote:
>> ...
>>> The only thing that this patch tries to solve is when a driver expect to 
>>> request
>>> a IRQ and it doesn't care if is a real IRQ line from an interrupt 
>>> controller or
>>> a GPIO pin mapped as an IRQ.
>>
>> That can be solved in the interrupt chip driver. The fact the previous
>> attempt didn't work doesn't mean that it's impossible.
>>
> 
> Indeed. Unfortunately that patch-set got merged as a fix quite late on the -rc
> cycle so it was safer to just revert the patches instead of analyzing the
> regression and providing a fix.
> 
> If Linus is fond about taking a local fix for gpio-omap then we can try again
> as a RFC with a better test coverage than before (although the patches had
> several tested and acked-by but no one tested on OMAP1 until the patches were
> merged) getting some TI folks in the loop who have access to those ancient 
> OMAP1
> devices. That way we can repost as a patch just once we are definitely sure 
> that
> it won't cause a regression on any OMAP platform.
> 
>>> With board files we used to explicitly do the GPIO setup
>>> (gpio_{request,direction_input}) but with DT these board files are gone and 
>>> we
>>> need a way to setup a GPIO implicitly when is mapped as an IRQ.
>>
>> Well, that's just an example of hacking around something in a board file
>> that should have been fixed in the GPIO/IRQ controller.
>>
>>> That's the only use case that this patch covers.
>> ...
>>> Also, it would be great if we can find a temporary solution so we can 
>>> finally
>>> have ethernet working with DT on most OMAP2+ boards. Since I expect that 
>>> doing
>>> the mentioned change on gpiolib would take at least a couple of kernel 
>>> releases.
>>
>> Really? I thought this patch was error-checking to make sure that
>> different drivers didn't request a GPIO and an IRQ that are actually the
>> same signal. This patch shouldn't affect any functionality except in
>> cases where there's a bug in the DT (incorrect GPIO/IRQ passed to some
>> driver).
>>
> 
> Yes, it doesn't do any error-checking neither prevent a driver to request a 
> GPIO
> and an IRQ that are the same signal (as long as this is supported by the
> GPIO/IRQ controller and its driver). The only thing that Linus patch does is 
> to
> auto request a GPIO for pins that are mapped as IRQ in DT (i.e: 
> interrupt-parent
> = <>).
> 
> The name of the function introduced by Linus is
> of_gpiochip_interrupt_consistency_check() but probably a better name is
> of_gpiochip_autorequest_irq() or something like that.
> 
> A similar behavior could be obtained by let's say calling gpio_request() in
> irq_create_of_mapping() if you wanted to add the logic in the IRQ chip DT core
> instead of doing it in the GPIO chip DT core as Linus does with his patch.
> 
> That's why I don't understand why Linus patch could be an issue for drivers 
> that
> needs to request both the GPIO and the mapped IRQ.
> 
> If this is already supported then nothing will break. If the driver tries to
> request the GPIO twice because this is already made by the DT core then I 
> think
> is a bug in the driver and has to be fixed to support DT since there won't be
> any need to do this manually anymore.

Quick question- Wouldn't this mean that there have to be 2 code paths in the
driver then.. One for DT-case where gpio_request double request is prevented,
and one for non-DT case where you would do the gpio_request followed by
request_irq. I'm not sure if there are drivers today that use DT and need to
converted to prevent the double request? If there are, and such drivers are also
used on non-DT platform, then we would have to fork 2 different code paths while
requesting an IRQ for DT/non-DT in the driver..

Also this path kind of enforces that the driver author must be aware whether
driver is being used on DT or non-DT platform.. Linus mentioned enforcing of
semantics, this is also enforcing semantics no?

Looks like the correct fix for this as discussed in this thread should be to
associate the struct device with the GPIO request, remember it and use the info
during request_irq. This is provided that the old pattern of gpio_request and
request_irq is continued to be used and working. I know this is some time away
so I'm not too opinionated about it.

Regards,

-Joel




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

[113/251] drm/radeon/atom: initialize more atom interpretor elements to 0

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Alex Deucher 

[ Upstream commit 42a21826dc54583cdb79cc8477732e911ac9c376 ]

The ProcessAuxChannel table on some rv635 boards assumes
the divmul members are initialized to 0 otherwise we get
an invalid fb offset since it has a bad mask set when
setting the fb base.  While here initialize all the
atom interpretor elements to 0.

Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=60639

Signed-off-by: Alex Deucher 
Cc: sta...@vger.kernel.org
Signed-off-by: Steven Rostedt 
---
 drivers/gpu/drm/radeon/atom.c |5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
index 43672b6..daa1e34 100644
--- a/drivers/gpu/drm/radeon/atom.c
+++ b/drivers/gpu/drm/radeon/atom.c
@@ -1222,12 +1222,17 @@ int atom_execute_table(struct atom_context *ctx, int 
index, uint32_t * params)
int r;
 
mutex_lock(>mutex);
+   /* reset data block */
+   ctx->data_block = 0;
/* reset reg block */
ctx->reg_block = 0;
/* reset fb window */
ctx->fb_base = 0;
/* reset io mode */
ctx->io_mode = ATOM_IO_MM;
+   /* reset divmul */
+   ctx->divmul[0] = 0;
+   ctx->divmul[1] = 0;
r = atom_execute_table_locked(ctx, index, params);
mutex_unlock(>mutex);
return r;
-- 
1.7.10.4


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

[112/251] drm/i915: fix long-standing SNB regression in power consumption after resume v2

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Konstantin Khlebnikov 

[ Upstream commit 7dcd2677ea912573d9ed4bcd629b0023b2d11505 ]

This patch fixes regression in power consumtion of sandy bridge gpu, which
exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking that
it's extremely busy. After that it never reaches rc6 state.

Bug exists since kernel v3.6:

commit b4ae3f22d238617ca11610b29fde16cf8c0bc6e0
Author: Jesse Barnes 
Date:   Thu Jun 14 11:04:48 2012 -0700

drm/i915: load boot context at driver init time

For some reason RC6 is already enabled at the beginning of resuming process.
Following initliaztion breaks some internal state and confuses RPS engine.
This patch disables RC6 at the beginnig of resume and initialization.

I've rearranged initialization sequence, because intel_disable_gt_powersave()
needs initialized force_wake_get/put and some locks from the dev_priv.

Note: The culprit in the initialization sequence seems to be the write
to MBCTL added in the above mentioned commit. The first version of
this patch just held a forcewake reference across the clock gating
init functions, which seems to have been enought to gather quite a few
positive test reports. But since that smelled a bit like ad-hoc
duct-tape v2 now just disables rps/rc6 across the entire hw setup.

References: https://bugs.freedesktop.org/show_bug.cgi?id=54089
References: https://bugzilla.kernel.org/show_bug.cgi?id=58971
References: https://patchwork.kernel.org/patch/2827634/ (patch v1)
Signed-off-by: Konstantin Khlebnikov 
Cc: Daniel Vetter 
Cc: Chris Wilson 
Cc: Jesse Barnes 
Signed-off-by: Steven Rostedt 
[danvet: Add note about v1 vs. v2 of this patch and use standard
layout for the commit citation. Also add the tested-bys from v1 and a
cc: stable.]
Cc: sta...@vger.kernel.org (Note: tiny conflict due to the addition of
the backlight lock in 3.11)
Tested-by: Alexander Kaltsas  (v1)
Tested-by: rocko  (v1)
Tested-by: JohnMB  (v1)
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_dma.c |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 0969a7c..4c6e9dd 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1465,6 +1465,11 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
dev_priv->dev = dev;
dev_priv->info = info;
 
+   spin_lock_init(_priv->irq_lock);
+   spin_lock_init(_priv->error_lock);
+   spin_lock_init(_priv->rps_lock);
+   spin_lock_init(_priv->dpio_lock);
+
if (i915_get_bridge_dev(dev)) {
ret = -EIO;
goto free_priv;
@@ -1585,11 +1590,6 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
if (!IS_I945G(dev) && !IS_I945GM(dev))
pci_enable_msi(dev->pdev);
 
-   spin_lock_init(_priv->irq_lock);
-   spin_lock_init(_priv->error_lock);
-   spin_lock_init(_priv->rps_lock);
-   spin_lock_init(_priv->dpio_lock);
-
if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev))
dev_priv->num_pipe = 3;
else if (IS_MOBILE(dev) || !IS_GEN2(dev))
-- 
1.7.10.4


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

[237/251] jfs: fix readdir cookie incompatibility with NFSv4

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Dave Kleikamp 

[ Upstream commit 44512449c0ab368889dd13ae0031fba74ee7e1d2 ]

NFSv4 reserves readdir cookie values 0-2 for special entries (. and ..),
but jfs allows a value of 2 for a non-special entry. This incompatibility
can result in the nfs client reporting a readdir loop.

This patch doesn't change the value stored internally, but adds one to
the value exposed to the iterate method.

Signed-off-by: Dave Kleikamp 
Tested-by: Christian Kujau 
Signed-off-by: Steven Rostedt 
---
 fs/jfs/jfs_dtree.c |   31 +++
 1 file changed, 23 insertions(+), 8 deletions(-)

diff --git a/fs/jfs/jfs_dtree.c b/fs/jfs/jfs_dtree.c
index 9197a1b..9f7c758 100644
--- a/fs/jfs/jfs_dtree.c
+++ b/fs/jfs/jfs_dtree.c
@@ -3047,6 +3047,14 @@ int jfs_readdir(struct file *filp, void *dirent, 
filldir_t filldir)
 
dir_index = (u32) filp->f_pos;
 
+   /*
+* NFSv4 reserves cookies 1 and 2 for . and .. so the value
+* we return to the vfs is one greater than the one we use
+* internally.
+*/
+   if (dir_index)
+   dir_index--;
+
if (dir_index > 1) {
struct dir_table_slot dirtab_slot;
 
@@ -3086,7 +3094,7 @@ int jfs_readdir(struct file *filp, void *dirent, 
filldir_t filldir)
if (p->header.flag & BT_INTERNAL) {
jfs_err("jfs_readdir: bad index table");
DT_PUTPAGE(mp);
-   filp->f_pos = -1;
+   filp->f_pos = DIREND;
return 0;
}
} else {
@@ -3094,7 +3102,7 @@ int jfs_readdir(struct file *filp, void *dirent, 
filldir_t filldir)
/*
 * self "."
 */
-   filp->f_pos = 0;
+   filp->f_pos = 1;
if (filldir(dirent, ".", 1, 0, ip->i_ino,
DT_DIR))
return 0;
@@ -3102,7 +3110,7 @@ int jfs_readdir(struct file *filp, void *dirent, 
filldir_t filldir)
/*
 * parent ".."
 */
-   filp->f_pos = 1;
+   filp->f_pos = 2;
if (filldir(dirent, "..", 2, 1, PARENT(ip), DT_DIR))
return 0;
 
@@ -3123,24 +3131,25 @@ int jfs_readdir(struct file *filp, void *dirent, 
filldir_t filldir)
/*
 * Legacy filesystem - OS/2 & Linux JFS < 0.3.6
 *
-* pn = index = 0:  First entry "."
-* pn = 0; index = 1:   Second entry ".."
+* pn = 0; index = 1:   First entry "."
+* pn = 0; index = 2:   Second entry ".."
 * pn > 0:  Real entries, pn=1 -> leftmost page
 * pn = index = -1: No more entries
 */
dtpos = filp->f_pos;
-   if (dtpos == 0) {
+   if (dtpos < 2) {
/* build "." entry */
 
+   filp->f_pos = 1;
if (filldir(dirent, ".", 1, filp->f_pos, ip->i_ino,
DT_DIR))
return 0;
-   dtoffset->index = 1;
+   dtoffset->index = 2;
filp->f_pos = dtpos;
}
 
if (dtoffset->pn == 0) {
-   if (dtoffset->index == 1) {
+   if (dtoffset->index == 2) {
/* build ".." entry */
 
if (filldir(dirent, "..", 2, filp->f_pos,
@@ -3233,6 +3242,12 @@ int jfs_readdir(struct file *filp, void *dirent, 
filldir_t filldir)
}
jfs_dirent->position = unique_pos++;
}
+   /*
+* We add 1 to the index because we may
+* use a value of 2 internally, and NFSv4
+* doesn't like that.
+*/
+   jfs_dirent->position++;
} else {
jfs_dirent->position = dtpos;
len = min(d_namleft, DTLHDRDATALEN_LEGACY);
-- 
1.7.10.4


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

[110/251] drm/radeon: fix combios tables on older cards

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Mark Kettenis 

[ Upstream commit cef1d00cd56f600121ad121875655ad410a001b8 ]

Noticed that my old Radeon 7500 hung after printing

   drm: GPU not posted. posting now...

when it wasn't selected as the primary card the BIOS.  Some digging
revealed that it was hanging in combios_parse_mmio_table() while
parsing the ASIC INIT 3 table.  Looking at the BIOS ROM for the card,
it becomes obvious that there is no ASIC INIT 3 table in the BIOS.
The code is just processing random garbage.  No surprise it hangs!

Why do I say that there is no ASIC INIT 3 table is the BIOS?  This
table is found through the MISC INFO table.  The MISC INFO table can
be found at offset 0x5e in the COMBIOS header.  But the header is
smaller than that.  The COMBIOS header starts at offset 0x126.  The
standard PCI Data Structure (the bit that starts with 'PCIR') lives at
offset 0x180.  That means that the COMBIOS header can not be larger
than 0x5a bytes and therefore cannot contain a MISC INFO table.

I looked at a dozen or so BIOS images, some my own, some downloaded from:



It is fairly obvious that the size of the COMBIOS header can be found
at offset 0x6 of the header.  Not sure if it is a 16-bit number or
just an 8-bit number, but that doesn't really matter since the tables
seems to be always smaller than 256 bytes.

So I think combios_get_table_offset() should check if the requested
table is present.  This can be done by checking the offset against the
size of the header.  See the diff below.  The diff is against the WIP
OpenBSD codebase that roughly corresponds to Linux 3.8.13 at this
point.  But I don't think this bit of the code changed much since
then.

For what it is worth:

Signed-off-by: Mark Kettenis 
Signed-off-by: Alex Deucher 
Cc: sta...@vger.kernel.org
Signed-off-by: Steven Rostedt 
---
 drivers/gpu/drm/radeon/radeon_combios.c |  145 +--
 1 file changed, 41 insertions(+), 104 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_combios.c 
b/drivers/gpu/drm/radeon/radeon_combios.c
index f75247d..16bd2a2 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -147,7 +147,7 @@ static uint16_t combios_get_table_offset(struct drm_device 
*dev,
 enum radeon_combios_table_offset table)
 {
struct radeon_device *rdev = dev->dev_private;
-   int rev;
+   int rev, size;
uint16_t offset = 0, check_offset;
 
if (!rdev->bios)
@@ -156,174 +156,106 @@ static uint16_t combios_get_table_offset(struct 
drm_device *dev,
switch (table) {
/* absolute offset tables */
case COMBIOS_ASIC_INIT_1_TABLE:
-   check_offset = RBIOS16(rdev->bios_header_start + 0xc);
-   if (check_offset)
-   offset = check_offset;
+   check_offset = 0xc;
break;
case COMBIOS_BIOS_SUPPORT_TABLE:
-   check_offset = RBIOS16(rdev->bios_header_start + 0x14);
-   if (check_offset)
-   offset = check_offset;
+   check_offset = 0x14;
break;
case COMBIOS_DAC_PROGRAMMING_TABLE:
-   check_offset = RBIOS16(rdev->bios_header_start + 0x2a);
-   if (check_offset)
-   offset = check_offset;
+   check_offset = 0x2a;
break;
case COMBIOS_MAX_COLOR_DEPTH_TABLE:
-   check_offset = RBIOS16(rdev->bios_header_start + 0x2c);
-   if (check_offset)
-   offset = check_offset;
+   check_offset = 0x2c;
break;
case COMBIOS_CRTC_INFO_TABLE:
-   check_offset = RBIOS16(rdev->bios_header_start + 0x2e);
-   if (check_offset)
-   offset = check_offset;
+   check_offset = 0x2e;
break;
case COMBIOS_PLL_INFO_TABLE:
-   check_offset = RBIOS16(rdev->bios_header_start + 0x30);
-   if (check_offset)
-   offset = check_offset;
+   check_offset = 0x30;
break;
case COMBIOS_TV_INFO_TABLE:
-   check_offset = RBIOS16(rdev->bios_header_start + 0x32);
-   if (check_offset)
-   offset = check_offset;
+   check_offset = 0x32;
break;
case COMBIOS_DFP_INFO_TABLE:
-   check_offset = RBIOS16(rdev->bios_header_start + 0x34);
-   if (check_offset)
-   offset = check_offset;
+   check_offset = 0x34;
break;
case COMBIOS_HW_CONFIG_INFO_TABLE:
-   check_offset = RBIOS16(rdev->bios_header_start + 0x36);
-   if (check_offset)
- 

[107/251] dm mpath: fix ioctl deadlock when no paths

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Hannes Reinecke 

[ Upstream commit 6c182cd88d179cbbd06f4f8a8a19b6977940753f ]

When multipath needs to retry an ioctl the reference to the
current live table needs to be dropped. Otherwise a deadlock
occurs when all paths are down:
- dm_blk_ioctl takes a reference to the current table
  and spins in multipath_ioctl().
- A new table is being loaded, but upon resume the process
  hangs in dm_table_destroy() waiting for references to
  drop to zero.

With this patch the reference to the old table is dropped
prior to retry, thereby avoiding the deadlock.

Signed-off-by: Hannes Reinecke 
Cc: Mike Snitzer 
Cc: sta...@vger.kernel.org
Signed-off-by: Alasdair G Kergon 
Signed-off-by: Steven Rostedt 
---
 drivers/md/dm-mpath.c |8 ++--
 drivers/md/dm.c   |9 -
 2 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/md/dm-mpath.c b/drivers/md/dm-mpath.c
index 034233e..4fc70c8 100644
--- a/drivers/md/dm-mpath.c
+++ b/drivers/md/dm-mpath.c
@@ -1561,7 +1561,6 @@ static int multipath_ioctl(struct dm_target *ti, unsigned 
int cmd,
unsigned long flags;
int r;
 
-again:
bdev = NULL;
mode = 0;
r = 0;
@@ -1579,7 +1578,7 @@ again:
}
 
if ((pgpath && m->queue_io) || (!pgpath && m->queue_if_no_path))
-   r = -EAGAIN;
+   r = -ENOTCONN;
else if (!bdev)
r = -EIO;
 
@@ -1591,11 +1590,8 @@ again:
if (!r && ti->len != i_size_read(bdev->bd_inode) >> SECTOR_SHIFT)
r = scsi_verify_blk_ioctl(NULL, cmd);
 
-   if (r == -EAGAIN && !fatal_signal_pending(current)) {
+   if (r == -ENOTCONN && !fatal_signal_pending(current))
queue_work(kmultipathd, >process_queued_ios);
-   msleep(10);
-   goto again;
-   }
 
return r ? : __blkdev_driver_ioctl(bdev, mode, cmd, arg);
 }
diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index 4256200..dd0a1a8 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -414,10 +414,12 @@ static int dm_blk_ioctl(struct block_device *bdev, 
fmode_t mode,
unsigned int cmd, unsigned long arg)
 {
struct mapped_device *md = bdev->bd_disk->private_data;
-   struct dm_table *map = dm_get_live_table(md);
+   struct dm_table *map;
struct dm_target *tgt;
int r = -ENOTTY;
 
+retry:
+   map = dm_get_live_table(md);
if (!map || !dm_table_get_size(map))
goto out;
 
@@ -438,6 +440,11 @@ static int dm_blk_ioctl(struct block_device *bdev, fmode_t 
mode,
 out:
dm_table_put(map);
 
+   if (r == -ENOTCONN) {
+   msleep(10);
+   goto retry;
+   }
+
return r;
 }
 
-- 
1.7.10.4


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

[108/251] dm verity: fix inability to use a few specific devices sizes

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Mikulas Patocka 

[ Upstream commit b1bf2de07271932326af847a3c6a01fdfd29d4be ]

Fix a boundary condition that caused failure for certain device sizes.

The problem is reported at
  http://code.google.com/p/cryptsetup/issues/detail?id=160

For certain device sizes the number of hashes at a specific level was
calculated incorrectly.

It happens for example for a device with data and metadata block size 4096
that has 16385 blocks and algorithm sha256.

The user can test if he is affected by this bug by running the
"veritysetup verify" command and also by activating the dm-verity kernel
driver and reading the whole block device. If it passes without an error,
then the user is not affected.

The condition for the bug is:

Split the total number of data blocks (data_block_bits) into bit strings,
each string has hash_per_block_bits bits. hash_per_block_bits is
rounddown(log2(metadata_block_size/hash_digest_size)). Equivalently, you
can say that you convert data_blocks_bits to 2^hash_per_block_bits base.

If there some zero bit string below the most significant bit string and at
least one bit below this zero bit string is set, then the bug happens.

The same bug exists in the userspace veritysetup tool, so you must use
fixed veritysetup too if you want to use devices that are affected by
this boundary condition.

Signed-off-by: Mikulas Patocka 
Cc: sta...@vger.kernel.org # 3.4+
Cc: Milan Broz 
Signed-off-by: Alasdair G Kergon 
Signed-off-by: Steven Rostedt 
---
 drivers/md/dm-verity.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/md/dm-verity.c b/drivers/md/dm-verity.c
index dd5ba3b..30b364c 100644
--- a/drivers/md/dm-verity.c
+++ b/drivers/md/dm-verity.c
@@ -842,9 +842,8 @@ static int verity_ctr(struct dm_target *ti, unsigned argc, 
char **argv)
for (i = v->levels - 1; i >= 0; i--) {
sector_t s;
v->hash_level_block[i] = hash_position;
-   s = verity_position_at_level(v, v->data_blocks, i);
-   s = (s >> v->hash_per_block_bits) +
-   !!(s & ((1 << v->hash_per_block_bits) - 1));
+   s = (v->data_blocks + ((sector_t)1 << ((i + 1) * 
v->hash_per_block_bits)) - 1)
+   >> ((i + 1) * v->hash_per_block_bits);
if (hash_position + s < hash_position) {
ti->error = "Hash device offset overflow";
r = -E2BIG;
-- 
1.7.10.4


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

[109/251] drm/radeon: fix endian issues with DP handling (v3)

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Alex Deucher 

[ Upstream commit 34be8c9af7b8728465963740fc11136ae90dfc36 ]

The atom interpreter expects data in LE format, so
swap the message buffer as apprioriate.

v2: properly handle non-dw aligned byte counts.
v3: properly handle remainder

Signed-off-by: Alex Deucher 
Cc: Dong He 
Cc: sta...@vger.kernel.org
Signed-off-by: Steven Rostedt 
---
 drivers/gpu/drm/radeon/atombios_dp.c |   43 ++
 1 file changed, 39 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
b/drivers/gpu/drm/radeon/atombios_dp.c
index 3623b98..a0b5e1e 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -45,6 +45,41 @@ static char *pre_emph_names[] = {
 };
 
 /* radeon AUX functions */
+
+/* Atom needs data in little endian format
+ * so swap as appropriate when copying data to
+ * or from atom. Note that atom operates on
+ * dw units.
+ */
+static void radeon_copy_swap(u8 *dst, u8 *src, u8 num_bytes, bool to_le)
+{
+#ifdef __BIG_ENDIAN
+   u8 src_tmp[20], dst_tmp[20]; /* used for byteswapping */
+   u32 *dst32, *src32;
+   int i;
+
+   memcpy(src_tmp, src, num_bytes);
+   src32 = (u32 *)src_tmp;
+   dst32 = (u32 *)dst_tmp;
+   if (to_le) {
+   for (i = 0; i < ((num_bytes + 3) / 4); i++)
+   dst32[i] = cpu_to_le32(src32[i]);
+   memcpy(dst, dst_tmp, num_bytes);
+   } else {
+   u8 dws = num_bytes & ~3;
+   for (i = 0; i < ((num_bytes + 3) / 4); i++)
+   dst32[i] = le32_to_cpu(src32[i]);
+   memcpy(dst, dst_tmp, dws);
+   if (num_bytes % 4) {
+   for (i = 0; i < (num_bytes % 4); i++)
+   dst[dws+i] = dst_tmp[dws+i];
+   }
+   }
+#else
+   memcpy(dst, src, num_bytes);
+#endif
+}
+
 union aux_channel_transaction {
PROCESS_AUX_CHANNEL_TRANSACTION_PS_ALLOCATION v1;
PROCESS_AUX_CHANNEL_TRANSACTION_PARAMETERS_V2 v2;
@@ -66,10 +101,10 @@ static int radeon_process_aux_ch(struct radeon_i2c_chan 
*chan,
 
base = (unsigned char *)(rdev->mode_info.atom_context->scratch + 1);
 
-   memcpy(base, send, send_bytes);
+   radeon_copy_swap(base, send, send_bytes, true);
 
-   args.v1.lpAuxRequest = 0 + 4;
-   args.v1.lpDataOut = 16 + 4;
+   args.v1.lpAuxRequest = cpu_to_le16((u16)(0 + 4));
+   args.v1.lpDataOut = cpu_to_le16((u16)(16 + 4));
args.v1.ucDataOutLen = 0;
args.v1.ucChannelID = chan->rec.i2c_id;
args.v1.ucDelay = delay / 10;
@@ -103,7 +138,7 @@ static int radeon_process_aux_ch(struct radeon_i2c_chan 
*chan,
recv_bytes = recv_size;
 
if (recv && recv_size)
-   memcpy(recv, base + 16, recv_bytes);
+   radeon_copy_swap(recv, base + 16, recv_bytes, false);
 
return recv_bytes;
 }
-- 
1.7.10.4


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

[105/251] nfsd: nfsd_open: when dentry_open returns an error do not propagate as struct file

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Harshula Jayasuriya 

[ Upstream commit e4daf1ffbe6cc3b12aab4d604e627829e93e9914 ]

The following call chain:

nfs4_get_vfs_file
- nfsd_open
  - dentry_open
- do_dentry_open
  - __get_file_write_access
- get_write_access
  - return atomic_inc_unless_negative(>i_writecount) ? 0 : 
-ETXTBSY;


can result in the following state:

struct nfs4_file {
...
  fi_fds = {0x880c1fa65c80, 0xffe6, 0x0},
  fi_access = {{
  counter = 0x1
}, {
  counter = 0x0
}},
...


1) First time around, in nfs4_get_vfs_file() fp->fi_fds[O_WRONLY] is
NULL, hence nfsd_open() is called where we get status set to an error
and fp->fi_fds[O_WRONLY] to -ETXTBSY. Thus we do not reach
nfs4_file_get_access() and fi_access[O_WRONLY] is not incremented.

2) Second time around, in nfs4_get_vfs_file() fp->fi_fds[O_WRONLY] is
NOT NULL (-ETXTBSY), so nfsd_open() is NOT called, but
nfs4_file_get_access() IS called and fi_access[O_WRONLY] is incremented.
Thus we leave a landmine in the form of the nfs4_file data structure in
an incorrect state.

3) Eventually, when __nfs4_file_put_access() is called it finds
fi_access[O_WRONLY] being non-zero, it decrements it and calls
nfs4_file_put_fd() which tries to fput -ETXTBSY.

...
 [exception RIP: fput+0x9]
 RIP: 81177fa9  RSP: 88062e365c90  RFLAGS: 00010282
 RAX: 880c2b3d99cc  RBX: 880c2b3d9978  RCX: 0002
 RDX: dead00100101  RSI: 0001  RDI: ffe6
 RBP: 88062e365c90   R8: 88041fe797d8   R9: 88062e365d58
 R10: 0008  R11:   R12: 0001
 R13: 0007  R14:   R15: 
 ORIG_RAX:   CS: 0010  SS: 0018
  #9 [88062e365c98] __nfs4_file_put_access at a0562334 [nfsd]
 #10 [88062e365cc8] nfs4_file_put_access at a05623ab [nfsd]
 #11 [88062e365ce8] free_generic_stateid at a056634d [nfsd]
 #12 [88062e365d18] release_open_stateid at a0566e4b [nfsd]
 #13 [88062e365d38] nfsd4_close at a0567401 [nfsd]
 #14 [88062e365d88] nfsd4_proc_compound at a0557f28 [nfsd]
 #15 [88062e365dd8] nfsd_dispatch at a054543e [nfsd]
 #16 [88062e365e18] svc_process_common at a04ba5a4 [sunrpc]
 #17 [88062e365e98] svc_process at a04babe0 [sunrpc]
 #18 [88062e365eb8] nfsd at a0545b62 [nfsd]
 #19 [88062e365ee8] kthread at 81090886
 #20 [88062e365f48] kernel_thread at 8100c14a


Cc: sta...@vger.kernel.org
Signed-off-by: Harshula Jayasuriya 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Steven Rostedt 
---
 fs/nfsd/vfs.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
index a9269f1..1db47bc 100644
--- a/fs/nfsd/vfs.c
+++ b/fs/nfsd/vfs.c
@@ -802,9 +802,10 @@ nfsd_open(struct svc_rqst *rqstp, struct svc_fh *fhp, 
umode_t type,
flags = O_WRONLY|O_LARGEFILE;
}
*filp = dentry_open(, flags, current_cred());
-   if (IS_ERR(*filp))
+   if (IS_ERR(*filp)) {
host_err = PTR_ERR(*filp);
-   else {
+   *filp = NULL;
+   } else {
host_err = ima_file_check(*filp, may_flags);
 
if (may_flags & NFSD_MAY_64BIT_COOKIE)
-- 
1.7.10.4


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

[103/251] svcrdma: underflow issue in decode_write_list()

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Dan Carpenter 

[ Upstream commit b2781e1021525649c0b33fffd005ef219da33926 ]

My static checker marks everything from ntohl() as untrusted and it
complains we could have an underflow problem doing:

return (u32 *)>wc_array[nchunks];

Also on 32 bit systems the upper bound check could overflow.

Cc: sta...@vger.kernel.org
Signed-off-by: Dan Carpenter 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Steven Rostedt 
---
 net/sunrpc/xprtrdma/svc_rdma_marshal.c |   20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/net/sunrpc/xprtrdma/svc_rdma_marshal.c 
b/net/sunrpc/xprtrdma/svc_rdma_marshal.c
index 8d2eddd..65b1462 100644
--- a/net/sunrpc/xprtrdma/svc_rdma_marshal.c
+++ b/net/sunrpc/xprtrdma/svc_rdma_marshal.c
@@ -98,6 +98,7 @@ void svc_rdma_rcl_chunk_counts(struct rpcrdma_read_chunk *ch,
  */
 static u32 *decode_write_list(u32 *va, u32 *vaend)
 {
+   unsigned long start, end;
int nchunks;
 
struct rpcrdma_write_array *ary =
@@ -113,9 +114,12 @@ static u32 *decode_write_list(u32 *va, u32 *vaend)
return NULL;
}
nchunks = ntohl(ary->wc_nchunks);
-   if (((unsigned long)>wc_array[0] +
-(sizeof(struct rpcrdma_write_chunk) * nchunks)) >
-   (unsigned long)vaend) {
+
+   start = (unsigned long)>wc_array[0];
+   end = (unsigned long)vaend;
+   if (nchunks < 0 ||
+   nchunks > (SIZE_MAX - start) / sizeof(struct rpcrdma_write_chunk) ||
+   (start + (sizeof(struct rpcrdma_write_chunk) * nchunks)) > end) {
dprintk("svcrdma: ary=%p, wc_nchunks=%d, vaend=%p\n",
ary, nchunks, vaend);
return NULL;
@@ -129,6 +133,7 @@ static u32 *decode_write_list(u32 *va, u32 *vaend)
 
 static u32 *decode_reply_array(u32 *va, u32 *vaend)
 {
+   unsigned long start, end;
int nchunks;
struct rpcrdma_write_array *ary =
(struct rpcrdma_write_array *)va;
@@ -143,9 +148,12 @@ static u32 *decode_reply_array(u32 *va, u32 *vaend)
return NULL;
}
nchunks = ntohl(ary->wc_nchunks);
-   if (((unsigned long)>wc_array[0] +
-(sizeof(struct rpcrdma_write_chunk) * nchunks)) >
-   (unsigned long)vaend) {
+
+   start = (unsigned long)>wc_array[0];
+   end = (unsigned long)vaend;
+   if (nchunks < 0 ||
+   nchunks > (SIZE_MAX - start) / sizeof(struct rpcrdma_write_chunk) ||
+   (start + (sizeof(struct rpcrdma_write_chunk) * nchunks)) > end) {
dprintk("svcrdma: ary=%p, wc_nchunks=%d, vaend=%p\n",
ary, nchunks, vaend);
return NULL;
-- 
1.7.10.4


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

[104/251] powerpc/modules: Module CRC relocation fix causes perf issues

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Anton Blanchard 

[ Upstream commit 0e0ed6406e61434d3f38fb58aa8464ec4722b77e ]

Module CRCs are implemented as absolute symbols that get resolved by
a linker script. We build an intermediate .o that contains an
unresolved symbol for each CRC. genksysms parses this .o, calculates
the CRCs and writes a linker script that "resolves" the symbols to
the calculated CRC.

Unfortunately the ppc64 relocatable kernel sees these CRCs as symbols
that need relocating and relocates them at boot. Commit d4703aef
(module: handle ppc64 relocating kcrctabs when CONFIG_RELOCATABLE=y)
added a hook to reverse the bogus relocations. Part of this patch
created a symbol at 0x0:

# head -2 /proc/kallsyms
 T reloc_start
c000 T .__start

This reloc_start symbol is causing lots of confusion to perf. It
thinks reloc_start is a massive function that stretches from 0x0 to
0xc000 and we get various cryptic errors out of perf,
including:

problem incrementing symbol count, skipping event

This patch removes the  reloc_start linker script label and instead
defines it as PHYSICAL_START. We also need to wrap it with
CONFIG_PPC64 because the ppc32 kernel can set a non zero
PHYSICAL_START at compile time and we wouldn't want to subtract
it from the CRCs in that case.

Signed-off-by: Anton Blanchard 
Cc: 
Acked-by: Rusty Russell 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Steven Rostedt 
---
 arch/powerpc/include/asm/module.h |5 ++---
 arch/powerpc/kernel/vmlinux.lds.S |3 ---
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/include/asm/module.h 
b/arch/powerpc/include/asm/module.h
index 0192a4e..80de64b 100644
--- a/arch/powerpc/include/asm/module.h
+++ b/arch/powerpc/include/asm/module.h
@@ -87,10 +87,9 @@ struct exception_table_entry;
 void sort_ex_table(struct exception_table_entry *start,
   struct exception_table_entry *finish);
 
-#ifdef CONFIG_MODVERSIONS
+#if defined(CONFIG_MODVERSIONS) && defined(CONFIG_PPC64)
 #define ARCH_RELOCATES_KCRCTAB
-
-extern const unsigned long reloc_start[];
+#define reloc_start PHYSICAL_START
 #endif
 #endif /* __KERNEL__ */
 #endif /* _ASM_POWERPC_MODULE_H */
diff --git a/arch/powerpc/kernel/vmlinux.lds.S 
b/arch/powerpc/kernel/vmlinux.lds.S
index 65d1c08..7703569 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -38,9 +38,6 @@ jiffies = jiffies_64 + 4;
 #endif
 SECTIONS
 {
-   . = 0;
-   reloc_start = .;
-
. = KERNELBASE;
 
 /*
-- 
1.7.10.4


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

[100/251] md/raid5: fix interaction of replace and recovery.

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: NeilBrown 

[ Upstream commit f94c0b6658c7edea8bc19d13be321e3860a3fa54 ]

If a device in a RAID4/5/6 is being replaced while another is being
recovered, then the writes to the replacement device currently don't
happen, resulting in corruption when the replacement completes and the
new drive takes over.

This is because the replacement writes are only triggered when
's.replacing' is set and not when the similar 's.sync' is set (which
is the case during resync and recovery - it means all devices need to
be read).

So schedule those writes when s.replacing is set as well.

In this case we cannot use "STRIPE_INSYNC" to record that the
replacement has happened as that is needed for recording that any
parity calculation is complete.  So introduce STRIPE_REPLACED to
record if the replacement has happened.

For safety we should also check that STRIPE_COMPUTE_RUN is not set.
This has a similar effect to the "s.locked == 0" test.  The latter
ensure that now IO has been flagged but not started.  The former
checks if any parity calculation has been flagged by not started.
We must wait for both of these to complete before triggering the
'replace'.

Add a similar test to the subsequent check for "are we finished yet".
This possibly isn't needed (is subsumed in the STRIPE_INSYNC test),
but it makes it more obvious that the REPLACE will happen before we
think we are finished.

Finally if a NeedReplace device is not UPTODATE then that is an
error.  We really must trigger a warning.

This bug was introduced in commit 9a3e1101b827a59ac9036a672f5fa8d5279d0fe2
(md/raid5:  detect and handle replacements during recovery.)
which introduced replacement for raid5.
That was in 3.3-rc3, so any stable kernel since then would benefit
from this fix.

Cc: sta...@vger.kernel.org (3.3+)
Reported-by: qindehua <13691222...@163.com>
Tested-by: qindehua 
Signed-off-by: NeilBrown 
Signed-off-by: Steven Rostedt 
---
 drivers/md/raid5.c |   15 ++-
 drivers/md/raid5.h |1 +
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 0689173..f94452d 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -3396,6 +3396,7 @@ static void handle_stripe(struct stripe_head *sh)
if (test_and_clear_bit(STRIPE_SYNC_REQUESTED, >state)) {
set_bit(STRIPE_SYNCING, >state);
clear_bit(STRIPE_INSYNC, >state);
+   clear_bit(STRIPE_REPLACED, >state);
}
clear_bit(STRIPE_DELAYED, >state);
 
@@ -3535,19 +3536,23 @@ static void handle_stripe(struct stripe_head *sh)
handle_parity_checks5(conf, sh, , disks);
}
 
-   if (s.replacing && s.locked == 0
-   && !test_bit(STRIPE_INSYNC, >state)) {
+   if ((s.replacing || s.syncing) && s.locked == 0
+   && !test_bit(STRIPE_COMPUTE_RUN, >state)
+   && !test_bit(STRIPE_REPLACED, >state)) {
/* Write out to replacement devices where possible */
for (i = 0; i < conf->raid_disks; i++)
-   if (test_bit(R5_UPTODATE, >dev[i].flags) &&
-   test_bit(R5_NeedReplace, >dev[i].flags)) {
+   if (test_bit(R5_NeedReplace, >dev[i].flags)) {
+   WARN_ON(!test_bit(R5_UPTODATE, 
>dev[i].flags));
set_bit(R5_WantReplace, >dev[i].flags);
set_bit(R5_LOCKED, >dev[i].flags);
s.locked++;
}
-   set_bit(STRIPE_INSYNC, >state);
+   if (s.replacing)
+   set_bit(STRIPE_INSYNC, >state);
+   set_bit(STRIPE_REPLACED, >state);
}
if ((s.syncing || s.replacing) && s.locked == 0 &&
+   !test_bit(STRIPE_COMPUTE_RUN, >state) &&
test_bit(STRIPE_INSYNC, >state)) {
md_done_sync(conf->mddev, STRIPE_SECTORS, 1);
clear_bit(STRIPE_SYNCING, >state);
diff --git a/drivers/md/raid5.h b/drivers/md/raid5.h
index a9fc249..03f988b 100644
--- a/drivers/md/raid5.h
+++ b/drivers/md/raid5.h
@@ -309,6 +309,7 @@ enum {
STRIPE_SYNC_REQUESTED,
STRIPE_SYNCING,
STRIPE_INSYNC,
+   STRIPE_REPLACED,
STRIPE_PREREAD_ACTIVE,
STRIPE_DELAYED,
STRIPE_DEGRADED,
-- 
1.7.10.4


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

[101/251] md/raid10: remove use-after-free bug.

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: NeilBrown 

[ Upstream commit 0eb25bb027a100f5a9df8991f2f628e7d851bc1e ]

We always need to be careful when calling generic_make_request, as it
can start a chain of events which might free something that we are
using.

Here is one place I wasn't careful enough.  If the wbio2 is not in
use, then it might get freed at the first generic_make_request call.
So perform all necessary tests first.

This bug was introduced in 3.3-rc3 (24afd80d99) and can cause an
oops, so fix is suitable for any -stable since then.

Cc: sta...@vger.kernel.org (3.3+)
Signed-off-by: NeilBrown 
Signed-off-by: Steven Rostedt 
---
 drivers/md/raid10.c |8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index e2d5778..f40decb 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -2155,12 +2155,18 @@ static void recovery_request_write(struct mddev *mddev, 
struct r10bio *r10_bio)
d = r10_bio->devs[1].devnum;
wbio = r10_bio->devs[1].bio;
wbio2 = r10_bio->devs[1].repl_bio;
+   /* Need to test wbio2->bi_end_io before we call
+* generic_make_request as if the former is NULL,
+* the latter is free to free wbio2.
+*/
+   if (wbio2 && !wbio2->bi_end_io)
+   wbio2 = NULL;
if (wbio->bi_end_io) {
atomic_inc(>mirrors[d].rdev->nr_pending);
md_sync_acct(conf->mirrors[d].rdev->bdev, wbio->bi_size >> 9);
generic_make_request(wbio);
}
-   if (wbio2 && wbio2->bi_end_io) {
+   if (wbio2) {
atomic_inc(>mirrors[d].replacement->nr_pending);
md_sync_acct(conf->mirrors[d].replacement->bdev,
 wbio2->bi_size >> 9);
-- 
1.7.10.4


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

[239/251] ALSA: opti9xx: Fix conflicting driver object name

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Takashi Iwai 

[ Upstream commit fb615499f0ad28ed74201c1cdfddf9e64e205424 ]

The recent commit to delay the release of kobject triggered NULL
dereferences of opti9xx drivers.  The cause is that all
snd-opti92x-ad1848, snd-opti92x-cs4231 and snd-opti93x drivers
register the PnP card driver with the very same name, and also
snd-opti92x-ad1848 and -cs4231 drivers register the ISA driver with
the same name, too.  When these drivers are built in, quick
"register-release-and-re-register" actions occur, and this results in
Oops because of the same name is assigned to the kobject.

The fix is simply to assign individual names.  As a bonus, by using
KBUILD_MODNAME, the patch reduces more lines than it adds.

The fix is based on the suggestion by Russell King.

Reported-and-tested-by: Fengguang Wu 
Cc: 
Signed-off-by: Takashi Iwai 
Signed-off-by: Steven Rostedt 
---
 sound/isa/opti9xx/opti92x-ad1848.c |8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/sound/isa/opti9xx/opti92x-ad1848.c 
b/sound/isa/opti9xx/opti92x-ad1848.c
index f8fbe22..e7ec347 100644
--- a/sound/isa/opti9xx/opti92x-ad1848.c
+++ b/sound/isa/opti9xx/opti92x-ad1848.c
@@ -172,11 +172,7 @@ MODULE_DEVICE_TABLE(pnp_card, snd_opti9xx_pnpids);
 
 #endif /* CONFIG_PNP */
 
-#ifdef OPTi93X
-#define DEV_NAME "opti93x"
-#else
-#define DEV_NAME "opti92x"
-#endif
+#define DEV_NAME KBUILD_MODNAME
 
 static char * snd_opti9xx_names[] = {
"unknown",
@@ -1180,7 +1176,7 @@ static int snd_opti9xx_pnp_resume(struct pnp_card_link 
*pcard)
 
 static struct pnp_card_driver opti9xx_pnpc_driver = {
.flags  = PNP_DRIVER_RES_DISABLE,
-   .name   = "opti9xx",
+   .name   = DEV_NAME,
.id_table   = snd_opti9xx_pnpids,
.probe  = snd_opti9xx_pnp_probe,
.remove = __devexit_p(snd_opti9xx_pnp_remove),
-- 
1.7.10.4


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

[238/251] ALSA: hda - Add inverted digital mic fixup for Acer Aspire One

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Takashi Iwai 

[ Upstream commit d3d3835ce919438c00c5d1270d6f9d6ffea59d03 ]

Yet another entry, just use the existing fixup for this machine, too.

Reported-by: "Nathanael D. Noblet" 
Cc: 
Signed-off-by: Takashi Iwai 
Signed-off-by: Steven Rostedt 
---
 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 6d31bc8..d0bbdf9 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6860,6 +6860,7 @@ static const struct alc_fixup alc662_fixups[] = {
 
 static const struct snd_pci_quirk alc662_fixup_tbl[] = {
SND_PCI_QUIRK(0x1019, 0x9087, "ECS", ALC662_FIXUP_ASUS_MODE2),
+   SND_PCI_QUIRK(0x1025, 0x022f, "Acer Aspire One", ALC662_FIXUP_INV_DMIC),
SND_PCI_QUIRK(0x1025, 0x0308, "Acer Aspire 8942G", ALC662_FIXUP_ASPIRE),
SND_PCI_QUIRK(0x1025, 0x031c, "Gateway NV79", ALC662_FIXUP_SKU_IGNORE),
SND_PCI_QUIRK(0x1025, 0x0349, "eMachines eM250", ALC662_FIXUP_INV_DMIC),
-- 
1.7.10.4


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

[102/251] libata: make it clear that sata_inic162x is experimental

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Tejun Heo 

[ Upstream commit bb9696192826a7d9279caf872e95b41bc26c7eff ]

sata_inic162x never reached a state where it's reliable enough for
production use and data corruption is a relatively common occurrence.
Make the driver generate warning about the issues and mark the Kconfig
option as experimental.

If the situation doesn't improve, we'd be better off making it depend
on CONFIG_BROKEN.  Let's wait for several cycles and see if the kernel
message draws any attention.

Signed-off-by: Tejun Heo 
Reported-by: Martin Braure de Calignon 
Reported-by: Ben Hutchings 
Reported-by: risc4...@yahoo.com
Signed-off-by: Steven Rostedt 
---
 drivers/ata/Kconfig |2 +-
 drivers/ata/sata_inic162x.c |   14 ++
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 27cecd3..79ba92e 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -93,7 +93,7 @@ config SATA_FSL
  If unsure, say N.
 
 config SATA_INIC162X
-   tristate "Initio 162x SATA support"
+   tristate "Initio 162x SATA support (Very Experimental)"
depends on PCI
help
  This option enables support for Initio 162x Serial ATA.
diff --git a/drivers/ata/sata_inic162x.c b/drivers/ata/sata_inic162x.c
index dc35f4d..4d238c8 100644
--- a/drivers/ata/sata_inic162x.c
+++ b/drivers/ata/sata_inic162x.c
@@ -6,6 +6,18 @@
  *
  * This file is released under GPL v2.
  *
+ *  WARNING 
+ *
+ * This driver never worked properly and unfortunately data corruption is
+ * relatively common.  There isn't anyone working on the driver and there's
+ * no support from the vendor.  Do not use this driver in any production
+ * environment.
+ *
+ * http://thread.gmane.org/gmane.linux.debian.devel.bugs.rc/378525/focus=54491
+ * https://bugzilla.kernel.org/show_bug.cgi?id=60565
+ *
+ * *
+ *
  * This controller is eccentric and easily locks up if something isn't
  * right.  Documentation is available at initio's website but it only
  * documents registers (not programming model).
@@ -809,6 +821,8 @@ static int inic_init_one(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 
ata_print_version_once(>dev, DRV_VERSION);
 
+   dev_alert(>dev, "inic162x support is broken with common data 
corruption issues and will be disabled by default, contact 
linux-...@vger.kernel.org if in production use\n");
+
/* alloc host */
host = ata_host_alloc_pinfo(>dev, ppi, NR_PORTS);
hpriv = devm_kzalloc(>dev, sizeof(*hpriv), GFP_KERNEL);
-- 
1.7.10.4


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

[106/251] ACPI / memhotplug: Fix a stale pointer in error path

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Toshi Kani 

[ Upstream commit d19f503e22316a84c39bc19445e0e4fdd49b3532 ]

device->driver_data needs to be cleared when releasing its data,
mem_device, in an error path of acpi_memory_device_add().

The function evaluates the _CRS of memory device objects, and fails
when it gets an unexpected resource or cannot allocate memory.  A
kernel crash or data corruption may occur when the kernel accesses
the stale pointer.

Signed-off-by: Toshi Kani 
Reviewed-by: Yasuaki Ishimatsu 
Cc: 2.6.32+ 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Steven Rostedt 
---
 drivers/acpi/acpi_memhotplug.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index 24c807f..f16ffd4 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -442,6 +442,7 @@ static int acpi_memory_device_add(struct acpi_device 
*device)
/* Get the range from the _CRS */
result = acpi_memory_get_device_resources(mem_device);
if (result) {
+   device->driver_data = NULL;
kfree(mem_device);
return result;
}
-- 
1.7.10.4


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

[244/251] drivers/base/memory.c: fix show_mem_removable() to handle missing sections

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Russ Anderson 

[ Upstream commit 21ea9f5ace3a7317cc3ba1fbc749758021a83136 ]

"cat /sys/devices/system/memory/memory*/removable" crashed the system.

The problem is that show_mem_removable() is passing a
bad pfn to is_mem_section_removable(), which causes

if (!node_online(page_to_nid(page)))

to blow up.  Why is it passing in a bad pfn?

The reason is that show_mem_removable() will loop sections_per_block
times.  sections_per_block is 16, but mem->section_count is 8,
indicating holes in this memory block.  Checking that the memory section
is present before checking to see if the memory section is removable
fixes the problem.

   harp5-sys:~ # cat /sys/devices/system/memory/memory*/removable
   0
   1
   1
   1
   1
   1
   1
   1
   1
   1
   1
   1
   1
   1
   BUG: unable to handle kernel paging request at ea00c320
   IP: [] is_pageblock_removable_nolock+0x1/0x90
   PGD 83ffd4067 PUD 37bdfce067 PMD 0
   Oops:  [#1] SMP
   Modules linked in: autofs4 binfmt_misc rdma_ucm rdma_cm iw_cm ib_addr ib_srp 
scsi_transport_srp scsi_tgt ib_ipoib ib_cm ib_uverbs ib_umad iw_cxgb3 cxgb3 
mdio mlx4_en mlx4_ib ib_sa mlx4_core ib_mthca ib_mad ib_core fuse nls_iso8859_1 
nls_cp437 vfat fat joydev loop hid_generic usbhid hid hwperf(O) numatools(O) 
dm_mod iTCO_wdt ipv6 iTCO_vendor_support igb i2c_i801 ioatdma i2c_algo_bit 
ehci_pci pcspkr lpc_ich i2c_core ehci_hcd ptp sg mfd_core dca rtc_cmos pps_core 
mperf button xhci_hcd sd_mod crc_t10dif usbcore usb_common scsi_dh_emc 
scsi_dh_hp_sw scsi_dh_alua scsi_dh_rdac scsi_dh gru(O) xvma(O) xfs crc32c 
libcrc32c thermal sata_nv processor piix mptsas mptscsih scsi_transport_sas 
mptbase megaraid_sas fan thermal_sys hwmon ext3 jbd ata_piix ahci libahci 
libata scsi_mod
   CPU: 4 PID: 5991 Comm: cat Tainted: G   O 3.11.0-rc5-rja-uv+ #10
   Hardware name: SGI UV2000/ROMLEY, BIOS SGI UV 2000/3000 series BIOS 
01/15/2013
   task: 88081f034580 ti: 880820022000 task.ti: 880820022000
   RIP: 0010:[]  [] 
is_pageblock_removable_nolock+0x1/0x90
   RSP: 0018:880820023df8  EFLAGS: 00010287
   RAX: 0004 RBX: ea00c320 RCX: 0004
   RDX: ea00c30b RSI: 001c RDI: ea00c320
   RBP: 880820023e38 R08:  R09: 0001
   R10:  R11: 0001 R12: ea00c33c
   R13: 1600 R14: 6db6db6db6db6db7 R15: 0001
   FS:  77fb2700() GS:88083fc8() knlGS:
   CS:  0010 DS:  ES:  CR0: 80050033
   CR2: ea00c320 CR3: 00081b954000 CR4: 000407e0
   Call Trace:
 show_mem_removable+0x41/0x70
 dev_attr_show+0x2a/0x60
 sysfs_read_file+0xf7/0x1c0
 vfs_read+0xc8/0x130
 SyS_read+0x5d/0xa0
 system_call_fastpath+0x16/0x1b

Signed-off-by: Russ Anderson 
Cc: Greg Kroah-Hartman 
Cc: "Rafael J. Wysocki" 
Cc: Yinghai Lu 
Reviewed-by: Yasuaki Ishimatsu 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Steven Rostedt 
---
 drivers/base/memory.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 7dda4f7..d63a06b 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -154,6 +154,8 @@ static ssize_t show_mem_removable(struct device *dev,
container_of(dev, struct memory_block, dev);
 
for (i = 0; i < sections_per_block; i++) {
+   if (!present_section_nr(mem->start_section_nr + i))
+   continue;
pfn = section_nr_to_pfn(mem->start_section_nr + i);
ret &= is_mem_section_removable(pfn, PAGES_PER_SECTION);
}
-- 
1.7.10.4


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

[248/251] SUNRPC: Fix memory corruption issue on 32-bit highmem systems

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Trond Myklebust 

[ Upstream commit 347e2233b7667e336d9f671f1a52dfa3f0416e2c ]

Some architectures, such as ARM-32 do not return the same base address
when you call kmap_atomic() twice on the same page.
This causes problems for the memmove() call in the XDR helper routine
"_shift_data_right_pages()", since it defeats the detection of
overlapping memory ranges, and has been seen to corrupt memory.

The fix is to distinguish between the case where we're doing an
inter-page copy or not. In the former case of we know that the memory
ranges cannot possibly overlap, so we can additionally micro-optimise
by replacing memmove() with memcpy().

Reported-by: Mark Young 
Reported-by: Matt Craighead 
Cc: Bruce Fields 
Cc: sta...@vger.kernel.org
Signed-off-by: Trond Myklebust 
Tested-by: Matt Craighead 
Signed-off-by: Steven Rostedt 
---
 net/sunrpc/xdr.c |9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/net/sunrpc/xdr.c b/net/sunrpc/xdr.c
index 0afba1b..7e99acd 100644
--- a/net/sunrpc/xdr.c
+++ b/net/sunrpc/xdr.c
@@ -207,10 +207,13 @@ _shift_data_right_pages(struct page **pages, size_t 
pgto_base,
pgfrom_base -= copy;
 
vto = kmap_atomic(*pgto);
-   vfrom = kmap_atomic(*pgfrom);
-   memmove(vto + pgto_base, vfrom + pgfrom_base, copy);
+   if (*pgto != *pgfrom) {
+   vfrom = kmap_atomic(*pgfrom);
+   memcpy(vto + pgto_base, vfrom + pgfrom_base, copy);
+   kunmap_atomic(vfrom);
+   } else
+   memmove(vto + pgto_base, vto + pgfrom_base, copy);
flush_dcache_page(*pgto);
-   kunmap_atomic(vfrom);
kunmap_atomic(vto);
 
} while ((len -= copy) != 0);
-- 
1.7.10.4


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

[236/251] x86/xen: do not identity map UNUSABLE regions in the machine E820

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: David Vrabel 

[ Upstream commit 3bc38cbceb85881a8eb789ee1aa56678038b1909 ]

If there are UNUSABLE regions in the machine memory map, dom0 will
attempt to map them 1:1 which is not permitted by Xen and the kernel
will crash.

There isn't anything interesting in the UNUSABLE region that the dom0
kernel needs access to so we can avoid making the 1:1 mapping and
treat it as RAM.

We only do this for dom0, as that is where tboot case shows up.
A PV domU could have an UNUSABLE region in its pseudo-physical map
and would need to be handled in another patch.

This fixes a boot failure on hosts with tboot.

tboot marks a region in the e820 map as unusable and the dom0 kernel
would attempt to map this region and Xen does not permit unusable
regions to be mapped by guests.

  (XEN)   - 0006 (usable)
  (XEN)  0006 - 00068000 (reserved)
  (XEN)  00068000 - 0009e000 (usable)
  (XEN)  0010 - 0080 (usable)
  (XEN)  0080 - 00972000 (unusable)

tboot marked this region as unusable.

  (XEN)  00972000 - cf20 (usable)
  (XEN)  cf20 - cf38f000 (reserved)
  (XEN)  cf38f000 - cf3ce000 (ACPI data)
  (XEN)  cf3ce000 - d000 (reserved)
  (XEN)  e000 - f000 (reserved)
  (XEN)  fe00 - 0001 (reserved)
  (XEN)  0001 - 00063000 (usable)

Signed-off-by: David Vrabel 
Signed-off-by: Steven Rostedt 
[v1: Altered the patch and description with domU's with UNUSABLE regions]
Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/xen/setup.c |   22 ++
 1 file changed, 22 insertions(+)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index e2d62d6..8cf7449 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -313,6 +313,17 @@ static void xen_align_and_add_e820_region(u64 start, u64 
size, int type)
e820_add_region(start, end - start, type);
 }
 
+void xen_ignore_unusable(struct e820entry *list, size_t map_size)
+{
+   struct e820entry *entry;
+   unsigned int i;
+
+   for (i = 0, entry = list; i < map_size; i++, entry++) {
+   if (entry->type == E820_UNUSABLE)
+   entry->type = E820_RAM;
+   }
+}
+
 /**
  * machine_specific_memory_setup - Hook for machine specific memory setup.
  **/
@@ -353,6 +364,17 @@ char * __init xen_memory_setup(void)
}
BUG_ON(rc);
 
+   /*
+* Xen won't allow a 1:1 mapping to be created to UNUSABLE
+* regions, so if we're using the machine memory map leave the
+* region as RAM as it is in the pseudo-physical map.
+*
+* UNUSABLE regions in domUs are not handled and will need
+* a patch in the future.
+*/
+   if (xen_initial_domain())
+   xen_ignore_unusable(map, memmap.nr_entries);
+
/* Make sure the Xen-supplied memory map is well-ordered. */
sanitize_e820_map(map, memmap.nr_entries, _entries);
 
-- 
1.7.10.4


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

[243/251] regmap: Add another missing header for !CONFIG_REGMAP stubs

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Kevin Hilman 

[ Upstream commit 3f0fa9a808f98fa10a18ba2a73f13d65fda990fb ]

The use of WARN_ON() needs the definitions from bug.h, without it
you can get:

include/linux/regmap.h: In function 'regmap_write':
include/linux/regmap.h:525:2: error: implicit declaration of function 
'WARN_ONCE' [-Werror=implicit-function-declaration]

Signed-off-by: Kevin Hilman 
Signed-off-by: Mark Brown 
Cc: sta...@vger.kernel.org
Signed-off-by: Steven Rostedt 
---
 include/linux/regmap.h |1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/regmap.h b/include/linux/regmap.h
index 519d5f2..db23dde 100644
--- a/include/linux/regmap.h
+++ b/include/linux/regmap.h
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct module;
 struct device;
-- 
1.7.10.4


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

[241/251] powerpc: Dont Oops when accessing /proc/powerpc/lparcfg without hypervisor

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Benjamin Herrenschmidt 

[ Upstream commit f5f6cbb61610b7bf9d9d96db9c3979d62a424bab ]

/proc/powerpc/lparcfg is an ancient facility (though still actively used)
which allows access to some informations relative to the partition when
running underneath a PAPR compliant hypervisor.

It makes no sense on non-pseries machines. However, currently, not only
can it be created on these if the kernel has pseries support, but accessing
it on such a machine will crash due to trying to do hypervisor calls.

In fact, it should also not do HV calls on older pseries that didn't have
an hypervisor either.

Finally, it has the plumbing to be a module but is a "bool" Kconfig option.

This fixes the whole lot by turning it into a machine_device_initcall
that is only created on pseries, and adding the necessary hypervisor
check before calling the H_GET_EM_PARMS hypercall

CC: 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Steven Rostedt 
---
 arch/powerpc/kernel/lparcfg.c |   23 +--
 1 file changed, 9 insertions(+), 14 deletions(-)

diff --git a/arch/powerpc/kernel/lparcfg.c b/arch/powerpc/kernel/lparcfg.c
index f5725bc..7ebbae0 100644
--- a/arch/powerpc/kernel/lparcfg.c
+++ b/arch/powerpc/kernel/lparcfg.c
@@ -35,7 +35,13 @@
 #include 
 #include 
 #include 
+#include 
 
+
+/*
+ * This isn't a module but we expose that to userspace
+ * via /proc so leave the definitions here
+ */
 #define MODULE_VERS "1.9"
 #define MODULE_NAME "lparcfg"
 
@@ -419,7 +425,8 @@ static void parse_em_data(struct seq_file *m)
 {
unsigned long retbuf[PLPAR_HCALL_BUFSIZE];
 
-   if (plpar_hcall(H_GET_EM_PARMS, retbuf) == H_SUCCESS)
+   if (firmware_has_feature(FW_FEATURE_LPAR) &&
+   plpar_hcall(H_GET_EM_PARMS, retbuf) == H_SUCCESS)
seq_printf(m, "power_mode_data=%016lx\n", retbuf[0]);
 }
 
@@ -678,7 +685,6 @@ static int lparcfg_open(struct inode *inode, struct file 
*file)
 }
 
 static const struct file_operations lparcfg_fops = {
-   .owner  = THIS_MODULE,
.read   = seq_read,
.write  = lparcfg_write,
.open   = lparcfg_open,
@@ -704,15 +710,4 @@ static int __init lparcfg_init(void)
proc_ppc64_lparcfg = ent;
return 0;
 }
-
-static void __exit lparcfg_cleanup(void)
-{
-   if (proc_ppc64_lparcfg)
-   remove_proc_entry("lparcfg", proc_ppc64_lparcfg->parent);
-}
-
-module_init(lparcfg_init);
-module_exit(lparcfg_cleanup);
-MODULE_DESCRIPTION("Interface for LPAR configuration data");
-MODULE_AUTHOR("Dave Engebretsen");
-MODULE_LICENSE("GPL");
+machine_device_initcall(pseries, lparcfg_init);
-- 
1.7.10.4


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

Re: [PATCH] staging: dgnc: fix potential format string flaw

[Kees Cook]

On Tue, Sep 10, 2013 at 10:00 PM, Joe Perches  wrote:
> On Tue, 2013-09-10 at 21:41 -0700, Kees Cook wrote:
>> Make sure that format strings cannot leak into printk() calls from the
>> msgbuf string.
>
> printf(string);
> vs
> printf("%s", string);
>
> How does this help?

In the former case, format characters will get processed by the
sprintf logic. In the latter, they are printed as-is. In this specific
case, if there was a way to inject strings like "ohai %n" into the
msgbuf string, the former would actually attempt to resolve the %n. In
the simple case, this could lead to Oopses, and in the unlucky case,
it could allow arbitrary memory writing and execution control.

http://en.wikipedia.org/wiki/Uncontrolled_format_string

-Kees

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

[229/251] Hostap: copying wrong data prism2_ioctl_giwaplist()

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Dan Carpenter 

[ Upstream commit 909bd5926d474e275599094acad986af79671ac9 ]

We want the data stored in "addr" and "qual", but the extra ampersands
mean we are copying stack data instead.

Signed-off-by: Dan Carpenter 
Cc: sta...@vger.kernel.org
Signed-off-by: John W. Linville 
Signed-off-by: Steven Rostedt 
---
 drivers/net/wireless/hostap/hostap_ioctl.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/hostap/hostap_ioctl.c 
b/drivers/net/wireless/hostap/hostap_ioctl.c
index 18054d9..dbec2ff 100644
--- a/drivers/net/wireless/hostap/hostap_ioctl.c
+++ b/drivers/net/wireless/hostap/hostap_ioctl.c
@@ -522,9 +522,9 @@ static int prism2_ioctl_giwaplist(struct net_device *dev,
 
data->length = prism2_ap_get_sta_qual(local, addr, qual, IW_MAX_AP, 1);
 
-   memcpy(extra, , sizeof(struct sockaddr) * data->length);
+   memcpy(extra, addr, sizeof(struct sockaddr) * data->length);
data->flags = 1; /* has quality information */
-   memcpy(extra + sizeof(struct sockaddr) * data->length, ,
+   memcpy(extra + sizeof(struct sockaddr) * data->length, qual,
   sizeof(struct iw_quality) * data->length);
 
kfree(addr);
-- 
1.7.10.4


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

[240/251] powerpc: Work around gcc miscompilation of __pa() on 64-bit

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Paul Mackerras 

[ Upstream commit bdbc29c19b2633b1d9c52638fb732bcde7a2031a ]

On 64-bit, __pa(_var) gets miscompiled by recent versions of
gcc as something like:

addis 3,2,.LANCHOR1+4611686018427387904@toc@ha
addi 3,3,.LANCHOR1+4611686018427387904@toc@l

This ends up effectively ignoring the offset, since its bottom 32 bits
are zero, and means that the result of __pa() still has 0xC in the top
nibble.  This happens with gcc 4.8.1, at least.

To work around this, for 64-bit we make __pa() use an AND operator,
and for symmetry, we make __va() use an OR operator.  Using an AND
operator rather than a subtraction ends up with slightly shorter code
since it can be done with a single clrldi instruction, whereas it
takes three instructions to form the constant (-PAGE_OFFSET) and add
it on.  (Note that MEMORY_START is always 0 on 64-bit.)

CC: 
Signed-off-by: Paul Mackerras 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Steven Rostedt 
---
 arch/powerpc/Kconfig|1 +
 arch/powerpc/include/asm/page.h |   10 ++
 2 files changed, 11 insertions(+)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 352f416..3254335 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -973,6 +973,7 @@ config RELOCATABLE
  must live at a different physical address than the primary
  kernel.
 
+# This value must have zeroes in the bottom 60 bits otherwise lots will break
 config PAGE_OFFSET
hex
default "0xc000"
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index f072e97..2e6c4e5a 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -211,9 +211,19 @@ extern long long virt_phys_offset;
 #define __va(x) ((void *)(unsigned long)((phys_addr_t)(x) + VIRT_PHYS_OFFSET))
 #define __pa(x) ((unsigned long)(x) - VIRT_PHYS_OFFSET)
 #else
+#ifdef CONFIG_PPC64
+/*
+ * gcc miscompiles (unsigned long)(_var) - PAGE_OFFSET
+ * with -mcmodel=medium, so we use & and | instead of - and + on 64-bit.
+ */
+#define __va(x) ((void *)(unsigned long)((phys_addr_t)(x) | PAGE_OFFSET))
+#define __pa(x) ((unsigned long)(x) & 0x0fffUL)
+
+#else /* 32-bit, non book E */
 #define __va(x) ((void *)(unsigned long)((phys_addr_t)(x) + PAGE_OFFSET - 
MEMORY_START))
 #define __pa(x) ((unsigned long)(x) - PAGE_OFFSET + MEMORY_START)
 #endif
+#endif
 
 /*
  * Unfortunately the PLT is in the BSS in the PPC32 ELF ABI,
-- 
1.7.10.4


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

Re: [PATCH 0/3] ARM: dts: Enable EDMA, MMC and SPI on AM33XX for v3.13

[Koen Kooi]

Op 10 sep. 2013, om 22:14 heeft Joel Fernandes  het volgende 
geschreven:

> On 09/10/2013 02:39 PM, Koen Kooi wrote:
>> 
>> Op 10 sep. 2013, om 21:24 heeft Joel Fernandes  het volgende 
>> geschreven:
>> 
>>> Here are last few patches required to add EDMA and MMC/SPI support for 
>>> AM33xx.
>>> 
>>> Now that all dependent DMA patches and fixes are in linux next or mainline, 
>>> except
>>> for [1] which should go in for 3.12 -rc cycle, it is safe to enable MMC and 
>>> SPI support
>>> and this patch series enables it. These are originally Matt Porter's 
>>> patches with
>>> changes to make it work with recent kernels, addition of irq, memory 
>>> resources and
>>> enable other extra properties.
>>> 
>>> These patches should cleanly apply on master branch after Koen's patch [2] 
>>> for basic
>>> BBB DT support is applied.
>>> 
>>> MMC support is enabled for: Beaglebone, AM335x EVM and EVM-SK boards. MMC 
>>> support
>>> for BBB is intentionally not added due to custom fixes and other patches 
>>> that are
>>> in Koen's tree and which will be separately submitted by him.
>> 
>> Correct, but your patches for MMC support on BBW are missing the card detect 
>> entries to make it hotplug work.
> 
> I thought it was determined that this would be submitted by you separately 
> after
> rebasing as we discussed [1] and [2].

I have no problem submitting that, I just think it's weird that the patch you 
submitted contains a known broken version for BBW.

> 
> [1] https://lkml.org/lkml/2013/9/6/183
> [2] http://marc.info/?l=linux-omap=137879246709612=2
> 
> 
> Regards,
> 
> -Joel

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

[235/251] sg: Fix user memory corruption when SG_IO is interrupted by a signal

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Roland Dreier 

[ Upstream commit 35dc248383bbab0a7203fca4d722875bc81ef091 ]

There is a nasty bug in the SCSI SG_IO ioctl that in some circumstances
leads to one process writing data into the address space of some other
random unrelated process if the ioctl is interrupted by a signal.
What happens is the following:

 - A process issues an SG_IO ioctl with direction DXFER_FROM_DEV (ie the
   underlying SCSI command will transfer data from the SCSI device to
   the buffer provided in the ioctl)

 - Before the command finishes, a signal is sent to the process waiting
   in the ioctl.  This will end up waking up the sg_ioctl() code:

result = wait_event_interruptible(sfp->read_wait,
(srp_done(sfp, srp) || sdp->detached));

   but neither srp_done() nor sdp->detached is true, so we end up just
   setting srp->orphan and returning to userspace:

srp->orphan = 1;
write_unlock_irq(>rq_list_lock);
return result;  /* -ERESTARTSYS because signal hit process */

   At this point the original process is done with the ioctl and
   blithely goes ahead handling the signal, reissuing the ioctl, etc.

 - Eventually, the SCSI command issued by the first ioctl finishes and
   ends up in sg_rq_end_io().  At the end of that function, we run through:

write_lock_irqsave(>rq_list_lock, iflags);
if (unlikely(srp->orphan)) {
if (sfp->keep_orphan)
srp->sg_io_owned = 0;
else
done = 0;
}
srp->done = done;
write_unlock_irqrestore(>rq_list_lock, iflags);

if (likely(done)) {
/* Now wake up any sg_read() that is waiting for this
 * packet.
 */
wake_up_interruptible(>read_wait);
kill_fasync(>async_qp, SIGPOLL, POLL_IN);
kref_put(>f_ref, sg_remove_sfp);
} else {
INIT_WORK(>ew.work, sg_rq_end_io_usercontext);
schedule_work(>ew.work);
}

   Since srp->orphan *is* set, we set done to 0 (assuming the
   userspace app has not set keep_orphan via an SG_SET_KEEP_ORPHAN
   ioctl), and therefore we end up scheduling sg_rq_end_io_usercontext()
   to run in a workqueue.

 - In workqueue context we go through sg_rq_end_io_usercontext() ->
   sg_finish_rem_req() -> blk_rq_unmap_user() -> ... ->
   bio_uncopy_user() -> __bio_copy_iov() -> copy_to_user().

   The key point here is that we are doing copy_to_user() on a
   workqueue -- that is, we're on a kernel thread with current->mm
   equal to whatever random previous user process was scheduled before
   this kernel thread.  So we end up copying whatever data the SCSI
   command returned to the virtual address of the buffer passed into
   the original ioctl, but it's quite likely we do this copying into a
   different address space!

As suggested by James Bottomley ,
add a check for current->mm (which is NULL if we're on a kernel thread
without a real userspace address space) in bio_uncopy_user(), and skip
the copy if we're on a kernel thread.

There's no reason that I can think of for any caller of bio_uncopy_user()
to want to do copying on a kernel thread with a random active userspace
address space.

Huge thanks to Costa Sapuntzakis  for the
original pointer to this bug in the sg code.

Signed-off-by: Roland Dreier 
Tested-by: David Milburn 
Cc: Jens Axboe 
Cc: 
Signed-off-by: James Bottomley 
Signed-off-by: Steven Rostedt 
---
 fs/bio.c |   20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/fs/bio.c b/fs/bio.c
index 71072ab..6e2a362 100644
--- a/fs/bio.c
+++ b/fs/bio.c
@@ -791,12 +791,22 @@ static int __bio_copy_iov(struct bio *bio, struct bio_vec 
*iovecs,
 int bio_uncopy_user(struct bio *bio)
 {
struct bio_map_data *bmd = bio->bi_private;
-   int ret = 0;
+   struct bio_vec *bvec;
+   int ret = 0, i;
 
-   if (!bio_flagged(bio, BIO_NULL_MAPPED))
-   ret = __bio_copy_iov(bio, bmd->iovecs, bmd->sgvecs,
-bmd->nr_sgvecs, bio_data_dir(bio) == READ,
-0, bmd->is_our_pages);
+   if (!bio_flagged(bio, BIO_NULL_MAPPED)) {
+   /*
+* if we're in a workqueue, the request is orphaned, so
+* don't copy into a random user address space, just free.
+*/
+   if (current->mm)
+   ret = __bio_copy_iov(bio, bmd->iovecs, bmd->sgvecs,
+bmd->nr_sgvecs, bio_data_dir(bio) 
== READ,
+0, bmd->is_our_pages);
+   else if (bmd->is_our_pages)
+   __bio_for_each_segment(bvec, bio, i, 0)
+ 

[227/251] drivers/platform/olpc/olpc-ec.c: initialise earlier

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Daniel Drake 

[ Upstream commit 93dbc1b3b506e16c1f6d5b5dcfe756a85cb1dc58 ]

Being a low-level component, various drivers (e.g.  olpc-battery) assume
that it is ok to communicate with the OLPC Embedded Controller during
probe.  Therefore the OLPC EC driver must be initialised before other
drivers try to use it.  This was the case until it was recently moved
out of arch/x86 and restructured around commits ac2504151f5a ("Platform:
OLPC: turn EC driver into a platform_driver") and 85f90cf6ca56 ("x86:
OLPC: switch over to using new EC driver on x86").

Use arch_initcall so that olpc-ec is readied earlier, matching the
previous behaviour.

Fixes a regression introduced in Linux-3.6 where various drivers such as
olpc-battery and olpc-xo1-sci failed to load due to an inability to
communicate with the EC.  The user-visible effect was a lack of battery
monitoring, missing ebook/lid switch input devices, etc.

Signed-off-by: Daniel Drake 
Cc: Andres Salomon 
Cc: Paul Fox 
Cc: Thomas Gleixner 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Steven Rostedt 
---
 drivers/platform/olpc/olpc-ec.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/platform/olpc/olpc-ec.c b/drivers/platform/olpc/olpc-ec.c
index 0f9f859..f911952 100644
--- a/drivers/platform/olpc/olpc-ec.c
+++ b/drivers/platform/olpc/olpc-ec.c
@@ -330,7 +330,7 @@ static int __init olpc_ec_init_module(void)
return platform_driver_register(_ec_plat_driver);
 }
 
-module_init(olpc_ec_init_module);
+arch_initcall(olpc_ec_init_module);
 
 MODULE_AUTHOR("Andres Salomon ");
 MODULE_LICENSE("GPL");
-- 
1.7.10.4


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

[232/251] iwlwifi: pcie: disable L1 Active after pci_enable_device

[Steven Rostedt]

3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Emmanuel Grumbach 

[ Upstream commit eabc4ac5d7606a57ee2b7308cb7323ea8f60183b ]

As Arjan pointed out, we mustn't do anything related to PCI
configuration until the device is properly enabled with
pci_enable_device().

Cc: sta...@vger.kernel.org
Reported-by: Arjan van de Ven 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Johannes Berg 
Signed-off-by: Steven Rostedt 
---
 drivers/net/wireless/iwlwifi/pcie/trans.c |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/pcie/trans.c 
b/drivers/net/wireless/iwlwifi/pcie/trans.c
index dbeebef..d7eeb96 100644
--- a/drivers/net/wireless/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/iwlwifi/pcie/trans.c
@@ -2100,16 +2100,16 @@ struct iwl_trans *iwl_trans_pcie_alloc(struct pci_dev 
*pdev,
spin_lock_init(_pcie->irq_lock);
init_waitqueue_head(_pcie->ucode_write_waitq);
 
-   /* W/A - seems to solve weird behavior. We need to remove this if we
-* don't want to stay in L1 all the time. This wastes a lot of power */
-   pci_disable_link_state(pdev, PCIE_LINK_STATE_L0S | PCIE_LINK_STATE_L1 |
-  PCIE_LINK_STATE_CLKPM);
-
if (pci_enable_device(pdev)) {
err = -ENODEV;
goto out_no_pci;
}
 
+   /* W/A - seems to solve weird behavior. We need to remove this if we
+* don't want to stay in L1 all the time. This wastes a lot of power */
+   pci_disable_link_state(pdev, PCIE_LINK_STATE_L0S | PCIE_LINK_STATE_L1 |
+  PCIE_LINK_STATE_CLKPM);
+
pci_set_master(pdev);
 
err = pci_set_dma_mask(pdev, DMA_BIT_MASK(36));
-- 
1.7.10.4


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