Re: [PATCH 0/7] Use 'Scsi_Host' as argument for host reset

2014-09-08 Thread Hannes Reinecke
On 09/07/2014 06:21 PM, Christoph Hellwig wrote: Did you plan to get back to this series and revisit it per the comments? I'd love to at least get the first preparatory patches in ASAP. Up to now I've been focussed on the printk series, and I've shelved this one as the initial feedback was to

ATTN::::: PROPOSAL

2014-09-08 Thread ST CHANG
China Steel Corporation (CSAC), is in urgent need of a reputable company,/firm or individual to serve as our financial coordinator in Canada, America, Europe, Uk. It's a part time job and pays well. If you are interested in working with us please reply: stchan...@yahoo.com.hk Thank you very

Re: I/O path cleanup

2014-09-08 Thread Bart Van Assche
On 09/07/14 18:31, Christoph Hellwig wrote: This series cleans up a couple of lose ends I noticed during the scsi-mq work, but which weren't important enough to address during the last cycle. Hello Christoph, Is there perhaps a public git tree available with this patch series ? I have tried

Re: [PATCH] bnx2i: Make boot_nic entry visible in the sysfs session objects

2014-09-08 Thread Maurizio Lombardi
Hi Cristoph, Jens, On 05/19/2014 01:32 PM, vikas.chaudh...@qlogic.com wrote: From: Tej Parkash tej.park...@qlogic.com Signed-off-by: Tej Parkash tej.park...@qlogic.com Signed-off-by: Vikas Chaudhary vikas.chaudh...@qlogic.com --- drivers/scsi/bnx2i/bnx2i_iscsi.c | 3 +++ 1 file changed,

Re: [PATCH] scsi_debug: deadlock between completions and surprise module removal

2014-09-08 Thread Bart Van Assche
On 09/06/14 16:40, Douglas Gilbert wrote: On 14-09-05 11:25 AM, Bart Van Assche wrote: An LLD must call scsi_remove_host() directly or indirectly from the module cleanup path. scsi_remove_host() triggers a call to blk_cleanup_queue(). That last function sets the flag QUEUE_FLAG_DYING which

Re: [GIT PULL] target updates for v3.17-rc3

2014-09-08 Thread Stephen Rothwell
Hi Nicholas, On Sun, 31 Aug 2014 17:51:07 -0700 Linus Torvalds torva...@linux-foundation.org wrote: On Sun, Aug 31, 2014 at 11:59 AM, Nicholas A. Bellinger n...@linux-iscsi.org wrote: Note that these patches where originally intended for -rc1, but missed the merge window. They are

[patch] xen-scsifront: use GFP_ATOMIC under spin_lock

2014-09-08 Thread Dan Carpenter
This function is only called with a spin_lock held and IRQs disabled. The allocation is not allowed to sleep and NOIO is not sufficient, it has to be ATOMIC. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com diff --git a/drivers/scsi/xen-scsifront.c b/drivers/scsi/xen-scsifront.c index

[patch] xen-scsiback: clean up a type issue in scsiback_make_tpg()

2014-09-08 Thread Dan Carpenter
This code was confusing because we had an unsigned long and then we compared it to UINT_MAX and then we stored it in a u16. How many bytes is this supposed to have: 2, 4 or 16??? I've made it a u16 throughout. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com diff --git

Re: [Xen-devel] [patch] xen-scsifront: use GFP_ATOMIC under spin_lock

2014-09-08 Thread Juergen Gross
On 09/08/2014 01:15 PM, Dan Carpenter wrote: This function is only called with a spin_lock held and IRQs disabled. The allocation is not allowed to sleep and NOIO is not sufficient, it has to be ATOMIC. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com Reviewed-by: Juergen Gross

Re: [Xen-devel] [patch] xen-scsiback: clean up a type issue in scsiback_make_tpg()

2014-09-08 Thread Juergen Gross
On 09/08/2014 01:17 PM, Dan Carpenter wrote: This code was confusing because we had an unsigned long and then we compared it to UINT_MAX and then we stored it in a u16. How many bytes is this supposed to have: 2, 4 or 16??? I've made it a u16 throughout. Signed-off-by: Dan Carpenter

Re: WARNING in block layer triggered in 3.17-rc3

