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
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,
>>>
>>> Starting i
read_unlock_bh(>sk_callback_lock);
> return;
> }
> session = conn->session;
> @@ -179,7 +179,7 @@ static void iscsi_sw_tcp_state_change(struct sock *sk)
> tcp_sw_conn = tcp_conn->dd_data;
> old_state_change = tcp_sw_conn->old_state_change;
>
> - read_unlock(>sk_callback_lock);
> + read_unlock_bh(>sk_callback_lock);
>
> old_state_change(sk);
> }
>
Reviewed and tested. Thanks
Acked-by: Mike Christie <micha...@cs.wisc.edu>
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 backlog")
--
> drivers/scsi/iscsi_tcp.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 <micha...@cs.wisc.edu>
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
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
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
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.
When used for swapping, TCP socket creation
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 method takes care of reserving
the extra memory needed and marking all
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:
Implement sht-swapdev() for iSCSI. This method takes care of reserving
the extra memory
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:
iscsi_tcp_data_recv()
iscsi_data_rescv()
iscsi_complete_pdu
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...
found this:
iscsi_tcp_data_recv()
iscsi_data_rescv
.
Signed-off-by: Peter Zijlstra [EMAIL PROTECTED]
CC: Mike Christie [EMAIL PROTECTED]
---
drivers/scsi/iscsi_tcp.c| 103
+++-
drivers/scsi/scsi_transport_iscsi.c | 23 +++-
include/scsi/libiscsi.h |1
include/scsi
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.c) does and just suffer a couple
copies
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
drivers/scsi/scsi_transport_iscsi.c) does and just suffer
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 we know the limits and can look at other
implementation alternatives.
Mike Christie wrote
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 we know the limits and can look at other
implementation alternatives
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 within
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 file mode 100644
21 matches
Mail list logo
