[PATCH 06/24] rtc: rtc-davinci: use module_platform_driver_probe()

2013-03-03 Thread Jingoo Han
This patch uses module_platform_driver_probe() macro which makes
the code smaller and simpler.

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-davinci.c |   12 +---
 1 files changed, 1 insertions(+), 11 deletions(-)

diff --git a/drivers/rtc/rtc-davinci.c b/drivers/rtc/rtc-davinci.c
index db877e0..1b0f9322 100644
--- a/drivers/rtc/rtc-davinci.c
+++ b/drivers/rtc/rtc-davinci.c
@@ -588,17 +588,7 @@ static struct platform_driver davinci_rtc_driver = {
},
 };
 
-static int __init rtc_init(void)
-{
-   return platform_driver_probe(_rtc_driver, davinci_rtc_probe);
-}
-module_init(rtc_init);
-
-static void __exit rtc_exit(void)
-{
-   platform_driver_unregister(_rtc_driver);
-}
-module_exit(rtc_exit);
+module_platform_driver_probe(davinci_rtc_driver, davinci_rtc_probe);
 
 MODULE_AUTHOR("Miguel Aguilar ");
 MODULE_DESCRIPTION("Texas Instruments DaVinci PRTC Driver");
-- 
1.7.2.5


--
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 04/24] rtc: rtc-au1xxx: use module_platform_driver_probe()

2013-03-03 Thread Jingoo Han
This patch uses module_platform_driver_probe() macro which makes
the code smaller and simpler.

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-au1xxx.c |   13 +
 1 files changed, 1 insertions(+), 12 deletions(-)

diff --git a/drivers/rtc/rtc-au1xxx.c b/drivers/rtc/rtc-au1xxx.c
index b309da4..dfd6d66 100644
--- a/drivers/rtc/rtc-au1xxx.c
+++ b/drivers/rtc/rtc-au1xxx.c
@@ -134,18 +134,7 @@ static struct platform_driver au1xrtc_driver = {
.remove = au1xtoy_rtc_remove,
 };
 
-static int __init au1xtoy_rtc_init(void)
-{
-   return platform_driver_probe(_driver, au1xtoy_rtc_probe);
-}
-
-static void __exit au1xtoy_rtc_exit(void)
-{
-   platform_driver_unregister(_driver);
-}
-
-module_init(au1xtoy_rtc_init);
-module_exit(au1xtoy_rtc_exit);
+module_platform_driver_probe(au1xrtc_driver, au1xtoy_rtc_probe);
 
 MODULE_DESCRIPTION("Au1xxx TOY-counter-based RTC driver");
 MODULE_AUTHOR("Manuel Lauss ");
-- 
1.7.2.5


--
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 05/24] rtc: rtc-coh901331: use module_platform_driver_probe()

2013-03-03 Thread Jingoo Han
This patch uses module_platform_driver_probe() macro which makes
the code smaller and simpler.

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-coh901331.c |   13 +
 1 files changed, 1 insertions(+), 12 deletions(-)

diff --git a/drivers/rtc/rtc-coh901331.c b/drivers/rtc/rtc-coh901331.c
index 2d28ec1a..f53fcd6 100644
--- a/drivers/rtc/rtc-coh901331.c
+++ b/drivers/rtc/rtc-coh901331.c
@@ -287,18 +287,7 @@ static struct platform_driver coh901331_driver = {
.shutdown = coh901331_shutdown,
 };
 
-static int __init coh901331_init(void)
-{
-   return platform_driver_probe(_driver, coh901331_probe);
-}
-
-static void __exit coh901331_exit(void)
-{
-   platform_driver_unregister(_driver);
-}
-
-module_init(coh901331_init);
-module_exit(coh901331_exit);
+module_platform_driver_probe(coh901331_driver, coh901331_probe);
 
 MODULE_AUTHOR("Linus Walleij ");
 MODULE_DESCRIPTION("ST-Ericsson AB COH 901 331 RTC Driver");
-- 
1.7.2.5


--
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 03/24] rtc: rtc-at91rm9200: use module_platform_driver_probe()

2013-03-03 Thread Jingoo Han
This patch uses module_platform_driver_probe() macro which makes
the code smaller and simpler.

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-at91rm9200.c |   13 +
 1 files changed, 1 insertions(+), 12 deletions(-)

diff --git a/drivers/rtc/rtc-at91rm9200.c b/drivers/rtc/rtc-at91rm9200.c
index 434ebc3..f63c8fe 100644
--- a/drivers/rtc/rtc-at91rm9200.c
+++ b/drivers/rtc/rtc-at91rm9200.c
@@ -390,18 +390,7 @@ static struct platform_driver at91_rtc_driver = {
},
 };
 
-static int __init at91_rtc_init(void)
-{
-   return platform_driver_probe(_rtc_driver, at91_rtc_probe);
-}
-
-static void __exit at91_rtc_exit(void)
-{
-   platform_driver_unregister(_rtc_driver);
-}
-
-module_init(at91_rtc_init);
-module_exit(at91_rtc_exit);
+module_platform_driver_probe(at91_rtc_driver, at91_rtc_probe);
 
 MODULE_AUTHOR("Rick Bronson");
 MODULE_DESCRIPTION("RTC driver for Atmel AT91RM9200");
-- 
1.7.2.5


--
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 02/24] rtc: rtc-at32ap700x: use module_platform_driver_probe()

2013-03-03 Thread Jingoo Han
This patch uses module_platform_driver_probe() macro which makes
the code smaller and simpler.

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-at32ap700x.c |   12 +---
 1 files changed, 1 insertions(+), 11 deletions(-)

diff --git a/drivers/rtc/rtc-at32ap700x.c b/drivers/rtc/rtc-at32ap700x.c
index 8dd0830..619c887 100644
--- a/drivers/rtc/rtc-at32ap700x.c
+++ b/drivers/rtc/rtc-at32ap700x.c
@@ -302,17 +302,7 @@ static struct platform_driver at32_rtc_driver = {
},
 };
 
-static int __init at32_rtc_init(void)
-{
-   return platform_driver_probe(_rtc_driver, at32_rtc_probe);
-}
-module_init(at32_rtc_init);
-
-static void __exit at32_rtc_exit(void)
-{
-   platform_driver_unregister(_rtc_driver);
-}
-module_exit(at32_rtc_exit);
+module_platform_driver_probe(at32_rtc_driver, at32_rtc_probe);
 
 MODULE_AUTHOR("Hans-Christian Egtvedt ");
 MODULE_DESCRIPTION("Real time clock for AVR32 AT32AP700x");
-- 
1.7.2.5


--
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 01/24] rtc: rtc-ab3100: use module_platform_driver_probe()

2013-03-03 Thread Jingoo Han
This patch uses module_platform_driver_probe() macro which makes
the code smaller and simpler.

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-ab3100.c |   14 +-
 1 files changed, 1 insertions(+), 13 deletions(-)

diff --git a/drivers/rtc/rtc-ab3100.c b/drivers/rtc/rtc-ab3100.c
index 261a07e..c2f12d3 100644
--- a/drivers/rtc/rtc-ab3100.c
+++ b/drivers/rtc/rtc-ab3100.c
@@ -257,19 +257,7 @@ static struct platform_driver ab3100_rtc_driver = {
.remove  = __exit_p(ab3100_rtc_remove),
 };
 
-static int __init ab3100_rtc_init(void)
-{
-   return platform_driver_probe(_rtc_driver,
-ab3100_rtc_probe);
-}
-
-static void __exit ab3100_rtc_exit(void)
-{
-   platform_driver_unregister(_rtc_driver);
-}
-
-module_init(ab3100_rtc_init);
-module_exit(ab3100_rtc_exit);
+module_platform_driver_probe(ab3100_rtc_driver, ab3100_rtc_probe);
 
 MODULE_AUTHOR("Linus Walleij ");
 MODULE_DESCRIPTION("AB3100 RTC Driver");
-- 
1.7.2.5


--
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: [ 093/153] ALSA: hda - hdmi: Make jacks phantom, if theyre not detectable

2013-03-03 Thread David Henningsson

On 03/04/2013 08:48 AM, Greg Kroah-Hartman wrote:

On Mon, Mar 04, 2013 at 08:46:16AM +0100, David Henningsson wrote:

On 03/04/2013 06:13 AM, Ben Hutchings wrote:

On Mon, 2013-03-04 at 03:38 +, Ben Hutchings wrote:

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

--

From: David Henningsson 

commit 30efd8debd1ef30be342d374f01e993509f5b76b upstream.

Just as for analog codecs, a jack that isn't suitable for detection
(in this case, NO_PRESENCE was set) should be a phantom Jack
instead of a normal one.

Thanks to Raymond Yau for spotting.

BugLink: https://bugs.launchpad.net/bugs/961286
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=903869
Signed-off-by: David Henningsson 
Signed-off-by: Takashi Iwai 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings 


David, do I need to change this further for 3.2.y?


Greg and Ben,

Given some thought, the definition of is_jack_detectable has
changed/improved over kernels. Therefore I think it's safer not to
apply the patch at all for kernels earlier than 3.6. Let's revisit
this decision if there's actually a user demand for this fix.


So should I revert this in the next 3.4 release, as it's now in the
3.4.35 release.


That seems to be the safest option; given that we don't get people with 
the actual hardware to test the different options and report back which 
one works best.


Sorry for the late reply.

--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
--
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: [ 34/77] xen/blkback: Dont trust the handle from the frontend.

2013-03-03 Thread Jan Beulich
>>> On 03.03.13 at 11:20, Paul Bolle  wrote:
> Perhaps Konrad, Jan, Or Ian can tell whether the patch still needs to go
> in stable as is, because the problem it fixes is more severe than the
> problem it apparently creates. Maybe a mainline fix is needed before
> this can go in, or perhaps even a stable specific fix (if context
> changes are to blame).

For one, a fix for the (indeed valid) compiler warning has been in
Konrad's tree for several days
(http://git.kernel.org/cgit/linux/kernel/git/konrad/xen.git/commit/drivers/block/xen-blkback/blkback.c?id=a72d9002f80bffd7e4c7d60e5a9caa0cddffe894).

And second, there's nothing really being fixed with the patch in
question here. The title is kind of misleading, as the handle
coming from the frontend is - without said patch - in the worst
case being used for the very message that triggered the
compiler warning. Nothing else is affected, the code just gave
the impression that the handle was used.

IOW I don't see why this got proposed for stable at all.

Jan


--
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] usb: host: tegra: Reset Tegra USB controller before init

2013-03-03 Thread Venu Byravarasu
> -Original Message-
> From: Stephen Warren [mailto:swar...@wwwdotorg.org]
> Sent: Thursday, February 28, 2013 11:47 PM
> To: Venu Byravarasu
> Cc: gre...@linuxfoundation.org; st...@rowland.harvard.edu; linux-
> u...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] usb: host: tegra: Reset Tegra USB controller before init
> 
> On 02/27/2013 11:36 PM, Venu Byravarasu wrote:
> > To clear any configurations made by U-Boot on Tegra USB controller,
> > reset it before init in probe.
> 
> > diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
> 
> > @@ -691,6 +692,10 @@ static int tegra_ehci_probe(struct platform_device
> *pdev)
> > if (err)
> > goto fail_clk;
> >
> > +   tegra_periph_reset_assert(tegra->clk);
> > +   udelay(1);
> > +   tegra_periph_reset_deassert(tegra->clk);
> 
> I think this patch might cause unintended consequences.
> 
> When the Tegra PHY code is converted to a driver (i.e. has its own
> probe), the initial order of execution of the PHY and EHCI driver probes
> will not be guaranteed.
> 
> In particular, since the EHCI probe will attempt to "find" the PHY
> device, and defer the EHCI probe until it can do so, this guarantees
> that the PHY's probe() will have completed before EHCI's probe()
> completes (although EHCI's probe may start running first some number of
> times, and be retried with -EPROBE_DEFERRED for a variety of reasons).
> 
> Now, if the PHY driver's probe() actually touches HW and sets up some
> registers, isn't this reset call going to trash any of that register
> setup? Or, will PHY probe() not touch registers, but only do so during
> the standard PHY open/init "op"/API calls?
 
Yes, PHY driver probe does not touch any registers. It just sets up the PHY API 
hooks.
These APIs will be called from ehci-tegra.c as part of ehci tegra probe 
function, after
getting  PHY handle, which in turn happens after issuing above reset.

Thanks to Stephen & Alan, for the review comments.
 
> 
> I think the way to solve this is to put the reset call into the PHY
> driver. I assume it has access to the appropriate clock object. 

--
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 2/2] fs: Limit sys_mount to only request filesystem modules.

2013-03-03 Thread Eric W. Biederman

Modify the request_module to prefix the file system type with "fs-"
and add aliases to all of the filesystems that can be built as modules
to match.

A common practice is to build all of the kernel code and leave code
that is not commonly needed as modules, with the result that many
users are exposed to any bug anywhere in the kernel.

Looking for filesystems with a fs- prefix limits the pool of possible
modules that can be loaded by mount to just filesystems trivially
making things safer with no real cost.

Using aliases means user space can control the policy of which
filesystem modules are auto-loaded by editing /etc/modprobe.d/*.conf
with blacklist and alias directives.  Allowing simple, safe,
well understood work-arounds to known problematic software.

This also addresses a rare but unfortunate problem where the filesystem
name is not the same as it's module name and module auto-loading
would not work.  While writing this patch I saw a handful of such
cases.  The most significant being autofs that lives in the module
autofs4.

This is relevant to user namespaces because we can reach the request
module in get_fs_type() without having any special permissions, and
people get uncomfortable when a user specified string (in this case
the filesystem type) goes all of the way to request_module.

After having looked at this issue I don't think there is any
particular reason to perform any filtering or permission checks beyond
making it clear in the module request that we want a filesystem
module.  The common pattern in the kernel is to call request_module()
without regards to the users permissions.  In general all a filesystem
module does once loaded is call register_filesystem() and go to sleep.
Which means there is not much attack surface exposed by loading a
filesytem module unless the filesystem is mounted.  In a user
namespace filesystems are not mounted unless .fs_flags = FS_USERNS_MOUNT,
which most filesystems do not set today.

Acked-by: Serge Hallyn 
Acked-by: Kees Cook 
Reported-by: Kees Cook 
Signed-off-by: "Eric W. Biederman" 
---
 arch/ia64/kernel/perfmon.c|1 +
 arch/powerpc/platforms/cell/spufs/inode.c |1 +
 arch/s390/hypfs/inode.c   |1 +
 drivers/firmware/efivars.c|1 +
 drivers/infiniband/hw/ipath/ipath_fs.c|1 +
 drivers/infiniband/hw/qib/qib_fs.c|1 +
 drivers/misc/ibmasm/ibmasmfs.c|1 +
 drivers/mtd/mtdchar.c |1 +
 drivers/oprofile/oprofilefs.c |1 +
 drivers/staging/ccg/f_fs.c|1 +
 drivers/usb/gadget/f_fs.c |1 +
 drivers/usb/gadget/inode.c|1 +
 drivers/xen/xenfs/super.c |1 +
 fs/9p/vfs_super.c |1 +
 fs/adfs/super.c   |1 +
 fs/affs/super.c   |1 +
 fs/afs/super.c|1 +
 fs/autofs4/init.c |1 +
 fs/befs/linuxvfs.c|1 +
 fs/bfs/inode.c|1 +
 fs/binfmt_misc.c  |1 +
 fs/btrfs/super.c  |1 +
 fs/ceph/super.c   |1 +
 fs/coda/inode.c   |1 +
 fs/configfs/mount.c   |1 +
 fs/cramfs/inode.c |1 +
 fs/debugfs/inode.c|1 +
 fs/devpts/inode.c |1 +
 fs/ecryptfs/main.c|1 +
 fs/efs/super.c|1 +
 fs/exofs/super.c  |1 +
 fs/ext2/super.c   |1 +
 fs/ext3/super.c   |1 +
 fs/ext4/super.c   |5 +++--
 fs/f2fs/super.c   |1 +
 fs/fat/namei_msdos.c  |1 +
 fs/fat/namei_vfat.c   |1 +
 fs/filesystems.c  |2 +-
 fs/freevxfs/vxfs_super.c  |2 +-
 fs/fuse/control.c |1 +
 fs/fuse/inode.c   |2 ++
 fs/gfs2/ops_fstype.c  |4 +++-
 fs/hfs/super.c|1 +
 fs/hfsplus/super.c|1 +
 fs/hppfs/hppfs.c  |1 +
 fs/hugetlbfs/inode.c  |1 +
 fs/isofs/inode.c  |3 +--
 fs/jffs2/super.c  |1 +
 fs/jfs/super.c|1 +
 fs/logfs/super.c  |1 +
 fs/minix/inode.c  |1 +
 fs/ncpfs/inode.c  |1 +
 fs/nfs/super.c|3 ++-
 fs/nfsd/nfsctl.c  |1 +
 fs/nilfs2/super.c |1 +
 fs/ntfs/super.c   |

Re: [PATCH V3 1/3] mtd: add new fields to nand_flash_dev{}

2013-03-03 Thread Artem Bityutskiy
On Mon, 2013-03-04 at 13:57 +0800, Huang Shijie wrote:
> The current code uses the @id to store the device id(byte 1).
> But if we use the 8 bytes id data as the keyword, and expand the @id 
> field to 8byte array,
> the device id is the second byte now. All the added zeros are for the 

I do not think you need to store the full array of ID's. Device ID's for
all the 4 of above chips are different, which is enough to distinguish
between them.

The only thing you need to add is the OOB size field to 'struct
nand_flash_dev'.

-- 
Best Regards,
Artem Bityutskiy

--
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 1/2] userns: Stop oopsing in key_change_session_keyring

2013-03-03 Thread Eric W. Biederman

Dave Jones  writes:
> Just hit this on Linus' current tree.
>
> [   89.621770] BUG: unable to handle kernel NULL pointer dereference at 
> 00c8
> [   89.623111] IP: [] commit_creds+0x250/0x2f0
> [   89.624062] PGD 122bfd067 PUD 122bfe067 PMD 0
> [   89.624901] Oops:  [#1] PREEMPT SMP
> [   89.625678] Modules linked in: caif_socket caif netrom bridge hidp 8021q 
> garp stp mrp rose llc2 af_rxrpc phonet af_key binfmt_misc bnep l2tp_ppp 
> can_bcm l2tp_core pppoe pppox can_raw scsi_transport_iscsi ppp_generic slhc 
> nfnetlink can ipt_ULOG ax25 decnet irda nfc rds x25 crc_ccitt appletalk atm 
> ipx p8023 psnap p8022 llc lockd sunrpc ip6t_REJECT nf_conntrack_ipv6 
> nf_defrag_ipv6 xt_conntrack nf_conntrack ip6table_filter ip6_tables btusb 
> bluetooth snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_pcm vhost_net 
> snd_page_alloc snd_timer tun macvtap usb_debug snd rfkill microcode macvlan 
> edac_core pcspkr serio_raw kvm_amd soundcore kvm r8169 mii
> [   89.637846] CPU 2
> [   89.638175] Pid: 782, comm: trinity-main Not tainted 3.8.0+ #63 Gigabyte 
> Technology Co., Ltd. GA-MA78GM-S2H/GA-MA78GM-S2H
> [   89.639850] RIP: 0010:[]  [] 
> commit_creds+0x250/0x2f0
> [   89.641161] RSP: 0018:880115657eb8  EFLAGS: 00010207
> [   89.641984] RAX: 03e8 RBX: 88012688b000 RCX: 
> 
> [   89.643069] RDX:  RSI: 81c32960 RDI: 
> 880105839600
> [   89.644167] RBP: 880115657ed8 R08:  R09: 
> 
> [   89.645254] R10: 0001 R11: 0246 R12: 
> 880105839600
> [   89.646340] R13: 88011beea490 R14: 88011beea490 R15: 
> 
> [   89.647431] FS:  7f3ac063b740() GS:88012b20() 
> knlGS:
> [   89.648660] CS:  0010 DS:  ES:  CR0: 8005003b
> [   89.649548] CR2: 00c8 CR3: 000122bfc000 CR4: 
> 07e0
> [   89.650635] DR0:  DR1:  DR2: 
> 
> [   89.651723] DR3:  DR6: 0ff0 DR7: 
> 0400
> [   89.652812] Process trinity-main (pid: 782, threadinfo 880115656000, 
> task 88011beea490)
> [   89.654128] Stack:
> [   89.654433]   8801058396a0 880105839600 
> 88011beeaa78
> [   89.655769]  880115657ef8 812c7d9b 82079be0 
> 
> [   89.657073]  880115657f28 8106c665 0002 
> 880115657f58
> [   89.658399] Call Trace:
> [   89.658822]  [] key_change_session_keyring+0xfb/0x140
> [   89.659845]  [] task_work_run+0xa5/0xd0
> [   89.660698]  [] do_notify_resume+0x71/0xb0
> [   89.661581]  [] int_signal+0x12/0x17
> [   89.662385] Code: 24 90 00 00 00 48 8b b3 90 00 00 00 49 8b 4c 24 40 48 39 
> f2 75 08 e9 83 00 00 00 48 89 ca 48 81 fa 60 29 c3 81 0f 84 41 fe ff ff <48> 
> 8b 8a c8 00 00 00 48 39 ce 75 e4 3b 82 d0 00 00 00 0f 84 4b
> [   89.667778] RIP  [] commit_creds+0x250/0x2f0
> [   89.668733]  RSP 
> [   89.669301] CR2: 00c8
>
> My fastest trinity induced oops yet!
>
>
> Appears to be..
>
> if ((set_ns == subset_ns->parent)  &&
>  850:   48 8b 8a c8 00 00 00mov0xc8(%rdx),%rcx
>
> from the inlined cred_cap_issubset

By historical accident we have been reading trying to set new->user_ns
from new->user_ns.  Which is totally silly as new->user_ns is NULL (as
is every other field in new except session_keyring at that point).

The intent is clearly to copy all of the fields from old to new so copy
old->user_ns into  into new->user_ns.

Cc: sta...@vger.kernel.org
Reported-by: Dave Jones 
Tested-by: Dave Jones 
Acked-by: Serge Hallyn 
Signed-off-by: "Eric W. Biederman" 
---
 security/keys/process_keys.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/security/keys/process_keys.c b/security/keys/process_keys.c
index 58dfe08..a571fad 100644
--- a/security/keys/process_keys.c
+++ b/security/keys/process_keys.c
@@ -839,7 +839,7 @@ void key_change_session_keyring(struct callback_head *twork)
new-> sgid  = old-> sgid;
new->fsgid  = old->fsgid;
new->user   = get_uid(old->user);
-   new->user_ns= get_user_ns(new->user_ns);
+   new->user_ns= get_user_ns(old->user_ns);
new->group_info = get_group_info(old->group_info);
 
new->securebits = old->securebits;
-- 
1.7.5.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/


[PATCH 0/2] userns bug fixes for v3.9-rc2 for review

2013-03-03 Thread Eric W. Biederman

Baring problems these are the changes I intend to put in linux-next and
then send to Linus for v3.9-rc2.

The first is a trivial oops fix.
The second reworks how mount -t triggers module loading to make it
harder to abuse. 

Eric W. Biederman (2):
  userns: Stop oopsing in key_change_session_keyring
  fs: Limit sys_mount to only request filesystem modules.

 arch/ia64/kernel/perfmon.c|1 +
 arch/powerpc/platforms/cell/spufs/inode.c |1 +
 arch/s390/hypfs/inode.c   |1 +
 drivers/firmware/efivars.c|1 +
 drivers/infiniband/hw/ipath/ipath_fs.c|1 +
 drivers/infiniband/hw/qib/qib_fs.c|1 +
 drivers/misc/ibmasm/ibmasmfs.c|1 +
 drivers/mtd/mtdchar.c |1 +
 drivers/oprofile/oprofilefs.c |1 +
 drivers/staging/ccg/f_fs.c|1 +
 drivers/usb/gadget/f_fs.c |1 +
 drivers/usb/gadget/inode.c|1 +
 drivers/xen/xenfs/super.c |1 +
 fs/9p/vfs_super.c |1 +
 fs/adfs/super.c   |1 +
 fs/affs/super.c   |1 +
 fs/afs/super.c|1 +
 fs/autofs4/init.c |1 +
 fs/befs/linuxvfs.c|1 +
 fs/bfs/inode.c|1 +
 fs/binfmt_misc.c  |1 +
 fs/btrfs/super.c  |1 +
 fs/ceph/super.c   |1 +
 fs/coda/inode.c   |1 +
 fs/configfs/mount.c   |1 +
 fs/cramfs/inode.c |1 +
 fs/debugfs/inode.c|1 +
 fs/devpts/inode.c |1 +
 fs/ecryptfs/main.c|1 +
 fs/efs/super.c|1 +
 fs/exofs/super.c  |1 +
 fs/ext2/super.c   |1 +
 fs/ext3/super.c   |1 +
 fs/ext4/super.c   |5 +++--
 fs/f2fs/super.c   |1 +
 fs/fat/namei_msdos.c  |1 +
 fs/fat/namei_vfat.c   |1 +
 fs/filesystems.c  |2 +-
 fs/freevxfs/vxfs_super.c  |2 +-
 fs/fuse/control.c |1 +
 fs/fuse/inode.c   |2 ++
 fs/gfs2/ops_fstype.c  |4 +++-
 fs/hfs/super.c|1 +
 fs/hfsplus/super.c|1 +
 fs/hppfs/hppfs.c  |1 +
 fs/hugetlbfs/inode.c  |1 +
 fs/isofs/inode.c  |3 +--
 fs/jffs2/super.c  |1 +
 fs/jfs/super.c|1 +
 fs/logfs/super.c  |1 +
 fs/minix/inode.c  |1 +
 fs/ncpfs/inode.c  |1 +
 fs/nfs/super.c|3 ++-
 fs/nfsd/nfsctl.c  |1 +
 fs/nilfs2/super.c |1 +
 fs/ntfs/super.c   |1 +
 fs/ocfs2/dlmfs/dlmfs.c|1 +
 fs/omfs/inode.c   |1 +
 fs/openpromfs/inode.c |1 +
 fs/qnx4/inode.c   |1 +
 fs/qnx6/inode.c   |1 +
 fs/reiserfs/super.c   |1 +
 fs/romfs/super.c  |1 +
 fs/sysv/super.c   |3 ++-
 fs/ubifs/super.c  |1 +
 fs/ufs/super.c|1 +
 fs/xfs/xfs_super.c|1 +
 include/linux/fs.h|2 ++
 net/sunrpc/rpc_pipe.c |4 +---
 security/keys/process_keys.c  |2 +-
 70 files changed, 78 insertions(+), 13 deletions(-)
--
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: [ 093/153] ALSA: hda - hdmi: Make jacks phantom, if theyre not detectable

2013-03-03 Thread Greg Kroah-Hartman
On Mon, Mar 04, 2013 at 08:46:16AM +0100, David Henningsson wrote:
> On 03/04/2013 06:13 AM, Ben Hutchings wrote:
> >On Mon, 2013-03-04 at 03:38 +, Ben Hutchings wrote:
> >>3.2-stable review patch.  If anyone has any objections, please let me know.
> >>
> >>--
> >>
> >>From: David Henningsson 
> >>
> >>commit 30efd8debd1ef30be342d374f01e993509f5b76b upstream.
> >>
> >>Just as for analog codecs, a jack that isn't suitable for detection
> >>(in this case, NO_PRESENCE was set) should be a phantom Jack
> >>instead of a normal one.
> >>
> >>Thanks to Raymond Yau for spotting.
> >>
> >>BugLink: https://bugs.launchpad.net/bugs/961286
> >>BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=903869
> >>Signed-off-by: David Henningsson 
> >>Signed-off-by: Takashi Iwai 
> >>[bwh: Backported to 3.2: adjust context]
> >>Signed-off-by: Ben Hutchings 
> >
> >David, do I need to change this further for 3.2.y?
> 
> Greg and Ben,
> 
> Given some thought, the definition of is_jack_detectable has
> changed/improved over kernels. Therefore I think it's safer not to
> apply the patch at all for kernels earlier than 3.6. Let's revisit
> this decision if there's actually a user demand for this fix.

So should I revert this in the next 3.4 release, as it's now in the
3.4.35 release.

thanks,

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


[PATCH V2 1/2] cpufreq: ondemand: Don't update sample_type if we don't evaluate load again

2013-03-03 Thread Viresh Kumar
Because we have per cpu timer now, we check if we need to evaluate load again or
not (In case it is recently evaluated). Here the 2nd cpu which got timer
interrupt updates core_dbs_info->sample_type irrespective of load evaluation is
required or not. Which is wrong as the first cpu is dependent on this variable
set to an older value.

Moreover it would be best in this case to schedule 2nd cpu's timer to
sampling_rate instead of freq_lo or hi as that must be managed by the other cpu.
In case the other cpu idles in between then also we wouldn't loose much power.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq_ondemand.c | 24 +++-
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/drivers/cpufreq/cpufreq_ondemand.c 
b/drivers/cpufreq/cpufreq_ondemand.c
index c5fd794..e76f4f8 100644
--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -224,34 +224,32 @@ static void od_dbs_timer(struct work_struct *work)
cpu);
struct dbs_data *dbs_data = dbs_info->cdbs.cur_policy->governor_data;
struct od_dbs_tuners *od_tuners = dbs_data->tuners;
-   int delay, sample_type = core_dbs_info->sample_type;
-   bool eval_load;
+   int delay = 0, sample_type = core_dbs_info->sample_type;
 
mutex_lock(_dbs_info->cdbs.timer_mutex);
-   eval_load = need_load_eval(_dbs_info->cdbs,
-   od_tuners->sampling_rate);
+   if (!need_load_eval(_dbs_info->cdbs, od_tuners->sampling_rate))
+   goto max_delay;
 
/* Common NORMAL_SAMPLE setup */
core_dbs_info->sample_type = OD_NORMAL_SAMPLE;
if (sample_type == OD_SUB_SAMPLE) {
delay = core_dbs_info->freq_lo_jiffies;
-   if (eval_load)
-   __cpufreq_driver_target(core_dbs_info->cdbs.cur_policy,
-   core_dbs_info->freq_lo,
-   CPUFREQ_RELATION_H);
+   __cpufreq_driver_target(core_dbs_info->cdbs.cur_policy,
+   core_dbs_info->freq_lo, CPUFREQ_RELATION_H);
} else {
-   if (eval_load)
-   dbs_check_cpu(dbs_data, cpu);
+   dbs_check_cpu(dbs_data, cpu);
if (core_dbs_info->freq_lo) {
/* Setup timer for SUB_SAMPLE */
core_dbs_info->sample_type = OD_SUB_SAMPLE;
delay = core_dbs_info->freq_hi_jiffies;
-   } else {
-   delay = delay_for_sampling_rate(od_tuners->sampling_rate
-   * core_dbs_info->rate_mult);
}
}
 
+max_delay:
+   if (!delay)
+   delay = delay_for_sampling_rate(od_tuners->sampling_rate
+   * core_dbs_info->rate_mult);
+
schedule_delayed_work_on(smp_processor_id(), dw, delay);
mutex_unlock(_dbs_info->cdbs.timer_mutex);
 }
-- 
1.7.12.rc2.18.g61b472e

--
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/2] cpufreq: governors: Avoid unnecessary per cpu timer interrupts

2013-03-03 Thread Viresh Kumar
Following patch has introduced per cpu timers or works for ondemand and
conservative governors.

commit 2abfa876f1117b0ab45f191fb1f82c41b1cbc8fe
Author: Rickard Andersson 
Date:   Thu Dec 27 14:55:38 2012 +

cpufreq: handle SW coordinated CPUs

This causes additional unnecessary interrupts on all cpus when the load is
recently evaluated by any other cpu. i.e. When load is recently evaluated by cpu
x, we don't really need any other cpu to evaluate this load again for the next
sampling_rate time.

Some sort of code is present to avoid that but we are still getting timer
interrupts for all cpus. A good way of avoiding this would be to modify delays
for all cpus (policy->cpus) whenever any cpu has evaluated load.

This patch does this change and some related code cleanup.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq_conservative.c |  8 ---
 drivers/cpufreq/cpufreq_governor.c | 39 --
 drivers/cpufreq/cpufreq_governor.h |  2 ++
 drivers/cpufreq/cpufreq_ondemand.c | 12 ++-
 4 files changed, 42 insertions(+), 19 deletions(-)

diff --git a/drivers/cpufreq/cpufreq_conservative.c 
b/drivers/cpufreq/cpufreq_conservative.c
index d86577f..77b60a7 100644
--- a/drivers/cpufreq/cpufreq_conservative.c
+++ b/drivers/cpufreq/cpufreq_conservative.c
@@ -107,7 +107,6 @@ static void cs_check_cpu(int cpu, unsigned int load)
 
 static void cs_dbs_timer(struct work_struct *work)
 {
-   struct delayed_work *dw = to_delayed_work(work);
struct cs_cpu_dbs_info_s *dbs_info = container_of(work,
struct cs_cpu_dbs_info_s, cdbs.work.work);
unsigned int cpu = dbs_info->cdbs.cur_policy->cpu;
@@ -116,12 +115,15 @@ static void cs_dbs_timer(struct work_struct *work)
struct dbs_data *dbs_data = dbs_info->cdbs.cur_policy->governor_data;
struct cs_dbs_tuners *cs_tuners = dbs_data->tuners;
int delay = delay_for_sampling_rate(cs_tuners->sampling_rate);
+   bool modify_all = true;
 
mutex_lock(_dbs_info->cdbs.timer_mutex);
-   if (need_load_eval(_dbs_info->cdbs, cs_tuners->sampling_rate))
+   if (!need_load_eval(_dbs_info->cdbs, cs_tuners->sampling_rate))
+   modify_all = false;
+   else
dbs_check_cpu(dbs_data, cpu);
 
-   schedule_delayed_work_on(smp_processor_id(), dw, delay);
+   gov_queue_work(dbs_data, dbs_info->cdbs.cur_policy, delay, modify_all);
mutex_unlock(_dbs_info->cdbs.timer_mutex);
 }
 
diff --git a/drivers/cpufreq/cpufreq_governor.c 
b/drivers/cpufreq/cpufreq_governor.c
index 7722505..f592f71 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -162,20 +162,38 @@ void dbs_check_cpu(struct dbs_data *dbs_data, int cpu)
 }
 EXPORT_SYMBOL_GPL(dbs_check_cpu);
 
-static inline void dbs_timer_init(struct dbs_data *dbs_data, int cpu,
- unsigned int sampling_rate)
+static inline void __gov_queue_work(int cpu, struct dbs_data *dbs_data,
+   unsigned int delay)
 {
-   int delay = delay_for_sampling_rate(sampling_rate);
struct cpu_dbs_common_info *cdbs = dbs_data->cdata->get_cpu_cdbs(cpu);
 
-   schedule_delayed_work_on(cpu, >work, delay);
+   mod_delayed_work_on(cpu, system_wq, >work, delay);
 }
 
-static inline void dbs_timer_exit(struct dbs_data *dbs_data, int cpu)
+void gov_queue_work(struct dbs_data *dbs_data, struct cpufreq_policy *policy,
+   unsigned int delay, bool all_cpus)
 {
-   struct cpu_dbs_common_info *cdbs = dbs_data->cdata->get_cpu_cdbs(cpu);
+   int i;
+
+   if (!all_cpus) {
+   __gov_queue_work(smp_processor_id(), dbs_data, delay);
+   } else {
+   for_each_cpu(i, policy->cpus)
+   __gov_queue_work(i, dbs_data, delay);
+   }
+}
+EXPORT_SYMBOL_GPL(gov_queue_work);
+
+static inline void gov_cancel_work(struct dbs_data *dbs_data,
+   struct cpufreq_policy *policy)
+{
+   struct cpu_dbs_common_info *cdbs;
+   int i;
 
-   cancel_delayed_work_sync(>work);
+   for_each_cpu(i, policy->cpus) {
+   cdbs = dbs_data->cdata->get_cpu_cdbs(i);
+   cancel_delayed_work_sync(>work);
+   }
 }
 
 /* Will return if we need to evaluate cpu load again or not */
@@ -330,16 +348,15 @@ int cpufreq_governor_dbs(struct cpufreq_policy *policy,
/* Initiate timer time stamp */
cpu_cdbs->time_stamp = ktime_get();
 
-   for_each_cpu(j, policy->cpus)
-   dbs_timer_init(dbs_data, j, sampling_rate);
+   gov_queue_work(dbs_data, policy,
+   delay_for_sampling_rate(sampling_rate), true);
break;
 
case CPUFREQ_GOV_STOP:
if (dbs_data->cdata->governor == GOV_CONSERVATIVE)
cs_dbs_info->enable = 0;
 
-   for_each_cpu(j, 

[PATCH V2 0/2] cpufreq: governors: Avoid unnecessary per cpu timer interrupts

2013-03-03 Thread Viresh Kumar
Following patch has introduced per cpu timers or works for ondemand and
conservative governors.

commit 2abfa876f1117b0ab45f191fb1f82c41b1cbc8fe
Author: Rickard Andersson 
Date:   Thu Dec 27 14:55:38 2012 +

cpufreq: handle SW coordinated CPUs

This causes additional unnecessary interrupts on all cpus when the load is
recently evaluated by any other cpu. i.e. When load is recently evaluated by cpu
x, we don't really need any other cpu to evaluate this load again for the next
sampling_rate time.

Some sort of code is present to avoid that but we are still getting timer
interrupts for all cpus. A good way of avoiding this would be to modify delays
for all cpus (policy->cpus) whenever any cpu has evaluated load.

This patchset tries to fix this issue.

These patches are applied here:

http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=shortlog;h=refs/heads/for-3.10

V1->V2:
- Dropped Workqueue modifications and use system_wq directly.

Viresh Kumar (2):
  cpufreq: ondemand: Don't update sample_type if we don't evaluate load
again
  cpufreq: governors: Avoid unnecessary per cpu timer interrupts

 drivers/cpufreq/cpufreq_conservative.c |  8 ---
 drivers/cpufreq/cpufreq_governor.c | 39 --
 drivers/cpufreq/cpufreq_governor.h |  2 ++
 drivers/cpufreq/cpufreq_ondemand.c | 34 ++---
 4 files changed, 52 insertions(+), 31 deletions(-)

-- 
1.7.12.rc2.18.g61b472e

--
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: [ 093/153] ALSA: hda - hdmi: Make jacks phantom, if theyre not detectable

2013-03-03 Thread David Henningsson

On 03/04/2013 06:13 AM, Ben Hutchings wrote:

On Mon, 2013-03-04 at 03:38 +, Ben Hutchings wrote:

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

--

From: David Henningsson 

commit 30efd8debd1ef30be342d374f01e993509f5b76b upstream.

Just as for analog codecs, a jack that isn't suitable for detection
(in this case, NO_PRESENCE was set) should be a phantom Jack
instead of a normal one.

Thanks to Raymond Yau for spotting.

BugLink: https://bugs.launchpad.net/bugs/961286
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=903869
Signed-off-by: David Henningsson 
Signed-off-by: Takashi Iwai 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings 


David, do I need to change this further for 3.2.y?


Greg and Ben,

Given some thought, the definition of is_jack_detectable has 
changed/improved over kernels. Therefore I think it's safer not to apply 
the patch at all for kernels earlier than 3.6. Let's revisit this 
decision if there's actually a user demand for this fix.





Ben.


---
  sound/pci/hda/patch_hdmi.c |3 +++
  1 file changed, 3 insertions(+)

--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -1228,6 +1228,9 @@ static int generic_hdmi_build_jack(struc
int pcmdev = spec->pcm_rec[pin_idx].device;

snprintf(hdmi_str, sizeof(hdmi_str), "HDMI/DP,pcm=%d", pcmdev);
+   if (!is_jack_detectable(codec, per_pin->pin_nid))
+   strncat(hdmi_str, " Phantom",
+   sizeof(hdmi_str) - strlen(hdmi_str) - 1);

err = snd_hda_input_jack_add(codec, per_pin->pin_nid,
 SND_JACK_VIDEOOUT, pcmdev > 0 ? hdmi_str : NULL);


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







--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
--
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] leds-ot200: Fix misbehavior caused by wrong bit masks

2013-03-03 Thread Christian Gmeiner
ping
--
Christian Gmeiner, MSc


2013/2/23 Christian Gmeiner :
> 2013/2/15 Bryan Wu :
>> On Wed, Feb 13, 2013 at 7:58 AM, Christian Gmeiner
>>  wrote:
>>> During the development of this driver an in-house register
>>> documentation was used. The last weeks some integration tests
>>> were done and this problem was found. It turned out that
>>> the released register documentation is wrong.
>>>
>>> The fix is very simple: shift all masks by one.
>>>
>>> Our customers can control LEDs from userspace via Java,
>>> C++ or what every. They have running/working applications where
>>> they want to control led_3 but led_2 get's used.
>>> I got a bug report in our in-house bug tracker so it would be
>>> great to fix this upstream.
>>>
>>> Signed-off-by: Christian Gmeiner 
>>
>> Thanks, Christian.
>>
>> And Andrew, are you going to take care of this patch? Or I will merge this.
>>
>
> Whats the current state of the patch? Hope we can get it into 3.9 :)
>
> --
> Christian Gmeiner, MSc
--
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 0/5] net: low latency Ethernet device polling

2013-03-03 Thread Cong Wang

On 02/28/2013 01:55 AM, Eliezer Tamir wrote:


Open issues:
1. Find a way to avoid the need to change the sk and skb structs.
One big disadvantage of how we do this right now is that when a device is
removed, it's hard to prevent it from getting polled by a socket
which holds a stale reference.

2. How do we decide which sockets are eligible to do busy polling?
Do we add a socket option to control this?
How do we provide sane defaults while allowing flexibility and performance?

3. Andi Kleen and HPA pointed out that using get_cycles() is not portable.

4. How and where do we call ndo_ll_poll from the socket code?
One good place seems to be wherever the kernel puts the process to sleep,
waiting for more data, but this makes doing something intelligent about
poll (the system call) hard. From the perspective of how ndo_ll_poll
itself is implemented this does not seem to matter.

5. I would like to hear suggestions on naming conventions and where
to put the code that for now I have put in include/net/ll_poll.h




A dumb question: is bypassing tcpdump/netfilters/qdisc etc. what we 
always want? Isn't this a security issue?


Thanks!
--
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: fasync race in fs/fcntl.c

2013-03-03 Thread Greg KH
On Sun, Mar 03, 2013 at 10:16:10PM -0800, Russ Dill wrote:
> On Sat, Mar 2, 2013 at 4:09 PM, Russ Dill  wrote:
> > On Sat, Mar 2, 2013 at 11:49 AM, Al Viro  wrote:
> >> On Sat, Mar 02, 2013 at 03:00:28AM -0800, Russ Dill wrote:
> >>> I'm seeing a race in fs/fcntl.c. I'm not sure exactly how the race is
> >>> occurring, but the following is my best guess. A kernel log is
> >>> attached.
> >>
> >> [snip the analysis - it's a different lock anyway]
> >>
> >> The traces below are essentially sys_execve() getting to 
> >> get_random_bytes(),
> >> to kill_fasync(), to send_sigio(), which spins on tasklist_lock.
> >>
> >> Could you rebuild it with lockdep enabled and try to reproduce that?
> >> I very much doubt that this execve() is a part of deadlock - it's
> >> getting caught on one, but it shouldn't be holding any locks that
> >> nest inside tasklist_lock at that point, so even it hadn't been there,
> >> the process holding tasklist_lock probably wouldn't have progressed any
> >> further...
> >
> > ok, I did screw up the analysis quite badly, luckily, lockdep got it right 
> > away.
> >
> 
> So lockdep gives some clues, but seems a bit confused, so here's what 
> happened.
> 
> mix_pool_bytes /* takes nonblocking_pool.lock */
> add_device_randomness
> posix_cpu_timers_exit
> __exit_signal
> release_task /* takes write lock on tasklist_lock */
> do_exit
> __module_put_and_exit
> cryptomgr_test
> 
> send_sigio /* takes read lock on tasklist_lock */
> kill_fasync_rcu
> kill_fasync
> account /* takes nonblocking_pool.lock */
> extract_entropy
> get_random_bytes
> create_elf_tables
> load_elf_binary
> load_elf_library
> search_binary_handler
> 
> This would mark the culprit as 613370549 'random: Mix cputime from
> each thread that exits to the pool'.  So long as I'm not as crazy on
> the last analysis as this one, may I suggest a revert of this commit
> for 3.8.3?

I'll revert it, but shouldn't we fix this properly upstream in Linus's
tree as well?  I'd rather take the fix than a revert so that we don't
have a problem that no one remembers to fix until 3.9-final is out.

thanks,

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


[PATCH V3 3/4] cpufreq: Get rid of "struct global_attr"

2013-03-03 Thread Viresh Kumar
We don't need to keep two structures for file attributes, global_attr and
freq_attr. Lets use freq_attr only for cpufreq core and drivers.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/acpi-cpufreq.c |  9 -
 drivers/cpufreq/intel_pstate.c | 20 ++--
 include/linux/cpufreq.h| 16 
 3 files changed, 14 insertions(+), 31 deletions(-)

diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 937bc28..14219c3 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -160,19 +160,18 @@ static ssize_t _store_boost(const char *buf, size_t count)
return count;
 }
 
-static ssize_t store_global_boost(struct kobject *kobj, struct attribute *attr,
- const char *buf, size_t count)
+static ssize_t store_global_boost(struct cpufreq_policy *policy,
+   const char *buf, size_t count)
 {
return _store_boost(buf, count);
 }
 
-static ssize_t show_global_boost(struct kobject *kobj,
-struct attribute *attr, char *buf)
+static ssize_t show_global_boost(struct cpufreq_policy *policy, char *buf)
 {
return sprintf(buf, "%u\n", boost_enabled);
 }
 
-static struct global_attr global_boost = __ATTR(boost, 0644,
+static struct freq_attr global_boost = __ATTR(boost, 0644,
show_global_boost,
store_global_boost);
 
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 096fde0..49846b9 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -275,13 +275,13 @@ static void intel_pstate_debug_expose_params(void)
 /** sysfs begin /
 #define show_one(file_name, object)\
static ssize_t show_##file_name \
-   (struct kobject *kobj, struct attribute *attr, char *buf)   \
+   (struct cpufreq_policy *policy, char *buf)  \
{   \
return sprintf(buf, "%u\n", limits.object); \
}
 
-static ssize_t store_no_turbo(struct kobject *a, struct attribute *b,
-   const char *buf, size_t count)
+static ssize_t store_no_turbo(struct cpufreq_policy *policy, const char *buf,
+   size_t count)
 {
unsigned int input;
int ret;
@@ -293,8 +293,8 @@ static ssize_t store_no_turbo(struct kobject *a, struct 
attribute *b,
return count;
 }
 
-static ssize_t store_max_perf_pct(struct kobject *a, struct attribute *b,
-   const char *buf, size_t count)
+static ssize_t store_max_perf_pct(struct cpufreq_policy *policy,
+   const char *buf, size_t count)
 {
unsigned int input;
int ret;
@@ -307,8 +307,8 @@ static ssize_t store_max_perf_pct(struct kobject *a, struct 
attribute *b,
return count;
 }
 
-static ssize_t store_min_perf_pct(struct kobject *a, struct attribute *b,
-   const char *buf, size_t count)
+static ssize_t store_min_perf_pct(struct cpufreq_policy *policy,
+   const char *buf, size_t count)
 {
unsigned int input;
int ret;
@@ -325,9 +325,9 @@ show_one(no_turbo, no_turbo);
 show_one(max_perf_pct, max_perf_pct);
 show_one(min_perf_pct, min_perf_pct);
 
-define_one_global_rw(no_turbo);
-define_one_global_rw(max_perf_pct);
-define_one_global_rw(min_perf_pct);
+cpufreq_freq_attr_rw(no_turbo);
+cpufreq_freq_attr_rw(max_perf_pct);
+cpufreq_freq_attr_rw(min_perf_pct);
 
 static struct attribute *intel_pstate_attributes[] = {
_turbo.attr,
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index c5ac9a5..6e1abd2 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -320,22 +320,6 @@ __ATTR(_name, _perm, show_##_name, NULL)
 static struct freq_attr _name =\
 __ATTR(_name, 0644, show_##_name, store_##_name)
 
-struct global_attr {
-   struct attribute attr;
-   ssize_t (*show)(struct kobject *kobj,
-   struct attribute *attr, char *buf);
-   ssize_t (*store)(struct kobject *a, struct attribute *b,
-const char *c, size_t count);
-};
-
-#define define_one_global_ro(_name)\
-static struct global_attr _name =  \
-__ATTR(_name, 0444, show_##_name, NULL)
-
-#define define_one_global_rw(_name)\
-static struct global_attr _name =  \
-__ATTR(_name, 0644, show_##_name, store_##_name)
-
 struct cpufreq_policy *cpufreq_cpu_get(unsigned int cpu);
 void cpufreq_cpu_put(struct cpufreq_policy *data);
 const char *cpufreq_get_current_driver(void);
-- 
1.7.12.rc2.18.g61b472e

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" 

[PATCH V3 4/4] cpufreq: Add Kconfig option to enable/disable have_multiple_policies

2013-03-03 Thread Viresh Kumar
have_multiple_policies is required by platforms having multiple clock-domains
for cpus, i.e. supporting multiple policies for cpus. This patch adds in a
Kconfig option for enabling execution of this code.

Reported-by: Borislav Petkov 
Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/Kconfig | 3 +++
 include/linux/cpufreq.h | 4 
 2 files changed, 7 insertions(+)

diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index cbcb21e..e6e6939 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -23,6 +23,9 @@ config CPU_FREQ_TABLE
 config CPU_FREQ_GOV_COMMON
bool
 
+config CPU_FREQ_HAVE_MULTIPLE_POLICIES
+   bool
+
 config CPU_FREQ_STAT
tristate "CPU frequency translation statistics"
select CPU_FREQ_TABLE
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 6e1abd2..a092fcb 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -107,11 +107,13 @@ struct cpufreq_policy {
unsigned intpolicy; /* see above */
struct cpufreq_governor *governor; /* see below */
void*governor_data;
+#ifdef CONFIG_CPU_FREQ_HAVE_MULTIPLE_POLICIES
/* This should be set by init() of platforms having multiple
 * clock-domains, i.e.  supporting multiple policies. With this sysfs
 * directories of governor would be created in cpu/cpu/cpufreq/
 * directory */
boolhave_multiple_policies;
+#endif
 
struct work_struct  update; /* if update_policy() needs to be
 * called, but you're in IRQ context */
@@ -142,9 +144,11 @@ static inline bool policy_is_shared(struct cpufreq_policy 
*policy)
 static inline struct kobject *
 get_governor_parent_kobj(struct cpufreq_policy *policy)
 {
+#ifdef CONFIG_CPU_FREQ_HAVE_MULTIPLE_POLICIES
if (policy->have_multiple_policies)
return >kobj;
else
+#endif
return cpufreq_global_kobject;
 }
 
-- 
1.7.12.rc2.18.g61b472e

--
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 V3 2/4] cpufreq: governor: Implement per policy instances of governors

2013-03-03 Thread Viresh Kumar
Currently, there can't be multiple instances of single governor_type. If we have
a multi-package system, where we have multiple instances of struct policy (per
package), we can't have multiple instances of same governor. i.e. We can't have
multiple instances of ondemand governor for multiple packages.

Governors directory in sysfs is created at /sys/devices/system/cpu/cpufreq/
governor-name/. Which again reflects that there can be only one instance of a
governor_type in the system.

This is a bottleneck for multicluster system, where we want different packages
to use same governor type, but with different tunables.

This patch uses the infrastructure provided by earlier patch and implements
init/exit routines for ondemand and conservative governors.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq.c  |   6 -
 drivers/cpufreq/cpufreq_conservative.c | 148 +-
 drivers/cpufreq/cpufreq_governor.c | 159 ++--
 drivers/cpufreq/cpufreq_governor.h |  43 +--
 drivers/cpufreq/cpufreq_ondemand.c | 216 +++--
 include/linux/cpufreq.h|  15 ++-
 6 files changed, 352 insertions(+), 235 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 7d59688..75b64e2 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1546,11 +1546,6 @@ static int __cpufreq_governor(struct cpufreq_policy 
*policy,
policy->cpu, event);
ret = policy->governor->governor(policy, event);
 
-   if (event == CPUFREQ_GOV_START)
-   policy->governor->initialized++;
-   else if (event == CPUFREQ_GOV_STOP)
-   policy->governor->initialized--;
-
/* we keep one module reference alive for
each CPU governed by this CPU */
if ((event != CPUFREQ_GOV_START) || ret)
@@ -1574,7 +1569,6 @@ int cpufreq_register_governor(struct cpufreq_governor 
*governor)
 
mutex_lock(_governor_mutex);
 
