alloc failure in qla1280 probe -- need to decrease can_queue?

2016-04-18 Thread Laura Abbott

Hi,

We received a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1321033
of qla1280 scsi host failure on 4.4 based kernels that looks to be caused
by page alloc failure:

[4.804166] scsi host0: QLogic QLA1040 PCI to SCSI Host Adapter
  Firmware version:  7.65.06, Driver version 3.27.1
[4.804174] [ cut here ]
[4.804184] WARNING: CPU: 2 PID: 305 at mm/page_alloc.c:2989 
__alloc_pages_nodemask+0xae8/0xbc0()
[4.804186] Modules linked in: amdkfd amd_iommu_v2 radeon i2c_algo_bit 
drm_kms_helper ttm drm megaraid_sas serio_raw 8021q garp bnx2 stp llc mrp 
sunhme qla1280(+) fjes
[4.804208] CPU: 2 PID: 305 Comm: systemd-udevd Not tainted 
4.4.6-201.fc22.x86_64 #1
[4.804210] Hardware name: Google Enterprise Search Appliance/0DT021, BIOS 
1.1.2 08/14/2006
[4.804212]  0286 2f01064c 88042985b710 
813b542e
[4.804216]   81a75024 88042985b748 
810a40f2
[4.804220]    000b 

[4.804223] Call Trace:
[4.804231]  [] dump_stack+0x63/0x85
[4.804236]  [] warn_slowpath_common+0x82/0xc0
[4.804239]  [] warn_slowpath_null+0x1a/0x20
[4.804242]  [] __alloc_pages_nodemask+0xae8/0xbc0
[4.804247]  [] ? _raw_spin_unlock_irqrestore+0xe/0x10
[4.804251]  [] ? irq_work_queue+0x8e/0xa0
[4.804256]  [] ? console_unlock+0x20a/0x540
[4.804262]  [] alloc_pages_current+0x8c/0x110
[4.804265]  [] alloc_kmem_pages+0x19/0x90
[4.804268]  [] kmalloc_order_trace+0x2e/0xe0
[4.804272]  [] __kmalloc+0x232/0x260
[4.804277]  [] init_tag_map+0x3d/0xc0
[4.804290]  [] __blk_queue_init_tags+0x45/0x80
[4.804293]  [] blk_init_tags+0x14/0x20
[4.804298]  [] scsi_add_host_with_dma+0x80/0x300
[4.804305]  [] qla1280_probe_one+0x683/0x9ef [qla1280]
[4.804309]  [] local_pci_probe+0x45/0xa0
[4.804312]  [] pci_device_probe+0xfd/0x140
[4.804316]  [] driver_probe_device+0x222/0x490
[4.804319]  [] __driver_attach+0x84/0x90
[4.804321]  [] ? driver_probe_device+0x490/0x490
[4.804324]  [] bus_for_each_dev+0x6c/0xc0
[4.804326]  [] driver_attach+0x1e/0x20
[4.804328]  [] bus_add_driver+0x1eb/0x280
[4.804331]  [] ? 0xa0015000
[4.804333]  [] driver_register+0x60/0xe0
[4.804336]  [] __pci_register_driver+0x4c/0x50
[4.804339]  [] qla1280_init+0x1ce/0x1000 [qla1280]
[4.804341]  [] ? 0xa0015000
[4.804345]  [] do_one_initcall+0xb3/0x200
[4.804348]  [] ? kmem_cache_alloc_trace+0x196/0x210
[4.804352]  [] ? do_init_module+0x27/0x1cb
[4.804354]  [] do_init_module+0x5f/0x1cb
[4.804358]  [] load_module+0x2040/0x2680
[4.804360]  [] ? __symbol_put+0x60/0x60
[4.804363]  [] SYSC_init_module+0x149/0x190
[4.804366]  [] SyS_init_module+0xe/0x10
[4.804369]  [] entry_SYSCALL_64_fastpath+0x12/0x71
[4.804371] ---[ end trace 0ea3b625f86705f7 ]---
[4.804581] qla1280: probe of :11:04.0 failed with error -12

This looks very similar to http://www.spinics.net/lists/linux-usb/msg136998.html
which was fixed by 55ff8cfbc4e1 ("USB: uas: Reduce can_queue to MAX_CMNDS").
Does a similar fix need to be applied here?

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


Greetings!!!

