Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

[Sinan Kaya]

On 11/10/2015 3:38 AM, Arnd Bergmann wrote:
> No, as Timur found, the driver is correct and it intentionally

sets the 32-bit mask, and that is guaranteed to work on all sane
hardware. Don't change the driver but find a better platform for
your workload, or talk to the people that are responsible for
the platform and get them to fix it.


Platform does have an IOMMU. No issues there. I am trying to clean out 
the patch pipe I have in order to get this card working with and without 
IOMMU.




If the platform also doesn't have an IOMMU, you can probably work
around it by setting up the dma-ranges property of the PCI host
to map the low PCI addresses to the start of RAM. This will also
require changes in the bootloader to set up the PCI outbound translation,
and it will require implementing the DMA offset on ARM64, which I was
hoping to avoid.


From the email thread, it looks like this was introduced to support 
some legacy card that has 64 bit addressing limitations and is being 
carried around ("rotted") since then.


I'm the second guy after the powerpc architecture complaining about the 
very same issue. Any red flags?


I can't change the address map for PCIe. SBSA requires all inbound PCIe 
addresses to be non-translated.


I'll just have to stick with IOMMU for this card.

--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

[Arnd Bergmann]

On Tuesday 10 November 2015 11:06:40 Sinan Kaya wrote:
> On 11/10/2015 3:38 AM, Arnd Bergmann wrote:
>  > No, as Timur found, the driver is correct and it intentionally
> > sets the 32-bit mask, and that is guaranteed to work on all sane
> > hardware. Don't change the driver but find a better platform for
> > your workload, or talk to the people that are responsible for
> > the platform and get them to fix it.
> 
> Platform does have an IOMMU. No issues there. I am trying to clean out 
> the patch pipe I have in order to get this card working with and without 
> IOMMU.

On PowerPC, I think we automatically enable the IOMMU whenever a DMA
mask is set that doesn't cover all of the RAM. We could think about
doing the same thing on ARM64 to make all devices work out of the box.

> > If the platform also doesn't have an IOMMU, you can probably work
> > around it by setting up the dma-ranges property of the PCI host
> > to map the low PCI addresses to the start of RAM. This will also
> > require changes in the bootloader to set up the PCI outbound translation,
> > and it will require implementing the DMA offset on ARM64, which I was
> > hoping to avoid.
> 
>  From the email thread, it looks like this was introduced to support 
> some legacy card that has 64 bit addressing limitations and is being 
> carried around ("rotted") since then.
> 
> I'm the second guy after the powerpc architecture complaining about the 
> very same issue. Any red flags?

What BenH was worried about here is that the driver sets different masks
for streaming and coherent mappings, which is indeed a worry that
could hit us on ARM as well, but I suppose we'll have to deal with
that in platform code.

Setting both masks to 32-bit is something that a lot of drivers do,
and without IOMMU enabled, you'd hit the same bug on all of them.
 
> I can't change the address map for PCIe. SBSA requires all inbound PCIe 
> addresses to be non-translated.

What about changing the memory map? I suspect there will be more
problems for you in the future when all of your RAM is at high
addresses.  Is this something you could fix in the bootloader by
moving the first 2GB to a different CPU physical address?

> I'll just have to stick with IOMMU for this card.

Ok. But how do you currently decide whether to use the IOMMU or not?

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

[Timur Tabi]

On 11/10/2015 10:47 AM, Arnd Bergmann wrote:

What BenH was worried about here is that the driver sets different masks
for streaming and coherent mappings, which is indeed a worry that
could hit us on ARM as well, but I suppose we'll have to deal with
that in platform code.

Setting both masks to 32-bit is something that a lot of drivers do,
and without IOMMU enabled, you'd hit the same bug on all of them.


Also note that I think that on PowerPC, the mask is set to 32 by default 
for all devices.  I don't think we do that on ARM64.  So on PowerPC, 
some drivers get away with not explicitly setting the mask.


--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

[Sinan Kaya]

On 11/10/2015 1:27 PM, James Bottomley wrote:

On Tue, 2015-11-10 at 12:19 -0500, Sinan Kaya wrote:

On 11/10/2015 11:47 AM, Arnd Bergmann wrote:

On Tuesday 10 November 2015 11:06:40 Sinan Kaya wrote:

On 11/10/2015 3:38 AM, Arnd Bergmann wrote:
   From the email thread, it looks like this was introduced to support
some legacy card that has 64 bit addressing limitations and is being
carried around ("rotted") since then.

I'm the second guy after the powerpc architecture complaining about the
very same issue. Any red flags?


What BenH was worried about here is that the driver sets different masks
for streaming and coherent mappings, which is indeed a worry that
could hit us on ARM as well, but I suppose we'll have to deal with
that in platform code.

Setting both masks to 32-bit is something that a lot of drivers do,
and without IOMMU enabled, you'd hit the same bug on all of them.



Maybe, maybe not. This is the only card that I had problems with.


Your characterisation of "some legacy card" isn't entirely correct.
Just to clarify how this happens, most I/O cards today are intelligent
offload engines which means they have some type of embedded CPU (it can
even be a specially designed asic).  This CPU is driven by firmware
which is mostly (but not always) in the machine language of the CPU.
DMA transfers are sometimes run by this CPU, but mostly handed off to a
separate offload engine.  When the board gets revised, it's often easier
to update the offload engine to 64 bits and keep the CPU at 32 (or even
16) bits.  This means that all the internal addresses in the firmware
are 32 bit only.  As I read the comments in the original thread, it
looks like the mpt people tried to mitigate this by using segment
registers for external addresses firmware uses ... that's why they say
that they don't have to have all the addresses in DMA32 ... they just
need the upper 32 bits to be constant so they can correctly program the
segment register.  Unfortunately, we have no way to parametrise this to
the DMA allocation code.

You'll find the same thing with Adaptec SPI cards.  Their route to 64
bits was via an initial 39 bit extension that had them layering the
additional 7 bits into the unused lower region of the page descriptors
for the firmware (keeping the actual pointers to DMA at 32 bits because
they're always parametrised as address, offset, length and the address
is always a 4k page).

Eventually, everything will rev to 64 bits and this problem will go
away, but, as I suspect you know, it takes time for the embedded world
to get to where everyone else already is.

As Arnd said, if you failed to allow for this in your platform, then
oops, just don't use the card.  I think this solution would be better
than trying to get the driver to work out which cards can support 64 bit
firmware descriptors and only failing on your platform for those that
can't.

James




James,
I was referring to this conversation here.

https://lkml.org/lkml/2015/2/20/31

"The aic79xx hardware problem was that the DMA engine could address the 
whole of memory (it had two address modes, a 39 bit one and a 64 bit 
one) but the script engine that runs the mailboxes only had a 32 bit 
activation register (the activating write points at the physical address 
of the script to begin executing)."


The fact that LSI SAS 92118i is working with 64 bit addresses suggests 
me that this problem is already solved.  I have not hit any kind of 
regressions with 93xx and 92xx families under load in a true 64 bit 
environment. I am only mentioning this based on my testing exposure.


Another comment here from you.
https://lkml.org/lkml/2015/4/2/28

"Well, it was originally a hack for altix, because they had no regions
below 4GB and had to specifically manufacture them.  As you know, in
Linux, if Intel doesn't need it, no-one cares and the implementation
bitrots."

Maybe, it is time to fix the code for more recent (even decent) hardware?

Sinan

--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

[Arnd Bergmann]

On Tuesday 10 November 2015 11:00:59 Timur Tabi wrote:
> On 11/10/2015 10:47 AM, Arnd Bergmann wrote:
> > What BenH was worried about here is that the driver sets different masks
> > for streaming and coherent mappings, which is indeed a worry that
> > could hit us on ARM as well, but I suppose we'll have to deal with
> > that in platform code.
> >
> > Setting both masks to 32-bit is something that a lot of drivers do,
> > and without IOMMU enabled, you'd hit the same bug on all of them.
> 
> Also note that I think that on PowerPC, the mask is set to 32 by default 
> for all devices.  I don't think we do that on ARM64.  So on PowerPC, 
> some drivers get away with not explicitly setting the mask.
> 

