On Mon, 23 Sep 2013, Jingoo Han wrote:
> The driver core clears the driver data to NULL after device_release
> or on probe failure. Thus, it is not needed to manually clear the
> device driver data to NULL.
>
> Signed-off-by: Jingoo Han
Acked-by: Guennadi Liakhovetski
Thanks
Guennadi
> ---
>
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han
---
drivers/scsi/tmscsim.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/scsi/tmscsim.c b/dr
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han
---
drivers/scsi/dc395x.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/scsi/dc395x.c b/driv
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han
---
drivers/scsi/vmw_pvscsi.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/scsi/vmw_pvscs
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han
---
drivers/scsi/ufs/ufshcd-pci.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/scsi/ufs/ufs
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han
---
drivers/scsi/stex.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/scsi/stex.c b/driver
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han
---
drivers/scsi/qla4xxx/ql4_os.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/scsi/qla4xxx
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han
---
drivers/scsi/qla2xxx/qla_os.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/scsi/qla2xxx
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han
---
drivers/scsi/pmcraid.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/scsi/pmcraid.c b/dr
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han
---
drivers/scsi/pm8001/pm8001_init.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/scsi/pm8
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han
---
drivers/scsi/mvsas/mv_init.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/scsi/mvsas/mv
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han
---
drivers/scsi/mvumi.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/scsi/mvumi.c b/driv
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han
---
drivers/scsi/megaraid/megaraid_mbox.c |6 --
drivers/scsi/megaraid/megaraid_sas_base.c |
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han
---
drivers/scsi/hpsa.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han
---
drivers/scsi/fnic/fnic_main.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/scsi/fnic/fn
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han
---
drivers/scsi/gdth.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/scsi/gdth.c b/driver
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han
---
drivers/scsi/csiostor/csio_init.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/scsi/c
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han
---
drivers/scsi/bfa/bfad.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/scsi/bfa/bfad.c b/
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han
---
drivers/scsi/atp870u.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/scsi/atp870u.c b/
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han
---
drivers/scsi/arcmsr/arcmsr_hba.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/scsi/arcm
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han
---
drivers/scsi/lpfc/lpfc_init.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/scsi/lpfc
Since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound),
the driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
---
drivers/scsi/ar
On Sun, 2013-09-22 at 20:44 +0200, Peter Senna Tschudin wrote:
> Convert 0 to false and 1 to true when assigning values to bool
> variables. Inspired by commit 3db1cd5c05f35fb43eb134df6f321de4e63141f2.
[]
> @@
> bool b;
> @@
> -b = 1
> +b = true
You might also look for non-zero values other than 1
https://bugzilla.kernel.org/show_bug.cgi?id=60758
--- Comment #36 from Alan Bartlett ---
(In reply to zakrzewskim from comment #34)
> Tested again. Here are the results:
>
> http://files.tinypic.pl/i/00449/clv7pa58vgxk.jpg
> http://files.tinypic.pl/i/00449/nawfo9bwhyn8.jpg
>
> Please help the c
https://bugzilla.kernel.org/show_bug.cgi?id=60758
--- Comment #35 from zakrzews...@wp.pl ---
Please note that was with:
#{ rmmod scsi_wait_scan ; modprobe scsi_wait_scan ; rmmod scsi_wait_scan ; }
>/dev/null 2>&1
and
title CentOS (3.11.1-2.el6.elrepo.x86_64)
root (hd0,1)
kernel /vmlinuz-3.11.1-
https://bugzilla.kernel.org/show_bug.cgi?id=60758
zakrzews...@wp.pl changed:
What|Removed |Added
Kernel Version|3.10.6 |3.10.5-3.11.1
--
You are receiving th
https://bugzilla.kernel.org/show_bug.cgi?id=60758
--- Comment #34 from zakrzews...@wp.pl ---
Tested again. Here are the results:
http://files.tinypic.pl/i/00449/clv7pa58vgxk.jpg
http://files.tinypic.pl/i/00449/nawfo9bwhyn8.jpg
Please help the current kernel is just unstable !
--
You are receiv
On Sun, Sep 22, 2013 at 2:47 PM, Tejun Heo wrote:
> Hello,
>
> On Sun, Sep 22, 2013 at 11:59:53AM -0700, Dmitry Vyukov wrote:
>> I've noticed that free happens in scsi_error_handler thread, so maybe
>> a timeout or some other error condition is involved here.
>> It is possible that timeout happens
Hello,
On Sun, Sep 22, 2013 at 11:59:53AM -0700, Dmitry Vyukov wrote:
> I've noticed that free happens in scsi_error_handler thread, so maybe
> a timeout or some other error condition is involved here.
> It is possible that timeout happens while the request is still being
> in process of submittin
https://bugzilla.kernel.org/show_bug.cgi?id=60758
--- Comment #33 from zakrzews...@wp.pl ---
Maybe this will help:
lspci
00:00.0 Host bridge: Intel Corporation 4th Gen Core Processor DRAM Controller
(rev 06)
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen
Core Process
On Sun, Sep 22, 2013 at 11:24 AM, Dmitry Vyukov wrote:
> On Sun, Sep 22, 2013 at 9:39 AM, Tejun Heo wrote:
>>
>> (cc'ing SCSI people)
>>
>> On Wed, Sep 18, 2013 at 11:45:22AM -0700, Dmitry Vyukov wrote:
>> > Hi!
>> >
>> > I am working on AddressSanitizer -- a tool that detects use-after-free
>> >
Convert 0 to false and 1 to true when assigning values to bool
variables. Inspired by commit 3db1cd5c05f35fb43eb134df6f321de4e63141f2.
The simplified semantic patch that find this problem is as
follows (http://coccinelle.lip6.fr/):
@@
bool b;
@@
(
-b = 0
+b = false
|
-b = 1
+b = true
)
Signed-of
On Sun, Sep 22, 2013 at 9:39 AM, Tejun Heo wrote:
>
> (cc'ing SCSI people)
>
> On Wed, Sep 18, 2013 at 11:45:22AM -0700, Dmitry Vyukov wrote:
> > Hi!
> >
> > I am working on AddressSanitizer -- a tool that detects use-after-free
> > and out-of-bounds bugs
> > (https://code.google.com/p/address-san
Hello James
I used the two most recent debian kernels (3.10 and 3.11)
both show this behaviour, both have the same problem
Also of course i had a look at both git trees before sending out the email
Taking the debian kernel source tree for 3.11-trunk and reverting the patch
makes the raid control
James Bottomley wrote:
>[cc to linux-scsi added]
>On Sun, 2013-09-22 at 16:27 +0200, Christian Bahls - gmail.com wrote:
>> Dear all,
>>
>> Looks like i have been bitten by the above mentioned commit.
>
>Just from a practical point of view, I only really work upstream, so
>this commit id doesn't s
(cc'ing SCSI people)
On Wed, Sep 18, 2013 at 11:45:22AM -0700, Dmitry Vyukov wrote:
> Hi!
>
> I am working on AddressSanitizer -- a tool that detects use-after-free
> and out-of-bounds bugs
> (https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel).
> Below is one of the bug r
https://bugzilla.kernel.org/show_bug.cgi?id=60758
--- Comment #32 from zakrzews...@wp.pl ---
It seems I'm not the only one with this problem:
http://www.gossamer-threads.com/lists/linux/kernel/1747344
--
You are receiving this mail because:
You are the assignee for the bug.
--
To unsubscribe fro
https://bugzilla.kernel.org/show_bug.cgi?id=60758
--- Comment #31 from zakrzews...@wp.pl ---
Standard CentOS 6 kernel got such module:
/lib/modules/2.6.32-358.18.1.el6.x86_64/kernel/drivers/scsi/scsi_wait_scan.ko
/lib/modules/2.6.32-358.el6.x86_64/kernel/drivers/scsi/scsi_wait_scan.ko
That's why
https://bugzilla.kernel.org/show_bug.cgi?id=60758
--- Comment #30 from zakrzews...@wp.pl ---
(In reply to Alan Bartlett from comment #24)
> (3) Grep'ing the standard RHEL 6 /etc/rc.d/rc.sysinit file shows something
> interesting on line 165 but, once again, I do not think it is relevant.
Nice fin
On Thu, 19 Sep 2013 22:47:01 +0100, Russell King
wrote:
> AMBA Primecell devices always treat streaming and coherent DMA exactly
> the same, so there's no point in having the masks separated.
>
> Signed-off-by: Russell King
for the drivers/of/platform.c portion:
Acked-by: Grant Likely
g.
--
https://bugzilla.kernel.org/show_bug.cgi?id=60758
--- Comment #29 from zakrzews...@wp.pl ---
kernel 3.1.11-2 does not boot too :/
--
You are receiving this mail because:
You are the assignee for the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a me
41 matches
Mail list logo
