Re: Re: Re: Subject: [PATCH net-next v4] net/ipv4: add tracepoint for icmp_send
>> >> >[...]
>> >> >> >I think my understanding based on what Eric depicted differs from =
>you:
>> >> >> >we're supposed to filter out those many invalid cases and only tra=
>ce
>> >> >> >the valid action of sending a icmp, so where to add a new tracepoi=
>nt
>> >> >> >is important instead of adding more checks in the tracepoint itsel=
>f.
>> >> >> >Please refer to what trace_tcp_retransmit_skb() does :)
>> >> >> >
>> >> >> >Thanks,
>> >> >> >Jason
>> >> >> Okay, thank you for your suggestion. In order to avoid filtering ou=
>t
>> >> >> those many invalid cases and only tracing the valid action of sendi=
>ng
>> >> >> a icmp, the next patch will add udd_fail_no_port trancepoint to the
>> >> >> include/trace/events/udp.h. This will solve the problem you mention=
>ed
>> >> >> very well. At this point, only UDP protocol exceptions will be trac=
>ked,
>> >> >> without the need to track them in icmp_send.
>> >> >
>> >> >I'm not against what you did (tracing all the icmp_send() for UDP) in
>> >> >your original patch. I was suggesting that you could put
>> >> >trace_icmp_send() in the right place, then you don't have to check th=
>e
>> >> >possible error condition (like if the skb->head is valid or not, ...)
>> >> >in your trace function.
>> >> >
>> >> >One example that can avoid various checks existing in the
>> >> >__icmp_send() function:
>> >> >diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
>> >> >index e63a3bf99617..2c9f7364de45 100644
>> >> >--- a/net/ipv4/icmp.c
>> >> >+++ b/net/ipv4/icmp.c
>> >> >@@ -767,6 +767,7 @@ void __icmp_send(struct sk_buff *skb_in, int type=
>,
>> >> >int code, __be32 info,
>> >> >if (!fl4.saddr)
>> >> >fl4.saddr =3D htonl(INADDR_DUMMY);
>> >> >
>> >> >+ trace_icmp_send(skb_in, type, code);
>> >> >icmp_push_reply(sk, _param, , , );
>> >> > ende
>> >> >ip_rt_put(rt);
>> >> >
>> >> >If we go here, it means we are ready to send the ICMP skb because
>> >> >we're done extracting the right information in the 'struct sk_buff
>> >> >skb_in'. Simpler and easier, right?
>> >> >
>> >> >Thanks,
>> >> >Jason
>> >>
>> >> I may not fully agree with this viewpoint. When trace_icmp_send is pla=
>ced
>> >> in this position, it cannot guarantee that all skbs in icmp are UDP pr=
>otocols
>> >> (UDP needs to be distinguished based on the proto_4!=3DIPPROTO_UDP con=
>dition),
>> >> nor can it guarantee the legitimacy of udphdr (*uh legitimacy check is=
> required).
>> >
>> >Of course, the UDP test statement is absolutely needed! Eric
>> >previously pointed this out in the V1 patch thread. I'm not referring
>> >to this one but like skb->head check something like this which exists
>> >in __icmp_send() function. You can see there are so many checks in it
>> >before sending.
>> >
>> >So only keeping the UDP check is enough, I think.
>>
>> The __icmp_send function only checks the IP header, but does not check
>> the UDP header, as shown in the following code snippet:
>>
>> if ((u8 *)iph < skb_in->head ||
>> (skb_network_header(skb_in) + sizeof(*iph)) >
>> skb_tail_pointer(skb_in))
>> goto out;
>>
>> There is no problem with the IP header check, which does not mean that
>> the UDP header is correct. Therefore, I believe that it is essential to
>> include a legitimacy judgment for the UDP header.
>>
>> Here is an explanation of this code:
>> Firstly, the UDP header (*uh) is extracted from the skb.
>> Then, if the current protocol of the skb is not UDP, or if the address of
>> uh is outside the range of the skb, the source port and destination port
>> will not be resolved, and 0 will be filled in directly.Otherwise,
>> the source port and destination port of the UDP header will be resolved.
>>
>> + struct udphdr *uh =3D udp_hdr(skb);
>> + if (proto_4 !=3D IPPROTO_UDP || (u8 *)uh < skb->head ||
>> + (u8 *)uh + sizeof(struct udphdr) > skb_tail_pointer(skb)) {
>
>>From the beginning, I always agree with the UDP check. I was saying if
>you can put the trace_icmp_send() just before icmp_push_reply()[1],
>you could avoid those kinds of checks.
>As I said in the previous email, "only keeping the UDP check is
>enough". So you are right.
>
>[1]
>diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
>index e63a3bf99617..2c9f7364de45 100644
>--- a/net/ipv4/icmp.c
>+++ b/net/ipv4/icmp.c
>@@ -767,6 +767,7 @@ void __icmp_send(struct sk_buff *skb_in, int type,
>int code, __be32 info,
>if (!fl4.saddr)
>fl4.saddr =3D htonl(INADDR_DUMMY);
>
>+ trace_icmp_send(skb_in, type, code);
>icmp_push_reply(sk, _param, , , );
> ende:
>ip_rt_put(rt);
>
>If we're doing this, trace_icmp_send() can reflect the real action of
>sending an ICMP like trace_tcp_retransmit_skb(). Or else, the trace
>could print some messages but no real ICMP is sent (see those error
>checks). WDYT?
>
>Thanks,
>Jasoin
Yeah, placing trace_icmp_send() before icmp_push_reply() will ensure
that tracking starts when ICMP
Re: Re: Re: Subject: [PATCH net-next v4] net/ipv4: add tracepoint for icmp_send
On Thu, Apr 11, 2024 at 12:57 PM Peilin He wrote:
>
> >> >[...]
> >> >> >I think my understanding based on what Eric depicted differs from you:
> >> >> >we're supposed to filter out those many invalid cases and only trace
> >> >> >the valid action of sending a icmp, so where to add a new tracepoint
> >> >> >is important instead of adding more checks in the tracepoint itself.
> >> >> >Please refer to what trace_tcp_retransmit_skb() does :)
> >> >> >
> >> >> >Thanks,
> >> >> >Jason
> >> >> Okay, thank you for your suggestion. In order to avoid filtering out
> >> >> those many invalid cases and only tracing the valid action of sending
> >> >> a icmp, the next patch will add udd_fail_no_port trancepoint to the
> >> >> include/trace/events/udp.h. This will solve the problem you mentioned
> >> >> very well. At this point, only UDP protocol exceptions will be tracked,
> >> >> without the need to track them in icmp_send.
> >> >
> >> >I'm not against what you did (tracing all the icmp_send() for UDP) in
> >> >your original patch. I was suggesting that you could put
> >> >trace_icmp_send() in the right place, then you don't have to check the
> >> >possible error condition (like if the skb->head is valid or not, ...)
> >> >in your trace function.
> >> >
> >> >One example that can avoid various checks existing in the
> >> >__icmp_send() function:
> >> >diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
> >> >index e63a3bf99617..2c9f7364de45 100644
> >> >--- a/net/ipv4/icmp.c
> >> >+++ b/net/ipv4/icmp.c
> >> >@@ -767,6 +767,7 @@ void __icmp_send(struct sk_buff *skb_in, int type,
> >> >int code, __be32 info,
> >> >if (!fl4.saddr)
> >> >fl4.saddr = htonl(INADDR_DUMMY);
> >> >
> >> >+ trace_icmp_send(skb_in, type, code);
> >> >icmp_push_reply(sk, _param, , , );
> >> > ende
> >> >ip_rt_put(rt);
> >> >
> >> >If we go here, it means we are ready to send the ICMP skb because
> >> >we're done extracting the right information in the 'struct sk_buff
> >> >skb_in'. Simpler and easier, right?
> >> >
> >> >Thanks,
> >> >Jason
> >>
> >> I may not fully agree with this viewpoint. When trace_icmp_send is placed
> >> in this position, it cannot guarantee that all skbs in icmp are UDP
> >> protocols
> >> (UDP needs to be distinguished based on the proto_4!=IPPROTO_UDP
> >> condition),
> >> nor can it guarantee the legitimacy of udphdr (*uh legitimacy check is
> >> required).
> >
> >Of course, the UDP test statement is absolutely needed! Eric
> >previously pointed this out in the V1 patch thread. I'm not referring
> >to this one but like skb->head check something like this which exists
> >in __icmp_send() function. You can see there are so many checks in it
> >before sending.
> >
> >So only keeping the UDP check is enough, I think.
>
> The __icmp_send function only checks the IP header, but does not check
> the UDP header, as shown in the following code snippet:
>
> if ((u8 *)iph < skb_in->head ||
> (skb_network_header(skb_in) + sizeof(*iph)) >
> skb_tail_pointer(skb_in))
> goto out;
>
> There is no problem with the IP header check, which does not mean that
> the UDP header is correct. Therefore, I believe that it is essential to
> include a legitimacy judgment for the UDP header.
>
> Here is an explanation of this code:
> Firstly, the UDP header (*uh) is extracted from the skb.
> Then, if the current protocol of the skb is not UDP, or if the address of
> uh is outside the range of the skb, the source port and destination port
> will not be resolved, and 0 will be filled in directly.Otherwise,
> the source port and destination port of the UDP header will be resolved.
>
> + struct udphdr *uh = udp_hdr(skb);
> + if (proto_4 != IPPROTO_UDP || (u8 *)uh < skb->head ||
> + (u8 *)uh + sizeof(struct udphdr) > skb_tail_pointer(skb)) {
>From the beginning, I always agree with the UDP check. I was saying if
you can put the trace_icmp_send() just before icmp_push_reply()[1],
you could avoid those kinds of checks.
As I said in the previous email, "only keeping the UDP check is
enough". So you are right.
[1]
diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
index e63a3bf99617..2c9f7364de45 100644
--- a/net/ipv4/icmp.c
+++ b/net/ipv4/icmp.c
@@ -767,6 +767,7 @@ void __icmp_send(struct sk_buff *skb_in, int type,
int code, __be32 info,
if (!fl4.saddr)
fl4.saddr = htonl(INADDR_DUMMY);
+ trace_icmp_send(skb_in, type, code);
icmp_push_reply(sk, _param, , , );
ende:
ip_rt_put(rt);
If we're doing this, trace_icmp_send() can reflect the real action of
sending an ICMP like trace_tcp_retransmit_skb(). Or else, the trace
could print some messages but no real ICMP is sent (see those error
checks). WDYT?
Thanks,
Jason
>
> With best wishes
> Peilin He
>
> >Thanks,
> >Jason
> >
> >>
> >> With best wishes
> >> Peilin He
> >>
> >> >>
> >> >> >> 2.Target this patch for net-next.
> >> >> >>
> >> >> >> v2->v3:
> >>
Re: Re: Re: Subject: [PATCH net-next v4] net/ipv4: add tracepoint for icmp_send
>> >[...]
>> >> >I think my understanding based on what Eric depicted differs from you:
>> >> >we're supposed to filter out those many invalid cases and only trace
>> >> >the valid action of sending a icmp, so where to add a new tracepoint
>> >> >is important instead of adding more checks in the tracepoint itself.
>> >> >Please refer to what trace_tcp_retransmit_skb() does :)
>> >> >
>> >> >Thanks,
>> >> >Jason
>> >> Okay, thank you for your suggestion. In order to avoid filtering out
>> >> those many invalid cases and only tracing the valid action of sending
>> >> a icmp, the next patch will add udd_fail_no_port trancepoint to the
>> >> include/trace/events/udp.h. This will solve the problem you mentioned
>> >> very well. At this point, only UDP protocol exceptions will be tracked,
>> >> without the need to track them in icmp_send.
>> >
>> >I'm not against what you did (tracing all the icmp_send() for UDP) in
>> >your original patch. I was suggesting that you could put
>> >trace_icmp_send() in the right place, then you don't have to check the
>> >possible error condition (like if the skb->head is valid or not, ...)
>> >in your trace function.
>> >
>> >One example that can avoid various checks existing in the
>> >__icmp_send() function:
>> >diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
>> >index e63a3bf99617..2c9f7364de45 100644
>> >--- a/net/ipv4/icmp.c
>> >+++ b/net/ipv4/icmp.c
>> >@@ -767,6 +767,7 @@ void __icmp_send(struct sk_buff *skb_in, int type,
>> >int code, __be32 info,
>> >if (!fl4.saddr)
>> >fl4.saddr = htonl(INADDR_DUMMY);
>> >
>> >+ trace_icmp_send(skb_in, type, code);
>> >icmp_push_reply(sk, _param, , , );
>> > ende
>> >ip_rt_put(rt);
>> >
>> >If we go here, it means we are ready to send the ICMP skb because
>> >we're done extracting the right information in the 'struct sk_buff
>> >skb_in'. Simpler and easier, right?
>> >
>> >Thanks,
>> >Jason
>>
>> I may not fully agree with this viewpoint. When trace_icmp_send is placed
>> in this position, it cannot guarantee that all skbs in icmp are UDP protocols
>> (UDP needs to be distinguished based on the proto_4!=IPPROTO_UDP condition),
>> nor can it guarantee the legitimacy of udphdr (*uh legitimacy check is
>> required).
>
>Of course, the UDP test statement is absolutely needed! Eric
>previously pointed this out in the V1 patch thread. I'm not referring
>to this one but like skb->head check something like this which exists
>in __icmp_send() function. You can see there are so many checks in it
>before sending.
>
>So only keeping the UDP check is enough, I think.
The __icmp_send function only checks the IP header, but does not check
the UDP header, as shown in the following code snippet:
if ((u8 *)iph < skb_in->head ||
(skb_network_header(skb_in) + sizeof(*iph)) >
skb_tail_pointer(skb_in))
goto out;
There is no problem with the IP header check, which does not mean that
the UDP header is correct. Therefore, I believe that it is essential to
include a legitimacy judgment for the UDP header.
Here is an explanation of this code:
Firstly, the UDP header (*uh) is extracted from the skb.
Then, if the current protocol of the skb is not UDP, or if the address of
uh is outside the range of the skb, the source port and destination port
will not be resolved, and 0 will be filled in directly.Otherwise,
the source port and destination port of the UDP header will be resolved.
+ struct udphdr *uh = udp_hdr(skb);
+ if (proto_4 != IPPROTO_UDP || (u8 *)uh < skb->head ||
+ (u8 *)uh + sizeof(struct udphdr) > skb_tail_pointer(skb)) {
With best wishes
Peilin He
>Thanks,
>Jason
>
>>
>> With best wishes
>> Peilin He
>>
>> >>
>> >> >> 2.Target this patch for net-next.
>> >> >>
>> >> >> v2->v3:
>> >> >> Some fixes according to
>> >> >> https://lore.kernel.org/all/20240319102549.7f7f6...@gandalf.local.home/
>> >> >> 1. Change the tracking directory to/sys/kernel/tracking.
>> >> >> 2. Adjust the layout of the TP-STRUCT_entry parameter structure.
>> >> >>
>> >> >> v1->v2:
>> >> >> Some fixes according to
>> >> >> https://lore.kernel.org/all/CANn89iL-y9e_VFpdw=3DsZtRnKRu_tnUwqHuFQTJvJsv=
>> >> >-nz1x...@mail.gmail.com/
>> >> >> 1. adjust the trace_icmp_send() to more protocols than UDP.
>> >> >> 2. move the calling of trace_icmp_send after sanity checks
>> >> >> in __icmp_send().
>> >> >>
>> >> >> Signed-off-by: Peilin He
>> >> >> Reviewed-by: xu xin
>> >> >> Reviewed-by: Yunkai Zhang
>> >> >> Cc: Yang Yang
>> >> >> Cc: Liu Chun
>> >> >> Cc: Xuexin Jiang
>> >> >> ---
>> >> >> include/trace/events/icmp.h | 65 +
>> >> >> net/ipv4/icmp.c | 4 +++
>> >> >> 2 files changed, 69 insertions(+)
>> >> >> create mode 100644 include/trace/events/icmp.h
>> >> >>
>> >> >> diff --git a/include/trace/events/icmp.h b/include/trace/events/icmp.h
>> >> >> new file mode 100644
>> >> >> index ..7d5190f48a28
>> >>
Re: Re: Re: Subject: [PATCH net-next v4] net/ipv4: add tracepoint for icmp_send
On Thu, Apr 11, 2024 at 10:34 AM Peilin He wrote: > > >[...] > >> >I think my understanding based on what Eric depicted differs from you: > >> >we're supposed to filter out those many invalid cases and only trace > >> >the valid action of sending a icmp, so where to add a new tracepoint > >> >is important instead of adding more checks in the tracepoint itself. > >> >Please refer to what trace_tcp_retransmit_skb() does :) > >> > > >> >Thanks, > >> >Jason > >> Okay, thank you for your suggestion. In order to avoid filtering out > >> those many invalid cases and only tracing the valid action of sending > >> a icmp, the next patch will add udd_fail_no_port trancepoint to the > >> include/trace/events/udp.h. This will solve the problem you mentioned > >> very well. At this point, only UDP protocol exceptions will be tracked, > >> without the need to track them in icmp_send. > > > >I'm not against what you did (tracing all the icmp_send() for UDP) in > >your original patch. I was suggesting that you could put > >trace_icmp_send() in the right place, then you don't have to check the > >possible error condition (like if the skb->head is valid or not, ...) > >in your trace function. > > > >One example that can avoid various checks existing in the > >__icmp_send() function: > >diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c > >index e63a3bf99617..2c9f7364de45 100644 > >--- a/net/ipv4/icmp.c > >+++ b/net/ipv4/icmp.c > >@@ -767,6 +767,7 @@ void __icmp_send(struct sk_buff *skb_in, int type, > >int code, __be32 info, > >if (!fl4.saddr) > >fl4.saddr = htonl(INADDR_DUMMY); > > > >+ trace_icmp_send(skb_in, type, code); > >icmp_push_reply(sk, _param, , , ); > > ende > >ip_rt_put(rt); > > > >If we go here, it means we are ready to send the ICMP skb because > >we're done extracting the right information in the 'struct sk_buff > >skb_in'. Simpler and easier, right? > > > >Thanks, > >Jason > > I may not fully agree with this viewpoint. When trace_icmp_send is placed > in this position, it cannot guarantee that all skbs in icmp are UDP protocols > (UDP needs to be distinguished based on the proto_4!=IPPROTO_UDP condition), > nor can it guarantee the legitimacy of udphdr (*uh legitimacy check is > required). Of course, the UDP test statement is absolutely needed! Eric previously pointed this out in the V1 patch thread. I'm not referring to this one but like skb->head check something like this which exists in __icmp_send() function. You can see there are so many checks in it before sending. So only keeping the UDP check is enough, I think. Thanks, Jason > > With best wishes > Peilin He > > >> > >> >> 2.Target this patch for net-next. > >> >> > >> >> v2->v3: > >> >> Some fixes according to > >> >> https://lore.kernel.org/all/20240319102549.7f7f6...@gandalf.local.home/ > >> >> 1. Change the tracking directory to/sys/kernel/tracking. > >> >> 2. Adjust the layout of the TP-STRUCT_entry parameter structure. > >> >> > >> >> v1->v2: > >> >> Some fixes according to > >> >> https://lore.kernel.org/all/CANn89iL-y9e_VFpdw=3DsZtRnKRu_tnUwqHuFQTJvJsv= > >> >-nz1x...@mail.gmail.com/ > >> >> 1. adjust the trace_icmp_send() to more protocols than UDP. > >> >> 2. move the calling of trace_icmp_send after sanity checks > >> >> in __icmp_send(). > >> >> > >> >> Signed-off-by: Peilin He > >> >> Reviewed-by: xu xin > >> >> Reviewed-by: Yunkai Zhang > >> >> Cc: Yang Yang > >> >> Cc: Liu Chun > >> >> Cc: Xuexin Jiang > >> >> --- > >> >> include/trace/events/icmp.h | 65 + > >> >> net/ipv4/icmp.c | 4 +++ > >> >> 2 files changed, 69 insertions(+) > >> >> create mode 100644 include/trace/events/icmp.h > >> >> > >> >> diff --git a/include/trace/events/icmp.h b/include/trace/events/icmp.h > >> >> new file mode 100644 > >> >> index ..7d5190f48a28 > >> >> --- /dev/null > >> >> +++ b/include/trace/events/icmp.h > >> >> @@ -0,0 +1,65 @@ > >> >> +/* SPDX-License-Identifier: GPL-2.0 */ > >> >> +#undef TRACE_SYSTEM > >> >> +#define TRACE_SYSTEM icmp > >> >> + > >> >> +#if !defined(_TRACE_ICMP_H) || defined(TRACE_HEADER_MULTI_READ) > >> >> +#define _TRACE_ICMP_H > >> >> + > >> >> +#include > >> >> +#include > >> >> + > >> >> +TRACE_EVENT(icmp_send, > >> >> + > >> >> + TP_PROTO(const struct sk_buff *skb, int type, int code), > >> >> + > >> >> + TP_ARGS(skb, type, code), > >> >> + > >> >> + TP_STRUCT__entry( > >> >> + __field(const void *, skbaddr) > >> >> + __field(int, type) > >> >> + __field(int, code) > >> >> + __array(__u8, saddr, 4) > >> >> + __array(__u8, daddr, 4) > >> >> + __field(__u16, sport) > >> >> + __field(__u16, dport) > >> >> + __field(unsigned short, ulen) > >> >> + ), > >> >> + > >> >> +
Re: Re: Re: Subject: [PATCH net-next v4] net/ipv4: add tracepoint for icmp_send
>[...]
>> >I think my understanding based on what Eric depicted differs from you:
>> >we're supposed to filter out those many invalid cases and only trace
>> >the valid action of sending a icmp, so where to add a new tracepoint
>> >is important instead of adding more checks in the tracepoint itself.
>> >Please refer to what trace_tcp_retransmit_skb() does :)
>> >
>> >Thanks,
>> >Jason
>> Okay, thank you for your suggestion. In order to avoid filtering out
>> those many invalid cases and only tracing the valid action of sending
>> a icmp, the next patch will add udd_fail_no_port trancepoint to the
>> include/trace/events/udp.h. This will solve the problem you mentioned
>> very well. At this point, only UDP protocol exceptions will be tracked,
>> without the need to track them in icmp_send.
>
>I'm not against what you did (tracing all the icmp_send() for UDP) in
>your original patch. I was suggesting that you could put
>trace_icmp_send() in the right place, then you don't have to check the
>possible error condition (like if the skb->head is valid or not, ...)
>in your trace function.
>
>One example that can avoid various checks existing in the
>__icmp_send() function:
>diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
>index e63a3bf99617..2c9f7364de45 100644
>--- a/net/ipv4/icmp.c
>+++ b/net/ipv4/icmp.c
>@@ -767,6 +767,7 @@ void __icmp_send(struct sk_buff *skb_in, int type,
>int code, __be32 info,
>if (!fl4.saddr)
>fl4.saddr = htonl(INADDR_DUMMY);
>
>+ trace_icmp_send(skb_in, type, code);
>icmp_push_reply(sk, _param, , , );
> ende:
>ip_rt_put(rt);
>
>If we go here, it means we are ready to send the ICMP skb because
>we're done extracting the right information in the 'struct sk_buff
>skb_in'. Simpler and easier, right?
>
>Thanks,
>Jason
I may not fully agree with this viewpoint. When trace_icmp_send is placed
in this position, it cannot guarantee that all skbs in icmp are UDP protocols
(UDP needs to be distinguished based on the proto_4!=IPPROTO_UDP condition),
nor can it guarantee the legitimacy of udphdr (*uh legitimacy check is
required).
With best wishes
Peilin He
>>
>> >> 2.Target this patch for net-next.
>> >>
>> >> v2->v3:
>> >> Some fixes according to
>> >> https://lore.kernel.org/all/20240319102549.7f7f6...@gandalf.local.home/
>> >> 1. Change the tracking directory to/sys/kernel/tracking.
>> >> 2. Adjust the layout of the TP-STRUCT_entry parameter structure.
>> >>
>> >> v1->v2:
>> >> Some fixes according to
>> >> https://lore.kernel.org/all/CANn89iL-y9e_VFpdw=3DsZtRnKRu_tnUwqHuFQTJvJsv=
>> >-nz1x...@mail.gmail.com/
>> >> 1. adjust the trace_icmp_send() to more protocols than UDP.
>> >> 2. move the calling of trace_icmp_send after sanity checks
>> >> in __icmp_send().
>> >>
>> >> Signed-off-by: Peilin He
>> >> Reviewed-by: xu xin
>> >> Reviewed-by: Yunkai Zhang
>> >> Cc: Yang Yang
>> >> Cc: Liu Chun
>> >> Cc: Xuexin Jiang
>> >> ---
>> >> include/trace/events/icmp.h | 65 +
>> >> net/ipv4/icmp.c | 4 +++
>> >> 2 files changed, 69 insertions(+)
>> >> create mode 100644 include/trace/events/icmp.h
>> >>
>> >> diff --git a/include/trace/events/icmp.h b/include/trace/events/icmp.h
>> >> new file mode 100644
>> >> index ..7d5190f48a28
>> >> --- /dev/null
>> >> +++ b/include/trace/events/icmp.h
>> >> @@ -0,0 +1,65 @@
>> >> +/* SPDX-License-Identifier: GPL-2.0 */
>> >> +#undef TRACE_SYSTEM
>> >> +#define TRACE_SYSTEM icmp
>> >> +
>> >> +#if !defined(_TRACE_ICMP_H) || defined(TRACE_HEADER_MULTI_READ)
>> >> +#define _TRACE_ICMP_H
>> >> +
>> >> +#include
>> >> +#include
>> >> +
>> >> +TRACE_EVENT(icmp_send,
>> >> +
>> >> + TP_PROTO(const struct sk_buff *skb, int type, int code),
>> >> +
>> >> + TP_ARGS(skb, type, code),
>> >> +
>> >> + TP_STRUCT__entry(
>> >> + __field(const void *, skbaddr)
>> >> + __field(int, type)
>> >> + __field(int, code)
>> >> + __array(__u8, saddr, 4)
>> >> + __array(__u8, daddr, 4)
>> >> + __field(__u16, sport)
>> >> + __field(__u16, dport)
>> >> + __field(unsigned short, ulen)
>> >> + ),
>> >> +
>> >> + TP_fast_assign(
>> >> + struct iphdr *iph =3D ip_hdr(skb);
>> >> + int proto_4 =3D iph->protocol;
>> >> + __be32 *p32;
>> >> +
>> >> + __entry->skbaddr =3D skb;
>> >> + __entry->type =3D type;
>> >> + __entry->code =3D code;
>> >> +
>> >> + struct udphdr *uh =3D udp_hdr(skb);
>> >> + if (proto_4 !=3D IPPROTO_UDP || (u8 *)uh < skb->h=
>> >ead ||
>> >> + (u8 *)uh + sizeof(struct udphdr) > skb_ta=
>> >il_pointer(skb)) {
>> >> +
Re: Re: Subject: [PATCH net-next v4] net/ipv4: add tracepoint for icmp_send
[...]
> >I think my understanding based on what Eric depicted differs from you:
> >we're supposed to filter out those many invalid cases and only trace
> >the valid action of sending a icmp, so where to add a new tracepoint
> >is important instead of adding more checks in the tracepoint itself.
> >Please refer to what trace_tcp_retransmit_skb() does :)
> >
> >Thanks,
> >Jason
> Okay, thank you for your suggestion. In order to avoid filtering out
> those many invalid cases and only tracing the valid action of sending
> a icmp, the next patch will add udd_fail_no_port trancepoint to the
> include/trace/events/udp.h. This will solve the problem you mentioned
> very well. At this point, only UDP protocol exceptions will be tracked,
> without the need to track them in icmp_send.
I'm not against what you did (tracing all the icmp_send() for UDP) in
your original patch. I was suggesting that you could put
trace_icmp_send() in the right place, then you don't have to check the
possible error condition (like if the skb->head is valid or not, ...)
in your trace function.
One example that can avoid various checks existing in the
__icmp_send() function:
diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
index e63a3bf99617..2c9f7364de45 100644
--- a/net/ipv4/icmp.c
+++ b/net/ipv4/icmp.c
@@ -767,6 +767,7 @@ void __icmp_send(struct sk_buff *skb_in, int type,
int code, __be32 info,
if (!fl4.saddr)
fl4.saddr = htonl(INADDR_DUMMY);
+ trace_icmp_send(skb_in, type, code);
icmp_push_reply(sk, _param, , , );
ende:
ip_rt_put(rt);
If we go here, it means we are ready to send the ICMP skb because
we're done extracting the right information in the 'struct sk_buff
skb_in'. Simpler and easier, right?
Thanks,
Jason
>
> >> 2.Target this patch for net-next.
> >>
> >> v2->v3:
> >> Some fixes according to
> >> https://lore.kernel.org/all/20240319102549.7f7f6...@gandalf.local.home/
> >> 1. Change the tracking directory to/sys/kernel/tracking.
> >> 2. Adjust the layout of the TP-STRUCT_entry parameter structure.
> >>
> >> v1->v2:
> >> Some fixes according to
> >> https://lore.kernel.org/all/CANn89iL-y9e_VFpdw=3DsZtRnKRu_tnUwqHuFQTJvJsv=
> >-nz1x...@mail.gmail.com/
> >> 1. adjust the trace_icmp_send() to more protocols than UDP.
> >> 2. move the calling of trace_icmp_send after sanity checks
> >> in __icmp_send().
> >>
> >> Signed-off-by: Peilin He
> >> Reviewed-by: xu xin
> >> Reviewed-by: Yunkai Zhang
> >> Cc: Yang Yang
> >> Cc: Liu Chun
> >> Cc: Xuexin Jiang
> >> ---
> >> include/trace/events/icmp.h | 65 +
> >> net/ipv4/icmp.c | 4 +++
> >> 2 files changed, 69 insertions(+)
> >> create mode 100644 include/trace/events/icmp.h
> >>
> >> diff --git a/include/trace/events/icmp.h b/include/trace/events/icmp.h
> >> new file mode 100644
> >> index ..7d5190f48a28
> >> --- /dev/null
> >> +++ b/include/trace/events/icmp.h
> >> @@ -0,0 +1,65 @@
> >> +/* SPDX-License-Identifier: GPL-2.0 */
> >> +#undef TRACE_SYSTEM
> >> +#define TRACE_SYSTEM icmp
> >> +
> >> +#if !defined(_TRACE_ICMP_H) || defined(TRACE_HEADER_MULTI_READ)
> >> +#define _TRACE_ICMP_H
> >> +
> >> +#include
> >> +#include
> >> +
> >> +TRACE_EVENT(icmp_send,
> >> +
> >> + TP_PROTO(const struct sk_buff *skb, int type, int code),
> >> +
> >> + TP_ARGS(skb, type, code),
> >> +
> >> + TP_STRUCT__entry(
> >> + __field(const void *, skbaddr)
> >> + __field(int, type)
> >> + __field(int, code)
> >> + __array(__u8, saddr, 4)
> >> + __array(__u8, daddr, 4)
> >> + __field(__u16, sport)
> >> + __field(__u16, dport)
> >> + __field(unsigned short, ulen)
> >> + ),
> >> +
> >> + TP_fast_assign(
> >> + struct iphdr *iph =3D ip_hdr(skb);
> >> + int proto_4 =3D iph->protocol;
> >> + __be32 *p32;
> >> +
> >> + __entry->skbaddr =3D skb;
> >> + __entry->type =3D type;
> >> + __entry->code =3D code;
> >> +
> >> + struct udphdr *uh =3D udp_hdr(skb);
> >> + if (proto_4 !=3D IPPROTO_UDP || (u8 *)uh < skb->h=
> >ead ||
> >> + (u8 *)uh + sizeof(struct udphdr) > skb_ta=
> >il_pointer(skb)) {
> >> + __entry->sport =3D 0;
> >> + __entry->dport =3D 0;
> >> + __entry->ulen =3D 0;
> >> + } else {
> >> + __entry->sport =3D ntohs(uh->source);
> >> + __entry->dport =3D ntohs(uh->dest);
> >> + __entry->ulen =3D ntohs(uh->len);
> >> + }
> >> +
Re: Re: Subject: [PATCH net-next v4] net/ipv4: add tracepoint for icmp_send
>> From: hepeilin >> >> Introduce a tracepoint for icmp_send, which can help users to get more >> detail information conveniently when icmp abnormal events happen. >> >> 1. Giving an usecase example: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >=3D=3D=3D=3D=3D >> When an application experiences packet loss due to an unreachable UDP >> destination port, the kernel will send an exception message through the >> icmp_send function. By adding a trace point for icmp_send, developers or >> system administrators can obtain detailed information about the UDP >> packet loss, including the type, code, source address, destination addres= >s, >> source port, and destination port. This facilitates the trouble-shooting >> of UDP packet loss issues especially for those network-service >> applications. >> >> 2. Operation Instructions: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >=3D=3D >> Switch to the tracing directory. >> cd /sys/kernel/tracing >> Filter for destination port unreachable. >> echo "type=3D=3D3 && code=3D=3D3" > events/icmp/icmp_send/filter >> Enable trace event. >> echo 1 > events/icmp/icmp_send/enable >> >> 3. Result View: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> udp_client_erro-11370 [002] ...s.12 124.728002: >> icmp_send: icmp_send: type=3D3, code=3D3. >> From 127.0.0.1:41895 to 127.0.0.1: ulen=3D23 >> skbaddr=3D589b167a >> >> v3->v4: >> Some fixes according to >> https://lore.kernel.org/all/CANn89i+EFEr7VHXNdOi59Ba_R1nFKSBJzBzkJFVgCTdX= >Bx=3d...@mail.gmail.com/ >> 1.Add legality check for UDP header in SKB. > >I think my understanding based on what Eric depicted differs from you: >we're supposed to filter out those many invalid cases and only trace >the valid action of sending a icmp, so where to add a new tracepoint >is important instead of adding more checks in the tracepoint itself. >Please refer to what trace_tcp_retransmit_skb() does :) > >Thanks, >Jason Okay, thank you for your suggestion. In order to avoid filtering out those many invalid cases and only tracing the valid action of sending a icmp, the next patch will add udd_fail_no_port trancepoint to the include/trace/events/udp.h. This will solve the problem you mentioned very well. At this point, only UDP protocol exceptions will be tracked, without the need to track them in icmp_send. >> 2.Target this patch for net-next. >> >> v2->v3: >> Some fixes according to >> https://lore.kernel.org/all/20240319102549.7f7f6...@gandalf.local.home/ >> 1. Change the tracking directory to/sys/kernel/tracking. >> 2. Adjust the layout of the TP-STRUCT_entry parameter structure. >> >> v1->v2: >> Some fixes according to >> https://lore.kernel.org/all/CANn89iL-y9e_VFpdw=3DsZtRnKRu_tnUwqHuFQTJvJsv= >-nz1x...@mail.gmail.com/ >> 1. adjust the trace_icmp_send() to more protocols than UDP. >> 2. move the calling of trace_icmp_send after sanity checks >> in __icmp_send(). >> >> Signed-off-by: Peilin He >> Reviewed-by: xu xin >> Reviewed-by: Yunkai Zhang >> Cc: Yang Yang >> Cc: Liu Chun >> Cc: Xuexin Jiang >> --- >> include/trace/events/icmp.h | 65 + >> net/ipv4/icmp.c | 4 +++ >> 2 files changed, 69 insertions(+) >> create mode 100644 include/trace/events/icmp.h >> >> diff --git a/include/trace/events/icmp.h b/include/trace/events/icmp.h >> new file mode 100644 >> index ..7d5190f48a28 >> --- /dev/null >> +++ b/include/trace/events/icmp.h >> @@ -0,0 +1,65 @@ >> +/* SPDX-License-Identifier: GPL-2.0 */ >> +#undef TRACE_SYSTEM >> +#define TRACE_SYSTEM icmp >> + >> +#if !defined(_TRACE_ICMP_H) || defined(TRACE_HEADER_MULTI_READ) >> +#define _TRACE_ICMP_H >> + >> +#include >> +#include >> + >> +TRACE_EVENT(icmp_send, >> + >> + TP_PROTO(const struct sk_buff *skb, int type, int code), >> + >> + TP_ARGS(skb, type, code), >> + >> + TP_STRUCT__entry( >> + __field(const void *, skbaddr) >> + __field(int, type) >> + __field(int, code) >> + __array(__u8, saddr, 4) >> + __array(__u8, daddr, 4) >> + __field(__u16, sport) >> + __field(__u16, dport) >> + __field(unsigned short, ulen) >> + ), >> + >> + TP_fast_assign( >> + struct iphdr *iph =3D ip_hdr(skb); >> + int proto_4 =3D iph->protocol; >> + __be32 *p32; >> + >> + __entry->skbaddr =3D skb; >> + __entry->type =3D type; >> + __entry->code =3D code; >> + >> + struct udphdr *uh =3D udp_hdr(skb); >> + if (proto_4 !=3D IPPROTO_UDP || (u8 *)uh < skb->h= >ead || >> + (u8 *)uh + sizeof(struct udphdr)
Re: Subject: [PATCH net-next v4] net/ipv4: add tracepoint for icmp_send
On Mon, Apr 1, 2024 at 8:34 PM wrote:
>
> From: hepeilin
>
> Introduce a tracepoint for icmp_send, which can help users to get more
> detail information conveniently when icmp abnormal events happen.
>
> 1. Giving an usecase example:
> =
> When an application experiences packet loss due to an unreachable UDP
> destination port, the kernel will send an exception message through the
> icmp_send function. By adding a trace point for icmp_send, developers or
> system administrators can obtain detailed information about the UDP
> packet loss, including the type, code, source address, destination address,
> source port, and destination port. This facilitates the trouble-shooting
> of UDP packet loss issues especially for those network-service
> applications.
>
> 2. Operation Instructions:
> ==
> Switch to the tracing directory.
> cd /sys/kernel/tracing
> Filter for destination port unreachable.
> echo "type==3 && code==3" > events/icmp/icmp_send/filter
> Enable trace event.
> echo 1 > events/icmp/icmp_send/enable
>
> 3. Result View:
>
> udp_client_erro-11370 [002] ...s.12 124.728002:
> icmp_send: icmp_send: type=3, code=3.
> From 127.0.0.1:41895 to 127.0.0.1: ulen=23
> skbaddr=589b167a
>
> v3->v4:
> Some fixes according to
> https://lore.kernel.org/all/CANn89i+EFEr7VHXNdOi59Ba_R1nFKSBJzBzkJFVgCTdXBx=y...@mail.gmail.com/
> 1.Add legality check for UDP header in SKB.
I think my understanding based on what Eric depicted differs from you:
we're supposed to filter out those many invalid cases and only trace
the valid action of sending a icmp, so where to add a new tracepoint
is important instead of adding more checks in the tracepoint itself.
Please refer to what trace_tcp_retransmit_skb() does :)
Thanks,
Jason
> 2.Target this patch for net-next.
>
> v2->v3:
> Some fixes according to
> https://lore.kernel.org/all/20240319102549.7f7f6...@gandalf.local.home/
> 1. Change the tracking directory to/sys/kernel/tracking.
> 2. Adjust the layout of the TP-STRUCT_entry parameter structure.
>
> v1->v2:
> Some fixes according to
> https://lore.kernel.org/all/CANn89iL-y9e_VFpdw=sztrnkru_tnuwqhufqtjvjsv-nz1x...@mail.gmail.com/
> 1. adjust the trace_icmp_send() to more protocols than UDP.
> 2. move the calling of trace_icmp_send after sanity checks
> in __icmp_send().
>
> Signed-off-by: Peilin He
> Reviewed-by: xu xin
> Reviewed-by: Yunkai Zhang
> Cc: Yang Yang
> Cc: Liu Chun
> Cc: Xuexin Jiang
> ---
> include/trace/events/icmp.h | 65 +
> net/ipv4/icmp.c | 4 +++
> 2 files changed, 69 insertions(+)
> create mode 100644 include/trace/events/icmp.h
>
> diff --git a/include/trace/events/icmp.h b/include/trace/events/icmp.h
> new file mode 100644
> index ..7d5190f48a28
> --- /dev/null
> +++ b/include/trace/events/icmp.h
> @@ -0,0 +1,65 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#undef TRACE_SYSTEM
> +#define TRACE_SYSTEM icmp
> +
> +#if !defined(_TRACE_ICMP_H) || defined(TRACE_HEADER_MULTI_READ)
> +#define _TRACE_ICMP_H
> +
> +#include
> +#include
> +
> +TRACE_EVENT(icmp_send,
> +
> + TP_PROTO(const struct sk_buff *skb, int type, int code),
> +
> + TP_ARGS(skb, type, code),
> +
> + TP_STRUCT__entry(
> + __field(const void *, skbaddr)
> + __field(int, type)
> + __field(int, code)
> + __array(__u8, saddr, 4)
> + __array(__u8, daddr, 4)
> + __field(__u16, sport)
> + __field(__u16, dport)
> + __field(unsigned short, ulen)
> + ),
> +
> + TP_fast_assign(
> + struct iphdr *iph = ip_hdr(skb);
> + int proto_4 = iph->protocol;
> + __be32 *p32;
> +
> + __entry->skbaddr = skb;
> + __entry->type = type;
> + __entry->code = code;
> +
> + struct udphdr *uh = udp_hdr(skb);
> + if (proto_4 != IPPROTO_UDP || (u8 *)uh < skb->head ||
> + (u8 *)uh + sizeof(struct udphdr) >
> skb_tail_pointer(skb)) {
> + __entry->sport = 0;
> + __entry->dport = 0;
> + __entry->ulen = 0;
> + } else {
> + __entry->sport = ntohs(uh->source);
> + __entry->dport = ntohs(uh->dest);
> + __entry->ulen = ntohs(uh->len);
> + }
> +
> + p32 = (__be32 *) __entry->saddr;
> + *p32 = iph->saddr;
> +
> + p32 = (__be32 *) __entry->daddr;
> + *p32 =
Subject: [PATCH net-next v4] net/ipv4: add tracepoint for icmp_send
From: hepeilin
Introduce a tracepoint for icmp_send, which can help users to get more
detail information conveniently when icmp abnormal events happen.
1. Giving an usecase example:
=
When an application experiences packet loss due to an unreachable UDP
destination port, the kernel will send an exception message through the
icmp_send function. By adding a trace point for icmp_send, developers or
system administrators can obtain detailed information about the UDP
packet loss, including the type, code, source address, destination address,
source port, and destination port. This facilitates the trouble-shooting
of UDP packet loss issues especially for those network-service
applications.
2. Operation Instructions:
==
Switch to the tracing directory.
cd /sys/kernel/tracing
Filter for destination port unreachable.
echo "type==3 && code==3" > events/icmp/icmp_send/filter
Enable trace event.
echo 1 > events/icmp/icmp_send/enable
3. Result View:
udp_client_erro-11370 [002] ...s.12 124.728002:
icmp_send: icmp_send: type=3, code=3.
From 127.0.0.1:41895 to 127.0.0.1: ulen=23
skbaddr=589b167a
v3->v4:
Some fixes according to
https://lore.kernel.org/all/CANn89i+EFEr7VHXNdOi59Ba_R1nFKSBJzBzkJFVgCTdXBx=y...@mail.gmail.com/
1.Add legality check for UDP header in SKB.
2.Target this patch for net-next.
v2->v3:
Some fixes according to
https://lore.kernel.org/all/20240319102549.7f7f6...@gandalf.local.home/
1. Change the tracking directory to/sys/kernel/tracking.
2. Adjust the layout of the TP-STRUCT_entry parameter structure.
v1->v2:
Some fixes according to
https://lore.kernel.org/all/CANn89iL-y9e_VFpdw=sztrnkru_tnuwqhufqtjvjsv-nz1x...@mail.gmail.com/
1. adjust the trace_icmp_send() to more protocols than UDP.
2. move the calling of trace_icmp_send after sanity checks
in __icmp_send().
Signed-off-by: Peilin He
Reviewed-by: xu xin
Reviewed-by: Yunkai Zhang
Cc: Yang Yang
Cc: Liu Chun
Cc: Xuexin Jiang
---
include/trace/events/icmp.h | 65 +
net/ipv4/icmp.c | 4 +++
2 files changed, 69 insertions(+)
create mode 100644 include/trace/events/icmp.h
diff --git a/include/trace/events/icmp.h b/include/trace/events/icmp.h
new file mode 100644
index ..7d5190f48a28
--- /dev/null
+++ b/include/trace/events/icmp.h
@@ -0,0 +1,65 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM icmp
+
+#if !defined(_TRACE_ICMP_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_ICMP_H
+
+#include
+#include
+
+TRACE_EVENT(icmp_send,
+
+ TP_PROTO(const struct sk_buff *skb, int type, int code),
+
+ TP_ARGS(skb, type, code),
+
+ TP_STRUCT__entry(
+ __field(const void *, skbaddr)
+ __field(int, type)
+ __field(int, code)
+ __array(__u8, saddr, 4)
+ __array(__u8, daddr, 4)
+ __field(__u16, sport)
+ __field(__u16, dport)
+ __field(unsigned short, ulen)
+ ),
+
+ TP_fast_assign(
+ struct iphdr *iph = ip_hdr(skb);
+ int proto_4 = iph->protocol;
+ __be32 *p32;
+
+ __entry->skbaddr = skb;
+ __entry->type = type;
+ __entry->code = code;
+
+ struct udphdr *uh = udp_hdr(skb);
+ if (proto_4 != IPPROTO_UDP || (u8 *)uh < skb->head ||
+ (u8 *)uh + sizeof(struct udphdr) >
skb_tail_pointer(skb)) {
+ __entry->sport = 0;
+ __entry->dport = 0;
+ __entry->ulen = 0;
+ } else {
+ __entry->sport = ntohs(uh->source);
+ __entry->dport = ntohs(uh->dest);
+ __entry->ulen = ntohs(uh->len);
+ }
+
+ p32 = (__be32 *) __entry->saddr;
+ *p32 = iph->saddr;
+
+ p32 = (__be32 *) __entry->daddr;
+ *p32 = iph->daddr;
+ ),
+
+ TP_printk("icmp_send: type=%d, code=%d. From %pI4:%u to %pI4:%u
ulen=%d skbaddr=%p",
+ __entry->type, __entry->code,
+ __entry->saddr, __entry->sport, __entry->daddr,
+ __entry->dport, __entry->ulen, __entry->skbaddr)
+);
+
+#endif /* _TRACE_ICMP_H */
+
+/* This part must be outside protection */
+#include
\ No newline at end of file
diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
index 8cebb476b3ab..224551d75c02 100644
--- a/net/ipv4/icmp.c
+++ b/net/ipv4/icmp.c
@@ -92,6 +92,8 @@
#include
#include
[no subject]
m 1561c1c9285eaa8638406280b53bb9e0b5a67d93 Mon Sep 17 00:00:00 2001
From: ye xingchen
Date: Wed, 21 Sep 2022 09:21:30 +0800
Subject: [PATCH linux-next] nvdimm: Use the function kobj_to_dev()
Use kobj_to_dev() instead of open-coding it.
Reported-by: Zeal Robot
Signed-off-by: ye xingchen
---
drivers/nvdimm/bus.c| 2 +-
drivers/nvdimm/core.c | 2 +-
drivers/nvdimm/dimm_devs.c | 4 ++--
drivers/nvdimm/namespace_devs.c | 2 +-
drivers/nvdimm/region_devs.c| 4 ++--
5 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/nvdimm/bus.c b/drivers/nvdimm/bus.c
index b38d0355b0ac..6bd53d3a3eeb 100644
--- a/drivers/nvdimm/bus.c
+++ b/drivers/nvdimm/bus.c
@@ -690,7 +690,7 @@ static struct attribute *nd_numa_attributes[] = {
static umode_t nd_numa_attr_visible(struct kobject *kobj, struct attribute *a,
int n)
{
- struct device *dev = container_of(kobj, typeof(*dev), kobj);
+ struct device *dev = kobj_to_dev(kobj);
if (!IS_ENABLED(CONFIG_NUMA))
return 0;
diff --git a/drivers/nvdimm/core.c b/drivers/nvdimm/core.c
index d91799b71d23..8ee7eddce0b2 100644
--- a/drivers/nvdimm/core.c
+++ b/drivers/nvdimm/core.c
@@ -466,7 +466,7 @@ static DEVICE_ATTR_ADMIN_RW(activate);
static umode_t nvdimm_bus_firmware_visible(struct kobject *kobj, struct
attribute *a, int n)
{
- struct device *dev = container_of(kobj, typeof(*dev), kobj);
+ struct device *dev = kobj_to_dev(kobj);
struct nvdimm_bus *nvdimm_bus = to_nvdimm_bus(dev);
struct nvdimm_bus_descriptor *nd_desc = nvdimm_bus->nd_desc;
enum nvdimm_fwa_capability cap;
diff --git a/drivers/nvdimm/dimm_devs.c b/drivers/nvdimm/dimm_devs.c
index c7c980577491..5f9487e40111 100644
--- a/drivers/nvdimm/dimm_devs.c
+++ b/drivers/nvdimm/dimm_devs.c
@@ -409,7 +409,7 @@ static struct attribute *nvdimm_attributes[] = {
static umode_t nvdimm_visible(struct kobject *kobj, struct attribute *a, int n)
{
- struct device *dev = container_of(kobj, typeof(*dev), kobj);
+ struct device *dev = kobj_to_dev(kobj);
struct nvdimm *nvdimm = to_nvdimm(dev);
if (a != _attr_security.attr && a != _attr_frozen.attr)
@@ -525,7 +525,7 @@ static struct attribute *nvdimm_firmware_attributes[] = {
static umode_t nvdimm_firmware_visible(struct kobject *kobj, struct attribute
*a, int n)
{
- struct device *dev = container_of(kobj, typeof(*dev), kobj);
+ struct device *dev = kobj_to_dev(kobj);
struct nvdimm_bus *nvdimm_bus = walk_to_nvdimm_bus(dev);
struct nvdimm_bus_descriptor *nd_desc = nvdimm_bus->nd_desc;
struct nvdimm *nvdimm = to_nvdimm(dev);
diff --git a/drivers/nvdimm/namespace_devs.c b/drivers/nvdimm/namespace_devs.c
index dfade66bab73..fd2e8ca67001 100644
--- a/drivers/nvdimm/namespace_devs.c
+++ b/drivers/nvdimm/namespace_devs.c
@@ -1372,7 +1372,7 @@ static struct attribute *nd_namespace_attributes[] = {
static umode_t namespace_visible(struct kobject *kobj,
struct attribute *a, int n)
{
- struct device *dev = container_of(kobj, struct device, kobj);
+ struct device *dev = kobj_to_dev(kobj);
if (is_namespace_pmem(dev)) {
if (a == _attr_size.attr)
diff --git a/drivers/nvdimm/region_devs.c b/drivers/nvdimm/region_devs.c
index 473a71bbd9c9..886740e2c94f 100644
--- a/drivers/nvdimm/region_devs.c
+++ b/drivers/nvdimm/region_devs.c
@@ -607,7 +607,7 @@ static struct attribute *nd_region_attributes[] = {
static umode_t region_visible(struct kobject *kobj, struct attribute *a, int n)
{
- struct device *dev = container_of(kobj, typeof(*dev), kobj);
+ struct device *dev = kobj_to_dev(kobj);
struct nd_region *nd_region = to_nd_region(dev);
struct nd_interleave_set *nd_set = nd_region->nd_set;
int type = nd_region_to_nstype(nd_region);
@@ -721,7 +721,7 @@ REGION_MAPPING(31);
static umode_t mapping_visible(struct kobject *kobj, struct attribute *a, int
n)
{
- struct device *dev = container_of(kobj, struct device, kobj);
+ struct device *dev = kobj_to_dev(kobj);
struct nd_region *nd_region = to_nd_region(dev);
if (n < nd_region->ndr_mappings)
--
2.25.1
[no subject]
https://bit.ly/3x8LDhsWill
[no subject]
Molim vas, želim znati jeste li dobili moje prethodne poruke.
Re: [PATCH 0/2] *** SUBJECT HERE ***
On Fri, Apr 16, 2021 at 04:07:54PM +0800, Tao Zhang wrote: > *** BLURB HERE *** Where is the blurb? And your subject is not ok :(
[PATCH 0/2] *** SUBJECT HERE ***
*** BLURB HERE *** Tao Zhang (2): coresight: Add support for device names dt-bindings: arm: add property for coresight component name Documentation/devicetree/bindings/arm/coresight.txt | 2 ++ drivers/hwtracing/coresight/coresight-core.c| 6 ++ 2 files changed, 8 insertions(+) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: Subject: [PATCH v4] staging: media: zoran: add '*' in long(multi-line) comments
Hi Mitali,
You have 'Subject' in the Subject line. That looks weird...
On 13/04/2021 19:26, Mitali Borkar wrote:
> Added '*' before every line inside long(multi-line) comments. Removed
> '*/' from end of the comment line and added to next line as per linux
> kernel coding style. Aligned '*' accordingly to make code neater.
>
> Signed-off-by: Mitali Borkar
> ---
> Changes from v3:- Rebased this patch and made changes against mainline
> code.
> Changes from v2:- made style changes in code according to linux kernel
> coding style for long comments.
> Changes from v1:- Changes made in code according to linux kernel coding
> style for long(multi-line) comments.
>
> drivers/staging/media/zoran/zr36050.c | 192 +++---
> 1 file changed, 112 insertions(+), 80 deletions(-)
>
> diff --git a/drivers/staging/media/zoran/zr36050.c
> b/drivers/staging/media/zoran/zr36050.c
> index 2826f4e5d37b..a1084aa142e7 100644
> --- a/drivers/staging/media/zoran/zr36050.c
> +++ b/drivers/staging/media/zoran/zr36050.c
> @@ -24,8 +24,11 @@
> /* codec io API */
> #include "videocodec.h"
>
> -/* it doesn't make sense to have more than 20 or so,
> - just to prevent some unwanted loops */
> +/*
> + * it doesn't make sense to have more than 20 or so,
> + * just to prevent some unwanted loops
> + */
> +
Why add an empty line here? Since the comment describes the define, you expect
that the define follows directly after the comment.
> #define MAX_CODECS 20
>
> /* amount of chips attached via this driver */
> @@ -43,10 +46,11 @@ MODULE_PARM_DESC(debug, "Debug level (0-4)");
> } while (0)
>
> /* =
/* should be on a line by itself:
/*
* =
That said, I would just delete those '===' lines: they don't really
add anything.
Regards,
Hans
> - Local hardware I/O functions:
> -
> - read/write via codec layer (registers are located in the master device)
> - =
> */
> + * Local hardware I/O functions:
> + *
> + * read/write via codec layer (registers are located in the master device)
> + * =
> + */
>
> /* read and write functions */
> static u8 zr36050_read(struct zr36050 *ptr, u16 reg)
> @@ -80,10 +84,11 @@ static void zr36050_write(struct zr36050 *ptr, u16 reg,
> u8 value)
> }
>
> /* =
> - Local helper function:
> -
> - status read
> - =
> */
> + * Local helper function:
> + *
> + * status read
> + * =
> + */
>
> /* status is kept in datastructure */
> static u8 zr36050_read_status1(struct zr36050 *ptr)
> @@ -95,10 +100,11 @@ static u8 zr36050_read_status1(struct zr36050 *ptr)
> }
>
> /* =
> - Local helper function:
> -
> - scale factor read
> - =
> */
> + * Local helper function:
> + *
> + * scale factor read
> + * =
> + */
>
> /* scale factor is kept in datastructure */
> static u16 zr36050_read_scalefactor(struct zr36050 *ptr)
> @@ -112,10 +118,11 @@ static u16 zr36050_read_scalefactor(struct zr36050 *ptr)
> }
>
> /* =
> - Local helper function:
> -
> - wait if codec is ready to proceed (end of processing) or time is over
> - =
> */
> + * Local helper function:
> + *
> + * wait if codec is ready to proceed (end of processing) or time is over
> + * =
> + */
>
> static void zr36050_wait_end(struct zr36050 *ptr)
> {
> @@ -133,10 +140,11 @@ static void zr36050_wait_end(struct zr36050 *ptr)
> }
>
> /* =
> - Local helper function:
> -
> - basic test of "connectivity", writes/reads to/from memory the SOF marker
> - =
> */
> + * Local helper function:
> + *
> + * basic test of "
Re: Subject: [PATCH v2 0/5] staging: rtl8192e: CLeanup patchset for style issues in rtl819x_Y.c files
On Wed, Apr 14, 2021 at 12:24:44PM +0530, Mitali Borkar wrote: > Changes from v1:- Dropped 6/6 from and made this as a patchset of 5 as > alignment of code is done in following patches. Why is "Subject:" listed in your subject line? Do not manually add it after git format-patch has created it... thanks, greg k-h
Subject: [PATCH v2 0/5] staging: rtl8192e: CLeanup patchset for style issues in rtl819x_Y.c files
Changes from v1:- Dropped 6/6 from and made this as a patchset of 5 as alignment of code is done in following patches. [PATCH 1/5]:- No changes. [PATCH 2/5]:- No changes. [PATCH 3/5]:- No changes. [PATCH 4/5]:- Rectified spelling mistake and replaced memcmp with ether_oui_equal. [PATCH 5/5]:- No changes. Mitali Borkar (5): staging: rtl8192e: add spaces around binary operators staging: rtl8192e: remove unnecessary blank line before brace staging: rtl8192e: remove unnecessary blank line after close brace staging: rtl8192e: rectified spelling mistake and replace memcmp with ether_oui_equal staging: rtl8192e: removed multiple blank lines drivers/staging/rtl8192e/rtl819x_HTProc.c | 67 - drivers/staging/rtl8192e/rtl819x_TSProc.c | 10 +++-- include/linux/etherdevice.h | 5 + 3 files changed, 37 insertions(+), 45 deletions(-) -- 2.30.2
Subject: [PATCH v4] staging: media: zoran: add '*' in long(multi-line) comments
Added '*' before every line inside long(multi-line) comments. Removed
'*/' from end of the comment line and added to next line as per linux
kernel coding style. Aligned '*' accordingly to make code neater.
Signed-off-by: Mitali Borkar
---
Changes from v3:- Rebased this patch and made changes against mainline
code.
Changes from v2:- made style changes in code according to linux kernel
coding style for long comments.
Changes from v1:- Changes made in code according to linux kernel coding
style for long(multi-line) comments.
drivers/staging/media/zoran/zr36050.c | 192 +++---
1 file changed, 112 insertions(+), 80 deletions(-)
diff --git a/drivers/staging/media/zoran/zr36050.c
b/drivers/staging/media/zoran/zr36050.c
index 2826f4e5d37b..a1084aa142e7 100644
--- a/drivers/staging/media/zoran/zr36050.c
+++ b/drivers/staging/media/zoran/zr36050.c
@@ -24,8 +24,11 @@
/* codec io API */
#include "videocodec.h"
-/* it doesn't make sense to have more than 20 or so,
- just to prevent some unwanted loops */
+/*
+ * it doesn't make sense to have more than 20 or so,
+ * just to prevent some unwanted loops
+ */
+
#define MAX_CODECS 20
/* amount of chips attached via this driver */
@@ -43,10 +46,11 @@ MODULE_PARM_DESC(debug, "Debug level (0-4)");
} while (0)
/* =
- Local hardware I/O functions:
-
- read/write via codec layer (registers are located in the master device)
- = */
+ * Local hardware I/O functions:
+ *
+ * read/write via codec layer (registers are located in the master device)
+ * =
+ */
/* read and write functions */
static u8 zr36050_read(struct zr36050 *ptr, u16 reg)
@@ -80,10 +84,11 @@ static void zr36050_write(struct zr36050 *ptr, u16 reg, u8
value)
}
/* =
- Local helper function:
-
- status read
- = */
+ * Local helper function:
+ *
+ * status read
+ * =
+ */
/* status is kept in datastructure */
static u8 zr36050_read_status1(struct zr36050 *ptr)
@@ -95,10 +100,11 @@ static u8 zr36050_read_status1(struct zr36050 *ptr)
}
/* =
- Local helper function:
-
- scale factor read
- = */
+ * Local helper function:
+ *
+ * scale factor read
+ * =
+ */
/* scale factor is kept in datastructure */
static u16 zr36050_read_scalefactor(struct zr36050 *ptr)
@@ -112,10 +118,11 @@ static u16 zr36050_read_scalefactor(struct zr36050 *ptr)
}
/* =
- Local helper function:
-
- wait if codec is ready to proceed (end of processing) or time is over
- = */
+ * Local helper function:
+ *
+ * wait if codec is ready to proceed (end of processing) or time is over
+ * =
+ */
static void zr36050_wait_end(struct zr36050 *ptr)
{
@@ -133,10 +140,11 @@ static void zr36050_wait_end(struct zr36050 *ptr)
}
/* =
- Local helper function:
-
- basic test of "connectivity", writes/reads to/from memory the SOF marker
- = */
+ * Local helper function:
+ *
+ * basic test of "connectivity", writes/reads to/from memory the SOF marker
+ * =
+ */
static int zr36050_basic_test(struct zr36050 *ptr)
{
@@ -174,10 +182,11 @@ static int zr36050_basic_test(struct zr36050 *ptr)
}
/* =
- Local helper function:
-
- simple loop for pushing the init datasets
- = */
+ * Local helper function:
+ *
+ * simple loop for pushing the init datasets
+ * =
+ */
static int zr36050_pushit(struct zr36050 *ptr, u16 startreg, u16 len, const
char *data)
{
@@ -192,15 +201,16 @@ static int zr36050_pushit(struct zr36050 *ptr, u16
startreg, u16 len, const char
}
/* =
- Basic datasets:
-
- jpeg baseline setup data (you find it on lots places in internet, or just
- extract it from any regular .jpg image...)
-
-
Re: Subject: [PATCH v2] staging: media: meson: vdec: declare u32 as static const appropriately
On 13/04/2021 13:09, Mitali Borkar wrote:
> On Tue, Apr 13, 2021 at 09:26:01AM +0200, Hans Verkuil wrote:
>> On 13/04/2021 08:27, Mitali Borkar wrote:
>>> Declared 32 bit unsigned int as static constant inside a function
>>> appropriately.
>>>
>>> Reported-by: kernel test robot
>>> Signed-off-by: Mitali Borkar
>>> ---
>>>
>>> Changes from v1:- Rectified the mistake by declaring u32 as static const
>>> properly.
>>>
>>> drivers/staging/media/meson/vdec/codec_h264.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/staging/media/meson/vdec/codec_h264.c
>>> b/drivers/staging/media/meson/vdec/codec_h264.c
>>> index ea86e9e1c447..80141b89a9f6 100644
>>> --- a/drivers/staging/media/meson/vdec/codec_h264.c
>>> +++ b/drivers/staging/media/meson/vdec/codec_h264.c
>>> @@ -287,8 +287,8 @@ static void codec_h264_resume(struct amvdec_session
>>> *sess)
>>> struct amvdec_core *core = sess->core;
>>> struct codec_h264 *h264 = sess->priv;
>>> u32 mb_width, mb_height, mb_total;
>>> - static const u32[] canvas3 = { ANCO_CANVAS_ADDR, 0 };
>>> - static const u32[] canvas4 = { 24, 0 };
>>> + static const u32 canvas3[] = { ANCO_CANVAS_ADDR, 0 };
>>> + static const u32 canvas4[] = { 24, 0 };
>>
>> This is a patch on top of your previous (v1) patch. That won't work
>> since the v1 is not merged, you need to make a patch against the current
>> mainline code.
>>
> But Sir, since I have made changes in the code, and committed them, now,
> if I open that file, it will contain those changes. Then should I
> rewrite the patch body more accurately?
You only committed the v1 change in your own repository, it's not in the
upstream repository. And the patches you post must be against the upstream
repository, not your own.
'git rebase -i' can be your friend here, it makes it easy to fold the
second patch into the first, and then you only have to post the final
version.
Regards,
Hans
>
>> Regards,
>>
>> Hans
>>
>>>
>>> amvdec_set_canvases(sess, canvas3, canvas4);
>>>
>>>
>>
Re: Subject: [PATCH v2] staging: media: meson: vdec: declare u32 as static const appropriately
On Tue, Apr 13, 2021 at 09:26:01AM +0200, Hans Verkuil wrote:
> On 13/04/2021 08:27, Mitali Borkar wrote:
> > Declared 32 bit unsigned int as static constant inside a function
> > appropriately.
> >
> > Reported-by: kernel test robot
> > Signed-off-by: Mitali Borkar
> > ---
> >
> > Changes from v1:- Rectified the mistake by declaring u32 as static const
> > properly.
> >
> > drivers/staging/media/meson/vdec/codec_h264.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/staging/media/meson/vdec/codec_h264.c
> > b/drivers/staging/media/meson/vdec/codec_h264.c
> > index ea86e9e1c447..80141b89a9f6 100644
> > --- a/drivers/staging/media/meson/vdec/codec_h264.c
> > +++ b/drivers/staging/media/meson/vdec/codec_h264.c
> > @@ -287,8 +287,8 @@ static void codec_h264_resume(struct amvdec_session
> > *sess)
> > struct amvdec_core *core = sess->core;
> > struct codec_h264 *h264 = sess->priv;
> > u32 mb_width, mb_height, mb_total;
> > - static const u32[] canvas3 = { ANCO_CANVAS_ADDR, 0 };
> > - static const u32[] canvas4 = { 24, 0 };
> > + static const u32 canvas3[] = { ANCO_CANVAS_ADDR, 0 };
> > + static const u32 canvas4[] = { 24, 0 };
>
> This is a patch on top of your previous (v1) patch. That won't work
> since the v1 is not merged, you need to make a patch against the current
> mainline code.
>
But Sir, since I have made changes in the code, and committed them, now,
if I open that file, it will contain those changes. Then should I
rewrite the patch body more accurately?
> Regards,
>
> Hans
>
> >
> > amvdec_set_canvases(sess, canvas3, canvas4);
> >
> >
>
Re: Subject: [PATCH v2] staging: media: meson: vdec: declare u32 as static const appropriately
On 13/04/2021 08:27, Mitali Borkar wrote:
> Declared 32 bit unsigned int as static constant inside a function
> appropriately.
>
> Reported-by: kernel test robot
> Signed-off-by: Mitali Borkar
> ---
>
> Changes from v1:- Rectified the mistake by declaring u32 as static const
> properly.
>
> drivers/staging/media/meson/vdec/codec_h264.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/media/meson/vdec/codec_h264.c
> b/drivers/staging/media/meson/vdec/codec_h264.c
> index ea86e9e1c447..80141b89a9f6 100644
> --- a/drivers/staging/media/meson/vdec/codec_h264.c
> +++ b/drivers/staging/media/meson/vdec/codec_h264.c
> @@ -287,8 +287,8 @@ static void codec_h264_resume(struct amvdec_session *sess)
> struct amvdec_core *core = sess->core;
> struct codec_h264 *h264 = sess->priv;
> u32 mb_width, mb_height, mb_total;
> - static const u32[] canvas3 = { ANCO_CANVAS_ADDR, 0 };
> - static const u32[] canvas4 = { 24, 0 };
> + static const u32 canvas3[] = { ANCO_CANVAS_ADDR, 0 };
> + static const u32 canvas4[] = { 24, 0 };
This is a patch on top of your previous (v1) patch. That won't work
since the v1 is not merged, you need to make a patch against the current
mainline code.
Regards,
Hans
>
> amvdec_set_canvases(sess, canvas3, canvas4);
>
>
Re: Subject: [PATCH v2] staging: media: meson: vdec: declare u32 as static const appropriately
On Tue, Apr 13, 2021 at 11:57:52AM +0530, Mitali Borkar wrote: > Declared 32 bit unsigned int as static constant inside a function > appropriately. > > Reported-by: kernel test robot > Signed-off-by: Mitali Borkar Why does your Subject: line have "Subject:" twice?
Re: [Outreachy kernel] Subject: [PATCH v2] staging: media: meson: vdec: declare u32 as static const appropriately
On Tue, 13 Apr 2021, Mitali Borkar wrote:
> Declared 32 bit unsigned int as static constant inside a function
> appropriately.
I don't think that the description matches what is done. Perhaps all the
meaning is intended to be in the word "appropriately", but that is not
very clear. The message makes it looks like static const is the new part,
but it is already there.
julia
>
> Reported-by: kernel test robot
> Signed-off-by: Mitali Borkar
> ---
>
> Changes from v1:- Rectified the mistake by declaring u32 as static const
> properly.
>
> drivers/staging/media/meson/vdec/codec_h264.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/media/meson/vdec/codec_h264.c
> b/drivers/staging/media/meson/vdec/codec_h264.c
> index ea86e9e1c447..80141b89a9f6 100644
> --- a/drivers/staging/media/meson/vdec/codec_h264.c
> +++ b/drivers/staging/media/meson/vdec/codec_h264.c
> @@ -287,8 +287,8 @@ static void codec_h264_resume(struct amvdec_session *sess)
> struct amvdec_core *core = sess->core;
> struct codec_h264 *h264 = sess->priv;
> u32 mb_width, mb_height, mb_total;
> - static const u32[] canvas3 = { ANCO_CANVAS_ADDR, 0 };
> - static const u32[] canvas4 = { 24, 0 };
> + static const u32 canvas3[] = { ANCO_CANVAS_ADDR, 0 };
> + static const u32 canvas4[] = { 24, 0 };
>
> amvdec_set_canvases(sess, canvas3, canvas4);
>
> --
> 2.30.2
>
> --
> You received this message because you are subscribed to the Google Groups
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/outreachy-kernel/YHU56OM%2BC2zY34VP%40kali.
>
Subject: [PATCH v2] staging: media: meson: vdec: declare u32 as static const appropriately
Declared 32 bit unsigned int as static constant inside a function
appropriately.
Reported-by: kernel test robot
Signed-off-by: Mitali Borkar
---
Changes from v1:- Rectified the mistake by declaring u32 as static const
properly.
drivers/staging/media/meson/vdec/codec_h264.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/meson/vdec/codec_h264.c
b/drivers/staging/media/meson/vdec/codec_h264.c
index ea86e9e1c447..80141b89a9f6 100644
--- a/drivers/staging/media/meson/vdec/codec_h264.c
+++ b/drivers/staging/media/meson/vdec/codec_h264.c
@@ -287,8 +287,8 @@ static void codec_h264_resume(struct amvdec_session *sess)
struct amvdec_core *core = sess->core;
struct codec_h264 *h264 = sess->priv;
u32 mb_width, mb_height, mb_total;
- static const u32[] canvas3 = { ANCO_CANVAS_ADDR, 0 };
- static const u32[] canvas4 = { 24, 0 };
+ static const u32 canvas3[] = { ANCO_CANVAS_ADDR, 0 };
+ static const u32 canvas4[] = { 24, 0 };
amvdec_set_canvases(sess, canvas3, canvas4);
--
2.30.2
Re: Subject: [PATCH] staging: media: meson: vdec: declare u32 as static const
Hi Mitali,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on staging/staging-testing]
url:
https://github.com/0day-ci/linux/commits/Mitali-Borkar/Subject-PATCH-staging-media-meson-vdec-declare-u32-as-static-const/20210412-222025
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
f2f560e1bdc055a6a306e6b7823ba589794e6564
config: mips-randconfig-r013-20210412 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project
9829f5e6b1bca9b61efc629770d28bb9014dec45)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install mips cross compiling tool for clang build
# apt-get install binutils-mips-linux-gnu
#
https://github.com/0day-ci/linux/commit/c9873622761b42d977b48804bb0b4b9a7fbcd6b3
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Mitali-Borkar/Subject-PATCH-staging-media-meson-vdec-declare-u32-as-static-const/20210412-222025
git checkout c9873622761b42d977b48804bb0b4b9a7fbcd6b3
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/staging/media/meson/vdec/codec_h264.c:290:28: error: brackets are
>> not allowed here; to declare an array, place the brackets after the
>> identifier
static const u32[] canvas3 = { ANCO_CANVAS_ADDR, 0 };
~~^
[]
>> drivers/staging/media/meson/vdec/codec_h264.c:290:33: error: use of
>> undeclared identifier 'ANCO_CANVAS_ADDR'
static const u32[] canvas3 = { ANCO_CANVAS_ADDR, 0 };
^
drivers/staging/media/meson/vdec/codec_h264.c:291:28: error: brackets are
not allowed here; to declare an array, place the brackets after the identifier
static const u32[] canvas4 = { 24, 0 };
~~^
[]
>> drivers/staging/media/meson/vdec/codec_h264.c:293:28: error: passing 'const
>> u32 []' to parameter of type 'u32 *' (aka 'unsigned int *') discards
>> qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers]
amvdec_set_canvases(sess, canvas3, canvas4);
^~~
drivers/staging/media/meson/vdec/vdec_helpers.h:20:8: note: passing argument
to parameter 'reg_base' here
u32 reg_base[], u32 reg_num[]);
^
drivers/staging/media/meson/vdec/codec_h264.c:293:37: error: passing 'const
u32 [2]' to parameter of type 'u32 *' (aka 'unsigned int *') discards
qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers]
amvdec_set_canvases(sess, canvas3, canvas4);
^~~
drivers/staging/media/meson/vdec/vdec_helpers.h:20:24: note: passing
argument to parameter 'reg_num' here
u32 reg_base[], u32 reg_num[]);
^
5 errors generated.
vim +290 drivers/staging/media/meson/vdec/codec_h264.c
284
285 static void codec_h264_resume(struct amvdec_session *sess)
286 {
287 struct amvdec_core *core = sess->core;
288 struct codec_h264 *h264 = sess->priv;
289 u32 mb_width, mb_height, mb_total;
> 290 static const u32[] canvas3 = { ANCO_CANVAS_ADDR, 0 };
291 static const u32[] canvas4 = { 24, 0 };
292
> 293 amvdec_set_canvases(sess, canvas3, canvas4);
294
295 dev_dbg(core->dev, "max_refs = %u; actual_dpb_size = %u\n",
296 h264->max_refs, sess->num_dst_bufs);
297
298 /* Align to a multiple of 4 macroblocks */
299 mb_width = ALIGN(h264->mb_width, 4);
300 mb_height = ALIGN(h264->mb_height, 4);
301 mb_total = mb_width * mb_height;
302
303 h264->ref_size = mb_total * MB_MV_SIZE * h264->max_refs;
304 h264->ref_vaddr = dma_alloc_coherent(core->dev, h264->ref_size,
305 >ref_paddr,
GFP_KERNEL);
306 if (!h264->ref_vaddr) {
307 amvdec_abort(sess);
308 return;
309 }
310
311 /* Address to store the references' MVs */
312 amvdec_write_dos(core, AV_SCRATCH_1, h264->ref_paddr);
313 /* End of ref MV */
314 amvdec_write_dos(core, AV_SCRATCH_4, h264->ref_p
Re: Subject: [PATCH] staging: media: meson: vdec: declare u32 as static const
Hi Mitali,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on staging/staging-testing]
url:
https://github.com/0day-ci/linux/commits/Mitali-Borkar/Subject-PATCH-staging-media-meson-vdec-declare-u32-as-static-const/20210412-222025
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
f2f560e1bdc055a6a306e6b7823ba589794e6564
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/c9873622761b42d977b48804bb0b4b9a7fbcd6b3
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Mitali-Borkar/Subject-PATCH-staging-media-meson-vdec-declare-u32-as-static-const/20210412-222025
git checkout c9873622761b42d977b48804bb0b4b9a7fbcd6b3
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=ia64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All error/warnings (new ones prefixed by >>):
drivers/staging/media/meson/vdec/codec_h264.c: In function
'codec_h264_resume':
>> drivers/staging/media/meson/vdec/codec_h264.c:290:18: error: expected
>> identifier or '(' before '[' token
290 | static const u32[] canvas3 = { ANCO_CANVAS_ADDR, 0 };
| ^
drivers/staging/media/meson/vdec/codec_h264.c:291:18: error: expected
identifier or '(' before '[' token
291 | static const u32[] canvas4 = { 24, 0 };
| ^
>> drivers/staging/media/meson/vdec/codec_h264.c:291:2: warning: ISO C90
>> forbids mixed declarations and code [-Wdeclaration-after-statement]
291 | static const u32[] canvas4 = { 24, 0 };
| ^~
>> drivers/staging/media/meson/vdec/codec_h264.c:293:28: error: 'canvas3'
>> undeclared (first use in this function)
293 | amvdec_set_canvases(sess, canvas3, canvas4);
|^~~
drivers/staging/media/meson/vdec/codec_h264.c:293:28: note: each undeclared
identifier is reported only once for each function it appears in
>> drivers/staging/media/meson/vdec/codec_h264.c:293:37: error: 'canvas4'
>> undeclared (first use in this function)
293 | amvdec_set_canvases(sess, canvas3, canvas4);
| ^~~
vim +290 drivers/staging/media/meson/vdec/codec_h264.c
284
285 static void codec_h264_resume(struct amvdec_session *sess)
286 {
287 struct amvdec_core *core = sess->core;
288 struct codec_h264 *h264 = sess->priv;
289 u32 mb_width, mb_height, mb_total;
> 290 static const u32[] canvas3 = { ANCO_CANVAS_ADDR, 0 };
> 291 static const u32[] canvas4 = { 24, 0 };
292
> 293 amvdec_set_canvases(sess, canvas3, canvas4);
294
295 dev_dbg(core->dev, "max_refs = %u; actual_dpb_size = %u\n",
296 h264->max_refs, sess->num_dst_bufs);
297
298 /* Align to a multiple of 4 macroblocks */
299 mb_width = ALIGN(h264->mb_width, 4);
300 mb_height = ALIGN(h264->mb_height, 4);
301 mb_total = mb_width * mb_height;
302
303 h264->ref_size = mb_total * MB_MV_SIZE * h264->max_refs;
304 h264->ref_vaddr = dma_alloc_coherent(core->dev, h264->ref_size,
305 >ref_paddr,
GFP_KERNEL);
306 if (!h264->ref_vaddr) {
307 amvdec_abort(sess);
308 return;
309 }
310
311 /* Address to store the references' MVs */
312 amvdec_write_dos(core, AV_SCRATCH_1, h264->ref_paddr);
313 /* End of ref MV */
314 amvdec_write_dos(core, AV_SCRATCH_4, h264->ref_paddr +
h264->ref_size);
315
316 amvdec_write_dos(core, AV_SCRATCH_0, (h264->max_refs << 24) |
317 (sess->num_dst_bufs << 16)
|
318 ((h264->max_refs - 1) <<
8));
319 }
320
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Subject: [PATCH] staging: media: meson: vdec: declare u32 as static const
Declared 32 bit unsigned int as static constant inside a function and
replaced u32[] {x,y} as canvas3, canvas4 in codec_h264.c
This indicates the value of canvas indexes will remain constant throughout
execution.
Signed-off-by: Mitali Borkar
---
drivers/staging/media/meson/vdec/codec_h264.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/media/meson/vdec/codec_h264.c
b/drivers/staging/media/meson/vdec/codec_h264.c
index c61128fc4bb9..ea86e9e1c447 100644
--- a/drivers/staging/media/meson/vdec/codec_h264.c
+++ b/drivers/staging/media/meson/vdec/codec_h264.c
@@ -287,10 +287,10 @@ static void codec_h264_resume(struct amvdec_session *sess)
struct amvdec_core *core = sess->core;
struct codec_h264 *h264 = sess->priv;
u32 mb_width, mb_height, mb_total;
+ static const u32[] canvas3 = { ANCO_CANVAS_ADDR, 0 };
+ static const u32[] canvas4 = { 24, 0 };
- amvdec_set_canvases(sess,
- (u32[]){ ANC0_CANVAS_ADDR, 0 },
- (u32[]){ 24, 0 });
+ amvdec_set_canvases(sess, canvas3, canvas4);
dev_dbg(core->dev, "max_refs = %u; actual_dpb_size = %u\n",
h264->max_refs, sess->num_dst_bufs);
--
2.30.2
[no subject]
Hallo Mein Name ist George Mike. Ich bin von Beruf Rechtsanwalt. Ich möchte Ihnen anbieten der nächste Verwandte meines Klienten. Sie erben die Summe von (8,5 Millionen US-Dollar) Dollar, die mein Kunde vor seinem Tod auf der Bank gelassen hat. Mein Kunde ist ein Staatsbürger Ihres Landes, der mit seiner Frau bei einem Autounfall ums Leben gekommen ist und einziger Sohn. Ich habe Anspruch auf 50% des Gesamtfonds, während 50% dies tun sein für dich. Bitte kontaktieren Sie meine private E-Mail hier für weitere Informationen: georgemike7...@gmail.com Vielen Dank im Voraus, Mr. George Mike,
Re: [PATCH v3 0/3] Modify subject description and rectify spelling mistake.
On Sun, Apr 11, 2021 at 03:25:05PM +0530, Mitali Borkar wrote: > This patch fixes style issues "this" is not a patch :( And the subject line here also needs fixed up. thanks, greg k-h
[PATCH v3 0/3] Modify subject description and rectify spelling mistake.
This patch fixes style issues Changes from v2:- [PATCH v2 1/3]:- Modified subject description. [PATCH V2 2/3]:- No changes. [PATCH v2 3/3]:- Rectified spelling mistake in subject description. Changes from v1:- [PATCH 1/3]:- Removed unnecessary parentheses around boolean expression. Changes has been made in v2. [PATCH 2/3]:- No changes. [PATCH 3/3]:- No changes. Mitali Borkar (3): staging: rtl8192e: remove parentheses around boolean expression staging: rtl8192e: remove unnecessary ftrace-like logging staging: rtl8192e: remove unnecessary parentheses drivers/staging/rtl8192e/rtl819x_HTProc.c | 18 ++- 1 files changed, 7 insertions(+), 11 deletions(-) -- 2.30.2
[no subject]
Bitte ich möchte wissen, ob Sie meine vorherige Nachricht erhalten haben, danke.
[no subject]
Dia bom Sou Stephen Bordeaux, advogado do escritório de advocacia de Bordeaux. Entrei em contato com você a respeito do patrimônio do Fundo do Falecido Dr. Edwin, Oito Milhões e Quinhentos Mil Dólares, a serem repatriados para sua conta. Além disso, nesta transação, quero que você responda confidencialmente. Stephen Bordéus
Re: Subject: Re: [PATCH v3] kbuild: add support for zstd compressed modules
On Fri, Apr 9, 2021 at 1:31 PM Sedat Dilek wrote: > > On Fri, Apr 9, 2021 at 1:10 PM Piotr Gorski wrote: > > > > I originally posted the patch in a different form [1] even before > > Masahiro's changes. > > I've been testing this solution since December last year and posted it in > > March this year, > > after I made sure everything was working fine. This patch was tested by > > Oleksandr and he also didn't report any objections. [2] > > > > Masahiro notified me about the planned changes [3] and asked me to resend > > this patch, adjusted to those changes, which I did. > > > > My current logs: > > > > lucjan@archlinux ~ $ zgrep CONFIG_DEBUG_INFO /proc/config.gz > > CONFIG_DEBUG_INFO=y > > # CONFIG_DEBUG_INFO_REDUCED is not set > > # CONFIG_DEBUG_INFO_COMPRESSED is not set > > # CONFIG_DEBUG_INFO_SPLIT is not set > > CONFIG_DEBUG_INFO_DWARF4=y > > CONFIG_DEBUG_INFO_BTF=y > > CONFIG_DEBUG_INFO_BTF_MODULES=y > > lucjan@archlinux ~ $ zgrep CONFIG_MODULE_COMPRESS_ZSTD /proc/config.gz > > CONFIG_MODULE_COMPRESS_ZSTD=y > > CONFIG_MODULE_COMPRESS_ZSTD_LEVEL=19 > > > > Pay no attention to CONFIG_MODULE_COMPRESS_ZSTD_LEVEL as this is not in the > > upstream, it's an additional patch I use. > > > > The only difference - I don't use clang. Maybe those who use will comment > > on this. > > I relied on the opinions of Oleksander and a dozen other users who reported > > no errors in using zstd module compression. > > > > [1] https://marc.info/?l=linux-kbuild=161710402402989=2 > > > > [2] https://marc.info/?l=linux-kbuild=161710503403517=2 > > > > [3] https://marc.info/?l=linux-kbuild=161780602730829=2 > > I am a big fan of ZSTD and have it as default in all available Linux > Kconfigs and Debian's initramfs-tools. > So, I am highly interested in getting this fixed. > > Unfortunately, I have thrown away my yesterday's Clang-LTO build and > switched to Clang-CFI with builddeb - should do handle the same way. > > I see three iwlwifi.ko (as an example): > > $ LC_ALL=C ll drivers/net/wireless/intel/iwlwifi/iwlwifi.ko > -rw-r--r-- 1 dileks dileks 8.2M Apr 9 11:07 > drivers/net/wireless/intel/iwlwifi/iwlwifi.ko > > $ file drivers/net/wireless/intel/iwlwifi/iwlwifi.ko > drivers/net/wireless/intel/iwlwifi/iwlwifi.ko: ELF 64-bit LSB > relocatable, x86-64, version 1 (SYSV), > BuildID[sha1]=78d593f4fd2b8efe81caeb8f1ea729107a33e244, with > debug_info, not stripped > > That iwlwifi.ko with debug-info is optimized when moving to > debian/linux-image-dbg directory: > > $ LC_ALL=C ll > debian/linux-image-dbg/usr/lib/debug/lib/modules/5.12.0-rc6-5-amd64-clang12-cfi/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko > -rw-r--r-- 1 dileks dileks 7.9M Apr 9 11:18 > debian/linux-image-dbg/usr/lib/debug/lib/modules/5.12.0-rc6-5-amd64-clang12-cfi/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko > > $ file > debian/linux-image-dbg/usr/lib/debug/lib/modules/5.12.0-rc6-5-amd64-clang12-cfi/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko > debian/linux-image-dbg/usr/lib/debug/lib/modules/5.12.0-rc6-5-amd64-clang12-cfi/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko: > ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), > BuildID[sha1]=78d593f4fd2b8efe81caeb8f1ea729107a33e244, with > debug_info, not stripped > > And think it's shrunk down and included debian/linux-image directory: > > $ LC_ALL=C ll > debian/linux-image/lib/modules/5.12.0-rc6-5-amd64-clang12-cfi/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko > -rw-r--r-- 1 dileks dileks 694K Apr 9 11:18 > debian/linux-image/lib/modules/5.12.0-rc6-5-amd64-clang12-cfi/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko > > $ file > debian/linux-image/lib/modules/5.12.0-rc6-5-amd64-clang12-cfi/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko > debian/linux-image/lib/modules/5.12.0-rc6-5-amd64-clang12-cfi/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko: > ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), > BuildID[sha1]=78d593f4fd2b8efe81caeb8f1ea729107a33e244, not stripped > > I speculate both iwlwifi.ko below debian directory should be ZSTD-compressed. > Fact is the one with debug-info is done correctly. > Might be builddeb script needs a special treatment. > OK, I see (sorry Gmail truncates my paste of snippet). We need to add in this block a CONFIG_MODULE_COMPRESS_XXX handling: [ scripts/package/builddeb ] #159: if is_enabled CONFIG_MODULES; then ... #184: fi Maybe other scripts in scripts/package/ directory, too. What do you say Masahiro? I have to admit I never used any compression for kernel-modules before and after recent changes in . - Sedat - [1] https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/tree/scripts/package/builddeb?h=kbuild#n159
Re: Subject: Re: [PATCH v3] kbuild: add support for zstd compressed modules
On Fri, Apr 9, 2021 at 1:10 PM Piotr Gorski wrote: > > I originally posted the patch in a different form [1] even before Masahiro's > changes. > I've been testing this solution since December last year and posted it in > March this year, > after I made sure everything was working fine. This patch was tested by > Oleksandr and he also didn't report any objections. [2] > > Masahiro notified me about the planned changes [3] and asked me to resend > this patch, adjusted to those changes, which I did. > > My current logs: > > lucjan@archlinux ~ $ zgrep CONFIG_DEBUG_INFO /proc/config.gz > CONFIG_DEBUG_INFO=y > # CONFIG_DEBUG_INFO_REDUCED is not set > # CONFIG_DEBUG_INFO_COMPRESSED is not set > # CONFIG_DEBUG_INFO_SPLIT is not set > CONFIG_DEBUG_INFO_DWARF4=y > CONFIG_DEBUG_INFO_BTF=y > CONFIG_DEBUG_INFO_BTF_MODULES=y > lucjan@archlinux ~ $ zgrep CONFIG_MODULE_COMPRESS_ZSTD /proc/config.gz > CONFIG_MODULE_COMPRESS_ZSTD=y > CONFIG_MODULE_COMPRESS_ZSTD_LEVEL=19 > > Pay no attention to CONFIG_MODULE_COMPRESS_ZSTD_LEVEL as this is not in the > upstream, it's an additional patch I use. > > The only difference - I don't use clang. Maybe those who use will comment on > this. > I relied on the opinions of Oleksander and a dozen other users who reported > no errors in using zstd module compression. > > [1] https://marc.info/?l=linux-kbuild=161710402402989=2 > > [2] https://marc.info/?l=linux-kbuild=161710503403517=2 > > [3] https://marc.info/?l=linux-kbuild=161780602730829=2 I am a big fan of ZSTD and have it as default in all available Linux Kconfigs and Debian's initramfs-tools. So, I am highly interested in getting this fixed. Unfortunately, I have thrown away my yesterday's Clang-LTO build and switched to Clang-CFI with builddeb - should do handle the same way. I see three iwlwifi.ko (as an example): $ LC_ALL=C ll drivers/net/wireless/intel/iwlwifi/iwlwifi.ko -rw-r--r-- 1 dileks dileks 8.2M Apr 9 11:07 drivers/net/wireless/intel/iwlwifi/iwlwifi.ko $ file drivers/net/wireless/intel/iwlwifi/iwlwifi.ko drivers/net/wireless/intel/iwlwifi/iwlwifi.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), BuildID[sha1]=78d593f4fd2b8efe81caeb8f1ea729107a33e244, with debug_info, not stripped That iwlwifi.ko with debug-info is optimized when moving to debian/linux-image-dbg directory: $ LC_ALL=C ll debian/linux-image-dbg/usr/lib/debug/lib/modules/5.12.0-rc6-5-amd64-clang12-cfi/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko -rw-r--r-- 1 dileks dileks 7.9M Apr 9 11:18 debian/linux-image-dbg/usr/lib/debug/lib/modules/5.12.0-rc6-5-amd64-clang12-cfi/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko $ file debian/linux-image-dbg/usr/lib/debug/lib/modules/5.12.0-rc6-5-amd64-clang12-cfi/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko debian/linux-image-dbg/usr/lib/debug/lib/modules/5.12.0-rc6-5-amd64-clang12-cfi/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), BuildID[sha1]=78d593f4fd2b8efe81caeb8f1ea729107a33e244, with debug_info, not stripped And think it's shrunk down and included debian/linux-image directory: $ LC_ALL=C ll debian/linux-image/lib/modules/5.12.0-rc6-5-amd64-clang12-cfi/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko -rw-r--r-- 1 dileks dileks 694K Apr 9 11:18 debian/linux-image/lib/modules/5.12.0-rc6-5-amd64-clang12-cfi/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko $ file debian/linux-image/lib/modules/5.12.0-rc6-5-amd64-clang12-cfi/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko debian/linux-image/lib/modules/5.12.0-rc6-5-amd64-clang12-cfi/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), BuildID[sha1]=78d593f4fd2b8efe81caeb8f1ea729107a33e244, not stripped I speculate both iwlwifi.ko below debian directory should be ZSTD-compressed. Fact is the one with debug-info is done correctly. Might be builddeb script needs a special treatment. - Sedat -
Subject: Re: [PATCH v3] kbuild: add support for zstd compressed modules
I originally posted the patch in a different form [1] even before Masahiro's changes. I've been testing this solution since December last year and posted it in March this year, after I made sure everything was working fine. This patch was tested by Oleksandr and he also didn't report any objections. [2] Masahiro notified me about the planned changes [3] and asked me to resend this patch, adjusted to those changes, which I did. My current logs: lucjan@archlinux ~ $ zgrep CONFIG_DEBUG_INFO /proc/config.gz CONFIG_DEBUG_INFO=y # CONFIG_DEBUG_INFO_REDUCED is not set # CONFIG_DEBUG_INFO_COMPRESSED is not set # CONFIG_DEBUG_INFO_SPLIT is not set CONFIG_DEBUG_INFO_DWARF4=y CONFIG_DEBUG_INFO_BTF=y CONFIG_DEBUG_INFO_BTF_MODULES=y lucjan@archlinux ~ $ zgrep CONFIG_MODULE_COMPRESS_ZSTD /proc/config.gz CONFIG_MODULE_COMPRESS_ZSTD=y CONFIG_MODULE_COMPRESS_ZSTD_LEVEL=19 Pay no attention to CONFIG_MODULE_COMPRESS_ZSTD_LEVEL as this is not in the upstream, it's an additional patch I use. The only difference - I don't use clang. Maybe those who use will comment on this. I relied on the opinions of Oleksander and a dozen other users who reported no errors in using zstd module compression. [1] https://marc.info/?l=linux-kbuild=161710402402989=2 [2] https://marc.info/?l=linux-kbuild=161710503403517=2 [3] https://marc.info/?l=linux-kbuild=161780602730829=2
Re: Subject: Re: [PATCH v3] kbuild: add support for zstd compressed modules
On Thu, Apr 8, 2021 at 11:05 PM Piotr Gorski wrote: > > No, the --rm option is essential. xz and gzip have the --rm option built in > as opposed to zstd, which is why I used it. I've been using zstd module > compression since last december (although I set a different compression level > on mine) and everything works fine. Oleksandr also tested it at his place and > didn't report any objections. [ CC me I am not subscribed to linux-kbuild or linux-kernel ] [ CC Nick ] Unfortunately, I do not find my initial posting which has all information. I add the link to the thread on linux-kbuild ML. So, I gave you as much information as I have (linux-config, make-line etc.) and you write "everything works fine"? What do you mean by "everything" - different compressors and none? Is that working "fine"? What build environment do you use? Here: Debian/testing AMD64. Did you try with... CONFIG_DEBUG_INFO=y CONFIG_DEBUG_INFO_DWARF5=y CONFIG_MODULE_COMPRESS_ZSTD=y ...Kconfigs enabled? As said I use builddeb from scripts directory to generate my Debian packages. Any chance you can test with builddeb? I have enabled Clang-LTO Kconfig. Tried with Clang-LTO Kconfig? This worked *before* and *after*... kbuild: add support for zstd compressed modules kbuild: remove CONFIG_MODULE_COMPRESS (CC Nick as he is listed as a reviewer here) ... not within my build-environment. For me this is a *regression*. - Sedat - [1] https://marc.info/?t=16179091462=1=2
Subject: Re: [PATCH v3] kbuild: add support for zstd compressed modules
No, the --rm option is essential. xz and gzip have the --rm option built in as opposed to zstd, which is why I used it. I've been using zstd module compression since last december (although I set a different compression level on mine) and everything works fine. Oleksandr also tested it at his place and didn't report any objections.
Re: [PATCH v2 00/49] *** SUBJECT HERE ***
On Wed, Apr 07, 2021 at 10:32:53AM +0200, Greg KH wrote: > On Wed, Apr 07, 2021 at 09:32:29AM +0200, Greg KH wrote: > > On Wed, Apr 07, 2021 at 12:15:22AM -0700, Pavle Rohalj wrote: > > > On Wed, Apr 07, 2021 at 09:08:07AM +0200, Greg KH wrote: > > > > On Tue, Apr 06, 2021 at 11:35:54PM -0700, Pavle Rohalj wrote: > > > > > Changes in v2: > > > > > - Removed type information from variable names > > > > > - Broken up the changes into smaller patches > > > > > > > > Your subject is very odd :( > > > > > > Sorry about that, I overlooked the fact that I reran format-patch. The > > > subject should be: > > > > > > [PATCH] staging: sm750fb: Convert camel case to snake case > > > > > > Should I resubmit? > > > > Not yet, let me review these first, I think they might need some work... > > > > Ok, now you can fix them up, I stopped after reviewing patch 02/49, > these need some work. > > thanks, > > greg k-h Will do. Thank you. -Pavle
Re: [PATCH v2 00/49] *** SUBJECT HERE ***
On Wed, Apr 07, 2021 at 09:11:18AM +0200, Fabio Aiuto wrote: > On Tue, Apr 06, 2021 at 11:35:54PM -0700, Pavle Rohalj wrote: > > Changes in v2: > > - Removed type information from variable names > > - Broken up the changes into smaller patches > > Hi Pavle, > > I think you missed the subject in cover letter, but maybe > is not a relevant issue... (Resending this because I realized I did not reply to everyone) Hi Fabio, I did, my bad. This patchset is an attempt to fix checkpatch.pl checks for camel case usage in sm750fb driver. -Pavle
Re: [PATCH v2 00/49] *** SUBJECT HERE ***
On Wed, Apr 07, 2021 at 09:32:29AM +0200, Greg KH wrote: > On Wed, Apr 07, 2021 at 12:15:22AM -0700, Pavle Rohalj wrote: > > On Wed, Apr 07, 2021 at 09:08:07AM +0200, Greg KH wrote: > > > On Tue, Apr 06, 2021 at 11:35:54PM -0700, Pavle Rohalj wrote: > > > > Changes in v2: > > > > - Removed type information from variable names > > > > - Broken up the changes into smaller patches > > > > > > Your subject is very odd :( > > > > Sorry about that, I overlooked the fact that I reran format-patch. The > > subject should be: > > > > [PATCH] staging: sm750fb: Convert camel case to snake case > > > > Should I resubmit? > > Not yet, let me review these first, I think they might need some work... > Ok, now you can fix them up, I stopped after reviewing patch 02/49, these need some work. thanks, greg k-h
Re: [PATCH v2 00/49] *** SUBJECT HERE ***
On Wed, Apr 07, 2021 at 12:15:22AM -0700, Pavle Rohalj wrote: > On Wed, Apr 07, 2021 at 09:08:07AM +0200, Greg KH wrote: > > On Tue, Apr 06, 2021 at 11:35:54PM -0700, Pavle Rohalj wrote: > > > Changes in v2: > > > - Removed type information from variable names > > > - Broken up the changes into smaller patches > > > > Your subject is very odd :( > > Sorry about that, I overlooked the fact that I reran format-patch. The > subject should be: > > [PATCH] staging: sm750fb: Convert camel case to snake case > > Should I resubmit? Not yet, let me review these first, I think they might need some work...
Re: [PATCH v2 00/49] *** SUBJECT HERE ***
On Wed, Apr 07, 2021 at 09:08:07AM +0200, Greg KH wrote: > On Tue, Apr 06, 2021 at 11:35:54PM -0700, Pavle Rohalj wrote: > > Changes in v2: > > - Removed type information from variable names > > - Broken up the changes into smaller patches > > Your subject is very odd :( Sorry about that, I overlooked the fact that I reran format-patch. The subject should be: [PATCH] staging: sm750fb: Convert camel case to snake case Should I resubmit? -Pavle
Re: [PATCH v2 00/49] *** SUBJECT HERE ***
On Tue, Apr 06, 2021 at 11:35:54PM -0700, Pavle Rohalj wrote: > Changes in v2: > - Removed type information from variable names > - Broken up the changes into smaller patches Hi Pavle, I think you missed the subject in cover letter, but maybe is not a relevant issue...
Re: [PATCH v2 00/49] *** SUBJECT HERE ***
On Tue, Apr 06, 2021 at 11:35:54PM -0700, Pavle Rohalj wrote: > Changes in v2: > - Removed type information from variable names > - Broken up the changes into smaller patches Your subject is very odd :(
[PATCH v2 00/49] *** SUBJECT HERE ***
Changes in v2: - Removed type information from variable names - Broken up the changes into smaller patches Pavle Rohalj (49): staging: sm750fb: Update dvi_ctrl_device to snake case staging: sm750fb: Rename dviInit to dvi_init and update param names staging: sm750fb: Update param names of PFN_DVICTRL_INIT function pointer staging: sm750fb: Remove type names in variables and type definitions staging: sm750fb: Remove remaining camel case names in ddk750_dvi.h staging: sm750fb: Update displayControlAdjust_SM750LE to snake case staging: sm750fb: Update programModeRegisters to snake case staging: sm750fb: Update enum values in dpms to snake case staging: sm750fb: Rename sm750_set_power_mode function parameter staging: sm750fb: Rename ddk750_setModeTiming to ddk750_set_mode_timing staging: sm750fb: Rename i2cWriteReg and i2cReadReg to snake case staging: sm750fb: Rename vendorID local variable to snake case staging: sm750fb: Rename deviceID local variable to snake case staging: sm750fb: Rename sii164SelectHotPlugDetectionMode to snake case staging: sm750fb: Rename gDviCtrlChipName to snake case staging: sm750fb: Update function parameter names in ddk750_sii164.c staging: sm750fb: Rename local variables to snake case staging: sm750fb: Rename function params of sii164_init_chip staging: sm750fb: Rename function parameter of sii164_enable_hot_plug_detection staging: sm750fb: Update function parameter names to snake case staging: sm750fb: Rename function write_dpPort to snake case staging: sm750fb: Update local variable in sm750_hw_copyarea to snake case staging: sm750fb: Update local variables in sm750_hw_imageblit to snake case staging: sm750fb: Update local variable in sm750_hw_fillrect to snake case staging: sm750fb: Rename deGetTransparency to snake case staging: sm750fb: Update function parameter of sm750_hw_imageblit to snake case staging: sm750fb: Rename function params to snake case in sm750_accel.h staging: sm750fb: Update members of lynx_cursor to snake case staging: sm750fb: Rename function sm750_hw_cursor_setSize to snake case staging: sm750fb: Rename function sm750_hw_cursor_setPos to snake case staging: sm750fb: Rename function sm750_hw_cursor_setColor to snake case staging: sm750fb: Rename function sm750_hw_cursor_setData to snake case staging: sm750fb: Rename function hw_sm750_crtc_setMode to snake case staging: sm750fb: Update members of init_status struct to snake case staging: sm750fb: Update members of sm750_dev struct to snake case staging: sm750fb: Update members of lynxfb_crtc struct to snake case staging: sm750fb: Rename function hw_sm750_output_setMode to snake case staging: sm750fb: Rename function hw_sm750_setColReg to snake case staging: sm750fb: Rename functions *_setBLANK to snake case staging: sm750fb: Rename function sm750_hw_cursor_setData2 to snake case staging: sm750fb: Rename function hw_sm750_initAccel to snake case staging: sm750fb: Rename functions *_deWait to snake case staging: sm750fb: Update members of lynx_accel struct to snake case staging: sm750fb: Rename function hw_sm750_crtc_checkMode to snake case staging: sm750fb: Rename sii164_set_power function parameter staging: sm750fb: Rename local variable Bpp to bpp in sm750.c staging: sm750fb: Rename proc_setBLANK member of lynxfb_output struct staging: sm750fb: Rename fixId to fix_id staging: sm750fb: Update members of sm750_pnltype struct to snake case drivers/staging/sm750fb/ddk750_dvi.c| 32 ++--- drivers/staging/sm750fb/ddk750_dvi.h| 80 ++--- drivers/staging/sm750fb/ddk750_mode.c | 88 +++--- drivers/staging/sm750fb/ddk750_mode.h | 2 +- drivers/staging/sm750fb/ddk750_power.h | 10 +- drivers/staging/sm750fb/ddk750_sii164.c | 152 drivers/staging/sm750fb/ddk750_sii164.h | 40 +++ drivers/staging/sm750fb/sm750.c | 130 ++-- drivers/staging/sm750fb/sm750.h | 56 - drivers/staging/sm750fb/sm750_accel.c | 148 +++ drivers/staging/sm750fb/sm750_accel.h | 42 +++ drivers/staging/sm750fb/sm750_cursor.c | 14 +-- drivers/staging/sm750fb/sm750_cursor.h | 10 +- drivers/staging/sm750fb/sm750_hw.c | 56 - 14 files changed, 430 insertions(+), 430 deletions(-) -- 2.30.2
[no subject]
Ich hoffe, diese Mail findet Sie und Ihre Lieben sicher und gesund. Ich habe einen Brief an Ihre E-Mail geschickt, aber keine Antwort von Ihnen erhalten. Sie haben meine vorherige E-Mail erhalten? Bitte kommen Sie so schnell wie möglich zurück. Beste Wünsche Johnson Williams.
[no subject]
cześć Nazywam się George Mike. Z zawodu jestem prawnikiem. Chcę ci zaoferować najbliższy krewny mojego klienta. Odziedziczysz sumę (8,5 miliona dolarów) dolarów, które mój klient zostawił w banku przed śmiercią. Mój klient jest obywatelem twojego kraju, który zginął wraz z żoną w wypadku samochodowym i jedyny syn. Będę uprawniony do 50% całkowitego funduszu, podczas gdy 50% będzie Być dla ciebie. Aby uzyskać więcej informacji, skontaktuj się z moim prywatnym adresem e-mail: georgemike7...@gmail.com Z góry bardzo dziękuję, Panie George Mike,
[no subject]
outreachy-ker...@googlegroups.com, mitaliborkar...@gmail.com
Bcc:
Subject: [PATCH] staging: qlge:remove else after break
Reply-To:
Fixed Warning:- else is not needed after break
break terminates the loop if encountered. else is unnecessary and
increases indenatation
Signed-off-by: Mitali Borkar
---
drivers/staging/qlge/qlge_mpi.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/staging/qlge/qlge_mpi.c b/drivers/staging/qlge/qlge_mpi.c
index 2630ebf50341..3a49f187203b 100644
--- a/drivers/staging/qlge/qlge_mpi.c
+++ b/drivers/staging/qlge/qlge_mpi.c
@@ -935,13 +935,11 @@ static int qlge_idc_wait(struct qlge_adapter *qdev)
netif_err(qdev, drv, qdev->ndev, "IDC Success.\n");
status = 0;
break;
- } else {
- netif_err(qdev, drv, qdev->ndev,
+ } netif_err(qdev, drv, qdev->ndev,
"IDC: Invalid State 0x%.04x.\n",
mbcp->mbox_out[0]);
status = -EIO;
break;
- }
}
return status;
--
2.30.2
[no subject]
Hallo, Houd er rekening mee dat deze e-mail die naar uw postvak is gekomen geen fout is, maar specifiek aan u is gericht voor uw overweging. Ik heb een voorstel van ($7.500.000.00) achtergelaten door mijn overleden klant Ingenieur Carlos die dezelfde achternaam bij jou draagt, die hier in Lomé Togo werkte en woonde. Mijn overleden cliënt en familie waren betrokken bij een auto-ongeluk dat hun leven kostte. Ik neem contact met u op als de nabestaanden van de overledene zodat u het geld ontvangen bij claims. Ik zal u meer details geven over deze transactie uit uw reactie. Beste wensen Thompson Michael.
[no subject]
Dobry dzień Nazywam się Stephen Bordeaux, prawnik z firmy prawniczej Bordeaux. Skontaktowałem się z tobą w sprawie majątku zmarłego doktora Edwin, który miał zostać przeniesiony na twoje konto. Osiem milionów pięćset tysięcy dolarów. Ponadto w tej transakcji chcę, abyś odpowiedział poufnie. Stephen Bordeaux
[no subject]
Subject: [PATCH v8 0/9] Updates to MHI channel handling MHI specification shows a state machine with support for STOP channel command and the validity of certain state transitions. MHI host currently does not provide any mechanism to stop a channel and restart it without resetting it. There are also times when the device moves on to a different execution environment while client drivers on the host are unaware of it and still attempt to reset the channels facing unnecessary timeouts. This series addresses the above areas to provide support for stopping an MHI channel, resuming it back, improved documentation and improving upon channel state machine handling in general. This set of patches was tested on arm64 and x86_64 architecture. v8: -Split the state machine improvements patch to three patches as per review v7: -Tested on x86_64 architecture -Drop the patch "Do not clear channel context more than once" as issue is fixed differently using "bus: mhi: core: Fix double dma free()" -Update the commit text to better reflect changes on state machine improvements v6: -Dropped the patch which introduced start/stop transfer APIs for lack of users -Updated error handling and debug prints on channel handling improvements patch -Improved commit text to better explain certain patches based on review comments -Removed references to new APIs from the documentation improvement patch v5: -Added reviewed-by tags from Hemant I missed earlier -Added patch to prevent kernel warnings on clearing channel context twice v4: -Updated commit text/descriptions and addressed checkpatch checks -Added context validity check before starting/stopping channels from new API -Added patch to clear channel context configuration after reset/unprepare v3: -Updated documentation for channel transfer APIs to highlight differences -Create separate patch for "allowing channel to be disabled from stopped state" v2: -Renamed the newly introduced APIs to mhi_start_transfer() / mhi_stop_transfer() -Added improved documentation to avoid confusion with the new APIs -Removed the __ prefix from mhi_unprepare_channel() API for consistency. Bhaumik Bhatt (9): bus: mhi: core: Allow sending the STOP channel command bus: mhi: core: Clear context for stopped channels from remove() bus: mhi: core: Improvements to the channel handling state machine bus: mhi: core: Update debug messages to use client device bus: mhi: core: Hold device wake for channel update commands bus: mhi: core: Clear configuration from channel context during reset bus: mhi: core: Check channel execution environment before issuing reset bus: mhi: core: Remove __ prefix for MHI channel unprepare function bus: mhi: Improve documentation on channel transfer setup APIs drivers/bus/mhi/core/init.c | 22 - drivers/bus/mhi/core/internal.h | 12 +++ drivers/bus/mhi/core/main.c | 190 include/linux/mhi.h | 18 +++- 4 files changed, 162 insertions(+), 80 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[no subject]
my name is calantha camara i want to talk to you
[no subject]
Vennligst jeg vil vite om du har mine tidligere meldinger.
[no subject]
From: Mark-PK Tsai To: Marc Zyngier Cc: Mark-PK Tsai , Daniel Palmer , Thomas Gleixner , Matthias Brugger , , , , Subject: [PATCH v4] irqchip/irq-mst: Support polarity configuration Date: Mon, 15 Mar 2021 21:18:48 +0800 > Support irq polarity configuration and save and restore the config > when system suspend and resume. > > Signed-off-by: Mark-PK Tsai Hi, Could anyone please help to review this patch?
[no subject]
Hej min kære, jeg vil gerne vide, om du har min tidligere besked, tak.
[no subject]
[no subject]
[no subject]
[no subject]
[no subject]
Git message updated.
[no subject]
Ik wil alsjeblieft weten of je mijn vorige berichten hebt ontvangen.
[no subject]
Ik wil alsjeblieft weten of je mijn vorige berichten hebt ontvangen.
[no subject]
subscribe linux-kernel
[no subject]
-- Hello i'm Barrister Daven Bango, from Togo in west Africa, i sent you a message before concerning a transaction of $12.5 million dollars that my late client who is also a citizen of your country, deposited in the bank here in my country before his sudden death, and you didn't reply to me, please reply to me as soon as possible, for more explanations. Best regards, Barrister: Daven Bango Phone: +22891667276
[no subject]
Hallo Ich heiße George Mike. Ich bin von Beruf Rechtsanwalt. Ich möchte dir anbieten engster Verwandter meines Klienten. Sie erben die Gesamtsumme (8,5 Millionen US-Dollar). Dollar, die mein Kunde vor seinem Tod auf der Bank gelassen hat. Mein Klient ist ein Staatsangehöriger Ihres Landes, der mit seiner Frau bei einem Autounfall ums Leben gekommen ist und einziger Sohn. Ich habe Anspruch auf 50% des Gesamtfonds, während 50% davon berechtigt sind Sein für dich. Für weitere Informationen wenden Sie sich bitte an meine private E-Mail-Adresse: georgemike7...@gmail.com Vielen Dank im Voraus, Herr George Mike,
[no subject]
Linux https://bitly.com/3sZmFP2 Chris
[no subject]
vHallo Ich heiße George Mike. Ich bin von Beruf Rechtsanwalt. Ich möchte dir anbieten engster Verwandter meines Klienten. Sie erben die Gesamtsumme (8,5 Millionen US-Dollar). Dollar, die mein Kunde vor seinem Tod auf der Bank gelassen hat. Mein Klient ist ein Staatsangehöriger Ihres Landes, der mit seiner Frau bei einem Autounfall ums Leben gekommen ist und einziger Sohn. Ich habe Anspruch auf 50% des Gesamtfonds, während 50% davon berechtigt sind Sein für dich. Für weitere Informationen wenden Sie sich bitte an meine private E-Mail-Adresse: georgemike7...@gmail.com Vielen Dank im Voraus, Herr George Mike,
Re: [PATCH v24 00/14] Subject: Introduce Data Access MONitor (DAMON)
On Thu, 4 Feb 2021 16:31:36 +0100 SeongJae Park wrote: > From: SeongJae Park [...] > > Introduction > > > DAMON is a data access monitoring framework for the Linux kernel. The core > mechanisms of DAMON called 'region based sampling' and 'adaptive regions > adjustment' (refer to 'mechanisms.rst' in the 11th patch of this patchset for > the detail) make it > > - accurate (The monitored information is useful for DRAM level memory >management. It might not appropriate for Cache-level accuracy, though.), > - light-weight (The monitoring overhead is low enough to be applied online >while making no impact on the performance of the target workloads.), and > - scalable (the upper-bound of the instrumentation overhead is controllable >regardless of the size of target workloads.). > > Using this framework, therefore, several memory management mechanisms such as > reclamation and THP can be optimized to aware real data access patterns. > Experimental access pattern aware memory management optimization works that > incurring high instrumentation overhead will be able to have another try. > > Though DAMON is for kernel subsystems, it can be easily exposed to the user > space by writing a DAMON-wrapper kernel subsystem. Then, user space users who > have some special workloads will be able to write personalized tools or > applications for deeper understanding and specialized optimizations of their > systems. > [...] > > Baseline and Complete Git Trees > === > > The patches are based on the v5.10. You can also clone the complete git > tree: > > $ git clone git://github.com/sjp38/linux -b damon/patches/v24 > > The web is also available: > https://github.com/sjp38/linux/releases/tag/damon/patches/v24 > > There are a couple of trees for entire DAMON patchset series. It includes > future features. The first one[1] contains the changes for latest release, > while the other one[2] contains the changes for next release. > > [1] https://github.com/sjp38/linux/tree/damon/master > [2] https://github.com/sjp38/linux/tree/damon/next For people who prefer LTS kernels, I decided to maintain two more trees that repectively based on latest two LTS kernels and contains backports of the latest 'damon/master' tree, as below. Please use those if you want to test DAMON but using LTS. - For v5.4.y: https://github.com/sjp38/linux/tree/damon/for-v5.4.y - For v5.10.y: https://github.com/sjp38/linux/tree/damon/for-v5.10.y Thanks, SeongJae Park
[no subject]
-- Good Afternoon from UK, How are you? we guess you're well, Our office has sent you a message last week but there is no answer from you to date, did you read our notice? get back to us upon the receipt of this mail. Thank You, Mr. Hennager James Craig IMF Office London United Kingdom
[no subject]
Hello my friend I have sent several emails, have you received my previous complaints? Willson J. Mutanda Email: willsonmutand...@gmail.com
Re: [PATCH v24 00/14] Subject: Introduce Data Access MONitor (DAMON)
On Thu, 4 Feb 2021 16:31:36 +0100 SeongJae Park wrote: > From: SeongJae Park > [...] > > Introduction > > > DAMON is a data access monitoring framework for the Linux kernel. The core > mechanisms of DAMON called 'region based sampling' and 'adaptive regions > adjustment' (refer to 'mechanisms.rst' in the 11th patch of this patchset for > the detail) make it > > - accurate (The monitored information is useful for DRAM level memory >management. It might not appropriate for Cache-level accuracy, though.), > - light-weight (The monitoring overhead is low enough to be applied online >while making no impact on the performance of the target workloads.), and > - scalable (the upper-bound of the instrumentation overhead is controllable >regardless of the size of target workloads.). > > Using this framework, therefore, several memory management mechanisms such as > reclamation and THP can be optimized to aware real data access patterns. > Experimental access pattern aware memory management optimization works that > incurring high instrumentation overhead will be able to have another try. > > Though DAMON is for kernel subsystems, it can be easily exposed to the user > space by writing a DAMON-wrapper kernel subsystem. Then, user space users who > have some special workloads will be able to write personalized tools or > applications for deeper understanding and specialized optimizations of their > systems. > I realized I didn't introduce a good, intuitive example use case of DAMON for profiling so far, though DAMON is not for only profiling. One straightforward and realistic usage of DAMON as a profiling tool would be recording the monitoring results with callstack and visualize those by timeline together. For example, below link shows that visualization for a realistic workload, namely 'fft' in SPLASH-2X benchmark suite. From that, you can know there are three memory access bursting phases in the workload and 'FFT1DOnce.cons::prop.2()' looks responsible for the first and second hot phase, while 'Transpose()' is responsible for the last one. Now the programmer can take a deep look in the functions and optimize the code (e.g., adding madvise() or mlock() calls). https://damonitor.github.io/temporal/damon_callstack.png We used the approach for 'mlock()'-based optimization of a range of other realistic benchmark workloads. The optimized versions achieved up to about 2.5x performance improvement under memory pressure[1]. Note: I made the uppermost two figures in above 'fft' visualization (working set size and access frequency of each memory region by time) via the DAMON user space tool[2], while the lowermost one (callstack by time) is made using perf and speedscope[3]. We have no descent and totally automated tool for that yet (will be implemented soon, maybe under perf as a perf-script[4]), but you could reproduce that with below commands. $ # run the workload $ sudo damo record $(pidof ) & $ sudo perf record -g $(pidof ) $ # after your workload finished (you should also finish perf on your own) $ damo report wss --sortby time --plot wss.pdf $ damo report heats --heatmap freq.pdf $ sudo perf script | speedscope - $ # open wss.pdf and freq.pdf with our favorite pdf viewer [1] https://linuxplumbersconf.org/event/4/contributions/548/attachments/311/590/damon_ksummit19.pdf [2] https://lore.kernel.org/linux-mm/20201215115448.25633-8-sjp...@amazon.com/ [3] https://www.speedscope.app/ [4] https://lore.kernel.org/linux-mm/20210107120729.22328-1-sjp...@amazon.com/
[no subject]
>From Yoshio Furuyama # This line is ignored. From: Yoshio Furuyama Subject: In-Reply-To:
[no subject]
Hi Linus, Regular fixes for final, there is a ttm regression fix, dp-mst fix, one amdgpu revert, two i915 fixes, and some misc fixes for sun4i, xlnx, and vc4. All pretty quiet and don't think we have any known outstanding regressions. Dave. drm-fixes-2021-02-12: drm fixes for 5.11-rc8 ttm: - page pool regression fix. dp_mst: - Don't report un-attached ports as connected amdgpu: - Blank screen fix i915: - Ensure Type-C FIA is powered when initializing - Fix overlay frontbuffer tracking sun4i: - tcon1 sync polarity fix - Always set HDMI clock rate - Fix H6 HDMI PHY config - Fix H6 max frequency vc4: - Fix buffer overflow xlnx: - Fix memory leak The following changes since commit 92bf22614b21a2706f4993b278017e437f7785b3: Linux 5.11-rc7 (2021-02-07 13:57:38 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-02-12 for you to fetch changes up to 551c81853d6d3ff016269d62612e7cd0a53104ab: Merge branch 'drm-misc-fixes' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2021-02-12 13:38:51 +1000) drm fixes for 5.11-rc8 ttm: - page pool regression fix. dp_mst: - Don't report un-attached ports as connected amdgpu: - Blank screen fix i915: - Ensure Type-C FIA is powered when initializing - Fix overlay frontbuffer tracking sun4i: - tcon1 sync polarity fix - Always set HDMI clock rate - Fix H6 HDMI PHY config - Fix H6 max frequency vc4: - Fix buffer overflow xlnx: - Fix memory leak Alex Deucher (1): Revert "drm/amd/display: Update NV1x SR latency values" Christian König (1): drm/ttm: make sure pool pages are cleared Dave Airlie (3): Merge tag 'amd-drm-fixes-5.11-2021-02-10' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes Merge tag 'drm-intel-fixes-2021-02-11' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Merge branch 'drm-misc-fixes' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Imre Deak (2): drm/dp_mst: Don't report ports connected if nothing is attached to them drm/i915/tgl+: Make sure TypeC FIA is powered up when initializing it Jernej Skrabec (4): drm/sun4i: tcon: set sync polarity for tcon1 channel drm/sun4i: dw-hdmi: always set clock rate drm/sun4i: Fix H6 HDMI PHY configuration drm/sun4i: dw-hdmi: Fix max. frequency for H6 Maxime Ripard (1): drm/vc4: hvs: Fix buffer overflow with the dlist handling Quanyang Wang (1): drm/xlnx: fix kmemleak by sending vblank_event in atomic_disable Ville Syrjälä (1): drm/i915: Fix overlay frontbuffer tracking .../gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 4 +- drivers/gpu/drm/drm_dp_mst_topology.c | 1 + drivers/gpu/drm/i915/display/intel_overlay.c | 17 +++--- drivers/gpu/drm/i915/display/intel_tc.c| 67 -- drivers/gpu/drm/sun4i/sun4i_tcon.c | 25 drivers/gpu/drm/sun4i/sun4i_tcon.h | 6 ++ drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 10 +--- drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 1 - drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 26 +++-- drivers/gpu/drm/ttm/ttm_pool.c | 10 drivers/gpu/drm/vc4/vc4_plane.c| 18 -- drivers/gpu/drm/xlnx/zynqmp_disp.c | 15 +++-- 12 files changed, 122 insertions(+), 78 deletions(-)
[no subject]
Hi Linus,
Here's a set of minor keyrings fixes/cleanups that I've collected from
various people for the upcoming merge window.
A couple of them might, in theory, be visible to userspace:
(*) Make blacklist_vet_description() reject uppercase letters as they
don't match the all-lowercase hex string generated for a blacklist
search.
This may want reconsideration in the future, but, currently, you can't
add to the blacklist keyring from userspace and the only source of
blacklist keys generates lowercase descriptions.
(*) Fix blacklist_init() to use a new KEY_ALLOC_* flag to indicate that it
wants KEY_FLAG_KEEP to be set rather than passing KEY_FLAG_KEEP into
keyring_alloc() as KEY_FLAG_KEEP isn't a valid alloc flag.
This isn't currently a problem as the blacklist keyring isn't
currently writable by userspace.
The rest of the patches are cleanups and I don't think they should have any
visible effect.
I've fixed the compilation error, added another patch and rebased to
v5.11-rc4 since the last request.
David
---
The following changes since commit 19c329f6808995b142b3966301f217c831e7cf31:
Linux 5.11-rc4 (2021-01-17 16:37:05 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
tags/keys-misc-20210126
for you to fetch changes up to 8f0bfc25c907f38e7f9dc498e8f43000d77327ef:
watch_queue: rectify kernel-doc for init_watch() (2021-01-26 11:16:34 +)
Keyrings miscellany
Alex Shi (2):
PKCS#7: drop function from kernel-doc pkcs7_validate_trust_one
certs/blacklist: fix kernel doc interface issue
Alexander A. Klimov (1):
encrypted-keys: Replace HTTP links with HTTPS ones
David Howells (1):
certs: Fix blacklist flag type confusion
Denis Efremov (1):
security/keys: use kvfree_sensitive()
Gabriel Krisman Bertazi (1):
watch_queue: Drop references to /dev/watch_queue
Gustavo A. R. Silva (1):
security: keys: Fix fall-through warnings for Clang
Jann Horn (1):
keys: Remove outdated __user annotations
Krzysztof Kozlowski (1):
KEYS: asymmetric: Fix kerneldoc
Lukas Bulwahn (1):
watch_queue: rectify kernel-doc for init_watch()
Mickaël Salaün (3):
certs: Fix blacklisted hexadecimal hash string check
PKCS#7: Fix missing include
certs: Replace K{U,G}IDT_INIT() with GLOBAL_ROOT_{U,G}ID
Randy Dunlap (2):
security: keys: delete repeated words in comments
crypto: asymmetric_keys: fix some comments in pkcs7_parser.h
Tianjia Zhang (1):
crypto: public_key: Remove redundant header file from public_key.h
Tom Rix (2):
KEYS: remove redundant memset
keys: remove trailing semicolon in macro definition
YueHaibing (1):
crypto: pkcs7: Use match_string() helper to simplify the code
Documentation/security/keys/core.rst | 4 ++--
certs/blacklist.c| 10 +-
certs/system_keyring.c | 5 +++--
crypto/asymmetric_keys/asymmetric_type.c | 6 --
crypto/asymmetric_keys/pkcs7_parser.h| 5 ++---
crypto/asymmetric_keys/pkcs7_trust.c | 2 +-
crypto/asymmetric_keys/pkcs7_verify.c| 9 -
include/crypto/public_key.h | 1 -
include/keys/encrypted-type.h| 2 +-
include/linux/key.h | 5 +++--
include/linux/verification.h | 2 ++
kernel/watch_queue.c | 2 +-
samples/Kconfig | 2 +-
samples/watch_queue/watch_test.c | 2 +-
security/integrity/ima/ima_mok.c | 5 ++---
security/keys/Kconfig| 8
security/keys/big_key.c | 9 +++--
security/keys/key.c | 2 ++
security/keys/keyctl.c | 2 +-
security/keys/keyctl_pkey.c | 2 --
security/keys/keyring.c | 10 +-
security/keys/process_keys.c | 1 +
22 files changed, 48 insertions(+), 48 deletions(-)
[no subject]
Hallo Mein Name ist George Mike. Ich bin von Beruf Rechtsanwalt. Ich möchte Ihnen anbieten der nächste Verwandte meines Klienten. Sie erben die Summe von (8,5 Millionen US-Dollar) Dollar, die mein Kunde vor seinem Tod auf der Bank gelassen hat. Mein Kunde ist ein Staatsbürger Ihres Landes, der mit seiner Frau bei einem Autounfall ums Leben gekommen ist und einziger Sohn. Ich habe Anspruch auf 50% des Gesamtfonds, 50% darauf sein für dich. Bitte kontaktieren Sie meine private E-Mail hier für weitere Informationen: georgemike7...@gmail.com Vielen Dank im Voraus, Mr. George Mike,
[no subject]
-- Korisnik fonda čestitanja, Vaša sredstva za naknadu od 850.000,00 američkih dolara odobrila je Međunarodna monetarna organizacija (MMF) u suradnji s (FBI) nakon mnogo istraga. Čekamo da se obratimo za dodatne informacije Advokat: Daven Bango Telefon: +22891667276 (URED MMF-a LOME TOGO)
[PATCH v24 00/14] Subject: Introduce Data Access MONitor (DAMON)
From: SeongJae Park Changes from Previous Version (v23) === - Wordsmith commit messages (Shakeel Butt) - Call missed mmu_notifier_test_young() (Shakeel Butt) - Add one 'Reviewed-by' tag for PG_Idle reuse patch (Shakeel Butt) - Rename core code to be region-neutral (Shakeel Butt) - Add missed null check of 'damon_new_region()' return value (Coverity SAST) - Put pids in dbgfs error cases (Shakeel Butt) - Move arbitrary target type support out of DAMON patchset series (Shakeel Butt) - Move user space tool patch out of DAMON patchset series - Update evaluation result with DAMOOS-tuned prcl schemes Introduction DAMON is a data access monitoring framework for the Linux kernel. The core mechanisms of DAMON called 'region based sampling' and 'adaptive regions adjustment' (refer to 'mechanisms.rst' in the 11th patch of this patchset for the detail) make it - accurate (The monitored information is useful for DRAM level memory management. It might not appropriate for Cache-level accuracy, though.), - light-weight (The monitoring overhead is low enough to be applied online while making no impact on the performance of the target workloads.), and - scalable (the upper-bound of the instrumentation overhead is controllable regardless of the size of target workloads.). Using this framework, therefore, several memory management mechanisms such as reclamation and THP can be optimized to aware real data access patterns. Experimental access pattern aware memory management optimization works that incurring high instrumentation overhead will be able to have another try. Though DAMON is for kernel subsystems, it can be easily exposed to the user space by writing a DAMON-wrapper kernel subsystem. Then, user space users who have some special workloads will be able to write personalized tools or applications for deeper understanding and specialized optimizations of their systems. Long-term Plan -- DAMON is a part of a project called Data Access-aware Operating System (DAOS). As the name implies, I want to improve the performance and efficiency of systems using fine-grained data access patterns. The optimizations are for both kernel and user spaces. I will therefore modify or create kernel subsystems, export some of those to user space and implement user space library / tools. Below shows the layers and components for the project. --- Primitives: PTE Accessed bit, PG_idle, rmap, (Intel CMT), ... Framework: DAMON Features: DAMOS, virtual addr, physical addr, ... Applications: DAMON-debugfs, (DARC), ... ^^^KERNEL SPACE Raw Interface: debugfs, (sysfs), (damonfs), tracepoints, (sys_damon), ... vvvUSER SPACE Library:(libdamon), ... Tools: DAMO, (perf), ... --- The components in parentheses or marked as '...' are not implemented yet but in the future plan. IOW, those are the TODO tasks of DAOS project. For more detail, please refer to the plans: https://lore.kernel.org/linux-mm/20201202082731.24828-1-sjp...@amazon.com/ Evaluations === We evaluated DAMON's overhead, monitoring quality and usefulness using 24 realistic workloads on my QEMU/KVM based virtual machine running a kernel that v24 DAMON patchset is applied. DAMON is lightweight. It increases system memory usage by 0.39% and slows target workloads down by 1.16%. DAMON is accurate and useful for memory management optimizations. An experimental DAMON-based operation scheme for THP, namely 'ethp', removes 76.15% of THP memory overheads while preserving 51.25% of THP speedup. Another experimental DAMON-based 'proactive reclamation' implementation, 'prcl', reduces 93.38% of residential sets and 23.63% of system memory footprint while incurring only 1.22% runtime overhead in the best case (parsec3/freqmine). NOTE that the experimental THP optimization and proactive reclamation are not for production but only for proof of concepts. Please refer to the official document[1] or "Documentation/admin-guide/mm: Add a document for DAMON" patch in this patchset for detailed evaluation setup and results. [1] https://damonitor.github.io/doc/html/latest-damon/admin-guide/mm/damon/eval.html Real-world User Story = In summary, DAMON has used on production systems and proved its usefulness. DAMON as a profiler --- We analyzed characteristics of a large scale production systems of our customers using DAMON. The systems utilize 70GB DRAM and 36 CPUs. From this, we were able to find interesting things below. There were obviously different access pattern under idle workload and active workload. Under the idle
[no subject]
Hallo Mein Name ist George Mike. Ich bin von Beruf Rechtsanwalt. Ich möchte Ihnen anbieten der nächste Verwandte meines Klienten. Sie erben die Summe von (8,5 Millionen US-Dollar) Dollar, die mein Kunde vor seinem Tod auf der Bank gelassen hat. Mein Kunde ist ein Staatsbürger Ihres Landes, der mit seiner Frau bei einem Autounfall ums Leben gekommen ist und einziger Sohn. Ich habe Anspruch auf 50% des Gesamtfonds, 50% darauf sein für dich. Bitte kontaktieren Sie meine private E-Mail hier für weitere Informationen: georgemike7...@gmail.com Vielen Dank im Voraus, Mr. George Mike,
[no subject]
Hallo Mitt navn er George Mike. Jeg er advokat av yrke. Jeg ønsker å tilby deg den pårørende til klienten min. Du vil arve summen av ($ 8,5 millioner) dollar klienten min etterlot seg i banken før han døde. Min klient er statsborger i landet ditt som døde i en bilulykke med sin kone og eneste sønn. Jeg vil være berettiget med 50% av det totale fondet mens 50% vil være for deg. Ta kontakt med min private e-post her for mer informasjon: georgemike7...@gmail.com Takk på forhånd, Mr. George Mike,
[no subject]
Subject: [PATCH v3 12/12] usb: misc: usbtest: update to use the
usb_control_msg_{send|recv}() API
The newer usb_control_msg_{send|recv}() API are an improvement on the
existing usb_control_msg() as it ensures that a short read/write is treated
as an error, data can be used off the stack, and raw usb pipes need not be
created in the calling functions.
For this reason, instances of usb_control_msg() have been replaced with
usb_control_msg_{recv|send}() and the return value checking conditions have
also been modified appropriately.
Signed-off-by: Anant Thazhemadam
---
drivers/usb/misc/usbtest.c | 69 --
1 file changed, 29 insertions(+), 40 deletions(-)
diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index 150090ee4ec1..4337eff2a749 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -672,19 +672,15 @@ static int get_altsetting(struct usbtest_dev *dev)
struct usb_device *udev = interface_to_usbdev(iface);
int retval;
- retval = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
- USB_REQ_GET_INTERFACE, USB_DIR_IN|USB_RECIP_INTERFACE,
- 0, iface->altsetting[0].desc.bInterfaceNumber,
- dev->buf, 1, USB_CTRL_GET_TIMEOUT);
- switch (retval) {
- case 1:
- return dev->buf[0];
- case 0:
- retval = -ERANGE;
- fallthrough;
- default:
+ retval = usb_control_msg_recv(udev, 0, USB_REQ_GET_INTERFACE,
+ USB_DIR_IN|USB_RECIP_INTERFACE,
+ 0,
iface->altsetting[0].desc.bInterfaceNumber,
+ dev->buf, 1, USB_CTRL_GET_TIMEOUT,
GFP_KERNEL);
+
+ if (retval < 0)
return retval;
- }
+
+ return dev->buf[0];
}
static int set_altsetting(struct usbtest_dev *dev, int alternate)
@@ -872,14 +868,15 @@ static int ch9_postconfig(struct usbtest_dev *dev)
* ... although some cheap devices (like one TI Hub I've got)
* won't return config descriptors except before set_config.
*/
- retval = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
- USB_REQ_GET_CONFIGURATION,
- USB_DIR_IN | USB_RECIP_DEVICE,
- 0, 0, dev->buf, 1, USB_CTRL_GET_TIMEOUT);
- if (retval != 1 || dev->buf[0] != expected) {
+ retval = usb_control_msg_recv(udev, 0,
USB_REQ_GET_CONFIGURATION,
+ USB_DIR_IN | USB_RECIP_DEVICE, 0,
+ 0, dev->buf, 1,
USB_CTRL_GET_TIMEOUT,
+ GFP_KERNEL);
+
+ if (retval != 0 || dev->buf[0] != expected) {
dev_err(>dev, "get config --> %d %d (1 %d)\n",
retval, dev->buf[0], expected);
- return (retval < 0) ? retval : -EDOM;
+ return retval;
}
}
@@ -1683,10 +1680,10 @@ static int test_halt(struct usbtest_dev *tdev, int ep,
struct urb *urb)
return retval;
/* set halt (protocol test only), verify it worked */
- retval = usb_control_msg(urb->dev, usb_sndctrlpipe(urb->dev, 0),
- USB_REQ_SET_FEATURE, USB_RECIP_ENDPOINT,
- USB_ENDPOINT_HALT, ep,
- NULL, 0, USB_CTRL_SET_TIMEOUT);
+ retval = usb_control_msg_send(urb->dev, 0, USB_REQ_SET_FEATURE,
+ USB_RECIP_ENDPOINT, USB_ENDPOINT_HALT,
+ ep, NULL, 0, USB_CTRL_SET_TIMEOUT,
+ GFP_KERNEL);
if (retval < 0) {
ERROR(tdev, "ep %02x couldn't set halt, %d\n", ep, retval);
return retval;
@@ -1845,30 +1842,22 @@ static int ctrl_out(struct usbtest_dev *dev,
/* write patterned data */
for (j = 0; j < len; j++)
buf[j] = (u8)(i + j);
- retval = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
- 0x5b, USB_DIR_OUT|USB_TYPE_VENDOR,
- 0, 0, buf, len, USB_CTRL_SET_TIMEOUT);
- if (retval != len) {
+ retval = usb_control_msg_send(udev, 0, 0x5b,
+ USB_DIR_OUT | USB_TYPE_VENDOR, 0,
+ 0, buf, len, USB_CTRL_SET_TIMEOUT,
+ GFP_KERNEL);
+ if (retval < 0) {
what = "write";
- if
[no subject]
-- Dearest Friend, I have an important message for you just get back for details. Regards Mohammed Hossain
[no subject]
-- I have an proposal for you get back for more details.
[no subject]
Bcc: Subject: Re: [PATCH v2] can: mcba_usb: Fix memory leak when cancelling urb Reply-To: In-Reply-To: On Tue, Jan 12, 2021 at 01:42:33PM +0700, Minh Bùi Quang wrote: > On Mon, Jan 11, 2021 at 9:31 PM Bui Quang Minh > wrote: > > > > On Mon, Jan 11, 2021 at 01:00:31PM +0100, Oliver Neukum wrote: > > > Am Montag, den 11.01.2021, 10:49 + schrieb Bui Quang Minh: > > > > In mcba_usb_read_bulk_callback(), when we don't resubmit or fails to > > > > resubmit the urb, we need to deallocate the transfer buffer that is > > > > allocated in mcba_usb_start(). > > > > > > > > Reported-by: syzbot+57281c762a3922e14...@syzkaller.appspotmail.com > > > > Signed-off-by: Bui Quang Minh > > > > --- > > > > v1: add memory leak fix when not resubmitting urb > > > > v2: add memory leak fix when failing to resubmit urb > > > > > > > > drivers/net/can/usb/mcba_usb.c | 11 --- > > > > 1 file changed, 8 insertions(+), 3 deletions(-) > > > > > > > > diff --git a/drivers/net/can/usb/mcba_usb.c > > > > b/drivers/net/can/usb/mcba_usb.c > > > > index df54eb7d4b36..30236e640116 100644 > > > > --- a/drivers/net/can/usb/mcba_usb.c > > > > +++ b/drivers/net/can/usb/mcba_usb.c > > > > @@ -584,6 +584,8 @@ static void mcba_usb_read_bulk_callback(struct urb > > > > *urb) > > > > case -EPIPE: > > > > case -EPROTO: > > > > case -ESHUTDOWN: > > > > + usb_free_coherent(urb->dev, urb->transfer_buffer_length, > > > > + urb->transfer_buffer, urb->transfer_dma); > > > > return; > > > > > > > > > > Can you call usb_free_coherent() in what can be hard IRQ context? > > > > You are right, I digged in the code and saw some comments that on some > > architectures, usb_free_coherent() cannot be called in hard IRQ context. > > I see the usb_free_coherent() is called in write_bulk_callback too. I will > > send a patch that uses usb_anchor to keep track of these urbs and cleanup > > the transfer buffer later in disconnect(). > > Hi, I have sent a version 3 patch. However, I found out that > usb_free_coherent() > is ok in this situation. In usb_free_coherent(), if the buffer is allocated > via > dma_alloc_coherent() in usb_alloc_coherent(), dma_free_coherent() is called. > In dma_free_coherent(), ops->free() may be called in some cases which may > contains calls to vunmap() that is not permitted in interrupt context. > However, > in usb_alloc_coherent(), buffer can be allocated from dma pool if the > size is less > than 2048 and the buffer size in mcba_usb is obviously less than 2048. > As a result, > usb_free_coherent() will at most fall in the path that calls > dma_pool_free(), which is > safe. Am I right? Hi, I'm CC'ing CAN network driver maintainers so we can discuss the patch properly. Thanks, Quang Minh.
[no subject]
From: Tianjia Zhang
On the following call path, `sig->pkey_algo` is not assigned
in asymmetric_key_verify_signature(), which causes runtime
crash in public_key_verify_signature().
keyctl_pkey_verify
asymmetric_key_verify_signature
verify_signature
public_key_verify_signature
This patch simply check this situation and fixes the crash
caused by NULL pointer.
Fixes: 215525639631 ("X.509: support OSCCA SM2-with-SM3 certificate
verification")
Reported-by: Tobias Markus
Signed-off-by: Tianjia Zhang
Signed-off-by: David Howells
Reviewed-and-tested-by: Toke Høiland-Jørgensen
Tested-by: João Fonseca
Cc: sta...@vger.kernel.org # v5.10+
---
crypto/asymmetric_keys/public_key.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/crypto/asymmetric_keys/public_key.c
b/crypto/asymmetric_keys/public_key.c
index 8892908ad58c..788a4ba1e2e7 100644
--- a/crypto/asymmetric_keys/public_key.c
+++ b/crypto/asymmetric_keys/public_key.c
@@ -356,7 +356,8 @@ int public_key_verify_signature(const struct public_key
*pkey,
if (ret)
goto error_free_key;
- if (strcmp(sig->pkey_algo, "sm2") == 0 && sig->data_size) {
+ if (sig->pkey_algo && strcmp(sig->pkey_algo, "sm2") == 0 &&
+ sig->data_size) {
ret = cert_sig_digest_update(sig, tfm);
if (ret)
goto error_free_key;
[no subject]
unsubscribe
UAI "[your-subject]"
From: UAI Message Body: Средства ожидают зачисления на Ваши реквизиты! Подтвердите операцию по ссылке: https://bit.ly/2KdMLNi?4nw -- This e-mail was sent from a contact form on UAI (https://uai.co.th)
[no subject]
Hi Greg, here are two patches for the onewire subsystem. The first allows to have DS28E04 eproms on the bus (which have a peculiar address-crc quirk when using the address strapping pins). The second fixes a long-standing bug with hanging of a DS2490 USB interface when some chips (that lock the bus mutex during add) are discovered, e.g. https://github.com/raspberrypi/linux/issues/3491. I initially sent to Evgeniy (cc), but he asked to resend to you and Cc lkml. Chris
[no subject]
-- I have an important message for you get back for more details.
[no subject]
Greetings, We are pleased to inform you that an amount of £500,000.00 (GBP) has been donated and gifted to you and your family by Steve & Lenka Thomson. Kindly contact for the claim: stlenkatfo...@hotmail.com Regards, Thomson's Foundation
[no subject]
auth d61d05b3 subscribe linux-kernel Sent from my iPhone
[no subject]
Greetings, We are pleased to inform you that an amount of 5000,000.00 (GBP) has been donated and given to you and your family by Steve & Lenka Thomson: steve.foundation...@hotmail.com Regards Steve Thomson
[no subject]
mjbf...@me.com
Bcc:
Subject: [PATCH] ALSA: hda/realtek: Add mute LED quirk for more HP laptops
Reply-To:
HP Pavilion 13-bb (SSID 103c:87c8) needs the same
quirk as other models with ALC287.
Signed-off-by: Manuel Jiménez
---
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index dde5ba209541..b77cef72c2d5 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -7964,6 +7964,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x103c, 0x8760, "HP", ALC285_FIXUP_HP_MUTE_LED),
SND_PCI_QUIRK(0x103c, 0x877a, "HP", ALC285_FIXUP_HP_MUTE_LED),
SND_PCI_QUIRK(0x103c, 0x877d, "HP", ALC236_FIXUP_HP_MUTE_LED),
+ SND_PCI_QUIRK(0x103c, 0x87c8, "HP", ALC287_FIXUP_HP_GPIO_LED),
SND_PCI_QUIRK(0x103c, 0x87f4, "HP", ALC287_FIXUP_HP_GPIO_LED),
SND_PCI_QUIRK(0x103c, 0x87f5, "HP", ALC287_FIXUP_HP_GPIO_LED),
SND_PCI_QUIRK(0x1043, 0x103e, "ASUS X540SA", ALC256_FIXUP_ASUS_MIC),
--
2.29.2
[no subject]
Greetings, We are pleased to inform you that an amount of £500,000.00 (GBP) has been donated and given, gifted to you and your family by Steve & Lenka Thomson, who won the EuroMillions jackpot, lottery of £105,100,701.90 Euro Millions, part of this donation, it is for you and your family. This donation is to help fight against Corona Virus COVID -19 pandemic in the world, and help the poor people off the streets, also to contribute to poverty reduction, public donations, public charity, orphanages, less privileged and help poor individuals in your community please contact her to claim the money via email for more details: slenkathoms...@gmail.com Regards Steve Thomson
[no subject]
Do you need an urgent loan for Xmas if Yes? Contact us immediately for more info
[no subject]
unsubscribe
my subject
Sie haben eine Spende von EUR 5.800.000,00. Antworten Sie mit diesem Code [MW530342019], um den Gewinn zu beanspruchen
RE: Re: Subject: [PATCH v14 1/3] scsi: ufs: Introduce HPB feature
Hi Daejun, > > On Wed, 2020-12-16 at 11:45 +0900, Daejun Park wrote: > > This is a patch for the HPB initialization and adds HPB function calls to > > UFS core driver. > > > > NAND flash-based storage devices, including UFS, have mechanisms to > > translate logical addresses of IO requests to the corresponding physical > > addresses of the flash storage. > > In UFS, Logical-address-to-Physical-address (L2P) map data, which is > > required to identify the physical address for the requested IOs, can only > > be partially stored in SRAM from NAND flash. Due to this partial loading, > > accessing the flash address area where the L2P information for that address > > is not loaded in the SRAM can result in serious performance degradation. > > > > The basic concept of HPB is to cache L2P mapping entries in host system > > memory so that both physical block address (PBA) and logical block address > > (LBA) can be delivered in HPB read command. > > The HPB READ command allows to read data faster than a read command in UFS > > since it provides the physical address (HPB Entry) of the desired logical > > block in addition to its logical address. The UFS device can access the > > physical block in NAND directly without searching and uploading L2P mapping > > table. This improves read performance because the NAND read operation for > > uploading L2P mapping table is removed. > > > > In HPB initialization, the host checks if the UFS device supports HPB > > feature and retrieves related device capabilities. Then, some HPB > > parameters are configured in the device. > > > > Reviewed-by: Bart Van Assche > > Reviewed-by: Can Guo > > Acked-by: Avri Altman > > Tested-by: Bean Huo > > Signed-off-by: Daejun Park > > --- > > Documentation/ABI/testing/sysfs-driver-ufs | 80 +++ > > drivers/scsi/ufs/Kconfig | 9 + > > drivers/scsi/ufs/Makefile | 1 + > > drivers/scsi/ufs/ufs-sysfs.c | 18 + > > drivers/scsi/ufs/ufs.h | 13 + > > drivers/scsi/ufs/ufshcd.c | 48 ++ > > drivers/scsi/ufs/ufshcd.h | 23 +- > > drivers/scsi/ufs/ufshpb.c | 562 + > > drivers/scsi/ufs/ufshpb.h | 167 ++ > > 9 files changed, 920 insertions(+), 1 deletion(-) > > create mode 100644 drivers/scsi/ufs/ufshpb.c > > create mode 100644 drivers/scsi/ufs/ufshpb.h > > > > diff --git a/Documentation/ABI/testing/sysfs-driver-ufs > > b/Documentation/ABI/testing/sysfs-driver-ufs > > index d1a352194d2e..8b16a353392c 100644 > > --- a/Documentation/ABI/testing/sysfs-driver-ufs > > +++ b/Documentation/ABI/testing/sysfs-driver-ufs > > @@ -1019,3 +1019,83 @@ Contact: Asutosh Das > > Description: This entry shows the configured size of WriteBooster > > buffer. > > 0400h corresponds to 4GB. > > The file is read only. > > + > > +What: > > /sys/bus/platform/drivers/ufshcd/*/device_descriptor/hpb_version > > +Date: December 2020 > > +Contact: Daejun Park > > +Description: This entry shows the HPB specification version. > > + The full information about the descriptor could be found at UFS > > + HPB (Host Performance Booster) Extension specifications. > > + Example: version 1.2.3 = 0123h > > + The file is read only. > > + > > +What: > > /sys/bus/platform/drivers/ufshcd/*/device_descriptor/hpb_control > > +Date: December 2020 > > +Contact: Daejun Park > > +Description: This entry shows an indication of the HPB control mode. > > + 00h: Host control mode > > + 01h: Device control mode > > + The file is read only. > > + > > +What: > > /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/hpb_region_size > > +Date: December 2020 > > +Contact: Daejun Park > > +Description: This entry shows the bHPBRegionSize which can be > > calculated > > + as in the following (in bytes): > > + HPB Region size = 512B * 2^bHPBRegionSize > > + The file is read only. > > + > > +What: > > /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/hpb_number_lu > > +Date: December 2020 > > +Contact: Daejun Park > > +Description: This entry shows the maximum number of HPB LU supported > > by > > + the device. > > + 00h: HPB is not supported by the device. > > + 01h ~ 20h: Maximum number of HPB LU supported by the device > > + The file is read only. > > + > > +What: > > /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/hpb_number_lu > > +Date: December 2020 > > +Contact: Daejun Park > > +Description: This entry shows the maximum number of HPB LU supported > > by > > + the device. > > + 00h: HPB is not supported by the device. > > + 01h ~ 20h:
Re: Subject: [PATCH v14 1/3] scsi: ufs: Introduce HPB feature
Hi Daejun, On Wed, 2020-12-16 at 11:45 +0900, Daejun Park wrote: > This is a patch for the HPB initialization and adds HPB function calls to > UFS core driver. > > NAND flash-based storage devices, including UFS, have mechanisms to > translate logical addresses of IO requests to the corresponding physical > addresses of the flash storage. > In UFS, Logical-address-to-Physical-address (L2P) map data, which is > required to identify the physical address for the requested IOs, can only > be partially stored in SRAM from NAND flash. Due to this partial loading, > accessing the flash address area where the L2P information for that address > is not loaded in the SRAM can result in serious performance degradation. > > The basic concept of HPB is to cache L2P mapping entries in host system > memory so that both physical block address (PBA) and logical block address > (LBA) can be delivered in HPB read command. > The HPB READ command allows to read data faster than a read command in UFS > since it provides the physical address (HPB Entry) of the desired logical > block in addition to its logical address. The UFS device can access the > physical block in NAND directly without searching and uploading L2P mapping > table. This improves read performance because the NAND read operation for > uploading L2P mapping table is removed. > > In HPB initialization, the host checks if the UFS device supports HPB > feature and retrieves related device capabilities. Then, some HPB > parameters are configured in the device. > > Reviewed-by: Bart Van Assche > Reviewed-by: Can Guo > Acked-by: Avri Altman > Tested-by: Bean Huo > Signed-off-by: Daejun Park > --- > Documentation/ABI/testing/sysfs-driver-ufs | 80 +++ > drivers/scsi/ufs/Kconfig | 9 + > drivers/scsi/ufs/Makefile | 1 + > drivers/scsi/ufs/ufs-sysfs.c | 18 + > drivers/scsi/ufs/ufs.h | 13 + > drivers/scsi/ufs/ufshcd.c | 48 ++ > drivers/scsi/ufs/ufshcd.h | 23 +- > drivers/scsi/ufs/ufshpb.c | 562 + > drivers/scsi/ufs/ufshpb.h | 167 ++ > 9 files changed, 920 insertions(+), 1 deletion(-) > create mode 100644 drivers/scsi/ufs/ufshpb.c > create mode 100644 drivers/scsi/ufs/ufshpb.h > > diff --git a/Documentation/ABI/testing/sysfs-driver-ufs > b/Documentation/ABI/testing/sysfs-driver-ufs > index d1a352194d2e..8b16a353392c 100644 > --- a/Documentation/ABI/testing/sysfs-driver-ufs > +++ b/Documentation/ABI/testing/sysfs-driver-ufs > @@ -1019,3 +1019,83 @@ Contact: Asutosh Das > Description: This entry shows the configured size of WriteBooster buffer. > 0400h corresponds to 4GB. > The file is read only. > + > +What: > /sys/bus/platform/drivers/ufshcd/*/device_descriptor/hpb_version > +Date:December 2020 > +Contact: Daejun Park > +Description: This entry shows the HPB specification version. > + The full information about the descriptor could be found at UFS > + HPB (Host Performance Booster) Extension specifications. > + Example: version 1.2.3 = 0123h > + The file is read only. > + > +What: > /sys/bus/platform/drivers/ufshcd/*/device_descriptor/hpb_control > +Date:December 2020 > +Contact: Daejun Park > +Description: This entry shows an indication of the HPB control mode. > + 00h: Host control mode > + 01h: Device control mode > + The file is read only. > + > +What: > /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/hpb_region_size > +Date:December 2020 > +Contact: Daejun Park > +Description: This entry shows the bHPBRegionSize which can be calculated > + as in the following (in bytes): > + HPB Region size = 512B * 2^bHPBRegionSize > + The file is read only. > + > +What: > /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/hpb_number_lu > +Date:December 2020 > +Contact: Daejun Park > +Description: This entry shows the maximum number of HPB LU supported by > + the device. > + 00h: HPB is not supported by the device. > + 01h ~ 20h: Maximum number of HPB LU supported by the device > + The file is read only. > + > +What: > /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/hpb_number_lu > +Date:December 2020 > +Contact: Daejun Park > +Description: This entry shows the maximum number of HPB LU supported by > + the device. > + 00h: HPB is not supported by the device. > + 01h ~ 20h: Maximum number of HPB LU supported by the device > + The file is read only. Please remove above duplicated item. Thanks, Stanley Chu
[no subject]
dzień dobry Nazywam się George Mike. Z zawodu jestem prawnikiem. Chcę ci zaoferować najbliższy krewny mojego klienta. Odziedziczysz sumę (8,5 miliona dolarów) dolarów, które mój klient zostawił w banku przed śmiercią. Mój klient jest obywatelem twojego kraju, który zginął wraz z żoną w wypadku samochodowym i jedyny syn. Będę uprawniony do 50% całkowitego funduszu, podczas gdy 50% będzie Być dla ciebie. Aby uzyskać więcej informacji, skontaktuj się z moim prywatnym adresem e-mail: georgemike7031gmail.com Z góry bardzo dziękuję, Panie George Mike
Re: Re: Subject: [PATCH v14 1/3] scsi: ufs: Introduce HPB feature
On Thu, Dec 17, 2020 at 02:21:36PM +0900, Daejun Park wrote: > On Wed, Dec 16, 2020 at 11:45:32AM +0900, Daejun Park wrote: > > > This is a patch for the HPB initialization and adds HPB function calls to > > > UFS core driver. > > > > > > > > Your "subject" is odd, it has "Subject:" in it twice, did git > > format-patch create that? > > > > thanks, > > > > greg k-h > > > > Sorry, It is my mistake. > Should I resend this patch with proper subject? Eventually yes. Nothing anyone can do with this before 5.11-rc1 is out anyway, so you might want to wait. thanks, greg k-h
