Re: Test results from v4

[Chuck Lever III <chuck.lever@oracle.com>]

> On Feb 16, 2023, at 11:03 AM, Chuck Lever III <chuck.lever@oracle.com> wrote:
> 
> 
> 
>> On Feb 16, 2023, at 10:58 AM, Hannes Reinecke <hare@suse.de> wrote:
>> 
>> Hi Chuck,
>> 
>> I've given v4 a spin on my testbed, and ... well, things could've been better :-(
>> 
>> Biggest issue is that I've lost connectivity to my testbed (openssl-based). It always kicks me back with:
>> 
>> SSL routines:tls_choose_sigalg:no suitable signature algorithm
>> 
>> for whatever reasons.
>> I try to fiddle with the priority string, but it's _really_ annoying.
> 
> Haven't seen that, could be a PSK-specific thing?
> 
> 
>> And also reference counting is wrong:
> 
> That's not terribly surprising.
> 
> 
>> unreferenced object 0xffff9989c22a0018 (size 24):
>> comm "tlshd", pid 2332, jiffies 4294964098 (age 1513.848s)
>> hex dump (first 24 bytes):
>>   00 00 00 00 00 00 00 00 a8 31 85 c1 89 99 ff ff  .........1......
>>   00 00 00 00 00 00 00 00                          ........
>> backtrace:
>>   [<ffffffffa00ad3e4>] security_file_alloc+0x24/0x90
>>   [<ffffffff9ffbb747>] __alloc_file+0x57/0xc0
>>   [<ffffffff9ffbbbc3>] alloc_empty_file+0x43/0xf0
>>   [<ffffffff9ffbbcad>] alloc_file+0x2d/0x170
>>   [<ffffffff9ffbbea7>] alloc_file_pseudo+0xa7/0x100
>>   [<ffffffffa05158a9>] sock_alloc_file+0x39/0xa0
>>   [<ffffffffa073594b>] handshake_genl_cmd_accept+0x19b/0x2a0
>>   [<ffffffffa05d44e7>] genl_family_rcv_msg_doit.isra.19+0xf7/0x120
>>   [<ffffffffa05d495f>] genl_rcv_msg+0x19f/0x2a0
>>   [<ffffffffa05d3286>] netlink_rcv_skb+0x56/0x110
>>   [<ffffffffa05d3cc4>] genl_rcv+0x24/0x40
>>   [<ffffffffa05d277b>] netlink_unicast+0x1bb/0x290
>>   [<ffffffffa05d2bc5>] netlink_sendmsg+0x365/0x4d0
>>   [<ffffffffa0516e9f>] sock_sendmsg+0x5f/0x70
>>   [<ffffffffa0517211>] ____sys_sendmsg+0x201/0x280
>>   [<ffffffffa0519ca8>] ___sys_sendmsg+0x88/0xd0
>> 
>> But I guess you've found these already.
> 
> Nope, I haven't seen that either, but I'm not looking for
> memory leaks yet. My focus right now is to address netdev's
> concerns, so I haven't enabled kmemleak (as it slows down
> the dev loop). Not crashing is a higher priority than
> leaking right at the moment.

Or, to put this another way: I'm trying to address the
reference counting issues by addressing Paolo's request
for adding a socket destructor callback.


--
Chuck Lever