bug#109: [kernel] bug#109: iptables causes trap 27

X-PA-RISC Linux-PR-Message: report 109
X-PA-RISC Linux-PR-Package: kernel
X-Loop: daniel_frazier@hp.com
Received: via spool by 109-bugs@bugs.parisc-linux.org id=B109.98765449418885
          (code B ref 109); Thu, 19 Apr 2001 04:33:01 GMT
Message-Id: <200104190421.WAA21523@puffin.external.hp.com>
To: Richard Hirst <rhirst@linuxcare.com>
Cc: 109@bugs.parisc-linux.org
In-Reply-To: Your message of "Wed, 18 Apr 2001 22:41:44 BST."
             <20010418224144.Y11226@linuxcare.com> 
Date: Wed, 18 Apr 2001 22:21:37 -0600
From: Grant Grundler <grundler@puffin.external.hp.com>

Richard Hirst wrote:
> > GR24 00000000000000ff
> > GR25 000000000008f001
> > GR26 000119800000e9d4
> > SR1  0000000000000180 	(SR0 is the same)
> > 
> > Looks like we tried to copyout the counters info but went past the
> > end of the page/space allocated by iptables. Not sure about this > > conclusion though...
> 
> I'd guess gr26 was screwed.  Surely the top half should be zero?

I thought so too. But then thought I have no clue how we copy from
kernel to user space and have sr1 == sr0. Hopefully jsm or willy
can comment on this ASAP.

I haven't traced the syscall path.
This could be a 32-user/64-kernel issue.
0x00011980 would be a valid user app address while 0xe9d4 would not.
(I thought all user app addresses were > 0x00010000).
Interesting we managed to make more than a dozen calls before it crashed.

thanks,
grant

Grant Grundler
parisc-linux {PCI|IOMMU|SMP} hacker
+1.408.447.7253