If there is an architecture-specific random number generator (such as
RDRAND for Intel architectures), use it to initialize /dev/random's
entropy stores.  Even in the worst case, if RDRAND is something like
AES(NSA_KEY, counter++), it won't hurt, and it will definitely help
against any other adversaries.
Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
Link: http://lkml.kernel.org/r/1324589281-31931-1-git-send-email-tytso@mit.eduSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>

We still don't use rdrand in /dev/random, which just seems stupid. We
accept the *cycle*counter* as a random input, but we don't accept
rdrand? That's just broken.

Sure, people can do things in user space (write to /dev/random, use
rdrand in addition to /dev/random themselves etc etc), but that
*still* seems to be a particularly stupid reason for saying "we
shouldn't bother to try to do better in /dev/random".

And even if somebody really doesn't trust rdrand as a source of random
bytes, it seems singularly stupid to trust the cycle counter *more*.

So I'd suggest the attached patch. I'm not going to even bother
arguing that we should add more bits to the entropy estimate, because
that's not the point - I don't care if /dev/random fills up slowly or
not, I think it's just stupid to not use the bits we can get from
rdrand and mix them into the strong randomness pool.

Link: http://lkml.kernel.org/r/CA%2B55aFwn59N1=m651QAyTy-1gO1noGbK18zwKDwvwqnravA84A@mail.gmail.comAcked-by: N"David S. Miller" <davem@davemloft.net>
Acked-by: N"Theodore Ts'o" <tytso@mit.edu>
Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
Cc: Matt Mackall <mpm@selenic.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>

If the BMC gets reset, it will return 0x80 response errors.

In less than a week
# grep "Error 80 on cmd 22" /var/log/kernel |wc -l
378681

In this case, it is probably a good idea to restore the IPMI settings.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Tested-by: NArkadiusz Miśkiewicz <a.miskiewicz@gmail.com>
Reported-by: NArkadiusz Miśkiewicz <a.miskiewicz@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

If there is an architecture-specific random number generator we use it
to acquire randomness one "long" at a time.  We should put these random
words into consecutive words in the result buffer - not just overwrite
the first word again and again.
Signed-off-by: NTony Luck <tony.luck@intel.com>
Acked-by: NH. Peter Anvin <hpa@zytor.com>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

If there is an architecture-specific random number generator we use
it to acquire randomness one "long" at a time. We should put these
random words into consecutive words in the result buffer - not just
overwrite the first word again and again.
Signed-off-by: NTony Luck <tony.luck@intel.com>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/4ec4061010261a4cb0@agluck-desktop.sc.intel.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>

Kernels with no iommu support cannot ever need the Ironlake
work-around, so never enable it in that case.

Might be better to completely remove the work-around from the kernel
in this case?
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>

The semi-colon is a typo here and it makes the if statement
unconditional.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NRichard Weinberger <richard@nod.at>

* kill duplicates with drivers/char/Kconfig
* take watchdog one into drivers/watchdog/Kconfig
* take mmapper to arch/um/Kconfig.um
* rename Kconfig.char menu to "UML Character Devices"
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NRichard Weinberger <richard@nod.at>

On s390 I have seen some random

"Warning: unable to open an initial console"

boot failure. Turns out that tty_open fails, because the
hvc_alloc was not yet done. In former times this could not happen,
since the probe function automatically called hvc_alloc. With newer
versions (multiport) some host<->guest interaction is required
before hvc_alloc is called. This might be too late, especially if
an initramfs is involved. Lets use a completion if we have
multiport and an early console.

[Amit:
  * Use NULL instead of 0 for pointer comparison
  * Rename 'port_added' to 'early_console_added'
  * Re-format, re-word commit message
  * Rebase patch on top of current queue]
Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Acked-by: NChrstian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

This commit adds port-specific stats for the number of bytes received,
sent and discarded.  They're exposed via the debugfs interface.  This
data can be used to check for data loss bugs (or disprove such claims).
It can also be used for accounting, if there's such a need.

The stats remain valid throughout the lifetime of the port.  Unplugging
a port will reset the stats.  The numbers are not reset across port
opens/closes.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

discard_port_data() used virtqueue_get_buf() directly instead of using
get_inbuf().  Fix this, so that we get accounting for all received
bytes.  This also simplifies the code a lot.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

'ret' is a misnomer in discard_port_data() since we don't return the
value.  Rename it to 'err'.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Instead of pulling in a buffer from the vq each time it's called,
get_inbuf() now checks if the current active buffer, in port->inbuf is
valid.  If it is, just returns a pointer to it.  This ends up
simplifying a lot of code calling get_inbuf() since the check for
port->inbuf being valid was done by all the callers.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

get_inbuf() returns void *.  There's no reason to return void pointers
instead of the correct struct port_buffer *.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Get ready to support suspend/resume by using the freezable calls so that
blocking read/write syscalls are handled properly across suspend/resume.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

We don't allow port name changes dynamically for a port.  So any
requests by the host to change the name are ignored.

Before this patch, if the hypervisor sent a port name while we had one
set already, we would leak memory equivalent to the size of the old
name.

This scenario wasn't expected so far, but with the suspend-resume
support, we'll send the VIRTIO_CONSOLE_PORT_READY message after restore,
which can get us into this situation.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Convert spaces to tabs and fix indentation for an if statement split
into multiple lines.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

This patch modifies virtio-console to use virtio_config_val() instead
of a 'if(virtio_has_feature()) vdev->config->get()' construct to retrieve
optional values from the config space.

Cc: Amit Shah <amit.shah@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: virtualization@lists.linux-foundation.org
Signed-off-by: NSasha Levin <levinsasha928@gmail.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

drivers/char/ramoops.c: In function 'ramoops_init':
drivers/char/ramoops.c:221: error: implicit declaration of function 'IS_ERR'
drivers/char/ramoops.c:222: error: implicit declaration of function 'PTR_ERR'
make[3]: *** [drivers/char/ramoops.o] Error 1
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

They will need it called out explicitly in the near future due
to a module.h usage cleanup that removes its implicit presence
everywhere.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

A pending cleanup will mean that module.h won't be implicitly
everywhere anymore.  Make sure the modular drivers in char are
actually calling out for <module.h> explicitly in advance.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

Kernels with no iommu support cannot ever need the Ironlake
work-around, so never enable it in that case.

Might be better to completely remove the work-around from the kernel
in this case?
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>

The semi-colon is a typo here and it makes the if statement
unconditional.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

Idle the GPU before doing any unmaps. We know if VT-d is in use through
an exported variable from iommu code.

This should avoid a known HW issue.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NKeith Packard <keithp@keithp.com>

For the IP block on 9g45/9g46/9m10/9m11.
Signed-off-by: NPeter Korsgaard <jacmet@sunsite.dk>
Reviewed-by: NJamie Iles <jamie@jamieiles.com>
Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>

Just convert all the files that have an nmi handler to the new routines.
Most of it is straight forward conversion.  A couple of places needed some
tweaking like kgdb which separates the debug notifier from the nmi handler
and mce removes a call to notify_die.

[Thanks to Ying for finding out the history behind that mce call

https://lkml.org/lkml/2010/5/27/114

And Boris responding that he would like to remove that call because of it

https://lkml.org/lkml/2011/9/21/163]

The things that get converted are the registeration/unregistration routines
and the nmi handler itself has its args changed along with code removal
to check which list it is on (most are on one NMI list except for kgdb
which has both an NMI routine and an NMI Unknown routine).
Signed-off-by: NDon Zickus <dzickus@redhat.com>
Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: NCorey Minyard <minyard@acm.org>
Cc: Jason Wessel <jason.wessel@windriver.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Robert Richter <robert.richter@amd.com>
Cc: Huang Ying <ying.huang@intel.com>
Cc: Corey Minyard <minyard@acm.org>
Cc: Jack Steiner <steiner@sgi.com>
Link: http://lkml.kernel.org/r/1317409584-23662-4-git-send-email-dzickus@redhat.comSigned-off-by: NIngo Molnar <mingo@elte.hu>

There are numerous broken references to Documentation files (in other
Documentation files, in comments, etc.). These broken references are
caused by typo's in the references, and by renames or removals of the
Documentation files. Some broken references are simply odd.

Fix these broken references, sometimes by dropping the irrelevant text
they were part of.
Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Since the buffer might contain security related data it might be a good idea to
zero the buffer after we have copied it to userspace.

This got assigned CVE-2011-1162.
Signed-off-by: NRajiv Andrade <srajiv@linux.vnet.ibm.com>
Cc: Stable Kernel <stable@kernel.org>
Signed-off-by: NJames Morris <jmorris@namei.org>

This patch changes the call of tpm_transmit by supplying the size of the
userspace buffer instead of TPM_BUFSIZE.

This got assigned CVE-2011-1161.

[The first hunk didn't make sense given one could expect
 way less data than TPM_BUFSIZE, so added tpm_transmit boundary
 check over bufsiz instead
 The last parameter of tpm_transmit() reflects the amount
 of data expected from the device, and not the buffer size
 being supplied to it. It isn't ideal to parse it directly,
 so we just set it to the maximum the input buffer can handle
 and let the userspace API to do such job.]
Signed-off-by: NRajiv Andrade <srajiv@linux.vnet.ibm.com>
Cc: Stable Kernel <stable@kernel.org>
Signed-off-by: NJames Morris <jmorris@namei.org>

platform_device_unregister() will release all resources
and remove it from the subsystem, then drop reference count by
calling platform_device_put().

We should not call kfree(pdev) after platform_device_unregister(pdev).
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NRajiv Andrade <srajiv@linux.vnet.ibm.com>
Signed-off-by: NJames Morris <jmorris@namei.org>

On m68k, I get:

drivers/char/tpm/tpm_atmel.h: In function ‘atmel_get_base_addr’:
drivers/char/tpm/tpm_atmel.h:129: error: implicit declaration of function ‘ioport_map’
drivers/char/tpm/tpm_atmel.h:129: warning: return makes pointer from integer without a cast

The code in tpm_atmel.h supports PPC64 (using the device tree and ioremap())
and "anything else" (using ioport_map()). However, ioportmap() is only
available on platforms that set HAS_IOPORT.

Although PC64 seems to have HAS_IOPORT, a "depends on HAS_IOPORT" should work,
but I think it's better to expose the special PPC64 handling explicit using
"depends on PPC64 || HAS_IOPORT".
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NRajiv Andrade <srajiv@linux.vnet.ibm.com>
Signed-off-by: NJames Morris <jmorris@namei.org>

Change the CONFIG_DMAR to CONFIG_INTEL_IOMMU to be consistent
with the other IOMMU options.

Rename the CONFIG_INTR_REMAP to CONFIG_IRQ_REMAP to match the
irq subsystem name.

And define the CONFIG_DMAR_TABLE for the common ACPI DMAR
routines shared by both CONFIG_INTEL_IOMMU and CONFIG_IRQ_REMAP.
Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
Cc: yinghai@kernel.org
Cc: youquan.song@intel.com
Cc: joerg.roedel@amd.com
Cc: tony.luck@intel.com
Cc: dwmw2@infradead.org
Link: http://lkml.kernel.org/r/20110824001456.558630224@sbsiddha-desk.sc.intel.comSigned-off-by: NIngo Molnar <mingo@elte.hu>

Since printk_ratelimit() shouldn't be used anymore (see comment in
include/linux/printk.h), replace it with printk_ratelimited.
Signed-off-by: NChristian Dietrich <christian.dietrich@informatik.uni-erlangen.de>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The various basic memory allocation function return NULL, not an
ERR_PTR.

