linux-toradex.git/fs, branch v2.6.13.4

[PATCH] Avoid 'names_cache' memory leak with CONFIG_AUDITSYSCALL

2005-10-10T18:50:54+00:00

Avoid 'names_cache' memory leak with CONFIG_AUDITSYSCALL

The nameidata "last.name" is always allocated with "__getname()", and
should always be free'd with "__putname()".

Using "putname()" without the underscores will leak memory, because the
allocation will have been hidden from the AUDITSYSCALL code.

Arguably the real bug is that the AUDITSYSCALL code is really broken,
but in the meantime this fixes the problem people see.

Reported by Robert Derr, patch by Rick Lindsley.

Acked-by: Al Viro 
Signed-off-by: Linus Torvalds 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

[PATCH] Fix fs/exec.c:788 (de_thread()) BUG_ON

2005-10-03T23:27:17+00:00

It turns out that the BUG_ON() in fs/exec.c: de_thread() is unreliable
and can trigger due to the test itself being racy.

de_thread() does
 	while (atomic_read(&sig->count) > count) {
	}
	.....
	.....
	BUG_ON(!thread_group_empty(current));

but release_task does
	write_lock_irq(&tasklist_lock)
	__exit_signal
		(this is where atomic_dec(&sig->count) is run)
	__exit_sighand
	__unhash_process
		takes write lock on tasklist_lock
		remove itself out of PIDTYPE_TGID list
	write_unlock_irq(&tasklist_lock)

so there's a clear (although small) window between the
atomic_dec(&sig->count) and the actual PIDTYPE_TGID unhashing of the
thread.

And actually there is no need for all threads to have exited at this
point, so we simply kill the BUG_ON.

Big thanks to Marc Lehmann who provided the test-case.

Fixes Bug 5170 (http://bugme.osdl.org/show_bug.cgi?id=5170)

Signed-off-by: Alexander Nyberg 
Cc: Roland McGrath 
Cc: Andrew Morton 
Cc: Ingo Molnar 
Acked-by: Andi Kleen 
Signed-off-by: Linus Torvalds 
Signed-off-by: Chris Wright

[PATCH] jfs: jfs_delete_inode must call clear_inode

2005-09-17T01:01:58+00:00

JFS: jfs_delete_inode should always call clear_inode.

> From Chuck Ebbert:
I'm submitting this patch for -stable:

  - it reportedly fixes an oops
  - it's already in 2.6.13-git

Signed-off-by: Dave Kleikamp 
Signed-off-by: Chris Wright

[PATCH] Lost sockfd_put() in routing_ioctl()

2005-09-17T01:01:56+00:00

This patch adds lost sockfd_put() in 32bit compat rounting_ioctl() on
64bit platforms, bug found by Vasiliy Averin .

I believe this is a security issues, since user can fget() file as many
times as he wants to. So file refcounter can be overlapped and first
fput() will free resources though there will be still structures
pointing to the file, mnt, dentry etc.
Also fput() sets f_dentry and f_vfsmnt to NULL,
so other file users will OOPS.

The oops can be done under files_lock and others, so this can be an
exploitable DoS on SMP. Didn't checked it on practice actually.

Signed-Off-By: Kirill Korotaev 
Signed-Off-By: Maxim Giryaev 
Signed-off-by: Chris Wright

[PATCH] Fix oops in sysfs_hash_and_remove_file()

2005-08-27T02:37:13+00:00

The problem arises if an entity in sysfs is created and removed without
ever having been made completely visible.  In SCSI this is triggered by
removing a device while it's initialising.

The problem appears to be that because it was never made visible in sysfs,
the sysfs dentry has a null d_inode which oopses when a reference is made
to it.  The solution is simply to check d_inode and assume the object was
never made visible (and thus doesn't need deleting) if it's NULL.

(akpm: possibly a stopgap for 2.6.13 scsi problems.  May not be the
long-term fix)

Signed-off-by: James Bottomley 
Cc: Greg KH 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] Fix oops in fs/locks.c on close of file with pending locks

2005-08-26T23:05:35+00:00

The recent change to locks_remove_flock code in fs/locks.c changes how
byte range locks are removed from closing files, which shows up a bug in
cifs.

The assumption in the cifs code was that the close call sent to the
server would remove any pending locks on the server on this file, but
that is no longer safe as the fs/locks.c code on the client wants unlock
of 0 to PATH_MAX to remove all locks (at least from this client, it is
not possible AFAIK to remove all locks from other clients made to the
server copy of the file).

Note that cifs locks are different from posix locks - and it is not
possible to map posix locks perfectly on the wire yet, due to
restrictions of the cifs network protocol, even to Samba without adding
a new request type to the network protocol (which we plan to do for
Samba 3.0.21 within a few months), but the local client will have the
correct, posix view, of the lock in most cases.

The correct fix for cifs for this would involve a bigger change than I
would like to do this late in the 2.6.13-rc cycle - and would involve
cifs keeping track of all unmerged (uncoalesced) byte range locks for
each remote inode and scanning that list to remove locks that intersect
or fall wholly within the range - locks that intersect may have to be
reaquired with the smaller, remaining range.

Signed-off-by: Steve French 
Signed-off-by: Dave Kleikamp 
Signed-off-by: Linus Torvalds

[PATCH] hppfs: fix symlink error path

2005-08-26T18:39:19+00:00

While touching this code I noticed the error handling is bogus, so I
fixed it up.

I've removed the IS_ERR(proc_dentry) check, which will never trigger and
is clearly a typo: we must check proc_file instead.

Signed-off-by: Paolo 'Blaisorblade' Giarrusso 
Signed-off-by: Linus Torvalds

[PATCH] Fixup symlink function pointers for hppfs [for 2.6.13]

2005-08-26T18:39:19+00:00

Update hppfs for the symlink functions prototype change.

Yes, I know the code I leave there is still _bogus_, see next patch for
this.

Signed-off-by: Paolo 'Blaisorblade' Giarrusso 
Signed-off-by: Linus Torvalds

[PATCH] Document idr_get_new_above() semantics, update inotify

2005-08-26T18:32:57+00:00

There is an off by one problem with idr_get_new_above.

The comment and function name suggest that it will return an id >
starting_id, but it actually returned an id >= starting_id, and kernel
callers other than inotify treated it as such.

The patch below fixes the comment, and fixes inotifys usage.  The
function name still doesn't match the behaviour, but it never did.

Signed-off-by: John McCutchan 
Signed-off-by: Linus Torvalds

Don't allow normal users to set idle IO priority

2005-08-21T01:51:29+00:00

It has all the normal priority inversion problems.

Signed-off-by: Linus Torvalds