If the mask is 64-bit by default on ARM64, that is a bug that we need
to fix urgently. Can you verify this?

A lot of PCI devices can only do 32-bit DMA, and we have plenty
of drivers that don't bother setting a mask at all because the 32-bit
mask is the default on all other architectures.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

[James Bottomley]

On Tue, 2015-11-10 at 12:19 -0500, Sinan Kaya wrote:
> On 11/10/2015 11:47 AM, Arnd Bergmann wrote:
> > On Tuesday 10 November 2015 11:06:40 Sinan Kaya wrote:
> >> On 11/10/2015 3:38 AM, Arnd Bergmann wrote:
> >>   From the email thread, it looks like this was introduced to support
> >> some legacy card that has 64 bit addressing limitations and is being
> >> carried around ("rotted") since then.
> >>
> >> I'm the second guy after the powerpc architecture complaining about the
> >> very same issue. Any red flags?
> >
> > What BenH was worried about here is that the driver sets different masks
> > for streaming and coherent mappings, which is indeed a worry that
> > could hit us on ARM as well, but I suppose we'll have to deal with
> > that in platform code.
> >
> > Setting both masks to 32-bit is something that a lot of drivers do,
> > and without IOMMU enabled, you'd hit the same bug on all of them.
> >
> 
> Maybe, maybe not. This is the only card that I had problems with.

Your characterisation of "some legacy card" isn't entirely correct.
Just to clarify how this happens, most I/O cards today are intelligent
offload engines which means they have some type of embedded CPU (it can
even be a specially designed asic).  This CPU is driven by firmware
which is mostly (but not always) in the machine language of the CPU.
DMA transfers are sometimes run by this CPU, but mostly handed off to a
separate offload engine.  When the board gets revised, it's often easier
to update the offload engine to 64 bits and keep the CPU at 32 (or even
16) bits.  This means that all the internal addresses in the firmware
are 32 bit only.  As I read the comments in the original thread, it
looks like the mpt people tried to mitigate this by using segment
registers for external addresses firmware uses ... that's why they say
that they don't have to have all the addresses in DMA32 ... they just
need the upper 32 bits to be constant so they can correctly program the
segment register.  Unfortunately, we have no way to parametrise this to
the DMA allocation code.

You'll find the same thing with Adaptec SPI cards.  Their route to 64
bits was via an initial 39 bit extension that had them layering the
additional 7 bits into the unused lower region of the page descriptors
for the firmware (keeping the actual pointers to DMA at 32 bits because
they're always parametrised as address, offset, length and the address
is always a 4k page).

Eventually, everything will rev to 64 bits and this problem will go
away, but, as I suspect you know, it takes time for the embedded world
to get to where everyone else already is.

As Arnd said, if you failed to allow for this in your platform, then
oops, just don't use the card.  I think this solution would be better
than trying to get the driver to work out which cards can support 64 bit
firmware descriptors and only failing on your platform for those that
can't.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4.1] target-core: fix return without a value

[Greg Kroah-Hartman]

On Tue, Nov 10, 2015 at 01:32:10PM -0500, Mikulas Patocka wrote:
> Fix the warning drivers/target/target_core_pr.c:332:3: warning: 'return'
> with no value, in function returning non-void [-Wreturn-type]
> 
> The patch 35afa65642a9a88c81913377b93a3a66220f8b9d committed to 4.1.11
> adds a check if device_list is NULL. The patch adds a return statement
> without a value to the function core_scsi3_pr_seq_non_holder that returns
> int.
> 
> Signed-off-by: Mikulas Patocka 
> 
> ---
>  drivers/target/target_core_pr.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)



This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
for how to do this properly.


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

[Sinan Kaya]

On 11/10/2015 11:47 AM, Arnd Bergmann wrote:

On Tuesday 10 November 2015 11:06:40 Sinan Kaya wrote:

On 11/10/2015 3:38 AM, Arnd Bergmann wrote:
  > No, as Timur found, the driver is correct and it intentionally

sets the 32-bit mask, and that is guaranteed to work on all sane
hardware. Don't change the driver but find a better platform for
your workload, or talk to the people that are responsible for
the platform and get them to fix it.


Platform does have an IOMMU. No issues there. I am trying to clean out
the patch pipe I have in order to get this card working with and without
IOMMU.


On PowerPC, I think we automatically enable the IOMMU whenever a DMA
mask is set that doesn't cover all of the RAM. We could think about
doing the same thing on ARM64 to make all devices work out of the box.



The ACPI IORT table declares whether you enable IOMMU for a particular 
device or not. The placement of IOMMU HW is system specific. The IORT 
table gives the IOMMU HW topology to the operating system.



If the platform also doesn't have an IOMMU, you can probably work
around it by setting up the dma-ranges property of the PCI host
to map the low PCI addresses to the start of RAM. This will also
require changes in the bootloader to set up the PCI outbound translation,
and it will require implementing the DMA offset on ARM64, which I was
hoping to avoid.


  From the email thread, it looks like this was introduced to support
some legacy card that has 64 bit addressing limitations and is being
carried around ("rotted") since then.

I'm the second guy after the powerpc architecture complaining about the
very same issue. Any red flags?


What BenH was worried about here is that the driver sets different masks
for streaming and coherent mappings, which is indeed a worry that
could hit us on ARM as well, but I suppose we'll have to deal with
that in platform code.

Setting both masks to 32-bit is something that a lot of drivers do,
and without IOMMU enabled, you'd hit the same bug on all of them.



Maybe, maybe not. This is the only card that I had problems with.


I can't change the address map for PCIe. SBSA requires all inbound PCIe
addresses to be non-translated.


What about changing the memory map? I suspect there will be more
problems for you in the future when all of your RAM is at high
addresses.  Is this something you could fix in the bootloader by
moving the first 2GB to a different CPU physical address?


I'm thinking about this.




I'll just have to stick with IOMMU for this card.


Ok. But how do you currently decide whether to use the IOMMU or not?



ACPI table. I wanted to get this fix in so that all operating systems 
whether they have IOMMU driver enabled or not would work.



Arnd



--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4.1] target-core: fix return without a value

[Mikulas Patocka]

Fix the warning drivers/target/target_core_pr.c:332:3: warning: 'return'
with no value, in function returning non-void [-Wreturn-type]

The patch 35afa65642a9a88c81913377b93a3a66220f8b9d committed to 4.1.11
adds a check if device_list is NULL. The patch adds a return statement
without a value to the function core_scsi3_pr_seq_non_holder that returns
int.

Signed-off-by: Mikulas Patocka 

---
 drivers/target/target_core_pr.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-4.1.13/drivers/target/target_core_pr.c
