Re: if_ath - should it be compiled without ath_hal support?
Hi, On 25 August 2011 12:49, Garrett Cooper wrote: > I ran into the panic shown below because it appears that some > array indexing went off into the weeds. I haven't seen this happen but > once though when running a buildworld last night using r225089 on > i386. > This begs the question - is it wise to compile if_ath without > ath_hal support today? I've been doing this recently because ath_hal > isn't available under /sys/modules , and unless I unload the module, > things like suspend and resume don't work because if_ath doesn't > support suspend/resume yet). There are a lot of references to the > ath_hal APIs in if_ath.c now that don't have #ifdefs guarding them as > well which concern me.. Well, the ath_hal code should be built in as part of the ath module. ath needs ath_hal to speak to the MAC/baseband/radio. There's no need for #ifdef's to guard them as .. well, they're needed. I'd like to eventually split out the ath_hal again into a separate module and re-instate the separation between HAL and driver code (primarily to enforce cleaner code and more stable APIs.) If you're seeing issues like the above, chances are that you're seeing some corruption. Can you please print out the whole value of *rs (ie, all the fields of the ath_rx_status struct) so I can see how valid it is? Adrian ___ 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: ath0 no longer attaches, cardbus problems?
On 25 August 2011 08:19, Daniel Eischen wrote: > I have an older Dell 4150 laptop that takes forever to build > world, so I don't update it that often. The last time I > updated it was March 1, 2010. I just updated the system > yesterday and ath0 (a Linksys PCCard) no longer attaches. > > The interesting thing is that ath0 is detected at different > addresses between the working kernel and the non-working > kernel: [snip] Yup, looks like another cardbus/pci allocation issue. :-) Adrian ___ 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"
if_ath - should it be compiled without ath_hal support?
I ran into the panic shown below because it appears that some
array indexing went off into the weeds. I haven't seen this happen but
once though when running a buildworld last night using r225089 on
i386.
This begs the question - is it wise to compile if_ath without
ath_hal support today? I've been doing this recently because ath_hal
isn't available under /sys/modules , and unless I unload the module,
things like suspend and resume don't work because if_ath doesn't
support suspend/resume yet). There are a lot of references to the
ath_hal APIs in if_ath.c now that don't have #ifdefs guarding them as
well which concern me..
TIA!
-Garrett
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0xc5ec97f0
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc0c58968
stack pointer = 0x28:0xd87e2bfc
frame pointer = 0x28:0xd87e2c78
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 0 (ath0 taskq)
Physical memory: 1001 MB
Dumping 103 MB: 88 72 56 40 24 8
...
(kgdb) list
3659m->m_pkthdr.rcvif = ifp;
3660m->m_pkthdr.len = len;
3661}
3662
3663ifp->if_ipackets++;
3664sc->sc_stats.ast_ant_rx[rs->rs_antenna]++;
3665
3666/*
3667 * Populate the rx status block. When there are bpf
3668 * listeners we do the additional work to provide
(kgdb) p sc->sc_stats.ast_ant_rx
$6 = {0, 3458, 0, 0, 0, 0, 0, 0}
(kgdb) p rs->rs_antenna
$7 = 8399232
(kgdb)
___
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"
ath0 no longer attaches, cardbus problems?
Hello, I have an older Dell 4150 laptop that takes forever to build world, so I don't update it that often. The last time I updated it was March 1, 2010. I just updated the system yesterday and ath0 (a Linksys PCCard) no longer attaches. The interesting thing is that ath0 is detected at different addresses between the working kernel and the non-working kernel: March 1, 2010 kernel ath0: mem 0x8800-0x8800 irq 11 at device 0.0 on cardbus0 ath0: [ITHREAD] ath0: AR5212 mac 5.9 RF5112 phy 4.3 Aug 23, 2011 kernel --- ath0: mem 0xf8f1-0xf8f1 irq 11 at device 0.0 on cardbus0 I've tried forcing successful returns from ar5212SetPowerModeAwake() and ar5212SetResetReg() but it doesn't help (diffs below). Any suggestions on how to get this to work? Full dmesg from working and non-working kernels at http://people.freebsd.org/~deischen/ath/ath.dmesg -- DE [deischen@orion /usr/src/sys/dev/ath]$ svn diff Index: ath_hal/ar5212/ar5212_reset.c === --- ath_hal/ar5212/ar5212_reset.c (revision 225101) +++ ath_hal/ar5212/ar5212_reset.c (working copy) @@ -1145,7 +1145,8 @@ /* track PHY power state so we don't try to r/w BB registers */ AH5212(ah)->ah_phyPowerOn = ((resetMask & AR_RC_BB) == 0); - return rt; +// return rt; + return AH_TRUE; } int16_t Index: ath_hal/ar5212/ar5212_power.c === --- ath_hal/ar5212/ar5212_power.c (revision 225101) +++ ath_hal/ar5212/ar5212_power.c (working copy) @@ -77,7 +77,9 @@ ath_hal_printf(ah, "%s: Failed to wakeup in %ums\n", __func__, POWER_UP_TIME/50); #endif +#if 0 return AH_FALSE; +#endif } } -- DE ___ 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"
F_RDLCK lock to FreeBSD NFS server fails to R/O target file
Hi Fellow NFS'ers,
I believe I have found the problem we've been having with read locks
while attaching to a FreeBSD NFS server.
In sys/nlm/nlm_prot_impl.c, function nlm_get_vfs_state(), there is a call
to VOP_ACCESS() as follows:
/*
* Check cred.
*/
NLM_DEBUG(3, "nlm_get_vfs_state(): Calling VOP_ACCESS(VWRITE) with
cred->cr_uid=%d\n",cred->cr_uid);
error = VOP_ACCESS(vs->vs_vp, VWRITE, cred, curthread);
if (error) {
NLM_DEBUG(3, "nlm_get_vfs_state(): caller_name = %s
VOP_ACCESS() returns %d\n",
host->nh_caller_name, error);
goto out;
}
The file being accessed is read only to the user, and open()ed with
O_RDONLY. The lock being requested is for a read.
fd = open(filename, O_RDONLY, 0);
...
lblk.l_type = F_RDLCK;
lblk.l_start = 0;
lblk.l_whence= SEEK_SET;
lblk.l_len = 0;
lblk.l_pid = 0;
rc = fcntl(fd, F_SETLK, &lblk);
Running the above from a remote system, the lock call fails with
errno set to ENOLCK. Given cred->cr_uid comes in as 227 which is
my uid on the remote system. Since the file is R/O to me, and the
VOP_ACCESS() is asking for VWRITE, it fails with errno 13, EACCES,
Permission denied.
The above operations work correctly to some of our other
favorite big-name nfs vendors :-)
Opinions on the "correct" way to fix this?
1. Since we're only asking for a read lock, why do we need to ask
for VWRITE? I may not understand an underlying requirement for
the VWRITE so please feel free to educate me if needed.
Something like: request == F_RDLCK ? VREAD : VWRITE
(need to figure out where to get the request from in this context).
2. Attempt VWRITE, fallback to VREAD... seems off to me though.
3. Other?
I appreciate any thoughts on this.
Thanks,
John
While they might not follow style(9) completely, I've uploaded
my patch to nlm_prot.impl.c with the NLM_DEBUG() calls i've added.
I'd appreciate it if someone would consider committing them so
who ever debugs this file next will have them available.
http://people.freebsd.org/~jwd/nlm_prot_impl.c.patch
___
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: fsid change of ZFS?
On Wed, 24 Aug 2011, Rick Macklem wrote:
"afs"
The current OpenAFS codebase uses the all-caps "AFS". Judging by the
omitted text, perhaps this should change. (We also don't use VFS_SET to
set it, which I filed a bug about.)
and here is my current rendition of the patch. (I took Gleb's suggestion
and switched to fnv_32_str(). I'll leave it that way unless there is a
collision after adding any names people post to the above list.)
It sounds like people have agreed that this is a reasonable solution.
If hrs@ can confirm that testing shows it fixes the original problem
(the ZFS file handles don't change when it's loaded at different times),
I'll pass it along to re@.
Thanks for the helpful suggestions, rick
--- kern/vfs_init.c.sav 2011-06-11 18:58:33.0 -0400
+++ kern/vfs_init.c 2011-08-24 16:15:24.0 -0400
@@ -39,6 +39,7 @@ __FBSDID("$FreeBSD: head/sys/kern/vfs_in
#include
#include
+#include
#include
#include
#include
@@ -138,6 +139,8 @@ vfs_register(struct vfsconf *vfc)
struct sysctl_oid *oidp;
struct vfsops *vfsops;
static int once;
+ struct vfsconf *tvfc;
+ uint32_t hashval;
if (!once) {
vattr_null(&va_null);
@@ -152,7 +155,26 @@ vfs_register(struct vfsconf *vfc)
if (vfs_byname(vfc->vfc_name) != NULL)
return EEXIST;
- vfc->vfc_typenum = maxvfsconf++;
+ /*
+* Calculate a hash on vfc_name to use for vfc_typenum. Unless
+* a collision occurs, it is limited to 8bits since that is
+* what ZFS uses from vfc_typenum and that also limits how sparsely
+* distributed vfc_typenum becomes.
+*/
+ hashval = fnv_32_str(vfc->vfc_name, FNV1_32_INIT);
+ hashval &= 0xff;
+ do {
+ /* Look for and fix any collision. */
+ TAILQ_FOREACH(tvfc, &vfsconf, vfc_list) {
+ if (hashval == tvfc->vfc_typenum) {
+ hashval++; /* Can exceed 8bits, if needed. */
If we're confident that we won't ever fully fill the hash table, I would
think that this should wrap around back to zero (or one?) instead of
overflowing.
Do we need to care about something attempting to add the same vfc_name
twice? This code will happily add a second entry at the next available
index.
+ break;
+ }
+ }
+ } while (tvfc != NULL);
+ vfc->vfc_typenum = hashval;
+ if (vfc->vfc_typenum >= maxvfsconf)
+ maxvfsconf = vfc->vfc_typenum + 1;
I guess we're holding off on killing maxvfsconf until after 9.0 is out?
-Ben
TAILQ_INSERT_TAIL(&vfsconf, vfc, vfc_list);
/*
___
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: fsid change of ZFS?
Pawel Jakub Dawidek wrote:
> On Wed, Aug 24, 2011 at 04:41:25PM +0300, Kostik Belousov wrote:
> > On Wed, Aug 24, 2011 at 09:36:37AM -0400, Rick Macklem wrote:
> > > Well, doesn't this result in the same issue as the fixed table?
> > > In other words, the developer has to supply the "suggested byte"
> > > for
> > > fsid and make sure that it doesn't conflict with other "suggested
> > > byte"
> > > values or suffer the same consequence as forgetting to update the
> > > fixed
> > > table. (ie. It just puts the fixed value in a different place,
> > > from what
> > > I see, for in-tree modules. Also, with a fixed table, they are all
> > > in
> > > one place, so it's easy to choose a non-colliding value?)
> > The reason for my proposal was Pawel note that a porter of the
> > filesystem
> > should be aware of some place in kern/ where to register, besides
> > writing
> > the module.
>
> Well, he has to be aware, but we should do all we can to minimize the
> number of place he needs to update, as it is easy to forget some.
>
> I agree with Rick that what you proposed is similar to fixed table of
> file system names and I'd prefer to avoid that. If we can have
> name-based hash that produces no collision for in-tree file systems
> and
> know current 3rd party file systems plus collision detection for the
> future then it is good enough, IMHO. And this is what Rick proposed
> with
> his patch.
>
Ok, here is the list of file system names I've been checking and there
haven't been any collisions (either hash function). If you know of other
well known file type names, please email and I'll add them to the list
and check for collisions again.
"cd9660"
"ufs"
"procfs"
"devfs"
"msdosfs"
"nfs"
"xfs"
"reiserfs"
"tmpfs"
"hpfs"
"ntfs"
"ext2fs"
"udf"
"zfs"
"afs"
and here is my current rendition of the patch. (I took Gleb's suggestion
and switched to fnv_32_str(). I'll leave it that way unless there is a
collision after adding any names people post to the above list.)
It sounds like people have agreed that this is a reasonable solution.
If hrs@ can confirm that testing shows it fixes the original problem
(the ZFS file handles don't change when it's loaded at different times),
I'll pass it along to re@.
Thanks for the helpful suggestions, rick
--- kern/vfs_init.c.sav 2011-06-11 18:58:33.0 -0400
+++ kern/vfs_init.c 2011-08-24 16:15:24.0 -0400
@@ -39,6 +39,7 @@ __FBSDID("$FreeBSD: head/sys/kern/vfs_in
#include
#include
+#include
#include
#include
#include
@@ -138,6 +139,8 @@ vfs_register(struct vfsconf *vfc)
struct sysctl_oid *oidp;
struct vfsops *vfsops;
static int once;
+ struct vfsconf *tvfc;
+ uint32_t hashval;
if (!once) {
vattr_null(&va_null);
@@ -152,7 +155,26 @@ vfs_register(struct vfsconf *vfc)
if (vfs_byname(vfc->vfc_name) != NULL)
return EEXIST;
- vfc->vfc_typenum = maxvfsconf++;
+ /*
+* Calculate a hash on vfc_name to use for vfc_typenum. Unless
+* a collision occurs, it is limited to 8bits since that is
+* what ZFS uses from vfc_typenum and that also limits how sparsely
+* distributed vfc_typenum becomes.
+*/
+ hashval = fnv_32_str(vfc->vfc_name, FNV1_32_INIT);
+ hashval &= 0xff;
+ do {
+ /* Look for and fix any collision. */
+ TAILQ_FOREACH(tvfc, &vfsconf, vfc_list) {
+ if (hashval == tvfc->vfc_typenum) {
+ hashval++; /* Can exceed 8bits, if needed. */
+ break;
+ }
+ }
+ } while (tvfc != NULL);
+ vfc->vfc_typenum = hashval;
+ if (vfc->vfc_typenum >= maxvfsconf)
+ maxvfsconf = vfc->vfc_typenum + 1;
TAILQ_INSERT_TAIL(&vfsconf, vfc, vfc_list);
/*
___
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: fsid change of ZFS?
Pawel Jakub Dawidek wrote:
> On Wed, Aug 24, 2011 at 04:41:25PM +0300, Kostik Belousov wrote:
> > On Wed, Aug 24, 2011 at 09:36:37AM -0400, Rick Macklem wrote:
> > > Well, doesn't this result in the same issue as the fixed table?
> > > In other words, the developer has to supply the "suggested byte"
> > > for
> > > fsid and make sure that it doesn't conflict with other "suggested
> > > byte"
> > > values or suffer the same consequence as forgetting to update the
> > > fixed
> > > table. (ie. It just puts the fixed value in a different place,
> > > from what
> > > I see, for in-tree modules. Also, with a fixed table, they are all
> > > in
> > > one place, so it's easy to choose a non-colliding value?)
> > The reason for my proposal was Pawel note that a porter of the
> > filesystem
> > should be aware of some place in kern/ where to register, besides
> > writing
> > the module.
>
> Well, he has to be aware, but we should do all we can to minimize the
> number of place he needs to update, as it is easy to forget some.
>
> I agree with Rick that what you proposed is similar to fixed table of
> file system names and I'd prefer to avoid that. If we can have
> name-based hash that produces no collision for in-tree file systems
> and
> know current 3rd party file systems plus collision detection for the
> future then it is good enough, IMHO. And this is what Rick proposed
> with
> his patch.
>
Ok, here is the list of file system names I've been checking and there
haven't been any collisions (either hash function). If you know of other
well known file type names, please email and I'll add them to the list
and check for collisions again.
"cd9660"
"ufs"
"procfs"
"devfs"
"msdosfs"
"nfs"
"xfs"
"reiserfs"
"tmpfs"
"hpfs"
"ntfs"
"ext2fs"
"udf"
"zfs"
"afs"
and here is my current rendition of the patch. (I took Gleb's suggestion
and switched to fnv_32_str(). I'll leave it that way unless there is a
collision after adding any names people post to the above list.)
It sounds like people have agreed that this is a reasonable solution.
If hrs@ can confirm that testing shows it fixes the original problem
(the ZFS file handles don't change when it's loaded at different times),
I'll pass it along to re@.
Thanks for the helpful suggestions, rick
--- kern/vfs_init.c.sav 2011-06-11 18:58:33.0 -0400
+++ kern/vfs_init.c 2011-08-24 16:15:24.0 -0400
@@ -39,6 +39,7 @@ __FBSDID("$FreeBSD: head/sys/kern/vfs_in
#include
#include
+#include
#include
#include
#include
@@ -138,6 +139,8 @@ vfs_register(struct vfsconf *vfc)
struct sysctl_oid *oidp;
struct vfsops *vfsops;
static int once;
+ struct vfsconf *tvfc;
+ uint32_t hashval;
if (!once) {
vattr_null(&va_null);
@@ -152,7 +155,26 @@ vfs_register(struct vfsconf *vfc)
if (vfs_byname(vfc->vfc_name) != NULL)
return EEXIST;
- vfc->vfc_typenum = maxvfsconf++;
+ /*
+* Calculate a hash on vfc_name to use for vfc_typenum. Unless
+* a collision occurs, it is limited to 8bits since that is
+* what ZFS uses from vfc_typenum and that also limits how sparsely
+* distributed vfc_typenum becomes.
+*/
+ hashval = fnv_32_str(vfc->vfc_name, FNV1_32_INIT);
+ hashval &= 0xff;
+ do {
+ /* Look for and fix any collision. */
+ TAILQ_FOREACH(tvfc, &vfsconf, vfc_list) {
+ if (hashval == tvfc->vfc_typenum) {
+ hashval++; /* Can exceed 8bits, if needed. */
+ break;
+ }
+ }
+ } while (tvfc != NULL);
+ vfc->vfc_typenum = hashval;
+ if (vfc->vfc_typenum >= maxvfsconf)
+ maxvfsconf = vfc->vfc_typenum + 1;
TAILQ_INSERT_TAIL(&vfsconf, vfc, vfc_list);
/*
___
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: fsid change of ZFS?
On Wed, Aug 24, 2011 at 04:41:25PM +0300, Kostik Belousov wrote: > On Wed, Aug 24, 2011 at 09:36:37AM -0400, Rick Macklem wrote: > > Well, doesn't this result in the same issue as the fixed table? > > In other words, the developer has to supply the "suggested byte" for > > fsid and make sure that it doesn't conflict with other "suggested byte" > > values or suffer the same consequence as forgetting to update the fixed > > table. (ie. It just puts the fixed value in a different place, from what > > I see, for in-tree modules. Also, with a fixed table, they are all in > > one place, so it's easy to choose a non-colliding value?) > The reason for my proposal was Pawel note that a porter of the filesystem > should be aware of some place in kern/ where to register, besides writing > the module. Well, he has to be aware, but we should do all we can to minimize the number of place he needs to update, as it is easy to forget some. I agree with Rick that what you proposed is similar to fixed table of file system names and I'd prefer to avoid that. If we can have name-based hash that produces no collision for in-tree file systems and know current 3rd party file systems plus collision detection for the future then it is good enough, IMHO. And this is what Rick proposed with his patch. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com pgpOyu4gfRBq3.pgp Description: PGP signature
Re: fsid change of ZFS?
On Thu, 25 Aug 2011, Hiroki Sato wrote: My opinion is using a hash function which occurs no collision in the well-known names is sufficient for our purpose because the number of file systems on a running system is small anyway and not changed frequently in most cases. I am not sure which function is best; fnv_32_str() seemed better against a large data set but it is not likely to have >30 file systems, for example. This was a large part of my reasoning when proposing a hash table initially -- there are 256 (maybe 255 if you want to reserve one) slots, and only 14 or so filesystems currently in the tree. It seems very unlikely that any single machine would ever have more than another five out-of-tree filesystem types on it (right?), so putting 20 items into 250 hash bins is a pretty good chance of being collision-free. -Ben ___ 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: fsid change of ZFS?
Rick Macklem wrote in <920337541.272757.1314192294772.javamail.r...@erie.cs.uoguelph.ca>: rm> Kostik Belousov wrote: rm> > On Tue, Aug 23, 2011 at 11:23:03PM +0200, Pawel Jakub Dawidek wrote: rm> > > On Tue, Aug 23, 2011 at 04:11:20PM -0400, Rick Macklem wrote: rm> > > > Pawel Jakub Dawidek wrote: rm> > > > > On Tue, Aug 23, 2011 at 10:09:41AM -0400, Rick Macklem wrote: rm> > > > > > Ok, I'll admit I wasn't very fond of a fixed table that would rm> > > > > > inevitably rm> > > > > > get out of date someday, either. rm> > > > > > rm> > > > > > I didn't think hashing for the cases not in the table was rm> > > > > > worth the rm> > > > > > effort, rm> > > > > > but doing a hash instead of a table seems reasonable. rm> > > > > > rm> > > > > > I see that ZFS only uses the low order 8 bits, so I'll try and rm> > > > > > come rm> > > > > > up rm> > > > > > with an 8bit hash solution and will post a patch for rm> > > > > > testing/review rm> > > > > > soon. rm> > > > > > rm> > > > > > I don't think the vfs_sysctl() is that great a concern, given rm> > > > > > that rm> > > > > > it rm> > > > > > appears to be deprecated already anyhow. (With an 8bit hash, rm> > > > > > vfs_typenum rm> > > > > > won't be that sparse.) I'll also make sure that whatever hash rm> > > > > > I use rm> > > > > > doesn't collide for the current list of file names (although I rm> > > > > > will rm> > > > > > include rm> > > > > > code that handles a collision in the patch). rm> > > > > rm> > > > > Sounds great. Thanks! rm> > > > > rm> > > > Here's the patch. (Hiroki could you please test this, thanks, rm> > > > rick.) rm> > > > ps: If the white space gets trashed, the same patch is at: rm> > > >http://people.freebsd.org/~rmacklem/fsid.patch rm> > > rm> > > The patch is fine by me. Thanks, Rick! rm> > rm> > Sorry, I am late. rm> > rm> > It seems that the probability of the collisions for the hash is quite rm> > high. rm> > Due to the fixup procedure, the resulting typenum will depend on the rm> > order rm> > of the module initialization, isn't it ? IMO, it makes the patch goal rm> > not rm> > met. rm> Well, the about 15 file system types currently in FreeBSD don't collide. rm> (At least with the patch I posted. I'll test it again with "hash & 0xff;".) rm> rm> Also, since the collision results in the second one using the next higher rm> value (usually, until you get something like 50+ file system types), it works rm> for those cases unless the order that these 2 file systems call vfs_register() rm> is reversed. (The likelyhood of this reversal is lower than the likelyhood rm> of vfs_register() just being called in a different order, I think?) rm> rm> Since it now changes whenever a different kernel config or different module rm> loading order is used and there aren't a lot of complaints, I think "usually rm> works" is good enough. However, it doesn't matter to me, so I'll let others rm> decide. rm> rm> Yet another option is to go back to what hrs@ originally suggested, which rm> was change ZFS to not use vfc_typenum in its fsid. (I now see that 0 won't rm> conflict with any assigned vfc_typenum values, since they start at 1 and rm> 255 would also probably be safe, since its unlikely there ever will be rm> 255 different file system types.) The problem with this is no future FS rm> can use the same trick. My opinion is using a hash function which occurs no collision in the well-known names is sufficient for our purpose because the number of file systems on a running system is small anyway and not changed frequently in most cases. I am not sure which function is best; fnv_32_str() seemed better against a large data set but it is not likely to have >30 file systems, for example. -- Hiroki pgp5gcbSw2jiZ.pgp Description: PGP signature
Re: fsid change of ZFS?
Gleb Kurtsou wrote in <20110824150235.GA46460@tops>: gl> On (24/08/2011 21:34), Hiroki Sato wrote: gl> > Kostik Belousov wrote gl> > in <20110824082119.gj17...@deviant.kiev.zoral.com.ua>: gl> > gl> > ko> On Tue, Aug 23, 2011 at 11:23:03PM +0200, Pawel Jakub Dawidek wrote: gl> > ko> > On Tue, Aug 23, 2011 at 04:11:20PM -0400, Rick Macklem wrote: gl> > ko> > > Here's the patch. (Hiroki could you please test this, thanks, rick.) gl> > ko> > > ps: If the white space gets trashed, the same patch is at: gl> > ko> > >http://people.freebsd.org/~rmacklem/fsid.patch gl> > ko> > gl> > ko> > The patch is fine by me. Thanks, Rick! gl> > ko> gl> > ko> Sorry, I am late. gl> > ko> gl> > ko> It seems that the probability of the collisions for the hash is quite high. gl> > ko> Due to the fixup procedure, the resulting typenum will depend on the order gl> > ko> of the module initialization, isn't it ? IMO, it makes the patch goal not gl> > ko> met. gl> > gl> > I tried the following two experiments (the complete results are gl> > attached) to confirm the probability: gl> > gl> > 1. [fsidhash1.txt] gl> > well-known vfc_name and the names "[a-z]fs" (# of names is 36) gl> > with no fix-up recalculation. gl> > gl> > 2. [fsidhash2.txt] gl> > well-known vfc_name and the names "[a-z][a-z]fs" (# of names is 710) gl> > with no fix-up recalculation. gl> > gl> > There is no collision in the case 1. And when [a-z][a-z]fs are gl> > included the average number of the collided names in the same hash gl> > value is 4.43 (i.e. 160 different hash values are generated, the gl> > theoretical best number is (710 entries / 256 buckets) = 2.77). gl> Could you run the same test with fnv_32_buf()? Collision rate is likely gl> to be lower. The results by fnv_32_str() are attached. The number of the collisions reduced but this time there were four collisions in the "well-known ones + [a-z]fs" case though no collision within the well-known names. The generated hash values for the case 2 was 235, so the rate is 3.02. This is certainly better than hash32_str(). -- Hiroki 0x0d = yfs 0x13 = mfs 0x19 = procfs 0x1a = kfs 0x30 = bfs 0x34 = ufs 0x3a = gfs 0x40 = sfs, udf 0x56 = jfs 0x5a = ntfs 0x5d = ext2fs 0x61 = devfs 0x6f = hpfs 0x75 = hfs 0x7a = pfs 0x7b = ofs 0x7c = dfs 0x81 = wfs 0x88 = msdosfs 0xa0 = cd9660 0xa1 = lfs, xfs 0xa8 = cfs, tfs 0xbf = tmpfs 0xc0 = afs 0xc2 = reiserfs 0xc6 = ifs 0xc8 = ffs, rfs 0xec = qfs 0xed = zfs 0xee = efs 0xef = nfs 0xf4 = vfs 0x01 = mcfs, prfs, xufs 0x02 = iafs, jifs, kpfs, xifs 0x04 = bzfs, dbfs, ehfs, ewfs, klfs, yhfs 0x05 = ycfs 0x06 = dyfs, ecfs, ipfs, qdfs, qpfs 0x07 = pnfs, ywfs 0x08 = qofs, xafs 0x09 = bmfs, iffs, iyfs, kdfs, pufs, vffs 0x0a = imfs 0x0b = bffs, dmfs 0x0c = idfs, yofs 0x0d = adfs, nmfs, pafs, vqfs, yfs 0x0e = aifs, qwfs 0x0f = hafs, nffs, vzfs 0x10 = zafs 0x11 = wcfs 0x12 = zjfs 0x13 = mfs, nqfs, wwfs 0x14 = nefs, vcfs 0x15 = bkfs 0x16 = clfs, zifs 0x17 = njfs, zrfs 0x18 = ocfs, owfs, tvfs, wdfs 0x19 = fefs, procfs, tbfs, vwfs, zffs 0x1a = fnfs, fqfs, kfs 0x1b = gofs, ryfs 0x1d = fzfs, rmfs, rrfs, skfs 0x1e = odfs, tqfs 0x1f = lvfs, oofs, oxfs, rffs, tzfs 0x20 = eefs, gwfs, kmfs, tmfs, xcfs 0x21 = ulfs, yqfs 0x22 = fbfs, hrfs, mtfs, qifs, sxfs, xjfs 0x23 = dofs, sdfs, ssfs, ugfs 0x24 = etfs, kofs, usfs, uxfs 0x25 = kqfs, ljfs, mkfs, opfs, pcfs 0x26 = jrfs, pwfs, qxfs 0x27 = ghfs 0x28 = hjfs, xvfs 0x29 = hufs, ikfs, jpfs, ksfs, slfs 0x2a = byfs, jefs, khfs, ukfs 0x2b = brfs, dhfs, jnfs, ytfs 0x2c = defs, hwfs, msfs 0x2d = apfs, qlfs 0x2e = pdfs, pifs, vefs 0x2f = befs, cgfs, hmfs, iwfs, jlfs, vnfs 0x30 = bfs, bjfs, jwfs 0x31 = csfs, cxfs 0x33 = alfs, axfs, vyfs 0x34 = ufs 0x35 = acfs, jcfs, vvfs 0x36 = awfs, bcfs, vbfs 0x37 = wkfs 0x38 = tofs 0x3a = fmfs, gfs 0x3b = nvfs 0x3c = nbfs, rqfs 0x3d = tgfs, tsfs, zwfs 0x3e = wlfs, zzfs 0x3f = fkfs, wgfs, znfs 0x40 = dvfs, gcfs, sfs, thfs, udf, wpfs 0x41 = fwfs 0x42 = pzfs, rwfs, udfs 0x43 = dgfs, lgfs, sgfs 0x44 = rkfs 0x45 = dnfs, llfs, lsfs, ogfs 0x46 = lxfs, pkfs, wxfs 0x47 = dqfs, eofs, gdfs, xofs 0x48 = dzfs, pbfs, upfs, xdfs, xpfs 0x49 = qcfs 0x4a = dsfs, pvfs, rcfs 0x4b = exfs, jzfs, mhfs, ohfs 0x4c = esfs, gpfs, ylfs 0x4d = qtfs, ygfs 0x4e = hbfs, hofs, ihfs 0x4f = bhfs, hvfs, icfs, uvfs 0x50 = bwfs, ktfs, mnfs, stfs 0x51 = ejfs 0x53 = itfs 0x54 = qffs, vkfs, vtfs 0x56 = bofs, cofs, jfs, jkfs 0x57 = iofs, yjfs 0x59 = qrfs 0x5a = atfs, ntfs, vsfs 0x5b = akfs 0x5d = ccfs, chfs, ctfs, ext2fs, zlfs, zxfs 0x5e = fvfs, wzfs 0x60 = nsfs, rjfs, wsfs 0x61 = devfs, ftfs, nofs, nxfs 0x62 = agfs, fjfs, xbfs 0x63 = ojfs 0x64 = grfs, kgfs, rhfs, rvfs, tkfs, wofs, zcfs, ztfs 0x65 = lofs, ttfs 0x66 = fhfs, gffs 0x67 = mgfs, ngfs, svfs, xsfs 0x68 = fsfs, sbfs 0x69 = ppfs, rtfs, zkfs 0x6a = jxfs, rofs, uhfs 0x6b = dkfs, elfs, kkfs, mefs, mpfs, ucfs 0x6c = omfs, txfs, yxfs 0x6d = egfs, fgfs, pgfs, ysfs 0x6e = gufs, gxfs, kbfs, plfs, uafs, xgfs 0x6f = hpfs 0x70 = myfs, qkfs, sqfs, uzfs 0x71 = epfs, jtfs, kxfs 0x72 = mbfs, ydf
Re: FreeBSD mbufs() cache poisoning local priv escalation v2 by KCOPE
On 24.08.2011 16:59, Victor Detoni wrote: > Does Someone know if this was fixed? > > On Wed, Aug 24, 2011 at 11:57 AM, Victor Detoni wrote: > >> Oh shit guys! >> >> http://pastebin.com/dyKLRr0v >> http://security.freebsd.org/advisories/FreeBSD-SA-10:07.mbuf.asc Isn't this the one? //Svein -- +---+--- /"\ |Svein Skogen | sv...@d80.iso100.no \ / |Solberg Østli 9| PGP Key: 0xE5E76831 X|2020 Skedsmokorset | sv...@jernhuset.no / \ |Norway | PGP Key: 0xCE96CE13 | | sv...@stillbilde.net ascii | | PGP Key: 0x58CD33B6 ribbon |System Admin | svein-listm...@stillbilde.net Campaign|stillbilde.net | PGP Key: 0x22D494A4 +---+--- |msn messenger: | Mobile Phone: +47 907 03 575 |sv...@jernhuset.no | RIPE handle:SS16503-RIPE +---+--- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? Picture Gallery: https://gallery.stillbilde.net/v/svein/ signature.asc Description: OpenPGP digital signature
Re: FreeBSD mbufs() cache poisoning local priv escalation v2 by KCOPE
On Wed, Aug 24, 2011 at 11:59:01AM -0300, Victor Detoni wrote: > Does Someone know if this was fixed? > > On Wed, Aug 24, 2011 at 11:57 AM, Victor Detoni wrote: > > > Oh shit guys! > > > > http://pastebin.com/dyKLRr0v > > > It is already one year old... and it was fixed before this pastebin: http://security.freebsd.org/advisories/FreeBSD-SA-10:07.mbuf.asc Alexey. ___ 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: fsid change of ZFS?
On (24/08/2011 21:34), Hiroki Sato wrote: > Kostik Belousov wrote > in <20110824082119.gj17...@deviant.kiev.zoral.com.ua>: > > ko> On Tue, Aug 23, 2011 at 11:23:03PM +0200, Pawel Jakub Dawidek wrote: > ko> > On Tue, Aug 23, 2011 at 04:11:20PM -0400, Rick Macklem wrote: > ko> > > Here's the patch. (Hiroki could you please test this, thanks, rick.) > ko> > > ps: If the white space gets trashed, the same patch is at: > ko> > >http://people.freebsd.org/~rmacklem/fsid.patch > ko> > > ko> > The patch is fine by me. Thanks, Rick! > ko> > ko> Sorry, I am late. > ko> > ko> It seems that the probability of the collisions for the hash is quite > high. > ko> Due to the fixup procedure, the resulting typenum will depend on the order > ko> of the module initialization, isn't it ? IMO, it makes the patch goal not > ko> met. > > I tried the following two experiments (the complete results are > attached) to confirm the probability: > > 1. [fsidhash1.txt] > well-known vfc_name and the names "[a-z]fs" (# of names is 36) > with no fix-up recalculation. > > 2. [fsidhash2.txt] > well-known vfc_name and the names "[a-z][a-z]fs" (# of names is 710) > with no fix-up recalculation. > > There is no collision in the case 1. And when [a-z][a-z]fs are > included the average number of the collided names in the same hash > value is 4.43 (i.e. 160 different hash values are generated, the > theoretical best number is (710 entries / 256 buckets) = 2.77). Could you run the same test with fnv_32_buf()? Collision rate is likely to be lower. > At least, vfc_names we currently have in our kernel code have no > collision, fortunately. As you noticed "[a-z][a-z]fs" is an > impractical data set and these results cannot explain the > characteristics for all possible and practical vfc_names, so whether > this hash is reasonable or not depends on how we think of them. > Comments or other better idea? > > -- Hiroki ___ 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"
AW: Panic with 9.0 Beta 1 (arcmsr.c)
After this messages there are no visible disks. A camcontrol rescan all leads tot he same timeouts. > -Ursprüngliche Nachricht- > Von: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd- > curr...@freebsd.org] Im Auftrag von Uwe Grohnwaldt > Gesendet: Mittwoch, 24. August 2011 16:37 > An: freebsd-current@freebsd.org > Betreff: AW: Panic with 9.0 Beta 1 (arcmsr.c) > > Hi, > > I upgraded a fresh RELENG_8_2 to CURRENT and nearly everything works > fine. I only have to wait about 3 minutes during boot. In dmesg I have many > messages like this: arcmsr1: scsi id 17 lun 0 cmd=0x12 > srb='0xff8462bd9780' ccb command time out! > > http://ugrohnwaldt.web02.lando.us/FBSD/dmesg-2011-08-24.log.txt > > Thanks, > Uwe > > > -Ursprüngliche Nachricht- > > Von: John Baldwin [mailto:j...@freebsd.org] > > Gesendet: Dienstag, 23. August 2011 13:43 > > An: freebsd-current@freebsd.org > > Cc: Uwe Grohnwaldt > > Betreff: Re: Panic with 9.0 Beta 1 (arcmsr.c) > > > > On Tuesday, August 23, 2011 6:57:45 am Uwe Grohnwaldt wrote: > > > Hi, > > > > > > i tried to install FBSD 9.0 beta 1. Booting the install-cd stopped > > > with a kernel panic: > > > > > > panic: _mtx_lock_sleep: recursed on non-recursive mutex arcmsr Q > > > buffer lock @ /usr/src/sys/dev/arcmsr/arcmsr.c:2093 > > > > > > A screenshot from the panic can be found here: > > > http://ugrohnwaldt.web02.lando.us/FBSD/arcmsr.png > > > > Looks like this was fixed after BETA1 was released. > > > > -- > > 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" ___ 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: FreeBSD mbufs() cache poisoning local priv escalation v2 by KCOPE
Does Someone know if this was fixed? On Wed, Aug 24, 2011 at 11:57 AM, Victor Detoni wrote: > Oh shit guys! > > http://pastebin.com/dyKLRr0v > ___ 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"
FreeBSD mbufs() cache poisoning local priv escalation v2 by KCOPE
Oh shit guys! http://pastebin.com/dyKLRr0v ___ 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"
AW: Panic with 9.0 Beta 1 (arcmsr.c)
Hi, I upgraded a fresh RELENG_8_2 to CURRENT and nearly everything works fine. I only have to wait about 3 minutes during boot. In dmesg I have many messages like this: arcmsr1: scsi id 17 lun 0 cmd=0x12 srb='0xff8462bd9780' ccb command time out! http://ugrohnwaldt.web02.lando.us/FBSD/dmesg-2011-08-24.log.txt Thanks, Uwe > -Ursprüngliche Nachricht- > Von: John Baldwin [mailto:j...@freebsd.org] > Gesendet: Dienstag, 23. August 2011 13:43 > An: freebsd-current@freebsd.org > Cc: Uwe Grohnwaldt > Betreff: Re: Panic with 9.0 Beta 1 (arcmsr.c) > > On Tuesday, August 23, 2011 6:57:45 am Uwe Grohnwaldt wrote: > > Hi, > > > > i tried to install FBSD 9.0 beta 1. Booting the install-cd stopped > > with a kernel panic: > > > > panic: _mtx_lock_sleep: recursed on non-recursive mutex arcmsr Q > > buffer lock @ /usr/src/sys/dev/arcmsr/arcmsr.c:2093 > > > > A screenshot from the panic can be found here: > > http://ugrohnwaldt.web02.lando.us/FBSD/arcmsr.png > > Looks like this was fixed after BETA1 was released. > > -- > 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: fsid change of ZFS?
On Wed, Aug 24, 2011 at 09:36:37AM -0400, Rick Macklem wrote: > Kostik Belousov wrote: > > On Wed, Aug 24, 2011 at 09:34:58PM +0900, Hiroki Sato wrote: > > > Kostik Belousov wrote > > > in <20110824082119.gj17...@deviant.kiev.zoral.com.ua>: > > > > > > ko> On Tue, Aug 23, 2011 at 11:23:03PM +0200, Pawel Jakub Dawidek > > > wrote: > > > ko> > On Tue, Aug 23, 2011 at 04:11:20PM -0400, Rick Macklem wrote: > > > ko> > > Pawel Jakub Dawidek wrote: > > > ko> > > > On Tue, Aug 23, 2011 at 10:09:41AM -0400, Rick Macklem > > > wrote: > > > ko> > > > > Ok, I'll admit I wasn't very fond of a fixed table that > > > would > > > ko> > > > > inevitably > > > ko> > > > > get out of date someday, either. > > > ko> > > > > > > > ko> > > > > I didn't think hashing for the cases not in the table > > > was worth the > > > ko> > > > > effort, > > > ko> > > > > but doing a hash instead of a table seems reasonable. > > > ko> > > > > > > > ko> > > > > I see that ZFS only uses the low order 8 bits, so I'll > > > try and come > > > ko> > > > > up > > > ko> > > > > with an 8bit hash solution and will post a patch for > > > testing/review > > > ko> > > > > soon. > > > ko> > > > > > > > ko> > > > > I don't think the vfs_sysctl() is that great a concern, > > > given that > > > ko> > > > > it > > > ko> > > > > appears to be deprecated already anyhow. (With an 8bit > > > hash, > > > ko> > > > > vfs_typenum > > > ko> > > > > won't be that sparse.) I'll also make sure that whatever > > > hash I use > > > ko> > > > > doesn't collide for the current list of file names > > > (although I will > > > ko> > > > > include > > > ko> > > > > code that handles a collision in the patch). > > > ko> > > > > > > ko> > > > Sounds great. Thanks! > > > ko> > > > > > > ko> > > Here's the patch. (Hiroki could you please test this, > > > thanks, rick.) > > > ko> > > ps: If the white space gets trashed, the same patch is at: > > > ko> > > http://people.freebsd.org/~rmacklem/fsid.patch > > > ko> > > > > ko> > The patch is fine by me. Thanks, Rick! > > > ko> > > > ko> Sorry, I am late. > > > ko> > > > ko> It seems that the probability of the collisions for the hash is > > > quite high. > > > ko> Due to the fixup procedure, the resulting typenum will depend on > > > the order > > > ko> of the module initialization, isn't it ? IMO, it makes the patch > > > goal not > > > ko> met. > > > > > > I tried the following two experiments (the complete results are > > > attached) to confirm the probability: > > > > > > 1. [fsidhash1.txt] > > > well-known vfc_name and the names "[a-z]fs" (# of names is 36) > > > with no fix-up recalculation. > > > > > > 2. [fsidhash2.txt] > > > well-known vfc_name and the names "[a-z][a-z]fs" (# of names is > > > 710) > > > with no fix-up recalculation. > > > > > > There is no collision in the case 1. And when [a-z][a-z]fs are > > > included the average number of the collided names in the same hash > > > value is 4.43 (i.e. 160 different hash values are generated, the > > > theoretical best number is (710 entries / 256 buckets) = 2.77). > > > > > > At least, vfc_names we currently have in our kernel code have no > > > collision, fortunately. As you noticed "[a-z][a-z]fs" is an > > > impractical data set and these results cannot explain the > > > characteristics for all possible and practical vfc_names, so > > > whether > > > this hash is reasonable or not depends on how we think of them. > > > Comments or other better idea? > > > > Might be, add a new byte field to struct vfsconf, containing the > > suggested > > byte to be used by fsid. Divide the namespace into two half by the > > highest > > bit 7. Use the byte values with the highest bit clear for statically > > assignment for in-tree modules. Kernel will still check for the > > uniquiness > > on initialization. > > > Well, doesn't this result in the same issue as the fixed table? > In other words, the developer has to supply the "suggested byte" for > fsid and make sure that it doesn't conflict with other "suggested byte" > values or suffer the same consequence as forgetting to update the fixed > table. (ie. It just puts the fixed value in a different place, from what > I see, for in-tree modules. Also, with a fixed table, they are all in > one place, so it's easy to choose a non-colliding value?) The reason for my proposal was Pawel note that a porter of the filesystem should be aware of some place in kern/ where to register, besides writing the module. Anyway, do whatever you prefer. > > > Reserve the value '0' to mean that kernel must assign the next unused > > value >= 128. This is done to support out-of-tree modules. > > > > Might be, also reserve the value 0 to mean 'kernel > > Main drawback is that is sounds complicated. pgptfUeGgQ5a2.pgp Description: PGP signature
Re: fsid change of ZFS?
Kostik Belousov wrote: > On Wed, Aug 24, 2011 at 09:34:58PM +0900, Hiroki Sato wrote: > > Kostik Belousov wrote > > in <20110824082119.gj17...@deviant.kiev.zoral.com.ua>: > > > > ko> On Tue, Aug 23, 2011 at 11:23:03PM +0200, Pawel Jakub Dawidek > > wrote: > > ko> > On Tue, Aug 23, 2011 at 04:11:20PM -0400, Rick Macklem wrote: > > ko> > > Pawel Jakub Dawidek wrote: > > ko> > > > On Tue, Aug 23, 2011 at 10:09:41AM -0400, Rick Macklem > > wrote: > > ko> > > > > Ok, I'll admit I wasn't very fond of a fixed table that > > would > > ko> > > > > inevitably > > ko> > > > > get out of date someday, either. > > ko> > > > > > > ko> > > > > I didn't think hashing for the cases not in the table > > was worth the > > ko> > > > > effort, > > ko> > > > > but doing a hash instead of a table seems reasonable. > > ko> > > > > > > ko> > > > > I see that ZFS only uses the low order 8 bits, so I'll > > try and come > > ko> > > > > up > > ko> > > > > with an 8bit hash solution and will post a patch for > > testing/review > > ko> > > > > soon. > > ko> > > > > > > ko> > > > > I don't think the vfs_sysctl() is that great a concern, > > given that > > ko> > > > > it > > ko> > > > > appears to be deprecated already anyhow. (With an 8bit > > hash, > > ko> > > > > vfs_typenum > > ko> > > > > won't be that sparse.) I'll also make sure that whatever > > hash I use > > ko> > > > > doesn't collide for the current list of file names > > (although I will > > ko> > > > > include > > ko> > > > > code that handles a collision in the patch). > > ko> > > > > > ko> > > > Sounds great. Thanks! > > ko> > > > > > ko> > > Here's the patch. (Hiroki could you please test this, > > thanks, rick.) > > ko> > > ps: If the white space gets trashed, the same patch is at: > > ko> > > http://people.freebsd.org/~rmacklem/fsid.patch > > ko> > > > ko> > The patch is fine by me. Thanks, Rick! > > ko> > > ko> Sorry, I am late. > > ko> > > ko> It seems that the probability of the collisions for the hash is > > quite high. > > ko> Due to the fixup procedure, the resulting typenum will depend on > > the order > > ko> of the module initialization, isn't it ? IMO, it makes the patch > > goal not > > ko> met. > > > > I tried the following two experiments (the complete results are > > attached) to confirm the probability: > > > > 1. [fsidhash1.txt] > > well-known vfc_name and the names "[a-z]fs" (# of names is 36) > > with no fix-up recalculation. > > > > 2. [fsidhash2.txt] > > well-known vfc_name and the names "[a-z][a-z]fs" (# of names is > > 710) > > with no fix-up recalculation. > > > > There is no collision in the case 1. And when [a-z][a-z]fs are > > included the average number of the collided names in the same hash > > value is 4.43 (i.e. 160 different hash values are generated, the > > theoretical best number is (710 entries / 256 buckets) = 2.77). > > > > At least, vfc_names we currently have in our kernel code have no > > collision, fortunately. As you noticed "[a-z][a-z]fs" is an > > impractical data set and these results cannot explain the > > characteristics for all possible and practical vfc_names, so > > whether > > this hash is reasonable or not depends on how we think of them. > > Comments or other better idea? > > Might be, add a new byte field to struct vfsconf, containing the > suggested > byte to be used by fsid. Divide the namespace into two half by the > highest > bit 7. Use the byte values with the highest bit clear for statically > assignment for in-tree modules. Kernel will still check for the > uniquiness > on initialization. > Well, doesn't this result in the same issue as the fixed table? In other words, the developer has to supply the "suggested byte" for fsid and make sure that it doesn't conflict with other "suggested byte" values or suffer the same consequence as forgetting to update the fixed table. (ie. It just puts the fixed value in a different place, from what I see, for in-tree modules. Also, with a fixed table, they are all in one place, so it's easy to choose a non-colliding value?) > Reserve the value '0' to mean that kernel must assign the next unused > value >= 128. This is done to support out-of-tree modules. > > Might be, also reserve the value 0 to mean 'kernel > Main drawback is that is sounds complicated. ___ 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: fsid change of ZFS?
Kostik Belousov wrote: > On Tue, Aug 23, 2011 at 11:23:03PM +0200, Pawel Jakub Dawidek wrote: > > On Tue, Aug 23, 2011 at 04:11:20PM -0400, Rick Macklem wrote: > > > Pawel Jakub Dawidek wrote: > > > > On Tue, Aug 23, 2011 at 10:09:41AM -0400, Rick Macklem wrote: > > > > > Ok, I'll admit I wasn't very fond of a fixed table that would > > > > > inevitably > > > > > get out of date someday, either. > > > > > > > > > > I didn't think hashing for the cases not in the table was > > > > > worth the > > > > > effort, > > > > > but doing a hash instead of a table seems reasonable. > > > > > > > > > > I see that ZFS only uses the low order 8 bits, so I'll try and > > > > > come > > > > > up > > > > > with an 8bit hash solution and will post a patch for > > > > > testing/review > > > > > soon. > > > > > > > > > > I don't think the vfs_sysctl() is that great a concern, given > > > > > that > > > > > it > > > > > appears to be deprecated already anyhow. (With an 8bit hash, > > > > > vfs_typenum > > > > > won't be that sparse.) I'll also make sure that whatever hash > > > > > I use > > > > > doesn't collide for the current list of file names (although I > > > > > will > > > > > include > > > > > code that handles a collision in the patch). > > > > > > > > Sounds great. Thanks! > > > > > > > Here's the patch. (Hiroki could you please test this, thanks, > > > rick.) > > > ps: If the white space gets trashed, the same patch is at: > > >http://people.freebsd.org/~rmacklem/fsid.patch > > > > The patch is fine by me. Thanks, Rick! > > Sorry, I am late. > > It seems that the probability of the collisions for the hash is quite > high. > Due to the fixup procedure, the resulting typenum will depend on the > order > of the module initialization, isn't it ? IMO, it makes the patch goal > not > met. Well, the about 15 file system types currently in FreeBSD don't collide. (At least with the patch I posted. I'll test it again with "hash & 0xff;".) Also, since the collision results in the second one using the next higher value (usually, until you get something like 50+ file system types), it works for those cases unless the order that these 2 file systems call vfs_register() is reversed. (The likelyhood of this reversal is lower than the likelyhood of vfs_register() just being called in a different order, I think?) Since it now changes whenever a different kernel config or different module loading order is used and there aren't a lot of complaints, I think "usually works" is good enough. However, it doesn't matter to me, so I'll let others decide. Yet another option is to go back to what hrs@ originally suggested, which was change ZFS to not use vfc_typenum in its fsid. (I now see that 0 won't conflict with any assigned vfc_typenum values, since they start at 1 and 255 would also probably be safe, since its unlikely there ever will be 255 different file system types.) The problem with this is no future FS can use the same trick. ___ 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: fsid change of ZFS?
On Wed, Aug 24, 2011 at 09:34:58PM +0900, Hiroki Sato wrote: > Kostik Belousov wrote > in <20110824082119.gj17...@deviant.kiev.zoral.com.ua>: > > ko> On Tue, Aug 23, 2011 at 11:23:03PM +0200, Pawel Jakub Dawidek wrote: > ko> > On Tue, Aug 23, 2011 at 04:11:20PM -0400, Rick Macklem wrote: > ko> > > Pawel Jakub Dawidek wrote: > ko> > > > On Tue, Aug 23, 2011 at 10:09:41AM -0400, Rick Macklem wrote: > ko> > > > > Ok, I'll admit I wasn't very fond of a fixed table that would > ko> > > > > inevitably > ko> > > > > get out of date someday, either. > ko> > > > > > ko> > > > > I didn't think hashing for the cases not in the table was worth > the > ko> > > > > effort, > ko> > > > > but doing a hash instead of a table seems reasonable. > ko> > > > > > ko> > > > > I see that ZFS only uses the low order 8 bits, so I'll try and > come > ko> > > > > up > ko> > > > > with an 8bit hash solution and will post a patch for > testing/review > ko> > > > > soon. > ko> > > > > > ko> > > > > I don't think the vfs_sysctl() is that great a concern, given that > ko> > > > > it > ko> > > > > appears to be deprecated already anyhow. (With an 8bit hash, > ko> > > > > vfs_typenum > ko> > > > > won't be that sparse.) I'll also make sure that whatever hash I > use > ko> > > > > doesn't collide for the current list of file names (although I > will > ko> > > > > include > ko> > > > > code that handles a collision in the patch). > ko> > > > > ko> > > > Sounds great. Thanks! > ko> > > > > ko> > > Here's the patch. (Hiroki could you please test this, thanks, rick.) > ko> > > ps: If the white space gets trashed, the same patch is at: > ko> > >http://people.freebsd.org/~rmacklem/fsid.patch > ko> > > ko> > The patch is fine by me. Thanks, Rick! > ko> > ko> Sorry, I am late. > ko> > ko> It seems that the probability of the collisions for the hash is quite > high. > ko> Due to the fixup procedure, the resulting typenum will depend on the order > ko> of the module initialization, isn't it ? IMO, it makes the patch goal not > ko> met. > > I tried the following two experiments (the complete results are > attached) to confirm the probability: > > 1. [fsidhash1.txt] > well-known vfc_name and the names "[a-z]fs" (# of names is 36) > with no fix-up recalculation. > > 2. [fsidhash2.txt] > well-known vfc_name and the names "[a-z][a-z]fs" (# of names is 710) > with no fix-up recalculation. > > There is no collision in the case 1. And when [a-z][a-z]fs are > included the average number of the collided names in the same hash > value is 4.43 (i.e. 160 different hash values are generated, the > theoretical best number is (710 entries / 256 buckets) = 2.77). > > At least, vfc_names we currently have in our kernel code have no > collision, fortunately. As you noticed "[a-z][a-z]fs" is an > impractical data set and these results cannot explain the > characteristics for all possible and practical vfc_names, so whether > this hash is reasonable or not depends on how we think of them. > Comments or other better idea? Might be, add a new byte field to struct vfsconf, containing the suggested byte to be used by fsid. Divide the namespace into two half by the highest bit 7. Use the byte values with the highest bit clear for statically assignment for in-tree modules. Kernel will still check for the uniquiness on initialization. Reserve the value '0' to mean that kernel must assign the next unused value >= 128. This is done to support out-of-tree modules. Might be, also reserve the value 0 to mean 'kernel Main drawback is that is sounds complicated. pgpF1ekzuaUOK.pgp Description: PGP signature
Re: fsid change of ZFS?
Kostik Belousov wrote in <20110824082119.gj17...@deviant.kiev.zoral.com.ua>: ko> On Tue, Aug 23, 2011 at 11:23:03PM +0200, Pawel Jakub Dawidek wrote: ko> > On Tue, Aug 23, 2011 at 04:11:20PM -0400, Rick Macklem wrote: ko> > > Pawel Jakub Dawidek wrote: ko> > > > On Tue, Aug 23, 2011 at 10:09:41AM -0400, Rick Macklem wrote: ko> > > > > Ok, I'll admit I wasn't very fond of a fixed table that would ko> > > > > inevitably ko> > > > > get out of date someday, either. ko> > > > > ko> > > > > I didn't think hashing for the cases not in the table was worth the ko> > > > > effort, ko> > > > > but doing a hash instead of a table seems reasonable. ko> > > > > ko> > > > > I see that ZFS only uses the low order 8 bits, so I'll try and come ko> > > > > up ko> > > > > with an 8bit hash solution and will post a patch for testing/review ko> > > > > soon. ko> > > > > ko> > > > > I don't think the vfs_sysctl() is that great a concern, given that ko> > > > > it ko> > > > > appears to be deprecated already anyhow. (With an 8bit hash, ko> > > > > vfs_typenum ko> > > > > won't be that sparse.) I'll also make sure that whatever hash I use ko> > > > > doesn't collide for the current list of file names (although I will ko> > > > > include ko> > > > > code that handles a collision in the patch). ko> > > > ko> > > > Sounds great. Thanks! ko> > > > ko> > > Here's the patch. (Hiroki could you please test this, thanks, rick.) ko> > > ps: If the white space gets trashed, the same patch is at: ko> > >http://people.freebsd.org/~rmacklem/fsid.patch ko> > ko> > The patch is fine by me. Thanks, Rick! ko> ko> Sorry, I am late. ko> ko> It seems that the probability of the collisions for the hash is quite high. ko> Due to the fixup procedure, the resulting typenum will depend on the order ko> of the module initialization, isn't it ? IMO, it makes the patch goal not ko> met. I tried the following two experiments (the complete results are attached) to confirm the probability: 1. [fsidhash1.txt] well-known vfc_name and the names "[a-z]fs" (# of names is 36) with no fix-up recalculation. 2. [fsidhash2.txt] well-known vfc_name and the names "[a-z][a-z]fs" (# of names is 710) with no fix-up recalculation. There is no collision in the case 1. And when [a-z][a-z]fs are included the average number of the collided names in the same hash value is 4.43 (i.e. 160 different hash values are generated, the theoretical best number is (710 entries / 256 buckets) = 2.77). At least, vfc_names we currently have in our kernel code have no collision, fortunately. As you noticed "[a-z][a-z]fs" is an impractical data set and these results cannot explain the characteristics for all possible and practical vfc_names, so whether this hash is reasonable or not depends on how we think of them. Comments or other better idea? -- Hiroki 0x09 = tfs 0x0b = tmpfs 0x0f = ifs 0x1f = xfs 0x24 = mfs 0x2a = bfs 0x39 = qfs 0x3b = msdosfs 0x3f = ffs 0x45 = ntfs 0x4e = ufs 0x54 = jfs 0x64 = yfs 0x69 = nfs 0x6f = cfs 0x7e = rfs 0x81 = devfs 0x84 = gfs 0x87 = ext2fs 0x89 = procfs 0x94 = vfs 0x99 = kfs 0x9c = hpfs 0xa1 = cd9660 0xa9 = zfs 0xae = ofs 0xb4 = dfs 0xc3 = sfs 0xca = hfs 0xcb = reiserfs 0xd9 = wfs 0xdf = lfs 0xe5 = afs 0xf4 = pfs 0xfa = efs 0xfe = udf 0x00 = awfs, difs, infs, nsfs, qefs, sxfs, vjfs 0x02 = owfs 0x03 = emfs, jrfs, mdfs, rifs, wnfs 0x05 = fqfs, smfs 0x06 = alfs, icfs, kvfs, nhfs, xrfs 0x08 = jgfs, wcfs 0x09 = bpfs, ebfs, gufs, lzfs, olfs, tfs, tqfs, yvfs 0x0b = aafs, tmpfs, zzfs 0x0c = ctfs, fffs, hyfs, kkfs, ppfs, sbfs, uufs, xgfs 0x0e = dxfs, qtfs 0x0f = befs, gjfs, ifs, lofs, oafs, tffs, vyfs, ykfs 0x11 = hnfs, ujfs 0x12 = cifs, msfs, pefs, rxfs, zofs 0x14 = ldfs 0x15 = dmfs, irfs, nwfs, qifs, vnfs 0x18 = eqfs, hcfs, jvfs, mhfs, rmfs, wrfs, zdfs 0x1a = fufs, sqfs 0x1b = apfs, dbfs, igfs, kzfs, nlfs, vcfs, xvfs 0x1d = jkfs 0x1e = btfs, effs, gyfs, opfs, rbfs, tufs, wgfs, yzfs 0x1f = xfs 0x20 = aefs, nafs 0x21 = cxfs, fjfs, kofs, ptfs, sffs, uyfs, xkfs 0x24 = bifs, gnfs, lsfs, mfs, oefs, qxfs, tjfs, yofs 0x26 = hrfs 0x27 = cmfs, kdfs, mwfs, pifs, unfs, zsfs 0x2a = bfs, dqfs, gcfs, ivfs, lhfs, qmfs, vrfs, ydfs 0x2c = cbfs 0x2d = eufs, hgfs, jzfs, mlfs, rqfs, ucfs, wvfs, zhfs 0x2f = fyfs 0x30 = atfs, dffs, ikfs, npfs, qbfs, sufs, vgfs, xzfs 0x33 = bxfs, ejfs, jofs, mafs, otfs, rffs, tyfs, wkfs 0x36 = aifs, fnfs, ksfs, nefs, pxfs, sjfs, xofs 0x39 = bmfs, grfs, jdfs, lwfs, oifs, qfs, tnfs, ysfs 0x3b = msdosfs 0x3c = cqfs, fcfs, hvfs, khfs, pmfs, urfs, xdfs, zwfs 0x3f = bbfs, dufs, ffs, ggfs, izfs, llfs, qqfs, tcfs, vvfs, yhfs 0x42 = eyfs, hkfs, mpfs, pbfs, rufs, ugfs, wzfs, zlfs 0x43 = cffs 0x45 = axfs, djfs, iofs, lafs, ntfs, qffs, syfs, vkfs 0x48 = enfs, jsfs, mefs, oxfs, rjfs, wofs, zafs 0x4b = frfs, idfs, kwfs, nifs, snfs, xsfs 0x4c = amfs 0x4e = bqfs, gvfs, jhfs, omfs, trfs, ufs, wdfs, ywfs 0x4f = ecfs 0x51 = abfs, cufs, fgfs, hzfs, klfs, pqfs, scfs, uvfs, xhfs 0x54 = bffs, dyfs, gkfs, jfs, lpfs, obfs, qu
Re: fsid change of ZFS?
On Tue, Aug 23, 2011 at 11:23:03PM +0200, Pawel Jakub Dawidek wrote: > On Tue, Aug 23, 2011 at 04:11:20PM -0400, Rick Macklem wrote: > > Pawel Jakub Dawidek wrote: > > > On Tue, Aug 23, 2011 at 10:09:41AM -0400, Rick Macklem wrote: > > > > Ok, I'll admit I wasn't very fond of a fixed table that would > > > > inevitably > > > > get out of date someday, either. > > > > > > > > I didn't think hashing for the cases not in the table was worth the > > > > effort, > > > > but doing a hash instead of a table seems reasonable. > > > > > > > > I see that ZFS only uses the low order 8 bits, so I'll try and come > > > > up > > > > with an 8bit hash solution and will post a patch for testing/review > > > > soon. > > > > > > > > I don't think the vfs_sysctl() is that great a concern, given that > > > > it > > > > appears to be deprecated already anyhow. (With an 8bit hash, > > > > vfs_typenum > > > > won't be that sparse.) I'll also make sure that whatever hash I use > > > > doesn't collide for the current list of file names (although I will > > > > include > > > > code that handles a collision in the patch). > > > > > > Sounds great. Thanks! > > > > > Here's the patch. (Hiroki could you please test this, thanks, rick.) > > ps: If the white space gets trashed, the same patch is at: > >http://people.freebsd.org/~rmacklem/fsid.patch > > The patch is fine by me. Thanks, Rick! Sorry, I am late. It seems that the probability of the collisions for the hash is quite high. Due to the fixup procedure, the resulting typenum will depend on the order of the module initialization, isn't it ? IMO, it makes the patch goal not met. pgpvKs4ptQOnr.pgp Description: PGP signature
Re: Failure with 9.0 Beta1
On Tuesday 23 August 2011 23:24:30 Conrad J. Sabatier wrote: > On Tue, 23 Aug 2011 23:08:17 -0800 > > Beech Rintoul wrote: > > Trying to build today's current I get the following: > > > > cc -O2 -pipe -DATJOB_DIR=\"/var/at/jobs/\" - > > DLFILE=\"/var/at/jobs/.lockfile\" -DLOADAVG_MX=1.5 - > > DATSPOOL_DIR=\"/var/at/spool\" -DVERSION=\"2.9\" -DDAEMON_UID=1 - > > DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\' - > > DPERM_PATH=\"/var/at/\" -I/usr/src/libexec/atrun/../../usr.bin/at - > > I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 > > -fstack-protector - Wsystem-headers -Werror -Wall -Wno-format-y2k > > -Wno-uninitialized -Wno-pointer- sign -o atrun atrun.o gloadavg.o > > -lpam -lutil /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined > > reference to `_nsyylex' /usr/obj/usr/src/tmp/usr/lib/libc.so: > > undefined reference to > > `_nsyyin' /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference > > to `_nsyytext' /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined > > reference to `_nsyyerror' /usr/obj/usr/src/tmp/usr/lib/libc.so: > > undefined reference to `_nsyylineno' *** Error code 1 > > > > uname -a > > FreeBSD pinnacle.akherb.com 9.0-BETA1 FreeBSD 9.0-BETA1 #3: Fri Aug > > 12 22:55:05 AKDT 2011 > > r...@pinnacle.akherb.com:/usr/obj/usr/src/sys/PINNACLE i386 > > > > I'm not building with clang and the only references I get from google > > don't seem to have any answers. > > > > Beech > > There was a thread on this problem just a few weeks ago. Without going > into all of the technical explanations for what's happening, the short > answer is: build and install a new kernel (should work), reboot, *then* > do a buildworld. > > I can't recall the thread Subject: offhand, but it worked for me and > others, so it's "safe". If I think of the actual reference to point > you to, I'll let you know. > > Happy building. :-) Thanks, that's also what UPDATING implies. Beech -- --- Beech Rintoul - FreeBSD Developer - be...@freebsd.org /"\ ASCII Ribbon Campaign | FreeBSD Since 4.x \ / - NO HTML/RTF in e-mail | http://people.freebsd.org/~beech X - NO Word docs in e-mail | Skype: akbeech / \ - http://www.FreeBSD.org/releases/8.2R/announce.html --- ___ 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: Failure with 9.0 Beta1
On Tuesday 23 August 2011 23:43:14 Garrett Cooper wrote: > On Wed, Aug 24, 2011 at 12:08 AM, Beech Rintoul wrote: > > Trying to build today's current I get the following: > Please update to HEAD and read UPDATING @ 20110815. There are > several references in the archives last week and the week before to > this build failure. > Cheers, > -Garrett Thanks, I missed the second part of that post. Beech -- --- Beech Rintoul - FreeBSD Developer - be...@freebsd.org /"\ ASCII Ribbon Campaign | FreeBSD Since 4.x \ / - NO HTML/RTF in e-mail | http://people.freebsd.org/~beech X - NO Word docs in e-mail | Skype: akbeech / \ - http://www.FreeBSD.org/releases/8.2R/announce.html --- ___ 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: Failure with 9.0 Beta1
On Wed, Aug 24, 2011 at 12:08 AM, Beech Rintoul wrote: > Trying to build today's current I get the following: Please update to HEAD and read UPDATING @ 20110815. There are several references in the archives last week and the week before to this build failure. Cheers, -Garrett ___ 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"
Failure with 9.0 Beta1
Trying to build today's current I get the following: cc -O2 -pipe -DATJOB_DIR=\"/var/at/jobs/\" - DLFILE=\"/var/at/jobs/.lockfile\" -DLOADAVG_MX=1.5 - DATSPOOL_DIR=\"/var/at/spool\" -DVERSION=\"2.9\" -DDAEMON_UID=1 - DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\' - DPERM_PATH=\"/var/at/\" -I/usr/src/libexec/atrun/../../usr.bin/at - I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector - Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer- sign -o atrun atrun.o gloadavg.o -lpam -lutil /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyylex' /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyyin' /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyytext' /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyyerror' /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyylineno' *** Error code 1 uname -a FreeBSD pinnacle.akherb.com 9.0-BETA1 FreeBSD 9.0-BETA1 #3: Fri Aug 12 22:55:05 AKDT 2011 r...@pinnacle.akherb.com:/usr/obj/usr/src/sys/PINNACLE i386 I'm not building with clang and the only references I get from google don't seem to have any answers. Beech -- --- Beech Rintoul - FreeBSD Developer - be...@freebsd.org /"\ ASCII Ribbon Campaign | FreeBSD Since 4.x \ / - NO HTML/RTF in e-mail | http://people.freebsd.org/~beech X - NO Word docs in e-mail | Skype: akbeech / \ - http://www.FreeBSD.org/releases/8.2R/announce.html --- ___ 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"
