ult = -ENOMSG;
>>>> +bsg_reply = job->reply;
>>>> + bsg_reply->reply_payload_rcv_len = 0;
>>>> +bsg_reply->result = -ENOMSG;
>
> Compiler optimization re-ordered above two lines and the first pointer
> derefence i
ply = job->reply;
>>>> +bsg_reply->reply_payload_rcv_len = 0;
>>>> +bsg_reply->result = -ENOMSG;
>
> Compiler optimization re-ordered above two lines and the first pointer
> derefence is bsg_reply->result [field offset 0] where bsg_reply is NULL.
> The assignment tries to write to memory at address NULL causing the
> kernel page fault.
>
I spoke to our compiler people, and they strongly believed this not to
be the case. Or, put it the other way round, if such a thing would
happen it would be a compiler issue.
Have you checked the compiler output?
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@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)
On 10/27/2016 01:51 PM, Bjorn Helgaas wrote:
> On Thu, Oct 27, 2016 at 07:42:27AM +0200, Hannes Reinecke wrote:
>> On 10/26/2016 09:43 PM, Bjorn Helgaas wrote:
>>> Hi Johannes,
>>>
>>> On Wed, Oct 26, 2016 at 03:53:34PM +0200, Johannes Thumshirn wrote:
>&g
On 10/27/2016 01:51 PM, Bjorn Helgaas wrote:
> On Thu, Oct 27, 2016 at 07:42:27AM +0200, Hannes Reinecke wrote:
>> On 10/26/2016 09:43 PM, Bjorn Helgaas wrote:
>>> Hi Johannes,
>>>
>>> On Wed, Oct 26, 2016 at 03:53:34PM +0200, Johannes Thumshirn wrote:
>&g
ver"
> -#define MPT3SAS_DRIVER_VERSION "13.100.00.00"
> -#define MPT3SAS_MAJOR_VERSION13
> +#define MPT3SAS_DRIVER_VERSION "14.100.00.00"
> +#define MPT3SAS_MAJOR_VERSION14
> #define MPT3SAS_MINOR_VERSION
R_VERSION "14.100.00.00"
> +#define MPT3SAS_MAJOR_VERSION14
> #define MPT3SAS_MINOR_VERSION 100
> #define MPT3SAS_BUILD_VERSION 0
> #define MPT3SAS_RELEASE_VERSION 00
>
Rev
N101
> #define MPT3SAS_BUILD_VERSION 0
> #define MPT3SAS_RELEASE_VERSION 00
>
>
Reviewed-by: Hannes Reinecke <h...@suse.com>
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de
> drivers/scsi/mpt3sas/mpt3sas_base.c | 19 +++
> drivers/scsi/mpt3sas/mpt3sas_base.h | 5
> drivers/scsi/mpt3sas/mpt3sas_ctl.c | 46
> ++--
> drivers/scsi/mpt3sas/mpt3sas_scsih.c | 24 ++-
> 4 files changed, 86 insertions(+)
#define MPT3SAS_MAJOR_VERSION14
> -#define MPT3SAS_MINOR_VERSION100
> +#define MPT3SAS_MINOR_VERSION101
> #define MPT3SAS_BUILD_VERSION 0
> #define MPT3SAS_RELEASE_VERSION 00
>
>
rs/scsi/mpt3sas/mpt3sas_ctl.c | 46
> ++--
> drivers/scsi/mpt3sas/mpt3sas_scsih.c | 24 ++-
> 4 files changed, 86 insertions(+), 8 deletions(-)
>
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes Reinecke
se the _HPX method was causing the RCB for all PCI
devices to be set to 128 bytes, while the root bridge remained at 64 bytes.
While this is arguably a BIOS bug, earlier linux version (ie without the
mentioned patch) were running fine, so this is actually a regression.
Cheers,
Hannes
--
Dr. Hann
se the _HPX method was causing the RCB for all PCI
devices to be set to 128 bytes, while the root bridge remained at 64 bytes.
While this is arguably a BIOS bug, earlier linux version (ie without the
mentioned patch) were running fine, so this is actually a regression.
Cheers,
Hannes
--
Dr. Hann
d-off-by: Johannes Thumshirn <jthumsh...@suse.de>
> ---
> drivers/pci/probe.c | 26 --
> 1 file changed, 24 insertions(+), 2 deletions(-)
>
This fixes a regression where the mlx4 driver would not load (and, in
fact, crash) on certain Ivybridge servers.
Review
d-off-by: Johannes Thumshirn
> ---
> drivers/pci/probe.c | 26 --
> 1 file changed, 24 insertions(+), 2 deletions(-)
>
This fixes a regression where the mlx4 driver would not load (and, in
fact, crash) on certain Ivybridge servers.
Reviewed-by: Hannes Reinecke
ces you (might) increase the number of devices,
potentially overflowing the bitmap.
Hence the question: is it possible that you can add _more_ devices than
the bitmap can hold?
Or, to put it the other way round: Why don't you need to check the size
of the bitmap to avoid accessing an invalid b
ces you (might) increase the number of devices,
potentially overflowing the bitmap.
Hence the question: is it possible that you can add _more_ devices than
the bitmap can hold?
Or, to put it the other way round: Why don't you need to check the size
of the bitmap to avoid accessing an invalid b
et = AdvInitGetConfig(pdev, shost) ? -ENODEV : 0;
> +#else
> + share_irq = 0;
> + ret = -ENODEV;
> #endif /* CONFIG_PCI */
> }
>
>
Reviewed-by: Hannes Reinecke <h...@suse.com>
Cheers,
Hannes
--
Dr. Hannes Reinecke
shost) ? -ENODEV : 0;
> +#else
> + share_irq = 0;
> + ret = -ENODEV;
> #endif /* CONFIG_PCI */
> }
>
>
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes ReineckezSeries & Storage
h...@suse.com
ice_pg0.SASAddress);
sas_device_pg0.Slot = le16_to_cpu(sas_device_pg0.Slot);
+ sas_device_pg0.Flags = le16_to_cpu(sas_device_pg0.Flags);
_scsih_mark_responding_sas_device(ioc, _device_pg0);
}
Reviewed-by: Hannes Reinecke <h...@suse.com>
+ sas_device_pg0.Flags = le16_to_cpu(sas_device_pg0.Flags);
_scsih_mark_responding_sas_device(ioc, _device_pg0);
}
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74
_reply_index_count =
+MPT3_SUP_REPLY_POST_HOST_INDEX_REG_COUNT_G35;
+ else
+ ioc->combined_reply_index_count =
+ MPT3_SUP_REPLY_POST_HOST_INDEX_REG_COUNT_G3;
+ }
break
_EEDPFLAGS_APPTAG_DISABLE_MODE;
mpi_request->EEDPFlags = cpu_to_le16(eedp_flags);
}
Reviewed-by: Hannes Reinecke <h...@suse.com>
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74053 688
SUSE L
ioc->combined_reply_index_count =
+ MPT3_SUP_REPLY_POST_HOST_INDEX_REG_COUNT_G3;
+ }
break;
default:
return -ENODEV;
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes Reinecke
,
mpi_request_3v->EEDPBlockSize =
cpu_to_le16(scmd->device->sector_size);
+
+ if (ioc->is_gen35_ioc)
+ eedp_flags |= MPI25_SCSIIO_EEDPFLAGS_APPTAG_DISABLE_MODE;
mpi_request->EEDPFlags = cpu_to_le16(eedp_flags);
}
Reviewed-by: Hannes Re
_scsih.c | 24 +++---
drivers/scsi/mpt3sas/mpt3sas_transport.c | 8 +-
6 files changed, 161 insertions(+), 54 deletions(-)
Reviewed-by: Hannes Reinecke <h...@suse.com>
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de
deletions(-)
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmany
ID_SAS3516_1,
+ PCI_ANY_ID, PCI_ANY_ID },
+ { MPI2_MFGPAGE_VENDORID_LSI, MPI26_MFGPAGE_DEVID_SAS3416,
+ PCI_ANY_ID, PCI_ANY_ID },
{0} /* Terminating entry */
};
MODULE_DEVICE_TABLE(pci, mpt3sas_pci_table);
Reviewed-by: Hannes Reinecke <h...@suse.com>
PCI_ANY_ID, PCI_ANY_ID },
{0} /* Terminating entry */
};
MODULE_DEVICE_TABLE(pci, mpt3sas_pci_table);
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 7
/scsi/mpt3sas/mpt3sas_base.h
@@ -375,7 +375,6 @@ struct MPT3SAS_TARGET {
* per device private data
*/
#define MPT_DEVICE_FLAGS_INIT 0x01
-#define MPT_DEVICE_TLR_ON 0x02
#define MFG_PAGE10_HIDE_SSDS_MASK (0x0003)
#define MFG_PAGE10_HIDE_ALL_DISKS (0x00)
Rev
/
#define MPT_DEVICE_FLAGS_INIT 0x01
-#define MPT_DEVICE_TLR_ON 0x02
#define MFG_PAGE10_HIDE_SSDS_MASK (0x0003)
#define MFG_PAGE10_HIDE_ALL_DISKS (0x00)
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networkin
PT3SAS_MAJOR_VERSION 13
+#define MPT3SAS_DRIVER_VERSION "14.100.00.00"
+#define MPT3SAS_MAJOR_VERSION 14
#define MPT3SAS_MINOR_VERSION 100
#define MPT3SAS_BUILD_VERSION 0
#define MPT3SAS_RELEASE_VERSION00
Please move th
define MPT3SAS_MINOR_VERSION 100
#define MPT3SAS_BUILD_VERSION 0
#define MPT3SAS_RELEASE_VERSION00
Please move this to the end of the patch series.
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +
}
+ memset(ioc->pend_os_device_add, 0, ioc->pend_os_device_add_sz);
+ memset(ioc->device_remove_in_progress, 0,
+ ioc->device_remove_in_progress_sz);
_scsih_fw_event_cleanup_queue(ioc);
_scsih_flush_running_cmds(ioc);
break;
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@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)
TARG_ADDED:
@@ -7707,6 +7726,9 @@ mpt3sas_scsih_reset_handler(struct MPT3SAS_ADAPTER *ioc,
int reset_phase)
complete(>tm_cmds.done);
}
+ memset(ioc->pend_os_device_add, 0, ioc->pend_os_device_add_sz);
+ mem
else if (max_msix_vectors == 0)
+ } else if (local_max_msix_vectors == 0)
goto try_ioapic;
if (ioc->msix_vector_count < ioc->cpu_count)
Reviewed-by: Hannes Reinecke <h...@suse.com>
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead St
c;
if (ioc->msix_vector_count < ioc->cpu_count)
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F.
NNING);
if (r)
sdev_printk(KERN_WARNING, sdev, "retried device_unblock"
" failed with return(%d) for handle(0x%04x)\n",
- sas_device_priv_data->sas_target->handle, r);
+
retried device_unblock"
" failed with return(%d) for handle(0x%04x)\n",
- sas_device_priv_data->sas_target->handle, r);
+ r, sas_device_priv_data->sas_target->handle);
}
}
Reviewed-by: Hannes Reinecke
Cheers,
Hanne
0) {
Reviewed-by: Hannes Reinecke <h...@suse.com>
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild,
/* Do a report zone to get the same field */
ret = sd_zbc_report_zones(sdkp, buf, SD_ZBC_BUF_SIZE, 0);
- if (ret)
+ if (ret) {
+ zone_blocks = 0;
goto out;
+ }
same = buf[4] & 0x0f;
if (same > 0) {
Reviewed
On 10/18/2016 11:56 AM, Karel Zak wrote:
> On Mon, Oct 17, 2016 at 12:20:30PM +0200, Hannes Reinecke wrote:
>> The GPT specification requires that the alternate GPT is at the
>> end of the disk. However, if a Software RAID1 is enabled the RAID
>> metadata typically placed a
On 10/18/2016 11:56 AM, Karel Zak wrote:
> On Mon, Oct 17, 2016 at 12:20:30PM +0200, Hannes Reinecke wrote:
>> The GPT specification requires that the alternate GPT is at the
>> end of the disk. However, if a Software RAID1 is enabled the RAID
>> metadata typically placed a
it trying to out-guess what the compiler might be
doing during compilation. For which the easiest method is checking.
So back to the original task for you: Show me in the generated output
where the benefits are.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
h...@sus
it trying to out-guess what the compiler might be
doing during compilation. For which the easiest method is checking.
So back to the original task for you: Show me in the generated output
where the benefits are.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
h...@sus
.
In this particular case: hardly.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
.
In this particular case: hardly.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
t; Thanks for this detail.
>
> * Did you choose any special optimisation settings for your quick check?
>
> * Will any compilation results matter if "optimisation" would be
> switched off there?
>
>
These were the results when calling 'make' in the kernel source tree.
t; Thanks for this detail.
>
> * Did you choose any special optimisation settings for your quick check?
>
> * Will any compilation results matter if "optimisation" would be
> switched off there?
>
>
These were the results when calling 'make' in the kernel source tree.
to reconsider
> implementation details from three status functions?
>
No.
But we're waiting for you showing is that it is an improvement.
Which at the moment we don't see.
Hence we're waiting from a proof or validation from your side.
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Sto
to reconsider
> implementation details from three status functions?
>
No.
But we're waiting for you showing is that it is an improvement.
Which at the moment we don't see.
Hence we're waiting from a proof or validation from your side.
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Sto
a partition table which is
_smaller_ than the device; eg we don't check for the device
size in the msdos partition, neither.
So don't print out a warning here.
Signed-off-by: Hannes Reinecke <h...@suse.com>
---
block/partitions/efi.c | 15 ---
1 file changed, 15 deletions(-)
diff --git a
a partition table which is
_smaller_ than the device; eg we don't check for the device
size in the msdos partition, neither.
So don't print out a warning here.
Signed-off-by: Hannes Reinecke
---
block/partitions/efi.c | 15 ---
1 file changed, 15 deletions(-)
diff --git a/block/partitions
c, but with one instruction _more_
>> after your patch has been applied.
>
> Which software versions and command parameters did you try out
> for this information (from an unspecified run time environment)?
>
>
# gcc --version
gcc (SUSE Linux) 4.8.5
Copyright (C) 2015 Free Software Foundatio
c, but with one instruction _more_
>> after your patch has been applied.
>
> Which software versions and command parameters did you try out
> for this information (from an unspecified run time environment)?
>
>
# gcc --version
gcc (SUSE Linux) 4.8.5
Copyright (C) 2015 Free Software Foundatio
?
>
Because it's being called at the end of a function calling seq_printf()
already. So exchanging a single call is probably not helping anything,
as the compiler will optimize it anyway.
Case in point: with your patch the x86_64 compiler generates nearly
identical code for driver/md/raid1.c, bu
?
>
Because it's being called at the end of a function calling seq_printf()
already. So exchanging a single call is probably not helping anything,
as the compiler will optimize it anyway.
Case in point: with your patch the x86_64 compiler generates nearly
identical code for driver/md/raid1.c, bu
t the answer is 'yes' to the above two
questions) the patch will be applied.
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@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)
t the answer is 'yes' to the above two
questions) the patch will be applied.
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@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)
seq_file *seq, struct
mddev *mddev)
seq_printf (seq, "%s", rdev && test_bit(In_sync, >flags) ? "U" :
"_");
}
rcu_read_unlock();
- seq_printf (seq, "]");
+ seq_putc(seq, ']');
}
static void pri
;, rdev && test_bit(In_sync, >flags) ? "U" :
"_");
}
rcu_read_unlock();
- seq_printf (seq, "]");
+ seq_putc(seq, ']');
}
static void print_raid5_conf (struct r5conf *conf)
The point of this patch being ... what?
Does it impr
On 10/14/2016 08:35 PM, Adam Manzananares wrote:
The 10/14/2016 07:54, Hannes Reinecke wrote:
On 10/13/2016 09:53 PM, Adam Manzanares wrote:
Patch adds an association between iocontext ioprio and the ioprio of a
request. This value is set in blk_rq_set_prio which takes the request and
the ioc
On 10/14/2016 08:35 PM, Adam Manzananares wrote:
The 10/14/2016 07:54, Hannes Reinecke wrote:
On 10/13/2016 09:53 PM, Adam Manzanares wrote:
Patch adds an association between iocontext ioprio and the ioprio of a
request. This value is set in blk_rq_set_prio which takes the request and
the ioc
!(SCpnt->request->ioprio & 0x7))
> - scsictl |= MPI_SCSIIO_CONTROL_HEADOFQ;
> - }
> } else
> scsictl = scsidir | MPI_SCSIIO_CONTROL_UNTAGGED;
>
>
Reviewed-by: Hannes Reinecke <h...@suse.com>
->ioprio & 0x7))
> - scsictl |= MPI_SCSIIO_CONTROL_HEADOFQ;
> - }
> } else
> scsictl = scsidir | MPI_SCSIIO_CONTROL_UNTAGGED;
>
>
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes Reinecke
age priority information.
> + */
> +static inline void blk_rq_set_prio(struct request *rq, struct io_context
> *ioc)
> +{
> + if (ioc)
> + rq->ioprio = ioc->ioprio;
> +}
> +
> +/*
> * Request issue related functions.
> */
> e
> +static inline void blk_rq_set_prio(struct request *rq, struct io_context
> *ioc)
> +{
> + if (ioc)
> + rq->ioprio = ioc->ioprio;
> +}
> +
> +/*
> * Request issue related functions.
> */
> extern struct request *blk_peek_request(struct re
-
> drivers/scsi/qla2xxx/qla_bsg.c | 66 +-
> drivers/scsi/scsi_transport_fc.c | 22 +++--
> include/scsi/scsi_transport_fc.h | 3 +-
> 8 files changed, 116 insertions(+), 60 deletions(-)
>
Reviewed-by: Hannes Reinecke <h...@suse.com>
drivers/scsi/qla2xxx/qla_bsg.c | 66 +-
> drivers/scsi/scsi_transport_fc.c | 22 +++--
> include/scsi/scsi_transport_fc.h | 3 +-
> 8 files changed, 116 insertions(+), 60 deletions(-)
>
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes Reinecke
gt; drivers/scsi/qla2xxx/qla_bsg.c | 54
>
> drivers/scsi/scsi_transport_fc.c | 2 +-
> include/scsi/scsi_transport_fc.h | 5
> 8 files changed, 56 insertions(+), 53 deletions(-)
>
Reviewed-by: Hannes Reinecke <h...@suse.com>
Cheers,
Hannes
--
D
rivers/scsi/qla2xxx/qla_bsg.c | 54
>
> drivers/scsi/scsi_transport_fc.c | 2 +-
> include/scsi/scsi_transport_fc.h | 5
> 8 files changed, 56 insertions(+), 53 deletions(-)
>
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes Reinecke
> drivers/scsi/scsi_transport_fc.c | 287
> ++-
> 2 files changed, 44 insertions(+), 244 deletions(-)
>
Reviewed-by: Hannes Reinecke <h...@suse.com>
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de
drivers/scsi/scsi_transport_fc.c | 287
> ++-
> 2 files changed, 44 insertions(+), 244 deletions(-)
>
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74053 688
bsg_job_fn *job_fn, int dd_job_size);
> void bsg_request_fn(struct request_queue *q);
> -void bsg_softirq_done(struct request *rq);
> void bsg_job_put(struct bsg_job *job);
> int __must_check bsg_job_get(struct bsg_job *job);
>
>
Revie
fn, int dd_job_size);
> void bsg_request_fn(struct request_queue *q);
> -void bsg_softirq_done(struct request *rq);
> void bsg_job_put(struct bsg_job *job);
> int __must_check bsg_job_get(struct bsg_job *job);
>
>
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes Re
| 3 ++-
> drivers/scsi/scsi_transport_fc.c | 16 ++--
> include/linux/bsg-lib.h | 1 +
> 3 files changed, 5 insertions(+), 15 deletions(-)
>
Reviewed-by: Hannes Reinecke <h...@suse.com>
Cheers,
Hannes
--
Dr. Hannes Reinecke
i_transport_fc.c | 16 ++--
> include/linux/bsg-lib.h | 1 +
> 3 files changed, 5 insertions(+), 15 deletions(-)
>
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de
+---
> drivers/scsi/scsi_transport_fc.c | 4 ++--
> include/linux/bsg-lib.h | 3 ++-
> 3 files changed, 18 insertions(+), 6 deletions(-)
>
Reviewed-by: Hannes Reinecke <h...@suse.com>
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...
++
> drivers/scsi/scsi_transport_fc.c | 41 +++--
> include/scsi/scsi_transport_fc.h | 2 --
> 8 files changed, 50 insertions(+), 87 deletions(-)
>
Reviewed-by: Hannes Reinecke <h...@suse.com>
Cheers,
Hannes
--
Dr. Ha
i_transport_fc.c | 4 ++--
> include/linux/bsg-lib.h | 3 ++-
> 3 files changed, 18 insertions(+), 6 deletions(-)
>
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de
> drivers/scsi/scsi_transport_fc.c | 41 +++--
> include/scsi/scsi_transport_fc.h | 2 --
> 8 files changed, 50 insertions(+), 87 deletions(-)
>
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes Reinecke
si/scsi_transport_fc.c | 20 ++--
> include/linux/bsg-lib.h | 1 +
> 3 files changed, 5 insertions(+), 19 deletions(-)
>
Reviewed-by: Hannes Reinecke <h...@suse.com>
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de
--
> include/linux/bsg-lib.h | 1 +
> 3 files changed, 5 insertions(+), 19 deletions(-)
>
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74053
+++----
> 17 files changed, 138 insertions(+), 163 deletions(-)
>
Reviewed-by: Hannes Reinecke <h...@suse.com>
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74053 6
---
> 17 files changed, 138 insertions(+), 163 deletions(-)
>
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürn
}
>
> /**
Hmm. blk_end_request_all() (potentially) triggers a recursion into all
.end_io callbacks, which might end up doing god-knows-what.
With some delays in doing so
During that time we have no idea that bsg_softirq_done() is actually
running, and we might clash with eg. timeouts
ck/bsg-lib.c | 7 +--
> include/linux/bsg-lib.h | 2 ++
> 2 files changed, 7 insertions(+), 2 deletions(-)
>
Reviewed-by: Hannes Reinecke <h...@suse.com>
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de
/**
Hmm. blk_end_request_all() (potentially) triggers a recursion into all
.end_io callbacks, which might end up doing god-knows-what.
With some delays in doing so
During that time we have no idea that bsg_softirq_done() is actually
running, and we might clash with eg. timeouts or somesuch.
t; include/linux/bsg-lib.h | 2 ++
> 2 files changed, 7 insertions(+), 2 deletions(-)
>
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH, M
= 0;
> - job->state_flags |= FC_RQST_STATE_DONE;
> fc_bsg_jobdone(job, bsg_reply->result,
> bsg_reply->reply_payload_rcv_len);
> kfree(info);
>
Reviewed-by: Hannes Reinecke <h...@suse.com>
Cheers,
Hannes
--
Dr. Hannes Reinecke
C_RQST_STATE_DONE;
> fc_bsg_jobdone(job, bsg_reply->result,
> bsg_reply->reply_payload_rcv_len);
> kfree(info);
>
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networki
+-
> include/scsi/scsi_transport_fc.h | 5 +
> 7 files changed, 17 insertions(+), 10 deletions(-)
>
Reviewed-by: Hannes Reinecke <h...@suse.com>
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de
csi_transport_fc.h | 5 +
> 7 files changed, 17 insertions(+), 10 deletions(-)
>
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH, Ma
2 +-
> 8 files changed, 50 insertions(+), 51 deletions(-)
>
Reviewed-by: Hannes Reinecke <h...@suse.com>
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5
insertions(+), 51 deletions(-)
>
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@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)
les changed, 387 insertions(+), 263 deletions(-)
>
Reviewed-by: Hannes Reinecke <h...@suse.com>
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürn
ivers/scsi/qla2xxx/qla_bsg.c | 264
> ++-
> drivers/scsi/qla2xxx/qla_iocb.c | 5 +-
> drivers/scsi/qla2xxx/qla_isr.c | 46 ---
> drivers/scsi/qla2xxx/qla_mr.c| 10 +-
> drivers/scsi/scsi_transport_fc.c | 37 +++---
> 10 files changed, 387 insertion
rs/scsi/scsi_transport_fc.c | 2 +-
> include/scsi/scsi_transport_fc.h | 12 +++-
> 3 files changed, 6 insertions(+), 11 deletions(-)
>
Reviewed-by: Hannes Reinecke <h...@suse.com>
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...
.c | 2 +-
> include/scsi/scsi_transport_fc.h | 12 +++-
> 3 files changed, 6 insertions(+), 11 deletions(-)
>
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de
of patches by quite a bit.
Cheers,
Hannes
--
Dr. Hannes ReineckezSeries & Storage
h...@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 2
of patches by quite a bit.
Cheers,
Hannes
--
Dr. Hannes ReineckezSeries & Storage
h...@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 2
501 - 600 of 1903 matches
Mail list logo
