On Sun, 18 Jan 2004, Matthew Dillon wrote:
Well, this is fun. There are over 460 files in the 5.x source tree
(360 in DFly) that make calls to malloc(... M_NOWAIT), and so far
about 80% of the calls that I've reviewed generate inappropriate
side effects when/if a failure
On Sun, Jan 18, 2004 at 05:44:52PM -0500, Matthew N. Dodd wrote:
On Sun, 18 Jan 2004, Ruslan Ermilov wrote:
But we're missing the proper NULL checking, here's the fix:
...
I've already dealt with this.
Neat, this works much better! Can you please propagate your fix
to
Scott,
Attached is the patch that fixes memory leak according to the below report.
On Fri, Jan 16, 2004 at 04:09:34PM -0800, Paul Twohey wrote:
-
[BUG] though we should demote things that are not locals.
On Sun, Jan 18, 2004 at 02:45:02PM +0200, Ruslan Ermilov wrote:
Scott,
Attached is the patch that fixes memory leak according to the below report.
Attached is the corrected patch that doesn't do a waiting malloc()
while interrupts are blocked. Yes I know that splbio() is a no-op
these days.
On Fri, Jan 16, 2004 at 04:09:34PM -0800, Paul Twohey wrote:
[...]
-
[BUG]
/u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/dpt/dpt_scsi.c:1542:dpt_attach:ERROR:LEAK:1542:1571:
pointer=devq from RO=cam_simq_alloc(-1)
Looks good to me if you want to commit it, thanks!
Scott
Ruslan Ermilov wrote:
On Sun, Jan 18, 2004 at 02:45:02PM +0200, Ruslan Ermilov wrote:
Scott,
Attached is the patch that fixes memory leak according to the below report.
Attached is the corrected patch that doesn't do a waiting malloc()
These cam_sim_alloc() calls seem to be fairly critical to the operation
of DPT and friends, why is it even possible for them to return NULL
in the first place and what would be the effect of a (properly handled)
NULL return if it did occur at this point?
Matthew Dillon wrote:
These cam_sim_alloc() calls seem to be fairly critical to the operation
of DPT and friends, why is it even possible for them to return NULL
in the first place and what would be the effect of a (properly handled)
NULL return if it did occur at this point?
:
:Matthew Dillon wrote:
: These cam_sim_alloc() calls seem to be fairly critical to the operation
: of DPT and friends, why is it even possible for them to return NULL
: in the first place and what would be the effect of a (properly handled)
: NULL return if it did occur at
Matthew Dillon wrote:
:
:Matthew Dillon wrote:
: These cam_sim_alloc() calls seem to be fairly critical to the operation
: of DPT and friends, why is it even possible for them to return NULL
: in the first place and what would be the effect of a (properly handled)
: NULL return
: I know cam uses some helper threads so I am not entirely sure about
: the context the cam_sim_alloc() calls are being made in, but if they
: do not create I/O stalls for already-operational SCSI devices then I
: am inclined (in DFly anyway) to simply make the malloc in
:
Matthew Dillon wrote:
: I know cam uses some helper threads so I am not entirely sure about
: the context the cam_sim_alloc() calls are being made in, but if they
: do not create I/O stalls for already-operational SCSI devices then I
: am inclined (in DFly anyway) to simply make
Well, this is fun. There are over 460 files in the 5.x source tree
(360 in DFly) that make calls to malloc(... M_NOWAIT), and so far
about 80% of the calls that I've reviewed generate inappropriate
side effects when/if a failure occurs. CAM is the biggest violator...
it
On Sun, 18 Jan 2004, Ruslan Ermilov wrote:
But we're missing the proper NULL checking, here's the fix:
...
I've already dealt with this.
--
10 40 80 C0 00 FF FF FF FF C0 00 00 00 00 10 AA AA 03 00 00 00 08 00
___
[EMAIL PROTECTED] mailing list
:M_NOWAIT is being used pretty much as if it were M_WAITOK|M_USE_RESERVE
:most of the time, especially considering the side effect situation when
:such allocations fail. I don't think M_WAITOK|M_USE_RESERVE would be
:any less reliable, actually. It looks like the whole paradigm
More research... correct me if I am wrong but it appears that the 5.x
kmem_malloc() code may have some issues. If you look down at around line
349 there is a comment:
/*
* Note: if M_NOWAIT specified alone, allocate from
* interrupt-safe queues only (just
In message: [EMAIL PROTECTED]
Paul Twohey [EMAIL PROTECTED] writes:
: Hi,
:
: I'm with the Stanford Metacompilation research group. We have a suite of
: checkers that find bugs at compile time and we've had quite a bit of
: success checking the Linux kernel code for errors. Since our
Hi,
I'm with the Stanford Metacompilation research group. We have a suite of
checkers that find bugs at compile time and we've had quite a bit of
success checking the Linux kernel code for errors. Since our checkers can
emit false alarms we filter the reports before we give them to the kernel
Hi,
I'm with the Stanford Metacompilation research group. We have a suite of
checkers that find bugs at compile time and we've had quite a bit of
success checking the Linux kernel code for errors. Since our checkers can
emit false alarms we filter the reports before we give them to the kernel
, 2004 8:01 AM
Subject: [CHECKER] bugs in FreeBSD
Hi,
I'm with the Stanford Metacompilation research group. We have a suite of
checkers that find bugs at compile time and we've had quite a bit of
success checking the Linux kernel code for errors. Since our checkers can
emit false alarms we
Subject: [CHECKER] bugs in FreeBSD
Hi,
I'm with the Stanford Metacompilation research group. We have a suite of
checkers that find bugs at compile time and we've had quite a bit of
success checking the Linux kernel code for errors. Since our checkers can
emit false alarms we filter
21 matches
Mail list logo
