On 2019-07-03 1:20 p.m., Sagi Grimberg wrote:
>
>>> Can we handle this in the core instead (also so we'd be consistent
>>> across transports)?
>>
>> Yes, that would be much better if we can sort out some other issues
>> below...
>>
>>> How about this untested patch instead?
>>
>> I've found a c
Can we handle this in the core instead (also so we'd be consistent
across transports)?
Yes, that would be much better if we can sort out some other issues below...
How about this untested patch instead?
I've found a couple of problems with the patch:
1) port->subsystems will always be em
On 2019-07-03 11:01 a.m., Logan Gunthorpe wrote:
> Hey,
>
> NVME target ports can be removed while there are still active
> controllers. Largely this is fine, except some admin commands
> can access the req->port (for example, id-ctrl uses the port's
> inline date size as part of it's response)
On 2019-07-03 11:33 a.m., Sagi Grimberg wrote:
>> NVME target ports can be removed while there are still active
>> controllers. Largely this is fine, except some admin commands
>> can access the req->port (for example, id-ctrl uses the port's
>> inline date size as part of it's response). This w
Hey,
Hey Logan,
NVME target ports can be removed while there are still active
controllers. Largely this is fine, except some admin commands
can access the req->port (for example, id-ctrl uses the port's
inline date size as part of it's response). This was found
while testing with KASAN.
Two p
Hey,
NVME target ports can be removed while there are still active
controllers. Largely this is fine, except some admin commands
can access the req->port (for example, id-ctrl uses the port's
inline date size as part of it's response). This was found
while testing with KASAN.
Two patches follow w
6 matches
Mail list logo
