From: Petr Vandrovec <vandrove@vc.cvut.cz>


Arjan van de Ven pointed out to me there are no checks on name component
lengths in ncpfs, so potentially 4KB regions could be allocated on stack,
leading to the user controlled stack overflow.

It was using variable-sized arrays, so this snuck past the static
stack-usage checking tools.

As NCP is limited to 255 bytes on components, we can simple limit these
local variables to 256 bytes, and after this stack usage looks more
acceptable.  Length checking occurs inside ncp_vol2io, during
iocharset->codepage conversion.

As a side effect support for multibyte codepages now works as it should,
instead of returning -EINVAL whenever filename in 'codepage' encoding was
longer than in 'iocharset'.

Other part fixes typo where atime change updated ctime and not atime field.

Fat chance, but we should try.

From: Anton Blanchard <anton@samba.org>

Some architectures use cpu_vm_mask to optimise TLB flushes.  On ppc64 we
are now using a common flush infrastructure that handles both userspace and
kernelspace (vmalloc) pages.  In order to avoid triggering this
optimisation we need to mark the init mm as having scheduled on all cpus.

Things currently work by luck (we check for the cpu only having run on the
local cpu, and the field is initialised to 0), but it would be safer to
initialise it CPU_MASK_ALL.

This driver is trying an order-9 allocation and if that fails, order 8, etc.
Crufty, but we do expect failures, so suppress the warnings.

From: William Lee Irwin III <wli@holomorphy.com>

->valid_addr_bitmap is initialized nowhere.  Any kern_addr_valid() testing
it returns 0 unconditionally.

This patch converts kern_addr_valid() implementations using it to return 0
as per the above and removes it from structures and zone initialization.
Untested (not even compiletested), though a similar patch also nuking
d_validate() was in use in -wli for several months.

From: Nigel Cunningham <ncunningham@users.sourceforge.net>

Change the console code to support up to 256 (maybe 255?) columns.

From: John McKell <mckellj@iomega.com>

This 2.6.1 patch works by setting gendisk->policy to the correct value
during initialization as the various drivers decide whether or not the disk
is writeable.  This patch persuades "blockdev --getro ..." to correctly
report the read-only state of a newly inserted disk.  This patch applies to
sr.c, sd.c and ide-floppy.c.  ide-cd.c already has this functionality built
into it.

Using an Iomega Zip drive as the test case...

Without the patch, I always see:

$ sudo blockdev --getro /dev/sda
0
$

That's only correct for writeable disks though.  Only when the patch
is applied do I see a write-protected disk described correctly:

$ sudo blockdev --getro /dev/sda
1
$

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>

This patch has been in my tree for monthes and Paulus agrees that it should
be made generic, so here we go, PPC32 is now proud to run at 1000HZ :)

From: Neil Brown <neilb@cse.unsw.edu.au>

In fs/partitions/check.c  there are two pieces of code that add a
partition number to a block-device name:

  - the 'disk_name' function
  - a snprintf in add_partitions.

'disk_name' inserts a 'p' before the partition number if the device
name ends with a digit.  The snprintf in add_partitions doesn't.

This patch rectifies this anomoly so that names in sysfs can be
parsed more reliably.


This has been extensively discussed.  It will probably break the external
`iostat' tool.  But only for disks whose name ends in a digit, which appears
to be only DAC960.

From: Jun Sun <jsun@mvista.com>

'console_driver' is defined only when CONFIG_VT_CONSOLE is set.  However it
is used by vty_init() which is outside the scope of CONFIG_VT_CONSOLE.

From: Andrea Arcangeli <andrea@suse.de>

Return the proper error code

From: Anton Blanchard <anton@samba.org>

Remove some duplicated hugetlbfs code.

From: Anton Blanchard <anton@samba.org>

Update ctime/mtime in libfs where appropriate.

From: Anton Blanchard <anton@samba.org>

hugetlbfs is doing strange things with directory sizes.  Al says there is no
semantics for reported size of directories so we can remove this code.

From: Anton Blanchard <anton@samba.org>

Paul wrote a patch to use some of the rmap infrastructure to flush TLB
entries on ppc64.  When testing it we found a problem in vmalloc where it
sets up the pte -> address mapping incorrectly.  We clear the top bits of
the address but then forget to pass in the full address to
pte_alloc_kernel.  The end result is the address in page->index is
truncated.

I fixed it in a similar way to how zeromap_pmd_range etc does it.  I'm
guessing no one uses the rmap hooks on vmalloc pages yet, so havent seen
this problem.

From: Pavel Machek <pavel@ucw.cz>

software_suspend() can fail for quite a lot of reasons (for example not
enough swapspace).  However current interface returned void, so you could
not propagate error back to userland.  This fixes it.  Plus
__read_suspend_image() is only done during init time, so we might as well
mark it __init.

From: Pavel Machek <pavel@ucw.cz>

This kills unused part of struct and fixes spelling.

It also fixes codingstyle a bit, converts "can not happen" panic into BUG_ON
(fill_suspend_header() allocates no memory so panic is meaningless) and adds
check for sizeof (struct link) [if that is not PAGE_SIZE, we have *bad*
problem, better check early].

From: Pavel Machek <pavel@ucw.cz>

To correctly stop all DMA activity, make the boot kernel put all devices
into suspend state before entering the resume kernel image.

From: Matt Domsch <Matt_Domsch@dell.com>


There are 4 bytes in the MSDOS master boot record, at offset 0x1b8,
which may contain a per-system-unique signature.  By first writing a unique
signature to each disk in the system, then rebooting, and then reading the
MBR to get the signature for the boot disk (int13 dev 80h), userspace may
use it to compare against disks it knows as named /dev/[hs]d[a-z], and thus
determine which disk is the BIOS boot disk, thus where the /boot, / and
boot loaders should be placed.

This is useful in the case where the BIOS is not EDD3.0 compliant, thus
doesn't provide the PCI bus/dev/fn and IDE/SCSI location of the boot disk,
yet you need to know which disk is the boot disk.  It's most useful in OS
installers.

This patch retrieves the signature from the disk in setup.S, stores it in a
space reserved in the empty_zero_page, copies it somewhere safe in setup.c,
and exports it via /sys/firmware/edd/int13_disk80/mbr_signature in edd.c.
Code is covered under CONFIG_EDD=[ym].

From: Nikita Danilov <Nikita@Namesys.COM>

Replace all existing usages of __attribute__((const)) with
__attribute_const__.

From: Sam Ravnborg <sam@ravnborg.org>

'enable' is not documented in Documentation/kbuild/kconfig-language.txt So
remove usage in the only Kconfig file in the kernel tree where it was used.

From: Sam Ravnborg <sam@ravnborg.org>

- Use keyword select in relevant warning

- Include more information in warnings related to select

- Move part of error-checking to a sepearate function

- Added helpers used when issuing warnings - makes code simpler

- Wrapped most edited lines at column 80

From: jbarnes@sgi.com (Jesse Barnes)

Here's the patch to add the new _relaxed variants for PIO read accesses.
It's been ack'd by gregkh and Grant Grundler, and I think it's ready to
go.

PCI ordering rules also guarantee that PIO read responses arrive after any
outstanding DMA writes on that bus, since for some devices the result of a
readb() call may signal to the driver that a DMA transaction is complete.  In
many cases, however, the driver may want to indicate that the next readb()
call has no relation to any previous DMA writes performed by the device.  The
driver can use the readb_relaxed() for these cases, although only some
platforms will honor the relaxed semantics.

From: Anton Blanchard <anton@samba.org>

I made a few changes, basically the burst parameter is now in units of
messages, makes much more sense than the old net ratelimit one.

I also screwed up adding a sysctl_jiffies strategy for the burst parameter.

From: "Randy.Dunlap" <rddunlap@osdl.org>
      Eugene TEO <eugeneteo@eugeneteo.net>

From: Joe Korty <joe.korty@ccur.com>

1) the version in 2.6.1 is broken, doesn't work on 64bit big endian
   machines at all.  This needed fixing.  I thought it best to fix by
   rewriting the printer/parser with an algorithm that is naturally endian &
   sizeof(long) resistant.

2) I wanted all digits to print, eg, 0000ffff,00000004 not ffff,4.

3) I wanted exactly NR_CPUS bits to print (or whatever the bitmap size is
   in bits, and not have what is displayed rounded up to the nearest full
   byte, as the current version did.

4) The bitmap printer and parser should be part of bitmap.[ch] with syntax
   and semantics to match.  The original lib/mask.c versions did not
   recognize this commonality.

From: Andi Kleen <ak@muc.de>

Fix all the x86-64 warnings with gcc 3.5 and make it compile again.

	++nmi_count(cpu);

arch/i386/kernel/traps.c: In function `do_nmi':
arch/i386/kernel/traps.c:552: error: invalid lvalue in increment

and

include/linux/netdevice.h: In function `__netif_rx_schedule':
include/linux/netdevice.h:818: error: invalid lvalue in assignment
include/linux/netdevice.h: In function `netif_rx_reschedule':
include/linux/netdevice.h:842: error: invalid lvalue in assignment


This fix will probably reintroduce unused variable warnings...

drivers/video/vgastate.c: In function `save_vga':
drivers/video/vgastate.c:368: error: invalid lvalue in assignment

drivers/video/cfbimgblt.c: In function `color_imageblit':
drivers/video/cfbimgblt.c:140: error: invalid lvalue in assignment
drivers/video/cfbimgblt.c: In function `slow_imageblit':
drivers/video/cfbimgblt.c:206: error: invalid lvalue in assignment

drivers/video/riva/fbdev.c: In function `rivafb_load_cursor_image':
drivers/video/riva/fbdev.c:498: error: invalid lvalue in increment
drivers/video/riva/fbdev.c:499: error: invalid lvalue in increment
drivers/video/riva/fbdev.c: In function `rivafb_imageblit':
drivers/video/riva/fbdev.c:1440: error: invalid lvalue in increment
drivers/video/riva/fbdev.c:1449: error: invalid lvalue in increment

drivers/video/console/fbcon.c: In function `fbcon_set_font':
drivers/video/console/fbcon.c:2000: error: invalid lvalue in decrement

drivers/scsi/gdth.c:267:10: warning: extra tokens at end of #ident directive

