[linux-cifs-client] [PATCH] [CIFS] Prevent OOPs when mounting with remote prefixpath

Jeff Layton jlayton at redhat.com
Sun Feb 8 12:18:58 GMT 2009


On Sat, 7 Feb 2009 20:37:42 -0600
Steve French <smfrench at gmail.com> wrote:

> Trying it just now, the patch causes an extra QueryPathInfo on every mount,
> and presumably it can't be cached information since it doesn't use the
> normal Unix vs. Non-Unix Query Path Info check and because we special cause
> the lookup of the root inode.
> 

Good point. Now that I look at this closer, I wonder whether it might be
better to move this check into cifs_iget. Mounting is a pretty slow
codepath anyway so an extra QPathInfo call shouldn't be a big deal.

This patch is probably fine as an interim workaround, but long term, we
really need to consider how best to fix this the right way -- i.e. to
chase the DFS referrals in the mount() call and have it mount the
ultimate target.

The *best* outcome would be to handle this situation something like
this:

1) parse mount options

2) find or set up tcp ses, smb ses, and tcon.

3) QPathInfo call against root inode. If it gets an -EREMOTE, chase
the referral, and plug the right info into the smb_vol that we've
already parsed

4) get new references to tcp_ses/smb_ses/tcon for DFS target. Do
another QPathInfo call. If we get -EREMOTE, redo the setup.
Repeat and keep track of the tcons we get.

5) eventually, when we hit the target we put all of the tcon
references except for the last one, and plug the last tcon into
the superblock.

We'd probably also want to have some sort of check for too many DFS
references (maybe use MAX_NESTED_LINKS) and bail out with -ELOOP or
something if we get too many.

This will require a bit of reorganization/breakup of cifs_mount,
particularly with how option parsing is handled, but it's probably
the best way to handle it.

PS: Steve, you asked about -stable for this. I'm inclined to say
no for stable since this code is still considered experimental.

-- 
Jeff Layton <jlayton at redhat.com>


More information about the linux-cifs-client mailing list