On 11/28/2011 12:47 PM, Nicholas A. Bellinger wrote:
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..?
This script:
#!/bin/sh
modprobe target_core_mod
mount a -t configfs /sys/kernel/config
CONFIGFS=/sys/kernel/config/
TARGET=/sys/kernel/config/target/core/
export FABRIC=/sys/kernel/config/target/loopback/
mkdir -p $TARGET/fileio_0/fileio
echo "fd_dev_name=/root/file.bin,fd_dev_size=31457280" >
$TARGET/fileio_0/fileio/control
echo 1 > $TARGET/fileio_0/fileio/enable
mkdir -p $FABRIC/naa.6001405c3214b06a/tpgt_1
mkdir $FABRIC/naa.6001405c3214b06a/tpgt_1/lun/lun_0
echo naa.6001405c3214b06b > $FABRIC/naa.6001405c3214b06a/tpgt_1/nexus
ln -sv $TARGET/fileio_0/fileio
$FABRIC/naa.6001405c3214b06a/tpgt_1/lun/lun_0/virtual_scsi_port
followed by
- cfdiks /dev/sda (make 1 partition)
- mkfs.ext2 /dev/sda
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..?
Just the script I mentioned plus the two commands afterwords. The crash
happens during mkfs.ext2
--nab
Sebastian
--
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
