re N is a constant or an expression, to avoid the multiplication.
>
> [...]
Applied, thanks!
[06/16] rbd: convert timeouts to secs_to_jiffies()
commit: c02eea7eeaebd7270cb8ff09049cc7e0fc9bc8da
Best regards,
--
Jens Axboe
routines.
>
> Link: https://lore.kernel.org/lkml/2d631f0615918...@google.com/
> Reported-by: syzbot+045b454ab35fd82a3...@syzkaller.appspotmail.com
> Reviewed-by: Jens Axboe
> Signed-off-by: Linus Torvalds
> ---
>
> Changes since v1:
>
> - add Link, Reporte
age is.
I've done some basic testing with this - both to verify it fixes the
actual issue at hand (it does, crashes trivially without it), and
networking/pipe based epoll usage and no ill effects observed. Also
passes all ltp test cases as well, but I was less concerned about that
side.
Reviewed-by: Jens Axboe
--
Jens Axboe
On 5/3/24 1:22 PM, Kees Cook wrote:
> On Fri, May 03, 2024 at 12:49:11PM -0600, Jens Axboe wrote:
>> On 5/3/24 12:26 PM, Kees Cook wrote:
>>> Thanks for doing this analysis! I suspect at least a start of a fix
>>> would be this:
>>>
>>> diff --git a/dr
can just grab a reference. That seems
pretty horrible, and the real source of the issue.
> Due to this issue I've proposed fixing get_file() to detect pathological
> states:
> https://lore.kernel.org/lkml/2024050252.work.690-k...@kernel.org/
I don't think this would catch this case, as the memory could just be
garbage at this point.
--
Jens Axboe
On 4/30/24 12:29 PM, Mina Almasry wrote:
> On Tue, Apr 30, 2024 at 6:46?AM Jens Axboe wrote:
>>
>> On 4/26/24 8:11 PM, Mina Almasry wrote:
>>> On Fri, Apr 26, 2024 at 5:18?PM David Wei wrote:
>>>>
>>>> On 2024-04-02 5:20 pm, Mina Almasry wrote:
ate to be in the patches you
> apply on top.
In general, attempting to hide overhead behind config options is always
a losing proposition. It merely serves to say "look, if these things
aren't enabled, the overhead isn't there", while distros blindly enable
pretty much everything and then you're back where you started.
--
Jens Axboe
On 1/19/24 5:27 PM, Helge Deller wrote:
> On 1/19/24 22:22, Jens Axboe wrote:
>> On 1/19/24 2:14 PM, Helge Deller wrote:
>>> On 1/19/24 22:01, Jens Axboe wrote:
>>>> On 1/19/24 1:55 PM, Helge Deller wrote:
>>>>> Adding Mirsad Todorovac (who reported a
On 1/19/24 2:14 PM, Helge Deller wrote:
> On 1/19/24 22:01, Jens Axboe wrote:
>> On 1/19/24 1:55 PM, Helge Deller wrote:
>>> Adding Mirsad Todorovac (who reported a similar issue).
>>>
>>> On 1/19/24 19:39, Jens Axboe wrote:
>>>> My trusty R7525 t
On 1/19/24 1:55 PM, Helge Deller wrote:
> Adding Mirsad Todorovac (who reported a similar issue).
>
> On 1/19/24 19:39, Jens Axboe wrote:
>> My trusty R7525 test box is failing to show a console, or in fact anything,
>> on current -git. There's no output after:
based on Sean's suggestion.
>
> Signed-off-by: Christian Brauner
>
> Changes in v2:
> - further simplify helpers
> - Link to v1:
> https://lore.kernel.org/r/20230713-vfs-eventfd-signal-v1-0-7fda6c5d2...@kernel.org
Only oddity I spotted was the kerneldoc, which someone else alr
#x27;t see them,
or only see small parts of a patchset. And it's really annoying to have
to deal with as a recipient.
--
Jens Axboe
to hear back if it fixes things at your side too.
Yep, looks like that'd fix it indeed.
--
Jens Axboe
0: 80050033
CR2: fff4 CR3: 00010efb5001 CR4: 00570ee0
PKRU: 5554
Ring a bell for anyone? This is an X1 gen9 laptop, intel graphics.
--
Jens Axboe
let()
>
> - out_cast() or outer_cast()
> - from_member().
> - container_from() or from_container()
>
> from_container() sounds fine, would trimming it a bit work? like from_cont().
I like container_from() the most, since it's the closest to contain_of()
which is a well known i
On 8/18/20 1:00 PM, James Bottomley wrote:
> On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote:
>> On 8/17/20 12:48 PM, Kees Cook wrote:
>>> On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote:
>>>> On 8/17/20 12:29 PM, Kees Cook wrote:
>>>>> O
On 8/19/20 6:11 AM, Greg KH wrote:
> On Wed, Aug 19, 2020 at 07:00:53AM -0600, Jens Axboe wrote:
>> On 8/18/20 1:00 PM, James Bottomley wrote:
>>> On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote:
>>>> On 8/17/20 12:48 PM, Kees Cook wrote:
>>>>> O
e up with the idea to add a macro 'from_tasklet' that is just
container_of? container_of in the code would be _much_ more readable,
and not leave anyone guessing wtf from_tasklet is doing.
I'd fix that up now before everything else goes in...
--
Jens Axboe
On 8/17/20 12:29 PM, Kees Cook wrote:
> On Mon, Aug 17, 2020 at 06:56:47AM -0700, Jens Axboe wrote:
>> On 8/17/20 2:15 AM, Allen Pais wrote:
>>> From: Allen Pais
>>>
>>> In preparation for unconditionally passing the
>>> struct tasklet_struct pointer
On 8/17/20 12:48 PM, Kees Cook wrote:
> On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote:
>> On 8/17/20 12:29 PM, Kees Cook wrote:
>>> On Mon, Aug 17, 2020 at 06:56:47AM -0700, Jens Axboe wrote:
>>>> On 8/17/20 2:15 AM, Allen Pais wrote:
>>>>>
gt; Signed-off-by: Anshuman Khandual
>
> For the 'ixgbe' driver changes.
>
> Acked-by: Jeff Kirsher
Lost the original, but for mtip32xx:
Acked-by: Jens Axboe
--
Jens Axboe
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
w them out.
>
> A short status yields the following _outdated_ 00-INDEX files, first
> counter is files listed in 00-INDEX but missing in the directory, last
> is files present but not listed in 00-INDEX.
For the block related bits:
Reviewed-by: Jens Axboe
--
Jens Axboe
__
On 7/12/18 12:45 AM, Joe Perches wrote:
> On Wed, 2018-07-11 at 20:50 +0200, Daniel Vetter wrote:
>> On Wed, Jul 11, 2018 at 8:30 PM, Jens Axboe wrote:
>>> On 7/11/18 10:45 AM, Tejun Heo wrote:
>>>> On Wed, Jul 11, 2018 at 09:40:58AM -0700, Tejun Heo wrote:
>&
; Signed-off-by: Daniel Vetter
>>> Cc: Tejun Heo
>>> Cc: Jens Axboe
>>> Cc: Shaohua Li
>>> Cc: Kate Stewart
>>> Cc: Greg Kroah-Hartman
>>> Cc: Joseph Qi
>>> Cc: Daniel Vetter
>>> Cc: Arnd Bergmann
>>
>> Acke
On 7/11/18 12:50 PM, Daniel Vetter wrote:
> On Wed, Jul 11, 2018 at 8:30 PM, Jens Axboe wrote:
>> On 7/11/18 10:45 AM, Tejun Heo wrote:
>>> On Wed, Jul 11, 2018 at 09:40:58AM -0700, Tejun Heo wrote:
>>>> On Mon, Jul 09, 2018 at 10:36:40AM +0200, Daniel Vetter
On 7/11/18 3:08 PM, Daniel Vetter wrote:
> On Wed, Jul 11, 2018 at 10:06 PM, Tejun Heo wrote:
>> On Wed, Jul 11, 2018 at 01:31:51PM -0600, Jens Axboe wrote:
>>> I don't think there's a git easy way of sending it out outside of
>>> just ensuring that everybody
On 05/07/2017 11:56 AM, Daniel Vetter wrote:
> On Sun, May 7, 2017 at 7:46 PM, Jens Axboe wrote:
>> On 05/07/2017 11:12 AM, ville.syrj...@linux.intel.com wrote:
>>> From: Ville Syrjälä
>>>
>>> Add a new Kconfig option to enable/disable the extra warnings
>
On 05/08/2017 01:25 AM, Daniel Vetter wrote:
> On Sun, May 07, 2017 at 07:52:14PM -0600, Jens Axboe wrote:
>> On 05/07/2017 11:56 AM, Daniel Vetter wrote:
>>> On Sun, May 7, 2017 at 7:46 PM, Jens Axboe wrote:
>>>> On 05/07/2017 11:12 AM, ville.syrj...@linux.inte
still very easy
> to hit on SKL, so we have more work ahead of us to optimize
> the crtiical section further.
Shouldn't it just be a debug printk or something instead, so that normal
people don't see it, but the folks that turn on debugging can get the
info they nee
[drm] Atomic update on pipe (A) took 296 us, max time under
evasion is 100 us
[ 8648.787792] [drm] Atomic update on pipe (A) took 214 us, max time under
evasion is 100 us
--
Jens Axboe
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
On 05/04/2017 11:42 AM, Ville Syrjälä wrote:
> On Thu, May 04, 2017 at 09:26:09AM -0600, Jens Axboe wrote:
>> Hi,
>>
>> Running current -git on my laptop (20FB, X1 Carbon gen4, skylake), I get
>> a lot of the below warnings. Things seem to work fine (in fact it seems
&g
ple can enable
it and play with it if they want, but not making it default to on until
some more clever tracking has been added to dynamically adapt to on when
to poll and when not to. It should not be a default-on type of thing
until it's closer to doing the right thing for a normal workload, not
just some synthetic benchmark.
--
Jens Axboe
On 11/13/2015 03:12 PM, Chris Wilson wrote:
> On Fri, Nov 13, 2015 at 09:22:52AM -0700, Jens Axboe wrote:
>> On 11/13/2015 09:13 AM, Mike Galbraith wrote:
>>> On Fri, 2015-11-13 at 08:36 -0700, Jens Axboe wrote:
>>>> Previous patch was obvious pre-coffee crap, this sh
On 11/13/2015 09:13 AM, Mike Galbraith wrote:
> On Fri, 2015-11-13 at 08:36 -0700, Jens Axboe wrote:
>> Previous patch was obvious pre-coffee crap, this should work for using
>> ktime to spin max 1usec.
>
> 1us seems a tad low. I doubt the little wooden gears and pulleys
if (ktime_after(ktime_get(), timeout))
break;
cpu_relax_lowlatency();
--
Jens Axboe
On 11/13/2015 02:15 AM, Chris Wilson wrote:
> On Thu, Nov 12, 2015 at 03:52:02PM -0700, Jens Axboe wrote:
>> On 11/12/2015 03:19 PM, Chris Wilson wrote:
>>>>> So today, I figured I'd try just killing that spin. If it fails, we'll
>>>>> punt to nor
On 11/12/2015 03:52 PM, Jens Axboe wrote:
> On 11/12/2015 03:19 PM, Chris Wilson wrote:
>>>> So today, I figured I'd try just killing that spin. If it fails, we'll
>>>> punt to normal completions, so easy change. And wow, MASSIVE
>>>> difference.
&
t;> seriously screwed up, guys.
>
> That's over and above the termination condition for blk_poll().
?! And this is related, how? Comparing apples and oranges. One is a test
opt-in feature for experimentation, the other is unconditionally enabled
for everyone. I believe the commit even says so. See the difference?
Would I use busy loop spinning waiting for rotating storage completions,
which are in the 1-10ms range? No, with the reason being that the
potential wins for spins are in the usec range.
--
Jens Axboe
On 11/12/2015 01:36 PM, Jens Axboe wrote:
> Hi,
>
> So a few months ago I got an XPS13 laptop, the one with the high res
> screen. GUI performance was never really that great, I attributed it to
> coming from a more powerful laptop, and the i915 driving a lot of
> pixels. But y
ec6e34
Author: Chris Wilson
Date: Tue Apr 7 16:20:41 2015 +0100
drm/i915: Optimistically spin for the request completion
and read the commit message. Doesn't sound that impressive. Especially
not for something that screws up interactive performance by a LOT.
What's the deal? Revert?
--
Jens Axboe
ce drivers are converting not everyone will have seen this from
> the start.
>
> Jens reported this and submitted a patch to just grab the
> mode_config.connection_mutex, but we can do a bit better.
>
> v2: Remove unused variables I failed to git add for real.
>
> Reported
] [] entry_SYSCALL_64_fastpath+0x12/0x6a
[14954.928008] ---[ end trace b1d297c2aeff3470 ]---
Looks like we're missing a modeset lock/unlock around the property
retrieval from the sysfs path. Below patch works for me.
Signed-off-by: Jens Axboe
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gp
On Fri, Oct 25 2013, Dave Airlie wrote:
> On Fri, Oct 25, 2013 at 8:59 AM, Dave Airlie wrote:
> >> Booting 3.12-rc6 on my macbook quickly freezes after logging in to X. I
> >> was able to capture this oops. It's 100% consistent. 3.11 works
> >> perfectly fine, as did previous kernels.
> >
> > Can
Hi,
Booting 3.12-rc6 on my macbook quickly freezes after logging in to X. I
was able to capture this oops. It's 100% consistent. 3.11 works
perfectly fine, as did previous kernels.
--
Jens Axboe
-- next part --
A non-text attachment was scrubbed...
Name: no
xes things by creating a new system-wide, non-reentrant,
> freezable workqueue and using it for disk-events polling.
Thanks Alan, picked up.
--
Jens Axboe
xes things by creating a new system-wide, non-reentrant,
> freezable workqueue and using it for disk-events polling.
Thanks Alan, picked up.
--
Jens Axboe
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
:
>> Should be easy. Ingo? Steven?
>>
>
> Jens,
>
> Git blame shows this to be your code (copied from block/blktrace.c from
> years past).
>
> Is the lock_kernel() needed here? (although Arnd did add it in 62c2a7d9)
It isn't, it can be removed.
--
:
>> Should be easy. Ingo? Steven?
>>
>
> Jens,
>
> Git blame shows this to be your code (copied from block/blktrace.c from
> years past).
>
> Is the lock_kernel() needed here? (although Arnd did add it in 62c2a7d9)
It isn't, it can be removed.
--
On 2010-08-05 11:17, Markus Trippelsdorf wrote:
> On Thu, Aug 05, 2010 at 11:02:43AM +0200, Jens Axboe wrote:
>> On 2010-08-04 17:59, Tejun Heo wrote:
>>> bd_prepare_to_claim() incorrectly allowed multiple attempts for
>>> exclusive open to progress in parallel if
Signed-off-by: Tejun Heo
> Reported-by: Markus Trippelsdorf
> Cc: stable at kernel.org
Thanks Tejun, applied.
--
Jens Axboe
Confidentiality Notice: This e-mail message, its contents and any attachments
to it are confidential to the intended recipient, and may contain information
that
On 2010-08-05 11:17, Markus Trippelsdorf wrote:
> On Thu, Aug 05, 2010 at 11:02:43AM +0200, Jens Axboe wrote:
>> On 2010-08-04 17:59, Tejun Heo wrote:
>>> bd_prepare_to_claim() incorrectly allowed multiple attempts for
>>> exclusive open to progress in parallel if
Signed-off-by: Tejun Heo
> Reported-by: Markus Trippelsdorf
> Cc: sta...@kernel.org
Thanks Tejun, applied.
--
Jens Axboe
Confidentiality Notice: This e-mail message, its contents and any attachments
to it are confidential to the intended recipient, and may contain information
that
52 matches
Mail list logo
