William,
You are right, gsh_calloc is getting invoked (even for 2.3 code).
Interestingly for the core we got in testing, has almost all the fields
filled with 0xFF. So wondering is it something to do with underneath glibc
or RHEL in general.
Here is the gdb o/p indicating the same.
(gdb) p reqdata->r_u.req.svc
$7 = {rq_prog = 4294967295, rq_vers = 4294967295, rq_proc = 4294967295,
rq_cred = {oa_flavor = -1,
oa_base = 0xffffffffffffffff <Address 0xffffffffffffffff out of
bounds>, oa_length = 4294967295},
rq_clntcred = 0x7f183c0a83e0, rq_xprt = 0x7f1932423830,
rq_clntname = 0xffffffffffffffff <Address 0xffffffffffffffff out of
bounds>,
rq_svcname = 0xffffffffffffffff <Address 0xffffffffffffffff out of
bounds>, rq_msg = 0x7f183c0a8020, rq_context = 0x0,
rq_u1 = 0xffffffffffffffff, rq_u2 = 0xffffffffffffffff, rq_cksum =
18446744073709551615, rq_xid = 4294967295, rq_verf = {
oa_flavor = -1, oa_base = 0xffffffffffffffff <Address
0xffffffffffffffff out of bounds>, oa_length = 4294967295},
rq_auth = 0xffffffffffffffff, rq_ap1 = 0xffffffffffffffff, rq_ap2 =
0xffffffffffffffff, rq_raddr = {ss_family = 65535,
__ss_align = 18446744073709551615, __ss_padding = '\377' <repeats 112
times>}, rq_daddr = {ss_family = 65535,
__ss_align = 18446744073709551615, __ss_padding = '\377' <repeats 112
times>}, rq_raddr_len = 0, rq_daddr_len = 0}
(gdb) p reqdata->r_u.req
$8 = {xprt = 0x7f1932423830, svc = {rq_prog = 4294967295, rq_vers =
4294967295, rq_proc = 4294967295, rq_cred = {
oa_flavor = -1, oa_base = 0xffffffffffffffff <Address
0xffffffffffffffff out of bounds>, oa_length = 4294967295},
rq_clntcred = 0x7f183c0a83e0, rq_xprt = 0x7f1932423830,
rq_clntname = 0xffffffffffffffff <Address 0xffffffffffffffff out of
bounds>,
rq_svcname = 0xffffffffffffffff <Address 0xffffffffffffffff out of
bounds>, rq_msg = 0x7f183c0a8020, rq_context = 0x0,
rq_u1 = 0xffffffffffffffff, rq_u2 = 0xffffffffffffffff, rq_cksum =
18446744073709551615, rq_xid = 4294967295,
rq_verf = {oa_flavor = -1, oa_base = 0xffffffffffffffff <Address
0xffffffffffffffff out of bounds>,
oa_length = 4294967295}, rq_auth = 0xffffffffffffffff, rq_ap1 =
0xffffffffffffffff, rq_ap2 = 0xffffffffffffffff,
rq_raddr = {ss_family = 65535, __ss_align = 18446744073709551615,
__ss_padding = '\377' <repeats 112 times>},
rq_daddr = {ss_family = 65535, __ss_align = 18446744073709551615,
__ss_padding = '\377' <repeats 112 times>},
rq_raddr_len = 0, rq_daddr_len = 0}, lookahead = {flags = 4294967295,
read = 65535, write = 65535}, arg_nfs = {
arg_getattr3 = {object = {data = {data_len = 4294967295,
data_val = 0xffffffffffffffff <Address 0xffffffffffffffff out of
bounds>}}}, arg_setattr3 = {object = {data = {
data_len = 4294967295, data_val = 0xffffffffffffffff <Address
0xffffffffffffffff out of bounds>}},
new_attributes = {mode = {set_it = -1, set_mode3_u = {mode =
4294967295}}, uid = {set_it = -1, set_uid3_u = {
uid = 4294967295}}, gid = {set_it = -1, set_gid3_u = {gid =
4294967295}}, size = {set_it = -1, set_size3_u = {
size = 18446744073709551615}}, atime = {
set_it = (SET_TO_SERVER_TIME | SET_TO_CLIENT_TIME | unknown:
4294967292), set_atime_u = {atime = {
tv_sec = 4294967295, tv_nsec = 4294967295}}}, mtime = {
set_it = (SET_TO_SERVER_TIME | SET_TO_CLIENT_TIME | unknown:
4294967292), set_mtime_u = {mtime = {
tv_sec = 4294967295, tv_nsec = 4294967295}}}}, guard = {check
= -1, sattrguard3_u = {obj_ctime = {
tv_sec = 4294967295, tv_nsec = 4294967295}}}}, arg_lookup3 =
{what = {dir = {data = {data_len = 4294967295,
data_val = 0xffffffffffffffff <Address 0xffffffffffffffff out
of bounds>}},
name = 0xffffffffffffffff <Address 0xffffffffffffffff out of
bounds>}}, arg_access3 = {object = {data = {
data_len = 4294967295, data_val = 0xffffffffffffffff <Address
0xffffffffffffffff out of bounds>}},
access = 4294967295}, arg_readlink3 = {symlink = {data = {data_len =
4294967295,
data_val = 0xffffffffffffffff <Address 0xffffffffffffffff out of
bounds>}}}, arg_read3 = {file = {data = {
data_len = 4294967295, data_val = 0xffffffffffffffff <Address
0xffffffffffffffff out of bounds>}},
offset = 18446744073709551615, count = 4294967295}, arg_write3 =
{file = {data = {data_len = 4294967295,
data_val = 0xffffffffffffffff <Address 0xffffffffffffffff out of
bounds>}}, offset = 18446744073709551615,
count = 4294967295, stable = (DATA_SYNC | FILE_SYNC | unknown:
4294967292), data = {data_len = 4294967295,
data_val = 0xffffffffffffffff <Address 0xffffffffffffffff out of
bounds>}}, arg_create3 = {where = {dir = {data = {
data_len = 4294967295, data_val = 0xffffffffffffffff <Address
0xffffffffffffffff out of bounds>}},
name = 0xffffffffffffffff <Address 0xffffffffffffffff out of
bounds>}, how = {
mode = (GUARDED | EXCLUSIVE | unknown: 4294967292), createhow3_u =
{obj_attributes = {mode = {set_it = -1,
---Type <return> to continue, or q <return> to quit---
Let me know if any one observed this kind of behavior.
Thanks in advance.
On Mon, Oct 30, 2017 at 9:38 PM, William Allen Simpson <
william.allen.simp...@gmail.com> wrote:
> On 10/27/17 7:56 AM, Sachin Punadikar wrote:
>
>> Ganesha 2.3 got segfault with below :
>> [...]
>> After analyzing the core and related code found that - In
>> "thr_decode_rpc_request" function, if call to SVC_RECV fails, then
>> free_nfs_request is invoked to free the resources. But so far one of the
>> field "reqdata->r_u.req.svc.rq_auth" is not initialized nor allocated,
>> which is leading to segfault.
>>
>> The code in this area is same for Ganesha 2.3 and 2.5.
>> I have created below patch to overcome this issue. Please review and if
>> suitable merge with Ganesha 2.5 stable.
>> https://github.com/sachinpunadikar/nfs-ganesha/commit/91baff
>> a8bd197c78eff106f42927a370155ae6b4
>>
>> While your code should be harmless, at least in V2.5 that is already
> initialized with gsh_calloc(). So it should already be NULL.
>
> The answer of course as always is to upgrade.... There are a lot of
> fixes in V2.4 and V2.5, the current stable branch!
>
--
with regards,
Sachin Punadikar
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
