Re: [PATCH v3] scsi: sg: Avoid race in error handling & drop bogus warn

[Bart Van Assche]

On 4/1/24 12:10, Alexander Wetzel wrote:

commit 27f58c04a8f4 ("scsi: sg: Avoid sg device teardown race")
introduced an incorrect WARN_ON_ONCE() and missed a sequence where
sg_device_destroy() was used after scsi_device_put().

sg_device_destroy() is accessing the parent scsi_device request_queue which
will already be set to NULL when the preceding call to scsi_device_put()
removed the last reference to the parent scsi_device.

Drop the incorrect WARN_ON_ONCE() - allowing more than one concurrent
access to the sg device - and make sure sg_device_destroy() is not used
after scsi_device_put() in the error handling.


Reviewed-by: Bart Van Assche 

Re: [PATCH v3] scsi: sg: Avoid race in error handling & drop bogus warn

[Bart Van Assche]

On 4/1/24 12:10 PM, Alexander Wetzel wrote:

@@ -301,11 +302,12 @@ sg_open(struct inode *inode, struct file *filp)
  
  	/* This driver's module count bumped by fops_get in  */

/* Prevent the device driver from vanishing while we sleep */
-   retval = scsi_device_get(sdp->device);
+   device = sdp->device;
+   retval = scsi_device_get(device);
if (retval)
goto sg_put;


Are all the sdp->device -> device changes essential? Isn't there a
preference to minimize patches that will end up in the stable trees?

Thanks,

Bart.

Re: [PATCH v2] scsi: sg: Avoid race in error handling & drop bogus warn

[Bart Van Assche]

On 4/1/24 03:03, Alexander Wetzel wrote:

commit 27f58c04a8f4 ("scsi: sg: Avoid sg device teardown race")
introduced an incorrect WARN_ON_ONCE() and missed a sequence where
sg_device_destroy() was used after scsi_device_put().


Isn't that too negative? I think that the WARN_ON_ONCE() mentioned above
has proven to be useful: it helped to catch a bug.


sg_device_destroy() is accessing the parent scsi_device request_queue which
will already be set to NULL when the preceding call to scsi_device_put()
removed the last reference to the parent scsi_device.

Drop the incorrect WARN_ON_ONCE() - allowing more than one concurrent
access to the sg device - and make sure sg_device_destroy() is not used
after scsi_device_put() in the error handling.

Link: 
https://lore.kernel.org/all/5375b275-d137-4d5f-be25-6af8acae4...@linux.ibm.com
Fixes: 27f58c04a8f4 ("scsi: sg: Avoid sg device teardown race")


The "goto sg_put" removed by this patch was introduced by commit
cc833acbee9d ("sg: O_EXCL and other lock handling"). Since the latter
commit is older than the one mentioned above, shouldn't the Fixes tag
refer to the latter commit?


diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index 386981c6976a..833c9277419b 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -372,8 +372,9 @@ sg_open(struct inode *inode, struct file *filp)
  error_out:
scsi_autopm_put_device(sdp->device);
  sdp_put:
+   kref_put(>d_ref, sg_device_destroy);
scsi_device_put(sdp->device);
-   goto sg_put;
+   return retval;
  }


Please add a comment above "return retval" that explains which code will
drop the sg reference.

Thanks,

Bart.

Re: [PATCH 01/34] lib/find: add atomic find_bit() primitives

[Bart Van Assche]

On 11/18/23 07:50, Yury Norov wrote:

Add helpers around test_and_{set,clear}_bit() that allow to search for
clear or set bits and flip them atomically.


Has it been considered to add kunit tests for the new functions?

Thanks,

Bart.

Re: [PATCH 00/34] biops: add atomig find_bit() operations

[Bart Van Assche]

On 11/18/23 07:50, Yury Norov wrote:

Add helpers around test_and_{set,clear}_bit() that allow to search for
clear or set bits and flip them atomically.


There is a typo in the subject: shouldn't "atomig" be changed
into "atomic"?

Thanks,

Bart.

Re: [6.1.0-rc4-next-20221109] Boot time warning kernel/module/main.c:852

[Bart Van Assche]

On 11/10/22 00:01, Sachin Sant wrote:

While booting 6.1.0-rc4-next-20221109 next kernel on a IBM Power9 LPAR
following warning is seen:

[ 8.808868] [ cut here ]
[ 8.808872] WARNING: CPU: 1 PID: 378 at kernel/module/main.c:852 
module_put+0x48/0x100
[ 8.809024] sd 1:0:0:1: [sdc] Write cache: disabled, read cache: enabled, 
supports DPO and FUA
[ 8.809024] LR [c09ee680] scsi_device_put+0x50/0x70
[ 8.809035] Call Trace:
[ 8.809038] [c7c37b10] [c7c37b50] 0xc7c37b50 
(unreliable)
[ 8.809045] [c7c37b50] [c09ee674] scsi_device_put+0x44/0x70
[ 8.809053] [c7c37b80] [c0a10c70] alua_rtpg_work+0x210/0x920
[ 8.809059] [c7c37c90] [c0182314] process_one_work+0x2b4/0x5b0
[ 8.809066] [c7c37d30] [c0182688] worker_thread+0x78/0x600
[ 8.809072] [c7c37dc0] [c018f4f4] kthread+0x124/0x130
[ 8.809079] [c7c37e10] [c000cffc] 
ret_from_kernel_thread+0x5c/0x64
[ 8.809086] Instruction dump:
[ 8.809090] f821ffc1 41820034 395e03c0 7c0004ac 7d205028 2c090001 3929 
41c00010
[ 8.809101] 7d20512d
[ 8.809101] sd 1:0:0:1: [sdc] Preferred minimum I/O size 32768 bytes
[ 8.809102] 40c2ffec 7c0004ac 79290fe2 <0b09> 6000 38210040 ebc1fff0
[ 8.809115] ---[ end trace  ]—

-next-20221108 was good. Git bisect points to following

commit 0b25e17e9018a0ea68a9f0b4787672e8c68fa8d5
Date:   Mon Oct 31 15:47:25 2022 -0700
 scsi: alua: Move a scsi_device_put() call out of alua_check_vpd()

Reverting this patch gets rid of the warning.


Hi Sachin,

Thanks for the detailed report. Does the patch below help?

diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c 
b/drivers/scsi/device_handler/scsi_dh_alua.c
index 693cd827e138..d2cf15338724 100644
--- a/drivers/scsi/device_handler/scsi_dh_alua.c
+++ b/drivers/scsi/device_handler/scsi_dh_alua.c
@@ -1025,7 +1025,7 @@ static bool __must_check alua_rtpg_queue(struct 
alua_port_group *pg,
kref_put(>kref, release_port_group);
}

-   return true;
+   return sdev != NULL;
 }

 /*

Re: [PATCH v2 3/3] arch/*/: remove CONFIG_VIRT_TO_BUS

[Bart Van Assche]

On 6/28/22 16:09, Michael Schmitz wrote:

On 29/06/22 09:50, Arnd Bergmann wrote:
On Tue, Jun 28, 2022 at 11:03 PM Michael Schmitz 
 wrote:

On 28/06/22 19:03, Geert Uytterhoeven wrote:

The driver allocates bounce buffers using kmalloc if it hits an
unaligned data buffer - can such buffers still even happen these days?

No idea.

Hmmm - I think I'll stick a WARN_ONCE() in there so we know whether this
code path is still being used.

kmalloc() guarantees alignment to the next power-of-two size or
KMALLOC_MIN_ALIGN, whichever is bigger. On m68k this means it
is cacheline aligned.


And all SCSI buffers are allocated using kmalloc? No way at all for user 
space to pass unaligned data?


(SCSI is a weird beast - I have used a SCSI DAT tape driver many many 
years ago, which broke all sorts of assumptions about transfer block 
sizes ... but that might actually have been in the v0.99 days, many 
rewrites of SCSI midlevel ago).


Just being cautious, as getting any of this tested will be a stretch.


An example of a user space application that passes an SG I/O data buffer 
to the kernel that is aligned to a four byte boundary but not to an 
eight byte boundary if the -s (scattered) command line option is used: 
https://github.com/osandov/blktests/blob/master/src/discontiguous-io.cpp


Bart.

Re: [PATCH] scsi: ibmvfc: Stop using scsi_cmnd.tag

[Bart Van Assche]

On 8/17/21 6:43 AM, John Garry wrote:
> Use scsi_cmd_to_rq(scsi_cmnd)->tag in preference to scsi_cmnd.tag.

Reviewed-by: Bart Van Assche 

Re: [powerpc][next-20210625] WARN block/mq-deadline-main.c:743 during boot

[Bart Van Assche]

On 6/27/21 6:30 AM, Sachin Sant wrote:
> While booting 5.13.0-rc7-next-20210625 on POWER9 LPAR following warning
> is seen [ ... ]

Please help with testing of the patch that is available at
https://lore.kernel.org/linux-block/2021062722.12720-1-bvanass...@acm.org/T/#u

Thanks,

Bart.

Re: [dm-devel] [PATCH 06/18] bvec: add a bvec_kmap_local helper

[Bart Van Assche]

On 6/15/21 6:24 AM, Christoph Hellwig wrote:
> +/**
> + * bvec_kmap_local - map a bvec into the kernel virtual address space
> + * @bvec: bvec to map
> + *
> + * Must be called on single-page bvecs only.  Call kunmap_local on the 
> returned
> + * address to unmap.
> + */
> +static inline void *bvec_kmap_local(struct bio_vec *bvec)
> +{
> + return kmap_local_page(bvec->bv_page) + bvec->bv_offset;
> +}

Hi Christoph,

Would it be appropriate to add WARN_ON_ONCE(bvec->bv_offset >=
PAGE_SIZE) in this function?

Thanks,

Bart.

Re: [PATCH 08/16] dm-writecache: use bvec_kmap_local instead of bvec_kmap_irq

[Bart Van Assche]

