linux-kernel - Re: [RFC PATCH 3/7] drivers/zio: core files for the ZIO input/output

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAH5GJ0rwJj9m7Hx1o_1N-Hb7CmDU9hRfp3oPXET9ecD4+TQDYA@mail.gmail.com>
Date:	Mon, 28 Nov 2011 15:59:41 +0100
From:	Federico Vaga <federico.vaga@...il.com>
To:	Greg KH <greg@...ah.com>
Cc:	Alessandro Rubini <rubini@...dd.com>, linux-iio@...r.kernel.org,
	linux-kernel@...r.kernel.org, dcobas@...n.ch, siglesia@...n.ch,
	manohar.vanga@...n.ch
Subject: Re: [RFC PATCH 3/7] drivers/zio: core files for the ZIO input/output

2011/11/27 Greg KH <greg@...ah.com>:
> On Sat, Nov 26, 2011 at 11:58:41PM +0100, Federico Vaga wrote:
>> In data sabato 26 novembre 2011 12:03:41, Greg KH ha scritto:
>> > On Sat, Nov 26, 2011 at 06:30:42PM +0100, Alessandro Rubini wrote:
>> > > +static struct kobj_type zdktype = { /* For standard and extended
>> > > attribute */ +    .release   = NULL,
>> >
>> > Sweet!
>> >
>> > As-per the in-kernel documentation, I now get to mock you for doing
>> > this :)
>> >
>> > Please NEVER DO THIS, you are ignoring the messages that the kernel
>> > sends you when you remove one of these devices, and causing a memory
>> > leak.
>>
>> Honestly we never see any messages about this.
>
> Really?  Then you never removed that kobject from memory.  Please go
> read the kobject documentation for more details.

Yes. All the kobjects are correctly removed and no memory leak was found.

I took a look into kobject.c and I found (I suppose) the message but
it is a pr_debug(); if it is so important we can think to "promote" it
to pr_warning()

>> > Not nice at all, yet another reason to use a 'struct device'.
>>
>> I don't think is a valid reason, because device_release implementation require
>> us to implement a release method within device, or device_type or class; so we
>> can use kobj_type as well.
>
> True, but it tries to make things easier to not get wrong, like you are
> here.
>
> Please fix this.

I'll fix it

> greg k-h
>



-- 
Federico Vaga
--
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/