Hi Seth,
Seth Thielemann <sthielemann@xxxxxxxxxxxxx> writes:
> - Observed segfaults during cifs share backups, core investigation and strace revealed that files were being opened
> but upon read the syscall was returning a 32-bit error code:
On my system (x86_64)
- ssize_t is signed and long which is 8 bytes
- int is signed and 4 bytes
That is a weird bug. Casting (long)-13 to int is ok because -13 is
representable in both.
> - Above is an impossible situation, the sign extension was at fault. The two functions using the trinary assignment of rc
> in the cifs asio context:
You mean this line in collect_uncached_write_data() right? I think the
current code changed from your version, it's in a different function now.
ctx->rc = (rc == 0) ? ctx->total_len : rc;
> 188db: 45 85 e4 test r12d,r12d
Ok I'm assuming r12d is the rc var.
we test if rc == 0 (low 32bit of r12)
> 188de: 44 89 e0 mov eax,r12d <- msl cleared
Now we set eax (low 32bits) to rc (what is msl? most significat l...?).
But the high 32bits are unknown
> 188e1: 0f 84 6a 01 00 00 je 18a51 <cifs_uncached_writev_complete+0x371>
if rc was zero, we take the jump
> 188e7: 48 8b 7c 24 18 mov rdi,QWORD PTR [rsp+0x18]
> 188ec: 49 89 85 a8 00 00 00 mov QWORD PTR [r13+0xa8],rax <- saved
Otherwise we store rax (unknown high 32 bits + low 32bit of rc) in the ctx.
So -13 is
0xfffffff3 (int)
but if you copy it in low part of a zero 64bits you end up with (wrong)
0x00000000fffffff3 (long)
which is 4294967283... should have been 0xfffffffffffffff3
I'm no compiler expert but this looks like possible wrong generated
code for the cast :/
Cheers,
--
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München)
