I noticed that the class_register() function in drivers/base/class.c
always returns 0 and thus will never fail.  Patch below inserts simple
error checking to return any errors if they occur.  Feedback welcome.
Thanks,

Patch adds sysfs simple class support for netlink character device
(Major 36).  Feedback appreciated.  Thanks,

The only spot that seems to care about class_simple_device_add possibly
failing, but it gets the wrong error test.

Error path doesn't class_simple_destroy.

Doesn't catch error on class_simple_add, and existing error return paths
forget to class_simple_destroy.

Error condition isn't caught on class_simple_create, and
parport_register_driver failure doesn't do proper cleanup.

* Hanna Linder (hannal@us.ibm.com) wrote:
> +		ppp_class = class_simple_create(THIS_MODULE, "ppp");
> +		class_simple_device_add(ppp_class, MKDEV(PPP_MAJOR, 0), NULL, "ppp");

What happens if that class_simple_create() fails?  Actually,
class_simple_device_add could fail too, but doesn't seem anybody is
checking for that.

>  		err = devfs_mk_cdev(MKDEV(PPP_MAJOR, 0),
>  				S_IFCHR|S_IRUSR|S_IWUSR, "ppp");
> -		if (err)
> +		if (err) {
>  			unregister_chrdev(PPP_MAJOR, "ppp");
> +			class_simple_device_remove(MKDEV(PPP_MAJOR,0));
> +		}

need to destroy the class on error path to avoid leak.

> @@ -2540,6 +2547,7 @@ static void __exit ppp_cleanup(void)
>  	if (unregister_chrdev(PPP_MAJOR, "ppp") != 0)
>  		printk(KERN_ERR "PPP: failed to unregister PPP device\n");
>  	devfs_remove("ppp");
> +	class_simple_device_remove(MKDEV(PPP_MAJOR, 0));

ditto.  this will leak and would cause oops on reload of module.

something like below.

This got fixed in 2.4, but somehow got missed in 2.6.

This is a cleaner fix for the previous bogon fix.

- Move free_block prototype, and ac_entry and ac_data functions up in file.

- Use list_for_each_entry in cpuup_callback.

- Remove unneccessary g_cpucache_up in cpuup_callback.

- Make reap_timer_func take CPU number as data, and check if that is
  offline before rescheduing (noop without CONFIG_HOTPLUG_CPU).

Levent Serinol <levent.serinol@mynet.com> found that the hotplug cpu
patch broke Sparc64.  I introduced a num_possible_cpus(), which
Sparc64 already has.  Remove the Sparc64 one.

I also removed Sparc64's cpu_online() macro: it's in linux/cpumask.h
already.

Note that without CONFIG_HOTPLUG_CPU, online cpus == possible cpus, so
substitutions are a noop.

- Changes show_stat to print out stats for every possible cpu, not
  just online CPUs.

- Allocate mem in stat_open on possible, not online_cpus.

- Add conventient macros to cpu.h: especially cpu_is_offline() for
  testing if a cpu is still online.

- Add a num_possible_cpus() similar to num_online_cpus(), and define
  cpu_possible_mask for UP.

- Allow printk on down cpus once system is running.

- Mask cpumask with possible, not online cpus, for sys_getaffinity().

Extracts core of drain_pages() for hotcpu use.  Trivial.

Hotplug CPU needs to drain pages on a downed CPU (usually it's the
current cpu).  Introduce "__drain_pages", make the CPU an argument,
and expose it if CONFIG_HOTPLUG_CPU as well as CONFIG_PM.

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

into redhat.com:/spare/repo/via-crypto-2.5

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

Promise driver uses a custom error handling function, so we need
the fix that was applied to the libata core:  the SCSI error
handling thread requires that we complete commands using a special
completion function, since the normal one doesn't work inside
the error handling thread.

The following patch is a very crude one to at least not make sata block
suspend-to-ram entirely. Probably you want more powermanagement handling as
well... but it's a start

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

