xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Cc: "'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 3/3] Xen physical cpus interface
Date: Fri, 11 May 2012 15:00:41 -0400	[thread overview]
Message-ID: <20120511190041.GA3785@phenom.dumpdata.com> (raw)
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923351BC88D@SHSMSX101.ccr.corp.intel.com>

On Fri, May 11, 2012 at 06:04:21PM +0000, Liu, Jinsong wrote:
> Konrad Rzeszutek Wilk wrote:
> > On Fri, May 11, 2012 at 01:12:13PM +0000, Liu, Jinsong wrote:
> >> Liu, Jinsong wrote:
> >>> Just notice your reply (so quick :)
> >>> 
> >>> Agree and will update later, except 1 concern below.
> >>> 
> >>> Konrad Rzeszutek Wilk wrote:
> >>>>> 
> >>>>> Hmm, it's good if it's convenient to do it automatically via
> >>>>> dev->release. However, dev container (pcpu) would be free at some
> >>>>> other error cases, so I prefer do it 'manually'.
> >>>> 
> >>>> You could also call pcpu_release(..) to do it manually.
> >>>> 
> >>> 
> >>> that means kfree(pcpu) would be done twice at some error cases, do
> >>> you think it really good? 
> >>> 
> >> 
> >> Ping.
> >> 
> >> I think error recovery should be kept inside error logic level
> >> itself, if try to recover upper level error would bring trouble. 
> >> 
> >> In our example, there are 2 logic levels:
> >> pcpu level (as container), and dev level (subfield used for sys)
> > 
> > So you need to untangle free_pcpu from doing both. Meaning one does
> > the SysFS and the other deals with free-ing the structure and
> > removing itself from the list.
> > 
> 
> free_cpu is very samll, just consist of the 2 parts your said:
> * pcpu_sys_remove() deal with sysfs
> * list_del/kfree(pcpu) deal with pcpu
> 
> > 
> >> dev->release should only recover error occurred at dev/sys level,
> >> and the pcpu error should be recovered at pcpu level. 
> >> 
> >> If dev->release try to recover its container pcpu level error, like
> >> list_del/kfree(pcpu), it would make confusing. i.e., considering
> >> pcpu_sys_create(), 2 error cases: device_register fail, and
> >> device_create_file fail --> how can the caller decide kfree(pcpu) or
> >> not?   
> > 
> > Then you should free it manually. But you can do this by a wrapper
> > function:
> > 
> > __pcpu_release(..) {
> > 	..
> > 	/* Does the removing itself from the list and kfree the pcpu */
> > }
> > pcpu_release(..) {
> > 	struct pcpcu *p= container_of(..)
> > 	__pcpu_release(p);
> > }
> > 
> > dev->release = &pcpu_release;
> > 
> 
> Too weird way. If we want to release dev itself it's good to use dev->release, but for pcpu I doubt it.
> (consider the example I gave --> why we create issue (it maybe solved in weird method I agree), just for using dev->release?)
> 
> In kernel many dev->release keep NULL.
> An example of using dev->release is cpu/mcheck/mce.c --> mce_device_release(), it *just* deal dev itself.

OK? I am not sure what are we arguing here anymore?
I think using 'kfree(pcpu)' on the error paths (as long as it is
done before device_register) is OK. I think that seperating
the SysFS deletion from the pcpu deletion should be done to
avoid races. Perhaps the SysFS deletion function should also
remove the pcpu from the list.

  reply	other threads:[~2012-05-11 19:00 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-19 13:33 [PATCH 3/3] Xen physical cpus interface Liu, Jinsong
2012-04-20 19:24 ` Konrad Rzeszutek Wilk
2012-05-10 14:54   ` Liu, Jinsong
2012-05-10 14:57     ` Konrad Rzeszutek Wilk
2012-05-10 15:20       ` Liu, Jinsong
     [not found]       ` <DE8DF0795D48FD4CA783C40EC82923351B5A2E@SHSMSX101.ccr.corp.intel.com>
2012-05-11 13:12         ` Liu, Jinsong
2012-05-11 14:27           ` Konrad Rzeszutek Wilk
2012-05-11 18:04             ` Liu, Jinsong
2012-05-11 19:00               ` Konrad Rzeszutek Wilk [this message]
2012-05-11 20:31                 ` [Xen-devel] " Liu, Jinsong
2012-05-11 20:48                   ` Konrad Rzeszutek Wilk

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=20120511190041.GA3785@phenom.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=jinsong.liu@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xen-devel@lists.xensource.com \
    /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;
as well as URLs for NNTP newsgroup(s).