lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0710281211170.18815@twin.jikos.cz>
Date:	Sun, 28 Oct 2007 12:12:19 +0100 (CET)
From:	Jiri Kosina <jikos@...os.cz>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Gabriel C <nix.or.die@...glemail.com>, a.zummo@...ertech.it,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	rtc-linux@...glegroups.com
Subject: Re: BUG: lock held when returning to user space

(CC list stripped)

On Sat, 27 Oct 2007, Andrew Morton wrote:

> It's a fairly daft thing to do.  I think it'd be saner to teach rtc about
> test_and_set_bit() personally..


From: Jiri Kosina <jkosina@...e.cz>

RTC: convert mutex to bitfield

RTC code is using mutex to assure exclusive access to /dev/rtc.
This is however wrong usage, as it leaves the mutex locked when
returning into userspace, which is unacceptable.

Convert rtc->char_lock into bit operation.

Signed-off-by: Jiri Kosina <jkosina@...e.cz>

diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
index de0da54..a4f56e9 100644
--- a/drivers/rtc/interface.c
+++ b/drivers/rtc/interface.c
@@ -293,7 +293,7 @@ int rtc_irq_register(struct rtc_device *rtc, struct rtc_task *task)
 		return -EINVAL;
 
 	/* Cannot register while the char dev is in use */
-	if (!(mutex_trylock(&rtc->char_lock)))
+	if (test_and_set_bit(RTC_DEV_BUSY, &rtc->flags))
 		return -EBUSY;
 
 	spin_lock_irq(&rtc->irq_task_lock);
@@ -303,7 +303,7 @@ int rtc_irq_register(struct rtc_device *rtc, struct rtc_task *task)
 	}
 	spin_unlock_irq(&rtc->irq_task_lock);
 
-	mutex_unlock(&rtc->char_lock);
+	clear_bit(RTC_DEV_BUSY, &rtc->flags);
 
 	return retval;
 }
diff --git a/drivers/rtc/rtc-dev.c b/drivers/rtc/rtc-dev.c
index 814583b..ae1bf17 100644
--- a/drivers/rtc/rtc-dev.c
+++ b/drivers/rtc/rtc-dev.c
@@ -26,10 +26,7 @@ static int rtc_dev_open(struct inode *inode, struct file *file)
 					struct rtc_device, char_dev);
 	const struct rtc_class_ops *ops = rtc->ops;
 
-	/* We keep the lock as long as the device is in use
-	 * and return immediately if busy
-	 */
-	if (!(mutex_trylock(&rtc->char_lock)))
+	if (test_and_set_bit(RTC_DEV_BUSY, &rtc->flags))
 		return -EBUSY;
 
 	file->private_data = rtc;
@@ -43,8 +40,8 @@ static int rtc_dev_open(struct inode *inode, struct file *file)
 		return 0;
 	}
 
-	/* something has gone wrong, release the lock */
-	mutex_unlock(&rtc->char_lock);
+	/* something has gone wrong */
+	clear_bit(RTC_DEV_BUSY, &rtc->flags);
 	return err;
 }
 
@@ -405,7 +402,7 @@ static int rtc_dev_release(struct inode *inode, struct file *file)
 	if (rtc->ops->release)
 		rtc->ops->release(rtc->dev.parent);
 
-	mutex_unlock(&rtc->char_lock);
+	clear_bit(RTC_DEV_BUSY, &rtc->flags);
 	return 0;
 }
 
@@ -440,7 +437,6 @@ void rtc_dev_prepare(struct rtc_device *rtc)
 
 	rtc->dev.devt = MKDEV(MAJOR(rtc_devt), rtc->id);
 
-	mutex_init(&rtc->char_lock);
 #ifdef CONFIG_RTC_INTF_DEV_UIE_EMUL
 	INIT_WORK(&rtc->uie_task, rtc_uie_task);
 	setup_timer(&rtc->uie_timer, rtc_uie_timer, (unsigned long)rtc);
diff --git a/include/linux/rtc.h b/include/linux/rtc.h
index 6d5e4a4..f2d0d15 100644
--- a/include/linux/rtc.h
+++ b/include/linux/rtc.h
@@ -133,6 +133,9 @@ struct rtc_class_ops {
 #define RTC_DEVICE_NAME_SIZE 20
 struct rtc_task;
 
+/* flags */
+#define RTC_DEV_BUSY 0
+
 struct rtc_device
 {
 	struct device dev;
@@ -145,7 +148,7 @@ struct rtc_device
 	struct mutex ops_lock;
 
 	struct cdev char_dev;
-	struct mutex char_lock;
+	unsigned long flags;
 
 	unsigned long irq_data;
 	spinlock_t irq_lock;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists