[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e2e108260802120805v4c8e07d6if59c881213c4ae97@mail.gmail.com>
Date: Tue, 12 Feb 2008 17:05:20 +0100
From: "Bart Van Assche" <bart.vanassche@...il.com>
To: "Nicholas A. Bellinger" <nab@...ux-iscsi.org>
Cc: "Vladislav Bolkhovitin" <vst@...b.net>,
"FUJITA Tomonori" <fujita.tomonori@....ntt.co.jp>,
"Mike Christie" <michaelc@...wisc.edu>, linux-scsi@...r.kernel.org,
"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
"James Bottomley" <James.Bottomley@...senpartnership.com>,
scst-devel@...ts.sourceforge.net,
"Andrew Morton" <akpm@...ux-foundation.org>
Subject: Re: [Scst-devel] Integration of SCST in the mainstream Linux kernel
On Feb 6, 2008 1:11 AM, Nicholas A. Bellinger <nab@...ux-iscsi.org> wrote:
> I have always observed the case with LIO SE/iSCSI target mode ...
Hello Nicholas,
Are you sure that the LIO-SE kernel module source code is ready for
inclusion in the mainstream Linux kernel ? As you know I tried to test
the LIO-SE iSCSI target. Already while configuring the target I
encountered a kernel crash that froze the whole system. I can
reproduce this kernel crash easily, and I reported it 11 days ago on
the LIO-SE mailing list (February 4, 2008). One of the call stacks I
posted shows a crash in mempool_alloc() called from jbd. Or: the crash
is most likely the result of memory corruption caused by LIO-SE.
Because I was curious to know why it took so long to fix such a severe
crash, I started browsing through the LIO-SE source code. Analysis of
the LIO-SE kernel module source code learned me that this crash is not
a coincidence. Dynamic memory allocation (kmalloc()/kfree()) in the
LIO-SE kernel module is complex and hard to verify. There are 412
memory allocation/deallocation calls in the current version of the
LIO-SE kernel module source code, which is a lot. Additionally,
because of the complexity of the memory handling in LIO-SE, it is not
possible to verify the correctness of the memory handling by analyzing
a single function at a time. In my opinion this makes the LIO-SE
source code hard to maintain.
Furthermore, the LIO-SE kernel module source code does not follow
conventions that have proven their value in the past like grouping all
error handling at the end of a function. As could be expected, the
consequence is that error handling is not correct in several
functions, resulting in memory leaks in case of an error. Some
examples of functions in which error handling is clearly incorrect:
* transport_allocate_passthrough().
* iscsi_do_build_list().
Bart Van Assche.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists