| Age | Commit message (Collapse) | Author |
|---|
|
Chocked while compiling linux with dash shell instead of bash
shell. See:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html
Signed-off-by: Sylvain BERTRAND <sylvain.bertrand@gmail.com>
Link: http://lkml.kernel.org/r/20141223123912.GA1386@localhost.localdomain
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
Make sure this fetches 16-bits port data from the register.
Remove casting to make sparse happy, not needed anymore.
Signed-off-by: leroy christophe <christophe.leroy@c-s.fr>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
When allocating space for load_balance_mask, in sched_init, when
CPUMASK_OFFSTACK is set, we've managed to spill over
KMALLOC_MAX_SIZE on our 6144 core machine. The patch below
breaks up the allocations so that they don't overflow the max
alloc size. It also allocates the masks on the the node from
which they'll most commonly be accessed, to minimize remote
accesses on NUMA machines.
Suggested-by: George Beshers <gbeshers@sgi.com>
Signed-off-by: Alex Thorlton <athorlton@sgi.com>
Cc: George Beshers <gbeshers@sgi.com>
Cc: Russ Anderson <rja@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/1418928270-148543-1-git-send-email-athorlton@sgi.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
The old scheme can lead to failure in certain cases - the
problem is that after bumping step_size the next (non-final)
iteration is only guaranteed to make available a memory block
the size of what step_size was before. E.g. for a memory block
[0,3004600000) we'd have:
iter start end step amount
1 3004400000 30045fffff 2M 2M
2 3004000000 30043fffff 64M 4M
3 3000000000 3003ffffff 2G 64M
4 2000000000 2fffffffff 64G 64G
Yet to map 64G with 4k pages (as happens e.g. under PV Xen) we
need slightly over 128M, but the first three iterations made
only about 70M available.
The condition (new_mapped_ram_size > mapped_ram_size) for
bumping step_size is just not suitable. Instead we want to bump
it when we know we have enough memory available to cover a block
of the new step_size. And rather than making that condition more
complicated than needed, simply adjust step_size by the largest
possible factor we know we can cover at that point - which is
shifting it left by one less than the difference between page
table level shifts. (Interestingly the original STEP_SIZE_SHIFT
definition had a comment hinting at that having been the
intention, just that it should have been PUD_SHIFT-PMD_SHIFT-1
instead of (PUD_SHIFT-PMD_SHIFT)/2, and of course for non-PAE
32-bit we can't really use these two constants as they're equal
there.)
Furthermore the comment in get_new_step_size() didn't get
updated when the bottom-down mapping logic got added. Yet while
an overflow (flushing step_size to zero) of the shift doesn't
matter for the top-down method, it does for bottom-up because
round_up(x, 0) = 0, and an upper range boundary of zero can't
really work well.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Link: http://lkml.kernel.org/r/54945C1E020000780005114E@mail.emea.novell.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
There is no reason for having it and, with commit 250a1ac685f1 ("x86,
smpboot: Remove pointless preempt_disable() in
native_smp_prepare_cpus()"), it prevents HVM guests from booting.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
|
|
Prior to DRA74x silicon rev 1.1, pcie_pcs register bits 8-15 and bits 16-23
were used to configure RC delay count for phy1 and phy2 respectively.
phyid was used as index to distinguish the phys and to configure the delay
values appropriately.
As of DRA74x silicon rev 1.1, pcie_pcs register definition has changed.
Bits 16-23 are used to configure delay values for *both* phy1 and phy2.
Hence phyid is no longer required.
So, drop id field from ti_pipe3 structure and its subsequent references
for configuring pcie_pcs register.
Also, pcie_pcs register now needs to be configured with delay value of 0x96
at bit positions 16-23. See register description of CTRL_CORE_PCIE_PCS in
ARM572x TRM, SPRUHZ6, October 2014, section 18.5.2.2, table 18-1804.
This is needed to ensure Gen2 cards are enumerated consistently.
DRA72x silicon behaves same way as DRA74x rev 1.1 as far as this functionality
is considered.
Test results on DRA74x and DRA72x EVMs:
Before patch
------------
DRA74x ES 1.0: Gen1 cards work, Gen2 cards do not work (expected result due to
silicon errata)
DRA74x ES 1.1: Gen1 cards work, Gen2 cards do not work sometimes due to incorrect
programming of register
DRA72x: Gen1 cards work, Gen2 cards do not work sometimes due to incorrect
programming of register
After patch
-----------
DRA74x ES 1.0: Gen1 cards work, Gen2 cards do not work (expected result due to
silicon errata)
DRA74x ES 1.1: Gen1 cards work, Gen2 cards work consistently.
DRA72x: Gen1 and Gen2 cards enumerate consistently.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
|
|
The allwinner SDK uses a value of 3 for the disconnect threshold setting on
sun6i, do the same in the kernel.
In my previous experience with sun5i problems getting the threshold right
is important to avoid usb2 devices being unplugged sometimes going unnoticed.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
|
|
We need to unlock before returning the -EINVAL here.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Gabriel Fernandez <gabriel.fernandez@linaro.org>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
|
|
- Remove soon-to-be-dead @redhat address.
- Jeff Hartmann wrote the bulk of the original backend code, and should
at least get a mention in the MODULE_AUTHOR for backend.o
- Various people at Intel have done a lot more work than myself on the
intel-* drivers, so again, mention that.
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux into core/urgent
Pull a liblockdep fix from Sasha Levin:
"A small (but important) fix to the way we detect freeing live locks. We would
pass a wrong memory region when testing for locks inside freed memory spaces,
which would trigger false positives."
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
Pull device mapper fixes from Mike Snitzer:
"Thre stable fixes and one fix for a regression introduced during 3.19
merge:
- Fix inability to discard used space when the thin-pool target is in
out-of-data-space mode and also transition the thin-pool back to
write mode once free space is made available.
- Fix DM core bio-based end_io bug that prevented proper
post-processing of the error code returned from the block layer.
- Fix crash in DM thin-pool due to thin device being added to the
pool's active_thins list before properly initializing the thin
device's refcount"
* tag 'dm-3.19-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
dm: fix missed error code if .end_io isn't implemented by target_type
dm thin: fix crash by initializing thin device's refcount and completion earlier
dm thin: fix missing out-of-data-space to write mode transition if blocks are released
dm thin: fix inability to discard blocks when in out-of-data-space mode
|
|
This reverts commit c8475d144abb1e62958cc5ec281d2a9e161c1946.
There are several[1][2] of bug reports which points to this commit as potential
cause[3].
Let's revert it until we figure out what's going on.
[1] https://lkml.org/lkml/2014/11/14/342
[2] https://lkml.org/lkml/2014/12/22/213
[3] https://lkml.org/lkml/2014/12/9/741
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Acked-by: Davidlohr Bueso <dave@stgolabs.net>
Cc: Hugh Dickins <hughd@google.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: Mel Gorman <mgorman@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
git://people.freedesktop.org/~tagr/linux into drm-fixes
drm/tegra: Fixes for v3.19-rc1
This is a set of fixes for two regressions and one bug in the IOMMU
mapping code. It turns out that all of these issues turn up primarily
on Tegra30 hardware. The IOMMU mapping bug only manifests on buffers
that aren't multiples of the page size. I happened to be testing HDMI
with 1080p while writing the code and framebuffers for that happen to
fit exactly within 2025 pages of 4 KiB each.
One of the regressions is caused by the IOMMU code allocating pages from
shmem which can have associated cache lines. If the pages aren't flushed
then these cache lines may be flushed later on and cause framebuffer
corruption. I'm not sure why I didn't see this before. Perhaps the board
that I was using had enough RAM so that the pages shmem would hand out
had a better chance of being unused. Or maybe I didn't look too closely.
The fix for this is to fake up an SG table so that it can be passed to
the DMA API. Ideally this would use drm_clflush_*(), but implementing
that for ARM causes DRM to fail to build as a module since some of the
low-level cache maintenance functions aren't exported. Hopefully we can
get a suitable API exported on ARM for the next release.
The second regression is caused by a mismatch between the hardware pipe
number and the CRTC's DRM index. These were used inconsistently, which
could cause one code location to call drm_vblank_get() with a different
pipe than the corresponding drm_vblank_put(), thereby causing the
reference count to become unbalanced. Alexandre also reported a possible
race condition related to this, which this series also fixes.
* tag 'drm/tegra/for-3.19-rc1-fixes' of git://people.freedesktop.org/~tagr/linux:
drm/tegra: dc: Select root window for event dispatch
drm/tegra: gem: Use the proper size for GEM objects
drm/tegra: gem: Flush buffer objects upon allocation
drm/tegra: dc: Fix a potential race on page-flip completion
drm/tegra: dc: Consistently use the same pipe
drm/irq: Add drm_crtc_vblank_count()
drm/irq: Add drm_crtc_handle_vblank()
drm/irq: Add drm_crtc_send_vblank_event()
|
|
git://anongit.freedesktop.org/drm-intel into drm-fixes
misc i915 fixes.
* tag 'drm-intel-next-fixes-2014-12-17' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Disable PSMI sleep messages on all rings around context switches
drm/i915: Force the CS stall for invalidate flushes
drm/i915: Invalidate media caches on gen7
drm/i915: sanitize RPS resetting during GPU reset
drm/i915: move RPS PM_IER enabling to gen6_enable_rps_interrupts
drm/i915: vlv: fix IRQ masking when uninstalling interrupts
|
|
git://anongit.freedesktop.org/drm-intel into drm-fixes
Yeah a pull for one patch is a bit overkill but I started to assemble the
various patches for 3.20 in a branch for atomic props/ioctl and didn't
realize that this bugfix here at the beginnning of the branch should be in
3.19 (because msm is using the helpers arleady). So if you'd merge we'd
have it twice or or I need to shuffle branches again. Can do if you want.
* tag 'topic/atomic-fixes-2014-12-17' of git://anongit.freedesktop.org/drm-intel:
drm/atomic: fix potential null ptr on plane enable
|
|
git://people.freedesktop.org/~robclark/linux into drm-fixes
A few msm fixes for 3.19:
* hdmi regulators fix
* hdmi fix for spurious HPD interrupts
* fix for sync atomic update after async update (which could show
up with a setcrtc following a pageflip)
* couple little Coccinelle cleanups
* 'msm-fixes-3.19' of git://people.freedesktop.org/~robclark/linux:
drm/msm/hdmi: rework HDMI IRQ handler
drm/msm/hdmi: enable regulators before clocks to avoid warnings
drm/msm/mdp5: update irqs on crtc<->encoder link change
drm/msm: block incoming update on pending updates
drm/msm: Deletion of unnecessary checks before the function call "release_firmware"
drm/msm: Deletion of unnecessary checks before two function calls
|
|
nouveau userspace back at 1.0.1 used to call the X server
DRIOpenDRMMaster interface even for DRI2 (doh!), this attempts
to map the sarea and fails if it can't.
Since 884c6dabb0eafe7227f099c9e78e514191efaf13 from Daniel,
this fails, but only ancient drivers would see it.
Revert the nouveau bits of that fix.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: <stable@vger.kernel.org> # 3.18
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Several Samsung laptop models (SAMSUNG 870Z5E/880Z5E/680Z5E and
SAMSUNG 370R4E/370R4V/370R5E/3570RE/370R5V) do not have a working
native backlight control interface so restore their acpi_videoX
interface.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=84221
Link: https://bugzilla.kernel.org/show_bug.cgi?id=84651
For SAMSUNG 870Z5E/880Z5E/680Z5E:
Reported-and-tested-by: Brent Saner <brent.saner@gmail.com>
Reported-by: Vitaliy Filippov <vitalif@yourcmc.ru>
Reported-by: Laszlo KREKACS <laszlo.krekacs.list@gmail.com>
For SAMSUNG 370R4E/370R4V/370R5E/3570RE/370R5V:
Reported-by: Vladimir Perepechin <vovochka13@gmail.com>
Cc: 3.17+ <stable@vger.kernel.org> # 3.17+
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
When xfrm6_policy_check() is used, _decode_session6() is called after some
intermediate functions. This function uses IP6CB(), thus TCP_SKB_CB() must be
prepared after the call of xfrm6_policy_check().
Before this patch, scenarii with IPv6 + TCP + IPsec Transport are broken.
Fixes: 971f10eca186 ("tcp: better TCP_SKB_CB layout to reduce cache line misses")
Reported-by: Huaibin Wang <huaibin.wang@6wind.com>
Suggested-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Decode and display Port Type and Module Type for ethtool get_settings() call
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The commit d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less
interrupt masking in NAPI) breaks caif.
It is now required that if the entire budget is consumed when poll
returns, the napi poll_list must remain empty. However, like some
other drivers caif tries to do a last-ditch check and if there is
more work it will call napi_schedule and then immediately process
some of this new work. Should the entire budget be consumed while
processing such new work then we will violate the new caller
contract.
This patch fixes this by not touching any work when we reschedule
in caif.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
iowrite32() will byteswap it's argument on big endian archs.
iowrite32be() will byteswap on little endian archs.
Since we don't want to do this unnecessary byteswap on the fast path,
doorbell is stored in the NIC's native endianness. Using the right
iowrite() according to the arch endianness.
CC: Wei Yang <weiyang@linux.vnet.ibm.com>
CC: David Laight <david.laight@aculab.com>
Fixes: 6a4e812 ("net/mlx4_en: Avoid calling bswap in tx fast path")
Signed-off-by: Amir Vadai <amirv@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
For linux-3.18.0
The driver lacks netif_napi_del in the normal path and error path
to match the call of netif_napi_add in rtl8139_init_one.
This patch fixes this problem.
Signed-off-by: Jia-Ju Bai <baijiaju1990@163.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
For linux-3.18.0
When pci_request_regions is failed in rtl8139_init_board, pci_disable_device
is not called to disable the device which are enabled by pci_enable_device,
because of disable_dev_on_err is not assigned 1.
This patch fix this problem.
Signed-off-by: Jia-Ju Bai <baijiaju1990@163.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This platform_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The s6000 Xtensa support has been removed from the kernel in
4006e565e1500db4. There are no other chips using this driver.
While the Mentor/Alcatel PE-MCXMAC IP core is also used in other
designs (Freescale Gianfar/UCC, QLogic NetXen, Solarflare, Agere
ET-1310, Netlogic XLR/XLS), none of these use this driver as it
heavily depends on the s6000 DMA engine. In fact, there is no
code sharing across any of the aforementioned devices.
Signed-off-by: Daniel Glöckner <dg@emlix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Remove the function port_cfg_dis_learn() that is not used anywhere.
This was partially found by using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
During driver load in tg3_init_one, if the driver detects DMA activity before
intializing the chip tg3_halt is called. As part of tg3_halt interrupts are
disabled using routine tg3_disable_ints. This routine was using mailbox value
which was not initialized (default value is 0). As a result driver was writing
0x00000001 to pci config space register 0, which is the vendor id / device id.
This driver bug was exposed because of the commit a7877b17a667 (PCI: Check only
the Vendor ID to identify Configuration Request Retry). Also this issue is only
seen in older generation chipsets like 5722 because config space write to offset
0 from driver is possible. The newer generation chips ignore writes to offset 0.
Also without commit a7877b17a667, for these older chips when a GRC reset is
issued the Bootcode would reprogram the vendor id/device id, which is the reason
this bug was masked earlier.
Fixed by initializing the interrupt mailbox registers before calling tg3_halt.
Please queue for -stable.
Reported-by: Nils Holland <nholland@tisys.org>
Reported-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: Prashant Sreedharan <prashant@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Resolve conflicts between glibc definition of IPV6 socket options
and those defined in Linux headers. Looks like earlier efforts to
solve this did not cover all the definitions.
It resolves warnings during iproute2 build.
Please consider for stable as well.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The changed names are union fields with the same size, so the existing code
still works. But, we now update these variables to the correct names.
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The commit d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less
interrupt masking in NAPI) breaks virtio_net in an insidious way.
It is now required that if the entire budget is consumed when poll
returns, the napi poll_list must remain empty. However, like some
other drivers virtio_net tries to do a last-ditch check and if
there is more work it will call napi_schedule and then immediately
process some of this new work. Should the entire budget be consumed
while processing such new work then we will violate the new caller
contract.
This patch fixes this by not touching any work when we reschedule
in virtio_net.
The worst part of this bug is that the list corruption causes other
napi users to be moved off-list. In my case I was chasing a stall
in IPsec (IPsec uses netif_rx) and I only belatedly realised that it
was virtio_net which caused the stall even though the virtio_net
poll was still functioning perfectly after IPsec stalled.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Both stmmac_open() and stmmac_resume() call stmmac_hw_setup(), and
stmmac_hw_setup() call stmmac_init_ptp() unconditionally. However, only
stmmac_release() calls stmmac_release_ptp(). Since stmmac_suspend()
doesn't call stmmac_release_ptp(), stmmac_resume() also needn't call
stmmac_init_ptp().
This patch also fix a "scheduling while atomic" problem when resume
from suspend/hibernation. Because stmmac_init_ptp() will trigger
scheduling while stmmac_resume() hold a spinlock.
Callgraph of "scheduling while atomic":
stmmac_resume() --> stmmac_hw_setup() --> stmmac_init_ptp() -->
stmmac_ptp_register() --> ptp_clock_register() --> device_create() -->
device_create_groups_vargs() --> device_add() --> devtmpfs_create_node()
--> wait_for_common() --> schedule_timeout() --> __schedule()
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
every packet
Make TPACKET_V3 signal poll when block is closed rather than for every
packet. Side effect is that poll will be signaled when block retire
timer expires which didn't previously happen. Issue was visible when
sending packets at a very low frequency such that all blocks are retired
before packets are received by TPACKET_V3. This caused avoidable packet
loss. The fix ensures that the signal is sent when blocks are closed
which covers the normal path where the block is filled as well as the
path where the timer expires. The case where a block is filled without
moving to the next block (ie. all blocks are full) will still cause poll
to be signaled.
Signed-off-by: Dan Collins <dan@dcollins.co.nz>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
In spite of different file type,
if file is same name and same inode number, old inode cache is used.
This causes that you can not cd directory, can not cat SymbolicLink.
So this patch is that if file type is different, return error.
Reproducible sample :
1. create file 'a' at cifs client.
2. repeat rm and mkdir 'a' 4 times at server, then direcotry 'a' having same inode number is created.
(Repeat 4 times, then same inode number is recycled.)
(When server is under RHEL 6.6, 1 time is O.K. Always same inode number is recycled.)
3. ls -li at client, then you can not cd directory, can not remove directory.
SymbolicLink has same problem.
Bug link:
https://bugzilla.kernel.org/show_bug.cgi?id=90011
Signed-off-by: Nakajima Akira <nakajima.akira@nttcom.co.jp>
Acked-by: Jeff Layton <jlayton@primarydata.com>
Signed-off-by: Steve French <steve.french@primarydata.com>
|
|
Sets the vector to an invalid value after it's freed so we don't free
it twice.
Signed-off-by: Keith Busch <keith.busch@intel.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
|
|
On 32-bit:
execveat.c: In function 'check_execveat_pathmax':
execveat.c:183: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'size_t'
execveat.c:187: warning: format '%lu' expects type 'long unsigned int', but argument 2 has type 'size_t'
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
|
|
It is recommended that the SPFI controller be enabled (i.e. setting
SPFI_EN in SPFI_CONTROL) before TX DMA begins.
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
There is a problem with the audit system when multiple audit records
are created for the same path, each with a different path name type.
The root cause of the problem is in __audit_inode() when an exact
match (both the path name and path name type) is not found for a
path name record; the existing code creates a new path name record,
but it never sets the path name in this record, leaving it NULL.
This patch corrects this problem by assigning the path name to these
newly created records.
There are many ways to reproduce this problem, but one of the
easiest is the following (assuming auditd is running):
# mkdir /root/tmp/test
# touch /root/tmp/test/567
# auditctl -a always,exit -F dir=/root/tmp/test
# touch /root/tmp/test/567
Afterwards, or while the commands above are running, check the audit
log and pay special attention to the PATH records. A faulty kernel
will display something like the following for the file creation:
type=SYSCALL msg=audit(1416957442.025:93): arch=c000003e syscall=2
success=yes exit=3 ... comm="touch" exe="/usr/bin/touch"
type=CWD msg=audit(1416957442.025:93): cwd="/root/tmp"
type=PATH msg=audit(1416957442.025:93): item=0 name="test/"
inode=401409 ... nametype=PARENT
type=PATH msg=audit(1416957442.025:93): item=1 name=(null)
inode=393804 ... nametype=NORMAL
type=PATH msg=audit(1416957442.025:93): item=2 name=(null)
inode=393804 ... nametype=NORMAL
While a patched kernel will show the following:
type=SYSCALL msg=audit(1416955786.566:89): arch=c000003e syscall=2
success=yes exit=3 ... comm="touch" exe="/usr/bin/touch"
type=CWD msg=audit(1416955786.566:89): cwd="/root/tmp"
type=PATH msg=audit(1416955786.566:89): item=0 name="test/"
inode=401409 ... nametype=PARENT
type=PATH msg=audit(1416955786.566:89): item=1 name="test/567"
inode=393804 ... nametype=NORMAL
This issue was brought up by a number of people, but special credit
should go to hujianyang@huawei.com for reporting the problem along
with an explanation of the problem and a patch. While the original
patch did have some problems (see the archive link below), it did
demonstrate the problem and helped kickstart the fix presented here.
* https://lkml.org/lkml/2014/9/5/66
Reported-by: hujianyang <hujianyang@huawei.com>
Signed-off-by: Paul Moore <pmoore@redhat.com>
Acked-by: Richard Guy Briggs <rgb@redhat.com>
|
|
When receive data, the RXRDY in status register set by hardware
after a new packet has been stored in the endpoint FIFO. When it
is copied from FIFO, this bit is cleared which make the FIFO can
be accessed again.
In the receive_data() function, this bit RXRDY has been cleared.
So, after the receive_data() function return, this bit should
not be cleared again, or else it may cause the accessing FIFO
corrupt, which will make the data loss.
Fixes: 914a3f3b3754 (USB: add atmel_usba_udc driver)
Cc: <stable@vger.kernel.org> # 2.6.24+
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Bo Shen <voice.shen@atmel.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
According to the datasheet, when transfer using DMA, the control
setting for IN packet only need END_BUF_EN, END_BUF_IE, CH_EN,
while for OUT packet, need more two bits END_TR_EN and END_TR_IE
to be configured.
Fixes: 914a3f3b3754 (USB: add atmel_usba_udc driver)
Cc: <stable@vger.kernel.org> # 2.6.24+
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Bo Shen <voice.shen@atmel.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Add PCI IDs for Intel Sunrise Point PCH.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Commit 3b74c73f8d6f053f422e85fce955b61fb181cfe7 switched over to memdup_user()
in ep_write() function and removed kfree (kbuf).
memdup_user() function allocates memory which is never freed.
Fixes: 3b74c73 (usb: gadget: inode: switch over to memdup_user())
Cc: <stable@vger.kernel.org> # v3.15+
Signed-off-by: Mario Schuknecht <mario.schuknecht@dresearch-fe.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
since the split of host+gadget mode in commit 74c2e9360058 ("usb: musb:
factor out hcd initalization") we leak the usb_hcd struct. We call now
musb_host_cleanup() which does basically usb_remove_hcd() and also sets
the hcd variable to NULL. Doing so makes the finall call to
musb_host_free() basically a nop and the usb_hcd remains around for ever
without anowner.
This patch drops that NULL assignment for that reason.
Fixes: 74c2e9360058 ("usb: musb: factor out hcd initalization")
Cc: <stable@vger.kernel.org> # v3.11+
Cc: Daniel Mack <zonque@gmail.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
This makes us sure that all requests are completed before we unbind
gadget. There are assumptions in gadget API that all requests have to
be completed and leak of complete can break some usb function drivers.
For example unbind of ECM function can cause NULL pointer dereference:
[ 26.396595] configfs-gadget gadget: unbind function
'cdc_ethernet'/e79c4c00
[ 26.414999] Unable to handle kernel NULL pointer dereference at
virtual address 00000000
(...)
[ 26.452223] PC is at ecm_unbind+0x6c/0x9c
[ 26.456209] LR is at ecm_unbind+0x68/0x9c
(...)
[ 26.603696] [<c033fdb4>] (ecm_unbind) from [<c033661c>]
(purge_configs_funcs+0x94/0xd8)
[ 26.611674] [<c033661c>] (purge_configs_funcs) from [<c0336674>]
(configfs_composite_unbind+0x14/0x34)
[ 26.620961] [<c0336674>] (configfs_composite_unbind) from
[<c0337124>] (usb_gadget_remove_driver+0x68/0x9c)
[ 26.630683] [<c0337124>] (usb_gadget_remove_driver) from [<c03376c8>]
(usb_gadget_unregister_driver+0x64/0x94)
[ 26.640664] [<c03376c8>] (usb_gadget_unregister_driver) from
[<c0336be8>] (unregister_gadget+0x20/0x3c)
[ 26.650038] [<c0336be8>] (unregister_gadget) from [<c0336c84>]
(gadget_dev_desc_UDC_store+0x80/0xb8)
[ 26.659152] [<c0336c84>] (gadget_dev_desc_UDC_store) from
[<c0335120>] (gadget_info_attr_store+0x1c/0x28)
[ 26.668703] [<c0335120>] (gadget_info_attr_store) from [<c012135c>]
(configfs_write_file+0xe8/0x148)
[ 26.677818] [<c012135c>] (configfs_write_file) from [<c00c8dd4>]
(vfs_write+0xb0/0x1a0)
[ 26.685801] [<c00c8dd4>] (vfs_write) from [<c00c91b8>]
(SyS_write+0x44/0x84)
[ 26.692834] [<c00c91b8>] (SyS_write) from [<c000e560>]
(ret_fast_syscall+0x0/0x30)
[ 26.700381] Code: e30409f8 e34c0069 eb07b88d e59430a8 (e5930000)
[ 26.706485] ---[ end trace f62a082b323838a2 ]---
It's because in some cases request is still running on endpoint during
unbind and kill_all_requests() called from s3c_hsotg_udc_stop() function
doesn't cause call of complete() of request. Missing complete() call
causes ecm->notify_req equals NULL in ecm_unbind() function, and this
is reason of this bug.
Similar breaks can be observed in another usb function drivers.
This patch fixes this bug forcing usb request completion in when
s3c_hsotg_ep_disable() is called from s3c_hsotg_udc_stop().
Acked-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Replace a misspelled function name by %s and then __func__.
This was done using Coccinelle, including the use of Levenshtein distance,
as proposed by Rasmus Villemoes.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Commit 82c02f58ba3a ("usb: musb: Allow multiple glue layers to be
built in") enabled selecting multiple glue layers, which in turn
exposed things more for randconfig builds. If NOP_USB_XCEIV is
built-in and TUSB6010 is a loadable module, we will get:
drivers/built-in.o: In function `tusb_remove':
tusb6010.c:(.text+0x16a817): undefined reference to `usb_phy_generic_unregister'
drivers/built-in.o: In function `tusb_probe':
tusb6010.c:(.text+0x16b24e): undefined reference to `usb_phy_generic_register'
make: *** [vmlinux] Error 1
Let's fix this the same way as commit 70c1ff4b3c86 ("usb: musb:
tusb-dma can't be built-in if tusb is not").
And while at it, let's not allow selecting the glue layers except
on platforms really using them unless COMPILE_TEST is specified:
- TUSB6010 is in practise only used on omaps
- DSPS is only used on TI platforms
- UX500 is only used on STE platforms
Cc: Linus Walleij <linus.walleij@linaro.org>
Reported-by: Jim Davis <jim.epost@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
At f_audio_free_inst, it tries to access struct gaudio *card which is
freed at f_audio_free, it causes below oops if the audio device is not
there (do unload module may trigger the same problem). The gaudio_cleanup
is related to function, so it is better move to f_audio_free.
root@freescale ~$ modprobe g_audio
[ 751.968931] g_audio gadget: unable to open sound control device file: /dev/snd/controlC0
[ 751.977134] g_audio gadget: we need at least one control device
[ 751.988633] Unable to handle kernel paging request at virtual address 455f448e
[ 751.995963] pgd = bd42c000
[ 751.998681] [455f448e] *pgd=00000000
[ 752.002383] Internal error: Oops: 5 [#1] SMP ARM
[ 752.007008] Modules linked in: usb_f_uac1 g_audio(+) usb_f_mass_storage libcomposite configfs [last unloaded: g_mass_storage]
[ 752.018427] CPU: 0 PID: 692 Comm: modprobe Not tainted 3.18.0-rc4-00345-g842f57b #10
[ 752.026176] task: bdb3ba80 ti: bd41a000 task.ti: bd41a000
[ 752.031590] PC is at filp_close+0xc/0x84
[ 752.035530] LR is at gaudio_cleanup+0x28/0x54 [usb_f_uac1]
[ 752.041023] pc : [<800ec94c>] lr : [<7f03c63c>] psr: 20000013
[ 752.041023] sp : bd41bcc8 ip : bd41bce8 fp : bd41bce4
[ 752.052504] r10: 7f036234 r9 : 7f036220 r8 : 7f036500
[ 752.057732] r7 : bd456480 r6 : 7f036500 r5 : 7f03626c r4 : bd441000
[ 752.064264] r3 : 7f03b3dc r2 : 7f03cab0 r1 : 00000000 r0 : 455f4456
[ 752.070798] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 752.077938] Control: 10c5387d Table: bd42c04a DAC: 00000015
[ 752.083688] Process modprobe (pid: 692, stack limit = 0xbd41a240)
[ 752.089786] Stack: (0xbd41bcc8 to 0xbd41c000)
[ 752.094152] bcc0: 7f03b3dc bd441000 7f03626c 7f036500 bd41bcfc bd41bce8
[ 752.102337] bce0: 7f03c63c 800ec94c 7f03b3dc bdaa6b00 bd41bd14 bd41bd00 7f03b3f4 7f03c620
[ 752.110521] bd00: 7f03b3dc 7f03cbd4 bd41bd2c bd41bd18 7f00f88c 7f03b3e8 00000000 fffffffe
[ 752.118705] bd20: bd41bd5c bd41bd30 7f0380d8 7f00f874 7f038000 bd456480 7f036364 be392240
[ 752.126889] bd40: 00000000 7f00f620 7f00f638 bd41a008 bd41bd94 bd41bd60 7f00f6d4 7f03800c
[ 752.135073] bd60: 00000001 00000000 8047438c be3a4000 7f036364 7f036364 7f00db28 7f00f620
[ 752.143257] bd80: 7f00f638 bd41a008 bd41bdb4 bd41bd98 804742ac 7f00f644 00000000 809adde0
[ 752.151442] bda0: 7f036364 7f036364 bd41bdcc bd41bdb8 804743c8 80474284 7f03633c 7f036200
[ 752.159626] bdc0: bd41bdf4 bd41bdd0 7f00d5b4 8047435c bd41a000 80974060 7f038158 00000000
[ 752.167811] bde0: 80974060 bdaa9940 bd41be04 bd41bdf8 7f03816c 7f00d518 bd41be8c bd41be08
[ 752.175995] be00: 80008a5c 7f038164 be001f00 7f0363c4 bd41bf48 00000000 bd41be54 bd41be28
[ 752.184179] be20: 800e9498 800e8e74 00000002 00000003 bd4129c0 c0a07000 00000001 7f0363c4
[ 752.192363] be40: bd41bf48 00000000 bd41be74 bd41be58 800de780 800e9320 bd41a000 7f0363d0
[ 752.200547] be60: 00000000 bd41a000 7f0363d0 00000000 bd41beec 7f0363c4 bd41bf48 00000000
[ 752.208731] be80: bd41bf44 bd41be90 80093e54 800089e0 ffff8000 00007fff 80091390 0000065f
[ 752.216915] bea0: 00000000 c0a0834c bd41bf7c 00000086 bd41bf50 00000000 7f03651c 00000086
[ 752.225099] bec0: bd41a010 00c28758 800ddcc4 800ddae0 000000d2 bd412a00 bd41bf24 00000000
[ 752.233283] bee0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 752.241467] bf00: 00000000 00000000 00000000 00000000 00000000 00000000 bd41bf44 000025b0
[ 752.249651] bf20: 00c28a08 00c28758 00000080 8000edc4 bd41a000 00000000 bd41bfa4 bd41bf48
[ 752.257835] bf40: 800943e4 800932ec c0a07000 000025b0 c0a07f8c c0a07ea4 c0a08e5c 0000051c
[ 752.266019] bf60: 0000088c 00000000 00000000 00000000 00000018 00000019 00000010 0000000b
[ 752.274203] bf80: 00000009 00000000 00000000 000025b0 00000000 00c28758 00000000 bd41bfa8
[ 752.282387] bfa0: 8000ec00 8009430c 000025b0 00000000 00c28a08 000025b0 00c28758 00c28980
[ 752.290571] bfc0: 000025b0 00000000 00c28758 00000080 000a6a78 00000007 00c28718 00c28980
[ 752.298756] bfe0: 7ebc1af0 7ebc1ae0 0001a32c 76e9c490 60000010 00c28a08 22013510 ecebffff
[ 752.306933] Backtrace:
[ 752.309414] [<800ec940>] (filp_close) from [<7f03c63c>] (gaudio_cleanup+0x28/0x54 [usb_f_uac1])
[ 752.318115] r6:7f036500 r5:7f03626c r4:bd441000 r3:7f03b3dc
[ 752.323851] [<7f03c614>] (gaudio_cleanup [usb_f_uac1]) from [<7f03b3f4>] (f_audio_free_inst+0x18/0x68 [usb_f_uac1])
[ 752.334288] r4:bdaa6b00 r3:7f03b3dc
[ 752.337931] [<7f03b3dc>] (f_audio_free_inst [usb_f_uac1]) from [<7f00f88c>] (usb_put_function_instance+0x24/0x30 [libcomposite])
[ 752.349498] r4:7f03cbd4 r3:7f03b3dc
[ 752.353127] [<7f00f868>] (usb_put_function_instance [libcomposite]) from [<7f0380d8>] (audio_bind+0xd8/0xfc [g_audio])
[ 752.363824] r4:fffffffe r3:00000000
[ 752.367456] [<7f038000>] (audio_bind [g_audio]) from [<7f00f6d4>] (composite_bind+0x9c/0x1e8 [libcomposite])
[ 752.377284] r10:bd41a008 r9:7f00f638 r8:7f00f620 r7:00000000 r6:be392240 r5:7f036364
[ 752.385193] r4:bd456480 r3:7f038000
[ 752.388825] [<7f00f638>] (composite_bind [libcomposite]) from [<804742ac>] (udc_bind_to_driver+0x34/0xd8)
[ 752.398394] r10:bd41a008 r9:7f00f638 r8:7f00f620 r7:7f00db28 r6:7f036364 r5:7f036364
[ 752.406302] r4:be3a4000
[ 752.408860] [<80474278>] (udc_bind_to_driver) from [<804743c8>] (usb_gadget_probe_driver+0x78/0xa8)
[ 752.417908] r6:7f036364 r5:7f036364 r4:809adde0 r3:00000000
[ 752.423649] [<80474350>] (usb_gadget_probe_driver) from [<7f00d5b4>] (usb_composite_probe+0xa8/0xd4 [libcomposite])
[ 752.434086] r5:7f036200 r4:7f03633c
[ 752.437713] [<7f00d50c>] (usb_composite_probe [libcomposite]) from [<7f03816c>] (audio_driver_init+0x14/0x1c [g_audio])
[ 752.448498] r9:bdaa9940 r8:80974060 r7:00000000 r6:7f038158 r5:80974060 r4:bd41a000
[ 752.456330] [<7f038158>] (audio_driver_init [g_audio]) from [<80008a5c>] (do_one_initcall+0x88/0x1d4)
[ 752.465564] [<800089d4>] (do_one_initcall) from [<80093e54>] (load_module+0xb74/0x1020)
[ 752.473571] r10:00000000 r9:bd41bf48 r8:7f0363c4 r7:bd41beec r6:00000000 r5:7f0363d0
[ 752.481478] r4:bd41a000
[ 752.484037] [<800932e0>] (load_module) from [<800943e4>] (SyS_init_module+0xe4/0xf8)
[ 752.491781] r10:00000000 r9:bd41a000 r8:8000edc4 r7:00000080 r6:00c28758 r5:00c28a08
[ 752.499689] r4:000025b0
[ 752.502252] [<80094300>] (SyS_init_module) from [<8000ec00>] (ret_fast_syscall+0x0/0x48)
[ 752.510345] r6:00c28758 r5:00000000 r4:000025b0
[ 752.515013] Code: 808475b4 e1a0c00d e92dd878 e24cb004 (e5904038)
[ 752.521223] ---[ end trace 70babe34de4ab99b ]---
Segmentation fault
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
!strncmp(buf, "force host", 9) is true if and only if buf starts with
"force hos". This was obviously not what was intended. The same error
exists for "force full-speed", "force high-speed" and "test
packet". Using strstarts avoids the error-prone hardcoding of the
prefix length.
For consistency, also change the other occurences of the !strncmp
idiom.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
commit cc92f681 (usb: musb: Populate new IO
functions for blackfin) added a typo which
prevented MUSB's blackfin glue layer from being
built. Due to lack of tests and compilers for
that architecture, the typo ended up being
merged and causing a build regression.
Fix that here
Cc: Tony Lindgren <tony@atomide.com>
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Blackfin's MUSB implementation lacks a bunch of
registers which they end up not defining a macro
for. In order to avoid build breaks, let's ifdef
out some of the registers from our regdump debugfs
utility so that we don't try to use those on
Blackfin builds.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
