.
(And we have disabled the IDE drivers since SLES11, where we still
support Itanium.)
So they can be safely assumed defunct at this time.
I'm all for removing them.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
h...@suse.de +49 911 74053
.
(And we have disabled the IDE drivers since SLES11, where we still
support Itanium.)
So they can be safely assumed defunct at this time.
I'm all for removing them.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
h...@suse.de +49 911 74053
On 01/31/2017 01:31 AM, Bart Van Assche wrote:
> On Wed, 2017-01-18 at 10:48 +0100, Hannes Reinecke wrote:
>> @@ -1488,26 +1487,13 @@ static unsigned long disk_events_poll_jiffies(struct
>> gendisk *disk)
>> void disk_block_events(struct gendisk *disk)
>> {
>&g
On 01/31/2017 01:31 AM, Bart Van Assche wrote:
> On Wed, 2017-01-18 at 10:48 +0100, Hannes Reinecke wrote:
>> @@ -1488,26 +1487,13 @@ static unsigned long disk_events_poll_jiffies(struct
>> gendisk *disk)
>> void disk_block_events(struct gendisk *disk)
>> {
>&g
; include/linux/blkdev.h |1 +
> include/linux/genhd.h | 17 +
> 5 files changed, 59 insertions(+), 8 deletions(-)
>
Please check the patchset from Jan Kara (cf 'BDI lifetime fix' on
linux-block), which attempts to solve the same problem.
Cheers,
Hannes
--
Dr.
+++
> drivers/scsi/sd.c | 41 +
> include/linux/blkdev.h |1 +
> include/linux/genhd.h | 17 +
> 5 files changed, 59 insertions(+), 8 deletions(-)
>
Please check the patchset from Jan Kara (cf 'BDI lifet
[ 989.716542] SyS_open+0x1e/0x20
[ 989.716546] entry_SYSCALL_64_fastpath+0x23/0xc6
Signed-off-by: Hannes Reinecke <h...@suse.com>
diff --git a/block/genhd.c b/block/genhd.c
index fcd6d4f..ae46caa 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -1426,8 +1426,7 @@ struct disk_events {
[ 989.716542] SyS_open+0x1e/0x20
[ 989.716546] entry_SYSCALL_64_fastpath+0x23/0xc6
Signed-off-by: Hannes Reinecke
diff --git a/block/genhd.c b/block/genhd.c
index fcd6d4f..ae46caa 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -1426,8 +1426,7 @@ struct disk_events {
struct gendisk
nous LUN remapping?
And we really should make sure to have a single FC host in the guest
presenting all LUNs.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nü
nous LUN remapping?
And we really should make sure to have a single FC host in the guest
presenting all LUNs.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nü
On 01/13/2017 05:02 PM, Jens Axboe wrote:
> On 01/13/2017 09:00 AM, Jens Axboe wrote:
>> On 01/13/2017 08:59 AM, Hannes Reinecke wrote:
>>> On 01/13/2017 04:34 PM, Jens Axboe wrote:
>>>> On 01/13/2017 08:33 AM, Hannes Reinecke wrote:
>>> [ .. ]
>>>&g
On 01/13/2017 05:02 PM, Jens Axboe wrote:
> On 01/13/2017 09:00 AM, Jens Axboe wrote:
>> On 01/13/2017 08:59 AM, Hannes Reinecke wrote:
>>> On 01/13/2017 04:34 PM, Jens Axboe wrote:
>>>> On 01/13/2017 08:33 AM, Hannes Reinecke wrote:
>>> [ .. ]
>>>&g
On 01/13/2017 05:41 PM, Omar Sandoval wrote:
> On Fri, Jan 13, 2017 at 12:15:17PM +0100, Hannes Reinecke wrote:
>> On 01/11/2017 10:40 PM, Jens Axboe wrote:
>>> This adds a set of hooks that intercepts the blk-mq path of
>>> allocating/inserting/issuing/completin
On 01/13/2017 05:41 PM, Omar Sandoval wrote:
> On Fri, Jan 13, 2017 at 12:15:17PM +0100, Hannes Reinecke wrote:
>> On 01/11/2017 10:40 PM, Jens Axboe wrote:
>>> This adds a set of hooks that intercepts the blk-mq path of
>>> allocating/inserting/issuing/completin
On 01/13/2017 04:34 PM, Jens Axboe wrote:
> On 01/13/2017 08:33 AM, Hannes Reinecke wrote:
[ .. ]
>> Ah, indeed.
>> There is an ominous udev rule here, trying to switch to 'deadline'.
>>
>> # cat 60-ssd-scheduler.rules
>> # do not edit this file, it will be overwri
On 01/13/2017 04:34 PM, Jens Axboe wrote:
> On 01/13/2017 08:33 AM, Hannes Reinecke wrote:
[ .. ]
>> Ah, indeed.
>> There is an ominous udev rule here, trying to switch to 'deadline'.
>>
>> # cat 60-ssd-scheduler.rules
>> # do not edit this file, it will be overwri
On 01/13/2017 04:23 PM, Jens Axboe wrote:
> On 01/13/2017 04:04 AM, Hannes Reinecke wrote:
>> On 01/13/2017 09:15 AM, Hannes Reinecke wrote:
>>> On 01/11/2017 10:39 PM, Jens Axboe wrote:
>>>> Another year, another posting of this patchset. The previous posting
On 01/13/2017 04:23 PM, Jens Axboe wrote:
> On 01/13/2017 04:04 AM, Hannes Reinecke wrote:
>> On 01/13/2017 09:15 AM, Hannes Reinecke wrote:
>>> On 01/11/2017 10:39 PM, Jens Axboe wrote:
>>>> Another year, another posting of this patchset. The previous posting
On 01/13/2017 12:04 PM, Hannes Reinecke wrote:
> On 01/13/2017 09:15 AM, Hannes Reinecke wrote:
>> On 01/11/2017 10:39 PM, Jens Axboe wrote:
>>> Another year, another posting of this patchset. The previous posting
>>> was here:
>>>
>>> https:/
On 01/13/2017 12:04 PM, Hannes Reinecke wrote:
> On 01/13/2017 09:15 AM, Hannes Reinecke wrote:
>> On 01/11/2017 10:39 PM, Jens Axboe wrote:
>>> Another year, another posting of this patchset. The previous posting
>>> was here:
>>>
>>> https:/
Surely there is one already, right?
Things like '->init_request' assume a fully populated array, so moving
one entry to another location is ... interesting.
I would have thought we need to do a request cloning here,
otherwise this would introduce a memory leak, right?
(Not to m
ready, right?
Things like '->init_request' assume a fully populated array, so moving
one entry to another location is ... interesting.
I would have thought we need to do a request cloning here,
otherwise this would introduce a memory leak, right?
(Not to mention
On 01/13/2017 09:15 AM, Hannes Reinecke wrote:
> On 01/11/2017 10:39 PM, Jens Axboe wrote:
>> Another year, another posting of this patchset. The previous posting
>> was here:
>>
>> https://www.spinics.net/lists/kernel/msg2406106.html
>>
>> (yes, I'v
On 01/13/2017 09:15 AM, Hannes Reinecke wrote:
> On 01/11/2017 10:39 PM, Jens Axboe wrote:
>> Another year, another posting of this patchset. The previous posting
>> was here:
>>
>> https://www.spinics.net/lists/kernel/msg2406106.html
>>
>> (yes, I'v
8.987716] async_port_probe+0x43/0x60 [libata]
[ 28.987718] async_run_entry_fn+0x37/0x150
[ 28.987722] process_one_work+0x1d0/0x660
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH,
8.987716] async_port_probe+0x43/0x60 [libata]
[ 28.987718] async_run_entry_fn+0x37/0x150
[ 28.987722] process_one_work+0x1d0/0x660
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH,
port_opcode+0xab/0x100
checking ...
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)
port_opcode+0xab/0x100
checking ...
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)
want to
head to; I might be able to work on this start of January.
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,
want to
head to; I might be able to work on this start of January.
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,
_might_ end up
with a residual smaller than the physical sector size.
But that should be handled by firmware; after all, that's what the 'e'
implies, right?
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911
_might_ end up
with a residual smaller than the physical sector size.
But that should be handled by firmware; after all, that's what the 'e'
implies, right?
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911
l(>queuelist, >queue_head);
return;
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
queuelist, >queue_head);
return;
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. Smit
files changed, 48 insertions(+), 38 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, 9040
insertions(+), 38 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. G
On 12/08/2016 09:13 PM, Jens Axboe wrote:
Signed-off-by: Jens Axboe <ax...@fb.com>
---
block/elevator.c | 8
include/linux/elevator.h | 5 +
2 files changed, 9 insertions(+), 4 deletions(-)
Reviewed-by: Hannes Reinecke <h...@suse.com>
Cheers,
Hannes
-
On 12/08/2016 09:13 PM, Jens Axboe wrote:
Signed-off-by: Jens Axboe
---
block/elevator.c | 8
include/linux/elevator.h | 5 +
2 files changed, 9 insertions(+), 4 deletions(-)
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead
was not to prefer a longer T10 to a NAA identifier.
Cheers,
Hannes
--
Dr. Hannes ReineckezSeries & Storage
h...@suse.com +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
was not to prefer a longer T10 to a NAA identifier.
Cheers,
Hannes
--
Dr. Hannes ReineckezSeries & Storage
h...@suse.com +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
vers/scsi/hpsa.c
@@ -2031,7 +2031,7 @@ static struct hpsa_scsi_dev_t
*lookup_hpsa_scsi_dev(struct ctlr_info *h,
static int hpsa_slave_alloc(struct scsi_device *sdev)
{
- struct hpsa_scsi_dev_t *sd;
+ struct hpsa_scsi_dev_t *sd = NULL;
unsigned long flags;
struct ctlr_info *h;
1,7 +2031,7 @@ static struct hpsa_scsi_dev_t
*lookup_hpsa_scsi_dev(struct ctlr_info *h,
static int hpsa_slave_alloc(struct scsi_device *sdev)
{
- struct hpsa_scsi_dev_t *sd;
+ struct hpsa_scsi_dev_t *sd = NULL;
unsigned long flags;
struct ctlr_info *h;
Cheers,
Hannes
--
o while the FAILFAST flag is a mere convenience for SCSI, it's a
positive must for S/390 if you want to have a functional RAID.
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74053 688
SUSE LINUX Gm
o while the FAILFAST flag is a mere convenience for SCSI, it's a
positive must for S/390 if you want to have a functional RAID.
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74053 688
SUSE LINUX Gm
'struct fc_bsg_job' and 'struct bsg_job'.
>
> Signed-off-by: Johannes Thumshirn <jthumsh...@suse.de>
> ---
> drivers/scsi/scsi_transport_fc.c | 40
> +++-
> include/scsi/scsi_transport_fc.h | 4 +---
> 2 files changed, 12 insertions(+), 32
'struct fc_bsg_job' and 'struct bsg_job'.
>
> Signed-off-by: Johannes Thumshirn
> ---
> drivers/scsi/scsi_transport_fc.c | 40
> +++-
> include/scsi/scsi_transport_fc.h | 4 +---
> 2 files changed, 12 insertions(+), 32 deletions(-)
>
Revi
physicals + nlogicals;
>
> So the first logical volume gets BTL 0:0:0 and then we attempt to add in
> the controller
> using the same BTL values at the end of the list. Thus you get the
> "device not added" messages.
>
> The change to bus 0 was because the SA
physicals + nlogicals;
>
> So the first logical volume gets BTL 0:0:0 and then we attempt to add in
> the controller
> using the same BTL values at the end of the list. Thus you get the
> "device not added" messages.
>
> The change to bus 0 was because the SA
changed, 31 insertions(+), 25 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ürnberg
(-)
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 2
it through struct
irq_affinity.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/pci/msi.c | 8
include/linux/interrupt.h | 4 ++--
kernel/irq/affinity.c | 24 ++--
3 files changed, 16 insertions(+), 20 deletions(-)
Reviewed-by: Hannes Reine
it through struct
irq_affinity.
Signed-off-by: Christoph Hellwig
---
drivers/pci/msi.c | 8
include/linux/interrupt.h | 4 ++--
kernel/irq/affinity.c | 24 ++--
3 files changed, 16 insertions(+), 20 deletions(-)
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
On 11/08/2016 04:11 PM, Christoph Hellwig wrote:
On Tue, Nov 08, 2016 at 04:08:51PM +0100, Hannes Reinecke wrote:
The use-case here is that one needs to feed the MSI-X index into the driver
command structure. While we can extract that number trivially with scsi-mq,
but for scsi-sq we don't have
On 11/08/2016 04:11 PM, Christoph Hellwig wrote:
On Tue, Nov 08, 2016 at 04:08:51PM +0100, Hannes Reinecke wrote:
The use-case here is that one needs to feed the MSI-X index into the driver
command structure. While we can extract that number trivially with scsi-mq,
but for scsi-sq we don't have
On 11/08/2016 03:56 PM, Christoph Hellwig wrote:
On Tue, Nov 08, 2016 at 08:47:21AM +0100, Hannes Reinecke wrote:
Add a reverse-mapping function to return the interrupt vector for
any CPU if interrupt affinity is enabled.
What's the use case of it?
Also as-is this won't work due to the non
On 11/08/2016 03:56 PM, Christoph Hellwig wrote:
On Tue, Nov 08, 2016 at 08:47:21AM +0100, Hannes Reinecke wrote:
Add a reverse-mapping function to return the interrupt vector for
any CPU if interrupt affinity is enabled.
What's the use case of it?
Also as-is this won't work due to the non
On 11/08/2016 03:55 PM, Christoph Hellwig wrote:
[please trim the f***king context in your replies, thanks..]
On Tue, Nov 08, 2016 at 09:15:27AM +0100, Hannes Reinecke wrote:
+irq_create_affinity_masks(int nvecs, const struct irq_affinity *affd)
{
- int n, nodes, vecs_per_node
On 11/08/2016 03:55 PM, Christoph Hellwig wrote:
[please trim the f***king context in your replies, thanks..]
On Tue, Nov 08, 2016 at 09:15:27AM +0100, Hannes Reinecke wrote:
+irq_create_affinity_masks(int nvecs, const struct irq_affinity *affd)
{
- int n, nodes, vecs_per_node
source[DEVICE_COUNT_RESOURCE]; /* I/O and memory
regions + expansion ROMs */
bool match_driver; /* Skip attaching driver */
Reviewed-by: Hannes Reinecke <h...@suse.com>
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Network
[DEVICE_COUNT_RESOURCE]; /* I/O and memory
regions + expansion ROMs */
bool match_driver; /* Skip attaching driver */
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 7
x/pci.h | 24 +++-
2 files changed, 32 insertions(+), 12 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
, 32 insertions(+), 12 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. Smithar
i/msi.c | 62 +--
1 file changed, 33 insertions(+), 29 deletions(-)
Reviewed-by: Hannes Reinecke <h...@suse.com>
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74053 688
SUSE LIN
file changed, 33 insertions(+), 29 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örffe
nodemask_t nodemsk = NODE_MASK_NONE;
struct cpumask *masks;
cpumask_var_t nmsk;
Check for NULL affd?
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH, Max
ASK_NONE;
struct cpumask *masks;
cpumask_var_t nmsk;
Check for NULL affd?
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. I
onst struct irq_affinity *affd)
{
- int cpus, ret;
+ int resv = affd->pre_vectors + affd->post_vectors;
+ int vecs = maxvec - resv;
+ int cpus;
Shouldn't you check for NULL affd here?
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Sto
- int cpus, ret;
+ int resv = affd->pre_vectors + affd->post_vectors;
+ int vecs = maxvec - resv;
+ int cpus;
Shouldn't you check for NULL affd here?
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de
post_vectors;
+};
+
#if defined(CONFIG_SMP)
extern cpumask_var_t irq_default_affinity;
Reviewed-by: Hannes Reinecke <h...@suse.com>
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74053 688
SUSE LIN
)
extern cpumask_var_t irq_default_affinity;
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örffe
Add a reverse-mapping function to return the interrupt vector for
any CPU if interrupt affinity is enabled.
Signed-off-by: Hannes Reinecke <h...@suse.com>
---
drivers/pci/msi.c | 36
include/linux/pci.h | 1 +
2 files changed, 37 insertions(+)
diff
Add a reverse-mapping function to return the interrupt vector for
any CPU if interrupt affinity is enabled.
Signed-off-by: Hannes Reinecke
---
drivers/pci/msi.c | 36
include/linux/pci.h | 1 +
2 files changed, 37 insertions(+)
diff --git a/drivers/pci
vers/nvme/host/pci.c| 2 +-
> include/linux/blk-mq-pci.h | 3 ++-
> 3 files changed, 7 insertions(+), 4 deletions(-)
>
With this patch smartpqi doesn't compile anymore; it still uses the old
interface.
So to get this merged you probably should send a patch for that one, too.
Che
> include/linux/blk-mq-pci.h | 3 ++-
> 3 files changed, 7 insertions(+), 4 deletions(-)
>
With this patch smartpqi doesn't compile anymore; it still uses the old
interface.
So to get this merged you probably should send a patch for that one, too.
Cheers,
Hannes
--
Dr. Hannes Reinecke
vers/nvme/host/pci.c| 2 +-
> include/linux/blk-mq-pci.h | 3 ++-
> 3 files changed, 7 insertions(+), 4 deletions(-)
>
Reviewed-by: Hannes Reinecke <h...@suse.com>
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de
> include/linux/blk-mq-pci.h | 3 ++-
> 3 files changed, 7 insertions(+), 4 deletions(-)
>
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74053 688
SUSE LINUX G
| 65
> ---
> 4 files changed, 98 insertions(+), 68 deletions(-)
>
Good idea.
Reviewed-by: Hannes Reinecke <h...@suse.com>
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de
---
> 4 files changed, 98 insertions(+), 68 deletions(-)
>
Good idea.
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74053 688
SU
blocksize.
Signed-off-by: Hannes Reinecke <h...@suse.com>
---
drivers/block/loop.c | 36 +++-
drivers/block/loop.h | 1 +
include/uapi/linux/loop.h | 1 +
3 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/drivers/block/loop.c b/d
blocksize.
Signed-off-by: Hannes Reinecke
---
drivers/block/loop.c | 36 +++-
drivers/block/loop.h | 1 +
include/uapi/linux/loop.h | 1 +
3 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index
.
Changes to v1:
- Move LO_FLAGS_BLOCKSIZE definition
- Reshuffle patches
Changes to v2:
- Include reviews from Ming Lei
Changes to v3:
- Include reviews from Christoph
- Merge patches
Hannes Reinecke (2):
loop: Remove unused 'bdev' argument from loop_set_capacity
loop: support 4k physical blocksize
Signed-off-by: Hannes Reinecke <h...@suse.de>
Reviewed-by: Christoph Hellwig <h...@lst.de>
Reviewed-by: Ming Lei <tom.leim...@gmail.com>
---
drivers/block/loop.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/block/loop.c b/drivers/block/lo
.
Changes to v1:
- Move LO_FLAGS_BLOCKSIZE definition
- Reshuffle patches
Changes to v2:
- Include reviews from Ming Lei
Changes to v3:
- Include reviews from Christoph
- Merge patches
Hannes Reinecke (2):
loop: Remove unused 'bdev' argument from loop_set_capacity
loop: support 4k physical blocksize
Signed-off-by: Hannes Reinecke
Reviewed-by: Christoph Hellwig
Reviewed-by: Ming Lei
---
drivers/block/loop.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index fa1b7a9..3008dec 100644
--- a/drivers/block/loop.c
+++ b
On 11/01/2016 03:02 PM, Christoph Hellwig wrote:
On Mon, Oct 31, 2016 at 08:37:19PM +0100, Hannes Reinecke wrote:
The current LOOP_SET_STATUS64 ioctl has two unused fields
'init[2]', which can be used in conjunction with the
LO_FLAGS_BLOCKSIZE flag to pass in the new logical blocksize.
Can we
On 11/01/2016 03:02 PM, Christoph Hellwig wrote:
On Mon, Oct 31, 2016 at 08:37:19PM +0100, Hannes Reinecke wrote:
The current LOOP_SET_STATUS64 ioctl has two unused fields
'init[2]', which can be used in conjunction with the
LO_FLAGS_BLOCKSIZE flag to pass in the new logical blocksize.
Can we
On 11/01/2016 03:02 PM, Christoph Hellwig wrote:
On Mon, Oct 31, 2016 at 08:37:19PM +0100, Hannes Reinecke wrote:
The current LOOP_SET_STATUS64 ioctl has two unused fields
'init[2]', which can be used in conjunction with the
LO_FLAGS_BLOCKSIZE flag to pass in the new logical blocksize.
Can we
On 11/01/2016 03:02 PM, Christoph Hellwig wrote:
On Mon, Oct 31, 2016 at 08:37:19PM +0100, Hannes Reinecke wrote:
The current LOOP_SET_STATUS64 ioctl has two unused fields
'init[2]', which can be used in conjunction with the
LO_FLAGS_BLOCKSIZE flag to pass in the new logical blocksize.
Can we
On 11/01/2016 03:01 PM, Christoph Hellwig wrote:
On Mon, Oct 31, 2016 at 08:37:18PM +0100, Hannes Reinecke wrote:
Add a new field 'lo_logical_blocksize' to hold the logical
blocksize of the loop device.
Why do we use the same flag for both block sizes? If there is a good
reason
On 11/01/2016 03:01 PM, Christoph Hellwig wrote:
On Mon, Oct 31, 2016 at 08:37:18PM +0100, Hannes Reinecke wrote:
Add a new field 'lo_logical_blocksize' to hold the logical
blocksize of the loop device.
Why do we use the same flag for both block sizes? If there is a good
reason
The current LOOP_SET_STATUS64 ioctl has two unused fields
'init[2]', which can be used in conjunction with the
LO_FLAGS_BLOCKSIZE flag to pass in the new logical blocksize.
Signed-off-by: Hannes Reinecke <h...@suse.de>
---
drivers/block/loop.c | 24 +++-
1 file chang
The current LOOP_SET_STATUS64 ioctl has two unused fields
'init[2]', which can be used in conjunction with the
LO_FLAGS_BLOCKSIZE flag to pass in the new logical blocksize.
Signed-off-by: Hannes Reinecke
---
drivers/block/loop.c | 24 +++-
1 file changed, 19 insertions(+), 5
patches
Changes to v2:
- Include reviews from Ming Lei
Hannes Reinecke (4):
loop: Remove unused 'bdev' argument from loop_set_capacity
loop: Enable correct physical blocksize
loop: Add 'lo_logical_blocksize'
loop: Pass logical blocksize in 'lo_init[0]' ioctl field
drivers/block/loop.c
Signed-off-by: Hannes Reinecke <h...@suse.de>
Reviewed-by: Christoph Hellwig <h...@lst.de>
---
drivers/block/loop.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index fa1b7a9..3008dec 100644
--- a/drivers/block/
When running on files the physical blocksize is actually 4k,
so we should be announcing it as such. This is enabled with
a new LO_FLAGS_BLOCKSIZE flag value to the existing
loop_set_status ioctl.
Signed-off-by: Hannes Reinecke <h...@suse.de>
---
drivers/block/loop.c | 9 -
i
patches
Changes to v2:
- Include reviews from Ming Lei
Hannes Reinecke (4):
loop: Remove unused 'bdev' argument from loop_set_capacity
loop: Enable correct physical blocksize
loop: Add 'lo_logical_blocksize'
loop: Pass logical blocksize in 'lo_init[0]' ioctl field
drivers/block/loop.c
Signed-off-by: Hannes Reinecke
Reviewed-by: Christoph Hellwig
---
drivers/block/loop.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index fa1b7a9..3008dec 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
When running on files the physical blocksize is actually 4k,
so we should be announcing it as such. This is enabled with
a new LO_FLAGS_BLOCKSIZE flag value to the existing
loop_set_status ioctl.
Signed-off-by: Hannes Reinecke
---
drivers/block/loop.c | 9 -
include/uapi/linux
Add a new field 'lo_logical_blocksize' to hold the logical
blocksize of the loop device.
Signed-off-by: Hannes Reinecke <h...@suse.de>
---
drivers/block/loop.c | 9 +++--
drivers/block/loop.h | 1 +
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/block/loop.c b/d
Add a new field 'lo_logical_blocksize' to hold the logical
blocksize of the loop device.
Signed-off-by: Hannes Reinecke
---
drivers/block/loop.c | 9 +++--
drivers/block/loop.h | 1 +
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
401 - 500 of 1903 matches
Mail list logo
