On fre, 2014-08-15 at 13:01 +0200, Ralf Baechle wrote: > On Fri, Aug 15, 2014 at 10:03:47AM +0200, Lars Persson wrote: > > > > > On fre, 2014-08-08 at 22:47 +0200, Ralf Baechle wrote: > > > On Fri, Aug 08, 2014 at 09:55:00AM -0700, David Daney wrote: > > > > > > > >+static inline void set_pte_at(struct mm_struct *mm, unsigned long addr, > > > > >+ pte_t *ptep, pte_t pteval); > > > > >+ > > > > > > > > Is it possible to reorder the code such that this declaration is not > > > > necessary? > > > > > > That's not as obvious as one might think initially. set_pte_at needs > > > to be defined after set_pte but before clear_pte which is calling set_pte_at. > > > > > > Of both set_pte and clear_pte there are two #ifdefd variants. > > > > > > set_pte_at is a fairly small function only but it's invoked quite a few > > > times so I was a little concerned about the effect on I'm experimenting with > > > outlining set_pte_at entirely. ip22_defconfig with the patch applied as > > > posted; this is the effect on code size. > > > > > > text data bss dec hex filename > > > 3790118 175304 84544 4049966 3dcc2e vmlinux as posted > > > 3789062 175304 84544 4048910 3dc80e vmlinux set_pte_at outlined > > > > > > Ralf > > > > Hi Ralf > > > > Should I update the patch with outlined set_pte_at ? > > Not necessary; I've already done that myself. I was just waiting for > comments. > > Thanks for your work on tracking this down. I wonder, how did you discover > this issue? This one was tricky to track down. We had sporadic SIGILLs in multi-threaded apps for a long time. Eventually we got a test case that triggered more page cache evictions and the frequency of SIGILLs increased enough to catch it with a JTAG debugger. Kernel call stacks showed one thread handling an illegal instruction exception while another thread was somewhere around the set_pte_at/update_mmu_cache calls for the same page. BR, Lars
