On Mon, 2011-11-28 at 12:33 +0100, Sebastian Andrzej Siewior wrote:
> Fixes:
> |kernel BUG at include/linux/scatterlist.h:97!
> |invalid opcode: 0000 [#1] PREEMPT SMP
> |Modules linked in: sd_mod tcm_loop target_core_stgt scsi_tgt target_core_pscsi target_core_file target_core_iblock target_core_mod configfs scsi_mod
> |
> |Pid: 671, comm: LIO_fileio Not tainted 3.1.0-rc10+ #139 Bochs Bochs
> |EIP: 0060:[<e0afd746>] EFLAGS: 00010202 CPU: 0
> |EIP is at fd_do_task+0x396/0x420 [target_core_file]
> | [<e0aa7884>] __transport_execute_tasks+0xd4/0x190 [target_core_mod]
> | [<e0aa797c>] transport_execute_tasks+0x3c/0xf0 [target_core_mod]
> |EIP: [<e0afd746>] fd_do_task+0x396/0x420 [target_core_file] SS:ESP 0068:dea47e90
>
> which appeared while executing mkfs.ext2 /dev/sda1.
>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx>
> ---
> drivers/target/target_core_file.c | 12 ++++++------
> 1 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/target/target_core_file.c b/drivers/target/target_core_file.c
> index e51addf..1e2d4a2 100644
> --- a/drivers/target/target_core_file.c
> +++ b/drivers/target/target_core_file.c
> @@ -287,9 +287,9 @@ static int fd_do_readv(struct se_task *task)
> return -ENOMEM;
> }
>
> - for (i = 0; i < task->task_sg_nents; i++) {
> - iov[i].iov_len = sg[i].length;
> - iov[i].iov_base = sg_virt(&sg[i]);
> + for_each_sg(task->task_sg, sg, task->task_sg_nents, i) {
> + iov[i].iov_len = sg->length;
> + iov[i].iov_base = sg_virt(sg);
> }
>
> old_fs = get_fs();
> @@ -340,9 +340,9 @@ static int fd_do_writev(struct se_task *task)
> return -ENOMEM;
> }
>
> - for (i = 0; i < task->task_sg_nents; i++) {
> - iov[i].iov_len = sg[i].length;
> - iov[i].iov_base = sg_virt(&sg[i]);
> + for_each_sg(task->task_sg, sg, task->task_sg_nents, i) {
> + iov[i].iov_len = sg->length;
> + iov[i].iov_base = sg_virt(sg);
> }
>
> old_fs = get_fs();
Note that IBLOCK and PSCSI are already using for_each_sg when walking
task->task_sg memory, and making FILEIO do this as well is what we
should be doing. However, I'm curious what your use-case was to trigger
this with fileio, as we don't expect a single task to ever use chained
sg in order to trigger this bug..?
Is this with a manually set small max_sectors fileio backend, or a
limited block_device max_sectors with fileio that would cause > 1 task
allocation to occur on your setup..?
--nab
--
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
