summaryrefslogtreecommitdiff
path: root/fs/cifs
AgeCommit message (Collapse)AuthorFilesLines
2012-11-26cifs: fix potential buffer overrun in cifs.idmap handling codeJeff Layton1-29/+20
commit 36960e440ccf94349c09fb944930d3bfe4bc473f upstream. The userspace cifs.idmap program generally works with the wbclient libs to generate binary SIDs in userspace. That program defines the struct that holds these values as having a max of 15 subauthorities. The kernel idmapping code however limits that value to 5. When the kernel copies those values around though, it doesn't sanity check the num_subauths value handed back from userspace or from the server. It's possible therefore for userspace to hand us back a bogus num_subauths value (or one that's valid, but greater than 5) that could cause the kernel to walk off the end of the cifs_sid->sub_auths array. Fix this by defining a new routine for copying sids and using that in all of the places that copy it. If we end up with a sid that's longer than expected then this approach will just lop off the "extra" subauths, but that's basically what the code does today already. Better approaches might be to fix this code to reject SIDs with >5 subauths, or fix it to handle the subauths array dynamically. At the same time, change the kernel to check the length of the data returned by userspace. If it's shorter than struct cifs_sid, reject it and return -EIO. If that happens we'll end up with fields that are basically uninitialized. Long term, it might make sense to redefine cifs_sid using a flexarray at the end, to allow for variable-length subauth lists, and teach the code to handle the case where the subauths array being passed in from userspace is shorter than 5 elements. Note too, that I don't consider this a security issue since you'd need a compromised cifs.idmap program. If you have that, you can do all sorts of nefarious stuff. Still, this is probably reasonable for stable. Reviewed-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com> Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-13Convert properly UTF-8 to UTF-16Frediano Ziglio1-0/+22
commit fd3ba42c76d3d4b776120c2b24c1791e7bb3deb1 upstream. wchar_t is currently 16bit so converting a utf8 encoded characters not in plane 0 (>= 0x10000) to wchar_t (that is calling char2uni) lead to a -EINVAL return. This patch detect utf8 in cifs_strtoUTF16 and add special code calling utf8s_to_utf16s. Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com> Acked-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <smfrench@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-13cifs: reinstate the forcegid optionJeff Layton1-0/+9
commit 72bd481f860f0125c810bb43d878ce5f9c060c58 upstream. Apparently this was lost when we converted to the standard option parser in 8830d7e07a5e38bc47650a7554b7c1cfd49902bf Reported-by: Gregory Lee Bartholomew <gregory.lee.bartholomew@gmail.com> Cc: Sachin Prabhu <sprabhu@redhat.com> Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <smfrench@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-02cifs: fix return value in cifsConvertToUTF16Jeff Layton1-1/+1
commit c73f693989d7a7d99ec66a7065295a0c93d0b127 upstream. This function returns the wrong value, which causes the callers to get the length of the resulting pathname wrong when it contains non-ASCII characters. This seems to fix https://bugzilla.samba.org/show_bug.cgi?id=6767 Reported-by: Baldvin Kovacs <baldvin.kovacs@gmail.com> Reported-and-Tested-by: Nicolas Lefebvre <nico.lefebvre@gmail.com> Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <smfrench@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-08-09cifs: reinstate sec=ntlmv2 mount optionJeff Layton1-4/+5
commit 7659624ffb550d69c87f9af9ae63e717daa874bd upstream. sec=ntlmv2 as a mount option got dropped in the mount option overhaul. Cc: Sachin Prabhu <sprabhu@redhat.com> Reported-by: Günter Kukkukk <linux@kukkukk.com> Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <smfrench@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-07-29cifs: when CONFIG_HIGHMEM is set, serialize the read/write kmapsJeff Layton1-0/+30
commit 3cf003c08be785af4bee9ac05891a15bcbff856a upstream. [The async read code was broadened to include uncached reads in 3.5, so the mainline patch did not apply directly. This patch is just a backport to account for that change.] Jian found that when he ran fsx on a 32 bit arch with a large wsize the process and one of the bdi writeback kthreads would sometimes deadlock with a stack trace like this: crash> bt PID: 2789 TASK: f02edaa0 CPU: 3 COMMAND: "fsx" #0 [eed63cbc] schedule at c083c5b3 #1 [eed63d80] kmap_high at c0500ec8 #2 [eed63db0] cifs_async_writev at f7fabcd7 [cifs] #3 [eed63df0] cifs_writepages at f7fb7f5c [cifs] #4 [eed63e50] do_writepages at c04f3e32 #5 [eed63e54] __filemap_fdatawrite_range at c04e152a #6 [eed63ea4] filemap_fdatawrite at c04e1b3e #7 [eed63eb4] cifs_file_aio_write at f7fa111a [cifs] #8 [eed63ecc] do_sync_write at c052d202 #9 [eed63f74] vfs_write at c052d4ee #10 [eed63f94] sys_write at c052df4c #11 [eed63fb0] ia32_sysenter_target at c0409a98 EAX: 00000004 EBX: 00000003 ECX: abd73b73 EDX: 012a65c6 DS: 007b ESI: 012a65c6 ES: 007b EDI: 00000000 SS: 007b ESP: bf8db178 EBP: bf8db1f8 GS: 0033 CS: 0073 EIP: 40000424 ERR: 00000004 EFLAGS: 00000246 Each task would kmap part of its address array before getting stuck, but not enough to actually issue the write. This patch fixes this by serializing the marshal_iov operations for async reads and writes. The idea here is to ensure that cifs aggressively tries to populate a request before attempting to fulfill another one. As soon as all of the pages are kmapped for a request, then we can unlock and allow another one to proceed. There's no need to do this serialization on non-CONFIG_HIGHMEM arches however, so optimize all of this out when CONFIG_HIGHMEM isn't set. Reported-by: Jian Li <jiali@redhat.com> Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <smfrench@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-07-29cifs: on CONFIG_HIGHMEM machines, limit the rsize/wsize to the kmap spaceJeff Layton1-0/+18
commit 3ae629d98bd5ed77585a878566f04f310adbc591 upstream. We currently rely on being able to kmap all of the pages in an async read or write request. If you're on a machine that has CONFIG_HIGHMEM set then that kmap space is limited, sometimes to as low as 512 slots. With 512 slots, we can only support up to a 2M r/wsize, and that's assuming that we can get our greedy little hands on all of them. There are other users however, so it's possible we'll end up stuck with a size that large. Since we can't handle a rsize or wsize larger than that currently, cap those options at the number of kmap slots we have. We could consider capping it even lower, but we currently default to a max of 1M. Might as well allow those luddites on 32 bit arches enough rope to hang themselves. A more robust fix would be to teach the send and receive routines how to contend with an array of pages so we don't need to marshal up a kvec array at all. That's a fairly significant overhaul though, so we'll need this limit in place until that's ready. Reported-by: Jian Li <jiali@redhat.com> Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <smfrench@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-07-29cifs: always update the inode cache with the results from a FIND_*Jeff Layton1-2/+5
commit cd60042cc1392e79410dc8de9e9c1abb38a29e57 upstream. When we get back a FIND_FIRST/NEXT result, we have some info about the dentry that we use to instantiate a new inode. We were ignoring and discarding that info when we had an existing dentry in the cache. Fix this by updating the inode in place when we find an existing dentry and the uniqueid is the same. Reported-and-Tested-by: Andrew Bartlett <abartlet@samba.org> Reported-by: Bill Robertson <bill_robertson@debortoli.com.au> Reported-by: Dion Edwards <dion_edwards@debortoli.com.au> Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <smfrench@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-07-16cifs: when server doesn't set CAP_LARGE_READ_X, cap default rsize at ↵Jeff Layton1-6/+3
MaxBufferSize commit ec01d738a1691dfc85b96b9f796020267a7be577 upstream. When the server doesn't advertise CAP_LARGE_READ_X, then MS-CIFS states that you must cap the size of the read at the client's MaxBufferSize. Unfortunately, testing with many older servers shows that they often can't service a read larger than their own MaxBufferSize. Since we can't assume what the server will do in this situation, we must be conservative here for the default. When the server can't do large reads, then assume that it can't satisfy any read larger than its MaxBufferSize either. Luckily almost all modern servers can do large reads, so this won't affect them. This is really just for older win9x and OS/2 era servers. Also, note that this patch just governs the default rsize. The admin can always override this if he so chooses. Reported-by: David H. Durgee <dhdurgee@acm.org> Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steven French <sfrench@w500smf.none> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-07-16cifs: fix parsing of password mount optionSuresh Jayaraman1-15/+17
commit e73f843a3235a19de38359c91586e9eadef12238 upstream. The double delimiter check that allows a comma in the password parsing code is unconditional. We set "tmp_end" to the end of the string and we continue to check for double delimiter. In the case where the password doesn't contain a comma we end up setting tmp_end to NULL and eventually setting "options" to "end". This results in the premature termination of the options string and hence the values of UNCip and UNC are being set to NULL. This results in mount failure with "Connecting to DFS root not implemented yet" error. This error is usually not noticable as we have password as the last option in the superblock mountdata. But when we call expand_dfs_referral() from cifs_mount() and try to compose mount options for the submount, the resulting mountdata will be of the form ",ver=1,user=foo,pass=bar,ip=x.x.x.x,unc=\\server\share" and hence results in the above error. This bug has been seen with older NAS servers running Samba 3.0.24. Fix this by moving the double delimiter check inside the conditional loop. Changes since -v1 - removed the wrong strlen() micro optimization. Signed-off-by: Suresh Jayaraman <sjayaraman@suse.com> Acked-by: Sachin Prabhu <sprabhu@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-09cifs: fix oops while traversing open file list (try #4)Shirish Pargaonkar2-24/+34
commit 2c0c2a08bed7a3b791f88d09d16ace56acb3dd98 upstream. While traversing the linked list of open file handles, if the identfied file handle is invalid, a reopen is attempted and if it fails, we resume traversing where we stopped and cifs can oops while accessing invalid next element, for list might have changed. So mark the invalid file handle and attempt reopen if no valid file handle is found in rest of the list. If reopen fails, move the invalid file handle to the end of the list and start traversing the list again from the begining. Repeat this four times before giving up and returning an error if file reopen keeps failing. Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com> Reviewed-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-09cifs: Include backup intent search flags during searches {try #2)Shirish Pargaonkar3-11/+22
commit 2608bee744a92d60d15ff4e6e0b913d8b406aedd upstream. As observed and suggested by Tushar Gosavi... --------- readdir calls these function to send TRANS2_FIND_FIRST and TRANS2_FIND_NEXT command to the server. The current cifs module is not specifying CIFS_SEARCH_BACKUP_SEARCH flag while sending these command when backupuid/backupgid is specified. This can be resolved by specifying CIFS_SEARCH_BACKUP_SEARCH flag. --------- Reported-and-Tested-by: Tushar Gosavi <tugosavi@in.ibm.com> Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com> Acked-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-05-16cifs: fix misspelling of "forcedirectio"Jeff Layton1-1/+2
...and add a "directio" synonym since that's what the manpage has always advertised. Acked-by: Sachin Prabhu <sprabhu@redhat.com> Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
2012-05-10cifs: fix revalidation test in cifs_llseek()Dan Carpenter1-1/+1
This test is always true so it means we revalidate the length every time, which generates more network traffic. When it is SEEK_SET or SEEK_CUR, then we don't need to revalidate. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
2012-05-04fs/cifs: fix parsing of dfs referralsStefan Metzmacher1-1/+5
The problem was that the first referral was parsed more than once and so the caller tried the same referrals multiple times. The problem was introduced partly by commit 066ce6899484d9026acd6ba3a8dbbedb33d7ae1b, where 'ref += le16_to_cpu(ref->Size);' got lost, but that was also wrong... Cc: <stable@vger.kernel.org> Signed-off-by: Stefan Metzmacher <metze@samba.org> Tested-by: Björn Jacke <bj@sernet.de> Reviewed-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
2012-05-03cifs: make sure we ignore the credentials= and cred= optionsJeff Layton1-0/+2
Older mount.cifs programs passed this on to the kernel after parsing the file. Make sure the kernel ignores that option. Should fix: https://bugzilla.kernel.org/show_bug.cgi?id=43195 Cc: Sachin Prabhu <sprabhu@redhat.com> Reported-by: Ronald <ronald645@gmail.com> Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
2012-05-03[CIFS] Update cifs version to 1.78Steve French1-1/+1
Signed-off-by: Steve French <sfrench@us.ibm.com>
2012-05-03cifs - check S_AUTOMOUNT in revalidateIan Kent1-5/+12
When revalidating a dentry, if the inode wasn't known to be a dfs entry when the dentry was instantiated, such as when created via ->readdir(), the DCACHE_NEED_AUTOMOUNT flag needs to be set on the dentry in ->d_revalidate(). The false return from cifs_d_revalidate(), due to the inode now being marked with the S_AUTOMOUNT flag, might not invalidate the dentry if there is a concurrent unlazy path walk. This is because the dentry reference count will be at least 2 in this case causing d_invalidate() to return EBUSY. So the asumption that the dentry will be discarded then correctly instantiated via ->lookup() might not hold. Signed-off-by: Ian Kent <raven@themaw.net> Reviewed-by: Jeff Layton <jlayton@redhat.com> Cc: Steve French <smfrench@gmail.com> Cc: linux-cifs@vger.kernel.org Signed-off-by: Steve French <sfrench@us.ibm.com>
2012-05-02cifs: add missing initialization of server->req_lockJeff Layton1-0/+1
Cc: Pavel Shilovsky <piastryyy@gmail.com> Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
2012-05-02cifs: don't cap ra_pages at the same level as default_backing_dev_infoJeff Layton1-17/+1
While testing, I've found that even when we are able to negotiate a much larger rsize with the server, on-the-wire reads often end up being capped at 128k because of ra_pages being capped at that level. Lifting this restriction gave almost a twofold increase in sequential read performance on my craptactular KVM test rig with a 1M rsize. I think this is safe since the actual ra_pages that the VM requests is run through max_sane_readahead() prior to submitting the I/O. Under memory pressure we should end up with large readahead requests being suppressed anyway. Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
2012-05-02CIFS: Fix indentation in cifs_show_optionsSachin Prabhu1-1/+1
Trivial patch which fixes a misplaced tab in cifs_show_options(). Signed-off-by: Sachin Prabhu <sprabhu@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
2012-04-24Use correct conversion specifiers in cifs_show_optionsSachin Prabhu1-4/+4
cifs_show_options uses the wrong conversion specifier for uid, gid, rsize & wsize. Correct this to %u to match it to the variable type 'unsigned integer'. Signed-off-by: Sachin Prabhu <sprabhu@redhat.com> Reviewed-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
2012-04-24CIFS: Show backupuid/gid in /proc/mountsSachin Prabhu2-6/+10
Show backupuid/backupgid in /proc/mounts for cifs shares mounted with the backupuid/backupgid feature. Also consolidate the two separate checks for pvolume_info->backupuid_specified into a single if condition in cifs_setup_cifs_sb(). Signed-off-by: Sachin Prabhu <sprabhu@redhat.com> Reviewed-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
2012-04-20cifs: fix offset handling in cifs_iovec_writeJeff Layton1-1/+2
In the recent update of the cifs_iovec_write code to use async writes, the handling of the file position was broken. That patch added a local "offset" variable to handle the offset, and then only updated the original "*poffset" before exiting. Unfortunately, it copied off the original offset from the beginning, instead of doing so after generic_write_checks had been called. Fix this by moving the initialization of "offset" after that in the function. Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
2012-04-13Fix number parsing in cifs_parse_mount_optionsSachin Prabhu1-1/+1
The function kstrtoul() used to parse number strings in the mount option parser is set to expect a base 10 number . This treats the octal numbers passed for mount options such as file_mode as base10 numbers leading to incorrect behavior. Change the 'base' argument passed to kstrtoul from 10 to 0 to allow it to auto-detect the base of the number passed. Signed-off-by: Sachin Prabhu <sprabhu@redhat.com> Acked-by: Jeff Layton <jlayton@samba.org> Reported-by: Chris Clayton <chris2553@googlemail.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
2012-04-12Cleanup handling of NULL value passed for a mount optionSachin Prabhu1-61/+19
Allow blank user= and ip= mount option. Also clean up redundant checks for NULL values since the token parser will not actually match mount options with NULL values unless explicitly specified. Signed-off-by: Sachin Prabhu <sprabhu@redhat.com> Reported-by: Chris Clayton <chris2553@googlemail.com> Acked-by: Jeff Layton <jlayton@samba.org> Tested-by: Chris Clayton <chris2553@googlemail.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
2012-04-04Fix UNC parsing on mountSachin Prabhu1-7/+7
The code cleanup of cifs_parse_mount_options resulted in a new bug being introduced in the parsing of the UNC. This results in vol->UNC being modified before vol->UNC was allocated. Reported-by: Steve French <smfrench@gmail.com> Signed-off-by: Sachin Prabhu <sprabhu@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
2012-04-04Remove unnecessary check for NULL in password parserSachin Prabhu1-2/+1
The password parser has an unnecessary check for a NULL value which triggers warnings in source checking tools. The code contains artifacts from the old parsing code which are no longer required. Signed-off-by: Sachin Prabhu <sprabhu@redhat.com> Reviewed-by: Jeff Layton <jlayton@redhat.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
2012-04-01CIFS: Fix VFS lock usage for oplocked filesPavel Shilovsky1-1/+9
We can deadlock if we have a write oplock and two processes use the same file handle. In this case the first process can't unlock its lock if the second process blocked on the lock in the same time. Fix it by using posix_lock_file rather than posix_lock_file_wait under cinode->lock_mutex. If we request a blocking lock and posix_lock_file indicates that there is another lock that prevents us, wait untill that lock is released and restart our call. Cc: stable@kernel.org Acked-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Pavel Shilovsky <piastry@etersoft.ru> Signed-off-by: Steve French <sfrench@us.ibm.com>
2012-04-01Revert "CIFS: Fix VFS lock usage for oplocked files"Steve French1-52/+4
Revert previous version of patch to incorporate feedback so that we can merge version 3 of the patch instead.w This reverts commit b5efb978469d152c2c7c0a09746fb0bfc6171868.
2012-04-01cifs: writing past end of struct in cifs_convert_address()Dan Carpenter1-2/+1
"s6->sin6_scope_id" is an int bits but strict_strtoul() writes a long so this can corrupt memory on 64 bit systems. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
2012-04-01cifs: silence compiler warnings showing up with gcc-4.7.0Jeff Layton1-12/+12
gcc-4.7.0 has started throwing these warnings when building cifs.ko. CC [M] fs/cifs/cifssmb.o fs/cifs/cifssmb.c: In function ‘CIFSSMBSetCIFSACL’: fs/cifs/cifssmb.c:3905:9: warning: array subscript is above array bounds [-Warray-bounds] fs/cifs/cifssmb.c: In function ‘CIFSSMBSetFileInfo’: fs/cifs/cifssmb.c:5711:8: warning: array subscript is above array bounds [-Warray-bounds] fs/cifs/cifssmb.c: In function ‘CIFSSMBUnixSetFileInfo’: fs/cifs/cifssmb.c:6001:25: warning: array subscript is above array bounds [-Warray-bounds] This patch cleans up the code a bit by using the offsetof macro instead of the funky "&pSMB->hdr.Protocol" construct. Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
2012-04-01CIFS: Fix VFS lock usage for oplocked filesPavel Shilovsky1-4/+52
We can deadlock if we have a write oplock and two processes use the same file handle. In this case the first process can't unlock its lock if another process blocked on the lock in the same time. Fix this by removing lock_mutex protection from waiting on a blocked lock and protect only posix_lock_file call. Cc: stable@kernel.org Signed-off-by: Pavel Shilovsky <piastry@etersoft.ru> Acked-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
2012-03-27[CIFS] Update CIFS version number to 1.77Steve French1-1/+1
Signed-off-by: Steve French <sfrench@us.ibm.com>
2012-03-27CIFS: Add missed forcemand mount optionPavel Shilovsky1-2/+5
The 'forcemand' form of 'forcemandatorylock' mount option was missed when the code moved to use the standard token parser. Return it back. Also fix a comment style in the parser. Signed-off-by: Pavel Shilovsky <piastry@etersoft.ru> Reviewed-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
2012-03-24[CIFS] Fix trivial sparse warning with asyn i/o patchSteve French1-1/+1
Signed-off-by: Steve French <sfrench@us.ibm.com> Reviewed-by: Jeff Layton <jlayton@redhat.com>
2012-03-23cifs: handle "sloppy" option appropriatelyJeff Layton1-3/+18
cifs.ko has historically been tolerant of options that it does not recognize. This is not normal behavior for a filesystem however. Usually, it should only do this if you mount with '-s', and autofs generally passes -s to the mount command to allow this behavior. This patch makes cifs handle the option "sloppy" appropriately. If it's present in the options string, then the client will tolerate options that it doesn't recognize. If it's not present then the client will error out in the presence of options that it does not recognize and throw an error message explaining why. There is also a companion patch being proposed for mount.cifs to make it append "sloppy" to the mount options when passed the '-s' flag. This also should (obviously) be applied on top of Sachin's conversion to the standard option parser. Signed-off-by: Jeff Layton <jlayton@redhat.com> Acked-By: Sachin Prabhu <sprabhu@redhat.com>
2012-03-23cifs: use standard token parser for mount optionsSachin Prabhu1-524/+814
Use the standard token parser instead of the long if condition to parse cifs mount options. This was first proposed by Scott Lovenberg http://lists.samba.org/archive/linux-cifs-client/2010-May/006079.html Mount options have been grouped together in terms of their input types. Aliases for username, password, domain and credentials have been added. The password parser has been modified to make it easier to read. Since the patch was first proposed, the following bugs have been fixed 1) Allow blank 'pass' option to be passed by the cifs mount helper when using sec=none. 2) Do not explicitly set vol->nullauth to 0. This causes a problem when using sec=none while also using a username. Signed-off-by: Sachin Prabhu <sprabhu@redhat.com> Reviewed-by: Jeff Layton <jlayton@redhat.com>
2012-03-23cifs: remove /proc/fs/cifs/OplockEnabledJeff Layton1-43/+0
We've had a deprecation warning on this file for 2 releases now. Remove it as promised for 3.4. Signed-off-by: Jeff Layton <jlayton@redhat.com>
2012-03-23cifs: convert cifs_iovec_write to use async writesJeff Layton3-86/+143
Signed-off-by: Jeff Layton <jlayton@redhat.com> Reviewed-by: Pavel Shilovsky <piastry@etersoft.ru>
2012-03-23cifs: call cifs_update_eof with i_lock heldJeff Layton3-2/+11
cifs_update_eof has the potential to be racy if multiple threads are trying to modify it at the same time. Protect modifications of the server_eof value with the inode->i_lock. Signed-off-by: Jeff Layton <jlayton@redhat.com>
2012-03-23cifs: abstract out function to marshal up the iovec array for async writesJeff Layton3-10/+31
We'll need to do something a bit different depending on the caller. Abstract the code that marshals the page array into an iovec. Signed-off-by: Jeff Layton <jlayton@redhat.com> Reviewed-by: Pavel Shilovsky <piastry@etersoft.ru>
2012-03-23cifs: fix up get_numpagesJeff Layton1-3/+1
Use DIV_ROUND_UP. Also, PAGE_SIZE is more appropriate here since these aren't pagecache pages. Signed-off-by: Jeff Layton <jlayton@redhat.com> Reviewed-by: Pavel Shilovsky <piastry@etersoft.ru>
2012-03-23cifs: make cifsFileInfo_get return the cifsFileInfo pointerJeff Layton1-1/+3
Signed-off-by: Jeff Layton <jlayton@redhat.com> Reviewed-by: Pavel Shilovsky <piastry@etersoft.ru>
2012-03-23cifs: fix allocation in cifs_write_allocate_pagesJeff Layton1-7/+6
The gfp flags are currently set to __GPF_HIGHMEM, which doesn't allow for any reclaim. Make this more resilient by or'ing that with GFP_KERNEL. Also, get rid of the goto and unify the exit codepath. Signed-off-by: Jeff Layton <jlayton@redhat.com> Acked-by: Pavel Shilovsky <piastry@etersoft.ru>
2012-03-23cifs: allow caller to specify completion op when allocating writedataJeff Layton3-5/+8
We'll need a different set of write completion ops when not writing out of the pagecache. Signed-off-by: Jeff Layton <jlayton@redhat.com> Reviewed-by: Pavel Shilovsky <piastry@etersoft.ru>
2012-03-23cifs: add pid field to cifs_writedataJeff Layton3-2/+4
We'll need this to handle rwpidforward option correctly when we use async writes in the aio_write op. Signed-off-by: Jeff Layton <jlayton@redhat.com> Reviewed-by: Pavel Shilovsky <piastry@etersoft.ru>
2012-03-23cifs: add new cifsiod_wq workqueueJeff Layton5-8/+20
...and convert existing cifs users of system_nrt_wq to use that instead. Also, make it freezable, and set WQ_MEM_RECLAIM since we use it to deal with write reply handling. Signed-off-by: Jeff Layton <jlayton@redhat.com> Acked-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
2012-03-23CIFS: Change mid_q_entry structure fieldsPavel Shilovsky6-59/+59
to be protocol-unspecific and big enough to keep both CIFS and SMB2 values. Signed-off-by: Pavel Shilovsky <piastry@etersoft.ru>
2012-03-23CIFS: Expand CurrentMid fieldPavel Shilovsky3-40/+48
While in CIFS/SMB we have 16 bit mid, in SMB2 it is 64 bit. Convert the existing field to 64 bit and mask off higher bits for CIFS/SMB. Signed-off-by: Pavel Shilovsky <piastry@etersoft.ru>
generated by cgit v1.2.3 (git 2.39.0) at 2024-11-24 00:31:36 +0300