Hi,
I hit a false positives bug when run script/checkpatch.pl to my patch,
It reported errors to following macro definition, but in fact the macro is
correct, I couldn't change that macro according to the error message output
by script/checkpatch.pl. because of this bug, my patch was rejected
On Fujitsu Lifebook A512 pressing Fn+F6 or Fn+F7 the brightness doesn't
change.
I tried the latest upstream kernel 3.15-rc8 but the hot keys still don't
work.
--
WORKAROUND
Execute at a terminal:
for i in /sys/class/backlight/*; do echo $i;cat $i/brightness;ca
On Tue, May 20, 2014 at 11:40 PM, Martin wrote:
>> I've looked into second crash. Just because gmail has marked that
>> email as important for some reason =)
>>
>> In function tid_fd_revalidate(), in line "file = fcheck_files(files,
>> fd)" file = is 0x0400 instead of valid pointer or
I've looked into second crash. Just because gmail has marked that
email as important for some reason =)
In function tid_fd_revalidate(), in line "file = fcheck_files(files,
fd)" file = is 0x0400 instead of valid pointer or NULL.
This value has only one non-zero bit, so this looks like
> Hi,
>
> I'm having regular issues with crashes, this time I was only browsing the
> web.
> Please could you let me know how best to report this if this isn't the
> right way.
This is an oops this time not sure if this is related.
Thanks,
M
May 18 22:39:01 superworm kernel: [ 2196.483533] BUG:
Hi,
I'm having regular issues with crashes, this time I was only browsing the
web.
Please could you let me know how best to report this if this isn't the
right way.
Thanks,
M
May 17 14:31:48 superworm kernel: [ 6252.073731] Restarting tasks ...
May 17 14:31:48 superworm kernel: [ 6252.074724] ge
#x27;linux-arch-ow...@vger.kernel.org'; 'linux-kernel@vger.kernel.org';
'linux-arm-msm-ow...@vger.kernel.org'
Subject: Re: bug report about assert at [ kernel/fs/jbd2/transaction.c:2138 ]
On Thu, Nov 21, 2013 at 03:54:29PM +0800, Wang, Yalin wrote:
>
> I have a crash on Android
7;; 'linux-kernel@vger.kernel.org';
Peng, Arthur; Zhang, Bojie; Gu, Youcai 1 (EXT); Alevoor, Raghavendra 2
Subject: Re: BUG report about ipt_do_table( )
On Thu, Oct 17, 2013 at 02:51:34AM +0100, Wang, Yalin wrote:
> Hi Will,
Hello,
> I am happy to notify that our stability test has
On Thu, Oct 17, 2013 at 02:51:34AM +0100, Wang, Yalin wrote:
> Hi Will,
Hello,
> I am happy to notify that our stability test has passed,
> And this Crash don't happen again,
> So seems this patch work now .
Great!
> We has merged it into our release SW .
> Could I know if this patch will be
ssage-
From: Wang, Yalin
Sent: Friday, October 11, 2013 7:15 PM
To: 'Will Deacon'
Cc: 'linux-arm-msm-ow...@vger.kernel.org'; linux-kernel@vger.kernel.org; Peng,
Arthur; Zhang, Bojie; Gu, Youcai 1 (EXT); Alevoor, Raghavendra 2
Subject: RE: BUG report about ipt_do_table( )
(EXT); Alevoor, Raghavendra 2
Subject: Re: BUG report about ipt_do_table( )
On Fri, Oct 11, 2013 at 02:50:24AM +0100, Wang, Yalin wrote:
> Hi Will,
Hello again,
> Maybe I know your meaning ,
> If it use spinlock to protected the shared data, The bug will not
> happen, because spinlo
On Fri, Oct 11, 2013 at 02:50:24AM +0100, Wang, Yalin wrote:
> Hi Will,
Hello again,
> Maybe I know your meaning ,
> If it use spinlock to protected the shared data,
> The bug will not happen, because spinlock will
> Use DSB( ) to sync .
Actually, the dsb is for something else (the sev). It i
n [mailto:will.dea...@arm.com]
Sent: Thursday, October 10, 2013 10:19 PM
To: Wang, Yalin
Cc: 'linux-arm-msm-ow...@vger.kernel.org'; linux-kernel@vger.kernel.org; Peng,
Arthur; Zhang, Bojie; Gu, Youcai 1 (EXT); Alevoor, Raghavendra 2
Subject: Re: BUG report about ipt_do_table( )
On Thu, Oct
On Thu, Oct 10, 2013 at 12:26:38PM +0100, Wang, Yalin wrote:
> Hi Will ,
Hello,
> Seems your patch is better than mine,
> It make sure newinfo->initial_entries update is
> Seen by others .
>
> I will test by your patches , and update to you ASAP .
Thanks.
> I have another questions about t
ompleted !
Am I right ?
Thank you !
-Original Message-
From: Will Deacon [mailto:will.dea...@arm.com]
Sent: Thursday, October 10, 2013 7:03 PM
To: Wang, Yalin
Cc: 'linux-arm-msm-ow...@vger.kernel.org'; linux-kernel@vger.kernel.org; Peng,
Arthur; Zhang, Bojie
Subject: Re
On Thu, Oct 10, 2013 at 11:22:21AM +0100, Wang, Yalin wrote:
> Thanks for your reply .
No problem.
> I have compare our kernel with 3.12 ,
> Ip_tables.c x_tables.c is the same ,
> So the BUG should can also be reproduce on 3.12 (just my guess).
[...]
> /--
5:48 PM
To: Wang, Yalin
Cc: 'linux-arm-msm-ow...@vger.kernel.org'; linux-kernel@vger.kernel.org
Subject: Re: BUG report about ipt_do_table( )
On Thu, Oct 10, 2013 at 06:16:05AM +0100, Wang, Yalin wrote:
> Dear all,
Hello,
> We encounter a crash in ipt_do_table( ) function During
On Thu, Oct 10, 2013 at 06:16:05AM +0100, Wang, Yalin wrote:
> Dear all,
Hello,
> We encounter a crash in ipt_do_table( ) function
> During our stability test .
>
> The CPU is qcom msm8960 / dual core , linux kernel version is 3.4
I appreciate that this is a mammoth task, but can you reprod
Hello Weijie,
On Thu, Sep 26, 2013 at 04:48:03PM +0800, Weijie Yang wrote:
> On Thu, Sep 26, 2013 at 3:57 PM, Minchan Kim wrote:
> > On Thu, Sep 26, 2013 at 03:26:33PM +0800, Weijie Yang wrote:
> >> On Thu, Sep 26, 2013 at 1:58 PM, Minchan Kim wrote:
> >> > Hello Weigie,
> >> >
> >> > On Wed, Se
On Thu, Sep 26, 2013 at 4:48 PM, Weijie Yang wrote:
> On Thu, Sep 26, 2013 at 3:57 PM, Minchan Kim wrote:
>> On Thu, Sep 26, 2013 at 03:26:33PM +0800, Weijie Yang wrote:
>>> On Thu, Sep 26, 2013 at 1:58 PM, Minchan Kim wrote:
>>> > Hello Weigie,
>>> >
>>> > On Wed, Sep 25, 2013 at 05:33:43PM +08
On Thu, Sep 26, 2013 at 3:57 PM, Minchan Kim wrote:
> On Thu, Sep 26, 2013 at 03:26:33PM +0800, Weijie Yang wrote:
>> On Thu, Sep 26, 2013 at 1:58 PM, Minchan Kim wrote:
>> > Hello Weigie,
>> >
>> > On Wed, Sep 25, 2013 at 05:33:43PM +0800, Weijie Yang wrote:
>> >> On Wed, Sep 25, 2013 at 4:31 PM
On Thu, Sep 26, 2013 at 03:26:33PM +0800, Weijie Yang wrote:
> On Thu, Sep 26, 2013 at 1:58 PM, Minchan Kim wrote:
> > Hello Weigie,
> >
> > On Wed, Sep 25, 2013 at 05:33:43PM +0800, Weijie Yang wrote:
> >> On Wed, Sep 25, 2013 at 4:31 PM, Bob Liu wrote:
> >> > On Wed, Sep 25, 2013 at 4:09 PM, We
On Thu, Sep 26, 2013 at 1:58 PM, Minchan Kim wrote:
> Hello Weigie,
>
> On Wed, Sep 25, 2013 at 05:33:43PM +0800, Weijie Yang wrote:
>> On Wed, Sep 25, 2013 at 4:31 PM, Bob Liu wrote:
>> > On Wed, Sep 25, 2013 at 4:09 PM, Weijie Yang
>> > wrote:
>> >> I think I find a new issue, for integrity o
Hello Weigie,
On Wed, Sep 25, 2013 at 05:33:43PM +0800, Weijie Yang wrote:
> On Wed, Sep 25, 2013 at 4:31 PM, Bob Liu wrote:
> > On Wed, Sep 25, 2013 at 4:09 PM, Weijie Yang
> > wrote:
> >> I think I find a new issue, for integrity of this mail thread, I reply
> >> to this mail.
> >>
> >> It is
Hi Rafael,
On 09/25/2013 10:36 PM, Rafael J. Wysocki wrote:
> On Wednesday, September 25, 2013 06:31:09 PM Gu Zheng wrote:
>> Hi Toshi,
>>
>> On 09/12/2013 11:11 PM, Toshi Kani wrote:
>>
>>> On Thu, 2013-09-12 at 13:00 +0800, Tang Chen wrote:
Hi Rafael, Toshi,
When we hot-add an AC
Hi Toshi,
On 09/26/2013 06:24 AM, Toshi Kani wrote:
> On Wed, 2013-09-25 at 10:31 +, Gu Zheng wrote:
>> Hi Toshi,
>>
>> On 09/12/2013 11:11 PM, Toshi Kani wrote:
>>
>>> On Thu, 2013-09-12 at 13:00 +0800, Tang Chen wrote:
Hi Rafael, Toshi,
When we hot-add an ACPI0004 device, we
On Wed, Sep 25, 2013 at 6:02 PM, Bob Liu wrote:
> On Wed, Sep 25, 2013 at 5:33 PM, Weijie Yang wrote:
>> On Wed, Sep 25, 2013 at 4:31 PM, Bob Liu wrote:
>>> On Wed, Sep 25, 2013 at 4:09 PM, Weijie Yang
>>> wrote:
I think I find a new issue, for integrity of this mail thread, I reply
On Wed, 2013-09-25 at 10:31 +, Gu Zheng wrote:
> Hi Toshi,
>
> On 09/12/2013 11:11 PM, Toshi Kani wrote:
>
> > On Thu, 2013-09-12 at 13:00 +0800, Tang Chen wrote:
> >> Hi Rafael, Toshi,
> >>
> >> When we hot-add an ACPI0004 device, we got the following warning:
> >>
> >>acpi ACPI0004:01:
On Wednesday, September 25, 2013 06:31:09 PM Gu Zheng wrote:
> Hi Toshi,
>
> On 09/12/2013 11:11 PM, Toshi Kani wrote:
>
> > On Thu, 2013-09-12 at 13:00 +0800, Tang Chen wrote:
> >> Hi Rafael, Toshi,
> >>
> >> When we hot-add an ACPI0004 device, we got the following warning:
> >>
> >>acpi ACP
Hi Toshi,
On 09/12/2013 11:11 PM, Toshi Kani wrote:
> On Thu, 2013-09-12 at 13:00 +0800, Tang Chen wrote:
>> Hi Rafael, Toshi,
>>
>> When we hot-add an ACPI0004 device, we got the following warning:
>>
>> acpi ACPI0004:01: Attempt to re-insert
>>
>> The ACPI0004 device is a System Board in F
On Wed, Sep 25, 2013 at 5:33 PM, Weijie Yang wrote:
> On Wed, Sep 25, 2013 at 4:31 PM, Bob Liu wrote:
>> On Wed, Sep 25, 2013 at 4:09 PM, Weijie Yang
>> wrote:
>>> I think I find a new issue, for integrity of this mail thread, I reply
>>> to this mail.
>>>
>>> It is a concurrence issue either,
On Wed, Sep 25, 2013 at 4:31 PM, Bob Liu wrote:
> On Wed, Sep 25, 2013 at 4:09 PM, Weijie Yang wrote:
>> I think I find a new issue, for integrity of this mail thread, I reply
>> to this mail.
>>
>> It is a concurrence issue either, when duplicate store and reclaim
>> concurrentlly.
>>
>> zswap e
On Wed, Sep 25, 2013 at 4:09 PM, Weijie Yang wrote:
> I think I find a new issue, for integrity of this mail thread, I reply
> to this mail.
>
> It is a concurrence issue either, when duplicate store and reclaim
> concurrentlly.
>
> zswap entry x with offset A is already stored in zswap backend.
>
I think I find a new issue, for integrity of this mail thread, I reply
to this mail.
It is a concurrence issue either, when duplicate store and reclaim
concurrentlly.
zswap entry x with offset A is already stored in zswap backend.
Consider the following scenario:
thread 0: reclaim entry x (get r
On Thu, 2013-09-12 at 13:00 +0800, Tang Chen wrote:
> Hi Rafael, Toshi,
>
> When we hot-add an ACPI0004 device, we got the following warning:
>
> acpi ACPI0004:01: Attempt to re-insert
>
> The ACPI0004 device is a System Board in Fujitsu server, which has two
> numa nodes (processors and m
Hi Rafael, Toshi,
When we hot-add an ACPI0004 device, we got the following warning:
acpi ACPI0004:01: Attempt to re-insert
The ACPI0004 device is a System Board in Fujitsu server, which has two
numa nodes (processors and memory).
It seems that we reserved the ACPI_NOTIFY_DEVICE_CHECK e
On 08/21/2013 08:58 PM, Libin wrote:
> I test it on IBM System x3850 X5 platform, and also trigger oops in boot
> process. But if don't config the kmemcheck, it can boot up normally.
> Hardware information and oops information as following:
>
> [0.205976] BUG: unable to handle kernel paging re
On 2013/8/21 12:46, Dave Hansen wrote:
> On 08/20/2013 07:45 PM, Libin wrote:
>> [3.158023] [ cut here ]
>> [3.162626] WARNING: CPU: 0 PID: 1 at
>> arch/x86/mm/kmemcheck/kmemcheck.c:634 kmemcheck_fault+0xb1/0xc0()
> ...
>> [3.314877] [] ? kmemcheck_trap+0x17/0x
Hello,
On Tue, Aug 20, 2013 at 11:30:29PM +0800, Weijie Yang wrote:
> 2013/8/19 Minchan Kim :
> > On Mon, Aug 19, 2013 at 10:17:38AM +0800, Bob Liu wrote:
> >> Hi Weijie,
> >>
> >> On 08/19/2013 12:14 AM, Weijie Yang wrote:
> >> > I found a few bugs in zswap when I review Linux-3.11-rc5, and I hav
On 08/20/2013 07:45 PM, Libin wrote:
> [3.158023] [ cut here ]
> [3.162626] WARNING: CPU: 0 PID: 1 at
> arch/x86/mm/kmemcheck/kmemcheck.c:634 kmemcheck_fault+0xb1/0xc0()
...
> [3.314877] [] ? kmemcheck_trap+0x17/0x30
> [3.320507] <> <#DB> [] do_debug+0x1
2013/8/19 Minchan Kim :
> On Mon, Aug 19, 2013 at 10:17:38AM +0800, Bob Liu wrote:
>> Hi Weijie,
>>
>> On 08/19/2013 12:14 AM, Weijie Yang wrote:
>> > I found a few bugs in zswap when I review Linux-3.11-rc5, and I have
>> > also some questions about it, described as following:
>> >
>> > BUG:
>> >
On 08/19/2013 07:44 PM, Libin wrote:
> When kmemcheck kernel support configured??we encountered random kernel panic
> (sometimes can be booted) during system boot process in our environment. I
> have tested the mainline kernel version from v3.0 to v3.11-rc6, they also
> have this problem. And the m
On Mon, Aug 19, 2013 at 10:17:38AM +0800, Bob Liu wrote:
> Hi Weijie,
>
> On 08/19/2013 12:14 AM, Weijie Yang wrote:
> > I found a few bugs in zswap when I review Linux-3.11-rc5, and I have
> > also some questions about it, described as following:
> >
> > BUG:
> > 1. A race condition when reclaim
Hi Weijie,
On 08/19/2013 12:14 AM, Weijie Yang wrote:
> I found a few bugs in zswap when I review Linux-3.11-rc5, and I have
> also some questions about it, described as following:
>
> BUG:
> 1. A race condition when reclaim a page
> when a handle alloced from zbud, zbud considers this handle is
I found a few bugs in zswap when I review Linux-3.11-rc5, and I have
also some questions about it, described as following:
BUG:
1. A race condition when reclaim a page
when a handle alloced from zbud, zbud considers this handle is used
validly by upper(zswap) and can be a candidate for reclaim.
Bu
Hello,
On Tue, Aug 13, 2013 at 01:21:12PM +0530, Shyam Kaushik wrote:
> Any chances of backporting some parts of fix to <3.9 kernels?
For kernels which are too old for -stable, backporting is up to the
distros which hopefully are still maintaining the kernel (you really
don't want to run an unmai
: Shyam Kaushik
Cc: Tejun Heo; Andrew Morton; linux-kernel@vger.kernel.org
Subject: Re: BUG REPORT - IDR wraps around at 30-bits - works very bad
with NFSD/SCTP
On Tue, Aug 13, 2013 at 12:51:14PM +0530, Shyam Kaushik wrote:
> Hi Greg,
>
> Unfortunately we don't have a 3.9/3.10 enviro
dule_exit(driver_exit);
-Original Message-
From: Greg KH [mailto:gre...@linuxfoundation.org]
Sent: Tuesday, August 13, 2013 1:03 PM
To: Shyam Kaushik
Cc: linux-kernel@vger.kernel.org
Subject: Re: BUG REPORT - IDR wraps around at 30-bits - works very bad
with NFSD/SCTP
On Tue, Aug 13, 2013
On Tue, Aug 13, 2013 at 12:31:29PM +0530, Shyam Kaushik wrote:
> pr_info("%d\n", MAX_INT);
How did this line build, there is no MAX_INT in the kernel tree.
odd.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.
On Tue, Aug 13, 2013 at 12:51:14PM +0530, Shyam Kaushik wrote:
> Hi Greg,
>
> Unfortunately we dont have a 3.9/3.10 environment here. So if IDR
> developers can try the example code, it should show if the bug is still
> present in there. Thanks.
There shouldn't be anything in 3.10 preventing you
PM
To: Shyam Kaushik
Cc: Tejun Heo; Andrew Morton; linux-kernel@vger.kernel.org
Subject: Re: BUG REPORT - IDR wraps around at 30-bits - works very bad
with NFSD/SCTP
On Tue, Aug 13, 2013 at 12:31:29PM +0530, Shyam Kaushik wrote:
> Hi Folks,
>
> We are using Ubuntu linux kernel 3.2.0-2
On Tue, Aug 13, 2013 at 12:31:29PM +0530, Shyam Kaushik wrote:
> Hi Folks,
>
> We are using Ubuntu linux kernel 3.2.0-25-generic & 3.8.13-030813-generic
> in our environments, but I think this bug is still present in mainline
> kernel. Clients of IDR rollover at MAX_INT (NFSD & SCTP in kernel do t
Hi Folks,
We are using Ubuntu linux kernel 3.2.0-25-generic & 3.8.13-030813-generic
in our environments, but I think this bug is still present in mainline
kernel. Clients of IDR rollover at MAX_INT (NFSD & SCTP in kernel do this)
& others on MAX_IDR_MASK. This is ideally 2^31. But there is some BU
Summary: use bonding lacp mode aggregation NIC has performance
problems while intel_immu switch opening
Product: Networking
Version:
Kernel Version: 3.10.0-rc5
Platform: X86
OS/Version: Linux
Tree: Mainline
Status:
yes, it works with them.
Those patches will be included in the next rc of the kernel 3.10?
2013/6/15 Yinghai Lu :
> On Sat, Jun 15, 2013 at 8:34 AM, diego fanesi wrote:
>> I would like to report a bug about the module acpiphp. I don't know if
>> this is the right place, if it isn't please tell m
On Sat, Jun 15, 2013 at 8:34 AM, diego fanesi wrote:
> I would like to report a bug about the module acpiphp. I don't know if
> this is the right place, if it isn't please tell me where I should
> write and I will do it.
>
> description: docking station hotplug working on 3.5.0 kernel but not
> in
I would like to report a bug about the module acpiphp. I don't know if
this is the right place, if it isn't please tell me where I should
write and I will do it.
description: docking station hotplug working on 3.5.0 kernel but not
in previous and next kernel releases
hardware: sony vaio serie z SV
* Andi Kleen wrote:
> > I found a similar system (not same stepping, but same model) and tested
> > perf top works fine here. Also on a couple of other systems.
> >
> > Since I cannot reproduce I would need your help debugging it.
>
> Ingo, I haven't heard back from you on this.
FYI, the v3.
> I found a similar system (not same stepping, but same model) and tested
> perf top works fine here. Also on a couple of other systems.
>
> Since I cannot reproduce I would need your help debugging it.
Ingo, I haven't heard back from you on this.
You reported an unreproducable bug. I gave you
Quoting Jens Axboe (2013-04-19 09:32:50)
> >
> > No wonder this thing crashes. Chris, can't the original bio carry
> > bbio in bi_private and let end_bio_extent_readpage() free the bbio
> > instead of abusing bi_bdev like this?
>
> Ugh, wtf.
>
> Chris, time for a swim in the bay :-)
Yeah, I ca
On Thu, Apr 18 2013, Tejun Heo wrote:
> (cc'ing btrfs people)
>
> On Fri, Apr 19, 2013 at 11:33:20AM +0800, Wanlong Gao wrote:
> > RIP: 0010:[] []
> > ftrace_raw_event_block_bio_complete+0x73/0xf0
> ...
> > [] bio_endio+0x80/0x90
> > [] btrfs_end_bio+0xf6/0x190 [btrfs]
> > [] bio_endio+0x3d/0
On Thu, Apr 18 2013, Tejun Heo wrote:
> On Thu, Apr 18, 2013 at 10:57:54PM -0700, Tejun Heo wrote:
> > No wonder this thing crashes. Chris, can't the original bio carry
> > bbio in bi_private and let end_bio_extent_readpage() free the bbio
> > instead of abusing bi_bdev like this?
>
> BTW, I thin
Quoting Tejun Heo (2013-04-19 01:57:54)
>
> Ewweehh
>
> No wonder this thing crashes. Chris, can't the original bio carry
> bbio in bi_private and let end_bio_extent_readpage() free the bbio
> instead of abusing bi_bdev like this?
Yes, we can definitely carry bbio up hig
On Fri, April 19, 2013 at 07:57 (+0200), Tejun Heo wrote:
> (cc'ing btrfs people)
>
> On Fri, Apr 19, 2013 at 11:33:20AM +0800, Wanlong Gao wrote:
>> RIP: 0010:[] []
>> ftrace_raw_event_block_bio_complete+0x73/0xf0
> ...
>> [] bio_endio+0x80/0x90
>> [] btrfs_end_bio+0xf6/0x190 [btrfs]
>> [] b
On 04/19/2013 02:17 PM, Tejun Heo wrote:
> On Thu, Apr 18, 2013 at 10:57:54PM -0700, Tejun Heo wrote:
>> No wonder this thing crashes. Chris, can't the original bio carry
>> bbio in bi_private and let end_bio_extent_readpage() free the bbio
>> instead of abusing bi_bdev like this?
>
> BTW, I thin
On Thu, Apr 18, 2013 at 10:57:54PM -0700, Tejun Heo wrote:
> No wonder this thing crashes. Chris, can't the original bio carry
> bbio in bi_private and let end_bio_extent_readpage() free the bbio
> instead of abusing bi_bdev like this?
BTW, I think it's a bit too late to fix this properly from bt
(cc'ing btrfs people)
On Fri, Apr 19, 2013 at 11:33:20AM +0800, Wanlong Gao wrote:
> RIP: 0010:[] []
> ftrace_raw_event_block_bio_complete+0x73/0xf0
...
> [] bio_endio+0x80/0x90
> [] btrfs_end_bio+0xf6/0x190 [btrfs]
> [] bio_endio+0x3d/0x90
> [] req_bio_endio+0xa3/0xe0
Ugh
In fs/btrfs/
On 04/18/2013 10:30 PM, Jens Axboe wrote:
> On Thu, Apr 18 2013, Wanlong Gao wrote:
>> On 04/18/2013 09:35 PM, Jens Axboe wrote:
>>> On Thu, Apr 18 2013, Wanlong Gao wrote:
> A bio is always fully initialized, regardless of which internal
> allocator it came from. If people are doing privat
Could it be a module not recompiled with a newer kernel?
-- Steve
Jens Axboe wrote:
>
>Hmm dunno. It happens right after we've completed the bio, which
>touches
>a lot of fields too. bi_bdev sits between bi_next (which we definitely
>used) and bi_flags.
>
>But adding slab use-after-free debug
On Thu, Apr 18 2013, Linus Torvalds wrote:
> On Thu, Apr 18, 2013 at 11:13 AM, Jens Axboe wrote:
> > On Thu, Apr 18 2013, Tejun Heo wrote:
> >> On Thu, Apr 18, 2013 at 10:39:00AM -0700, Jens Axboe wrote:
> >> >
> >> > Yep, thanks Linus for that hint... Must be someone abusing it for a
> >> > flag
On Thu, Apr 18, 2013 at 11:13 AM, Jens Axboe wrote:
> On Thu, Apr 18 2013, Tejun Heo wrote:
>> On Thu, Apr 18, 2013 at 10:39:00AM -0700, Jens Axboe wrote:
>> >
>> > Yep, thanks Linus for that hint... Must be someone abusing it for a
>> > flag field post submission? Crazy.
>>
>> Let's hope that's n
On Thu, Apr 18 2013, Tejun Heo wrote:
> On Thu, Apr 18, 2013 at 10:39:00AM -0700, Jens Axboe wrote:
> > > If I'm not mistaken, it seems like we have a bio which has 1 as its
> > > ->bi_bdev. Ummm no idea whatsoever how that can happen tho right
> > > now. Looking into it.
> >
> > Yep, thanks
On Thu, Apr 18, 2013 at 10:39:00AM -0700, Jens Axboe wrote:
> > If I'm not mistaken, it seems like we have a bio which has 1 as its
> > ->bi_bdev. Ummm no idea whatsoever how that can happen tho right
> > now. Looking into it.
>
> Yep, thanks Linus for that hint... Must be someone abusing it
Hello, Wanlong.
On Thu, Apr 18, 2013 at 10:45:10PM +0800, Wanlong Gao wrote:
> OK, but I should capture it tomorrow morning because this remote machine has
> already panicked
> and need hard reboot.
Can you please apply the following patch when you try the next time
and report the kernel log? I
On Thu, Apr 18 2013, Tejun Heo wrote:
> Hello,
>
> On Thu, Apr 18, 2013 at 09:08:34AM -0700, Linus Torvalds wrote:
> > On Thu, Apr 18, 2013 at 7:30 AM, Jens Axboe wrote:
> > >
> > > Could you capture the full dump? I'd like to see what rcx was, and that
> > > seems to have scrolled off.
> >
> >
Hello,
On Thu, Apr 18, 2013 at 09:08:34AM -0700, Linus Torvalds wrote:
> On Thu, Apr 18, 2013 at 7:30 AM, Jens Axboe wrote:
> >
> > Could you capture the full dump? I'd like to see what rcx was, and that
> > seems to have scrolled off.
>
> You don't need it. The %cr2 value shows the address of t
On Thu, Apr 18, 2013 at 7:30 AM, Jens Axboe wrote:
>
> Could you capture the full dump? I'd like to see what rcx was, and that
> seems to have scrolled off.
You don't need it. The %cr2 value shows the address of the bad access,
and it's 0x0001.
Linus
--
To unsubscribe from th
On 04/18/2013 10:30 PM, Jens Axboe wrote:
> On Thu, Apr 18 2013, Wanlong Gao wrote:
>> On 04/18/2013 09:35 PM, Jens Axboe wrote:
>>> On Thu, Apr 18 2013, Wanlong Gao wrote:
> A bio is always fully initialized, regardless of which internal
> allocator it came from. If people are doing privat
On Thu, Apr 18 2013, Wanlong Gao wrote:
> On 04/18/2013 09:35 PM, Jens Axboe wrote:
> > On Thu, Apr 18 2013, Wanlong Gao wrote:
> >>> A bio is always fully initialized, regardless of which internal
> >>> allocator it came from. If people are doing private kmallocs, then they
> >>> better be using b
On 04/18/2013 09:35 PM, Jens Axboe wrote:
> On Thu, Apr 18 2013, Wanlong Gao wrote:
>>> A bio is always fully initialized, regardless of which internal
>>> allocator it came from. If people are doing private kmallocs, then they
>>> better be using bio_init() as well.
>>>
>>> Wanlong, would it be po
On Thu, Apr 18 2013, Wanlong Gao wrote:
> > A bio is always fully initialized, regardless of which internal
> > allocator it came from. If people are doing private kmallocs, then they
> > better be using bio_init() as well.
> >
> > Wanlong, would it be possible to get a full dmesg on boot see I ca
On Wed, Apr 17 2013, Steven Rostedt wrote:
> On Wed, 2013-04-17 at 16:36 +0800, Wanlong Gao wrote:
> > Hi Tj, all,
> >
> > I can get kernel panic on my machine with kernel 3.9.0-rc7-4-gbb33db7 every
> > time
> > after booting for several minutes.
> >
> > Here attached the panic picture and the c
On Wed, 2013-04-17 at 16:36 +0800, Wanlong Gao wrote:
> Hi Tj, all,
>
> I can get kernel panic on my machine with kernel 3.9.0-rc7-4-gbb33db7 every
> time
> after booting for several minutes.
>
> Here attached the panic picture and the config.
> I'm sorry that the panic log is not completed.
>
ncing bugs get merged. I find it useful.
> >
> > Recently however there was a comment about a commit referencing a commit
> > referencing the bug report. Turns out the comment was missing one level
> > of indirection, it was really about a commit referencing a commit
> > refere
commit
> referencing the bug report. Turns out the comment was missing one level
> of indirection, it was really about a commit referencing a commit
> referencing a commit referencing the bug [1].
>
> Do we really need go that far, or is that a bug in your scripts? I think
> th
Hello Peter
[with Andrea and Mel cced]
On Fri, Feb 22, 2013 at 8:51 PM, Peter Hurley wrote:
> Hi Kirill,
>
> I thought you might be interested in this.
>
> HEAD is now at a49f0d1... Linux 3.8-rc1
> peter@thor:~/src/kernels/mainline$ sed = mm/huge_memory.c | sed 'N;s/\n/ /' |
> sed -n '2730,2744
Hi Kirill,
I thought you might be interested in this.
HEAD is now at a49f0d1... Linux 3.8-rc1
peter@thor:~/src/kernels/mainline$ sed = mm/huge_memory.c | sed 'N;s/\n/ /' |
sed -n '2730,2744p'
2730spin_unlock(&mm->page_table_lock);
2731mmu_notifier_invalidate_range_end(mm,
Feb 22 10:44:16 nkoc kernel: [ cut here ]
Feb 22 10:44:16 nkoc kernel: kernel BUG at mm/huge_memory.c:2743!
Feb 22 10:44:16 nkoc kernel: invalid opcode: [#1] SMP
Feb 22 10:44:16 nkoc kernel: Modules linked in: snd_seq_dummy
snd_seq_oss snd_seq_midi_event snd_seq snd_
Hi Florian, all -
First, thanks for your work on adding the bugzilla comments when patches
referencing bugs get merged. I find it useful.
Recently however there was a comment about a commit referencing a commit
referencing the bug report. Turns out the comment was missing one level
of
Hi,
2013-01-18 (금), 16:29 +0300, Dan Carpenter:
> Hello Jaegeuk Kim,
>
> The patch 7bc0900347e0: "f2fs: add garbage collection functions" from
> Nov 2, 2012, has an off-by-one bug.
>
>429 block_t start_bidx_of_node(unsigned int node_ofs)
>430 {
>431 unsigned int indirect_
Hello Jaegeuk Kim,
The patch 7bc0900347e0: "f2fs: add garbage collection functions" from
Nov 2, 2012, has an off-by-one bug.
429 block_t start_bidx_of_node(unsigned int node_ofs)
430 {
431 unsigned int indirect_blks = 2 * NIDS_PER_BLOCK + 4;
432 unsigned int bidx;
On Mon, Dec 03, 2012 at 10:52:27AM +0800, Lin Feng wrote:
>
>
> On 11/30/2012 07:00 PM, Mel Gorman wrote:
> >>
> >> Well, that's a fairly low-level implementation detail. A more typical
> >> approach would be to add a new get_user_pages_non_movable() or such.
> >> That would probably have the s
On 11/30/2012 06:47 PM, Andrew Morton wrote:
> On Fri, 30 Nov 2012 18:29:30 +0800 Lin Feng wrote:
>
>>> add a new library function which callers can use before (or after?)
>>> calling get_user_pages[_fast]().
>> Sorry, I'm not quite understand what "library function" function means..
>> Does it
On 11/30/2012 07:00 PM, Mel Gorman wrote:
>>
>> Well, that's a fairly low-level implementation detail. A more typical
>> approach would be to add a new get_user_pages_non_movable() or such.
>> That would probably have the same signature as get_user_pages(), with
>> one additional argument. The
hi Domenico,
Sorry for my late reply and thanks for your attention, see below :)
On 11/30/2012 11:24 PM, Domenico Andreoli wrote:
> On Thu, Nov 29, 2012 at 02:54:58PM +0800, Lin Feng wrote:
>> Hi all,
>
> Hi Lin,
>
>> We encounter a "Resource temporarily unavailable" fail while trying
>> to off
On Thu, Nov 29, 2012 at 02:54:58PM +0800, Lin Feng wrote:
> Hi all,
Hi Lin,
> We encounter a "Resource temporarily unavailable" fail while trying
> to offline a memory section in a movable zone. We found that there are
> some pages can't be migrated. The offline operation fails in function
> mi
On Thu, Nov 29, 2012 at 11:55:02PM -0800, Andrew Morton wrote:
> On Fri, 30 Nov 2012 15:01:26 +0800 Lin Feng wrote:
>
> >
> >
> > On 11/30/2012 01:57 PM, Andrew Morton wrote:
> > > On Fri, 30 Nov 2012 11:42:05 +0800 Lin Feng
> > > wrote:
> > >
> > >> hi Andrew,
> > >>
> > >> On 11/30/2012 07
On Thu, Nov 29, 2012 at 03:39:30PM -0800, Andrew Morton wrote:
> On Thu, 29 Nov 2012 14:54:58 +0800
> Lin Feng wrote:
>
> > Hi all,
> >
> > We encounter a "Resource temporarily unavailable" fail while trying
> > to offline a memory section in a movable zone. We found that there are
> > some pag
On Fri, 30 Nov 2012 18:29:30 +0800 Lin Feng wrote:
> > add a new library function which callers can use before (or after?)
> > calling get_user_pages[_fast]().
> Sorry, I'm not quite understand what "library function" function means..
> Does it means a function aids get_user_pages() or totally wr
On 11/30/2012 03:55 PM, Andrew Morton wrote:
> On Fri, 30 Nov 2012 15:01:26 +0800 Lin Feng wrote:
>
>>
>>
>> On 11/30/2012 01:57 PM, Andrew Morton wrote:
>>> On Fri, 30 Nov 2012 11:42:05 +0800 Lin Feng wrote:
>>>
hi Andrew,
On 11/30/2012 07:39 AM, Andrew Morton wrote:
> Tric
301 - 400 of 623 matches
Mail list logo