2014-09-08 Thread Alan Stern
On Sun, 7 Sep 2014, Shirish Pargaonkar wrote: I think the problem is, when a gendisk is detached, its request queue is not put in bypass mode cause when it is re-attached, code tries to put it out of bypass mode, hence the warning. So either of these should work, I have not tested it, just

[Bug 84091] New: Unloading qla2xxx kernel module triggers segmentation fault

2014-09-08 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=84091 Bug ID: 84091 Summary: Unloading qla2xxx kernel module triggers segmentation fault Product: SCSI Drivers Version: 2.5 Kernel Version: 3.16.1 Hardware: x86-64

Re: WARNING in block layer triggered in 3.17-rc3

2014-09-08 Thread Shirish Pargaonkar
So should a request queue be in bypass mode when the device is being detached and queue is being unregistereed because requests can get queued up? On Mon, Sep 8, 2014 at 9:51 AM, Alan Stern st...@rowland.harvard.edu wrote: On Sun, 7 Sep 2014, Shirish Pargaonkar wrote: I think the problem is,

Re: [PATCH] scsi_debug: deadlock between completions and surprise module removal

2014-09-08 Thread Christoph Hellwig
On Mon, Sep 08, 2014 at 11:11:23AM +0200, Bart Van Assche wrote: Hello Doug, In the scsi_debug driver scsi_remove_host() is called from inside the sdebug_driver_remove() callback function. Unless I have missed something it is not guaranteed that that callback function is invoked before

[Bug 84091] Unloading qla2xxx kernel module triggers segmentation fault

2014-09-08 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=84091 Joe Lawrence joe.lawre...@stratus.com changed: What|Removed |Added CC|

Re: I/O path cleanup

2014-09-08 Thread Christoph Hellwig
On Mon, Sep 08, 2014 at 09:22:40AM +0200, Bart Van Assche wrote: On 09/07/14 18:31, Christoph Hellwig wrote: This series cleans up a couple of lose ends I noticed during the scsi-mq work, but which weren't important enough to address during the last cycle. Hello Christoph, Is there perhaps

Re: [PATCH V2] hpsa: refine the pci enable/disable handling

2014-09-08 Thread Tomas Henzl
On 09/07/2014 01:38 AM, Elliott, Robert (Server Storage) wrote: -Original Message- From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- ow...@vger.kernel.org] On Behalf Of Tomas Henzl ... +/* kdump kernel is loading, we don't know in which state is + * the pci

Re: Block/SCSI data integrity update v3

2014-09-08 Thread Jens Axboe
On 09/07/2014 10:29 AM, Christoph Hellwig wrote: On Thu, Aug 28, 2014 at 02:10:49PM -0600, Jens Axboe wrote: On 08/28/2014 01:31 PM, Martin K. Petersen wrote: This is the data integrity patch series originally submitted for 3.16 and 3.17. It has been rebased on top of block/for-3.18/core.

Re: WARNING in block layer triggered in 3.17-rc3

2014-09-08 Thread James Bottomley
On Mon, 2014-09-08 at 10:51 -0400, Alan Stern wrote: On Sun, 7 Sep 2014, Shirish Pargaonkar wrote: I think the problem is, when a gendisk is detached, its request queue is not put in bypass mode cause when it is re-attached, code tries to put it out of bypass mode, hence the warning.

Re: WARNING in block layer triggered in 3.17-rc3

2014-09-08 Thread Shirish Pargaonkar
see this issue/warning in 3.12 also. On Mon, Sep 8, 2014 at 10:51 AM, James Bottomley james.bottom...@hansenpartnership.com wrote: On Mon, 2014-09-08 at 10:51 -0400, Alan Stern wrote: On Sun, 7 Sep 2014, Shirish Pargaonkar wrote: I think the problem is, when a gendisk is detached, its

[Bug 84091] Unloading qla2xxx kernel module triggers segmentation fault

2014-09-08 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=84091 --- Comment #2 from Bart Van Assche bvanass...@acm.org --- This issue doesn't occur anymore with that patch applied. Thanks ! -- You are receiving this mail because: You are watching the assignee of the bug. -- To unsubscribe from this list:

Re: [Xen-devel] [patch] xen-scsifront: use GFP_ATOMIC under spin_lock

2014-09-08 Thread David Vrabel
On 08/09/14 12:15, Dan Carpenter wrote: This function is only called with a spin_lock held and IRQs disabled. The allocation is not allowed to sleep and NOIO is not sufficient, it has to be ATOMIC. Applied this and the scsiback one to devel/for-linus-3.18. Thanks. David -- To unsubscribe

Re: WARNING in block layer triggered in 3.17-rc3

2014-09-08 Thread Alan Stern
On Mon, 8 Sep 2014, James Bottomley wrote: Jens and James, it appears the problem is in blk_register_queue(). The code does this: /* * Initialization must be complete by now. Finish the initial * bypass from queue allocation. */

Re: [PATCH 0/6] blk-mq: initialize pdu of flush req explicitly

2014-09-08 Thread Jens Axboe
On 09/08/2014 10:55 AM, Ming Lei wrote: On Mon, Sep 8, 2014 at 2:49 AM, Christoph Hellwig h...@lst.de wrote: This works fine for me, although I still don't really like it very much. If you really want to go down the path of major surgery in this area we should probably allocate a flush

RE:

2014-09-08 Thread Deborah Mayher
From: Deborah Mayher Sent: Monday, September 08, 2014 10:13 AM To: Deborah Mayher Subject: IT_Helpdesk is currently migrating from old outlook to the new Outlook Web access 2014 to strengthen our security. You need to update your account immediately for

RE: [PATCH 1/1] Drivers: scsi: storvsc: Get rid of warning messages

2014-09-08 Thread KY Srinivasan
-Original Message- From: Christoph Hellwig [mailto:h...@infradead.org] Sent: Thursday, September 4, 2014 10:40 PM To: KY Srinivasan Cc: linux-ker...@vger.kernel.org; de...@linuxdriverproject.org; oher...@suse.com; jbottom...@parallels.com; linux-scsi@vger.kernel.org Subject: Re:

Re: [PATCH] scsi_debug: deadlock between completions and surprise module removal

2014-09-08 Thread Douglas Gilbert
On 14-09-08 11:07 AM, Christoph Hellwig wrote: On Mon, Sep 08, 2014 at 11:11:23AM +0200, Bart Van Assche wrote: Hello Doug, In the scsi_debug driver scsi_remove_host() is called from inside the sdebug_driver_remove() callback function. Unless I have missed something it is not guaranteed that

RE: [PATCH 0/6] blk-mq: initialize pdu of flush req explicitly

2014-09-08 Thread Elliott, Robert (Server Storage)
-Original Message- From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- ow...@vger.kernel.org] On Behalf Of Ming Lei Sent: Monday, 08 September, 2014 11:55 AM To: Christoph Hellwig Cc: Jens Axboe; Linux Kernel Mailing List; Linux SCSI List Subject: Re: [PATCH 0/6] blk-mq:

Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM

2014-09-08 Thread Luis R. Rodriguez
On Fri, Sep 5, 2014 at 3:40 PM, Tejun Heo t...@kernel.org wrote: Hello, Luis. On Fri, Sep 05, 2014 at 11:12:17AM -0700, Luis R. Rodriguez wrote: Meanwhile we are allowing a major design consideration such as a 30 second timeout for both init + probe all of a sudden become a hard requirement

Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM

2014-09-08 Thread Tejun Heo
Hello, Luis. On Mon, Sep 08, 2014 at 06:04:23PM -0700, Luis R. Rodriguez wrote: I have no idea how the selection should be. It could be per-insmod or maybe just a system-wide flag with explicit exceptions marked on drivers is good enough. I don't know. Its perfectly understandable if

Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM

2014-09-08 Thread Tejun Heo
On Tue, Sep 09, 2014 at 10:10:59AM +0900, Tejun Heo wrote: * Identify cases which can't be asynchronous and make them synchronous. e.g. keep who's doing request_module() and avoid asynchronous probing if current is probing one of those. That wouldn't work as we don't know what's gonna

Re: WARNING in block layer triggered in 3.17-rc3

2014-09-08 Thread Tejun Heo
Hello, On Mon, Sep 08, 2014 at 01:42:44PM -0400, Alan Stern wrote: This looks like a nasty hack. In theory the QUEUE_FLAG_INIT_DONE should be unset on blk_unregister_queue() to match the teardown; it's only accident it isn't. del_gendisk() in sd_remove() is supposed to tear a lot of

Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM

2014-09-08 Thread Tejun Heo
On Tue, Sep 09, 2014 at 10:10:59AM +0900, Tejun Heo wrote: I'm not too convinced this is such a difficult problem to figure out. We already have most of logic in place and the only thing missing is how to switch it. Wouldn't something like the following work? * Add a sysctl knob to enable

Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM

2014-09-08 Thread Luis R. Rodriguez
On Mon, Sep 8, 2014 at 6:22 PM, Tejun Heo t...@kernel.org wrote: On Tue, Sep 09, 2014 at 10:10:59AM +0900, Tejun Heo wrote: I'm not too convinced this is such a difficult problem to figure out. We already have most of logic in place and the only thing missing is how to switch it. Wouldn't

Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM

2014-09-08 Thread Tejun Heo
On Mon, Sep 08, 2014 at 06:26:04PM -0700, Luis R. Rodriguez wrote: Alternatively, add a module-generic param async_probe or whatever and use that to switch the behavior should work too. I don't know which way is better but either should work fine. I take it by this you meant a generic

Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM

2014-09-08 Thread Luis R. Rodriguez
On Mon, Sep 8, 2014 at 6:29 PM, Tejun Heo t...@kernel.org wrote: On Mon, Sep 08, 2014 at 06:26:04PM -0700, Luis R. Rodriguez wrote: Alternatively, add a module-generic param async_probe or whatever and use that to switch the behavior should work too. I don't know which way is better but

Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM

2014-09-08 Thread Tejun Heo
Hello, On Mon, Sep 08, 2014 at 06:38:34PM -0700, Luis R. Rodriguez wrote: OK then one only concern I would have with this is that the presence of such a flag doesn't necessarily mean that all drivers on a system have been tested for asynch probe yet. I'd feel much more comfortable Given that

Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM

2014-09-08 Thread Luis R. Rodriguez
On Mon, Sep 8, 2014 at 6:47 PM, Tejun Heo t...@kernel.org wrote: Hello, On Mon, Sep 08, 2014 at 06:38:34PM -0700, Luis R. Rodriguez wrote: OK then one only concern I would have with this is that the presence of such a flag doesn't necessarily mean that all drivers on a system have been

Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM

2014-09-08 Thread Tejun Heo
Hello, On Mon, Sep 08, 2014 at 07:28:58PM -0700, Luis R. Rodriguez wrote: Given that the behvaior change is from driver core and that device probing can happen post-loading anyway, Ah but lets not forget Dmitry's requirement which is for in-kernel drivers. We'd need to deal with both

Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM

2014-09-08 Thread Luis R. Rodriguez
On Mon, Sep 8, 2014 at 7:39 PM, Tejun Heo t...@kernel.org wrote: Hello, On Mon, Sep 08, 2014 at 07:28:58PM -0700, Luis R. Rodriguez wrote: Given that the behvaior change is from driver core and that device probing can happen post-loading anyway, Ah but lets not forget Dmitry's requirement

Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM

2014-09-08 Thread Tejun Heo
On Mon, Sep 08, 2014 at 07:57:28PM -0700, Luis R. Rodriguez wrote: I think we just should make exceptions sensible so that it works fine in practice for now (and I don't think that'd be too hard). So, the only cooperation necessary from userland would be just saying I don't wanna wait

Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM

2014-09-08 Thread Luis R. Rodriguez
On Mon, Sep 8, 2014 at 8:03 PM, Tejun Heo t...@kernel.org wrote: On Mon, Sep 08, 2014 at 07:57:28PM -0700, Luis R. Rodriguez wrote: I think we just should make exceptions sensible so that it works fine in practice for now (and I don't think that'd be too hard). So, the only cooperation

Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM

2014-09-08 Thread Tejun Heo
Hello, On Mon, Sep 08, 2014 at 08:19:12PM -0700, Luis R. Rodriguez wrote: On the systemd side of things it should enable this sysctl and for older kernels what should it do? Supposing the change is backported via -stable, it can try to set the sysctl on all kernels. If the knob doesn't exist,

Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM

2014-09-08 Thread James Bottomley
On Tue, 2014-09-09 at 10:10 +0900, Tejun Heo wrote: Hello, Luis. On Mon, Sep 08, 2014 at 06:04:23PM -0700, Luis R. Rodriguez wrote: I have no idea how the selection should be. It could be per-insmod or maybe just a system-wide flag with explicit exceptions marked on drivers is good