Andrew Morton [Tue, 17 Feb 2004 11:32:13 +0000 (03:32 -0800)]
[PATCH] Tuner bugfix
From: Neal Stephenson <neal@bakerst.org>
In 2.6.2, I noticed that my modprobe.conf line for tuner "options tuner
type=2" no longer worked. It even failed with insmod "insmod tuner.ko
type=2". dmesg reported
vmunix: tuner: chip found @ 0xc0
vmunix: tuner: type set to 19 (Temic PAL* auto (4006 FN5))
vmunix: tuner: type forced to 19 (Temic PAL* auto (4006 FN5)) [insmod]
I noticed that the a line had been removed from 2.6.1 and when it is added
everything works again.
Roman Zippel [Tue, 17 Feb 2004 08:52:46 +0000 (00:52 -0800)]
[PATCH] Avoid bogus warning about recursive dependencies
This allows us to do something like
config FB_RADEON
select I2C_ALGOBIT if FB_RADEON_I2C
where FB_RADEON_I2C itself depends on FB_RADEON without getting a bogus
warning about recursive dependencies.
This matters because the select takes the default minimum dependancy
from the parent menu, so we want to do this under FB_RADEON rather than
under FB_RADEON_I2C (so that the I2C_ALGOBIT config depends properly
on the state of FB_RADEON)
Alexander Viro [Tue, 17 Feb 2004 08:49:03 +0000 (00:49 -0800)]
[PATCH] blkdev_put() data corruption
We used to have sync_blockdev() on each normal (== non-raw)
blkdev_put() + kill_bdev() on the final blkdev_put(). That worked
fine until we'd moved sync_blockdev() to the final blkdev_put().
Now we have a nasty scenario:
open block device
open raw device
write on block device # data ends up in cache
close block device # no sync here, we still have the sucker opened
close raw device # no sync here either
# ... and cache is killed by kill_bdev()
IOW, if we postpone sync to final close, we must do it regardless of
kind of close. Otherwise we are in for data corruption and yes, it is easy
to trigger. Fix is obvious...
Jim Paradis [Tue, 17 Feb 2004 05:23:23 +0000 (21:23 -0800)]
[PATCH] Fix fencepost error in x86_64 IOMMU
There's a fencepost error in the GART IOMMU handling on x86_64
in the unmap path. When testing to see if the bus address is
within the IOMMU window and needs to be unmapped, the start of
the first page *beyond* the window also passes the test. This
can cause the first doubleword of the next page beyond the gatt
table to be smashed to zero, with unpredictable results depending
on what that page is used for.
Andrew Morton [Tue, 17 Feb 2004 02:32:47 +0000 (18:32 -0800)]
[PATCH] mremap NULL pointer dereference fix
This is a cleaned-up version of a mremap() fix for "move_one_page()"
by Rajesh Venkatasubramanian <vrajesh@umich.edu>. We could use a NULL
"src" pointer.
Because while we do hold the MM semaphore over the whole sequence, the
destination page table allocation will possibly drop the page table
spinlock. That in turn can cause a clean source page to be stolen by
page reclaim, causing the source-side "get_one_pte_map_nested()" to
return NULL the second time around even if it didn't on the first case.
So we just check "src" again, and get rid of the bogus TLB invalidate
while we're at it.
The rtasd kernel thread would exit before daemoniz'ing itself if
RTAS wasn't present (or if allocation of the buffer failed), thus
leaving a zombie. This patch fixes it (and remove #if 0'ed code)
[PATCH] make __ide_dma_off() generic and remove ide_hwif_t->ide_dma_off
Move ide-dma.c:__ide_dma_off() outside of #ifdef CONFIG_BLK_DEV_IDEDMA_PCI,
so it can be used for all DMA capable hosts. Remove ide_hwif_t->ide_dma_off.
[PATCH] remove __ide_dma_count() and ide_hwif_t->ide_dma_count
->ide_dma_count() was introduced in kernel 2.5.35 and was meant to add support
for host FIFO counters (for VDMA), but is only a wrapper for ->ide_dma_begin()
(even for siimage.c b/c SIIMAGE_VIRTUAL_DMAPIO is undefined).
Moreover it should be possible to add VDMA code directly to ->ide_dma_begin().
[PATCH] ide-tape: warn about soon to be removed OnStream support
I see only pros of removing OnStream support:
- SCSI osst.c driver is actively maintained by Willem Riede <wrlk@riede.org>
- there is no functionality loss (OnStream IDE drives don't support DSC)
- ide-tape.c driver is too ugly & complicated even without OnStream support
- long term benefits (2.7.x plans on unifying storage drivers)
Andrew Morton [Mon, 16 Feb 2004 02:06:16 +0000 (18:06 -0800)]
[PATCH] selinux: Allow non-root processes to read selinuxfs enforce node
From: Stephen Smalley <sds@epoch.ncsc.mil>
This patch changes the mode bits on the selinuxfs enforce node so that
non-root processes can read it. This is necessary to allow non-root
userspace policy enforcers to check the enforcing flag upon a permission
failure as well. A process must still have the appropriate SELinux
permission in order to read the node.
Andrew Morton [Mon, 16 Feb 2004 02:05:39 +0000 (18:05 -0800)]
[PATCH] SELinux: context mount support - SELinux changes.
From: James Morris <jmorris@redhat.com>
This patch implements context mount support within SELinux.
Three new mount options are provided:
context=%s
Label the entire filesystem with the specified security context during
mount and change the labeling behavior to 'mountpoint labeling'. The
/proc/self/attr/fscreate attribute will be ignored for file creation on
the filesystem, although policy-specified transitions will still work
normally. This also sets the aggregate filesystem security context.
fscontext=%s
Set the label of the aggregate filesystem to the specified security
context, so that SELinux policy controls over the filesystem itself may
be reinstated. Only works for filesystems without EA labeling support,
and is not valid if 'context' has been specified.
defcontext=%s
Set the default security context for files created in this filesystem to
the specified security context (as opposed to the current global default).
Only works for filesystems without EA labeling support, and is not
valid if 'context' has been specified.
To set the context or fscontext options, the security policy must specify
appropriate permissions for the filesystem relabelfrom and filesystem
relabelto controls. For the defcontext option, the filesystem relablefrom
and filesystem assoicate controls are invoked.
The security mount options are parsed out and stripped from the normal
mount option data so that no normal filesystems need to be aware of them.
Filesystems with binary mount option data (e.g. NFS, SMBFS, AFS, Coda)
need to be handled as special cases: only NFS is supprted at this stage
per the previous patch.
Andrew Morton [Mon, 16 Feb 2004 02:05:17 +0000 (18:05 -0800)]
[PATCH] SELinux: context mount support - NFS
From: James Morris <jmorris@redhat.com>
This patch modifies the kernel's NFS mount data structure to include SELinux
context mount data. It allows NFS fileystems to be labeled on a
per-mountpoint basis, and should not affect existing versions of userspace
mount.
(A patch to the userspace mount code is available at
http://people.redhat.com/jmorris/selinux/context_mounts/)
Andrew Morton [Mon, 16 Feb 2004 02:04:59 +0000 (18:04 -0800)]
[PATCH] SELinux: context mount support - LSM/FS
From: James Morris <jmorris@redhat.com>
This series of patches adds support for SELinux 'context mounts', which
allows filesystems to be assigned security context information at mount time.
For example, some filesystems do not support extended attributes (e.g. NFS,
vfat), and this feature allows security contexts to be assigned to them on a
per-mountpoint basis. It is also useful when the existing labeling on a
filesystem is untrusted or unwanted for some reason (e.g. removable media),
and needs to be overridden with a safe default.
The first patch below consists of infrastructure changes to the kernel:
- A new LSM hook has been added, sb_copy_data, which allows the security
module to copy security-specific mount data once the superblock has been
setup by the filesystem.
- The sb_kern_mount hook has been modified to take this security data as a
parameter, and would typically be used at that point to configure the
security parameters of the filesystem being mounted.
- Allocation and freeing of the security data has been implemented in the
core fs code as it is cleaner than trying to do it purely via LSM hooks,
and should make maintenance easier. This code will be compiled away if LSM
is not enabled.
This updates the PowerMac-only platinumfb driver to use the new mac-io
device infrastructure. It also switch allocation to the new
framebuffer_alloc/release and fix a couple of bugs.
This adds a limit on how much of the framebuffer is ioremap'ed by
radeonfb, thus enabling it to work with 128Mb VRAM or more on an x86
with 900Mb of lowmem in the linear mapping.
It also adds a significant amount of debug messages and adds a CONFIG
option to enable the debugging output, that should help with diagnosing
new problems. Among others, it dumps the connector info as I understand
them (so far, they give "strange" informations on laptops, I need more
data on more various laptops to see if there's a pattern I can really use
to figure out on which connector the LVDS is)
Regarding the "lid closed at boot", ultimately, we may want to default
to the VGA output in those cases, though I'm not sure what logic to use
here. Maybe we could standardize some way for the platform to provide
this "environment" information to the driver, but i wouldn't rely on it.
More reliably, if we can find out that there is an LVDS output, and
LVDS is disabled, just ignore the flat panel...
We could assume any mobility chip has LVDS, which is true, but that would
still cause a problem for laptops with an additional DVI output (only
Macs so far afaik).
Fix proper detection of the "noaccel" command line argument for
new radeonfb so we can boot without acceleration. Useful when
diagnosing an accel-related problem.
Marcel Holtmann [Sun, 15 Feb 2004 17:47:56 +0000 (18:47 +0100)]
[Bluetooth] Revert reference counting fixes
The RFCOMM TTY code don't leak reference counting, because the TTY layer
will call the ->close() method even if open fails and the reference count
is decreased there.
This makes fbcon ask for notification of events from fbdev to deal with
suspend/resume (stop cursor on suspend, refresh screen on resume).
Could probably do more (like dealing better with the cursor timer), but
this simple implementation works fine enough for now.
This adds some "state" information for power management to fbdev's,
along with a notifier mecanism to inform clients of state changes. It
also "uses" this mecanism in the function fb_set_suspend() which was an
empty placeholder previously, and "shields" various places that access
the HW when state isn't running. (It's best to not call them in the
first place, but the current state of fbcon makes that _very_ difficult)
This updates the aty128fb driver. It adds more PCI IDs, uses the new
framebuffer alloc/release functions, make BIOS PLL data access more
reliable (using ROM whenever possible, with a fallback to RAM BIOS
image), cleanup the Power Management stuff (get rid of PowerMac specific
stuffs, use real PCI ones instead), along with some style cleanups
This removes the broken locking code in the pixmaps, and rewrite the
buffer access function to properly call fb_sync when needed. The old
broken loocking is useless as we are covered by the console semaphore in
all cases hopefully (except if I missed one :)
[PATCH] shield fbdev operations with console semaphore
This fixes the fbdev ioctl's and fbcon cursor management with the
console semaphore, which is the best we can do at this point in 2.6,
thus fixing a bunch of races where we could have, for example, tried to
blit while changing mode, etc..
Independently from the other fbdev updates I'm cooking (some of them
will be in your mailbox rsn), this fixes an error in parameter passing
to a function in rivafb (only used on ppc) that could cause an oops and
definitely causes a warning at compile time.
Roman Zippel [Sat, 14 Feb 2004 03:51:31 +0000 (19:51 -0800)]
[PATCH] fix FB_RADEON_I2C dependency
Thus fixes the weird kconfig message "optimize || ?", it's an old debug
check and is triggered by the unusual dependency. It's not incorrect,
but the solution below is better and it's the same FB_MATROX_I2C already
uses.
This backs out James' sysfs support for fbdev again. It introduces a
big, race for every driver not converted to framebuffer_{alloc,release}
(that is every driver but Ben's new radeonfb).
I've left in framebuffer_{alloc,release} as stubs so drivers can be
converted to it gradually and once all drivers are done it can be
enabled again.
Anton Blanchard [Fri, 13 Feb 2004 23:30:34 +0000 (15:30 -0800)]
[PATCH] cleanup debugger hooks
Theres still more to do here, but at least the ifdef mess is gone. No
more checking for NULL before calling functions, that was playing with
fire. Oh yeah and lots more deletions :)
Clean up the debugger hooks, it was way too easy to screw up.
And we did. And Linus hit it.
- create CONFIG_DEBUGGER so we can enable kernel debugging options but not
have any trace of debugger gunk.
- remove a bunch of xmon prototypes so no one gets the urge to call them
- Use die() instead of panic in a number of places, it gives us much better
debug information.
- Get rid of the ifdef madness
Anton Blanchard [Fri, 13 Feb 2004 23:30:14 +0000 (15:30 -0800)]
[PATCH] various xmon cleanups
Heres a patch I've had for a while, it removes a bunch of debugger code
which is good :) The next patch will sanitise it (and the rest of the
debugger hooks).
Various xmon cleanups
- recover from bad SPR read/write (we get a program check)
- remove some old code (bat and segment register stuff)
- update the help text to match reality
- add a "press ? for help" when xmon first appears to make rusty happy
- protect against flushing bad parts of memory from Milton
- dont print iseries specific stuff on pseries in SPR dump (S)
- add code to dump the segment table or SLB
- remove a number of functions that wouldnt work on LPAR
Anton Blanchard [Fri, 13 Feb 2004 23:29:59 +0000 (15:29 -0800)]
[PATCH] add thread_info to oops output
- Add thread_info to pointer, its a useful piece of information.
- Do the kallsyms lookup on the link register
- Remove extra newline on one call to die()
Anton Blanchard [Fri, 13 Feb 2004 23:29:48 +0000 (15:29 -0800)]
[PATCH] Fix ppc64 build problem
From: Paul Mackerras <paulus@samba.org>
Recent changes in include/linux/*.h meant that likely()
isn't defined here (since we don't set __KERNEL__), and thus
we don't get some prototypes and we can't use do_div. This
fixes the resulting compile errors and warnings.
Remove %L handling from sprintf - we don't need it, and it
meant we needed do_div from asm/div64.h, which gives problems
when __KERNEL__ isn't defined. Also add a prototype for
strlen to kill a warning.