On 18.11.20 14:19, Jan Beulich wrote:
On 09.11.2020 17:38, Juergen Gross wrote:
Currently the lock for a single event channel needs to be taken with
interrupts off, which causes deadlocks in some cases.
Rework the per event channel lock to be non-blocking for the case of
sending an event and re
Hi Julien,
finally I could try out what you suggested, please find my answers inline.
> -Ursprüngliche Nachricht-
> Von: Julien Grall
> Gesendet: Mittwoch, 18. November 2020 13:24
> An: Stefano Stabellini ; Leo Krueger
>
> Cc: Peng Fan ; bru...@xilinx.com; Cornelia Bruelhart
> ; oleksan
On 22.11.20 22:44, Andy Lutomirski wrote:
On Sat, Nov 21, 2020 at 10:55 PM Jürgen Groß wrote:
On 20.11.20 12:59, Peter Zijlstra wrote:
On Fri, Nov 20, 2020 at 12:46:23PM +0100, Juergen Gross wrote:
+static __always_inline void arch_local_irq_restore(unsigned long flags)
+{
+if (!arch_irq
flight 156948 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156948/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
On Mon, 2020-11-23 at 09:33 +1100, Finn Thain wrote:
> On Sun, 22 Nov 2020, Joe Perches wrote:
> > But provably correct conversions IMO _should_ be done and IMO churn
> > considerations should generally have less importance.
[]
> Moreover, the patch review workload for skilled humans is being gen
flight 156945 qemu-mainline real [real]
flight 156952 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/156945/
http://logs.test-lab.xenproject.org/osstest/logs/156952/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On Mon, 2020-11-23 at 09:54 +1100, Finn Thain wrote:
> But is anyone keeping score of the regressions? If unreported bugs
> count, what about unreported regressions?
Well, I was curious about the former (obviously no tool will tell me
about the latter), so I asked git what patches had a fall-throu
On Sun, 22 Nov 2020, Miguel Ojeda wrote:
>
> It isn't that much effort, isn't it? Plus we need to take into account
> the future mistakes that it might prevent, too.
We should also take into account optimisim about future improvements in
tooling.
> So even if there were zero problems found
On Sun, 2020-11-22 at 21:35 +0100, Miguel Ojeda wrote:
> On Sun, Nov 22, 2020 at 7:22 PM James Bottomley
> wrote:
> > Well, it's a problem in an error leg, sure, but it's not a really
> > compelling reason for a 141 patch series, is it? All that fixing
> > this error will do is get the driver to
On Sun, 22 Nov 2020, Joe Perches wrote:
> On Sun, 2020-11-22 at 08:49 -0800, James Bottomley wrote:
> > We can enforce sysfs_emit going forwards
> > using tools like checkpatch
>
> It's not really possible for checkpatch to find or warn about
> sysfs uses of sprintf. checkpatch is really just a
Hi James.
> > > If none of the 140 patches here fix a real bug, and there is no
> > > change to machine code then it sounds to me like a W=2 kind of a
> > > warning.
> >
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6q
On Sat, Nov 21, 2020 at 10:55 PM Jürgen Groß wrote:
>
> On 20.11.20 12:59, Peter Zijlstra wrote:
> > On Fri, Nov 20, 2020 at 12:46:23PM +0100, Juergen Gross wrote:
> >> +static __always_inline void arch_local_irq_restore(unsigned long flags)
> >> +{
> >> +if (!arch_irqs_disabled_flags(flags))
On Sun, Nov 22, 2020 at 7:22 PM James Bottomley
wrote:
>
> Well, it's a problem in an error leg, sure, but it's not a really
> compelling reason for a 141 patch series, is it? All that fixing this
> error will do is get the driver to print "oh dear there's a problem"
> under four more conditions
On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > Please tell me our reward for all this effort isn't a s
flight 156942 linux-5.4 real [real]
flight 156949 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/156942/
http://logs.test-lab.xenproject.org/osstest/logs/156949/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd6
On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > Please tell me our reward for all this effort isn't a single
> > > missing error print.
> >
> > There were quite lit
On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > Please tell me our reward for all this effort isn't a single
> > missing error print.
>
> There were quite literally dozens of logical defects found
> by the fallthrough additions.
On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> Please tell me
> our reward for all this effort isn't a single missing error print.
There were quite literally dozens of logical defects found
by the fallthrough additions. Very few were logging only.
On Sun, 2020-11-22 at 08:49 -0800, James Bottomley wrote:
> We can enforce sysfs_emit going forwards
> using tools like checkpatch
It's not really possible for checkpatch to find or warn about
sysfs uses of sprintf. checkpatch is really just a trivial
line-by-line parser and it has no concept of c
On Sun, 2020-11-22 at 08:33 -0800, Tom Rix wrote:
> On 11/21/20 9:10 AM, Joe Perches wrote:
> > On Sat, 2020-11-21 at 08:50 -0800, t...@redhat.com wrote:
> > > A difficult part of automating commits is composing the subsystem
> > > preamble in the commit log. For the ongoing effort of a fixer prod
On Sun, 2020-11-22 at 08:17 -0800, Kees Cook wrote:
> On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R
flight 156937 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156937/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
On Sun, 2020-11-22 at 08:10 -0800, Tom Rix wrote:
> On 11/22/20 6:56 AM, Matthew Wilcox wrote:
> > On Sun, Nov 22, 2020 at 06:46:46AM -0800, Tom Rix wrote:
> > > On 11/21/20 7:23 PM, Matthew Wilcox wrote:
> > > > On Sat, Nov 21, 2020 at 08:50:58AM -0800, t...@redhat.com
> > > > wrote:
> > > > > The
On 11/21/20 9:10 AM, Joe Perches wrote:
> On Sat, 2020-11-21 at 08:50 -0800, t...@redhat.com wrote:
>> A difficult part of automating commits is composing the subsystem
>> preamble in the commit log. For the ongoing effort of a fixer producing
>> one or two fixes a release the use of 'treewide:'
On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
> > > > This series aims to fix almost all
On 11/22/20 6:56 AM, Matthew Wilcox wrote:
> On Sun, Nov 22, 2020 at 06:46:46AM -0800, Tom Rix wrote:
>> On 11/21/20 7:23 PM, Matthew Wilcox wrote:
>>> On Sat, Nov 21, 2020 at 08:50:58AM -0800, t...@redhat.com wrote:
The fixer review is
https://reviews.llvm.org/D91789
A run ov
On Sun, Nov 22, 2020 at 06:46:46AM -0800, Tom Rix wrote:
>
> On 11/21/20 7:23 PM, Matthew Wilcox wrote:
> > On Sat, Nov 21, 2020 at 08:50:58AM -0800, t...@redhat.com wrote:
> >> The fixer review is
> >> https://reviews.llvm.org/D91789
> >>
> >> A run over allyesconfig for x86_64 finds 62 issues, 5
On 11/21/20 7:23 PM, Matthew Wilcox wrote:
> On Sat, Nov 21, 2020 at 08:50:58AM -0800, t...@redhat.com wrote:
>> The fixer review is
>> https://reviews.llvm.org/D91789
>>
>> A run over allyesconfig for x86_64 finds 62 issues, 5 are false positives.
>> The false positives are caused by macros pass
flight 156935 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156935/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 156918
test-amd64-amd64-xl-qemuu-win7-amd64
flight 156934 qemu-mainline real [real]
flight 156944 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/156934/
http://logs.test-lab.xenproject.org/osstest/logs/156944/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
flight 156941 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156941/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen b659a5cebd611dbe698e63c03485b5fe8cd964ad
baseline version:
xen 5505
31 matches
Mail list logo
