headers
Pavel Machek | 3 Jan 2009 13:44
Picon

atomics: document that linux expects certain atomic behaviour from unsigned long

Linux relies on unsigned long to behave like atomic for read/write.
diff --git a/Documentation/atomic_ops.txt b/Documentation/atomic_ops.txt
index 4ef2450..0a7d180 100644
--- a/Documentation/atomic_ops.txt
+++ b/Documentation/atomic_ops.txt
 <at>  <at>  -21,6 +21,9  <at>  <at>  local_t is very similar to atomic_t. If the counter is per CPU and only
 updated by one CPU, local_t is probably more appropriate. Please see
 Documentation/local_ops.txt for the semantics of local_t.

+unsigned long can be used instead of atomic_t, if all you
+need is atomic setting and atomic reading.
+
 The first operations to implement for atomic_t's are the initializers and
 plain reads.

--

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 32 comments |
headers
Pavel Machek | 3 Jan 2009 13:38
Picon

document ext3 requirements

Using ext3 is only safe if storage subsystem meets certain
criteria. Document those.

Errors=remount-ro is documented as default, but superblock setting
overrides that and mkfs defaults to errors=continue... so the default
is errors=continue in practice.

readonly mount does actually write to the media in some cases. Document that.

Signed-off-by: Pavel Machek <pavel <at> suse.cz>

diff --git a/Documentation/filesystems/ext3.txt b/Documentation/filesystems/ext3.txt
index 9dd2a3b..74a73b0 100644
--- a/Documentation/filesystems/ext3.txt
+++ b/Documentation/filesystems/ext3.txt
 <at>  <at>  -14,6 +14,9  <at>  <at>  Options
 When mounting an ext3 filesystem, the following option are accepted:
 (*) == default

+ro			Note that ext3 will replay the journal (and thus write
+			to the partition) even when mounted "read only".
+
 journal=update		Update the ext3 file system's journal to the current
 			format.

 <at>  <at>  -95,6 +98,8  <at>  <at>  debug			Extra debugging information is sent to syslog.
 errors=remount-ro(*)	Remount the filesystem read-only on an error.
 errors=continue		Keep going on a filesystem error.
 errors=panic		Panic and halt the machine if an error occurs.
