Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

port-mm-code #47

Open
wants to merge 35 commits into
base: master
Choose a base branch
from
Open

port-mm-code #47

wants to merge 35 commits into from

Conversation

jyizheng
Copy link

Review on Reviewable

@thehajime
Copy link
Member

@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
Copy link
Author

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
Copy link
Member

>5 viftype TAP

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

@jyizheng
Copy link
Author

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 [email protected]
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
#47 (comment)
.

@thehajime
Copy link
Member

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

  • check the stacktrace by gdb (sudo gdb /bin/ping core), and paste the stacktrace here.
    • make sure you configured the limit by ulimit -c unlimited
  • whether the crash happens without your patch or not
  • your local environment (distribution, kernel, version, 32 or 64bits, etc)

@jyizheng
Copy link
Author

jyizheng commented Sep 1, 2015

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

@thehajime
Copy link
Member

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

@jyizheng 'rumpns_' is a prefix introduced by recently. See 751adb6 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
Copy link
Author

jyizheng commented Sep 2, 2015

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 [email protected]
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
751adb6
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
#47 (comment)
.

mm/bootmem.c Outdated
@@ -48,7 +48,7 @@ static int __init bootmem_debug_setup(char *buf)
early_param("bootmem_debug", bootmem_debug_setup);

#define bdebug(fmt, args...) ({ \
if (unlikely(bootmem_debug)) \
if (unlikely(bootmem_debug)) \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

revert unchanged white-spaces.

@thehajime
Copy link
Member

@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 (simple nuse crashes with wait_queue #45,merge master #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.

2)Use symbolic link in arch/lib/include
3)Resolve ERRORs reported by checkpatch.pl
   1) resovle undefined symbol rumpns_irq_stat
@@ -127,7 +128,7 @@ quiet_cmd_objsmk = OBJS-MK $@
done > $@

$(ARCH_DIR)/objs.mk: $(ARCH_DIR)/Makefile.print $(srctree)/.config $(ARCH_DIR)/Makefile
+$(call if_changed,objsmk)
+$(call if_changed,objsmk); \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

delete "; " at the end of line

(I meant revert it as it was.)

@thehajime
Copy link
Member

@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 (simple nuse crashes with wait_queue #45,merge master #46).

@jyizheng jyizheng changed the title Master port-mm-code Sep 8, 2015
@jyizheng
Copy link
Author

jyizheng commented Sep 8, 2015

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

@thehajime
Copy link
Member

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
Copy link
Author

jyizheng commented Sep 9, 2015

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 [email protected]
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
#47 (comment)
.

@thehajime
Copy link
Member

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
Copy link
Author

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 [email protected]
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
#47 (comment)
.

@thehajime
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants