All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Reshetova, Elena" <elena.reshetova@intel.com>
To: David Miller <davem@davemloft.net>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
	"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"peterz@infradead.org" <peterz@infradead.org>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"Luck, Tony" <tony.luck@intel.com>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"ishkamiel@gmail.com" <ishkamiel@gmail.com>,
	"keescook@chromium.org" <keescook@chromium.org>,
	"dwindsor@gmail.com" <dwindsor@gmail.com>
Subject: RE: [PATCH 3/4] sparc: convert mdesc_handle.refcnt from atomic_t to refcount_t
Date: Mon, 3 Apr 2017 16:06:44 +0000	[thread overview]
Message-ID: <2236FBA76BA1254E88B949DDB74E612B41C87070@IRSMSX102.ger.corp.intel.com> (raw)
In-Reply-To: <20170403.061252.1545979851987245996.davem@davemloft.net>

> From: "Reshetova, Elena" <elena.reshetova@intel.com>
> Date: Mon, 3 Apr 2017 07:28:01 +0000
> 
> >
> >> From: Elena Reshetova <elena.reshetova@intel.com>
> >> Date: Mon, 20 Feb 2017 13:06:20 +0200
> >>
> >> > refcount_t type and corresponding API should be
> >> > used instead of atomic_t when the variable is used as
> >> > a reference counter. This allows to avoid accidental
> >> > refcounter overflows that might lead to use-after-free
> >> > situations.
> >> >
> >> > Signed-off-by: Elena Reshetova <elena.reshetova@intel.com>
> >> > Signed-off-by: Hans Liljestrand <ishkamiel@gmail.com>
> >> > Signed-off-by: Kees Cook <keescook@chromium.org>
> >> > Signed-off-by: David Windsor <dwindsor@gmail.com>
> >>
> >> Acked-by: David S. Miller <davem@davemloft.net>
> >
> > Hi David,
> >
> > Would you be able to propagate this patch further or should I send
> > it (with your acked-by) once more to specific list/maintainer for
> > the inclusion?
> 
> I'm generally not happy with the refcount_t and the added overhead it
> has compared to the existing atomic_t operations.
> 
> I know it is going to make a difference for networking.
> 
> I understand that this sparc case is a slow path, but I know that if
> we just apply all of these refcount_t conversions, there will be no
> work done to address the performance issues.

I think we will have to address the performance problems in places where we can see it matters. 
The problem is that so far noone told us how to measure in any reasonable way the overhead neither in networking, not in mm changes. 
If this change is a slow path, why would it matter for *this particular patch*?

Best Regards,
Elena.
 
> So I'm reluctant to ACK in any way these refcount_t conversions,
> sorry.

WARNING: multiple messages have this Message-ID (diff)
From: "Reshetova, Elena" <elena.reshetova@intel.com>
To: David Miller <davem@davemloft.net>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
	"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"peterz@infradead.org" <peterz@infradead.org>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"Luck, Tony" <tony.luck@intel.com>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"ishkamiel@gmail.com" <ishkamiel@gmail.com>,
	"keescook@chromium.org" <keescook@chromium.org>,
	"dwindsor@gmail.com" <dwindsor@gmail.com>
Subject: RE: [PATCH 3/4] sparc: convert mdesc_handle.refcnt from atomic_t to refcount_t
Date: Mon, 03 Apr 2017 16:06:44 +0000	[thread overview]
Message-ID: <2236FBA76BA1254E88B949DDB74E612B41C87070@IRSMSX102.ger.corp.intel.com> (raw)
In-Reply-To: <20170403.061252.1545979851987245996.davem@davemloft.net>

