g...@ir.bbn.com (Greg Troxel) writes:
>1) What do FreeBSD, Linux, and Illumos do? OpenBSD/Dragonfly/others?
If I'm not mistaken, this looks like:
FreeBSD - native disk blocks
Linux - native disk blocks
Illumos - DEV_BSIZE
OpenBSD - DEV_BSIZE
NetBSD - DEV_BSIZE
DragonFly - native disk blocks
Ami
jan.m.daniels...@gmail.com (Jan Danielsson) writes:
>On 27/11/15 00:20, Robert Elz wrote:
>[---]
>> Making the CGD believe its underlying sectors are 4K panics the system.
>> (That's about as far as I got, but I think the problem is related to
>> translation between units, being done when it shoul
As a few people have heard, I thought up a way to implement
per-process namespaces reasonably cheaply without requiring massive
rewrites of everything. It is kind of a hack, but not super awful.
Preliminary patch is here:
http://www.netbsd.org/~dholland/tmp/namespaces-20151127.diff
It at least
Date:Sat, 28 Nov 2015 14:57:08 + (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:
| I've just committed a few fixes for disks with non-512byte sectors
| to HEAD.
|
| cgd now works on my drive with 1k sectors.
Thanks, works for me too (I didn'
Hi,
here is a (draft) patch to map the kernel DATA and BSS segments with
the NX/XD bit in the PTEs on i386+amd64.
A nice PoC: patch your (amd64) kernel with the shellcode below, and
launch this:
#include
#include
#include
int main() {
sched_getp
k...@munnari.oz.au (Robert Elz) writes:
>This is (it appears) caused by this line in cgdioctl() ...
>dk_getdisklabel(dksc, 0 /* XXX ? (cause of PR 41704) */);
>The 0 ((dev_t)0) and XXX have been there since cgd.c 1.1, so this
>is nothing new!
That's vp->v_rdev stored as cs->sc_tdev. A v
Date:Sun, 29 Nov 2015 01:22:08 +0700
From:Robert Elz
Message-ID: <19896.1448734...@andromeda.noi.kre.to>
| Stuff related to PR 41704 generating a panic in my setup ...
| Anyone have any suggestions?
Actually, the (or a) fix for this is astoundingly easy, and I'm
On Sun, Nov 29, 2015 at 03:06:10AM +0700, Robert Elz wrote:
> Date:Sun, 29 Nov 2015 01:22:08 +0700
> From:Robert Elz
> Message-ID: <19896.1448734...@andromeda.noi.kre.to>
>
> | Stuff related to PR 41704 generating a panic in my setup ...
> | Anyone have any sugges
Date:Sat, 28 Nov 2015 19:58:19 + (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:
| The correct thing is therefore to drop the dk_getdisklabel call.
| Can you verify that this just solves the problem?
Yes, that works too.
I wondered about that, b
On Mon, Oct 12, 2015 at 09:40:09PM +0200, Joerg Sonnenberger wrote:
> I have a build machine building pkgsrc where I see some very strange
> issues. The individual chroots share a read-only null-mounted base
> directory with a number of tmpfs instances on top for most of the
> writeable parts. Symp
On Sat, Nov 28, 2015 at 09:38:57PM +0100, Joerg Sonnenberger wrote:
> On Mon, Oct 12, 2015 at 09:40:09PM +0200, Joerg Sonnenberger wrote:
> > I have a build machine building pkgsrc where I see some very strange
> > issues. The individual chroots share a read-only null-mounted base
> > directory wit
k...@munnari.oz.au (Robert Elz) writes:
> | The correct thing is therefore to drop the dk_getdisklabel call.
> | Can you verify that this just solves the problem?
>Yes, that works too.
Committed.
--
--
Michael van Elst
Internet: mlel...@serpens.de
> The current code operates on full sectors and encodes the sector number
> into the data.
>
> Modifying this to encode multiple 512 byte blocks instead and using
> block numbers instead of sector numbers looks straight forward to me.
>
> We just have to decide if that is a good thing. Or maybe i
On Sun, Nov 29, 2015 at 03:33:31AM +0700, Robert Elz wrote:
>
> I wondered about that, but wasn't sure if the disklabel read might be
> needed for the dkwedge_discover() that immediately follows.
The wedge autodiscover code doesn't need the disklabel, it gets
some geometry data from the driver it
On Sat, Nov 28, 2015 at 07:54:10PM +0100, Maxime Villard wrote:
> Hi,
> here is a (draft) patch to map the kernel DATA and BSS segments with
> the NX/XD bit in the PTEs on i386+amd64.
Pretty sure this won't work on i386. You have to have PAE enabled
before you can use NX/XD in the MMU. AFAIK i38
On Sun, Nov 29, 2015 at 08:11:58AM +1100, matthew green wrote:
>
> i think it should use 512 byte crypto blocks in all cases, using
> offset in DEV_BSIZE units as part of the IV, at least by default.
>
> that would at least allow data to be recovered, by default, from
> the wrong sized media.
It
On Sat, Nov 28, 2015 at 07:54:10PM +0100, Maxime Villard wrote:
> here is a (draft) patch to map the kernel DATA and BSS segments with
> the NX/XD bit in the PTEs on i386+amd64.
There should be no need to force extra padding between .data and .bss.
Joerg
Date:Sat, 28 Nov 2015 22:34:25 +0100
From:Michael van Elst
Message-ID: <20151128213424.gc6...@serpens.de>
| > that would at least allow data to be recovered, by default, from
| > the wrong sized media.
There's no reason there could not be a userland tool that wou
k...@munnari.oz.au (Robert Elz) writes:
>I havem't looked carefully yet, but does vnd have the RMW behaviour to
>allow an emulated small sector drive to exist on a big sector underlying.
It doesn't need to, the backend is a file and you can access arbitrary
byte positions. The "RMW behaviour" is
Date:Sun, 29 Nov 2015 00:05:37 + (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:
| It doesn't need to, the backend is a file and you can access arbitrary
| byte positions.
You would think so, and that is probably what should happen, but I just
di
On Nov 29, 12:05am, Michael van Elst wrote:
} k...@munnari.oz.au (Robert Elz) writes:
}
} >I havem't looked carefully yet, but does vnd have the RMW behaviour to
} >allow an emulated small sector drive to exist on a big sector underlying.
}
} It doesn't need to, the backend is a file and you can
21 matches
Mail list logo
