Re: /var/lock
On Tue, Jan 04, 2011 at 05:23:08 +, David Holland wrote: > On Tue, Jan 04, 2011 at 02:58:18AM +0100, Adam Hamsik wrote: > > > Are they really *lock* files? > > > > It's lvm subsystem lock file. Does it need to be specific in any way ? > > If it's really a lock file that may need to persist across reboots, then > > > 2) /var/spool/lock/lvm > > is the right place. Ugh. What does it have to do with spooling? -uwe
Re: CVS commit: src/sys/uvm
Matt Thomas modified UVM colour matching scheme; Modified Files: src/sys/uvm: uvm_extern.h uvm_fault.c uvm_km.c uvm_page.c Log Message: Add better color matching selecting free pages. KM pages will now allocated so that VA and PA have the same color. On a page fault, choose a physical page that has the same color as the virtual address. This change is a big forward-reap to have VIPT-safe NetBSD VM for R4000 and modern ARM. Combined with matched KVA selection against UVA, found in vm_machdep.c::vmapbuf(), there remains little ocasion where VM chooses mistakenly wrong colour combination to bind VPN and PFN. The entire effect is to eliminate the necessity of VIPT fixup efforts in port-specific pmap.c and ends up with improving the cache effeciency in large degree. This is _the intent_behind VIPT design. So far OS virtual memory strategy paid little attention to make VIPT cache work correctly. Toru Nishimura / ALKYL Technology
Re: CVS commit: src/sys/uvm
On 1/4/11 2:26 AM, Matt Thomas wrote: > Module Name: src > Committed By: matt > Date: Tue Jan 4 08:26:33 UTC 2011 > > Modified Files: > src/sys/uvm: uvm_extern.h uvm_fault.c uvm_km.c uvm_page.c > > Log Message: ... > When allocating kernel memory pages, allow the MD to specify a preferred > VM_FREELIST from which to choose pages. For machines with large amounts > of memory (> 4GB), all kernel memory to come from <4GB to reduce the amount > of bounce buffering needed with 32bit DMA devices. Sorry to be clueless here, but does this mean I lose my large, automatic disk cache on my 32GB machine, or is this just for other types of memory purposes? --Michael
Re: CVS commit: src/sys/uvm
On Jan 4, 2011, at 2:19 AM, Michael Graff wrote: > On 1/4/11 2:26 AM, Matt Thomas wrote: >> Module Name: src >> Committed By:matt >> Date:Tue Jan 4 08:26:33 UTC 2011 >> >> Modified Files: >> src/sys/uvm: uvm_extern.h uvm_fault.c uvm_km.c uvm_page.c >> >> Log Message: > ... >> When allocating kernel memory pages, allow the MD to specify a preferred >> VM_FREELIST from which to choose pages. For machines with large amounts >> of memory (> 4GB), all kernel memory to come from <4GB to reduce the amount >> of bounce buffering needed with 32bit DMA devices. > > Sorry to be clueless here, but does this mean I lose my large, automatic > disk cache on my 32GB machine, or is this just for other types of memory > purposes? Not really. A lot of device can only do 32bit DMA transfers so without some type assistance (like the alpha has) you are restricted to DMA to the first 4GB of RAM. If you are doing DMA to an address >= 4GB, the system will stage the data in a buffer < 4GB for the DMA and then move the data to its ultimate destination (for a read). For a write it copies to the "bounce" buffer, and then does a DMA. The point is if you are allocating a mbuf or a usb buffer, it makes sense to allocate from the first 4GB if you can to avoid using bounce buffers. It's just a preference.
Re: CVS commit: src/crypto/external/bsd/openssh/dist
On Mon Jan 03 2011 at 18:55:42 +, Arnaud Ysmal wrote: > Module Name: src > Committed By: stacktic > Date: Mon Jan 3 18:55:42 UTC 2011 > > Modified Files: > src/crypto/external/bsd/openssh/dist: sshconnect2.c > > Log Message: > Fixed strvisx usage Didn't you fix that already once before? Can the fix be upstreamed? -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/sys/compat/netbsd32
On Tue, 4 Jan 2011, Matt Thomas wrote: Module Name:src Committed By: matt Date: Tue Jan 4 10:59:29 UTC 2011 Modified Files: src/sys/compat/netbsd32: files.netbsd32 netbsd32_sa.c Log Message: Make the SA support as optional as is possible. This commit appears to have broken the build, at least on port-amd64: #create compat_netbsd32/netbsd32_sa.d CC=/test-bed/tools/bin/x86_64--netbsd-gcc /test-bed/tools/bin/nbmkdep -f netbsd32_sa.d -- -I/test-bed/src/common/include -DSYSVSHM -DSYSVSEM -DSYSVMSG -DCOMPAT_NETBSD32 -DEXEC_ELF32 -DEXEC_ELF64 -DEXEC_AOUT -DP1003_1B_SEMAPHORE -DCOREDUMP -I/test-bed/src/common/include -nostdinc -I. -I/test-bed/src/sys/modules/compat_netbsd32 -isystem /test-bed/src/sys -isystem /test-bed/src/sys/arch -isystem /test-bed/src/sys/../common/include -D_KERNEL -D_LKM -D_MODULE -std=gnu99 /test-bed/src/sys/compat/netbsd32/netbsd32_sa.c /test-bed/src/sys/compat/netbsd32/netbsd32_sa.c:37:31: error: opt_compat_netbsd.h: No such file or directory /test-bed/src/sys/compat/netbsd32/netbsd32_sa.c:38:20: error: opt_sa.h: No such file or directory nbmkdep: compile failed. - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: CVS commit: src/sys/dev/acpi
Looks reasonable to me.
In the man-page update, please refer to "an already scheduled function"
(insert the word "an").
On Tue, 4 Jan 2011, Jukka Ruohonen wrote:
On Tue, Jan 04, 2011 at 05:48:49AM +, Jukka Ruohonen wrote:
"Do not queue functions via sysmon_taskq(9) in the pmf(9) resume hooks.
There is a small and unlikely race when the drivers are loaded as modules;
suspend, resume, queue a function, and immediately unload the module."
Anything against adding for instance the following to sysmon_taskq(9)? Or
better ideas how this should be handled?
- Jukka.
Index: sysmon_taskq.c
===
RCS file: /cvsroot/src/sys/dev/sysmon/sysmon_taskq.c,v
retrieving revision 1.14
diff -u -p -r1.14 sysmon_taskq.c
--- sysmon_taskq.c 5 Sep 2008 22:06:52 - 1.14
+++ sysmon_taskq.c 4 Jan 2011 06:17:45 -
@@ -209,3 +209,30 @@ sysmon_task_queue_sched(u_int pri, void
return 0;
}
+
+/*
+ * sysmon_task_queue_cancel:
+ *
+ * Cancel a scheduled task.
+ */
+int
+sysmon_task_queue_cancel(void (*func)(void *))
+{
+ struct sysmon_task *st;
+
+ if (func == NULL)
+ return EINVAL;
+
+ mutex_enter(&sysmon_task_queue_mtx);
+ TAILQ_FOREACH(st, &sysmon_task_queue, st_list) {
+ if (st->st_func == func) {
+ TAILQ_REMOVE(&sysmon_task_queue, st, st_list);
+ mutex_exit(&sysmon_task_queue_mtx);
+ free(st, M_TEMP);
+ mutex_enter(&sysmon_task_queue_mtx);
+ }
+ }
+ mutex_exit(&sysmon_task_queue_mtx);
+
+ return 0;
+}
Index: sysmon_taskq.h
===
RCS file: /cvsroot/src/sys/dev/sysmon/sysmon_taskq.h,v
retrieving revision 1.2
diff -u -p -r1.2 sysmon_taskq.h
--- sysmon_taskq.h 21 Jul 2007 23:15:17 - 1.2
+++ sysmon_taskq.h 4 Jan 2011 06:17:45 -
@@ -42,5 +42,6 @@ void sysmon_task_queue_preinit(void);
voidsysmon_task_queue_init(void);
voidsysmon_task_queue_fini(void);
int sysmon_task_queue_sched(u_int, void (*)(void *), void *);
+intsysmon_task_queue_cancel(void (*func)(void *));
#endif /* _DEV_SYSMON_SYSMON_TASKQ_H_ */
Index: sysmon_taskq.9
===
RCS file: /cvsroot/src/share/man/man9/sysmon_taskq.9,v
retrieving revision 1.6
diff -u -p -r1.6 sysmon_taskq.9
--- sysmon_taskq.9 26 Jan 2010 08:48:39 - 1.6
+++ sysmon_taskq.9 4 Jan 2011 06:18:23 -
@@ -43,6 +43,8 @@
.Fn sysmon_task_queue_fini "void"
.Ft int
.Fn sysmon_task_queue_sched "u_int pri" "void (*func)(void *)" "void *arg"
+.Ft int
+.Fn sysmon_task_queue_cancel "void (*func)(void *)"
.Sh DESCRIPTION
The machine-independent
.Nm
@@ -78,10 +80,15 @@ The single argument passed to
.Fa func
is specified by
.Fa arg .
+The
+.Fn sysmon_task_queue_cancel
+function can be used to cancel the execution of already scheduled function.
.Sh RETURN VALUES
-Upon successful completion,
+Both
.Fn sysmon_task_queue_sched
-returns 0.
+and
+.Fn sysmon_task_queue_cancel
+return 0 upon successful completion,
Otherwise, the following error values are returned:
.Bl -tag -width [EINVAL]
.It Bq Er EINVAL
!DSPAM:4d22bca92344589720801!
-
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer | | pgoyette at netbsd.org |
-
Re: CVS commit: src/sys/dev/acpi
Jukka Ruohonen wrote:
> +/*
> + * sysmon_task_queue_cancel:
> + *
> + * Cancel a scheduled task.
> + */
> +int
> +sysmon_task_queue_cancel(void (*func)(void *))
> +{
> + struct sysmon_task *st;
> +
> + if (func == NULL)
> + return EINVAL;
> +
> + mutex_enter(&sysmon_task_queue_mtx);
> + TAILQ_FOREACH(st, &sysmon_task_queue, st_list) {
> + if (st->st_func == func) {
> + TAILQ_REMOVE(&sysmon_task_queue, st, st_list);
> + mutex_exit(&sysmon_task_queue_mtx);
> + free(st, M_TEMP);
> + mutex_enter(&sysmon_task_queue_mtx);
> + }
> + }
> + mutex_exit(&sysmon_task_queue_mtx);
1) There is a use-after-free. Hint: TAILQ_FOREACH_SAFE().
2) It is not safe; while lock is dropped, the 'next' entry may also
be removed and freed. Hint: have a local list and avoid relocking.
--
Mindaugas
Re: CVS commit: src/sys/uvm
On Tue, Jan 04, 2011 at 02:32:02AM -0800, Matt Thomas wrote: > Not really. A lot of device can only do 32bit DMA transfers so without some > type assistance (like the alpha has) you are restricted to DMA to the first > 4GB of RAM. If you are doing DMA to an address >= 4GB, the system will stage > the data in a buffer < 4GB for the DMA and then move the data to its ultimate > destination (for a read). For a write it copies to the "bounce" buffer, and > then does a DMA. > > The point is if you are allocating a mbuf or a usb buffer, it makes sense to > allocate from the first 4GB if you can to avoid using bounce buffers. > > It's just a preference. Is there some provision to always keep some <4GB pages free (with some being quite large for e.g. USB descriptors) so there is always some bounce buffers available ? AFAIK, if you allocate from the <4Gb free list, you can eat all DMA-capable RAM. I fixed this issue in arch/x86/x86/x86_machdep.c 1.37, I wonder if your change has reintroduced this problem ... -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: /var/lock
On Tue, 04 Jan 2011, Adam Hamsik wrote: > I would like to have something persistent between reboots. I > have found that we already have /var/spool/lock. Therefore > /var/spool/lock/lvm/ seems to be might preferred place. Do you agree ? I had forgotten about /var/spool/lock; it's been a long time since I used UUCP. Given that it exists, /var/spool/lock/lvm seems fine. > Also /var/spool/lock is not mentioned in hier. That should be fixed. --apb (Alan Barrett)
Re: CVS commit: src/sys/compat/netbsd32
The following patch seems to take care of things, at least on my amd64 machine. I'm not sure if this is the correct fix, so I will let someone else handle the commit! Index: netbsd32_sa.c === RCS file: /cvsroot/src/sys/compat/netbsd32/netbsd32_sa.c,v retrieving revision 1.12 diff -u -p -r1.12 netbsd32_sa.c --- netbsd32_sa.c 4 Jan 2011 10:59:28 - 1.12 +++ netbsd32_sa.c 4 Jan 2011 13:56:08 - @@ -34,8 +34,11 @@ #include __KERNEL_RCSID(0, "$NetBSD: netbsd32_sa.c,v 1.12 2011/01/04 10:59:28 matt Exp $"); + +#if defined(_KERNEL_OPT) #include "opt_compat_netbsd.h" #include "opt_sa.h" +#endif #include #include On Tue, 4 Jan 2011, Paul Goyette wrote: On Tue, 4 Jan 2011, Matt Thomas wrote: Module Name:src Committed By: matt Date: Tue Jan 4 10:59:29 UTC 2011 Modified Files: src/sys/compat/netbsd32: files.netbsd32 netbsd32_sa.c Log Message: Make the SA support as optional as is possible. This commit appears to have broken the build, at least on port-amd64: #create compat_netbsd32/netbsd32_sa.d CC=/test-bed/tools/bin/x86_64--netbsd-gcc /test-bed/tools/bin/nbmkdep -f netbsd32_sa.d -- -I/test-bed/src/common/include -DSYSVSHM -DSYSVSEM -DSYSVMSG -DCOMPAT_NETBSD32 -DEXEC_ELF32 -DEXEC_ELF64 -DEXEC_AOUT -DP1003_1B_SEMAPHORE -DCOREDUMP -I/test-bed/src/common/include -nostdinc -I. -I/test-bed/src/sys/modules/compat_netbsd32 -isystem /test-bed/src/sys -isystem /test-bed/src/sys/arch -isystem /test-bed/src/sys/../common/include -D_KERNEL -D_LKM -D_MODULE -std=gnu99 /test-bed/src/sys/compat/netbsd32/netbsd32_sa.c /test-bed/src/sys/compat/netbsd32/netbsd32_sa.c:37:31: error: opt_compat_netbsd.h: No such file or directory /test-bed/src/sys/compat/netbsd32/netbsd32_sa.c:38:20: error: opt_sa.h: No such file or directory nbmkdep: compile failed. - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | - - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: CVS commit: src/sys/dev/acpi
On Tue, Jan 04, 2011 at 12:52:57PM +, Mindaugas Rasiukevicius wrote: > 1) There is a use-after-free. Hint: TAILQ_FOREACH_SAFE(). > > 2) It is not safe; while lock is dropped, the 'next' entry may also > be removed and freed. Hint: have a local list and avoid relocking. Hmm. 2) implies that the whole sysmon_taskq(9) is not safe? - Jukka. PS. It is crazy to have "safe" and "unsafe" variants of these macros.
Re: CVS commit: src/sys/uvm
On Tue, Jan 04, 2011 at 06:25:12PM +0900, Toru Nishimura wrote: > Matt Thomas modified UVM colour matching scheme; > > >Modified Files: > > src/sys/uvm: uvm_extern.h uvm_fault.c uvm_km.c uvm_page.c > > > >Log Message: > >Add better color matching selecting free pages. KM pages will now allocated > >so that VA and PA have the same color. On a page fault, choose a physical > >page that has the same color as the virtual address. > > This change is a big forward-reap to have VIPT-safe NetBSD VM for R4000 and > modern ARM. Combined with matched KVA selection against UVA, found in > vm_machdep.c::vmapbuf(), there remains little ocasion where VM chooses > mistakenly wrong colour combination to bind VPN and PFN. > > The entire effect is to eliminate the necessity of VIPT fixup efforts in > port-specific > pmap.c and ends up with improving the cache effeciency in large degree. This > is _the intent_behind VIPT design. So far OS virtual memory strategy paid > little > attention to make VIPT cache work correctly. It'd be nice if we can really eliminate VIPT fixup *code* in pmaps. And I *think* this is possible if we don't remap pages using pmap_kenter_pa().
Re: CVS commit: src/sys/uvm
On Jan 4, 2011, at 4:57 AM, Manuel Bouyer wrote: > On Tue, Jan 04, 2011 at 02:32:02AM -0800, Matt Thomas wrote: >> Not really. A lot of device can only do 32bit DMA transfers so without some >> type assistance (like the alpha has) you are restricted to DMA to the first >> 4GB of RAM. If you are doing DMA to an address >= 4GB, the system will >> stage the data in a buffer < 4GB for the DMA and then move the data to its >> ultimate destination (for a read). For a write it copies to the "bounce" >> buffer, and then does a DMA. >> >> The point is if you are allocating a mbuf or a usb buffer, it makes sense to >> allocate from the first 4GB if you can to avoid using bounce buffers. >> >> It's just a preference. > > Is there some provision to always keep some <4GB pages free (with some being > quite large for e.g. USB descriptors) so there is always some bounce buffers > available ? AFAIK, if you allocate from the <4Gb free list, you can eat all > DMA-capable RAM. > I fixed this issue in arch/x86/x86/x86_machdep.c 1.37, I wonder if your change > has reintroduced this problem ... Since it's not turned on by default, I doubt it.
Re: CVS commit: src/sys/uvm
Masao Uebayashi responds as; The entire effect is to eliminate the necessity of VIPT fixup efforts in port-specific pmap.c and ends up with improving the cache effeciency in large degree. This is _the intent_ behind VIPT design. So far OS virtual memory strategy paid little attention to make VIPT cache work correctly. It'd be nice if we can really eliminate VIPT fixup *code* in pmaps. And I *think* this is possible if we don't remap pages using pmap_kenter_pa(). The VIPT rule is simple; just make sure to match colour between VPN and PFN. It's the mandatory programming practice. This rule is clearly documented in _many_ CPU architecture documents with VIPT cache. - mmap(2) must refuse to map mixed colour VA. - dynamic linker should pay attention to map share library at "colour boundary." This ensure cache lines shared between processes. Toru Nishimura / ALKYL Technology
Re: CVS commit: src/sys/uvm
On Tue, Jan 04, 2011 at 08:03:33AM -0800, Matt Thomas wrote: > > I fixed this issue in arch/x86/x86/x86_machdep.c 1.37, I wonder if your > > change > > has reintroduced this problem ... > > Since it's not turned on by default, I doubt it. I guess if you wrote it, you expect to use it for something :) in which cases do you intend to turn it on ? A kernel config option, or for some ports ? -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: CVS commit: src/sys/uvm
On Jan 4, 2011, at 8:33 AM, Manuel Bouyer wrote: > On Tue, Jan 04, 2011 at 08:03:33AM -0800, Matt Thomas wrote: >>> I fixed this issue in arch/x86/x86/x86_machdep.c 1.37, I wonder if your >>> change >>> has reintroduced this problem ... >> >> Since it's not turned on by default, I doubt it. > > I guess if you wrote it, you expect to use it for something :) > in which cases do you intend to turn it on ? A kernel config option, > or for some ports ? I turn it on for MIPS. BTW, MIPS has separate freelists for <512MB, <4GB, and then everything else.
Re: CVS commit: src/sys/uvm
On Tue, Jan 04, 2011 at 08:35:48AM -0800, Matt Thomas wrote: > > On Jan 4, 2011, at 8:33 AM, Manuel Bouyer wrote: > > > On Tue, Jan 04, 2011 at 08:03:33AM -0800, Matt Thomas wrote: > >>> I fixed this issue in arch/x86/x86/x86_machdep.c 1.37, I wonder if your > >>> change > >>> has reintroduced this problem ... > >> > >> Since it's not turned on by default, I doubt it. > > > > I guess if you wrote it, you expect to use it for something :) > > in which cases do you intend to turn it on ? A kernel config option, > > or for some ports ? > > I turn it on for MIPS. > > BTW, MIPS has separate freelists for <512MB, <4GB, and then everything else. OK, so the question remains for mips :) how do you prevent kernel memory from stealing all DMA-capable memory ? Or do maybe you expect to always have something free in the <512MB list ? BTW, x86 has <16MB, <4GB and everything else. the <16MB list was not enough to cover the bus_dma(9) needs. Maybe the <512MB list will, provided it's not already starved by other needs. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: CVS commit: src/crypto/external/bsd/openssh/dist
> On Mon Jan 03 2011 at 18:55:42 +, Arnaud Ysmal wrote: > > Module Name: src > > Committed By: stacktic > > Date: Mon Jan 3 18:55:42 UTC 2011 > > > > Modified Files: > > src/crypto/external/bsd/openssh/dist: sshconnect2.c > > > > Log Message: > > Fixed strvisx usage > > Didn't you fix that already once before? Can the fix be upstreamed? Yes I did. There is no problem upstream, they are using strnvis, which takes the length of the destination buffer as a parameter, while we are using strvisx, which takes the length of the input buffer. This fix should be part of the fixes we merge for each new version of openssh.
Re: /var/lock
On Tue, Jan 04, 2011 at 11:46:34AM +0300, Valeriy E. Ushakov wrote: > > > 2) /var/spool/lock/lvm > > > > is the right place. > > Ugh. What does it have to do with spooling? What do any locks have to do with spooling? Historically, /var/spool is for "stuff". Since then lots of things traditionally in /var/spool have been moved into /var, like /var/cron, /var/at, /var/rwho, and so forth, mostly for no clear reason but I guess because they don't have anything to do with "spooling", whatever that means. Anyway, the reason this whole thread started out with /var/lock is that the Linux world apparently also did this with /var/spool/lock. -- David A. Holland dholl...@netbsd.org
Re: /var/lock
On Jan,Tuesday 4 2011, at 8:56 AM, Alan Barrett wrote: > On Tue, 04 Jan 2011, Adam Hamsik wrote: >> I would like to have something persistent between reboots. I >> have found that we already have /var/spool/lock. Therefore >> /var/spool/lock/lvm/ seems to be might preferred place. Do you agree ? > > I had forgotten about /var/spool/lock; it's been a long time since I > used UUCP. Given that it exists, /var/spool/lock/lvm seems fine. > >> Also /var/spool/lock is not mentioned in hier. > > That should be fixed. Ok I will change it to /var/spool/lock/lvm tomorrow and I will update hier to mention those directories, too. Is that ok ? Regards Adam.
Re: /var/lock
On Tue, Jan 04, 2011 at 19:43:49 +, David Holland wrote: > On Tue, Jan 04, 2011 at 11:46:34AM +0300, Valeriy E. Ushakov wrote: > > > > 2) /var/spool/lock/lvm > > > > > > is the right place. > > > > Ugh. What does it have to do with spooling? > > What do any locks have to do with spooling? Historically, /var/spool > is for "stuff". Since then lots of things traditionally in /var/spool > have been moved into /var, like /var/cron, /var/at, /var/rwho, and so > forth, mostly for no clear reason but I guess because they don't have > anything to do with "spooling", whatever that means. > > Anyway, the reason this whole thread started out with /var/lock is > that the Linux world apparently also did this with /var/spool/lock. But our /var/spool/lock is specifically uucp's lockdir (uucp/daemon). Creating lvm subdir beneath is (owned by operator) feels monumentally gross. RHEL5 I have at work has /var/lock, with /var/lock/uucp being equivalent of our /var/spool/lock. -uwe
Re: /var/lock
On Tue, Jan 04, 2011 at 23:41:00 +0100, Adam Hamsik wrote: > Subject: Re: /var/lock > From: Adam Hamsik > Date: Tue, 4 Jan 2011 23:41:00 +0100 > Cc: source-changes-d@NetBSD.org > To: Alan Barrett > > > On Jan,Tuesday 4 2011, at 8:56 AM, Alan Barrett wrote: > > > On Tue, 04 Jan 2011, Adam Hamsik wrote: > >> I would like to have something persistent between reboots. I > >> have found that we already have /var/spool/lock. Therefore > >> /var/spool/lock/lvm/ seems to be might preferred place. Do you agree ? > > > > I had forgotten about /var/spool/lock; it's been a long time since I > > used UUCP. Given that it exists, /var/spool/lock/lvm seems fine. > > > >> Also /var/spool/lock is not mentioned in hier. > > > > That should be fixed. > > Ok I will change it to /var/spool/lock/lvm tomorrow and I will update > hier to mention those directories, too. Is that ok ? IMO, no. As I explained upthread, our /var/spool/lock is specifically for uucp, see its permissions. Please don't create /var/spool/lock/lvm -uwe
Re: /var/lock
On Jan,Wednesday 5 2011, at 12:13 AM, Valeriy E. Ushakov wrote: > On Tue, Jan 04, 2011 at 23:41:00 +0100, Adam Hamsik wrote: >> Subject: Re: /var/lock >> From: Adam Hamsik >> Date: Tue, 4 Jan 2011 23:41:00 +0100 >> Cc: source-changes-d@NetBSD.org >> To: Alan Barrett >> >> >> On Jan,Tuesday 4 2011, at 8:56 AM, Alan Barrett wrote: >> >>> On Tue, 04 Jan 2011, Adam Hamsik wrote: I would like to have something persistent between reboots. I have found that we already have /var/spool/lock. Therefore /var/spool/lock/lvm/ seems to be might preferred place. Do you agree ? >>> >>> I had forgotten about /var/spool/lock; it's been a long time since I >>> used UUCP. Given that it exists, /var/spool/lock/lvm seems fine. >>> Also /var/spool/lock is not mentioned in hier. >>> >>> That should be fixed. >> >> Ok I will change it to /var/spool/lock/lvm tomorrow and I will update >> hier to mention those directories, too. Is that ok ? > > IMO, no. As I explained upthread, our /var/spool/lock is specifically > for uucp, see its permissions. > > Please don't create /var/spool/lock/lvm Then please suggest another directory which is persistent between reboots and others are willing to accept it. Regards Adam.
Re: /var/lock
On Wed, Jan 05, 2011 at 00:43:11 +0100, Adam Hamsik wrote: > On Jan,Wednesday 5 2011, at 12:13 AM, Valeriy E. Ushakov wrote: > > > On Tue, Jan 04, 2011 at 23:41:00 +0100, Adam Hamsik wrote: > > > >> Ok I will change it to /var/spool/lock/lvm tomorrow and I will update > >> hier to mention those directories, too. Is that ok ? > > > > IMO, no. As I explained upthread, our /var/spool/lock is specifically > > for uucp, see its permissions. > > > > Please don't create /var/spool/lock/lvm > > Then please suggest another directory which is persistent between > reboots and others are willing to accept it. I have no idea what lvm locks are and what are they for and I don't remember you ever epxlained that in this thread. You also never explained why you ... would like to have something persistent between reboots. So, does lvm requre locks to persist reboots or not for correct operation? lvm.conf(5) says ... use flocks on files in locking_dir ... to avoid conflicting LVM2 commands running concurrently on a single machine. and flocks don't persist across reboots. -uwe
Re: CVS commit: src
On Wed, 5 Jan 2011, Jeff Rizzo wrote: Module Name:src Committed By: riz Date: Wed Jan 5 02:25:27 UTC 2011 Modified Files: src/distrib/sets/lists/tests: mi src/tests/sbin/resize_ffs: Makefile common.sh t_grow.sh t_shrink.sh Added Files: src/tests/sbin/resize_ffs: t_grow_swapped.sh t_shrink_swapped.sh Log Message: Update resize_ffs tests for byteswapped file system support, and for UFS2 growth support. Also, reduce the number of tests run by default while still maintaining decent coverage of features and block sizes. Anyone working on resize_Ffs should run the tests with RESIZE_FFS_ALL_TESTS set in the environment, which adds a lot more testing. Jeff, I'm wondering if maybe it would be "more correct" to use an atf variable (ie, atf-run -v RESIZE_FFS_ALL_TESTS=true) rather than something in the environment? As an example, take a look at my recent commit for src/tests/lib/libc/string/t_popcount.c To generate a diff of this commit: cvs rdiff -u -r1.206 -r1.207 src/distrib/sets/lists/tests/mi cvs rdiff -u -r1.2 -r1.3 src/tests/sbin/resize_ffs/Makefile cvs rdiff -u -r1.5 -r1.6 src/tests/sbin/resize_ffs/common.sh cvs rdiff -u -r1.6 -r1.7 src/tests/sbin/resize_ffs/t_grow.sh \ src/tests/sbin/resize_ffs/t_shrink.sh cvs rdiff -u -r0 -r1.1 src/tests/sbin/resize_ffs/t_grow_swapped.sh \ src/tests/sbin/resize_ffs/t_shrink_swapped.sh Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. !DSPAM:4d23d69d2341473314484! - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: CVS commit: src
On 1/4/11 6:32 PM, Paul Goyette wrote: On Wed, 5 Jan 2011, Jeff Rizzo wrote: Log Message: Update resize_ffs tests for byteswapped file system support, and for UFS2 growth support. Also, reduce the number of tests run by default while still maintaining decent coverage of features and block sizes. Anyone working on resize_Ffs should run the tests with RESIZE_FFS_ALL_TESTS set in the environment, which adds a lot more testing. Jeff, I'm wondering if maybe it would be "more correct" to use an atf variable (ie, atf-run -v RESIZE_FFS_ALL_TESTS=true) rather than something in the environment? As an example, take a look at my recent commit for src/tests/lib/libc/string/t_popcount.c Yeah, that's probably a better way to handle it. I'll look into doing that tomorrow. +j
Re: CVS commit: src/sys/uvm
hi,
> I take silence as "no objection".
the silence in this case means was-busy-for-other-things-and-forgot.
sorry.
>> I have no real code for this big picture at this moment. Making
>> vm_physseg available as reference is the first step. This only
>> changes uvm_page_physload() to return a pointer:
>>
>> -void uvm_page_physload();
>> +void *uvm_page_physload();
>>
>> But this makes XIP pager MUCH cleaner. The reason has been explained
>> many times.
because the separate uvm_page_physload_device is no longer necessary,
you mean? i have no problem with the step.
>> Making fault handlers and pagers to use vm_physseg * + off_t is
>> the next step, and I don't intend to work on it now. I just want
>> to explain the big picture.
>>
>> >
>> > >>
>> > >> Keep vm_physseg * + off_t array on stack. If UVM objects uses
>> > >> vm_page (e.g. vnode), its pager looks up vm_page -> vm_physseg *
>> > >> + off_t *once* and cache it on stack.
>> >
>> > do you mean something like this?
>> >struct {
>> >vm_physseg *hoge;
>> >off_t fuga;
>> >} foo [16];
>>
>> Yes.
>>
>> Or cache vm_page * with it, like:
>>
>> struct vm_id {
>> vm_physseg *seg;
>> off_t off;
>> vm_page *pg;
>> };
>>
>> uvm_fault()
>> {
>> vm_id pgs[];
>> :
>> }
>>
>> Vnode pager (genfs_getpages) takes vm_page's by looking up
>> vnode::v_uobj's list, or uvn_findpages().
>>
>> When it returns back to fault handler, we have to lookup vm_physseg
>> for each page. Then fill the "seg" slot above (assuming we'll
>> remove vm_page::phys_addr soon).
>>
>> Fault handler calls per-vm_page operations iff vm_page slot is filled.
>> XIP pages are not pageq'ed.
pgo_get returns either seg+off or pg for each vm_id slots?
>> XIP pages don't need vm_page, but
>> cached because it's vnode.
can you explain this sentence?
>> (Just in case, have you read my paper?)
which paper? i guess no.
YAMAMOTO Takashi
