svn commit: r235911 - in head: share/examples/ses share/examples/ses/srcs sys/cam/scsi sys/conf sys/fs/devfs sys/modules/cam usr.bin/kdump

Konstantin Belousov kostikbel at gmail.com
Thu May 24 14:32:41 UTC 2012


On Thu, May 24, 2012 at 02:07:44PM +0000, Alexander Motin wrote:
> Author: mav
> Date: Thu May 24 14:07:44 2012
> New Revision: 235911
> URL: http://svn.freebsd.org/changeset/base/235911
> 
> Log:
>   MFprojects/zfsd:
>   Revamp the CAM enclosure services driver.
>   This updated driver uses an in-kernel daemon to track state changes and
>   publishes physical path location information\for disk elements into the
>   CAM device database.
>   
>   Sponsored by:   Spectra Logic Corporation
>   Sponsored by:   iXsystems, Inc.
>   Submitted by:   gibbs, will, mav
> 
> Added:
>   head/sys/cam/scsi/scsi_enc.c   (contents, props changed)
>   head/sys/cam/scsi/scsi_enc.h   (contents, props changed)
>   head/sys/cam/scsi/scsi_enc_internal.h   (contents, props changed)
>   head/sys/cam/scsi/scsi_enc_safte.c   (contents, props changed)
>   head/sys/cam/scsi/scsi_enc_ses.c   (contents, props changed)
> Deleted:
>   head/sys/cam/scsi/scsi_ses.c
> Modified:
>   head/share/examples/ses/Makefile.inc
>   head/share/examples/ses/srcs/eltsub.c
>   head/share/examples/ses/srcs/getencstat.c
>   head/share/examples/ses/srcs/getnobj.c
>   head/share/examples/ses/srcs/getobjmap.c
>   head/share/examples/ses/srcs/getobjstat.c
>   head/share/examples/ses/srcs/inienc.c
>   head/share/examples/ses/srcs/sesd.c
>   head/share/examples/ses/srcs/setencstat.c
>   head/share/examples/ses/srcs/setobjstat.c
>   head/sys/cam/scsi/scsi_ses.h
>   head/sys/conf/files
>   head/sys/fs/devfs/devfs_vnops.c
>   head/sys/modules/cam/Makefile
>   head/usr.bin/kdump/mkioctls

The devfs change should have been committed separately. Also, I do not
see why devfs should do this to aliases at all. Also, your change only
handles jails and not chroots, why ?


Index: devfs_vnops.c
===================================================================
--- devfs_vnops.c	(revision 235910)
+++ devfs_vnops.c	(revision 235911)
@@ -1266,8 +1266,53 @@ static int
 devfs_readlink(struct vop_readlink_args *ap)
 {
 	struct devfs_dirent *de;
+	struct cdev_priv *cdp;
 
 	de = ap->a_vp->v_data;
+	cdp = de->de_cdp;
+
+	if (cdp != NULL && (cdp->cdp_c.si_flags & SI_ALIAS) != 0) {
+		struct devfs_mount *dmp;
+		struct prison *pr;
+		char *mp;
+		int mp_len;
+		int pr_path_len;
+		int err;
The declarations should be placed at the start of the function, not
at the start of the block.

+
+		/*
+		 * For device aliases, construct an absolute symlink (to
+		 * shorten its length and avoid the ugliness of a relative
+		 * link) by prepending the fully qualified path to the root
+		 * of this devfs.  For a non-jailed process, the devfs root
+		 * is our mount point.  For a jailed process, we must remove
+		 * any jail prefix in our mount point so that our response
+		 * matches the user process's world view.
+		 */
+		dmp = VFSTODEVFS(ap->a_vp->v_mount);
+		mp = dmp->dm_mount->mnt_stat.f_mntonname;
+		mp_len = strlen(mp);
+
+		pr = ap->a_cred->cr_prison;
+		pr_path_len = strlen(pr->pr_path);
+
+		if (strncmp(pr->pr_path, mp, pr_path_len) == 0
+		 && mp[pr_path_len] == '/') {
Style prefers to put '&&' on the first line, and not on the continuation
line.

I suspect that you may access mp past the end of its memory there, no ?

+			mp += pr_path_len;
+			mp_len -= pr_path_len;
+		}
+
+		err = uiomove(mp, mp_len, ap->a_uio);
+		if (err != 0)
+			return (err);
+
+		/*
+		 * Devfs cannot be the root file system, so its
+		 * mount point must always be terminated by a '/'.
+		 */
+		err = uiomove("/", 1, ap->a_uio);
+		if (err != 0)
+			return (err);
+	}
 	return (uiomove(de->de_symlink, strlen(de->de_symlink), ap->a_uio));
 }
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-head/attachments/20120524/85099ea4/attachment.pgp


More information about the svn-src-head mailing list