+			(Note that default is overriden by superblock
(Continue reading)

Permalink | Reply | 129 comments |
headers
Alan Cox | 3 Jan 2009 21:19
Picon

Re: atomics: document that linux expects certain atomic behaviour from unsigned long

On Sat, 3 Jan 2009 13:44:00 +0100
Pavel Machek <pavel <at> suse.cz> wrote:

> Linux relies on unsigned long to behave like atomic for read/write.

Actually it isn't that simple and this advice shouldn't be given IMHO.

unsigned long is not the same as atomic in several respects including
ordering and caching of the result.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 30 comments |
headers
Pavel Machek | 3 Jan 2009 21:27
Picon

Re: atomics: document that linux expects certain atomic behaviour from unsigned long

On Sat 2009-01-03 20:19:55, Alan Cox wrote:
> On Sat, 3 Jan 2009 13:44:00 +0100
> Pavel Machek <pavel <at> suse.cz> wrote:
> 
> > Linux relies on unsigned long to behave like atomic for read/write.
> 
> Actually it isn't that simple and this advice shouldn't be given IMHO.
> 
> unsigned long is not the same as atomic in several respects including
> ordering and caching of the result.

Ok... I keep seeing patches using int/long instead of atomic and
claiming that it is okay.

If it is okay and linux relies on it, it should be documented.

If it is not okay, I guess we should document it, too -- it seems to
be common mistake. 

--

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 28 comments |
headers
Alan Cox | 3 Jan 2009 21:30
Picon

Re: atomics: document that linux expects certain atomic behaviour from unsigned long

> If it is okay and linux relies on it, it should be documented.
> 
> If it is not okay, I guess we should document it, too -- it seems to
> be common mistake. 

A lot of old code did it knowing it was under the BKL, outside of the BKL
its a very bad idea. There were lots of them in the tty layer and I don't
doubt there are some left I missed too 8(
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 26 comments |
headers
Pavel Machek | 3 Jan 2009 21:56
Picon

Re: atomics: document that linux expects certain atomic behaviour from unsigned long

On Sat 2009-01-03 20:30:44, Alan Cox wrote:
> > If it is okay and linux relies on it, it should be documented.
> > 
> > If it is not okay, I guess we should document it, too -- it seems to
> > be common mistake. 
> 
> A lot of old code did it knowing it was under the BKL, outside of the BKL
> its a very bad idea. There were lots of them in the tty layer and I don't
> doubt there are some left I missed too 8(

I have seen this in new code (some LED driver last time), definitely
no BKL.

Is there concrete architecture where it breaks? I'd expect i386/x86-64
to be safe, and pretty much everyone to be safe as long as that long
is aligned.... or that was the result of arch-maintainers
discussion...

I'd really like to document if it is right or not, so that I can point
people to documentation...
								Pavel
--

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 22 comments |
headers
Martin MOKREJŠ | 3 Jan 2009 22:17
Picon

Re: document ext3 requirements

Can one avoid replay of the journal then if it would be unclean?
Just curious.
M.

Pavel Machek wrote:
> Using ext3 is only safe if storage subsystem meets certain
> criteria. Document those.
> 
> Errors=remount-ro is documented as default, but superblock setting
> overrides that and mkfs defaults to errors=continue... so the default
> is errors=continue in practice.
> 
> readonly mount does actually write to the media in some cases. Document that.
> 
> Signed-off-by: Pavel Machek <pavel <at> suse.cz>
> 
> diff --git a/Documentation/filesystems/ext3.txt b/Documentation/filesystems/ext3.txt
Permalink | Reply | 59 comments |
headers
david | 4 Jan 2009 00:01

Re: atomics: document that linux expects certain atomic behaviour from unsigned long

On Sat, 3 Jan 2009, Pavel Machek wrote:

> On Sat 2009-01-03 20:30:44, Alan Cox wrote:
>>> If it is okay and linux relies on it, it should be documented.
>>>
>>> If it is not okay, I guess we should document it, too -- it seems to
>>> be common mistake.
>>
>> A lot of old code did it knowing it was under the BKL, outside of the BKL
>> its a very bad idea. There were lots of them in the tty layer and I don't
>> doubt there are some left I missed too 8(
>
> I have seen this in new code (some LED driver last time), definitely
> no BKL.
>
> Is there concrete architecture where it breaks? I'd expect i386/x86-64
> to be safe, and pretty much everyone to be safe as long as that long
> is aligned.... or that was the result of arch-maintainers
> discussion...
>
> I'd really like to document if it is right or not, so that I can point
> people to documentation...

you may want to take a look at the new C/C++/POSIX standards (some just 
standardized, some still in development), they explicitly address this 
area.

David Lang
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pavel Machek | 3 Jan 2009 23:06
Picon

Re: document ext3 requirements

On Sat 2009-01-03 22:17:11, Martin MOKREJŠ wrote:
> Can one avoid replay of the journal then if it would be unclean?
> Just curious.

Well, mounting unclean filesystem is dangerous but depending on
circumstances, it may be better than writing to the filesystems.

(You may not be able to read some data and may provoke kernel bugs,
but at least you don't damage what is on disk. If you are collecting
evidence -- not writing is very important. If you suspect something is
very wrong with the drive, not writing is good idea).

								Pavel
> 
> Pavel Machek wrote:
> > Using ext3 is only safe if storage subsystem meets certain
> > criteria. Document those.
> > 
> > Errors=remount-ro is documented as default, but superblock setting
> > overrides that and mkfs defaults to errors=continue... so the default
> > is errors=continue in practice.
> > 
> > readonly mount does actually write to the media in some cases. Document that.
> > 
> > Signed-off-by: Pavel Machek <pavel <at> suse.cz>
> > 
> > diff --git a/Documentation/filesystems/ext3.txt b/Documentation/filesystems/ext3.txt

--

-- 
(english) http://www.livejournal.com/~pavelmachek
(Continue reading)

Permalink | Reply | 0 comments |
headers
Duane Griffin | 3 Jan 2009 23:17
Gravatar

Re: document ext3 requirements

[Fixed top-posting]

2009/1/3 Martin MOKREJŠ <mmokrejs <at> ribosome.natur.cuni.cz>:
> Pavel Machek wrote:
>> readonly mount does actually write to the media in some cases. Document that.
>>
> Can one avoid replay of the journal then if it would be unclean?
> Just curious.

Nope. If the underlying block device is read-only then mounting the
filesystem will fail. I tried to fix this some time ago, and have a
set of patches that almost always work, but "almost always" isn't good
enough. Unfortunately I never managed to figure out a way to finish it
off without disgusting hacks or major surgery.

> M.

Cheers,
Duane.

--

-- 
"I never could learn to drink that blood and call it wine" - Bob Dylan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 55 comments |

Gmane