From mboxrd@z Thu Jan 1 00:00:00 1970 From: oleg@redhat.com (Oleg Nesterov) Date: Tue, 15 Apr 2014 19:49:00 +0200 Subject: [RFC PATCH] uprobes: copy to user-space xol page with proper cache flushing In-Reply-To: <20140415.133840.2270952586596479547.davem@davemloft.net> References: <20140415154637.GA3560@redhat.com> <534D6A1F.70102@linaro.org> <20140415.133840.2270952586596479547.davem@davemloft.net> Message-ID: <20140415174900.GA11184@redhat.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 04/15, David Miller wrote: > > From: David Long > Date: Tue, 15 Apr 2014 13:19:27 -0400 > > > On 04/15/14 11:46, Oleg Nesterov wrote: > >> > >> But. Please do not add copy_to_user_page() into copy_to_page() (as your patch > >> did). This is certainly not what uprobe_write_opcode() wants, we do not want > >> or need "flush" in this case. The same for __create_xol_area(). > >> > > > > It looked me like a call to a new __copy_to_user_page(current->mm, ...) in xol_get_insn_slot() > > would be in line with David Miller's suggestion and would cure the problem on ARM (and hopefuly > > be more philosophically correct for all architectures): > > It occurs to me that because of the specific environment in which this > executes we can make the interface take advantage of the invariants at > this call site: > > 1) We are copying into userspace and thus current->mm > > 2) We are only storing an instruction or two Not sure this can help, but also 3) nobody else will even read/execute this peace of memory > Furthermore, we can do the stores using something akin to put_user(), > directly store them into userspace. > > This avoids completely any D-cache aliasing issues. The kernel stores > to the same address, and therefore the same cache lines, as userspace > would. Heh. Of course I thought about this. This can not work afaics. We do not want to write to, say, page cache if the probed application mmaps a file at the same vaddr. Oleg.