Skip to content

GitLab

Switch branch/tag
  1. 23 Mar, 2011 24 commits
  3. 14 Mar, 2011 16 commits
    • Greg Kroah-Hartman's avatar
      Linux 2.6.37.4 · 97b197f0
      Greg Kroah-Hartman authored
      97b197f0
    • stephen hemminger's avatar
      ip6ip6: autoload ip6 tunnel · a0c904c5
      stephen hemminger authored 
      commit 6dfbd87a

 upstream

ip6ip6: autoload ip6 tunnel

Add necessary alias to autoload ip6ip6 tunnel module.
Signed-off-by: default avatarStephen Hemminger <shemminger@vyatta.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      a0c904c5
    • Olivier Grenie's avatar
      DiB7000M: add pid filtering · c5729162
      Olivier Grenie authored 
      commit e192a7cf upstream.

This patch adds the pid filtering for the dib7000M demod. It also
corrects the pid filtering for the dib7700 based board. It should
prevent an oops, when using dib7700p based board.

References: https://bugzilla.novell.com/show_bug.cgi?id=644807

Signed-off-by: default avatarOlivier Grenie <olivier.grenie@dibcom.fr>
Signed-off-by: default avatarPatrick Boettcher <patrick.boettcher@dibcom.fr>
Tested-by: default avatarPavel SKARKA <paul.sp@seznam.cz>
Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      c5729162
    • Sven Barth's avatar
      cx25840: fix probing of cx2583x chips · e53b53dd
      Sven Barth authored 
      commit 1e6406b8

 upstream.

Fix the probing of cx2583x chips, because two controls were clustered
that are not created for these chips.

This regression was introduced in 2.6.36.
Signed-off-by: default avatarSven Barth <pascaldragon@googlemail.com>
Signed-off-by: default avatarAndy Walls <awalls@md.metrocast.net>
Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      e53b53dd
    • Andy Walls's avatar
      cx23885: Revert "Check for slave nack on all transactions" · c06dc644
      Andy Walls authored 
      commit 67914b5c upstream.

This reverts commit 44835f19

.

With the CX23885 hardware I2C master, checking for I2C slave ACK/NAK
is not valid when the I2C_EXTEND or I2C_NOSTOP bits are set.
Revert the commit that checks for I2C slave ACK/NAK on all transactions,
so that XC5000 tuners work with the CX23885 again.

Thanks go to Mark Zimmerman for reporting and bisecting this problem.
Bisected-by: default avatarMark Zimmerman <markzimm@frii.com>
Reported-by: default avatarMark Zimmerman <markzimm@frii.com>
Signed-off-by: default avatarAndy Walls <awalls@md.metrocast.net>
Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      c06dc644
    • Michael's avatar
      ivtv: Fix corrective action taken upon DMA ERR interrupt to avoid hang · 0ab29c52
      Michael authored 
      commit d213ad08 upstream.

After upgrading the kernel from stock Ubuntu 7.10 to
10.04, with no hardware changes, I started getting the dreaded DMA
TIMEOUT errors, followed by inability to encode until the machine was
rebooted.

I came across a post from Andy in March
(http://www.gossamer-threads.com/lists/ivtv/users/40943#40943

) where he
speculates that perhaps the corrective actions being taken after a DMA
ERROR are not sufficient to recover the situation.  After some testing
I suspect that this is indeed the case, and that in fact the corrective
action may be what hangs the card's DMA engine, rather than the
original error.

Specifically these DMA ERROR IRQs seem to present with two different
values in the IVTV_REG_DMASTATUS register: 0x11 and 0x13.  The current
corrective action is to clear that status register back to 0x01 or
0x03, and then issue the next DMA request.  In the case of a 0x13 this
seems to result in a minor glitch in the encoded stream due to the
failed transfer that was not retried, but otherwise things continue OK.
In the case of a 0x11 the card's DMA write engine is never heard from
again, and a DMA TIMEOUT follows shortly after.  0x11 is the killer.

I suspect that the two cases need to be handled differently.  The
difference is in bit 1 (0x02), which is set when the error is about to
be successfully recovered, and clear when things are about to go bad.

Bit 1 of DMASTATUS is described differently in different places either
as a positive "write finished", or an inverted "write busy".  If we
take the first definition, then when an error arises with state 0x11,
it means that the write did not complete.   It makes sense to start a
new transfer, as in the current code.  But if we take the second
definition, then 0x11 means "an error but the write engine is still
busy".  Trying to feed it a new transfer in this situation might not be
a good idea.

