Re: core statement on fexecve, O_EXEC, and O_SEARCH

2012-12-04 Thread Michael van Elst
m...@netbsd.org (Emmanuel Dreyfus) writes: Alan Barrett a...@netbsd.org wrote: The fexecve function could be implemented entirely in libc, via execve(2) on a file name of the form /proc/self/fd/N. Any security concerns around fexecve() also apply to exec of /proc/self/fd/N. I gave a try

Re: core statement on fexecve, O_EXEC, and O_SEARCH

2012-12-04 Thread Alan Barrett
The fexecve function could be implemented entirely in libc, via execve(2) on a file name of the form /proc/self/fd/N. Any security concerns around fexecve() also apply to exec of /proc/self/fd/N. I gave a try to this approach. There is an unexpected issue: The descriptor is probably already

Re: core statement on fexecve, O_EXEC, and O_SEARCH

2012-12-04 Thread Julian Yon
On Tue, 4 Dec 2012 08:49:17 + (UTC) mlel...@serpens.de (Michael van Elst) wrote: The descriptor is probably already closed on exec before the syscall tries to use it. Nope. That happens later. I was looking through this code yesterday as the topic interests me. The namei lookup happens

Re: Problem identified: WAPL/RAIDframe performance problems

2012-12-04 Thread David Holland
On Sat, Dec 01, 2012 at 11:38:55PM -0500, Mouse wrote: things. What I care about is the largest size sector that will (in ^^^ the ordinary course of things anyway) be written atomically. Then those are 512-byte-sector drives [...] No; because

Re: Problem identified: WAPL/RAIDframe performance problems

2012-12-04 Thread David Holland
On Mon, Dec 03, 2012 at 12:19:58AM +, Julian Yon wrote: You appear to have just agreed with me, which makes me wonder what I'm missing, given you continue as though you disagree. You asked why 4096-byte-sector disks accept 512-byte writes. I was trying to explain. However, we're

Re: Problem identified: WAPL/RAIDframe performance problems

2012-12-04 Thread Thor Lancelot Simon
On Tue, Dec 04, 2012 at 02:14:27PM +, David Holland wrote: On Sat, Dec 01, 2012 at 11:38:55PM -0500, Mouse wrote: things. What I care about is the largest size sector that will (in ^^^ the ordinary course of things anyway) be written

Re: Problem identified: WAPL/RAIDframe performance problems

2012-12-04 Thread David Holland
On Tue, Dec 04, 2012 at 09:26:17AM -0500, Thor Lancelot Simon wrote: And, can't you do that with traditional drives, drives which really do have 512-byte sectors? Do a 4K transfer and you write 8 physical sectors with no opportunity for any other operation to see the write

Re: FFS write coalescing

2012-12-04 Thread David Holland
On Tue, Dec 04, 2012 at 09:59:46AM +0300, Alan Barrett wrote: the genfs code also never writes clean pages to disk, even though for RAID5 storage it would likely be more efficient to write clean pages that are in the same stripe as dirty pages if that would avoid issuing partial-stripe

Re: core statement on fexecve, O_EXEC, and O_SEARCH

2012-12-04 Thread David Holland
On Tue, Dec 04, 2012 at 01:58:13PM +, Julian Yon wrote: The descriptor is probably already closed on exec before the syscall tries to use it. Nope. That happens later. I was looking through this code yesterday as the topic interests me. The namei lookup happens pretty early on. I

Re: Making forced unmounts work

2012-12-04 Thread David Holland
On Sun, Dec 02, 2012 at 05:29:01PM +0100, J. Hannken-Illjes wrote: I'm convinced -- having fstrans_start() return ERESTART is the way to go. Ok then :-) Also I wonder if there's any way to accomplish this that doesn't require adding fstrans calls to every operation in every fs.

Re: core statement on fexecve, O_EXEC, and O_SEARCH

2012-12-04 Thread Robert Elz
Date:Tue, 4 Dec 2012 15:44:47 +0300 From:Alan Barrett a...@cequrux.com Message-ID: 20121204124447.gf8...@apb-laptoy.apb.alt.za | The fexecve function could be implemented entirely in libc, | via execve(2) on a file name of the form /proc/self/fd/N. | Any

Re: core statement on fexecve, O_EXEC, and O_SEARCH

2012-12-04 Thread Julian Yon
On Tue, 4 Dec 2012 15:30:36 + David Holland dholland-t...@netbsd.org wrote: On Tue, Dec 04, 2012 at 01:58:13PM +, Julian Yon wrote: The descriptor is probably already closed on exec before the syscall tries to use it. Nope. That happens later. I was looking through this

Re: Problem identified: WAPL/RAIDframe performance problems

2012-12-04 Thread David Laight
On Tue, Dec 04, 2012 at 02:57:52PM +, David Holland wrote: What's a kernel panic got to do with it? If you hand the controller and thus the drive 4K write, the kernel panicing won't suddenly cause you to reverse time and have issued 8 512-byte writes instead. That depends on

Re: wapbl_flush() speedup

2012-12-04 Thread Michael van Elst
hann...@eis.cs.tu-bs.de (J. Hannken-Illjes) writes: The attached diff tries to coalesce writes to the journal in MAXPHYS sized and aligned blocks. [...] Comments or objections anyone? + * Write data to the log. + * Try to coalesce writes and emit MAXPHYS aligned blocks. Looks fine, but I would

Re: wapbl_flush() speedup

2012-12-04 Thread Thor Lancelot Simon
On Tue, Dec 04, 2012 at 07:10:47PM +, Michael van Elst wrote: hann...@eis.cs.tu-bs.de (J. Hannken-Illjes) writes: The attached diff tries to coalesce writes to the journal in MAXPHYS sized and aligned blocks. [...] Comments or objections anyone? + * Write data to the log. + * Try to

Re: wapbl_flush() speedup

2012-12-04 Thread J. Hannken-Illjes
On Dec 4, 2012, at 8:10 PM, Michael van Elst mlel...@serpens.de wrote: hann...@eis.cs.tu-bs.de (J. Hannken-Illjes) writes: The attached diff tries to coalesce writes to the journal in MAXPHYS sized and aligned blocks. [...] Comments or objections anyone? + * Write data to the log. + *

Re: wapbl_flush() speedup

2012-12-04 Thread David Laight
On Tue, Dec 04, 2012 at 09:53:11PM +0100, J. Hannken-Illjes wrote: On Dec 4, 2012, at 8:10 PM, Michael van Elst mlel...@serpens.de wrote: hann...@eis.cs.tu-bs.de (J. Hannken-Illjes) writes: The attached diff tries to coalesce writes to the journal in MAXPHYS sized and aligned blocks.

Re: core statement on fexecve, O_EXEC, and O_SEARCH

2012-12-04 Thread Roland C. Dowdeswell
On Tue, Dec 04, 2012 at 11:42:04PM +0700, Robert Elz wrote: Even chroot isn't a problem, unless you're tempted to view it as some kind of security mechanism. It really isn't - it is just namespace modification. Sure, by modifying the filesystem namespace a bunch of simple security

Re: Broadcast traffic on vlans leaks into the parent interface on NetBSD-5.1

2012-12-04 Thread John Nemeth
On Apr 22, 5:50pm, Robert Elz wrote: } } Date:Thu, 29 Nov 2012 22:54:24 -0500 (EST) } From:Mouse mo...@rodents-montreal.org } Message-ID: 201211300354.waa22...@sparkle.rodents-montreal.org } } On the general VLAn topic, I agree with all Dennis said - leave the VLAN

Re: wapbl_flush() speedup

2012-12-04 Thread J. Hannken-Illjes
On Dec 4, 2012, at 10:11 PM, David Laight da...@l8s.co.uk wrote: On Tue, Dec 04, 2012 at 09:53:11PM +0100, J. Hannken-Illjes wrote: On Dec 4, 2012, at 8:10 PM, Michael van Elst mlel...@serpens.de wrote: hann...@eis.cs.tu-bs.de (J. Hannken-Illjes) writes: The attached diff tries to