- 11 Jun, 2007 20 commits
-
-
Hugh Dickins authored
Why is it that since the 2f1a2ccb console UTF-8 fixes went into 2.6.22-rc1, the PowerMac G5 shows only inverse video question marks for the text on tty2-6? whereas tty1 is fine, and so is x86. No fault of that patch: by removing the old fallback behaviour, it reveals that 32-bit setfont running on 64-bit kernels has only really worked on the current console, the rest getting faked by that inadequate fallback. Bring the compat do_unimap_ioctl into line with the main one: PIO_UNIMAP and GIO_UNIMAP apply to the specified tty, not redirected to fg_console. Use the same checks, and most particularly, remember to check access_ok: con_set_unimap and con_get_unimap are using __get_user and __put_user. And the compat vt_check should ask for the same capability as the main one, CAP_SYS_TTY_CONFIG rather than CAP_SYS_ADMIN. Added in vt_ioctl's vc_cons_allocated check for safety, though failure may well be impossible. Signed-off-by:
Hugh Dickins <hugh@veritas.com> Signed-off-by:
Chris Wright <chrisw@sous-sol.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Daniel Drake authored
ZD1211 appears to be back in production: a number of new devices have been appearing! Some of them are using new radios. This patch adds support for the next generation AL2230 RF chip which has been spotted in a few new devices. [As this patch was too late for 2.6.21, the kernel was modified to reject AL2230S devices because for me and others, the devices silently failed (and this looked like a driver bug). After doing so, a few people reported that AL2230S devices were working correctly for them even before AL2230S support was present. I'd like to propose that we fix both situations by backporting the AL2230S support into 2.6.21-stable] Signed-off-by:
Daniel Drake <dsd@gentoo.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Oliver Endriss authored
Revert changeset http://linuxtv.org/hg/v4l-dvb?cmd=changeset;node=e7c424bbf9aa;style=gitweb Petri Helin found that this changeset broke tuning: 'Well, after going through the changes that might have had effect on tuning, I found out the one which had caused this problem. I do not know the actual reason behind the change, but the changelog says that it was meant to "Fix TD1316 tuner for DVBC". But at least in my case it seams to have broken the tuner instead.' Signed-off-by:
Oliver Endriss <o.endriss@gmx.de> Thanks-to: Petri Helin <phelin@googlemail.com> Acked-by:
e9hack <e9hack@googlemail.com> Acked-by:
Thomas Kaiser <linux-dvb@kaiser-linux.li> Signed-off-by:
Mauro Carvalho Chehab <mchehab@infradead.org> Acked-by:
Michael Krufky <mkrufky@linuxtv.org> Signed-off-by:
-
Stefan Richter authored
This adds a real parent device to eth1394's ethX device like in Linux 2.6.20 and older. However, due to unfinished conversion of the ieee1394 away from class_device, we now refer to the FireWire controller's PCI device as the parent, not to the ieee1394 driver's fw-host device. Having a real parent device instead of a virtual one allows udev scripts to distinguish eth1394 interfaces from networking bridges, bondings and the likes. Fixes a regression since 2.6.21: https://bugs.gentoo.org/show_bug.cgi?id=177199Signed-off-by:
Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by:
-
Roland Scheidegger authored
The i8042 driver fails detection of the AUX port with some chips, because they apparently do not change the I8042_CTR_AUXDIS bit immediately. This is known to affect at least HP500/HP510 notebooks, consequently the built-in touchpad will not work. The patch will simply reread the value until it gets the expected value or a retry limit is hit, without touching other workaround code in the same area. Signed-off-by:
Roland Scheidegger <sroland@tungstengraphics.com> Signed-off-by:
Dmitry Torokhov <dtor@mail.ru> Signed-off-by:
-
Daniel Drake authored
Commit 93c8bf45 modified the USB device matching behaviour to ignore interface class matches if the device class is vendor-specific. This patch adds explicit ID matches for Logitech QuickCam devices, which have a vendor specific device class (but standards-compliant audio interfaces). This fixes a 2.6.20 regression where the audio component of these devices was no longer usable. http://bugs.gentoo.org/show_bug.cgi?id=175715 https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/93822 https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3040 Based on a patch from sergiom Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
Jaroslav Kysela <perex@suse.cz> Signed-off-by:
-
Auke Kok authored
To assure the symmetry of poll enable/disable in up/down, we should initialize the netdevice to be poll_disabled at load time. Doing this after register_netdevice leaves us open to another race, so lets move all the netif_* calls above register_netdevice so the stack starts out how we expect it to be. Signed-off-by:
Auke Kok <auke-jan.h.kok@intel.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Doug Chapman <doug.chapman@hp.com> Signed-off-by:
Jeff Garzik <jeff@garzik.org> Signed-off-by:
-
Sergei Shtylyov authored
HPT36x chip don't seem to have the channel enable bits, so prevent the IDE core from checking them... Signed-off-by:
Sergei Shtylyov <sshtylyov@ru.mvista.com> Cc: <bzolnier@gmail.com> Signed-off-by:
-
Jiri Slaby authored
An omitted unlock. Signed-off-by:
Jiri Slaby <jirislaby@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Takashi Iwai authored
Some boards have the audio codec on slot #3 while the modem codec on slot #0. The driver should continue to probe the slots when no audio codec is found. This fixes the problem of no device on Toshiba A100 (and some other ATI SB450 devices). Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
Probing the codec slots on ATI controller causes problems on some devices like Acer laptops. On these devices, reading from codec slot 3 results in the communication failure with the codec chip. Meanwhile, some laptops (e.g. Gateway) have the codec connection only on slot 3, and probing this slot is mandatory for them. The patch improves the probing robustness. The additional slots are now checked only when no codecs are found in the primary three slots. Signed-off-by:
-
Thomas Gleixner authored
The NOHZ patch contains a check for softirqs pending when a CPU goes idle. The BUG is unrelated to NOHZ, it just was made visible by the NOHZ patch. The BUG showed up mainly on P4 / hyperthreading enabled machines which lead the investigations into the wrong direction in the first place. The real cause is in cond_resched_softirq(): cond_resched_softirq() is enabling softirqs without invoking the softirq daemon when softirqs are pending. This leads to the warning message in the NOHZ idle code: t1 runs softirq disabled code on CPU#0 interrupt happens, softirq is raised, but deferred (softirqs disabled) t1 calls cond_resched_softirq() enables softirqs via _local_bh_enable() calls schedule() t2 runs t1 is migrated to CPU#1 t2 is done and invokes idle() NOHZ detects the pending softirq Fix: change _local_bh_enable() to local_bh_enable() so the softirq daemon is invoked. Thanks to Anant Nitya for debugging this with great patience ! Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Oleg Nesterov authored
It is a known fact that freezeable multithreaded workqueues doesn't like CPU_DEAD. We keep them only for the incoming CPU-hotplug rework. Sadly, we can't just kill create_freezeable_workqueue() right now, make them singlethread. Signed-off-by:
Oleg Nesterov <oleg@tv-sign.ru> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Gautham R Shenoy <ego@in.ibm.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Miklos Szeredi authored
The wrong lookup flag was tested in ->create() causing havoc (error or Oops) when a regular file was created with mknod() in a fuse filesystem. Thanks to J. Cameijo Cerdeira for the report. Kernels 2.6.18 onward are affected. Please apply to -stable as well. Signed-off-by:
Miklos Szeredi <mszeredi@suse.cz> Signed-off-by:
-
NeilBrown authored
It is possible that real data or metadata follows the bitmap without full page alignment. So limit the last write to be only the required number of bytes, rounded up to the hard sector size of the device. Signed-off-by:
Neil Brown <neilb@suse.de> Signed-off-by:
-
NeilBrown authored
If a raid0 has a component device larger than 4TB, and is accessed on a 32bit machines, then as 'chunk' is unsigned lock, chunk << chunksize_bits can overflow (this can be as high as the size of the device in KB). chunk itself will not overflow (without triggering a BUG). So change 'chunk' to be 'sector_t, and get rid of the 'BUG' as it becomes impossible to hit. Cc: "Jeff Zheng" <Jeff.Zheng@endace.com> Signed-off-by:
-
Andi Kleen authored
Only try to allocate MSRs once instead of for every CPU. This assumes the MSRs are the same on all CPUs which is currently true. P4-HT is a special case for different SMT threads, but the code always saves/restores all MSRs so it works identical. Signed-off-by:
Andi Kleen <ak@suse.de> Signed-off-by:
-
Thomas Gleixner authored
The warning in the NOHZ code, which triggers when a CPU goes idle with softirqs pending can fill up the logs quite quickly. Rate limit the output until we found the root cause of that problem. Signed-off-by:
-
Thomas Gleixner authored
Booting a SMP kernel with maxcpus=1 on a SMP system leads to a hard hang, because ACPI ignores the maxcpus setting and sends timer broadcast info for the offline CPUs. This results in a stuck for ever call to smp_call_function_single() on an offline CPU. Ignore the bogus information and print a kernel error to remind ACPI folks to fix it. Affects 2.6.21 / 2.6.22-rc Signed-off-by:
-
Thomas Gleixner authored
Some systems have a HPET which is not incrementing, which leads to a complete hang. Detect it during HPET setup. Signed-off-by:
-
- 07 Jun, 2007 5 commits
-
-
Chris Wright authored
-
Patrick McHardy authored
[PATCH] NETFILTER: {ip, nf}_conntrack_sctp: fix remotely triggerable NULL ptr dereference (CVE-2007-2876) When creating a new connection by sending an unknown chunk type, we don't transition to a valid state, causing a NULL pointer dereference in sctp_packet when accessing sctp_timeouts[SCTP_CONNTRACK_NONE]. Fix by don't creating new conntrack entry if initial state is invalid. Noticed by Vilmos Nebehaj <vilmos.nebehaj@ramsys.hu> CC: Kiran Kumar Immidi <immidi_kiran@yahoo.com> Cc: David Miller <davem@davemloft.net> Signed-off-by:Patrick McHardy <kaber@trash.net> Signed-off-by:
-
Chris Wright authored
Use simple_read_from_buffer to avoid possible underflow in cpuset_tasks_read which could allow user to read kernel memory. Note: This is fixed upstream in 85badbdfSigned-off-by:
-
Matt Mackall authored
Add data from zero-entropy random_writes directly to output pools to avoid accounting difficulties on machines without entropy sources. Tested on lguest with all entropy sources disabled. Signed-off-by:
Matt Mackall <mpm@selenic.com> Acked-by:
"Theodore Ts'o" <tytso@mit.edu> Signed-off-by:
-
Matt Mackall authored
Fix cast error in entropy extraction. Add comments explaining the magic 16. Remove extra confusing loop variable. Signed-off-by:
-
- 24 May, 2007 2 commits
-
-
Chris Wright authored
-
Jordan Crouse authored
Allow in-place crypto operations. Also remove the coherent user flag (we use it automagically now), and by default use the user written key rather then the HW hidden key - this makes crypto just work without any special considerations, and thats OK, since its our only usage model. Signed-off-by:
Jordan Crouse <jordan.crouse@amd.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
- 23 May, 2007 13 commits
-
-
Chris Wright authored
-
Herbert Xu authored
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:
-
Daniel Drake authored
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:
Dave Jones <davej@redhat.com> Signed-off-by:
-
Dave Jones authored
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 authored
Reported-by:
Calvin Dodge <caldodge@gmail.com> Signed-off-by:
-
Patrick McHardy authored
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:
-
Dave Kleikamp authored
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:
-
Jiri Kosina authored
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:
-
Stephen Hemminger authored
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:
-
Stephen Hemminger authored
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 authored
The driver is not ready to support 88e8071 chip, it requires several more changes (not done yet). If this chip is present, system will hang on boot. Signed-off-by: -
Stephen Hemminger authored
It looks like the problems of Gigabyte 88E8056 are unique to that chip motherboard and maybe fixable by EEPROM update. Signed-off-by:
-
David Miller authored
If we miss on the ranges, just toss the translation up to the parent instead of failing. Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
