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>] [day] [month] [year] [list]
Date:	Sat, 8 Dec 2007 13:43:37 +0200
From:	"T T" <gentuu.call@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: Quotaon livelock

Hi lkml,

Enabling FS quotas can take up to several minutes to finish and
depends on other users disk activity. This makes it a livelock (as it
can be finished anyway).

The problem described at:
http://bugzilla.kernel.org/show_bug.cgi?id=9520

Yes, if we need to enable quotas once in the system start - no problem.
But if we have to disable/enable it periodically - this become a nightmare.

Please don't advice to use edquota or so (quotactl(Q_SETQUOTA...) based things).
What if it's really needed to use quotactl(Q_QUOTAOFF...)/quotactl(Q_QUOTAON...)

The problem is at fs/dquot.c:add_dquot_ref()
It's restarting to loop over the inodes list once it inits quota on an inode.
And this happens over and over if something is modifying inodes list
during quotas enabling.

It looks like the action must take some time depending on FS size, but
not on other users
disk activity...
Any advices how the algorithm at fs/dquot.c:add_dquot_ref() can be enhanced?

Thanks
Nick
--
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