Bug 11112

We don't correctly check the full size of buffers printed with %m/%M.  When the
precision is dynamic, the entire range is checked, but with a fixed precision we
are only checking that the first byte can be deref'ed.  This poses an issue if
the starting address is valid but then falls off a page:

$ stap -ve 'probe process("./stap").function("main") {
  printf("%.1000000M\n", $argv) }' -c './stap -V'

stap_24f99805b992175d160c5afb97a0ad20_1268: systemtap: 1.0/0.143, base:
ffffffffa01ec000, memory: 54data/22text/0ctx/13net/19alloc kb, probes: 1
BUG: unable to handle kernel paging request at 00007fff76162000
IP: [<ffffffffa01ecee9>] _stp_vsnprintf+0x928/0xc10
[stap_24f99805b992175d160c5afb97a0ad20_1268]
PGD 1dd6e067 PUD 5ffc067 PMD 1bc1d067 PTE 0
Oops: 0000 [#2] SMP 
last sysfs file: /sys/module/virtio_ring/sections/__verbose
CPU 0 
Modules linked in: stap_24f99805b992175d160c5afb97a0ad20_1268
stap_db7716791ff58e1f3d03381e38c1171e_1394 uprobes nfs lockd fscache nfs_acl
auth_rpcgss autofs4 sunrpc ip6t_REJECT nf_conntrack_ipv6 ip6table_filter
ip6_tables ipv6 i2c_piix4 i2c_core virtio_net virtio_balloon virtio_blk floppy
virtio_pci virtio_ring virtio [last unloaded:
stap_2161bcb8f5cec40bb660a1d6982e24da_1260]
Pid: 6668, comm: stap Tainted: G      D    2.6.31.6-166.fc12.x86_64 #1 
RIP: 0010:[<ffffffffa01ecee9>]  [<ffffffffa01ecee9>] _stp_vsnprintf+0x928/0xc10
[stap_24f99805b992175d160c5afb97a0ad20_1268]
RSP: 0000:ffff880003d29b48  EFLAGS: 00010287
RAX: 00000000000f4240 RBX: ffffc9000020a3f4 RCX: 00007fff76162000
RDX: 00007fff76160fe8 RSI: 0000000000001018 RDI: ffff880003d29bb9
RBP: ffff880003d29bf8 R08: 00000000fffffffe R09: 00000000000f4240
R10: 0000000000002000 R11: 0000000000003608 R12: ffff880003d29c08
R13: ffffc9000020a3c3 R14: 0000000000000000 R15: ffffffffa01f2531
FS:  00007fafd5e2f720(0000) GS:ffff8800019b6000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fff76162000 CR3: 0000000003698000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400
Process stap (pid: 6668, threadinfo ffff880003d28000, task ffff88001d9a8000)
Stack:
 ffff880003d2e630 ffff88001d9a8000 ffff880003d29be8 ffff880003d29ba8
<0> ffff88001d14f000 0000000000000000 0000000000002000 0000000000000000
<0> ffff880000000010 ffff880003d29c68 ffff880003d29c28 0000000000000000
Call Trace:
 [<ffffffffa01ed254>] _stp_printf+0x48/0x4a
[stap_24f99805b992175d160c5afb97a0ad20_1268]
 [<ffffffff8101a406>] ? genregs_get+0x34/0x88
 [<ffffffffa01f1524>] probe_1885+0x287/0x2ea
[stap_24f99805b992175d160c5afb97a0ad20_1268]
 [<ffffffffa01ee950>] enter_uprobe_probe+0x173/0x2d4
[stap_24f99805b992175d160c5afb97a0ad20_1268]
 [<ffffffffa018e640>] uprobe_report_signal+0x532/0x9be [uprobes]
 [<ffffffff8105dc6b>] ? __dequeue_signal+0xed/0x122
 [<ffffffff8105f8cb>] ? dequeue_signal+0xab/0x11d
 [<ffffffff8108dc31>] utrace_get_signal+0x33d/0x5bc
 [<ffffffff810c1523>] ? unlock_page+0x14/0x16
 [<ffffffff810d6a5e>] ? __do_fault+0x38d/0x3c4
 [<ffffffff8105fa29>] get_signal_to_deliver+0xec/0x36d
 [<ffffffff8101106f>] do_notify_resume+0x89/0x748
 [<ffffffff811ff209>] ? __up_read+0x76/0x81
 [<ffffffff8106af52>] ? up_read+0xe/0x10
 [<ffffffff8141b3a2>] paranoid_userspace+0x46/0x50
Code: 41 8d 70 01 39 f1 7c ea 41 80 3f 4d 48 89 d9 75 60 48 8b bd 68 ff ff ff 48
c7 c6 1f 1c 1f a0 b9 11 00 00 00 f3 a4 48 89 d1 eb 29 <0f> be 31 48 c1 ee 04 83
e6 0f 40 8a 74 35 b0 40 88 33 48 0f be 
RIP  [<ffffffffa01ecee9>] _stp_vsnprintf+0x928/0xc10
[stap_24f99805b992175d160c5afb97a0ad20_1268]
 RSP <ffff880003d29b48>
CR2: 00007fff76162000
---[ end trace a772de976987833d ]---
Task died at uprobe probepoint:  pid/tgid = 6668/6668, probepoint = 0x40abf0

This leaves the stap task stuck in the kernel chewing full CPU, though the
system is otherwise still usable.