3.8.13.27 -stable review patch. If anyone has any objections, please let me
know.
--
From: Hans de Goede
commit cd9e83e2754465856097f31c7ab933ce74c473f8 upstream.
At least the Dell Vostro 5470 elantech *clickpad* reports right button
clicks when clicked in the right bottom
3.8.13.27 -stable review patch. If anyone has any objections, please let me
know.
--
From: "J. Bruce Fields"
commit 48385408b45523d9a432c66292d47ef43efcbb94 upstream.
27b11428b7de ("nfsd4: remove lockowner when removing lock stateid")
introduced a memory leak.
Reported-by:
3.8.13.27 -stable review patch. If anyone has any objections, please let me
know.
--
From: Hugh Dickins
commit 7f39dda9d86fb4f4f17af0de170decf125726f8c upstream.
Trinity reports BUG:
sleeping function called from invalid context at kernel/locking/rwsem.c:47
in_atomic():
3.8.13.27 -stable review patch. If anyone has any objections, please let me
know.
--
From: Viresh Kumar
commit 938626d96a3ffb9eb54552bb0d3a4f2b30ffdeb0 upstream.
Implementation of ->set_timeout() is supposed to set 'timeout' field of 'struct
watchdog_device' passed to it.
3.8.13.27 -stable review patch. If anyone has any objections, please let me
know.
--
From: Dwight Engen
commit fd5e2aa8653665ae1cc60f7aca1069abdbcad3f6 upstream.
Use inode_capable() to check if SUID|SGID bits should be cleared to match
similar check in inode_change_ok().
3.8.13.27 -stable review patch. If anyone has any objections, please let me
know.
--
From: Tony Luck
commit a70ffcac741d31a406c1d2b832ae43d658e7e1cf upstream.
When a thread in a multi-threaded application hits a machine check because
of an uncorrectable error in memory - we
3.8.13.27 -stable review patch. If anyone has any objections, please let me
know.
--
From: Mel Gorman
commit e58469bafd0524e848c3733bc3918d854595e20f upstream.
The test_bit operations in get/set pageblock flags are expensive. This
patch reads the bitmap on a word basis and
3.8.13.27 -stable review patch. If anyone has any objections, please let me
know.
--
From: Mel Gorman
commit 675becce15f320337499bc1a9356260409a5ba29 upstream.
throttle_direct_reclaim() is meant to trigger during swap-over-network
during which the min watermark is treated as
3.8.13.27 -stable review patch. If anyone has any objections, please let me
know.
--
From: Michal Hocko
commit d8dc595ce3909fbc131bdf5ab8c9808fe624b18d upstream.
Eric has reported that he can see task(s) stuck in memcg OOM handler
regularly. The only way out is to
On Tue, Jul 22, 2014 at 3:21 PM, Kamal Mostafa wrote:
> 3.8.13.27 -stable review patch. If anyone has any objections, please let me
> know.
>
> --
>
> From: Andy Lutomirski
>
> commit 554086d85e71f30abe46fc014fea31929a7c6a8a upstream.
>
> The bad syscall nr paths are their own
3.8.13.27 -stable review patch. If anyone has any objections, please let me
know.
--
From: Bart Van Assche
commit 024ca90151f5e4296d30f72c13ff9a075e23c9ec upstream.
Avoid that the loops that iterate over the request ring can encounter
a pointer to a SCSI command in
3.8.13.27 -stable review patch. If anyone has any objections, please let me
know.
--
From: Kailang Yang
commit b6c5fbad16aa5026f508093a8d651c25e1cb6179 upstream.
New codec support for ALC891.
Signed-off-by: Kailang Yang
Signed-off-by: Takashi Iwai
Signed-off-by: Kamal
3.8.13.27 -stable review patch. If anyone has any objections, please let me
know.
--
From: Jukka Taimisto
commit 8a96f3cd22878fc0bb564a8478a6e17c0b8dca73 upstream.
-[0x01 Introduction
We have found a programming error causing a deadlock in Bluetooth subsystem
of Linux
3.8.13.27 -stable review patch. If anyone has any objections, please let me
know.
--
From: Anton Blanchard
commit 5d73320a96fcce80286f1447864c481b5f0b96fa upstream.
commit 8f9c0119d7ba (compat: fs: Generic compat_sys_sendfile
implementation) changed the PowerPC 64bit
3.8.13.27 -stable review patch. If anyone has any objections, please let me
know.
--
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Carretero?=
commit d251836508fb26cd1a22b41381739835ee23728d upstream.
This device normally comes with a proprietary driver, using a web GUI
to configure
3.8.13.27 -stable review patch. If anyone has any objections, please let me
know.
--
From: Russell King
commit 3683f44c42e991d313dc301504ee0fca1aeb8580 upstream.
While debugging the FEC ethernet driver using stacktrace, it was noticed
that the stacktraces always begin as
3.8.13.27 -stable review patch. If anyone has any objections, please let me
know.
--
From: Kees Cook
commit 1b15d2e5b8077670b1e6a33250a0d9577efff4a5 upstream.
Some drivers use the first HID report in the list instead of using an
index. In these cases, validation uses ID 0,
3.8.13.27 -stable review patch. If anyone has any objections, please let me
know.
--
From: Mike Marciniszyn
commit 911eccd284d13d78c92ec4f1f1092c03457d732a upstream.
The code used a literal 1 in dispatching an IB_EVENT_PKEY_CHANGE.
As of the dual port qib QDR card, this is
3.8.13.27 -stable review patch. If anyone has any objections, please let me
know.
--
From: Andy Lutomirski
commit 554086d85e71f30abe46fc014fea31929a7c6a8a upstream.
The bad syscall nr paths are their own incomprehensible route
through the entry control flow. Rearrange them
3.8.13.27 -stable review patch. If anyone has any objections, please let me
know.
--
From: Steve French
commit ce36d9ab3bab06b7b5522f5c8b68fac231b76ffb upstream.
When we SMB3 mounted with mapchars (to allow reserved characters : \ / > < * ?
via the Unicode Windows to POSIX
3.8.13.27 -stable review patch. If anyone has any objections, please let me
know.
--
From: Stanislaw Gruszka
commit 616a8394b5df8c88f4dd416f4527439a4e365034 upstream.
As reported by Niels, starting rfkill polling during device probe
(commit e2bc7c5, generally sane change)
On Tuesday 22 July 2014 17:33:50 Matt Porter wrote:
>
> > > For the reset of mach-bcm stuff, I'll just send an arm-soc pull request
> > > soon enough, unless Matt/Arnd/Olof object.
> >
> > I'll wait for Matt to comment before pulling it, otherwise that sounds
> > fine.
>
> I'm fine with it, but
3.8.13.27 -stable review patch. If anyone has any objections, please let me
know.
--
From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=
commit 2fc68eb122c7ea6cd5be1fe7d6650c0beb2f4f40 upstream.
Support for firmware rev 508+ was added years ago, but we never noticed
it reports
3.8.13.27 -stable review patch. If anyone has any objections, please let me
know.
--
From: Mikulas Patocka
commit 81a9c5e72bdf7109a65102ca61d8cbd722cf4021 upstream.
On uniprocessor preemptible kernel, target core deadlocks on unload. The
following events happen:
*
3.8.13.27 -stable review patch. If anyone has any objections, please let me
know.
--
From: Hugh Dickins
commit d05f0cdcbe6388723f1900c549b4850360545201 upstream.
In v2.6.34 commit 9d8cebd4bcd7 ("mm: fix mbind vma merge problem")
introduced vma merging to mbind(), but it
3.8.13.27 -stable review patch. If anyone has any objections, please let me
know.
--
From: Johan Hedberg
commit ba15a58b179ed76a7e887177f2b06de12c58ec8f upstream.
>From the Bluetooth Core Specification 4.1 page 1958:
"if both devices have set the Authentication_Requirements
On Tue, Jul 22, 2014 at 11:42:06AM +0100, Richard Fitzgerald wrote:
> Changes to the AIF configuration registers only take
> effect when the AIF is disabled. If the configuration
> is being changed from the previous setup, temporarily
> disable the AIF.
Applied, thanks.
signature.asc
3.8.13.27 -stable review patch. If anyone has any objections, please let me
know.
--
From: Will Deacon
commit 34c65c43f1518bf85f93526ad373adc6a683b4c5 upstream.
Whilst native arm64 applications don't have the 16-bit UID/GID syscalls
wired up, compat tasks can still access
3.8.13.27 -stable review patch. If anyone has any objections, please let me
know.
--
From: Marcin Kraglak
commit 92d1372e1a9fec00e146b74e8b9ad7a385b9b37f upstream.
Kernel supports SMP Security Request so don't block increasing security
when we are slave.
Signed-off-by:
3.8.13.27 -stable review patch. If anyone has any objections, please let me
know.
--
From: ChiaHao
commit 3906c2b53cd23c2ae03e6ce41432c8e7f0a3cbbb upstream.
The value of ESR has been stored into x1, and should be directly pass to
do_sp_pc_abort function, "MOV x1, x25" is an
3.8.13.27 -stable review patch. If anyone has any objections, please let me
know.
--
From: Greg Kroah-Hartman
commit b29f680c4fe305902d02c1d5aa4968fe13a45fe6 upstream.
This reverts commit ddb09754e6c7239e302c7b675df9bbd415f8de5d.
Linus objected to this originally, I can see
3.8.13.27 -stable review patch. If anyone has any objections, please let me
know.
--
From: Johan Hedberg
commit e694788d73efe139b24f78b036deb97fe57fa8cb upstream.
The conn->link_key variable tracks the type of link key in use. It is
set whenever we respond to a link key
3.8.13.27 -stable review patch. If anyone has any objections, please let me
know.
--
From: Dan Carpenter
commit 4f3bcd878f1d3c730fe00f619b7260c6125d49eb upstream.
at91_adc_get_trigger_value_by_name() was returning -ENOMEM truncated to
a positive u8 and that doesn't work.
3.8.13.27 -stable review patch. If anyone has any objections, please let me
know.
--
From: Mario Schuknecht
commit c404618cd06dad771495fe1cf9d5a63b5664f65f upstream.
Consider high byte of proximity min and max treshold in function
'tsl2x7x_chip_on'. So far, the high byte was
On Tue, Jul 22, 2014 at 11:50:22AM +0100, Richard Fitzgerald wrote:
> Different playback and capture bits-per-sample
> are not supported on the AIFs
Applied all, thanks.
signature.asc
Description: Digital signature
This is the start of the review cycle for the Linux 3.8.13.27 stable kernel.
This version contains 116 new patches, summarized below. The new patches are
posted as replies to this message and also available in this git branch:
On 07/18/14 17:14, John Stultz wrote:
> On 07/18/2014 04:24 PM, Stephen Boyd wrote:
>> On 07/18/14 15:42, John Stultz wrote:
>>> If its a regression (and needs -stable backports) it needs to go in via
>>> tip/timers/urgent, and not via the regular merge window.
>>>
>>> Whats the additional risk
On Tue, Jul 22, 2014 at 3:11 PM, Luis R. Rodriguez wrote:
> On Tue, Jul 22, 2014 at 1:55 PM, Kees Cook wrote:
>> On Tue, Jul 22, 2014 at 12:39 PM, Luis R. Rodriguez wrote:
>>> On Mon, Jul 14, 2014 at 3:31 PM, Kees Cook wrote:
Yup, with this and the module hook, adding a similar hook for
On Tue, Jul 22, 2014 at 6:13 PM, David Rientjes wrote:
> On Tue, 22 Jul 2014, Nick Krause wrote:
>
>> >> This patch removes a fix me by including linux/types.h in kvm_para.h
>> >> as stated by the fix me in main.c and also removes the comment from
>> >> main.c too.
>> >>
>> >> Signed-off-by:
This is a note to let you know that I have just added a patch titled
recordmcount/MIPS: Fix possible incorrect mcount_loc table entries in
modules
to the linux-3.8.y-queue branch of the 3.8.y.z extended stable tree
which can be found at:
Try three...
---
Hi again,
Playing some more with the new kernel release i noticed this:
[ 9064.008821] WARNING: CPU: 3 PID: 22929 at
drivers/gpu/drm/i915/intel_pm.c:5997 intel_display_power_put+0x12d/0x160()
[ 9064.008822] Modules linked in: uas bnep b43 mac80211 cfg80211
On Tue, 22 Jul 2014, Madhavan Srinivasan wrote:
> On Tuesday 22 July 2014 05:38 AM, David Rientjes wrote:
> > On Tue, 22 Jul 2014, Madhavan Srinivasan wrote:
> >
> >> Commit 4b358e2206 "cleanup include/asm-generic/atomic.h" added
> >> comments for #else/#endif, but ended up adding same comment
>
On Fri, May 23 2014 at 5:28pm -0400,
Pekka Enberg wrote:
> On 05/23/2014 11:16 PM, Mike Snitzer wrote:
> >On Tue, Mar 25 2014 at 2:07pm -0400,
> >Christoph Lameter wrote:
> >
> >>On Tue, 25 Mar 2014, Mike Snitzer wrote:
> >>
> >>>This patch still isn't upstream. Who should be shepherding it
On Tue, 22 Jul 2014, Nick Krause wrote:
> >> This patch removes a fix me by including linux/types.h in kvm_para.h
> >> as stated by the fix me in main.c and also removes the comment from
> >> main.c too.
> >>
> >> Signed-off-by: Nicholas Krause
> >> ---
> >> arch/x86/kernel/cpu/mtrr/main.c | 2
On Tue, Jul 22, 2014 at 1:55 PM, Kees Cook wrote:
> On Tue, Jul 22, 2014 at 12:39 PM, Luis R. Rodriguez wrote:
>> On Mon, Jul 14, 2014 at 3:31 PM, Kees Cook wrote:
>>> Yup, with this and the module hook, adding a similar hook for kexec
>>> makes sense as well. A paranoid kernel doesn't want to
This function will help an async task processing batched jobs from workqueue
decide if it wants to keep processing on more chunks of batched work that
can be delayed, or to accumulate more work for more efficient batched
processing later.
If no other tasks are running on the cpu, it can take
The crypto daemon can take advantage of available cpu
cycles to flush any unfinished jobs if it is the
only task running on the cpu, and there are no more crypto
jobs to process.
Signed-off-by: Tim Chen
---
crypto/mcryptd.c | 39 ---
1 file changed, 36
This patch introduces the multi-buffer scheduler which is responsible
for submitting scatter-gather buffers from several SHA1 jobs to the
multi-buffer algorithm. It also contains the flush routine to that's
called by the crypto daemon to complete the job when no new jobs arrive
before the
This patch introduces the assembly routines to do SHA1 computation on
buffers belonging to serveral jobs at once. The assembly routines are
optimized with AVX2 instructions that have 8 data lanes and using AVX2
registers.
Signed-off-by: Tim Chen
---
arch/x86/crypto/sha-mb/sha1_x8_avx2.S | 472
This patch introduces the data structures and prototypes of functions
needed for computing SHA1 hash using multi-buffer. Included are the
structures of the multi-buffer SHA1 job, job scheduler in C and x86
assembly.
Signed-off-by: Tim Chen
---
arch/x86/crypto/sha-mb/sha1_mb_mgr_datastruct.S |
Herbert,
I've updated my implementation from v4 to have the multi-buffer daemon
flush the jobs if there're no other jobs running on the cpu. The flusher
logic is reorganized so it is contained in mcryptd per Peter's feedback.
The multi-buffer crypto daemon now directly takes advantage of the cpu
This patch introduces the routines used to submit and flush buffers
belonging to SHA1 crypto jobs to the SHA1 multibuffer algorithm. It is
implemented mostly in assembly optimized with AVX2 instructions.
Signed-off-by: Tim Chen
---
arch/x86/crypto/sha-mb/sha1_mb_mgr_flush_avx2.S | 327
This patch introduces the multi-buffer crypto daemon which is responsible
for submitting crypto jobs in a work queue to the responsible multi-buffer
crypto algorithm. The idea of the multi-buffer algorihtm is to put
data streams from multiple jobs in a wide (AVX2) register and then
take advantage
On Tue, Jul 22, 2014 at 6:06 PM, David Rientjes wrote:
> On Tue, 22 Jul 2014, Nicholas Krause wrote:
>
>> This patch removes a fix me by including linux/types.h in kvm_para.h
>> as stated by the fix me in main.c and also removes the comment from
>> main.c too.
>>
>> Signed-off-by: Nicholas
On Tuesday, July 22, 2014 02:13:45 PM Peter Zijlstra wrote:
> On Tue, Jul 22, 2014 at 02:23:03PM +0200, Rafael J. Wysocki wrote:
> > > Doesn't break, doesn't 'work' either.
> >
> > This probably means that WoL on that machine is not ACPI-based.
>
> Oh lovely, of course that's an 'option' !
>
>
On Tue, 22 Jul 2014, Nicholas Krause wrote:
> This patch removes a fix me by including linux/types.h in kvm_para.h
> as stated by the fix me in main.c and also removes the comment from
> main.c too.
>
> Signed-off-by: Nicholas Krause
> ---
> arch/x86/kernel/cpu/mtrr/main.c | 2 +-
>
- Original Message -
> Commit 8b7de6aa8468: "vmwgfx: Rework fence event action" removed the
> tv_sec & tv_usec arguments to vmw_event_fence_action_create, which meant
> that both sides of the if/else are now exactly the same.
>
> Remove the flag check, and just do it unconditionally.
>
>
On Tue, Jul 22, 2014 at 10:08:26PM +0200, Guillaume Clement wrote:
> PortOffset was an unsigned long, but used as an pointer to io
> memory. Sometimes it was not properly cast before use, which caused
> many warning by sparse.
>
> By updating its type to void __iomem *, and reflecting the changes
On Tuesday, July 22, 2014 01:25:00 AM Zheng, Lv wrote:
> Hi, Rafael
>
> > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> > Sent: Tuesday, July 22, 2014 9:12 AM
> >
> > On Monday, July 21, 2014 02:04:51 PM Lv Zheng wrote:
> > > Note that this patchset is very stable now, it is sent as RFC
On Wednesday, July 23, 2014 12:43:39 AM Arjun Sreedharan wrote:
> Handle error condition since pnpacpi_parse_allocated_resource() and
> pnpacpi_parse_resource_option_data() could return -EPERM.
>
> Signed-off-by: Arjun Sreedharan
I wonder if this fixes any functional issue you've seen or
On Tue, Jul 22, 2014 at 02:23:27PM -0600, Alex Williamson wrote:
> On Tue, 2014-07-22 at 13:55 -0600, Bjorn Helgaas wrote:
> > On Wed, Jul 16, 2014 at 01:14:08PM -0600, Alex Williamson wrote:
> > > There are numerous ATI/AMD GPUs available that report that they
> > > support a PM reset
On Sat, Jul 12, 2014 at 11:33 AM, Linus Walleij
wrote:
> From: Dmitry Artamonow
>
> This adds a driver for reading the battery status of the
> battery connected to the Atmel microcontroller on the
> iPAQ h3xxx series.
>
> Based on a driver from handhelds.org 2.6.21 kernel, written
> by
Hello list,
I have just found out about this mailing list which obviously also takes
care of overlayfs.
I have been a happy user of overlayfs for quiet some time using it to
propagate a shared r/o LVM ext4 lowerdir rootfs with a small r/w ext4
upperdir for a number of XEN domU guests. I
This patch removes a fix me by including linux/types.h in kvm_para.h
as stated by the fix me in main.c and also removes the comment from
main.c too.
Signed-off-by: Nicholas Krause
---
arch/x86/kernel/cpu/mtrr/main.c | 2 +-
include/linux/kvm_para.h| 3 +--
2 files changed, 2
On Thu, Jul 17, 2014 at 12:41 PM, Ivan T. Ivanov wrote:
> From: "Ivan T. Ivanov"
>
Hi Ivan,
Sorry for the slow response, I wanted to respin my pm8xxx-gpio driver to figure
out some resonable answers to you.
> Available 'power-source' labels differ between chips.
> Use just VIN0-VIN14 in the
The dividend in do_div() is expected to be an unsigned 64-bit integer,
which leads to the following warning when building for 32-bit MIPS:
drivers/net/wireless/mac80211_hwsim.c: In function 'mac80211_hwsim_set_tsf':
drivers/net/wireless/mac80211_hwsim.c:664:98: warning: comparison of distinct
Am Montag, 14. Juli 2014, 21:04:26 schrieb Beniamino Galvani:
> On Sun, Jul 13, 2014 at 02:37:40PM +0200, Heiko Stübner wrote:
> > Am Sonntag, 13. Juli 2014, 14:10:01 schrieb Beniamino Galvani:
> > > This adds a device tree node for the infrared receiver connected to a
> > > GPIO pin on the Radxa
Hi,
On Wed, Jul 9, 2014 at 5:17 AM, Antoine Ténart
wrote:
> Before using the PHY framework instead of the USB PHY one, we need to
> move the OTG state into another place, since it won't be available when
> USB PHY isn't used. This patch moves the OTG state into the OTG
> structure, and makes all
On Thu, Jul 17, 2014 at 02:30:39PM +0530, Kishon Vijay Abraham I wrote:
> Changes from v2:
> * Added myself as MAINTAINER of pcie dra7xx driver
>
> Changes from v1:
> * fixed dw_pcie_prog_viewport_io_outbound() to use untranslated address
> * split dra7xx patch into driver part and documentation
On Tue, Jul 22, 2014 at 10:57:17PM +0200, Arnd Bergmann wrote:
> On Tuesday 22 July 2014 13:44:31 Brian Norris wrote:
> > > For the platform changes in the first patch, I would prefer to have
> > > Matt pick up the first patch, but we can also apply it directly into
> > > arm-soc if he prefers
On Tue, Jul 22, 2014 at 04:56:59PM -0400, Jeff Oczek wrote:
> On Tue, Jul 22, 2014 at 01:17:22PM -0700, Greg KH wrote:
> > On Tue, Jul 22, 2014 at 04:07:51PM -0400, Jeff Oczek wrote:
> > > Put extern declarations in cxt1e1_common.h to reduce sparse warnings for
> > > linux.c:
> >
> > I know you
On Tue, Jul 22, 2014 at 09:46:46PM +0300, Grygorii Strashko wrote:
> I'm not sure, this optimization is safe (
> Because, in many cases the access to PMIC IC needs to be allowed till late
> stages of suspending (at least till suspend_noirq stage or even later).
> For example, on some OMAP SoC
On 07/22/2014 02:10 PM, Andy Lutomirski wrote:
> On Tue, Jul 22, 2014 at 2:08 PM, H. Peter Anvin wrote:
>> On 07/22/2014 02:04 PM, Andy Lutomirski wrote:
>>>
>>> Just to check: do you mean the RDRAND is very likely to work (i.e.
>>> arch_get_random_long will return true) or that RDRAND will
On Tue, Jul 22, 2014 at 2:08 PM, H. Peter Anvin wrote:
> On 07/22/2014 02:04 PM, Andy Lutomirski wrote:
>>
>> Just to check: do you mean the RDRAND is very likely to work (i.e.
>> arch_get_random_long will return true) or that RDRAND will actually
>> reseed several times during initialization?
>>
On Tuesday 22 July 2014 14:53:26 Bjorn Helgaas wrote:
> > @@ -2,6 +2,10 @@
> >
> > Required properties:
> > - compatible: should contain "snps,dw-pcie" to identify the core.
> > +- reg: Should contain the configuration address space.
> > +- reg-names: Must be "config" for the PCIe
static void __init irq_pm_init(void)
382 {
383 /* FIXME: Remove this when MPU OSWR support is added */
384 if (!soc_is_omap54xx())
385 cpu_pm_register_notifier(_notifier_block);
386 }
I am wondering is this omap supported now if it is can I remove it?
Cheers Nick
--
On Tue, Jul 22, 2014 at 2:20 AM, Tomasz Nowicki
wrote:
> APEI is currently implemented so that it depends on x86 hardware.
> The primary dependency is that GHES uses the x86 NMI for hardware
> error notification and MCE for memory error handling. These patches
> remove that dependency.
>
> Other
On 07/22/2014 02:04 PM, Andy Lutomirski wrote:
>
> Just to check: do you mean the RDRAND is very likely to work (i.e.
> arch_get_random_long will return true) or that RDRAND will actually
> reseed several times during initialization?
>
I mean that RDRAND will actually reseed several times
:
git diff keys-next-20140717 keys-next-20140722 | diffstat
keys.txt |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
The component subsets are:
(1) Tag keys-preparse-1-20140722
A set of patches that mostly convert extant key types to perform
preparsing to make
On Tue, Jul 22, 2014 at 1:57 PM, H. Peter Anvin wrote:
> On 07/22/2014 01:44 PM, Andy Lutomirski wrote:
>>
>> But, if you Intel's hardware does, in fact, work as documented, then
>> the current code will collect very little entropy on RDSEED-less
>> hardware. I see no great reason that we should
On Tue, Jul 22, 2014 at 07:06:44PM +0100, Arnd Bergmann wrote:
> On Wednesday 02 July 2014, Laura Abbott wrote:
> > + pgprot_t prot = __pgprot(PROT_NORMAL_NC);
> > + unsigned long nr_pages = atomic_pool_size >> PAGE_SHIFT;
> > + struct page *page;
> > + void *addr;
> > +
>
On Tue, 22 Jul 2014, Waiman Long wrote:
> On 07/21/2014 09:01 PM, Thomas Gleixner wrote:
> > So before anyone comes up with a "solution" for all of this tomorrow
> > afternoon in form of another half baken patch, please sit back mull it
> > in your head and lets have a proper discussion about the
On 07/18/2014 09:06 AM, Thierry Reding wrote:
> On Fri, Jul 18, 2014 at 12:28:54PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 07/18/2014 09:16 AM, Mikko Perttunen wrote:
>>> So here's v5: this time, as suggested, I handle the sata clock myself and
>>> let ahci_platform handle it too, leading it
On Tuesday 22 July 2014 13:02:13 Brian Norris wrote:
> How about a third option, where we drop the 'select' statement and
> set POWER_RESET_BRCMSTB to be 'default y'? Then we don't have to modify
> the defconfig, and it gives the added bonus of choosing a sane default
> even if you're not based on
On Tue, 22 Jul 2014, Waiman Long wrote:
> On 07/21/2014 12:42 PM, Thomas Gleixner wrote:
> > > + /*
> > > + * The unlocker may have cleared the TID value and another task may
> > > + * steal it. However, if its TID is still set, we need to clear
> > > + * it as well as the FUTEX_WAITERS bit.
>
On Tuesday 22 July 2014 13:44:31 Brian Norris wrote:
> > For the platform changes in the first patch, I would prefer to have
> > Matt pick up the first patch, but we can also apply it directly into
> > arm-soc if he prefers that.
>
> That brings up a question related to PATCH 11 in the series
On Tue, Jul 22, 2014 at 01:17:22PM -0700, Greg KH wrote:
> On Tue, Jul 22, 2014 at 04:07:51PM -0400, Jeff Oczek wrote:
> > Put extern declarations in cxt1e1_common.h to reduce sparse warnings for
> > linux.c:
>
> I know you didn't name this variable, but wow, that's a horrid name for
> a global
On 07/22/2014 01:44 PM, Andy Lutomirski wrote:
>
> But, if you Intel's hardware does, in fact, work as documented, then
> the current code will collect very little entropy on RDSEED-less
> hardware. I see no great reason that we should do something weaker
> than following Intel's explicit
On Tue, Jul 22, 2014 at 3:33 PM, Steven Rostedt wrote:
> On Tue, Jul 22, 2014 at 02:25:24PM -0400, Nick Krause wrote:
>>
>> I understand what your saying and I should have searched for Page shift.
>> In addition I am already got commits in the kernel for fix mes so I feel
>> that your comment on
On Tue, Jul 22, 2014 at 12:39 PM, Luis R. Rodriguez wrote:
> On Mon, Jul 14, 2014 at 3:31 PM, Kees Cook wrote:
>> Yup, with this and the module hook, adding a similar hook for kexec
>> makes sense as well. A paranoid kernel doesn't want to trust anything
>> it's loading from userspace. :)
>
>
On Thu, Jul 17, 2014 at 02:30:40PM +0530, Kishon Vijay Abraham I wrote:
> The configuration address space has so far been specified in *ranges*,
> however it should be specified in *reg* making it a platform MEM resource.
> Hence used 'platform_get_resource_*' API to get configuration address
>
On Tue, 22 Jul 2014, Waiman Long wrote:
> On 07/22/2014 05:59 AM, Thomas Gleixner wrote:
> > On Tue, 22 Jul 2014, Peter Zijlstra wrote:
> > > On Tue, Jul 22, 2014 at 10:39:17AM +0200, Thomas Gleixner wrote:
> > > > On Tue, 22 Jul 2014, Peter Zijlstra wrote:
> > > > > Anyway, there is one big fail
On Tue, Jul 22, 2014 at 6:59 AM, Theodore Ts'o wrote:
> On Thu, Jul 17, 2014 at 11:22:17AM -0700, Andy Lutomirski wrote:
>> Currently, init_std_data contains its own logic for using arch
>> random sources. This logic is a bit strange: it reads one long of
>> arch random data per byte of internal
+ Sebastian
On Tue, Jul 22, 2014 at 09:35:45AM +0200, Arnd Bergmann wrote:
> On Monday 21 July 2014 14:07:55 Brian Norris wrote:
> > I'm taking over the latest resubmission of this patch series.
> > There are a few moderate changes for v8 (noted below), but we
> > are waiting mostly for an Ack
On Tue, 22 Jul 2014 09:17:45 +0200 Bart Van Assche wrote:
> Evaluating a macro argument only if certain configuration options
> have been selected is confusing and error-prone. Hence always
> evaluate the second argument of spin_lock_nested() and
> spin_lock_nest_lock().
>
> An intentional side
On 07/03/2014 09:01 AM, nick.d...@itdev.co.uk wrote:
> From: Stephen Warren
> diff --git a/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
> b/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
> + touch@4b {
> + compatible = "atmel,maxtouch";
> +
On Tue, Jul 22, 2014 at 01:07:51PM -0700, Kees Cook wrote:
> On Fri, Jul 11, 2014 at 10:36 AM, Cyrill Gorcunov wrote:
> > On Wed, Jul 09, 2014 at 07:06:04PM +0400, Cyrill Gorcunov wrote:
> >>
> >> Thanks a lot for comments, Kees! I tend to agre, leaving off the @prctl_map
> >> variable out of
On Thu, Jul 17, 2014 at 11:22:17AM -0700, Andy Lutomirski wrote:
> Currently, init_std_data contains its own logic for using arch
> random sources. This logic is a bit strange: it reads one long of
> arch random data per byte of internal state.
This isn't true. Check out the init_std_data() a
On 07/03/2014 09:01 AM, nick.d...@itdev.co.uk wrote:
> Hi Dimitry-
>
> Here is another set of atmel_mxt_ts patches for upstream. There are some
> really useful new features, but I hope nothing too controversial.
Unfortunately, I still can't get these to work on my system.
Per your "Re:
From: Quentin Armitage
Date: Tue, 22 Jul 2014 09:10:10 +0100
> Currently, although IP_MULTICAST_ALL and IP_MSFILTER ioctl calls succeed on
> raw sockets, there is no code to implement the functionality on received
> packets; it is only implemented for UDP sockets. The raw(7) man page states:
>
301 - 400 of 2222 matches
Mail list logo
