status_type_t type,
}
}
+static int linear_rmap(struct dm_target *ti, sector_t offset,
+ rmap_callout_fn fn, void *data)
+{
+ struct linear_c *lc = (struct linear_c *) ti->private;
+ struct mapped_device *md = ti->table->md;
+ struct block_d
status_type_t type,
}
}
+static int linear_rmap(struct dm_target *ti, sector_t offset,
+ rmap_callout_fn fn, void *data)
+{
+ struct linear_c *lc = (struct linear_c *) ti->private;
+ struct mapped_device *md = ti->table->md;
+ struct block_d
status_type_t type,
}
}
+static int linear_rmap(struct dm_target *ti, sector_t offset,
+ rmap_callout_fn fn, void *data)
+{
+ struct linear_c *lc = (struct linear_c *) ti->private;
+ struct mapped_device *md = ti->table->md;
+ struct block_d
+++ b/drivers/nvme/target/io-cmd-bdev.c
@@ -323,9 +323,7 @@ static void nvmet_bdev_execute_flush(struct nvmet_req *req)
return;
bio_init(bio, req->inline_bvec, ARRAY_SIZE(req->inline_bvec));
- bio_set_dev(bio, req->ns->bdev);
- bio->bi_private = r
= (struct linear_c *) ti->private;
+
+ return offset - dm_target_offset(ti, lc->start);
+}
+
static int linear_prepare_ioctl(struct dm_target *ti, struct block_device
**bdev)
{
struct linear_c *lc = (struct linear_c *) ti->private;
@@ -238,6 +245,7 @@ static struct ta
From: Dongsheng Yang
[ Upstream commit df4ad53242158f9f1f97daf4feddbb4f8b77f080 ]
There is a race condition in detaching as below:
A. detachingB. Write request
(1) writing back
(2) write back done, set bdev
state to clean.
(3) cached_dev_put() and
schedule_work(&am
= (struct linear_c *) ti->private;
+
+ return offset - dm_target_offset(ti, lc->start);
+}
+
static int linear_prepare_ioctl(struct dm_target *ti, struct block_device
**bdev)
{
struct linear_c *lc = (struct linear_c *) ti->private;
@@ -238,6 +245,7 @@ static struct ta
,
+&sbi->s_bdev_wb_err);
sb->s_bdev->bd_super = sb;
EXT4_SB(sb)->s_mount_state |= EXT4_ORPHAN_FS;
ext4_orphan_cleanup(sb, es);
@@ -5721,14 +5720,6 @@ static int ext4_remount(struct super_blo
}
stem:
...
1 lock held by dd/2798:
#0: ff814ac1a3b8 (&bdev->bd_mutex){+.+.}, at: __blkdev_put+0x50/0x204
...
dd D0 2798 2764 0x00400208
Call trace:
...
schedule+0x8c/0xbc
io_schedule+0x1c/0x40
wait_on_page_bit_common+0x238/0x338
__lock_page+0x5c/0x68
wri
stem:
...
1 lock held by dd/2798:
#0: ff814ac1a3b8 (&bdev->bd_mutex){+.+.}, at: __blkdev_put+0x50/0x204
...
dd D0 2798 2764 0x00400208
Call trace:
...
schedule+0x8c/0xbc
io_schedule+0x1c/0x40
wait_on_page_bit_common+0x238/0x338
__lock_page+0x5c/0x68
wri
stem:
...
1 lock held by dd/2798:
#0: ff814ac1a3b8 (&bdev->bd_mutex){+.+.}, at: __blkdev_put+0x50/0x204
...
dd D0 2798 2764 0x00400208
Call trace:
...
schedule+0x8c/0xbc
io_schedule+0x1c/0x40
wait_on_page_bit_common+0x238/0x338
__lock_page+0x5c/0x68
wri
stem:
...
1 lock held by dd/2798:
#0: ff814ac1a3b8 (&bdev->bd_mutex){+.+.}, at: __blkdev_put+0x50/0x204
...
dd D0 2798 2764 0x00400208
Call trace:
...
schedule+0x8c/0xbc
io_schedule+0x1c/0x40
wait_on_page_bit_common+0x238/0x338
__lock_page+0x5c/0x68
wri
stem:
...
1 lock held by dd/2798:
#0: ff814ac1a3b8 (&bdev->bd_mutex){+.+.}, at: __blkdev_put+0x50/0x204
...
dd D0 2798 2764 0x00400208
Call trace:
...
schedule+0x8c/0xbc
io_schedule+0x1c/0x40
wait_on_page_bit_common+0x238/0x338
__lock_page+0x5c/0x68
wri
stem:
...
1 lock held by dd/2798:
#0: ff814ac1a3b8 (&bdev->bd_mutex){+.+.}, at: __blkdev_put+0x50/0x204
...
dd D0 2798 2764 0x00400208
Call trace:
...
schedule+0x8c/0xbc
io_schedule+0x1c/0x40
wait_on_page_bit_common+0x238/0x338
__lock_page+0x5c/0x68
wri
stem:
...
1 lock held by dd/2798:
#0: ff814ac1a3b8 (&bdev->bd_mutex){+.+.}, at: __blkdev_put+0x50/0x204
...
dd D0 2798 2764 0x00400208
Call trace:
...
schedule+0x8c/0xbc
io_schedule+0x1c/0x40
wait_on_page_bit_common+0x238/0x338
__lock_page+0x5c/0x68
wri
stem:
...
1 lock held by dd/2798:
#0: ff814ac1a3b8 (&bdev->bd_mutex){+.+.}, at: __blkdev_put+0x50/0x204
...
dd D0 2798 2764 0x00400208
Call trace:
...
schedule+0x8c/0xbc
io_schedule+0x1c/0x40
wait_on_page_bit_common+0x238/0x338
__lock_page+0x5c/0x68
wri
stem:
...
1 lock held by dd/2798:
#0: ff814ac1a3b8 (&bdev->bd_mutex){+.+.}, at: __blkdev_put+0x50/0x204
...
dd D0 2798 2764 0x00400208
Call trace:
...
schedule+0x8c/0xbc
io_schedule+0x1c/0x40
wait_on_page_bit_common+0x238/0x338
__lock_page+0x5c/0x68
wri
stem:
...
1 lock held by dd/2798:
#0: ff814ac1a3b8 (&bdev->bd_mutex){+.+.}, at: __blkdev_put+0x50/0x204
...
dd D0 2798 2764 0x00400208
Call trace:
...
schedule+0x8c/0xbc
io_schedule+0x1c/0x40
wait_on_page_bit_common+0x238/0x338
__lock_page+0x5c/0x68
wri
virtiofs does not have a block device but it has dax device.
Modify bdev_dax_pgoff() to be able to handle that.
If there is no bdev, that means dax offset is 0. (It can't be a partition
block device starting at an offset in dax device).
This is little hackish. There have been discussions
On Fri 07-08-20 15:55:07, Vivek Goyal wrote:
> virtiofs does not have a block device but it has dax device.
> Modify bdev_dax_pgoff() to be able to handle that.
>
> If there is no bdev, that means dax offset is 0. (It can't be a partition
> block device starting at an
virtiofs does not have a block device but it has dax device.
Modify bdev_dax_pgoff() to be able to handle that.
If there is no bdev, that means dax offset is 0. (It can't be a partition
block device starting at an offset in dax device).
This is little hackish. There have been discussions
/block_dev.c
+++ b/fs/block_dev.c
@@ -1526,6 +1526,7 @@ static int __blkdev_get(struct block_device *bdev,
fmode_t mode, int for_part)
int partno;
int perm = 0;
bool first_open = false;
+ bool need_finish = false;
if (mode & FMODE_READ)
rs/nvme/host/core.c:827:1: note: in expansion of macro
>> 'EXPORT_SYMBOL_GPL'
EXPORT_SYMBOL_GPL(nvme_nsid_by_bdev);
^
vim +827 drivers/nvme/host/core.c
814
815 int nvme_get_nsid_by_bdev(struct block_device *bdev, unsigned int *nsid)
816 {
817 s
.h:9:0,
from drivers/nvme/host/fault_inject.c:9:
>> include/linux/nvme.h:1395:42: warning: 'struct block_device' declared inside
>> parameter list will not be visible outside of this definition or declaration
int nvme_submit_admin_cmd_by_bd
nvme_submit_admin_cmd_by_bdev(struct block_device *bdev,
+ struct nvme_command *c, void *buffer, unsigned int bufflen)
+{
+ struct nvme_ns *ns;
+ struct nvme_ctrl *ctrl;
+ int error;
+
+ if (!bdev && !c)
+ return -EINVAL;
+
+ ns = bdev-
..35d121cd2378 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -812,6 +812,20 @@ int nvme_submit_sync_cmd(struct request_queue *q, struct
nvme_command *cmd,
}
EXPORT_SYMBOL_GPL(nvme_submit_sync_cmd);
+int nvme_get_nsid_by_bdev(struct block_device *bdev, unsigned int *nsid
andling in blkdev_get() and thus the bdev has been marked as held
even in case __blkdev_get() returned error. This led to occasional
warnings with block/001 test from blktests like:
kernel: WARNING: CPU: 5 PID: 907 at fs/block_dev.c:1899 __blkdev_put+0x396/0x3a0
Correct the error handling
up some stuff */
dummy_log->base = 0;
dummy_log->size = 1024;
+ dummy_log->bdev = sb->s_bdev;
rc = lmLogInit(dummy_log);
if (rc) {
kfree(dummy_log);
--
1.8.3.1
[ Upstream commit 3562f5d9f21e7779ae442a45197fed6cb247fd22 ]
The WRITE ZEROES command has no data transfer so that we need to
initialize the struct (nvmet_req *req)->data_len to 0x0. While
(nvmet_req *req)->transfer_len is initialized in nvmet_req_init(),
data_len will be initialized by nowhere w
[ Upstream commit 3562f5d9f21e7779ae442a45197fed6cb247fd22 ]
The WRITE ZEROES command has no data transfer so that we need to
initialize the struct (nvmet_req *req)->data_len to 0x0. While
(nvmet_req *req)->transfer_len is initialized in nvmet_req_init(),
data_len will be initialized by nowhere w
up some stuff */
dummy_log->base = 0;
dummy_log->size = 1024;
+ dummy_log->bdev = sb->s_bdev;
rc = lmLogInit(dummy_log);
if (rc) {
kfree(dummy_log);
--
1.8.3.1
From: Sean Wang
commit 77f328dbc6cf42f22c691a164958a5452142a542 upstream.
Restore bdev->tx_state with clearing bit BTMTKUART_TX_WAIT_VND_EVT
when there is an error on waiting for the corresponding event.
Fixes: 7237c4c9ec92 ("Bluetooth: mediatek: Add protocol support for MediaTek
From: Sean Wang
commit 77f328dbc6cf42f22c691a164958a5452142a542 upstream.
Restore bdev->tx_state with clearing bit BTMTKUART_TX_WAIT_VND_EVT
when there is an error on waiting for the corresponding event.
Fixes: 7237c4c9ec92 ("Bluetooth: mediatek: Add protocol support for MediaTek
From: Al Viro
Signed-off-by: Al Viro
---
fs/block_dev.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 78d3257435c0..9d5fd05dd643 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -789,17 +789,9 @@ static struct inode
Convert the bdev filesystem to the new internal mount API as the old
one will be obsoleted and removed. This allows greater flexibility in
communication of mount parameters between userspace, the VFS and the
filesystem.
See Documentation/filesystems/mount_api.txt for more information.
Signed
, const char *dev_name, void *data)
+static int bd_init_fs_context(struct fs_context *fc)
{
- struct dentry *dent;
- dent = mount_pseudo(fs_type, "bdev:", &bdev_sops, NULL, BDEVFS_MAGIC);
- if (!IS_ERR(dent))
- dent->d_sb->s_iflags |= SB_I_CGRO
Applied. Thanks!
On Tue, Feb 19, 2019 at 3:22 AM YueHaibing wrote:
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/ttm/ttm_execbuf_util.c: In function
> 'ttm_eu_fence_buffer_objects':
> drivers/gpu/drm/ttm/ttm_execbuf_util.c:191:2
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/ttm/ttm_execbuf_util.c: In function
'ttm_eu_fence_buffer_objects':
drivers/gpu/drm/ttm/ttm_execbuf_util.c:191:24: warning:
variable 'bdev' set but not used [-Wunused-but-set-variable]
It's n
Hi Sean,
> Restore bdev->tx_state with clearing bit BTMTKUART_TX_WAIT_VND_EVT
> when there is an error on waiting for the corresponding event.
>
> Fixes: 7237c4c9ec92 ("Bluetooth: mediatek: Add protocol support for MediaTek
> serial devices")
> Signed-off
From: Sean Wang
Restore bdev->tx_state with clearing bit BTMTKUART_TX_WAIT_VND_EVT
when there is an error on waiting for the corresponding event.
Fixes: 7237c4c9ec92 ("Bluetooth: mediatek: Add protocol support for MediaTek
serial devices")
Signed-off-by: Sean Wang
---
driv
On Sat, 20 Jan 2018 22:09:34 +
Colin King wrote:
> From: Colin Ian King
>
> Pointer bdev is being initialized however this value is never
> read as bdev is assigned an updated value from the returned
> call to blkdev_get_by_path. Remove the redundant assignment.
>
From: Colin Ian King
Pointer bdev is being initialized however this value is never
read as bdev is assigned an updated value from the returned
call to blkdev_get_by_path. Remove the redundant assignment.
Cleans up clang warning:
drivers/mtd/devices/block2mtd.c:228:23: warning: Value stored to
If the backing device hasn't been detached due to exceptional stop
like power outage, the BDEV_STATE in super block can't be reset,
it will fail to register this backing device in next time, but the
opened bdev will be hold, this makes the backing device unaccessable
because of FMODE_
if (!IS_ERR(bdev))
+ bdput(bdev);
if (attr == &ksysfs_register_quiet)
goto out;
}
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Ross Zwisler
commit 6851a3db7e224bbb85e23b3c64a506c9e0904382 upstream.
Currently only the blocksize is checked, but we should really be calling
bdev_dax_supported() which also tests to make sur
4.13-stable review patch. If anyone has any objections, please let me know.
--
From: Ross Zwisler
commit 6851a3db7e224bbb85e23b3c64a506c9e0904382 upstream.
Currently only the blocksize is checked, but we should really be calling
bdev_dax_supported() which also tests to make su
On Tue, Sep 26, 2017 at 11:16:38AM -0600, Ross Zwisler wrote:
> On Tue, Sep 26, 2017 at 08:36:50AM +0200, Christoph Hellwig wrote:
> > On Mon, Sep 25, 2017 at 05:13:59PM -0600, Ross Zwisler wrote:
> > > Currently only the blocksize is checked, but we should really be calling
> > > bdev_dax_supporte
On Tue, Sep 26, 2017 at 08:36:50AM +0200, Christoph Hellwig wrote:
> On Mon, Sep 25, 2017 at 05:13:59PM -0600, Ross Zwisler wrote:
> > Currently only the blocksize is checked, but we should really be calling
> > bdev_dax_supported() which also tests to make sure we can get a
> > struct dax_device a
On Mon, Sep 25, 2017 at 05:13:59PM -0600, Ross Zwisler wrote:
> Currently only the blocksize is checked, but we should really be calling
> bdev_dax_supported() which also tests to make sure we can get a
> struct dax_device and that the dax_direct_access() path is working.
>
> This is the same chec
Currently only the blocksize is checked, but we should really be calling
bdev_dax_supported() which also tests to make sure we can get a
struct dax_device and that the dax_direct_access() path is working.
This is the same check that we do for the "-o dax" mount option in
xfs_fs_fill_super().
Sign
if (!IS_ERR(bdev))
+ bdput(bdev);
if (attr == &ksysfs_register_quiet)
goto out;
}
if (!IS_ERR(bdev))
+ bdput(bdev);
if (attr == &ksysfs_register_quiet)
goto out;
}
_register_lock);
+ if (!IS_ERR(bdev))
+ bdput(bdev);
if (attr == &ksysfs_register_quiet)
goto out;
}
_register_lock);
+ if (!IS_ERR(bdev))
+ bdput(bdev);
if (attr == &ksysfs_register_quiet)
goto out;
}
Looks good,
Reviewed-by: Christoph Hellwig
Currently only the blocksize is checked, but we should really be calling
bdev_dax_supported() which also tests to make sure we can get a
struct dax_device and that the dax_direct_access() path is working.
This is the same check that we do for the "-o dax" mount option in
xfs_fs_fill_super().
This
Currently only the blocksize is checked, but we should really be calling
bdev_dax_supported() which also tests to make sure we can get a
struct dax_device and that the dax_direct_access() path is working.
This is the same check that we do for the "-o dax" mount option in
xfs_fs_fill_super().
Sign
From: NeilBrown
commit bcc7f5b4bee8e327689a4d994022765855c807ff upstream.
bdev->bd_contains is not stable before calling __blkdev_get().
When __blkdev_get() is called on a parition with ->bd_openers == 0
it sets
bdev->bd_contains = bdev;
which is not correct for a partition.
After
Some callers (usually error paths) call bdevname with null bdev.
Signed-off-by: Dmitry Monakhov
---
block/partition-generic.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/block/partition-generic.c b/block/partition-generic.c
index 7afb990..284de18 100644
--- a/block/partition-generic.c
This prevent us from panic if someone invalidate bh under us.
Signed-off-by: Dmitry Monakhov
---
fs/jbd2/revoke.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/jbd2/revoke.c b/fs/jbd2/revoke.c
index f9aefcd..e3b791d 100644
--- a/fs/jbd2/revoke.c
+++ b/fs/jbd2/revoke.c
3.16.42-rc1 review patch. If anyone has any objections, please let me know.
--
From: NeilBrown
commit bcc7f5b4bee8e327689a4d994022765855c807ff upstream.
bdev->bd_contains is not stable before calling __blkdev_get().
When __blkdev_get() is called on a parition w
3.2.87-rc1 review patch. If anyone has any objections, please let me know.
--
From: NeilBrown
commit bcc7f5b4bee8e327689a4d994022765855c807ff upstream.
bdev->bd_contains is not stable before calling __blkdev_get().
When __blkdev_get() is called on a parition with ->bd_o
/drivers/block/loop.c
@@ -1298,7 +1298,7 @@ static int loop_clr_fd(struct loop_device *lo)
return err;
}
-static int loop_set_capacity(struct loop_device *lo, struct block_device *bdev)
+static int loop_set_capacity(struct loop_device *lo)
{
if (unlikely(lo->lo_state != Lo_bo
From: NeilBrown
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit bcc7f5b4bee8e327689a4d994022765855c807ff upstream.
bdev->bd_contains is not stable before calling __blkdev_get().
When __blkdev_get() is called on a parition with ->bd_o
On Fri, Jan 06, 2017 at 11:23:30AM +0100, Jan Kara wrote:
> So what I think needs to be done is that we make backing_dev_info
> independently allocated structure with different lifetime rules to gendisk
> or request_queue - definitely I want it to live as long as block device
> inode exists. Howeve
a block device
>>> > we do put_disk() and thus the request queue containing backing_dev_info
>>> > does not have to be around at that time. In your case you are lucky enough
>>> > to have the containing disk still around but that's not the case fo
ing disk still around but that's not the case for all
>> > inode_to_bdi() users (see e.g. the report I referenced) and your patch
>> > would change relatively straightforward NULL pointer dereference to rather
>> > subtle use-after-free issue
>>
>> Tr
e to be around at that time. In your case you are lucky enough
> > to have the containing disk still around but that's not the case for all
> > inode_to_bdi() users (see e.g. the report I referenced) and your patch
> > would change relatively straightforward NULL pointer de
device. Simply switch bdev_get_queue() to use ->bd_queue directly
which is guaranteed to still be valid since the request_queue is alive
as long as the inode corresponding to the bdev has not been destroyed.
BUG: unable to handle kernel NULL pointer dereference at 0568
IP: blk_get_b
By definition the lifetime of a struct block_device is equal to the
lifetime of its corresponding inode since they both live in struct
bdev_inode. Up until the inode is destroyed it may be the target of
delayed write-back requests. Issuing write-back to a block_device
requires a lookup of the bdev
d change relatively straightforward NULL pointer dereference to rather
> subtle use-after-free issue
True. If there are other cases that don't hold their own queue
reference this patch makes things worse.
> so I disagree with going down this path.
I still think this patch is the right
t; block/blk-core.c |4 ++--
> include/linux/blkdev.h |2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/block/blk-core.c b/block/blk-core.c
> index 61ba08c58b64..04737548e1e1 100644
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
> @@ -10
x 61ba08c58b64..04737548e1e1 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -109,8 +109,8 @@ void blk_queue_congestion_threshold(struct request_queue *q)
* @bdev: device
*
* Locates the passed device's request queue and returns the address of its
- * backing_dev_info. This
4.8-stable review patch. If anyone has any objections, please let me know.
--
From: NeilBrown
commit bcc7f5b4bee8e327689a4d994022765855c807ff upstream.
bdev->bd_contains is not stable before calling __blkdev_get().
When __blkdev_get() is called on a parition with ->bd_o
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: NeilBrown
commit bcc7f5b4bee8e327689a4d994022765855c807ff upstream.
bdev->bd_contains is not stable before calling __blkdev_get().
When __blkdev_get() is called on a parition with ->bd_o
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: NeilBrown
commit bcc7f5b4bee8e327689a4d994022765855c807ff upstream.
bdev->bd_contains is not stable before calling __blkdev_get().
When __blkdev_get() is called on a parition with ->bd_o
On 12/11/2016 05:29 PM, NeilBrown wrote:
>
> bdev->bd_contains is not stable before calling __blkdev_get().
> When __blkdev_get() is called on a parition with ->bd_openers == 0
> it sets
> bdev->bd_contains = bdev;
> which is not correct for a partition.
>
bdev->bd_contains is not stable before calling __blkdev_get().
When __blkdev_get() is called on a parition with ->bd_openers == 0
it sets
bdev->bd_contains = bdev;
which is not correct for a partition.
After a call to __blkdev_get() succeeds, ->bd_openers will be > 0
and then -
bdev->bd_contains is not stable before calling __blkdev_get().
When __blkdev_get() is called on a parition with ->bd_openers == 0
it sets
bdev->bd_contains = bdev;
which is not correct for a partition.
After a call to __blkdev_get() succeeds, ->bd_openers will be > 0
and then -
/drivers/block/loop.c
@@ -1298,7 +1298,7 @@ loop_get_status64(struct loop_device *lo, struct
loop_info64 __user *arg) {
return err;
}
-static int loop_set_capacity(struct loop_device *lo, struct block_device *bdev)
+static int loop_set_capacity(struct loop_device *lo)
{
if (unlikely(lo
oop.c
> index fa1b7a9..3008dec 100644
> --- a/drivers/block/loop.c
> +++ b/drivers/block/loop.c
> @@ -1298,7 +1298,7 @@ loop_get_status64(struct loop_device *lo, struct
> loop_info64 __user *arg) {
> return err;
> }
>
> -static int loop_set_capacity(struct loop_device
@@ -1298,7 +1298,7 @@ loop_get_status64(struct loop_device *lo, struct
loop_info64 __user *arg) {
return err;
}
-static int loop_set_capacity(struct loop_device *lo, struct block_device *bdev)
+static int loop_set_capacity(struct loop_device *lo)
{
if (unlikely(lo->lo_state != Lo_bo
2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -659,7 +659,7 @@ static struct dentry *bd_mount(struct fi
{
struct dentry *dent;
dent = mount_pseudo(fs_type, "bdev:", &bdev_sops, NULL, BDEVFS_MAGIC);
- if (
ss the callback. Can you please verify whether
> > that works?
>
> Didn't work for me, I kept getting use-after-free in __blkdev_get() on
> bdev->bd_invalidated after it calls bdev->bd_disk->fops->open(). I tried
> a few related things without much luck.
I s
block device.
I think the right thing to do there is doing blkdev_get() /
blkdev_put() around func() invocation in iterate_bdevs() rather than
holding bd_mutex across the callback. Can you please verify whether
that works?
Didn't work for me, I kept getting use-after-free in __blkdev_get
Hello,
On Mon, Aug 29, 2016 at 10:49:57PM +0200, Vegard Nossum wrote:
> That didn't work at all. I guess bd_acquire() would just do a bdgrab()
> and not touch ->bd_holders, whereas blkdev_get() would increment
Yeah, bdev has two different refs - one for bdev struct itself and the
list_for_each_entry(inode, &blockdev_superblock->s_inodes,
i_sb_list) {
struct address_space *mapping = inode->i_mapping;
+ struct block_device *bdev;
spin_lock(&inode->i_lock);
Hello,
On Sat, Aug 27, 2016 at 11:30:22AM +0200, Vegard Nossum wrote:
> > Don't know what's the right fix, but I posted a slightly different one
> > for the same crash some months ago:
> > https://patchwork.kernel.org/patch/8556941/
> >
>
> Ah, I'm sorry, I didn't see that.
>
> Your patch is 10
a/0x70
RSP
The problem is that sync() calls down to blk_get_backing_dev_info()
without necessarily having the block device opened (if it races with
another process doing close()):
/**
* blk_get_backing_dev_info - get the address of a queue's backing_dev_info
* @bdev:
sarily having the block device opened (if it races with
> another process doing close()):
>
> /**
> * blk_get_backing_dev_info - get the address of a queue's
> backing_dev_info
> * @bdev: device
> *
> * Locates the passed device
block device opened (if it races with
another process doing close()):
/**
* blk_get_backing_dev_info - get the address of a queue's backing_dev_info
* @bdev: device
*
* Locates the passed device's request queue and returns the address of its
* backing
On 08/22/2016 04:47 AM, Vegard Nossum wrote:
I got this:
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: [#1] PREEMPT SMP KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
CPU: 0 PID: 5505 Comm: syz-executor Not tainted 4.
*bd_mount(struct file_system_type
*fs_type,
{
struct dentry *dent;
dent = mount_pseudo(fs_type, "bdev:", &bdev_sops, NULL, BDEVFS_MAGIC);
- if (dent)
+ if (!IS_ERR(dent))
dent->d_sb->s_iflags |= SB_I_CGROUPWB;
return dent;
}
--
2.10.0.rc0.1.g07c9292
On 25/07/2016 15:29, Jan Kara wrote:
> Hi!
>
> On Mon 25-07-16 09:48:37, Laurent Dufour wrote:
>> This is about the patch "block: flush writeback dwork before detaching a
>> bdev inode from it" you sent a month ago to fix a panic hit by Dimitry:
>> https
Hi!
On Mon 25-07-16 09:48:37, Laurent Dufour wrote:
> This is about the patch "block: flush writeback dwork before detaching a
> bdev inode from it" you sent a month ago to fix a panic hit by Dimitry:
> https://patchwork.kernel.org/patch/9187409/
>
> We hit the same is
Hi Jan,
This is about the patch "block: flush writeback dwork before detaching a
bdev inode from it" you sent a month ago to fix a panic hit by Dimitry:
https://patchwork.kernel.org/patch/9187409/
We hit the same issue on our side, and gave your patch a try, and it
fixed the issue.
Is
On Mon, Jun 20, 2016 at 7:40 PM, Tejun Heo wrote:
> Hello,
>
> On Mon, Jun 20, 2016 at 03:38:41PM +0200, Dmitry Vyukov wrote:
>> > Sorry for the late reply but now when thinking about the patch I don't
>> > think it is quite right. Writeback can happen from other contexts than just
>> > the worker
Hello,
On Mon, Jun 20, 2016 at 03:38:41PM +0200, Dmitry Vyukov wrote:
> > Sorry for the late reply but now when thinking about the patch I don't
> > think it is quite right. Writeback can happen from other contexts than just
> > the worker one (e.g. kswapd can do writeback, or in some out-of-memor
On Mon, Jun 20, 2016 at 3:31 PM, Jan Kara wrote:
> Hi,
>
> On Fri 17-06-16 12:04:05, Tejun Heo wrote:
>> 43d1c0eb7e11 ("block: detach bdev inode from its wb in
>> __blkdev_put()") detached bdev inode from its wb as the bdev inode may
>> outlive the und
Hi,
On Fri 17-06-16 12:04:05, Tejun Heo wrote:
> 43d1c0eb7e11 ("block: detach bdev inode from its wb in
> __blkdev_put()") detached bdev inode from its wb as the bdev inode may
> outlive the underlying bdi and thus the wb. This is accomplished by
> invoking inode_detach_
1 - 100 of 243 matches
Mail list logo