> From: "Reshetova, Elena" <elena.reshetova@intel.com>
> Date: Mon, 3 Apr 2017 07:28:01 +0000
> 
> >
> >> From: Elena Reshetova <elena.reshetova@intel.com>
> >> Date: Mon, 20 Feb 2017 13:06:20 +0200
> >>
> >> > refcount_t type and corresponding API should be
> >> > used instead of atomic_t when the variable is used as
> >> > a reference counter. This allows to avoid accidental
> >> > refcounter overflows that might lead to use-after-free
> >> > situations.
> >> >
> >> > Signed-off-by: Elena Reshetova <elena.reshetova@intel.com>
> >> > Signed-off-by: Hans Liljestrand <ishkamiel@gmail.com>
> >> > Signed-off-by: Kees Cook <keescook@chromium.org>
> >> > Signed-off-by: David Windsor <dwindsor@gmail.com>
> >>
> >> Acked-by: David S. Miller <davem@davemloft.net>
> >
> > Hi David,
> >
> > Would you be able to propagate this patch further or should I send
> > it (with your acked-by) once more to specific list/maintainer for
> > the inclusion?
> 
> I'm generally not happy with the refcount_t and the added overhead it
> has compared to the existing atomic_t operations.
> 
> I know it is going to make a difference for networking.
> 
> I understand that this sparc case is a slow path, but I know that if
> we just apply all of these refcount_t conversions, there will be no
> work done to address the performance issues.

I think we will have to address the performance problems in places where we can see it matters. 
The problem is that so far noone told us how to measure in any reasonable way the overhead neither in networking, not in mm changes. 
If this change is a slow path, why would it matter for *this particular patch*?

Best Regards,
Elena.
 
> So I'm reluctant to ACK in any way these refcount_t conversions,
> sorry.

  reply	other threads:[~2017-04-03 16:06 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-20 11:06 [PATCH 0/4] arch subsystem refcounter conversions Elena Reshetova
2017-02-20 11:06 ` Elena Reshetova
2017-02-20 11:06 ` [PATCH 1/4] s390: convert debug_info.ref_count from atomic_t to refcount_t Elena Reshetova
2017-02-20 11:06   ` Elena Reshetova
2017-02-20 13:24   ` Heiko Carstens
2017-02-20 13:24     ` Heiko Carstens
2017-02-20 13:34     ` Heiko Carstens
2017-02-20 13:34       ` Heiko Carstens
2017-02-20 13:35     ` Reshetova, Elena
2017-02-20 13:39     ` Peter Zijlstra
2017-02-20 13:39       ` Peter Zijlstra
2017-02-20 11:06 ` [PATCH 2/4] x86: convert threshold_bank.cpus " Elena Reshetova
2017-02-20 11:06   ` Elena Reshetova
2017-02-20 11:17   ` Borislav Petkov
2017-02-20 11:17     ` Borislav Petkov
2017-02-20 12:20     ` Reshetova, Elena
2017-02-20 12:20       ` Reshetova, Elena
2017-02-20 12:30       ` Borislav Petkov
2017-02-20 12:30         ` Borislav Petkov
2017-02-21 20:45     ` Kees Cook
2017-02-21 20:45       ` Kees Cook
2017-02-22  9:27       ` Borislav Petkov
2017-02-22  9:27         ` Borislav Petkov
2017-02-20 11:06 ` [PATCH 3/4] sparc: convert mdesc_handle.refcnt " Elena Reshetova
2017-02-20 11:06   ` Elena Reshetova
2017-02-20 14:56   ` David Miller
2017-02-20 14:56     ` David Miller
2017-04-03  7:28     ` Reshetova, Elena
2017-04-03  7:28       ` Reshetova, Elena
2017-04-03 13:12       ` David Miller
2017-04-03 13:12         ` David Miller
2017-04-03 16:06         ` Reshetova, Elena [this message]
2017-04-03 16:06           ` Reshetova, Elena
2017-04-03 16:16           ` David Miller
2017-04-03 16:16             ` David Miller
2017-02-20 11:06 ` [PATCH 4/4] kvm: convert kvm.users_count " Elena Reshetova
2017-02-20 11:06   ` Elena Reshetova
2017-02-20 11:37   ` Paolo Bonzini
2017-02-20 11:37     ` Paolo Bonzini
2017-02-20 12:22     ` Reshetova, Elena
2017-02-20 12:22       ` Reshetova, Elena

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=2236FBA76BA1254E88B949DDB74E612B41C87070@IRSMSX102.ger.corp.intel.com \
    --to=elena.reshetova@intel.com \
    --cc=davem@davemloft.net \
    --cc=dwindsor@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpa@zytor.com \
    --cc=ishkamiel@gmail.com \
    --cc=keescook@chromium.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=sparclinux@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=x86@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.