Skip to content

L
linux
Switch branch/tag
  1. 18 May, 2014 28 commits
  3. 30 Apr, 2014 12 commits
    • Ben Hutchings's avatar
      Linux 3.2.58 · f453538a
      Ben Hutchings authored
      f453538a
    • Ben Hutchings's avatar
      Revert "isci: fix reset timeout handling" · 2e59f013
      Ben Hutchings authored 
      This reverts commit 584ec122, which
was commit ddfadd77 upstream.  It
causes boot failure on 3.2 although no such problem occurs upstream.
Reported-by: default avatarOndrej Zary <linux@rainbow-software.org>
Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
Acked-by: default avatarDan Williams <dan.j.williams@intel.com>
      2e59f013
    • Ben Hutchings's avatar
      Revert "alpha: fix broken network checksum" · 53119558
      Ben Hutchings authored 
      This reverts commit b93b90ff, which
was commit 0ef38d70 upstream.
It was intended to fix a regression which never occurred in 3.2.
      53119558
    • Mikulas Patocka's avatar
      powernow-k6: reorder frequencies · 3d793c47
      Mikulas Patocka authored 
      commit 22c73795 upstream.

This patch reorders reported frequencies from the highest to the lowest,
just like in other frequency drivers.
Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
[bwh: Backported to 3.2: cpu_frequency_table::driver_data is called index]
Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      3d793c47
    • Mikulas Patocka's avatar
      powernow-k6: correctly initialize default parameters · 133eadd5
      Mikulas Patocka authored 
      commit d82b922a upstream.

The powernow-k6 driver used to read the initial multiplier from the
powernow register. However, there is a problem with this:

* If there was a frequency transition before, the multiplier read from the
  register corresponds to the current multiplier.
* If there was no frequency transition since reset, the field in the
  register always reads as zero, regardless of the current multiplier that
  is set using switches on the mainboard and that the CPU is running at.

The zero value corresponds to multiplier 4.5, so as a consequence, the
powernow-k6 driver always assumes multiplier 4.5.

For example, if we have 550MHz CPU with bus frequency 100MHz and
multiplier 5.5, the powernow-k6 driver thinks that the multiplier is 4.5
and bus frequency is 122MHz. The powernow-k6 driver then sets the
multiplier to 4.5, underclocking the CPU to 450MHz, but reports the
current frequency as 550MHz.

There is no reliable way how to read the initial multiplier. I modified
the driver so that it contains a table of known frequencies (based on
parameters of existing CPUs and some common overclocking schemes) and sets
the multiplier according to the frequency. If the frequency is unknown
(because of unusual overclocking or underclocking), the user must supply
the bus speed and maximum multiplier as module parameters.

This patch should be backported to all stable kernels. If it doesn't
apply cleanly, change it, or ask me to change it.
Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
[bwh: Backported to 3.2:
 - Adjust context
 - s/driver_data/index/]
Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      133eadd5
    • Mikulas Patocka's avatar
      powernow-k6: disable cache when changing frequency · f5fe5bb9
      Mikulas Patocka authored 
      commit e20e1d0a upstream.

I found out that a system with k6-3+ processor is unstable during network
server load. The system locks up or the network card stops receiving. The
reason for the instability is the CPU frequency scaling.

During frequency transition the processor is in "EPM Stop Grant" state.
The documentation says that the processor doesn't respond to inquiry
requests in this state. Consequently, coherency of processor caches and
bus master devices is not maintained, causing the system instability.

This patch flushes the cache during frequency transition. It fixes the
instability.

Other minor changes:
* u64 invalue changed to unsigned long because the variable is 32-bit
* move the logic to set the multiplier to a separate function
  powernow_k6_set_cpu_multiplier
* preserve lower 5 bits of the powernow port instead of 4 (the voltage
  field has 5 bits)
* mask interrupts when reading the multiplier, so that the port is not
  open during other activity (running other kernel code with the port open
  shouldn't cause any misbehavior, but we should better be safe and keep
  the port closed)

This patch should be backported to all stable kernels. If it doesn't
apply cleanly, change it, or ask me to change it.
Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      f5fe5bb9
    • Paul Moore's avatar
      selinux: correctly label /proc inodes in use before the policy is loaded · a07089d7
      Paul Moore authored 
      commit f64410ec upstream.

This patch is based on an earlier patch by Eric Paris, he describes
the problem below:

  "If an inode is accessed before policy load it will get placed on a
   list of inodes to be initialized after policy load.  After policy
   load we call inode_doinit() which calls inode_doinit_with_dentry()
   on all inodes accessed before policy load.  In the case of inodes
   in procfs that means we'll end up at the bottom where it does:

     /* Default to the fs superblock SID. */
     isec->sid = sbsec->sid;

     if ((sbsec->flags & SE_SBPROC) && !S_ISLNK(inode->i_mode)) {
             if (opt_dentry) {
                     isec->sclass = inode_mode_to_security_class(...)
                     rc = selinux_proc_get_sid(opt_dentry,
                                               isec->sclass,
                                               &sid);
                     if (rc)
                             goto out_unlock;
                     isec->sid = sid;
             }
     }

   Since opt_dentry is null, we'll never call selinux_proc_get_sid()
   and will leave the inode labeled with the label on the superblock.
   I believe a fix would be to mimic the behavior of xattrs.  Look
   for an alias of the inode.  If it can't be found, just leave the
   inode uninitialized (and pick it up later) if it can be found, we
   should be able to call selinux_proc_get_sid() ..."