2016-04-18 Thread andreas122
Hi, how are you? My name is J Eric Denials, External Financial Auditor at 
Lloyds Banking Group plc., London. It is a pleasure to contact you at this time 
through this medium. I have a cool and legitimate deal to do with you as you're 
a foreigner, it will be mutually beneficial to both. If you’re interested, 
urgently, get back to me for more explanation about the deal.
Regards
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Greetings!!!

2016-04-18 Thread andreas11
Hi, how are you? My name is J Eric Denials, External Financial Auditor at 
Lloyds Banking Group plc., London. It is a pleasure to contact you at this time 
through this medium. I have a cool and legitimate deal to do with you as you're 
a foreigner, it will be mutually beneficial to both. If you’re interested, 
urgently, get back to me for more explanation about the deal.
Regards
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [dm-devel] [PATCH 04/42] fs: have submit_bh users pass in op and flags separately

2016-04-18 Thread Ryusuke Konishi
On Fri, 15 Apr 2016 05:39:24 -0500, mchri...@redhat.com wrote:
> From: Mike Christie 
> 
> This has submit_bh users pass in the operation and flags separately,
> so submit_bh_wbc can setup bio->bi_op and bio-bi_rw on the bio that
> is submitted.
> 
> Signed-off-by: Mike Christie 
> Reviewed-by: Christoph Hellwig 
> Reviewed-by: Hannes Reinecke 
> ---

Looks good with regard to nilfs2.

Acked-by: Ryusuke Konishi 