-   governor->initialized = 0;
err = -EBUSY;
if (__find_governor(governor->name) == NULL) {
err = 0;
diff --git a/drivers/cpufreq/cpufreq_conservative.c 
b/drivers/cpufreq/cpufreq_conservative.c
index 4fd0006..d86577f 100644
--- a/drivers/cpufreq/cpufreq_conservative.c
+++ b/drivers/cpufreq/cpufreq_conservative.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -31,17 +32,8 @@
 #define DEF_SAMPLING_DOWN_FACTOR   (1)
 #define MAX_SAMPLING_DOWN_FACTOR   (10)
 
-static struct dbs_data cs_dbs_data;
 static DEFINE_PER_CPU(struct cs_cpu_dbs_info_s, cs_cpu_dbs_info);
 
-static struct cs_dbs_tuners cs_tuners = {
-   .up_threshold = DEF_FREQUENCY_UP_THRESHOLD,
-   .down_threshold = DEF_FREQUENCY_DOWN_THRESHOLD,
-   .sampling_down_factor = DEF_SAMPLING_DOWN_FACTOR,
-   .ignore_nice = 0,
-   .freq_step = 5,
-};
-
 /*
  * Every sampling_rate, we check, if current idle time is less than 20%
  * (default), then we try to increase frequency Every sampling_rate *
@@ -55,24 +47,26 @@ static void cs_check_cpu(int cpu, unsigned int load)
 {
struct cs_cpu_dbs_info_s *dbs_info = _cpu(cs_cpu_dbs_info, cpu);
struct cpufreq_policy *policy = dbs_info->cdbs.cur_policy;
+   struct dbs_data *dbs_data = policy->governor_data;
+   struct cs_dbs_tuners *cs_tuners = dbs_data->tuners;
unsigned int freq_target;
 
/*
 * break out if we 'cannot' reduce the speed as the user might
 * want freq_step to be zero
 */
-   if (cs_tuners.freq_step == 0)
+   if (cs_tuners->freq_step == 0)
return;
 
/* Check for frequency increase */
-   if (load > cs_tuners.up_threshold) {
+   if (load > cs_tuners->up_threshold) {
dbs_info->down_skip = 0;
 
/* if we are already at full speed then break out early */
if (dbs_info->requested_freq == policy->max)
return;
 
-   freq_target = (cs_tuners.freq_step * policy->max) / 100;
+   freq_target = (cs_tuners->freq_step * policy->max) / 100;
 
/* max freq cannot be less than 100. But who knows */
if (unlikely(freq_target == 0))
@@ -92,8 +86,8 @@ static void cs_check_cpu(int cpu, unsigned int load)
 * support the current CPU usage without triggering the up policy. To be
 * safe, we focus 10 points under the threshold.
 */
-   if (load < (cs_tuners.down_threshold - 10)) {
-   freq_target = (cs_tuners.freq_step * policy->max) / 100;
+   if (load < (cs_tuners->down_threshold - 10)) {
+   freq_target = (cs_tuners->freq_step * policy->max) / 100;
 
dbs_info->requested_freq -= freq_target;
if (dbs_info->requested_freq < policy->min)
@@ -119,11 +113,13 @@ static void 

[PATCH V3 1/4] cpufreq: Add per policy governor-init/exit infrastructure

2013-03-03 Thread Viresh Kumar
Currently, there can't be multiple instances of single governor_type. If we have
a multi-package system, where we have multiple instances of struct policy (per
package), we can't have multiple instances of same governor. i.e. We can't have
multiple instances of ondemand governor for multiple packages.

Governors directory in sysfs is created at /sys/devices/system/cpu/cpufreq/
governor-name/. Which again reflects that there can be only one instance of a
governor_type in the system.

This is a bottleneck for multicluster system, where we want different packages
to use same governor type, but with different tunables.

This patch is inclined towards providing this infrastructure. Because we are
required to allocate governor's resources dynamically now, we must do it at
policy creation and end. And so got CPUFREQ_GOV_POLICY_INIT/EXIT.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq.c | 21 ++---
 include/linux/cpufreq.h   |  9 ++---
 2 files changed, 24 insertions(+), 6 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index b02824d..7d59688 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1070,6 +1070,8 @@ static int __cpufreq_remove_dev(struct device *dev, 
struct subsys_interface *sif
 
/* If cpu is last user of policy, free policy */
if (cpus == 1) {
+   __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT);
+
lock_policy_rwsem_read(cpu);
kobj = >kobj;
cmp = >kobj_unregister;
@@ -1651,7 +1653,7 @@ EXPORT_SYMBOL(cpufreq_get_policy);
 static int __cpufreq_set_policy(struct cpufreq_policy *data,
struct cpufreq_policy *policy)
 {
-   int ret = 0;
+   int ret = 0, failed = 1;
 
pr_debug("setting new policy for CPU %u: %u - %u kHz\n", policy->cpu,
policy->min, policy->max);
@@ -1705,18 +1707,31 @@ static int __cpufreq_set_policy(struct cpufreq_policy 
*data,
pr_debug("governor switch\n");
 
/* end old governor */
-   if (data->governor)
+   if (data->governor) {
__cpufreq_governor(data, CPUFREQ_GOV_STOP);
+   __cpufreq_governor(data,
+   CPUFREQ_GOV_POLICY_EXIT);
+   }
 
/* start new governor */
data->governor = policy->governor;
-   if (__cpufreq_governor(data, CPUFREQ_GOV_START)) {
+   if (!__cpufreq_governor(data, CPUFREQ_GOV_POLICY_INIT)) 
{
+   if (!__cpufreq_governor(data, 
CPUFREQ_GOV_START))
+   failed = 0;
+   else
+   __cpufreq_governor(data,
+   
CPUFREQ_GOV_POLICY_EXIT);
+   }
+
+   if (failed) {
/* new governor failed, so re-start old one */
pr_debug("starting governor %s failed\n",
data->governor->name);
if (old_gov) {
data->governor = old_gov;
__cpufreq_governor(data,
+   
CPUFREQ_GOV_POLICY_INIT);
+   __cpufreq_governor(data,
   CPUFREQ_GOV_START);
}
ret = -EINVAL;
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index a22944c..b7393b5 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -106,6 +106,7 @@ struct cpufreq_policy {
 * governors are used */
unsigned intpolicy; /* see above */
struct cpufreq_governor *governor; /* see below */
+   void*governor_data;
 
struct work_struct  update; /* if update_policy() needs to be
 * called, but you're in IRQ context */
@@ -178,9 +179,11 @@ static inline unsigned long cpufreq_scale(unsigned long 
old, u_int div, u_int mu
  *  CPUFREQ GOVERNORS*
  */
 
-#define CPUFREQ_GOV_START  1
-#define CPUFREQ_GOV_STOP   2
-#define CPUFREQ_GOV_LIMITS 3
+#define CPUFREQ_GOV_START  1
+#define CPUFREQ_GOV_STOP   2
+#define CPUFREQ_GOV_LIMITS 3
+#define CPUFREQ_GOV_POLICY_INIT4
+#define CPUFREQ_GOV_POLICY_EXIT5
 
 struct cpufreq_governor {
charname[CPUFREQ_NAME_LEN];
-- 

[PATCH V3 0/4] CPUFreq: Implement per policy instances of governors

2013-03-03 Thread Viresh Kumar
This is targetted for 3.10-rc1 or linux-next just after the merge window.

All patches are pushed here for others to apply:
http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=shortlog;h=refs/heads/for-3.10

Currently, there can't be multiple instances of single governor_type. If we have
a multi-package system, where we have multiple instances of struct policy (per
package), we can't have multiple instances of same governor. i.e. We can't have
multiple instances of ondemand governor for multiple packages.

Governors directory in sysfs is created at /sys/devices/system/cpu/cpufreq/
governor-name/. Which again reflects that there can be only one instance of a
governor_type in the system.

This is a bottleneck for multicluster system, where we want different packages
to use same governor type, but with different tunables.

This patchset is inclined towards fixing this issue. Now we will create
governors directory in cpu/cpu*/cpufreq/ for platforms which have multiple
struct policy alive at any moment. For others the interface is kept same:
cpu/cpufreq/.

@Rafael: Clearly, I don't want to have following patch: "cpufreq: Add Kconfig
option to enable/disable have_multiple_policies" and added it because of comment
from Borislov against which nobody else replied :)

So, please drop it if you agree over my comments with earlier version.

V2->V3:
- Fixed value of CPUFREQ_GOV_POLICY_EXIT in the correct patch
- Drop indentation fixes from intel_pstate.c

V1->V2:
- Few patches from V1 are already picked up by Rafael for 3.9-rc1
- Last two patches are new
- Added dbs_data->exit() routines to free up memory used for struct tuners.

Viresh Kumar (4):
  cpufreq: Add per policy governor-init/exit infrastructure
  cpufreq: governor: Implement per policy instances of governors
  cpufreq: Get rid of "struct global_attr"
  cpufreq: Add Kconfig option to enable/disable have_multiple_policies

 drivers/cpufreq/Kconfig|   3 +
 drivers/cpufreq/acpi-cpufreq.c |   9 +-
 drivers/cpufreq/cpufreq.c  |  27 +++--
 drivers/cpufreq/cpufreq_conservative.c | 148 +-
 drivers/cpufreq/cpufreq_governor.c | 159 ++--
 drivers/cpufreq/cpufreq_governor.h |  43 +--
 drivers/cpufreq/cpufreq_ondemand.c | 216 +++--
 drivers/cpufreq/intel_pstate.c |  20 +--
 include/linux/cpufreq.h|  44 ---
 9 files changed, 397 insertions(+), 272 deletions(-)

-- 
1.7.12.rc2.18.g61b472e

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


3.9-rc1 boot warning at drivers/gpu/drm/i915/intel_dp.c:1121 ironlake_panel_vdd_off_sync+0xef/0x100 [i915]()

2013-03-03 Thread Greg KH
Hi Daniel,

On 3.9-rc1, I get the following warning on my MacBook Pro Retina.

Graphics still seem to work ok, but I think that's because it's really
using the nouveau driver instead of the intel driver (so David says).

Anything I can do to test to try to fix this?

thanks,

greg k-h



[6.000101] Console: switching to colour frame buffer device 360x112
[6.006662] nouveau :01:00.0: fb0: nouveaufb frame buffer device
[6.006664] nouveau :01:00.0: registered panic notifier
[6.006668] [drm] Initialized nouveau 1.1.0 20120801 for :01:00.0 on 
minor 0
[6.006756] snd_hda_intel :01:00.1: enabling device ( -> 0002)
[6.006838] hda_intel: Disabling MSI
[6.006868] hda-intel :01:00.1: Handle VGA-switcheroo audio client
[6.007848] [drm] Memory usable by graphics device = 2048M
[6.007867] i915 :00:02.0: setting latency timer to 64
[6.031217] usb 2-1.8.1.2: USB disconnect, device number 7
[6.043198] i915 :00:02.0: irq 49 for MSI/MSI-X
[6.043204] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[6.043222] [drm] Driver supports precise vblank timestamp query.
[6.043228] i915 :00:02.0: Invalid ROM contents
[6.043232] [drm] failed to find VBIOS tables
[6.043271] vga_switcheroo: enabled
[6.043307] vgaarb: device changed decodes: 
PCI::01:00.0,olddecodes=io+mem,decodes=none:owns=none
[6.043314] vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=io+mem,decodes=none:owns=io+mem
[6.070805] [drm] failed to retrieve link info, disabling eDP
[6.070840] [ cut here ]
[6.070870] WARNING: at drivers/gpu/drm/i915/intel_dp.c:1121 
ironlake_panel_vdd_off_sync+0xef/0x100 [i915]()
[6.070878] Hardware name: MacBookPro10,1
[6.070882] Modules linked in: btusb bluetooth nls_cp437 vfat fat arc4 b43 
ssb pcmcia pcmcia_core mac80211 cfg80211 rfkill joydev iTCO_wdt bcm5974 
iTCO_vendor_support applesmc input_polldev snd_hda_codec_cirrus coretemp 
kvm_intel kvm acpi_cpufreq crc32c_intel mperf ghash_clmulni_intel evdev 
aesni_intel xts aes_x86_64 lrw gf128mul ablk_helper cryptd microcode pcspkr 
i2c_i801(+) apple_gmux snd_hda_intel(+) i915(+) sdhci_pci lpc_ich snd_hda_codec 
bcma nouveau sdhci mfd_core snd_hwdep mmc_core mxm_wmi wmi ttm intel_agp 
snd_pcm intel_gtt i2c_algo_bit drm_kms_helper snd_page_alloc snd_timer snd 
soundcore drm video battery apple_bl mei processor ac button
[6.071025] Pid: 123, comm: systemd-udevd Tainted: GW3.9.0-rc1 
#100
[6.071031] Call Trace:
[6.071038]  [] warn_slowpath_common+0x7f/0xc0
[6.071045]  [] warn_slowpath_null+0x1a/0x20
[6.071063]  [] ironlake_panel_vdd_off_sync+0xef/0x100 
[i915]
[6.071079]  [] intel_dp_encoder_destroy+0x64/0x70 [i915]
[6.071095]  [] intel_dp_init_connector+0xa76/0xa90 [i915]
[6.071107]  [] ? drm_modeset_unlock_all+0x52/0x60 [drm]
[6.071122]  [] intel_dp_init+0x106/0x140 [i915]
[6.071138]  [] intel_modeset_init+0xbf9/0xea0 [i915]
[6.071154]  [] i915_driver_load+0xb59/0xde0 [i915]
[6.071176]  [] drm_get_pci_dev+0x186/0x2c0 [drm]
[6.071192]  [] i915_pci_probe+0x3c/0x90 [i915]
[6.071201]  [] local_pci_probe+0x4b/0x80
[6.071211]  [] pci_device_probe+0x111/0x120
[6.071219]  [] driver_probe_device+0x7b/0x240
[6.071225]  [] __driver_attach+0xab/0xb0
[6.071232]  [] ? driver_probe_device+0x240/0x240
[6.071239]  [] bus_for_each_dev+0x5d/0xa0
[6.071246]  [] driver_attach+0x1e/0x20
[6.071253]  [] bus_add_driver+0x10e/0x270
[6.071260]  [] ? 0xa0462fff
[6.071267]  [] driver_register+0x77/0x170
[6.071273]  [] ? tracepoint_module_notify+0x117/0x220
[6.071281]  [] ? 0xa0462fff
[6.071287]  [] __pci_register_driver+0x4b/0x50
[6.071297]  [] drm_pci_init+0x11a/0x130 [drm]
[6.071304]  [] ? 0xa0462fff
[6.071319]  [] i915_init+0x66/0x68 [i915]
[6.071325]  [] do_one_initcall+0x12a/0x180
[6.071334]  [] load_module+0x1a47/0x24b0
[6.071340]  [] ? sys_getegid16+0x50/0x50
[6.071349]  [] sys_init_module+0xa6/0xd0
[6.071356]  [] system_call_fastpath+0x1a/0x1f
[6.071362] ---[ end trace 138aae7ee5fa912d ]---
[6.370967] input: HDA NVidia HDMI/DP,pcm=8 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input10
[6.371243] input: HDA NVidia HDMI/DP,pcm=7 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input11
[6.371504] input: HDA NVidia HDMI/DP,pcm=3 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input12
[6.644053] [drm] GMBUS [i915 gmbus vga] timed out, falling back to bit 
banging on pin 2
[6.657295] i915 :00:02.0: No connectors reported connected with modes
[6.657302] [drm] Cannot find any crtc or sizes - going 1024x768
[6.659683] i915 :00:02.0: fb1: inteldrmfb frame buffer device
[6.660364] [Firmware Bug]: ACPI(GFX0) defines _DOD but not _DOS
[6.661371] ACPI: Video Device [GFX0] (multi-head: yes  

[PATCH] backlight: atmel-pwm-bl: use module_platform_driver_probe()

2013-03-03 Thread Jingoo Han
This patch uses module_platform_driver_probe() macro which makes
the code smaller and simpler.

Signed-off-by: Jingoo Han 
---
 drivers/video/backlight/atmel-pwm-bl.c |   12 +---
 1 files changed, 1 insertions(+), 11 deletions(-)

diff --git a/drivers/video/backlight/atmel-pwm-bl.c 
b/drivers/video/backlight/atmel-pwm-bl.c
index de5e5e7..20b330d 100644
--- a/drivers/video/backlight/atmel-pwm-bl.c
+++ b/drivers/video/backlight/atmel-pwm-bl.c
@@ -225,17 +225,7 @@ static struct platform_driver atmel_pwm_bl_driver = {
.remove = __exit_p(atmel_pwm_bl_remove),
 };
 
-static int __init atmel_pwm_bl_init(void)
-{
-   return platform_driver_probe(_pwm_bl_driver, atmel_pwm_bl_probe);
-}
-module_init(atmel_pwm_bl_init);
-
-static void __exit atmel_pwm_bl_exit(void)
-{
-   platform_driver_unregister(_pwm_bl_driver);
-}
-module_exit(atmel_pwm_bl_exit);
+module_platform_driver_probe(atmel_pwm_bl_driver, atmel_pwm_bl_probe);
 
 MODULE_AUTHOR("Hans-Christian egtvedt ");
 MODULE_DESCRIPTION("Atmel PWM backlight driver");
-- 
1.7.2.5


--
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/5] net: implement support for low latency socket polling

2013-03-03 Thread Cong Wang
On Wed, 27 Feb 2013 at 17:55 GMT, Eliezer Tamir 
 wrote:
> +static inline void skb_mark_ll(struct napi_struct *napi, struct sk_buff *skb)
> +{
> + skb->dev_ref = napi;
> +}
> +
> +static inline void sk_mark_ll(struct sock *sk, struct sk_buff *skb)
> +{
> + if (skb->dev_ref)
> + sk->dev_ref = skb->dev_ref;
> +
> +}


It is actually easier to read the code without making them be
functions...


--
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 v7 0/7] fat (exportfs): support stale_rw and nostale_ro mount option.

2013-03-03 Thread Namjae Jeon
2013/3/2, OGAWA Hirofumi :
> Namjae Jeon  writes:
>
>> From: Namjae Jeon 
>>
>> This patch set eliminates the client side ESTALE errors when a FAT
>> partition
>> exported over NFS has it's dentries evicted from the cache. The idea is
>> to
>> find the on-disk location_'i_pos' of the dirent of the inode that has
>> been
>> evicted and use it to rebuild the inode.
>
> Looks like users can start to test this.
>
> Acked-by: OGAWA Hirofumi 
>
> Thanks.
Okay, Thanks OGAWA.
I will start to work write support on fat exportfs.

> --
> OGAWA Hirofumi 
>
--
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 v3] CAIF: fix sparse warning for caif_usb

2013-03-03 Thread Silviu-Mihai Popescu
This fixes the following sparse warning:
net/caif/caif_usb.c:84:16: warning: symbol 'cfusbl_create' was not
declared. Should it be static?

Signed-off-by: Silviu-Mihai Popescu 
---
 net/caif/caif_usb.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/caif/caif_usb.c b/net/caif/caif_usb.c
index 3ebc8cb..1c6ded9 100644
--- a/net/caif/caif_usb.c
+++ b/net/caif/caif_usb.c
@@ -81,8 +81,8 @@ static void cfusbl_ctrlcmd(struct cflayer *layr, enum 
caif_ctrlcmd ctrl,
layr->up->ctrlcmd(layr->up, ctrl, layr->id);
 }
 
-struct cflayer *cfusbl_create(int phyid, u8 ethaddr[ETH_ALEN],
-   u8 braddr[ETH_ALEN])
+static struct cflayer *cfusbl_create(int phyid, u8 ethaddr[ETH_ALEN],
+ u8 braddr[ETH_ALEN])
 {
struct cfusbl *this = kmalloc(sizeof(struct cfusbl), GFP_ATOMIC);
 
-- 
1.7.9.5

--
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 RESEND 2/2] clocksource: dbx500-prcmu: comment cleanup

2013-03-03 Thread Linus Walleij
On Thu, Feb 28, 2013 at 11:01 AM, Fabio Baltieri
 wrote:

> Remove references to the deprecated DB5500 platform.
>
> Acked-by: Linus Walleij 
> Signed-off-by: Fabio Baltieri 

I've taken this and the other patch into the ux500 tree,
as per discussion with John changes to these drivers should
go through someone who can test it on the actual hardware.

Linus Walleij
--
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] CAIF: fix sparse warning for caif_usb

2013-03-03 Thread David Miller
From: Silviu-Mihai Popescu 
Date: Mon,  4 Mar 2013 08:52:00 +0200

> This fixes the following sparse warning:
> net/caif/caif_usb.c:84:16: warning: symbol 'cfusbl_create' was not
> declared. Should it be static?
> 
> Signed-off-by: Silviu-Mihai Popescu 
> ---
>  net/caif/caif_usb.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/net/caif/caif_usb.c b/net/caif/caif_usb.c
> index 3ebc8cb..1c6ded9 100644
> --- a/net/caif/caif_usb.c
> +++ b/net/caif/caif_usb.c
> @@ -81,8 +81,8 @@ static void cfusbl_ctrlcmd(struct cflayer *layr, enum 
> caif_ctrlcmd ctrl,
>   layr->up->ctrlcmd(layr->up, ctrl, layr->id);
>  }
>  
> -struct cflayer *cfusbl_create(int phyid, u8 ethaddr[ETH_ALEN],
> - u8 braddr[ETH_ALEN])
> +static struct cflayer *cfusbl_create(int phyid, u8 ethaddr[ETH_ALEN],
> + u8 braddr[ETH_ALEN])

Nope, that indentation isn't correct, is should be:

static struct cflayer *cfusbl_create(int phyid, u8 ethaddr[ETH_ALEN],
 u8 braddr[ETH_ALEN])

Read my email, I said that the first character on the second line
must line up with the first column after the openning parenthesis
of the first line.
--
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] CAIF: fix sparse warning for caif_usb

2013-03-03 Thread Silviu-Mihai Popescu
This fixes the following sparse warning:
net/caif/caif_usb.c:84:16: warning: symbol 'cfusbl_create' was not
declared. Should it be static?

Signed-off-by: Silviu-Mihai Popescu 
---
 net/caif/caif_usb.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/caif/caif_usb.c b/net/caif/caif_usb.c
index 3ebc8cb..1c6ded9 100644
--- a/net/caif/caif_usb.c
+++ b/net/caif/caif_usb.c
@@ -81,8 +81,8 @@ static void cfusbl_ctrlcmd(struct cflayer *layr, enum 
caif_ctrlcmd ctrl,
layr->up->ctrlcmd(layr->up, ctrl, layr->id);
 }
 
-struct cflayer *cfusbl_create(int phyid, u8 ethaddr[ETH_ALEN],
-   u8 braddr[ETH_ALEN])
+static struct cflayer *cfusbl_create(int phyid, u8 ethaddr[ETH_ALEN],
+   u8 braddr[ETH_ALEN])
 {
struct cfusbl *this = kmalloc(sizeof(struct cfusbl), GFP_ATOMIC);
 
-- 
1.7.9.5

--
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] nfsd: try nfsdcld client tracker in containers

2013-03-03 Thread Stanislav Kinsbursky

01.03.2013 17:09, Jeff Layton пишет:

On Fri, 01 Mar 2013 11:24:23 +0300
Stanislav Kinsbursky  wrote:


Currently, UMH and Legacy trackers are disabled in containers.
But existent logic can lookup nfs4_recoverydir in a container, and in this
case will try to init Legacy tracker and skip nfsdcld client tracker.
This actually means, that no client tracker will be started in a container at
all, because Legacy tracker init will return -EINVAL for a container.
So, let's change "-EINVAL" on "-ENOTSUPP" for legacy tracker init call in a
container and in case of this error code, try nfsdcld client tracker instead
of returning a error.

Signed-off-by: Stanislav Kinsbursky 
---
  fs/nfsd/nfs4recover.c |   12 
  1 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/fs/nfsd/nfs4recover.c b/fs/nfsd/nfs4recover.c
index e0ae1cf..8aa069a 100644
--- a/fs/nfsd/nfs4recover.c
+++ b/fs/nfsd/nfs4recover.c
@@ -524,7 +524,7 @@ nfsd4_legacy_tracking_init(struct net *net)
if (net != _net) {
WARN(1, KERN_ERR "NFSD: attempt to initialize legacy client "
"tracking in a container!\n");
-   return -EINVAL;
+   return -ENOTSUPP;
}

status = nfs4_legacy_state_init(net);
@@ -1285,14 +1285,17 @@ nfsd4_client_tracking_init(struct net *net)
/*
 * See if the recoverydir exists and is a directory. If it is,
 * then use the legacy ops.
+* If legacy ops init return -ENOSUPP, then we are in a container and
+* should try nfsdcld client tracking.
 */
nn->client_tracking_ops = _legacy_tracking_ops;
status = kern_path(nfs4_recoverydir(), LOOKUP_FOLLOW, );
if (!status) {
-   status = S_ISDIR(path.dentry->d_inode->i_mode);
+   if (S_ISDIR(path.dentry->d_inode->i_mode))
+   status = nn->client_tracking_ops->init(net);
path_put();
-   if (status)
-   goto do_init;
+   if (status != -ENOTSUPP)
+   goto do_exit;
}

/* Finally, try to use nfsdcld */
@@ -1302,6 +1305,7 @@ nfsd4_client_tracking_init(struct net *net)
"nfsdcltrack.\n");
  do_init:
status = nn->client_tracking_ops->init(net);
+do_exit:
if (status) {
printk(KERN_WARNING "NFSD: Unable to initialize client "
"recovery tracking! (%d)\n", status);



Seems OK as a stopgap fix. We're removing nfsdcld in 3.10 though so
this won't help prospective users of nfsd in a container for
long...particularly since our expectation is that no one has actually
ever deployed nfsdcld.

This is something that really needs to be fixed the right way since a
NFS server that doesn't allow clients to reclaim state after a reboot is
potentially dangerous...

I'm afraid I haven't been following along as closely as I should have
been. What's the rationale for disabling the UMH upcall? Is there no
way to make it so that new processes it spawns are done within the
correct container?



Straight answer is "no, there is no way to do so": UMH threads are spawned in 
"init" context.
But we solve the problem in a slightly different way.

So, here are my ideas about all the trackers (I haven't shared them yet, so I 
do it now):

1) nfsdcld uses SUNRPC pipefs, which is containerised already. So it was very 
easy to containerise it.

2) Legacy tracker uses path. All is great and simple until we imagine two containers with the same root. In this case we have to make sure, that we can start 
only one NFSd with this path (I don't care about user-space problems).
I was thinking about global in-kernel RB tree for all paths. But maybe even a simple global list is enough (not so many NFSd can be started, and it not a 
fast-path to optimise the search over all used paths).


3) UMH lookup and execute binary from current root. This problem just chasing all the containerisation work. So, either UHM logic have to updated (which is not 
trivial or easy to implement and push upstream), or process root have to swapped to the right (container's) one. This, BTW, not that hard, because UMH call 
accept "init" callback, which can be used to swap the root right before do_execve() is called.


What do you, guys, think about all this?

--
Best regards,
Stanislav Kinsbursky
--
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 1/6 v8] iommu/fsl: Store iommu domain information pointer in archdata.

2013-03-03 Thread Sethi Varun-B16395


> -Original Message-
> From: Yoder Stuart-B08248
> Sent: Friday, March 01, 2013 9:52 PM
> To: Alexey Kardashevskiy; Sethi Varun-B16395
> Cc: Kumar Gala; Benjamin Herrenschmidt; io...@lists.linux-foundation.org;
> linuxppc-...@lists.ozlabs.org list; linux-kernel@vger.kernel.org list;
> Wood Scott-B07421; Joerg Roedel; Paul Mackerras; David Gibson; Alex
> Williamson
> Subject: RE: [PATCH 1/6 v8] iommu/fsl: Store iommu domain information
> pointer in archdata.
> 
> 
> 
> > -Original Message-
> > From: Alexey Kardashevskiy [mailto:a...@ozlabs.ru]
> > Sent: Friday, March 01, 2013 4:07 AM
> > To: Sethi Varun-B16395
> > Cc: Kumar Gala; Benjamin Herrenschmidt;
> > io...@lists.linux-foundation.org; linuxppc-...@lists.ozlabs.org list;
> > linux-kernel@vger.kernel.org list; Wood Scott-B07421; Yoder
> > Stuart-B08248; Joerg Roedel; Paul Mackerras; David Gibson; Alex
> > Williamson
> > Subject: Re: [PATCH 1/6 v8] iommu/fsl: Store iommu domain information
> pointer in archdata.
> >
> > btw the device struct already has a pointer to its iommu_group, and
> > the iommu_group struct itself has a pointer void *iommu_data which you
> > could use for anything you want (iommu_group_get_iommudata(),
> > iommu_group_set_iommudata()).
> >
> > By design you are expected to add iommu groups to a domain but not
> > devices so I am not so sure that you really need a pointer to domain
> > in the device struct.
> 
> Well, at the lowest level the IOMMU API does attach devices to domains--
> i.e.
> API attach_dev().  So, it seems to conceptually make sense to have a ptr
> from the device to the associated domain.  When you implement
> attach_dev() you need to be able to see whether the device is already
> attached to
> a domain.   Adding a couple of levels of indirection...from device to
> group to domain...doesn't seems to make things simpler or better IMHO.
> 
> x86 keeps a pointer to the domain in device archdata and since there is a
> direct correlation between a device and domain I'd rather see it where
> this patch has it.
> 

As Stuart stated this allows us to maintain the device <-> domain relationship 
at the lowest level.

-Varun

--
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 4/5] f2fs: align f2fs maximum name length to linux based filesystem

2013-03-03 Thread Namjae Jeon
2013/3/3, Jaegeuk Kim :
> We should not change the on-disk layout.
> Instead, simply we can deal with it by changing original condition check
> like below.

Even though the changes you suggested are ok. But there is one doubt.
By not changing the on-disk layout and just taking care of the limits
using the code is just causing confusion and looks a make-shift
arrangement.
Even though ‘256’ is the space reserved for the name ‘on-disk’ but by
changing the code – we are limiting it to use ‘255’.
If we chance the on-disk to make use of ‘255’ bytes it allows for
keeping all code intact and also like the code changes suggested, it
will still refer only the ‘255’ bytes.

More so, changing the on-disk allows for ‘1byte’ which is still padded
at the same position to be used in future. Otherwise, this ‘extra’
byte will continue to exist without having that to be used for some
extra work.

Let me know your opinion.
Thanks.

>
> ---
> From ccc2546eded1efd2d6ed98f8aee7d7ce247cb4a2 Mon Sep 17 00:00:00 2001
> From: Jaegeuk Kim 
> Date: Sun, 3 Mar 2013 13:58:05 +0900
> Subject: [PATCH] f2fs: align f2fs maximum name length to linux based
>  filesystem
> Cc: linux-fsde...@vger.kernel.org, linux-kernel@vger.kernel.org,
> linux-f2fs-de...@lists.sourceforge.net
>
> The maximum filename length supported in linux is 255 characters.
> So let's follow that.
>
> Signed-off-by: Namjae Jeon 
> Signed-off-by: Amit Sahrawat 
> Signed-off-by: Jaegeuk Kim 
> ---
>  fs/f2fs/dir.c   |  3 +++
>  fs/f2fs/namei.c |  2 +-
>  fs/f2fs/super.c |  2 +-
>  include/linux/f2fs_fs.h | 14 --
>  4 files changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
> index c395c50..4ac8a7b 100644
> --- a/fs/f2fs/dir.c
> +++ b/fs/f2fs/dir.c
> @@ -189,6 +189,9 @@ struct f2fs_dir_entry *f2fs_find_entry(struct inode
> *dir,
>   unsigned int max_depth;
>   unsigned int level;
>
> + if (namelen > F2FS_NAME_LEN)
> + return NULL;
> +
>   if (npages == 0)
>   return NULL;
>
> diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c
> index 1a49b88..d4a171b 100644
> --- a/fs/f2fs/namei.c
> +++ b/fs/f2fs/namei.c
> @@ -197,7 +197,7 @@ static struct dentry *f2fs_lookup(struct inode *dir,
> struct dentry *dentry,
>   struct f2fs_dir_entry *de;
>   struct page *page;
>
> - if (dentry->d_name.len > F2FS_MAX_NAME_LEN)
> + if (dentry->d_name.len > F2FS_NAME_LEN)
>   return ERR_PTR(-ENAMETOOLONG);
>
>   de = f2fs_find_entry(dir, >d_name, );
> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> index 8c11764..1c7f595 100644
> --- a/fs/f2fs/super.c
> +++ b/fs/f2fs/super.c
> @@ -180,7 +180,7 @@ static int f2fs_statfs(struct dentry *dentry, struct
> kstatfs *buf)
>   buf->f_files = sbi->total_node_count;
>   buf->f_ffree = sbi->total_node_count - valid_inode_count(sbi);
>
> - buf->f_namelen = F2FS_MAX_NAME_LEN;
> + buf->f_namelen = F2FS_NAME_LEN;
>   buf->f_fsid.val[0] = (u32)id;
>   buf->f_fsid.val[1] = (u32)(id >> 32);
>
> diff --git a/include/linux/f2fs_fs.h b/include/linux/f2fs_fs.h
> index f9a12f6..7b50991 100644
> --- a/include/linux/f2fs_fs.h
> +++ b/include/linux/f2fs_fs.h
> @@ -139,6 +139,8 @@ struct f2fs_extent {
>   __le32 len; /* lengh of the extent */
>  } __packed;
>
> +/* We can store F2FS_MAX_NAME_LEN, but lets follow linux convention. */
> +#define F2FS_NAME_LEN255
>  #define F2FS_MAX_NAME_LEN256
>  #define ADDRS_PER_INODE 923  /* Address Pointers in an Inode */
>  #define ADDRS_PER_BLOCK 1018 /* Address Pointers in a Direct
> Block */
> @@ -362,10 +364,10 @@ struct f2fs_summary_block {
>  typedef __le32   f2fs_hash_t;
>
>  /* One directory entry slot covers 8bytes-long file name */
> -#define F2FS_NAME_LEN8
> -#define F2FS_NAME_LEN_BITS   3
> +#define F2FS_SLOT_LEN8
> +#define F2FS_SLOT_LEN_BITS   3
>
> -#define GET_DENTRY_SLOTS(x)  ((x + F2FS_NAME_LEN - 1) >>
> F2FS_NAME_LEN_BITS)
> +#define GET_DENTRY_SLOTS(x)  ((x + F2FS_SLOT_LEN - 1) >>
> F2FS_SLOT_LEN_BITS)
>
>  /* the number of dentry in a block */
>  #define NR_DENTRY_IN_BLOCK   214
> @@ -377,10 +379,10 @@ typedef __le32  f2fs_hash_t;
>  #define SIZE_OF_DENTRY_BITMAP((NR_DENTRY_IN_BLOCK + BITS_PER_BYTE -
> 1) / \
>   BITS_PER_BYTE)
>  #define SIZE_OF_RESERVED (PAGE_SIZE - ((SIZE_OF_DIR_ENTRY + \
> - F2FS_NAME_LEN) * \
> + F2FS_SLOT_LEN) * \
>   NR_DENTRY_IN_BLOCK + SIZE_OF_DENTRY_BITMAP))
>
> -/* One directory entry slot representing F2FS_NAME_LEN-sized file name
> */
> +/* One directory entry slot representing F2FS_SLOT_LEN-sized file name
> */
>  struct f2fs_dir_entry {
>   __le32 hash_code;   /* hash code of file name */
>   __le32 ino; /* inode number */
> @@ -394,7 +396,7 @@ struct f2fs_dentry_block {
>   __u8 

[PATCH] tracing: Fix some section mismatch warninings

2013-03-03 Thread Li Zefan
As we've added __init annotation to field-defining functions, we should
add __refdata annotation to event_call variables, which reference those
functions.

Reported-by: Fengguang Wu 
Signed-off-by: Li Zefan 
---
 include/trace/ftrace.h| 2 +-
 kernel/trace/trace_export.c   | 2 +-
 kernel/trace/trace_syscalls.c | 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
index dc18af3..3ffaf52 100644
--- a/include/trace/ftrace.h
+++ b/include/trace/ftrace.h
@@ -570,7 +570,7 @@ static inline void ftrace_test_probe_##call(void)   
\
 #define DECLARE_EVENT_CLASS(call, proto, args, tstruct, assign, print) \
 _TRACE_PERF_PROTO(call, PARAMS(proto));
\
 static const char print_fmt_##call[] = print;  \
-static struct ftrace_event_class __used event_class_##call = { \
+static struct ftrace_event_class __used __refdata event_class_##call = { \
.system = __stringify(TRACE_SYSTEM),\
.define_fields  = ftrace_define_fields_##call,  \
.fields = LIST_HEAD_INIT(event_class_##call.fields),\
diff --git a/kernel/trace/trace_export.c b/kernel/trace/trace_export.c
index 4f6a91c..d21a746 100644
--- a/kernel/trace/trace_export.c
+++ b/kernel/trace/trace_export.c
@@ -168,7 +168,7 @@ ftrace_define_fields_##name(struct ftrace_event_call 
*event_call)   \
 #define FTRACE_ENTRY_REG(call, struct_name, etype, tstruct, print, filter,\
 regfn) \
\
-struct ftrace_event_class event_class_ftrace_##call = {
\
+struct ftrace_event_class __refdata event_class_ftrace_##call = {  \
.system = __stringify(TRACE_SYSTEM),\
.define_fields  = ftrace_define_fields_##call,  \
.fields = 
LIST_HEAD_INIT(event_class_ftrace_##call.fields),\
diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c
index c57fe3d..07d75e5 100644
--- a/kernel/trace/trace_syscalls.c
+++ b/kernel/trace/trace_syscalls.c
@@ -438,7 +438,7 @@ struct trace_event_functions exit_syscall_print_funcs = {
.trace  = print_syscall_exit,
 };
 
-struct ftrace_event_class event_class_syscall_enter = {
+struct ftrace_event_class __refdata event_class_syscall_enter = {
.system = "syscalls",
.reg= syscall_enter_register,
.define_fields  = syscall_enter_define_fields,
@@ -446,7 +446,7 @@ struct ftrace_event_class event_class_syscall_enter = {
.raw_init   = init_syscall_trace,
 };
 
-struct ftrace_event_class event_class_syscall_exit = {
+struct ftrace_event_class __refdata event_class_syscall_exit = {
.system = "syscalls",
.reg= syscall_exit_register,
.define_fields  = syscall_exit_define_fields,
-- 
1.8.0.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/


Re: fasync race in fs/fcntl.c

2013-03-03 Thread Russ Dill
On Sat, Mar 2, 2013 at 4:09 PM, Russ Dill  wrote:
> On Sat, Mar 2, 2013 at 11:49 AM, Al Viro  wrote:
>> On Sat, Mar 02, 2013 at 03:00:28AM -0800, Russ Dill wrote:
>>> I'm seeing a race in fs/fcntl.c. I'm not sure exactly how the race is
>>> occurring, but the following is my best guess. A kernel log is
>>> attached.
>>
>> [snip the analysis - it's a different lock anyway]
>>
>> The traces below are essentially sys_execve() getting to get_random_bytes(),
>> to kill_fasync(), to send_sigio(), which spins on tasklist_lock.
>>
>> Could you rebuild it with lockdep enabled and try to reproduce that?
>> I very much doubt that this execve() is a part of deadlock - it's
>> getting caught on one, but it shouldn't be holding any locks that
>> nest inside tasklist_lock at that point, so even it hadn't been there,
>> the process holding tasklist_lock probably wouldn't have progressed any
>> further...
>
> ok, I did screw up the analysis quite badly, luckily, lockdep got it right 
> away.
>

So lockdep gives some clues, but seems a bit confused, so here's what happened.

mix_pool_bytes /* takes nonblocking_pool.lock */
add_device_randomness
posix_cpu_timers_exit
__exit_signal
release_task /* takes write lock on tasklist_lock */
do_exit
__module_put_and_exit
cryptomgr_test

send_sigio /* takes read lock on tasklist_lock */
kill_fasync_rcu
kill_fasync
account /* takes nonblocking_pool.lock */
extract_entropy
get_random_bytes
create_elf_tables
load_elf_binary
load_elf_library
search_binary_handler

This would mark the culprit as 613370549 'random: Mix cputime from
each thread that exits to the pool'.  So long as I'm not as crazy on
the last analysis as this one, may I suggest a revert of this commit
for 3.8.3?

> [  199.411236]
> [  199.411261] ==
> [  199.411268] [ INFO: possible circular locking dependency detected ]
> [  199.411277] 3.8.0-9-generic #18 Not tainted
> [  199.411283] ---
> [  199.411290] slirp-wrapper.s/5574 is trying to acquire lock:
> [  199.411296]  (&(>fa_lock)->rlock){-.-...}, at:
> [] kill_fasync+0x69/0xe0
> [  199.411332]
> [  199.411332] but task is already holding lock:
> [  199.411338]  (_pool.lock){..}, at:
> [] account+0x39/0x1d0
> [  199.411364]
> [  199.411364] which lock already depends on the new lock.
> [  199.411364]
> [  199.411371]
> [  199.411371] the existing dependency chain (in reverse order) is:
> [  199.411379]
> [  199.411379] -> #2 (_pool.lock){..}:
> [  199.411400][] lock_acquire+0x98/0x120
> [  199.411416][] _raw_spin_lock_irqsave+0x4e/0x70
> [  199.411430][] 
> mix_pool_bytes.constprop.20+0x43/0xb0
> [  199.411442][] add_device_randomness+0x64/0x90
> [  199.411454][] posix_cpu_timers_exit+0x1e/0x50
> [  199.411469][] release_task+0xe2/0x470
> [  199.411484][] do_exit+0x5d7/0x9c0
> [  199.411495][] __module_put_and_exit+0x1a/0x20
> [  199.411509][] cryptomgr_test+0x25/0x30
> [  199.411526][] kthread+0xea/0xf0
> [  199.411537][] ret_from_fork+0x7c/0xb0
> [  199.411550]
> [  199.411550] -> #1 (&(>siglock)->rlock){-.-...}:
> [  199.411689][] lock_acquire+0x98/0x120
> [  199.411702][] _raw_spin_lock_irqsave+0x4e/0x70
> [  199.411713][] vblank_disable_fn+0x60/0xd0 [drm]
> [  199.411768][] call_timer_fn+0x7a/0x180
> [  199.411781][] run_timer_softirq+0x1fc/0x2a0
> [  199.411794][] __do_softirq+0xe0/0x220
> [  199.411807][] call_softirq+0x1c/0x30
> [  199.411819][] do_softirq+0xa5/0xe0
> [  199.411833][] irq_exit+0xb5/0xc0
> [  199.411846][] smp_apic_timer_interrupt+0x6e/0x99
> [  199.411859][] apic_timer_interrupt+0x72/0x80
> [  199.411871][] cpuidle_enter_tk+0x10/0x20
> [  199.411885][] cpuidle_idle_call+0xa5/0x270
> [  199.411897][] cpu_idle+0xb5/0x120
> [  199.411910][] rest_init+0xb4/0xc0
> [  199.411924][] start_kernel+0x3ea/0x3f6
> [  199.411939][] 
> x86_64_start_reservations+0x130/0x133
> [  199.411952][] x86_64_start_kernel+0x100/0x10f
> [  199.411966]
> [  199.411966] -> #0 (&(>fa_lock)->rlock){-.-...}:
> [  199.411984][] __lock_acquire+0x1279/0x1aa0
> [  199.411997][] lock_acquire+0x98/0x120
> [  199.412103][] _raw_spin_lock_irqsave+0x4e/0x70
> [  199.412115][] kill_fasync+0x69/0xe0
> [  199.412127][] account+0x113/0x1d0
> [  199.412138][] extract_entropy+0x65/0x140
> [  199.412149][] get_random_bytes+0x20/0x30
> [  199.412159][] create_elf_tables+0xaa/0x615
> [  199.412172][] load_elf_binary+0xae4/0xe00
> [  199.412185][] search_binary_handler+0x171/0x390
> [  199.412197][] load_script+0x265/0x2b0
> [  199.412208][] search_binary_handler+0x171/0x390
> [  199.412219][] 
> do_execve_common.isra.23+0x405/0x4c0
> [  199.412230]

Re: [PATCH] ARM: ux500: read the correct soc_id number

2013-03-03 Thread Linus Walleij
On Wed, Feb 20, 2013 at 9:29 AM, Fabio Baltieri
 wrote:

> Fix db8500_read_soc_id() to read all five soc_id number locations
> instead of repeating the second one two times.
>
> Signed-off-by: Fabio Baltieri 

Thanks, patch applied!

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


Re: [PATCH 3/5] f2fs: move f2fs_balance_fs to correct place in unlink

2013-03-03 Thread Namjae Jeon
2013/3/3, Jaegeuk Kim :
> 2013-03-02 (토), 12:41 +0900, Namjae Jeon:
>> From: Namjae Jeon 
>>
>> Actual dirty of pages will occur in f2fs_delete_entry so move the
>> f2fs_balance_fs just before deletion.
>>
>> Signed-off-by: Namjae Jeon 
>> Signed-off-by: Amit Sahrawat 
>> ---
>>  fs/f2fs/namei.c |4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c
>> index 1a49b88..eaa86f5 100644
>> --- a/fs/f2fs/namei.c
>> +++ b/fs/f2fs/namei.c
>> @@ -223,8 +223,6 @@ static int f2fs_unlink(struct inode *dir, struct
>> dentry *dentry)
>>  struct page *page;
>>  int err = -ENOENT;
>>
>> -f2fs_balance_fs(sbi);
>> -
>>  de = f2fs_find_entry(dir, >d_name, );
>>  if (!de)
>>  goto fail;
>> @@ -236,6 +234,8 @@ static int f2fs_unlink(struct inode *dir, struct
>> dentry *dentry)
>>  goto fail;
>>  }
>>
>> +f2fs_balance_fs(sbi);
>> +
>
> I think we don't need to do this because of no issues on performance and
> reliability.
> In addition, it would be better to call f2fs_balance_fs without any
> dentry page.
Regarding moving “f2fs_balance_fs” in unlink part– we considered one scenario.
Suppose – when the disk is full and it really needed to trigger the
Garbage collection. But in this we considered one scenario. Let’s say
the ‘name’ being passed is for invalid file i.e., the file does not
exist. So, primarily in this case – I think it should return
immediately.
In such cases it actually results in wrong timing results for the
non-existence files.
For this observation we thought that f2fs_balance_fs be instead called
at a proper place i.e., after there is no lookup-failure.

Let me know your opinion.
Thanks.
>
>>  f2fs_delete_entry(de, page, inode);
>>
>>  /* In order to evict this inode,  we set it dirty */
>
> --
> Jaegeuk Kim
> Samsung
>
--
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 1/3] mtd: add new fields to nand_flash_dev{}

2013-03-03 Thread Huang Shijie

于 2013年03月02日 22:21, Artem Bityutskiy 写道:

On Sat, 2013-02-16 at 11:56 +0800, Huang Shijie wrote:

On Tue, Feb 12, 2013 at 11:47 PM, Artem Bityutskiy  wrote:

On Mon, 2013-01-28 at 12:57 +0800, Huang Shijie wrote:

+   {"SmartMedia 256MiB 3,3V",  {0, 0x71}, 512, 256, 0x4000 },
+   {"SmartMedia 256MiB 3,3V ROM",  {0, 0x5b}, 512, 256, 0x4000,
NAND_ROM},

Sorry for a possibly stupid question, but what does it buy you adding
another "0" to all the entries? I see you add another table, which you
look up if the "traditional" table does not work. Why you need to add
these zeroes?

The zeros are for the maf_id.

The dev_id is the second byte of the 8-byte id data.

It does not really make me understand why we add these zeroes, they
still look useless to me... Would you please be a little more verbose
about your solution?

the 8bytes id data read out by the READ ID command is in the following 
order:
   byte 0(Maker id): such as 0x98 stands for Toshiba, 0xec stands for 
Samsung.

   byte 1(device id):
   byte 2(used to store the chip number,cell type information):
   byte 3(used to store the page size, block size information)
   byte 4(used to store the Plane information).
   


The current code uses the @id to store the device id(byte 1).
But if we use the 8 bytes id data as the keyword, and expand the @id 
field to 8byte array,
the device id is the second byte now. All the added zeros are for the 
Maker id.

For example,
{"SmartMedia 256MiB 3,3V",  {0, 0x71}, 512, 256, 0x4000 },

We really do not use the zeros. All the zeros are added for avoiding the 
misunderstanding.

If we do not add the zero, it will looks like:

 {"SmartMedia 256MiB 3,3V",  {0x71}, 512, 256, 0x4000 },

The device id (0x71) becomes the first byte of 8byte id array, people will 
treat the 0x71 as the Maker code.


thanks
Huang Shijie


--
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 RFT] pinctrl: single: Fix build error

2013-03-03 Thread Haojian Zhuang
On 4 March 2013 13:47, Axel Lin  wrote:
> If pcs->is_pinconf is false, it means does not support pinconf.
> If pcs->is_pinconf is true, is_generic flag is always true.
>
> This patch fixes below build error:
>
>   CC [M]  drivers/pinctrl/pinctrl-single.o
> drivers/pinctrl/pinctrl-single.c: In function 'pcs_probe':
> drivers/pinctrl/pinctrl-single.c:1441:3: error: assignment of member 
> 'is_generic' in read-only object
> make[2]: *** [drivers/pinctrl/pinctrl-single.o] Error 1
> make[1]: *** [drivers/pinctrl] Error 2
> make: *** [drivers] Error 2
>
> Signed-off-by: Axel Lin 
> ---
>  drivers/pinctrl/pinctrl-single.c |6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pinctrl/pinctrl-single.c 
> b/drivers/pinctrl/pinctrl-single.c
> index 4cdcf85..e35dabd 100644
> --- a/drivers/pinctrl/pinctrl-single.c
> +++ b/drivers/pinctrl/pinctrl-single.c
> @@ -734,6 +734,7 @@ static const struct pinconf_ops pcs_pinconf_ops = {
> .pin_config_dbg_show = pcs_pinconf_dbg_show,
> .pin_config_group_dbg_show = pcs_pinconf_group_dbg_show,
> .pin_config_config_dbg_show = pcs_pinconf_config_dbg_show,
> +   .is_generic = true,

There's two cases for is_generic. Your fix only make thing worse.

By the way, I already sent a patch to fix it.

Regards
Haojian
>  };
>
>  /**
> @@ -1435,10 +1436,9 @@ static int pcs_probe(struct platform_device *pdev)
> pcs->desc.name = DRIVER_NAME;
> pcs->desc.pctlops = _pinctrl_ops;
> pcs->desc.pmxops = _pinmux_ops;
> -   pcs->desc.confops = _pinconf_ops;
> +   if (pcs->is_pinconf)
> +   pcs->desc.confops = _pinconf_ops;
> pcs->desc.owner = THIS_MODULE;
> -   if (match->data)
> -   pcs_pinconf_ops.is_generic = true;
>
> ret = pcs_allocate_pin_table(pcs);
> if (ret < 0)
> --
> 1.7.9.5
>
>
>
--
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 RFT] pinctrl: single: Fix build error

2013-03-03 Thread Axel Lin
If pcs->is_pinconf is false, it means does not support pinconf.
If pcs->is_pinconf is true, is_generic flag is always true.

This patch fixes below build error:

  CC [M]  drivers/pinctrl/pinctrl-single.o
drivers/pinctrl/pinctrl-single.c: In function 'pcs_probe':
drivers/pinctrl/pinctrl-single.c:1441:3: error: assignment of member 
'is_generic' in read-only object
make[2]: *** [drivers/pinctrl/pinctrl-single.o] Error 1
make[1]: *** [drivers/pinctrl] Error 2
make: *** [drivers] Error 2

Signed-off-by: Axel Lin 
---
 drivers/pinctrl/pinctrl-single.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index 4cdcf85..e35dabd 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -734,6 +734,7 @@ static const struct pinconf_ops pcs_pinconf_ops = {
.pin_config_dbg_show = pcs_pinconf_dbg_show,
.pin_config_group_dbg_show = pcs_pinconf_group_dbg_show,
.pin_config_config_dbg_show = pcs_pinconf_config_dbg_show,
+   .is_generic = true,
 };
 
 /**
@@ -1435,10 +1436,9 @@ static int pcs_probe(struct platform_device *pdev)
pcs->desc.name = DRIVER_NAME;
pcs->desc.pctlops = _pinctrl_ops;
pcs->desc.pmxops = _pinmux_ops;
-   pcs->desc.confops = _pinconf_ops;
+   if (pcs->is_pinconf)
+   pcs->desc.confops = _pinconf_ops;
pcs->desc.owner = THIS_MODULE;
-   if (match->data)
-   pcs_pinconf_ops.is_generic = true;
 
ret = pcs_allocate_pin_table(pcs);
if (ret < 0)
-- 
1.7.9.5



--
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 2/2] ARM: EXYNOS: support burst mode for for dev-to-mem and dev-to-mem transmit

2013-03-03 Thread Vinod Koul
On Tue, Feb 19, 2013 at 11:02:09AM +0900, Boojin Kim wrote:
> This patch adds to support burst mode for for dev-to-mem and dev-to-mem 
> transmit
> 
> Signed-off-by: Boojin Kim 
> ---
>  arch/arm/plat-samsung/dma-ops.c  |   10 --
>  arch/arm/plat-samsung/include/plat/dma-ops.h |1 +
>  2 files changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/plat-samsung/dma-ops.c b/arch/arm/plat-samsung/dma-ops.c
> index d088afa..c25e842 100644
> --- a/arch/arm/plat-samsung/dma-ops.c
> +++ b/arch/arm/plat-samsung/dma-ops.c
> @@ -54,14 +54,20 @@ static int samsung_dmadev_config(unsigned ch,
>   slave_config.direction = param->direction;
>   slave_config.src_addr = param->fifo;
>   slave_config.src_addr_width = param->width;
> - slave_config.src_maxburst = 1;
Hi Boojin,

what do you mean by the busrt mode here?

fwiw the meanining of above maxburst is:
@src_maxburst: the maximum number of words (note: words, as in
units of the src_addr_width member, not bytes) that can be sent
in one burst to the device. Typically something like half the
FIFO depth on I/O peripherals so you don't overflow it. This
may or may not be applicable on memory sources.

> + if (param->maxburst)
> + slave_config.src_maxburst = param->maxburst;
> + else
> + slave_config.src_maxburst = 1;
>   dmaengine_slave_config(chan, _config);
>   } else if (param->direction == DMA_MEM_TO_DEV) {
>   memset(_config, 0, sizeof(struct dma_slave_config));
>   slave_config.direction = param->direction;
>   slave_config.dst_addr = param->fifo;
>   slave_config.dst_addr_width = param->width;
> - slave_config.dst_maxburst = 1;
> + if (param->maxburst)
> + slave_config.dst_maxburst = param->maxburst;
> + else
> + slave_config.dst_maxburst = 1;
>   dmaengine_slave_config(chan, _config);
>   } else {
>   pr_warn("unsupported direction\n");
> diff --git a/arch/arm/plat-samsung/include/plat/dma-ops.h 
> b/arch/arm/plat-samsung/include/plat/dma-ops.h
> index f5144cd..95893c7 100644
> --- a/arch/arm/plat-samsung/include/plat/dma-ops.h
> +++ b/arch/arm/plat-samsung/include/plat/dma-ops.h
> @@ -35,6 +35,7 @@ struct samsung_dma_prep {
>  struct samsung_dma_config {
>   enum dma_transfer_direction direction;
>   enum dma_slave_buswidth width;
> + u32 maxburst;
>   dma_addr_t fifo;
>  };
> 
> --
> 1.7.5.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/


[PATCH] x86: fix idle notifier not being called in CONFIG_X86_32

2013-03-03 Thread Illyas Mansoor
Idle notifier not registered if CONFIG_X86_32 is defined,
those callbacks are empty for X86_32 platform.

ifdef CONFIG_X86_64
 void enter_idle(void);
 void exit_idle(void);
else
static inline void enter_idle(void) { }
static inline void exit_idle(void) { }
static inline void __exit_idle(void) { }
endif

Make this work on X86_32 platforms by
removing the restriction for X86_64

Signed-off-by: Dyut Kumar Sil 
Signed-off-by: Ashish K 
Signed-off-by: Illyas Mansoor 
Reviewed-by: Cuesta, Fernand 
Reviewed-by: Cuesta, Fernand 
Reviewed-by: Kumar P, Mahesh 
Tested-by: Cuesta, Fernand 
---
 arch/x86/include/asm/idle.h |6 --
 arch/x86/kernel/process.c   |4 
 2 files changed, 10 deletions(-)

diff --git a/arch/x86/include/asm/idle.h b/arch/x86/include/asm/idle.h
index c5d1785..489ac46 100644
--- a/arch/x86/include/asm/idle.h
+++ b/arch/x86/include/asm/idle.h
@@ -8,14 +8,8 @@ struct notifier_block;
 void idle_notifier_register(struct notifier_block *n);
 void idle_notifier_unregister(struct notifier_block *n);
 
-#ifdef CONFIG_X86_64
 void enter_idle(void);
 void exit_idle(void);
-#else /* !CONFIG_X86_64 */
-static inline void enter_idle(void) { }
-static inline void exit_idle(void) { }
-static inline void __exit_idle(void) { }
-#endif /* CONFIG_X86_64 */
 
 void amd_e400_remove_cpu(int cpu);
 
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 14ae100..043e553 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -38,7 +38,6 @@
  */
 DEFINE_PER_CPU_SHARED_ALIGNED(struct tss_struct, init_tss) = INIT_TSS;
 
-#ifdef CONFIG_X86_64
 static DEFINE_PER_CPU(unsigned char, is_idle);
 static ATOMIC_NOTIFIER_HEAD(idle_notifier);
 
@@ -53,7 +52,6 @@ void idle_notifier_unregister(struct notifier_block *n)
atomic_notifier_chain_unregister(_notifier, n);
 }
 EXPORT_SYMBOL_GPL(idle_notifier_unregister);
-#endif
 
 struct kmem_cache *task_xstate_cachep;
 EXPORT_SYMBOL_GPL(task_xstate_cachep);
@@ -277,7 +275,6 @@ static inline void play_dead(void)
 }
 #endif
 
-#ifdef CONFIG_X86_64
 void enter_idle(void)
 {
this_cpu_write(is_idle, 1);
@@ -299,7 +296,6 @@ void exit_idle(void)
return;
__exit_idle();
 }
-#endif
 
 /*
  * The idle thread. There's no useful work to be
-- 
1.7.9.5

--
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: [ 093/153] ALSA: hda - hdmi: Make jacks phantom, if theyre not detectable

2013-03-03 Thread Ben Hutchings
On Mon, 2013-03-04 at 03:38 +, Ben Hutchings wrote:
> 3.2-stable review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: David Henningsson 
> 
> commit 30efd8debd1ef30be342d374f01e993509f5b76b upstream.
> 
> Just as for analog codecs, a jack that isn't suitable for detection
> (in this case, NO_PRESENCE was set) should be a phantom Jack
> instead of a normal one.
> 
> Thanks to Raymond Yau for spotting.
> 
> BugLink: https://bugs.launchpad.net/bugs/961286
> BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=903869
> Signed-off-by: David Henningsson 
> Signed-off-by: Takashi Iwai 
> [bwh: Backported to 3.2: adjust context]
> Signed-off-by: Ben Hutchings 

David, do I need to change this further for 3.2.y?

Ben.

> ---
>  sound/pci/hda/patch_hdmi.c |3 +++
>  1 file changed, 3 insertions(+)
> 
> --- a/sound/pci/hda/patch_hdmi.c
> +++ b/sound/pci/hda/patch_hdmi.c
> @@ -1228,6 +1228,9 @@ static int generic_hdmi_build_jack(struc
>   int pcmdev = spec->pcm_rec[pin_idx].device;
>  
>   snprintf(hdmi_str, sizeof(hdmi_str), "HDMI/DP,pcm=%d", pcmdev);
> + if (!is_jack_detectable(codec, per_pin->pin_nid))
> + strncat(hdmi_str, " Phantom",
> + sizeof(hdmi_str) - strlen(hdmi_str) - 1);
>  
>   err = snd_hda_input_jack_add(codec, per_pin->pin_nid,
>SND_JACK_VIDEOOUT, pcmdev > 0 ? hdmi_str : NULL);
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
Ben Hutchings
Always try to do things in chronological order;
it's less confusing that way.


signature.asc
Description: This is a digitally signed message part


Re: [PATCHv2] dw_dmac: adjust slave_id accordingly to request line base

2013-03-03 Thread Vinod Koul
On Wed, Feb 20, 2013 at 01:52:17PM +0200, Andy Shevchenko wrote:
> On some hardware configurations we have got the request line with the offset.
> The patch introduces convert_slave_id() helper for that cases. The request 
> line
> base is came from the driver data provided by the platform_device_id table.
> 
> Signed-off-by: Mika Westerberg 
> Signed-off-by: Andy Shevchenko 
> Cc: Viresh Kumar 
Applied, Thanks

> ---
> Since v1:
>  - use driver_data instead of parsing IORESOURCE_DMA
>  drivers/dma/dw_dmac.c  |   17 -
>  drivers/dma/dw_dmac_regs.h |1 +
>  2 files changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
> index 51c3ea2..67a868d 100644
> --- a/drivers/dma/dw_dmac.c
> +++ b/drivers/dma/dw_dmac.c
> @@ -994,6 +994,13 @@ static inline void convert_burst(u32 *maxburst)
>   *maxburst = 0;
>  }
>  
> +static inline void convert_slave_id(struct dw_dma_chan *dwc)
> +{
> + struct dw_dma *dw = to_dw_dma(dwc->chan.device);
> +
> + dwc->dma_sconfig.slave_id -= dw->request_line_base;
> +}
> +
>  static int
>  set_runtime_config(struct dma_chan *chan, struct dma_slave_config *sconfig)
>  {
> @@ -1008,6 +1015,7 @@ set_runtime_config(struct dma_chan *chan, struct 
> dma_slave_config *sconfig)
>  
>   convert_burst(>dma_sconfig.src_maxburst);
>   convert_burst(>dma_sconfig.dst_maxburst);
> + convert_slave_id(dwc);
>  
>   return 0;
>  }
> @@ -1637,6 +1645,7 @@ dw_dma_parse_dt(struct platform_device *pdev)
>  
>  static int dw_probe(struct platform_device *pdev)
>  {
> + const struct platform_device_id *match;
>   struct dw_dma_platform_data *pdata;
>   struct resource *io;
>   struct dw_dma   *dw;
> @@ -1722,6 +1731,11 @@ static int dw_probe(struct platform_device *pdev)
>   memcpy(dw->data_width, pdata->data_width, 4);
>   }
>  
> + /* Get the base request line if set */
> + match = platform_get_device_id(pdev);
> + if (match)
> + dw->request_line_base = (unsigned int)match->driver_data;
> +
>   /* Calculate all channel mask before DMA setup */
>   dw->all_chan_mask = (1 << nr_channels) - 1;
>  
> @@ -1907,7 +1921,8 @@ MODULE_DEVICE_TABLE(of, dw_dma_id_table);
>  #endif
>  
>  static const struct platform_device_id dw_dma_ids[] = {
> - { "INTL9C60", 0 },
> + /* Name,Request Line Base */
> + { "INTL9C60",   (kernel_ulong_t)16 },
>   { }
>  };
>  
> diff --git a/drivers/dma/dw_dmac_regs.h b/drivers/dma/dw_dmac_regs.h
> index 88dd8eb..3eeb766 100644
> --- a/drivers/dma/dw_dmac_regs.h
> +++ b/drivers/dma/dw_dmac_regs.h
> @@ -248,6 +248,7 @@ struct dw_dma {
>   /* hardware configuration */
>   unsigned char   nr_masters;
>   unsigned char   data_width[4];
> + unsigned intrequest_line_base;
>  
>   struct dw_dma_chan  chan[0];
>  };
> -- 
> 1.7.10.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: linux-next stats (Was: Linux 3.9-rc1)

2013-03-03 Thread Stephen Rothwell
Hi all,

On Mon, 4 Mar 2013 15:22:22 +1100 Stephen Rothwell  
wrote:
>
> So commits in -rc1 that were "in" next-20130220:  930090.6%
>   (down from 90.0% last time)

That should read "down from 90.9% last time".

At least I know that one person reads my postings (thanks Ted :-))

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpzE5XZ4E46P.pgp
Description: PGP signature


Re: [PATCH] pch_dma: Use GFP_ATOMIC because called from interrupt context

2013-03-03 Thread Vinod Koul
> On Tue, Feb 12, 2013 at 11:25 AM, Tomoya MORINAGA  
> wrote:
> > 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 
Applied, thanks

> > ---
> >  drivers/dma/pch_dma.c |2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/dma/pch_dma.c b/drivers/dma/pch_dma.c
> > index 987ab5c..d5cbd44 100644
> > --- a/drivers/dma/pch_dma.c
> > +++ b/drivers/dma/pch_dma.c
> > @@ -476,7 +476,7 @@ static struct pch_dma_desc *pdc_desc_get(struct 
> > pch_dma_chan *pd_chan)
> > 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++;
> > --
> > 1.7.4.4
> 
> -- 
> ROHM Co., Ltd.
> tomoya
--
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: [ 052/153] idr: idr_for_each_entry() macro

2013-03-03 Thread Ben Hutchings
On Mon, 2013-03-04 at 03:37 +, Ben Hutchings wrote:
> 3.2-stable review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Philipp Reisner 
> 
> commit 9749f30f1a387070e6e8351f35aeb829eacc3ab6 upstream.
> 
> Inspired by the list_for_each_entry() macro
> 
> Signed-off-by: Ben Hutchings 

Philipp, please can I have an explicit Signed-off-by from you?  It was
missing in mainline though this change appeared in a long series of drbd
changes with proper Signed-off-by lines.

Ben.

> ---
>  include/linux/idr.h |   11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/include/linux/idr.h b/include/linux/idr.h
> index 255491c..52a9da2 100644
> --- a/include/linux/idr.h
> +++ b/include/linux/idr.h
> @@ -152,4 +152,15 @@ void ida_simple_remove(struct ida *ida, unsigned int id);
>  
>  void __init idr_init_cache(void);
>  
> +/**
> + * idr_for_each_entry - iterate over an idr's elements of a given type
> + * @idp: idr handle
> + * @entry:   the type * to use as cursor
> + * @id:  id entry's key
> + */
> +#define idr_for_each_entry(idp, entry, id)   \
> + for (id = 0, entry = (typeof(entry))idr_get_next((idp), &(id)); \
> +  entry != NULL; \
> +  ++id, entry = (typeof(entry))idr_get_next((idp), &(id)))
> +
>  #endif /* __IDR_H__ */
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
Ben Hutchings
Always try to do things in chronological order;
it's less confusing that way.


signature.asc
Description: This is a digitally signed message part


[RFC PATCH] ARM: mm: disable kmap_high_get() for SMP

2013-03-03 Thread Joonsoo Kim
With SMP and enabling kmap_high_get(), it makes users of kmap_atomic()
sequential ordered, because kmap_high_get() use global kmap_lock().
It is not welcome situation, so turn off this optimization for SMP.

Cc: Nicolas Pitre 
Signed-off-by: Joonsoo Kim 

diff --git a/arch/arm/include/asm/highmem.h b/arch/arm/include/asm/highmem.h
index 8c5e828..82fea0f 100644
--- a/arch/arm/include/asm/highmem.h
+++ b/arch/arm/include/asm/highmem.h
@@ -26,15 +26,13 @@ extern void kunmap_high(struct page *page);
  * The reason for kmap_high_get() is to ensure that the currently kmap'd
  * page usage count does not decrease to zero while we're using its
  * existing virtual mapping in an atomic context.  With a VIVT cache this
- * is essential to do, but with a VIPT cache this is only an optimization
- * so not to pay the price of establishing a second mapping if an existing
- * one can be used.  However, on platforms without hardware TLB maintenance
- * broadcast, we simply cannot use ARCH_NEEDS_KMAP_HIGH_GET at all since
- * the locking involved must also disable IRQs which is incompatible with
- * the IPI mechanism used by global TLB operations.
+ * is essential to do, but with a VIPT cache this is only an optimization.
+ * With SMP and enabling kmap_high_get(), it makes users of kmap_atomic()
+ * sequential ordered, because kmap_high_get() use global kmap_lock().
+ * It is not welcome situation, so turn off this optimization for SMP.
  */
 #define ARCH_NEEDS_KMAP_HIGH_GET
-#if defined(CONFIG_SMP) && defined(CONFIG_CPU_TLB_V6)
+#if defined(CONFIG_SMP)
 #undef ARCH_NEEDS_KMAP_HIGH_GET
 #if defined(CONFIG_HIGHMEM) && defined(CONFIG_CPU_CACHE_VIVT)
 #error "The sum of features in your kernel config cannot be supported together"
-- 
1.7.9.5

--
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] ARM: mm: clean-up in order to reduce to call kmap_high_get()

2013-03-03 Thread Joonsoo Kim
In kmap_atomic(), kmap_high_get() is invoked for checking already
mapped area. In __flush_dcache_page() and dma_cache_maint_page(),
we explicitly call kmap_high_get() before kmap_atomic()
when cache_is_vipt(), so kmap_high_get() can be invoked twice.
This is useless operation, so remove one.

Signed-off-by: Joonsoo Kim 

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index c7e3759..b7711be 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -822,16 +822,16 @@ static void dma_cache_maint_page(struct page *page, 
unsigned long offset,
if (PageHighMem(page)) {
if (len + offset > PAGE_SIZE)
len = PAGE_SIZE - offset;
-   vaddr = kmap_high_get(page);
-   if (vaddr) {
-   vaddr += offset;
-   op(vaddr, len, dir);
-   kunmap_high(page);
-   } else if (cache_is_vipt()) {
-   /* unmapped pages might still be cached */
+   if (cache_is_vipt()) {
vaddr = kmap_atomic(page);
op(vaddr + offset, len, dir);
kunmap_atomic(vaddr);
+   } else {
+   vaddr = kmap_high_get(page);
+   if (vaddr) {
+   op(vaddr + offset, len, dir);
+   kunmap_high(page);
+   }
}
} else {
vaddr = page_address(page) + offset;
diff --git a/arch/arm/mm/flush.c b/arch/arm/mm/flush.c
index 1c8f7f5..e6a03d0 100644
--- a/arch/arm/mm/flush.c
+++ b/arch/arm/mm/flush.c
@@ -170,15 +170,18 @@ void __flush_dcache_page(struct address_space *mapping, 
struct page *page)
if (!PageHighMem(page)) {
__cpuc_flush_dcache_area(page_address(page), PAGE_SIZE);
} else {
-   void *addr = kmap_high_get(page);
-   if (addr) {
-   __cpuc_flush_dcache_area(addr, PAGE_SIZE);
-   kunmap_high(page);
-   } else if (cache_is_vipt()) {
-   /* unmapped pages might still be cached */
+   void *addr;
+
+   if (cache_is_vipt()) {
addr = kmap_atomic(page);
__cpuc_flush_dcache_area(addr, PAGE_SIZE);
kunmap_atomic(addr);
+   } else {
+   addr = kmap_high_get(page);
+   if (addr) {
+   __cpuc_flush_dcache_area(addr, PAGE_SIZE);
+   kunmap_high(page);
+   }
}
}
 
-- 
1.7.9.5

--
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] ircomm: release tty before sleeping potentially indefintely

2013-03-03 Thread Peter Hurley

On Sun, 2013-03-03 at 21:36 -0500, David Miller wrote:
> From: Peter Hurley 
> Date: Sun, 03 Mar 2013 20:06:18 -0500
> 
> > But regardless, this function __cannot__ sleep holding the tty_lock().
> 
> So drop it across the schedule(), but recheck the termios after
> regrabbing it.

I'll have to do some research on that.

1) The code is using a deliberate snapshot.

if (tty->termios.c_cflag & CLOCAL) {
IRDA_DEBUG(1, "%s(), doing CLOCAL!\n", __func__ );
do_clocal = 1;
}

.

while (1) {

.

/*
 * Check if link is ready now. Even if CLOCAL is
 * specified, we cannot return before the IrCOMM link is
 * ready
 */
if (!test_bit(ASYNCB_CLOSING, >flags) &&
(do_clocal || tty_port_carrier_raised(port)) &&
self->state == IRCOMM_TTY_READY)
{
break;
}


2) The only reason this driver isn't using tty_port_block_til_ready() is
the lone state check:
self->state == IRCOMM_TTY_READY

I take it IRDA has some kind of virtual cabling protocol. But it's
unclear why this can't be implemented in the driver without duplicating
tty_port_block_til_ready(). For example, if the device can't do CLOCAL
open (meaning no underlying device attached prior to open) then why
specify that in the driver flags? Additionally, CLOCAL can be masked out
by the driver's set_termios() method. And then it could implement the
state check in its .carrier_raised() method.

The net result of which would obviate the need for
ircomm_tty_block_til_ready() at all.

3) The do_clocal snapshot is universally employed by every tty driver. I
don't mean that as some kind of lame excuse. But if this should change,
it should change across every tty driver with a really good reason.

4) Rechecking termios will change the way the user-space open() for this
device behaves. And I need to think more on how that might or might not
be a problem.

