Re: [PATCH v2 0/2] scsi: storvsc: Add support for FC lightweight host.
On Sun, Jan 29, 2017 at 12:35:32AM +, KY Srinivasan wrote: > Windows has chosen this model for virtualizing FC devices to the guest - > without rports (or vports). As I noted in my earlier email, James came > up with this notion of a lightweight template almost a year ago. We can > certainly pick a more appropriate name and include better documentation. Can we take a step back and figure out what you're trying to archive here. storsvc is a paravirtualized device interface, and whatever underlies it should be of no relevance for the guest. Despite that fact Microsoft apparently wants to expose a FC-like port_name and node_name to guests for some virtual disks. Can you please explain what the guest is supposed to use them for? And second I'd like to understand what the fascination with the FC transport class is to expose these two attributes. Given that your sysfs layout will be entirely different from real FC devices I simply don't see any need for that. Why can't this whole thing simply be solved by adding sdev_attrs for the port_name and node_name to storsvc directly? -- 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] storvsc: remove bogus code to transfer struct scatterlist
Remove a piece of code in storvsc_queuecommand that tries to pass the
physical address of the kernel struct scatterlist pointer to the host.
Fortunately the code can't ever be reached anyway.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/storvsc_drv.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 05526b7..62f4545 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1511,13 +1511,6 @@ static int storvsc_queuecommand(struct Scsi_Host *host,
struct scsi_cmnd *scmnd)
page_to_pfn(sg_page((cur_sgl)));
cur_sgl = sg_next(cur_sgl);
}
-
- } else if (scsi_sglist(scmnd)) {
- payload->range.len = length;
- payload->range.offset =
- virt_to_phys(scsi_sglist(scmnd)) & (PAGE_SIZE-1);
- payload->range.pfn_array[0] =
- virt_to_phys(scsi_sglist(scmnd)) >> PAGE_SHIFT;
}
cmd_request->payload = payload;
--
2.1.4
--
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 1/2] qla2xxx: Fix a recently introduced memory leak
Hi Bart,
thanks for the analysis. I think the main issue here is that we shouldn't
try to assign affinity masks if there are not affinity vectors left to
assign.
Does the patch below fix the issue for you?
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 50c5003..96c0713 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -1206,6 +1206,11 @@ int pci_alloc_irq_vectors_affinity(struct pci_dev *dev,
unsigned int min_vecs,
if (flags & PCI_IRQ_AFFINITY) {
if (!affd)
affd = &msi_default_affd;
+
+ if (affd->pre_vectors + affd->post_vectors > min_vecs)
+ return -EINVAL;
+ if (affd->pre_vectors + affd->post_vectors == min_vecs)
+ flags &=~ PCI_IRQ_AFFINITY;
} else {
if (WARN_ON(affd))
affd = NULL;
--
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
[Bug 176951] boot fails unless acpi=off Acer Travelmate X-349
https://bugzilla.kernel.org/show_bug.cgi?id=176951 --- Comment #20 from Martin Goyot --- A new Bios update is available on Acer's website: https://www.acer.com/ac/en/GB/content/support-product/6917?b=1 v1.08 apparently. If anyone has tried it, does it solve the remaining problems? -- You are receiving this mail because: You are watching the assignee of the bug. -- 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 1/2] qla2xxx: Fix a recently introduced memory leak
On Sun, 2017-01-29 at 10:07 +0100, h...@lst.de wrote:
> Hi Bart,
>
> thanks for the analysis. I think the main issue here is that we shouldn't
> try to assign affinity masks if there are not affinity vectors left to
> assign.
>
> Does the patch below fix the issue for you?
>
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index 50c5003..96c0713 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -1206,6 +1206,11 @@ int pci_alloc_irq_vectors_affinity(struct pci_dev
> *dev, unsigned int min_vecs,
> if (flags & PCI_IRQ_AFFINITY) {
> if (!affd)
> affd = &msi_default_affd;
> +
> + if (affd->pre_vectors + affd->post_vectors > min_vecs)
> + return -EINVAL;
> + if (affd->pre_vectors + affd->post_vectors == min_vecs)
> + flags &=~ PCI_IRQ_AFFINITY;
> } else {
> if (WARN_ON(affd))
> affd = NULL;
Hello Christoph,
Thanks for the quick reply. Sorry but the above patch didn't help - the
PCI_IRQ_AFFINITY isn't tested after the above code clears it. But after I
changed "flags &=~ PCI_IRQ_AFFINITY" into "affd = NULL" the memory
corruption complaint was gone and I/O through the qla2xxx adapter
was still working fine. If you want you can add the following to the above
patch with the aforementioned change:
Tested-by: Bart Van Assche
Bart.
Re: Advanced Format SAT devices show incorrect physical block size
On Wednesday 11 January 2017 16:23:29 Alan Stern wrote:
> On Tue, 10 Jan 2017, James Bottomley wrote:
> > On Tue, 2017-01-10 at 16:00 -0500, Alan Stern wrote:
> > > In theory, I suppose we could change the kernel so that it would
> > > default to READ CAPACITY(16) for devices that report a SCSI level
> > > >= 3, or something along those lines. In general we hesitate to
> > > make changes of this sort, because they almost always end up
> > > breaking _some_ devices -- and if that happens then the change
> > > is reverted, with no exceptions. Linus has a very strict rule
> > > about not breaking working systems.
> >
> > You shouldn't have to change anything: it already does (otherwise
> > how else would we detect physical exponent for proper SCSI
> > devices) see sd.c:sd_try_rc16_first(). It always returns false
> > for USB because you set sdev->try_rc_10_first
>
> In fact, this approach probably won't work. See Bugzilla entries
> #43265 and #43391. The devices in those reports claimed to be ANSI
> level 4, but they failed anyway.
Seems those devices return capacity 0x7F0001 or 0xFF0001
Maybe there is some error pattern?
> If you guys want to try the quirk flag, you can apply the patch
> below. Then set the usb-storage module parameter quirks=::k
> where and are the Vendor and Product ID codes for your
> device (as 4 hex digits).
>
> In the long run, however, this is not a viable approach. We'd be
> better off with an explicit blacklist.
Ok, so what are next steps? I think that explicit blacklist would be
needed if "bad" devices is less.
How many bug reports were there?
> Alan Stern
>
>
>
> Index: usb-4.x/drivers/usb/storage/usb.c
> ===
> --- usb-4.x.orig/drivers/usb/storage/usb.c
> +++ usb-4.x/drivers/usb/storage/usb.c
> @@ -498,7 +498,7 @@ void usb_stor_adjust_quirks(struct usb_d
> US_FL_INITIAL_READ10 | US_FL_WRITE_CACHE |
> US_FL_NO_ATA_1X | US_FL_NO_REPORT_OPCODES |
> US_FL_MAX_SECTORS_240 | US_FL_NO_REPORT_LUNS |
> - US_FL_ALWAYS_SYNC);
> + US_FL_ALWAYS_SYNC | US_FL_NEEDS_CAP16);
>
> p = quirks;
> while (*p) {
> @@ -551,6 +551,9 @@ void usb_stor_adjust_quirks(struct usb_d
> case 'j':
> f |= US_FL_NO_REPORT_LUNS;
> break;
> + case 'k':
> + f |= US_FL_NEEDS_CAP16;
> + break;
> case 'l':
> f |= US_FL_NOT_LOCKABLE;
> break;
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH 0/6] ncr5380: Miscellaneous minor patches
Hi Finn, Am 16.01.2017 um 12:50 schrieb Finn Thain: > This series removes some unused code and related comments, > addresses the warnings generated by 'make W=1' and 'make C=1' > and fixes a theoretical bug in the bus reset method in atari_scsi. > > There's also a patch to add a missing error check during target > selection. The only target I tested was a QUANTUM DAYTONA514S disk > as that's all I have access to right now. Some testing with other > targets would be prudent. > > Michael, Ondrej, can I get you to review/test please? No regressions during testing on my Falcon both using default settings, i.e. can_queue=1 or internal queueing (can_queue=4, cmd_per_lun=2), and the legacy IDE driver. I've seen a bus reset executed when reloading the module (bus jammed for some reason apparently), so that code path has been tested as well. No change in the weird behaviour of my SCSI-SATA adapter, but perhaps that wasn't unexpected. Targets: Disks Seagate ST34520W and IBM DORS-32160W, CD-ROM Plextor PX-40TS. Tested-by: Michael Schmitz > > > Finn Thain (6): > ncr5380: Shorten host info string by removing unused option macros > ncr5380: Clean up dead code and redundant macro usage > ncr5380: Reduce #include files > ncr5380: Resolve various static checker warnings > ncr5380: Improve target selection robustness > atari_scsi: Reset DMA during bus reset only under ST-DMA lock > > drivers/scsi/NCR5380.c| 64 ++--- > drivers/scsi/NCR5380.h| 17 +--- > drivers/scsi/atari_scsi.c | 36 ++-- > drivers/scsi/g_NCR5380.c | 45 +++- > drivers/scsi/g_NCR5380.h | 56 - > drivers/scsi/mac_scsi.c | 8 ++-- > drivers/scsi/sun3_scsi.c | 83 +++-- > drivers/scsi/sun3_scsi.h | 102 > -- > 8 files changed, 152 insertions(+), 259 deletions(-) > delete mode 100644 drivers/scsi/g_NCR5380.h > delete mode 100644 drivers/scsi/sun3_scsi.h > -- 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 0/6] ncr5380: Miscellaneous minor patches
On Mon, 30 Jan 2017, Michael Schmitz wrote: > > Michael, Ondrej, can I get you to review/test please? > > No regressions during testing on my Falcon both using default settings, > i.e. can_queue=1 or internal queueing (can_queue=4, cmd_per_lun=2), and > the legacy IDE driver. > > I've seen a bus reset executed when reloading the module (bus jammed for > some reason apparently), so that code path has been tested as well. > > No change in the weird behaviour of my SCSI-SATA adapter, but perhaps > that wasn't unexpected. > Well, I guess we eliminated one possibility. Could be a bus termination issue perhaps? > Targets: Disks Seagate ST34520W and IBM DORS-32160W, CD-ROM Plextor > PX-40TS. > > Tested-by: Michael Schmitz Thanks, Michael. -- -- 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: split scsi passthrough fields out of struct request V2
On 01/27/2017 10:27 PM, Bart Van Assche wrote: > On Wed, 2017-01-25 at 18:25 +0100, Christoph Hellwig wrote: >> this series splits the support for SCSI passthrough commands from the >> main struct request used all over the block layer into a separate >> scsi_request structure that drivers that want to support SCSI passthough >> need to embedded as the first thing into their request-private data, >> similar to how we handle NVMe passthrough commands. >> >> To support this I've added support for that the private data after >> request structure to the legacy request path instead, so that it can >> be treated the same way as the blk-mq path. Compare to the current >> scsi_cmnd allocator that actually is a major simplification. >> >> Changes since V1: >> - fix handling of a NULL sense pointer in __scsi_execute >> - clean up handling of the flush flags in the block layer and MD >> - additional small cleanup in dm-rq > > Hello Christoph, > > A general comment: patch "block: allow specifying size for extra > command data" is a very welcome improvement but unfortunately also > introduces an inconsistency among block drivers. This patch series > namely creates two kinds of block drivers: > - Block drivers that use the block layer core to allocate > request-private data. These block drivers set request.cmd_size > to a non-zero value and do not need request.special. > - Block drivers that allocate request-private data themselves. > These block drivers set request.cmd_size to zero and use > request.special to translate a request pointer into the private > data pointer. > > Have you considered to convert all block drivers to the new > approach and to get rid of request.special? If so, do you already > have plans to start working on this? I'm namely wondering wheter I > should start working on this myself. > I was actually looking into it, too. Once scsi passthrough is removed from struct request there is no reasonable need to rely on '->special' for anything, and we should just ditch it. Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- 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: [RFC PATCH] scsi, block: fix duplicate bdi name registration crashes
On 01/29/2017 05:58 AM, Dan Williams wrote: > Warnings of the following form occur because scsi reuses a devt number > while the block layer still has it referenced as the name of the bdi > [1]: > > WARNING: CPU: 1 PID: 93 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x62/0x80 > sysfs: cannot create duplicate filename '/devices/virtual/bdi/8:192' > [..] > Call Trace: > dump_stack+0x86/0xc3 > __warn+0xcb/0xf0 > warn_slowpath_fmt+0x5f/0x80 > ? kernfs_path_from_node+0x4f/0x60 > sysfs_warn_dup+0x62/0x80 > sysfs_create_dir_ns+0x77/0x90 > kobject_add_internal+0xb2/0x350 > kobject_add+0x75/0xd0 > device_add+0x15a/0x650 > device_create_groups_vargs+0xe0/0xf0 > device_create_vargs+0x1c/0x20 > bdi_register+0x90/0x240 > ? lockdep_init_map+0x57/0x200 > bdi_register_owner+0x36/0x60 > device_add_disk+0x1bb/0x4e0 > ? __pm_runtime_use_autosuspend+0x5c/0x70 > sd_probe_async+0x10d/0x1c0 > async_run_entry_fn+0x39/0x170 > > This is a brute-force fix to pass the devt release information from > sd_probe() to the locations where we register the bdi, > device_add_disk(), and unregister the bdi, blk_cleanup_queue(). > > Thanks to Omar for the quick reproducer script [2]. This patch survives > where an unmodified kernel fails in a few seconds. > > [1]: https://marc.info/?l=linux-scsi&m=147116857810716&w=4 > [2]: http://marc.info/?l=linux-block&m=148554717109098&w=2 > > Cc: James Bottomley > Cc: Bart Van Assche > Cc: "Martin K. Petersen" > Cc: Christoph Hellwig > Cc: Jens Axboe > Reported-by: Omar Sandoval > Signed-off-by: Dan Williams > --- > block/blk-core.c |1 + > block/genhd.c |7 +++ > drivers/scsi/sd.c | 41 + > include/linux/blkdev.h |1 + > include/linux/genhd.h | 17 + > 5 files changed, 59 insertions(+), 8 deletions(-) > Please check the patchset from Jan Kara (cf 'BDI lifetime fix' on linux-block), which attempts to solve the same problem. Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- 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
scsi: use-after-free in sg_start_req
Hello, The following program triggers use-after-free in sg_start_req: https://gist.githubusercontent.com/dvyukov/be6561d2819fe30a78711234e53866b8/raw/1d75d4508f7a8ebb0b1ec0d18c0054fbffbc0708/gistfile1.txt BUG: KASAN: use-after-free in bio_copy_user_iov+0xee1/0xf00 block/bio.c:1248 at addr 8801c8c3ed00 Read of size 8 by task /9023 CPU: 0 PID: 9023 Comm: Not tainted 4.9.0 #5 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 8801d451f420 82346bdf 11003a8a3e17 ed003a8a3e0f 41b58ab3 84b37e38 823468f1 813183a6 8801d451f0e0 Call Trace: [] __dump_stack lib/dump_stack.c:15 [inline] [] dump_stack+0x2ee/0x3ef lib/dump_stack.c:51 [] kasan_object_err+0x1c/0x70 mm/kasan/report.c:161 [] print_address_description mm/kasan/report.c:199 [inline] [] kasan_report_error+0x1d1/0x4d0 mm/kasan/report.c:288 [] kasan_report mm/kasan/report.c:308 [inline] [] __asan_report_load8_noabort+0x3e/0x40 mm/kasan/report.c:329 [] bio_copy_user_iov+0xee1/0xf00 block/bio.c:1248 [] __blk_rq_map_user_iov block/blk-map.c:56 [inline] [] blk_rq_map_user_iov+0x2c5/0x970 block/blk-map.c:133 [] blk_rq_map_user+0x134/0x1d0 block/blk-map.c:163 [] sg_start_req drivers/scsi/sg.c:1758 [inline] [] sg_common_write.isra.20+0x12b1/0x1b00 drivers/scsi/sg.c:772 [] sg_write+0x785/0xda0 drivers/scsi/sg.c:675 [] __vfs_write+0x5b1/0x740 fs/read_write.c:510 [] vfs_write+0x170/0x4e0 fs/read_write.c:560 [] SYSC_write fs/read_write.c:607 [inline] [] SyS_write+0xfb/0x230 fs/read_write.c:599 [] entry_SYSCALL_64_fastpath+0x1f/0xc2 Object at 8801c8c3ed00, in cache kmalloc-256 size: 256 Allocated: PID = 9032 [ 52.586815] [] save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57 [ 52.594037] [] save_stack+0x43/0xd0 mm/kasan/kasan.c:495 [ 52.600735] [] set_track mm/kasan/kasan.c:507 [inline] [ 52.600735] [] kasan_kmalloc+0xaa/0xd0 mm/kasan/kasan.c:598 [ 52.607700] [] __do_kmalloc mm/slab.c:3729 [inline] [ 52.607700] [] __kmalloc+0x12c/0x690 mm/slab.c:3738 [ 52.614520] [] kmalloc include/linux/slab.h:495 [inline] [ 52.614520] [] kzalloc include/linux/slab.h:636 [inline] [ 52.614520] [] sg_build_sgat drivers/scsi/sg.c:1808 [inline] [ 52.614520] [] sg_build_indirect.isra.19+0x8b/0x540 drivers/scsi/sg.c:1834 [ 52.622591] [] sg_build_reserve+0x8d/0xb0 drivers/scsi/sg.c:1965 [ 52.629815] [] sg_add_sfp drivers/scsi/sg.c:2152 [inline] [ 52.629815] [] sg_open+0xcb1/0x15b0 drivers/scsi/sg.c:329 [ 52.636503] [] chrdev_open+0x253/0x6b0 fs/char_dev.c:392 [ 52.643451] [] do_dentry_open+0x6ca/0xc50 fs/open.c:753 [ 52.650660] [] vfs_open+0x105/0x220 fs/open.c:866 [ 52.657351] [] do_last fs/namei.c:3374 [inline] [ 52.657351] [] path_openat+0x100f/0x3830 fs/namei.c:3497 [ 52.664488] [] do_filp_open+0x288/0x3f0 fs/namei.c:3532 [ 52.671538] [] do_sys_open+0x535/0x710 fs/open.c:1053 [ 52.678484] [] SYSC_open fs/open.c:1071 [inline] [ 52.678484] [] SyS_open+0x2d/0x40 fs/open.c:1066 [ 52.685000] [] entry_SYSCALL_64_fastpath+0x1f/0xc2 Freed: PID = 9032 [ 52.697636] [] save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57 [ 52.704842] [] save_stack+0x43/0xd0 mm/kasan/kasan.c:495 [ 52.711522] [] set_track mm/kasan/kasan.c:507 [inline] [ 52.711522] [] kasan_slab_free+0x6f/0xb0 mm/kasan/kasan.c:571 [ 52.718640] [] __cache_free mm/slab.c:3507 [inline] [ 52.718640] [] kfree+0xd3/0x250 mm/slab.c:3824 [ 52.724979] [] sg_remove_scat.isra.16+0x212/0x2d0 drivers/scsi/sg.c:1916 [ 52.732879] [] sg_ioctl+0x1903/0x3840 drivers/scsi/sg.c:970 [ 52.739745] [] vfs_ioctl fs/ioctl.c:43 [inline] [ 52.739745] [] do_vfs_ioctl+0x1bf/0x1630 fs/ioctl.c:679 [ 52.746866] [] SYSC_ioctl fs/ioctl.c:694 [inline] [ 52.746866] [] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:685 [ 52.753478] [] entry_SYSCALL_64_fastpath+0x1f/0xc2 On commit ca63ff9b11f958efafd8c8fa60fda14baec6149c -- 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: [RFC PATCH] scsi, block: fix duplicate bdi name registration crashes
On Mon, Jan 30, 2017 at 08:05:52AM +0100, Hannes Reinecke wrote: > On 01/29/2017 05:58 AM, Dan Williams wrote: > > Warnings of the following form occur because scsi reuses a devt number > > while the block layer still has it referenced as the name of the bdi > > [1]: > > > > WARNING: CPU: 1 PID: 93 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x62/0x80 > > sysfs: cannot create duplicate filename '/devices/virtual/bdi/8:192' > > [..] > > Call Trace: > > dump_stack+0x86/0xc3 > > __warn+0xcb/0xf0 > > warn_slowpath_fmt+0x5f/0x80 > > ? kernfs_path_from_node+0x4f/0x60 > > sysfs_warn_dup+0x62/0x80 > > sysfs_create_dir_ns+0x77/0x90 > > kobject_add_internal+0xb2/0x350 > > kobject_add+0x75/0xd0 > > device_add+0x15a/0x650 > > device_create_groups_vargs+0xe0/0xf0 > > device_create_vargs+0x1c/0x20 > > bdi_register+0x90/0x240 > > ? lockdep_init_map+0x57/0x200 > > bdi_register_owner+0x36/0x60 > > device_add_disk+0x1bb/0x4e0 > > ? __pm_runtime_use_autosuspend+0x5c/0x70 > > sd_probe_async+0x10d/0x1c0 > > async_run_entry_fn+0x39/0x170 > > > > This is a brute-force fix to pass the devt release information from > > sd_probe() to the locations where we register the bdi, > > device_add_disk(), and unregister the bdi, blk_cleanup_queue(). > > > > Thanks to Omar for the quick reproducer script [2]. This patch survives > > where an unmodified kernel fails in a few seconds. > > > > [1]: https://marc.info/?l=linux-scsi&m=147116857810716&w=4 > > [2]: http://marc.info/?l=linux-block&m=148554717109098&w=2 > > > > Cc: James Bottomley > > Cc: Bart Van Assche > > Cc: "Martin K. Petersen" > > Cc: Christoph Hellwig > > Cc: Jens Axboe > > Reported-by: Omar Sandoval > > Signed-off-by: Dan Williams > > --- > > block/blk-core.c |1 + > > block/genhd.c |7 +++ > > drivers/scsi/sd.c | 41 + > > include/linux/blkdev.h |1 + > > include/linux/genhd.h | 17 + > > 5 files changed, 59 insertions(+), 8 deletions(-) > > > Please check the patchset from Jan Kara (cf 'BDI lifetime fix' on > linux-block), which attempts to solve the same problem. Hi, Hannes, It's not the same problem. Jan's series fixes a bdi vs. inode lifetime issue, this patch is for a bdi vs devt lifetime issue. Jan's series doesn't fix the crashes caused by my reproducer script. -- 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: [RFC PATCH] scsi, block: fix duplicate bdi name registration crashes
On Sun, Jan 29, 2017 at 11:22 PM, Omar Sandoval wrote: > On Mon, Jan 30, 2017 at 08:05:52AM +0100, Hannes Reinecke wrote: >> On 01/29/2017 05:58 AM, Dan Williams wrote: >> > Warnings of the following form occur because scsi reuses a devt number >> > while the block layer still has it referenced as the name of the bdi >> > [1]: >> > >> > WARNING: CPU: 1 PID: 93 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x62/0x80 >> > sysfs: cannot create duplicate filename '/devices/virtual/bdi/8:192' >> > [..] >> > Call Trace: >> > dump_stack+0x86/0xc3 >> > __warn+0xcb/0xf0 >> > warn_slowpath_fmt+0x5f/0x80 >> > ? kernfs_path_from_node+0x4f/0x60 >> > sysfs_warn_dup+0x62/0x80 >> > sysfs_create_dir_ns+0x77/0x90 >> > kobject_add_internal+0xb2/0x350 >> > kobject_add+0x75/0xd0 >> > device_add+0x15a/0x650 >> > device_create_groups_vargs+0xe0/0xf0 >> > device_create_vargs+0x1c/0x20 >> > bdi_register+0x90/0x240 >> > ? lockdep_init_map+0x57/0x200 >> > bdi_register_owner+0x36/0x60 >> > device_add_disk+0x1bb/0x4e0 >> > ? __pm_runtime_use_autosuspend+0x5c/0x70 >> > sd_probe_async+0x10d/0x1c0 >> > async_run_entry_fn+0x39/0x170 >> > >> > This is a brute-force fix to pass the devt release information from >> > sd_probe() to the locations where we register the bdi, >> > device_add_disk(), and unregister the bdi, blk_cleanup_queue(). >> > >> > Thanks to Omar for the quick reproducer script [2]. This patch survives >> > where an unmodified kernel fails in a few seconds. >> > >> > [1]: https://marc.info/?l=linux-scsi&m=147116857810716&w=4 >> > [2]: http://marc.info/?l=linux-block&m=148554717109098&w=2 >> > >> > Cc: James Bottomley >> > Cc: Bart Van Assche >> > Cc: "Martin K. Petersen" >> > Cc: Christoph Hellwig >> > Cc: Jens Axboe >> > Reported-by: Omar Sandoval >> > Signed-off-by: Dan Williams >> > --- >> > block/blk-core.c |1 + >> > block/genhd.c |7 +++ >> > drivers/scsi/sd.c | 41 + >> > include/linux/blkdev.h |1 + >> > include/linux/genhd.h | 17 + >> > 5 files changed, 59 insertions(+), 8 deletions(-) >> > >> Please check the patchset from Jan Kara (cf 'BDI lifetime fix' on >> linux-block), which attempts to solve the same problem. > > Hi, Hannes, > > It's not the same problem. Jan's series fixes a bdi vs. inode lifetime > issue, this patch is for a bdi vs devt lifetime issue. Jan's series > doesn't fix the crashes caused by my reproducer script. Correct. In fact I was running Jan's patches in my baseline kernel that fails almost immediately. -- 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
