Re: Overflow?

Re: Overflow?

[Li Guanglei]

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

Re: Overflow?

[Frank Ch. Eigler]

Li Guanglei <guanglei@cn.ibm.com> writes:

> asmlinkage long sys_open(const char __user *filename, int flags, int mode)
> [...]
> Nov 20 18:00:01 localhost kernel: lgl, sys_open:
> name:/lib/libselinux.so.1, flags:0, mode:-1074164556

The mode argument is optional, and is only set when flags includes
O_CREAT.

> [...]  anyone has idea about why mode will be a negative value?
> [...]

(By the way, those large negative numbers you were seeing are in the
neighbourhood of the thread stack.)

- FChE