Add a short member for proper alignment and one will probably pop out.
Sent from my tablet, pardon any formatting problems.
> On Sep 8, 2014, at 19:56, James Bottomley
> wrote:
>
>> On Mon, 2014-09-08 at 19:30 -0400, Peter Hurley wrote:
>> On 09/08/2014 01:50 AM, James Bottomley wrote:
Tw
On 09/08/2014 07:56 PM, James Bottomley wrote:
>>
>> Yeah, the extra requirement I added is basically nonsense, since the
>> only issue is what instructions the compiler is emitting. So if compiler
>> thinks the alignment is natural and combines the writes -- ok. If the
>> compiler thinks the align
On Mon, 2014-09-08 at 19:30 -0400, Peter Hurley wrote:
> On 09/08/2014 01:50 AM, James Bottomley wrote:
> >> Two things: I think that gcc has given up on combining adjacent writes,
> >> perhaps because unaligned writes on some arches are prohibitive, so
> >> whatever minor optimization was believed
On 09/08/2014 03:39 PM, James Bottomley wrote:
>
> I don't understand what you mean by "pass each other". Atomicity
> guarantees are not ordering guarantees in a SMP environment. The
> guarantee is that if you follow the rules when two CPUs update the same
> natural width aligned object simultan
On 09/08/2014 03:43 PM, James Bottomley wrote:
>
> This was years ago (possibly decades). We had to implement in-kernel
> unaligned traps for the networking layer because it could access short
> and int fields that weren't of the correct alignment when processing
> packets. It that's all correct
On 2014/9/5 22:29, David Vrabel wrote:
> On 05/09/14 11:09, Yijing Wang wrote:
>> Use MSI chip framework instead of arch MSI functions to configure
>> MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
> [...]
>> --- a/arch/x86/pci/xen.c
>> +++ b/arch/x86/pci/xen.c
> [...]
>> @@
On Mon, Sep 08, 2014 at 06:47:35PM -0400, Peter Hurley wrote:
> On 09/08/2014 01:59 PM, H. Peter Anvin wrote:
> > On 09/08/2014 10:52 AM, One Thousand Gnomes wrote:
> >> On Fri, 05 Sep 2014 08:41:52 -0700
> >> "H. Peter Anvin" wrote:
> >>
> >>> On 09/05/2014 08:31 AM, Peter Hurley wrote:
>
>
Michael Ellerman writes:
> The encoding of the lengths in the ibm_architecture_vec array is
> "interesting" to say the least. It's non-obvious how the number of bytes
> we provide relates to the length value.
>
> In fact we already got it wrong once, see 11e9ed43ca8a "Fix up
> ibm_architecture_vec
On Fri, 2014-09-05 at 15:27 -0600, Bjorn Helgaas wrote:
> On Fri, Sep 5, 2014 at 3:25 PM, Bjorn Helgaas wrote:
> > On Sat, Jul 12, 2014 at 01:21:06PM +0200, Alexander Gordeev wrote:
> >> Hello,
> >>
> >> This is a cleanup effort to get rid of useless arch_msi_check_device().
> >> I am not sure wha
On Friday, September 05, 2014 01:11:22 PM Viresh Kumar wrote:
> On 5 September 2014 13:09, Preeti U Murthy wrote:
> > Today cpus go to winkle when they are offlined. Since it is the deepest
> > idle state that we have, it is expected to save good amount of power as
> > compared
> > to online stat
On 09/08/2014 01:50 AM, James Bottomley wrote:
> On Sun, 2014-09-07 at 16:41 -0400, Peter Hurley wrote:
>> On 09/07/2014 03:04 PM, James Bottomley wrote:
>>> On Sun, 2014-09-07 at 09:21 -0700, Paul E. McKenney wrote:
On Sat, Sep 06, 2014 at 10:07:22PM -0700, James Bottomley wrote:
> On Thu
On 09/08/2014 01:59 PM, H. Peter Anvin wrote:
> On 09/08/2014 10:52 AM, One Thousand Gnomes wrote:
>> On Fri, 05 Sep 2014 08:41:52 -0700
>> "H. Peter Anvin" wrote:
>>
>>> On 09/05/2014 08:31 AM, Peter Hurley wrote:
Which is a bit ironic because I remember when Digital had a team
wor
On Mon, 2014-09-08 at 16:45 -0400, Chris Metcalf wrote:
> On 9/8/2014 1:50 AM, James Bottomley wrote:
> > Actual alignment is pretty irrelevant. That's why all architectures
> > which require alignment also have to implement misaligned traps ... this
> > is a fundamental requirement of the network
On Mon, 2014-09-08 at 12:12 -0700, H. Peter Anvin wrote:
> On 09/08/2014 12:09 PM, James Bottomley wrote:
> >
> > Um, I think you need to re-read the thread; that's not what I said at
> > all. It's even written lower down: "PA can't do atomic bit sets (no
> > atomic RMW except the ldcw operation)
On 9/8/2014 1:50 AM, James Bottomley wrote:
Actual alignment is pretty irrelevant. That's why all architectures
which require alignment also have to implement misaligned traps ... this
is a fundamental requirement of the networking code, for instance.
Can you clarify what you think the require
Currently in the event of a stack overrun a call to schedule()
does not check for this type of corruption. This corruption is
often silent and can go unnoticed. However once the corrupted
region is examined at a later stage, the outcome is undefined
and often results in a sporadic page fault which
Currently in the event of a stack overrun a call to schedule()
does not check for this type of corruption. This corruption is
often silent and can go unnoticed. However once the corrupted
region is examined at a later stage, the outcome is undefined
and often results in a sporadic page fault which
This facility is used in a few places so let's introduce
a helper function to improve code readability.
Signed-off-by: Aaron Tomlin
---
arch/powerpc/mm/fault.c| 4 +---
arch/x86/mm/fault.c| 4 +---
include/linux/sched.h | 2 ++
kernel/trace/trace_stack.c | 2 +-
4 files changed,
Tasks get their end of stack set to STACK_END_MAGIC with the
aim to catch stack overruns. Currently this feature does not
apply to init_task. This patch removes this restriction.
Note that a similar patch was posted by Prarit Bhargava [1]
some time ago but was never merged.
[1]: http://marc.info/
On 09/08/2014 12:09 PM, James Bottomley wrote:
>
> Um, I think you need to re-read the thread; that's not what I said at
> all. It's even written lower down: "PA can't do atomic bit sets (no
> atomic RMW except the ldcw operation) it can do atomic writes to
> fundamental sizes (byte, short, int, l
> > I think the whole "removing Alpha EV5" support is basically bonkers. Just
> > use set_bit in the tty layer. Alpha will continue to work as well as it
> > always has done and you won't design out support for any future processor
> > that turns out not to do byte aligned stores.
> >
> > Alan
> >
On 09/08/2014 12:09 PM, James Bottomley wrote:
>
> Um, I think you need to re-read the thread; that's not what I said at
> all. It's even written lower down: "PA can't do atomic bit sets (no
> atomic RMW except the ldcw operation) it can do atomic writes to
> fundamental sizes (byte, short, int, l
On Mon, 2014-09-08 at 11:12 -0700, H. Peter Anvin wrote:
> On 09/07/2014 10:56 PM, James Bottomley wrote:
> > On Sun, 2014-09-07 at 16:39 -0700, H. Peter Anvin wrote:
> >> How many PARISC systems do we have that actually do real work on Linux?
> >
> > I'd be very surprised if this problem didn't e
On Mon, 2014-09-08 at 18:52 +0100, One Thousand Gnomes wrote:
> On Fri, 05 Sep 2014 08:41:52 -0700
> "H. Peter Anvin" wrote:
>
> > On 09/05/2014 08:31 AM, Peter Hurley wrote:
> > >
> > > Which is a bit ironic because I remember when Digital had a team
> > > working on emulating native x86 apps o
On 09/07/2014 10:56 PM, James Bottomley wrote:
> On Sun, 2014-09-07 at 16:39 -0700, H. Peter Anvin wrote:
>> How many PARISC systems do we have that actually do real work on Linux?
>
> I'd be very surprised if this problem didn't exist on all alignment
> requiring architectures, like PPC and Sparc
On 09/08/2014 10:52 AM, One Thousand Gnomes wrote:
> On Fri, 05 Sep 2014 08:41:52 -0700
> "H. Peter Anvin" wrote:
>
>> On 09/05/2014 08:31 AM, Peter Hurley wrote:
>>>
>>> Which is a bit ironic because I remember when Digital had a team
>>> working on emulating native x86 apps on Alpha/NT.
>>>
>>
On Fri, 05 Sep 2014 08:41:52 -0700
"H. Peter Anvin" wrote:
> On 09/05/2014 08:31 AM, Peter Hurley wrote:
> >
> > Which is a bit ironic because I remember when Digital had a team
> > working on emulating native x86 apps on Alpha/NT.
> >
>
> Right, because the x86 architecture was obsolete and w
I guess we were both working on it independently. I had made the
changes to hotplug a cpu a few weeks ago, but was blocked on removing a
cpu. Last week I realized what was blocking me and fixed cpu removal,
so I sent the patch along. Since Bharata has already submitted a patch
that will hand
Paul E. McKenney wrote:
>On Fri, Sep 05, 2014 at 02:50:31PM -0400, Peter Hurley wrote:
>>On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
>>> This commit documents the fact that it is not safe to use bitfields as
>>> shared variables in synchronization algorithms. It also documents that
>>> CPUs mu
> 在 2014年9月5日,18:47,Sergei Shtylyov 写道:
>
> Hello.
>
>> On 9/5/2014 2:10 PM, Yijing Wang wrote:
>>
>> Use MSI chip framework instead of arch MSI functions to configure
>> MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
>
>> Signed-off-by: Yijing Wang
>> ---
>> arch/po
> 在 2014年9月5日,18:42,Sergei Shtylyov 写道:
>
> Hello.
>
>> On 9/5/2014 2:09 PM, Yijing Wang wrote:
>>
>> Use MSI chip framework instead of arch MSI functions to configure
>> MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
>
>> Signed-off-by: Yijing Wang
>> ---
>> drivers/
On 09/08/2014 04:29 PM, Grant Likely wrote:
> On Wed, 27 Aug 2014 17:09:39 +0300, Laurentiu Tudor
> wrote:
>> Simply swap of_alias and of_chosen initialization so
>> that of_alias ends up read first. This must be done
>> because it is accessed couple of lines below when
>> trying to initialize th
It looks like you have a lot of the same changes as the patch Bharata
sent out last week. Including the one issue I saw in Bharata's patch
below.
On 09/05/2014 02:09 PM, Thomas Falcon wrote:
> This patch attempts to ensure that all values are in the proper
> endianness format when both hotadding a
On Wed, 27 Aug 2014 17:09:39 +0300, Laurentiu Tudor
wrote:
> Simply swap of_alias and of_chosen initialization so
> that of_alias ends up read first. This must be done
> because it is accessed couple of lines below when
> trying to initialize the of_stdout using the alias
> based legacy method.
>
On 07.09.14 18:31, Madhavan Srinivasan wrote:
> This patch extends the use of illegal instruction as software
> breakpoint instruction across the ppc platform. Patch extends
> booke program interrupt code to support software breakpoint.
>
> Signed-off-by: Madhavan Srinivasan
> ---
>
> Patch is
On 07.09.14 18:31, Madhavan Srinivasan wrote:
> This patch adds kernel side support for software breakpoint.
> Design is that, by using an illegal instruction, we trap to hypervisor
> via Emulation Assistance interrupt, where we check for the illegal instruction
> and accordingly we return to Hos
Hi Jason,
Am Sonntag, den 07.09.2014, 09:32 -0400 schrieb Jason Cooper:
> Just to dot our i's and cross our t's, would you mind sending out a
> non-rfc version of this series?
Thank you for the reminder, I have sent an updated version.
regards
Philipp
___
Currently there is a wild mixture of isl, isil, and intersil
compatibles in the kernel. At this point, changing the vendor
symbol to the most often used variant, which is equal to the
NASDAQ symbol, isil, should not hurt.
This patch marks both intersil and isl prefix as deprecated
and documents th
Currently there is a wild mixture of isl, isil, and intersil compatibles
in the kernel. At this point, changing the vendor symbol to the most often
used variant, which is equal to the NASDAQ symbol, isil, should not hurt.
Patch 70e123373c05 (rtc: Add support for Intersil ISL12057 I2C RTC chip)
add
Currently there is a wild mixture of isl, isil, and intersil
compatibles in the kernel. At this point, changing the vendor
symbol to the most often used variant, which is equal to the
NASDAQ symbol, isil, should not hurt.
Signed-off-by: Philipp Zabel
---
arch/arm/boot/dts/armada-370-netgear-rn10
Hi,
currently there is a wild mixture of isl, isil, and intersil
compatibles in the kernel. I figure at this point it is still
possible to change this to use "isil" everywhere without too
much pain, but it might be preferred to keep the already
documented "isl" prefix, even though it doesn't follo
Currently there is a wild mixture of isl, isil, and intersil compatibles
in the kernel. At this point, changing the vendor symbol to the most often
used variant, which is equal to the NASDAQ symbol, isil, should not hurt.
Patch db04d6284e2a (drivers/rtc/rtc-isl12022.c: device tree support)
added d
This patch adds the Intersil ISL1208 and ISL12022 I2C RTCs to the
trivial-devices list. For ISL1208 a deprecated intersil,isl1208
entry is added since that is used in ppa8548.dts.
Signed-off-by: Philipp Zabel
---
Changes since v1:
- Added deprecated entries that are still in use
---
Documentati
On Thu, Aug 28, 2014 at 08:32:58PM +0530, Sudip Mukherjee wrote:
> as pr_* macros are more preffered over printk, so printk replaced with
> corresponding pr_* macros
>
> Signed-off-by: Sudip Mukherjee
> ---
>
> The replacement was done by a bash script to avoid copy paste error. The
> script i
44 matches
Mail list logo