===
--- linux-4.1.13.orig/drivers/target/target_core_pr.c   2015-10-23 
18:25:26.0 +0200
+++ linux-4.1.13/drivers/target/target_core_pr.c2015-11-10 
19:22:07.0 +0100
@@ -329,7 +329,7 @@ static int core_scsi3_pr_seq_non_holder(
 * RESERVATION CONFLICT on some CDBs */
 
if (!se_sess->se_node_acl->device_list)
-   return;
+   return -EINVAL;
 
se_deve = se_sess->se_node_acl->device_list[cmd->orig_fe_lun];
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

[James Bottomley]

On Tue, 2015-11-10 at 14:56 -0500, Sinan Kaya wrote:
> 
> On 11/10/2015 2:43 PM, James Bottomley wrote:
> > The Issue, as stated by LSI is
> >
> >  Initially set the consistent DMA mask to 32 bit and then change
> >  it
> >  to 64 bit mask after allocating RDPQ pools by calling the
> >  function
> >  _base_change_consistent_dma_mask. This is to ensure that all the
> >  upper 32 bits of RDPQ entries's base address to be same.
> >
> 
> Need somebody from mpt to confirm that this behavior is still valid for 
> the recent cards besides altix.

OK, you don't seem to be understanding the problem: the Altix isn't a
LSI card, it was a SGI platform.  It was the platform where we first
discovered the issue that a lot of storage cards didn't work because it
by default had no memory below 4GB.  The reason coherent masks were
introduced was initially so the Altix could manufacture and manage a
region of memory in the lower 4GB region and we would guarantee to make
allocations from it so the storage cards would then work on that
platform.

I thought the Altix was a historical relic because after they
disappeared, there was no other platform with this issue ...  until you
came along.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

[Sinan Kaya]

On 11/10/2015 3:05 PM, James Bottomley wrote:

OK, you don't seem to be understanding the problem: the Altix isn't a
LSI card, it was a SGI platform.


Got it.


It was the platform where we first
discovered the issue that a lot of storage cards didn't work because it
by default had no memory below 4GB.  The reason coherent masks were
introduced was initially so the Altix could manufacture and manage a
region of memory in the lower 4GB region and we would guarantee to make
allocations from it so the storage cards would then work on that
platform.


I can't fix the issue if the card cannot do 64 bit DMA when IOMMU is not 
there. I need IOMMU enabled all the time for this card.


--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

[Arnd Bergmann]

On Tuesday 10 November 2015 12:19:33 Sinan Kaya wrote:
> On 11/10/2015 11:47 AM, Arnd Bergmann wrote:
> > On Tuesday 10 November 2015 11:06:40 Sinan Kaya wrote:
> >> On 11/10/2015 3:38 AM, Arnd Bergmann wrote:
> >>   > No, as Timur found, the driver is correct and it intentionally
> >>> sets the 32-bit mask, and that is guaranteed to work on all sane
> >>> hardware. Don't change the driver but find a better platform for
> >>> your workload, or talk to the people that are responsible for
> >>> the platform and get them to fix it.
> >>
> >> Platform does have an IOMMU. No issues there. I am trying to clean out
> >> the patch pipe I have in order to get this card working with and without
> >> IOMMU.
> >
> > On PowerPC, I think we automatically enable the IOMMU whenever a DMA
> > mask is set that doesn't cover all of the RAM. We could think about
> > doing the same thing on ARM64 to make all devices work out of the box.
> >
> 
> The ACPI IORT table declares whether you enable IOMMU for a particular 
> device or not. The placement of IOMMU HW is system specific. The IORT 
> table gives the IOMMU HW topology to the operating system.

This sounds odd. Clearly you need to specify the IOMMU settings for each
possible PCI device independent of whether the OS actually uses the IOMMU
or not. In a lot of cases, we want to turn it off to get better performance
when the driver has set a DMA mask that covers all of RAM, but you
also want to enable the IOMMU for debugging purposes or for device
assignment if you run virtual machines. The bootloader doesn't know how
the device is going to be used, so it cannot define the policy here.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

[Arnd Bergmann]

On Tuesday 10 November 2015 15:03:59 Timur Tabi wrote:
> On 11/10/2015 01:13 PM, Arnd Bergmann wrote:
> > If the mask is 64-bit by default on ARM64, that is a bug that we need
> > to fix urgently. Can you verify this?
> 
> I think the mask is 0 by default, because there's no code in ARM64 that 
> actually sets the mask.
> 
> Take a look at arch_setup_pdev_archdata() in 
> arch/powerpc/kernel/setup-common.c.
> 
> void arch_setup_pdev_archdata(struct platform_device *pdev)
> {
>  pdev->archdata.dma_mask = DMA_BIT_MASK(32);
>  pdev->dev.dma_mask = >archdata.dma_mask;
>  set_dma_ops(>dev, _direct_ops);
> }
> 
> I don't see anything equivalent in arch/arm64

of_dma_configure() sets up an initial DMA mask for 32 bits. The
same thing happens for pci_setup_device() in architecture-independent
code?

> > A lot of PCI devices can only do 32-bit DMA, and we have plenty
> > of drivers that don't bother setting a mask at all because the 32-bit
> > mask is the default on all other architectures.
> 
> In our drivers for 32-bit devices, we have to explicitly set the DMA 
> mask to 32-bits in order to get any DMA working.

Do you mean PCI devices or platform devices?

Maybe the parent bus is lacking a dma-ranges property?

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

[Sinan Kaya]

On 11/10/2015 2:43 PM, James Bottomley wrote:

The Issue, as stated by LSI is

 Initially set the consistent DMA mask to 32 bit and then change
 it
 to 64 bit mask after allocating RDPQ pools by calling the
 function
 _base_change_consistent_dma_mask. This is to ensure that all the
 upper 32 bits of RDPQ entries's base address to be same.



Need somebody from mpt to confirm that this behavior is still valid for 
the recent cards besides altix.



If you set a 64 bit coherent mask before this point, you're benefiting
from being lucky that all the upper 32 bits of the allocations are the
same ... we can't code a driver to rely on luck.  Particularly not when
the failure mode looks like it would be silent and deadly.


Of course nobody wants unreliable code.

I'm wondering if I was just lucky during my testing or the 92xx and 93xx 
hardware supports full 64 bit range. I don't have any insight into what 
the endpoint does or what it is capable of.





>Another comment here from you.
>https://lkml.org/lkml/2015/4/2/28
>
>"Well, it was originally a hack for altix, because they had no regions
>below 4GB and had to specifically manufacture them.  As you know, in
>Linux, if Intel doesn't need it, no-one cares and the implementation
>bitrots."
>
>Maybe, it is time to fix the code for more recent (even decent) hardware?

What do you mean "fix the code"?  The code isn't broken, it's
parametrising issues with particular hardware.  There's no software work
around (except allocating memory with the correct characteristics).


Need confirmation. I'm questioning if we are stuck with this behavior 
because of altix or something else. If the latter case, the code could 
have used PCI ID to do something special for it.


--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

[James Bottomley]

On Tue, 2015-11-10 at 14:14 -0500, Sinan Kaya wrote:
> 
> On 11/10/2015 1:27 PM, James Bottomley wrote:
> > On Tue, 2015-11-10 at 12:19 -0500, Sinan Kaya wrote:
> >> On 11/10/2015 11:47 AM, Arnd Bergmann wrote:
> >>> On Tuesday 10 November 2015 11:06:40 Sinan Kaya wrote:
>  On 11/10/2015 3:38 AM, Arnd Bergmann wrote:
> From the email thread, it looks like this was introduced to support
>  some legacy card that has 64 bit addressing limitations and is being
>  carried around ("rotted") since then.
> 
>  I'm the second guy after the powerpc architecture complaining about the
>  very same issue. Any red flags?
> >>>
> >>> What BenH was worried about here is that the driver sets different masks
> >>> for streaming and coherent mappings, which is indeed a worry that
> >>> could hit us on ARM as well, but I suppose we'll have to deal with
> >>> that in platform code.
> >>>
> >>> Setting both masks to 32-bit is something that a lot of drivers do,
> >>> and without IOMMU enabled, you'd hit the same bug on all of them.
> >>>
> >>
> >> Maybe, maybe not. This is the only card that I had problems with.
> >
> > Your characterisation of "some legacy card" isn't entirely correct.
> > Just to clarify how this happens, most I/O cards today are intelligent
> > offload engines which means they have some type of embedded CPU (it can
> > even be a specially designed asic).  This CPU is driven by firmware
> > which is mostly (but not always) in the machine language of the CPU.
> > DMA transfers are sometimes run by this CPU, but mostly handed off to a
> > separate offload engine.  When the board gets revised, it's often easier
> > to update the offload engine to 64 bits and keep the CPU at 32 (or even
> > 16) bits.  This means that all the internal addresses in the firmware
> > are 32 bit only.  As I read the comments in the original thread, it
> > looks like the mpt people tried to mitigate this by using segment
> > registers for external addresses firmware uses ... that's why they say
> > that they don't have to have all the addresses in DMA32 ... they just
> > need the upper 32 bits to be constant so they can correctly program the
> > segment register.  Unfortunately, we have no way to parametrise this to
> > the DMA allocation code.
> >
> > You'll find the same thing with Adaptec SPI cards.  Their route to 64
> > bits was via an initial 39 bit extension that had them layering the
> > additional 7 bits into the unused lower region of the page descriptors
> > for the firmware (keeping the actual pointers to DMA at 32 bits because
> > they're always parametrised as address, offset, length and the address
> > is always a 4k page).
> >
> > Eventually, everything will rev to 64 bits and this problem will go
> > away, but, as I suspect you know, it takes time for the embedded world
> > to get to where everyone else already is.
> >
> > As Arnd said, if you failed to allow for this in your platform, then
> > oops, just don't use the card.  I think this solution would be better
> > than trying to get the driver to work out which cards can support 64 bit
> > firmware descriptors and only failing on your platform for those that
> > can't.
> >
> > James
> >
> >
> 
> James,
> I was referring to this conversation here.
> 
> https://lkml.org/lkml/2015/2/20/31
> 
> "The aic79xx hardware problem was that the DMA engine could address the 
> whole of memory (it had two address modes, a 39 bit one and a 64 bit 
> one) but the script engine that runs the mailboxes only had a 32 bit 
> activation register (the activating write points at the physical address 
> of the script to begin executing)."
> 
> The fact that LSI SAS 92118i is working with 64 bit addresses suggests 
> me that this problem is already solved.  I have not hit any kind of 
> regressions with 93xx and 92xx families under load in a true 64 bit 
> environment. I am only mentioning this based on my testing exposure.

The Issue, as stated by LSI is

Initially set the consistent DMA mask to 32 bit and then change
it
to 64 bit mask after allocating RDPQ pools by calling the
function
_base_change_consistent_dma_mask. This is to ensure that all the
upper 32 bits of RDPQ entries's base address to be same.

If you set a 64 bit coherent mask before this point, you're benefiting
from being lucky that all the upper 32 bits of the allocations are the
same ... we can't code a driver to rely on luck.  Particularly not when
the failure mode looks like it would be silent and deadly.

> Another comment here from you.
> https://lkml.org/lkml/2015/4/2/28
> 
> "Well, it was originally a hack for altix, because they had no regions
> below 4GB and had to specifically manufacture them.  As you know, in
> Linux, if Intel doesn't need it, no-one cares and the implementation
> bitrots."
> 
> Maybe, it is time to fix the code for more recent (even decent) hardware?

What do you mean "fix the code"?  The code isn't broken, it's

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

[James Bottomley]

On Tue, 2015-11-10 at 15:26 -0500, Sinan Kaya wrote:
> 
> On 11/10/2015 3:05 PM, James Bottomley wrote:
> > OK, you don't seem to be understanding the problem: the Altix isn't a
> > LSI card, it was a SGI platform.
> 
> Got it.
> 
> > It was the platform where we first
> > discovered the issue that a lot of storage cards didn't work because it
> > by default had no memory below 4GB.  The reason coherent masks were
> > introduced was initially so the Altix could manufacture and manage a
> > region of memory in the lower 4GB region and we would guarantee to make
> > allocations from it so the storage cards would then work on that
> > platform.
> 
> I can't fix the issue if the card cannot do 64 bit DMA when IOMMU is not 
> there. I need IOMMU enabled all the time for this card.

That depends on the limitations of your platform.  The Altix only used
an iommu to manufacture the coherent memory for the descriptors, but the
card itself mostly operated in bypass mode (using 64 bit physical
addresses rather than iommu remapped ones), so all accesses except for
the few firmware descriptor ones didn't use an iommu.  Apparently this
was for performance reasons.

So, to recap, the card itself *can* do 64 bit DMA.  The limitation is
that the RDPQ descriptors need to be all in the same region of 4G memory
and the way the driver ensures this is to set the 64 bit coherent mask
after using the 32 bit one to allocate the RDPQ pools.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

[Timur Tabi]

On 11/10/2015 01:13 PM, Arnd Bergmann wrote:

If the mask is 64-bit by default on ARM64, that is a bug that we need
to fix urgently. Can you verify this?


I think the mask is 0 by default, because there's no code in ARM64 that 
actually sets the mask.


Take a look at arch_setup_pdev_archdata() in 
arch/powerpc/kernel/setup-common.c.


void arch_setup_pdev_archdata(struct platform_device *pdev)
{
pdev->archdata.dma_mask = DMA_BIT_MASK(32);
pdev->dev.dma_mask = >archdata.dma_mask;
set_dma_ops(>dev, _direct_ops);
}

I don't see anything equivalent in arch/arm64


A lot of PCI devices can only do 32-bit DMA, and we have plenty
of drivers that don't bother setting a mask at all because the 32-bit
mask is the default on all other architectures.


In our drivers for 32-bit devices, we have to explicitly set the DMA 
mask to 32-bits in order to get any DMA working.


--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

[Sinan Kaya]

On 11/10/2015 2:56 PM, Arnd Bergmann wrote:

The ACPI IORT table declares whether you enable IOMMU for a particular
>device or not. The placement of IOMMU HW is system specific. The IORT
>table gives the IOMMU HW topology to the operating system.

This sounds odd. Clearly you need to specify the IOMMU settings for each
possible PCI device independent of whether the OS actually uses the IOMMU
or not.


There are provisions to have DMA mask in the PCIe host bridge not at the 
PCIe device level inside IORT table. This setting is specific for each 
PCIe bus. It is not per PCIe device.


It is assumed that the endpoint device driver knows the hardware for 
PCIe devices. The driver can also query the supported DMA bits by this 
platform via DMA APIs and will request the correct DMA mask from the DMA 
subsystem (surprise!).



In a lot of cases, we want to turn it off to get better performance
when the driver has set a DMA mask that covers all of RAM, but you
also want to enable the IOMMU for debugging purposes or for device
assignment if you run virtual machines. The bootloader doesn't know how
the device is going to be used, so it cannot define the policy here.


I think we'll end up adding a virtualization option to the UEFI BIOS 
similar to how Intel platforms work. Based on this switch, we'll end up 
patching the ACPI table.


If I remove the IORT entry, then the device is in coherent mode with 
device accessing the full RAM range.


If I have the IORT table, the device is in IOMMU translation mode.

Details are in the IORT spec.


--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

[Timur Tabi]

On 11/10/2015 03:54 PM, Arnd Bergmann wrote:


In our drivers for 32-bit devices, we have to explicitly set the DMA
mask to 32-bits in order to get any DMA working.


Do you mean PCI devices or platform devices?


Platform.


Maybe the parent bus is lacking a dma-ranges property?


All of this applies only on device-tree platforms.  Sinan and I are 
working on an ACPI server platform.  So we never call 
of_dma_configure(), and we don't have a dma-ranges property.


--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

[Arnd Bergmann]

On Tuesday 10 November 2015 15:58:19 Sinan Kaya wrote:
> 
> On 11/10/2015 2:56 PM, Arnd Bergmann wrote:
> >> The ACPI IORT table declares whether you enable IOMMU for a particular
> >> >device or not. The placement of IOMMU HW is system specific. The IORT
> >> >table gives the IOMMU HW topology to the operating system.
> > This sounds odd. Clearly you need to specify the IOMMU settings for each
> > possible PCI device independent of whether the OS actually uses the IOMMU
> > or not.
> 
> There are provisions to have DMA mask in the PCIe host bridge not at the 
> PCIe device level inside IORT table. This setting is specific for each 
> PCIe bus. It is not per PCIe device.

Same thing, I meant the bootloader must provide all the information that
is needed to use the IOMMU on all PCI devices. I don't care where the IOMMU
driver gets that information. Some IOMMUs require programming a
bus/device/function specific number into the I/O page tables, and they
might not always have the same algorithm to map from the PCI numbers
into their own number space.

> It is assumed that the endpoint device driver knows the hardware for 
> PCIe devices. The driver can also query the supported DMA bits by this 
> platform via DMA APIs and will request the correct DMA mask from the DMA 
> subsystem (surprise!).

I know how the negotiation works. Note that dma_get_required_mask()
will only tell you what mask the device needs to access all of memory,
while both the device and bus may have additional limitations, and
there is not always a solution.

> >In a lot of cases, we want to turn it off to get better performance
> > when the driver has set a DMA mask that covers all of RAM, but you
> > also want to enable the IOMMU for debugging purposes or for device
> > assignment if you run virtual machines. The bootloader doesn't know how
> > the device is going to be used, so it cannot define the policy here.
> 
> I think we'll end up adding a virtualization option to the UEFI BIOS 
> similar to how Intel platforms work. Based on this switch, we'll end up 
> patching the ACPI table.
> 
> If I remove the IORT entry, then the device is in coherent mode with 
> device accessing the full RAM range.
> 
> If I have the IORT table, the device is in IOMMU translation mode.
> 
> Details are in the IORT spec.

I think that would suck a lot more than being slightly out of spec
regarding SBSA if you make the low PCI addresses map to the start
of RAM. Asking users to select a 'virtualization' option based on
what kind of PCI device and kernel version they have is a major
hassle.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4.1] target-core: fix return without a value