5) The code behavior pre-dates the 2005 check-in so I'll probably have
to do some code archaeology.


That's probably going to take some time.

In the meantime, while reviewing that code, I noticed there's a handful
of serious bugs in that one function that I'll send a patchset for.

Plus, someone could be back to me on if and why the driver needs to be
virtually cabled to open().

Regards,
Peter Hurley


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


[ 004/153] workqueue: consider work function when searching for busy work items

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Tejun Heo 

commit a2c1c57be8d9fd5b716113c8991d3d702eeacf77 upstream.

To avoid executing the same work item concurrenlty, workqueue hashes
currently busy workers according to their current work items and looks
up the the table when it wants to execute a new work item.  If there
already is a worker which is executing the new work item, the new item
is queued to the found worker so that it gets executed only after the
current execution finishes.

Unfortunately, a work item may be freed while being executed and thus
recycled for different purposes.  If it gets recycled for a different
work item and queued while the previous execution is still in
progress, workqueue may make the new work item wait for the old one
although the two aren't really related in any way.

In extreme cases, this false dependency may lead to deadlock although
it's extremely unlikely given that there aren't too many self-freeing
work item users and they usually don't wait for other work items.

To alleviate the problem, record the current work function in each
busy worker and match it together with the work item address in
find_worker_executing_work().  While this isn't complete, it ensures
that unrelated work items don't interact with each other and in the
very unlikely case where a twisted wq user triggers it, it's always
onto itself making the culprit easy to spot.

Signed-off-by: Tejun Heo 
Reported-by: Andrey Isakov 
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=51701
[bwh: Backported to 3.2:
 - Adjust context
 - Incorporate earlier logging cleanup in process_one_work() from
   044c782ce3a9 ('workqueue: fix checkpatch issues')]
Signed-off-by: Ben Hutchings 
---
 kernel/workqueue.c |   39 +++
 1 file changed, 31 insertions(+), 8 deletions(-)

--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -128,6 +128,7 @@ struct worker {
};
 
struct work_struct  *current_work;  /* L: work being processed */
+   work_func_t current_func;   /* L: current_work's fn */
struct cpu_workqueue_struct *current_cwq; /* L: current_work's cwq */
struct list_headscheduled;  /* L: scheduled works */
struct task_struct  *task;  /* I: worker task */
@@ -843,7 +844,8 @@ static struct worker *__find_worker_exec
struct hlist_node *tmp;
 
hlist_for_each_entry(worker, tmp, bwh, hentry)
-   if (worker->current_work == work)
+   if (worker->current_work == work &&
+   worker->current_func == work->func)
return worker;
return NULL;
 }
@@ -853,9 +855,27 @@ static struct worker *__find_worker_exec
  * @gcwq: gcwq of interest
  * @work: work to find worker for
  *
- * Find a worker which is executing @work on @gcwq.  This function is
- * identical to __find_worker_executing_work() except that this
- * function calculates @bwh itself.
+ * Find a worker which is executing @work on @gcwq by searching
+ * @gcwq->busy_hash which is keyed by the address of @work.  For a worker
+ * to match, its current execution should match the address of @work and
+ * its work function.  This is to avoid unwanted dependency between
+ * unrelated work executions through a work item being recycled while still
+ * being executed.
+ *
+ * This is a bit tricky.  A work item may be freed once its execution
+ * starts and nothing prevents the freed area from being recycled for
+ * another work item.  If the same work item address ends up being reused
+ * before the original execution finishes, workqueue will identify the
+ * recycled work item as currently executing and make it wait until the
+ * current execution finishes, introducing an unwanted dependency.
+ *
+ * This function checks the work item address, work function and workqueue
+ * to avoid false positives.  Note that this isn't complete as one may
+ * construct a work function which can introduce dependency onto itself
+ * through a recycled work item.  Well, if somebody wants to shoot oneself
+ * in the foot that badly, there's only so much we can do, and if such
+ * deadlock actually occurs, it should be easy to locate the culprit work
+ * function.
  *
  * CONTEXT:
  * spin_lock_irq(gcwq->lock).
@@ -1816,7 +1836,6 @@ __acquires(>lock)
struct global_cwq *gcwq = cwq->gcwq;
struct hlist_head *bwh = busy_worker_head(gcwq, work);
bool cpu_intensive = cwq->wq->flags & WQ_CPU_INTENSIVE;
-   work_func_t f = work->func;
int work_color;
struct worker *collision;
 #ifdef CONFIG_LOCKDEP
@@ -1845,6 +1864,7 @@ __acquires(>lock)
debug_work_deactivate(work);
hlist_add_head(>hentry, bwh);
worker->current_work = work;
+   worker->current_func = work->func;
worker->current_cwq = cwq;
work_color = get_work_color(work);
 
@@ -1882,7 +1902,7 @@ 

Re: [PATCH] ircomm: release tty before sleeping potentially indefintely

2013-03-03 Thread Peter Hurley
On Sun, 2013-03-03 at 21:36 -0500, David Miller wrote:
> From: Peter Hurley 
> Date: Sun, 03 Mar 2013 20:06:18 -0500
> 
> > But regardless, this function __cannot__ sleep holding the tty_lock().
> 
> So drop it across the schedule(), but recheck the termios after
> regrabbing it.

I'll have to do some research on that.

1) The code is using a deliberate snapshot.

if (tty->termios.c_cflag & CLOCAL) {
IRDA_DEBUG(1, "%s(), doing CLOCAL!\n", __func__ );
do_clocal = 1;
}

.

while (1) {

.

/*
 * Check if link is ready now. Even if CLOCAL is
 * specified, we cannot return before the IrCOMM link is
 * ready
 */
if (!test_bit(ASYNCB_CLOSING, >flags) &&
(do_clocal || tty_port_carrier_raised(port)) &&
self->state == IRCOMM_TTY_READY)
{
break;
}


2) The only reason this driver isn't using tty_port_block_til_ready() is
the lone state check:
self->state == IRCOMM_TTY_READY

I take it IRDA has some kind of virtual cabling protocol. But it's
unclear why this can't be implemented in the driver without duplicating
tty_port_block_til_ready(). For example, if the device can't do CLOCAL
open (meaning no underlying device attached prior to open) then why
specify that in the driver flags? Additionally, CLOCAL can be masked out
by the driver's set_termios() method. And then it could implement the
state check in its .carrier_raised() method.

3) The do_clocal snapshot is universally employed by every tty driver. I
don't mean that as some kind of lame excuse. But if this should change,
it should change across every tty driver with a really good reason.

4) Rechecking termios will change the way the user-space open() for this
device behaves. And I need to think more on how that might or might not
be a problem.

5) The code behavior pre-dates the 2005 check-in so I'll probably have
to do some code archaeology.


That's probably going to take some time.

In the meantime, while reviewing that code, I noticed there's a handful
of serious bugs in that one function that I'll send a patchset for.

Plus, someone could be back to me on if and why the driver needs to be
virtually cabled to open().

Regards,
Peter Hurley

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


[ 013/153] USB: option: add and update Alcatel modems

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Bjørn Mork 

commit f8f0302bbcbd1b14655bef29f6996a2152be559d upstream.

Adding three currently unsupported modems based on information
from .inf driver files:

  Diag  VID_1BBB_0052_00
  AGPS  VID_1BBB_0052_01
  VOICE VID_1BBB_0052_02
  ATVID_1BBB_0052_03
  Modem VID_1BBB_0052_05
  wwan  VID_1BBB_0052_06

  Diag  VID_1BBB_00B6_00
  ATVID_1BBB_00B6_01
  Modem VID_1BBB_00B6_02
  wwan  VID_1BBB_00B6_03

  Diag  VID_1BBB_00B7_00
  AGPS  VID_1BBB_00B7_01
  VOICE VID_1BBB_00B7_02
  ATVID_1BBB_00B7_03
  Modem VID_1BBB_00B7_04
  wwan  VID_1BBB_00B7_05

Updating the blacklist info for the X060S_X200 and X220_X500D,
reserving interfaces for a wwan driver, based on

  wwan VID_1BBB__04
  wwan VID_1BBB_0017_06

