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

[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

[PATCH] freevxfs: fix breakage introduced by symlink fixes

2005-08-20T21:30:50+00:00

Signed-off-by: Alexey Dobriyan 
Signed-off-by: Linus Torvalds

befs: fix up missed follow_link declaration change

2005-08-20T20:20:01+00:00

We'd updated the prototype and the return value, but not the function
declaration itself.