[Linux-ia64] patching the syscall table via a module

[Linux-ia64] patching the syscall table via a module

[chas williams]

afs patches the syscall table when it loads as a module.  currently afs
pags and pioctl are implemented this way.  while this might change in
the future, its not going to happen any time soon.  i have run into a
problem with this recently, and noticed that sys_call_table is declared
as .rodata.  my older ia64 machines dont seem to enforce the read only,
but the new sn machine does!

is there a particular reason the sys_call_table needs to be .rodata and
not just .data?  could it be changed?  it seems the ia64 port is the
only port that does this.

Re: [Linux-ia64] patching the syscall table via a module

[David Mosberger]

>>>>> On Wed, 14 Aug 2002 09:31:45 -0400, chas williams <chas@cmf.nrl.navy.mil> said:

  chas> afs patches the syscall table when it loads as a module.
  chas> currently afs pags and pioctl are implemented this way.  while
  chas> this might change in the future, its not going to happen any
  chas> time soon.  i have run into a problem with this recently, and
  chas> noticed that sys_call_table is declared as .rodata.  my older
  chas> ia64 machines dont seem to enforce the read only, but the new
  chas> sn machine does!

  chas> is there a particular reason the sys_call_table needs to be
  chas> .rodata and not just .data?  could it be changed?  it seems
  chas> the ia64 port is the only port that does this.

I don't have a problem with changing that, but beware that recent Red
Hat kernels no longer export the sys_call_table symbol.  Personally, I
don't like this syscall-patching business either (for several
reasons).  While a bit rude, perhaps the Red Hat approach will force
those who care to find a better solution. ;-)

	--david

Re: [Linux-ia64] patching the syscall table via a module

[chas williams]

In message <15709.34404.525197.190900@napali.hpl.hp.com>,David Mosberger writes:
>reasons).  While a bit rude, perhaps the Red Hat approach will force
>those who care to find a better solution. ;-)

i believe the developers of afs are aware of this situation.  i dont
know if the necessary api has materialized yet though.  for the short
term, sys_call_table will need to be writable.