Signed-off-by: Bjørn Mork 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
---
 drivers/usb/serial/option.c |   10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -479,6 +479,7 @@ static const struct option_blacklist_inf
 
 static const struct option_blacklist_info alcatel_x200_blacklist = {
.sendsetup = BIT(0) | BIT(1),
+   .reserved = BIT(4),
 };
 
 static const struct option_blacklist_info zte_0037_blacklist = {
@@ -1215,7 +1216,14 @@ static const struct usb_device_id option
{ USB_DEVICE(ALCATEL_VENDOR_ID, ALCATEL_PRODUCT_X060S_X200),
  .driver_info = (kernel_ulong_t)_x200_blacklist
},
-   { USB_DEVICE(ALCATEL_VENDOR_ID, ALCATEL_PRODUCT_X220_X500D) },
+   { USB_DEVICE(ALCATEL_VENDOR_ID, ALCATEL_PRODUCT_X220_X500D),
+ .driver_info = (kernel_ulong_t)_intf6_blacklist },
+   { USB_DEVICE(ALCATEL_VENDOR_ID, 0x0052),
+ .driver_info = (kernel_ulong_t)_intf6_blacklist },
+   { USB_DEVICE(ALCATEL_VENDOR_ID, 0x00b6),
+ .driver_info = (kernel_ulong_t)_intf3_blacklist },
+   { USB_DEVICE(ALCATEL_VENDOR_ID, 0x00b7),
+ .driver_info = (kernel_ulong_t)_intf5_blacklist },
{ USB_DEVICE(ALCATEL_VENDOR_ID, ALCATEL_PRODUCT_L100V),
  .driver_info = (kernel_ulong_t)_intf4_blacklist },
{ USB_DEVICE(AIRPLUS_VENDOR_ID, AIRPLUS_PRODUCT_MCD650) },


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


linux-next stats (Was: Linux 3.9-rc1)

2013-03-03 Thread Stephen Rothwell
On Sun, 3 Mar 2013 16:28:25 -0800 Linus Torvalds 
 wrote:
>
> It's been two weeks (ok, thirteen days, but close enough), and the
> merge window is closed, and I've cut the 3.9-rc1 release.
> 
> I don't know if it's just me, but this merge window had more "Uhhuh"
> moments than I'm used to. I stopped merging a couple of times, because
> we had bugs that looked really scary, but thankfully each time people
> were on them like paparazzi on Justin Bieber. Special thanks to Peter,
> Ted and Rafael (and the people who reported the bugs too!) for being
> so responsive. It could have been so much worse.

Well here are this merge windows' stats:

(No merge commits counted, next-20130220 is the linux-next based exactly
on v3.8)

Commits in v3.9-rc1 (relative to v3.8): 10265
Commits in next-20130220:9903
Commits with the same SHA1:  8493
Commits with the same patch_id:   727   (1)
Commits with the same subject line:80   (1)

(1) not counting those in the lines above.

So commits in -rc1 that were "in" next-20130220:930090.6%
(down from 90.0% last time)
Commits in -rc1 that were not in next-20120722:  9659.4%

Pretty good, but it would be still nice to figure out where the last lot
came from.  I have the "git log --oneline --no-walk" list if someone wants them.

Some break down of the onelines list:

grep for drm gives 134
 btrfs gives 118
 mips gives 85
 ceph gives 41

Quite a few of the rest appear to be bug fixes.

As of today, there are 752 commits left in linux-next ... .  There are
161 commits in the akpm tree, 135 in the xen-two tree, 78 in the renesas
tree and everything else is in the noise.

There are also ~550 merge commits in there (not counting mine), so some
trees could definitely do with some cleaning up.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpk9hsomrbWg.pgp
Description: PGP signature


[ 010/153] pcmcia/vrc4171: Add missing spinlock init

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Jean Delvare 

commit 811af9723859884f2f771f3174f3ddedab7c53b5 upstream.

It doesn't seem this spinlock was properly initialized. This bug was
introduced by commit 7a410e8d4d97457c8c381e2de9cdc7bd3306badc.

Signed-off-by: Jean Delvare 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
---
 drivers/pcmcia/vrc4171_card.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/pcmcia/vrc4171_card.c
+++ b/drivers/pcmcia/vrc4171_card.c
@@ -246,6 +246,7 @@ static int pccard_init(struct pcmcia_soc
socket = _sockets[slot];
socket->csc_irq = search_nonuse_irq();
socket->io_irq = search_nonuse_irq();
+   spin_lock_init(>lock);
 
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/


[ 011/153] [PARISC] Purge existing TLB entries in set_pte_at and ptep_set_wrprotect

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: John David Anglin 

commit 7139bc1579901b53db7e898789e916ee2fb52d78 upstream.

This patch goes a long way toward fixing the minifail bug, and
it  significantly improves the stability of SMP machines such as
the rp3440.  When write  protecting a page for COW, we need to
purge the existing translation.  Otherwise, the COW break
doesn't occur as expected because the TLB may still have a stale entry
which allows writes.

[jejb: fix up checkpatch errors]
Signed-off-by: John David Anglin 
Signed-off-by: James Bottomley 
Signed-off-by: Ben Hutchings 
---
 arch/parisc/include/asm/pgtable.h |   13 ++---
 arch/parisc/kernel/cache.c|   18 ++
 2 files changed, 28 insertions(+), 3 deletions(-)

--- a/arch/parisc/include/asm/pgtable.h
+++ b/arch/parisc/include/asm/pgtable.h
@@ -12,11 +12,10 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
-struct vm_area_struct;
-
 /*
  * kern_addr_valid(ADDR) tests if ADDR is pointing to valid kernel
  * memory.  For the return value to be meaningful, ADDR must be >=
@@ -40,7 +39,14 @@ struct vm_area_struct;
 do{ \
 *(pteptr) = (pteval);   \
 } while(0)
-#define set_pte_at(mm,addr,ptep,pteval) set_pte(ptep,pteval)
+
+extern void purge_tlb_entries(struct mm_struct *, unsigned long);
+
+#define set_pte_at(mm, addr, ptep, pteval)  \
+   do {\
+   set_pte(ptep, pteval);  \
+   purge_tlb_entries(mm, addr);\
+   } while (0)
 
 #endif /* !__ASSEMBLY__ */
 
@@ -464,6 +470,7 @@ static inline void ptep_set_wrprotect(st
old = pte_val(*ptep);
new = pte_val(pte_wrprotect(__pte (old)));
} while (cmpxchg((unsigned long *) ptep, old, new) != old);
+   purge_tlb_entries(mm, addr);
 #else
pte_t old_pte = *ptep;
set_pte_at(mm, addr, ptep, pte_wrprotect(old_pte));
--- a/arch/parisc/kernel/cache.c
+++ b/arch/parisc/kernel/cache.c
@@ -421,6 +421,24 @@ void kunmap_parisc(void *addr)
 EXPORT_SYMBOL(kunmap_parisc);
 #endif
 
+void purge_tlb_entries(struct mm_struct *mm, unsigned long addr)
+{
+   unsigned long flags;
+
+   /* Note: purge_tlb_entries can be called at startup with
+  no context.  */
+
+   /* Disable preemption while we play with %sr1.  */
+   preempt_disable();
+   mtsp(mm->context, 1);
+   purge_tlb_start(flags);
+   pdtlb(addr);
+   pitlb(addr);
+   purge_tlb_end(flags);
+   preempt_enable();
+}
+EXPORT_SYMBOL(purge_tlb_entries);
+
 void __flush_tlb_range(unsigned long sid, unsigned long start,
   unsigned long 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/


[ 002/153] genirq: Avoid deadlock in spurious handling

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Thomas Gleixner 

commit e716efde75267eab919cdb2bef5b2cb77f305326 upstream.

commit 52553ddf(genirq: fix regression in irqfixup, irqpoll)
introduced a potential deadlock by calling the action handler with the
irq descriptor lock held.

Remove the call and let the handling code run even for an interrupt
where only a single action is registered. That matches the goal of
the above commit and avoids the deadlock.

Document the confusing action = desc->action reload in the handling
loop while at it.

Reported-and-tested-by: "Wang, Warner" 
Tested-by: Edward Donovan 
Cc: "Wang, Song-Bo (Stoney)" 
Signed-off-by: Thomas Gleixner 
Signed-off-by: Ben Hutchings 
---
 kernel/irq/spurious.c |7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

--- a/kernel/irq/spurious.c
+++ b/kernel/irq/spurious.c
@@ -80,13 +80,11 @@ static int try_one_irq(int irq, struct i
 
/*
 * All handlers must agree on IRQF_SHARED, so we test just the
-* first. Check for action->next as well.
+* first.
 */
action = desc->action;
if (!action || !(action->flags & IRQF_SHARED) ||
-   (action->flags & __IRQF_TIMER) ||
-   (action->handler(irq, action->dev_id) == IRQ_HANDLED) ||
-   !action->next)
+   (action->flags & __IRQF_TIMER))
goto out;
 
/* Already running on another processor */
@@ -104,6 +102,7 @@ static int try_one_irq(int irq, struct i
do {
if (handle_irq_event(desc) == IRQ_HANDLED)
ret = IRQ_HANDLED;
+   /* Make sure that there is still a valid action */
action = desc->action;
} while ((desc->istate & IRQS_PENDING) && action);
desc->istate &= ~IRQS_POLL_INPROGRESS;


--
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] perf: Expand definition of sysfs format attribute

2013-03-03 Thread Michael Ellerman
Make it explicit that the format attributes may define overlapping bit
ranges. Unfortunately this was left unspecified originally, and all the
examples show non-overlapping ranges. I don't believe this is an ABI
change, as we are defining something that was previously undefined, but
others may disagree.

The POWER8 PMU would like to define overlapping ranges, as bit ranges in
the event code have different meanings for certain events. It will also
allow us to define an overarching "event" field, that encompasses all
others.

As far as I can see perf is comfortable with this change, however I am
not sure if there are any other users of the interface.

Signed-off-by: Michael Ellerman 
---
 Documentation/ABI/testing/sysfs-bus-event_source-devices-format |6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-format 
b/Documentation/ABI/testing/sysfs-bus-event_source-devices-format
index 079afc7..77f47ff 100644
--- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-format
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-format
@@ -9,6 +9,12 @@ Description:
we want to export, so that userspace can deal with sane
name/value pairs.
 
+   Userspace must be prepared for the possibility that attributes
+   define overlapping bit ranges. For example:
+   attr1 = 'config:0-23'
+   attr2 = 'config:0-7'
+   attr3 = 'config:12-35'
+
Example: 'config1:1,6-10,44'
Defines contents of attribute that occupies bits 1,6-10,44 of
perf_event_attr::config1.
-- 
1.7.10.4

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


[ 017/153] staging: comedi: disallow COMEDI_DEVCONFIG on non-board minors

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Ian Abbott 

commit 754ab5c0e55dd118273ca2c217c4d95e9fbc8259 upstream.

Comedi has two sorts of minor devices:
(a) normal board minor devices in the range 0 to
COMEDI_NUM_BOARD_MINORS-1 inclusive; and
(b) special subdevice minor devices in the range COMEDI_NUM_BOARD_MINORS
upwards that are used to open the same underlying comedi device as the
normal board minor devices, but with non-default read and write
subdevices for asynchronous commands.

The special subdevice minor devices get created when a board supporting
asynchronous commands is attached to a normal board minor device, and
destroyed when the board is detached from the normal board minor device.
One way to attach or detach a board is by using the COMEDI_DEVCONFIG
ioctl.  This should only be used on normal board minors as the special
subdevice minors are too ephemeral.  In particular, the change
introduced in commit 7d3135af399e92cf4c9bbc5f86b6c140aab3b88c ("staging:
comedi: prevent auto-unconfig of manually configured devices") breaks
horribly for special subdevice minor devices.

Since there's no legitimate use for the COMEDI_DEVCONFIG ioctl on a
special subdevice minor device node, disallow it and return -ENOTTY.

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

--- a/drivers/staging/comedi/comedi_fops.c
+++ b/drivers/staging/comedi/comedi_fops.c
@@ -136,6 +136,11 @@ static long comedi_unlocked_ioctl(struct
/* Device config is special, because it must work on
 * an unconfigured device. */
if (cmd == COMEDI_DEVCONFIG) {
+   if (minor >= COMEDI_NUM_BOARD_MINORS) {
+   /* Device config not appropriate on non-board minors. */
+   rc = -ENOTTY;
+   goto done;
+   }
rc = do_devconfig_ioctl(dev,
(struct comedi_devconfig __user *)arg);
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/


[ 006/153] [media] omap_vout: find_vma() needs ->mmap_sem held

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Al Viro 

commit 55ee64b30a38d688232e5eb2860467dddc493573 upstream.

Walking rbtree while it's modified is a Bad Idea(tm); besides,
the result of find_vma() can be freed just as it's getting returned
to caller.  Fortunately, it's easy to fix - just take ->mmap_sem a bit
earlier (and don't bother with find_vma() at all if virtp >= PAGE_OFFSET -
in that case we don't even look at its result).

While we are at it, what prevents VIDIOC_PREPARE_BUF calling
v4l_prepare_buf() -> (e.g) vb2_ioctl_prepare_buf() -> vb2_prepare_buf() ->
__buf_prepare() -> __qbuf_userptr() -> vb2_vmalloc_get_userptr() -> find_vma(),
AFAICS without having taken ->mmap_sem anywhere in process?  The code flow
is bloody convoluted and depends on a bunch of things done by initialization,
so I certainly might've missed something...

Signed-off-by: Al Viro 
Cc: Sakari Ailus 
Cc: Laurent Pinchart 
Cc: Archit Taneja 
Cc: Prabhakar Lad 
Signed-off-by: Mauro Carvalho Chehab 
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings 
---
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -206,19 +206,21 @@ static u32 omap_vout_uservirt_to_phys(u3
struct vm_area_struct *vma;
struct mm_struct *mm = current->mm;
 
-   vma = find_vma(mm, virtp);
/* For kernel direct-mapped memory, take the easy way */
-   if (virtp >= PAGE_OFFSET) {
-   physp = virt_to_phys((void *) virtp);
-   } else if (vma && (vma->vm_flags & VM_IO) && vma->vm_pgoff) {
+   if (virtp >= PAGE_OFFSET)
+   return virt_to_phys((void *) virtp);
+
+   down_read(>mm->mmap_sem);
+   vma = find_vma(mm, virtp);
+   if (vma && (vma->vm_flags & VM_IO) && vma->vm_pgoff) {
/* this will catch, kernel-allocated, mmaped-to-usermode
   addresses */
physp = (vma->vm_pgoff << PAGE_SHIFT) + (virtp - vma->vm_start);
+   up_read(>mm->mmap_sem);
} else {
/* otherwise, use get_user_pages() for general userland pages */
int res, nr_pages = 1;
struct page *pages;
-   down_read(>mm->mmap_sem);
 
res = get_user_pages(current, current->mm, virtp, nr_pages, 1,
0, , 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/


Re: [PATCH RFC] arm: l2x0: Leverage power saving features

2013-03-03 Thread Will Deacon
Hello Soren,

On Fri, Mar 01, 2013 at 06:51:26PM +, Soren Brinkmann wrote:
> Enable the 'dynamic clock stop' and 'standby mode' features in the
> l2x0 disable path.
> 
> Signed-off-by: Soren Brinkmann 
> ---
> Hi,
> 
> we are currently implementing a suspend to RAM like low power mode for
> Zynq.
> The code for entering suspend looks like this:
>   outer_disable(); 
> cpu_suspend(0, zynq_pm_suspend); 
> outer_resume();
> 
> In our low power guidelines we mention the pl310's standby and clock stop
> feature and that they should be enabled for low power modes. The question
> arising here now is: Does the outer_disable() make these features redundant,
> or does it make sense to add it like shown in this patch?

The settings in the power control register are unrelated to CPU suspend
afaict. Instead, they are for semi-autonomous entry to non-destructive
low-power states (e.g. when the L2 is idle for n cycles, or all of the L1
masters have asserted WFI).

This raises the question of whether or not we should poke this register at
all (other than saving/restoring it across suspend, which *is* destructive).
I personally think that this stuff is better off being dealt with in
firmware and initialised there, which follows what we do for other registers
like this.

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


[ 014/153] quota: autoload the quota_v2 module for QFMT_VFS_V1 quota format

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Theodore Ts'o 

commit c3ad83d9efdfe6a86efd44945a781f00c879b7b4 upstream.

Otherwise, ext4 file systems with the quota featured enable will get a
very confusing "No such process" error message if the quota code is
built as a module and the quota_v2 module has not been loaded.

Signed-off-by: "Theodore Ts'o" 
Reviewed-by: Carlos Maiolino 
Acked-by: Jan Kara 
Signed-off-by: Ben Hutchings 
---
 include/linux/quota.h |1 +
 1 file changed, 1 insertion(+)

--- a/include/linux/quota.h
+++ b/include/linux/quota.h
@@ -413,6 +413,7 @@ struct quota_module_name {
 #define INIT_QUOTA_MODULE_NAMES {\
{QFMT_VFS_OLD, "quota_v1"},\
{QFMT_VFS_V0, "quota_v2"},\
+   {QFMT_VFS_V1, "quota_v2"},\
{0, NULL}}
 
 #endif /* __KERNEL__ */


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


[ 138/153] vhost: fix length for cross region descriptor

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: "Michael S. Tsirkin" 

commit bd97120fc3d1a11f3124c7c9ba1d91f51829eb85 upstream.

If a single descriptor crosses a region, the
second chunk length should be decremented
by size translated so far, instead it includes
the full descriptor length.

Signed-off-by: Michael S. Tsirkin 
Acked-by: Jason Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
---
 drivers/vhost/vhost.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -1073,7 +1073,7 @@ static int translate_desc(struct vhost_d
}
_iov = iov + ret;
size = reg->memory_size - addr + reg->guest_phys_addr;
-   _iov->iov_len = min((u64)len, size);
+   _iov->iov_len = min((u64)len - s, size);
_iov->iov_base = (void __user *)(unsigned long)
(reg->userspace_addr + addr - reg->guest_phys_addr);
s += size;


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


[ 143/153] asus-laptop: Do not call HWRS on init

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Ben Hutchings 

commit cb7da022450cdaaebd33078b6b32fb7dd2aaf6db upstream.

Since commit 8871e99f89b7 ('asus-laptop: HRWS/HWRS typo'), module
initialisation is very slow on the Asus UL30A.  The HWRS method takes
about 12 seconds to run, and subsequent initialisation also seems to
be delayed.  Since we don't really need the result, don't bother
calling it on init.  Those who are curious can still get the result
through the 'infos' device attribute.

Update the comment about HWRS in show_infos().

Reported-by: ryan 
References: http://bugs.debian.org/692436
Signed-off-by: Ben Hutchings 
Signed-off-by: Corentin Chary 
Signed-off-by: Matthew Garrett 
---
 drivers/platform/x86/asus-laptop.c |   17 -
 1 file changed, 4 insertions(+), 13 deletions(-)

--- a/drivers/platform/x86/asus-laptop.c
+++ b/drivers/platform/x86/asus-laptop.c
@@ -820,8 +820,10 @@ static ssize_t show_infos(struct device
/*
 * The HWRS method return informations about the hardware.
 * 0x80 bit is for WLAN, 0x100 for Bluetooth.
+* 0x40 for WWAN, 0x10 for WIMAX.
 * The significance of others is yet to be found.
-* If we don't find the method, we assume the device are present.
+* We don't currently use this for device detection, and it
+* takes several seconds to run on some systems.
 */
rv = acpi_evaluate_integer(asus->handle, "HWRS", NULL, );
if (!ACPI_FAILURE(rv))
@@ -1591,7 +1593,7 @@ static int asus_laptop_get_info(struct a
 {
struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
union acpi_object *model = NULL;
-   unsigned long long bsts_result, hwrs_result;
+   unsigned long long bsts_result;
char *string = NULL;
acpi_status status;
 
@@ -1653,17 +1655,6 @@ static int asus_laptop_get_info(struct a
if (*string)
pr_notice("  %s model detected\n", string);
 
-   /*
-* The HWRS method return informations about the hardware.
-* 0x80 bit is for WLAN, 0x100 for Bluetooth,
-* 0x40 for WWAN, 0x10 for WIMAX.
-* The significance of others is yet to be found.
-*/
-   status =
-   acpi_evaluate_integer(asus->handle, "HWRS", NULL, _result);
-   if (!ACPI_FAILURE(status))
-   pr_notice("  HWRS returned %x", (int)hwrs_result);
-
if (!acpi_check_handle(asus->handle, METHOD_WL_STATUS, NULL))
asus->have_rsts = true;
 


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


[ 142/153] speakup: lower default software speech rate

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Samuel Thibault 

commit cfd757010691eae4e17acc246f74e7622c3a2f05 upstream.

Speech synthesis beginners need a low speech rate, and trained people
want a high speech rate.  A medium speech rate is thus actually not a
good default for neither.  Since trained people will typically know how
to change the rate, better default for a low speech rate, which
beginners can grasp and learn how to increase it afterwards

This was agreed with users on the speakup mailing list.

Signed-off-by: Samuel Thibault 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
---
 drivers/staging/speakup/speakup_soft.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/speakup/speakup_soft.c 
b/drivers/staging/speakup/speakup_soft.c
index 42cdafe..2a67610 100644
--- a/drivers/staging/speakup/speakup_soft.c
+++ b/drivers/staging/speakup/speakup_soft.c
@@ -46,7 +46,7 @@ static int misc_registered;
 static struct var_t vars[] = {
{ CAPS_START, .u.s = {"\x01+3p" } },
{ CAPS_STOP, .u.s = {"\x01-3p" } },
-   { RATE, .u.n = {"\x01%ds", 5, 0, 9, 0, 0, NULL } },
+   { RATE, .u.n = {"\x01%ds", 2, 0, 9, 0, 0, NULL } },
{ PITCH, .u.n = {"\x01%dp", 5, 0, 9, 0, 0, NULL } },
{ VOL, .u.n = {"\x01%dv", 5, 0, 9, 0, 0, NULL } },
{ TONE, .u.n = {"\x01%dx", 1, 0, 2, 0, 0, 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/


[ 136/153] [media] Avoid sysfs oops when an rc_devs raw device is absent

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Douglas Bagnall 

commit 720bb6436ff30fccad05cf5bdf961ea5b1f5686d upstream.

For some reason, when the lirc daemon learns that a usb remote control
has been unplugged, it wants to read the sysfs attributes of the
disappearing device. This is useful for uncovering transient
inconsistencies, but less so for keeping the system running when such
inconsistencies exist.

Under some circumstances (like every time I unplug my dvb stick from
my laptop), lirc catches an rc_dev whose raw event handler has been
removed (presumably by ir_raw_event_unregister), and proceeds to
interrogate the raw protocols supported by the NULL pointer.

This patch avoids the NULL dereference, and ignores the issue of how
this state of affairs came about in the first place.

Version 2 incorporates changes recommended by Mauro Carvalho Chehab
(-ENODEV instead of -EINVAL, and a signed-off-by).

Signed-off-by: Douglas Bagnall 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Ben Hutchings 
---
 drivers/media/rc/rc-main.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -774,10 +774,11 @@ static ssize_t show_protocols(struct dev
if (dev->driver_type == RC_DRIVER_SCANCODE) {
enabled = dev->rc_map.rc_type;
allowed = dev->allowed_protos;
-   } else {
+   } else if (dev->raw) {
enabled = dev->raw->enabled_protocols;
allowed = ir_raw_get_allowed_protocols();
-   }
+   } else
+   return -ENODEV;
 
IR_dprintk(1, "allowed - 0x%llx, enabled - 0x%llx\n",
   (long long)allowed,


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


[ 007/153] dca: check against empty dca_domains list before unregister provider

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Maciej Sosnowski 

commit c419fcfd071cf34ba00f9f65282583772d2655e7 upstream.

When providers get blocked unregister_dca_providers() is called ending up
with dca_providers and dca_domain lists emptied. Dca should be prevented from
trying to unregister any provider if dca_domain list is found empty.

Reported-by: Jiang Liu 
Tested-by: Gaohuai Han 
Signed-off-by: Maciej Sosnowski 
Signed-off-by: Dan Williams 
Signed-off-by: Ben Hutchings 
---
 drivers/dca/dca-core.c |5 +
 1 file changed, 5 insertions(+)

--- a/drivers/dca/dca-core.c
+++ b/drivers/dca/dca-core.c
@@ -420,6 +420,11 @@ void unregister_dca_provider(struct dca_
 
raw_spin_lock_irqsave(_lock, flags);
 
+   if (list_empty(_domains)) {
+   raw_spin_unlock_irqrestore(_lock, flags);
+   return;
+   }
+
list_del(>node);
 
pci_rc = dca_pci_rc_from_dev(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/


[ 151/153] ext4: rewrite punch hole to use ext4_ext_remove_space()

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Lukas Czerner 

commit 5f95d21fb6f2aaa52830e5b7fb405f6c71d3ab85 upstream.

This commit rewrites ext4 punch hole implementation to use
ext4_ext_remove_space() instead of its home gown way of doing this via
ext4_ext_map_blocks(). There are several reasons for changing this.

Firstly it is quite non obvious that punching hole needs to
ext4_ext_map_blocks() to punch a hole, especially given that this
function should map blocks, not unmap it. It also required a lot of new
code in ext4_ext_map_blocks().

Secondly the design of it is not very effective. The reason is that we
are trying to punch out blocks in ext4_ext_punch_hole() in opposite
direction than in ext4_ext_rm_leaf() which causes the ext4_ext_rm_leaf()
to iterate through the whole tree from the end to the start to find the
requested extent for every extent we are going to punch out.

And finally the current implementation does not use the existing code,
but bring a lot of new code, which is IMO unnecessary since there
already is some infrastructure we can use. Specifically
ext4_ext_remove_space().

This commit changes ext4_ext_remove_space() to accept 'end' parameter so
we can not only truncate to the end of file, but also remove the space
in the middle of the file (punch a hole). Moreover, because the last
block to punch out, might be in the middle of the extent, we have to
split the extent at 'end + 1' so ext4_ext_rm_leaf() can easily either
remove the whole fist part of split extent, or change its size.

ext4_ext_remove_space() is then used to actually remove the space
(extents) from within the hole, instead of ext4_ext_map_blocks().

Note that this also fix the issue with punch hole, where we would forget
to remove empty index blocks from the extent tree, resulting in double
free block error and file system corruption. This is simply because we
now use different code path, where this problem does not exist.

This has been tested with fsx running for several days and xfstests,
plus xfstest #251 with '-o discard' run on the loop image (which
converts discard requestes into punch hole to the backing file). All of
it on 1K and 4K file system block size.

Signed-off-by: Lukas Czerner 
Signed-off-by: "Theodore Ts'o" 
[bwh: Backported to 3.2.y: move EXT4_EXT_DATA_VALID{1,2} along with the
 other extent splitting flags]
Signed-off-by: Ben Hutchings 
---
 fs/ext4/extents.c | 170 --
 1 file changed, 88 insertions(+), 82 deletions(-)

--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -45,6 +45,17 @@
 
 #include 
 
+/*
+ * used by extent splitting.
+ */
+#define EXT4_EXT_MAY_ZEROOUT   0x1  /* safe to zeroout if split fails \
+   due to ENOSPC */
+#define EXT4_EXT_MARK_UNINIT1  0x2  /* mark first half uninitialized */
+#define EXT4_EXT_MARK_UNINIT2  0x4  /* mark second half uninitialized */
+
+#define EXT4_EXT_DATA_VALID1   0x8  /* first half contains valid data */
+#define EXT4_EXT_DATA_VALID2   0x10 /* second half contains valid data */
+
 static int ext4_split_extent(handle_t *handle,
struct inode *inode,
struct ext4_ext_path *path,
@@ -52,6 +63,13 @@ static int ext4_split_extent(handle_t *h
int split_flag,
int flags);
 
+static int ext4_split_extent_at(handle_t *handle,
+struct inode *inode,
+struct ext4_ext_path *path,
+ext4_lblk_t split,
+int split_flag,
+int flags);
+
 static int ext4_ext_truncate_extend_restart(handle_t *handle,
struct inode *inode,
int needed)
@@ -2324,7 +2342,7 @@ ext4_ext_rm_leaf(handle_t *handle, struc
struct ext4_extent *ex;
 
/* the header must be checked already in ext4_ext_remove_space() */
-   ext_debug("truncate since %u in leaf\n", start);
+   ext_debug("truncate since %u in leaf to %u\n", start, end);
if (!path[depth].p_hdr)
path[depth].p_hdr = ext_block_hdr(path[depth].p_bh);
eh = path[depth].p_hdr;
@@ -2359,7 +2377,7 @@ ext4_ext_rm_leaf(handle_t *handle, struc
ext_debug("  border %u:%u\n", a, b);
 
/* If this extent is beyond the end of the hole, skip it */
-   if (end <= ex_ee_block) {
+   if (end < ex_ee_block) {
ex--;
ex_ee_block = le32_to_cpu(ex->ee_block);
ex_ee_len = ext4_ext_get_actual_len(ex);
@@ -2498,7 +2516,8 @@ ext4_ext_more_to_rm(struct ext4_ext_path
return 1;
 }
 
-static int ext4_ext_remove_space(struct inode *inode, ext4_lblk_t start)
+static int ext4_ext_remove_space(struct inode 

[ 149/153] exec: use -ELOOP for max recursion depth

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Kees Cook 

commit d740269867021faf4ce38a449353d2b986c34a67 upstream.

To avoid an explosion of request_module calls on a chain of abusive
scripts, fail maximum recursion with -ELOOP instead of -ENOEXEC. As soon
as maximum recursion depth is hit, the error will fail all the way back
up the chain, aborting immediately.

This also has the side-effect of stopping the user's shell from attempting
to reexecute the top-level file as a shell script. As seen in the
dash source:

if (cmd != path_bshell && errno == ENOEXEC) {
*argv-- = cmd;
*argv = cmd = path_bshell;
goto repeat;
}

The above logic was designed for running scripts automatically that lacked
the "#!" header, not to re-try failed recursion. On a legitimate -ENOEXEC,
things continue to behave as the shell expects.

Additionally, when tracking recursion, the binfmt handlers should not be
involved. The recursion being tracked is the depth of calls through
search_binary_handler(), so that function should be exclusively responsible
for tracking the depth.

Signed-off-by: Kees Cook 
Cc: halfdog 
Cc: P J P 
Cc: Alexander Viro 
Signed-off-by: Andrew Morton 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings 
---
 fs/binfmt_em86.c|1 -
 fs/binfmt_misc.c|6 --
 fs/binfmt_script.c  |4 +---
 fs/exec.c   |   10 +-
 include/linux/binfmts.h |2 --
 5 files changed, 6 insertions(+), 17 deletions(-)

--- a/fs/binfmt_em86.c
+++ b/fs/binfmt_em86.c
@@ -42,7 +42,6 @@ static int load_em86(struct linux_binprm
return -ENOEXEC;
}
 
-   bprm->recursion_depth++; /* Well, the bang-shell is implicit... */
allow_write_access(bprm->file);
fput(bprm->file);
bprm->file = NULL;
--- a/fs/binfmt_misc.c
+++ b/fs/binfmt_misc.c
@@ -116,10 +116,6 @@ static int load_misc_binary(struct linux
if (!enabled)
goto _ret;
 
-   retval = -ENOEXEC;
-   if (bprm->recursion_depth > BINPRM_MAX_RECURSION)
-   goto _ret;
-
/* to keep locking time low, we copy the interpreter string */
read_lock(_lock);
fmt = check_file(bprm);
@@ -199,8 +195,6 @@ static int load_misc_binary(struct linux
if (retval < 0)
goto _error;
 
-   bprm->recursion_depth++;
-
retval = search_binary_handler (bprm, regs);
if (retval < 0)
goto _error;
--- a/fs/binfmt_script.c
+++ b/fs/binfmt_script.c
@@ -22,15 +22,13 @@ static int load_script(struct linux_binp
char interp[BINPRM_BUF_SIZE];
int retval;
 
-   if ((bprm->buf[0] != '#') || (bprm->buf[1] != '!') ||
-   (bprm->recursion_depth > BINPRM_MAX_RECURSION))
+   if ((bprm->buf[0] != '#') || (bprm->buf[1] != '!'))
return -ENOEXEC;
/*
 * This section does the #! interpretation.
 * Sorta complicated, but hopefully it will work.  -TYT
 */
 
-   bprm->recursion_depth++;
allow_write_access(bprm->file);
fput(bprm->file);
bprm->file = NULL;
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1385,6 +1385,10 @@ int search_binary_handler(struct linux_b
struct linux_binfmt *fmt;
pid_t old_pid;
 
+   /* This allows 4 levels of binfmt rewrites before failing hard. */
+   if (depth > 5)
+   return -ELOOP;
+
retval = security_bprm_check(bprm);
if (retval)
return retval;
@@ -1408,12 +1412,8 @@ int search_binary_handler(struct linux_b
if (!try_module_get(fmt->module))
continue;
read_unlock(_lock);
+   bprm->recursion_depth = depth + 1;
retval = fn(bprm, regs);
-   /*
-* Restore the depth counter to its starting value
-* in this call, so we don't have to rely on every
-* load_binary function to restore it on return.
-*/
bprm->recursion_depth = depth;
if (retval >= 0) {
if (depth == 0)
--- a/include/linux/binfmts.h
+++ b/include/linux/binfmts.h
@@ -67,8 +67,6 @@ struct linux_binprm {
 #define BINPRM_FLAGS_EXECFD_BIT 1
 #define BINPRM_FLAGS_EXECFD (1 << BINPRM_FLAGS_EXECFD_BIT)
 
-#define BINPRM_MAX_RECURSION 4
-
 /* Function parameter for binfmt->coredump */
 struct coredump_params {
long signr;


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


[ 016/153] s390/kvm: Fix store status for ACRS/FPRS

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Christian Borntraeger 

commit 15bc8d8457875f495c59d933b05770ba88d1eacb upstream.

On store status we need to copy the current state of registers
into a save area. Currently we might save stale versions:
The sie state descriptor doesnt have fields for guest ACRS,FPRS,
those registers are simply stored in the host registers. The host
program must copy these away if needed. We do that in vcpu_put/load.

If we now do a store status in KVM code between vcpu_put/load, the
saved values are not up-to-date. Lets collect the ACRS/FPRS before
saving them.

This also fixes some strange problems with hotplug and virtio-ccw,
since the low level machine check handler (on hotplug a machine check
will happen) will revalidate all registers with the content of the
save area.

Signed-off-by: Christian Borntraeger 
Signed-off-by: Gleb Natapov 
[bwh: Backported to 3.2 as done in 3.0 by Jiri Slaby]
Signed-off-by: Ben Hutchings 
Cc: Jiri Slaby 
---
 arch/s390/kvm/kvm-s390.c |8 
 1 file changed, 8 insertions(+)

--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -597,6 +597,14 @@ int kvm_s390_vcpu_store_status(struct kv
} else
prefix = 0;
 
+   /*
+* The guest FPRS and ACRS are in the host FPRS/ACRS due to the lazy
+* copying in vcpu load/put. Lets update our copies before we save
+* it into the save area
+*/
+   save_fp_regs(>arch.guest_fpregs);
+   save_access_regs(vcpu->arch.guest_acrs);
+
if (__guestcopy(vcpu, addr + offsetof(struct save_area, fp_regs),
vcpu->arch.guest_fpregs.fprs, 128, prefix))
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/


[ 012/153] ARM: PXA3xx: program the CSMSADRCFG register

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Igor Grinberg 

commit d107a204154ddd79339203c2deeb7433f0cf6777 upstream.

The Chip Select Configuration Register must be programmed to 0x2 in
order to achieve the correct behavior of the Static Memory Controller.

Without this patch devices wired to DFI and accessed through SMC cannot
be accessed after resume from S2.

Do not rely on the boot loader to program the CSMSADRCFG register by
programming it in the kernel smemc module.

Signed-off-by: Igor Grinberg 
Acked-by: Eric Miao 
Signed-off-by: Haojian Zhuang 
Signed-off-by: Ben Hutchings 
---
 arch/arm/mach-pxa/include/mach/smemc.h |1 +
 arch/arm/mach-pxa/smemc.c  |   15 ++-
 2 files changed, 15 insertions(+), 1 deletion(-)

--- a/arch/arm/mach-pxa/include/mach/smemc.h
+++ b/arch/arm/mach-pxa/include/mach/smemc.h
@@ -37,6 +37,7 @@
 #define CSADRCFG1  (SMEMC_VIRT + 0x84)  /* Address Configuration Register 
for CS1 */
 #define CSADRCFG2  (SMEMC_VIRT + 0x88)  /* Address Configuration Register 
for CS2 */
 #define CSADRCFG3  (SMEMC_VIRT + 0x8C)  /* Address Configuration Register 
for CS3 */
+#define CSMSADRCFG (SMEMC_VIRT + 0xA0)  /* Chip Select Configuration 
Register */
 
 /*
  * More handy macros for PCMCIA
--- a/arch/arm/mach-pxa/smemc.c
+++ b/arch/arm/mach-pxa/smemc.c
@@ -40,6 +40,8 @@ static void pxa3xx_smemc_resume(void)
__raw_writel(csadrcfg[1], CSADRCFG1);
__raw_writel(csadrcfg[2], CSADRCFG2);
__raw_writel(csadrcfg[3], CSADRCFG3);
+   /* CSMSADRCFG wakes up in its default state (0), so we need to set it */
+   __raw_writel(0x2, CSMSADRCFG);
 }
 
 static struct syscore_ops smemc_syscore_ops = {
@@ -49,8 +51,19 @@ static struct syscore_ops smemc_syscore_
 
 static int __init smemc_init(void)
 {
-   if (cpu_is_pxa3xx())
+   if (cpu_is_pxa3xx()) {
+   /*
+* The only documentation we have on the
+* Chip Select Configuration Register (CSMSADRCFG) is that
+* it must be programmed to 0x2.
+* Moreover, in the bit definitions, the second bit
+* (CSMSADRCFG[1]) is called "SETALWAYS".
+* Other bits are reserved in this register.
+*/
+   __raw_writel(0x2, CSMSADRCFG);
+
register_syscore_ops(_syscore_ops);
+   }
 
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/


[ 139/153] 8250: use correct value for PORT_BRCM_TRUMANAGE

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Ben Hutchings 

When backporting commit ebebd49a8eab ('8250/16?50: Add support for
Broadcom TruManage redirected serial port') I took the next
available port type number for PORT_BRCM_TRUMANAGE (22).

However, the 8250 port type numbers are exposed to userland through
the TIOC{G,S}SERIAL ioctls and so must remain stable.  Redefine
PORT_BRCM_TRUMANAGE as 25, matching mainline as of commit
85f024401bf807.

This leaves port types 22-24 within the valid range for 8250 but not
implemented there.  Change serial8250_verify_port() to specifically
reject these and change serial8250_type() to return "unknown" for them
(though I'm not sure why it would ever see them).

Signed-off-by: Ben Hutchings 
---
--- a/drivers/tty/serial/8250.c
+++ b/drivers/tty/serial/8250.c
@@ -2695,7 +2695,7 @@ serial8250_verify_port(struct uart_port
if (ser->irq >= nr_irqs || ser->irq < 0 ||
ser->baud_base < 9600 || ser->type < PORT_UNKNOWN ||
ser->type >= ARRAY_SIZE(uart_config) || ser->type == PORT_CIRRUS ||
-   ser->type == PORT_STARTECH)
+   ser->type == PORT_STARTECH || uart_config[ser->type].name == NULL)
return -EINVAL;
return 0;
 }
@@ -2705,7 +2705,7 @@ serial8250_type(struct uart_port *port)
 {
int type = port->type;
 
-   if (type >= ARRAY_SIZE(uart_config))
+   if (type >= ARRAY_SIZE(uart_config) || uart_config[type].name == NULL)
type = 0;
return uart_config[type].name;
 }
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -47,8 +47,8 @@
 #define PORT_U6_16550A 19  /* ST-Ericsson U6xxx internal UART */
 #define PORT_TEGRA 20  /* NVIDIA Tegra internal UART */
 #define PORT_XR17D15X  21  /* Exar XR17D15x UART */
-#define PORT_BRCM_TRUMANAGE22
-#define PORT_MAX_8250  22  /* max port ID */
+#define PORT_BRCM_TRUMANAGE25
+#define PORT_MAX_8250  25  /* max port ID */
 
 /*
  * ARM specific type numbers.  These are not currently guaranteed


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


[ 003/153] KVM: s390: Handle hosts not supporting s390-virtio.

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Cornelia Huck 

commit 55c171a6d90dc0574021f9c836127cfd1a7d2e30 upstream.

Running under a kvm host does not necessarily imply the presence of
a page mapped above the main memory with the virtio information;
however, the code includes a hard coded access to that page.

Instead, check for the presence of the page and exit gracefully
before we hit an addressing exception if it does not exist.

Reviewed-by: Marcelo Tosatti 
Reviewed-by: Alexander Graf 
Signed-off-by: Cornelia Huck 
Signed-off-by: Gleb Natapov 
Signed-off-by: Ben Hutchings 
---
 drivers/s390/kvm/kvm_virtio.c |   38 ++
 1 file changed, 30 insertions(+), 8 deletions(-)

--- a/drivers/s390/kvm/kvm_virtio.c
+++ b/drivers/s390/kvm/kvm_virtio.c
@@ -414,6 +414,26 @@ static void kvm_extint_handler(unsigned
 }
 
 /*
+ * For s390-virtio, we expect a page above main storage containing
+ * the virtio configuration. Try to actually load from this area
+ * in order to figure out if the host provides this page.
+ */
+static int __init test_devices_support(unsigned long addr)
+{
+   int ret = -EIO;
+
+   asm volatile(
+   "0: lura0,%1\n"
+   "1: xgr %0,%0\n"
+   "2:\n"
+   EX_TABLE(0b,2b)
+   EX_TABLE(1b,2b)
+   : "+d" (ret)
+   : "a" (addr)
+   : "0", "cc");
+   return ret;
+}
+/*
  * Init function for virtio
  * devices are in a single page above top of "normal" mem
  */
@@ -424,21 +444,23 @@ static int __init kvm_devices_init(void)
if (!MACHINE_IS_KVM)
return -ENODEV;
 
+   if (test_devices_support(real_memory_size) < 0)
+   return -ENODEV;
+
+   rc = vmem_add_mapping(real_memory_size, PAGE_SIZE);
+   if (rc)
+   return rc;
+
+   kvm_devices = (void *) real_memory_size;
+
kvm_root = root_device_register("kvm_s390");
if (IS_ERR(kvm_root)) {
rc = PTR_ERR(kvm_root);
printk(KERN_ERR "Could not register kvm_s390 root device");
+   vmem_remove_mapping(real_memory_size, PAGE_SIZE);
return rc;
}
 
-   rc = vmem_add_mapping(real_memory_size, PAGE_SIZE);
-   if (rc) {
-   root_device_unregister(kvm_root);
-   return rc;
-   }
-
-   kvm_devices = (void *) real_memory_size;
-
INIT_WORK(_work, hotplug_devices);
 
service_subclass_irq_register();


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


[ 015/153] ext4: fix possible use-after-free with AIO

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Jan Kara 

commit 091e26dfc156aeb3b73bc5c5f277e433ad39331c upstream.

Running AIO is pinning inode in memory using file reference. Once AIO
is completed using aio_complete(), file reference is put and inode can
be freed from memory. So we have to be sure that calling aio_complete()
is the last thing we do with the inode.

Reviewed-by: Carlos Maiolino 
Acked-by: Jeff Moyer 
Signed-off-by: Jan Kara 
Signed-off-by: "Theodore Ts'o" 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings 
---
 fs/ext4/inode.c   |2 +-
 fs/ext4/page-io.c |9 -
 2 files changed, 5 insertions(+), 6 deletions(-)

--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -2795,9 +2795,9 @@ static void ext4_end_io_dio(struct kiocb
if (!(io_end->flag & EXT4_IO_END_UNWRITTEN)) {
ext4_free_io_end(io_end);
 out:
+   inode_dio_done(inode);
if (is_async)
aio_complete(iocb, ret, 0);
-   inode_dio_done(inode);
return;
}
 
--- a/fs/ext4/page-io.c
+++ b/fs/ext4/page-io.c
@@ -108,14 +108,13 @@ int ext4_end_io_nolock(ext4_io_end_t *io
 inode->i_ino, offset, size, ret);
}
 
-   if (io->iocb)
-   aio_complete(io->iocb, io->result, 0);
-
-   if (io->flag & EXT4_IO_END_DIRECT)
-   inode_dio_done(inode);
/* Wake up anyone waiting on unwritten extent conversion */
if (atomic_dec_and_test(_I(inode)->i_aiodio_unwritten))
wake_up_all(ext4_ioend_wq(io->inode));
+   if (io->flag & EXT4_IO_END_DIRECT)
+   inode_dio_done(inode);
+   if (io->iocb)
+   aio_complete(io->iocb, io->result, 0);
return ret;
 }
 


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


[ 005/153] [media] v4l: Reset subdev v4l2_dev field to NULL if registration fails

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Laurent Pinchart 

commit 317efce991620adc589b3005b9baed433dcb2a56 upstream.

When subdev registration fails the subdev v4l2_dev field is left to a
non-NULL value. Later calls to v4l2_device_unregister_subdev() will
consider the subdev as registered and will module_put() the subdev
module without any matching module_get().
Fix this by setting the subdev v4l2_dev field to NULL in
v4l2_device_register_subdev() when the function fails.

Signed-off-by: Laurent Pinchart 
Acked-by: Sylwester Nawrocki 
Signed-off-by: Mauro Carvalho Chehab 
[bwh: Backported to 3.2: adjust context, filename]
Signed-off-by: Ben Hutchings 
---
--- a/drivers/media/video/v4l2-device.c
+++ b/drivers/media/video/v4l2-device.c
@@ -159,31 +159,21 @@ int v4l2_device_register_subdev(struct v
sd->v4l2_dev = v4l2_dev;
if (sd->internal_ops && sd->internal_ops->registered) {
err = sd->internal_ops->registered(sd);
-   if (err) {
-   module_put(sd->owner);
-   return err;
-   }
+   if (err)
+   goto error_module;
}
 
/* This just returns 0 if either of the two args is NULL */
err = v4l2_ctrl_add_handler(v4l2_dev->ctrl_handler, sd->ctrl_handler);
-   if (err) {
-   if (sd->internal_ops && sd->internal_ops->unregistered)
-   sd->internal_ops->unregistered(sd);
-   module_put(sd->owner);
-   return err;
-   }
+   if (err)
+   goto error_unregister;
 
 #if defined(CONFIG_MEDIA_CONTROLLER)
/* Register the entity. */
if (v4l2_dev->mdev) {
err = media_device_register_entity(v4l2_dev->mdev, entity);
-   if (err < 0) {
-   if (sd->internal_ops && sd->internal_ops->unregistered)
-   sd->internal_ops->unregistered(sd);
-   module_put(sd->owner);
-   return err;
-   }
+   if (err < 0)
+   goto error_unregister;
}
 #endif
 
@@ -192,6 +182,14 @@ int v4l2_device_register_subdev(struct v
spin_unlock(_dev->lock);
 
return 0;
+
+error_unregister:
+   if (sd->internal_ops && sd->internal_ops->unregistered)
+   sd->internal_ops->unregistered(sd);
+error_module:
+   module_put(sd->owner);
+   sd->v4l2_dev = NULL;
+   return err;
 }
 EXPORT_SYMBOL_GPL(v4l2_device_register_subdev);
 


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


[ 001/153] sunvdc: Fix off-by-one in generic_request().

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: "David S. Miller" 

[ Upstream commit f4d9605434c0fd4cc8639bf25cfc043418c52362 ]

The 'operations' bitmap corresponds one-for-one with the operation
codes, no adjustment is necessary.

Reported-by: Mark Kettenis 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
---
 drivers/block/sunvdc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/block/sunvdc.c
+++ b/drivers/block/sunvdc.c
@@ -461,7 +461,7 @@ static int generic_request(struct vdc_po
int op_len, err;
void *req_buf;
 
-   if (!(((u64)1 << ((u64)op - 1)) & port->operations))
+   if (!(((u64)1 << (u64)op) & port->operations))
return -EOPNOTSUPP;
 
switch (op) {


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


[ 009/153] ext4: return ENOMEM if sb_getblk() fails

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Theodore Ts'o 

commit 860d21e2c585f7ee8a4ecc06f474fdc33c9474f4 upstream.

The only reason for sb_getblk() failing is if it can't allocate the
buffer_head.  So ENOMEM is more appropriate than EIO.  In addition,
make sure that the file system is marked as being inconsistent if
sb_getblk() fails.

Signed-off-by: "Theodore Ts'o" 
[bwh: Backported to 3.2:
 - Adjust context
 - Drop change to inline.c
 - Call to ext4_ext_check() from ext4_ext_find_extent() is conditional]
Signed-off-by: Ben Hutchings 
---
 fs/ext4/extents.c  |   25 ++---
 fs/ext4/indirect.c |9 ++---
 fs/ext4/inline.c   |2 +-
 fs/ext4/inode.c|9 +++--
 fs/ext4/mmp.c  |2 ++
 fs/ext4/resize.c   |8 
 fs/ext4/xattr.c|3 ++-
 7 files changed, 32 insertions(+), 26 deletions(-)

--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -636,6 +636,7 @@ ext4_ext_find_extent(struct inode *inode
struct ext4_extent_header *eh;
struct buffer_head *bh;
short int depth, i, ppos = 0, alloc = 0;
+   int ret;
 
eh = ext_inode_hdr(inode);
depth = ext_depth(inode);
@@ -665,12 +666,15 @@ ext4_ext_find_extent(struct inode *inode
path[ppos].p_ext = NULL;
 
bh = sb_getblk(inode->i_sb, path[ppos].p_block);
-   if (unlikely(!bh))
+   if (unlikely(!bh)) {
+   ret = -ENOMEM;
goto err;
+   }
if (!bh_uptodate_or_lock(bh)) {
trace_ext4_ext_load_extent(inode, block,
path[ppos].p_block);
-   if (bh_submit_read(bh) < 0) {
+   ret = bh_submit_read(bh);
+   if (ret < 0) {
put_bh(bh);
goto err;
}
@@ -683,13 +687,15 @@ ext4_ext_find_extent(struct inode *inode
put_bh(bh);
EXT4_ERROR_INODE(inode,
 "ppos %d > depth %d", ppos, depth);
+   ret = -EIO;
goto err;
}
path[ppos].p_bh = bh;
path[ppos].p_hdr = eh;
i--;
 
-   if (need_to_validate && ext4_ext_check(inode, eh, i))
+   ret = need_to_validate ? ext4_ext_check(inode, eh, i) : 0;
+   if (ret < 0)
goto err;
}
 
@@ -711,7 +717,7 @@ err:
ext4_ext_drop_refs(path);
if (alloc)
kfree(path);
-   return ERR_PTR(-EIO);
+   return ERR_PTR(ret);
 }
 
 /*
@@ -866,7 +872,7 @@ static int ext4_ext_split(handle_t *hand
}
bh = sb_getblk(inode->i_sb, newblock);
if (!bh) {
-   err = -EIO;
+   err = -ENOMEM;
goto cleanup;
}
lock_buffer(bh);
@@ -938,7 +944,7 @@ static int ext4_ext_split(handle_t *hand
newblock = ablocks[--a];
bh = sb_getblk(inode->i_sb, newblock);
if (!bh) {
-   err = -EIO;
+   err = -ENOMEM;
goto cleanup;
}
lock_buffer(bh);
@@ -1049,11 +1055,8 @@ static int ext4_ext_grow_indepth(handle_
return err;
 
bh = sb_getblk(inode->i_sb, newblock);
-   if (!bh) {
-   err = -EIO;
-   ext4_std_error(inode->i_sb, err);
-   return err;
-   }
+   if (!bh)
+   return -ENOMEM;
lock_buffer(bh);
 
err = ext4_journal_get_create_access(handle, bh);
--- a/fs/ext4/indirect.c
+++ b/fs/ext4/indirect.c
@@ -146,6 +146,7 @@ static Indirect *ext4_get_branch(struct
struct super_block *sb = inode->i_sb;
Indirect *p = chain;
struct buffer_head *bh;
+   int ret = -EIO;
 
*err = 0;
/* i_data is not going away, no lock needed */
@@ -154,8 +155,10 @@ static Indirect *ext4_get_branch(struct
goto no_block;
while (--depth) {
bh = sb_getblk(sb, le32_to_cpu(p->key));
-   if (unlikely(!bh))
+   if (unlikely(!bh)) {
+   ret = -ENOMEM;
goto failure;
+   }
 
if (!bh_uptodate_or_lock(bh)) {
if (bh_submit_read(bh) < 0) {
@@ -177,7 +180,7 @@ static Indirect *ext4_get_branch(struct
return NULL;
 
 failure:
-   *err = -EIO;
+   *err = ret;
 no_block:
return p;
 }
@@ -471,7 +474,7 @@ static int ext4_alloc_branch(handle_t *h
 */
bh = sb_getblk(inode->i_sb, new_blocks[n-1]);
if (unlikely(!bh)) {
-   err = -EIO;
+   

[ 019/153] x86-32, mm: Rip out x86_32 NUMA remapping code

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Dave Hansen 

commit f03574f2d5b2d6229dcdf2d322848065f72953c7 upstream.

This code was an optimization for 32-bit NUMA systems.

It has probably been the cause of a number of subtle bugs over
the years, although the conditions to excite them would have
been hard to trigger.  Essentially, we remap part of the kernel
linear mapping area, and then sometimes part of that area gets
freed back in to the bootmem allocator.  If those pages get
used by kernel data structures (say mem_map[] or a dentry),
there's no big deal.  But, if anyone ever tried to use the
linear mapping for these pages _and_ cared about their physical
address, bad things happen.

For instance, say you passed __GFP_ZERO to the page allocator
and then happened to get handed one of these pages, it zero the
remapped page, but it would make a pte to the _old_ page.
There are probably a hundred other ways that it could screw
with things.

We don't need to hang on to performance optimizations for
these old boxes any more.  All my 32-bit NUMA systems are long
dead and buried, and I probably had access to more than most
people.

This code is causing real things to break today:

https://lkml.org/lkml/2013/1/9/376

I looked in to actually fixing this, but it requires surgery
to way too much brittle code, as well as stuff like
per_cpu_ptr_to_phys().

[ hpa: Cc: this for -stable, since it is a memory corruption issue.
  However, an alternative is to simply mark NUMA as depends BROKEN
  rather than EXPERIMENTAL in the X86_32 subclause... ]

Link: http://lkml.kernel.org/r/20130131005616.1c79f...@kernel.stglabs.ibm.com
Signed-off-by: H. Peter Anvin 
[bwh: For 3.2, using the suggested alternative]
Signed-off-by: Ben Hutchings 
---

--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1150,7 +1150,7 @@ config DIRECT_GBPAGES
 config NUMA
bool "Numa Memory Allocation and Scheduler Support"
depends on SMP
-   depends on X86_64 || (X86_32 && HIGHMEM64G && (X86_NUMAQ || X86_BIGSMP 
|| X86_SUMMIT && ACPI) && EXPERIMENTAL)
+   depends on X86_64 || (X86_32 && HIGHMEM64G && (X86_NUMAQ || X86_BIGSMP 
|| X86_SUMMIT && ACPI) && BROKEN)
default y if (X86_NUMAQ || X86_SUMMIT || X86_BIGSMP)
---help---
  Enable NUMA (Non Uniform Memory Access) support.


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


[ 150/153] fs: cachefiles: add support for large files in filesystem caching

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Justin Lecher 

commit 98c350cda2c14a343d34ea01a3d9c24fea5ec66d upstream.

Support the caching of large files.

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

Signed-off-by: Justin Lecher 
Signed-off-by: Suresh Jayaraman 
Tested-by: Suresh Jayaraman 
Acked-by: David Howells 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[bwh: Backported to 3.2: 
 - Adjust context
 - dentry_open() takes dentry and vfsmount pointers, not a path pointer]
Signed-off-by: Ben Hutchings 
---
--- a/fs/cachefiles/rdwr.c
+++ b/fs/cachefiles/rdwr.c
@@ -918,7 +918,7 @@ int cachefiles_write_page(struct fscache_storage *op, 
struct page *page)
 * own time */
dget(object->backer);
mntget(cache->mnt);
-   file = dentry_open(object->backer, cache->mnt, O_RDWR,
+   file = dentry_open(object->backer, cache->mnt, O_RDWR | O_LARGEFILE,
   cache->cache_cred);
if (IS_ERR(file)) {
ret = PTR_ERR(file);



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


[ 141/153] usb: Add USB_QUIRK_RESET_RESUME for all Logitech UVC webcams

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Laurent Pinchart 

commit e387ef5c47ddeaeaa3cbdc54424cdb7a28dae2c0 upstream.

Most Logitech UVC webcams (both early models that don't advertise UVC
compatibility and newer UVC-advertised devices) require the RESET_RESUME
quirk. Instead of listing each and every model, match the devices based
on the UVC interface information.

Signed-off-by: Laurent Pinchart 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Adjust context to apply after 3.2.38]
Signed-off-by: Ben Hutchings 
---
 drivers/usb/core/quirks.c |   58 +
 1 file changed, 16 insertions(+), 42 deletions(-)

--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -46,53 +46,23 @@ static const struct usb_device_id usb_qu
/* Microsoft LifeCam-VX700 v2.0 */
{ USB_DEVICE(0x045e, 0x0770), .driver_info = USB_QUIRK_RESET_RESUME },
 
-   /* Logitech Webcam C200 */
-   { USB_DEVICE(0x046d, 0x0802), .driver_info = USB_QUIRK_RESET_RESUME },
+   /* Logitech Quickcam Fusion */
+   { USB_DEVICE(0x046d, 0x08c1), .driver_info = USB_QUIRK_RESET_RESUME },
 
-   /* Logitech Webcam C250 */
-   { USB_DEVICE(0x046d, 0x0804), .driver_info = USB_QUIRK_RESET_RESUME },
+   /* Logitech Quickcam Orbit MP */
+   { USB_DEVICE(0x046d, 0x08c2), .driver_info = USB_QUIRK_RESET_RESUME },
 
-   /* Logitech Webcam C300 */
-   { USB_DEVICE(0x046d, 0x0805), .driver_info = USB_QUIRK_RESET_RESUME },
+   /* Logitech Quickcam Pro for Notebook */
+   { USB_DEVICE(0x046d, 0x08c3), .driver_info = USB_QUIRK_RESET_RESUME },
 
-   /* Logitech Webcam B/C500 */
-   { USB_DEVICE(0x046d, 0x0807), .driver_info = USB_QUIRK_RESET_RESUME },
+   /* Logitech Quickcam Pro 5000 */
+   { USB_DEVICE(0x046d, 0x08c5), .driver_info = USB_QUIRK_RESET_RESUME },
 
-   /* Logitech Webcam C600 */
-   { USB_DEVICE(0x046d, 0x0808), .driver_info = USB_QUIRK_RESET_RESUME },
+   /* Logitech Quickcam OEM Dell Notebook */
+   { USB_DEVICE(0x046d, 0x08c6), .driver_info = USB_QUIRK_RESET_RESUME },
 
-   /* Logitech Webcam Pro 9000 */
-   { USB_DEVICE(0x046d, 0x0809), .driver_info = USB_QUIRK_RESET_RESUME },
-
-   /* Logitech Webcam C905 */
-   { USB_DEVICE(0x046d, 0x080a), .driver_info = USB_QUIRK_RESET_RESUME },
-
-   /* Logitech Webcam C210 */
-   { USB_DEVICE(0x046d, 0x0819), .driver_info = USB_QUIRK_RESET_RESUME },
-
-   /* Logitech Webcam C260 */
-   { USB_DEVICE(0x046d, 0x081a), .driver_info = USB_QUIRK_RESET_RESUME },
-
-   /* Logitech Webcam C310 */
-   { USB_DEVICE(0x046d, 0x081b), .driver_info = USB_QUIRK_RESET_RESUME },
-
-   /* Logitech Webcam C910 */
-   { USB_DEVICE(0x046d, 0x0821), .driver_info = USB_QUIRK_RESET_RESUME },
-
-   /* Logitech Webcam C160 */
-   { USB_DEVICE(0x046d, 0x0824), .driver_info = USB_QUIRK_RESET_RESUME },
-
-   /* Logitech Webcam C270 */
-   { USB_DEVICE(0x046d, 0x0825), .driver_info = USB_QUIRK_RESET_RESUME },
-
-   /* Logitech Quickcam Pro 9000 */
-   { USB_DEVICE(0x046d, 0x0990), .driver_info = USB_QUIRK_RESET_RESUME },
-
-   /* Logitech Quickcam E3500 */
-   { USB_DEVICE(0x046d, 0x09a4), .driver_info = USB_QUIRK_RESET_RESUME },
-
-   /* Logitech Quickcam Vision Pro */
-   { USB_DEVICE(0x046d, 0x09a6), .driver_info = USB_QUIRK_RESET_RESUME },
+   /* Logitech Quickcam OEM Cisco VT Camera II */
+   { USB_DEVICE(0x046d, 0x08c7), .driver_info = USB_QUIRK_RESET_RESUME },
 
/* Logitech Harmony 700-series */
{ USB_DEVICE(0x046d, 0xc122), .driver_info = USB_QUIRK_DELAY_INIT },
@@ -169,6 +139,10 @@ static const struct usb_device_id usb_qu
 };
 
 static const struct usb_device_id usb_interface_quirk_list[] = {
+   /* Logitech UVC Cameras */
+   { USB_VENDOR_AND_INTERFACE_INFO(0x046d, USB_CLASS_VIDEO, 1, 0),
+ .driver_info = USB_QUIRK_RESET_RESUME },
+
{ }  /* terminating entry must be last */
 };
 



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


[ 140/153] usb: Add quirk detection based on interface information

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Laurent Pinchart 

commit 80da2e0df5af700518611b7d1cc4fc9945bcaf95 upstream.

When a whole class of devices (possibly from a specific vendor, or
across multiple vendors) require a quirk, explictly listing all devices
in the class make the quirks table unnecessarily large. Fix this by
allowing matching devices based on interface information.

Signed-off-by: Laurent Pinchart 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
---
 drivers/usb/core/driver.c |   38 ++
 drivers/usb/core/hub.c|   10 +++--
 drivers/usb/core/quirks.c |   93 +++--
 drivers/usb/core/usb.h|4 ++
 4 files changed, 106 insertions(+), 39 deletions(-)

--- a/drivers/usb/core/driver.c
+++ b/drivers/usb/core/driver.c
@@ -541,22 +541,10 @@ int usb_match_device(struct usb_device *
 }
 
 /* returns 0 if no match, 1 if match */
-int usb_match_one_id(struct usb_interface *interface,
-const struct usb_device_id *id)
+int usb_match_one_id_intf(struct usb_device *dev,
+ struct usb_host_interface *intf,
+ const struct usb_device_id *id)
 {
-   struct usb_host_interface *intf;
-   struct usb_device *dev;
-
-   /* proc_connectinfo in devio.c may call us with id == NULL. */
-   if (id == NULL)
-   return 0;
-
-   intf = interface->cur_altsetting;
-   dev = interface_to_usbdev(interface);
-
-   if (!usb_match_device(dev, id))
-   return 0;
-
/* The interface class, subclass, and protocol should never be
 * checked for a match if the device class is Vendor Specific,
 * unless the match record specifies the Vendor ID. */
@@ -581,6 +569,26 @@ int usb_match_one_id(struct usb_interfac
 
return 1;
 }
+
+/* returns 0 if no match, 1 if match */
+int usb_match_one_id(struct usb_interface *interface,
+const struct usb_device_id *id)
+{
+   struct usb_host_interface *intf;
+   struct usb_device *dev;
+
+   /* proc_connectinfo in devio.c may call us with id == NULL. */
+   if (id == NULL)
+   return 0;
+
+   intf = interface->cur_altsetting;
+   dev = interface_to_usbdev(interface);
+
+   if (!usb_match_device(dev, id))
+   return 0;
+
+   return usb_match_one_id_intf(dev, intf, id);
+}
 EXPORT_SYMBOL_GPL(usb_match_one_id);
 
 /**
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1883,7 +1883,7 @@ static int usb_enumerate_device(struct u
if (err < 0) {
dev_err(>dev, "can't read configurations, error 
%d\n",
err);
-   goto fail;
+   return err;
}
}
if (udev->wusb == 1 && udev->authorized == 0) {
@@ -1899,8 +1899,12 @@ static int usb_enumerate_device(struct u
udev->serial = usb_cache_string(udev, 
udev->descriptor.iSerialNumber);
}
err = usb_enumerate_device_otg(udev);
-fail:
-   return err;
+   if (err < 0)
+   return err;
+
+   usb_detect_interface_quirks(udev);
+
+   return 0;
 }
 
 
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -15,17 +15,22 @@
 #include 
 #include "usb.h"
 
-/* List of quirky USB devices.  Please keep this list ordered by:
+/* Lists of quirky USB devices, split in device quirks and interface quirks.
+ * Device quirks are applied at the very beginning of the enumeration process,
+ * right after reading the device descriptor. They can thus only match on 
device
+ * information.
+ *
+ * Interface quirks are applied after reading all the configuration 
descriptors.
+ * They can match on both device and interface information.
+ *
+ * Note that the DELAY_INIT and HONOR_BNUMINTERFACES quirks do not make sense 
as
+ * interface quirks, as they only influence the enumeration process which is 
run
+ * before processing the interface quirks.
+ *
+ * Please keep the lists ordered by:
  * 1) Vendor ID
  * 2) Product ID
  * 3) Class ID
- *
- * as we want specific devices to be overridden first, and only after that, any
- * class specific quirks.
- *
- * Right now the logic aborts if it finds a valid device in the table, we might
- * want to change that in the future if it turns out that a whole class of
- * devices is broken...
  */
 static const struct usb_device_id usb_quirk_list[] = {
/* CBM - Flash disk */
@@ -163,16 +168,53 @@ static const struct usb_device_id usb_qu
{ }  /* terminating entry must be last */
 };
 
-static const struct usb_device_id *find_id(struct usb_device *udev)
+static const struct usb_device_id usb_interface_quirk_list[] = {
+   { }  /* terminating entry must be last */
+};
+
+static bool usb_match_any_interface(struct usb_device *udev,
+

[ 135/153] [hid] usb hid quirks for Masterkit MA901 usb radio

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Alexey Klimov 

commit 0322bd3980b3ebf7dde8474e22614cb443d6479a upstream.

Don't let Masterkit MA901 USB radio be handled by usb hid drivers.
This device will be handled by radio-ma901.c driver.

Signed-off-by: Alexey Klimov 
Acked-by: Hans Verkuil 
Acked-by: Jiri Kosina 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Ben Hutchings 
---
 drivers/hid/hid-core.c |1 +
 drivers/hid/hid-ids.h  |3 +++
 2 files changed, 4 insertions(+)

--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1900,6 +1900,7 @@ static const struct hid_device_id hid_ig
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_HYBRID) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_HEATCONTROL) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MADCATZ, USB_DEVICE_ID_MADCATZ_BEATPAD) 
},
+   { HID_USB_DEVICE(USB_VENDOR_ID_MASTERKIT, 
USB_DEVICE_ID_MASTERKIT_MA901RADIO) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MCC, USB_DEVICE_ID_MCC_PMD1024LS) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MCC, USB_DEVICE_ID_MCC_PMD1208LS) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROCHIP, USB_DEVICE_ID_PICKIT1) },
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -506,6 +506,9 @@
 #define USB_VENDOR_ID_MADCATZ  0x0738
 #define USB_DEVICE_ID_MADCATZ_BEATPAD  0x4540
 
+#define USB_VENDOR_ID_MASTERKIT0x16c0
+#define USB_DEVICE_ID_MASTERKIT_MA901RADIO 0x05df
+
 #define USB_VENDOR_ID_MCC  0x09db
 #define USB_DEVICE_ID_MCC_PMD1024LS0x0076
 #define USB_DEVICE_ID_MCC_PMD1208LS0x007a


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


[ 146/153] usermodehelper: ____call_usermodehelper() doesnt need do_exit()

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Oleg Nesterov 

commit 5b9bd473e3b8a8c6c4ae99be475e6e9b27568555 upstream.

Minor cleanup.  call_usermodehelper() can simply return, no need to
call do_exit() explicitely.

Signed-off-by: Oleg Nesterov 
Cc: Tetsuo Handa 
Cc: Rusty Russell 
Cc: Tejun Heo 
Cc: David Rientjes 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings 
---
 kernel/kmod.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -186,7 +186,7 @@ static int call_usermodehelper(void
/* Exec failed? */
 fail:
sub_info->retval = retval;
-   do_exit(0);
+   return 0;
 }
 
 void call_usermodehelper_freeinfo(struct subprocess_info *info)


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


[ 148/153] kmod: make __request_module() killable

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Oleg Nesterov 

commit 1cc684ab75123efe7ff446eb821d44375ba8fa30 upstream.

As Tetsuo Handa pointed out, request_module() can stress the system
while the oom-killed caller sleeps in TASK_UNINTERRUPTIBLE.

The task T uses "almost all" memory, then it does something which
triggers request_module().  Say, it can simply call sys_socket().  This
in turn needs more memory and leads to OOM.  oom-killer correctly
chooses T and kills it, but this can't help because it sleeps in
TASK_UNINTERRUPTIBLE and after that oom-killer becomes "disabled" by the
TIF_MEMDIE task T.

Make __request_module() killable.  The only necessary change is that
call_modprobe() should kmalloc argv and module_name, they can't live in
the stack if we use UMH_KILLABLE.  This memory is freed via
call_usermodehelper_freeinfo()->cleanup.

Reported-by: Tetsuo Handa 
Signed-off-by: Oleg Nesterov 
Cc: Rusty Russell 
Cc: Tejun Heo 
Cc: David Rientjes 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings 
---
 kernel/kmod.c |   26 --
 1 file changed, 24 insertions(+), 2 deletions(-)

--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -58,6 +58,12 @@ static DEFINE_SPINLOCK(umh_sysctl_lock);
 */
 char modprobe_path[KMOD_PATH_LEN] = "/sbin/modprobe";
 
+static void free_modprobe_argv(struct subprocess_info *info)
+{
+   kfree(info->argv[3]); /* check call_modprobe() */
+   kfree(info->argv);
+}
+
 static int call_modprobe(char *module_name, int wait)
 {
static char *envp[] = {
@@ -67,10 +73,26 @@ static int call_modprobe(char *module_na
NULL
};
 
-   char *argv[] = { modprobe_path, "-q", "--", module_name, NULL };
+   char **argv = kmalloc(sizeof(char *[5]), GFP_KERNEL);
+   if (!argv)
+   goto out;
+
+   module_name = kstrdup(module_name, GFP_KERNEL);
+   if (!module_name)
+   goto free_argv;
+
+   argv[0] = modprobe_path;
+   argv[1] = "-q";
+   argv[2] = "--";
+   argv[3] = module_name;  /* check free_modprobe_argv() */
+   argv[4] = NULL;
 
return call_usermodehelper_fns(modprobe_path, argv, envp,
-   wait, NULL, NULL, NULL);
+   wait | UMH_KILLABLE, NULL, free_modprobe_argv, NULL);
+free_argv:
+   kfree(argv);
+out:
+   return -ENOMEM;
 }
 
 /**


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


[ 098/153] mm: mmu_notifier: make the mmu_notifier srcu static

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Andrea Arcangeli 

commit 70400303ce0c4ced3139499c676d5c79636b0c72 upstream.

The variable must be static especially given the variable name.

s/RCU/SRCU/ over a few comments.

Signed-off-by: Andrea Arcangeli 
Cc: Xiao Guangrong 
Cc: Sagi Grimberg 
Cc: Peter Zijlstra 
Cc: Haggai Eran 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings 
---
 mm/mmu_notifier.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/mm/mmu_notifier.c
+++ b/mm/mmu_notifier.c
@@ -20,7 +20,7 @@
 #include 
 
 /* global SRCU for all MMs */
-struct srcu_struct srcu;
+static struct srcu_struct srcu;
 
 /*
  * This function can't run concurrently against mmu_notifier_register
@@ -41,7 +41,7 @@ void __mmu_notifier_release(struct mm_st
int id;
 
/*
-* RCU here will block mmu_notifier_unregister until
+* SRCU here will block mmu_notifier_unregister until
 * ->release returns.
 */
id = srcu_read_lock();
@@ -302,7 +302,7 @@ void mmu_notifier_unregister(struct mmu_
 
if (!hlist_unhashed(>hlist)) {
/*
-* RCU here will force exit_mmap to wait ->release to finish
+* SRCU here will force exit_mmap to wait ->release to finish
 * before freeing the pages.
 */
int id;


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


[ 127/153] staging: comedi: ni_labpc: correct differential channel sequence for AI commands

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Ian Abbott 

commit 4c4bc25d0fa6beaf054c0b4c3b324487f266c820 upstream.

Tuomas  reported problems getting
meaningful output from a Lab-PC+ in differential mode for AI cmds, but
AI insn reads gave correct readings.  He tracked it down to two
problems, one of which is addressed by this patch.

It seems the setting of the channel bits for particular scanning modes
was incorrect for differential mode.  (Only half the number of channels
are available in differential mode; comedi refers to them as channels 0,
1, 2 and 3, but the hardware documentation refers to them as channels 0,
2, 4 and 6.)  In differential mode, the setting of the channel enable
bits in the command1 register should depend on whether the scan enable
bit is set.  Effectively, we need to double the comedi channel number
when the scan enable bit is not set in differential mode.  The scan
enable bit gets set when the AI scan mode is `MODE_MULT_CHAN_UP` or
`MODE_MULT_CHAN_DOWN`, and gets cleared when the AI scan mode is
`MODE_SINGLE_CHAN` or `MODE_SINGLE_CHAN_INTERVAL`.  The existing test
for whether the comedi channel number needs to be doubled in
differential mode is incorrect in `labpc_ai_cmd()`.  This patch corrects
the test.

Thanks to Tuomas for suggesting the fix.

Signed-off-by: Ian Abbott 
Signed-off-by: Ben Hutchings 
---
 drivers/staging/comedi/drivers/ni_labpc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/staging/comedi/drivers/ni_labpc.c
+++ b/drivers/staging/comedi/drivers/ni_labpc.c
@@ -1264,7 +1264,9 @@ static int labpc_ai_cmd(struct comedi_de
else
channel = CR_CHAN(cmd->chanlist[0]);
/* munge channel bits for differential / scan disabled mode */
-   if (labpc_ai_scan_mode(cmd) != MODE_SINGLE_CHAN && aref == AREF_DIFF)
+   if ((labpc_ai_scan_mode(cmd) == MODE_SINGLE_CHAN ||
+labpc_ai_scan_mode(cmd) == MODE_SINGLE_CHAN_INTERVAL) &&
+   aref == AREF_DIFF)
channel *= 2;
devpriv->command1_bits |= ADC_CHAN_BITS(channel);
devpriv->command1_bits |= thisboard->ai_range_code[range];


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


[ 128/153] staging: comedi: ni_labpc: set up command4 register *after* command3

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Ian Abbott 

commit 22056e2b46246d97ff0f7c6e21a77b8daa07f02c upstream.

Tuomas  reported problems getting
meaningful output from a Lab-PC+ in differential mode for AI cmds, but
AI insn reads gave correct readings.  He tracked it down to two
problems, one of which is addressed by this patch.

It seems that writing to the command3 register after writing to the
command4 register in `labpc_ai_cmd()` messes up the differential
reference bit setting in the command4 register.  Set up the command4
register after the command3 register (as in `labpc_ai_rinsn()`) to avoid
the problem.

Thanks to Tuomas for suggesting the fix.

Signed-off-by: Ian Abbott 
Signed-off-by: Ben Hutchings 
---
 drivers/staging/comedi/drivers/ni_labpc.c | 31 ---
 1 file changed, 16 insertions(+), 15 deletions(-)

--- a/drivers/staging/comedi/drivers/ni_labpc.c
+++ b/drivers/staging/comedi/drivers/ni_labpc.c
@@ -1282,21 +1282,6 @@ static int labpc_ai_cmd(struct comedi_de
devpriv->write_byte(devpriv->command1_bits,
dev->iobase + COMMAND1_REG);
}
-   /*  setup any external triggering/pacing (command4 register) */
-   devpriv->command4_bits = 0;
-   if (cmd->convert_src != TRIG_EXT)
-   devpriv->command4_bits |= EXT_CONVERT_DISABLE_BIT;
-   /* XXX should discard first scan when using interval scanning
-* since manual says it is not synced with scan clock */
-   if (labpc_use_continuous_mode(cmd) == 0) {
-   devpriv->command4_bits |= INTERVAL_SCAN_EN_BIT;
-   if (cmd->scan_begin_src == TRIG_EXT)
-   devpriv->command4_bits |= EXT_SCAN_EN_BIT;
-   }
-   /*  single-ended/differential */
-   if (aref == AREF_DIFF)
-   devpriv->command4_bits |= ADC_DIFF_BIT;
-   devpriv->write_byte(devpriv->command4_bits, dev->iobase + COMMAND4_REG);
 
devpriv->write_byte(cmd->chanlist_len,
dev->iobase + INTERVAL_COUNT_REG);
@@ -1376,6 +1361,22 @@ static int labpc_ai_cmd(struct comedi_de
devpriv->command3_bits &= ~ADC_FNE_INTR_EN_BIT;
devpriv->write_byte(devpriv->command3_bits, dev->iobase + COMMAND3_REG);
 
+   /*  setup any external triggering/pacing (command4 register) */
+   devpriv->command4_bits = 0;
+   if (cmd->convert_src != TRIG_EXT)
+   devpriv->command4_bits |= EXT_CONVERT_DISABLE_BIT;
+   /* XXX should discard first scan when using interval scanning
+* since manual says it is not synced with scan clock */
+   if (labpc_use_continuous_mode(cmd) == 0) {
+   devpriv->command4_bits |= INTERVAL_SCAN_EN_BIT;
+   if (cmd->scan_begin_src == TRIG_EXT)
+   devpriv->command4_bits |= EXT_SCAN_EN_BIT;
+   }
+   /*  single-ended/differential */
+   if (aref == AREF_DIFF)
+   devpriv->command4_bits |= ADC_DIFF_BIT;
+   devpriv->write_byte(devpriv->command4_bits, dev->iobase + COMMAND4_REG);
+
/*  startup acquisition */
 
/*  command2 reg */


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


[ 145/153] usermodehelper: implement UMH_KILLABLE

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Oleg Nesterov 

commit d0bd587a80960d7ba7e0c8396e154028c9045c54 upstream.

Implement UMH_KILLABLE, should be used along with UMH_WAIT_EXEC/PROC.
The caller must ensure that subprocess_info->path/etc can not go away
until call_usermodehelper_freeinfo().

call_usermodehelper_exec(UMH_KILLABLE) does
wait_for_completion_killable.  If it fails, it uses
xchg(_info->complete, NULL) to serialize with umh_complete() which
does the same xhcg() to access sub_info->complete.

If call_usermodehelper_exec wins, it can safely return.  umh_complete()
should get NULL and call call_usermodehelper_freeinfo().

Otherwise we know that umh_complete() was already called, in this case
call_usermodehelper_exec() falls back to wait_for_completion() which
should succeed "very soon".

Note: UMH_NO_WAIT == -1 but it obviously should not be used with
UMH_KILLABLE.  We delay the neccessary cleanup to simplify the back
porting.

Signed-off-by: Oleg Nesterov 
Cc: Tetsuo Handa 
Cc: Rusty Russell 
Cc: Tejun Heo 
Cc: David Rientjes 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings 
---
 include/linux/kmod.h |2 ++
 kernel/kmod.c|   27 +--
 2 files changed, 27 insertions(+), 2 deletions(-)

--- a/include/linux/kmod.h
+++ b/include/linux/kmod.h
@@ -54,6 +54,8 @@ enum umh_wait {
UMH_WAIT_PROC = 1,  /* wait for the process to complete */
 };
 
+#define UMH_KILLABLE   4   /* wait for EXEC/PROC killable */
+
 struct subprocess_info {
struct work_struct work;
struct completion *complete;
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -199,7 +199,15 @@ EXPORT_SYMBOL(call_usermodehelper_freein
 
 static void umh_complete(struct subprocess_info *sub_info)
 {
-   complete(sub_info->complete);
+   struct completion *comp = xchg(_info->complete, NULL);
+   /*
+* See call_usermodehelper_exec(). If xchg() returns NULL
+* we own sub_info, the UMH_KILLABLE caller has gone away.
+*/
+   if (comp)
+   complete(comp);
+   else
+   call_usermodehelper_freeinfo(sub_info);
 }
 
 /* Keventd can't block, but this (a child) can. */
@@ -250,6 +258,9 @@ static void __call_usermodehelper(struct
enum umh_wait wait = sub_info->wait;
pid_t pid;
 
+   if (wait != UMH_NO_WAIT)
+   wait &= ~UMH_KILLABLE;
+
/* CLONE_VFORK: wait until the usermode helper has execve'd
 * successfully We need the data structures to stay around
 * until that is done.  */
@@ -440,9 +451,21 @@ int call_usermodehelper_exec(struct subp
queue_work(khelper_wq, _info->work);
if (wait == UMH_NO_WAIT)/* task has freed sub_info */
goto unlock;
+
+   if (wait & UMH_KILLABLE) {
+   retval = wait_for_completion_killable();
+   if (!retval)
+   goto wait_done;
+
+   /* umh_complete() will see NULL and free sub_info */
+   if (xchg(_info->complete, NULL))
+   goto unlock;
+   /* fallthrough, umh_complete() was already called */
+   }
+
wait_for_completion();
+wait_done:
retval = sub_info->retval;
-
 out:
call_usermodehelper_freeinfo(sub_info);
 unlock:


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


[ 134/153] ata_piix: Add Device IDs for Intel Wellsburg PCH

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: James Ralston 

commit 3aee8bc52c415aba8148f144e5e5359b0fd75dd1 upstream.

This patch adds the IDE-mode SATA Device IDs for the Intel Wellsburg PCH

Signed-off-by: James Ralston 
Signed-off-by: Jeff Garzik 
Signed-off-by: Ben Hutchings 
---
 drivers/ata/ata_piix.c |9 +
 1 file changed, 9 insertions(+)

--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -347,6 +347,15 @@ static const struct pci_device_id piix_p
{ 0x8086, 0x1f30, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
/* SATA Controller IDE (Avoton) */
{ 0x8086, 0x1f31, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
+   /* SATA Controller IDE (Wellsburg) */
+   { 0x8086, 0x8d00, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_snb },
+   /* SATA Controller IDE (Wellsburg) */
+   { 0x8086, 0x8d08, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
+   /* SATA Controller IDE (Wellsburg) */
+   { 0x8086, 0x8d60, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_snb },
+   /* SATA Controller IDE (Wellsburg) */
+   { 0x8086, 0x8d68, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
+
{ } /* terminate 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/


[ 125/153] ipv4: fix a bug in ping_err().

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Li Wei 

[ Upstream commit b531ed61a2a2a77eeb2f7c88b49aa5ec7d9880d8 ]

We should get 'type' and 'code' from the outer ICMP header.

Signed-off-by: Li Wei 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
---
 net/ipv4/ping.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c
index 43d4c3b..294a380 100644
--- a/net/ipv4/ping.c
+++ b/net/ipv4/ping.c
@@ -321,8 +321,8 @@ void ping_err(struct sk_buff *skb, u32 info)
struct iphdr *iph = (struct iphdr *)skb->data;
struct icmphdr *icmph = (struct icmphdr *)(skb->data+(iph->ihl<<2));
struct inet_sock *inet_sock;
-   int type = icmph->type;
-   int code = icmph->code;
+   int type = icmp_hdr(skb)->type;
+   int code = icmp_hdr(skb)->code;
struct net *net = dev_net(skb->dev);
struct sock *sk;
int harderr;


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


[ 130/153] ata_piix: IDE-mode SATA patch for Intel Lynx Point DeviceIDs

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Seth Heasley 

commit 78140cfec503c60a178b11fbaae2fef63e9abdc0 upstream.

This patch adds the IDE-mode SATA DeviceIDs for the Intel Lynx Point PCH.

Signed-off-by: Seth Heasley 
Signed-off-by: Jeff Garzik 
Signed-off-by: Ben Hutchings 
---
 drivers/ata/ata_piix.c |8 
 1 file changed, 8 insertions(+)

--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -321,6 +321,14 @@ static const struct pci_device_id piix_p
{ 0x8086, 0x1e08, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
/* SATA Controller IDE (Panther Point) */
{ 0x8086, 0x1e09, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
+   /* SATA Controller IDE (Lynx Point) */
+   { 0x8086, 0x8c00, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_snb },
+   /* SATA Controller IDE (Lynx Point) */
+   { 0x8086, 0x8c01, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_snb },
+   /* SATA Controller IDE (Lynx Point) */
+   { 0x8086, 0x8c08, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
+   /* SATA Controller IDE (Lynx Point) */
+   { 0x8086, 0x8c09, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
{ } /* terminate 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/


[ 123/153] xen-netback: correctly return errors from netbk_count_requests()

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: David Vrabel 

[ Upstream commit 35876b5ffc154c357476b2c3bdab10feaf4bd8f0 ]

netbk_count_requests() could detect an error, call
netbk_fatal_tx_error() but return 0.  The vif may then be used
afterwards (e.g., in a call to netbk_tx_error().

Since netbk_fatal_tx_error() could set vif->refcnt to 1, the vif may
be freed immediately after the call to netbk_fatal_tx_error() (e.g.,
if the vif is also removed).

Netback thread  Xenwatch thread
---
netbk_fatal_tx_err()netback_remove()
  xenvif_disconnect()
...
free_netdev()
netbk_tx_err() Oops!

Signed-off-by: Wei Liu 
Signed-off-by: Jan Beulich 
Signed-off-by: David Vrabel 
Reported-by: Christopher S. Aker 
Acked-by: Ian Campbell 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
---
 drivers/net/xen-netback/netback.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c 
b/drivers/net/xen-netback/netback.c
index b802bb3..185a0eb 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -883,13 +883,13 @@ static int netbk_count_requests(struct xenvif *vif,
if (frags >= work_to_do) {
netdev_err(vif->dev, "Need more frags\n");
netbk_fatal_tx_err(vif);
-   return -frags;
+   return -ENODATA;
}
 
if (unlikely(frags >= MAX_SKB_FRAGS)) {
netdev_err(vif->dev, "Too many frags\n");
netbk_fatal_tx_err(vif);
-   return -frags;
+   return -E2BIG;
}
 
memcpy(txp, RING_GET_REQUEST(>tx, cons + frags),
@@ -897,7 +897,7 @@ static int netbk_count_requests(struct xenvif *vif,
if (txp->size > first->size) {
netdev_err(vif->dev, "Frag is bigger than frame.\n");
netbk_fatal_tx_err(vif);
-   return -frags;
+   return -EIO;
}
 
first->size -= txp->size;
@@ -907,7 +907,7 @@ static int netbk_count_requests(struct xenvif *vif,
netdev_err(vif->dev, "txp->offset: %x, size: %u\n",
 txp->offset, txp->size);
netbk_fatal_tx_err(vif);
-   return -frags;
+   return -EINVAL;
}
} while ((txp++)->flags & XEN_NETTXF_more_data);
return frags;


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


[ 118/153] drm/radeon/evergreen+: wait for the MC to settle after MC blackout

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Alex Deucher 

commit ed39fadd6df01095378e499fac3674883f16b853 upstream.

Some chips seem to need a little delay after blacking out
the MC before the requests actually stop.

May fix:
https://bugs.freedesktop.org/show_bug.cgi?id=56139
https://bugs.freedesktop.org/show_bug.cgi?id=57567

Signed-off-by: Alex Deucher 
Signed-off-by: Ben Hutchings 
---
 drivers/gpu/drm/radeon/evergreen.c |2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1137,6 +1137,8 @@ void evergreen_mc_stop(struct radeon_dev
blackout &= ~BLACKOUT_MODE_MASK;
WREG32(MC_SHARED_BLACKOUT_CNTL, blackout | 1);
}
+   /* wait for the MC to settle */
+   udelay(100);
 }
 
 void evergreen_mc_resume(struct radeon_device *rdev, struct evergreen_mc_save 
*save)


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


[ 116/153] nbd: fsync and kill block device on shutdown

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Paolo Bonzini 

commit 3a2d63f87989e01437ba994df5f297528c353d7d upstream.

There are two problems with shutdown in the NBD driver.

1: Receiving the NBD_DISCONNECT ioctl does not sync the filesystem.

   This patch adds the sync operation into __nbd_ioctl()'s
   NBD_DISCONNECT handler.  This is useful because BLKFLSBUF is restricted
   to processes that have CAP_SYS_ADMIN, and the NBD client may not
   possess it (fsync of the block device does not sync the filesystem,
   either).

2: Once we clear the socket we have no guarantee that later reads will
   come from the same backing storage.

   The patch adds calls to kill_bdev() in __nbd_ioctl()'s socket
   clearing code so the page cache is cleaned, lest reads that hit on the
   page cache will return stale data from the previously-accessible disk.

Example:

# qemu-nbd -r -c/dev/nbd0 /dev/sr0
# file -s /dev/nbd0
/dev/stdin: # UDF filesystem data (version 1.5) etc.
# qemu-nbd -d /dev/nbd0
# qemu-nbd -r -c/dev/nbd0 /dev/sda
# file -s /dev/nbd0
/dev/stdin: # UDF filesystem data (version 1.5) etc.

While /dev/sda has:

# file -s /dev/sda
/dev/sda: x86 boot sector; etc.

Signed-off-by: Paolo Bonzini 
Acked-by: Paul Clements 
Cc: Alex Bligh 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[bwh: Backported to 3.2:
 - Adjusted context
 - s/\bnbd\b/lo/
 - Incorporate export of kill_bdev() from commit ff01bb483265
   ('fs: move code out of buffer.c')]
Signed-off-by: Ben Hutchings 
---
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -584,12 +584,20 @@ static int __nbd_ioctl(struct block_devi
struct request sreq;
 
dev_info(disk_to_dev(lo->disk), "NBD_DISCONNECT\n");
+   if (!lo->sock)
+   return -EINVAL;
 
+   mutex_unlock(>tx_lock);
+   fsync_bdev(bdev);
+   mutex_lock(>tx_lock);
blk_rq_init(NULL, );
sreq.cmd_type = REQ_TYPE_SPECIAL;
nbd_cmd() = NBD_CMD_DISC;
+
+   /* Check again after getting mutex back.  */
if (!lo->sock)
return -EINVAL;
+
nbd_send_req(lo, );
 return 0;
}
@@ -603,6 +611,7 @@ static int __nbd_ioctl(struct block_devi
nbd_clear_que(lo);
BUG_ON(!list_empty(>queue_head));
BUG_ON(!list_empty(>waiting_queue));
+   kill_bdev(bdev);
if (file)
fput(file);
return 0;
@@ -683,6 +692,7 @@ static int __nbd_ioctl(struct block_devi
lo->file = NULL;
nbd_clear_que(lo);
dev_warn(disk_to_dev(lo->disk), "queue cleared\n");
+   kill_bdev(bdev);
if (file)
fput(file);
lo->bytesize = 0;
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -82,13 +82,14 @@ sector_t blkdev_max_block(struct block_d
 }
 
 /* Kill _all_ buffers and pagecache , dirty or not.. */
-static void kill_bdev(struct block_device *bdev)
+void kill_bdev(struct block_device *bdev)
 {
if (bdev->bd_inode->i_mapping->nrpages == 0)
return;
invalidate_bh_lrus();
truncate_inode_pages(bdev->bd_inode->i_mapping, 0);
 }  
+EXPORT_SYMBOL(kill_bdev);
 
 int set_blocksize(struct block_device *bdev, int size)
 {
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2103,6 +2103,7 @@ extern void bd_forget(struct inode *inod
 extern void bdput(struct block_device *);
 extern void invalidate_bdev(struct block_device *);
 extern int sync_blockdev(struct block_device *bdev);
+extern void kill_bdev(struct block_device *);
 extern struct super_block *freeze_bdev(struct block_device *);
 extern void emergency_thaw_all(void);
 extern int thaw_bdev(struct block_device *bdev, struct super_block *sb);
@@ -2110,6 +2111,7 @@ extern int fsync_bdev(struct block_devic
 #else
 static inline void bd_forget(struct inode *inode) {}
 static inline int sync_blockdev(struct block_device *bdev) { return 0; }
+static inline void kill_bdev(struct block_device *bdev) {}
 static inline void invalidate_bdev(struct block_device *bdev) {}
 
 static inline struct super_block *freeze_bdev(struct block_device *sb)


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


[ 120/153] unbreak automounter support on 64-bit kernel with 32-bit userspace (v2)

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Helge Deller 

commit 4f4ffc3a5398ef9bdbb32db04756d7d34e356fcf upstream.

automount-support is broken on the parisc architecture, because the existing
#if list does not include a check for defined(__hppa__). The HPPA (parisc)
architecture is similiar to other 64bit Linux targets where we have to define
autofs_wqt_t (which is passed back and forth to user space) as int type which
has a size of 32bit across 32 and 64bit kernels.

During the discussion on the mailing list, H. Peter Anvin suggested to invert
the #if list since only specific platforms (specifically those who do not have
a 32bit userspace, like IA64 and Alpha) should have autofs_wqt_t as unsigned
long type.

This suggestion is probably the best way to go, since Arm64 (and maybe others?)
seems to have a non-working automounter. So in the long run even for other new
upcoming architectures this inverted check seem to be the best solution, since
it will not require them to change this #if again (unless they are 64bit only).

Signed-off-by: Helge Deller 
Acked-by: H. Peter Anvin 
Acked-by: Ian Kent 
Acked-by: Catalin Marinas 
CC: James Bottomley 
CC: Rolf Eike Beer 
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings 
---
--- a/include/linux/auto_fs.h
+++ b/include/linux/auto_fs.h
@@ -31,25 +31,16 @@
 #define AUTOFS_MIN_PROTO_VERSION   AUTOFS_PROTO_VERSION
 
 /*
- * Architectures where both 32- and 64-bit binaries can be executed
- * on 64-bit kernels need this.  This keeps the structure format
- * uniform, and makes sure the wait_queue_token isn't too big to be
- * passed back down to the kernel.
- *
- * This assumes that on these architectures:
- * mode 32 bit64 bit
- * -
- * int  32 bit32 bit
- * long 32 bit64 bit
- *
- * If so, 32-bit user-space code should be backwards compatible.
+ * The wait_queue_token (autofs_wqt_t) is part of a structure which is passed
+ * back to the kernel via ioctl from userspace. On architectures where 32- and
+ * 64-bit userspace binaries can be executed it's important that the size of
+ * autofs_wqt_t stays constant between 32- and 64-bit Linux kernels so that we
+ * do not break the binary ABI interface by changing the structure size.
  */
-
-#if defined(__sparc__) || defined(__mips__) || defined(__x86_64__) \
- || defined(__powerpc__) || defined(__s390__)
-typedef unsigned int autofs_wqt_t;
-#else
+#if defined(__ia64__) || defined(__alpha__) /* pure 64bit architectures */
 typedef unsigned long autofs_wqt_t;
+#else
+typedef unsigned int autofs_wqt_t;
 #endif
 
 /* Packet types */


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


[ 121/153] xen-pciback: rate limit error messages from xen_pcibk_enable_msi{,x}()

2013-03-03 Thread Ben Hutchings
3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Jan Beulich 

commit 51ac8893a7a51b196501164e645583bf78138699 upstream.

... as being guest triggerable (e.g. by invoking
XEN_PCI_OP_enable_msi{,x} on a device not being MSI/MSI-X capable).

This is CVE-2013-0231 / XSA-43.

Also make the two messages uniform in both their wording and severity.

Signed-off-by: Jan Beulich 
Acked-by: Ian Campbell 
Reviewed-by: Konrad Rzeszutek Wilk 
[bwh: Backported to 3.2: add #include , needed by
 printk_ratelimited()]
Signed-off-by: Ben Hutchings 
---
 drivers/xen/xen-pciback/pciback_ops.c |   14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

--- a/drivers/xen/xen-pciback/pciback_ops.c
+++ b/drivers/xen/xen-pciback/pciback_ops.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "pciback.h"
 
 int verbose_request;
@@ -135,7 +136,6 @@ int xen_pcibk_enable_msi(struct xen_pcib
 struct pci_dev *dev, struct xen_pci_op *op)
 {
struct xen_pcibk_dev_data *dev_data;
-   int otherend = pdev->xdev->otherend_id;
int status;
 
if (unlikely(verbose_request))
@@ -144,8 +144,9 @@ int xen_pcibk_enable_msi(struct xen_pcib
status = pci_enable_msi(dev);
 
if (status) {
-   printk(KERN_ERR "error enable msi for guest %x status %x\n",
-   otherend, status);
+   pr_warn_ratelimited(DRV_NAME ": %s: error enabling MSI for 
guest %u: err %d\n",
+   pci_name(dev), pdev->xdev->otherend_id,
+   status);
op->value = 0;
return XEN_PCI_ERR_op_failed;
}
@@ -223,10 +224,10 @@ int xen_pcibk_enable_msix(struct xen_pci
pci_name(dev), i,
op->msix_entries[i].vector);
}
-   } else {
-   printk(KERN_WARNING DRV_NAME ": %s: failed to enable MSI-X: err 
%d!\n",
-   pci_name(dev), result);
-   }
+   } else
+   pr_warn_ratelimited(DRV_NAME ": %s: error enabling MSI-X for 
guest %u: err %d!\n",
+   pci_name(dev), pdev->xdev->otherend_id,
+   result);
kfree(entries);
 
op->value = result;


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


  1   2   3   4   5   6   7   8   9   >