linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: Fenghua Yu <fenghua.yu@intel.com>, Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>, H Peter Anvin <hpa@zytor.com>,
	Ashok Raj <ashok.raj@intel.com>, Alan Cox <alan@linux.intel.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Rafael Wysocki <rafael.j.wysocki@intel.com>,
	Tony Luck <tony.luck@intel.com>,
	Ravi V Shankar <ravi.v.shankar@intel.com>,
	linux-kernel <linux-kernel@vger.kernel.org>, x86 <x86@kernel.org>
Subject: Re: [PATCH v2 2/4] x86/split_lock: Align x86_capability to unsigned long to avoid split locked access
Date: Fri, 29 Jun 2018 13:48:45 -0700	[thread overview]
Message-ID: <8fdfb671-f223-163b-12cd-3c97d94f91b4@intel.com> (raw)
In-Reply-To: <20180629203844.GA68178@romley-ivt3.sc.intel.com>

On 06/29/2018 01:38 PM, Fenghua Yu wrote:
> How to handle data that is used in generic code which can be used on
> non-Intel platform? For exmple, if I do this change for struct efi in
> include/linux/efi.h because set_bit() sets bits in efi.flags:
> -       unsigned long flags;
> +       unsigned long flags __aligned(unsigned long);
>  } efi;
> 
> People may argue that the alignment unnecessarily increases size of 'efi'
> on non-Intel platform which doesn't have split lock issue. Do we care this
> argument?

Unaligned memory accesses are bad, pretty much universally.  This is a
general good practice that we should have been doing anyway.  Let folks
complain.  Don't let it stop you.

Also, look at the size of that structure.  Look at how many pointers it
has.  Do you think *anyone* is going to complain about an extra 4 bytes
in a 400-byte structure?

> Another question, there will be a bunch of one-line changes for
> the alignment (i.e. adding __aligned(unsigned long)) in various files.
> Will the changes be put in one big patch or in separate one-liner patches?

Just group them logically.

  reply	other threads:[~2018-06-29 20:48 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-29 14:33 [PATCH v2 0/4] x86/split_lock: Enable #AC exception for split locked accesses Fenghua Yu
2018-06-29 14:33 ` [PATCH v2 1/4] x86/split_lock: Enumerate #AC exception for split locked access feature Fenghua Yu
2018-06-29 14:56   ` Dave Hansen
2018-06-29 16:23     ` Thomas Gleixner
2018-06-29 16:32       ` Dave Hansen
2018-07-04 20:07       ` Eduardo Habkost
2018-07-10 18:45         ` Fenghua Yu
2018-07-10 18:54           ` Dave Hansen
2018-07-10 19:47             ` Thomas Gleixner
2018-07-11 19:59               ` Dave Hansen
2018-07-12 20:00                 ` Thomas Gleixner
2018-06-29 14:33 ` [PATCH v2 2/4] x86/split_lock: Align x86_capability to unsigned long to avoid split locked access Fenghua Yu
2018-06-29 16:04   ` Dave Hansen
2018-06-29 16:35     ` Thomas Gleixner
2018-06-29 19:03       ` Fenghua Yu
2018-06-29 20:08         ` Thomas Gleixner
2018-06-29 20:38           ` Fenghua Yu
2018-06-29 20:48             ` Dave Hansen [this message]
2018-06-29 21:10               ` Fenghua Yu
2018-06-29 21:44               ` Thomas Gleixner
2018-06-30  0:00                 ` Fenghua Yu
2018-06-30  0:14                   ` Fenghua Yu
2018-06-30  6:23                     ` Thomas Gleixner
2018-07-02 12:18             ` Peter Zijlstra
2018-07-02 14:11               ` Fenghua Yu
2018-06-29 14:33 ` [PATCH v2 3/4] x86/split_lock: Handle #AC exception for split lock Fenghua Yu
2018-06-29 16:29   ` Dave Hansen
2018-06-29 16:33     ` Luck, Tony
2018-06-29 17:16       ` Fenghua Yu
2018-06-29 17:29         ` Dave Hansen
2018-06-29 17:39           ` Fenghua Yu
2018-06-29 17:47             ` Dave Hansen
2018-06-29 14:33 ` [PATCH v2 4/4] x86/split_lock: Disable #AC for split locked accesses Fenghua Yu
2018-06-29 16:31   ` Dave Hansen

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=8fdfb671-f223-163b-12cd-3c97d94f91b4@intel.com \
    --to=dave.hansen@intel.com \
    --cc=alan@linux.intel.com \
    --cc=ashok.raj@intel.com \
    --cc=fenghua.yu@intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=ravi.v.shankar@intel.com \
    --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 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).