1. 22 Oct, 2008 12 commits
    • Taisuke Yamada's avatar
      libata: LBA28/LBA48 off-by-one bug in ata.h · abcfbcb7
      Taisuke Yamada authored
      commit 97b697a1 upstream
      
      I recently bought 3 HGST P7K500-series 500GB SATA drives and
      had trouble accessing the block right on the LBA28-LBA48 border.
      Here's how it fails (same for all 3 drives):
      
        # dd if=/dev/sdc bs=512 count=1 skip=268435455 > /dev/null
        dd: reading `/dev/sdc': Input/output error
        0+0 records in
        0+0 records out
        0 bytes (0 B) copied, 0.288033 seconds, 0.0 kB/s
        # dmesg
        ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
        ata1.00: BMDMA stat 0x25
        ata1.00: cmd c8/00:08:f8:ff:ff/00:00:00:00:00/ef tag 0 dma 4096 in
        res 51/04:08:f8:ff:ff/00:00:00:00:00/ef Emask 0x1 (device error)
        ata1.00: status: { DRDY ERR }
        ata1.00: error: { ABRT }
        ata1.00: configured for UDMA/33
        ata1: EH complete
        ...
      
      After some investigations, it turned out this seems to be caused
      by misinterpretation of the ATA specification on LBA28 access.
      Following part is the code in question:
      
        === include/linux/ata.h ===
        static inline int lba_28_ok(u64 block, u32 n_block)
        {
          /* check the ending block number */
          return ((block + n_block - 1) < ((u64)1 << 28)) && (n_block <= 256);
        }
      
      HGST drive (sometimes) fails with LBA28 access of {block = 0xfffffff,
      n_block = 1}, and this behavior seems to be comformant. Other drives,
      including other HGST drives are not that strict, through.
      
      >From the ATA specification:
      (http://www.t13.org/Documents/UploadedDocuments/project/d1410r3b-ATA-ATAPI-6.pdf)
      
        8.15.29  Word (61:60): Total number of user addressable sectors
        This field contains a value that is one greater than the total number
        of user addressable sectors (see 6.2). The maximum value that shall
        be placed in this field is 0FFFFFFFh.
      
      So the driver shouldn't use the value of 0xfffffff for LBA28 request
      as this exceeds maximum user addressable sector. The logical maximum
      value for LBA28 is 0xffffffe.
      
      The obvious fix is to cut "- 1" part, and the patch attached just do
      that. I've been using the patched kernel for about a month now, and
      the same fix is also floating on the net for some time. So I believe
      this fix works reliably.
      
      Just FYI, many Windows/Intel platform users also seems to be struck
      by this, and HGST has issued a note pointing to Intel ICH8/9 driver.
      
        "28-bit LBA command is being used to access LBAs 29-bits in length"
      http://www.hitachigst.com/hddt/knowtree.nsf/cffe836ed7c12018862565b000530c74/b531b8bce8745fb78825740f00580e23
      
      Also, *BSDs seems to have similar fix included sometime around ~2004,
      through I have not checked out exact portion of the code.
      Signed-off-by: default avatarTaisuke Yamada <tai@rakugaki.org>
      Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      Cc: Chuck Ebbert <cebbert@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      abcfbcb7
    • Tejun Heo's avatar
      libata: fix EH action overwriting in ata_eh_reset() · dcbe5f2d
      Tejun Heo authored
      Commit a674050e upstream
      
      ehc->i.action got accidentally overwritten to ATA_EH_HARD/SOFTRESET in
      ata_eh_reset().  The original intention was to clear reset action
      which wasn't selected.  This can cause unexpected behavior when other
      EH actions are scheduled together with reset.  Fix it.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      Cc: Chuck Ebbert <cebbert@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      dcbe5f2d
    • Tejun Heo's avatar
      libata: always do follow-up SRST if hardreset returned -EAGAIN · dd5d2d84
      Tejun Heo authored
      commit 5dbfc9cb upstream
      
      As an optimization, follow-up SRST used to be skipped if
      classification wasn't requested even when hardreset requested it via
      -EAGAIN.  However, some hardresets can't wait for device readiness and
      skipping SRST can cause timeout or other failures during revalidation.
      Always perform follow-up SRST if hardreset returns -EAGAIN.  This
      makes reset paths more predictable and thus less error-prone.
      
      While at it, move hardreset error checking such that it's done right
      after hardreset is finished.  This simplifies followup SRST condition
      check a bit and makes the reset path easier to modify.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      Cc: Chuck Ebbert <cebbert@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      dd5d2d84
    • Oleg Nesterov's avatar
      fbcon_set_all_vcs: fix kernel crash when switching the rotated consoles · c8d4a26c
      Oleg Nesterov authored
      commit 232fb69a upstream
      
      echo 3 >> /sys/class/graphics/fbcon/rotate_all, then switch to another
      console. Result:
      
      	BUG: unable to handle kernel paging request at ffffc20005d00000
      	IP: [bitfill_aligned+149/265] bitfill_aligned+0x95/0x109
      	PGD 7e228067 PUD 7e229067 PMD 7bc1f067 PTE 0
      	Oops: 0002 [1] SMP
      	CPU 1
      	Modules linked in: [...a lot...]
      	Pid: 10, comm: events/1 Not tainted 2.6.26.5-45.fc9.x86_64 #1
      	RIP: 0010:[bitfill_aligned+149/265]  [bitfill_aligned+149/265] bitfill_aligned+0x95/0x109
      	RSP: 0018:ffff81007d811bc8  EFLAGS: 00010216
      	RAX: ffffc20005d00000 RBX: 0000000000000000 RCX: 0000000000000400
      	RDX: 0000000000000000 RSI: ffffc20005d00000 RDI: ffffffffffffffff
      	RBP: ffff81007d811be0 R08: 0000000000000400 R09: 0000000000000040
      	R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000010000
      	R13: ffffffff811632f0 R14: 0000000000000006 R15: ffff81007cb85400
      	FS:  0000000000000000(0000) GS:ffff81007e004780(0000) knlGS:0000000000000000
      	CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
      	CR2: ffffc20005d00000 CR3: 0000000000201000 CR4: 00000000000006e0
      	DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      	DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      	Process events/1 (pid: 10, threadinfo ffff81007d810000, task ffff81007d808000)
      	Stack:  ffff81007c9d75a0 0000000000000000 0000000000000000 ffff81007d811c80
      	 ffffffff81163a61 ffff810000000000 ffffffff8115f9c8 0000001000000000
      	 0000000100aaaaaa 000000007cd0d4a0 fffffd8a00000800 0001000000000000
      	Call Trace:
      	 [cfb_fillrect+523/798] cfb_fillrect+0x20b/0x31e
      	 [soft_cursor+416/436] ? soft_cursor+0x1a0/0x1b4
      	 [ccw_clear_margins+205/263] ccw_clear_margins+0xcd/0x107
      	 [fbcon_clear_margins+59/61] fbcon_clear_margins+0x3b/0x3d
      	 [fbcon_switch+1291/1466] fbcon_switch+0x50b/0x5ba
      	 [redraw_screen+261/481] redraw_screen+0x105/0x1e1
      	 [ccw_cursor+0/1869] ? ccw_cursor+0x0/0x74d
      	 [complete_change_console+48/190] complete_change_console+0x30/0xbe
      	 [change_console+115/120] change_console+0x73/0x78
      	 [console_callback+0/292] ? console_callback+0x0/0x124
      	 [console_callback+97/292] console_callback+0x61/0x124
      	 [schedule_delayed_work+25/30] ? schedule_delayed_work+0x19/0x1e
      	 [run_workqueue+139/282] run_workqueue+0x8b/0x11a
      	 [worker_thread+221/238] worker_thread+0xdd/0xee
      	 [autoremove_wake_function+0/56] ? autoremove_wake_function+0x0/0x38
      	 [worker_thread+0/238] ? worker_thread+0x0/0xee
      	 [kthread+73/118] kthread+0x49/0x76
      	 [child_rip+10/18] child_rip+0xa/0x12
      	 [kthread+0/118] ? kthread+0x0/0x76
      	 [child_rip+0/18] ? child_rip+0x0/0x12
      
      Because fbcon_set_all_vcs()->FBCON_SWAP() uses display->rotate == 0 instead
      of fbcon_ops->rotate, and vc_resize() has no effect because it is called with
      new_cols/rows == ->vc_cols/rows.
      
      Tested on 2.6.26.5-45.fc9.x86_64, but
      http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git seems to
      have the same problem.
      Signed-off-by: default avatarOleg Nesterov <oleg@tv-sign.ru>
      Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      c8d4a26c
    • Alexey Dobriyan's avatar
      modules: fix module "notes" kobject leak · 7a67d6e8
      Alexey Dobriyan authored
      commit e9432093 upstream
      
      Fix "notes" kobject leak
      
      It happens every rmmod if KALLSYMS=y and SYSFS=y.
      
      	# modprobe foo
      
      kobject: 'foo' (ffffffffa00743d0): kobject_add_internal: parent: 'module', set: 'module'
      kobject: 'holders' (ffff88017e7c5770): kobject_add_internal: parent: 'foo', set: '<NULL>'
      kobject: 'foo' (ffffffffa00743d0): kobject_uevent_env
      kobject: 'foo' (ffffffffa00743d0): fill_kobj_path: path = '/module/foo'
      kobject: 'notes' (ffff88017fa9b668): kobject_add_internal: parent: 'foo', set: '<NULL>'
      	  ^^^^^
      
      	# rmmod foo
      
      kobject: 'holders' (ffff88017e7c5770): kobject_cleanup
      kobject: 'holders' (ffff88017e7c5770): auto cleanup kobject_del
      kobject: 'holders' (ffff88017e7c5770): calling ktype release
      kobject: (ffff88017e7c5770): dynamic_kobj_release
      kobject: 'holders': free name
      kobject: 'foo' (ffffffffa00743d0): kobject_cleanup
      kobject: 'foo' (ffffffffa00743d0): does not have a release() function, it is broken and must be fixed.
      kobject: 'foo' (ffffffffa00743d0): auto cleanup 'remove' event
      kobject: 'foo' (ffffffffa00743d0): kobject_uevent_env
      kobject: 'foo' (ffffffffa00743d0): fill_kobj_path: path = '/module/foo'
      kobject: 'foo' (ffffffffa00743d0): auto cleanup kobject_del
      kobject: 'foo': free name
      
      	[whooops]
      Signed-off-by: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      7a67d6e8
    • Larry Finger's avatar
      b43legacy: Fix failure in rate-adjustment mechanism · c2fa492c
      Larry Finger authored
      commit c6a2afda upstream
      Date: Sat, 6 Sep 2008 16:51:22 -0500
      Subject: b43legacy: Fix failure in rate-adjustment mechanism
      
      A coding error present since b43legacy was incorporated into the
      kernel has prevented the driver from using the rate-setting mechanism
      of mac80211. The driver has been forced to remain at a 1 Mb/s rate.
      Signed-off-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      c2fa492c
    • Steve French's avatar
      CIFS: make sure we have the right resume info before calling CIFSFindNext · 282333bd
      Steve French authored
      commit 0752f152 upstream
      
      When we do a seekdir() or equivalent, we usually end up doing a
      FindFirst call and then call FindNext until we get to the offset that we
      want. The problem is that when we call FindNext, the code usually
      doesn't have the proper info (mostly, the filename of the entry from the
      last search) to resume the search.
      
      Add a "last_entry" field to the cifs_search_info that points to the last
      entry in the search. We calculate this pointer by using the
      LastNameOffset field from the search parms that are returned. We then
      use that info to do a cifs_save_resume_key before we call CIFSFindNext.
      
      This patch allows CIFS to reliably pass the "telldir" connectathon test.
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarSteve French <sfrench@us.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      282333bd
    • Dario Faggioli's avatar
      sched_rt.c: resch needed in rt_rq_enqueue() for the root rt_rq · 3c03d1ac
      Dario Faggioli authored
      commit f6121f4f upstream
      
      While working on the new version of the code for SCHED_SPORADIC I
      noticed something strange in the present throttling mechanism. More
      specifically in the throttling timer handler in sched_rt.c
      (do_sched_rt_period_timer()) and in rt_rq_enqueue().
      
      The problem is that, when unthrottling a runqueue, rt_rq_enqueue() only
      asks for rescheduling if the runqueue has a sched_entity associated to
      it (i.e., rt_rq->rt_se != NULL).
      Now, if the runqueue is the root rq (which has a rt_se = NULL)
      rescheduling does not take place, and it is delayed to some undefined
      instant in the future.
      
      This imply some random bandwidth usage by the RT tasks under throttling.
      For instance, setting rt_runtime_us/rt_period_us = 950ms/1000ms an RT
      task will get less than 95%. In our tests we got something varying
      between 70% to 95%.
      Using smaller time values, e.g., 95ms/100ms, things are even worse, and
      I can see values also going down to 20-25%!!
      
      The tests we performed are simply running 'yes' as a SCHED_FIFO task,
      and checking the CPU usage with top, but we can investigate thoroughly
      if you think it is needed.
      
      Things go much better, for us, with the attached patch... Don't know if
      it is the best approach, but it solved the issue for us.
      Signed-off-by: default avatarDario Faggioli <raistlin@linux.it>
      Signed-off-by: default avatarMichael Trimarchi <trimarchimichael@yahoo.it>
      Acked-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      3c03d1ac
    • Alan Cox's avatar
      tty: Termios locking - sort out real_tty confusions and lock reads · 0c178500
      Alan Cox authored
      commit 8f520021 upstream
      
      (only the tty_io.c portion of this commit)
      
      This moves us towards sanity and should mean our termios locking is now
      complete and comprehensive.
      Signed-off-by: default avatarAlan Cox <alan@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      0c178500
    • Alan Cox's avatar
      x86, early_ioremap: fix fencepost error · 6cb603ed
      Alan Cox authored
      commit c613ec1a upstream
      
      The x86 implementation of early_ioremap has an off by one error. If we get
      an object which ends on the first byte of a page we undermap by one page and
      this causes a crash on boot with the ASUS P5QL whose DMI table happens to fit
      this alignment.
      
      The size computation is currently
      
      	last_addr = phys_addr + size - 1;
      	npages = (PAGE_ALIGN(last_addr) - phys_addr)
      
      (Consider a request for 1 byte at alignment 0...)
      
      Closes #11693
      
      Debugging work by Ian Campbell/Felix Geyer
      Signed-off-by: default avatarAlan Cox <alan@rehat.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      6cb603ed
    • Thomas Gleixner's avatar
      x86: improve UP kernel when CPU-hotplug and SMP is enabled · b50094cc
      Thomas Gleixner authored
      commit 649c6653 upstream
      
      num_possible_cpus() can be > 1 when disabled CPUs have been accounted.
      
      Disabled CPUs are not in the cpu_present_map, so we can use
      num_present_cpus() as a safe indicator to switch to UP alternatives.
      Reported-by: default avatarChuck Ebbert <cebbert@redhat.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      b50094cc
    • Stefan Bader's avatar
      x86: Reserve FIRST_DEVICE_VECTOR in used_vectors bitmap. · 4c1f10b9
      Stefan Bader authored
      Not in upstream above 2.6.27 due to change in the way this code works
      (has been fixed differently there.)
      
      Someone from the community found out, that after repeatedly unloading
      and loading a device driver that uses MSI IRQs, the system eventually
      assigned the vector initially reserved for IRQ0 to the device driver.
      
      The reason for this is, that although IRQ0 is tied to the
      FIRST_DEVICE_VECTOR when declaring the irq_vector table, the
      corresponding bit in the used_vectors map is not set. So, if vectors are
      released and assigned often enough, the vector will get assigned to
      another interrupt. This happens more often with MSI interrupts as those
      are exclusively using a vector.
      
      Fix this by setting the bit for the FIRST_DEVICE_VECTOR in the bitmap.
      Signed-off-by: default avatarStefan Bader <stefan.bader@canonical.com>
      Acked-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      4c1f10b9
  2. 09 Oct, 2008 28 commits
    • Greg Kroah-Hartman's avatar
      Linux 2.6.26.6 · afc84dac
      Greg Kroah-Hartman authored
      afc84dac
    • Jarod Wilson's avatar
      S390: CVE-2008-1514: prevent ptrace padding area read/write in 31-bit mode · 34f3c11b
      Jarod Wilson authored
      commit 3d6e48f4 upstream
      
      When running a 31-bit ptrace, on either an s390 or s390x kernel,
      reads and writes into a padding area in struct user_regs_struct32
      will result in a kernel panic.
      
      This is also known as CVE-2008-1514.
      
      Test case available here:
      http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/tests/ptrace-tests/tests/user-area-padding.c?cvsroot=systemtap
      
      Steps to reproduce:
      1) wget the above
      2) gcc -o user-area-padding-31bit user-area-padding.c -Wall -ggdb2 -D_GNU_SOURCE -m31
      3) ./user-area-padding-31bit
      <panic>
      
      Test status
      -----------
      Without patch, both s390 and s390x kernels panic. With patch, the test case,
      as well as the gdb testsuite, pass without incident, padding area reads
      returning zero, writes ignored.
      
      Nb: original version returned -EINVAL on write attempts, which broke the
      gdb test and made the test case slightly unhappy, Jan Kratochvil suggested
      the change to return 0 on write attempts.
      Signed-off-by: default avatarJarod Wilson <jarod@redhat.com>
      Tested-by: default avatarJan Kratochvil <jan.kratochvil@redhat.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Moritz Muehlenhoff <jmm@debian.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      34f3c11b
    • Balbir Singh's avatar
      mm owner: fix race between swapoff and exit · 553d7dd7
      Balbir Singh authored
      [Here's a backport of 2.6.27-rc8's 31a78f23
       to 2.6.26 or 2.6.26.5: I wouldn't trouble -stable for the (root only)
       swapoff case which uncovered the bug, but the /proc/<pid>/<mmstats> case
       is open to all, so I think worth plugging in the next 2.6.26-stable.
       - Hugh]
      
      
      There's a race between mm->owner assignment and swapoff, more easily
      seen when task slab poisoning is turned on.  The condition occurs when
      try_to_unuse() runs in parallel with an exiting task.  A similar race
      can occur with callers of get_task_mm(), such as /proc/<pid>/<mmstats>
      or ptrace or page migration.
      
      CPU0                                    CPU1
                                              try_to_unuse
                                              looks at mm = task0->mm
                                              increments mm->mm_users
      task 0 exits
      mm->owner needs to be updated, but no
      new owner is found (mm_users > 1, but
      no other task has task->mm = task0->mm)
      mm_update_next_owner() leaves
                                              mmput(mm) decrements mm->mm_users
      task0 freed
                                              dereferencing mm->owner fails
      
      The fix is to notify the subsystem via mm_owner_changed callback(),
      if no new owner is found, by specifying the new task as NULL.
      
      Jiri Slaby:
      mm->owner was set to NULL prior to calling cgroup_mm_owner_callbacks(), but
      must be set after that, so as not to pass NULL as old owner causing oops.
      
      Daisuke Nishimura:
      mm_update_next_owner() may set mm->owner to NULL, but mem_cgroup_from_task()
      and its callers need to take account of this situation to avoid oops.
      
      Hugh Dickins:
      Lockdep warning and hang below exec_mmap() when testing these patches.
      exit_mm() up_reads mmap_sem before calling mm_update_next_owner(),
      so exec_mmap() now needs to do the same.  And with that repositioning,
      there's now no point in mm_need_new_owner() allowing for NULL mm.
      Reported-by: default avatarHugh Dickins <hugh@veritas.com>
      Signed-off-by: default avatarBalbir Singh <balbir@linux.vnet.ibm.com>
      Signed-off-by: default avatarJiri Slaby <jirislaby@gmail.com>
      Signed-off-by: default avatarDaisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
      Signed-off-by: default avatarHugh Dickins <hugh@veritas.com>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Paul Menage <menage@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      553d7dd7
    • Marcin Slusarz's avatar
      rtc: fix kernel panic on second use of SIGIO nofitication · eb07718d
      Marcin Slusarz authored
      commit 2e4a75cd upstream
      
      When userspace uses SIGIO notification and forgets to disable it before
      closing file descriptor, rtc->async_queue contains stale pointer to struct
      file.  When user space enables again SIGIO notification in different
      process, kernel dereferences this (poisoned) pointer and crashes.
      
      So disable SIGIO notification on close.
      
      Kernel panic:
      (second run of qemu (requires echo 1024 > /sys/class/rtc/rtc0/max_user_freq))
      
      general protection fault: 0000 [1] PREEMPT
      CPU 0
      Modules linked in: af_packet snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq usbhid tuner tea5767 tda8290 tuner_xc2028 xc5000 tda9887 tuner_simple tuner_types mt20xx tea5761 tda9875 uhci_hcd ehci_hcd usbcore bttv snd_via82xx snd_ac97_codec ac97_bus snd_pcm snd_timer ir_common compat_ioctl32 snd_page_alloc videodev v4l1_compat snd_mpu401_uart snd_rawmidi v4l2_common videobuf_dma_sg videobuf_core snd_seq_device snd btcx_risc soundcore tveeprom i2c_viapro
      Pid: 5781, comm: qemu-system-x86 Not tainted 2.6.27-rc6 #363
      RIP: 0010:[<ffffffff8024f891>]  [<ffffffff8024f891>] __lock_acquire+0x3db/0x73f
      RSP: 0000:ffffffff80674cb8  EFLAGS: 00010002
      RAX: ffff8800224c62f0 RBX: 0000000000000046 RCX: 0000000000000002
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8800224c62f0
      RBP: ffffffff80674d08 R08: 0000000000000002 R09: 0000000000000001
      R10: ffffffff80238941 R11: 0000000000000001 R12: 0000000000000000
      R13: 6b6b6b6b6b6b6b6b R14: ffff88003a450080 R15: 0000000000000000
      FS:  00007f98b69516f0(0000) GS:ffffffff80623200(0000) knlGS:00000000f7cc86d0
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 0000000000a87000 CR3: 0000000022598000 CR4: 00000000000006e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process qemu-system-x86 (pid: 5781, threadinfo ffff880028812000, task ffff88003a450080)
      Stack:  ffffffff80674cf8 0000000180238440 0000000200000002 0000000000000000
       ffff8800224c62f0 0000000000000046 0000000000000000 0000000000000002
       0000000000000002 0000000000000000 ffffffff80674d68 ffffffff8024fc7a
      Call Trace:
       <IRQ>  [<ffffffff8024fc7a>] lock_acquire+0x85/0xa9
       [<ffffffff8029cb62>] ? send_sigio+0x2a/0x184
       [<ffffffff80491d1f>] _read_lock+0x3e/0x4a
       [<ffffffff8029cb62>] ? send_sigio+0x2a/0x184
       [<ffffffff8029cb62>] send_sigio+0x2a/0x184
       [<ffffffff8024fb97>] ? __lock_acquire+0x6e1/0x73f
       [<ffffffff8029cd4d>] ? kill_fasync+0x2c/0x4e
       [<ffffffff8029cd10>] __kill_fasync+0x54/0x65
       [<ffffffff8029cd5b>] kill_fasync+0x3a/0x4e
       [<ffffffff80402896>] rtc_update_irq+0x9c/0xa5
       [<ffffffff80404640>] cmos_interrupt+0xae/0xc0
       [<ffffffff8025d1c1>] handle_IRQ_event+0x25/0x5a
       [<ffffffff8025e5e4>] handle_edge_irq+0xdd/0x123
       [<ffffffff8020da34>] do_IRQ+0xe4/0x144
       [<ffffffff8020bad6>] ret_from_intr+0x0/0xf
       <EOI>  [<ffffffff8026fdc2>] ? __alloc_pages_internal+0xe7/0x3ad
       [<ffffffff8033fe67>] ? clear_page_c+0x7/0x10
       [<ffffffff8026fc10>] ? get_page_from_freelist+0x385/0x450
       [<ffffffff8026fdc2>] ? __alloc_pages_internal+0xe7/0x3ad
       [<ffffffff80280aac>] ? anon_vma_prepare+0x2e/0xf6
       [<ffffffff80279400>] ? handle_mm_fault+0x227/0x6a5
       [<ffffffff80494716>] ? do_page_fault+0x494/0x83f
       [<ffffffff8049251d>] ? error_exit+0x0/0xa9
      
      Code: cc 41 39 45 28 74 24 e8 5e 1d 0f 00 85 c0 0f 84 6a 03 00 00 83 3d 8f a9 aa 00 00 be 47 03 00 00 0f 84 6a 02 00 00 e9 53 03 00 00 <41> ff 85 38 01 00 00 45 8b be 90 06 00 00 41 83 ff 2f 76 24 e8
      RIP  [<ffffffff8024f891>] __lock_acquire+0x3db/0x73f
       RSP <ffffffff80674cb8>
      ---[ end trace 431877d860448760 ]---
      Kernel panic - not syncing: Aiee, killing interrupt handler!
      Signed-off-by: default avatarMarcin Slusarz <marcin.slusarz@gmail.com>
      Acked-by: default avatarAlessandro Zummo <alessandro.zummo@towertech.it>
      Acked-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      eb07718d
    • David Winn's avatar
      fbcon: fix monochrome color value calculation · be38e82a
      David Winn authored
      commit 08650869 upstream
      
      Commit 22af89aa ("fbcon: replace mono_col
      macro with static inline") changed the order of operations for computing
      monochrome color values.  This generates 0xffff000f instead of 0x0000000f
      for a 4 bit monochrome color, leading to image corruption if it is passed
      to cfb_imageblit or other similar functions.  Fix it up.
      
      Cc: Harvey Harrison <harvey.harrison@gmail.com>
      Cc: "Antonino A. Daplas" <adaplas@pol.net>
      Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      be38e82a
    • Risto Suominen's avatar
      ALSA: snd-powermac: HP detection for 1st iMac G3 SL · ff37b8e1
      Risto Suominen authored
      commit 030b655b upstream
      
      Correct headphone detection for 1st generation iMac G3 Slot-loading (Screamer).
      
      This patch fixes the regression in the recent snd-powermac which
      doesn't support some G3/G4 PowerMacs:
          http://lkml.org/lkml/2008/10/1/220Signed-off-by: default avatarRisto Suominen <Risto.Suominen@gmail.com>
      Tested-by: default avatarMariusz Kozlowski <m.kozlowski@tuxland.pl>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      ff37b8e1
    • Risto Suominen's avatar
      ALSA: snd-powermac: mixers for PowerMac G4 AGP · 0433c92c
      Risto Suominen authored
      commit 4dbf95ba upstream
      
      Add mixer controls for PowerMac G4 AGP (Screamer).
      
      This patch fixes the regression in the recent snd-powermac which
      doesn't support some G3/G4 PowerMacs:
          http://lkml.org/lkml/2008/10/1/220Signed-off-by: default avatarRisto Suominen <Risto.Suominen@gmail.com>
      Tested-by: default avatarMariusz Kozlowski <m.kozlowski@tuxland.pl>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      0433c92c
    • Pascal Terjan's avatar
      braille_console: only register notifiers when the braille console is used · c6b06fdb
      Pascal Terjan authored
      commit c0c9209d upstream
      
      Only register the braille driver VT and keyboard notifiers when the
      braille console is used.  Avoids eating insert or backspace keys.
      
      Addresses http://bugzilla.kernel.org/show_bug.cgi?id=11242Signed-off-by: default avatarPascal Terjan <pterjan@mandriva.com>
      Signed-off-by: default avatarSamuel Thibault <samuel.thibault@ens-lyon.org>
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Moritz Muehlenhoff <jmm@inutil.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      c6b06fdb
    • David S. Miller's avatar
      sparc64: Fix missing devices due to PCI bridge test in of_create_pci_dev(). · 88e399f0
      David S. Miller authored
      [ Upstream commit 44b50e5a ]
      
      Just like in the arch/sparc64/kernel/of_device.c code fix commit
      071d7f4c3b411beae08d27656e958070c43b78b4 ("sparc64: Fix disappearing
      PCI devices on e3500.") we have to check the OF device node name for
      "pci" instead of relying upon the 'device_type' property being there
      on all PCI bridges.
      
      Tested by Meelis Roos, and confirmed to make the PCI QFE devices
      reappear on the E3500 system.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      88e399f0
    • David S. Miller's avatar
      sparc64: Fix disappearing PCI devices on e3500. · d78fdd8a
      David S. Miller authored
      [ Upstream commit 7ee766d8 ]
      
      Based upon a bug report by Meelis Roos.
      
      The OF device layer builds properties by matching bus types and
      applying 'range' properties as appropriate, up to the root.
      
      The match for "PCI" busses is looking at the 'device_type' property,
      and this does work %99 of the time.
      
      But on an E3500 system with a PCI QFE card, the DEC 21153 bridge
      sitting above the QFE network interface devices has a 'name' of "pci",
      but it completely lacks a 'device_type' property.  So we don't match
      it as a PCI bus, and subsequently we end up with no resource values at
      all for the devices sitting under that DEC bridge.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      d78fdd8a
    • David S. Miller's avatar
      sparc64: Fix OOPS in psycho_pcierr_intr_other(). · 28a65ba6
      David S. Miller authored
      [ Upstream commit f948cc6a ]
      
      We no longer put the top-level PCI controller device into the
      PCI layer device list.  So pbm->pci_bus->self is always NULL.
      
      Therefore, use direct PCI config space accesses to get at
      the PCI controller's PCI_STATUS register.
      
      Tested by Meelis Roos.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      28a65ba6
    • David S. Miller's avatar
      sparc64: Fix interrupt register calculations on Psycho and Sabre. · 284be31e
      David S. Miller authored
      [ Upstream commit ebfb2c63 ]
      
      Use the IMAP offset calculation for OBIO devices as documented in the
      programmer's manual.  Which is "0x10000 + ((ino & 0x1f) << 3)"
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      284be31e
    • David S. Miller's avatar
      sparc64: Fix PCI error interrupt registry on PSYCHO. · 24c5886b
      David S. Miller authored
      [ Upstream commit 80a56ab6 ]
      
      We need to pass IRQF_SHARED, otherwise we get things like:
      
      IRQ handler type mismatch for IRQ 33
      current handler: PSYCHO_UE
      Call Trace:
       [000000000048394c] request_irq+0xac/0x120
       [00000000007c5f6c] psycho_scan_bus+0x98/0x158
       [00000000007c2bc0] pcibios_init+0xdc/0x12c
       [0000000000426a5c] do_one_initcall+0x1c/0x160
       [00000000007c0180] kernel_init+0x9c/0xfc
       [0000000000427050] kernel_thread+0x30/0x60
       [00000000006ae1d0] rest_init+0x10/0x60
      
      on e3500 and similar systems.
      
      On a single board, the UE interrupts of two Psycho nodes
      are funneled through the same interrupt, from of_debug=3
      dump:
      
      /pci@b,4000: direct translate 2ee --> 21
       ...
      /pci@b,2000: direct translate 2ee --> 21
      
      Decimal "33" mentioned above is the hex "21" mentioned here.
      
      Thanks to Meelis Roos for dumps and testing.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      24c5886b
    • Herbert Xu's avatar
      udp: Fix rcv socket locking · fc69b36c
      Herbert Xu authored
      [ Upstream commit 93821778 ]
      
      The previous patch in response to the recursive locking on IPsec
      reception is broken as it tries to drop the BH socket lock while in
      user context.
      
      This patch fixes it by shrinking the section protected by the
      socket lock to sock_queue_rcv_skb only.  The only reason we added
      the lock is for the accounting which happens in that function.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      fc69b36c
    • Vlad Yasevich's avatar
      sctp: Fix oops when INIT-ACK indicates that peer doesn't support AUTH · ce8fd8b9
      Vlad Yasevich authored
      [ Upstream commit add52379 ]
      
      If INIT-ACK is received with SupportedExtensions parameter which
      indicates that the peer does not support AUTH, the packet will be
      silently ignore, and sctp_process_init() do cleanup all of the
      transports in the association.
      When T1-Init timer is expires, OOPS happen while we try to choose
      a different init transport.
      
      The solution is to only clean up the non-active transports, i.e
      the ones that the peer added.  However, that introduces a problem
      with sctp_connectx(), because we don't mark the proper state for
      the transports provided by the user.  So, we'll simply mark
      user-provided transports as ACTIVE.  That will allow INIT
      retransmissions to work properly in the sctp_connectx() context
      and prevent the crash.
      Signed-off-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      ce8fd8b9
    • Vlad Yasevich's avatar
      sctp: do not enable peer features if we can't do them. · 43562861
      Vlad Yasevich authored
      [ Upstream commit 0ef46e28 ]
      
      Do not enable peer features like addip and auth, if they
      are administratively disabled localy.  If the peer resports
      that he supports something that we don't, neither end can
      use it so enabling it is pointless.  This solves a problem
      when talking to a peer that has auth and addip enabled while
      we do not.  Found by Andrei Pelinescu-Onciul <andrei@iptel.org>.
      Signed-off-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      43562861
    • Herbert Xu's avatar
      ipsec: Fix pskb_expand_head corruption in xfrm_state_check_space · b047cf6d
      Herbert Xu authored
      [ Upstream commit d01dbeb6 ]
      
      We're never supposed to shrink the headroom or tailroom.  In fact,
      shrinking the headroom is a fatal action.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      b047cf6d
    • Vegard Nossum's avatar
      netlink: fix overrun in attribute iteration · 877755eb
      Vegard Nossum authored
      [ Upstream commit 1045b03e ]
      
      kmemcheck reported this:
      
        kmemcheck: Caught 16-bit read from uninitialized memory (f6c1ba30)
        0500110001508abf050010000500000002017300140000006f72672e66726565
         i i i i i i i i i i i i i u u u u u u u u u u u u u u u u u u u
                                         ^
      
        Pid: 3462, comm: wpa_supplicant Not tainted (2.6.27-rc3-00054-g6397ab9-dirty #13)
        EIP: 0060:[<c05de64a>] EFLAGS: 00010296 CPU: 0
        EIP is at nla_parse+0x5a/0xf0
        EAX: 00000008 EBX: fffffffd ECX: c06f16c0 EDX: 00000005
        ESI: 00000010 EDI: f6c1ba30 EBP: f6367c6c ESP: c0a11e88
         DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
        CR0: 8005003b CR2: f781cc84 CR3: 3632f000 CR4: 000006d0
        DR0: c0ead9bc DR1: 00000000 DR2: 00000000 DR3: 00000000
        DR6: ffff4ff0 DR7: 00000400
         [<c05d4b23>] rtnl_setlink+0x63/0x130
         [<c05d5f75>] rtnetlink_rcv_msg+0x165/0x200
         [<c05ddf66>] netlink_rcv_skb+0x76/0xa0
         [<c05d5dfe>] rtnetlink_rcv+0x1e/0x30
         [<c05dda21>] netlink_unicast+0x281/0x290
         [<c05ddbe9>] netlink_sendmsg+0x1b9/0x2b0
         [<c05beef2>] sock_sendmsg+0xd2/0x100
         [<c05bf945>] sys_sendto+0xa5/0xd0
         [<c05bf9a6>] sys_send+0x36/0x40
         [<c05c03d6>] sys_socketcall+0x1e6/0x2c0
         [<c020353b>] sysenter_do_call+0x12/0x3f
         [<ffffffff>] 0xffffffff
      
      This is the line in nla_ok():
      
        /**
         * nla_ok - check if the netlink attribute fits into the remaining bytes
         * @nla: netlink attribute
         * @remaining: number of bytes remaining in attribute stream
         */
        static inline int nla_ok(const struct nlattr *nla, int remaining)
        {
                return remaining >= sizeof(*nla) &&
                       nla->nla_len >= sizeof(*nla) &&
                       nla->nla_len <= remaining;
        }
      
      It turns out that remaining can become negative due to alignment in
      nla_next(). But GCC promotes "remaining" to unsigned in the test
      against sizeof(*nla) above. Therefore the test succeeds, and the
      nla_for_each_attr() may access memory outside the received buffer.
      
      A short example illustrating this point is here:
      
        #include <stdio.h>
      
        main(void)
        {
                printf("%d\n", -1 >= sizeof(int));
        }
      
      ...which prints "1".
      
      This patch adds a cast in front of the sizeof so that GCC will make
      a signed comparison and fix the illegal memory dereference. With the
      patch applied, there is no kmemcheck report.
      Signed-off-by: default avatarVegard Nossum <vegard.nossum@gmail.com>
      Acked-by: default avatarThomas Graf <tgraf@suug.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      877755eb
    • Santwona Behera's avatar
      niu: panic on reset · 99479c65
      Santwona Behera authored
      [ Upstream commit cff502a3 ]
      
      The reset_task function in the niu driver does not reset the tx and rx
      buffers properly. This leads to panic on reset. This patch is a
      modified implementation of the previously posted fix.
      Signed-off-by: default avatarSantwona Behera <santwona.behera@sun.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      99479c65
    • Neil Horman's avatar
      ipv6: Fix OOPS in ip6_dst_lookup_tail(). · 1e4c1698
      Neil Horman authored
      [ Upstream commit e550dfb0 ]
      
      This fixes kernel bugzilla 11469: "TUN with 1024 neighbours:
      ip6_dst_lookup_tail NULL crash"
      
      dst->neighbour is not necessarily hooked up at this point
      in the processing path, so blindly dereferencing it is
      the wrong thing to do.  This NULL check exists in other
      similar paths and this case was just an oversight.
      
      Also fix the completely wrong and confusing indentation
      here while we're at it.
      
      Based upon a patch by Evgeniy Polyakov.
      Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      1e4c1698
    • Arnaud Ebalard's avatar
      XFRM,IPv6: initialize ip6_dst_blackhole_ops.kmem_cachep · 9c44da04
      Arnaud Ebalard authored
      [ Upstream commit 5dc121e9 ]
      
      ip6_dst_blackhole_ops.kmem_cachep is not expected to be NULL (i.e. to
      be initialized) when dst_alloc() is called from ip6_dst_blackhole().
      Otherwise, it results in the following (xfrm_larval_drop is now set to
      1 by default):
      
      [   78.697642] Unable to handle kernel paging request for data at address 0x0000004c
      [   78.703449] Faulting instruction address: 0xc0097f54
      [   78.786896] Oops: Kernel access of bad area, sig: 11 [#1]
      [   78.792791] PowerMac
      [   78.798383] Modules linked in: btusb usbhid bluetooth b43 mac80211 cfg80211 ehci_hcd ohci_hcd sungem sungem_phy usbcore ssb
      [   78.804263] NIP: c0097f54 LR: c0334a28 CTR: c002d430
      [   78.809997] REGS: eef19ad0 TRAP: 0300   Not tainted  (2.6.27-rc5)
      [   78.815743] MSR: 00001032 <ME,IR,DR>  CR: 22242482  XER: 20000000
      [   78.821550] DAR: 0000004c, DSISR: 40000000
      [   78.827278] TASK = eef0df40[3035] 'mip6d' THREAD: eef18000
      [   78.827408] GPR00: 00001032 eef19b80 eef0df40 00000000 00008020 eef19c30 00000001 00000000
      [   78.833249] GPR08: eee5101c c05a5c10 ef9ad500 00000000 24242422 1005787c 00000000 1004f960
      [   78.839151] GPR16: 00000000 10024e90 10050040 48030018 0fe44150 00000000 00000000 eef19c30
      [   78.845046] GPR24: eef19e44 00000000 eef19bf8 efb37c14 eef19bf8 00008020 00009032 c0596064
      [   78.856671] NIP [c0097f54] kmem_cache_alloc+0x20/0x94
      [   78.862581] LR [c0334a28] dst_alloc+0x40/0xc4
      [   78.868451] Call Trace:
      [   78.874252] [eef19b80] [c03c1810] ip6_dst_lookup_tail+0x1c8/0x1dc (unreliable)
      [   78.880222] [eef19ba0] [c0334a28] dst_alloc+0x40/0xc4
      [   78.886164] [eef19bb0] [c03cd698] ip6_dst_blackhole+0x28/0x1cc
      [   78.892090] [eef19be0] [c03d9be8] rawv6_sendmsg+0x75c/0xc88
      [   78.897999] [eef19cb0] [c038bca4] inet_sendmsg+0x4c/0x78
      [   78.903907] [eef19cd0] [c03207c8] sock_sendmsg+0xac/0xe4
      [   78.909734] [eef19db0] [c03209e4] sys_sendmsg+0x1e4/0x2a0
      [   78.915540] [eef19f00] [c03220a8] sys_socketcall+0xfc/0x210
      [   78.921406] [eef19f40] [c0014b3c] ret_from_syscall+0x0/0x38
      [   78.927295] --- Exception: c01 at 0xfe2d730
      [   78.927297]     LR = 0xfe2d71c
      [   78.939019] Instruction dump:
      [   78.944835] 91640018 9144001c 900a0000 4bffff44 9421ffe0 7c0802a6 bf810010 7c9d2378
      [   78.950694] 90010024 7fc000a6 57c0045e 7c000124 <83e3004c> 8383005c 2f9f0000 419e0050
      [   78.956464] ---[ end trace 05fa1ed7972487a1 ]---
      
      As commented by Benjamin Thery, the bug was introduced by
      f2fc6a54, while adding network
      namespaces support to ipv6 routes.
      Signed-off-by: default avatarArnaud Ebalard <arno@natisbad.org>
      Acked-by: default avatarBenjamin Thery <benjamin.thery@bull.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      9c44da04
    • Timo Teras's avatar
      af_key: Free dumping state on socket close · 1ead836b
      Timo Teras authored
      [ Upstream commit 05238204 ]
      
      Fix a xfrm_{state,policy}_walk leak if pfkey socket is closed while
      dumping is on-going.
      Signed-off-by: default avatarTimo Teras <timo.teras@iki.fi>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1ead836b
    • Alan Cox's avatar
      pcmcia: Fix broken abuse of dev->driver_data · 400f9f32
      Alan Cox authored
      [ Upstream commit: cec5eb7b ]
      
      PCMCIA abuses dev->private_data in the probe methods. Unfortunately it
      continues to abuse it after calling drv->probe() which leads to crashes and
      other nasties (such as bogus probes of multifunction devices) giving errors like
      
      pcmcia: registering new device pcmcia0.1
      kernel: 0.1: GetNextTuple: No more items
      
      Extract the passed data before calling the driver probe function that way
      we don't blow up when the driver reuses dev->private_data as its right.
      Signed-off-by: default avatarAlan Cox <alan@redhat.com>
      Signed-off-by: default avatarDominik Brodowski <linux@dominikbrodowski.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      400f9f32
    • Thomas Gleixner's avatar
      clockevents: remove WARN_ON which was used to gather information · bc3ac469
      Thomas Gleixner authored
      commit 61c22c34 upstream
      
      The issue of the endless reprogramming loop due to a too small
      min_delta_ns was fixed with the previous updates of the clock events
      code, but we had no information about the spread of this problem. I
      added a WARN_ON to get automated information via kerneloops.org and to
      get some direct reports, which allowed me to analyse the affected
      machines.
      
      The WARN_ON has served its purpose and would be annoying for a release
      kernel. Remove it and just keep the information about the increase of
      the min_delta_ns value.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      bc3ac469
    • Maciej W. Rozycki's avatar
      ntp: fix calculation of the next jiffie to trigger RTC sync · e0d725a2
      Maciej W. Rozycki authored
      commit 4ff4b9e1 upstream
      
      We have a bug in the calculation of the next jiffie to trigger the RTC
      synchronisation.  The aim here is to run sync_cmos_clock() as close as
      possible to the middle of a second.  Which means we want this function to
      be called less than or equal to half a jiffie away from when now.tv_nsec
      equals 5e8 (500000000).
      
      If this is not the case for a given call to the function, for this purpose
      instead of updating the RTC we calculate the offset in nanoseconds to the
      next point in time where now.tv_nsec will be equal 5e8.  The calculated
      offset is then converted to jiffies as these are the unit used by the
      timer.
      
      Hovewer timespec_to_jiffies() used here uses a ceil()-type rounding mode,
      where the resulting value is rounded up.  As a result the range of
      now.tv_nsec when the timer will trigger is from 5e8 to 5e8 + TICK_NSEC
      rather than the desired 5e8 - TICK_NSEC / 2 to 5e8 + TICK_NSEC / 2.
      
      As a result if for example sync_cmos_clock() happens to be called at the
      time when now.tv_nsec is between 5e8 + TICK_NSEC / 2 and 5e8 to 5e8 +
      TICK_NSEC, it will simply be rescheduled HZ jiffies later, falling in the
      same range of now.tv_nsec again.  Similarly for cases offsetted by an
      integer multiple of TICK_NSEC.
      
      This change addresses the problem by subtracting TICK_NSEC / 2 from the
      nanosecond offset to the next point in time where now.tv_nsec will be
      equal 5e8, effectively shifting the following rounding in
      timespec_to_jiffies() so that it produces a rounded-to-nearest result.
      Signed-off-by: default avatarMaciej W. Rozycki <macro@linux-mips.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      e0d725a2
    • Thomas Gleixner's avatar
      x86: HPET: read back compare register before reading counter · 9c57bca1
      Thomas Gleixner authored
      commit 72d43d9b upstream
      
      After fixing the u32 thinko I sill had occasional hickups on ATI chipsets
      with small deltas. There seems to be a delay between writing the compare
      register and the transffer to the internal register which triggers the
      interrupt. Reading back the value makes sure, that it hit the internal
      match register befor we compare against the counter value.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      9c57bca1
    • Thomas Gleixner's avatar
      x86: HPET fix moronic 32/64bit thinko · 45f9d522
      Thomas Gleixner authored
      commit f7676254 upstream
      
      We use the HPET only in 32bit mode because:
      1) some HPETs are 32bit only
      2) on i386 there is no way to read/write the HPET atomic 64bit wide
      
      The HPET code unification done by the "moron of the year" did
      not take into account that unsigned long is different on 32 and
      64 bit.
      
      This thinko results in a possible endless loop in the clockevents
      code, when the return comparison fails due to the 64bit/332bit
      unawareness.
      
      unsigned long cnt = (u32) hpet_read() + delta can wrap over 32bit.
      but the final compare will fail and return -ETIME causing endless
      loops.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      45f9d522
    • Thomas Gleixner's avatar
      clockevents: broadcast fixup possible waiters · 92741d2d
      Thomas Gleixner authored
      commit 7300711e upstream
      
      Until the C1E patches arrived there where no users of periodic broadcast
      before switching to oneshot mode. Now we need to trigger a possible
      waiter for a periodic broadcast when switching to oneshot mode.
      Otherwise we can starve them for ever.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      92741d2d