[Greg Kroah-Hartman]

On Tue, Nov 10, 2015 at 06:31:47PM -0500, Mikulas Patocka wrote:
> 
> 
> On Tue, 10 Nov 2015, Greg Kroah-Hartman wrote:
> 
> > On Tue, Nov 10, 2015 at 01:32:10PM -0500, Mikulas Patocka wrote:
> > > Fix the warning drivers/target/target_core_pr.c:332:3: warning: 'return'
> > > with no value, in function returning non-void [-Wreturn-type]
> > > 
> > > The patch 35afa65642a9a88c81913377b93a3a66220f8b9d committed to 4.1.11
> > > adds a check if device_list is NULL. The patch adds a return statement
> > > without a value to the function core_scsi3_pr_seq_non_holder that returns
> > > int.
> > > 
> > > Signed-off-by: Mikulas Patocka 
> > > 
> > > ---
> > >  drivers/target/target_core_pr.c |2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > 
> > 
> > This is not the correct way to submit patches for inclusion in the
> > stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
> > for how to do this properly.
> > 
> > 
> 
> This patch has no upstream equivalent (because the code in upstream was 
> already refactored), so none of the rules in stable_kernel_rules.txt apply 
> to it. The patch that broke it also has no upstream equivalent.
>

Then you need to say that!

