Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 8946 - rp-pppoe sandbox violation again
Summary: rp-pppoe sandbox violation again
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Ryan Phillips (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-10-09 16:37 UTC by Henryk Plötz
Modified: 2003-02-04 19:42 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Output of lsmod (lsmod.output,1.61 KB, text/plain)
2002-10-09 16:39 UTC, Henryk Plötz
Details
The log file generated by emerge -u rp-pppoe (sandbox-rp-pppoe-3.4-r1-11433.log,108 bytes, text/plain)
2002-10-09 16:40 UTC, Henryk Plötz
Details
Kernel configuration (.config,16.40 KB, text/plain)
2002-10-09 16:41 UTC, Henryk Plötz
Details
Output of emerge -u rp-pppoe >& emergelog (emergelog,14.37 KB, text/plain)
2002-10-10 03:18 UTC, Henryk Plötz
Details
The ebuild (rp-pppoe-3.4-r1.ebuild,921 bytes, text/plain)
2002-10-13 03:10 UTC, Pierre-Henri Jondot
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Henryk Plötz 2002-10-09 16:37:57 UTC
This is basically the same thing as reported in bug 4615 and bug 5809 and it's
obviously not fixed yet.

I'm using a vanilla 2.4.18 from kernel.org and gcc 2.95.3, currently
rp-pppoe-3.4 is installed and I had no problem installing that. I will post my
kernel configuration, the log file and the output of lsmod as requested in the
other two bugs.

Below are the last lines of emerge -u rp-pppoe:
strip:
/var/tmp/portage/rp-pppoe-3.4-r1/image/usr/sbin/pppoe-wrapper
/var/tmp/portage/rp-pppoe-3.4-r1/image/usr/sbin/pppoe
/var/tmp/portage/rp-pppoe-3.4-r1/image/usr/sbin/pppoe-server
/var/tmp/portage/rp-pppoe-3.4-r1/image/usr/sbin/pppoe-relay
/var/tmp/portage/rp-pppoe-3.4-r1/image/usr/sbin/pppoe-sniff
>>> Completed installing into /var/tmp/portage/rp-pppoe-3.4-r1/image/

--------------------------- ACCESS VIOLATION SUMMARY ---------------------------
LOG FILE = "/tmp/sandbox-rp-pppoe-3.4-r1-11433.log"

open_wr:   /proc/sys/kernel/tainted
open_wr:   /proc/sys/kernel/tainted
open_wr:   /proc/sys/kernel/tainted
--------------------------------------------------------------------------------
Comment 1 Henryk Plötz 2002-10-09 16:39:13 UTC
Created attachment 4552 [details]
Output of lsmod
Comment 2 Henryk Plötz 2002-10-09 16:40:00 UTC
Created attachment 4553 [details]
The log file generated by emerge -u rp-pppoe
Comment 3 Henryk Plötz 2002-10-09 16:41:05 UTC
Created attachment 4554 [details]
Kernel configuration
Comment 4 Henryk Plötz 2002-10-09 20:50:40 UTC
Update: I did some experimenting and the access violations do not occur when I
taint the kernel (either by loading a non-free module such as ppp_deflate or via
echo 1 > /proc/sys/kernel/tainted) or modprobe pppoe before emerging. 

They do occur when I untaint the kernel (echo 0 > /proc/sys/kernel/tainted) or
modprobe pppox (which is needed by pppoe) and make sure that pppoe is not loaded. 

In either case pppoe and pppox are loaded after the emerge.
Comment 5 SpanKY gentoo-dev 2002-10-10 01:25:55 UTC
attach this stuff too please: 
(1) `emerge -u rp-pppoe >& emergelog` 
(2) `strace -f -s 4096 emerge -u rp-pppoe >& stracelog` 
Comment 6 Henryk Plötz 2002-10-10 03:18:23 UTC
Created attachment 4564 [details]
Output of emerge -u rp-pppoe >& emergelog
Comment 7 Henryk Plötz 2002-10-10 03:51:38 UTC
The output of strace -f -s 4096 emerge -u rp-pppoe >& stracelog is 16MB and even
gzip'ed it is too big for bugzilla, so I uploaded the compressed file to
http://www.informatik.hu-berlin.de/~ploetz/misc/stracelog.gz (1.5MB)
Comment 8 Pierre-Henri Jondot 2002-10-13 03:08:45 UTC
OK

The bug is easy to trace :  it comes from the modprobing of modules being done
during the configure process. (It might sound strange as the sandbox violation
occurs at the end of the emerging, yet it does : stopping the emerging with
ctrl-c just after the configuration make sandbox complain immediately of a
sandbox violation...)

These tests are stupid since :
  if the configure script detects that everything is present to use kernel mode
pppoe, it won't build the necessary plugin anyway because it needs the sources
for pppd under hand... (And if it fails, it won't prevent him from building the
plugin anyway, he will just complain !)

I don't know if kernel mode pppoe is needed (I suppose not, and the two user
space modes of rp-pppoe, standard async, or sync are certainly enough, from what
I read, kernel mode pppoe should be useful in a pppoe server, not a client...)

Anyway, modifying rp-pppoe ebuild to enable the building of the rp-pppoe kernel
mode plugin is a little painful, and not worth the trouble right now.

The easiest fix would be to comment out the modprobe commands in the configure
script. That's all...

I'll attach a slightly modified ebuild. (No use to change the revision.)
Comment 9 Pierre-Henri Jondot 2002-10-13 03:10:37 UTC
Created attachment 4651 [details]
The ebuild
Comment 10 Pierre-Henri Jondot 2002-10-13 03:27:27 UTC
Humm...

There is something strange still... The modules do get loaded anyway (I guess I
should have patched configure.in too) but then they do not create sandbox
violation...

Does it work for you, such as it is ?

A bit weird IMO...
Comment 11 Henryk Plötz 2002-10-13 03:58:03 UTC
Yes, the corrected ebuild compiles successfully and the access violation is
gone. Thanks for the fix!

(I can't currently test the PPPoE-connection, but I can see no reason why it
shouldn't work.)
Comment 12 SpanKY gentoo-dev 2002-10-13 12:45:56 UTC
nice work :) 
Comment 13 Pierre-Henri Jondot 2002-10-14 11:57:41 UTC
Good news...

My patch seems to work for everyone... According to bug 9089, the sandbox
violation was seen too by those who built PPP, PPPoE in the kernel, not as
modules. And indeed, I was able to reproduce the violation this way. (As in
every other case, the second emerging of rp-pppoe has ALWAYS worked without a
sandbox violation.)

I absolutely have no idea why it does work in this second case (How could the
modprobing of non-existent modules 'taint the kernel' ?) and was so surprised
from the resolution of bug 9089 I wanted to test it myself... The fact is it
worked just fine (the first time of course)

Pierre-Henri Jondot (not a little proud of having solved a four months old bug :)
Comment 14 Ryan Phillips (RETIRED) gentoo-dev 2002-10-27 13:31:47 UTC
committed