Gerd Knorr [Thu, 21 Aug 2003 02:53:10 +0000 (19:53 -0700)]
[PATCH] v4l: remove stale CONFIG_VIDEO_PROC_FS
* makes the three USB drivers not use the procfs stuff, also added a
warning that they should converted to sysfs.
* Removes the leftover, obsolete VIDEO_PROC_FS config option, that
should catch any other build failures too (if any).
Andrew Morton [Wed, 20 Aug 2003 17:29:16 +0000 (10:29 -0700)]
[PATCH] fix /proc mm_struct refcounting bug
From: Suparna Bhattacharya <suparna@in.ibm.com>
The /proc code's bare atomic_inc(&mm->count) is racy against __exit_mm()'s
mmput() on another CPU: it calls mmput() outside task_lock(tsk), and
task_lock() isn't appropriate locking anyway.
The patch implements a new mmgrab() routine which increments mm_users only if
the mm isn't already going away. Changes get_task_mm() and proc_pid_stat()
to call mmgrab() instead of a direct atomic_inc(&mm->mm_users).
Hugh, there's some cruft in swapoff which looks like it should be using
mmgrab()...
Andrew Morton [Wed, 20 Aug 2003 17:29:07 +0000 (10:29 -0700)]
[PATCH] Fix CPU boot problem
From: Dave Hansen <haveblue@us.ibm.com>
Hmmm. This is looking like fallout from the massive wli-bomb. Here's
the loop that controls the cpu booting, before and after cpumask_t:
- for (bit = 0; kicked < NR_CPUS && bit < BITS_PER_LONG; bit++)
+ for (bit = 0; kicked < NR_CPUS && bit < MAX_APICS; bit++)
apicid = cpu_present_to_apicid(bit);
"kicked" only gets incremented for CPUs that were successfully booted,
so it doesn't help terminate the loop much. MAX_APICS is 256 on summit,
which is *MUCH* bigger than BITS_PER_LONG.
cpu_2_logical_apicid[NR_CPUS] which is referenced from
cpu_present_to_apicid() is getting referenced up to MAX_APICs, which is
bigger than NR_CPUS. Overflow. Bang. garbage != BAD_APICID :)
Andrew Morton [Wed, 20 Aug 2003 17:28:44 +0000 (10:28 -0700)]
[PATCH] fix for htree corruption
From: chrisl@vmware.com
Fixes the "perl installer weirdness" problem which a few people have been
reporting.
The bug is triggered by creating the index. Coping out the index we assume
the dirents start with the first entry after "." "..".
It can make the first previous deleted entry reappear. In the past we set
inode to zero for an empty entry so this is not a problem. That is not
true any more.
Also, there were a few places where we were altering inode times after
running ext3_mark_inode_dirty(). We should be doing that beforehand.
Andrew Morton [Wed, 20 Aug 2003 17:28:19 +0000 (10:28 -0700)]
[PATCH] fix intel copy_to_user()
A `cat /dev/kmem' oopses the kernel. This is because new Intel
copy_to_user() doesn't handle segfaults against the kernel-side source
address of the copy.
It is not obvious how to fix read_kmem(), and handling faults on either
source or dest is traditional behaviour, so fix it in the copy function by
adding exception table entries for the reads as well as the writes.
Andrew Morton [Wed, 20 Aug 2003 17:27:47 +0000 (10:27 -0700)]
[PATCH] dscc4: reset changes
From: Francois Romieu <romieu@fr.zoreil.com>
Workaround for lack of true reset:
- devices/ports are put in silent mode at ifconfig down time but some
state is kept around to allow 'ifconfig up' issuing at a later time.
Device specific structures are allocated when the pci asic is
probed: dscc4_init_ring() moves from dscc4_open() to dscc4_found1().
- try to use reset related board-specific feature at module removal
time if available. Comments in the code explain the whole story.
Not a complicated feature but it is unavailable on the cards I own
and no user gave me feedback -> currently untested.
It shouldn't harm anyway.
Andrew Morton [Wed, 20 Aug 2003 17:27:39 +0000 (10:27 -0700)]
[PATCH] dscc4: scc changes
From: Francois Romieu <romieu@fr.zoreil.com>
- more #define for specific bits;
- more scc_patchl use;
- just say no to bozo programming:
+ SCC core _really_ disabled at startup;
+ Interrupts Mask Register setup and SCC core activation are
done as late as possible (i.e. in dscc4_open());
+ they are reverted if dscc4_open() fails;
+ as well as unconditionnaly in dscc4_close();
- more or less paranoid quirk in Xpr handler.
Andrew Morton [Wed, 20 Aug 2003 17:26:57 +0000 (10:26 -0700)]
[PATCH] Allow O_EXCL on a block device to claim exclusive use.
From: NeilBrown <neilb@cse.unsw.edu.au>
The blockdev layer has a concept of 'claiming' a device, so for example it
can be claimed when a filesystem is mounted or when it is included into a
raid array. Only one subsystem can claim it at a time.
This patch matches this functionality available to user-space via the
O_EXCL flag to open.
This allows user-space programs to easily test if a device is currently
mounted etc, and to prevent a device from being mounted or otherwise
claimed.
Andrew Morton [Wed, 20 Aug 2003 17:26:48 +0000 (10:26 -0700)]
[PATCH] When a partition is claimed, claim the whole device
From: NeilBrown <neilb@cse.unsw.edu.au>
Current devices can be 'claimed' by filesystems (when mounting) or
md/raid (when being included in an array) or 'raw' or ....
This stop concurrent access by these systems.
However it is still possible for one system to claim the whole device
and a second system to claim one partition, which is not good.
With this patch, when a partition is claimed, the whole device is
claimed for partitioning. So you cannot have a partition and the
whole devices claimed at the same time (except if the whole device
is claimed for partitioning).
Andrew Morton [Wed, 20 Aug 2003 17:26:39 +0000 (10:26 -0700)]
[PATCH] vmscan: give dirty referenced pages another pass
In a further attempt to prevent dirty pages from being written out from the
LRU, don't write them if they were referenced. This gives those pages
another trip around the inactive list. So more of them are written via
balance_dirty_pages().
It speeds up an untar-of-five-kernel trees by 5% on a 256M box, presumably
because balance_dirty_pages() has better IO patterns.
It largely fixes the problem which Gerrit talked about at the kernel summit:
the individual writepage()s of dirty pages coming off the tail of the LRU are
reduced by 83% in their database workload.
I'm a bit worried that it increases scanning and OOM possibilities under
nutty VM stress cases, but nothing untoward has been noted during its four
weeks in -mm, so...
Jeff Garzik [Wed, 20 Aug 2003 09:26:16 +0000 (02:26 -0700)]
[PATCH] remove mount_root_failed_msg()
This one snuck in...
- debugging message for ACPI
- Intel guys removed it from their 2.4 tree (at my request)
- it's point-in-time specific (message becomes nearly useless after
ACPI bug fixes)
- b/c of the point-in-time issue, it's IMO much more appropriate for a
vendor kernel (where the message, I agree, may be helpful)
- can potentially mislead users to the correct cause of root mount failure
- overall, I disagree with adding messages like this. The number one
bug report, by far, for networking drivers is ACPI-related (no
interrupts delivered). You don't see me adding "boot with acpi=off"
messages to the net subsystem.
Ronald Bultje [Wed, 20 Aug 2003 07:30:34 +0000 (00:30 -0700)]
[PATCH] Big zoran driver update
This is a patch for the video4linux unified zoran driver that has been
in the kernel since 2.4.5 or so.
It fixes the compile issues in the current 2.6.0-test3 unified zoran
driver (current one doesn't compile at all), and also updates its
version to what we have in CVS. This adds support for new cards (e.g.
LML33R10 from LinuxMediaLabs and DC30+ from Pinnacle), fixes bugs in
cards that were already supported and generally improves capture
reliability. Changes per file (in detail) are given below.
i2c-id.h:
add some new IDs for new i2c drivers
pci_ids.h:
add PCI IDs for each of the supported cards if it has any
saa7111.c, saa7110.c, adv7175.c, bt819.c, saa7185.c, bt856.c:
update to whatever we've got in our CVS. For most, these are just
"easiness" fixes that either add some better debug output, or that make
maintainance for both 2.6.x and 2.4.x simpler for me. There's also some
specific changes. E.g., in saa7110.c, we enable the VCR mode bits so we
get a better image from VCR input. In all of them, we make debugging an
insmod option rather than a compile-time option (this makes debugging
for users a *lot* easier). Point is that I just want our latest CVS in
here. Maintainance is going to be a personal horror-story if it's not.
vpx3220.c, saa7114.c, adv7170.c:
new i2c ones (for respectively DC10/DC30, LML33R10 and again LML33R10)
zr36067.c:
removed, the driver is now spread over multiple source files.
zoran*.[ch], zr36057.h
spread-out source files. Also fixes lots of bugs, can't even start
naming them all, you don't want that, neither do I. Just assume that it
works better than it used to - it does.
Nice things that aren't in the old driver: much more stable, supports
DC30+, supports LML33R10, has proper locking/semaphores, supports
multiple opens without races now, adapted to new i2c subsystem, v4l2
support, Xv (hardware-scaled) overlay support, and a lot more.
Oh, and this one actually compiles.
videocodec.[ch], zr360{16,50,60}.[ch]:
new sublayer for the driver to unify how we handle the zr36060 chip
(DC10(+)/LML33/LML33R10/Buz) and the zr36050/zr36016 (DC30(+)).
MAINTAINERS:
add me as maintainer (I am).
Kconfig:
add new cards, plus improve the descriptions.
Makefile:
d'oh.
Zoran:
documentation update.
Others:
I don't think there are any.
Greg has gone over the i2c changes a long time ago, he agreed on all of
them. Gerd is supposed to take care of the v4l part, he has never
complained about any of them. Stability is good, we've fixed most issues
(there's still some out there, but nothing serious), lots better than in
the old driver. Also, the cards work much better than with the old
driver.
Albert Cahalan [Wed, 20 Aug 2003 04:53:41 +0000 (21:53 -0700)]
[PATCH] IO port bitmap cleanups, x86-64 oops fix
This patch brings x86-64 and i386 closer together, eliminating an oops
that LTP test ioperm02.c causes on x86-64. An IO port permission bitmap
must be followed by an extra 0xff.
(Add comments to that effect, to avoid the problem in the future).
Trond Myklebust [Wed, 20 Aug 2003 04:35:45 +0000 (21:35 -0700)]
[PATCH] Support dentry revalidation under open(".")
link_path_walk() currently treats the special filenames ".", ".."
and "/" differently in that it does not call down to the filesystem in
order to revalidate the cached dentry, but just assumes that it is
fine.
For most filesystems this is OK, but it the case of the stateless
NFS, this means that it circumvents path staleness detection, and the
attribute+data cache revalidation code on such common commands as
opendir(".").
This change provides a way to do such revalidation for NFS without
impacting other filesystems.
Note: the failure to revalidate the path here does not result in a
call to d_invalidate() unlike (all?) other calls to d_revalidate(). It
only results in an ESTALE error being returned to the caller.
- set owner field on tty ldisc
- allocate network device objects with alloc_netdev
- use list_head macros and put locking around list of devices
- convert to seq_file for /proc
- use change_mtu hook rather than guessing at mtu changes
When doing the audit for this change, it was obvious that several drivers
allocate but never free the net_device.
This fixes these drivers. This patch is riskier than the earlier
ones, because it isn't just a simple substitution and maybe there
is a reason they never free.
[NET]: free_netdev - free network device on last class_device_usage
This patch adds the free_netdev function and associated
changes so that net_device structures are not freed until
last reference to the network device class is released.
Russell King [Tue, 19 Aug 2003 20:46:33 +0000 (21:46 +0100)]
[ARM] Remove redundant CONFIG_DEBUG_INFO.
ARM had CONFIG_DEBUG_INFO for ages. Unfortunately, the new
CONFIG_DEBUG_INFO was rather blindly applied across all architectures.
This removes the duplication from the ARM architecture.