And the fact that a "please take this patch, it's correct but doesn't
apply to upstream" patch is now broken is proof of why I didn't want to
take it in the first place!

Ugh.  How about I just revert the original patch and then you send me
backports of what is actually in Linus's tree so we don't have this
problem anymore?

Oh, and you got the stable mailing list address wrong as well :(

Please fix all of this up and resend.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RESEND] scsi: Set sg_tablesize to 1, for LLDDs that set SG_NONE

[Manoj Kumar]

Oops while testing blk_mq over the new cxlflash driver.

[ 2960.817172] Oops: Kernel access of bad area, sig: 11 [#5]
[ 2960.817309] NIP  __blk_mq_run_hw_queue+0x278/0x4c0
[ 2960.817313] LR __blk_mq_run_hw_queue+0x2bc/0x4c0
[ 2960.817314] Call Trace:
[ 2960.817320] __blk_mq_run_hw_queue+0x2bc/0x4c0 (unreliable)
[ 2960.817324] blk_mq_run_hw_queue+0xd8/0x100
[ 2960.817329] blk_mq_insert_requests+0x14c/0x1f0
[ 2960.817333] blk_mq_flush_plug_list+0x150/0x190
[ 2960.817338] blk_flush_plug_list+0x11c/0x2b0
[ 2960.817344] blk_finish_plug+0x58/0x80
[ 2960.817348] __do_page_cache_readahead+0x1c0/0x2e0
[ 2960.817352] force_page_cache_readahead+0x68/0xd0
[ 2960.817356] generic_file_read_iter+0x43c/0x6a0
[ 2960.817359] blkdev_read_iter+0x68/0xa0
[ 2960.817361] __vfs_read+0x11c/0x180
[ 2960.817364] vfs_read+0xa4/0x1c0
[ 2960.817366] SyS_read+0x6c/0x110
[ 2960.817369] system_call+0x38/0xb4

The root cause of the problem was this low level device driver(LLDD),
in this case cxlflash, does not support scatter-gather and hence had
set it's sg_tablesize to SG_NONE (value of 0). In reality the tablesize
is of length 1. This value of SG_NONE does not cause any problems with
the standard block driver stack but causes issues for blk_mq, as shown
above. Since quite a few of the legacy LLDDs are setting sg_tablesize
to SG_NONE, it was preferable to override the LLDD provided value in
scsi_host_alloc().

Signed-off-by: Manoj N. Kumar 
Signed-off-by: Youngjae Lee 
Reviewed-by: Matthew R. Ochs 
---
 drivers/scsi/hosts.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
index 8bb173e..bd13c9d 100644
--- a/drivers/scsi/hosts.c
+++ b/drivers/scsi/hosts.c
@@ -413,7 +413,7 @@ struct Scsi_Host *scsi_host_alloc(struct scsi_host_template 
*sht, int privsize)
shost->hostt = sht;
shost->this_id = sht->this_id;
shost->can_queue = sht->can_queue;
-   shost->sg_tablesize = sht->sg_tablesize;
+   shost->sg_tablesize = (sht->sg_tablesize ? sht->sg_tablesize : 1);
shost->sg_prot_tablesize = sht->sg_prot_tablesize;
shost->cmd_per_lun = sht->cmd_per_lun;
shost->unchecked_isa_dma = sht->unchecked_isa_dma;
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[patch] mptfusion: don't allow negative bytes in kbuf_alloc_2_sgl()

[Dan Carpenter]

There is a static checker warning here because "bytes" is controlled by
the user and we cap the upper bound with min() but allow negatives.
Negative bytes will result in some nasty warning messages but are not
super harmful.  Anyway, no one needs negative bytes so let's just check
for it and return NULL.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/message/fusion/mptctl.c b/drivers/message/fusion/mptctl.c
index fc73937..02b5f69 100644
--- a/drivers/message/fusion/mptctl.c
+++ b/drivers/message/fusion/mptctl.c
@@ -1038,6 +1038,10 @@ kbuf_alloc_2_sgl(int bytes, u32 sgdir, int sge_offset, 
int *frags,
int  i, buflist_ent;
int  sg_spill = MAX_FRAGS_SPILL1;
int  dir;
+
+   if (bytes < 0)
+   return NULL;
+
/* initialization */
*frags = 0;
*blp = NULL;
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4.1] target-core: fix return without a value

[Mikulas Patocka]

On Tue, 10 Nov 2015, Greg Kroah-Hartman wrote:

> On Tue, Nov 10, 2015 at 01:32:10PM -0500, Mikulas Patocka wrote:
> > Fix the warning drivers/target/target_core_pr.c:332:3: warning: 'return'
> > with no value, in function returning non-void [-Wreturn-type]
> > 
> > The patch 35afa65642a9a88c81913377b93a3a66220f8b9d committed to 4.1.11
> > adds a check if device_list is NULL. The patch adds a return statement
> > without a value to the function core_scsi3_pr_seq_non_holder that returns
> > int.
> > 
> > Signed-off-by: Mikulas Patocka 
> > 
> > ---
> >  drivers/target/target_core_pr.c |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> 
> 
> This is not the correct way to submit patches for inclusion in the
> stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
> for how to do this properly.
> 
> 

This patch has no upstream equivalent (because the code in upstream was 
already refactored), so none of the rules in stable_kernel_rules.txt apply 
to it. The patch that broke it also has no upstream equivalent.


Documentation/stable_kernel_rules.txt

   --- Option 1 ---

   To have the patch automatically included in the stable tree, add the tag
 Cc: sta...@vger.kernel.org
   in the sign-off area. Once the patch is merged it will be applied to
   the stable tree without anything else needing to be done by the author
   or subsystem maintainer.

   --- Option 2 ---

   After the patch has been merged to Linus' tree, send an email to
   sta...@vger.kernel.org containing the subject of the patch, the commit ID,
   why you think it should be applied, and what kernel version you wish it to
   be applied to.

   --- Option 3 ---

   Send the patch, after verifying that it follows the above rules, to
   sta...@vger.kernel.org.  You must note the upstream commit ID in the
   changelog of your submission, as well as the kernel version you wish
   it to be applied to.

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

[Arnd Bergmann]

On Tuesday 10 November 2015 15:59:18 Timur Tabi wrote:
> On 11/10/2015 03:54 PM, Arnd Bergmann wrote:
> 
> >> In our drivers for 32-bit devices, we have to explicitly set the DMA
> >> mask to 32-bits in order to get any DMA working.
> >
> > Do you mean PCI devices or platform devices?
> 
> Platform.
> 
> > Maybe the parent bus is lacking a dma-ranges property?
> 
> All of this applies only on device-tree platforms.  Sinan and I are 
> working on an ACPI server platform.  So we never call 
> of_dma_configure(), and we don't have a dma-ranges property.

ACPI must have something else to mark DMA master devices and their
capabilities, right?

The platform should initialize the dma_mask pointer to a per-device
mask and set both the dma_mask and dma_coherent_mask to 32 bits
for any DMA master device, and the device driver should override
that to be an appropriate mask based on its needs later.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 10/11] Documentation: devicetree: ufs: Add DT bindings for exynos UFS host controller

