headers
Joerg Sonnenberger | 1 Jan 2012 02:58
Picon

Re: NetBSD/usermode (Was: CVS commit: src)

On Sat, Dec 31, 2011 at 05:20:16PM +0000, David Holland wrote:
> The other obvious approach is to add one or more new ptrace operations
> to provide proper/adequate/better support for intercepting system
> calls. This is probably a more useful facility in the long run, and it
> *can* be made leakproof, but it'll be more work.

The missing piece is being able to modify the mapping of the debuggee.
Adding that is actually useful for a number of cases for a "normal"
debugger as well. Consider conditional break points. It would speed up
the processing a lot if a debugger could use JIT compilation and map the
conditional handling into the target process.

Joerg
Permalink | Reply | 0 comments |
headers
Emmanuel Dreyfus | 1 Jan 2012 19:05
Picon

UFS and POSIX test suite

Hi

There is a POSIX test suite here:
http://www.tuxera.com/community/posix-test-suite/

I intentend to use it to hunt bugs for NetBSD FUSE. Without any
surprise, there are a lot of failures, but I am a it surprised to see
that NetBSD UFS fails the same tests most of the time.

To give an exaample, the script detects that when an unprivilegied user
attempts to set the setGID bit, it should be cleared, while NetBSD UFS
returns EPERM.

And just clearing the bit indeed seems to be mandated by POSIX:
 http://pubs.opengroup.org/onlinepubs/7908799/xsh/chmod.html)

Opinions? Do we have bugs to fix here? Anyone already gave it a try?

--

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu <at> netbsd.org
Permalink | Reply | 3 comments |
headers
Roland C. Dowdeswell | 1 Jan 2012 19:12
Favicon

Re: UFS and POSIX test suite

On Sun, Jan 01, 2012 at 07:05:06PM +0100, Emmanuel Dreyfus wrote:
>

> I intentend to use it to hunt bugs for NetBSD FUSE. Without any
> surprise, there are a lot of failures, but I am a it surprised to see
> that NetBSD UFS fails the same tests most of the time.
> 
> To give an exaample, the script detects that when an unprivilegied user
> attempts to set the setGID bit, it should be cleared, while NetBSD UFS
> returns EPERM.
> 
> And just clearing the bit indeed seems to be mandated by POSIX:
>  http://pubs.opengroup.org/onlinepubs/7908799/xsh/chmod.html)
> 
> Opinions? Do we have bugs to fix here? Anyone already gave it a try?

It seems to me that either behaviour complies with the language
that you quote:

	If the calling process does not have appropriate privileges,
	and if the group ID of the file does not match the effective
	group ID or one of the supplementary group IDs and if the
	file is a regular file, bit S_ISGID (set-group-ID on
	execution) in the file's mode will be cleared upon successful
	return from chmod().

This does not specify that the call to chmod(2) return success if
an unprivileged user attempts to set the setGID but it does specify
that if success is returned then the bit should be cleared, if I
am reading it correctly.  This seems to indicate that both behaviours
(Continue reading)

Permalink | Reply | 2 comments |
headers
Valeriy E. Ushakov | 1 Jan 2012 22:37
Picon

Re: UFS and POSIX test suite

On Sun, Jan 01, 2012 at 18:12:48 +0000, Roland C. Dowdeswell wrote:

> On Sun, Jan 01, 2012 at 07:05:06PM +0100, Emmanuel Dreyfus wrote:
> >
> 
> > I intentend to use it to hunt bugs for NetBSD FUSE. Without any
> > surprise, there are a lot of failures, but I am a it surprised to see
> > that NetBSD UFS fails the same tests most of the time.
> > 
> > To give an exaample, the script detects that when an unprivilegied user
> > attempts to set the setGID bit, it should be cleared, while NetBSD UFS
> > returns EPERM.
> > 
> > And just clearing the bit indeed seems to be mandated by POSIX:
> >  http://pubs.opengroup.org/onlinepubs/7908799/xsh/chmod.html)
> > 
> > Opinions? Do we have bugs to fix here? Anyone already gave it a try?
> 
> It seems to me that either behaviour complies with the language
> that you quote:
> 
> 	If the calling process does not have appropriate privileges,
> 	and if the group ID of the file does not match the effective
> 	group ID or one of the supplementary group IDs and if the
> 	file is a regular file, bit S_ISGID (set-group-ID on
> 	execution) in the file's mode will be cleared upon successful
> 	return from chmod().
> 
> This does not specify that the call to chmod(2) return success if
> an unprivileged user attempts to set the setGID but it does specify
(Continue reading)

Permalink | Reply | 1 comment |
headers
Julian Fagir | 2 Jan 2012 01:34
Picon

ZFS status in NetBSD?

Hi,

I just again wondered about the status of ZFS in NetBSD. You can find
something about it written on the webpage and in the wiki, but cannot find
any recent information.

What is the current status of ZFS, and why, what is missing, etc.?