>  drivers/md/bitmap.c |  4 ++--
>  fs/btrfs/check-integrity.c  | 24 ++--
>  fs/btrfs/check-integrity.h  |  2 +-
>  fs/btrfs/disk-io.c  |  4 ++--
>  fs/buffer.c | 54 
> +++--
>  fs/ext4/balloc.c|  2 +-
>  fs/ext4/ialloc.c|  2 +-
>  fs/ext4/inode.c |  2 +-
>  fs/ext4/mmp.c   |  4 ++--
>  fs/fat/misc.c   |  2 +-
>  fs/gfs2/bmap.c  |  2 +-
>  fs/gfs2/dir.c   |  2 +-
>  fs/gfs2/meta_io.c   |  6 ++---
>  fs/jbd2/commit.c|  6 ++---
>  fs/jbd2/journal.c   |  8 +++
>  fs/nilfs2/btnode.c  |  6 ++---
>  fs/nilfs2/btnode.h  |  2 +-
>  fs/nilfs2/btree.c   |  6 +++--
>  fs/nilfs2/gcinode.c |  5 +++--
>  fs/nilfs2/mdt.c | 11 -
>  fs/ntfs/aops.c  |  6 ++---
>  fs/ntfs/compress.c  |  2 +-
>  fs/ntfs/file.c  |  2 +-
>  fs/ntfs/logfile.c   |  2 +-
>  fs/ntfs/mft.c   |  4 ++--
>  fs/ocfs2/buffer_head_io.c   |  8 +++
>  fs/reiserfs/inode.c |  4 ++--
>  fs/reiserfs/journal.c   |  6 ++---
>  fs/ufs/util.c   |  2 +-
>  include/linux/buffer_head.h |  9 
>  30 files changed, 103 insertions(+), 96 deletions(-)
> 
> diff --git a/drivers/md/bitmap.c b/drivers/md/bitmap.c
> index 3fe86b5..8b2e16f 100644
> --- a/drivers/md/bitmap.c
> +++ b/drivers/md/bitmap.c
> @@ -294,7 +294,7 @@ static void write_page(struct bitmap *bitmap, struct page 
> *page, int wait)
>   atomic_inc(>pending_writes);
>   set_buffer_locked(bh);
>   set_buffer_mapped(bh);
> - submit_bh(WRITE | REQ_SYNC, bh);
> + submit_bh(REQ_OP_WRITE, REQ_SYNC, bh);
>   bh = bh->b_this_page;
>   }
>  
> @@ -389,7 +389,7 @@ static int read_page(struct file *file, unsigned long 
> index,
>   atomic_inc(>pending_writes);
>   set_buffer_locked(bh);
>   set_buffer_mapped(bh);
> - submit_bh(READ, bh);
> + submit_bh(REQ_OP_READ, 0, bh);
>   }
>   block++;
>   bh = bh->b_this_page;
> diff --git a/fs/btrfs/check-integrity.c b/fs/btrfs/check-integrity.c
> index 9400acd..f82190f 100644
> --- a/fs/btrfs/check-integrity.c
> +++ b/fs/btrfs/check-integrity.c
> @@ -2856,12 +2856,12 @@ static struct btrfsic_dev_state 
> *btrfsic_dev_state_lookup(
>   return ds;
>  }
>  
> -int btrfsic_submit_bh(int rw, struct buffer_head *bh)
> +int btrfsic_submit_bh(int op, int op_flags, struct buffer_head *bh)
>  {
>   struct btrfsic_dev_state *dev_state;
>  
>   if (!btrfsic_is_initialized)
> - return submit_bh(rw, bh);
> + return submit_bh(op, op_flags, bh);
>  
>   mutex_lock(_mutex);
>   /* since btrfsic_submit_bh() might also be called before
> @@ -2870,26 +2870,26 @@ int btrfsic_submit_bh(int rw, struct buffer_head *bh)
>  
>   /* Only called to write the superblock (incl. FLUSH/FUA) */
>   if (NULL != dev_state &&
> - (rw & WRITE) && bh->b_size > 0) {
> + (op == REQ_OP_WRITE) && bh->b_size > 0) {
>   u64 dev_bytenr;
>  
>   dev_bytenr = 4096 * bh->b_blocknr;
>   if (dev_state->state->print_mask &
>   BTRFSIC_PRINT_MASK_SUBMIT_BIO_BH)
>   printk(KERN_INFO
> -"submit_bh(rw=0x%x, blocknr=%llu (bytenr %llu),"
> -" size=%zu, data=%p, bdev=%p)\n",
> -rw, (unsigned long long)bh->b_blocknr,
> +"submit_bh(op=0x%x,0x%x, blocknr=%llu "
> +"(bytenr %llu), size=%zu, data=%p, bdev=%p)\n",
> +op, op_flags, (unsigned long long)bh->b_blocknr,
>  dev_bytenr, bh->b_size, bh->b_data, bh->b_bdev);
>   btrfsic_process_written_block(dev_state, dev_bytenr,
> >b_data, 1, NULL,
> -   NULL, bh, rw);
> - } else if (NULL != dev_state && (rw & REQ_FLUSH)) {
> +   NULL, bh, op_flags);
> + } else if (NULL != dev_state && (op_flags & REQ_FLUSH)) {
> 

Re: [PATCH 16/42] nilfs: set bi_op to REQ_OP

2016-04-18 Thread Ryusuke Konishi
On Fri, 15 Apr 2016 14:15:51 -0500, mchri...@redhat.com wrote:
> From: Mike Christie 
> 
> This patch has nilfs use bio->bi_op for REQ_OPs and rq_flag_bits
> to bio->bi_rw.
> 
> Signed-off-by: Mike Christie 
> Reviewed-by: Christoph Hellwig 
> Reviewed-by: Hannes Reinecke 
> ---
>  fs/nilfs2/segbuf.c | 18 ++
>  1 file changed, 10 insertions(+), 8 deletions(-)

Looks good to me.

Acked-by: Ryusuke Konishi 

Thanks,
Ryuske Konishi

> 
> diff --git a/fs/nilfs2/segbuf.c b/fs/nilfs2/segbuf.c
> index 7666f1d..7b13e14 100644
> --- a/fs/nilfs2/segbuf.c
> +++ b/fs/nilfs2/segbuf.c
> @@ -350,7 +350,8 @@ static void nilfs_end_bio_write(struct bio *bio)
>  }
>  
>  static int nilfs_segbuf_submit_bio(struct nilfs_segment_buffer *segbuf,
> -struct nilfs_write_info *wi, int mode)
> +struct nilfs_write_info *wi, int mode,
> +int mode_flags)
>  {
>   struct bio *bio = wi->bio;
>   int err;
> @@ -368,7 +369,8 @@ static int nilfs_segbuf_submit_bio(struct 
> nilfs_segment_buffer *segbuf,
>  
>   bio->bi_end_io = nilfs_end_bio_write;
>   bio->bi_private = segbuf;
> - bio->bi_rw = mode;
> + bio->bi_op = mode;
> + bio->bi_rw = mode_flags;
>   submit_bio(bio);
>   segbuf->sb_nbio++;
>  
> @@ -442,7 +444,7 @@ static int nilfs_segbuf_submit_bh(struct 
> nilfs_segment_buffer *segbuf,
>   return 0;
>   }
>   /* bio is FULL */
> - err = nilfs_segbuf_submit_bio(segbuf, wi, mode);
> + err = nilfs_segbuf_submit_bio(segbuf, wi, mode, 0);
>   /* never submit current bh */
>   if (likely(!err))
>   goto repeat;
> @@ -466,19 +468,19 @@ static int nilfs_segbuf_write(struct 
> nilfs_segment_buffer *segbuf,
>  {
>   struct nilfs_write_info wi;
>   struct buffer_head *bh;
> - int res = 0, rw = WRITE;
> + int res = 0;
>  
>   wi.nilfs = nilfs;
>   nilfs_segbuf_prepare_write(segbuf, );
>  
>   list_for_each_entry(bh, >sb_segsum_buffers, b_assoc_buffers) {
> - res = nilfs_segbuf_submit_bh(segbuf, , bh, rw);
> + res = nilfs_segbuf_submit_bh(segbuf, , bh, REQ_OP_WRITE);
>   if (unlikely(res))
>   goto failed_bio;
>   }
>  
>   list_for_each_entry(bh, >sb_payload_buffers, b_assoc_buffers) {
> - res = nilfs_segbuf_submit_bh(segbuf, , bh, rw);
> + res = nilfs_segbuf_submit_bh(segbuf, , bh, REQ_OP_WRITE);
>   if (unlikely(res))
>   goto failed_bio;
>   }
> @@ -488,8 +490,8 @@ static int nilfs_segbuf_write(struct nilfs_segment_buffer 
> *segbuf,
>* Last BIO is always sent through the following
>* submission.
>*/
> - rw |= REQ_SYNC;
> - res = nilfs_segbuf_submit_bio(segbuf, , rw);
> + res = nilfs_segbuf_submit_bio(segbuf, , REQ_OP_WRITE,
> +   REQ_SYNC);
>   }
>  
>   failed_bio:
> -- 
> 2.7.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2] mpt3sas - remove unused fw_event_work elements

2016-04-18 Thread Joe Lawrence
Firmware events are queued up using the fw_event_work's struct work, not
its delayed_work member.  The initial driver for SAS2 controllers had
handled firmware reset using the rescan barrier and was later redesigned
through "mpt2sas: [Resend] Host Reset code cleanup".  The delayed_work
variables are now unused and may provoke CONFIG_DEBUG_OBJECTS_TIMERS
"assert_init not available" false warnings in
_scsih_fw_event_cleanup_queue.

Cleanup fw_event_work's unused entries, update it's kerneldoc, and update
_scsih_fw_event_cleanup_queue accordingly.

Fixes: 146b16c8071f (mpt3sas: Refcount fw_events and fix unsafe list usage)
Signed-off-by: Joe Lawrence 
---
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c 
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index e0e4920d0fa6..f2139e5604a3 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -174,13 +174,13 @@ struct sense_info {
  * struct fw_event_work - firmware event struct
  * @list: link list framework
  * @work: work object (ioc->fault_reset_work_q)
- * @cancel_pending_work: flag set during reset handling
  * @ioc: per adapter object
  * @device_handle: device handle
  * @VF_ID: virtual function id
  * @VP_ID: virtual port id
  * @ignore: flag meaning this event has been marked to ignore
- * @event: firmware event MPI2_EVENT_XXX defined in mpt2_ioc.h
+ * @event: firmware event MPI2_EVENT_XXX defined in mpi2_ioc.h
+ * @refcount: kref for this event
  * @event_data: reply event data payload follows
  *
  * This object stored on ioc->fw_event_list.
@@ -188,8 +188,6 @@ struct sense_info {
 struct fw_event_work {
struct list_headlist;
struct work_struct  work;
-   u8  cancel_pending_work;
-   struct delayed_work delayed_work;
 
struct MPT3SAS_ADAPTER *ioc;
u16 device_handle;
@@ -2804,12 +2802,12 @@ _scsih_fw_event_cleanup_queue(struct MPT3SAS_ADAPTER 
*ioc)
/*
 * Wait on the fw_event to complete. If this returns 1, then
 * the event was never executed, and we need a put for the
-* reference the delayed_work had on the fw_event.
+* reference the work had on the fw_event.
 *
 * If it did execute, we wait for it to finish, and the put will
 * happen from _firmware_event_work()
 */
-   if (cancel_delayed_work_sync(_event->delayed_work))
+   if (cancel_work_sync(_event->work))
fw_event_work_put(fw_event);
 
fw_event_work_put(fw_event);
-- 
1.8.3.1

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


Re: This patch triggers a bad gcc bug (was Re: [PATCH] force inlining of some byteswap operations)

2016-04-18 Thread Arnd Bergmann
On Monday 18 April 2016 08:39:32 Josh Poimboeuf wrote:
> 
> I agree.  So how should we work around the bug in this case?  There have
> been several suggestions:
> 
> - change wwn_to_u64() to __always_inline
> 
> - change qla2x00_get_host_fabric_name() to skip the unnecessary call to
>   wwn_to_u64()
> 
> - revert one of the two commits:
>   bc27fb68aaad ("include/uapi/linux/byteorder, swab: force inlining of some 
> byteswap operations")
>   ef3fb2422ffe ("scsi: fc: use get/put_unaligned64 for wwn access")

What about the patch to change get_unaligned_be64() that I posted?

I think we want to merge that anyway, I just don't know if that helps
with this particular problem as well.

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


Re: This patch triggers a bad gcc bug (was Re: [PATCH] force inlining of some byteswap operations)

2016-04-18 Thread Arnd Bergmann
On Monday 18 April 2016 09:12:41 Josh Poimboeuf wrote:
> On Mon, Apr 18, 2016 at 04:07:51PM +0200, Arnd Bergmann wrote:
> > On Monday 18 April 2016 08:39:32 Josh Poimboeuf wrote:
> > > 
> > > I agree.  So how should we work around the bug in this case?  There have
> > > been several suggestions:
> > > 
> > > - change wwn_to_u64() to __always_inline
> > > 
> > > - change qla2x00_get_host_fabric_name() to skip the unnecessary call to
> > >   wwn_to_u64()
> > > 
> > > - revert one of the two commits:
> > >   bc27fb68aaad ("include/uapi/linux/byteorder, swab: force inlining of 
> > > some byteswap operations")
> > >   ef3fb2422ffe ("scsi: fc: use get/put_unaligned64 for wwn access")
> > 
> > What about the patch to change get_unaligned_be64() that I posted?
> > 
> > I think we want to merge that anyway, I just don't know if that helps
> > with this particular problem as well.
> 
> I replied to your other email about that -- it doesn't seem to help this
> issue.
> 

Ok, I see. I had problems with my mail server last week, your reply
must have been a victim of that as I never saw it (found it on the
web archive now).

I'd vote for the wwn_to_u64 change then as it should prevent the
same thing from happining in other drivers. I would prefer not to
see ef3fb2422ffe reverted, as that works around another gcc-6 bug
on ARM.

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


Re: This patch triggers a bad gcc bug (was Re: [PATCH] force inlining of some byteswap operations)

2016-04-18 Thread Josh Poimboeuf
On Mon, Apr 18, 2016 at 04:07:51PM +0200, Arnd Bergmann wrote:
> On Monday 18 April 2016 08:39:32 Josh Poimboeuf wrote:
> > 
> > I agree.  So how should we work around the bug in this case?  There have
> > been several suggestions:
> > 
> > - change wwn_to_u64() to __always_inline
> > 
> > - change qla2x00_get_host_fabric_name() to skip the unnecessary call to
> >   wwn_to_u64()
> > 
> > - revert one of the two commits:
> >   bc27fb68aaad ("include/uapi/linux/byteorder, swab: force inlining of some 
> > byteswap operations")
> >   ef3fb2422ffe ("scsi: fc: use get/put_unaligned64 for wwn access")
> 
> What about the patch to change get_unaligned_be64() that I posted?
> 
> I think we want to merge that anyway, I just don't know if that helps
> with this particular problem as well.

I replied to your other email about that -- it doesn't seem to help this
issue.

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


Re: This patch triggers a bad gcc bug (was Re: [PATCH] force inlining of some byteswap operations)

2016-04-18 Thread Josh Poimboeuf
On Sat, Apr 16, 2016 at 11:03:32AM +0200, Ingo Molnar wrote:
> 
> * Josh Poimboeuf  wrote:
> 
> > > I don't think we know yet if there's a reliable way to turn the bug off.
> > > 
> > > Also, according to the gcc guys, this bug won't always result in a
> > > truncated function, and may sometimes just make some inline function
> > > call sites disappear:
> > > 
> > >   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646#c14
> > > 
> > > though I haven't been able to confirm that experimentally.  But if it's
> > > true, that means that objtool won't be able to detect all cases of the
> > > bug and some function calls may just silently disappear!
> > > 
> > > There's a lot of activity in the bug now, so hopefully they'll be able
> > > to tell us soon if there's a reliable way to avoid it and/or detect it.
> > > 
> > > BTW, Denys posted a workaround patch for the qla2 code:
> > > 
> > >   
> > > https://lkml.kernel.org/r/1460716583-15673-1-git-send-email-dvlas...@redhat.com
> > 
> > Martin Jambor wrote a succinct summary of the conditions needed for this
> > bug:
> > 
> >   "This bug can occur when an inlineable function containing a call to
> >   __builtin_constant_p, which checks a parameter or a value it
> >   references and a (possibly indirect) caller of the function actually
> >   passes a constant, but stores it using a type of a different size."
> > 
> > So to prevent it from happening elsewhere in the kernel, it sounds like
> > we'd have to either remove all uses of __builtin_constant_p() or disable
> > inlining completely.
> > 
> > There's also no reliable way to detect the bug has occurred, though
> > objtool will detect it in cases when the function gets truncated.
> 
> So it appears to me that due to the hard to detect nature of the GCC bug the 
> fix 
> will probably be backported by them, so I think we should be fine with 
> relying on 
> objtool to detect weird code sequences in the kernel, and should work around 
> specific instances of the bug.

I agree.  So how should we work around the bug in this case?  There have
been several suggestions:

- change wwn_to_u64() to __always_inline

- change qla2x00_get_host_fabric_name() to skip the unnecessary call to
  wwn_to_u64()

- revert one of the two commits:
  bc27fb68aaad ("include/uapi/linux/byteorder, swab: force inlining of some 
byteswap operations")
  ef3fb2422ffe ("scsi: fc: use get/put_unaligned64 for wwn access")


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


Re: This patch triggers a bad gcc bug (was Re: [PATCH] force inlining of some byteswap operations)

2016-04-18 Thread Josh Poimboeuf
On Sat, Apr 16, 2016 at 09:42:37AM +0200, Arnd Bergmann wrote:
> On Friday 15 April 2016 07:45:19 Ingo Molnar wrote:
> > 
> > * Denys Vlasenko  wrote:
> > 
> > > > In fact, the following patch seems to fix it:
> > > > 
> > > > diff --git a/include/scsi/scsi_transport_fc.h 
> > > > b/include/scsi/scsi_transport_fc.h
> > > > index bf66ea6..56b9e81 100644
> > > > --- a/include/scsi/scsi_transport_fc.h
> > > > +++ b/include/scsi/scsi_transport_fc.h
> > > > @@ -796,7 +796,7 @@ fc_remote_port_chkready(struct fc_rport *rport)
> > > > return result;
> > > >  }
> > > >  
> > > > -static inline u64 wwn_to_u64(u8 *wwn)
> > > > +static __always_inline u64 wwn_to_u64(u8 *wwn)
> > > >  {
> > > > return get_unaligned_be64(wwn);
> > > >  }
> > > 
> > > It is not a guarantee.
> > 
> > Of course it's a workaround - but is there any deterministic way to turn 
> > off this 
> > GCC bug (by activating some GCC command line switch), or do we have to live 
> > with 
> > objtool warning about this GCC?
> > 
> > Which, by the way, is pretty cool!
> 
> I have done a patch for the asm-generic/unaligned handling recently that
> reworks the implementation to avoid an ARM specific bug (gcc uses certain
> CPU instructions that require aligned data when we tell it that unaligned
> data is not).
> 
> It changes the code enough that the gcc bug might not be triggered any more,
> aside from generating far superior code in some cases.

I tried this patch, but unfortunately it doesn't make the gcc bug go
away.

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


Re: [PATCH] st: clear ILI if Medium Error

2016-04-18 Thread Laurence Oberman
Looks good
Reviewed-by Laurence Oberman 

Laurence Oberman
Principal Software Maintenance Engineer
Red Hat Global Support Services

- Original Message -
From: "Kai Makisara" 
To: linux-scsi@vger.kernel.org
Cc: mlomb...@redhat.com
Sent: Monday, April 18, 2016 1:47:18 AM
Subject: [PATCH] st: clear ILI if Medium Error

Some drives set the ILI flag together with MEDIUM ERROR
sense code. Clear the ILI flag in this case so that the
medium error will be handled. The problem was reported by
Maurizio Lombardi.

Signed-off-by: Kai Mäkisara 
---
 drivers/scsi/st.c |9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

--- a/drivers/scsi/st.c 2016-04-17 21:22:15.671897001 +0300
+++ b/drivers/scsi/st.c 2016-04-17 22:25:39.234321293 +0300
@@ -1974,9 +1974,12 @@ static long read_tape(struct scsi_tape *
transfer = (int)cmdstatp->uremainder64;
else
transfer = 0;
-   if (STp->block_size == 0 &&
-   cmdstatp->sense_hdr.sense_key == 
MEDIUM_ERROR)
-   transfer = bytes;
+   if (cmdstatp->sense_hdr.sense_key == 
MEDIUM_ERROR) {
+   if (STp->block_size == 0)
+   transfer = bytes;
+   /* Some drives set ILI with MEDIUM 
ERROR */
+   cmdstatp->flags &= ~SENSE_ILI;
+   }
 
if (cmdstatp->flags & SENSE_ILI) {  /* ILI 
*/
if (STp->block_size == 0 &&
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


IMPORTANT MAIL TO YOU

2016-04-18 Thread verifelaw
I am Capt. Lawrence Tyman, an officer in US Army,and also a West Point
Graduate, serving in the Military with the 82nd Air Borne Division
Peace keeping force deployed from Afganistan to Syria.  
We were moved to Syria from Iraq as the last batch just left,and i
really need your help in assisting me with the safe keeping of 1 military
trunk box contain funds amount of $10.2M which i secured on a raiding we 
carried out in 
January in one of the chief Syrian IsIs base which i headed the squard as the 
Captain.  With every possible arrangement to lift this box out, is intended to 
arrive 
Belgium from there a diplomat will deliver it to your designated location
I hope you can be trusted? You will be rewarded handsomely if you could help
me secure the funds until I conclude my service here in 3 month to meet you 
while we can 
plan head to head on a good and profitable business or company i can invest my 
funds in your country.
If you can be trusted and willing to support me in securing this safely kindly 
indicate 
by Letting me know this (1) Your name (2) Your address (3) Age (4) Occupation 
and 
i will explain further when i get a response from you
kindly contact me in this my private email address below: lawrencety...@gmx.com

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


[PATCH] SCSI: LIBSCSI: Fixed codeing style errors

2016-04-18 Thread Bob Stlt
Fixed codeing style formatting errors.

Signed-off-by: Bob Stlt 
---
 drivers/scsi/libiscsi.c | 90 -
 1 file changed, 45 insertions(+), 45 deletions(-)

diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index 6bffd91..41be9d3 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -197,7 +197,7 @@ static int iscsi_prep_ecdb_ahs(struct iscsi_task *task)
pad_len = iscsi_padding(rlen);
 
rc = iscsi_add_hdr(task, sizeof(ecdb_ahdr->ahslength) +
-  sizeof(ecdb_ahdr->ahstype) + ahslength + pad_len);
+   sizeof(ecdb_ahdr->ahstype) + ahslength + pad_len);
if (rc)
return rc;
 
@@ -210,10 +210,10 @@ static int iscsi_prep_ecdb_ahs(struct iscsi_task *task)
memcpy(ecdb_ahdr->ecdb, cmd->cmnd + ISCSI_CDB_SIZE, rlen);
 
ISCSI_DBG_SESSION(task->conn->session,
- "iscsi_prep_ecdb_ahs: varlen_cdb_len %d "
- "rlen %d pad_len %d ahs_length %d iscsi_headers_size "
- "%u\n", cmd->cmd_len, rlen, pad_len, ahslength,
- task->hdr_len);
+   "iscsi_prep_ecdb_ahs: varlen_cdb_len %d "
+   "rlen %d pad_len %d ahs_length %d iscsi_headers_size "
+   "%u\n", cmd->cmd_len, rlen, pad_len, ahslength,
+   task->hdr_len);
return 0;
 }
 
@@ -236,10 +236,10 @@ static int iscsi_prep_bidi_ahs(struct iscsi_task *task)
rlen_ahdr->read_length = cpu_to_be32(scsi_in(sc)->length);
 
ISCSI_DBG_SESSION(task->conn->session,
- "bidi-in rlen_ahdr->read_length(%d) "
- "rlen_ahdr->ahslength(%d)\n",
- be32_to_cpu(rlen_ahdr->read_length),
- be16_to_cpu(rlen_ahdr->ahslength));
+   "bidi-in rlen_ahdr->read_length(%d) "
+   "rlen_ahdr->ahslength(%d)\n",
+   be32_to_cpu(rlen_ahdr->read_length),
+   be16_to_cpu(rlen_ahdr->ahslength));
return 0;
 }
 
@@ -500,7 +500,7 @@ static void iscsi_free_task(struct iscsi_task *task)
if (conn->login_task == task)
return;
 
-   kfifo_in(>cmdpool.queue, (void*), sizeof(void*));
+   kfifo_in(>cmdpool.queue, (void *), sizeof(void *));
 
if (sc) {
/* SCSI eh reuses commands to verify us */
@@ -736,7 +736,7 @@ __iscsi_conn_send_pdu(struct iscsi_conn *conn, struct 
iscsi_hdr *hdr,
BUG_ON(conn->c_stage == ISCSI_CONN_STOPPED);
 
if (!kfifo_out(>cmdpool.queue,
-(void*), sizeof(void*)))
+(void *), sizeof(void *)))
return NULL;
}
/*
@@ -831,7 +831,7 @@ static void iscsi_scsi_cmd_rsp(struct iscsi_conn *conn, 
struct iscsi_hdr *hdr,
struct iscsi_session *session = conn->session;
struct scsi_cmnd *sc = task->sc;
 
-   iscsi_update_cmdsn(session, (struct iscsi_nopin*)rhdr);
+   iscsi_update_cmdsn(session, (struct iscsi_nopin *)rhdr);
conn->exp_statsn = be32_to_cpu(rhdr->statsn) + 1;
 
sc->result = (DID_OK << 16) | rhdr->cmd_status;
@@ -901,12 +901,12 @@ invalid_datalen:
}
 
if (rhdr->flags & (ISCSI_FLAG_CMD_UNDERFLOW |
-  ISCSI_FLAG_CMD_OVERFLOW)) {
+   ISCSI_FLAG_CMD_OVERFLOW)) {
int res_count = be32_to_cpu(rhdr->residual_count);
 
if (res_count > 0 &&
(rhdr->flags & ISCSI_FLAG_CMD_OVERFLOW ||
-res_count <= scsi_bufflen(sc)))
+   res_count <= scsi_bufflen(sc)))
/* write side for bidi or uni-io set_resid */
scsi_set_resid(sc, res_count);
else
@@ -939,7 +939,7 @@ iscsi_data_in_rsp(struct iscsi_conn *conn, struct iscsi_hdr 
*hdr,
sc->result = (DID_OK << 16) | rhdr->cmd_status;
conn->exp_statsn = be32_to_cpu(rhdr->statsn) + 1;
if (rhdr->flags & (ISCSI_FLAG_DATA_UNDERFLOW |
-  ISCSI_FLAG_DATA_OVERFLOW)) {
+   ISCSI_FLAG_DATA_OVERFLOW)) {
int res_count = be32_to_cpu(rhdr->residual_count);
 
if (res_count > 0 &&
@@ -978,7 +978,7 @@ static void iscsi_tmf_rsp(struct iscsi_conn *conn, struct 
iscsi_hdr *hdr)
 
 static int iscsi_send_nopout(struct iscsi_conn *conn, struct iscsi_nopin *rhdr)
 {
-struct iscsi_nopout hdr;
+   struct iscsi_nopout hdr;
struct iscsi_task *task;
 
if (!rhdr && conn->ping_task)
@@ -1080,7 +1080,7 @@ static int iscsi_handle_reject(struct iscsi_conn *conn, 
struct iscsi_hdr *hdr,
spin_unlock(>session->back_lock);
spin_lock(>session->frwd_lock);
  

Re: [PATCH] lpfc: remove incorrect lockdep assertion

2016-04-18 Thread Johannes Thumshirn
On Sonntag, 17. April 2016 13:27:27 CEST Sebastian Herbszt wrote:
> Remove incorrect lockdep assertion from lpfc_sli_hbqbuf_find() which acquires
> the hbalock itself. Fix the comment which resulted in this mistake.
> 
> Fixes: 1c2ba475eb0e ("lpfc: Add lockdep assertions")
> Signed-off-by: Sebastian Herbszt 
> 

Good catch,
Reviewed-by: Johannes Thumshirn 

-- 
Johannes Thumshirn  
  Storage
jthumsh...@suse.de 
+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850

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