headers
remodeler | 1 Nov 2009 01:59

dumpon to an encrypted swap partition?

I am running 8.0 RC1 on a multi-user server with a few dozen vnet-enabled
jails and netgraph. The swap partition is encrypted by its /etc/fstab entry, like:

/dev/ad2s1b.eli   none    swap    sw   0   0

I am getting sporadic kernel panics on reboot, during the GEOM_JOURNAL
shutdown sequence. However, they occur after geli detaches the swap partition,
so I get an error like:

Cannot dump. Device not defined or unavailable.

I know I can set dumpdev in /etc/rc.conf to a file rather than a swap
partition, but is there a way to (1) have an encrypted swap partition, and (2)
dump a core to a swap partition without failure? If I set up a second
unencrypted swap, I can't let the system write potentially confidential
information into that space.

Also, at the end of the panic, I get the message:

Automatic reboot in 15 seconds - press a key on the console to abort

but then the server hangs and requires manual power-down and reboot. I thought
a reboot was inevitable after a kernel panic - that nothing could prevent it
in terms of misbehaving processes, etc. Any idea what could cause such a freeze?

Thank you.
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
(Continue reading)

Permalink | Reply | 1 comment |
headers
ไพรัช ศรีโยธา | 1 Nov 2009 09:33
Picon
Favicon

Re: make release stop at Creating ISO imagess (success)

Quoting ไพรัช ศรีโยธา <pirat <at> tint.or.th>:

> Quoting Ruben de Groot <mail25 <at> bzerk.org>:
>
>> On Mon, Oct 26, 2009 at 02:36:39PM +0700, ???????????????  
>> ????????????????????? typed:
>>> hi sirs,
>>>
>>> apologized me for disturbing this list but ireally have problem s.
>>> i make my own release by follwoing document in releng articles.
>>>
>>> here is my command
>>>
>>> cd /usr/src/release
>>> time make CHROOTDIR=/kaitag/KAITAG BUILDNAME=7.2-RELEASE \
>>> CVSROOT=/var/ftp/pub/ncvs RELEASETAG=RELENG_7_2_0_RELEASE \
>>> EXTSRCDIR=/usr/src EXTPORTSDIR=/usr/ports \
>>> DOC_LANG=en_US.ISO8859-1 NODOC=NO NOPORTS=NO \
>>> MAKE_DVD=YES MAKE_ISOS=YES CDROM=YES
>>> RELEASEDISTFILES=/var/ftp/pub/distfiles \
>>> release
>>>
>>> the build process goes well but then fetching for cdrtools.tbz begin and
>>> stop.
>>> in my machine i have installed cdrtools and there is also mkisofs file
>>> so i wonder why the script /usr/src/release/i386/mkisofsimages.sh
>>> still fetching for cdrtools.
>>
>> Do you have the cdrtools.tbz package in /var/ftp/pub/distfiles ?
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gleb Kurtsou | 1 Nov 2009 16:14
Picon
Gravatar

Re: dumpon to an encrypted swap partition?

On (31/10/2009 19:59), remodeler wrote:
> I am running 8.0 RC1 on a multi-user server with a few dozen vnet-enabled
> jails and netgraph. The swap partition is encrypted by its /etc/fstab entry, like:
> 
> /dev/ad2s1b.eli   none    swap    sw   0   0
> 
> I am getting sporadic kernel panics on reboot, during the GEOM_JOURNAL
> shutdown sequence. However, they occur after geli detaches the swap partition,
> so I get an error like:
> 
> Cannot dump. Device not defined or unavailable.
As far as I remember you should configure dump device to be raw swap
partition. Like /dev/ad2s1b in your case, and you can continue using it
for encrypted swap. I suppose you are using one time passwords for swap
partitions, so dump can't be restored after reboot anyway.

But there are issues with saving dump from encrypted swap after reboot.
See http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/124747
It's about dependencies during startup and the patch from PR is not
entirely correct/complete.

> I know I can set dumpdev in /etc/rc.conf to a file rather than a swap
> partition, but is there a way to (1) have an encrypted swap partition, and (2)
> dump a core to a swap partition without failure? If I set up a second
> unencrypted swap, I can't let the system write potentially confidential
> information into that space.
No, using file as dumpdev is impossible, not all device drivers support
crash dumps (because after kernel panic all interrupts are masked,
acquiring mutex always succeeds, driver should be able to operate in
poling mode, etc). I've never tried, but it seems dumping to umass
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dag-Erling Smørgrav | 1 Nov 2009 17:36
Picon
Gravatar

Re: help needed to fix contrib/ee crash/exit when receiving SIGWINCH

Alexander Best <alexbestms <at> math.uni-muenster.de> writes:
> great news. so should the PR be closed or should it remain in patched state in
> order for 7.x to get patched?

Set it to "patched" until you've merged the patch to 6, 7 and 8 (IIRC, 6
has the new ncurses as well)

> another question: how about our ncurses base version in general? should it
> remain the ncurses release version with our own patchset or would it be better
> to update it more frequently with the official ncurses patchsets? i guess this
> is the way acpi in the base dir is being handled. vendor updates get
> integrated on the fly into the base dir.

I would just import releases, unless there is a compelling reason to
import a patchset (i.e. it fixes a serious bug and we can't easily apply
just that one patch).

DES
--

-- 
Dag-Erling Smørgrav - des <at> des.no
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply | 3 comments |
headers
Max Boyarov | 2 Nov 2009 14:52
Picon

strange gdb behavior

Hi,

Who could help understand this:

`--> cat 1.c
int
main(int argc, char **argv)
{
        return 0;
}

`--> cc -ggdb -o 1 1.c

