Alison Schofield wrote:
> On Thu, Dec 21, 2023 at 10:12:12PM -0800, Dan Williams wrote:
> > From: Huang Ying <ying.huang@xxxxxxxxx>
> >
> > The decoder_populate_targets() helper walks all of the targets in a port
> > and makes sure they can be looked up in @target_map. Where @target_map
> > is a lookup table from target position to target id (corresponding to a
> > cxl_dport instance). However @target_map is only responsible for
> > conveying the active dport instances as conveyed by interleave_ways.
> >
> > When nr_targets > interleave_ways it results in
> > decoder_populate_targets() walking off the end of the valid entries in
> > @target_map. Given target_map is initialized to 0 it results in the
> > dport lookup failing if position 0 is not mapped to a dport with an id
> > of 0:
> >
> > cxl_port port3: Failed to populate active decoder targets
> > cxl_port port3: Failed to add decoder
> > cxl_port port3: Failed to add decoder3.0
> > cxl_bus_probe: cxl_port port3: probe: -6
> >
> > This bug also highlights that when the decoder's ->targets[] array is
> > written in cxl_port_setup_targets() it is missing a hold of the
> > targets_lock to synchronize against sysfs readers of the target list. A
> > fix for that is saved for a later patch.
> >
> > Fixes: a5c258021689 ("cxl/bus: Populate the target list at decoder create")
> > Cc: <stable@xxxxxxxxxxxxxxx>
> > Signed-off-by: "Huang, Ying" <ying.huang@xxxxxxxxx>
> > [djbw: rewrite the changelog, find the Fixes: tag]
> > Co-developed-by: Dan Williams <dan.j.williams@xxxxxxxxx>
> > Signed-off-by: Dan Williams <dan.j.williams@xxxxxxxxx>
> > ---
> > drivers/cxl/core/port.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/cxl/core/port.c b/drivers/cxl/core/port.c
> > index b7c93bb18f6e..57495cdc181f 100644
> > --- a/drivers/cxl/core/port.c
> > +++ b/drivers/cxl/core/port.c
> > @@ -1644,7 +1644,7 @@ static int decoder_populate_targets(struct cxl_switch_decoder *cxlsd,
> > return -EINVAL;
> >
> > write_seqlock(&cxlsd->target_lock);
> > - for (i = 0; i < cxlsd->nr_targets; i++) {
> > + for (i = 0; i < cxlsd->cxld.interleave_ways; i++) {
> > struct cxl_dport *dport = find_dport(port, target_map[i]);
> >
>
> Does this loop need to protect against interleave_ways > nr_targets?
> ie protect from walking off the target_map[nr_targets].
It's a good review question, but I think target_map[] is safe from those
shenanigans. For the CFMWS case interleave_ways == nr_targets, see the
@nr_tagets argument to cxl_root_decoder_alloc(). For the mid-level
switch decoder case it is protected by the fact that the decoder's
interleave_ways setting is sanity checked by the eiw_to_ways() call in
init_hdm_decoder(). So there's never any danger of walking off the end
of the target_map[] because that is allocated to support the
spec-defined hardware-max of CXL_DECODER_MAX_INTERLEAVE.
> There is a check for that in cxl_port_setup_targets()
> >> if (iw > 8 || iw > cxlsd->nr_targets) {
> >> dev_dbg(&cxlr->dev,
> >> "%s:%s:%s: ways: %d overflows targets: %d\n",
That check is for programming mid-level decoders where we find out at
run time that the interleave_ways of the region can not be satisfied by
one of the decoders in the chain, so that one is not about walking past
the end of a target list, that one is about detecting impossible region
configurations.
