On Fri, Aug 24, 2018 at 06:33:29PM -0600, Jens Axboe wrote:
> On 8/24/18 6:21 PM, Jens Axboe wrote:
> > On 8/24/18 5:16 PM, Ming Lei wrote:
> >> Hi,
> >>
> >> On Fri, Aug 24, 2018 at 04:20:41PM -0600, Jens Axboe wrote:
> >>> Hi,
> >>>
> >>> Was testing other things today, but ended up with this:
>
On 8/24/18 6:21 PM, Jens Axboe wrote:
> On 8/24/18 5:16 PM, Ming Lei wrote:
>> Hi,
>>
>> On Fri, Aug 24, 2018 at 04:20:41PM -0600, Jens Axboe wrote:
>>> Hi,
>>>
>>> Was testing other things today, but ended up with this:
>>>
>>> # echo "write through" > /sys/block/sde/device/scsi_disk/4:0:0:0/cache
On 8/24/18 5:16 PM, Ming Lei wrote:
> Hi,
>
> On Fri, Aug 24, 2018 at 04:20:41PM -0600, Jens Axboe wrote:
>> Hi,
>>
>> Was testing other things today, but ended up with this:
>>
>> # echo "write through" > /sys/block/sde/device/scsi_disk/4:0:0:0/cache_type
>>
>> hanging. Looking closer, the reques
Hi,
On Fri, Aug 24, 2018 at 04:20:41PM -0600, Jens Axboe wrote:
> Hi,
>
> Was testing other things today, but ended up with this:
>
> # echo "write through" > /sys/block/sde/device/scsi_disk/4:0:0:0/cache_type
>
> hanging. Looking closer, the request is successfully queued and the
> caller is w
On 8/24/18 4:20 PM, Jens Axboe wrote:
> Hi,
>
> Was testing other things today, but ended up with this:
>
> # echo "write through" > /sys/block/sde/device/scsi_disk/4:0:0:0/cache_type
>
> hanging. Looking closer, the request is successfully queued and the
> caller is waiting on rq execution and
Hi,
Was testing other things today, but ended up with this:
# echo "write through" > /sys/block/sde/device/scsi_disk/4:0:0:0/cache_type
hanging. Looking closer, the request is successfully queued and the
caller is waiting on rq execution and completion, but the request is
sitting in the hctx->di
On Fri, Aug 24, 2018 at 01:37:12PM -0500, Mike Christie wrote:
> Also, let idr_alloc return value through instead of replacing it with -ENOMEM,
> as it is already a negative value and caller checks sign, not exact value.
I bet it's less code to just return -ENOMEM in all situations instead of
maki
On Fri, Aug 24, 2018 at 01:37:10PM -0500, Mike Christie wrote:
> The following patchset is a round up of login fixes that have been
> on the list and in Mathew's tree. They fix a couple of bugs in the
> iscsi login failure handling path.
>
> The patches were made against Martin's 4.19/scsi-queue b
If iscsi_login_init_conn fails it can free conn_ops.
__iscsi_target_login_thread will then call iscsi_target_login_sess_out
which will also free it.
This fixes the problem by organizing conn allocation/setup into parts
that are needed through the life of the conn and parts that are only
needed for
The following patchset is a round up of login fixes that have been
on the list and in Mathew's tree. They fix a couple of bugs in the
iscsi login failure handling path.
The patches were made against Martin's 4.19/scsi-queue branch.
Matthew, the first patch is one that I had sent to you that had a
From: Vincent Pelletier
Fixes a use-after-free reported by KASAN when later
iscsi_target_login_sess_out gets called and it tries to access
conn->sess->se_sess:
Disabling lock debugging due to kernel taint
iSCSI Login timeout on Network Portal [::]:3260
iSCSI Login negotiation failed.
===
The problem is that iscsi_login_zero_tsih_s1 sets conn->sess early in
iscsi_login_set_conn_values. If the function fails later like when we
alloc the idr it does kfree(sess) it leaves the conn->sess pointer set.
iscsi_login_zero_tsih_s1 then returns -Exyz and we then call
iscsi_target_login_sess_ou
Mike,
> It looks like there is also going to be a conflict with another patch
> upstream. I will just round up all the patches and resend in one set
> rebased against your current for-4.19 tree.
Super, thanks!
--
Martin K. Petersen Oracle Linux Engineering
On 08/23/2018 09:11 PM, Martin K. Petersen wrote:
>
> Mike,
>
>> this was made over that patch that was going through Mathew's tree. I
>> do not know exactly which one though. It is in next here
>
> Doesn't look like Linus will pull Matthew's tree for 4.19.
>
It looks like there is also going t
On 28/06/2018 23:07, Martin K. Petersen wrote:
John,
OK, but please be aware that there may be a more serious issue fixed
here than the WARN, in that we could try to free memory embedded in a
structure.
We can still get it into 4.18.x. I'm just wary of submitting stuff to
Linus that has had
15 matches
Mail list logo