Regards, Julian
Permalink | Reply | 1 comment |
headers
David Holland | 2 Jan 2012 21:28
Picon

Re: ZFS status in NetBSD?

On Mon, Jan 02, 2012 at 01:34:49AM +0100, Julian Fagir wrote:
 > I just again wondered about the status of ZFS in NetBSD. You can find
 > something about it written on the webpage and in the wiki, but cannot find
 > any recent information.
 > 
 > What is the current status of ZFS, and why, what is missing, etc.?

The short answer is: it doesn't work yet and needs someone to take
charge of getting it working.

Beyond that I don't know. I'm a zfs skeptic and not all that
interested in getting directly involved, but I can certainly advise on
vfs and interfacing issues.

--

-- 
David A. Holland
dholland <at> netbsd.org
Permalink | Reply | 0 comments |
headers
David Laight | 3 Jan 2012 09:24
Picon

Re: UFS and POSIX test suite

On Mon, Jan 02, 2012 at 01:37:23AM +0400, Valeriy E. Ushakov wrote:
> > It seems to me that either behaviour complies with the language
> > that you quote:
> > 
> > 	If the calling process does not have appropriate privileges,
> > 	and if the group ID of the file does not match the effective
> > 	group ID or one of the supplementary group IDs and if the
> > 	file is a regular file, bit S_ISGID (set-group-ID on
> > 	execution) in the file's mode will be cleared upon successful
> > 	return from chmod().
> > 
...
>   [EPERM]
>     The effective user ID does not match the owner of the file and the
>     process does not have appropriate privileges.
...
> The quoted passage about S_ISGID seems to tell that if user does own
> the file (cf. "successful return from chmod()") but there is gid
> mismatch, then S_ISGID in "mode" is silently ignored if present and is
> also "cleared ...  in the file's mode" - but chmod() still succeeds.

Hmmmm.... It seems a little strange that a request to set the file
modes to their current values has the effect of clearing the S_ISGID bit!
It would even make sense to allow the removal of other bits without
S_ISGID being cleared - but you don't want to allow write access to
be gained on such files.

	David

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Manuel Bouyer | 3 Jan 2012 13:12

Re: VT6410 IDE and WDC_NO_IDS

On Sun, Dec 25, 2011 at 09:35:40PM +0100, Frank Wille wrote:
> In my effort to add Iomega Storcenter G2 support to sandpoint I
> experimented with Takahiro Kambe's patch for the VIA VT6410 IDE RAID
> controller (not using the RAID part here):
>   http://mail-index.netbsd.org/port-i386/2007/03/30/0000.html
> 
> The VT6410 freezes the kernel with an interrupt storm during wdcprobe().
> But after some time I found out that defining the option WDC_NO_IDS
> fixes that.
> 
> As far as I understand the problem, we cannot enable interrupts during
> drive probing, because there is something wrong (with the chip or with
> our driver?). But I am not an IDE expert.
> 
> I found no such hack in the Linux and FreeBSD sources, and not even
> in the Storcenter GPL patches, which Iomega released, so I see no
> other solution. Unfortunately there are (as usual) no datasheets for
> the VT6410 available either.
> 
> 
> So I tend to accept WDC_NO_IDS as a solution, but I don't like it as a
> config file option. In the GENERIC sandpoint config it would also enable
> this hack for all the other (innocent) IDE chips.
> 
> Now I would like to turn this option into a device property, so it
> can be enabled on demand.
> 
> AFAICS WDC_NO_IDS was introduced for evbmips/LOONGSON (workaround
> CS5536+JMH330), which I would have to change too.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Frank Wille | 4 Jan 2012 09:42
Picon

Re: VT6410 IDE and WDC_NO_IDS

On Tue, 3 Jan 2012 13:12:36 +0100
Manuel Bouyer <bouyer <at> antioche.eu.org> wrote:

> > Now I would like to turn this option into a device property, so it
> > can be enabled on demand.
> > [...]
> 
> I'm not sure a device property would work, unless you can force it
> with a config option: I found the JMH330 connected to a CS5536 in
> the fuloong, but you can connect a JMH330 to any PATA controller
> (and there's no way to detect this at run time).

Ok, I understand. I won't change that.

I decided to take a different workaround for the VT6410 on sandpoint.
Establishing an edge-triggered PCI interrupt seems to solve the problem
for me.

If anybody can test a VT6410 on a different platform, I would be
interested in the results.

--

-- 
Frank Wille
Permalink | Reply | 0 comments |
headers
Edgar Fuß | 4 Jan 2012 16:44
Picon
Favicon

Status of SAS2008 (or other SAS2 controller) support

It's time to buy new fileserver hardware and I'd like to keep running NetBSD
on it. Which seems to get tough with current hardware.

What's the status of LSI SAS2008 support? I can find the PCI IDs added in
February 2010, but no sign of actual driver support.
Is there another SAS2 controller supported?

Thanks for any comments.
Permalink | Reply | 0 comments |

Gmane