GitHub PushEvent at 2014-05-17 10:08:39
Repository: z5smini
Actor: parheliamm
Payload: {"shas":[["ad3d6d91a10f150c036753eaf30a69d8fe1a0686","8dcb73d3151da6cb1ccc5cb471442932e4b77796@codeaurora.org","msm: mdp: Update sync pt. behaviour\n\nAdd a retire fence and clean up the existing release fence\nimplementation\n\nSigned-off-by: Naseer Ahmed <naseer@codeaurora.org>","naseer",true],["e513e02db053d81166749ebc94cde25cd4c0dfb4","a054b3e50100c3c57432475f65c6e22f189f7975@gmail.com","cifs: Include backup intent search flags during searches {try #2)\n\ncommit 2608bee744a92d60d15ff4e6e0b913d8b406aedd upstream.\n\nAs observed and suggested by Tushar Gosavi...\n\n---------\nreaddir calls these function to send TRANS2_FIND_FIRST and\nTRANS2_FIND_NEXT command to the server. The current cifs module is\nnot specifying CIFS_SEARCH_BACKUP_SEARCH flag while sending these\ncommand when backupuid/backupgid is specified. This can be resolved\nby specifying CIFS_SEARCH_BACKUP_SEARCH flag.\n---------\n\nReported-and-Tested-by: Tushar Gosavi <tugosavi@in.ibm.com>\nSigned-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>\nAcked-by: Jeff Layton <jlayton@redhat.com>\nSigned-off-by: Steve French <sfrench@us.ibm.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Shirish Pargaonkar",true],["f2527d40b8d61f8635aa0bfd0e6c58cca1a70b53","a054b3e50100c3c57432475f65c6e22f189f7975@gmail.com","cifs: fix oops while traversing open file list (try #4)\n\ncommit 2c0c2a08bed7a3b791f88d09d16ace56acb3dd98 upstream.\n\nWhile traversing the linked list of open file handles, if the identfied\nfile handle is invalid, a reopen is attempted and if it fails, we\nresume traversing where we stopped and cifs can oops while accessing\ninvalid next element, for list might have changed.\n\nSo mark the invalid file handle and attempt reopen if no\nvalid file handle is found in rest of the list.\nIf reopen fails, move the invalid file handle to the end of the list\nand start traversing the list again from the begining.\nRepeat this four times before giving up and returning an error if\nfile reopen keeps failing.\n\nSigned-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>\nReviewed-by: Jeff Layton <jlayton@redhat.com>\nSigned-off-by: Steve French <sfrench@us.ibm.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Shirish Pargaonkar",true],["93d0a643c6e7bf83e7b4bbbf612a4548aa52f528","f409583cd9cda60cf3706d325fdb8cfd1551a59d@suse.com","cifs: fix parsing of password mount option\n\ncommit e73f843a3235a19de38359c91586e9eadef12238 upstream.\n\nThe double delimiter check that allows a comma in the password parsing code is\nunconditional. We set \"tmp_end\" to the end of the string and we continue to\ncheck for double delimiter. In the case where the password doesn't contain a\ncomma we end up setting tmp_end to NULL and eventually setting \"options\" to\n\"end\". This results in the premature termination of the options string and hence\nthe values of UNCip and UNC are being set to NULL. This results in mount failure\nwith \"Connecting to DFS root not implemented yet\" error.\n\nThis error is usually not noticable as we have password as the last option in\nthe superblock mountdata. But when we call expand_dfs_referral() from\ncifs_mount() and try to compose mount options for the submount, the resulting\nmountdata will be of the form\n\n   \",ver=1,user=foo,pass=bar,ip=x.x.x.x,unc=\\\\server\\share\"\n\nand hence results in the above error. This bug has been seen with older NAS\nservers running Samba 3.0.24.\n\nFix this by moving the double delimiter check inside the conditional loop.\n\nChanges since -v1\n\n   - removed the wrong strlen() micro optimization.\n\nSigned-off-by: Suresh Jayaraman <sjayaraman@suse.com>\nAcked-by: Sachin Prabhu <sprabhu@redhat.com>\nSigned-off-by: Steve French <sfrench@us.ibm.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Suresh Jayaraman",true],["ff88a16b205b90506833cd9c1bc4e750926be814","4376fbf8623cd7b7c0232225289bb91cedc0a27f@redhat.com","cifs: when server doesn't set CAP_LARGE_READ_X, cap default rsize at MaxBufferSize\n\ncommit ec01d738a1691dfc85b96b9f796020267a7be577 upstream.\n\nWhen the server doesn't advertise CAP_LARGE_READ_X, then MS-CIFS states\nthat you must cap the size of the read at the client's MaxBufferSize.\nUnfortunately, testing with many older servers shows that they often\ncan't service a read larger than their own MaxBufferSize.\n\nSince we can't assume what the server will do in this situation, we must\nbe conservative here for the default. When the server can't do large\nreads, then assume that it can't satisfy any read larger than its\nMaxBufferSize either.\n\nLuckily almost all modern servers can do large reads, so this won't\naffect them. This is really just for older win9x and OS/2 era servers.\nAlso, note that this patch just governs the default rsize. The admin can\nalways override this if he so chooses.\n\nReported-by: David H. Durgee <dhdurgee@acm.org>\nSigned-off-by: Jeff Layton <jlayton@redhat.com>\nSigned-off-by: Steven French <sfrench@w500smf.none>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Jeff Layton",true],["e7adc50bfc14b52ed1531af36c1260dbcf403e59","4376fbf8623cd7b7c0232225289bb91cedc0a27f@redhat.com","cifs: always update the inode cache with the results from a FIND_*\n\ncommit cd60042cc1392e79410dc8de9e9c1abb38a29e57 upstream.\n\nWhen we get back a FIND_FIRST/NEXT result, we have some info about the\ndentry that we use to instantiate a new inode. We were ignoring and\ndiscarding that info when we had an existing dentry in the cache.\n\nFix this by updating the inode in place when we find an existing dentry\nand the uniqueid is the same.\n\nReported-and-Tested-by: Andrew Bartlett <abartlet@samba.org>\nReported-by: Bill Robertson <bill_robertson@debortoli.com.au>\nReported-by: Dion Edwards <dion_edwards@debortoli.com.au>\nSigned-off-by: Jeff Layton <jlayton@redhat.com>\nSigned-off-by: Steve French <smfrench@gmail.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Jeff Layton",true],["c018301f30d2087ce2c0e2f62add396bc85f39b1","4376fbf8623cd7b7c0232225289bb91cedc0a27f@redhat.com","cifs: on CONFIG_HIGHMEM machines, limit the rsize/wsize to the kmap space\n\ncommit 3ae629d98bd5ed77585a878566f04f310adbc591 upstream.\n\nWe currently rely on being able to kmap all of the pages in an async\nread or write request. If you're on a machine that has CONFIG_HIGHMEM\nset then that kmap space is limited, sometimes to as low as 512 slots.\n\nWith 512 slots, we can only support up to a 2M r/wsize, and that's\nassuming that we can get our greedy little hands on all of them. There\nare other users however, so it's possible we'll end up stuck with a\nsize that large.\n\nSince we can't handle a rsize or wsize larger than that currently, cap\nthose options at the number of kmap slots we have. We could consider\ncapping it even lower, but we currently default to a max of 1M. Might as\nwell allow those luddites on 32 bit arches enough rope to hang\nthemselves.\n\nA more robust fix would be to teach the send and receive routines how\nto contend with an array of pages so we don't need to marshal up a kvec\narray at all. That's a fairly significant overhaul though, so we'll need\nthis limit in place until that's ready.\n\nReported-by: Jian Li <jiali@redhat.com>\nSigned-off-by: Jeff Layton <jlayton@redhat.com>\nSigned-off-by: Steve French <smfrench@gmail.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Jeff Layton",true],["e991cdf3a0ff1fd98b2eeb1fe128eb7591372f34","4376fbf8623cd7b7c0232225289bb91cedc0a27f@redhat.com","cifs: when CONFIG_HIGHMEM is set, serialize the read/write kmaps\n\ncommit 3cf003c08be785af4bee9ac05891a15bcbff856a upstream.\n\n[The async read code was broadened to include uncached reads in 3.5, so\nthe mainline patch did not apply directly. This patch is just a backport\nto account for that change.]\n\nJian found that when he ran fsx on a 32 bit arch with a large wsize the\nprocess and one of the bdi writeback kthreads would sometimes deadlock\nwith a stack trace like this:\n\ncrash> bt\nPID: 2789   TASK: f02edaa0  CPU: 3   COMMAND: \"fsx\"\n #0 [eed63cbc] schedule at c083c5b3\n #1 [eed63d80] kmap_high at c0500ec8\n #2 [eed63db0] cifs_async_writev at f7fabcd7 [cifs]\n #3 [eed63df0] cifs_writepages at f7fb7f5c [cifs]\n #4 [eed63e50] do_writepages at c04f3e32\n #5 [eed63e54] __filemap_fdatawrite_range at c04e152a\n #6 [eed63ea4] filemap_fdatawrite at c04e1b3e\n #7 [eed63eb4] cifs_file_aio_write at f7fa111a [cifs]\n #8 [eed63ecc] do_sync_write at c052d202\n #9 [eed63f74] vfs_write at c052d4ee\n#10 [eed63f94] sys_write at c052df4c\n#11 [eed63fb0] ia32_sysenter_target at c0409a98\n    EAX: 00000004  EBX: 00000003  ECX: abd73b73  EDX: 012a65c6\n    DS:  007b      ESI: 012a65c6  ES:  007b      EDI: 00000000\n    SS:  007b      ESP: bf8db178  EBP: bf8db1f8  GS:  0033\n    CS:  0073      EIP: 40000424  ERR: 00000004  EFLAGS: 00000246\n\nEach task would kmap part of its address array before getting stuck, but\nnot enough to actually issue the write.\n\nThis patch fixes this by serializing the marshal_iov operations for\nasync reads and writes. The idea here is to ensure that cifs\naggressively tries to populate a request before attempting to fulfill\nanother one. As soon as all of the pages are kmapped for a request, then\nwe can unlock and allow another one to proceed.\n\nThere's no need to do this serialization on non-CONFIG_HIGHMEM arches\nhowever, so optimize all of this out when CONFIG_HIGHMEM isn't set.\n\nReported-by: Jian Li <jiali@redhat.com>\nSigned-off-by: Jeff Layton <jlayton@redhat.com>\nSigned-off-by: Steve French <smfrench@gmail.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Jeff Layton",true],["af0e0db5a5e4e87b6e4d64cb018bb0a23ba3fd8e","4376fbf8623cd7b7c0232225289bb91cedc0a27f@redhat.com","cifs: reinstate sec=ntlmv2 mount option\n\ncommit 7659624ffb550d69c87f9af9ae63e717daa874bd upstream.\n\nsec=ntlmv2 as a mount option got dropped in the mount option overhaul.\n\nCc: Sachin Prabhu <sprabhu@redhat.com>\nReported-by: Günter Kukkukk <linux@kukkukk.com>\nSigned-off-by: Jeff Layton <jlayton@redhat.com>\nSigned-off-by: Steve French <smfrench@gmail.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Jeff Layton",true],["a28470ffec3fa4426699be458f8263d56f273ab3","4376fbf8623cd7b7c0232225289bb91cedc0a27f@redhat.com","cifs: fix return value in cifsConvertToUTF16\n\ncommit c73f693989d7a7d99ec66a7065295a0c93d0b127 upstream.\n\nThis function returns the wrong value, which causes the callers to get\nthe length of the resulting pathname wrong when it contains non-ASCII\ncharacters.\n\nThis seems to fix https://bugzilla.samba.org/show_bug.cgi?id=6767\n\nReported-by: Baldvin Kovacs <baldvin.kovacs@gmail.com>\nReported-and-Tested-by: Nicolas Lefebvre <nico.lefebvre@gmail.com>\nSigned-off-by: Jeff Layton <jlayton@redhat.com>\nSigned-off-by: Steve French <smfrench@gmail.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Jeff Layton",true],["08cd7d666e046315c6ee9e24bb93b6830301d420","4376fbf8623cd7b7c0232225289bb91cedc0a27f@redhat.com","cifs: reinstate the forcegid option\n\ncommit 72bd481f860f0125c810bb43d878ce5f9c060c58 upstream.\n\nApparently this was lost when we converted to the standard option\nparser in 8830d7e07a5e38bc47650a7554b7c1cfd49902bf\n\nReported-by: Gregory Lee Bartholomew <gregory.lee.bartholomew@gmail.com>\nCc: Sachin Prabhu <sprabhu@redhat.com>\nSigned-off-by: Jeff Layton <jlayton@redhat.com>\nSigned-off-by: Steve French <smfrench@gmail.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Jeff Layton",true],["eef6c4aa783131da0c42d6064604bd319161f50f","4376fbf8623cd7b7c0232225289bb91cedc0a27f@redhat.com","cifs: fix potential buffer overrun in cifs.idmap handling code\n\ncommit 36960e440ccf94349c09fb944930d3bfe4bc473f upstream.\n\nThe userspace cifs.idmap program generally works with the wbclient libs\nto generate binary SIDs in userspace. That program defines the struct\nthat holds these values as having a max of 15 subauthorities. The kernel\nidmapping code however limits that value to 5.\n\nWhen the kernel copies those values around though, it doesn't sanity\ncheck the num_subauths value handed back from userspace or from the\nserver. It's possible therefore for userspace to hand us back a bogus\nnum_subauths value (or one that's valid, but greater than 5) that could\ncause the kernel to walk off the end of the cifs_sid->sub_auths array.\n\nFix this by defining a new routine for copying sids and using that in\nall of the places that copy it. If we end up with a sid that's longer\nthan expected then this approach will just lop off the \"extra\" subauths,\nbut that's basically what the code does today already. Better approaches\nmight be to fix this code to reject SIDs with >5 subauths, or fix it\nto handle the subauths array dynamically.\n\nAt the same time, change the kernel to check the length of the data\nreturned by userspace. If it's shorter than struct cifs_sid, reject it\nand return -EIO. If that happens we'll end up with fields that are\nbasically uninitialized.\n\nLong term, it might make sense to redefine cifs_sid using a flexarray at\nthe end, to allow for variable-length subauth lists, and teach the code\nto handle the case where the subauths array being passed in from\nuserspace is shorter than 5 elements.\n\nNote too, that I don't consider this a security issue since you'd need\na compromised cifs.idmap program. If you have that, you can do all sorts\nof nefarious stuff. Still, this is probably reasonable for stable.\n\nReviewed-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>\nSigned-off-by: Jeff Layton <jlayton@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Jeff Layton",true],["9dd4b73ebf0e2123754c7664d29a217a6d15f7ed","8001b54ad539330acc19ca3e17ac1f04f07b36a6@gmail.com","fs/cifs/cifs_dfs_ref.c: fix potential memory leakage\n\ncommit 10b8c7dff5d3633b69e77f57d404dab54ead3787 upstream.\n\nWhen it goes to error through line 144, the memory allocated to *devname is\nnot freed, and the caller doesn't free it either in line 250. So we free the\nmemroy of *devname in function cifs_compose_mount_options() when it goes to\nerror.\n\nSigned-off-by: Cong Ding <dinggnu@gmail.com>\nReviewed-by: Jeff Layton <jlayton@redhat.com>\nSigned-off-by: Steve French <smfrench@gmail.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Cong Ding",true],["88d8d8d997ff52e6f4aaf7a9c60882d321c0d888","4376fbf8623cd7b7c0232225289bb91cedc0a27f@redhat.com","cifs: ensure that cifs_get_root() only traverses directories\n\ncommit ce2ac52105aa663056dfc17966ebed1bf93e6e64 upstream.\n\nKjell Braden reported this oops:\n\n[  833.211970] BUG: unable to handle kernel NULL pointer dereference at           (null)\n[  833.212816] IP: [<          (null)>]           (null)\n[  833.213280] PGD 1b9b2067 PUD e9f7067 PMD 0\n[  833.213874] Oops: 0010 [#1] SMP\n[  833.214344] CPU 0\n[  833.214458] Modules linked in: des_generic md4 nls_utf8 cifs vboxvideo drm snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq bnep rfcomm snd_timer bluetooth snd_seq_device ppdev snd vboxguest parport_pc joydev mac_hid soundcore snd_page_alloc psmouse i2c_piix4 serio_raw lp parport usbhid hid e1000\n[  833.215629]\n[  833.215629] Pid: 1752, comm: mount.cifs Not tainted 3.0.0-rc7-bisectcifs-fec11dd9a0+ #18 innotek GmbH VirtualBox/VirtualBox\n[  833.215629] RIP: 0010:[<0000000000000000>]  [<          (null)>]           (null)\n[  833.215629] RSP: 0018:ffff8800119c9c50  EFLAGS: 00010282\n[  833.215629] RAX: ffffffffa02186c0 RBX: ffff88000c427780 RCX: 0000000000000000\n[  833.215629] RDX: 0000000000000000 RSI: ffff88000c427780 RDI: ffff88000c4362e8\n[  833.215629] RBP: ffff8800119c9c88 R08: ffff88001fc15e30 R09: 00000000d69515c7\n[  833.215629] R10: ffffffffa0201972 R11: ffff88000e8f6a28 R12: ffff88000c4362e8\n[  833.215629] R13: 0000000000000000 R14: 0000000000000000 R15: ffff88001181aaa6\n[  833.215629] FS:  00007f2986171700(0000) GS:ffff88001fc00000(0000) knlGS:0000000000000000\n[  833.215629] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b\n[  833.215629] CR2: 0000000000000000 CR3: 000000001b982000 CR4: 00000000000006f0\n[  833.215629] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[  833.215629] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400\n[  833.215629] Process mount.cifs (pid: 1752, threadinfo ffff8800119c8000, task ffff88001c1c16f0)\n[  833.215629] Stack:\n[  833.215629]  ffffffff8116a9b5 ffff8800119c9c88 ffffffff81178075 0000000000000286\n[  833.215629]  0000000000000000 ffff88000c4276c0 ffff8800119c9ce8 ffff8800119c9cc8\n[  833.215629]  ffffffff8116b06e ffff88001bc6fc00 ffff88000c4276c0 ffff88000c4276c0\n[  833.215629] Call Trace:\n[  833.215629]  [<ffffffff8116a9b5>] ? d_alloc_and_lookup+0x45/0x90\n[  833.215629]  [<ffffffff81178075>] ? d_lookup+0x35/0x60\n[  833.215629]  [<ffffffff8116b06e>] __lookup_hash.part.14+0x9e/0xc0\n[  833.215629]  [<ffffffff8116b1d6>] lookup_one_len+0x146/0x1e0\n[  833.215629]  [<ffffffff815e4f7e>] ? _raw_spin_lock+0xe/0x20\n[  833.215629]  [<ffffffffa01eef0d>] cifs_do_mount+0x26d/0x500 [cifs]\n[  833.215629]  [<ffffffff81163bd3>] mount_fs+0x43/0x1b0\n[  833.215629]  [<ffffffff8117d41a>] vfs_kern_mount+0x6a/0xd0\n[  833.215629]  [<ffffffff8117e584>] do_kern_mount+0x54/0x110\n[  833.215629]  [<ffffffff8117fdc2>] do_mount+0x262/0x840\n[  833.215629]  [<ffffffff81108a0e>] ? __get_free_pages+0xe/0x50\n[  833.215629]  [<ffffffff8117f9ca>] ? copy_mount_options+0x3a/0x180\n[  833.215629]  [<ffffffff8118075d>] sys_mount+0x8d/0xe0\n[  833.215629]  [<ffffffff815ece82>] system_call_fastpath+0x16/0x1b\n[  833.215629] Code:  Bad RIP value.\n[  833.215629] RIP  [<          (null)>]           (null)\n[  833.215629]  RSP <ffff8800119c9c50>\n[  833.215629] CR2: 0000000000000000\n[  833.238525] ---[ end trace ec00758b8d44f529 ]---\n\nWhen walking down the path on the server, it's possible to hit a\nsymlink. The path walking code assumes that the caller will handle that\nsituation properly, but cifs_get_root() isn't set up for it. This patch\nprevents the oops by simply returning an error.\n\nA better solution would be to try and chase the symlinks here, but that's\nfairly complicated to handle.\n\nFixes:\n\n    https://bugzilla.kernel.org/show_bug.cgi?id=53221\n\nReported-and-tested-by: Kjell Braden <afflux@pentabarf.de>\nSigned-off-by: Jeff Layton <jlayton@redhat.com>\nSigned-off-by: Steve French <sfrench@us.ibm.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Jeff Layton",true],["a566d06eea21349c610aaa7bc89d217659791669","4376fbf8623cd7b7c0232225289bb91cedc0a27f@redhat.com","cifs: ignore everything in SPNEGO blob after mechTypes\n\ncommit f853c616883a8de966873a1dab283f1369e275a1 upstream.\n\nWe've had several reports of people attempting to mount Windows 8 shares\nand getting failures with a return code of -EINVAL. The default sec=\nmode changed recently to sec=ntlmssp. With that, we expect and parse a\nSPNEGO blob from the server in the NEGOTIATE reply.\n\nThe current decode_negTokenInit function first parses all of the\nmechTypes and then tries to parse the rest of the negTokenInit reply.\nThe parser however currently expects a mechListMIC or nothing to follow the\nmechTypes, but Windows 8 puts a mechToken field there instead to carry\nsome info for the new NegoEx stuff.\n\nIn practice, we don't do anything with the fields after the mechTypes\nanyway so I don't see any real benefit in continuing to parse them.\nThis patch just has the kernel ignore the fields after the mechTypes.\nWe'll probably need to reinstate some of this if we ever want to support\nNegoEx.\n\nReported-by: Jason Burgess <jason@jacknife2.dns2go.com>\nReported-by: Yan Li <elliot.li.tech@gmail.com>\nSigned-off-by: Jeff Layton <jlayton@redhat.com>\nSigned-off-by: Steve French <sfrench@us.ibm.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Jeff Layton",true],["89b172a2cf8d6307957e672d405acf70d200b406","fe031bd268e574c3e649d0fd7ef4a978e9d7c1cd@redhat.com","cifs: Allow passwords which begin with a delimitor\n\ncommit c369c9a4a7c82d33329d869cbaf93304cc7a0c40 upstream.\n\nFixes a regression in cifs_parse_mount_options where a password\nwhich begins with a delimitor is parsed incorrectly as being a blank\npassword.\n\nSigned-off-by: Sachin Prabhu <sprabhu@redhat.com>\nAcked-by: Jeff Layton <jlayton@redhat.com>\nSigned-off-by: Steve French <sfrench@us.ibm.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Sachin Prabhu",true],["a1072aaf8a56580e148f87d1f4d2c0da676283db","4376fbf8623cd7b7c0232225289bb91cedc0a27f@redhat.com","cifs: only set ops for inodes in I_NEW state\n\ncommit c2b93e0699723700f886ce17bb65ffd771195a6d upstream.\n\nIt's generally not safe to reset the inode ops once they've been set. In\nthe case where the inode was originally thought to be a directory and\nthen later found to be a DFS referral, this can lead to an oops when we\ntry to trigger an inode op on it after changing the ops to the blank\nreferral operations.\n\nReported-and-Tested-by: Sachin Prabhu <sprabhu@redhat.com>\nSigned-off-by: Jeff Layton <jlayton@redhat.com>\nSigned-off-by: Steve French <smfrench@gmail.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Jeff Layton",true],["5e339a190460be00386a661192f6b141aa806e3b","4376fbf8623cd7b7c0232225289bb91cedc0a27f@redhat.com","cifs: fix potential buffer overrun when composing a new options string\n\ncommit 166faf21bd14bc5c5295a44874bf7f3930c30b20 upstream.\n\nConsider the case where we have a very short ip= string in the original\nmount options, and when we chase a referral we end up with a very long\nIPv6 address. Be sure to allow for that possibility when estimating the\nsize of the string to allocate.\n\nSigned-off-by: Jeff Layton <jlayton@redhat.com>\nSigned-off-by: Steve French <sfrench@us.ibm.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Jeff Layton",true],["5db7a4e3c179652284528699d16cdb7ab7920617","51565b4e5841e493fd669866e11ea3c7c0d781cc@gmail.com","CIFS use sensible file nlink values if unprovided\n\ncommit 6658b9f70ebca5fc0795b1d6d733996af1e2caa7 upstream.\n\nCertain servers may not set the NumberOfLinks field in query file/path\ninfo responses. In such a case, cifs_inode_needs_reval() assumes that\nall regular files are hardlinks and triggers revalidation, leading to\nexcessive and unnecessary network traffic.\n\nThis change hardcodes cf_nlink (and subsequently i_nlink) when not\nreturned by the server, similar to what already occurs in cifs_mkdir().\n\nSigned-off-by: David Disseldorp <ddiss@suse.de>\nSigned-off-by: Steve French <smfrench@gmail.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Steve French",true],["bec2d0455d21c826b4959b54cee8eec8c989f316","a683964d4489dfcd1de21d1566170b1d560c877b@asianux.com","cifs: extend the buffer length enought for sprintf() using\n\ncommit 057d6332b24a4497c55a761c83c823eed9e3f23b upstream.\n\nFor cifs_set_cifscreds() in \"fs/cifs/connect.c\", 'desc' buffer length\nis 'CIFSCREDS_DESC_SIZE' (56 is less than 256), and 'ses->domainName'\nlength may be \"255 + '\\0'\".\n\nThe related sprintf() may cause memory overflow, so need extend related\nbuffer enough to hold all things.\n\nIt is also necessary to be sure of 'ses->domainName' must be less than\n256, and define the related macro instead of hard code number '256'.\n\nSigned-off-by: Chen Gang <gang.chen@asianux.com>\nReviewed-by: Jeff Layton <jlayton@redhat.com>\nReviewed-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>\nReviewed-by: Scott Lovenberg <scott.lovenberg@gmail.com>\nSigned-off-by: Steve French <smfrench@gmail.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Chen Gang",true]],"size":81,"ref":"refs/heads/cm-11.0-V10c","head":"9c5242e7861e4d32bea55a499679f72cea09d1c1"}