Re: How to find system call in kernel source code?

[Giorgos Keramidas]

On 2005-11-25 21:09, David Kelly [EMAIL PROTECTED] wrote:
 The sendfile(2) function is apparently a kernel system call. I've
 find /usr/src -type f -exec grep -il sendfile {} \; and several
 variations yet not found where the code which performs sendfile() is
 located. Is system call 393. Guessing I'm just missing the dispatch
 table.

The default implementation of sendfile() is in the file:

src/sys/kern/uipc_syscalls.c

Look for '^sendfile' with grep(1).

The arguments of sendfile() are copied in a struct sendfile_args{} and
then passed to do_sendfile().  The definition of the sendfile_args
struct is in src/sys/sys/sysproto.h and it looks a bit scary with all
that padding and macro 'magic' going on around it.

 This is also related to P/R bin/89100. At least for me, RELENG_6
 fails to send files greater than 4 GB after a few hours or days on
 the disk. Freshly copied files work fine. No problem copying the file
 with cp. And md5 confirms the contents have not changed.

This sounds suspiciously like a 32-bit value overflowing somewhere :-/

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]

How to find system call in kernel source code?

[David Kelly]

The sendfile(2) function is apparently a kernel system call. I've  
find /usr/src -type f -exec grep -il sendfile {} \; and several  
variations yet not found where the code which performs sendfile() is  
located. Is system call 393. Guessing I'm just missing the dispatch  
table.


This is also related to P/R bin/89100. At least for me, RELENG_6  
fails to send files greater than 4 GB after a few hours or days on  
the disk. Freshly copied files work fine. No problem copying the file  
with cp. And md5 confirms the contents have not changed.


Built a special ftpd with -g compiler flag. Am not good enough with  
gdb to breakpoint a forked child, which apparently ftpd -D does  
immediately. So sprinkled enough printf's to confirm sendfile() is  
coming up short, is restarted, and errs finally producing the  
premature EOF error message. Yet I've done enough that I'm  
confident the arguments are being passed properly and of sufficient  
size.


The files are between 4G and 8G and when the failure occurs the  
transfer is always filesize modulo 4G. Exactly as if a 4 byte length  
truncated. But strange in that it works on a new file today but  
doesn't after the file is a few hours or days old. Once a file is old  
enough to fail all files on that filesystem written before it also  
fail. Not related to timestamp as cp -p will repair the file  
temporarily.


No errors in /var/log/messages or dmesg. No errors manually launching  
fsck to check the filesystems. And everything but the sendfile()  
system call seems to work.


--
David Kelly N4HHE, [EMAIL PROTECTED]

Whom computers would destroy, they must first drive mad.

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]