linaro-kernel March 2011

linaro-kernel@lists.linaro.org

21 participants
50 discussions

[RFC] [PATCH 0/4] ARM: kprobes: Infrastructure to support probes in Thumb code

by Tixy

This patch series adds the infrastructure required to support kprobes in Thumb code. As it stands, it allows probes to be inserted onto NOP instructions. Work Remaining -------------- - Add decoding and emulation code for all the different Thumb instructions. - Make framework test for probes on conditionally executed instructions and not execute callback functions if the relevant condition isn't met. - Write test code for all Thumb and ARM instruction types. (Does Linux have in tree test code or do I need to stash this elsewhere?) Open Issue ---------- 32-bit Thumb breakpoints may straddle two memory words, which means that when we set or clear them there is a window of opportunity where another CPU may only see half of the new instruction and execute invalid code. To prevent this I've used stop_machine() to get all CPUs to synchronously modify the instruction and update their I-caches. To my thinking, something like this would also be needed so that other CPUs see the new instruction, otherwise they could indefinately be executing the old one from their local I-cache. The problem with using stop_machine() is that the breakpoint setting code is called from enable_kprobe() which holds the text_mutex and has this comment which says: since [the breakpoint setting code] doesn't use stop_machine(), this doesn't cause deadlock on text_mutex. So, we don't need get_online_cpus() Now I am using stop_machine() I need to understand what the consequences and alternatives are. I do note, that when probes are disabled, the existing ARM kprobe implementation uses stop_machine() and we have a similar issue with this being called from disarm_kprobe() which takes the text_mutex.

13 years, 1 month

[ACTIVITY] week 1111

by Mian Yousaf Kaukab

== m-y == === Highlights === * Patch set for DMA support in USB for U8500 was sent to linux-usb. No comments so far. * Patch set v2 is now in internal review. === Plans === * AB8500 USB transceiver power management * Bug # 709245. Thanks, -- Mian Yousaf Kaukab

13 years, 1 month

[ACTIVITY] (Arnd Bergmann) 2011-03-14 - 2011-03-18

by Arnd Bergmann

== Merge window status == * My final BKL patches were all merged. * unicore32 architecture was merged, I've spent a lot of time reviewing that in the past. == Kernel development == * Did a review of the IIO (industrial I/O) code in drivers/staging, from which an extensive discussion started * Reviewed arm vt8500 clock code and LPS001WP pressure sensor * and continued commenting on drivers I previously reviewed == Flash memory performance == * Incorporated new measurements from other people into survey * Updated wiki page

13 years, 1 month

[ACTIVITY] (Thomas Abraham) 2011-03-15 - 2011-03-21

by Thomas Abraham

== Device Tree == * Submitted a set of prerequisite patches for device tree support on s5pv310. (http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg04344.html) * Working on third version of the s5pv310 device tree patchset which uses of_platform_prepare and of_platform_populate

13 years, 1 month

[ACTIVITY] (Shawn Guo) 2011-03-14 - 2011-03-18

by Shawn Guo

== Device Tree == * Sent out the v2 of mx51-platform-dt-clock * Studied and tested Grant's preregister branch on babbage board * Sent out sdhci-device-self-registration patch set for review == Misc == * Prepare document for Hungary VISA application -- Regards, Shawn

13 years, 1 month

[ACTIVITY] (Per Forlin) 2011-03-14 - 2011-03-18

by Per Forlin

