From patchwork Sat Aug 17 04:35:44 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ian Lance Taylor X-Patchwork-Id: 1148573 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-507177-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=golang.org Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="K7TcmG5s"; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=golang-org.20150623.gappssmtp.com header.i=@golang-org.20150623.gappssmtp.com header.b="vbdaNNHv"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 469S7H3pcBz9s3Z for ; Sat, 17 Aug 2019 14:36:08 +1000 (AEST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:from:date:message-id:subject:to:content-type; q= dns; s=default; b=yC6CkLdhKgW6NqAI+BXeLKEOLrHlpdg2OSPzvHwH9wynvF ML0i/BdgogpDNnDHdUgUkrNyP6t3CiYqZEerPpjQkOAfVzoFrlkYzUUIIaHPWjxi 1dl29exdf3fQmLzAPBZaYt2etENJzeLZb4g7G4YyBJXGy4JP5ssSZiS9+G04k= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:from:date:message-id:subject:to:content-type; s= default; bh=VRJG8c4Q77w28UEivw44Ckk6C/U=; b=K7TcmG5s0delb3hUjGm/ jTgO9Mon2C0Ooo9sUZvZ4Bx71nhpfWdyn3UutHTd+pU4BOIp17kWqfIIyMDVOLPy wyW/MN/9/zcoNtVPTturmI+KTtj9mhyCdlj0btimJpGwMBP4PBZqc6Vt2kOw4+tH gezeD8thIaXjM8yEplI9o9Y= Received: (qmail 113201 invoked by alias); 17 Aug 2019 04:36:00 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 113191 invoked by uid 89); 17 Aug 2019 04:36:00 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-10.7 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3, KAM_ASCII_DIVIDERS, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mail-lf1-f50.google.com Received: from mail-lf1-f50.google.com (HELO mail-lf1-f50.google.com) (209.85.167.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 17 Aug 2019 04:35:59 +0000 Received: by mail-lf1-f50.google.com with SMTP id b29so5421481lfq.1 for ; Fri, 16 Aug 2019 21:35:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=golang-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=/Qc09KXaw4DiMpsXFKaIL+L1GTMG4uKJKyd9CludHpA=; b=vbdaNNHvBJKb1dv2TMBKYfqWlGToxCrQuGliADpanTwjlBO7DcGtX0dDWxyB/MADCI W+Z410aiAC2dkpbZ94jK/zO0lY+DCwtqSQ7fuDwxqV4eQLymlzfXAazGcsKlMdrIPi+Q kfNEGOTVnrLHUdU2ZfFjK24btpJFelLJtpbYZ9fOATi709/YaIULiFPPnrffdSdO7BZq gmQvPfQWapOb+jxVNNy8GRLIIbrfLy4nJLoSEXVe7JjuWBgIKBZtAzXLqX3CHxNlWcqJ /kToVq+0W+HHwEqfRT/4m0MyeI7KwXufoUvKHn/73CIREszt4isIWY56RSY+wCW57hz1 9crw== MIME-Version: 1.0 From: Ian Lance Taylor Date: Fri, 16 Aug 2019 21:35:44 -0700 Message-ID: Subject: libgo patch committed: Scan write barrier buffer conservatively To: gcc-patches , gofrontend-dev This libgo patch by Cherry Zhang scans the write barrier buffer conservatively. In gccgo, we insert the write barriers in the frontend, and so we cannot completely prevent write barriers on stack writes. So it is possible for a bad pointer appearing in the write barrier buffer. When flushing the write barrier, treat it the same as scanning the stack. In particular, don't mark a pointer if it does not point to an allocated object. We already have similar logic in greyobject. With this, hopefully, we can prevent an unallocated object from being marked completely. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline. Ian Index: gcc/go/gofrontend/MERGE =================================================================== --- gcc/go/gofrontend/MERGE (revision 274591) +++ gcc/go/gofrontend/MERGE (working copy) @@ -1,4 +1,4 @@ -0f6d673d5b1a3474c3424cb6994ae8ff9baed255 +838f926c93898767f0337122725a4f52a1335186 The first line of this file holds the git revision number of the last merge done from the gofrontend repository. Index: libgo/go/runtime/mwbbuf.go =================================================================== --- libgo/go/runtime/mwbbuf.go (revision 274169) +++ libgo/go/runtime/mwbbuf.go (working copy) @@ -285,10 +285,17 @@ func wbBufFlush1(_p_ *p) { // path to reduce the rate of flushes? continue } - obj, span, objIndex := findObject(ptr, 0, 0, false) + obj, span, objIndex := findObject(ptr, 0, 0, !usestackmaps) if obj == 0 { continue } + if span.isFree(objIndex) { + // For gccgo, it is possible that we have a write barrier + // writing to unintialized stack memory. So we could see + // a bad pointer in the write barrier buffer. Don't mark + // it in this case. + continue + } // TODO: Consider making two passes where the first // just prefetches the mark bits. mbits := span.markBitsForIndex(objIndex)