On 2017年07月11日 16:41, Nicholas A. Bellinger wrote:
Hey Xiubo,
On Tue, 2017-07-11 at 16:04 +0800, Xiubo Li wrote:
Hi All
Please ignore about this patch.
Just my mistake.
Sorry.
Damien (CC'ed) has been observing something similar atop the latest
target-pending/for-next with his user-space ZBC backend:
http://www.spinics.net/lists/target-devel/msg15804.html
Sorry I missed about this thread these days just for debugging about
similar issue reported by Bryant weeks ago to me and Mike.
I had reproduced one crash bug as Bryant reported, but I couldn't get
any crash dump message due to the kdump service failed to start up on my
environment, I have sent another patch just after this one and have test
it about 17 hours which on my environment works fine.
Please ignore about the current patch, which is none sense and will
introduce a new bug.
I'm not very sure my another fix patch will resolve the crash as Damien
reported, and I will have a look later.
Just curious, are you going to re-send a different patch to address
this..?
Another fix patch has been sent, please review.
Is there anything that he can test to verify it's the same bug..?
I could get any crash dump message on my environment, so need more
investigate about mine and Damien's.
Thanks,
BRs
Xiubo
Brs
Xiubo
On 2017年07月11日 15:40, lixiubo@xxxxxxxxxxxxxxxxxxxx wrote:
From: Xiubo Li <lixiubo@xxxxxxxxxxxxxxxxxxxx>
Before the data area dynamic grow patches, though the overflow
bug was already exist, since the data area memories are all
preallocated, so there mostly won't any bad page fault core
trace produced.
The dynamic grow patches will only allocate and map the block
needed in data area, so when memcpy overflow, the system will
die.
[ 367.864705] [c0000000fc657340] [c0000000000d220c] do_exit+0x79c/0xcf0
[ 367.864710] [c0000000fc657410] [c0000000000249a4] die+0x314/0x470
[ 367.864715] [c0000000fc6574a0] [c00000000005425c] bad_page_fault+0xdc/0x150
[ 367.864720] [c0000000fc657510] [c000000000008964] handle_page_fault+0x2c/0x30
[ 367.864726] --- interrupt: 300 at memcpy_power7+0x20c/0x840
[ 367.864726] LR = tcmu_queue_cmd+0x844/0xa80 [target_core_user]
[ 367.864732] [c0000000fc657800] [d0000000088916d8] tcmu_queue_cmd+0x768/0xa80 [target_core_user] (unreliable)
[ 367.864746] [c0000000fc657940] [d000000002993184] __target_execute_cmd+0x54/0x150 [target_core_mod]
[ 367.864758] [c0000000fc657970] [d000000002994708] transport_generic_new_cmd+0x158/0x2d0 [target_core_mod]
[ 367.864770] [c0000000fc6579f0] [d0000000029948e4] transport_handle_cdb_direct+0x64/0xd0 [target_core_mod]
[ 367.864783] [c0000000fc657a60] [d000000002994af8] target_submit_cmd_map_sgls+0x1a8/0x320 [target_core_mod]
[ 367.864796] [c0000000fc657af0] [d000000002994cb8] target_submit_cmd+0x48/0x60 [target_core_mod]
[ 367.864803] [c0000000fc657b90] [d000000002a54bd0] ibmvscsis_scheduler+0x350/0x5c0 [ibmvscsis]
[ 367.864808] [c0000000fc657c50] [c0000000000f1c28] process_one_work+0x1e8/0x5b0
[ 367.864813] [c0000000fc657ce0] [c0000000000f2098] worker_thread+0xa8/0x650
[ 367.864818] [c0000000fc657d80] [c0000000000fa864] kthread+0x114/0x140
[ 367.864823] [c0000000fc657e30] [c0000000000098f0] ret_from_kernel_thread+0x5c/0x6c
[ 367.864827] Instruction dump:
[ 367.864829] 60420000 7fe3fb78 4bfcd175 60000000 4bfffecc 7c0802a6 f8010010 60000000
[ 367.864838] 7c0802a6 f8010010 f821ffe1 e9230690 <e869ffd8> 38210020 e8010010 7c0803a6
[ 367.864847] ---[ end trace 8d085df7e65f7d20 ]---
[ 367.870358]
[ 367.870362] Fixing recursive fault but reboot is needed!
[ 388.859695] INFO: rcu_sched detected stalls on CPUs/tasks:
[ 388.859717] 16-...: (0 ticks this GP) idle=7e3/140000000000000/0 softirq=12245/12245 fqs=2622
[ 388.859722] (detected by 20, t=5252 jiffies, g=12458, c=12457, q=2904)
[ 388.859744] Task dump for CPU 16:
[ 388.859747] kworker/16:2 D 0000000000000000 0 6865 0 0x00000800
[ 388.859762] Call Trace:
[ 388.859768] [c0000000fc6579a0] [c0000000014ef090] sysctl_sched_migration_cost+0x0/0x4 (unreliable)
[ 388.859778] [c0000000fc6579c0] [d000000008890c1c] tcmu_parse_cdb+0x2c/0x40 [target_core_user]
[ 388.859782] [c0000000fc6579e0] [c0000000fc657a60] 0xc0000000fc657a60
Reported-by: Bryant G. Ly <bryantly@xxxxxxxxxxxxxxxxxx>
Signed-off-by: Xiubo Li <lixiubo@xxxxxxxxxxxxxxxxxxxx>
---
drivers/target/target_core_user.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/target/target_core_user.c b/drivers/target/target_core_user.c
index 930800c..86a845a 100644
--- a/drivers/target/target_core_user.c
+++ b/drivers/target/target_core_user.c
@@ -437,7 +437,7 @@ static int scatter_data_area(struct tcmu_dev *udev,
to_offset = get_block_offset_user(udev, dbi,
block_remaining);
offset = DATA_BLOCK_SIZE - block_remaining;
- to = (void *)(unsigned long)to + offset;
+ to = (void *)((unsigned long)to + offset);
if (*iov_cnt != 0 &&
to_offset == iov_tail(udev, *iov)) {
@@ -510,7 +510,7 @@ static void gather_data_area(struct tcmu_dev *udev, struct tcmu_cmd *cmd,
copy_bytes = min_t(size_t, sg_remaining,
block_remaining);
offset = DATA_BLOCK_SIZE - block_remaining;
- from = (void *)(unsigned long)from + offset;
+ from = (void *)((unsigned long)from + offset);
tcmu_flush_dcache_range(from, copy_bytes);
memcpy(to + sg->length - sg_remaining, from,
copy_bytes);
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