[Alim Akhtar]

Hi Rob,

On 11/09/2015 09:53 PM, Rob Herring wrote:

On Mon, Nov 09, 2015 at 10:56:26AM +0530, Alim Akhtar wrote:

From: Seungwon Jeon 

This adds Exynos Universal Flash Storage (UFS) Host Controller DT bindings.

Signed-off-by: Seungwon Jeon 
Signed-off-by: Alim Akhtar 
---
  .../devicetree/bindings/ufs/ufs-exynos.txt |  104 
  1 file changed, 104 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/ufs/ufs-exynos.txt

diff --git a/Documentation/devicetree/bindings/ufs/ufs-exynos.txt 
b/Documentation/devicetree/bindings/ufs/ufs-exynos.txt
new file mode 100644
index ..08e2d1497b1b
--- /dev/null
+++ b/Documentation/devicetree/bindings/ufs/ufs-exynos.txt
@@ -0,0 +1,104 @@
+* Exynos Universal Flash Storage (UFS) Host Controller
+
+UFSHC nodes are defined to describe on-chip UFS host controllers.
+Each UFS controller instance should have its own node.
+
+Required properties:
+- compatible: compatible name, contains "samsung,exynos7-ufs"
+- interrupts: 
+- reg   : Should contain HCI, vendor specific, UNIPRO and
+ UFS protector address space
+- reg-names: "hci", "vs_hci", "unipro", "ufsp";


No phy for MPHY?


ufs-phy is documented, see 01/11 of this series.

+
+Optional properties:
+- vdd-hba-supply: phandle to UFS host controller supply regulator node
+- vcc-supply: phandle to VCC supply regulator node
+- vccq-supply   : phandle to VCCQ supply regulator node
+- vccq2-supply  : phandle to VCCQ2 supply regulator node
+- vcc-supply-1p8: For embedded UFS devices, valid VCC range is 
1.7-1.95V
+  or 2.7-3.6V. This boolean property when set, 
specifies
+ to use low voltage range of 1.7-1.95V. Note for 
external
+ UFS cards this property is invalid and valid VCC 
range is
+ always 2.7-3.6V.
+- vcc-max-microamp  : specifies max. load that can be drawn from vcc supply
+- vccq-max-microamp : specifies max. load that can be drawn from vccq 
supply
+- vccq2-max-microamp: specifies max. load that can be drawn from vccq2 
supply


Some of these are supplies to the flash chip, so you should make
these common properties (in a common doc).


Ah, yes these are duplicated, already documented in common ufshcd file
Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
What is the recommended way, do I need to include it here as well? or 
just mentioning that "same as documented in ufshcd-pltfrm.txt"?



+- -fixed-regulator : boolean property specifying that -supply is a 
fixed regulator


This should be determined from the regulator.


Same as above already documented as part of ufshcd-pltfrm binding.

+
+- clocks: List of phandle and clock specifier pairs
+- clock-names   : List of clock input name strings sorted in the same
+  order as the clocks property.
+ "core", "sclk_unipro_main", "ref" and ref_parent
+
+- freq-table-hz: Array of  operating frequencies 
stored in the same
+ order as the clocks property. If this property is not
+ defined or a value in the array is "0" then it is 
assumed
+ that the frequency is set by the parent clock or a
+ fixed rate clock source.
+- pclk-freq-avail-range : specifies available frequency range(min/max) for APB 
clock
+- ufs,pwr-attr-mode : specifies mode value for power mode change, possible 
values are
+   "FAST", "SLOW", "FAST_auto" and "SLOW_auto"


ufs is not a vendor. Use a '-' rather than ','.


Ok will change.

+- ufs,pwr-attr-lane : specifies lane count value for power mode change
+ allowed values are 1 or 2
+- ufs,pwr-attr-gear : specifies gear count value for power mode change
+ allowed values are 1 or 2
+- ufs,pwr-attr-hs-series : specifies HS rate series for power mode change
+  can be one of "HS_rate_b" or "HS_rate_a"
+- ufs,pwr-local-l2-timer : specifies array of local UNIPRO L2 timer values
+  3 timers supported
+  
+- ufs,pwr-remote-l2-timer : specifies array of remote UNIPRO L2 timer values
+  3 timers supported
+  
+- ufs-rx-adv-fine-gran-sup_en : specifies support of fine granularity of MPHY,
+ this is a boolean property.
+- ufs-rx-adv-fine-gran-step : specifies granularity steps of MPHY,
+ allowed step size is 0 to 3
+- ufs-rx-adv-min-activate-time-cap : specifies rx advanced minimum activate 
time of MPHY
+  

RE: [patch 2/2] megaraid_sas: missing curly braces in megasas_detach_one()

[Kashyap Desai]

> -Original Message-
> From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> Sent: Saturday, November 07, 2015 9:47 PM
> To: Kashyap Desai; Sumit Saxena
> Cc: Uday Lingala; James E.J. Bottomley; megaraidlinux@avagotech.com;
> linux-scsi@vger.kernel.org; kernel-janit...@vger.kernel.org
> Subject: [patch 2/2] megaraid_sas: missing curly braces in
> megasas_detach_one()
>
> The indenting indicates that there are supposed to be some curly braces
> here.  Presumably it means we free something unintentionally leading to
a
> use after free.