drivers/scsi/atp870u.c: In function `send_s870':                                drivers/scsi/atp870u.c:706: error: invalid lvalue in assignment
drivers/scsi/atp870u.c:707: error: invalid lvalue in assignment
drivers/scsi/atp870u.c:708: error: invalid lvalue in assignment
drivers/scsi/atp870u.c:713: error: invalid lvalue in assignment                 drivers/scsi/atp870u.c:714: error: invalid lvalue in assignment
drivers/scsi/atp870u.c:715: error: invalid lvalue in assignment
drivers/scsi/atp870u.c:718: error: invalid lvalue in assignment
drivers/scsi/atp870u.c:727: error: invalid lvalue in assignment                 drivers/scsi/atp870u.c:728: error: invalid lvalue in assignment
drivers/scsi/atp870u.c:729: error: invalid lvalue in assignment
drivers/scsi/atp870u.c:734: error: invalid lvalue in assignment                 drivers/scsi/atp870u.c:735: error: invalid lvalue in assignment
drivers/scsi/atp870u.c:736: error: invalid lvalue in assignment

drivers/scsi/advansys.c: In function `advansys_reset':
drivers/scsi/advansys.c:6022: error: invalid lvalue in assignment
drivers/scsi/advansys.c:6045: error: invalid lvalue in assignment
drivers/scsi/advansys.c: In function `advansys_interrupt':
drivers/scsi/advansys.c:6314: error: invalid lvalue in assignment
drivers/scsi/advansys.c: In function `asc_scsi_done_list':
drivers/scsi/advansys.c:6386: error: invalid lvalue in assignment
drivers/scsi/advansys.c: In function `asc_enqueue':
drivers/scsi/advansys.c:7437: error: invalid lvalue in assignment
drivers/scsi/advansys.c:7445: error: invalid lvalue in assignment
drivers/scsi/advansys.c:7448: error: invalid lvalue in assignment
drivers/scsi/advansys.c: In function `asc_dequeue_list':
drivers/scsi/advansys.c:7569: error: invalid lvalue in assignment
drivers/scsi/advansys.c: In function `asc_rmqueue':
drivers/scsi/advansys.c:7647: error: invalid lvalue in assignment
drivers/scsi/advansys.c:7648: error: invalid lvalue in assignment

In file included from drivers/scsi/53c700.c:140:
drivers/scsi/53c700.h: In function `NCR_700_set_SXFER':
drivers/scsi/53c700.h:106: error: invalid lvalue in assignment
drivers/scsi/53c700.h:107: error: invalid lvalue in assignment
drivers/scsi/53c700.h: In function `NCR_700_set_depth':
drivers/scsi/53c700.h:116: error: invalid lvalue in assignment
drivers/scsi/53c700.h:117: error: invalid lvalue in assignment
drivers/scsi/53c700.h: In function `NCR_700_set_flag':
drivers/scsi/53c700.h:137: error: invalid lvalue in assignment
drivers/scsi/53c700.h: In function `NCR_700_clear_flag':
drivers/scsi/53c700.h:142: error: invalid lvalue in assignment

drivers/pnp/pnpbios/core.c:438: warning: use of cast expressions as lvalues is deprecated

drivers/media/video/mxb.c: In function `mxb_probe':
drivers/media/video/mxb.c:264: error: invalid lvalue in assignment

include/pcmcia/mem_op.h: In function `copy_from_pc':
include/pcmcia/mem_op.h:85: error: invalid lvalue in assignment
include/pcmcia/mem_op.h:85: error: invalid lvalue in assignment
include/pcmcia/mem_op.h: In function `copy_to_pc':
include/pcmcia/mem_op.h:97: error: invalid lvalue in assignment
include/pcmcia/mem_op.h:97: error: invalid lvalue in assignment
include/pcmcia/mem_op.h: In function `copy_pc_to_user':
include/pcmcia/mem_op.h:109: error: invalid lvalue in assignment
include/pcmcia/mem_op.h:109: error: invalid lvalue in assignment
include/pcmcia/mem_op.h: In function `copy_user_to_pc':
include/pcmcia/mem_op.h:124: error: invalid lvalue in assignment
include/pcmcia/mem_op.h:124: error: invalid lvalue in assignment

drivers/media/dvb/frontends/ves1820.c: In function `ves1820_setup_reg0':
drivers/media/dvb/frontends/ves1820.c:244: error: invalid lvalue in assignment
drivers/media/dvb/frontends/ves1820.c:244: error: invalid lvalue in assignment
drivers/media/dvb/frontends/ves1820.c: In function `ves1820_attach':
drivers/media/dvb/frontends/ves1820.c:541: error: invalid lvalue in assignment
drivers/media/dvb/frontends/ves1820.c:541: error: invalid lvalue in assignment
drivers/media/dvb/frontends/ves1820.c:544: error: invalid lvalue in assignment
drivers/media/dvb/frontends/ves1820.c:544: error: invalid lvalue in assignment
drivers/media/dvb/frontends/ves1820.c:545: error: invalid lvalue in assignment
drivers/media/dvb/frontends/ves1820.c:545: error: invalid lvalue in assignment
drivers/media/dvb/frontends/ves1820.c:546: error: invalid lvalue in assignment
drivers/media/dvb/frontends/ves1820.c:546: error: invalid lvalue in assignment
drivers/media/dvb/frontends/ves1820.c:547: error: invalid lvalue in assignment
drivers/media/dvb/frontends/ves1820.c:547: error: invalid lvalue in assignment