kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-09-18 18:15:59 +00:00
Code Issues Releases Packages Activity
linux/include/asm-s390/bitops.h

1029 lines
30 KiB
Raw Normal View History

Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] s390: test_bit return value The test_bit function returns a non-boolean value, it returns 0,1,2,4,... instead of only 0 or 1. This causes wrongs results in the mincore system call. Check against 0 to get a proper boolean value. Signed-off-by: Christian Borntraeger <cborntra@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-07 00:59:07 -08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] s390: find_next_{zero}_bit fixes The find_next_{zero}_bit primitives on s390* should never return a bit number bigger then the bit field size. In the case of a bitfield that doesn't end on a word boundary, an offset that makes the search start at the last word of the bit field and the last word doesn't contain any zero/one bits the search is continued with a call to find_first_bit with a negative size. The search normally ends pretty quickly because the words following the bit field contain a mix of zeros and ones. But the bit number that is returned in this case is too big. To fix this and additional if to check for this case is needed. To make the code easier to read I removed the assembler parts from the find_next_{zero}_bit functions, the C-ified code is as good. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-27 11:44:58 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] s390: find_next_{zero}_bit fixes The find_next_{zero}_bit primitives on s390* should never return a bit number bigger then the bit field size. In the case of a bitfield that doesn't end on a word boundary, an offset that makes the search start at the last word of the bit field and the last word doesn't contain any zero/one bits the search is continued with a call to find_first_bit with a negative size. The search normally ends pretty quickly because the words following the bit field contain a mix of zeros and ones. But the bit number that is returned in this case is too big. To fix this and additional if to check for this case is needed. To make the code easier to read I removed the assembler parts from the find_next_{zero}_bit functions, the C-ified code is as good. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-27 11:44:58 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] s390: find_next_{zero}_bit fixes The find_next_{zero}_bit primitives on s390* should never return a bit number bigger then the bit field size. In the case of a bitfield that doesn't end on a word boundary, an offset that makes the search start at the last word of the bit field and the last word doesn't contain any zero/one bits the search is continued with a call to find_first_bit with a negative size. The search normally ends pretty quickly because the words following the bit field contain a mix of zeros and ones. But the bit number that is returned in this case is too big. To fix this and additional if to check for this case is needed. To make the code easier to read I removed the assembler parts from the find_next_{zero}_bit functions, the C-ified code is as good. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-27 11:44:58 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] s390: find_next_{zero}_bit fixes The find_next_{zero}_bit primitives on s390* should never return a bit number bigger then the bit field size. In the case of a bitfield that doesn't end on a word boundary, an offset that makes the search start at the last word of the bit field and the last word doesn't contain any zero/one bits the search is continued with a call to find_first_bit with a negative size. The search normally ends pretty quickly because the words following the bit field contain a mix of zeros and ones. But the bit number that is returned in this case is too big. To fix this and additional if to check for this case is needed. To make the code easier to read I removed the assembler parts from the find_next_{zero}_bit functions, the C-ified code is as good. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-27 11:44:58 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] s390: find_next_{zero}_bit fixes The find_next_{zero}_bit primitives on s390* should never return a bit number bigger then the bit field size. In the case of a bitfield that doesn't end on a word boundary, an offset that makes the search start at the last word of the bit field and the last word doesn't contain any zero/one bits the search is continued with a call to find_first_bit with a negative size. The search normally ends pretty quickly because the words following the bit field contain a mix of zeros and ones. But the bit number that is returned in this case is too big. To fix this and additional if to check for this case is needed. To make the code easier to read I removed the assembler parts from the find_next_{zero}_bit functions, the C-ified code is as good. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-27 11:44:58 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] s390: find_next_{zero}_bit fixes The find_next_{zero}_bit primitives on s390* should never return a bit number bigger then the bit field size. In the case of a bitfield that doesn't end on a word boundary, an offset that makes the search start at the last word of the bit field and the last word doesn't contain any zero/one bits the search is continued with a call to find_first_bit with a negative size. The search normally ends pretty quickly because the words following the bit field contain a mix of zeros and ones. But the bit number that is returned in this case is too big. To fix this and additional if to check for this case is needed. To make the code easier to read I removed the assembler parts from the find_next_{zero}_bit functions, the C-ified code is as good. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-27 11:44:58 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] s390: find_next_{zero}_bit fixes The find_next_{zero}_bit primitives on s390* should never return a bit number bigger then the bit field size. In the case of a bitfield that doesn't end on a word boundary, an offset that makes the search start at the last word of the bit field and the last word doesn't contain any zero/one bits the search is continued with a call to find_first_bit with a negative size. The search normally ends pretty quickly because the words following the bit field contain a mix of zeros and ones. But the bit number that is returned in this case is too big. To fix this and additional if to check for this case is needed. To make the code easier to read I removed the assembler parts from the find_next_{zero}_bit functions, the C-ified code is as good. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-27 11:44:58 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] s390: find_next_{zero}_bit fixes The find_next_{zero}_bit primitives on s390* should never return a bit number bigger then the bit field size. In the case of a bitfield that doesn't end on a word boundary, an offset that makes the search start at the last word of the bit field and the last word doesn't contain any zero/one bits the search is continued with a call to find_first_bit with a negative size. The search normally ends pretty quickly because the words following the bit field contain a mix of zeros and ones. But the bit number that is returned in this case is too big. To fix this and additional if to check for this case is needed. To make the code easier to read I removed the assembler parts from the find_next_{zero}_bit functions, the C-ified code is as good. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-27 11:44:58 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] s390: find_next_{zero}_bit fixes The find_next_{zero}_bit primitives on s390* should never return a bit number bigger then the bit field size. In the case of a bitfield that doesn't end on a word boundary, an offset that makes the search start at the last word of the bit field and the last word doesn't contain any zero/one bits the search is continued with a call to find_first_bit with a negative size. The search normally ends pretty quickly because the words following the bit field contain a mix of zeros and ones. But the bit number that is returned in this case is too big. To fix this and additional if to check for this case is needed. To make the code easier to read I removed the assembler parts from the find_next_{zero}_bit functions, the C-ified code is as good. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-27 11:44:58 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] s390: find_next_{zero}_bit fixes The find_next_{zero}_bit primitives on s390* should never return a bit number bigger then the bit field size. In the case of a bitfield that doesn't end on a word boundary, an offset that makes the search start at the last word of the bit field and the last word doesn't contain any zero/one bits the search is continued with a call to find_first_bit with a negative size. The search normally ends pretty quickly because the words following the bit field contain a mix of zeros and ones. But the bit number that is returned in this case is too big. To fix this and additional if to check for this case is needed. To make the code easier to read I removed the assembler parts from the find_next_{zero}_bit functions, the C-ified code is as good. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-27 11:44:58 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] s390: find_next_{zero}_bit fixes The find_next_{zero}_bit primitives on s390* should never return a bit number bigger then the bit field size. In the case of a bitfield that doesn't end on a word boundary, an offset that makes the search start at the last word of the bit field and the last word doesn't contain any zero/one bits the search is continued with a call to find_first_bit with a negative size. The search normally ends pretty quickly because the words following the bit field contain a mix of zeros and ones. But the bit number that is returned in this case is too big. To fix this and additional if to check for this case is needed. To make the code easier to read I removed the assembler parts from the find_next_{zero}_bit functions, the C-ified code is as good. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-27 11:44:58 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] s390: find_next_{zero}_bit fixes The find_next_{zero}_bit primitives on s390* should never return a bit number bigger then the bit field size. In the case of a bitfield that doesn't end on a word boundary, an offset that makes the search start at the last word of the bit field and the last word doesn't contain any zero/one bits the search is continued with a call to find_first_bit with a negative size. The search normally ends pretty quickly because the words following the bit field contain a mix of zeros and ones. But the bit number that is returned in this case is too big. To fix this and additional if to check for this case is needed. To make the code easier to read I removed the assembler parts from the find_next_{zero}_bit functions, the C-ified code is as good. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-27 11:44:58 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] s390: find_next_{zero}_bit fixes The find_next_{zero}_bit primitives on s390* should never return a bit number bigger then the bit field size. In the case of a bitfield that doesn't end on a word boundary, an offset that makes the search start at the last word of the bit field and the last word doesn't contain any zero/one bits the search is continued with a call to find_first_bit with a negative size. The search normally ends pretty quickly because the words following the bit field contain a mix of zeros and ones. But the bit number that is returned in this case is too big. To fix this and additional if to check for this case is needed. To make the code easier to read I removed the assembler parts from the find_next_{zero}_bit functions, the C-ified code is as good. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-27 11:44:58 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[FLS64]: generic version Signed-off-by: Stephen Hemminger <shemminger@osdl.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-12-21 19:30:53 -08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] s390: find_next_{zero}_bit fixes The find_next_{zero}_bit primitives on s390* should never return a bit number bigger then the bit field size. In the case of a bitfield that doesn't end on a word boundary, an offset that makes the search start at the last word of the bit field and the last word doesn't contain any zero/one bits the search is continued with a call to find_first_bit with a negative size. The search normally ends pretty quickly because the words following the bit field contain a mix of zeros and ones. But the bit number that is returned in this case is too big. To fix this and additional if to check for this case is needed. To make the code easier to read I removed the assembler parts from the find_next_{zero}_bit functions, the C-ified code is as good. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-27 11:44:58 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] s390: find_next_{zero}_bit fixes The find_next_{zero}_bit primitives on s390* should never return a bit number bigger then the bit field size. In the case of a bitfield that doesn't end on a word boundary, an offset that makes the search start at the last word of the bit field and the last word doesn't contain any zero/one bits the search is continued with a call to find_first_bit with a negative size. The search normally ends pretty quickly because the words following the bit field contain a mix of zeros and ones. But the bit number that is returned in this case is too big. To fix this and additional if to check for this case is needed. To make the code easier to read I removed the assembler parts from the find_next_{zero}_bit functions, the C-ified code is as good. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-27 11:44:58 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] s390: find_next_{zero}_bit fixes The find_next_{zero}_bit primitives on s390* should never return a bit number bigger then the bit field size. In the case of a bitfield that doesn't end on a word boundary, an offset that makes the search start at the last word of the bit field and the last word doesn't contain any zero/one bits the search is continued with a call to find_first_bit with a negative size. The search normally ends pretty quickly because the words following the bit field contain a mix of zeros and ones. But the bit number that is returned in this case is too big. To fix this and additional if to check for this case is needed. To make the code easier to read I removed the assembler parts from the find_next_{zero}_bit functions, the C-ified code is as good. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-27 11:44:58 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] s390: find_next_{zero}_bit fixes The find_next_{zero}_bit primitives on s390* should never return a bit number bigger then the bit field size. In the case of a bitfield that doesn't end on a word boundary, an offset that makes the search start at the last word of the bit field and the last word doesn't contain any zero/one bits the search is continued with a call to find_first_bit with a negative size. The search normally ends pretty quickly because the words following the bit field contain a mix of zeros and ones. But the bit number that is returned in this case is too big. To fix this and additional if to check for this case is needed. To make the code easier to read I removed the assembler parts from the find_next_{zero}_bit functions, the C-ified code is as good. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-27 11:44:58 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] s390: find_next_{zero}_bit fixes The find_next_{zero}_bit primitives on s390* should never return a bit number bigger then the bit field size. In the case of a bitfield that doesn't end on a word boundary, an offset that makes the search start at the last word of the bit field and the last word doesn't contain any zero/one bits the search is continued with a call to find_first_bit with a negative size. The search normally ends pretty quickly because the words following the bit field contain a mix of zeros and ones. But the bit number that is returned in this case is too big. To fix this and additional if to check for this case is needed. To make the code easier to read I removed the assembler parts from the find_next_{zero}_bit functions, the C-ified code is as good. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-27 11:44:58 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00