On a system exhibiting this problem, you will notice a lot of files in
/proc with the generic "proc_t" type (at least the ones that were
accessed early in the boot), for example:

   # ls -Z /proc/sys/kernel/shmmax | awk '{ print $4 " " $5 }'
   system_u:object_r:proc_t:s0 /proc/sys/kernel/shmmax

However, with this patch in place we see the expected result:

   # ls -Z /proc/sys/kernel/shmmax | awk '{ print $4 " " $5 }'
   system_u:object_r:sysctl_kernel_t:s0 /proc/sys/kernel/shmmax

Cc: Eric Paris <eparis@redhat.com>
Signed-off-by: default avatarPaul Moore <pmoore@redhat.com>
Acked-by: default avatarEric Paris <eparis@redhat.com>
Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      a07089d7
    • Jiri Slaby's avatar
      Char: ipmi_bt_sm, fix infinite loop · 24b528cb
      Jiri Slaby authored 
      commit a94cdd1f upstream.

In read_all_bytes, we do

  unsigned char i;
  ...
  bt->read_data[0] = BMC2HOST;
  bt->read_count = bt->read_data[0];
  ...
  for (i = 1; i <= bt->read_count; i++)
    bt->read_data[i] = BMC2HOST;

If bt->read_data[0] == bt->read_count == 255, we loop infinitely in the
'for' loop.  Make 'i' an 'int' instead of 'char' to get rid of the
overflow and finish the loop after 255 iterations every time.
Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
Reported-and-debugged-by: default avatarRui Hui Dian <rhdian@novell.com>
Cc: Tomas Cech <tcech@suse.cz>
Cc: Corey Minyard <minyard@acm.org>
Cc: <openipmi-developer@lists.sourceforge.net>
Signed-off-by: default avatarCorey Minyard <cminyard@mvista.com>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      24b528cb
    • Qiang Huang's avatar
      drivers: hv: additional switch to use mb() instead of smp_mb() · 683bce8d
      Qiang Huang authored 
      commit e4af376d(drivers: hv: switch to use mb() instead of smp_mb()),
the adjustment mistakenly dropped the change in hv_ringbuffer_read,
so add it.
Signed-off-by: default avatarQiang Huang <h.huangqiang@huawei.com>
Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      683bce8d
    • Andy Grover's avatar
      target/tcm_fc: Fix use-after-free of ft_tpg · 6ff2fec9
      Andy Grover authored 
      commit 2c42be2d upstream.

ft_del_tpg checks tpg->tport is set before unlinking the tpg from the
tport when the tpg is being removed. Set this pointer in ft_tport_create,
or the unlinking won't happen in ft_del_tpg and tport->tpg will reference
a deleted object.

This patch sets tpg->tport in ft_tport_create, because that's what
ft_del_tpg checks, and is the only way to get back to the tport to
clear tport->tpg.

The bug was occuring when:

- lport created, tport (our per-lport, per-provider context) is
  allocated.
  tport->tpg = NULL
- tpg created
- a PRLI is received. ft_tport_create is called, tpg is found and
  tport->tpg is set
- tpg removed. ft_tpg is freed in ft_del_tpg. Since tpg->tport was not
  set, tport->tpg is not cleared and points at freed memory
- Future calls to ft_tport_create return tport via first conditional,
  instead of searching for new tpg by calling ft_lport_find_tpg.
  tport->tpg is still invalid, and will access freed memory.

see https://bugzilla.redhat.com/show_bug.cgi?id=1071340Signed-off-by: default avatarAndy Grover <agrover@redhat.com>
Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      6ff2fec9
    • H. Peter Anvin's avatar
      x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels · a862b5c4
      H. Peter Anvin authored 
      commit b3b42ac2 upstream.

The IRET instruction, when returning to a 16-bit segment, only
restores the bottom 16 bits of the user space stack pointer.  We have
a software workaround for that ("espfix") for the 32-bit kernel, but
it relies on a nonzero stack segment base which is not available in
32-bit mode.

Since 16-bit support is somewhat crippled anyway on a 64-bit kernel
(no V86 mode), and most (if not quite all) 64-bit processors support
virtualization for the users who really need it, simply reject
attempts at creating a 16-bit segment when running on top of a 64-bit
kernel.

Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
Link: http://lkml.kernel.org/n/tip-kicdm89kzw9lldryb1br9od0@git.kernel.orgSigned-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      a862b5c4
    • Rafał Miłecki's avatar
      b43: Fix machine check error due to improper access of B43_MMIO_PSM_PHY_HDR · 68289dd3
      Rafał Miłecki authored 
      commit 12cd43c6 upstream.

Register B43_MMIO_PSM_PHY_HDR is 16 bit one, so accessing it with 32b
functions isn't safe. On my machine it causes delayed (!) CPU exception:

Disabling lock debugging due to kernel taint
mce: [Hardware Error]: CPU 0: Machine Check Exception: 4 Bank 4: b200000000070f0f
mce: [Hardware Error]: TSC 164083803dc
mce: [Hardware Error]: PROCESSOR 2:20fc2 TIME 1396650505 SOCKET 0 APIC 0 microcode 0
mce: [Hardware Error]: Run the above through 'mcelog --ascii'
mce: [Hardware Error]: Machine check: Processor context corrupt
Kernel panic - not syncing: Fatal machine check on current CPU
Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)
Signed-off-by: default avatarRafał Miłecki <zajec5@gmail.com>
Acked-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      68289dd3
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7