All of lore.kernel.org
 help / color / mirror / Atom feed
* [patch] ir-keytable: avoid double lock
@ 2010-04-01 15:54 ` Dan Carpenter
  0 siblings, 0 replies; 2+ messages in thread
From: Dan Carpenter @ 2010-04-01 15:54 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Dmitry Torokhov, Márton Németh, Alexander Beregalov,
	Matthew Garrett, linux-media, linux-kernel, kernel-janitors

It's possible that we wanted to resize to a smaller size but we didn't
have enough memory to create the new table.  We need to test for that
here so we don't try to lock twice and dead lock.  Also we free the
"oldkeymap" on that path and that would be bad.

Signed-off-by: Dan Carpenter <error27@gmail.com>
---
I don't know this code very well.  Maybe we should  just take the lock
earlier in the function for the resize case and the non resize case.
Can we add new keys while the resize is taking place?

diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
index 0a3b4ed..51cd0f3 100644
--- a/drivers/media/IR/ir-keytable.c
+++ b/drivers/media/IR/ir-keytable.c
@@ -216,7 +216,7 @@ static void ir_delete_key(struct ir_scancode_table *rc_tab, int elem)
 		memcpy(&newkeymap[elem], &oldkeymap[elem + 1],
 		       (newsize - elem) * sizeof(*newkeymap));
 
-	if (resize) {
+	if (resize && newkeymap != oldkeymap) {
 		/*
 		 * As the copy happened to a temporary table, only here
 		 * it needs to lock while replacing the table pointers

^ permalink raw reply related	[flat|nested] 2+ messages in thread

* [patch] ir-keytable: avoid double lock
@ 2010-04-01 15:54 ` Dan Carpenter
  0 siblings, 0 replies; 2+ messages in thread
From: Dan Carpenter @ 2010-04-01 15:54 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Dmitry Torokhov, Márton Németh, Alexander Beregalov,
	Matthew Garrett, linux-media, linux-kernel, kernel-janitors

It's possible that we wanted to resize to a smaller size but we didn't
have enough memory to create the new table.  We need to test for that
here so we don't try to lock twice and dead lock.  Also we free the
"oldkeymap" on that path and that would be bad.

Signed-off-by: Dan Carpenter <error27@gmail.com>
---
I don't know this code very well.  Maybe we should  just take the lock
earlier in the function for the resize case and the non resize case.
Can we add new keys while the resize is taking place?

diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
index 0a3b4ed..51cd0f3 100644
--- a/drivers/media/IR/ir-keytable.c
+++ b/drivers/media/IR/ir-keytable.c
@@ -216,7 +216,7 @@ static void ir_delete_key(struct ir_scancode_table *rc_tab, int elem)
 		memcpy(&newkeymap[elem], &oldkeymap[elem + 1],
 		       (newsize - elem) * sizeof(*newkeymap));
 
-	if (resize) {
+	if (resize && newkeymap != oldkeymap) {
 		/*
 		 * As the copy happened to a temporary table, only here
 		 * it needs to lock while replacing the table pointers

^ permalink raw reply related	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2010-04-01 15:54 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-04-01 15:54 [patch] ir-keytable: avoid double lock Dan Carpenter
2010-04-01 15:54 ` Dan Carpenter

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.