The pcnet32 driver will hang after a few frames (<30) with the 79C971
(and probably the 79C972 though I don't have the hardware to prove it).
By interrupting slightly more frequently the hang will not occur.

>>>>> "Pawel" == Pawel Sokolowski <falcon@muflon.linux.pl> writes:

Pawel> This machine has RAM BIOS booted from floppy. I ran it and EISA
Pawel> configure utility to check this once more. Card is enabled and not
Pawel> locked. I added eisa_bus.enable_dev=2 parameter but it didn't help much.
Pawel> I'm getting:

Pawel> EISA: Probing bus 0 at eisa0
Pawel> EISA: Mainboard HWPC061 detected.
Pawel> EISA: slot 2 : HWP1940 detected (forced enabled).
Pawel> EISA: Detected 1 card.

Pawel> I added this final entry you mailed but nothing changed. Still - module
Pawel> loads and unloads cleanly and without any warnings on 2.6.4-rc1. But
Pawel> does nothing - not a single line in logs/dmesg after it's loaded. Card
Pawel> does not work after modprobe, I can't get interface up.

Ok, found it.

It really looks like the new EISA probing code in hp100 never got
tested, since a precious offset has disappeared during the rewriting
process.

Please note that you still need to enable the device by hand, since
your BIOS (or maybe the EISA CFG file, since I'm seeing the exact same
problem on a Compaq machine here) doesn't properly enable the card.

Here is what I'm getting on my test system :

EISA: Probing bus 0 at 0000:00:0f.0
EISA: Mainboard CPQ0541 detected.
EISA: slot 1 : DEC4250 detected.
EISA: slot 2 : UNB0048 detected.
EISA: slot 3 : HWP1940 detected (forced enabled).
hp100: Using (slow) programmed i/o mode.
hp100: at 0x3c38, IRQ 3, EISA bus, 128k SRAM (rx/tx 75%).
hp100: Adapter is attached to 10Mb/s network (10baseT).
EISA: slot 4 : NVL0701 detected.

Now we've moved the bogolock code out to stop_machine.c and
generalized it a little, use it in module.c and delete the duplicate
code there.

The "bogolock" code was introduced in module.c, as a way of freezing
the machine when we wanted to remove a module.  This patch moves it
out to stop_machine.c and stop_machine.h.

Since the code changes affinity and proirity, it's impolite to hijack
the current context, so we use a kthread.  This means we have to pass
the function rather than implement "stop_machine()" and
"restart_machine()".

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

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

into kernel.bkbits.net:/home/davem/sparc-2.6

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

into austin.ibm.com:/shaggy/bk/jfs-2.5

Submitted by Christoph Hellwig

Committing a transaction creating a file required insuring that the
inode stayed in cache until the journal was written to.  i_count was
being incremented until the transaction was complete.

However, incrementing i_count caused fcntl(S_SETLEASE) to fail.  I
reworked the transaction code so that the inode does not have to
stay in-memory while the transaction is being committed.

Thanks to Steve French for figuring out why setlease was failing.

When no iocharset is specified, the default action is to trivially
map each byte into the low order of the 16-bit unicode character.
If an existing name exists that has a non-zero high order byte, the
file will be inaccessible without remounting with iocharset set to
a charset that supports the character.

This patch will cause a warning to be issued to the syslog (no more
than five times) suggesting that the volume be mounted with
iocharset=utf8 in order to access the file.

From: Valdis.Kletnieks@vt.edu

The send_IPI_self() in smp.c was fixed but the one in io_apic.c was not.

From: Hugh Dickins <hugh@veritas.com>

Fixes bugzilla #2219

fork's dup_mmap leaves child mm_rb as copied from parent mm while doing all
the copy_page_ranges, and then calls build_mmap_rb without holding
page_table_lock.

try_to_unmap_one's find_vma (holding page_table_lock not mmap_sem) coming
on another cpu may cause mm mayhem.  It may leave the child's mmap_cache
pointing to a vma of the parent mm.

When the parent exits and the child faults, quite what happens rather
depends on what junk then inhabits vm_page_prot, which gets set in the page
table, with page_add_rmap adding the ptep, but junk pte likely to fail the
tests for page_remove_rmap.

Eventually the child exits, the page table is freed and try_to_unmap_one
oopses on null ptep_to_mm (but in a kernel with rss limiting, usually
page_referenced hits the null ptep_to_mm first).

This took me days and days to unravel!  Big thanks to Matthieu for
reporting it with a good test case.

It provides a best-effort, minimum-latency "get all the writeout
underway" function.