On 6/8/21 9:05 AM, Christoph Hellwig wrote:
> diff --git a/drivers/md/dm-writecache.c b/drivers/md/dm-writecache.c
> index aecc246ade26..93ca454eaca9 100644
> --- a/drivers/md/dm-writecache.c
> +++ b/drivers/md/dm-writecache.c
> @@ -1205,14 +1205,13 @@ static void memcpy_flushcache_optimized(void *dest, 
> void *source, size_t size)
>  static void bio_copy_block(struct dm_writecache *wc, struct bio *bio, void 
> *data)
>  {
>   void *buf;
> - unsigned long flags;
>   unsigned size;
>   int rw = bio_data_dir(bio);
>   unsigned remaining_size = wc->block_size;
>  
>   do {
>   struct bio_vec bv = bio_iter_iovec(bio, bio->bi_iter);
> - buf = bvec_kmap_irq(, );
> + buf = bvec_kmap_local();
>   size = bv.bv_len;
>   if (unlikely(size > remaining_size))
>   size = remaining_size;
> @@ -1230,7 +1229,7 @@ static void bio_copy_block(struct dm_writecache *wc, 
> struct bio *bio, void *data
>   memcpy_flushcache_optimized(data, buf, size);
>   }
>  
> - bvec_kunmap_irq(buf, );
> + kunmap_local(buf);
>  
>   data = (char *)data + size;
>   remaining_size -= size;

>From one of the functions called by kunmap_local():

unsigned long addr = (unsigned long) vaddr & PAGE_MASK;

This won't work well if bvec->bv_offset >= PAGE_SIZE I assume?

Thanks,

Bart.

Re: [PATCH 03/16] bvec: fix the include guards for bvec.h

[Bart Van Assche]

On 6/8/21 9:05 AM, Christoph Hellwig wrote:
> Fix the include guards to match the file naming.

Reviewed-by: Bart Van Assche 

Re: [PATCH 02/16] MIPS: don't include in

[Bart Van Assche]

On 6/8/21 9:05 AM, Christoph Hellwig wrote:
> There is no need to include genhd.h from a random arch header, and not
> doing so prevents the possibility for nasty include loops.
> 
> Signed-off-by: Christoph Hellwig 
> ---
>  arch/mips/include/asm/mach-rc32434/rb.h | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/arch/mips/include/asm/mach-rc32434/rb.h 
> b/arch/mips/include/asm/mach-rc32434/rb.h
> index d502673a4f6c..34d179ca020b 100644
> --- a/arch/mips/include/asm/mach-rc32434/rb.h
> +++ b/arch/mips/include/asm/mach-rc32434/rb.h
> @@ -7,8 +7,6 @@
>  #ifndef __ASM_RC32434_RB_H
>  #define __ASM_RC32434_RB_H
>  
> -#include 
> -
>  #define REGBASE  0x1800
>  #define IDT434_REG_BASE ((volatile void *) KSEG1ADDR(REGBASE))
>  #define UART0BASE0x58000

Reviewed-by: Bart Van Assche 

Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver

[Bart Van Assche]

On 1/4/21 2:50 PM, Finn Thain wrote:
> On Mon, 4 Jan 2021, Bart Van Assche wrote:
>> Additionally, there is a good alternative available for the sbp driver. 
>> Every system I know of that is equipped with a Firewire port also has an 
>> Ethernet port. So users who want to provide SCSI target functionality on 
>> such systems can use any SCSI transport protocol that is compatible with 
>> Ethernet (iSCSI, iSER over soft-RoCE, SRP over soft-RoCE, ...).
> 
> Ethernet is not always an alternative. That was already discussed in this 
> thread. But let's assume for a moment that you can migrate any and all 
> users of this driver over to an ethernet driver.
> 
> Why would the maintainers of that Ethernet driver and its API accept that 
> plan, if adding users would extend their maintenance and testing 
> obligations? Do you think those maintainers should pay the "kind of tax 
> that all developers/users pay to all developers/users?"

Hi Finn,

I cannot speak in the name of the iSCSI over TCP/IP or iSER driver
maintainers. But since I maintain the SRP initiator and target kernel
drivers myself, I can state that I would be happy to help SBP target users
(if that driver has any users today) to switch from SCSI over Firewire to
SCSI over SRP over RoCE or even NVMEoF over TCP.

Thanks,

Bart.

Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver

[Bart Van Assche]

On 6/16/20 7:07 PM, Finn Thain wrote:
> On Tue, 16 Jun 2020, Bart Van Assche wrote:
>> As far as I know the sbp driver only has had one user ever and that user 
>> is no longer user the sbp driver.
> 
> So, you estimate the userbase at zero. Can you give a confidence level? 
> Actual measurement is hard because when end users encounter breakage, they 
> look for quick workarounds before they undertake post mortem, log 
> collection, bug reporting, mailing list discussions, analysis etc.

(replying to an e-mail from six months ago)

Hi Finn,

I am confident that my estimate is an accurate estimate since I have not
seen any sbp support requests, sbp bug reports nor any sbp bug fixes since
the sbp target driver has been accepted upstream.

> Here's a different question: "Why remove it from the kernel tree?"
> 
> If maintaining this code is a burden, is it not the kind of tax that all 
> developers/users pay to all developers/users? Does this driver impose an 
> unreasonably high burden for some reason?

Yes. If anyone wants to change the interface between SCSI target core and
SCSI target drivers, all target drivers, including the sbp and FCoE target
driver have to be retested. In other words, keeping unused target drivers
inside the kernel tree involves a significant maintenance burden for anyone
who wants to modify the interface between the SCSI target core and SCSI
target drivers.

Additionally, there is a good alternative available for the sbp driver.
Every system I know of that is equipped with a Firewire port also has an
Ethernet port. So users who want to provide SCSI target functionality on
such systems can use any SCSI transport protocol that is compatible with
Ethernet (iSCSI, iSER over soft-RoCE, SRP over soft-RoCE, ...).

Thanks,

Bart.

Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver

[Bart Van Assche]

On 2020-06-16 02:42, Finn Thain wrote:
> Martin said, "I'd appreciate a patch to remove it"
> 
> And Bart said, "do you want to keep this driver in the kernel tree?"
> 
> AFAICT both comments are quite ambiguous. I don't see an actionable 
> request, just an expression of interest from people doing their jobs.
> 
> Note well: there is no pay check associated with having a MAINTAINERS file 
> entry.

Hi Finn,

As far as I know the sbp driver only has had one user ever and that user
is no longer user the sbp driver. So why to keep it in the kernel tree?
Restoring a kernel driver can be easy - the first step is a "git revert".

Thanks,

Bart.

Re: lockdep warning while booting POWER9 PowerNV

[Bart Van Assche]

On 8/30/19 2:13 PM, Qian Cai wrote:

https://raw.githubusercontent.com/cailca/linux-mm/master/powerpc.config

Once in a while, booting an IBM POWER9 PowerNV system (8335-GTH) would generate
a warning in lockdep_register_key() at,

if (WARN_ON_ONCE(static_obj(key)))

because

key = 0xc19ad118
&_stext = 0xc000
&_end = 0xc49d

i.e., it will cause static_obj() returns 1.


(back from a trip)

Hi Qian,

Does this mean that on POWER9 it can happen that a dynamically allocated 
object has an address that falls between &_stext and &_end? Since I am 
not familiar with POWER9 nor have access to such a system, can you 
propose a patch?


Thanks,

Bart.

Re: [5.3.0-rc4-next][bisected 882632][qla2xxx] WARNING: CPU: 10 PID: 425 at drivers/scsi/qla2xxx/qla_isr.c:2784 qla2x00_status_entry.isra

[Bart Van Assche]

On 8/14/19 10:18 AM, Abdul Haleem wrote:

On Wed, 2019-08-14 at 10:05 -0700, Bart Van Assche wrote:

On 8/14/19 9:52 AM, Abdul Haleem wrote:

Greeting's

Today's linux-next kernel (5.3.0-rc4-next-20190813)  booted with warning on my 
powerpc power 8 lpar

The WARN_ON_ONCE() was introduced by commit 88263208 (scsi: qla2xxx: Complain if 
sp->done() is not...)

boot logs:

WARNING: CPU: 10 PID: 425 at drivers/scsi/qla2xxx/qla_isr.c:2784


Hi Abdul,

Thank you for having reported this. Is that the only warning reported on your 
setup by the qla2xxx
driver? If that warning is commented out, does the qla2xxx driver work as 
expected?


boot warning did not show up when the commit is reverted.

should I comment out only the WARN_ON_ONCE() which is causing the issue,
and not the other one ?


Yes please. Commit 88263208 introduced five kernel warnings but I think 
only one of these should be removed again, e.g. as follows:


diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c
index cd39ac18c5fd..d81b5ecce24b 100644
--- a/drivers/scsi/qla2xxx/qla_isr.c
+++ b/drivers/scsi/qla2xxx/qla_isr.c
@@ -2780,8 +2780,6 @@ qla2x00_status_entry(scsi_qla_host_t *vha, struct 
rsp_que *rsp, void *pkt)


if (rsp->status_srb == NULL)
sp->done(sp, res);
-   else
-   WARN_ON_ONCE(true);
 }

 /**

Re: [5.3.0-rc4-next][bisected 882632][qla2xxx] WARNING: CPU: 10 PID: 425 at drivers/scsi/qla2xxx/qla_isr.c:2784 qla2x00_status_entry.isra

[Bart Van Assche]

On 8/14/19 9:52 AM, Abdul Haleem wrote:
> Greeting's
> 
> Today's linux-next kernel (5.3.0-rc4-next-20190813)  booted with warning on 
> my powerpc power 8 lpar
> 
> The WARN_ON_ONCE() was introduced by commit 88263208 (scsi: qla2xxx: Complain 
> if sp->done() is not...)
> 
> boot logs:
> 
> WARNING: CPU: 10 PID: 425 at drivers/scsi/qla2xxx/qla_isr.c:2784

Hi Abdul,

Thank you for having reported this. Is that the only warning reported on your 
setup by the qla2xxx
driver? If that warning is commented out, does the qla2xxx driver work as 
expected?

Thanks,

Bart.

Re: [PATCH v3 03/24] drivers/block/z2ram: use ioremap_wt() instead of __ioremap(_PAGE_WRITETHRU)

[Bart Van Assche]

On Tue, 2018-10-09 at 13:51 +, Christophe Leroy wrote:
> _PAGE_WRITETHRU is a target specific flag. Prefer generic functions.
> 
> Acked-by: Geert Uytterhoeven 
> Signed-off-by: Christophe Leroy 

Hi Geert,

All patches that have been applied to this driver since 2005 are API refactoring
patches. I haven't found any patches in the history of this driver that seem to
have been submitted by a user of this driver. Do you perhaps know whether anyone
is using this driver?

Thanks,

Bart.

Re: [4.18.0-rc4][bisected a063057d][mpt3sas] WARNING: CPU: 87 PID: 18868 at block/blk-core.c:781 blk_cleanup_queue+0x20c/0x220

[Bart Van Assche]

On Mon, 2018-07-16 at 14:23 +0530, Abdul Haleem wrote:
> mpt3sas module unload triggered a warning at block/blk-core.c:781 on a
> powerpc bare-metal running mainline kernel
> 
> WARN_ON_ONCE() was introduced with commit a063057 : block: Fix a race
> between request queue removal and the block cgroup controller

Please check whether the following patch series fixes this regression: [PATCH
v3 0/2] Ensure that a request queue is dissociated from the cgroup controller
(https://www.mail-archive.com/linux-block@vger.kernel.org/msg21897.html).

Thanks,

Bart.

Re: Fwd: [powerpc/Baremetal]Kernel OOPS while executing memory hotplug on Power8 baremetal

[Bart Van Assche]

On Thu, 2018-06-07 at 12:56 +0530, Venkat Rao B wrote:
> On Thursday 07 June 2018 12:46 PM, Bart Van Assche wrote:
> > On Thu, 2018-06-07 at 12:38 +0530, vrbagal1 wrote:
> > > Observing Kernel oops and machine reboots while executing memory hotplug
> > > test case, on Power8 Baremetal machine.
> > > 
> > > I see this is introduced some where between rc6 and 4.17.
> > 
> > Please provide the exact versions (git commit IDs) of the kernel versions
> > you have tested.
> 
> Commit Id ---> 5037be168f

The reason I was asking for the commit ID is because I saw that clone_endio()
occurs in the oops which means that the dm driver is involved. An important fix
for the dm driver went upstream recently, namely d37753540568 ("dm: Use kzalloc
for all structs with embedded biosets/mempools"). Can you double check whether
that commit it present in your tree? If it is not present, please update to the
latest master and retest. If it is present, please report how to reproduce
this oops to Kent Overstreet, Jens Axboe, linux-block and Mike Snitzer.

Thanks,

Bart.

Re: Fwd: [powerpc/Baremetal]Kernel OOPS while executing memory hotplug on Power8 baremetal

[Bart Van Assche]

On Thu, 2018-06-07 at 12:38 +0530, vrbagal1 wrote:
> Observing Kernel oops and machine reboots while executing memory hotplug 
> test case, on Power8 Baremetal machine.
> 
> I see this is introduced some where between rc6 and 4.17.

Please provide the exact versions (git commit IDs) of the kernel versions
you have tested.

Thanks,

Bart.

Re: [linux-next][qla2xxx][85caa95]kernel BUG at lib/list_debug.c:31!

[Bart Van Assche]

On Tue, 2018-01-09 at 14:44 +0530, Abdul Haleem wrote:
> Greeting's, 
> 
> Linux next kernel panics on powerpc when module qla2xxx is load/unload.
> 
> Machine Type: Power 8 PowerVM LPAR
> Kernel : 4.15.0-rc2-next-20171211
> gcc : version 4.8.5
> Test type: module load/unload few times
> 
> Trace messages:
> ---
> qla2xxx [:00:00.0]-0005: : QLogic Fibre Channel HBA Driver: 10.00.00.03-k.
> qla2xxx [0106:a0:00.0]-001a: : MSI-X vector count: 32.
> qla2xxx [0106:a0:00.0]-001d: : Found an ISP2532 irq 505 iobase 
> 0xaeb324e6.
> qla2xxx [0106:a0:00.0]-00c6:1: MSI-X: Failed to enable support with 32 
> vectors, using 16 vectors.
> qla2xxx [0106:a0:00.0]-00fb:1: QLogic QLE2562 - PCIe 2-port 8Gb FC Adapter.
> qla2xxx [0106:a0:00.0]-00fc:1: ISP2532: PCIe (5.0GT/s x8) @ 0106:a0:00.0 
> hdma- host#=1 fw=8.06.00 (90d5).
> qla2xxx [0106:a0:00.1]-001a: : MSI-X vector count: 32.
> qla2xxx [0106:a0:00.1]-001d: : Found an ISP2532 irq 506 iobase 
> 0xa46f1774.
> qla2xxx [0106:a0:00.1]-00c6:2: MSI-X: Failed to enable support with 32 
> vectors, using 16 vectors.
> 2xxx
> qla2xxx [0106:a0:00.1]-00fb:2: QLogic QLE2562 - PCIe 2-port 8Gb FC Adapter.
> qla2xxx [0106:a0:00.1]-00fc:2: ISP2532: PCIe (5.0GT/s x8) @ 0106:a0:00.1 
> hdma- host#=2 fw=8.06.00 (90d5).
> 0:00.0]-500a:1: LOOP UP detected (8 Gbps). 
> qla2xxx [0106:a0:00.1]-500a:2: LOOP UP detected (8 Gbps).
> list_add double add: new=8d33e594, prev=8d33e594, 
> next=adef1df4.
> [ cut here ]
> kernel BUG at lib/list_debug.c:31! 
> Oops: Exception in kernel mode, sig: 5 [#1]
> LE SMP NR_CPUS=2048 NUMA pSeries 
> Dumping ftrace buffer: 
>(ftrace buffer empty)
> Modules linked in: qla2xxx(E) tg3(E) ibmveth(E) xt_CHECKSUM(E)
> iptable_mangle(E) ipt_MASQUERADE(E) nf_nat_masquerade_ipv4(E)
> iptable_nat(E) nf_nat_ipv4(E) nf_nat(E) nf_conntrack_ipv4(E)
> nf_defrag_ipv4(E) xt_conntrack(E) nf_conntrack(E) ipt_REJECT(E)
> nf_reject_ipv4(E) tun(E) bridge(E) stp(E) llc(E) kvm_pr(E) kvm(E)
> sctp_diag(E) sctp(E) libcrc32c(E) tcp_diag(E) udp_diag(E)
> ebtable_filter(E) ebtables(E) dccp_diag(E) ip6table_filter(E) dccp(E)
> ip6_tables(E) iptable_filter(E) inet_diag(E) unix_diag(E)
> af_packet_diag(E) netlink_diag(E) xts(E) sg(E) vmx_crypto(E)
> pseries_rng(E) nfsd(E) auth_rpcgss(E) nfs_acl(E) lockd(E) grace(E)
> sunrpc(E) binfmt_misc(E) ip_tables(E) ext4(E) mbcache(E) jbd2(E)
> fscrypto(E) sd_mod(E) ibmvscsi(E) scsi_transport_srp(E) nvme_fc(E)
> nvme_fabrics(E) nvme_core(E) scsi_transport_fc(E)
>  ptp(E) pps_core(E) dm_mirror(E) dm_region_hash(E) dm_log(E) dm_mod(E)
> [last unloaded: qla2xxx]
> CPU: 7 PID: 22230 Comm: qla2xxx_1_dpc Tainted: GE
> 4.15.0-rc2-next-20171211-autotest-autotest #1
> NIP:  c0511040 LR: c051103c CTR: 00655170
> REGS: 9b7356fa TRAP: 0700   Tainted: GE 
> (4.15.0-rc2-next-20171211-autotest-autotest)
> MSR:  80010282b033   CR: 2222  
> XER: 0009  
> CFAR: c0170594 SOFTE: 0 
> GPR00: c051103c c000fc293ac0 c10f1d00 0058 
> GPR04: c0028fcccdd0 c0028fce3798 8000374060b8  
> GPR08:  c0d435ec 00028ef9 2717 
> GPR12:  ce734980 c01215d8 c002886996c0 
> GPR16:  0020 c002813d83f8 0001 
> GPR20: 2000 2000 0002 c002813dc808 
> GPR24: 0003 0001 c0027f5a5c20 c002813dced0 
> GPR28: c0027f5a5d90 c0027f5a5d90 c0027f5a5c00 c002813dc7f8 
> NIP [c0511040] __list_add_valid+0x70/0xb0
> LR [c051103c] __list_add_valid+0x6c/0xb0
> Call Trace:
> [c000fc293ac0] [c051103c] __list_add_valid+0x6c/0xb0 (unreliable)
> [c000fc293b20] [d51f1a08] qla24xx_async_gnl+0x108/0x420 [qla2xxx]
> [c000fc293bc0] [d51e762c] qla2x00_do_work+0x18c/0x8c0 [qla2xxx]
> [c000fc293ce0] [d51e8180] qla2x00_relogin+0x420/0xff0 [qla2xxx]
> [c000fc293dc0] [c012172c] kthread+0x15c/0x1a0
> [c000fc293e30] [c000b4e8] ret_from_kernel_thread+0x5c/0x74
> Instruction dump:
> 41de0018 38210060 3861 e8010010 7c0803a6 4e800020 3c62ffae 7d445378 
> 38631748 7d254b78 4bc5f51d 6000 <0fe0> 3c62ffae 7cc43378 386316f8 
> ---[ end trace a41bc8bd434657f1 ]---
> 
> Kernel panic - not syncing: Fatal exception
> Dumping ftrace buffer: 
>(ftrace buffer empty)
> Rebooting in 10 seconds..
> 
> This trace back to the below code path:
> 
> # gdb -batch vmlinux -ex 'list *(0xc0511040)'
> 0xc0511040 is in __list_add_valid (lib/list_debug.c:29).
> 24"list_add corruption. next->prev should be prev 
> (%p), but was %p. (next=%p).\n",
> 25prev, next->prev, next) ||
> 26

Re: [BUG][bisected 270065e] linux-next fails to boot on powerpc

[Bart Van Assche]

On Fri, 2017-08-18 at 16:57 -0500, Brian King wrote:
> To add to my analysis above, #9 should not be there... It looks like
> jiffies_at_alloc would also be getting reinitialized in this case, resulting 
> in
> a perpetual retry, which is what I was seeing.

Hello Brian,

Some time ago I noticed that jiffies_at_alloc is indeed set while a command
is being prepared instead of at command allocation time. I think that
behavior was introduced in 2005 through commit b21a41385118 ("[SCSI] add
global timeout to the scsi mid-layer"). At that time SCSI commands were
allocated at prep time and freed at unprep time. Recently that has been
changed such that a SCSI command (struct scsi_cmnd) has the same lifetime as
struct request. In other words, it was not possible in 2005 but it is
possible today to set jiffies_at_alloc at command allocation time instead of
when a command is being prepared. Do you want me to submit a patch that
implements this change?

Bart.

Re: [BUG][bisected 270065e] linux-next fails to boot on powerpc

[Bart Van Assche]

On Fri, 2017-08-18 at 16:04 -0500, Brian King wrote:
> I think I have an understanding what is going on and why Bart's patch is 
> causing problems for ipr.
> I can work around the boot hang in ipr, but ultimately I think we need to 
> figure out a fix
> in scsi / block. I added some tracing and confirmed its not a matter of 
> commands getting stuck
> in ipr. The issue is we are retrying failed commands until we finally run out 
> of time. This is
> what I see:
> 
> 1. sd_revalidate_disk calls scsi_report_opcode
> 2. ipr RAID arrays don't support MAINTENANCE_IN / 
> MI_REPORT_SUPPORTED_OPERATION_CODES
> 3. ipr returns the command with DID_ERROR
> 4. scsi_decide_disposition goes to maybe_retry, increments scmd->retries, and 
> returns NEEDS_RETRY
> 5. scsi_softirq_done calls scsi_queue_insert to requeue the command, which 
> calls scsi_mq_requeue_cmd
> 6. With Bart's change, we then clear RQF_DONTPREP in this path, while prior 
> we did not
> 7. This results in the command getting scmd->retries zeroed out when it gets 
> re-queued,
>since we go through prep again and we lose our retry counter, resulting in 
> lots and lots of retries.
> 8. Since the default command timeout for an ipr RAID array is 120 seconds, 
> these retries go on for
>quite a long time...
> 9. Finally, the command has been retried so long we trip over the overall 
> retry timer
>in scsi_softirq_done and we timeout the command.
> 
> I'll follow up with a patch to ipr to workaround the hang, but I think we 
> need to somehow preserve
> the retry counter in the scsi command, as this will likely cause issues with 
> other drivers. 

Hello Brian,

Thanks for the detailed analysis. This is very helpful. Have you considered
to change the ipr driver such that it terminates REPORT SUPPORTED OPERATION
CODES commands with the appropriate check condition code instead of DID_ERROR?

Thanks,

Bart.

Re: [BUG][bisected 270065e] linux-next fails to boot on powerpc

[Bart Van Assche]

On Wed, 2017-08-16 at 18:18 -0500, Brian King wrote:
> On 08/16/2017 12:21 PM, Bart Van Assche wrote:
> > On Wed, 2017-08-16 at 22:30 +0530, Abdul Haleem wrote:
> > > As of next-20170809, linux-next on powerpc boot hung with below trace
> > > message.
> > > 
> > > [ ... ]
> > > 
> > > A bisection resulted in first bad commit (270065e92 - scsi: scsi-mq:
> > > Always unprepare ...) in the merge branch 'scsi/for-next'
> > > 
> > > System booted fine when the below commit is reverted: 
> > > 
> > > commit 270065e92c317845d69095ec8e3d18616b5b39d5
> > > Author: Bart Van Assche <bart.vanass...@wdc.com>
> > > Date:   Thu Aug 3 14:40:14 2017 -0700
> > > 
> > > scsi: scsi-mq: Always unprepare before requeuing a request
> > 
> > Hello Brian and Michael,
> > 
> > Do you agree that this probably indicates a bug in the PowerPC block driver
> > that is used to access the boot disk? Anyway, since a solution is not yet
> > available, I will submit a revert for this patch.
> 
> I've been looking at this a bit, and can recreate the issue, but haven't
> got to root cause of the issue as of yet. If I do a sysrq-w while the system 
> is hung
> during boot I see this:
> 
> [   25.561523] Workqueue: events_unbound async_run_entry_fn
> [   25.561527] Call Trace:
> [   25.561529] [c001697873f0] [c00169701600] 0xc00169701600 
> (unreliable)
> [   25.561534] [c001697875c0] [c001ab78] __switch_to+0x2e8/0x430
> [   25.561539] [c00169787620] [c091ccb0] __schedule+0x310/0xa00
> [   25.561543] [c001697876f0] [c091d3e0] schedule+0x40/0xb0
> [   25.561548] [c00169787720] [c0921e40] 
> schedule_timeout+0x200/0x430
> [   25.561553] [c00169787810] [c091db10] 
> io_schedule_timeout+0x30/0x70
> [   25.561558] [c00169787840] [c091e978] 
> wait_for_common_io.constprop.3+0x178/0x280
> [   25.561563] [c001697878c0] [c047f7ec] blk_execute_rq+0x7c/0xd0
> [   25.561567] [c00169787910] [c0614cd0] scsi_execute+0x100/0x230
> [   25.561572] [c00169787990] [c060d29c] 
> scsi_report_opcode+0xbc/0x170
> [   25.561577] [c00169787a50] [d4fe6404] 
> sd_revalidate_disk+0xe04/0x1620 [sd_mod]
> [   25.561583] [c00169787b80] [d4fe6d84] 
> sd_probe_async+0xb4/0x230 [sd_mod]
> [   25.561588] [c00169787c00] [c010fc44] 
> async_run_entry_fn+0x74/0x210
> [   25.561593] [c00169787c90] [c0102f48] 
> process_one_work+0x198/0x480
> [   25.561598] [c00169787d30] [c01032b8] worker_thread+0x88/0x510
> [   25.561603] [c00169787dc0] [c010b030] kthread+0x160/0x1a0
> [   25.561608] [c00169787e30] [c000b3a4] 
> ret_from_kernel_thread+0x5c/0xb8
> 
> I was noticing that we are commonly in scsi_report_opcode. Since ipr RAID 
> arrays don't support
> the MAINTENANCE_IN / MI_REPORT_SUPPORTED_OPERATION_CODES, I tried setting 
> sdev->no_report_opcodes = 1
> in ipr's slave configure. This seems to eliminate the boot hang for me, but 
> is only working around
> the issue. Since this command is not supported by ipr, it should return with 
> an illegal request.
> When I'm hung at this point, there is nothing outstanding to the adapter / 
> driver. I'll continue
> debugging...

(+linux-scsi)

Hello Brian,

Is kernel debugging enabled on your test system? Is lockdep enabled?
Anyway, stack traces like the above usually mean that a request got stuck in
a block or scsi driver (ipr in this case). Information about pending requests,
including the SCSI CDB, is available under /sys/kernel/debug/block (see also
commit 0eebd005dd07 ("scsi: Implement blk_mq_ops.show_rq()")).

Bart.

Re: WARNING: CPU: 15 PID: 0 at block/blk-mq.c:1111 __blk_mq_run_hw_queue+0x1d8/0x1f0

[Bart Van Assche]

On Wed, 2017-08-16 at 15:10 -0500, Brian King wrote:
> On 08/16/2017 01:15 PM, Bart Van Assche wrote:
> > On Wed, 2017-08-16 at 23:37 +0530, Abdul Haleem wrote:
> > > Linux-next booted with the below warnings on powerpc
> > > 
> > > [ ... ]
> > > 
> > > boot warnings:
> > > --
> > > kvm: exiting hardware virtualization
> > > [ cut here ]
> > > WARNING: CPU: 15 PID: 0 at block/blk-mq.c: __blk_mq_run_hw_queue
> > > +0x1d8/0x1f0
> > > Modules linked in: iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4
> > > Call Trace:
> > > [c0037990] [c088f7b0] __blk_mq_delay_run_hw_queue
> > > +0x1f0/0x210
> > > [c00379d0] [c088fcb8] blk_mq_start_hw_queue+0x58/0x80
> > > [c00379f0] [c088fd40] blk_mq_start_hw_queues+0x60/0xb0
> > > [c0037a30] [c0ae2b54] scsi_kick_queue+0x34/0xa0
> > > [c0037a50] [c0ae2f70] scsi_run_queue+0x3b0/0x660
> > > [c0037ac0] [c0ae7ed4] scsi_run_host_queues+0x64/0xc0
> > > [c0037b00] [c0ae7f64] scsi_unblock_requests+0x34/0x60
> > > [c0037b20] [c0b14998] ipr_ioa_bringdown_done+0xf8/0x3a0
> > > [c0037bc0] [c0b12528] ipr_reset_ioa_job+0xd8/0x170
> > > [c0037c00] [c0b18790] ipr_reset_timer_done+0x110/0x160
> > > [c0037c50] [c024db50] call_timer_fn+0xa0/0x3a0
> > > [c0037ce0] [c024e058] expire_timers+0x1b8/0x350
> > > [c0037d50] [c024e2f0] run_timer_softirq+0x100/0x3e0
> > > [c0037df0] [c0162edc] __do_softirq+0x20c/0x620
> > > [c0037ee0] [c0163a80] irq_exit+0x230/0x290
> > > [c0037f10] [c001d770] __do_irq+0x170/0x410
> > > [c0037f90] [c003ea20] call_do_irq+0x14/0x24
> > > [c007f84e3a70] [c001dae0] do_IRQ+0xd0/0x190
> > > [c007f84e3ac0] [c0008c58] hardware_interrupt_common
> > > +0x158/0x160
> > 
> > Hello Brian,
> > 
> > In the MAINTAINERS file I found the following:
> > 
> > IBM Power Linux RAID adapter
> > M:  Brian King <brk...@us.ibm.com>
> > S:  Supported
> > F:  drivers/scsi/ipr.*
> > 
> > Is that information up-to-date? Do you agree that the above message 
> > indicates
> > a bug in the ipr driver?
> 
> Yes. Can you try with this patch that is in 4.13/scsi-fixes:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/commit/?h=4.13/scsi-fixes=b0e17a9b0df29590c45dfb296f541270a5941f41

Hello Brian,

Sorry but I don't have access to a setup on which I can test the ipr driver ...

Bart.

Re: [BUG][bisected 270065e] linux-next fails to boot on powerpc

[Bart Van Assche]

On Wed, 2017-08-16 at 22:30 +0530, Abdul Haleem wrote:
> As of next-20170809, linux-next on powerpc boot hung with below trace
> message.
> [ ... ]
> System booted fine when the below commit is reverted: 

Hello Abdul,

Can you check whether applying the following commit on top of next-20170809
fixes this regression:

https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/commit/?h=4.13/scsi-fixes=b0e17a9b0df29590c45dfb296f541270a5941f41

Thanks,

Bart.

Re: WARNING: CPU: 15 PID: 0 at block/blk-mq.c:1111 __blk_mq_run_hw_queue+0x1d8/0x1f0

[Bart Van Assche]

On Wed, 2017-08-16 at 23:37 +0530, Abdul Haleem wrote:
> Linux-next booted with the below warnings on powerpc
> 
> [ ... ]
> 
> boot warnings:
> --
> kvm: exiting hardware virtualization
> [ cut here ]
> WARNING: CPU: 15 PID: 0 at block/blk-mq.c: __blk_mq_run_hw_queue
> +0x1d8/0x1f0
> Modules linked in: iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4
> Call Trace:
> [c0037990] [c088f7b0] __blk_mq_delay_run_hw_queue
> +0x1f0/0x210
> [c00379d0] [c088fcb8] blk_mq_start_hw_queue+0x58/0x80
> [c00379f0] [c088fd40] blk_mq_start_hw_queues+0x60/0xb0
> [c0037a30] [c0ae2b54] scsi_kick_queue+0x34/0xa0
> [c0037a50] [c0ae2f70] scsi_run_queue+0x3b0/0x660
> [c0037ac0] [c0ae7ed4] scsi_run_host_queues+0x64/0xc0
> [c0037b00] [c0ae7f64] scsi_unblock_requests+0x34/0x60
> [c0037b20] [c0b14998] ipr_ioa_bringdown_done+0xf8/0x3a0
> [c0037bc0] [c0b12528] ipr_reset_ioa_job+0xd8/0x170
> [c0037c00] [c0b18790] ipr_reset_timer_done+0x110/0x160
> [c0037c50] [c024db50] call_timer_fn+0xa0/0x3a0
> [c0037ce0] [c024e058] expire_timers+0x1b8/0x350
> [c0037d50] [c024e2f0] run_timer_softirq+0x100/0x3e0
> [c0037df0] [c0162edc] __do_softirq+0x20c/0x620
> [c0037ee0] [c0163a80] irq_exit+0x230/0x290
> [c0037f10] [c001d770] __do_irq+0x170/0x410
> [c0037f90] [c003ea20] call_do_irq+0x14/0x24
> [c007f84e3a70] [c001dae0] do_IRQ+0xd0/0x190
> [c007f84e3ac0] [c0008c58] hardware_interrupt_common
> +0x158/0x160

Hello Brian,

In the MAINTAINERS file I found the following:

IBM Power Linux RAID adapter
M:  Brian King 
S:  Supported
F:  drivers/scsi/ipr.*

Is that information up-to-date? Do you agree that the above message indicates
a bug in the ipr driver?

Thanks,

Bart.

Re: [BUG][bisected 270065e] linux-next fails to boot on powerpc

[Bart Van Assche]

On Wed, 2017-08-16 at 22:30 +0530, Abdul Haleem wrote:
> As of next-20170809, linux-next on powerpc boot hung with below trace
> message.
> 
> [ ... ]
> 
> A bisection resulted in first bad commit (270065e92 - scsi: scsi-mq:
> Always unprepare ...) in the merge branch 'scsi/for-next'
> 
> System booted fine when the below commit is reverted: 
> 
> commit 270065e92c317845d69095ec8e3d18616b5b39d5
> Author: Bart Van Assche <bart.vanass...@wdc.com>
> Date:   Thu Aug 3 14:40:14 2017 -0700
> 
> scsi: scsi-mq: Always unprepare before requeuing a request

Hello Brian and Michael,

Do you agree that this probably indicates a bug in the PowerPC block driver
that is used to access the boot disk? Anyway, since a solution is not yet
available, I will submit a revert for this patch.

Bart.

Re: blk_mq_sched_insert_request: inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage

[Bart Van Assche]

On Fri, 2017-07-28 at 08:25 -0600, Jens Axboe wrote:
> On 07/28/2017 12:19 AM, Michael Ellerman wrote:
> > OK, so the resolution is "fix it in IPR" ?
> 
> I'll leave that to the SCSI crew. But at least one bug is in IPR, if you
> look at the call trace:
> 
> - timer function triggers, runs ipr_reset_timer_done(), which grabs the
>   host lock AND disables interrupts.
> - further down in the call path, ipr_ioa_bringdown_done() uncondtionally
>   enables interrupts:
> 
> spin_unlock_irq(ioa_cfg->host->host_lock);
> scsi_unblock_requests(ioa_cfg->host);
> spin_lock_irq(ioa_cfg->host->host_lock); 
> 
> And the call to scsi_unblock_requests() is the one that ultimately runs
> the queue. The IRQ issue aside here, scsi_unblock_requests() could run
> the queue async, and we could retain the normal sync run otherwise.
> 
> Can you try the below fix? Should be more palatable than the previous
> one. Brian, maybe you can take a look at the IRQ issue mentioned above?
> 
> [ ... ]

Hello Jens,

Are there other block drivers that can call blk_mq_start_hw_queues() from
interrupt context? I'm currently working on converting the skd driver
(drivers/block/skd_main.c) from a single queue block driver into a scsi-mq
driver. The skd driver calls blk_start_queue() from interrupt context. As we
know it is not safe to call blk_mq_start_hw_queues() from interrupt context.
Can you recommend me how I should proceed: should I implement a solution in
the skd driver or should perhaps the blk-mq core be modified?

Thanks,

Bart.

Re: blk_mq_sched_insert_request: inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage

[Bart Van Assche]

On Thu, 2017-07-27 at 08:02 -0600, Jens Axboe wrote:
> The bug looks like SCSI running the queue inline from IRQ
> context, that's not a good idea. Can you confirm the below works for
> you?
> 
> 
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index f6097b89d5d3..78740ebf966c 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -497,7 +497,7 @@ static void scsi_run_queue(struct request_queue *q)
>   scsi_starved_list_run(sdev->host);
>  
>   if (q->mq_ops)
> - blk_mq_run_hw_queues(q, false);
> + blk_mq_run_hw_queues(q, true);
>   else
>   blk_run_queue(q);
>  }

Hello Jens,

scsi_run_queue() works fine if no scheduler is configured. Additionally, that
code predates the introduction of blk-mq I/O schedulers. I think it is
nontrivial for block driver authors to figure out that a queue has to be run
from process context if a scheduler has been configured that does not support
to be run from interrupt context. How about adding WARN_ON_ONCE(in_interrupt())
to blk_mq_start_hw_queue() or replacing the above patch by the following:


Subject: [PATCH] blk-mq: Make it safe to call blk_mq_start_hw_queues() from 
interrupt context

blk_mq_start_hw_queues() triggers a queue run. Some functions that
get called to run a queue, e.g. dd_dispatch_request(), are not IRQ-safe.
Hence run the queue asynchronously if blk_mq_start_hw_queues() is called
from interrupt context.

Signed-off-by: Bart Van Assche <bart.vanass...@wdc.com>
---
 block/blk-mq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/block/blk-mq.c b/block/blk-mq.c
index 041f7b7fa0d6..c5cb3b2aabcf 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -1251,7 +1251,7 @@ void blk_mq_start_hw_queue(struct blk_mq_hw_ctx *hctx)
 {
clear_bit(BLK_MQ_S_STOPPED, >state);
 
-   blk_mq_run_hw_queue(hctx, false);
+   blk_mq_run_hw_queue(hctx, in_interrupt());
 }
 EXPORT_SYMBOL(blk_mq_start_hw_queue);
 
Thanks,

Bart.

[PATCH v3 03/37] treewide: Consolidate set_dma_ops() implementations

[Bart Van Assche]

Now that all set_dma_ops() implementations are identical (ignoring
BUG_ON() statements), remove the architecture specific definitions
and add a definition in .

Signed-off-by: Bart Van Assche <bart.vanass...@sandisk.com>
Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org>
Cc: Chris Metcalf <cmetc...@mellanox.com>
Cc: David Woodhouse <dw...@infradead.org>
Cc: linux-a...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Paul Mackerras <pau...@samba.org>
Cc: Russell King <li...@armlinux.org.uk>
---
 arch/arm/include/asm/dma-mapping.h | 6 --
 arch/powerpc/include/asm/dma-mapping.h | 5 -
 arch/tile/include/asm/dma-mapping.h| 5 -
 include/linux/dma-mapping.h| 5 +
 4 files changed, 5 insertions(+), 16 deletions(-)

diff --git a/arch/arm/include/asm/dma-mapping.h 
b/arch/arm/include/asm/dma-mapping.h
index 312f4d0564d6..c7432d647e53 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -31,12 +31,6 @@ static inline const struct dma_map_ops *get_dma_ops(struct 
device *dev)
return __generic_dma_ops(dev);
 }
 
-static inline void set_dma_ops(struct device *dev, const struct dma_map_ops 
*ops)
-{
-   BUG_ON(!dev);
-   dev->dma_ops = ops;
-}
-
 #define HAVE_ARCH_DMA_SUPPORTED 1
 extern int dma_supported(struct device *dev, u64 mask);
 
diff --git a/arch/powerpc/include/asm/dma-mapping.h 
b/arch/powerpc/include/asm/dma-mapping.h
index 59fbd4abcbf8..8275603ba4d5 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -91,11 +91,6 @@ static inline const struct dma_map_ops *get_dma_ops(struct 
device *dev)
return dev->dma_ops;
 }
 
-static inline void set_dma_ops(struct device *dev, const struct dma_map_ops 
*ops)
-{
-   dev->dma_ops = ops;
-}
-
 /*
  * get_dma_offset()
  *
diff --git a/arch/tile/include/asm/dma-mapping.h 
b/arch/tile/include/asm/dma-mapping.h
index c0620697eaad..2562995a6ac9 100644
--- a/arch/tile/include/asm/dma-mapping.h
+++ b/arch/tile/include/asm/dma-mapping.h
@@ -59,11 +59,6 @@ static inline phys_addr_t dma_to_phys(struct device *dev, 
dma_addr_t daddr)
 
 static inline void dma_mark_clean(void *addr, size_t size) {}
 
-static inline void set_dma_ops(struct device *dev, const struct dma_map_ops 
*ops)
-{
-   dev->dma_ops = ops;
-}
-
 static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t 
size)
 {
if (!dev->dma_mask)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index f1da68b82c63..e97f23e8b2d9 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -164,6 +164,11 @@ int dma_mmap_from_coherent(struct device *dev, struct 
vm_area_struct *vma,
 
 #ifdef CONFIG_HAS_DMA
 #include 
+static inline void set_dma_ops(struct device *dev,
+  const struct dma_map_ops *dma_ops)
+{
+   dev->dma_ops = dma_ops;
+}
 #else
 /*
  * Define the dma api to allow compilation but not linking of
-- 
2.11.0

[PATCH v2 03/26] treewide: Consolidate set_dma_ops() implementations

[Bart Van Assche]

Now that all set_dma_ops() implementations are identical (ignoring
BUG_ON() statements), remove the architecture specific definitions
and add a definition in .

Signed-off-by: Bart Van Assche <bart.vanass...@sandisk.com>
Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org>
Cc: Chris Metcalf <cmetc...@mellanox.com>
Cc: David Woodhouse <dw...@infradead.org>
Cc: linux-a...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Paul Mackerras <pau...@samba.org>
Cc: Russell King <li...@armlinux.org.uk>
---
 arch/arm/include/asm/dma-mapping.h | 6 --
 arch/powerpc/include/asm/dma-mapping.h | 5 -
 arch/tile/include/asm/dma-mapping.h| 5 -
 include/linux/dma-mapping.h| 5 +
 4 files changed, 5 insertions(+), 16 deletions(-)

diff --git a/arch/arm/include/asm/dma-mapping.h 
b/arch/arm/include/asm/dma-mapping.h
index 312f4d0564d6..c7432d647e53 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -31,12 +31,6 @@ static inline const struct dma_map_ops *get_dma_ops(struct 
device *dev)
return __generic_dma_ops(dev);
 }
 
-static inline void set_dma_ops(struct device *dev, const struct dma_map_ops 
*ops)
-{
-   BUG_ON(!dev);
-   dev->dma_ops = ops;
-}
-
 #define HAVE_ARCH_DMA_SUPPORTED 1
 extern int dma_supported(struct device *dev, u64 mask);
 
diff --git a/arch/powerpc/include/asm/dma-mapping.h 
b/arch/powerpc/include/asm/dma-mapping.h
index 59fbd4abcbf8..8275603ba4d5 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -91,11 +91,6 @@ static inline const struct dma_map_ops *get_dma_ops(struct 
device *dev)
return dev->dma_ops;
 }
 
-static inline void set_dma_ops(struct device *dev, const struct dma_map_ops 
*ops)
-{
-   dev->dma_ops = ops;
-}
-
 /*
  * get_dma_offset()
  *
diff --git a/arch/tile/include/asm/dma-mapping.h 
b/arch/tile/include/asm/dma-mapping.h
index c0620697eaad..2562995a6ac9 100644
--- a/arch/tile/include/asm/dma-mapping.h
+++ b/arch/tile/include/asm/dma-mapping.h
@@ -59,11 +59,6 @@ static inline phys_addr_t dma_to_phys(struct device *dev, 
dma_addr_t daddr)
 
 static inline void dma_mark_clean(void *addr, size_t size) {}
 
-static inline void set_dma_ops(struct device *dev, const struct dma_map_ops 
*ops)
-{
-   dev->dma_ops = ops;
-}
-
 static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t 
size)
 {
if (!dev->dma_mask)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index f1da68b82c63..e97f23e8b2d9 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -164,6 +164,11 @@ int dma_mmap_from_coherent(struct device *dev, struct 
vm_area_struct *vma,
 
 #ifdef CONFIG_HAS_DMA
 #include 
+static inline void set_dma_ops(struct device *dev,
+  const struct dma_map_ops *dma_ops)
+{
+   dev->dma_ops = dma_ops;
+}
 #else
 /*
  * Define the dma api to allow compilation but not linking of
-- 
2.11.0

Re: [PATCH 2/9] Move dma_ops from archdata into struct device

[Bart Van Assche]

On Wed, 2017-01-11 at 21:31 +0100, gre...@linuxfoundation.org wrote:
> That's a big sign that your patch series needs work.  Break it up into
> smaller pieces, it should be possible, which will make merges easier
> (well, different in a way.)

Hello Greg,

Can you have a look at the attached patches? These three patches are a
splitup of the single patch at the start of this e-mail thread.

Thanks,

Bart.From a6fe3a6db80f2bc359e049b72e13aa171fff6ffa Mon Sep 17 00:00:00 2001
From: Bart Van Assche <bart.vanass...@sandisk.com>
Date: Wed, 11 Jan 2017 13:31:42 -0800
Subject: [PATCH 1/3] treewide: Move dma_ops from struct dev_archdata into
 struct device

This change is necessary to make the dma_ops pointer configurable
per device on architectures that do not yet implement set_dma_ops().

Signed-off-by: Bart Van Assche <bart.vanass...@sandisk.com>
---
 arch/arm/include/asm/device.h| 1 -
 arch/arm/include/asm/dma-mapping.h   | 6 +++---
 arch/arm64/include/asm/device.h  | 1 -
 arch/arm64/include/asm/dma-mapping.h | 4 ++--
 arch/arm64/mm/dma-mapping.c  | 8 
 arch/m32r/include/asm/device.h   | 1 -
 arch/m32r/include/asm/dma-mapping.h  | 4 ++--
 arch/mips/include/asm/device.h   | 5 -
 arch/mips/include/asm/dma-mapping.h  | 4 ++--
 arch/mips/pci/pci-octeon.c   | 2 +-
 arch/powerpc/include/asm/device.h| 4 
 arch/powerpc/include/asm/dma-mapping.h   | 4 ++--
 arch/powerpc/kernel/dma.c| 2 +-
 arch/powerpc/platforms/cell/iommu.c  | 2 +-
 arch/powerpc/platforms/pasemi/iommu.c| 2 +-
 arch/powerpc/platforms/pasemi/setup.c| 2 +-
 arch/powerpc/platforms/ps3/system-bus.c  | 4 ++--
 arch/powerpc/platforms/pseries/ibmebus.c | 2 +-
 arch/s390/include/asm/device.h   | 1 -
 arch/s390/include/asm/dma-mapping.h  | 4 ++--
 arch/s390/pci/pci.c  | 2 +-
 arch/tile/include/asm/device.h   | 3 ---
 arch/tile/include/asm/dma-mapping.h  | 6 +++---
 arch/x86/include/asm/device.h| 3 ---
 arch/x86/include/asm/dma-mapping.h   | 4 ++--
 arch/x86/kernel/pci-calgary_64.c | 4 ++--
 arch/x86/pci/common.c| 2 +-
 arch/x86/pci/sta2x11-fixup.c | 8 
 arch/xtensa/include/asm/device.h | 4 
 arch/xtensa/include/asm/dma-mapping.h| 4 ++--
 drivers/infiniband/ulp/srpt/ib_srpt.c| 2 +-
 drivers/iommu/amd_iommu.c| 6 +++---
 drivers/misc/mic/bus/mic_bus.c   | 2 +-
 drivers/misc/mic/bus/scif_bus.c  | 2 +-
 include/linux/device.h   | 1 +
 35 files changed, 47 insertions(+), 69 deletions(-)

diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
index d8a572f9c187..220ba207be91 100644
--- a/arch/arm/include/asm/device.h
+++ b/arch/arm/include/asm/device.h
@@ -7,7 +7,6 @@
 #define ASMARM_DEVICE_H
 
 struct dev_archdata {
-	const struct dma_map_ops	*dma_ops;
 #ifdef CONFIG_DMABOUNCE
 	struct dmabounce_device_info *dmabounce;
 #endif
diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
index 1aabd781306f..312f4d0564d6 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -18,8 +18,8 @@ extern const struct dma_map_ops arm_coherent_dma_ops;
 
 static inline const struct dma_map_ops *__generic_dma_ops(struct device *dev)
 {
-	if (dev && dev->archdata.dma_ops)
-		return dev->archdata.dma_ops;
+	if (dev && dev->dma_ops)
+		return dev->dma_ops;
 	return _dma_ops;
 }
 
@@ -34,7 +34,7 @@ static inline const struct dma_map_ops *get_dma_ops(struct device *dev)
 static inline void set_dma_ops(struct device *dev, const struct dma_map_ops *ops)
 {
 	BUG_ON(!dev);
-	dev->archdata.dma_ops = ops;
+	dev->dma_ops = ops;
 }
 
 #define HAVE_ARCH_DMA_SUPPORTED 1
diff --git a/arch/arm64/include/asm/device.h b/arch/arm64/include/asm/device.h
index 00c678cc31e1..73d5bab015eb 100644
--- a/arch/arm64/include/asm/device.h
+++ b/arch/arm64/include/asm/device.h
@@ -17,7 +17,6 @@
 #define __ASM_DEVICE_H
 
 struct dev_archdata {
-	const struct dma_map_ops *dma_ops;
 #ifdef CONFIG_IOMMU_API
 	void *iommu;			/* private IOMMU data */
 #endif
diff --git a/arch/arm64/include/asm/dma-mapping.h b/arch/arm64/include/asm/dma-mapping.h
index 1fedb43be712..58ae36cc3b60 100644
--- a/arch/arm64/include/asm/dma-mapping.h
+++ b/arch/arm64/include/asm/dma-mapping.h
@@ -29,8 +29,8 @@ extern const struct dma_map_ops dummy_dma_ops;
 
 static inline const struct dma_map_ops *__generic_dma_ops(struct device *dev)
 {
-	if (dev && dev->archdata.dma_ops)
-		return dev->archdata.dma_ops;
+	if (dev && dev->dma_ops)
+		return dev->dma_ops;
 
 	/*
 	 * We expect no ISA devices, and all other DMA masters are expected to
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index bcef6368d48f..dbab4c6c084b 100644
--- a/arch/arm64/mm/dma-mapping.

Re: [PATCH 2/9] Move dma_ops from archdata into struct device

[Bart Van Assche]

On Wed, 2017-01-11 at 07:48 +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 10, 2017 at 04:56:41PM -0800, Bart Van Assche wrote:
> > Several RDMA drivers, e.g. drivers/infiniband/hw/qib, use the CPU to
> > transfer data between memory and PCIe adapter. Because of performance
> > reasons it is important that the CPU cache is not flushed when such
> > drivers transfer data. Make this possible by allowing these drivers to
> > override the dma_map_ops pointer. Additionally, introduce the function
> > set_dma_ops() that will be used by a later patch in this series.
> 
> When you say things like "additionally", that's a huge flag that this
> needs to be split up into multiple patches.  No need to add
> set_dma_ops() here in this patch.

Hello Greg,

Some architectures already define a set_dma_ops() function. So what this
patch does is to move both the dma_ops pointer and the set_dma_ops()
function from architecture-specific to architecture independent code. I
don't think that it is possible to separate these two changes. But I
understand that how I formulated the patch description caused confusion. I
will rewrite the patch description to make it more clear before I repost
this patch series.

> And I'd argue that it should be dma_ops_set(), and dma_ops_get(), just
> to keep the namespace sane, but that's probably a different set of
> patches...

Every time I rebase and retest this patch series on top of a new kernel
version I have to modify some of the patches to compensate for changes in
the architecture code. So I expect that once Linus merges these patches that
he will have to resolve one or more merge conflicts. Including a rename of
the functions that query and set the dma_ops pointer in this patch series
would increase the number of merge conflicts triggered by this patch series
and would make Linus' job harder. So I hope that you will allow me to
postpone that rename until a later time ...

Bart.

Re: [PATCH 2/9] Move dma_ops from archdata into struct device

[Bart Van Assche]

On Wed, 2017-01-11 at 07:46 +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 10, 2017 at 04:56:41PM -0800, Bart Van Assche wrote:
> > Several RDMA drivers, e.g. drivers/infiniband/hw/qib, use the CPU to
> > transfer data between memory and PCIe adapter. Because of performance
> > reasons it is important that the CPU cache is not flushed when such
> > drivers transfer data. Make this possible by allowing these drivers to
> > override the dma_map_ops pointer. Additionally, introduce the function
> > set_dma_ops() that will be used by a later patch in this series.
> > 
> > Signed-off-by: Bart Van Assche <bart.vanass...@sandisk.com>
> > Cc: [ ... ]
> 
> That's a crazy cc: list, you should break this up into smaller pieces,
> otherwise it's going to bounce...

That's a subset of what scripts/get_maintainer.pl came up with. Suggestions
for a more appropriate cc-list for a patch like this that touches all
architectures would be welcome.

> > diff --git a/include/linux/device.h b/include/linux/device.h
> > index 491b4c0ca633..c7cb225d36b0 100644
> > --- a/include/linux/device.h
> > +++ b/include/linux/device.h
> > @@ -885,6 +885,8 @@ struct dev_links_info {
> >   * a higher-level representation of the device.
> >   */
> >  struct device {
> > +   const struct dma_map_ops *dma_ops; /* See also get_dma_ops() */
> > +
> >     struct device   *parent;
> >  
> >     struct device_private   *p;
> 
> Why not put this new pointer down with the other dma fields in this
> structure?  Any specific reason it needs to be first?

Are there CPU architectures for which access to the first member of a
structure can be encoded and/or executed more efficiently than access to
other members of a structure? If not, I'm fine with moving the new pointer
further down.

Bart.

[PATCH 1/9] treewide: Constify most dma_map_ops structures

[Bart Van Assche]

Most dma_map_ops structures are never modified. Constify these
structures such that these can be write-protected. This patch
has been generated as follows:

git grep -l 'struct dma_map_ops' |
  xargs -d\\n sed -i \
-e 's/struct dma_map_ops/const struct dma_map_ops/g' \
-e 's/const struct dma_map_ops {/struct dma_map_ops {/g' \
-e 's/^const struct dma_map_ops;$/struct dma_map_ops;/' \
-e 's/const const struct dma_map_ops /const struct dma_map_ops /g';
sed -i -e 's/const \(struct dma_map_ops intel_dma_ops\)/\1/' \
  $(git grep -l 'struct dma_map_ops intel_dma_ops');
sed -i -e 's/const \(struct dma_map_ops dma_iommu_ops\)/\1/' \
  $(git grep -l 'struct dma_map_ops' | grep ^arch/powerpc);
sed -i -e '/^struct vmd_dev {$/,/^};$/ s/const \(struct 
dma_map_ops[[:blank:]]dma_ops;\)/\1/' \
   -e '/^static void vmd_setup_dma_ops/,/^}$/ s/const \(struct dma_map_ops 
\*dest\)/\1/' \
   -e 's/const \(struct dma_map_ops \*dest = \>dma_ops\)/\1/' \
drivers/pci/host/*.c
sed -i -e '/^void __init pci_iommu_alloc(void)$/,/^}$/ 
s/dma_ops->/intel_dma_ops./' arch/ia64/kernel/pci-dma.c
sed -i -e 's/static const struct dma_map_ops sn_dma_ops/static struct 
dma_map_ops sn_dma_ops/' arch/ia64/sn/pci/pci_dma.c

Signed-off-by: Bart Van Assche <bart.vanass...@sandisk.com>
Reviewed-by: Christoph Hellwig <h...@lst.de>
Cc: Aurelien Jacquiot <a-jacqu...@ti.com>
Cc: Catalin Marinas <catalin.mari...@arm.com>
Cc: Chris Zankel <ch...@zankel.net>
Cc: David Howells <dhowe...@redhat.com>
Cc: David S. Miller <da...@davemloft.net>
Cc: Fenghua Yu <fenghua...@intel.com>
Cc: Geert Uytterhoeven <ge...@linux-m68k.org>
Cc: Geoff Levand <ge...@infradead.org>
Cc: Guan Xuetao <g...@mprc.pku.edu.cn>
Cc: H. Peter Anvin <h...@zytor.com>
Cc: Haavard Skinnemoen <hskinnem...@gmail.com>
Cc: Hans-Christian Egtvedt <egtv...@samfundet.no>
Cc: Helge Deller <del...@gmx.de>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: James E.J. Bottomley <j...@parisc-linux.org>
Cc: Jesper Nilsson <jesper.nils...@axis.com>
Cc: Joerg Roedel <j...@8bytes.org>
Cc: Jon Mason <jdma...@kudzu.us>
Cc: Jonas Bonn <jo...@southpole.se>
Cc: Ley Foon Tan <lf...@altera.com>
Cc: Mark Salter <msal...@redhat.com>
Cc: Max Filippov <jcmvb...@gmail.com>
Cc: Mikael Starvik <star...@axis.com>
Cc: Muli Ben-Yehuda <mu...@mulix.org>
Cc: Rich Felker <dal...@libc.org>
Cc: Russell King <li...@armlinux.org.uk>
Cc: Stafford Horne <sho...@gmail.com>
Cc: Stefan Kristiansson <stefan.kristians...@saunalahti.fi>
Cc: Stefano Stabellini <sstabell...@kernel.org>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Tony Luck <tony.l...@intel.com>
Cc: Will Deacon <will.dea...@arm.com>
Cc: x...@kernel.org
Cc: Yoshinori Sato <ys...@users.sourceforge.jp>
Cc: adi-buildroot-de...@lists.sourceforge.net
Cc: io...@lists.linux-foundation.org
Cc: linux-al...@vger.kernel.org
Cc: linux-am33-l...@redhat.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-c6x-...@linux-c6x.org
Cc: linux-cris-ker...@axis.com
Cc: linux-hexa...@vger.kernel.org
Cc: linux-i...@vger.kernel.org
Cc: linux-m...@lists.linux-m68k.org
Cc: linux-me...@vger.kernel.org
Cc: linux-m...@linux-mips.org
Cc: linux-par...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-s...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-snps-...@lists.infradead.org
Cc: linux-xte...@linux-xtensa.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: nios2-...@lists.rocketboards.org
Cc: openr...@lists.librecores.org
Cc: sparcli...@vger.kernel.org
Cc: uclinux-h8-de...@lists.sourceforge.jp
Cc: xen-de...@lists.xenproject.org
---
 arch/alpha/include/asm/dma-mapping.h   |  4 +--
 arch/alpha/kernel/pci-noop.c   |  4 +--
 arch/alpha/kernel/pci_iommu.c  |  4 +--
 arch/arc/include/asm/dma-mapping.h |  4 +--
 arch/arc/mm/dma.c  |  2 +-
 arch/arm/common/dmabounce.c|  2 +-
 arch/arm/include/asm/device.h  |  2 +-
 arch/arm/include/asm/dma-mapping.h | 10 +++---
 arch/arm/mm/dma-mapping.c  | 22 ++--
 arch/arm/xen/mm.c  |  4 +--
 arch/arm64/include/asm/device.h|  2 +-
 arch/arm64/include/asm/dma-mapping.h   |  6 ++--
 arch/arm64/mm/dma-mapping.c|  6 ++--
 arch/avr32/include/asm/dma-mapping.h   |  4 +--
 arch/avr32/mm/dma-coherent.c   |  2 +-
 arch/blackfin/include/asm/dma-mapping.h|  4 +--
 arch/blackfin/kernel/dma-mapping.c |  2 +-
 arch/c6x/include/asm/dma-mapping.h |  4 +--
 arch/c6x/kernel/dma.c  |  2 +-
 arch/cris/arch-v32/drivers/pci/dma.c   |  2 +-
 arch/cris/include/asm/dma-mappi

[PATCH 2/9] Move dma_ops from archdata into struct device

[Bart Van Assche]

Several RDMA drivers, e.g. drivers/infiniband/hw/qib, use the CPU to
transfer data between memory and PCIe adapter. Because of performance
reasons it is important that the CPU cache is not flushed when such
drivers transfer data. Make this possible by allowing these drivers to
override the dma_map_ops pointer. Additionally, introduce the function
set_dma_ops() that will be used by a later patch in this series.

Signed-off-by: Bart Van Assche <bart.vanass...@sandisk.com>
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Cc: Aurelien Jacquiot <a-jacqu...@ti.com>
Cc: Catalin Marinas <catalin.mari...@arm.com>
Cc: Chris Zankel <ch...@zankel.net>
Cc: David Howells <dhowe...@redhat.com>
Cc: David S. Miller <da...@davemloft.net>
Cc: Fenghua Yu <fenghua...@intel.com>
Cc: Geert Uytterhoeven <ge...@linux-m68k.org>
Cc: Geoff Levand <ge...@infradead.org>
Cc: H. Peter Anvin <h...@zytor.com>
Cc: Haavard Skinnemoen <hskinnem...@gmail.com>
Cc: Hans-Christian Egtvedt <egtv...@samfundet.no>
Cc: Helge Deller <del...@gmx.de>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: James E.J. Bottomley <j...@parisc-linux.org>
Cc: Jesper Nilsson <jesper.nils...@axis.com>
Cc: Joerg Roedel <j...@8bytes.org>
Cc: Jon Mason <jdma...@kudzu.us>
Cc: Jonas Bonn <jo...@southpole.se>
Cc: Ley Foon Tan <lf...@altera.com>
Cc: Mark Salter <msal...@redhat.com>
Cc: Max Filippov <jcmvb...@gmail.com>
Cc: Mikael Starvik <star...@axis.com>
Cc: Muli Ben-Yehuda <mu...@mulix.org>
Cc: Rich Felker <dal...@libc.org>
Cc: Russell King <li...@armlinux.org.uk>
Cc: Stafford Horne <sho...@gmail.com>
Cc: Stefan Kristiansson <stefan.kristians...@saunalahti.fi>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Tony Luck <tony.l...@intel.com>
Cc: Will Deacon <will.dea...@arm.com>
Cc: x...@kernel.org
Cc: Yoshinori Sato <ys...@users.sourceforge.jp>
Cc: adi-buildroot-de...@lists.sourceforge.net
Cc: io...@lists.linux-foundation.org
Cc: linux-al...@vger.kernel.org
Cc: linux-am33-l...@redhat.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-c6x-...@linux-c6x.org
Cc: linux-cris-ker...@axis.com
Cc: linux-hexa...@vger.kernel.org
Cc: linux-i...@vger.kernel.org
Cc: linux-m...@lists.linux-m68k.org
Cc: linux-me...@vger.kernel.org
Cc: linux-m...@linux-mips.org
Cc: linux-par...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-r...@vger.kernel.org
Cc: linux-s...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-snps-...@lists.infradead.org
Cc: linux-xte...@linux-xtensa.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: nios2-...@lists.rocketboards.org
Cc: openr...@lists.librecores.org
Cc: sparcli...@vger.kernel.org
Cc: uclinux-h8-de...@lists.sourceforge.jp
---
 arch/alpha/include/asm/dma-mapping.h  |  2 +-
 arch/arc/include/asm/dma-mapping.h|  2 +-
 arch/arm/include/asm/device.h |  1 -
 arch/arm/include/asm/dma-mapping.h| 17 -
 arch/arm64/include/asm/device.h   |  1 -
 arch/arm64/include/asm/dma-mapping.h  |  8 
 arch/arm64/mm/dma-mapping.c   |  8 
 arch/avr32/include/asm/dma-mapping.h  |  2 +-
 arch/blackfin/include/asm/dma-mapping.h   |  2 +-
 arch/c6x/include/asm/dma-mapping.h|  2 +-
 arch/cris/include/asm/dma-mapping.h   |  4 ++--
 arch/frv/include/asm/dma-mapping.h|  2 +-
 arch/h8300/include/asm/dma-mapping.h  |  2 +-
 arch/hexagon/include/asm/dma-mapping.h|  5 +
 arch/ia64/include/asm/dma-mapping.h   |  5 -
 arch/m32r/include/asm/dma-mapping.h   |  4 +---
 arch/m68k/include/asm/dma-mapping.h   |  2 +-
 arch/metag/include/asm/dma-mapping.h  |  2 +-
 arch/microblaze/include/asm/dma-mapping.h |  2 +-
 arch/mips/include/asm/device.h|  5 -
 arch/mips/include/asm/dma-mapping.h   |  7 ++-
 arch/mips/pci/pci-octeon.c|  2 +-
 arch/mn10300/include/asm/dma-mapping.h|  2 +-
 arch/nios2/include/asm/dma-mapping.h  |  2 +-
 arch/openrisc/include/asm/dma-mapping.h   |  2 +-
 arch/parisc/include/asm/dma-mapping.h |  2 +-
 arch/powerpc/include/asm/device.h |  4 
 arch/powerpc/include/asm/dma-mapping.h| 17 ++---
 arch/powerpc/include/asm/ps3.h|  2 +-
 arch/powerpc/kernel/dma.c |  2 +-
 arch/powerpc/platforms/cell/iommu.c   |  2 +-
 arch/powerpc/platforms/pasemi/iommu.c |  2 +-
 arch/powerpc/platforms/pasemi/setup.c |  2 +-
 arch/powerpc/platforms/ps3/system-bus.c   |  4 ++--
 arch/powerpc/platforms/pseries/ibmebus.c  |  2 +-
 arch/s390/include/asm/device.h|  1 -
 arch/s390/include/asm/dma-mapping.h   |  4 +---
 arch/s390/pci/pci.c   |  2 +-
 arch/sh/include/asm/dma-mapping.h |  2 +-
 arch/sparc/include/asm/dma-mapping.h  |  4 ++--
 arch/tile/include/asm/device.h|  3 ---
 arch/tile/include/a

Re: Regression in 3.15 on POWER8 with multipath SCSI

[Bart Van Assche]

On 07/01/14 21:39, Mike Snitzer wrote:
 (btw, Bart Van Assche also has issues with commit e8099177 due to hangs
 during cable pull testing of mpath devices -- Bart: curious to know if
 your cable pull tests pass if you just revert bcccff93).

Sorry but even with bcccff93 reverted after a few iterations my cable
pull simulation test still causes several tasks to hang in sleep_on_page().

Bart.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 2/4] i2c/chips: Remove deprecated pcf8575-driver

