destroy_vq_cmds;
}
Reviewed-by: Mike Christie
On 11/30/20 11:52 AM, Paolo Bonzini wrote:
> On 30/11/20 18:38, Sasha Levin wrote:
>>> I am not aware of any public CI being done _at all_ done on vhost-scsi, by
>>> CKI or everyone else. So autoselection should be done only on subsystems
>>> that have very high coverage in CI.
>>
>> Where can I
On 01/18/2018 09:10 AM, Florian Westphal wrote:
>> It would indicate users providing their own ->sk_data_ready() callback
>> must be responsible for waking up a kthread context blocked on
>> sock_recvmsg(..., MSG_WAITALL), when a second ->sk_data_ready() is
>> received before the first sock_recvmsg
gt;
>> (Adding net-dev + DaveM CC')
>>
>> Catching up on pre-holiday threads, thanks for the heads up.
>>
>> Comments below.
>>
>> On Wed, 2017-12-13 at 23:56 -0600, Mike Christie wrote:
>>> Hey Nick and Florian,
>>>
>>> Start
xt.
>
> Use read_lock_bh() variant to restore previous assumption.
>
> Ideally this code could use RCU instead...
>
> Fixes: 5413d1babe8f ("net: do not block BH while processing socket backlog")
> Fixes: d41a69f1d390 ("tcp: make tcp_sendmsg() aware of socket backl
xt.
>
> Use read_lock_bh() variant to restore previous assumption.
>
> Ideally this code could use RCU instead...
>
> Fixes: 5413d1babe8f ("net: do not block BH while processing socket backlog")
> Fixes: d41a69f1d390 ("tcp: make tcp_sendmsg() aware of socket backl
.h|4 +--
> drivers/scsi/libiscsi_tcp.c | 29 +--
> include/scsi/libiscsi_tcp.h | 13 +-
> 4 files changed, 58 insertions(+), 42 deletions(-)
>
iSCSI parts look ok.
Reviewed-by: Mike Christie
Anil Veerabhadrappa wrote:
Which ones were they exactly? I think JamesB wanted only common
transport values in the transport class. If it is driver specific then
it should go on the host or target or device with the scsi_host_template
attrs.
It's a chicken & egg issue to put "port mapper"
Anil Veerabhadrappa wrote:
The sysfs bits related to the hba should be use one of the scsi sysfs
facilities or if they are related to iscsi bits and are generic then
through the iscsi hba
bnx2i needs 2 sysfs entries -
1. QP size info - this is used to size per connection shared data
structures
Some quick comments that got cut out of the original mail.
+
+/*
+ * map single buffer
+ */
+static int bnx2i_map_single_buf(struct bnx2i_hba *hba,
+ struct bnx2i_cmd *cmd)
+{
+ struct scsi_cmnd *sc = cmd->scsi_cmd;
+ struct iscsi_bd *bd = cmd->b
Anil Veerabhadrappa wrote:
+
+/* iSCSI stages */
+#define ISCSI_STAGE_SECURITY_NEGOTIATION (0)
+#define ISCSI_STAGE_LOGIN_OPERATIONAL_NEGOTIATION (1)
+#define ISCSI_STAGE_FULL_FEATURE_PHASE (3)
+/* Logout response codes */
+#define ISCSI_LOGOUT_RESPONSE_CONNECTION_CLOSED (0)
+#define ISCSI_LOGO
Michael Chan wrote:
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 6f2c71e..adcfbbc 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -1800,6 +1800,8 @@ config ZFCP
called zfcp. If you want to compile it as a module, say M here
and read .
+sou
Qi, Yanling wrote:
> Hi All,
>
> This panic is related to the interactions between scsi/sg.c, iscsi
> initiator and tcp on the RHEL 2.6.9-42 kernel. But we may also have the
> similar problem with open-iscsi initiator. I will explain why we see the
Yeah, this problem should occur in the upstream
Mike Christie wrote:
> Peter Zijlstra wrote:
>> On Thu, 2006-09-14 at 22:35 +0200, Peter Zijlstra wrote:
>>> On Thu, 2006-09-14 at 14:22 -0500, Mike Christie wrote:
>>>>> I thought I found allocations in that path, lemme search...
>>>>
Peter Zijlstra wrote:
> On Thu, 2006-09-14 at 22:35 +0200, Peter Zijlstra wrote:
>> On Thu, 2006-09-14 at 14:22 -0500, Mike Christie wrote:
>
>>>> I thought I found allocations in that path, lemme search...
>>>> found this:
>>>>
&g
Peter Zijlstra wrote:
> On Thu, 2006-09-14 at 14:22 -0500, Mike Christie wrote:
>> Peter Zijlstra wrote:
>>> On Wed, 2006-09-13 at 15:50 -0500, Mike Christie wrote:
>>>> Peter Zijlstra wrote:
>>>>> Implement sht->swapdev() for iSCSI. This metho
Mike Christie wrote:
> Peter Zijlstra wrote:
>> On Thu, 2006-09-14 at 14:22 -0500, Mike Christie wrote:
>>> Peter Zijlstra wrote:
>>>> On Wed, 2006-09-13 at 15:50 -0500, Mike Christie wrote:
>>>>> Peter Zijlstra wrote:
>>>>>> Implemen
Peter Zijlstra wrote:
> On Wed, 2006-09-13 at 15:50 -0500, Mike Christie wrote:
>> Peter Zijlstra wrote:
>>> Implement sht->swapdev() for iSCSI. This method takes care of reserving
>>> the extra memory needed and marking all relevant sockets with SOCK_VMIO.
>&
cal socket, and that we do not
> fail to process incomming data.
>
> Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
> CC: Mike Christie <[EMAIL PROTECTED]>
> ---
> drivers/scsi/iscsi_tcp.c| 103
> +++-
Mike Christie wrote:
> James Smart wrote:
>> Note: We've transitioned off topic. If what this means is "there isn't a
>> good
>> way except by ioctls (which still isn't easily portable) or system calls",
>> then that's ok. Then at least w
r
> implementation alternatives.
>
> Mike Christie wrote:
>> James Smart wrote:
>>> Mike Christie wrote:
>>>> For the tasks you want to do for the fc class is performance critical?
>>> No, it should not be.
>>>
>>>> If not, you could do
Mike Christie wrote:
> James Smart wrote:
>> Mike Christie wrote:
>>> For the tasks you want to do for the fc class is performance critical?
>> No, it should not be.
>>
>>> If not, you could do what the iscsi class (for the netdev people this is
>>&g
Mike Christie wrote:
> James Smart wrote:
>> Mike Christie wrote:
>>> For the tasks you want to do for the fc class is performance critical?
>> No, it should not be.
>>
>>> If not, you could do what the iscsi class (for the netdev people this is
>>&g
James Smart wrote:
>
> Mike Christie wrote:
>> For the tasks you want to do for the fc class is performance critical?
>
> No, it should not be.
>
>> If not, you could do what the iscsi class (for the netdev people this is
>> drivers/scsi/scsi_transport_iscsi
James Smart wrote:
> Folks,
>
> To take netlink to where we want to use it within the SCSI subsystem (as
> the mechanism of choice to replace ioctls), we're going to need to pass
> user-space buffer pointers.
>
> What is the best, portable manner to pass a pointer between user and kernel
> space
ce
to indicate the success or failure of the operation (using
scsi_tgt_uspace_send_status in the patch below).
Signed-off-by: Mike Christie <[EMAIL PROTECTED]>
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
diff --git a/drivers/scsi/scsi_tgt_if.c b/drivers/scsi/scsi_tgt_if.c
new
26 matches
Mail list logo
