- 08 May, 2007 40 commits
-
-
Bernhard Walle authored
irqpoll is broken on some architectures that don't use the IRQ 0 for the timer interrupt like IA64. This patch adds a IRQF_IRQPOLL flag. Each architecture is handled in a separate pach. As I left the irq == 0 as condition, this should not break existing architectures that use timer_irq == 0 and that I did't address with that patch (because I don't know). This patch: This patch adds a IRQF_IRQPOLL flag that the interrupt registration code could use for the interrupt it wants to use for IRQ polling. Because this must not be the timer interrupt, an additional flag was added instead of re-using the IRQF_TIMER constant. Until all architectures will have an IRQF_IRQPOLL interrupt, irq == 0 will stay as alternative as it should not break anything. Also, note_interrupt() is called on CPU-specific interrupts to be used as interrupt source for IRQ polling. Signed-off-by:
Bernhard Walle <bwalle@suse.de> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Kyle McMartin <kyle@mcmartin.ca> Cc: Matthew Wilcox <willy@debian.org> Cc: Grant Grundler <grundler@google.com> Cc: Paul Mundt <lethal@linux-sh.org> Cc: "Luck, Tony" <tony.luck@intel.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Dmitriy Monakhov authored
sb_read may return NULL, let's explicitly check it. Signed-off-by:
Dmitriy Monakhov <dmonakhov@openvz.org> Cc: Jan Kara <jack@ucw.cz> Signed-off-by:
-
Jan Kara authored
Make UDF work correctly for files larger than 1GB. As no extent can be longer than (1<<30)-blocksize bytes, we have to create several extents if a big hole is being created. As a side-effect, we now don't discard preallocated blocks when creating a hole. Signed-off-by:
Jan Kara <jack@suse.cz> Acked-by:
Christoph Hellwig <hch@infradead.org> Signed-off-by:
-
Jan Kara authored
Add a few assertions into udf_discard_prealloc() to check that the file is sane (mostly helps debugging further patches ;). Signed-off-by:
-
Jan Kara authored
Make UDF use get_bh() instead of directly accessing b_count and use brelse() instead of udf_release_data() which does just brelse()... Signed-off-by:
-
Jan Kara authored
Introduce a structure extent_position to store a position of an extent and the corresponding buffer_head in one place. Signed-off-by:
-
Jan Kara authored
Use sector_t and loff_t for file offsets in UDF filesystem. Otherwise an overflow may occur for long files. Also make inode_bmap() return offset in the extent in number of blocks instead of number of bytes - for most callers this is more convenient. Signed-off-by:
-
Peter Zijlstra authored
Change the atomic_t in struct nfs_server to atomic_long_t in anticipation of machines that can handle 8+TB of (4K) pages under writeback. However I suspect other things in NFS will start going *bang* by then. Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Trond Myklebust <trond.myklebust@fys.uio.no> Signed-off-by:
-
Adrian Bunk authored
Include the new linux/kdebug.h instead of asm/kdebug.h. Simply remove the asm/kdebug.h include if both had been included. Signed-off-by:
Adrian Bunk <bunk@stusta.de> Signed-off-by:
-
Robert P. J. Day authored
Tweak and add content for extractable documentation in asm-i386/atomic.h. Signed-off-by:
Robert P. J. Day <rpjday@mindspring.com> Acked-by:
Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by:
-
Jeff Dike authored
Allow a pcap device to be assigned a MAC on the command line. They don't really need one, but it is handy to be able to do when your distro assigns a new ethernet device whenever it sees a new MAC. Signed-off-by:
Jeff Dike <jdike@linux.intel.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by:
-
Jeff Dike authored
Some network device cleanup. When setup_etheraddr found a globally valid MAC being assigned to an interface, it went ahead and used it rather than assigning a random MAC like the other cases do. This isn't really an error like the others, but it seems consistent to make it behave the same. We were getting some duplicate kfree() in the error case in eth_configure because platform_device_unregister frees buffers that the error cases following tried to free again. The pcap initialization routine wasn't doing the proper printk of its information, causing a printk of the first part of that line to be unterminated by a newline. The pcap code had a bunch of style violations, which are now fixed. pcap_setup wasn't returning false when it detected an unrecognized option. The printks in pcap_user all got UM_KERN_BLAH prepended to their format strings. pcap_remove now checks for a non-NULL pcap structure before it calls pcap_close. Signed-off-by:
Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by:
-
Jeff Dike authored
i386: Rearrange the cmpxchg code to allow atomic.h to get it without needing to include system.h. This kills warnings in the UML build from atomic.h about implicit declarations of cmpxchg symbols. The i386 build presumably isn't seeing this because a separate inclusion of system.h is covering it over. The cmpxchg stuff is moved to asm-i386/cmpxchg.h, with an include left in system.h for the benefit of generic code which expects cmpxchg there. Meanwhile, atomic.h includes cmpxchg.h. This causes no noticable damage to the i386 build. x86_64: Move cmpxchg into its own header. atomic.h already included system.h, so this is changed to include cmpxchg.h. This is purely cleanup - it's not fixing any warnings - so if the x86_64 system.h isn't considered as cleanup-worthy as i386, then this can be dropped. It causes no noticable damage to the x86_64 build. uml: The i386 and x86_64 cmpxchg patches require an asm-um/cmpxchg.h for the UML build. Signed-off-by:
-
Jeff Dike authored
tas() has no users, so get rid of it. Signed-off-by:
-
Mathieu Desnoyers authored
Signed-off-by:
Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Cc: Andi Kleen <ak@muc.de> Signed-off-by:
-
Mathieu Desnoyers authored
sparc64 local_t cleanup : simply use asm-generic/local.h. Signed-off-by:
-
Mathieu Desnoyers authored
[akpm@linux-foundation.org: build fixes] Signed-off-by:
-
Mathieu Desnoyers authored
parisc architecture local_t cleanup : use asm-generic/local.h. Signed-off-by:
-
Mathieu Desnoyers authored
Signed-off-by:
-
Mathieu Desnoyers authored
Signed-off-by:
-
Mathieu Desnoyers authored
Signed-off-by:
-
Mathieu Desnoyers authored
Signed-off-by:
-
Mathieu Desnoyers authored
This series extena and standardises local_t operations on each architecture, allowing a rich set of atomic operations to be done on per-cpu data with minimal performance impact. On architectures where there seems to be no difference between the SMP and UP operation (same memory barriers, same LOCKing), local.h simply includes asm-generic/local.h, which removes duplicated code from the current kernel tree. This patch: local_t: architecture independent extension Signed-off-by:
-
Mathieu Desnoyers authored
atomic_add_unless as inline. Remove system.h atomic.h circular dependency. I agree (with Andi Kleen) this typeof is not needed and more error prone. All the original atomic.h code that uses cmpxchg (which includes the atomic_add_unless) uses defines instead of inline functions, probably to circumvent a circular dependency between system.h and atomic.h on powerpc (which my patch addresses). Therefore, it makes sense to use inline functions that will provide type checking. atomic_add_unless as inline. Remove system.h atomic.h circular dependency. Digging into the FRV architecture shows me that it is also affected by such a circular dependency. Here is the diff applying this against the rest of my atomic.h patches. It applies over the atomic.h standardization patches. Signed-off-by:
-
Mathieu Desnoyers authored
Signed-off-by:
-
Mathieu Desnoyers authored
Signed-off-by:
-
Mathieu Desnoyers authored
[akpm@linux-foundation.org: build fixes] Signed-off-by:
-
Mathieu Desnoyers authored
Signed-off-by:
Grant Grundler <grundler@parisc-linux.org> Signed-off-by:
-
Mathieu Desnoyers authored
Signed-off-by:
-
Mathieu Desnoyers authored
Signed-off-by:
-
Mathieu Desnoyers authored
Remove an explicit cast to an integer type for the result returned by cmpxchg. It is not per se a problem on the i386 architecture, because sizeof(int) == sizeof(long), but whenever this code is cut'n'pasted to a accept passing an atomic64_t value as parameter to cmpxchg, xchg and add_unless, having 64 bits inputs casted to 32 bits. Signed-off-by:
-
Mathieu Desnoyers authored
Signed-off-by:
-
Mathieu Desnoyers authored
This series mainly adds support for missing 64 bits cmpxchg and 64 bits atomic add unless. Therefore, principally 64 bits architectures are targeted by these patches. It also adds the complete list of atomic operations on the atomic_long type. This patch: atomic.h: add atomic64 cmpxchg, xchg and add_unless to alpha Signed-off-by:
-
Ananth N Mavinakayanahalli authored
This patch provides a debugfs knob to turn kprobes on/off o A new file /debug/kprobes/enabled indicates if kprobes is enabled or not (default enabled) o Echoing 0 to this file will disarm all installed probes o Any new probe registration when disabled will register the probe but not arm it. A message will be printed out in such a case. o When a value 1 is echoed to the file, all probes (including ones registered in the intervening period) will be enabled o Unregistration will happen irrespective of whether probes are globally enabled or not. o Update Documentation/kprobes.txt to reflect these changes. While there also update the doc to make it current. We are also looking at providing sysrq key support to tie to the disabling feature provided by this patch. [akpm@linux-foundation.org: Use bool like a bool!] [akpm@linux-foundation.org: add printk facility levels] [cornelia.huck@de.ibm.com: Add the missing arch_trampoline_kprobe() for s390] Signed-off-by:
Ananth N Mavinakayanahalli <ananth@in.ibm.com> Signed-off-by:
Srinivasa DS <srinivasa@in.ibm.com> Signed-off-by:
Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by:
-
Christoph Hellwig authored
- consolidate duplicate code in all arch_prepare_kretprobe instances into common code - replace various odd helpers that use hlist_for_each_entry to get the first elemenet of a list with either a hlist_for_each_entry_save or an opencoded access to the first element in the caller - inline add_rp_inst into it's only remaining caller - use kretprobe_inst_table_head instead of opencoding it Signed-off-by:
Christoph Hellwig <hch@lst.de> Cc: Prasanna S Panchamukhi <prasanna@in.ibm.com> Acked-by:
-
Christoph Hellwig authored
Remove superflous braces and fix indentation aswell as comments. Signed-off-by:
-
Christoph Hellwig authored
Signed-off-by:
-
Marko Vrh authored
Replace CONFIG_PNPACPI with CONFIG_PNP, so it loads on ACPI-less PNPBIOS systems. Signed-off-by:
Marko Vrh <mvrh@freeshells.ch> Acked-by:
David Brownell <dbrownell@users.sourceforge.net> Signed-off-by:
-
David Brownell authored
This fixes a common glitch in how RTC drivers handle two "set alarm" modes, by getting rid of the surprising/hidden one that was rarely implemented correctly (and which could expose nonportable hardware-specific behavior). The glitch comes from the /dev/rtcX logic implementing the legacy RTC_ALM_SET (limited to 24 hours, needing RTC_AIE_ON) ioctl on top of the RTC driver call providing access to the newer RTC_WKALM_SET (without those limitations) by initializing the day/month/year fields to be invalid ... that second mode. Now, since few RTC drivers check those fields, and most hardware misbehaves when faced with invalid date fields, many RTC drivers will set bogus alarm times on those RTC_ALM_SET code paths. (Several in-tree drivers have that issue, and I also noticed it with code reviews on several new RTC drivers.) This patch ensures that RTC drivers never see such invalid alarm fields, by moving some logic out of rtc-omap into the RTC_ALM_SET code and adding an explicit check (which will prevent the issue on other code paths). Signed-off-by:
-
Andrew Morton authored
David says "884b4aaa should be reverted. It added an rtc_merge_alarm() call to the 2.6.20 kernel, which hasn't yet been used by any in-tree driver; this patch obviates the need for that call, and uses a more robust approach." Cc: Scott Wood <scottwood@freescale.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: David Brownell <david-b@pacbell.net> Signed-off-by:
-
