Reviewed-by: Karol Herbst
On Fri, Apr 16, 2021 at 4:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nouveau_ioc32.c:2: warning: Cannot understand *
> file mga_ioc32.c
>
> Cc: Ben Skeggs
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri
--
I am Mrs samira mohamed
Hi Friend I am a bank director of the UBA Bank Plc bf .I want to
transfer an abandoned sum of 27.5 millions USD to you through ATM
VISA CARD .50% will be for you. No risk involved. Contact me for more
details. Kindly reply me back to my alternative email
address(sm855
How are you today?
This is MoneyGram International Inc. we are contacting you concerning
your winning fund $1.500, 000.00 USD; your e-mail won $1.500, 000.00
dollars through Internet contest, and lottery bonus under MoneyGram
International Inc. Worldwide. The lottery bonus is contesting once in
a
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/nouveau/nouveau_ioc32.c:2: warning: Cannot understand * file
mga_ioc32.c
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
dr
How are you today?
This is MoneyGram International Inc. we are contacting you concerning
your winning fund $1.500, 000.00 USD; your e-mail won $1.500, 000.00
dollars through Internet contest, and lottery bonus under MoneyGram
International Inc. Worldwide. The lottery bonus is contesting once in
a
HELLO
I am Mrs. Chantal Lawrence. I am sending this brief letter to solicit
your partnership to transfer a sum of 12 Million Dollars into your
reliable account as my business partner. However, it's my urgent need
for foreign partner that made me to contact you for this transaction.
Further details
Return the exactly delay time given by root hub descriptor,
this helps to reduce resume time etc.
Due to the root hub descriptor is usually provided by the host
controller driver, if there is compatibility for a root hub,
we can fix it easily without affect other root hub
Acked-by: Alan Stern
Si
On Fri, Apr 09, 2021 at 10:39:07AM +0800, Chunfeng Yun wrote:
> Return the exactly delay time given by root hub descriptor,
> this helps to reduce resume time etc.
>
> Due to the root hub descriptor is usually provided by the host
> controller driver, if there is compatibility for a root hub,
> we
Return the exactly delay time given by root hub descriptor,
this helps to reduce resume time etc.
Due to the root hub descriptor is usually provided by the host
controller driver, if there is compatibility for a root hub,
we can fix it easily without affect other root hub
Signed-off-by: Chunfeng
On Fri, Mar 19, 2021 at 03:34:50PM +0100, David Hildenbrand wrote:
> Exploring /dev/kmem and /dev/mem in the context of memory hot(un)plug and
> memory ballooning, I started questioning the existance of /dev/kmem.
>
> Comparing it with the /proc/kcore implementation, it does not seem to be
> able
Good Day,
Please accept my apologies for writing you a surprise letter.I am
Mr.Mohammed Mashab, account Manager with an investment bank here in
Burkina Faso.I have a very important business I want to discuss with
you.There is a draft account opened in my firm by a long-time client
of our bank.I
crap), another good reason for
kicking it out asap.
But those systems tend to carry a lot of specialized changes anyway, so
they can just add "revert David's patch" to their pile.
Often those kind of people aren't capable of that. If anyone finds such
systems, report them to c
gt; > > > Let's start a discussion if /dev/kmem is worth keeping around and
> > > > fixing/maintaining or if we should just remove it now for good.
> > >
> > > I'll happily do this for the next merge window, but would really want
> > > dist
On 19.03.21 18:33, Sebastian Andrzej Siewior wrote:
On 2021-03-19 10:14:02 [-0700], Linus Torvalds wrote:
On Fri, Mar 19, 2021 at 7:35 AM David Hildenbrand wrote:
Let's start a discussion if /dev/kmem is worth keeping around and
fixing/maintaining or if we should just remove it now for
Supply description for the 'daemon' param too.
Fixes the following W=1 kernel build warning(s):
fs/ecryptfs/miscdev.c:19: warning: cannot understand function prototype:
'atomic_t ecryptfs_num_miscdev_opens; '
fs/ecryptfs/miscdev.c:323: warning: Function parameter or member 'daemon' not
descri
Fixes the following W=1 kernel build warning(s):
fs/ecryptfs/dentry.c:19: warning: Incorrect use of kernel-doc format: *
ecryptfs_d_revalidate - revalidate an ecryptfs dentry
fs/ecryptfs/dentry.c:32: warning: Function parameter or member 'dentry' not
described in 'ecryptfs_d_revalidate'
fs/e
Provide missing param description for 'page_index' too.
Fixes the following W=1 kernel build warning(s):
fs/ecryptfs/read_write.c:16: warning: Incorrect use of kernel-doc format: *
ecryptfs_write_lower
fs/ecryptfs/read_write.c:29: warning: Function parameter or member
'ecryptfs_inode' not de
--
Good day.
Please forgive me for using this means to reach you but I can't think
of any other way of letting you know the urgent matter at hand. A
national of your country who happens to be a customer of our bank
where I work (Ecobank Ghana) was a victim of an auto crash in 2017 and
he
>
> > I was wondering if it would be better to permanently disable /dev/kmem
> > in Kconfig along with a comment "if you really want this thing then
> > email peeps@places with a very good reason why". Let that ride for a
> > year or three then blam.
>
On Wed, Mar 24, 2021 at 12:24:12PM -0700, Andrew Morton wrote:
>
> > Let's remove /dev/kmem, which is unused and obsolete.
>
> I grabbed these. Silently - the cc list is amazing ;)
Thanks, I was going to do so, but your tree is fine with me:
Acked-by: Greg Kroah-Hartman
nfig along with a comment "if you really want this thing then
> email peeps@places with a very good reason why". Let that ride for a
> year or three then blam.
>
> But this is so much more attractive, and it certainly sounds like it's
> worth any damage it might cause.
Acked-by: Michal Hocko
for the series.
Thanks!
--
Michal Hocko
SUSE Labs
> Let's remove /dev/kmem, which is unused and obsolete.
I grabbed these. Silently - the cc list is amazing ;)
I was wondering if it would be better to permanently disable /dev/kmem
in Kconfig along with a comment "if you really want this thing then
email peeps@places with a ver
Exploring /dev/kmem and /dev/mem in the context of memory hot(un)plug and
memory ballooning, I started questioning the existance of /dev/kmem.
Comparing it with the /proc/kcore implementation, it does not seem to be
able to deal with things like
a) Pages unmapped from the direct mapping (e.g., to
s://bugzilla.redhat.com/show_bug.cgi?id=154796
"
RFC -> v1:
- "drivers/char: remove /dev/kmem for good"
-- Add more details to patch description regarding distributions
- "mm/vmalloc: remove vwrite()"
-- Also remove the nommu variant
- Compile-tested on more archs/configs
On 23.03.21 14:16, Greg Kroah-Hartman wrote:
On Fri, Mar 19, 2021 at 03:34:49PM +0100, David Hildenbrand wrote:
Let's start a discussion if /dev/kmem is worth keeping around and
fixing/maintaining or if we should just remove it now for good.
More details / findings in patch #1. Patch #2 a
On Fri, Mar 19, 2021 at 03:34:49PM +0100, David Hildenbrand wrote:
> Let's start a discussion if /dev/kmem is worth keeping around and
> fixing/maintaining or if we should just remove it now for good.
>
> More details / findings in patch #1. Patch #2 and #3 perform minor cl
On Mon, 22 Mar 2021 11:08:47 +0100
David Hildenbrand wrote:
>
> Wonder if "echo c > /proc/sysrq-trigger" already existed and would have
> worked back then. :)
>
>
Looks like sysrq-c was added in 2005:
commit 86b1ae38c0a62 ("kdump: sysrq trigger mechanism for kexec based
crashdumps")
Thus
On Fri 19-03-21 15:34:50, David Hildenbrand wrote:
> Exploring /dev/kmem and /dev/mem in the context of memory hot(un)plug and
> memory ballooning, I started questioning the existance of /dev/kmem.
>
> Comparing it with the /proc/kcore implementation, it does not seem to be
> able to deal with thi
On Fri 19-03-21 10:14:02, Linus Torvalds wrote:
> On Fri, Mar 19, 2021 at 7:35 AM David Hildenbrand wrote:
> >
> > Let's start a discussion if /dev/kmem is worth keeping around and
> > fixing/maintaining or if we should just remove it now for good.
>
> I'
On 19.03.21 19:10, Steven Rostedt wrote:
On Fri, 19 Mar 2021 15:34:49 +0100
David Hildenbrand wrote:
Let's start a discussion if /dev/kmem is worth keeping around and
fixing/maintaining or if we should just remove it now for good.
The last time I used /dev/kmem was in 2003. While in Ge
On 19.03.21 18:14, Linus Torvalds wrote:
On Fri, Mar 19, 2021 at 7:35 AM David Hildenbrand wrote:
Let's start a discussion if /dev/kmem is worth keeping around and
fixing/maintaining or if we should just remove it now for good.
I'll happily do this for the next merge window,
Linus Torvalds writes:
> On Fri, Mar 19, 2021 at 7:35 AM David Hildenbrand wrote:
>>
>> Let's start a discussion if /dev/kmem is worth keeping around and
>> fixing/maintaining or if we should just remove it now for good.
>
> I'll happily do this for the nex
On Fri, 19 Mar 2021 15:34:49 +0100
David Hildenbrand wrote:
> Let's start a discussion if /dev/kmem is worth keeping around and
> fixing/maintaining or if we should just remove it now for good.
The last time I used /dev/kmem was in 2003. While in Germany, my home
firewall (in the US)
On 2021-03-19 10:14:02 [-0700], Linus Torvalds wrote:
> On Fri, Mar 19, 2021 at 7:35 AM David Hildenbrand wrote:
> >
> > Let's start a discussion if /dev/kmem is worth keeping around and
> > fixing/maintaining or if we should just remove it now for good.
>
> I
On Fri, Mar 19, 2021 at 7:35 AM David Hildenbrand wrote:
>
> Let's start a discussion if /dev/kmem is worth keeping around and
> fixing/maintaining or if we should just remove it now for good.
I'll happily do this for the next merge window, but would really want
distros t
On 19.03.21 15:34, David Hildenbrand wrote:
Let's start a discussion if /dev/kmem is worth keeping around and
fixing/maintaining or if we should just remove it now for good.
More details / findings in patch #1. Patch #2 and #3 perform minor cleanups
based on removed /dev/kmem support.
As
Exploring /dev/kmem and /dev/mem in the context of memory hot(un)plug and
memory ballooning, I started questioning the existance of /dev/kmem.
Comparing it with the /proc/kcore implementation, it does not seem to be
able to deal with things like
a) Pages unmapped from the direct mapping (e.g., to
Let's start a discussion if /dev/kmem is worth keeping around and
fixing/maintaining or if we should just remove it now for good.
More details / findings in patch #1. Patch #2 and #3 perform minor cleanups
based on removed /dev/kmem support.
Only compile-tested on x86-64 -- good enoug
On Fri, Mar 19, 2021 at 9:25 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nouveau_ioc32.c:2: warning: Cannot understand *
> file mga_ioc32.c
>
> Cc: Ben Skeggs
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-de...@lists.freedesktop.org
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/nouveau/nouveau_ioc32.c:2: warning: Cannot understand * file
mga_ioc32.c
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
dr
Fixes the following W=1 kernel build warning(s):
drivers/crypto/vmx/vmx.c:23: warning: expecting prototype for Routines
supporting VMX instructions on the Power 8(). Prototype was for p8_init()
instead
Cc: "Breno Leitão"
Cc: Nayna Jain
Cc: Paulo Flabiano Smorigo
Cc: Michael Ellerman
Cc: Be
I am Jim Yang. I am the Operation Manager at China Citic Bank International,
Hong Kong. I do not know if we can work together in transferring US$48.2
million from my bank to your bank account. Finally if you are interested I
shall provide you with more details. Please contact me with this
Email
--
Hello,
>From Mr. Idris Desmond, have you Receive the Fund that was paid to
your account? please, do not hesitate to reply as soon as possible as
to enable this Bank make the balance transfer into your nominated
account. awaiting your urgent notification.
Thanks
Mr. Idris Desmond,
Foreign Remit
Fixes the following W=1 kernel build warning(s):
drivers/crypto/vmx/vmx.c:23: warning: expecting prototype for Routines
supporting VMX instructions on the Power 8(). Prototype was for p8_init()
instead
Cc: "Breno Leitão"
Cc: Nayna Jain
Cc: Paulo Flabiano Smorigo
Cc: Michael Ellerman
Cc: Be
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/nouveau/nouveau_ioc32.c:2: warning: Cannot understand * file
mga_ioc32.c
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
dr
I am Jim Yang. I am the Operation Manager at China Citic Bank International,
Hong Kong. I do not know if we can work together in transferring US$48.2
million from my bank to your bank account. Finally if you are interested I
shall provide you with more details. Please contact me with this
Email
--
Good Day,
My name is Fredrick Idahosa, a registered Forex Broker with ETX
Capital. I am soliciting on behalf of a private Client who held a
Government Position in his Country and wishes to invest the sum of
$10.5 Million [Ten Million, Five Hundred Thousand U.S Dollars] in
viable business
nt. Better rewrite the comment
entirely than just swapping "fucking" with a random word, no?
Got your point , and I do understand "fuck" and "fucking" is so strong word
that it is really difficult to replace with something else.
But..but you suggestion to rewrite t
- Ursprüngliche Mail -
> Von: "Bhaskar Chowdhury"
> An: "Miquel Raynal"
> CC: "richard" , "Vignesh Raghavendra" ,
> "linux-mtd" ,
> "linux-kernel" , "Randy Dunlap"
>
> Gesendet: Freitag, 5. F
sendet: Freitag, 5. Februar 2021 14:36:39
Betreff: Re: [PATCH] drivers: mtd: Better word replace a not so good word in
the file mtd_blkdevs.c
On 14:26 Fri 05 Feb 2021, Miquel Raynal wrote:
Hi Bhaskar,
Bhaskar Chowdhury wrote on Fri, 5 Feb 2021
18:11:51 +0530:
s/fucking/invite/
If you are
x27;t even get the point. Better rewrite the comment
>entirely than just swapping "fucking" with a random word, no?
>
Got your point , and I do understand "fuck" and "fucking" is so strong word
that it is really difficult to replace with something else.
Bu
t a native English speaker but this does not bring any value to
> >my ears. Worse, I don't even get the point. Better rewrite the comment
> >entirely than just swapping "fucking" with a random word, no?
> >
> Got your point , and I do understand "fuck" and
Hi Bhaskar,
Bhaskar Chowdhury wrote on Fri, 5 Feb 2021
18:11:51 +0530:
> s/fucking/invite/
>
>
> Signed-off-by: Bhaskar Chowdhury
> ---
> drivers/mtd/mtd_blkdevs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/mtd_blkdevs.c b/drivers/mtd/mtd_blkdevs.c
On 14:08 Fri 05 Feb 2021, Rafael J. Wysocki wrote:
On Fri, Feb 5, 2021 at 1:55 PM Bhaskar Chowdhury wrote:
s/fucked/messed/
I wouldn't make the changelog so explicit, just say "Use more
appropriate language" or similar.
okay.
Signed-off-by: Bhaskar Chowdhury
---
drivers/cpufreq/power
On Fri, Feb 5, 2021 at 1:55 PM Bhaskar Chowdhury wrote:
>
>
>
> s/fucked/messed/
I wouldn't make the changelog so explicit, just say "Use more
appropriate language" or similar.
>
> Signed-off-by: Bhaskar Chowdhury
> ---
> drivers/cpufreq/powernow-k7.c | 2 +-
> 1 file changed, 1 insertion(+),
s/fucking/messing/
Signed-off-by: Bhaskar Chowdhury
---
drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
index 9de74f41dcd2..bc
s/fucked/messed/
Signed-off-by: Bhaskar Chowdhury
---
drivers/cpufreq/powernow-k7.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/powernow-k7.c b/drivers/cpufreq/powernow-k7.c
index 5d515fc34836..2e114fc75e68 100644
--- a/drivers/cpufreq/powernow-k7.c
+++
s/fucking/invite/
Signed-off-by: Bhaskar Chowdhury
---
drivers/mtd/mtd_blkdevs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/mtd_blkdevs.c b/drivers/mtd/mtd_blkdevs.c
index fb8e12d590a1..756a0995e474 100644
--- a/drivers/mtd/mtd_blkdevs.c
+++ b/drivers/mtd
Fixes the following W=1 kernel build warning(s):
drivers/crypto/vmx/vmx.c:23: warning: expecting prototype for Routines
supporting VMX instructions on the Power 8(). Prototype was for p8_init()
instead
Cc: "Breno Leitão"
Cc: Nayna Jain
Cc: Paulo Flabiano Smorigo
Cc: Michael Ellerman
Cc: Be
Fixes the following W=1 kernel build warning(s):
drivers/crypto/ux500/cryp/cryp_irq.c:21: warning: Function parameter or member
'device_data' not described in 'cryp_enable_irq_src'
drivers/crypto/ux500/cryp/cryp_irq.c:21: warning: Function parameter or member
'irq_src' not described in 'cryp_e
Fixes the following W=1 kernel build warning(s):
drivers/crypto/chelsio/chcr_core.c:2: warning: wrong kernel-doc identifier on
line:
Cc: Ayush Sawal
Cc: Vinay Kumar Yadav
Cc: Rohit Maheshwari
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: Manoj Malviya
Cc: Atul Gupta
Cc: Jitendra Lulla
Cc: M
--
Hello
Can i talk to you please?
Amanda
Hello Sir/Ma,
We are a leading investment company working on project financing
internationally. We grant loan at a low interest rate of 2% RIO per
anum. Kindly revert back if interested for further proceedings and
negotiations.
For further inquiries contact us. calebp
--
Good Day, My name is James Broadbent, I have a genuine business to
transact with you. Please get back to me for more details please it's
very
important.
Thanks,
James Broadbent.
Good News.
I am happy to inform you about my success in getting the fund
transferred under the cooperation of a new partner from India
Presently I am in India for the investment projects
with my new partner with the total money Mean while I didn't forget
all your past efforts and attemp
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/nouveau/nouveau_ioc32.c:2: warning: Cannot understand * file
mga_ioc32.c
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
dr
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/r128/r128_ioc32.c:2: warning: Cannot understand * file
r128_ioc32.c
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/r128/r128_ioc32.c | 2 +-
1 file changed,
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/mga/mga_ioc32.c:2: warning: Cannot understand * file
mga_ioc32.c
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/mga/mga_ioc32.c | 2 +-
1 file changed, 1 in
Hello,
My name is Paul Wagner, a family lawyer for the late Mr. Michael. I
have a suggestion for you regarding my late client Michael. Please
write back to me for more details.
greetings
Paul Wagner
Good Day Dearest One,
I pray this mail finds you in a state of your sound health and
indomitable spirit. Please, I would like to confide in you for your
honesty and truth for progress, I feel quite safe dealing with you in
this important Project.
Let me introduce myself to you, I am MRS.MARIA
Analysing the arabic script written right to left "Al Ilah", we seem to
get La Guad, in latin.
Updated prayer translation. SINO is the only Guad.
It should be a solid background for Fair Pay, and the needed step forward.
https://www.youtube.com/watch?v=gQjHE0WnenA
And really necessary step. L
On Mon, Nov 16, 2020 at 03:37:29PM +, Matthew Wilcox wrote:
> > > Something I believe lockdep is missing is a way to annotate "This lock
> > > will be released by a softirq". If we had lockdep for lock_page(), this
> > > would be a great case to show off. The filesystem locks the page, then
>
On Mon, Nov 16, 2020 at 06:05:47PM +0900, Byungchul Park wrote:
> On Thu, Nov 12, 2020 at 11:58:44PM +0900, Byungchul Park wrote:
> > > > FYI, roughly Lockdep is doing:
> > > >
> > > >1. Dependency check
> > > >2. Lock usage correctness check (including RCU)
> > > >3. IRQ related usage
On Thu, Nov 12, 2020 at 11:01:58AM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/input/misc/wm831x-on.c:30: warning: cannot understand function
> prototype: 'struct wm831x_on '
>
> Cc: Dmitry Torokhov
> Cc: Mark Brown
> Cc: patc...@opensource.cirrus.co
On Thu, Nov 12, 2020 at 11:01:52AM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/input/misc/mc13783-pwrbutton.c:32: warning: cannot understand
> function prototype: 'struct mc13783_pwrb '
>
> Cc: Dmitry Torokhov
> Cc: De Schrijver
> Cc: Felipe Balbi
>
On Mon, 2020-11-09 at 18:21:45 UTC, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/mtd/devices/phram.c:19: warning: Function parameter or member 'fmt'
> not described in 'pr_fmt'
>
> Cc: Miquel Raynal
> Cc: Richard Weinberger
> Cc: Vignesh Raghavendra
> Cc: "
u for good work of God Almighty. I have asked
Almighty God to forgive me and believe he has, because he is a
Merciful God I will be going in for an operation surgery soon.
I decided to donate the sum of ($ 8.1 million DOLLARS) to you for the
good work of God Almighty for you to help the motherles
On Wed, Nov 18, 2020 at 09:45:40AM +0800, Boqun Feng wrote:
> Hi Matthew,
>
> On Mon, Nov 16, 2020 at 03:37:29PM +, Matthew Wilcox wrote:
> [...]
> >
> > It's not just about lockdep for semaphores. Mutexes will spin if the
> > current owner is still running, so to convert an interrupt-releas
Hi Matthew,
On Mon, Nov 16, 2020 at 03:37:29PM +, Matthew Wilcox wrote:
[...]
>
> It's not just about lockdep for semaphores. Mutexes will spin if the
> current owner is still running, so to convert an interrupt-released
> semaphore to a mutex, we need a way to mark the mutex as being releas
On Mon, Nov 16, 2020 at 05:57:57PM +0900, Byungchul Park wrote:
> On Thu, Nov 12, 2020 at 02:52:51PM +, Matthew Wilcox wrote:
> > On Thu, Nov 12, 2020 at 09:26:12AM -0500, Steven Rostedt wrote:
> > > > FYI, roughly Lockdep is doing:
> > > >
> > > >1. Dependency check
> > > >2. Lock usa
eady did exactly the same thing while I was developing cross-release.
> But I'm willing to do it again with the current Lockdep code.
>
> But not today. It's over mid-night. Good night~
>
> --
> Thanks,
> Byungchul
On Thu, Nov 12, 2020 at 02:52:51PM +, Matthew Wilcox wrote:
> On Thu, Nov 12, 2020 at 09:26:12AM -0500, Steven Rostedt wrote:
> > > FYI, roughly Lockdep is doing:
> > >
> > >1. Dependency check
> > >2. Lock usage correctness check (including RCU)
> > >3. IRQ related usage correctne
On Thu, Nov 12, 2020 at 02:56:49PM +0100, Daniel Vetter wrote:
> > > I think I understand it. For things like completions and other "wait for
> > > events" we have lockdep annotation, but it is rather awkward to implement.
> > > Having something that says "lockdep_wait_event()" and
> > > "lockdep_e
ou do not believe that lockdep can handle. If
> lockdep cannot handle it, it will show us where lockdep is lacking. If it
> can handle it, it will educate you on other ways that lockdep can be
> helpful in your development ;-)
Yes. That's the best thing I can do for all of us. I will.
I already did exactly the same thing while I was developing cross-release.
But I'm willing to do it again with the current Lockdep code.
But not today. It's over mid-night. Good night~
--
Thanks,
Byungchul
On Thu, Nov 12, 2020 at 09:26:12AM -0500, Steven Rostedt wrote:
> > FYI, roughly Lockdep is doing:
> >
> >1. Dependency check
> >2. Lock usage correctness check (including RCU)
> >3. IRQ related usage correctness check with IRQFLAGS
> >
> > 2 and 3 should be there forever which is sub
On Thu, 12 Nov 2020 17:10:30 +0900
Byungchul Park wrote:
> 2. Does Lockdep do what a deadlock detection tool should do? From
>internal engine to APIs, all the internal data structure and
>algotithm of Lockdep is only looking at lock(?) acquisition order.
>Fundamentally Lockdep cannot
On Thu, Nov 12, 2020 at 11:33 AM Byungchul Park wrote:
>
> On Wed, Nov 11, 2020 at 09:36:09AM -0500, Steven Rostedt wrote:
> > And this is especially true with lockdep, because lockdep only detects the
> > deadlock, it doesn't tell you which lock was the incorrect locking.
> >
> > For example. If
On 12/11/2020 11:01, Lee Jones wrote:
Fixes the following W=1 kernel build warning(s):
drivers/input/misc/wm831x-on.c:30: warning: cannot understand function
prototype: 'struct wm831x_on '
Cc: Dmitry Torokhov
Cc: Mark Brown
Cc: patc...@opensource.cirrus.com
Cc: linux-in...@vger.kernel.org
Fixes the following W=1 kernel build warning(s):
drivers/input/misc/wm831x-on.c:30: warning: cannot understand function
prototype: 'struct wm831x_on '
Cc: Dmitry Torokhov
Cc: Mark Brown
Cc: patc...@opensource.cirrus.com
Cc: linux-in...@vger.kernel.org
Signed-off-by: Lee Jones
---
drivers/in
Fixes the following W=1 kernel build warning(s):
drivers/input/misc/mc13783-pwrbutton.c:32: warning: cannot understand function
prototype: 'struct mc13783_pwrb '
Cc: Dmitry Torokhov
Cc: De Schrijver
Cc: Felipe Balbi
Cc: linux-in...@vger.kernel.org
Signed-off-by: Lee Jones
---
drivers/input
On Wed, Nov 11, 2020 at 09:36:09AM -0500, Steven Rostedt wrote:
> And this is especially true with lockdep, because lockdep only detects the
> deadlock, it doesn't tell you which lock was the incorrect locking.
>
> For example. If we have a locking chain of:
>
> A -> B -> D
>
> A -> C -> D
>
On Thu, Nov 12, 2020 at 05:51:14PM +0900, Byungchul Park wrote:
> On Thu, Nov 12, 2020 at 03:15:32PM +0900, Byungchul Park wrote:
> > > If on the other hand there's some bug in lockdep itself that causes
> > > excessive false positives, it's better to limit the number of reports
> > > to one per
On Thu, Nov 12, 2020 at 03:15:32PM +0900, Byungchul Park wrote:
> > If on the other hand there's some bug in lockdep itself that causes
> > excessive false positives, it's better to limit the number of reports
> > to one per bootup, so that it's not seen as a nuisance debugging
> > facility.
> >
On Thu, Nov 12, 2020 at 12:16:50AM +0100, Thomas Gleixner wrote:
> Wrappers which make things simpler are always useful, but the lack of
> wrappers does not justify a wholesale replacement.
Totally right. Lack of wrappers doesn't matter at all. That could be
achieved easily by modifying the origin
ixed is
> actually pretty low.
Again, this is true if Lockdep is for checking maintainers' tree only.
> linux-next offers several weeks/months advance integration testing to
> see whether the combination of maintainer trees causes
> problems/warnings.
Good for us.
> >
On Wed, Nov 11 2020 at 09:36, Steven Rostedt wrote:
> Ingo Molnar wrote:
>> Not sure I understand the "problem 2)" outlined here, but I'm looking
>> forward to your patchset!
>>
> I think I understand it. For things like completions and other "wait for
> events" we have lockdep annotation, but i
On Wed, 11 Nov 2020 11:54:41 +0100
Ingo Molnar wrote:
> * Byungchul Park wrote:
>
> > PROBLEM 1) First of all, Lockdep gets disabled on the first detection.
>
> Lockdep disabling itself after the first warning was an intentional
> and deliberate design decision. (See more details below.)
>
* Byungchul Park wrote:
> PROBLEM 1) First of all, Lockdep gets disabled on the first detection.
Lockdep disabling itself after the first warning was an intentional
and deliberate design decision. (See more details below.)
>What if there are more than two problems?
So the usual way this
...
This way we try to detect deadlocks by waits for now. But don't you
think it looks ugly? Are you good if it manages to work by some
means? That even doesn't work correctly. Instead it should look like:
At the interest wait,
...
xxx_wait(X);
1 - 100 of 680 matches
Mail list logo
