Crypto Fixes for 3.10

2013-05-27 Thread Herbert Xu
Hi Linus:

This push fixes a crash in the new sha256_ssse3 driver as well as
a DMA setup/teardown bug in caam.

Please pull from

git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git

or

master.kernel.org:/pub/scm/linux/kernel/git/herbert/crypto-2.6.git


Horia Geanta (1):
  crypto: caam - fix inconsistent assoc dma mapping direction

Jussi Kivilinna (1):
  crypto: sha256_ssse3 - fix stack corruption with SSSE3 and AVX 
implementations

 arch/x86/crypto/sha256-avx-asm.S   |2 +-
 arch/x86/crypto/sha256-ssse3-asm.S |2 +-
 drivers/crypto/caam/caamalg.c  |4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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] drm/tegra: add support for runtime pm

2013-05-27 Thread Terje Bergström
On 27.05.2013 18:45, Thierry Reding wrote:
> On Mon, May 27, 2013 at 07:19:28PM +0530, Mayuresh Kulkarni wrote:
>> +#ifdef CONFIG_PM_RUNTIME
>> +static int host1x_runtime_suspend(struct device *dev)
>> +{
>> +struct host1x *host;
>> +
>> +host = dev_get_drvdata(dev);
>> +if (IS_ERR_OR_NULL(host))
> 
> I think a simple
> 
>   if (!host)
>   return -EINVAL;
> 
> would be enough here. The driver-data of the device should never be an
> ERR_PTR()-encoded value, but either a valid pointer to a host1x object
> or NULL.

True, we should avoid IS_ERR_OR_NULL() like plague. We always know if
the called API returns a NULL on error or an error code. In case of
error code we should just propagate that.

> Same comments apply here. Also I think it might be a good idea to split
> the host1x and gr2d changes into separate patches.

That's a bit tricky, but doable. We just need to enable it for 2D first,
and then host1x to keep bisectability.

>>  static void action_submit_complete(struct host1x_waitlist *waiter)
>>  {
>> +int completed = waiter->count;
>>  struct host1x_channel *channel = waiter->data;
>>  
>> +/* disable clocks for all the submits that got completed in this lot */
>> +while (completed--)
>> +pm_runtime_put(channel->dev);
>> +
>>  host1x_cdma_update(>cdma);
>>  
>> -/*  Add nr_completed to trace */
>> +/* Add nr_completed to trace */
>>  trace_host1x_channel_submit_complete(dev_name(channel->dev),
>>   waiter->count, waiter->thresh);
>> -
>>  }
> 
> This feels hackish. But I can't see any better place to do this. Terje,
> Arto: any ideas how we can do this in a cleaner way? If there's nothing
> better then maybe moving the code into a separate function, say
> host1x_waitlist_complete(), might make this less awkward?

Yeah, it's a bit awkward. action_submit_complete() actually does handle
completion of multiple jobs, and we do one pm_runtime_get() per job.

We could do pm_runtime_put() in host1x_cdma_update(). It anyway goes
through each job that is completed, so while freeing the job it could as
well call runtime PM. That way we could even remove the waiter->count
variable altogether as it's not needed anymore.

The not-so-beautiful aspect is that we do pm_runtime_get() in
host1x_channel.c and pm_runtime_put() in host1x_cdma.c. For code
readability it's be great to have them in the same file. I actually get
questions every now and then because in downstream because of doing
these operations in different files.

Terje
--
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] at91: cleanup (pinctrl macros, defconfigs) for 3.11 #1

2013-05-27 Thread Olof Johansson
On Fri, May 24, 2013 at 06:11:02PM +0200, Nicolas Ferre wrote:
> On 17/05/2013 16:02, Nicolas Ferre :
> >Arnd, Olof,
> >
> >Here is the first AT91 cleanup pull-request for 3.11. I is dominated by a big
> >update of DT files because of the move to macros in pinctrl. As we plan to
> >make this "cleanup" series the base of all our work on AT91 for 3.11, we 
> >would
> >like to see it appearing early in arm-soc and linux-next: this is why we send
> >it to you right now.
> >
> >We have colected the Acked-by from Linus Walleij and we all think that it 
> >makes
> >sense to merge this material through arm-soc tree:
> >- is touches nearly nothing of pinctrl actual code (a header file)
> >- all dtsi/dts modifications for 3.11 will need this as a codebase for 
> >avoiding
> >   merging nightmare
> >
> >I hope that it is okay with you.
> >
> >Thanks, best regards,
> >
> >The following changes since commit f722406faae2d073cc1d01063d1123c35425939e:
> >
> >   Linux 3.10-rc1 (2013-05-11 17:14:08 -0700)
> >
> >are available in the git repository at:
> >
> >   git://github.com/at91linux/linux-at91.git tags/at91-cleanup
> 
> Arnd, Olof,
> 
> After having sent the second "fixes" pull-request to you, I want to
> warn you about merging conflicts concerning this "cleanup"
> pull-request for 3.11.
> 
> 2 merging conflicts are appearing when placing the "cleanup" branch
> on top of the "fixes" material contained today in at91-fixes tag.
> To address this, I have pushed a resolution branch on our usual git tree:
> 
> git://github.com/at91linux/linux-at91.git   at91-3.11-cleanup1+resolved
> 
> In case of any question, please let me know. If you want me to
> rebase the original tag that I've sent you, I can do it as well.

Hi,

Thanks, not a big deal for us to resolve so that's ok.

Pulled in the branch. Some comments below:


> >
> >Big update with pinctrl by use of macros and
> >header files. Increases readability and avoid
> >typos.
> >Update of AT91 defconfigs and merge of defconfigs for
> >SoC look-alike:
> >sam9260/9g20 and sam9261/9g10.

This is hard to follow, please structure them better in the future.

> >
> >Jean-Christophe PLAGNIOL-VILLARD (6):
> >   ARM: at91: dt: use #include for all device trees
> >   ARM: at91: dt: switch to standard GPIO flag defines.
> >   ARM: at91: dt: add pinctrl pre-processor define
> >   ARM: at91: dt: switch to pinctrl to pre-processor
> >   ARM: at91: dt: switch to standard IRQ flag defines
> >   ARM: at91: udpate defconfigs

Typo in the patch subject, please keep an eye on these in the future.

> >  arch/arm/configs/at91_dt_defconfig |  55 ++-
> >  arch/arm/configs/at91rm9200_defconfig  | 218 ++---
> >  ...am9g20_defconfig => at91sam9260_9g20_defconfig} |  67 ++-
> >  arch/arm/configs/at91sam9260_defconfig |  91 
> >  ...am9261_defconfig => at91sam9261_9g10_defconfig} |  19 +-
> >  arch/arm/configs/at91sam9263_defconfig |  39 +-
> >  arch/arm/configs/at91sam9g45_defconfig |  94 ++--
> >  arch/arm/configs/sama5_defconfig   |  35 +-
> >  arch/arm/mach-at91/Kconfig.non_dt  | 159 +++
> >  arch/arm/mach-at91/Makefile|   2 -
> >  arch/arm/mach-at91/board-sam9261ek.c   |  28 +-
> >  include/dt-bindings/pinctrl/at91.h |  35 ++
> >  63 files changed, 1407 insertions(+), 1617 deletions(-)
> >  rename arch/arm/configs/{at91sam9g20_defconfig => 
> > at91sam9260_9g20_defconfig} (67%)
> >  delete mode 100644 arch/arm/configs/at91sam9260_defconfig
> >  rename arch/arm/configs/{at91sam9261_defconfig => 
> > at91sam9261_9g10_defconfig} (91%)
> >  create mode 100644 include/dt-bindings/pinctrl/at91.h

Good to see consolidation, it'd be awesome if there could be even more.


-Olof
--
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/2] Clock changes for supporting CPUFreq on Exynos5250

2013-05-27 Thread Tushar Behera
On 05/17/2013 11:25 AM, Tushar Behera wrote:
> With the use of common clock framework, CPUFreq driver on EXYNOS5250 now
> requires a few changes in clocks.
> 
> Tested on Exynos5250 based Arndale board.
> The patches are based on v3.10-rc1.
> 
> Tushar Behera (2):
>   clk: exynos5250: Update cpufreq related clocks for EXYNOS5250
>   clk: exynos5250: Add sclk_mpll to the parent list of mout_cpu clock
> 
>  drivers/clk/samsung/clk-exynos5250.c |8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 

Any comments on this series?

-- 
Tushar Behera
--
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 v2] usb: dwc3: use extcon fwrk to receive connect/disconnect notification

2013-05-27 Thread Kishon Vijay Abraham I

On Tuesday 28 May 2013 07:54 AM, Chanwoo Choi wrote:

On 05/27/2013 10:35 PM, Kishon Vijay Abraham I wrote:

Modified dwc3-omap to receive connect and disconnect notification using
extcon framework. Also did the necessary cleanups required after
adapting to extcon framework.

Signed-off-by: Kishon Vijay Abraham I 
Acked-by: Chanwoo Choi 
---
Changes from v1:
* regulator enable/disable is now done here instead of palmas-usb as some users
of palmas-usb wont need regulator.
  drivers/usb/dwc3/dwc3-omap.c  | 103 ++
  include/linux/usb/dwc3-omap.h |  30 
  2 files changed, 85 insertions(+), 48 deletions(-)
  delete mode 100644 include/linux/usb/dwc3-omap.h

I think that usb or other maintainer have to confirm this patch
for applying extcon-next branch.


Ok. I'll check with Felipe.

Thanks
Kishon
--
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: [RFC PATCH 1/4] arm: omap: Add phy binding info for musb in plat data

2013-05-27 Thread Kishon Vijay Abraham I

Hi Tony,

On Friday 17 May 2013 06:52 PM, Kishon Vijay Abraham I wrote:

In order for controllers to get PHY in case of non dt boot, the phy
binding information (phy label) should be added in the platform
data of the controller.


This series would be needed to get MUSB working in OMAP3 boards for 
non-dt boot case. Do you think this is good enough to go in this rc cycle?


Thanks
Kishon
--
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/


[RFC PATCH] sched: smart wake-affine

2013-05-27 Thread Michael Wang
wake-affine stuff is always trying to pull wakee close to waker, by theory,
this will bring benefit if waker's cpu cached hot data for wakee, or the
extreme ping-pong case.

And testing show it could benefit hackbench 15% at most.

However, the whole stuff is somewhat blindly and time-consuming, some
workload therefore suffer.

And testing show it could damage pgbench 50% at most.

Thus, wake-affine stuff should be smarter, and realise when to stop
it's thankless effort.

This patch introduced per task 'nr_wakee_switch', which will be increased
each time the task switch it's wakee.

So a high 'nr_wakee_switch' means the task has more than one wakee, and
less the wakee number, higher the wakeup frequency.

Now when making the decision on whether to pull or not, pay attention on
the wakee with a high 'nr_wakee_switch', pull such task may benefit wakee,
but that imply waker will face cruel competition later, it could be very
crule or very fast depends on the story behind 'nr_wakee_switch', whatever,
waker therefore suffer.

Furthermore, if waker also has a high 'nr_wakee_switch', that imply multiple
tasks rely on it, waker's higher latency will damage all those tasks, pull
wakee in such cases seems to be a bad deal.

Thus, when 'waker->nr_wakee_switch / wakee->nr_wakee_switch' become higher
and higher, the deal seems to be worse and worse.

This patch therefore help wake-affine stuff to stop it's work when:

wakee->nr_wakee_switch > factor &&
waker->nr_wakee_switch > (factor * wakee->nr_wakee_switch)

The factor here is the online cpu number, so more cpu will lead to more pull
since the trial become more severe.

After applied the patch, pgbench show 42% improvement at most.

Test:
Test with 12 cpu X86 server and tip 3.10.0-rc1.

basesmart

| db_size | clients |  tps  | |  tps  |
+-+-+---+ +---+
| 21 MB   |   1 | 10749 | | 10337 |
| 21 MB   |   2 | 21382 | | 21391 |
| 21 MB   |   4 | 41570 | | 41808 |
| 21 MB   |   8 | 52828 | | 58792 |
| 21 MB   |  12 | 48447 | | 54553 |
| 21 MB   |  16 | 46246 | | 56726 | +22.66%
| 21 MB   |  24 | 43850 | | 56853 | +29.65%
| 21 MB   |  32 | 43455 | | 55846 | +28.51%
| 7483 MB |   1 |  9290 | |  8848 |
| 7483 MB |   2 | 19347 | | 19351 |
| 7483 MB |   4 | 37135 | | 37511 |
| 7483 MB |   8 | 47310 | | 50210 |
| 7483 MB |  12 | 42721 | | 49396 |
| 7483 MB |  16 | 41016 | | 51826 | +26.36%
| 7483 MB |  24 | 37540 | | 52579 | +40.06%
| 7483 MB |  32 | 36756 | | 51332 | +39.66%
| 15 GB   |   1 |  8758 | |  8670 |
| 15 GB   |   2 | 19204 | | 19249 |
| 15 GB   |   4 | 36997 | | 37199 |
| 15 GB   |   8 | 46578 | | 50681 |
| 15 GB   |  12 | 42141 | | 48671 |
| 15 GB   |  16 | 40518 | | 51280 | +26.56%
| 15 GB   |  24 | 36788 | | 52329 | +42.24%
| 15 GB   |  32 | 36056 | | 50350 | +39.64%



