Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1290673 > unrolled thread
| Started by | "K. Y. Srinivasan" <kys@microsoft.com> |
|---|---|
| First post | 2015-12-13 20:00 +0100 |
| Last post | 2015-12-18 09:50 +0100 |
| Articles | 11 — 4 participants |
Back to article view | Back to linux.kernel
[PATCH V3 0/4] scsi: storvsc: Properly support FC hosts "K. Y. Srinivasan" <kys@microsoft.com> - 2015-12-13 20:00 +0100
[PATCH V3 1/4] scsi: storvsc: Fix a bug in the layout of the hv_fc_wwn_packet "K. Y. Srinivasan" <kys@microsoft.com> - 2015-12-13 20:00 +0100
[PATCH V3 4/4] scsi: storvsc: Tighten up the interrupt path "K. Y. Srinivasan" <kys@microsoft.com> - 2015-12-13 20:00 +0100
Re: [PATCH V3 4/4] scsi: storvsc: Tighten up the interrupt path Hannes Reinecke <hare@suse.de> - 2015-12-18 10:00 +0100
RE: [PATCH V3 4/4] scsi: storvsc: Tighten up the interrupt path KY Srinivasan <kys@microsoft.com> - 2015-12-18 17:30 +0100
Re: [PATCH V3 4/4] scsi: storvsc: Tighten up the interrupt path James Bottomley <James.Bottomley@HansenPartnership.com> - 2015-12-18 17:50 +0100
RE: [PATCH V3 4/4] scsi: storvsc: Tighten up the interrupt path KY Srinivasan <kys@microsoft.com> - 2015-12-19 03:30 +0100
Re: [PATCH V3 4/4] scsi: storvsc: Tighten up the interrupt path Hannes Reinecke <hare@suse.de> - 2015-12-21 08:50 +0100
Re: [PATCH V3 4/4] scsi: storvsc: Tighten up the interrupt path James Bottomley <James.Bottomley@HansenPartnership.com> - 2015-12-21 17:30 +0100
RE: [PATCH V3 4/4] scsi: storvsc: Tighten up the interrupt path KY Srinivasan <kys@microsoft.com> - 2015-12-21 20:50 +0100
Re: [PATCH V3 1/4] scsi: storvsc: Fix a bug in the layout of the hv_fc_wwn_packet Hannes Reinecke <hare@suse.de> - 2015-12-18 09:50 +0100
| From | "K. Y. Srinivasan" <kys@microsoft.com> |
|---|---|
| Date | 2015-12-13 20:00 +0100 |
| Subject | [PATCH V3 0/4] scsi: storvsc: Properly support FC hosts |
| Message-ID | <qFk2e-3De-7@gated-at.bofh.it> |
Properly support FC hosts. Additional cleanup patches are also included. V2: Comments from Dan Carpenter <dan.carpenter@oracle.com> and from Johannes Thumshirn <jthumshirn@suse.de> addressed. V3: Fixed build issues reported by kbuild test robot <lkp@intel.com> K. Y. Srinivasan (4): scsi: storvsc: Fix a bug in the layout of the hv_fc_wwn_packet scsi: storvsc: Properly support Fibre Channel devices scsi: storvsc: Refactor the code in storvsc_channel_init() scsi: storvsc: Tighten up the interrupt path drivers/scsi/storvsc_drv.c | 275 +++++++++++++++++++++++++------------------ 1 files changed, 160 insertions(+), 115 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [next] | [standalone]
| From | "K. Y. Srinivasan" <kys@microsoft.com> |
|---|---|
| Date | 2015-12-13 20:00 +0100 |
| Subject | [PATCH V3 1/4] scsi: storvsc: Fix a bug in the layout of the hv_fc_wwn_packet |
| Message-ID | <qFk2e-3De-9@gated-at.bofh.it> |
| In reply to | #1290673 |
The hv_fc_wwn_packet is exchanged over vmbus. Make the definition in Linux match
the Window's definition.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Long Li <longli@microsoft.com>
Tested-by: Alex Ng <alexng@microsoft.com>
---
drivers/scsi/storvsc_drv.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index c41f674..00bb4bd 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -92,9 +92,8 @@ enum vstor_packet_operation {
*/
struct hv_fc_wwn_packet {
- bool primary_active;
- u8 reserved1;
- u8 reserved2;
+ u8 primary_active;
+ u8 reserved1[3];
u8 primary_port_wwn[8];
u8 primary_node_wwn[8];
u8 secondary_port_wwn[8];
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "K. Y. Srinivasan" <kys@microsoft.com> |
|---|---|
| Date | 2015-12-13 20:00 +0100 |
| Subject | [PATCH V3 4/4] scsi: storvsc: Tighten up the interrupt path |
| Message-ID | <qFk2f-3De-35@gated-at.bofh.it> |
| In reply to | #1290674 |
On the interrupt path, we repeatedly establish the pointer to the
storvsc_device. Fix this.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Reviewed-by: Long Li <longli@microsoft.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Tested-by: Alex Ng <alexng@microsoft.com>
---
drivers/scsi/storvsc_drv.c | 23 ++++++++---------------
1 files changed, 8 insertions(+), 15 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index d6ca4f2..b68aebe 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -945,19 +945,16 @@ static void storvsc_handle_error(struct vmscsi_request *vm_srb,
}
-static void storvsc_command_completion(struct storvsc_cmd_request *cmd_request)
+static void storvsc_command_completion(struct storvsc_cmd_request *cmd_request,
+ struct storvsc_device *stor_dev)
{
struct scsi_cmnd *scmnd = cmd_request->cmd;
- struct hv_host_device *host_dev = shost_priv(scmnd->device->host);
struct scsi_sense_hdr sense_hdr;
struct vmscsi_request *vm_srb;
struct Scsi_Host *host;
- struct storvsc_device *stor_dev;
- struct hv_device *dev = host_dev->dev;
u32 payload_sz = cmd_request->payload_sz;
void *payload = cmd_request->payload;
- stor_dev = get_in_stor_device(dev);
host = stor_dev->host;
vm_srb = &cmd_request->vstor_packet.vm_srb;
@@ -987,14 +984,13 @@ static void storvsc_command_completion(struct storvsc_cmd_request *cmd_request)
kfree(payload);
}
-static void storvsc_on_io_completion(struct hv_device *device,
+static void storvsc_on_io_completion(struct storvsc_device *stor_device,
struct vstor_packet *vstor_packet,
struct storvsc_cmd_request *request)
{
- struct storvsc_device *stor_device;
struct vstor_packet *stor_pkt;
+ struct hv_device *device = stor_device->device;
- stor_device = hv_get_drvdata(device);
stor_pkt = &request->vstor_packet;
/*
@@ -1049,7 +1045,7 @@ static void storvsc_on_io_completion(struct hv_device *device,
stor_pkt->vm_srb.data_transfer_length =
vstor_packet->vm_srb.data_transfer_length;
- storvsc_command_completion(request);
+ storvsc_command_completion(request, stor_device);
if (atomic_dec_and_test(&stor_device->num_outstanding_req) &&
stor_device->drain_notify)
@@ -1058,21 +1054,19 @@ static void storvsc_on_io_completion(struct hv_device *device,
}
-static void storvsc_on_receive(struct hv_device *device,
+static void storvsc_on_receive(struct storvsc_device *stor_device,
struct vstor_packet *vstor_packet,
struct storvsc_cmd_request *request)
{
struct storvsc_scan_work *work;
- struct storvsc_device *stor_device;
switch (vstor_packet->operation) {
case VSTOR_OPERATION_COMPLETE_IO:
- storvsc_on_io_completion(device, vstor_packet, request);
+ storvsc_on_io_completion(stor_device, vstor_packet, request);
break;
case VSTOR_OPERATION_REMOVE_DEVICE:
case VSTOR_OPERATION_ENUMERATE_BUS:
- stor_device = get_in_stor_device(device);
work = kmalloc(sizeof(struct storvsc_scan_work), GFP_ATOMIC);
if (!work)
return;
@@ -1083,7 +1077,6 @@ static void storvsc_on_receive(struct hv_device *device,
break;
case VSTOR_OPERATION_FCHBA_DATA:
- stor_device = get_in_stor_device(device);
cache_wwn(stor_device, vstor_packet);
#ifdef CONFIG_SCSI_FC_ATTRS
fc_host_node_name(stor_device->host) = stor_device->node_name;
@@ -1133,7 +1126,7 @@ static void storvsc_on_channel_callback(void *context)
vmscsi_size_delta));
complete(&request->wait_event);
} else {
- storvsc_on_receive(device,
+ storvsc_on_receive(stor_device,
(struct vstor_packet *)packet,
request);
}
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Hannes Reinecke <hare@suse.de> |
|---|---|
| Date | 2015-12-18 10:00 +0100 |
| Subject | Re: [PATCH V3 4/4] scsi: storvsc: Tighten up the interrupt path |
| Message-ID | <qGZ3m-3mL-55@gated-at.bofh.it> |
| In reply to | #1290676 |
On 12/13/2015 09:28 PM, K. Y. Srinivasan wrote:
> On the interrupt path, we repeatedly establish the pointer to the
> storvsc_device. Fix this.
>
> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> Reviewed-by: Long Li <longli@microsoft.com>
> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
> Tested-by: Alex Ng <alexng@microsoft.com>
> ---
> drivers/scsi/storvsc_drv.c | 23 ++++++++---------------
> 1 files changed, 8 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> index d6ca4f2..b68aebe 100644
> --- a/drivers/scsi/storvsc_drv.c
> +++ b/drivers/scsi/storvsc_drv.c
> @@ -945,19 +945,16 @@ static void storvsc_handle_error(struct vmscsi_request *vm_srb,
> }
>
>
> -static void storvsc_command_completion(struct storvsc_cmd_request *cmd_request)
> +static void storvsc_command_completion(struct storvsc_cmd_request *cmd_request,
> + struct storvsc_device *stor_dev)
> {
> struct scsi_cmnd *scmnd = cmd_request->cmd;
> - struct hv_host_device *host_dev = shost_priv(scmnd->device->host);
> struct scsi_sense_hdr sense_hdr;
> struct vmscsi_request *vm_srb;
> struct Scsi_Host *host;
> - struct storvsc_device *stor_dev;
> - struct hv_device *dev = host_dev->dev;
> u32 payload_sz = cmd_request->payload_sz;
> void *payload = cmd_request->payload;
>
> - stor_dev = get_in_stor_device(dev);
> host = stor_dev->host;
>
> vm_srb = &cmd_request->vstor_packet.vm_srb;
> @@ -987,14 +984,13 @@ static void storvsc_command_completion(struct storvsc_cmd_request *cmd_request)
> kfree(payload);
> }
>
> -static void storvsc_on_io_completion(struct hv_device *device,
> +static void storvsc_on_io_completion(struct storvsc_device *stor_device,
> struct vstor_packet *vstor_packet,
> struct storvsc_cmd_request *request)
> {
> - struct storvsc_device *stor_device;
> struct vstor_packet *stor_pkt;
> + struct hv_device *device = stor_device->device;
>
> - stor_device = hv_get_drvdata(device);
> stor_pkt = &request->vstor_packet;
>
> /*
> @@ -1049,7 +1045,7 @@ static void storvsc_on_io_completion(struct hv_device *device,
> stor_pkt->vm_srb.data_transfer_length =
> vstor_packet->vm_srb.data_transfer_length;
>
> - storvsc_command_completion(request);
> + storvsc_command_completion(request, stor_device);
>
> if (atomic_dec_and_test(&stor_device->num_outstanding_req) &&
> stor_device->drain_notify)
> @@ -1058,21 +1054,19 @@ static void storvsc_on_io_completion(struct hv_device *device,
>
> }
>
> -static void storvsc_on_receive(struct hv_device *device,
> +static void storvsc_on_receive(struct storvsc_device *stor_device,
> struct vstor_packet *vstor_packet,
> struct storvsc_cmd_request *request)
> {
> struct storvsc_scan_work *work;
> - struct storvsc_device *stor_device;
>
> switch (vstor_packet->operation) {
> case VSTOR_OPERATION_COMPLETE_IO:
> - storvsc_on_io_completion(device, vstor_packet, request);
> + storvsc_on_io_completion(stor_device, vstor_packet, request);
> break;
>
> case VSTOR_OPERATION_REMOVE_DEVICE:
> case VSTOR_OPERATION_ENUMERATE_BUS:
> - stor_device = get_in_stor_device(device);
> work = kmalloc(sizeof(struct storvsc_scan_work), GFP_ATOMIC);
> if (!work)
> return;
> @@ -1083,7 +1077,6 @@ static void storvsc_on_receive(struct hv_device *device,
> break;
>
> case VSTOR_OPERATION_FCHBA_DATA:
> - stor_device = get_in_stor_device(device);
> cache_wwn(stor_device, vstor_packet);
> #ifdef CONFIG_SCSI_FC_ATTRS
> fc_host_node_name(stor_device->host) = stor_device->node_name;
> @@ -1133,7 +1126,7 @@ static void storvsc_on_channel_callback(void *context)
> vmscsi_size_delta));
> complete(&request->wait_event);
> } else {
> - storvsc_on_receive(device,
> + storvsc_on_receive(stor_device,
> (struct vstor_packet *)packet,
> request);
> }
>
Hmm. I would've thought the compiler optimizes this away. Have you
checked whether it actually makes a difference in the assembler output?
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | KY Srinivasan <kys@microsoft.com> |
|---|---|
| Date | 2015-12-18 17:30 +0100 |
| Subject | RE: [PATCH V3 4/4] scsi: storvsc: Tighten up the interrupt path |
| Message-ID | <qH64O-7Y5-5@gated-at.bofh.it> |
| In reply to | #1294542 |
> -----Original Message-----
> From: Hannes Reinecke [mailto:hare@suse.de]
> Sent: Friday, December 18, 2015 12:52 AM
> To: KY Srinivasan <kys@microsoft.com>; gregkh@linuxfoundation.org; linux-
> kernel@vger.kernel.org; devel@linuxdriverproject.org; ohering@suse.com;
> jbottomley@parallels.com; hch@infradead.org; linux-scsi@vger.kernel.org;
> apw@canonical.com; vkuznets@redhat.com; jasowang@redhat.com;
> martin.petersen@oracle.com
> Subject: Re: [PATCH V3 4/4] scsi: storvsc: Tighten up the interrupt path
>
> On 12/13/2015 09:28 PM, K. Y. Srinivasan wrote:
> > On the interrupt path, we repeatedly establish the pointer to the
> > storvsc_device. Fix this.
> >
> > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > Reviewed-by: Long Li <longli@microsoft.com>
> > Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
> > Tested-by: Alex Ng <alexng@microsoft.com>
> > ---
> > drivers/scsi/storvsc_drv.c | 23 ++++++++---------------
> > 1 files changed, 8 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> > index d6ca4f2..b68aebe 100644
> > --- a/drivers/scsi/storvsc_drv.c
> > +++ b/drivers/scsi/storvsc_drv.c
> > @@ -945,19 +945,16 @@ static void storvsc_handle_error(struct
> vmscsi_request *vm_srb,
> > }
> >
> >
> > -static void storvsc_command_completion(struct storvsc_cmd_request
> *cmd_request)
> > +static void storvsc_command_completion(struct storvsc_cmd_request
> *cmd_request,
> > + struct storvsc_device *stor_dev)
> > {
> > struct scsi_cmnd *scmnd = cmd_request->cmd;
> > - struct hv_host_device *host_dev = shost_priv(scmnd->device-
> >host);
> > struct scsi_sense_hdr sense_hdr;
> > struct vmscsi_request *vm_srb;
> > struct Scsi_Host *host;
> > - struct storvsc_device *stor_dev;
> > - struct hv_device *dev = host_dev->dev;
> > u32 payload_sz = cmd_request->payload_sz;
> > void *payload = cmd_request->payload;
> >
> > - stor_dev = get_in_stor_device(dev);
> > host = stor_dev->host;
> >
> > vm_srb = &cmd_request->vstor_packet.vm_srb;
> > @@ -987,14 +984,13 @@ static void storvsc_command_completion(struct
> storvsc_cmd_request *cmd_request)
> > kfree(payload);
> > }
> >
> > -static void storvsc_on_io_completion(struct hv_device *device,
> > +static void storvsc_on_io_completion(struct storvsc_device *stor_device,
> > struct vstor_packet *vstor_packet,
> > struct storvsc_cmd_request *request)
> > {
> > - struct storvsc_device *stor_device;
> > struct vstor_packet *stor_pkt;
> > + struct hv_device *device = stor_device->device;
> >
> > - stor_device = hv_get_drvdata(device);
> > stor_pkt = &request->vstor_packet;
> >
> > /*
> > @@ -1049,7 +1045,7 @@ static void storvsc_on_io_completion(struct
> hv_device *device,
> > stor_pkt->vm_srb.data_transfer_length =
> > vstor_packet->vm_srb.data_transfer_length;
> >
> > - storvsc_command_completion(request);
> > + storvsc_command_completion(request, stor_device);
> >
> > if (atomic_dec_and_test(&stor_device->num_outstanding_req) &&
> > stor_device->drain_notify)
> > @@ -1058,21 +1054,19 @@ static void storvsc_on_io_completion(struct
> hv_device *device,
> >
> > }
> >
> > -static void storvsc_on_receive(struct hv_device *device,
> > +static void storvsc_on_receive(struct storvsc_device *stor_device,
> > struct vstor_packet *vstor_packet,
> > struct storvsc_cmd_request *request)
> > {
> > struct storvsc_scan_work *work;
> > - struct storvsc_device *stor_device;
> >
> > switch (vstor_packet->operation) {
> > case VSTOR_OPERATION_COMPLETE_IO:
> > - storvsc_on_io_completion(device, vstor_packet, request);
> > + storvsc_on_io_completion(stor_device, vstor_packet,
> request);
> > break;
> >
> > case VSTOR_OPERATION_REMOVE_DEVICE:
> > case VSTOR_OPERATION_ENUMERATE_BUS:
> > - stor_device = get_in_stor_device(device);
> > work = kmalloc(sizeof(struct storvsc_scan_work),
> GFP_ATOMIC);
> > if (!work)
> > return;
> > @@ -1083,7 +1077,6 @@ static void storvsc_on_receive(struct hv_device
> *device,
> > break;
> >
> > case VSTOR_OPERATION_FCHBA_DATA:
> > - stor_device = get_in_stor_device(device);
> > cache_wwn(stor_device, vstor_packet);
> > #ifdef CONFIG_SCSI_FC_ATTRS
> > fc_host_node_name(stor_device->host) = stor_device-
> >node_name;
> > @@ -1133,7 +1126,7 @@ static void storvsc_on_channel_callback(void
> *context)
> > vmscsi_size_delta));
> > complete(&request->wait_event);
> > } else {
> > - storvsc_on_receive(device,
> > + storvsc_on_receive(stor_device,
> > (struct vstor_packet
> *)packet,
> > request);
> > }
> >
> Hmm. I would've thought the compiler optimizes this away. Have you
> checked whether it actually makes a difference in the assembler output?
I have not checked the assembler output. It was easy enough to fix the source.
K. Y
>
> Cheers,
>
> Hannes
> --
> Dr. Hannes Reinecke zSeries & Storage
> hare@suse.de +49 911 74053 688
> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
> GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
> HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | James Bottomley <James.Bottomley@HansenPartnership.com> |
|---|---|
| Date | 2015-12-18 17:50 +0100 |
| Subject | Re: [PATCH V3 4/4] scsi: storvsc: Tighten up the interrupt path |
| Message-ID | <qH6ob-86R-21@gated-at.bofh.it> |
| In reply to | #1295005 |
On Fri, 2015-12-18 at 16:20 +0000, KY Srinivasan wrote:
>
> > -----Original Message-----
> > From: Hannes Reinecke [mailto:hare@suse.de]
> > Sent: Friday, December 18, 2015 12:52 AM
> > To: KY Srinivasan <kys@microsoft.com>; gregkh@linuxfoundation.org;
> > linux-
> > kernel@vger.kernel.org; devel@linuxdriverproject.org;
> > ohering@suse.com;
> > jbottomley@parallels.com; hch@infradead.org;
> > linux-scsi@vger.kernel.org;
> > apw@canonical.com; vkuznets@redhat.com; jasowang@redhat.com;
> > martin.petersen@oracle.com
> > Subject: Re: [PATCH V3 4/4] scsi: storvsc: Tighten up the interrupt
> > path
> >
> > On 12/13/2015 09:28 PM, K. Y. Srinivasan wrote:
> > > On the interrupt path, we repeatedly establish the pointer to the
> > > storvsc_device. Fix this.
> > >
> > > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > > Reviewed-by: Long Li <longli@microsoft.com>
> > > Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
> > > Tested-by: Alex Ng <alexng@microsoft.com>
> > > ---
> > > drivers/scsi/storvsc_drv.c | 23 ++++++++---------------
> > > 1 files changed, 8 insertions(+), 15 deletions(-)
> > >
> > > diff --git a/drivers/scsi/storvsc_drv.c
> > > b/drivers/scsi/storvsc_drv.c
> > > index d6ca4f2..b68aebe 100644
> > > --- a/drivers/scsi/storvsc_drv.c
> > > +++ b/drivers/scsi/storvsc_drv.c
> > > @@ -945,19 +945,16 @@ static void storvsc_handle_error(struct
> > vmscsi_request *vm_srb,
> > > }
> > >
> > >
> > > -static void storvsc_command_completion(struct
> > > storvsc_cmd_request
> > *cmd_request)
> > > +static void storvsc_command_completion(struct
> > > storvsc_cmd_request
> > *cmd_request,
> > > + struct storvsc_device
> > > *stor_dev)
> > > {
> > > struct scsi_cmnd *scmnd = cmd_request->cmd;
> > > - struct hv_host_device *host_dev = shost_priv(scmnd
> > > ->device-
> > > host);
> > > struct scsi_sense_hdr sense_hdr;
> > > struct vmscsi_request *vm_srb;
> > > struct Scsi_Host *host;
> > > - struct storvsc_device *stor_dev;
> > > - struct hv_device *dev = host_dev->dev;
> > > u32 payload_sz = cmd_request->payload_sz;
> > > void *payload = cmd_request->payload;
> > >
> > > - stor_dev = get_in_stor_device(dev);
> > > host = stor_dev->host;
> > >
> > > vm_srb = &cmd_request->vstor_packet.vm_srb;
> > > @@ -987,14 +984,13 @@ static void
> > > storvsc_command_completion(struct
> > storvsc_cmd_request *cmd_request)
> > > kfree(payload);
> > > }
> > >
> > > -static void storvsc_on_io_completion(struct hv_device *device,
> > > +static void storvsc_on_io_completion(struct storvsc_device
> > > *stor_device,
> > > struct vstor_packet
> > > *vstor_packet,
> > > struct storvsc_cmd_request
> > > *request)
> > > {
> > > - struct storvsc_device *stor_device;
> > > struct vstor_packet *stor_pkt;
> > > + struct hv_device *device = stor_device->device;
> > >
> > > - stor_device = hv_get_drvdata(device);
> > > stor_pkt = &request->vstor_packet;
> > >
> > > /*
> > > @@ -1049,7 +1045,7 @@ static void storvsc_on_io_completion(struct
> > hv_device *device,
> > > stor_pkt->vm_srb.data_transfer_length =
> > > vstor_packet->vm_srb.data_transfer_length;
> > >
> > > - storvsc_command_completion(request);
> > > + storvsc_command_completion(request, stor_device);
> > >
> > > if (atomic_dec_and_test(&stor_device
> > > ->num_outstanding_req) &&
> > > stor_device->drain_notify)
> > > @@ -1058,21 +1054,19 @@ static void
> > > storvsc_on_io_completion(struct
> > hv_device *device,
> > >
> > > }
> > >
> > > -static void storvsc_on_receive(struct hv_device *device,
> > > +static void storvsc_on_receive(struct storvsc_device
> > > *stor_device,
> > > struct vstor_packet *vstor_packet,
> > > struct storvsc_cmd_request
> > > *request)
> > > {
> > > struct storvsc_scan_work *work;
> > > - struct storvsc_device *stor_device;
> > >
> > > switch (vstor_packet->operation) {
> > > case VSTOR_OPERATION_COMPLETE_IO:
> > > - storvsc_on_io_completion(device, vstor_packet,
> > > request);
> > > + storvsc_on_io_completion(stor_device,
> > > vstor_packet,
> > request);
> > > break;
> > >
> > > case VSTOR_OPERATION_REMOVE_DEVICE:
> > > case VSTOR_OPERATION_ENUMERATE_BUS:
> > > - stor_device = get_in_stor_device(device);
> > > work = kmalloc(sizeof(struct
> > > storvsc_scan_work),
> > GFP_ATOMIC);
> > > if (!work)
> > > return;
> > > @@ -1083,7 +1077,6 @@ static void storvsc_on_receive(struct
> > > hv_device
> > *device,
> > > break;
> > >
> > > case VSTOR_OPERATION_FCHBA_DATA:
> > > - stor_device = get_in_stor_device(device);
> > > cache_wwn(stor_device, vstor_packet);
> > > #ifdef CONFIG_SCSI_FC_ATTRS
> > > fc_host_node_name(stor_device->host) =
> > > stor_device-
> > > node_name;
> > > @@ -1133,7 +1126,7 @@ static void
> > > storvsc_on_channel_callback(void
> > *context)
> > > vmscsi_size_delta));
> > > complete(&request->wait_event);
> > > } else {
> > > - storvsc_on_receive(device,
> > > + storvsc_on_receive(stor_device,
> > > (struct
> > > vstor_packet
> > *)packet,
> > > request);
> > > }
> > >
> > Hmm. I would've thought the compiler optimizes this away. Have you
> > checked whether it actually makes a difference in the assembler
> > output?
>
> I have not checked the assembler output. It was easy enough to fix
> the source.
Could you? You're making what you describe as an optimisation but
there are two reasons why this might not be so. The first is that the
compiler is entitled to inline static functions. If it did, likely it
picked up the optmisation anyway as Hannes suggested. However, the
other reason this might not be an optimisation (assuming the compiler
doesn't inline the function) is you're passing an argument which can be
offset computed. On all architectures, you have a fixed number of
registers for passing function arguments, then we have to use the
stack. Using the stack comes in far more expensive than computing an
offset to an existing pointer. Even if you're still in registers, the
offset now has to be computed and stored and the compiler loses track
of the relation.
The bottom line is that adding an extra argument for a value which can
be offset computed is rarely a win.
James
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | KY Srinivasan <kys@microsoft.com> |
|---|---|
| Date | 2015-12-19 03:30 +0100 |
| Subject | RE: [PATCH V3 4/4] scsi: storvsc: Tighten up the interrupt path |
| Message-ID | <qHfrr-5uX-1@gated-at.bofh.it> |
| In reply to | #1295030 |
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSmFtZXMgQm90dG9tbGV5 IFttYWlsdG86SmFtZXMuQm90dG9tbGV5QEhhbnNlblBhcnRuZXJzaGlwLmNvbV0NCj4gU2VudDog RnJpZGF5LCBEZWNlbWJlciAxOCwgMjAxNSA4OjQ4IEFNDQo+IFRvOiBLWSBTcmluaXZhc2FuIDxr eXNAbWljcm9zb2Z0LmNvbT47IEhhbm5lcyBSZWluZWNrZSA8aGFyZUBzdXNlLmRlPjsNCj4gZ3Jl Z2toQGxpbnV4Zm91bmRhdGlvbi5vcmc7IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7DQo+ IGRldmVsQGxpbnV4ZHJpdmVycHJvamVjdC5vcmc7IG9oZXJpbmdAc3VzZS5jb207DQo+IGpib3R0 b21sZXlAcGFyYWxsZWxzLmNvbTsgaGNoQGluZnJhZGVhZC5vcmc7IGxpbnV4LXNjc2lAdmdlci5r ZXJuZWwub3JnOw0KPiBhcHdAY2Fub25pY2FsLmNvbTsgdmt1em5ldHNAcmVkaGF0LmNvbTsgamFz b3dhbmdAcmVkaGF0LmNvbTsNCj4gbWFydGluLnBldGVyc2VuQG9yYWNsZS5jb20NCj4gU3ViamVj dDogUmU6IFtQQVRDSCBWMyA0LzRdIHNjc2k6IHN0b3J2c2M6IFRpZ2h0ZW4gdXAgdGhlIGludGVy cnVwdCBwYXRoDQo+IA0KPiBPbiBGcmksIDIwMTUtMTItMTggYXQgMTY6MjAgKzAwMDAsIEtZIFNy aW5pdmFzYW4gd3JvdGU6DQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID4gPiBGcm9tOiBIYW5uZXMgUmVpbmVja2UgW21haWx0bzpoYXJlQHN1c2UuZGVdDQo+ID4gPiBT ZW50OiBGcmlkYXksIERlY2VtYmVyIDE4LCAyMDE1IDEyOjUyIEFNDQo+ID4gPiBUbzogS1kgU3Jp bml2YXNhbiA8a3lzQG1pY3Jvc29mdC5jb20+OyBncmVna2hAbGludXhmb3VuZGF0aW9uLm9yZzsN Cj4gPiA+IGxpbnV4LQ0KPiA+ID4ga2VybmVsQHZnZXIua2VybmVsLm9yZzsgZGV2ZWxAbGludXhk cml2ZXJwcm9qZWN0Lm9yZzsNCj4gPiA+IG9oZXJpbmdAc3VzZS5jb207DQo+ID4gPiBqYm90dG9t bGV5QHBhcmFsbGVscy5jb207IGhjaEBpbmZyYWRlYWQub3JnOw0KPiA+ID4gbGludXgtc2NzaUB2 Z2VyLmtlcm5lbC5vcmc7DQo+ID4gPiBhcHdAY2Fub25pY2FsLmNvbTsgdmt1em5ldHNAcmVkaGF0 LmNvbTsgamFzb3dhbmdAcmVkaGF0LmNvbTsNCj4gPiA+IG1hcnRpbi5wZXRlcnNlbkBvcmFjbGUu Y29tDQo+ID4gPiBTdWJqZWN0OiBSZTogW1BBVENIIFYzIDQvNF0gc2NzaTogc3RvcnZzYzogVGln aHRlbiB1cCB0aGUgaW50ZXJydXB0DQo+ID4gPiBwYXRoDQo+ID4gPg0KPiA+ID4gT24gMTIvMTMv MjAxNSAwOToyOCBQTSwgSy4gWS4gU3Jpbml2YXNhbiB3cm90ZToNCj4gPiA+ID4gT24gdGhlIGlu dGVycnVwdCBwYXRoLCB3ZSByZXBlYXRlZGx5IGVzdGFibGlzaCB0aGUgcG9pbnRlciB0byB0aGUN Cj4gPiA+ID4gc3RvcnZzY19kZXZpY2UuIEZpeCB0aGlzLg0KPiA+ID4gPg0KPiA+ID4gPiBTaWdu ZWQtb2ZmLWJ5OiBLLiBZLiBTcmluaXZhc2FuIDxreXNAbWljcm9zb2Z0LmNvbT4NCj4gPiA+ID4g UmV2aWV3ZWQtYnk6IExvbmcgTGkgPGxvbmdsaUBtaWNyb3NvZnQuY29tPg0KPiA+ID4gPiBSZXZp ZXdlZC1ieTogSm9oYW5uZXMgVGh1bXNoaXJuIDxqdGh1bXNoaXJuQHN1c2UuZGU+DQo+ID4gPiA+ IFRlc3RlZC1ieTogQWxleCBOZyA8YWxleG5nQG1pY3Jvc29mdC5jb20+DQo+ID4gPiA+IC0tLQ0K PiA+ID4gPiAgIGRyaXZlcnMvc2NzaS9zdG9ydnNjX2Rydi5jIHwgICAyMyArKysrKysrKy0tLS0t LS0tLS0tLS0tLQ0KPiA+ID4gPiAgIDEgZmlsZXMgY2hhbmdlZCwgOCBpbnNlcnRpb25zKCspLCAx NSBkZWxldGlvbnMoLSkNCj4gPiA+ID4NCj4gPiA+ID4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvc2Nz aS9zdG9ydnNjX2Rydi5jDQo+ID4gPiA+IGIvZHJpdmVycy9zY3NpL3N0b3J2c2NfZHJ2LmMNCj4g PiA+ID4gaW5kZXggZDZjYTRmMi4uYjY4YWViZSAxMDA2NDQNCj4gPiA+ID4gLS0tIGEvZHJpdmVy cy9zY3NpL3N0b3J2c2NfZHJ2LmMNCj4gPiA+ID4gKysrIGIvZHJpdmVycy9zY3NpL3N0b3J2c2Nf ZHJ2LmMNCj4gPiA+ID4gQEAgLTk0NSwxOSArOTQ1LDE2IEBAIHN0YXRpYyB2b2lkIHN0b3J2c2Nf aGFuZGxlX2Vycm9yKHN0cnVjdA0KPiA+ID4gdm1zY3NpX3JlcXVlc3QgKnZtX3NyYiwNCj4gPiA+ ID4gICB9DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IC1zdGF0aWMgdm9pZCBzdG9ydnNjX2Nv bW1hbmRfY29tcGxldGlvbihzdHJ1Y3QNCj4gPiA+ID4gc3RvcnZzY19jbWRfcmVxdWVzdA0KPiA+ ID4gKmNtZF9yZXF1ZXN0KQ0KPiA+ID4gPiArc3RhdGljIHZvaWQgc3RvcnZzY19jb21tYW5kX2Nv bXBsZXRpb24oc3RydWN0DQo+ID4gPiA+IHN0b3J2c2NfY21kX3JlcXVlc3QNCj4gPiA+ICpjbWRf cmVxdWVzdCwNCj4gPiA+ID4gKwkJCQkgICAgICAgc3RydWN0IHN0b3J2c2NfZGV2aWNlDQo+ID4g PiA+ICpzdG9yX2RldikNCj4gPiA+ID4gICB7DQo+ID4gPiA+ICAgCXN0cnVjdCBzY3NpX2NtbmQg KnNjbW5kID0gY21kX3JlcXVlc3QtPmNtZDsNCj4gPiA+ID4gLQlzdHJ1Y3QgaHZfaG9zdF9kZXZp Y2UgKmhvc3RfZGV2ID0gc2hvc3RfcHJpdihzY21uZA0KPiA+ID4gPiAtPmRldmljZS0NCj4gPiA+ ID4gaG9zdCk7DQo+ID4gPiA+ICAgCXN0cnVjdCBzY3NpX3NlbnNlX2hkciBzZW5zZV9oZHI7DQo+ ID4gPiA+ICAgCXN0cnVjdCB2bXNjc2lfcmVxdWVzdCAqdm1fc3JiOw0KPiA+ID4gPiAgIAlzdHJ1 Y3QgU2NzaV9Ib3N0ICpob3N0Ow0KPiA+ID4gPiAtCXN0cnVjdCBzdG9ydnNjX2RldmljZSAqc3Rv cl9kZXY7DQo+ID4gPiA+IC0Jc3RydWN0IGh2X2RldmljZSAqZGV2ID0gaG9zdF9kZXYtPmRldjsN Cj4gPiA+ID4gICAJdTMyIHBheWxvYWRfc3ogPSBjbWRfcmVxdWVzdC0+cGF5bG9hZF9zejsNCj4g PiA+ID4gICAJdm9pZCAqcGF5bG9hZCA9IGNtZF9yZXF1ZXN0LT5wYXlsb2FkOw0KPiA+ID4gPg0K PiA+ID4gPiAtCXN0b3JfZGV2ID0gZ2V0X2luX3N0b3JfZGV2aWNlKGRldik7DQo+ID4gPiA+ICAg CWhvc3QgPSBzdG9yX2Rldi0+aG9zdDsNCj4gPiA+ID4NCj4gPiA+ID4gICAJdm1fc3JiID0gJmNt ZF9yZXF1ZXN0LT52c3Rvcl9wYWNrZXQudm1fc3JiOw0KPiA+ID4gPiBAQCAtOTg3LDE0ICs5ODQs MTMgQEAgc3RhdGljIHZvaWQNCj4gPiA+ID4gc3RvcnZzY19jb21tYW5kX2NvbXBsZXRpb24oc3Ry dWN0DQo+ID4gPiBzdG9ydnNjX2NtZF9yZXF1ZXN0ICpjbWRfcmVxdWVzdCkNCj4gPiA+ID4gICAJ CWtmcmVlKHBheWxvYWQpOw0KPiA+ID4gPiAgIH0NCj4gPiA+ID4NCj4gPiA+ID4gLXN0YXRpYyB2 b2lkIHN0b3J2c2Nfb25faW9fY29tcGxldGlvbihzdHJ1Y3QgaHZfZGV2aWNlICpkZXZpY2UsDQo+ ID4gPiA+ICtzdGF0aWMgdm9pZCBzdG9ydnNjX29uX2lvX2NvbXBsZXRpb24oc3RydWN0IHN0b3J2 c2NfZGV2aWNlDQo+ID4gPiA+ICpzdG9yX2RldmljZSwNCj4gPiA+ID4gICAJCQkJICBzdHJ1Y3Qg dnN0b3JfcGFja2V0DQo+ID4gPiA+ICp2c3Rvcl9wYWNrZXQsDQo+ID4gPiA+ICAgCQkJCSAgc3Ry dWN0IHN0b3J2c2NfY21kX3JlcXVlc3QNCj4gPiA+ID4gKnJlcXVlc3QpDQo+ID4gPiA+ICAgew0K PiA+ID4gPiAtCXN0cnVjdCBzdG9ydnNjX2RldmljZSAqc3Rvcl9kZXZpY2U7DQo+ID4gPiA+ICAg CXN0cnVjdCB2c3Rvcl9wYWNrZXQgKnN0b3JfcGt0Ow0KPiA+ID4gPiArCXN0cnVjdCBodl9kZXZp Y2UgKmRldmljZSA9IHN0b3JfZGV2aWNlLT5kZXZpY2U7DQo+ID4gPiA+DQo+ID4gPiA+IC0Jc3Rv cl9kZXZpY2UgPSBodl9nZXRfZHJ2ZGF0YShkZXZpY2UpOw0KPiA+ID4gPiAgIAlzdG9yX3BrdCA9 ICZyZXF1ZXN0LT52c3Rvcl9wYWNrZXQ7DQo+ID4gPiA+DQo+ID4gPiA+ICAgCS8qDQo+ID4gPiA+ IEBAIC0xMDQ5LDcgKzEwNDUsNyBAQCBzdGF0aWMgdm9pZCBzdG9ydnNjX29uX2lvX2NvbXBsZXRp b24oc3RydWN0DQo+ID4gPiBodl9kZXZpY2UgKmRldmljZSwNCj4gPiA+ID4gICAJc3Rvcl9wa3Qt PnZtX3NyYi5kYXRhX3RyYW5zZmVyX2xlbmd0aCA9DQo+ID4gPiA+ICAgCXZzdG9yX3BhY2tldC0+ dm1fc3JiLmRhdGFfdHJhbnNmZXJfbGVuZ3RoOw0KPiA+ID4gPg0KPiA+ID4gPiAtCXN0b3J2c2Nf Y29tbWFuZF9jb21wbGV0aW9uKHJlcXVlc3QpOw0KPiA+ID4gPiArCXN0b3J2c2NfY29tbWFuZF9j b21wbGV0aW9uKHJlcXVlc3QsIHN0b3JfZGV2aWNlKTsNCj4gPiA+ID4NCj4gPiA+ID4gICAJaWYg KGF0b21pY19kZWNfYW5kX3Rlc3QoJnN0b3JfZGV2aWNlDQo+ID4gPiA+IC0+bnVtX291dHN0YW5k aW5nX3JlcSkgJiYNCj4gPiA+ID4gICAJCXN0b3JfZGV2aWNlLT5kcmFpbl9ub3RpZnkpDQo+ID4g PiA+IEBAIC0xMDU4LDIxICsxMDU0LDE5IEBAIHN0YXRpYyB2b2lkDQo+ID4gPiA+IHN0b3J2c2Nf b25faW9fY29tcGxldGlvbihzdHJ1Y3QNCj4gPiA+IGh2X2RldmljZSAqZGV2aWNlLA0KPiA+ID4g Pg0KPiA+ID4gPiAgIH0NCj4gPiA+ID4NCj4gPiA+ID4gLXN0YXRpYyB2b2lkIHN0b3J2c2Nfb25f cmVjZWl2ZShzdHJ1Y3QgaHZfZGV2aWNlICpkZXZpY2UsDQo+ID4gPiA+ICtzdGF0aWMgdm9pZCBz dG9ydnNjX29uX3JlY2VpdmUoc3RydWN0IHN0b3J2c2NfZGV2aWNlDQo+ID4gPiA+ICpzdG9yX2Rl dmljZSwNCj4gPiA+ID4gICAJCQkgICAgIHN0cnVjdCB2c3Rvcl9wYWNrZXQgKnZzdG9yX3BhY2tl dCwNCj4gPiA+ID4gICAJCQkgICAgIHN0cnVjdCBzdG9ydnNjX2NtZF9yZXF1ZXN0DQo+ID4gPiA+ ICpyZXF1ZXN0KQ0KPiA+ID4gPiAgIHsNCj4gPiA+ID4gICAJc3RydWN0IHN0b3J2c2Nfc2Nhbl93 b3JrICp3b3JrOw0KPiA+ID4gPiAtCXN0cnVjdCBzdG9ydnNjX2RldmljZSAqc3Rvcl9kZXZpY2U7 DQo+ID4gPiA+DQo+ID4gPiA+ICAgCXN3aXRjaCAodnN0b3JfcGFja2V0LT5vcGVyYXRpb24pIHsN Cj4gPiA+ID4gICAJY2FzZSBWU1RPUl9PUEVSQVRJT05fQ09NUExFVEVfSU86DQo+ID4gPiA+IC0J CXN0b3J2c2Nfb25faW9fY29tcGxldGlvbihkZXZpY2UsIHZzdG9yX3BhY2tldCwNCj4gPiA+ID4g cmVxdWVzdCk7DQo+ID4gPiA+ICsJCXN0b3J2c2Nfb25faW9fY29tcGxldGlvbihzdG9yX2Rldmlj ZSwNCj4gPiA+ID4gdnN0b3JfcGFja2V0LA0KPiA+ID4gcmVxdWVzdCk7DQo+ID4gPiA+ICAgCQli cmVhazsNCj4gPiA+ID4NCj4gPiA+ID4gICAJY2FzZSBWU1RPUl9PUEVSQVRJT05fUkVNT1ZFX0RF VklDRToNCj4gPiA+ID4gICAJY2FzZSBWU1RPUl9PUEVSQVRJT05fRU5VTUVSQVRFX0JVUzoNCj4g PiA+ID4gLQkJc3Rvcl9kZXZpY2UgPSBnZXRfaW5fc3Rvcl9kZXZpY2UoZGV2aWNlKTsNCj4gPiA+ ID4gICAJCXdvcmsgPSBrbWFsbG9jKHNpemVvZihzdHJ1Y3QNCj4gPiA+ID4gc3RvcnZzY19zY2Fu X3dvcmspLA0KPiA+ID4gR0ZQX0FUT01JQyk7DQo+ID4gPiA+ICAgCQlpZiAoIXdvcmspDQo+ID4g PiA+ICAgCQkJcmV0dXJuOw0KPiA+ID4gPiBAQCAtMTA4Myw3ICsxMDc3LDYgQEAgc3RhdGljIHZv aWQgc3RvcnZzY19vbl9yZWNlaXZlKHN0cnVjdA0KPiA+ID4gPiBodl9kZXZpY2UNCj4gPiA+ICpk ZXZpY2UsDQo+ID4gPiA+ICAgCQlicmVhazsNCj4gPiA+ID4NCj4gPiA+ID4gICAJY2FzZSBWU1RP Ul9PUEVSQVRJT05fRkNIQkFfREFUQToNCj4gPiA+ID4gLQkJc3Rvcl9kZXZpY2UgPSBnZXRfaW5f c3Rvcl9kZXZpY2UoZGV2aWNlKTsNCj4gPiA+ID4gICAJCWNhY2hlX3d3bihzdG9yX2RldmljZSwg dnN0b3JfcGFja2V0KTsNCj4gPiA+ID4gICAjaWZkZWYgQ09ORklHX1NDU0lfRkNfQVRUUlMNCj4g PiA+ID4gICAJCWZjX2hvc3Rfbm9kZV9uYW1lKHN0b3JfZGV2aWNlLT5ob3N0KSA9DQo+ID4gPiA+ IHN0b3JfZGV2aWNlLQ0KPiA+ID4gPiBub2RlX25hbWU7DQo+ID4gPiA+IEBAIC0xMTMzLDcgKzEx MjYsNyBAQCBzdGF0aWMgdm9pZA0KPiA+ID4gPiBzdG9ydnNjX29uX2NoYW5uZWxfY2FsbGJhY2so dm9pZA0KPiA+ID4gKmNvbnRleHQpDQo+ID4gPiA+ICAgCQkJCQl2bXNjc2lfc2l6ZV9kZWx0YSkp Ow0KPiA+ID4gPiAgIAkJCQljb21wbGV0ZSgmcmVxdWVzdC0+d2FpdF9ldmVudCk7DQo+ID4gPiA+ ICAgCQkJfSBlbHNlIHsNCj4gPiA+ID4gLQkJCQlzdG9ydnNjX29uX3JlY2VpdmUoZGV2aWNlLA0K PiA+ID4gPiArCQkJCXN0b3J2c2Nfb25fcmVjZWl2ZShzdG9yX2RldmljZSwNCj4gPiA+ID4gICAJ CQkJCQkoc3RydWN0DQo+ID4gPiA+IHZzdG9yX3BhY2tldA0KPiA+ID4gKilwYWNrZXQsDQo+ID4g PiA+ICAgCQkJCQkJcmVxdWVzdCk7DQo+ID4gPiA+ICAgCQkJfQ0KPiA+ID4gPg0KPiA+ID4gSG1t LiBJIHdvdWxkJ3ZlIHRob3VnaHQgdGhlIGNvbXBpbGVyIG9wdGltaXplcyB0aGlzIGF3YXkuIEhh dmUgeW91DQo+ID4gPiBjaGVja2VkIHdoZXRoZXIgaXQgYWN0dWFsbHkgbWFrZXMgYSBkaWZmZXJl bmNlIGluIHRoZSBhc3NlbWJsZXINCj4gPiA+IG91dHB1dD8NCj4gPg0KPiA+IEkgaGF2ZSBub3Qg Y2hlY2tlZCB0aGUgYXNzZW1ibGVyIG91dHB1dC4gSXQgd2FzIGVhc3kgZW5vdWdoIHRvIGZpeA0K PiA+IHRoZSBzb3VyY2UuDQo+IA0KPiBDb3VsZCB5b3U/ICBZb3UncmUgbWFraW5nIHdoYXQgeW91 IGRlc2NyaWJlIGFzIGFuIG9wdGltaXNhdGlvbiBidXQNCj4gdGhlcmUgYXJlIHR3byByZWFzb25z IHdoeSB0aGlzIG1pZ2h0IG5vdCBiZSBzby4gIFRoZSBmaXJzdCBpcyB0aGF0IHRoZQ0KPiBjb21w aWxlciBpcyBlbnRpdGxlZCB0byBpbmxpbmUgc3RhdGljIGZ1bmN0aW9ucy4gIElmIGl0IGRpZCwg bGlrZWx5IGl0DQo+IHBpY2tlZCB1cCB0aGUgb3B0bWlzYXRpb24gYW55d2F5IGFzIEhhbm5lcyBz dWdnZXN0ZWQuICBIb3dldmVyLCB0aGUNCj4gb3RoZXIgcmVhc29uIHRoaXMgbWlnaHQgbm90IGJl IGFuIG9wdGltaXNhdGlvbiAoYXNzdW1pbmcgdGhlIGNvbXBpbGVyDQo+IGRvZXNuJ3QgaW5saW5l IHRoZSBmdW5jdGlvbikgaXMgeW91J3JlIHBhc3NpbmcgYW4gYXJndW1lbnQgd2hpY2ggY2FuIGJl DQo+IG9mZnNldCBjb21wdXRlZC4gIE9uIGFsbCBhcmNoaXRlY3R1cmVzLCB5b3UgaGF2ZSBhIGZp eGVkIG51bWJlciBvZg0KPiByZWdpc3RlcnMgZm9yIHBhc3NpbmcgZnVuY3Rpb24gYXJndW1lbnRz LCB0aGVuIHdlIGhhdmUgdG8gdXNlIHRoZQ0KPiBzdGFjay4gIFVzaW5nIHRoZSBzdGFjayBjb21l cyBpbiBmYXIgbW9yZSBleHBlbnNpdmUgdGhhbiBjb21wdXRpbmcgYW4NCj4gb2Zmc2V0IHRvIGFu IGV4aXN0aW5nIHBvaW50ZXIuICBFdmVuIGlmIHlvdSdyZSBzdGlsbCBpbiByZWdpc3RlcnMsIHRo ZQ0KPiBvZmZzZXQgbm93IGhhcyB0byBiZSBjb21wdXRlZCBhbmQgc3RvcmVkIGFuZCB0aGUgY29t cGlsZXIgbG9zZXMgdHJhY2sNCj4gb2YgdGhlIHJlbGF0aW9uLg0KPiANCj4gVGhlIGJvdHRvbSBs aW5lIGlzIHRoYXQgYWRkaW5nIGFuIGV4dHJhIGFyZ3VtZW50IGZvciBhIHZhbHVlIHdoaWNoIGNh bg0KPiBiZSBvZmZzZXQgY29tcHV0ZWQgaXMgcmFyZWx5IGEgd2luLg0KDQpKYW1lcywNCldoZW4g SSBkaWQgdGhpcywgSSB3YXMgbW9zdGx5IGNvbmNlcm5lZCBhYm91dCB0aGUgY29zdCBvZiByZWVz dGFibGlzaGluZyBzdGF0ZSB0aGF0IHdhcw0KYWxyZWFkeSBrbm93bi4gU28sIGV2ZW4gd2l0aCB0 aGUgZnVuY3Rpb24gYmVpbmcgaW4tbGluZWQsIEkgZmVsdCB0aGUgY29zdCBvZiByZWVzdGFibGlz aGluZw0Kc3RhdGUgdGhhdCB3YXMgYWxyZWFkeSBrbm93biBpcyB1bm5lY2Vzc2FyeS4gSW4gdGhp cyBwYXJ0aWN1bGFyIGNhc2UsIEkgZGlkIG5vdCBjaGFuZ2UgdGhlDQpudW1iZXIgb2YgYXJndW1l bnRzIHRoYXQgd2VyZSBiZWluZyBwYXNzZWQ7IEkganVzdCBjaGFuZ2VkIHRoZSB0eXBlIG9mIG9u ZSBvZiB0aGVtIC0NCmluc3RlYWQgb2YgcGFzc2luZyBzdHJ1Y3QgaHZfZGV2aWNlICosIEkgYW0g bm93IHBhc3Npbmcgc3RydWN0IHN0b3J2c2NfZGV2aWNlICouIEluIHRoZQ0KY3VycmVudCBjb2Rl LCB3ZSBhcmUgdXNpbmcgc3RydWN0IGh2X2RldmljZSAqIHRvIGVzdGFibGlzaCBhIHBvaW50ZXIg dG8gc3RydWN0IHN0b3J2c2NfZGV2aWNlICoNCnZpYSB0aGUgZnVuY3Rpb24gZ2V0X2luX3N0b3Jf ZGV2aWNlKCkuIFRoaXMgcGF0dGVybiBjdXJyZW50bHkgZXhpc3RzIGluIHRoZSBjYWxsIGNoYWlu IGZyb20gdGhlDQppbnRlcnJ1cHQgaGFuZGxlciAtIHN0b3J2c2Nfb25fY2hhbm5lbF9jYWxsYmFj aygpLg0KDQpXaGlsZSB0aGUgY29tcGlsZXIgaXMgc21hcnQgZW5vdWdoIHRvIGlubGluZSBib3Ro IGdldF9pbl9zdG9yX2RldmljZSgpIGFzIHdlbGwgYXMgbWFueSBvZiB0aGUgc3RhdGljDQpmdW5j dGlvbnMgaW4gdGhlIGNhbGwgY2hhaW4gZnJvbSBzdG9ydnNjX29uX2NoYW5uZWxfY2FsbGJhY2so KSwgbG9va2luZyBhdCB0aGUgYXNzZW1ibGVkIGNvZGUsDQp0aGUgY29tcGlsZXIgaXMgcmVwZWF0 ZWRseSBpbmxpbmluZyB0aGUgY2FsbCB0byBnZXRfaW5fc3Rvcl9kZXZpY2UoKSBhbmQgdGhpcyBj bGVhcmx5IGlzIGxlc3MgdGhhbiBvcHRpbWFsLg0KDQpSZWdhcmRzLA0KDQpLLiBZDQoNCg0KDQo= -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Hannes Reinecke <hare@suse.de> |
|---|---|
| Date | 2015-12-21 08:50 +0100 |
| Subject | Re: [PATCH V3 4/4] scsi: storvsc: Tighten up the interrupt path |
| Message-ID | <qI3oe-3AX-9@gated-at.bofh.it> |
| In reply to | #1295269 |
On 12/19/2015 03:28 AM, KY Srinivasan wrote: > [ .. ] >> >> Could you? You're making what you describe as an optimisation but >> there are two reasons why this might not be so. The first is that the >> compiler is entitled to inline static functions. If it did, likely it >> picked up the optmisation anyway as Hannes suggested. However, the >> other reason this might not be an optimisation (assuming the compiler >> doesn't inline the function) is you're passing an argument which can be >> offset computed. On all architectures, you have a fixed number of >> registers for passing function arguments, then we have to use the >> stack. Using the stack comes in far more expensive than computing an >> offset to an existing pointer. Even if you're still in registers, the >> offset now has to be computed and stored and the compiler loses track >> of the relation. >> >> The bottom line is that adding an extra argument for a value which can >> be offset computed is rarely a win. > > James, > When I did this, I was mostly concerned about the cost of reestablishing state that was > already known. So, even with the function being in-lined, I felt the cost of reestablishing > state that was already known is unnecessary. In this particular case, I did not change the > number of arguments that were being passed; I just changed the type of one of them - > instead of passing struct hv_device *, I am now passing struct storvsc_device *. In the > current code, we are using struct hv_device * to establish a pointer to struct storvsc_device * > via the function get_in_stor_device(). This pattern currently exists in the call chain from the > interrupt handler - storvsc_on_channel_callback(). > > While the compiler is smart enough to inline both get_in_stor_device() as well as many of the static > functions in the call chain from storvsc_on_channel_callback(), looking at the assembled code, > the compiler is repeatedly inlining the call to get_in_stor_device() and this clearly is less than optimal. > Which means you actually checked the compiler output, and it made a difference. That's all I wanted to know, as it's not immediately clear from the patch. So: Reviewed-by: Hannes Reinecke <hare@suse.com> Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | James Bottomley <James.Bottomley@HansenPartnership.com> |
|---|---|
| Date | 2015-12-21 17:30 +0100 |
| Subject | Re: [PATCH V3 4/4] scsi: storvsc: Tighten up the interrupt path |
| Message-ID | <qIbvs-nr-25@gated-at.bofh.it> |
| In reply to | #1295269 |
On Sat, 2015-12-19 at 02:28 +0000, KY Srinivasan wrote:
>
> > -----Original Message-----
> > From: James Bottomley [mailto:James.Bottomley@HansenPartnership.com
> > ]
> > Sent: Friday, December 18, 2015 8:48 AM
> > To: KY Srinivasan <kys@microsoft.com>; Hannes Reinecke <
> > hare@suse.de>;
> > gregkh@linuxfoundation.org; linux-kernel@vger.kernel.org;
> > devel@linuxdriverproject.org; ohering@suse.com;
> > jbottomley@parallels.com; hch@infradead.org;
> > linux-scsi@vger.kernel.org;
> > apw@canonical.com; vkuznets@redhat.com; jasowang@redhat.com;
> > martin.petersen@oracle.com
> > Subject: Re: [PATCH V3 4/4] scsi: storvsc: Tighten up the interrupt
> > path
> >
> > On Fri, 2015-12-18 at 16:20 +0000, KY Srinivasan wrote:
> > >
> > > > -----Original Message-----
> > > > From: Hannes Reinecke [mailto:hare@suse.de]
> > > > Sent: Friday, December 18, 2015 12:52 AM
> > > > To: KY Srinivasan <kys@microsoft.com>;
> > > > gregkh@linuxfoundation.org;
> > > > linux-
> > > > kernel@vger.kernel.org; devel@linuxdriverproject.org;
> > > > ohering@suse.com;
> > > > jbottomley@parallels.com; hch@infradead.org;
> > > > linux-scsi@vger.kernel.org;
> > > > apw@canonical.com; vkuznets@redhat.com; jasowang@redhat.com;
> > > > martin.petersen@oracle.com
> > > > Subject: Re: [PATCH V3 4/4] scsi: storvsc: Tighten up the
> > > > interrupt
> > > > path
> > > >
> > > > On 12/13/2015 09:28 PM, K. Y. Srinivasan wrote:
> > > > > On the interrupt path, we repeatedly establish the pointer to
> > > > > the
> > > > > storvsc_device. Fix this.
> > > > >
> > > > > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > > > > Reviewed-by: Long Li <longli@microsoft.com>
> > > > > Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
> > > > > Tested-by: Alex Ng <alexng@microsoft.com>
> > > > > ---
> > > > > drivers/scsi/storvsc_drv.c | 23 ++++++++---------------
> > > > > 1 files changed, 8 insertions(+), 15 deletions(-)
> > > > >
> > > > > diff --git a/drivers/scsi/storvsc_drv.c
> > > > > b/drivers/scsi/storvsc_drv.c
> > > > > index d6ca4f2..b68aebe 100644
> > > > > --- a/drivers/scsi/storvsc_drv.c
> > > > > +++ b/drivers/scsi/storvsc_drv.c
> > > > > @@ -945,19 +945,16 @@ static void storvsc_handle_error(struct
> > > > vmscsi_request *vm_srb,
> > > > > }
> > > > >
> > > > >
> > > > > -static void storvsc_command_completion(struct
> > > > > storvsc_cmd_request
> > > > *cmd_request)
> > > > > +static void storvsc_command_completion(struct
> > > > > storvsc_cmd_request
> > > > *cmd_request,
> > > > > + struct storvsc_device
> > > > > *stor_dev)
> > > > > {
> > > > > struct scsi_cmnd *scmnd = cmd_request->cmd;
> > > > > - struct hv_host_device *host_dev = shost_priv(scmnd
> > > > > ->device-
> > > > > host);
> > > > > struct scsi_sense_hdr sense_hdr;
> > > > > struct vmscsi_request *vm_srb;
> > > > > struct Scsi_Host *host;
> > > > > - struct storvsc_device *stor_dev;
> > > > > - struct hv_device *dev = host_dev->dev;
> > > > > u32 payload_sz = cmd_request->payload_sz;
> > > > > void *payload = cmd_request->payload;
> > > > >
> > > > > - stor_dev = get_in_stor_device(dev);
> > > > > host = stor_dev->host;
> > > > >
> > > > > vm_srb = &cmd_request->vstor_packet.vm_srb;
> > > > > @@ -987,14 +984,13 @@ static void
> > > > > storvsc_command_completion(struct
> > > > storvsc_cmd_request *cmd_request)
> > > > > kfree(payload);
> > > > > }
> > > > >
> > > > > -static void storvsc_on_io_completion(struct hv_device
> > > > > *device,
> > > > > +static void storvsc_on_io_completion(struct storvsc_device
> > > > > *stor_device,
> > > > > struct vstor_packet
> > > > > *vstor_packet,
> > > > > struct
> > > > > storvsc_cmd_request
> > > > > *request)
> > > > > {
> > > > > - struct storvsc_device *stor_device;
> > > > > struct vstor_packet *stor_pkt;
> > > > > + struct hv_device *device = stor_device->device;
> > > > >
> > > > > - stor_device = hv_get_drvdata(device);
> > > > > stor_pkt = &request->vstor_packet;
> > > > >
> > > > > /*
> > > > > @@ -1049,7 +1045,7 @@ static void
> > > > > storvsc_on_io_completion(struct
> > > > hv_device *device,
> > > > > stor_pkt->vm_srb.data_transfer_length =
> > > > > vstor_packet->vm_srb.data_transfer_length;
> > > > >
> > > > > - storvsc_command_completion(request);
> > > > > + storvsc_command_completion(request, stor_device);
> > > > >
> > > > > if (atomic_dec_and_test(&stor_device
> > > > > ->num_outstanding_req) &&
> > > > > stor_device->drain_notify)
> > > > > @@ -1058,21 +1054,19 @@ static void
> > > > > storvsc_on_io_completion(struct
> > > > hv_device *device,
> > > > >
> > > > > }
> > > > >
> > > > > -static void storvsc_on_receive(struct hv_device *device,
> > > > > +static void storvsc_on_receive(struct storvsc_device
> > > > > *stor_device,
> > > > > struct vstor_packet
> > > > > *vstor_packet,
> > > > > struct storvsc_cmd_request
> > > > > *request)
> > > > > {
> > > > > struct storvsc_scan_work *work;
> > > > > - struct storvsc_device *stor_device;
> > > > >
> > > > > switch (vstor_packet->operation) {
> > > > > case VSTOR_OPERATION_COMPLETE_IO:
> > > > > - storvsc_on_io_completion(device,
> > > > > vstor_packet,
> > > > > request);
> > > > > + storvsc_on_io_completion(stor_device,
> > > > > vstor_packet,
> > > > request);
> > > > > break;
> > > > >
> > > > > case VSTOR_OPERATION_REMOVE_DEVICE:
> > > > > case VSTOR_OPERATION_ENUMERATE_BUS:
> > > > > - stor_device = get_in_stor_device(device);
> > > > > work = kmalloc(sizeof(struct
> > > > > storvsc_scan_work),
> > > > GFP_ATOMIC);
> > > > > if (!work)
> > > > > return;
> > > > > @@ -1083,7 +1077,6 @@ static void storvsc_on_receive(struct
> > > > > hv_device
> > > > *device,
> > > > > break;
> > > > >
> > > > > case VSTOR_OPERATION_FCHBA_DATA:
> > > > > - stor_device = get_in_stor_device(device);
> > > > > cache_wwn(stor_device, vstor_packet);
> > > > > #ifdef CONFIG_SCSI_FC_ATTRS
> > > > > fc_host_node_name(stor_device->host) =
> > > > > stor_device-
> > > > > node_name;
> > > > > @@ -1133,7 +1126,7 @@ static void
> > > > > storvsc_on_channel_callback(void
> > > > *context)
> > > > > vmscsi_size_delta))
> > > > > ;
> > > > > complete(&request
> > > > > ->wait_event);
> > > > > } else {
> > > > > - storvsc_on_receive(device,
> > > > > + storvsc_on_receive(stor_devi
> > > > > ce,
> > > > > (struct
> > > > > vstor_packet
> > > > *)packet,
> > > > > request);
> > > > > }
> > > > >
> > > > Hmm. I would've thought the compiler optimizes this away. Have
> > > > you
> > > > checked whether it actually makes a difference in the assembler
> > > > output?
> > >
> > > I have not checked the assembler output. It was easy enough to
> > > fix
> > > the source.
> >
> > Could you? You're making what you describe as an optimisation but
> > there are two reasons why this might not be so. The first is that
> > the
> > compiler is entitled to inline static functions. If it did, likely
> > it
> > picked up the optmisation anyway as Hannes suggested. However, the
> > other reason this might not be an optimisation (assuming the
> > compiler
> > doesn't inline the function) is you're passing an argument which
> > can be
> > offset computed. On all architectures, you have a fixed number of
> > registers for passing function arguments, then we have to use the
> > stack. Using the stack comes in far more expensive than computing
> > an
> > offset to an existing pointer. Even if you're still in registers,
> > the
> > offset now has to be computed and stored and the compiler loses
> > track
> > of the relation.
> >
> > The bottom line is that adding an extra argument for a value which
> > can
> > be offset computed is rarely a win.
>
> James,
> When I did this, I was mostly concerned about the cost of
> reestablishing state that was
> already known. So, even with the function being in-lined, I felt the
> cost of reestablishing
> state that was already known is unnecessary. In this particular case,
> I did not change the
> number of arguments that were being passed; I just changed the type
> of one of them -
> instead of passing struct hv_device *, I am now passing struct
> storvsc_device *. In the
> current code, we are using struct hv_device * to establish a pointer
> to struct storvsc_device *
> via the function get_in_stor_device(). This pattern currently exists
> in the call chain from the
> interrupt handler - storvsc_on_channel_callback().
>
> While the compiler is smart enough to inline both
> get_in_stor_device() as well as many of the static
> functions in the call chain from storvsc_on_channel_callback(),
> looking at the assembled code,
> the compiler is repeatedly inlining the call to get_in_stor_device()
> and this clearly is less than optimal.
OK, so the reason for the recomputation is the destruction condition
check which is evaluated every time you call it? Perhaps what you
simply want is an __get_in_stor_device() that does the offset
mathematics without the destruction check. It's doing exactly what
passing the additional parameter does: the calling function is taking
on the burden of verifying they've got a device which is still valid.
I'm not making this a hard requirement for reviewing the code: you have
arguments to spare in the functions, so I don't think it matters which
way this is done. I do, however, think it makes consumers of the stor
device think about why they're using it and whether they actually need
the destruct check.
James
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | KY Srinivasan <kys@microsoft.com> |
|---|---|
| Date | 2015-12-21 20:50 +0100 |
| Subject | RE: [PATCH V3 4/4] scsi: storvsc: Tighten up the interrupt path |
| Message-ID | <qIeD0-2hx-9@gated-at.bofh.it> |
| In reply to | #1296060 |
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSmFtZXMgQm90dG9tbGV5 IFttYWlsdG86SmFtZXMuQm90dG9tbGV5QEhhbnNlblBhcnRuZXJzaGlwLmNvbV0NCj4gU2VudDog TW9uZGF5LCBEZWNlbWJlciAyMSwgMjAxNSA4OjI4IEFNDQo+IFRvOiBLWSBTcmluaXZhc2FuIDxr eXNAbWljcm9zb2Z0LmNvbT47IEhhbm5lcyBSZWluZWNrZSA8aGFyZUBzdXNlLmRlPjsNCj4gZ3Jl Z2toQGxpbnV4Zm91bmRhdGlvbi5vcmc7IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7DQo+ IGRldmVsQGxpbnV4ZHJpdmVycHJvamVjdC5vcmc7IG9oZXJpbmdAc3VzZS5jb207DQo+IGpib3R0 b21sZXlAcGFyYWxsZWxzLmNvbTsgaGNoQGluZnJhZGVhZC5vcmc7IGxpbnV4LXNjc2lAdmdlci5r ZXJuZWwub3JnOw0KPiBhcHdAY2Fub25pY2FsLmNvbTsgdmt1em5ldHNAcmVkaGF0LmNvbTsgamFz b3dhbmdAcmVkaGF0LmNvbTsNCj4gbWFydGluLnBldGVyc2VuQG9yYWNsZS5jb20NCj4gU3ViamVj dDogUmU6IFtQQVRDSCBWMyA0LzRdIHNjc2k6IHN0b3J2c2M6IFRpZ2h0ZW4gdXAgdGhlIGludGVy cnVwdCBwYXRoDQo+IA0KPiBPbiBTYXQsIDIwMTUtMTItMTkgYXQgMDI6MjggKzAwMDAsIEtZIFNy aW5pdmFzYW4gd3JvdGU6DQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID4gPiBGcm9tOiBKYW1lcyBCb3R0b21sZXkNCj4gW21haWx0bzpKYW1lcy5Cb3R0b21sZXlASGFu c2VuUGFydG5lcnNoaXAuY29tDQo+ID4gPiBdDQo+ID4gPiBTZW50OiBGcmlkYXksIERlY2VtYmVy IDE4LCAyMDE1IDg6NDggQU0NCj4gPiA+IFRvOiBLWSBTcmluaXZhc2FuIDxreXNAbWljcm9zb2Z0 LmNvbT47IEhhbm5lcyBSZWluZWNrZSA8DQo+ID4gPiBoYXJlQHN1c2UuZGU+Ow0KPiA+ID4gZ3Jl Z2toQGxpbnV4Zm91bmRhdGlvbi5vcmc7IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7DQo+ ID4gPiBkZXZlbEBsaW51eGRyaXZlcnByb2plY3Qub3JnOyBvaGVyaW5nQHN1c2UuY29tOw0KPiA+ ID4gamJvdHRvbWxleUBwYXJhbGxlbHMuY29tOyBoY2hAaW5mcmFkZWFkLm9yZzsNCj4gPiA+IGxp bnV4LXNjc2lAdmdlci5rZXJuZWwub3JnOw0KPiA+ID4gYXB3QGNhbm9uaWNhbC5jb207IHZrdXpu ZXRzQHJlZGhhdC5jb207IGphc293YW5nQHJlZGhhdC5jb207DQo+ID4gPiBtYXJ0aW4ucGV0ZXJz ZW5Ab3JhY2xlLmNvbQ0KPiA+ID4gU3ViamVjdDogUmU6IFtQQVRDSCBWMyA0LzRdIHNjc2k6IHN0 b3J2c2M6IFRpZ2h0ZW4gdXAgdGhlIGludGVycnVwdA0KPiA+ID4gcGF0aA0KPiA+ID4NCj4gPiA+ IE9uIEZyaSwgMjAxNS0xMi0xOCBhdCAxNjoyMCArMDAwMCwgS1kgU3Jpbml2YXNhbiB3cm90ZToN Cj4gPiA+ID4NCj4gPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiA+ IEZyb206IEhhbm5lcyBSZWluZWNrZSBbbWFpbHRvOmhhcmVAc3VzZS5kZV0NCj4gPiA+ID4gPiBT ZW50OiBGcmlkYXksIERlY2VtYmVyIDE4LCAyMDE1IDEyOjUyIEFNDQo+ID4gPiA+ID4gVG86IEtZ IFNyaW5pdmFzYW4gPGt5c0BtaWNyb3NvZnQuY29tPjsNCj4gPiA+ID4gPiBncmVna2hAbGludXhm b3VuZGF0aW9uLm9yZzsNCj4gPiA+ID4gPiBsaW51eC0NCj4gPiA+ID4gPiBrZXJuZWxAdmdlci5r ZXJuZWwub3JnOyBkZXZlbEBsaW51eGRyaXZlcnByb2plY3Qub3JnOw0KPiA+ID4gPiA+IG9oZXJp bmdAc3VzZS5jb207DQo+ID4gPiA+ID4gamJvdHRvbWxleUBwYXJhbGxlbHMuY29tOyBoY2hAaW5m cmFkZWFkLm9yZzsNCj4gPiA+ID4gPiBsaW51eC1zY3NpQHZnZXIua2VybmVsLm9yZzsNCj4gPiA+ ID4gPiBhcHdAY2Fub25pY2FsLmNvbTsgdmt1em5ldHNAcmVkaGF0LmNvbTsgamFzb3dhbmdAcmVk aGF0LmNvbTsNCj4gPiA+ID4gPiBtYXJ0aW4ucGV0ZXJzZW5Ab3JhY2xlLmNvbQ0KPiA+ID4gPiA+ IFN1YmplY3Q6IFJlOiBbUEFUQ0ggVjMgNC80XSBzY3NpOiBzdG9ydnNjOiBUaWdodGVuIHVwIHRo ZQ0KPiA+ID4gPiA+IGludGVycnVwdA0KPiA+ID4gPiA+IHBhdGgNCj4gPiA+ID4gPg0KPiA+ID4g PiA+IE9uIDEyLzEzLzIwMTUgMDk6MjggUE0sIEsuIFkuIFNyaW5pdmFzYW4gd3JvdGU6DQo+ID4g PiA+ID4gPiBPbiB0aGUgaW50ZXJydXB0IHBhdGgsIHdlIHJlcGVhdGVkbHkgZXN0YWJsaXNoIHRo ZSBwb2ludGVyIHRvDQo+ID4gPiA+ID4gPiB0aGUNCj4gPiA+ID4gPiA+IHN0b3J2c2NfZGV2aWNl LiBGaXggdGhpcy4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBTaWduZWQtb2ZmLWJ5OiBLLiBZ LiBTcmluaXZhc2FuIDxreXNAbWljcm9zb2Z0LmNvbT4NCj4gPiA+ID4gPiA+IFJldmlld2VkLWJ5 OiBMb25nIExpIDxsb25nbGlAbWljcm9zb2Z0LmNvbT4NCj4gPiA+ID4gPiA+IFJldmlld2VkLWJ5 OiBKb2hhbm5lcyBUaHVtc2hpcm4gPGp0aHVtc2hpcm5Ac3VzZS5kZT4NCj4gPiA+ID4gPiA+IFRl c3RlZC1ieTogQWxleCBOZyA8YWxleG5nQG1pY3Jvc29mdC5jb20+DQo+ID4gPiA+ID4gPiAtLS0N Cj4gPiA+ID4gPiA+ICAgZHJpdmVycy9zY3NpL3N0b3J2c2NfZHJ2LmMgfCAgIDIzICsrKysrKysr LS0tLS0tLS0tLS0tLS0tDQo+ID4gPiA+ID4gPiAgIDEgZmlsZXMgY2hhbmdlZCwgOCBpbnNlcnRp b25zKCspLCAxNSBkZWxldGlvbnMoLSkNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBkaWZmIC0t Z2l0IGEvZHJpdmVycy9zY3NpL3N0b3J2c2NfZHJ2LmMNCj4gPiA+ID4gPiA+IGIvZHJpdmVycy9z Y3NpL3N0b3J2c2NfZHJ2LmMNCj4gPiA+ID4gPiA+IGluZGV4IGQ2Y2E0ZjIuLmI2OGFlYmUgMTAw NjQ0DQo+ID4gPiA+ID4gPiAtLS0gYS9kcml2ZXJzL3Njc2kvc3RvcnZzY19kcnYuYw0KPiA+ID4g PiA+ID4gKysrIGIvZHJpdmVycy9zY3NpL3N0b3J2c2NfZHJ2LmMNCj4gPiA+ID4gPiA+IEBAIC05 NDUsMTkgKzk0NSwxNiBAQCBzdGF0aWMgdm9pZCBzdG9ydnNjX2hhbmRsZV9lcnJvcihzdHJ1Y3QN Cj4gPiA+ID4gPiB2bXNjc2lfcmVxdWVzdCAqdm1fc3JiLA0KPiA+ID4gPiA+ID4gICB9DQo+ID4g PiA+ID4gPg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IC1zdGF0aWMgdm9pZCBzdG9ydnNjX2Nv bW1hbmRfY29tcGxldGlvbihzdHJ1Y3QNCj4gPiA+ID4gPiA+IHN0b3J2c2NfY21kX3JlcXVlc3QN Cj4gPiA+ID4gPiAqY21kX3JlcXVlc3QpDQo+ID4gPiA+ID4gPiArc3RhdGljIHZvaWQgc3RvcnZz Y19jb21tYW5kX2NvbXBsZXRpb24oc3RydWN0DQo+ID4gPiA+ID4gPiBzdG9ydnNjX2NtZF9yZXF1 ZXN0DQo+ID4gPiA+ID4gKmNtZF9yZXF1ZXN0LA0KPiA+ID4gPiA+ID4gKwkJCQkgICAgICAgc3Ry dWN0IHN0b3J2c2NfZGV2aWNlDQo+ID4gPiA+ID4gPiAqc3Rvcl9kZXYpDQo+ID4gPiA+ID4gPiAg IHsNCj4gPiA+ID4gPiA+ICAgCXN0cnVjdCBzY3NpX2NtbmQgKnNjbW5kID0gY21kX3JlcXVlc3Qt PmNtZDsNCj4gPiA+ID4gPiA+IC0Jc3RydWN0IGh2X2hvc3RfZGV2aWNlICpob3N0X2RldiA9IHNo b3N0X3ByaXYoc2NtbmQNCj4gPiA+ID4gPiA+IC0+ZGV2aWNlLQ0KPiA+ID4gPiA+ID4gaG9zdCk7 DQo+ID4gPiA+ID4gPiAgIAlzdHJ1Y3Qgc2NzaV9zZW5zZV9oZHIgc2Vuc2VfaGRyOw0KPiA+ID4g PiA+ID4gICAJc3RydWN0IHZtc2NzaV9yZXF1ZXN0ICp2bV9zcmI7DQo+ID4gPiA+ID4gPiAgIAlz dHJ1Y3QgU2NzaV9Ib3N0ICpob3N0Ow0KPiA+ID4gPiA+ID4gLQlzdHJ1Y3Qgc3RvcnZzY19kZXZp Y2UgKnN0b3JfZGV2Ow0KPiA+ID4gPiA+ID4gLQlzdHJ1Y3QgaHZfZGV2aWNlICpkZXYgPSBob3N0 X2Rldi0+ZGV2Ow0KPiA+ID4gPiA+ID4gICAJdTMyIHBheWxvYWRfc3ogPSBjbWRfcmVxdWVzdC0+ cGF5bG9hZF9zejsNCj4gPiA+ID4gPiA+ICAgCXZvaWQgKnBheWxvYWQgPSBjbWRfcmVxdWVzdC0+ cGF5bG9hZDsNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiAtCXN0b3JfZGV2ID0gZ2V0X2luX3N0 b3JfZGV2aWNlKGRldik7DQo+ID4gPiA+ID4gPiAgIAlob3N0ID0gc3Rvcl9kZXYtPmhvc3Q7DQo+ ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gICAJdm1fc3JiID0gJmNtZF9yZXF1ZXN0LT52c3Rvcl9w YWNrZXQudm1fc3JiOw0KPiA+ID4gPiA+ID4gQEAgLTk4NywxNCArOTg0LDEzIEBAIHN0YXRpYyB2 b2lkDQo+ID4gPiA+ID4gPiBzdG9ydnNjX2NvbW1hbmRfY29tcGxldGlvbihzdHJ1Y3QNCj4gPiA+ ID4gPiBzdG9ydnNjX2NtZF9yZXF1ZXN0ICpjbWRfcmVxdWVzdCkNCj4gPiA+ID4gPiA+ICAgCQlr ZnJlZShwYXlsb2FkKTsNCj4gPiA+ID4gPiA+ICAgfQ0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ IC1zdGF0aWMgdm9pZCBzdG9ydnNjX29uX2lvX2NvbXBsZXRpb24oc3RydWN0IGh2X2RldmljZQ0K PiA+ID4gPiA+ID4gKmRldmljZSwNCj4gPiA+ID4gPiA+ICtzdGF0aWMgdm9pZCBzdG9ydnNjX29u X2lvX2NvbXBsZXRpb24oc3RydWN0IHN0b3J2c2NfZGV2aWNlDQo+ID4gPiA+ID4gPiAqc3Rvcl9k ZXZpY2UsDQo+ID4gPiA+ID4gPiAgIAkJCQkgIHN0cnVjdCB2c3Rvcl9wYWNrZXQNCj4gPiA+ID4g PiA+ICp2c3Rvcl9wYWNrZXQsDQo+ID4gPiA+ID4gPiAgIAkJCQkgIHN0cnVjdA0KPiA+ID4gPiA+ ID4gc3RvcnZzY19jbWRfcmVxdWVzdA0KPiA+ID4gPiA+ID4gKnJlcXVlc3QpDQo+ID4gPiA+ID4g PiAgIHsNCj4gPiA+ID4gPiA+IC0Jc3RydWN0IHN0b3J2c2NfZGV2aWNlICpzdG9yX2RldmljZTsN Cj4gPiA+ID4gPiA+ICAgCXN0cnVjdCB2c3Rvcl9wYWNrZXQgKnN0b3JfcGt0Ow0KPiA+ID4gPiA+ ID4gKwlzdHJ1Y3QgaHZfZGV2aWNlICpkZXZpY2UgPSBzdG9yX2RldmljZS0+ZGV2aWNlOw0KPiA+ ID4gPiA+ID4NCj4gPiA+ID4gPiA+IC0Jc3Rvcl9kZXZpY2UgPSBodl9nZXRfZHJ2ZGF0YShkZXZp Y2UpOw0KPiA+ID4gPiA+ID4gICAJc3Rvcl9wa3QgPSAmcmVxdWVzdC0+dnN0b3JfcGFja2V0Ow0K PiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ICAgCS8qDQo+ID4gPiA+ID4gPiBAQCAtMTA0OSw3ICsx MDQ1LDcgQEAgc3RhdGljIHZvaWQNCj4gPiA+ID4gPiA+IHN0b3J2c2Nfb25faW9fY29tcGxldGlv bihzdHJ1Y3QNCj4gPiA+ID4gPiBodl9kZXZpY2UgKmRldmljZSwNCj4gPiA+ID4gPiA+ICAgCXN0 b3JfcGt0LT52bV9zcmIuZGF0YV90cmFuc2Zlcl9sZW5ndGggPQ0KPiA+ID4gPiA+ID4gICAJdnN0 b3JfcGFja2V0LT52bV9zcmIuZGF0YV90cmFuc2Zlcl9sZW5ndGg7DQo+ID4gPiA+ID4gPg0KPiA+ ID4gPiA+ID4gLQlzdG9ydnNjX2NvbW1hbmRfY29tcGxldGlvbihyZXF1ZXN0KTsNCj4gPiA+ID4g PiA+ICsJc3RvcnZzY19jb21tYW5kX2NvbXBsZXRpb24ocmVxdWVzdCwgc3Rvcl9kZXZpY2UpOw0K PiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ICAgCWlmIChhdG9taWNfZGVjX2FuZF90ZXN0KCZzdG9y X2RldmljZQ0KPiA+ID4gPiA+ID4gLT5udW1fb3V0c3RhbmRpbmdfcmVxKSAmJg0KPiA+ID4gPiA+ ID4gICAJCXN0b3JfZGV2aWNlLT5kcmFpbl9ub3RpZnkpDQo+ID4gPiA+ID4gPiBAQCAtMTA1OCwy MSArMTA1NCwxOSBAQCBzdGF0aWMgdm9pZA0KPiA+ID4gPiA+ID4gc3RvcnZzY19vbl9pb19jb21w bGV0aW9uKHN0cnVjdA0KPiA+ID4gPiA+IGh2X2RldmljZSAqZGV2aWNlLA0KPiA+ID4gPiA+ID4N Cj4gPiA+ID4gPiA+ICAgfQ0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IC1zdGF0aWMgdm9pZCBz dG9ydnNjX29uX3JlY2VpdmUoc3RydWN0IGh2X2RldmljZSAqZGV2aWNlLA0KPiA+ID4gPiA+ID4g K3N0YXRpYyB2b2lkIHN0b3J2c2Nfb25fcmVjZWl2ZShzdHJ1Y3Qgc3RvcnZzY19kZXZpY2UNCj4g PiA+ID4gPiA+ICpzdG9yX2RldmljZSwNCj4gPiA+ID4gPiA+ICAgCQkJICAgICBzdHJ1Y3QgdnN0 b3JfcGFja2V0DQo+ID4gPiA+ID4gPiAqdnN0b3JfcGFja2V0LA0KPiA+ID4gPiA+ID4gICAJCQkg ICAgIHN0cnVjdCBzdG9ydnNjX2NtZF9yZXF1ZXN0DQo+ID4gPiA+ID4gPiAqcmVxdWVzdCkNCj4g PiA+ID4gPiA+ICAgew0KPiA+ID4gPiA+ID4gICAJc3RydWN0IHN0b3J2c2Nfc2Nhbl93b3JrICp3 b3JrOw0KPiA+ID4gPiA+ID4gLQlzdHJ1Y3Qgc3RvcnZzY19kZXZpY2UgKnN0b3JfZGV2aWNlOw0K PiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ICAgCXN3aXRjaCAodnN0b3JfcGFja2V0LT5vcGVyYXRp b24pIHsNCj4gPiA+ID4gPiA+ICAgCWNhc2UgVlNUT1JfT1BFUkFUSU9OX0NPTVBMRVRFX0lPOg0K PiA+ID4gPiA+ID4gLQkJc3RvcnZzY19vbl9pb19jb21wbGV0aW9uKGRldmljZSwNCj4gPiA+ID4g PiA+IHZzdG9yX3BhY2tldCwNCj4gPiA+ID4gPiA+IHJlcXVlc3QpOw0KPiA+ID4gPiA+ID4gKwkJ c3RvcnZzY19vbl9pb19jb21wbGV0aW9uKHN0b3JfZGV2aWNlLA0KPiA+ID4gPiA+ID4gdnN0b3Jf cGFja2V0LA0KPiA+ID4gPiA+IHJlcXVlc3QpOw0KPiA+ID4gPiA+ID4gICAJCWJyZWFrOw0KPiA+ ID4gPiA+ID4NCj4gPiA+ID4gPiA+ICAgCWNhc2UgVlNUT1JfT1BFUkFUSU9OX1JFTU9WRV9ERVZJ Q0U6DQo+ID4gPiA+ID4gPiAgIAljYXNlIFZTVE9SX09QRVJBVElPTl9FTlVNRVJBVEVfQlVTOg0K PiA+ID4gPiA+ID4gLQkJc3Rvcl9kZXZpY2UgPSBnZXRfaW5fc3Rvcl9kZXZpY2UoZGV2aWNlKTsN Cj4gPiA+ID4gPiA+ICAgCQl3b3JrID0ga21hbGxvYyhzaXplb2Yoc3RydWN0DQo+ID4gPiA+ID4g PiBzdG9ydnNjX3NjYW5fd29yayksDQo+ID4gPiA+ID4gR0ZQX0FUT01JQyk7DQo+ID4gPiA+ID4g PiAgIAkJaWYgKCF3b3JrKQ0KPiA+ID4gPiA+ID4gICAJCQlyZXR1cm47DQo+ID4gPiA+ID4gPiBA QCAtMTA4Myw3ICsxMDc3LDYgQEAgc3RhdGljIHZvaWQgc3RvcnZzY19vbl9yZWNlaXZlKHN0cnVj dA0KPiA+ID4gPiA+ID4gaHZfZGV2aWNlDQo+ID4gPiA+ID4gKmRldmljZSwNCj4gPiA+ID4gPiA+ ICAgCQlicmVhazsNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiAgIAljYXNlIFZTVE9SX09QRVJB VElPTl9GQ0hCQV9EQVRBOg0KPiA+ID4gPiA+ID4gLQkJc3Rvcl9kZXZpY2UgPSBnZXRfaW5fc3Rv cl9kZXZpY2UoZGV2aWNlKTsNCj4gPiA+ID4gPiA+ICAgCQljYWNoZV93d24oc3Rvcl9kZXZpY2Us IHZzdG9yX3BhY2tldCk7DQo+ID4gPiA+ID4gPiAgICNpZmRlZiBDT05GSUdfU0NTSV9GQ19BVFRS Uw0KPiA+ID4gPiA+ID4gICAJCWZjX2hvc3Rfbm9kZV9uYW1lKHN0b3JfZGV2aWNlLT5ob3N0KSA9 DQo+ID4gPiA+ID4gPiBzdG9yX2RldmljZS0NCj4gPiA+ID4gPiA+IG5vZGVfbmFtZTsNCj4gPiA+ ID4gPiA+IEBAIC0xMTMzLDcgKzExMjYsNyBAQCBzdGF0aWMgdm9pZA0KPiA+ID4gPiA+ID4gc3Rv cnZzY19vbl9jaGFubmVsX2NhbGxiYWNrKHZvaWQNCj4gPiA+ID4gPiAqY29udGV4dCkNCj4gPiA+ ID4gPiA+ICAgCQkJCQl2bXNjc2lfc2l6ZV9kZWx0YSkpDQo+ID4gPiA+ID4gPiA7DQo+ID4gPiA+ ID4gPiAgIAkJCQljb21wbGV0ZSgmcmVxdWVzdA0KPiA+ID4gPiA+ID4gLT53YWl0X2V2ZW50KTsN Cj4gPiA+ID4gPiA+ICAgCQkJfSBlbHNlIHsNCj4gPiA+ID4gPiA+IC0JCQkJc3RvcnZzY19vbl9y ZWNlaXZlKGRldmljZSwNCj4gPiA+ID4gPiA+ICsJCQkJc3RvcnZzY19vbl9yZWNlaXZlKHN0b3Jf ZGV2aQ0KPiA+ID4gPiA+ID4gY2UsDQo+ID4gPiA+ID4gPiAgIAkJCQkJCShzdHJ1Y3QNCj4gPiA+ ID4gPiA+IHZzdG9yX3BhY2tldA0KPiA+ID4gPiA+ICopcGFja2V0LA0KPiA+ID4gPiA+ID4gICAJ CQkJCQlyZXF1ZXN0KTsNCj4gPiA+ID4gPiA+ICAgCQkJfQ0KPiA+ID4gPiA+ID4NCj4gPiA+ID4g PiBIbW0uIEkgd291bGQndmUgdGhvdWdodCB0aGUgY29tcGlsZXIgb3B0aW1pemVzIHRoaXMgYXdh eS4gSGF2ZQ0KPiA+ID4gPiA+IHlvdQ0KPiA+ID4gPiA+IGNoZWNrZWQgd2hldGhlciBpdCBhY3R1 YWxseSBtYWtlcyBhIGRpZmZlcmVuY2UgaW4gdGhlIGFzc2VtYmxlcg0KPiA+ID4gPiA+IG91dHB1 dD8NCj4gPiA+ID4NCj4gPiA+ID4gSSBoYXZlIG5vdCBjaGVja2VkIHRoZSBhc3NlbWJsZXIgb3V0 cHV0LiBJdCB3YXMgZWFzeSBlbm91Z2ggdG8NCj4gPiA+ID4gZml4DQo+ID4gPiA+IHRoZSBzb3Vy Y2UuDQo+ID4gPg0KPiA+ID4gQ291bGQgeW91PyAgWW91J3JlIG1ha2luZyB3aGF0IHlvdSBkZXNj cmliZSBhcyBhbiBvcHRpbWlzYXRpb24gYnV0DQo+ID4gPiB0aGVyZSBhcmUgdHdvIHJlYXNvbnMg d2h5IHRoaXMgbWlnaHQgbm90IGJlIHNvLiAgVGhlIGZpcnN0IGlzIHRoYXQNCj4gPiA+IHRoZQ0K PiA+ID4gY29tcGlsZXIgaXMgZW50aXRsZWQgdG8gaW5saW5lIHN0YXRpYyBmdW5jdGlvbnMuICBJ ZiBpdCBkaWQsIGxpa2VseQ0KPiA+ID4gaXQNCj4gPiA+IHBpY2tlZCB1cCB0aGUgb3B0bWlzYXRp b24gYW55d2F5IGFzIEhhbm5lcyBzdWdnZXN0ZWQuICBIb3dldmVyLCB0aGUNCj4gPiA+IG90aGVy IHJlYXNvbiB0aGlzIG1pZ2h0IG5vdCBiZSBhbiBvcHRpbWlzYXRpb24gKGFzc3VtaW5nIHRoZQ0K PiA+ID4gY29tcGlsZXINCj4gPiA+IGRvZXNuJ3QgaW5saW5lIHRoZSBmdW5jdGlvbikgaXMgeW91 J3JlIHBhc3NpbmcgYW4gYXJndW1lbnQgd2hpY2gNCj4gPiA+IGNhbiBiZQ0KPiA+ID4gb2Zmc2V0 IGNvbXB1dGVkLiAgT24gYWxsIGFyY2hpdGVjdHVyZXMsIHlvdSBoYXZlIGEgZml4ZWQgbnVtYmVy IG9mDQo+ID4gPiByZWdpc3RlcnMgZm9yIHBhc3NpbmcgZnVuY3Rpb24gYXJndW1lbnRzLCB0aGVu IHdlIGhhdmUgdG8gdXNlIHRoZQ0KPiA+ID4gc3RhY2suICBVc2luZyB0aGUgc3RhY2sgY29tZXMg aW4gZmFyIG1vcmUgZXhwZW5zaXZlIHRoYW4gY29tcHV0aW5nDQo+ID4gPiBhbg0KPiA+ID4gb2Zm c2V0IHRvIGFuIGV4aXN0aW5nIHBvaW50ZXIuICBFdmVuIGlmIHlvdSdyZSBzdGlsbCBpbiByZWdp c3RlcnMsDQo+ID4gPiB0aGUNCj4gPiA+IG9mZnNldCBub3cgaGFzIHRvIGJlIGNvbXB1dGVkIGFu ZCBzdG9yZWQgYW5kIHRoZSBjb21waWxlciBsb3Nlcw0KPiA+ID4gdHJhY2sNCj4gPiA+IG9mIHRo ZSByZWxhdGlvbi4NCj4gPiA+DQo+ID4gPiBUaGUgYm90dG9tIGxpbmUgaXMgdGhhdCBhZGRpbmcg YW4gZXh0cmEgYXJndW1lbnQgZm9yIGEgdmFsdWUgd2hpY2gNCj4gPiA+IGNhbg0KPiA+ID4gYmUg b2Zmc2V0IGNvbXB1dGVkIGlzIHJhcmVseSBhIHdpbi4NCj4gPg0KPiA+IEphbWVzLA0KPiA+IFdo ZW4gSSBkaWQgdGhpcywgSSB3YXMgbW9zdGx5IGNvbmNlcm5lZCBhYm91dCB0aGUgY29zdCBvZg0K PiA+IHJlZXN0YWJsaXNoaW5nIHN0YXRlIHRoYXQgd2FzDQo+ID4gYWxyZWFkeSBrbm93bi4gU28s IGV2ZW4gd2l0aCB0aGUgZnVuY3Rpb24gYmVpbmcgaW4tbGluZWQsIEkgZmVsdCB0aGUNCj4gPiBj b3N0IG9mIHJlZXN0YWJsaXNoaW5nDQo+ID4gc3RhdGUgdGhhdCB3YXMgYWxyZWFkeSBrbm93biBp cyB1bm5lY2Vzc2FyeS4gSW4gdGhpcyBwYXJ0aWN1bGFyIGNhc2UsDQo+ID4gSSBkaWQgbm90IGNo YW5nZSB0aGUNCj4gPiBudW1iZXIgb2YgYXJndW1lbnRzIHRoYXQgd2VyZSBiZWluZyBwYXNzZWQ7 IEkganVzdCBjaGFuZ2VkIHRoZSB0eXBlDQo+ID4gb2Ygb25lIG9mIHRoZW0gLQ0KPiA+IGluc3Rl YWQgb2YgcGFzc2luZyBzdHJ1Y3QgaHZfZGV2aWNlICosIEkgYW0gbm93IHBhc3Npbmcgc3RydWN0 DQo+ID4gc3RvcnZzY19kZXZpY2UgKi4gSW4gdGhlDQo+ID4gY3VycmVudCBjb2RlLCB3ZSBhcmUg dXNpbmcgc3RydWN0IGh2X2RldmljZSAqIHRvIGVzdGFibGlzaCBhIHBvaW50ZXINCj4gPiB0byBz dHJ1Y3Qgc3RvcnZzY19kZXZpY2UgKg0KPiA+IHZpYSB0aGUgZnVuY3Rpb24gZ2V0X2luX3N0b3Jf ZGV2aWNlKCkuIFRoaXMgcGF0dGVybiBjdXJyZW50bHkgZXhpc3RzDQo+ID4gaW4gdGhlIGNhbGwg Y2hhaW4gZnJvbSB0aGUNCj4gPiBpbnRlcnJ1cHQgaGFuZGxlciAtIHN0b3J2c2Nfb25fY2hhbm5l bF9jYWxsYmFjaygpLg0KPiA+DQo+ID4gV2hpbGUgdGhlIGNvbXBpbGVyIGlzIHNtYXJ0IGVub3Vn aCB0byBpbmxpbmUgYm90aA0KPiA+IGdldF9pbl9zdG9yX2RldmljZSgpIGFzIHdlbGwgYXMgbWFu eSBvZiB0aGUgc3RhdGljDQo+ID4gZnVuY3Rpb25zIGluIHRoZSBjYWxsIGNoYWluIGZyb20gc3Rv cnZzY19vbl9jaGFubmVsX2NhbGxiYWNrKCksDQo+ID4gbG9va2luZyBhdCB0aGUgYXNzZW1ibGVk IGNvZGUsDQo+ID4gdGhlIGNvbXBpbGVyIGlzIHJlcGVhdGVkbHkgaW5saW5pbmcgdGhlIGNhbGwg dG8gZ2V0X2luX3N0b3JfZGV2aWNlKCkNCj4gPiBhbmQgdGhpcyBjbGVhcmx5IGlzIGxlc3MgdGhh biBvcHRpbWFsLg0KPiANCj4gT0ssIHNvIHRoZSByZWFzb24gZm9yIHRoZSByZWNvbXB1dGF0aW9u IGlzIHRoZSBkZXN0cnVjdGlvbiBjb25kaXRpb24NCj4gY2hlY2sgd2hpY2ggaXMgZXZhbHVhdGVk IGV2ZXJ5IHRpbWUgeW91IGNhbGwgaXQ/ICBQZXJoYXBzIHdoYXQgeW91DQo+IHNpbXBseSB3YW50 IGlzIGFuIF9fZ2V0X2luX3N0b3JfZGV2aWNlKCkgdGhhdCBkb2VzIHRoZSBvZmZzZXQNCj4gbWF0 aGVtYXRpY3Mgd2l0aG91dCB0aGUgZGVzdHJ1Y3Rpb24gY2hlY2suICBJdCdzIGRvaW5nIGV4YWN0 bHkgd2hhdA0KPiBwYXNzaW5nIHRoZSBhZGRpdGlvbmFsIHBhcmFtZXRlciBkb2VzOiB0aGUgY2Fs bGluZyBmdW5jdGlvbiBpcyB0YWtpbmcNCj4gb24gdGhlIGJ1cmRlbiBvZiB2ZXJpZnlpbmcgdGhl eSd2ZSBnb3QgYSBkZXZpY2Ugd2hpY2ggaXMgc3RpbGwgdmFsaWQuDQo+IA0KPiBJJ20gbm90IG1h a2luZyB0aGlzIGEgaGFyZCByZXF1aXJlbWVudCBmb3IgcmV2aWV3aW5nIHRoZSBjb2RlOiB5b3Ug aGF2ZQ0KPiBhcmd1bWVudHMgdG8gc3BhcmUgaW4gdGhlIGZ1bmN0aW9ucywgc28gSSBkb24ndCB0 aGluayBpdCBtYXR0ZXJzIHdoaWNoDQo+IHdheSB0aGlzIGlzIGRvbmUuDQoNCkFncmVlZC4NCg0K PiAgSSBkbywgaG93ZXZlciwgdGhpbmsgaXQgbWFrZXMgY29uc3VtZXJzIG9mIHRoZSBzdG9yDQo+ IGRldmljZSB0aGluayBhYm91dCB3aHkgdGhleSdyZSB1c2luZyBpdCBhbmQgd2hldGhlciB0aGV5 IGFjdHVhbGx5IG5lZWQNCj4gdGhlIGRlc3RydWN0IGNoZWNrLg0KDQpUaGVyZSBpcyBoaWdoZXIg bGV2ZWwgc2VyaWFsaXphdGlvbiB0aGF0IG1ha2VzIHRoZSBkZXN0cnVjdCBjaGVjayB1bm5lY2Vz c2FyeQ0Kb25jZSB3ZSBnZXQgcGFzdCB0aGUgY2hlY2sgaW4gdGhlIGZpcnN0IGZ1bmN0aW9uIGlu IHRoZSBpbnRlcnJ1cHQgaGFuZGxlciBmb3INCnRoaXMgZHJpdmVyIC0gIHN0b3J2c2Nfb25fY2hh bm5lbF9jYWxsYmFjaygpLiANCkluIHRoZSBhYnNlbmNlIG9mIHRoaXMsIHRoZSBkZXN0cnVjdCBj aGVjayBpcyBtZWFuaW5nbGVzcyBzaW5jZSB0aGUgc3RhdGUgY2FuIA0KY2hhbmdlIHNvb24gYWZ0 ZXIgaXQgaGFzIGJlZW4gY2hlY2tlZC4gU28sIGlmIGl0IGlzIG9rIHdpdGggeW91LCBJIHdpbGwg YWRkIGFkZGl0aW9uYWwNCmNvbW1lbnQgdG8gdGhlIGNvbW1pdCBsb2cgYW5kIHJlc3VibWl0IHRo ZSBwYXRjaC4NCg0KUmVnYXJkcywNCg0KSy4gWSAgDQoNCg0K -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Hannes Reinecke <hare@suse.de> |
|---|---|
| Date | 2015-12-18 09:50 +0100 |
| Subject | Re: [PATCH V3 1/4] scsi: storvsc: Fix a bug in the layout of the hv_fc_wwn_packet |
| Message-ID | <qGYTE-3jm-27@gated-at.bofh.it> |
| In reply to | #1290674 |
On 12/13/2015 09:28 PM, K. Y. Srinivasan wrote:
> The hv_fc_wwn_packet is exchanged over vmbus. Make the definition in Linux match
> the Window's definition.
>
> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
> Reviewed-by: Long Li <longli@microsoft.com>
> Tested-by: Alex Ng <alexng@microsoft.com>
> ---
> drivers/scsi/storvsc_drv.c | 5 ++---
> 1 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> index c41f674..00bb4bd 100644
> --- a/drivers/scsi/storvsc_drv.c
> +++ b/drivers/scsi/storvsc_drv.c
> @@ -92,9 +92,8 @@ enum vstor_packet_operation {
> */
>
> struct hv_fc_wwn_packet {
> - bool primary_active;
> - u8 reserved1;
> - u8 reserved2;
> + u8 primary_active;
> + u8 reserved1[3];
> u8 primary_port_wwn[8];
> u8 primary_node_wwn[8];
> u8 secondary_port_wwn[8];
>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web