== Storage performance mmc async liability == * Added basic fault generation in core.c, using fault injection framework, to trigger error handling in the mmc async block device implementation * Run DT (http://www.scsifaq.org/RMiller_Tools/dt.html) on top of a vanilla kernel with the fault generation successfully. Next step if to run this on mmc async and fix bugs. When stable I will rebase on 2.6.39 and post patches. == absence == 2,5 days last week due to child sickness === planned absence === No sickness in sight yet

13 years, 1 month

[ACTIVITY] (Dave Martin) 2011-03-14 - 2011-03-18

by Dave Martin

== Dave Martin <dmart> == === Activity === ==== hardware-n-kernel-standard-architecture ==== * Some discussion with Tixy about the proposed Thumb-2 kprobes work. ==== miscellaneous ==== * Holiday * Some time spent dealing with ARM internal issues. === Plans === * Post an RFC proposal for adding the NEON/VFP state in coredumps. * Try and reflash U-Boot on the validation lab u8500 boards. * Set up the remaining Freescale boards in validation lab. * Write up the output from the Freescale i.MX BSP review discussion, and post for comment. === Issues === * (none) === Absences === * (none)

13 years, 1 month

Re: KProbes for thumb2

by Tixy

CC'ing linaro-kernel(a)lists.linaro.org and dropping other CC's... On Fri, 2011-03-18 at 13:20 +0000, Dave Martin wrote: > On Fri, Mar 18, 2011 at 7:18 AM, Tixy <tixy(a)yxit.co.uk> wrote: > > On Thu, 2011-03-17 at 19:08 -0400, Nicolas Pitre wrote: > >> On Thu, 17 Mar 2011, Tixy wrote: > > [...] > >> > I also have the first draft of a test framework so I can start working > >> > on on implementing emulation code for the rest of the Thumb > >> > instruction set, that could take a while longer ;-) (I plan on adding > >> > test cases for the current ARM instruction simulation as well). > >> > >> Hmmm... How are you doing that? To me this always seemed to be as hard > >> to make such test framework error free as ensuring that the tested code > >> is itself error free in the first place. > > > > True, but hopefully the bugs in each won't usually cancel each other out > > and lead to false test passes. Any way, I need some test code otherwise > > I won't have a simple way of exercising the emulation code I write. > > > > The testing method I hit upon was this: > > > > probe_before: > > nop; > > probe_test: > > add r0, r1, r2 > > probe_after: > > nop; > > > > Pass 1: > > - Insert probe_before and probe_after > > - Run code > > - When handler 'before' runs, modify register context with test values > > - When handler 'after' runs, save register context > > > > Pass 2: > > - Insert probe_test > > - Do same as Pass 1 > > - Verify saved register context is identical to Pass 1. > > > > I do the above two passes twice, the second time with CPSR inverted and > > with the registers not used by the tested instruction also inverted (to > > more robustly detect if they accidentally get corrupted). > > > > I plan on doubling up the passes as well to add setting an IT State, as > > some instructions behave different in an IT block by not modifying CPSR. > > > > I'll have to add support for testing LDR, STR and friends, plus anything > > else as needed. > > I feel that it's important to get some initial, incomplete > implementation patches out for review as soon as feasible, since that > gives people the best opportunity to comment or express any concerns > on the implementation strategy. I'll aim to post a patch to linaro-kernel by Monday which will have the Thumb NOP probing work. It'll act as a catalyst for discussing issues and coding decisions. I'm new to git and patches, so I'll do some tests with creating local branches and emailing patches to myself first :-) I won't post the test code yet as that is very much work in progress, though for anyone curious I put it at http://tixy.me.uk/kprobe-test.c (I knew I would eventually find a use for the Web server I put on my Sheevaplug :-) > > The testing ideas look like a good start. Can the framework be > applied to ARM as well as Thumb? It looks at first glance like it > can, and it would be good to cover the ARM case in the testing if > there's no test framework already. Should work with ARM as well with some small tweaking. > Branch-like instructions are an interesting case, since these often > occur as specific encodings of otherwise non-branch-like instructions > (for example, LDR, LDM/POP, MOV{S} etc.) For branches, test code would need an extra probe at the branch target (and one at the instruction before to trap miscalculated branches.) But writing test code is probably a lot less work than actually writing the simulation code in the kprobe implementation. That has to cope with all the different instruction types, the test framework would just needs one or two test types implementing. > Coming up with all the appropriate test cases could be quite a bit of > work too, since there is not the same level or orthogonality in the > instruction set encoding as you get with ARM. Again, I think this is more of a problem for the implementation of kprobes, not the test cases. For Thumb, we do have some factors making it simpler that appears at first sight though... For 16-bit instructions there are whole swathes of instructions which only operation on low registers. These can all use the same simulation code which just restores r0-r7,cpsr, executes the original instruction, then saves r0-r7,cpsr again. (I realised this after writing my first half dozen simulation functions :-) For 32-bit instructions, many of the operations on PC are illegal or Undefined behaviour; so we can probably get away with ignoring these cases. Cheers -- Tixy

13 years, 1 month

Including a MMC patch in the Linaro kernel

by Matt Waddel

