public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Veaceslav Falico <vfalico@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Yinghai Lu" <yinghai@kernel.org>,
	"Knut Petersen" <Knut_Petersen@t-online.de>,
	"Ingo Molnar" <mingo@kernel.org>,
	"Paul McKenney" <paulmck@linux.vnet.ibm.com>,
	"Frédéric Weisbecker" <fweisbec@gmail.com>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Neil Horman" <nhorman@tuxdriver.com>
Subject: Re: [PATCH v3 1/3] msi: free msi_desc entry only after we've released the kobject
Date: Tue, 29 Oct 2013 17:47:20 +0100	[thread overview]
Message-ID: <20131029164720.GO692@redhat.com> (raw)
In-Reply-To: <CA+55aFxt9KnmZnK5QdkPcpHNR+Ath5WTzhRibu5Y=xOhiz3fzA@mail.gmail.com>

On Tue, Oct 29, 2013 at 09:34:28AM -0700, Linus Torvalds wrote:
>On Tue, Oct 29, 2013 at 3:30 AM, Veaceslav Falico <vfalico@redhat.com> wrote:
>>                 /*
>>                  * Its possible that we get into this path
>>                  * When populate_msi_sysfs fails, which means the entries
>>                  * were not registered with sysfs.  In that case don't
>> -                * unregister them.
>> +                * unregister them, and just free. Otherwise the
>> +                * kobject->release will take care of freeing the entry via
>> +                * msi_kobj_release().
>>                  */
>>                 if (entry->kobj.parent) {
>>                         kobject_del(&entry->kobj);
>>                         kobject_put(&entry->kobj);
>> +               } else {
>> +                       kfree(entry);
>>                 }
>> -
>> -               list_del(&entry->list);
>> -               kfree(entry);
>
>So this code sequence still makes me very unhappy.
>
>Why does not just a simple unconditional
>
>        kobject_del(&entry->kobj);
>        kobject_put(&entry->kobj);
>
>work for the "not registered with sysfs" case? And if the sysfs code
>really gets confused, why not
>
>        if (entry->kobj.parent)
>                kobject_del(&entry->kobj);
>        kobject_put(&entry->kobj);

It was fixed this way in 424eb39 ("PCI: msi: fix imbalanced refcount of msi
irq sysfs objects"). kobject_put() still failed in case it wasn't
registered with sysfs earlier. populate_msi_sysfs() creates an kobject for
each entry in msi_list, and we have no idea (on fallback) up to which entry
was it already registered, on which it failed and which entries are still
not kobject_init_and_add()ed.

>
>(btw, looking at the sysfs code, this looks *very* suspicious in
>sysfs_remove_dir():
>
>        struct sysfs_dirent *sd = kobj->sd;
>
>        spin_lock(&sysfs_assoc_lock);
>        kobj->sd = NULL;
>        spin_unlock(&sysfs_assoc_lock);
>
>and I would suggest that "sd = kobj->sd" should be done under the
>lock, because otherwise the lock is kind of pointless..)
>
>Greg?
>
>                Linus

  reply	other threads:[~2013-10-29 16:50 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1383042632-7102-1-git-send-email-vfalico@redhat.com>
2013-10-29 10:30 ` [PATCH v3 1/3] msi: free msi_desc entry only after we've released the kobject Veaceslav Falico
2013-10-29 11:32   ` Neil Horman
2013-10-29 16:34   ` Linus Torvalds
2013-10-29 16:47     ` Veaceslav Falico [this message]
2013-10-29 21:49     ` Greg Kroah-Hartman
2013-11-25 23:12   ` Bjorn Helgaas
2013-11-25 23:29     ` Greg Kroah-Hartman
2013-11-26 12:47       ` Neil Horman
2013-10-29 10:30 ` [PATCH v3 2/3] pci: remove redundant pci_dev_get/put() on kobject (un)register Veaceslav Falico
2013-10-29 11:34   ` Neil Horman
2013-10-29 10:30 ` [PATCH v3 3/3] msi: always unregister ->msi_kset within free_msi_irqs() Veaceslav Falico
2013-10-29 11:45   ` Neil Horman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131029164720.GO692@redhat.com \
    --to=vfalico@redhat.com \
    --cc=Knut_Petersen@t-online.de \
    --cc=bhelgaas@google.com \
    --cc=fweisbec@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=nhorman@tuxdriver.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=yinghai@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox