linux-kernel - Re: [RFC PATCH] scsi, block: fix duplicate bdi name registration crashes

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: <CAPcyv4j2zm93jp6j7__xhSTXWKnh2MdEr5BxJ_ycku77xdtrTQ@mail.gmail.com>
Date:   Mon, 30 Jan 2017 12:57:05 -0800
From:   Dan Williams <dan.j.williams@...el.com>
To:     Christoph Hellwig <hch@....de>
Cc:     "Martin K. Petersen" <martin.petersen@...cle.com>,
        Jens Axboe <axboe@...nel.dk>, linux-block@...r.kernel.org,
        linux-scsi <linux-scsi@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        James Bottomley <James.Bottomley@...senpartnership.com>,
        Bart Van Assche <bart.vanassche@...disk.com>,
        Omar Sandoval <osandov@...ndov.com>
Subject: Re: [RFC PATCH] scsi, block: fix duplicate bdi name registration crashes

On Mon, Jan 30, 2017 at 4:24 AM, Christoph Hellwig <hch@....de> wrote:
> Hi Dan,
>
> this looks mostly fine to me.  A few code comments below, but except
> for this there is another issue with it:  We still have drivers
> that share a single request_queue for multiple gendisks, so I wonder
>
> Also I think you probably want one patch for the block framework,
> and one to switch SCSI over to it.
>
>> +struct disk_devt {
>> +     struct kref kref;
>> +     void (*release)(struct kref *);
>> +};
>> +
>> +static inline void put_disk_devt(struct disk_devt *disk_devt)
>> +{
>> +     if (disk_devt)
>> +             kref_put(&disk_devt->kref, disk_devt->release);
>> +}
>> +
>> +static inline void get_disk_devt(struct disk_devt *disk_devt)
>> +{
>> +     if (disk_devt)
>> +             kref_get(&disk_devt->kref);
>> +}
>
> Given that we have a user-supplied release callack I'd much rather get
> rid of the kref here, use a normal atomic_t and pass the disk_devt
> structure to the release callback then a kref.

I'm missing something... kref is just:

struct kref {
        atomic_t refcount;
};

...so what do we gain by open coding kref_get() and kref_put()?