I will pull out that patch from the drivers queue, thanks.
--
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
On Fri, May 30, 2014 at 02:50:11PM +0200, Jan Kasprzak wrote:
Not sure whether I should ack my own patch, though. But you may apply
it to the original one, which is identical to what I did.
http://marc.info/?l=linux-scsim=139277202005675w=2
Yes, that's what I will do.
Thanks a lot!
--
To
Hi all,
this is a first stab at implementing SMR support.
The powers that be decided to call the ATA implementation
'ZAC' (zoned access commands), and the SCSI implementation
'ZBC' (zoned block commands).
This is just basic enablement to get ZAC and ZBC drives
detected as such. None of the
ZBC (zoned block command aka 'SMR drives') devices will have
a new device type 0x14 assigned by T10. So add the necessary
mappings to sd.c and make it an alias for ATA ZAC devices.
Signed-off-by: Hannes Reinecke h...@suse.de
---
drivers/ata/libata-scsi.c | 8 +++-
drivers/scsi/scsi.c
Add new ATA device type for ZAC devices.
Signed-off-by: Hannes Reinecke h...@suse.de
---
drivers/ata/libata-core.c | 20 ++--
drivers/ata/libata-eh.c| 7 +--
drivers/ata/libata-scsi.c | 5 +++--
drivers/ata/libata-transport.c | 1 +
include/linux/libata.h
ata_dev_classify() just uses the 'lbah' and 'lbam'
fields from the taskfile, so we can as well use those
as arguments and rip out the custom code from sas_ata.
Signed-off-by: Hannes Reinecke h...@suse.de
---
drivers/ata/libahci.c | 11 +++
drivers/ata/libata-core.c |
On Thu, May 22, 2014 at 02:26:16AM +, Nicholas A. Bellinger wrote:
From: Nicholas Bellinger n...@linux-iscsi.org
Hi MST, MKP, Paolo Co,
Here is the v2 patch series for adding T1O protection information (PI)
SGL passthrough support between virtio-scsi LLD + vhost-scsi fabric
With Linus opening the merge window things should calm down now.
I've pushed the mvsas pciid update, and a revert of the be2scsi patch
that wasn't quite ready to the drivers-for-3.16 branch.
I've also created a new drivers-for-3.16-2 branch that contains the
remaining hpsa updates that might be
Do we have any good testcases for this, especially the scsilun_to_int
change? Can we export big enough luns from the target core or
scsi_debug? If not I'd really like to see that support to ease testing.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a
On 06/02/2014 10:58 AM, Christoph Hellwig wrote:
With Linus opening the merge window things should calm down now.
I've pushed the mvsas pciid update, and a revert of the be2scsi patch
that wasn't quite ready to the drivers-for-3.16 branch.
I've also created a new drivers-for-3.16-2 branch
On Mon, Jun 02, 2014 at 11:25:00AM +0300, Boaz Harrosh wrote:
Hi Christoph
Could you please add this very trivial patch for this merge window?
http://www.spinics.net/lists/linux-scsi/msg74774.html
my hack here: http://www.spinics.net/lists/linux-scsi/msg74775.html
Looks more like an ack
Looks more like an ack than a hack :)
Oops so I do need that coffee ;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
Looks good,
Reviewed-by: Christoph Hellwig h...@lst.de
--
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
On Mon, Jun 02, 2014 at 09:01:18AM +0200, Hannes Reinecke wrote:
ZBC (zoned block command aka 'SMR drives') devices will have
a new device type 0x14 assigned by T10. So add the necessary
mappings to sd.c and make it an alias for ATA ZAC devices.
The libata changes should defintively be a
On 06/02/2014 10:39 AM, Christoph Hellwig wrote:
On Mon, Jun 02, 2014 at 09:01:18AM +0200, Hannes Reinecke wrote:
ZBC (zoned block command aka 'SMR drives') devices will have
a new device type 0x14 assigned by T10. So add the necessary
mappings to sd.c and make it an alias for ATA ZAC devices.
On Mon, Jun 02, 2014 at 09:01:16AM +0200, Hannes Reinecke wrote:
ata_dev_classify() just uses the 'lbah' and 'lbam'
fields from the taskfile, so we can as well use those
as arguments and rip out the custom code from sas_ata.
There is no reason why SAS couldn't set up a taskfile structure
This also need to be run past the libata maintainers and the linux-ide
list..
+ if ((lbam == 0xcd) (lbah == 0xab)) {
The inner braces here aren't needed.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index e02b3aa..0788213 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -819,6 +819,7 @@ static int scsi_add_lun(struct scsi_device *sdev,
unsigned char *inq_result,
case TYPE_COMM:
case
On Mon, Jun 02, 2014 at 10:46:35AM +0200, Hannes Reinecke wrote:
But I'm uneasy with adding anything like this for now, for one the specs
aren't even anywhere close to done, and second attaching ZBC devices
in general doesn't sound like a very smart idea, we really need a
strategy for the
On 05/30/2014 04:59 PM, Neil Horman wrote:
debugfs caught this:
WARNING: at lib/debugobjects.c:260 debug_print_object+0x83/0xa0()
ODEBUG: free active (active state 0) object type: work_struct
hint: fc_scsi_scan_rport+0x0/0xd0 [scsi_transport_fc]
CPU: 1 PID: 184 Comm: kworker/1:1 Tainted: G
On Thu, May 29, 2014 at 10:53:02AM -0500, Stephen M. Cameron wrote:
From: Stephen M. Cameron scame...@beardog.cce.hp.com
No sense having 8 or 16 reply queues if you only have 4 cpus,
and likewise no sense limiting to 8 reply queues if you have
many more cpus.
I've applied this as it looks
scsi_put_command() is either invoked before blk_start_request() or
after block layer processing has completed. scsi_cmnd.abort_work
is scheduled from inside the SCSI timeout handler. The block layer
guarantees that either the regular completion handler
(softirq_done_fn()) or the timeout handler
John,
can you please review the endianess annotations and byte swaps in be2scsi?
On Thu, May 29, 2014 at 10:15:03PM +0800, kbuild test robot wrote:
tree: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
master
head: 07dd999f99b1135fdece697e17c4f4248ab40f72
commit:
From: Quinn Tran quinn.t...@qlogic.com
Fix sparse warning introduce by
commit f83adb617f55be13046191d83fa9110ff0689406
Author: Quinn Tran quinn.t...@qlogic.com
Date: Fri Apr 11 16:54:43 2014 -0400
qla2xxx: T10-Dif: add T10-PI support
Add support for T10-Dif for Target Mode to qla
On Mon, Jun 02, 2014 at 11:50:52AM +0200, Bart Van Assche wrote:
scsi_put_command() is either invoked before blk_start_request() or
after block layer processing has completed. scsi_cmnd.abort_work
is scheduled from inside the SCSI timeout handler. The block layer
guarantees that either the
On 06/02/2014 12:46 PM, Alain Kalker wrote:
Reduce the lernel log level to KERN_NOTICE for messages related
to a missing caching mode page.
Reasons why I think this change is justified:
- The condition is non-fatal; the existing workaround assumes
a write through cache. Although this reduces
Reduce the lernel log level to KERN_NOTICE for messages related
to a missing caching mode page.
Reasons why I think this change is justified:
- The condition is not an error; the existing workaround of assuming
a write through cache doesn't limit functionality in any way.
- It doesn't warrant a
On Fri, 30 May 2014, Arnd Bergmann wrote:
a) is this the right approach in general? The previous discussion
pointed this way, but there may be other opinions.
The syscall changes seem like the sort of thing I'd expect, although
patches adding new syscalls or otherwise affecting the
BLKSECTGET ioctl loads the request queue's max_sectors as unsigned
short value to the argument pointer. So if the max_sector is greater
than USHRT_MAX, the upper 16 bits of that is just discarded.
In such case, USHRT_MAX is more preferable than the lower 16 bits of
max_sectors.
Signed-off-by:
This patchset increases the SCSI mid level's limitation for max_sectors
upto the block layer's limitation for max_hw_sectors, and enables the
scsi_debug driver to request read/write commands with huge transfer
length. This also includes a few fixes for the problems which can be
caused by huge
SG_GET_RESERVED_SIZE and SG_SET_RESERVED_SIZE ioctls access a reserved
buffer in bytes as int type. The value needs to be capped at the request
queue's max_sectors. But integer overflow is not correctly handled in
the calculation when converting max_sectors from sectors to bytes.
Signed-off-by:
max_sectors in struct Scsi_Host specifies maximum number of sectors
allowed in a single SCSI command. The data type of max_sectors is
unsigned short, so the maximum transfer length per SCSI command is
limited to less than 256MB in 4096-bytes sector size. (0x * 4096)
This commit increases the
This prevents integer overflow when converting the request queue's
max_sectors from sectors to bytes. However, this is a preparation for
extending the data type of max_sectors in struct Scsi_Host and
scsi_host_template. So, it is impossible to happen this integer
overflow for now, because SCSI
This change makes the scsi disk driver handle the requests whose
transfer length is greater than 0x with READ_16 or WRITE_16.
However, this is a preparation for extending the data type of
max_sectors in struct Scsi_Host and scsi_host_template. So, it is
impossible to happen this condition
In _scsih_{slave,target}_alloc, an incorrect structure type is passed
to sizeof() when allocating storage for hostdata. Luckily larger
structure types were used, so at least the wrong sizes were safe:
struct scsi_device (1784 bytes) struct MPT2SAS_DEVICE (24 bytes)
struct scsi_target (760
Hello Sreekanth, Dan,
These are a few minor smatch and sparse static checker fixes for the LSI
mpt2 and mpt3 drivers. The first three fix real potential bugs and the
last cleans up a noisy complaint from sparse.
Joe Lawrence (4):
mpt2sas: correct scsi_{target,device} hostdata allocation
If mpt3sas_send_trigger_data_event exits early without inserting a
fw_event, be sure to undo any prior allocations.
This fixes the following smatch warning:
drivers/scsi/mpt3sas/mpt3sas_scsih.c:2522
mpt3sas_send_trigger_data_event() warn: possible memory leak of
'fw_event'
In _scsih_{slave,target}_alloc, an incorrect structure type is passed
to sizeof() when allocating storage for hostdata. Luckily larger
structure types were used, so at least the wrong sizes were safe:
struct scsi_device (1784 bytes) struct MPT3SAS_DEVICE (24 bytes)
struct scsi_target (760
The MPT2SAS_ADAPTER reply_post_host_index[] holds calculated addresses
in memory mapped register space. Add an __iomem annotation to silence
the following sparse warnings:
drivers/scsi/mpt2sas/mpt2sas_base.c:1006:43:
warning: incorrect type in argument 2 (different address spaces)
On Mon, Jun 02, 2014 at 02:27:51AM -0700, Christoph Hellwig wrote:
On Thu, May 29, 2014 at 10:53:02AM -0500, Stephen M. Cameron wrote:
From: Stephen M. Cameron scame...@beardog.cce.hp.com
No sense having 8 or 16 reply queues if you only have 4 cpus,
and likewise no sense limiting to 8
On Fri, 30 May 2014 19:07:36 +0200
Fabian Frederick f...@skynet.be wrote:
(memdup_user can be used to replace kmalloc/copy_from_user. Not sure if it's
ok with kzalloc ...)
+ kern_buf = memdup_user((void __user *)buf, nbytes);
+ if (IS_ERR(kern_buf)) {
+
Looks good.
Reviewed-By: Dick Kennedy dick.kenn...@emulex.com
--
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
On Mon, Jun 02, 2014 at 09:52:06AM -0500, scame...@beardog.cce.hp.com wrote:
On Mon, Jun 02, 2014 at 02:27:51AM -0700, Christoph Hellwig wrote:
On Thu, May 29, 2014 at 10:53:02AM -0500, Stephen M. Cameron wrote:
From: Stephen M. Cameron scame...@beardog.cce.hp.com
No sense having 8 or
On Sat, 2014-05-31 at 11:01 +0200, Hannes Reinecke wrote:
scsilun_to_int() has an error which prevents it from generating
correct LUN numbers for 64bit values.
Also we should remove the misleading comment about portions of
the LUN being ignored; the initiator should treat the LUN as
an opaque
On 05/31/14 11:01, Hannes Reinecke wrote:
-void int_to_scsilun(unsigned int lun, struct scsi_lun *scsilun)
+void int_to_scsilun(u64 lun, struct scsi_lun *scsilun)
Nothing important, but there is a memset() at the start of
int_to_scsilun(). I think this change makes that memset() superfluous.
On 05/31/14 11:01, Hannes Reinecke wrote:
u64 scsilun_to_int(struct scsi_lun *scsilun)
{
- int i;
- u64 lun;
+ const unsigned char * cp;
+ uint64_t res;
- lun = 0;
- for (i = 0; i sizeof(lun); i += 2)
- lun = lun | (((scsilun-scsi_lun[i] 8) |
-
Looks good,
Reviewed-by: Christoph Hellwig h...@lst.de
--
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
On Mon, Jun 02, 2014 at 10:37:26AM -0400, Joe Lawrence wrote:
If mpt3sas_send_trigger_data_event exits early without inserting a
fw_event, be sure to undo any prior allocations.
Looks good, but why don't we just allocate the two in a single
allocation?
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig h...@lst.de
--
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
On Mon, Jun 02, 2014 at 10:38:32AM -0400, Joe Lawrence wrote:
The MPT2SAS_ADAPTER reply_post_host_index[] holds calculated addresses
in memory mapped register space. Add an __iomem annotation to silence
the following sparse warnings:
Looks good,
Reviewed-by: Christoph Hellwig h...@lst.de
--
On Mon, Jun 02, 2014 at 10:34:28AM -0400, Joe Lawrence wrote:
Hello Sreekanth, Dan,
These are a few minor smatch and sparse static checker fixes for the LSI
mpt2 and mpt3 drivers. The first three fix real potential bugs and the
last cleans up a noisy complaint from sparse.
Can you check if
Sagi == Sagi Grimberg sa...@mellanox.com writes:
Sagi,
Sagi In various areas of the code, it is assumed that
Sagi se_cmd- data_length describes pure data. In case
Sagi that protection information exists over the wire (protect bits is
Sagi are on) the target core decrease the protection length
Akinobu == Akinobu Mita akinobu.m...@gmail.com writes:
Akinobu This change makes the scsi disk driver handle the requests
Akinobu whose transfer length is greater than 0x with READ_16 or
Akinobu WRITE_16.
Reviewed-by: Martin K. Petersen martin.peter...@oracle.com
--
Martin K. Petersen
Akinobu == Akinobu Mita akinobu.m...@gmail.com writes:
Akinobu This commit increases the SCSI mid level's limitation for
Akinobu max_sectors upto the block layer's limitation for
Akinobu max_hw_sectors by extending the data type of max_sectors in
Akinobu struct Scsi_Host and scsi_host_template,
On 14-06-02 09:56 AM, Akinobu Mita wrote:
This change enables to test read/write commands with huge transfer
length such as 1GB. For example:
# modprobe scsi_debug dev_size_mb=1024 clustering=1 opts=1
# cat /sys/block/$DEV/queue/max_hw_sectors_kb \
On 14-06-02 09:56 AM, Akinobu Mita wrote:
This prevents integer overflow when converting the request queue's
max_sectors from sectors to bytes. However, this is a preparation for
extending the data type of max_sectors in struct Scsi_Host and
scsi_host_template. So, it is impossible to happen
Akinobu == Akinobu Mita akinobu.m...@gmail.com writes:
Akinobu Also, this increases sg_tablesize and max_segment_size,
Akinobu otherwise the maximum transfer length is limited to 64MB.
Akinobu (sg_tablesize * max_segment_size = 256 * 256KB)
Things are easy for scsi_debug. And since we're not
Akinobu == Akinobu Mita akinobu.m...@gmail.com writes:
Akinobu BLKSECTGET ioctl loads the request queue's max_sectors as
Akinobu unsigned short value to the argument pointer. So if the
Akinobu max_sector is greater than USHRT_MAX, the upper 16 bits of that
Akinobu is just discarded.
Akinobu In
Reduce the lernel log level to KERN_NOTICE for messages related
to a missing caching mode page.
Reasons why I think this change is justified:
- The condition is not an error; the existing workaround of assuming
a write through cache doesn't limit functionality in any way.
- It doesn't warrant a
On 06/02/2014 08:48 PM, Alain Kalker wrote:
Reduce the lernel log level to KERN_NOTICE for messages related
to a missing caching mode page.
There is an open bug report at kernel.org (dating all the way back to
Linux 2.6.34.1) about this:
Bug 16490 – Assuming drive cache: write through
Until now the per-command transfer length has exclusively been gated by
the max_sectors parameter in the scsi_host template. Given that the size
of this parameter has been bumped to an unsigned int we have to be
careful not to exceed the target device's capabilities.
If the if the device
On 06/02/2014 09:14 PM, James Bottomley wrote:
On Mon, 2014-06-02 at 20:48 +0200, Alain Kalker wrote:
Reduce the lernel log level to KERN_NOTICE for messages related
to a missing caching mode page.
Reasons why I think this change is justified:
- The condition is not an error; the existing
On Mon, Jun 02, 2014 at 07:22:07PM +, James Bottomley wrote:
Actually, can you really pull it out, not just revert it? Reverts cause
problems with bisection and are unnecessary before the tree goes to
Linus.
If preserving history becomes a real goal, we'd have to move to a tip
like
On Mon, 2014-06-02 at 15:11 -0400, Martin K. Petersen wrote:
Until now the per-command transfer length has exclusively been gated by
the max_sectors parameter in the scsi_host template. Given that the size
of this parameter has been bumped to an unsigned int we have to be
careful not to exceed
On Monday 02 June 2014 12:26:22 H. Peter Anvin wrote:
On 06/02/2014 12:19 PM, Arnd Bergmann wrote:
On Monday 02 June 2014 13:52:19 Joseph S. Myers wrote:
On Fri, 30 May 2014, Arnd Bergmann wrote:
a) is this the right approach in general? The previous discussion
pointed this way, but
On Mon, 2014-06-02 at 12:33 -0700, h...@infradead.org wrote:
On Mon, Jun 02, 2014 at 07:22:07PM +, James Bottomley wrote:
Actually, can you really pull it out, not just revert it? Reverts cause
problems with bisection and are unnecessary before the tree goes to
Linus.
If
On Mon, Jun 2, 2014 at 12:33 PM, h...@infradead.org h...@infradead.org wrote:
Linus has been very unappy about rebasing close to or in the merge
window, and other subsystems generally revert patches that late in the
cycle as well. I'd prefer to stick to that model, but if you and Linus
On Mon, Jun 02, 2014 at 01:05:38PM -0700, Linus Torvalds wrote:
I would indeed prefer to avoid rebases, _unless_ the tree is a real
mess without it.
Now, what constitues real mess can vary. It can be just really ugly
history, and part of that can be it doesn't build or work at all
partway
On Mon, Jun 2, 2014 at 1:08 PM, h...@infradead.org h...@infradead.org wrote:
It's reverting a patch that just doesn't fix a problem fully, so the
prime reviewer and the patch author decided to withdraw it. It won't
cause any kind of problem during bisection.
If it isn't a particularly large
On Mon, Jun 02, 2014 at 01:24:22PM -0700, Linus Torvalds wrote:
If it isn't a particularly large patch and doesn't have any other
issues, I'd suggest just reverting it.
Particularly large patches can be worth undoing just to avoid
unnecessary noise in git blame etc, but that's an issue
On Wed, 2014-05-28 at 23:52 -0400, Martin K. Petersen wrote:
For commands like REQ_COPY we need a way to pass extra information along
with each bio. Like integrity metadata this information must be
available at the bottom of the stack so bi_private does not suffice.
Rename the existing
On Wed, 2014-05-28 at 23:52 -0400, Martin K. Petersen wrote:
Many modern SCSI devices support copy offloading operations in which one
can copy a block range from one LUN to another without the need for data
to be copied sent to the host and back. This is particularly useful for
things like
On Wed, 2014-05-28 at 23:52 -0400, Martin K. Petersen wrote:
blkdev_issue_copy() is a library function that filesystems can use to
clone block ranges between devices that support copy offloading. Both
source and target device must have max_copy_sectors 0 in the queue
limits.
On Wed, 2014-05-28 at 23:52 -0400, Martin K. Petersen wrote:
Add an ioctl which can be used to clone a block range within a single
block device. This is useful for testing the copy offload code.
Signed-off-by: Martin K. Petersen martin.peter...@oracle.com
---
block/ioctl.c | 35
On Wed, 2014-05-28 at 23:52 -0400, Martin K. Petersen wrote:
Copy offloading requires us to know the NAA descriptor for both source
target device. This descriptor is mandatory in the Device Identification
VPD page. Locate this descriptor in the returned VPD data so we don't
have to do lookups
On Mon, 2 Jun 2014 09:33:07 -0700
Christoph Hellwig h...@infradead.org wrote:
On Mon, Jun 02, 2014 at 10:34:28AM -0400, Joe Lawrence wrote:
Hello Sreekanth, Dan,
These are a few minor smatch and sparse static checker fixes for the LSI
mpt2 and mpt3 drivers. The first three fix real
On Wed, 2014-05-28 at 23:52 -0400, Martin K. Petersen wrote:
Implement support for hardware copy offload. This initial implementation
only supports EXTENDED COPY(LID1). If need be we can add support for
LID4 or token copy at a later date.
If a device has the 3PC flag set in the standard
On Mon, Jun 02, 2014 at 10:37:26AM -0400, Joe Lawrence wrote:
If mpt3sas_send_trigger_data_event exits early without inserting a
fw_event, be sure to undo any prior allocations.
Looks good, but why don't we just allocate the two in a single
allocation?
Hi Christoph,
The following
Il 29/05/2014 05:52, Martin K. Petersen ha scritto:
+ sdev_printk(KERN_ERR, sdev,
+ %s: VPD page 0x83 NAA descriptor not found\n, __func__);
+
+ return;
I suspect this error will be relatively common.
libata for example has
if (ata_id_has_wwn(args-id)) {
On Mon, 2 Jun 2014, Arnd Bergmann wrote:
Ok. Sorry about missing linux-api, I confused it with linux-arch, which
may not be as relevant here, except for the one question whether we
actually want to have the new ABI on all 32-bit architectures or only
as an opt-in for those that expect to stay
On 06/02/2014 12:55 PM, Arnd Bergmann wrote:
The bit that is really going to hurt is every single ioctl that uses a
timespec.
Honestly, though, I really don't understand the point with struct
inode_time. It seems like the zeroeth-order thing is to change the
kernel internal version of
On Thu, 2014-05-29 at 20:29 +, Quinn Tran wrote:
On 5/23/14 7:33 PM, Nicholas A. Bellinger n...@linux-iscsi.org wrote:
SNIP
diff --git a/drivers/scsi/qla2xxx/tcm_qla2xxx.c
b/drivers/scsi/qla2xxx/tcm_qla2xxx.c
index 68fb66f..34db344 100644
--- a/drivers/scsi/qla2xxx/tcm_qla2xxx.c
Regards,
Quinn Tran
On 6/2/14 3:12 PM, Nicholas A. Bellinger n...@linux-iscsi.org wrote:
Extra size note, the true value should be extracted from
ha-fw_xcb_count, if this field is set. Otherwise, default back to
TCM_QLA2XXX_DEFAULT_TAGS.
Ok, squashing the following patch into the original
On Fri, 2014-05-30 at 10:59 -0400, Neil Horman wrote:
debugfs caught this:
WARNING: at lib/debugobjects.c:260 debug_print_object+0x83/0xa0()
ODEBUG: free active (active state 0) object type: work_struct
hint: fc_scsi_scan_rport+0x0/0xd0 [scsi_transport_fc]
CPU: 1 PID: 184 Comm: kworker/1:1
84 matches
Mail list logo
