Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754875AbeALKwF (ORCPT + 1 other); Fri, 12 Jan 2018 05:52:05 -0500 Received: from mx1.redhat.com ([209.132.183.28]:58044 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754555AbeALKwE (ORCPT ); Fri, 12 Jan 2018 05:52:04 -0500 Date: Fri, 12 Jan 2018 11:52:00 +0100 From: Jiri Olsa To: "Liang, Kan" Cc: "acme@kernel.org" , "peterz@infradead.org" , "mingo@redhat.com" , "linux-kernel@vger.kernel.org" , "wangnan0@huawei.com" , "jolsa@kernel.org" , "namhyung@kernel.org" , "ak@linux.intel.com" , "yao.jin@linux.intel.com" Subject: Re: [PATCH V3 02/12] perf mmap: factor out function to find ringbuffer position Message-ID: <20180112105200.GA24958@krava> References: <1513879734-237492-1-git-send-email-kan.liang@intel.com> <1513879734-237492-3-git-send-email-kan.liang@intel.com> <20180111142520.GA16655@krava> <37D7C6CF3E00A74B8858931C1DB2F077537FFBDE@SHSMSX103.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37D7C6CF3E00A74B8858931C1DB2F077537FFBDE@SHSMSX103.ccr.corp.intel.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Fri, 12 Jan 2018 10:52:04 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Thu, Jan 11, 2018 at 09:26:28PM +0000, Liang, Kan wrote: > > > On Thu, Dec 21, 2017 at 10:08:44AM -0800, kan.liang@intel.com wrote: > > > > SNIP > > > > > +/* > > > + * Report the start and end of the available data in ringbuffer > > > + */ > > > +int perf_mmap__read_init(struct perf_mmap *map, bool overwrite, > > > + u64 *start, u64 *end) > > > { > > > - u64 head = perf_mmap__read_head(md); > > > - u64 old = md->prev; > > > - u64 end = head, start = old; > > > - unsigned char *data = md->base + page_size; > > > + u64 head = perf_mmap__read_head(map); > > > + u64 old = map->prev; > > > + unsigned char *data = map->base + page_size; > > > unsigned long size; > > > - void *buf; > > > - int rc = 0; > > > > > > - start = overwrite ? head : old; > > > - end = overwrite ? old : head; > > > + /* > > > + * Check if event was unmapped due to a POLLHUP/POLLERR. > > > + */ > > > + if (!refcount_read(&map->refcnt)) > > > + return -EINVAL; > > > > > > - if (start == end) > > > - return 0; > > > + *start = overwrite ? head : old; > > > + *end = overwrite ? old : head; > > > > > > - size = end - start; > > > - if (size > (unsigned long)(md->mask) + 1) { > > > + if (*start == *end) > > > + return -EAGAIN; > > > + > > > + size = *end - *start; > > > + if (size > (unsigned long)(map->mask) + 1) { > > > if (!overwrite) { > > > WARN_ONCE(1, "failed to keep up with mmap data. > > (warn only once)\n"); > > > > > > > I know you did not change this, but is this leg even possible > > in !overwrite mode? I think kernel will throw away the data, > > keep the head and wait for tail to be read by user.. > > Right, it should not happen in !overwrite mode. I guess it's just > sanity check. > It should not bring any problems. > I think I will still keep it for V4 if no objection? ok jirka