Hi Nicholas, Pawel Moll submitted a patch to linux-arm-kernel and the linux-mmc mailing lists to improve the Versatile Express MMC problem (Launch pad bug #632798). I have tried this fix on my vexpress and it does improve the mmc throughput. Can we pull this patch into the current Linaro kernel? http://permalink.gmane.org/gmane.linux.kernel.mmc/6634 Thanks, Matt

13 years, 1 month

Fw: Re: LDS - Candidate list for Sponsorship (travel paid) (mgt@linaro.org)

by Paul E. McKenney

Hello! Any nominations for invitations to LDS in May? Thanx, Paul ----- Forwarded message from Michael Opdenacker <michael.opdenacker(a)linaro.org> ----- Date: Wed, 09 Mar 2011 22:15:18 +0100 From: Michael Opdenacker <michael.opdenacker(a)linaro.org> To: techleads(a)linaro.org CC: Rob Coombs <rob.coombs(a)linaro.org>, Stephen Doel <stephen.doel(a)linaro.org>, mgt(a)linaro.org, asac(a)linaro.org Subject: Re: LDS - Candidate list for Sponsorship (travel paid) (mgt(a)linaro.org) Organization: Linaro Hi tech leads, Did you have time about who you would like to invite at LDS, and if needed, pay for their costs? I added some suggestions about people who could be interesting to lock with us for 5 days. I'm not only thinking about people from the mainstream projects we contribute to, but also about open-source projects who use or could use our deliverables. See the shared document and the notes I added: https://spreadsheets.google.com/a/linaro.org/ccc?key=0AjOUcebQ3tSidHhqdzdyb… <https://spreadsheets.google.com/a/linaro.org/ccc?key=0AjOUcebQ3tSidHhqdzdyb…> These were just suggestions. You decide who you would like to invite in our working groups. Thank you in advance, Cheers, Michael. On 02/08/2011 10:05 AM, Rob Coombs wrote: > Hi Stephen, > > We already have a shared document > https://spreadsheets.google.com/a/linaro.org/ccc?key=0AjOUcebQ3tSidHhqdzdyb… > <https://spreadsheets.google.com/a/linaro.org/ccc?key=0AjOUcebQ3tSidHhqdzdyb…> > > Please continue to edit this. > > Thanks, > > Rob > > On 8 February 2011 06:14, Stephen Doel <stephen.doel(a)linaro.org > <mailto:stephen.doel@linaro.org>> wrote: > > Hi All, > > This list is to gather together candidates from a) the Linux > community and b) key corporate accounts & relationships. > > Please can you help build the list so we can start the > invitations. We're looking to sponsor around 10 people again, as > an example attached is the list from Florida. > > I expect we'd want to start arranging invites from 21 February, so > input before then please. > > Stephen > > > On 2 February 2011 14:27, <rob.coombs(a)linaro.org > <mailto:rob.coombs@linaro.org>> wrote: > > I've shared LDS - Candidate list for Sponsorship (travel > paid) > <https://spreadsheets.google.com/a/linaro.org/ccc?key=0AjOUcebQ3tSidHhqdzdyb…> > > > Message from rob.coombs(a)linaro.org > <mailto:rob.coombs@linaro.org>: > > Please add possible candidate names for sponsoring travel costs to LDS in May. > > > Click to open: > > * LDS - Candidate list for Sponsorship (travel paid) > <https://spreadsheets.google.com/a/linaro.org/ccc?key=0AjOUcebQ3tSidHhqdzdyb…> > > > Google Docs makes it easy to create, store and share online > documents, spreadsheets and presentations. > Logo for Google Docs <https://docs.google.com/a/linaro.org> > > > > > -- > Thx > > Stephen Doel > Linaro Ltd > Chief Operating Officer > +44 77 66 014 247 > > > > > -- > ========================== > Rob Coombs - Head of Global Alliances > Linaro > Liberty House, > Moorbridge Rd, > Maidenhead > Berkshire SL6 8LT > Direct: +44 (0) 1628 427794 > Mobile: +44 (0) 7747801576 > Email: rob.coombs(a)linaro.org <mailto:rob.coombs@linaro.org> > www.linaro.org <http://www.linaro.org> > -- Michael Opdenacker - Community Manager Linaro, http://linaro.org Cell: +33 621 604 642 IRC: 'opm' in #linaro on irc.freenode.net ----- End forwarded message -----

13 years, 1 month

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

linaro-kernel March 2011