As an experiment, I added code to ignore the DMA ERROR IRQ if DMASTATUS
is 0x11.  I.e., don't start a new transfer, don't clear our flags, etc.
The hope was that the card would complete the transfer and issue a ENC
DMA COMPLETE, either successfully or with an error condition there.
However the card still hung.

The only remaining corrective action being taken with a 0x11 status was
then the write back to the status register to clear the error, i.e.
DMASTATUS = DMASTATUS & ~3.  This would have the effect of clearing the
error bit 4, while leaving the lower bits indicating DMA write busy.

Strangely enough, removing this write to the status register solved the
problem!  If the DMA ERROR IRQ with DMASTATUS=0x11 is completely
ignored, with no corrective action at all, then the card will complete
the transfer and issue a new IRQ.  If the status register is written to
when it has the value 0x11, then the DMA engine hangs.  Perhaps it's
illegal to write to
DMASTATUS while the read or write busy bit is set?  At any rate, it
appears that the current corrective action is indeed making things
worse rather than better.

I put together a patch that modifies ivtv_irq_dma_err to do the
following:

- Don't write back to IVTV_REG_DMASTATUS.
- If write-busy is asserted, leave the card alone.  Just extend the
timeout slightly.
- If write-busy is de-asserted, retry the current transfer.

This has completely fixed my DMA TIMEOUT woes.  DMA ERR events still
occur, but now they seem to be correctly handled.  0x11 events no
longer hang the card, and 0x13 events no longer result in a glitch in
the stream, as the failed transfer is retried.  I'm happy.

I've inlined the patch below in case it is of interest.  As described
above, I have a theory about why it works (based on a different
interpretation of bit 1 of DMASTATUS), but I can't guarantee that my
theory is correct.  There may be another explanation, or it may be a
fluke.  Maybe ignoring that IRQ entirely would be equally effective?
Maybe the status register read/writeback sequence is race condition if
the card changes it in the mean time?  Also as I am using a PVR-150
only, I have not been able to test it on other cards, which may be
especially relevant for 350s that support concurrent decoding.
Hopefully the patch does not break the DMA READ path.

Mike

[awalls@md.metrocast.net: Modified patch to add a verbose comment, make minor
brace reformats, and clear the error flags in the IVTV_REG_DMASTATUS iff both
read and write DMA were not in progress.  Mike's conjecture about a race
condition with the writeback is correct; it can confuse the DMA engine.]

[Comment and analysis from the ML post by Michael <mike@rsy.com>]
Signed-off-by: default avatarAndy Walls <awalls@md.metrocast.net>
Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      0ab29c52
    • Balbir Singh's avatar
      sched: Fix sched rt group scheduling when hierachy is enabled · 4065ec08
      Balbir Singh authored 
      commit 0c3b9168

 upstream.

The current sched rt code is broken when it comes to hierarchical
scheduling, this patch fixes two problems

1. It adds redundant enqueuing (harmless) when it finds a queue
   has tasks enqueued, but it has no run time and it is not
   throttled.

2. The most important change is in sched_rt_rq_enqueue/dequeue.
   The code just picks the rt_rq belonging to the current cpu
   on which the period timer runs, the patch fixes it, so that
   the correct rt_se is enqueued/dequeued.

Tested with a simple hierarchy

/c/d, c and d assigned similar runtimes of 50,000 and a while
1 loop runs within "d". Both c and d get throttled, without
the patch, the task just stops running and never runs (depends
on where the sched_rt b/w timer runs). With the patch, the
task is throttled and runs as expected.

[ bharata, suggestions on how to pick the rt_se belong to the
  rt_rq and correct cpu ]
Signed-off-by: default avatarBalbir Singh <balbir@linux.vnet.ibm.com>
Acked-by: default avatarBharata B Rao <bharata@linux.vnet.ibm.com>
Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <20110303113435.GA2868@balbir.in.ibm.com>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      4065ec08
    • Ivan Vecera's avatar
      drivers/net: Call netif_carrier_off at the end of the probe · fea891e3
      Ivan Vecera authored 
      commit 0d672e9f

 upstream.

Without calling of netif_carrier_off at the end of the probe the operstate
is unknown when the device is initially opened. By default the carrier is
on so when the device is opened and netif_carrier_on is called the link
watch event is not fired and operstate remains zero (unknown).

This patch fixes this behavior in forcedeth and r8169.
Signed-off-by: default avatarIvan Vecera <ivecera@redhat.com>
Acked-by: default avatarFrancois Romieu <romieu@fr.zoreil.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      fea891e3
    • Francois Romieu's avatar
      r8169: prevent RxFIFO induced loops in the irq handler. · 30b7cb31
      Francois Romieu authored 
      commit f60ac8e7

 upstream.