[Bart Van Assche]

On Wed, Sep 9, 2009 at 11:22 PM, Wolfram Sang w.s...@pengutronix.de wrote:

 The pcf8575-driver in drivers/i2c/chips which just exports its register to
 sysfs is superseeded by drivers/gpio/pcf857x.c which properly uses the 
 gpiolib.
 As this driver has been deprecated for more than a year, finally remove it.

 Signed-off-by: Wolfram Sang w.s...@pengutronix.de
 Cc: Bart Van Assche bart.vanass...@gmail.com
 Cc: Jean Delvare kh...@linux-fr.org
 ---
  Documentation/i2c/chips/pcf8575 |   69 --
  drivers/i2c/chips/Kconfig       |   18 
  drivers/i2c/chips/Makefile      |    1 -
  drivers/i2c/chips/pcf8575.c     |  198 
 ---
  4 files changed, 0 insertions(+), 286 deletions(-)
  delete mode 100644 Documentation/i2c/chips/pcf8575
  delete mode 100644 drivers/i2c/chips/pcf8575.c

This patch removes the documentation file
Documentation/i2c/chips/pcf8575 while there is no documentation under
Documentation/ for the drivers/gpio/pcf857x.c driver. Shouldn't proper
documentation for the pcf857x driver be added to the kernel tree
before the pcf8575 driver is removed ?

