LKML.ORG - the Linux Kernel Mailing List Archive

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> <link href="/css/frontpage.css" rel="stylesheet" type="text/css" /> <title>LKML.ORG - the Linux Kernel Mailing List Archive</title> <script type="text/javascript" src="/css/multiline-tooltip.js"></script> <script type="text/javascript">  </script> </head> <body onload="makeNiceTitles()"> <table width="100%"> <tr class="quickbar"> <td width="25%"> <a href="/lkml/last100">Last 100 messages</a> </td> <td width="25%"> <a href="/lkml/today">Today's messages</a> </td> <td width="25%"> <a href="/lkml/yesterday">Yesterday's messages</a> </td> <td width="25%"> <a href="/">LKML Homepage</a> </td> </tr> </table> <div align="center"> <div align="center" style="margin: 1ex 0 1ex"> <script type="text/javascript" src="https://pagead2.googlesyndication.com/pagead/show_ads.js"></script> </div> <table cellspacing="1" cellpadding="0" border="0" bgcolor="#555653"> <tr> <td> <table cellspacing="0" cellpadding="1" border="0" bgcolor="#dde8e8"> <tr> <td colspan="3" align="center" bgcolor="#fbffea"> Hottest messages - half-life = 1 hour </td> </tr> <tr class="c1"> <td>Ilya Dryomov</td> <td>聽</td> <td> <a href="/lkml/2019/9/2/225" title="Ilya Dryomov writes: On Sat, Aug 31, 2019 at 11:57 PM Krzysztof Wilczynski &lt;kw@linux.com&gt; wrote:

e-declaration] 

e-declaration] 

e-declaration] 

len, 

*rawfh, int *max_len, 

 int type; 
Applied. 
Applied. 
Thanks, 
Thanks, 
 Ilya 
 Ilya 
 Ilya 
">Re: [PATCH] ceph: Move static keyword to the front...</a> </td> </tr> <tr class="c0"> <td>Aaron Lu</td> <td>聽</td> <td> <a href="/lkml/2017/2/24/249" title="Aaron Lu writes: (Summary) 55 ++++++++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 59 insertions(+), 8 deletions(-)

diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
index 7eed8cf3130a..07229b48e7f9 100644
--- a/include/asm-generic/tlb.h
+++ b/include/asm-generic/tlb.h
@@ -78,13 +78,9 @@ struct mmu_gather_batch {
 #define MAX_GATHER_BATCH \
 ((PAGE_SIZE - sizeof(struct mmu_gather_batch)) / sizeof(void *))
 
-/*
- * Limit the maximum number of mmu_gather batches to reduce a risk of soft
- * lockups for non-preemptible kernels on huge machines when a lot of memory
- * is zapped during unmapping.
+
+ if (batch_free) {
+ /*
+ * Start a worker to free pages stored
+ * in batches following tlb-&gt;local.
">[PATCH 2/5] mm: parallel free pages</a> </td> </tr> <tr class="c1"> <td>Jiang Liu</td> <td>聽</td> <td> <a href="/lkml/2015/5/20/287" title="Jiang Liu writes: (Summary) 
 
-static void se7343_irq_demux(unsigned int irq, struct irq_desc *desc)
+static void se7343_irq_demux(struct irq_desc *desc)
 {
- struct irq_data *data = irq_get_irq_data(irq);
 }
 
-static void x3proto_gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
+static void x3proto_gpio_irq_handler(struct irq_desc *desc)
 {
- struct irq_data *data = irq_get_irq_data(irq);
 }
 
-static void intc_virq_handler(unsigned int irq, struct irq_desc *desc)
+static void intc_virq_handler(struct irq_desc *desc)
 {
+ unsigned int irq = irq_desc_get_irq(desc);
">[RFC v1 19/25] genirq: Kill the first parameter 'i...</a> </td> </tr> <tr class="c0"> <td>David Cohen</td> <td>聽</td> <td> <a href="/lkml/2014/10/16/735" title="David Cohen writes: (Summary) Hi Bjorn and Sathya, 
 
On Thu, Oct 16, 2014 at 05:42:11PM -0700, sathyanarayanan kuppuswamy wrote:

 
I partially agree :) 
 
Historically, this file was created because we could not build all intel
mid variants at once. Anyway I'm fine. 
 
Br, David 
 

-- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org 
More majordomo info at <a href="http://vger.kernel.org/majordomo-info.html">http://vger.kernel.org/majordomo-info.html</a>
Please read the FAQ at <a href="http://www.tux.org/lkml/">http://www.tux.org/lkml/</a> 
 
 

">Re: [PATCH v1 02/10] x86, intel-mid: Remove "weak"...</a> </td> </tr> <tr class="c1"> <td>Chandra Seetharaman</td> <td>聽</td> <td> <a href="/lkml/2008/7/16/326" title="Chandra Seetharaman writes: (Summary) i++) {
 if (!strncmp(sdev-&gt;vendor, rdac_dev_list[i].vendor,
Index: linux2.6.26-git3/drivers/scsi/device_handler/scsi_dh_emc.c
===================================================================
--- linux2.6.26-git3.orig/drivers/scsi/device_handler/scsi_dh_emc.c
+++ linux2.6.26-git3/drivers/scsi/device_handler/scsi_dh_emc.c
@@ -416,12 +416,17 @@ static int clariion_bus_notify(struct no
 unsigned long action, void *data)
 {
 struct device *dev = data; i++) {
 if (!strncmp(sdev-&gt;vendor, clariion_dev_list[i].vendor,
Index: linux2.6.26-git3/drivers/scsi/device_handler/scsi_dh_hp_sw.c
===================================================================
--- linux2.6.26-git3.orig/drivers/scsi/device_handler/scsi_dh_hp_sw.c
+++ linux2.6.26-git3/drivers/scsi/device_handler/scsi_dh_hp_sw.c
@@ -131,11 +131,16 @@ static int hp_sw_bus_notify(struct notif
 unsigned long action, void *data)
 {
 struct device *dev = data; i++) {
 if (!strncmp(sdev-&gt;vendor, hp_sw_dh_data_list[i].vendor,
---
On We">Re: rdac and aac</a> </td> </tr> <tr class="c0"> <td>Joel Becker</td> <td>聽</td> <td> <a href="/lkml/2008/7/16/301" title="Joel Becker writes: (Summary) On Wed, Jul 16, 2008 at 03:08:21PM +0200, Louis Rilling wrote:

 
 Ok, I'm going to get it to linux-next,then off to Linus for .27.
">Re: [BUGFIX][PATCH v2 0/2] configfs: Fix cleanup a...</a> </td> </tr> <tr class="c1"> <td>Daniel Baluta</td> <td>聽</td> <td> <a href="/lkml/2023/10/9/399" title="Daniel Baluta writes: On Sun, Oct 8, 2023 at 6:30=E2=80=AFAM Hao Ge &lt;gehao@kylinos.cn&gt; wrote:

x_dsp_setup_channels()") 

Signed-off-by: Hao Ge &lt;gehao@kylinos.cn&gt; 
Reviewed-by: Daniel Baluta &lt;daniel.baluta@nxp.com&gt;
Reviewed-by: Daniel Baluta &lt;daniel.baluta@nxp.com&gt;

p.c 

c *dsp_ipc) 

e); 

2.25.1 
2.25.1 
">Re: [PATCH] firmware/imx-dsp: Fix use_after_free i...</a> </td> </tr> <tr class="c0"> <td>AngeloGioacchino Del Regno</td> <td>聽</td> <td> <a href="/lkml/2023/9/5/497" title="AngeloGioacchino Del Regno writes: (Summary) Il 01/09/23 10:09, Tinghan Shen ha scritto: 

to bring-up the 2nd core of the dual-core SCP. 
Whole series is 
Tested-by: AngeloGioacchino Del Regno &lt;angelogioacchino.delregno@collabora.com&gt;
On MT8195 Tomato Chromebook. 
On MT8195 Tomato Chromebook. 

 8 files changed, 656 insertions(+), 146 deletions(-)
 8 files changed, 656 insertions(+), 146 deletions(-)
 8 files changed, 656 insertions(+), 146 deletions(-)

">Re: [PATCH v17 00/14] Add support for MT8195 SCP 2...</a> </td> </tr> <tr class="c1"> <td>Hui Zhu</td> <td>聽</td> <td> <a href="/lkml/2019/9/22/927" title="Hui Zhu writes: (Summary) 
 
+config ZSWAP_IO_SWITCH
+ bool "Compressed cache for swap pages according to the IO status"
+ depends on ZSWAP
+ help
+ This function helps the system that normal swap speed is higher
+ than zswap speed to handle the swap IO issue. When zswap is enabled, pages will
+ be stored to zswap only when the IO in flight number of swap device
+ is bigger than zswap_read_in_flight_limit or
+ zswap_write_in_flight_limit.
">[RFC v3] zswap: Add CONFIG_ZSWAP_IO_SWITCH to hand...</a> </td> </tr> <tr class="c0"> <td>Qii Wang</td> <td>聽</td> <td> <a href="/lkml/2019/3/6/948" title="Qii Wang writes: (Summary) More comments inline. 
I have split this patch into three in V5. 
I have split this patch into three in V5. 

something which shows that we need ltiming. 
ok, I will add a flag(ltiming_adjust) in mtk_i2c_compatible.
ok, I will set it dependent on ltiming_adjust. 
ok, I will set it dependent on ltiming_adjust. 

Matthias 
Yes, old SoCs also have the bit(I2C_ARB_LOST), but there was no need for
multi-master before, so we didn't set it up specifically.
">Re: [PATCH v4 3/3] i2c: mediatek: Add i2c support ...</a> </td> </tr> <tr class="c1"> <td>Andrew Morton</td> <td>聽</td> <td> <a href="/lkml/2017/12/6/1074" title="Andrew Morton writes: (Summary) 
Subject: lib/ubsan.c: don't handle misaligned address when kernel supports unaligned access
Subject: lib/ubsan.c: don't handle misaligned address when kernel supports unaligned access
ubsan reports a warning like: 
ubsan reports a warning like: 
UBSAN: Undefined behaviour in ../include/linux/etherdevice.h:386:9
load of misaligned address ffffffc069ba0482 for type 'long unsigned int'
which requires 8 byte alignment
CPU: 0 PID: 901 Comm: sshd Not tainted 4.xx+ #1
Hardware name: linux,dummy-virt (DT)
Call trace:
[&lt;ffffffc000093600&gt;] dump_backtrace+0x0/0x348
[&lt;ffffffc000093968&gt;] show_stack+0x20/0x30
[&lt;ffffffc001651664&gt;] dump_stack+0x144/0x1b4
[&lt;ffffffc0016519b0&gt;] ubsan_epilogue+0x18/0x74
[&lt;ffffffc001651bac&gt;] __ubsan_handle_type_mismatch+0x1a0/0x25c
[&lt;ffffffc00125d8a0&gt;] dev_gro_receive+0x17d8/0x1830
[&lt;ffffffc00125d928&gt;] napi_gro_receive+0x30/0x158
[&lt;ffffffc000f4f93c&gt;] virtnet_receive+0xad4/0x1fa8

The reason is that when enabling the CONFIG_UBSAN_ALIGNM">Re: [PATCH v2] ubsan: don't handle misaligned addr...</a> </td> </tr> <tr class="c0"> <td>Sudeep Dutt</td> <td>聽</td> <td> <a href="/lkml/2016/2/8/639" title="Sudeep Dutt writes: On Sun, 2016-02-07 at 22:57 -0800, Greg Kroah-Hartman wrote:

 
Hi Greg, 
 
I will clean this up, refresh this patch series against the latest
char-misc-next tree and resend today. 
 
Thanks for reviewing! 
 
Sudeep Dutt 
 
 
">Re: [PATCH char-misc-next 3/8] misc: mic: MIC VOP ...</a> </td> </tr> <tr class="c1"> <td>Dmitry Torokhov</td> <td>聽</td> <td> <a href="/lkml/2015/3/12/870" title="Dmitry Torokhov writes: (Summary) 11 +----------
 1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/char/hw_random/msm-rng.c b/drivers/char/hw_random/msm-rng.c
index cea1c70..96fb986 100644
--- a/drivers/char/hw_random/msm-rng.c
+++ b/drivers/char/hw_random/msm-rng.c
@@ -157,7 +157,7 @@ static int msm_rng_probe(struct platform_device *pdev)
 rng-&gt;hwrng.cleanup = msm_rng_cleanup,
 rng-&gt;hwrng.read = msm_rng_read,
 
- ret = hwrng_register(&amp;rng-&gt;hwrng);
 
 static struct platform_driver msm_rng_driver = {
 .probe = msm_rng_probe,
- .remove = msm_rng_remove,
 .driver = {
 .name = KBUILD_MODNAME,
 .of_match_table = of_match_ptr(msm_rng_of_match),
-- 
2.2.0.rc0.207.ga3a616c
-- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org 
More majordomo info at <a href="http://vger.kernel.org/majordomo-info.html">http://vger.kernel.org/majordomo-info.html</a>
Please read the FAQ at <a href="http://www.tux.org/lkml/">htt">[PATCH 4/6] hwrng: msm - make use of devm_hwrng_re...</a> </td> </tr> <tr class="c0"> <td>lizf@kernel ...</td> <td>聽</td> <td> <a href="/lkml/2014/11/27/171" title="	lizf@kernel ... writes: (Summary) 12 ------------
 1 file changed, 12 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index 307611a..d8e4562 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
@@ -969,8 +969,6 @@ static irqreturn_t ixgbevf_msix_clean_tx(int irq, void *data)
 r_idx = find_first_bit(q_vector-&gt;txr_idx, adapter-&gt;num_tx_queues); i++) {
- rx_ring = &amp;(adapter-&gt;rx_ring[r_idx]);
- r_idx = find_next_bit(q_vector-&gt;rxr_idx, adapter-&gt;num_rx_queues,
- r_idx + 1);
">[PATCH 3.4 90/91] ixgbevf: Prevent RX/TX statistic...</a> </td> </tr> <tr class="c1"> <td>"Rafael J. Wysocki"</td> <td>聽</td> <td> <a href="/lkml/2012/11/13/600" title="Summary not available">[PATCH 0/3 rev 2] Centralized parsing of ACPI devi...</a> </td> </tr> </table> </td> </tr> </table> <div align="center" style="margin: 1ex 0 1ex"> <script type="text/javascript" src="https://pagead2.googlesyndication.com/pagead/show_ads.js"></script> </div> <table cellspacing="1" cellpadding="0" border="0" bgcolor="#555653"> <tr> <td> <table cellspacing="0" cellpadding="1" border="0" bgcolor="#dde8e8"> <tr> <td colspan="3" align="center" bgcolor="#fbffea"> Hottest messages - half-life = 1 day </td> </tr> <tr class="c1"> <td>Linus Torvalds</td> <td>聽</td> <td> <a href="/lkml/2024/1/6/180" title="Linus Torvalds writes: (Summary) Complain to clang people for
being *extra* stupid - we told the compiler that it can use a register
or memory, and clang decided "I'll use memory", so then when we gave
it a memory location, it said "no, not *that* memory - I'll just
reload it on stack". 
reload it on stack". 
In contrast, gcc gets this right - and for that udp.c case it just generates
In contrast, gcc gets this right - and for that udp.c case it just generates
 addl 136(%rax),%ecx # frags_67-&gt;D.58941.D.58869.D.58836.csum, a
 adcl $0,%ecx # a 
 adcl $0,%ecx # a 
like it should. 
like it should. 
And for csum_ipv6_magic, gcc generates this: 
And for csum_ipv6_magic, gcc generates this: 
 addl %edx,%eax # tmp112, a 
 adcl $0,%eax # a 
 adcl $0,%eax # a 
IOW, the kernel is *right*, and this is purely clang being completely bogus.
">Re: x86/csum: Remove unnecessary odd handling</a> </td> </tr> <tr class="c0"> <td>Linus Torvalds</td> <td>聽</td> <td> <a href="/lkml/2025/2/20/2066" title="Linus Torvalds writes: (Summary) They basically become the maintainers of
the Rust interfaces too. 
the Rust interfaces too. 
But maintainers who are taking the "I don't want to deal with Rust"
option also then basically will obviously not have to bother with the
Rust bindings - but as a result they also won't have any say on what
goes on on the Rust side. 
goes on on the Rust side. 
So when you change the C interfaces, the Rust people will have to deal
with the fallout, and will have to fix the Rust bindings.
">Re: Rust kernel policy</a> </td> </tr> <tr class="c1"> <td>Linus Torvalds</td> <td>聽</td> <td> <a href="/lkml/2025/2/6/1292" title="Linus Torvalds writes: (Summary) wrote:

because I'm out of ideas. 
How about you accept the fact that maybe the problem is you.
It has problems, but problems are a fact of life.
It has problems, but problems are a fact of life. The same way it sure as hell
wasn't the solution to politics. 
wasn't the solution to politics. 
Technical patches and discussions matter. Social media brigading - no
than\k you. 
than\k you. 
 Linus 
 Linus 
 Linus 

">Re: On community influencing (was Re: [PATCH v8 2/...</a> </td> </tr> <tr class="c0"> <td>"Theodore Ts'o"</td> <td>聽</td> <td> <a href="/lkml/2021/4/19/907" title="&quot;Theodore Ts'o&quot; writes: (Summary) [ Feel free to forward this to other Linux kernel mailing lists as
 appropriate -- Ted ] 
 appropriate -- Ted ] 
This year, the Maintainers and Kernel Summit is currently planned to
be held in Dublin, Ireland, September 27 -- 29th.
If you were not subscribed on to the kernel@lists.linux-dev mailing
list from last year (or if you had removed yourself from the
ksummit-discuss@lists.linux-foundation.org mailing list after the
previous year's kernel and maintainers' summit summit), you can
subscribe sending an e-mail to: 
subscribe sending an e-mail to: 
 ksummit+subscribe@lists.linux.dev 
 ksummit+subscribe@lists.linux.dev 
The mailing list archive is available at: 
The mailing list archive is available at: 
 <a href="https://lore.kernel.org/ksummit">https://lore.kernel.org/ksummit</a> 
 <a href="https://lore.kernel.org/ksummit">https://lore.kernel.org/ksummit</a> 
The program committee this year is composed of the following people:
The program committee this year is com">Maintainers / Kernel Summit 2021 planning kick-off</a> </td> </tr> <tr class="c1"> <td>Ma Ke</td> <td>聽</td> <td> <a href="/lkml/2025/3/13/340" title="Ma Ke writes: (Summary) Once device_add() failed, we should call put_device() to decrement
reference count for cleanup. If device_add() has
not succeeded, use only put_device() to drop the reference count'.
Found by code review. 
Found by code review. 
Cc: stable@vger.kernel.org 
Fixes: 0cd587735205 ("Input: preallocate memory to hold event values")
Signed-off-by: Ma Ke &lt;make24@iscas.ac.cn&gt; 
---
 drivers/input/input.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/input/input.c b/drivers/input/input.c
index c9e3ac64bcd0..2e70f346dadc 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -2424,6 +2424,7 @@ int input_register_device(struct input_dev *dev)
 err_device_del:
 device_del(&amp;dev-&gt;dev);
">[PATCH] Input: fix error handling in input_registe...</a> </td> </tr> <tr class="c0"> <td>Philipp Zabel</td> <td>聽</td> <td> <a href="/lkml/2025/3/13/349" title="Philipp Zabel writes: (Summary) On Mi, 2025-03-12 at 22:59 +0100, Heiko Stuebner wrote:

tten [-Werror=3Doverride-init] 

0*4 + reg * 16 + bit) 

562_DDRCRU_RESET_OFFSET' 

rk3562_register_offset[173]') 

0*4 + reg * 16 + bit) 

562_DDRCRU_RESET_OFFSET' 

ntel.com/ 

into the clock tree, so this patch should of course also go that way.
regards 
Philipp 
Philipp 
Philipp 

">Re: [PATCH] dt-bindings: reset: fix double id on r...</a> </td> </tr> <tr class="c1"> <td>Steven Rostedt</td> <td>聽</td> <td> <a href="/lkml/2021/6/10/1041" title="Steven Rostedt writes: (Summary) On Thu, 10 Jun 2021 21:20:50 +0100 
Matthew Wilcox &lt;willy@infradead.org&gt; wrote: 

answered for everybody there. 
For presentations, I think this is a very good idea. But it wouldn't
work for a BoF or a microconference. 
work for a BoF or a microconference. 
I also thought about doing this for a presentations. Perhaps instead of going in line to a microphone, go
in line to a public laptop to type in your question.
in line to a public laptop to type in your question.
-- Steve 
-- Steve 
-- Steve 

">Re: Maintainers / Kernel Summit 2021 planning kick...</a> </td> </tr> <tr class="c0"> <td>Linus Torvalds</td> <td>聽</td> <td> <a href="/lkml/2025/2/23/351" title="Linus Torvalds writes: (Summary) But nothing is ever perfect, and you really shouldn't
expect it to be. 
expect it to be. 
At the same time, people harping on some rust issues seem to do so not
because rust is any worse, but because they have internalized our
*normal* issues so much that they don't even think about them.
So next time you want to write an email to complain about rust
support: take a look in the mirror. 
support: take a look in the mirror. 
Is the problem actually the rust code causing you issue, or is the
problem between the keyboard and the chair, and you just want to vent?
">Re: Rust kernel policy</a> </td> </tr> <tr class="c1"> <td>Drew Fustini</td> <td>聽</td> <td> <a href="/lkml/2025/3/13/289" title="Drew Fustini writes: On Tue, Mar 11, 2025 at 06:18:55PM +0100, Michal Wilczynski wrote:

2.34.1 
For the series: 
For the series: 
Acked-by: Drew Fustini &lt;drew@pdp7.com&gt; 
Acked-by: Drew Fustini &lt;drew@pdp7.com&gt; 
Acked-by: Drew Fustini &lt;drew@pdp7.com&gt; 
">Re: [PATCH v8 0/5] TH1520 SoC: Add AON firmware & ...</a> </td> </tr> <tr class="c0"> <td>Kevin Chen</td> <td>聽</td> <td> <a href="/lkml/2025/3/14/735" title="Kevin Chen writes: (Summary) PiBPbiAxMC8wMy8yMDI1IDEyOjQ4LCBLZXZpbiBDaGVuIHdyb3RlOg0KPiA+ICtzdGF0aWMgaW50
IGFzcGVlZF9wY2NfcHJvYmUoc3RydWN0IHBsYXRmb3JtX2RldmljZSAqcGRldikgew0KPiA+ICsJ
aW50IHJjOw0KPiA+ICsJc3RydWN0IGFzcGVlZF9wY2NfY3RybCAqcGNjOw0KPiA+ICsJc3RydWN0
IGRldmljZSAqZGV2ID0gJnBkZXYtPmRldjsNCj4gPiArCXVpbnQzMl90IGZpZm9fc2l6ZSA9IFBB
R0VfU0laRTsNCj4gPiArDQo+ID4gKwlwY2MgPSBkZXZtX2t6YWxsb2MoZGV2LCBzaXplb2YoKnBj
YyksIEdGUF9LRVJORUwpOw0KPiA+ICsJaWYgKCFwY2MpDQo+ID4gKwkJcmV0dXJuIC1FTk9NRU07
DQo+ID4gKw0KPiA+ICsJcGNjLT5yZWdtYXAgPSBzeXNjb25fbm9kZV90b19yZWdtYXAoZGV2LT5w
YXJlbnQtPm9mX25vZGUpOw0KPiA+ICsJaWYgKElTX0VSUihwY2MtPnJlZ21hcCkpIHsNCj4gPiAr
CQlkZXZfZXJyKGRldiwgIkNvdWxkbid0IGdldCByZWdtYXBcbiIpOw0KPiANCj4gcmV0dXJuIGRl
dl9lcnJfcHJvYmUoKSBpcyBub3Qgc3VpdGFibGU/DQpBZ3JlZS4gQ2hhbmdlIHRvICIgZGV2X2Vy
cl9wcm9iZShkZXYsIFBUUl9FUlIocGNjLT5yZWdtYXApLCJDb3VsZG4ndCBnZXQgcmVnbWFwXG4i
KTsiPw0KDQo+IA0KPiA+ICsJCXJldHVybiAtRU5PREVWOw0KPiANCj4gV2h5IG92ZXJyaWRpbmcg
ZXJyb3IgY29kZT8NCg0KPiANCj4gPiArCX0NCj4gPiArDQo+ID4gKwlyYyA9IG9mX3Byb3BlcnR5
X3JlYWRfdTMyKGRldi0+b2Z">RE: [PATCH v3 3/3] soc: aspeed: lpc-pcc: Add PCC c...</a> </td> </tr> <tr class="c1"> <td>Cristian Marussi</td> <td>聽</td> <td> <a href="/lkml/2024/1/25/1045" title="Cristian Marussi writes: (Summary) 
Add a check and bail out early on remove too. 
Add a check and bail out early on remove too. 
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008
Mem abort info:
 ESR = 0x0000000096000004
 EC = 0x25: DABT (current EL), IL = 32 bits
 SET = 0, FnV = 0
 EA = 0, S1PTW = 0
 FSC = 0x04: level 0 translation fault
 Data abort info:
 ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
 CM = 0, WnR = 0, TnD = 0, TagAccess = 0
 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
 user pgtable: 4k pages, 48-bit VAs, pgdp=00000001076e5000
 [0000000000000008] pgd=0000000000000000, p4d=0000000000000000
 Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
 Modules linked in: scmi_perf_domain(-) scmi_module scmi_core
 CPU: 0 PID: 231 Comm: rmmod Not tainted 6.7.0-00084-gb4b1f27d3b83-dirty #15
 Hardware name: linux,dummy-virt (DT)
 pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
 pc : scmi_perf_domain_remove+0x28/0x70 [scmi_perf_domain]
 lr : scmi_perf_domain_r">[PATCH] pmdomain: arm: Fix NULL dereference on scm...</a> </td> </tr> <tr class="c0"> <td>"tip-bot2 for Ard Biesheuvel"</td> <td>聽</td> <td> <a href="/lkml/2025/3/7/1883" title="&quot;tip-bot2 for Ard Biesheuvel&quot; writes: (Summary) 
-
-/*----------------------------------------------------------------------*/
-
-static const u32 crctab32[] = {
- 0x00000000, 0x77073096, 0xee0e612c, 0x990951ba, 0x076dc419,
- 0x706af48f, 0xe963a535, 0x9e6495a3, 0x0edb8832, 0x79dcb8a4,
- 0xe0d5e91e, 0x97d2d988, 0x09b64c2b, 0x7eb17cbd, 0xe7b82d07,
- 0x90bf1d91, 0x1db71064, 0x6ab020f2, 0xf3b97148, 0x84be41de,
- 0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7, 0x136c9856,
- 0x646ba8c0, 0xfd62f97a, 0x8a65c9ec, 0x14015c4f, 0x63066cd9,
- 0xfa0f3d63, 0x8d080df5, 0x3b6e20c8, 0x4c69105e, 0xd56041e4,
- 0xa2677172, 0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b,
- 0x35b5a8fa, 0x42b2986c, 0xdbbbc9d6, 0xacbcf940, 0x32d86ce3,
- 0x45df5c75, 0xdcd60dcf, 0xabd13d59, 0x26d930ac, 0x51de003a,
- 0xc8d75180, 0xbfd06116, 0x21b4f4b5, 0x56b3c423, 0xcfba9599,
- 0xb8bda50f, 0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924,
- 0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d, 0x76dc4190,
- 0x01db7106, 0x98d220bc, 0xefd5102a, 0x71b18589, 0x06b6b51f,
- 0x9fbfe4a5, 0xe8b8d433, 0x7807c9a2, 0x0f">[tip: x86/build] x86/boot: Drop CRC-32 checksum an...</a> </td> </tr> <tr class="c1"> <td>Davidlohr Bueso</td> <td>聽</td> <td> <a href="/lkml/2025/3/13/1226" title="Davidlohr Bueso writes: (Summary) 

&gt;+
&gt;+ /* If the page was hot a while ago, don't promote */
&gt;+ if ((now - phi-&gt;last_update) &gt;
&gt;+ }
&gt;+
&gt;+ /* If the page hasn't been accessed enough number of times, don't promote */
&gt;+ if (phi-&gt;frequency &lt;

See <a href="https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=c6a566f6c1b4d5dff659acd221f95a72923f4085">https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=c6a566f6c1b4d5dff659acd221f95a72923f4085</a>

&gt;+
&gt;+ while (!kthread_should_stop()) {
&gt;+ wait_event_timeout(pgdat-&gt;kpromoted_wait,
&gt;+ kpromoted_work_requested(pgdat), timeout);
">Re: [RFC PATCH 2/4] mm: kpromoted: Hot page info c...</a> </td> </tr> <tr class="c0"> <td>Thomas Gleixner</td> <td>聽</td> <td> <a href="/lkml/2025/3/12/500" title="Thomas Gleixner writes: (Summary) 
Delta patch below. 
Delta patch below. 
Thanks, 
Thanks, 
 tglx 
---
--- a/include/uapi/linux/prctl.h
+++ b/include/uapi/linux/prctl.h
@@ -362,5 +362,6 @@ struct prctl_mm_map {
 #define PR_TIMER_CREATE_RESTORE_IDS 77
 # define PR_TIMER_CREATE_RESTORE_IDS_OFF 0
 # define PR_TIMER_CREATE_RESTORE_IDS_ON 1
+# define PR_TIMER_CREATE_RESTORE_IDS_GET 2
 
 #endif /* _LINUX_PRCTL_H */
--- a/kernel/time/posix-timers.c
+++ b/kernel/time/posix-timers.c
@@ -391,11 +391,17 @@ static enum hrtimer_restart posix_timer_
 
 long posixtimer_create_prctl(unsigned long ctrl)
 {
- if (ctrl &gt;
">Re: [patch V3a 17/18] posix-timers: Provide a mech...</a> </td> </tr> <tr class="c1"> <td>Aradhya Bhatia</td> <td>聽</td> <td> <a href="/lkml/2025/3/11/185" title="Aradhya Bhatia writes: Hi, 
Hi, 
All the patches within this series have been reviewed.
Are there any more concerns that should be taken care of?
Are there any more concerns that should be taken care of?
Are there any more concerns that should be taken care of?
On 26/02/25 21:22, Aradhya Bhatia wrote: 

base-commit: 8433c776e1eb1371f5cd40b5fd3a61f9c7b7f3ad

">Re: [PATCH v10 00/13] drm/bridge: cdns-dsi: Fix th...</a> </td> </tr> <tr class="c0"> <td>Hector Martin</td> <td>聽</td> <td> <a href="/lkml/2025/2/7/9" title="Hector Martin writes: (Summary) I no longer have any faith left in the kernel development process or
community management approach. 
community management approach. 
Apple/ARM platform development will continue downstream. 1 -
 1 file changed, 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 1e930c7a58b13d8bbe6bf133ba7b36aa24c2b5e0..c9623439998709c9d6d6944cbd87e025356422da 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2177,7 +2177,6 @@ F: sound/soc/codecs/cs42l84.*
 F: sound/soc/codecs/ssm3515.c
 
 ARM/APPLE MACHINE SUPPORT
-M: Hector Martin &lt;marcan@marcan.st&gt;
">[PATCH] MAINTAINERS: Remove myself</a> </td> </tr> <tr class="c1"> <td>Alejandro Colomar</td> <td>聽</td> <td> <a href="/lkml/2025/3/7/1714" title="Alejandro Colomar writes: (Summary) 
And thanks to our sponsors! 
And thanks to our sponsors! 
 - Adfinis &lt;<a href="https://adfinis.com/&gt;">https://adfinis.com/&gt;</a> 
 - Google &lt;<a href="https://opensource.google/&gt;">https://opensource.google/&gt;</a> 
 - Hudson River Trading &lt;<a href="https://www.hudsonrivertrading.com/&gt;">https://www.hudsonrivertrading.com/&gt;</a>
 - Meta &lt;<a href="https://www.meta.com/&gt;">https://www.meta.com/&gt;</a> 
 - Red Hat &lt;<a href="https://www.redhat.com/&gt;">https://www.redhat.com/&gt;</a> 
 - Red Hat &lt;<a href="https://www.redhat.com/&gt;">https://www.redhat.com/&gt;</a> 
Have a lovely day! 
Alex 
Alex 
Alex 
You are receiving this message either because: 
You are receiving this message either because: 
 a) (BCC) You contributed to this release. 
 a) (BCC) You contributed to this release. 
 b) You are subscribed to &lt;linux-man@vger.kernel.org&gt;,
 &lt;linux-kernel@vger.kernel.o">man-pages-6.13 released</a> </td> </tr> <tr class="c0"> <td>Kees Cook</td> <td>聽</td> <td> <a href="/lkml/2025/3/10/1641" title="Kees Cook writes: (Summary) 3 +++
 2 files changed, 15 insertions(+)

diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index 981cc3d7e3aa..7ccea700b46d 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -348,6 +348,18 @@ struct ftrace_likely_data {
 # define __counted_by(member)
 #endif
 
+/*
+ * Optional: only supported since gcc &gt;= 15
+ * Optional: not supported by Clang
+ *
+ * gcc: <a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178">https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178</a>
+ */
+#ifdef CONFIG_CC_HAS_MULTIDIMENSIONAL_NONSTRING
+# define __nonstring_array __attribute__((__nonstring__))
+#else
+# define __nonstring_array
+#endif
+
 /*
 * Apply __counted_by() when the Endianness matches to increase test coverage.
">[PATCH] compiler_types: Introduce __nonstring_arra...</a> </td> </tr> <tr class="c1"> <td>Borislav Petkov</td> <td>聽</td> <td> <a href="/lkml/2025/3/12/371" title="Borislav Petkov writes: On Tue, Mar 11, 2025 at 02:13:56PM +0100, Borislav Petkov wrote:

Lemme run randbuilds with that one, see what else breaks with it.
Yeah, looks good. 
Yeah, looks good. 
Pls send a proper patch. 
Pls send a proper patch. 
Thx. 
Thx. 

">Re: [PATCH] x86/stackprotector: fix build failure ...</a> </td> </tr> <tr class="c0"> <td>Madadi Vineeth Reddy</td> <td>聽</td> <td> <a href="/lkml/2025/3/12/1138" title="Madadi Vineeth Reddy writes: ">Re: [PATCH RESEND] sched: Fix incorrect runnable t...</a> </td> </tr> </table> </td> </tr> </table> <div align="center" style="margin: 1ex 0 1ex"> <script type="text/javascript" src="https://pagead2.googlesyndication.com/pagead/show_ads.js"></script> </div> <table cellspacing="1" cellpadding="0" border="0" bgcolor="#555653"> <tr> <td> <table cellspacing="0" cellpadding="1" border="0" bgcolor="#dde8e8"> <tr> <td colspan="3" align="center" bgcolor="#fbffea"> Hottest messages - half-life = 1 month </td> </tr> <tr class="c1"> <td>Hector Martin</td> <td>聽</td> <td> <a href="/lkml/2025/2/7/9" title="Hector Martin writes: (Summary) I no longer have any faith left in the kernel development process or
community management approach. 
community management approach. 
Apple/ARM platform development will continue downstream. 1 -
 1 file changed, 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 1e930c7a58b13d8bbe6bf133ba7b36aa24c2b5e0..c9623439998709c9d6d6944cbd87e025356422da 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2177,7 +2177,6 @@ F: sound/soc/codecs/cs42l84.*
 F: sound/soc/codecs/ssm3515.c
 
 ARM/APPLE MACHINE SUPPORT
-M: Hector Martin &lt;marcan@marcan.st&gt;
">[PATCH] MAINTAINERS: Remove myself</a> </td> </tr> <tr class="c0"> <td>Linus Torvalds</td> <td>聽</td> <td> <a href="/lkml/2025/2/6/1292" title="Linus Torvalds writes: (Summary) wrote:

because I'm out of ideas. 
How about you accept the fact that maybe the problem is you.
It has problems, but problems are a fact of life.
It has problems, but problems are a fact of life. The same way it sure as hell
wasn't the solution to politics. 
wasn't the solution to politics. 
Technical patches and discussions matter. Social media brigading - no
than\k you. 
than\k you. 
 Linus 
 Linus 
 Linus 

">Re: On community influencing (was Re: [PATCH v8 2/...</a> </td> </tr> <tr class="c1"> <td>Linus Torvalds</td> <td>聽</td> <td> <a href="/lkml/2025/2/20/2066" title="Linus Torvalds writes: (Summary) They basically become the maintainers of
the Rust interfaces too. 
the Rust interfaces too. 
But maintainers who are taking the "I don't want to deal with Rust"
option also then basically will obviously not have to bother with the
Rust bindings - but as a result they also won't have any say on what
goes on on the Rust side. 
goes on on the Rust side. 
So when you change the C interfaces, the Rust people will have to deal
with the fallout, and will have to fix the Rust bindings.
">Re: Rust kernel policy</a> </td> </tr> <tr class="c0"> <td>Linus Torvalds</td> <td>聽</td> <td> <a href="/lkml/2024/1/6/180" title="Linus Torvalds writes: (Summary) Complain to clang people for
being *extra* stupid - we told the compiler that it can use a register
or memory, and clang decided "I'll use memory", so then when we gave
it a memory location, it said "no, not *that* memory - I'll just
reload it on stack". 
reload it on stack". 
In contrast, gcc gets this right - and for that udp.c case it just generates
In contrast, gcc gets this right - and for that udp.c case it just generates
 addl 136(%rax),%ecx # frags_67-&gt;D.58941.D.58869.D.58836.csum, a
 adcl $0,%ecx # a 
 adcl $0,%ecx # a 
like it should. 
like it should. 
And for csum_ipv6_magic, gcc generates this: 
And for csum_ipv6_magic, gcc generates this: 
 addl %edx,%eax # tmp112, a 
 adcl $0,%eax # a 
 adcl $0,%eax # a 
IOW, the kernel is *right*, and this is purely clang being completely bogus.
">Re: x86/csum: Remove unnecessary odd handling</a> </td> </tr> <tr class="c1"> <td>Hector Martin</td> <td>聽</td> <td> <a href="/lkml/2025/2/6/404" title="Hector Martin writes: (Summary) On 2025/02/06 5:36, Dave Airlie wrote: 

Dave. 
I'm tired. 
I'm tired. 
I'm tired of seeing positive, technically impressive kernel projects
blockaded delayed by maintainers with no technical justification, and at
best end up moving along at a glacial pace. 
best end up moving along at a glacial pace. 
I'm tired of seeing important contributors and maintainers give up and
throw the towel after enduring repeated misbehavior and hostility
towards their efforts from others. 
towards their efforts from others. 
I'm tired of getting messages, privately and publicly, from all kinds of
people, saying they won't touch the kernel with a 10-foot pole due to
the hostility and the baroque, regressive process. 
the hostility and the baroque, regressive process. 
I'm tired of seeing people get away with using words like "cancer" to
describe others' work, with zero repercussion. 
describe others' work, with zero repercussion. 
I'm tired of *politely and calmly* cal">Re: On community influencing (was Re: [PATCH v8 2/...</a> </td> </tr> <tr class="c0"> <td>Abdiel Janulgue</td> <td>聽</td> <td> <a href="/lkml/2025/1/8/801" title="Abdiel Janulgue writes: (Summary) 
- Reintroduce r/w helpers instead which includes proper safety
 invariants (Daniel Almeida). 
- Link to v7: <a href="https://lore.kernel.org/lkml/20241210221603.3174929-1-abdiel.janulgue@gmail.com/">https://lore.kernel.org/lkml/20241210221603.3174929-1-abdiel.janulgue@gmail.com/</a>
- Link to v7: <a href="https://lore.kernel.org/lkml/20241210221603.3174929-1-abdiel.janulgue@gmail.com/">https://lore.kernel.org/lkml/20241210221603.3174929-1-abdiel.janulgue@gmail.com/</a>
Changes since v6: 
- Include the dma_attrs in the constructor, use alloc::Flags as inpiration
- Include the dma_attrs in the constructor, use alloc::Flags as inpiration
Changes since v5: 
- Remove unnecessary lifetime annotation when returning the CPU buffer.
">[PATCH v8 0/2] Add dma coherent allocator abstract...</a> </td> </tr> <tr class="c1"> <td>Neal Gompa</td> <td>聽</td> <td> <a href="/lkml/2025/2/6/1440" title="Neal Gompa writes: (Summary) I hope
that there's some reflection on both sides and there's an opportunity
in the future to rekindle and improve the relationship between the
Linux kernel project and Asahi Linux contributors. 
Linux kernel project and Asahi Linux contributors. 
Linux kernel project and Asahi Linux contributors. 
Linux kernel project and Asahi Linux contributors. 
-- 
=E7=9C=9F=E5=AE=9F=E3=81=AF=E3=81=84=E3=81=A4=E3=82=82=E4=B8=80=E3=81=A4=EF=
=BC=81/ Always, there's only one truth! 
=BC=81/ Always, there's only one truth! 
=BC=81/ Always, there's only one truth! 

">Re: [PATCH] MAINTAINERS: Remove myself</a> </td> </tr> <tr class="c0"> <td>Nick Chan</td> <td>聽</td> <td> <a href="/lkml/2025/2/7/222" title="Nick Chan writes: ">Re: [PATCH] MAINTAINERS: Remove myself</a> </td> </tr> <tr class="c1"> <td>"Dr. Greg"</td> <td>聽</td> <td> <a href="/lkml/2025/2/7/755" title="&quot;Dr. Greg&quot; writes: (Summary) On Thu, Feb 06, 2025 at 09:58:36AM -0800, Linus Torvalds wrote:
On Thu, Feb 06, 2025 at 09:58:36AM -0800, Linus Torvalds wrote:
Good morning to everyone. 
Good morning to everyone. 

because I'm out of ideas. 

thank you. 
I truely wish that technical patches and discussions were the currency
that matter but I believe we are struggling with that, at least in
some venues in the kernel development process. 
some venues in the kernel development process. 
No one should construe that statement as an endorsement of berating
people on social media as the 'fix'. 
people on social media as the 'fix'. 
I come at this from the perspective of having worked on Linux since
around December of 1991.
">Re: On community influencing (was Re: [PATCH v8 2/...</a> </td> </tr> <tr class="c0"> <td>Steven Rostedt</td> <td>聽</td> <td> <a href="/lkml/2021/6/10/1041" title="Steven Rostedt writes: (Summary) On Thu, 10 Jun 2021 21:20:50 +0100 
Matthew Wilcox &lt;willy@infradead.org&gt; wrote: 

answered for everybody there. 
For presentations, I think this is a very good idea. But it wouldn't
work for a BoF or a microconference. 
work for a BoF or a microconference. 
I also thought about doing this for a presentations. Perhaps instead of going in line to a microphone, go
in line to a public laptop to type in your question.
in line to a public laptop to type in your question.
-- Steve 
-- Steve 
-- Steve 

">Re: Maintainers / Kernel Summit 2021 planning kick...</a> </td> </tr> <tr class="c1"> <td>Evelyn Harthbrooke</td> <td>聽</td> <td> <a href="/lkml/2025/2/7/1036" title="Evelyn Harthbrooke writes: ">Re: [PATCH] MAINTAINERS: Remove myself</a> </td> </tr> <tr class="c0"> <td>Linus Torvalds</td> <td>聽</td> <td> <a href="/lkml/2025/2/23/351" title="Linus Torvalds writes: (Summary) But nothing is ever perfect, and you really shouldn't
expect it to be. 
expect it to be. 
At the same time, people harping on some rust issues seem to do so not
because rust is any worse, but because they have internalized our
*normal* issues so much that they don't even think about them.
So next time you want to write an email to complain about rust
support: take a look in the mirror. 
support: take a look in the mirror. 
Is the problem actually the rust code causing you issue, or is the
problem between the keyboard and the chair, and you just want to vent?
">Re: Rust kernel policy</a> </td> </tr> <tr class="c1"> <td>Linus Torvalds</td> <td>聽</td> <td> <a href="/lkml/2013/4/14/107" title="Linus Torvalds writes: (Summary) 
 
Huacai Chen (1): 
 PM / reboot: call syscore_shutdown() after disable_nonboot_cpus()
 
Jan Kiszka (1): 
 ftrace: Consistently restore trace function on sysctl enabling
 
Jens Axboe (2): 
 mtip32xx: fix two smatch warnings 
 Revert "loop: cleanup partitions when detaching loop device"
 
Jiri Pirko (2): 
 net: ipv4: reset check_lifetime_work after changing lifetime
 net: ipv4: fix schedule while atomic bug in check_lifetime()
 
Joe Carnuccio (1): 
 [SCSI] Revert "qla2xxx: Add setting of driver version string for
vendor application." 
 
Joe Lawrence (1): 
 [SCSI] st: Take additional queue ref in st_probe 
 
John Gong (1): 
 [SCSI] libsas: use right function to alloc smp response
 
Joonyoung Shim (1): 
 ASoC: core: Fix to check return value of snd_soc_update_bits_lock=
ed() 
 
Josef Bacik (1): 
 Btrfs: make sure nbytes are right after log replay 
 
Jussi Kivilin">Linux 3.9-rc7</a> </td> </tr> <tr class="c0"> <td>Linus Torvalds</td> <td>聽</td> <td> <a href="/lkml/2022/9/19/1105" title="Linus Torvalds writes: (Summary) 
You need to realize that 
You need to realize that 
 (a) reality trumps fantasy 
 (a) reality trumps fantasy 
 (b) kernel needs trump any Rust needs 
 (b) kernel needs trump any Rust needs 
And the *reality* is that there are no absolute guarantees.
In the kernel, "panic and stop" is not an option (it's actively worse
than even the wrong answer, since it's really not debugable), so the
kernel version of "panic" is "WARN_ON_ONCE()" and continue with the
wrong answer. 
wrong answer. 
So this is something that I really *need* the Rust people to
understand.
">Re: [PATCH v9 12/27] rust: add `kernel` crate</a> </td> </tr> <tr class="c1"> <td>Linus Torvalds</td> <td>聽</td> <td> <a href="/lkml/2012/12/23/75" title="Linus Torvalds writes: (Summary) wrote: 

 
Mauro, SHUT THE FUCK UP! 
 
It's a bug alright - in the kernel. ioctl's are done
on files that have already been opened, there's no way in hell that
ENOENT would ever be valid. 
 

 
Shut up, Mauro. And you've shown
yourself to not be competent in this issue, so I'll apply it directly
and immediately myself. 
 
WE DO NOT BREAK USERSPACE! 
 
Seriously.
And fix your approach to kernel programming. 
 
 Linus 
-- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org 
More majordomo info at <a href="http://vger.kernel.org/majordomo-info.html">http://vger.kernel.org/majordomo-info.html</a>
Please read the FAQ at <a href="http://www.tux.org/lkml/">http://www.tux.org/lkml/</a> 
 
 

">Re: [Regression w/ patch] Media commit causes user...</a> </td> </tr> <tr class="c0"> <td>"Theodore Ts'o"</td> <td>聽</td> <td> <a href="/lkml/2021/4/19/907" title="&quot;Theodore Ts'o&quot; writes: (Summary) [ Feel free to forward this to other Linux kernel mailing lists as
 appropriate -- Ted ] 
 appropriate -- Ted ] 
This year, the Maintainers and Kernel Summit is currently planned to
be held in Dublin, Ireland, September 27 -- 29th.
If you were not subscribed on to the kernel@lists.linux-dev mailing
list from last year (or if you had removed yourself from the
ksummit-discuss@lists.linux-foundation.org mailing list after the
previous year's kernel and maintainers' summit summit), you can
subscribe sending an e-mail to: 
subscribe sending an e-mail to: 
 ksummit+subscribe@lists.linux.dev 
 ksummit+subscribe@lists.linux.dev 
The mailing list archive is available at: 
The mailing list archive is available at: 
 <a href="https://lore.kernel.org/ksummit">https://lore.kernel.org/ksummit</a> 
 <a href="https://lore.kernel.org/ksummit">https://lore.kernel.org/ksummit</a> 
The program committee this year is composed of the following people:
The program committee this year is com">Maintainers / Kernel Summit 2021 planning kick-off</a> </td> </tr> <tr class="c1"> <td>Christoph Hellwig</td> <td>聽</td> <td> <a href="/lkml/2025/1/8/951" title="Christoph Hellwig writes: No rust code in kernel/dma, please. 
No rust code in kernel/dma, please. 
No rust code in kernel/dma, please. 
No rust code in kernel/dma, please. 
">Re: [PATCH v8 2/2] rust: add dma coherent allocato...</a> </td> </tr> <tr class="c0"> <td>Linus Torvalds</td> <td>聽</td> <td> <a href="/lkml/2024/11/17/326" title="Linus Torvalds writes: (Summary) Silva (1):
 integrity: Use static_assert() to check struct sizes

Hajime Tazaki (1):
 nommu: pass NULL argument to vma_iter_prealloc()

Hamish Claxton (1):
 drm/amd/display: Fix failure to read vram info due to static BP_RESUL=
T

Hangbin Liu (2):
 bonding: add ns target multicast address to slave device
 selftests: bonding: add ns multicast group testing

Harith G (2):
 ARM: 9419/1: mm: Fix kernel memory mapping for xip kernels
 ARM: 9420/1: smp: Fix SMP for xip kernels

Hou Tao (1):
 selftests/bpf: Use -4095 as the bad address for bits iterator

Huacai Chen (4):
 LoongArch: For all possible CPUs setup logical-physical CPU mapping
 LoongArch: Fix early_numa_add_cpu() usage for FDT systems
 LoongArch: Make KASAN work with 5-level page-tables
 LoongArch: Disable KASAN if PGDIR_SIZE is too large for cpu_vabits

Hugh Dickins (1):
 mm/thp: fix deferred split queue not partially_mapped: fix

Hyunwoo Kim (1):
 vsock/virtio: Initialization of the">Linux 6.12</a> </td> </tr> <tr class="c1"> <td>Serge Semin</td> <td>聽</td> <td> <a href="/lkml/2024/10/24/177" title="Serge Semin writes: (Summary) Thank you for your time and experience I've got from
the reviews. 
the reviews. 
Paul, Thomas, Arnd, Jiaxun, we met several times in the mailing list during my
MIPS P5600 patches and just generic MIPS patches review. It means a lot. 
A little bit statics of my kernel-work at the end: 
A little bit statics of my kernel-work at the end: 
Signed-off patches: 518 
Reviewed and Acked patches: 253 
Tested patches: 80 
Tested patches: 80 
You might say not the greatest achievement for seven years comparing to some
other developers.
">linux: Goodbye from a Linux community volunteer</a> </td> </tr> <tr class="c0"> <td>Christoph Hellwig</td> <td>聽</td> <td> <a href="/lkml/2025/2/18/1309" title="Christoph Hellwig writes: (Summary) (He did so in private in case you
are looking for a reference). 
are looking for a reference). 
So as of now, as a Linux developer or maintainer you must deal with
Rust if you want to or not. 
Rust if you want to or not. 
Where Rust code doesn't just mean Rust code [1] - the bindings look
nothing like idiomatic Rust code, they are very different kind of beast
trying to bridge a huge semantic gap.
[1] I've written and worked on a fair bit of userspace Rust code, but
I'm not an expert by any means, so take this with a grain of salt
I'm not an expert by any means, so take this with a grain of salt
[2] The idea of drivers in eBPF as done by HID also really doesn't help
with that as much as I like eBPF for some use cases
with that as much as I like eBPF for some use cases
[3] Unless Linus forces it onto your subsystem, or Dave decides anything
touching Nvidia hardware must be in Rust of course 
touching Nvidia hardware must be in Rust of course 
touching Nvidia hardware must be in Rust of">Re: Rust kernel policy</a> </td> </tr> <tr class="c1"> <td>Christoph Hellwig</td> <td>聽</td> <td> <a href="/lkml/2025/1/8/1086" title="Christoph Hellwig writes: ">Re: [PATCH v8 2/2] rust: add dma coherent allocato...</a> </td> </tr> <tr class="c0"> <td>Abdiel Janulgue</td> <td>聽</td> <td> <a href="/lkml/2025/1/8/803" title="Abdiel Janulgue writes: (Summary) C header: [`include/linux/dma-mapping.h`](srctree/include/linux/dma-mapping.h)
+
+use crate::{
+ bindings, build_assert,
+ device::Device,
+ error::code::*,
+ error::Result,
+ transmute::{AsBytes, FromBytes},
+ types::ARef,
+}; {
+ dev: ARef&lt;Device&gt;,
+ dma_handle: bindings::dma_addr_t,
+ count: usize,
+ cpu_addr: *mut T,
+ dma_attrs: Attrs,
+}
+
+impl&lt;T: AsBytes + FromBytes&gt;
+ unsafe {
+ bindings::dma_free_attrs(
+ self.dev.as_raw(),
+ size,
+ self.cpu_addr as _,
+ self.dma_handle,
+ self.dma_attrs.as_raw(),
+ )
+ }
+ }
+}
diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
index e1065a7551a3..6e90ebf5a130 100644
--- a/rust/kernel/lib.rs
+++ b/rust/kernel/lib.rs
@@ -35,6 +35,7 @@
 mod build_assert;
">[PATCH v8 2/2] rust: add dma coherent allocator ab...</a> </td> </tr> <tr class="c1"> <td>Hector Martin</td> <td>聽</td> <td> <a href="/lkml/2025/2/4/8" title="Hector Martin writes: (Summary) 

On 2025/01/31 22:54, Jason Gunthorpe wrote: 

rejecting PRs that fail to build. 
Adding Linus 
Adding Linus 
My 2c: If Linus doesn't pipe up with an authoritative answer to this
thread, Miguel and the other Rust folks should just merge this series
once it is reviewed and ready, ignoring Christoph's overt attempt at
sabotaging the project.
FWIW, in my opinion, the "cancer" comment from Christoph would be enough
to qualify for Code-of-Conduct action, but I doubt anything of the sort
will happen. 
will happen. 

Jason 
- Hector 
- Hector 
- Hector 
- Hector 

">Re: [PATCH v8 2/2] rust: add dma coherent allocato...</a> </td> </tr> <tr class="c0"> <td>Dave Airlie</td> <td>聽</td> <td> <a href="/lkml/2025/2/6/21" title="Dave Airlie writes: (Summary) 
To back up Sima here, we don't need grandstanding, brigading, playing
to the crowd, streamer drama creation or any of that in discussions
around this. 
around this. 
The r4l team and drm maintainer team have this sort of thing in hand,
it's not like we don't understand the community of the Linux kernel,
and having this first reaction to blow shit up and dramatise it just
isn't helpful. 
isn't helpful. 
Being toxic on the right side of an argument is still toxic, please
try and be better, and maybe take a step back and consider is what you
are posting going to help the discussion or just adding pointless
drama to it. 
drama to it. 
Dave. 
Dave. 
Dave. 

">Re: On community influencing (was Re: [PATCH v8 2/...</a> </td> </tr> <tr class="c1"> <td>Hector Martin</td> <td>聽</td> <td> <a href="/lkml/2025/2/7/16" title="Hector Martin writes: (Summary) And that's not going to change no
matter how many long technical arguments we have on the MLs (or even off
MLs, since MLs are also not particularly good for this, and I've seen
multiple arguments only reach a resolution after being redirected to IRC). Whether the rest of the kernel community chooses
to continue to live in an ugly bubble or actually try to fix some of
these systemic issues, is up to them. 
these systemic issues, is up to them. 
- Hector 
- Hector 
- Hector 
- Hector 

">Re: On community influencing (was Re: [PATCH v8 2/...</a> </td> </tr> </table> </td> </tr> </table> </div> <div align="right"> (c) 2002-2010 <a href="http://jasper.es/">Jasper Spaans</a> </div> </body> </html>

CINXE.COM

LKML.ORG - the Linux Kernel Mailing List Archive