linux-stable.git/include/asm-m68k, branch linux-2.6.17.y

[PATCH] m68k: fix undefined reference to generic_find_next_zero_le_bit

2006-03-26T16:57:13+00:00

This patch reverts ext2 bitmap functions.

Signed-off-by: Akinobu Mita 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] bitops: m68k: use generic bitops

2006-03-26T16:57:12+00:00

- remove generic_fls64()
- remove sched_find_first_bit()
- remove generic_hweight()
- remove ext2_{set,clear,test,find_first_zero,find_next_zero}_bit()

Signed-off-by: Akinobu Mita 
Cc: Roman Zippel 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] bitops: use non atomic operations for minix__bit() and ext2__bit()

2006-03-26T16:57:10+00:00

Bitmap functions for the minix filesystem and the ext2 filesystem except
ext2_set_bit_atomic() and ext2_clear_bit_atomic() do not require the atomic
guarantees.

But these are defined by using atomic bit operations on several architectures.
 (cris, frv, h8300, ia64, m32r, m68k, m68knommu, mips, s390, sh, sh64, sparc,
sparc64, v850, and xtensa)

This patch switches to non atomic bit operation.

Signed-off-by: Akinobu Mita 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] 2TB files: st_blocks is invalid when calling stat64

2006-03-26T16:57:00+00:00

This patch series fixes the following problems on 32 bits architecture.

o stat64 returns the lower 32 bits of blocks, although userland st_blocks
  has 64 bits, because i_blocks has only 32 bits.  The ioctl with FIOQSIZE has
  the same problem.

o As Dave Kleikamp said, making >2TB file on JFS results in writing an
  invalid block number to disk inode.  The cause is the same as above too.

o In generic quota code dquot_transfer(), the file usage is calculated from
  i_blocks via inode_get_bytes().  If the file is over 2TB, the change of
  usage is less than expected.  The cause is the same as above too.

o As Trond Myklebust said, statfs64's entries related to blocks are invalid
  on statfs64 for a network filesystem which has more than 2^32-1 blocks with
  CONFIG_LBD disabled.  [PATCH 3/3]

We made patches to fix problems that occur when handling a large filesystem
and a large file.  It was discussed on the mails titled "stat64 for over 2TB
file returned invalid st_blocks".

Signed-off-by: Takashi Sato 
Cc: Dave Kleikamp 
Cc: Jan Kara 
Cc: Trond Myklebust 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] POLLRDHUP/EPOLLRDHUP handling for half-closed devices notifications

2006-03-25T16:22:56+00:00

Implement the half-closed devices notifiation, by adding a new POLLRDHUP
(and its alias EPOLLRDHUP) bit to the existing poll/select sets.  Since the
existing POLLHUP handling, that does not report correctly half-closed
devices, was feared to be changed, this implementation leaves the current
POLLHUP reporting unchanged and simply add a new bit that is set in the few
places where it makes sense.  The same thing was discussed and conceptually
agreed quite some time ago:

http://lkml.org/lkml/2003/7/12/116

Since this new event bit is added to the existing Linux poll infrastruture,
even the existing poll/select system calls will be able to use it.  As far
as the existing POLLHUP handling, the patch leaves it as is.  The
pollrdhup-2.6.16.rc5-0.10.diff defines the POLLRDHUP for all the existing
archs and sets the bit in the six relevant files.  The other attached diff
is the simple change required to sys/epoll.h to add the EPOLLRDHUP
definition.

There is "a stupid program" to test POLLRDHUP delivery here:

 http://www.xmailserver.org/pollrdhup-test.c

It tests poll(2), but since the delivery is same epoll(2) will work equally.

Signed-off-by: Davide Libenzi 
Cc: "David S. Miller" 
Cc: Michael Kerrisk 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] atomic: add_unless cmpxchg optimise

2006-03-23T15:38:17+00:00

Without branch hints, the very unlikely chance of the loop repeating due to
cmpxchg failure is unrolled with gcc-4 that I have tested.

Improve this for architectures with a native cas/cmpxchg.  llsc archs
should try to implement this natively.

Signed-off-by: Nick Piggin 
Cc: Andi Kleen 
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: "David S. Miller" 
Cc: Roman Zippel 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] m68k: fix cmpxchg compile errors if CONFIG_RMW_INSNS=n

2006-03-10T03:47:38+00:00

We require that all archs implement atomic_cmpxchg(), for the generic
version of atomic_add_unless().

Signed-off-by: Roman Zippel 
Cc: Geert Uytterhoeven 
Cc: Adrian Bunk 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] iomap_copy fallout (m68k)

2006-02-18T21:30:40+00:00

added __raw_writel(), sanitized include order in iomap_copy.c

Signed-off-by: Al Viro

[PATCH] m68k: restore disable_irq_nosync()

2006-02-18T20:59:06+00:00

Patch claiming to remove enable_irq_nosync() had left it alive but killed
disable_irq_nosync() instead...

Signed-off-by: Al Viro

[PATCH] add asm-generic/mman.h

2006-02-15T23:32:22+00:00

Make new MADV_REMOVE, MADV_DONTFORK, MADV_DOFORK consistent across all
arches.  The idea is to make it possible to use them portably even before
distros include them in libc headers.

Move common flags to asm-generic/mman.h

Signed-off-by: Michael S. Tsirkin 
Cc: Roland Dreier 
Cc: Badari Pulavarty 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds