3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Sergey Senozhatsky
commit 27c505ca84e164ec66ad55dcf3f5befaac83f10a upstream.
Commit a01c34f72e7cd2624570818f579b5ab464f93de2 (radeon kms: do not
flush uninitialized hotplug work) moved work
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Tom Stellard
commit e5b9e7503eb1f4884efa3b321d3cc47806779202 upstream.
Also add a new RADEON_INFO query to check that CP DMA packets are
supported on the compute ring.
CP DMA has been
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Daniel Vetter
commit 17e1df07df0fbc77696a1e1b6ccf9f2e5af70e40 upstream.
My g33 here seems to be shockingly good at hitting them all. This time
around kms_flip/flip-vs-panning-vs-hang blows
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Stanislaw Gruszka
commit 5a8e01f8fa51f5cbce8f37acc050eb2319d12956 upstream.
scale_stime() silently assumes that stime < rtime, otherwise
when stime == rtime and both values are big enough
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Alex Deucher
commit 84f3d9f7b4781dea6e11dcaf7f81367c1b39fef0 upstream.
Some older 6xx-7xx boards didn't always fill in the
UVD clocks properly in the UVD power states. This
leads to the
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Alex Deucher
commit ef4e03658420bbf91365647615460668c2510e79 upstream.
bapm is a power management feature for handling the
power budget between the CPU and GPU on APUs. This
patch adds
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Jan Kara
commit e729eac6f65e11c5f03b09adcc84bd5bcb230467 upstream.
Refuse RW mount of udf filesystem. So far we just silently changed it
to RO mount but when the media is writeable, block
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Alex Deucher
commit 1ff60ddb84bb9ff6fa182710c4e08b66badf918c upstream.
Check to make sure the dc limits are valid before using them.
Some systems may not have a dc limits table. In that case
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Alex Deucher
commit 1b9ba70a49ba92e910d8e5df702edf8c1858cecf upstream.
Certain r6xx boards use the same power state for both UVD
and other things. Since we don't support UVD on r6xx boards
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Nithin Sujir
commit 300cf9b93f74c3d969a0ad50bdac65416107c44c upstream.
Commit 989038e217e94161862a959e82f9a1ecf8dda152 ("tg3: Don't turn off
led on 5719 serdes port 0") added code to skip
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Jan Kara
commit d759bfa4e7919b89357de50a2e23817079889195 upstream.
Change all function used in filesystem discovery during mount to user
standard kernel return values - -errno on error, 0 on
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Stanislaw Gruszka
commit 6e956da2027c767859128b9bfef085cf2a8e233b upstream.
We should not do temperature compensation on devices without
EXTERNAL_TX_ALC bit set (called DynamicTxAgcControl on
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Alex Deucher
commit 95663948ba22a4be8b99acd67fbf83e86ddffba4 upstream.
If the LCD table contains an EDID record, properly account
for the edid size when walking through the records.
This
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Alex Deucher
commit e40210cca98068835acd5a4fe760bf96b3a1aa48 upstream.
If the low and high sclks are the same, there is no need to
enable sclk scaling. This causes display stability issues
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Christian König
commit 4f66c59922cbcda14c9e103e6c7f4ee616360d43 upstream.
Putting everything into VRAM seems to help.
Signed-off-by: Christian König
Signed-off-by: Alex Deucher
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Alex Deucher
commit 855f5f1d882a34e4e9dd27b299737cd3508a5624 upstream.
We were using the wrong set_properly callback so we always
ended up with Full scaling even if something else (Center or
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Stanislaw Gruszka
commit f4e1a4d3ecbb9e42bdf8e7869ee8a4ebfa27fb20 upstream.
My commit
commit c630ccf1a127578421a928489d51e99c05037054
Author: Stanislaw Gruszka
Date: Sat Mar 16 19:19:46
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Alex Deucher
commit f75195cac32bfd2ef07764bd370d3b788bd8b003 upstream.
The LCD has a relatively short vblank time (216us), but
the card is able to reclock memory fine in that time.
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Alex Deucher
commit 91f3a6aaf280294b07c05dfe606e6c27b7ba3c72 upstream.
The OUTPUT_ENABLE action jumps past the point in the coder where
the data_offset is set on certain rs780 cards. This
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Alex Deucher
commit fb93df1c2d8b3b1fb16d6ee9e32554e0c038815d upstream.
The table has the following format:
typedef struct _ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT //usSrcDstTableOffset
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Christian König
commit 6a3808b8233eb91b57c230cf1161ac116a189ffd upstream.
The same as on evergreen.
Signed-off-by: Christian König
Reported-by: FrankR Huang
Signed-off-by: Alex Deucher
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Oliver Smith
commit 2cf55125c64d64cc106e204d53b107094762dfdf upstream.
This fixes a serious bug affecting all hash types with a net element -
specifically, if a CIDR value is deleted such
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Solomon Peachy
commit 85ba8f529c57ac6e2fca9be0d9e17920a1afb2e8 upstream.
The cw1200_spi driver tries to mirror the cw1200_sdio driver's lock
API, which relies on
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Solomon Peachy
commit aec8e88c947b7017e2b4bbcb68a4bfc4a1f8ad35 upstream.
When we get an interrupt from the hardware, the first thing the driver does
is tell the device to mask off the
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: "J. Bruce Fields"
commit 9dfd87da1aeb0fd364167ad199f40fe96a6a87be upstream.
The reply to a gssproxy can include up to NGROUPS_MAX gid's, which will
take up more than a page. We therefore
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Alex Deucher
commit acf88deb8ddbb73acd1c3fa32fde51af9153227f upstream.
Setting MC_MISC_CNTL.GART_INDEX_REG_EN causes hangs on
some boards on resume. The systems seem to work fine
without
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: "J. Bruce Fields"
commit d4a516560fc96a9d486a9939bcb567e3fdce8f49 upstream.
In theory the linux cred in a gssproxy reply can include up to
NGROUPS_MAX data, 256K of data. In the common case
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: "J. Bruce Fields"
commit 6a36978e6931e6601be586eb313375335f2cfaa3 upstream.
The encoding of linux creds is a bit confusing.
Also: I think in practice it doesn't really matter whether we
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Khalid Aziz
commit 7cb2ef56e6a8b7b368b2e883a0a47d02fed66911 upstream.
I am working with a tool that simulates oracle database I/O workload.
This tool (orion to be specific -
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: "J. Bruce Fields"
commit 778e512bb1d3315c6b55832248cd30c566c081d7 upstream.
We can use the normal coding infrastructure here.
Two minor behavior changes:
- we're assuming no wasted
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Konstantin Khlebnikov
commit 8ac1c8d5deba65513b6a82c35e89e73996c8e0d6 upstream.
After commit 829199197a43 ("kernel/audit.c: avoid negative sleep
durations") audit emitters will block forever
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Alex Deucher
commit 4543eda52113d1e2cc0e9bf416f79597e6ef1ec7 upstream.
Need to swap the data fetched over i2c properly. This
is the same fix as the endian fix for aux channel
transactions.
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Alex Deucher
commit bc01a8c7a24169f8b111b7dda6f5d8e7088309af upstream.
We need to allocate line buffer to each display when
setting up the watermarks. Failure to do so can lead
to a blank
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Mikulas Patocka
commit c194992cbe71c20bb3623a566af8d11b0bfaa721 upstream.
The patch 136d8f377e1575463b47840bc5f1b22d94bf8f63 broke the skge driver.
Note this part of the patch:
+
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Alex Deucher
commit 0431b2742f8e7755f3bbf5924900d12973412e94 upstream.
This adds the pci ids for the berlin GPU core.
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman
---
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Alex Deucher
commit 7c4622d5415038a74964480844de885e7253a0f4 upstream.
Sets the right paramters for the new pci id.
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman
---
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Alex Deucher
commit e5903d399a7b0e5c14673c1206f4aeec2859c730 upstream.
The vram scratch buffer needs to be initialized
before the mc is programmed otherwise we program
0 as the GPU address of
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Anatol Pomozov
commit f3cff25f05f2ac29b2ee355e611b0657482f6f1d upstream.
'samples' is 64bit operant, but do_div() second parameter is 32.
do_div silently truncates high 32 bits and calculated
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Alex Deucher
commit 0b31e02363b0db4e7931561bc6c141436e729d9f upstream.
We need to allocate line buffer to each display when
setting up the watermarks. Failure to do so can lead
to a blank
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Bjorn Helgaas
commit adbe6991efd36104ac9eaf751993d35eaa7f493a upstream.
This fixes a copy and paste error introduced by 9f060e2231
("block: Convert integrity to bvec_alloc_bs()").
Found by
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Alex Deucher
commit 9a71677874d200865433647e9282fcf9fa6b05dd upstream.
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman
---
include/drm/drm_pciids.h |3 +++
1 file
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Emil Velikov
commit 5087f51da805f53cba7366f70d596e7bde2a5486 upstream.
Commit ea9197cc323839ef3d5280c0453b2c622caa6bc7 effectively enabled the
use of an improved DAC detection code, but
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Alex Deucher
commit b2e4c70a9747ecb618d563b004ba746869dde5aa upstream.
This fills in the GPU specific details for berlin
GPU cores so that the driver will work with them.
Signed-off-by: Alex
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Ben Skeggs
commit 182b17c8dc4e83aab000ce86587b6810e515da87 upstream.
After a vmalloc failure in ttm_dma_tt_alloc_page_directory(),
ttm_dma_tt_init() will call ttm_tt_destroy() to cleanup, and
3.11-stable review patch. If anyone has any objections, please let me know.
--
From: Kees Cook
commit 0a9cd0a80ac559357c6a90d26c55270ed752aa26 upstream.
A HID device could send a malicious output report that would cause the
lenovo-tpkbd HID driver to write just beyond the
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Alex Deucher
commit 91f3a6aaf280294b07c05dfe606e6c27b7ba3c72 upstream.
The OUTPUT_ENABLE action jumps past the point in the coder where
the data_offset is set on certain rs780 cards. This
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Konstantin Khlebnikov
commit 8ac1c8d5deba65513b6a82c35e89e73996c8e0d6 upstream.
After commit 829199197a43 ("kernel/audit.c: avoid negative sleep
durations") audit emitters will block forever
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Greg Kroah-Hartman
This reverts commit c2f5b7507ac5d808f29287d77ee6148358d7fbfe which is
commit f6e80abeab928b7c47cc1fbf53df13b4398a2bec.
Michal writes:
Mainline commit f6e80abe was
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Alex Deucher
commit 0b31e02363b0db4e7931561bc6c141436e729d9f upstream.
We need to allocate line buffer to each display when
setting up the watermarks. Failure to do so can lead
to a blank
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Li Zefan
commit f169007b2773f285e098cb84c74aac0154d65ff7 upstream.
If we pass fd of memory.usage_in_bytes of cgroup A to cgroup.event_control
of cgroup B, then we won't get memory usage
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: John Stultz
commit 7bd36014460f793c19e7d6c94dab67b0afcfcb7f upstream.
Gerlando Falauto reported that when HRTICK is enabled, it is
possible to trigger system deadlocks. These were hard to
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Alex Deucher
commit fb93df1c2d8b3b1fb16d6ee9e32554e0c038815d upstream.
The table has the following format:
typedef struct _ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT //usSrcDstTableOffset
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Christian König
commit 4f66c59922cbcda14c9e103e6c7f4ee616360d43 upstream.
Putting everything into VRAM seems to help.
Signed-off-by: Christian König
Signed-off-by: Alex Deucher
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Benjamin Tissoires
commit cc6b54aa54bf40b762cab45a9fc8aa81653146eb upstream.
When dealing with usage_index, be sure to properly use unsigned instead of
int to avoid overflows.
When working
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Alex Deucher
commit 4543eda52113d1e2cc0e9bf416f79597e6ef1ec7 upstream.
Need to swap the data fetched over i2c properly. This
is the same fix as the endian fix for aux channel
transactions.
This is the start of the stable review cycle for the 3.0.98 release.
There are 17 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Tue Oct 1 19:07:47 UTC 2013.
Anything
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Kees Cook
commit 78214e81a1bf43740ce89bb5efda78eac2f8ef83 upstream.
The zeroplus HID driver was not checking the size of allocated values
in fields it used. A HID device could send a malicious
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Stanislaw Gruszka
commit 6e956da2027c767859128b9bfef085cf2a8e233b upstream.
We should not do temperature compensation on devices without
EXTERNAL_TX_ALC bit set (called DynamicTxAgcControl on
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Kees Cook
commit 331415ff16a12147d57d5c953f3a961b7ede348b upstream.
Many drivers need to validate the characteristics of their HID report
during initialization to avoid misusing the reports.
On Sun, Sep 29, 2013 at 07:10:47PM +0100, Al Viro wrote:
> FWIW, right now I'm reviewing the subset of fs code that can be hit in
> RCU mode. Not a pretty sight, that... ;-/ First catch: in
[snip]
and another, this one completely unrelated to RCU:
unsigned long gen = (unsigned
On Sun, Sep 29, 2013 at 07:10:47PM +0100, Al Viro wrote:
> FWIW, right now I'm reviewing the subset of fs code that can be hit in
> RCU mode. Not a pretty sight, that... ;-/ First catch: in
> fuse_dentry_revalidate() we have a case (reachable with LOOKUP_RCU) where
> we do this:
> } else
On Sun, Sep 29, 2013 at 01:34:08AM -0300, Emilio López wrote:
> >>Also, would any special considerations be needed when adjusting the
> >>ahb clock? A future cpufreq driver will most likely need to.
> >
> >While this will be needed at some point, I don't really see how to
> >handle that properly.
Hello.
Paul, Peter, et al, could you review the code below?
I am not sending the patch, I think it is simpler to read the code
inline (just in case, I didn't try to compile it yet).
It is functionally equivalent to
struct xxx_struct {
atomic_t counter;
};
On Sun, Sep 29, 2013 at 11:10 AM, Al Viro wrote:
>
> FWIW, right now I'm reviewing the subset of fs code that can be hit in
> RCU mode. Not a pretty sight, that... ;-/ First catch: in
> fuse_dentry_revalidate() we have a case (reachable with LOOKUP_RCU) where
> we do this:
> } else if
Hi,
Am Thu, 26 Sep 2013 16:54:47 +0200
schrieb Ulf Hansson :
> Suspend and resume of cards are being handled from the protocol layer
> and consequently the mmc_suspend|resume_host APIs are deprecated.
>
> This means we can simplify the suspend|resume callbacks by removing
> the use of the
On Sun, Sep 29, 2013 at 10:19:59AM -0700, Linus Torvalds wrote:
> I have to say, that when I was working with the dcache lockref code, I
> absolutely _detested_ the magical shrink_dcache_for_umount() code that
> violated all the locking rules.
... and duplicated random-half-of-an-arseload of
Hello everyone,
I would like to write a driver to support the "Security System" hardware
block on some Allwinner ARM SoCs. The hardware supports AES, DES, 3DES,
SHA-1, MD5 and has a PRNG. Data passing is done via two FIFOs. You can
find some ugly userspace code to calculate a SHA1 hash here,
On Sun, Sep 29, 2013 at 06:52:36PM +0100, Mark Brown wrote:
> On Sun, Sep 29, 2013 at 03:11:37PM +0100, Charles Keepax wrote:
>
> > There is currently only one other MFD driver (tps65910) which defines
> > the GPIOs on the main MFD node as we do in the Arizona driver and it
> > uses the 'hack'
On Sun, Sep 29, 2013 at 01:54:00PM -0400, Austin S Hemmelgarn wrote:
> From: Austin S. Hemmelgarn
>
> This patch adds Kconfig options to allow optimization for AMD family
> 10h, AMD Bulldozer, and AMD Piledriver derived CPU's in version
> 3.12-rc2. These provide noticeable improvements over the
From: Austin S. Hemmelgarn
This patch adds Kconfig options to allow optimization for AMD family
10h, AMD Bulldozer, and AMD Piledriver derived CPU's in version
3.12-rc2. These provide noticeable improvements over the K8 config
option, and allow the kernel to take full advantage of AMD specific
On Sun, Sep 29, 2013 at 03:11:37PM +0100, Charles Keepax wrote:
> There is currently only one other MFD driver (tps65910) which defines
> the GPIOs on the main MFD node as we do in the Arizona driver and it
> uses the 'hack' that I suggested in my first email of copying the
> of_node.
>
On 09/29/2013 10:51 AM, Lars-Peter Clausen wrote:
The 'driver' field of the i2c_client struct is redundant and is going to be
removed. The results of the expressions 'client->driver.driver->field' and
'client->dev.driver->field' are identical, so replace all occurrences of the
former with the
On 09/29/2013 10:50 AM, Lars-Peter Clausen wrote:
The 'driver' field of the i2c_client struct is redundant and is going to be
removed. The results of the expressions 'client->driver.driver->field' and
'client->dev.driver->field' are identical, so replace all occurrences of the
former with the
On Sun, Sep 29, 2013 at 10:50:58AM +0200, Lars-Peter Clausen wrote:
> This series removes the redundant driver field from the i2c_client struct. The
> field is redundant since the same pointer can be accessed through
> to_i2c_driver(client->dev.driver). The commit log suggests that the field has
On Sat, Sep 28, 2013 at 11:06 PM, Al Viro wrote:
>
> Sigh... Looks like there's a lot of fun in shrink_dcache_for_umount() -
> at the very least, it needs to bump ->d_seq on everything, because with
> that change we *can* walk into a filesystem in the middle of that.
> We obviously don't want to
On 09/29/2013 08:14 AM, Richard Weinberger wrote:
> On Sun, Sep 29, 2013 at 7:22 AM, Pádraig Brady wrote:
>> On 09/25/2013 03:37 PM, richard -rw- weinberger wrote:
>>> On Wed, Sep 25, 2013 at 4:28 PM, Thomas Meyer wrote:
Am Mittwoch, den 25.09.2013, 08:59 -0500 schrieb Rob Landley:
> On
Please keep me in CC.
CCing Borislav Petkov , intel-...@lists.freedesktop.org,
dri-de...@lists.freedesktop.org as they were on another part of this thread.
Chris Wilson wrote:
> > > I receive a warning in drivers/gpu/drm/i915/intel_display.c:3869. This
> > > happens when I'm on a console, the
On Sun, Sep 29, 2013 at 4:45 PM, Hannes Frederic Sowa
wrote:
> On Sun, Sep 29, 2013 at 10:40:11AM +0100, Oussama Ghorbel wrote:
>> On Fri, Sep 27, 2013 at 6:03 PM, Hannes Frederic Sowa
>> wrote:
>> > Ok, let's go with one function per protocol type. Seems easier.
>> >
>> > It seems to get more
According to board schematics, for HSMMC1 a GPIO line is used to detect
card presence, while currently it is being configured for internal card
detect line, which is multiplexed with card detect line of HSMMC0 and
thus breaking it.
This patch adds proper sdhci platform data setting card detect
On Saturday 28 of September 2013 23:00:27 Alan Stern wrote:
> On Sat, 28 Sep 2013, Tomasz Figa wrote:
> > A series of commit starting at
> >
> > 50a97e059b USB: OHCI: make ohci-exynos a separate driver
> >
> > and ending at
> >
> > b8ad5c3706 USB: OHCI: make ohci-pxa27x a separate driver
> >
>
On 29/09/2013 12:02, Bo Shen wrote:
> Hi Alexandre,
> [snip]
> Thank for point out this.
>
> I see you have sent out a patch to fix it (however the other contents
> of your patch doesn't work). So, do you prefer I send out v5 patch to
> fix this? or you fix your patch at same time fix this issue?
On Sun, 2013-09-29 at 17:44 +0300, Gleb Natapov wrote:
> On Sun, Sep 29, 2013 at 07:52:28AM -0600, Alex Williamson wrote:
> > On Sun, 2013-09-29 at 16:16 +0300, Gleb Natapov wrote:
> > > On Thu, Sep 12, 2013 at 03:23:15PM -0600, Alex Williamson wrote:
> > > > So far we've succeeded at making KVM
On 29/09/2013 12:12, Bo Shen wrote:
> Hi Alexandre,
>
> On 9/28/2013 04:10, Alexandre Belloni wrote:
>> I found that disabling a pwm while it is at a low level will actually
>> put it
>> back at a high level. The main symptom is that leds-pwm is calling
>> pwm_disable()
>> after setting the duty
On Sun, Sep 29, 2013 at 10:40:11AM +0100, Oussama Ghorbel wrote:
> On Fri, Sep 27, 2013 at 6:03 PM, Hannes Frederic Sowa
> wrote:
> > Ok, let's go with one function per protocol type. Seems easier.
> >
> > It seems to get more hairy, because it depends on the tunnel driver if the
> > prepended ip
If the goal is to feed this to the field width in printf, which I would think
would be the dominant use, then you do have to account for the minus sign.
Borislav Petkov wrote:
>On Sat, Sep 28, 2013 at 04:13:29PM -0700, H. Peter Anvin wrote:
>> For negative numbers presumably we need to d++ for
From: Tyler Hicks
Use the shash interface, rather than the hash interface, when hashing
AppArmor profiles. The shash interface does not use scatterlists and it
is a better fit for what AppArmor needs.
This fixes a kernel paging BUG when aa_calc_profile_hash() is passed a
buffer from vmalloc().
James,
could you pull and forward the follow fixes for the 3.12 kernel. Both
issues have had multiple reports.
thanks
---
The following changes since commit eb8948a03704f3dbbfc7e83090e20e93c6c476d2:
X.509: remove possible code fragility: enumeration values not handled
(2013-09-25 17:17:01
The recent 3.12 pull request for apparmor was missing a couple rcu _protected
access modifiers. Resulting in the follow suspicious RCU usage
[ 29.804534] [ INFO: suspicious RCU usage. ]
[ 29.804539] 3.11.0+ #5 Not tainted
[ 29.804541] ---
[ 29.804545]
On 2 September 2013 18:23, Valentin Ilie wrote:
> Convert a compound if-else blob to a switch statement.
>
> Signed-off-by: Valentin Ilie
> ---
> arch/arm/mach-iop32x/iq31244.c | 29 +++--
> 1 file changed, 11 insertions(+), 18 deletions(-)
>
> diff --git
From: Borislav Petkov
Turn it into (for example):
[0.073380] x86: Booting SMP configuration:
[0.074005] node #0, CPUs: #1 #2 #3 #4 #5 #6 #7
[0.603005] node #1, CPUs: #8 #9 #10 #11 #12 #13 #14 #15
[1.25] node #2, CPUs:
On Sun, Sep 29, 2013 at 04:58:39PM +0200, Borislav Petkov wrote:
> Let's CC some more people.
Please boot with drm.debug=0xe, reproduce the WARN and then attach the
full dmesg.
Thanks, Daniel
>
> On Sun, Sep 29, 2013 at 10:17:34AM -0400, Wakko Warner wrote:
> > Wakko Warner wrote:
> > > Please
Btw,
while I got your attention, on a not-really related topic: how do we
feel about adding support for specifying a non-contiguous set of cpus
for a numa node in qemu with the -numa option? I.e., like this, for
example:
x86_64-softmmu/qemu-system-x86_64 -smp 8 -numa node,nodeid=0,cpus=0\;2\;4-5
On Sun, Sep 29, 2013 at 10:17:34AM -0400, Wakko Warner wrote:
> Wakko Warner wrote:
> > Please keep me in CC.
> >
> > I receive a warning in drivers/gpu/drm/i915/intel_display.c:3869. This
> > happens when I'm on a console, the screen has gone into power save and I
> > press a key to wake it up.
Let's CC some more people.
On Sun, Sep 29, 2013 at 10:17:34AM -0400, Wakko Warner wrote:
> Wakko Warner wrote:
> > Please keep me in CC.
> >
> > I receive a warning in drivers/gpu/drm/i915/intel_display.c:3869. This
> > happens when I'm on a console, the screen has gone into power save and I
>
On Sun, Sep 29, 2013 at 07:52:28AM -0600, Alex Williamson wrote:
> On Sun, 2013-09-29 at 16:16 +0300, Gleb Natapov wrote:
> > On Thu, Sep 12, 2013 at 03:23:15PM -0600, Alex Williamson wrote:
> > > So far we've succeeded at making KVM and VFIO mostly unaware of each
> > > other, but there's any
* Markus Trippelsdorf wrote:
> On 2013.09.28 at 20:03 +0200, Ingo Molnar wrote:
> > Andi Kleen (1):
> > perf symbols: Demangle cloned functions
>
> The commit above e95ab53645:
>
> commit de95ab53645a2f0015e0f68ee723f18dce2b8b51
> Author: Andi Kleen
> Date: Thu Sep 12 08:16:38
Wakko Warner wrote:
> Please keep me in CC.
>
> I receive a warning in drivers/gpu/drm/i915/intel_display.c:3869. This
> happens when I'm on a console, the screen has gone into power save and I
> press a key to wake it up.
>
> This doesn't happen when I'm in X.
>
> Kernel is Vanilla 3.11.2.
On Sat, Sep 28, 2013 at 11:55:35PM +0100, Mark Brown wrote:
> No, having the supplies bound to the parent is desired (especially given
> that there isn't a child node) - it's the fact that you're bodging this
> in the framework by just randomly peering at the parent device and
> hoping it's an MFD
On 09/27, Oleg Nesterov wrote:
>
> I tried hard to find any hole in this version but failed, I believe it
> is correct.
And I still believe it is. But now I am starting to think that we
don't need cpuhp_seq. (and imo cpuhp_waitcount, but this is minor).
> We need to ensure 2 things:
>
> 1. The
On Sun, 2013-09-29 at 16:16 +0300, Gleb Natapov wrote:
> On Thu, Sep 12, 2013 at 03:23:15PM -0600, Alex Williamson wrote:
> > So far we've succeeded at making KVM and VFIO mostly unaware of each
> > other, but there's any important point where that breaks down. Intel
> > VT-d hardware may or may
201 - 300 of 682 matches
Mail list logo
