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] [day] [month] [year] [list]
Message-ID: <1301402284.3343.27.camel@BR8HFPP0.boeblingen.de.ibm.com>
Date:	Tue, 29 Mar 2011 14:38:04 +0200
From:	Heinz Graalfs <graalfs@...ux.vnet.ibm.com>
To:	Robert Richter <robert.richter@....com>
Cc:	"mingo@...e.hu" <mingo@...e.hu>,
	"oprofile-list@...ts.sf.net" <oprofile-list@...ts.sf.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
	"borntraeger@...ibm.com" <borntraeger@...ibm.com>,
	"schwidefsky@...ibm.com" <schwidefsky@...ibm.com>,
	"heiko.carstens@...ibm.com" <heiko.carstens@...ibm.com>,
	Mahesh Salgaonkar <mahesh@...ux.vnet.ibm.com>,
	Maran Pakkirisamy <maranp@...ux.vnet.ibm.com>
Subject: Re: [patch v2 1/3] This patch adds support for hardware based
 sampling on System z processors (models z10 and up)

On Fri, 2011-03-25 at 12:00 +0100, Robert Richter wrote: 
> On 21.01.11 05:06:52, Heinz Graalfs wrote:
> > From: Heinz Graalfs <graalfs@...ux.vnet.ibm.com>
> > 
> > System z's hardware sampling is described in detail in:
> > 
> >    SA23-2260-01 "The Load-Program-Parameter and CPU-Measurement Facilities"
> > 
> > The patch introduces
> >  - support for System z's hardware sampler in OProfile's kernel module
> >  - it adds functions that control all hardware sampling related operations as
> >   - checking if hardware sampling feature is available
> >     - ie: on System z models z10 and up, in LPAR mode only, and authorised during LPAR activation
> >   - allocating memory for the hardware sampling feature
> >   - starting/stopping hardware sampling
> > 
> > All functions required to start and stop hardware sampling have to be
> > invoked by the oprofile kernel module as provided by the other patches of this patch set.
> > 
> > In case hardware based sampling cannot be setup standard timer based sampling is used by OProfile.
> > 
> > Signed-off-by: Mahesh Salgaonkar <mahesh@...ux.vnet.ibm.com>
> > Signed-off-by: Maran Pakkirisamy <maranp@...ux.vnet.ibm.com>
> > Signed-off-by: Heinz Graalfs <graalfs@...ux.vnet.ibm.com>
> > ---
> >  arch/Kconfig                   |    3
> >  arch/s390/Kconfig              |    1
> >  arch/s390/oprofile/hwsampler.c | 1256 +++++++++++++++++++++++++++++++++++++++++
> >  arch/s390/oprofile/hwsampler.h |  113 +++
> >  4 files changed, 1373 insertions(+)
> 
> > +int hwsampler_setup()
> > +{
> > +       int rc;
> > +       int cpu;
> > +       struct hws_cpu_buffer *cb;
> > +
> > +       mutex_lock(&hws_sem);
> > +
> > +       rc = -EINVAL;
> > +       if (hws_state)
> > +               goto setup_exit;
> > +
> > +       hws_state = HWS_INIT;
> 
> hws_state is never set to zero again, so we will pass this point only
> one time, even after hwsampler_shutdown(). Is this intended? Only
> loading and unloading this as module would work.
> 
> Maybe we clear hws_state in hwsampler_shutdown()?
> 
> -Robert
> 
yes, the intent is:
hwsampler_setup() is called on module load - oprofile_arch_init()
and 
hwsampler_shutdown() is called on unload - oprofile_arch_exit()

hws_state is reset in hwsampler_shutdown()

hwsampler_shutdown processing only succeeds if we are in states
HWS_DEALLOCATED or HWS_STOPPED.
Usually this is ensured by the current approach the functions are
called, and in this case hws_state is also reset to HWS_INIT.

In case hwsampler_shutdown is called in other 'invalid states' it should
return -EINVAL.
However, in this case, the unregister_cpu_notifier() would be executed,
which is not good and should be avoided.

Although, current processing, never calls hwsampler_shutdown() in
invalid states, I suppose, it might better if we do the unregister call
as intended only if hwsampler_shutdown succeeds.

I will submit a separate patch.

Heinz

> > +
> > +       init_all_cpu_buffers();
> > +
> > +       rc = check_hardware_prerequisites();
> > +       if (rc)
> > +               goto setup_exit;
> > +
> > +       rc = check_qsi_on_setup();
> > +       if (rc)
> > +               goto setup_exit;
> > +
> > +       rc = -EINVAL;
> > +       hws_wq = create_workqueue("hwsampler");
> > +       if (!hws_wq)
> > +               goto setup_exit;
> > +
> > +       register_cpu_notifier(&hws_cpu_notifier);
> > +
> > +       for_each_online_cpu(cpu) {
> > +               cb = &per_cpu(sampler_cpu_buffer, cpu);
> > +               INIT_WORK(&cb->worker, worker);
> > +               rc = smp_ctl_qsi(cpu);
> > +               WARN_ON(rc);
> > +               if (min_sampler_rate != cb->qsi.min_sampl_rate) {
> > +                       if (min_sampler_rate) {
> > +                               printk(KERN_WARNING
> > +                                       "hwsampler: different min sampler rate values.\n");
> > +                               if (min_sampler_rate < cb->qsi.min_sampl_rate)
> > +                                       min_sampler_rate =
> > +                                               cb->qsi.min_sampl_rate;
> > +                       } else
> > +                               min_sampler_rate = cb->qsi.min_sampl_rate;
> > +               }
> > +               if (max_sampler_rate != cb->qsi.max_sampl_rate) {
> > +                       if (max_sampler_rate) {
> > +                               printk(KERN_WARNING
> > +                                       "hwsampler: different max sampler rate values.\n");
> > +                               if (max_sampler_rate > cb->qsi.max_sampl_rate)
> > +                                       max_sampler_rate =
> > +                                               cb->qsi.max_sampl_rate;
> > +                       } else
> > +                               max_sampler_rate = cb->qsi.max_sampl_rate;
> > +               }
> > +       }
> > +       register_external_interrupt(0x1407, hws_ext_handler);
> > +
> > +       hws_state = HWS_DEALLOCATED;
> > +       rc = 0;
> > +
> > +setup_exit:
> > +       mutex_unlock(&hws_sem);
> > +       return rc;
> > +}
> > +
> > +int hwsampler_shutdown()
> > +{
> > +       int rc;
> > +
> > +       mutex_lock(&hws_sem);
> > +
> > +       rc = -EINVAL;
> > +       if (hws_state == HWS_DEALLOCATED || hws_state == HWS_STOPPED) {
> > +               mutex_unlock(&hws_sem);
> > +
> > +               if (hws_wq)
> > +                       flush_workqueue(hws_wq);
> > +
> > +               mutex_lock(&hws_sem);
> > +
> > +               if (hws_state == HWS_STOPPED) {
> > +                       smp_ctl_clear_bit(0, 5); /* set bit 58 CR0 off */
> > +                       deallocate_sdbt();
> > +               }
> > +               if (hws_wq) {
> > +                       destroy_workqueue(hws_wq);
> > +                       hws_wq = NULL;
> > +               }
> > +
> > +               unregister_external_interrupt(0x1407, hws_ext_handler);
> > +               hws_state = HWS_INIT;
> > +               rc = 0;
> > +       }
> > +       mutex_unlock(&hws_sem);
> > +
> > +       unregister_cpu_notifier(&hws_cpu_notifier);
> > +
> > +       return rc;
> > +}
> 



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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