Re: Add operation vcache_rekey

2014-06-25 Thread David Holland
On Wed, Jun 25, 2014 at 09:46:16AM +, Taylor R Campbell wrote: > Also, I wonder whether any file systems will ever change the length of > the key for a vnode. Probably not. As I recall from when I was looking at this a couple weeks ago (feels like a minor eternity ago, but it can't be much

Re: wm_intr may lead wm_start unexpectedly

2014-06-25 Thread Thor Lancelot Simon
On Wed, Jun 25, 2014 at 11:57:11AM +0200, Manuel Bouyer wrote: > On Wed, Jun 25, 2014 at 06:51:06PM +0900, Ryota Ozaki wrote: > > >> Any comments? > > > > > > why not change in6_if_link_up() to use a delay >= 1 instead of 0 ? > > > > My change intends to make it clear whether a callout will be use

re: Fix netbsd32's getfh()

2014-06-25 Thread Christos Zoulas
On Jun 26, 11:30am, m...@eterna.com.au (matthew green) wrote: -- Subject: re: Fix netbsd32's getfh() | | Christos Zoulas writes: | > Well, let's not propagate the evil design! I is is one thing having: | > | > void *p = malloc(n); | > free(p); | > | > where you know p is going to be NUL

re: Fix netbsd32's getfh()

2014-06-25 Thread matthew green
Christos Zoulas writes: > Well, let's not propagate the evil design! I is is one thing having: > > void *p = malloc(n); > free(p); > > where you know p is going to be NULL when it fails and another having: > > foo *p; > error = allocate_foo(&p); > free_foo(p); > >

Re: Fix netbsd32's getfh()

2014-06-25 Thread Christos Zoulas
In article <53ab0471.4080...@m00nbsd.net>, Maxime Villard wrote: >> >> That should probably be: >> >> return error; >> >> since vfs_composefh_alloc() failed, and we should not be calling >> vfs_composefh_free(). > >Yes, but no. Actually, vfs_composefh_free() handles NULL correctl

Re: Fix netbsd32's getfh()

2014-06-25 Thread Maxime Villard
Le 25/06/2014 17:28, Christos Zoulas a écrit : > In article <53aa91a3.1070...@m00nbsd.net>, > Maxime Villard wrote: >> Hi, >> Here is a patch to sync netbsd32 with the native getfh() syscall. In addition >> to making it consistent, it also: >> >> a) fixes the return value: >> } else

Re: Fix netbsd32's getfh()

2014-06-25 Thread Christos Zoulas
In article <53aa91a3.1070...@m00nbsd.net>, Maxime Villard wrote: >Hi, >Here is a patch to sync netbsd32 with the native getfh() syscall. In addition >to making it consistent, it also: > >a) fixes the return value: > } else if (error == E2BIG) { > error = copyou

Re: wm_intr may lead wm_start unexpectedly

2014-06-25 Thread Ryota Ozaki
On Wed, Jun 25, 2014 at 6:57 PM, Manuel Bouyer wrote: > On Wed, Jun 25, 2014 at 06:51:06PM +0900, Ryota Ozaki wrote: >> >> Any comments? >> > >> > why not change in6_if_link_up() to use a delay >= 1 instead of 0 ? >> >> My change intends to make it clear whether a callout will be used >> or not. I

Fix netbsd32's getfh()

2014-06-25 Thread Maxime Villard
Hi, Here is a patch to sync netbsd32 with the native getfh() syscall. In addition to making it consistent, it also: a) fixes the return value: } else if (error == E2BIG) { error = copyout(&sz, SCARG_P32(uap, fh_size), sizeof(size_t)); } h

Re: unification of boot.cfg parsing copies

2014-06-25 Thread Tyler Retzlaff
hey, On Wed, Jun 25, 2014 at 02:01:02AM +, Christos Zoulas wrote: > > Looks good at first glance. I would change all exported names to start > with bootcfg_ and BOOTCFG_; most of them do already. i'm glad you suggested this this. all new names were prefixed with bootcfg_ and BOOTCFG_ respec

Re: Add operation vcache_rekey

2014-06-25 Thread Taylor R Campbell
Date: Wed, 25 Jun 2014 12:04:30 +0200 From: "J. Hannken-Illjes" Using "memcpy(__UNCONST(node->vn_key.vk_key), new_key, new_key_len)" works but I'm not sure if __UNCONST is the right way to go. I think __UNCONST is the right way to go -- removing const from the API itself is certainly

Re: Add operation vcache_rekey

2014-06-25 Thread J. Hannken-Illjes
On 25 Jun 2014, at 11:46, Taylor R Campbell wrote: > Date: Wed, 25 Jun 2014 11:24:16 +0200 > From: "J. Hannken-Illjes" > > The attached diff adds a new vcache operation > > void > vcache_rekey(struct mount *mp, void *old_key, size_t old_key_len, > void

Re: wm_intr may lead wm_start unexpectedly

2014-06-25 Thread Manuel Bouyer
On Wed, Jun 25, 2014 at 06:51:06PM +0900, Ryota Ozaki wrote: > >> Any comments? > > > > why not change in6_if_link_up() to use a delay >= 1 instead of 0 ? > > My change intends to make it clear whether a callout will be used > or not. I think it's error-prone. for me, it's clear that a timeout of

Re: wm_intr may lead wm_start unexpectedly

2014-06-25 Thread Ryota Ozaki
On Wed, Jun 25, 2014 at 4:30 PM, Manuel Bouyer wrote: > On Wed, Jun 25, 2014 at 02:43:16PM +0900, Ryota Ozaki wrote: >> Hi, >> >> I found a strange behavior of if_wm that >> its interrupt handler may call its if_start >> (xmit function) eventually. I don't think >> it's sane. It makes difficult to

Re: Add operation vcache_rekey

2014-06-25 Thread Taylor R Campbell
Date: Wed, 25 Jun 2014 11:24:16 +0200 From: "J. Hannken-Illjes" The attached diff adds a new vcache operation void vcache_rekey(struct mount *mp, void *old_key, size_t old_key_len, void *new_key, size_t new_key_len) to atomically change the key o

Add operation vcache_rekey

2014-06-25 Thread J. Hannken-Illjes
The attached diff adds a new vcache operation void vcache_rekey(struct mount *mp, void *old_key, size_t old_key_len, void *new_key, size_t new_key_len) to atomically change the key of a cached vnode. As the key is no longer constant remove "const" from all key argumen

Re: wm_intr may lead wm_start unexpectedly

2014-06-25 Thread Manuel Bouyer
On Wed, Jun 25, 2014 at 02:43:16PM +0900, Ryota Ozaki wrote: > Hi, > > I found a strange behavior of if_wm that > its interrupt handler may call its if_start > (xmit function) eventually. I don't think > it's sane. It makes difficult to use mutex for MP. > > Here is a call trace: > wm_intr => wm_