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]
Date:   Fri, 8 Jun 2018 12:35:51 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>, x86@...nel.org,
        platform-driver-x86@...r.kernel.org
Cc:     sean.j.christopherson@...el.com, nhorman@...hat.com,
        npmccallum@...hat.com, Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Darren Hart <dvhart@...radead.org>,
        Andy Shevchenko <andy@...radead.org>,
        "open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)" 
        <linux-kernel@...r.kernel.org>,
        "open list:INTEL SGX" <intel-sgx-kernel-dev@...ts.01.org>
Subject: Re: [PATCH v11 10/13] intel_sgx: driver for Intel Software Guard
 Extensions

> +#define sgx_pr_ratelimited(level, encl, fmt, ...)			\
> +	pr_ ## level ## _ratelimited("[%d:0x%p] " fmt,			\
> +				     pid_nr((encl)->tgid),		\
> +				     (void *)(encl)->base, ##__VA_ARGS__)
> +
> +#define sgx_dbg(encl, fmt, ...) \
> +	sgx_pr_ratelimited(debug, encl, fmt, ##__VA_ARGS__)
> +#define sgx_info(encl, fmt, ...) \
> +	sgx_pr_ratelimited(info, encl, fmt, ##__VA_ARGS__)
> +#define sgx_warn(encl, fmt, ...) \
> +	sgx_pr_ratelimited(warn, encl, fmt, ##__VA_ARGS__)
> +#define sgx_err(encl, fmt, ...) \
> +	sgx_pr_ratelimited(err, encl, fmt, ##__VA_ARGS__)
> +#define sgx_crit(encl, fmt, ...) \
> +	sgx_pr_ratelimited(crit, encl, fmt, ##__VA_ARGS__)

I thought the pr_* thingies were to keep everyone from having to do this
in each driver.  Why did you need this?

Can you do any better than a 2,000-line patch?  For instance, could you
break out the memory management portion into its own part and have that
reviewed by mm folks?  Or the ioctl()'s by device driver folks?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