Unfortunately, I just found another bug in this code, similar to one you
already fixed in the sock_get_timestamp handler:
You can't do the copy_from_user like this if the arguments have different
types. Changing the declaration 'struct x25_subscrip_struct x25_subscr;'
to 'struct compat_x25_subscrip_struct x25_subscr;' should fix this problem,
but please verify that it really works with a test case that relies on the
contents of x25_subscr->extended.
Arnd <><
Hi Arnd
Here is the corrected version.
Using the x25_subscrip_struct structure (extend value = 1) set
the following values in the kernel after copy_from_user
global facility mask is F00000000
Extended value is 1
Using the 32 bit compat_x25_subscrip_struct
set the following values in the struct after
copying from user.
global facility mask is 0000000F
Extended value is 1
The nb->global_facil_mask was then
set to 0000000F when extended was 1
Thanks for this,
/Shaun
diff -uprN -X dontdiff linux-2.6.15-vanilla/net/x25/af_x25.c
linux-2.6.15/net/x25/af_x25.c
Hi Arnd
Assuming you are happy with the state of the patches, is there anyway
for me to know if they will become a part of the next release?
Usually submitted/reviewed patches to netdev does not not always
guarantee they will be acccepted/signed-off.
Any advice would be useful
Thanks
Shaun
Am Wednesday 18 January 2006 07:56 schrieb Shaun Pereira:
Assuming you are happy with the state of the patches, is there anyway
for me to know if they will become a part of the next release?
I don't see any more technical problems with your patches. You still need
to proper patch description and Signed-off-by: line like it is described
in Documentation/SubmittingPatches.
You can add an 'Acked-by: Arnd Bergmann [off-list ref]' line to the four
patches you posted last if you like.
Usually submitted/reviewed patches to netdev does not not always
guarantee they will be acccepted/signed-off.
Any advice would be useful
I'm not that familiar with the process for non-driver patches for netdev
(nor for device drivers as it seems ;-)), but my understanding is that you
should address those to Jeff Garzik as well, asking for inclusion in the
netdev-2.6 git tree in your introductory '[PATCH 0/4]' mail.
Since the official merge window for 2.6.16 is now over (2.6.16-rc1 has been
released), it may have to wait for 2.6.17 to become part of the mainline
kernel, that probably depends on Jeffs judgement.
I would think it can still go in since it is a bug fix for the execution of
32 bit programs using x25 ioctls, but it's clearly not my decision ;-).
Arnd <><
I'm not that familiar with the process for non-driver patches for
netdev (nor for device drivers as it seems ;-)), but my
understanding is that you should address those to Jeff Garzik as
well, asking for inclusion in the netdev-2.6 git tree in your
introductory '[PATCH 0/4]' mail.
Those should be CC:'d to me, not Jeff, he has enough to review
and merge :)