19 Oct, 2005
10 commits
-
This is needed by NFSv4 for atomicity reasons: our open command is in
fact a lookup+open, so we need to be able to propagate open context
information from lookup() into the resulting struct file's
private_data field.Signed-off-by: Trond Myklebust
-
...and fix a memory corruption bug due to improper use of memcpy() on
a struct file_lock.Signed-off-by: Trond Myklebust
-
Signed-off-by: Trond Myklebust
-
Currently we fail to do so if the process was signalled.
Signed-off-by: Trond Myklebust
-
Signed-off-by: Trond Myklebust
-
We no longer need to worry about collisions between close() and the state
recovery code, since the new close will automatically recheck the
file state once it is done waiting on its sequence slot.Ditto for the nfs4_proc_locku() procedure.
Signed-off-by: Trond Myklebust
-
OPEN, CLOSE, etc no longer need these semaphores to ensure ordering of
requests.Signed-off-by: Trond Myklebust
-
Once the state_owner and lock_owner semaphores get removed, it will be
possible for other OPEN requests to reopen the same file if they have
lower sequence ids than our CLOSE call.
This patch ensures that we recheck the file state once
nfs_wait_on_sequence() has completed waiting.Signed-off-by: Trond Myklebust
-
NFSv4 file state-changing functions such as OPEN, CLOSE, LOCK,... are all
labelled with "sequence identifiers" in order to prevent the server from
reordering RPC requests, as this could cause its file state to
become out of sync with the client.Currently the NFS client code enforces this ordering locally using
semaphores to restrict access to structures until the RPC call is done.
This, of course, only works with synchronous RPC calls, since the
user process must first grab the semaphore.
By dropping semaphores, and instead teaching the RPC engine to hold
the RPC calls until they are ready to be sent, we can extend this
process to work nicely with asynchronous RPC calls too.This patch adds a new list called "rpc_sequence" that defines the order
of the RPC calls to be sent. We add one such list for each state_owner.
When an RPC call is ready to be sent, it checks if it is top of the
rpc_sequence list. If so, it proceeds. If not, it goes back to sleep,
and loops until it hits top of the list.
Once the RPC call has completed, it can then bump the sequence id counter,
and remove itself from the rpc_sequence list, and then wake up the next
sleeper.Note that the state_owner sequence ids and lock_owner sequence ids are
all indexed to the same rpc_sequence list, so OPEN, LOCK,... requests
are all ordered w.r.t. each other.Signed-off-by: Trond Myklebust
18 Oct, 2005
4 commits
-
lock_kiocb() was introduced to serialize retrying and cancellation. In the
process of doing so it tried to sleep waiting for KIF_LOCKED while holding
the ctx_lock spinlock. Recent fixes have ensured that multiple concurrent
retries won't be attempted for a given iocb. Cancel has other problems and
has no significant in-tree users that have been complaining about it. So
for the immediate future we'll revert sleeping with the lock held and will
address proper cancellation and retry serialization in the future.Signed-off-by: Zach Brown
Acked-by: Benjamin LaHaise
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Currently you do not get all the map entries on nommu systems because the
start function doesn't index into the list using the value of "pos".Signed-off-by: David McCullough
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Oopsable since nfs_wait_on_inode() can get called as part of iput_final().
Unnecessary since the caller had better be damned sure that the inode won't
disappear from underneath it anyway.Signed-off-by: Trond Myklebust
Signed-off-by: Linus Torvalds -
If the data cache has been marked as potentially invalid by nfs_refresh_inode,
we should invalidate it rather than assume that changes are due to our own
activity.Also ensure that we always start with a valid cache before declaring it
to be protected by a delegation.Signed-off-by: Trond Myklebust
Signed-off-by: Linus Torvalds
15 Oct, 2005
1 commit
-
"proc_smaps_operations" is not defined in case of "CONFIG_MMU=n".
Signed-off-by: Yoshinori Sato
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
12 Oct, 2005
3 commits
-
Nir Tzachar points out that if an ELF file specifies a
zero-length bss at a whacky address, we cannot load that binary because
padzero() tries to zero out the end of the page at the whacky address, and
that may not be writeable.See also http://bugzilla.kernel.org/show_bug.cgi?id=5411
So teach load_elf_binary() to skip the bss settng altogether if the elf file
has a zero-length bss segment.Cc: Roland McGrath
Cc: Daniel Jacobowitz
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Here is a compatibility fix between Linux and Solaris when used with VxFS
filesystems: Solaris usually accepts acl entries in any order, but with
VxFS it replies with NFSERR_INVAL when it sees a four-entry acl that is not
in canonical form. It may also fail with other non-canonical acls -- I
can't tell, because that case never triggers: We only send non-canonical
acls when we fake up an ACL_MASK entry.Instead of adding fake ACL_MASK entries at the end, inserting them in the
correct position makes Solaris+VxFS happy. The Linux client and server
sides don't care about entry order. The three-entry-acl special case in
which we need a fake ACL_MASK entry was handled in xdr_nfsace_encode. The
patch moves this into nfsacl_encode.Signed-off-by: Andreas Gruenbacher
Acked-by: Trond Myklebust
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
v9fs_file_read and v9fs_file_write use kmalloc to allocate buffers as big
as the data buffer received as parameter. kmalloc cannot be used to
allocate buffers bigger than 128K, so reading/writing data in chunks bigger
than 128k fails.This patch reorganizes v9fs_file_read and v9fs_file_write to allocate only
buffers as big as the maximum data that can be sent in one 9P message.Signed-off-by: Latchesar Ionkov
Cc: Eric Van Hensbergen
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
10 Oct, 2005
1 commit
-
The third param in this call to vmap shouldn't be GFP_KERNEL, which
makes no sense, but rather VM_MAP. Thanks to Al Viro for spotting
this.Signed-off-by: Tom Zanussi
Signed-off-by: Linus Torvalds
09 Oct, 2005
1 commit
-
- added typedef unsigned int __nocast gfp_t;
- replaced __nocast uses for gfp flags with gfp_t - it gives exactly
the same warnings as far as sparse is concerned, doesn't change
generated code (from gcc point of view we replaced unsigned int with
typedef) and documents what's going on far better.Signed-off-by: Al Viro
Signed-off-by: Linus Torvalds
07 Oct, 2005
1 commit
-
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
05 Oct, 2005
2 commits
-
bfs_fill_super() walks the inode table to get the bitmap of free inodes
and collect stats. It has no business using iget() for that - it's a
lot of extra work, extra icache pollution and more complex code.
Switched to walking the damn thing directly.Note: that also allows to kill ->i_dsk_ino in there - separate patch if
Tigran can confirm that this field can be zero only for deleted inodes
(i.e. something that could only be found during that scan and not by
normal lookups).Signed-off-by: Al Viro
Signed-off-by: Linus Torvalds -
Signed-off-by: Alexey Dobriyan
Signed-off-by: Al Viro
Signed-off-by: Linus Torvalds
04 Oct, 2005
2 commits
-
which we now cast to 64-bit first (fs/ntfs/mft.c::map_mft_record_page().
Signed-off-by: Anton Altaparmakov
-
count to become negative and hence we had a wild memset() scribbling
all over the system's ram.Signed-off-by: Anton Altaparmakov
01 Oct, 2005
5 commits
-
Check O_DIRECT and return -EINVAL error in open. dentry_open() also checks
this but only after the open method is called. This patch optimizes away
the unnecessary upcalls in this case.It could be a correctness issue too: if filesystem has open() with side
effect, then it should fail before doing the open, not after.Signed-off-by: Miklos Szeredi
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Calling truncate() on hostfs spits a kernel warning "Something isn't
implemented here", but it still works fine.Indeed, hostfs i_op->truncate doesn't do anything. But hostfs_setattr() ->
set_attr() correctly detects ATTR_SIZE and calls truncate() on the host. So
we should be safe (using ftruncate() may be better, in case the file is
unlinked on the host, but we aren't sure to have the file open for writing,
and reopening it would cause the same races; plus nobody should expect UML to
be so careful).So, the warning is wrong, because the current implementation is working. Al,
am I correct, and can the warning be therefore dropped?CC: Al Viro
Signed-off-by: Paolo 'Blaisorblade' Giarrusso
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Recently aio_p{read,write} changed to perform retries internally rather
than returning -EIOCBRETRY. This inadvertantly resulted in always calling
aio_{read,write} with ki_left at 0 which would in turn immediately return
0. Harmless, but we can avoid this call by checking in the caller.Signed-off-by: Zach Brown
Signed-off-by: Benjamin LaHaise
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Only one of the run or kick path is supposed to put an iocb on the run
list. If both of them do it than one of them can end up referencing a
freed iocb. The kick path could delete the task_list item from the wait
queue before getting the ctx_lock and putting the iocb on the run list.
The run path was testing the task_list item outside the lock so that it
could catch ki_retry methods that return -EIOCBRETRY *without* putting the
iocb on a wait queue and promising to call kick_iocb. This unlocked check
could then race with the kick path to cause both to try and put the iocb on
the run list.The patch stops the run path from testing task_list by requring that any
ki_retry that returns -EIOCBRETRY *must* guarantee that kick_iocb() will be
called in the future. aio_p{read,write}, the only in-tree -EIOCBRETRY
users, are updated.Signed-off-by: Zach Brown
Signed-off-by: Benjamin LaHaise
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Only one of the run or kick path is supposed to put an iocb on the run
list. If both of them do it than one of them can end up referencing a
freed iocb. The kick patch could set the Kicked bit before acquiring the
ctx_lock and putting the iocb on the run list. The run path, while holding
the ctx_lock, could see this partial kick and mistake it for a kick that
was deferred while it was doing work with the run_list NULLed out. It
would then race with the kick thread to add the iocb to the run list.This patch moves the kick setting under the ctx_lock so that only one of
the kick or run path queues the iocb on the run list, as intended.Signed-off-by: Zach Brown
Signed-off-by: Benjamin LaHaise
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
30 Sep, 2005
2 commits
-
Signed-off-by: Al Viro
Signed-off-by: Linus Torvalds -
it seems that readv(2)/writev(2) syscalls do not call
file_permission callback. Looks like this is overlook.I have filled the issue into redhat bugzilla as
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169433
and got the recommendation to post this on lsm mailing list.The following trivial patch solves the problem.
Signed-off-by: Kostik Belousov
Signed-off-by: Chris Wright
28 Sep, 2005
6 commits
-
Handle the timeout upper boundary for epoll.
Signed-off-by: Davide Libenzi
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Fid management cleanup. The patch attempts to fix the races in dentry's
fid management.Dentries don't keep the opened fids anymore, they are moved to the file
structs. Ideally there should be no more than one fid with fidcreate equal
to zero in the dentry's list of fids.v9fs_fid_create initializes the important fields (fid, fidcreated) before
v9fs_fid is added to the list. v9fs_fid_lookup returns only fids that are
not created by v9fs_create. v9fs_fid_get_created returns the fid created
by the same process by v9fs_create (if any) and removes it from dentry's
listSigned-off-by: Latchesar Ionkov
Cc: Eric Van Hensbergen
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Fix failure paths in ext3_new_inode() and clean up duplicated code: -
DQUOT_DROP() was not being called if ext3_init_security() failed.Signed-off-by: Chris Sykes
Cc: Stephen Smalley
Cc: Jan Kara
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Fix failure paths in ext2_new_inode() and clean up duplicated code: -
DQUOT_DROP() was not being called if ext2_init_security() failed.Signed-off-by: Chris Sykes
Cc: Stephen Smalley
Cc: Jan Kara
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
This patch checks reserved node ID values returned by lookup and creation
operations. In case one of the reserved values is sent, return -EIO.Signed-off-by: Miklos Szeredi
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Add information about required version of the userspace library/utilities
to Documentation/Changes. Also add pointer to this and to FUSE
documentation from Kconfig.Thanks to Anton Altaparmakov for the reminder.
Signed-off-by: Miklos Szeredi
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
27 Sep, 2005
1 commit
-
different types in it but #define the two constants instead.
Signed-off-by: Anton Altaparmakov
26 Sep, 2005
1 commit