Received: by 10.223.185.116 with SMTP id b49csp2394344wrg; Mon, 12 Feb 2018 08:52:59 -0800 (PST) X-Google-Smtp-Source: AH8x227exTwnw0TuZaZuRRXsxmLVk3BUrzqLkRzFwsD06sU8RjfbbV0PoOOdpmqi+Qeu8pOf8ZRE X-Received: by 2002:a17:902:e65:: with SMTP id 92-v6mr11491423plw.148.1518454379752; Mon, 12 Feb 2018 08:52:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518454379; cv=none; d=google.com; s=arc-20160816; b=sAS2pyQaT1CHuJNjW312E963lnJMk406RHC/V3DhMyqYoLm87DHjv0Hr1OLcHCW5UX Mpgkf2+rVbkFYVL6/HnJlAgNr+lrvPlN8lklEeDo+5zkz+REVm/N09HhDreLhbPnwNrn fjEi6b9JadBAavHkItJvVEe5lAhr8CbNjH8jCOzqwMEPkhFiJUe0SdZPqi/Oz+O6ZQXz XtwXw0rT/dPc/JjF5/yTeeCBgL5rZtYMhmEXwSjyc4+BiDqjT1ZwLbN47xJa7gRFW6UY fWoqWg/+y8xEpW6mDYARGsGnBpCfvQ+vvPL1iFCAzYRZwYbmVm6yhD9jjZCN/d68mW7o P4oA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:content-language :content-transfer-encoding:mime-version:user-agent:date:subject:from :cc:to:arc-authentication-results; bh=EapH1MbhYVcueJc/nm8U+y1k5tpPT+bnJol13a37p6Q=; b=VtpvPhMrvoFhC9rQR0yx00fzDg+I2oF61VDy7SvyWIpjRHZ5v55huO/8zQyZlCkVqa 0KRUOiQbbqa4kPhUWjS3QQVr/GODFFBInrXrlk5+but0kgMZ1l0fDrw0YN5dpe7QtSgA svlbb2RCPRZFYdYIRFT7or3ILCji8/pze68ARopsb1PTwh0qt7d9t5KGoo33W0uhCEV8 0BDlw3cuqUGK6aYmNbPdeHN690O8870Rb9UuoU2pz/Z4lrrSyzNTpblIFzhcsuAUQCbQ Swwi4Oq6x44PiwDY2Mk412zRM0L6vMWtWzUzs61nM65XO2fJCnw5H0003P1iPWdPiW1v /GyQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e14si513180pgu.306.2018.02.12.08.52.44; Mon, 12 Feb 2018 08:52:59 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935205AbeBLNOg (ORCPT + 99 others); Mon, 12 Feb 2018 08:14:36 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:51742 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933655AbeBLNOd (ORCPT ); Mon, 12 Feb 2018 08:14:33 -0500 Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1CDEKu9035734 for ; Mon, 12 Feb 2018 08:14:33 -0500 Received: from e06smtp12.uk.ibm.com (e06smtp12.uk.ibm.com [195.75.94.108]) by mx0a-001b2d01.pphosted.com with ESMTP id 2g39cmn9we-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Mon, 12 Feb 2018 08:14:33 -0500 Received: from localhost by e06smtp12.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 12 Feb 2018 13:14:17 -0000 Received: from b06cxnps4076.portsmouth.uk.ibm.com (9.149.109.198) by e06smtp12.uk.ibm.com (192.168.101.142) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 12 Feb 2018 13:14:15 -0000 Received: from d06av24.portsmouth.uk.ibm.com (d06av24.portsmouth.uk.ibm.com [9.149.105.60]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w1CDEF5548431346; Mon, 12 Feb 2018 13:14:15 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D8E8342042; Mon, 12 Feb 2018 13:07:04 +0000 (GMT) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0BAD942041; Mon, 12 Feb 2018 13:07:03 +0000 (GMT) Received: from [9.195.47.73] (unknown [9.195.47.73]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTP; Mon, 12 Feb 2018 13:07:02 +0000 (GMT) To: Oleg Nesterov Cc: Srikar Dronamraju , "Naveen N. Rao" , ananth@linux.vnet.ibm.com, lkml From: Ravi Bangoria Subject: Uprobe: Bug(?) when probing small binaries Date: Mon, 12 Feb 2018 18:46:06 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-TM-AS-GCONF: 00 x-cbid: 18021213-0008-0000-0000-000004CBE7BD X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18021213-0009-0000-0000-00001E5FA53F Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-02-12_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1802120171 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Oleg, I'm observing a bug in the uprobe infrastructure. When target binary is quite small, uprobe replaces 'trap' instruction at two different places. Ex, Simple test.c that loops for 100 seconds:     void main()     {         int i = 0;             while (i++ != 100) {             printf("hi: %d", i);             sleep(1);         }     } Add a probe on function main() in test.c   $ perf probe -x ./a.out main     Added new event:       probe_a:main          (on main in /home/ravi/a.out) Start the target program and pause it.   $ gdb --args ./a.out     (gdb) r     main: 1     main: 2     ^C   (gdb) disassemble main        0x000000001000069c <+8>:    mflr    r0     (gdb) x/w 0x1001069c     0x1001069c:    2080899750 Now enable the probe:   # echo 1 > events/probe_a/main/enable Check probed instruction:   (gdb) disassemble main        0x000000001000069c <+8>:    trap *Bug*:   (gdb) x/w 0x1001069c     0x1001069c:  2145386504 In short, when it replaces the probe instruction, it does some corruption in the readonly vma. This seems to be a bug. How did I get the other address 0x1001069c?I found build_map_info() returns these two vmas for the single probe:   10000000-10010000 r-xp 00000000 08:05 67325595   /home/ravi/a.out   10010000-10020000 r--p 00000000 08:05 67325595   /home/ravi/a.out and thusregister_for_each_vmas() calls install_breakpoint() on both of thesevmas with different vaddr. The example is on powerpc but same issue is observed on x86 as well. As, the code is common, it should be reproducible on every architecture. Also, I don't observe this issue for bigger binaries (maybe for those whose vma spans across multiple pages). Thanks, Ravi