[PATCH v2 04/22] powerpc/cell: Switch to irq_get_nr_irqs()
Use the irq_get_nr_irqs() function instead of the global variable 'nr_irqs'. This patch prepares for changing 'nr_irqs' from an exported global variable into a variable with file scope. Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Bart Van Assche --- arch/powerpc/platforms/cell/axon_msi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/platforms/cell/axon_msi.c b/arch/powerpc/platforms/cell/axon_msi.c index 28dc86744cac..d243f7fd8982 100644 --- a/arch/powerpc/platforms/cell/axon_msi.c +++ b/arch/powerpc/platforms/cell/axon_msi.c @@ -112,7 +112,7 @@ static void axon_msi_cascade(struct irq_desc *desc) pr_devel("axon_msi: woff %x roff %x msi %x\n", write_offset, msic->read_offset, msi); - if (msi < nr_irqs && irq_get_chip_data(msi) == msic) { + if (msi < irq_get_nr_irqs() && irq_get_chip_data(msi) == msic) { generic_handle_irq(msi); msic->fifo_virt[idx] = cpu_to_le32(0x); } else {
[PATCH 04/21] powerpc/cell: Switch to number_of_interrupts()
Use the number_of_interrupts() function instead of the global variable 'nr_irqs'. This patch prepares for changing 'nr_irqs' from an exported global variable into a variable with file scope. Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Bart Van Assche --- arch/powerpc/platforms/cell/axon_msi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/platforms/cell/axon_msi.c b/arch/powerpc/platforms/cell/axon_msi.c index 28dc86744cac..b7996bc091e6 100644 --- a/arch/powerpc/platforms/cell/axon_msi.c +++ b/arch/powerpc/platforms/cell/axon_msi.c @@ -112,7 +112,7 @@ static void axon_msi_cascade(struct irq_desc *desc) pr_devel("axon_msi: woff %x roff %x msi %x\n", write_offset, msic->read_offset, msi); - if (msi < nr_irqs && irq_get_chip_data(msi) == msic) { + if (msi < number_of_interrupts() && irq_get_chip_data(msi) == msic) { generic_handle_irq(msi); msic->fifo_virt[idx] = cpu_to_le32(0x); } else {
Re: [PATCH 12/26] block: remove blk_flush_policy
On 6/10/24 10:19 PM, Christoph Hellwig wrote: Fold blk_flush_policy into the only caller to prepare for pending changes to it. Reviewed-by: Bart Van Assche
Re: [PATCH 11/26] block: freeze the queue in queue_attr_store
On 6/10/24 10:19 PM, Christoph Hellwig wrote: queue_attr_store updates attributes used to control generating I/O, and can cause malformed bios if changed with I/O in flight. Freeze the queue in common code instead of adding it to almost every attribute. Reviewed-by: Bart Van Assche
Re: [PATCH 09/26] nbd: move setting the cache control flags to __nbd_set_size
On 6/10/24 10:19 PM, Christoph Hellwig wrote: Move setting the cache control flags in nbd in preparation for moving these flags into the queue_limits structure. Reviewed-by: Bart Van Assche
Re: [PATCH 08/26] virtio_blk: remove virtblk_update_cache_mode
On 6/10/24 10:19 PM, Christoph Hellwig wrote: virtblk_update_cache_mode boils down to a single call to blk_queue_write_cache. Remove it in preparation for moving the cache control flags into the queue_limits. Reviewed-by: Bart Van Assche
Re: [PATCH 07/26] loop: fold loop_update_rotational into loop_reconfigure_limits
On 6/10/24 10:19 PM, Christoph Hellwig wrote: This prepares for moving the rotational flag into the queue_limits and also fixes it for the case where the loop device is backed by a block device. Reviewed-by: Bart Van Assche
Re: [PATCH 06/26] loop: also use the default block size from an underlying block device
On 6/10/24 10:19 PM, Christoph Hellwig wrote: Fix the code in loop_reconfigure_limits to pick a default block size for O_DIRECT file descriptors to also work when the loop device sits on top of a block device and not just on a regular file on a block device based file system. Reviewed-by: Bart Van Assche
Re: [PATCH 05/26] loop: regularize upgrading the lock size for direct I/O
On 6/10/24 10:19 PM, Christoph Hellwig wrote: The LOOP_CONFIGURE path automatically upgrades the block size to that of the underlying file for O_DIRECT file descriptors, but the LOOP_SET_BLOCK_SIZE path does not. Fix this by lifting the code to pick the block size into common code. Reviewed-by: Bart Van Assche
Re: [PATCH 04/26] loop: always update discard settings in loop_reconfigure_limits
On 6/10/24 10:19 PM, Christoph Hellwig wrote: Simplify loop_reconfigure_limits by always updating the discard limits. This adds a little more work to loop_set_block_size, but doesn't change the outcome as the discard flag won't change. Reviewed-by: Bart Van Assche
Re: [PATCH 01/26] sd: fix sd_is_zoned
On 6/10/24 10:19 PM, Christoph Hellwig wrote: Since commit 7437bb73f087 ("block: remove support for the host aware zone model"), only ZBC devices expose a zoned access model. sd_is_zoned is used to check for that and thus return false for host aware devices. Reviewed-by: Bart Van Assche
Re: [PATCH 03/26] loop: stop using loop_reconfigure_limits in __loop_clr_fd
On 6/10/24 10:19 PM, Christoph Hellwig wrote: __loop_clr_fd wants to clear all settings on the device. Prepare for moving more settings into the block limits by open coding loop_reconfigure_limits. If Damien's comment is addressed, feel free to add: Reviewed-by: Bart Van Assche
Re: [PATCH v3] scsi: sg: Avoid race in error handling & drop bogus warn
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
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
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(&sdp->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
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
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
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(&pg->kref, release_port_group); } - return true; + return sdev != NULL; } /*
Re: [PATCH v2 3/3] arch/*/: remove CONFIG_VIRT_TO_BUS
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
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
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
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
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(&bv, &flags); > + buf = bvec_kmap_local(&bv); > 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, &flags); > + 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
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
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
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
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
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
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
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
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)
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
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
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
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!
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) || > 26CHECK_DATA_CORRUPTION(prev->next != next, > 27
Re: [BUG][bisected 270065e] linux-next fails to boot on powerpc
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
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
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 > > > 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
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 > > 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&id=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
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&id=b0e17a9b0df29590c45dfb296f541270a5941f41 Thanks, Bart.
Re: WARNING: CPU: 15 PID: 0 at block/blk-mq.c:1111 __blk_mq_run_hw_queue+0x1d8/0x1f0
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
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 > 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
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
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 --- 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, &hctx->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
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 Cc: Benjamin Herrenschmidt Cc: Chris Metcalf Cc: David Woodhouse 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 Cc: Russell King --- 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
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 Cc: Benjamin Herrenschmidt Cc: Chris Metcalf Cc: David Woodhouse 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 Cc: Russell King --- 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
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 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 --- 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 &arm_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.c +++ b/arch/arm64/mm/dma-mapping.c @@ -837,7 +837,
Re: [PATCH 2/9] Move dma_ops from archdata into struct device
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
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 > > 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
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 = \&vmd->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 Reviewed-by: Christoph Hellwig Cc: Aurelien Jacquiot Cc: Catalin Marinas Cc: Chris Zankel Cc: David Howells Cc: David S. Miller Cc: Fenghua Yu Cc: Geert Uytterhoeven Cc: Geoff Levand Cc: Guan Xuetao Cc: H. Peter Anvin Cc: Haavard Skinnemoen Cc: Hans-Christian Egtvedt Cc: Helge Deller Cc: Ingo Molnar Cc: James E.J. Bottomley Cc: Jesper Nilsson Cc: Joerg Roedel Cc: Jon Mason Cc: Jonas Bonn Cc: Ley Foon Tan Cc: Mark Salter Cc: Max Filippov Cc: Mikael Starvik Cc: Muli Ben-Yehuda Cc: Rich Felker Cc: Russell King Cc: Stafford Horne Cc: Stefan Kristiansson Cc: Stefano Stabellini Cc: Thomas Gleixner Cc: Tony Luck Cc: Will Deacon Cc: x...@kernel.org Cc: Yoshinori Sato 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-mapping.h| 6 ++-- arch/frv/include/asm/dma-mapping.h | 4 +-- arch/frv/mb93090-mb00/pci-dma-nommu.c | 2 +- arch/frv/mb93090-mb00/pci-dma.c| 2 +- arch/h8300/include/asm/dma-mapping.h | 4 +-- arch/h8300/kernel/dma.c| 2 +- arch/hexagon/include/asm/dma-mapping.h | 4 +-- arch/hexagon/kernel/dma.c | 4 +-- arch/ia64/hp/common/hwsw_iommu.c | 4 +-- arch/ia64/hp/common/sba_iommu.c| 4 +-- arch/ia64/include/asm/dma-mapping.h| 2 +- arch/ia64/include/asm/machvec.h| 4 +-- arch/ia64/kernel/dma-mapping.c | 4 +-- arch/ia64/kernel/pci-dma.c
[PATCH 2/9] Move dma_ops from archdata into struct device
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 Cc: Greg Kroah-Hartman Cc: Aurelien Jacquiot Cc: Catalin Marinas Cc: Chris Zankel Cc: David Howells Cc: David S. Miller Cc: Fenghua Yu Cc: Geert Uytterhoeven Cc: Geoff Levand Cc: H. Peter Anvin Cc: Haavard Skinnemoen Cc: Hans-Christian Egtvedt Cc: Helge Deller Cc: Ingo Molnar Cc: James E.J. Bottomley Cc: Jesper Nilsson Cc: Joerg Roedel Cc: Jon Mason Cc: Jonas Bonn Cc: Ley Foon Tan Cc: Mark Salter Cc: Max Filippov Cc: Mikael Starvik Cc: Muli Ben-Yehuda Cc: Rich Felker Cc: Russell King Cc: Stafford Horne Cc: Stefan Kristiansson Cc: Thomas Gleixner Cc: Tony Luck Cc: Will Deacon Cc: x...@kernel.org Cc: Yoshinori Sato 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/asm/dma-mapping.h | 12 ++-- arch/x86/include/asm/device.h | 3 --- arch/x86/include/asm/dma-mapping.h| 9 + 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 | 7 ++- 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 +- drivers/misc/mic/bus/vop_bus.c| 2 +- include/linux/device.h| 2 ++ include/linux/dma-mapping.h | 12 56 files changed, 85 insertions(+), 140 deletions(-) diff --git a/arch/alpha/include/asm/dma-mapping.h b
Re: Regression in 3.15 on POWER8 with multipath SCSI
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
On Wed, Sep 9, 2009 at 11:22 PM, Wolfram Sang 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 > Cc: Bart Van Assche > Cc: Jean Delvare > --- > 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
Re: [PATCH 2.6.25.9] Make sure that include/asm-powerpc/spinlock.h does not trigger compilation warnings
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 , 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
[PATCH 2.6.25.9] Make sure that include/asm-powerpc/spinlock.h does not trigger compilation warnings
When compiling kernel modules for ppc that include , 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: section mismatch warnings in current git head for powerpc
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