PDA

View Full Version : ppc disassembly/patching



ronnythunder
03-17-2004, 05:58 PM
i'm contemplating a kernel patch that will get rid of these maddening messages from the kernel error log:
Mar 10 12:51:27 (none) kernel: tcp_keepalive: call keepopen(0x80b31920) . i'm tackling ppc first, but the same principle could be applied to mips.

what i've done so far: identified where in the code it's being logged, and generated a disassembly with objdump:
/usr/installs/tivo31/ppc/linux-2.1/net/ipv4/tcp_timer.c:378
{
printk(KERN_ERR "tcp_keepalive: call keepopen(0x%p)\n", sk);
70c: 3c 60 00 00 lis r3,0
710: 38 63 00 00 addi r3,r3,0
714: 7f e4 fb 78 mr r4,r31
718: 48 00 00 01 bl 718 <tcp_keepalive+0x8c>
my question is: is the hack as simple as replacing the "bl" instruction with a "nop"? my gut says yes, but i'm not brave enough to try it on one of my "live" boxes.

can anyone weigh in?

ronny

malfunct
03-17-2004, 06:54 PM
i'm contemplating a kernel patch that will get rid of these maddening messages from the kernel error log:
Mar 10 12:51:27 (none) kernel: tcp_keepalive: call keepopen(0x80b31920) . i'm tackling ppc first, but the same principle could be applied to mips.

what i've done so far: identified where in the code it's being logged, and generated a disassembly with objdump:
/usr/installs/tivo31/ppc/linux-2.1/net/ipv4/tcp_timer.c:378
{
printk(KERN_ERR "tcp_keepalive: call keepopen(0x%p)\n", sk);
70c: 3c 60 00 00 lis r3,0
710: 38 63 00 00 addi r3,r3,0
714: 7f e4 fb 78 mr r4,r31
718: 48 00 00 01 bl 718 <tcp_keepalive+0x8c>
my question is: is the hack as simple as replacing the "bl" instruction with a "nop"? my gut says yes, but i'm not brave enough to try it on one of my "live" boxes.

can anyone weigh in?

ronny

With my limited knowledge of PPC assembly I'd say what you propose is ok.

The first two lines clear r3, the second one moves the contents of r4 to r31. Both of these seem to be in preparation to make the call, not sure if its necessary to nop them too. The last line of course is the function call.

edit: Ok, I got some better info, the mr line is moving r31 (as best I can tell holds the "environmental pointer") into r4 (which is one of two registers for holding parameters to function calls). More and more its looking safe to nop the function call and be happy.

ronnythunder
03-17-2004, 07:07 PM
i may work up enough courage to try it.. thanks, malfunct. since i posted, i also wrote a simple program:
#include <stdio.h>
int main(int argc, char *argv[])
{
printf("hello, world\n");
printf("hello, earth\n");
return;
}
i then built it for ppc, copied it to two new executables "hellow" and "helloe". i nop'ed one call in each of the copies, and ran all three. they all behaved as expected. of course, this was in userspace; i'm assuming there's nothing that would make it tricky just because i'm in the kernel...

ronny

malfunct
03-17-2004, 08:56 PM
i may work up enough courage to try it.. thanks, malfunct. since i posted, i also wrote a simple program:
#include <stdio.h>
int main(int argc, char *argv[])
{
printf("hello, world\n");
printf("hello, earth\n");
return;
}
i then built it for ppc, copied it to two new executables "hellow" and "helloe". i nop'ed one call in each of the copies, and ran all three. they all behaved as expected. of course, this was in userspace; i'm assuming there's nothing that would make it tricky just because i'm in the kernel...

ronny

The only think I could imagine causing problems is if the registers were left dirty. I don't think register 4 or 3 are cleaned up by the call though, but if there are problems just nop the register clears and moves (the 3 lines before the bl, or is it bi) too

ozTiVoEd
04-27-2004, 12:23 PM
Those messages were giving me the sh*ts too, so I just commented out the printk statement on line 378 of net/ipv4/tcp_timer.c and recompiled the kernel

ronnythunder
04-27-2004, 12:34 PM
Those messages were giving me the sh*ts too, so I just commented out the printk statement on line 378 of net/ipv4/tcp_timer.c and recompiled the kernelsure, ordinarily that'd be my choice as well, but 99% of the audience here won't install a new kernel. plus, since i'm only running simple patches in mine, i don't mind another simple patch to avoid the hassles.

ronny