From: Stephen Smalley <sds@epoch.ncsc.mil>

This patch adds an AT_SECURE auxv entry to pass a boolean flag indicating
whether "secure mode" should be enabled (i.e.  sanitize the environment,
initial descriptors, etc) and allows each security module to specify the
flag value via a new hook.

New userland can then simply obey this flag when present rather than
applying other methods of deciding (sample patch for glibc-2.3.2 can be
found at http://www.cs.utah.edu/~sds/glibc-secureexec.patch).

This change enables security modules like SELinux to request secure mode
upon changes to other security attributes (e.g.  capabilities,
roles/domains, etc) in addition to uid/gid changes or even to completely
override the legacy logic.

The legacy decision algorithm is preserved in the default hook functions
for the dummy and capability security modules.

Credit for the idea of adding an AT_SECURE auxv entry goes to Roland
McGrath.

- unused var warning in pnp_add_irq_resource()

- unused var in fd_mcs.c (Adrian Bunk)

- remove dead code in i810_main.c (a u8 cannot exceed 255) (Adrian Bunk)

- don't truncate dma_addr_t's in gdth.c (Jes Sorensen)

- vgastate.c needs vmalloc.h (Geert Uytterhoeven <geert@linux-m68k.org>)

- revert bogus test from rd_open() - it was a 2.4 forward-port, and 2.5
  doesn't need it.  (The gendisks aren't registered, we cannot get there
  anyway).

From: Robert Love <rml@tech9.net>

Basically, the problem is that setscheduler() does not set need_resched
when needed.  There are two basic cases where this is needed:

	- the task is running, but now it is no longer the highest
	  priority task on the rq
	- the task is not running, but now it is the highest
	  priority task on the rq

In either case, we need to set need_resched to invoke the scheduler.

sysrq-T currently displays the same stack trace for every process.

Teach show_stack() to look in the passed task_struct first if the caller did
not pass in a stack address.

From: Mikael Pettersson <mikpe@csd.uu.se>

2.5.73 removed the workaround needed to prevent gcc-2.95.x from
miscompiling spinlocks on UP.  It turns out that some versions of
gcc-2.95 still do have problems with empty structs, so re-introduce
the workaround.

into kroah.com:/home/greg/linux/BK/pci-2.5

Useful for testing hotplug issues with pci drivers.

Added needed release function, now all pci hotplug drivers need to implement
it...

 - Combine pci_alloc_primary_bus_parented into pci_scan_bus_parented.
 - Move the EXPORT_SYMBOL for pci_root_buses up to its definition.
 - Don't EXPORT_SYMBOL pci_scan_bus since it's a static inline.
 - Add the pci_domain_nr() to the sysfs name for this bus.

I noticed we have a couple of redundancies in drivers/pci/Makefile,
have a patch...

into home.osdl.org:/home/torvalds/v2.5/linux

Add missing CONFIG_TC35805 entry to Kconfig.
Update CONFIG_NET_SB1250_MAC Kconfig entry.
Minor cosmetic updates to gt96100eth.

Submitted by Ralf Baechle <ralf@linux-mips.org>

[ Registers of the world, unite! ]

This makes the IO-APIC data structures use unions, so that we can
cleanly access them both as flat "raw" values, and as the bitmap
sub-entries.

into home.transmeta.com:/home/torvalds/v2.5/linux

This error is handled in the signal delivery code and should never be
returned from a syscall unless a signal is pending.  Grepping seems to
indicate that that is in fact the case (but not for ERESTARTSYS, but
that is another problem).

Ignore earlier patch -- this one locks and free's as appropriate.
Tested on 2.5.72 with SMP.

Of course, it begs the question why have two (now three) versions of drivers for
the same hardware...

dev_ioctl already checks capable(CAP_NET_ADMIN), so no need to do so in
drivers.

net_device is no longer allocated as part of the driver's private structure,
instead it's allocated via alloc_netdev. compile tested only since no hardware
against 2.5.73-bk


-daniel

===== smc91c92_cs.c 1.18 vs edited =====

net_device is no longer allocated as part of the driver's private structure,
instead it's allocated via alloc_netdev. compile tested only since no hardware
against 2.5.73-bk


-daniel

===== nmclan_cs.c 1.14 vs edited =====

net_device is no longer allocated as part of the driver's private structure,
instead it's allocated via alloc_netdev. compile tested only since no hardware
against 2.5.73-bk


-daniel

===== fmvj18x_cs.c 1.21 vs edited =====

net_device is no longer allocated as part of the driver's private structure,
instead it's allocated via alloc_netdev. compile tested only since no hardware
against 2.5.73-bk


-daniel

===== drivers/net/pcmcia/3c589_cs.c 1.17 vs edited =====

net_device is no longer allocated as part of the driver's private structure,
instead it's allocated via alloc_netdev. compile tested only since no hardware
against 2.5.73-bk


-daniel


===== drivers/net/pcmcia/3c574_cs.c 1.17 vs edited =====

into samba.org:/stuff/paulus/kernel/for-linus-ppc

Recently there has been a rash of Unexpected IO APIC reports on the
linux-smp mailing list.  Most of the most recent ones are due to some
newer Intel chipsets (865, 875).

The IO APIC Version register doesn't indicate the differences in these
IO APICs.

I have an patch that addresses these chipsets.  It has been tested by a
few people with good results and has been blessed by Maciej Rozycki.

Other than conditionally decoding IO APIC registers 2 and 3, we could
alternately ignore them since Linux doesn't use the values for anything
other than printing them.

This patch ignores IO APIC register 2 if it's the same value as IO APIC
register 1.  It also reads IO APIC register 3 if the IO APIC version is
>= 0x20, but some chipsets don't support this register, so it is also
ignored if its value if the same as IO APIC register 1 or 2.

Another possible(?) alternative is to read the PID/VID of the device to
determine which registers it supports.  However, PCI devices have not
been scanned at this point in init, so it would require scanning PCI
config space directly and I don't yet see the point of doing that.

Oh, and the UNEXPECTED_IO_APIC() function doesn't print anything in
2.5.current and I didn't change that.

This does the following:

 - IV value is current 512-byte sector relative to start of loop
   container file.  This is what all cryptoloop people have done, if I
   am not mistaken.  Andi or others - if you can demonstrate the need
   for a more flexible setup an additional ioctl field may be needed.  I
   hope we can do without.

 - made some things static

 - made lo_offset a loff_t

 - added lo_sizelimit

   If one wanted a (crypto)loop somewhere inside a container file, the
   old code allowed a starting offset, but no size, so that the
   cryptoloop always extended to the end of the container file.  This
   field allows one to select an arbitrary interval.  Note that this
   changes struct loop_info64.

 - improve error handling of loop_init()

 - removed the unused typedef transfer_proc_t.

 - added a define for LO_CRYPT_CRYPTOAPI