NACK. Indentation is wrong. We don't need to add braces. We will fix
indentation and resend patch. Since this is not critical, let's ignore for
now.
>
> Fixes: 3761cb4cf65e ('megaraid_sas: JBOD sequence number support')
> Signed-off-by: Dan Carpenter 
> ---
> Not tested.
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index 829e9e9..91e200d 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -5932,7 +5932,7 @@ static void megasas_detach_one(struct pci_dev
> *pdev)
> fusion->max_map_sz,
> fusion->ld_map[i],
> fusion->ld_map_phys[i]);
> - if (fusion->ld_drv_map[i])
> + if (fusion->ld_drv_map[i]) {
>   free_pages((ulong)fusion->ld_drv_map[i],
>   fusion->drv_map_pages);
>   if (fusion->pd_seq_sync)
> @@ -5940,6 +5940,7 @@ static void megasas_detach_one(struct pci_dev
> *pdev)
>   pd_seq_map_sz,
>   fusion->pd_seq_sync[i],
>   fusion->pd_seq_phys[i]);
> + }
>   }
>   free_pages((ulong)instance->ctrl_context,
>   instance->ctrl_context_pages);
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 2/3] scsi: fix compiler warning for sg

[Andy Shevchenko]

On Tue, Nov 10, 2015 at 6:53 AM, Timur Tabi  wrote:
> Sinan Kaya wrote:
>>
>>
>> The code says it is using these macros for small integers only which
>> can't overflow. I was trying to get rid of compiler warning and it seems
>> to have disappeared.
>
>
> I would double-check the assembly code, if I were you.  I don't like it when
> warnings just go away like that.

+1 to that.

>
> Besides, we *should* be using do_div() for 64-bit division.

But here looks like all numbers are guaranteed to be less than or
equal to INT_MAX.
Thus, the matter is only to replace MULDIV() by mult_frac() which is
already in kernel.

-- 
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 2/3] scsi: fix compiler warning for sg

[Arnd Bergmann]

On Monday 09 November 2015 22:53:17 Timur Tabi wrote:
> Sinan Kaya wrote:
> >
> > The code says it is using these macros for small integers only which
> > can't overflow. I was trying to get rid of compiler warning and it seems
> > to have disappeared.
> 
> I would double-check the assembly code, if I were you.  I don't like it 
> when warnings just go away like that.
> 
> Besides, we *should* be using do_div() for 64-bit division.

I stared at this code for some time and couldn't figure out whether it
is actually safe or not. The point here is that it doesn't actually do
a 64-bit division here:

MULDIV(INT_MAX, USER_HZ, HZ)

where all arguments are 32bit and it tries to figure out whether the
ioctl argument is too big to fit into a 32-bit number

but it does a 'long' division that happens to be 64-bit long on
architectures with the respective register size when it then does

sfp->timeout = MULDIV (val, HZ, USER_HZ);

to scale up the argument from USER_HZ to the possibly larger in-kernel
HZ value. So I think it's safe as is, but I'm still not entirely sure.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [patch 1/2] megaraid_sas: remove a stray tab

[Kashyap Desai]

> -Original Message-
> From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> Sent: Saturday, November 07, 2015 9:46 PM
> To: Kashyap Desai; Sumit Saxena
> Cc: Uday Lingala; James E.J. Bottomley; megaraidlinux@avagotech.com;
> linux-scsi@vger.kernel.org; linux-ker...@vger.kernel.org; kernel-
> janit...@vger.kernel.org
> Subject: [patch 1/2] megaraid_sas: remove a stray tab
>
> One line was indented more than the others.
>
> Signed-off-by: Dan Carpenter 

Let us combine your next patch (because that is also indentation issue)
and this one. We will resubmit patch.   For now ignore to avoid any issue
for pending patches to be committed.

>
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index cc95372..829e9e9 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -5923,9 +5923,9 @@ static void megasas_detach_one(struct pci_dev
> *pdev)
>
>   if (instance->ctrl_context) {
>   megasas_release_fusion(instance);
> - pd_seq_map_sz = sizeof(struct
> MR_PD_CFG_SEQ_NUM_SYNC) +
> + pd_seq_map_sz = sizeof(struct
> MR_PD_CFG_SEQ_NUM_SYNC) +
>   (sizeof(struct MR_PD_CFG_SEQ) *
> - (MAX_PHYSICAL_DEVICES - 1));
> + (MAX_PHYSICAL_DEVICES - 1));
>   for (i = 0; i < 2 ; i++) {
>   if (fusion->ld_map[i])
>   dma_free_coherent(>pdev->dev,
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

[Arnd Bergmann]

On Monday 09 November 2015 18:22:22 Sinan Kaya wrote:
> On 11/9/2015 9:33 AM, Arnd Bergmann wrote:
> > On Monday 09 November 2015 09:07:36 Sinan Kaya wrote:
> >> On 11/9/2015 3:59 AM, Arnd Bergmann wrote:
> 
> ioc->dma_mask is 0 and the driver is trying to use 32 bit even though 64 
> bit supported by the platform.

Ok, makes sense.

> I think the proper fix is to pass the required_mask back to 
> consistent_dma_mask rather than using ioc->dma_mask and guessing.
> 
> pci_set_consistent_dma_mask(pdev, required_mask)
> 
> My code was just a band aid for broken code.
> 

No, as Timur found, the driver is correct and it intentionally
sets the 32-bit mask, and that is guaranteed to work on all sane
hardware. Don't change the driver but find a better platform for
your workload, or talk to the people that are responsible for
the platform and get them to fix it.

If the platform also doesn't have an IOMMU, you can probably work
around it by setting up the dma-ranges property of the PCI host
to map the low PCI addresses to the start of RAM. This will also
require changes in the bootloader to set up the PCI outbound translation,
and it will require implementing the DMA offset on ARM64, which I was
hoping to avoid.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 02/32] devicetree: bindings: scsi: HiSi SAS

[John Garry]

On 09/11/2015 18:01, Rob Herring wrote:

On Tue, Nov 10, 2015 at 12:32:07AM +0800, John Garry wrote:

Add devicetree bindings for HiSilicon SAS driver.

Signed-off-by: John Garry 
Signed-off-by: Zhangfei Gao 
---
  .../devicetree/bindings/scsi/hisilicon-sas.txt | 81 ++
  1 file changed, 81 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/scsi/hisilicon-sas.txt

diff --git a/Documentation/devicetree/bindings/scsi/hisilicon-sas.txt 
b/Documentation/devicetree/bindings/scsi/hisilicon-sas.txt
new file mode 100644
index 000..2333cc3
--- /dev/null
+++ b/Documentation/devicetree/bindings/scsi/hisilicon-sas.txt
@@ -0,0 +1,81 @@
+* HiSilicon SAS controller
+
+The HiSilicon SAS controller supports SAS/SATA.
+
+Main node required properties:
+  - compatible : value should be as follows:
+   (a) "hisilicon,sas-controller-v1" for v1 of HiSilicon SAS controller IP


Please do a more specific compatible string with the SOC part number.
Same versions of IP blocks can have different integration/process
features/bugs.



How about "hisilicon,hip05-sas-v1"?


+  - sas-addr : array of 8 bytes for host SAS address
+  - reg : Address and length of the SAS register
+  - hisilicon,sas-syscon: phandle of syscon used for sas control
+  - ctrl-reset-reg : offset to controller reset register in ctrl reg
+  - ctrl-reset-sts-reg : offset to controller reset status register in ctrl reg
+  - ctrl-clock-ena-reg : offset to controller clock enable register in ctrl reg
+  - queue-count : number of delivery and completion queues in the controller
+  - phy-count : number of phys accessible by the controller
+  - interrupts : Interrupts for phys, completion queues, and fatal
+   sources; the interrupts are ordered in 3 groups, as follows:
+ - Phy interrupts
+ - Completion queue interrupts
+ - Fatal interrupts
+   Phy interrupts : Each phy has 3 interrupt sources:
+   - broadcast
+   - phyup
+   - abnormal
+   The phy interrupts are ordered into groups of 3 per phy
+   (broadcast, phyup, and abnormal) in increasing order.
+   Completion queue interrupts : each completion queue has 1
+   interrupt source. The interrupts are ordered in
+   increasing order.
+   Fatal interrupts : the fatal interrupts are ordered as follows:
+   - ECC
+   - AXI bus
+
+* HiSilicon SAS syscon
+
+Required properties:
+- compatible: should be "hisilicon,sas-ctrl", "syscon"


Please add a more specific compatible here too.


We plan to remove this node now as it will be defined in the platform dt 
bindings:

https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt#n174



Rob


Thanks,
John


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 08/32] scsi: hisi_sas: add hisi_sas_remove

