Re: [dm-devel] [PATCH 4/6] libmpathpersist: fix byte swapping for big endian systems
On 06/22/18 16:27, Martin Wilck wrote:
On Fri, 2018-06-22 at 16:19 -0700, Bart Van Assche wrote:
On 06/22/18 16:16, Martin Wilck wrote:
- sa_key = 0;
- for (i = 0; i < 8; ++i){
- if (i > 0)
- sa_key <<= 8;
- sa_key |= paramp->sa_key[i];
- }
+ sa_key = be64_to_cpu(*(uint64_t *)
sa_key[0]);
Have you considered to use get_unaligned_be64() instead of the above
construct with casts?
Yes, I did. I opted for this construct for patch brevity (and
admittedly, lazyness), because get_unaligned_be64() doesn't exist yet.
I can change that of course if you insist.
Adding an implementation of get_unaligned_be64() and introducing it in
the above code would be highly appreciated. I think that will improve
readability.
Thanks,
Bart.
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
Re: [dm-devel] [PATCH 4/6] libmpathpersist: fix byte swapping for big endian systems
On Fri, 2018-06-22 at 16:19 -0700, Bart Van Assche wrote:
> On 06/22/18 16:16, Martin Wilck wrote:
> > - sa_key = 0;
> > - for (i = 0; i < 8; ++i){
> > - if (i > 0)
> > - sa_key <<= 8;
> > - sa_key |= paramp->sa_key[i];
> > - }
> > + sa_key = be64_to_cpu(*(uint64_t *)
> > >sa_key[0]);
>
> Have you considered to use get_unaligned_be64() instead of the above
> construct with casts?
Yes, I did. I opted for this construct for patch brevity (and
admittedly, lazyness), because get_unaligned_be64() doesn't exist yet.
I can change that of course if you insist.
Thanks,
Martin
--
Dr. Martin Wilck , Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
Re: [dm-devel] [PATCH 4/6] libmpathpersist: fix byte swapping for big endian systems
On 06/22/18 16:16, Martin Wilck wrote:
- sa_key = 0;
- for (i = 0; i < 8; ++i){
- if (i > 0)
- sa_key <<= 8;
- sa_key |= paramp->sa_key[i];
- }
+ sa_key = be64_to_cpu(*(uint64_t *)>sa_key[0]);
Have you considered to use get_unaligned_be64() instead of the above
construct with casts?
Thanks,
Bart.
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
Re: [dm-devel] [PATCH 1/6] libmpathpersist: remove duplicate test in readfullstatus
On Sat, 2018-06-23 at 01:15 +0200, Martin Wilck wrote: > Signed-off-by: Martin Wilck in replies, please remove Eli from cc, his email bounces. Martin -- Dr. Martin Wilck , Tel. +49 (0)911 74053 2107 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
[dm-devel] [PATCH 3/6] libmpathpersist: fix stack overflow in mpath_format_readfullstatus()
Some storage arrays return corrupt data in response to READ FULL STATUS
PRIN commands. This may lead to stack overflow if the values aren't
sanitized.
Signed-off-by: Martin Wilck
---
libmpathpersist/mpath_pr_ioctl.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libmpathpersist/mpath_pr_ioctl.c b/libmpathpersist/mpath_pr_ioctl.c
index bcbb9691..347f21b2 100644
--- a/libmpathpersist/mpath_pr_ioctl.c
+++ b/libmpathpersist/mpath_pr_ioctl.c
@@ -241,6 +241,13 @@ void mpath_format_readfullstatus(struct prin_resp
*pr_buff, int len, int noisy)
fdesc.rtpi = get_unaligned_be16([18]);
tid_len_len = get_unaligned_be32([20]);
+ if (tid_len_len + 24 + k >= additional_length) {
+ condlog(0,
+ "%s: corrupt PRIN response: status descriptor
end %d exceeds length %d",
+ __func__, tid_len_len + k + 24,
+ additional_length);
+ tid_len_len = additional_length - k - 24;
+ }
if (tid_len_len > 0)
decode_transport_id( , [24], tid_len_len);
@@ -272,6 +279,8 @@ decode_transport_id(struct prin_fulldescr *fdesc, unsigned
char * p, int length)
break;
case MPATH_PROTOCOL_ID_ISCSI:
num = get_unaligned_be16([2]);
+ if (num >= sizeof(fdesc->trnptid.iscsi_name))
+ num = sizeof(fdesc->trnptid.iscsi_name);
memcpy(>trnptid.iscsi_name, [4], num);
jump = (((num + 4) < 24) ? 24 : num + 4);
break;
--
2.17.1
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
[dm-devel] [PATCH 2/6] libmpathpersist: fix typo in mpath_format_readfullstatus
Signed-off-by: Martin Wilck
---
libmpathpersist/mpath_pr_ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libmpathpersist/mpath_pr_ioctl.c b/libmpathpersist/mpath_pr_ioctl.c
index dcdb530d..bcbb9691 100644
--- a/libmpathpersist/mpath_pr_ioctl.c
+++ b/libmpathpersist/mpath_pr_ioctl.c
@@ -218,7 +218,7 @@ void mpath_format_readfullstatus(struct prin_resp *pr_buff,
int len, int noisy)
if (pr_buff->prin_descriptor.prin_readfd.number_of_descriptor == 0)
{
- condlog(3, "No registration or resrvation found.");
+ condlog(3, "No registration or reservation found.");
return;
}
--
2.17.1
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
[dm-devel] [PATCH 1/6] libmpathpersist: remove duplicate test in readfullstatus
Signed-off-by: Martin Wilck
---
libmpathpersist/mpath_pr_ioctl.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/libmpathpersist/mpath_pr_ioctl.c b/libmpathpersist/mpath_pr_ioctl.c
index 6dd74031..dcdb530d 100644
--- a/libmpathpersist/mpath_pr_ioctl.c
+++ b/libmpathpersist/mpath_pr_ioctl.c
@@ -216,12 +216,6 @@ void mpath_format_readfullstatus(struct prin_resp
*pr_buff, int len, int noisy)
mpath_reverse_uint32_byteorder(_buff->prin_descriptor.prin_readfd.prgeneration);
mpath_reverse_uint32_byteorder(_buff->prin_descriptor.prin_readfd.number_of_descriptor);
- if (0 == pr_buff->prin_descriptor.prin_readfd.number_of_descriptor)
- {
- return ;
- }
-
-
if (pr_buff->prin_descriptor.prin_readfd.number_of_descriptor == 0)
{
condlog(3, "No registration or resrvation found.");
--
2.17.1
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
[dm-devel] [PATCH 5/6] (lib)mpathpersist: use O_RDONLY file descriptors
udevd catches close-after-write inotify events and generates "change"
uvents for such devices, which may cause extra unnecessary and unwanted
udev activity.
Therefore use O_RDONLY file descriptors for PRIN and PROUT commands. This
works just as well as O_WRONLY. sg_persist has supported the --readonly option
for years.
Signed-off-by: Martin Wilck
---
libmpathpersist/mpath_pr_ioctl.c | 4 ++--
mpathpersist/main.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/libmpathpersist/mpath_pr_ioctl.c b/libmpathpersist/mpath_pr_ioctl.c
index 76271ff1..e641ce62 100644
--- a/libmpathpersist/mpath_pr_ioctl.c
+++ b/libmpathpersist/mpath_pr_ioctl.c
@@ -52,7 +52,7 @@ int prout_do_scsi_ioctl(char * dev, int rq_servact, int
rq_scope,
int fd = -1;
snprintf(devname, FILE_NAME_SIZE, "/dev/%s",dev);
- fd = open(devname, O_WRONLY);
+ fd = open(devname, O_RDONLY);
if(fd < 0){
condlog (1, "%s: unable to open device.", dev);
return MPATH_PR_FILE_ERROR;
@@ -308,7 +308,7 @@ int prin_do_scsi_ioctl(char * dev, int rq_servact, struct
prin_resp * resp, int
{MPATH_PRIN_CMD, 0, 0, 0, 0, 0, 0, 0, 0, 0};
snprintf(devname, FILE_NAME_SIZE, "/dev/%s",dev);
- fd = open(devname, O_WRONLY);
+ fd = open(devname, O_RDONLY);
if(fd < 0){
condlog(0, "%s: Unable to open device ", dev);
return MPATH_PR_FILE_ERROR;
diff --git a/mpathpersist/main.c b/mpathpersist/main.c
index 5b37f3ae..34caa16c 100644
--- a/mpathpersist/main.c
+++ b/mpathpersist/main.c
@@ -380,7 +380,7 @@ int main (int argc, char * argv[])
}
/* open device */
- if ((fd = open (device_name, O_WRONLY)) < 0)
+ if ((fd = open (device_name, O_RDONLY)) < 0)
{
fprintf (stderr, "%s: error opening file (rw) fd=%d\n",
device_name, fd);
--
2.17.1
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
[dm-devel] [PATCH 4/6] libmpathpersist: fix byte swapping for big endian systems
This code was obviously intended to convert big-endian data
from PRIN to CPU endianness. It doesn't work on big endian systems.
Signed-off-by: Martin Wilck
---
libmpathpersist/mpath_persist.c | 7 +--
libmpathpersist/mpath_pr_ioctl.c | 16 ++--
2 files changed, 3 insertions(+), 20 deletions(-)
diff --git a/libmpathpersist/mpath_persist.c b/libmpathpersist/mpath_persist.c
index 907a17c9..12dad7a7 100644
--- a/libmpathpersist/mpath_persist.c
+++ b/libmpathpersist/mpath_persist.c
@@ -543,12 +543,7 @@ int mpath_prout_reg(struct multipath *mpp,int rq_servact,
int rq_scope,
}
if (!rollback && (thread[i].param.status ==
MPATH_PR_RESERV_CONFLICT)){
rollback = 1;
- sa_key = 0;
- for (i = 0; i < 8; ++i){
- if (i > 0)
- sa_key <<= 8;
- sa_key |= paramp->sa_key[i];
- }
+ sa_key = be64_to_cpu(*(uint64_t *)>sa_key[0]);
status = MPATH_PR_RESERV_CONFLICT ;
}
if (!rollback && (status == MPATH_PR_SUCCESS)){
diff --git a/libmpathpersist/mpath_pr_ioctl.c b/libmpathpersist/mpath_pr_ioctl.c
index 347f21b2..76271ff1 100644
--- a/libmpathpersist/mpath_pr_ioctl.c
+++ b/libmpathpersist/mpath_pr_ioctl.c
@@ -485,24 +485,12 @@ int mpath_isLittleEndian(void)
void mpath_reverse_uint16_byteorder(uint16_t *num)
{
- uint16_t byte0, byte1;
-
- byte0 = (*num & 0x00FF) >> 0 ;
- byte1 = (*num & 0xFF00) >> 8 ;
-
- *num = ((byte0 << 8) | (byte1 << 0));
+ *num = get_unaligned_be16(num);
}
void mpath_reverse_uint32_byteorder(uint32_t *num)
{
- uint32_t byte0, byte1, byte2, byte3;
-
- byte0 = (*num & 0x00FF) >> 0 ;
- byte1 = (*num & 0xFF00) >> 8 ;
- byte2 = (*num & 0x00FF) >> 16 ;
- byte3 = (*num & 0xFF00) >> 24 ;
-
- *num = ((byte0 << 24) | (byte1 << 16) | (byte2 << 8) | (byte3 << 0));
+ *num = get_unaligned_be32(num);
}
void
--
2.17.1
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
Re: [dm-devel] [dm:for-next 6/8] drivers/md/dm-writecache.c:862:24: error: implicit declaration of function 'array_size'; did you mean '__ua_size'?
sorry for the noise, I forgot to rebase to v4.18-rc1 before picking this
change up. since fixed and pushed out.
On Fri, Jun 22 2018 at 2:40pm -0400,
kbuild test robot wrote:
> tree:
> https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git
> for-next
> head: 696ee10fad76d6ec15f256e6dc2c08aa2c706890
> commit: 5174624414ac49495a08eca4ee584dac193c0eb7 [6/8] dm writecache: use
> 2-factor allocator arguments
> config: mips-allyesconfig (attached as .config)
> compiler: mips-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 5174624414ac49495a08eca4ee584dac193c0eb7
> # save the attached .config to linux build tree
> GCC_VERSION=7.2.0 make.cross ARCH=mips
>
> All errors (new ones prefixed by >>):
>
>drivers/md/dm-writecache.c: In function 'writecache_alloc_entries':
> >> drivers/md/dm-writecache.c:862:24: error: implicit declaration of function
> >> 'array_size'; did you mean '__ua_size'?
> >> [-Werror=implicit-function-declaration]
> wc->entries = vmalloc(array_size(sizeof(struct wc_entry), wc->n_blocks));
>^~
>__ua_size
>cc1: some warnings being treated as errors
>
> vim +862 drivers/md/dm-writecache.c
>
>855
>856static int writecache_alloc_entries(struct dm_writecache *wc)
>857{
>858size_t b;
>859
>860if (wc->entries)
>861return 0;
> > 862wc->entries = vmalloc(array_size(sizeof(struct
> wc_entry), wc->n_blocks));
>863if (!wc->entries)
>864return -ENOMEM;
>865for (b = 0; b < wc->n_blocks; b++) {
>866struct wc_entry *e = >entries[b];
>867e->index = b;
>868e->write_in_progress = false;
>869}
>870
>871return 0;
>872}
>873
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
Re: [dm-devel] dm bufio: Reduce dm_bufio_lock contention
On Fri, 22 Jun 2018, Michal Hocko wrote: > On Fri 22-06-18 08:52:09, Mikulas Patocka wrote: > > > > > > On Fri, 22 Jun 2018, Michal Hocko wrote: > > > > > On Fri 22-06-18 11:01:51, Michal Hocko wrote: > > > > On Thu 21-06-18 21:17:24, Mikulas Patocka wrote: > > > [...] > > > > > What about this patch? If __GFP_NORETRY and __GFP_FS is not set (i.e. > > > > > the > > > > > request comes from a block device driver or a filesystem), we should > > > > > not > > > > > sleep. > > > > > > > > Why? How are you going to audit all the callers that the behavior makes > > > > sense and moreover how are you going to ensure that future usage will > > > > still make sense. The more subtle side effects gfp flags have the harder > > > > they are to maintain. > > > > > > So just as an excercise. Try to explain the above semantic to users. We > > > currently have the following. > > > > > > * __GFP_NORETRY: The VM implementation will try only very lightweight > > > * memory direct reclaim to get some memory under memory pressure (thus > > > * it can sleep). It will avoid disruptive actions like OOM killer. The > > > * caller must handle the failure which is quite likely to happen under > > > * heavy memory pressure. The flag is suitable when failure can easily > > > be > > > * handled at small cost, such as reduced throughput > > > > > > * __GFP_FS can call down to the low-level FS. Clearing the flag avoids > > > the > > > * allocator recursing into the filesystem which might already be > > > holding > > > * locks. > > > > > > So how are you going to explain gfp & (__GFP_NORETRY | ~__GFP_FS)? What > > > is the actual semantic without explaining the whole reclaim or force > > > users to look into the code to understand that? What about GFP_NOIO | > > > __GFP_NORETRY? What does it mean to that "should not sleep". Do all > > > shrinkers have to follow that as well? > > > > My reasoning was that there is broken code that uses __GFP_NORETRY and > > assumes that it can't fail - so conditioning the change on !__GFP_FS would > > minimize the diruption to the broken code. > > > > Anyway - if you want to test only on __GFP_NORETRY (and fix those 16 > > broken cases that assume that __GFP_NORETRY can't fail), I'm OK with that. > > As I've already said, this is a subtle change which is really hard to > reason about. Throttling on congestion has its meaning and reason. Look > at why we are doing that in the first place. You cannot simply say this So - explain why is throttling needed. You support throttling, I don't, so you have to explain it :) > is ok based on your specific usecase. We do have means to achieve that. > It is explicit and thus it will be applied only where it makes sense. > You keep repeating that implicit behavior change for everybody is > better. I don't want to change it for everybody. I want to change it for block device drivers. I don't care what you do with non-block drivers. > I guess we will not agree on that part. I consider it a hack > rather than a systematic solution. I can easily imagine that we just > find out other call sites that would cause over reclaim or similar If a __GFP_NORETRY allocation does overreclaim - it could be fixed by returning NULL instead of doing overreclaim. The specification says that callers must handle failure of __GFP_NORETRY allocations. So yes - if you think that just skipping throttling on __GFP_NORETRY could cause excessive CPU consumption trying to reclaim unreclaimable pages or something like that - then you can add more points where the __GFP_NORETRY is failed with NULL to avoid the excessive CPU consumption. > problems because they are not throttled on too many dirty pages due to > congested storage. What are we going to then? Add another magic gfp > flag? Really, try to not add even more subtle side effects for gfp > flags. We _do_ have ways to accomplish what your particular usecase > requires. > > -- > Michal Hocko > SUSE Labs Mikulas -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
[dm-devel] [dm:for-next 6/8] drivers/md/dm-writecache.c:862:24: error: implicit declaration of function 'array_size'; did you mean '__ua_size'?
tree:
https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git
for-next
head: 696ee10fad76d6ec15f256e6dc2c08aa2c706890
commit: 5174624414ac49495a08eca4ee584dac193c0eb7 [6/8] dm writecache: use
2-factor allocator arguments
config: mips-allyesconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 5174624414ac49495a08eca4ee584dac193c0eb7
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=mips
All errors (new ones prefixed by >>):
drivers/md/dm-writecache.c: In function 'writecache_alloc_entries':
>> drivers/md/dm-writecache.c:862:24: error: implicit declaration of function
>> 'array_size'; did you mean '__ua_size'?
>> [-Werror=implicit-function-declaration]
wc->entries = vmalloc(array_size(sizeof(struct wc_entry), wc->n_blocks));
^~
__ua_size
cc1: some warnings being treated as errors
vim +862 drivers/md/dm-writecache.c
855
856 static int writecache_alloc_entries(struct dm_writecache *wc)
857 {
858 size_t b;
859
860 if (wc->entries)
861 return 0;
> 862 wc->entries = vmalloc(array_size(sizeof(struct wc_entry),
> wc->n_blocks));
863 if (!wc->entries)
864 return -ENOMEM;
865 for (b = 0; b < wc->n_blocks; b++) {
866 struct wc_entry *e = >entries[b];
867 e->index = b;
868 e->write_in_progress = false;
869 }
870
871 return 0;
872 }
873
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
[dm-devel] [PATCH v2] dm-zoned: Avoid triggering reclaim from inside dmz_map()
This patch avoids that lockdep reports the following:
==
WARNING: possible circular locking dependency detected
4.18.0-rc1 #62 Not tainted
--
kswapd0/84 is trying to acquire lock:
c313516d (_nondir_ilock_class){}, at:
xfs_free_eofblocks+0xa2/0x1e0
but task is already holding lock:
591c83ae (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x5/0x30
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (fs_reclaim){+.+.}:
kmem_cache_alloc+0x2c/0x2b0
radix_tree_node_alloc.constprop.19+0x3d/0xc0
__radix_tree_create+0x161/0x1c0
__radix_tree_insert+0x45/0x210
dmz_map+0x245/0x2d0 [dm_zoned]
__map_bio+0x40/0x260
__split_and_process_non_flush+0x116/0x220
__split_and_process_bio+0x81/0x180
__dm_make_request.isra.32+0x5a/0x100
generic_make_request+0x36e/0x690
submit_bio+0x6c/0x140
mpage_readpages+0x19e/0x1f0
read_pages+0x6d/0x1b0
__do_page_cache_readahead+0x21b/0x2d0
force_page_cache_readahead+0xc4/0x100
generic_file_read_iter+0x7c6/0xd20
__vfs_read+0x102/0x180
vfs_read+0x9b/0x140
ksys_read+0x55/0xc0
do_syscall_64+0x5a/0x1f0
entry_SYSCALL_64_after_hwframe+0x49/0xbe
-> #1 (>chunk_lock){+.+.}:
dmz_map+0x133/0x2d0 [dm_zoned]
__map_bio+0x40/0x260
__split_and_process_non_flush+0x116/0x220
__split_and_process_bio+0x81/0x180
__dm_make_request.isra.32+0x5a/0x100
generic_make_request+0x36e/0x690
submit_bio+0x6c/0x140
_xfs_buf_ioapply+0x31c/0x590
xfs_buf_submit_wait+0x73/0x520
xfs_buf_read_map+0x134/0x2f0
xfs_trans_read_buf_map+0xc3/0x580
xfs_read_agf+0xa5/0x1e0
xfs_alloc_read_agf+0x59/0x2b0
xfs_alloc_pagf_init+0x27/0x60
xfs_bmap_longest_free_extent+0x43/0xb0
xfs_bmap_btalloc_nullfb+0x7f/0xf0
xfs_bmap_btalloc+0x428/0x7c0
xfs_bmapi_write+0x598/0xcc0
xfs_iomap_write_allocate+0x15a/0x330
xfs_map_blocks+0x1cf/0x3f0
xfs_do_writepage+0x15f/0x7b0
write_cache_pages+0x1ca/0x540
xfs_vm_writepages+0x65/0xa0
do_writepages+0x48/0xf0
__writeback_single_inode+0x58/0x730
writeback_sb_inodes+0x249/0x5c0
wb_writeback+0x11e/0x550
wb_workfn+0xa3/0x670
process_one_work+0x228/0x670
worker_thread+0x3c/0x390
kthread+0x11c/0x140
ret_from_fork+0x3a/0x50
-> #0 (_nondir_ilock_class){}:
down_read_nested+0x43/0x70
xfs_free_eofblocks+0xa2/0x1e0
xfs_fs_destroy_inode+0xac/0x270
dispose_list+0x51/0x80
prune_icache_sb+0x52/0x70
super_cache_scan+0x127/0x1a0
shrink_slab.part.47+0x1bd/0x590
shrink_node+0x3b5/0x470
balance_pgdat+0x158/0x3b0
kswapd+0x1ba/0x600
kthread+0x11c/0x140
ret_from_fork+0x3a/0x50
other info that might help us debug this:
Chain exists of:
_nondir_ilock_class --> >chunk_lock --> fs_reclaim
Possible unsafe locking scenario:
CPU0CPU1
lock(fs_reclaim);
lock(>chunk_lock);
lock(fs_reclaim);
lock(_nondir_ilock_class);
*** DEADLOCK ***
3 locks held by kswapd0/84:
#0: 591c83ae (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x5/0x30
#1: 0f8208f5 (shrinker_rwsem){}, at: shrink_slab.part.47+0x3f/0x590
#2: cacefa54 (>s_umount_key#43){.+.+}, at:
trylock_super+0x16/0x50
stack backtrace:
CPU: 7 PID: 84 Comm: kswapd0 Not tainted 4.18.0-rc1 #62
Hardware name: Supermicro Super Server/X10SRL-F, BIOS 2.0 12/17/2015
Call Trace:
dump_stack+0x85/0xcb
print_circular_bug.isra.36+0x1ce/0x1db
__lock_acquire+0x124e/0x1310
lock_acquire+0x9f/0x1f0
down_read_nested+0x43/0x70
xfs_free_eofblocks+0xa2/0x1e0
xfs_fs_destroy_inode+0xac/0x270
dispose_list+0x51/0x80
prune_icache_sb+0x52/0x70
super_cache_scan+0x127/0x1a0
shrink_slab.part.47+0x1bd/0x590
shrink_node+0x3b5/0x470
balance_pgdat+0x158/0x3b0
kswapd+0x1ba/0x600
kthread+0x11c/0x140
ret_from_fork+0x3a/0x50
Reported-by: Masato Suzuki
Fixes: 4218a9554653 ("dm zoned: use GFP_NOIO in I/O path")
Signed-off-by: Bart Van Assche
Cc: Damien Le Moal
Cc: Mikulas Patocka
Cc:
---
Changes compared to v1: added "Cc: stable"
drivers/md/dm-zoned-target.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/dm-zoned-target.c b/drivers/md/dm-zoned-target.c
index 3c0e45f4dcf5..a44183ff4be0 100644
--- a/drivers/md/dm-zoned-target.c
+++ b/drivers/md/dm-zoned-target.c
@@ -787,7 +787,7 @@ static int dmz_ctr(struct dm_target *ti, unsigned int argc,
char **argv)
/* Chunk BIO work */
mutex_init(>chunk_lock);
- INIT_RADIX_TREE(>chunk_rxtree, GFP_KERNEL);
+ INIT_RADIX_TREE(>chunk_rxtree, GFP_NOIO);
dmz->chunk_wq = alloc_workqueue("dmz_cwq_%s", WQ_MEM_RECLAIM |
WQ_UNBOUND,
0, dev->name);
if (!dmz->chunk_wq) {
--
2.17.1
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
[dm-devel] [PATCH] dm-zoned: Avoid triggering reclaim from inside dmz_map()
This patch avoids that lockdep reports the following:
==
WARNING: possible circular locking dependency detected
4.18.0-rc1 #62 Not tainted
--
kswapd0/84 is trying to acquire lock:
c313516d (_nondir_ilock_class){}, at:
xfs_free_eofblocks+0xa2/0x1e0
but task is already holding lock:
591c83ae (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x5/0x30
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (fs_reclaim){+.+.}:
kmem_cache_alloc+0x2c/0x2b0
radix_tree_node_alloc.constprop.19+0x3d/0xc0
__radix_tree_create+0x161/0x1c0
__radix_tree_insert+0x45/0x210
dmz_map+0x245/0x2d0 [dm_zoned]
__map_bio+0x40/0x260
__split_and_process_non_flush+0x116/0x220
__split_and_process_bio+0x81/0x180
__dm_make_request.isra.32+0x5a/0x100
generic_make_request+0x36e/0x690
submit_bio+0x6c/0x140
mpage_readpages+0x19e/0x1f0
read_pages+0x6d/0x1b0
__do_page_cache_readahead+0x21b/0x2d0
force_page_cache_readahead+0xc4/0x100
generic_file_read_iter+0x7c6/0xd20
__vfs_read+0x102/0x180
vfs_read+0x9b/0x140
ksys_read+0x55/0xc0
do_syscall_64+0x5a/0x1f0
entry_SYSCALL_64_after_hwframe+0x49/0xbe
-> #1 (>chunk_lock){+.+.}:
dmz_map+0x133/0x2d0 [dm_zoned]
__map_bio+0x40/0x260
__split_and_process_non_flush+0x116/0x220
__split_and_process_bio+0x81/0x180
__dm_make_request.isra.32+0x5a/0x100
generic_make_request+0x36e/0x690
submit_bio+0x6c/0x140
_xfs_buf_ioapply+0x31c/0x590
xfs_buf_submit_wait+0x73/0x520
xfs_buf_read_map+0x134/0x2f0
xfs_trans_read_buf_map+0xc3/0x580
xfs_read_agf+0xa5/0x1e0
xfs_alloc_read_agf+0x59/0x2b0
xfs_alloc_pagf_init+0x27/0x60
xfs_bmap_longest_free_extent+0x43/0xb0
xfs_bmap_btalloc_nullfb+0x7f/0xf0
xfs_bmap_btalloc+0x428/0x7c0
xfs_bmapi_write+0x598/0xcc0
xfs_iomap_write_allocate+0x15a/0x330
xfs_map_blocks+0x1cf/0x3f0
xfs_do_writepage+0x15f/0x7b0
write_cache_pages+0x1ca/0x540
xfs_vm_writepages+0x65/0xa0
do_writepages+0x48/0xf0
__writeback_single_inode+0x58/0x730
writeback_sb_inodes+0x249/0x5c0
wb_writeback+0x11e/0x550
wb_workfn+0xa3/0x670
process_one_work+0x228/0x670
worker_thread+0x3c/0x390
kthread+0x11c/0x140
ret_from_fork+0x3a/0x50
-> #0 (_nondir_ilock_class){}:
down_read_nested+0x43/0x70
xfs_free_eofblocks+0xa2/0x1e0
xfs_fs_destroy_inode+0xac/0x270
dispose_list+0x51/0x80
prune_icache_sb+0x52/0x70
super_cache_scan+0x127/0x1a0
shrink_slab.part.47+0x1bd/0x590
shrink_node+0x3b5/0x470
balance_pgdat+0x158/0x3b0
kswapd+0x1ba/0x600
kthread+0x11c/0x140
ret_from_fork+0x3a/0x50
other info that might help us debug this:
Chain exists of:
_nondir_ilock_class --> >chunk_lock --> fs_reclaim
Possible unsafe locking scenario:
CPU0CPU1
lock(fs_reclaim);
lock(>chunk_lock);
lock(fs_reclaim);
lock(_nondir_ilock_class);
*** DEADLOCK ***
3 locks held by kswapd0/84:
#0: 591c83ae (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x5/0x30
#1: 0f8208f5 (shrinker_rwsem){}, at: shrink_slab.part.47+0x3f/0x590
#2: cacefa54 (>s_umount_key#43){.+.+}, at:
trylock_super+0x16/0x50
stack backtrace:
CPU: 7 PID: 84 Comm: kswapd0 Not tainted 4.18.0-rc1 #62
Hardware name: Supermicro Super Server/X10SRL-F, BIOS 2.0 12/17/2015
Call Trace:
dump_stack+0x85/0xcb
print_circular_bug.isra.36+0x1ce/0x1db
__lock_acquire+0x124e/0x1310
lock_acquire+0x9f/0x1f0
down_read_nested+0x43/0x70
xfs_free_eofblocks+0xa2/0x1e0
xfs_fs_destroy_inode+0xac/0x270
dispose_list+0x51/0x80
prune_icache_sb+0x52/0x70
super_cache_scan+0x127/0x1a0
shrink_slab.part.47+0x1bd/0x590
shrink_node+0x3b5/0x470
balance_pgdat+0x158/0x3b0
kswapd+0x1ba/0x600
kthread+0x11c/0x140
ret_from_fork+0x3a/0x50
Reported-by: Masato Suzuki
Fixes: 4218a9554653 ("dm zoned: use GFP_NOIO in I/O path")
Signed-off-by: Bart Van Assche
Cc: Damien Le Moal
Cc: Mikulas Patocka
---
drivers/md/dm-zoned-target.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/dm-zoned-target.c b/drivers/md/dm-zoned-target.c
index 3c0e45f4dcf5..a44183ff4be0 100644
--- a/drivers/md/dm-zoned-target.c
+++ b/drivers/md/dm-zoned-target.c
@@ -787,7 +787,7 @@ static int dmz_ctr(struct dm_target *ti, unsigned int argc,
char **argv)
/* Chunk BIO work */
mutex_init(>chunk_lock);
- INIT_RADIX_TREE(>chunk_rxtree, GFP_KERNEL);
+ INIT_RADIX_TREE(>chunk_rxtree, GFP_NOIO);
dmz->chunk_wq = alloc_workqueue("dmz_cwq_%s", WQ_MEM_RECLAIM |
WQ_UNBOUND,
0, dev->name);
if (!dmz->chunk_wq) {
--
2.17.1
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
Re: [dm-devel] dm bufio: Reduce dm_bufio_lock contention
On Fri 22-06-18 08:44:52, Mikulas Patocka wrote: > On Fri, 22 Jun 2018, Michal Hocko wrote: [...] > > Why? How are you going to audit all the callers that the behavior makes > > sense and moreover how are you going to ensure that future usage will > > still make sense. The more subtle side effects gfp flags have the harder > > they are to maintain. > > I did audit them - see the previous email in this thread: > https://www.redhat.com/archives/dm-devel/2018-June/thread.html I do not see any mention about throttling expectations for those users. You have focused only on the allocation failure fallback AFAIR -- Michal Hocko SUSE Labs -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
Re: [dm-devel] dm bufio: Reduce dm_bufio_lock contention
On Fri 22-06-18 08:52:09, Mikulas Patocka wrote: > > > On Fri, 22 Jun 2018, Michal Hocko wrote: > > > On Fri 22-06-18 11:01:51, Michal Hocko wrote: > > > On Thu 21-06-18 21:17:24, Mikulas Patocka wrote: > > [...] > > > > What about this patch? If __GFP_NORETRY and __GFP_FS is not set (i.e. > > > > the > > > > request comes from a block device driver or a filesystem), we should > > > > not > > > > sleep. > > > > > > Why? How are you going to audit all the callers that the behavior makes > > > sense and moreover how are you going to ensure that future usage will > > > still make sense. The more subtle side effects gfp flags have the harder > > > they are to maintain. > > > > So just as an excercise. Try to explain the above semantic to users. We > > currently have the following. > > > > * __GFP_NORETRY: The VM implementation will try only very lightweight > > * memory direct reclaim to get some memory under memory pressure (thus > > * it can sleep). It will avoid disruptive actions like OOM killer. The > > * caller must handle the failure which is quite likely to happen under > > * heavy memory pressure. The flag is suitable when failure can easily be > > * handled at small cost, such as reduced throughput > > > > * __GFP_FS can call down to the low-level FS. Clearing the flag avoids the > > * allocator recursing into the filesystem which might already be holding > > * locks. > > > > So how are you going to explain gfp & (__GFP_NORETRY | ~__GFP_FS)? What > > is the actual semantic without explaining the whole reclaim or force > > users to look into the code to understand that? What about GFP_NOIO | > > __GFP_NORETRY? What does it mean to that "should not sleep". Do all > > shrinkers have to follow that as well? > > My reasoning was that there is broken code that uses __GFP_NORETRY and > assumes that it can't fail - so conditioning the change on !__GFP_FS would > minimize the diruption to the broken code. > > Anyway - if you want to test only on __GFP_NORETRY (and fix those 16 > broken cases that assume that __GFP_NORETRY can't fail), I'm OK with that. As I've already said, this is a subtle change which is really hard to reason about. Throttling on congestion has its meaning and reason. Look at why we are doing that in the first place. You cannot simply say this is ok based on your specific usecase. We do have means to achieve that. It is explicit and thus it will be applied only where it makes sense. You keep repeating that implicit behavior change for everybody is better. I guess we will not agree on that part. I consider it a hack rather than a systematic solution. I can easily imagine that we just find out other call sites that would cause over reclaim or similar problems because they are not throttled on too many dirty pages due to congested storage. What are we going to then? Add another magic gfp flag? Really, try to not add even more subtle side effects for gfp flags. We _do_ have ways to accomplish what your particular usecase requires. -- Michal Hocko SUSE Labs -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
Re: [dm-devel] dm bufio: Reduce dm_bufio_lock contention
On Fri, 22 Jun 2018, Michal Hocko wrote: > On Fri 22-06-18 11:01:51, Michal Hocko wrote: > > On Thu 21-06-18 21:17:24, Mikulas Patocka wrote: > [...] > > > What about this patch? If __GFP_NORETRY and __GFP_FS is not set (i.e. the > > > request comes from a block device driver or a filesystem), we should not > > > sleep. > > > > Why? How are you going to audit all the callers that the behavior makes > > sense and moreover how are you going to ensure that future usage will > > still make sense. The more subtle side effects gfp flags have the harder > > they are to maintain. > > So just as an excercise. Try to explain the above semantic to users. We > currently have the following. > > * __GFP_NORETRY: The VM implementation will try only very lightweight > * memory direct reclaim to get some memory under memory pressure (thus > * it can sleep). It will avoid disruptive actions like OOM killer. The > * caller must handle the failure which is quite likely to happen under > * heavy memory pressure. The flag is suitable when failure can easily be > * handled at small cost, such as reduced throughput > > * __GFP_FS can call down to the low-level FS. Clearing the flag avoids the > * allocator recursing into the filesystem which might already be holding > * locks. > > So how are you going to explain gfp & (__GFP_NORETRY | ~__GFP_FS)? What > is the actual semantic without explaining the whole reclaim or force > users to look into the code to understand that? What about GFP_NOIO | > __GFP_NORETRY? What does it mean to that "should not sleep". Do all > shrinkers have to follow that as well? My reasoning was that there is broken code that uses __GFP_NORETRY and assumes that it can't fail - so conditioning the change on !__GFP_FS would minimize the diruption to the broken code. Anyway - if you want to test only on __GFP_NORETRY (and fix those 16 broken cases that assume that __GFP_NORETRY can't fail), I'm OK with that. Mikulas Index: linux-2.6/mm/vmscan.c === --- linux-2.6.orig/mm/vmscan.c +++ linux-2.6/mm/vmscan.c @@ -2674,6 +2674,7 @@ static bool shrink_node(pg_data_t *pgdat * the LRU too quickly. */ if (!sc->hibernation_mode && !current_is_kswapd() && + !(sc->gfp_mask & __GFP_NORETRY) && current_may_throttle() && pgdat_memcg_congested(pgdat, root)) wait_iff_congested(BLK_RW_ASYNC, HZ/10); -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
Re: [dm-devel] dm bufio: Reduce dm_bufio_lock contention
On Fri, 22 Jun 2018, Michal Hocko wrote: > On Thu 21-06-18 21:17:24, Mikulas Patocka wrote: > [...] > > > But seriously, isn't the best way around the throttling issue to use > > > PF_LESS_THROTTLE? > > > > Yes - it could be done by setting PF_LESS_THROTTLE. But I think it would > > be better to change it just in one place than to add PF_LESS_THROTTLE to > > every block device driver (because adding it to every block driver results > > in more code). > > Why would every block device need this? I thought we were talking about > mempool allocator and the md variant of it. They are explicitly doing > their own back off so PF_LESS_THROTTLE sounds appropriate to me. Because every block driver is suspicible to this problem. Two years ago, there was a bug that when the user was swapping to dm-crypt device, memory management would stall the allocations done by dm-crypt by 100ms - that slowed down swapping rate and made the machine unuseable. Then, people are complaining about the same problem in dm-bufio. Next time, it will be something else. (you will answer : "we will not fix bugs unless people are reporting them" :-) > > What about this patch? If __GFP_NORETRY and __GFP_FS is not set (i.e. the > > request comes from a block device driver or a filesystem), we should not > > sleep. > > Why? How are you going to audit all the callers that the behavior makes > sense and moreover how are you going to ensure that future usage will > still make sense. The more subtle side effects gfp flags have the harder > they are to maintain. I did audit them - see the previous email in this thread: https://www.redhat.com/archives/dm-devel/2018-June/thread.html Mikulas > > Signed-off-by: Mikulas Patocka > > Cc: sta...@vger.kernel.org > > > > Index: linux-2.6/mm/vmscan.c > > === > > --- linux-2.6.orig/mm/vmscan.c > > +++ linux-2.6/mm/vmscan.c > > @@ -2674,6 +2674,7 @@ static bool shrink_node(pg_data_t *pgdat > > * the LRU too quickly. > > */ > > if (!sc->hibernation_mode && !current_is_kswapd() && > > + (sc->gfp_mask & (__GFP_NORETRY | __GFP_FS)) != __GFP_NORETRY > > && > >current_may_throttle() && pgdat_memcg_congested(pgdat, root)) > > wait_iff_congested(BLK_RW_ASYNC, HZ/10); > > > > -- > Michal Hocko > SUSE Labs > -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
Re: [dm-devel] dm bufio: Reduce dm_bufio_lock contention
On Thu 21-06-18 21:17:24, Mikulas Patocka wrote: [...] > > But seriously, isn't the best way around the throttling issue to use > > PF_LESS_THROTTLE? > > Yes - it could be done by setting PF_LESS_THROTTLE. But I think it would > be better to change it just in one place than to add PF_LESS_THROTTLE to > every block device driver (because adding it to every block driver results > in more code). Why would every block device need this? I thought we were talking about mempool allocator and the md variant of it. They are explicitly doing their own back off so PF_LESS_THROTTLE sounds appropriate to me. > What about this patch? If __GFP_NORETRY and __GFP_FS is not set (i.e. the > request comes from a block device driver or a filesystem), we should not > sleep. Why? How are you going to audit all the callers that the behavior makes sense and moreover how are you going to ensure that future usage will still make sense. The more subtle side effects gfp flags have the harder they are to maintain. > Signed-off-by: Mikulas Patocka > Cc: sta...@vger.kernel.org > > Index: linux-2.6/mm/vmscan.c > === > --- linux-2.6.orig/mm/vmscan.c > +++ linux-2.6/mm/vmscan.c > @@ -2674,6 +2674,7 @@ static bool shrink_node(pg_data_t *pgdat >* the LRU too quickly. >*/ > if (!sc->hibernation_mode && !current_is_kswapd() && > +(sc->gfp_mask & (__GFP_NORETRY | __GFP_FS)) != __GFP_NORETRY > && > current_may_throttle() && pgdat_memcg_congested(pgdat, root)) > wait_iff_congested(BLK_RW_ASYNC, HZ/10); > -- Michal Hocko SUSE Labs -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
[dm-devel] [PATCH] dm raid: don't use 'const' in function return
From: Arnd Bergmann
A newly introduced function has 'const int' as the return type,
but as "make W=1" reports, that has no meaning:
drivers/md/dm-raid.c:510:18: error: type qualifiers ignored on function return
type [-Werror=ignored-qualifiers]
This changes the return type to plain 'int'.
Signed-off-by: Arnd Bergmann
Fixes: 33e53f06850f ("dm raid: introduce extended superblock and new raid types
to support takeover/reshaping")
Signed-off-by: Mike Snitzer
Fixes: 552aa679f2657431 ("dm raid: use rs_is_raid*()")
Signed-off-by: Geert Uytterhoeven
---
Cherry-picked from 68c1c4d5eafc65dd ("dm raid: don't use 'const' in
function return") with new Fixes tag, as the issue has been
reintroduced.
---
drivers/md/dm-raid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/dm-raid.c b/drivers/md/dm-raid.c
index ab13fcec3fca046c..75df4c9d8b541de4 100644
--- a/drivers/md/dm-raid.c
+++ b/drivers/md/dm-raid.c
@@ -588,7 +588,7 @@ static const char *raid10_md_layout_to_format(int layout)
}
/* Return md raid10 algorithm for @name */
-static const int raid10_name_to_format(const char *name)
+static int raid10_name_to_format(const char *name)
{
if (!strcasecmp(name, "near"))
return ALGORITHM_RAID10_NEAR;
--
2.17.1
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
[dm-devel] [PATCH 4.17.0-rc3 1/2] dm: Reduce line length
Signed-off-by: Ssemagoye Umar Munddu
---
drivers/md/dm.c | 187 +---
1 file changed, 123 insertions(+), 64 deletions(-)
diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index 4ea404d..bb465e6 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -107,7 +107,8 @@ void *dm_per_bio_data(struct bio *bio, size_t data_size)
struct dm_target_io *tio = container_of(bio, struct dm_target_io,
clone);
if (!tio->inside_dm_io)
return (char *)bio - offsetof(struct dm_target_io, clone) -
data_size;
- return (char *)bio - offsetof(struct dm_target_io, clone) -
offsetof(struct dm_io, tio) - data_size;
+ return (char *)bio - offsetof(struct dm_target_io, clone) - offsetof(
+ struct dm_io, tio) - data_size;
}
EXPORT_SYMBOL_GPL(dm_per_bio_data);
@@ -115,7 +116,8 @@ struct bio *dm_bio_from_per_bio_data(void *data, size_t
data_size)
{
struct dm_io *io = (struct dm_io *)((char *)data + data_size);
if (io->magic == DM_IO_MAGIC)
- return (struct bio *)((char *)io + offsetof(struct dm_io, tio)
+ offsetof(struct dm_target_io, clone));
+ return (struct bio *)((char *)io + offsetof(
+ struct dm_io, tio) + offsetof(struct dm_target_io,
clone));
BUG_ON(io->magic != DM_TIO_MAGIC);
return (struct bio *)((char *)io + offsetof(struct dm_target_io,
clone));
}
@@ -228,7 +230,8 @@ static int __init local_init(void)
if (!_rq_tio_cache)
return r;
- _rq_cache = kmem_cache_create("dm_old_clone_request", sizeof(struct
request),
+ _rq_cache = kmem_cache_create("dm_old_clone_request", sizeof(
+ struct request),
__alignof__(struct request), 0, NULL);
if (!_rq_cache)
goto out_free_rq_tio_cache;
@@ -395,7 +398,8 @@ int dm_open_count(struct mapped_device *md)
/*
* Guarantees nothing is using the device before it's deleted.
*/
-int dm_lock_for_deletion(struct mapped_device *md, bool mark_deferred, bool
only_deferred)
+int dm_lock_for_deletion(
+ struct mapped_device *md, bool mark_deferred, bool only_deferred)
{
int r = 0;
@@ -451,7 +455,8 @@ struct dm_stats *dm_get_stats(struct mapped_device *md)
return >stats;
}
-static int dm_blk_getgeo(struct block_device *bdev, struct hd_geometry *geo)
+static int dm_blk_getgeo(
+ struct block_device *bdev, struct hd_geometry *geo)
{
struct mapped_device *md = bdev->bd_disk->private_data;
@@ -563,7 +568,8 @@ static void free_io(struct mapped_device *md, struct dm_io
*io)
bio_put(>tio.clone);
}
-static struct dm_target_io *alloc_tio(struct clone_info *ci, struct dm_target
*ti,
+static struct dm_target_io *alloc_tio(
+ struct clone_info *ci, struct dm_target *ti,
unsigned target_bio_nr, gfp_t gfp_mask)
{
struct dm_target_io *tio;
@@ -609,7 +615,8 @@ static void start_io_acct(struct dm_io *io)
io->start_time = jiffies;
- generic_start_io_acct(md->queue, rw, bio_sectors(bio),
_disk(md)->part0);
+ generic_start_io_acct(
+ md->queue, rw, bio_sectors(bio), _disk(md)->part0);
atomic_set(_disk(md)->part0.in_flight[rw],
atomic_inc_return(>pending[rw]));
@@ -666,14 +673,16 @@ static void queue_io(struct mapped_device *md, struct bio
*bio)
* function to access the md->map field, and make sure they call
* dm_put_live_table() when finished.
*/
-struct dm_table *dm_get_live_table(struct mapped_device *md, int *srcu_idx)
__acquires(md->io_barrier)
+struct dm_table *dm_get_live_table(
+ struct mapped_device *md, int *srcu_idx) __acquires(md->io_barrier)
{
*srcu_idx = srcu_read_lock(>io_barrier);
return srcu_dereference(md->map, >io_barrier);
}
-void dm_put_live_table(struct mapped_device *md, int srcu_idx)
__releases(md->io_barrier)
+void dm_put_live_table(
+ struct mapped_device *md, int srcu_idx) __releases(md->io_barrier)
{
srcu_read_unlock(>io_barrier, srcu_idx);
}
@@ -688,13 +697,15 @@ void dm_sync_table(struct mapped_device *md)
* A fast alternative to dm_get_live_table/dm_put_live_table.
* The caller must not block between these two functions.
*/
-static struct dm_table *dm_get_live_table_fast(struct mapped_device *md)
__acquires(RCU)
+static struct dm_table *dm_get_live_table_fast(
+ struct mapped_device *md) __acquires(RCU)
{
rcu_read_lock();
return rcu_dereference(md->map);
}
-static void dm_put_live_table_fast(struct mapped_device *md) __releases(RCU)
+static void dm_put_live_table_fast(
+ struct mapped_device *md) __releases(RCU)
{
rcu_read_unlock();
}
@@ -713,7 +724,8 @@ static int open_table_device(struct table_device *td, dev_t
dev,
