- 01 Apr, 2006 2 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6Linus Torvalds authored
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6: [IA64] Avoid "u64 foo : 32;" for gcc3 vs. gcc4 compatibility [IA64] Export cpu cache info by sysfs
-
Linus Torvalds authored
* master.kernel.org:/pub/scm/linux/kernel/git/sfrench/cifs-2.6: [CIFS] Fix typo in earlier cifs_unlink change and protect one [CIFS] Incorrect signature sent on SMB Read [CIFS] Fix unlink oops when indirectly called in rename error path [CIFS] Fix two remaining coverity scan tool warnings. [CIFS] Set correct lock type on new posix unlock call [CIFS] Upate cifs change log [CIFS] Fix slow oplock break response when mounts to different [CIFS] Workaround various server bugs found in testing at connectathon [CIFS] Allow fallback for setting file size to Procom SMB server when [CIFS] Make POSIX CIFS Extensions SetFSInfo match exactly what we want [CIFS] Move noisy debug message (triggerred by some older servers) from [CIFS] Use correct pid on new cifs posix byte range lock call [CIFS] Add posix (advisory) byte range locking support to cifs client [CIFS] CIFS readdir perf optimizations part 1 [CIFS] Free small buffers earlier so we exceed the cifs [CIFS] Fix large (ie over 64K for MaxCIFSBufSize) buffer case for wrapping [CIFS] Convert remaining places in fs/cifs from [CIFS] SessionSetup cleanup part 2 [CIFS] fix compile error (typo) and warning in cifssmb.c [CIFS] Cleanup NTLMSSP session setup handling
-
- 31 Mar, 2006 38 commits
-
-
Steve French authored
extra path. Since cifs_unlink can also be called from rename path and there was one report of oops am making the extra check for null inode. Signed-off-by:Steve French <sfrench@us.ibm.com>
-
Steve French authored
Fixes Samba bug 3621 and kernel.org bug 6147 For servers which require SMB/CIFS packet signing, we were sending the wrong signature (all zeros) on SMB Read request. The new cifs routine to do signatures across an iovec was not complete - and SMB Read, unlike the new SMBWrite2, did not fall back to the older routine (ie use SendReceive vs. the more efficient SendReceive2 ie used the older cifs_sign_smb vs. the disabled cifs_sign_smb2) for calculating signatures. This finishes up cifs_sign_smb2/cifs_calc_signature2 so that the callers of SendReceive2 can get SMB/CIFS packet signatures. Now that cifs_sign_smb2 is supported, we could start using it in the write path but this smaller fix does not include the change to use SMBWrite2 when signatures are required (which when enabled will make more Writes more efficient and alloc less memory). Currently Write2 is only used when signatures are not required at the moment but after more testing we will enable that as well). Thanks to James Slepicka and Sam Flory for initial investigation. Signed-off-by: -
Linus Torvalds authored
* master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6: [NET]: Allow skb headroom to be overridden [TCP]: Kill unused extern decl for tcp_v4_hash_connecting() [NET]: add SO_RCVBUF comment [NET]: Deinline some larger functions from netdevice.h [DCCP]: Use NULL for pointers, comfort sparse. [DECNET]: Fix refcount
-
Jes Sorensen authored
Commit 70674f95: [PATCH] Optimize select/poll by putting small data sets on the stack resulted in the poll stack being 4-byte aligned on 64-bit architectures, causing misaligned accesses to elements in the array. This patch fixes it by declaring the stack in terms of 'long' instead of 'char'. Force alignment of poll and select stacks to long to avoid unaligned access on 64 bit architectures. Signed-off-by:
Jes Sorensen <jes@sgi.com> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Linus Torvalds authored
* 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev: [PATCH] libata: fix ata_xfer_tbl termination [PATCH] libata: make ata_qc_issue complete failed qcs [PATCH] libata: fix ata_qc_issue failure path [PATCH] ata_piix: fix ich6/m_map_db [libata] ahci: add ATI SB600 PCI IDs
-
David Howells authored
The attached patch documents the Linux kernel's memory barriers. I've updated it from the comments I've been given. The per-arch notes sections are gone because it's clear that there are so many exceptions, that it's not worth having them. I've added a list of references to other documents. I've tried to get rid of the concept of memory accesses appearing on the bus; what matters is apparent behaviour with respect to other observers in the system. Interrupts barrier effects are now considered to be non-existent. They may be there, but you may not rely on them. I've added a couple of definition sections at the top of the document: one to specify the minimum execution model that may be assumed, the other to specify what this document refers to by the term "memory". I've made greater mention of the use of mmiowb(). I've adjusted the way in which caches are described, and described the fun that can be had with cache coherence maintenance being unordered and data dependency not being necessarily implicit. I've described (smp_)read_barrier_depends(). I've rearranged the order of the sections, so that memory barriers are discussed in abstract first, and then described the memory barrier facilities available on Linux, before going on to more real-world discussions and examples. I've added information about the lack of memory barriering effects with atomic ops and bitops. I've added information about control dependencies. I've added more diagrams to illustrate caching interactions between CPUs. Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
-
Kirill Korotaev authored
Wrong error path in dup_fd() - it should return NULL on error, not an address of already freed memory :/ Triggered by OpenVZ stress test suite. What is interesting is that it was causing different oopses in RCU like below: Call Trace: [<c013492c>] rcu_do_batch+0x2c/0x80 [<c0134bdd>] rcu_process_callbacks+0x3d/0x70 [<c0126cf3>] tasklet_action+0x73/0xe0 [<c01269aa>] __do_softirq+0x10a/0x130 [<c01058ff>] do_softirq+0x4f/0x60 ======================= [<c0113817>] smp_apic_timer_interrupt+0x77/0x110 [<c0103b54>] apic_timer_interrupt+0x1c/0x24 Code: Bad EIP value. <0>Kernel panic - not syncing: Fatal exception in interrupt Signed-Off-By:
Pavel Emelianov <xemul@sw.ru> Signed-Off-By:
Dmitry Mishin <dim@openvz.org> Signed-Off-By:
Kirill Korotaev <dev@openvz.org> Signed-Off-By:
-
Nicolas Pitre authored
Turn some macros into inline functions and add proper type checking as well as being more readable. Also a minor comment adjustment. Signed-off-by:
Nicolas Pitre <nico@cam.org> Acked-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
-
Jesper Juhl authored
Decrease the number of pointer derefs in drivers/serial/jsm/jsm_tty.c Benefits of the patch: - Fewer pointer dereferences should make the code slightly faster. - Size of generated code is smaller - Improved readability Signed-off-by:
Jesper Juhl <jesper.juhl@gmail.com> Acked-by:
"V. ANANDA KRISHNAN" <mansarov@us.ibm.com> Signed-off-by:
-
Adrian Bunk authored
As announced, lookup_hash() can now become static. Signed-off-by:
Adrian Bunk <bunk@stusta.de> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Adrian Bunk authored
The only user of get_wchan is the proc fs - and proc can't be built modular. Signed-off-by:
-
NeilBrown authored
Signed-off-by:
Brad Campbell <brad@wasp.net.au> Signed-off-by:
Neil Brown <neilb@suse.de> Signed-off-by:
-
NeilBrown authored
And remove the comments that were put in inplace of a fix too.... Signed-off-by:
-
NeilBrown authored
Currently a device failure during recovery leaves bits set in the bitmap. This normally isn't a problem as the offending device will be rejected because of errors. However if device re-adding is being used with non-persistent bitmaps, this can be a problem. Signed-off-by:
-
Michael Hanselmann authored
This patch removes the old radeon driver which has been replaced by a newer one. Signed-off-by:
Michael Hanselmann <linux-kernel@hansmi.ch> Acked-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
Antonino Daplas <adaplas@pol.net> Signed-off-by:
-
Antonino A. Daplas authored
The monochrome->color expansion routine that handles bitmaps which have (widths % 8) != 0 (slow_imageblit) produces corrupt characters in big-endian. This is caused by a bogus bit test in slow_imageblit(). Fix. This patch may deserve to go to the stable tree. The code has already been well tested in little-endian machines. It's only in big-endian where there is uncertainty and Herbert confirmed that this is the correct way to go. It should not introduce regressions. Signed-off-by:
Herbert Poetzl <herbert@13thfloor.at> Cc: <stable@kernel.org> Signed-off-by:
-
Richard Purdie authored
Fixes for the pxafb driver: * Return -EINVAL for resolutions that are too large as per framebuffer driver policy. * Increase the error timeout for disabling the LCD controller. The current timeout is sometimes too short on the Sharp Zaurus Cxx00 hardware and an extra delay in an error path shouldn't pose any problems. * Fix a dev reference which causes a compile error when DEBUG is defined. Signed-off-by:
Richard Purdie <rpurdie@rpsys.net> Signed-off-by:
-
Richard Purdie authored
Generalise the Corgi backlight driver by moving the default intensity and limit mask settings into the platform specific data structure. This enables the driver to support other Zaurus hardware, specifically the SL-6000x (Tosa) model. Also change the spinlock to a mutex (the spinlock is overkill). Signed-off-by:
-
Richard Purdie authored
Updates to the HP Jornada 680 Backlight driver: - Correct the suspend/resume functions so the driver compiles (SUSPEND_POWER_DOWN/RESUME_POWER_ON no longer exist). - Convert the driver to match the recent platform device changes. - Replace the unsafe static struct platform_device with dynamic allocation. - Convert the driver to the new backlight code. This has not been tested on a device due to lack of hardware but wouldn't compile beforehand. Signed-off-by:
-
Richard Purdie authored
Backlight class attributes are currently easy to implement incorrectly. Moving certain handling into the backlight core prevents this whilst at the same time makes the drivers simpler and consistent. The following changes are included: The brightness attribute only sets and reads the brightness variable in the backlight_properties structure. The power attribute only sets and reads the power variable in the backlight_properties structure. Any framebuffer blanking events change a variable fb_blank in the backlight_properties structure. The backlight driver has only two functions to implement. One function is called when any of the above properties change (to update the backlight brightness), the second is called to return the current backlight brightness value. A new attribute "actual_brightness" is added to return this brightness as determined by the driver having combined all the above factors (and any driver/device specific factors). Additionally, the backlight core takes care of checking the maximum brightness is not exceeded and of turning off the backlight before device removal. The corgi backlight driver is updated to reflect these changes. Signed-off-by:
-
Alberto Mardegan authored
Add acceleration support in w100fb.c (i.e. ATI Imageons) for the copyarea and fillrect operations. Signed-off-by:
Alberto Mardegan <mardy@users.sourceforge.net> Signed-off-by:
-
Antonino A. Daplas authored
The current display was not saved during initialization. This leads to hard to track console corruption, such as a misplaced cursor, which is correctible by switching consoles. Fix this minor bug. Signed-off-by:
-
Eric W. Biederman authored
It is very common to hash a dentry and then to call lookup. If we take fs specific hash functions into account the full hash logic can get ugly. Further full_name_hash as an inline function is almost 100 bytes on x86 so having a non-inline choice in some cases can measurably decrease code size. Signed-off-by:
Eric W. Biederman <ebiederm@xmission.com> Signed-off-by:
-
Eric W. Biederman authored
Simplifies the code, reduces the need for 4 pid hash tables, and makes the code more capable. In the discussions I had with Oleg it was felt that to a large extent the cleanup itself justified the work. With struct pid being dynamically allocated meant we could create the hash table entry when the pid was allocated and free the hash table entry when the pid was freed. Instead of playing with the hash lists when ever a process would attach or detach to a process. For myself the fact that it gave what my previous task_ref patch gave for free with simpler code was a big win. The problem is that if you hold a reference to struct task_struct you lock in 10K of low memory. If you do that in a user controllable way like /proc does, with an unprivileged but hostile user space application with typical resource limits of 1000 fds and 100 processes I can trigger the OOM killer by consuming all of low memory with task structs, on a machine wight 1GB of low memory. If I instead hold a reference to struct pid which holds a pointer to my task_struct, I don't suffer from that problem because struct pid is 2 orders of magnitude smaller. In fact struct pid is small enough that most other kernel data structures dwarf it, so simply limiting the number of referring data structures is enough to prevent exhaustion of low memory. This splits the current struct pid into two structures, struct pid and struct pid_link, and reduces our number of hash tables from PIDTYPE_MAX to just one. struct pid_link is the per process linkage into the hash tables and lives in struct task_struct. struct pid is given an indepedent lifetime, and holds pointers to each of the pid types. The independent life of struct pid simplifies attach_pid, and detach_pid, because we are always manipulating the list of pids and not the hash table. In addition in giving struct pid an indpendent life it makes the concept much more powerful. Kernel data structures can now embed a struct pid * instead of a pid_t and not suffer from pid wrap around problems or from keeping unnecessarily large amounts of memory allocated. Signed-off-by:
-
Eric W. Biederman authored
A big problem with rcu protected data structures that are also reference counted is that you must jump through several hoops to increase the reference count. I think someone finally implemented atomic_inc_not_zero(&count) to automate the common case. Unfortunately this means you must special case the rcu access case. When data structures are only visible via rcu in a manner that is not determined by the reference count on the object (i.e. tasks are visible until their zombies are reaped) there is a much simpler technique we can employ. Simply delaying the decrement of the reference count until the rcu interval is over. What that means is that the proc code that looks up a task and later wants to sleep can now do: rcu_read_lock(); task = find_task_by_pid(some_pid); if (task) { get_task_struct(task); } rcu_read_unlock(); The effect on the rest of the kernel is that put_task_struct becomes cheaper and immediate, and in the case where the task has been reaped it frees the task immediate instead of unnecessarily waiting an until the rcu interval is over. Cleanup of task_struct does not happen when its reference count drops to zero, instead cleanup happens when release_task is called. Tasks can only be looked up via rcu before release_task is called. All rcu protected members of task_struct are freed by release_task. Therefore we can move call_rcu from put_task_struct into release_task. And we can modify release_task to not immediately release the reference count but instead have it call put_task_struct from the function it gives to call_rcu. The end result: - get_task_struct is safe in an rcu context where we have just looked up the task. - put_task_struct() simplifies into its old pre rcu self. This reorganization also makes put_task_struct uncallable from modules as it is not exported but it does not appear to be called from any modules so this should not be an issue, and is trivially fixed. Signed-off-by: -
Herbert Poetzl authored
proc_check_chroot() does the check in a very unintuitive way (keeping a copy of the argument, then modifying the argument), and has uncommented sideeffects. Signed-off-by:
-
Andrew Morton authored
This just got nuked in mainline. Bring it back because Eric's patches use it. Cc: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
Eric W. Biederman authored
The core problem: setsid fails if it is called by init. The effect in 2.6.16 and the earlier kernels that have this problem is that if you do a "ps -j 1 or ps -ej 1" you will see that init and several of it's children have process group and session == 0. Instead of process group == session == 1. Despite init calling setsid. The reason it fails is that daemonize calls set_special_pids(1,1) on kernel threads that are launched before /sbin/init is called. The only remaining effect in that current->signal->leader == 0 for init instead of 1. And the setsid call fails. No one has noticed because /sbin/init does not check the return value of setsid. In 2.4 where we don't have the pidhash table, and daemonize doesn't exist setsid actually works for init. I care a lot about pid == 1 not being a special case that we leave broken, because of the container/jail work that I am doing. - Carefully allow init (pid == 1) to call setsid despite the kernel using its session. - Use find_task_by_pid instead of find_pid because find_pid taking a pidtype is going away. Signed-off-by:
-
Thomas Gleixner authored
The futex timeval is not checked for correctness. The change does not break existing applications as the timeval is supplied by glibc (and glibc always passes a correct value), but the glibc-internal tests for this functionality fail. Signed-off-by:
Thomas Gleixner <tglx@tglx.de> Signed-off-by:
-
Con Kolivas authored
To increase the strength of SCHED_BATCH as a scheduling hint we can activate batch tasks on the expired array since by definition they are latency insensitive tasks. Signed-off-by:
Con Kolivas <kernel@kolivas.org> Acked-by:
-
Con Kolivas authored
On runqueue time is used to elevate priority in schedule(). In the code it currently requeues tasks even if their priority is not elevated, which would end up placing them at the end of their runqueue array effectively delaying them instead of improving their priority. Bug spotted by Mike Galbraith <efault@gmx.de> This patch removes this requeueing. Signed-off-by:
-
Con Kolivas authored
Tasks waiting in SLEEP_NONINTERACTIVE state can now get to best priority so they need to be included in the idle detection code. Signed-off-by:
-
Con Kolivas authored
We watch for tasks that sleep extended periods and don't allow one single prolonged sleep period from elevating priority to maximum bonus to prevent cpu bound tasks from getting high priority with single long sleeps. There is a bug in the current code that also penalises tasks that already have high priority. Correct that bug. Signed-off-by:
-
Con Kolivas authored
Alterations to the pipe code in the kernel made it possible for relative starvation to occur with tasks that slept waiting on a pipe getting unfair priority bonuses even if they were otherwise fully cpu bound so the TASK_NONINTERACTIVE flag was introduced which prevented any change to sleep_avg while sleeping waiting on a pipe. This change also leads to the converse though, preventing any priority boost from occurring in truly interactive tasks that wait on pipes. Convert the TASK_NONINTERACTIVE flag to set sleep_type to SLEEP_NONINTERACTIVE which will allow a linear bonus to priority based on sleep time thus allowing interactive tasks to get high priority if they sleep enough. Signed-off-by:
-
Con Kolivas authored
The activated flag in task_struct is used to track different sleep types and its usage is somewhat obfuscated. Convert the variable to an enum with more descriptive names without altering the function. Signed-off-by:
-
Jack Steiner authored
Currently, count_active_tasks() calls both nr_running() & nr_interruptible(). Each of these functions does a "for_each_cpu" & reads values from the runqueue of each cpu. Although this is not a lot of instructions, each runqueue may be located on different node. Depending on the architecture, a unique TLB entry may be required to access each runqueue. Since there may be more runqueues than cpu TLB entries, a scan of all runqueues can trash the TLB. Each memory reference incurs a TLB miss & refill. In addition, the runqueue cacheline that contains nr_running & nr_uninterruptible may be evicted from the cache between the two passes. This causes unnecessary cache misses. Combining nr_running() & nr_interruptible() into a single function substantially reduces the TLB & cache misses on large systems. This should have no measureable effect on smaller systems. On a 128p IA64 system running a memory stress workload, the new function reduced the overhead of calc_load() from 605 usec/call to 324 usec/call. Signed-off-by:
Jack Steiner <steiner@sgi.com> Acked-by:
-
Dimitri Sivanich authored
It seems that run_hrtimer_queue() is calling get_softirq_time() more often than it needs to. With this patch, it only calls get_softirq_time() if there's a pending timer. Signed-off-by:
Dimitri Sivanich <sivanich@sgi.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Thomas Gleixner authored
Replace the nanosleep private sleeper functionality by the generic hrtimer sleeper. Signed-off-by:
-
