In some cases indentation looks a bit weird with starting from = sign
and being in a ladder-type style. Unify it across the module.
While at it, add blank line after definition block where it needed,
Signed-off-by: Andy Shevchenko
---
v2: fixed typo in the commit message (tupe->type)
drivers/ii
In some cases indentation looks a bit weird with starting from = sign
and being in a ladder-type style. Unify it across the module.
While at it, add blank line after definition block where it needed,
Signed-off-by: Andy Shevchenko
---
drivers/iio/industrialio-trigger.c | 25
ting some unrelated memory.
Maybe something's creating broken pointers and then writing there ?
Obviously my driver code shit, but those strange things happending
smells like some weird is going on deep inside the oftree code, that
maybe *could* provide an attack surface.
Does anyone have an
> On 26. Jun 2020, at 18:13, David Laight wrote:
>
> From: Xin Long
>> Sent: 23 June 2020 11:14
It looks like a bug to me. Testing with this test app here, I can see
the INIT_ACK being sent with a bunch of ipv4 addresses in it and
that's unexpected for a v6only socket. As is, it's
From: Xin Long
> Sent: 23 June 2020 11:14
> > > It looks like a bug to me. Testing with this test app here, I can see
> > > the INIT_ACK being sent with a bunch of ipv4 addresses in it and
> > > that's unexpected for a v6only socket. As is, it's the server saying
> > > "I'm available at these other
ght wrote:
>>>>>>> From: Marcelo Ricardo Leitner
>>>>>>>> Sent: 22 June 2020 19:33
>>>>>>>> On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote:
>>>>>>>>>> On 22. Jun 2020, at 18:57, Corey M
22 June 2020 19:33
> >>>>>> On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote:
> >>>>>>>> On 22. Jun 2020, at 18:57, Corey Minyard wrote:
> >>>>>>>>
> >>>>>>>> On Mon, Jun 22, 202
at 08:01:24PM +0200, Michael Tuexen wrote:
> > > > > >>> On 22. Jun 2020, at 18:57, Corey Minyard wrote:
> > > > > >>>
> > > > > >>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote:
> > > > > >>&g
t;>>>>>> On 22. Jun 2020, at 18:57, Corey Minyard wrote:
>>>>>>>>
>>>>>>>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote:
>>>>>>>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard
>>&
> >>>>>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote:
> >>>>>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>> I've stu
9:33
>>>> On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote:
>>>>>> On 22. Jun 2020, at 18:57, Corey Minyard wrote:
>>>>>>
>>>>>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote:
>>>>>>> On
; > > > On 22. Jun 2020, at 18:57, Corey Minyard wrote:
> > > > >
> > > > > On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote:
> > > > >> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard
> > > > >> wrote:
&
t;> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote:
>>>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote:
>>>>>>
>>>>>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an
>>>>>> sctp
; > > > On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote:
> > > >> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote:
> > > >>>
> > > >>> I've stumbled upon a strange problem with SCTP and IPv6. If I create
> > >
wrote:
> > > > >>>
> > > > >>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote:
> > > > >>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard
> > > > >>>> wrote:
> > > > >>&
g wrote:
> > > >>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard
> > > >>>> wrote:
> > > >>>>>
> > > >>>>> I've stumbled upon a strange problem with SCTP and IPv6. If I
> > > >>&g
ichael Tuexen wrote:
> > >>> On 22. Jun 2020, at 18:57, Corey Minyard wrote:
> > >>>
> > >>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote:
> > >>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote:
> > >>
t;> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote:
> > >>>
> > >>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an
> > >>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it,
> > >
t;>>
> >>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote:
> >>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote:
> >>>>>
> >>>>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an
> &
>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote:
>>>>>
>>>>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an
>>>>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it,
>>>&g
On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote:
> > On 22. Jun 2020, at 18:57, Corey Minyard wrote:
> >
> > On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote:
> >> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote:
> >>>
> >
> On 22. Jun 2020, at 18:57, Corey Minyard wrote:
>
> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote:
>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote:
>>>
>>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an
>&
On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote:
> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote:
> >
> > I've stumbled upon a strange problem with SCTP and IPv6. If I create an
> > sctp listening socket on :: and set the IPV6_V6ONLY socket optio
> On 22. Jun 2020, at 14:01, Xin Long wrote:
>
> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote:
>>
>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an
>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it,
&
On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote:
>
> I've stumbled upon a strange problem with SCTP and IPv6. If I create an
> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it,
> then I make a connection to it using ::1, the connection will drop af
I've stumbled upon a strange problem with SCTP and IPv6. If I create an
sctp listening socket on :: and set the IPV6_V6ONLY socket option on it,
then I make a connection to it using ::1, the connection will drop after
2.5 seconds with an ECONNRESET error.
It only happens on SCTP, it doesn&#
Hi Arnd,
You seem t have remerged a whole series of patches in your tree:
commits a55aa89aab90..ecc43067d9a5 are identical to commits
a55aa89aab90..846e9b109913 apart from the commit message for commit
e83dd16c24d8/654f7717ef51. And you have both sets fo commits merged.
--
Cheers,
Stephen Roth
On Fri, 28 Jun 2019 23:32:06 +0900 OGAWA Hirofumi
wrote:
>
> v2:
> Just cleanup, changed the place of options under comment of fat.
>
> ---
Please be careful with the "^---$" - it denotes "end of changelog", so
I ended up without a changelog!
> There
Christoph Hellwig writes:
> On Sat, Jun 29, 2019 at 12:03:46AM +0900, OGAWA Hirofumi wrote:
>> I see, sounds like good though. Does it work for all stable versions?
>> Can it disable only flush command without other effect? And it would be
>> better to be normal user controllable easily.
>
> The
On Sat, Jun 29, 2019 at 12:03:46AM +0900, OGAWA Hirofumi wrote:
> I see, sounds like good though. Does it work for all stable versions?
> Can it disable only flush command without other effect? And it would be
> better to be normal user controllable easily.
The option was added in 2.6.17, so it's
Christoph Hellwig writes:
> On Fri, Jun 28, 2019 at 11:18:19PM +0900, OGAWA Hirofumi wrote:
>> To workaround those devices and provide flexibility, this adds
>> "barrier"/"nobarrier" mount options to fat driver.
>
> We have deprecated these rather misnamed options, and now instead allow
> tweakin
v2:
Just cleanup, changed the place of options under comment of fat.
---
There was the report of strange behavior of device with recent
blkdev_issue_flush() position change.
The following is simplified usbmon trace.
4203 9.160230 host -> 1.25.1 USBMS 95 SCSI: Synchron
On Fri, Jun 28, 2019 at 11:18:19PM +0900, OGAWA Hirofumi wrote:
> To workaround those devices and provide flexibility, this adds
> "barrier"/"nobarrier" mount options to fat driver.
We have deprecated these rather misnamed options, and now instead allow
tweaking the 'cache_type' attribute on the S
There was the report of strange behavior of device with recent
blkdev_issue_flush() position change.
The following is simplified usbmon trace.
4203 9.160230 host -> 1.25.1 USBMS 95 SCSI: Synchronize
Cache(10) LUN: 0x00 (LBA: 0x, Len: 0)
4206 9.164911 1.2
On Wed, 12 Jun 2019, Rafael J. Wysocki wrote:
> > > hid-logitech-dj is not loaded after a fresh boot, so I need to modprobe
> > > it manually and that
> > > appears to be blocking (apparently indefinitely) until terminated with
> > > ^C. But then it turns
> > > out that hid-logitech-dj is there
On Wednesday, June 12, 2019 10:31:45 AM CEST Jiri Kosina wrote:
> On Wed, 12 Jun 2019, Rafael J. Wysocki wrote:
>
> > It kind of helps, but there is a catch.
> >
> > hid-logitech-dj is not loaded after a fresh boot, so I need to modprobe it
> > manually and that
> > appears to be blocking (appar
On Wed, 12 Jun 2019, Rafael J. Wysocki wrote:
> It kind of helps, but there is a catch.
>
> hid-logitech-dj is not loaded after a fresh boot, so I need to modprobe it
> manually and that
> appears to be blocking (apparently indefinitely) until terminated with ^C.
> But then it turns
> out that
On Wednesday, June 12, 2019 12:02:21 AM CEST Jiri Kosina wrote:
> On Tue, 11 Jun 2019, Rafael J. Wysocki wrote:
>
> > I noticed that the cordless mouse used by me with one of the machines here
> > stopped to work in 5.2-rc (up to and including the -rc4).
> >
> > Bisection turned up commit 74808f9
On Tue, 11 Jun 2019, Rafael J. Wysocki wrote:
> I noticed that the cordless mouse used by me with one of the machines here
> stopped to work in 5.2-rc (up to and including the -rc4).
>
> Bisection turned up commit 74808f9115ce ("HID: logitech-dj: add support for
> non
> unifying receivers").
>
On Sunday, June 9, 2019 5:46:48 AM CEST Linus Torvalds wrote:
> No, I'm not confused, and I haven't lost track of what day it is, I do
> actually know that it's still Saturday here, not Sunday, and I'm just
> doing rc4 a bit early because I'll be on an airplane during my normal
> release time. And
On Thu, 02 May 2019, Deepa Dinamani wrote:
Reported-by: Omar Kilani
Do we actually know if this was the issue Omar was hitting?
Thanks,
Davidlohr
Deepa Dinamani wrote:
> Eric,
> Can you please help test this?
Nope, that was _really_ badly whitespace-damaged.
(C'mon, it's not like you're new to this)
Eric,
Can you please help test this?
If this solves your problem, I can post the fix.
Thanks,
- Deepa
-8<---
Subject: [PATCH] signal: Adjust error codes according to restore_user_sigmask()
For all the syscalls that receive a sigmask from the userland,
the user sigmask is to be in eff
On Wed, May 1, 2019 at 1:48 PM Eric Wong wrote:
>
> Deepa Dinamani wrote:
> > So here is my analysis:
>
>
>
> > So the 854a6ed56839a40f6 seems to be better than the original code in
> > that it detects the signal.
>
> OTOH, does matter to anybody that a signal is detected slightly
> sooner than
Deepa Dinamani wrote:
> So here is my analysis:
> So the 854a6ed56839a40f6 seems to be better than the original code in
> that it detects the signal.
OTOH, does matter to anybody that a signal is detected slightly
sooner than it would've been, otherwise?
> But, the problem is that it doesn't
Thanks for trying the fix.
So here is my analysis:
Let's start with epoll_pwait:
ep_poll() is what checks for signal_pending() and is responsible for
setting errno to -EINTR when there is a signal.
So if a signal is received after ep_poll(), it is never noticed by the
syscall during execution.
Eric Wong wrote:
> (didn't test AIO, but everything else seems good)
"seems" != "is"
Now that I understand the fix for epoll, the fs/select.c changes
would hit the same problem and not return -EINTR when it should.
I'll let you guys decide how to fix this, but there's definitely
a problem when
Eric Wong wrote:
> Deepa Dinamani wrote:
> > I'm not sure what the hang in the userspace is about. Is it because
> > the syscall did not return an error or the particular signal was
> > blocked etc.
>
> Uh, ok; that's less comforting.
Nevermind, I think I understand everything, now. epoll_pwai
Deepa Dinamani wrote:
> I was also not able to reproduce this.
> Arnd and I were talking about this today morning. Here is something
> Arnd noticed:
>
> If there was a signal after do_epoll_wait(), we never were not
> entering the if (err = -EINTR) at all before.
I'm not sure which `if' statemen
I was also not able to reproduce this.
Arnd and I were talking about this today morning. Here is something
Arnd noticed:
If there was a signal after do_epoll_wait(), we never were not
entering the if (err = -EINTR) at all before. But, now we do.
We could try with the below patch:
diff --git a/fs/
Davidlohr Bueso wrote:
> On Sun, 28 Apr 2019, Eric Wong wrote:
>
> > Just running one test won't trigger since it needs a busy
> > machine; but:
> >
> > make test/mgmt_auto_adjust.log
> > (and "rm make test/mgmt_auto_adjust.log" if you want to rerun)
>
> fyi no luck reproducing on both
On Sun, 28 Apr 2019, Eric Wong wrote:
Just running one test won't trigger since it needs a busy
machine; but:
make test/mgmt_auto_adjust.log
(and "rm make test/mgmt_auto_adjust.log" if you want to rerun)
fyi no luck reproducing on both either a large (280) or small (4 cpu)
mac
ake test/mgmt_auto_adjust.log
(and "rm make test/mgmt_auto_adjust.log" if you want to rerun)
Thanks for looking into this. Fwiw, cmogstored uses epoll in
strange and uncommon ways which has led to kernel bugfixes
in the past.
I tried to replicate the failure on qemu.
I do not see the failure with N=32.
Does it work for N < 32?
Does any other signal work?
Are there any other architectures that fail?
Could you help me figure out how to run just the one test that is failing?
-Deepa
ilani wrote:
> > Basically, something’s broken (or at least, has changed enough to
> > cause problems in user space) in epoll since 5.0. It’s still broken in
> > 5.1-rc5.
> >
> > It doesn’t happen 100% of the time. It’s sort of hard to pin down but
> > I’v
doesn???t happen 100% of the time. It???s sort of hard to pin down but
I???ve observed the following:
* nginx not accepting connections under load
* A java app which uses netty / NIO having strange writability
semantics on channels, which confuses netty / java enough to not
properly flush written
rt of hard to pin down but
I???ve observed the following:
* nginx not accepting connections under load
* A java app which uses netty / NIO having strange writability
semantics on channels, which confuses netty / java enough to not
properly flush written data on the socket.
I went and tested these
x not accepting connections under load
> * A java app which uses netty / NIO having strange writability
> semantics on channels, which confuses netty / java enough to not
> properly flush written data on the socket.
>
> I went and tested these Linux kernels:
>
> 4.20.1
broken in
5.1-rc5.
It doesn’t happen 100% of the time. It’s sort of hard to pin down but
I’ve observed the following:
* nginx not accepting connections under load
* A java app which uses netty / NIO having strange writability
semantics on channels, which confuses netty / java enough to not
properly
l 4.9: strange behavior with fifo scheduler
Hi Frédéric,
On 2/5/19 11:47 AM, Frédéric Mathieu wrote:
Hi,
on an X86_64 architecture (Intel(R) Core(TM) i3-6100U CPU @ 2.30GHz),
I use the linux kernel 4.9.146 with patch rt 125.
uname -a: Linux 4.9.146-rt125 #1 SMP PREEMPT RT Tue Jan 29 14:17:55
CET 2019
x
.
-Message d'origine-
De : linux-kernel-ow...@vger.kernel.org
[mailto:linux-kernel-ow...@vger.kernel.org] De la part de Dietmar Eggemann
Envoyé : mercredi 6 février 2019 11:55
À : Frédéric Mathieu ; linux-kernel@vger.kernel.org
Objet : Re: Kernel 4.9: strange behavior with fifo scheduler
Hi Fré
strange behavior of the scheduler when several tasks are
executed in FIFO mode on a CPU core and a significant CPU activity.
first test (reference: cpu load=0%):
cyclictest -m -D 5 -i 1000 -p 50 -a 0
# / dev / cpu_dma_latency set to 0us
policy: fifo: loadavg: 1.95 1.06 0.43 1/159 14305
Hi,
on an X86_64 architecture (Intel(R) Core(TM) i3-6100U CPU @ 2.30GHz), I use
the linux kernel 4.9.146 with patch rt 125.
uname a: Linux 4.9.146-rt125 #1 SMP PREEMPT RT Tue Jan 29 14:17:55 CET 2019
x86_64 GNU/Linux
I observed a strange behavior of the scheduler when several tasks are
executed
* Steven Rostedt wrote:
> On Tue, 4 Dec 2018 09:15:06 +0100
> Ingo Molnar wrote:
>
> > * Masami Hiramatsu wrote:
> >
> > > I remember I have fixed this, and actually WE did it :-D
> > >
> > > https://lkml.org/lkml/2018/8/23/1203
> > >
> > > Ah, we hit a same bug...
> > >
> > > Ingo, coul
On Tue, 4 Dec 2018 09:15:06 +0100
Ingo Molnar wrote:
> * Masami Hiramatsu wrote:
>
> > I remember I have fixed this, and actually WE did it :-D
> >
> > https://lkml.org/lkml/2018/8/23/1203
> >
> > Ah, we hit a same bug...
> >
> > Ingo, could you pick the patch? Should I resend it?
>
> Ind
* Masami Hiramatsu wrote:
> I remember I have fixed this, and actually WE did it :-D
>
> https://lkml.org/lkml/2018/8/23/1203
>
> Ah, we hit a same bug...
>
> Ingo, could you pick the patch? Should I resend it?
Indeed: I just picked it up into tip:perf/urgent.
It's my bad: I missed the ori
On Tue, 4 Dec 2018 16:40:07 +0900
Masami Hiramatsu wrote:
> Hi Steve,
>
> On Mon, 3 Dec 2018 21:18:07 -0500
> Steven Rostedt wrote:
>
> > Hi Masami,
> >
> > I started testing some of my new code and the system got into a
> > strange state. Debugging f
Hi Steve,
On Mon, 3 Dec 2018 21:18:07 -0500
Steven Rostedt wrote:
> Hi Masami,
>
> I started testing some of my new code and the system got into a
> strange state. Debugging further, I found the cause came from the
> kprobe tests. It became stranger to me that I could reproduce
On Mon, 2018-10-08 at 10:56 +0300, Igor Stoppa wrote:
> Hi,
>
> I have the following fragment of code:
>
> +struct my_struct {
> + atomic_long_t l __aligned(sizeof(atomic_long_t));
> +} __aligned(sizeof(atomic_long_t));
>
>
> triggering this warning, when fed to checkpatch.pl:
>
> WARNIN
Hi,
I have the following fragment of code:
+struct my_struct {
+ atomic_long_t l __aligned(sizeof(atomic_long_t));
+} __aligned(sizeof(atomic_long_t));
triggering this warning, when fed to checkpatch.pl:
WARNING: function definition argument 'atomic_long_t' should also have
an identifi
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Harald Freudenberger
[ Upstream commit 0b0882672640ced4deeebf84da0b88b6389619c4 ]
The function to decide if one zcrypt queue is better than
another one compared two pointers instead of compar
From: Harald Freudenberger
[ Upstream commit 0b0882672640ced4deeebf84da0b88b6389619c4 ]
The function to decide if one zcrypt queue is better than
another one compared two pointers instead of comparing the
values where the pointers refer to. So within the same
zcrypt card when load of each queue
Signed-off-by: "Eric W. Biederman"
---
include/uapi/asm-generic/siginfo.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/uapi/asm-generic/siginfo.h
b/include/uapi/asm-generic/siginfo.h
index cbe1b0cc7a6a..7158421ac911 100644
--- a/include/uapi/asm-generic/siginfo.h
+++ b/includ
Hi Takashi,
On Mon, 05 Jun 2017 18:32:54 +0200 Takashi Iwai wrote:
>
> Doh, I pushed out a wrong branch (master) to for-next, as I had to
> work on another machine at home today due to a holiday. Now the
> correct branch was pushed.
Much better, thanks :-)
--
Cheers,
Stephen Rothwell
On Mon, 05 Jun 2017 16:17:23 +0200,
Stephen Rothwell wrote:
>
> Hi Takashi,
>
> I don't think you have the result in the sound tree
> (git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
> branch for-next). Yesterday it was a fairly linear tree with head
> commit 7421a1671abe ("ALSA: p
Hi Takashi,
I don't think you have the result in the sound tree
(git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
branch for-next). Yesterday it was a fairly linear tree with head
commit 7421a1671abe ("ALSA: pcm: include pcm_local.h and remove some
extraneous tabs") based on commit f
On 6/2/2017 9:43 AM, Michal Hocko wrote:
On Fri 02-06-17 09:20:54, Tom Lendacky wrote:
On 5/31/2017 11:04 AM, Michal Hocko wrote:
Hi Tom,
Hi Michal,
I have stumbled over the following construct in xgbe_map_rx_buffer
order = max_t(int, PAGE_ALLOC_COSTLY_ORDER - 1, 0);
which looks qui
On Fri 02-06-17 09:20:54, Tom Lendacky wrote:
> On 5/31/2017 11:04 AM, Michal Hocko wrote:
> >Hi Tom,
>
> Hi Michal,
>
> >I have stumbled over the following construct in xgbe_map_rx_buffer
> > order = max_t(int, PAGE_ALLOC_COSTLY_ORDER - 1, 0);
> >which looks quite suspicious. Why does it PAG
On 5/31/2017 11:04 AM, Michal Hocko wrote:
Hi Tom,
Hi Michal,
I have stumbled over the following construct in xgbe_map_rx_buffer
order = max_t(int, PAGE_ALLOC_COSTLY_ORDER - 1, 0);
which looks quite suspicious. Why does it PAGE_ALLOC_COSTLY_ORDER - 1?
And why do you depend on PAGE_ALL
Hi Tom,
I have stumbled over the following construct in xgbe_map_rx_buffer
order = max_t(int, PAGE_ALLOC_COSTLY_ORDER - 1, 0);
which looks quite suspicious. Why does it PAGE_ALLOC_COSTLY_ORDER - 1?
And why do you depend on PAGE_ALLOC_COSTLY_ORDER at all?
Thanks!
--
Michal Hocko
SUSE Labs
On Wed, May 03 2017, Mikulas Patocka wrote:
> On Mon, 24 Apr 2017, NeilBrown wrote:
>>
>> I had a look at how the allocation 'dm_region' objects are used,
>> and it would take a bit of work to make it really safe.
>> My guess is __rh_find() should be allowed to fail, and the various
>> callers ne
On Mon, 24 Apr 2017, NeilBrown wrote:
> On Fri, Apr 21 2017, Mikulas Patocka wrote:
>
> > On Mon, 10 Apr 2017, NeilBrown wrote:
> >
> >> mempool_alloc() should only be called with GFP_ATOMIC when
> >> it is not safe to wait. Passing __GFP_NOFAIL to kmalloc()
> >> says that it is safe to wait in
On Fri, Apr 21 2017, Mikulas Patocka wrote:
> On Mon, 10 Apr 2017, NeilBrown wrote:
>
>> mempool_alloc() should only be called with GFP_ATOMIC when
>> it is not safe to wait. Passing __GFP_NOFAIL to kmalloc()
>> says that it is safe to wait indefinitely. So this code is
>> inconsistent.
>>
>> Cl
On Mon, 10 Apr 2017, NeilBrown wrote:
> mempool_alloc() should only be called with GFP_ATOMIC when
> it is not safe to wait. Passing __GFP_NOFAIL to kmalloc()
> says that it is safe to wait indefinitely. So this code is
> inconsistent.
>
> Clearly it is OK to wait indefinitely in this code, an
mempool_alloc() should only be called with GFP_ATOMIC when
it is not safe to wait. Passing __GFP_NOFAIL to kmalloc()
says that it is safe to wait indefinitely. So this code is
inconsistent.
Clearly it is OK to wait indefinitely in this code, and
mempool_alloc() is able to do that. So just use
m
From: Michal Hocko
alloc_bucket_locks allocation pattern is quite unusual. We are
preferring vmalloc when CONFIG_NUMA is enabled. The rationale is that
vmalloc will respect the memory policy of the current process and so the
backing memory will get distributed over multiple nodes if the requester
From: Michal Hocko
alloc_ila_locks seemed to c&p from alloc_bucket_locks allocation
pattern which is quite unusual. The default allocation size is 320 *
sizeof(spinlock_t) which is sub page unless lockdep is enabled when the
performance benefit is really questionable and not worth the subtle code
The s5p-cec driver has a few places that touch hdmicec clk:
static int s5p_cec_probe(struct platform_device *pdev)
{
...
cec->clk = devm_clk_get(dev, "hdmicec");
if (IS_ERR(cec->clk))
return PTR_ERR(cec->clk);
...
}
static int __maybe_unused s5p_cec
On 01/30/2017 10:49 AM, Michal Hocko wrote:
From: Michal Hocko
alloc_ila_locks seemed to c&p from alloc_bucket_locks allocation
pattern which is quite unusual. The default allocation size is 320 *
sizeof(spinlock_t) which is sub page unless lockdep is enabled when the
performance benefit is rea
On 01/30/2017 10:49 AM, Michal Hocko wrote:
From: Michal Hocko
alloc_bucket_locks allocation pattern is quite unusual. We are
preferring vmalloc when CONFIG_NUMA is enabled. The rationale is that
vmalloc will respect the memory policy of the current process and so the
backing memory will get di
From: Michal Hocko
alloc_ila_locks seemed to c&p from alloc_bucket_locks allocation
pattern which is quite unusual. The default allocation size is 320 *
sizeof(spinlock_t) which is sub page unless lockdep is enabled when the
performance benefit is really questionable and not worth the subtle code
From: Michal Hocko
alloc_bucket_locks allocation pattern is quite unusual. We are
preferring vmalloc when CONFIG_NUMA is enabled. The rationale is that
vmalloc will respect the memory policy of the current process and so the
backing memory will get distributed over multiple nodes if the requester
On Thu, Jan 26, 2017 at 06:57:44AM -0200, Mauro Carvalho Chehab wrote:
> Seems OK to me. Do you want to put it on your tree, or do you
> prefer if I put it on mine?
I can carry it.
> If you prefer to send via your tree:
>
> Reviewed-by: Mauro Carvalho Chehab
Thanks.
--
Regards/Gruss,
Bor
Em Wed, 25 Jan 2017 16:37:28 +0100
Borislav Petkov escreveu:
> On Wed, Jan 25, 2017 at 12:04:04PM +, David Binderman wrote:
> > You'll have a very long wait to get a linux patch from me.
> >
> > I am happy for someone else to invent a patch.
>
> Ah ok, I thought you wanted to give it a tr
On Wed, Jan 25, 2017 at 12:04:04PM +, David Binderman wrote:
> You'll have a very long wait to get a linux patch from me.
>
> I am happy for someone else to invent a patch.
Ah ok, I thought you wanted to give it a try and would want me to help
you with it. :-)
Anyway, here it is:
---
From:
On Wed, Jan 11, 2017 at 11:04:22PM +, David Binderman wrote:
> Thanks for the confirmation that my best guess looks good to you.
So what now, is there a fix in the form of a patch going to appear on
the horizon anytime soon?
:-)
--
Regards/Gruss,
Boris.
Good mailing practices for 400:
From: Michal Hocko
alloc_ila_locks seemed to c&p from alloc_bucket_locks allocation
pattern which is quite unusual. The default allocation size is 320 *
sizeof(spinlock_t) which is sub page unless lockdep is enabled when the
performance benefit is really questionable and not worth the subtle code
From: Michal Hocko
alloc_bucket_locks allocation pattern is quite unusual. We are
preferring vmalloc when CONFIG_NUMA is enabled. The rationale is that
vmalloc will respect the memory policy of the current process and so the
backing memory will get distributed over multiple nodes if the requester
On Wed, Jan 11, 2017 at 04:48:51PM +, David Binderman wrote:
> Hello there,
>
> drivers/edac/i7300_edac.c:307:32: warning: ‘*’ in boolean context, suggest
> ‘&&’ instead [-Wint-in-bool-context]
Are you adding some other -W-switches to the kernel Makefile?
:-)
> Source code is
>
> #defin
From: Michal Hocko
alloc_bucket_locks allocation pattern is quite unusual. We are
preferring vmalloc when CONFIG_NUMA is enabled. The rationale is that
vmalloc will respect the memory policy of the current process and so the
backing memory will get distributed over multiple nodes if the requester
1 - 100 of 1110 matches
Mail list logo
