The function crypto_mod_put first frees the algorithm and then drops
the reference to its module.  Unfortunately we read the module pointer
which after freeing the algorithm and that pointer sits inside the
object that we just freed.

So this patch reads the module pointer out before we free the object.

Thanks to Luca Tettamanti for reporting this.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

When the PST tables are broken, powernow-k7 uses ACPI's processor_perflib to
deduce the available frequency multipliers from the _PSS tables.

Upon frequency change, processor_perflib performs some verification on the
frequency (checks that it's within allowable bounds).

powernow-k7 deals with absolute frequencies in KHz, whereas perflib only
deals with MHz values. When performing the above verification, perflib
multiplies the MHz values by 1000 to obtain the KHz value.

We then end up with situations like the following:
 - powernow-k7 multiplies the multiplier by the FSB, and obtains a value
   such as 1266768 KHz
 - perflib belives the same state has frequency of 1266 MHz
 - acpi_processor_ppc_notifier calls cpufreq_verify_within_limits to verify
   that 1266768 is in the allowable range of 0 to 1266000 (i.e. 1266 * 1000)
 - it's not, so that frequency is rejected
 - the maximum CPU frequency is not reachable

This patch solves the problem by rounding up the MHz values stored in perflib's
tables. Additionally it corrects a broken URL.

It also fixes http://bugzilla.kernel.org/show_bug.cgi?id=8255 although this
case is a bit different: the frequencies in the _PSS tables are wildly wrong,
but we get better results if we force ACPI to respect the fsb * multiplier
calculations (even though it seems that the multiplier values aren't entirely
correct either).

Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

Mark Langsdorf points out that the correct define for this
revision bump is 0x80000.  Also to save us having to keep
renaming the #define, give it a more meaningful name.

Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

Reported-by: Calvin Dodge <caldodge@gmail.com>
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

When the helper module is removed for a master connection that has a
fulfilled expectation, but has already timed out and got removed from
the hash tables, nf_conntrack_helper_unregister can't find the master
connection to unset the helper, causing a use-after-free when the
expected connection is destroyed and releases the last reference to
the master.

The helper destroy callback was introduced for the PPtP helper to clean
up expectations and expected connections when the master connection
times out, but doing this from destroy_conntrack only works for
unfulfilled expectations since expected connections hold a reference
to the master, preventing its destruction. Move the destroy callback to
the timeout function, which fixes both problems.

Reported/tested by Gabor Burjan <buga@buvoshetes.hu>.

Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

It's possible for a journal I/O request to be added to the log_redrive
queue and the jfsIO thread to be awakened after the thread releases
log_redrive_lock but before it sets its state to TASK_INTERRUPTIBLE.

The jfsIO thread should set the state before giving up the spinlock, so
the waking thread will really wake it.

Signed-off-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

USB HID: hiddev - fix race between hiddev_send_event() and hiddev_release()

There is a small race window in which hiddev_release() could corrupt the
list that is being processed for new event in hiddev_send_event().
Synchronize the operations over this list.

Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

If the device fails during module startup for some reason like unsupported chip
version then the driver would crash dereferencing a null pointer, on shutdown
or suspend/resume.

Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

If device fails during module startup for some reason (like unsupported chip
version) then driver would crash dereferencing a null pointer, on shutdown
or suspend/resume.

Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>