`--> gdb 1
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...
(gdb) set args test
(gdb) b main
Breakpoint 1 at 0x80483d0: file 1.c, line 3.
(gdb) r
Starting program: /tmp/1 test

Breakpoint 1, main () at 1.c:3
3       {
(Continue reading)

Permalink | Reply | 4 comments |
headers
Alexey Shuvaev | 2 Nov 2009 16:42
Picon
Favicon

Re: strange gdb behavior

On Mon, Nov 02, 2009 at 03:52:33PM +0200, Max Boyarov wrote:
> Hi,
> 
> Who could help understand this:
> 
> `--> cat 1.c
> int
> main(int argc, char **argv)
> {
>         return 0;
> }
> 
> [snip]
> 
> (gdb) set args test
> (gdb) b main
> Breakpoint 1 at 0x80483d0: file 1.c, line 3.
> (gdb) r
> Starting program: /tmp/1 test
> 
> Breakpoint 1, main () at 1.c:3
> 3       {
> (gdb) print argc
> Error accessing memory address 0x0: Bad address.
> (gdb) list
> 1       int
> 2       main(int argc, char **argv)
> 3       {
> 4               return 0;
> 5       }
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kostik Belousov | 2 Nov 2009 16:51
Picon

Re: strange gdb behavior

On Mon, Nov 02, 2009 at 03:52:33PM +0200, Max Boyarov wrote:
> Hi,
> 
> Who could help understand this:
> 
> `--> cat 1.c
> int
> main(int argc, char **argv)
> {
>         return 0;
> }
> 
> 
> `--> cc -ggdb -o 1 1.c
> 
> 
> `--> gdb 1
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i386-marcel-freebsd"...
> (gdb) set args test
> (gdb) b main
> Breakpoint 1 at 0x80483d0: file 1.c, line 3.
> (gdb) r
> Starting program: /tmp/1 test
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ryan Stone | 2 Nov 2009 19:24
Picon

Re: MIPS: bus_dma(9) and cache problems

> What sync operation are you doing?  At least for PREREAD or PREWRITE,
> I'd expect any dirty cache lines to be flushed to RAM.  If this isn't
> happening, then you may want to submit a bug report.

For a PREREAD, I don't believe that it's correct to flush a dirty
cache line to RAM.  That would overwrite whatever had been DMA'ed into
that cache line.

What about the following procedure for a PREREAD for a non-cache
aligned buffer I'll call dma_buf

1) read the entire cache line into a buffer, buf1
2) issue the invalidate
3) copy the portion of buf1 that preceeds dma_buf back to that address

One problem I can see immediately is that there is a race here: if
something tries to access the memory preceeding dma_buf after the
invalidate is issued but before the copy completes they will see
inconsistent data.  Maybe somebody else can think of a way around
that.

Ryan Stone
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply | 1 comment |
headers
Jason Harmening | 2 Nov 2009 20:33
Picon

Re: MIPS: bus_dma(9) and cache problems

On Mon, Nov 2, 2009 at 12:24 PM, Ryan Stone <rysto32 <at> gmail.com> wrote:
>> What sync operation are you doing?  At least for PREREAD or PREWRITE,
>> I'd expect any dirty cache lines to be flushed to RAM.  If this isn't
>> happening, then you may want to submit a bug report.
>
> For a PREREAD, I don't believe that it's correct to flush a dirty
> cache line to RAM.  That would overwrite whatever had been DMA'ed into
> that cache line.
>

I don't think that should matter--if you're issuing a PREREAD,
*before* the start of a DMA transfer, the CPU either doesn't care
about what's currently in the part of the line that is to be DMA'ed
into (because it's about to be overwritten by the device anyway), or
it's finished accessing what's in there from a previous DMA operation
(in which case you'd expect it to either be present in the cache or
already flushed out by something else anyway).

But the basic idea is that the CPU shouldn't access the cache line
from the time the PRE-whatever operation is issued to the time the
POST-whatever operation is issued, so if you have multiple threads
(anywhere on the system) accessing that line, you could be screwed.

Heh, I just noticed the copyright at the top of the MIPS busdma
implementation--apparently you ARE familiar w/ the MIPS sync
implementation :)
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Baldwin | 2 Nov 2009 16:28
Picon
Favicon

Re: mmap(2) with MAP_ANON honouring offset although it shouldn't

On Friday 30 October 2009 10:38:24 pm Alexander Best wrote:
> John Baldwin schrieb am 2009-10-21:
> > On Wednesday 21 October 2009 11:51:04 am Alexander Best wrote:
> > > although the mmap(2) manual states in section MAP_ANON:
> 
> > > "The offset argument is ignored."
> 
> > > this doesn't seem to be true. running
> 
> > > printf("%p\n", mmap((void*)0x1000, 0x1000, PROT_NONE, MAP_ANON, -1,
> > > 0x12345678));
> 
> > > and
> 
> > > printf("%p\n", mmap((void*)0x1000, 0x1000, PROT_NONE, MAP_ANON, -1,
> > > 0));
> 
> > > produces different outputs. i've attached a patch to solve the
> > > problem. the
> > > patch is similar to the one proposed in this PR, but should apply
> > > cleanly to
> > > CURRENT: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/71258
> 
> > A simpler patch would be to simply set pos = 0 below the MAP_STACK
> > line if
> > MAP_ANON is set.
> 
> how about the following patch. problem seems to be that pos = 0 needs to be
> set before pageoff is being calculated.
(Continue reading)

Permalink | Reply | 7 comments |

Gmane