search

libos-nuse / net-next-nuse

Network Stack in Userspace
Other
289 stars 67 forks source link

port-mm-code #47

Open jyizheng opened 9 years ago

jyizheng commented 9 years ago

Review on Reviewable

thehajime commented 9 years ago

@jyizheng I can't reproduce the travis CI issue, which said the followings.

https://travis-ci.org/libos-nuse/net-next-nuse/builds/68581850#L2497

  type    = 0
failed to get interface status
ioctl: No such device
err ioctl for assign address venet0 for link -22
ioctl: No such device
err ioctl for assign netmask 255.255.255.0 for link -99
Segmentation fault
/bin/ls: cannot access /tmp/rump-server-nuse.*: No such file or directory
chmod: cannot access `/tmp/rump-server-nuse.': No such file or directory
The command "./tools/testing/libos/nuse-test.sh" exited with 1.

mine is Fedora 21 x86_64. It only happened with optimized build (default one, OPT=yes).

could you please let me know the stack trace obtained by gdb ? sudo gdb -c core /bin/ping then backtrace on the gdb prompt ?

jyizheng commented 9 years ago

First of all, I need to confirm whether I have set the nuse.conf file correctly. "ifconfig" result of my machine is below.

yjiao@rowlf:/home/yjiao/net-next-nuse/arch/lib/tools$ ifconfig eth0 Link encap:Ethernet HWaddr bc:ae:c5:6b:49:91
inet addr:130.245.153.8 Bcast:130.245.153.255 Mask:255.255.255.0 inet6 addr: fe80::beae:c5ff:fe6b:4991/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:803144 errors:0 dropped:0 overruns:0 frame:0 TX packets:357246 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1015243408 (1.0 GB) TX bytes:26940095 (26.9 MB)

eth0:0 Link encap:Ethernet HWaddr bc:ae:c5:6b:49:91
inet addr:192.168.99.200 Bcast:192.168.99.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:15236 errors:0 dropped:0 overruns:0 frame:0 TX packets:15236 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:4709575 (4.7 MB) TX bytes:4709575 (4.7 MB)

"route -n":

yjiao@rowlf:/home/yjiao/net-next-nuse/arch/lib/tools$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 130.245.153.1 0.0.0.0 UG 0 0 0 eth0 130.245.153.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0 192.168.99.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

My nuse.conf file looks like this: 1 interface eth0 2 address 130.245.153.8 3 netmask 255.255.255.0 4 # if macaddr is not specified, random mac addr is used. 5 viftype TAP 6 7 #interface p1p1 8 # address 172.16.0.1 9 # netmask 255.255.255.0 10 # macaddr 00:01:01:01:01:01 11 # if viftype is not specified, defualt raw socket is used. 12 13 #route 14 # network 130.245.153.0 15 # netmask 255.255.255.0 16 # gateway 130.245.153.1 17 18 route 19 network 0.0.0.0 20 netmask 0.0.0.0 21 gateway 130.245.153.1

With this configuration file, I cannot run "ping google", for which the terminal got stuck without return with message below: tap_alloc: alloc tap interface nuse-eth0 mac address for eth0 is randomized 02:00:e0:c4:05:5c nuse syscall proxy start at unix:///tmp/rump-server-nuse.28764 PING 130.245.153.1 (130.245.153.1) 56(84) bytes of data.

thehajime commented 9 years ago 
>5 viftype TAP

This line should be viftype RAW to ping www.google.com. viftype TAP is to join existing bridge interface.

jyizheng commented 9 years ago

Is it possible for you to log on my machine to diagnose the problem? I can create an account for you on my machine.

On Mon, Jun 29, 2015 at 1:48 PM, Hajime Tazaki notifications@github.com wrote:

5 viftype TAP

This line should be viftype RAW to ping www.google.com. viftype TAP is to join existing bridge interface.

— Reply to this email directly or view it on GitHub https://github.com/libos-nuse/net-next-nuse/pull/47#issuecomment-116773777 .

thehajime commented 9 years ago

before creating an account for me, please check the followings:

jyizheng commented 9 years ago

Cannot pass the test due to things related to "rumpns_oom_lock".

thehajime commented 9 years ago

Cannot pass the test due to things related to "rumpns_oom_lock".

@jyizheng 'rumpns_' is a prefix introduced by recently. See 751adb6cd217bca14d4ec93d2a686c771ab89ffd commit.

it basically says the symbol 'oom_lock' is not included though it's referred by someone. maybe adding mm/oom_kill.o into your arch/lib/Makefile would be the first step.

jyizheng commented 9 years ago

I see. page_alloc.c is using oom_lock now. I will try to fix it.

On Tue, Sep 1, 2015 at 7:38 PM, Hajime Tazaki notifications@github.com wrote:

Cannot pass the test due to things related to "rumpns_oom_lock".

@jyizheng https://github.com/jyizheng 'rumpns_' is a prefix introduced by recently. See 751adb6 https://github.com/libos-nuse/net-next-nuse/commit/751adb6cd217bca14d4ec93d2a686c771ab89ffd commit.

it basically says the symbol 'oom_lock' is not included though it's referred by someone. maybe adding mm/oom_kill.o into your arch/lib/Makefile would be the first step.

— Reply to this email directly or view it on GitHub https://github.com/libos-nuse/net-next-nuse/pull/47#issuecomment-136892485 .

jyizheng commented 9 years ago

I still have the problem below.

The command "make clean ARCH=lib V=1 && make library ARCH=lib OPT=no V=1" exited with 0.

$ ./tools/testing/libos/nuse-test.sh

ping: symbol lookup error: ../../../liblinux.so: undefined symbol: rumpns__end

The command "./tools/testing/libos/nuse-test.sh" exited with 127.

On Tue, Sep 1, 2015 at 9:52 PM, Andy Joe jyizheng@gmail.com wrote:

I see. page_alloc.c is using oom_lock now. I will try to fix it.

On Tue, Sep 1, 2015 at 7:38 PM, Hajime Tazaki notifications@github.com wrote:

Cannot pass the test due to things related to "rumpns_oom_lock".

@jyizheng https://github.com/jyizheng 'rumpns_' is a prefix introduced by recently. See 751adb6 https://github.com/libos-nuse/net-next-nuse/commit/751adb6cd217bca14d4ec93d2a686c771ab89ffd commit.

it basically says the symbol 'oom_lock' is not included though it's referred by someone. maybe adding mm/oom_kill.o into your arch/lib/Makefile would be the first step.

— Reply to this email directly or view it on GitHub https://github.com/libos-nuse/net-next-nuse/pull/47#issuecomment-136892485 .

thehajime commented 9 years ago

I still have the problem below. (snip) $ ./tools/testing/libos/nuse-test.sh

ping: symbol lookup error: ../../../liblinux.so: undefined symbol: rumpns__end

I fixed this issue (359e2da2d7913513f08abb8cc247c8a73c62c9ee). please pull the latest net-next-nuse/master to your branch. you may face another unresolved symbol 'smp_store_mb' which you may need to fix it in your branch.

jyizheng commented 9 years ago

Finally passed!

thehajime commented 9 years ago

@jyizheng I put review comments on your patch. please take a look at and apply them if it's fine.

thehajime commented 9 years ago

@jyIzheng thanks for the update. I put comments again to your files.

I think we need a couple of rounds to clean up more. for your particular pull request,

  1. change PR's title in order to understand what this patch does,
  2. close unneeded PR (#45,#46).

I briefly memorized the general guideline for a pull request for this project.

https://github.com/libos-nuse/net-next-nuse/wiki/Pull-request-guideline

thank you for your time.

thehajime commented 9 years ago

@jyizheng I've commented on your patch.

I would remind the followings again: please update them as well.

  1. change PR's title in order to understand what this patch does,
  2. close unneeded PR (#45,#46).
jyizheng commented 9 years ago

Updated my code again and renamed the pull request and deleted the old ones.

thehajime commented 9 years ago

thanks @jyizheng, I've tried to play locally with your patch. I was wondering what is the expected behavior with this ? can we have any specifics from an execution ? (I meant I'd like to add a test, like in tools/testing/libos/nuse-test.sh for instance to ensure this feature is working or not.)

jyizheng commented 9 years ago

I agree. I think I can write a test case that calling APIs in page_alloc.c directly for memory allocation and then do some arithmetic operation. Is this good enough?

On Tue, Sep 8, 2015 at 1:05 AM, Hajime Tazaki notifications@github.com wrote:

thanks @jyizheng https://github.com/jyizheng, I've tried to play locally with your patch. I was wondering what is the expected behavior with this ? can we have any specifics from an execution ? (I meant I'd like to add a test, like in tools/testing/libos/nuse-test.sh for instance to ensure this feature is working or not.)

— Reply to this email directly or view it on GitHub https://github.com/libos-nuse/net-next-nuse/pull/47#issuecomment-138435711 .

thehajime commented 9 years ago

I agree. I think I can write a test case that calling APIs in page_alloc.c directly for memory allocation and then do some arithmetic operation. Is this good enough?

Great !

jyizheng commented 9 years ago

Where do you want me to add the test? I don't have the scripts for testing.

Best, Yizheng

On Wed, Sep 9, 2015 at 10:44 AM, Hajime Tazaki notifications@github.com wrote:

I agree. I think I can write a test case that calling APIs in page_alloc.c directly for memory allocation and then do some arithmetic operation. Is this good enough?

Great !

— Reply to this email directly or view it on GitHub https://github.com/libos-nuse/net-next-nuse/pull/47#issuecomment-138933419 .

thehajime commented 9 years ago

What about creating a program in tools/testing/libos and calling from nuse-test.sh ?