Age | Commit message (Collapse) | Author | Files | Lines |
|
SHUTDOWN_PENDING
when A sends a data to B, then A close() and enter into SHUTDOWN_PENDING
state, if B neither claim his rwnd is 0 nor send SACK for this data, A
will keep retransmitting this data until t5 timeout, Max.Retrans times
can't work anymore, which is bad.
if B's rwnd is not 0, it should send abort after Max.Retrans times, only
when B's rwnd == 0 and A's retransmitting beyonds Max.Retrans times, A
will start t5 timer, which is also commit f8d960524328 ("sctp: Enforce
retransmission limit during shutdown") means, but it lacks the condition
peer rwnd == 0.
so fix it by adding a bit (zero_window_announced) in peer to record if
the last rwnd is 0. If it was, zero_window_announced will be set. and use
this bit to decide if start t5 timer when local.state is SHUTDOWN_PENDING.
Fixes: commit f8d960524328 ("sctp: Enforce retransmission limit during shutdown")
Signed-off-by: Xin Long <[email protected]>
Signed-off-by: Marcelo Ricardo Leitner <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
|
|
The ioctl IOC_LIBCFS_PING_TEST has not been used in ages. The recent
nidstring changes which moved all the nidstring operations from libcfs
to the LNet layer but this ioctl code was still using an nidstring
operation that was causing a circular dependency loop between libcfs and
LNet.
Signed-off-by: James Simmons <[email protected]>
Signed-off-by: Oleg Drokin <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
Pull vfs fixes from Al Viro:
"A couple of fixes (-stable fodder) + dead code removal after the
overlayfs fix.
I agree that it's better to separate from the fix part to make
backporting easier, but IMO it's not worth delaying said dead code
removal until the next window"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
Don't reset ->total_link_count on nested calls of vfs_path_lookup()
ovl: get rid of the dead code left from broken (and disabled) optimizations
ovl: fix permission checking for setattr
|
|
If the chunks are enqueued successfully but sctp_cmd_interpreter()
return err to sctp_sendmsg() (mainly because of no mem), the chunks will
get re-queued, but we are dropping the reference and freeing them.
The fix is to just drop the reference on the datamsg just as it had
succeeded, as:
- if the chunks weren't queued, this is enough to get them freed.
- if they were queued, they will get freed when they finally get out or
discarded.
Signed-off-by: Xin Long <[email protected]>
Marcelo Ricardo Leitner <[email protected]>
Signed-off-by: Marcelo Ricardo Leitner <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
When a msg is sent, sctp will hold the chunks of this msg and then try
to enqueue them. But if the chunks are not enqueued in sctp_outq_tail()
because of the invalid state, sctp_cmd_interpreter() may still return
success to sctp_sendmsg() after calling sctp_outq_flush(), these chunks
will become orphans and will leak.
So we fix them by moving sctp_chunk_hold() to sctp_outq_tail(), where we
are sure that the chunk is going to get queued.
Signed-off-by: Xin Long <[email protected]>
Signed-off-by: Marcelo Ricardo Leitner <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
we already zero it on outermost set_nameidata(), so initialization in
path_init() is pointless and wrong. The same DoS exists on pre-4.2
kernels, but there a slightly different fix will be needed.
Cc: [email protected] # v4.2
Signed-off-by: Al Viro <[email protected]>
|
|
Signed-off-by: Al Viro <[email protected]>
|
|
[Al Viro] The bug is in being too enthusiastic about optimizing ->setattr()
away - instead of "copy verbatim with metadata" + "chmod/chown/utimes"
(with the former being always safe and the latter failing in case of
insufficient permissions) it tries to combine these two. Note that copyup
itself will have to do ->setattr() anyway; _that_ is where the elevated
capabilities are right. Having these two ->setattr() (one to set verbatim
copy of metadata, another to do what overlayfs ->setattr() had been asked
to do in the first place) combined is where it breaks.
Signed-off-by: Miklos Szeredi <[email protected]>
Cc: <[email protected]>
Signed-off-by: Al Viro <[email protected]>
|
|
In case of a tx queue timeout every transmit is blocked until the
QCA7000 resets himself and triggers a sync which makes the driver
flushs the tx ring. So avoid this blocking situation by triggering
the sync immediately after the timeout. Waking the queue doesn't
make sense in this situation.
Signed-off-by: Stefan Wahren <[email protected]>
Fixes: 291ab06ecf67 ("net: qualcomm: new Ethernet over SPI driver for QCA7000")
Signed-off-by: David S. Miller <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull scheduler fixes from Thomas Gleixner:
"This updates contains the following changes:
- Fix a signal handling regression in the bit wait functions.
- Avoid false positive warnings in the wakeup path.
- Initialize the scheduler root domain properly.
- Handle gtime calculations in proc/$PID/stat proper.
- Add more documentation for the barriers in try_to_wake_up().
- Fix a subtle race in try_to_wake_up() which might cause a task to
be scheduled on two cpus
- Compile static helper function only when it is used"
* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched/core: Fix an SMP ordering race in try_to_wake_up() vs. schedule()
sched/core: Better document the try_to_wake_up() barriers
sched/cputime: Fix invalid gtime in proc
sched/core: Clear the root_domain cpumasks in init_rootdomain()
sched/core: Remove false-positive warning from wake_up_process()
sched/wait: Fix signal handling in bit wait helpers
sched/rt: Hide the push_irq_work_func() declaration
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Thoma Gleixner:
"Another round of fixes for x86:
- Move the initialization of the microcode driver to late_initcall to
make sure everything that init function needs is available.
- Make sure that lockdep knows about interrupts being off in the
entry code before calling into c-code.
- Undo the cpu hotplug init delay regression.
- Use the proper conditionals in the mpx instruction decoder.
- Fixup restart_syscall for x32 tasks.
- Fix the hugepage regression on PAE kernels which was introduced
with the latest PAT changes"
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/signal: Fix restart_syscall number for x32 tasks
x86/mpx: Fix instruction decoder condition
x86/mm: Fix regression with huge pages on PAE
x86 smpboot: Re-enable init_udelay=0 by default on modern CPUs
x86/entry/64: Fix irqflag tracing wrt context tracking
x86/microcode: Initialize the driver late when facilities are up
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"This is quite a bumper crop of fixes: three from Arnd correcting
various build issues in some configurations, a lock recursion in
qla2xxx. Two potentially exploitable issues in hpsa and mvsas, a
potential null deref in st, a revert of a bdi registration fix that
turned out to cause even more problems, a set of fixes to allow people
who only defined MPT2SAS to still work after the mpt2/mpt3sas merger
and a couple of fixes for issues turned up by the hyper-v storvsc
driver"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
mpt3sas: fix Kconfig dependency problem for mpt2sas back compatibility
Revert "scsi: Fix a bdi reregistration race"
mpt3sas: Add dummy Kconfig option for backwards compatibility
Fix a memory leak in scsi_host_dev_release()
block/sd: Fix device-imposed transfer length limits
scsi_debug: fix prevent_allow+verify regressions
MAINTAINERS: Add myself as co-maintainer of the SCSI subsystem.
sd: Make discard granularity match logical block size when LBPRZ=1
scsi: hpsa: select CONFIG_SCSI_SAS_ATTR
scsi: advansys needs ISA dma api for ISA support
scsi_sysfs: protect against double execution of __scsi_remove_device()
st: fix potential null pointer dereference.
scsi: report 'INQUIRY result too short' once per host
advansys: fix big-endian builds
qla2xxx: Fix rwlock recursion
hpsa: logical vs bitwise AND typo
mvsas: don't allow negative timeouts
mpt3sas: Fix use sas_is_tlr_enabled API before enabling MPI2_SCSIIO_CONTROL_TLR_ON flag
|
|
In case we monitor events system wide, we get EXIT event
(when configured) twice for each task that exited.
Note doubled lines with same pid/tid in following example:
$ sudo ./perf record -a
^C[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.480 MB perf.data (2518 samples) ]
$ sudo ./perf report -D | grep EXIT
0 60290687567581 0x59910 [0x38]: PERF_RECORD_EXIT(1250:1250):(1250:1250)
0 60290687568354 0x59948 [0x38]: PERF_RECORD_EXIT(1250:1250):(1250:1250)
0 60290687988744 0x59ad8 [0x38]: PERF_RECORD_EXIT(1250:1250):(1250:1250)
0 60290687989198 0x59b10 [0x38]: PERF_RECORD_EXIT(1250:1250):(1250:1250)
1 60290692567895 0x62af0 [0x38]: PERF_RECORD_EXIT(1253:1253):(1253:1253)
1 60290692568322 0x62b28 [0x38]: PERF_RECORD_EXIT(1253:1253):(1253:1253)
2 60290692739276 0x69a18 [0x38]: PERF_RECORD_EXIT(1252:1252):(1252:1252)
2 60290692739910 0x69a50 [0x38]: PERF_RECORD_EXIT(1252:1252):(1252:1252)
The reason is that the cpu contexts are processes each time
we call perf_event_task. I'm changing the perf_event_aux logic
to serve task_ctx and cpu contexts separately, which ensure we
don't get EXIT event generated twice on same cpu context.
This does not affect other auxiliary events, as they don't
use task_ctx at all.
Signed-off-by: Jiri Olsa <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Cc: Arnaldo Carvalho de Melo <[email protected]>
Cc: Arnaldo Carvalho de Melo <[email protected]>
Cc: David Ahern <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Stephane Eranian <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Vince Weaver <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
|
|
We need to add rest of the flags to the constraint mask
instead of another INTEL_ARCH_EVENT_MASK, fixing a typo.
Signed-off-by: Jiri Olsa <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Cc: Arnaldo Carvalho de Melo <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Paul Mackerras <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Stephane Eranian <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Vince Weaver <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
|
|
There was a mistake in the Haswell constraints table.
Signed-off-by: Yuanfang Chen <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Reviewed-by: Andi Kleen <[email protected]>
Cc: Arnaldo Carvalho de Melo <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Stephane Eranian <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Vince Weaver <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
|
|
The Huawei E3372 (12d1:157d) needs this quirk in MBIM mode
as well. Allow this by forcing the NTB to contain only a
single NDP, and add a device specific entry for this ID.
Due to the way Huawei use device IDs, this might be applied
to other modems as well. It is assumed that those modems
will be based on the same firmware and will need this quirk
too. If not, it will still not harm normal usage, although
multiplexing performance could be impacted.
Cc: Enrico Mioso <[email protected]>
Reported-by: Sami Farin <[email protected]>
Signed-off-by: Bjørn Mork <[email protected]>
Acked-By: Enrico Mioso <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
This reverts commit d3716f18a7d841565c930efde30737a3557eee69.
vmalloc cannot be used in BH disabled contexts, even
with GFP_ATOMIC. And we certainly want to support
rhashtable users inserting entries with software
interrupts disabled.
Signed-off-by: David S. Miller <[email protected]>
|
|
Add myself as a reviewer for the Renesas Ethernet drivers -- hopefully I
won't miss the buggy patches anymore. :-)
Signed-off-by: Sergei Shtylyov <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Marcelo Ricardo Leitner says:
====================
sctp: packet timestamp fixes
These a couple of fixes regarding sctp/packet timestamps.
Dmitry Vyukov <[email protected]> reported the counter leak on missing
net_enable_timestamp() (2nd patch) and further testing here revealed the
other two issues.
Please consider these to -stable.
====================
Signed-off-by: David S. Miller <[email protected]>
|
|
As we are keeping timestamps on when copying the socket, we also have to
copy sk_tsflags.
This is needed since b9f40e21ef42 ("net-timestamp: move timestamp flags
out of sk_flags").
Signed-off-by: Marcelo Ricardo Leitner <[email protected]>
Acked-by: Vlad Yasevich <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Dmitry Vyukov reported that SCTP was triggering a WARN on socket destroy
related to disabling sock timestamp.
When SCTP accepts an association or peel one off, it copies sock flags
but forgot to call net_enable_timestamp() if a packet timestamping flag
was copied, leading to extra calls to net_disable_timestamp() whenever
such clones were closed.
The fix is to call net_enable_timestamp() whenever we copy a sock with
that flag on, like tcp does.
Reported-by: Dmitry Vyukov <[email protected]>
Signed-off-by: Marcelo Ricardo Leitner <[email protected]>
Acked-by: Vlad Yasevich <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
SCTP echoes a cookie o INIT ACK chunks that contains a timestamp, for
detecting stale cookies. This cookie is echoed back to the server by the
client and then that timestamp is checked.
Thing is, if the listening socket is using packet timestamping, the
cookie is encoded with ktime_get() value and checked against
ktime_get_real(), as done by __net_timestamp().
The fix is to sctp also use ktime_get_real(), so we can compare bananas
with bananas later no matter if packet timestamping was enabled or not.
Fixes: 52db882f3fc2 ("net: sctp: migrate cookie life from timeval to ktime")
Signed-off-by: Marcelo Ricardo Leitner <[email protected]>
Acked-by: Vlad Yasevich <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Pull drm fixes from Dave Airlie:
"A bunch of change across the board, the main things are some vblank
fallout in radeon and nouveau required some work, but I think this
should fix it all. There is also one drm fix for an oops in vmwgfx
with how we pass the drm master around.
The rest is just some amdgpu, i915, imx and rockchip fixes.
Probably more than I'd like at this point, but hopefully things settle
down now"
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: (40 commits)
drm/amdgpu: Fixup hw vblank counter/ts for new drm_update_vblank_count() (v3)
drm/radeon: Fixup hw vblank counter/ts for new drm_update_vblank_count() (v2)
drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt
drm/amdgpu: add spin lock to protect freed list in vm (v2)
drm/amdgpu: partially revert "drm/amdgpu: fix VM_CONTEXT*_PAGE_TABLE_END_ADDR" v2
drm/amdgpu: take a BO reference for the user fence
drm/amdgpu: take a BO reference in the display code
drm/amdgpu: set snooped flags only on system addresses v2
drm/nouveau: Fix pre-nv50 pageflip events (v4)
drm: Fix an unwanted master inheritance v2
drm/amdgpu: fix race condition in amd_sched_entity_push_job
drm/amdgpu: add err check for pin userptr
drm/i915: take a power domain reference while checking the HDMI live status
drm/i915: add MISSING_CASE to a few port/aux power domain helpers
drm/i915/ddi: fix intel_display_port_aux_power_domain() after HDMI detect
drm/i915: Introduce a gmbus power domain
drm/i915: Clean up AUX power domain handling
drm/rockchip: Use CRTC vblank event interface
drm/rockchip: Fix module autoload for OF platform driver
drm/rockchip: vop: fix window origin calculation
...
|
|
Commit 3511494ce2f3d ("vxlan: Group Policy extension") changed definition of
VXLAN_HF_RCO from 0x00200000 to BIT(24). This is obviously incorrect. It's
also in violation with the RFC draft.
Fixes: 3511494ce2f3d ("vxlan: Group Policy extension")
Cc: Thomas Graf <[email protected]>
Cc: Tom Herbert <[email protected]>
Signed-off-by: Jiri Benc <[email protected]>
Acked-by: Tom Herbert <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Commit 64236f3f3d74 ("ipv6: introduce IFA_F_STABLE_PRIVACY flag")
failed to update the setting of the IFA_F_OPTIMISTIC flag, causing
the IFA_F_STABLE_PRIVACY flag to be lost if IFA_F_OPTIMISTIC is set.
Cc: Erik Kline <[email protected]>
Cc: Fernando Gont <[email protected]>
Cc: Lorenzo Colitti <[email protected]>
Cc: YOSHIFUJI Hideaki/吉藤英明 <[email protected]>
Cc: Hannes Frederic Sowa <[email protected]>
Fixes: 64236f3f3d74 ("ipv6: introduce IFA_F_STABLE_PRIVACY flag")
Signed-off-by: Bjørn Mork <[email protected]>
Acked-by: Hannes Frederic Sowa <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
There is a memleak when suspend/resume this driver version.
Currently the stmmac, during resume step, reallocates all the resources
but they are not released when suspend.
The patch is not to release these resources but the logic has been changed.
In fact, it is not necessary to free and reallocate all from scratch
because the memory data will be always preserved.
As final solution, the patch just reinit the descriptors and the rx/tx
pointers only when resume. Tested done on STi boxes.
Reported-by: ZhengShunQian <[email protected]>
Signed-off-by: Giuseppe Cavallaro <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
The Rx queue #1 frame error counter name contains trailing underscore,
probably due to a typo...
Signed-off-by: Sergei Shtylyov <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
In a low memory situation the following kernel oops occurs:
Unable to handle kernel NULL pointer dereference at virtual address 00000050
pgd = 8490c000
[00000050] *pgd=4651e831, *pte=00000000, *ppte=00000000
Internal error: Oops: 17 [#1] PREEMPT ARM
Modules linked in:
CPU: 0 Not tainted (3.4-at16 #9)
PC is at skb_put+0x10/0x98
LR is at sh_eth_poll+0x2c8/0xa10
pc : [<8035f780>] lr : [<8028bf50>] psr: 60000113
sp : 84eb1a90 ip : 84eb1ac8 fp : 84eb1ac4
r10: 0000003f r9 : 000005ea r8 : 00000000
r7 : 00000000 r6 : 940453b0 r5 : 00030000 r4 : 9381b180
r3 : 00000000 r2 : 00000000 r1 : 000005ea r0 : 00000000
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 10c53c7d Table: 4248c059 DAC: 00000015
Process klogd (pid: 2046, stack limit = 0x84eb02e8)
[...]
This is because netdev_alloc_skb() fails and 'mdp->rx_skbuff[entry]' is left
NULL but sh_eth_rx() later uses it without checking. Add such check...
Reported-by: Yasushi SHOJI <[email protected]>
Signed-off-by: Sergei Shtylyov <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue
Jeff Kirsher says:
====================
Intel Wired LAN Driver Updates 2015-12-03
This series contains updates to ixgbe, i40e/i40evf, MAINTAINERS and e100.txt
Alex provides a fix for ixgbe where enabling SR-IOV and then bringing the
interface up was resulting in the PF MAC addresses getting into a bad state.
The workaround for this issue is to bring up the interface first and then
enable SR-IOV as this will trigger the reset in the existing code.
I clean up legacy license stuff in the e100.txt documentation and then
update the maintainers/reviewers list for our drivers.
Jesse fixes an issue with the i40e/i40evf drivers, where if the driver were
to happen to have a mutex held while the i40e_init_adminq() call was called,
the init_adminq might inadvertently call mutex_init on a lock that was held
which is a violation of the calling semantices.
====================
Signed-off-by: David S. Miller <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
Pull crypto fixes from Herbert Xu:
"This fixes a couple of crypto drivers that were using memcmp to verify
authentication tags. They now use crypto_memneq instead"
* 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
crypto: talitos - Fix timing leak in ESP ICV verification
crypto: nx - Fix timing leak in GCM and CCM decryption
|
|
When restarting a syscall with regs->ax == -ERESTART_RESTARTBLOCK,
regs->ax is assigned to a restart_syscall number. For x32 tasks, this
syscall number must have __X32_SYSCALL_BIT set, otherwise it will be
an x86_64 syscall number instead of a valid x32 syscall number. This
issue has been there since the introduction of x32.
Reported-by: strace/tests/restart_syscall.test
Reported-and-tested-by: Elvira Khabirova <[email protected]>
Signed-off-by: Dmitry V. Levin <[email protected]>
Cc: Elvira Khabirova <[email protected]>
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
|
|
MPX decodes instructions in order to tell which bounds register
was violated. Part of this decoding involves looking at the "REX
prefix" which is a special instrucion prefix used to retrofit
support for new registers in to old instructions.
The X86_REX_*() macros are defined to return actual bit values:
#define X86_REX_R(rex) ((rex) & 4)
*not* boolean values. However, the MPX code was checking for
them like they were booleans. This might have led to us
mis-decoding the "REX prefix" and giving false information out to
userspace about bounds violations. X86_REX_B() actually is bit 1,
so this is really only broken for the X86_REX_X() case.
Fix the conditionals up to tolerate the non-boolean values.
Fixes: fcc7ffd67991 "x86, mpx: Decode MPX instruction to get bound violation information"
Reported-by: Dan Carpenter <[email protected]>
Signed-off-by: Dave Hansen <[email protected]>
Cc: [email protected]
Cc: Dave Hansen <[email protected]>
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
|
|
spin lock should be released while returning from function
Signed-off-by: Saurabh Sengar <[email protected]>
Signed-off-by: Vinod Koul <[email protected]>
|
|
f93178291712 dmaengine: bcm2835-dma: Fix memory leak when stopping a
running transfer
Fixed the memleak, but introduced another issue: the terminate_all callback
might be called with interrupts disabled and the dma_free_coherent() is
not allowed to be called when IRQs are disabled.
Convert the driver to use dma_pool_* for managing the list of control
blocks for the transfer.
Fixes: f93178291712 ("dmaengine: bcm2835-dma: Fix memory leak when stopping a running transfer")
Signed-off-by: Peter Ujfalusi <[email protected]>
Tested-by: Matthias Reichl <[email protected]>
Signed-off-by: Vinod Koul <[email protected]>
|
|
When performing interleaved transfers with numf > 1, an extra line is
copied. The mbr.bc field is incremented once too often. The length of
the block is (BLEN+1) microblocks.
Signed-off-by: Sylvain ETIENNE <[email protected]>
Signed-off-by: Ludovic Desroches <[email protected]>
Fixes: 4e5385784e69 ("dmaengine: at_xdmac: handle numf > 1")
Signed-off-by: Vinod Koul <[email protected]>
|
|
The code was not in agreement with the comments.
Signed-off-by: Ludovic Desroches <[email protected]>
Cc: [email protected] # 4.3 and later
Signed-off-by: Vinod Koul <[email protected]>
|
|
Fix typo in a macro which was not used until now. It explains why there
is no error at compilation time.
Signed-off-by: Ludovic Desroches <[email protected]>
Fixes: e1f7c9eee707 "dmaengine: at_xdmac: creation of the atmel eXtended
DMA Controller driver"
Cc: [email protected] # 3.19 and later
Acked-by: Nicolas Ferre <[email protected]>
Signed-off-by: Vinod Koul <[email protected]>
|
|
into drm-next
A few more last minute fixes for 4.4 on top of my pull request from
earlier this week. The big change here is a vblank regression fix due to
commit 4dfd6486 "drm: Use vblank timestamps to guesstimate how many vblanks
were missed". Beyond that, a hotplug fix and a few VM fixes.
* 'drm-fixes-4.4' of git://people.freedesktop.org/~agd5f/linux:
drm/amdgpu: Fixup hw vblank counter/ts for new drm_update_vblank_count() (v3)
drm/radeon: Fixup hw vblank counter/ts for new drm_update_vblank_count() (v2)
drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt
drm/amdgpu: add spin lock to protect freed list in vm (v2)
drm/amdgpu: partially revert "drm/amdgpu: fix VM_CONTEXT*_PAGE_TABLE_END_ADDR" v2
drm/amdgpu: take a BO reference for the user fence
drm/amdgpu: take a BO reference in the display code
drm/amdgpu: set snooped flags only on system addresses v2
drm/amdgpu: fix race condition in amd_sched_entity_push_job
drm/amdgpu: add err check for pin userptr
add blacklist for thinkpad T40p
drm/amdgpu: fix VM page table reference counting
drm/amdgpu: fix userptr flags check
|
|
PCI interrupt lines start at 1, not at 0. So, creates additional one
interrupt when register for irq domain.
Error when PCIe devices have 4 INTx:
WARNING: CPU: 1 PID: 1 at kernel/irq/irqdomain.c:280
irq_domain_associate+0x17c/0x1cc()
error: hwirq 0x4 is too large for dummy
Tested on Ethernet adapter card with multi-functions.
Signed-off-by: Ley Foon Tan <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
|
|
Check TLP packet successful completion status. This fix the issue when
accessing multi-function devices in enumeration process, TLP will return
error when accessing non-exist function number. Returns PCI error code
instead of generic errno.
Tested on Ethernet adapter card with multi-functions.
[bhelgaas: simplify completion status checking code]
Signed-off-by: Ley Foon Tan <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
|
|
The Requester ID should use the Root Port devfn and it should be always 0.
Previously we constructed the Requester ID using the *Completer* devfn,
i.e., the devfn of the Function we expect to respond to the config access.
This causes issues when accessing configuration space for devices other
than the Root Port.
Build the Requester ID using the Root Port devfn.
Tested on Ethernet adapter card with multi-functions.
Signed-off-by: Ley Foon Tan <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
|
|
TLP_LOOP is 500 and the "loop" variable was a u8 so "loop < TLP_LOOP" is
always true. We only need this condition to work if there is a problem so
it would have been easy to miss this in testing.
Make it a normal for loop with "int i" instead of over thinking things and
making it complicated.
Fixes: 6bb4dd154ae8 ("PCI: altera: Add Altera PCIe host controller driver")
Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Acked-by: Ley Foon Tan <[email protected]>
|
|
atl1c driver is doing order-4 allocation with GFP_ATOMIC
priority. That often breaks networking after resume. Switch to
GFP_KERNEL. Still not ideal, but should be significantly better.
atl1c_setup_ring_resources() is called from .open() function, and
already uses GFP_KERNEL, so this change is safe.
Signed-off-by: Pavel Machek <[email protected]>
Acked-by: Michal Hocko <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
When an rhashtable user pounds rhashtable hard with back-to-back
insertions we may end up growing the table in GFP_ATOMIC context.
Unfortunately when the table reaches a certain size this often
fails because we don't have enough physically contiguous pages
to hold the new table.
Eric Dumazet suggested (and in fact wrote this patch) using
__vmalloc instead which can be used in GFP_ATOMIC context.
Reported-by: Phil Sutter <[email protected]>
Suggested-by: Eric Dumazet <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Parameters were updated only if the kernel was unable to find the tunnel
with the new parameters, ie only if core pamareters were updated (keys,
addr, link, type).
Now it's possible to update ttl, hoplimit, flowinfo and flags.
Fixes: c12b395a4664 ("gre: Support GRE over IPv6")
Signed-off-by: Nicolas Dichtel <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
pppoe_connect() mustn't touch the padt_work field of pppoe sockets
because that work could be already pending.
[ 21.473147] BUG: unable to handle kernel NULL pointer dereference at 00000004
[ 21.474523] IP: [<c1043177>] process_one_work+0x29/0x31c
[ 21.475164] *pde = 00000000
[ 21.475513] Oops: 0000 [#1] SMP
[ 21.475910] Modules linked in: pppoe pppox ppp_generic slhc crc32c_intel aesni_intel virtio_net xts aes_i586 lrw gf128mul ablk_helper cryptd evdev acpi_cpufreq processor serio_raw button ext4 crc16 mbcache jbd2 virtio_blk virtio_pci virtio_ring virtio
[ 21.476168] CPU: 2 PID: 164 Comm: kworker/2:2 Not tainted 4.4.0-rc1 #1
[ 21.476168] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014
[ 21.476168] task: f5f83c00 ti: f5e28000 task.ti: f5e28000
[ 21.476168] EIP: 0060:[<c1043177>] EFLAGS: 00010046 CPU: 2
[ 21.476168] EIP is at process_one_work+0x29/0x31c
[ 21.484082] EAX: 00000000 EBX: f678b2a0 ECX: 00000004 EDX: 00000000
[ 21.484082] ESI: f6c69940 EDI: f5e29ef0 EBP: f5e29f0c ESP: f5e29edc
[ 21.484082] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[ 21.484082] CR0: 80050033 CR2: 000000a4 CR3: 317ad000 CR4: 00040690
[ 21.484082] Stack:
[ 21.484082] 00000000 f6c69950 00000000 f6c69940 c0042338 f5e29f0c c1327945 00000000
[ 21.484082] 00000008 f678b2a0 f6c69940 f678b2b8 f5e29f30 c1043984 f5f83c00 f6c69970
[ 21.484082] f678b2a0 c10437d3 f6775e80 f678b2a0 c10437d3 f5e29fac c1047059 f5e29f74
[ 21.484082] Call Trace:
[ 21.484082] [<c1327945>] ? _raw_spin_lock_irq+0x28/0x30
[ 21.484082] [<c1043984>] worker_thread+0x1b1/0x244
[ 21.484082] [<c10437d3>] ? rescuer_thread+0x229/0x229
[ 21.484082] [<c10437d3>] ? rescuer_thread+0x229/0x229
[ 21.484082] [<c1047059>] kthread+0x8f/0x94
[ 21.484082] [<c1327a32>] ? _raw_spin_unlock_irq+0x22/0x26
[ 21.484082] [<c1327ee9>] ret_from_kernel_thread+0x21/0x38
[ 21.484082] [<c1046fca>] ? kthread_parkme+0x19/0x19
[ 21.496082] Code: 5d c3 55 89 e5 57 56 53 89 c3 83 ec 24 89 d0 89 55 e0 8d 7d e4 e8 6c d8 ff ff b9 04 00 00 00 89 45 d8 8b 43 24 89 45 dc 8b 45 d8 <8b> 40 04 8b 80 e0 00 00 00 c1 e8 05 24 01 88 45 d7 8b 45 e0 8d
[ 21.496082] EIP: [<c1043177>] process_one_work+0x29/0x31c SS:ESP 0068:f5e29edc
[ 21.496082] CR2: 0000000000000004
[ 21.496082] ---[ end trace e362cc9cf10dae89 ]---
Reported-by: Andrew <[email protected]>
Fixes: 287f3a943fef ("pppoe: Use workqueue to die properly when a PADT is received")
Signed-off-by: Guillaume Nault <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client
Pull Ceph fix from Sage Weil:
"This addresses a refcounting bug that leads to a use-after-free"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client:
rbd: don't put snap_context twice in rbd_queue_workfn()
|
|
commit 4dfd6486 "drm: Use vblank timestamps to guesstimate how many
vblanks were missed" introduced in Linux 4.4-rc1 makes the drm core
more fragile to drivers which don't update hw vblank counters and
vblank timestamps in sync with firing of the vblank irq and
essentially at leading edge of vblank.
This exposed a problem with radeon-kms/amdgpu-kms which do not
satisfy above requirements:
The vblank irq fires a few scanlines before start of vblank, but
programmed pageflips complete at start of vblank and
vblank timestamps update at start of vblank, whereas the
hw vblank counter increments only later, at start of vsync.
This leads to problems like off by one errors for vblank counter
updates, vblank counters apparently going backwards or vblank
timestamps apparently having time going backwards. The net result
is stuttering of graphics in games, or little hangs, as well as
total failure of timing sensitive applications.
See bug #93147 for an example of the regression on Linux 4.4-rc:
https://bugs.freedesktop.org/show_bug.cgi?id=93147
This patch tries to align all above events better from the
viewpoint of the drm core / of external callers to fix the problem:
1. The apparent start of vblank is shifted a few scanlines earlier,
so the vblank irq now always happens after start of this extended
vblank interval and thereby drm_update_vblank_count() always samples
the updated vblank count and timestamp of the new vblank interval.
To achieve this, the reporting of scanout positions by
radeon_get_crtc_scanoutpos() now operates as if the vblank starts
radeon_crtc->lb_vblank_lead_lines before the real start of the hw
vblank interval. This means that the vblank timestamps which are based
on these scanout positions will now update at this earlier start of
vblank.
2. The driver->get_vblank_counter() function will bump the returned
vblank count as read from the hw by +1 if the query happens after
the shifted earlier start of the vblank, but before the real hw increment
at start of vsync, so the counter appears to increment at start of vblank
in sync with the timestamp update.
3. Calls from vblank irq-context and regular non-irq calls are now
treated identical, always simulating the shifted vblank start, to
avoid inconsistent results for queries happening from vblank irq vs.
happening from drm_vblank_enable() or vblank_disable_fn().
4. The radeon_flip_work_func will delay mmio programming a pageflip until
the start of the real vblank iff it happens to execute inside the shifted
earlier start of the vblank, so pageflips now also appear to execute at
start of the shifted vblank, in sync with vblank counter and timestamp
updates. This to avoid some races between updates of vblank count and
timestamps that are used for swap scheduling and pageflip execution which
could cause pageflips to execute before the scheduled target vblank.
The lb_vblank_lead_lines "fudge" value is calculated as the size of
the display controllers line buffer in scanlines for the given video
mode: Vblank irq's are triggered by the line buffer logic when the line
buffer refill for a video frame ends, ie. when the line buffer source read
position enters the hw vblank. This means that a vblank irq could fire at
most as many scanlines before the current reported scanout position of the
crtc timing generator as the number of scanlines the line buffer can
maximally hold for a given video mode.
This patch has been successfully tested on a RV730 card with DCE-3 display
engine and on a evergreen card with DCE-4 display engine, in single-display
and dual-display configuration, with different video modes.
A similar patch is needed for amdgpu-kms to fix the same problem.
Limitations:
- Maybe replace the udelay() in the flip_work_func() by a suitable
usleep_range() for a bit better efficiency? Will try that.
- Line buffer sizes in pixels are hard-coded on < DCE-4 to a value
i just guessed to be high enough to work ok, lacking info on the true
sizes atm.
Probably fixes: fdo#93147
Port of Mario's radeon fix to amdgpu.
Signed-off-by: Alex Deucher <[email protected]>
(v1) Reviewed-by: Mario Kleiner <[email protected]>
(v2) Refine amdgpu_flip_work_func() for better efficiency.
In amdgpu_flip_work_func, replace the busy waiting udelay(5)
with event lock held by a more performance and energy efficient
usleep_range() until at least predicted true start of hw vblank,
with some slack for scheduler happiness. Release the event lock
during waits to not delay other outputs in doing their stuff, as
the waiting can last up to 200 usecs in some cases.
Also small fix to code comment and formatting in that function.
(v2) Signed-off-by: Mario Kleiner <[email protected]>
(v3) Fix crash in crtc disabled case
|
|
Marcin Wojtas says:
====================
Marvell Armada 375 mvpp2 fixes
During my work on mvneta driver I revised mvpp2, and it occurred that the
initial version of Marvell Armada 375 SoC comprised bugs around
DMA-unmapping in both ingress and egress paths - not all buffers were
umapped in TX path and none(!) in RX. Three patches that I send fix
this situation.
Any feedback would be welcome.
====================
Signed-off-by: David S. Miller <[email protected]>
|