The semantic patch that makes this change is available in
scripts/coccinelle/null/eno.cocci.

More information about semantic patching is available at
http://coccinelle.lip6.fr/Signed-off-by: NThomas Meyer <thomas@m3y3r.de>
Cc: Niranjana Vishwanathapura <nvishwan@codeaurora.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This was needed by one of the generic serial drivers that was removed a
while ago.  No one even noticed that the driver could not be built
properly while it was in the staging directory.

So this removed the unneeded .h file.
Reported-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Suppress the output in the 'durations' sysfs entry if they were not read
during driver initialization. This is similar to other sysfs entries
that return nothing if for some reason sending the commands to the TPM
fails.
Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com>
Signed-off-by: NJames Morris <jmorris@namei.org>

dmesg reports:
[   29.365973] [TTM] AGP Bind memory failed.
[   29.366015] radeon 0000:80:00.0: object_init failed for (4096, 0x00000002)
[   29.366052] radeon 0000:80:00.0: (-22) create WB bo failed
[   29.366087] radeon 0000:80:00.0: Disabling GPU acceleration
[   29.366124] [drm] radeon: cp finalized
[   29.366168] [drm] radeon: cp finalized
[   29.366210] [TTM] Finalizing pool allocator.
[   29.366924] [TTM] Zone  kernel: Used memory at exit: 0 kiB.
[   29.366961] [TTM] Zone   dma32: Used memory at exit: 0 kiB.
[   29.366996] [drm] radeon: ttm finalized
[   29.367030] [drm] Forcing AGP to PCI mode

This patch allows binding user memory to the AGP GART on zx1-based
systems. dmesg thus no more complains about AGP bind memory failure,
disabled GPU acceleration or AGP mode forced to PCI.

Original work from Francisco Jerez in agp/amd-k7
(https://lkml.org/lkml/2010/10/15/469).
Tested-by: NÉmeric Maschino <emeric.maschino@gmail.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

vfork is moving away from freezer_[do_not_]count() one way or the
other leaving apm_ioctl() as the only user.  apm_ioctl() just wants to
wait for suspend/resume cycle to complete without hindering the
freezer.  Use wait_event_freezable() instead.

The only annoyance is that wait_event_freezable() wakes up with
-ERESTART if there are pending signals while apm_ioctl() wants to
ignore all signals until suspend is complete.  We can play with
@current->[real_]blocked but this is hardly a performance or latency
critical path - simply chill a bit on each iteration until
SUSPEND_DONE for unlikely cases where there are pending signals.
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>