Re: arm64: fp-stress: BUG: KFENCE: memory corruption in fpsimd_release_task

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, May 17, 2023 at 10:30:29PM +0300, Dan Carpenter wrote:

> I don't know this code at all so probably this is dumb...  I don't
> undestand how vec_set_vector_length() ensures that sme_state_size()
> stays in sync with the actual size allocated in sme_alloc()

>    866          vl = find_supported_vector_length(type, vl);

> type is ARM64_VEC_SVE.  I've looked at this function for a while and
> I don't see anything which ensures that "vl" is less than the current
> value.

It could be either ARM64_VEC_SVE or ARM64_VEC_SME.

>    917          task_set_vl(task, type, vl);

> "vl" is set here.  This is fine if we are setting it to a smaller value,
> but if we are setting it to a larger value then I think we need to
> realloc the ->sme_state buffer.

> When we call sme_alloc() it will say the buffer is already allocated
> and just zero out what we need for "vl", but the existing buffer is too
> small.

If we are setting the SVE vector length we do not need to reallocate the
SME state since the size of the data stored in the sme_state buffer is
influenced only by the SME vector length, not the SVE vector length.  We
unconditionally free the SVE state (causing it to be reallocated when
needed) since the size needed for it depends on both vector lengths.

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux