Hi,
Trying to apply patch to newly cvs'd current
# cd
/usr/src/
/usr/src/sys/arch/i386/pci/glxsb.patch
<
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- sys/arch/i386/pci/glxsb.c
|+++ sys/arch/i386/pci/glxsb.c
--------------------------
Patching file sys/arch/i386/pci/glxsb.c using Plan A...
Hunk #1 succeeded at 32.
Hunk #2 failed at 398.
1 out of 2 hunks failed--saving rejects to sys/arch/i386/pci/glxsb.c.rej
done
# cat sys/arch/i386/pci/glxsb.c.rej
@@ -398,14 +398,24 @@
case CRYPTO_AES_CBC:
if (c->cri_klen != 128) {
- swd = malloc(sizeof(struct swcr_data),
M_CRYPTO_DATA,
- M_NOWAIT|M_ZERO);
+ swd = malloc(sizeof(struct swcr_data),
+ M_CRYPTO_DATA, M_NOWAIT|M_ZERO);
if (swd == NULL) {
glxsb_crypto_freesession(sesn);
return (ENOMEM);
}
ses->ses_swd_enc = swd;
txf = &enc_xform_rijndael128;
+ if (txf->ctxsize > 0) {
+ swd->sw_kschedule =
+ malloc(txf->ctxsize,
+ M_CRYPTO_DATA,
+ M_NOWAIT|M_ZERO);
+ if (swd->sw_kschedule == NULL) {
+
glxsb_crypto_freesession(sesn);
+ return (EINVAL);
+ }
+ }
if (txf->setkey(&(swd->sw_kschedule),
c->cri_key,
c->cri_klen / 8) < 0) {
glxsb_crypto_freesession(sesn);
On Wed, Oct 23, 2013 at 5:23 AM, Mike Belopuhov <m...@belopuhov.com> wrote:
> On Wed, Oct 23, 2013 at 08:45 +0100, Stuart Henderson wrote:
> > The panic seems odd (0x594f69b5 !=
> > 0x594f69b5 - these are the same value) , maybe someone else will
> be able to comment on that.
> >
> > It would be useful to know what isakmpd is doing at the time e.g. run it
> in the foreground with fairly high debug settings (maybe "isakmpd -K -d
> -DA=99" and "ipsecctl -f /etc/ipsrc.conf" - there will be a lot of output
> so run from ssh not serial console).
> >
> > You may be able to workaround by using 'boot -c' at the bootloader
> prompt, then 'disable glxsb' and 'quit', or the kernel on-disk could be
> modified using 'config -ef /bsd'. (glxsb is for hardware AES acceleration
> for Geode LX systems).
> >
> > iamatt <iam...@gmail.com> wrote:
> > ># Data modified on freelist: word 153288032 of object 0xd17218e0 size
> > >0x18
> > >previ
> > >ous type ??? (invalid addr
> > >0x3557935e)
> > >panic: Data modified on freelist: word 3 of object 0xd17218e0 size 0x18
> > >previous
> > > type ??? (0x594f69b5 !=
> > >0x594f69b5)
> > >
> > >
> > >Stopped at Debugger+0x4: popl
> > >%ebp
> > >RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS
> > >PANIC!
> > >DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT
> > >INFORMATION!
> > >ddb>
> > >trace
> > >Debugger(d0976848,f53be668,d0952384,f53be668,d0a95014) at
> > >Debugger+0x4
> > >panic(d0952384,d095232c,3,d17218e0,18) at
> > >panic+0x67
> > >malloc(18,6c,a,f53be6fc,d1613000) at
> > >malloc+0x5e4
> > >glxsb_crypto_newsession(f53be73c,f53be794,0,10,40) at
> > >glxsb_crypto_newsession+0
> > >x133
> > >
> > >crypto_newsession(d17264f0,f53be794,0,f53be7b8,d0b05340) at
> > >crypto_newsession+0
> > >x135
> > >
> > >esp_init(d1726400,d0a96cd8,f53be900,d1724f50,d1724f68) at
> > >esp_init+0x245
> > >pfkeyv2_send(d5d1f008,d1724e00,198,d1724f98,d0b05340) at
> > >pfkeyv2_send+0x1a6e
> > >pfkey_register(d5d8cc00,d5d1f008,f53bedbc,d03c0a4a,88ab98a0) at
> > >pfkey_register+
> > >0x278
> > >
> > >raw_usrreq(d5d1f008,9,d5d8cc00,0,0) at
> > >raw_usrreq+0x221
> > >sosend(d5d1f008,0,f53beeb0,d5d8cc00,0) at
> > >sosend+0x48d
> > >soo_write(d5d230ac,d5d230c8,f53beeb0,d5e202d0,55187908) at
> > >soo_write+0x3b
> > >dofilewritev(d5d3c618,8,d5d230ac,84fa7500,11) at
> > >dofilewritev+0x133
> > >sys_writev(d5d3c618,f53bef64,f53bef84,f53befa8,d5e11600) at
> > >sys_writev+0x7c
> > >syscall() at
> > >syscall+0x1f9
> > >--- syscall (number 5)
> > >---
> > >0x2:
> > >
> > >ddb>
> > >ps
> > > PID PPID PGRP UID S FLAGS WAIT
> > >COMMAND
> > > 31132 1 31132 0 3 0x83 ttyin
> > >ksh
> > > 6230 1 6230 0 3 0x80 select
> > >cron
> > > 1331 1 1331 601 3 0x90 kqread
> > >unbound
> > > 30501 1 30501 535 3 0x90 nanosleep
> > >symon
> > > 16688 1 16688 99 3 0x90 poll
> > >sndiod
> > > 27774 30105 30105 0 3 0xb0 netcon2
> > >sendmail
> > > 30105 1 30105 0 3 0xb0 select
> > >sendmail
> > > 11400 1 11400 77 3 0x90 poll
> > >dhcpd
> > > 1054 1 1054 0 3 0x80 kqread
> > >ifstated
> > > 7646 1 7646 0 3 0x80 select
> > >sshd
> > > 18014 0 0 0 3 0x100280 nfsidl
> > >nfsio
> > > 20915 0 0 0 3 0x100280 nfsidl
> > >nfsio
> > > 8480 0 0 0 3 0x100280 nfsidl
> > >nfsio
> > > 13835 0 0 0 3 0x100280 nfsidl
> > >nfsio
> > >*25527 31834 31834 68 7 0x10
> > >isakmpd
> > > 31834 1 31834 0 3 0x80 netio
> > >isakmpd
> > > 19715 24693 17897 83 3 0x90 poll
> > >ntpd
> > > 24693 17897 17897 83 3 0x90 poll
> > >ntpd
> > > 17897 1 17897 0 3 0x80 poll
> > >ntpd
> > > 630 4742 4742 74 3 0x90 bpf
> > >pflogd
> > > 4742 1 4742 0 3 0x80 netio
> > >pflogd
> > > 9803 9138 9138 73 2 0x90
> > >syslogd
> > > 9138 1 9138 0 3 0x80 netio
> > >syslogd
> > > 18744 1 18744 77 3 0x90 poll
> > >dhclient
> > > 22501 1 22501 0 3 0x80 poll
> > >dhclient
> > > 13 0 0 0 3 0x100200 aiodoned
> > >aiodoned
> > > 12 0 0 0 3 0x100200 syncer
> > >update
> > > 11 0 0 0 3 0x100200 cleaner
> > >cleaner
> > > 10 0 0 0 3 0x100200 reaper
> > >reaper
> > > 9 0 0 0 3 0x100200 pgdaemon
> > >pagedaemon
> > > 8 0 0 0 3 0x100200 bored
> > >crypto
> > > 7 0 0 0 3 0x100200 pftm
> > >pfpurge
> > > 6 0 0 0 3 0x100200 usbtsk
> > >usbtask
> > > 5 0 0 0 3 0x100200 usbatsk
> > >usbatsk
> > > 4 0 0 0 3 0x100200 bored
> > >syswq
> > > 3 0 0 0 3 0x40100200
> > >idle0
> > > 2 0 0 0 3 0x100200 kmalloc
> > >kmthread
> > > 1 0 1 0 3 0x82 wait
> > >init
> > > 0 -1 0 0 3 0x200 scheduler
> > >swapper
> > >ddb>
> > >
> > >
> > >
> > >On Mon, Oct 21, 2013 at 5:20 PM, Stuart Henderson <st...@openbsd.org>
> > >wrote:
> > >
> > >> On 2013/10/21 10:29, iamatt wrote:
> > >> > I do not have the console debug screen but I do have the files from
> > >> > /var/crash/ Is there some commands I can run on them using gdb
> > >that can
> > >> > be of use?
> > >>
> > >> If you have a crashdump, possibly, see "man crash".
> > >>
> > >> As the panic message goes,
> > >>
> > >> RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS
> > >PANIC!
> > >> DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
> > >>
> > >> This is much easier than for somebody else to install Linux
> > >> and the shrewsoft client before they can even start looking at the
> > >bug
> > >> (and even then, they might not be able to replicate it).
> >
>
> hi,
>
> this is partially my screwup. please try the diff below. we
> forget to actually allocate the memory for our key schedule
> but free it later on in the glxsb_crypto_freesession. that's
> why you get memory corruption all the way.
>
> it has another seemingly unrelated chunk (pctr.h -> cpufunc.h
> change) that i would like to commit as well (perhaps separately)
> to limit pctr.h usage in kernel. so it would be nice to test
> the whole thing together.
>
> i also reformat one malloc block to shorten it (:
>
> ok's are welcome (assuming this will pass the test).
>
> diff --git sys/arch/i386/pci/glxsb.c sys/arch/i386/pci/glxsb.c
> index dacb500..59a7e06 100644
> --- sys/arch/i386/pci/glxsb.c
> +++ sys/arch/i386/pci/glxsb.c
> @@ -32,7 +32,7 @@
> #include <sys/timeout.h>
>
> #include <machine/bus.h>
> -#include <machine/pctr.h>
> +#include <machine/cpufunc.h>
>
> #include <dev/rndvar.h>
> #include <dev/pci/pcivar.h>
> @@ -398,14 +398,24 @@ glxsb_crypto_newsession(uint32_t *sidp, struct
> cryptoini *cri)
> case CRYPTO_AES_CBC:
>
> if (c->cri_klen != 128) {
> - swd = malloc(sizeof(struct swcr_data),
> M_CRYPTO_DATA,
> - M_NOWAIT|M_ZERO);
> + swd = malloc(sizeof(struct swcr_data),
> + M_CRYPTO_DATA, M_NOWAIT|M_ZERO);
> if (swd == NULL) {
> glxsb_crypto_freesession(sesn);
> return (ENOMEM);
> }
> ses->ses_swd_enc = swd;
> txf = &enc_xform_rijndael128;
> + if (txf->ctxsize > 0) {
> + swd->sw_kschedule =
> + malloc(txf->ctxsize,
> + M_CRYPTO_DATA,
> + M_NOWAIT|M_ZERO);
> + if (swd->sw_kschedule == NULL) {
> +
> glxsb_crypto_freesession(sesn);
> + return (EINVAL);
> + }
> + }
> if (txf->setkey(&(swd->sw_kschedule),
> c->cri_key,
> c->cri_klen / 8) < 0) {
> glxsb_crypto_freesession(sesn);
