| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Adam Jackson <ajax@redhat.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
EDID 1.4 retcons the meaning of the "GTF feature" bit to mean "is
continuous frequency", and moves the set of supported timing formulas
into the range descriptor itself. In any event, the range descriptor
can act as a filter on the DMT list without regard to a specific timing
formula.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Signed-off-by: Adam Jackson <ajax@redhat.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Copied from the list in xserver.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Slightly more honest naming.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
mode_in_range() handles what this was warning about.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
It won't find any, yet. Fix up callers to match: standard mode codes
will look prefer r-b modes for a given size if present, EST3 mode codes
will look for exactly the r-b-ness mentioned in the mode code. This
might mean fewer modes matched for EST3 mode codes between now and when
the DMT mode list regrows the r-b modes, but practically speaking EST3
codes don't exist in the wild.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
No functional change, but will make an upcoming change clearer.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Signed-off-by: Adam Jackson <ajax@redhat.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
CEA modes 6, 7, 8, 9, 21, 22, 23, 24, 44, 45, 50, 51, 54, 55, 58 and 59
require sending pixel data 2 times. This doesn't mean the modes will
work yet, but now the drivers know they're different.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
The specification defines a VIC (Video Identification Code) for each
mode. When we're browsing drm_edid_modes.h, it really helps to have the
number available (otherwise we have to count...). These numbers are also
used in the EDID data (by the CEA-EXT extension block).
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
The CEA extension block has a field which describes which YCbCr modes are
supported by the device, use it to fill the drm_display_info color_formats
fields. Also the existence of a CEA extension block is used as indication
that the device supports RGB.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
The code should obviously check the EDID feature field for EDID feature flags
and not the color_formats field of the drm_display_info struct. Also update the
color_formats field with new modes instead of overwriting the current mode.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Perform some basic sanity check on some of the parameters in
drm_mode_fb_cmd2.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
These functions return the chroma subsampling factors for the specified
pixel format.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
This function returns the bytes per pixel value based on the pixel
format and plane index.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
There will be a need for this function in drm_crtc.c later. This
avoids making drm_crtc.c depend on drm_crtc_helper.c.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
This loop on EBCISR register was designed to clear IRQ sources before enabling
a DMA channel. This register is clear-on-read so a race condition can appear if
another channel is already active and has just finished its transfer.
Removing this read on EBCISR is fixing the issue as there is no case where an IRQ
could be pending: we already make sure that this register is drained at probe()
time and during resume.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
|
|
Enable channel in device_issue_pending call, so that the order between
cookie assignment and channel enabling can be ensured naturally.
It fixes the mxs gpmi-nand breakage which is caused by the incorrect
order of cookie assigning and channel enabling.
Suggested-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Tested-by: Huang Shijie <b32955@freescale.com>
Tested-by <samgandhi9@gmail.com>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
|
|
the cookie updates completed the cyclic dma descriptor wrongly. This caused the
BUG_ON to be hit as submit is called for completed descriptor
Fix this by not marking the cyclic descriptor as complete
Tested-by: Javier Martin <javier.martin@vista-silicon.com>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
|
|
According to the reporter, external mic starts to work if the
laptop-dmic model is used. According to BIOS pin config, all
pins are consistent with the alc269vb_laptop_dmic fixup, except
for the external mic, which is not present.
Cc: stable@kernel.org
BugLink: https://bugs.launchpad.net/bugs/950490
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Since the VIC was converted to use generic IRQ domains IRQ 0
is silently ignored. This IRQ is used on the U300 so we're
missing it now. Bump all IRQ numbers by one since they are
now decoupled from the hardware IRQ numbers.
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
It doesn't make sense to grant permission to change the status of a
regulator that is also set as always on and similarly it doesn't make
sense to allow a driver to change the voltage of a regulator which can
only be set to a single voltage.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
It looks like we also need to flush the render cache when we just
invalidate it. This fixes a regression in i-g-t/gem_tiled_blits on my
i855gm. I guess the render cache there is virtually indexed, so we
need to clean it when changing gtt mappings.
This regression has been introduce in
commit 46f0f8d120c4afae53a5670bf3ac80a928340ff3
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Apr 18 11:12:11 2012 +0100
drm/i915: Don't set a MBZ bit in gen2/3 MI_FLUSH
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
In the recent update of the cifs_iovec_write code to use async writes,
the handling of the file position was broken. That patch added a local
"offset" variable to handle the offset, and then only updated the
original "*poffset" before exiting.
Unfortunately, it copied off the original offset from the beginning,
instead of doing so after generic_write_checks had been called. Fix
this by moving the initialization of "offset" after that in the
function.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
|
|
tty_unlock is used on all other exits from the function.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Acked-by: Jiri Slaby <jslaby@suse.cz>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Pull nfsd bugfixes from J. Bruce Fields:
"One bugfix, and one minor header fix from Jeff Layton while we're
here"
* 'for-3.4' of git://linux-nfs.org/~bfields/linux:
nfsd: include cld.h in the headers_install target
nfsd: don't fail unchecked creates of non-special files
|
|
While debugging a latency with someone on IRC (mirage335) on #linux-rt (OFTC),
we discovered that the stacktrace output of the latency tracers
(preemptirqsoff) was empty.
This bug was caused by the creation of the dynamic length stack trace
again (like commit 12b5da3 "tracing: Fix ent_size in trace output" was).
This bug is caused by the latency tracers requiring the next event
to determine the time between the current event and the next. But by
grabbing the next event, the iter->ent_size is set to the next event
instead of the current one. As the stacktrace event is the last event,
this makes the ent_size zero and causes nothing to be printed for
the stack trace. The dynamic stacktrace uses the ent_size to determine
how much of the stack can be printed. The ent_size of zero means
no stack.
The simple fix is to save the iter->ent_size before finding the next event.
Note, mirage335 asked to remain anonymous from LKML and git, so I will
not add the Reported-by and Tested-by tags, even though he did report
the issue and tested the fix.
Cc: stable@vger.kernel.org # 3.1+
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
|
|
Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
|
|
Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
|
|
Also fix issue of accessing invalid msgr pointer issue. The local
msgr pointer in fucntion mpic_msgr_get will be accessed before
getting a valid address which will cause kernel crash.
Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
|
|
In file included from arch/powerpc/sysdev/mpic_msgr.c:20:0:
~/arch/powerpc/include/asm/mpic_msgr.h: In function 'mpic_msgr_set_destination':
~/arch/powerpc/include/asm/mpic_msgr.h:117:2:
error: implicit declaration of function 'get_hard_smp_processor_id'
make[1]: *** [arch/powerpc/sysdev/mpic_msgr.o] Error 1
Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
|
|
Commit ae3a197e (Disintegrate asm/system.h for PowerPC) broke build of
assembly files when CONFIG_BOOKE_WDT is enabled as follows:
AS arch/powerpc/lib/string.o
/home/baruch/git/stable/arch/powerpc/include/asm/reg_booke.h: Assembler messages:
/home/baruch/git/stable/arch/powerpc/include/asm/reg_booke.h:19: Error: Unrecognized opcode: `extern'
/home/baruch/git/stable/arch/powerpc/include/asm/reg_booke.h:20: Error: Unrecognized opcode: `extern'
Since setup_32.c is the only user of the booke_wdt configuration variables, move
the declarations there.
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
|
|
Commit 46d026ac ("powerpc/85xx: consolidate of_platform_bus_probe calls")
replaced platform-specific of_device_id tables with a single function
that probes the most of the busses in 85xx device trees. If a specific
platform needed additional busses probed, then it could call
of_platform_bus_probe() again. Typically, the additional platform-specific
busses are children of existing busses that have already been probed.
of_platform_bus_probe() does not handle those child busses automatically.
Unfortunately, this doesn't actually work. The second (platform-specific)
call to of_platform_bus_probe() never finds any of the busses it's asked
to find.
To remedy this, the platform-specific of_device_id tables are eliminated,
and their entries are merged into mpc85xx_common_ids[], so that all busses
are probed at once.
Signed-off-by: Timur Tabi <timur@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
|
|
While reviewing the sysctl code in ax25 I spotted races in ax25_exit
where it is possible to receive notifications and packets after already
freeing up some of the data structures needed to process those
notifications and updates.
Call unregister_netdevice_notifier early so that the rest of the cleanup
code does not need to deal with network devices. This takes advantage
of my recent enhancement to unregister_netdevice_notifier to send
unregister notifications of all network devices that are current
registered.
Move the unregistration for packet types, socket types and protocol
types before we cleanup any of the ax25 data structures to remove the
possibilities of other races.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This patch fixes and adds the irq handler for the
IC+ 101A/G where we need to read the reg17 to clean
the irq.
Also remove the flag for the 1001LF where no interrupt
can be used for this device.
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
During resume, tick_resume_broadcast() programs the broadcast timer in
oneshot mode unconditionally. On the platforms where broadcast timer
is not really required, this will generate spurious broadcast timer
ticks upon resume. For example, on the always running apic timer
platforms with HPET, I see spurious hpet tick once every ~5minutes
(which is the 32-bit hpet counter wraparound time).
Similar to boot time, during resume make the oneshot mode setting of
the broadcast clock event device conditional on the state of active
broadcast users.
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: svenjoac@gmx.de
Cc: torvalds@linux-foundation.org
Cc: rjw@sisk.pl
Link: http://lkml.kernel.org/r/1334802459.28674.209.camel@sbsiddha-desk.sc.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
|
Santosh found another trap when we avoid to initialize the broadcast
device in the switch_to_oneshot code. The broadcast device might be
still in SHUTDOWN state when we actually need to use it. That
obviously breaks, as set_next_event() is called on a shutdown
device. This did not break on x86, but Suresh analyzed it:
From the review, most likely on Sven's system we are force enabling
the hpet using the pci quirk's method very late. And in this case,
hpet_clockevent (which will be global_clock_event) handler can be
null, specifically as this platform might not be using deeper c-states
and using the reliable APIC timer.
Prior to commit 'fa4da365bc7772c', that handler will be set to
'tick_handle_oneshot_broadcast' when we switch the broadcast timer to
oneshot mode, even though we don't use it. Post commit
'fa4da365bc7772c', we stopped switching the broadcast mode to oneshot
as this is not really needed and his platform's global_clock_event's
handler will remain null. While on my SNB laptop, same is set to
'clockevents_handle_noop' because hpet gets enabled very early. (noop
handler on my platform set when the early enabled hpet timer gets
replaced by the lapic timer).
But the commit 'fa4da365bc7772c' tracked the broadcast timer mode in
the SW as oneshot, even though it didn't touch the HW timer. During
resume however, tick_resume_broadcast() saw the SW broadcast mode as
oneshot and actually programmed the broadcast device also into oneshot
mode. So this triggered the null pointer de-reference after the hpet
wraps around and depending on what the hpet counter is set to. On the
normal platforms where hpet gets enabled early we should be seeing a
spurious interrupt (in my SNB laptop I see one spurious interrupt
after around 5 minutes ;) which is 32-bit hpet counter wraparound
time), but that's a separate issue.
Enforce the mode setting when trying to set an event.
Reported-and-tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: torvalds@linux-foundation.org
Cc: svenjoac@gmx.de
Cc: rjw@sisk.pl
Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1204181723350.2542@ionos
|
|
The MC77xx devices can operate in two modes: "Direct IP" or "QMI",
switchable using a password protected AT command. Both product ID
and USB interface configuration will change when switched.
The "sierra_net" driver supports the "Direct IP" mode. This driver
supports the "QMI" mode.
There are also multiple possible USB interface configurations in each
mode, some providing more than one wwan interface. Like many other
devices made for Windows, different interface types are identified
using a static interface number. We define a Sierra specific
interface whitelist to support this.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The sp_pri_to_cos[] array size depends on the config but lets say it is
BX_E3B0_MAX_NUM_COS_PORT0 and max_num_of_cos is also
DCBX_E3B0_MAX_NUM_COS_PORT0. In the original code
"pri == max_num_of_cos" was accepted but it is one past the end of the
array.
Also we used "pri" before capping it. It's a harmless read past the end
of the array, but it would affect which error message gets printed.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Eilon Greenstein <eilong@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Rather than loading firmware specific for the xtal frequency, just use
the standard firmware and set the xtal frequency after firmware upload.
The modified firmware will never be released, so we're better off
merging this now rather than waiting for v3.5.
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
linux/drivers/xen/manage.c: In function 'do_suspend':
linux/drivers/xen/manage.c:160:5: warning: 'si.cancelled' may be used uninitialized in this function
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
|
Pull drm fixes from Dave Airlie:
"It's like a grab bag of one liners:
- core: fix page flip error path, reorder object teardown.
- usb: fix the drm_usb module license.
- i915: VT switch on SNB with non-native modes fix, and a regression
fix from 3.3.
- radeon: missing unreserve on SI, AGP/VRAM setup fix (fixes radeon on
IA64, but its a generic bug), an rn50 regression from 3.3, turn off
MSIs on rv515 (it loses rearms every so often)."
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
nouveau: Set special lane map for the right chipset
drm/radeon: fix load detect on rn50 with hardcoded EDIDs.
drm: Releasing FBs before releasing GEM objects during drm_release
drm/nouveau/pm: don't read/write beyond end of stack buffer
drivers: gpu: drm: gma500: mdfld_dsi_output.h: Remove not unneeded include of version.h
radeon: fix r600/agp when vram is after AGP (v3)
drm: fix page_flip error handling
drm/radeon/kms: fix the regression of DVI connector check
drm/usb: fix module license on drm/usb layer.
drm/i915: Do not set "Enable Panel Fitter" on SNB pageflips
drm/i915: Hold mode_config lock whilst changing mode for lastclose()
drm/radeon/si: add missing radeon_bo_unreserve in si_rlc_init() v2
drm/radeon: disable MSI on RV515
drm/i915: don't clobber the special upscaling lvds timings
|
|
Fix the following compilation failure:
linux-2.6/drivers/media/video/mt9m032.c: In function '__mt9m032_get_pad_crop':
linux-2.6/drivers/media/video/mt9m032.c:337: error: implicit declaration of function 'v4l2_subdev_get_try_crop'
linux-2.6/drivers/media/video/mt9m032.c:337: warning: return makes pointer from integer without a cast
linux-2.6/drivers/media/video/mt9m032.c: In function '__mt9m032_get_pad_format':
linux-2.6/drivers/media/video/mt9m032.c:359: error: implicit declaration of function 'v4l2_subdev_get_try_format'
linux-2.6/drivers/media/video/mt9m032.c:359: warning: return makes pointer from integer without a cast
linux-2.6/drivers/media/video/mt9m032.c: In function 'mt9m032_probe':
linux-2.6/drivers/media/video/mt9m032.c:767: error: 'struct v4l2_subdev' has no member named 'entity'
linux-2.6/drivers/media/video/mt9m032.c:826: error: 'struct v4l2_subdev' has no member named 'entity'
linux-2.6/drivers/media/video/mt9m032.c: In function 'mt9m032_remove':
linux-2.6/drivers/media/video/mt9m032.c:842: error: 'struct v4l2_subdev' has no member named 'entity'
make[4]: *** [drivers/media/video/mt9m032.o] Error 1
by adding a dependency on VIDEO_V4L2_SUBDEV_API.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
This reverts commit 9f85550347f51c79a917b2aec04c90691c11e20a.
Peter Zijlstra says:
| Argh, how did that ever make it upstream, please drop.
|
| Russell, please make that go away upstream.
|
| Like I said, this is both completely the wrong way to solve, and you're
| so not paying attention, see:
|
| 5fbd036b552f633abb394a319f7c62a5c86a9cd7
| 2baab4e90495ebc9826c93f79d74d6e60a828d24
| e3831edd59edf57ca11fc289f08961b20baf5146
|
| What's even worse:
|
| git describe --contains 9f85550347f51c79a917b2aec04c90691c11e20a --match "v*"
| v3.4-rc3~1^2~3
|
| that nonsense got merged long after those other commits.
Linus Walleij says:
| My bad, was because the initial patch was submitted march 9th before
| these fixes were merged:
| http://marc.info/?l=linux-arm-kernel&m=133159655513844&w=2
|
| It was pending for a while in Russell's patch tracker and I
| rebased it to -rc2 without paying enough attention to recent
| related scheduler fixes ... lesson learned.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Pull KVM updates from Marcelo Tosatti.
* git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: lock slots_lock around device assignment
KVM: VMX: Fix kvm_set_shared_msr() called in preemptible context
KVM: unmap pages from the iommu when slots are removed
KVM: PMU emulation: GLOBAL_CTRL MSR should be enabled on reset
|
|
MAX_ADDR_LEN is 32. ETH_ALEN is 6. mac->sa_data is a 14 byte array, so
the memcpy() is doing a read past the end of the array. I asked about
this on netdev and Ben Hutchings told me it's supposed to be copying
ETH_ALEN bytes (thanks Ben).
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
If the file wasn't opened for writing, then truncate and ftruncate
need to report the appropriate errors.
Reported-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: stable@vger.kernel.org
|
|
Since we may be simulating flock() locks using NFS byte range locks,
we can't rely on the VFS having checked the file open mode for us.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: stable@vger.kernel.org
|
|
All callers of nfs4_handle_exception() that need to handle
NFS4ERR_OPENMODE correctly should set exception->inode
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: stable@vger.kernel.org
|
