kernel.git/fs/cifs/connect.c, branch linux-3.5.y

cifs: reinstate the forcegid option

2012-10-12T20:47:25Z

commit 72bd481f860f0125c810bb43d878ce5f9c060c58 upstream. Apparently this was lost when we converted to the standard option parser in 8830d7e07a5e38bc47650a7554b7c1cfd49902bf Reported-by: Gregory Lee Bartholomew Cc: Sachin Prabhu Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman

cifs: reinstate sec=ntlmv2 mount option

2012-08-09T15:22:54Z

commit 7659624ffb550d69c87f9af9ae63e717daa874bd upstream. sec=ntlmv2 as a mount option got dropped in the mount option overhaul. Cc: Sachin Prabhu Reported-by: Günter Kukkukk Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman

cifs: on CONFIG_HIGHMEM machines, limit the rsize/wsize to the kmap space

2012-07-17T04:57:09Z

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. Cc: Reported-by: Jian Li Signed-off-by: Jeff Layton Signed-off-by: Steve French

cifs: when server doesn't set CAP_LARGE_READ_X, cap default rsize at MaxBufferSize

2012-07-03T17:54:42Z

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. Cc: # 3.2 Reported-by: David H. Durgee Signed-off-by: Jeff Layton Signed-off-by: Steven French

cifs: fix parsing of password mount option

2012-06-12T17:53:02Z

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 Acked-by: Sachin Prabhu Cc: stable@vger.kernel.org [3.1+] Signed-off-by: Steve French

CIFS: Move get_next_mid to ops struct

2012-06-01T17:35:19Z

Reviewed-by: Jeff Layton Signed-off-by: Pavel Shilovsky Signed-off-by: Steve French

CIFS: Make accessing is_valid_oplock/dump_detail ops struct field safe

2012-06-01T17:35:16Z

Signed-off-by: Pavel Shilovsky Signed-off-by: Steve French

CIFS: Introduce SMB2 mounts as vers=2.1

2012-05-23T08:33:15Z

As with Linux nfs client, which uses "nfsvers=" or "vers=" to indicate which protocol to use for mount, specifying "vers=2.1" will force an SMB2 mount. When vers is not specified CIFS is used "vers=1" We can eventually autonegotiate down from SMB2 to CIFS when SMB2 is stable enough to make it the default, but this is for the future. At that time we could also implement a "maxprotocol" mount option as smbclient and Samba have today, but that would be premature until SMB2 is stable. Intially the SMB2 Kconfig option will depend on "BROKEN" until the merge is complete, and then be "EXPERIMENTAL" When it is no longer experimental we can consider changing the default protocol to attempt first. Signed-off-by: Pavel Shilovsky Signed-off-by: Jeff Layton Acked-by: Shirish Pargaonkar Signed-off-by: Steve French

CIFS: Move add/set_credits and get_credits_field to ops structure

2012-05-23T08:33:12Z

Acked-by: Shirish Pargaonkar Reviewed-by: Jeff Layton Signed-off-by: Pavel Shilovsky Signed-off-by: Steve French

CIFS: Move protocol specific demultiplex thread calls to ops struct

2012-05-23T08:33:11Z

Acked-by: Shirish Pargaonkar Signed-off-by: Pavel Shilovsky Signed-off-by: Steve French