While the RxFIFO interruption is masked for most 8168, nothing prevents
it to appear in the irq status word. This is no excuse to crash.
Signed-off-by: default avatarFrancois Romieu <romieu@fr.zoreil.com>
Cc: Ivan Vecera <ivecera@redhat.com>
Cc: Hayes <hayeswang@realtek.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      30b7cb31
    • Francois Romieu's avatar
      r8169: RxFIFO overflow oddities with 8168 chipsets. · be70b4e2
      Francois Romieu authored 
      commit 1519e57f

 upstream.

Some experiment-based action to prevent my 8168 chipsets locking-up hard
in the irq handler under load (pktgen ~1Mpps). Apparently a reset is not
always mandatory (is it at all ?).

- RTL_GIGA_MAC_VER_12
- RTL_GIGA_MAC_VER_25
  Missed ~55% packets. Note:
  - this is an old SiS 965L motherboard
  - the 8168 chipset emits (lots of) control frames towards the sender

- RTL_GIGA_MAC_VER_26
  The chipset does not go into a frenzy of mac control pause when it
  crashes yet but it can still be crashed. It needs more work.
Signed-off-by: default avatarFrancois Romieu <romieu@fr.zoreil.com>
Cc: Ivan Vecera <ivecera@redhat.com>
Cc: Hayes <hayeswang@realtek.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      be70b4e2
    • Ivan Vecera's avatar
      r8169: use RxFIFO overflow workaround for 8168c chipset. · cb1f3fd3
      Ivan Vecera authored 
      commit b5ba6d12

 upstream.

I found that one of the 8168c chipsets (concretely XID 1c4000c0) starts
generating RxFIFO overflow errors. The result is an infinite loop in
interrupt handler as the RxFIFOOver is handled only for ...MAC_VER_11.
With the workaround everything goes fine.
Signed-off-by: default avatarIvan Vecera <ivecera@redhat.com>
Acked-by: default avatarFrancois Romieu <romieu@fr.zoreil.com>
Cc: Hayes <hayeswang@realtek.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      cb1f3fd3
    • Pablo Neira Ayuso's avatar
      netfilter: arpt_mangle: fix return values of checkentry · 1d328fe9
      Pablo Neira Ayuso authored 
      commit 9d0db8b6 upstream.

In 135367b8

 "netfilter: xtables: change xt_target.checkentry return type",
the type returned by checkentry was changed from boolean to int, but the
return values where not adjusted.

arptables: Input/output error

This broke arptables with the mangle target since it returns true
under success, which is interpreted by xtables as >0, thus
returning EIO.
Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      1d328fe9
    • Vasiliy Kulikov's avatar
      net: don't allow CAP_NET_ADMIN to load non-netdev kernel modules · 8767008a
      Vasiliy Kulikov authored 
      commit 8909c9ad upstream.