Bart.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 2.6.25.9] Make sure that include/asm-powerpc/spinlock.h does not trigger compilation warnings

[Bart Van Assche]

When compiling kernel modules for ppc that include linux/spinlock.h, gcc
prints a warning message every time it encounters a function declaration where
the inline keyword appears after the return type. The patch below makes sure
that the order of the inline keyword and the return type is as gcc expects it.
Additionally, the __inline__ keyword is replaced by inline, as checkpatch
expects.

Signed-off-by: Bart Van Assche [EMAIL PROTECTED]

diff -uprN orig/linux-2.6.25.9/include/asm-powerpc/spinlock.h 
linux-2.6.25.9/include/asm-powerpc/spinlock.h
--- orig/linux-2.6.25.9/include/asm-powerpc/spinlock.h  2008-06-24 
23:09:06.0 +0200
+++ linux-2.6.25.9/include/asm-powerpc/spinlock.h   2008-06-28 
08:34:52.0 +0200
@@ -53,7 +53,7 @@
  * This returns the old value in the lock, so we succeeded
  * in getting the lock if the return value is 0.
  */
-static __inline__ unsigned long __spin_trylock(raw_spinlock_t *lock)
+static inline unsigned long __spin_trylock(raw_spinlock_t *lock)
 {
unsigned long tmp, token;
 
@@ -72,7 +72,7 @@ static __inline__ unsigned long __spin_t
return tmp;
 }
 
-static int __inline__ __raw_spin_trylock(raw_spinlock_t *lock)
+static inline int __raw_spin_trylock(raw_spinlock_t *lock)
 {
CLEAR_IO_SYNC;
return __spin_trylock(lock) == 0;
@@ -103,7 +103,7 @@ extern void __rw_yield(raw_rwlock_t *loc
 #define SHARED_PROCESSOR   0
 #endif
 
-static void __inline__ __raw_spin_lock(raw_spinlock_t *lock)
+static inline void __raw_spin_lock(raw_spinlock_t *lock)
 {
CLEAR_IO_SYNC;
while (1) {
@@ -118,7 +118,8 @@ static void __inline__ __raw_spin_lock(r
}
 }
 
-static void __inline__ __raw_spin_lock_flags(raw_spinlock_t *lock, unsigned 
long flags)
+static inline
+void __raw_spin_lock_flags(raw_spinlock_t *lock, unsigned long flags)
 {
unsigned long flags_dis;
 
@@ -138,7 +139,7 @@ static void __inline__ __raw_spin_lock_f
}
 }
 
-static __inline__ void __raw_spin_unlock(raw_spinlock_t *lock)
+static inline void __raw_spin_unlock(raw_spinlock_t *lock)
 {
SYNC_IO;
__asm__ __volatile__(# __raw_spin_unlock\n\t
@@ -179,7 +180,7 @@ extern void __raw_spin_unlock_wait(raw_s
  * This returns the old value in the lock + 1,
  * so we got a read lock if the return value is  0.
  */
-static long __inline__ __read_trylock(raw_rwlock_t *rw)
+static inline long __read_trylock(raw_rwlock_t *rw)
 {
long tmp;
 
@@ -203,7 +204,7 @@ static long __inline__ __read_trylock(ra
  * This returns the old value in the lock,
  * so we got the write lock if the return value is 0.
  */
-static __inline__ long __write_trylock(raw_rwlock_t *rw)
+static inline long __write_trylock(raw_rwlock_t *rw)
 {
long tmp, token;
 
@@ -223,7 +224,7 @@ static __inline__ long __write_trylock(r
return tmp;
 }
 
-static void __inline__ __raw_read_lock(raw_rwlock_t *rw)
+static inline void __raw_read_lock(raw_rwlock_t *rw)
 {
while (1) {
if (likely(__read_trylock(rw)  0))
@@ -237,7 +238,7 @@ static void __inline__ __raw_read_lock(r
}
 }
 
-static void __inline__ __raw_write_lock(raw_rwlock_t *rw)
+static inline void __raw_write_lock(raw_rwlock_t *rw)
 {
while (1) {
if (likely(__write_trylock(rw) == 0))
@@ -251,17 +252,17 @@ static void __inline__ __raw_write_lock(
}
 }
 
-static int __inline__ __raw_read_trylock(raw_rwlock_t *rw)
+static inline int __raw_read_trylock(raw_rwlock_t *rw)
 {
return __read_trylock(rw)  0;
 }
 
-static int __inline__ __raw_write_trylock(raw_rwlock_t *rw)
+static inline int __raw_write_trylock(raw_rwlock_t *rw)
 {
return __write_trylock(rw) == 0;
 }
 
-static void __inline__ __raw_read_unlock(raw_rwlock_t *rw)
+static inline void __raw_read_unlock(raw_rwlock_t *rw)
 {
long tmp;
 
@@ -278,7 +279,7 @@ static void __inline__ __raw_read_unlock
: cr0, memory);
 }
 
-static __inline__ void __raw_write_unlock(raw_rwlock_t *rw)
+static inline void __raw_write_unlock(raw_rwlock_t *rw)
 {
__asm__ __volatile__(# write_unlock\n\t
LWSYNC_ON_SMP: : :memory);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 2.6.25.9] Make sure that include/asm-powerpc/spinlock.h does not trigger compilation warnings

[Bart Van Assche]

On Sat, Jun 28, 2008 at 5:07 PM, Kumar Gala [EMAIL PROTECTED] wrote:

 On Jun 28, 2008, at 1:51 AM, Bart Van Assche wrote:

 When compiling kernel modules for ppc that include linux/spinlock.h, gcc
 prints a warning message every time it encounters a function declaration
 where
 the inline keyword appears after the return type. The patch below makes
 sure
 that the order of the inline keyword and the return type is as gcc expects
 it.
 Additionally, the __inline__ keyword is replaced by inline, as checkpatch
 expects.

 Signed-off-by: Bart Van Assche [EMAIL PROTECTED]

 what version of gcc and what config are you building for?

The gcc details are as follows (openSUSE 10.3 PPC running on a PS3):

$ gcc -v
Using built-in specs.
Target: powerpc64-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release
--with-gxx-include-dir=/usr/include/c++/4.2.1 --enable-ssp
--disable-libssp --disable-libgcj --with-slibdir=/lib
--with-system-zlib --enable-shared --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--program-suffix=-4.2 --enable-version-specific-runtime-libs
--without-system-libunwind --with-cpu=default32 --enable-secureplt
--with-long-double-128 --host=powerpc64-suse-linux
Thread model: posix
gcc version 4.2.1 (SUSE Linux)

Bart.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: section mismatch warnings in current git head for powerpc

[Bart Van Assche]

On Thu, May 22, 2008 at 7:22 PM, Chris Friesen [EMAIL PROTECTED] wrote:
 I got the following warnings when building current git head for powerpc
 64bit:

Something that should be fixed, but not something to worry about.
Similar warnings appear when building the kernel for x86_64. See also
http://lkml.org/lkml/2008/4/13/98, http://lkml.org/lkml/2008/4/17/202
and http://bugzilla.kernel.org/show_bug.cgi?id=9974.

Bart.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev