Skip to content

pthread_t is a pointer type on FreeBSD#209

Merged
1 commit merged intolkl:masterfrom
cemeyer:posix-host-freebsd
Aug 16, 2016
Merged

pthread_t is a pointer type on FreeBSD#209
1 commit merged intolkl:masterfrom
cemeyer:posix-host-freebsd

Conversation

@cemeyer
Copy link

@cemeyer cemeyer commented Aug 16, 2016

Use a needed cast.

Also, use pthread_self() in place of Linux-exclusive gettid().


This change is Reviewable

Use a needed cast.

Also, use pthread_self() in place of Linux-exclusive gettid().
@cemeyer
Copy link
Author

cemeyer commented Aug 16, 2016

By the way, the virtio_net_* routines don't compile on FreeBSD for a variety of reasons (minor tun/tap usage differences, epoll instead of kqueue/kevent). It wouldn't be too hard to port by someone with sufficient motivation. I'm not too familiar with tun/tap myself.

@ghost
Copy link

ghost commented Aug 16, 2016

:lgtm:

PR #202 should help with the main virtio issues, could you take a look when you have some time? I also wonder if there is a way to do a FreeBSD build on the CircleCI instance to catch such issues in the feature.


Reviewed 1 of 1 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.


Comments from Reviewable

@ghost ghost merged commit 1e6059f into lkl:master Aug 16, 2016
@cemeyer
Copy link
Author

cemeyer commented Aug 16, 2016

It looks like Circle CI doesn't do FreeBSD, unfortunately. I'll take a look at #202.

thehajime pushed a commit to libos-nuse/lkl-linux that referenced this pull request Feb 23, 2017
Dmitry reported a kernel warning:

 WARNING: CPU: 3 PID: 2936 at net/kcm/kcmsock.c:627
 kcm_write_msgs+0x12e3/0x1b90 net/kcm/kcmsock.c:627
 CPU: 3 PID: 2936 Comm: a.out Not tainted 4.10.0-rc6+ lkl#209
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
 Call Trace:
  __dump_stack lib/dump_stack.c:15 [inline]
  dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
  panic+0x1fb/0x412 kernel/panic.c:179
  __warn+0x1c4/0x1e0 kernel/panic.c:539
  warn_slowpath_null+0x2c/0x40 kernel/panic.c:582
  kcm_write_msgs+0x12e3/0x1b90 net/kcm/kcmsock.c:627
  kcm_sendmsg+0x163a/0x2200 net/kcm/kcmsock.c:1029
  sock_sendmsg_nosec net/socket.c:635 [inline]
  sock_sendmsg+0xca/0x110 net/socket.c:645
  sock_write_iter+0x326/0x600 net/socket.c:848
  new_sync_write fs/read_write.c:499 [inline]
  __vfs_write+0x483/0x740 fs/read_write.c:512
  vfs_write+0x187/0x530 fs/read_write.c:560
  SYSC_write fs/read_write.c:607 [inline]
  SyS_write+0xfb/0x230 fs/read_write.c:599
  entry_SYSCALL_64_fastpath+0x1f/0xc2

when calling syscall(__NR_write, sock2, 0x208aaf27ul, 0x0ul) on a KCM
seqpacket socket. It appears that kcm_sendmsg() does not handle len==0
case correctly, which causes an empty skb is allocated and queued.
Fix this by skipping the skb allocation for len==0 case.

Reported-by: Dmitry Vyukov <dvyukov@google.com>
Cc: Tom Herbert <tom@herbertland.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This pull request was closed.
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.

1 participant