From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18170 invoked by alias); 20 Nov 2006 10:09:14 -0000 Received: (qmail 18159 invoked by uid 22791); 20 Nov 2006 10:09:12 -0000 X-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from ausmtp04.au.ibm.com (HELO ausmtp04.au.ibm.com) (202.81.18.152) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 20 Nov 2006 10:09:00 +0000 Received: from sd0208e0.au.ibm.com (d23rh904.au.ibm.com [202.81.18.202]) by ausmtp04.au.ibm.com (8.13.8/8.13.5) with ESMTP id kAKAJsJR162512 for ; Mon, 20 Nov 2006 21:19:55 +1100 Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.250.242]) by sd0208e0.au.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kAKABwAo145302 for ; Mon, 20 Nov 2006 21:12:03 +1100 Received: from d23av01.au.ibm.com (loopback [127.0.0.1]) by d23av01.au.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kAKA8U6Q002894 for ; Mon, 20 Nov 2006 21:08:30 +1100 Received: from [9.181.133.65] ([9.181.133.65]) by d23av01.au.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kAKA8TpR002830; Mon, 20 Nov 2006 21:08:30 +1100 Message-ID: <45617E9E.9000106@cn.ibm.com> Date: Mon, 20 Nov 2006 18:07:00 -0000 From: Li Guanglei Organization: IBM CSTL User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: Eugene Teo CC: systemtap@sourceware.org Subject: Re: Overflow? References: <455EB8E8.5000904@redhat.com> <45615DBD.8010804@cn.ibm.com> <45615E1E.3050005@redhat.com> In-Reply-To: <45615E1E.3050005@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2006-q4/txt/msg00472.txt.bz2 Hi, I once suspected it's a bug of SystemTap. But when I manually added a printk into the entry of sys_open: asmlinkage long sys_open(const char __user *filename, int flags, int mode) { long ret; printk(KERN_WARNING "lgl, sys_open: name:%s, flags:%d, mode:%d\n", filename, flags, mode); ... I got a lot of output like: Nov 20 18:00:01 localhost kernel: lgl, sys_open: name:/dev/null, flags:33345, mode:438 Nov 20 18:00:01 localhost kernel: lgl, sys_open: name:/etc/ld.so.cache, flags:0, mode:0 Nov 20 18:00:01 localhost kernel: lgl, sys_open: name:/lib/libselinux.so.1, flags:0, mode:-1074164556 Nov 20 18:00:01 localhost kernel: lgl, sys_open: name:/lib/libc.so.6, flags:0, mode:-1074164584 Nov 20 18:00:01 localhost kernel: lgl, sys_open: name:/lib/libdl.so.2, flags:0, mode:-1074164740 Nov 20 18:00:01 localhost kernel: lgl, sys_open: name:/lib/libsepol.so.1, flags:0, mode:-1074164768 Nov 20 18:00:01 localhost kernel: lgl, sys_open: name:/etc/selinux/config, flags:32768, mode:438 Nov 20 18:00:01 localhost kernel: lgl, sys_open: name:/proc/mounts, flags:32768, mode:438 Nov 20 18:00:01 localhost kernel: lgl, sys_open: name:/usr/lib/locale/locale-archive, flags:32768, mode:4 anyone has idea about why mode will be a negative value? Does glibc process the mode parameter of open() before calling sys_open? Thanks. - Guanglei Eugene Teo wrote: > Li Guanglei wrote: >> Hi, >> I tried a simple stap a.stp -o stap.out, where a.stp is: >> >> probe syscall.open >> { >> printf("flags:%d, mode:%d\n", flags, mode); >> } >> >> The stap.out is: >> ... >> flags:0, mode:-1074582532 >> flags:0, mode:-1074582680 >> flags:0, mode:-1074583132 >> flags:100352, mode:134561792 >> flags:32768, mode:0 >> flags:32962, mode:384 >> flags:100352, mode:1230149377 >> flags:32768, mode:0 >> flags:32768, mode:0 >> ... >> >> So this is not a LKET specific problem. but it seems strange to me that >> mode is a negative value. > > Yup. find it strange. > >> Eugene Teo wrote: >>> 6.71237 CPU:0 PID:2395 APPNAME:pcscd EVT_NAME:iosyscall.open.entry >>> filename:/dev/bus/usb/004,flags:100352,mode:-1209081572, >>> 6.71246 CPU:0 PID:2395 APPNAME:pcscd EVT_NAME:iosyscall.open.return >>> return:8, >>> 6.71272 CPU:0 PID:2395 APPNAME:pcscd EVT_NAME:iosyscall.open.entry >>> filename:/dev/bus/usb/004/001,flags:2,mode:1, >>> 6.71282 CPU:0 PID:2395 APPNAME:pcscd EVT_NAME:iosyscall.open.return >>> return:9, >>> 6.71308 CPU:0 PID:2395 APPNAME:pcscd EVT_NAME:iosyscall.open.entry >>> filename:/dev/bus/usb/004/001,flags:2,mode:1, >>> 6.71318 CPU:0 PID:2395 APPNAME:pcscd EVT_NAME:iosyscall.open.return >>> return:8, >>> 6.71332 CPU:0 PID:2395 APPNAME:pcscd EVT_NAME:iosyscall.open.entry >>> filename:/dev/bus/usb/005,flags:100352,mode:-1209081572, >>> >>> The flags and mode don't look right. Any idea why? >>> >>> Eugene >>> -- >>> eteo redhat.com ph: +65 6490 4142 http://www.kernel.org/~eugeneteo >>> gpg fingerprint: 47B9 90F6 AE4A 9C51 37E0 D6E1 EA84 C6A2 58DF 8823 >> > > > -- > eteo redhat.com ph: +65 6490 4142 http://www.kernel.org/~eugeneteo > gpg fingerprint: 47B9 90F6 AE4A 9C51 37E0 D6E1 EA84 C6A2 58DF 8823