avoids the
> warnings and adds useful format string checks.
>
> Signed-off-by: Arnd Bergmann
Acked-by: Stanislaw Gruszka
On Sun, Feb 28, 2021 at 08:25:22PM +0800, Dinghao Liu wrote:
> There is one il_set_tx_power() call in this function without
> return value check. Print error message and return error code
> on failure just like the other il_set_tx_power() call.
We have few calls for il_set_tx_power(), on some case
On Thu, Feb 18, 2021 at 03:20:14PM +0800, Jiapeng Chong wrote:
> Fix the following coccicheck warnings:
>
> ./drivers/net/wireless/intel/iwlegacy/4965-mac.c:2596:54-56: WARNING !A
> || A && B is equivalent to !A || B.
>
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Chong
> ---
> drivers/
-by: Jiapeng Chong
Acked-by: Stanislaw Gruszka
On Thu, Jan 21, 2021 at 04:47:37PM +0800, 慕冬亮 wrote:
> ## Patch
>
> I propose to memset reg variable before invoking
> rt2x00usb_vendor_req_buff_lock/rt2x00usb_vendor_request_buff.
>
>
On Wed, Dec 09, 2020 at 03:08:26PM +, Matthew Wilcox wrote:
> On Wed, Dec 09, 2020 at 03:46:28PM +0100, Stanislaw Gruszka wrote:
> > At this point of release cycle we should probably go with revert,
> > but I think the main problem is that BPF and ERROR_INJECTION use
> >
On Mon, Dec 07, 2020 at 05:12:52PM -0800, Alexei Starovoitov wrote:
> > > > > > > >>> -noinline int __add_to_page_cache_locked(struct page *page,
> > > > > > > >>> +static noinline int __add_to_page_cache_locked(struct page
> > > > > > > >>> *page,
> > > > > > > >>>
On Mon, Nov 02, 2020 at 06:19:32PM +0200, Kalle Valo wrote:
> Марков Михаил Александрович writes:
>
> > rt2800 only gives you survey for current channel.
> >
> > Survey-based ACS algorithms are failing to perform their job when working
> > with rt2800.
> >
> > Make rt2800 save survey for every ch
nd be able to give away
> that information.
>
> There is a bug registered https://dev.archive.openwrt.org/ticket/19081 and
> this patch solves the issue.
>
> Signed-off-by: Markov Mikhail
>
> ---
> Changes are now aggregated in rt2800lib.c.
Acked-by: Stanislaw Gruszka
Thanks
Stanislaw
On Mon, Oct 19, 2020 at 07:06:47PM +, Марков Михаил Александрович wrote:
> rt2800 only gives you survey for current channel.
> .watchdog= rt2800_watchdog,
> +.update_survey= rt2800_update_survey,
Since this feature is rt2800 specific, I would do not add new generic
ca
On Thu, Jul 25, 2019 at 04:09:26PM +0800, Jian-Hong Pan wrote:
> Each skb as the element in RX ring was expected with sized buffer 8216
> (RTK_PCI_RX_BUF_SIZE) bytes. However, the skb buffer's true size is
> 16640 bytes for alignment after allocated, x86_64 for example. And, the
rtw88 advertise IE
oN
>
> Signed-off-by: Masanari Iida
Acked-by: Stanislaw Gruszka
On Mon, Jul 22, 2019 at 10:00:34PM +0200, Peter Zijlstra wrote:
> On Mon, Jul 22, 2019 at 12:52:41PM +0200, Stanislaw Gruszka wrote:
> > On Fri, Jul 19, 2019 at 01:03:49PM +0200, Peter Zijlstra wrote:
> > > > shows the problem even when sum_exec_runtime is not that big:
On Fri, Jul 19, 2019 at 01:03:49PM +0200, Peter Zijlstra wrote:
> > shows the problem even when sum_exec_runtime is not that big: 30 secs.
> >
> > The new implementation of scale_stime() does the additional div64_u64_rem()
> > in a loop but see the comment, as long it is used by cputime_adjust
On Wed, Jul 17, 2019 at 06:57:12PM -0700, Brian Norris wrote:
> ieee80211_set_wmm_default() normally sets up the initial CW min/max for
> each queue, except that it skips doing this if the driver doesn't
> support ->conf_tx. We still end up calling drv_conf_tx() in some cases
> (e.g., ieee80211_rec
unnecessary ENTRY_DATA_STATUS_PENDING flag checks from the RX path.
> Also remove the misleading comment about reading RX status from device.
>
> Suggested-by: Stanislaw Gruszka
> Signed-off-by: Soeren Moch
Acked-by: Stanislaw Gruszka
lush_queue: Warning - Queue 14 failed to flush".
> Other operation modes are probably affected as well, this just was
> the used testcase.
>
> Fixes: ed194d136769 ("usb: core: remove local_irq_save() around ->complete()
> handler")
> Cc: sta...@vger.kernel.org # 4.20+
> Signed-off-by: Soeren Moch
Acked-by: Stanislaw Gruszka
On Mon, Jul 01, 2019 at 12:49:50PM +0200, Soeren Moch wrote:
> Hello!
>
> On 29.06.19 10:50, Stanislaw Gruszka wrote:
> > Hello
> >
> > On Wed, Jun 26, 2019 at 03:28:00PM +0200, Soeren Moch wrote:
> >> Hi Stanislaw,
> >>
> >> the good news
Hello
On Wed, Jun 26, 2019 at 03:28:00PM +0200, Soeren Moch wrote:
> Hi Stanislaw,
>
> the good news is: your patch below also solves the issue for me. But
> removing the ENTRY_DATA_STATUS_PENDING check in
> rt2x00usb_kick_rx_entry() alone does not help, while removing this check
> in rt2x00usb_w
Hello
On Fri, Jun 21, 2019 at 01:30:01PM +0200, Soeren Moch wrote:
> On 18.06.19 11:34, Stanislaw Gruszka wrote:
> > Hi
> >
> > On Mon, Jun 17, 2019 at 11:46:56AM +0200, Soeren Moch wrote:
> >> Since commit ed194d136769 ("usb: core: remove local_irq_save() arou
Hi
On Mon, Jun 17, 2019 at 11:46:56AM +0200, Soeren Moch wrote:
> Since commit ed194d136769 ("usb: core: remove local_irq_save() around
> ->complete() handler") the handlers rt2x00usb_interrupt_rxdone() and
> rt2x00usb_interrupt_txdone() are not running with interrupts disabled
> anymore. So thes
On Thu, Apr 25, 2019 at 10:42:01PM +0800, Ryder Lee wrote:
> Fix many warnings with incorrect endian assumptions.
>
> Reported-by: kbuild test robot
> Signed-off-by: Ryder Lee
> ---
> drivers/net/wireless/mediatek/mt76/mt7603/mac.c | 2 +-
> drivers/net/wireless/mediatek/mt76/mt7615/mac.c | 12
On Thu, Feb 28, 2019 at 02:40:29PM +0100, Joerg Roedel wrote:
> On Thu, Feb 28, 2019 at 01:19:48PM +0100, Stanislaw Gruszka wrote:
> > Nevermind, the patch is wrong, s->dma_address is initalized in
> > sg_num_pages().
>
> Yes, it is. In sg_num_pages() the offset i
On Thu, Feb 28, 2019 at 11:42:24AM +0100, Stanislaw Gruszka wrote:
> On Thu, Feb 28, 2019 at 10:04:12AM +0100, Stanislaw Gruszka wrote:
> > On Tue, Feb 26, 2019 at 12:24:08PM +0100, Stanislaw Gruszka wrote:
> > > On Tue, Feb 26, 2019 at 11:44:13AM +0100, Joerg Roedel wrote:
>
On Thu, Feb 28, 2019 at 10:04:12AM +0100, Stanislaw Gruszka wrote:
> On Tue, Feb 26, 2019 at 12:24:08PM +0100, Stanislaw Gruszka wrote:
> > On Tue, Feb 26, 2019 at 11:44:13AM +0100, Joerg Roedel wrote:
> > > On Tue, Feb 26, 2019 at 11:34:51AM +0100, Stanislaw Gruszka wrote:
>
On Tue, Feb 26, 2019 at 12:24:08PM +0100, Stanislaw Gruszka wrote:
> On Tue, Feb 26, 2019 at 11:44:13AM +0100, Joerg Roedel wrote:
> > On Tue, Feb 26, 2019 at 11:34:51AM +0100, Stanislaw Gruszka wrote:
> > > On Tue, Feb 26, 2019 at 11:05:36AM +0100, Joerg Roedel wrote:
&
On Tue, Feb 26, 2019 at 11:44:13AM +0100, Joerg Roedel wrote:
> On Tue, Feb 26, 2019 at 11:34:51AM +0100, Stanislaw Gruszka wrote:
> > On Tue, Feb 26, 2019 at 11:05:36AM +0100, Joerg Roedel wrote:
> > If sg->offset > PAGE_SIZE is fine then most likely we have problem with
&g
On Tue, Feb 26, 2019 at 11:05:36AM +0100, Joerg Roedel wrote:
> On Mon, Feb 18, 2019 at 03:37:48PM +0100, Stanislaw Gruszka wrote:
> > 0001-mt76x02u-use-usb_bulk_msg-to-upload-firmware.patch
> > 0002-mt76usb-do-not-use-compound-head-page-for-SG-I-O.patch
> >
> > Or pr
On Mon, Feb 18, 2019 at 05:01:59PM +, Robin Murphy wrote:
> On 18/02/2019 14:37, Stanislaw Gruszka wrote:
> [...]
> >Another issue is that dma_map_sg() & dma_map_page() may require some
> >constraints. I'm not sure about that and I want to clarify that with
> >
(cc: IOMMU & page_frag_alloc maintainers)
On Tue, Jan 15, 2019 at 10:04:01AM +0100, Lorenzo Bianconi wrote:
> > On Mon, Jan 14, 2019 at 1:18 AM Lorenzo Bianconi
> > wrote:
> > >
> > > > On Sun, Jan 13, 2019 at 11:00 AM Lorenzo Bianconi
> > > > wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > >
On Mon, Jan 28, 2019 at 09:45:03AM -0800, Andrew Morton wrote:
> On Mon, 28 Jan 2019 15:49:04 +0100 Stanislaw Gruszka
> wrote:
>
> > fls counts bits starting from 1 to 32 (returns 0 for zero argument).
> > If we add 1 we shift right one bit more and loose precision from
&g
=202391
Fixes: 658716d19f8f ("div64_u64(): improve precision on 32bit platforms")
Reported-and-tested-by: Siarhei Volkau
Signed-off-by: Stanislaw Gruszka
---
lib/div64.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/div64.c b/lib/div64.c
index 01
On Tue, Jan 22, 2019 at 04:21:34PM +0100, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: Stanislaw Gruszk
On Tue, Jan 22, 2019 at 04:21:18PM +0100, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: Stanislaw Grusz
ware is
> trying to be smarter than the driver, which is bound
> to fail.
>
> As workaround the function rt61pci_config_shared_key
> requests software decryption of the shared keys,
> by returning EOPNOTSUPP. However, pairwise keys are
> still handled by hardware which works just fine.
>
> Signed-off-by: Bernd Edlinger
Acked-by: Stanislaw Gruszka
On Thu, Oct 04, 2018 at 04:52:19PM +0800, Jia-Ju Bai wrote:
> On 2018/10/4 15:59, Stanislaw Gruszka wrote:
> >On Wed, Oct 03, 2018 at 10:07:45PM +0800, Jia-Ju Bai wrote:
> >>These possible races are detected by a runtime testing.
> >>To fix these races
On Wed, Apr 18, 2018 at 12:47:50PM +0100, Colin King wrote:
> From: Colin Ian King
>
> Rename several macros that contain mispellings of UNKNOWN
>
> Signed-off-by: Colin Ian King
Acked-by: Stanislaw Gruszka
On Fri, Jan 05, 2018 at 12:08:00AM +0900, Masanari Iida wrote:
> This patch fix a typo in rt2800lib.c
>
> Signed-off-by: Masanari Iida
Acked-by: Stanislaw Gruszka
t; Signed-off-by: Markus Elfring
Acked-by: Stanislaw Gruszka
On Wed, Nov 08, 2017 at 12:07:15PM +0100, Richard Genoud wrote:
> (maybe if there was more than one CPU on the board, I could do
> something, but that's not the case)
I reproduced the problem with nosmp option. I think we need
to check also for ENOENT error (not only for ENODEV).
Will post the fix
On Wed, Nov 08, 2017 at 12:07:15PM +0100, Richard Genoud wrote:
> > No, that not I wanted you to do. Please remove those options and just
> > do
> > below on tracing directory.
> >
> > echo 0 > tracing_on
> > cat trace > /dev/null
> > echo "function_graph" > current_tracer
> > echo "rt2*" > set
On Tue, Nov 07, 2017 at 12:13:47PM +0100, Richard Genoud wrote:
> Le mardi 07 novembre 2017 à 11:13 +0100, Stanislaw Gruszka a écrit :
> > On Tue, Nov 07, 2017 at 11:06:39AM +0100, Richard Genoud wrote:
> > > > 3 short articles how to configure and use ftrace are here:
&g
On Tue, Nov 07, 2017 at 12:01:23PM +0100, Richard Genoud wrote:
> Le mardi 07 novembre 2017 à 11:13 +0100, Stanislaw Gruszka a écrit :
> > On Tue, Nov 07, 2017 at 11:06:39AM +0100, Richard Genoud wrote:
> > > > 3 short articles how to configure and use ftrace are here:
&g
On Tue, Nov 07, 2017 at 11:06:39AM +0100, Richard Genoud wrote:
> > 3 short articles how to configure and use ftrace are here:
> > https://lwn.net/Articles/365835/
> > https://lwn.net/Articles/366796/
> > https://lwn.net/Articles/370423/
> >
> I tried with ftrace, but I don't think there's a way t
Hi
On Mon, Nov 06, 2017 at 04:57:09PM +0100, Richard Genoud wrote:
> I get a soft lock-up while unbinding the USB driver on a TP-Link TL-WN727Nv3
> (chipset 5370):
>
> # echo 1-2.2 > /sys/bus/usb/drivers/usb/unbind
> watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/u2:3:308]
...
> I ca
On Mon, Oct 16, 2017 at 04:37:44PM -0700, Kees Cook wrote:
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
>
> Cc: Stanislaw Grusz
On Mon, Oct 16, 2017 at 02:24:56PM +0200, Pavel Machek wrote:
> So far it happened once... so I don't know about reproducibility. And
> I'm not even sure if I'm using iwlegacy driver. Am I?
iwl3945 (and iwl4965) are iwlegacy drivers.
Regards
Stanislaw
Hi
Site note: Intel folks do not support iwlegacy, I removed them from CC.
On Mon, Oct 16, 2017 at 12:27:45PM +0200, Pavel Machek wrote:
> > In -next... after few days of usage with suspend and resume cycles,
> > wifi failed on thinkpad x60. I have not seen this in years...
> > Any ideas?
We do
Hi Dmitry
On Sat, Oct 14, 2017 at 04:38:03PM +0200, Dmitry Vyukov wrote:
> On Thu, Oct 12, 2017 at 9:25 AM, Stanislaw Gruszka
> wrote:
> > Hi
> >
> > On Mon, Oct 09, 2017 at 07:50:53PM +0200, Andrey Konovalov wrote:
> >> I've got the following report w
On Fri, Oct 13, 2017 at 04:47:45PM +0200, Oleg Nesterov wrote:
> Yes, sorry, my fault. Fixed by the patch from Eryu, already in -mm tree.
No worries, I just used power button to "help" the system to shutdown :-)
Now is fixed in mainline, thanks.
Stanislaw
On 4.14-rc4 updated today, I have OOPS on bm_evict_inode(). It happens
every time during shutdown of the system.
Seems e = inode->i_private is NULL and e->flags crashes.
Picture with the OOPS call trace is here:
http://people.redhat.com/sgruszka/DSC_0733.JPG
Thanks
Stanislaw
Hi
On Mon, Oct 09, 2017 at 07:50:53PM +0200, Andrey Konovalov wrote:
> I've got the following report while fuzzing the kernel with syzkaller.
>
> On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4).
>
> I'm not sure whether this is a bug in the driver, or just a way to
> report misbeha
On Tue, Oct 10, 2017 at 12:59:26PM +0200, Ingo Molnar wrote:
>
> (Cc:-ed more gents involved in kernel/sched/cputime.c work. Full patch quoted
> below.)
>
> * Dongli Zhang wrote:
>
> > After guest live migration on xen, steal time in /proc/stat
> > (cpustat[CPUTIME_STEAL]) might decrease becau
Content type information was added at the end of the topic, but
I think Kalle can fix that when he will be committing the patch.
Acked-by: Stanislaw Gruszka
On Fri, Jun 30, 2017 at 06:10:35AM -0700, tip-bot for Gustavo A. R. Silva wrote:
> diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
> index aea3135..67c70e2 100644
> --- a/kernel/sched/cputime.c
> +++ b/kernel/sched/cputime.c
> @@ -615,19 +615,13 @@ static void cputime_adjust(struct tas
On Tue, May 16, 2017 at 01:55:17PM +0200, Stanislaw Gruszka wrote:
> On Mon, May 15, 2017 at 10:39:51AM -0400, David Miller wrote:
> > From: Stanislaw Gruszka
> > Date: Mon, 15 May 2017 16:28:01 +0200
> >
> > > On Mon, May 15, 2017 at 03:46:55PM +0200, Ar
On Tue, May 16, 2017 at 01:58:56PM +0200, Johannes Berg wrote:
> On Tue, 2017-05-16 at 13:55 +0200, Stanislaw Gruszka wrote:
> >
> > In rt2x00 driver we use poor convention in other kind of registers
> > accessors like bbp, mac, eeprom. I dislike to changing only rfcsr
>
On Mon, May 15, 2017 at 10:39:51AM -0400, David Miller wrote:
> From: Stanislaw Gruszka
> Date: Mon, 15 May 2017 16:28:01 +0200
>
> > On Mon, May 15, 2017 at 03:46:55PM +0200, Arnd Bergmann wrote:
> >> With CONFIG_KASAN enabled and gcc-7, we get a warning about rather hig
On Mon, May 15, 2017 at 03:46:55PM +0200, Arnd Bergmann wrote:
> With CONFIG_KASAN enabled and gcc-7, we get a warning about rather high
> stack usage (with a private patch set I have to turn on this warning,
> which I intend to get into the next kernel release):
>
> wireless/ralink/rt2x00/rt2800l
On Mon, Apr 24, 2017 at 10:06:32PM +0900, Tetsuo Handa wrote:
> Stanislaw Gruszka wrote:
> > On Sun, Apr 23, 2017 at 07:24:21PM +0900, Tetsuo Handa wrote:
> > > On 2017/03/10 20:44, Tetsuo Handa wrote:
> > > > Michal Hocko wrote:
> > > >> I am definitel
On Sun, Apr 23, 2017 at 07:24:21PM +0900, Tetsuo Handa wrote:
> On 2017/03/10 20:44, Tetsuo Handa wrote:
> > Michal Hocko wrote:
> >> On Thu 09-03-17 13:05:40, Johannes Weiner wrote:
> >>> On Tue, Mar 07, 2017 at 02:52:36PM -0500, Rik van Riel wrote:
> It only does this to some extent. If rec
a NULL or we get a pointer to an inited structure.
>
> As for the hypervisor -- that falls back to more limited state after
> resume (because some of this state is thrown away at suspend) and so
> uses that until it gets the uploaded PM state from the initial-domain.
Patch looks good to me then.
Reviewed-by: Stanislaw Gruszka
On Tue, Mar 21, 2017 at 03:43:38PM -0700, Ankur Arora wrote:
> This was broken in commit cd979883b9ede90643e019f33cb317933eb867b4.
> do_suspend (from xen/manage.c) and thus xen_resume_notifier never get
> called on the initial-domain at resume (it is if running as guest.)
>
> The rationale for the
On Mon, Jan 30, 2017 at 03:56:49PM +0100, Frederic Weisbecker wrote:
> On Mon, Jan 30, 2017 at 03:32:24PM +0100, Stanislaw Gruszka wrote:
> > On Mon, Jan 30, 2017 at 05:46:43AM +0100, Frederic Weisbecker wrote:
> > > Now lets admit one drawback: s39
On Mon, Jan 30, 2017 at 05:46:43AM +0100, Frederic Weisbecker wrote:
> Now lets admit one drawback: s390 and powerpc with
> CONFIG_VIRT_CPU_ACCOUNTING_NATIVE have new cputime_t to nsecs conversion
> on cputime accounting path. But this should be leveraged by the recent
> changes which delay the cpu
On Sat, Jan 28, 2017 at 04:28:13PM +0100, Frederic Weisbecker wrote:
> On Sat, Jan 28, 2017 at 12:57:40PM +0100, Stanislaw Gruszka wrote:
> > On 32 bit architectures 64bit store/load is not atomic and if not
> > protected - 64bit variables can be mangled. I do not see any prote
Hi Frederic and sorry for late comment.
On Sun, Jan 22, 2017 at 07:19:44PM +0100, Frederic Weisbecker wrote:
> Now that most cputime readers use the transition API which return the
> task cputime in old style cputime_t, we can safely store the cputime in
> nsecs. This will eventually make cputime
Commit-ID: 353c50ebe329daaf2c94dc41c1c481cbba2a31fd
Gitweb: http://git.kernel.org/tip/353c50ebe329daaf2c94dc41c1c481cbba2a31fd
Author: Stanislaw Gruszka
AuthorDate: Tue, 15 Nov 2016 03:06:52 +0100
Committer: Ingo Molnar
CommitDate: Tue, 15 Nov 2016 09:51:05 +0100
sched/cputime
Commit-ID: 981ee2d08fc55b9390d6a4a54a6697513611
Gitweb: http://git.kernel.org/tip/981ee2d08fc55b9390d6a4a54a6697513611
Author: Stanislaw Gruszka
AuthorDate: Tue, 15 Nov 2016 03:06:50 +0100
Committer: Ingo Molnar
CommitDate: Tue, 15 Nov 2016 09:51:04 +0100
sched/cputime
Commit-ID: 40565b5aedd6d0ca88b7dfd3859d709d2f6f8cf9
Gitweb: http://git.kernel.org/tip/40565b5aedd6d0ca88b7dfd3859d709d2f6f8cf9
Author: Stanislaw Gruszka
AuthorDate: Tue, 15 Nov 2016 03:06:51 +0100
Committer: Ingo Molnar
CommitDate: Tue, 15 Nov 2016 09:51:05 +0100
sched/cputime
Commit-ID: 7008eb997bcfdd8c5274bb6672aa5d4e77994309
Gitweb: http://git.kernel.org/tip/7008eb997bcfdd8c5274bb6672aa5d4e77994309
Author: Stanislaw Gruszka
AuthorDate: Tue, 15 Nov 2016 03:06:49 +0100
Committer: Ingo Molnar
CommitDate: Tue, 15 Nov 2016 09:51:04 +0100
sched/cputime
On Wed, Nov 02, 2016 at 10:11:22AM +0100, Christian Borntraeger wrote:
> On 10/31/2016 01:36 PM, Stanislaw Gruszka wrote:
> > Only s390 and powerpc have hardware facilities allowing to measure
> > cputimes scaled by frequency. On all other architectures
> > utimescaled/sti
s390, where those values are explicitly accounted on proper
places.
Signed-off-by: Stanislaw Gruszka
---
v1 -> v2 : fix compilation (missed comma)
v2 -> v3 : fix compilation when ARCH_HAS_SCALED_CPUTIME should be selected
arch/Kconfig|3 ++
arch/ia64/kernel/time.c
s390, where those values are explicitly accounted on proper
places.
Signed-off-by: Stanislaw Gruszka
---
v1 -> v2 : fix compilation (missed comma)
arch/ia64/kernel/time.c |4 +-
arch/powerpc/Kconfig|1 +
arch/powerpc/kernel/time.c |6 +++-
arch/s390/Kconfig |
NULL checks on task_cputimes_scaled().
Signed-off-by: Stanislaw Gruszka
---
arch/x86/kernel/apm_32.c |4 +-
include/linux/sched.h | 12 +++-
kernel/sched/cputime.c | 57 ++-
kernel/time/posix-cpu-timers.c |4 +-
4
Since commit:
cf9efce0ce313 ("powerpc: Account time using timebase rather than PURR")
cputime_last_delta is not initialized to other value than 0, hence it's
not used except zero check and cputime_to_scaled() just returns
the argument.
Signed-off-by: Stanislaw Gruszka
---
arch/
s390, where those values are explicitly accounted on proper
places.
Signed-off-by: Stanislaw Gruszka
---
arch/ia64/kernel/time.c |4 +-
arch/powerpc/Kconfig|1 +
arch/powerpc/kernel/time.c |6 +++-
arch/s390/Kconfig |1 +
arch/s390/kernel/vtime.c|9
Currently cputime_to_scaled() just return it's argument on
all implementations, we don't need to call this function.
Signed-off-by: Stanislaw Gruszka
---
arch/powerpc/include/asm/cputime.h|7 ---
include/asm-generic/cputime_jiffies.h |1 -
include/asm-generic/cputi
not be removed by whole (i.e. replaced by normal
utimes/stimes on powerpc and s390).
Stanislaw Gruszka (4):
cputime/powerpc: remove cputime_last_delta global variable
cputime/powerpc: remove cputime_to_scaled()
cputime/powerpc/s390: make scaled cputime arch specific
cputime: simplify
sed to a top-level macro call
> 4. No pointer or array-typed field passed to a function or stored in a
> variable.
> Declare structures having all of these properties as const.
>
> Done using Coccinelle.
> Based on a suggestion by Joe Perches .
>
> Signed-off-by: Julia Lawall
Acked-by: Stanislaw Gruszka
On Tue, Sep 06, 2016 at 09:01:29PM +0200, Peter Zijlstra wrote:
> On Tue, Sep 06, 2016 at 02:49:08PM +0200, Stanislaw Gruszka wrote:
> > diff --git a/kernel/exit.c b/kernel/exit.c
> > index 2f974ae..a46f96f 100644
> > --- a/kernel/exit.c
> > +++ b/kernel/exit.c
> >
stency can results of cpuclock
monotonicity breakage or cputimer expire too early or too late.
Signed-off-by: Stanislaw Gruszka
---
v2 -> v3:
- don't drop rq->lock
- don't use read_sum_exec_runtime() where we read other 64bit variables
without protection for debug/statistics p
On Mon, Sep 05, 2016 at 11:13:01AM +0200, Stanislaw Gruszka wrote:
> Currently we protect 64bit sum_exec_runtime read on 32bit cpus using
> task_rq_lock() which internally takes t->pi_lock and rq->lock. Taking
> rq->lock is not needed in this case.
I looked more at kernel/sched
Optimize read_sum_exec_runtime() on 32-bit cpus by taking only p->pi_lock
and use above function to protect reads of 64bit sum_exec_runtime on
other places on 32 bit architectures.
Stanislaw Gruszka (2):
sched/cputime: Use only pi_lock to protect sum_exec_runtime read
sched/cputime: Prot
Currently we protect 64bit sum_exec_runtime read on 32bit cpus using
task_rq_lock() which internally takes t->pi_lock and rq->lock. Taking
rq->lock is not needed in this case.
Signed-off-by: Stanislaw Gruszka
---
kernel/sched/cputime.c | 7 +++
1 file changed, 3 insertions(+), 4
, exec_start) without protection.
But since this is for debug purpose and inconsistency is very unlike,
we can ignore that.
Signed-off-by: Stanislaw Gruszka
---
fs/proc/base.c | 2 +-
include/linux/sched.h | 19 +++
kernel/delayacct.c | 2
On Thu, Sep 01, 2016 at 11:49:06AM +0200, Peter Zijlstra wrote:
> On Thu, Sep 01, 2016 at 11:27:42AM +0200, Stanislaw Gruszka wrote:
> > My previous commit:
> >
> > a1eb1411b4e4 ("sched/cputime: Improve scalability by not accounting
> > thread group tasks pend
architectures.
Second patch could be merged with first one, but I posted it separately
for eventual discussion.
Stanislaw Gruszka (3):
sched/cputime: Improve scalability of times()/clock_gettime() on 32
bit cpus
sched/cputime: Make nr_migrations u32 on 32 bit cpus
sched/cputime: Protect
) without protection.
But since this is for debug purpose and inconsistency is very very
improbable, we can ignore it.
Signed-off-by: Stanislaw Gruszka
---
fs/proc/base.c | 2 +-
kernel/delayacct.c | 2 +-
kernel/exit.c | 2 +-
kernel/sched/cputime.c
x8()) are slow.
Signed-off-by: Stanislaw Gruszka
---
include/linux/sched.h | 39 +--
kernel/sched/core.c| 17 +
kernel/sched/cputime.c | 22 +-
kernel/sched/deadline.c| 2 +-
kernel/sched
variables commonly used
together are kept in a cache line, make nr_migrations field u32 on
32 bit architectures.
This field is used only for debugging and basically nr_migrations
should not be enormous number.
Signed-off-by: Stanislaw Gruszka
---
include/linux/sched.h | 5 +++--
kernel/sched/de
Commit-ID: a1eb1411b4e4251db02179e39d234c2ee5192c72
Gitweb: http://git.kernel.org/tip/a1eb1411b4e4251db02179e39d234c2ee5192c72
Author: Stanislaw Gruszka
AuthorDate: Wed, 17 Aug 2016 11:30:44 +0200
Committer: Ingo Molnar
CommitDate: Thu, 18 Aug 2016 11:53:46 +0200
sched/cputime
3.28 ( 15.42%)1.60 (
58.81%)
1103.902.98 ( 23.73%)3.38 ( 13.35%)1.73 (
55.61%)
1284.003.10 ( 22.40%)3.38 ( 15.45%)1.66 (
58.52%)
Reported-and-tested-by: Giovanni Gherdovich
Signed-off-by: Stanislaw G
On Mon, Aug 15, 2016 at 10:58:04AM +0100, Mel Gorman wrote:
> On Mon, Aug 15, 2016 at 11:19:01AM +0200, Stanislaw Gruszka wrote:
> > > Is this really equivalent though? It updates one task instead of all
> > > tasks in the group and there is no guarantee that tsk == cur
On Mon, Aug 15, 2016 at 05:13:30PM +0800, Wanpeng Li wrote:
> 2016-08-12 20:10 GMT+08:00 Stanislaw Gruszka :
> > Hi
> >
> > On Wed, Aug 10, 2016 at 01:26:41PM +0200, Ingo Molnar wrote:
> >> Nice detective work! I'm wondering, where do we stand if compared
On Mon, Aug 15, 2016 at 09:33:49AM +0100, Mel Gorman wrote:
> On Mon, Aug 15, 2016 at 09:49:05AM +0200, Giovanni Gherdovich wrote:
> > > mmtest benchmark results are below (full compare-kernels.sh output is in
> > > attachment):
> > >
> > > vanila-4.7revertprefetch
Hi
On Wed, Aug 10, 2016 at 01:26:41PM +0200, Ingo Molnar wrote:
> Nice detective work! I'm wondering, where do we stand if compared with a
> pre-6e998916dfe3 kernel?
>
> I admit this is a difficult question: 6e998916dfe3 does not revert cleanly
> and I
> suspect v3.17 does not run easily on a
009313f ("rt2x00usb: Use usb anchor to manage URB")
>
> Signed-off-by: Christophe JAILLET
Acked-by: Stanislaw Gruszka
On Thu, Jul 14, 2016 at 09:44:22AM +, Grumbach, Emmanuel wrote:
> > If I understad correctly this error happen 100% of the time, not only during
> > init. Hence seems there is an issue here, i.e. cur_ucode is not marked
> > correctly as IWL_UCODE_REGULAR or iwl_mvm_get_temp() fail 100% of the
>
On Mon, Jul 11, 2016 at 06:27:30PM +, Grumbach, Emmanuel wrote:
> I guess that works, but it seems wrong to me. Usually, registration
> should happen only upon INIT, and yes, at that time the firmware is not
> ready to provide the information yet.
> >
> > As can be seen in the current code ba
1 - 100 of 263 matches
Mail list logo
