Muli Ben-Yehuda's journal

There was some interest on lkml from Pavel Machek and
offline from Randy
Dunlap, in the ‘remove %n support from printk’, so I have
resurrected it and fixed the sole user of ‘%n’ in the kernel.

patches/printk-dont-supoprt-percent-n-2.6.5-rc3-B1 – the
printf man page has this to say about ‘%n’:

“The number of characters written so far is stored into the
integer indicated by the int * (or variant) pointer
argument. No argument is converted.”

Very little code actually uses %n for that. Now days, %n has
a much more common use – in printf format string
exploits. Since no kernel code appears to be using %n (thus
said grep), this patch removes support for it. To preempt
the obvious argument, I agree that printk should look and
behave as much as possible as printf – except where it’s
harmful. We don’t support floating point, for example, and I
doubt we should support %n – although I don’t strongly care
one way or another.

The patch is a bit more intrusive than I would’ve
liked. fs/proc/task_mmu.c:show_map() called seq_printf with
%n, in order to calculate the proper number of spaces to add
in each line in the /proc/$PID/map output for named maps. I
changed seq_printf to return the number of characters
written (not including the final ) as returned from
vcnsprintf. This required two changes to the only two
callers of seq_printf who bothered to check the return
value. One of them (cris/arch-v10/kernel/setup.c) was
trivial, and the other (arch/i386/kernel/cpu/mtrr/if.c)
didn’t do anything with the return value anyway. (prev:
-A1)