[John Garry]

+int hisi_sas_remove(struct platform_device *pdev)
+{
+   struct sas_ha_struct *sha = platform_get_drvdata(pdev);
+   struct hisi_hba *hisi_hba = sha->lldd_ha;
+
+   sas_unregister_ha(sha);
+   sas_remove_host(sha->core.shost);
+   scsi_remove_host(sha->core.shost);


scsi host should be removed before detaching SAS transport.

See more information:
http://www.spinics.net/lists/linux-scsi/msg90088.html

Thanks,
Wei


OK, I can make this minor change.

Thanks,
John


+   hisi_sas_free(hisi_hba);
+   return 0;
+}
+EXPORT_SYMBOL_GPL(hisi_sas_remove);
+
  static __init int hisi_sas_init(void)
  {
pr_info("hisi_sas: driver version %s\n", DRV_VERSION);




.




--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RESEND] scsi: Set sg_tablesize to 1, for LLDDs that set SG_NONE

[Hannes Reinecke]

On 11/10/2015 11:45 PM, Manoj Kumar wrote:
> Oops while testing blk_mq over the new cxlflash driver.
> 
> [ 2960.817172] Oops: Kernel access of bad area, sig: 11 [#5]
> [ 2960.817309] NIP  __blk_mq_run_hw_queue+0x278/0x4c0
> [ 2960.817313] LR __blk_mq_run_hw_queue+0x2bc/0x4c0
> [ 2960.817314] Call Trace:
> [ 2960.817320] __blk_mq_run_hw_queue+0x2bc/0x4c0 (unreliable)
> [ 2960.817324] blk_mq_run_hw_queue+0xd8/0x100
> [ 2960.817329] blk_mq_insert_requests+0x14c/0x1f0
> [ 2960.817333] blk_mq_flush_plug_list+0x150/0x190
> [ 2960.817338] blk_flush_plug_list+0x11c/0x2b0
> [ 2960.817344] blk_finish_plug+0x58/0x80
> [ 2960.817348] __do_page_cache_readahead+0x1c0/0x2e0
> [ 2960.817352] force_page_cache_readahead+0x68/0xd0
> [ 2960.817356] generic_file_read_iter+0x43c/0x6a0
> [ 2960.817359] blkdev_read_iter+0x68/0xa0
> [ 2960.817361] __vfs_read+0x11c/0x180
> [ 2960.817364] vfs_read+0xa4/0x1c0
> [ 2960.817366] SyS_read+0x6c/0x110
> [ 2960.817369] system_call+0x38/0xb4
> 
> The root cause of the problem was this low level device driver(LLDD),
> in this case cxlflash, does not support scatter-gather and hence had
> set it's sg_tablesize to SG_NONE (value of 0). In reality the tablesize
> is of length 1. This value of SG_NONE does not cause any problems with
> the standard block driver stack but causes issues for blk_mq, as shown
> above. Since quite a few of the legacy LLDDs are setting sg_tablesize
> to SG_NONE, it was preferable to override the LLDD provided value in
> scsi_host_alloc().
> 
> Signed-off-by: Manoj N. Kumar 
> Signed-off-by: Youngjae Lee 
> Reviewed-by: Matthew R. Ochs 
> ---
>  drivers/scsi/hosts.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
> index 8bb173e..bd13c9d 100644
> --- a/drivers/scsi/hosts.c
> +++ b/drivers/scsi/hosts.c
> @@ -413,7 +413,7 @@ struct Scsi_Host *scsi_host_alloc(struct 
> scsi_host_template *sht, int privsize)
>   shost->hostt = sht;
>   shost->this_id = sht->this_id;
>   shost->can_queue = sht->can_queue;
> - shost->sg_tablesize = sht->sg_tablesize;
> + shost->sg_tablesize = (sht->sg_tablesize ? sht->sg_tablesize : 1);
>   shost->sg_prot_tablesize = sht->sg_prot_tablesize;
>   shost->cmd_per_lun = sht->cmd_per_lun;
>   shost->unchecked_isa_dma = sht->unchecked_isa_dma;
> 
Shouldn't we rather fixup blk-mq to properly support SG_NONE?
Silently converting SG_NONE (=0) to 1 has a fair chance of breaking
non-mq enabled setups, which happily work with SG_NONE currently.

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 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 02/32] devicetree: bindings: scsi: HiSi SAS

[Rob Herring]

On Tue, Nov 10, 2015 at 5:09 AM, John Garry  wrote:
> On 09/11/2015 18:01, Rob Herring wrote:
>>
>> On Tue, Nov 10, 2015 at 12:32:07AM +0800, John Garry wrote:
>>>
>>> Add devicetree bindings for HiSilicon SAS driver.
>>>
>>> Signed-off-by: John Garry 
>>> Signed-off-by: Zhangfei Gao 
>>> ---
>>>   .../devicetree/bindings/scsi/hisilicon-sas.txt | 81
>>> ++
>>>   1 file changed, 81 insertions(+)
>>>   create mode 100644
>>> Documentation/devicetree/bindings/scsi/hisilicon-sas.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/scsi/hisilicon-sas.txt
>>> b/Documentation/devicetree/bindings/scsi/hisilicon-sas.txt
>>> new file mode 100644
>>> index 000..2333cc3
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/scsi/hisilicon-sas.txt
>>> @@ -0,0 +1,81 @@
>>> +* HiSilicon SAS controller
>>> +
>>> +The HiSilicon SAS controller supports SAS/SATA.
>>> +
>>> +Main node required properties:
>>> +  - compatible : value should be as follows:
>>> +   (a) "hisilicon,sas-controller-v1" for v1 of HiSilicon SAS
>>> controller IP
>>
>>
>> Please do a more specific compatible string with the SOC part number.
>> Same versions of IP blocks can have different integration/process
>> features/bugs.
>>
>
> How about "hisilicon,hip05-sas-v1"?

That's fine.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [dm-devel] [RFC PATCH 00/32] separate operations from flags in the bio/request structs

[Mike Christie]

On 11/07/2015 04:23 AM, Christoph Hellwig wrote:
> On Wed, Nov 04, 2015 at 10:53:39AM -0600, Mike Christie wrote:
>>> If you have to touch submit_bio() and submit_bio_wait(), how about
>>> requiring the callers of these functions to set the cmd and flags
>>> arguments in the bio structure and to leave out the cmd and flags
>>> arguments from the submit_bio() and submit_bio_wait() functions ? A
>>> (compile tested only) patch that implements this idea is available at
>>> https://lkml.org/lkml/2014/6/2/173.
>>>
>>
>> Yeah, I can do that.
> 
> I think this would be useful to do at the beginning of the series.

I just wanted to double check that we wanted to do this.

We no longer have the bvec merge functions so the original reason given
in the thread/patch Bart referenced is no longer valid.

Offlist it was suggested that dropping the argument from submit_bio
might still improve performance, but I modified xfs and dm and did some
testing and did not see anything.

So the change is not needed, and it would only be done because people
feel it would improve the interface.

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html