mm: Swap checksum

swap_info_get() is used for more than swap_free().

Use "swap_info_get:" instead of "swap_free:" in the error messages.

Signed-off-by Cesar Eduardo Barros <[email protected]>

---
 mm/swapfile.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

mm/swapfile.c +0 -0

index 6cd0a8f..af7d499 100644

mm/swapfile.c static struct swap_info_struct *swap_info_get(swp_entry_t entry) · line 525

Quoted 6 lines

mm/swapfile.c +1 -1

@@ -522,16 +522,16 @@ static struct swap_info_struct *swap_info_get(swp_entry_t entry)
  	return p;
 
  bad_free:
-	printk(KERN_ERR "swap_free: %s%08lx\n", Unused_offset, entry.val);
+	printk(KERN_ERR "swap_info_get: %s%08lx\n", Unused_offset, entry.val);

Why not let the compiler do it for ya:

	printk(KERN_ERR "%s: %s%08lx\n", __func__, Unused_offset, entry.val);

?... etc.

Add support for checksumming the swap pages written to disk, using the same checksum as btrfs (crc32c). Since the contents of the swap do not matter after a shutdown, the checksum is kept in memory only.

Note that this code does not checksum the software suspend image.

  #define SWAP_FLAG_PREFER	0x8000	/* set if swap priority specified */
  #define SWAP_FLAG_PRIO_MASK	0x7fff

On 64-bit, we may be able to store the checksum in the pte, if the swap device is small enough.

If we take the trouble to touch the page, we may as well compare it against zero, and if so drop it instead of swapping it out.

Em 23-05-2010 12:19, Avi Kivity escreveu:

Quoted 2 lines

On 64-bit, we may be able to store the checksum in the pte, if the swap device is small enough.

Which pte?

Correct me if I am wrong, but I do not think all pages written to the swap have exactly one pte pointing to them. And I have not looked at the shmem.c code yet, but does it even use ptes?

It might be possible (find all ptes and write the 32-bit checksum to them, do something else for shmem, have two different code paths for small/large swapfiles), but I do not know if the memory savings are worth the extra complexity (especially the need for two separate code paths).

Quoted 3 lines

If we take the trouble to touch the page, we may as well compare it against zero, and if so drop it instead of swapping it out.

The problem with this is that the page is touched deep inside the crc32c code, which might even be using hardware instructions (crc32c-intel). So we would need to read it two times to compare against zero.

One possibility could be to compare the full page against zero only if its crc is a specific value (the crc32c of a page full of zeros). This would not be too slow (we would be wasting time only when we have a very high probability of saving much more time), and not need to touch the crc32c code at all. I would only have to look at how this messes up the state tracking (i.e. how to make it track the fact that, instead of getting written out, this is now a zeroed page).

Other than that, it seems a good idea.

Quoted 5 lines · Cesar Eduardo Barros

Em 23-05-2010 12:19, Avi Kivity escreveu:

Quoted 2 lines

On 64-bit, we may be able to store the checksum in the pte, if the swap device is small enough.

Which pte?

All of them.

Quoted 3 lines

Correct me if I am wrong, but I do not think all pages written to the swap have exactly one pte pointing to them. And I have not looked at the shmem.c code yet, but does it even use ptes?

Well, the ptes need the swap address written into them, so they are already found and updated somehow. All that's needed is to update the value written to also include the checksum.

Quoted 5 lines

It might be possible (find all ptes and write the 32-bit checksum to them, do something else for shmem, have two different code paths for small/large swapfiles), but I do not know if the memory savings are worth the extra complexity (especially the need for two separate code paths).

Certainly not at first, but later it may be worthwhile.

Quoted 4 lines

Quoted 3 lines

If we take the trouble to touch the page, we may as well compare it against zero, and if so drop it instead of swapping it out.

Quoted 4 lines

The problem with this is that the page is touched deep inside the crc32c code, which might even be using hardware instructions (crc32c-intel). So we would need to read it two times to compare against zero.

The second read is very cheap since the page is already in cache. Also, we fail early when any word is nonzero, so usually the compare exits quickly.

Quoted 8 lines

One possibility could be to compare the full page against zero only if its crc is a specific value (the crc32c of a page full of zeros). This would not be too slow (we would be wasting time only when we have a very high probability of saving much more time), and not need to touch the crc32c code at all. I would only have to look at how this messes up the state tracking (i.e. how to make it track the fact that, instead of getting written out, this is now a zeroed page).

Instead of returning a swap pte to be written to the page tables, return a zeroed pte.

I wonder, though. If we no longer trust block devices to give the correct data back, should we provide a meta block device to do error detection?

No production filesystem on Linux has checksums (well, ext4 has a few). Of the ones that add checksumming, I'd say most will not do data checksumming (and for direct IO it is not done).

Quoted 7 lines

One possibility could be to compare the full page against zero only if its crc is a specific value (the crc32c of a page full of zeros). This would not be too slow (we would be wasting time only when we have a very high probability of saving much more time), and not need to touch the crc32c code at all. I would only have to look at how this messes up the state tracking (i.e. how to make it track the fact that, instead of getting written out, this is now a zeroed page).

Instead of returning a swap pte to be written to the page tables, return a zeroed pte.

Add support for checksumming the swap pages written to disk, using the same checksum as btrfs (crc32c). Since the contents of the swap do not matter after a shutdown, the checksum is kept in memory only.

Note that this code does not checksum the software suspend image.

Quoted 5 lines

Add support for checksumming the swap pages written to disk, using the same checksum as btrfs (crc32c). Since the contents of the swap do not matter after a shutdown, the checksum is kept in memory only.

Note that this code does not checksum the software suspend image.

We have been used swap pages without checksum.

First of all, Could you explain why you need checksum on swap pages? Do you see any problem which swap pages are broken?

Em 23-05-2010 11:03, Minchan Kim escreveu:

Quoted 7 lines · Cesar Eduardo Barros

Quoted 5 lines

Add support for checksumming the swap pages written to disk, using the same checksum as btrfs (crc32c). Since the contents of the swap do not matter after a shutdown, the checksum is kept in memory only.

Quoted 6 lines

Quoted 1 line

Note that this code does not checksum the software suspend image.

We have been used swap pages without checksum.

First of all, Could you explain why you need checksum on swap pages? Do you see any problem which swap pages are broken?

The same reason we need checksums in the filesystem.

If you use btrfs as your root filesystem, you are protected by checksums from damage in the filesystem, but not in the swap partition (which is often in the same disk, and thus as vulnerable as the filesystem). It is better to get a checksum error when swapping in than having a silently corrupted page.

Hi, Cesar.
I am not sure Cesar is first name. :)

Quoted 8 lines

Em 23-05-2010 11:03, Minchan Kim escreveu:

Quoted 4 lines

We have been used swap pages without checksum.

First of all, Could you explain why you need checksum on swap pages? Do you see any problem which swap pages are broken?

The same reason we need checksums in the filesystem.

Quoted 4 lines

If you use btrfs as your root filesystem, you are protected by checksums from damage in the filesystem, but not in the swap partition (which is often in the same disk, and thus as vulnerable as the filesystem). It is better to get a checksum error when swapping in than having a silently corrupted page.

Do you mean "vulnerable" is other file system or block I/O operation invades swap partition and breaks data of swap?

If it is, I think it's the problem of them. so we have to fix it before merged into mainline. But I admit human being always take a mistake so that we can miss it at review time. In such case, it would be very hard bug when swap pages are broken. I haven't hear about such problem until now but it might be useful if the problem happens. (Maybe they can't notice that due to hard bug to find)

But I have a concern about breaking memory which includes crc by dangling pointer. In this case, swap block is correct but it would emit crc error.

Do you have an idea making sure memory includes crc is correct?

Em 23-05-2010 21:09, Minchan Kim escreveu:

Quoted 3 lines

Hi, Cesar.
I am not sure Cesar is first name. :)

Yes, it is.

Quoted 20 lines

Quoted 10 lines · Cesar Eduardo Barros

Em 23-05-2010 11:03, Minchan Kim escreveu:

Quoted 5 lines

We have been used swap pages without checksum.

First of all, Could you explain why you need checksum on swap pages? Do you see any problem which swap pages are broken?

The same reason we need checksums in the filesystem.

Quoted 7 lines

If you use btrfs as your root filesystem, you are protected by checksums from damage in the filesystem, but not in the swap partition (which is often
in the same disk, and thus as vulnerable as the filesystem). It is better to
get a checksum error when swapping in than having a silently corrupted page.

Quoted 2 lines

Do you mean "vulnerable" is other file system or block I/O operation invades swap partition and breaks data of swap?

Vulnerable in that the same kind of hardware problems which can silently damage filesystem data in the disk can damage swap pages in the disk.

