- 10 May, 2004 40 commits
-
-
Andrew Morton authored
From: Adrian Bunk <bunk@fs.tum.de> The patch below removes some #ifdef'd kernel 2.2 code from drivers/net/hamradio/dmascc.c.
-
Andrew Morton authored
From: Joseph Parmelee <jparmele@wildbear.com> Fixes improper setup of the mixer on Crystal soundcards with the CS4235 chip.
-
Andrew Morton authored
fbcon needs this symbol.
-
Andrew Morton authored
We may as well make usermodehelper_init() core_initcall as well, to make sure its services are avaialble to all the other initcall levels.
-
Andrew Morton authored
We need to register the binfmts earlier, so normal initcalls can successfully run call_usermodehelper() to execute things.
-
Andrew Morton authored
From: Stephen Hemminger <shemminger@osdl.org> Minor tweak to rcu, use __list_splice instead of list_splice because the list has already been checked for empty.
-
Andrew Morton authored
From: Christoph Hellwig <hch@lst.de> ->open already has a reference so use __module_get. The file has no maintainer noted in it, all credits are from the driver it's copied from.
-
Andrew Morton authored
From: Christoph Hellwig <hch@lst.de> mtd driver need to get another reference if ->probe succeeds (strange design if you ask me, but what the heck..), and while most drivers have been switched to __module_get already two are still missing.
-
Andrew Morton authored
From: Christoph Hellwig <hch@lst.de> A bunch of framebuffer drivers use MOD_INC_USE_COUNT to prevent themselves from unloading completely - but we have a much easier way to do so, that is simply removing the module_exit/cleanup_module handler.
-
Andrew Morton authored
From: Christoph Hellwig <hch@lst.de> Well, UML is pretty out of date in mainline, but I'd like to squash the last users of said beasts rather sooner than later.
-
Andrew Morton authored
From: Christoph Hellwig <hch@lst.de> Driver already sets fops->owner so the open/close methods are entirely superflous.
-
Andrew Morton authored
From: Christoph Hellwig <hch@lst.de> Callers are exported register/unregister handlers so the module is locked in core by users of said exports.
-
Andrew Morton authored
From: <mikem@beardog.cca.cpqcorp.net> This patch fixes 2 minor issues that break our Array Configuration utility. my_io was changed to a pointer so the & had to removed when using it with copy_to_user(). Sometime in 2.5 SG_MAX got changed to 31. Maybe to copy cciss? Now I'm changing it back to 32 so our app can work.
-
Andrew Morton authored
From: "Chen, Kenneth W" <kenneth.w.chen@intel.com>, "Seth, Rohit" <rohit.seth@intel.com> This patch addresses the longstanding problem wherein Oracle needs CAP_IPC_LOCK to allocate SHM_HUGETLB shm memory, but people don't want to run Oracle as root, and capabilties are busted. Various ideas with rlimits didn't work out, mainly because these objects live beyond the lifetime of the user processes which establish them. What we do is to create root-writeable /proc/sys/vm/hugetlb_shm_group which specifies a single group ID. Users who belong to that group may allocate hugepages for SHM_HUGETLB shm segments. So the sysadmin will greate a new group, say `hugepageusers', will add the oracle user to that group and will write that group's ID into /proc/sys/vm/hugetlb_shm_group.
-
Andrew Morton authored
From: David Gibson <david@gibson.dropbear.id.au> add_to_page_cache() locks the given page if and only if it suceeds. The hugepage code (every arch), however, does an unlock_page() after add_to_page_cache() before checking the return code, which could trip the BUG() in unlock_page() if add_to_page_cache() failed. In practice we've never hit this bug, because the only ways add_to_page_cache() can fail are when we fail to allocate a radix tree node (very rare), or when there is already a page at that offset in the radix tree, which never happens during prefault, obviously. We should probably fix it anyway, though. The analagous bug in some of the patches floating about to demand-allocation of hugepages is more of a problem, because multiple processes can race to instantiate a particular page in the radix tree - that's been hit at least once (which is how I found this).
-
Andrew Morton authored
From: "Luiz Fernando N. Capitulino" <lcapitulino@prefeitura.sp.gov.br> Zhenmin's checker tool <zli4@cs.uiuc.edu> detected this: 9. /drivers/pci/hotplug/shpchp_ctrl.c, Line 1575: err("%s: Failed to disable slot, error code(%d)\n", __FUNCTION__, rc); Maybe change to: err("%s: Failed to disable slot, error code(%d)\n", __FUNCTION__, retval); I think it is right because at line 1564, the slot is turned off, and in this line (1575) is checked the status to see if we got an error; if so, the error number is shown. This number is in 'retval', not in 'rc' ('rc' does have the return of configure_new_device()).
-
Andrew Morton authored
From: Hanna Linder <hannal@us.ibm.com> Per Greg's request this is a patch of having run Lindent on cpuid.c. The tabs were not the right number of spaces before. I have verified it still compiles and boots with this "change".
-
Andrew Morton authored
From: "Luiz Fernando N. Capitulino" <lcapitulino@prefeitura.sp.gov.br> drivers/pcmcia/tcic.c:63: warning: `version' defined but not used
-
Andrew Morton authored
From: Jens Axboe <axboe@suse.de> AS does not correctly account requests inserted with INSERT_FRONT or INSERT_BACK, barriers for example. In other elevators, requeued requests also go through the insert path, but AS has its own requeue handler which means the code has never been tested. Also, make inserting a barrier with INSERT_SORT imply INSERT_BACK, which is the logical behaviour. Previously such insertions weren't rigorously defined.
-
Andrew Morton authored
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> ldisc close can race with the flush_to_ldisc workqueue. This patch fixes it by killing the workqueue first.
-
Andrew Morton authored
From: Olaf Dabrunz <od@suse.de> Add the necessary hooks so that a SELinux-enabled kernel will allow the new "report the size of the printk buffer" query to work.
-
Andrew Morton authored
From: "Chen, Kenneth W" <kenneth.w.chen@intel.com> It's kind of redundant that queue_congestion_on/off_threshold gets calculated on every I/O and they produce the same number over and over again unless q->nr_requests gets changed (which is probably a very rare event). We can cache those values in the request_queue structure.
-
Andrew Morton authored
From: Pavel Machek <pavel@ucw.cz>
-
Andrew Morton authored
From: Chris Wright <chrisw@osdl.org> Currently, if a user creates an mqueue and passes an mq_attr, the info->messages will be created twice (and the extra one is properly freed). This patch simply delays the allocation so that it only ever happens once. The relevant mq_attr data is passed to lower levels via the dentry->d_fsdata fs private data. This also helps isolate the areas we'd need to touch to do rlimits on mqueues.
-
Andrew Morton authored
From: Jakub Jermar <jermar@itbs.cz> I found out that BFS filesystem will eventually try to read and interpret garbage past the end of directory in bfs_add_entry(). If the garbage (interpreted as i-node number) is not set to zero (does it have to be?) bfs_add_entry() will consider it a regular directory entry. This causes weird things like this: # touch a # rm a # ls # touch b # ls a My patch detects an attempt to read past the end of directory and explicitly clears the garbage that represents i-node number. Thus the correct behaviour is achieved. (was unable to contact Tigran)
-
Andrew Morton authored
From: <spam@altium.nl> (Dick Streefland) The following patch documents the currently undocumented raid= kernel parameter.
-
Andrew Morton authored
From: "Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com> This is ES7000 sub architecture update. It makes ES7000 a part of the generic architecture, so the single compiled kernel will be able to choose a correct set of parameters, routines ("genapic"), and a boot path. It uses criteria provided by the subarch for platform identification. In case of ES7000, it is a unique product/vendor string in the ACPI/MP OEM table, and server control registers. The patch is confined to only es7000 subarch and generic subarch. It was tested on ES7000 as well as generic Intel 8x Xeon system. Andi Kleen has reviewed the changes.
-
Andrew Morton authored
From: Thorsten Kranzkowski <dl8bcu@dl8bcu.de> use CLOCK_TICK_RATE where 1193180 was used in general timing calculations. (optional)
-
Andrew Morton authored
From: Thorsten Kranzkowski <dl8bcu@dl8bcu.de>
-
Andrew Morton authored
From: Thorsten Kranzkowski <dl8bcu@dl8bcu.de> The calculation of the counter values in drivers/input/misc/pcspkr.c is incorrectly based on CLOCK_TICK_RATE. This goes unnoticed in i386 because there the system clock is driven by the same Programmable Interval Timer chip as the speaker. But this doesn't hold true on other archs, e.g. Alpha. To solve this problem I made these patches: 1/3: introduce asm-*/8253pit.h, #define PIT_TICK_RATE constant. It seems this is not always the same value. 2/3: use PIT_TICK_RATE in *spkr.c 3/3: use CLOCK_TICK_RATE where 1193180 was used in general timing calculations. (optional) There are still some places where the magic number is used instead of the #define (vt_ioctl.c, gameport.c) but I left them as-is. I got some responses from arch maintainers to specifically not touch their respective architectures so changing these places would mean breakage for them. Tested on Alpha and i386, ack'ed by Ralf Baechle for MIPS. This patch: introduce asm-*/8253pit.h, #define PIT_TICK_RATE constant.
-
Andrew Morton authored
When two threads are simultaneously pread()ing from the same fd (which is a legitimate thing to do), the readahead code thinks that a huge amount of seeking is happening and shrinks the window, damaging performance a lot. I don't see a sane way to avoid this within the readahead code, so take a private copy of the readahead state and restore it prior to returning from the read.
-
Andrew Morton authored
From: john stultz <johnstul@us.ibm.com> This patch polishes up Tim Schmielau's (tim@physik3.uni-rostock.de) fix for jiffies_to_clock_t() and jiffies_64_to_clock_t(). The issues observed was w/ /proc output not matching up to wall time due to accumulated error caused by HZ not being exactly 1000 on i386 systems. The solution is to correct that error by using the more accurate TICK_NSEC in our calculation. Additionally, this patch corrects 3 warnings in the TCP layer uncovered by this change.
-
Andrew Morton authored
From: Marcelo Tosatti <marcelo.tosatti@cyclades.com> - cleanups for cyclades Kconfig entry (Adrian Bunk/me) - janitors project: remove dead function (Don Koch) From: aris@cathedrallabs.org (Aristeu Sergio Rozanski Filho) Use the standard min/max macros
-
Andrew Morton authored
From: Jorn Engel <joern@wohnheim.fh-wedel.de> AS arch/i386/boot/setup.o /usr/src/linux-2.6.5/arch/i386/boot/setup.S: Assembler messages: /usr/src/linux-2.6.5/arch/i386/boot/setup.S:159: Warning: value 0x37ffffff truncated to 0x37ffffff The warning is correct, the calculated value for ramdisk_max would be 0xb7ffffff instead of 0x37ffffff. Truncating 0xb7ffffff to 0x37ffffff is desired behaviour, so we should do it explicitly.
-
Andrew Morton authored
From: David Gibson <david@gibson.dropbear.id.au> Currently ppc64 has its own code to convert 32-bit ipc() syscalls to 64-bit, rather than using the common translation code from ipc/compat.c. This patch, tweaked slightly from an earlier version of Anton Blanchard's fixes that, replacing the ppc64 code with calls to the common code. I've run the LSB IPC tests, and as many of the LTP IPC tests as I could figure out how to run easily, and it seems to pass them all.
-
Andrew Morton authored
From: Mikael Pettersson <mikpe@csd.uu.se> Here are some patches to fix compilation warnings from gcc-3.4.0 in the 2.6.6-rc3 x86_64 kernel. - puts() type conflict in boot/compressed/misc.c: rename to putstr(), just like i386 did - cast-as-lvalue in ia32_copy_siginfo_from_user(): use temporary - code before declaration in io_apic.c: move decl up - code before declaration in ioremap.c: move existing #ifndef up - cast-as-lvalue (tons of them) from UP version of per_cpu(): merged asm-generic's version
-
Andrew Morton authored
From: Christoph Hellwig <hch@lst.de>
-
Andrew Morton authored
From: Keith Owens <kaos@sgi.com> Almost every architecture has a comment above smp_call_function() * You must not call this function with disabled interrupts or from a * hardware interrupt handler or from a bottom half handler. I have not seen any problems with calling smp_call_function() from a bottom half handler, but calling it with interrupts disabled can definitely deadlock. This bug is hard to reproduce and even harder to debug. CPU A CPU B Disable interrupts smp_call_function() Take call_lock Send IPIs Wait for all cpus to acknowledge IPI CPU A has not responded, spin waiting for cpu A to respond, holding call_lock smp_call_function() Spin waiting for call_lock Deadlock Deadlock Change all smp_call_function() to WARN_ON(irqs_disabled()). It should be BUG_ON() but some buggy code like SCSI sg will break with BUG_ON, so just warn for now. Change it to BUG_ON after the buggy code has been fixed.
-
Andrew Morton authored
Fix a waitqueue-handling race in worker_thread().
-
Andrew Morton authored
From: "Luiz Fernando N. Capitulino" <lcapitulino@prefeitura.sp.gov.br> drivers/pcmcia/i82365.c: At top level: drivers/pcmcia/i82365.c:71: warning: `version' defined but not used
-