Re: ichwd0: unable to reserve GCS registers
on 19/07/2011 18:16 John Baldwin said the following: > Hmm, can you get devinfo -r output from a working kernel with ichwd loaded? > You might be able to just build the kernel with 'nooptions NEW_PCIB'. I believe that I've got a similar problem with amdsbwd(4). It needs some resources (I/O ports) that belong to ACPI. The problem is that the driver attaches to isa bus which is under isab->pci->pcib and those particular resources are not assigned to the Host-PCI bridge. I think that you already made a suggestion that perhaps isa bus should directly attach to acpi bus when acpi is available. Not sure if there are any alternative approaches. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] updated /etc/rc.d/jail and added ZFS support
So what do you think about this updated patch (attached)?
Here we leave everything possible for jail_example_params.
Btw. you can also set jid=xxx in params to have a "static" jail id for
this jail.
Also stopping a persistent jail doesn't delete it (but you cannot start
it again).
Dňa 28. 7. 2011 20:47, Jamie Gritton wrote / napísal(a):
> Yes, it was intentional to move away from the global sysctls and to
> the per-jail parameters instead. It makes more sense once config
> files come into play, which can do a better job of providing global
> defaults as well as per-jail parameters.
>
> The connection between ZFS and persist makes sense. So for ZFS-based
> jail you'd want to set (and then reset) persist. For others, this
> could be left to the user. The changes to jail(8) for config files
> also sets persist when creating jails, and then clears it at a later
> stage unless the user specifies to keep it set. It looks like I might
> want to add some ZFS support to the new jail(8).
>
> I would prefer to keep things simpler regarding create/start and
> remove/stop, and keep them tied together.
>
> - Jamie
>
>
> On 07/28/11 12:00, Martin Matuska wrote:
>> If you start jail(8) witth "-c" (the new "param" way,) the values of the
>> actual security.jail. variables are not initialized inside the jail,
>> default values are used instead. I don't know if this is intentional,
>> but probably yes. Default enforce_statfs=2, allow.mount=0.
>> As of me we can leave everything for ${_params}, but then ${_zfs} makes
>> sense only if enforce_statfs<2 and allow.mount=1.
>>
>> Regarding zfs, if you want to operate zfs from the very start of a jail
>> (and e.g. make use of /etc/rc.d/zfs which has jail support), you have to
>> pair datasets with an existing jail. In simple words, you have to create
>> a process-less jail (persist=1), attach zfs datasets and then run the
>> command. The persist option can be made optional - but we always start
>> with persist=1, then we can set (or not) persist=0 depending on user
>> setting.
>>
>> The question that opens, should we remove a persisting jail on "stop"?
>> Or should we support new commands "create" and "remove" in addition to
>> "start" and "stop"? Create would just make a processless jail, remove
>> would wipe out a jail and start/stop would just deal with the processes
>> (if persist=0 the old way, of course)?
>>
>> Cheers,
>> mm
>>
>> Dňa 28. 7. 2011 18:25, Jamie Gritton wrote / napísal(a):
>>> Since I missed the 9.0 boat with jail config file capability, something
>>> like this seems necessary; rc.d/jail has long been unable to handle the
>>> full scale of what jail(8) can do.
>>>
>>> I gather that setting persist is necessary for the ZFS operation. As
>>> long as we're making the parameter setting more generic from rc, we
>>> should handle the case where persist is specified in ${_params}, and
>>> not
>>> always set/reset it around the jail creation unless ZFS is used.
>>>
>>> Also, why the specific inclusion of the security-related parameters?
>>> They could just be folded into ${_params}, and if left unspecified then
>>> jail(8) should by default do the right thing.
>>>
>>> - Jamie
>>>
>>>
>>> On 07/28/11 08:11, Martin Matuska wrote:
The attached patch allows better fine-tuning of jails started via
/etc/rc.d, uses the new jail(8) flags (-c -m), the persist
parameter and
adds ZFS support.
Patch is fully backward compatible.
Please review, comment and/or test my attached patch.
Cheers,
mm
--
Martin Matuska
FreeBSD committer
http://blog.vx.sk
Index: etc/rc.d/jail
===
--- etc/rc.d/jail (revision 224494)
+++ etc/rc.d/jail (working copy)
@@ -43,6 +43,9 @@
eval _ip=\"\$jail_${_j}_ip\"
eval _interface=\"\${jail_${_j}_interface:-${jail_interface}}\"
eval _exec=\"\$jail_${_j}_exec\"
+ eval _params=\"\$jail_${_j}_params\"
+ eval _persist=\"\$jail_${_j}_persist\"
+ eval _zfs=\"\${jail_${_j}_zfs:-}\"
i=0
while : ; do
@@ -98,6 +101,9 @@
fi
# The default jail ruleset will be used by rc.subr if none is specified.
+ if [ -n "jail_devfs_ruleset" -a -n "_zfs" ]; then
+ jail_devfs_ruleset="devfsrules_jail_zfs"
+ fi
eval _ruleset=\"\${jail_${_j}_devfs_ruleset:-${jail_devfs_ruleset}}\"
eval _devfs=\"\${jail_${_j}_devfs_enable:-${jail_devfs_enable}}\"
[ -z "${_devfs}" ] && _devfs="NO"
@@ -345,6 +351,36 @@
mount -a -F "${_fstab}"
}
+# jail_zfs_jailin
+# Make zfs datasets manageable from inside a jail
+# the "jailed" dataset property must be set to "on"
+jail_zfs_jailin()
+{
+ if [ -n "${_zfs}" ]; then
+ for _ds in ${_zfs}; do
+ _jailed=`zfs get -H jailed ${_ds} 2>/dev/null | awk '{
print $3 }'`
+ if [ "$_jailed" = "on" ]; then
+
[PATCH] Updated jail mount/unmount patch
After implementing a suggestion from pjd@, a new version of the patch is
attached, now using a more universal solution - vn_fullpath_global() in
the mount part.
Dňa 28. 7. 2011 16:59, Martin Matuska wrote / napísal(a):
> Please review my attached patch.
>
> The patch fixes f_mntonname with mount/unmount inside a jail with allow.mount
> enabled.
> Filesystems mountable in a jail require the VFCF_JAIL flag (currently only
> ZFS).
>
> With this patch, mount and unmount works both with enforce_statfs = 0 and
> enforce_statfs = 1.
> I suggest disabling mount/unmount for jails with enforce_statfs = 2, as this
> is contradictory and does not play well with or without this patch.
>
> I have successfully tested this patch with ZFS, nullfs and tmpfs.
>
> To enable nullfs for a jail, you have to modify tmpfs/tmpfs_vfsops.c and
> recompile the tmpfs module:
> -VFS_SET(tmpfs_vfsops, tmpfs, 0);
> +VFS_SET(tmpfs_vfsops, tmpfs, VFCF_JAIL);
>
> To enable tmpfs for a jail, you have to modify nullfs/null_vfsops.c and
> recompile the nullfs module:
> -VFS_SET(null_vfsops, nullfs, VFCF_LOOPBACK);
> +VFS_SET(null_vfsops, nullfs, VFCF_LOOPBACK | VFCF_JAIL);
>
> The filesystems can be successfully mounted/unmounted inside a jail and also
> unmounted from the parent host without problems.
>
> The mount inside jail, a jail needs allow.mount=1 and enforce.statfs=0 or
> enforce.statfs=1, for more information see jail(8)
> I assume other filesystem not dealing with devices may work correctly with
> this patch, too (e.g. nfs).
>
> With jailed nullfs we can run tinderbox in a jail ;)
>
> Please review, comment and/or test my attached patch.
>
> Cheers,
> mm
--
Martin Matuska
FreeBSD committer
http://blog.vx.sk
Index: sys/kern/kern_jail.c
===
--- sys/kern/kern_jail.c(revision 224471)
+++ sys/kern/kern_jail.c(working copy)
@@ -3858,7 +3858,8 @@
case PRIV_VFS_UNMOUNT:
case PRIV_VFS_MOUNT_NONUSER:
case PRIV_VFS_MOUNT_OWNER:
- if (cred->cr_prison->pr_allow & PR_ALLOW_MOUNT)
+ if (cred->cr_prison->pr_allow & PR_ALLOW_MOUNT &&
+ cred->cr_prison->pr_enforce_statfs != 2)
return (0);
else
return (EPERM);
Index: sys/kern/vfs_mount.c
===
--- sys/kern/vfs_mount.c(revision 224471)
+++ sys/kern/vfs_mount.c(working copy)
@@ -745,7 +745,6 @@
vfs_domount_first(
struct thread *td, /* Calling thread. */
struct vfsconf *vfsp, /* File system type. */
- char *fspath, /* Mount path. */
struct vnode *vp, /* Vnode to be covered. */
int fsflags,/* Flags common to all filesystems. */
struct vfsoptlist **optlist /* Options local to the filesystem. */
@@ -755,11 +754,23 @@
struct mount *mp;
struct vnode *newdp;
int error;
+ char *fspath, *fbuf;
mtx_assert(&Giant, MA_OWNED);
ASSERT_VOP_ELOCKED(vp, __func__);
KASSERT((fsflags & MNT_UPDATE) == 0, ("MNT_UPDATE shouldn't be here"));
+ /* Construct global filesystem path from vp */
+ error = vn_fullpath_global(td, vp, &fspath, &fbuf);
+ if (error == 0 && strlen(fspath) >= MNAMELEN)
+ error = ENAMETOOLONG;
+ if (error != 0) {
+ vput(vp);
+ if (fbuf != NULL)
+ free(fbuf, M_TEMP);
+ return(error);
+ }
+
/*
* If the user is not root, ensure that they own the directory
* onto which we are attempting to mount.
@@ -781,12 +792,14 @@
}
if (error != 0) {
vput(vp);
+ free(fbuf, M_TEMP);
return (error);
}
VOP_UNLOCK(vp, 0);
/* Allocate and initialize the filesystem. */
mp = vfs_mount_alloc(vp, vfsp, fspath, td->td_ucred);
+ free(fbuf, M_TEMP);
/* XXXMAC: pass to vfs_mount_alloc? */
mp->mnt_optnew = *optlist;
/* Set the mount level flags. */
@@ -1070,7 +1083,7 @@
NDFREE(&nd, NDF_ONLY_PNBUF);
vp = nd.ni_vp;
if ((fsflags & MNT_UPDATE) == 0) {
- error = vfs_domount_first(td, vfsp, fspath, vp, fsflags,
+ error = vfs_domount_first(td, vfsp, vp, fsflags,
optlist);
} else {
error = vfs_domount_update(td, vp, fsflags, optlist);
@@ -1105,7 +1118,7 @@
} */ *uap;
{
struct mount *mp;
- char *pathbuf;
+ char *pathbuf, *rpathbuf;
int error, id0, id1;
AUDIT_ARG_VALUE(uap->flags);
@@ -1140,12 +1153,27 @@
mtx_unlock(&mountlist_mtx);
} else {
AUDIT_ARG_UPATH1(td, pathbuf);
+ /*
+* If we are jailed and e
Re: some smp documentation fixes for review
On Friday, July 29, 2011 6:08:30 am Andriy Gapon wrote: > > This is to account for the recent changes in x86 SMP code: > http://people.freebsd.org/~avg/hlt_cpus-doc.diff > Please review. Thank you! Looks good to me. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: recovering data from a RAID1 array from a single disk on a different system
Alban Hertroys wrote: > On 28 Jul 2011, at 21:13, Lee Whalen wrote: > > I'm no expert, but I'll add my insights regardless ;) > > > 1. Using CCD or one of the other utilities, I need to add this USB-caged > > disk into a temporary RAID-1 array in a 'degraded' state so FreeBSD sees > > As far as I know, CCD (concatenated disk) can not do mirroring, so > your RAID-1 disk won't be created using CCD. If it's a ccd, just configure a 1 disk mirror using ccdconfig. See ccdconfig(8) for more info. But it sounds like this may be some proprietry RAID format used by the controller in the NAS device. Often the controller doesn't actually do the RAID, so the OP might have some success using ataraid(4) to attach the disks. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
some smp documentation fixes for review
This is to account for the recent changes in x86 SMP code: http://people.freebsd.org/~avg/hlt_cpus-doc.diff Please review. Thank you! -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: recovering data from a RAID1 array from a single disk on a different system
On 28 Jul 2011, at 21:13, Lee Whalen wrote:
I'm no expert, but I'll add my insights regardless ;)
> 1. Using CCD or one of the other utilities, I need to add this USB-caged
> disk into a temporary RAID-1 array in a 'degraded' state so FreeBSD sees
As far as I know, CCD (concatenated disk) can not do mirroring, so your RAID-1
disk won't be created using CCD.
> the disklabels as something other than type "raid". This will allow me
> to mount the preexisting partitions as normal, and copy the data off the
> disk. If there's some way I can positively identify a given
> partition/slice as having been created by either ccd/geom/vinum, that
> would be awesome.
According to the man page, descriptions of the various fs_type's are in
/usr/include/sys/disklabel.h, and indeed:
...
#define FS_RAID 15 /* RAIDFrame drive */
...
static const char *fstypenames[] = {
...
"raid",
...
};
So, apparently your disk contains a "RAIDFrame drive". I never heard of that
before, but apparently it's something that's part of NetBSD:
http://www.netbsd.org/docs/guide/en/chap-rf.html
So my guess is that the NAS device contained NetBSD instead of FreeBSD.
Alban Hertroys
--
The scale of a problem often equals the size of an ego.
!DSPAM:909,4e32752b12094789815349!
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