This is the reason both btrfs and zfs checksum all their data and metadata. However, the swap partition is still vulnerable (using a swap file is not a solution, since the swap code bypasses the filesystem). And silent data corruption in the swap partition could be even worse than in the filesystem
- while a program might not trust a file it is reading to not be corrupted, almost all programs will trust their *memory* to not be corrupted.

The internal ECC of the disk will not save you - a quick Google search found an instance of someone with silent data corruption caused by a faulty *power supply*.[1]

And if it is silent corruption, without the checksums you will not notice it
- it will just be dismissed as "oh, Firefox just crashed again" or similar (the same as bit flips on RAM without ECC).

Quoted 8 lines

If it is, I think it's the problem of them. so we have to fix it before merged into mainline. But I admit human being always take a mistake so that we can miss it at review time. In such case, it would be very hard bug when swap pages are broken. I haven't hear about such problem until now but it might be useful if the problem happens. (Maybe they can't notice that due to hard bug to find)

Quoted 5 lines

But I have a concern about breaking memory which includes crc by dangling pointer. In this case, swap block is correct but it would emit crc error.

Do you have an idea making sure memory includes crc is correct?

The swap checksum only protects the page against being silently corrupted while on the disk and at least to some degree on the I/O path between the memory and the disk. It does not protect against broken kernel-mode code writing to the wrong address, nor against broken hardware (or hardware misconfigured by broken drivers) doing DMA to wrong addresses. It also does not protect against hardware errors in the RAM itself (you have ECC memory for that).

That is, the code assumes the memory containing the checksums will not be corrupted, because if it is, you have worse problems (and the CRC error here would be a *good* thing, since it would make you notice something is not quite right).

[1] http://blogs.sun.com/elowe/entry/zfs_saves_the_day_ta

--
Cesar Eduardo Barros
[email protected]
[email protected]

Quoted 7 lines

The internal ECC of the disk will not save you - a quick Google search found an instance of someone with silent data corruption caused by a faulty *power supply*.[1]

And if it is silent corruption, without the checksums you will not notice it
- it will just be dismissed as "oh, Firefox just crashed again" or similar (the same as bit flips on RAM without ECC).

When I read your comment, suddenly some thought occurred to me. If we can't believe ECC of the disk, why do we separate error detection logic between file system and swap disk?

I mean it make sense that put crc detection into block layer? It can make sure any block I/O.

And what's BER of disk?
Is it usual to meet the problem?

In normal desktop, some app killed are not critical. If the application is critical, maybe app have to logic fault handling. Firefox has session restore feature and Office program has temporal save feature.

On the other hand, in server, does it designed well to use swap disk until we meet bit error of disk?

My feel is that it seem to be rather overkill.

Quoted 8 lines

The swap checksum only protects the page against being silently corrupted while on the disk and at least to some degree on the I/O path between the memory and the disk. It does not protect against broken kernel-mode code writing to the wrong address, nor against broken hardware (or hardware misconfigured by broken drivers) doing DMA to wrong addresses. It also does not protect against hardware errors in the RAM itself (you have ECC memory for that).

Quoted 5 lines

That is, the code assumes the memory containing the checksums will not be corrupted, because if it is, you have worse problems (and the CRC error here would be a *good* thing, since it would make you notice something is not quite right).

Which is high between BER of RAM and disk?
It's a just question. :)

Em 23-05-2010 23:05, Minchan Kim escreveu:

Quoted 16 lines

Quoted 7 lines · Cesar Eduardo Barros

The internal ECC of the disk will not save you - a quick Google search found
an instance of someone with silent data corruption caused by a faulty *power
supply*.[1]

Quoted 5 lines

And if it is silent corruption, without the checksums you will not notice it
- it will just be dismissed as "oh, Firefox just crashed again" or similar
(the same as bit flips on RAM without ECC).

Quoted 6 lines

When I read your comment, suddenly some thought occurred to me. If we can't believe ECC of the disk, why do we separate error detection logic between file system and swap disk?

I mean it make sense that put crc detection into block layer? It can make sure any block I/O.

There are differences as to where the checksum will be stored.

For the filesystem (and for the software suspend image), you have to store the checksums in the disk itself, and the correct place (and ordering requirements) depends on the filesystem. Also, most filesystems do not currently have on-disk checksums.

For the swap, it is much simpler; the checksums can be stored in memory (since they do not matter after a reboot; the swap contents are simply discarded). This also gives better performance, since the checksums do not have to be separately written, and more flexibility, since the kernel can use whatever kind of checksum it wants and can store the checksum in whatever data structure it choses, without worrying about compatibility.

And, in fact, there is a CRC code in the block layer; it is CONFIG_BLK_DEV_INTEGRITY. However, it is not a generic solution; it needs some extra prerequisites (like a disk low-level formatted with sectors with

Quoted 1 line

512 bytes).

Quoted 4 lines

And, in fact, there is a CRC code in the block layer; it is CONFIG_BLK_DEV_INTEGRITY. However, it is not a generic solution; it needs some extra prerequisites (like a disk low-level formatted with sectors with

Quoted 1 line

512 bytes).

You mean BLK_DEV_INTEGRITY has a dependency with block device driver? If you want to support checksum into suspend, At last, should we put the checksum on disk?

I mean could we extend BLK_DEV_INTEGRITY by more generic solution? As you said, in case of swap, we don't need to put checksum on disk.

If swap case, let it put the one on memory. If non-swap case, let it put checksum on disk,
I am not sure it's possible.

When we have a unreliable disk, your point is that let's solve it with (btrfs + swap) which both supports checksum. And my point is that let's solve it with (any file system + swap) which is put on block layer which supports checksum.

Em 25-05-2010 20:52, Minchan Kim escreveu:

Quoted 10 lines · Cesar Eduardo Barros

Quoted 4 lines

And, in fact, there is a CRC code in the block layer; it is CONFIG_BLK_DEV_INTEGRITY. However, it is not a generic solution; it needs some extra prerequisites (like a disk low-level formatted with sectors with

Quoted 1 line

512 bytes).

You mean BLK_DEV_INTEGRITY has a dependency with block device driver? If you want to support checksum into suspend, At last, should we put the checksum on disk?

Quoted 2 lines

I mean could we extend BLK_DEV_INTEGRITY by more generic solution? As you said, in case of swap, we don't need to put checksum on disk.

CONFIG_BLK_DEV_INTEGRITY writes the checksum to the same sector as the data. However, for that to be possible, the sector size is increased on the disk itself, from 512 bytes to 520 bytes (and not all disks can do that). It is not a generic solution. It also, as

far as I can see, does nothing against the disk simply failing to write and later returning stale data, since the stale checksum would match the stale data.

See the LWN article [1] and the presentations [2] for more detail.

For suspend, the swap checksum pages would be saved together with the rest of the memory (they are in the memory, after all), and the suspend snapshot would have its own separate checksum (written directly to the disk after the image).

Quoted 8 lines

If swap case, let it put the one on memory. If non-swap case, let it put checksum on disk,
I am not sure it's possible.

When we have a unreliable disk, your point is that let's solve it with (btrfs + swap) which both supports checksum. And my point is that let's solve it with (any file system + swap) which is put on block layer which supports checksum.

A generic "checksumming block device" would be less efficient.

For the swap case, it cannot exploit the fact that its state tracking is within the swapfile code. Avi Kivity's idea of storing the checksum in otherwise wasted bits of the pte is an example of how this could be exploited in the future. In fact, the reason I did it on the swap layer (instead of interposing something in the block layer) was precisely to make it easier to enhance the state tracking in the future (and also because it felt the most natural layer to do it).

It would also complicate adding checksums to the software suspend snapshot. While normally you do not want to write the swap checksums to the disk, you do want to write them when saving the memory snapshot - which is written to the same block device. However, the checksums for the rest of the swap pages are already being saved as part of the memory snapshot (since the checksums were in the memory).

For the generic ("any file system") case, it is worse, since you actually have to write the checksum to the disk, and unlike in the software suspend case you cannot simply write them all in one pass at the end. In the worst case, you would have to write twice for each sector/page - once for the data, and once for the checksums (CONFIG_BLK_DEV_INTEGRITY completely avoids this issue since with it the checksum is together with the data in the same sector). Not to mention fun things like write amplification.

A filesystem with data checksums can write the checksum as part of its normal metadata updates (which it already has to do anyway).

A generic "checksumming block device" could be a way of "updating" a filesystem without checksums (or with only metadata checksums) to have them. However, I believe it would be more productive to add them directly to the filesystem itself. Even more since the only way I can see of doing it efficiently in a generic block layer is by using lots of filesystem-style tricks (things like a log-structured list of CRC values, dividing the device in "block groups" to keep the checksum close to the data, and so on).

[1] Block layer: integrity checking and lots of partitions

    http://lwn.net/Articles/290141/

[2] http://oss.oracle.com/projects/data-integrity/documentation/

Signature · 4 lines

-- 
Cesar Eduardo Barros
[email protected]
[email protected]

Quoted 3 lines · Cesar Eduardo Barros

far as I can see, does nothing against the disk simply failing to write and later returning stale data, since the stale checksum would match the stale data.

Sorry. I can't understand your point.
Who makes stale data? If any layer makes data as stale, integrity is up to the layer. Maybe I am missing your point.
Could you explain more detail?

Quoted 9 lines · Minchan Kim

Quoted 3 lines · Cesar Eduardo Barros

far as I can see, does nothing against the disk simply failing to write and later returning stale data, since the stale checksum would match the stale data.

Sorry. I can't understand your point.
Who makes stale data? If any layer makes data as stale, integrity is up to the layer. Maybe I am missing your point.
Could you explain more detail?

I'm pretty sure that what Cesar meant was that the following could happen:

1) Write block 11983 on the disk, checksum 34FE9B72.
(... time passes.. maybe weeks)
2) Attempt to write block 11983 on disk with checksum AE9F3581. The write fails due to a power failure or something.
(... more time passes...)
3) Read block 11983, get back data with checksum 34FE9B72. Checksum matches, and there's no indication that the write in (2) ever failed. The program proceeds thinking it's just read back the most recently written data, when in fact it's just read an older version of that block. Problems can ensue if the data just read is now out of sync with *other* blocks of data - instant data corruption.

Quoted 13 lines · Minchan Kim

Quoted 9 lines · Cesar Eduardo Barros

Quoted 3 lines

far as I can see, does nothing against the disk simply failing to write and later returning stale data, since the stale checksum would match the stale data.

Sorry. I can't understand your point.
Who makes stale data? If any layer makes data as stale, integrity is up to the layer. Maybe I am missing your point.
Could you explain more detail?

I'm pretty sure that what Cesar meant was that the following could happen:

Quoted 11 lines

1) Write block 11983 on the disk, checksum 34FE9B72.
(... time passes.. maybe weeks)
2) Attempt to write block 11983 on disk with checksum AE9F3581. The write fails due to a power failure or something.
(... more time passes...)
3) Read block 11983, get back data with checksum 34FE9B72. Checksum matches, and there's no indication that the write in (2) ever failed. The program proceeds thinking it's just read back the most recently written data, when in fact it's just read an older version of that block. Problems can ensue if the data just read is now out of sync with *other* blocks of data - instant data corruption.

Oh, doesn't normal disk support atomicity of sector write?
I have been thought disk must support atomicity of sector write at least.

Em 26-05-2010 19:45, Minchan Kim escreveu:

Quoted 37 lines · On Thu, May 27, 2010 at 6:28 AM,<[email protected]>  wrote:

Quoted 34 lines · Minchan Kim

Quoted 7 lines · Cesar Eduardo Barros

Quoted 4 lines

far as I can see, does nothing against the disk simply failing to write and later returning stale data, since the stale checksum would match the stale data.

Quoted 5 lines

Sorry. I can't understand your point.
Who makes stale data? If any layer makes data as stale, integrity is up to
the layer. Maybe I am missing your point.
Could you explain more detail?

I'm pretty sure that what Cesar meant was that the following could happen:

1) Write block 11983 on the disk, checksum 34FE9B72.
(... time passes.. maybe weeks)
2) Attempt to write block 11983 on disk with checksum AE9F3581. The write fails
due to a power failure or something.
(... more time passes...)
3) Read block 11983, get back data with checksum 34FE9B72. Checksum matches,
and there's no indication that the write in (2) ever failed. The program proceeds thinking it's just read back the most recently written data, when in
fact it's just read an older version of that block. Problems can ensue if the
data just read is now out of sync with *other* blocks of data - instant data
corruption.

Quoted 2 lines

Oh, doesn't normal disk support atomicity of sector write?
I have been thought disk must support atomicity of sector write at least.

It is called a "high fly write" (a write where the disk head was flying too high and the data did not get written at all). There are other causes than high fly writes for this, of course, but the symptom is the same: whatever you were trying to write was not written at all, and the old contents are still there.

The write is still atomic: it either did happen completely or did not happen at all (in this case, it did not happen at all). You *can* have a partial write (with a well-timed power loss, for instance), but the disk's own ECC will detect this as a corrupted sector and return an error on read.

--
Cesar Eduardo Barros
[email protected]
[email protected]