lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:	Thu, 24 Dec 2009 10:08:23 -0500
From:	Chetan Loke <chetanloke@...il.com>
To:	王金浦 <jinpuwang@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: libsas - sas_queue's policy of re-queuing all the tasks ...

On Thu, Dec 24, 2009 at 7:26 AM, 王金浦 <jinpuwang@...il.com> wrote:
>
>
> 2009/12/24 Chetan Loke <chetanloke@...il.com>
>>
>> Hello,
>>
>> I've a question regarding the libsas core.
>>
>> So, sas_queue() will dispatch the coalesced tasks. It then invokes the
>> SAS_LLDD's execute_task. Let's assume mv_sas driver.In this case
>> mvs_task_exec(). Say, it received 'N' tasks the first time it was
>> called.However, the LLDD was only able to service M tasks(where M<N).
>> Now it will return rc(non-zero value). sas_queue will then requeue all
>> the tasks. But only (N-M) tasks should have been queued, correct? So
>> why are we re-trying all the tasks again?
>>
>
> if you see the code , at mv_init , in function mvs_post_sas_ha_init set
> sha->lldd_max_execute_num = 1;
> and libsas invoke sas_queue_up when sha->lldd_max_execute_num> 1 .
>

Ignore the max_execute_num for this discussion. What I'm saying is, if
you do 'coalesce' the tasks.
mv_sas core clearly has 256+ slots in their adapter. That means you
could coalesce them. Well, that's not the point.
What I would like to know is why does the libsas core wants to requeue
all the tasks?
What was the rationale behind this logic?

> Jack Wang
>

Chetan Loke
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