Since a8f80e8f any process with
CAP_NET_ADMIN may load any module from /lib/modules/.  This doesn't mean
that CAP_NET_ADMIN is a superset of CAP_SYS_MODULE as modules are
limited to /lib/modules/**.  However, CAP_NET_ADMIN capability shouldn't
allow anybody load any module not related to networking.

This patch restricts an ability of autoloading modules to netdev modules
with explicit aliases.  This fixes CVE-2011-1019.

Arnd Bergmann suggested to leave untouched the old pre-v2.6.32 behavior
of loading netdev modules by name (without any prefix) for processes
with CAP_SYS_MODULE to maintain the compatibility with network scripts
that use autoloading netdev modules by aliases like "eth0", "wlan0".

Currently there are only three users of the feature in the upstream
kernel: ipip, ip_gre and sit.

    root@albatros:~# capsh --drop=$(seq -s, 0 11),$(seq -s, 13 34) --
    root@albatros:~# grep Cap /proc/$$/status
    CapInh:	0000000000000000
    CapPrm:	fffffff800001000
    CapEff:	fffffff800001000
    CapBnd:	fffffff800001000
    root@albatros:~# modprobe xfs
    FATAL: Error inserting xfs
    (/lib/modules/2.6.38-rc6-00001-g2bf4ca3/kernel/fs/xfs/xfs.ko): Operation not permitted
    root@albatros:~# lsmod | grep xfs
    root@albatros:~# ifconfig xfs
    xfs: error fetching interface information: Device not found
    root@albatros:~# lsmod | grep xfs
    root@albatros:~# lsmod | grep sit
    root@albatros:~# ifconfig sit
    sit: error fetching interface information: Device not found
    root@albatros:~# lsmod | grep sit
    root@albatros:~# ifconfig sit0
    sit0      Link encap:IPv6-in-IPv4
	      NOARP  MTU:1480  Metric:1

    root@albatros:~# lsmod | grep sit
    sit                    10457  0
    tunnel4                 2957  1 sit

For CAP_SYS_MODULE module loading is still relaxed:

    root@albatros:~# grep Cap /proc/$$/status
    CapInh:	0000000000000000
    CapPrm:	ffffffffffffffff
    CapEff:	ffffffffffffffff
    CapBnd:	ffffffffffffffff
    root@albatros:~# ifconfig xfs
    xfs: error fetching interface information: Device not found
    root@albatros:~# lsmod | grep xfs
    xfs                   745319  0

Reference: https://lkml.org/lkml/2011/2/24/203

Signed-off-by: default avatarVasiliy Kulikov <segoon@openwall.com>
Signed-off-by: default avatarMichael Tokarev <mjt@tls.msk.ru>
Acked-by: default avatarDavid S. Miller <davem@davemloft.net>
Acked-by: default avatarKees Cook <kees.cook@canonical.com>
Signed-off-by: default avatarJames Morris <jmorris@namei.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      8767008a
    • Julian Anastasov's avatar
      ipvs: fix dst_lock locking on dest update · 46d5660d
      Julian Anastasov authored 
      commit ff75f40f

 upstream.

	Fix dst_lock usage in __ip_vs_update_dest. We need
_bh locking because destination is updated in user context.
Can cause lockups on frequent destination updates.
Problem reported by Simon Kirby. Bug was introduced
in 2.6.37 from the "ipvs: changes for local real server"
change.
Signed-off-by: default avatarJulian Anastasov <ja@ssi.bg>
Signed-off-by: default avatarHans Schillstrom <hans@schillstrom.com>
Signed-off-by: default avatarSimon Horman <horms@verge.net.au>
Cc: Simon Kirby <sim@hostway.ca>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      46d5660d
    • Chuck Lever's avatar
      NFS: NFSv4 readdir loses entries · 73c2a0d9
      Chuck Lever authored 
      commit d1205f87 upstream.

On recent 2.6.38-rc kernels, connectathon basic test 6 fails on
NFSv4 mounts of OpenSolaris with something like:

> ./test6: readdir
> 	./test6: (/mnt/klimt/matisse.test) didn't read expected 'file.12' dir entry, pass 0
> 	./test6: (/mnt/klimt/matisse.test) didn't read expected 'file.82' dir entry, pass 0
> 	./test6: (/mnt/klimt/matisse.test) didn't read expected 'file.164' dir entry, pass 0
> 	./test6: (/mnt/klimt/matisse.test) Test failed with 3 errors
> basic tests failed
> Tests failed, leaving /mnt/klimt mounted
> [cel@matisse cthon04]$

I narrowed the problem down to nfs4_decode_dirent() reporting that the
decode buffer had overflowed while decoding the entries for those
missing files.

verify_attr_len() assumes both it's pointer arguments reside on the
same page.  When these arguments point to locations on two different
pages, verify_attr_len() can report false errors.  This can happen now
that a large NFSv4 readdir result can span pages.

We have reasonably good checking in nfs4_decode_dirent() anyway, so
it should be safe to simply remove the extra checking.

At a guess, this was introduced by commit 6650239a

, "NFS: Don't use
vm_map_ram() in readdir".
Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      73c2a0d9
    • Benjamin Tissoires's avatar
      HID: hid-mosart: ignore buttons report · 1eac7b1d
      Benjamin Tissoires authored 
      commit ad6d4267

 upstream.

This commit allows the device to be recognized as a touchscreen, and not a
touchpad by xf86-input-evdev.

The device has 2 modes. The first one is an emulation of a touchscreen by
sending left and right button, and the second mode is the one used in
dual-touch (sending trackingID, touch and else).

That's why there is a hid report containing left and right buttons
(9000001 and 9000002). The point is that xorg relies on these fields to
determine if it's a touchpad or a touchscreen.
Clearing the report (return -1) makes xorg detecting it out of the box
as a quite pleasant (dual)touchscreen.
Signed-off-by: default avatarBenjamin Tissoires <benjamin.tissoires@enac.fr>
Acked-by: default avatarChase Douglas <chase.douglas@canonical.com>
Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
Cc: James Sharam <james.sharam@googlemail.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      1eac7b1d