* [Bug 25280] r600: glPolygonStipple broken
From: bugzilla-daemon @ 2011-10-22 17:34 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-25280-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=25280
gsr.bugs <gsr.bugs@infernal-iceberg.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |gsr.bugs@infernal-iceberg.c
| |om
--- Comment #6 from gsr.bugs <gsr.bugs@infernal-iceberg.com> 2011-10-22 10:34:40 PDT ---
r300c at least can use software fallbacks (see driconf), which make app like
Blender usable (polygon and line stipples are used to give feedback about item
relations, object types, selection status, etc). Should not Gallium also use
software fallbacks, at least as stop gap until shader method is coded?
Specially if r[36]00c are going to be deprecated in the near future.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* Re: kernel 3.0: BUG: soft lockup: find_get_pages+0x51/0x110
From: Paweł Sikora @ 2011-10-22 16:42 UTC (permalink / raw)
To: nai.xia
Cc: Hugh Dickins, arekm, Linus Torvalds, linux-mm, Mel Gorman,
jpiszcz, linux-kernel, Andrew Morton, Andrea Arcangeli
In-Reply-To: <201110221421.23181.nai.xia@gmail.com>
On Saturday 22 of October 2011 08:21:23 Nai Xia wrote:
> On Saturday 22 October 2011 05:36:46 PaweA? Sikora wrote:
> > On Friday 21 of October 2011 11:07:56 Nai Xia wrote:
> > > On Fri, Oct 21, 2011 at 4:07 PM, Pawel Sikora <pluto@agmk.net> wrote:
> > > > On Friday 21 of October 2011 14:22:37 Nai Xia wrote:
> > > >
> > > >> And as a side note. Since I notice that Pawel's workload may include OOM,
> > > >
> > > > my last tests on patched (3.0.4 + migrate.c fix + vserver) kernel produce full cpu load
> > > > on dual 8-cores opterons like on this htop screenshot -> http://pluto.agmk.net/kernel/screen1.png
> > > > afaics all userspace applications usualy don't use more than half of physical memory
> > > > and so called "cache" on htop bar doesn't reach the 100%.
> > >
> > > OKi 1/4 ?did you logged any OOM killing if there was some memory usage burst?
> > > But, well my above OOM reasoning is a direct short cut to imagined
> > > root cause of "adjacent VMAs which
> > > should have been merged but in fact not merged" case.
> > > Maybe there are other cases that can lead to this or maybe it's
> > > totally another bug....
> >
> > i don't see any OOM killing with my conservative settings
> > (vm.overcommit_memory=2, vm.overcommit_ratio=100).
>
> OK, that does not matter now. Andrea showed us a simpler way to goto
> this bug.
>
> >
> > > But still I think if my reasoning is good, similar bad things will
> > > happen again some time in the future,
> > > even if it was not your case here...
> > >
> > > >
> > > > the patched kernel with disabled CONFIG_TRANSPARENT_HUGEPAGE (new thing in 2.6.38)
> > > > died at night, so now i'm going to disable also CONFIG_COMPACTION/MIGRATION in next
> > > > steps and stress this machine again...
> > >
> > > OK, it's smart to narrow down the range first....
> >
> > disabling hugepage/compacting didn't help but disabling hugepage/compacting/migration keeps
> > opterons stable for ~9h so far. userspace uses ~40GB (from 64) ram, caches reach 100% on htop bar,
> > average load ~16. i wonder if it survive weekend...
> >
>
> Maybe you should give another shot of Andrea's latest anon_vma_order_tail() patch. :)
>
all my attempts to disabling thp/compaction/migration failed (machine locked).
now, i'm testing 3.0.7+vserver+Hugh's+Andrea's patches+enabled few kernel debug options.
so far it has logged only something unrelated to memory managment subsystem:
[ 258.397014] =======================================================
[ 258.397209] [ INFO: possible circular locking dependency detected ]
[ 258.397311] 3.0.7-vs2.3.1-dirty #1
[ 258.397402] -------------------------------------------------------
[ 258.397503] slave_odra_g_00/19432 is trying to acquire lock:
[ 258.397603] (&(&sig->cputimer.lock)->rlock){-.....}, at: [<ffffffff8103adfc>] update_curr+0xfc/0x190
[ 258.397912]
[ 258.397912] but task is already holding lock:
[ 258.398090] (&rq->lock){-.-.-.}, at: [<ffffffff81041a8e>] scheduler_tick+0x4e/0x280
[ 258.398387]
[ 258.398388] which lock already depends on the new lock.
[ 258.398389]
[ 258.398652]
[ 258.398653] the existing dependency chain (in reverse order) is:
[ 258.398836]
[ 258.398837] -> #2 (&rq->lock){-.-.-.}:
[ 258.399178] [<ffffffff810959ee>] lock_acquire+0x8e/0x120
[ 258.399336] [<ffffffff81466e5c>] _raw_spin_lock+0x2c/0x40
[ 258.399495] [<ffffffff81040bd7>] wake_up_new_task+0x97/0x1c0
[ 258.399652] [<ffffffff81047db6>] do_fork+0x176/0x460
[ 258.399807] [<ffffffff8100999c>] kernel_thread+0x6c/0x70
[ 258.399964] [<ffffffff8144715d>] rest_init+0x21/0xc4
[ 258.400120] [<ffffffff818adbd2>] start_kernel+0x3d6/0x3e1
[ 258.400280] [<ffffffff818ad322>] x86_64_start_reservations+0x132/0x136
[ 258.400336] [<ffffffff818ad416>] x86_64_start_kernel+0xf0/0xf7
[ 258.400336]
[ 258.400336] -> #1 (&p->pi_lock){-.-.-.}:
[ 258.400336] [<ffffffff810959ee>] lock_acquire+0x8e/0x120
[ 258.400336] [<ffffffff81466f5c>] _raw_spin_lock_irqsave+0x3c/0x60
[ 258.400336] [<ffffffff8106f328>] thread_group_cputimer+0x38/0x100
[ 258.400336] [<ffffffff8106f41d>] cpu_timer_sample_group+0x2d/0xa0
[ 258.400336] [<ffffffff8107080a>] set_process_cpu_timer+0x3a/0x110
[ 258.400336] [<ffffffff8107091a>] update_rlimit_cpu+0x3a/0x60
[ 258.400336] [<ffffffff81062c0e>] do_prlimit+0x19e/0x240
[ 258.400336] [<ffffffff81063008>] sys_setrlimit+0x48/0x60
[ 258.400336] [<ffffffff8146efbb>] system_call_fastpath+0x16/0x1b
[ 258.400336]
[ 258.400336] -> #0 (&(&sig->cputimer.lock)->rlock){-.....}:
[ 258.400336] [<ffffffff810951e7>] __lock_acquire+0x1aa7/0x1cc0
[ 258.400336] [<ffffffff810959ee>] lock_acquire+0x8e/0x120
[ 258.400336] [<ffffffff81466e5c>] _raw_spin_lock+0x2c/0x40
[ 258.400336] [<ffffffff8103adfc>] update_curr+0xfc/0x190
[ 258.400336] [<ffffffff8103b22d>] task_tick_fair+0x2d/0x140
[ 258.400336] [<ffffffff81041b0f>] scheduler_tick+0xcf/0x280
[ 258.400336] [<ffffffff8105a439>] update_process_times+0x69/0x80
[ 258.400336] [<ffffffff8108e0cf>] tick_sched_timer+0x5f/0xc0
[ 258.400336] [<ffffffff81071339>] __run_hrtimer+0x79/0x1f0
[ 258.400336] [<ffffffff81071ce3>] hrtimer_interrupt+0xf3/0x220
[ 258.400336] [<ffffffff8101daa4>] smp_apic_timer_interrupt+0x64/0xa0
[ 258.400336] [<ffffffff8146f9d3>] apic_timer_interrupt+0x13/0x20
[ 258.400336] [<ffffffff8107092d>] update_rlimit_cpu+0x4d/0x60
[ 258.400336] [<ffffffff81062c0e>] do_prlimit+0x19e/0x240
[ 258.400336] [<ffffffff81063008>] sys_setrlimit+0x48/0x60
[ 258.400336] [<ffffffff8146efbb>] system_call_fastpath+0x16/0x1b
[ 258.400336]
[ 258.400336] other info that might help us debug this:
[ 258.400336]
[ 258.400336] Chain exists of:
[ 258.400336] &(&sig->cputimer.lock)->rlock --> &p->pi_lock --> &rq->lock
[ 258.400336]
[ 258.400336] Possible unsafe locking scenario:
[ 258.400336]
[ 258.400336] CPU0 CPU1
[ 258.400336] ---- ----
[ 258.400336] lock(&rq->lock);
[ 258.400336] lock(&p->pi_lock);
[ 258.400336] lock(&rq->lock);
[ 258.400336] lock(&(&sig->cputimer.lock)->rlock);
[ 258.400336]
[ 258.400336] *** DEADLOCK ***
[ 258.400336]
[ 258.400336] 2 locks held by slave_odra_g_00/19432:
[ 258.400336] #0: (tasklist_lock){.+.+..}, at: [<ffffffff81062acd>] do_prlimit+0x5d/0x240
[ 258.400336] #1: (&rq->lock){-.-.-.}, at: [<ffffffff81041a8e>] scheduler_tick+0x4e/0x280
[ 258.400336]
[ 258.400336] stack backtrace:
[ 258.400336] Pid: 19432, comm: slave_odra_g_00 Not tainted 3.0.7-vs2.3.1-dirty #1
[ 258.400336] Call Trace:
[ 258.400336] <IRQ> [<ffffffff8145e204>] print_circular_bug+0x23d/0x24e
[ 258.400336] [<ffffffff810951e7>] __lock_acquire+0x1aa7/0x1cc0
[ 258.400336] [<ffffffff8109264d>] ? mark_lock+0x2dd/0x330
[ 258.400336] [<ffffffff81093bfd>] ? __lock_acquire+0x4bd/0x1cc0
[ 258.400336] [<ffffffff8103adfc>] ? update_curr+0xfc/0x190
[ 258.400336] [<ffffffff810959ee>] lock_acquire+0x8e/0x120
[ 258.400336] [<ffffffff8103adfc>] ? update_curr+0xfc/0x190
[ 258.400336] [<ffffffff81466e5c>] _raw_spin_lock+0x2c/0x40
[ 258.400336] [<ffffffff8103adfc>] ? update_curr+0xfc/0x190
[ 258.400336] [<ffffffff8103adfc>] update_curr+0xfc/0x190
[ 258.400336] [<ffffffff8103b22d>] task_tick_fair+0x2d/0x140
[ 258.400336] [<ffffffff81041b0f>] scheduler_tick+0xcf/0x280
[ 258.400336] [<ffffffff8105a439>] update_process_times+0x69/0x80
[ 258.400336] [<ffffffff8108e0cf>] tick_sched_timer+0x5f/0xc0
[ 258.400336] [<ffffffff81071339>] __run_hrtimer+0x79/0x1f0
[ 258.400336] [<ffffffff8108e070>] ? tick_nohz_handler+0x100/0x100
[ 258.400336] [<ffffffff81071ce3>] hrtimer_interrupt+0xf3/0x220
[ 258.400336] [<ffffffff8101daa4>] smp_apic_timer_interrupt+0x64/0xa0
[ 258.400336] [<ffffffff8146f9d3>] apic_timer_interrupt+0x13/0x20
[ 258.400336] <EOI> [<ffffffff814674e0>] ? _raw_spin_unlock_irq+0x30/0x40
[ 258.400336] [<ffffffff8107092d>] update_rlimit_cpu+0x4d/0x60
[ 258.400336] [<ffffffff81062c0e>] do_prlimit+0x19e/0x240
[ 258.400336] [<ffffffff81063008>] sys_setrlimit+0x48/0x60
[ 258.400336] [<ffffffff8146efbb>] system_call_fastpath+0x16/0x1b
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: kernel 3.0: BUG: soft lockup: find_get_pages+0x51/0x110
From: Paweł Sikora @ 2011-10-22 16:42 UTC (permalink / raw)
To: nai.xia
Cc: Hugh Dickins, arekm, Linus Torvalds, linux-mm, Mel Gorman,
jpiszcz, linux-kernel, Andrew Morton, Andrea Arcangeli
In-Reply-To: <201110221421.23181.nai.xia@gmail.com>
On Saturday 22 of October 2011 08:21:23 Nai Xia wrote:
> On Saturday 22 October 2011 05:36:46 Paweł Sikora wrote:
> > On Friday 21 of October 2011 11:07:56 Nai Xia wrote:
> > > On Fri, Oct 21, 2011 at 4:07 PM, Pawel Sikora <pluto@agmk.net> wrote:
> > > > On Friday 21 of October 2011 14:22:37 Nai Xia wrote:
> > > >
> > > >> And as a side note. Since I notice that Pawel's workload may include OOM,
> > > >
> > > > my last tests on patched (3.0.4 + migrate.c fix + vserver) kernel produce full cpu load
> > > > on dual 8-cores opterons like on this htop screenshot -> http://pluto.agmk.net/kernel/screen1.png
> > > > afaics all userspace applications usualy don't use more than half of physical memory
> > > > and so called "cache" on htop bar doesn't reach the 100%.
> > >
> > > OK，did you logged any OOM killing if there was some memory usage burst?
> > > But, well my above OOM reasoning is a direct short cut to imagined
> > > root cause of "adjacent VMAs which
> > > should have been merged but in fact not merged" case.
> > > Maybe there are other cases that can lead to this or maybe it's
> > > totally another bug....
> >
> > i don't see any OOM killing with my conservative settings
> > (vm.overcommit_memory=2, vm.overcommit_ratio=100).
>
> OK, that does not matter now. Andrea showed us a simpler way to goto
> this bug.
>
> >
> > > But still I think if my reasoning is good, similar bad things will
> > > happen again some time in the future,
> > > even if it was not your case here...
> > >
> > > >
> > > > the patched kernel with disabled CONFIG_TRANSPARENT_HUGEPAGE (new thing in 2.6.38)
> > > > died at night, so now i'm going to disable also CONFIG_COMPACTION/MIGRATION in next
> > > > steps and stress this machine again...
> > >
> > > OK, it's smart to narrow down the range first....
> >
> > disabling hugepage/compacting didn't help but disabling hugepage/compacting/migration keeps
> > opterons stable for ~9h so far. userspace uses ~40GB (from 64) ram, caches reach 100% on htop bar,
> > average load ~16. i wonder if it survive weekend...
> >
>
> Maybe you should give another shot of Andrea's latest anon_vma_order_tail() patch. :)
>
all my attempts to disabling thp/compaction/migration failed (machine locked).
now, i'm testing 3.0.7+vserver+Hugh's+Andrea's patches+enabled few kernel debug options.
so far it has logged only something unrelated to memory managment subsystem:
[ 258.397014] =======================================================
[ 258.397209] [ INFO: possible circular locking dependency detected ]
[ 258.397311] 3.0.7-vs2.3.1-dirty #1
[ 258.397402] -------------------------------------------------------
[ 258.397503] slave_odra_g_00/19432 is trying to acquire lock:
[ 258.397603] (&(&sig->cputimer.lock)->rlock){-.....}, at: [<ffffffff8103adfc>] update_curr+0xfc/0x190
[ 258.397912]
[ 258.397912] but task is already holding lock:
[ 258.398090] (&rq->lock){-.-.-.}, at: [<ffffffff81041a8e>] scheduler_tick+0x4e/0x280
[ 258.398387]
[ 258.398388] which lock already depends on the new lock.
[ 258.398389]
[ 258.398652]
[ 258.398653] the existing dependency chain (in reverse order) is:
[ 258.398836]
[ 258.398837] -> #2 (&rq->lock){-.-.-.}:
[ 258.399178] [<ffffffff810959ee>] lock_acquire+0x8e/0x120
[ 258.399336] [<ffffffff81466e5c>] _raw_spin_lock+0x2c/0x40
[ 258.399495] [<ffffffff81040bd7>] wake_up_new_task+0x97/0x1c0
[ 258.399652] [<ffffffff81047db6>] do_fork+0x176/0x460
[ 258.399807] [<ffffffff8100999c>] kernel_thread+0x6c/0x70
[ 258.399964] [<ffffffff8144715d>] rest_init+0x21/0xc4
[ 258.400120] [<ffffffff818adbd2>] start_kernel+0x3d6/0x3e1
[ 258.400280] [<ffffffff818ad322>] x86_64_start_reservations+0x132/0x136
[ 258.400336] [<ffffffff818ad416>] x86_64_start_kernel+0xf0/0xf7
[ 258.400336]
[ 258.400336] -> #1 (&p->pi_lock){-.-.-.}:
[ 258.400336] [<ffffffff810959ee>] lock_acquire+0x8e/0x120
[ 258.400336] [<ffffffff81466f5c>] _raw_spin_lock_irqsave+0x3c/0x60
[ 258.400336] [<ffffffff8106f328>] thread_group_cputimer+0x38/0x100
[ 258.400336] [<ffffffff8106f41d>] cpu_timer_sample_group+0x2d/0xa0
[ 258.400336] [<ffffffff8107080a>] set_process_cpu_timer+0x3a/0x110
[ 258.400336] [<ffffffff8107091a>] update_rlimit_cpu+0x3a/0x60
[ 258.400336] [<ffffffff81062c0e>] do_prlimit+0x19e/0x240
[ 258.400336] [<ffffffff81063008>] sys_setrlimit+0x48/0x60
[ 258.400336] [<ffffffff8146efbb>] system_call_fastpath+0x16/0x1b
[ 258.400336]
[ 258.400336] -> #0 (&(&sig->cputimer.lock)->rlock){-.....}:
[ 258.400336] [<ffffffff810951e7>] __lock_acquire+0x1aa7/0x1cc0
[ 258.400336] [<ffffffff810959ee>] lock_acquire+0x8e/0x120
[ 258.400336] [<ffffffff81466e5c>] _raw_spin_lock+0x2c/0x40
[ 258.400336] [<ffffffff8103adfc>] update_curr+0xfc/0x190
[ 258.400336] [<ffffffff8103b22d>] task_tick_fair+0x2d/0x140
[ 258.400336] [<ffffffff81041b0f>] scheduler_tick+0xcf/0x280
[ 258.400336] [<ffffffff8105a439>] update_process_times+0x69/0x80
[ 258.400336] [<ffffffff8108e0cf>] tick_sched_timer+0x5f/0xc0
[ 258.400336] [<ffffffff81071339>] __run_hrtimer+0x79/0x1f0
[ 258.400336] [<ffffffff81071ce3>] hrtimer_interrupt+0xf3/0x220
[ 258.400336] [<ffffffff8101daa4>] smp_apic_timer_interrupt+0x64/0xa0
[ 258.400336] [<ffffffff8146f9d3>] apic_timer_interrupt+0x13/0x20
[ 258.400336] [<ffffffff8107092d>] update_rlimit_cpu+0x4d/0x60
[ 258.400336] [<ffffffff81062c0e>] do_prlimit+0x19e/0x240
[ 258.400336] [<ffffffff81063008>] sys_setrlimit+0x48/0x60
[ 258.400336] [<ffffffff8146efbb>] system_call_fastpath+0x16/0x1b
[ 258.400336]
[ 258.400336] other info that might help us debug this:
[ 258.400336]
[ 258.400336] Chain exists of:
[ 258.400336] &(&sig->cputimer.lock)->rlock --> &p->pi_lock --> &rq->lock
[ 258.400336]
[ 258.400336] Possible unsafe locking scenario:
[ 258.400336]
[ 258.400336] CPU0 CPU1
[ 258.400336] ---- ----
[ 258.400336] lock(&rq->lock);
[ 258.400336] lock(&p->pi_lock);
[ 258.400336] lock(&rq->lock);
[ 258.400336] lock(&(&sig->cputimer.lock)->rlock);
[ 258.400336]
[ 258.400336] *** DEADLOCK ***
[ 258.400336]
[ 258.400336] 2 locks held by slave_odra_g_00/19432:
[ 258.400336] #0: (tasklist_lock){.+.+..}, at: [<ffffffff81062acd>] do_prlimit+0x5d/0x240
[ 258.400336] #1: (&rq->lock){-.-.-.}, at: [<ffffffff81041a8e>] scheduler_tick+0x4e/0x280
[ 258.400336]
[ 258.400336] stack backtrace:
[ 258.400336] Pid: 19432, comm: slave_odra_g_00 Not tainted 3.0.7-vs2.3.1-dirty #1
[ 258.400336] Call Trace:
[ 258.400336] <IRQ> [<ffffffff8145e204>] print_circular_bug+0x23d/0x24e
[ 258.400336] [<ffffffff810951e7>] __lock_acquire+0x1aa7/0x1cc0
[ 258.400336] [<ffffffff8109264d>] ? mark_lock+0x2dd/0x330
[ 258.400336] [<ffffffff81093bfd>] ? __lock_acquire+0x4bd/0x1cc0
[ 258.400336] [<ffffffff8103adfc>] ? update_curr+0xfc/0x190
[ 258.400336] [<ffffffff810959ee>] lock_acquire+0x8e/0x120
[ 258.400336] [<ffffffff8103adfc>] ? update_curr+0xfc/0x190
[ 258.400336] [<ffffffff81466e5c>] _raw_spin_lock+0x2c/0x40
[ 258.400336] [<ffffffff8103adfc>] ? update_curr+0xfc/0x190
[ 258.400336] [<ffffffff8103adfc>] update_curr+0xfc/0x190
[ 258.400336] [<ffffffff8103b22d>] task_tick_fair+0x2d/0x140
[ 258.400336] [<ffffffff81041b0f>] scheduler_tick+0xcf/0x280
[ 258.400336] [<ffffffff8105a439>] update_process_times+0x69/0x80
[ 258.400336] [<ffffffff8108e0cf>] tick_sched_timer+0x5f/0xc0
[ 258.400336] [<ffffffff81071339>] __run_hrtimer+0x79/0x1f0
[ 258.400336] [<ffffffff8108e070>] ? tick_nohz_handler+0x100/0x100
[ 258.400336] [<ffffffff81071ce3>] hrtimer_interrupt+0xf3/0x220
[ 258.400336] [<ffffffff8101daa4>] smp_apic_timer_interrupt+0x64/0xa0
[ 258.400336] [<ffffffff8146f9d3>] apic_timer_interrupt+0x13/0x20
[ 258.400336] <EOI> [<ffffffff814674e0>] ? _raw_spin_unlock_irq+0x30/0x40
[ 258.400336] [<ffffffff8107092d>] update_rlimit_cpu+0x4d/0x60
[ 258.400336] [<ffffffff81062c0e>] do_prlimit+0x19e/0x240
[ 258.400336] [<ffffffff81063008>] sys_setrlimit+0x48/0x60
[ 258.400336] [<ffffffff8146efbb>] system_call_fastpath+0x16/0x1b
^ permalink raw reply
* Re: [PATCH] make the sample pre-commit hook script reject names with newlines, too
From: Andreas Schwab @ 2011-10-22 17:35 UTC (permalink / raw)
To: Jim Meyering; +Cc: git list
In-Reply-To: <87obx9eygk.fsf@rho.meyering.net>
Jim Meyering <jim@meyering.net> writes:
> @@ -26,7 +29,7 @@ if [ "$allownonascii" != "true" ] &&
> # even required, for portability to Solaris 10's /usr/bin/tr), since
> # the square bracket bytes happen to fall in the designated range.
> test "$(git diff --cached --name-only --diff-filter=A -z $against |
> - LC_ALL=C tr -d '[ -~]\0')"
> + LC_ALL=C tr -d '[ -~]\0' | wc -c)" != 0
This will fail if the output of wc contains leading spaces.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH 1/4] nl80211: Add probe response offload attribute
From: Johannes Berg @ 2011-10-22 17:39 UTC (permalink / raw)
To: Guy Eilam; +Cc: linux-wireless
In-Reply-To: <CAA038468Y7T4BSAycqmNc0q+Ph1wSh07B57tV--O00kvDEp-wg@mail.gmail.com>
On Sat, 2011-10-22 at 19:26 +0200, Guy Eilam wrote:
> >> > +enum nl80211_probe_resp_offload_support_attr {
> >> > + NL80211_PROBE_RESP_OFFLOAD_SUPPORT_WPS,
> >> > + NL80211_PROBE_RESP_OFFLOAD_SUPPORT_WPS2,
> >> > + NL80211_PROBE_RESP_OFFLOAD_SUPPORT_P2P,
> >> > +};
> >>
> >> I think doing = 1<<N here would be nicer to use in drivers & userspace.
> >
> > Hm, also: should we call this WPS or WSC, and do we need to distinguish
> > WPS and WPS2? My AP mode patch called it WSC in a different context but
> > I can change, we just should be consistent.
> >
> >> > + * @get_probe_resp_offload: Get probe response offload support from driver.
> >>
> >> and this seems unnecessary -- why not just put a u32 value into struct
> >> wiphy?
> >
> > Oh, and probably a regular WIPHY flag that indicates whether the
> > attribute should be added at all so that it can also be 0 but present
> > (presence with 0 value indicates something other than not present).
>
> When this is not supported a -EOPNOTSUPP should be returned.
> A 0 return means that it is supported.
Yeah but if you add a wiphy flag and the bits into struct wiphy, then
you can save the function pointer which seems nicer?
johannes
^ permalink raw reply
* Re: [PATCH 1/4] nl80211: Add probe response offload attribute
From: Guy Eilam @ 2011-10-22 17:42 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1319305186.3956.11.camel@jlt3.sipsolutions.net>
On Sat, Oct 22, 2011 at 7:39 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Sat, 2011-10-22 at 19:26 +0200, Guy Eilam wrote:
>
>> >> > +enum nl80211_probe_resp_offload_support_attr {
>> >> > + NL80211_PROBE_RESP_OFFLOAD_SUPPORT_WPS,
>> >> > + NL80211_PROBE_RESP_OFFLOAD_SUPPORT_WPS2,
>> >> > + NL80211_PROBE_RESP_OFFLOAD_SUPPORT_P2P,
>> >> > +};
>> >>
>> >> I think doing = 1<<N here would be nicer to use in drivers & userspace.
>> >
>> > Hm, also: should we call this WPS or WSC, and do we need to distinguish
>> > WPS and WPS2? My AP mode patch called it WSC in a different context but
>> > I can change, we just should be consistent.
>> >
>> >> > + * @get_probe_resp_offload: Get probe response offload support from driver.
>> >>
>> >> and this seems unnecessary -- why not just put a u32 value into struct
>> >> wiphy?
>> >
>> > Oh, and probably a regular WIPHY flag that indicates whether the
>> > attribute should be added at all so that it can also be 0 but present
>> > (presence with 0 value indicates something other than not present).
>>
>> When this is not supported a -EOPNOTSUPP should be returned.
>> A 0 return means that it is supported.
>
> Yeah but if you add a wiphy flag and the bits into struct wiphy, then
> you can save the function pointer which seems nicer?
You're absolutely right.
I'll send another version of the patch that will have a flag and
bitmap in the wiphy struct.
>
> johannes
>
>
Guy.
^ permalink raw reply
* [PATCH] drivers: create a pin control subsystem v8
From: Mike Frysinger @ 2011-10-22 17:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111004203520.GK2870@ponder.secretlab.ca>
On Tue, Oct 4, 2011 at 16:35, Grant Likely wrote:
> On Sat, Oct 01, 2011 at 12:39:21PM +0200, Linus Walleij wrote:
>> 2011/9/30 Grant Likely:
>> >?I'm not convinced that the sysfs approach is
>> > actually the right interface here (I'm certainly not a fan of the gpio
>> > sysfs i/f), and I'd rather not be putting in unneeded stuff until the
>> > userspace i/f is hammered out.
>>
>> Actually, thinking about it I cannot see what would be wrong
>> with /dev/gpio0 & friends in the first place.
>>
>> Using sysfs as swiss army knife for custom I/O does not
>> seem like it would be long-term viable so thanks for this
>> observation, and I think we need /dev/gpio* put on some
>> mental roadmap somewhere.
>
> Agreed. ?I don't want to be in the situation we are now with GPIO,
> where every time I look at the sysfs interface I shudder.
the problem with that is it doesn't scale. if i have a device with
over 150 GPIOs on the SoC itself (obviously GPIO expanders can make
that much bigger), i don't want to see 150+ device nodes in /dev/.
that's a pretty big waste. sysfs only allocates/frees resources when
userspace actually wants to utilize a GPIO.
-mike
^ permalink raw reply
* Re: [PATCH 1/4] nl80211: Add probe response offload attribute
From: Johannes Berg @ 2011-10-22 17:44 UTC (permalink / raw)
To: Guy Eilam; +Cc: linux-wireless
In-Reply-To: <CAA03845twSZjJHN-MygjLvK8VsQk+_S6qNqdM7JgZA9GS9LPWQ@mail.gmail.com>
On Sat, 2011-10-22 at 19:42 +0200, Guy Eilam wrote:
> > Yeah but if you add a wiphy flag and the bits into struct wiphy, then
> > you can save the function pointer which seems nicer?
>
> You're absolutely right.
> I'll send another version of the patch that will have a flag and
> bitmap in the wiphy struct.
Also I believe that means you don't need patch 2 at all so that's kinda
nice :-)
johannes
^ permalink raw reply
* Re: [PATCH] drivers: create a pin control subsystem v8
From: Mike Frysinger @ 2011-10-22 17:44 UTC (permalink / raw)
To: Grant Likely
Cc: Linus Walleij, Stephen Warren, Sascha Hauer, Barry Song,
linux-kernel, Joe Perches, Russell King, Linaro Dev, Lee Jones,
David Brown, linux-arm-kernel, Stijn Devriendt
In-Reply-To: <20111004203520.GK2870@ponder.secretlab.ca>
On Tue, Oct 4, 2011 at 16:35, Grant Likely wrote:
> On Sat, Oct 01, 2011 at 12:39:21PM +0200, Linus Walleij wrote:
>> 2011/9/30 Grant Likely:
>> > I'm not convinced that the sysfs approach is
>> > actually the right interface here (I'm certainly not a fan of the gpio
>> > sysfs i/f), and I'd rather not be putting in unneeded stuff until the
>> > userspace i/f is hammered out.
>>
>> Actually, thinking about it I cannot see what would be wrong
>> with /dev/gpio0 & friends in the first place.
>>
>> Using sysfs as swiss army knife for custom I/O does not
>> seem like it would be long-term viable so thanks for this
>> observation, and I think we need /dev/gpio* put on some
>> mental roadmap somewhere.
>
> Agreed. I don't want to be in the situation we are now with GPIO,
> where every time I look at the sysfs interface I shudder.
the problem with that is it doesn't scale. if i have a device with
over 150 GPIOs on the SoC itself (obviously GPIO expanders can make
that much bigger), i don't want to see 150+ device nodes in /dev/.
that's a pretty big waste. sysfs only allocates/frees resources when
userspace actually wants to utilize a GPIO.
-mike
^ permalink raw reply
* Re: [PATCH] make the sample pre-commit hook script reject names with newlines, too
From: Jim Meyering @ 2011-10-22 17:44 UTC (permalink / raw)
To: Andreas Schwab; +Cc: git list
In-Reply-To: <m262jhoro1.fsf@igel.home>
Andreas Schwab wrote:
> Jim Meyering <jim@meyering.net> writes:
>
>> @@ -26,7 +29,7 @@ if [ "$allownonascii" != "true" ] &&
>> # even required, for portability to Solaris 10's /usr/bin/tr), since
>> # the square bracket bytes happen to fall in the designated range.
>> test "$(git diff --cached --name-only --diff-filter=A -z $against |
>> - LC_ALL=C tr -d '[ -~]\0')"
>> + LC_ALL=C tr -d '[ -~]\0' | wc -c)" != 0
>
> This will fail if the output of wc contains leading spaces.
Good point. Thanks. That's a portability bug.
GNU wc outputs no leading spaces, but others certainly do.
Removing the double quotes fixes that:
-- >8 --
Subject: [PATCH] make the sample pre-commit hook script reject names with
newlines, too
The sample pre-commit hook script would fail to reject a file name
like "a\nb" because of the way newlines are handled in "$(...)".
Adjust the test to count filtered bytes and require there be 0.
Also print all diagnostics to standard error, not stdout, so they
will actually be seen.
Signed-off-by: Jim Meyering <meyering@redhat.com>
---
templates/hooks--pre-commit.sample | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/templates/hooks--pre-commit.sample b/templates/hooks--pre-commit.sample
index b187c4b..18c4829 100755
--- a/templates/hooks--pre-commit.sample
+++ b/templates/hooks--pre-commit.sample
@@ -18,6 +18,9 @@ fi
# If you want to allow non-ascii filenames set this variable to true.
allownonascii=$(git config hooks.allownonascii)
+# Redirect output to stderr.
+exec 1>&2
+
# Cross platform projects tend to avoid non-ascii filenames; prevent
# them from being added to the repository. We exploit the fact that the
# printable range starts at the space character and ends with tilde.
@@ -25,8 +28,8 @@ if [ "$allownonascii" != "true" ] &&
# Note that the use of brackets around a tr range is ok here, (it's
# even required, for portability to Solaris 10's /usr/bin/tr), since
# the square bracket bytes happen to fall in the designated range.
- test "$(git diff --cached --name-only --diff-filter=A -z $against |
- LC_ALL=C tr -d '[ -~]\0')"
+ test $(git diff --cached --name-only --diff-filter=A -z $against |
+ LC_ALL=C tr -d '[ -~]\0' | wc -c) != 0
then
echo "Error: Attempt to add a non-ascii file name."
echo
@@ -43,4 +46,5 @@ then
exit 1
fi
+# If there are whitespace errors, print the offending file names and fail.
exec git diff-index --check --cached $against --
--
1.7.7.419.g87009
^ permalink raw reply related
* Re: [PATCH] squashfs-tools: add recipe (2nd try)
From: Cliff Brake @ 2011-10-22 17:42 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <4EA19B3E.2020302@intel.com>
On Fri, Oct 21, 2011 at 12:18 PM, Saul Wold <saul.wold@intel.com> wrote:
> This one is on hold pending an update from Cliff based on Khem's comments.
v3 posted. Thanks for all the feedback.
Cliff
^ permalink raw reply
* Re: [Xenomai-core] Usage of Xenomai name
From: Philippe Gerum @ 2011-10-22 17:54 UTC (permalink / raw)
To: Jorge Amado Azevedo; +Cc: xenomai
In-Reply-To: <CAADnnhW-NzAxC5sRTv1WS64KOTe_ywAr8Ko7U-TzviTuVBijEA@mail.gmail.com>
On Mon, 2011-10-17 at 11:15 +0100, Jorge Amado Azevedo wrote:
> Hello
>
>
> I'm currently finishing a small application that allows users to draw
> block diagrams of control systems and execute them in real-time using
> Xenomai. Technically, each block is a Xenomai task and users can
> easily make their own as long as they adhere to a specific interface.
> I'm a student at the university of Aveiro (Portugal) and this work is
> part of my master's thesis. My original idea was to call my
> application "Xenomai Lab" but I'm not sure if I can use the Xenomai
> name like that.
>
>
> Am I violating any trademarks, copyrights or other legal restrictions
> by using the Xenomai name for my application?
There would be no objection from the Xenomai project, provided this is
and remains LGPL/GPL software.
>
> Regards,
> Jorge Azevedo
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
--
Philippe.
^ permalink raw reply
* Re: [PATCH 7/5] pretty: %G[?GS] placeholders
From: Junio C Hamano @ 2011-10-22 17:55 UTC (permalink / raw)
To: Elia Pinto; +Cc: git
In-Reply-To: <CA+EOSB=EowzV5B9jjq9D9rshPt8LmO9K_GbwNWo_x3Uv9+kwxg@mail.gmail.com>
Elia Pinto <gitter.spiros@gmail.com> writes:
> Can you suggest what do you think can be useful placeholders ? Thanks.
That is a weird question.
> 2011/10/22, Junio C Hamano <gitster@pobox.com>:
>> Add new placeholders related to the GPG signature on signed commits.
>>
>> - %GG to show the raw verification message from GPG;
>> - %G? to show either "G" for Good, "B" for Bad;
>> - %GS to show the name of the signer.
>>
>> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>> ---
>> * The 6th is the one that works with a bogus commit with NUL in it I sent
>> out previously.
>>
>> This concludes the series; I'll leave the design and implementation of
>> other useful placeholders to the list for now.
I can think of random other placeholders off the top of my head purely by
speculation without having real need [*1*], but they won't be much useful.
People on the list who *want* to use this feature in their projects may
have specific needs and they would be closer to what is needed in the real
world use cases than what comes out of thin air by imagination.
That is the reason why I left the enhancement to the list.
If you have to ask that question because you do not have any specific need
yourself, and especially if you have to ask it to *me*, then you should
wait for others to come up with their real needs, just like what I am
doing right now ;-).
[Footnote]
*1*
- %GC that is replaced with COLOR_GREEN when Good signature is found,
COLOR_RED when BAD signature is found, and COLOR_RESET when there is no
signature;
- %GD for the date the signature was made on (with date format variants);
- %Gk for the type of the key and the Key-ID.
^ permalink raw reply
* Re: Use of _hint() functions and older machines
From: Colin Guthrie @ 2011-10-22 18:04 UTC (permalink / raw)
To: Randell Jesup; +Cc: ALSA Development Mailing List
In-Reply-To: <4EA0E6E5.1050600@jesup.org>
'Twas brillig, and Randell Jesup at 21/10/11 04:28 did gyre and gimble:
> [ I initially posted this to the -users list, but it may be more
> appropriate here ]
>
> At Mozilla, we're in the process of adding support for WebRTC
> (http://webrtc.org/), which is being standardized by the IETF (their
> part is 'rtcweb'), and the W3C. This adds real-time audio and video
> (and data) communication to browsers, peer-to-peer over encrypted channels.
>
> We have a sound library that can load either Pulse or Alsa. However,
> for Alsa, it wants to look at snd_device_name_hint() and also
> _get_hint() and _free_hint(). It lazy-binds to libasound, so it will
> dlopen() it and then dlsym() all the symbols it uses; if any fail it
> unloads the lib and says it's not there. It uses the hint functions to
> build a device list, for example for presenting to the user.
>
> I have two problems:
>
> 1) Firefox is build on machines configured with I believe Centos5, and
> I'm told the machines run Alsa 1.0.12, while the hints() functions were
> added in 1.0.14 (released June 2007). Right now I can't build release
> or 'try' builds on the build servers because of this.
Are you sure? CentOS 5 is fairly new and on a box I have access to:
[csuk@shake ~]$ cat /etc/redhat-release
CentOS release 5.5 (Final)
[csuk@shake ~]$ rpm -q alsa-lib
alsa-lib-1.0.17-1.el5
So I guess it's likely CentOS 4? Even still updating alsa-lib to 1.0.14
should be pretty trivial and safe. Or do you not have any control at all
over the version used?
> 2) We'd like to run on older machines if possible, and official release
> builds are made on those servers. On older machines, _hint() aren't
> available, so even if I make them optional to dlsym-loading, I would
> need some other method to get the information I assume using older,
> now-deprecated-or-gone interfaces.
Not sure, but I suspect strongly that you should simply not worry about
this too much. While it's nice to give a good experience to everyone,
people with systems 4 years old have got to expect a degree of
degradation over a more recent install.
My €0.02
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply
* [PATCH] kbuild: fix warnings by specifing format arguments
From: Peter Foley @ 2011-10-22 17:19 UTC (permalink / raw)
To: Linux Kernel Mailing List, Linux Kbuild Mailing List, mmarek
Specify format arguments to fix warnings.
HOSTCC scripts/kconfig/gconf.o
/usr/src/lto/scripts/kconfig/gconf.c: In function 'on_introduction1_activate':
/usr/src/lto/scripts/kconfig/gconf.c:686:6: warning: format not a string literal and no format arguments
/usr/src/lto/scripts/kconfig/gconf.c: In function 'on_about1_activate':
/usr/src/lto/scripts/kconfig/gconf.c:704:6: warning: format not a string literal and no format arguments
/usr/src/lto/scripts/kconfig/gconf.c: In function 'on_license1_activate':
/usr/src/lto/scripts/kconfig/gconf.c:723:6: warning: format not a string literal and no format arguments
Signed-off-by: Peter Foley <pefoley2@verizon.net>
---
scripts/kconfig/gconf.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/scripts/kconfig/gconf.c b/scripts/kconfig/gconf.c
index 9f44380..b9e26a5 100644
--- a/scripts/kconfig/gconf.c
+++ b/scripts/kconfig/gconf.c
@@ -683,7 +683,7 @@ void on_introduction1_activate(GtkMenuItem * menuitem, gpointer user_data)
dialog = gtk_message_dialog_new(GTK_WINDOW(main_wnd),
GTK_DIALOG_DESTROY_WITH_PARENT,
GTK_MESSAGE_INFO,
- GTK_BUTTONS_CLOSE, intro_text);
+ GTK_BUTTONS_CLOSE, "%s", intro_text);
g_signal_connect_swapped(GTK_OBJECT(dialog), "response",
G_CALLBACK(gtk_widget_destroy),
GTK_OBJECT(dialog));
@@ -701,7 +701,7 @@ void on_about1_activate(GtkMenuItem * menuitem, gpointer user_data)
dialog = gtk_message_dialog_new(GTK_WINDOW(main_wnd),
GTK_DIALOG_DESTROY_WITH_PARENT,
GTK_MESSAGE_INFO,
- GTK_BUTTONS_CLOSE, about_text);
+ GTK_BUTTONS_CLOSE, "%s", about_text);
g_signal_connect_swapped(GTK_OBJECT(dialog), "response",
G_CALLBACK(gtk_widget_destroy),
GTK_OBJECT(dialog));
@@ -720,7 +720,7 @@ void on_license1_activate(GtkMenuItem * menuitem, gpointer user_data)
dialog = gtk_message_dialog_new(GTK_WINDOW(main_wnd),
GTK_DIALOG_DESTROY_WITH_PARENT,
GTK_MESSAGE_INFO,
- GTK_BUTTONS_CLOSE, license_text);
+ GTK_BUTTONS_CLOSE, "%s", license_text);
g_signal_connect_swapped(GTK_OBJECT(dialog), "response",
G_CALLBACK(gtk_widget_destroy),
GTK_OBJECT(dialog));
--
1.7.7
^ permalink raw reply related
* cifs file copy performance much faster - more results
From: Steve French @ 2011-10-22 18:25 UTC (permalink / raw)
To: linux-cifs-u79uwXL29TY76Z2rM5mHXA, samba-technical, linux-fsdevel,
LKML
Did some quick tests to Samba 3.6 from the current cifs git tree which
includes Jeff's async read performance improvements. About a 4x
performance increase on GiGE, maxing the network adapter (slightly
slower writing to local disk file).
/* As expected, running earlier cifs (3.0 kernel), the network
utilization on single large file copy is 20-25% over GigE */
[stevef@smfhomegateway ~]$ dd of=/dev/zero
if=/mnt/target-file-1GB-size bs=8M count=125
^C85+0 records in
84+0 records out
704643072 bytes (705 MB) copied, 29.5827 s, 23.8 MB/s
/* try it again to make sure it is not a fluke - current cifs suffers
from synchronous
dispatch of read in single file copy case and also small read sizes */
[stevef@smfhomegateway ~]$ dd of=/dev/null
if=/mnt/target-file-1GB-size bs=8M count=125
125+0 records in
125+0 records out
1048576000 bytes (1.0 GB) copied, 43.4298 s, 24.1 MB/s
/* Load the current cifs-2.6.git module - backported to 2.6.40-FC */
[stevef@smfhomegateway ~]$ dd of=/dev/null
if=/mnt/target-file-1GB-size bs=8M count=125
125+0 records in
125+0 records out
1048576000 bytes (1.0 GB) copied, 9.06156 s, 116 MB/s
/* Writing to local file on this low end SATA drive instead of
dev/null slows things down a little but still close to wire speed
[stevef@smfhomegateway ~]$ dd of=foo if=/mnt/target-file-1GB-size
bs=8M count=125
125+0 records in
125+0 records out
1048576000 bytes (1.0 GB) copied, 11.4381 s, 91.7 MB/s
--
Thanks,
Steve
^ permalink raw reply
* cifs file copy performance much faster - more results
From: Steve French @ 2011-10-22 18:25 UTC (permalink / raw)
To: linux-cifs, samba-technical, linux-fsdevel, LKML
Did some quick tests to Samba 3.6 from the current cifs git tree which
includes Jeff's async read performance improvements. About a 4x
performance increase on GiGE, maxing the network adapter (slightly
slower writing to local disk file).
/* As expected, running earlier cifs (3.0 kernel), the network
utilization on single large file copy is 20-25% over GigE */
[stevef@smfhomegateway ~]$ dd of=/dev/zero
if=/mnt/target-file-1GB-size bs=8M count=125
^C85+0 records in
84+0 records out
704643072 bytes (705 MB) copied, 29.5827 s, 23.8 MB/s
/* try it again to make sure it is not a fluke - current cifs suffers
from synchronous
dispatch of read in single file copy case and also small read sizes */
[stevef@smfhomegateway ~]$ dd of=/dev/null
if=/mnt/target-file-1GB-size bs=8M count=125
125+0 records in
125+0 records out
1048576000 bytes (1.0 GB) copied, 43.4298 s, 24.1 MB/s
/* Load the current cifs-2.6.git module - backported to 2.6.40-FC */
[stevef@smfhomegateway ~]$ dd of=/dev/null
if=/mnt/target-file-1GB-size bs=8M count=125
125+0 records in
125+0 records out
1048576000 bytes (1.0 GB) copied, 9.06156 s, 116 MB/s
/* Writing to local file on this low end SATA drive instead of
dev/null slows things down a little but still close to wire speed
[stevef@smfhomegateway ~]$ dd of=foo if=/mnt/target-file-1GB-size
bs=8M count=125
125+0 records in
125+0 records out
1048576000 bytes (1.0 GB) copied, 11.4381 s, 91.7 MB/s
--
Thanks,
Steve
^ permalink raw reply
* Re: [PATCH 1/2] LSM: Do not apply mmap_min_addr check to PROT_NONE mappings
From: Linus Torvalds @ 2011-10-22 18:32 UTC (permalink / raw)
To: Roland McGrath
Cc: Andrew Morton, James Morris, Eric Paris, Stephen Smalley, selinux,
John Johansen, linux-security-module, linux-kernel
In-Reply-To: <20111022172450.0BCCE2C0A9@topped-with-meat.com>
On Sat, Oct 22, 2011 at 8:24 PM, Roland McGrath <roland@hack.frob.com> wrote:
>
> It's exactly the case that I did mention: an application's own attempt to
> ensure robustness by doing a PROT_NONE mmap of the [0,0x10000) region. An
> application cannot presume that this region is already precluded from being
> used by any non-MAP_FIXED mmap across all systems and configurations, so
> it's defensive coding to explicitly block it off with a PROT_NONE mapping.
Quite frankly, I don't think that's an interesting case.
The app can try to be robust by doing the mmap(PROT_NONE), but if that
fails, then the app should just let it go.
Why should the kernel make its own security more complex (and thus fragile)?
So I think that it's perfectly ok for some user-level app to do
mmap(NULL, 64k, PROT_NONE, MAP_FIXED|MAP_ANON, -1, 0);
to try to create a PROT_NONE mapping at NULL, but then just ignore the
error if that fails. That way the app can handle the case of "maybe
the system is set up to allow NULL mappings, so I'll harden it
myself".
But that's no reason for the kernel to *allow* the mapping.
And if the app actually *fails* due to the mmap failing, then the app
is just buggy and stupid. So again, there's no reason for the kernel
to allow it.
IOW, either the app is fine with the kernel not letting it do a
PROT_NONE mapping, or the app is so braindamaged as to not be worth
worrying about. In neither case do I actually see any reason to apply
your patch.
So I was looking for some *other* reason for the patch.
Because, quite frankly, "security hardening" is absolutely *not* a
reason to do it - complex security is not "hardened", it's just
"harder and more likely to be buggy".
Linus
^ permalink raw reply
* Re: [PATCH 1/2] LSM: Do not apply mmap_min_addr check to PROT_NONE mappings
From: Linus Torvalds @ 2011-10-22 18:41 UTC (permalink / raw)
To: Roland McGrath
Cc: Andrew Morton, James Morris, Eric Paris, Stephen Smalley, selinux,
John Johansen, linux-security-module, linux-kernel
In-Reply-To: <CA+55aFx_9D8jY2sqcZ+Tm305W9d8o+ZhEv8XNWuN4--S2bqRwQ@mail.gmail.com>
On Sat, Oct 22, 2011 at 9:32 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> So I was looking for some *other* reason for the patch.
>
> Because, quite frankly, "security hardening" is absolutely *not* a
> reason to do it - complex security is not "hardened", it's just
> "harder and more likely to be buggy".
Btw, if the only concern is "you don't want to elevate the selinux
denial to be some user-visible thing", then I'd suggest attacking
*that* issue directly.
For example, maybe we could fail the PROT_NONE mmap (ie not actually
create any mapping at all, and certainly not create anything that is
then mprotectable), but return success and not elevate it to be
reported.
But then it really is important to return success, because otherwise
it would be a "silent probe" of the security model (ie a bad user
could use the mmap(PROT_NONE) to see if min_mmap_addr is on or not
without triggering any selinux warnings).
And unlike your patch, it wouldn't open up some new interface
(mprotect) to worry about.
So I think it might be valid to say "always allow mmap(PROT_NONE)
under mmap_min_limit, by simply turning it into a no-op".
Linus
^ permalink raw reply
* Re: CRT not detected via hotplug on resume
From: Rainer Dorsch @ 2011-10-22 18:41 UTC (permalink / raw)
To: Keith Packard; +Cc: intel-gfx
In-Reply-To: <yunaa9uo6do.fsf@aiko.keithp.com>
Keith,
sorry for the late reply, but it took until now until the problem came back.
My problem was that with my G35 (GMA X3500)
00:02.0 VGA compatible controller: Intel Corporation 82G35 Express Integrated
Graphics Controller (rev 03) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. Device 8276
Flags: bus master, fast devsel, latency 0, IRQ 44
Memory at fe800000 (32-bit, non-prefetchable) [size=1M]
Memory at d0000000 (64-bit, prefetchable) [size=256M]
I/O ports at cc00 [size=8]
Expansion ROM at <unassigned> [disabled]
Capabilities: <access denied>
Kernel driver in use: i915
SDVO did not come up after resume in rare cases, i.e. the screen stays black
(machine is fine, login via ssh is no problem at all):
http://lists.freedesktop.org/archives/intel-gfx/2011-September/012132.html
Now I got a register dump from a clean resume:
http://bokomoko.de/~rd/GMA3500-black-screen/intel_reg_dump-20111022-working-
screen.dump
and a not working resume
http://bokomoko.de/~rd/GMA3500-black-screen/intel_reg_dump-20111022-black-
screen.dump
Here is the diff of the register dumps, a few registers are different:
blackbox:~# diff -u intel_reg_dump-20111022-working-screen.dump
intel_reg_dump-20111022-black-screen.dump
--- intel_reg_dump-20111022-working-screen.dump 2011-10-22 18:17:31.740634880
+0200
+++ intel_reg_dump-20111022-black-screen.dump 2011-10-22 18:14:10.651270448
+0200
@@ -1,4 +1,4 @@
- DCC: 0x00100008 ( �y�d����cz�T�����v�H���d�{�)
+ DCC: 0x00100008 ( �|�t����}�d���z�X��d�~�)
CHDECMISC: 0x000000ac (XOR bank/rank, ch2 enh disabled, ch1 enh
enabled, ch0 enh enabled, flex disabled, ep not present)
C0DRB0: 0x00100008 (0x0008)
C0DRB1: 0x00180010 (0x0010)
@@ -51,18 +51,18 @@
DSPAPOS: 0x00000000 (0, 0)
DSPASIZE: 0x00000000 (1, 1)
DSPABASE: 0x00000000
- DSPASURF: 0x0144c000
+ DSPASURF: 0x0e4eb000
DSPATILEOFF: 0x00000000
PIPEACONF: 0xc0000000 (enabled, active)
PIPEASRC: 0x04ff03ff (1280, 1024)
- PIPEASTAT: 0x00000307 (status: VSYNC_INT_STATUS
DLINE_COMPARE_STATUS SVBLANK_INT_STATUS VBLANK_INT_STATUS OREG_UPDATE_STATUS)
+ PIPEASTAT: 0x00040203 (status: SVBLANK_INT_ENABLE VSYNC_INT_STATUS
VBLANK_INT_STATUS OREG_UPDATE_STATUS)
PIPEA_GMCH_DATA_M: 0x00000000
PIPEA_GMCH_DATA_N: 0x00000000
PIPEA_DP_LINK_M: 0x00000000
PIPEA_DP_LINK_N: 0x00000000
CURSOR_A_BASE: 0x01950000
CURSOR_A_CONTROL: 0x04000027
- CURSOR_A_POSITION: 0x0267800b
+ CURSOR_A_POSITION: 0x024b0182
FPA0: 0x00020e08 (n = 2, m1 = 14, m2 = 8)
FPA1: 0x00020e08 (n = 2, m1 = 14, m2 = 8)
DPLL_A: 0xd4020c00 (enabled, dvo, default clock, DAC/serial
mode, p1 = 2, p2 = 10)
@@ -150,7 +150,7 @@
FBC_CONTROL2: 0xffffffff
FBC_FENCE_OFF: 0xffffffff
FBC_MOD_NUM: 0xffffffff
- MI_MODE: 0x00000240
+ MI_MODE: 0x00000040
MI_ARB_STATE: 0x00000044
MI_RDRET_STATE: 0x00000000
ECOSKPD: 0x00000307
@@ -195,36 +195,36 @@
FENCE 5: 0x00000000 (disabled)
FENCE 6: 0x00000000 (disabled)
FENCE 7: 0x00000000 (disabled)
- FENCE 8: 0x085f809d (disabled)
- FENCE 9: 0x08af7000 (disabled)
- FENCE 10: 0x0ae6409d (disabled)
- FENCE 11: 0x0b363000 (disabled)
- FENCE 12: 0x0e4eb09d (disabled)
- FENCE 13: 0x0e9ea000 (disabled)
- FENCE 14: 0x04f5d09d (disabled)
- FENCE 15: 0x04f84000 (disabled)
- FENCE START 0: 0x085f809d ( enabled, X tile walk, 5120 pitch,
0x085f8000 start)
- FENCE END 0: 0x08af7000 (
0x08af7000 end)
- FENCE START 1: 0x0ae6409d ( enabled, X tile walk, 5120 pitch,
0x0ae64000 start)
- FENCE END 1: 0x0b363000 (
0x0b363000 end)
- FENCE START 2: 0x0e4eb09d ( enabled, X tile walk, 5120 pitch,
0x0e4eb000 start)
- FENCE END 2: 0x0e9ea000 (
0x0e9ea000 end)
- FENCE START 3: 0x04f5d09d ( enabled, X tile walk, 5120 pitch,
0x04f5d000 start)
- FENCE END 3: 0x04f84000 (
0x04f84000 end)
- FENCE START 4: 0x07ddb06d ( enabled, X tile walk, 3584 pitch,
0x07ddb000 start)
- FENCE END 4: 0x080da000 (
0x080da000 end)
- FENCE START 5: 0x048f109d ( enabled, X tile walk, 5120 pitch,
0x048f1000 start)
- FENCE END 5: 0x04918000 (
0x04918000 end)
- FENCE START 6: 0x0d39e09d ( enabled, X tile walk, 5120 pitch,
0x0d39e000 start)
- FENCE END 6: 0x0d89d000 (
0x0d89d000 end)
- FENCE START 7: 0x0144c09d ( enabled, X tile walk, 5120 pitch,
0x0144c000 start)
- FENCE END 7: 0x0194b000 (
0x0194b000 end)
- FENCE START 8: 0x0491d09d ( enabled, X tile walk, 5120 pitch,
0x0491d000 start)
- FENCE END 8: 0x04944000 (
0x04944000 end)
- FENCE START 9: 0x00000000 (disabled, X tile walk, 128 pitch,
0x00000000 start)
- FENCE END 9: 0x00000000 (
0x00000000 end)
- FENCE START 10: 0x00000000 (disabled, X tile walk, 128 pitch,
0x00000000 start)
- FENCE END 10: 0x00000000 (
0x00000000 end)
+ FENCE 8: 0x0144c09d (disabled)
+ FENCE 9: 0x0194b000 (disabled)
+ FENCE 10: 0x0e4eb09d (disabled)
+ FENCE 11: 0x0e9ea000 (disabled)
+ FENCE 12: 0x086e909d (disabled)
+ FENCE 13: 0x08be8000 (disabled)
+ FENCE 14: 0x064ab09d (disabled)
+ FENCE 15: 0x069aa000 (disabled)
+ FENCE START 0: 0x0144c09d ( enabled, X tile walk, 5120 pitch,
0x0144c000 start)
+ FENCE END 0: 0x0194b000 (
0x0194b000 end)
+ FENCE START 1: 0x0e4eb09d ( enabled, X tile walk, 5120 pitch,
0x0e4eb000 start)
+ FENCE END 1: 0x0e9ea000 (
0x0e9ea000 end)
+ FENCE START 2: 0x086e909d ( enabled, X tile walk, 5120 pitch,
0x086e9000 start)
+ FENCE END 2: 0x08be8000 (
0x08be8000 end)
+ FENCE START 3: 0x064ab09d ( enabled, X tile walk, 5120 pitch,
0x064ab000 start)
+ FENCE END 3: 0x069aa000 (
0x069aa000 end)
+ FENCE START 4: 0x0d39e09d ( enabled, X tile walk, 5120 pitch,
0x0d39e000 start)
+ FENCE END 4: 0x0d89d000 (
0x0d89d000 end)
+ FENCE START 5: 0x04f5d09d ( enabled, X tile walk, 5120 pitch,
0x04f5d000 start)
+ FENCE END 5: 0x04f84000 (
0x04f84000 end)
+ FENCE START 6: 0x048f109d ( enabled, X tile walk, 5120 pitch,
0x048f1000 start)
+ FENCE END 6: 0x04918000 (
0x04918000 end)
+ FENCE START 7: 0x0491d09d ( enabled, X tile walk, 5120 pitch,
0x0491d000 start)
+ FENCE END 7: 0x04944000 (
0x04944000 end)
+ FENCE START 8: 0x0dc8300d ( enabled, X tile walk, 512 pitch,
0x0dc83000 start)
+ FENCE END 8: 0x0dc85000 (
0x0dc85000 end)
+ FENCE START 9: 0x0dc1e00d ( enabled, X tile walk, 512 pitch,
0x0dc1e000 start)
+ FENCE END 9: 0x0dc20000 (
0x0dc20000 end)
+ FENCE START 10: 0x0dc2101d ( enabled, X tile walk, 1024 pitch,
0x0dc21000 start)
+ FENCE END 10: 0x0dc26000 (
0x0dc26000 end)
FENCE START 11: 0x00000000 (disabled, X tile walk, 128 pitch,
0x00000000 start)
FENCE END 11: 0x00000000 (
0x00000000 end)
FENCE START 12: 0x00000000 (disabled, X tile walk, 128 pitch,
0x00000000 start)
blackbox:~#
(when I suspend the machine after the not working resume again, it usually
comes up nicely after that resume).
Is there anything unexpected in the register dumps?
Many thanks,
Rainer
Am Saturday, 24. September 2011 schrieb Keith Packard:
> On Fri, 23 Sep 2011 21:05:37 +0200, Rainer Dorsch <ml@bokomoko.de> wrote:
> > Are there any other data I could gather to figure out what is going
> > wrong?
>
> Oh, have we gotten register dumps from a working vs non-working resume?
>
> git://anongit.freedesktop.org/git/xorg/app/intel-gpu-tools
>
> Let's hope there's some difference...
--
Rainer Dorsch
http://bokomoko.de/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: Does NFS4 need st_gen?
From: Boaz Harrosh @ 2011-10-22 18:47 UTC (permalink / raw)
To: Nikolaus Rath; +Cc: Trond Myklebust, linux-nfs
In-Reply-To: <4EA1AF6D.60603@rath.org>
On 10/21/2011 10:44 AM, Nikolaus Rath wrote:
> Yes, with 64bit inodes everything would be fine. But fuse uses 'long'
> for inodes, so on 32bit systems you only have 32bit inodes even if ino_t
> is 64bit.
With out knowing any of the details, what kind of brain dead thing is
putting "long" in an API. What do you do with 32bit user-mode on 64bit
Kernel.
32 bits for inode numbers is a broken system for 15 years already.
Fix the broken FUSE that falsely calls itself File-System and
stop bitching about NFS. It's FUSE you should be hacking and fixing.
Realy
Boaz
^ permalink raw reply
* Re: [Qemu-devel] [QEMU : VVFAT] vvfat.c - help required for understanding/modification
From: Johannes Schindelin @ 2011-10-22 18:58 UTC (permalink / raw)
To: Pintu Kumar; +Cc: Kevin Wolf, qemu-devel
In-Reply-To: <CAOuPNLgZp+YgFAL+=WTyJhZz=HfSEp-pCZ6DN1E4Sw04iRP9yw@mail.gmail.com>
Hi Pintu,
On Sat, 22 Oct 2011, Pintu Kumar wrote:
> I already did some work for scanning only top level directory in vvfat.
> Using the following logic in read_directory()
>
> if(parent_index >= 0 & (!dot & !dotdot))
> {
> free(buffer);
> break;
> }
Sorry, this is way too deep in the code (and I'd have to guess because you
did not grace me with exact locations), I cannot afford to dive into it
that far. But what I can say is that it is not all that easy; you'll need
to refactor the code.
You _will_ need to reserve sectors for future directory parsing. You
_will_ need to add code that intercepts reads to those sectors. You _will_
have to read the directories in question when those sectors are accessed
and thereby commit the sectors to a final state.
BTW both Kevin and I said that before.
> Hope this is correct logic for skipping sub-directories content by just
> scanning only dot and dotdot entries inside it.
It would be, if all you want are empty directories.
> But as per the recent analysis it was observed that there is some
> problem in skipping sub-directory scanning itself. Because when I issue
> "df" command on VVFAT partition I get read_cluster errors during these
> sector location.
When you issue "df", you need to commit to which sectors are reserved. By
that, you take almost all the advantage of lazy directory parsing away.
> Mr. Johannes, can you clarify on this first.
>
> Then we will look into the dynamic mapping part later.
I am very sorry, but I do get the impression that the intent is to lure me
into doing all the work, including the investigation what it would take to
turn the code into a version that reads just the top-level first and only
later the subdirectories.
This will not happen. I have enough projects that I want to tackle myself,
and I am extremely unwilling to do the work for somebody else when that
somebody else is paid to do the work. For the things I _want_ to do I
already have too little time, given that my day job is quite demanding and
asks software design and architecture of me already.
So: you _will_ have to acquaint yourself with the FAT and then the VFAT
specification. You _will_ have to make a proper plan how the client may be
fooled into believing that there is a fixed filesystem when there is
actually just directories of files. And you _will_ have to write that code
yourself.
I hope this clarified it?
Ciao,
Johannes
^ permalink raw reply
* Re: [PATCH 3/6] revert: fix buffer overflow in insn sheet parser
From: Ramkumar Ramachandra @ 2011-10-22 18:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, Git List, Christian Couder
In-Reply-To: <7vaa8va3xm.fsf@alter.siamese.dyndns.org>
Hi Junio and Jonathan,
Thanks for the good suggestions. Will post the next iteration in a
few minutes (some tests running now).
Junio C Hamano writes:
> [...]
> When the log message justifies the cause and the approach in the right
> way, the actual patch becomes self evident. Also I often find myself
> coming up with a _better_ solution than the patch I originally prepared
> while writing the commit log message to explain it, and redoing the patch
> text to match the description.
Wow. It looks like I have a long way to go :/
Maybe I should practice writing more Haskell.
-- Ram
^ permalink raw reply
* Re: Does NFS4 need st_gen?
From: Boaz Harrosh @ 2011-10-22 18:59 UTC (permalink / raw)
To: Nikolaus Rath; +Cc: Trond Myklebust, linux-nfs
In-Reply-To: <4EA30FC7.7080600@panasas.com>
On 10/22/2011 11:47 AM, Boaz Harrosh wrote:
> On 10/21/2011 10:44 AM, Nikolaus Rath wrote:
>> Yes, with 64bit inodes everything would be fine. But fuse uses 'long'
>> for inodes, so on 32bit systems you only have 32bit inodes even if ino_t
>> is 64bit.
>
> With out knowing any of the details, what kind of brain dead thing is
> putting "long" in an API. What do you do with 32bit user-mode on 64bit
> Kernel.
>
API => ABI
> 32 bits for inode numbers is a broken system for 15 years already.
> Fix the broken FUSE that falsely calls itself File-System and
> stop bitching about NFS. It's FUSE you should be hacking and fixing.
>
> Realy
> Boaz
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Compat-wireless release for 2011-10-22 is baked
From: Compat-wireless cronjob account @ 2011-10-22 19:03 UTC (permalink / raw)
To: linux-wireless
compat-wireless code metrics
814119 - Total upstream lines of code being pulled
2431 - backport code changes
2113 - backport code additions
318 - backport code deletions
8588 - backport from compat module
11019 - total backport code
1.3535 - % of code consists of backport work
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.