On Wed, Nov 7, 2012 at 10:48 AM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > On Wed, 07 Nov 2012 16:20:22 +0100 > Federico Sauter <fsauter@xxxxxxxxxxxxxx> wrote: > >> Here the corrected (and tested) version. >> >> Jeff: I agree with you regarding removing the UNC parameter altogether. >> Is there any scenario in which an UNC parameter could differ from the >> specified source parameter? >> >> Regards, >> Fred >> > > I suppose someone could provide their own unc= option that differs from > the device name. At that point, the device name in /proc/mounts (and in > programs like "df") might look like you've mounted one location when in > reality you've mounted another. > > That doesn't seem like a valid use-case to me though. It's probably > best that we discourage such abuse ;). Would this ever be the case when using a DFS mount? I'm not sure how that's handled internally to the kernel (I know Samba doesn't provide support for multiple servers on a DFS root, but Windows does, IIRC). So far as I can tell, in the simple case Samba is a proxy, in the complex case, the share is on another server and the original server is down. Does the kernel use the same device in both cases? > > The tricky part is how to get there from here. The mount helper > provides this option pretty much unconditionally, though it generally > generates it from the device string. Maybe something like this? > > 1) fix the kernel to parse a copy of the UNC out of the device string > > 2) compare that UNC to the one provided by the unc= option > > 3) if they differ, then printk a warning that mentions that there is a > discrepancy and that the kernel is going to use the value of the unc= > option for now, but that we'll change that default in two releases. > > Something like: > > "CIFS VFS: the unc= mount option differs from the device passed in. Using > the value of the unc= option. The kernel will begin preferring the value > in the device string in 3.10!" > > Then, have a patch ready to go for the 3.10 merge window that will make > the kernel start ignoring the value of the unc= option. You might even > be nice and keep the comparison and warning around for a little while, > but switch it to mention that the kernel is going to ignore the value > of the unc= option when there is a discrepancy. > > In another few releases, we can then get rid of the warning and > comparison too. > > Sound reasonable? > Would it be reasonable to deprecate the "UNC" / "path" / "target" options (they all resolve to OPT_UNC from parse_opt_token()) in mount.cifs if the kernel is going to do the heavy lifting? That would break compatibility between mount.cifs and older kernels, though. I guess it doesn't hurt anything to keep passing UNC even if it's not being used, other than users not understanding the unexplained behavior of the kernel deciding what the actual value of UNC is and disregarding their explicit setting of it. After typing that out, it sounds kind of bad. -- Peace and Blessings, -Scott. -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