CC: Ingo Molnar 
CC: Peter Zijlstra 
CC: Mike Galbraith 
Signed-off-by: Michael Wang 
---
 include/linux/sched.h |3 +++
 kernel/sched/fair.c   |   45 +
 2 files changed, 48 insertions(+), 0 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 178a8d9..1c996c7 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1041,6 +1041,9 @@ struct task_struct {
 #ifdef CONFIG_SMP
struct llist_node wake_entry;
int on_cpu;
+   struct task_struct *last_wakee;
+   unsigned long nr_wakee_switch;
+   unsigned long last_switch_decay;
 #endif
int on_rq;
 
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index f62b16d..eaaceb7 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3127,6 +3127,45 @@ static inline unsigned long effective_load(struct 
task_group *tg, int cpu,
 
 #endif
 
+static void record_wakee(struct task_struct *p)
+{
+   /*
+* Rough decay, don't worry about the boundary, really active
+* task won't care the loose.
+*/
+   if (jiffies > current->last_switch_decay + HZ) {
+   current->nr_wakee_switch = 0;
+   current->last_switch_decay = jiffies;
+   }
+
+   if (current->last_wakee != p) {
+   current->last_wakee = p;
+   current->nr_wakee_switch++;
+   }
+}
+
+static int nasty_pull(struct task_struct *p)
+{
+   int factor = cpumask_weight(cpu_online_mask);
+
+   /*
+* Yeah, it's the switching-frequency, could means many wakee or
+* rapidly switch, use factor here will just help to automatically
+* adjust the loose-degree, so more cpu will lead to more pull.
+*/
+   if (p->nr_wakee_switch > factor) {
+   /*
+* wakee is 

Re: [PATCH v2] sched: wake-affine throttle

2013-05-27 Thread Michael Wang
On 05/22/2013 10:55 PM, Mike Galbraith wrote:
> On Wed, 2013-05-22 at 17:25 +0800, Michael Wang wrote:
> 
>> I've not test the hackbench with wakeup-buddy before, will do it this
>> time, I suppose the 15% illegal income will suffered, anyway, it's
>> illegal :)
> 
> On a 4 socket 40 core (+SMT) box, hackbench wasn't too happy.

I've done more test and now I got the reason of regression...

The writer and reader in hackbench is N:N, prev writer will write all
the fd then switch to next writer and repeat the same work, so it's
impossible to setup the buddy relationship by just record the last one,
and we have to record all the waker/wakee in history, but that means
unacceptable memory overhead...

So this buddy idea seems to be bad...

I think a better way may should be allowing pull in most time, but
filter the very bad cases carefully.

For workload like pgbench, we actually just need to avoid pull if that
will damage the 'mother' thread, which is busy and be relied by many
'child'.

I will send out a new implementation, let's see whether it could solve
the problems ;-)

Regards,
Michael Wang

> 
> defaultx = wakeup buddy
> 
> tbench 30 localhost
>  1   5   10   20   40   80  
> 160  320
> 3.10.0-default  188.13  953.03  1860.03  3180.93  5378.34 10826.06 
> 11342.90 11651.30
> 3.10.0-defaultx 187.26  934.55  1859.30  3160.29  5016.35 12477.15 
> 12567.05 12068.47
> 
> hackbench -l 400 -g 400
> 3.10.0-default Time: 3.9194.250 4.116
> 3.10.0-defaultxTime: 9.074   10.985 9.849
> 
> aim7 compute
> AIM Multiuser Benchmark - Suite VII "1.1"   3.10.0-default AIM 
> Multiuser Benchmark - Suite VII "1.1"   3.10.0-defaultx
> 
> Tasks   Jobs/MinJTI RealCPU Jobs/sec/task  Tasks   
> Jobs/MinJTI RealCPU Jobs/sec/task
> 1   428.0   100 14.24.1 7.1328 1   
> 428.9   100 14.14.1 7.1479
> 1   417.9   100 14.54.1 6.9655 1   
> 430.4   100 14.14.0 7.1733
> 1   427.7   100 14.24.2 7.1277 1   
> 424.7   100 14.34.2 7.0778
> 5   2350.7  99  12.913.87.8355 5   
> 2156.6  99  14.119.87.1886
> 5   2422.1  99  12.512.18.0735 5   
> 2155.0  99  14.119.77.1835
> 5   2189.3  98  13.818.37.2977 5   
> 2108.6  99  14.421.47.0285
> 10  4515.6  93  13.427.67.5261 10  
> 4529.1  96  13.429.57.5486
> 10  4708.6  96  12.924.37.8477 10  
> 4597.9  96  13.226.97.6631
> 10  4636.6  96  13.125.77.7276 10  
> 5197.3  98  11.714.88.6621
> 20  8053.2  95  15.178.16.7110 20  
> 9431.9  98  12.849.17.8599
> 20  8250.5  92  14.767.56.8754 20  
> 7973.7  97  15.293.46.6447
> 20  8178.1  97  14.878.56.8151 20  
> 8145.2  95  14.978.46.7876
> 40  17413.8 94  13.988.67.2557 40  
> 16312.2 92  14.9115.6   6.7968
> 40  16775.1 93  14.5111.6   6.9896 40  
> 17070.4 94  14.2110.6   7.1127
> 40  16031.7 93  15.1147.1   6.6799 40  
> 17578.0 94  13.896.97.3241
> 80  33666.7 95  14.4138.4   7.0139 80  
> 33854.7 96  14.3177.9   7.0531
> 80  33949.6 97  14.3128.0   7.0728 80  
> 34164.9 96  14.2146.4   7.1177
> 80  35752.2 96  13.6159.1   7.4484 80  
> 33807.5 96  14.3127.6   7.0432
> 160 74814.8 98  13.0149.8   7.7932 160 
> 75162.8 98  12.9148.6   7.8295
> 160 74015.3 97  13.1149.5   7.7099 160 
> 74642.0 98  13.0168.2   7.7752
> 160 73621.9 98  13.2146.3   7.6689 160 
> 75572.9 98  12.8163.6   7.8722
> 320 139210.396  13.9280.1   7.2505 320 
> 139010.897  14.0282.4   7.2401
> 320 135135.996  14.3277.8   7.0383 320 
> 139611.296  13.9282.2   7.2714
> 320 139110.596  13.9280.4   7.2453 320 
> 138514.397  14.0281.0   7.2143
> 640 223538.998  17.4577.2   5.8213 640 

Re: [PATCH] arch: xtensa: include: asm: compiling issue, need cmpxchg64() defined.

2013-05-27 Thread Chen Gang
On 05/28/2013 12:19 AM, Max Filippov wrote:
> On Mon, May 27, 2013 at 3:57 PM, Chen Gang  wrote:
>>
>> When compiling with 'allmodconfig', some of drivers need cmpxchg64(),
>> xtensa does not supply 64-bit implementation for 'xchg', so use the
>> 'generic' implementation.
>>
>> e.g. (for next-20130527 tree):
>>   drivers/block/blockconsole.c:164:2: error: implicit declaration of 
>> function ‘cmpxchg64’ [-Werror=implicit-function-declaration]
>>
>> Signed-off-by: Chen Gang 
>> ---
>>  arch/xtensa/include/asm/cmpxchg.h |1 +
>>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> Taken to the xtensa-fixes tree. Thanks.
> 

Thank you too.

-- 
Chen Gang

Asianux Corporation
--
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 v2] video: simplefb: add mode parsing function

2013-05-27 Thread Alexandre Courbot
On Tue, May 28, 2013 at 1:13 PM, Stephen Warren  wrote:
> On 05/26/2013 09:53 PM, Alexandre Courbot wrote:
>> The naming scheme of simplefb's mode is precise enough to allow building
>> the mode structure from it instead of using a static list of modes. This
>> patch introduces a function that does this. In case exotic modes that
>> cannot be represented from their name alone are needed, the static list
>> of modes is still available as a backup.
>>
>> It also changes the order in which colors are declared from MSB first to
>> the more standard LSB first.
>>
>> Signed-off-by: Alexandre Courbot 
>> ---
>> Changes from v1:
>> - amended documentation following Stephen's suggestion
>> - allow parsing of bitfields larger than 9 bits
>> - made it clear that the parsing order of bits is changed with respect
>>   to the original patch
>>
>> Andrew, since this patch introduces a (small) change in the DT bindings,
>> could we try to merge it during the -rc cycle so we don't have to come
>> with a more complex solution in the future?
>
> So, I think we shouldn't change the DT binding at all now. The original
> driver is now merged for 3.10, and I think it's far too late to take
> code that implements new features for 3.10. This means that we couldn't
> merge this patch until 3.11. However, by then, we shouldn't be changing
> the DT binding in incompatible ways. Olof has already published some
> U-Boot binaries that use the current binding, and on IRC indicated he'd
> prefer not to change the binding because of that.
>
> As such, we should either:
>
> a) Just add new entries into the format array that already exists in the
> driver. Given David's response, this might be simplest.
>
> b) Extend the DT binding in a 100% backwards-compatible way, which would
> mean defaulting the bit-order to match the existing 1 format, and adding
> a new Boolean property to indicate that the format string is specified
> in the other order.

a) is definitely simpler, so let's do that and drop this patch. Sorry
about the noise.

Alex.
--
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/


[PATCH v2 2/4] mfd: 88pm800: remove "IRQF_TRIGGER_FALLING" flag

2013-05-27 Thread yizhang.mrvl
From: Yi Zhang 

for interrupt controller such as GIC who is level triggered,
"IRQF_TRIGGER_FALLING" will fail to request irq

Signed-off-by: Yi Zhang 
---
 drivers/mfd/88pm800.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
index bbb6aa8..618a6b9 100644
--- a/drivers/mfd/88pm800.c
+++ b/drivers/mfd/88pm800.c
@@ -318,7 +318,7 @@ out:
 static int device_irq_init_800(struct pm80x_chip *chip)
 {
struct regmap *map = chip->regmap;
-   unsigned long flags = IRQF_TRIGGER_FALLING | IRQF_ONESHOT;
+   unsigned long flags = IRQF_ONESHOT;
int data, mask, ret = -EINVAL;
 
if (!map || !chip->irq) {
-- 
1.7.4.1

--
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/


[PATCH v2 4/4] mfd: 88pm800: add regulator support

2013-05-27 Thread yizhang.mrvl
From: Yi Zhang 

Signed-off-by: Yi Zhang 
---
 drivers/mfd/88pm800.c   |  108 +++
 include/linux/mfd/88pm80x.h |   48 +++
 2 files changed, 156 insertions(+), 0 deletions(-)

diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
index 2c68cbc..477295f 100644
--- a/drivers/mfd/88pm800.c
+++ b/drivers/mfd/88pm800.c
@@ -167,6 +167,62 @@ static struct mfd_cell onkey_devs[] = {
 },
 };
 
+static struct resource regulator_resources[] = {
+   {PM800_ID_BUCK1, PM800_ID_BUCK1, "buck-1", IORESOURCE_IO,},
+   {PM800_ID_BUCK2, PM800_ID_BUCK2, "buck-2", IORESOURCE_IO,},
+   {PM800_ID_BUCK3, PM800_ID_BUCK3, "buck-3", IORESOURCE_IO,},
+   {PM800_ID_BUCK4, PM800_ID_BUCK4, "buck-4", IORESOURCE_IO,},
+   {PM800_ID_BUCK5, PM800_ID_BUCK5, "buck-5", IORESOURCE_IO,},
+   {PM800_ID_LDO1, PM800_ID_LDO1, "ldo-01", IORESOURCE_IO,},
+   {PM800_ID_LDO2, PM800_ID_LDO2, "ldo-02", IORESOURCE_IO,},
+   {PM800_ID_LDO3, PM800_ID_LDO3, "ldo-03", IORESOURCE_IO,},
+   {PM800_ID_LDO4, PM800_ID_LDO4, "ldo-04", IORESOURCE_IO,},
+   {PM800_ID_LDO5, PM800_ID_LDO5, "ldo-05", IORESOURCE_IO,},
+   {PM800_ID_LDO6, PM800_ID_LDO6, "ldo-06", IORESOURCE_IO,},
+   {PM800_ID_LDO7, PM800_ID_LDO7, "ldo-07", IORESOURCE_IO,},
+   {PM800_ID_LDO8, PM800_ID_LDO8, "ldo-08", IORESOURCE_IO,},
+   {PM800_ID_LDO9, PM800_ID_LDO9, "ldo-09", IORESOURCE_IO,},
+   {PM800_ID_LDO10, PM800_ID_LDO10, "ldo-10", IORESOURCE_IO,},
+   {PM800_ID_LDO11, PM800_ID_LDO11, "ldo-11", IORESOURCE_IO,},
+   {PM800_ID_LDO12, PM800_ID_LDO12, "ldo-12", IORESOURCE_IO,},
+   {PM800_ID_LDO13, PM800_ID_LDO13, "ldo-13", IORESOURCE_IO,},
+   {PM800_ID_LDO14, PM800_ID_LDO14, "ldo-14", IORESOURCE_IO,},
+   {PM800_ID_LDO15, PM800_ID_LDO15, "ldo-15", IORESOURCE_IO,},
+   {PM800_ID_LDO16, PM800_ID_LDO16, "ldo-16", IORESOURCE_IO,},
+   {PM800_ID_LDO17, PM800_ID_LDO17, "ldo-17", IORESOURCE_IO,},
+   {PM800_ID_LDO18, PM800_ID_LDO18, "ldo-18", IORESOURCE_IO,},
+   {PM800_ID_LDO19, PM800_ID_LDO19, "ldo-19", IORESOURCE_IO,},
+};
+
+static struct mfd_cell regulator_devs[] = {
+   {"88pm80x-regulator", 0,},
+   {"88pm80x-regulator", 1,},
+   {"88pm80x-regulator", 2,},
+   {"88pm80x-regulator", 3,},
+   {"88pm80x-regulator", 4,},
+   {"88pm80x-regulator", 5,},
+   {"88pm80x-regulator", 6,},
+   {"88pm80x-regulator", 7,},
+   {"88pm80x-regulator", 8,},
+   {"88pm80x-regulator", 9,},
+   {"88pm80x-regulator", 10,},
+   {"88pm80x-regulator", 11,},
+   {"88pm80x-regulator", 12,},
+   {"88pm80x-regulator", 13,},
+   {"88pm80x-regulator", 14,},
+   {"88pm80x-regulator", 15,},
+   {"88pm80x-regulator", 16,},
+   {"88pm80x-regulator", 17,},
+   {"88pm80x-regulator", 18,},
+   {"88pm80x-regulator", 19,},
+   {"88pm80x-regulator", 20,},
+   {"88pm80x-regulator", 21,},
+   {"88pm80x-regulator", 22,},
+   {"88pm80x-regulator", 23,},
+};
+
+static struct regulator_init_data regulator_pdata[ARRAY_SIZE(regulator_devs)];
+
 static const struct regmap_irq pm800_irqs[] = {
/* INT0 */
[PM800_IRQ_ONKEY] = {
@@ -315,6 +371,52 @@ out:
return ret;
 }
 
+static int device_regulator_init(struct pm80x_chip *chip,
+  struct pm80x_platform_data *pdata)
+{
+   struct regulator_init_data *initdata;
+   int ret = 0;
+   int i, seq;
+
+   if (!pdata || !pdata->regulator) {
+   dev_warn(chip->dev, "Regulator pdata is unavailable!\n");
+   return 0;
+   }
+
+   if (pdata->num_regulators > ARRAY_SIZE(regulator_devs))
+   pdata->num_regulators = ARRAY_SIZE(regulator_devs);
+
+   for (i = 0; i < pdata->num_regulators; i++) {
+   initdata = >regulator[i];
+   seq = *(unsigned int *)initdata->driver_data;
+   if ((seq < 0) || (seq > PM800_ID_RG_MAX)) {
+   dev_err(chip->dev, "Wrong ID(%d) on regulator(%s)\n",
+   seq, initdata->constraints.name);
+   ret = -EINVAL;
+   goto out_err;
+   }
+   memcpy(_pdata[i], >regulator[i],
+  sizeof(struct regulator_init_data));
+   regulator_devs[i].platform_data = _pdata[i];
+   regulator_devs[i].pdata_size =
+   sizeof(struct regulator_init_data);
+   regulator_devs[i].num_resources = 1;
+   regulator_devs[i].resources = _resources[seq];
+
+   ret = mfd_add_devices(chip->dev, 0, _devs[i], 1,
+ _resources[seq], 0, NULL);
+   if (ret < 0) {
+   dev_err(chip->dev, "Failed to add regulator subdev\n");
+   goto out_err;
+   }
+   }
+
+   return 0;
+
+out_err:
+   return ret;
+}
+

[PATCH v2 1/4] mfd: 88pm800: fix NULL pointer error

2013-05-27 Thread yizhang.mrvl
From: Yi Zhang 

move "device_800_init" to fix NULL pointer error when
calling "device_gpadc_init"

for "device_gpadc_init" needs "subchip->regmap_gpadc"
to set registers via regmap interface

Signed-off-by: Yi Zhang 
---
 drivers/mfd/88pm800.c |   16 
 1 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
index 582bda5..bbb6aa8 100644
--- a/drivers/mfd/88pm800.c
+++ b/drivers/mfd/88pm800.c
@@ -528,25 +528,25 @@ static int pm800_probe(struct i2c_client *client,
subchip->gpadc_page_addr = pdata->gpadc_page_addr;
chip->subchip = subchip;
 
-   ret = device_800_init(chip, pdata);
-   if (ret) {
-   dev_err(chip->dev, "%s id 0x%x failed!\n", __func__, chip->id);
-   goto err_subchip_alloc;
-   }
-
ret = pm800_pages_init(chip);
if (ret) {
dev_err(>dev, "pm800_pages_init failed!\n");
goto err_page_init;
}
 
+   ret = device_800_init(chip, pdata);
+   if (ret) {
+   dev_err(chip->dev, "%s id 0x%x failed!\n", __func__, chip->id);
+   goto err_subchip_alloc;
+   }
+
if (pdata->plat_config)
pdata->plat_config(chip, pdata);
 
-err_page_init:
+err_subchip_alloc:
mfd_remove_devices(chip->dev);
device_irq_exit_800(chip);
-err_subchip_alloc:
+err_page_init:
pm80x_deinit();
 out_init:
return ret;
-- 
1.7.4.1

--
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: [RFC PATCH v2, part3 00/11] Introduce PCI bus lock and state machine

2013-05-27 Thread Yinghai Lu
On Wed, May 22, 2013 at 2:48 AM, Gu Zheng  wrote:
> On 05/16/2013 11:50 PM, Jiang Liu wrote:
> We're gladly to see the new patch-set, and I tested all the whole 3 
> parts
> patch-set on the latest kernel tree. Because of the limitation of our test 
> environment,
> we only use the method *1* to trigger PCI hotplug concurrently, and it works 
> well.
>
> Though I'm not sure whether the way you introduced is the best one to solve 
> these
> race condition issues, but it does fix the concurrent PCI hotplug(via sysfs)
> issues that disturb us.

Not sure what happened, at lease after Jiang's first patch, we should still need
https://patchwork.kernel.org/patch/2562431/
 [1/7] PCI: move back pci_proc_attach_devices calling
https://patchwork.kernel.org/patch/2562461/
 [2/7] PCI: move resources and bus_list releasing to pci_release_dev
https://patchwork.kernel.org/patch/2562451/
 [3/7] PCI: Detach driver in pci_stop_device

they will allow pci_stop_and_remove_bus_device is called two times in the
your case.

this one is not needed.
https://patchwork.kernel.org/patch/2562561/
  [4/7] PCI: Fix racing for pci device removing via sysfs
it should be the same as the two pci_alloc_dev patches.

other three are about sriov one

Thanks

Yinghai
--
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/


[PATCH v2 3/4] mfd: 88pm800: fix probe bug

2013-05-27 Thread yizhang.mrvl
From: Yi Zhang 

1) return 0 when probe function is successful
2) fine-tune pm800_pages_init()

Signed-off-by: Yi Zhang 
---
 drivers/mfd/88pm800.c |   29 +
 1 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
index 618a6b9..2c68cbc 100644
--- a/drivers/mfd/88pm800.c
+++ b/drivers/mfd/88pm800.c
@@ -369,32 +369,43 @@ static int pm800_pages_init(struct pm80x_chip *chip)
struct pm80x_subchip *subchip;
struct i2c_client *client = chip->client;
 
+   int ret = -ENODEV;
+
subchip = chip->subchip;
/* PM800 block power: i2c addr 0x31 */
-   if (subchip->power_page_addr) {
+   if (subchip && (subchip->power_page_addr)) {
subchip->power_page =
i2c_new_dummy(client->adapter, subchip->power_page_addr);
subchip->regmap_power =
devm_regmap_init_i2c(subchip->power_page,
 _regmap_config);
i2c_set_clientdata(subchip->power_page, chip);
-   } else
+   } else {
dev_info(chip->dev,
 "PM800 block power 0x31: No power_page_addr\n");
+   return ret;
+   }
 
/* PM800 block GPADC: i2c addr 0x32 */
-   if (subchip->gpadc_page_addr) {
+   if (subchip && (subchip->gpadc_page_addr)) {
subchip->gpadc_page = i2c_new_dummy(client->adapter,
subchip->gpadc_page_addr);
subchip->regmap_gpadc =
devm_regmap_init_i2c(subchip->gpadc_page,
 _regmap_config);
i2c_set_clientdata(subchip->gpadc_page, chip);
-   } else
+   } else {
dev_info(chip->dev,
 "PM800 block GPADC 0x32: No gpadc_page_addr\n");
+   goto out_gpadc_page;
+   }
 
return 0;
+
+out_gpadc_page:
+   regmap_exit(subchip->regmap_power);
+   i2c_unregister_device(subchip->power_page);
+   return ret;
 }
 
 static void pm800_pages_exit(struct pm80x_chip *chip)
@@ -537,16 +548,18 @@ static int pm800_probe(struct i2c_client *client,
ret = device_800_init(chip, pdata);
if (ret) {
dev_err(chip->dev, "%s id 0x%x failed!\n", __func__, chip->id);
-   goto err_subchip_alloc;
+   goto err_800_init;
}
 
if (pdata->plat_config)
pdata->plat_config(chip, pdata);
 
-err_subchip_alloc:
-   mfd_remove_devices(chip->dev);
-   device_irq_exit_800(chip);
+   return 0;
+
+err_800_init:
+   pm800_pages_exit(chip);
 err_page_init:
+err_subchip_alloc:
pm80x_deinit();
 out_init:
return ret;
-- 
1.7.4.1

--
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/


[PATCH v2 0/4] mfd: 88pm800: bug fix and regulator support

2013-05-27 Thread yizhang.mrvl
From: Yi Zhang 

v2: fix an "&&" usage error of "mfd: 88pm800: fix probe bug" in v1

Yi Zhang (4):
  mfd: 88pm800: fix NULL pointer error
  mfd: 88pm800: remove "IRQF_TRIGGER_FALLING" flag
  mfd: 88pm800: fix probe bug
  mfd: 88pm800: add regulator support

 drivers/mfd/88pm800.c   |  147 +++
 include/linux/mfd/88pm80x.h |   48 ++
 2 files changed, 182 insertions(+), 13 deletions(-)

-- 
1.7.4.1

--
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 v2] skbuff: Hide GFP_ATOMIC page allocation failures for dropped packets

2013-05-27 Thread Joe Perches
On Mon, 2013-05-27 at 15:25 -0700, Eric Dumazet wrote:
> On Mon, 2013-05-27 at 13:39 -0400, Rik van Riel wrote:
> > On 05/26/2013 04:19 PM, atom...@redhat.com wrote:
> > > Failed GFP_ATOMIC allocations by the network stack result in dropped
> > > packets, which will be received on a subsequent retransmit, and an
> > > unnecessary, noisy warning with a kernel backtrace.
> 
> This claim is wrong, only some protocols deal with retransmits.
> 
> > > These warnings are harmless, but they still cause users to panic and
> > > file bug reports over dropped packets. It would be better to hide the
> > > failed allocation warnings and backtraces, and let retransmits handle
> > > dropped packets quietly.
> > 
> > Yes please. Getting memory management bug reports for
> > dropped network packets got old years ago.  Lets get
> > rid of those messages.
> 
> I am only wondering why this path has anything needing special
> attention, over thousands of kmalloc() like call sites in the kernel.

I don't think this site is particularly special.

> If mm allocation warnings are useless, just make __GFP_NOWARN the
> default, and save us thousand of patches (adding the __GFP_NOWARN
> everywhere)
> 
> Truth is : some network drivers don't deal very well with allocation
> errors. mlx4 for example absolutely wants order-2 pages in RX path, with
> no fallback to order-0 pages.
> 
> So I am not against this patch, but I can not really acknowledge it,
> sorry.

I think the __alloc_skb alloc failure message is ok,
but maybe there shouldn't be something "scary" like
a dump_stack.

Maybe this site should use a trivial debug error
message like below instead.
---
 net/core/skbuff.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index d629891..0154803 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -231,17 +231,24 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t 
gfp_mask,
struct sk_buff *skb;
u8 *data;
bool pfmemalloc;
+   bool warn_no_skb = !(gfp_mask & __GFP_NOWARN);
 
cache = (flags & SKB_ALLOC_FCLONE)
? skbuff_fclone_cache : skbuff_head_cache;
 
if (sk_memalloc_socks() && (flags & SKB_ALLOC_RX))
-   gfp_mask |= __GFP_MEMALLOC;
+   gfp_mask |= __GFP_MEMALLOC | __GFP_NOWARN;
 
/* Get the HEAD */
skb = kmem_cache_alloc_node(cache, gfp_mask & ~__GFP_DMA, node);
-   if (!skb)
+   if (!skb) {
+   if (warn_no_skb)
+   printk_ratelimited(KERN_DEBUG "%s: OOM from %pF via 
%pF\n",
+  __func__,
+  __builtin_return_address(0),
+  __builtin_return_address(1));
goto out;
+   }
prefetchw(skb);
 
/* We do our best to align skb_shared_info on a separate cache


--
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, part2 01/20] PCI: introduce hotplug-safe PCI bus iterators

2013-05-27 Thread Yinghai Lu
On Sun, May 26, 2013 at 8:52 AM, Jiang Liu  wrote:
> Introduce hotplug-safe PCI bus iterators as below, which hold a
> reference on the returned PCI bus object.
> bool pci_bus_exists(int domain, int busnr);
> struct pci_bus *pci_get_bus(int domain, int busnr);
> struct pci_bus *pci_get_next_bus(struct pci_bus *from);
> struct pci_bus *pci_get_next_root_bus(struct pci_bus *from);
> #define for_each_pci_bus(b) for (b = NULL; (b = pci_get_next_bus(b)); )
> #define for_each_pci_root_bus(b)  \
> for (b = NULL; (b = pci_get_next_root_bus(b)); )
>
> The long-term goal is to remove hotplug-unsafe pci_find_bus(),
> pci_find_next_bus() and the global pci_root_buses list.
>
> These new interfaces may be a littler slower than existing interfaces,
> but it should be acceptable because they are not used on hot paths.

looks like go over all buses to find out several root buses is not good.


>
> Signed-off-by: Jiang Liu 
> Acked-by: Yinghai Lu 

I take that back.

> Cc: linux-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  drivers/pci/pci.h|   1 +
>  drivers/pci/probe.c  |   2 +-
>  drivers/pci/search.c | 159 
> +--
>  include/linux/pci.h  |  23 +++-
>  4 files changed, 153 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
> index 68678ed..8fe15f6 100644
> --- a/drivers/pci/pci.h
> +++ b/drivers/pci/pci.h
> @@ -126,6 +126,7 @@ static inline void pci_remove_legacy_files(struct pci_bus 
> *bus) { return; }
>
>  /* Lock for read/write access to pci device and bus lists */
>  extern struct rw_semaphore pci_bus_sem;
> +extern struct class pcibus_class;
>
>  extern raw_spinlock_t pci_lock;
>
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 2830070..1004a05 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -93,7 +93,7 @@ static void release_pcibus_dev(struct device *dev)
> kfree(pci_bus);
>  }
>
> -static struct class pcibus_class = {
> +struct class pcibus_class = {
> .name   = "pci_bus",
> .dev_release= _pcibus_dev,
> .dev_attrs  = pcibus_dev_attrs,
...
> +static int pci_match_next_root_bus(struct device *dev, const void *data)
> +{
> +   return pci_is_root_bus(to_pci_bus(dev));
>  }
...
> +
> +/**
> + * pci_find_next_root_bus - begin or continue searching for a PCI root bus
> + * @from: Previous PCI bus found, or %NULL for new search.
> + *
> + * Iterates through the list of known PCI root busses. If a PCI bus is found,
> + * the reference count to the root bus is incremented and a pointer to it is
> + * returned. Otherwise, %NULL is returned. A new search is initiated by
> + * passing %NULL as the @from argument. Otherwise if @from is not %NULL,
> + * searches continue from next root bus on the global list. The reference
> + * count for @from is always decremented if it is not %NULL.
> + */
> +struct pci_bus *pci_get_next_root_bus(struct pci_bus *from)
> +{
> +   struct device *dev = from ? >dev : NULL;
> +
> +   WARN_ON(in_interrupt());
> +   dev = class_find_device(_class, dev, NULL,
> +   _match_next_root_bus);
> +   pci_bus_put(from);
> +   if (dev)
> +   return to_pci_bus(dev);
> +
> +   return NULL;
>  }
> +EXPORT_SYMBOL(pci_get_next_root_bus);

this patchset is most doing same thing like my for_each_host_bridge patchset.
that patchset add bus_type for host_bridge and loop with each_...bus
to find host_bridge
and to its bus.

looks like for each host bridge should be right direction.

also late we could add per host bridge lock instead of whole pci bus sem etc.

Thanks

Yinghai
--
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/


[49/94] btrfs: don't stop searching after encountering the wrong item

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Gabriel de Perthuis 

commit 03b71c6ca6286625d8f1ed44aabab9b5bf5dac10 upstream.

The search ioctl skips items that are too large for a result buffer, but
inline items of a certain size occuring before any search result is
found would trigger an overflow and stop the search entirely.

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

Signed-off-by: Gabriel de Perthuis 
Signed-off-by: Josef Bacik 
Signed-off-by: Ben Hutchings 
---
 fs/btrfs/ioctl.c |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -1571,7 +1571,11 @@ static noinline int copy_to_sk(struct bt
item_off = btrfs_item_ptr_offset(leaf, i);
item_len = btrfs_item_size_nr(leaf, i);
 
-   if (item_len > BTRFS_SEARCH_ARGS_BUFSIZE)
+   btrfs_item_key_to_cpu(leaf, key, i);
+   if (!key_in_sk(key, sk))
+   continue;
+
+   if (sizeof(sh) + item_len > BTRFS_SEARCH_ARGS_BUFSIZE)
item_len = 0;
 
if (sizeof(sh) + item_len + *sk_offset >
@@ -1580,10 +1584,6 @@ static noinline int copy_to_sk(struct bt
goto overflow;
}
 
-   btrfs_item_key_to_cpu(leaf, key, i);
-   if (!key_in_sk(key, sk))
-   continue;
-
sh.objectid = key->objectid;
sh.offset = key->offset;
sh.type = key->type;

--
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 rusty/virtio-pci-new-layout] virtio: new layout minor header fixups

2013-05-27 Thread Rusty Russell
"Michael S. Tsirkin"  writes:
> Fix issues observed with the new layout code, seen
> when implementing device in qemu:
>   - use of uXX in uapi header
>   - incorrect readonly tag on one field
>   - unconditional warning breaks builds with -Werr
>
> Signed-off-by: Michael S. Tsirkin 

Hmm, this means if we ever *do* remove those defines, qemu will break.

But perhaps that's OK, because we'll probably remove legacy support at
the same time as we break the header.

Applied, thanks!
Rusty.

> This patch is on top of rusty/virtio-pci-new-layout.
>
>  include/uapi/linux/virtio_pci.h | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/include/uapi/linux/virtio_pci.h b/include/uapi/linux/virtio_pci.h
> index 3e61d55..cda688f 100644
> --- a/include/uapi/linux/virtio_pci.h
> +++ b/include/uapi/linux/virtio_pci.h
> @@ -86,8 +86,10 @@
>  #define VIRTIO_PCI_LEGACY_VRING_ALIGN4096
>  
>  #ifndef VIRTIO_PCI_NO_LEGACY
> +#ifndef VIRTIO_PCI_LEGACY_COMPAT_NAMES
>  /* Don't break compile of old userspace code.  These will go away. */
>  #warning "Please support virtio_pci non-legacy mode!"
> +#endif
>  #define VIRTIO_PCI_HOST_FEATURES VIRTIO_PCI_LEGACY_HOST_FEATURES
>  #define VIRTIO_PCI_GUEST_FEATURES VIRTIO_PCI_LEGACY_GUEST_FEATURES
>  #define VIRTIO_PCI_QUEUE_PFN VIRTIO_PCI_LEGACY_QUEUE_PFN
> @@ -125,10 +127,10 @@
>  
>  /* This is the PCI capability header: */
>  struct virtio_pci_cap {
> - u8 cap_vndr;/* Generic PCI field: PCI_CAP_ID_VNDR */
> - u8 cap_next;/* Generic PCI field: next ptr. */
> - u8 cfg_type;/* One of the VIRTIO_PCI_CAP_*_CFG. */
> - u8 bar; /* Where to find it. */
> + __u8 cap_vndr;  /* Generic PCI field: PCI_CAP_ID_VNDR */
> + __u8 cap_next;  /* Generic PCI field: next ptr. */
> + __u8 cfg_type;  /* One of the VIRTIO_PCI_CAP_*_CFG. */
> + __u8 bar;   /* Where to find it. */
>   __le32 offset;  /* Offset within bar. */
>   __le32 length;  /* Length. */
>  };
> @@ -144,7 +146,7 @@ struct virtio_pci_common_cfg {
>   __le32 device_feature_select;   /* read-write */
>   __le32 device_feature;  /* read-only */
>   __le32 guest_feature_select;/* read-write */
> - __le32 guest_feature;   /* read-only */
> + __le32 guest_feature;   /* read-write */
>   __le16 msix_config; /* read-write */
>   __le16 num_queues;  /* read-only */
>   __u8 device_status; /* read-write */
> -- 
> MST
--
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/


[04/94] mfd: adp5520: Restore mode bits on resume

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Lars-Peter Clausen 

commit c6cc25fda58da8685ecef3f179adc7b99c8253b2 upstream.

The adp5520 unfortunately also clears the BL_EN bit when the nSTNDBY bit is
cleared. So we need to make sure to restore it during resume if it was set
before suspend.

Signed-off-by: Lars-Peter Clausen 
Acked-by: Michael Hennerich 
Signed-off-by: Samuel Ortiz 
Signed-off-by: Ben Hutchings 
---
 drivers/mfd/adp5520.c |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

--- a/drivers/mfd/adp5520.c
+++ b/drivers/mfd/adp5520.c
@@ -36,6 +36,7 @@ struct adp5520_chip {
struct blocking_notifier_head notifier_list;
int irq;
unsigned long id;
+   uint8_t mode;
 };
 
 static int __adp5520_read(struct i2c_client *client,
@@ -326,7 +327,10 @@ static int adp5520_suspend(struct device
struct i2c_client *client = to_i2c_client(dev);
struct adp5520_chip *chip = dev_get_drvdata(>dev);
 
-   adp5520_clr_bits(chip->dev, ADP5520_MODE_STATUS, ADP5520_nSTNBY);
+   adp5520_read(chip->dev, ADP5520_MODE_STATUS, >mode);
+   /* All other bits are W1C */
+   chip->mode &= ADP5520_BL_EN | ADP5520_DIM_EN | ADP5520_nSTNBY;
+   adp5520_write(chip->dev, ADP5520_MODE_STATUS, 0);
return 0;
 }
 
@@ -335,7 +339,7 @@ static int adp5520_resume(struct device
struct i2c_client *client = to_i2c_client(dev);
struct adp5520_chip *chip = dev_get_drvdata(>dev);
 
-   adp5520_set_bits(chip->dev, ADP5520_MODE_STATUS, ADP5520_nSTNBY);
+   adp5520_write(chip->dev, ADP5520_MODE_STATUS, chip->mode);
return 0;
 }
 #endif

--
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/


[53/94] TTY: Fix tty miss restart after we turn off flow-control

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Wang YanQing 

commit dab73b4eb9ef924a2b90dab84e539076d82b256f upstream.

I meet emacs hang in start if I do the operation below:
  1: echo 3 > /proc/sys/vm/drop_caches
  2: emacs BigFile
  3: Press CTRL-S follow 2 immediately

Then emacs hang on, CTRL-Q can't resume, the terminal
hang on, you can do nothing with this terminal except
close it.

The reason is before emacs takeover control the tty,
we use CTRL-S to XOFF it. Then when emacs takeover the
control, it may don't use the flow-control, so emacs hang.
This patch fix it.

This patch will fix a kind of strange tty relation hang problem,
I believe I meet it with vim in ssh, and also see below bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465823

Signed-off-by: Wang YanQing 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
---
 drivers/tty/n_tty.c |8 
 1 file changed, 8 insertions(+)

--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -1530,6 +1530,14 @@ static void n_tty_set_termios(struct tty
tty->real_raw = 0;
}
n_tty_set_room(tty);
+   /*
+* Fix tty hang when I_IXON(tty) is cleared, but the tty
+* been stopped by STOP_CHAR(tty) before it.
+*/
+   if (!I_IXON(tty) && old && (old->c_iflag & IXON) && !tty->flow_stopped) 
{
+   start_tty(tty);
+   }
+
/* The termios change make the tty ready for I/O */
wake_up_interruptible(>write_wait);
wake_up_interruptible(>read_wait);

--
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/


[25/94] dm bufio: avoid a possible __vmalloc deadlock

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Mikulas Patocka 

commit 502624bdad3dba45dfaacaf36b7d83e39e74b2d2 upstream.

This patch uses memalloc_noio_save to avoid a possible deadlock in
dm-bufio.  (it could happen only with large block size, at most
PAGE_SIZE << MAX_ORDER (typically 8MiB).

__vmalloc doesn't fully respect gfp flags. The specified gfp flags are
used for allocation of requested pages, structures vmap_area, vmap_block
and vm_struct and the radix tree nodes.

However, the kernel pagetables are allocated always with GFP_KERNEL.
Thus the allocation of pagetables can recurse back to the I/O layer and
cause a deadlock.

This patch uses the function memalloc_noio_save to set per-process
PF_MEMALLOC_NOIO flag and the function memalloc_noio_restore to restore
it. When this flag is set, all allocations in the process are done with
implied GFP_NOIO flag, thus the deadlock can't happen.

This should be backported to stable kernels, but they don't have the
PF_MEMALLOC_NOIO flag and memalloc_noio_save/memalloc_noio_restore
functions. So, PF_MEMALLOC should be set and restored instead.

Signed-off-by: Mikulas Patocka 
Signed-off-by: Alasdair G Kergon 
[bwh: Backported to 3.2 as recommended]
Signed-off-by: Ben Hutchings 
---
 drivers/md/dm-bufio.c |   24 +++-
 1 file changed, 23 insertions(+), 1 deletion(-)

--- a/drivers/md/dm-bufio.c
+++ b/drivers/md/dm-bufio.c
@@ -322,6 +322,9 @@ static void __cache_size_refresh(void)
 static void *alloc_buffer_data(struct dm_bufio_client *c, gfp_t gfp_mask,
   enum data_mode *data_mode)
 {
+   unsigned noio_flag;
+   void *ptr;
+
if (c->block_size <= DM_BUFIO_BLOCK_SIZE_SLAB_LIMIT) {
*data_mode = DATA_MODE_SLAB;
return kmem_cache_alloc(DM_BUFIO_CACHE(c), gfp_mask);
@@ -335,7 +338,28 @@ static void *alloc_buffer_data(struct dm
}
 
*data_mode = DATA_MODE_VMALLOC;
-   return __vmalloc(c->block_size, gfp_mask, PAGE_KERNEL);
+
+   /*
+* __vmalloc allocates the data pages and auxiliary structures with
+* gfp_flags that were specified, but pagetables are always allocated
+* with GFP_KERNEL, no matter what was specified as gfp_mask.
+*
+* Consequently, we must set per-process flag PF_MEMALLOC_NOIO so that
+* all allocations done by this process (including pagetables) are done
+* as if GFP_NOIO was specified.
+*/
+
+   if (gfp_mask & __GFP_NORETRY) {
+   noio_flag = current->flags & PF_MEMALLOC;
+   current->flags |= PF_MEMALLOC;
+   }
+
+   ptr = __vmalloc(c->block_size, gfp_mask, PAGE_KERNEL);
+
+   if (gfp_mask & __GFP_NORETRY)
+   current->flags = (current->flags & ~PF_MEMALLOC) | noio_flag;
+
+   return ptr;
 }
 
 /*

--
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/


[02/94] mmc: at91/avr32/atmel-mci: fix DMA-channel leak on module unload

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Johan Hovold 

commit 91cf54feecf815bec0b6a8d6d9dbd0e219f2f2cc upstream.

Fix regression introduced by commit 796211b7953 ("mmc: atmel-mci: add
pdc support and runtime capabilities detection") which removed the need
for CONFIG_MMC_ATMELMCI_DMA but kept the Kconfig-entry as well as the
compile guards around dma_release_channel() in remove(). Consequently,
DMA is always enabled (if supported), but the DMA-channel is not
released on module unload unless the DMA-config option is selected.

Remove the no longer used CONFIG_MMC_ATMELMCI_DMA option completely.

Signed-off-by: Johan Hovold 
Acked-by: Ludovic Desroches 
Signed-off-by: Chris Ball 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings 
---
 arch/arm/configs/at91sam9g45_defconfig |1 -
 arch/avr32/configs/favr-32_defconfig   |1 -
 arch/avr32/configs/merisc_defconfig|1 -
 drivers/mmc/host/Kconfig   |   10 --
 drivers/mmc/host/atmel-mci.c   |2 --
 5 files changed, 15 deletions(-)

--- a/arch/arm/configs/at91sam9g45_defconfig
+++ b/arch/arm/configs/at91sam9g45_defconfig
@@ -173,7 +173,6 @@ CONFIG_MMC=y
 # CONFIG_MMC_BLOCK_BOUNCE is not set
 CONFIG_SDIO_UART=m
 CONFIG_MMC_ATMELMCI=y
-CONFIG_MMC_ATMELMCI_DMA=y
 CONFIG_LEDS_ATMEL_PWM=y
 CONFIG_LEDS_GPIO=y
 CONFIG_LEDS_TRIGGER_TIMER=y
--- a/arch/avr32/configs/favr-32_defconfig
+++ b/arch/avr32/configs/favr-32_defconfig
@@ -122,7 +122,6 @@ CONFIG_USB_G_SERIAL=m
 CONFIG_USB_CDC_COMPOSITE=m
 CONFIG_MMC=y
 CONFIG_MMC_ATMELMCI=y
-CONFIG_MMC_ATMELMCI_DMA=y
 CONFIG_NEW_LEDS=y
 CONFIG_LEDS_CLASS=y
 CONFIG_LEDS_ATMEL_PWM=m
--- a/arch/avr32/configs/merisc_defconfig
+++ b/arch/avr32/configs/merisc_defconfig
@@ -102,7 +102,6 @@ CONFIG_FRAMEBUFFER_CONSOLE=y
 CONFIG_LOGO=y
 CONFIG_MMC=y
 CONFIG_MMC_ATMELMCI=y
-CONFIG_MMC_ATMELMCI_DMA=y
 CONFIG_NEW_LEDS=y
 CONFIG_LEDS_CLASS=y
 CONFIG_LEDS_ATMEL_PWM=y
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -297,16 +297,6 @@ config MMC_ATMELMCI
 
 endchoice
 
-config MMC_ATMELMCI_DMA
-   bool "Atmel MCI DMA support"
-   depends on MMC_ATMELMCI && (AVR32 || ARCH_AT91SAM9G45) && DMA_ENGINE
-   help
- Say Y here to have the Atmel MCI driver use a DMA engine to
- do data transfers and thus increase the throughput and
- reduce the CPU utilization.
-
- If unsure, say N.
-
 config MMC_IMX
tristate "Motorola i.MX Multimedia Card Interface support"
depends on ARCH_MX1
--- a/drivers/mmc/host/atmel-mci.c
+++ b/drivers/mmc/host/atmel-mci.c
@@ -2167,10 +2167,8 @@ static int __exit atmci_remove(struct pl
atmci_readl(host, ATMCI_SR);
clk_disable(host->mck);
 
-#ifdef CONFIG_MMC_ATMELMCI_DMA
if (host->dma.chan)
dma_release_channel(host->dma.chan);
-#endif
 
free_irq(platform_get_irq(pdev, 0), host);
iounmap(host->regs);

--
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/


[79/94] x86,efi: Implement efi_no_storage_paranoia parameter

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Richard Weinberger 

commit 8c58bf3eec3b8fc8162fe557e9361891c20758f2 upstream.

Using this parameter one can disable the storage_size/2 check if
he is really sure that the UEFI does sane gc and fulfills the spec.

This parameter is useful if a devices uses more than 50% of the
storage by default.
The Intel DQSW67 desktop board is such a sucker for exmaple.

Signed-off-by: Richard Weinberger 
Signed-off-by: Matt Fleming 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings 
---
 Documentation/kernel-parameters.txt |6 ++
 arch/x86/platform/efi/efi.c |   14 +-
 2 files changed, 19 insertions(+), 1 deletion(-)

--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -734,6 +734,12 @@ bytes respectively. Such letter suffixes
edd=[EDD]
Format: {"off" | "on" | "skip[mbr]"}
 
+   efi_no_storage_paranoia [EFI; X86]
+   Using this parameter you can use more than 50% of
+   your efi variable storage. Use this parameter only if
+   you are really sure that your UEFI does sane gc and
+   fulfills the spec otherwise your board may brick.
+
eisa_irq_edge=  [PARISC,HW]
See header of drivers/parisc/eisa.c.
 
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -101,6 +101,15 @@ static int __init setup_add_efi_memmap(c
 }
 early_param("add_efi_memmap", setup_add_efi_memmap);
 
+static bool efi_no_storage_paranoia;
+
+static int __init setup_storage_paranoia(char *arg)
+{
+   efi_no_storage_paranoia = true;
+   return 0;
+}
+early_param("efi_no_storage_paranoia", setup_storage_paranoia);
+
 
 static efi_status_t virt_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
 {
@@ -839,7 +848,10 @@ efi_status_t efi_query_variable_store(u3
" is returning MaxVariableSize=0\n");
 
if (!storage_size || size > remaining_size ||
-   (max_size && size > max_size) ||
+   (max_size && size > max_size))
+   return EFI_OUT_OF_RESOURCES;
+
+   if (!efi_no_storage_paranoia &&
(remaining_size - size) < (storage_size / 2))
return EFI_OUT_OF_RESOURCES;
 

--
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/


[51/94] ARM: plat-orion: Fix num_resources and id for ge10 and ge11

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Gregory CLEMENT 

commit 2b8b2797142c7951e635c6eec5d1705ee9bc45c5 upstream.

When platform data were moved from arch/arm/mach-mv78xx0/common.c to
arch/arm/plat-orion/common.c with the commit "7e3819d ARM: orion:
Consolidate ethernet platform data", there were few typo made on
gigabit Ethernet interface ge10 and ge11. This commit writes back
their initial value, which allows to use this interfaces again.

Signed-off-by: Gregory CLEMENT 
Acked-by: Andrew Lunn 
Signed-off-by: Jason Cooper 
Signed-off-by: Ben Hutchings 
---
 arch/arm/plat-orion/common.c |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

--- a/arch/arm/plat-orion/common.c
+++ b/arch/arm/plat-orion/common.c
@@ -347,7 +347,7 @@ static struct resource orion_ge10_shared
 
 static struct platform_device orion_ge10_shared = {
.name   = MV643XX_ETH_SHARED_NAME,
-   .id = 1,
+   .id = 2,
.dev= {
.platform_data  = _ge10_shared_data,
},
@@ -362,8 +362,8 @@ static struct resource orion_ge10_resour
 
 static struct platform_device orion_ge10 = {
.name   = MV643XX_ETH_NAME,
-   .id = 1,
-   .num_resources  = 2,
+   .id = 2,
+   .num_resources  = 1,
.resource   = orion_ge10_resources,
.dev= {
.coherent_dma_mask  = DMA_BIT_MASK(32),
@@ -401,7 +401,7 @@ static struct resource orion_ge11_shared
 
 static struct platform_device orion_ge11_shared = {
.name   = MV643XX_ETH_SHARED_NAME,
-   .id = 1,
+   .id = 3,
.dev= {
.platform_data  = _ge11_shared_data,
},
@@ -416,8 +416,8 @@ static struct resource orion_ge11_resour
 
 static struct platform_device orion_ge11 = {
.name   = MV643XX_ETH_NAME,
-   .id = 1,
-   .num_resources  = 2,
+   .id = 3,
+   .num_resources  = 1,
.resource   = orion_ge11_resources,
.dev= {
.coherent_dma_mask  = DMA_BIT_MASK(32),

--
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/


[35/94] timer: Don't reinitialize the cpu base lock during CPU_UP_PREPARE

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Tirupathi Reddy 

commit 42a5cf46cd56f46267d2a9fcf2655f4078cd3042 upstream.

An inactive timer's base can refer to a offline cpu's base.

In the current code, cpu_base's lock is blindly reinitialized each
time a CPU is brought up. If a CPU is brought online during the period
that another thread is trying to modify an inactive timer on that CPU
with holding its timer base lock, then the lock will be reinitialized
under its feet. This leads to following SPIN_BUG().

<0> BUG: spinlock already unlocked on CPU#3, kworker/u:3/1466
<0> lock: 0xe3ebe000, .magic: dead4ead, .owner: kworker/u:3/1466, .owner_cpu: 1
<4> [] (unwind_backtrace+0x0/0x11c) from [] 
(do_raw_spin_unlock+0x40/0xcc)
<4> [] (do_raw_spin_unlock+0x40/0xcc) from [] 
(_raw_spin_unlock+0x8/0x30)
<4> [] (_raw_spin_unlock+0x8/0x30) from [] 
(mod_timer+0x294/0x310)
<4> [] (mod_timer+0x294/0x310) from [] 
(queue_delayed_work_on+0x104/0x120)
<4> [] (queue_delayed_work_on+0x104/0x120) from [] 
(sdhci_msm_bus_voting+0x88/0x9c)
<4> [] (sdhci_msm_bus_voting+0x88/0x9c) from [] 
(sdhci_disable+0x40/0x48)
<4> [] (sdhci_disable+0x40/0x48) from [] 
(mmc_release_host+0x4c/0xb0)
<4> [] (mmc_release_host+0x4c/0xb0) from [] 
(mmc_sd_detect+0x90/0xfc)
<4> [] (mmc_sd_detect+0x90/0xfc) from [] 
(mmc_rescan+0x7c/0x2c4)
<4> [] (mmc_rescan+0x7c/0x2c4) from [] 
(process_one_work+0x27c/0x484)
<4> [] (process_one_work+0x27c/0x484) from [] 
(worker_thread+0x210/0x3b0)
<4> [] (worker_thread+0x210/0x3b0) from [] 
(kthread+0x80/0x8c)
<4> [] (kthread+0x80/0x8c) from [] 
(kernel_thread_exit+0x0/0x8)

As an example, this particular crash occurred when CPU #3 is executing
mod_timer() on an inactive timer whose base is refered to offlined CPU
#2.  The code locked the timer_base corresponding to CPU #2. Before it
could proceed, CPU #2 came online and reinitialized the spinlock
corresponding to its base. Thus now CPU #3 held a lock which was
reinitialized. When CPU #3 finally ended up unlocking the old cpu_base
corresponding to CPU #2, we hit the above SPIN_BUG().

CPU #0  CPU #3 CPU #2
--  ------
...   
mod_timer()
 lock_timer_base
   spin_lock_irqsave(>lock)

cpu_up(2).  ..
init_timers_cpu()
 .  
spin_lock_init(>lock)
.  spin_unlock_irqrestore(>lock)  ..
   

Allocation of per_cpu timer vector bases is done only once under
"tvec_base_done[]" check. In the current code, spinlock_initialization
of base->lock isn't under this check. When a CPU is up each time the
base lock is reinitialized. Move base spinlock initialization under
the check.

Signed-off-by: Tirupathi Reddy 
Link: 
http://lkml.kernel.org/r/1368520142-4136-1-git-send-email-tirup...@codeaurora.org
Signed-off-by: Thomas Gleixner 
Signed-off-by: Ben Hutchings 
---
 kernel/timer.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/kernel/timer.c
+++ b/kernel/timer.c
@@ -1630,12 +1630,12 @@ static int __cpuinit init_timers_cpu(int
boot_done = 1;
base = _tvec_bases;
}
+   spin_lock_init(>lock);
tvec_base_done[cpu] = 1;
} else {
base = per_cpu(tvec_bases, cpu);
}
 
-   spin_lock_init(>lock);
 
for (j = 0; j < TVN_SIZE; j++) {
INIT_LIST_HEAD(base->tv5.vec + j);

--
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/


[61/94] mm: mmu_notifier: re-fix freed page still mapped in secondary MMU

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Xiao Guangrong 

commit d34883d4e35c0a994e91dd847a82b4c9e0c31d83 upstream.

Commit 751efd8610d3 ("mmu_notifier_unregister NULL Pointer deref and
multiple ->release()") breaks the fix 3ad3d901bbcf ("mm: mmu_notifier:
fix freed page still mapped in secondary MMU").

Since hlist_for_each_entry_rcu() is changed now, we can not revert that
patch directly, so this patch reverts the commit and simply fix the bug
spotted by that patch

This bug spotted by commit 751efd8610d3 is:

There is a race condition between mmu_notifier_unregister() and
__mmu_notifier_release().

Assume two tasks, one calling mmu_notifier_unregister() as a result
of a filp_close() ->flush() callout (task A), and the other calling
mmu_notifier_release() from an mmput() (task B).

A   B
t1srcu_read_lock()
t2if (!hlist_unhashed())
t3srcu_read_unlock()
t4srcu_read_lock()
t5hlist_del_init_rcu()
t6synchronize_srcu()
t7srcu_read_unlock()
t8hlist_del_rcu()  <--- NULL pointer deref.

This can be fixed by using hlist_del_init_rcu instead of hlist_del_rcu.

The another issue spotted in the commit is "multiple ->release()
callouts", we needn't care it too much because it is really rare (e.g,
can not happen on kvm since mmu-notify is unregistered after
exit_mmap()) and the later call of multiple ->release should be fast
since all the pages have already been released by the first call.
Anyway, this issue should be fixed in a separate patch.

-stable suggestions: Any version that has commit 751efd8610d3 need to be
backported.  I find the oldest version has this commit is 3.0-stable.

[a...@linux-foundation.org: tweak comments]
Signed-off-by: Xiao Guangrong 
Tested-by: Robin Holt 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[bwh: Backported to 3.2: hlist_for_each_entry_rcu() still requires the
 struct hlist_node pointer]
Signed-off-by: Ben Hutchings 
---
 mm/mmu_notifier.c |   79 ++---
 1 file changed, 39 insertions(+), 40 deletions(-)

--- a/mm/mmu_notifier.c
+++ b/mm/mmu_notifier.c
@@ -37,51 +37,48 @@ static struct srcu_struct srcu;
 void __mmu_notifier_release(struct mm_struct *mm)
 {
struct mmu_notifier *mn;
+   struct hlist_node *n;
int id;
 
/*
-* srcu_read_lock() here will block synchronize_srcu() in
-* mmu_notifier_unregister() until all registered
-* ->release() callouts this function makes have
-* returned.
+* SRCU here will block mmu_notifier_unregister until
+* ->release returns.
 */
id = srcu_read_lock();
+   hlist_for_each_entry_rcu(mn, n, >mmu_notifier_mm->list, hlist)
+   /*
+* If ->release runs before mmu_notifier_unregister it must be
+* handled, as it's the only way for the driver to flush all
+* existing sptes and stop the driver from establishing any more
+* sptes before all the pages in the mm are freed.
+*/
+   if (mn->ops->release)
+   mn->ops->release(mn, mm);
+   srcu_read_unlock(, id);
+
spin_lock(>mmu_notifier_mm->lock);
while (unlikely(!hlist_empty(>mmu_notifier_mm->list))) {
mn = hlist_entry(mm->mmu_notifier_mm->list.first,
 struct mmu_notifier,
 hlist);
-
/*
-* Unlink.  This will prevent mmu_notifier_unregister()
-* from also making the ->release() callout.
+* We arrived before mmu_notifier_unregister so
+* mmu_notifier_unregister will do nothing other than to wait
+* for ->release to finish and for mmu_notifier_unregister to
+* return.
 */
hlist_del_init_rcu(>hlist);
-   spin_unlock(>mmu_notifier_mm->lock);
-
-   /*
-* Clear sptes. (see 'release' description in mmu_notifier.h)
-*/
-   if (mn->ops->release)
-   mn->ops->release(mn, mm);
-
-   spin_lock(>mmu_notifier_mm->lock);
}
spin_unlock(>mmu_notifier_mm->lock);
 
/*
-* All callouts to ->release() which we have done are complete.
-* Allow synchronize_srcu() in mmu_notifier_unregister() to complete
-*/
-   srcu_read_unlock(, id);
-
-   /*
-* mmu_notifier_unregister() may have unlinked a notifier and may
-* still be calling out to it.  Additionally, other notifiers

[43/94] USB: reset resume quirk needed by a hub

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Oliver Neukum 

commit bac6b03275184c912ad0818c9a0a736847804dca upstream.

Werner Fink has reported problems with this hub.

Signed-off-by: Oliver Neukum 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
---
 drivers/usb/core/quirks.c |3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -88,6 +88,9 @@ static const struct usb_device_id usb_qu
/* Edirol SD-20 */
{ USB_DEVICE(0x0582, 0x0027), .driver_info = USB_QUIRK_RESET_RESUME },
 
+   /* Alcor Micro Corp. Hub */
+   { USB_DEVICE(0x058f, 0x9254), .driver_info = USB_QUIRK_RESET_RESUME },
+
/* appletouch */
{ USB_DEVICE(0x05ac, 0x021a), .driver_info = USB_QUIRK_RESET_RESUME },
 

--
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/


[55/94] SUNRPC: Prevent an rpc_task wakeup race

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Trond Myklebust 

commit a3c3cac5d31879cd9ae2de7874dc6544ca704aec upstream.

The lockless RPC_IS_QUEUED() test in __rpc_execute means that we need to
be careful about ordering the calls to rpc_test_and_set_running(task) and
rpc_clear_queued(task). If we get the order wrong, then we may end up
testing the RPC_TASK_RUNNING flag after __rpc_execute() has looped
and changed the state of the rpc_task.

Signed-off-by: Trond Myklebust 
Signed-off-by: Ben Hutchings 
---
 net/sunrpc/sched.c |8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

--- a/net/sunrpc/sched.c
+++ b/net/sunrpc/sched.c
@@ -299,11 +299,17 @@ EXPORT_SYMBOL_GPL(__rpc_wait_for_complet
  * Note: If the task is ASYNC, and is being made runnable after sitting on an
  * rpc_wait_queue, this must be called with the queue spinlock held to protect
  * the wait queue operation.
+ * Note the ordering of rpc_test_and_set_running() and rpc_clear_queued(),
+ * which is needed to ensure that __rpc_execute() doesn't loop (due to the
+ * lockless RPC_IS_QUEUED() test) before we've had a chance to test
+ * the RPC_TASK_RUNNING flag.
  */
 static void rpc_make_runnable(struct rpc_task *task)
 {
+   bool need_wakeup = !rpc_test_and_set_running(task);
+
rpc_clear_queued(task);
-   if (rpc_test_and_set_running(task))
+   if (!need_wakeup)
return;
if (RPC_IS_ASYNC(task)) {
INIT_WORK(>u.tk_work, rpc_async_schedule);

--
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/


[17/94] B43: Handle DMA RX descriptor underrun

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Thommy Jakobsson 

commit 73b82bf0bfbf58e6ff328d3726934370585f6e78 upstream.

Add handling of rx descriptor underflow. This fixes a fault that could
happen on slow machines, where data is received faster than the CPU can
handle. In such a case the device will use up all rx descriptors and
refuse to send any more data before confirming that it is ok. This
patch enables necessary interrupt to discover such a situation and will
handle them by dropping everything in the ring buffer.

Reviewed-by: Michael Buesch 
Signed-off-by: Thommy Jakobsson 
Signed-off-by: John W. Linville 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings 
---
 drivers/net/wireless/b43/dma.c  |   19 +
 drivers/net/wireless/b43/dma.h  |4 +++-
 drivers/net/wireless/b43/main.c |   43 ---
 3 files changed, 40 insertions(+), 26 deletions(-)

--- a/drivers/net/wireless/b43/dma.c
+++ b/drivers/net/wireless/b43/dma.c
@@ -1719,6 +1719,25 @@ drop_recycle_buffer:
sync_descbuffer_for_device(ring, dmaaddr, ring->rx_buffersize);
 }
 
+void b43_dma_handle_rx_overflow(struct b43_dmaring *ring)
+{
+   int current_slot, previous_slot;
+
+   B43_WARN_ON(ring->tx);
+
+   /* Device has filled all buffers, drop all packets and let TCP
+* decrease speed.
+* Decrement RX index by one will let the device to see all slots
+* as free again
+*/
+   /*
+   *TODO: How to increase rx_drop in mac80211?
+   */
+   current_slot = ring->ops->get_current_rxslot(ring);
+   previous_slot = prev_slot(ring, current_slot);
+   ring->ops->set_current_rxslot(ring, previous_slot);
+}
+
 void b43_dma_rx(struct b43_dmaring *ring)
 {
const struct b43_dma_ops *ops = ring->ops;
--- a/drivers/net/wireless/b43/dma.h
+++ b/drivers/net/wireless/b43/dma.h
@@ -9,7 +9,7 @@
 /* DMA-Interrupt reasons. */
 #define B43_DMAIRQ_FATALMASK   ((1 << 10) | (1 << 11) | (1 << 12) \
 | (1 << 14) | (1 << 15))
-#define B43_DMAIRQ_NONFATALMASK(1 << 13)
+#define B43_DMAIRQ_RDESC_UFLOW (1 << 13)
 #define B43_DMAIRQ_RX_DONE (1 << 16)
 
 /*** 32-bit DMA Engine. ***/
@@ -295,6 +295,8 @@ int b43_dma_tx(struct b43_wldev *dev,
 void b43_dma_handle_txstatus(struct b43_wldev *dev,
 const struct b43_txstatus *status);
 
+void b43_dma_handle_rx_overflow(struct b43_dmaring *ring);
+
 void b43_dma_rx(struct b43_dmaring *ring);
 
 void b43_dma_direct_fifo_rx(struct b43_wldev *dev,
--- a/drivers/net/wireless/b43/main.c
+++ b/drivers/net/wireless/b43/main.c
@@ -1901,30 +1901,18 @@ static void b43_do_interrupt_thread(stru
}
}
 
-   if (unlikely(merged_dma_reason & (B43_DMAIRQ_FATALMASK |
- B43_DMAIRQ_NONFATALMASK))) {
-   if (merged_dma_reason & B43_DMAIRQ_FATALMASK) {
-   b43err(dev->wl, "Fatal DMA error: "
-  "0x%08X, 0x%08X, 0x%08X, "
-  "0x%08X, 0x%08X, 0x%08X\n",
-  dma_reason[0], dma_reason[1],
-  dma_reason[2], dma_reason[3],
-  dma_reason[4], dma_reason[5]);
-   b43err(dev->wl, "This device does not support DMA "
+   if (unlikely(merged_dma_reason & (B43_DMAIRQ_FATALMASK))) {
+   b43err(dev->wl,
+   "Fatal DMA error: 0x%08X, 0x%08X, 0x%08X, 0x%08X, 
0x%08X, 0x%08X\n",
+   dma_reason[0], dma_reason[1],
+   dma_reason[2], dma_reason[3],
+   dma_reason[4], dma_reason[5]);
+   b43err(dev->wl, "This device does not support DMA "
   "on your system. It will now be switched to 
PIO.\n");
-   /* Fall back to PIO transfers if we get fatal DMA 
errors! */
-   dev->use_pio = 1;
-   b43_controller_restart(dev, "DMA error");
-   return;
-   }
-   if (merged_dma_reason & B43_DMAIRQ_NONFATALMASK) {
-   b43err(dev->wl, "DMA error: "
-  "0x%08X, 0x%08X, 0x%08X, "
-  "0x%08X, 0x%08X, 0x%08X\n",
-  dma_reason[0], dma_reason[1],
-  dma_reason[2], dma_reason[3],
-  dma_reason[4], dma_reason[5]);
-   }
+   /* Fall back to PIO transfers if we get fatal DMA errors! */
+   dev->use_pio = true;
+   b43_controller_restart(dev, "DMA error");
+   return;
}
 
if (unlikely(reason & B43_IRQ_UCODE_DEBUG))
@@ -1943,6 +1931,11 @@ static void b43_do_interrupt_thread(stru
  

[12/94] xen/vcpu/pvhvm: Fix vcpu hotplugging hanging.

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Konrad Rzeszutek Wilk 

commit 7f1fc268c47491fd5e63548f6415fc8604e13003 upstream.

If a user did:

echo 0 > /sys/devices/system/cpu/cpu1/online
echo 1 > /sys/devices/system/cpu/cpu1/online

we would (this a build with DEBUG enabled) get to:
smpboot: =_---CPU UP  1
.. snip..
smpboot: Stack at about 880074c0ff44
smpboot: CPU1: has booted.

and hang. The RCU mechanism would kick in an try to IPI the CPU1
but the IPIs (and all other interrupts) would never arrive at the
CPU1. At first glance at least. A bit digging in the hypervisor
trace shows that (using xenanalyze):

[vla] d4v1 vec 243 injecting
   0.043163027 --|x d4v1 intr_window vec 243 src 5(vector) intr f3
]  0.043163639 --|x d4v1 vmentry cycles 1468
]  0.043164913 --|x d4v1 vmexit exit_reason PENDING_INTERRUPT eip 
81673254
   0.043164913 --|x d4v1 inj_virq vec 243  real
  [vla] d4v1 vec 243 injecting
   0.043164913 --|x d4v1 intr_window vec 243 src 5(vector) intr f3
]  0.043165526 --|x d4v1 vmentry cycles 1472
]  0.043166800 --|x d4v1 vmexit exit_reason PENDING_INTERRUPT eip 
81673254
   0.043166800 --|x d4v1 inj_virq vec 243  real
  [vla] d4v1 vec 243 injecting

there is a pending event (subsequent debugging shows it is the IPI
from the VCPU0 when smpboot.c on VCPU1 has done
"set_cpu_online(smp_processor_id(), true)") and the guest VCPU1 is
interrupted with the callback IPI (0xf3 aka 243) which ends up calling
__xen_evtchn_do_upcall.

The __xen_evtchn_do_upcall seems to do *something* but not acknowledge
the pending events. And the moment the guest does a 'cli' (that is the
81673254 in the log above) the hypervisor is invoked again to
inject the IPI (0xf3) to tell the guest it has pending interrupts.
This repeats itself forever.

The culprit was the per_cpu(xen_vcpu, cpu) pointer. At the bootup
we set each per_cpu(xen_vcpu, cpu) to point to the
shared_info->vcpu_info[vcpu] but later on use the VCPUOP_register_vcpu_info
to register per-CPU  structures (xen_vcpu_setup).
This is used to allow events for more than 32 VCPUs and for performance
optimizations reasons.

When the user performs the VCPU hotplug we end up calling the
the xen_vcpu_setup once more. We make the hypercall which returns
-EINVAL as it does not allow multiple registration calls (and
already has re-assigned where the events are being set). We pick
the fallback case and set per_cpu(xen_vcpu, cpu) to point to the
shared_info->vcpu_info[vcpu] (which is a good fallback during bootup).
However the hypervisor is still setting events in the register
per-cpu structure (per_cpu(xen_vcpu_info, cpu)).

As such when the events are set by the hypervisor (such as timer one),
and when we iterate in __xen_evtchn_do_upcall we end up reading stale
events from the shared_info->vcpu_info[vcpu] instead of the
per_cpu(xen_vcpu_info, cpu) structures. Hence we never acknowledge the
events that the hypervisor has set and the hypervisor keeps on reminding
us to ack the events which we never do.

The fix is simple. Don't on the second time when xen_vcpu_setup is
called over-write the per_cpu(xen_vcpu, cpu) if it points to
per_cpu(xen_vcpu_info).

Acked-by: Stefano Stabellini 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Ben Hutchings 
---
 arch/x86/xen/enlighten.c |   15 +++
 1 file changed, 15 insertions(+)

--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -129,6 +129,21 @@ static void xen_vcpu_setup(int cpu)
 
BUG_ON(HYPERVISOR_shared_info == _dummy_shared_info);
 
+   /*
+* This path is called twice on PVHVM - first during bootup via
+* smp_init -> xen_hvm_cpu_notify, and then if the VCPU is being
+* hotplugged: cpu_up -> xen_hvm_cpu_notify.
+* As we can only do the VCPUOP_register_vcpu_info once lets
+* not over-write its result.
+*
+* For PV it is called during restore (xen_vcpu_restore) and bootup
+* (xen_setup_vcpu_info_placement). The hotplug mechanism does not
+* use this function.
+*/
+   if (xen_hvm_domain()) {
+   if (per_cpu(xen_vcpu, cpu) == _cpu(xen_vcpu_info, cpu))
+   return;
+   }
if (cpu < MAX_VIRT_CPUS)
per_cpu(xen_vcpu,cpu) = _shared_info->vcpu_info[cpu];
 

--
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/


[32/94] avr32: fix relocation check for signed 18-bit offset

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Hans-Christian Egtvedt 

commit e68c636d88db3fda74e664ecb1a213ae0d50a7d8 upstream.

Caught by static code analysis by David.

Reported-by: David Binderman 
Signed-off-by: Hans-Christian Egtvedt 
Signed-off-by: Ben Hutchings 
---
 arch/avr32/kernel/module.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/avr32/kernel/module.c
+++ b/arch/avr32/kernel/module.c
@@ -264,7 +264,7 @@ int apply_relocate_add(Elf32_Shdr *sechd
break;
case R_AVR32_GOT18SW:
if ((relocation & 0xfffe0003) != 0
-   && (relocation & 0xfffc0003) != 0x)
+   && (relocation & 0xfffc) != 0xfffc)
return reloc_overflow(module, "R_AVR32_GOT18SW",
 relocation);
relocation >>= 2;

--
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/


[58/94] ACPI / video: Add "Asus UL30A" to ACPI video detect blacklist

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Bastian Triller 

commit c8f6d8351ba8c89d5cd4c562552ec7ec29274e31 upstream.

Like on UL30VT, the ACPI video driver can't control backlight correctly on
Asus UL30A.  Vendor driver (asus-laptop) can work.  This patch is to
add "Asus UL30A" to ACPI video detect blacklist in order to use
asus-laptop for video control on the "Asus UL30A" rather than ACPI
video driver.

Signed-off-by: Bastian Triller 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Ben Hutchings 
---
 drivers/acpi/video_detect.c |8 
 1 file changed, 8 insertions(+)

--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -164,6 +164,14 @@ static struct dmi_system_id video_detect
DMI_MATCH(DMI_PRODUCT_NAME, "UL30VT"),
},
},
+   {
+   .callback = video_detect_force_vendor,
+   .ident = "Asus UL30A",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK Computer Inc."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "UL30A"),
+   },
+   },
{ },
 };
 

--
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/


[76/94] x86, efivars: firmware bug workarounds should be in platform code

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Matt Fleming 

commit a6e4d5a03e9e3587e88aba687d8f225f4f04c792 upstream.

Let's not burden ia64 with checks in the common efivars code that we're not
writing too much data to the variable store. That kind of thing is an x86
firmware bug, plain and simple.

efi_query_variable_store() provides platforms with a wrapper in which they can
perform checks and workarounds for EFI variable storage bugs.

Cc: H. Peter Anvin 
Cc: Matthew Garrett 
Signed-off-by: Matt Fleming 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings 
---

--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -815,3 +815,28 @@ u64 efi_mem_attributes(unsigned long phy
}
return 0;
 }
+
+/*
+ * Some firmware has serious problems when using more than 50% of the EFI
+ * variable store, i.e. it triggers bugs that can brick machines. Ensure that
+ * we never use more than this safe limit.
+ *
+ * Return EFI_SUCCESS if it is safe to write 'size' bytes to the variable
+ * store.
+ */
+efi_status_t efi_query_variable_store(u32 attributes, unsigned long size)
+{
+   efi_status_t status;
+   u64 storage_size, remaining_size, max_size;
+
+   status = efi.query_variable_info(attributes, _size,
+_size, _size);
+   if (status != EFI_SUCCESS)
+   return status;
+
+   if (!storage_size || size > remaining_size || size > max_size ||
+   (remaining_size - size) < (storage_size / 2))
+   return EFI_OUT_OF_RESOURCES;
+
+   return EFI_SUCCESS;
+}
--- a/drivers/firmware/efivars.c
+++ b/drivers/firmware/efivars.c
@@ -425,24 +425,12 @@ static efi_status_t
 check_var_size_locked(struct efivars *efivars, u32 attributes,
unsigned long size)
 {
-   u64 storage_size, remaining_size, max_size;
-   efi_status_t status;
const struct efivar_operations *fops = efivars->ops;
 
-   if (!efivars->ops->query_variable_info)
+   if (!efivars->ops->query_variable_store)
return EFI_UNSUPPORTED;
 
-   status = fops->query_variable_info(attributes, _size,
-  _size, _size);
-
-   if (status != EFI_SUCCESS)
-   return status;
-
-   if (!storage_size || size > remaining_size || size > max_size ||
-   (remaining_size - size) < (storage_size / 2))
-   return EFI_OUT_OF_RESOURCES;
-
-   return status;
+   return fops->query_variable_store(attributes, size);
 }
 
 static ssize_t
@@ -1456,7 +1444,7 @@ efivars_init(void)
ops.get_variable = efi.get_variable;
ops.set_variable = efi.set_variable;
ops.get_next_variable = efi.get_next_variable;
-   ops.query_variable_info = efi.query_variable_info;
+   ops.query_variable_store = efi_query_variable_store;
error = register_efivars(&__efivars, , efi_kobj);
if (error)
goto err_put;
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -204,6 +204,7 @@ typedef efi_status_t efi_query_capsule_c
  unsigned long count,
  u64 *max_size,
  int *reset_type);
+typedef efi_status_t efi_query_variable_store_t(u32 attributes, unsigned long 
size);
 
 /*
  *  EFI Configuration Table and GUID definitions
@@ -331,6 +332,14 @@ extern void efi_map_pal_code (void);
 extern void efi_memmap_walk (efi_freemem_callback_t callback, void *arg);
 extern void efi_gettimeofday (struct timespec *ts);
 extern void efi_enter_virtual_mode (void); /* switch EFI to virtual mode, 
if possible */
+#ifdef CONFIG_X86
+extern efi_status_t efi_query_variable_store(u32 attributes, unsigned long 
size);
+#else
+static inline efi_status_t efi_query_variable_store(u32 attributes, unsigned 
long size)
+{
+   return EFI_SUCCESS;
+}
+#endif
 extern u64 efi_get_iobase (void);
 extern u32 efi_mem_type (unsigned long phys_addr);
 extern u64 efi_mem_attributes (unsigned long phys_addr);
@@ -475,7 +484,7 @@ struct efivar_operations {
efi_get_variable_t *get_variable;
efi_get_next_variable_t *get_next_variable;
efi_set_variable_t *set_variable;
-   efi_query_variable_info_t *query_variable_info;
+   efi_query_variable_store_t *query_variable_store;
 };
 
 struct efivars {

--
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/


[00/94] 3.2.46-rc1 review

2013-05-27 Thread Ben Hutchings
This is the start of the stable review cycle for the 3.2.46 release.
There are 94 patches in this series, which will be posted as responses
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Thu May 30 12:00:00 UTC 2013.
Anything received after that time might be too late.

A combined patch relative to 3.2.45 will be posted as an additional
response to this.  A shortlog and diffstat can be found below.

Ben.

-

Alan Cox (1):
  [media] mantis: fix silly crash case
 [e1d45ae10aea8e8a403e5d96bf5902ee670007ff]

Alan Stern (2):
  USB: UHCI: fix for suspend of virtual HP controller
 [997ff893603c6455da4c5e26ba1d0f81adfecdfc]
  USB: xHCI: override bogus bulk wMaxPacketSize values
 [e4f47e3675e6f1f40906b785b934ce963e9f2eb3]

Alexandre Bounine (1):
  rapidio/tsi721: fix bug in MSI interrupt handling
 [1ccc819da6fda9bee10ab8b72e9adbb5ad3e4959]

Amitkumar Karwar (1):
  mwifiex: fix memory leak issue when driver unload
 [f16fdc9d2dc1e5b270e9a08377587e831e0d36ac]

Andrew Gomella (1):
  USB: ftdi_sio: Add support for Newport CONEX motor drivers
 [7138143972b7c293267c783fc99a194f0ceff7f2]

Aneesh Kumar K.V (1):
  mm/THP: use pmd_populate() to update the pmd with pgtable_t pointer
 [7c3425123ddfdc5f48e7913ff59d908789712b18]

Bastian Triller (1):
  ACPI / video: Add "Asus UL30A" to ACPI video detect blacklist
 [c8f6d8351ba8c89d5cd4c562552ec7ec29274e31]

Ben Hutchings (3):
  Revert "drm/i915: Fix detection of base of stolen memory"
 [not upstream; fix is not needed in 3.2 and was backported wrongly]
  perf: net_dropmonitor: Fix symbol-relative addresses
 [5a1e99dd2028e00998d42029be86835d8ef4a46e]
  perf: net_dropmonitor: Fix trace parameter order
 [140c3c6a2bcd2c31e2f7f5a8d59689724776c8e5]

Benjamin Herrenschmidt (1):
  net/eth/ibmveth: Fixup retrieval of MAC address
 [13f85203e1060da83d9ec1c1c5a63343eaab8de4]

Benjamin LaHaise (1):
  ipmi: ipmi_devintf: compat_ioctl method fails to take ipmi_mutex
 [6368087e851e697679af059b4247aca33a69cef3]

Bing Zhao (1):
  mwifiex: clear is_suspended flag when interrupt is received early
 [48795424acff7215d5eac0b52793a2c1eb3a6283]

Bob Moore (1):
  ACPICA: Fix possible buffer overflow during a field unit read operation
 [61388f9e5d93053cf399a356414f31f9b4814c6d]

Brian Behlendorf (1):
  drivers/block/brd.c: fix brd_lookup_page() race
 [dfd20b2b174d3a9b258ea3b7a35ead33576587b1]

Brian King (1):
  powerpc/pseries: Fix partition migration hang in stop_topology_update
 [444080d13d05dc38d07dd3bf751d38bce7ab7c72]

Chen Gang (1):
  drivers/char/ipmi: memcpy, need additional 2 bytes to avoid memory 
overflow
 [a5f2b3d6a738e7d4180012fe7b541172f8c8dcea]

Cliff Wickman (1):
  mm/pagewalk.c: walk_page_range should avoid VM_PFNMAP areas
 [a9ff785e4437c83d2179161e012f5bdfbd6381f0]

Cong Wang (1):
  xfrm6: release dev before returning error
 [84c4a9dfbf430861e7588d95ae3ff61535dca351]

Dan Carpenter (2):
  ASoC: wm8994: missing break in wm8994_aif3_hw_params()
 [4495e46fe18f198366961bb2b324a694ef8a9b44]
  USB: cxacru: potential underflow in cxacru_cm_get_array()
 [2a0ebf80aa95cc758d4725f74a7016e992606a39]

Dan Williams (1):
  USB: option: add device IDs for Dell 5804 (Novatel E371) WWAN card
 [49c6e370dd6400b84897c4100095089b5c13a061]

Daniel Borkmann (1):
  packet: tpacket_v3: do not trigger bug() on wrong  header status
 [8da3056c04bfc5f69f840ab038a38389e2de8189]

Daniel Drake (1):
  mwifiex: fix setting of multicast filter
 [ccd384b10420ac81ba3fb9b0a7d18272c7173552]

David Jeffery (1):
  autofs - remove autofs dentry mount check
 [ce8a5dbdf9e709bdaf4618d7ef8cceb91e8adc69]

Eric Dumazet (2):
  ipv6: do not clear pinet6 field
 [f77d602124d865c38705df7fa25c03de9c284ad2]
  tcp: force a dst refcount when prequeue packet
 [093162553c33e9479283e107b4431378271c735d]

Felix Fietkau (1):
  ath9k: fix key allocation error handling for powersave keys
 [4ef69d0394cba8caa9f75d3f2e53429bfb8b3045]

Gabriel de Perthuis (1):
  btrfs: don't stop searching after encountering the wrong item
 [03b71c6ca6286625d8f1ed44aabab9b5bf5dac10]

Gleb Natapov (1):
  KVM: VMX: fix halt emulation while emulating invalid guest sate
 [8d76c49e9ffeee839bc0b7a3278a23f99101263e]

Gregory CLEMENT (1):
  ARM: plat-orion: Fix num_resources and id for ge10 and ge11
 [2b8b2797142c7951e635c6eec5d1705ee9bc45c5]

Hans Schillstrom (1):
  ipvs: ip_vs_sip_fill_param() BUG: bad check of return value
 [f7a1dd6e3ad59f0cfd51da29dfdbfd54122c5916]

Hans-Christian Egtvedt (1):
  avr32: fix relocation check for signed 18-bit offset
 [e68c636d88db3fda74e664ecb1a213ae0d50a7d8]

Hema 

[57/94] perf: net_dropmonitor: Fix symbol-relative addresses

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Ben Hutchings 

commit 5a1e99dd2028e00998d42029be86835d8ef4a46e upstream.

The comparison between traced and symbol addresses is backwards: if
the traced address doesn't exactly match a symbol (which we don't
expect it to), we'll show the next symbol and the offset to it,
whereas we should show the previous symbol and the offset from it.

Signed-off-by: Ben Hutchings 
Signed-off-by: David S. Miller 
---
 tools/perf/scripts/python/net_dropmonitor.py |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/tools/perf/scripts/python/net_dropmonitor.py
+++ b/tools/perf/scripts/python/net_dropmonitor.py
@@ -40,9 +40,9 @@ def get_kallsyms_table():
 
 def get_sym(sloc):
loc = int(sloc)
-   for i in kallsyms:
-   if (i['loc'] >= loc):
-   return (i['name'], i['loc']-loc)
+   for i in kallsyms[::-1]:
+   if loc >= i['loc']:
+   return (i['name'], loc - i['loc'])
return (None, 0)
 
 def print_drop_table():

--
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/


[81/94] 3c509.c: call SET_NETDEV_DEV for all device types (ISA/ISAPnP/EISA)

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Matthew Whitehead 

[ Upstream commit 3b54912f9cd167641b91d4a697bd742f70e534fe ]

The venerable 3c509 driver only sets its device parent in one case, the ISAPnP 
one.
It does this with the SET_NETDEV_DEV function. It should register with the 
device
hierarchy in two additional cases: standard (non-PnP) ISA and EISA.

- Currently they appear here:
/sys/devices/virtual/net/eth0 (standard ISA)
/sys/devices/virtual/net/eth1 (EISA)

- Rather, they should instead be here:
/sys/devices/isa/3c509.0/net/eth0 (standard ISA)
/sys/devices/pci:00/:00:07.0/00:04/net/eth1 (EISA)

Tested on ISA and EISA boards.

Signed-off-by: Matthew Whitehead 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
---
 drivers/net/ethernet/3com/3c509.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/3com/3c509.c 
b/drivers/net/ethernet/3com/3c509.c
index 92053e6..c15d6ce 100644
--- a/drivers/net/ethernet/3com/3c509.c
+++ b/drivers/net/ethernet/3com/3c509.c
@@ -309,6 +309,7 @@ static int __devinit el3_isa_match(struct device *pdev,
if (!dev)
return -ENOMEM;
 
+   SET_NETDEV_DEV(dev, pdev);
netdev_boot_setup_check(dev);
 
if (!request_region(ioaddr, EL3_IO_EXTENT, "3c509-isa")) {
@@ -704,6 +705,7 @@ static int __init el3_eisa_probe (struct device *device)
return -ENOMEM;
}
 
+   SET_NETDEV_DEV(dev, device);
netdev_boot_setup_check(dev);
 
el3_dev_fill(dev, phys_addr, ioaddr, irq, if_port, EL3_EISA);

--
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/


[56/94] perf: net_dropmonitor: Fix trace parameter order

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Ben Hutchings 

commit 140c3c6a2bcd2c31e2f7f5a8d59689724776c8e5 upstream.

This works much better if we don't treat protocol numbers as addresses.

Signed-off-by: Ben Hutchings 
Signed-off-by: David S. Miller 
---
 tools/perf/scripts/python/net_dropmonitor.py |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/tools/perf/scripts/python/net_dropmonitor.py
+++ b/tools/perf/scripts/python/net_dropmonitor.py
@@ -64,7 +64,7 @@ def trace_end():
 
 # called from perf, when it finds a correspoinding event
 def skb__kfree_skb(name, context, cpu, sec, nsec, pid, comm,
-   skbaddr, protocol, location):
+  skbaddr, location, protocol):
slocation = str(location)
try:
drop_log[slocation] = drop_log[slocation] + 1

--
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/


[64/94] mm/THP: use pmd_populate() to update the pmd with pgtable_t pointer

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: "Aneesh Kumar K.V" 

commit 7c3425123ddfdc5f48e7913ff59d908789712b18 upstream.

We should not use set_pmd_at to update pmd_t with pgtable_t pointer.
set_pmd_at is used to set pmd with huge pte entries and architectures
like ppc64, clear few flags from the pte when saving a new entry.
Without this change we observe bad pte errors like below on ppc64 with
THP enabled.

  BUG: Bad page map in process ld mm=0xc01ee39f4780 pte:7fc3f3784801 
pmd:c01ec000

Signed-off-by: Aneesh Kumar K.V 
Cc: Hugh Dickins 
Cc: Benjamin Herrenschmidt 
Reviewed-by: Andrea Arcangeli 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings 
---
 mm/huge_memory.c |7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1937,7 +1937,12 @@ static void collapse_huge_page(struct mm
pte_unmap(pte);
spin_lock(>page_table_lock);
BUG_ON(!pmd_none(*pmd));
-   set_pmd_at(mm, address, pmd, _pmd);
+   /*
+* We can only use set_pmd_at when establishing
+* hugepmds and never for establishing regular pmds that
+* points to regular pagetables. Use pmd_populate for that
+*/
+   pmd_populate(mm, pmd, pmd_pgtable(_pmd));
spin_unlock(>page_table_lock);
anon_vma_unlock(vma->anon_vma);
goto out;

--
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/


[28/94] drm/radeon: check incoming cliprects pointer

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Kees Cook 

commit fefaedcfb82d2e57c2320acf60604ab03b750cc0 upstream.

The "boxes" parameter points into userspace memory. It should be verified
like any other operation against user memory.

Signed-off-by: Kees Cook 
Signed-off-by: Dave Airlie 
Signed-off-by: Ben Hutchings 
---
 drivers/gpu/drm/radeon/r300_cmdbuf.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/radeon/r300_cmdbuf.c
+++ b/drivers/gpu/drm/radeon/r300_cmdbuf.c
@@ -74,7 +74,7 @@ static int r300_emit_cliprects(drm_radeo
OUT_RING(CP_PACKET0(R300_RE_CLIPRECT_TL_0, nr * 2 - 1));
 
for (i = 0; i < nr; ++i) {
-   if (DRM_COPY_FROM_USER_UNCHECKED
+   if (DRM_COPY_FROM_USER
(, >boxes[n + i], sizeof(box))) {
DRM_ERROR("copy cliprect faulted\n");
return -EFAULT;

--
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 v2] video: simplefb: add mode parsing function

2013-05-27 Thread Stephen Warren
On 05/26/2013 09:53 PM, Alexandre Courbot wrote:
> The naming scheme of simplefb's mode is precise enough to allow building
> the mode structure from it instead of using a static list of modes. This
> patch introduces a function that does this. In case exotic modes that
> cannot be represented from their name alone are needed, the static list
> of modes is still available as a backup.
> 
> It also changes the order in which colors are declared from MSB first to
> the more standard LSB first.
> 
> Signed-off-by: Alexandre Courbot 
> ---
> Changes from v1:
> - amended documentation following Stephen's suggestion
> - allow parsing of bitfields larger than 9 bits
> - made it clear that the parsing order of bits is changed with respect
>   to the original patch
> 
> Andrew, since this patch introduces a (small) change in the DT bindings,
> could we try to merge it during the -rc cycle so we don't have to come
> with a more complex solution in the future?

So, I think we shouldn't change the DT binding at all now. The original
driver is now merged for 3.10, and I think it's far too late to take
code that implements new features for 3.10. This means that we couldn't
merge this patch until 3.11. However, by then, we shouldn't be changing
the DT binding in incompatible ways. Olof has already published some
U-Boot binaries that use the current binding, and on IRC indicated he'd
prefer not to change the binding because of that.

As such, we should either:

a) Just add new entries into the format array that already exists in the
driver. Given David's response, this might be simplest.

b) Extend the DT binding in a 100% backwards-compatible way, which would
mean defaulting the bit-order to match the existing 1 format, and adding
a new Boolean property to indicate that the format string is specified
in the other order.
--
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/


[54/94] sunrpc: clarify comments on rpc_make_runnable

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Jeff Layton 

commit 506026c3ec270e18402f0c9d33fee37482c23861 upstream.

rpc_make_runnable is not generally called with the queue lock held, unless
it's waking up a task that has been sitting on a waitqueue. This is safe
when the task has not entered the FSM yet, but the comments don't really
spell this out.

Signed-off-by: Jeff Layton 
Signed-off-by: Trond Myklebust 
Signed-off-by: Ben Hutchings 
---
 net/sunrpc/sched.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- a/net/sunrpc/sched.c
+++ b/net/sunrpc/sched.c
@@ -296,8 +296,9 @@ EXPORT_SYMBOL_GPL(__rpc_wait_for_complet
 /*
  * Make an RPC task runnable.
  *
- * Note: If the task is ASYNC, this must be called with
- * the spinlock held to protect the wait queue operation.
+ * Note: If the task is ASYNC, and is being made runnable after sitting on an
+ * rpc_wait_queue, this must be called with the queue spinlock held to protect
+ * the wait queue operation.
  */
 static void rpc_make_runnable(struct rpc_task *task)
 {

--
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/


[08/94] ath9k: fix key allocation error handling for powersave keys

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Felix Fietkau 

commit 4ef69d0394cba8caa9f75d3f2e53429bfb8b3045 upstream.

If no keycache slots are available, ath_key_config can return -ENOSPC.
If the key index is not checked for errors, it can lead to logspam that
looks like this: "ath: wiphy0: keyreset: keycache entry 228 out of range"
This can cause follow-up errors if the invalid keycache index gets
used for tx.

Signed-off-by: Felix Fietkau 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings 
---
 drivers/net/wireless/ath/ath9k/main.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1793,6 +1793,7 @@ static int ath9k_sta_add(struct ieee8021
struct ath_common *common = ath9k_hw_common(sc->sc_ah);
struct ath_node *an = (struct ath_node *) sta->drv_priv;
struct ieee80211_key_conf ps_key = { };
+   int key;
 
ath_node_attach(sc, sta);
 
@@ -1800,7 +1801,9 @@ static int ath9k_sta_add(struct ieee8021
vif->type != NL80211_IFTYPE_AP_VLAN)
return 0;
 
-   an->ps_key = ath_key_config(common, vif, sta, _key);
+   key = ath_key_config(common, vif, sta, _key);
+   if (key > 0)
+   an->ps_key = key;
 
return 0;
 }
@@ -1817,6 +1820,7 @@ static void ath9k_del_ps_key(struct ath_
return;
 
ath_key_delete(common, _key);
+   an->ps_key = 0;
 }
 
 static int ath9k_sta_remove(struct ieee80211_hw *hw,

--
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/


[30/94] hwmon: fix error return code in abituguru_probe()

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Wei Yongjun 

commit ecacb0b17c08fae89f65468727f0e4b8e91da4e1 upstream.

Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.

Signed-off-by: Wei Yongjun 
Signed-off-by: Guenter Roeck 
Signed-off-by: Ben Hutchings 
---
 drivers/hwmon/abituguru.c |   16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

--- a/drivers/hwmon/abituguru.c
+++ b/drivers/hwmon/abituguru.c
@@ -1280,14 +1280,18 @@ static int __devinit abituguru_probe(str
pr_info("found Abit uGuru\n");
 
/* Register sysfs hooks */
-   for (i = 0; i < sysfs_attr_i; i++)
-   if (device_create_file(>dev,
-   >sysfs_attr[i].dev_attr))
+   for (i = 0; i < sysfs_attr_i; i++) {
+   res = device_create_file(>dev,
+>sysfs_attr[i].dev_attr);
+   if (res)
goto abituguru_probe_error;
-   for (i = 0; i < ARRAY_SIZE(abituguru_sysfs_attr); i++)
-   if (device_create_file(>dev,
-   _sysfs_attr[i].dev_attr))
+   }
+   for (i = 0; i < ARRAY_SIZE(abituguru_sysfs_attr); i++) {
+   res = device_create_file(>dev,
+_sysfs_attr[i].dev_attr);
+   if (res)
goto abituguru_probe_error;
+   }
 
data->hwmon_dev = hwmon_device_register(>dev);
if (!IS_ERR(data->hwmon_dev))

--
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/


[29/94] staging: vt6656: use free_netdev instead of kfree

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Hema Prathaban 

commit 0a438d5b381e2bdfd5e02d653bf46fcc878356e3 upstream.

use free_netdev() instead of kfree(pDevice->apdev)

Signed-off-by: Hema Prathaban 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
---
 drivers/staging/vt6656/hostap.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/staging/vt6656/hostap.c
+++ b/drivers/staging/vt6656/hostap.c
@@ -153,7 +153,7 @@ static int hostap_disable_hostapd(PSDevi
 DBG_PRT(MSG_LEVEL_DEBUG, KERN_INFO "%s: Netdevice %s 
unregistered\n",
   pDevice->dev->name, pDevice->apdev->name);
}
-   kfree(pDevice->apdev);
+   free_netdev(pDevice->apdev);
pDevice->apdev = NULL;
 pDevice->bEnable8021x = FALSE;
 pDevice->bEnableHostWEP = FALSE;

--
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/


[48/94] USB: ftdi_sio: Add support for Newport CONEX motor drivers

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: "Gomella, Andrew (NIH/NHLBI) [F]" 

commit 7138143972b7c293267c783fc99a194f0ceff7f2 upstream.

Here are two more devices that use FTDI USB-to-serial chips with new product 
ID's.

The devices are the Newport Conex-AGP and Conex-CC motor controllers.
(http://www.newport.com/CONEX-AGP-Integrated-Piezo-Motor-Rotation-Stages-/987623/1033/info.aspx)
(http://www.newport.com/CONEX-CC-DC-Servo-Controller-Actuators/934114/1033/info.aspx)

usb-devices command yields:

P:  Vendor=104d ProdID=3002 Rev=06.00
S:  Manufacturer=Newport
S:  Product=CONEX-CC

as well as

P:  Vendor=104d ProdID=3006 Rev=06.00
S:  Manufacturer=Newport
S:  Product=CONEX-AGP

Signed-off-by: Andrew Gomella 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
---
 drivers/usb/serial/ftdi_sio.c |2 ++
 drivers/usb/serial/ftdi_sio_ids.h |2 ++
 2 files changed, 4 insertions(+)

--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -197,6 +197,8 @@ static struct usb_device_id id_table_com
{ USB_DEVICE(FTDI_VID, FTDI_OPENDCC_GBM_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_OPENDCC_GBM_BOOST_PID) },
{ USB_DEVICE(NEWPORT_VID, NEWPORT_AGILIS_PID) },
+   { USB_DEVICE(NEWPORT_VID, NEWPORT_CONEX_CC_PID) },
+   { USB_DEVICE(NEWPORT_VID, NEWPORT_CONEX_AGP_PID) },
{ USB_DEVICE(INTERBIOMETRICS_VID, INTERBIOMETRICS_IOBOARD_PID) },
{ USB_DEVICE(INTERBIOMETRICS_VID, INTERBIOMETRICS_MINI_IOBOARD_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_SPROG_II) },
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -772,6 +772,8 @@
  */
 #define NEWPORT_VID0x104D
 #define NEWPORT_AGILIS_PID 0x3000
+#define NEWPORT_CONEX_CC_PID   0x3002
+#define NEWPORT_CONEX_AGP_PID  0x3006
 
 /* Interbiometrics USB I/O Board */
 /* Developed for Interbiometrics by Rudolf Gugler */

--
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/


[94/94] um: Serve io_remap_pfn_range()

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Richard Weinberger 

commit 4d94d6d030adfdea4837694d293ec6918d133ab2 upstream.

At some places io_remap_pfn_range() is needed.
UML has to serve it like all other archs do.

Signed-off-by: Richard Weinberger 
Signed-off-by: Ben Hutchings 
---
 arch/um/include/asm/pgtable.h |2 ++
 1 file changed, 2 insertions(+)

--- a/arch/um/include/asm/pgtable.h
+++ b/arch/um/include/asm/pgtable.h
@@ -69,6 +69,8 @@ extern unsigned long end_iomem;
 #define PAGE_KERNEL__pgprot(_PAGE_PRESENT | _PAGE_RW | _PAGE_DIRTY | 
_PAGE_ACCESSED)
 #define PAGE_KERNEL_EXEC   __pgprot(__PAGE_KERNEL_EXEC)
 
+#define io_remap_pfn_range remap_pfn_range
+
 /*
  * The i386 can't do page protection for execute, and considers that the same
  * are read.

--
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/


[92/94] [media] mantis: fix silly crash case

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Alan Cox 

commit e1d45ae10aea8e8a403e5d96bf5902ee670007ff upstream.

If we set mantis->fe to NULL on an error its not a good idea to then try
passing NULL to the unregister paths and oopsing really.

Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=16473

Signed-off-by: Alan Cox 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Ben Hutchings 
---
 drivers/media/dvb/mantis/mantis_dvb.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/media/dvb/mantis/mantis_dvb.c
+++ b/drivers/media/dvb/mantis/mantis_dvb.c
@@ -248,8 +248,10 @@ int __devinit mantis_dvb_init(struct man
 err5:
tasklet_kill(>tasklet);
dvb_net_release(>dvbnet);
-   dvb_unregister_frontend(mantis->fe);
-   dvb_frontend_detach(mantis->fe);
+   if (mantis->fe) {
+   dvb_unregister_frontend(mantis->fe);
+   dvb_frontend_detach(mantis->fe);
+   }
 err4:
mantis->demux.dmx.remove_frontend(>demux.dmx, >fe_mem);
 

--
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/


[07/94] ASoC: wm8994: missing break in wm8994_aif3_hw_params()

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Dan Carpenter 

commit 4495e46fe18f198366961bb2b324a694ef8a9b44 upstream.

The missing break here means that we always return early and the
function is a no-op.

Signed-off-by: Dan Carpenter 
Signed-off-by: Mark Brown 
Signed-off-by: Ben Hutchings 
---
 sound/soc/codecs/wm8994.c |1 +
 1 file changed, 1 insertion(+)

--- a/sound/soc/codecs/wm8994.c
+++ b/sound/soc/codecs/wm8994.c
@@ -2636,6 +2636,7 @@ static int wm8994_aif3_hw_params(struct
default:
return 0;
}
+   break;
default:
return 0;
}

--
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/


[40/94] usermodehelper: check subprocess_info->path != NULL

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Oleg Nesterov 

commit 264b83c07a84223f0efd0d1db9ccc66d6f88288f upstream.

argv_split(empty_or_all_spaces) happily succeeds, it simply returns
argc == 0 and argv[0] == NULL. Change call_usermodehelper_exec() to
check sub_info->path != NULL to avoid the crash.

This is the minimal fix, todo:

 - perhaps we should change argv_split() to return NULL or change the
   callers.

 - kill or justify ->path[0] check

 - narrow the scope of helper_lock()

Signed-off-by: Oleg Nesterov 
Acked-By: Lucas De Marchi 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings 
---
 kernel/kmod.c |5 +
 1 file changed, 5 insertions(+)

--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -467,6 +467,11 @@ int call_usermodehelper_exec(struct subp
int retval = 0;
 
helper_lock();
+   if (!sub_info->path) {
+   retval = -EINVAL;
+   goto out;
+   }
+
if (sub_info->path[0] == '\0')
goto out;
 

--
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/


[59/94] fat: fix possible overflow for fat_clusters

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: OGAWA Hirofumi 

commit 7b92d03c3239f43e5b86c9cc9630f026d36ee995 upstream.

Intermediate value of fat_clusters can be overflowed on 32bits arch.

Reported-by: Krzysztof Strasburger 
Signed-off-by: OGAWA Hirofumi 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings 
---
 fs/fat/inode.c |   15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

--- a/fs/fat/inode.c
+++ b/fs/fat/inode.c
@@ -1238,6 +1238,19 @@ static int fat_read_root(struct inode *i
return 0;
 }
 
+static unsigned long calc_fat_clusters(struct super_block *sb)
+{
+   struct msdos_sb_info *sbi = MSDOS_SB(sb);
+
+   /* Divide first to avoid overflow */
+   if (sbi->fat_bits != 12) {
+   unsigned long ent_per_sec = sb->s_blocksize * 8 / sbi->fat_bits;
+   return ent_per_sec * sbi->fat_length;
+   }
+
+   return sbi->fat_length * sb->s_blocksize * 8 / sbi->fat_bits;
+}
+
 /*
  * Read the super block of an MS-DOS FS.
  */
@@ -1434,7 +1447,7 @@ int fat_fill_super(struct super_block *s
sbi->fat_bits = (total_clusters > MAX_FAT12) ? 16 : 12;
 
/* check that FAT table does not overflow */
-   fat_clusters = sbi->fat_length * sb->s_blocksize * 8 / sbi->fat_bits;
+   fat_clusters = calc_fat_clusters(sb);
total_clusters = min(total_clusters, fat_clusters - FAT_START_ENT);
if (total_clusters > MAX_FAT(sb)) {
if (!silent)

--
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/


[77/94] efi: Export efi_query_variable_store() for efivars.ko

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Sergey Vlasov 

commit 3668011d4ad556224f7c012c1e870a6eaa0e59da upstream.

Fixes build with CONFIG_EFI_VARS=m which was broken after the commit
"x86, efivars: firmware bug workarounds should be in platform code".

Signed-off-by: Sergey Vlasov 
Signed-off-by: Matt Fleming 
Signed-off-by: Ben Hutchings 
---
 arch/x86/platform/efi/efi.c |1 +
 1 file changed, 1 insertion(+)

--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -840,3 +840,4 @@ efi_status_t efi_query_variable_store(u3
 
return EFI_SUCCESS;
 }
+EXPORT_SYMBOL_GPL(efi_query_variable_store);

--
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/


[15/94] iscsi-target: Fix processing of OOO commands

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Shlomo Pongratz 

commit 3eccfdb01da58fbd0f789ae6ca61cee3769e26de upstream.

Fix two issues in OOO commands processing done at iscsit_attach_ooo_cmdsn.

Handle command serial numbers wrap around by using iscsi_sna_lt and not regular 
comparisson.

The routine iterates until it finds an entry whose serial number is greater 
than the serial number of
the new one, thus the new entry should be inserted before that entry and not 
after.

Signed-off-by: Shlomo Pongratz 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Ben Hutchings 
---
 drivers/target/iscsi/iscsi_target_erl1.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

--- a/drivers/target/iscsi/iscsi_target_erl1.c
+++ b/drivers/target/iscsi/iscsi_target_erl1.c
@@ -824,7 +824,7 @@ static int iscsit_attach_ooo_cmdsn(
/*
 * CmdSN is greater than the tail of the list.
 */
-   if (ooo_tail->cmdsn < ooo_cmdsn->cmdsn)
+   if (iscsi_sna_lt(ooo_tail->cmdsn, ooo_cmdsn->cmdsn))
list_add_tail(_cmdsn->ooo_list,
>sess_ooo_cmdsn_list);
else {
@@ -834,11 +834,12 @@ static int iscsit_attach_ooo_cmdsn(
 */
list_for_each_entry(ooo_tmp, >sess_ooo_cmdsn_list,
ooo_list) {
-   if (ooo_tmp->cmdsn < ooo_cmdsn->cmdsn)
+   if (iscsi_sna_lt(ooo_tmp->cmdsn, 
ooo_cmdsn->cmdsn))
continue;
 
+   /* Insert before this entry */
list_add(_cmdsn->ooo_list,
-   _tmp->ooo_list);
+   ooo_tmp->ooo_list.prev);
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/


[41/94] drivers/char/ipmi: memcpy, need additional 2 bytes to avoid memory overflow

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Chen Gang 

commit a5f2b3d6a738e7d4180012fe7b541172f8c8dcea upstream.

When calling memcpy, read_data and write_data need additional 2 bytes.

  write_data:
for checking:  "if (size > IPMI_MAX_MSG_LENGTH)"
for operating: "memcpy(bt->write_data + 3, data + 1, size - 1)"

  read_data:
for checking:  "if (msg_len < 3 || msg_len > IPMI_MAX_MSG_LENGTH)"
for operating: "memcpy(data + 2, bt->read_data + 4, msg_len - 2)"

Signed-off-by: Chen Gang 
Signed-off-by: Corey Minyard 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings 
---
 drivers/char/ipmi/ipmi_bt_sm.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/char/ipmi/ipmi_bt_sm.c
+++ b/drivers/char/ipmi/ipmi_bt_sm.c
@@ -95,9 +95,9 @@ struct si_sm_data {
enum bt_states  state;
unsigned char   seq;/* BT sequence number */
struct si_sm_io *io;
-   unsigned char   write_data[IPMI_MAX_MSG_LENGTH];
+   unsigned char   write_data[IPMI_MAX_MSG_LENGTH + 2]; /* +2 for memcpy */
int write_count;
-   unsigned char   read_data[IPMI_MAX_MSG_LENGTH];
+   unsigned char   read_data[IPMI_MAX_MSG_LENGTH + 2]; /* +2 for memcpy */
int read_count;
int truncated;
longtimeout;/* microseconds countdown */

--
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/


[16/94] ACPICA: Fix possible buffer overflow during a field unit read operation

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Bob Moore 

commit 61388f9e5d93053cf399a356414f31f9b4814c6d upstream.

Can only happen under these conditions: 1) The DSDT version is 1,
meaning integers are 32-bits.  2) The field is between 33 and 64
bits long.

It applies cleanly back to ACPICA 20100806+ (Linux v2.6.37+).

Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Ben Hutchings 
---
 drivers/acpi/acpica/exfldio.c |   14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

--- a/drivers/acpi/acpica/exfldio.c
+++ b/drivers/acpi/acpica/exfldio.c
@@ -702,7 +702,19 @@ acpi_ex_extract_from_field(union acpi_op
 
if ((obj_desc->common_field.start_field_bit_offset == 0) &&
(obj_desc->common_field.bit_length == access_bit_width)) {
-   status = acpi_ex_field_datum_io(obj_desc, 0, buffer, ACPI_READ);
+   if (buffer_length >= sizeof(u64)) {
+   status =
+   acpi_ex_field_datum_io(obj_desc, 0, buffer,
+  ACPI_READ);
+   } else {
+   /* Use raw_datum (u64) to handle buffers < 64 bits */
+
+   status =
+   acpi_ex_field_datum_io(obj_desc, 0, _datum,
+  ACPI_READ);
+   ACPI_MEMCPY(buffer, _datum, buffer_length);
+   }
+
return_ACPI_STATUS(status);
}
 

--
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/


[45/94] USB: Blacklisted Cinterion's PLxx WWAN Interface

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Schemmel Hans-Christoph 

commit 8ff10bdb14a52e3f25d4ce09e0582a8684c1a6db upstream.

/drivers/usb/serial/option.c: Blacklisted Cinterion's PLxx WWAN
Interface (USB Interface 4), because it will be handled by QMI WWAN
driver. Product IDs renamed.

Signed-off-by: Hans-Christoph Schemmel 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
---
 drivers/usb/serial/option.c |9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -341,8 +341,8 @@ static void option_instat_callback(struc
 #define CINTERION_PRODUCT_EU3_E0x0051
 #define CINTERION_PRODUCT_EU3_P0x0052
 #define CINTERION_PRODUCT_PH8  0x0053
-#define CINTERION_PRODUCT_AH6  0x0055
-#define CINTERION_PRODUCT_PLS8 0x0060
+#define CINTERION_PRODUCT_AHXX 0x0055
+#define CINTERION_PRODUCT_PLXX 0x0060
 
 /* Olivetti products */
 #define OLIVETTI_VENDOR_ID 0x0b3c
@@ -1266,8 +1266,9 @@ static const struct usb_device_id option
{ USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_EU3_E) },
{ USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_EU3_P) },
{ USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_PH8) },
-   { USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_AH6) },
-   { USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_PLS8) },
+   { USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_AHXX) },
+   { USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_PLXX),
+   .driver_info = (kernel_ulong_t)_intf4_blacklist },
{ USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_HC28_MDM) }, 
{ USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_HC28_MDMNET) },
{ USB_DEVICE(SIEMENS_VENDOR_ID, CINTERION_PRODUCT_HC25_MDM) },

--
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/


[50/94] virtio_console: fix uapi header

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: "Michael S. Tsirkin" 

commit 6407d75afd08545f2252bb39806ffd3f10c7faac upstream.

uapi should use __u32 not u32.
Fix a macro in virtio_console.h which uses u32.

Signed-off-by: Michael S. Tsirkin 
Signed-off-by: Rusty Russell 
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings 
---
 include/linux/virtio_console.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/include/linux/virtio_console.h
+++ b/include/linux/virtio_console.h
@@ -39,7 +39,7 @@
 #define VIRTIO_CONSOLE_F_SIZE  0   /* Does host provide console size? */
 #define VIRTIO_CONSOLE_F_MULTIPORT 1   /* Does host provide multiple ports? */
 
-#define VIRTIO_CONSOLE_BAD_ID  (~(u32)0)
+#define VIRTIO_CONSOLE_BAD_ID  (~(__u32)0)
 
 struct virtio_console_config {
/* colums of the screens */

--
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/


[47/94] i2c: designware: always clear interrupts before enabling them

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Mika Westerberg 

commit 2a2d95e9d6d29e726cc294b65391917ed2e32bf4 upstream.

If the I2C bus is put to a low power state by an ACPI method it might pull
the SDA line low (as its power is removed). Once the bus is put to full
power state again, the SDA line is pulled back to high. This transition
looks like a STOP condition from the controller point-of-view which sets
STOP detected bit in its status register causing the driver to fail
subsequent transfers.

Fix this by always clearing all interrupts before we start a transfer.

Signed-off-by: Mika Westerberg 
Signed-off-by: Wolfram Sang 
Signed-off-by: Ben Hutchings 
---
 drivers/i2c/busses/i2c-designware-core.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/i2c/busses/i2c-designware-core.c
+++ b/drivers/i2c/busses/i2c-designware-core.c
@@ -349,7 +349,8 @@ static void i2c_dw_xfer_init(struct dw_i
/* Enable the adapter */
dw_writel(dev, 1, DW_IC_ENABLE);
 
-   /* Enable interrupts */
+   /* Clear and enable interrupts */
+   i2c_dw_clear_int(dev);
dw_writel(dev, DW_IC_INTR_DEFAULT_MASK, DW_IC_INTR_MASK);
 }
 

--
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/


[19/94] mwifiex: fix memory leak issue when driver unload

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Amitkumar Karwar 

commit f16fdc9d2dc1e5b270e9a08377587e831e0d36ac upstream.

After unregister_netdevice() call the request is queued and
reg_state is changed to NETREG_UNREGISTERING.
As we check for NETREG_UNREGISTERED state, free_netdev() never
gets executed causing memory leak.

Initialize "dev->destructor" to free_netdev() to free device
data after unregistration.

Reported-by: Daniel Drake 
Tested-by: Daniel Drake 
Signed-off-by: Amitkumar Karwar 
Signed-off-by: Bing Zhao 
Signed-off-by: John W. Linville 
[bwh: Backported to 3.2: s/wdev->netdev/dev/]
Signed-off-by: Ben Hutchings 
---
 drivers/net/wireless/mwifiex/cfg80211.c |3 ---
 drivers/net/wireless/mwifiex/main.c |1 +
 2 files changed, 1 insertion(+), 3 deletions(-)

--- a/drivers/net/wireless/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/mwifiex/cfg80211.c
@@ -1281,9 +1281,6 @@ int mwifiex_del_virtual_intf(struct wiph
if (dev->reg_state == NETREG_REGISTERED)
unregister_netdevice(dev);
 
-   if (dev->reg_state == NETREG_UNREGISTERED)
-   free_netdev(dev);
-
/* Clear the priv in adapter */
priv->netdev = NULL;
 
--- a/drivers/net/wireless/mwifiex/main.c
+++ b/drivers/net/wireless/mwifiex/main.c
@@ -581,6 +581,7 @@ void mwifiex_init_priv_params(struct mwi
struct net_device *dev)
 {
dev->netdev_ops = _netdev_ops;
+   dev->destructor = free_netdev;
/* Initialize private structure */
priv->current_key_index = 0;
priv->media_connected = false;

--
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/


[22/94] hp_accel: Ignore the error from lis3lv02d_poweron() at resume

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Shuah Khan 

commit 7783819920ca52fc582a2782f654fe6ed373f465 upstream.

The error in lis3lv02_poweron() is harmless in the resume path, so
we should ignore it. It is inline with the other usages of lis3lv02_poweron()
and matches the 3.0 code for this routine. This patch is in suse git and
might have missed making it into the mainline.
opensuse - commit id: 66ccdac87c322cf7af12bddba8c805af640b1cff

Signed-off-by: Takashi Iwai 
Signed-off-by: Shuah Khan 
Signed-off-by: Matthew Garrett 
Signed-off-by: Ben Hutchings 
---
 drivers/platform/x86/hp_accel.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/platform/x86/hp_accel.c
+++ b/drivers/platform/x86/hp_accel.c
@@ -362,7 +362,8 @@ static int lis3lv02d_suspend(struct acpi
 
 static int lis3lv02d_resume(struct acpi_device *device)
 {
-   return lis3lv02d_poweron(_dev);
+   lis3lv02d_poweron(_dev);
+   return 0;
 }
 #else
 #define lis3lv02d_suspend NULL

--
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/


[46/94] USB: option: add device IDs for Dell 5804 (Novatel E371) WWAN card

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Dan Williams 

commit 49c6e370dd6400b84897c4100095089b5c13a061 upstream.

A rebranded Novatel E371 for AT's LTE bands.

Signed-off-by: Dan Williams 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
---
 drivers/usb/serial/option.c |2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -196,6 +196,7 @@ static void option_instat_callback(struc
 
 #define DELL_PRODUCT_5800_MINICARD_VZW 0x8195  /* Novatel E362 */
 #define DELL_PRODUCT_5800_V2_MINICARD_VZW  0x8196  /* Novatel E362 */
+#define DELL_PRODUCT_5804_MINICARD_ATT 0x819b  /* Novatel E371 */
 
 #define KYOCERA_VENDOR_ID  0x0c88
 #define KYOCERA_PRODUCT_KPC650 0x17da
@@ -771,6 +772,7 @@ static const struct usb_device_id option
{ USB_DEVICE(DELL_VENDOR_ID, DELL_PRODUCT_5730_MINICARD_VZW) }, 
/* Dell Wireless 5730 Mobile Broadband EVDO/HSPA Mini-Card */
{ USB_DEVICE_AND_INTERFACE_INFO(DELL_VENDOR_ID, 
DELL_PRODUCT_5800_MINICARD_VZW, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(DELL_VENDOR_ID, 
DELL_PRODUCT_5800_V2_MINICARD_VZW, 0xff, 0xff, 0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(DELL_VENDOR_ID, 
DELL_PRODUCT_5804_MINICARD_ATT, 0xff, 0xff, 0xff) },
{ USB_DEVICE(ANYDATA_VENDOR_ID, ANYDATA_PRODUCT_ADU_E100A) },   /* 
ADU-E100, ADU-310 */
{ USB_DEVICE(ANYDATA_VENDOR_ID, ANYDATA_PRODUCT_ADU_500A) },
{ USB_DEVICE(ANYDATA_VENDOR_ID, ANYDATA_PRODUCT_ADU_620UW) },

--
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/


[26/94] tick: Cleanup NOHZ per cpu data on cpu down

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Thomas Gleixner 

commit 4b0c0f294f60abcdd20994a8341a95c8ac5eeb96 upstream.

Prarit reported a crash on CPU offline/online. The reason is that on
CPU down the NOHZ related per cpu data of the dead cpu is not cleaned
up. If at cpu online an interrupt happens before the per cpu tick
device is registered the irq_enter() check potentially sees stale data
and dereferences a NULL pointer.

Cleanup the data after the cpu is dead.

Reported-by: Prarit Bhargava 
Cc: Mike Galbraith 
Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1305031451561.2886@ionos
Signed-off-by: Thomas Gleixner 
Signed-off-by: Ben Hutchings 
---
 kernel/time/tick-sched.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -833,7 +833,7 @@ void tick_cancel_sched_timer(int cpu)
hrtimer_cancel(>sched_timer);
 # endif
 
-   ts->nohz_mode = NOHZ_MODE_INACTIVE;
+   memset(ts, 0, sizeof(*ts));
 }
 #endif
 

--
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/


[71/94] sched/debug: Limit sd->*_idx range on sysctl

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Namhyung Kim 

commit 201c373e8e4823700d3160d5c28e1ab18fd1193e upstream.

Various sd->*_idx's are used for refering the rq's load average table
when selecting a cpu to run.  However they can be set to any number
with sysctl knobs so that it can crash the kernel if something bad is
given. Fix it by limiting them into the actual range.

Signed-off-by: Namhyung Kim 
Signed-off-by: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1345104204-8317-1-git-send-email-namhy...@kernel.org
Signed-off-by: Ingo Molnar 
[bwh: Backported to 3.2:
 - Adjust filename
 - s/umode_t/mode_t/]
Signed-off-by: Ben Hutchings 
---
 kernel/sched.c |   35 ++-
 1 file changed, 22 insertions(+), 13 deletions(-)

--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -6672,16 +6672,25 @@ static void sd_free_ctl_entry(struct ctl
*tablep = NULL;
 }
 
+static int min_load_idx = 0;
+static int max_load_idx = CPU_LOAD_IDX_MAX;
+
 static void
 set_table_entry(struct ctl_table *entry,
const char *procname, void *data, int maxlen,
-   mode_t mode, proc_handler *proc_handler)
+   mode_t mode, proc_handler *proc_handler,
+   bool load_idx)
 {
entry->procname = procname;
entry->data = data;
entry->maxlen = maxlen;
entry->mode = mode;
entry->proc_handler = proc_handler;
+
+   if (load_idx) {
+   entry->extra1 = _load_idx;
+   entry->extra2 = _load_idx;
+   }
 }
 
 static struct ctl_table *
@@ -6693,30 +6702,30 @@ sd_alloc_ctl_domain_table(struct sched_d
return NULL;
 
set_table_entry([0], "min_interval", >min_interval,
-   sizeof(long), 0644, proc_doulongvec_minmax);
+   sizeof(long), 0644, proc_doulongvec_minmax, false);
set_table_entry([1], "max_interval", >max_interval,
-   sizeof(long), 0644, proc_doulongvec_minmax);
+   sizeof(long), 0644, proc_doulongvec_minmax, false);
set_table_entry([2], "busy_idx", >busy_idx,
-   sizeof(int), 0644, proc_dointvec_minmax);
+   sizeof(int), 0644, proc_dointvec_minmax, true);
set_table_entry([3], "idle_idx", >idle_idx,
-   sizeof(int), 0644, proc_dointvec_minmax);
+   sizeof(int), 0644, proc_dointvec_minmax, true);
set_table_entry([4], "newidle_idx", >newidle_idx,
-   sizeof(int), 0644, proc_dointvec_minmax);
+   sizeof(int), 0644, proc_dointvec_minmax, true);
set_table_entry([5], "wake_idx", >wake_idx,
-   sizeof(int), 0644, proc_dointvec_minmax);
+   sizeof(int), 0644, proc_dointvec_minmax, true);
set_table_entry([6], "forkexec_idx", >forkexec_idx,
-   sizeof(int), 0644, proc_dointvec_minmax);
+   sizeof(int), 0644, proc_dointvec_minmax, true);
set_table_entry([7], "busy_factor", >busy_factor,
-   sizeof(int), 0644, proc_dointvec_minmax);
+   sizeof(int), 0644, proc_dointvec_minmax, false);
set_table_entry([8], "imbalance_pct", >imbalance_pct,
-   sizeof(int), 0644, proc_dointvec_minmax);
+   sizeof(int), 0644, proc_dointvec_minmax, false);
set_table_entry([9], "cache_nice_tries",
>cache_nice_tries,
-   sizeof(int), 0644, proc_dointvec_minmax);
+   sizeof(int), 0644, proc_dointvec_minmax, false);
set_table_entry([10], "flags", >flags,
-   sizeof(int), 0644, proc_dointvec_minmax);
+   sizeof(int), 0644, proc_dointvec_minmax, false);
set_table_entry([11], "name", sd->name,
-   CORENAME_MAX_SIZE, 0444, proc_dostring);
+   CORENAME_MAX_SIZE, 0444, proc_dostring, false);
/* [12] is terminator */
 
return table;

--
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/


[38/94] USB: UHCI: fix for suspend of virtual HP controller

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Alan Stern 

commit 997ff893603c6455da4c5e26ba1d0f81adfecdfc upstream.

HP's virtual UHCI host controller takes a long time to suspend
(several hundred microseconds), even when no devices are attached.
This provokes a warning message from uhci-hcd in the auto-stop case.

To prevent this from happening, this patch adds a test to avoid
performing an auto-stop when the wait_for_hp quirk flag is set.  The
controller will still suspend through the normal runtime PM mechanism.
And since that pathway includes a 1-ms delay, the slowness of the
virtual hardware won't matter.

Signed-off-by: Alan Stern 
Reported-and-tested-by: ZhenHua 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
---
 drivers/usb/host/uhci-hub.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/usb/host/uhci-hub.c
+++ b/drivers/usb/host/uhci-hub.c
@@ -221,7 +221,8 @@ static int uhci_hub_status_data(struct u
/* auto-stop if nothing connected for 1 second */
if (any_ports_active(uhci))
uhci->rh_state = UHCI_RH_RUNNING;
-   else if (time_after_eq(jiffies, uhci->auto_stop_time))
+   else if (time_after_eq(jiffies, uhci->auto_stop_time) &&
+   !uhci->wait_for_hp)
suspend_rh(uhci, UHCI_RH_AUTO_STOPPED);
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/


[05/94] mmc: atmel-mci: pio hang on block errors

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Terry Barnaby 

commit bdbc5d0c60f3e9de3eeccf1c1a18bdc11dca62cc upstream.

The driver is doing, by default, multi-block reads. When a block error
occurs, card/block.c instigates a single block read: "mmcblk0: retrying
using single block read".  It leaves the sg chain intact and just changes
the length attribute for the first sg entry and the overall sg_len
parameter.  When atmci_read_data_pio is called to read the single block
of data it ignores the sg_len and expects to read more than 512 bytes as
it sees there are multiple items in the sg list. No more data comes as
the controller has only been commanded to get one block.

Signed-off-by: Terry Barnaby 
Acked-by: Ludovic Desroches 
Signed-off-by: Chris Ball 
Signed-off-by: Ben Hutchings 
---
 drivers/mmc/host/atmel-mci.c |   14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

--- a/drivers/mmc/host/atmel-mci.c
+++ b/drivers/mmc/host/atmel-mci.c
@@ -163,6 +163,7 @@ struct atmel_mci {
void __iomem*regs;
 
struct scatterlist  *sg;
+   unsigned intsg_len;
unsigned intpio_offset;
 
struct atmel_mci_slot   *cur_slot;
@@ -751,6 +752,7 @@ static u32 atmci_prepare_data(struct atm
data->error = -EINPROGRESS;
 
host->sg = data->sg;
+   host->sg_len = data->sg_len;
host->data = data;
host->data_chan = NULL;
 
@@ -1573,7 +1575,8 @@ static void atmci_read_data_pio(struct a
if (offset == sg->length) {
flush_dcache_page(sg_page(sg));
host->sg = sg = sg_next(sg);
-   if (!sg)
+   host->sg_len--;
+   if (!sg || !host->sg_len)
goto done;
 
offset = 0;
@@ -1586,7 +1589,8 @@ static void atmci_read_data_pio(struct a
 
flush_dcache_page(sg_page(sg));
host->sg = sg = sg_next(sg);
-   if (!sg)
+   host->sg_len--;
+   if (!sg || !host->sg_len)
goto done;
 
offset = 4 - remaining;
@@ -1640,7 +1644,8 @@ static void atmci_write_data_pio(struct
nbytes += 4;
if (offset == sg->length) {
host->sg = sg = sg_next(sg);
-   if (!sg)
+   host->sg_len--;
+   if (!sg || !host->sg_len)
goto done;
 
offset = 0;
@@ -1654,7 +1659,8 @@ static void atmci_write_data_pio(struct
nbytes += remaining;
 
host->sg = sg = sg_next(sg);
-   if (!sg) {
+   host->sg_len--;
+   if (!sg || !host->sg_len) {
atmci_writel(host, ATMCI_TDR, value);
goto done;
}

--
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/


[65/94] drivers/block/brd.c: fix brd_lookup_page() race

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Brian Behlendorf 

commit dfd20b2b174d3a9b258ea3b7a35ead33576587b1 upstream.

The index on the page must be set before it is inserted in the radix
tree.  Otherwise there is a small race which can occur during lookup
where the page can be found with the incorrect index.  This will trigger
the BUG_ON() in brd_lookup_page().

Signed-off-by: Brian Behlendorf 
Reported-by: Chris Wedgwood 
Cc: Jens Axboe 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings 
---
 drivers/block/brd.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/block/brd.c
+++ b/drivers/block/brd.c
@@ -117,13 +117,13 @@ static struct page *brd_insert_page(stru
 
spin_lock(>brd_lock);
idx = sector >> PAGE_SECTORS_SHIFT;
+   page->index = idx;
if (radix_tree_insert(>brd_pages, idx, page)) {
__free_page(page);
page = radix_tree_lookup(>brd_pages, idx);
BUG_ON(!page);
BUG_ON(page->index != idx);
-   } else
-   page->index = idx;
+   }
spin_unlock(>brd_lock);
 
radix_tree_preload_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/


[74/94] pch_dma: Use GFP_ATOMIC because called from interrupt context

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Tomoya MORINAGA 

commit 5c1ef59168c485318e40ba485c1eba57d81d0faa upstream.

pdc_desc_get() is called from pd_prep_slave_sg, and the function is
called from interrupt context(e.g. Uart driver "pch_uart.c").
In fact, I saw kernel error message.
So, GFP_ATOMIC must be used not GFP_NOIO.

Signed-off-by: Tomoya MORINAGA 
Signed-off-by: Vinod Koul 
Signed-off-by: Ben Hutchings 
---
 drivers/dma/pch_dma.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/dma/pch_dma.c
+++ b/drivers/dma/pch_dma.c
@@ -489,7 +489,7 @@ static struct pch_dma_desc *pdc_desc_get
dev_dbg(chan2dev(_chan->chan), "scanned %d descriptors\n", i);
 
if (!ret) {
-   ret = pdc_alloc_desc(_chan->chan, GFP_NOIO);
+   ret = pdc_alloc_desc(_chan->chan, GFP_ATOMIC);
if (ret) {
spin_lock(_chan->lock);
pd_chan->descs_allocated++;

--
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/


[23/94] KVM: VMX: fix halt emulation while emulating invalid guest sate

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Gleb Natapov 

commit 8d76c49e9ffeee839bc0b7a3278a23f99101263e upstream.

The invalid guest state emulation loop does not check halt_request
which causes 100% cpu loop while guest is in halt and in invalid
state, but more serious issue is that this leaves halt_request set, so
random instruction emulated by vm86 #GP exit can be interpreted
as halt which causes guest hang. Fix both problems by handling
halt_request in emulation loop.

Reported-by: Tomas Papan 
Tested-by: Tomas Papan 
Reviewed-by: Paolo Bonzini 
Signed-off-by: Gleb Natapov 
Signed-off-by: Ben Hutchings 
---
 arch/x86/kvm/vmx.c |6 ++
 1 file changed, 6 insertions(+)

--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -4882,6 +4882,12 @@ static int handle_invalid_guest_state(st
if (err != EMULATE_DONE)
return 0;
 
+   if (vcpu->arch.halt_request) {
+   vcpu->arch.halt_request = 0;
+   ret = kvm_emulate_halt(vcpu);
+   goto out;
+   }
+
if (signal_pending(current))
goto out;
if (need_resched())

--
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/


[39/94] tracing: Fix leaks of filter preds

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: "Steven Rostedt (Red Hat)" 

commit 60705c89460fdc7227f2d153b68b3f34814738a4 upstream.

Special preds are created when folding a series of preds that
can be done in serial. These are allocated in an ops field of
the pred structure. But they were never freed, causing memory
leaks.

This was discovered using the kmemleak checker:

unreferenced object 0x8800797fd5e0 (size 32):
  comm "swapper/0", pid 1, jiffies 4294690605 (age 104.608s)
  hex dump (first 32 bytes):
00 00 01 00 03 00 05 00 07 00 09 00 0b 00 0d 00  
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  backtrace:
[] kmemleak_alloc+0x73/0x98
[] kmemleak_alloc_recursive.constprop.42+0x16/0x18
[] __kmalloc+0xd7/0x125
[] kcalloc.constprop.24+0x2d/0x2f
[] fold_pred_tree_cb+0xa9/0xf4
[] walk_pred_tree+0x47/0xcc
[] replace_preds.isra.20+0x6f8/0x72f
[] create_filter+0x4e/0x8b
[] ftrace_test_event_filter+0x5a/0x155
[] do_one_initcall+0xa0/0x137
[] kernel_init_freeable+0x14d/0x1dc
[] kernel_init+0xe/0xdb
[] ret_from_fork+0x7c/0xb0
[] 0x

Cc: Tom Zanussi 
Signed-off-by: Steven Rostedt 
Signed-off-by: Ben Hutchings 
---
 kernel/trace/trace_events_filter.c |4 
 1 file changed, 4 insertions(+)

--- a/kernel/trace/trace_events_filter.c
+++ b/kernel/trace/trace_events_filter.c
@@ -769,7 +769,11 @@ static int filter_set_pred(struct event_
 
 static void __free_preds(struct event_filter *filter)
 {
+   int i;
+
if (filter->preds) {
+   for (i = 0; i < filter->n_preds; i++)
+   kfree(filter->preds[i].ops);
kfree(filter->preds);
filter->preds = NULL;
}

--
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/


[85/94] 3c59x: fix freeing nonexistent resource on driver unload

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Sergei Shtylyov 

[ Upstream commit c81400be716aa4c76f6ebf339ba94358dbbf6da6 ]

When unloading the driver that drives an EISA board, a message similar to the
following one is displayed:

Trying to free nonexistent resource <00013000-0001301f>

Then an user is unable to reload the driver because the resource it requested in
the previous load hasn't been freed. This happens most probably due to a typo in
vortex_eisa_remove() which calls release_region() with 'dev->base_addr'  instead
of 'edev->base_addr'...

Reported-by: Matthew Whitehead 
Tested-by: Matthew Whitehead 
Signed-off-by: Sergei Shtylyov 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
---
 drivers/net/ethernet/3com/3c59x.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/3com/3c59x.c 
b/drivers/net/ethernet/3com/3c59x.c
index e0c5529..d1a6dbb 100644
--- a/drivers/net/ethernet/3com/3c59x.c
+++ b/drivers/net/ethernet/3com/3c59x.c
@@ -951,7 +951,7 @@ static int __devexit vortex_eisa_remove(struct device 
*device)
 
unregister_netdev(dev);
iowrite16(TotalReset|0x14, ioaddr + EL3_CMD);
-   release_region(dev->base_addr, VORTEX_TOTAL_SIZE);
+   release_region(edev->base_addr, VORTEX_TOTAL_SIZE);
 
free_netdev(dev);
return 0;

--
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/


[09/94] nfsd4: don't allow owner override on 4.1 CLAIM_FH opens

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: "J. Bruce Fields" 

commit 9f415eb25574db4b73a9a712a4438e41dc284922 upstream.

The Linux client is using CLAIM_FH to implement regular opens, not just
recovery cases, so it depends on the server to check permissions
correctly.

Therefore the owner override, which may make sense in the delegation
recovery case, isn't right in the CLAIM_FH case.

Symptoms: on a client with 49f9a0fafd844c32f2abada047c0b9a5ba0d6255
"NFSv4.1: Enable open-by-filehandle", Bryan noticed this:

touch test.txt
chmod 000 test.txt
echo test > test.txt

succeeding.

Reported-by: Bryan Schumaker 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Ben Hutchings 
---
 fs/nfsd/nfs4proc.c |   15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

--- a/fs/nfsd/nfs4proc.c
+++ b/fs/nfsd/nfs4proc.c
@@ -267,6 +267,7 @@ static __be32
 do_open_fhandle(struct svc_rqst *rqstp, struct svc_fh *current_fh, struct 
nfsd4_open *open)
 {
__be32 status;
+   int accmode = 0;
 
/* Only reclaims from previously confirmed clients are valid */
if ((status = nfs4_check_open_reclaim(>op_clientid)))
@@ -284,9 +285,19 @@ do_open_fhandle(struct svc_rqst *rqstp,
 
open->op_truncate = (open->op_iattr.ia_valid & ATTR_SIZE) &&
(open->op_iattr.ia_size == 0);
+   /*
+* In the delegation case, the client is telling us about an
+* open that it *already* performed locally, some time ago.  We
+* should let it succeed now if possible.
+*
+* In the case of a CLAIM_FH open, on the other hand, the client
+* may be counting on us to enforce permissions (the Linux 4.1
+* client uses this for normal opens, for example).
+*/
+   if (open->op_claim_type == NFS4_OPEN_CLAIM_DELEG_CUR_FH)
+   accmode = NFSD_MAY_OWNER_OVERRIDE;
 
-   status = do_open_permission(rqstp, current_fh, open,
-   NFSD_MAY_OWNER_OVERRIDE);
+   status = do_open_permission(rqstp, current_fh, open, accmode);
 
return status;
 }

--
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/


[78/94] x86,efi: Check max_size only if it is non-zero.

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Richard Weinberger 

commit 7791c8423f1f7f4dad94e753bae67461d5b80be8 upstream.

Some EFI implementations return always a MaximumVariableSize of 0,
check against max_size only if it is non-zero.
My Intel DQ67SW desktop board has such an implementation.

Signed-off-by: Richard Weinberger 
Signed-off-by: Matt Fleming 
Signed-off-by: Ben Hutchings 
---
 arch/x86/platform/efi/efi.c |7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -834,7 +834,12 @@ efi_status_t efi_query_variable_store(u3
if (status != EFI_SUCCESS)
return status;
 
-   if (!storage_size || size > remaining_size || size > max_size ||
+   if (!max_size && remaining_size > size)
+   printk_once(KERN_ERR FW_BUG "Broken EFI implementation"
+   " is returning MaxVariableSize=0\n");
+
+   if (!storage_size || size > remaining_size ||
+   (max_size && size > max_size) ||
(remaining_size - size) < (storage_size / 2))
return EFI_OUT_OF_RESOURCES;
 

--
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/


[20/94] mwifiex: fix setting of multicast filter

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Daniel Drake 

commit ccd384b10420ac81ba3fb9b0a7d18272c7173552 upstream.

A small bug in this code was causing the ALLMULTI filter to be set
when in fact we were just wanting to program a selective multicast list
to the hardware.

Fix that bug and remove a redundant if condition in the code that
follows.

This fixes wakeup behaviour when multicast WOL is enabled. Previously,
all multicast packets would wake up the system. Now, only those that the
host intended to receive trigger wakeups.

Signed-off-by: Daniel Drake 
Acked-by: Bing Zhao 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings 
---
 drivers/net/wireless/mwifiex/sta_ioctl.c |   21 ++---
 1 file changed, 6 insertions(+), 15 deletions(-)

--- a/drivers/net/wireless/mwifiex/sta_ioctl.c
+++ b/drivers/net/wireless/mwifiex/sta_ioctl.c
@@ -105,7 +105,7 @@ int mwifiex_request_set_multicast_list(s
} else {
/* Multicast */
priv->curr_pkt_filter &= ~HostCmd_ACT_MAC_PROMISCUOUS_ENABLE;
-   if (mcast_list->mode == MWIFIEX_MULTICAST_MODE) {
+   if (mcast_list->mode == MWIFIEX_ALL_MULTI_MODE) {
dev_dbg(priv->adapter->dev,
"info: Enabling All Multicast!\n");
priv->curr_pkt_filter |=
@@ -117,20 +117,11 @@ int mwifiex_request_set_multicast_list(s
dev_dbg(priv->adapter->dev,
"info: Set multicast list=%d\n",
   mcast_list->num_multicast_addr);
-   /* Set multicast addresses to firmware */
-   if (old_pkt_filter == priv->curr_pkt_filter) {
-   /* Send request to firmware */
-   ret = mwifiex_send_cmd_async(priv,
-   HostCmd_CMD_MAC_MULTICAST_ADR,
-   HostCmd_ACT_GEN_SET, 0,
-   mcast_list);
-   } else {
-   /* Send request to firmware */
-   ret = mwifiex_send_cmd_async(priv,
-   HostCmd_CMD_MAC_MULTICAST_ADR,
-   HostCmd_ACT_GEN_SET, 0,
-   mcast_list);
-   }
+   /* Send multicast addresses to firmware */
+   ret = mwifiex_send_cmd_async(priv,
+   HostCmd_CMD_MAC_MULTICAST_ADR,
+   HostCmd_ACT_GEN_SET, 0,
+   mcast_list);
}
}
}

--
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/


[03/94] mmc: core: Fix bit width test failing on old eMMC cards

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Philip Rakity 

commit 836dc2fe89c968c10cada87e0dfae6626f8f9da3 upstream.

PARTITION_SUPPORT needs to be set before doing the compare on version
number so the bit width test does not get invalid data.  Before this
patch, a Sandisk iNAND eMMC card would detect 1-bit width although
the hardware supports 4-bit.

Only affects old emmc devices - pre 4.4 devices.

Reported-by: Elad Yi 
Signed-off-by: Philip Rakity 
Signed-off-by: Chris Ball 
Signed-off-by: Ben Hutchings 
---
 drivers/mmc/core/mmc.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -363,13 +363,13 @@ static int mmc_read_ext_csd(struct mmc_c
ext_csd[EXT_CSD_SEC_FEATURE_SUPPORT];
card->ext_csd.raw_trim_mult =
ext_csd[EXT_CSD_TRIM_MULT];
+   card->ext_csd.raw_partition_support = 
ext_csd[EXT_CSD_PARTITION_SUPPORT];
if (card->ext_csd.rev >= 4) {
/*
 * Enhanced area feature support -- check whether the eMMC
 * card has the Enhanced area enabled.  If so, export enhanced
 * area offset and size to user by adding sysfs interface.
 */
-   card->ext_csd.raw_partition_support = 
ext_csd[EXT_CSD_PARTITION_SUPPORT];
if ((ext_csd[EXT_CSD_PARTITION_SUPPORT] & 0x2) &&
(ext_csd[EXT_CSD_PARTITION_ATTRIBUTE] & 0x1)) {
hc_erase_grp_sz =

--
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/


[06/94] x86: Eliminate irq_mis_count counted in arch_irq_stat

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Li Fei 

commit f7b0e1055574ce06ab53391263b4e205bf38daf3 upstream.

With the current implementation, kstat_cpu(cpu).irqs_sum is also
increased in case of irq_mis_count increment.

So there is no need to count irq_mis_count in arch_irq_stat,
otherwise irq_mis_count will be counted twice in the sum of
/proc/stat.

Reported-by: Liu Chuansheng 
Signed-off-by: Li Fei 
Acked-by: Liu Chuansheng 
Cc: tomoki.sekiyama...@hitachi.com
Cc: j...@perches.com
Link: 
http://lkml.kernel.org/r/1366980611.32469.7.camel@fli24-HP-Compaq-8100-Elite-CMT-PC
Signed-off-by: Ingo Molnar 
Signed-off-by: Ben Hutchings 
---
 arch/x86/kernel/irq.c |4 
 1 file changed, 4 deletions(-)

--- a/arch/x86/kernel/irq.c
+++ b/arch/x86/kernel/irq.c
@@ -160,10 +160,6 @@ u64 arch_irq_stat_cpu(unsigned int cpu)
 u64 arch_irq_stat(void)
 {
u64 sum = atomic_read(_err_count);
-
-#ifdef CONFIG_X86_IO_APIC
-   sum += atomic_read(_mis_count);
-#endif
return sum;
 }
 

--
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/


[83/94] bridge: fix race with topology change timer

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: stephen hemminger 

[ Upstream commit 83401eb4990ff6af55aeed8f49681558544192e6 ]

A bridge should only send topology change notice if it is not
the root bridge. It is possible for message age timer to elect itself
as a new root bridge, and still have a topology change timer running
but waiting for bridge lock on other CPU.

Solve the race by checking if we are root bridge before continuing.
This was the root cause of the cases where br_send_tcn_bpdu would OOPS.

Reported-by: JerryKang 
Signed-off-by: Stephen Hemminger 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
---
 net/bridge/br_stp_timer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/bridge/br_stp_timer.c b/net/bridge/br_stp_timer.c
index 58de2a0..c83ee79 100644
--- a/net/bridge/br_stp_timer.c
+++ b/net/bridge/br_stp_timer.c
@@ -107,7 +107,7 @@ static void br_tcn_timer_expired(unsigned long arg)
 
br_debug(br, "tcn timer expired\n");
spin_lock(>lock);
-   if (br->dev->flags & IFF_UP) {
+   if (!br_is_root_bridge(br) && (br->dev->flags & IFF_UP)) {
br_transmit_tcn(br);
 
mod_timer(>tcn_timer,jiffies + br->bridge_hello_time);

--
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/


[91/94] drivers/rtc/rtc-pcf2123.c: fix error return code in pcf2123_probe()

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Wei Yongjun 

commit 35623715818dfa720cccf99cd280dcbb4b78da23 upstream.

Fix to return -ENODEV in the chip not found error handling
case instead of 0, as done elsewhere in this function.

Signed-off-by: Wei Yongjun 
Cc: Jingoo Han 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings 
---
 drivers/rtc/rtc-pcf2123.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/rtc/rtc-pcf2123.c
+++ b/drivers/rtc/rtc-pcf2123.c
@@ -264,6 +264,7 @@ static int __devinit pcf2123_probe(struc
 
if (!(rxbuf[0] & 0x20)) {
dev_err(>dev, "chip not found\n");
+   ret = -ENODEV;
goto kfree_exit;
}
 

--
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/


[11/94] ext4: limit group search loop for non-extent files

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Lachlan McIlroy 

commit e6155736ad76b2070652745f9e54cdea3f0d8567 upstream.

In the case where we are allocating for a non-extent file,
we must limit the groups we allocate from to those below
2^32 blocks, and ext4_mb_regular_allocator() attempts to
do this initially by putting a cap on ngroups for the
subsequent search loop.

However, the initial target group comes in from the
allocation context (ac), and it may already be beyond
the artificially limited ngroups.  In this case,
the limit

if (group == ngroups)
group = 0;

at the top of the loop is never true, and the loop will
run away.

Catch this case inside the loop and reset the search to
start at group 0.

[sand...@redhat.com: add commit msg & comments]

Signed-off-by: Lachlan McIlroy 
Signed-off-by: Eric Sandeen 
Signed-off-by: "Theodore Ts'o" 
Signed-off-by: Ben Hutchings 
---
 fs/ext4/mballoc.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -2027,7 +2027,11 @@ repeat:
group = ac->ac_g_ex.fe_group;
 
for (i = 0; i < ngroups; group++, i++) {
-   if (group == ngroups)
+   /*
+* Artificially restricted ngroups for non-extent
+* files makes group > ngroups possible on first loop.
+*/
+   if (group >= ngroups)
group = 0;
 
/* This now checks without needing the buddy page */

--
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/


[68/94] ocfs2: goto out_unlock if ocfs2_get_clusters_nocache() failed in ocfs2_fiemap()

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Joseph Qi 

commit b4ca2b4b577c3530e34dcfaafccb2cc680ce95d1 upstream.

Last time we found there is lock/unlock bug in ocfs2_file_aio_write, and
then we did a thorough search for all lock resources in
ocfs2_inode_info, including rw, inode and open lockres and found this
bug.  My kernel version is 3.0.13, and it is also in the lastest version
3.9.  In ocfs2_fiemap, once ocfs2_get_clusters_nocache failed, it should
goto out_unlock instead of out, because we need release buffer head, up
read alloc sem and unlock inode.

Signed-off-by: Joseph Qi 
Reviewed-by: Jie Liu 
Cc: Mark Fasheh 
Cc: Joel Becker 
Acked-by: Sunil Mushran 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings 
---
 fs/ocfs2/extent_map.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/ocfs2/extent_map.c
+++ b/fs/ocfs2/extent_map.c
@@ -791,7 +791,7 @@ int ocfs2_fiemap(struct inode *inode, st
 _size, , _last);
if (ret) {
mlog_errno(ret);
-   goto out;
+   goto out_unlock;
}
 
if (rec.e_blkno == 0ULL) {

--
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/


[24/94] dm snapshot: fix error return code in snapshot_ctr

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Wei Yongjun 

commit 09e8b813897a0f85bb401435d009228644c81214 upstream.

Return -ENOMEM instead of success if unable to allocate pending
exception mempool in snapshot_ctr.

Signed-off-by: Wei Yongjun 
Signed-off-by: Alasdair G Kergon 
Signed-off-by: Ben Hutchings 
---
 drivers/md/dm-snap.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/md/dm-snap.c
+++ b/drivers/md/dm-snap.c
@@ -1117,6 +1117,7 @@ static int snapshot_ctr(struct dm_target
s->pending_pool = mempool_create_slab_pool(MIN_IOS, pending_cache);
if (!s->pending_pool) {
ti->error = "Could not allocate mempool for pending exceptions";
+   r = -ENOMEM;
goto bad_pending_pool;
}
 

--
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/


[13/94] autofs - remove autofs dentry mount check

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: David Jeffery 

commit ce8a5dbdf9e709bdaf4618d7ef8cceb91e8adc69 upstream.

When checking if an autofs mount point is busy it isn't sufficient to
only check if it's a mount point.

For example, if the mount of an offset mountpoint in a tree is denied
for this host by its export and the dentry becomes a process working
directory the check incorrectly returns the mount as not in use at
expire.

This can happen since the default when mounting within a tree is
nostrict, which means ingnore mount fails on mounts within the tree and
continue.  The nostrict option is meant to allow mounting in this case.

Signed-off-by: David Jeffery 
Signed-off-by: Ian Kent 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings 
---
 fs/autofs4/expire.c |9 -
 1 file changed, 9 deletions(-)

--- a/fs/autofs4/expire.c
+++ b/fs/autofs4/expire.c
@@ -61,15 +61,6 @@ static int autofs4_mount_busy(struct vfs
/* This is an autofs submount, we can't expire it */
if (autofs_type_indirect(sbi->type))
goto done;
-
-   /*
-* Otherwise it's an offset mount and we need to check
-* if we can umount its mount, if there is one.
-*/
-   if (!d_mountpoint(path.dentry)) {
-   status = 0;
-   goto done;
-   }
}
 
/* Update the expiry counter if fs is busy */

--
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/


[67/94] random: fix accounting race condition with lockless irq entropy_count update

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Jiri Kosina 

commit 10b3a32d292c21ea5b3ad5ca5975e88bb20b8d68 upstream.

Commit 902c098a3663 ("random: use lockless techniques in the interrupt
path") turned IRQ path from being spinlock protected into lockless
cmpxchg-retry update.

That commit removed r->lock serialization between crediting entropy bits
from IRQ context and accounting when extracting entropy on userspace
read path, but didn't turn the r->entropy_count reads/updates in
account() to use cmpxchg as well.

It has been observed, that under certain circumstances this leads to
read() on /dev/urandom to return 0 (EOF), as r->entropy_count gets
corrupted and becomes negative, which in turn results in propagating 0
all the way from account() to the actual read() call.

Convert the accounting code to be the proper lockless counterpart of
what has been partially done by 902c098a3663.

Signed-off-by: Jiri Kosina 
Cc: Theodore Ts'o 
Cc: Greg KH 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings 
---
 drivers/char/random.c |   24 
 1 file changed, 16 insertions(+), 8 deletions(-)

--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -889,16 +889,24 @@ static size_t account(struct entropy_sto
if (r->entropy_count / 8 < min + reserved) {
nbytes = 0;
} else {
+   int entropy_count, orig;
+retry:
+   entropy_count = orig = ACCESS_ONCE(r->entropy_count);
/* If limited, never pull more than available */
-   if (r->limit && nbytes + reserved >= r->entropy_count / 8)
-   nbytes = r->entropy_count/8 - reserved;
+   if (r->limit && nbytes + reserved >= entropy_count / 8)
+   nbytes = entropy_count/8 - reserved;
 
-   if (r->entropy_count / 8 >= nbytes + reserved)
-   r->entropy_count -= nbytes*8;
-   else
-   r->entropy_count = reserved;
+   if (entropy_count / 8 >= nbytes + reserved) {
+   entropy_count -= nbytes*8;
+   if (cmpxchg(>entropy_count, orig, entropy_count) != 
orig)
+   goto retry;
+   } else {
+   entropy_count = reserved;
+   if (cmpxchg(>entropy_count, orig, entropy_count) != 
orig)
+   goto retry;
+   }
 
-   if (r->entropy_count < random_write_wakeup_thresh) {
+   if (entropy_count < random_write_wakeup_thresh) {
wake_up_interruptible(_write_wait);
kill_fasync(, SIGIO, POLL_OUT);
}

--
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/


[62/94] rapidio/tsi721: fix bug in MSI interrupt handling

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Alexandre Bounine 

commit 1ccc819da6fda9bee10ab8b72e9adbb5ad3e4959 upstream.

Fix bug in MSI interrupt handling which causes loss of event
notifications.

Typical indication of lost MSI interrupts are stalled message and
doorbell transfers between RapidIO endpoints.  To avoid loss of MSI
interrupts all interrupts from the device must be disabled on entering
the interrupt handler routine and re-enabled when exiting it.
Re-enabling device interrupts will trigger new MSI message(s) if Tsi721
registered new events since entering interrupt handler routine.

This patch is applicable to kernel versions starting from v3.2.

Signed-off-by: Alexandre Bounine 
Cc: Matt Porter 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings 
---
--- a/drivers/rapidio/devices/tsi721.c
+++ b/drivers/rapidio/devices/tsi721.c
@@ -475,6 +475,10 @@ static irqreturn_t tsi721_irqhandler(int
u32 intval;
u32 ch_inte;
 
+   /* For MSI mode disable all device-level interrupts */
+   if (priv->flags & TSI721_USING_MSI)
+   iowrite32(0, priv->regs + TSI721_DEV_INTE);
+
dev_int = ioread32(priv->regs + TSI721_DEV_INT);
if (!dev_int)
return IRQ_NONE;
@@ -548,6 +552,13 @@ static irqreturn_t tsi721_irqhandler(int
tsi721_pw_handler(mport);
}
 
+   /* For MSI mode re-enable device-level interrupts */
+   if (priv->flags & TSI721_USING_MSI) {
+   dev_int = TSI721_DEV_INT_SR2PC_CH | TSI721_DEV_INT_SRIO |
+   TSI721_DEV_INT_SMSG_CH | TSI721_DEV_INT_BDMA_CH;
+   iowrite32(dev_int, priv->regs + TSI721_DEV_INTE);
+   }
+
return IRQ_HANDLED;
 }
 

--
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/


[86/94] 3c59x: fix PCI resource management

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Sergei Shtylyov 

[ Upstream commit 4b264a1676e70dc656ba53a8cac690f2d4b65f4e ]

The driver wrongly claimed I/O ports at an address returned by pci_iomap() --
even if it was passed an MMIO address.  Fix this by claiming/releasing all PCI
resources in the PCI driver's probe()/remove() methods instead and get rid of
'must_free_region' flag weirdness (why would Cardbus claim anything for us?).

Signed-off-by: Sergei Shtylyov 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
---
 drivers/net/ethernet/3com/3c59x.c | 25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/3com/3c59x.c 
b/drivers/net/ethernet/3com/3c59x.c
index d1a6dbb..efc9dee 100644
--- a/drivers/net/ethernet/3com/3c59x.c
+++ b/drivers/net/ethernet/3com/3c59x.c
@@ -632,7 +632,6 @@ struct vortex_private {
pm_state_valid:1,   /* 
pci_dev->saved_config_space has sane contents */
open:1,
medialock:1,
-   must_free_region:1, /* Flag: if 
zero, Cardbus owns the I/O region */
large_frames:1, /* accept large frames */
handling_irq:1; /* private in_irq indicator */
/* {get|set}_wol operations are already serialized by rtnl.
@@ -1012,6 +1011,12 @@ static int __devinit vortex_init_one(struct pci_dev 
*pdev,
if (rc < 0)
goto out;
 
+   rc = pci_request_regions(pdev, DRV_NAME);
+   if (rc < 0) {
+   pci_disable_device(pdev);
+   goto out;
+   }
+
unit = vortex_cards_found;
 
if (global_use_mmio < 0 && (unit >= MAX_UNITS || use_mmio[unit] < 0)) {
@@ -1027,6 +1032,7 @@ static int __devinit vortex_init_one(struct pci_dev *pdev,
if (!ioaddr) /* If mapping fails, fall-back to BAR 0... */
ioaddr = pci_iomap(pdev, 0, 0);
if (!ioaddr) {
+   pci_release_regions(pdev);
pci_disable_device(pdev);
rc = -ENOMEM;
goto out;
@@ -1036,6 +1042,7 @@ static int __devinit vortex_init_one(struct pci_dev *pdev,
   ent->driver_data, unit);
if (rc < 0) {
pci_iounmap(pdev, ioaddr);
+   pci_release_regions(pdev);
pci_disable_device(pdev);
goto out;
}
@@ -1180,11 +1187,6 @@ static int __devinit vortex_probe1(struct device *gendev,
 
/* PCI-only startup logic */
if (pdev) {
-   /* EISA resources already marked, so only PCI needs to do this 
here */
-   /* Ignore return value, because Cardbus drivers already 
allocate for us */
-   if (request_region(dev->base_addr, vci->io_size, print_name) != 
NULL)
-   vp->must_free_region = 1;
-
/* enable bus-mastering if necessary */
if (vci->flags & PCI_USES_MASTER)
pci_set_master(pdev);
@@ -1222,7 +1224,7 @@ static int __devinit vortex_probe1(struct device *gendev,
   >rx_ring_dma);
retval = -ENOMEM;
if (!vp->rx_ring)
-   goto free_region;
+   goto free_device;
 
vp->tx_ring = (struct boom_tx_desc *)(vp->rx_ring + RX_RING_SIZE);
vp->tx_ring_dma = vp->rx_ring_dma + sizeof(struct boom_rx_desc) * 
RX_RING_SIZE;
@@ -1487,9 +1489,7 @@ free_ring:
+ sizeof(struct 
boom_tx_desc) * TX_RING_SIZE,
vp->rx_ring,
vp->rx_ring_dma);
-free_region:
-   if (vp->must_free_region)
-   release_region(dev->base_addr, vci->io_size);
+free_device:
free_netdev(dev);
pr_err(PFX "vortex_probe1 fails.  Returns %d\n", retval);
 out:
@@ -3254,8 +3254,9 @@ static void __devexit vortex_remove_one(struct pci_dev 
*pdev)
+ sizeof(struct 
boom_tx_desc) * TX_RING_SIZE,
vp->rx_ring,
vp->rx_ring_dma);
-   if (vp->must_free_region)
-   release_region(dev->base_addr, vp->io_size);
+
+   pci_release_regions(pdev);
+
free_netdev(dev);
 }
 

--
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/


[93/94] staging: comedi: prevent auto-unconfig of manually configured devices

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Ian Abbott 

commit 7d3135af399e92cf4c9bbc5f86b6c140aab3b88c upstream.

When a low-level comedi driver auto-configures a device, a `struct
comedi_dev_file_info` is allocated (as well as a `struct
comedi_device`) by `comedi_alloc_board_minor()`.  A pointer to the
hardware `struct device` is stored as a cookie in the `struct
comedi_dev_file_info`.  When the low-level comedi driver
auto-unconfigures the device, `comedi_auto_unconfig()` uses the cookie
to find the `struct comedi_dev_file_info` so it can detach the comedi
device from the driver, clean it up and free it.

A problem arises if the user manually unconfigures and reconfigures the
comedi device using the `COMEDI_DEVCONFIG` ioctl so that is no longer
associated with the original hardware device.  The problem is that the
cookie is not cleared, so that a call to `comedi_auto_unconfig()` from
the low-level driver will still find it, detach it, clean it up and free
it.

Stop this problem occurring by always clearing the `hardware_device`
cookie in the `struct comedi_dev_file_info` whenever the
`COMEDI_DEVCONFIG` ioctl call is successful.

Signed-off-by: Ian Abbott 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
---
 drivers/staging/comedi/comedi_fops.c |3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/staging/comedi/comedi_fops.c
+++ b/drivers/staging/comedi/comedi_fops.c
@@ -143,6 +143,9 @@ static long comedi_unlocked_ioctl(struct
}
rc = do_devconfig_ioctl(dev,
(struct comedi_devconfig __user *)arg);
+   if (rc == 0)
+   /* Evade comedi_auto_unconfig(). */
+   dev_file_info->hardware_device = NULL;
goto done;
}
 

--
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/


[89/94] ipv6: do not clear pinet6 field

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Eric Dumazet 

[ Upstream commit f77d602124d865c38705df7fa25c03de9c284ad2 ]

We have seen multiple NULL dereferences in __inet6_lookup_established()

After analysis, I found that inet6_sk() could be NULL while the
check for sk_family == AF_INET6 was true.

Bug was added in linux-2.6.29 when RCU lookups were introduced in UDP
and TCP stacks.

Once an IPv6 socket, using SLAB_DESTROY_BY_RCU is inserted in a hash
table, we no longer can clear pinet6 field.

This patch extends logic used in commit fcbdf09d9652c891
("net: fix nulls list corruptions in sk_prot_alloc")

TCP/UDP/UDPLite IPv6 protocols provide their own .clear_sk() method
to make sure we do not clear pinet6 field.

At socket clone phase, we do not really care, as cloning the parent (non
NULL) pinet6 is not adding a fatal race.

Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
---
 include/net/sock.h  | 12 
 net/core/sock.c | 12 
 net/ipv6/tcp_ipv6.c | 12 
 net/ipv6/udp.c  | 13 -
 net/ipv6/udp_impl.h |  2 ++
 net/ipv6/udplite.c  |  2 +-
 6 files changed, 39 insertions(+), 14 deletions(-)

diff --git a/include/net/sock.h b/include/net/sock.h
index ddf523c..e6454b6 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -734,6 +734,18 @@ struct inet_hashinfo;
 struct raw_hashinfo;
 struct module;
 
+/*
+ * caches using SLAB_DESTROY_BY_RCU should let .next pointer from nulls nodes
+ * un-modified. Special care is taken when initializing object to zero.
+ */
+static inline void sk_prot_clear_nulls(struct sock *sk, int size)
+{
+   if (offsetof(struct sock, sk_node.next) != 0)
+   memset(sk, 0, offsetof(struct sock, sk_node.next));
+   memset(>sk_node.pprev, 0,
+  size - offsetof(struct sock, sk_node.pprev));
+}
+
 /* Networking protocol blocks we attach to sockets.
  * socket layer -> transport layer interface
  * transport -> network interface is defined by struct inet_proto
diff --git a/net/core/sock.c b/net/core/sock.c
index 2c73adf..8a2c2dd 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1021,18 +1021,6 @@ static void sock_copy(struct sock *nsk, const struct 
sock *osk)
 #endif
 }
 
-/*
- * caches using SLAB_DESTROY_BY_RCU should let .next pointer from nulls nodes
- * un-modified. Special care is taken when initializing object to zero.
- */
-static inline void sk_prot_clear_nulls(struct sock *sk, int size)
-{
-   if (offsetof(struct sock, sk_node.next) != 0)
-   memset(sk, 0, offsetof(struct sock, sk_node.next));
-   memset(>sk_node.pprev, 0,
-  size - offsetof(struct sock, sk_node.pprev));
-}
-
 void sk_prot_clear_portaddr_nulls(struct sock *sk, int size)
 {
unsigned long nulls1, nulls2;
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index db10805..c69358c 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -2196,6 +2196,17 @@ void tcp6_proc_exit(struct net *net)
 }
 #endif
 
+static void tcp_v6_clear_sk(struct sock *sk, int size)
+{
+   struct inet_sock *inet = inet_sk(sk);
+
+   /* we do not want to clear pinet6 field, because of RCU lookups */
+   sk_prot_clear_nulls(sk, offsetof(struct inet_sock, pinet6));
+
+   size -= offsetof(struct inet_sock, pinet6) + sizeof(inet->pinet6);
+   memset(>pinet6 + 1, 0, size);
+}
+
 struct proto tcpv6_prot = {
.name   = "TCPv6",
.owner  = THIS_MODULE,
@@ -2235,6 +2246,7 @@ struct proto tcpv6_prot = {
.compat_setsockopt  = compat_tcp_setsockopt,
.compat_getsockopt  = compat_tcp_getsockopt,
 #endif
+   .clear_sk   = tcp_v6_clear_sk,
 };
 
 static const struct inet6_protocol tcpv6_protocol = {
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 8c25419..20f0812 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -1453,6 +1453,17 @@ void udp6_proc_exit(struct net *net) {
 }
 #endif /* CONFIG_PROC_FS */
 
+void udp_v6_clear_sk(struct sock *sk, int size)
+{
+   struct inet_sock *inet = inet_sk(sk);
+
+   /* we do not want to clear pinet6 field, because of RCU lookups */
+   sk_prot_clear_portaddr_nulls(sk, offsetof(struct inet_sock, pinet6));
+
+   size -= offsetof(struct inet_sock, pinet6) + sizeof(inet->pinet6);
+   memset(>pinet6 + 1, 0, size);
+}
+
 /*  */
 
 struct proto udpv6_prot = {
@@ -1483,7 +1494,7 @@ struct proto udpv6_prot = {
.compat_setsockopt = compat_udpv6_setsockopt,
.compat_getsockopt = compat_udpv6_getsockopt,
 #endif
-   .clear_sk  = sk_prot_clear_portaddr_nulls,
+   .clear_sk  = udp_v6_clear_sk,
 };
 
 static struct inet_protosw udpv6_protosw = {
diff --git a/net/ipv6/udp_impl.h b/net/ipv6/udp_impl.h
index d757104..4691ed5 100644
--- a/net/ipv6/udp_impl.h
+++ 

[80/94] tcp: force a dst refcount when prequeue packet

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Eric Dumazet 

[ Upstream commit 093162553c33e9479283e107b4431378271c735d ]

Before escaping RCU protected section and adding packet into
prequeue, make sure the dst is refcounted.

Reported-by: Mike Galbraith 
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
---
 include/net/tcp.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/net/tcp.h b/include/net/tcp.h
index 0768715..fe46019 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -931,6 +931,7 @@ static inline int tcp_prequeue(struct sock *sk, struct 
sk_buff *skb)
if (sysctl_tcp_low_latency || !tp->ucopy.task)
return 0;
 
+   skb_dst_force(skb);
__skb_queue_tail(>ucopy.prequeue, skb);
tp->ucopy.memory += skb->truesize;
if (tp->ucopy.memory > sk->sk_rcvbuf) {

--
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/


[82/94] net_sched: act_ipt forward compat with xtables

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Jamal Hadi Salim 

[ Upstream commit 0dcffd09641f3abb21ac5cabc61542ab289d1a3c ]

Deal with changes in newer xtables while maintaining backward
compatibility. Thanks to Jan Engelhardt for suggestions.

Signed-off-by: Jamal Hadi Salim 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
---
 net/sched/act_ipt.c | 33 ++---
 1 file changed, 30 insertions(+), 3 deletions(-)

diff --git a/net/sched/act_ipt.c b/net/sched/act_ipt.c
index 60f8f61..57827bf 100644
--- a/net/sched/act_ipt.c
+++ b/net/sched/act_ipt.c
@@ -8,7 +8,7 @@
  * as published by the Free Software Foundation; either version
  * 2 of the License, or (at your option) any later version.
  *
- * Copyright:  Jamal Hadi Salim (2002-4)
+ * Copyright:  Jamal Hadi Salim (2002-13)
  */
 
 #include 
@@ -299,17 +299,44 @@ static struct tc_action_ops act_ipt_ops = {
.walk   =   tcf_generic_walker
 };
 
-MODULE_AUTHOR("Jamal Hadi Salim(2002-4)");
+static struct tc_action_ops act_xt_ops = {
+   .kind   =   "xt",
+   .hinfo  =   _hash_info,
+   .type   =   TCA_ACT_IPT,
+   .capab  =   TCA_CAP_NONE,
+   .owner  =   THIS_MODULE,
+   .act=   tcf_ipt,
+   .dump   =   tcf_ipt_dump,
+   .cleanup=   tcf_ipt_cleanup,
+   .lookup =   tcf_hash_search,
+   .init   =   tcf_ipt_init,
+   .walk   =   tcf_generic_walker
+};
+
+MODULE_AUTHOR("Jamal Hadi Salim(2002-13)");
 MODULE_DESCRIPTION("Iptables target actions");
 MODULE_LICENSE("GPL");
+MODULE_ALIAS("act_xt");
 
 static int __init ipt_init_module(void)
 {
-   return tcf_register_action(_ipt_ops);
+   int ret1, ret2;
+   ret1 = tcf_register_action(_xt_ops);
+   if (ret1 < 0)
+   printk("Failed to load xt action\n");
+   ret2 = tcf_register_action(_ipt_ops);
+   if (ret2 < 0)
+   printk("Failed to load ipt action\n");
+
+   if (ret1 < 0 && ret2 < 0)
+   return ret1;
+   else
+   return 0;
 }
 
 static void __exit ipt_cleanup_module(void)
 {
+   tcf_unregister_action(_xt_ops);
tcf_unregister_action(_ipt_ops);
 }
 

--
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/


[37/94] USB: xHCI: override bogus bulk wMaxPacketSize values

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Alan Stern 

commit e4f47e3675e6f1f40906b785b934ce963e9f2eb3 upstream.

This patch shortens the logic in xhci_endpoint_init() by moving common
calculations involving max_packet and max_burst outside the switch
statement, rather than repeating the same code in multiple
case-specific statements.  It also replaces two usages of max_packet
which were clearly intended to be max_burst all along.

More importantly, it compensates for a common bug in high-speed bulk
endpoint descriptors.  In many devices there is a bulk endpoint having
a wMaxPacketSize value smaller than 512, which is forbidden by the USB
spec.  Some xHCI controllers can't handle this and refuse to accept
the endpoint.  This patch changes the max_packet value to 512, which
allows the controller to use the endpoint properly.

In practice the bogus maxpacket size doesn't matter, because none of
the transfers sent via these endpoints are longer than the maxpacket
value anyway.

Signed-off-by: Alan Stern 
Reported-and-tested-by: "Aurélien Leblond" 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
---
 drivers/usb/host/xhci-mem.c |   17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1353,15 +1353,17 @@ int xhci_endpoint_init(struct xhci_hcd *
ep_ctx->ep_info2 |= cpu_to_le32(xhci_get_endpoint_type(udev, ep));
 
/* Set the max packet size and max burst */
+   max_packet = GET_MAX_PACKET(usb_endpoint_maxp(>desc));
+   max_burst = 0;
switch (udev->speed) {
case USB_SPEED_SUPER:
-   max_packet = usb_endpoint_maxp(>desc);
-   ep_ctx->ep_info2 |= cpu_to_le32(MAX_PACKET(max_packet));
/* dig out max burst from ep companion desc */
-   max_packet = ep->ss_ep_comp.bMaxBurst;
-   ep_ctx->ep_info2 |= cpu_to_le32(MAX_BURST(max_packet));
+   max_burst = ep->ss_ep_comp.bMaxBurst;
break;
case USB_SPEED_HIGH:
+   /* Some devices get this wrong */
+   if (usb_endpoint_xfer_bulk(>desc))
+   max_packet = 512;
/* bits 11:12 specify the number of additional transaction
 * opportunities per microframe (USB 2.0, section 9.6.6)
 */
@@ -1369,17 +1371,16 @@ int xhci_endpoint_init(struct xhci_hcd *
usb_endpoint_xfer_int(>desc)) {
max_burst = (usb_endpoint_maxp(>desc)
 & 0x1800) >> 11;
-   ep_ctx->ep_info2 |= cpu_to_le32(MAX_BURST(max_burst));
}
-   /* Fall through */
+   break;
case USB_SPEED_FULL:
case USB_SPEED_LOW:
-   max_packet = GET_MAX_PACKET(usb_endpoint_maxp(>desc));
-   ep_ctx->ep_info2 |= cpu_to_le32(MAX_PACKET(max_packet));
break;
default:
BUG();
}
+   ep_ctx->ep_info2 |= cpu_to_le32(MAX_PACKET(max_packet) |
+   MAX_BURST(max_burst));
max_esit_payload = xhci_get_max_esit_payload(xhci, udev, ep);
ep_ctx->tx_info = 
cpu_to_le32(MAX_ESIT_PAYLOAD_FOR_EP(max_esit_payload));
 

--
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/


[63/94] mm compaction: fix of improper cache flush in migration code

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Leonid Yegoshin 

commit c2cc499c5bcf9040a738f49e8051b42078205748 upstream.

Page 'new' during MIGRATION can't be flushed with flush_cache_page().
Using flush_cache_page(vma, addr, pfn) is justified only if the page is
already placed in process page table, and that is done right after
flush_cache_page().  But without it the arch function has no knowledge
of process PTE and does nothing.

Besides that, flush_cache_page() flushes an application cache page, but
the kernel has a different page virtual address and dirtied it.

Replace it with flush_dcache_page(new) which is the proper usage.

The old page is flushed in try_to_unmap_one() before migration.

This bug takes place in Sead3 board with M14Kc MIPS CPU without cache
aliasing (but Harvard arch - separate I and D cache) in tight memory
environment (128MB) each 1-3days on SOAK test.  It fails in cc1 during
kernel build (SIGILL, SIGBUS, SIGSEG) if CONFIG_COMPACTION is switched
ON.

Signed-off-by: Leonid Yegoshin 
Cc: Leonid Yegoshin 
Acked-by: Rik van Riel 
Cc: Michal Hocko 
Acked-by: Mel Gorman 
Cc: Ralf Baechle 
Cc: Russell King 
Cc: David Miller 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings 
---
 mm/migrate.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -147,7 +147,7 @@ static int remove_migration_pte(struct p
if (PageHuge(new))
pte = pte_mkhuge(pte);
 #endif
-   flush_cache_page(vma, addr, pte_pfn(pte));
+   flush_dcache_page(new);
set_pte_at(mm, addr, ptep, pte);
 
if (PageHuge(new)) {

--
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/


[84/94] packet: tpacket_v3: do not trigger bug() on wrong header status

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Daniel Borkmann 

[ Upstream commit 8da3056c04bfc5f69f840ab038a38389e2de8189 ]

Jakub reported that it is fairly easy to trigger the BUG() macro
from user space with TPACKET_V3's RX_RING by just giving a wrong
header status flag. We already had a similar situation in commit
7f5c3e3a80e6654 (``af_packet: remove BUG statement in
tpacket_destruct_skb'') where this was the case in the TX_RING
side that could be triggered from user space. So really, don't use
BUG() or BUG_ON() unless there's really no way out, and i.e.
don't use it for consistency checking when there's user space
involved, no excuses, especially not if you're slapping the user
with WARN + dump_stack + BUG all at once. The two functions are
of concern:

  prb_retire_current_block() [when block status != TP_STATUS_KERNEL]
  prb_open_block() [when block_status != TP_STATUS_KERNEL]

Calls to prb_open_block() are guarded by ealier checks if block_status
is really TP_STATUS_KERNEL (racy!), but the first one BUG() is easily
triggable from user space. System behaves still stable after they are
removed. Also remove that yoda condition entirely, since it's already
guarded.

Reported-by: Jakub Zawadzki 
Signed-off-by: Daniel Borkmann 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
---
 net/packet/af_packet.c | 54 +++---
 1 file changed, 20 insertions(+), 34 deletions(-)

diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 835fcea..5a70215 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -813,37 +813,27 @@ static void prb_open_block(struct tpacket_kbdq_core *pkc1,
 
smp_rmb();
 
-   if (likely(TP_STATUS_KERNEL == BLOCK_STATUS(pbd1))) {
-
-   /* We could have just memset this but we will lose the
-* flexibility of making the priv area sticky
-*/
-   BLOCK_SNUM(pbd1) = pkc1->knxt_seq_num++;
-   BLOCK_NUM_PKTS(pbd1) = 0;
-   BLOCK_LEN(pbd1) = BLK_PLUS_PRIV(pkc1->blk_sizeof_priv);
-   getnstimeofday();
-   h1->ts_first_pkt.ts_sec = ts.tv_sec;
-   h1->ts_first_pkt.ts_nsec = ts.tv_nsec;
-   pkc1->pkblk_start = (char *)pbd1;
-   pkc1->nxt_offset = (char *)(pkc1->pkblk_start +
-   BLK_PLUS_PRIV(pkc1->blk_sizeof_priv));
-   BLOCK_O2FP(pbd1) = (__u32)BLK_PLUS_PRIV(pkc1->blk_sizeof_priv);
-   BLOCK_O2PRIV(pbd1) = BLK_HDR_LEN;
-   pbd1->version = pkc1->version;
-   pkc1->prev = pkc1->nxt_offset;
-   pkc1->pkblk_end = pkc1->pkblk_start + pkc1->kblk_size;
-   prb_thaw_queue(pkc1);
-   _prb_refresh_rx_retire_blk_timer(pkc1);
-
-   smp_wmb();
-
-   return;
-   }
+   /* We could have just memset this but we will lose the
+* flexibility of making the priv area sticky
+*/
+   BLOCK_SNUM(pbd1) = pkc1->knxt_seq_num++;
+   BLOCK_NUM_PKTS(pbd1) = 0;
+   BLOCK_LEN(pbd1) = BLK_PLUS_PRIV(pkc1->blk_sizeof_priv);
+   getnstimeofday();
+   h1->ts_first_pkt.ts_sec = ts.tv_sec;
+   h1->ts_first_pkt.ts_nsec = ts.tv_nsec;
+   pkc1->pkblk_start = (char *)pbd1;
+   pkc1->nxt_offset = (char *)(pkc1->pkblk_start +
+   BLK_PLUS_PRIV(pkc1->blk_sizeof_priv));
+   BLOCK_O2FP(pbd1) = (__u32)BLK_PLUS_PRIV(pkc1->blk_sizeof_priv);
+   BLOCK_O2PRIV(pbd1) = BLK_HDR_LEN;
+   pbd1->version = pkc1->version;
+   pkc1->prev = pkc1->nxt_offset;
+   pkc1->pkblk_end = pkc1->pkblk_start + pkc1->kblk_size;
+   prb_thaw_queue(pkc1);
+   _prb_refresh_rx_retire_blk_timer(pkc1);
 
-   WARN(1, "ERROR block:%p is NOT FREE status:%d kactive_blk_num:%d\n",
-   pbd1, BLOCK_STATUS(pbd1), pkc1->kactive_blk_num);
-   dump_stack();
-   BUG();
+   smp_wmb();
 }
 
 /*
@@ -934,10 +924,6 @@ static void prb_retire_current_block(struct 
tpacket_kbdq_core *pkc,
prb_close_block(pkc, pbd, po, status);
return;
}
-
-   WARN(1, "ERROR-pbd[%d]:%p\n", pkc->kactive_blk_num, pbd);
-   dump_stack();
-   BUG();
 }
 
 static int prb_curr_blk_in_use(struct tpacket_kbdq_core *pkc,

--
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/


[10/94] net/eth/ibmveth: Fixup retrieval of MAC address

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Benjamin Herrenschmidt 

commit 13f85203e1060da83d9ec1c1c5a63343eaab8de4 upstream.

Some ancient pHyp versions used to create a 8 bytes local-mac-address
property in the device-tree instead of a 6 bytes one for veth.

The Linux driver code to deal with that is an insane hack which also
happens to break with some choices of MAC addresses in qemu by testing
for a bit in the address rather than just looking at the size of the
property.

Sanitize this by doing the latter instead.

Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
---
 drivers/net/ethernet/ibm/ibmveth.c |   23 ++-
 1 file changed, 10 insertions(+), 13 deletions(-)

--- a/drivers/net/ethernet/ibm/ibmveth.c
+++ b/drivers/net/ethernet/ibm/ibmveth.c
@@ -1325,7 +1325,7 @@ static const struct net_device_ops ibmve
 static int __devinit ibmveth_probe(struct vio_dev *dev,
   const struct vio_device_id *id)
 {
-   int rc, i;
+   int rc, i, mac_len;
struct net_device *netdev;
struct ibmveth_adapter *adapter;
unsigned char *mac_addr_p;
@@ -1335,11 +1335,19 @@ static int __devinit ibmveth_probe(struc
dev->unit_address);
 
mac_addr_p = (unsigned char *)vio_get_attribute(dev, VETH_MAC_ADDR,
-   NULL);
+   _len);
if (!mac_addr_p) {
dev_err(>dev, "Can't find VETH_MAC_ADDR attribute\n");
return -EINVAL;
}
+   /* Workaround for old/broken pHyp */
+   if (mac_len == 8)
+   mac_addr_p += 2;
+   else if (mac_len != 6) {
+   dev_err(>dev, "VETH_MAC_ADDR attribute wrong len %d\n",
+   mac_len);
+   return -EINVAL;
+   }
 
mcastFilterSize_p = (unsigned int *)vio_get_attribute(dev,
VETH_MCAST_FILTER_SIZE, NULL);
@@ -1364,17 +1372,6 @@ static int __devinit ibmveth_probe(struc
 
netif_napi_add(netdev, >napi, ibmveth_poll, 16);
 
-   /*
-* Some older boxes running PHYP non-natively have an OF that returns
-* a 8-byte local-mac-address field (and the first 2 bytes have to be
-* ignored) while newer boxes' OF return a 6-byte field. Note that
-* IEEE 1275 specifies that local-mac-address must be a 6-byte field.
-* The RPA doc specifies that the first byte must be 10b, so we'll
-* just look for it to solve this 8 vs. 6 byte field issue
-*/
-   if ((*mac_addr_p & 0x3) != 0x02)
-   mac_addr_p += 2;
-
adapter->mac_addr = 0;
memcpy(>mac_addr, mac_addr_p, 6);
 

--
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/


[73/94] ipvs: ip_vs_sip_fill_param() BUG: bad check of return value

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Hans Schillstrom 

commit f7a1dd6e3ad59f0cfd51da29dfdbfd54122c5916 upstream.

The reason for this patch is crash in kmemdup
caused by returning from get_callid with uniialized
matchoff and matchlen.

Removing Zero check of matchlen since it's done by ct_sip_get_header()

BUG: unable to handle kernel paging request at 880457b5763f
IP: [] kmemdup+0x2e/0x35
PGD 27f6067 PUD 0
Oops:  [#1] PREEMPT SMP
Modules linked in: xt_state xt_helper nf_conntrack_ipv6 nf_defrag_ipv6 
ip6table_mangle xt_connmark xt_conntrack ip6_tables nf_conntrack_ftp ip_vs_ftp 
nf_nat xt_tcpudp iptable_mangle xt_mark ip_tables x_tables ip_vs_rr ip_vs_lblcr 
ip_vs_pe_sip ip_vs nf_conntrack_sip nf_conntrack bonding igb i2c_algo_bit 
i2c_core
CPU 5
Pid: 0, comm: swapper/5 Not tainted 3.9.0-rc5+ #5  /S1200KP
RIP: 0010:[]  [] kmemdup+0x2e/0x35
RSP: 0018:8803fea03648  EFLAGS: 00010282
RAX: 8803d61063e0 RBX: 0003 RCX: 0003
RDX: 0003 RSI: 880457b5763f RDI: 8803d61063e0
RBP: 8803fea03658 R08: 0008 R09: 0011
R10: 0011 R11: 0081a8a3 R12: 880457b5763f
R13: 8803d67f786a R14: 8803fea03730 R15: a0098e90
FS:  () GS:8803fea0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 880457b5763f CR3: 01a0c000 CR4: 001407e0
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0400
Process swapper/5 (pid: 0, threadinfo 8803ee18c000, task 8803ee18a480)
Stack:
 8803d822a080 001c 8803fea036c8 a000937a
 81f0d8a0 00038135fdd5 88030014 88030011
 150118ac 8803d7e8a000 88031e0118ac 
Call Trace:
 

 [] ip_vs_sip_fill_param+0x13a/0x187 [ip_vs_pe_sip]
 [] ip_vs_sched_persist+0x2c6/0x9c3 [ip_vs]
 [] ? __lock_acquire+0x677/0x1697
 [] ? native_sched_clock+0x3c/0x7d
 [] ? native_sched_clock+0x3c/0x7d
 [] ? sched_clock_cpu+0x43/0xcf
 [] ip_vs_schedule+0x181/0x4ba [ip_vs]
...

Signed-off-by: Hans Schillstrom 
Acked-by: Julian Anastasov 
Signed-off-by: Simon Horman 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
---
 net/netfilter/ipvs/ip_vs_pe_sip.c |6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/net/netfilter/ipvs/ip_vs_pe_sip.c 
b/net/netfilter/ipvs/ip_vs_pe_sip.c
index 12475ef..e5920fb 100644
--- a/net/netfilter/ipvs/ip_vs_pe_sip.c
+++ b/net/netfilter/ipvs/ip_vs_pe_sip.c
@@ -37,14 +37,10 @@ static int get_callid(const char *dptr, unsigned int 
dataoff,
if (ret > 0)
break;
if (!ret)
-   return 0;
+   return -EINVAL;
dataoff += *matchoff;
}
 
-   /* Empty callid is useless */
-   if (!*matchlen)
-   return -EINVAL;
-
/* Too large is useless */
if (*matchlen > IP_VS_PEDATA_MAXLEN)
return -EINVAL;

--
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/


[69/94] mm/pagewalk.c: walk_page_range should avoid VM_PFNMAP areas

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Cliff Wickman 

commit a9ff785e4437c83d2179161e012f5bdfbd6381f0 upstream.

A panic can be caused by simply cat'ing /proc//smaps while an
application has a VM_PFNMAP range.  It happened in-house when a
benchmarker was trying to decipher the memory layout of his program.

/proc//smaps and similar walks through a user page table should not
be looking at VM_PFNMAP areas.

Certain tests in walk_page_range() (specifically split_huge_page_pmd())
assume that all the mapped PFN's are backed with page structures.  And
this is not usually true for VM_PFNMAP areas.  This can result in panics
on kernel page faults when attempting to address those page structures.

There are a half dozen callers of walk_page_range() that walk through a
task's entire page table (as N.  Horiguchi pointed out).  So rather than
change all of them, this patch changes just walk_page_range() to ignore
VM_PFNMAP areas.

The logic of hugetlb_vma() is moved back into walk_page_range(), as we
want to test any vma in the range.

VM_PFNMAP areas are used by:
- graphics memory manager   gpu/drm/drm_gem.c
- global reference unit sgi-gru/grufile.c
- sgi special memorychar/mspec.c
- and probably several out-of-tree modules

[a...@linux-foundation.org: remove now-unused hugetlb_vma() stub]
Signed-off-by: Cliff Wickman 
Reviewed-by: Naoya Horiguchi 
Cc: Mel Gorman 
Cc: Andrea Arcangeli 
Cc: Dave Hansen 
Cc: David Sterba 
Cc: Johannes Weiner 
Cc: KOSAKI Motohiro 
Cc: "Kirill A. Shutemov" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings 
---
 mm/pagewalk.c |   70 +
 1 file changed, 36 insertions(+), 34 deletions(-)

--- a/mm/pagewalk.c
+++ b/mm/pagewalk.c
@@ -127,28 +127,7 @@ static int walk_hugetlb_range(struct vm_
return 0;
 }
 
-static struct vm_area_struct* hugetlb_vma(unsigned long addr, struct mm_walk 
*walk)
-{
-   struct vm_area_struct *vma;
-
-   /* We don't need vma lookup at all. */
-   if (!walk->hugetlb_entry)
-   return NULL;
-
-   VM_BUG_ON(!rwsem_is_locked(>mm->mmap_sem));
-   vma = find_vma(walk->mm, addr);
-   if (vma && vma->vm_start <= addr && is_vm_hugetlb_page(vma))
-   return vma;
-
-   return NULL;
-}
-
 #else /* CONFIG_HUGETLB_PAGE */
-static struct vm_area_struct* hugetlb_vma(unsigned long addr, struct mm_walk 
*walk)
-{
-   return NULL;
-}
-
 static int walk_hugetlb_range(struct vm_area_struct *vma,
  unsigned long addr, unsigned long end,
  struct mm_walk *walk)
@@ -199,30 +178,53 @@ int walk_page_range(unsigned long addr,
if (!walk->mm)
return -EINVAL;
 
+   VM_BUG_ON(!rwsem_is_locked(>mm->mmap_sem));
+
pgd = pgd_offset(walk->mm, addr);
do {
-   struct vm_area_struct *vma;
+   struct vm_area_struct *vma = NULL;
 
next = pgd_addr_end(addr, end);
 
/*
-* handle hugetlb vma individually because pagetable walk for
-* the hugetlb page is dependent on the architecture and
-* we can't handled it in the same manner as non-huge pages.
+* This function was not intended to be vma based.
+* But there are vma special cases to be handled:
+* - hugetlb vma's
+* - VM_PFNMAP vma's
 */
-   vma = hugetlb_vma(addr, walk);
+   vma = find_vma(walk->mm, addr);
if (vma) {
-   if (vma->vm_end < next)
+   /*
+* There are no page structures backing a VM_PFNMAP
+* range, so do not allow split_huge_page_pmd().
+*/
+   if ((vma->vm_start <= addr) &&
+   (vma->vm_flags & VM_PFNMAP)) {
next = vma->vm_end;
+   pgd = pgd_offset(walk->mm, next);
+   continue;
+   }
/*
-* Hugepage is very tightly coupled with vma, so
-* walk through hugetlb entries within a given vma.
+* Handle hugetlb vma individually because pagetable
+* walk for the hugetlb page is dependent on the
+* architecture and we can't handled it in the same
+* manner as non-huge pages.
 */
-   err = walk_hugetlb_range(vma, addr, next, walk);
-   if (err)
-   break;
-   pgd = pgd_offset(walk->mm, next);
-   continue;
+   if 

[14/94] ALSA: HDA: Fix Oops caused by dereference NULL pointer

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Wang YanQing 

commit 2195b063f6609e4c6268f291683902f25eaf9aa6 upstream.

The interrupt handler azx_interrupt will call azx_update_rirb,
which may call snd_hda_queue_unsol_event, snd_hda_queue_unsol_event
will dereference chip->bus pointer.

The problem is we alloc chip->bus in azx_codec_create
which will be called after we enable IRQ and enable unsolicited
event in azx_probe.

This will cause Oops due dereference NULL pointer. I meet it, good luck:)

[Rearranged the NULL check before the tracepoint and added another
 NULL check of bus->workq -- tiwai]

Signed-off-by: Wang YanQing 
Signed-off-by: Takashi Iwai 
Signed-off-by: Ben Hutchings 
---
 sound/pci/hda/hda_codec.c |3 +++
 1 file changed, 3 insertions(+)

--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -615,6 +615,9 @@ int snd_hda_queue_unsol_event(struct hda
struct hda_bus_unsolicited *unsol;
unsigned int wp;
 
+   if (!bus || !bus->workq)
+   return 0;
+
trace_hda_unsol_event(bus, res, res_ex);
unsol = bus->unsol;
if (!unsol)

--
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/


[42/94] ipmi: ipmi_devintf: compat_ioctl method fails to take ipmi_mutex

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Benjamin LaHaise 

commit 6368087e851e697679af059b4247aca33a69cef3 upstream.

When a 32 bit version of ipmitool is used on a 64 bit kernel, the
ipmi_devintf code fails to correctly acquire ipmi_mutex.  This results in
incomplete data being retrieved in some cases, or other possible failures.
Add a wrapper around compat_ipmi_ioctl() to take ipmi_mutex to fix this.

Signed-off-by: Benjamin LaHaise 
Signed-off-by: Corey Minyard 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings 
---
 drivers/char/ipmi/ipmi_devintf.c |   14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

--- a/drivers/char/ipmi/ipmi_devintf.c
+++ b/drivers/char/ipmi/ipmi_devintf.c
@@ -838,13 +838,25 @@ static long compat_ipmi_ioctl(struct fil
return ipmi_ioctl(filep, cmd, arg);
}
 }
+
+static long unlocked_compat_ipmi_ioctl(struct file *filep, unsigned int cmd,
+  unsigned long arg)
+{
+   int ret;
+
+   mutex_lock(_mutex);
+   ret = compat_ipmi_ioctl(filep, cmd, arg);
+   mutex_unlock(_mutex);
+
+   return ret;
+}
 #endif
 
 static const struct file_operations ipmi_fops = {
.owner  = THIS_MODULE,
.unlocked_ioctl = ipmi_unlocked_ioctl,
 #ifdef CONFIG_COMPAT
-   .compat_ioctl   = compat_ipmi_ioctl,
+   .compat_ioctl   = unlocked_compat_ipmi_ioctl,
 #endif
.open   = ipmi_open,
.release= ipmi_release,

--
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/


[52/94] USB: cxacru: potential underflow in cxacru_cm_get_array()

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Dan Carpenter 

commit 2a0ebf80aa95cc758d4725f74a7016e992606a39 upstream.

The value of "offd" comes off the instance->rcv_buf[] and we used it as
the offset into an array.  The problem is that we check the upper bound
but not for negative values.

Signed-off-by: Dan Carpenter 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
---
 drivers/usb/atm/cxacru.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/usb/atm/cxacru.c
+++ b/drivers/usb/atm/cxacru.c
@@ -686,7 +686,8 @@ static int cxacru_cm_get_array(struct cx
 {
int ret, len;
__le32 *buf;
-   int offb, offd;
+   int offb;
+   unsigned int offd;
const int stride = CMD_PACKET_SIZE / (4 * 2) - 1;
int buflen =  ((size - 1) / stride + 1 + size * 2) * 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/


[33/94] powerpc/pseries: Fix partition migration hang in stop_topology_update

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Brian King 

commit 444080d13d05dc38d07dd3bf751d38bce7ab7c72 upstream.

This fixes a hang that was observed during live partition migration.
Since stop_topology_update must not be called from an interrupt
context, call it earlier in the migration process. The hang observed
can be seen below:

WARNING: at kernel/timer.c:1011
Modules linked in: ip6t_LOG xt_tcpudp xt_pkttype ipt_LOG xt_limit ip6t_REJECT 
nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw xt_NOTRACK ipt_REJECT xt_state 
iptable_raw iptable_filter ip6table_mangle nf_conntrack_netbios_ns 
nf_conntrack_broadcast nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables 
ip6table_filter ip6_tables x_tables ipv6 fuse loop ibmveth sg ext3 jbd mbcache 
raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx 
raid10 raid1 raid0 scsi_dh_alua scsi_dh_rdac scsi_dh_hp_sw scsi_dh_emc 
dm_round_robin dm_multipath scsi_dh sd_mod crc_t10dif ibmvfc scsi_transport_fc 
scsi_tgt scsi_mod dm_snapshot dm_mod
NIP: c00c52d8 LR: c004be28 CTR: 
REGS: c0005ffd77d0 TRAP: 0700   Not tainted  (3.2.0-git-1-g07d106d)
MSR: 80021032   CR: 4884  XER: 0001
CFAR: c004be20
TASK = c0005ec78860[0] 'swapper/3' THREAD: c0005ec98000 CPU: 3
GPR00: 0001 c0005ffd7a50 c0fbbc98 c0ec8340
GPR04: 282a0020  4000 0101
GPR08: 0012 c0005ffd4000 0020 c0f3ba88
GPR12:  c7f40900 0001 0004
GPR16: 0001   c1022310
GPR20: 0001  00200200 c1029e14
GPR24:  0001 0040 c0003f74bc80
GPR28: c0003f74bc84 c0f38038 c0f16b58 c0ec8340
NIP [c00c52d8] .del_timer_sync+0x28/0x60
LR [c004be28] .stop_topology_update+0x20/0x38
Call Trace:
[c0005ffd7a50] [c0005ec78860] 0xc0005ec78860 (unreliable)
[c0005ffd7ad0] [c004be28] .stop_topology_update+0x20/0x38
[c0005ffd7b40] [c0028378] .__rtas_suspend_last_cpu+0x58/0x260
[c0005ffd7bf0] [c00fa230] 
.generic_smp_call_function_interrupt+0x160/0x358
[c0005ffd7cf0] [c0036ec8] .smp_ipi_demux+0x88/0x100
[c0005ffd7d80] [c005c154] .icp_hv_ipi_action+0x5c/0x80
[c0005ffd7e00] [c012a088] .handle_irq_event_percpu+0x100/0x318
[c0005ffd7f00] [c012e774] .handle_percpu_irq+0x84/0xd0
[c0005ffd7f90] [c0022ba8] .call_handle_irq+0x1c/0x2c
[c0005ec9ba20] [c001157c] .do_IRQ+0x22c/0x2a8
[c0005ec9bae0] [c00054bc] hardware_interrupt_entry+0x18/0x1c
Exception: 501 at .cpu_idle+0x194/0x2f8
LR = .cpu_idle+0x194/0x2f8
[c0005ec9bdd0] [c0017e58] .cpu_idle+0x188/0x2f8 (unreliable)
[c0005ec9be90] [c067ec18] .start_secondary+0x3e4/0x524
[c0005ec9bf90] [c00093e8] .start_secondary_prolog+0x10/0x14
Instruction dump:
ebe1fff8 4e800020 fbe1fff8 7c0802a6 f8010010 7c7f1b78 f821ff81 78290464
80090014 5400019e 7cd0 78000fe0 <0b00> 480c 7c210b78 7c421378

Signed-off-by: Brian King 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Ben Hutchings 
---
 arch/powerpc/kernel/rtas.c   |5 +++--
 arch/powerpc/platforms/pseries/suspend.c |6 +-
 2 files changed, 8 insertions(+), 3 deletions(-)

--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -716,7 +716,6 @@ static int __rtas_suspend_last_cpu(struc
int cpu;
 
slb_set_size(SLB_MIN_SIZE);
-   stop_topology_update();
printk(KERN_DEBUG "calling ibm,suspend-me on cpu %i\n", 
smp_processor_id());
 
while (rc == H_MULTI_THREADS_ACTIVE && !atomic_read(>done) &&
@@ -732,7 +731,6 @@ static int __rtas_suspend_last_cpu(struc
rc = atomic_read(>error);
 
atomic_set(>error, rc);
-   start_topology_update();
pSeries_coalesce_init();
 
if (wake_when_done) {
@@ -846,6 +844,7 @@ int rtas_ibm_suspend_me(struct rtas_args
atomic_set(, 0);
data.token = rtas_token("ibm,suspend-me");
data.complete = 
+   stop_topology_update();
 
/* Call function on all CPUs.  One of us will make the
 * rtas call
@@ -858,6 +857,8 @@ int rtas_ibm_suspend_me(struct rtas_args
if (atomic_read() != 0)
printk(KERN_ERR "Error doing global join\n");
 
+   start_topology_update();
+
return atomic_read();
 }
 #else /* CONFIG_PPC_PSERIES */
--- a/arch/powerpc/platforms/pseries/suspend.c
+++ b/arch/powerpc/platforms/pseries/suspend.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static u64 stream_id;
 static struct sys_device suspend_sysdev;
@@ -138,8 +139,11 @@ static ssize_t store_hibernate(struct sy
   

[01/94] Revert "drm/i915: Fix detection of base of stolen memory"

2013-05-27 Thread Ben Hutchings
3.2.46-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Ben Hutchings 

This reverts commit 53e587aa5ca81497d0ea6e340320ec5778d1f311.
Yves-Alexis Perez reported that it broke the driver on two machines
with GMA4500 and i965 chips.  Only the backported version in 3.2.45
had this effect; the fix in mainline is fine.

Daniel Vetter stated that the fix is not needed in 3.2 anyway.

Reported-by: Yves-Alexis Perez 
Signed-off-by: Ben Hutchings 
---
 drivers/gpu/drm/i915/i915_dma.c |   81 +++
 drivers/gpu/drm/i915/i915_drv.h |1 -
 2 files changed, 40 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index c77fc67..ca67338 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1007,50 +1007,56 @@ intel_teardown_mchbar(struct drm_device *dev)
release_resource(_priv->mch_res);
 }
 
-static unsigned long i915_stolen_to_physical(struct drm_device *dev)
+#define PTE_ADDRESS_MASK   0xf000
+#define PTE_ADDRESS_MASK_HIGH  0x00f0 /* i915+ */
+#define PTE_MAPPING_TYPE_UNCACHED  (0 << 1)
+#define PTE_MAPPING_TYPE_DCACHE(1 << 1) /* i830 only */
+#define PTE_MAPPING_TYPE_CACHED(3 << 1)
+#define PTE_MAPPING_TYPE_MASK  (3 << 1)
+#define PTE_VALID  (1 << 0)
+
+/**
+ * i915_stolen_to_phys - take an offset into stolen memory and turn it into
+ *   a physical one
+ * @dev: drm device
+ * @offset: address to translate
+ *
+ * Some chip functions require allocations from stolen space and need the
+ * physical address of the memory in question.
+ */
+static unsigned long i915_stolen_to_phys(struct drm_device *dev, u32 offset)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
struct pci_dev *pdev = dev_priv->bridge_dev;
u32 base;
 
+#if 0
/* On the machines I have tested the Graphics Base of Stolen Memory
-* is unreliable, so on those compute the base by subtracting the
-* stolen memory from the Top of Low Usable DRAM which is where the
-* BIOS places the graphics stolen memory.
-*
-* On gen2, the layout is slightly different with the Graphics Segment
-* immediately following Top of Memory (or Top of Usable DRAM). Note
-* it appears that TOUD is only reported by 865g, so we just use the
-* top of memory as determined by the e820 probe.
-*
-* XXX gen2 requires an unavailable symbol and 945gm fails with
-* its value of TOLUD.
+* is unreliable, so compute the base by subtracting the stolen memory
+* from the Top of Low Usable DRAM which is where the BIOS places
+* the graphics stolen memory.
 */
-   base = 0;
-   if (INTEL_INFO(dev)->gen >= 6) {
-   /* Read Base Data of Stolen Memory Register (BDSM) directly.
-* Note that there is also a MCHBAR miror at 0x1080c0 or
-* we could use device 2:0x5c instead.
-   */
-   pci_read_config_dword(pdev, 0xB0, );
-   base &= ~4095; /* lower bits used for locking register */
-   } else if (INTEL_INFO(dev)->gen > 3 || IS_G33(dev)) {
-   /* Read Graphics Base of Stolen Memory directly */
+   if (INTEL_INFO(dev)->gen > 3 || IS_G33(dev)) {
+   /* top 32bits are reserved = 0 */
pci_read_config_dword(pdev, 0xA4, );
-#if 0
-   } else if (IS_GEN3(dev)) {
+   } else {
+   /* XXX presume 8xx is the same as i915 */
+   pci_bus_read_config_dword(pdev->bus, 2, 0x5C, );
+   }
+#else
+   if (INTEL_INFO(dev)->gen > 3 || IS_G33(dev)) {
+   u16 val;
+   pci_read_config_word(pdev, 0xb0, );
+   base = val >> 4 << 20;
+   } else {
u8 val;
-   /* Stolen is immediately below Top of Low Usable DRAM */
pci_read_config_byte(pdev, 0x9c, );
base = val >> 3 << 27;
-   base -= dev_priv->mm.gtt->stolen_size;
-   } else {
-   /* Stolen is immediately above Top of Memory */
-   base = max_low_pfn_mapped << PAGE_SHIFT;
-#endif
}
+   base -= dev_priv->mm.gtt->stolen_size;
+#endif
 
-   return base;
+   return base + offset;
 }
 
 static void i915_warn_stolen(struct drm_device *dev)
@@ -1075,7 +1081,7 @@ static void i915_setup_compression(struct drm_device 
*dev, int size)
if (!compressed_fb)
goto err;
 
-   cfb_base = dev_priv->mm.stolen_base + compressed_fb->start;
+   cfb_base = i915_stolen_to_phys(dev, compressed_fb->start);
if (!cfb_base)
goto err_fb;
 
@@ -1088,7 +1094,7 @@ static void i915_setup_compression(struct drm_device 
*dev, int size)
if (!compressed_llb)
   

  1   2   3   4   5   6   7   8   9   10   >