[git pull] single_open() leak fixes
A bunch of fixes for a moderately common class of bugs: file with single_open() done by its ->open() and seq_release as its ->release(). That leaks; fortunately, it's not _too_ common (either people manage to RTFM that says "When using single_open(), the programmer should use single_release() instead of seq_release() in the file_operations structure to avoid a memory leak", or they just copy a correct instance), but grepping through the tree has caught quite a pile. All of that is, AFAICS, -stable fodder, for as far as the patches apply. I tried to carve it up into reasonably-sized pieces (more or less "comes from the same tree"). Please, pull from git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus Shortlog: Al Viro (15): arm: single_open() leaks cris: single_open() leaks h8300: single_open() leaks ia64: single_open() leaks mips: single_open() leaks parisc: single_open() leaks sh: single_open() leaks ds1620: single_open() leak rtc: single_open() leaks input: single_open() leak wireless: single_open() leaks megaraid: single_open() leak staging: single_open() leaks gadget: single_open() leaks rcutrace: single_open() leaks Diffstat: arch/arm/kernel/swp_emulate.c |2 +- arch/arm/mach-omap1/pm.c |2 +- arch/cris/arch-v10/kernel/fasttimer.c |2 +- arch/cris/arch-v32/kernel/fasttimer.c |2 +- arch/h8300/kernel/gpio.c |2 +- arch/ia64/kernel/palinfo.c |2 +- arch/ia64/kernel/salinfo.c |2 +- arch/ia64/sn/kernel/sn2/prominfo_proc.c|4 ++-- arch/mips/kernel/smtc-proc.c |2 +- arch/mips/pci/ops-pmcmsp.c |4 ++-- arch/mips/sibyte/sb1250/bus_watcher.c |2 +- arch/parisc/kernel/pdc_chassis.c |2 +- arch/sh/drivers/dma/dma-api.c |2 +- drivers/char/ds1620.c |2 +- drivers/char/efirtc.c |2 +- drivers/char/genrtc.c |2 +- drivers/input/misc/hp_sdc_rtc.c|2 +- drivers/net/wireless/atmel.c |2 +- drivers/net/wireless/hostap/hostap_ap.c|4 ++-- drivers/net/wireless/hostap/hostap_hw.c|2 +- drivers/net/wireless/hostap/hostap_proc.c |6 +++--- drivers/scsi/megaraid.c|2 +- drivers/staging/comedi/proc.c |2 +- drivers/staging/csr/io.c |2 +- drivers/staging/cxt1e1/sbeproc.c |2 +- drivers/staging/ft1000/ft1000-pcmcia/ft1000_proc.c |2 +- drivers/staging/ft1000/ft1000-usb/ft1000_proc.c|2 +- drivers/staging/rtl8187se/r8180_core.c |2 +- drivers/staging/rtl8192u/r8192U_core.c |2 +- drivers/staging/wlags49_h2/wl_main.c |2 +- drivers/usb/gadget/fsl_udc_core.c |2 +- drivers/usb/gadget/goku_udc.c |2 +- kernel/rcutree_trace.c |8 33 files changed, 41 insertions(+), 41 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/
[PATCH] rtc: rtc-tile: add missing platform_device_unregister() when module exit
From: Wei Yongjun
We have registered platform device when module init, and
need unregister it when module exit.
Signed-off-by: Wei Yongjun
---
drivers/rtc/rtc-tile.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/rtc/rtc-tile.c b/drivers/rtc/rtc-tile.c
index 249b653..fc3dee9 100644
--- a/drivers/rtc/rtc-tile.c
+++ b/drivers/rtc/rtc-tile.c
@@ -146,6 +146,7 @@ exit_driver_unregister:
*/
static void __exit tile_rtc_driver_exit(void)
{
+ platform_device_unregister(tile_rtc_platform_device);
platform_driver_unregister(_rtc_platform_driver);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v8 1/3] of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and PowerPC
On Mon, 2013-04-22 at 11:41 +0100, Andrew Murray wrote: > The pci_process_bridge_OF_ranges function, used to parse the "ranges" > property of a PCI host device, is found in both Microblaze and PowerPC > architectures. These implementations are nearly identical. This patch > moves this common code to a common place. What's happening with this ? I'd like to avoid that patch for now as I'm doing some changes to pci_process_bridge_OF_ranges which are fairly urgent (I might even stick them in the current merge window) to deal with memory windows having separate offsets. There's also a few hacks in there that are really ppc specific... I think the right long term approach is to change the way powerpc (and microblaze ?) initializes PCI host bridges. Move it away from setup_arch() (which is a PITA anyway since it's way too early) to an early init call of some sort, and encapsulate the new struct pci_host_bridge. We can then directly configure the host bridge windows rather than having this "intermediary" set of resources in our pci_controller and in fact move most of the fields from pci_controller to pci_host_bridge to the point where the former can remain as a simple platform specific wrapper if needed. So for new stuff (hint: DT based ARM PCI) or stuff that has to deal with a lot less archaic platforms (hint: Microblaze), I'd recommend going straight for that approach rather than perpetuating the PowerPC code which I'll try to deal with in the next few monthes. Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT] Networking
1) Several routines do not use netdev_features_t to hold such bitmasks, fixes from Patrick McHardy and Bjørn Mork. 2) Update cpsw IRQ software state and the actual HW irq enabling in the correct order. From Mugunthan V N. 3) When sending tipc packets to multiple bearers, we have to make copies of the SKB rather than just giving the original SKB directly. Fix from Gerlando Falauto. 4) Fix race with bridging topology change timer, from Stephen Hemminger. 5) Fix TCPv6 segmentation handling in GRE and VXLAN, from Pravin B Shelar. 6) Endian bug in USB pegasus driver, from Dan Carpenter. 7) Fix crashes on MTU reduction in USB asix driver, from Holger Eitzenberger. 8) Don't allow the kernel to BUG() just because the user puts some crap in an AF_PACKET mmap() ring descriptor. Fix from Daniel Borkmann. 9) Don't use variable sized arrays on the stack in xen-netback, from Wei Liu. 10) Fix stats reporting and an unbalanced napi_disable() in be2net driver. From Somnath Kotur and Ajit Khaparde. Please pull, thanks a lot! The following changes since commit 99c6bcf46d2233d33e441834e958ed0bc22b190a: Merge tag 'multiplatform-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2013-05-02 09:38:16 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master for you to fetch changes up to 777c2300865cb9b1b1791862ed23da677abfe6dc: cxgb4: fix error recovery when t4_fw_hello returns a positive value (2013-05-03 16:10:34 -0400) Ajit Khaparde (4): be2net: Fix to use version 2 of cq_create for SkyHawk-R devices be2net: Fix to use 32-bit stats to report rx_drops_no_fragment be2net: Fix to show tx priority pause counter in ethtool -S be2net: Fix to receive Multicast Packets when Promiscuous mode is enabled on certain devices Bjørn Mork (1): net: vlan,ethtool: netdev_features_t is more than 32 bit Dan Carpenter (1): usbnet: pegasus: endian bug in write_mii_word() Daniel Borkmann (1): packet: tpacket_v3: do not trigger bug() on wrong header status Gerlando Falauto (3): tipc: cosmetic: clean up comments and break a long line tipc: tipc_bcbearer_send(): simplify bearer selection tipc: pskb_copy() buffers when sending on more than one bearer Kirill Smelkov (1): sky2: Fix crash on receiving VLAN frames Mugunthan V N (1): drivers: net: cpsw: irq not disabled in cpsw isr in particular sequence Patrick McHardy (1): net: use netdev_features_t in skb_needs_linearize() Pravin B Shelar (2): gre: Fix GREv4 TCPv6 segmentation. vxlan: Fix TCPv6 segmentation. Somnath Kotur (3): be2net: Fix firmware download for Lancer be2net: avoid napi_disable() when it has not been enabled be2net: Fix to fail probe if MSI-X enable fails for a VF Teppo Kotilainen (1): net: qmi_wwan: Add Telewell TW-LTE 4G Thadeu Lima de Souza Cascardo (1): cxgb4: fix error recovery when t4_fw_hello returns a positive value Wei Liu (3): xen-netback: remove redundent parameter in netbk_count_requests xen-netback: avoid allocating variable size array on stack xen-netback: better names for thresholds hol...@eitzenberger.org (1): asix: fix BUG in receive path when lowering MTU stephen hemminger (1): bridge: fix race with topology change timer drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 2 +- drivers/net/ethernet/emulex/benet/be.h | 1 + drivers/net/ethernet/emulex/benet/be_cmds.c | 35 +--- drivers/net/ethernet/emulex/benet/be_cmds.h | 2 +- drivers/net/ethernet/emulex/benet/be_ethtool.c | 1 + drivers/net/ethernet/emulex/benet/be_main.c | 54 +++-- drivers/net/ethernet/marvell/sky2.c | 2 ++ drivers/net/ethernet/ti/cpsw.c | 2 +- drivers/net/usb/asix_common.c | 3 +++ drivers/net/usb/pegasus.c | 3 ++- drivers/net/usb/qmi_wwan.c | 1 + drivers/net/xen-netback/netback.c | 69 --- net/8021q/vlan_dev.c| 2 +- net/bridge/br_stp_timer.c | 2 +- net/core/dev.c | 2 +- net/core/ethtool.c | 2 +- net/ipv4/af_inet.c | 1 + net/ipv4/gre.c | 4 +++- net/ipv4/udp.c | 7 ++- net/packet/af_packet.c | 53 +--- net/tipc/bcast.c| 40 +++- 21 files changed, 178 insertions(+), 110 deletions(-) -- To unsubscribe from this
[GIT] Sparc
1) Hibernation support, as well as removal of excess interrupt twiddling in MMU context allocation on sparc64 from Kirill Tkhai. 2) Kill references to __ARCH_WANT_UNLOCKED_CTXSW. 3) Sparc32 LEON bug fixes from Daniel Hellstrom and Andreas Larsson. 4) Provide cmpxchg64(), from Geert Uytterhoeven. 5) Device refcount and registry bug fixes from Federico Vaga and Wei Yongjun. Please pull, thanks a lot! The following changes since commit 150a8dcf109f68f322bf112c7604f2d950303f00: Merge tag 'boards-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2013-05-04 12:34:30 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-next.git master for you to fetch changes up to 048c9acca90ca7da42b92745445fe008a48add88: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc (2013-05-04 18:34:13 -0700) Andreas Larsson (1): sparc32, leon: Do not overwrite previously set irq flow handlers Daniel Hellstrom (3): sparc32,leon: add support for PCI busn resource for GRPCI2 sparc,leon: support for GRPCI1 PCI host bridge controller sparc,leon: updated GRPCI2 config name David S. Miller (3): sparc64: Kill __ARCH_WANT_UNLOCKED_CTXSW sparc: Consistently use 'wr' and 'rd' instructions for ASRs. Merge git://git.kernel.org/.../davem/sparc Federico Vaga (1): sparc/kernel/vio.c: add put_device() after device_find_child() Geert Uytterhoeven (1): sparc64: Provide cmpxchg64() Kirill Tkhai (1): sparc64: Do not save/restore interrupts in get_new_mmu_context() Tkhai Kirill (2): sparc64: Hibernation support sparc64: Do not change num_physpages during initmem freeing Wei Yongjun (1): serial: sunsu: add missing platform_driver_unregister() when module exit arch/sparc/Kconfig | 20 +- arch/sparc/Makefile | 1 + arch/sparc/include/asm/cmpxchg_64.h | 1 + arch/sparc/include/asm/head_32.h| 6 +- arch/sparc/include/asm/hibernate.h | 23 +++ arch/sparc/include/asm/leon_pci.h | 1 + arch/sparc/include/asm/mmu_context_64.h | 2 +- arch/sparc/include/asm/processor_64.h | 3 - arch/sparc/kernel/Makefile | 3 +- arch/sparc/kernel/asm-offsets.c | 15 ++ arch/sparc/kernel/leon_kernel.c | 10 +- arch/sparc/kernel/leon_pci.c| 2 + arch/sparc/kernel/leon_pci_grpci1.c | 724 ++ arch/sparc/kernel/leon_pci_grpci2.c | 5 + arch/sparc/kernel/leon_pmc.c| 4 +- arch/sparc/kernel/vio.c | 1 + arch/sparc/mm/init_64.c | 7 +- arch/sparc/power/Makefile | 3 + arch/sparc/power/hibernate.c| 42 + arch/sparc/power/hibernate_asm.S| 131 + drivers/tty/serial/sunsu.c | 1 + 21 files changed, 986 insertions(+), 19 deletions(-) create mode 100644 arch/sparc/include/asm/hibernate.h create mode 100644 arch/sparc/kernel/leon_pci_grpci1.c create mode 100644 arch/sparc/power/Makefile create mode 100644 arch/sparc/power/hibernate.c create mode 100644 arch/sparc/power/hibernate_asm.S -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] sparc/kernel/vio.c: add put_device() after device_find_child()
From: Federico Vaga Date: Mon, 15 Apr 2013 16:42:52 +0200 > The vio_remove() function uses device_find_child() but it does not drop > the reference of the retrieved child. > > Signed-off-by: Federico Vaga Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] lockdep: check that no locks held at freeze time
On Sat 2013-05-04 17:23:01, Colin Cross wrote:
> On Sat, May 4, 2013 at 5:05 PM, Pavel Machek wrote:
> > Hi!
> >
> >> >> >> --- a/kernel/exit.c
> >> >> >> +++ b/kernel/exit.c
> >> >> >> @@ -835,7 +835,7 @@ void do_exit(long code)
> >> >> >> /*
> >> >> >>* Make sure we are holding no locks:
> >> >> >>*/
> >> >> >> - debug_check_no_locks_held(tsk);
> >> >> >> + debug_check_no_locks_held();
> >> >> >
> >> >> > Is task guaranteed == current?
> >> >>
> >> >> Yes, the first line of do_exit is:
> >> >> struct task_struct *tsk = current;
> >> >
> >> > Aha, I understand it now.
> >> >
> >> > Accessing current is slower than local variable. So your "new" code
> >> > will work but will be slower. Please revert this part.
> >>
> >> Using current instead of passing in tsk was done at Andrew Morton's
> >> suggestion, and makes no difference from the freezer's perspective
> >> since it would have to use current to get the task to pass in, so I'm
> >> going to leave it as is.
> >
> > Well, current is:
> >
> > static inline struct thread_info *current_thread_info(void)
> > {
> > register unsigned long sp asm ("sp");
> > return (struct thread_info *)(sp & ~(THREAD_SIZE - 1));
> > }
> >
> > #define get_current() (current_thread_info()->task)
> >
> > #define current get_current()
> >
> > Instead of passing computed value to debug_check_no_locks_held(), you
> > force it to be computed again. do_exit() performance matters for
> > configure scripts, etc.
> >
> > I'd say it makes sense to keep the optimalization. akpm can correct
> > me.
>
> That translates to 3 instructions, with no memory accesses:
> c0008350: e1a0300dmov r3, sp
> c0008354: e3c32d7fbic r2, r3, #8128 ; 0x1fc0
> c0008358: e3c2203fbic r2, r2, #63 ; 0x3f
On ARM, you are right. It seems to have memory access on s390 and
x86-64. Ok, it is probably going to be in cache, but...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] TTY: fix atime/mtime regression
On Sat, May 4, 2013 at 5:30 PM, Craig Small wrote: > > I saw someone wants the 10 second resolution, can I get it confirmed > that the kernel will only be updating at minute intervals (so the .1 > second stuff is completely useless) or 10 second (so the .1 second > stuff is just confusing for most of us). Yeah, it's roughly 10s right now (it's actually 8 seconds, because the power-of-two rounding is cheaper, whatever), and I think that's where it will remain. It seems sufficient for people to know if somebody is "active right now", while being seldom enough that you can't actually get any useful information (ie you can get the "hey, somebody *just* pressed a key by continually stat'ing the file, and get the timing of that one key to almost arbitrary precision, but you won't know the timing of any other keys for another eight seconds, so there's data there but no useful *information*). Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] TTY: fix atime/mtime regression
On Fri, Apr 26, 2013 at 10:02:12AM -0700, Linus Torvalds wrote: > Craig, background: the current git kernel (so 3.9, and these commits > will presumably be back-ported) does not update tty timestamps very > often, because you can use the timestamps to look at peoples typing > behavior. Initially it didn't update the timestamps AT ALL, but that > broke the whole idle routine. Now it updates it only at minute > boundaries, so things like "w" _work_, but the hundreth-of-a-second > idle precision is obviously just totally random noise. I've always personally got confused with that field! Joey Hess kept bugging me for the -o option which was derived from w.bassman though its been so long ago I forget where that came from. I saw someone wants the 10 second resolution, can I get it confirmed that the kernel will only be updating at minute intervals (so the .1 second stuff is completely useless) or 10 second (so the .1 second stuff is just confusing for most of us). I'll then make some sort of change to w, possibly flipping the logic of the -o flag. - Craig -- Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] lockdep: check that no locks held at freeze time
On Sat, May 4, 2013 at 5:05 PM, Pavel Machek wrote:
> Hi!
>
>> >> >> --- a/kernel/exit.c
>> >> >> +++ b/kernel/exit.c
>> >> >> @@ -835,7 +835,7 @@ void do_exit(long code)
>> >> >> /*
>> >> >>* Make sure we are holding no locks:
>> >> >>*/
>> >> >> - debug_check_no_locks_held(tsk);
>> >> >> + debug_check_no_locks_held();
>> >> >
>> >> > Is task guaranteed == current?
>> >>
>> >> Yes, the first line of do_exit is:
>> >> struct task_struct *tsk = current;
>> >
>> > Aha, I understand it now.
>> >
>> > Accessing current is slower than local variable. So your "new" code
>> > will work but will be slower. Please revert this part.
>>
>> Using current instead of passing in tsk was done at Andrew Morton's
>> suggestion, and makes no difference from the freezer's perspective
>> since it would have to use current to get the task to pass in, so I'm
>> going to leave it as is.
>
> Well, current is:
>
> static inline struct thread_info *current_thread_info(void)
> {
> register unsigned long sp asm ("sp");
> return (struct thread_info *)(sp & ~(THREAD_SIZE - 1));
> }
>
> #define get_current() (current_thread_info()->task)
>
> #define current get_current()
>
> Instead of passing computed value to debug_check_no_locks_held(), you
> force it to be computed again. do_exit() performance matters for
> configure scripts, etc.
>
> I'd say it makes sense to keep the optimalization. akpm can correct
> me.
That translates to 3 instructions, with no memory accesses:
c0008350: e1a0300dmov r3, sp
c0008354: e3c32d7fbic r2, r3, #8128 ; 0x1fc0
c0008358: e3c2203fbic r2, r2, #63 ; 0x3f
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] lockdep: check that no locks held at freeze time
Hi!
> >> >> --- a/kernel/exit.c
> >> >> +++ b/kernel/exit.c
> >> >> @@ -835,7 +835,7 @@ void do_exit(long code)
> >> >> /*
> >> >>* Make sure we are holding no locks:
> >> >>*/
> >> >> - debug_check_no_locks_held(tsk);
> >> >> + debug_check_no_locks_held();
> >> >
> >> > Is task guaranteed == current?
> >>
> >> Yes, the first line of do_exit is:
> >> struct task_struct *tsk = current;
> >
> > Aha, I understand it now.
> >
> > Accessing current is slower than local variable. So your "new" code
> > will work but will be slower. Please revert this part.
>
> Using current instead of passing in tsk was done at Andrew Morton's
> suggestion, and makes no difference from the freezer's perspective
> since it would have to use current to get the task to pass in, so I'm
> going to leave it as is.
Well, current is:
static inline struct thread_info *current_thread_info(void)
{
register unsigned long sp asm ("sp");
return (struct thread_info *)(sp & ~(THREAD_SIZE - 1));
}
#define get_current() (current_thread_info()->task)
#define current get_current()
Instead of passing computed value to debug_check_no_locks_held(), you
force it to be computed again. do_exit() performance matters for
configure scripts, etc.
I'd say it makes sense to keep the optimalization. akpm can correct
me.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [systemd-devel] [PATCH 2/2] coredump: Handle programs with spaces in COMM
On Fri, 2013-05-03 at 17:08 +0200, Lennart Poettering wrote: > It sounds really wrong to first merge this into one string and then > split it up again. It sounds much more sensible to instead just pass the > string array around all the time. What's the reason to make this one > string first? I'm wondering if there are compatibility concerns; abrt wouldn't care from what I can tell if we just changed the kernel. systemd-coredump is just plain broken right now. I'll look for the source to the Ubuntu one... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] lockdep: check that no locks held at freeze time
On Sat, May 4, 2013 at 3:57 PM, Pavel Machek wrote:
> On Sat 2013-05-04 13:27:23, Colin Cross wrote:
>> On Sat, May 4, 2013 at 6:04 AM, Pavel Machek wrote:
>> > On Fri 2013-05-03 14:04:10, Colin Cross wrote:
>> >> From: Mandeep Singh Baines
>> >>
>> >> We shouldn't try_to_freeze if locks are held. Holding a lock can cause a
>> >> deadlock if the lock is later acquired in the suspend or hibernate path
>> >> (e.g. by dpm). Holding a lock can also cause a deadlock in the case of
>> >> cgroup_freezer if a lock is held inside a frozen cgroup that is later
>> >> acquired by a process outside that group.
>> >
>> > Ok, but this does not explain why
>> >
>> >> --- a/include/linux/debug_locks.h
>> >> +++ b/include/linux/debug_locks.h
>> >> @@ -51,7 +51,7 @@ struct task_struct;
>> >> extern void debug_show_all_locks(void);
>> >> extern void debug_show_held_locks(struct task_struct *task);
>> >> extern void debug_check_no_locks_freed(const void *from, unsigned long
>> >> len);
>> >> -extern void debug_check_no_locks_held(struct task_struct *task);
>> >> +extern void debug_check_no_locks_held(void);
>> >> #else
>> >> static inline void debug_show_all_locks(void)
>> >> {
>> >
>> > Removing task_struct argument from those functions is good idea?
>>
>> This is an existing patch that was merged in 3.9 and then reverted
>> again, so it has already been reviewed and accepted once.
>
> Well, it was also reverted once :-).
It was reverted because of problems in NFS, not because of any problem
with this patch.
>> >> --- a/kernel/exit.c
>> >> +++ b/kernel/exit.c
>> >> @@ -835,7 +835,7 @@ void do_exit(long code)
>> >> /*
>> >>* Make sure we are holding no locks:
>> >>*/
>> >> - debug_check_no_locks_held(tsk);
>> >> + debug_check_no_locks_held();
>> >
>> > Is task guaranteed == current?
>>
>> Yes, the first line of do_exit is:
>> struct task_struct *tsk = current;
>
> Aha, I understand it now.
>
> Accessing current is slower than local variable. So your "new" code
> will work but will be slower. Please revert this part.
Using current instead of passing in tsk was done at Andrew Morton's
suggestion, and makes no difference from the freezer's perspective
since it would have to use current to get the task to pass in, so I'm
going to leave it as is.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] lockdep: check that no locks held at freeze time
On Sat 2013-05-04 13:27:23, Colin Cross wrote:
> On Sat, May 4, 2013 at 6:04 AM, Pavel Machek wrote:
> > On Fri 2013-05-03 14:04:10, Colin Cross wrote:
> >> From: Mandeep Singh Baines
> >>
> >> We shouldn't try_to_freeze if locks are held. Holding a lock can cause a
> >> deadlock if the lock is later acquired in the suspend or hibernate path
> >> (e.g. by dpm). Holding a lock can also cause a deadlock in the case of
> >> cgroup_freezer if a lock is held inside a frozen cgroup that is later
> >> acquired by a process outside that group.
> >
> > Ok, but this does not explain why
> >
> >> --- a/include/linux/debug_locks.h
> >> +++ b/include/linux/debug_locks.h
> >> @@ -51,7 +51,7 @@ struct task_struct;
> >> extern void debug_show_all_locks(void);
> >> extern void debug_show_held_locks(struct task_struct *task);
> >> extern void debug_check_no_locks_freed(const void *from, unsigned long
> >> len);
> >> -extern void debug_check_no_locks_held(struct task_struct *task);
> >> +extern void debug_check_no_locks_held(void);
> >> #else
> >> static inline void debug_show_all_locks(void)
> >> {
> >
> > Removing task_struct argument from those functions is good idea?
>
> This is an existing patch that was merged in 3.9 and then reverted
> again, so it has already been reviewed and accepted once.
Well, it was also reverted once :-).
> >> --- a/kernel/exit.c
> >> +++ b/kernel/exit.c
> >> @@ -835,7 +835,7 @@ void do_exit(long code)
> >> /*
> >>* Make sure we are holding no locks:
> >>*/
> >> - debug_check_no_locks_held(tsk);
> >> + debug_check_no_locks_held();
> >
> > Is task guaranteed == current?
>
> Yes, the first line of do_exit is:
> struct task_struct *tsk = current;
Aha, I understand it now.
Accessing current is slower than local variable. So your "new" code
will work but will be slower. Please revert this part.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/2] freezer: add unsafe versions of freezable helpers
Hi!
> >> NFS calls the freezable helpers with locks held, which is unsafe
> >> and caused lockdep warnings when 6aa9707 "lockdep: check that no
> >> locks held at freeze time" was applied (reverted in dbf520a).
> >> Add new *_unsafe versions of the helpers that will not run the
> >> lockdep test when 6aa9707 is reapplied, and call them from NFS.
> >>
> >> Signed-off-by: Colin Cross
> >
> > Looks mostly good.
> >
> >> @@ -152,6 +169,14 @@ static inline bool freezer_should_skip(struct
> >> task_struct *p)
> >> freezer_count();\
> >> })
> >>
> >> +/* DO NOT ADD ANY NEW CALLERS OF THIS FUNCTION */
> >> +#define freezable_schedule_unsafe() \
> >> +({ \
> >> + freezer_do_not_count(); \
> >> + schedule(); \
> >> + freezer_count_unsafe(); \
> >> +})
> >> +
> >
> > Make it inline function? :-). Add short explanation why it is good
> > idea?
>
> These are exact copies of the existing non-unsafe versions, except
> they call freezer_count_unsafe() instead of freezer_count(). The next
> version of my other patch stack that goes on top of this has a patch
> to convert the macros in this file to static inline functions (at
> least the ones that can be). I'd rather not mix it in with this patch
> for ease of comparison with the existing calls.
Ok.
Acked-by: Pavel Machek
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 10/10] af_unix: use freezable blocking calls in read
On Sat, May 4, 2013 at 1:39 PM, Tejun Heo wrote: > Hello, Rafael. > > On Sat, May 4, 2013 at 12:19 PM, Rafael J. Wysocki wrote: >>> Heh, so you are aware of the deadlock possibilities. Good selection >>> of spots. For all the conversion patches. >>> >>> Acked-by: Tejun Heo >> >> I wonder if that includes [3/10] (just to get the record straight)? > > I think we want the lockdep annotations before these go in. I'll > review Colin's new series later today. Just to make sure the merge order is clear, the two patches I posted yesterday to reintroduce the lockdep warning in try_to_freeze() (https://lkml.org/lkml/2013/5/3/488) need to be merged first, then I will repost this series on top of that one. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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.0 dmesg reports that my NIC is hanging
After upgrading to the official Arch Linux 3.9-2 kernel package, dmesg reports that my NIC is hanging: [ 5.955720] e1000e :00:19.0 eno1: changing MTU from 1500 to 4000 [ 8.464507] e1000e :00:19.0 eno1: Detected Hardware Unit Hang: TDH <0> TDT <2> next_to_use <2> next_to_clean <0> buffer_info[next_to_clean]: time_stamp next_to_watch <0> jiffies next_to_watch.status <0> MAC Status <40080080> PHY Status <7949> PHY 1000BASE-T Status <0> PHY Extended Status <3000> PCI Status <10> Not too sure what else to post. I am not subscribed to lkml so please cc my email in your reply. Link to complete dmesg: http://pastebin.com/zRBajGrY Seems similar to: bugzilla.redhat.com/show_bug.cgi?id=785806 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 10/10] af_unix: use freezable blocking calls in read
Hello, Rafael. On Sat, May 4, 2013 at 12:19 PM, Rafael J. Wysocki wrote: >> Heh, so you are aware of the deadlock possibilities. Good selection >> of spots. For all the conversion patches. >> >> Acked-by: Tejun Heo > > I wonder if that includes [3/10] (just to get the record straight)? I think we want the lockdep annotations before these go in. I'll review Colin's new series later today. Thanks! -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] lockdep: check that no locks held at freeze time
On Sat, May 4, 2013 at 6:04 AM, Pavel Machek wrote:
> On Fri 2013-05-03 14:04:10, Colin Cross wrote:
>> From: Mandeep Singh Baines
>>
>> We shouldn't try_to_freeze if locks are held. Holding a lock can cause a
>> deadlock if the lock is later acquired in the suspend or hibernate path
>> (e.g. by dpm). Holding a lock can also cause a deadlock in the case of
>> cgroup_freezer if a lock is held inside a frozen cgroup that is later
>> acquired by a process outside that group.
>
> Ok, but this does not explain why
>
>> --- a/include/linux/debug_locks.h
>> +++ b/include/linux/debug_locks.h
>> @@ -51,7 +51,7 @@ struct task_struct;
>> extern void debug_show_all_locks(void);
>> extern void debug_show_held_locks(struct task_struct *task);
>> extern void debug_check_no_locks_freed(const void *from, unsigned long len);
>> -extern void debug_check_no_locks_held(struct task_struct *task);
>> +extern void debug_check_no_locks_held(void);
>> #else
>> static inline void debug_show_all_locks(void)
>> {
>
> Removing task_struct argument from those functions is good idea?
This is an existing patch that was merged in 3.9 and then reverted
again, so it has already been reviewed and accepted once.
>> --- a/kernel/exit.c
>> +++ b/kernel/exit.c
>> @@ -835,7 +835,7 @@ void do_exit(long code)
>> /*
>>* Make sure we are holding no locks:
>>*/
>> - debug_check_no_locks_held(tsk);
>> + debug_check_no_locks_held();
>
> Is task guaranteed == current?
Yes, the first line of do_exit is:
struct task_struct *tsk = current;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[git pull] vfs.git pile 2
Assorted fixes, etc. Please, pull from
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus
Shortlog:
Al Viro (6):
do_mount(): fix a leak introduced in 3.9 ("mount: consolidate permission
checks")
do_coredump(): don't wait for thaw if coredump has already been
interrupted
more mode_t whack-a-mole...
kill fs/read_write.h
create_mnt_ns: unidiomatic use of list_add()
xtensa simdisk: fix braino in "xtensa simdisk: switch to
proc_create_data()"
Geert Uytterhoeven (2):
nubus: Kill nubus_proc_detach_device()
sun3_scsi: add ->show_info()
Han Shen (1):
Removed unused typedef to avoid "unused local typedef" warnings.
James Hogan (3):
hostfs: remove "will unlock" comment
hostfs: move HOSTFS_SUPER_MAGIC to
hostfs: use kmalloc instead of kzalloc
Jan Kara (1):
fs: Fix hang with BSD accounting on frozen filesystem
Syam Sidhardhan (1):
proc_devtree: Replace include linux/module.h with linux/export.h
Wei Yongjun (1):
vfs: use list_move instead of list_del/list_add
Yan, Zheng (1):
fs: remove dentry_lru_prune()
Diffstat:
arch/xtensa/platforms/iss/simdisk.c |2 +-
drivers/hwmon/abx500.c |2 +-
drivers/nubus/proc.c| 15 ---
drivers/scsi/sun3_NCR5380.c | 185 +++
drivers/scsi/sun3_scsi.c|1 +
drivers/scsi/sun3_scsi.h|2 +-
fs/compat.c |2 -
fs/compat_ioctl.c |1 -
fs/coredump.c |9 +-
fs/dcache.c | 34 ++-
fs/hostfs/hostfs_kern.c |8 +-
fs/namespace.c |7 +-
fs/proc/proc_devtree.c |2 +-
fs/read_write.c |5 +-
fs/read_write.h |9 --
include/linux/fs.h |7 ++
include/linux/nubus.h |1 -
include/uapi/linux/magic.h |1 +
kernel/acct.c |7 +-
19 files changed, 124 insertions(+), 176 deletions(-)
delete mode 100644 fs/read_write.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/
Re: [PATCH 1/2] freezer: add unsafe versions of freezable helpers
On Sat, May 4, 2013 at 6:00 AM, Pavel Machek wrote:
> Hi!
>
>> NFS calls the freezable helpers with locks held, which is unsafe
>> and caused lockdep warnings when 6aa9707 "lockdep: check that no
>> locks held at freeze time" was applied (reverted in dbf520a).
>> Add new *_unsafe versions of the helpers that will not run the
>> lockdep test when 6aa9707 is reapplied, and call them from NFS.
>>
>> Signed-off-by: Colin Cross
>
> Looks mostly good.
>
>> @@ -152,6 +169,14 @@ static inline bool freezer_should_skip(struct
>> task_struct *p)
>> freezer_count();\
>> })
>>
>> +/* DO NOT ADD ANY NEW CALLERS OF THIS FUNCTION */
>> +#define freezable_schedule_unsafe() \
>> +({ \
>> + freezer_do_not_count(); \
>> + schedule(); \
>> + freezer_count_unsafe(); \
>> +})
>> +
>
> Make it inline function? :-). Add short explanation why it is good
> idea?
These are exact copies of the existing non-unsafe versions, except
they call freezer_count_unsafe() instead of freezer_count(). The next
version of my other patch stack that goes on top of this has a patch
to convert the macros in this file to static inline functions (at
least the ones that can be). I'd rather not mix it in with this patch
for ease of comparison with the existing calls.
>> +/* DO NOT ADD ANY NEW CALLERS OF THIS FUNCTION */
>> +#define freezable_schedule_timeout_killable_unsafe(timeout) \
>> +({ \
>> + long __retval; \
>> + freezer_do_not_count(); \
>> + __retval = schedule_timeout_killable(timeout); \
>> + freezer_count_unsafe(); \
>> + __retval; \
>> +})
>
> Function too?
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Splitting stk1160-ac97 as a module (Re: linux-next: Tree for May 1 (media/usb/stk1160))
Ezequiel, All, On Sat, May 04, 2013 at 02:21:44PM -0300, Ezequiel Garcia wrote: > I'm trying to split the ac97 support into a separate module. > So far I've managed to do this with two different approaches, > but both of them are broken in some way :-( > > Couple questions: > > 1. Is it possible to force two symbols to be both built-in (=y) or both > modules (=m)? This would make one of my solutions work. If they are always the same value, there is no need to have two symbols in the first place. However, given the original problem from this thread, if what you meant was to have the second symbol either 'n' or the same as the first symbol, ie. the following table: A: n m m y y B: n n m n y Then the closest I came up with is: config MODULES bool "Modules" config A tristate "A" config B_dummy bool "B" depends on A config B tristate default m if A=m && B_dummy default y if A=y && B_dummy where B_dummy is not used outside of Kconfig, and only A and B are the symbols of interest (eg. to build the drivers). Otherwise, I was not able to get the desired behviour with only the A and B symbols. Regards, Yann E. MORIN. -- .-..--.. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `.---: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL| v conspiracy. | '--^---^--^' -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 10/10] af_unix: use freezable blocking calls in read
On Thursday, May 02, 2013 05:08:12 PM Tejun Heo wrote: > On Wed, May 01, 2013 at 06:35:08PM -0700, Colin Cross wrote: > > Avoid waking up every thread sleeping in read call on an AF_UNIX > > socket during suspend and resume by calling a freezable blocking > > call. Previous patches modified the freezer to avoid sending > > wakeups to threads that are blocked in freezable blocking calls. > > > > This call was selected to be converted to a freezable call because > > it doesn't hold any locks or release any resources when interrupted > > that might be needed by another freezing task or a kernel driver > > during suspend, and is a common site where idle userspace tasks are > > blocked. > > Heh, so you are aware of the deadlock possibilities. Good selection > of spots. For all the conversion patches. > > Acked-by: Tejun Heo I wonder if that includes [3/10] (just to get the record straight)? Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 2/3] mailbox: Introduce a new common API
Hi Suman, On 4 May 2013 07:50, Suman Anna wrote: > Hi Jassi, > > On 04/27/2013 01:14 PM, jassisinghb...@gmail.com wrote: >> From: Jassi Brar >> >> Introduce common framework for client/protocol drivers and >> controller drivers of Inter-Processor-Communication (IPC). >> >> Client driver developers should have a look at >> include/linux/mailbox_client.h to understand the part of >> the API exposed to client drivers. >> Similarly controller driver developers should have a look >> at include/linux/mailbox_controller.h > > This implementation looks decent based on your design points. These > are the open/contention points that needs to be sorted out. > > I think understanding the OMAP mailbox architecture also helps you, > since this series currently addressed PL320, but we will run into > some issues when adopting for OMAP as is. OMAP has a single mailbox IP, > each with multiple h/w FIFOs (fifo of length 4, and message size of a > u32). Each IP can cause one or more irq (usually 1) into the linux host. > It has status registers for number of messages in a FIFO (Rx), FIFO full > (Tx non-readiness/busy state), and interrupts for both Rx and Tx. There > are registers indicating the source of the interrupt, and these are per > FIFO. The Tx interrupt source is really for indicating Tx readiness or > that a fifo has open room for sending messages. This will keep on firing > as long as the FIFO is not-full, so we usually configure this only when > the FIFO is full and disable it the moment it is fired. It is re-enabled > when the h/w FIFO is full again, and we use s/w buffering in between. > The Rx interrupt is fired as long as there is a message in any FIFO > which has been configured to interrupt the host, so we have to empty all > the messages for that interrupt source. > Yeah, thanks for explanation. I've worked on OMAP for almost 2 yrs now, though not mailbox. I did have a look at the OMAP4430 trm. I understand OMAP's MBox doesn't really have TX-Done/RTR interrupt, it only has "Tx Buffer Not Full" interrupt which serves the purpose only for the window when there are at least 4 TX messages pending. Now the driver could switch between Polling and IRQ at runtime depending upon the buffer filled extent, OR simply work in polling mode all the time. IMHO the controller driver should opt for the latter. Though it might be interesting to profile out of total transfers during a period, how many are actually queued till depth of 4. > Anyway, here is a summary of the open points that we have: > 1. Atomic Callbacks: > The current code provides some sort of buffering on Tx, but imposes the > restriction that the clients do the buffering on Rx. This is main > concern for OMAP. I am afraid a common API can't do without buffering TX and it can't do by buffering RX. The client(s) can always generate TX requests at a rate greater than the API could transmit on the physical link. So as much as we dislike it, we have to buffer TX requests, otherwise N clients would. OTOH Buffering received packets in the API doesn't help anybody, it only incurs unavoidable latencies on clients. Only clients, that need to take non-atomic actions upon RX, would need to buffer RX. Other clients should not suffer. IMHO if clients on OMAP need to buffer RX, let us keep it OMAP specific. If number of such platforms rise in future we could move that as an _optional_ helper API on top, that does RX buffering on behalf of clients ? > 2. Support for Shared Clients AND Time-shared Clients: > As I said before, we need the framework to be flexible enough to support > shared clients. The shared clients may not be applicable for all h/w > controllers, where a client has to send a series of operations that > needs to be sent to the remote before anyone else can use it. This is a > functional integration aspect, and is dictated by the nature of the > remote. For the time-shared clients, the remote must have some implicit > message protocol where in the remote is able to identify the macro > usecase through a specific message. The framework should allow the case > of shared clients, with the clients doing their own message demuxing. > If the API provides shared ownership of a mailbox, it won't work for clients that need exclusive ownership (like 'server' side implementation of a protocol). OTOH if the API provides exclusive ownership, it is still possible to emulate shared ownership by simply publishing the mailbox handle (void *chan) globally. It works for all. > > 3. Buffering/Size: I think we need to take a re-look at the whole tx > buffering mechanism. You are using an array that stores just the > pointers, which means that there are underlying assumptions that the > clients are keeping their buffer ptrs intact until the duration of the > transfer is done. This means that one cannot use local payload > variables for messages in the calling functions. I feel this is > unnecessary burden on the clients. > Most of the clients won't queue more
Re: [PATCH v2] fs: Fix hang with BSD accounting on frozen filesystem
On Sat, May 04, 2013 at 12:11:23AM +0200, Jan Kara wrote: > When BSD process accounting is enabled and logs information to a > filesystem which gets frozen, system easily becomes unusable because > each attempt to account process information blocks. Thus e.g. every task > gets blocked in exit. > > It seems better to drop accounting information (which can already happen > when filesystem is running out of space) instead of locking system up. > So we just skip the write if the filesystem is frozen. Applied, with one modification - file_start_write_trylock() added and used instead of sb_start_write_trylock() -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 -next 2/2] sun3_scsi: switch to ->show_info()
On Fri, May 03, 2013 at 10:03:43PM +0200, Geert Uytterhoeven wrote: > Ping? > > Now the build failure is also in Linus' tree: > > http://kisskb.ellerman.id.au/kisskb/buildresult/8674437/ > > BTW, this patch depends on "[PATCH 1/2] sun3_scsi: Fill in missing > scsi_host_template.proc_info method" Collapsed together and applied, will go out today -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [REGRESSION] bisected: 3.8 -> 3.9 cannot umount after using fuse
On Sat, May 04, 2013 at 08:02:40PM +0200, Michael Leun wrote: > On Sat, 4 May 2013 16:52:14 +0100 > Al Viro wrote: > > > On Sat, May 04, 2013 at 12:45:19PM +0200, Michael Leun wrote: > > > > > After reverting 57eccb830f1cc93d4b506ba306d8dfa685e0c88f from 3.9 > > > that umount above works (not busy). > > > > Sigh... Check if the following fix works for your testcase: > > diff --git a/fs/namespace.c b/fs/namespace.c > > index b4f96a5..b68eef2d 100644 > > --- a/fs/namespace.c > > +++ b/fs/namespace.c > [...] > > Yup, that fixes it. OK, committed, will go to Linus today, with Cc: stable -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/3] ARM: dove: add DT parsing for legacy timer
On Thu, May 02, 2013 at 08:25:39PM +0200, Sebastian Hesselbarth wrote: > To allow to move to orion irqchip driver, existing legacy devices > have to map their irqs. This patch adds a node for orion timer and > some init code to map the corresponding irqs. While the device tree > node can stay, the init code will vanish as soon as there is true > device tree support for orion timer. > > Signed-off-by: Sebastian Hesselbarth > --- > Cc: Grant Likely > Cc: Rob Herring > Cc: Rob Landley > Cc: Thomas Gleixner > Cc: Russell King > Cc: Arnd Bergmann > Cc: Jason Cooper > Cc: Andrew Lunn > Cc: Thomas Petazzoni > Cc: Gregory Clement > Cc: Ezequiel Garcia > Cc: Jean-Francois Moine > Cc: devicetree-disc...@lists.ozlabs.org > Cc: linux-...@vger.kernel.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-kernel@vger.kernel.org > --- > arch/arm/boot/dts/dove.dtsi |7 ++ > arch/arm/mach-dove/board-dt.c | 42 +++- > 2 files changed, 43 insertions(+), 6 deletions(-) Same for the rest of these, please. thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/3] ARM: dove: add DT parsing for legacy mv643xx_eth
On Thu, May 02, 2013 at 08:25:38PM +0200, Sebastian Hesselbarth wrote: > To allow to move to orion irqchip driver, existing legacy devices > have to map their irqs. This patch adds a node for mv643xx_eth and > some init code to map the corresponding irqs. While the device tree > node can stay, the init code will vanish as soon as there is true > device tree support for mv643xx_eth. > > Signed-off-by: Sebastian Hesselbarth > --- > Cc: Grant Likely > Cc: Rob Herring > Cc: Rob Landley > Cc: Thomas Gleixner > Cc: Russell King > Cc: Arnd Bergmann > Cc: Jason Cooper > Cc: Andrew Lunn > Cc: Thomas Petazzoni > Cc: Gregory Clement > Cc: Ezequiel Garcia > Cc: Jean-Francois Moine > Cc: devicetree-disc...@lists.ozlabs.org > Cc: linux-...@vger.kernel.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-kernel@vger.kernel.org > --- > arch/arm/boot/dts/dove.dtsi |7 +++ > arch/arm/mach-dove/board-dt.c | 31 ++- > 2 files changed, 37 insertions(+), 1 deletions(-) Please break this into two patches, dtsi in one, board-dt.c in the other. thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 2/5] ARM: dove: add DT parsing for legacy mv643xx_eth
On Fri, May 03, 2013 at 07:06:32AM +0200, Andrew Lunn wrote: > Jason: what is the status of the ethernet driver conversion to DT? > Will it get merged this week, or is it material for the next merge > window? You'd have to ask Florian/David Miller. I'm not sure wether David was able to pull that in for v3.10 or not. He was pretty responsive to all of the other changes Florian posted. thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: OMAP2: AM33XX: id: Add support for new AM335x PG2.1 Si
Add support for chip id detection of AM335x PG2.1 Silicon. Currently omap3xxx_check_revision() detects PG1.0 and PG2.0 only, this patch extends it by adding PG2.1 Si support. Signed-off-by: Vaibhav Hiremath --- arch/arm/mach-omap2/id.c |8 ++-- arch/arm/mach-omap2/soc.h |1 + 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c index 0f4c18e..9bc5a18 100644 --- a/arch/arm/mach-omap2/id.c +++ b/arch/arm/mach-omap2/id.c @@ -419,11 +419,15 @@ void __init omap3xxx_check_revision(void) cpu_rev = "1.0"; break; case 1: - /* FALLTHROUGH */ - default: omap_revision = AM335X_REV_ES2_0; cpu_rev = "2.0"; break; + case 2: + /* FALLTHROUGH */ + default: + omap_revision = AM335X_REV_ES2_1; + cpu_rev = "2.1"; + break; } break; case 0xb8f2: diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h index 18fdeeb..ccef2dd 100644 --- a/arch/arm/mach-omap2/soc.h +++ b/arch/arm/mach-omap2/soc.h @@ -396,6 +396,7 @@ IS_OMAP_TYPE(3430, 0x3430) #define AM335X_CLASS 0x33500033 #define AM335X_REV_ES1_0 AM335X_CLASS #define AM335X_REV_ES2_0 (AM335X_CLASS | (0x1 << 8)) +#define AM335X_REV_ES2_1 (AM335X_CLASS | (0x2 << 8)) #define OMAP443X_CLASS 0x44300044 #define OMAP4430_REV_ES1_0 (OMAP443X_CLASS | (0x10 << 8)) -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] irqchip: add support for Marvell Orion SoCs
On Fri, May 03, 2013 at 12:37:20AM +0200, Sebastian Hesselbarth wrote: > (@Jason C: Are you sure that I should merge dove and orion > irqchip patches? I doubt that anything touching generic irq > will not go through irq tree.) Putting them in the same patch series does not imply they have to go through the same tree. But it *does* allow us to see relationships, conflicts, etc. Based on how the finally dependencies work out, we may ask the irq maintainers for an Ack to take it through arm-soc. This would happen if we can't remove the dependency between the trees. The resulting potential merge conflicts weigh into it, and that's where the irqchip maintainer's Ack get decided. If the changes to irqchip are just Makefile/Kconfig, then it's easy. However, if several other files are changed and conflicting, then we let it go through irqchip and wait one merge window for the board changes depending on it. The goal here is to identify and remove branch dependencies within arm-soc and between arm-soc and other trees. A secondary goal is to identify high-risk series (risk of being dropped), and keep them in separate branches from other changes. thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: ipc,sem: sysv semaphore scalability
On Sat, May 04, 2013 at 11:55:58AM -0400, Jörn Engel wrote: > Blockconsole currently lives here: > https://git.kernel.org/cgit/linux/kernel/git/joern/bcon2.git/ Tja, if only that were upstream... -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [REGRESSION] bisected: 3.8 -> 3.9 cannot umount after using fuse
On Sat, 4 May 2013 16:52:14 +0100 Al Viro wrote: > On Sat, May 04, 2013 at 12:45:19PM +0200, Michael Leun wrote: > > > After reverting 57eccb830f1cc93d4b506ba306d8dfa685e0c88f from 3.9 > > that umount above works (not busy). > > Sigh... Check if the following fix works for your testcase: > diff --git a/fs/namespace.c b/fs/namespace.c > index b4f96a5..b68eef2d 100644 > --- a/fs/namespace.c > +++ b/fs/namespace.c [...] Yup, that fixes it. -- MfG, Michael Leun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 1/2] sched: Add cond_resched_rcu_lock() helper
On Sat, May 04, 2013 at 10:23:31AM +0300, Julian Anastasov wrote:
>
> Hello,
>
> On Fri, 3 May 2013, Paul E. McKenney wrote:
>
> > static inline int cond_resched_rcu(void)
> > {
> > #if defined(CONFIG_DEBUG_ATOMIC_SLEEP) || !defined(CONFIG_PREEMPT_RCU)
> > rcu_read_unlock();
> > cond_resched();
> > rcu_read_lock();
> > #endif
> > }
> >
> > This adds absolutely no overhead in non-debug builds of CONFIG_PREEMPT_RCU,
> > does the checking in debug builds, and allows voluntary preemption in
> > !CONFIG_PREEMPT_RCU builds. CONFIG_PROVE_RCU builds will check for an
> > (illegal) outer rcu_read_lock() in CONFIG_PREEMPT_RCU builds, and you
> > will get "scheduling while atomic" in response to an outer rcu_read_lock()
> > in !CONFIG_PREEMPT_RCU builds.
> >
> > It also seems to me a lot simpler.
> >
> > Does this work, or am I still missing something?
>
> Works perfectly. Thanks! Tested CONFIG_PREEMPT_RCU=y/n,
> the errors messages with extra RCU lock.
Very good! Please send the patch along, and I will ack it.
Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] irqchip: add support for Marvell Orion SoCs
On Thu, May 02, 2013 at 09:48:50PM +0200, Sebastian Hesselbarth wrote: > On 05/02/2013 09:35 PM, Jason Gunthorpe wrote: > >I have kirkwood HW but I haven't had time to make newer kernels run on > >it, otherwise I'd test it too :( > > I also have kirkwood HW but that will cut me from email as I use it as > relay server ;) Maybe I can turn it into a test bed for a while. > > There is also Orion5x and Discovery Innovation (mv78xx0) to be tested. > > @Jason Cooper: I will merge both irqchip and dove patches into one > patch set. I wasn't earlier because I didn't want the above SoCs to > slow down patch integration. And I will split dtsi changes into > separate patches as requested. Understood. I'd prefer to keep patches developed together in the same series, that way, discussions about who is taking what and which patch depends on what are all in the same thread of the archives. It's difficult because some series (eg pcie) touch many different areas and _need_ to be kept together because of the chain of dependencies. Most other series though, aren't in that situation. thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Staging: Goldfish: goldfish_nand: Fixed all checkpatch errors
>From 37830ddd9548d298c0c846cd36181cdb97ceebd7 Mon Sep 17 00:00:00 2001
From: Jake Champlin
Date: Sat, 4 May 2013 12:50:27 -0400
Subject: [PATCH] Staging: Goldfish: goldfish_nand: Fixed all checkpatch errors
Fixed all checkpatch errors included inside goldfish_nand.c.
Checkpatch is now clean for goldfish_nand.c
Signed-off-by: "Jake Champlin"
---
drivers/staging/goldfish/goldfish_nand.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/goldfish/goldfish_nand.c
b/drivers/staging/goldfish/goldfish_nand.c
index ab1f019..81e2ad4 100644
--- a/drivers/staging/goldfish/goldfish_nand.c
+++ b/drivers/staging/goldfish/goldfish_nand.c
@@ -326,9 +326,10 @@ static int goldfish_nand_init_device(struct
platform_device *pdev,
(mtd->writesize + mtd->oobsize) * mtd->writesize;
do_div(mtd->size, mtd->writesize + mtd->oobsize);
mtd->size *= mtd->writesize;
- dev_dbg(>dev,
+ dev_dbg(>dev,
"goldfish nand dev%d: size %llx, page %d, extra %d, erase %d\n",
- id, mtd->size, mtd->writesize, mtd->oobsize,
mtd->erasesize);
+ id, mtd->size, mtd->writesize,
+ mtd->oobsize, mtd->erasesize);
spin_unlock_irqrestore(>lock, irq_flags);
mtd->priv = nand;
@@ -340,7 +341,7 @@ static int goldfish_nand_init_device(struct platform_device
*pdev,
result = goldfish_nand_cmd(mtd, NAND_CMD_GET_DEV_NAME, 0, name_len,
name);
if (result != name_len) {
- dev_err(>dev,
+ dev_err(>dev,
"goldfish_nand_init_device failed to get dev name %d !=
%d\n",
result, name_len);
return -ENODEV;
@@ -391,7 +392,7 @@ static int goldfish_nand_probe(struct platform_device *pdev)
version = readl(base + NAND_VERSION);
if (version != NAND_VERSION_CURRENT) {
- dev_err(>dev,
+ dev_err(>dev,
"goldfish_nand_init: version mismatch, got %d, expected
%d\n",
version, NAND_VERSION_CURRENT);
return -ENODEV;
@@ -400,7 +401,7 @@ static int goldfish_nand_probe(struct platform_device *pdev)
if (num_dev == 0)
return -ENODEV;
- nand = devm_kzalloc(>dev, sizeof(*nand) +
+ nand = devm_kzalloc(>dev, sizeof(*nand) +
sizeof(struct mtd_info) * num_dev, GFP_KERNEL);
if (nand == NULL)
return -ENOMEM;
--
1.8.2.1
--
Jake Champlin
jake.champlin...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] drm (ast, cirrus, mgag200, nouveau, savage, vmwgfx): Rework drm_mtrr_{add, del}
On Sat, May 4, 2013 at 10:45 AM, Daniel Vetter wrote:
> On Fri, May 03, 2013 at 04:00:30PM -0700, Andy Lutomirski wrote:
>> This replaces drm_mtrr_{add,del} with drm_mtrr_{add,del}_wc. The
>> interface is simplified (because the base and size parameters to
>> drm_mtrr_del never did anything) and it uses
>> mtrr_{add,del}_wc_if_needed to avoid allocating MTRRs on systems
>> that don't need them.
>>
>> Signed-off-by: Andy Lutomirski
>> ---
>
>
> Tbh I'm not a big fan of the drm_ indirection. Historically that was
> useful as an OS abstraction layer so that the same drivers could be used
> unchanged on Linux and the *BSD. But those days are long gone and drm
> drivers are now proper Linux drivers, and generally OS HALs seem to be
> frowned upon.
>
> Is there another reason than just being consistent with the historic stuff
> here? If we need dummy functions for !CONFIG_MTRR I think those should
> simply be in the core.
I admit to a bit of cargo-culting. There was a layer of indirection,
so I kept it. I'll just call mtrr_add/del_wc_if_needed directly in v2
(I added those functions in patch 1 of this series).
I'd assume you're okay with skipping mtrr addition if PAT is available
since i915 already does it :) (Although the current logic is buggy --
cpu_has_pat is the wrong flag to check -- I think pat_enabled is
better.)
Note to self: I should remove #include in i915_dma.c in v2.
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] drm (ast, cirrus, mgag200, nouveau, savage, vmwgfx): Rework drm_mtrr_{add, del}
On Fri, May 03, 2013 at 04:00:30PM -0700, Andy Lutomirski wrote:
> This replaces drm_mtrr_{add,del} with drm_mtrr_{add,del}_wc. The
> interface is simplified (because the base and size parameters to
> drm_mtrr_del never did anything) and it uses
> mtrr_{add,del}_wc_if_needed to avoid allocating MTRRs on systems
> that don't need them.
>
> Signed-off-by: Andy Lutomirski
> ---
[snip]
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 2d94d74..2a3e1fd 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -1250,18 +1250,15 @@ static inline int drm_core_has_MTRR(struct drm_device
> *dev)
> return drm_core_check_feature(dev, DRIVER_USE_MTRR);
> }
>
> -#define DRM_MTRR_WC MTRR_TYPE_WRCOMB
> -
> -static inline int drm_mtrr_add(unsigned long offset, unsigned long size,
> -unsigned int flags)
> +static inline int __must_check drm_mtrr_add_wc(unsigned long offset,
> +unsigned long size)
> {
> - return mtrr_add(offset, size, flags, 1);
> + return mtrr_add_wc_if_needed(offset, size);
> }
>
> -static inline int drm_mtrr_del(int handle, unsigned long offset,
> -unsigned long size, unsigned int flags)
> +static inline void drm_mtrr_del_wc(int handle)
> {
> - return mtrr_del(handle, offset, size);
> + mtrr_del_wc_if_needed(handle);
> }
>
> #else
> @@ -1269,16 +1266,14 @@ static inline int drm_mtrr_del(int handle, unsigned
> long offset,
>
> #define DRM_MTRR_WC 0
>
> -static inline int drm_mtrr_add(unsigned long offset, unsigned long size,
> -unsigned int flags)
> +static inline int __must_check drm_mtrr_add_wc(unsigned long offset,
> +unsigned long size)
> {
> - return 0;
> + return -1;
> }
>
> -static inline int drm_mtrr_del(int handle, unsigned long offset,
> -unsigned long size, unsigned int flags)
> +static inline void drm_mtrr_del_wc(int handle)
> {
> - return 0;
> }
Tbh I'm not a big fan of the drm_ indirection. Historically that was
useful as an OS abstraction layer so that the same drivers could be used
unchanged on Linux and the *BSD. But those days are long gone and drm
drivers are now proper Linux drivers, and generally OS HALs seem to be
frowned upon.
Is there another reason than just being consistent with the historic stuff
here? If we need dummy functions for !CONFIG_MTRR I think those should
simply be in the core.
And if the inconsistency bugs you I'd volunteer myself to ditch the old
drm_ mtrr helpers.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: ipc,sem: sysv semaphore scalability
On Sat, 23 March 2013 10:19:16 +0700, Emmanuel Benisty wrote: > > I could reproduce it but could you please let me know what would be > the right tools I should use to catch the original oops? > This is what I got but I doubt it will be helpful: > http://i.imgur.com/Mewi1hC.jpg You could use either netconsole or blockconsole. Netconsole requires a second machine to capture the information, blockconsole requires a usb key or something similar to write to. In both cases you will get the entire console output in a file, often including very helpful messages leading up to the crash. Blockconsole currently lives here: https://git.kernel.org/cgit/linux/kernel/git/joern/bcon2.git/ Jörn -- Unless something dramatically changes, by 2015 we'll be largely wondering what all the fuss surrounding Linux was really about. -- Rob Enderle -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Splitting stk1160-ac97 as a module (Re: linux-next: Tree for May 1 (media/usb/stk1160))
Hi Mauro, On Thu, May 02, 2013 at 11:52:33AM -0300, Mauro Carvalho Chehab wrote: > > > > is unreliable (doesn't do what some people expect) when SND=m and > > SND_AC97_CODEC=m, > > since VIDEO_STK1160_AC97 is a bool. > > Using select is always tricky. > > I can see a few possible fixes for it: > > 1) split the alsa part into a separate module. IMHO, this is cleaner, > but requires a little more work. > I'm trying to split the ac97 support into a separate module. So far I've managed to do this with two different approaches, but both of them are broken in some way :-( Couple questions: 1. Is it possible to force two symbols to be both built-in (=y) or both modules (=m)? This would make one of my solutions work. 2. Do you think it's possible to split this as a module *without* requesting the driver dynamically? I've tried the same extensions approach as in em28xx and others, but found some problems with the way snd-usb-audio driver registers. Thanks, -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: Panel: panel: Fixed checkpatch line length warnings
On Sat, May 04, 2013 at 11:21:17AM -0400, Jake Champlin wrote: > Fixed 4 cases of line length issues with checkpatch. Checkpatch is now clean > for panel.c. OK that's clean, thanks! > Signed-off-by: 'Jake Champlin ' Acked-by: Willy Tarreau Willy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Staging: Panel: panel: Fixed checkpatch line length warnings
Fixed 4 cases of line length issues with checkpatch. Checkpatch is now clean
for panel.c.
Signed-off-by: 'Jake Champlin '
---
drivers/staging/panel/panel.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/panel/panel.c b/drivers/staging/panel/panel.c
index c54df39..cbc15c1 100644
--- a/drivers/staging/panel/panel.c
+++ b/drivers/staging/panel/panel.c
@@ -1756,17 +1756,18 @@ static inline int input_state_high(struct logical_input
*input)
if (input->high_timer == 0) {
char *press_str = input->u.kbd.press_str;
- if (press_str[0])
- keypad_send_key(press_str,
-
sizeof(input->u.kbd.press_str));
+ if (press_str[0]) {
+ int s = sizeof(input->u.kbd.press_str);
+ keypad_send_key(press_str, s);
+ }
}
if (input->u.kbd.repeat_str[0]) {
char *repeat_str = input->u.kbd.repeat_str;
if (input->high_timer >= KEYPAD_REP_START) {
+ int s = sizeof(input->u.kbd.repeat_str);
input->high_timer -= KEYPAD_REP_DELAY;
- keypad_send_key(repeat_str,
-
sizeof(input->u.kbd.repeat_str));
+ keypad_send_key(repeat_str, s);
}
/* we will need to come back here soon */
inputs_stable = 0;
@@ -1802,10 +1803,11 @@ static inline void input_state_falling(struct
logical_input *input)
if (input->u.kbd.repeat_str[0]) {
char *repeat_str = input->u.kbd.repeat_str;
- if (input->high_timer >= KEYPAD_REP_START)
+ if (input->high_timer >= KEYPAD_REP_START) {
+ int s = sizeof(input->u.kbd.repeat_str);
input->high_timer -= KEYPAD_REP_DELAY;
- keypad_send_key(repeat_str,
-
sizeof(input->u.kbd.repeat_str));
+ keypad_send_key(repeat_str, s);
+ }
/* we will need to come back here soon */
inputs_stable = 0;
}
@@ -1822,9 +1824,10 @@ static inline void input_state_falling(struct
logical_input *input)
release_fct(input->u.std.release_data);
} else if (input->type == INPUT_TYPE_KBD) {
char *release_str = input->u.kbd.release_str;
- if (release_str[0])
- keypad_send_key(release_str,
-
sizeof(input->u.kbd.release_str));
+ if (release_str[0]) {
+ int s = sizeof(input->u.kbd.release_str);
+ keypad_send_key(release_str, s);
+ }
}
input->state = INPUT_ST_LOW;
--
1.8.2.1
--
Jake Champlin
jake.champlin...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv2] arm: Preserve TPIDRURW on context switch
Am 03.05.2013 17:24, schrieb Jonathan Austin: > Hi Russell, > > Thanks for the comments - you're right about the 'switch_tls' > being more appropriate - needed to take a step back to see that. > > I've got a few questions, added inline. > > André, Assuming I've understood things okay, there's a patch that > uses Russell's asm stuff (with minor modifications, see the questions) > and includes the C-world changes too. Perhaps you could see that it > solves your problem? I'll test it tomorrow with my test tool and Wine. FWIW i hacked together a test tool and it's available at https://github.com/AndreRH/tpidrurw-test -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [REGRESSION] bisected: 3.8 -> 3.9 cannot umount after using fuse
On Sat, May 04, 2013 at 12:45:19PM +0200, Michael Leun wrote: > After reverting 57eccb830f1cc93d4b506ba306d8dfa685e0c88f from 3.9 that > umount above works (not busy). Sigh... Check if the following fix works for your testcase: diff --git a/fs/namespace.c b/fs/namespace.c index b4f96a5..b68eef2d 100644 --- a/fs/namespace.c +++ b/fs/namespace.c @@ -2284,12 +2284,11 @@ long do_mount(const char *dev_name, const char *dir_name, retval = security_sb_mount(dev_name, , type_page, flags, data_page); + if (!retval && !may_mount()) + retval = -EPERM; if (retval) goto dput_out; - if (!may_mount()) - return -EPERM; - /* Default to relatime unless overriden */ if (!(flags & MS_NOATIME)) mnt_flags |= MNT_RELATIME; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] regulator: ti-abb: Fix off-by-one valid range checking for abb->current_info_idx
Change in Liam's email ID.
On 22:02-20130504, Axel Lin wrote:
> abb->current_info_idx is used as array subscript to access volt_table,
> thus the valid value range should be 0 ... desc->n_voltages - 1.
>
> Signed-off-by: Axel Lin
> ---
> drivers/regulator/ti-abb-regulator.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/regulator/ti-abb-regulator.c
> b/drivers/regulator/ti-abb-regulator.c
> index c1870ea..870d209 100644
> --- a/drivers/regulator/ti-abb-regulator.c
> +++ b/drivers/regulator/ti-abb-regulator.c
> @@ -387,8 +387,8 @@ static int ti_abb_get_voltage_sel(struct regulator_dev
> *rdev)
> return -EINVAL;
> }
>
> - if (abb->current_info_idx > (int)desc->n_voltages) {
> - dev_err(dev, "%s: Corrupted data? idx(%d) > n_voltages(%d)\n",
> + if (abb->current_info_idx >= (int)desc->n_voltages) {
> + dev_err(dev, "%s: Corrupted data? idx(%d) >= n_voltages(%d)\n",
> __func__, abb->current_info_idx, desc->n_voltages);
> return -EINVAL;
> }
> --
> 1.8.1.2
Thanks for the same.
Acked-by: Nishanth Menon
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Fix cleaning in scripts/mod
Make sure devicetable-offsets.h is cleaned in the scripts/mod directory Signed-off-by: Andreas Schwab --- scripts/mod/Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/scripts/mod/Makefile b/scripts/mod/Makefile index 9415b56..75d59fc 100644 --- a/scripts/mod/Makefile +++ b/scripts/mod/Makefile @@ -37,6 +37,8 @@ scripts/mod/devicetable-offsets.s: scripts/mod/devicetable-offsets.c FORCE $(obj)/$(devicetable-offsets-file): scripts/mod/devicetable-offsets.s $(call cmd,offsets) +targets += $(devicetable-offsets-file) + # dependencies on generated files need to be listed explicitly $(obj)/modpost.o $(obj)/file2alias.o $(obj)/sumversion.o: $(obj)/elfconfig.h -- 1.8.2.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/
[GIT PULL] MMC updates for 3.10-rc1
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git
tags/mmc-updates-for-3.10-rc1
to receive the MMC merge for 3.10. There are currently no conflicts,
and these patches have been tested in linux-next. Thanks.
The following changes since commit 908ab9368866e6edf0edebdd546adefd5f3128f9:
ARM: dts: tegra: fix the activate polarity of cd-gpio in mmc host (2013-03-11
14:25:10 -0600)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git
tags/mmc-updates-for-3.10-rc1
for you to fetch changes up to e4404fab2e0b70287a471a1e760c9338ce683fde:
mmc: sdhci-tegra: fix MODULE_DEVICE_TABLE (2013-04-23 15:05:57 -0400)
MMC highlights for 3.10:
Core:
- Introduce MMC_CAP2_NO_PRESCAN_POWERUP to allow skipping mmc_power_up()
at boot/initialization time if it's already happened, for performance
(faster boot time) reasons.
- Fix a bit width test failure that resulted in old eMMC cards being put
into 1-bit mode when 4-bit mode was available.
- Expose fwrev/hwrev for MMCv4 parts.
- Improve card removal logic in the case where the card's removed slowly;
we were missing card removal events if the card retained contact with
the slot pads for long enough to reply to a CMD13 while being removed.
Drivers:
- davinci_mmc: Support using PIO instead of DMA.
- dw_mmc: Add support for Exynos4412.
- mxcmmc: DT support, use slot-gpio API.
- mxs-mmc: Add broken-cd/cd-inverted/non-removable DT property support.
- sdhci-sirf: New sdhci-pltfm driver for CSR SiRF SoCs:
SiRFprimaII: unicore ARM Cortex-A9
SiRFatlas6: unicore ARM Cortex-A9
SiRFmarco: dual core ARM Cortex-A9 SMP
- sdhci-tegra: Add support for Tegra114 platforms, use mmc_of_parse().
Aaron Lu (1):
mmc: sdio: bind acpi with sdio function device
Adrian Hunter (3):
Revert "mmc: core: wait while adding MMC host to ensure root mounts
successfully"
mmc: core: fix performance regression initializing MMC host controllers
mmc: core: fix init controller performance regression, updated patch
Alexander Shiyan (1):
mmc: mxcmmc: Fix bug when card is present during boot
Alexandru Gheorghiu (1):
mmc: wmt-sdmmc: Use resource_size()
Anatolij Gustschin (5):
mmc: mxcmmc: fix race conditions for host->req and host->data access
mmc: mxcmmc: add mpc512x SDHC support
mmc: mxcmmc: use slot-gpio API for write-protect detection
mmc: mxcmmc: constify mxcmci_devtype
mmc: mxcmmc: enable DMA support on mpc512x
Arnd Bergmann (1):
mmc: sdhci-tegra: fix MODULE_DEVICE_TABLE
Barry Song (1):
mmc: sdhci-sirf: add mmc host sdhci-pltfm based driver for SiRF SoCs
Bernie Thompson (1):
mmc: core: Add in support to expose PRV for v4 MMCs
Chris Ball (2):
Merge tag 'tegra-for-3.10-fixes-for-mmc' of
git://git.kernel.org/.../swarren/linux-tegra into mmc-next
mmc: sdhci: Don't ignore regulator_enable() return value
Chunhe Lan (1):
mmc: sdhci-pltfm: Fix timeout on t4240's sdhci controller
Dongjin Kim (1):
mmc: dw_mmc: Add MSHC compatible for Exynos4412
Hector Palacios (1):
mmc: mxs-mmc: add broken-cd property
Hyeonsu Kim (1):
mmc: dw_mmc: fixed a wrong UHS_REG 16 bit clear
Jaehoon Chung (2):
mmc: dw_mmc: return the result of mmc_add_host()
mmc: dw_mmc: control the power-enable register
James Hogan (2):
mmc: dw_mmc: setpower on MMC_POWER_{UP,OFF}
mmc: dw_mmc: move host->data_offset init earlier
Jan Luebbe (1):
mmc: omap_hsmmc: support deferred probing for GPIOs
Jingoo Han (4):
mmc: sdhci-s3c: Use devm_clk_get()
mmc: davinci_mmc: use module_platform_driver_probe()
mmc: mvsdio: use module_platform_driver_probe()
mmc: sdhci-spear: add CONFIG_PM_SLEEP to suspend/resume functions
Johan Hovold (1):
mmc: at91/avr32/atmel-mci: fix DMA-channel leak on module unload
Joseph Lo (1):
mmc: tegra: use mmc_of_parse to get the support of standard MMC DT
bindings
Kevin Liu (6):
mmc: core: enhance card removal judgement for slow removal
mmc: sdhci: add get_cd() implementation
mmc: sdhci-pxav3: transfer sdhci_pltfm_data as args to sdhci_pltfm_init
mmc: sdhci-pxav3: remove cd-broken quirk for permanently present card
mmc: sdhci-pxav3: enhance device tree parser code
mmc: sdhci-pxav3: controller should use SDCLK for timeout calculation
Kyoungil Kim (1):
mmc: dw_mmc: empty FIFO after data transfer over interrupt in pio mode
Lars-Peter Clausen (3):
mmc: sdhci_pltfm: Constify sdhci_pltfm_data
mmc: sdhci-pltfm: Constify the ops field of sdhci_pltfm_data struct
mmc: sdhci: Constify sdhci_ops structs where possible
Li Fei (1):
mmc: core: call pm_runtime_put_noidle in pm_runtime_get_sync failed case
Manjunathappa, Prakash (1):
[PATCH] regulator: ti-abb: Fix off-by-one valid range checking for abb->current_info_idx
abb->current_info_idx is used as array subscript to access volt_table,
thus the valid value range should be 0 ... desc->n_voltages - 1.
Signed-off-by: Axel Lin
---
drivers/regulator/ti-abb-regulator.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/ti-abb-regulator.c
b/drivers/regulator/ti-abb-regulator.c
index c1870ea..870d209 100644
--- a/drivers/regulator/ti-abb-regulator.c
+++ b/drivers/regulator/ti-abb-regulator.c
@@ -387,8 +387,8 @@ static int ti_abb_get_voltage_sel(struct regulator_dev
*rdev)
return -EINVAL;
}
- if (abb->current_info_idx > (int)desc->n_voltages) {
- dev_err(dev, "%s: Corrupted data? idx(%d) > n_voltages(%d)\n",
+ if (abb->current_info_idx >= (int)desc->n_voltages) {
+ dev_err(dev, "%s: Corrupted data? idx(%d) >= n_voltages(%d)\n",
__func__, abb->current_info_idx, desc->n_voltages);
return -EINVAL;
}
--
1.8.1.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: [PATCH 2/2] lockdep: check that no locks held at freeze time
On Fri 2013-05-03 14:04:10, Colin Cross wrote:
> From: Mandeep Singh Baines
>
> We shouldn't try_to_freeze if locks are held. Holding a lock can cause a
> deadlock if the lock is later acquired in the suspend or hibernate path
> (e.g. by dpm). Holding a lock can also cause a deadlock in the case of
> cgroup_freezer if a lock is held inside a frozen cgroup that is later
> acquired by a process outside that group.
Ok, but this does not explain why
> --- a/include/linux/debug_locks.h
> +++ b/include/linux/debug_locks.h
> @@ -51,7 +51,7 @@ struct task_struct;
> extern void debug_show_all_locks(void);
> extern void debug_show_held_locks(struct task_struct *task);
> extern void debug_check_no_locks_freed(const void *from, unsigned long len);
> -extern void debug_check_no_locks_held(struct task_struct *task);
> +extern void debug_check_no_locks_held(void);
> #else
> static inline void debug_show_all_locks(void)
> {
Removing task_struct argument from those functions is good idea?
> --- a/kernel/exit.c
> +++ b/kernel/exit.c
> @@ -835,7 +835,7 @@ void do_exit(long code)
> /*
>* Make sure we are holding no locks:
>*/
> - debug_check_no_locks_held(tsk);
> + debug_check_no_locks_held();
Is task guaranteed == current?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/2] freezer: add unsafe versions of freezable helpers
Hi!
> NFS calls the freezable helpers with locks held, which is unsafe
> and caused lockdep warnings when 6aa9707 "lockdep: check that no
> locks held at freeze time" was applied (reverted in dbf520a).
> Add new *_unsafe versions of the helpers that will not run the
> lockdep test when 6aa9707 is reapplied, and call them from NFS.
>
> Signed-off-by: Colin Cross
Looks mostly good.
> @@ -152,6 +169,14 @@ static inline bool freezer_should_skip(struct
> task_struct *p)
> freezer_count();\
> })
>
> +/* DO NOT ADD ANY NEW CALLERS OF THIS FUNCTION */
> +#define freezable_schedule_unsafe() \
> +({ \
> + freezer_do_not_count(); \
> + schedule(); \
> + freezer_count_unsafe(); \
> +})
> +
Make it inline function? :-). Add short explanation why it is good
idea?
> +/* DO NOT ADD ANY NEW CALLERS OF THIS FUNCTION */
> +#define freezable_schedule_timeout_killable_unsafe(timeout) \
> +({ \
> + long __retval; \
> + freezer_do_not_count(); \
> + __retval = schedule_timeout_killable(timeout); \
> + freezer_count_unsafe(); \
> + __retval; \
> +})
Function too?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] PM: Fix dev_pm_put_subsys_data() to not call kfree() while holding device power lock
Hi!
> dev_pm_put_subsys_data() calls kfree() while holding device power lock, when
> the reference count is 0. Fix it to call kfree() after releasing the lock.
>
> Signed-off-by: Shuah Khan
> ---
> drivers/base/power/common.c |6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
w> diff --git a/drivers/base/power/common.c b/drivers/base/power/common.c
> index 39c3252..da05fe2 100644
> --- a/drivers/base/power/common.c
> +++ b/drivers/base/power/common.c
> @@ -73,13 +73,17 @@ int dev_pm_put_subsys_data(struct device *dev)
>
> if (--psd->refcount == 0) {
> dev->power.subsys_data = NULL;
> - kfree(psd);
> ret = 1;
> }
>
> out:
> spin_unlock_irq(>power.lock);
>
> + if (ret == 1) {
> + /* kfree() verifies that its argument is nonzero. */
> + kfree(psd);
> + }
> +
> return ret;
> }
Wow, that function is fragile. It returns 0/1/-EINVAL, while being
documented for 0/1...
Patch does not look obviously wrong, but maybe
@@ -73,13 +73,17 @@ int dev_pm_put_subsys_data(struct device *dev)
if (--psd->refcount == 0) {
dev->power.subsys_data = NULL;
+ spin_unlock_irq(>power.lock);
- kfree(psd);
- ret = 1;
+ return 1;
}
Would be cleaner.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 04/22] staging/drm: imx: add missing dependencies
On Fri, May 03, 2013 at 05:21:37PM +0200, Arnd Bergmann wrote: > On Friday 03 May 2013, Shawn Guo wrote: > > On Thu, May 02, 2013 at 05:16:08PM +0200, Arnd Bergmann wrote: > > > The imx DRM driver needs a couple of extra Kconfig dependencies > > > to avoid random build failures: > > > > > > drivers/staging/imx-drm/ipuv3-crtc.c:448: > > > undefined reference to `ipu_idmac_put' > > > drivers/staging/imx-drm/ipuv3-crtc.c:450: undefined reference to > > > `ipu_dmfc_put' drivers/staging/imx-drm/ipuv3-crtc.c:452: > > > undefined reference to `ipu_dp_put' > > > drivers/staging/imx-drm/ipuv3-crtc.c:454: undefined reference to > > > `ipu_di_put' > > > drivers/built-in.o: In function `ipu_probe': > > > :(.text+0x4b4174): undefined reference to `device_reset' > > > drivers/built-in.o: In function `imx_tve_probe': > > > drivers/staging/imx-drm/imx-tve.c:648: undefined reference to > > > `devm_regmap_init_mmio_clk' > > > drivers/built-in.o: In function > > > `imx_pd_connector_get_modes': > > > > > drivers/staging/imx-drm/parallel-display.c:78: undefined > > > reference to `of_get_drm_display_mode' > > > > There is a patch [1] from Marek fixing this one. > > > > Shawn > > > > [1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/233449 > > > > That patch only addresses one of the four missing dependencies. > I originally had four separate patches, but did not want to > bother everyone with those so I combined them into one. Yea, I agree we can address all of them in one patch. But it seems people agreed that there is a more correct way [1] to fix of_get_drm_display_mode one, and that's how v2 of Marek's patch comes. Shawn [1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/232861/focus=232898 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Regression: ftdi_sio is slow (since Wed Oct 10 15:05:06 2012)
04.05.2013 15:15, Johan Hovold пишет: The query takes longer than the transmit at decent baudrates (>=38k) and under the assumption that flow control isn't causing any delays. But you do have a point, and I have been meaning to look into whether the added overhead of checking the hardware buffers could be mitigated by adding wait_until_sent support to usb-serial. This way the we would only query the hardware buffers on tty_wait_until_sent (e.g. at close) and select and TIOCMOUTQ would not suffer. This is also the way things are handled in serial_core. Thanks for taking a look. Indeed, it seems .wait_until_sent is the best candidate for that kind of things, and the patch in question would even match its description be it using .wait_until_sent and not .chars_in_buffer. Please count on testing your patches here when they are ready. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Regression: ftdi_sio is slow (since Wed Oct 10 15:05:06 2012)
On 05/04/2013 07:15 AM, Johan Hovold wrote: On Sat, May 04, 2013 at 01:50:42AM +0400, Stas Sergeev wrote: 04.05.2013 00:34, Greg KH пишет: On Fri, May 03, 2013 at 10:27:18PM +0400, Stas Sergeev wrote: 03.05.2013 21:16, Greg KH пишет: [...] There's no guarantee as to how long select or an ioctl will take, and now that we have fixed another bug, this device is slower. If you change hardware types to use a different usb to serial chip, that select call might take 4 times as long. Are we somehow supposed to change the kernel to "fix" that? Previously, the kernel was not calling to a device at all, so select() was independent of the chip, and it was fast. I was not aware you changed that willingly. I don't understand, what do you mean by this? Some drivers just return the value of an internally held number, and don't query the device. The only way the FTDI driver can determine if the hardware buffer on the chip way out on the end of the USB cable is empty or not, is to query it. So the driver now does so. It does so only for one char. And the query takes longer than to just xmit that char. So why do you think this even works as expected? The query takes longer than the transmit at decent baudrates (>=38k) and under the assumption that flow control isn't causing any delays. But you do have a point, and I have been meaning to look into whether the added overhead of checking the hardware buffers could be mitigated by adding wait_until_sent support to usb-serial. This way the we would only query the hardware buffers on tty_wait_until_sent (e.g. at close) and select and TIOCMOUTQ would not suffer. This is also the way things are handled in serial_core. Agreed. This is the correct solution. I'll prepare a series which adds wait_until_sent to usb-serial, but I doubt it would be stable material (even if it could get into 3.10). What do you think Greg, is this overhead to chars_in_buffer reason enough to disable it in the stable trees or should we simply fix it in 3.11 (or 3.10)? (The overhead is about 3-400 us per call when the port fifo is empty, which makes chars_in_buffer about 100 times slower on my test system.) A better solution for stable would be to set port->drain_delay. It won't help tcdrain() but at least the port won't shutdown on live outbound data. 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/
Re: Regression: ftdi_sio is slow (since Wed Oct 10 15:05:06 2012)
On Sat, May 04, 2013 at 01:50:42AM +0400, Stas Sergeev wrote: > 04.05.2013 00:34, Greg KH пишет: > > On Fri, May 03, 2013 at 10:27:18PM +0400, Stas Sergeev wrote: > >> 03.05.2013 21:16, Greg KH пишет: [...] > >>> There's no guarantee as to how long select or an ioctl will take, and > >>> now that we have fixed another bug, this device is slower. > >>> > >>> If you change hardware types to use a different usb to serial chip, that > >>> select call might take 4 times as long. Are we somehow supposed to > >>> change the kernel to "fix" that? > >> Previously, the kernel was not calling to a device at all, so > >> select() was independent of the chip, and it was fast. I was > >> not aware you changed that willingly. > > I don't understand, what do you mean by this? Some drivers just return > > the value of an internally held number, and don't query the device. > > > > The only way the FTDI driver can determine if the hardware buffer on the > > chip way out on the end of the USB cable is empty or not, is to query > > it. So the driver now does so. > It does so only for one char. And the query takes longer than > to just xmit that char. So why do you think this even works as > expected? The query takes longer than the transmit at decent baudrates (>=38k) and under the assumption that flow control isn't causing any delays. But you do have a point, and I have been meaning to look into whether the added overhead of checking the hardware buffers could be mitigated by adding wait_until_sent support to usb-serial. This way the we would only query the hardware buffers on tty_wait_until_sent (e.g. at close) and select and TIOCMOUTQ would not suffer. This is also the way things are handled in serial_core. I'll prepare a series which adds wait_until_sent to usb-serial, but I doubt it would be stable material (even if it could get into 3.10). What do you think Greg, is this overhead to chars_in_buffer reason enough to disable it in the stable trees or should we simply fix it in 3.11 (or 3.10)? (The overhead is about 3-400 us per call when the port fifo is empty, which makes chars_in_buffer about 100 times slower on my test system.) Thanks, Johan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v2, RFC] ACPI / memhotplug: Bind removable memory blocks to ACPI device nodes
From: Rafael J. Wysocki
During ACPI memory hotplug configuration bind memory blocks residing
in modules removable through the standard ACPI mechanism to struct
acpi_device objects associated with ACPI namespace objects
representing those modules. Accordingly, unbind those memory blocks
from the struct acpi_device objects when the memory modules in
question are being removed.
When "offline" operation for devices representing memory blocks is
introduced, this will allow the ACPI core's device hot-remove code to
use it to carry out remove_memory() for those memory blocks and check
the results of that before it actually removes the modules holding
them from the system.
Since walk_memory_range() is used for accessing all memory blocks
corresponding to a given ACPI namespace object, it is exported from
memory_hotplug.c so that the code in acpi_memhotplug.c can use it.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/acpi_memhotplug.c | 53 ++---
include/linux/memory_hotplug.h |2 +
mm/memory_hotplug.c|4 ++-
3 files changed, 55 insertions(+), 4 deletions(-)
Index: linux-pm/mm/memory_hotplug.c
===
--- linux-pm.orig/mm/memory_hotplug.c
+++ linux-pm/mm/memory_hotplug.c
@@ -1618,6 +1618,7 @@ int offline_pages(unsigned long start_pf
{
return __offline_pages(start_pfn, start_pfn + nr_pages, 120 * HZ);
}
+#endif /* CONFIG_MEMORY_HOTREMOVE */
/**
* walk_memory_range - walks through all mem sections in [start_pfn, end_pfn)
@@ -1631,7 +1632,7 @@ int offline_pages(unsigned long start_pf
*
* Returns the return value of func.
*/
-static int walk_memory_range(unsigned long start_pfn, unsigned long end_pfn,
+int walk_memory_range(unsigned long start_pfn, unsigned long end_pfn,
void *arg, int (*func)(struct memory_block *, void *))
{
struct memory_block *mem = NULL;
@@ -1668,6 +1669,7 @@ static int walk_memory_range(unsigned lo
return 0;
}
+#ifdef CONFIG_MEMORY_HOTREMOVE
/**
* offline_memory_block_cb - callback function for offlining memory block
* @mem: the memory block to be offlined
Index: linux-pm/include/linux/memory_hotplug.h
===
--- linux-pm.orig/include/linux/memory_hotplug.h
+++ linux-pm/include/linux/memory_hotplug.h
@@ -245,6 +245,8 @@ static inline int is_mem_section_removab
static inline void try_offline_node(int nid) {}
#endif /* CONFIG_MEMORY_HOTREMOVE */
+extern int walk_memory_range(unsigned long start_pfn, unsigned long end_pfn,
+ void *arg, int (*func)(struct memory_block *, void *));
extern int mem_online_node(int nid);
extern int add_memory(int nid, u64 start, u64 size);
extern int arch_add_memory(int nid, u64 start, u64 size);
Index: linux-pm/drivers/acpi/acpi_memhotplug.c
===
--- linux-pm.orig/drivers/acpi/acpi_memhotplug.c
+++ linux-pm/drivers/acpi/acpi_memhotplug.c
@@ -28,6 +28,7 @@
*/
#include
+#include
#include
#include "internal.h"
@@ -166,13 +167,50 @@ static int acpi_memory_check_device(stru
return 0;
}
+static unsigned long acpi_meminfo_start_pfn(struct acpi_memory_info *info)
+{
+ return PFN_DOWN(info->start_addr);
+}
+
+static unsigned long acpi_meminfo_end_pfn(struct acpi_memory_info *info)
+{
+ return PFN_UP(info->start_addr + info->length-1);
+}
+
+static int acpi_bind_memblk(struct memory_block *mem, void *arg)
+{
+ return acpi_bind_one(>dev, (acpi_handle)arg);
+}
+
+static int acpi_bind_memory_blocks(struct acpi_memory_info *info,
+ acpi_handle handle)
+{
+ return walk_memory_range(acpi_meminfo_start_pfn(info),
+acpi_meminfo_end_pfn(info), (void *)handle,
+acpi_bind_memblk);
+}
+
+static int acpi_unbind_memblk(struct memory_block *mem, void *arg)
+{
+ acpi_unbind_one(>dev);
+ return 0;
+}
+
+static void acpi_unbind_memory_blocks(struct acpi_memory_info *info,
+ acpi_handle handle)
+{
+ walk_memory_range(acpi_meminfo_start_pfn(info),
+ acpi_meminfo_end_pfn(info), NULL, acpi_unbind_memblk);
+}
+
static int acpi_memory_enable_device(struct acpi_memory_device *mem_device)
{
+ acpi_handle handle = mem_device->device->handle;
int result, num_enabled = 0;
struct acpi_memory_info *info;
int node;
- node = acpi_get_node(mem_device->device->handle);
+ node = acpi_get_node(handle);
/*
* Tell the VM there is more memory here...
* Note: Assume that this function returns zero on success
@@ -203,6 +241,12 @@ static int acpi_memory_enable_device(str
if (result && result != -EEXIST)
continue;
+ result =
[PATCH 0/2 v2, RFC] Driver core: Add offline/online callbacks for memory_subsys
Hi, On Saturday, May 04, 2013 03:01:23 AM Rafael J. Wysocki wrote: > Hi, > > This is a continuation of this patchset: https://lkml.org/lkml/2013/5/2/214 > and it applies on top of it or rather on top of the rebased version (with > build problems fixed) in the bleeding-edge branch of the linux-pm.git tree: > > http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/log/?h=bleeding-edge > > An introduction to the first part of the patchset is below, a description of > the current patches follows. Actually, I'm withdrawing the previous version of this patchset (or rather patches [2-3/3] from it), because I had a better idea in the meantime. Patch [1/2] is the same as the previous [1/3] -> > On Thursday, May 02, 2013 02:26:39 PM Rafael J. Wysocki wrote: > > On Monday, April 29, 2013 02:23:59 PM Rafael J. Wysocki wrote: > > > > > > It has been argued for a number of times that in some cases, if a device > > > cannot > > > be gracefully removed from the system, it shouldn't be removed from it at > > > all, > > > because that may lead to a kernel crash. In particular, that will happen > > > if a > > > memory module holding kernel memory is removed, but also removing the > > > last CPU > > > in the system may not be a good idea. [And I can imagine a few other > > > cases > > > like that.] > > > > > > The kernel currently only supports "forced" hot-remove which cannot be > > > stopped > > > once started, so users have no choice but to try to hot-remove stuff and > > > see > > > whether or not that crashes the kernel which is kind of unpleasant. That > > > seems > > > to be based on the "the user knows better" argument according to which > > > users > > > triggering device hot-removal should really know what they are doing, so > > > the > > > kernel doesn't have to worry about that. However, for instance, this > > > pretty > > > much isn't the case for memory modules, because the users have no way to > > > see > > > whether or not any kernel memory has been allocated from a given module. > > > > > > There have been a few attempts to address this issue, but none of them has > > > gained broader acceptance. The following 3 patches are the heart of a new > > > proposal which is based on the idea to introduce device_offline() and > > > device_online() operations along the lines of the existing CPU > > > offline/online > > > mechanism (or, rather, to extend the CPU offline/online so that analogous > > > operations are available for other devices). The way it is supposed to > > > work is > > > that device_offline() will fail if the given device cannot be gracefully > > > removed from the system (in the kernel's view). Once it succeeds, > > > though, the > > > device won't be used any more until either it is removed, or > > > device_online() is > > > run for it. That will allow the ACPI device hot-remove code, for one > > > example, > > > to avoid triggering a non-reversible removal procedure for devices that > > > cannot > > > be removed gracefully. > > > > > > Patch [1/3] introduces device_offline() and device_online() as outlined > > > above. > > > The .offline() and .online() callbacks are only added at the bus type > > > level for > > > now, because that should be sufficient to cover the memory and CPU use > > > cases. > > > > That's [1/4] now and the changes from the previous version are: > > - strtobool() is used in store_online(). > > - device_offline_lock has been renamed to device_hotplug_lock (and the > > functions operating it accordingly) following the Toshi's advice. > > > > > Patch [2/3] modifies the CPU hotplug support code to use device_offline() > > > and > > > device_online() to support the sysfs 'online' attribute for CPUs. > > > > That is [2/4] now and it takes cpu_hotplug_driver_lock() around cpu_up() and > > cpu_down(). > > > > > Patch [3/3] changes the ACPI device hot-remove code to use > > > device_offline() > > > for checking if graceful removal of devices is possible. The way it does > > > that > > > is to walk the list of "physical" companion devices for each struct > > > acpi_device > > > involved in the operation and call device_offline() for each of them. If > > > any > > > of the device_offline() calls fails (and the hot-removal is not "forced", > > > which > > > is an option), the removal procedure (which is not reversible) is simply > > > not > > > carried out. > > > > That's current [3/4]. It's a bit simpler, because I decided that it would > > be > > better to have a global 'force_remove' attribute (the semantics of the > > per-profile 'force_remove' wasn't clear and it didn't really add any value > > over > > a global one). I also added lock/unlock_device_hotplug() around > > acpi_bus_scan() > > in acpi_scan_bus_device_check() to allow scan handlers to update > > dev->offline > > for "physical" companion devices safely (the processor's one added by the > > next > > patch actually does that). > > > > > Of some
[PATCH 2/2 v2, RFC] Driver core: Introduce offline/online callbacks for memory blocks
From: Rafael J. Wysocki
Introduce .offline() and .online() callbacks for memory_subsys
that will allow the generic device_offline() and device_online()
to be used with device objects representing memory blocks. That,
in turn, allows the ACPI subsystem to use device_offline() to put
removable memory blocks offline, if possible, before removing
memory modules holding them.
The 'online' sysfs attribute of memory block devices will attempt to
put them offline if 0 is written to it and will attempt to apply the
previously used online type when onlining them (i.e. when 1 is
written to it).
Signed-off-by: Rafael J. Wysocki
---
drivers/base/memory.c | 105 +
include/linux/memory.h |1
2 files changed, 81 insertions(+), 25 deletions(-)
Index: linux-pm/drivers/base/memory.c
===
--- linux-pm.orig/drivers/base/memory.c
+++ linux-pm/drivers/base/memory.c
@@ -37,9 +37,14 @@ static inline int base_memory_block_id(i
return section_nr / sections_per_block;
}
+static int memory_subsys_online(struct device *dev);
+static int memory_subsys_offline(struct device *dev);
+
static struct bus_type memory_subsys = {
.name = MEMORY_CLASS_NAME,
.dev_name = MEMORY_CLASS_NAME,
+ .online = memory_subsys_online,
+ .offline = memory_subsys_offline,
};
static BLOCKING_NOTIFIER_HEAD(memory_chain);
@@ -278,33 +283,64 @@ static int __memory_block_change_state(s
{
int ret = 0;
- if (mem->state != from_state_req) {
- ret = -EINVAL;
- goto out;
- }
+ if (mem->state != from_state_req)
+ return -EINVAL;
if (to_state == MEM_OFFLINE)
mem->state = MEM_GOING_OFFLINE;
ret = memory_block_action(mem->start_section_nr, to_state, online_type);
-
if (ret) {
mem->state = from_state_req;
- goto out;
+ } else {
+ mem->state = to_state;
+ if (to_state == MEM_ONLINE)
+ mem->last_online = online_type;
}
+ return ret;
+}
- mem->state = to_state;
- switch (mem->state) {
- case MEM_OFFLINE:
- kobject_uevent(>dev.kobj, KOBJ_OFFLINE);
- break;
- case MEM_ONLINE:
- kobject_uevent(>dev.kobj, KOBJ_ONLINE);
- break;
- default:
- break;
+static int memory_subsys_online(struct device *dev)
+{
+ struct memory_block *mem = container_of(dev, struct memory_block, dev);
+ int ret;
+
+ mutex_lock(>state_mutex);
+ ret = __memory_block_change_state(mem, MEM_ONLINE, MEM_OFFLINE,
+ mem->last_online);
+ mutex_unlock(>state_mutex);
+ return ret;
+}
+
+static int memory_subsys_offline(struct device *dev)
+{
+ struct memory_block *mem = container_of(dev, struct memory_block, dev);
+ int ret;
+
+ mutex_lock(>state_mutex);
+ ret = __memory_block_change_state(mem, MEM_OFFLINE, MEM_ONLINE, -1);
+ mutex_unlock(>state_mutex);
+ return ret;
+}
+
+static int __memory_block_change_state_uevent(struct memory_block *mem,
+ unsigned long to_state, unsigned long from_state_req,
+ int online_type)
+{
+ int ret = __memory_block_change_state(mem, to_state, from_state_req,
+ online_type);
+ if (!ret) {
+ switch (mem->state) {
+ case MEM_OFFLINE:
+ kobject_uevent(>dev.kobj, KOBJ_OFFLINE);
+ break;
+ case MEM_ONLINE:
+ kobject_uevent(>dev.kobj, KOBJ_ONLINE);
+ break;
+ default:
+ break;
+ }
}
-out:
return ret;
}
@@ -315,8 +351,8 @@ static int memory_block_change_state(str
int ret;
mutex_lock(>state_mutex);
- ret = __memory_block_change_state(mem, to_state, from_state_req,
- online_type);
+ ret = __memory_block_change_state_uevent(mem, to_state, from_state_req,
+online_type);
mutex_unlock(>state_mutex);
return ret;
@@ -326,22 +362,34 @@ store_mem_state(struct device *dev,
struct device_attribute *attr, const char *buf, size_t count)
{
struct memory_block *mem;
+ bool offline;
int ret = -EINVAL;
mem = container_of(dev, struct memory_block, dev);
- if (!strncmp(buf, "online_kernel", min_t(int, count, 13)))
+ lock_device_hotplug();
+
+ if (!strncmp(buf, "online_kernel", min_t(int, count, 13))) {
+ offline = false;
ret = memory_block_change_state(mem, MEM_ONLINE,
Re: [tip:perf/urgent] perf/x86/intel/lbr: Demand proper privileges for PERF_SAMPLE_BRANCH_KERNEL
On Sat, May 04, 2013 at 01:22:57AM -0700, tip-bot for Peter Zijlstra wrote:
> Commit-ID: 0f5c78b5f33ce940034743e5f9485fc81ad75b0f
> Gitweb: http://git.kernel.org/tip/0f5c78b5f33ce940034743e5f9485fc81ad75b0f
> Author: Peter Zijlstra
> AuthorDate: Fri, 3 May 2013 14:11:25 +0200
> Committer: Ingo Molnar
> CommitDate: Sat, 4 May 2013 08:37:48 +0200
>
> perf/x86/intel/lbr: Demand proper privileges for PERF_SAMPLE_BRANCH_KERNEL
>
> We should always have proper privileges when requesting kernel
> data.
>
> Signed-off-by: Peter Zijlstra
> Cc:
> Cc: Andi Kleen
> Cc: eran...@google.com
> Link: http://lkml.kernel.org/r/20130503121256.230745...@chello.nl
> Signed-off-by: Ingo Molnar
> Link: http://lkml.kernel.org/n/tip-v0x9ky3ahzr6nm3c6ilwr...@git.kernel.org
> ---
> arch/x86/kernel/cpu/perf_event_intel_lbr.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
> b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
> index de341d4..0e92871 100644
> --- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
> +++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
> @@ -318,8 +318,11 @@ static void intel_pmu_setup_sw_lbr_filter(struct
> perf_event *event)
> if (br_type & PERF_SAMPLE_BRANCH_USER)
> mask |= X86_BR_USER;
>
> - if (br_type & PERF_SAMPLE_BRANCH_KERNEL)
> + if (br_type & PERF_SAMPLE_BRANCH_KERNEL) {
> + if (perf_paranoid_kernel() && !capable(CAP_SYS_ADMIN))
> + return -EACCES;
It is probably not too late to amend this patch and remove the "-EACCES":
arch/x86/kernel/cpu/perf_event_intel_lbr.c: In function
‘intel_pmu_setup_sw_lbr_filter’:
arch/x86/kernel/cpu/perf_event_intel_lbr.c:323:4: warning: ‘return’ with a
value, in function returning void [enabled by default]
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tps6507x-ts: Add DT support
Add device tree based support for TI's tps6507x touchscreen.
Tested on da850-evm.
Signed-off-by: Vishwanathrao Badarkhe, Manish
---
Changes since V1:
- Updated documetation to specify tps6507x as multifunctional
device.
- return proper error value in absence of platform and DT
data for touchscreen.
- Updated commit message.
:100755 100755 8fffa3c... cf8960c... M
Documentation/devicetree/bindings/mfd/tps6507x.txt
:100644 100644 65e0f9a... d5433d0... M drivers/input/touchscreen/tps6507x-ts.c
Documentation/devicetree/bindings/mfd/tps6507x.txt | 28 +-
drivers/input/touchscreen/tps6507x-ts.c| 105 ++--
2 files changed, 102 insertions(+), 31 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/tps6507x.txt
b/Documentation/devicetree/bindings/mfd/tps6507x.txt
index 8fffa3c..cf8960c 100755
--- a/Documentation/devicetree/bindings/mfd/tps6507x.txt
+++ b/Documentation/devicetree/bindings/mfd/tps6507x.txt
@@ -1,4 +1,8 @@
-TPS6507x Power Management Integrated Circuit
+TPS6507x Multifunctional Device.
+
+Features provided by TPS6507x:
+1.Power Management Integrated Circuit.
+2.Touch-Screen.
Required properties:
- compatible: "ti,tps6507x"
@@ -23,6 +27,12 @@ Required properties:
vindcdc1_2-supply: VDCDC1 and VDCDC2 input.
vindcdc3-supply : VDCDC3 input.
vldo1_2-supply : VLDO1 and VLDO2 input.
+- tsc: This node specifies touch screen data.
+ ti,poll_period : Time at which touch input is getting sampled in ms.
+ ti,min_pressure: Minimum pressure value to trigger touch.
+ ti,vref: voltage reference for ADC.
+ 0: Reference voltage for ADC is disabled.
+ 1: Reference voltage for ADC is enabled.
Regulator Optional properties:
- defdcdc_default: It's property of DCDC2 and DCDC3 regulators.
@@ -30,6 +40,14 @@ Regulator Optional properties:
1: If defdcdc pin of DCDC2/DCDC3 is driven HIGH.
If this property is not defined, it defaults to 0 (not enabled).
+Touchscreen Optional properties:
+- ti,vendor : Touchscreen vendor id to poppulate
+ in sysclass interface.
+- ti,product: Touchscreen product id to poppulate
+ in sysclass interface.
+- ti,version: Touchscreen version id to poppulate
+ in sysclass interface.
+
Example:
pmu: tps6507x@48 {
@@ -88,4 +106,12 @@ Example:
};
};
+ tsc {
+ ti,poll_period = <30>;
+ ti,min_pressure = <0x30>;
+ ti,vref = <0>;
+ ti,vendor = <0>;
+ ti,product = <65070>;
+ ti,version = <0x100>;
+ };
};
diff --git a/drivers/input/touchscreen/tps6507x-ts.c
b/drivers/input/touchscreen/tps6507x-ts.c
index 65e0f9a..d5433d0 100644
--- a/drivers/input/touchscreen/tps6507x-ts.c
+++ b/drivers/input/touchscreen/tps6507x-ts.c
@@ -21,6 +21,8 @@
#include
#include
#include
+#include
+#include
#define TSC_DEFAULT_POLL_PERIOD 30 /* ms */
#define TPS_DEFAULT_MIN_PRESSURE 0x30
@@ -231,36 +233,83 @@ done:
ret = tps6507x_adc_standby(tsc);
}
+static int tsc_init_data(struct tps6507x_dev *tps6507x_dev,
+ struct input_dev *input_dev)
+{
+ struct device_node *node = tps6507x_dev->dev->of_node;
+ struct tps6507x_board *tps_board =
+ (struct tps6507x_board *)tps6507x_dev->dev->platform_data;
+ struct touchscreen_init_data *init_data = NULL;
+ u32 val32;
+ int err;
+
+ if (node)
+ node = of_find_node_by_name(node, "tsc");
+ if (tps_board)
+ init_data = tps_board->tps6507x_ts_init_data;
+
+ if (init_data) {
+ tps6507x_dev->ts->poll_period = init_data->poll_period;
+ tps6507x_dev->ts->min_pressure = init_data->min_pressure;
+ tps6507x_dev->ts->vref = init_data->vref;
+ input_dev->id.vendor = init_data->vendor;
+ input_dev->id.product = init_data->product;
+ input_dev->id.version = init_data->version;
+ } else if (node) {
+ err = of_property_read_u32(node, "ti,poll_period", );
+ if (err < 0)
+ goto error_ret;
+ else
+ tps6507x_dev->ts->poll_period = val32;
+
+ err = of_property_read_u32(node, "ti,min_pressure", );
+ if (err < 0)
+ goto error_ret;
+ else
+ tps6507x_dev->ts->min_pressure = val32;
+
+ err = of_property_read_u32(node, "ti,vref", );
+ if (err < 0)
+ goto error_ret;
+ else
+ tps6507x_dev->ts->vref = val32;
+
+ err = of_property_read_u32(node,
[PATCH V2 2/2] ARM: davinci: da850: add tps6507x touchscreen DT data
Add tps6507x touchscreen DT node to da850-evm.
Touchscreen DT data is added as per da850 board file.
Tested on da850-evm.
Signed-off-by: Vishwanathrao Badarkhe, Manish
---
Changes since V1:
- Updated commit message.
:100644 100644 c914357... 9c136d1... M arch/arm/boot/dts/da850-evm.dts
arch/arm/boot/dts/da850-evm.dts |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index c914357..9c136d1 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -155,4 +155,13 @@
regulator-boot-on;
};
};
+
+ tsc {
+ ti,poll_period = <30>;
+ ti,min_pressure = <0x30>;
+ ti,vref = <0>;
+ ti,vendor = <0>;
+ ti,product = <65070>;
+ ti,version = <0x100>;
+ };
};
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 0/2] Add DT support for tps6507x touchscreen
Patch set adds DT support for tps6507x based touchscreen Also, add DT data for tps6507x touchscreen in da850-evm by providing touchscreen node inside tps6507x mfd device. This patch series applies on top of linux-next tree and depends on [1]. [1]tps6507x-ts: update to devm_* API https://patchwork.kernel.org/patch/2324441/ Tested on da850-evm board. Changes since V1: - Updated tps6507x documentation. - Updated commit message. - return proper error value in absence platform and DT data for touchscreen. Vishwanathrao Badarkhe, Manish (2): tps6507x-ts: Add DT support ARM: davinci: da850: add tps6507x touchscreen DT data Documentation/devicetree/bindings/mfd/tps6507x.txt | 28 +- arch/arm/boot/dts/da850-evm.dts|9 ++ drivers/input/touchscreen/tps6507x-ts.c| 105 ++-- 3 files changed, 111 insertions(+), 31 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[REGRESSION] bisected: 3.8 -> 3.9 cannot umount after using fuse
Mount some filesystem, below that mountpoint as user mount some fuse fs (tried that with sshfs and fuseiso, both same error), fusermount -u the fuse fs, try to unmount the filesystem -> busy. ml@lara:~> id -u 500 ml@lara:~> grep test /etc/fstab /dev/vg1/test /mnt2 ext4acl,user_xattr,user,noauto 0 0 ml@lara:~> mount /mnt2 ml@lara:~> cd /mnt2 ml@lara:/mnt2> ls -l insgesamt 24 drwx-- 2 root root 16384 4. Mai 11:24 lost+found drwxr-xr-x 2 root root 4096 4. Mai 11:44 test drwxr-xr-x 2 ml users 4096 4. Mai 11:25 xenia ml@lara:/mnt2> sshfs xenia: xenia Password: ml@lara:/mnt2> ls xenia/bla xenia/bla ml@lara:/mnt2> fusermount -u xenia ml@lara:/mnt2> cd ml@lara:~> umount /mnt2 umount: /mnt2: target is busy. (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1)) ml@lara:~> fuser -m /mnt2 ml@lara:~> It does'nt matter if the mounting and unmounting of the /mnt2 filesystem is done as user or as root, same result. This works in 3.8(.x). Bisecting yields 57eccb830f1cc93d4b506ba306d8dfa685e0c88f is the first bad commit commit 57eccb830f1cc93d4b506ba306d8dfa685e0c88f Author: Al Viro Date: Fri Feb 22 22:49:10 2013 -0500 mount: consolidate permission checks ... and ask for global CAP_SYS_ADMIN only for superblock-level remounts Signed-off-by: Al Viro :04 04 4e926c083f6ede645158f02714d73cdd3b233a05 584611744bad96544578259a6fa176577df0ebbd M fs After reverting 57eccb830f1cc93d4b506ba306d8dfa685e0c88f from 3.9 that umount above works (not busy). I've seen that this patch also was identified as problem in relation with user ns and module loading, see lkml cagxu5jlciqxcuhzdvpkpqa+mwv8e28zgamscatzov3u07bu...@mail.gmail.com After fixing this upstream the fix should be an stabile candidate. -- MfG, Michael Leun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] power_supply: pm2301_charger: Fix module alias prefix
This driver is a i2c driver, use "i2c" rather than "platform" prefix for module
alias.
Signed-off-by: Axel Lin
---
drivers/power/pm2301_charger.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/power/pm2301_charger.c b/drivers/power/pm2301_charger.c
index a441751..fef56e2 100644
--- a/drivers/power/pm2301_charger.c
+++ b/drivers/power/pm2301_charger.c
@@ -1269,5 +1269,5 @@ module_exit(pm2xxx_charger_exit);
MODULE_LICENSE("GPL v2");
MODULE_AUTHOR("Rajkumar kasirajan, Olivier Launay");
-MODULE_ALIAS("platform:pm2xxx-charger");
+MODULE_ALIAS("i2c:pm2xxx-charger");
MODULE_DESCRIPTION("PM2xxx charger management driver");
--
1.8.1.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: [PATCH -next] power: fix bq27x00_battery kconfig
On 05/04/2013 12:11 PM, zhou jencce wrote: > 2013/5/3 Lars-Peter Clausen : >> On 05/03/2013 11:56 AM, Xiong Zhou wrote: >>> From: Xiong Zhou >>> >>> This patch fixes build failure(randconfig) of next-20130501. >>> When config I2C as m, BATTERY_BQ27x00 as y, here comes the failure. >>> BATTERY_BQ27x00 depends on I2C according to the code. >>> >> >>> Failure message: >>> drivers/built-in.o: In function `bq27x00_read_i2c': >>> bq27x00_battery.c:(.text+0x1082a7): undefined reference to `i2c_transfer' >>> drivers/built-in.o: In function `bq27x00_battery_init': >>> bq27x00_battery.c:(.init.text+0x6085): undefined reference to >>> `i2c_register_driver' >>> bq27x00_battery.c:(.init.text+0x60c7): undefined reference to >>> `i2c_del_driver' >>> drivers/built-in.o: In function `bq27x00_battery_exit': >>> bq27x00_battery.c:(.exit.text+0xbf0): undefined reference to >>> `i2c_del_driver' >>> make: *** [vmlinux] Error 1 >>> >>> Signed-off-by: Xiong Zhou >> >> It's actually a bit more tricky. The driver can be built without I2C > > What about the build error ? > The built error only happens if the driver is built-in and I2C is built as a module. Every other combination works fine. E.g. if I2C is disabled the driver builds just fine. So the driver only depends on I2C if I2C is not disabled. >> support, so it does not depend on I2C, but if I2C is built as a module the >> driver should also only be built as a module. > > And this is what this patch trying to do. > >> >> I think the best solution is to put the platform code and the i2c code of >> the bq27x00 driver each in their on module, but if you want a quick solution > > Yes, more clear. > >> >> depends on I2C || I2C=n >> >> should work. >> > > Thanks. :) > >>> --- >>> drivers/power/Kconfig |1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig >>> index 0d0b5d7..89e5ebd 100644 >>> --- a/drivers/power/Kconfig >>> +++ b/drivers/power/Kconfig >>> @@ -152,6 +152,7 @@ config BATTERY_SBS >>> >>> config BATTERY_BQ27x00 >>> tristate "BQ27x00 battery driver" >>> + depends on I2C >>> help >>> Say Y here to enable support for batteries with BQ27x00 (I2C/HDQ) >>> chips. >>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >>> the body of a message to majord...@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> Please read the FAQ at http://www.tux.org/lkml/ >> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 -next] power: fix bq27x00_battery kconfig
2013/5/3 Lars-Peter Clausen : > On 05/03/2013 11:56 AM, Xiong Zhou wrote: >> From: Xiong Zhou >> >> This patch fixes build failure(randconfig) of next-20130501. >> When config I2C as m, BATTERY_BQ27x00 as y, here comes the failure. >> BATTERY_BQ27x00 depends on I2C according to the code. >> > >> Failure message: >> drivers/built-in.o: In function `bq27x00_read_i2c': >> bq27x00_battery.c:(.text+0x1082a7): undefined reference to `i2c_transfer' >> drivers/built-in.o: In function `bq27x00_battery_init': >> bq27x00_battery.c:(.init.text+0x6085): undefined reference to >> `i2c_register_driver' >> bq27x00_battery.c:(.init.text+0x60c7): undefined reference to >> `i2c_del_driver' >> drivers/built-in.o: In function `bq27x00_battery_exit': >> bq27x00_battery.c:(.exit.text+0xbf0): undefined reference to `i2c_del_driver' >> make: *** [vmlinux] Error 1 >> >> Signed-off-by: Xiong Zhou > > It's actually a bit more tricky. The driver can be built without I2C What about the build error ? > support, so it does not depend on I2C, but if I2C is built as a module the > driver should also only be built as a module. And this is what this patch trying to do. > > I think the best solution is to put the platform code and the i2c code of > the bq27x00 driver each in their on module, but if you want a quick solution Yes, more clear. > > depends on I2C || I2C=n > > should work. > Thanks. :) >> --- >> drivers/power/Kconfig |1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig >> index 0d0b5d7..89e5ebd 100644 >> --- a/drivers/power/Kconfig >> +++ b/drivers/power/Kconfig >> @@ -152,6 +152,7 @@ config BATTERY_SBS >> >> config BATTERY_BQ27x00 >> tristate "BQ27x00 battery driver" >> + depends on I2C >> help >> Say Y here to enable support for batteries with BQ27x00 (I2C/HDQ) >> chips. >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] pagemap: Introduce the /proc/PID/pagemap2 file
On 05/02/2013 09:08 PM, Matt Helsley wrote: > On Thu, Apr 11, 2013 at 03:29:41PM +0400, Pavel Emelyanov wrote: >> This file is the same as the pagemap one, but shows entries with bits >> 55-60 being zero (reserved for future use). Next patch will occupy one >> of them. > > This approach doesn't scale as well as it could. As best I can see > CRIU would do: > > for each vma in /proc//smaps > for each page in /proc//pagemap2 > if soft dirty bit > copy page > > (possibly with pfn checks to avoid copying the same page mapped in > multiple locations..) Comparing pfns got from two subsequent pagemap reads doesn't help at all. If they are equal, this can mean that either page is shared or (less likely, but still) that the page, that used to be at the 1st pagemap was reclaimed and mapped to the 2nd between two reads. If they differ, it can again mean either not-shared (most likely) or shared (pfns were equal, but got reclaimed and swapped in back). Some better API for pages sharing would be nice, probably such API could be also re-used for the user-space KSM :) > However, if soft dirty bit changes could be queued up (from say the > fault handler and page table ops that map/unmap pages) and accumulated > in something like an interval tree it could be something like: > > for each range of changed pages > for each page in range > copy page > > IOW something that scales with the number of changed pages rather > than the number of mapped pages. > > So I wonder if CRIU would abandon pagemap2 in the future for something > like this. We'd surely adopt such APIs is one exists. One thing to note about one is that we'd also appreciate if this API would be able to batch "present" bits as well as "swapped" and "page-file" ones. We use these three in CRIU as well, and these bits scanning can also be optimized. > Cheers, > -Matt Helsley > Thanks, Pavel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
electric hoist supplier
Dear Boss:
Nice day!
It is my big pleasure to hear you need chain hoist
we have chain hoist. electric hoist and so on
If you still need it pls inform me
Pls reply me let us contact details
Best wishes
Ida
Sales manager
EAST SIWEITE INDUSTRY CO., LIMITED
www.dfswt.com
Skype: siweite
email:s...@swtindustry.comn�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{��赙zXФ�≤�}��财�z�:+v�����赙zZ+��+zf＂�h���~i���z� �wア�?�ㄨ��&�)撷f��^j谦y�m��@A�a囤�
0鹅h���i
Re: KVM VM(rhel-5.5) %si is too high when TX/RX packets
>> I running a VM(RHEL-5.5) on KVM hypervisor(linux-3.8 + QEMU-1.4.1),
>> and direct-assign intel 82576 VF to the VM. When TX/RX packets on VM to the
>> other host via iperf tool, top tool result on VM shown that the %si is too
>> high, approximately 95% ~ 100%, but from the view of host, the VM's total
>> CPU usage is about 20% - 30%. And the throughput rate is approximately
>> 200Mb/s, far from the line rate 1Gb/s, And, I found the hardirq rate is
>> lower than normal by running "watch -d -n 1 cat /proc/interrupts", I think
>> it's caused by the too high %si, because the NIC's hardirq was disabled
>> during the softirq process.
>> Then, I direct-assign the intel 82576 to the VM, the same case happened too.
>> I found the intel 82576 and intel 82576 VF's interrupt mode are both
>> PCI-MSI-X.
>>
>> And,
>> I rmmod the igb driver, and, re-insmod the igb driver(igb-4.1.2) with the
>> parameter IntMode=0/1(0:legacy, 1:MSI, 2:MSI-x), the problem then gone, the
>> %si is approximately 20% -30%, and the throughput rate came to the line
>> rate, about 940Mb/s.
>> I update the VM to RHEL-6.1, the problem disappeared too.
>> And, I found a very strange thing, the VM's 82576VF's irq routing is set one
>> time on Vf's one interrupt received, so frequently.
>
>RHEL 5.5 is a very old update. Can you try RHEL 5.9?
>
>In any case, this looks a lot like a bug in the version of the driver that was
>included in RHEL5.5; you should contact Red Hat support services if you can
>still reproduce it with the latest RHEL5 update.
>
>Paolo
One patch has been proposed to QEMU, shown as below,
[PATCH] [KVM] Needless to update msi route when only msi-x entry "control"
section changed
With regard to old version linux guest(e.g., rhel-5.5), in ISR processing, mask
and unmask msi-x vector every time, which result in VMEXIT, then QEMU will
invoke kvm_irqchip_update_msi_route() to ask KVM hypervisor to update the VM
irq routing table. In KVM hypervisor, synchronizing RCU needed after updating
routing table, so much time consumed for waiting in wait_rcu_gp(). So CPU usage
in VM is so high, while from the view of host, VM's total CPU usage is so low.
Masking/unmasking msi-x vector only set msi-x entry "control" section, needless
to update VM irq routing table.
hw/i386/kvm/pci-assign.c | 3 +++
1 files changed, 3 insertions(+)
--- a/hw/i386/kvm/pci-assign.c 2013-05-04 15:53:18.0 +0800
+++ b/hw/i386/kvm/pci-assign.c 2013-05-04 15:50:46.0 +0800
@@ -1576,6 +1576,8 @@ static void assigned_dev_msix_mmio_write
MSIMessage msg;
int ret;
+/* Needless to update msi route when only msi-x entry
"control" section changed */
+if ((addr & (PCI_MSIX_ENTRY_SIZE - 1)) !=
PCI_MSIX_ENTRY_VECTOR_CTRL){
msg.address = entry->addr_lo |
((uint64_t)entry->addr_hi << 32);
msg.data = entry->data; @@ -1585,6 +1587,7 @@ static void
assigned_dev_msix_mmio_write
if (ret) {
error_report("Error updating irq routing entry (%d)", ret);
}
+}
}
}
}
Thanks,
Zhang Haoyu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Intel-gfx] [PATCH] [TRIVIAL] Fix declaration of intel_gmbus_{is_forced_bit/is_port_falid} in i915 driver.
On 3 May 2013 at 15:03, Jani Nikula wrote: > >> This fixes a compilation issue with clang. An initial version of this patch > >> was developed by PaX Team . > >> This is respin of this patch. > >> > >> Signed-off-by: Jan-Simon Möller > >> CC: pagee...@freemail.hu > >> CC: daniel.vet...@ffwll.ch > >> CC: airl...@linux.ie > >> CC: intel-...@lists.freedesktop.org > >> CC: dri-de...@lists.freedesktop.org > >> CC: linux-kernel@vger.kernel.org > > Picked up for -fixes, thanks for the patch. > > Please drop it. > > The patch removes the inline keyword, creating dozens of copies of the > functions, and consequently loads of warnings: in my original patch they were both static inline, not sure where the inline got lost... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Regression: ftdi_sio is slow (since Wed Oct 10 15:05:06 2012)
04.05.2013 00:34, Greg KH пишет: Don't call select for every character :) OK, let me draw an approximate workflow of the setup in question. Lets say we have 3 tty devices, A, B and C. A and B are blazingly fast, while C is a casual usb-serial chip. The app must establish a bidirectional relay between A and C, making sure that the output queue on C never exceeds some margin M. B is used for acknowledges: the next char from A will arrive only after an acknowledge is sent via B. Here's what the app approximately does: 1. select() on A and C for _input only_. 2. relay the char 3. if the char was from A, send ack to B and increment an ack counter (call that counter Q). 4. If Q>N (N is a threshold value that should be below M, currently 14), do TIOCOUTQ ioctl to make sure C is not overflowing, set Q to the value returned by TIOCOUTQ. If Q still above N, stop sending acks to B and do TIOCOUTQ periodically, until Q is below N, then resume the normal operations. 5. goto 1 So that's the workflow, and it used to work perfectly in the past. Now even on step 1, when select returns, there is already a big delay. Not to speak about TIOCOUTQ, a very funny way to query the buffer: the buffer is now entirely flushed while we query it. What exactly is so horrible here that it was deserved to break? How to improve the algo? And no, we can't improve the protocol. For instance, we can't send multiple acks and hope that multiple chars will be received from A - the protocol cannot be changed. Any suggestions? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/urgent] perf/x86/intel/lbr: Demand proper privileges for PERF_SAMPLE_BRANCH_KERNEL
Commit-ID: 0f5c78b5f33ce940034743e5f9485fc81ad75b0f
Gitweb: http://git.kernel.org/tip/0f5c78b5f33ce940034743e5f9485fc81ad75b0f
Author: Peter Zijlstra
AuthorDate: Fri, 3 May 2013 14:11:25 +0200
Committer: Ingo Molnar
CommitDate: Sat, 4 May 2013 08:37:48 +0200
perf/x86/intel/lbr: Demand proper privileges for PERF_SAMPLE_BRANCH_KERNEL
We should always have proper privileges when requesting kernel
data.
Signed-off-by: Peter Zijlstra
Cc:
Cc: Andi Kleen
Cc: eran...@google.com
Link: http://lkml.kernel.org/r/20130503121256.230745...@chello.nl
Signed-off-by: Ingo Molnar
Link: http://lkml.kernel.org/n/tip-v0x9ky3ahzr6nm3c6ilwr...@git.kernel.org
---
arch/x86/kernel/cpu/perf_event_intel_lbr.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
index de341d4..0e92871 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
@@ -318,8 +318,11 @@ static void intel_pmu_setup_sw_lbr_filter(struct
perf_event *event)
if (br_type & PERF_SAMPLE_BRANCH_USER)
mask |= X86_BR_USER;
- if (br_type & PERF_SAMPLE_BRANCH_KERNEL)
+ if (br_type & PERF_SAMPLE_BRANCH_KERNEL) {
+ if (perf_paranoid_kernel() && !capable(CAP_SYS_ADMIN))
+ return -EACCES;
mask |= X86_BR_KERNEL;
+ }
/* we ignore BRANCH_HV here */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/urgent] perf/x86/intel/lbr: Fix LBR filter
Commit-ID: 6e15eb3ba6c0249c9e8c783517d131b47db995ca
Gitweb: http://git.kernel.org/tip/6e15eb3ba6c0249c9e8c783517d131b47db995ca
Author: Peter Zijlstra
AuthorDate: Fri, 3 May 2013 14:11:24 +0200
Committer: Ingo Molnar
CommitDate: Sat, 4 May 2013 08:37:47 +0200
perf/x86/intel/lbr: Fix LBR filter
The LBR 'from' adddress is under full userspace control; ensure
we validate it before reading from it.
Note: is_module_text_address() can potentially be quite
expensive; for those running into that with high overhead
in modules optimize it using an RCU backed rb-tree.
Reported-by: Andi Kleen
Signed-off-by: Peter Zijlstra
Cc:
Cc: eran...@google.com
Link: http://lkml.kernel.org/r/20130503121256.158211...@chello.nl
Signed-off-by: Ingo Molnar
Link: http://lkml.kernel.org/n/tip-mk8i82ffzax01cnqo829i...@git.kernel.org
---
arch/x86/kernel/cpu/perf_event_intel_lbr.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
index da02e9c..de341d4 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
@@ -442,8 +442,18 @@ static int branch_type(unsigned long from, unsigned long
to)
return X86_BR_NONE;
addr = buf;
- } else
- addr = (void *)from;
+ } else {
+ /*
+* The LBR logs any address in the IP, even if the IP just
+* faulted. This means userspace can control the from address.
+* Ensure we don't blindy read any address by validating it is
+* a known text address.
+*/
+ if (kernel_text_address(from))
+ addr = (void *)from;
+ else
+ return X86_BR_NONE;
+ }
/*
* decoder needs to know the ABI especially
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/urgent] perf/x86: Blacklist all MEM_*_RETIRED events for Ivy Bridge
Commit-ID: 741a698f420c34c458294a6accecfbad702a7c52 Gitweb: http://git.kernel.org/tip/741a698f420c34c458294a6accecfbad702a7c52 Author: Peter Zijlstra AuthorDate: Fri, 3 May 2013 14:11:23 +0200 Committer: Ingo Molnar CommitDate: Sat, 4 May 2013 08:37:46 +0200 perf/x86: Blacklist all MEM_*_RETIRED events for Ivy Bridge Errata BV98 states that all MEM_*_RETIRED events corrupt the counter value of the SMT sibling's counters. Blacklist these events Reported-by: Andi Kleen Signed-off-by: Peter Zijlstra Cc: Cc: eran...@google.com Link: http://lkml.kernel.org/r/20130503121256.083340...@chello.nl Signed-off-by: Ingo Molnar Link: http://lkml.kernel.org/n/tip-jwra43mujrv1oq9xk6mfe...@git.kernel.org --- arch/x86/kernel/cpu/perf_event_intel.c | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/arch/x86/kernel/cpu/perf_event_intel.c b/arch/x86/kernel/cpu/perf_event_intel.c index cc45deb..4a0a462 100644 --- a/arch/x86/kernel/cpu/perf_event_intel.c +++ b/arch/x86/kernel/cpu/perf_event_intel.c @@ -125,10 +125,15 @@ static struct event_constraint intel_ivb_event_constraints[] __read_mostly = INTEL_UEVENT_CONSTRAINT(0x08a3, 0x4), /* CYCLE_ACTIVITY.CYCLES_L1D_PENDING */ INTEL_UEVENT_CONSTRAINT(0x0ca3, 0x4), /* CYCLE_ACTIVITY.STALLS_L1D_PENDING */ INTEL_UEVENT_CONSTRAINT(0x01c0, 0x2), /* INST_RETIRED.PREC_DIST */ - INTEL_EVENT_CONSTRAINT(0xd0, 0xf), /* MEM_UOPS_RETIRED.* */ - INTEL_EVENT_CONSTRAINT(0xd1, 0xf), /* MEM_LOAD_UOPS_RETIRED.* */ - INTEL_EVENT_CONSTRAINT(0xd2, 0xf), /* MEM_LOAD_UOPS_LLC_HIT_RETIRED.* */ - INTEL_EVENT_CONSTRAINT(0xd3, 0xf), /* MEM_LOAD_UOPS_LLC_MISS_RETIRED.* */ + /* +* Errata BV98 -- MEM_*_RETIRED events can leak between counters of SMT +* siblings; disable these events because they can corrupt unrelated +* counters. +*/ + INTEL_EVENT_CONSTRAINT(0xd0, 0x0), /* MEM_UOPS_RETIRED.* */ + INTEL_EVENT_CONSTRAINT(0xd1, 0x0), /* MEM_LOAD_UOPS_RETIRED.* */ + INTEL_EVENT_CONSTRAINT(0xd2, 0x0), /* MEM_LOAD_UOPS_LLC_HIT_RETIRED.* */ + INTEL_EVENT_CONSTRAINT(0xd3, 0x0), /* MEM_LOAD_UOPS_LLC_MISS_RETIRED.* */ EVENT_CONSTRAINT_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/
Re: [PATCH 1/8] perf tools: Add '.' as part of the event 'name' token
* Peter Zijlstra wrote: > > I meant to add that I think it would be more productive if we (you and I) > > were > > to work on the library to extend it with external text-based event tables > > that > > could be used by perf either directly or thru the libpfm4 interface. > > That would be very useful indeed.. I think we talked about this before. > Also wasn't there some vendor support for this idea as well? > > I think we want a format that is relatively simple to parse and human > readable (which excludes XML on both counts ;-). > > The main objection of using libpfm4 has always been that its primarily > something else. It also does the event listing thing, but that's only a > small part of it. > > But if we can split out that part and use it in both projects that would > be best I think. If that libpfm reference library moved to tools/lib/ like tools/lib/traceevents/ then that would be a nice, useful solution indeed. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] drm for 3.10-rc1
On Sat, May 4, 2013 at 3:18 AM, Josh Boyer wrote: > On Fri, May 03, 2013 at 10:40:17PM +0200, Daniel Vetter wrote: >>On Fri, May 3, 2013 at 10:31 PM, Josh Boyer wrote: >>> OK. Git bisect tells me this: >>> >>> 57c219633275c7e7413f8bc7be250dc092887458 is the first bad commit >>> commit 57c219633275c7e7413f8bc7be250dc092887458 >>> Author: Daniel Vetter >>> Date: Thu Apr 4 17:19:37 2013 +0200 >>> >>> drm/i915: revert eDP bpp clamping code changes >> >>Yeah, that commit is a bit dubios and for 3.11 we've already planned >>to kick it out. It tries to work around an issue on a funky >>pre-release hw. Does reverting this commit fix your issue? > > Yes, seems so. I reverted it on top of Linus tree as of commit > ce857229e0c3adc2 and things boot normally on the machine after that. Thanks for confirming, I've reverted the patch and will foward my current drm-intel-fixes tree soon to Dave. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 7/8] genirq: generic chip: Add linear irq domain support
On Sat, 4 May 2013, Sebastian Hesselbarth wrote:
> On 05/03/2013 11:50 PM, Thomas Gleixner wrote:
> > Provide infrastructure for irq chip implementations which work on
> > linear irq domains.
>
> Thomas,
>
> I am happy that I put you into rant mode. It took me little more
> than an hour to read through your patches, prepare orion irqchip
> driver on top of them and finally got it working.
Cool.
> Anyway, I found some more issues.
That was expected. :)
> > + for (i = 0; i < numchips; i++, gc++) {
>
> The memory you allocated for gc, num_ct * ct, and dgc doesn't allow
> to increment through gc. gc is struct irq_chip_generic * but next
> gc is at sizeof(*gc) + num_ct * sizeof(struct irq_chip_type).
> This also affects indexing dgc->gc later.
Indeed.
> I chose to fix it by having an index helper but that first maps
> dgc-gc to unsigned char * and then adds the correct offset. Not
void * is the preferred over uchar *
> nice but it works. Maybe having real array of ptr to gc is more
> intuitive here even if we will have to have split kzallocs.
No, you still can have a single kzalloc. It's just a matter of setting
the pointers correctly.
> > + irq_init_generic_chip(gc, name, num_ct, i * irqs_per_chip,
> > + NULL, handler);
>
> irq_init_generic_chip does not take care of initalizing ct
> mask_cache ptr. This should be done here.
Right.
> > + gc->domain = d;
> > + raw_spin_lock_irqsave(_lock, flags);
> > + list_add_tail(>list, _list);
> > + raw_spin_unlock_irqrestore(_lock, flags);
> > + }
> > + d->gc = dgc;
>
> Moving this assignment above the for loop allows to get
> gc by index as indexing helper relies on domain, not domain
> generic chip.
>
> You want me to prepare patches for the above? Maybe you can
That'd be nice.
> split your RFC into 1-6 and 7-8. Then you can have 1-6 applied
> independently of irq_domain_generic_chip stuff.
> Thanks for the RFC again!
Welcome. Have fun!
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: 3.9.0 + CONFIG_X86_INTEL_PSTATE=y -> ThinkPad T420 with i5 lost ACPI functionality
On 05/03/2013 11:43 PM, Dirk Brandewie wrote: > On 05/03/2013 02:26 PM, Toralf Förster wrote: >> On 05/03/2013 11:10 PM, Dirk Brandewie wrote: >>> >>> ignore_nice_load is a feature of the ondemand governor. >>> The intel_pstate driver is seeing the load presented by the BOINC client >>> and is adjusting the pstate accordingly. >> >> Is the intel_pstate driver a choice for a notebook and friends where a >> grid software is running as a low-prio back ground job ? >> > > Probably not. Hhm. The kernel menuconfig says : This driver provides a P state for Intel core processors The driver implements an internal governor and will become the scaling driver and governor for Sandy bridge processors. What shall a company like IBM with a lot of notebook installation running BOINC in the back ground process (World Community Grid) do - what's the consequence for those installations if they will have that a processor ? In the past (few years ago and related to the ondemand governor IIRC) there were already a longer discussion about the "nice -n 19" topic and the result was to support it. /me Cc:'ing boinc devs, the topic might be interesting for them too. >> Because the CPU will be running mostly at high(er) frequency - which >> always results in a high temperature and short battery time. >> > > It would be better IMHO if the client software limited the resources > it uses when the system is not on wall power but that is a seperate > discussion :-) > > --Dirk > > -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Give the OID registry file module info to avoid kernel tainting
Give the OID registry file module information so that it doesn't taint the
kernel when compiled as a module and loaded.
Reported-by: Dros Adamson
Signed-off-by: David Howells
cc: Trond Myklebust
cc: sta...@vger.kernel.org
cc: linux-...@vger.kernel.org
---
lib/oid_registry.c |5 +
1 file changed, 5 insertions(+)
diff --git a/lib/oid_registry.c b/lib/oid_registry.c
index d8de11f..318f382 100644
--- a/lib/oid_registry.c
+++ b/lib/oid_registry.c
@@ -9,6 +9,7 @@
* 2 of the Licence, or (at your option) any later version.
*/
+#include
#include
#include
#include
@@ -16,6 +17,10 @@
#include
#include "oid_registry_data.c"
+MODULE_DESCRIPTION("OID Registry");
+MODULE_AUTHOR("Red Hat, Inc.");
+MODULE_LICENSE("GPL");
+
/**
* look_up_OID - Find an OID registration for the specified data
* @data: Binary representation of the OID
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Give the OID registry file module info to avoid kernel tainting
Give the OID registry file module information so that it doesn't taint the
kernel when compiled as a module and loaded.
Reported-by: Dros Adamson
Signed-off-by: David Howells
cc: Trond Myklebust
cc: sta...@vger.kernel.org
cc: linux-...@vger.kernel.org
---
lib/oid_registry.c |5 +
1 file changed, 5 insertions(+)
diff --git a/lib/oid_registry.c b/lib/oid_registry.c
index d8de11f..318f382 100644
--- a/lib/oid_registry.c
+++ b/lib/oid_registry.c
@@ -9,6 +9,7 @@
* 2 of the Licence, or (at your option) any later version.
*/
+#include
#include
#include
#include
@@ -16,6 +17,10 @@
#include
#include "oid_registry_data.c"
+MODULE_DESCRIPTION("OID Registry");
+MODULE_AUTHOR("Red Hat, Inc.");
+MODULE_LICENSE("GPL");
+
/**
* look_up_OID - Find an OID registration for the specified data
* @data: Binary representation of the OID
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: KVM VM(rhel-5.5) %si is too high when TX/RX packets
Il 03/05/2013 06:05, Zhanghaoyu (A) ha scritto: > I running a VM(RHEL-5.5) on KVM hypervisor(linux-3.8 + QEMU-1.4.1), and > direct-assign intel 82576 VF to the VM. When TX/RX packets on VM to the other > host via iperf tool, top tool result on VM shown that the %si is too high, > approximately 95% ~ 100%, but from the view of host, the VM's total CPU usage > is about 20% - 30%. And the throughput rate is approximately 200Mb/s, far > from the line rate 1Gb/s, > And, I found the hardirq rate is lower than normal by running "watch -d -n 1 > cat /proc/interrupts", I think it's caused by the too high %si, because the > NIC's hardirq was disabled during the softirq process. > Then, I direct-assign the intel 82576 to the VM, the same case happened too. > I found the intel 82576 and intel 82576 VF's interrupt mode are both > PCI-MSI-X. > > And, > I rmmod the igb driver, and, re-insmod the igb driver(igb-4.1.2) with the > parameter IntMode=0/1(0:legacy, 1:MSI, 2:MSI-x), the problem then gone, the > %si is approximately 20% -30%, and the throughput rate came to the line rate, > about 940Mb/s. > I update the VM to RHEL-6.1, the problem disappeared too. > And, I found a very strange thing, the VM's 82576VF's irq routing is set one > time on Vf's one interrupt received, so frequently. RHEL 5.5 is a very old update. Can you try RHEL 5.9? In any case, this looks a lot like a bug in the version of the driver that was included in RHEL5.5; you should contact Red Hat support services if you can still reproduce it with the latest RHEL5 update. Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL 4/4] ARM: arm-soc board specific changes for 3.10, part 1
These changes are all for board specific files. These used to make up a large portion of the ARM changes in the past, but as we are generalizing the support and moving to device tree probing, this has gotten significantly smaller. The only platform actually adding new code here at the moment is Renesas shmobile, as they are still busy converting their code to device tree and have not come far enough to not need it. Conflicts: arch/arm/Kconfig.debug: Add/add conflict, keep both. The following changes since commit c77984fd31ca2b2a3227eae717587da60072685f: Merge branch 'next/firmware' into HEAD are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/boards-for-linus for you to fetch changes up to 21bdcc1a2ffce8c9bc7caad711401fff47f99c00: ARM: msm: USB_MSM_OTG needs USB_PHY Aaro Koskinen (2): ARM: OMAP1: fix omap_udc registration ARM: OMAP: RX-51: add missing regulator supply definitions for lis3lv02d Andrew Chew (1): ARM: OMAP: board-4430sdp: Provide regulator to pwm-backlight Arnaud Ebalard (1): ARM: kirkwood: Add support for NETGEAR ReadyNAS Duo v2 using DT Arnd Bergmann (6): ARM: shmobile: mark mackerel sh_mmcif_device __maybe_unused Merge tag 'renesas-boards-for-v3.10' of git://git.kernel.org/.../horms/renesas into next/boards Merge tag 'renesas-boards2-for-v3.10' of git://git.kernel.org/.../horms/renesas into next/boards Merge tag 'davinci-for-v3.10/board' of git://git.kernel.org/.../nsekhar/linux-davinci into next/boards Merge tag 'omap-for-v3.10/board-signed' of git://git.kernel.org/.../tmlind/linux-omap into next/boards ARM: msm: USB_MSM_OTG needs USB_PHY David Brown (1): ARM: msm: enable SSBI driver in defconfig Guennadi Liakhovetski (11): ARM: shmobile: use GPIO SD-card detection on armadillo800eva ARM: shmobile: switch SDHI0 to GPIO regulator on armadillo800eva ARM: shmobile: streamline mackerel SD and MMC devices ARM: shmobile: parse DT and configure pinmux early on kzm9g-reference ARM: shmobile: SDHI and MMCIF interfaces to kzm9g-reference ARM: shmobile: simplify kzm9g Kconfig dependencies ARM: shmobile: kzm9g: SDHI0 and SDHI1 use a 3.3V power supply ARM: shmobile: sh73a0: move SDHI and MMCIF DT nodes to sh73a0.dtsi ARM: shmobile: armadillo800eva: add a fixed voltage regulator for SDHI1 ARM: shmobile: kzm9g: add fixed voltage regulators for SDHI0 and SDHI2 ARM: shmobile: kzm9g-reference: fix device-tree bindings and device names Haojian Zhuang (5): ARM: pxa: remove cpu_is_xxx in gpio driver ARM: pxa: move PXA_GPIO_TO_IRQ macro ARM: mmp: add more compatible names in gpio driver ARM: pxa: select PXA935 on saar & tavorevb ARM: pxa: move debug uart code Kuninori Morimoto (1): ARM: shmobile: marzen: Use gic_iid macro for ICCIAR / interrupt ID Lad, Prabhakar (1): ARM: davinci: use is IS_ENABLED macro Olof Johansson (4): Merge branch 'armsoc/pxa' of git://github.com/hzhuang1/linux into next/boards Merge tag 'msm-defconfig-3.10' of git://git.kernel.org/.../davidb/linux-msm into next/boards Merge tag 'boards-3.10' of git://git.infradead.org/users/jcooper/linux into next/boards Merge tag 'davinci-for-v3.10/board-2-v2' of git://git.kernel.org/.../nsekhar/linux-davinci into next/boards Paul Bolle (2): omap2+: Remove useless Makefile line omap2+: Remove useless Makefile line Peter Ujfalusi (1): ARM: OMAP: zoom: Use pwm stack for lcd and keyboard backlight Robert Tivy (1): ARM: davinci: da850 board: add remoteproc support Ruslan Bilovol (1): ARM: OMAP2+: omap2plus_defconfig: Add support for BMP085 pressure sensor Sebastian Hesselbarth (1): ARM: kirkwood: add MACH_GURUPLUG_DT to defconfig Sekhar Nori (2): ARM: davinci: defconfig: enable CGROUPS ARM: davinci: da850 evm: fix const qualifier placement Simon Guinot (3): ARM: Kirkwood: sort board entries by ASCII-code order ARM: Kirkwood: DT board setup for CloudBox ARM: Kirkwood: update Network Space Mini v2 description Simon Horman (7): Merge branches 'soc' and 'pinmux' into boards-base ARM: shmobile: marzen: Reference DT implementation ARM: shmobile: kzm9g: Reference DT implementation ARM: shmobile: kzm9g: Remove warning about SMP ARM: shmobile: kzm9g: Trim reference DT_MACHINE_START ARM: shmobile: kzm9g: correct smsc regulator registration Revert "ARM: shmobile: streamline mackerel SD and MMC devices" Stephen Boyd (1): ARM: msm: Concentrate defconfig on DT supported devices .../devicetree/bindings/gpio/mrvl-gpio.txt | 7 +- arch/arm/Kconfig.debug | 9 + arch/arm/boot/dts/Makefile
[GIT PULL 3/4] ARM: platform specific firmware interfaces for 3.10
Two platforms, bcm and exynos have their own firmware interfaces using the "secure monitor call", this adds support for those. We had originally planned to have a third set of patches in here, which would extend support for the existing generic "psci" call that is used on multiple platforms as well as Xen and KVM guests, but that ended up getting dropped because the patches were not ready in time. Conflicts: None The following changes since commit c47ceb86748d75280ab478ac0bb76150cde90b7a: Merge branch 'next/renesas-pinctrl' into HEAD are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/firmware-for-linus for you to fetch changes up to 721e0205b07589223343737a9c421d8118d87bba: ARM: bcm: mark bcm_kona_smc_init as __init Arnd Bergmann (3): Merge branch 'exynos/clk' into next/firmware Merge tag 'secure-exynos-for-v3.10' of git://git.kernel.org/.../kgene/linux-samsung into next/firmware ARM: bcm: mark bcm_kona_smc_init as __init Christian Daudt (2): ARM: bcm281xx: Add L2 cache enable code ARM: bcm281xx: Add DT support for SMC handler Olof Johansson (1): Merge tag 'fw-for-3.10' of git://github.com/broadcom/bcm11351 into next/firmware Tomasz Figa (5): ARM: Add interface for registering and calling firmware-specific operations ARM: EXYNOS: Add support for secure monitor calls ARM: EXYNOS: Add support for Exynos secure firmware ARM: EXYNOS: Add IO mapping for non-secure SYSRAM. ARM: EXYNOS: Add secure firmware support to secondary CPU bring-up Documentation/arm/firmware.txt | 88 ++ .../devicetree/bindings/arm/samsung-boards.txt | 10 ++ Documentation/devicetree/bindings/misc/smc.txt | 14 +++ arch/arm/boot/dts/bcm11351.dtsi | 5 + arch/arm/common/Makefile| 2 + arch/arm/common/firmware.c | 18 +++ arch/arm/include/asm/firmware.h | 66 +++ arch/arm/mach-bcm/Makefile | 4 +- arch/arm/mach-bcm/bcm_kona_smc.c| 118 +++ arch/arm/mach-bcm/bcm_kona_smc.h| 80 + arch/arm/mach-bcm/bcm_kona_smc_asm.S| 41 +++ arch/arm/mach-bcm/board_bcm.c | 23 arch/arm/mach-exynos/Makefile | 6 + arch/arm/mach-exynos/common.c | 35 ++ arch/arm/mach-exynos/common.h | 2 + arch/arm/mach-exynos/exynos-smc.S | 22 arch/arm/mach-exynos/firmware.c | 70 +++ arch/arm/mach-exynos/include/mach/map.h | 3 + arch/arm/mach-exynos/mach-exynos4-dt.c | 1 + arch/arm/mach-exynos/platsmp.c | 32 - arch/arm/mach-exynos/smc.h | 31 + arch/arm/plat-samsung/include/plat/map-s5p.h| 1 + 22 files changed, 666 insertions(+), 6 deletions(-) create mode 100644 Documentation/arm/firmware.txt create mode 100644 Documentation/devicetree/bindings/misc/smc.txt create mode 100644 arch/arm/common/firmware.c create mode 100644 arch/arm/include/asm/firmware.h create mode 100644 arch/arm/mach-bcm/bcm_kona_smc.c create mode 100644 arch/arm/mach-bcm/bcm_kona_smc.h create mode 100644 arch/arm/mach-bcm/bcm_kona_smc_asm.S create mode 100644 arch/arm/mach-exynos/exynos-smc.S create mode 100644 arch/arm/mach-exynos/firmware.c create mode 100644 arch/arm/mach-exynos/smc.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/
[GIT PULL 1/4] ARM: arm-soc driver changes for 3.10
This is a rather large set of patches for device drivers that for one reason or another the subsystem maintainer preferred to get merged through the arm-soc tree. There are both new drivers as well as existing drivers that are getting converted from platform-specific code into standalone drivers using the appropriate subsystem specific interfaces. In particular, we can now have pinctrl, clk, clksource and irqchip drivers in one file per driver, without the need to call into platform specific interface, or to get called from platform specific code, as long as all information about the hardware is provided through a device tree. Most of the drivers we touch this time are for clocksource. Since now most of them are part of drivers/clocksource, I expect that we won't have to touch these again from arm-soc and can let the clocksource maintainers take care of these in the future. Another larger part of this series is specific to the exynos platform, which is seeing some significant effort in upstreaming and modernization of its device drivers this time around, which unfortunately is also the cause for the churn and a lot of the merge conflicts. There is one new subsystem that gets merged as part of this series: the reset controller interface, which is a very simple interface for taking devices on the SoC out of reset or back into reset. Patches to use this interface on i.MX follow later in this merge window, and we are going to have other platforms (at least tegra and sirf) get converted in 3.11. This will let us get rid of platform specific callbacks in a number of platform independent device drivers. Conflicts: arch/arm/Kconfig: - Remove/change conflict. Take out the HAVE_ARM_TWD select. - Change/change conflict on ARCH_NR_GPIO. Keep 392 for U8500 and the split VT8500/SUNXI entries arch/arm/mach-omap2/*: Keep all versions from the branch (caused by a duplicate commits from the ARM tree). drivers/clocksource/Makefile: Add/add, keep both. drivers/irqchip/Makefile: Add/add, keep both. This file can do with a fresh sorting at some point. drivers/irqchip/irq-s3c24xx.c: - Include statements: Add/add, keep both. - reg_pending change: Keep first line from HEAD and second from branch. drivers/pinctrl/pinctrl-samsung.c: Add/add. Move new 5250 entry up into upper ifdef. drivers/pinctrl/pinctrl-samsung.h: Add/add, keep both. The following changes since commit 1db772216f48978d5146b858586f6178433aad38: Merge branch 'for-3.10' of git://linux-nfs.org/~bfields/linux are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/drivers-for-linus for you to fetch changes up to bc8fd900c4d460b4e4bf785bb48bfced0ac9941b: irqchip: s3c24xx: add missing __init annotations Abhilash Kesavan (1): ARM: dts: Add max77686 device tree support for CROS5250 Andrzej Hajda (1): clk: exynos4: Add missing CMU_TOP and ISP clocks Arnd Bergmann (25): Merge branch 'next/timer-samsung' of git://git.kernel.org/.../kgene/linux-samsung into next/drivers Merge branch 'next/irq-s3c24xx' of git://git.kernel.org/.../kgene/linux-samsung into next/drivers Merge branch 'next/pinctrl-exynos' of git://git.kernel.org/.../kgene/linux-samsung into next/drivers Merge tag 'at91-driversLCD' of git://github.com/at91linux/linux-at91 into next/drivers Merge tag 'renesas-intc-external-irq-for-v3.10' of git://git.kernel.org/.../horms/renesas into next/drivers Merge tag 'renesas-clocksource-for-v3.10' of git://git.kernel.org/.../horms/renesas into next/drivers Merge tag 'renesas-intc-external-irq2-for-v3.10' of git://git.kernel.org/.../horms/renesas into next/drivers Merge tag 'vt8500/pinctrl' of git://server.prisktech.co.nz/git/linuxwmt into next/drivers Merge branch 'zynq/clksrc/cleanup' of git://git.xilinx.com/linux-xlnx into next/drivers Merge tag 'omap-for-v3.10/usb-signed' of git://git.kernel.org/.../tmlind/linux-omap into next/drivers Merge tag 'omap-for-v3.10/timer-signed' of git://git.kernel.org/.../tmlind/linux-omap into next/drivers Merge tag 'omap-for-v3.10/gpmc-signed' of git://git.kernel.org/.../tmlind/linux-omap into next/drivers Merge branch 'tegra/soc' into next/drivers Merge branch 'depends/clk' into next/drivers Merge tag 'tegra-for-3.10-clk' of git://git.kernel.org/.../swarren/linux-tegra into next/drivers Merge tag 'ux500-pinctrl' of git://git.kernel.org/.../linusw/linux-stericsson into next/drivers Merge tag 'irq-s3c24xx-for-v3.10' of git://git.kernel.org/.../kgene/linux-samsung into next/drivers Merge tag 'mct-exynos-for-v3.10' of git://git.kernel.org/.../kgene/linux-samsung into next/drivers Merge tag 'clk-exynos-for-v3.10' of git://git.kernel.org/.../kgene/linux-samsung into next/drivers Merge tag
[GIT PULL 2/4] ARM: arm-soc pinctrl changes for Renesas for 3.10
This is yet another driver change, which is split out just because of its size. As already in 3.9, a lot of changes are going on here, as the shmobile platform gets converted from its own pin control API to the generic drivers/pinctrl subsystem. Based on agreements with Paul Mundt, we are merging the sh-arch-side changes here as well. Conflicts: arch/arm/mach-shmobile/board-armadillo800eva.c: Change/remove conflict. Remove. The following changes since commit 01e34577d8840a5f46693b6231eb6f5a334bb1ae: Merge branch 'next/drivers' into HEAD are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/renesas-pinctrl-for-linus for you to fetch changes up to cb3daf580a6bd798580d274a164e63a598d165c5: Merge tag 'renesas-pinmux-for-v3.10' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into next/renesas-pinctrl Arnd Bergmann (1): Merge tag 'renesas-pinmux-for-v3.10' of git://git.kernel.org/.../horms/renesas into next/renesas-pinctrl Guennadi Liakhovetski (5): sh-pfc: Fix a typo and simplify a definition on sh73a0 ARM: shmobile: sh73a0: Support sparse GPIO numbers sh-pfc: sh7372: Add SDHCI and MMCIF pin groups and functions sh-pfc: sh73a0: Add SDHI and MMCIF pin groups and functions sh-pfc: r8a7740: Add SDHI and MMCIF pin groups and functions Laurent Pinchart (136): sh-pfc: Declare operation structures as const sh-pfc: Don't define the per-device pinctrl struct instances as global sh-pfc: Drop the sh_pfc_pinctrl spinlock sh-pfc: Don't take the sh_pfc spinlock in sh_pfc_map_gpios() sh-pfc: Use GPIO_FN instead of PINMUX_GPIO where possible sh-pfc: Replace first_gpio and last_gpio with nr_gpios sh-pfc: Replace SoC info data and mark ranges with a number of pins sh-pfc: Remove unused sh_pfc_soc_info reserved_id field sh-pfc: Initialize pinmux_gpio flags statically sh-pfc: Make struct pinmux_gpio enum_id field const sh-pfc: Shrink the pinctrl GPIO range to include real GPIOs only sh-pfc: Don't needlessly check GPIO type in sh_gpio_free() sh-pfc: Split pins and functions definition tables sh-pfc: Split pins and functions into separate gpio_chip instances sh-pfc: Rename struct pinmux_pin to struct sh_pfc_pin sh-pfc: Look up IRQ table entries by GPIO number sh-pfc: Share the PORT_10_REV, PORT_32 and PORT_32_REV definitions sh-pfc: Use pinmux identifiers in the pin muxing API sh-pfc: Simplify the sh_pfc_gpio_is_pin() logic sh-pfc: Add function to retrieve a pin instance from its pin number sh-pfc: Replace pinctrl_add_gpio_range() with gpiochip_add_pin_range() sh-pfc: Add support for sparse pin numbers ARM: shmobile: ap4-evb: Replace GPIO_PORTx enum with GPIO port numbers ARM: shmobile: armadillo: Replace GPIO_PORTx enum with GPIO port numbers ARM: shmobile: bonito: Replace GPIO_PORTx enum with GPIO port numbers ARM: shmobile: mackerel: Replace GPIO_PORTx enum with GPIO port numbers sh-pfc: Expose real groups and functions in pinctrl/pinmux operations sh: sh7203: Add pin control resources sh: sh7264: Add pin control resources sh: sh7269: Add pin control resources sh: sh7720: Add pin control resources sh: sh7722: Add pin control resources sh: sh7723: Add pin control resources sh: sh7724: Add pin control resources sh: sh7757: Add pin control resources sh: sh7785: Add pin control resources sh: sh7786: Add pin control resources sh: shx3: Add pin control resources sh-pfc: Move GPIO registers access functions to gpio.c sh-pfc: Don't map data registers individually sh-pfc: Drop unused support for 1:1 physical to virtual memory mappings sh-pfc: Don't modify pinmux_data_reg SoC data sh-pfc: Don't modify sh_pfc_pin SoC data sh-pfc: Remove configuration dry-run and free sh-pfc: Constify all SoC data sh-pfc: Use proper error codes sh-pfc: Implement generic pinconf support sh-pfc: Merge sh_pfc_reconfig_pin() into sh_pfc_gpio_set_direction() sh-pfc: Clean up pin configuration type handling sh-pfc: Convert message printing from pr_* to dev_* sh-pfc: Return an error if a pin doesn't support the requested direction sh-pfc: sh73a0: Add bias (pull-up/down) pinconf support sh-pfc: sh73a0: Add LCD and LCD2 pin groups and functions sh-pfc: sh73a0: Add SCIFA and SCIFB pin groups and functions sh-pfc: sh73a0: Add I2C2 and I2C3 pin groups and functions sh-pfc: sh73a0: Add FSI pin groups and functions sh-pfc: sh73a0: Add KEYSC pin groups and functions sh-pfc: sh73a0: Add BSC pin groups and functions sh-pfc: sh73a0: Add USB pin groups and functions
[GIT PULL 0/4] ARM: Second batch of arm-soc changes for 3.10
Hi Linus, Here is the second batch of branches from arm-soc for 3.10, descriptions in each pull request including conflict resolutions. As before, a combined resolved branch has been pushed to our repo for comparison. Branch name this time is 'second-batch-resolved'. Thanks, -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [GIT PULL] (xen) stable/for-jens-3.10 xenwatch: page allocation failure: order:7, mode:0x10c0d0
Hello Sander, Monday, April 29, 2013, 6:05:20 PM, you wrote: > Monday, April 29, 2013, 5:46:23 PM, you wrote: >> On Wed, Apr 24, 2013 at 08:16:37PM +0200, Sander Eikelenboom wrote: >>> Friday, April 19, 2013, 4:44:01 PM, you wrote: >>> >>> > Hey Jens, >>> >>> > Please in your spare time (if there is such a thing at a conference) >>> > pull this branch: >>> >>> > git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git >>> > stable/for-jens-3.10 >>> >> .. snip.. >>> Hi Konrad / Roger, >>> >>> I tried this pull on top of latest Linus latest linux-3.9 tree, but >>> although it seems to boot and work fine at first, i seem to get trouble >>> after running for about a day. >>> Without this pull it runs fine for several days. >> .. snipp. >>> [18496.013743] xenwatch: page allocation failure: order:7, mode:0x10c0d0 >>> [18496.031948] Pid: 54, comm: xenwatch Not tainted 3.9.0-rc8-20130424-jens+ >>> #1 >>> [18496.049897] Call Trace: >>> [18496.067674] [] warn_alloc_failed+0xf1/0x140 >>> [18496.085453] [] ? trace_hardirqs_on+0xd/0x10 >>> [18496.102951] [] ? on_each_cpu_mask+0x94/0xd0 >>> [18496.120270] [] __alloc_pages_nodemask+0x69f/0x960 >>> [18496.137306] [] alloc_pages_current+0xb1/0x160 >>> [18496.154051] [] __get_free_pages+0x9/0x40 >>> [18496.170579] [] __kmalloc+0x134/0x160 >>> [18496.186921] [] xen_blkbk_probe+0x170/0x2f0 >>> [18496.202963] [] xenbus_dev_probe+0x77/0x130 >>> [18496.218714] [] ? __driver_attach+0xa0/0xa0 >>> [18496.234237] [] driver_probe_device+0x81/0x220 >>> [18496.249605] [] ? klist_next+0x8c/0x110 >>> [18496.264681] [] ? __driver_attach+0xa0/0xa0 >>> [18496.279500] [] __device_attach+0x4b/0x50 >>> [18496.294138] [] bus_for_each_drv+0x68/0x90 >>> [18496.308553] [] device_attach+0x89/0x90 >>> [18496.322694] [] bus_probe_device+0xa8/0xd0 >>> [18496.336640] [] device_add+0x650/0x720 >> .. snip.. >> Jens, >> I don't know if you had pulled this git tree yet (I don't see it in >> your for-3.10/* branches). >> But if you have, Sander has found a bug (and Roger has a fix for it). >> Whether you would like to wait until v3.11 to pull it (and me sending >> the git pull around a month) is OK. Or pull it now and we will fix the >> bugs in the -rc's as they creep up. > Roger's fix seems to work for me .. Hmm although it takes longer, i still see my memory getting souped-up. Will see what setting: echo 384 > /sys/module/xen_blkback/parameters/max_persistent_grants echo 256 >> /sys/module/xen_blkback/parameters/max_buffer_pages will do this time around. -- Sander (XEN) [2013-05-03 23:00:21] grant_table.c:1250:d1 Expanding dom (1) grant table from (7) to (8) frames. (XEN) [2013-05-03 23:00:41] grant_table.c:1250:d1 Expanding dom (1) grant table from (8) to (9) frames. (XEN) [2013-05-03 23:01:01] grant_table.c:1250:d1 Expanding dom (1) grant table from (9) to (10) frames. (XEN) [2013-05-03 23:01:01] grant_table.c:1250:d1 Expanding dom (1) grant table from (10) to (11) frames. (XEN) [2013-05-04 03:15:32] grant_table.c:289:d0 Increased maptrack size to 10 frames (XEN) [2013-05-04 03:15:34] grant_table.c:1250:d9 Expanding dom (9) grant table from (4) to (5) frames. (XEN) [2013-05-04 03:15:34] grant_table.c:1250:d9 Expanding dom (9) grant table from (5) to (6) frames. (XEN) [2013-05-04 03:15:34] grant_table.c:1250:d9 Expanding dom (9) grant table from (6) to (7) frames. (XEN) [2013-05-04 03:15:34] grant_table.c:289:d0 Increased maptrack size to 11 frames (XEN) [2013-05-04 03:15:36] grant_table.c:1250:d8 Expanding dom (8) grant table from (4) to (5) frames. (XEN) [2013-05-04 03:15:36] grant_table.c:1250:d8 Expanding dom (8) grant table from (5) to (6) frames. (XEN) [2013-05-04 03:15:36] grant_table.c:289:d0 Increased maptrack size to 12 frames (XEN) [2013-05-04 03:15:36] grant_table.c:289:d0 Increased maptrack size to 13 frames (XEN) [2013-05-04 03:15:37] grant_table.c:1250:d4 Expanding dom (4) grant table from (4) to (5) frames. (XEN) [2013-05-04 03:15:37] grant_table.c:1250:d4 Expanding dom (4) grant table from (5) to (6) frames. (XEN) [2013-05-04 03:15:37] grant_table.c:1250:d4 Expanding dom (4) grant table from (6) to (7) frames. (XEN) [2013-05-04 03:15:37] grant_table.c:289:d0 Increased maptrack size to 14 frames (XEN) [2013-05-04 03:15:37] grant_table.c:289:d0 Increased maptrack size to 15 frames (XEN) [2013-05-04 03:15:39] grant_table.c:1250:d3 Expanding dom (3) grant table from (4) to (5) frames. (XEN) [2013-05-04 03:15:39] grant_table.c:1250:d3 Expanding dom (3) grant table from (5) to (6) frames. (XEN) [2013-05-04 03:15:39] grant_table.c:289:d0 Increased maptrack size to 16 frames (XEN) [2013-05-04 03:15:39] grant_table.c:289:d0 Increased maptrack size to 17 frames (XEN) [2013-05-04 03:15:39] grant_table.c:1250:d13 Expanding dom (13) grant table from (4) to (5) frames. (XEN) [2013-05-04 03:15:39] grant_table.c:1250:d13 Expanding dom (13) grant table from (5) to (6) frames. (XEN) [2013-05-04 03:15:39] grant_table.c:1250:d13
Re: [PATCH v2 1/2] sched: Add cond_resched_rcu_lock() helper
Hello,
On Fri, 3 May 2013, Paul E. McKenney wrote:
> static inline int cond_resched_rcu(void)
> {
> #if defined(CONFIG_DEBUG_ATOMIC_SLEEP) || !defined(CONFIG_PREEMPT_RCU)
> rcu_read_unlock();
> cond_resched();
> rcu_read_lock();
> #endif
> }
>
> This adds absolutely no overhead in non-debug builds of CONFIG_PREEMPT_RCU,
> does the checking in debug builds, and allows voluntary preemption in
> !CONFIG_PREEMPT_RCU builds. CONFIG_PROVE_RCU builds will check for an
> (illegal) outer rcu_read_lock() in CONFIG_PREEMPT_RCU builds, and you
> will get "scheduling while atomic" in response to an outer rcu_read_lock()
> in !CONFIG_PREEMPT_RCU builds.
>
> It also seems to me a lot simpler.
>
> Does this work, or am I still missing something?
Works perfectly. Thanks! Tested CONFIG_PREEMPT_RCU=y/n,
the errors messages with extra RCU lock.
Regards
--
Julian Anastasov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/4] fsfreeze: return EINTR from mnt_want_write and mnt_want_write_file
Replaced sb_start_write with sb_start_write_killable inside
mnt_want_write and mnt_want_write_file.
Signed-off-by: Marco Stornelli
Reviewed-by: Jan Kara
---
fs/namei.c |6 ++
fs/namespace.c |8 ++--
ipc/mqueue.c |6 +-
3 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index 57ae9c8..5f239fd 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2750,6 +2750,8 @@ static int do_last(struct nameidata *nd, struct path
*path,
retry_lookup:
if (op->open_flag & (O_CREAT | O_TRUNC | O_WRONLY | O_RDWR)) {
error = mnt_want_write(nd->path.mnt);
+ if (error == -EINTR)
+ goto out;
if (!error)
got_write = true;
/*
@@ -3053,6 +3055,10 @@ struct dentry *kern_path_create(int dfd, const char
*pathname,
/* don't fail immediately if it's r/o, at least try to report other
errors */
err2 = mnt_want_write(nd.path.mnt);
+ if (err2 == -EINTR) {
+ dentry = ERR_PTR(-EINTR);
+ goto out;
+ }
/*
* Do the final lookup.
*/
diff --git a/fs/namespace.c b/fs/namespace.c
index b4f96a5..2028e74 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -345,7 +345,9 @@ int mnt_want_write(struct vfsmount *m)
{
int ret;
- sb_start_write(m->mnt_sb);
+ ret = sb_start_write_killable(m->mnt_sb);
+ if (ret < 0)
+ return ret;
ret = __mnt_want_write(m);
if (ret)
sb_end_write(m->mnt_sb);
@@ -405,7 +407,9 @@ int mnt_want_write_file(struct file *file)
{
int ret;
- sb_start_write(file->f_path.mnt->mnt_sb);
+ ret = sb_start_write_killable(file->f_path.mnt->mnt_sb);
+ if (ret < 0)
+ return ret;
ret = __mnt_want_write_file(file);
if (ret)
sb_end_write(file->f_path.mnt->mnt_sb);
diff --git a/ipc/mqueue.c b/ipc/mqueue.c
index e4e47f6..e8fdc03 100644
--- a/ipc/mqueue.c
+++ b/ipc/mqueue.c
@@ -800,7 +800,11 @@ SYSCALL_DEFINE4(mq_open, const char __user *, u_name, int,
oflag, umode_t, mode,
if (fd < 0)
goto out_putname;
- ro = mnt_want_write(mnt); /* we'll drop it in any case */
+ ro = mnt_want_write(mnt);
+ if (ro == -EINTR) {
+ fd = ro;
+ goto out_putname;
+ }
error = 0;
mutex_lock(>d_inode->i_mutex);
path.dentry = lookup_one_len(name->name, root, strlen(name->name));
--
1.7.3.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 3/4] fsfreeze: use sb_start_write_killable instead of sb_start_write
Replace sb_start_write with sb_start_write_killable where possible. Signed-off-by: Marco Stornelli Reviewed-by: Jan Kara --- fs/open.c |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/fs/open.c b/fs/open.c index 8c74100..d621d76 100644 --- a/fs/open.c +++ b/fs/open.c @@ -182,7 +182,9 @@ static long do_sys_ftruncate(unsigned int fd, loff_t length, int small) if (IS_APPEND(inode)) goto out_putf; - sb_start_write(inode->i_sb); + error = sb_start_write_killable(inode->i_sb); + if (error < 0) + return error; error = locks_verify_truncate(inode, f.file, length); if (!error) error = security_path_truncate(>f_path); @@ -273,7 +275,9 @@ int do_fallocate(struct file *file, int mode, loff_t offset, loff_t len) if (!file->f_op->fallocate) return -EOPNOTSUPP; - sb_start_write(inode->i_sb); + ret = sb_start_write_killable(inode->i_sb); + if (ret < 0) + return ret; ret = file->f_op->fallocate(file, mode, offset, len); sb_end_write(inode->i_sb); return ret; -- 1.7.3.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 2/4] fsfreeze: added new file_start_write_killable
Replace file_start_write with file_start_write_killable where
possible.
Signed-off-by: Marco Stornelli
Reviewed-by: Jan Kara
---
drivers/block/loop.c |4 +++-
fs/aio.c |7 +--
fs/coda/file.c |4 +++-
fs/read_write.c | 38 ++
fs/splice.c |4 +++-
include/linux/fs.h | 17 +
6 files changed, 53 insertions(+), 21 deletions(-)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index b2955b3..321cf26 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -230,7 +230,9 @@ static int __do_lo_send_write(struct file *file,
ssize_t bw;
mm_segment_t old_fs = get_fs();
- file_start_write(file);
+ bw = file_start_write_killable(file);
+ if (bw < 0)
+ return bw;
set_fs(get_ds());
bw = file->f_op->write(file, buf, len, );
set_fs(old_fs);
diff --git a/fs/aio.c b/fs/aio.c
index 351afe7..692b408 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -1324,8 +1324,11 @@ static ssize_t aio_rw_vect_retry(struct kiocb *iocb)
if (iocb->ki_pos < 0)
return -EINVAL;
- if (opcode == IOCB_CMD_PWRITEV)
- file_start_write(file);
+ if (opcode == IOCB_CMD_PWRITEV) {
+ ret = file_start_write_killable(file);
+ if (ret < 0)
+ return ret;
+ }
do {
ret = rw_op(iocb, >ki_iovec[iocb->ki_cur_seg],
iocb->ki_nr_segs - iocb->ki_cur_seg,
diff --git a/fs/coda/file.c b/fs/coda/file.c
index 380b798..c5708d0 100644
--- a/fs/coda/file.c
+++ b/fs/coda/file.c
@@ -79,7 +79,9 @@ coda_file_write(struct file *coda_file, const char __user
*buf, size_t count, lo
return -EINVAL;
host_inode = file_inode(host_file);
- file_start_write(host_file);
+ ret = file_start_write_killable(host_file);
+ if (ret < 0)
+ return ret;
mutex_lock(_inode->i_mutex);
ret = host_file->f_op->write(host_file, buf, count, ppos);
diff --git a/fs/read_write.c b/fs/read_write.c
index 605dbbc..b561818 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -457,21 +457,23 @@ ssize_t vfs_write(struct file *file, const char __user
*buf, size_t count, loff_
return -EFAULT;
ret = rw_verify_area(WRITE, file, pos, count);
- if (ret >= 0) {
- count = ret;
- file_start_write(file);
- if (file->f_op->write)
- ret = file->f_op->write(file, buf, count, pos);
- else
- ret = do_sync_write(file, buf, count, pos);
- if (ret > 0) {
- fsnotify_modify(file);
- add_wchar(current, ret);
- }
- inc_syscw(current);
- file_end_write(file);
+ if (ret < 0)
+ goto out;
+ count = ret;
+ ret = file_start_write_killable(file);
+ if (ret < 0)
+ goto out;
+ if (file->f_op->write)
+ ret = file->f_op->write(file, buf, count, pos);
+ else
+ ret = do_sync_write(file, buf, count, pos);
+ if (ret > 0) {
+ fsnotify_modify(file);
+ add_wchar(current, ret);
}
-
+ inc_syscw(current);
+ file_end_write(file);
+out:
return ret;
}
@@ -745,7 +747,9 @@ static ssize_t do_readv_writev(int type, struct file *file,
} else {
fn = (io_fn_t)file->f_op->write;
fnv = file->f_op->aio_write;
- file_start_write(file);
+ ret = file_start_write_killable(file);
+ if (ret < 0)
+ goto out;
}
if (fnv)
@@ -925,7 +929,9 @@ static ssize_t compat_do_readv_writev(int type, struct file
*file,
} else {
fn = (io_fn_t)file->f_op->write;
fnv = file->f_op->aio_write;
- file_start_write(file);
+ ret = file_start_write_killable(file);
+ if (ret < 0)
+ goto out;
}
if (fnv)
diff --git a/fs/splice.c b/fs/splice.c
index e6b2559..b37c30e 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -1115,7 +1115,9 @@ static long do_splice_from(struct pipe_inode_info *pipe,
struct file *out,
else
splice_write = default_file_splice_write;
- file_start_write(out);
+ ret = file_start_write_killable(out);
+ if (ret < 0)
+ return ret;
ret = splice_write(pipe, out, ppos, len, flags);
file_end_write(out);
return ret;
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 6d9bcef..a85091e 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1404,6 +1404,16 @@ static inline void sb_start_write(struct super_block *sb)
__sb_start_write(sb, SB_FREEZE_WRITE,
[PATCH 1/4] fsfreeze: wait in killable state in __sb_start_write
Added a new enum to decide if we want to sleep in uninterruptible or
killable state or we want simply to return immediately.
Signed-off-by: Marco Stornelli
Reviewed-by: Jan Kara
---
fs/super.c | 24 ++--
include/linux/fs.h | 19 +--
2 files changed, 31 insertions(+), 12 deletions(-)
diff --git a/fs/super.c b/fs/super.c
index 7465d43..6b70c7f 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -1190,14 +1190,25 @@ static void acquire_freeze_lock(struct super_block *sb,
int level, bool trylock,
* This is an internal function, please use sb_start_{write,pagefault,intwrite}
* instead.
*/
-int __sb_start_write(struct super_block *sb, int level, bool wait)
+int __sb_start_write(struct super_block *sb, int level, int wait)
{
+ int ret = 0;
retry:
if (unlikely(sb->s_writers.frozen >= level)) {
- if (!wait)
- return 0;
- wait_event(sb->s_writers.wait_unfrozen,
- sb->s_writers.frozen < level);
+ switch (wait) {
+ case FREEZE_NOWAIT:
+ return ret;
+ case FREEZE_WAIT:
+ wait_event(sb->s_writers.wait_unfrozen,
+ sb->s_writers.frozen < level);
+ break;
+ case FREEZE_WAIT_KILLABLE:
+ ret = wait_event_killable(sb->s_writers.wait_unfrozen,
+ sb->s_writers.frozen < level);
+ if (ret)
+ return -EINTR;
+ break;
+ }
}
#ifdef CONFIG_LOCKDEP
@@ -1213,7 +1224,8 @@ retry:
__sb_end_write(sb, level);
goto retry;
}
- return 1;
+ ret = 1;
+ return ret;
}
EXPORT_SYMBOL(__sb_start_write);
diff --git a/include/linux/fs.h b/include/linux/fs.h
index e8cd6b8..6d9bcef 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1220,6 +1220,13 @@ enum {
#define SB_FREEZE_LEVELS (SB_FREEZE_COMPLETE - 1)
+/* Possible waiting modes */
+enum {
+ FREEZE_NOWAIT = 0, /* no blocking call */
+ FREEZE_WAIT = 1,/* wait in uninterruptible state */
+ FREEZE_WAIT_KILLABLE = 2, /* wait in killable state */
+};
+
struct sb_writers {
/* Counters for counting writers at each level */
struct percpu_counter counter[SB_FREEZE_LEVELS];
@@ -1335,7 +1342,7 @@ extern struct timespec current_fs_time(struct super_block
*sb);
*/
void __sb_end_write(struct super_block *sb, int level);
-int __sb_start_write(struct super_block *sb, int level, bool wait);
+int __sb_start_write(struct super_block *sb, int level, int wait);
/**
* sb_end_write - drop write access to a superblock
@@ -1394,12 +1401,12 @@ static inline void sb_end_intwrite(struct super_block
*sb)
*/
static inline void sb_start_write(struct super_block *sb)
{
- __sb_start_write(sb, SB_FREEZE_WRITE, true);
+ __sb_start_write(sb, SB_FREEZE_WRITE, FREEZE_WAIT);
}
static inline int sb_start_write_trylock(struct super_block *sb)
{
- return __sb_start_write(sb, SB_FREEZE_WRITE, false);
+ return __sb_start_write(sb, SB_FREEZE_WRITE, FREEZE_NOWAIT);
}
/**
@@ -1423,7 +1430,7 @@ static inline int sb_start_write_trylock(struct
super_block *sb)
*/
static inline void sb_start_pagefault(struct super_block *sb)
{
- __sb_start_write(sb, SB_FREEZE_PAGEFAULT, true);
+ __sb_start_write(sb, SB_FREEZE_PAGEFAULT, FREEZE_WAIT);
}
/*
@@ -1441,7 +1448,7 @@ static inline void sb_start_pagefault(struct super_block
*sb)
*/
static inline void sb_start_intwrite(struct super_block *sb)
{
- __sb_start_write(sb, SB_FREEZE_FS, true);
+ __sb_start_write(sb, SB_FREEZE_FS, FREEZE_WAIT);
}
@@ -2224,7 +2231,7 @@ static inline void file_start_write(struct file *file)
{
if (!S_ISREG(file_inode(file)->i_mode))
return;
- __sb_start_write(file_inode(file)->i_sb, SB_FREEZE_WRITE, true);
+ __sb_start_write(file_inode(file)->i_sb, SB_FREEZE_WRITE, FREEZE_WAIT);
}
static inline void file_end_write(struct file *file)
--
1.7.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] nohz: Bunch of fixes
* Frederic Weisbecker wrote: > Ingo, > > Please pull the timers/nohz-hz1 branch that can be found at: > > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git > timers/nohz-hz1 > > HEAD: a7f4d69bb1d5e1f573b680355a2ad51566338887 > > It fixes a Kconfig dependency issue and forces a minimum of 1 tick every > seconds > to keep handling the scheduler_tick() duties, even at a very low granularity. > This > is a workaround until we can handle all these duties through on-demand driven > solutions rather than using periodic events, as per your suggestion. > > I just noted two things: > > * update_cpu_load_active() seem to rely on the fixed periodic tick at the > HZ rate. There is certainly something to tweak there to make it really > correct > with dynamick ticks. I have the feeling that modifying pending_updates > won't work > as it seems to decay assuming the time to catch up was idle. > > * I'll probably have to disable CONFIG_CFS_BANDWIDTH when full dynticks > is enabled. First of all it modifies rq->nr_running without using > inc/dec_nr_running > standard API, which is required for full dynticks. And second, I need to > triple > check it's safe to use with 1 tick per second. > > Ah and please note the merge commit (c032862fba51a3ca504752d3a25186b324c5ce83) > that was needed to get latest RCU and sched updates for the Kconfig fix. > > Thanks, > Frederic > --- > > Frederic Weisbecker (2): > rcu: Fix full dynticks' dependency on wide RCU nocb mode > sched: Keep at least 1 tick per second for active dynticks tasks > > > include/linux/sched.h|1 + > init/Kconfig |4 ++-- > kernel/sched/core.c | 30 ++ > kernel/sched/idle_task.c |1 + > kernel/sched/sched.h | 10 ++ > kernel/time/Kconfig |1 - > kernel/time/tick-sched.c |7 +++ > 7 files changed, 51 insertions(+), 3 deletions(-) Pulled, thanks Frederic! Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH, RFC 02/22] cpufreq: ARM_DT_BL_CPUFREQ needs ARM_CPU_TOPOLOGY
On 2 May 2013 20:46, Arnd Bergmann wrote: > The big.LITTLE cpufreq driver uses the CPU topology API, which > needs to be reflected in Kconfig to prevent broken configurations. > > warning: (ARM_DT_BL_CPUFREQ) selects ARM_BIG_LITTLE_CPUFREQ which > has unmet direct dependencies (ARCH_HAS_CPUFREQ && CPU_FREQ && ARM && > ARM_CPU_TOPOLOGY) > > Cc: Rafael J. Wysocki > Cc: Viresh Kumar > Cc: cpuf...@vger.kernel.org > Cc: linux...@vger.kernel.org > Signed-off-by: Arnd Bergmann > --- > drivers/cpufreq/Kconfig.arm | 1 + > 1 file changed, 1 insertion(+) With all the discussions we had, please see if you can replace your patch with this one (Attached too for applying, copy/paste in gmail will break it): From: Viresh Kumar Date: Sat, 4 May 2013 12:03:54 +0530 Subject: [PATCH] cpufreq: ARM big LITTLE: Fix Kconfig entries This fixes usage of "depends on" and "select" options in Kconfig for ARM big LITTLE cpufreq driver. Otherwise we get these warnings: warning: (ARM_DT_BL_CPUFREQ) selects ARM_BIG_LITTLE_CPUFREQ which has unmet direct dependencies (ARCH_HAS_CPUFREQ && CPU_FREQ && ARM && ARM_CPU_TOPOLOGY) Signed-off-by: Arnd Bergmann Signed-off-by: Viresh Kumar --- drivers/cpufreq/Kconfig.arm | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm index 634e992..a924408 100644 --- a/drivers/cpufreq/Kconfig.arm +++ b/drivers/cpufreq/Kconfig.arm @@ -3,17 +3,17 @@ # config ARM_BIG_LITTLE_CPUFREQ - tristate - depends on ARM_CPU_TOPOLOGY - select PM_OPP + tristate "Generic ARM big LITTLE CPUfreq driver" + depends on ARM_CPU_TOPOLOGY && PM_OPP && HAVE_CLK + help + This enables the Generic CPUfreq driver for ARM big.LITTLE platforms. config ARM_DT_BL_CPUFREQ - tristate "Generic ARM big LITTLE CPUfreq driver probed via DT" - select ARM_BIG_LITTLE_CPUFREQ - depends on OF && HAVE_CLK + tristate "Generic probing via DT for ARM big LITTLE CPUfreq driver" + depends on ARM_BIG_LITTLE_CPUFREQ && OF help - This enables the Generic CPUfreq driver for ARM big.LITTLE platform. - This gets frequency tables from DT. + This enables probing via DT for Generic CPUfreq driver for ARM + big.LITTLE platform. This gets frequency tables from DT. config ARM_EXYNOS_CPUFREQ bool "SAMSUNG EXYNOS SoCs" 0001-cpufreq-ARM-big-LITTLE-Fix-Kconfig-entries.patch Description: Binary data
Re: [PATCH 1/2] rcu: Fix full dynticks' dependency on wide RCU nocb mode
2013/5/3 Paul E. McKenney :
> On Fri, May 03, 2013 at 06:47:55PM +0200, Frederic Weisbecker wrote:
>> Commit 0637e029392386e6996f5d6574aadccee8315efa
>> ("nohz: Select wide RCU nocb for full dynticks") intended
>> to force CONFIG_RCU_NOCB_CPU_ALL=y when full dynticks is
>> enabled.
>>
>> However this option is part of a choice menu and Kconfig's
>> "select" instruction has no effect on such targets.
>>
>> Fix this by using reverse dependencies on the targets we
>> don't want instead.
>>
>> Signed-off-by: Frederic Weisbecker
>> Cc: Christoph Lameter
>> Cc: Hakan Akkan
>> Cc: Ingo Molnar
>> Cc: Kevin Hilman
>> Cc: Li Zhong
>> Cc: Paul E. McKenney
>> Cc: Paul Gortmaker
>> Cc: Peter Zijlstra
>> Cc: Steven Rostedt
>> Cc: Thomas Gleixner
>
> Reviewed-by: Paul E. McKenney
Nice!
Ingo, if you haven't yet pulled, please rather pick the
"timers/nohz-hz1-v2" branch that has the Reviewed-by: tag from Paul.
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: [PATCH 2/3] perf, x86, lbr: Fix LBR filter
* Andi Kleen wrote:
> > + } else {
> > + /*
> > +* The LBR logs any address in the IP, even if the IP just
> > +* faulted. This means userspace can control the from address.
> > +* Ensure we don't blindy read any address by validating it is
> > +* a known text address.
> > +*/
> > + if (kernel_text_address(from))
>
> Sorry doing it this way is just incredible expensive and dumb.
If anyone using this feature notices the __module_address() overhead then
a 'module addresses RCU rbtree' could be added, which should solve the
overhead impact.
In any case Peter's patch fixes the bug without regressing the feature as
it is implemented today. Do you have a better solution that does not break
the ABI? The solution you proposed before regresses existing
functionality.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 34/42] rtc: rtc-spear: remove unnecessary platform_set_drvdata()
On Fri, May 3, 2013 at 12:06 PM, Jingoo Han wrote: > The driver core clears the driver data to NULL after device_release > or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d > (device-core: Ensure drvdata = NULL when no driver is bound). > Thus, it is not needed to manually clear the device driver data to NULL. > > Signed-off-by: Jingoo Han > --- > drivers/rtc/rtc-spear.c |1 - > 1 files changed, 0 insertions(+), 1 deletions(-) Thanks. Acked-by: Viresh Kumar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 34/42] rtc: rtc-spear: remove unnecessary platform_set_drvdata()
On Fri, May 3, 2013 at 12:06 PM, Jingoo Han jg1@samsung.com wrote: The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han jg1@samsung.com --- drivers/rtc/rtc-spear.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) Thanks. Acked-by: Viresh Kumar viresh.ku...@linaro.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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/3] perf, x86, lbr: Fix LBR filter
* Andi Kleen a...@linux.intel.com wrote:
+ } else {
+ /*
+* The LBR logs any address in the IP, even if the IP just
+* faulted. This means userspace can control the from address.
+* Ensure we don't blindy read any address by validating it is
+* a known text address.
+*/
+ if (kernel_text_address(from))
Sorry doing it this way is just incredible expensive and dumb.
If anyone using this feature notices the __module_address() overhead then
a 'module addresses RCU rbtree' could be added, which should solve the
overhead impact.
In any case Peter's patch fixes the bug without regressing the feature as
it is implemented today. Do you have a better solution that does not break
the ABI? The solution you proposed before regresses existing
functionality.
Thanks,
Ingo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
