* Martin Sebor wrote:
> > I.e. the real workaround might be to turn off the
> > -Wstringop-overread-warning,
> > until GCC-11 gets fixed?
>
> In GCC 10 -Wstringop-overread is a subset of -Wstringop-overflow.
> GCC 11 breaks it out as a separate warning to make it easier to
> control. Both wa
* Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> gcc-11 warns about using string operations on pointers that are
> defined at compile time as offsets from a NULL pointer. Unfortunately
> that also happens on the result of fix_to_virt(), which is a
> compile-time constant for a constantn input
* Sebastian Andrzej Siewior wrote:
> From: Mike Galbraith
>
> send_msg() disables preemption to avoid out-of-order messages. As the
> code inside the preempt disabled section acquires regular spinlocks,
> which are converted to 'sleeping' spinlocks on a PREEMPT_RT kernel and
> eventually call
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> Please consider pulling, more to come as I go thru Adrian's x86
> PTI series and the C++ support improvements to 'perf probe', from
> Holger,
>
> Best Regards,
>
> - Arnaldo
>
> Test results at the end of this message, as usual.
>
> T
* Sebastian Andrzej Siewior wrote:
> On 2018-05-04 20:51:32 [+0200], Peter Zijlstra wrote:
> > On Fri, May 04, 2018 at 08:45:39PM +0200, Sebastian Andrzej Siewior wrote:
> > > On 2018-05-04 20:32:49 [+0200], Peter Zijlstra wrote:
> > > > On Fri, May 04, 2018 at 07:51:44PM +0200, Sebastian Andrze
* Linus Torvalds wrote:
> On Mon, Apr 2, 2018 at 12:04 PM, Dominik Brodowski
> wrote:
> >
> > This patchset removes all in-kernel calls to syscall functions in the
> > kernel with the exception of arch/.
>
> Ok, this finished off my arch updates for today, I'll probably move on
> to driver pul
* Pavel Machek wrote:
> > > > Yeah, so generic memcpy() replacement is only feasible I think if the
> > > > most
> > > > optimistic implementation is actually correct:
> > > >
> > > > - if no preempt disable()/enable() is required
> > > >
> > > > - if direct access to the AVX[2] registers
* Andy Lutomirski wrote:
> On Wed, Mar 21, 2018 at 6:32 AM, Ingo Molnar wrote:
> >
> > * Linus Torvalds wrote:
> >
> >> And even if you ignore that "maintenance problems down the line" issue
> >> ("we can fix them when they happen") I
* Linus Torvalds wrote:
> And the real worry is things like AVX-512 etc, which is exactly when
> things like "save and restore one ymm register" will quite likely
> clear the upper bits of the zmm register.
Yeah, I think the only valid save/restore pattern is to 100% correctly
enumerate
the w
So I poked around a bit and I'm having second thoughts:
* Linus Torvalds wrote:
> On Tue, Mar 20, 2018 at 1:26 AM, Ingo Molnar wrote:
> >
> > So assuming the target driver will only load on modern FPUs I *think* it
> > should
> > actually be possible
* Linus Torvalds wrote:
> And even if you ignore that "maintenance problems down the line" issue
> ("we can fix them when they happen") I don't want to see games like
> this, because I'm pretty sure it breaks the optimized xsave by tagging
> the state as being dirty.
That's true - and it would
* Thomas Gleixner wrote:
> On Tue, 20 Mar 2018, Ingo Molnar wrote:
> > * Thomas Gleixner wrote:
> >
> > > > So I do think we could do more in this area to improve driver
> > > > performance, if the
> > > > code is correct and
* Thomas Gleixner wrote:
> > So I do think we could do more in this area to improve driver performance,
> > if the
> > code is correct and if there's actual benchmarks that are showing real
> > benefits.
>
> If it's about hotpath performance I'm all for it, but the use case here is
> a debug
* Thomas Gleixner wrote:
> > Useful also for code that needs AVX-like registers to do things like CRCs.
>
> x86/crypto/ has a lot of AVX optimized code.
Yeah, that's true, but the crypto code is processing fundamentally bigger
blocks
of data, which amortizes the cost of using kernel_fpu_begi
* Linus Torvalds wrote:
> So an error message like
>
>warning: ISO C90 requires array sizes to be constant-expressions
>
> would be technically correct and useful from a portability angle. It
> tells you when you're doing something non-portable, and should be
> automatically enabled with "
> header files).
>
> Signed-off-by: Randy Dunlap
Nice find:
Reviewed-by: Ingo Molnar
I agree that it needs to go through 0-day to find any hidden dependencies we
might
have grown due to this.
Thanks,
Ingo
* Alan Cox wrote:
> On Mon, 8 Jan 2018 11:08:36 +0100
> Peter Zijlstra wrote:
>
> > On Fri, Jan 05, 2018 at 10:30:16PM -0800, Dan Williams wrote:
> > > On Fri, Jan 5, 2018 at 6:22 PM, Eric W. Biederman
> > > wrote:
> > > > In at least one place (mpls) you are patching a fast path. Compile
* Peter Zijlstra wrote:
> On Sun, Jan 07, 2018 at 06:24:11PM -0800, Alexei Starovoitov wrote:
> > How about:
> > CONFIG_SPECTRE1_WORKAROUND_INDEX_MASK
> > CONFIG_SPECTRE1_WORKAROUND_LOAD_FENCE
>
> INSTRUCTION_FENCE if anything. LFENCE for Intel (and now also for AMD as
> per 0592b0bce169) is a
reakage.
>
> It's really that simple. That's what "no regressions" means. We don't
> accept changes that cause regressions. This one did.
Yeah, absolutely - for the revert:
Acked-by: Ingo Molnar
as I doubt we have enough time to root-case this properly.
Thanks,
Ingo
in the BPF_*() namespace then it should include and
not
a random asm/* header...
With that detail fixed:
Acked-by: Ingo Molnar
for the whole series.
Thanks,
Ingo
* Josef Bacik wrote:
> > > Then 'not crashing kernel' requirement will be preserved.
> > > btrfs or whatever else we will be testing with override_return
> > > will be functioning in 'stress test' mode and if bpf program
> > > is not careful and returns error all the time then one particular
> >
* Alexei Starovoitov wrote:
> > One of the major advantages of having an in-kernel BPF sandbox is to never
> > crash the kernel - and allowing BPF programs to just randomly modify the
> > return value of kernel functions sounds immensely broken to me.
> >
> > (And yes, I realize that kprobes
* David Miller wrote:
> From: Josef Bacik
> Date: Tue, 7 Nov 2017 15:28:41 -0500
>
> > I'm sending this through Dave since it'll conflict with other BPF changes
> > in his
> > tree, but since it touches tracing as well Dave would like a review from
> > somebody on the tracing side.
> ...
>
* Josef Bacik wrote:
> On Fri, Nov 10, 2017 at 10:34:59AM +0100, Ingo Molnar wrote:
> >
> > * Josef Bacik wrote:
> >
> > > @@ -551,6 +578,10 @@ static const struct bpf_func_proto
> > > *kprobe_prog_func_proto(enum bpf_func_id func
> > >
* Josef Bacik wrote:
> @@ -551,6 +578,10 @@ static const struct bpf_func_proto
> *kprobe_prog_func_proto(enum bpf_func_id func
> return &bpf_get_stackid_proto;
> case BPF_FUNC_perf_event_read_value:
> return &bpf_perf_event_read_value_proto;
> + case BPF_FU
* Peter Zijlstra wrote:
> On Wed, Nov 01, 2017 at 09:27:43AM +0100, Ingo Molnar wrote:
> >
> > * Peter Zijlstra wrote:
> >
> > > On Wed, Nov 01, 2017 at 06:15:54PM +1100, Stephen Rothwell wrote:
> > > > Hi all,
> > > >
> > &g
* Peter Zijlstra wrote:
> On Wed, Nov 01, 2017 at 06:15:54PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the tip tree got a conflict in:
> >
> > kernel/trace/bpf_trace.c
> >
> > between commits:
> >
> > 97562633bcba ("bpf: perf event change needed for s
* Paul E. McKenney wrote:
> On Sat, Jul 08, 2017 at 10:35:43AM +0200, Ingo Molnar wrote:
> >
> > * Manfred Spraul wrote:
> >
> > > Hi Ingo,
> > >
> > > On 07/07/2017 10:31 AM, Ingo Molnar wrote:
> > > >
>
* Paul E. McKenney wrote:
> On Fri, Jul 07, 2017 at 10:31:28AM +0200, Ingo Molnar wrote:
>
> [ . . . ]
>
> > In fact I'd argue that any future high performance spin_unlock_wait() user
> > is
> > probably better off open coding the unlock-wait poll loop (a
* Manfred Spraul wrote:
> Hi Ingo,
>
> On 07/07/2017 10:31 AM, Ingo Molnar wrote:
> >
> > There's another, probably just as significant advantage:
> > queued_spin_unlock_wait()
> > is 'read-only', while spin_lock()+spin_unlock() dirties the loc
* Peter Zijlstra wrote:
> You missed the one in do_exit(), which I thought was the original one.
Indeed, it's raw_spin_unlock_wait() which my git grep pattern missed.
But it's not the original spin_unlock_wait(): the pi_lock and priority
inheritance
is a newfangled invention that Linus (righ
* Ingo Molnar wrote:
>
> * Peter Zijlstra wrote:
>
> > > It might even be that this is the defined semantics of spin_unlock_wait().
> >
> > As is, spin_unlock_wait() is somewhat ill defined. IIRC it grew from an
> > optimization by Oleg and subsequently
* Peter Zijlstra wrote:
> On Thu, Jul 06, 2017 at 09:20:24AM -0700, Paul E. McKenney wrote:
> > On Thu, Jul 06, 2017 at 06:05:55PM +0200, Peter Zijlstra wrote:
> > > On Thu, Jul 06, 2017 at 02:12:24PM +, David Laight wrote:
> > > > From: Paul E. McKenney
> >
> > [ . . . ]
> >
> > > Now on
* Peter Zijlstra wrote:
> > It might even be that this is the defined semantics of spin_unlock_wait().
>
> As is, spin_unlock_wait() is somewhat ill defined. IIRC it grew from an
> optimization by Oleg and subsequently got used elsewhere. And it being the
> subtle bugger it is, there were bug
* Jiri Slaby wrote:
> On 04/24/2017, 05:55 PM, Ingo Molnar wrote:
> > * Jiri Slaby wrote:
> >
> >> On 04/24/2017, 05:08 PM, David Miller wrote:
> >>> If you align the entry points, then the code sequence as a whole is
> >>> are no longer de
* Jiri Slaby wrote:
> On 04/24/2017, 05:08 PM, David Miller wrote:
> > If you align the entry points, then the code sequence as a whole is
> > are no longer densely packed.
>
> Sure.
>
> > Or do I misunderstand how your macros work?
>
> Perhaps. So the suggested macros for the code are:
> #de
* Masami Hiramatsu wrote:
> On Thu, 30 Mar 2017 08:53:32 +0200
> Ingo Molnar wrote:
>
> >
> > * Masami Hiramatsu wrote:
> >
> > > > So this is something I missed while the original code was merged, but
> > > > the concept
> > >
* Masami Hiramatsu wrote:
> > So this is something I missed while the original code was merged, but the
> > concept
> > looks a bit weird: why do we do any "allocation" while a handler is
> > executing?
> >
> > That's fundamentally fragile. What's the maximum number of parallel
> > 'kretpro
* Masami Hiramatsu wrote:
> @@ -1824,6 +1823,30 @@ void unregister_jprobes(struct jprobe **jps, int num)
> EXPORT_SYMBOL_GPL(unregister_jprobes);
>
> #ifdef CONFIG_KRETPROBES
> +
> +/* Try to use free instance first, if failed, try to allocate new instance */
> +struct kretprobe_instance *kr
* Stephen Rothwell wrote:
> Hi all,
>
> After merging the net tree, today's linux-next build (powerpc64le perf)
> failed like this:
>
> Warning: tools/include/uapi/linux/bpf.h differs from kernel
> bpf.c: In function 'bpf_prog_attach':
> bpf.c:180:6: error: 'union bpf_attr' has no member named
* Stephen Rothwell wrote:
> --- a/tools/include/uapi/linux/bpf.h
> +++ b/tools/include/uapi/linux/bpf.h
> @@ -116,6 +116,12 @@ enum bpf_attach_type {
>
> #define MAX_BPF_ATTACH_TYPE __MAX_BPF_ATTACH_TYPE
>
> +/* If BPF_F_ALLOW_OVERRIDE flag is used in BPF_PROG_ATTACH command
> + * to the gi
essage about tweaking the kernel.perf_event_paranoid setting,
> telling how to make the change permanent by editing /etc/sysctl.conf
> (Ingo Molnar)
>
> Infrastructure:
>
> - Introduce linux/compiler-gcc.h as a counterpart to the kernel's,
> initially containing the defin
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> Please consider pulling, I had most of this queued before your first
> pull req to Linus for 4.10, most are fixes, with 'perf sched timehist --idle'
> as a followup new feature to the 'perf sched timehist' command introduced in
> this win
* Daniel Borkmann wrote:
> On 09/08/2016 09:01 AM, Ingo Molnar wrote:
> >* Peter Zijlstra wrote:
> >>On Thu, Sep 08, 2016 at 08:30:52AM +0200, Ingo Molnar wrote:
> >>>>Thanks for the fix. Just saw build bot complaining last night and
> >>>>
* Peter Zijlstra wrote:
> On Thu, Sep 08, 2016 at 08:30:52AM +0200, Ingo Molnar wrote:
> > > Thanks for the fix. Just saw build bot complaining last night and
> > > by the morning your fix is already here. Thanks!
> >
> > Guys, this is the first time I saw t
* Alexei Starovoitov wrote:
> On Tue, Sep 06, 2016 at 03:10:22PM +0200, Arnd Bergmann wrote:
> > The newly added bpf_overflow_handler function is only built of both
> > CONFIG_EVENT_TRACING and CONFIG_BPF_SYSCALL are enabled, but the caller
> > only checks the latter:
> >
> > kernel/events/core
* Marcel Holtmann wrote:
> Hi Andy,
>
> > SMP does ECB crypto on stack buffers. This is complicated and
> > fragile, and it will not work if the stack is virtually allocated.
> >
> > Switch to the crypto_cipher interface, which is simpler and safer.
> >
> > Cc: Marcel Holtmann
> > Cc: Gusta
* Sedat Dilek wrote:
> Hi,
>
> as Linux v4.6 is very near, I decided to write this bug report (only
> drunk one coffee).
>
> First, I am not absolutely sure if this is a real issue as...
> #1: This is only a (lockdep) warning.
> #2: I have not a "vanilla" Linux v4.6-rc7+ here (see P.S. and att
* Michael S. Tsirkin wrote:
> On Fri, Aug 22, 2014 at 09:36:53AM +0200, Ingo Molnar wrote:
> >
> > > > diff --git a/include/net/busy_poll.h b/include/net/busy_poll.h
> > > > index 1d67fb6..8a33fb2 100644
> > > > --- a/include/net/busy
* Josh Poimboeuf wrote:
> This is v17 of the compile-time stack metadata validation patch set.
>
> It's based on tip:x86/debug. However, note that when run against that
> branch it will give a lot of warnings:
>
> objtool: arch/x86/ia32/sys_ia32.o: __ex_table size not a multiple of 12
> o
* Josh Poimboeuf wrote:
> Hi Ingo,
>
> On Tue, Feb 23, 2016 at 09:14:06AM +0100, Ingo Molnar wrote:
> > So I tried out this latest stacktool series and it looks mostly good for an
> > upstream merge.
> >
> > To help this effort move forward I've applied
So I tried out this latest stacktool series and it looks mostly good for an
upstream merge.
To help this effort move forward I've applied the preparatory/fix patches that
are
part of this series to tip:x86/debug - that's 26 out of 31 patches. (I've
propagated all the acks that the latest subm
* Tom Herbert wrote:
> Thanks for the explanation and sample code. Expanding on your example, I
> added a
> switch statement to perform to function (code below).
So I think your new switch() based testcase is broken in a subtle way.
The problem is that in your added testcase GCC effectively o
* Tom Herbert wrote:
> [] gcc turns these switch statements into jump tables (not function
> tables
> which is what Ingo's example code was using). [...]
So to the extent this still matters, on most x86 microarchitectures that count,
jump tables and function call tables (i.e. virtual fun
* Ingo Molnar wrote:
> s/!CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
>
> > +
> > + /* Check length */
> > +10:cmpl$8, %esi
> > + jg 30f
> > + jl 20f
> > +
> > + /* Exactly 8 bytes length */
> > + addl(%r
* Tom Herbert wrote:
> Implement assembly routine for csum_partial for 64 bit x86. This
> primarily speeds up checksum calculation for smaller lengths such as
> those that are present when doing skb_postpull_rcsum when getting
> CHECKSUM_COMPLETE from device or after CHECKSUM_UNNECESSARY
> conve
* Alexei Starovoitov wrote:
> > > I could be missing something. I think either this patch is not need or
> > > you
> > > need to teach the tool to ignore all JITed stuff. I don't think it's
> > > practical to annotate everything. Different JITs do their own magic. s390
> > > JIT is even more
* Linus Torvalds wrote:
> Does anybody have any particular other "uhhuh, overflow in multiplication"
> issues in mind? Because the interface for a saturating multiplication (or
> addition, for that matter) would actually be much easier. And would be
> trivial
> to have as an inline asm for c
* Alexei Starovoitov wrote:
> On 10/23/15 5:03 AM, Peter Zijlstra wrote:
> >So the bpf_perf_event_read() returns the count value, does this not also
> >mean that returning -EINVAL here is also 'wrong'?
> >
> >I mean, sure an actual count value that high is unlikely, but its still
> >a broken int
* Alexei Starovoitov wrote:
> exported perf symbols are GPL only, mark eBPF helper functions
> used in tracing as GPL only as well.
>
> Suggested-by: Peter Zijlstra
> Signed-off-by: Alexei Starovoitov
> ---
> this is on top of this patch that touches the same file:
> http://patchwork.ozlabs.o
* Wangnan (F) wrote:
>
>
> On 2015/10/22 0:57, Peter Zijlstra wrote:
> >On Wed, Oct 21, 2015 at 11:06:47PM +0800, pi3orama wrote:
> >>>So explain; how does this eBPF stuff work.
> >>I think I get your point this time, and let me explain the eBPF stuff to
> >>you.
> >>
> >>You are aware that B
* Alexei Starovoitov wrote:
> As far as sysctl we can look at two with similar purpose:
> sysctl_perf_event_paranoid and modules_disabled.
> First one is indeed multi level, but not because of the fear of bugs,
> but because of real security implications.
It serves both purposes flexibly, and n
* Andy Lutomirski wrote:
> On Tue, Oct 6, 2015 at 10:56 AM, Eric Dumazet wrote:
> > On Tue, 2015-10-06 at 10:50 -0700, Alexei Starovoitov wrote:
> >
> >> was also thinking that we can do it only in paths that actually
> >> have multiple protocol layers, since today bpf is mainly used with
> >>
* Daniel Borkmann wrote:
> On 10/06/2015 09:13 AM, Ingo Molnar wrote:
> >
> >* Alexei Starovoitov wrote:
> >
> >>On 10/5/15 3:14 PM, Daniel Borkmann wrote:
> >>>One scenario that comes to mind ... what happens when there are kernel
> >>>
* Alexei Starovoitov wrote:
> On 10/5/15 3:14 PM, Daniel Borkmann wrote:
> >One scenario that comes to mind ... what happens when there are kernel
> >pointers stored in skb->cb[] (either from the current layer or an old
> >one from a different layer that the skb went through previously, but
> >w
* Andy Lutomirski wrote:
> On Fri, Sep 11, 2015 at 3:14 AM, Arnd Bergmann wrote:
> > On Friday 11 September 2015 11:54:50 Geert Uytterhoeven wrote:
> >> To make sure I don't miss any (it seems I missed recvmmsg and sendmmsg for
> >> the socketcall case, sigh), this is the list of ipc syscalls t
ly different problem. You are just refusing to explain how
> all
> that stuff is supposed to work and what kind of functionality you need
> exactly.
Yeah, so I'm just going to NAK this until things are improved:
NAKed-by: Ingo Molnar
it's not like we are overly bored
hide places where vmalloc() et al are added to files
> but the include of vmalloc.h is forgotten.
Good idea.
Acked-by: Ingo Molnar
> Based in Linus' tree of today.
>
> There are probably more places that need vmalloc.h included, but this passes
> 64
> bit and 32 bit al
* David Miller <[EMAIL PROTECTED]> wrote:
> From: Andrew Morton <[EMAIL PROTECTED]>
> Date: Sat, 16 Feb 2008 11:26:18 -0800
>
> > On Sat, 16 Feb 2008 13:03:54 +0100 Eric Dumazet <[EMAIL PROTECTED]> wrote:
> >
> > > Yes, per connection basis. Some workloads want to open/close more
> > > than 10
* Casey Schaufler <[EMAIL PROTECTED]> wrote:
> > So unlike some other security modules like SELINUX, enabling SMACK
> > breaks un-aware userspace and breaks TCP networking?
> >
> > I dont think that's expected behavior - and i'd definitely like to
> > enable SMACK in automated tests to check f
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> yeah, although various other upstream breakages prevented real long
> randconfig series in the past 2-3 days. I'd say it's either in this
> pull from your tree:
ok, i have bisected it down but the result made no sense, so
* David Miller <[EMAIL PROTECTED]> wrote:
> From: Ingo Molnar <[EMAIL PROTECTED]>
> Date: Wed, 6 Feb 2008 13:22:48 +0100
>
> > So no, it does not fix the problem. The config i sent is a rather
> > generic one, it should boot on most whitebox PCs. TCP connection
* David Miller <[EMAIL PROTECTED]> wrote:
> From: Ingo Molnar <[EMAIL PROTECTED]>
> Date: Wed, 6 Feb 2008 12:38:29 +0100
>
> >
> > randconfig qa on x86.git ran into the following new networking related
> > problem on latest -git: with the attached .conf
randconfig qa on x86.git ran into the following new networking related
problem on latest -git: with the attached .config the testbox comes up
but cannot establish any TCP connections due to -ENOPROTO in
sys_connect().
The error comes from this condition in inet_stream_connect():
/* Co
* Yinghai Lu <[EMAIL PROTECTED]> wrote:
> [PATCH] x86_32: fix regression caused by trim ram according to mtrr on system
> with 4G more RAM
>
> Pravel report:
> "
> The commit
>
> 093af8d7f0ba3c6be1485973508584ef081e9f93
> x86_32: trim memory by updating e820
>
> broke my e1000
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> My workstation running 2.6.24-rc8 just hung during shutdown with an
> endless (or rather I didn't wait more than a few minutes) loop of
>
> unregister_netdev: waiting for ppp-device to become free. Usage count
> = 1
>
> ppp-device was an active PPPoE
* FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> The patches are available at:
>
> http://www.kernel.org/pub/linux/kernel/people/tomo/iommu/
>
> Or if you prefer the git tree:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-misc.git
> iommu-sg-fixes
btw., these improvements to
* Andreas Mohr <[EMAIL PROTECTED]> wrote:
> (yes, that's all there is, despite CONFIG_USB_DEBUG being set)
>
> The LED of a usb stick isn't active either, for obvious reasons.
>
> And keep in mind that this is a (relatively old) OHCI-only machine...
> (which had the 2.6.19 lsmod showing ohci-h
* Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> kerneloops.org news:
>
> * As of 2.6.24-rc6, oopses have a unique identifier which makes it
> possible to filter out duplicate reports of (and replies to) the
> same oops. Unfortunately some reporters remove this line from their
> reports t
* Herbert Xu <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 19, 2007 at 12:31:52PM +0100, Ingo Molnar wrote:
> >
> > > So I'm wondering if it would be reasonable to make it out-of-line
> > > when TRACE_IRQFLAGS is off. This may make a difference because
> &g
* Herbert Xu <[EMAIL PROTECTED]> wrote:
> Hi Ingo:
>
> I noticed that local_bh_disable is now always out-of-line. The change
> was made when TRACE_IRQFLAGS was added. However, with TRACE_IRQFLAGS
> off, local_bh_disable does exactly the same work as before. In
> particular, it does pretty
* Herbert Xu <[EMAIL PROTECTED]> wrote:
> On Sat, Dec 15, 2007 at 07:43:28PM +0100, Ingo Molnar wrote:
> >
> > we could perhaps introduce stat_smp_processor_id(), which signals that
> > the CPU id is used for statistical purposes and does not have to be
> > exa
* Herbert Xu <[EMAIL PROTECTED]> wrote:
> Ob Tue, Dec 04, 2007 at 12:17:23AM +1100, Herbert Xu wrote:
> >
> > Never mind, we already have that in local_t and as Alexey correctly
> > points out, USER is still going to be the expensive variant with the
> > preempt_disable (well until BH gets threa
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> > I can't see this compile failure posted anywhere:
> > http://test.kernel.org/results/IBM/126049/build/debug/stderr
> >
> > arch/x86/vdso/vdso32/sigreturn.S: Assembler messages:
> > arch/x86/vdso/vdso32/sigreturn.S:23: Error: suffix or operands inval
* Herbert Xu <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 28, 2007 at 02:37:53PM +, David Howells wrote:
> > AF_RXRPC uses the crypto services, so should depend on or select CRYPTO.
> >
> > Signed-off-by: David Howells <[EMAIL PROTECTED]>
>
> Patch applied to net-2.6. Thanks.
aimed at 2.6.24
* Ulrich Drepper <[EMAIL PROTECTED]> wrote:
> > Oh, it seems it has indeed been that way for a very long time, so I
> > was mistaken. It still seems a little odd to me. Ulrich can say
> > definitively whether the kind of concern I mentioned really matters
> > one way or the other for glibc.
* Guillaume Chazarain <[EMAIL PROTECTED]> wrote:
> On 11/21/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > i guess it was a v2.6.24 change, hence a regression that needs to be
> > fixed?
>
> It seems to be
>
> http://git.kernel.org/?p=linux/kernel/git/t
* Roland McGrath <[EMAIL PROTECTED]> wrote:
> When did /proc/self get changed to follow tgid instead of pid? glibc
> uses /proc/self to refer to various things that are usually shared
> anyway (fd, maps, cwd, exe), but I think the expectation has always
> been that this refers to the same cal
that this is a regression
and that we need the patch below included in 2.6.24?
> Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
Acked-by: Ingo Molnar <[EMAIL PROTECTED]>
> ---
> fs/proc/base.c | 12 ++--
> 1 files changed, 6 insertions(+), 6 deletions(-)
>
these are all questions for Ulrich and Roland - Cc:-ed them.
* Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> Ingo Molnar <[EMAIL PROTECTED]> writes:
>
> > * Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> >
> >> > lr-x-- 1 root root 64 Nov 2
* Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> > lr-x-- 1 root root 64 Nov 20 18:03 3 -> /proc/net
> > ...
>
> Yes all of those are nasty. So much for my clever way of implementing
> these things. Grr. Simple hacks that almost work!
btw., in case you feel inclined, i recently did some
* Pavel Machek <[EMAIL PROTECTED]> wrote:
> On Tue 2007-11-13 12:50:08, Mark Lord wrote:
> > Ingo Molnar wrote:
> > >
> > >for example git-bisect was godsent. I remember that
> > >years ago bisection of a bug was a very laborous task
> >
* James Bottomley <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-11-14 at 11:56 -0800, David Miller wrote:
> > From: Ingo Molnar <[EMAIL PROTECTED]>
> > Date: Wed, 14 Nov 2007 15:08:47 +0100
> >
> > > In fact this thread is the very example: David points ou
* David Miller <[EMAIL PROTECTED]> wrote:
> From: Ingo Molnar <[EMAIL PROTECTED]>
> Date: Wed, 14 Nov 2007 15:08:47 +0100
>
> > In fact this thread is the very example: David points out that on netdev
> > some of those bugs were already discussed and resolved.
* Randy Dunlap <[EMAIL PROTECTED]> wrote:
> On Wed, 14 Nov 2007 21:16:39 +0100 Ingo Molnar wrote:
>
> > countered by the underlined sentences above, just in case you missed
> > it.
>
> I didn't miss your claim.
ok, then you conceded it by not replying
* Randy Dunlap <[EMAIL PROTECTED]> wrote:
> On Wed, 14 Nov 2007 15:08:47 +0100 Ingo Molnar wrote:
>
> >
> > * Randy Dunlap <[EMAIL PROTECTED]> wrote:
> >
> > > > (and this is in no way directed at the networking folks - it holds
> &
* Mark Lord <[EMAIL PROTECTED]> wrote:
>> You're assuming that everything in linux-2.6 was downloaded; that's
>> not true. Everything in linux-2.6/.git was downloaded; but then you
>> do a checkout which happens to approximately double the size of the
>> linux-2.6 directory.
> ..
>
> Ah, I wo
* Randy Dunlap <[EMAIL PROTECTED]> wrote:
> > (and this is in no way directed at the networking folks - it holds
> > for all of us. I have one main complaint about networking: the
> > separate netdev list is a bad idea - networking regressions should
> > be discussed and fixed on lkml, like mo
* Benoit Boissinot <[EMAIL PROTECTED]> wrote:
> For debugging, maybe it's time someone does an amazon ec2+s3 service
> to automate the bisecting and create .deb/.rpm from git, I don't know
> how much it would cost though.
a few months ago i estimated the costs of this and it's just a few
tera
* Mark Lord <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
> ..
>> This is all QA-101 that _cannot be argued against on a rational basis_,
>> it's just that these sorts of things have been largely ignored for years,
>> in favor of the all-too-easy "ope
1 - 100 of 208 matches
Mail list logo
