From: Quinn Tran
In the case of IOCB QFull, Initiator code can leave behind
a stale pointer to an SRB structure on the outstanding command
array.
Fixes: 82de802ad46e ("scsi: qla2xxx: Preparation for Target MQ.")
Cc: sta...@vger.kernel.org #4.16
Signed-off-by: Quinn Tran
Signed-off-by: Himanshu
Hi,
On Thu, Jul 26, 2018 at 05:05:37PM +0200, Johannes Thumshirn wrote:
> On Thu, Jul 26, 2018 at 04:25:24PM +0200, ard wrote:
> > The system itself is an exynos 5422 arm. It worked perfectly fine
> > with 3.10 as an Initiator, now it leaks memory the moment I
> > enable the FCoE vlan on the
On Thu, 2018-07-26 at 07:14 -0700, t...@kernel.org wrote:
> Hello,
>
> On Thu, Jul 26, 2018 at 02:09:41PM +, Bart Van Assche wrote:
> > On Thu, 2018-07-26 at 06:35 -0700, Tejun Heo wrote:
> > > Making removal asynchronous this way sometimes causes issues because
> > > whether the user sees
Tell snprintf() to store at most 255 characters in the output buffer
instead of 256. This patch avoids that smatch reports the following
warning:
drivers/scsi/qedi/qedi_main.c:891: qedi_get_boot_tgt_info() error: snprintf()
is printing too much 256 vs 255
Signed-off-by: Bart Van Assche
Cc:
I would like to contact the person that manages your images for your
company?
We provide different services that makes your images and pictures to look
good. For the images to
be more attractive, we services such as background image cut out, clipping
path, shadow adding
(drop shadow, reflection
On Thu, Jul 26, 2018 at 04:25:24PM +0200, ard wrote:
> The system itself is an exynos 5422 arm. It worked perfectly fine
> with 3.10 as an Initiator, now it leaks memory the moment I
> enable the FCoE vlan on the port.
So I had a look through the commits between v3.10 and v4.14 and this
one
On Thu, Jul 26, 2018 at 04:25:24PM +0200, ard wrote:
> > Anyways, can you please enable the kernel memory leak detector [1] and
> > possibly even try a more up to date (like v4.18-rc6) kernel?
> >
> > [1] https://www.kernel.org/doc/html/v4.17/dev-tools/kmemleak.html
>
> The up to date kernel
Hi,
On Thu, Jul 26, 2018 at 03:36:22PM +0200, Johannes Thumshirn wrote:
> On Thu, Jul 26, 2018 at 03:02:14PM +0200, ard wrote:
> > Hi Guys,
> >
> > I sent this to fcoe-devel but it might be holiday season or the
> > mailing list is abandoned as the emails concerning fcoe are
> > pretty low.
>
>
Hello,
On Thu, Jul 26, 2018 at 02:09:41PM +, Bart Van Assche wrote:
> On Thu, 2018-07-26 at 06:35 -0700, Tejun Heo wrote:
> > Making removal asynchronous this way sometimes causes issues because
> > whether the user sees the device released or not is racy.
> > kernfs/sysfs have mechanisms to
On Thu, 2018-07-26 at 06:35 -0700, Tejun Heo wrote:
> Making removal asynchronous this way sometimes causes issues because
> whether the user sees the device released or not is racy.
> kernfs/sysfs have mechanisms to deal with these cases - remove_self
> and kernfs_break_active_protection(). Have
On Thu, Jul 26, 2018 at 2:25 PM, Sreekanth Reddy
wrote:
> On Wed, Jul 25, 2018 at 8:32 PM, Andy Shevchenko
> wrote:
>> On Wed, Jul 25, 2018 at 12:42 PM, Sreekanth Reddy
>> wrote:
>>> Swap the I/O memory read value back to cpu endianness before storing it
>>> in a data structures which are
On Thu, Jul 26, 2018 at 03:02:14PM +0200, ard wrote:
> Hi Guys,
>
> I sent this to fcoe-devel but it might be holiday season or the
> mailing list is abandoned as the emails concerning fcoe are
> pretty low.
Yes, the list is defunct as I didn't get admin privileges passed by
the old Maintainer
Hello,
ISTR giving the same feedback before.
On Wed, Jul 25, 2018 at 10:38:28AM -0700, Bart Van Assche wrote:
> +struct remove_dev_work {
> + struct callback_headhead;
> + struct scsi_device *sdev;
> +};
> +
> +static void delete_sdev(struct callback_head *head)
> +{
> +
Hi Guys,
I sent this to fcoe-devel but it might be holiday season or the
mailing list is abandoned as the emails concerning fcoe are
pretty low.
On Mon, Jul 23, 2018 at 02:16:31PM +0200, ard wrote:
Date: Mon, 23 Jul 2018 14:16:31 +0200
From: ard
Subject: FCOE vn2vn memory leaks in 4.14
To:
Bart Van Assche 于2018年7月25日周三 下午7:39写道：
>
> This patch avoids that self-removal triggers the following deadlock:
>
> ==
> WARNING: possible circular locking dependency detected
> 4.18.0-rc2-dbg+ #5 Not tainted
>
>From my limited insight into this:
Looks good,
Reviewed-by: Johannes Thumshirn
--
Johannes Thumshirn Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane
On Tue, Jul 24, 2018 at 10:37 AM, Sreekanth Reddy
wrote:
> Any update on this patch!.
Just Ping once again. Any update on this patch.
> Thanks,
> Sreekanth
>
> On Fri, Jul 20, 2018 at 5:56 PM, Sreekanth Reddy
> wrote:
>> In mpt3sas_base_clear_st() function smid value is reseted in wrong line,
On Wed, Jul 25, 2018 at 8:32 PM, Andy Shevchenko
wrote:
> On Wed, Jul 25, 2018 at 12:42 PM, Sreekanth Reddy
> wrote:
>> Swap the I/O memory read value back to cpu endianness before storing it
>> in a data structures which are defined in the MPI headers where
>> u8 components are not defined in
18 matches
Mail list logo
