Unregister and reregister BDI devices in the proper order. This patch
avoids that the following kernel warning can be triggered during
SCSI device reregistration:
WARNING: CPU: 7 PID: 203 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x68/0x80()
sysfs: cannot create duplicate filename '/devices/virtual/bdi/
On 11/30/2015 11:23 PM, Christoph Hellwig wrote:
On Mon, Nov 30, 2015 at 05:18:50PM -0800, Bart Van Assche wrote:
Since the original patch caused a regression, please proceed with reverting
the original patch.
Regarding this patch: is there anyone on the CC-list of this e-mail who can
review it
Hi,
I think you should squash the revert of v1 into this patch, and then
document the crash the original patch caused and how this new patch is
fixing that.
A.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More major
On 11/20/2015 02:44 PM, Aaro Koskinen wrote:
I think you should squash the revert of v1 into this patch, and then
document the crash the original patch caused and how this new patch is
fixing that.
Hello Aaro,
I'd like to know the opinion of the SCSI maintainers about this. It's
not impossibl
What sort of re-registration is this? Seems like we should only
release the minor number once the bdi is released.
--
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-
On 11/24/2015 03:13 PM, Christoph Hellwig wrote:
What sort of re-registration is this? Seems like we should only
release the minor number once the bdi is released.
Hello Christoph,
As you most likely know the BDI device name for disks is based on the
device major and minor number:
$ ls -l /
Hi Bart,
On Tue, Nov 24, 2015 at 03:23:21PM -0800, Bart Van Assche wrote:
> So if a driver stops using a (major, minor) number pair and the same device
> number is reused before the bdi device has been released the warning
> mentioned in the patch description at the start of this thread is trigger
On 11/25/15 00:47, Christoph Hellwig wrote:
But what I really wanted to ask for is what your reproducer looks like.
Hello Christoph,
This race is hard to trigger. I can trigger it by repeatedly removing
and re-adding SRP SCSI devices. Enabling debug options like SLUB
debugging and kmemleak h
> "Bart" == Bart Van Assche writes:
Bart,
Bart> This race is hard to trigger. I can trigger it by repeatedly
Bart> removing and re-adding SRP SCSI devices. Enabling debug options
Bart> like SLUB debugging and kmemleak helps. I think that is because
Bart> these debug options slow down the SCS
On 11/30/2015 04:57 PM, Martin K. Petersen wrote:
"Bart" == Bart Van Assche writes:
Bart> This race is hard to trigger. I can trigger it by repeatedly
Bart> removing and re-adding SRP SCSI devices. Enabling debug options
Bart> like SLUB debugging and kmemleak helps. I think that is because
Bar
On Mon, Nov 30, 2015 at 05:18:50PM -0800, Bart Van Assche wrote:
> Since the original patch caused a regression, please proceed with reverting
> the original patch.
>
> Regarding this patch: is there anyone on the CC-list of this e-mail who can
> review it ?
I'm not too fond of the approach. I'd
11 matches
Mail list logo
