On Wed, Jan 3, 2018 at 4:03 PM, Stefan Hajnoczi wrote:
> Print the capacity of the block device when the driver is probed. Many
> users expect this since SCSI disks (sd) do it. Moreover, kernel dmesg
> output is the primary source of troubleshooting information so it's
> helpful to include the d
On Fri, Jan 19, 2018 at 12:49:04PM +, yangerkun wrote:
> Hi,
> There is a problem confuses me while reading the soure code about lockdep:
> If thread get a lock first time, kernel will add a hash node in
> chainhash_table, then
> Copy and paste the lock chain and add the new one to tail. But,
On Thu, Jan 18, 2018 at 06:40:07PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> For situations where sysadmins might want to allow different level of
> of access control for different PMUs, we start creating per-PMU
> perf_event_paranoid controls in sysfs.
You've completely and utterl
On Fri, Jan 19 2018 at 11:41am -0500,
Jens Axboe wrote:
> On 1/19/18 9:37 AM, Ming Lei wrote:
> > On Fri, Jan 19, 2018 at 09:27:46AM -0700, Jens Axboe wrote:
> >> On 1/19/18 9:26 AM, Ming Lei wrote:
> >>> On Fri, Jan 19, 2018 at 09:19:24AM -0700, Jens Axboe wrote:
> >>
> >> There are no pending r
On 19/01/2018 17:08, David Woodhouse wrote:
> On Fri, 2018-01-19 at 16:25 +0100, Paolo Bonzini wrote:
>> Without retpolines, KVM userspace is not protected from the guest
>> poisoning the BTB, because there is no IBRS-barrier on the vmexit
>> path.
>> So there are two more IBPBs that are needed if
On 2018-01-19 12:37 PM, Christian König wrote:
> Am 19.01.2018 um 11:40 schrieb Michal Hocko:
>> On Fri 19-01-18 09:39:03, Christian König wrote:
>>> Am 19.01.2018 um 09:20 schrieb Michal Hocko:
>> [...]
OK, in that case I would propose a different approach. We already
have rss_stat. So w
On Tue, Jan 09, 2018 at 07:21:15AM -0800, Tejun Heo wrote:
> From ceb2d2b2e496f180be95adb670337bb254f89323 Mon Sep 17 00:00:00 2001
> From: Tejun Heo
> Date: Tue, 9 Jan 2018 07:00:29 -0800
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
Applied to c
On Fri, Jan 19, 2018 at 10:09:41AM -0600, Eric W. Biederman wrote:
> Ram Pai writes:
>
> > Currently the architecture specific code is expected to
> > display the protection keys in smap for a given vma.
> > This can lead to redundant code and possibly to divergent
> > formats in which th
On 1/19/18 9:47 AM, Mike Snitzer wrote:
> On Fri, Jan 19 2018 at 11:41am -0500,
> Jens Axboe wrote:
>
>> On 1/19/18 9:37 AM, Ming Lei wrote:
>>> On Fri, Jan 19, 2018 at 09:27:46AM -0700, Jens Axboe wrote:
On 1/19/18 9:26 AM, Ming Lei wrote:
> On Fri, Jan 19, 2018 at 09:19:24AM -0700, Jen
Am 19.01.2018 um 13:20 schrieb Michal Hocko:
On Fri 19-01-18 13:13:51, Michal Hocko wrote:
On Fri 19-01-18 12:37:51, Christian König wrote:
[...]
The per file descriptor badness is/was just the much easier approach to
solve the issue, because the drivers already knew which client is currently
u
On Fri, 2018-01-19 at 11:35 +0100, Alban Crequy wrote:
> On Thu, Jan 18, 2018 at 10:25 PM, Mimi Zohar wrote:
> > On Tue, 2018-01-16 at 16:10 +0100, Alban Crequy wrote:
> >> From: Alban Crequy
> >>
> >> This patch forces files to be re-measured, re-appraised and re-audited
> >> on file systems wit
Hello, Linus.
One patch to add touch_nmi_watchdog() while dumping workqueue debug
messages to avoid triggering the lockup detector spuriously. The
change is very low risk.
Thanks.
The following changes since commit 01dfee9582d9b4403c4902df096ed8b43d55181c:
workqueue: remove unneeded kallsyms
On 5/1/2017 12:27 PM, SF Markus Elfring wrote:
From: Markus Elfring
Date: Mon, 1 May 2017 20:55:55 +0200
A single character (line break) should be put into a sequence.
Thus use the corresponding function "seq_putc".
This issue was detected by using the Coccinelle software.
Signed-off-by: Mark
The following changes since commit b2cd1df66037e7c4697c7e40496bf7e4a5e16a2d:
Linux 4.15-rc7 (2018-01-07 14:22:41 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-fixes
for you to fetch changes up to b7563e2796f8b23c98afc
Ram Pai writes:
> On Fri, Jan 19, 2018 at 10:09:41AM -0600, Eric W. Biederman wrote:
>> Ram Pai writes:
>>
>> > Currently the architecture specific code is expected to
>> > display the protection keys in smap for a given vma.
>> > This can lead to redundant code and possibly to divergen
On Fri, Jan 19, 2018 at 09:52:32AM -0700, Jens Axboe wrote:
> On 1/19/18 9:47 AM, Mike Snitzer wrote:
> > On Fri, Jan 19 2018 at 11:41am -0500,
> > Jens Axboe wrote:
> >
> >> On 1/19/18 9:37 AM, Ming Lei wrote:
> >>> On Fri, Jan 19, 2018 at 09:27:46AM -0700, Jens Axboe wrote:
> On 1/19/18 9:
On Fri, Jan 19, 2018 at 10:49 AM, Mark Salyzyn wrote:
> On 01/18/2018 02:36 PM, Paul Moore wrote:
>> On Thu, Jan 18, 2018 at 4:58 PM, Mark Salyzyn wrote:
>>> general protection fault: [#1] PREEMPT SMP KASAN
>>> CPU: 1 PID: 14233 Comm: syz-executor2 Not tainted 4.4.112-g5f6325b #28
>>> . . .
On 1/19/18 10:05 AM, Ming Lei wrote:
> On Fri, Jan 19, 2018 at 09:52:32AM -0700, Jens Axboe wrote:
>> On 1/19/18 9:47 AM, Mike Snitzer wrote:
>>> On Fri, Jan 19 2018 at 11:41am -0500,
>>> Jens Axboe wrote:
>>>
On 1/19/18 9:37 AM, Ming Lei wrote:
> On Fri, Jan 19, 2018 at 09:27:46AM -0700,
Hi,
On 19/01/2018 16:45, Peter Zijlstra wrote:
On Thu, Jan 18, 2018 at 06:40:07PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
For situations where sysadmins might want to allow different level of
of access control for different PMUs, we start creating per-PMU
perf_event_paranoid contro
Hi, Peter! :-)
How do you do?
On Fri, Jan 19, 2018 at 03:34:34PM +0200, Peter Ujfalusi wrote:
> Instead of directly accessing to dmadev->device_prep_interleaved_dma() use
> the dmaengine_prep_interleaved_dma() wrapper instead.
>
> Signed-off-by: Peter Ujfalusi
Acked-by: Sakari Ailus
--
Saka
On Fri, Jan 19, 2018 at 02:11:18AM +0100, Francois Romieu wrote:
> Peter Zijlstra :
> [...]
> > There is only 1 variable afaict. Memory barriers need at least 2 in
> > order to be able to do _anything_.
>
> I don't get your point: why don't {cur_tx, dirty_tx} qualify as said
> two variables ?
Th
On 1/19/2018 10:02 AM, Gabriel C wrote:
> 2018-01-19 16:56 GMT+01:00 Tom Lendacky :
>> On 1/19/2018 9:35 AM, Greg Kroah-Hartman wrote:
>>> On Fri, Jan 19, 2018 at 09:27:47AM -0600, Tom Lendacky wrote:
On 1/19/2018 9:11 AM, Greg Kroah-Hartman wrote:
> On Fri, Jan 19, 2018 at 09:03:52AM -060
Hello, Linus.
This just adds one more entry for liteon optical drives to the device
blacklist for large IOs. The change is very low risk.
Thanks.
The following changes since commit 2dc0b46b5ea30f169b0b272253ea846a5a281731:
libata: sata_down_spd_limit should return if driver has not recorded
On Fri, Jan 19, 2018 at 09:18:54AM +0100, Ivan Vecera wrote:
> Commit b7ce40cff0b9 ("kernfs: cache atomic_write_len in
> kernfs_open_file") changes type of local variable 'len' from ssize_t
> to size_t. This change caused that the *ppos value is updated also
> when the previous write callback faile
On Fri, Jan 19, 2018 at 09:16:36AM -0800, Tejun Heo wrote:
> On Fri, Jan 19, 2018 at 09:18:54AM +0100, Ivan Vecera wrote:
> > Commit b7ce40cff0b9 ("kernfs: cache atomic_write_len in
> > kernfs_open_file") changes type of local variable 'len' from ssize_t
> > to size_t. This change caused that the *
On Thu, 2018-01-18 at 13:58 -0800, Mark Salyzyn wrote:
> general protection fault: [#1] PREEMPT SMP KASAN
> CPU: 1 PID: 14233 Comm: syz-executor2 Not tainted 4.4.112-g5f6325b
> #28
> task: 8801d1095f00 task.stack: 8800b595
> RIP: 0010:[] []
> sock_has_perm+0x1fe/0x3e0 security/sel
Arnd Bergmann writes:
> On Wed, Jan 10, 2018 at 9:22 PM, Robert Jarzmik
> wrote:
>> Arnd Bergmann writes:
>>
>>> Without this tag, we get a build warning:
>>>
>>> WARNING: modpost: missing MODULE_LICENSE() in arch/arm/mach-pxa/tosa-bt.o
>>>
>>> For completeness, I'm also adding author and desc
On Tue, Jan 16, 2018 at 04:21:40PM +0800, Xin Long wrote:
> ipv4 tunnels don't really set dev->hard_header_len properly,
> we may should fix it in pppoe by using needed_headroom,
> as what it doesn't in arp_create.
>
I'm a bit in doubt about which device needs to be fixed. Should ip_gre
set ->har
On Fri, Jan 19, 2018 at 03:15:00PM +, Liang, Kan wrote:
> >
> > On Thu, Jan 18, 2018 at 05:43:10PM +, Liang, Kan wrote:
> > > In the uncore document, there is no event-code assigned to free running
> > counters.
> > > Some events need to be defined to indicate the free running counters.
>
On 2018-01-06 09:55 AM, Harry Wentland wrote:
> On 2018-01-05 06:07 PM, Andy Lutomirski wrote:
>>
>>
>>> On Jan 5, 2018, at 1:51 PM, Harry Wentland wrote:
>>>
On 2018-01-05 04:28 PM, Andy Lutomirski wrote:
It's a known issue, and it should be fixed in newer -rc kernels.
>>>
>>> I'm
On Fri, Jan 19, 2018 at 10:09:11AM -0700, Jens Axboe wrote:
> On 1/19/18 10:05 AM, Ming Lei wrote:
> > On Fri, Jan 19, 2018 at 09:52:32AM -0700, Jens Axboe wrote:
> >> On 1/19/18 9:47 AM, Mike Snitzer wrote:
> >>> On Fri, Jan 19 2018 at 11:41am -0500,
> >>> Jens Axboe wrote:
> >>>
> On 1/19/1
From
The international Investigation Financial Crime Unit
Dear sir
We need your urgent information sir
I am writing to inform you that we are the international
investigation financial crime unit
and We have discovered through our network E-mail system This Week
that your Inheritance Claim F
On Fri, Jan 19, 2018 at 8:50 AM, Tejun Heo wrote:
>
> Applied to cgroup/for-4.16.
I did still have it queued up, but I was looking at other issues, and
hadn't gotten around to it. But if it's now in your git tree I can
just drop this from my queue.
Just as well. Thanks,
Linus
On 19 January 2018 at 08:55, Arnaldo Carvalho de Melo wrote:
> Em Fri, Jan 19, 2018 at 08:24:56AM -0700, Mathieu Poirier escreveu:
>> On 19 January 2018 at 08:12, Jiri Olsa wrote:
>> > On Fri, Jan 19, 2018 at 11:58:19AM -0300, Arnaldo Carvalho de Melo wrote:
>> >> Em Thu, Jan 18, 2018 at 03:27:43
On Fri, Jan 19, 2018 at 04:09:09PM +, mario.limoncie...@dell.com wrote:
> > -Original Message-
> > From: platform-driver-x86-ow...@vger.kernel.org [mailto:platform-driver-x86-
> > ow...@vger.kernel.org] On Behalf Of Pali Rohár
> > Sent: Friday, January 19, 2018 10:01 AM
> > To: Dmitry T
Sparse is whining about the u32 and __le32 mixed usage in the
driver.
drivers/ntb/test/ntb_perf.c:288:21: warning: cast to restricted __le32
drivers/ntb/test/ntb_perf.c:295:37: warning: incorrect type in argument 4
(different base types)
drivers/ntb/test/ntb_perf.c:295:37:expected unsigned in
Hello,
On Fri, Jan 19, 2018 at 09:27:50AM -0800, Linus Torvalds wrote:
> On Fri, Jan 19, 2018 at 8:50 AM, Tejun Heo wrote:
> >
> > Applied to cgroup/for-4.16.
>
> I did still have it queued up, but I was looking at other issues, and
> hadn't gotten around to it. But if it's now in your git tree
On Fri, Jan 19, 2018 at 11:50:58AM +0100, Hans-Christian Noren Egtvedt wrote:
> Around Fri 19 Jan 2018 09:17:45 +0100 or thereabout, Corentin Labbe wrote:
> > Since AVR32 arch is gone, atmel-wm97xx driver is useless.
> > Remove it.
>
> In theory it could have been rewritten to work with AT91 devic
On Thu, Jan 18, 2018 at 04:49:03PM -0500, Jean-François Têtu wrote:
> Fix small typos in the Instructions and Uploading sections. Fix a typo in
> the start/stop effect example usage code.
>
> Signed-off-by: Jean-François Têtu
Applied, thank you.
> ---
> Documentation/input/ff.rst | 6 +++---
>
On Fri, Jan 19, 2018 at 9:19 AM, Peter Zijlstra wrote:
>
> On Fri, Jan 19, 2018 at 03:15:00PM +, Liang, Kan wrote:
> > >
> > > On Thu, Jan 18, 2018 at 05:43:10PM +, Liang, Kan wrote:
> > > > In the uncore document, there is no event-code assigned to free running
> > > counters.
> > > > Som
On 01/19/2018 09:19 AM, Stephen Smalley wrote:
On Thu, 2018-01-18 at 13:58 -0800, Mark Salyzyn wrote:
general protection fault: [#1] PREEMPT SMP KASAN
. . .
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 8644d864e3c1..95d7c8143373 100644
--- a/security/selinux/hooks
On Fri, Jan 19, 2018 at 9:31 AM, Tejun Heo wrote:
>
> I see. I'll push it your way together with other cgroup changes once
> the merge window opens.
NP. This was a fairly unusual late rc window. It's normally quiet this
period, but first I was distracted by some of the Spectre detail
discussions
On 1/19/2018 9:06 AM, Paul Moore wrote:
> On Fri, Jan 19, 2018 at 10:49 AM, Mark Salyzyn wrote:
>> On 01/18/2018 02:36 PM, Paul Moore wrote:
>>> On Thu, Jan 18, 2018 at 4:58 PM, Mark Salyzyn wrote:
general protection fault: [#1] PREEMPT SMP KASAN
CPU: 1 PID: 14233 Comm: syz-executo
On 1/19/18 9:37 AM, Ming Lei wrote:
> On Fri, Jan 19, 2018 at 09:27:46AM -0700, Jens Axboe wrote:
>> On 1/19/18 9:26 AM, Ming Lei wrote:
>>> On Fri, Jan 19, 2018 at 09:19:24AM -0700, Jens Axboe wrote:
On 1/19/18 9:05 AM, Ming Lei wrote:
> On Fri, Jan 19, 2018 at 08:48:55AM -0700, Jens Axbo
On Fri, 2018-01-19 at 12:19 -0500, Stephen Smalley wrote:
> On Thu, 2018-01-18 at 13:58 -0800, Mark Salyzyn wrote:
> > general protection fault: [#1] PREEMPT SMP KASAN
> > CPU: 1 PID: 14233 Comm: syz-executor2 Not tainted 4.4.112-g5f6325b
> > #28
> > task: 8801d1095f00 task.stack: 8800
From: "Steven Rostedt (VMware)"
In bringing back the context checks, the code checks first if its normal
(non-interrupt) context, and then for NMI then IRQ then softirq. The final
check is redundant. Since the if branch is only hit if the context is one of
NMI, IRQ, or SOFTIRQ, if it's not NMI or
From: "Steven Rostedt (VMware)"
Since enums do not get converted by the TRACE_EVENT macro into their values,
the event format displaces the enum name and not the value. This breaks
tools like perf and trace-cmd that need to interpret the raw binary data. To
solve this, an enum map was created to
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
to receive updates for the input subsystem. You will get:
- a fix for use-after-free in Synaptics RMI4 driver
- correction to multitouch contact tracking on certain ALPS touchpads
(whicj
Linus,
Two more small fixes
- The conversion of enums into their actual numbers to display
in the event format file had an off-by-one bug, that could cause
an enum not to be converted, and break user space parsing tools.
- A fix to a previous fix to bring back the context recursion chec
Instead of __asan_report_load_n_noabort and __asan_report_store_n_noabort
callbacks Clang emits differently named __asan_report_loadN_noabort and
__asan_report_storeN_noabort (similar to __asan_loadN/storeN_noabort, whose
names both GCC and Clang agree on).
Add callback implementation for __asan_r
On Fri, Jan 19, 2018 at 10:03:53AM -0500, Steven Rostedt wrote:
> On Fri, 19 Jan 2018 14:53:05 +0530
> Pavan Kondeti wrote:
>
> > I am seeing "spinlock already unlocked" BUG for rd->rto_lock on a 4.9
> > stable kernel based system. This issue is observed only after
> > inclusion of this patch. It
On 01/19/2018 09:06 AM, Paul Moore wrote:
On Fri, Jan 19, 2018 at 10:49 AM, Mark Salyzyn wrote:
On 01/18/2018 02:36 PM, Paul Moore wrote:
On Thu, Jan 18, 2018 at 4:58 PM, Mark Salyzyn wrote:
general protection fault: [#1] PREEMPT SMP KASAN
CPU: 1 PID: 14233 Comm: syz-executor2 Not taint
> On Fri, Jan 19, 2018 at 03:15:00PM +, Liang, Kan wrote:
> > >
> > > On Thu, Jan 18, 2018 at 05:43:10PM +, Liang, Kan wrote:
> > > > In the uncore document, there is no event-code assigned to free
> > > > running
> > > counters.
> > > > Some events need to be defined to indicate the free r
On Fri, Jan 19, 2018 at 9:53 AM, Liang, Kan wrote:
>> On Fri, Jan 19, 2018 at 03:15:00PM +, Liang, Kan wrote:
>> > >
>> > > On Thu, Jan 18, 2018 at 05:43:10PM +, Liang, Kan wrote:
>> > > > In the uncore document, there is no event-code assigned to free
>> > > > running
>> > > counters.
>>
With KASAN enabled the kernel has two different memset() functions, one
with KASAN checks (memset) and one without (__memset). KASAN uses some
macro tricks to use the proper version where required. For example memset()
calls in mm/slub.c are without KASAN checks, since they operate on poisoned
slab
On Fri, Jan 19, 2018 at 4:57 PM, Andrey Ryabinin
wrote:
>
>
> On 01/19/2018 05:54 PM, Andrey Konovalov wrote:
>
>> diff --git a/scripts/Makefile.kasan b/scripts/Makefile.kasan
>> index dbbd4382f15a..db473309f136 100644
>> --- a/scripts/Makefile.kasan
>> +++ b/scripts/Makefile.kasan
>> @@ -39,4 +39
> On Fri, Jan 19, 2018 at 9:53 AM, Liang, Kan wrote:
> >> On Fri, Jan 19, 2018 at 03:15:00PM +, Liang, Kan wrote:
> >> > >
> >> > > On Thu, Jan 18, 2018 at 05:43:10PM +, Liang, Kan wrote:
> >> > > > In the uncore document, there is no event-code assigned to free
> >> > > > running
> >> > >
On Fri, Jan 19, 2018 at 4:49 AM, Kirill A. Shutemov
wrote:
>
> + if (pfn < page_to_pfn(pvmw->page))
> + return false;
> +
> + /* THP can be referenced by any subpage */
> + if (pfn - page_to_pfn(pvmw->page) >= hpage_nr_pages(pvmw->page))
> + return fal
On Sat, Jan 20, 2018 at 1:19 AM, Guillaume Nault wrote:
> On Tue, Jan 16, 2018 at 04:21:40PM +0800, Xin Long wrote:
>> ipv4 tunnels don't really set dev->hard_header_len properly,
>> we may should fix it in pppoe by using needed_headroom,
>> as what it doesn't in arp_create.
>>
> I'm a bit in dou
On Mon, Jan 15, 2018 at 06:40:09PM -0600, Eric W. Biederman wrote:
> Among the existing architecture specific versions of
> copy_siginfo_to_user32 there are several different implementation
> problems. Some architectures fail to handle all of the cases in in
> the siginfo union. Some architecture
Two one-liners for the same issue, second bug occurrence is just
a copy&pasted mistake from 2011...
Ladislav Michl (2):
devres: Fix double mem region release in devm_ioremap_resource()
PCI: Fix double mem region release in devm_pci_remap_cfg_resource()
drivers/pci/pci.c | 1 -
lib/devres.c
devm_release_mem_region() is called explicitely in case
devm_ioremap() fails, however the same release function
is later called also as devres release of
devm_request_mem_region() causing double resource free.
Fixes: 72f8c0bfa0de ("lib: devres: add convenience function to remap a
resource")
Signe
devm_release_mem_region() is called explicitely in case
devm_pci_remap_cfgspace() fails, however the same release
function is later called also as devres release of
devm_request_mem_region() causing double resource free.
Fixes: 490cb6ddb17d ("PCI: Implement devm_pci_remap_cfgspace()")
Signed-off-b
Hi Mika,
2018-01-18 14:00 GMT+01:00 Andrew Lunn :
>> I CC'ed Mika since he is more familiar with handling these bits of ACPI
>> specs - I wonder whether this is a problem that cropped up on x86
>> systems too.
>
> Hi Lorenzo
>
> There is nothing about MDIO, PHYs, Ethernet switches, etc in version
Looks good to me.
Reviewed-by: Lyude Paul
On Thu, 2018-01-18 at 16:49 -0800, Dmitry Torokhov wrote:
> Currently we register the pass-through serio port when we probe the F03 RMI
> function, and then, in sensor configure phase, we unmask interrupts.
> Unfortunately this is too late, as other driv
Reviewed-by: Lyude Paul
On Thu, 2018-01-18 at 16:49 -0800, Dmitry Torokhov wrote:
> To ease analyzing boot behavior from logs, let's log when we are about to
> register the pass-through serio port.
>
> Also, let's drop "Synaptics" prefix from the port name, as RMI4 is good
> enough indicator alr
On Fri, 19 Jan 2018 23:16:17 +0530
Pavan Kondeti wrote:
> I am thinking of another problem because of the race between
> rto_push_irq_work_func() and rq_attach_root() where rq->rd is modified.
>
> Lets say, we cache the rq->rd here and queued the IRQ work on a remote
> CPU. In the mean time, the
On Fri, 19 Jan 2018 13:11:21 -0500
Steven Rostedt wrote:
> void rto_push_irq_work_func(struct irq_work *work)
> {
> + struct root_domain *rd =
> + container_of(work, struct root_domain, rto_push_work);
> struct rq *rq;
Notice that I also remove the dependency on rq from g
[ adding Alexei back to the cc ]
On Fri, Jan 19, 2018 at 9:48 AM, Adam Sampson wrote:
> Jann Horn writes:
>
>>> +/*
>>> + * If idx is negative or if idx > size then bit 63 is set in the mask,
>>> + * and the value of ~(-1L) is zero. When the mask is zero, bounds check
>>> + * failed, array_ptr w
Jann Horn writes:
>> +/*
>> + * If idx is negative or if idx > size then bit 63 is set in the mask,
>> + * and the value of ~(-1L) is zero. When the mask is zero, bounds check
>> + * failed, array_ptr will return NULL.
>> + */
>> +#ifndef array_ptr_mask
>> +static inline unsigned long array_ptr_m
On Fri, Jan 19, 2018 at 10:12:47AM -0800, Dan Williams wrote:
> [ adding Alexei back to the cc ]
>
> On Fri, Jan 19, 2018 at 9:48 AM, Adam Sampson wrote:
> > Jann Horn writes:
> >
> >>> +/*
> >>> + * If idx is negative or if idx > size then bit 63 is set in the mask,
> >>> + * and the value of ~
On Fri, Jan 19, 2018 at 2:20 AM, Jann Horn wrote:
>> + \
>> + __u._ptr = _arr + (_i & _mask); \
>> + __u._bit &= _mask; \
>
> AFAICS, if `i
On 01/18/2018 09:23 PM, Chao Fan wrote:
> Cc: linux-...@vger.kernel.org
> Cc: Jonathan Corbet
> Cc: Randy Dunlap
> Signed-off-by: Chao Fan
> ---
> Documentation/admin-guide/kernel-parameters.txt | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/Documentation/admin-guide/kern
Tejun,
I was thinking about this a bit more, and instead of offloading a
recursive printk, perhaps its best to simply throttle it. Because the
problem may not go away if a printk thread takes over, because the bug
is really the printk infrastructure filling the printk buffer keeping
printk from ev
On Fri, Jan 19, 2018 at 10:38:41AM -0700, Jens Axboe wrote:
> On 1/19/18 9:37 AM, Ming Lei wrote:
> > On Fri, Jan 19, 2018 at 09:27:46AM -0700, Jens Axboe wrote:
> >> On 1/19/18 9:26 AM, Ming Lei wrote:
> >>> On Fri, Jan 19, 2018 at 09:19:24AM -0700, Jens Axboe wrote:
> On 1/19/18 9:05 AM, Min
On Fri, Jan 19, 2018 at 8:16 AM, David Miller wrote:
>
> So this "get requeued" condition I think will trigger always for
> networking tunnel decapsulation.
Hmm. Interesting and a perhaps bit discouraging.
Will it always be just a _single_ level of indirection, or will double
tunnels (I assume s
On Fri, Jan 19, 2018 at 10:18 AM, Will Deacon wrote:
>
> On Fri, Jan 19, 2018 at 10:12:47AM -0800, Dan Williams wrote:
> > [ adding Alexei back to the cc ]
> >
> > On Fri, Jan 19, 2018 at 9:48 AM, Adam Sampson wrote:
> > > Jann Horn writes:
> > >
> > >>> +/*
> > >>> + * If idx is negative or if
On Fri, Jan 19 2018 at 12:38pm -0500,
Jens Axboe wrote:
> On 1/19/18 9:37 AM, Ming Lei wrote:
> > On Fri, Jan 19, 2018 at 09:27:46AM -0700, Jens Axboe wrote:
> >>
> >> There are no pending requests for this case, nothing to restart the
> >> queue. When you fail that blk_get_request(), you are idl
This patchset removes some warnings generated by checkpatch
for cleanup of the rtl8723bs driver. Also some additional
cleanups are introduced in the *[1/4] and *[3/4] patches
to make the code according to the kernel coding style.
Changes in v2
-Rebase and resend all patches.
Changes in v3
-Ed
Replace true and false keywords with "x" and "!x"
respectively to follow the kernel coding style.
Signed-off-by: Shreeya Patel
---
drivers/staging/rtl8723bs/hal/sdio_ops.c | 30 ++
1 file changed, 14 insertions(+), 16 deletions(-)
diff --git a/drivers/staging/rtl8723
Change names of some variables and functions to conform
to the kernel coding style. The changes include some removal
of CamelCase warnings and renaming the variable and field names
that encode their type (eg the pointers seem to start with p).
Signed-off-by: Shreeya Patel
---
Changes in v3
-Ed
On Fri, Jan 19, 2018 at 4:55 AM, Matthew Wilcox wrote:
>
> So really we should be casting 'b' and 'a' to uintptr_t to be fully
> compliant with the spec.
That's an unnecessary technicality.
Any compiler that doesn't get pointer inequality testing right is not
worth even worrying about. We wouldn
"oldmem==NULL;"
The above bug under the ifdef code would have caused a GCC
warning if it were ever compiled. Hence, remove the dead ifdefed
code from the file.
Signed-off-by: Shreeya Patel
---
Changes in v3
-Remove dead code.
drivers/staging/rtl8723bs/hal/sdio_ops.c | 15 ---
1 f
If "x" is compared to NULL, use "!x" instead of it, so as
to follow the kernel coding style.
Signed-off-by: Shreeya Patel
---
drivers/staging/rtl8723bs/hal/sdio_ops.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/sdio_ops.c
b/
On Fri, Jan 19, 2018 at 10:28:24AM -0700, Mathieu Poirier wrote:
> On 19 January 2018 at 08:55, Arnaldo Carvalho de Melo wrote:
> > Em Fri, Jan 19, 2018 at 08:24:56AM -0700, Mathieu Poirier escreveu:
> >> On 19 January 2018 at 08:12, Jiri Olsa wrote:
> >> > On Fri, Jan 19, 2018 at 11:58:19AM -030
From: Linus Torvalds
Date: Fri, 19 Jan 2018 10:25:03 -0800
> On Fri, Jan 19, 2018 at 8:16 AM, David Miller wrote:
>>
>> So this "get requeued" condition I think will trigger always for
>> networking tunnel decapsulation.
>
> Hmm. Interesting and a perhaps bit discouraging.
>
> Will it always b
On 17 January 2018 at 05:31, Alexander Shishkin
wrote:
> On Tue, Feb 07, 2017 at 10:50:50AM -0700, Mathieu Poirier wrote:
>> > index 39106ae61b..d7a11faac1 100644
>> > --- a/kernel/events/core.c
>> > +++ b/kernel/events/core.c
>> > @@ -8194,7 +8194,8 @@ static void perf_event_addr_filters_apply(st
> Since I have a code that can be tested and easily modified to use
> different ACPI approaches with real platform MDIO controller
> (mvmdio.c) and NIC (mvpp2.c), in coming weeks I may be able to find
> some time to prepare a proof of concept based on GenericSerialBus.
> Please expect some RFC patc
On Fri, Jan 19, 2018 at 01:11:21PM -0500, Steven Rostedt wrote:
> On Fri, 19 Jan 2018 23:16:17 +0530
> Pavan Kondeti wrote:
>
> > I am thinking of another problem because of the race between
> > rto_push_irq_work_func() and rq_attach_root() where rq->rd is modified.
> >
> > Lets say, we cache th
+Cc alex.william...@redhat.com
On Fri, Jan 19, 2018 at 05:03:47PM +0800, Wanpeng Li wrote:
> 2018-01-19 17:01 GMT+08:00 Wanpeng Li :
> > 2018-01-19 16:18 GMT+08:00 Eric Biggers :
> >> From: Eric Biggers
> >>
> >> Memslots must not overlap in guest physical memory, since otherwise some
> >> guest
On Fri, Jan 19, 2018 at 11:18:59AM +, Lorenzo Pieralisi wrote:
> On Fri, Jan 19, 2018 at 10:39:06AM +0100, Niklas Cassel wrote:
> > If CONFIG_PCI=n and CONFIG_PCI_DRA7XX_EP=y, the build fails with:
> >
> > drivers/pci/dwc/pci-dra7xx.c:229:11: error: 'pci_irqd_intx_xlate'
> > undeclared her
On Thu, Jan 18, 2018 at 10:22:30PM +0800, Wang YanQing wrote:
> On Thu, Jan 18, 2018 at 10:43:18AM +0100, Jiri Olsa wrote:
> > On Wed, Jan 17, 2018 at 12:48:12AM +0800, Wang YanQing wrote:
> > > On Mon, Jan 15, 2018 at 11:06:11AM +0100, Jiri Olsa wrote:
> > > > On Mon, Jan 15, 2018 at 12:47:32PM +0
Hi Steve,
Thanks for the patch.
On Fri, Jan 19, 2018 at 01:12:54PM -0500, Steven Rostedt wrote:
> On Fri, 19 Jan 2018 13:11:21 -0500
> Steven Rostedt wrote:
>
> > void rto_push_irq_work_func(struct irq_work *work)
> > {
> > + struct root_domain *rd =
> > + container_of(work, struc
From: Arnd Bergmann
Date: Tue, 16 Jan 2018 17:34:00 +0100
> When CONFIG_KASAN is set, we can use relatively large amounts of kernel
> stack space:
>
> net/caif/cfctrl.c:555:1: warning: the frame size of 1600 bytes is larger than
> 1280 bytes [-Wframe-larger-than=]
>
> This adds convenience wra
On Fri, Jan 19, 2018 at 09:46:14AM +1100, Dave Chinner wrote:
> After I get back from LCA (all next week) I'll update the fsmark
> aio patches I have and retest this. The code looks pretty similar to
> the last "generic aio fsync" patch I wrote, so I'm guessing that the
> results will be pretty sim
Hmm... I had mentioned this patch to some coworkers who have much more
knowledge about LLVM than me. They had concern that LLVM needs memset
to be defined, and that there were discussions on the llvm mailing
list about this.
I'm digging through trying to find anything relevant, maybe this one
abo
sorry, for new people I just cc'ed: https://patchwork.kernel.org/patch/10175831/
On Fri, Jan 19, 2018 at 2:06 PM, Nick Desaulniers
wrote:
> Hmm... I had mentioned this patch to some coworkers who have much more
> knowledge about LLVM than me. They had concern that LLVM needs memset
> to be defin
On 01/19/2018 07:22 AM, Jayachandran C wrote:
> Use PSCI based mitigation for speculative execution attacks targeting
> the branch predictor. We use the same mechanism as the one used for
> Cortex-A CPUs, we expect the PSCI version call to have a side effect
> of clearing the BTBs.
>
> Signed-off-
On 01/17/2018 01:17 AM, Michal Hocko wrote:
On Tue 16-01-18 21:50:15, Kees Cook wrote:
One of the classes of kernel stack content leaks is exposing the contents
of prior heap or stack contents when a new process stack is allocated.
Normally, those stacks are not zeroed, and the old contents rema
Since the CMA API is now used directly the allocated memory is no longer
automatically zeroed.
Explicitly zero CMA allocated memory to ensure that no data is exposed
to userspace.
Change-Id: I08e143707a0d31610821a7f16826c262bf3c1999
Signed-off-by: Liam Mark
---
drivers/staging/android/ion/ion_c
401 - 500 of 703 matches
Mail list logo
