* [PATCH] spi/pl022: Activate resourses before deactivate them in suspend
From: Mark Brown @ 2012-10-14 5:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFpa8XoEy-kq3nq0dbRtM=a1wJ7cx=OzCOqMY1PmXrXJYw@mail.gmail.com>
On Fri, Oct 12, 2012 at 04:42:53PM +0200, Ulf Hansson wrote:
> Hi Mark,
>
> Just a kind remember on this. Do you see any problem merging this?
>
> Kind regards
> Ulf Hansson
>
> On 5 October 2012 09:43, Ulf Hansson <ulf.hansson@stericsson.com> wrote:
Don't top post and don't send contentless nags less than a week after
your original mail, especially not in the merge window when only urgent
bug fixes should be applied.
^ permalink raw reply
* dma_alloc_coherent fails in framebuffer
From: Tony Prisk @ 2012-10-14 5:28 UTC (permalink / raw)
To: linux-arm-kernel
Up until 07 Oct, drivers/video/wm8505-fb.c was working fine, but on the
11 Oct when I did another pull from linus all of a sudden
dma_alloc_coherent is failing to allocate the framebuffer any longer.
I did a quick look back and found this:
ARM: add coherent dma ops
arch_is_coherent is problematic as it is a global symbol. This
doesn't work for multi-platform kernels or platforms which can support
per device coherent DMA.
This adds arm_coherent_dma_ops to be used for devices which connected
coherently (i.e. to the ACP port on Cortex-A9 or A15). The arm_dma_ops
are modified at boot when arch_is_coherent is true.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
This is the only patch lately that I could find (not that I would claim
to be any good at finding things) that is related to the problem. Could
it have caused the allocations to fail?
Regards
Tony P
^ permalink raw reply
* pm: add suspend_mem and suspend_standby support
From: Rafael J. Wysocki @ 2012-10-14 7:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121010094353.GR12801@game.jcrosoft.org>
[...]
> > > I understand that, there is trade-off between power and latency numbers,
> > > but for certain use-cases latency is more important and it is not
> > > possible without telling driver about the low-power state.
> >
> > I understand the problem at hand, but the question is who's going to tell
> > the driver about that.
> >
> > Arguably, the PM core is not the right source of that information, because
> > if a driver is told "we're going into standby", it will have to ask the
> > platform about what "standby" actually means.
>
> who is going to tell the kernel to go to standby and which
>
> the sysfs handle via PM core
>
> so here the one who alwasy have the information is the pm core
The core tells the _platform_ "the user wants us to go into standby" or
"the user wants us to go into suspend", but it doesn't really know what
"standby" or "suspend" actually mean. It can't, because these things are
not universally well defined and there are differences between platforms
in that area. Different platforms may require different things to be
done to devices for "standby" and so drivers should not assume that
"standby" will always mean the same thing.
For example, if your driver is written for and ARM SoC and then the same
IP block happens to be used on an x86-based thing, whatever the driver did
and was specific to ARM is no longer valid. So if your ARM SoC required
drivers to do something special during a "suspend" transition which wasn't
necessary to do during a "standby" transition, it doesn't necessarily mean that
the new platform will do so as well. The "mem" and "standby" things may have
different meanings for the new platform and for this reason drivers _have_ _to_
ask the _platform_ what states to put the devices into _or_, alternatively,
leave the platform-specific handling of the devices to the platform (that's
what device drivers on ACPI-based x86 do). They should not expect the PM core
to tell them that, simply because the PM core has no idea what that may be.
And by the way, ACPI-based ARM platforms are reportedly in the works and they
_will_ use the same IP blocks that are already in use on ARM. On those
platforms drivers will be supposed to use ACPI for power management and
the whole design you're proposing will not make sense any more for them.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* [PATCH V2 3/3] ARM: SPEAr13xx: Pass DW DMAC platform data from DT
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-14 10:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKohpokj0Up23YEDTuSOHDgqcCuM3Q21cwnkAz5Ya=JhPKM98A@mail.gmail.com>
On 19:40 Sat 13 Oct , Viresh Kumar wrote:
> On 13 October 2012 19:38, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > On 13 October 2012 17:52, Jean-Christophe PLAGNIOL-VILLARD
> > <plagnioj@jcrosoft.com> wrote:
> >> On 14:18 Sat 13 Oct , Viresh Kumar wrote:
> >>> On Oct 13, 2012 12:16 PM, "Jean-Christophe PLAGNIOL-VILLARD"
> >>> <plagnioj@jcrosoft.com> wrote:
> >>> >
> >>> > On 22:42 Fri 12 Oct , Viresh Kumar wrote:
> >>> > > On 12 October 2012 21:51, Jean-Christophe PLAGNIOL-VILLARD
> >>> > > <plagnioj@jcrosoft.com> wrote:
> >>> > > >> >> + OF_DEV_AUXDATA("arasan,cf-spear1340", MCIF_CF_BASE, NULL,
> >>> "cf"),
> >>> > > >> > ?/
> >>> > > >>
> >>> > > >> Sorry. can't get it :(
> >>> > > > what is the "cf" as paltfrom data
> >>> > >
> >>> > > This is dma bus_id string, which matches with what is passed from dtb.
> >>> > so pass if via dtb too
> >>>
> >>> Yes. Already passed in 13xx.dtsi.
>
> Probably some confusion here. What i meant to say here is, dmac's
> DT slave info has a node for cf and cf driver expects this string to come
> via platform data currently.
so use a phandle to connect them
Best Regards,
J.
^ permalink raw reply
* No subject
From: Alexey Dobriyan @ 2012-10-14 10:05 UTC (permalink / raw)
To: linux-arm-kernel
http://www.hzsonic.com/en/wp-content/themes/twentyten/career.html
^ permalink raw reply
* [RFC] Common clock framework for external clock generators
From: Sebastian Hesselbarth @ 2012-10-14 10:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50785EBF.3060508@gmail.com>
Adding LAKML and devtree as there might be people willing to comment about
DT representation of i2c-attached clock generators, too.
On 10/12/2012 08:17 PM, Daniel Mack wrote:
> On 11.10.2012 18:00, Sebastian Hesselbarth wrote:
>> [...]
>> Does any of you work rely on a working si5351 driver?
>
> Yes, it does actually. I can hack around it for now, but at some point,
> a proper driver is needed. And yours looks quite feature complete, so it
> would be easiest to finish this one :)
Well, yes it is some kind of feature complete except regmap and DT. Adding
regmap to the driver should be quite easy but with DT I am still thinking
of the best way to represent the internal connections between OSC, PLLs, and
CLKOUTs. In the last version of the driver I had a callback that was
board specific to setup these connections but with DT there will be no board
specific code anymore.
Maybe one of the common clk maintainers can give a hint how this could be
done in a clean way. The question is how to represent a i2c-attached clock
generator config in DT where you want to setup clock parents of CLKOUTs and
PLLs.
A possible solution would be something like this:
si5351a at 60 {
compatible = "silabs,si5351a";
reg = <0x60>;
si_osc: osc {
compatible = "fixed-clock";
clock-frequency = <270000000>;
};
si_plla: pll at 0 {
compatible = "silabs,si5351-pll";
/* hook-up plla to osc input */
clocks = <&si_osc>;
};
si_clkout0: clkout at 0 {
compatible = "silabs,si5351-clkout";
/* hook-up clkout0 to plla */
clocks = <&si_plla>;
/* request target frequency */
clock-frequency = <148500000>;
};
};
Although this perfectly describes the clock hierarchy I still don't like
the sub-node style. Another flat solution would be something like:
si_osc: osc {
compatible = "fixed-clock";
clock-frequency = <270000000>;
};
si5351a at 60 {
compatible = "silabs,si5351a";
reg = <0x60>;
clocks = <&si_osc>;
si5351-pll-config = <0 0 /* pll A to osc */
1 0>; /* pll B to osc */
si5351-clock-config = <0 0 148500000 /* clkout 0 to pll A, 148.5MHz */
1 0 0 /* clkout 1 to pll A, disabled */
2 1 24000000>; /* clkout 2 to pll B, 24.0Mhz */
};
> Do you still have access to hardware you wrote the driver for? Let me
> know if you need any help around here.
Yes, hardware is still available although I only have access to the Si5351a
with 3 clkouts. The code should be compatible for Si5351a with 8 clkouts and
code skeleton for 5351b (OSC and VXCO input) and 5351c (OSC and CLKIN) is
there but untested.
I've transferred the current driver version to my repository to work on. As soon
as I have regmap done, I will push it online and give you a note.
Sebastian
^ permalink raw reply
* [RFC] Common clock framework for external clock generators
From: Daniel Mack @ 2012-10-14 11:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507A9AF6.4030008@gmail.com>
Hi,
On 14.10.2012 12:59, Sebastian Hesselbarth wrote:
> Adding LAKML and devtree as there might be people willing to comment about
> DT representation of i2c-attached clock generators, too.
>
> On 10/12/2012 08:17 PM, Daniel Mack wrote:
>> On 11.10.2012 18:00, Sebastian Hesselbarth wrote:
> >> [...]
>>> Does any of you work rely on a working si5351 driver?
>>
>> Yes, it does actually. I can hack around it for now, but at some point,
>> a proper driver is needed. And yours looks quite feature complete, so it
>> would be easiest to finish this one :)
>
> Well, yes it is some kind of feature complete except regmap and DT. Adding
> regmap to the driver should be quite easy but with DT I am still thinking
> of the best way to represent the internal connections between OSC, PLLs, and
> CLKOUTs. In the last version of the driver I had a callback that was
> board specific to setup these connections but with DT there will be no board
> specific code anymore.
>
> Maybe one of the common clk maintainers can give a hint how this could be
> done in a clean way. The question is how to represent a i2c-attached clock
> generator config in DT where you want to setup clock parents of CLKOUTs and
> PLLs.
>
> A possible solution would be something like this:
>
> si5351a at 60 {
> compatible = "silabs,si5351a";
> reg = <0x60>;
>
> si_osc: osc {
> compatible = "fixed-clock";
> clock-frequency = <270000000>;
> };
>
> si_plla: pll at 0 {
> compatible = "silabs,si5351-pll";
> /* hook-up plla to osc input */
> clocks = <&si_osc>;
> };
>
> si_clkout0: clkout at 0 {
> compatible = "silabs,si5351-clkout";
> /* hook-up clkout0 to plla */
> clocks = <&si_plla>;
> /* request target frequency */
> clock-frequency = <148500000>;
> };
> };
>
> Although this perfectly describes the clock hierarchy I still don't like
> the sub-node style. Another flat solution would be something like:
I think the sub-node style above it nicer because it allows referencing
the individual clocks outputs with a phandle. We use this chip to
generate base-frequencies for audio clocks, and so we have to switch
between two freqs for the multiples of 22.5KHz and 24KHz at runtime.
>> Do you still have access to hardware you wrote the driver for? Let me
>> know if you need any help around here.
>
> Yes, hardware is still available although I only have access to the Si5351a
> with 3 clkouts. The code should be compatible for Si5351a with 8 clkouts and
> code skeleton for 5351b (OSC and VXCO input) and 5351c (OSC and CLKIN) is
> there but untested.
The 3 clkout model is the only one I have access to as well.
> I've transferred the current driver version to my repository to work on. As soon
> as I have regmap done, I will push it online and give you a note.
That's great. Let me know if you want me to test anything.
Thanks,
Daniel
^ permalink raw reply
* [PATCH 3/4] ARM: AT91: Add AT91RM9200 support to DT board
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-14 14:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGhQ9VzOQ2V6Cn5tY1REcGzpjjs53Lu6tT7=fNKqJQkBhR8HDA@mail.gmail.com>
On 19:08 Fri 12 Oct , Joachim Eastwood wrote:
> On Fri, Oct 12, 2012 at 6:27 PM, Jean-Christophe PLAGNIOL-VILLARD
> <plagnioj@jcrosoft.com> wrote:
> > On 17:28 Fri 12 Oct , ludovic.desroches wrote:
> >> Le 10/12/2012 04:22 PM, Jean-Christophe PLAGNIOL-VILLARD a ?crit :
> >> >On 00:05 Fri 12 Oct , Joachim Eastwood wrote:
> >> >>Signed-off-by: Joachim Eastwood <manabian@gmail.com>
> >> >>---
> >> >>
> >> >>Hi,
> >> >>
> >> >>This patch has some potential issues.
> >> >>Before this patch board-dt would fail building when only AT91RM9200 was enabled because at91sam926x_timer symbol would be missing. This patch uses the at91rm9200_timer which
> >> >>will fail if AT91RM9200 is not enabled.
> >> >this need work with ot wtihout rm9200
>
> btw, to solve the build issue with board-dt in mainline now we need to
> add a select CONFIG_SOC_AT91SAM9 to config MACH_AT91SAM_DT.
>
> >> >>
> >> >>Any thoughts on solving this? As mention above this bug exists in mainline now.
> >> >duplicate the board-dt with one for rm9200 only
> >> >as rm9200 ans sam9 are 2 distict familly
> >>
> >> Why not adding a new machine descriptor for rm9200 in order to
> >> prevent file duplication?
> > because the soc are different and can only be compile if the timer is enable
> > and I do not want to enable the rm9200 timer on sam9 so instead of a ifdef i
> > the board-dt create a new board is better as we have a 50 lines file
> >
> > with different board_compat and different machine descriptor
>
> I am okey with either approach, but I would like to hear what Nicolas
> Ferre has to say since he is the on the one that added board-dt. It
> would be nice to have everything in one board DT file, but I
> understand your concern with the RM9200 timer.
>
> We will also bump into this again on AT91X40 I guess.
simple on x40 forget about it the x40 is no MMU only SoC
so you can not enable it by default as the all other at91 are use with MMU
I did the necessary to make the board-dt nearly empty and the same for all the
sam9 but the board-dt is sam9 only and need to be keeped this way
Nico will tell you the same
Best Regards,
J.
^ permalink raw reply
* [git pull] signals pile 3
From: Daniel Mack @ 2012-10-14 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121013005334.GM2616@ZenIV.linux.org.uk>
Hi Al,
On 13.10.2012 02:53, Al Viro wrote:
> The last bits of infrastructure for kernel_thread() et.al., with alpha/arm/x86
> use of those. Plus sanitizing the asm glue and do_notify_resume() on alpha,
> fixing the "disabled irq while running task_work stuff" breakage there.
>
> At that point the rest of kernel_thread/kernel_execve/sys_execve work can
> be done independently for different architectures. The only pending bits
> that do depend on having all architectures converted are restrictred to
> fs/* and kernel/* - that'll obviously have to wait for the next cycle.
> I thought we'd have to wait for all of them done before we start eliminating
> the longjump-style insanity in kernel_execve(), but it turned out there's
> a very simple way to do that without flagday-style changes.
>
> Please, pull from
> git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal for-linus
>
> Shortlog:
> Al Viro (12):
[...]
> arm: switch to saner kernel_execve() semantics
[...]
> Diffstat:
[...]
> arch/arm/include/asm/unistd.h | 1 -
> arch/arm/kernel/entry-common.S | 29 +--------
> arch/arm/kernel/process.c | 5 +-
I rebased my ARM development branch and figured that your patch 9fff2fa
("arm: switch to saner kernel_execve() semantics") breaks the boot on my
board right after init is invoked via NFS:
[ 4.682072] VFS: Mounted root (nfs filesystem) on device 0:12.
[ 4.690744] devtmpfs: mounted
[ 4.694395] Freeing init memory: 172K
[ 5.291417] Internal error: Oops - undefined instruction: 0 [#1] SMP
THUMB2
[ 5.298734] Modules linked in:
[ 5.301952] CPU: 0 Not tainted (3.6.0-11053-g56c8535 #128)
[ 5.308071] PC is at cpsw_probe+0x422/0x9ac
[ 5.312459] LR is at trace_hardirqs_on_caller+0x8f/0xfc
[ 5.317934] pc : [<c03493de>] lr : [<c005e81f>] psr: 60000113
[ 5.317934] sp : cf055fb0 ip : 00000000 fp : 00000000
[ 5.329944] r10: 00000000 r9 : 00000000 r8 : 00000000
[ 5.335413] r7 : 00000000 r6 : 00000000 r5 : c034458d r4 : 00000000
[ 5.342244] r3 : cf057a40 r2 : 00000000 r1 : 00000001 r0 : 00000000
[ 5.349078] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM
Segment user
[ 5.356546] Control: 50c5387d Table: 8f434019 DAC: 00000015
[ 5.362562] Process init (pid: 1, stack limit = 0xcf054240)
[ 5.368395] Stack: (0xcf055fb0 to 0xcf056000)
[ 5.372961] 5fa0: 00000001
00000000 00000000 00000000
[ 5.381525] 5fc0: cf055fb0 c000d1a8 00000000 00000000 00000000
00000000 00000000 00000000
[ 5.390091] 5fe0: 00000000 bee83f10 00000000 b6fdedd0 00000010
00000000 aaaabfaf a8babbaa
[ 5.398664] Code: 2206a010 718ef508 0184f8da f8b1f65d (3070f8d8)
[ 5.405049] ---[ end trace f92e44d0ab15d037 ]---
[ 5.410424] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b
Looking at the patch, I see it does two things:
a) kill the special treatment formerly done by ret_from_kernel_thread
b) switch over to generic execve for ARM
I know too little about the internals here, but reverting the latter
part fixes the boot for me. Find attached the patch I used locally for
that, on top of Linus' current merge tree (4d7127d).
FWIW, the config I'm using is here: http://pastebin.com/JPwAYmrD
I can test patches if you have any for me.
Thanks,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: arm-execve-revert.diff
Type: text/x-patch
Size: 1511 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121014/bbce05db/attachment.bin>
^ permalink raw reply
* [RFC] Common clock framework for external clock generators
From: Sebastian Hesselbarth @ 2012-10-14 16:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507A9E72.2030800@gmail.com>
On 10/14/2012 01:13 PM, Daniel Mack wrote:
> I think the sub-node style above it nicer because it allows referencing
> the individual clocks outputs with a phandle. We use this chip to
> generate base-frequencies for audio clocks, and so we have to switch
> between two freqs for the multiples of 22.5KHz and 24KHz at runtime.
Both examples allow you to have a phandle for all individual clock-outputs.
The examples weren't complete but with the sub-node style you'll reference
with e.g. <&clkout0> while the flat one will use <&si5351 0>. I still prefer
the flat-style as it will not allow to have a phandle of plls.
Sebastian
^ permalink raw reply
* [PATCH 3/4] ARM: AT91: Add AT91RM9200 support to DT board
From: Joachim Eastwood @ 2012-10-14 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121014145407.GN12801@game.jcrosoft.org>
On Sun, Oct 14, 2012 at 4:54 PM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> On 19:08 Fri 12 Oct , Joachim Eastwood wrote:
>> On Fri, Oct 12, 2012 at 6:27 PM, Jean-Christophe PLAGNIOL-VILLARD
>> <plagnioj@jcrosoft.com> wrote:
>> > On 17:28 Fri 12 Oct , ludovic.desroches wrote:
>> >> Le 10/12/2012 04:22 PM, Jean-Christophe PLAGNIOL-VILLARD a ?crit :
>> >> >On 00:05 Fri 12 Oct , Joachim Eastwood wrote:
>> >> >>Signed-off-by: Joachim Eastwood <manabian@gmail.com>
>> >> >>---
>> >> >>
>> >> >>Hi,
>> >> >>
>> >> >>This patch has some potential issues.
>> >> >>Before this patch board-dt would fail building when only AT91RM9200 was enabled because at91sam926x_timer symbol would be missing. This patch uses the at91rm9200_timer which
>> >> >>will fail if AT91RM9200 is not enabled.
>> >> >this need work with ot wtihout rm9200
>>
>> btw, to solve the build issue with board-dt in mainline now we need to
>> add a select CONFIG_SOC_AT91SAM9 to config MACH_AT91SAM_DT.
>>
>> >> >>
>> >> >>Any thoughts on solving this? As mention above this bug exists in mainline now.
>> >> >duplicate the board-dt with one for rm9200 only
>> >> >as rm9200 ans sam9 are 2 distict familly
>> >>
>> >> Why not adding a new machine descriptor for rm9200 in order to
>> >> prevent file duplication?
>> > because the soc are different and can only be compile if the timer is enable
>> > and I do not want to enable the rm9200 timer on sam9 so instead of a ifdef i
>> > the board-dt create a new board is better as we have a 50 lines file
>> >
>> > with different board_compat and different machine descriptor
>>
>> I am okey with either approach, but I would like to hear what Nicolas
>> Ferre has to say since he is the on the one that added board-dt. It
>> would be nice to have everything in one board DT file, but I
>> understand your concern with the RM9200 timer.
>>
>> We will also bump into this again on AT91X40 I guess.
> simple on x40 forget about it the x40 is no MMU only SoC
>
> so you can not enable it by default as the all other at91 are use with MMU
>
> I did the necessary to make the board-dt nearly empty and the same for all the
> sam9 but the board-dt is sam9 only and need to be keeped this way
>
> Nico will tell you the same
okay. I'll make the necessary changes to the patch set.
I'll also include a fix for board-dt (select CONFIG_SOC_AT91SAM9) to
stop the build failure when it's enabled on a RM9200 only config.
Secondly I'll rebase on linux-next which includes your at91-pinctrl stuff.
regards
Joachim Eastwood
> Best Regards,
> J.
^ permalink raw reply
* [revert request for commit 9fff2fa] Re: [git pull] signals pile 3
From: Al Viro @ 2012-10-14 16:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507ADBBB.9090209@gmail.com>
On Sun, Oct 14, 2012 at 05:35:23PM +0200, Daniel Mack wrote:
> I rebased my ARM development branch and figured that your patch 9fff2fa
> ("arm: switch to saner kernel_execve() semantics") breaks the boot on my
> board right after init is invoked via NFS:
OK, revert it is, then. Nothing in the tree has dependencies on that sucker
and while it survives testing here, it's obviously not ready for mainline.
So, with abject apologies to everyone involved, please revert.
^ permalink raw reply
* [revert request for commit 9fff2fa] Re: [git pull] signals pile 3
From: Daniel Mack @ 2012-10-14 16:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121014164020.GV2616@ZenIV.linux.org.uk>
On Oct 14, 2012 6:40 PM, "Al Viro" <viro@zeniv.linux.org.uk> wrote:
>
> On Sun, Oct 14, 2012 at 05:35:23PM +0200, Daniel Mack wrote:
>
> > I rebased my ARM development branch and figured that your patch 9fff2fa
> > ("arm: switch to saner kernel_execve() semantics") breaks the boot on my
> > board right after init is invoked via NFS:
>
> OK, revert it is, then. Nothing in the tree has dependencies on that
sucker
> and while it survives testing here, it's obviously not ready for mainline.
> So, with abject apologies to everyone involved, please revert.
Reverting it is not straight forward, and half of this patch doesn't seem
to cause issues.
I can resend my patch with an S-o-b if you want me to.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121014/0fc4e6e4/attachment-0001.html>
^ permalink raw reply
* [revert request for commit 9fff2fa] Re: [git pull] signals pile 3
From: Al Viro @ 2012-10-14 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACTFLAOpcLtHNx-TCHQkUOPNAkTO8EgDhbyZSGQ9ag+Wu_cNRw@mail.gmail.com>
On Sun, Oct 14, 2012 at 06:44:12PM +0200, Daniel Mack wrote:
> On Oct 14, 2012 6:40 PM, "Al Viro" <viro@zeniv.linux.org.uk> wrote:
> >
> > On Sun, Oct 14, 2012 at 05:35:23PM +0200, Daniel Mack wrote:
> >
> > > I rebased my ARM development branch and figured that your patch 9fff2fa
> > > ("arm: switch to saner kernel_execve() semantics") breaks the boot on my
> > > board right after init is invoked via NFS:
> >
> > OK, revert it is, then. Nothing in the tree has dependencies on that
> sucker
> > and while it survives testing here, it's obviously not ready for mainline.
> > So, with abject apologies to everyone involved, please revert.
>
> Reverting it is not straight forward, and half of this patch doesn't seem
> to cause issues.
>
> I can resend my patch with an S-o-b if you want me to.
Um... That's _really_ interesting. First of all, revert is absolutely
straightforward; the only change in Kconfig is "remove the damn select"
and it's not hard to resolve. But I actually wonder what the hell is
going on with that breakage - the *only* thing your revert changes is
that instead of letting the kernel_thread callback return all the way
to returning 0 to ret_from_kernel_thread() on do_execve() success you
have it do ret_from_kernel_execve() instead. Hmm...
Could you try to print current_pt_regs()->ARM_r0 in kernel_execve() before
calling ret_from_kernel_execve() with your patch applied? If that somehow
got non-zero, we'd see trouble, all right, but I don't see any places where
it could.
Wait a minute... I think I see what might be going on, but I don't
understand it at all. Look: arm start_thread() is
#define start_thread(regs,pc,sp) \
({ \
unsigned long *stack = (unsigned long *)sp; \
memset(regs->uregs, 0, sizeof(regs->uregs)); \
if (current->personality & ADDR_LIMIT_32BIT) \
regs->ARM_cpsr = USR_MODE; \
else \
regs->ARM_cpsr = USR26_MODE; \
if (elf_hwcap & HWCAP_THUMB && pc & 1) \
regs->ARM_cpsr |= PSR_T_BIT; \
regs->ARM_cpsr |= PSR_ENDSTATE; \
regs->ARM_pc = pc & ~1; /* pc */ \
regs->ARM_sp = sp; /* sp */ \
regs->ARM_r2 = stack[2]; /* r2 (envp) */ \
regs->ARM_r1 = stack[1]; /* r1 (argv) */ \
regs->ARM_r0 = stack[0]; /* r0 (argc) */ \
nommu_start_thread(regs); \
})
and the last 3 make no sense whatsoever. Note that on normal execve() we'll
be going through the syscall return, so the userland will see 0 in there,
no matter what do we do here. Theoretically, it might've been done for
ptrace sake (it will be able to observe the values in those registers before
the tracee reaches userland), but there's another oddity involved - "stack"
is a userland pointer here. Granted, it's been recently written to, so
we are not likely to hit a pagefault here, but... What happens if we are
under enough memory pressure to swap those pages out? PF in the kernel
mode with no exception table entries for those insns?
^ permalink raw reply
* [RFC PATCH v2] prevent top pte being overwritten before flushing
From: Andrew Yan-Pai Chen @ 2012-10-14 17:42 UTC (permalink / raw)
To: linux-arm-kernel
From: Yan-Pai Chen <ypchen@faraday-tech.com>
Since flush_pfn_alias() is preemptible, it is possible to be
preempted just after set_top_pte() is done. If the process
which preempts the previous happened to invoke flush_pfn_alias()
with the same colour vaddr as that of the previous, the same
top pte will be overwritten. When switching back to the previous,
it attempts to flush cache lines with incorrect mapping. Then
no lines (or wrong lines) will be flushed because of the nature
of vipt caches.
flush_icache_alias() has the same problem as well. However, as it
could be called in SMP setups, we prevent concurrent overwrites of
top pte by having a lock on it.
Signed-off-by: JasonLin <wwlin@faraday-tech.com>
Signed-off-by: Yan-Pai Chen <ypchen@faraday-tech.com>
---
arch/arm/mm/flush.c | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mm/flush.c b/arch/arm/mm/flush.c
index 40ca11e..b6510f4 100644
--- a/arch/arm/mm/flush.c
+++ b/arch/arm/mm/flush.c
@@ -11,6 +11,7 @@
#include <linux/mm.h>
#include <linux/pagemap.h>
#include <linux/highmem.h>
+#include <linux/spinlock.h>
#include <asm/cacheflush.h>
#include <asm/cachetype.h>
@@ -22,11 +23,15 @@
#ifdef CONFIG_CPU_CACHE_VIPT
+static DEFINE_RAW_SPINLOCK(flush_lock);
+
+/* Beware that this function is not to be called for SMP setups. */
static void flush_pfn_alias(unsigned long pfn, unsigned long vaddr)
{
unsigned long to = FLUSH_ALIAS_START + (CACHE_COLOUR(vaddr) << PAGE_SHIFT);
const int zero = 0;
+ preempt_disable();
set_top_pte(to, pfn_pte(pfn, PAGE_KERNEL));
asm( "mcrr p15, 0, %1, %0, c14\n"
@@ -34,6 +39,8 @@ static void flush_pfn_alias(unsigned long pfn, unsigned long vaddr)
:
: "r" (to), "r" (to + PAGE_SIZE - L1_CACHE_BYTES), "r" (zero)
: "cc");
+
+ preempt_enable();
}
static void flush_icache_alias(unsigned long pfn, unsigned long vaddr, unsigned long len)
@@ -42,9 +49,13 @@ static void flush_icache_alias(unsigned long pfn, unsigned long vaddr, unsigned
unsigned long offset = vaddr & (PAGE_SIZE - 1);
unsigned long to;
+ raw_spin_lock(&flush_lock);
+
set_top_pte(va, pfn_pte(pfn, PAGE_KERNEL));
to = va + offset;
flush_icache_range(to, to + len);
+
+ raw_spin_unlock(&flush_lock);
}
void flush_cache_mm(struct mm_struct *mm)
--
1.7.4.1
^ permalink raw reply related
* [revert request for commit 9fff2fa] Re: [git pull] signals pile 3
From: Al Viro @ 2012-10-14 17:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121014172640.GW2616@ZenIV.linux.org.uk>
On Sun, Oct 14, 2012 at 06:26:40PM +0100, Al Viro wrote:
> On Sun, Oct 14, 2012 at 06:44:12PM +0200, Daniel Mack wrote:
> > On Oct 14, 2012 6:40 PM, "Al Viro" <viro@zeniv.linux.org.uk> wrote:
> > >
> > > On Sun, Oct 14, 2012 at 05:35:23PM +0200, Daniel Mack wrote:
> > >
> > > > I rebased my ARM development branch and figured that your patch 9fff2fa
> > > > ("arm: switch to saner kernel_execve() semantics") breaks the boot on my
> > > > board right after init is invoked via NFS:
> > >
> > > OK, revert it is, then. Nothing in the tree has dependencies on that
> > sucker
> > > and while it survives testing here, it's obviously not ready for mainline.
> > > So, with abject apologies to everyone involved, please revert.
> >
> > Reverting it is not straight forward, and half of this patch doesn't seem
> > to cause issues.
> >
> > I can resend my patch with an S-o-b if you want me to.
>
> Um... That's _really_ interesting. First of all, revert is absolutely
> straightforward; the only change in Kconfig is "remove the damn select"
> and it's not hard to resolve. But I actually wonder what the hell is
> going on with that breakage - the *only* thing your revert changes is
> that instead of letting the kernel_thread callback return all the way
> to returning 0 to ret_from_kernel_thread() on do_execve() success you
> have it do ret_from_kernel_execve() instead. Hmm...
>
> Could you try to print current_pt_regs()->ARM_r0 in kernel_execve() before
> calling ret_from_kernel_execve() with your patch applied? If that somehow
> got non-zero, we'd see trouble, all right, but I don't see any places where
> it could.
>
> Wait a minute... I think I see what might be going on, but I don't
> understand it at all. Look: arm start_thread() is
> #define start_thread(regs,pc,sp) \
> ({ \
> unsigned long *stack = (unsigned long *)sp; \
> memset(regs->uregs, 0, sizeof(regs->uregs)); \
> if (current->personality & ADDR_LIMIT_32BIT) \
> regs->ARM_cpsr = USR_MODE; \
> else \
> regs->ARM_cpsr = USR26_MODE; \
> if (elf_hwcap & HWCAP_THUMB && pc & 1) \
> regs->ARM_cpsr |= PSR_T_BIT; \
> regs->ARM_cpsr |= PSR_ENDSTATE; \
> regs->ARM_pc = pc & ~1; /* pc */ \
> regs->ARM_sp = sp; /* sp */ \
> regs->ARM_r2 = stack[2]; /* r2 (envp) */ \
> regs->ARM_r1 = stack[1]; /* r1 (argv) */ \
> regs->ARM_r0 = stack[0]; /* r0 (argc) */ \
> nommu_start_thread(regs); \
> })
> and the last 3 make no sense whatsoever. Note that on normal execve() we'll
> be going through the syscall return, so the userland will see 0 in there,
> no matter what do we do here. Theoretically, it might've been done for
> ptrace sake (it will be able to observe the values in those registers before
> the tracee reaches userland), but there's another oddity involved - "stack"
> is a userland pointer here. Granted, it's been recently written to, so
> we are not likely to hit a pagefault here, but... What happens if we are
> under enough memory pressure to swap those pages out? PF in the kernel
> mode with no exception table entries for those insns?
FWIW, if you don't mind an experiment, try to take mainline (with that
commit not reverted) and add
strne r0, [sp, #S_R0]
right before
get_thread_info tsk
in ret_from_fork(). And see if that changes behaviour.
^ permalink raw reply
* [PATCH] lib: decompress_unlzo: Change include file name
From: Fabio Estevam @ 2012-10-14 18:13 UTC (permalink / raw)
To: linux-arm-kernel
From: Fabio Estevam <fabio.estevam@freescale.com>
Commit 7c979cebc (lib/lzo: Rename lzo1x_decompress.c to lzo1x_decompress_safe.c)
renamed lzo1x_decompress.c file, but missed to update lib/decompress_unlzo.c,
which breaks imx_v6_v7_defconfig build:
arch/arm/boot/compressed/../../../../lib/decompress_unlzo.c:34:34: fatal error: lzo/lzo1x_decompress.c: No such file or directory
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
lib/decompress_unlzo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/decompress_unlzo.c b/lib/decompress_unlzo.c
index 4531294..960183d 100644
--- a/lib/decompress_unlzo.c
+++ b/lib/decompress_unlzo.c
@@ -31,7 +31,7 @@
*/
#ifdef STATIC
-#include "lzo/lzo1x_decompress.c"
+#include "lzo/lzo1x_decompress_safe.c"
#else
#include <linux/decompress/unlzo.h>
#endif
--
1.7.9.5
^ permalink raw reply related
* [revert request for commit 9fff2fa] Re: [git pull] signals pile 3
From: Daniel Mack @ 2012-10-14 18:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121014175541.GX2616@ZenIV.linux.org.uk>
On 14.10.2012 19:55, Al Viro wrote:
> On Sun, Oct 14, 2012 at 06:26:40PM +0100, Al Viro wrote:
>> On Sun, Oct 14, 2012 at 06:44:12PM +0200, Daniel Mack wrote:
>>> On Oct 14, 2012 6:40 PM, "Al Viro" <viro@zeniv.linux.org.uk> wrote:
>>>>
>>>> On Sun, Oct 14, 2012 at 05:35:23PM +0200, Daniel Mack wrote:
>>>>
>>>>> I rebased my ARM development branch and figured that your patch 9fff2fa
>>>>> ("arm: switch to saner kernel_execve() semantics") breaks the boot on my
>>>>> board right after init is invoked via NFS:
>>>>
>>>> OK, revert it is, then. Nothing in the tree has dependencies on that
>>> sucker
>>>> and while it survives testing here, it's obviously not ready for mainline.
>>>> So, with abject apologies to everyone involved, please revert.
>>>
>>> Reverting it is not straight forward, and half of this patch doesn't seem
>>> to cause issues.
>>>
>>> I can resend my patch with an S-o-b if you want me to.
>>
>> Um... That's _really_ interesting. First of all, revert is absolutely
>> straightforward; the only change in Kconfig is "remove the damn select"
>> and it's not hard to resolve. But I actually wonder what the hell is
>> going on with that breakage - the *only* thing your revert changes is
>> that instead of letting the kernel_thread callback return all the way
>> to returning 0 to ret_from_kernel_thread() on do_execve() success you
>> have it do ret_from_kernel_execve() instead. Hmm...
>>
>> Could you try to print current_pt_regs()->ARM_r0 in kernel_execve() before
>> calling ret_from_kernel_execve() with your patch applied? If that somehow
>> got non-zero, we'd see trouble, all right, but I don't see any places where
>> it could.
>>
>> Wait a minute... I think I see what might be going on, but I don't
>> understand it at all. Look: arm start_thread() is
>> #define start_thread(regs,pc,sp) \
>> ({ \
>> unsigned long *stack = (unsigned long *)sp; \
>> memset(regs->uregs, 0, sizeof(regs->uregs)); \
>> if (current->personality & ADDR_LIMIT_32BIT) \
>> regs->ARM_cpsr = USR_MODE; \
>> else \
>> regs->ARM_cpsr = USR26_MODE; \
>> if (elf_hwcap & HWCAP_THUMB && pc & 1) \
>> regs->ARM_cpsr |= PSR_T_BIT; \
>> regs->ARM_cpsr |= PSR_ENDSTATE; \
>> regs->ARM_pc = pc & ~1; /* pc */ \
>> regs->ARM_sp = sp; /* sp */ \
>> regs->ARM_r2 = stack[2]; /* r2 (envp) */ \
>> regs->ARM_r1 = stack[1]; /* r1 (argv) */ \
>> regs->ARM_r0 = stack[0]; /* r0 (argc) */ \
>> nommu_start_thread(regs); \
>> })
>> and the last 3 make no sense whatsoever. Note that on normal execve() we'll
>> be going through the syscall return, so the userland will see 0 in there,
>> no matter what do we do here. Theoretically, it might've been done for
>> ptrace sake (it will be able to observe the values in those registers before
>> the tracee reaches userland), but there's another oddity involved - "stack"
>> is a userland pointer here. Granted, it's been recently written to, so
>> we are not likely to hit a pagefault here, but... What happens if we are
>> under enough memory pressure to swap those pages out? PF in the kernel
>> mode with no exception table entries for those insns?
>
> FWIW, if you don't mind an experiment, try to take mainline (with that
> commit not reverted) and add
> strne r0, [sp, #S_R0]
> right before
> get_thread_info tsk
> in ret_from_fork(). And see if that changes behaviour.
>
I don't mind experiments at all :)
However, with that extra line in place as described, I'm still getting
the Oops below. If you want me to test anything else, please let me know.
[ 4.683182] VFS: Mounted root (nfs filesystem) on device 0:12.
[ 4.742007] devtmpfs: mounted
[ 4.745746] Freeing init memory: 172K
[ 5.038724] Internal error: Oops - undefined instruction: 0 [#1] SMP
THUMB2
[ 5.046044] Modules linked in:
[ 5.049263] CPU: 0 Not tainted (3.6.0-11053-g56c8535-dirty #136)
[ 5.055925] PC is at cpsw_probe+0x422/0x9ac
[ 5.060314] LR is at trace_hardirqs_on_caller+0x8f/0xfc
[ 5.065790] pc : [<c03493de>] lr : [<c005e81f>] psr: 60000113
[ 5.065790] sp : cf055fb0 ip : 00000000 fp : 00000000
[ 5.077800] r10: 00000000 r9 : 00000000 r8 : 00000000
[ 5.083270] r7 : 00000000 r6 : 00000000 r5 : c034458d r4 : 00000000
[ 5.090101] r3 : cf057a40 r2 : 00000000 r1 : 00000001 r0 : 00000000
[ 5.096936] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM
Segment user
[ 5.104406] Control: 50c5387d Table: 8f434019 DAC: 00000015
[ 5.110422] Process init (pid: 1, stack limit = 0xcf054240)
[ 5.116257] Stack: (0xcf055fb0 to 0xcf056000)
[ 5.120824] 5fa0: 00000001
00000000 00000000 00000000
[ 5.129390] 5fc0: cf055fb0 c000d1a8 00000000 00000000 00000000
00000000 00000000 00000000
[ 5.137957] 5fe0: 00000000 becedf10 00000000 b6f81dd0 00000010
00000000 aaaabfaf a8babbaa
[ 5.146529] Code: 2206a010 718ef508 0184f8da f8b1f65d (3070f8d8)
[ 5.152915] ---[ end trace 7362bbe8e73e6b07 ]---
[ 5.158324] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b
[ 5.158324]
^ permalink raw reply
* [revert request for commit 9fff2fa] Re: [git pull] signals pile 3
From: Al Viro @ 2012-10-14 19:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507B02C1.1090101@gmail.com>
On Sun, Oct 14, 2012 at 08:21:53PM +0200, Daniel Mack wrote:
> On 14.10.2012 19:55, Al Viro wrote:
> > On Sun, Oct 14, 2012 at 06:26:40PM +0100, Al Viro wrote:
> >> On Sun, Oct 14, 2012 at 06:44:12PM +0200, Daniel Mack wrote:
> >>> On Oct 14, 2012 6:40 PM, "Al Viro" <viro@zeniv.linux.org.uk> wrote:
> >>>>
> >>>> On Sun, Oct 14, 2012 at 05:35:23PM +0200, Daniel Mack wrote:
> >>>>
> >>>>> I rebased my ARM development branch and figured that your patch 9fff2fa
> >>>>> ("arm: switch to saner kernel_execve() semantics") breaks the boot on my
> >>>>> board right after init is invoked via NFS:
> >>>>
> >>>> OK, revert it is, then. Nothing in the tree has dependencies on that
> >>> sucker
> >>>> and while it survives testing here, it's obviously not ready for mainline.
> >>>> So, with abject apologies to everyone involved, please revert.
> >>>
> >>> Reverting it is not straight forward, and half of this patch doesn't seem
> >>> to cause issues.
> >>>
> >>> I can resend my patch with an S-o-b if you want me to.
> >>
> >> Um... That's _really_ interesting. First of all, revert is absolutely
> >> straightforward; the only change in Kconfig is "remove the damn select"
> >> and it's not hard to resolve. But I actually wonder what the hell is
> >> going on with that breakage - the *only* thing your revert changes is
> >> that instead of letting the kernel_thread callback return all the way
> >> to returning 0 to ret_from_kernel_thread() on do_execve() success you
> >> have it do ret_from_kernel_execve() instead. Hmm...
> >>
> >> Could you try to print current_pt_regs()->ARM_r0 in kernel_execve() before
> >> calling ret_from_kernel_execve() with your patch applied? If that somehow
> >> got non-zero, we'd see trouble, all right, but I don't see any places where
> >> it could.
> >>
> >> Wait a minute... I think I see what might be going on, but I don't
> >> understand it at all. Look: arm start_thread() is
> >> #define start_thread(regs,pc,sp) \
> >> ({ \
> >> unsigned long *stack = (unsigned long *)sp; \
> >> memset(regs->uregs, 0, sizeof(regs->uregs)); \
> >> if (current->personality & ADDR_LIMIT_32BIT) \
> >> regs->ARM_cpsr = USR_MODE; \
> >> else \
> >> regs->ARM_cpsr = USR26_MODE; \
> >> if (elf_hwcap & HWCAP_THUMB && pc & 1) \
> >> regs->ARM_cpsr |= PSR_T_BIT; \
> >> regs->ARM_cpsr |= PSR_ENDSTATE; \
> >> regs->ARM_pc = pc & ~1; /* pc */ \
> >> regs->ARM_sp = sp; /* sp */ \
> >> regs->ARM_r2 = stack[2]; /* r2 (envp) */ \
> >> regs->ARM_r1 = stack[1]; /* r1 (argv) */ \
> >> regs->ARM_r0 = stack[0]; /* r0 (argc) */ \
> >> nommu_start_thread(regs); \
> >> })
> >> and the last 3 make no sense whatsoever. Note that on normal execve() we'll
> >> be going through the syscall return, so the userland will see 0 in there,
> >> no matter what do we do here. Theoretically, it might've been done for
> >> ptrace sake (it will be able to observe the values in those registers before
> >> the tracee reaches userland), but there's another oddity involved - "stack"
> >> is a userland pointer here. Granted, it's been recently written to, so
> >> we are not likely to hit a pagefault here, but... What happens if we are
> >> under enough memory pressure to swap those pages out? PF in the kernel
> >> mode with no exception table entries for those insns?
> >
> > FWIW, if you don't mind an experiment, try to take mainline (with that
> > commit not reverted) and add
> > strne r0, [sp, #S_R0]
> > right before
> > get_thread_info tsk
> > in ret_from_fork(). And see if that changes behaviour.
> >
>
> I don't mind experiments at all :)
>
> However, with that extra line in place as described, I'm still getting
> the Oops below. If you want me to test anything else, please let me know.
>
>
> [ 4.683182] VFS: Mounted root (nfs filesystem) on device 0:12.
> [ 4.742007] devtmpfs: mounted
> [ 4.745746] Freeing init memory: 172K
> [ 5.038724] Internal error: Oops - undefined instruction: 0 [#1] SMP
> THUMB2
> [ 5.046044] Modules linked in:
> [ 5.049263] CPU: 0 Not tainted (3.6.0-11053-g56c8535-dirty #136)
> [ 5.055925] PC is at cpsw_probe+0x422/0x9ac
> [ 5.060314] LR is at trace_hardirqs_on_caller+0x8f/0xfc
> [ 5.065790] pc : [<c03493de>] lr : [<c005e81f>] psr: 60000113
> [ 5.065790] sp : cf055fb0 ip : 00000000 fp : 00000000
> [ 5.077800] r10: 00000000 r9 : 00000000 r8 : 00000000
> [ 5.083270] r7 : 00000000 r6 : 00000000 r5 : c034458d r4 : 00000000
> [ 5.090101] r3 : cf057a40 r2 : 00000000 r1 : 00000001 r0 : 00000000
> [ 5.096936] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM
> Segment user
> [ 5.104406] Control: 50c5387d Table: 8f434019 DAC: 00000015
> [ 5.110422] Process init (pid: 1, stack limit = 0xcf054240)
> [ 5.116257] Stack: (0xcf055fb0 to 0xcf056000)
> [ 5.120824] 5fa0: 00000001
> 00000000 00000000 00000000
> [ 5.129390] 5fc0: cf055fb0 c000d1a8 00000000 00000000 00000000
> 00000000 00000000 00000000
> [ 5.137957] 5fe0: 00000000 becedf10 00000000 b6f81dd0 00000010
> 00000000 aaaabfaf a8babbaa
> [ 5.146529] Code: 2206a010 718ef508 0184f8da f8b1f65d (3070f8d8)
> [ 5.152915] ---[ end trace 7362bbe8e73e6b07 ]---
> [ 5.158324] Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x0000000b
> [ 5.158324]
Very interesting... So we have kernel_thread() payload called and we have
it reach kernel_execve() (otherwise your reverting kernel_execve() change
would've had no effect). Said payload returns, and sp value seems to be
sane. Buggered return address, perhaps? But that would be killing the
damn thing everywhere...
Just in case - print __builtin_return_address(0) in the beginning of
kernel_init(); it ought to point at the end of ret_from_fork...
And kill that strne along with assignment to ->ARM_r0 in start_thread().
I've missed the obvious problem with strne - flag values won't survive the
call of payload ;-/ IOW, it's still possible that we are getting bitten
by strange value left in there. Removing the assignment in start_thread()
would check that possiblity...
^ permalink raw reply
* [PATCH 1/9] uprobes: move function declarations out of arch
From: Rabin Vincent @ 2012-10-14 19:23 UTC (permalink / raw)
To: linux-arm-kernel
It seems odd to keep the function declarations in the arch header where
they will need to be copy/pasted verbatim across arches. Move them to
the common header.
Signed-off-by: Rabin Vincent <rabin@rab.in>
---
arch/x86/include/asm/uprobes.h | 6 ------
include/linux/uprobes.h | 8 ++++++++
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/arch/x86/include/asm/uprobes.h b/arch/x86/include/asm/uprobes.h
index 8ff8be7..b20b4d6 100644
--- a/arch/x86/include/asm/uprobes.h
+++ b/arch/x86/include/asm/uprobes.h
@@ -49,10 +49,4 @@ struct arch_uprobe_task {
unsigned int saved_tf;
};
-extern int arch_uprobe_analyze_insn(struct arch_uprobe *aup, struct mm_struct *mm, unsigned long addr);
-extern int arch_uprobe_pre_xol(struct arch_uprobe *aup, struct pt_regs *regs);
-extern int arch_uprobe_post_xol(struct arch_uprobe *aup, struct pt_regs *regs);
-extern bool arch_uprobe_xol_was_trapped(struct task_struct *tsk);
-extern int arch_uprobe_exception_notify(struct notifier_block *self, unsigned long val, void *data);
-extern void arch_uprobe_abort_xol(struct arch_uprobe *aup, struct pt_regs *regs);
#endif /* _ASM_UPROBES_H */
diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
index e6f0331..ac90704 100644
--- a/include/linux/uprobes.h
+++ b/include/linux/uprobes.h
@@ -30,6 +30,7 @@
struct vm_area_struct;
struct mm_struct;
struct inode;
+struct notifier_block;
#ifdef CONFIG_ARCH_SUPPORTS_UPROBES
# include <asm/uprobes.h>
@@ -120,6 +121,13 @@ extern void uprobe_notify_resume(struct pt_regs *regs);
extern bool uprobe_deny_signal(void);
extern bool __weak arch_uprobe_skip_sstep(struct arch_uprobe *aup, struct pt_regs *regs);
extern void uprobe_clear_state(struct mm_struct *mm);
+extern void uprobe_reset_state(struct mm_struct *mm);
+extern int arch_uprobe_analyze_insn(struct arch_uprobe *aup, struct mm_struct *mm,unsigned long addr);
+extern int arch_uprobe_pre_xol(struct arch_uprobe *aup, struct pt_regs *regs);
+extern int arch_uprobe_post_xol(struct arch_uprobe *aup, struct pt_regs *regs);
+extern bool arch_uprobe_xol_was_trapped(struct task_struct *tsk);
+extern int arch_uprobe_exception_notify(struct notifier_block *self, unsigned long val, void *data);
+extern void arch_uprobe_abort_xol(struct arch_uprobe *aup, struct pt_regs *regs);
#else /* !CONFIG_UPROBES */
struct uprobes_state {
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/9] uprobes: check for single step support
From: Rabin Vincent @ 2012-10-14 19:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350242593-17761-1-git-send-email-rabin@rab.in>
Check for single step support before calling user_enable_single_step(),
since user_enable_single_step() just BUG()s if support does not exist.
Needed by ARM.
Signed-off-by: Rabin Vincent <rabin@rab.in>
---
kernel/events/uprobes.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 98256bc..db4e3ab 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1450,7 +1450,8 @@ static struct uprobe *find_active_uprobe(unsigned long bp_vaddr, int *is_swbp)
void __weak arch_uprobe_enable_step(struct arch_uprobe *arch)
{
- user_enable_single_step(current);
+ if (arch_has_single_step())
+ user_enable_single_step(current);
}
void __weak arch_uprobe_disable_step(struct arch_uprobe *arch)
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/9] uprobes: allow ignoring of probe hits
From: Rabin Vincent @ 2012-10-14 19:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350242593-17761-1-git-send-email-rabin@rab.in>
Allow arches to decided to ignore a probe hit. ARM will use this to
only call handlers if the conditions to execute a conditionally executed
instruction are satisfied.
Signed-off-by: Rabin Vincent <rabin@rab.in>
---
include/linux/uprobes.h | 1 +
kernel/events/uprobes.c | 14 +++++++++++++-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
index ac90704..da21b66 100644
--- a/include/linux/uprobes.h
+++ b/include/linux/uprobes.h
@@ -128,6 +128,7 @@ extern int arch_uprobe_post_xol(struct arch_uprobe *aup, struct pt_regs *regs);
extern bool arch_uprobe_xol_was_trapped(struct task_struct *tsk);
extern int arch_uprobe_exception_notify(struct notifier_block *self, unsigned long val, void *data);
extern void arch_uprobe_abort_xol(struct arch_uprobe *aup, struct pt_regs *regs);
+extern bool __weak arch_uprobe_ignore(struct arch_uprobe *aup, struct pt_regs *regs);
#else /* !CONFIG_UPROBES */
struct uprobes_state {
};
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index db4e3ab..a0e1a38 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1419,6 +1419,11 @@ static void mmf_recalc_uprobes(struct mm_struct *mm)
clear_bit(MMF_HAS_UPROBES, &mm->flags);
}
+bool __weak arch_uprobe_ignore(struct arch_uprobe *aup, struct pt_regs *regs)
+{
+ return false;
+}
+
static struct uprobe *find_active_uprobe(unsigned long bp_vaddr, int *is_swbp)
{
struct mm_struct *mm = current->mm;
@@ -1469,6 +1474,7 @@ static void handle_swbp(struct pt_regs *regs)
struct uprobe *uprobe;
unsigned long bp_vaddr;
int uninitialized_var(is_swbp);
+ bool ignored = false;
bp_vaddr = uprobe_get_swbp_addr(regs);
uprobe = find_active_uprobe(bp_vaddr, &is_swbp);
@@ -1499,6 +1505,12 @@ static void handle_swbp(struct pt_regs *regs)
goto cleanup_ret;
}
utask->active_uprobe = uprobe;
+
+ if (arch_uprobe_ignore(&uprobe->arch, regs)) {
+ ignored = true;
+ goto cleanup_ret;
+ }
+
handler_chain(uprobe, regs);
if (uprobe->flags & UPROBE_SKIP_SSTEP && can_skip_sstep(uprobe, regs))
goto cleanup_ret;
@@ -1514,7 +1526,7 @@ cleanup_ret:
utask->active_uprobe = NULL;
utask->state = UTASK_RUNNING;
}
- if (!(uprobe->flags & UPROBE_SKIP_SSTEP))
+ if (!ignored && !(uprobe->flags & UPROBE_SKIP_SSTEP))
/*
* cannot singlestep; cannot skip instruction;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 4/9] uprobes: allow arch access to xol slot
From: Rabin Vincent @ 2012-10-14 19:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350242593-17761-1-git-send-email-rabin@rab.in>
Allow arches to customize how the instruction is filled into the xol
slot. ARM will use this to insert an undefined instruction after the
real instruction in order to simulate a single step of the instruction
without hardware support.
Signed-off-by: Rabin Vincent <rabin@rab.in>
---
include/linux/uprobes.h | 1 +
kernel/events/uprobes.c | 7 ++++++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
index da21b66..b4380ad 100644
--- a/include/linux/uprobes.h
+++ b/include/linux/uprobes.h
@@ -129,6 +129,7 @@ extern bool arch_uprobe_xol_was_trapped(struct task_struct *tsk);
extern int arch_uprobe_exception_notify(struct notifier_block *self, unsigned long val, void *data);
extern void arch_uprobe_abort_xol(struct arch_uprobe *aup, struct pt_regs *regs);
extern bool __weak arch_uprobe_ignore(struct arch_uprobe *aup, struct pt_regs *regs);
+extern void __weak arch_uprobe_xol_copy(struct arch_uprobe *auprobe, void *vaddr);
#else /* !CONFIG_UPROBES */
struct uprobes_state {
};
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index a0e1a38..f7ff3a4 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1211,6 +1211,11 @@ static unsigned long xol_take_insn_slot(struct xol_area *area)
return slot_addr;
}
+void __weak arch_uprobe_xol_copy(struct arch_uprobe *auprobe, void *vaddr)
+{
+ memcpy(vaddr, auprobe->insn, MAX_UINSN_BYTES);
+}
+
/*
* xol_get_insn_slot - If was not allocated a slot, then
* allocate a slot.
@@ -1240,7 +1245,7 @@ static unsigned long xol_get_insn_slot(struct uprobe *uprobe, unsigned long slot
current->utask->vaddr = slot_addr;
offset = current->utask->xol_vaddr & ~PAGE_MASK;
vaddr = kmap_atomic(area->page);
- memcpy(vaddr + offset, uprobe->arch.insn, MAX_UINSN_BYTES);
+ arch_uprobe_xol_copy(&uprobe->arch, vaddr + offset);
kunmap_atomic(vaddr);
return current->utask->xol_vaddr;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 5/9] uprobes: allow arch-specific initialization
From: Rabin Vincent @ 2012-10-14 19:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350242593-17761-1-git-send-email-rabin@rab.in>
Add a weak function for any architecture-specific initialization. ARM
will use this to register the handlers for the undefined instructions it
uses to implement uprobes.
Signed-off-by: Rabin Vincent <rabin@rab.in>
---
include/linux/uprobes.h | 1 +
kernel/events/uprobes.c | 10 ++++++++++
2 files changed, 11 insertions(+)
diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
index b4380ad..c3dc5de 100644
--- a/include/linux/uprobes.h
+++ b/include/linux/uprobes.h
@@ -130,6 +130,7 @@ extern int arch_uprobe_exception_notify(struct notifier_block *self, unsigned l
extern void arch_uprobe_abort_xol(struct arch_uprobe *aup, struct pt_regs *regs);
extern bool __weak arch_uprobe_ignore(struct arch_uprobe *aup, struct pt_regs *regs);
extern void __weak arch_uprobe_xol_copy(struct arch_uprobe *auprobe, void *vaddr);
+extern int __weak arch_uprobes_init(void);
#else /* !CONFIG_UPROBES */
struct uprobes_state {
};
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index f7ff3a4..ca000a9 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1634,8 +1634,14 @@ static struct notifier_block uprobe_exception_nb = {
.priority = INT_MAX-1, /* notified after kprobes, kgdb */
};
+int __weak __init arch_uprobes_init(void)
+{
+ return 0;
+}
+
static int __init init_uprobes(void)
{
+ int ret;
int i;
for (i = 0; i < UPROBES_HASH_SZ; i++) {
@@ -1643,6 +1649,10 @@ static int __init init_uprobes(void)
mutex_init(&uprobes_mmap_mutex[i]);
}
+ ret = arch_uprobes_init();
+ if (ret)
+ return ret;
+
return register_die_notifier(&uprobe_exception_nb);
}
module_init(init_uprobes);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 6/9] uprobes: flush cache after xol write
From: Rabin Vincent @ 2012-10-14 19:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350242593-17761-1-git-send-email-rabin@rab.in>
Flush the cache so that the instructions written to the XOL area are
visible.
Signed-off-by: Rabin Vincent <rabin@rab.in>
---
kernel/events/uprobes.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index ca000a9..8c52f93 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1246,6 +1246,7 @@ static unsigned long xol_get_insn_slot(struct uprobe *uprobe, unsigned long slot
offset = current->utask->xol_vaddr & ~PAGE_MASK;
vaddr = kmap_atomic(area->page);
arch_uprobe_xol_copy(&uprobe->arch, vaddr + offset);
+ flush_dcache_page(area->page);
kunmap_atomic(vaddr);
return current->utask->xol_vaddr;
--
1.7.9.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox