sr_block_get() returns dma_alloc(length, PR_NOWAIT | PR_ZERO) which may be
NULL if the memory pool is depleted.
The result is used as 'dst' argument to memcpy() in the following call to
sr_raid5_regenerate(), resulting in a possible NULL dereference.
ok?
Index: softraid_raid5.c
Joseph Mayer wrote this message on Sat, Mar 21, 2020 at 02:57 +:
> Thunderbolt support would be awesome. Especially it would allow the use
> of additional M.2 NVMe SSD:s on a laptop at full performance.
>
> Thunderbolt support would also allow the use of an AMDGPU via a PCIe
> chassi, as well
To wrap this up and get if off my plate, here is the updated patch,
and a testcase program together with what should be (imvho) the
correct output.
Please do NOT assume that I'm insisting or that I have any personal
interest to have this included, considered, etc.
The testcase is a stripped down
On 3/19/20 10:36 AM, Stuart Henderson wrote:
On 2020/03/19 09:27, Renaud Allard wrote:
After some days of testing I didn't see any real problem with that diff.
It's working as expected.
Also, I found out that putting "so-reuseport: no" completely stops all the
stalling problems I had with
pipex_destroy_session should be called under NET_LOCK but if it called
by this sequence: pppacclose -> pipex_iface_fini -> pipex_iface_stop
-> pipex_destroy_session, NET_LOCK is missing and kernel crashes.
pipex_iface_stop calls are protected by NET_LOCK, so it should be also
protected within
