* [PATCH v2 13/15] pack-bitmap: implement BLOB_NONE filtering
From: Jeff King @ 2020-02-14 18:22 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <20200214182147.GA654525@coredump.intra.peff.net>
We can easily support BLOB_NONE filters with bitmaps. Since we know the
types of all of the objects, we just need to clear the result bits of
any blobs.
Note two subtleties in the implementation (which I also called out in
comments):
- we have to include any blobs that were specifically asked for (and
not reached through graph traversal) to match the non-bitmap version
- we have to handle in-pack and "ext_index" objects separately.
Arguably prepare_bitmap_walk() could be adding these ext_index
objects to the type bitmaps. But it doesn't for now, so let's match
the rest of the bitmap code here (it probably wouldn't be an
efficiency improvement to do so since the cost of extending those
bitmaps is about the same as our loop here, but it might make the
code a bit simpler).
Here are perf results for the new test on git.git:
Test HEAD^ HEAD
--------------------------------------------------------------------------------
5310.9: rev-list count with blob:none 1.67(1.62+0.05) 0.22(0.21+0.02) -86.8%
Signed-off-by: Jeff King <peff@peff.net>
---
pack-bitmap.c | 74 ++++++++++++++++++++++++++++++
t/perf/p5310-pack-bitmaps.sh | 5 ++
t/t6113-rev-list-bitmap-filters.sh | 14 ++++++
3 files changed, 93 insertions(+)
diff --git a/pack-bitmap.c b/pack-bitmap.c
index 48c8694f92..dcf8a9aadf 100644
--- a/pack-bitmap.c
+++ b/pack-bitmap.c
@@ -712,6 +712,73 @@ static int in_bitmapped_pack(struct bitmap_index *bitmap_git,
return 0;
}
+static struct bitmap *find_tip_blobs(struct bitmap_index *bitmap_git,
+ struct object_list *tip_objects)
+{
+ struct bitmap *result = bitmap_new();
+ struct object_list *p;
+
+ for (p = tip_objects; p; p = p->next) {
+ int pos;
+
+ if (p->item->type != OBJ_BLOB)
+ continue;
+
+ pos = bitmap_position(bitmap_git, &p->item->oid);
+ if (pos < 0)
+ continue;
+
+ bitmap_set(result, pos);
+ }
+
+ return result;
+}
+
+static void filter_bitmap_blob_none(struct bitmap_index *bitmap_git,
+ struct object_list *tip_objects,
+ struct bitmap *to_filter)
+{
+ struct eindex *eindex = &bitmap_git->ext_index;
+ struct bitmap *tips;
+ struct ewah_iterator it;
+ eword_t mask;
+ uint32_t i;
+
+ /*
+ * The non-bitmap version of this filter never removes
+ * blobs which the other side specifically asked for,
+ * so we must match that behavior.
+ */
+ tips = find_tip_blobs(bitmap_git, tip_objects);
+
+ /*
+ * We can use the blob type-bitmap to work in whole words
+ * for the objects that are actually in the bitmapped packfile.
+ */
+ for (i = 0, init_type_iterator(&it, bitmap_git, OBJ_BLOB);
+ i < to_filter->word_alloc && ewah_iterator_next(&mask, &it);
+ i++) {
+ if (i < tips->word_alloc)
+ mask &= ~tips->words[i];
+ to_filter->words[i] &= ~mask;
+ }
+
+ /*
+ * Clear any blobs that weren't in the packfile (and so would not have
+ * been caught by the loop above. We'll have to check them
+ * individually.
+ */
+ for (i = 0; i < eindex->count; i++) {
+ uint32_t pos = i + bitmap_git->pack->num_objects;
+ if (eindex->objects[i]->type == OBJ_BLOB &&
+ bitmap_get(to_filter, pos) &&
+ !bitmap_get(tips, pos))
+ bitmap_unset(to_filter, pos);
+ }
+
+ bitmap_free(tips);
+}
+
static int filter_bitmap(struct bitmap_index *bitmap_git,
struct object_list *tip_objects,
struct bitmap *to_filter,
@@ -720,6 +787,13 @@ static int filter_bitmap(struct bitmap_index *bitmap_git,
if (!filter || filter->choice == LOFC_DISABLED)
return 0;
+ if (filter->choice == LOFC_BLOB_NONE) {
+ if (bitmap_git)
+ filter_bitmap_blob_none(bitmap_git, tip_objects,
+ to_filter);
+ return 0;
+ }
+
/* filter choice not handled */
return -1;
}
diff --git a/t/perf/p5310-pack-bitmaps.sh b/t/perf/p5310-pack-bitmaps.sh
index e52f66ec9e..936742314c 100755
--- a/t/perf/p5310-pack-bitmaps.sh
+++ b/t/perf/p5310-pack-bitmaps.sh
@@ -47,6 +47,11 @@ test_perf 'rev-list (objects)' '
git rev-list --all --use-bitmap-index --objects >/dev/null
'
+test_perf 'rev-list count with blob:none' '
+ git rev-list --use-bitmap-index --count --objects --all \
+ --filter=blob:none >/dev/null
+'
+
test_expect_success 'create partial bitmap state' '
# pick a commit to represent the repo tip in the past
cutoff=$(git rev-list HEAD~100 -1) &&
diff --git a/t/t6113-rev-list-bitmap-filters.sh b/t/t6113-rev-list-bitmap-filters.sh
index 977f8d0930..f4e6d582f0 100755
--- a/t/t6113-rev-list-bitmap-filters.sh
+++ b/t/t6113-rev-list-bitmap-filters.sh
@@ -21,4 +21,18 @@ test_expect_success 'filters fallback to non-bitmap traversal' '
test_cmp expect actual
'
+test_expect_success 'blob:none filter' '
+ git rev-list --objects --filter=blob:none HEAD >expect &&
+ git rev-list --use-bitmap-index \
+ --objects --filter=blob:none HEAD >actual &&
+ test_bitmap_traversal expect actual
+'
+
+test_expect_success 'blob:none filter with specified blob' '
+ git rev-list --objects --filter=blob:none HEAD HEAD:two.t >expect &&
+ git rev-list --use-bitmap-index \
+ --objects --filter=blob:none HEAD HEAD:two.t >actual &&
+ test_bitmap_traversal expect actual
+'
+
test_done
--
2.25.0.796.gcc29325708
^ permalink raw reply related
* [PATCH AUTOSEL 5.5 025/542] dmaengine: ti: edma: Fix error return code in edma_probe()
From: Sasha Levin @ 2020-02-14 15:40 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Wei Yongjun, Peter Ujfalusi, Vinod Koul, Sasha Levin, dmaengine
In-Reply-To: <20200214154854.6746-1-sashal@kernel.org>
From: Wei Yongjun <weiyongjun1@huawei.com>
[ Upstream commit d1fd03a35efc6285e43f4ef35ef04dbf2c9389c6 ]
Fix to return negative error code -ENOMEM from the error handling
case instead of 0, as done elsewhere in this function.
Fixes: 2a03c1314506 ("dmaengine: ti: edma: add missed operations")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/20191212114622.127322-1-weiyongjun1@huawei.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/dma/ti/edma.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/ti/edma.c b/drivers/dma/ti/edma.c
index 0628ee4bf1b41..03a7f647f7b2c 100644
--- a/drivers/dma/ti/edma.c
+++ b/drivers/dma/ti/edma.c
@@ -2342,8 +2342,10 @@ static int edma_probe(struct platform_device *pdev)
ecc->channels_mask = devm_kcalloc(dev,
BITS_TO_LONGS(ecc->num_channels),
sizeof(unsigned long), GFP_KERNEL);
- if (!ecc->slave_chans || !ecc->slot_inuse || !ecc->channels_mask)
+ if (!ecc->slave_chans || !ecc->slot_inuse || !ecc->channels_mask) {
+ ret = -ENOMEM;
goto err_disable_pm;
+ }
/* Mark all channels available initially */
bitmap_fill(ecc->channels_mask, ecc->num_channels);
--
2.20.1
^ permalink raw reply related
* [PATCH v2 14/15] pack-bitmap: implement BLOB_LIMIT filtering
From: Jeff King @ 2020-02-14 18:22 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <20200214182147.GA654525@coredump.intra.peff.net>
Just as the previous commit implemented BLOB_NONE, we can support
BLOB_LIMIT filters by looking at the sizes of any blobs in the result
and unsetting their bits as appropriate. This is slightly more expensive
than BLOB_NONE, but still produces a noticeable speedup (these results
are on git.git):
Test HEAD~2 HEAD
------------------------------------------------------------------------------------
5310.9: rev-list count with blob:none 1.80(1.77+0.02) 0.22(0.20+0.02) -87.8%
5310.10: rev-list count with blob:limit=1k 1.99(1.96+0.03) 0.29(0.25+0.03) -85.4%
The implementation is similar to the BLOB_NONE one, with the exception
that we have to go object-by-object while walking the blob-type bitmap
(since we can't mask out the matches, but must look up the size
individually for each blob). The trick with using ctz64() is taken from
show_objects_for_type(), which likewise needs to find individual bits
(but wants to quickly skip over big chunks without blobs).
Signed-off-by: Jeff King <peff@peff.net>
---
pack-bitmap.c | 80 ++++++++++++++++++++++++++++++
t/perf/p5310-pack-bitmaps.sh | 5 ++
t/t6113-rev-list-bitmap-filters.sh | 20 +++++++-
3 files changed, 104 insertions(+), 1 deletion(-)
diff --git a/pack-bitmap.c b/pack-bitmap.c
index dcf8a9aadf..9d680065e4 100644
--- a/pack-bitmap.c
+++ b/pack-bitmap.c
@@ -779,6 +779,78 @@ static void filter_bitmap_blob_none(struct bitmap_index *bitmap_git,
bitmap_free(tips);
}
+static unsigned long get_size_by_pos(struct bitmap_index *bitmap_git,
+ uint32_t pos)
+{
+ struct packed_git *pack = bitmap_git->pack;
+ unsigned long size;
+ struct object_info oi = OBJECT_INFO_INIT;
+
+ oi.sizep = &size;
+
+ if (pos < pack->num_objects) {
+ struct revindex_entry *entry = &pack->revindex[pos];
+ if (packed_object_info(the_repository, pack,
+ entry->offset, &oi) < 0) {
+ struct object_id oid;
+ nth_packed_object_oid(&oid, pack, entry->nr);
+ die(_("unable to get size of %s"), oid_to_hex(&oid));
+ }
+ } else {
+ struct eindex *eindex = &bitmap_git->ext_index;
+ struct object *obj = eindex->objects[pos - pack->num_objects];
+ if (oid_object_info_extended(the_repository, &obj->oid, &oi, 0) < 0)
+ die(_("unable to get size of %s"), oid_to_hex(&obj->oid));
+ }
+
+ return size;
+}
+
+static void filter_bitmap_blob_limit(struct bitmap_index *bitmap_git,
+ struct object_list *tip_objects,
+ struct bitmap *to_filter,
+ unsigned long limit)
+{
+ struct eindex *eindex = &bitmap_git->ext_index;
+ struct bitmap *tips;
+ struct ewah_iterator it;
+ eword_t mask;
+ uint32_t i;
+
+ tips = find_tip_blobs(bitmap_git, tip_objects);
+
+ for (i = 0, init_type_iterator(&it, bitmap_git, OBJ_BLOB);
+ i < to_filter->word_alloc && ewah_iterator_next(&mask, &it);
+ i++) {
+ eword_t word = to_filter->words[i] & mask;
+ unsigned offset;
+
+ for (offset = 0; offset < BITS_IN_EWORD; offset++) {
+ uint32_t pos;
+
+ if ((word >> offset) == 0)
+ break;
+ offset += ewah_bit_ctz64(word >> offset);
+ pos = i * BITS_IN_EWORD + offset;
+
+ if (!bitmap_get(tips, pos) &&
+ get_size_by_pos(bitmap_git, pos) >= limit)
+ bitmap_unset(to_filter, pos);
+ }
+ }
+
+ for (i = 0; i < eindex->count; i++) {
+ uint32_t pos = i + bitmap_git->pack->num_objects;
+ if (eindex->objects[i]->type == OBJ_BLOB &&
+ bitmap_get(to_filter, pos) &&
+ !bitmap_get(tips, pos) &&
+ get_size_by_pos(bitmap_git, pos) >= limit)
+ bitmap_unset(to_filter, pos);
+ }
+
+ bitmap_free(tips);
+}
+
static int filter_bitmap(struct bitmap_index *bitmap_git,
struct object_list *tip_objects,
struct bitmap *to_filter,
@@ -794,6 +866,14 @@ static int filter_bitmap(struct bitmap_index *bitmap_git,
return 0;
}
+ if (filter->choice == LOFC_BLOB_LIMIT) {
+ if (bitmap_git)
+ filter_bitmap_blob_limit(bitmap_git, tip_objects,
+ to_filter,
+ filter->blob_limit_value);
+ return 0;
+ }
+
/* filter choice not handled */
return -1;
}
diff --git a/t/perf/p5310-pack-bitmaps.sh b/t/perf/p5310-pack-bitmaps.sh
index 936742314c..8b43a545c1 100755
--- a/t/perf/p5310-pack-bitmaps.sh
+++ b/t/perf/p5310-pack-bitmaps.sh
@@ -52,6 +52,11 @@ test_perf 'rev-list count with blob:none' '
--filter=blob:none >/dev/null
'
+test_perf 'rev-list count with blob:limit=1k' '
+ git rev-list --use-bitmap-index --count --objects --all \
+ --filter=blob:limit=1k >/dev/null
+'
+
test_expect_success 'create partial bitmap state' '
# pick a commit to represent the repo tip in the past
cutoff=$(git rev-list HEAD~100 -1) &&
diff --git a/t/t6113-rev-list-bitmap-filters.sh b/t/t6113-rev-list-bitmap-filters.sh
index f4e6d582f0..145603f124 100755
--- a/t/t6113-rev-list-bitmap-filters.sh
+++ b/t/t6113-rev-list-bitmap-filters.sh
@@ -6,8 +6,10 @@ test_description='rev-list combining bitmaps and filters'
test_expect_success 'set up bitmapped repo' '
# one commit will have bitmaps, the other will not
test_commit one &&
+ test_commit much-larger-blob-one &&
git repack -adb &&
- test_commit two
+ test_commit two &&
+ test_commit much-larger-blob-two
'
test_expect_success 'filters fallback to non-bitmap traversal' '
@@ -35,4 +37,20 @@ test_expect_success 'blob:none filter with specified blob' '
test_bitmap_traversal expect actual
'
+test_expect_success 'blob:limit filter' '
+ git rev-list --objects --filter=blob:limit=5 HEAD >expect &&
+ git rev-list --use-bitmap-index \
+ --objects --filter=blob:limit=5 HEAD >actual &&
+ test_bitmap_traversal expect actual
+'
+
+test_expect_success 'blob:limit filter with specified blob' '
+ git rev-list --objects --filter=blob:limit=5 \
+ HEAD HEAD:much-larger-blob-two.t >expect &&
+ git rev-list --use-bitmap-index \
+ --objects --filter=blob:limit=5 \
+ HEAD HEAD:much-larger-blob-two.t >actual &&
+ test_bitmap_traversal expect actual
+'
+
test_done
--
2.25.0.796.gcc29325708
^ permalink raw reply related
* [PATCH v2 15/15] pack-objects: support filters with bitmaps
From: Jeff King @ 2020-02-14 18:22 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <20200214182147.GA654525@coredump.intra.peff.net>
Just as rev-list recently learned to combine filters and bitmaps, let's
do the same for pack-objects. The infrastructure is all there; we just
need to pass along our filter options, and the pack-bitmap code will
decide to use bitmaps or not.
This unsurprisingly makes things faster for partial clones of large
repositories (here we're cloning linux.git):
Test HEAD^ HEAD
------------------------------------------------------------------------------
5310.11: simulated partial clone 38.94(37.28+5.87) 11.06(11.27+4.07) -71.6%
Signed-off-by: Jeff King <peff@peff.net>
---
builtin/pack-objects.c | 3 +--
t/perf/p5310-pack-bitmaps.sh | 4 ++++
t/t5310-pack-bitmaps.sh | 14 ++++++++++++++
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 2bb81c2133..6bc9bc1ce2 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -3040,7 +3040,7 @@ static int pack_options_allow_reuse(void)
static int get_object_list_from_bitmap(struct rev_info *revs)
{
- if (!(bitmap_git = prepare_bitmap_walk(revs, NULL)))
+ if (!(bitmap_git = prepare_bitmap_walk(revs, &filter_options)))
return -1;
if (pack_options_allow_reuse() &&
@@ -3419,7 +3419,6 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
if (filter_options.choice) {
if (!pack_to_stdout)
die(_("cannot use --filter without --stdout"));
- use_bitmap_index = 0;
}
/*
diff --git a/t/perf/p5310-pack-bitmaps.sh b/t/perf/p5310-pack-bitmaps.sh
index 8b43a545c1..7743f4f4c9 100755
--- a/t/perf/p5310-pack-bitmaps.sh
+++ b/t/perf/p5310-pack-bitmaps.sh
@@ -57,6 +57,10 @@ test_perf 'rev-list count with blob:limit=1k' '
--filter=blob:limit=1k >/dev/null
'
+test_perf 'simulated partial clone' '
+ git pack-objects --stdout --all --filter=blob:none </dev/null >/dev/null
+'
+
test_expect_success 'create partial bitmap state' '
# pick a commit to represent the repo tip in the past
cutoff=$(git rev-list HEAD~100 -1) &&
diff --git a/t/t5310-pack-bitmaps.sh b/t/t5310-pack-bitmaps.sh
index 2c64d0c441..8318781d2b 100755
--- a/t/t5310-pack-bitmaps.sh
+++ b/t/t5310-pack-bitmaps.sh
@@ -107,6 +107,20 @@ test_expect_success 'clone from bitmapped repository' '
test_cmp expect actual
'
+test_expect_success 'partial clone from bitmapped repository' '
+ test_config uploadpack.allowfilter true &&
+ git clone --no-local --bare --filter=blob:none . partial-clone.git &&
+ (
+ cd partial-clone.git &&
+ pack=$(echo objects/pack/*.pack) &&
+ git verify-pack -v "$pack" >have &&
+ awk "/blob/ { print \$1 }" <have >blobs &&
+ # we expect this single blob because of the direct ref
+ git rev-parse refs/tags/tagged-blob >expect &&
+ test_cmp expect blobs
+ )
+'
+
test_expect_success 'setup further non-bitmapped commits' '
test_commit_bulk --id=further 10
'
--
2.25.0.796.gcc29325708
^ permalink raw reply related
* [PATCH AUTOSEL 5.5 026/542] brcmfmac: Fix memory leak in brcmf_p2p_create_p2pdev()
From: Sasha Levin @ 2020-02-14 15:40 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Navid Emamdoost, Kalle Valo, Sasha Levin, linux-wireless,
brcm80211-dev-list.pdl, brcm80211-dev-list, netdev
In-Reply-To: <20200214154854.6746-1-sashal@kernel.org>
From: Navid Emamdoost <navid.emamdoost@gmail.com>
[ Upstream commit 5cc509aa83c6acd2c5cd94f99065c39d2bd0a490 ]
In the implementation of brcmf_p2p_create_p2pdev() the allocated memory
for p2p_vif is leaked when the mac address is the same as primary
interface. To fix this, go to error path to release p2p_vif via
brcmf_free_vif().
Fixes: cb746e47837a ("brcmfmac: check p2pdev mac address uniqueness")
Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
index 7ba9f6a686459..1f5deea5a288e 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
@@ -2092,7 +2092,8 @@ static struct wireless_dev *brcmf_p2p_create_p2pdev(struct brcmf_p2p_info *p2p,
/* firmware requires unique mac address for p2pdev interface */
if (addr && ether_addr_equal(addr, pri_ifp->mac_addr)) {
bphy_err(drvr, "discovery vif must be different from primary interface\n");
- return ERR_PTR(-EINVAL);
+ err = -EINVAL;
+ goto fail;
}
brcmf_p2p_generate_bss_mac(p2p, addr);
--
2.20.1
^ permalink raw reply related
* [PATCH v2 12/15] bitmap: add bitmap_unset() function
From: Jeff King @ 2020-02-14 18:22 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <20200214182147.GA654525@coredump.intra.peff.net>
We've never needed to unset an individual bit in a bitmap until now.
Typically they start with all bits unset and we bitmap_set() them, or we
are applying another bitmap as a mask. But the easiest way to apply an
object filter to a bitmap result will be to unset the individual bits.
Signed-off-by: Jeff King <peff@peff.net>
---
ewah/bitmap.c | 8 ++++++++
ewah/ewok.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/ewah/bitmap.c b/ewah/bitmap.c
index 52f1178db4..1c31b3e249 100644
--- a/ewah/bitmap.c
+++ b/ewah/bitmap.c
@@ -45,6 +45,14 @@ void bitmap_set(struct bitmap *self, size_t pos)
self->words[block] |= EWAH_MASK(pos);
}
+void bitmap_unset(struct bitmap *self, size_t pos)
+{
+ size_t block = EWAH_BLOCK(pos);
+
+ if (block < self->word_alloc)
+ self->words[block] &= ~EWAH_MASK(pos);
+}
+
int bitmap_get(struct bitmap *self, size_t pos)
{
size_t block = EWAH_BLOCK(pos);
diff --git a/ewah/ewok.h b/ewah/ewok.h
index 84b2a29faa..59f4ef7c4f 100644
--- a/ewah/ewok.h
+++ b/ewah/ewok.h
@@ -173,6 +173,7 @@ struct bitmap {
struct bitmap *bitmap_new(void);
void bitmap_set(struct bitmap *self, size_t pos);
+void bitmap_unset(struct bitmap *self, size_t pos);
int bitmap_get(struct bitmap *self, size_t pos);
void bitmap_reset(struct bitmap *self);
void bitmap_free(struct bitmap *self);
--
2.25.0.796.gcc29325708
^ permalink raw reply related
* [PATCH v2 11/15] rev-list: use bitmap filters for traversal
From: Jeff King @ 2020-02-14 18:22 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <20200214182147.GA654525@coredump.intra.peff.net>
This just passes the filter-options struct to prepare_bitmap_walk().
Since the bitmap code doesn't actually support any filters yet, it will
fallback to the non-bitmap code if any --filter is specified. But this
lets us exercise that rejection code path, as well as getting us ready
to test filters via rev-list when we _do_ support them.
Signed-off-by: Jeff King <peff@peff.net>
---
builtin/rev-list.c | 17 ++++++++---------
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/builtin/rev-list.c b/builtin/rev-list.c
index 6ff5e175fa..35e14ad2ed 100644
--- a/builtin/rev-list.c
+++ b/builtin/rev-list.c
@@ -372,7 +372,8 @@ static inline int parse_missing_action_value(const char *value)
return 0;
}
-static int try_bitmap_count(struct rev_info *revs)
+static int try_bitmap_count(struct rev_info *revs,
+ struct list_objects_filter_options *filter)
{
uint32_t commit_count = 0,
tag_count = 0,
@@ -407,7 +408,7 @@ static int try_bitmap_count(struct rev_info *revs)
*/
max_count = revs->max_count;
- bitmap_git = prepare_bitmap_walk(revs, NULL);
+ bitmap_git = prepare_bitmap_walk(revs, filter);
if (!bitmap_git)
return -1;
@@ -423,7 +424,8 @@ static int try_bitmap_count(struct rev_info *revs)
return 0;
}
-static int try_bitmap_traversal(struct rev_info *revs)
+static int try_bitmap_traversal(struct rev_info *revs,
+ struct list_objects_filter_options *filter)
{
struct bitmap_index *bitmap_git;
@@ -434,7 +436,7 @@ static int try_bitmap_traversal(struct rev_info *revs)
if (revs->max_count >= 0)
return -1;
- bitmap_git = prepare_bitmap_walk(revs, NULL);
+ bitmap_git = prepare_bitmap_walk(revs, filter);
if (!bitmap_git)
return -1;
@@ -605,9 +607,6 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
(revs.left_right || revs.cherry_mark))
die(_("marked counting is incompatible with --objects"));
- if (filter_options.choice)
- use_bitmap_index = 0;
-
save_commit_buffer = (revs.verbose_header ||
revs.grep_filter.pattern_list ||
revs.grep_filter.header_list);
@@ -618,9 +617,9 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
progress = start_delayed_progress(show_progress, 0);
if (use_bitmap_index) {
- if (!try_bitmap_count(&revs))
+ if (!try_bitmap_count(&revs, &filter_options))
return 0;
- if (!try_bitmap_traversal(&revs))
+ if (!try_bitmap_traversal(&revs, &filter_options))
return 0;
}
--
2.25.0.796.gcc29325708
^ permalink raw reply related
* [PATCH v2 02/15] pack-bitmap: fix leak of haves/wants object lists
From: Jeff King @ 2020-02-14 18:22 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <20200214182147.GA654525@coredump.intra.peff.net>
When we do a bitmap-aware revision traversal, we create an object_list
for each of the "haves" and "wants" tips. After creating the result
bitmaps these are no longer needed or used, but we never free the list
memory.
Signed-off-by: Jeff King <peff@peff.net>
---
object.c | 9 +++++++++
object.h | 2 ++
pack-bitmap.c | 5 +++++
3 files changed, 16 insertions(+)
diff --git a/object.c b/object.c
index 142ef69399..4d11949b38 100644
--- a/object.c
+++ b/object.c
@@ -307,6 +307,15 @@ int object_list_contains(struct object_list *list, struct object *obj)
return 0;
}
+void object_list_free(struct object_list **list)
+{
+ while (*list) {
+ struct object_list *p = *list;
+ *list = p->next;
+ free(p);
+ }
+}
+
/*
* A zero-length string to which object_array_entry::name can be
* initialized without requiring a malloc/free.
diff --git a/object.h b/object.h
index 25f5ab3d54..2dbabfca0a 100644
--- a/object.h
+++ b/object.h
@@ -151,6 +151,8 @@ struct object_list *object_list_insert(struct object *item,
int object_list_contains(struct object_list *list, struct object *obj);
+void object_list_free(struct object_list **list);
+
/* Object array handling .. */
void add_object_array(struct object *obj, const char *name, struct object_array *array);
void add_object_array_with_path(struct object *obj, const char *name, struct object_array *array, unsigned mode, const char *path);
diff --git a/pack-bitmap.c b/pack-bitmap.c
index 9ca356ee29..6c06099dc7 100644
--- a/pack-bitmap.c
+++ b/pack-bitmap.c
@@ -787,10 +787,15 @@ struct bitmap_index *prepare_bitmap_walk(struct rev_info *revs)
bitmap_git->result = wants_bitmap;
bitmap_git->haves = haves_bitmap;
+ object_list_free(&wants);
+ object_list_free(&haves);
+
return bitmap_git;
cleanup:
free_bitmap_index(bitmap_git);
+ object_list_free(&wants);
+ object_list_free(&haves);
return NULL;
}
--
2.25.0.796.gcc29325708
^ permalink raw reply related
* Re: [PATCH v2 net 3/3] wireguard: send: account for mtu=0 devices
From: Eric Dumazet @ 2020-02-14 18:22 UTC (permalink / raw)
To: Jason A. Donenfeld, Eric Dumazet; +Cc: David Miller, Netdev, Eric Dumazet
In-Reply-To: <CAHmME9pjLfscZ-b0YFsOoKMcENRh4Ld1rfiTTzzHmt+OxOzdjA@mail.gmail.com>
On 2/14/20 10:15 AM, Jason A. Donenfeld wrote:
> On Fri, Feb 14, 2020 at 6:56 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> Oh dear, can you describe what do you expect of a wireguard device with mtu == 0 or mtu == 1
>>
>> Why simply not allowing silly configurations, instead of convoluted tests in fast path ?
>>
>> We are speaking of tunnels adding quite a lot of headers, so we better not try to make them
>> work on networks with tiny mtu. Just say no to syzbot.
>
> The idea was that wireguard might still be useful for the persistent
> keepalive stuff. This branch becomes very cold very fast, so I don't
> think it makes a difference performance wise, but if you feel strongly
> about it, I can get rid of it and set a non-zero min_mtu that's the
> smallest thing wireguard's xmit semantics will accept. It sounds like
> you'd prefer that?
>
Well, if you believe that wireguard in persistent keepalive
has some value on its own, I guess that we will have to support this mode.
Some legacy devices can have arbitrary mtu, and this has caused headaches.
I was hoping that for brand new devices, we could have saner limits.
About setting max_mtu to ~MAX_INT, does it mean wireguard will attempt
to send UDP datagrams bigger than 64K ? Where is the segmentation done ?
^ permalink raw reply
* [PATCH v2 10/15] pack-bitmap: basic noop bitmap filter infrastructure
From: Jeff King @ 2020-02-14 18:22 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <20200214182147.GA654525@coredump.intra.peff.net>
Currently you can't use object filters with bitmaps, but we plan to
support at least some filters with bitmaps. Let's introduce some
infrastructure that will help us do that:
- prepare_bitmap_walk() now accepts a list_objects_filter_options
parameter (which can be NULL for no filtering; all the current
callers pass this)
- we'll bail early if the filter is incompatible with bitmaps (just as
we would if there were no bitmaps at all). Currently all filters are
incompatible.
- we'll filter the resulting bitmap; since there are no supported
filters yet, this is always a noop.
There should be no behavior change yet, but we'll support some actual
filters in a future patch.
Signed-off-by: Jeff King <peff@peff.net>
---
builtin/pack-objects.c | 2 +-
builtin/rev-list.c | 4 ++--
pack-bitmap.c | 26 +++++++++++++++++++++++++-
pack-bitmap.h | 4 +++-
reachable.c | 2 +-
5 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 06915ebe7f..2bb81c2133 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -3040,7 +3040,7 @@ static int pack_options_allow_reuse(void)
static int get_object_list_from_bitmap(struct rev_info *revs)
{
- if (!(bitmap_git = prepare_bitmap_walk(revs)))
+ if (!(bitmap_git = prepare_bitmap_walk(revs, NULL)))
return -1;
if (pack_options_allow_reuse() &&
diff --git a/builtin/rev-list.c b/builtin/rev-list.c
index 937324cef0..6ff5e175fa 100644
--- a/builtin/rev-list.c
+++ b/builtin/rev-list.c
@@ -407,7 +407,7 @@ static int try_bitmap_count(struct rev_info *revs)
*/
max_count = revs->max_count;
- bitmap_git = prepare_bitmap_walk(revs);
+ bitmap_git = prepare_bitmap_walk(revs, NULL);
if (!bitmap_git)
return -1;
@@ -434,7 +434,7 @@ static int try_bitmap_traversal(struct rev_info *revs)
if (revs->max_count >= 0)
return -1;
- bitmap_git = prepare_bitmap_walk(revs);
+ bitmap_git = prepare_bitmap_walk(revs, NULL);
if (!bitmap_git)
return -1;
diff --git a/pack-bitmap.c b/pack-bitmap.c
index 2fbc748b19..48c8694f92 100644
--- a/pack-bitmap.c
+++ b/pack-bitmap.c
@@ -12,6 +12,7 @@
#include "packfile.h"
#include "repository.h"
#include "object-store.h"
+#include "list-objects-filter-options.h"
/*
* An entry on the bitmap index, representing the bitmap for a given
@@ -711,7 +712,25 @@ static int in_bitmapped_pack(struct bitmap_index *bitmap_git,
return 0;
}
-struct bitmap_index *prepare_bitmap_walk(struct rev_info *revs)
+static int filter_bitmap(struct bitmap_index *bitmap_git,
+ struct object_list *tip_objects,
+ struct bitmap *to_filter,
+ struct list_objects_filter_options *filter)
+{
+ if (!filter || filter->choice == LOFC_DISABLED)
+ return 0;
+
+ /* filter choice not handled */
+ return -1;
+}
+
+static int can_filter_bitmap(struct list_objects_filter_options *filter)
+{
+ return !filter_bitmap(NULL, NULL, NULL, filter);
+}
+
+struct bitmap_index *prepare_bitmap_walk(struct rev_info *revs,
+ struct list_objects_filter_options *filter)
{
unsigned int i;
@@ -731,6 +750,9 @@ struct bitmap_index *prepare_bitmap_walk(struct rev_info *revs)
if (revs->prune)
return NULL;
+ if (!can_filter_bitmap(filter))
+ return NULL;
+
/* try to open a bitmapped pack, but don't parse it yet
* because we may not need to use it */
bitmap_git = xcalloc(1, sizeof(*bitmap_git));
@@ -800,6 +822,8 @@ struct bitmap_index *prepare_bitmap_walk(struct rev_info *revs)
if (haves_bitmap)
bitmap_and_not(wants_bitmap, haves_bitmap);
+ filter_bitmap(bitmap_git, wants, wants_bitmap, filter);
+
bitmap_git->result = wants_bitmap;
bitmap_git->haves = haves_bitmap;
diff --git a/pack-bitmap.h b/pack-bitmap.h
index b0c06a212e..956775d0bb 100644
--- a/pack-bitmap.h
+++ b/pack-bitmap.h
@@ -8,6 +8,7 @@
struct commit;
struct repository;
struct rev_info;
+struct list_objects_filter_options;
static const char BITMAP_IDX_SIGNATURE[] = {'B', 'I', 'T', 'M'};
@@ -47,7 +48,8 @@ void traverse_bitmap_commit_list(struct bitmap_index *,
struct rev_info *revs,
show_reachable_fn show_reachable);
void test_bitmap_walk(struct rev_info *revs);
-struct bitmap_index *prepare_bitmap_walk(struct rev_info *revs);
+struct bitmap_index *prepare_bitmap_walk(struct rev_info *revs,
+ struct list_objects_filter_options *filter);
int reuse_partial_packfile_from_bitmap(struct bitmap_index *,
struct packed_git **packfile,
uint32_t *entries, off_t *up_to);
diff --git a/reachable.c b/reachable.c
index 0919f025c4..77a60c70a5 100644
--- a/reachable.c
+++ b/reachable.c
@@ -223,7 +223,7 @@ void mark_reachable_objects(struct rev_info *revs, int mark_reflog,
cp.progress = progress;
cp.count = 0;
- bitmap_git = prepare_bitmap_walk(revs);
+ bitmap_git = prepare_bitmap_walk(revs, NULL);
if (bitmap_git) {
traverse_bitmap_commit_list(bitmap_git, revs, mark_object_seen);
free_bitmap_index(bitmap_git);
--
2.25.0.796.gcc29325708
^ permalink raw reply related
* Re: [PATCH v2 09/19] tracing: only allow -trace to override -D if set
From: Robert Foley @ 2020-02-14 18:19 UTC (permalink / raw)
To: Alex Bennée
Cc: fam, berrange, pbonzini, stefanb, Richard Henderson, qemu-devel,
robhenry, f4bug, marcandre.lureau, aaron, cota, stefanha,
kuhn.chenqun, Peter Puhov, aurelien
In-Reply-To: <20200213225109.13120-10-alex.bennee@linaro.org>
On Thu, 13 Feb 2020 at 17:51, Alex Bennée <alex.bennee@linaro.org> wrote:
>
> Otherwise any -D settings the user may have made get ignored.
>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Robert Foley <robert.foley@linaro.org>
^ permalink raw reply
* [PATCH v2 09/15] rev-list: allow commit-only bitmap traversals
From: Jeff King @ 2020-02-14 18:22 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <20200214182147.GA654525@coredump.intra.peff.net>
Ever since we added reachability bitmap support, we've been able to use
it with rev-list to get the full list of objects, like:
git rev-list --objects --use-bitmap-index --all
But you can't do so without --objects, since we weren't ready to just
show the commits. However, the internals of the bitmap code are mostly
ready for this: they avoid opening up trees when walking to fill in the
bitmaps. We just need to actually pass in the rev_info to
traverse_bitmap_commit_list() so it knows which types to bother
triggering our callback for.
For completeness, the perf test now covers both the existing --objects
case, as well as the new commits-only behavior (the objects one got way
faster when we introduced bitmaps, but obviously isn't improved now).
Here are numbers for linux.git:
Test HEAD^ HEAD
------------------------------------------------------------------------
5310.7: rev-list (commits) 8.29(8.10+0.19) 1.76(1.72+0.04) -78.8%
5310.8: rev-list (objects) 8.06(7.94+0.12) 8.14(7.94+0.13) +1.0%
That run was cheating a little, as I didn't have any commit-graph in the
repository, and we'd built it by default these days when running git-gc.
Here are numbers with a commit-graph:
Test HEAD^ HEAD
------------------------------------------------------------------------
5310.7: rev-list (commits) 0.70(0.58+0.12) 0.51(0.46+0.04) -27.1%
5310.8: rev-list (objects) 6.20(6.09+0.10) 6.27(6.16+0.11) +1.1%
Still an improvement, but a lot less impressive.
We could have the perf script remove any commit-graph to show the
out-sized effect, but it probably makes sense to leave it in what would
be a more typical setup.
Signed-off-by: Jeff King <peff@peff.net>
---
builtin/pack-objects.c | 3 ++-
builtin/rev-list.c | 9 +--------
pack-bitmap.c | 20 +++++++++++++++-----
pack-bitmap.h | 1 +
reachable.c | 2 +-
t/perf/p5310-pack-bitmaps.sh | 8 ++++++++
t/t5310-pack-bitmaps.sh | 6 ++++++
7 files changed, 34 insertions(+), 15 deletions(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 393c20a2d7..06915ebe7f 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -3054,7 +3054,8 @@ static int get_object_list_from_bitmap(struct rev_info *revs)
display_progress(progress_state, nr_result);
}
- traverse_bitmap_commit_list(bitmap_git, &add_object_entry_from_bitmap);
+ traverse_bitmap_commit_list(bitmap_git, revs,
+ &add_object_entry_from_bitmap);
return 0;
}
diff --git a/builtin/rev-list.c b/builtin/rev-list.c
index 70f3207ecc..937324cef0 100644
--- a/builtin/rev-list.c
+++ b/builtin/rev-list.c
@@ -434,18 +434,11 @@ static int try_bitmap_traversal(struct rev_info *revs)
if (revs->max_count >= 0)
return -1;
- /*
- * Our bitmap result will return all objects, and we're not
- * yet prepared to show only particular types.
- */
- if (!revs->tag_objects || !revs->tree_objects || !revs->blob_objects)
- return -1;
-
bitmap_git = prepare_bitmap_walk(revs);
if (!bitmap_git)
return -1;
- traverse_bitmap_commit_list(bitmap_git, &show_object_fast);
+ traverse_bitmap_commit_list(bitmap_git, revs, &show_object_fast);
free_bitmap_index(bitmap_git);
return 0;
}
diff --git a/pack-bitmap.c b/pack-bitmap.c
index a97b717e55..2fbc748b19 100644
--- a/pack-bitmap.c
+++ b/pack-bitmap.c
@@ -599,6 +599,7 @@ static struct bitmap *find_objects(struct bitmap_index *bitmap_git,
}
static void show_extended_objects(struct bitmap_index *bitmap_git,
+ struct rev_info *revs,
show_reachable_fn show_reach)
{
struct bitmap *objects = bitmap_git->result;
@@ -612,6 +613,11 @@ static void show_extended_objects(struct bitmap_index *bitmap_git,
continue;
obj = eindex->objects[i];
+ if ((obj->type == OBJ_BLOB && !revs->blob_objects) ||
+ (obj->type == OBJ_TREE && !revs->tree_objects) ||
+ (obj->type == OBJ_TAG && !revs->tag_objects))
+ continue;
+
show_reach(&obj->oid, obj->type, 0, eindex->hashes[i], NULL, 0);
}
}
@@ -872,16 +878,20 @@ int reuse_partial_packfile_from_bitmap(struct bitmap_index *bitmap_git,
}
void traverse_bitmap_commit_list(struct bitmap_index *bitmap_git,
+ struct rev_info *revs,
show_reachable_fn show_reachable)
{
assert(bitmap_git->result);
show_objects_for_type(bitmap_git, OBJ_COMMIT, show_reachable);
- show_objects_for_type(bitmap_git, OBJ_TREE, show_reachable);
- show_objects_for_type(bitmap_git, OBJ_BLOB, show_reachable);
- show_objects_for_type(bitmap_git, OBJ_TAG, show_reachable);
-
- show_extended_objects(bitmap_git, show_reachable);
+ if (revs->tree_objects)
+ show_objects_for_type(bitmap_git, OBJ_TREE, show_reachable);
+ if (revs->blob_objects)
+ show_objects_for_type(bitmap_git, OBJ_BLOB, show_reachable);
+ if (revs->tag_objects)
+ show_objects_for_type(bitmap_git, OBJ_TAG, show_reachable);
+
+ show_extended_objects(bitmap_git, revs, show_reachable);
}
static uint32_t count_object_type(struct bitmap_index *bitmap_git,
diff --git a/pack-bitmap.h b/pack-bitmap.h
index 466c5afa09..b0c06a212e 100644
--- a/pack-bitmap.h
+++ b/pack-bitmap.h
@@ -44,6 +44,7 @@ struct bitmap_index *prepare_bitmap_git(struct repository *r);
void count_bitmap_commit_list(struct bitmap_index *, uint32_t *commits,
uint32_t *trees, uint32_t *blobs, uint32_t *tags);
void traverse_bitmap_commit_list(struct bitmap_index *,
+ struct rev_info *revs,
show_reachable_fn show_reachable);
void test_bitmap_walk(struct rev_info *revs);
struct bitmap_index *prepare_bitmap_walk(struct rev_info *revs);
diff --git a/reachable.c b/reachable.c
index 8f50235b28..0919f025c4 100644
--- a/reachable.c
+++ b/reachable.c
@@ -225,7 +225,7 @@ void mark_reachable_objects(struct rev_info *revs, int mark_reflog,
bitmap_git = prepare_bitmap_walk(revs);
if (bitmap_git) {
- traverse_bitmap_commit_list(bitmap_git, mark_object_seen);
+ traverse_bitmap_commit_list(bitmap_git, revs, mark_object_seen);
free_bitmap_index(bitmap_git);
return;
}
diff --git a/t/perf/p5310-pack-bitmaps.sh b/t/perf/p5310-pack-bitmaps.sh
index 6a3a42531b..e52f66ec9e 100755
--- a/t/perf/p5310-pack-bitmaps.sh
+++ b/t/perf/p5310-pack-bitmaps.sh
@@ -39,6 +39,14 @@ test_perf 'pack to file (bitmap)' '
git pack-objects --use-bitmap-index --all pack1b </dev/null >/dev/null
'
+test_perf 'rev-list (commits)' '
+ git rev-list --all --use-bitmap-index >/dev/null
+'
+
+test_perf 'rev-list (objects)' '
+ git rev-list --all --use-bitmap-index --objects >/dev/null
+'
+
test_expect_success 'create partial bitmap state' '
# pick a commit to represent the repo tip in the past
cutoff=$(git rev-list HEAD~100 -1) &&
diff --git a/t/t5310-pack-bitmaps.sh b/t/t5310-pack-bitmaps.sh
index b8645ae070..2c64d0c441 100755
--- a/t/t5310-pack-bitmaps.sh
+++ b/t/t5310-pack-bitmaps.sh
@@ -80,6 +80,12 @@ rev_list_tests() {
test_cmp expect actual
'
+ test_expect_success "enumerate commits ($state)" '
+ git rev-list --use-bitmap-index HEAD >actual &&
+ git rev-list HEAD >expect &&
+ test_bitmap_traversal --no-confirm-bitmaps expect actual
+ '
+
test_expect_success "enumerate --objects ($state)" '
git rev-list --objects --use-bitmap-index HEAD >actual &&
git rev-list --objects HEAD >expect &&
--
2.25.0.796.gcc29325708
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 430/459] powerpc: Do not consider weak unresolved symbol relocations as bad
From: Sasha Levin @ 2020-02-14 16:01 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Stephen Rothwell, Alexandre Ghiti, netdev, bpf,
linuxppc-dev
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Alexandre Ghiti <alex@ghiti.fr>
[ Upstream commit 43e76cd368fbb67e767da5363ffeaa3989993c8c ]
Commit 8580ac9404f6 ("bpf: Process in-kernel BTF") introduced two weak
symbols that may be unresolved at link time which result in an absolute
relocation to 0. relocs_check.sh emits the following warning:
"WARNING: 2 bad relocations
c000000001a41478 R_PPC64_ADDR64 _binary__btf_vmlinux_bin_start
c000000001a41480 R_PPC64_ADDR64 _binary__btf_vmlinux_bin_end"
whereas those relocations are legitimate even for a relocatable kernel
compiled with -pie option.
relocs_check.sh already excluded some weak unresolved symbols explicitly:
remove those hardcoded symbols and add some logic that parses the symbols
using nm, retrieves all the weak unresolved symbols and excludes those from
the list of the potential bad relocations.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Alexandre Ghiti <alex@ghiti.fr>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200118170335.21440-1-alex@ghiti.fr
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/Makefile.postlink | 4 ++--
arch/powerpc/tools/relocs_check.sh | 20 ++++++++++++--------
2 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/Makefile.postlink b/arch/powerpc/Makefile.postlink
index 134f12f89b92b..2268396ff4bba 100644
--- a/arch/powerpc/Makefile.postlink
+++ b/arch/powerpc/Makefile.postlink
@@ -17,11 +17,11 @@ quiet_cmd_head_check = CHKHEAD $@
quiet_cmd_relocs_check = CHKREL $@
ifdef CONFIG_PPC_BOOK3S_64
cmd_relocs_check = \
- $(CONFIG_SHELL) $(srctree)/arch/powerpc/tools/relocs_check.sh "$(OBJDUMP)" "$@" ; \
+ $(CONFIG_SHELL) $(srctree)/arch/powerpc/tools/relocs_check.sh "$(OBJDUMP)" "$(NM)" "$@" ; \
$(BASH) $(srctree)/arch/powerpc/tools/unrel_branch_check.sh "$(OBJDUMP)" "$@"
else
cmd_relocs_check = \
- $(CONFIG_SHELL) $(srctree)/arch/powerpc/tools/relocs_check.sh "$(OBJDUMP)" "$@"
+ $(CONFIG_SHELL) $(srctree)/arch/powerpc/tools/relocs_check.sh "$(OBJDUMP)" "$(NM)" "$@"
endif
# `@true` prevents complaint when there is nothing to be done
diff --git a/arch/powerpc/tools/relocs_check.sh b/arch/powerpc/tools/relocs_check.sh
index 7b9fe0a567cf3..014e00e74d2b6 100755
--- a/arch/powerpc/tools/relocs_check.sh
+++ b/arch/powerpc/tools/relocs_check.sh
@@ -10,14 +10,21 @@
# based on relocs_check.pl
# Copyright © 2009 IBM Corporation
-if [ $# -lt 2 ]; then
- echo "$0 [path to objdump] [path to vmlinux]" 1>&2
+if [ $# -lt 3 ]; then
+ echo "$0 [path to objdump] [path to nm] [path to vmlinux]" 1>&2
exit 1
fi
-# Have Kbuild supply the path to objdump so we handle cross compilation.
+# Have Kbuild supply the path to objdump and nm so we handle cross compilation.
objdump="$1"
-vmlinux="$2"
+nm="$2"
+vmlinux="$3"
+
+# Remove from the bad relocations those that match an undefined weak symbol
+# which will result in an absolute relocation to 0.
+# Weak unresolved symbols are of that form in nm output:
+# " w _binary__btf_vmlinux_bin_end"
+undef_weak_symbols=$($nm "$vmlinux" | awk '$1 ~ /w/ { print $2 }')
bad_relocs=$(
$objdump -R "$vmlinux" |
@@ -26,8 +33,6 @@ $objdump -R "$vmlinux" |
# These relocations are okay
# On PPC64:
# R_PPC64_RELATIVE, R_PPC64_NONE
- # R_PPC64_ADDR64 mach_<name>
- # R_PPC64_ADDR64 __crc_<name>
# On PPC:
# R_PPC_RELATIVE, R_PPC_ADDR16_HI,
# R_PPC_ADDR16_HA,R_PPC_ADDR16_LO,
@@ -39,8 +44,7 @@ R_PPC_ADDR16_HI
R_PPC_ADDR16_HA
R_PPC_RELATIVE
R_PPC_NONE' |
- grep -E -v '\<R_PPC64_ADDR64[[:space:]]+mach_' |
- grep -E -v '\<R_PPC64_ADDR64[[:space:]]+__crc_'
+ ([ "$undef_weak_symbols" ] && grep -F -w -v "$undef_weak_symbols" || cat)
)
if [ -z "$bad_relocs" ]; then
--
2.20.1
^ permalink raw reply related
* [PATCH v2 07/15] rev-list: allow bitmaps when counting objects
From: Jeff King @ 2020-02-14 18:22 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <20200214182147.GA654525@coredump.intra.peff.net>
The prior commit taught "--count --objects" to work without bitmaps. We
should be able to get the same answer much more quickly with bitmaps.
Note that we punt on the max_count case here. This perhaps _could_ be
made to work if we find all of the boundary commits and treat them as
UNINTERESTING, subtracting them (and their reachable objects) from the
set we return. That implies an actual commit traversal, but we'd still
be faster due to avoiding opening up any trees. Given the complexity and
the fact that anyone is unlikely to want this, it makes sense to just
fall back to the non-bitmap case for now.
Signed-off-by: Jeff King <peff@peff.net>
---
builtin/rev-list.c | 21 ++++++++++++++++++---
t/t5310-pack-bitmaps.sh | 6 ++++++
2 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/builtin/rev-list.c b/builtin/rev-list.c
index 9452123988..70f3207ecc 100644
--- a/builtin/rev-list.c
+++ b/builtin/rev-list.c
@@ -374,7 +374,10 @@ static inline int parse_missing_action_value(const char *value)
static int try_bitmap_count(struct rev_info *revs)
{
- uint32_t commit_count;
+ uint32_t commit_count = 0,
+ tag_count = 0,
+ tree_count = 0,
+ blob_count = 0;
int max_count;
struct bitmap_index *bitmap_git;
@@ -389,6 +392,15 @@ static int try_bitmap_count(struct rev_info *revs)
if (revs->left_right || revs->cherry_mark)
return -1;
+ /*
+ * If we're counting reachable objects, we can't handle a max count of
+ * commits to traverse, since we don't know which objects go with which
+ * commit.
+ */
+ if (revs->max_count >= 0 &&
+ (revs->tag_objects || revs->tree_objects || revs->blob_objects))
+ return -1;
+
/*
* This must be saved before doing any walking, since the revision
* machinery will count it down to zero while traversing.
@@ -399,11 +411,14 @@ static int try_bitmap_count(struct rev_info *revs)
if (!bitmap_git)
return -1;
- count_bitmap_commit_list(bitmap_git, &commit_count, NULL, NULL, NULL);
+ count_bitmap_commit_list(bitmap_git, &commit_count,
+ revs->tree_objects ? &tree_count : NULL,
+ revs->blob_objects ? &blob_count : NULL,
+ revs->tag_objects ? &tag_count : NULL);
if (max_count >= 0 && max_count < commit_count)
commit_count = max_count;
- printf("%d\n", commit_count);
+ printf("%d\n", commit_count + tree_count + blob_count + tag_count);
free_bitmap_index(bitmap_git);
return 0;
}
diff --git a/t/t5310-pack-bitmaps.sh b/t/t5310-pack-bitmaps.sh
index 6640329ebf..7ba7d294a5 100755
--- a/t/t5310-pack-bitmaps.sh
+++ b/t/t5310-pack-bitmaps.sh
@@ -74,6 +74,12 @@ rev_list_tests() {
test_cmp expect actual
'
+ test_expect_success "counting objects via bitmap ($state)" '
+ git rev-list --count --objects HEAD >expect &&
+ git rev-list --use-bitmap-index --count --objects HEAD >actual &&
+ test_cmp expect actual
+ '
+
test_expect_success "enumerate --objects ($state)" '
git rev-list --objects --use-bitmap-index HEAD >tmp &&
cut -d" " -f1 <tmp >tmp2 &&
--
2.25.0.796.gcc29325708
^ permalink raw reply related
* [PATCH v2 08/15] t5310: factor out bitmap traversal comparison
From: Jeff King @ 2020-02-14 18:22 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <20200214182147.GA654525@coredump.intra.peff.net>
We check the results of "rev-list --use-bitmap-index" by comparing it to
the same traversal without the bitmap option. However, this is a little
tricky to do because of some output differences (see the included
comment for details). Let's pull this out into a helper function, since
we'll be adding some similar tests.
While we're at it, let's also try to confirm that the bitmap output did
indeed use bitmaps. Since the code internally falls back to the
non-bitmap path in some cases, the tests are at risk of becoming trivial
noops.
This is a bit fragile, as not all outputs will differ (e.g., looking at
only the commits from a fully-bitmapped pack will end up exactly the
same as the normal traversal order, since it also matches the pack
order). So we'll provide an escape hatch by which tests can disable this
check (which should only be used after manually confirming that bitmaps
kicked in).
Signed-off-by: Jeff King <peff@peff.net>
---
t/t5310-pack-bitmaps.sh | 10 +++-------
t/test-lib-functions.sh | 27 +++++++++++++++++++++++++++
2 files changed, 30 insertions(+), 7 deletions(-)
diff --git a/t/t5310-pack-bitmaps.sh b/t/t5310-pack-bitmaps.sh
index 7ba7d294a5..b8645ae070 100755
--- a/t/t5310-pack-bitmaps.sh
+++ b/t/t5310-pack-bitmaps.sh
@@ -81,13 +81,9 @@ rev_list_tests() {
'
test_expect_success "enumerate --objects ($state)" '
- git rev-list --objects --use-bitmap-index HEAD >tmp &&
- cut -d" " -f1 <tmp >tmp2 &&
- sort <tmp2 >actual &&
- git rev-list --objects HEAD >tmp &&
- cut -d" " -f1 <tmp >tmp2 &&
- sort <tmp2 >expect &&
- test_cmp expect actual
+ git rev-list --objects --use-bitmap-index HEAD >actual &&
+ git rev-list --objects HEAD >expect &&
+ test_bitmap_traversal expect actual
'
test_expect_success "bitmap --objects handles non-commit objects ($state)" '
diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
index 284c52d076..352c213d52 100644
--- a/t/test-lib-functions.sh
+++ b/t/test-lib-functions.sh
@@ -1516,3 +1516,30 @@ test_set_port () {
port=$(($port + ${GIT_TEST_STRESS_JOB_NR:-0}))
eval $var=$port
}
+
+# Compare a file containing rev-list bitmap traversal output to its non-bitmap
+# counterpart. You can't just use test_cmp for this, because the two produce
+# subtly different output:
+#
+# - regular output is in traversal order, whereas bitmap is split by type,
+# with non-packed objects at the end
+#
+# - regular output has a space and the pathname appended to non-commit
+# objects; bitmap output omits this
+#
+# This function normalizes and compares the two. The second file should
+# always be the bitmap output.
+test_bitmap_traversal () {
+ if test "$1" = "--no-confirm-bitmaps"
+ then
+ shift
+ elif cmp "$1" "$2"
+ then
+ echo >&2 "identical raw outputs; are you sure bitmaps were used?"
+ return 1
+ fi &&
+ cut -d' ' -f1 "$1" | sort >"$1.normalized" &&
+ sort "$2" >"$2.normalized" &&
+ test_cmp "$1.normalized" "$2.normalized" &&
+ rm -f "$1.normalized" "$2.normalized"
+}
--
2.25.0.796.gcc29325708
^ permalink raw reply related
* [PATCH v2 06/15] rev-list: make --count work with --objects
From: Jeff King @ 2020-02-14 18:22 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <20200214182147.GA654525@coredump.intra.peff.net>
The current behavior from "rev-list --count --objects" is nonsensical:
we enumerate all of the objects except commits, but then give a count of
commits. This wasn't planned, and is just what the code happens to do.
Instead, let's give the answer the user almost certainly wanted: the
full count of objects.
Note that there are more complicated cases around cherry-marking, etc.
We'll punt on those for now, but let the user know that we can't produce
an answer (rather than giving them something useless).
We'll test both the new feature as well as a vanilla --count of commits,
since that surprisingly doesn't seem to be covered in the existing
tests.
Signed-off-by: Jeff King <peff@peff.net>
---
builtin/rev-list.c | 13 +++++++++++++
t/t6000-rev-list-misc.sh | 12 ++++++++++++
2 files changed, 25 insertions(+)
diff --git a/builtin/rev-list.c b/builtin/rev-list.c
index 38c5ca5603..9452123988 100644
--- a/builtin/rev-list.c
+++ b/builtin/rev-list.c
@@ -253,11 +253,19 @@ static int finish_object(struct object *obj, const char *name, void *cb_data)
static void show_object(struct object *obj, const char *name, void *cb_data)
{
struct rev_list_info *info = cb_data;
+ struct rev_info *revs = info->revs;
+
if (finish_object(obj, name, cb_data))
return;
display_progress(progress, ++progress_counter);
if (info->flags & REV_LIST_QUIET)
return;
+
+ if (revs->count) {
+ revs->count_right++;
+ return;
+ }
+
if (arg_show_object_names)
show_object_with_name(stdout, obj, name);
else
@@ -584,6 +592,11 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
if (revs.show_notes)
die(_("rev-list does not support display of notes"));
+ if (revs.count &&
+ (revs.tag_objects || revs.tree_objects || revs.blob_objects) &&
+ (revs.left_right || revs.cherry_mark))
+ die(_("marked counting is incompatible with --objects"));
+
if (filter_options.choice)
use_bitmap_index = 0;
diff --git a/t/t6000-rev-list-misc.sh b/t/t6000-rev-list-misc.sh
index b8cf82349b..383f2c457d 100755
--- a/t/t6000-rev-list-misc.sh
+++ b/t/t6000-rev-list-misc.sh
@@ -148,4 +148,16 @@ test_expect_success 'rev-list --end-of-options' '
test_cmp expect actual
'
+test_expect_success 'rev-list --count' '
+ count=$(git rev-list --count HEAD) &&
+ git rev-list HEAD >actual &&
+ test_line_count = $count actual
+'
+
+test_expect_success 'rev-list --count --objects' '
+ count=$(git rev-list --count --objects HEAD) &&
+ git rev-list --objects HEAD >actual &&
+ test_line_count = $count actual
+'
+
test_done
--
2.25.0.796.gcc29325708
^ permalink raw reply related
* [PATCH v2 05/15] rev-list: factor out bitmap-optimized routines
From: Jeff King @ 2020-02-14 18:22 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <20200214182147.GA654525@coredump.intra.peff.net>
There are a few operations in rev-list that are optimized for bitmaps.
Rather than having the code inline in cmd_rev_list(), let's move them
into helpers. This not only makes the flow of the main function simpler,
but it lets us replace the complex "can we do the optimization?"
conditionals with a series of early returns from the functions. That
also makes it easy to add comments explaining those conditions.
Signed-off-by: Jeff King <peff@peff.net>
---
builtin/rev-list.c | 88 +++++++++++++++++++++++++++++++++++-----------
1 file changed, 67 insertions(+), 21 deletions(-)
diff --git a/builtin/rev-list.c b/builtin/rev-list.c
index 4cb5a52dee..38c5ca5603 100644
--- a/builtin/rev-list.c
+++ b/builtin/rev-list.c
@@ -364,6 +364,69 @@ static inline int parse_missing_action_value(const char *value)
return 0;
}
+static int try_bitmap_count(struct rev_info *revs)
+{
+ uint32_t commit_count;
+ int max_count;
+ struct bitmap_index *bitmap_git;
+
+ /* This function only handles counting, not general traversal. */
+ if (!revs->count)
+ return -1;
+
+ /*
+ * A bitmap result can't know left/right, etc, because we don't
+ * actually traverse.
+ */
+ if (revs->left_right || revs->cherry_mark)
+ return -1;
+
+ /*
+ * This must be saved before doing any walking, since the revision
+ * machinery will count it down to zero while traversing.
+ */
+ max_count = revs->max_count;
+
+ bitmap_git = prepare_bitmap_walk(revs);
+ if (!bitmap_git)
+ return -1;
+
+ count_bitmap_commit_list(bitmap_git, &commit_count, NULL, NULL, NULL);
+ if (max_count >= 0 && max_count < commit_count)
+ commit_count = max_count;
+
+ printf("%d\n", commit_count);
+ free_bitmap_index(bitmap_git);
+ return 0;
+}
+
+static int try_bitmap_traversal(struct rev_info *revs)
+{
+ struct bitmap_index *bitmap_git;
+
+ /*
+ * We can't use a bitmap result with a traversal limit, since the set
+ * of commits we'd get would be essentially random.
+ */
+ if (revs->max_count >= 0)
+ return -1;
+
+ /*
+ * Our bitmap result will return all objects, and we're not
+ * yet prepared to show only particular types.
+ */
+ if (!revs->tag_objects || !revs->tree_objects || !revs->blob_objects)
+ return -1;
+
+ bitmap_git = prepare_bitmap_walk(revs);
+ if (!bitmap_git)
+ return -1;
+
+ traverse_bitmap_commit_list(bitmap_git, &show_object_fast);
+ free_bitmap_index(bitmap_git);
+ return 0;
+}
+
int cmd_rev_list(int argc, const char **argv, const char *prefix)
{
struct rev_info revs;
@@ -534,27 +597,10 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
progress = start_delayed_progress(show_progress, 0);
if (use_bitmap_index) {
- if (revs.count && !revs.left_right && !revs.cherry_mark) {
- uint32_t commit_count;
- int max_count = revs.max_count;
- struct bitmap_index *bitmap_git;
- if ((bitmap_git = prepare_bitmap_walk(&revs))) {
- count_bitmap_commit_list(bitmap_git, &commit_count, NULL, NULL, NULL);
- if (max_count >= 0 && max_count < commit_count)
- commit_count = max_count;
- printf("%d\n", commit_count);
- free_bitmap_index(bitmap_git);
- return 0;
- }
- } else if (revs.max_count < 0 &&
- revs.tag_objects && revs.tree_objects && revs.blob_objects) {
- struct bitmap_index *bitmap_git;
- if ((bitmap_git = prepare_bitmap_walk(&revs))) {
- traverse_bitmap_commit_list(bitmap_git, &show_object_fast);
- free_bitmap_index(bitmap_git);
- return 0;
- }
- }
+ if (!try_bitmap_count(&revs))
+ return 0;
+ if (!try_bitmap_traversal(&revs))
+ return 0;
}
if (prepare_revision_walk(&revs))
--
2.25.0.796.gcc29325708
^ permalink raw reply related
* [PATCH v2 04/15] pack-bitmap: refuse to do a bitmap traversal with pathspecs
From: Jeff King @ 2020-02-14 18:22 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <20200214182147.GA654525@coredump.intra.peff.net>
rev-list has refused to use bitmaps with pathspec limiting since
c8a70d3509 (rev-list: disable --use-bitmap-index when pruning commits,
2015-07-01). But this is true not just for rev-list, but for anyone who
calls prepare_bitmap_walk(); the code isn't equipped to handle this
case. We never noticed because the only other callers would never pass
a pathspec limiter.
But let's push the check down into prepare_bitmap_walk() anyway. That's
a more logical place for it to live, as callers shouldn't need to know
the details (and must be prepared to fall back to a regular traversal
anyway, since there might not be bitmaps in the repository).
It would also prepare us for a day where this case _is_ handled, but
that's pretty unlikely. E.g., we could use bitmaps to generate the set
of commits, and then diff each commit to see if it matches the pathspec.
That would be slightly faster than a naive traversal that actually walks
the commits. But you'd probably do better still to make use of the newer
commit-graph feature to make walking the commits very cheap.
Signed-off-by: Jeff King <peff@peff.net>
---
builtin/rev-list.c | 2 +-
pack-bitmap.c | 12 +++++++++++-
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/builtin/rev-list.c b/builtin/rev-list.c
index bce406bd1e..4cb5a52dee 100644
--- a/builtin/rev-list.c
+++ b/builtin/rev-list.c
@@ -533,7 +533,7 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
if (show_progress)
progress = start_delayed_progress(show_progress, 0);
- if (use_bitmap_index && !revs.prune) {
+ if (use_bitmap_index) {
if (revs.count && !revs.left_right && !revs.cherry_mark) {
uint32_t commit_count;
int max_count = revs.max_count;
diff --git a/pack-bitmap.c b/pack-bitmap.c
index 6c06099dc7..a97b717e55 100644
--- a/pack-bitmap.c
+++ b/pack-bitmap.c
@@ -715,9 +715,19 @@ struct bitmap_index *prepare_bitmap_walk(struct rev_info *revs)
struct bitmap *wants_bitmap = NULL;
struct bitmap *haves_bitmap = NULL;
- struct bitmap_index *bitmap_git = xcalloc(1, sizeof(*bitmap_git));
+ struct bitmap_index *bitmap_git;
+
+ /*
+ * We can't do pathspec limiting with bitmaps, because we don't know
+ * which commits are associated with which object changes (let alone
+ * even which objects are associated with which paths).
+ */
+ if (revs->prune)
+ return NULL;
+
/* try to open a bitmapped pack, but don't parse it yet
* because we may not need to use it */
+ bitmap_git = xcalloc(1, sizeof(*bitmap_git));
if (open_pack_bitmap(revs->repo, bitmap_git) < 0)
goto cleanup;
--
2.25.0.796.gcc29325708
^ permalink raw reply related
* [PATCH v2 03/15] rev-list: fallback to non-bitmap traversal when filtering
From: Jeff King @ 2020-02-14 18:22 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <20200214182147.GA654525@coredump.intra.peff.net>
The "--use-bitmap-index" option is usually aspirational: if we have
bitmaps and the request can be fulfilled more quickly using them we'll
do so, but otherwise fall back to a non-bitmap traversal.
The exception is object filtering, which explicitly dies if the two
options are combined. Let's convert this to the usual fallback behavior.
This is a minor convenience for now (since the caller can easily know
that --filter and --use-bitmap-index don't combine), but will become
much more useful as we start to support _some_ filters with bitmaps, but
not others.
The test infrastructure here is bigger than necessary for checking this
one small feature. But it will serve as the basis for more filtering
bitmap tests in future patches.
Signed-off-by: Jeff King <peff@peff.net>
---
builtin/rev-list.c | 4 ++--
t/t6113-rev-list-bitmap-filters.sh | 24 ++++++++++++++++++++++++
2 files changed, 26 insertions(+), 2 deletions(-)
create mode 100755 t/t6113-rev-list-bitmap-filters.sh
diff --git a/builtin/rev-list.c b/builtin/rev-list.c
index e28d62ec64..bce406bd1e 100644
--- a/builtin/rev-list.c
+++ b/builtin/rev-list.c
@@ -521,8 +521,8 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
if (revs.show_notes)
die(_("rev-list does not support display of notes"));
- if (filter_options.choice && use_bitmap_index)
- die(_("cannot combine --use-bitmap-index with object filtering"));
+ if (filter_options.choice)
+ use_bitmap_index = 0;
save_commit_buffer = (revs.verbose_header ||
revs.grep_filter.pattern_list ||
diff --git a/t/t6113-rev-list-bitmap-filters.sh b/t/t6113-rev-list-bitmap-filters.sh
new file mode 100755
index 0000000000..977f8d0930
--- /dev/null
+++ b/t/t6113-rev-list-bitmap-filters.sh
@@ -0,0 +1,24 @@
+#!/bin/sh
+
+test_description='rev-list combining bitmaps and filters'
+. ./test-lib.sh
+
+test_expect_success 'set up bitmapped repo' '
+ # one commit will have bitmaps, the other will not
+ test_commit one &&
+ git repack -adb &&
+ test_commit two
+'
+
+test_expect_success 'filters fallback to non-bitmap traversal' '
+ # use a path-based filter, since they are inherently incompatible with
+ # bitmaps (i.e., this test will never get confused by later code to
+ # combine the features)
+ filter=$(echo "!one" | git hash-object -w --stdin) &&
+ git rev-list --objects --filter=sparse:oid=$filter HEAD >expect &&
+ git rev-list --use-bitmap-index \
+ --objects --filter=sparse:oid=$filter HEAD >actual &&
+ test_cmp expect actual
+'
+
+test_done
--
2.25.0.796.gcc29325708
^ permalink raw reply related
* [PATCH v2 01/15] pack-bitmap: factor out type iterator initialization
From: Jeff King @ 2020-02-14 18:22 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <20200214182147.GA654525@coredump.intra.peff.net>
When count_object_type() wants to iterate over the bitmap of all objects
of a certain type, we have to pair up OBJ_COMMIT with bitmap->commits,
and so forth. Since we're about to add more code to iterate over these
bitmaps, let's pull the initialization into its own function.
We can also use this to simplify traverse_bitmap_commit_list(). It
accomplishes the same thing by manually passing the object type and the
bitmap to show_objects_for_type(), but using our helper we just need the
object type.
Note there's one small code change here: previously we'd simply return
zero when counting an unknown object type, and now we'll BUG(). This
shouldn't matter in practice, as all of the callers pass in only usual
commit/tree/blob/tag types.
Signed-off-by: Jeff King <peff@peff.net>
---
pack-bitmap.c | 63 +++++++++++++++++++++++++++------------------------
1 file changed, 33 insertions(+), 30 deletions(-)
diff --git a/pack-bitmap.c b/pack-bitmap.c
index e07c798879..9ca356ee29 100644
--- a/pack-bitmap.c
+++ b/pack-bitmap.c
@@ -616,9 +616,35 @@ static void show_extended_objects(struct bitmap_index *bitmap_git,
}
}
+static void init_type_iterator(struct ewah_iterator *it,
+ struct bitmap_index *bitmap_git,
+ enum object_type type)
+{
+ switch (type) {
+ case OBJ_COMMIT:
+ ewah_iterator_init(it, bitmap_git->commits);
+ break;
+
+ case OBJ_TREE:
+ ewah_iterator_init(it, bitmap_git->trees);
+ break;
+
+ case OBJ_BLOB:
+ ewah_iterator_init(it, bitmap_git->blobs);
+ break;
+
+ case OBJ_TAG:
+ ewah_iterator_init(it, bitmap_git->tags);
+ break;
+
+ default:
+ BUG("object type %d not stored by bitmap type index", type);
+ break;
+ }
+}
+
static void show_objects_for_type(
struct bitmap_index *bitmap_git,
- struct ewah_bitmap *type_filter,
enum object_type object_type,
show_reachable_fn show_reach)
{
@@ -633,7 +659,7 @@ static void show_objects_for_type(
if (bitmap_git->reuse_objects == bitmap_git->pack->num_objects)
return;
- ewah_iterator_init(&it, type_filter);
+ init_type_iterator(&it, bitmap_git, object_type);
while (i < objects->word_alloc && ewah_iterator_next(&filter, &it)) {
eword_t word = objects->words[i] & filter;
@@ -835,14 +861,10 @@ void traverse_bitmap_commit_list(struct bitmap_index *bitmap_git,
{
assert(bitmap_git->result);
- show_objects_for_type(bitmap_git, bitmap_git->commits,
- OBJ_COMMIT, show_reachable);
- show_objects_for_type(bitmap_git, bitmap_git->trees,
- OBJ_TREE, show_reachable);
- show_objects_for_type(bitmap_git, bitmap_git->blobs,
- OBJ_BLOB, show_reachable);
- show_objects_for_type(bitmap_git, bitmap_git->tags,
- OBJ_TAG, show_reachable);
+ show_objects_for_type(bitmap_git, OBJ_COMMIT, show_reachable);
+ show_objects_for_type(bitmap_git, OBJ_TREE, show_reachable);
+ show_objects_for_type(bitmap_git, OBJ_BLOB, show_reachable);
+ show_objects_for_type(bitmap_git, OBJ_TAG, show_reachable);
show_extended_objects(bitmap_git, show_reachable);
}
@@ -857,26 +879,7 @@ static uint32_t count_object_type(struct bitmap_index *bitmap_git,
struct ewah_iterator it;
eword_t filter;
- switch (type) {
- case OBJ_COMMIT:
- ewah_iterator_init(&it, bitmap_git->commits);
- break;
-
- case OBJ_TREE:
- ewah_iterator_init(&it, bitmap_git->trees);
- break;
-
- case OBJ_BLOB:
- ewah_iterator_init(&it, bitmap_git->blobs);
- break;
-
- case OBJ_TAG:
- ewah_iterator_init(&it, bitmap_git->tags);
- break;
-
- default:
- return 0;
- }
+ init_type_iterator(&it, bitmap_git, type);
while (i < objects->word_alloc && ewah_iterator_next(&filter, &it)) {
eword_t word = objects->words[i++] & filter;
--
2.25.0.796.gcc29325708
^ permalink raw reply related
* Re: [PATCH v5 1/7] mm: pass task and mm to do_madvise
From: Jens Axboe @ 2020-02-14 18:22 UTC (permalink / raw)
To: Jann Horn, Minchan Kim, io-uring
Cc: Andrew Morton, LKML, linux-mm, Linux API, Oleksandr Natalenko,
Suren Baghdasaryan, Tim Murray, Daniel Colascione, Sandeep Patil,
Sonny Rao, Brian Geffon, Michal Hocko, Johannes Weiner,
Shakeel Butt, John Dias, Joel Fernandes, sj38.park,
Alexander Duyck
In-Reply-To: <CAG48ez3S5+EasZ1ZWcMQYZQQ5zJOBtY-_C7oz6DMfG4Gcyig1g@mail.gmail.com>
On 2/14/20 10:25 AM, Jann Horn wrote:
> +Jens and io-uring list
>
> On Fri, Feb 14, 2020 at 6:06 PM Minchan Kim <minchan@kernel.org> wrote:
>> In upcoming patches, do_madvise will be called from external process
>> context so we shouldn't asssume "current" is always hinted process's
>> task_struct.
> [...]
>> [1] http://lore.kernel.org/r/CAG48ez27=pwm5m_N_988xT1huO7g7h6arTQL44zev6TD-h-7Tg@mail.gmail.com
> [...]
>> diff --git a/fs/io_uring.c b/fs/io_uring.c
> [...]
>> @@ -2736,7 +2736,7 @@ static int io_madvise(struct io_kiocb *req, struct io_kiocb **nxt,
>> if (force_nonblock)
>> return -EAGAIN;
>>
>> - ret = do_madvise(ma->addr, ma->len, ma->advice);
>> + ret = do_madvise(current, current->mm, ma->addr, ma->len, ma->advice);
>> if (ret < 0)
>> req_set_fail_links(req);
>> io_cqring_add_event(req, ret);
>
> Jens, can you have a look at this change and the following patch
> <https://lore.kernel.org/linux-mm/20200214170520.160271-4-minchan@kernel.org/>
> ("[PATCH v5 3/7] mm: check fatal signal pending of target process")?
> Basically Minchan's patch tries to plumb through the identity of the
> target task so that if that task gets killed in the middle of the
> operation, the (potentially long-running and costly) madvise operation
> can be cancelled. Just passing in "current" instead (which in this
> case is the uring worker thread AFAIK) doesn't really break anything,
> other than making the optimization not work, but I wonder whether this
> couldn't be done more cleanly - maybe by passing in NULL to mean "we
> don't know who the target task is", since I think we don't know that
> here?
Thanks for bringing this to my attention, patches that touch io_uring
(or anything else) really should be CC'ed to the maintainer(s) of those
areas...
Yeah, the change above won't do the right thing for io_uring, in fact
it'll always be the wrong task. So I'd second Jann's question, and ask
if we really need the actual task, or if NULL could be used? For
cancelation purposes, I'm guessing you want the task that's actually
doing the operation, even if it's on behalf of someone else. That makes
the interface a bit weird, as you'd assume the task/mm passed in would
be related to the madvise itself, not just for cancelation.
Would be nice with some clarification, so we can figure out an approach
that would actually work.
--
Jens Axboe
^ permalink raw reply
* [PATCH 13/19] target/arm: Move VLLDM and VLSTM to vfp.decode
From: Richard Henderson @ 2020-02-14 18:15 UTC (permalink / raw)
To: qemu-devel; +Cc: peter.maydell
In-Reply-To: <20200214181547.21408-1-richard.henderson@linaro.org>
Now that we no longer have an early check for ARM_FEATURE_VFP,
we can use the proper ISA check in trans_VLLDM_VLSTM.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
---
target/arm/vfp.decode | 2 ++
target/arm/translate-vfp.inc.c | 35 ++++++++++++++++++++++
target/arm/translate.c | 53 ++++++----------------------------
3 files changed, 46 insertions(+), 44 deletions(-)
diff --git a/target/arm/vfp.decode b/target/arm/vfp.decode
index a67b3f29ee..592fe9e1e4 100644
--- a/target/arm/vfp.decode
+++ b/target/arm/vfp.decode
@@ -242,3 +242,5 @@ VCVT_sp_int ---- 1110 1.11 110 s:1 .... 1010 rz:1 1.0 .... \
vd=%vd_sp vm=%vm_sp
VCVT_dp_int ---- 1110 1.11 110 s:1 .... 1011 rz:1 1.0 .... \
vd=%vd_sp vm=%vm_dp
+
+VLLDM_VLSTM 1110 1100 001 l:1 rn:4 0000 1010 0000 0000
diff --git a/target/arm/translate-vfp.inc.c b/target/arm/translate-vfp.inc.c
index f6f7601fe2..8f2b97e0e7 100644
--- a/target/arm/translate-vfp.inc.c
+++ b/target/arm/translate-vfp.inc.c
@@ -2816,3 +2816,38 @@ static bool trans_VCVT_dp_int(DisasContext *s, arg_VCVT_dp_int *a)
tcg_temp_free_ptr(fpst);
return true;
}
+
+/*
+ * Decode VLLDM of VLSTM are nonstandard because:
+ * * if there is no FPU then these insns must NOP in
+ * Secure state and UNDEF in Nonsecure state
+ * * if there is an FPU then these insns do not have
+ * the usual behaviour that disas_vfp_insn() provides of
+ * being controlled by CPACR/NSACR enable bits or the
+ * lazy-stacking logic.
+ */
+static bool trans_VLLDM_VLSTM(DisasContext *s, arg_VLLDM_VLSTM *a)
+{
+ TCGv_i32 fptr;
+
+ if (!arm_dc_feature(s, ARM_FEATURE_M) ||
+ !arm_dc_feature(s, ARM_FEATURE_V8)) {
+ return false;
+ }
+ if (!dc_isar_feature(aa32_fpsp_v2, s)) {
+ /* No FPU: NOP if secure, otherwise UNDEF. */
+ return s->v8m_secure;
+ }
+
+ fptr = load_reg(s, a->rn);
+ if (a->l) {
+ gen_helper_v7m_vlldm(cpu_env, fptr);
+ } else {
+ gen_helper_v7m_vlstm(cpu_env, fptr);
+ }
+ tcg_temp_free_i32(fptr);
+
+ /* End the TB, because we have updated FP control bits */
+ s->base.is_jmp = DISAS_UPDATE;
+ return true;
+}
diff --git a/target/arm/translate.c b/target/arm/translate.c
index e8c3d4f26f..b2641b4262 100644
--- a/target/arm/translate.c
+++ b/target/arm/translate.c
@@ -10708,53 +10708,18 @@ static void disas_thumb2_insn(DisasContext *s, uint32_t insn)
goto illegal_op; /* op0 = 0b11 : unallocated */
}
- /*
- * Decode VLLDM and VLSTM first: these are nonstandard because:
- * * if there is no FPU then these insns must NOP in
- * Secure state and UNDEF in Nonsecure state
- * * if there is an FPU then these insns do not have
- * the usual behaviour that disas_vfp_insn() provides of
- * being controlled by CPACR/NSACR enable bits or the
- * lazy-stacking logic.
- */
- if (arm_dc_feature(s, ARM_FEATURE_V8) &&
- (insn & 0xffa00f00) == 0xec200a00) {
- /* 0b1110_1100_0x1x_xxxx_xxxx_1010_xxxx_xxxx
- * - VLLDM, VLSTM
- * We choose to UNDEF if the RAZ bits are non-zero.
- */
- if (!s->v8m_secure || (insn & 0x0040f0ff)) {
+ if (disas_vfp_insn(s, insn)) {
+ if (((insn >> 8) & 0xe) == 10 &&
+ dc_isar_feature(aa32_fpsp_v2, s)) {
+ /* FP, and the CPU supports it */
goto illegal_op;
+ } else {
+ /* All other insns: NOCP */
+ gen_exception_insn(s, s->pc_curr, EXCP_NOCP,
+ syn_uncategorized(),
+ default_exception_el(s));
}
-
- if (arm_dc_feature(s, ARM_FEATURE_VFP)) {
- uint32_t rn = (insn >> 16) & 0xf;
- TCGv_i32 fptr = load_reg(s, rn);
-
- if (extract32(insn, 20, 1)) {
- gen_helper_v7m_vlldm(cpu_env, fptr);
- } else {
- gen_helper_v7m_vlstm(cpu_env, fptr);
- }
- tcg_temp_free_i32(fptr);
-
- /* End the TB, because we have updated FP control bits */
- s->base.is_jmp = DISAS_UPDATE;
- }
- break;
}
- if (arm_dc_feature(s, ARM_FEATURE_VFP) &&
- ((insn >> 8) & 0xe) == 10) {
- /* FP, and the CPU supports it */
- if (disas_vfp_insn(s, insn)) {
- goto illegal_op;
- }
- break;
- }
-
- /* All other insns: NOCP */
- gen_exception_insn(s, s->pc_curr, EXCP_NOCP, syn_uncategorized(),
- default_exception_el(s));
break;
}
if ((insn & 0xfe000a00) == 0xfc000800
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.5 027/542] brcmfmac: Fix use after free in brcmf_sdio_readframes()
From: Sasha Levin @ 2020-02-14 15:40 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Dan Carpenter, Franky Lin, Kalle Valo, Sasha Levin,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
netdev
In-Reply-To: <20200214154854.6746-1-sashal@kernel.org>
From: Dan Carpenter <dan.carpenter@oracle.com>
[ Upstream commit 216b44000ada87a63891a8214c347e05a4aea8fe ]
The brcmu_pkt_buf_free_skb() function frees "pkt" so it leads to a
static checker warning:
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:1974 brcmf_sdio_readframes()
error: dereferencing freed memory 'pkt'
It looks like there was supposed to be a continue after we free "pkt".
Fixes: 4754fceeb9a6 ("brcmfmac: streamline SDIO read frame routine")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index 264ad63232f87..1dea0178832ea 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -1935,6 +1935,7 @@ static uint brcmf_sdio_readframes(struct brcmf_sdio *bus, uint maxframes)
BRCMF_SDIO_FT_NORMAL)) {
rd->len = 0;
brcmu_pkt_buf_free_skb(pkt);
+ continue;
}
bus->sdcnt.rx_readahead_cnt++;
if (rd->len != roundup(rd_new.len, 16)) {
--
2.20.1
^ permalink raw reply related
* [PATCH 06/19] target/arm: Rename isar_feature_aa32_fpdp_v2
From: Richard Henderson @ 2020-02-14 18:15 UTC (permalink / raw)
To: qemu-devel; +Cc: peter.maydell
In-Reply-To: <20200214181547.21408-1-richard.henderson@linaro.org>
The old name, isar_feature_aa32_fpdp, does not reflect
that the test includes VFPv2. We will introduce another
feature tests for VFPv3.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
---
target/arm/cpu.h | 4 ++--
target/arm/translate-vfp.inc.c | 40 +++++++++++++++++-----------------
2 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 85b90eaed2..5f08cbd2d8 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -3429,9 +3429,9 @@ static inline bool isar_feature_aa32_fpshvec(const ARMISARegisters *id)
return FIELD_EX32(id->mvfr0, MVFR0, FPSHVEC) > 0;
}
-static inline bool isar_feature_aa32_fpdp(const ARMISARegisters *id)
+static inline bool isar_feature_aa32_fpdp_v2(const ARMISARegisters *id)
{
- /* Return true if CPU supports double precision floating point */
+ /* Return true if CPU supports double precision floating point, VFPv2 */
return FIELD_EX32(id->mvfr0, MVFR0, FPDP) > 0;
}
diff --git a/target/arm/translate-vfp.inc.c b/target/arm/translate-vfp.inc.c
index 96a1d727c6..5290828d0d 100644
--- a/target/arm/translate-vfp.inc.c
+++ b/target/arm/translate-vfp.inc.c
@@ -206,7 +206,7 @@ static bool trans_VSEL(DisasContext *s, arg_VSEL *a)
return false;
}
- if (dp && !dc_isar_feature(aa32_fpdp, s)) {
+ if (dp && !dc_isar_feature(aa32_fpdp_v2, s)) {
return false;
}
@@ -339,7 +339,7 @@ static bool trans_VMINMAXNM(DisasContext *s, arg_VMINMAXNM *a)
return false;
}
- if (dp && !dc_isar_feature(aa32_fpdp, s)) {
+ if (dp && !dc_isar_feature(aa32_fpdp_v2, s)) {
return false;
}
@@ -425,7 +425,7 @@ static bool trans_VRINT(DisasContext *s, arg_VRINT *a)
return false;
}
- if (dp && !dc_isar_feature(aa32_fpdp, s)) {
+ if (dp && !dc_isar_feature(aa32_fpdp_v2, s)) {
return false;
}
@@ -488,7 +488,7 @@ static bool trans_VCVT(DisasContext *s, arg_VCVT *a)
return false;
}
- if (dp && !dc_isar_feature(aa32_fpdp, s)) {
+ if (dp && !dc_isar_feature(aa32_fpdp_v2, s)) {
return false;
}
@@ -1313,7 +1313,7 @@ static bool do_vfp_3op_dp(DisasContext *s, VFPGen3OpDPFn *fn,
return false;
}
- if (!dc_isar_feature(aa32_fpdp, s)) {
+ if (!dc_isar_feature(aa32_fpdp_v2, s)) {
return false;
}
@@ -1462,7 +1462,7 @@ static bool do_vfp_2op_dp(DisasContext *s, VFPGen2OpDPFn *fn, int vd, int vm)
return false;
}
- if (!dc_isar_feature(aa32_fpdp, s)) {
+ if (!dc_isar_feature(aa32_fpdp_v2, s)) {
return false;
}
@@ -1826,7 +1826,7 @@ static bool trans_VFM_dp(DisasContext *s, arg_VFM_dp *a)
return false;
}
- if (!dc_isar_feature(aa32_fpdp, s)) {
+ if (!dc_isar_feature(aa32_fpdp_v2, s)) {
return false;
}
@@ -1925,7 +1925,7 @@ static bool trans_VMOV_imm_dp(DisasContext *s, arg_VMOV_imm_dp *a)
return false;
}
- if (!dc_isar_feature(aa32_fpdp, s)) {
+ if (!dc_isar_feature(aa32_fpdp_v2, s)) {
return false;
}
@@ -2069,7 +2069,7 @@ static bool trans_VCMP_dp(DisasContext *s, arg_VCMP_dp *a)
return false;
}
- if (!dc_isar_feature(aa32_fpdp, s)) {
+ if (!dc_isar_feature(aa32_fpdp_v2, s)) {
return false;
}
@@ -2142,7 +2142,7 @@ static bool trans_VCVT_f64_f16(DisasContext *s, arg_VCVT_f64_f16 *a)
return false;
}
- if (!dc_isar_feature(aa32_fpdp, s)) {
+ if (!dc_isar_feature(aa32_fpdp_v2, s)) {
return false;
}
@@ -2208,7 +2208,7 @@ static bool trans_VCVT_f16_f64(DisasContext *s, arg_VCVT_f16_f64 *a)
return false;
}
- if (!dc_isar_feature(aa32_fpdp, s)) {
+ if (!dc_isar_feature(aa32_fpdp_v2, s)) {
return false;
}
@@ -2268,7 +2268,7 @@ static bool trans_VRINTR_dp(DisasContext *s, arg_VRINTR_dp *a)
return false;
}
- if (!dc_isar_feature(aa32_fpdp, s)) {
+ if (!dc_isar_feature(aa32_fpdp_v2, s)) {
return false;
}
@@ -2329,7 +2329,7 @@ static bool trans_VRINTZ_dp(DisasContext *s, arg_VRINTZ_dp *a)
return false;
}
- if (!dc_isar_feature(aa32_fpdp, s)) {
+ if (!dc_isar_feature(aa32_fpdp_v2, s)) {
return false;
}
@@ -2388,7 +2388,7 @@ static bool trans_VRINTX_dp(DisasContext *s, arg_VRINTX_dp *a)
return false;
}
- if (!dc_isar_feature(aa32_fpdp, s)) {
+ if (!dc_isar_feature(aa32_fpdp_v2, s)) {
return false;
}
@@ -2416,7 +2416,7 @@ static bool trans_VCVT_sp(DisasContext *s, arg_VCVT_sp *a)
return false;
}
- if (!dc_isar_feature(aa32_fpdp, s)) {
+ if (!dc_isar_feature(aa32_fpdp_v2, s)) {
return false;
}
@@ -2444,7 +2444,7 @@ static bool trans_VCVT_dp(DisasContext *s, arg_VCVT_dp *a)
return false;
}
- if (!dc_isar_feature(aa32_fpdp, s)) {
+ if (!dc_isar_feature(aa32_fpdp_v2, s)) {
return false;
}
@@ -2498,7 +2498,7 @@ static bool trans_VCVT_int_dp(DisasContext *s, arg_VCVT_int_dp *a)
return false;
}
- if (!dc_isar_feature(aa32_fpdp, s)) {
+ if (!dc_isar_feature(aa32_fpdp_v2, s)) {
return false;
}
@@ -2538,7 +2538,7 @@ static bool trans_VJCVT(DisasContext *s, arg_VJCVT *a)
return false;
}
- if (!dc_isar_feature(aa32_fpdp, s)) {
+ if (!dc_isar_feature(aa32_fpdp_v2, s)) {
return false;
}
@@ -2631,7 +2631,7 @@ static bool trans_VCVT_fix_dp(DisasContext *s, arg_VCVT_fix_dp *a)
return false;
}
- if (!dc_isar_feature(aa32_fpdp, s)) {
+ if (!dc_isar_feature(aa32_fpdp_v2, s)) {
return false;
}
@@ -2727,7 +2727,7 @@ static bool trans_VCVT_dp_int(DisasContext *s, arg_VCVT_dp_int *a)
return false;
}
- if (!dc_isar_feature(aa32_fpdp, s)) {
+ if (!dc_isar_feature(aa32_fpdp_v2, s)) {
return false;
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.5 029/542] drm/amd/display: Map ODM memory correctly when doing ODM combine
From: Sasha Levin @ 2020-02-14 15:40 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Nikola Cornij, Jun Lei, Rodrigo Siqueira, Alex Deucher,
Sasha Levin, amd-gfx, dri-devel
In-Reply-To: <20200214154854.6746-1-sashal@kernel.org>
From: Nikola Cornij <nikola.cornij@amd.com>
[ Upstream commit ec5b356c58941bb8930858155d9ce14ceb3d30a0 ]
[why]
Up to 4 ODM memory pieces are required per ODM combine and cannot
overlap, i.e. each ODM "session" has to use its own memory pieces.
The ODM-memory mapping is currently broken for generic case.
The maximum number of memory pieces is ASIC-dependent, but it's always
big enough to satisfy maximum number of ODM combines. Memory pieces
are mapped as a bit-map, i.e. one memory piece corresponds to one bit.
The OPTC doing ODM needs to select memory pieces by setting the
corresponding bits, making sure there's no overlap with other OPTC
instances that might be doing ODM.
The current mapping works only for OPTC instance indexes smaller than
3. For instance indexes 3 and up it practically maps no ODM memory,
causing black, gray or white screen in display configs that include
ODM on OPTC instance 3 or up.
[how]
Statically map two unique ODM memory pieces for each OPTC instance
and piece them together when programming ODM combine mode.
Signed-off-by: Nikola Cornij <nikola.cornij@amd.com>
Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
.../gpu/drm/amd/display/dc/dcn20/dcn20_optc.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_optc.c b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_optc.c
index 3b613fb93ef80..0162d3ffe268f 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_optc.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_optc.c
@@ -233,12 +233,13 @@ void optc2_set_odm_combine(struct timing_generator *optc, int *opp_id, int opp_c
struct dc_crtc_timing *timing)
{
struct optc *optc1 = DCN10TG_FROM_TG(optc);
- /* 2 pieces of memory required for up to 5120 displays, 4 for up to 8192 */
int mpcc_hactive = (timing->h_addressable + timing->h_border_left + timing->h_border_right)
/ opp_cnt;
- int memory_mask = mpcc_hactive <= 2560 ? 0x3 : 0xf;
+ uint32_t memory_mask;
uint32_t data_fmt = 0;
+ ASSERT(opp_cnt == 2);
+
/* TODO: In pseudocode but does not affect maximus, delete comment if we dont need on asic
* REG_SET(OTG_GLOBAL_CONTROL2, 0, GLOBAL_UPDATE_LOCK_EN, 1);
* Program OTG register MASTER_UPDATE_LOCK_DB_X/Y to the position before DP frame start
@@ -246,9 +247,17 @@ void optc2_set_odm_combine(struct timing_generator *optc, int *opp_id, int opp_c
* MASTER_UPDATE_LOCK_DB_X, 160,
* MASTER_UPDATE_LOCK_DB_Y, 240);
*/
+
+ /* 2 pieces of memory required for up to 5120 displays, 4 for up to 8192,
+ * however, for ODM combine we can simplify by always using 4.
+ * To make sure there's no overlap, each instance "reserves" 2 memories and
+ * they are uniquely combined here.
+ */
+ memory_mask = 0x3 << (opp_id[0] * 2) | 0x3 << (opp_id[1] * 2);
+
if (REG(OPTC_MEMORY_CONFIG))
REG_SET(OPTC_MEMORY_CONFIG, 0,
- OPTC_MEM_SEL, memory_mask << (optc->inst * 4));
+ OPTC_MEM_SEL, memory_mask);
if (timing->pixel_encoding == PIXEL_ENCODING_YCBCR422)
data_fmt = 1;
@@ -257,7 +266,6 @@ void optc2_set_odm_combine(struct timing_generator *optc, int *opp_id, int opp_c
REG_UPDATE(OPTC_DATA_FORMAT_CONTROL, OPTC_DATA_FORMAT, data_fmt);
- ASSERT(opp_cnt == 2);
REG_SET_3(OPTC_DATA_SOURCE_SELECT, 0,
OPTC_NUM_OF_INPUT_SEGMENT, 1,
OPTC_SEG0_SRC_SEL, opp_id[0],
--
2.20.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.