From: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
To: Linux Media Mailing List <linux-media@vger.kernel.org>
Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Subject: [PATCH] [media] media-entity: Don't use var length arrays
Date: Tue, 22 Sep 2015 20:19:03 -0300 [thread overview]
Message-ID: <60c3f149566de02ae1d2b857d4b6115ec7a9107e.1442963941.git.mchehab@osg.samsung.com> (raw)
The graph traversal algorithm currently uses two variable-length
arrays that are dynamically allocated at the stack:
drivers/media/media-entity.c:238:17: warning: Variable length array is used.
drivers/media/media-entity.c:239:17: warning: Variable length array is used.
Those are bad, specially if the number of pads for some entity would
be bigger than a certain amount, as it would cause a Linux stack
overflow.
We could just replace entity->num_pads by a define in order to solve
the above sparse warnings, but that would still prevent having entities
with a big number of pads. So, let's do the right thing and use a
kalloced var to store those ancillary bitmaps, e. g. put them at
struct media_device, and use an arbitrary big number that will work
for all currently known usecases.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index 153a46469814..02842d875809 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -235,8 +235,6 @@ __must_check int media_entity_pipeline_start(struct media_entity *entity,
media_entity_graph_walk_start(&graph, entity);
while ((entity = media_entity_graph_walk_next(&graph))) {
- DECLARE_BITMAP(active, entity->num_pads);
- DECLARE_BITMAP(has_no_links, entity->num_pads);
unsigned int i;
entity->stream_count++;
@@ -250,8 +248,8 @@ __must_check int media_entity_pipeline_start(struct media_entity *entity,
if (!entity->ops || !entity->ops->link_validate)
continue;
- bitmap_zero(active, entity->num_pads);
- bitmap_fill(has_no_links, entity->num_pads);
+ bitmap_zero(mdev->active, entity->num_pads);
+ bitmap_fill(mdev->has_no_links, entity->num_pads);
for (i = 0; i < entity->num_links; i++) {
struct media_link *link = &entity->links[i];
@@ -259,7 +257,7 @@ __must_check int media_entity_pipeline_start(struct media_entity *entity,
? link->sink : link->source;
/* Mark that a pad is connected by a link. */
- bitmap_clear(has_no_links, pad->index, 1);
+ bitmap_clear(mdev->has_no_links, pad->index, 1);
/*
* Pads that either do not need to connect or
@@ -268,7 +266,7 @@ __must_check int media_entity_pipeline_start(struct media_entity *entity,
*/
if (!(pad->flags & MEDIA_PAD_FL_MUST_CONNECT) ||
link->flags & MEDIA_LNK_FL_ENABLED)
- bitmap_set(active, pad->index, 1);
+ bitmap_set(mdev->active, pad->index, 1);
/*
* Link validation will only take place for
@@ -290,15 +288,16 @@ __must_check int media_entity_pipeline_start(struct media_entity *entity,
}
/* Either no links or validated links are fine. */
- bitmap_or(active, active, has_no_links, entity->num_pads);
+ bitmap_or(mdev->active, mdev->active, mdev->has_no_links,
+ entity->num_pads);
- if (!bitmap_full(active, entity->num_pads)) {
+ if (!bitmap_full(mdev->active, entity->num_pads)) {
ret = -EPIPE;
dev_dbg(entity->parent->dev,
"\"%s\":%u must be connected by an enabled link\n",
entity->name,
(unsigned)find_first_zero_bit(
- active, entity->num_pads));
+ mdev->active, entity->num_pads));
goto error;
}
}
diff --git a/include/media/media-device.h b/include/media/media-device.h
index 6e6db78f1ee2..1ac132af031b 100644
--- a/include/media/media-device.h
+++ b/include/media/media-device.h
@@ -32,6 +32,10 @@
struct device;
+/* Maximum number of pads per entity */
+
+#define MEDIA_MAX_PADS 512
+
/**
* struct media_device - Media device
* @dev: Parent device
@@ -78,6 +82,11 @@ struct media_device {
int (*link_notify)(struct media_link *link, u32 flags,
unsigned int notification);
+
+ /* private: ancillary bitmaps used by graph traversal algo */
+
+ DECLARE_BITMAP(active, MEDIA_MAX_PADS);
+ DECLARE_BITMAP(has_no_links, MEDIA_MAX_PADS);
};
/* Supported link_notify @notification values. */
--
2.4.3
next reply other threads:[~2015-09-22 23:20 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-22 23:19 Mauro Carvalho Chehab [this message]
2015-10-04 16:52 ` [PATCH] [media] media-entity: Don't use var length arrays Sakari Ailus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=60c3f149566de02ae1d2b857d4b6115ec7a9107e.1442963941.git.mchehab@osg.samsung.com \
--to=mchehab@osg.samsung.com \
--cc=linux-media@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.