[PATCH net-next 0/8] udp: GRO L4 improvements

[PATCH net-next 0/8] udp: GRO L4 improvements

[Paolo Abeni]

This series improves the UDP L4 - either 'forward' or 'frag_list' -
co-existence with UDP tunnel GRO, allowing the first to take place
correctly even for encapsulated UDP traffic.

The first for patches are mostly bugfixes, addressing some GRO 
edge-cases when both tunnels and L4 are present, enabled and in use.

The next 3 patches avoid unneeded segmentation when UDP GRO
traffic traverses in the receive path UDP tunnels.

Finally, some self-tests are included, covering the relevant
GRO scenarios.

Even if most patches are actually bugfixes, this series is
targeting net-next, as overall it makes available a new feature.

Paolo Abeni (8):
  udp: fixup csum for GSO receive slow path
  udp: skip fwd/list GRO for tunnel packets
  udp: properly complete L4 GRO over UDP tunnel packet
  udp: never accept GSO_FRAGLIST packets
  vxlan: allow L4 GRO passthrou
  geneve: allow UDP L4 GRO passthrou
  bareudp: allow UDP L4 GRO passthrou
  selftests: net: add UDP GRO forwarding self-tests

 drivers/net/bareudp.c                     |   1 +
 drivers/net/geneve.c                      |   1 +
 drivers/net/vxlan.c                       |   1 +
 include/linux/udp.h                       |  15 +-
 include/net/udp.h                         |  18 ++
 net/ipv4/udp.c                            |  22 +-
 net/ipv4/udp_offload.c                    |  27 ++-
 net/ipv6/udp.c                            |   5 +
 net/ipv6/udp_offload.c                    |   3 +-
 tools/testing/selftests/net/Makefile      |   1 +
 tools/testing/selftests/net/udpgro_fwd.sh | 251 ++++++++++++++++++++++
 11 files changed, 330 insertions(+), 15 deletions(-)
 create mode 100755 tools/testing/selftests/net/udpgro_fwd.sh

-- 
2.26.2

[PATCH net-next 1/8] udp: fixup csum for GSO receive slow path

[Paolo Abeni]

When looping back UDP GSO over UDP tunnel packets to an UDP socket,
the individual packet csum is currently set to CSUM_NONE. That causes
unexpected/wrong csum validation errors later in the UDP receive path.

We could possibly addressing the issue with some additional check and
csum mangling in the UDP tunnel code. Since the issue affects only
this UDP receive slow path, let's set a suitable csum status there.

Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
 include/net/udp.h | 18 ++++++++++++++++++
 net/ipv4/udp.c    | 10 ++++++++++
 net/ipv6/udp.c    |  5 +++++
 3 files changed, 33 insertions(+)

diff --git a/include/net/udp.h b/include/net/udp.h
index d4d064c592328..007683eb3e113 100644
--- a/include/net/udp.h
+++ b/include/net/udp.h
@@ -515,6 +515,24 @@ static inline struct sk_buff *udp_rcv_segment(struct sock *sk,
 	return segs;
 }
 
+static inline void udp_post_segment_fix_csum(struct sk_buff *skb, int level)
+{
+	/* UDP-lite can't land here - no GRO */
+	WARN_ON_ONCE(UDP_SKB_CB(skb)->partial_cov);
+
+	/* GRO already validated the csum up to 'level', and we just
+	 * consumed one header, update the skb accordingly
+	 */
+	UDP_SKB_CB(skb)->cscov = skb->len;
+	if (level) {
+		skb->ip_summed = CHECKSUM_UNNECESSARY;
+		skb->csum_level = 0;
+	} else {
+		skb->ip_summed = CHECKSUM_NONE;
+		skb->csum_valid = 1;
+	}
+}
+
 #ifdef CONFIG_BPF_SYSCALL
 struct sk_psock;
 struct proto *udp_bpf_get_proto(struct sock *sk, struct sk_psock *psock);
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 4a0478b17243a..ff54135c51ffa 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -2168,6 +2168,7 @@ static int udp_queue_rcv_one_skb(struct sock *sk, struct sk_buff *skb)
 static int udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
 {
 	struct sk_buff *next, *segs;
+	int csum_level;
 	int ret;
 
 	if (likely(!udp_unexpected_gso(sk, skb)))
@@ -2175,9 +2176,18 @@ static int udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
 
 	BUILD_BUG_ON(sizeof(struct udp_skb_cb) > SKB_GSO_CB_OFFSET);
 	__skb_push(skb, -skb_mac_offset(skb));
+	csum_level = !!(skb_shinfo(skb)->gso_type &
+			(SKB_GSO_UDP_TUNNEL | SKB_GSO_UDP_TUNNEL_CSUM));
 	segs = udp_rcv_segment(sk, skb, true);
 	skb_list_walk_safe(segs, skb, next) {
 		__skb_pull(skb, skb_transport_offset(skb));
+
+		/* UDP GSO packets looped back after adding UDP encap land here with CHECKSUM none,
+		 * instead of adding another check in the tunnel fastpath, we can force valid
+		 * csums here (packets are locally generated).
+		 * Additionally fixup the UDP CB
+		 */
+		udp_post_segment_fix_csum(skb, csum_level);
 		ret = udp_queue_rcv_one_skb(sk, skb);
 		if (ret > 0)
 			ip_protocol_deliver_rcu(dev_net(skb->dev), skb, ret);
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index d25e5a9252fdb..e7d4bf3a65c72 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -739,16 +739,21 @@ static int udpv6_queue_rcv_one_skb(struct sock *sk, struct sk_buff *skb)
 static int udpv6_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
 {
 	struct sk_buff *next, *segs;
+	int csum_level;
 	int ret;
 
 	if (likely(!udp_unexpected_gso(sk, skb)))
 		return udpv6_queue_rcv_one_skb(sk, skb);
 
 	__skb_push(skb, -skb_mac_offset(skb));
+	csum_level = !!(skb_shinfo(skb)->gso_type &
+			(SKB_GSO_UDP_TUNNEL | SKB_GSO_UDP_TUNNEL_CSUM));
 	segs = udp_rcv_segment(sk, skb, false);
 	skb_list_walk_safe(segs, skb, next) {
 		__skb_pull(skb, skb_transport_offset(skb));
 
+		/* see comments in udp_queue_rcv_skb() */
+		udp_post_segment_fix_csum(skb, csum_level);
 		ret = udpv6_queue_rcv_one_skb(sk, skb);
 		if (ret > 0)
 			ip6_protocol_deliver_rcu(dev_net(skb->dev), skb, ret,
-- 
2.26.2

Re: [PATCH net-next 1/8] udp: fixup csum for GSO receive slow path

[Willem de Bruijn]

On Sun, Mar 21, 2021 at 1:01 PM Paolo Abeni <pabeni@redhat.com> wrote:
>
> When looping back UDP GSO over UDP tunnel packets to an UDP socket,
> the individual packet csum is currently set to CSUM_NONE. That causes
> unexpected/wrong csum validation errors later in the UDP receive path.
>
> We could possibly addressing the issue with some additional check and
> csum mangling in the UDP tunnel code. Since the issue affects only
> this UDP receive slow path, let's set a suitable csum status there.
>
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> ---
>  include/net/udp.h | 18 ++++++++++++++++++
>  net/ipv4/udp.c    | 10 ++++++++++
>  net/ipv6/udp.c    |  5 +++++
>  3 files changed, 33 insertions(+)
>
> diff --git a/include/net/udp.h b/include/net/udp.h
> index d4d064c592328..007683eb3e113 100644
> --- a/include/net/udp.h
> +++ b/include/net/udp.h
> @@ -515,6 +515,24 @@ static inline struct sk_buff *udp_rcv_segment(struct sock *sk,
>         return segs;
>  }
>
> +static inline void udp_post_segment_fix_csum(struct sk_buff *skb, int level)
> +{
> +       /* UDP-lite can't land here - no GRO */
> +       WARN_ON_ONCE(UDP_SKB_CB(skb)->partial_cov);
> +
> +       /* GRO already validated the csum up to 'level', and we just
> +        * consumed one header, update the skb accordingly
> +        */
> +       UDP_SKB_CB(skb)->cscov = skb->len;
> +       if (level) {
> +               skb->ip_summed = CHECKSUM_UNNECESSARY;
> +               skb->csum_level = 0;
> +       } else {
> +               skb->ip_summed = CHECKSUM_NONE;
> +               skb->csum_valid = 1;
> +       }

why does this function also update these fields for non-tunneled
packets? the commit only describes an issue with tunneled packets.

> +}
> +
>  #ifdef CONFIG_BPF_SYSCALL
>  struct sk_psock;
>  struct proto *udp_bpf_get_proto(struct sock *sk, struct sk_psock *psock);
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index 4a0478b17243a..ff54135c51ffa 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -2168,6 +2168,7 @@ static int udp_queue_rcv_one_skb(struct sock *sk, struct sk_buff *skb)
>  static int udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
>  {
>         struct sk_buff *next, *segs;
> +       int csum_level;
>         int ret;
>
>         if (likely(!udp_unexpected_gso(sk, skb)))
> @@ -2175,9 +2176,18 @@ static int udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
>
>         BUILD_BUG_ON(sizeof(struct udp_skb_cb) > SKB_GSO_CB_OFFSET);
>         __skb_push(skb, -skb_mac_offset(skb));
> +       csum_level = !!(skb_shinfo(skb)->gso_type &
> +                       (SKB_GSO_UDP_TUNNEL | SKB_GSO_UDP_TUNNEL_CSUM));
>         segs = udp_rcv_segment(sk, skb, true);
>         skb_list_walk_safe(segs, skb, next) {
>                 __skb_pull(skb, skb_transport_offset(skb));
> +
> +               /* UDP GSO packets looped back after adding UDP encap land here with CHECKSUM none,
> +                * instead of adding another check in the tunnel fastpath, we can force valid
> +                * csums here (packets are locally generated).
> +                * Additionally fixup the UDP CB
> +                */
> +               udp_post_segment_fix_csum(skb, csum_level);

How does this code differentiates locally generated packets with udp
tunnel headers from packets arriving from the wire, for which the
inner checksum may be incorrect?

>                 ret = udp_queue_rcv_one_skb(sk, skb);
>                 if (ret > 0)
>                         ip_protocol_deliver_rcu(dev_net(skb->dev), skb, ret);
> diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
> index d25e5a9252fdb..e7d4bf3a65c72 100644
> --- a/net/ipv6/udp.c
> +++ b/net/ipv6/udp.c
> @@ -739,16 +739,21 @@ static int udpv6_queue_rcv_one_skb(struct sock *sk, struct sk_buff *skb)
>  static int udpv6_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
>  {
>         struct sk_buff *next, *segs;
> +       int csum_level;
>         int ret;
>
>         if (likely(!udp_unexpected_gso(sk, skb)))
>                 return udpv6_queue_rcv_one_skb(sk, skb);
>
>         __skb_push(skb, -skb_mac_offset(skb));
> +       csum_level = !!(skb_shinfo(skb)->gso_type &
> +                       (SKB_GSO_UDP_TUNNEL | SKB_GSO_UDP_TUNNEL_CSUM));
>         segs = udp_rcv_segment(sk, skb, false);
>         skb_list_walk_safe(segs, skb, next) {
>                 __skb_pull(skb, skb_transport_offset(skb));
>
> +               /* see comments in udp_queue_rcv_skb() */
> +               udp_post_segment_fix_csum(skb, csum_level);
>                 ret = udpv6_queue_rcv_one_skb(sk, skb);
>                 if (ret > 0)
>                         ip6_protocol_deliver_rcu(dev_net(skb->dev), skb, ret,
> --
> 2.26.2
>

Re: [PATCH net-next 1/8] udp: fixup csum for GSO receive slow path

[Paolo Abeni]

On Mon, 2021-03-22 at 09:18 -0400, Willem de Bruijn wrote:
> On Sun, Mar 21, 2021 at 1:01 PM Paolo Abeni <pabeni@redhat.com> wrote:
> > When looping back UDP GSO over UDP tunnel packets to an UDP socket,
> > the individual packet csum is currently set to CSUM_NONE. That causes
> > unexpected/wrong csum validation errors later in the UDP receive path.
> > 
> > We could possibly addressing the issue with some additional check and
> > csum mangling in the UDP tunnel code. Since the issue affects only
> > this UDP receive slow path, let's set a suitable csum status there.
> > 
> > Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> > ---
> >  include/net/udp.h | 18 ++++++++++++++++++
> >  net/ipv4/udp.c    | 10 ++++++++++
> >  net/ipv6/udp.c    |  5 +++++
> >  3 files changed, 33 insertions(+)
> > 
> > diff --git a/include/net/udp.h b/include/net/udp.h
> > index d4d064c592328..007683eb3e113 100644
> > --- a/include/net/udp.h
> > +++ b/include/net/udp.h
> > @@ -515,6 +515,24 @@ static inline struct sk_buff *udp_rcv_segment(struct sock *sk,
> >         return segs;
> >  }
> > 
> > +static inline void udp_post_segment_fix_csum(struct sk_buff *skb, int level)
> > +{
> > +       /* UDP-lite can't land here - no GRO */
> > +       WARN_ON_ONCE(UDP_SKB_CB(skb)->partial_cov);
> > +
> > +       /* GRO already validated the csum up to 'level', and we just
> > +        * consumed one header, update the skb accordingly
> > +        */
> > +       UDP_SKB_CB(skb)->cscov = skb->len;
> > +       if (level) {
> > +               skb->ip_summed = CHECKSUM_UNNECESSARY;
> > +               skb->csum_level = 0;
> > +       } else {
> > +               skb->ip_summed = CHECKSUM_NONE;
> > +               skb->csum_valid = 1;
> > +       }
> 
> why does this function also update these fields for non-tunneled
> packets? the commit only describes an issue with tunneled packets.
> 
> > +}
> > +
> >  #ifdef CONFIG_BPF_SYSCALL
> >  struct sk_psock;
> >  struct proto *udp_bpf_get_proto(struct sock *sk, struct sk_psock *psock);
> > diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> > index 4a0478b17243a..ff54135c51ffa 100644
> > --- a/net/ipv4/udp.c
> > +++ b/net/ipv4/udp.c
> > @@ -2168,6 +2168,7 @@ static int udp_queue_rcv_one_skb(struct sock *sk, struct sk_buff *skb)
> >  static int udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
> >  {
> >         struct sk_buff *next, *segs;
> > +       int csum_level;
> >         int ret;
> > 
> >         if (likely(!udp_unexpected_gso(sk, skb)))
> > @@ -2175,9 +2176,18 @@ static int udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
> > 
> >         BUILD_BUG_ON(sizeof(struct udp_skb_cb) > SKB_GSO_CB_OFFSET);
> >         __skb_push(skb, -skb_mac_offset(skb));
> > +       csum_level = !!(skb_shinfo(skb)->gso_type &
> > +                       (SKB_GSO_UDP_TUNNEL | SKB_GSO_UDP_TUNNEL_CSUM));
> >         segs = udp_rcv_segment(sk, skb, true);
> >         skb_list_walk_safe(segs, skb, next) {
> >                 __skb_pull(skb, skb_transport_offset(skb));
> > +
> > +               /* UDP GSO packets looped back after adding UDP encap land here with CHECKSUM none,
> > +                * instead of adding another check in the tunnel fastpath, we can force valid
> > +                * csums here (packets are locally generated).
> > +                * Additionally fixup the UDP CB
> > +                */
> > +               udp_post_segment_fix_csum(skb, csum_level);
> 
> How does this code differentiates locally generated packets with udp
> tunnel headers from packets arriving from the wire, for which the
> inner checksum may be incorrect?

First thing first, thank you for the detailed review. Digesting all the
comments will take time, so please excuse for some latency.

I'll try to reply to both your question here because the replies are
related.

My understanding is that UDP GRO, when processing UDP over UDP traffic
with the appropriate features bit set, will validate the checksum for
both the inner and the outer header - udp{4,6}_gro_receive will be
traversed twice, the fist one for the outer header, the 2nd for the
inner.

So when we reach here, the inner header csum could not be incorrect,
and I don't do anything to differentiate locally generated GSO packets
and GROed one to keep the code simpler.

The udp_post_segment_fix_csum() always set the csum info - even for non
tunneled packets to avoid additional branches/make the code more
complex. The csum should be valid in any scenario.

I guess I can mention the above either in a code comment and/or in the
commit message.

Cheers,

Paolo

Re: [PATCH net-next 1/8] udp: fixup csum for GSO receive slow path

[Willem de Bruijn]

On Mon, Mar 22, 2021 at 12:36 PM Paolo Abeni <pabeni@redhat.com> wrote:
>
> On Mon, 2021-03-22 at 09:18 -0400, Willem de Bruijn wrote:
> > On Sun, Mar 21, 2021 at 1:01 PM Paolo Abeni <pabeni@redhat.com> wrote:
> > > When looping back UDP GSO over UDP tunnel packets to an UDP socket,
> > > the individual packet csum is currently set to CSUM_NONE. That causes
> > > unexpected/wrong csum validation errors later in the UDP receive path.
> > >
> > > We could possibly addressing the issue with some additional check and
> > > csum mangling in the UDP tunnel code. Since the issue affects only
> > > this UDP receive slow path, let's set a suitable csum status there.
> > >
> > > Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> > > ---
> > >  include/net/udp.h | 18 ++++++++++++++++++
> > >  net/ipv4/udp.c    | 10 ++++++++++
> > >  net/ipv6/udp.c    |  5 +++++
> > >  3 files changed, 33 insertions(+)
> > >
> > > diff --git a/include/net/udp.h b/include/net/udp.h
> > > index d4d064c592328..007683eb3e113 100644
> > > --- a/include/net/udp.h
> > > +++ b/include/net/udp.h
> > > @@ -515,6 +515,24 @@ static inline struct sk_buff *udp_rcv_segment(struct sock *sk,
> > >         return segs;
> > >  }
> > >
> > > +static inline void udp_post_segment_fix_csum(struct sk_buff *skb, int level)
> > > +{
> > > +       /* UDP-lite can't land here - no GRO */
> > > +       WARN_ON_ONCE(UDP_SKB_CB(skb)->partial_cov);
> > > +
> > > +       /* GRO already validated the csum up to 'level', and we just
> > > +        * consumed one header, update the skb accordingly
> > > +        */
> > > +       UDP_SKB_CB(skb)->cscov = skb->len;
> > > +       if (level) {
> > > +               skb->ip_summed = CHECKSUM_UNNECESSARY;
> > > +               skb->csum_level = 0;
> > > +       } else {
> > > +               skb->ip_summed = CHECKSUM_NONE;
> > > +               skb->csum_valid = 1;
> > > +       }
> >
> > why does this function also update these fields for non-tunneled
> > packets? the commit only describes an issue with tunneled packets.
> >
> > > +}
> > > +
> > >  #ifdef CONFIG_BPF_SYSCALL
> > >  struct sk_psock;
> > >  struct proto *udp_bpf_get_proto(struct sock *sk, struct sk_psock *psock);
> > > diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> > > index 4a0478b17243a..ff54135c51ffa 100644
> > > --- a/net/ipv4/udp.c
> > > +++ b/net/ipv4/udp.c
> > > @@ -2168,6 +2168,7 @@ static int udp_queue_rcv_one_skb(struct sock *sk, struct sk_buff *skb)
> > >  static int udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
> > >  {
> > >         struct sk_buff *next, *segs;
> > > +       int csum_level;
> > >         int ret;
> > >
> > >         if (likely(!udp_unexpected_gso(sk, skb)))
> > > @@ -2175,9 +2176,18 @@ static int udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
> > >
> > >         BUILD_BUG_ON(sizeof(struct udp_skb_cb) > SKB_GSO_CB_OFFSET);
> > >         __skb_push(skb, -skb_mac_offset(skb));
> > > +       csum_level = !!(skb_shinfo(skb)->gso_type &
> > > +                       (SKB_GSO_UDP_TUNNEL | SKB_GSO_UDP_TUNNEL_CSUM));
> > >         segs = udp_rcv_segment(sk, skb, true);
> > >         skb_list_walk_safe(segs, skb, next) {
> > >                 __skb_pull(skb, skb_transport_offset(skb));
> > > +
> > > +               /* UDP GSO packets looped back after adding UDP encap land here with CHECKSUM none,
> > > +                * instead of adding another check in the tunnel fastpath, we can force valid
> > > +                * csums here (packets are locally generated).
> > > +                * Additionally fixup the UDP CB
> > > +                */
> > > +               udp_post_segment_fix_csum(skb, csum_level);
> >
> > How does this code differentiates locally generated packets with udp
> > tunnel headers from packets arriving from the wire, for which the
> > inner checksum may be incorrect?
>
> First thing first, thank you for the detailed review. Digesting all the
> comments will take time, so please excuse for some latency.

Apologies for my own delayed response. I also need to take time to
understand the existing code and diffs :) And have a few questions.

> I'll try to reply to both your question here because the replies are
> related.
>
> My understanding is that UDP GRO, when processing UDP over UDP traffic

This is a UDP GSO packet egress packet that was further encapsulated
with a GSO_UDP_TUNNEL on egress, then looped to the ingress path?

Then in the ingress path it has traversed the GRO layer.

Is this veth with XDP? That seems unlikely for GSO packets. But there
aren't many paths that will loop a packet through napi_gro_receive or
napi_gro_frags.

> with the appropriate features bit set, will validate the checksum for
> both the inner and the outer header - udp{4,6}_gro_receive will be
> traversed twice, the fist one for the outer header, the 2nd for the
> inner.

GRO will validate multiple levels of checksums with CHECKSUM_COMPLETE.
It can only validate the outer checksum with CHECKSUM_UNNECESSARY, I
believe?

As for looped packets with CHECKSUM_PARTIAL: we definitely have found
bugs in that path before. I think it's fine to set csum_valid on any
packets that can unambiguously be identified as such. Hence the
detailed questions above on which exact packets this code is
targeting, so that there are not accidental false positives that look
the same but have a different ip_summed.

> So when we reach here, the inner header csum could not be incorrect,
> and I don't do anything to differentiate locally generated GSO packets
> and GROed one to keep the code simpler.

But the correctness of the patch depends on them being locally
generated, if I'm not mistaken. Then I would make it explicit.

> The udp_post_segment_fix_csum() always set the csum info - even for non
> tunneled packets to avoid additional branches/make the code more
> complex. The csum should be valid in any scenario.
>
> I guess I can mention the above either in a code comment and/or in the
> commit message.

I don't follow this. The patch adds an else clause for non-tunneled
packets. Why does it update these? It does not seem like avoiding
additional branches, but adding them. So I must be missing something
more involved.

> Cheers,
>
> Paolo
>

Re: [PATCH net-next 1/8] udp: fixup csum for GSO receive slow path

[Willem de Bruijn]

> > > > @@ -2168,6 +2168,7 @@ static int udp_queue_rcv_one_skb(struct sock *sk, struct sk_buff *skb)
> > > >  static int udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
> > > >  {
> > > >         struct sk_buff *next, *segs;
> > > > +       int csum_level;
> > > >         int ret;
> > > >
> > > >         if (likely(!udp_unexpected_gso(sk, skb)))
> > > > @@ -2175,9 +2176,18 @@ static int udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
> > > >
> > > >         BUILD_BUG_ON(sizeof(struct udp_skb_cb) > SKB_GSO_CB_OFFSET);
> > > >         __skb_push(skb, -skb_mac_offset(skb));
> > > > +       csum_level = !!(skb_shinfo(skb)->gso_type &
> > > > +                       (SKB_GSO_UDP_TUNNEL | SKB_GSO_UDP_TUNNEL_CSUM));
> > > >         segs = udp_rcv_segment(sk, skb, true);
> > > >         skb_list_walk_safe(segs, skb, next) {
> > > >                 __skb_pull(skb, skb_transport_offset(skb));
> > > > +
> > > > +               /* UDP GSO packets looped back after adding UDP encap land here with CHECKSUM none,
> > > > +                * instead of adding another check in the tunnel fastpath, we can force valid
> > > > +                * csums here (packets are locally generated).
> > > > +                * Additionally fixup the UDP CB
> > > > +                */

Btw, instead of this comment plus a comment in the ipv6 code that
points back to this ipv4 comment, I would move the explanation to
the udp_post_segment_fix_csum function itself.

Re: [PATCH net-next 1/8] udp: fixup csum for GSO receive slow path

[Paolo Abeni]

On Tue, 2021-03-23 at 21:45 -0400, Willem de Bruijn wrote:
> On Mon, Mar 22, 2021 at 12:36 PM Paolo Abeni <pabeni@redhat.com> wrote:
> > On Mon, 2021-03-22 at 09:18 -0400, Willem de Bruijn wrote:
> > > On Sun, Mar 21, 2021 at 1:01 PM Paolo Abeni <pabeni@redhat.com> wrote:
> > > > When looping back UDP GSO over UDP tunnel packets to an UDP socket,
> > > > the individual packet csum is currently set to CSUM_NONE. That causes
> > > > unexpected/wrong csum validation errors later in the UDP receive path.
> > > > 
> > > > We could possibly addressing the issue with some additional check and
> > > > csum mangling in the UDP tunnel code. Since the issue affects only
> > > > this UDP receive slow path, let's set a suitable csum status there.
> > > > 
> > > > Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> > > > ---
> > > >  include/net/udp.h | 18 ++++++++++++++++++
> > > >  net/ipv4/udp.c    | 10 ++++++++++
> > > >  net/ipv6/udp.c    |  5 +++++
> > > >  3 files changed, 33 insertions(+)
> > > > 
> > > > diff --git a/include/net/udp.h b/include/net/udp.h
> > > > index d4d064c592328..007683eb3e113 100644
> > > > --- a/include/net/udp.h
> > > > +++ b/include/net/udp.h
> > > > @@ -515,6 +515,24 @@ static inline struct sk_buff *udp_rcv_segment(struct sock *sk,
> > > >         return segs;
> > > >  }
> > > > 
> > > > +static inline void udp_post_segment_fix_csum(struct sk_buff *skb, int level)
> > > > +{
> > > > +       /* UDP-lite can't land here - no GRO */
> > > > +       WARN_ON_ONCE(UDP_SKB_CB(skb)->partial_cov);
> > > > +
> > > > +       /* GRO already validated the csum up to 'level', and we just
> > > > +        * consumed one header, update the skb accordingly
> > > > +        */
> > > > +       UDP_SKB_CB(skb)->cscov = skb->len;
> > > > +       if (level) {
> > > > +               skb->ip_summed = CHECKSUM_UNNECESSARY;
> > > > +               skb->csum_level = 0;
> > > > +       } else {
> > > > +               skb->ip_summed = CHECKSUM_NONE;
> > > > +               skb->csum_valid = 1;
> > > > +       }
> > > 
> > > why does this function also update these fields for non-tunneled
> > > packets? the commit only describes an issue with tunneled packets.
> > > 
> > > > +}
> > > > +
> > > >  #ifdef CONFIG_BPF_SYSCALL
> > > >  struct sk_psock;
> > > >  struct proto *udp_bpf_get_proto(struct sock *sk, struct sk_psock *psock);
> > > > diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> > > > index 4a0478b17243a..ff54135c51ffa 100644
> > > > --- a/net/ipv4/udp.c
> > > > +++ b/net/ipv4/udp.c
> > > > @@ -2168,6 +2168,7 @@ static int udp_queue_rcv_one_skb(struct sock *sk, struct sk_buff *skb)
> > > >  static int udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
> > > >  {
> > > >         struct sk_buff *next, *segs;
> > > > +       int csum_level;
> > > >         int ret;
> > > > 
> > > >         if (likely(!udp_unexpected_gso(sk, skb)))
> > > > @@ -2175,9 +2176,18 @@ static int udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
> > > > 
> > > >         BUILD_BUG_ON(sizeof(struct udp_skb_cb) > SKB_GSO_CB_OFFSET);
> > > >         __skb_push(skb, -skb_mac_offset(skb));
> > > > +       csum_level = !!(skb_shinfo(skb)->gso_type &
> > > > +                       (SKB_GSO_UDP_TUNNEL | SKB_GSO_UDP_TUNNEL_CSUM));
> > > >         segs = udp_rcv_segment(sk, skb, true);
> > > >         skb_list_walk_safe(segs, skb, next) {
> > > >                 __skb_pull(skb, skb_transport_offset(skb));
> > > > +
> > > > +               /* UDP GSO packets looped back after adding UDP encap land here with CHECKSUM none,
> > > > +                * instead of adding another check in the tunnel fastpath, we can force valid
> > > > +                * csums here (packets are locally generated).
> > > > +                * Additionally fixup the UDP CB
> > > > +                */
> > > > +               udp_post_segment_fix_csum(skb, csum_level);
> > > 
> > > How does this code differentiates locally generated packets with udp
> > > tunnel headers from packets arriving from the wire, for which the
> > > inner checksum may be incorrect?
> > 
> > First thing first, thank you for the detailed review. Digesting all the
> > comments will take time, so please excuse for some latency.
> 
> Apologies for my own delayed response. I also need to take time to
> understand the existing code and diffs :) And have a few questions.
> 
> > I'll try to reply to both your question here because the replies are
> > related.
> > 
> > My understanding is that UDP GRO, when processing UDP over UDP traffic
> 
> This is a UDP GSO packet egress packet that was further encapsulated
> with a GSO_UDP_TUNNEL on egress, then looped to the ingress path?
> 
> Then in the ingress path it has traversed the GRO layer.
> 
> Is this veth with XDP? That seems unlikely for GSO packets. But there
> aren't many paths that will loop a packet through napi_gro_receive or
> napi_gro_frags.

This patch addresses the following scenario:

sk ->vxlan -> veth -> (xdp in use, TSO disabled, GRO on) -> veth -> vxlan -> sk

What I meant here is that the issue is not visible with:

(baremetal, NETIF_F_GRO_UDP_FWD | NETIF_F_GRO_FRAGLIST enabled -> vxlan -> sk

> > with the appropriate features bit set, will validate the checksum for
> > both the inner and the outer header - udp{4,6}_gro_receive will be
> > traversed twice, the fist one for the outer header, the 2nd for the
> > inner.
> 
> GRO will validate multiple levels of checksums with CHECKSUM_COMPLETE.
> It can only validate the outer checksum with CHECKSUM_UNNECESSARY, I
> believe?

I possibly miss some bits here ?!?

AFAICS:

udp4_gro_receive() -> skb_gro_checksum_validate_zero_check() ->
__skb_gro_checksum_validate -> (if  not already valid)
__skb_gro_checksum_validate_complete() -> (if not CHECKSUM_COMPLETE)
__skb_gro_checksum_complete()

the latter will validate the UDP checksum at the current nesting level
(and set the csum-related bits in the GRO skb cb to the same status
as CHECKSUM_COMPLETE)

When processing UDP over UDP tunnel packet, the gro call chain will be:

[l2/l3 GRO] -> udp4_gro_receive (validate outher header csum) -> 
udp_sk(sk)->gro_receive -> [other gro layers] -> 
udp4_gro_receive (validate inner header csum) -> ...

> As for looped packets with CHECKSUM_PARTIAL: we definitely have found
> bugs in that path before. I think it's fine to set csum_valid on any
> packets that can unambiguously be identified as such. Hence the
> detailed questions above on which exact packets this code is
> targeting, so that there are not accidental false positives that look
> the same but have a different ip_summed.

I see this change is controversial. Since the addressed scenario is
really a corner case, a simpler alternative would be
replacing udp_post_segment_fix_csum with:

static inline void udp_post_segment_fix_cb(struct sk_buff *skb, int level)
{
	/* UDP-lite can't land here - no GRO */
	WARN_ON_ONCE(UDP_SKB_CB(skb)->partial_cov);

	/* UDP CB mirrors the GSO packet, we must re-init it */
	UDP_SKB_CB(skb)->cscov = skb->len;
}

the downside will be an additional, later, unneeded csum validation for the 

sk ->vxlan -> veth -> (xdp in use, TSO disabled, GRO on) -> veth -> vxlan -> sk

scenario. WDYT?

Thanks!

Paolo

Re: [PATCH net-next 1/8] udp: fixup csum for GSO receive slow path

[Willem de Bruijn]

> > This is a UDP GSO packet egress packet that was further encapsulated
> > with a GSO_UDP_TUNNEL on egress, then looped to the ingress path?
> >
> > Then in the ingress path it has traversed the GRO layer.
> >
> > Is this veth with XDP? That seems unlikely for GSO packets. But there
> > aren't many paths that will loop a packet through napi_gro_receive or
> > napi_gro_frags.
>
> This patch addresses the following scenario:
>
> sk ->vxlan -> veth -> (xdp in use, TSO disabled, GRO on) -> veth -> vxlan -> sk
>
> What I meant here is that the issue is not visible with:
>
> (baremetal, NETIF_F_GRO_UDP_FWD | NETIF_F_GRO_FRAGLIST enabled -> vxlan -> sk
>
> > > with the appropriate features bit set, will validate the checksum for
> > > both the inner and the outer header - udp{4,6}_gro_receive will be
> > > traversed twice, the fist one for the outer header, the 2nd for the
> > > inner.
> >
> > GRO will validate multiple levels of checksums with CHECKSUM_COMPLETE.
> > It can only validate the outer checksum with CHECKSUM_UNNECESSARY, I
> > believe?
>
> I possibly miss some bits here ?!?
>
> AFAICS:
>
> udp4_gro_receive() -> skb_gro_checksum_validate_zero_check() ->
> __skb_gro_checksum_validate -> (if  not already valid)
> __skb_gro_checksum_validate_complete() -> (if not CHECKSUM_COMPLETE)
> __skb_gro_checksum_complete()
>
> the latter will validate the UDP checksum at the current nesting level
> (and set the csum-related bits in the GRO skb cb to the same status
> as CHECKSUM_COMPLETE)
>
> When processing UDP over UDP tunnel packet, the gro call chain will be:
>
> [l2/l3 GRO] -> udp4_gro_receive (validate outher header csum) ->
> udp_sk(sk)->gro_receive -> [other gro layers] ->
> udp4_gro_receive (validate inner header csum) -> ...

Agreed. But __skb_gro_checksum_validate on the first invocation will
call skb_gro_incr_csum_unnecessary, so that on the second invocation
csum_cnt == 0 and triggers a real checksum validation?

At least, that is my understanding. Intuitively, CHECKSUM_UNNECESSARY
only validates the first checksum, so says nothing about the validity
of any subsequent ones.

But it seems I'm mistaken?

__skb_gro_checksum_validate has an obvious exception for locally
generated packets by excluding CHECKSUM_PARTIAL. Looped packets
usually have CHECKSUM_PARTIAL set. Unfortunately, this is similar to
the issue that I looked at earlier this year with looped UDP packets
with MSG_MORE: those are also changed to CHECKSUM_NONE (and exposed a
checksum bug: 52cbd23a119c).

Is there perhaps some other way that we can identify that these are
local packets? They should trivially avoid all checksum checks.

> > As for looped packets with CHECKSUM_PARTIAL: we definitely have found
> > bugs in that path before. I think it's fine to set csum_valid on any
> > packets that can unambiguously be identified as such. Hence the
> > detailed questions above on which exact packets this code is
> > targeting, so that there are not accidental false positives that look
> > the same but have a different ip_summed.
>
> I see this change is controversial.

I have no concerns with the fix. It is just a very narrow path (veth +
xdp - tso + gro ..), and to minimize risk I would try to avoid
updating state of unrelated packets. That was my initial comment: I
don't understand the need for the else clause.

> Since the addressed scenario is
> really a corner case, a simpler alternative would be
> replacing udp_post_segment_fix_csum with:
>
> static inline void udp_post_segment_fix_cb(struct sk_buff *skb, int level)
> {
>         /* UDP-lite can't land here - no GRO */
>         WARN_ON_ONCE(UDP_SKB_CB(skb)->partial_cov);
>
>         /* UDP CB mirrors the GSO packet, we must re-init it */
>         UDP_SKB_CB(skb)->cscov = skb->len;
> }
>
> the downside will be an additional, later, unneeded csum validation for the
>
> sk ->vxlan -> veth -> (xdp in use, TSO disabled, GRO on) -> veth -> vxlan -> sk
>
> scenario. WDYT?

No, let's definitely avoid an unneeded checksum verification.

Re: [PATCH net-next 1/8] udp: fixup csum for GSO receive slow path

[Paolo Abeni]

Hello,

On Wed, 2021-03-24 at 18:36 -0400, Willem de Bruijn wrote:
> > > This is a UDP GSO packet egress packet that was further encapsulated
> > > with a GSO_UDP_TUNNEL on egress, then looped to the ingress path?
> > > 
> > > Then in the ingress path it has traversed the GRO layer.
> > > 
> > > Is this veth with XDP? That seems unlikely for GSO packets. But there
> > > aren't many paths that will loop a packet through napi_gro_receive or
> > > napi_gro_frags.
> > 
> > This patch addresses the following scenario:
> > 
> > sk ->vxlan -> veth -> (xdp in use, TSO disabled, GRO on) -> veth -> vxlan -> sk
> > 
> > What I meant here is that the issue is not visible with:
> > 
> > (baremetal, NETIF_F_GRO_UDP_FWD | NETIF_F_GRO_FRAGLIST enabled -> vxlan -> sk
> > 
> > > > with the appropriate features bit set, will validate the checksum for
> > > > both the inner and the outer header - udp{4,6}_gro_receive will be
> > > > traversed twice, the fist one for the outer header, the 2nd for the
> > > > inner.
> > > 
> > > GRO will validate multiple levels of checksums with CHECKSUM_COMPLETE.
> > > It can only validate the outer checksum with CHECKSUM_UNNECESSARY, I
> > > believe?
> > 
> > I possibly miss some bits here ?!?
> > 
> > AFAICS:
> > 
> > udp4_gro_receive() -> skb_gro_checksum_validate_zero_check() ->
> > __skb_gro_checksum_validate -> (if  not already valid)
> > __skb_gro_checksum_validate_complete() -> (if not CHECKSUM_COMPLETE)
> > __skb_gro_checksum_complete()
> > 
> > the latter will validate the UDP checksum at the current nesting level
> > (and set the csum-related bits in the GRO skb cb to the same status
> > as CHECKSUM_COMPLETE)
> > 
> > When processing UDP over UDP tunnel packet, the gro call chain will be:
> > 
> > [l2/l3 GRO] -> udp4_gro_receive (validate outher header csum) ->
> > udp_sk(sk)->gro_receive -> [other gro layers] ->
> > udp4_gro_receive (validate inner header csum) -> ...
> 
> Agreed. But __skb_gro_checksum_validate on the first invocation will
> call skb_gro_incr_csum_unnecessary, so that on the second invocation
> csum_cnt == 0 and triggers a real checksum validation?
> 
> At least, that is my understanding. Intuitively, CHECKSUM_UNNECESSARY
> only validates the first checksum, so says nothing about the validity
> of any subsequent ones.
> 
> But it seems I'm mistaken?

AFAICS, it depends ;) From skbuff.h:

 *   skb->csum_level indicates the number of consecutive checksums found in
 *   the packet minus one that have been verified as CHECKSUM_UNNECESSARY.

if skb->csum_level > 0, the NIC validate additional headers. The intel
ixgbe driver use that for vxlan RX csum offload. Such field translates
into:

	NAPI_GRO_CB(skb)->csum_cnt

inside the GRO engine, and skb_gro_incr_csum_unnecessary takes care of
the updating it after validation.

> __skb_gro_checksum_validate has an obvious exception for locally
> generated packets by excluding CHECKSUM_PARTIAL. Looped packets
> usually have CHECKSUM_PARTIAL set. Unfortunately, this is similar to
> the issue that I looked at earlier this year with looped UDP packets
> with MSG_MORE: those are also changed to CHECKSUM_NONE (and exposed a
> checksum bug: 52cbd23a119c).
> 
> Is there perhaps some other way that we can identify that these are
> local packets? They should trivially avoid all checksum checks.
> 
> > > As for looped packets with CHECKSUM_PARTIAL: we definitely have found
> > > bugs in that path before. I think it's fine to set csum_valid on any
> > > packets that can unambiguously be identified as such. Hence the
> > > detailed questions above on which exact packets this code is
> > > targeting, so that there are not accidental false positives that look
> > > the same but have a different ip_summed.
> > 
> > I see this change is controversial.
> 
> I have no concerns with the fix. It is just a very narrow path (veth +
> xdp - tso + gro ..), and to minimize risk I would try to avoid
> updating state of unrelated packets. That was my initial comment: I
> don't understand the need for the else clause.

The branch is there because I wrote this patch before the patches 5,6,7
later in this series. GSO UDP L4 over UDP tunnel packets were segmented
at the UDP tunnel level, and that 'else' branch preserves the
appropriate 'csum_level' value to avoid later (if/when the packet lands
in a plain UDP socket) csum validation.

> > Since the addressed scenario is
> > really a corner case, a simpler alternative would be
> > replacing udp_post_segment_fix_csum with:
> > 
> > static inline void udp_post_segment_fix_cb(struct sk_buff *skb, int level)
> > {
> >         /* UDP-lite can't land here - no GRO */
> >         WARN_ON_ONCE(UDP_SKB_CB(skb)->partial_cov);
> > 
> >         /* UDP CB mirrors the GSO packet, we must re-init it */
> >         UDP_SKB_CB(skb)->cscov = skb->len;
> > }
> > 
> > the downside will be an additional, later, unneeded csum validation for the
> > 
> > sk ->vxlan -> veth -> (xdp in use, TSO disabled, GRO on) -> veth -> vxlan -> sk
> > 
> > scenario. WDYT?
> 
> No, let's definitely avoid an unneeded checksum verification.

Ok.

My understanding is that the following should be better:

static inline void udp_post_segment_fix_csum(struct sk_buff *skb)
{
	/* UDP-lite can't land here - no GRO */
	WARN_ON_ONCE(UDP_SKB_CB(skb)->partial_cov);

	/* UDP packets generated with UDP_SEGMENT and traversing:
	 * UDP tunnel(xmit) -> veth (segmentation) -> veth (gro) -> UDP tunnel (rx)
	 * land here with CHECKSUM_NONE. Instead of adding another check
	 * in the tunnel fastpath, we can force valid csums here:
	 * packets are locally generated and the GRO engine already validated
	 * the csum.
	 * Additionally fixup the UDP CB
	 */
	UDP_SKB_CB(skb)->cscov = skb->len;
	if (skb->ip_summed == CHECKSUM_NONE && !skb->csum_valid)
		skb->csum_valid = 1;
}

I'll use the above in v2.

Thanks!

Paolo

Re: [PATCH net-next 1/8] udp: fixup csum for GSO receive slow path

[Willem de Bruijn]

On Thu, Mar 25, 2021 at 6:57 AM Paolo Abeni <pabeni@redhat.com> wrote:
>
> Hello,
>
> On Wed, 2021-03-24 at 18:36 -0400, Willem de Bruijn wrote:
> > > > This is a UDP GSO packet egress packet that was further encapsulated
> > > > with a GSO_UDP_TUNNEL on egress, then looped to the ingress path?
> > > >
> > > > Then in the ingress path it has traversed the GRO layer.
> > > >
> > > > Is this veth with XDP? That seems unlikely for GSO packets. But there
> > > > aren't many paths that will loop a packet through napi_gro_receive or
> > > > napi_gro_frags.
> > >
> > > This patch addresses the following scenario:
> > >
> > > sk ->vxlan -> veth -> (xdp in use, TSO disabled, GRO on) -> veth -> vxlan -> sk
> > >
> > > What I meant here is that the issue is not visible with:
> > >
> > > (baremetal, NETIF_F_GRO_UDP_FWD | NETIF_F_GRO_FRAGLIST enabled -> vxlan -> sk
> > >
> > > > > with the appropriate features bit set, will validate the checksum for
> > > > > both the inner and the outer header - udp{4,6}_gro_receive will be
> > > > > traversed twice, the fist one for the outer header, the 2nd for the
> > > > > inner.
> > > >
> > > > GRO will validate multiple levels of checksums with CHECKSUM_COMPLETE.
> > > > It can only validate the outer checksum with CHECKSUM_UNNECESSARY, I
> > > > believe?
> > >
> > > I possibly miss some bits here ?!?
> > >
> > > AFAICS:
> > >
> > > udp4_gro_receive() -> skb_gro_checksum_validate_zero_check() ->
> > > __skb_gro_checksum_validate -> (if  not already valid)
> > > __skb_gro_checksum_validate_complete() -> (if not CHECKSUM_COMPLETE)
> > > __skb_gro_checksum_complete()
> > >
> > > the latter will validate the UDP checksum at the current nesting level
> > > (and set the csum-related bits in the GRO skb cb to the same status
> > > as CHECKSUM_COMPLETE)
> > >
> > > When processing UDP over UDP tunnel packet, the gro call chain will be:
> > >
> > > [l2/l3 GRO] -> udp4_gro_receive (validate outher header csum) ->
> > > udp_sk(sk)->gro_receive -> [other gro layers] ->
> > > udp4_gro_receive (validate inner header csum) -> ...
> >
> > Agreed. But __skb_gro_checksum_validate on the first invocation will
> > call skb_gro_incr_csum_unnecessary, so that on the second invocation
> > csum_cnt == 0 and triggers a real checksum validation?
> >
> > At least, that is my understanding. Intuitively, CHECKSUM_UNNECESSARY
> > only validates the first checksum, so says nothing about the validity
> > of any subsequent ones.
> >
> > But it seems I'm mistaken?
>
> AFAICS, it depends ;) From skbuff.h:
>
>  *   skb->csum_level indicates the number of consecutive checksums found in
>  *   the packet minus one that have been verified as CHECKSUM_UNNECESSARY.
>
> if skb->csum_level > 0, the NIC validate additional headers. The intel
> ixgbe driver use that for vxlan RX csum offload. Such field translates
> into:
>
>         NAPI_GRO_CB(skb)->csum_cnt
>
> inside the GRO engine, and skb_gro_incr_csum_unnecessary takes care of
> the updating it after validation.

True. I glanced over those cases.

More importantly, where exactly do these looped packets get converted
from CHECKSUM_PARTIAL to CHECKSUM_NONE before this patch?

> > __skb_gro_checksum_validate has an obvious exception for locally
> > generated packets by excluding CHECKSUM_PARTIAL. Looped packets
> > usually have CHECKSUM_PARTIAL set. Unfortunately, this is similar to
> > the issue that I looked at earlier this year with looped UDP packets
> > with MSG_MORE: those are also changed to CHECKSUM_NONE (and exposed a
> > checksum bug: 52cbd23a119c).
> >
> > Is there perhaps some other way that we can identify that these are
> > local packets? They should trivially avoid all checksum checks.
> >
> > > > As for looped packets with CHECKSUM_PARTIAL: we definitely have found
> > > > bugs in that path before. I think it's fine to set csum_valid on any
> > > > packets that can unambiguously be identified as such. Hence the
> > > > detailed questions above on which exact packets this code is
> > > > targeting, so that there are not accidental false positives that look
> > > > the same but have a different ip_summed.
> > >
> > > I see this change is controversial.
> >
> > I have no concerns with the fix. It is just a very narrow path (veth +
> > xdp - tso + gro ..), and to minimize risk I would try to avoid
> > updating state of unrelated packets. That was my initial comment: I
> > don't understand the need for the else clause.
>
> The branch is there because I wrote this patch before the patches 5,6,7
> later in this series. GSO UDP L4 over UDP tunnel packets were segmented
> at the UDP tunnel level, and that 'else' branch preserves the
> appropriate 'csum_level' value to avoid later (if/when the packet lands
> in a plain UDP socket) csum validation.
>
> > > Since the addressed scenario is
> > > really a corner case, a simpler alternative would be
> > > replacing udp_post_segment_fix_csum with:
> > >
> > > static inline void udp_post_segment_fix_cb(struct sk_buff *skb, int level)
> > > {
> > >         /* UDP-lite can't land here - no GRO */
> > >         WARN_ON_ONCE(UDP_SKB_CB(skb)->partial_cov);
> > >
> > >         /* UDP CB mirrors the GSO packet, we must re-init it */
> > >         UDP_SKB_CB(skb)->cscov = skb->len;
> > > }
> > >
> > > the downside will be an additional, later, unneeded csum validation for the
> > >
> > > sk ->vxlan -> veth -> (xdp in use, TSO disabled, GRO on) -> veth -> vxlan -> sk
> > >
> > > scenario. WDYT?
> >
> > No, let's definitely avoid an unneeded checksum verification.
>
> Ok.
>
> My understanding is that the following should be better:
>
> static inline void udp_post_segment_fix_csum(struct sk_buff *skb)
> {
>         /* UDP-lite can't land here - no GRO */
>         WARN_ON_ONCE(UDP_SKB_CB(skb)->partial_cov);
>
>         /* UDP packets generated with UDP_SEGMENT and traversing:
>          * UDP tunnel(xmit) -> veth (segmentation) -> veth (gro) -> UDP tunnel (rx)
>          * land here with CHECKSUM_NONE. Instead of adding another check
>          * in the tunnel fastpath, we can force valid csums here:
>          * packets are locally generated and the GRO engine already validated
>          * the csum.
>          * Additionally fixup the UDP CB
>          */
>         UDP_SKB_CB(skb)->cscov = skb->len;
>         if (skb->ip_summed == CHECKSUM_NONE && !skb->csum_valid)
>                 skb->csum_valid = 1;
> }
>
> I'll use the above in v2.

Do I understand correctly that this avoids matching tunneled packets
that arrive from the network with rx checksumming disabled, because
__skb_gro_checksum_complete will have been called on the outer packet
and have set skb->csum_valid?

Yes, this just (1) identifying the packet as being of local source and
then (2) setting csum_valid sounds great to me, thanks.

Re: [PATCH net-next 1/8] udp: fixup csum for GSO receive slow path

[Paolo Abeni]

On Thu, 2021-03-25 at 09:53 -0400, Willem de Bruijn wrote:
> On Thu, Mar 25, 2021 at 6:57 AM Paolo Abeni <pabeni@redhat.com> wrote:
> > AFAICS, it depends ;) From skbuff.h:
> > 
> >  *   skb->csum_level indicates the number of consecutive checksums found in
> >  *   the packet minus one that have been verified as CHECKSUM_UNNECESSARY.
> > 
> > if skb->csum_level > 0, the NIC validate additional headers. The intel
> > ixgbe driver use that for vxlan RX csum offload. Such field translates
> > into:
> > 
> >         NAPI_GRO_CB(skb)->csum_cnt
> > 
> > inside the GRO engine, and skb_gro_incr_csum_unnecessary takes care of
> > the updating it after validation.
> 
> True. I glanced over those cases.
> 
> More importantly, where exactly do these looped packets get converted
> from CHECKSUM_PARTIAL to CHECKSUM_NONE before this patch?

Very good question! It took a bit finding the exact place.

int __iptunnel_pull_header(struct sk_buff *skb, int hdr_len,
			   __be16 inner_proto, bool raw_proto, bool xnet)
{
	if (unlikely(!pskb_may_pull(skb, hdr_len)))
		return -ENOMEM;

	skb_pull_rcsum(skb, hdr_len);
        // here ^^^ via skb_pull_rcsum -> skb_postpull_rcsum() -> __skb_postpull_rcsum()

well, this is actually with _this_ patch applied: it does not change
the place where the ip_summed is set.

> > My understanding is that the following should be better:
> > 
> > static inline void udp_post_segment_fix_csum(struct sk_buff *skb)
> > {
> >         /* UDP-lite can't land here - no GRO */
> >         WARN_ON_ONCE(UDP_SKB_CB(skb)->partial_cov);
> > 
> >         /* UDP packets generated with UDP_SEGMENT and traversing:
> >          * UDP tunnel(xmit) -> veth (segmentation) -> veth (gro) -> UDP tunnel (rx)
> >          * land here with CHECKSUM_NONE. Instead of adding another check
> >          * in the tunnel fastpath, we can force valid csums here:
> >          * packets are locally generated and the GRO engine already validated
> >          * the csum.
> >          * Additionally fixup the UDP CB
> >          */
> >         UDP_SKB_CB(skb)->cscov = skb->len;
> >         if (skb->ip_summed == CHECKSUM_NONE && !skb->csum_valid)
> >                 skb->csum_valid = 1;
> > }
> > 
> > I'll use the above in v2.
> 
> Do I understand correctly that this avoids matching tunneled packets
> that arrive from the network with rx checksumming disabled, because
> __skb_gro_checksum_complete will have been called on the outer packet
> and have set skb->csum_valid?

Exactly. I did the test, and perf probes showed that.

> Yes, this just (1) identifying the packet as being of local source and
> then (2) setting csum_valid sounds great to me, thanks.

Will try to submit v2 soon, after some more testing.

Thanks for all the feedback!

Paolo

[PATCH net-next 2/8] udp: skip fwd/list GRO for tunnel packets

[Paolo Abeni]

If UDP GRO forwarding (or list) is enabled, and there are
udp tunnel available in the system, we could end-up doing L4
aggregation for packets targeting the UDP tunnel.

That could inner protocol corruption, as no overaly network
parameters is taken in account at aggregation time.

Just skip the fwd GRO if this packet could land in an UDP
tunnel. The current check is broader than what is strictly
needed, as the UDP tunnel could be e.g. on top of a different
device, but is simple and the performance downside looks not
relevant.

Fixes: 9fd1ff5d2ac7 ("udp: Support UDP fraglist GRO/GSO.")
Fixes: 36707061d6ba ("udp: allow forwarding of plain (non-fraglisted) UDP GRO packets")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
 net/ipv4/udp_offload.c | 19 +++++++++++--------
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
index c5b4b586570fe..25134a3548e99 100644
--- a/net/ipv4/udp_offload.c
+++ b/net/ipv4/udp_offload.c
@@ -515,21 +515,24 @@ struct sk_buff *udp_gro_receive(struct list_head *head, struct sk_buff *skb,
 	unsigned int off = skb_gro_offset(skb);
 	int flush = 1;
 
+	/* we can do L4 aggregation only if the packet can't land in a tunnel
+	 * otherwise we could corrupt the inner stream
+	 */
 	NAPI_GRO_CB(skb)->is_flist = 0;
-	if (skb->dev->features & NETIF_F_GRO_FRAGLIST)
-		NAPI_GRO_CB(skb)->is_flist = sk ? !udp_sk(sk)->gro_enabled: 1;
+	if (!sk || !udp_sk(sk)->gro_receive) {
+		if (skb->dev->features & NETIF_F_GRO_FRAGLIST)
+			NAPI_GRO_CB(skb)->is_flist = sk ? !udp_sk(sk)->gro_enabled : 1;
 
-	if ((!sk && (skb->dev->features & NETIF_F_GRO_UDP_FWD)) ||
-	    (sk && udp_sk(sk)->gro_enabled) || NAPI_GRO_CB(skb)->is_flist) {
-		pp = call_gro_receive(udp_gro_receive_segment, head, skb);
+		if ((!sk && (skb->dev->features & NETIF_F_GRO_UDP_FWD)) ||
+		    (sk && udp_sk(sk)->gro_enabled) || NAPI_GRO_CB(skb)->is_flist)
+			pp = call_gro_receive(udp_gro_receive_segment, head, skb);
 		return pp;
 	}
 
-	if (!sk || NAPI_GRO_CB(skb)->encap_mark ||
+	if (NAPI_GRO_CB(skb)->encap_mark ||
 	    (uh->check && skb->ip_summed != CHECKSUM_PARTIAL &&
 	     NAPI_GRO_CB(skb)->csum_cnt == 0 &&
-	     !NAPI_GRO_CB(skb)->csum_valid) ||
-	    !udp_sk(sk)->gro_receive)
+	     !NAPI_GRO_CB(skb)->csum_valid))
 		goto out;
 
 	/* mark that this skb passed once through the tunnel gro layer */
-- 
2.26.2

Re: [PATCH net-next 2/8] udp: skip fwd/list GRO for tunnel packets

[Willem de Bruijn]

On Sun, Mar 21, 2021 at 1:01 PM Paolo Abeni <pabeni@redhat.com> wrote:
>
> If UDP GRO forwarding (or list) is enabled,

Please explicitly mention the gso type SKB_GSO_FRAGLIST. I, at least,
didn't immediately grasp that gro forwarding is an alias for that.

> and there are
> udp tunnel available in the system, we could end-up doing L4
> aggregation for packets targeting the UDP tunnel.

Is this specific to UDP tunnels, or can this also occur with others,
such as GRE? (not implying that this patchset needs to address those
at the same time)

> That could inner protocol corruption, as no overaly network
> parameters is taken in account at aggregation time.

nit: overaly .. is taken -> overlay .. are taken

You mean the packets on the frag list may have mtu exceeding the mtu
of the tunnel? Please make the constraint more explicit.

> Just skip the fwd GRO if this packet could land in an UDP
> tunnel.

Could you make more clear that this does not skip UDP GRO, only
switches from fraglist-based to pure SKB_GSO_UDP_L4.

> The current check is broader than what is strictly
> needed, as the UDP tunnel could be e.g. on top of a different
> device, but is simple and the performance downside looks not
> relevant.
>
> Fixes: 9fd1ff5d2ac7 ("udp: Support UDP fraglist GRO/GSO.")
> Fixes: 36707061d6ba ("udp: allow forwarding of plain (non-fraglisted) UDP GRO packets")
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>

Re: [PATCH net-next 2/8] udp: skip fwd/list GRO for tunnel packets

[Paolo Abeni]

On Mon, 2021-03-22 at 09:24 -0400, Willem de Bruijn wrote:
> On Sun, Mar 21, 2021 at 1:01 PM Paolo Abeni <pabeni@redhat.com> wrote:
> > If UDP GRO forwarding (or list) is enabled,
> 
> Please explicitly mention the gso type SKB_GSO_FRAGLIST. I, at least,
> didn't immediately grasp that gro forwarding is an alias for that.

I see the commit message was not clear at all, I'm sorry.

The above means:

gso_type & (NETIF_F_GSO_UDP_L4 | NETIF_F_GSO_FRAGLIST) 

:)

> > and there are
> > udp tunnel available in the system, we could end-up doing L4
> > aggregation for packets targeting the UDP tunnel.
> 
> Is this specific to UDP tunnels, or can this also occur with others,
> such as GRE? (not implying that this patchset needs to address those
> at the same time)

I did not look at that before your suggestion. Thanks for pointing out.

I think the problem is specific to UDP: when processing the outer UDP
header that is potentially eligible for both NETIF_F_GSO_UDP_L4 and
gro_receive aggregation and that is the root cause of the problem
addressed here.


> > Just skip the fwd GRO if this packet could land in an UDP
> > tunnel.
> 
> Could you make more clear that this does not skip UDP GRO, only
> switches from fraglist-based to pure SKB_GSO_UDP_L4.

Sure, I'll try to rewrite the commit message.

Thanks!

Paolo

Re: [PATCH net-next 2/8] udp: skip fwd/list GRO for tunnel packets

[Willem de Bruijn]

> > > and there are
> > > udp tunnel available in the system, we could end-up doing L4
> > > aggregation for packets targeting the UDP tunnel.
> >
> > Is this specific to UDP tunnels, or can this also occur with others,
> > such as GRE? (not implying that this patchset needs to address those
> > at the same time)

I suppose GRE tunnels do not advertise GSO_UDP_L4 support, so GSO
packets would get segmented before entering the tunnel device.

Forwarded datagrams exceeding egress device MTU (whether tunnel or
not) is a wholly separate problem.

> I did not look at that before your suggestion. Thanks for pointing out.
>
> I think the problem is specific to UDP: when processing the outer UDP
> header that is potentially eligible for both NETIF_F_GSO_UDP_L4 and
> gro_receive aggregation and that is the root cause of the problem
> addressed here.

Can you elaborate on the exact problem? The commit mentions "inner
protocol corruption, as no overaly network parameters is taken in
account at aggregation time."

My understanding is that these are udp gro aggregated GSO_UDP_L4
packets forwarded to a udp tunnel device. They are not encapsulated
yet. Which overlay network parameters are not, but should have been,
taken account at aggregation time?

>
>
> > > Just skip the fwd GRO if this packet could land in an UDP
> > > tunnel.
> >
> > Could you make more clear that this does not skip UDP GRO, only
> > switches from fraglist-based to pure SKB_GSO_UDP_L4.
>
> Sure, I'll try to rewrite the commit message.
>
> Thanks!
>
> Paolo
>

!

[Paolo Abeni]

On Tue, 2021-03-23 at 21:54 -0400, Willem de Bruijn wrote:
> > I did not look at that before your suggestion. Thanks for pointing out.
> > 
> > I think the problem is specific to UDP: when processing the outer UDP
> > header that is potentially eligible for both NETIF_F_GSO_UDP_L4 and
> > gro_receive aggregation and that is the root cause of the problem
> > addressed here.
> 
> Can you elaborate on the exact problem? The commit mentions "inner
> protocol corruption, as no overaly network parameters is taken in
> account at aggregation time."
> 
> My understanding is that these are udp gro aggregated GSO_UDP_L4
> packets forwarded to a udp tunnel device. They are not encapsulated
> yet. Which overlay network parameters are not, but should have been,
> taken account at aggregation time?

The scenario is as follow: 

* a NIC has NETIF_F_GRO_UDP_FWD or NETIF_F_GRO_FRAGLIST enabled
* an UDP tunnel is configured/enabled in the system
* the above NIC receives some UDP-tunneled packets, targeting the
mentioned tunnel
* the packets go through gro_receive and they reache
'udp_gro_receive()' while processing the outer UDP header.

without this patch, udp_gro_receive_segment() will kick in and the
outer UDP header will be aggregated according to SKB_GSO_FRAGLIST
or SKB_GSO_UDP_L4, even if this is really e.g. a vxlan packet.

Different vxlan ids will be ignored/aggregated to the same GSO packet.
Inner headers will be ignored, too, so that e.g. TCP over vxlan push
packets will be held in the GRO engine till the next flush, etc.

Please let me know if the above is more clear.

Thanks!

Paolo

Re: !

[Willem de Bruijn]

On Wed, Mar 24, 2021 at 10:51 AM Paolo Abeni <pabeni@redhat.com> wrote:
>
> On Tue, 2021-03-23 at 21:54 -0400, Willem de Bruijn wrote:
> > > I did not look at that before your suggestion. Thanks for pointing out.
> > >
> > > I think the problem is specific to UDP: when processing the outer UDP
> > > header that is potentially eligible for both NETIF_F_GSO_UDP_L4 and
> > > gro_receive aggregation and that is the root cause of the problem
> > > addressed here.
> >
> > Can you elaborate on the exact problem? The commit mentions "inner
> > protocol corruption, as no overaly network parameters is taken in
> > account at aggregation time."
> >
> > My understanding is that these are udp gro aggregated GSO_UDP_L4
> > packets forwarded to a udp tunnel device. They are not encapsulated
> > yet. Which overlay network parameters are not, but should have been,
> > taken account at aggregation time?
>
> The scenario is as follow:
>
> * a NIC has NETIF_F_GRO_UDP_FWD or NETIF_F_GRO_FRAGLIST enabled
> * an UDP tunnel is configured/enabled in the system
> * the above NIC receives some UDP-tunneled packets, targeting the
> mentioned tunnel
> * the packets go through gro_receive and they reache
> 'udp_gro_receive()' while processing the outer UDP header.
>
> without this patch, udp_gro_receive_segment() will kick in and the
> outer UDP header will be aggregated according to SKB_GSO_FRAGLIST
> or SKB_GSO_UDP_L4, even if this is really e.g. a vxlan packet.
>
> Different vxlan ids will be ignored/aggregated to the same GSO packet.
> Inner headers will be ignored, too, so that e.g. TCP over vxlan push
> packets will be held in the GRO engine till the next flush, etc.
>
> Please let me know if the above is more clear.

Yes, thanks a lot! That's very concrete.

When processing the outer UDP tunnel header in the gro completion
path, it is incorrectly identified as an inner UDP transport layer due
to NAPI_GRO_CB(skb) identifying that such a layer is present
(is_flist).

The issue is that the UDP GRO layer distinguishes between tunnel and
transport layer too late, in udp_gro_complete, while an offending
assumption of that UDP == transport layer was already made in the
callers udp4_gro_complete and udp6_gro_complete.

[PATCH net-next 3/8] udp: properly complete L4 GRO over UDP tunnel packet

[Paolo Abeni]

After the previous patch the stack can do L4 UDP aggregation
on top of an UDP tunnel.

The current GRO complete code tries frag based aggregation first;
in the above scenario will generate corrupted frames.

We need to try first UDP tunnel based aggregation, if the GRO
packet requires that. We can use time GRO 'encap_mark' field
to track the need GRO complete action. If encap_mark is set,
skip the frag_list aggregation.

On tunnel encap GRO complete clear such field, so that an inner
frag_list GRO complete could take action.

Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
 net/ipv4/udp_offload.c | 8 +++++++-
 net/ipv6/udp_offload.c | 3 ++-
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
index 25134a3548e99..54e06b88af69a 100644
--- a/net/ipv4/udp_offload.c
+++ b/net/ipv4/udp_offload.c
@@ -642,6 +642,11 @@ int udp_gro_complete(struct sk_buff *skb, int nhoff,
 		skb_shinfo(skb)->gso_type = uh->check ? SKB_GSO_UDP_TUNNEL_CSUM
 					: SKB_GSO_UDP_TUNNEL;
 
+		/* clear the encap mark, so that inner frag_list gro_complete
+		 * can take place
+		 */
+		NAPI_GRO_CB(skb)->encap_mark = 0;
+
 		/* Set encapsulation before calling into inner gro_complete()
 		 * functions to make them set up the inner offsets.
 		 */
@@ -665,7 +670,8 @@ INDIRECT_CALLABLE_SCOPE int udp4_gro_complete(struct sk_buff *skb, int nhoff)
 	const struct iphdr *iph = ip_hdr(skb);
 	struct udphdr *uh = (struct udphdr *)(skb->data + nhoff);
 
-	if (NAPI_GRO_CB(skb)->is_flist) {
+	/* do fraglist only if there is no outer UDP encap (or we already processed it) */
+	if (NAPI_GRO_CB(skb)->is_flist && !NAPI_GRO_CB(skb)->encap_mark) {
 		uh->len = htons(skb->len - nhoff);
 
 		skb_shinfo(skb)->gso_type |= (SKB_GSO_FRAGLIST|SKB_GSO_UDP_L4);
diff --git a/net/ipv6/udp_offload.c b/net/ipv6/udp_offload.c
index faa823c242923..b3d9ed96e5ea5 100644
--- a/net/ipv6/udp_offload.c
+++ b/net/ipv6/udp_offload.c
@@ -163,7 +163,8 @@ INDIRECT_CALLABLE_SCOPE int udp6_gro_complete(struct sk_buff *skb, int nhoff)
 	const struct ipv6hdr *ipv6h = ipv6_hdr(skb);
 	struct udphdr *uh = (struct udphdr *)(skb->data + nhoff);
 
-	if (NAPI_GRO_CB(skb)->is_flist) {
+	/* do fraglist only if there is no outer UDP encap (or we already processed it) */
+	if (NAPI_GRO_CB(skb)->is_flist && !NAPI_GRO_CB(skb)->encap_mark) {
 		uh->len = htons(skb->len - nhoff);
 
 		skb_shinfo(skb)->gso_type |= (SKB_GSO_FRAGLIST|SKB_GSO_UDP_L4);
-- 
2.26.2

Re: [PATCH net-next 3/8] udp: properly complete L4 GRO over UDP tunnel packet

[Willem de Bruijn]

On Sun, Mar 21, 2021 at 1:01 PM Paolo Abeni <pabeni@redhat.com> wrote:
>
> After the previous patch the stack can do L4 UDP aggregation
> on top of an UDP tunnel.
>
> The current GRO complete code tries frag based aggregation first;
> in the above scenario will generate corrupted frames.
>
> We need to try first UDP tunnel based aggregation, if the GRO
> packet requires that. We can use time GRO 'encap_mark' field
> to track the need GRO complete action. If encap_mark is set,
> skip the frag_list aggregation.
>
> On tunnel encap GRO complete clear such field, so that an inner
> frag_list GRO complete could take action.
>
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> ---
>  net/ipv4/udp_offload.c | 8 +++++++-
>  net/ipv6/udp_offload.c | 3 ++-
>  2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
> index 25134a3548e99..54e06b88af69a 100644
> --- a/net/ipv4/udp_offload.c
> +++ b/net/ipv4/udp_offload.c
> @@ -642,6 +642,11 @@ int udp_gro_complete(struct sk_buff *skb, int nhoff,
>                 skb_shinfo(skb)->gso_type = uh->check ? SKB_GSO_UDP_TUNNEL_CSUM
>                                         : SKB_GSO_UDP_TUNNEL;
>
> +               /* clear the encap mark, so that inner frag_list gro_complete
> +                * can take place
> +                */
> +               NAPI_GRO_CB(skb)->encap_mark = 0;
> +
>                 /* Set encapsulation before calling into inner gro_complete()
>                  * functions to make them set up the inner offsets.
>                  */
> @@ -665,7 +670,8 @@ INDIRECT_CALLABLE_SCOPE int udp4_gro_complete(struct sk_buff *skb, int nhoff)
>         const struct iphdr *iph = ip_hdr(skb);
>         struct udphdr *uh = (struct udphdr *)(skb->data + nhoff);
>
> -       if (NAPI_GRO_CB(skb)->is_flist) {
> +       /* do fraglist only if there is no outer UDP encap (or we already processed it) */
> +       if (NAPI_GRO_CB(skb)->is_flist && !NAPI_GRO_CB(skb)->encap_mark) {

Sorry, I don't follow. I thought the point was to avoid fraglist if an
outer udp tunnel header is present. But the above code clears the mark
and allows entering the fraglist branch exactly when such a header is
encountered?

>                 uh->len = htons(skb->len - nhoff);
>
>                 skb_shinfo(skb)->gso_type |= (SKB_GSO_FRAGLIST|SKB_GSO_UDP_L4);
> diff --git a/net/ipv6/udp_offload.c b/net/ipv6/udp_offload.c
> index faa823c242923..b3d9ed96e5ea5 100644
> --- a/net/ipv6/udp_offload.c
> +++ b/net/ipv6/udp_offload.c
> @@ -163,7 +163,8 @@ INDIRECT_CALLABLE_SCOPE int udp6_gro_complete(struct sk_buff *skb, int nhoff)
>         const struct ipv6hdr *ipv6h = ipv6_hdr(skb);
>         struct udphdr *uh = (struct udphdr *)(skb->data + nhoff);
>
> -       if (NAPI_GRO_CB(skb)->is_flist) {
> +       /* do fraglist only if there is no outer UDP encap (or we already processed it) */
> +       if (NAPI_GRO_CB(skb)->is_flist && !NAPI_GRO_CB(skb)->encap_mark) {
>                 uh->len = htons(skb->len - nhoff);
>
>                 skb_shinfo(skb)->gso_type |= (SKB_GSO_FRAGLIST|SKB_GSO_UDP_L4);
> --
> 2.26.2
>

Re: [PATCH net-next 3/8] udp: properly complete L4 GRO over UDP tunnel packet

[Paolo Abeni]

On Mon, 2021-03-22 at 09:30 -0400, Willem de Bruijn wrote:
> On Sun, Mar 21, 2021 at 1:01 PM Paolo Abeni <pabeni@redhat.com> wrote:
> > After the previous patch the stack can do L4 UDP aggregation
> > on top of an UDP tunnel.
> > 
> > The current GRO complete code tries frag based aggregation first;
> > in the above scenario will generate corrupted frames.
> > 
> > We need to try first UDP tunnel based aggregation, if the GRO
> > packet requires that. We can use time GRO 'encap_mark' field
> > to track the need GRO complete action. If encap_mark is set,
> > skip the frag_list aggregation.
> > 
> > On tunnel encap GRO complete clear such field, so that an inner
> > frag_list GRO complete could take action.
> > 
> > Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> > ---
> >  net/ipv4/udp_offload.c | 8 +++++++-
> >  net/ipv6/udp_offload.c | 3 ++-
> >  2 files changed, 9 insertions(+), 2 deletions(-)
> > 
> > diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
> > index 25134a3548e99..54e06b88af69a 100644
> > --- a/net/ipv4/udp_offload.c
> > +++ b/net/ipv4/udp_offload.c
> > @@ -642,6 +642,11 @@ int udp_gro_complete(struct sk_buff *skb, int nhoff,
> >                 skb_shinfo(skb)->gso_type = uh->check ? SKB_GSO_UDP_TUNNEL_CSUM
> >                                         : SKB_GSO_UDP_TUNNEL;
> > 
> > +               /* clear the encap mark, so that inner frag_list gro_complete
> > +                * can take place
> > +                */
> > +               NAPI_GRO_CB(skb)->encap_mark = 0;
> > +
> >                 /* Set encapsulation before calling into inner gro_complete()
> >                  * functions to make them set up the inner offsets.
> >                  */
> > @@ -665,7 +670,8 @@ INDIRECT_CALLABLE_SCOPE int udp4_gro_complete(struct sk_buff *skb, int nhoff)
> >         const struct iphdr *iph = ip_hdr(skb);
> >         struct udphdr *uh = (struct udphdr *)(skb->data + nhoff);
> > 
> > -       if (NAPI_GRO_CB(skb)->is_flist) {
> > +       /* do fraglist only if there is no outer UDP encap (or we already processed it) */
> > +       if (NAPI_GRO_CB(skb)->is_flist && !NAPI_GRO_CB(skb)->encap_mark) {
> 
> Sorry, I don't follow. I thought the point was to avoid fraglist if an
> outer udp tunnel header is present. But the above code clears the mark
> and allows entering the fraglist branch exactly when such a header is
> encountered?

The relevant UDP packet has gone through:

[l2/l3 GRO] -> udp_gro_receive  -> udp_sk(sk)->gro_receive -> [some
more GRO layers] -> udp_gro_receive (again)

The first udp_gro_receive set NAPI_GRO_CB(skb)->encap_mark, the
latter udp_gro_receive set NAPI_GRO_CB(skb)->is_flist.

Then, at GRO complete time:

[l2/l3 GRO] -> udp{4,6}_gro_complete -> udp_sk(sk)->gro_complete ->
[more GRO layers] -> udp{4,6}_gro_complete (again).

In the first udp{4,6}_gro_complete invocation 'encap_mark' is 1, so
with this patch we do the 'udp_sk(sk)->gro_complete' path. In the
second udp{4,6}_gro_complete invocation 'encap_mark' has been cleared
(by udp_gro_complete), so we do the SKB_GSO_FRAGLIST completion.

In case SKB_GSO_FRAGLIST with no UDP tunnel, 'encap_mark' is 0 and we
do the SKB_GSO_FRAGLIST completion.

Another alternative, possibly more readable, would be avoid clearing
'encap_mark' in udp_gro_complete() and replacing the above check with:

	if (NAPI_GRO_CB(skb)->is_flist &&
            (!NAPI_GRO_CB(skb)->encap_mark ||
 	     (NAPI_GRO_CB(skb)->encap_mark && skb->encapsulation))) {

I opted otherwise to simplify the conditional expression.

Please let me know if the above is somewhat more clear and if you have
preferecens between the two options.

Cheers,

Paolo

Re: [PATCH net-next 3/8] udp: properly complete L4 GRO over UDP tunnel packet

[Willem de Bruijn]

On Mon, Mar 22, 2021 at 1:00 PM Paolo Abeni <pabeni@redhat.com> wrote:
>
> On Mon, 2021-03-22 at 09:30 -0400, Willem de Bruijn wrote:
> > On Sun, Mar 21, 2021 at 1:01 PM Paolo Abeni <pabeni@redhat.com> wrote:
> > > After the previous patch the stack can do L4 UDP aggregation
> > > on top of an UDP tunnel.
> > >
> > > The current GRO complete code tries frag based aggregation first;
> > > in the above scenario will generate corrupted frames.
> > >
> > > We need to try first UDP tunnel based aggregation, if the GRO
> > > packet requires that. We can use time GRO 'encap_mark' field
> > > to track the need GRO complete action. If encap_mark is set,
> > > skip the frag_list aggregation.
> > >
> > > On tunnel encap GRO complete clear such field, so that an inner
> > > frag_list GRO complete could take action.
> > >
> > > Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> > > ---
> > >  net/ipv4/udp_offload.c | 8 +++++++-
> > >  net/ipv6/udp_offload.c | 3 ++-
> > >  2 files changed, 9 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
> > > index 25134a3548e99..54e06b88af69a 100644
> > > --- a/net/ipv4/udp_offload.c
> > > +++ b/net/ipv4/udp_offload.c
> > > @@ -642,6 +642,11 @@ int udp_gro_complete(struct sk_buff *skb, int nhoff,
> > >                 skb_shinfo(skb)->gso_type = uh->check ? SKB_GSO_UDP_TUNNEL_CSUM
> > >                                         : SKB_GSO_UDP_TUNNEL;
> > >
> > > +               /* clear the encap mark, so that inner frag_list gro_complete
> > > +                * can take place
> > > +                */
> > > +               NAPI_GRO_CB(skb)->encap_mark = 0;
> > > +
> > >                 /* Set encapsulation before calling into inner gro_complete()
> > >                  * functions to make them set up the inner offsets.
> > >                  */
> > > @@ -665,7 +670,8 @@ INDIRECT_CALLABLE_SCOPE int udp4_gro_complete(struct sk_buff *skb, int nhoff)
> > >         const struct iphdr *iph = ip_hdr(skb);
> > >         struct udphdr *uh = (struct udphdr *)(skb->data + nhoff);
> > >
> > > -       if (NAPI_GRO_CB(skb)->is_flist) {
> > > +       /* do fraglist only if there is no outer UDP encap (or we already processed it) */
> > > +       if (NAPI_GRO_CB(skb)->is_flist && !NAPI_GRO_CB(skb)->encap_mark) {
> >
> > Sorry, I don't follow. I thought the point was to avoid fraglist if an
> > outer udp tunnel header is present. But the above code clears the mark
> > and allows entering the fraglist branch exactly when such a header is
> > encountered?
>
> The relevant UDP packet has gone through:
>
> [l2/l3 GRO] -> udp_gro_receive  -> udp_sk(sk)->gro_receive -> [some
> more GRO layers] -> udp_gro_receive (again)
>
> The first udp_gro_receive set NAPI_GRO_CB(skb)->encap_mark, the
> latter udp_gro_receive set NAPI_GRO_CB(skb)->is_flist.
>
> Then, at GRO complete time:
>
> [l2/l3 GRO] -> udp{4,6}_gro_complete -> udp_sk(sk)->gro_complete ->
> [more GRO layers] -> udp{4,6}_gro_complete (again).
>
> In the first udp{4,6}_gro_complete invocation 'encap_mark' is 1, so
> with this patch we do the 'udp_sk(sk)->gro_complete' path. In the
> second udp{4,6}_gro_complete invocation 'encap_mark' has been cleared
> (by udp_gro_complete), so we do the SKB_GSO_FRAGLIST completion.
>
> In case SKB_GSO_FRAGLIST with no UDP tunnel, 'encap_mark' is 0 and we
> do the SKB_GSO_FRAGLIST completion.
>
> Another alternative, possibly more readable, would be avoid clearing
> 'encap_mark' in udp_gro_complete() and replacing the above check with:
>
>         if (NAPI_GRO_CB(skb)->is_flist &&
>             (!NAPI_GRO_CB(skb)->encap_mark ||
>              (NAPI_GRO_CB(skb)->encap_mark && skb->encapsulation))) {
>
> I opted otherwise to simplify the conditional expression.
>
> Please let me know if the above is somewhat more clear and if you have
> preferecens between the two options.

Got it now, thanks. Yes, this patch makes sense.

When the GRO layer has built a GSO packet with both inner UDP
(GSO_UDP_L4) and UDP tunnel header (GSO_UDP_TUNNEL), then on
completion udp{4,6}_gro_complete will be called twice. This function
will enter its is_flist branch immediately, even though that is only
correct on the second call, as GSO_FRAGLIST is only relevant for the
inner packet. Skip this while encap_mark == 1, identifying processing
of the outer tunnel header. Clear the field to enter the path on the next
round, for the inner header.

This is subject to only supporting a single layer of encap, but that
is indeed the current state afaik.

[PATCH net-next 4/8] udp: never accept GSO_FRAGLIST packets

[Paolo Abeni]

Currently the UDP protocol delivers GSO_FRAGLIST packets to
the sockets without the expected segmentation.

This change addresses the issue introducing and maintaining
a per socket bitmask of GSO types requiring segmentation.
Enabling GSO removes SKB_GSO_UDP_L4 from such mask, while
GSO_FRAGLIST packets are never accepted

Note: this also updates the 'unused' field size to really
fit the otherwise existing hole. It's size become incorrect
after commit bec1f6f69736 ("udp: generate gso with UDP_SEGMENT").

Fixes: 9fd1ff5d2ac7 ("udp: Support UDP fraglist GRO/GSO.")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
 include/linux/udp.h | 10 ++++++----
 net/ipv4/udp.c      | 12 +++++++++++-
 2 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/include/linux/udp.h b/include/linux/udp.h
index aa84597bdc33c..6da342f15f351 100644
--- a/include/linux/udp.h
+++ b/include/linux/udp.h
@@ -51,7 +51,7 @@ struct udp_sock {
 					   * different encapsulation layer set
 					   * this
 					   */
-			 gro_enabled:1;	/* Can accept GRO packets */
+			 gro_enabled:1;	/* Request GRO aggregation */
 	/*
 	 * Following member retains the information to create a UDP header
 	 * when the socket is uncorked.
@@ -68,7 +68,10 @@ struct udp_sock {
 #define UDPLITE_SEND_CC  0x2  		/* set via udplite setsockopt         */
 #define UDPLITE_RECV_CC  0x4		/* set via udplite setsocktopt        */
 	__u8		 pcflag;        /* marks socket as UDP-Lite if > 0    */
-	__u8		 unused[3];
+	__u8		 unused[1];
+	unsigned int	 unexpected_gso;/* GSO types this socket can't accept,
+					 * any of SKB_GSO_UDP_L4 or SKB_GSO_FRAGLIST
+					 */
 	/*
 	 * For encapsulation sockets.
 	 */
@@ -131,8 +134,7 @@ static inline void udp_cmsg_recv(struct msghdr *msg, struct sock *sk,
 
 static inline bool udp_unexpected_gso(struct sock *sk, struct sk_buff *skb)
 {
-	return !udp_sk(sk)->gro_enabled && skb_is_gso(skb) &&
-	       skb_shinfo(skb)->gso_type & SKB_GSO_UDP_L4;
+	return skb_is_gso(skb) && skb_shinfo(skb)->gso_type & udp_sk(sk)->unexpected_gso;
 }
 
 #define udp_portaddr_for_each_entry(__sk, list) \
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index ff54135c51ffa..1ba6d153c2f0a 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1600,8 +1600,13 @@ EXPORT_SYMBOL_GPL(udp_destruct_sock);
 
 int udp_init_sock(struct sock *sk)
 {
-	skb_queue_head_init(&udp_sk(sk)->reader_queue);
+	struct udp_sock *up = udp_sk(sk);
+
+	skb_queue_head_init(&up->reader_queue);
 	sk->sk_destruct = udp_destruct_sock;
+
+	/* do not accept any GSO packet by default */
+	up->unexpected_gso = SKB_GSO_FRAGLIST | SKB_GSO_UDP_L4;
 	return 0;
 }
 EXPORT_SYMBOL_GPL(udp_init_sock);
@@ -2674,8 +2679,13 @@ int udp_lib_setsockopt(struct sock *sk, int level, int optname,
 
 	case UDP_GRO:
 		lock_sock(sk);
+
+		/* when enabling GRO, accept the related GSO packet type */
+		up->unexpected_gso = SKB_GSO_FRAGLIST;
 		if (valbool)
 			udp_tunnel_encap_enable(sk->sk_socket);
+		else
+			up->unexpected_gso |= SKB_GSO_UDP_L4;
 		up->gro_enabled = valbool;
 		release_sock(sk);
 		break;
-- 
2.26.2

Re: [PATCH net-next 4/8] udp: never accept GSO_FRAGLIST packets

[Willem de Bruijn]

On Sun, Mar 21, 2021 at 1:01 PM Paolo Abeni <pabeni@redhat.com> wrote:
>
> Currently the UDP protocol delivers GSO_FRAGLIST packets to
> the sockets without the expected segmentation.
>
> This change addresses the issue introducing and maintaining
> a per socket bitmask of GSO types requiring segmentation.
> Enabling GSO removes SKB_GSO_UDP_L4 from such mask, while
> GSO_FRAGLIST packets are never accepted
>
> Note: this also updates the 'unused' field size to really
> fit the otherwise existing hole. It's size become incorrect
> after commit bec1f6f69736 ("udp: generate gso with UDP_SEGMENT").
>
> Fixes: 9fd1ff5d2ac7 ("udp: Support UDP fraglist GRO/GSO.")
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> ---
>  include/linux/udp.h | 10 ++++++----
>  net/ipv4/udp.c      | 12 +++++++++++-
>  2 files changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/udp.h b/include/linux/udp.h
> index aa84597bdc33c..6da342f15f351 100644
> --- a/include/linux/udp.h
> +++ b/include/linux/udp.h
> @@ -51,7 +51,7 @@ struct udp_sock {
>                                            * different encapsulation layer set
>                                            * this
>                                            */
> -                        gro_enabled:1; /* Can accept GRO packets */
> +                        gro_enabled:1; /* Request GRO aggregation */

unnecessary comment change?

>         /*
>          * Following member retains the information to create a UDP header
>          * when the socket is uncorked.
> @@ -68,7 +68,10 @@ struct udp_sock {
>  #define UDPLITE_SEND_CC  0x2           /* set via udplite setsockopt         */
>  #define UDPLITE_RECV_CC  0x4           /* set via udplite setsocktopt        */
>         __u8             pcflag;        /* marks socket as UDP-Lite if > 0    */
> -       __u8             unused[3];
> +       __u8             unused[1];
> +       unsigned int     unexpected_gso;/* GSO types this socket can't accept,
> +                                        * any of SKB_GSO_UDP_L4 or SKB_GSO_FRAGLIST
> +                                        */

An extra unsigned int for this seems overkill.

Current sockets that support SKB_GSO_UDP_L4 implicitly also support
SKB_GSO_FRAGLIST. This patch makes explicit that the second is not
supported..

>         /*
>          * For encapsulation sockets.
>          */
> @@ -131,8 +134,7 @@ static inline void udp_cmsg_recv(struct msghdr *msg, struct sock *sk,
>
>  static inline bool udp_unexpected_gso(struct sock *sk, struct sk_buff *skb)
>  {
> -       return !udp_sk(sk)->gro_enabled && skb_is_gso(skb) &&
> -              skb_shinfo(skb)->gso_type & SKB_GSO_UDP_L4;
> +       return skb_is_gso(skb) && skb_shinfo(skb)->gso_type & udp_sk(sk)->unexpected_gso;

.. just update this function as follows ?

 -       return !udp_sk(sk)->gro_enabled && skb_is_gso(skb) &&
 -              skb_shinfo(skb)->gso_type & SKB_GSO_UDP_L4;
+       return skb_is_gso(skb) &&
+                 (skb_shinfo(skb)->gso_type & SKB_GSO_FRAGLIST ||
!udp_sk(sk)->gro_enabled)

where the latter is shorthand for

  (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_L4 && !udp_sk(sk)->gro_enabled)

but the are the only two GSO types that could arrive here.

Re: [PATCH net-next 4/8] udp: never accept GSO_FRAGLIST packets

[Paolo Abeni]

On Mon, 2021-03-22 at 09:42 -0400, Willem de Bruijn wrote:
> On Sun, Mar 21, 2021 at 1:01 PM Paolo Abeni <pabeni@redhat.com> wrote:
> > Currently the UDP protocol delivers GSO_FRAGLIST packets to
> > the sockets without the expected segmentation.
> > 
> > This change addresses the issue introducing and maintaining
> > a per socket bitmask of GSO types requiring segmentation.
> > Enabling GSO removes SKB_GSO_UDP_L4 from such mask, while
> > GSO_FRAGLIST packets are never accepted
> > 
> > Note: this also updates the 'unused' field size to really
> > fit the otherwise existing hole. It's size become incorrect
> > after commit bec1f6f69736 ("udp: generate gso with UDP_SEGMENT").
> > 
> > Fixes: 9fd1ff5d2ac7 ("udp: Support UDP fraglist GRO/GSO.")
> > Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> > ---
> >  include/linux/udp.h | 10 ++++++----
> >  net/ipv4/udp.c      | 12 +++++++++++-
> >  2 files changed, 17 insertions(+), 5 deletions(-)
> > 
> > diff --git a/include/linux/udp.h b/include/linux/udp.h
> > index aa84597bdc33c..6da342f15f351 100644
> > --- a/include/linux/udp.h
> > +++ b/include/linux/udp.h
> > @@ -51,7 +51,7 @@ struct udp_sock {
> >                                            * different encapsulation layer set
> >                                            * this
> >                                            */
> > -                        gro_enabled:1; /* Can accept GRO packets */
> > +                        gro_enabled:1; /* Request GRO aggregation */
> 
> unnecessary comment change?

Before this patch 'gro_enabled' was used in udp_unexpected_gso() to
check for GSO packets acceptance, after this patch such field is not
used there anymore, so does not carry explicilty the 'accept GRO
packets' semantic.

Anyway I don't have strong feeling regarding changing or not this
comment

> >         /*
> >          * Following member retains the information to create a UDP header
> >          * when the socket is uncorked.
> > @@ -68,7 +68,10 @@ struct udp_sock {
> >  #define UDPLITE_SEND_CC  0x2           /* set via udplite setsockopt         */
> >  #define UDPLITE_RECV_CC  0x4           /* set via udplite setsocktopt        */
> >         __u8             pcflag;        /* marks socket as UDP-Lite if > 0    */
> > -       __u8             unused[3];
> > +       __u8             unused[1];
> > +       unsigned int     unexpected_gso;/* GSO types this socket can't accept,
> > +                                        * any of SKB_GSO_UDP_L4 or SKB_GSO_FRAGLIST
> > +                                        */
> 
> An extra unsigned int for this seems overkill.

Should be more clear after the next patch.

Using an explicit 'acceptable GSO types' field makes the patch 5/8
quite simple.

After this patch the 'udp_sock' struct size remains unchanged and even
the number of 'udp_sock' cachelines touched for every packet is
unchanged.

I opted for an 'unsigned int' so that I could simply copy a gso_type
there.

> Current sockets that support SKB_GSO_UDP_L4 implicitly also support
> SKB_GSO_FRAGLIST. This patch makes explicit that the second is not
> supported..
> 
> >         /*
> >          * For encapsulation sockets.
> >          */
> > @@ -131,8 +134,7 @@ static inline void udp_cmsg_recv(struct msghdr *msg, struct sock *sk,
> > 
> >  static inline bool udp_unexpected_gso(struct sock *sk, struct sk_buff *skb)
> >  {
> > -       return !udp_sk(sk)->gro_enabled && skb_is_gso(skb) &&
> > -              skb_shinfo(skb)->gso_type & SKB_GSO_UDP_L4;
> > +       return skb_is_gso(skb) && skb_shinfo(skb)->gso_type & udp_sk(sk)->unexpected_gso;
> 
> .. just update this function as follows ?
> 
>  -       return !udp_sk(sk)->gro_enabled && skb_is_gso(skb) &&
>  -              skb_shinfo(skb)->gso_type & SKB_GSO_UDP_L4;
> +       return skb_is_gso(skb) &&
> +                 (skb_shinfo(skb)->gso_type & SKB_GSO_FRAGLIST ||
> !udp_sk(sk)->gro_enabled)
> 
> where the latter is shorthand for
> 
>   (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_L4 && !udp_sk(sk)->gro_enabled)
> 
> but the are the only two GSO types that could arrive here.

With the above patch 5/8 becomes messy ?!?

Thanks!

Paolo

Re: [PATCH net-next 4/8] udp: never accept GSO_FRAGLIST packets

[Willem de Bruijn]

On Mon, Mar 22, 2021 at 1:12 PM Paolo Abeni <pabeni@redhat.com> wrote:
>
> On Mon, 2021-03-22 at 09:42 -0400, Willem de Bruijn wrote:
> > On Sun, Mar 21, 2021 at 1:01 PM Paolo Abeni <pabeni@redhat.com> wrote:
> > > Currently the UDP protocol delivers GSO_FRAGLIST packets to
> > > the sockets without the expected segmentation.
> > >
> > > This change addresses the issue introducing and maintaining
> > > a per socket bitmask of GSO types requiring segmentation.
> > > Enabling GSO removes SKB_GSO_UDP_L4 from such mask, while
> > > GSO_FRAGLIST packets are never accepted
> > >
> > > Note: this also updates the 'unused' field size to really
> > > fit the otherwise existing hole. It's size become incorrect
> > > after commit bec1f6f69736 ("udp: generate gso with UDP_SEGMENT").
> > >
> > > Fixes: 9fd1ff5d2ac7 ("udp: Support UDP fraglist GRO/GSO.")
> > > Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> > > ---
> > >  include/linux/udp.h | 10 ++++++----
> > >  net/ipv4/udp.c      | 12 +++++++++++-
> > >  2 files changed, 17 insertions(+), 5 deletions(-)
> > >

> > >         /*
> > >          * Following member retains the information to create a UDP header
> > >          * when the socket is uncorked.
> > > @@ -68,7 +68,10 @@ struct udp_sock {
> > >  #define UDPLITE_SEND_CC  0x2           /* set via udplite setsockopt         */
> > >  #define UDPLITE_RECV_CC  0x4           /* set via udplite setsocktopt        */
> > >         __u8             pcflag;        /* marks socket as UDP-Lite if > 0    */
> > > -       __u8             unused[3];
> > > +       __u8             unused[1];
> > > +       unsigned int     unexpected_gso;/* GSO types this socket can't accept,
> > > +                                        * any of SKB_GSO_UDP_L4 or SKB_GSO_FRAGLIST
> > > +                                        */
> >
> > An extra unsigned int for this seems overkill.
>
> Should be more clear after the next patch.
>
> Using an explicit 'acceptable GSO types' field makes the patch 5/8
> quite simple.
>
> After this patch the 'udp_sock' struct size remains unchanged and even
> the number of 'udp_sock' cachelines touched for every packet is
> unchanged.

But there is opportunity cost, of course. Next time we need to add
something to the struct, we will add a new cacheline.

A 32-bit field for just 2 bits, where 1 already exists does seem like overkill.

More importantly, I just think it's less obvious code than a pair of fields

  accepts_udp_l4:1,
  accepts_udp_fraglist:1,

Local sockets can only accept the first, as there does not exist an
interface to pass along the multiple frag sizes that a frag_list based
approach might have.

Sockets with encap_rcv != NULL may opt-in to being able to handle either.

I think explicit code will be more maintainable. At the cost of
perhaps two branches instead of one, admittedly. But that seems
premature optimization.

Re: [PATCH net-next 4/8] udp: never accept GSO_FRAGLIST packets

[Paolo Abeni]

On Tue, 2021-03-23 at 22:21 -0400, Willem de Bruijn wrote:
> On Mon, Mar 22, 2021 at 1:12 PM Paolo Abeni <pabeni@redhat.com> wrote:
> > On Mon, 2021-03-22 at 09:42 -0400, Willem de Bruijn wrote:
> > > On Sun, Mar 21, 2021 at 1:01 PM Paolo Abeni <pabeni@redhat.com> wrote:
> > > > Currently the UDP protocol delivers GSO_FRAGLIST packets to
> > > > the sockets without the expected segmentation.
> > > > 
> > > > This change addresses the issue introducing and maintaining
> > > > a per socket bitmask of GSO types requiring segmentation.
> > > > Enabling GSO removes SKB_GSO_UDP_L4 from such mask, while
> > > > GSO_FRAGLIST packets are never accepted
> > > > 
> > > > Note: this also updates the 'unused' field size to really
> > > > fit the otherwise existing hole. It's size become incorrect
> > > > after commit bec1f6f69736 ("udp: generate gso with UDP_SEGMENT").
> > > > 
> > > > Fixes: 9fd1ff5d2ac7 ("udp: Support UDP fraglist GRO/GSO.")
> > > > Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> > > > ---
> > > >  include/linux/udp.h | 10 ++++++----
> > > >  net/ipv4/udp.c      | 12 +++++++++++-
> > > >  2 files changed, 17 insertions(+), 5 deletions(-)
> > > > 
> > > >         /*
> > > >          * Following member retains the information to create a UDP header
> > > >          * when the socket is uncorked.
> > > > @@ -68,7 +68,10 @@ struct udp_sock {
> > > >  #define UDPLITE_SEND_CC  0x2           /* set via udplite setsockopt         */
> > > >  #define UDPLITE_RECV_CC  0x4           /* set via udplite setsocktopt        */
> > > >         __u8             pcflag;        /* marks socket as UDP-Lite if > 0    */
> > > > -       __u8             unused[3];
> > > > +       __u8             unused[1];
> > > > +       unsigned int     unexpected_gso;/* GSO types this socket can't accept,
> > > > +                                        * any of SKB_GSO_UDP_L4 or SKB_GSO_FRAGLIST
> > > > +                                        */
> > > 
> > > An extra unsigned int for this seems overkill.
> > 
> > Should be more clear after the next patch.
> > 
> > Using an explicit 'acceptable GSO types' field makes the patch 5/8
> > quite simple.
> > 
> > After this patch the 'udp_sock' struct size remains unchanged and even
> > the number of 'udp_sock' cachelines touched for every packet is
> > unchanged.
> 
> But there is opportunity cost, of course. Next time we need to add
> something to the struct, we will add a new cacheline.
> 
> A 32-bit field for just 2 bits, where 1 already exists does seem like overkill.
> 
> More importantly, I just think it's less obvious code than a pair of fields
> 
>   accepts_udp_l4:1,
>   accepts_udp_fraglist:1,
> 
> Local sockets can only accept the first, as there does not exist an
> interface to pass along the multiple frag sizes that a frag_list based
> approach might have.
> 
> Sockets with encap_rcv != NULL may opt-in to being able to handle either.
> 
> I think explicit code will be more maintainable. 

ok

> At the cost of
> perhaps two branches instead of one, admittedly. But that seems
> premature optimization.

well, if it don't hurt too much your eyes, something along the
following could save udp_sock space and code branches:

    rejects_udp_l4_fraglist:2;

#define SKB_GSO_UDP_L4_SHIFT (NETIF_F_GSO_UDP_L4_BIT - NETIF_F_GSO_SHIFT)
 static inline bool udp_unexpected_gso(struct sock *sk, struct sk_buff *skb)
 {
	BUILD_BUG_ON(1 << SKB_GSO_UDP_L4_SHIFT != SKB_GSO_UDP_L4);
	BUILD_BUG_ON(1 << (SKB_GSO_UDP_L4_SHIFT + 1) != SKB_GSO_FRAGLIST);
 	return skb_is_gso(skb) && skb_shinfo(skb)->gso_type &
		(udp_sk(sk)->rejects_udp_l4_fraglist << SKB_GSO_UDP_L4_SHIFT);
 }

(not sure if /me runs/hides ;)

/P

Re: [PATCH net-next 4/8] udp: never accept GSO_FRAGLIST packets

[Willem de Bruijn]

On Wed, Mar 24, 2021 at 3:00 PM Paolo Abeni <pabeni@redhat.com> wrote:
>
> On Tue, 2021-03-23 at 22:21 -0400, Willem de Bruijn wrote:
> > On Mon, Mar 22, 2021 at 1:12 PM Paolo Abeni <pabeni@redhat.com> wrote:
> > > On Mon, 2021-03-22 at 09:42 -0400, Willem de Bruijn wrote:
> > > > On Sun, Mar 21, 2021 at 1:01 PM Paolo Abeni <pabeni@redhat.com> wrote:
> > > > > Currently the UDP protocol delivers GSO_FRAGLIST packets to
> > > > > the sockets without the expected segmentation.
> > > > >
> > > > > This change addresses the issue introducing and maintaining
> > > > > a per socket bitmask of GSO types requiring segmentation.
> > > > > Enabling GSO removes SKB_GSO_UDP_L4 from such mask, while
> > > > > GSO_FRAGLIST packets are never accepted
> > > > >
> > > > > Note: this also updates the 'unused' field size to really
> > > > > fit the otherwise existing hole. It's size become incorrect
> > > > > after commit bec1f6f69736 ("udp: generate gso with UDP_SEGMENT").
> > > > >
> > > > > Fixes: 9fd1ff5d2ac7 ("udp: Support UDP fraglist GRO/GSO.")
> > > > > Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> > > > > ---
> > > > >  include/linux/udp.h | 10 ++++++----
> > > > >  net/ipv4/udp.c      | 12 +++++++++++-
> > > > >  2 files changed, 17 insertions(+), 5 deletions(-)
> > > > >
> > > > >         /*
> > > > >          * Following member retains the information to create a UDP header
> > > > >          * when the socket is uncorked.
> > > > > @@ -68,7 +68,10 @@ struct udp_sock {
> > > > >  #define UDPLITE_SEND_CC  0x2           /* set via udplite setsockopt         */
> > > > >  #define UDPLITE_RECV_CC  0x4           /* set via udplite setsocktopt        */
> > > > >         __u8             pcflag;        /* marks socket as UDP-Lite if > 0    */
> > > > > -       __u8             unused[3];
> > > > > +       __u8             unused[1];
> > > > > +       unsigned int     unexpected_gso;/* GSO types this socket can't accept,
> > > > > +                                        * any of SKB_GSO_UDP_L4 or SKB_GSO_FRAGLIST
> > > > > +                                        */
> > > >
> > > > An extra unsigned int for this seems overkill.
> > >
> > > Should be more clear after the next patch.
> > >
> > > Using an explicit 'acceptable GSO types' field makes the patch 5/8
> > > quite simple.
> > >
> > > After this patch the 'udp_sock' struct size remains unchanged and even
> > > the number of 'udp_sock' cachelines touched for every packet is
> > > unchanged.
> >
> > But there is opportunity cost, of course. Next time we need to add
> > something to the struct, we will add a new cacheline.
> >
> > A 32-bit field for just 2 bits, where 1 already exists does seem like overkill.
> >
> > More importantly, I just think it's less obvious code than a pair of fields
> >
> >   accepts_udp_l4:1,
> >   accepts_udp_fraglist:1,
> >
> > Local sockets can only accept the first, as there does not exist an
> > interface to pass along the multiple frag sizes that a frag_list based
> > approach might have.
> >
> > Sockets with encap_rcv != NULL may opt-in to being able to handle either.
> >
> > I think explicit code will be more maintainable.
>
> ok
>
> > At the cost of
> > perhaps two branches instead of one, admittedly. But that seems
> > premature optimization.
>
> well, if it don't hurt too much your eyes, something along the
> following could save udp_sock space and code branches:
>
>     rejects_udp_l4_fraglist:2;
>
> #define SKB_GSO_UDP_L4_SHIFT (NETIF_F_GSO_UDP_L4_BIT - NETIF_F_GSO_SHIFT)
>  static inline bool udp_unexpected_gso(struct sock *sk, struct sk_buff *skb)
>  {
>         BUILD_BUG_ON(1 << SKB_GSO_UDP_L4_SHIFT != SKB_GSO_UDP_L4);
>         BUILD_BUG_ON(1 << (SKB_GSO_UDP_L4_SHIFT + 1) != SKB_GSO_FRAGLIST);
>         return skb_is_gso(skb) && skb_shinfo(skb)->gso_type &
>                 (udp_sk(sk)->rejects_udp_l4_fraglist << SKB_GSO_UDP_L4_SHIFT);
>  }
>
> (not sure if /me runs/hides ;)

:)

My opinion is just one, but I do find this a lot less readable and
hence maintainable than

  if (likely(!skb_is_gso(skb)))
     return true;

  if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_L4 && !udp_sk(sk)->accept_udp_l4)
    return false;

  if (skb_shinfo(skb)->gso_type & SKB_GSO_FRAGLIST &&
!udp_sk(sk)->accept_udp_fraglist)
    return false;

  return true;

at no obvious benefit. The tunnel gso code is hard enough to fathom as it is.

> /P
>
>
>

Re: [PATCH net-next 4/8] udp: never accept GSO_FRAGLIST packets

[Paolo Abeni]

On Wed, 2021-03-24 at 18:12 -0400, Willem de Bruijn wrote:
> On Wed, Mar 24, 2021 at 3:00 PM Paolo Abeni <pabeni@redhat.com> wrote:
> > On Tue, 2021-03-23 at 22:21 -0400, Willem de Bruijn wrote:
> > > On Mon, Mar 22, 2021 at 1:12 PM Paolo Abeni <pabeni@redhat.com> wrote:
> > > > On Mon, 2021-03-22 at 09:42 -0400, Willem de Bruijn wrote:
> > > > > On Sun, Mar 21, 2021 at 1:01 PM Paolo Abeni <pabeni@redhat.com> wrote:
> > > > > > Currently the UDP protocol delivers GSO_FRAGLIST packets to
> > > > > > the sockets without the expected segmentation.
> > > > > > 
> > > > > > This change addresses the issue introducing and maintaining
> > > > > > a per socket bitmask of GSO types requiring segmentation.
> > > > > > Enabling GSO removes SKB_GSO_UDP_L4 from such mask, while
> > > > > > GSO_FRAGLIST packets are never accepted
> > > > > > 
> > > > > > Note: this also updates the 'unused' field size to really
> > > > > > fit the otherwise existing hole. It's size become incorrect
> > > > > > after commit bec1f6f69736 ("udp: generate gso with UDP_SEGMENT").
> > > > > > 
> > > > > > Fixes: 9fd1ff5d2ac7 ("udp: Support UDP fraglist GRO/GSO.")
> > > > > > Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> > > > > > ---
> > > > > >  include/linux/udp.h | 10 ++++++----
> > > > > >  net/ipv4/udp.c      | 12 +++++++++++-
> > > > > >  2 files changed, 17 insertions(+), 5 deletions(-)
> > > > > > 
> > > > > >         /*
> > > > > >          * Following member retains the information to create a UDP header
> > > > > >          * when the socket is uncorked.
> > > > > > @@ -68,7 +68,10 @@ struct udp_sock {
> > > > > >  #define UDPLITE_SEND_CC  0x2           /* set via udplite setsockopt         */
> > > > > >  #define UDPLITE_RECV_CC  0x4           /* set via udplite setsocktopt        */
> > > > > >         __u8             pcflag;        /* marks socket as UDP-Lite if > 0    */
> > > > > > -       __u8             unused[3];
> > > > > > +       __u8             unused[1];
> > > > > > +       unsigned int     unexpected_gso;/* GSO types this socket can't accept,
> > > > > > +                                        * any of SKB_GSO_UDP_L4 or SKB_GSO_FRAGLIST
> > > > > > +                                        */
> > > > > 
> > > > > An extra unsigned int for this seems overkill.
> > > > 
> > > > Should be more clear after the next patch.
> > > > 
> > > > Using an explicit 'acceptable GSO types' field makes the patch 5/8
> > > > quite simple.
> > > > 
> > > > After this patch the 'udp_sock' struct size remains unchanged and even
> > > > the number of 'udp_sock' cachelines touched for every packet is
> > > > unchanged.
> > > 
> > > But there is opportunity cost, of course. Next time we need to add
> > > something to the struct, we will add a new cacheline.
> > > 
> > > A 32-bit field for just 2 bits, where 1 already exists does seem like overkill.
> > > 
> > > More importantly, I just think it's less obvious code than a pair of fields
> > > 
> > >   accepts_udp_l4:1,
> > >   accepts_udp_fraglist:1,
> > > 
> > > Local sockets can only accept the first, as there does not exist an
> > > interface to pass along the multiple frag sizes that a frag_list based
> > > approach might have.
> > > 
> > > Sockets with encap_rcv != NULL may opt-in to being able to handle either.
> > > 
> > > I think explicit code will be more maintainable.
> > 
> > ok
> > 
> > > At the cost of
> > > perhaps two branches instead of one, admittedly. But that seems
> > > premature optimization.
> > 
> > well, if it don't hurt too much your eyes, something along the
> > following could save udp_sock space and code branches:
> > 
> >     rejects_udp_l4_fraglist:2;
> > 
> > #define SKB_GSO_UDP_L4_SHIFT (NETIF_F_GSO_UDP_L4_BIT - NETIF_F_GSO_SHIFT)
> >  static inline bool udp_unexpected_gso(struct sock *sk, struct sk_buff *skb)
> >  {
> >         BUILD_BUG_ON(1 << SKB_GSO_UDP_L4_SHIFT != SKB_GSO_UDP_L4);
> >         BUILD_BUG_ON(1 << (SKB_GSO_UDP_L4_SHIFT + 1) != SKB_GSO_FRAGLIST);
> >         return skb_is_gso(skb) && skb_shinfo(skb)->gso_type &
> >                 (udp_sk(sk)->rejects_udp_l4_fraglist << SKB_GSO_UDP_L4_SHIFT);
> >  }
> > 
> > (not sure if /me runs/hides ;)
> 
> :)
> 
> My opinion is just one, but I do find this a lot less readable and
> hence maintainable than
> 
>   if (likely(!skb_is_gso(skb)))
>      return true;
> 
>   if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_L4 && !udp_sk(sk)->accept_udp_l4)
>     return false;
> 
>   if (skb_shinfo(skb)->gso_type & SKB_GSO_FRAGLIST &&
> !udp_sk(sk)->accept_udp_fraglist)
>     return false;
> 
>   return true;
> 
> at no obvious benefit. The tunnel gso code is hard enough to fathom as it is.

ok.

I'm only doubtful about the likely() annotation: systems with UDP
tunnels likely expect receiving a majority of UDP-encaped traffic,
which in turn will likely be GRO (e.g. TCP over UDP-tunnel).

In my next iteration I'll use the above, dropping the annotation.

Cheers,

Paolo

[PATCH net-next 5/8] vxlan: allow L4 GRO passthrou

[Paolo Abeni]

When passing up an UDP GSO packet with L4 aggregation, there is
no need to segment it at the vxlan level. We can propagate the
packet untouched and let it be segmented later, if needed.

Introduce an helper to allow let the UDP socket accepting any
L4 aggregation and use it in the vxlan driver.

Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
 drivers/net/vxlan.c | 1 +
 include/linux/udp.h | 5 +++++
 2 files changed, 6 insertions(+)

diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 7665817f3cb61..39ee1300cdd9d 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -3484,6 +3484,7 @@ static struct socket *vxlan_create_sock(struct net *net, bool ipv6,
 	if (err < 0)
 		return ERR_PTR(err);
 
+	udp_allow_gso(sock->sk);
 	return sock;
 }
 
diff --git a/include/linux/udp.h b/include/linux/udp.h
index 6da342f15f351..0444f2fb6002e 100644
--- a/include/linux/udp.h
+++ b/include/linux/udp.h
@@ -137,6 +137,11 @@ static inline bool udp_unexpected_gso(struct sock *sk, struct sk_buff *skb)
 	return skb_is_gso(skb) && skb_shinfo(skb)->gso_type & udp_sk(sk)->unexpected_gso;
 }
 
+static inline void udp_allow_gso(struct sock *sk)
+{
+	udp_sk(sk)->unexpected_gso = 0;
+}
+
 #define udp_portaddr_for_each_entry(__sk, list) \
 	hlist_for_each_entry(__sk, list, __sk_common.skc_portaddr_node)
 
-- 
2.26.2

[PATCH net-next 6/8] geneve: allow UDP L4 GRO passthrou

[Paolo Abeni]

Similar to the previous commit, let even geneve
passthrou the L4 GRO packets

Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
 drivers/net/geneve.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index 4ac0373326efd..5d7a2b1469f4c 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -461,6 +461,7 @@ static struct socket *geneve_create_sock(struct net *net, bool ipv6,
 	if (err < 0)
 		return ERR_PTR(err);
 
+	udp_allow_gso(sock->sk);
 	return sock;
 }
 
-- 
2.26.2

[PATCH net-next 7/8] bareudp: allow UDP L4 GRO passthrou

[Paolo Abeni]

Similar to the previous commit, let even geneve
passthrou the L4 GRO packets

Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
 drivers/net/bareudp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/bareudp.c b/drivers/net/bareudp.c
index 7511bca9c15ed..edfad93e7b686 100644
--- a/drivers/net/bareudp.c
+++ b/drivers/net/bareudp.c
@@ -218,6 +218,7 @@ static struct socket *bareudp_create_sock(struct net *net, __be16 port)
 	if (err < 0)
 		return ERR_PTR(err);
 
+	udp_allow_gso(sock->sk);
 	return sock;
 }
 
-- 
2.26.2

[PATCH net-next 8/8] selftests: net: add UDP GRO forwarding self-tests

[Paolo Abeni]

create a bunch of virtual topology and verify that
GRO_FRAG_LIST and GRO_FWD aggregate the ingress
packets as expected, and the aggregate packets
are segmented correctly when landing on a socket

Also test L4 aggregation on top of UDP tunnel (vxlan)

Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
 tools/testing/selftests/net/Makefile      |   1 +
 tools/testing/selftests/net/udpgro_fwd.sh | 251 ++++++++++++++++++++++
 2 files changed, 252 insertions(+)
 create mode 100755 tools/testing/selftests/net/udpgro_fwd.sh

diff --git a/tools/testing/selftests/net/Makefile b/tools/testing/selftests/net/Makefile
index 25f198bec0b25..2d71b283dde36 100644
--- a/tools/testing/selftests/net/Makefile
+++ b/tools/testing/selftests/net/Makefile
@@ -23,6 +23,7 @@ TEST_PROGS += drop_monitor_tests.sh
 TEST_PROGS += vrf_route_leaking.sh
 TEST_PROGS += bareudp.sh
 TEST_PROGS += unicast_extensions.sh
+TEST_PROGS += udpgro_fwd.sh
 TEST_PROGS_EXTENDED := in_netns.sh
 TEST_GEN_FILES =  socket nettest
 TEST_GEN_FILES += psock_fanout psock_tpacket msg_zerocopy reuseport_addr_any
diff --git a/tools/testing/selftests/net/udpgro_fwd.sh b/tools/testing/selftests/net/udpgro_fwd.sh
new file mode 100755
index 0000000000000..ac7ac56a27524
--- /dev/null
+++ b/tools/testing/selftests/net/udpgro_fwd.sh
@@ -0,0 +1,251 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+
+readonly BASE="ns-$(mktemp -u XXXXXX)"
+readonly SRC=2
+readonly DST=1
+readonly DST_NAT=100
+readonly NS_SRC=$BASE$SRC
+readonly NS_DST=$BASE$DST
+
+# "baremetal" network used for raw UDP traffic
+readonly BM_NET_V4=192.168.1.
+readonly BM_NET_V6=2001:db8::
+
+# "overlay" network used for UDP over UDP tunnel traffic
+readonly OL_NET_V4=172.16.1.
+readonly OL_NET_V6=2002:db8::
+readonly NPROCS=`nproc`
+
+cleanup() {
+	local ns
+	local -r jobs="$(jobs -p)"
+	[ -n "${jobs}" ] && kill -1 ${jobs} 2>/dev/null
+
+	for ns in $NS_SRC $NS_DST; do
+		ip netns del $ns 2>/dev/null
+	done
+}
+
+trap cleanup EXIT
+
+create_ns() {
+	local net
+	local ns
+
+	for ns in $NS_SRC $NS_DST; do
+		ip netns add $ns
+		ip -n $ns link set dev lo up
+	done
+
+	ip link add name veth$SRC type veth peer name veth$DST
+
+	for ns in $SRC $DST; do
+		ip link set dev veth$ns netns $BASE$ns
+		ip -n $BASE$ns link set dev veth$ns up
+		ip -n $BASE$ns addr add dev veth$ns $BM_NET_V4$ns/24
+		ip -n $BASE$ns addr add dev veth$ns $BM_NET_V6$ns/64 nodad
+	done
+	ip -n $NS_DST link set veth$DST xdp object ../bpf/xdp_dummy.o section xdp_dummy 2>/dev/null
+}
+
+create_vxlan_endpoint() {
+	local -r netns=$1
+	local -r bm_dev=$2
+	local -r bm_rem_addr=$3
+	local -r vxlan_dev=$4
+	local -r vxlan_id=$5
+	local -r vxlan_port=4789
+
+	ip -n $netns link set dev $bm_dev up
+	ip -n $netns link add dev $vxlan_dev type vxlan id $vxlan_id \
+				dstport $vxlan_port remote $bm_rem_addr
+	ip -n $netns link set dev $vxlan_dev up
+}
+
+create_vxlan_pair() {
+	local ns
+
+	create_ns
+
+	for ns in $SRC $DST; do
+		# note that 3 - $SRC == $DST and 3 - $DST == $SRC
+		create_vxlan_endpoint $BASE$ns veth$ns $BM_NET_V4$((3 - $ns)) vxlan$ns 4
+		ip -n $BASE$ns addr add dev vxlan$ns $OL_NET_V4$ns/24
+	done
+	for ns in $SRC $DST; do
+		create_vxlan_endpoint $BASE$ns veth$ns $BM_NET_V6$((3 - $ns)) vxlan6$ns 6
+		ip -n $BASE$ns addr add dev vxlan6$ns $OL_NET_V6$ns/24 nodad
+	done
+}
+
+is_ipv6() {
+	if [[ $1 =~ .*:.* ]]; then
+		return 0
+	fi
+	return 1
+}
+
+run_test() {
+	local -r msg=$1
+	local -r dst=$2
+	local -r pkts=$3
+	local -r vxpkts=$4
+	local bind=$5
+	local rx_args=""
+	local rx_family="-4"
+	local family=-4
+	local filter=IpInReceives
+	local ipt=iptables
+
+	printf "%-40s" "$msg"
+
+	if is_ipv6 $dst; then
+		# rx program does not support '-6' and implies ipv6 usage by default
+		rx_family=""
+		family=-6
+		filter=Ip6InReceives
+		ipt=ip6tables
+	fi
+
+	rx_args="$rx_family"
+	[ -n "$bind" ] && rx_args="$rx_args -b $bind"
+
+	# send a single GSO packet, segmented in 10 UDP frames.
+	# Always expect 10 UDP frames on RX side as rx socket does
+	# not enable GRO
+	ip netns exec $NS_DST $ipt -A INPUT -p udp --dport 4789
+	ip netns exec $NS_DST $ipt -A INPUT -p udp --dport 8000
+	ip netns exec $NS_DST ./udpgso_bench_rx -C 1000 -R 10 -n 10 -l 1300 $rx_args &
+	local spid=$!
+	sleep 0.1
+	ip netns exec $NS_SRC ./udpgso_bench_tx $family -M 1 -s 13000 -S 1300 -D $dst
+	local retc=$?
+	wait $spid
+	local rets=$?
+	if [ ${rets} -ne 0 ] || [ ${retc} -ne 0 ]; then
+		echo " fail client exit code $retc, server $rets"
+		ret=1
+		return
+	fi
+
+	local rcv=`ip netns exec $NS_DST $ipt"-save" -c | grep 'dport 8000' | \
+							  sed -e 's/\[//' -e 's/:.*//'`
+	if [ $rcv != $pkts ]; then
+		echo " fail - received $rvs packets, expected $pkts"
+		ret=1
+		return
+	fi
+
+	local vxrcv=`ip netns exec $NS_DST $ipt"-save" -c | grep 'dport 4789' | \
+							    sed -e 's/\[//' -e 's/:.*//'`
+
+	# upper net can generate a little noise, allow some tolerance
+	if [ $vxrcv -lt $vxpkts -o $vxrcv -gt $((vxpkts + 3)) ]; then
+		echo " fail - received $vxrcv vxlan packets, expected $vxpkts"
+		ret=1
+		return
+	fi
+	echo " ok"
+}
+
+run_bench() {
+	local -r msg=$1
+	local -r dst=$2
+	local family=-4
+
+	printf "%-40s" "$msg"
+	if [ $NPROCS -lt 2 ]; then
+		echo " skip - needed 2 CPUs found $NPROCS"
+		return
+	fi
+
+	is_ipv6 $dst && family=-6
+
+	# bind the sender and the receiver to different CPUs to try
+	# get reproducible results
+	ip netns exec $NS_DST bash -c "echo 2 > /sys/class/net/veth$DST/queues/rx-0/rps_cpus"
+	ip netns exec $NS_DST taskset 0x2 ./udpgso_bench_rx -C 1000 -R 10  &
+	local spid=$!
+	sleep 0.1
+	ip netns exec $NS_SRC taskset 0x1 ./udpgso_bench_tx $family -l 3 -S 1300 -D $dst
+	local retc=$?
+	wait $spid
+	local rets=$?
+	if [ ${rets} -ne 0 ] || [ ${retc} -ne 0 ]; then
+		echo " fail client exit code $retc, server $rets"
+		ret=1
+		return
+	fi
+}
+
+for family in 4 6; do
+	BM_NET=$BM_NET_V4
+	OL_NET=$OL_NET_V4
+	IPT=iptables
+	SUFFIX=24
+	VXDEV=vxlan
+
+	if [ $family = 6 ]; then
+		BM_NET=$BM_NET_V6
+		OL_NET=$OL_NET_V6
+		SUFFIX="64 nodad"
+		VXDEV=vxlan6
+		IPT=ip6tables
+	fi
+
+	echo "IPv$family"
+
+	create_ns
+	run_test "No GRO" $BM_NET$DST 10 0
+	cleanup
+
+	create_ns
+	ip netns exec $NS_DST ethtool -K veth$DST rx-gro-list on
+	run_test "GRO frag list" $BM_NET$DST 1 0
+	cleanup
+
+	# UDP GRO fwd skips aggregation when find an udp socket with the GRO option
+	# if there is an UDP tunnel in the running system, such lookup happen
+	# take place.
+	# use NAT to circumvent GRO FWD check
+	create_ns
+	ip -n $NS_DST addr add dev veth$DST $BM_NET$DST_NAT/$SUFFIX
+	ip netns exec $NS_DST ethtool -K veth$DST rx-udp-gro-forwarding on
+	ip netns exec $NS_DST $IPT -t nat -I PREROUTING -d $BM_NET$DST_NAT \
+					-j DNAT --to-destination $BM_NET$DST
+	run_test "GRO fwd" $BM_NET$DST_NAT 1 0 $BM_NET$DST
+	cleanup
+
+	create_ns
+	run_bench "UDP fwd perf" $BM_NET$DST
+	ip netns exec $NS_DST ethtool -K veth$DST rx-udp-gro-forwarding on
+	run_bench "UDP GRO fwd perf" $BM_NET$DST
+	cleanup
+
+	create_vxlan_pair
+	ip netns exec $NS_DST ethtool -K veth$DST rx-gro-list on
+	run_test "GRO frag list over UDP tunnel" $OL_NET$DST 1 1
+	cleanup
+
+	# use NAT to circumvent GRO FWD check
+	create_vxlan_pair
+	ip -n $NS_DST addr add dev $VXDEV$DST $OL_NET$DST_NAT/$SUFFIX
+	ip netns exec $NS_DST ethtool -K veth$DST rx-udp-gro-forwarding on
+	ip netns exec $NS_DST $IPT -t nat -I PREROUTING -d $OL_NET$DST_NAT \
+					-j DNAT --to-destination $OL_NET$DST
+
+	# load arp cache before running the test to reduce the amount of
+	# stray traffic on top of the UDP tunnel
+	ip netns exec $NS_SRC ping -q -c 1 $OL_NET$DST_NAT >/dev/null
+	run_test "GRO fwd over UDP tunnel" $OL_NET$DST_NAT 1 1 $OL_NET$DST
+	cleanup
+
+	create_vxlan_pair
+	run_bench "UDP tunnel fwd perf" $OL_NET$DST
+	ip netns exec $NS_DST ethtool -K veth$DST rx-udp-gro-forwarding on
+	run_bench "UDP tunnel GRO fwd perf" $OL_NET$DST
+	cleanup
+done
+
+exit $ret
-- 
2.26.2

Re: [PATCH net-next 8/8] selftests: net: add UDP GRO forwarding self-tests

[Willem de Bruijn]

On Sun, Mar 21, 2021 at 1:02 PM Paolo Abeni <pabeni@redhat.com> wrote:
>
> create a bunch of virtual topology and verify that
> GRO_FRAG_LIST and GRO_FWD aggregate the ingress

what are these constants? Aliases for SKB_GSO_FRAGLIST and ?

> packets as expected, and the aggregate packets
> are segmented correctly when landing on a socket
>
> Also test L4 aggregation on top of UDP tunnel (vxlan)
>
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>

Nice comprehensive test, thanks!

> ---
>  tools/testing/selftests/net/Makefile      |   1 +
>  tools/testing/selftests/net/udpgro_fwd.sh | 251 ++++++++++++++++++++++
>  2 files changed, 252 insertions(+)
>  create mode 100755 tools/testing/selftests/net/udpgro_fwd.sh
>
> diff --git a/tools/testing/selftests/net/Makefile b/tools/testing/selftests/net/Makefile
> index 25f198bec0b25..2d71b283dde36 100644
> --- a/tools/testing/selftests/net/Makefile
> +++ b/tools/testing/selftests/net/Makefile
> @@ -23,6 +23,7 @@ TEST_PROGS += drop_monitor_tests.sh
>  TEST_PROGS += vrf_route_leaking.sh
>  TEST_PROGS += bareudp.sh
>  TEST_PROGS += unicast_extensions.sh
> +TEST_PROGS += udpgro_fwd.sh
>  TEST_PROGS_EXTENDED := in_netns.sh
>  TEST_GEN_FILES =  socket nettest
>  TEST_GEN_FILES += psock_fanout psock_tpacket msg_zerocopy reuseport_addr_any
> diff --git a/tools/testing/selftests/net/udpgro_fwd.sh b/tools/testing/selftests/net/udpgro_fwd.sh
> new file mode 100755
> index 0000000000000..ac7ac56a27524
> --- /dev/null
> +++ b/tools/testing/selftests/net/udpgro_fwd.sh
> @@ -0,0 +1,251 @@
> +#!/bin/sh
> +# SPDX-License-Identifier: GPL-2.0
> +
> +readonly BASE="ns-$(mktemp -u XXXXXX)"
> +readonly SRC=2
> +readonly DST=1
> +readonly DST_NAT=100
> +readonly NS_SRC=$BASE$SRC
> +readonly NS_DST=$BASE$DST
> +
> +# "baremetal" network used for raw UDP traffic
> +readonly BM_NET_V4=192.168.1.
> +readonly BM_NET_V6=2001:db8::
> +
> +# "overlay" network used for UDP over UDP tunnel traffic
> +readonly OL_NET_V4=172.16.1.
> +readonly OL_NET_V6=2002:db8::

is it okay to use a prod64 prefix for this? should this be another
subnet of 2001:db8:: instead? of fd..

Re: [PATCH net-next 8/8] selftests: net: add UDP GRO forwarding self-tests

[Paolo Abeni]

On Mon, 2021-03-22 at 09:44 -0400, Willem de Bruijn wrote:
> On Sun, Mar 21, 2021 at 1:02 PM Paolo Abeni <pabeni@redhat.com> wrote:
> > create a bunch of virtual topology and verify that
> > GRO_FRAG_LIST and GRO_FWD aggregate the ingress
> 
> what are these constants? Aliases for SKB_GSO_FRAGLIST and ?

Well, I was inaccurate in many ways :(

I was speaking about device features, so it's really:

NETIF_F_GSO_FRAGLIST and NETIF_F_GRO_UDP_FWD

I really would love a commit message "compiler" to clarify this sort of
thing before submission;)

Thanks,

Paolo

Re: [PATCH net-next 8/8] selftests: net: add UDP GRO forwarding self-tests

[Paolo Abeni]

Hello,

On Mon, 2021-03-22 at 09:44 -0400, Willem de Bruijn wrote:
> > diff --git a/tools/testing/selftests/net/udpgro_fwd.sh b/tools/testing/selftests/net/udpgro_fwd.sh
> > new file mode 100755
> > index 0000000000000..ac7ac56a27524
> > --- /dev/null
> > +++ b/tools/testing/selftests/net/udpgro_fwd.sh
> > @@ -0,0 +1,251 @@
> > +#!/bin/sh
> > +# SPDX-License-Identifier: GPL-2.0
> > +
> > +readonly BASE="ns-$(mktemp -u XXXXXX)"
> > +readonly SRC=2
> > +readonly DST=1
> > +readonly DST_NAT=100
> > +readonly NS_SRC=$BASE$SRC
> > +readonly NS_DST=$BASE$DST
> > +
> > +# "baremetal" network used for raw UDP traffic
> > +readonly BM_NET_V4=192.168.1.
> > +readonly BM_NET_V6=2001:db8::
> > +
> > +# "overlay" network used for UDP over UDP tunnel traffic
> > +readonly OL_NET_V4=172.16.1.
> > +readonly OL_NET_V6=2002:db8::
> 
> is it okay to use a prod64 prefix for this? should this be another
> subnet of 2001:db8:: instead? of fd..

It looks like this comment slipped out of my sight... yep, I'll use
2001:db8:1:: for the overlay network in the next iteration.

Thanks!

Paolo

👍

[Sophia Wang]

HI.Linux-Media:
                  To cost down your investment and products’ cost by professional engineer
What I said costing down, it doesn’t mean to make lower quality. We just provided quality molds and products and do more analysis on the products to avoid any mistake.
 Our capacity as below:
1.	Coordinate design products
2.	Prototype making
3.	We industrialize your design
4.	Both metal and plastic mold and molding making; middle and small size mold
5.	Products assembly and testing.
Our customers like Barnem and ASA plastic from Italy etc. Every year I visited them once to discuss future cooperation.
Our strong point is to make small to middle quantity customized products 
Welcome to contact us.
http://tracking.mfg1.brcemail.com/tracking/click?d=vRuZXJ7QQCu6v6TXpPeO586xAczk55KEK_k90kz6BJVoYYnmC6Xw1vCweEVL4XJ6uThitmO1w-f4GMUyZfv7tMgmlbb_5jzJTrwFOXtiNxM5DwQJ3FW2n1JvKIfdTYZIsMjKsFy3NEYWpFecsyw-c4KOjt4MmA3B_pSWjY0xBAIz5Fc_tUtU9DauH_KTnf1ccqm28or5_ybx9_BMd031TbbMiMB2qMIGL1tswdLj0D5Wsu6qDJUMEn5T1L6BPL9ZV-3ufpQOqc4vZCiZx0bIfh41
http://tracking.mfg1.brcemail.com/tracking/click?d=vRuZXJ7QQCu6v6TXpPeO586xAczk55KEK_k90kz6BJVoYYnmC6Xw1vCweEVL4XJ6uThitmO1w-f4GMUyZfv7tMgmlbb_5jzJTrwFOXtiNxO_-jp37N2rrdBUtwe77iKDG76BXcWJncHI54LzdIfKpDEi0USp6xKv0XmK7VDloRKMRk8XcLpCMRO7Aqb783Ibqv9IxJ31Srn8_EVfkWVYrbniZ8uAqawfuAMdPj4i0angoP1nwCUA6ULPDw_cU_ATR7R1MMH58GpS_BXr7eOiQ7I1
Sophia

<a href="http://tracking.mfg1.brcemail.com/tracking/unsubscribe?d=SUfZSQjh8bC1ntzWDzUolB0Hd_XeqFNk1t7JHeP9Zg0fNpsZX3dyErcpQw3yxuNwlmnAAnptrVQ-wye4YvPlpGDxESzAtLl7hIvB3VXpStKRsTQtjxiWo51gATBeQmX492k0lxKtYpiu1X1NVV5eFDdUfhuGkmhoypiVs6QOEqAfYVZLZ0rN92odnTaLVr0u3XKBR7y7OqXemebV6rBCNX9LW3xwA2oJy2NGXMIpowijTEaHNdk69BRj9mPdB4MmxSpLBuvrx_Wg80mBNgu3J4hZHW0HBZyHuessCMUUOniq0gZMaXOtJbedL4IC0ONOUdrGnFsRA8omcgyt8BVpWRjr4hsGeVRhXxJjQWmoh3OHOc6UlaEvp04ZBeJh9Q_djamjRE7eM0DkD1G-Yc7j5ovDU1DPuejm2-xHURooxzsN_tlRs0Fw-vezkBB2f5YAj7RFLi6Pf8PJSFC11x4WkfoZpiat0wgzyAQG_Bi3lWVo0">Unsubscribe</a>

[]

[Joachim Wiberg]

commit 72282e537222988d1dfa787e79554d136fd1fc56
Author: Joachim Wiberg <troglobit@gmail.com>
Date:   Wed Nov 18 16:38:13 2015 +0100

    mtd: mtd2block: add support for an optional custom MTD label
    
    This patch adds support for an optional MTD label for mtd2block emulated
    MTD devices.  Useful when, e.g. testing device images using Qemu.  The
    following /etc/fstab line in can then be used to mount a file system
    regardless of the actual MTD partition number:
    
        mtd:Config  /mnt    jffs2   noatime,nodiratime      0    0
    
    Kernel command line syntax:
    
        block2mtd.block2mtd=/dev/sda,,Config
    
    The ',,' is the optional erase_size, which like before this patch,
    defaults to PAGE_SIZE if left out.
    
    Signed-off-by: Joachim Wiberg <troglobit@gmail.com>

diff --git a/drivers/mtd/devices/block2mtd.c b/drivers/mtd/devices/block2mtd.c
index c9e424993e37..f9c14146bf9c 100644
--- a/drivers/mtd/devices/block2mtd.c
+++ b/drivers/mtd/devices/block2mtd.c
@@ -214,7 +214,7 @@ static void block2mtd_free_device(struct block2mtd_dev *dev)
 
 
 static struct block2mtd_dev *add_device(char *devname, int erase_size,
-		int timeout)
+		char *label, int timeout)
 {
 #ifndef MODULE
 	int i;
@@ -278,7 +278,10 @@ static struct block2mtd_dev *add_device(char *devname, int erase_size,
 
 	/* Setup the MTD structure */
 	/* make the name contain the block device in */
-	name = kasprintf(GFP_KERNEL, "block2mtd: %s", devname);
+	if (!label)
+		name = kasprintf(GFP_KERNEL, "block2mtd: %s", devname);
+	else
+		name = kstrdup(label, GFP_KERNEL);
 	if (!name)
 		goto err_destroy_mutex;
 
@@ -379,8 +382,8 @@ static int block2mtd_setup2(const char *val)
 	/* 80 for device, 12 for erase size, 80 for name, 8 for timeout */
 	char buf[80 + 12 + 80 + 8];
 	char *str = buf;
-	char *token[2];
-	char *name;
+	char *token[3];
+	char *name, *label = NULL;
 	size_t erase_size = PAGE_SIZE;
 	unsigned long timeout = MTD_DEFAULT_TIMEOUT;
 	int i, ret;
@@ -393,7 +396,7 @@ static int block2mtd_setup2(const char *val)
 	strcpy(str, val);
 	kill_final_newline(str);
 
-	for (i = 0; i < 2; i++)
+	for (i = 0; i < 3; i++)
 		token[i] = strsep(&str, ",");
 
 	if (str) {
@@ -412,7 +415,7 @@ static int block2mtd_setup2(const char *val)
 		return 0;
 	}
 
-	if (token[1]) {
+	if (token[1] && strlen(token[1])) {
 		ret = parse_num(&erase_size, token[1]);
 		if (ret) {
 			pr_err("illegal erase size\n");
@@ -420,7 +423,12 @@ static int block2mtd_setup2(const char *val)
 		}
 	}
 
-	add_device(name, erase_size, timeout);
+	if (token[2]) {
+		label = token[2];
+		pr_info("Using custom MTD label '%s' for dev %s\n", label, name);
+	}
+
+	add_device(name, erase_size, label, timeout);
 
 	return 0;
 }
@@ -454,7 +462,7 @@ static int block2mtd_setup(const char *val, const struct kernel_param *kp)
 
 
 module_param_call(block2mtd, block2mtd_setup, NULL, NULL, 0200);
-MODULE_PARM_DESC(block2mtd, "Device to use. \"block2mtd=<dev>[,<erasesize>]\"");
+MODULE_PARM_DESC(block2mtd, "Device to use. \"block2mtd=<dev>[,[<erasesize>][,<name>]]\"");
 
 static int __init block2mtd_init(void)
 {

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: []

[Joachim Wiberg]

On Thu, Feb 04, 2021 at 14:17, Joachim Wiberg <troglobit@gmail.com> wrote:
>     mtd: mtd2block: add support for an optional custom MTD label

Ugh, sorry about the noise.  Managed to press send instead of abort.
An actual up-to-date patch for this is incoming though, as RFC.

Regards
 /Joachim

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

[PATCH v3 2/5] w1_therm: adding sysfs entry to check device power

[Akira Shimahara]

Patch for enhacement of w1_therm module.
Adding ext_power sysfs entry (RO). Return the power status of the device:
 - 0: device parasite powered
 - 1: device externally powered
 - xx: xx is kernel error

Creating Documentation/ABI/testing/sysfs-driver-w1_therm for the old 
driver sysfs and this new entry.

Signed-off-by: Akira Shimahara <akira215corp@gmail.com>
---
 .../ABI/testing/sysfs-driver-w1_therm         | 29 ++++++
 drivers/w1/slaves/w1_therm.c                  | 93 ++++++++++++++++++-
 drivers/w1/slaves/w1_therm.h                  | 44 ++++++++-
 3 files changed, 163 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-driver-w1_therm

diff --git a/Documentation/ABI/testing/sysfs-driver-w1_therm b/Documentation/ABI/testing/sysfs-driver-w1_therm
new file mode 100644
index 0000000..9aaf625
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-w1_therm
@@ -0,0 +1,29 @@
+What:		/sys/bus/w1/devices/.../ext_power
+Date:		Apr 2020
+Contact:	Akira Shimahara <akira215corp@gmail.com>
+Description:
+		(RO) return the power status by asking the device
+			* `0`: device parasite powered
+			* `1`: device externally powered
+			* `-xx`: xx is kernel error when reading power status
+Users:		any user space application which wants to communicate with
+		w1_term device
+
+
+What:		/sys/bus/w1/devices/.../w1_slave
+Date:		Apr 2020
+Contact:	Akira Shimahara <akira215corp@gmail.com>
+Description:
+		(RW) return the temperature in 1/1000 degC.
+		*read*: return 2 lines with the hexa output data sent on the
+		bus, return the CRC check and temperature in 1/1000 degC
+		*write* :
+			* `0` : save the 2 or 3 bytes to the device EEPROM
+			(i.e. TH, TL and config register)
+			* `9..12` : set the device resolution in RAM
+			(if supported)
+			* Anything else: do nothing
+		refer to Documentation/w1/slaves/w1_therm.rst for detailed
+		information.
+Users:		any user space application which wants to communicate with
+		w1_term device
\ No newline at end of file
diff --git a/drivers/w1/slaves/w1_therm.c b/drivers/w1/slaves/w1_therm.c
index 6245950..a530853 100644
--- a/drivers/w1/slaves/w1_therm.c
+++ b/drivers/w1/slaves/w1_therm.c
@@ -39,12 +39,14 @@ module_param_named(strong_pullup, w1_strong_pullup, int, 0);
 
 static struct attribute *w1_therm_attrs[] = {
 	&dev_attr_w1_slave.attr,
+	&dev_attr_ext_power.attr,
 	NULL,
 };
 
 static struct attribute *w1_ds28ea00_attrs[] = {
 	&dev_attr_w1_slave.attr,
 	&dev_attr_w1_seq.attr,
+	&dev_attr_ext_power.attr,
 	NULL,
 };
 
@@ -294,6 +296,26 @@ static inline int w1_DS18S20_convert_temp(u8 rom[9])
 	return t;
 }
 
+/*------------------------ Helpers Functions----------------------------*/
+
+static inline bool bus_mutex_lock(struct mutex *lock)
+{
+	int max_trying = W1_THERM_MAX_TRY;
+	/* try to acquire the mutex, if not, sleep retry_delay before retry) */
+	while (mutex_lock_interruptible(lock) != 0 && max_trying > 0) {
+		unsigned long sleep_rem;
+
+		sleep_rem = msleep_interruptible(W1_THERM_RETRY_DELAY);
+		if (!sleep_rem)
+			max_trying--;
+	}
+
+	if (!max_trying)
+		return false;	/* Didn't acquire the bus mutex */
+
+	return true;
+}
+
 /*-------------------------Interface Functions------------------------------*/
 static int w1_therm_add_slave(struct w1_slave *sl)
 {
@@ -302,6 +324,16 @@ static int w1_therm_add_slave(struct w1_slave *sl)
 	if (!sl->family_data)
 		return -ENOMEM;
 	atomic_set(THERM_REFCNT(sl->family_data), 1);
+
+	/* Getting the power mode of the device {external, parasite}*/
+	SLAVE_POWERMODE(sl) = read_powermode(sl);
+
+	if (SLAVE_POWERMODE(sl) < 0) {
+		/* no error returned as device has been added */
+		dev_warn(&sl->dev,
+			"%s: Device has been added, but power_mode may be corrupted. err=%d\n",
+			 __func__, SLAVE_POWERMODE(sl));
+	}
 	return 0;
 }
 
@@ -512,6 +544,43 @@ error:
 	return ret;
 }
 
+static int read_powermode(struct w1_slave *sl)
+{
+	struct w1_master *dev_master = sl->master;
+	int max_trying = W1_THERM_MAX_TRY;
+	int  ret = -ENODEV;
+
+	if (!sl->family_data)
+		goto error;
+
+	/* prevent the slave from going away in sleep */
+	atomic_inc(THERM_REFCNT(sl->family_data));
+
+	if (!bus_mutex_lock(&dev_master->bus_mutex)) {
+		ret = -EAGAIN;	// Didn't acquire the mutex
+		goto dec_refcnt;
+	}
+
+	while ((max_trying--) && (ret < 0)) {
+		/* safe version to select slave */
+		if (!reset_select_slave(sl)) {
+			w1_write_8(dev_master, W1_READ_PSUPPLY);
+			/* Read only one bit,
+			 * 1 is externally powered,
+			 * 0 is parasite powered
+			 */
+			ret = w1_touch_bit(dev_master, 1);
+			/* ret should be either 1 either 0 */
+		}
+	}
+	mutex_unlock(&dev_master->bus_mutex);
+
+dec_refcnt:
+	atomic_dec(THERM_REFCNT(sl->family_data));
+error:
+	return ret;
+}
+
 /*------------------------Interface sysfs--------------------------*/
 
 static ssize_t w1_slave_show(struct device *device,
@@ -565,13 +634,35 @@ static ssize_t w1_slave_store(struct device *device,
 				ret = w1_therm_families[i].eeprom(device);
 			else
 				ret = w1_therm_families[i].precision(device,
-								val);
+									val);
 			break;
 		}
 	}
 	return ret ? : size;
 }
 
+static ssize_t ext_power_show(struct device *device,
+	struct device_attribute *attr, char *buf)
+{
+	struct w1_slave *sl = dev_to_w1_slave(device);
+
+	if (!sl->family_data) {
+		dev_info(device,
+			"%s: Device not supported by the driver\n", __func__);
+		return 0;  /* No device family */
+	}
+
+	/* Getting the power mode of the device {external, parasite}*/
+	SLAVE_POWERMODE(sl) = read_powermode(sl);
+
+	if (SLAVE_POWERMODE(sl) < 0) {
+		dev_dbg(device,
+			"%s: Power_mode may be corrupted. err=%d\n",
+			__func__, SLAVE_POWERMODE(sl));
+	}
+	return sprintf(buf, "%d\n", SLAVE_POWERMODE(sl));
+}
+
 #if IS_REACHABLE(CONFIG_HWMON)
 static int w1_read_temp(struct device *device, u32 attr, int channel,
 			long *val)
diff --git a/drivers/w1/slaves/w1_therm.h b/drivers/w1/slaves/w1_therm.h
index b73af0b..2f975a4 100644
--- a/drivers/w1/slaves/w1_therm.h
+++ b/drivers/w1/slaves/w1_therm.h
@@ -25,6 +25,12 @@
 #include <linux/mutex.h>
 #include <linux/w1.h>
 
+/*----------------------------------Defines---------------------------------*/
+/* Nb of try for an operation */
+#define W1_THERM_MAX_TRY		5
+
+/* ms delay to retry bus mutex */
+#define W1_THERM_RETRY_DELAY		20
 /*----------------------------------Structs---------------------------------*/
 
 /**
@@ -47,10 +53,15 @@ struct w1_therm_family_converter {
  * struct w1_therm_family_data
  * @param rom data
  * @param refcnt ref count
+ * @param external_powered
+ *		1 device powered externally,
+ *		0 device parasite powered,
+ *		-x error or undefined
  */
 struct w1_therm_family_data {
 	uint8_t rom[9];
 	atomic_t refcnt;
+	int external_powered;
 };
 
 /**
@@ -80,11 +91,24 @@ static inline int w1_DS18B20_convert_temp(u8 rom[9]);
 static inline int w1_DS18S20_convert_temp(u8 rom[9]);
 
 /*-------------------------------Macros--------------------------------------*/
+/* return the power mode of the sl slave : 1-ext, 0-parasite, <0 unknown
+ * always test family data existence before
+ */
+#define SLAVE_POWERMODE(sl) \
+	(((struct w1_therm_family_data *)(sl->family_data))->external_powered)
 
 /* return the address of the refcnt in the family data */
 #define THERM_REFCNT(family_data) \
 	(&((struct w1_therm_family_data *)family_data)->refcnt)
 
+/*-------------------------- Helpers Functions------------------------------*/
+
+/** bus_mutex_lock() get the mutex & retry
+ *  @param lock w1 bus mutex to get
+ *  @return value true is mutex is acquired and lock, false otherwise
+ */
+static inline bool bus_mutex_lock(struct mutex *lock);
+
 /*---------------------------Hardware Functions-----------------------------*/
 
 /**
@@ -107,7 +131,14 @@ static int reset_select_slave(struct w1_slave *sl);
  */
 static ssize_t read_therm(struct device *device,
 			struct w1_slave *sl, struct therm_info *info);
-
+/** read_powermode()
+ * @brief ask the device to get its power mode {external, parasite}
+ * @param sl slave to be interrogated
+ * @return	0 parasite powered device
+ *			1 externally powered device
+ *			<0 kernel error code
+ */
+static int read_powermode(struct w1_slave *sl);
 /*----------------------------Interface sysfs-------------------------------*/
 
 /** @brief A callback function to output the temperature Old way
@@ -127,11 +158,20 @@ static ssize_t w1_slave_store(struct device *device,
 
 static ssize_t w1_seq_show(struct device *device,
 	struct device_attribute *attr, char *buf);
-
+/** @brief A callback function to output the power mode of the device
+ *	Once done, it is stored in the sl->family_data to avoid doing the test
+ *	during data read
+ *  @return	0 : device parasite powered
+ *			1 : device externally powered
+ *			-xx : xx is kernel error code
+ */
+static ssize_t ext_power_show(struct device *device,
+	struct device_attribute *attr, char *buf);
 /*-----------------------------Attributes declarations----------------------*/
 
 static DEVICE_ATTR_RW(w1_slave);
 static DEVICE_ATTR_RO(w1_seq);
+static DEVICE_ATTR_RO(ext_power);
 
 /*--------------------------Interface Functions-----------------------------*/
 
-- 
2.25.4

Re: [PATCH v3 2/5] w1_therm: adding sysfs entry to check device power

[Greg KH]

On Wed, Apr 29, 2020 at 03:32:04PM +0200, Akira Shimahara wrote:
> Patch for enhacement of w1_therm module.
> Adding ext_power sysfs entry (RO). Return the power status of the device:
>  - 0: device parasite powered
>  - 1: device externally powered
>  - xx: xx is kernel error
> 
> Creating Documentation/ABI/testing/sysfs-driver-w1_therm for the old 
> driver sysfs and this new entry.
> 
> Signed-off-by: Akira Shimahara <akira215corp@gmail.com>
> ---
>  .../ABI/testing/sysfs-driver-w1_therm         | 29 ++++++
>  drivers/w1/slaves/w1_therm.c                  | 93 ++++++++++++++++++-
>  drivers/w1/slaves/w1_therm.h                  | 44 ++++++++-
>  3 files changed, 163 insertions(+), 3 deletions(-)
>  create mode 100644 Documentation/ABI/testing/sysfs-driver-w1_therm
> 
> diff --git a/Documentation/ABI/testing/sysfs-driver-w1_therm b/Documentation/ABI/testing/sysfs-driver-w1_therm
> new file mode 100644
> index 0000000..9aaf625
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-driver-w1_therm
> @@ -0,0 +1,29 @@
> +What:		/sys/bus/w1/devices/.../ext_power
> +Date:		Apr 2020
> +Contact:	Akira Shimahara <akira215corp@gmail.com>
> +Description:
> +		(RO) return the power status by asking the device
> +			* `0`: device parasite powered
> +			* `1`: device externally powered
> +			* `-xx`: xx is kernel error when reading power status
> +Users:		any user space application which wants to communicate with
> +		w1_term device
> +
> +
> +What:		/sys/bus/w1/devices/.../w1_slave
> +Date:		Apr 2020
> +Contact:	Akira Shimahara <akira215corp@gmail.com>
> +Description:
> +		(RW) return the temperature in 1/1000 degC.
> +		*read*: return 2 lines with the hexa output data sent on the
> +		bus, return the CRC check and temperature in 1/1000 degC

the w1_slave file returns a temperature???

And sysfs is 1 value-per-file, not multiple lines.

And as this is a temperature, what's wrong with the iio interface that
handles temperature already?  Don't go making up new userspace apis when
we already have good ones today :)

> +		*write* :
> +			* `0` : save the 2 or 3 bytes to the device EEPROM
> +			(i.e. TH, TL and config register)
> +			* `9..12` : set the device resolution in RAM
> +			(if supported)

I don't understand these write values, how do they match up to a
temperature readin?

> +			* Anything else: do nothing
> +		refer to Documentation/w1/slaves/w1_therm.rst for detailed
> +		information.
> +Users:		any user space application which wants to communicate with
> +		w1_term device
> \ No newline at end of file
> diff --git a/drivers/w1/slaves/w1_therm.c b/drivers/w1/slaves/w1_therm.c
> index 6245950..a530853 100644
> --- a/drivers/w1/slaves/w1_therm.c
> +++ b/drivers/w1/slaves/w1_therm.c
> @@ -39,12 +39,14 @@ module_param_named(strong_pullup, w1_strong_pullup, int, 0);
>  
>  static struct attribute *w1_therm_attrs[] = {
>  	&dev_attr_w1_slave.attr,
> +	&dev_attr_ext_power.attr,
>  	NULL,
>  };
>  
>  static struct attribute *w1_ds28ea00_attrs[] = {
>  	&dev_attr_w1_slave.attr,
>  	&dev_attr_w1_seq.attr,
> +	&dev_attr_ext_power.attr,
>  	NULL,
>  };
>  
> @@ -294,6 +296,26 @@ static inline int w1_DS18S20_convert_temp(u8 rom[9])
>  	return t;
>  }
>  
> +/*------------------------ Helpers Functions----------------------------*/
> +
> +static inline bool bus_mutex_lock(struct mutex *lock)
> +{
> +	int max_trying = W1_THERM_MAX_TRY;
> +	/* try to acquire the mutex, if not, sleep retry_delay before retry) */

Please use scripts/checkpatch.pl on your patches, it should have asked
you to put an empty line after the int definition.



> +	while (mutex_lock_interruptible(lock) != 0 && max_trying > 0) {
> +		unsigned long sleep_rem;
> +
> +		sleep_rem = msleep_interruptible(W1_THERM_RETRY_DELAY);
> +		if (!sleep_rem)
> +			max_trying--;
> +	}
> +
> +	if (!max_trying)
> +		return false;	/* Didn't acquire the bus mutex */
> +
> +	return true;
> +}
> +
>  /*-------------------------Interface Functions------------------------------*/
>  static int w1_therm_add_slave(struct w1_slave *sl)
>  {
> @@ -302,6 +324,16 @@ static int w1_therm_add_slave(struct w1_slave *sl)
>  	if (!sl->family_data)
>  		return -ENOMEM;
>  	atomic_set(THERM_REFCNT(sl->family_data), 1);
> +
> +	/* Getting the power mode of the device {external, parasite}*/
> +	SLAVE_POWERMODE(sl) = read_powermode(sl);
> +
> +	if (SLAVE_POWERMODE(sl) < 0) {
> +		/* no error returned as device has been added */
> +		dev_warn(&sl->dev,
> +			"%s: Device has been added, but power_mode may be corrupted. err=%d\n",
> +			 __func__, SLAVE_POWERMODE(sl));
> +	}
>  	return 0;
>  }
>  
> @@ -512,6 +544,43 @@ error:
>  	return ret;
>  }
>  
> +static int read_powermode(struct w1_slave *sl)
> +{
> +	struct w1_master *dev_master = sl->master;
> +	int max_trying = W1_THERM_MAX_TRY;
> +	int  ret = -ENODEV;
> +
> +	if (!sl->family_data)
> +		goto error;
> +
> +	/* prevent the slave from going away in sleep */
> +	atomic_inc(THERM_REFCNT(sl->family_data));
> +
> +	if (!bus_mutex_lock(&dev_master->bus_mutex)) {
> +		ret = -EAGAIN;	// Didn't acquire the mutex
> +		goto dec_refcnt;
> +	}
> +
> +	while ((max_trying--) && (ret < 0)) {
> +		/* safe version to select slave */
> +		if (!reset_select_slave(sl)) {
> +			w1_write_8(dev_master, W1_READ_PSUPPLY);
> +			/* Read only one bit,
> +			 * 1 is externally powered,
> +			 * 0 is parasite powered
> +			 */
> +			ret = w1_touch_bit(dev_master, 1);
> +			/* ret should be either 1 either 0 */
> +		}
> +	}
> +	mutex_unlock(&dev_master->bus_mutex);
> +
> +dec_refcnt:
> +	atomic_dec(THERM_REFCNT(sl->family_data));
> +error:
> +	return ret;
> +}
> +
>  /*------------------------Interface sysfs--------------------------*/
>  
>  static ssize_t w1_slave_show(struct device *device,
> @@ -565,13 +634,35 @@ static ssize_t w1_slave_store(struct device *device,
>  				ret = w1_therm_families[i].eeprom(device);
>  			else
>  				ret = w1_therm_families[i].precision(device,
> -								val);
> +									val);
>  			break;
>  		}
>  	}
>  	return ret ? : size;
>  }
>  
> +static ssize_t ext_power_show(struct device *device,
> +	struct device_attribute *attr, char *buf)
> +{
> +	struct w1_slave *sl = dev_to_w1_slave(device);
> +
> +	if (!sl->family_data) {
> +		dev_info(device,
> +			"%s: Device not supported by the driver\n", __func__);
> +		return 0;  /* No device family */
> +	}
> +
> +	/* Getting the power mode of the device {external, parasite}*/
> +	SLAVE_POWERMODE(sl) = read_powermode(sl);
> +
> +	if (SLAVE_POWERMODE(sl) < 0) {
> +		dev_dbg(device,
> +			"%s: Power_mode may be corrupted. err=%d\n",
> +			__func__, SLAVE_POWERMODE(sl));
> +	}
> +	return sprintf(buf, "%d\n", SLAVE_POWERMODE(sl));
> +}
> +
>  #if IS_REACHABLE(CONFIG_HWMON)
>  static int w1_read_temp(struct device *device, u32 attr, int channel,
>  			long *val)
> diff --git a/drivers/w1/slaves/w1_therm.h b/drivers/w1/slaves/w1_therm.h
> index b73af0b..2f975a4 100644
> --- a/drivers/w1/slaves/w1_therm.h
> +++ b/drivers/w1/slaves/w1_therm.h
> @@ -25,6 +25,12 @@
>  #include <linux/mutex.h>
>  #include <linux/w1.h>
>  
> +/*----------------------------------Defines---------------------------------*/

No real need for this, we can see defines just fine :)

thanks,

greg k-h

_

[Akira shimahara]

Le mercredi 29 avril 2020 à 15:46 +0200, Greg KH a écrit :
> On Wed, Apr 29, 2020 at 03:32:04PM +0200, Akira Shimahara wrote:
> > Patch for enhacement of w1_therm module.
> > Adding ext_power sysfs entry (RO). Return the power status of the
> > device:
> >  - 0: device parasite powered
> >  - 1: device externally powered
> >  - xx: xx is kernel error
> > 
> > Creating Documentation/ABI/testing/sysfs-driver-w1_therm for the
> > old 
> > driver sysfs and this new entry.
> > 
> > Signed-off-by: Akira Shimahara <akira215corp@gmail.com>
> > ---
> >  .../ABI/testing/sysfs-driver-w1_therm         | 29 ++++++
> >  drivers/w1/slaves/w1_therm.c                  | 93
> > ++++++++++++++++++-
> >  drivers/w1/slaves/w1_therm.h                  | 44 ++++++++-
> >  3 files changed, 163 insertions(+), 3 deletions(-)
> >  create mode 100644 Documentation/ABI/testing/sysfs-driver-w1_therm
> > 
> > diff --git a/Documentation/ABI/testing/sysfs-driver-w1_therm
> > b/Documentation/ABI/testing/sysfs-driver-w1_therm
> > new file mode 100644
> > index 0000000..9aaf625
> > --- /dev/null
> > +++ b/Documentation/ABI/testing/sysfs-driver-w1_therm
> > @@ -0,0 +1,29 @@
> > +What:		/sys/bus/w1/devices/.../ext_power
> > +Date:		Apr 2020
> > +Contact:	Akira Shimahara <akira215corp@gmail.com>
> > +Description:
> > +		(RO) return the power status by asking the device
> > +			* `0`: device parasite powered
> > +			* `1`: device externally powered
> > +			* `-xx`: xx is kernel error when reading power
> > status
> > +Users:		any user space application which wants to
> > communicate with
> > +		w1_term device
> > +
> > +
> > +What:		/sys/bus/w1/devices/.../w1_slave
> > +Date:		Apr 2020
> > +Contact:	Akira Shimahara <akira215corp@gmail.com>
> > +Description:
> > +		(RW) return the temperature in 1/1000 degC.
> > +		*read*: return 2 lines with the hexa output data sent
> > on the
> > +		bus, return the CRC check and temperature in 1/1000
> > degC
> 
> the w1_slave file returns a temperature???
> 
> And sysfs is 1 value-per-file, not multiple lines.
> 
> And as this is a temperature, what's wrong with the iio interface
> that
> handles temperature already?  Don't go making up new userspace apis
> when
> we already have good ones today :)

Yes the existing syfs w1_slave return 2 lines, user application 
catch normally only the temperature. We keep it as many userspace
application are already based on this output, but to ease user
to catch the only purpose of these devices (temperature sensors),
we added on entry which return only the temperature (avoiding
string parsing ,... on both side i.e. driver and user app).

> 
> > +		*write* :
> > +			* `0` : save the 2 or 3 bytes to the device
> > EEPROM
> > +			(i.e. TH, TL and config register)
> > +			* `9..12` : set the device resolution in RAM
> > +			(if supported)
> 
> I don't understand these write values, how do they match up to a
> temperature readin?

This is the previous implementation, and yes, it was not very clear.
These value are not connected to temperature reading. The sysfs 
entry was used to enter user value to device RAM, in 2 registers:
if 0 it trigger a save to the device EEPROM, if the value is between
9 and 12, it stores in the resolution register of the device.
In the next patches, we add more sysfs entries to separate things.

> 
> > +			* Anything else: do nothing
> > +		refer to Documentation/w1/slaves/w1_therm.rst for
> > detailed
> > +		information.
> > +Users:		any user space application which wants to
> > communicate with
> > +		w1_term device
> > \ No newline at end of file
> > diff --git a/drivers/w1/slaves/w1_therm.c
> > b/drivers/w1/slaves/w1_therm.c
> > index 6245950..a530853 100644
> > --- a/drivers/w1/slaves/w1_therm.c
> > +++ b/drivers/w1/slaves/w1_therm.c
> > @@ -39,12 +39,14 @@ module_param_named(strong_pullup,
> > w1_strong_pullup, int, 0);
> >  
> >  static struct attribute *w1_therm_attrs[] = {
> >  	&dev_attr_w1_slave.attr,
> > +	&dev_attr_ext_power.attr,
> >  	NULL,
> >  };
> >  
> >  static struct attribute *w1_ds28ea00_attrs[] = {
> >  	&dev_attr_w1_slave.attr,
> >  	&dev_attr_w1_seq.attr,
> > +	&dev_attr_ext_power.attr,
> >  	NULL,
> >  };
> >  
> > @@ -294,6 +296,26 @@ static inline int w1_DS18S20_convert_temp(u8
> > rom[9])
> >  	return t;
> >  }
> >  
> > +/*------------------------ Helpers Functions--------------------
> > --------*/
> > +
> > +static inline bool bus_mutex_lock(struct mutex *lock)
> > +{
> > +	int max_trying = W1_THERM_MAX_TRY;
> > +	/* try to acquire the mutex, if not, sleep retry_delay before
> > retry) */
> 
> Please use scripts/checkpatch.pl on your patches, it should have
> asked
> you to put an empty line after the int definition.
> 
I used it, no warning on this line but I will add
> 
> 
> > +	while (mutex_lock_interruptible(lock) != 0 && max_trying > 0) {
> > +		unsigned long sleep_rem;
> > +
> > +		sleep_rem = msleep_interruptible(W1_THERM_RETRY_DELAY);
> > +		if (!sleep_rem)
> > +			max_trying--;
> > +	}
> > +
> > +	if (!max_trying)
> > +		return false;	/* Didn't acquire the bus mutex */
> > +
> > +	return true;
> > +}
> > +
> >  /*-------------------------Interface Functions------------------
> > ------------*/
> >  static int w1_therm_add_slave(struct w1_slave *sl)
> >  {
> > @@ -302,6 +324,16 @@ static int w1_therm_add_slave(struct w1_slave
> > *sl)
> >  	if (!sl->family_data)
> >  		return -ENOMEM;
> >  	atomic_set(THERM_REFCNT(sl->family_data), 1);
> > +
> > +	/* Getting the power mode of the device {external, parasite}*/
> > +	SLAVE_POWERMODE(sl) = read_powermode(sl);
> > +
> > +	if (SLAVE_POWERMODE(sl) < 0) {
> > +		/* no error returned as device has been added */
> > +		dev_warn(&sl->dev,
> > +			"%s: Device has been added, but power_mode may
> > be corrupted. err=%d\n",
> > +			 __func__, SLAVE_POWERMODE(sl));
> > +	}
> >  	return 0;
> >  }
> >  
> > @@ -512,6 +544,43 @@ error:
> >  	return ret;
> >  }
> >  
> > +static int read_powermode(struct w1_slave *sl)
> > +{
> > +	struct w1_master *dev_master = sl->master;
> > +	int max_trying = W1_THERM_MAX_TRY;
> > +	int  ret = -ENODEV;
> > +
> > +	if (!sl->family_data)
> > +		goto error;
> > +
> > +	/* prevent the slave from going away in sleep */
> > +	atomic_inc(THERM_REFCNT(sl->family_data));
> > +
> > +	if (!bus_mutex_lock(&dev_master->bus_mutex)) {
> > +		ret = -EAGAIN;	// Didn't acquire the mutex
> > +		goto dec_refcnt;
> > +	}
> > +
> > +	while ((max_trying--) && (ret < 0)) {
> > +		/* safe version to select slave */
> > +		if (!reset_select_slave(sl)) {
> > +			w1_write_8(dev_master, W1_READ_PSUPPLY);
> > +			/* Read only one bit,
> > +			 * 1 is externally powered,
> > +			 * 0 is parasite powered
> > +			 */
> > +			ret = w1_touch_bit(dev_master, 1);
> > +			/* ret should be either 1 either 0 */
> > +		}
> > +	}
> > +	mutex_unlock(&dev_master->bus_mutex);
> > +
> > +dec_refcnt:
> > +	atomic_dec(THERM_REFCNT(sl->family_data));
> > +error:
> > +	return ret;
> > +}
> > +
> >  /*------------------------Interface sysfs-------------------------
> > -*/
> >  
> >  static ssize_t w1_slave_show(struct device *device,
> > @@ -565,13 +634,35 @@ static ssize_t w1_slave_store(struct device
> > *device,
> >  				ret =
> > w1_therm_families[i].eeprom(device);
> >  			else
> >  				ret =
> > w1_therm_families[i].precision(device,
> > -								val);
> > +									
> > val);
> >  			break;
> >  		}
> >  	}
> >  	return ret ? : size;
> >  }
> >  
> > +static ssize_t ext_power_show(struct device *device,
> > +	struct device_attribute *attr, char *buf)
> > +{
> > +	struct w1_slave *sl = dev_to_w1_slave(device);
> > +
> > +	if (!sl->family_data) {
> > +		dev_info(device,
> > +			"%s: Device not supported by the driver\n",
> > __func__);
> > +		return 0;  /* No device family */
> > +	}
> > +
> > +	/* Getting the power mode of the device {external, parasite}*/
> > +	SLAVE_POWERMODE(sl) = read_powermode(sl);
> > +
> > +	if (SLAVE_POWERMODE(sl) < 0) {
> > +		dev_dbg(device,
> > +			"%s: Power_mode may be corrupted. err=%d\n",
> > +			__func__, SLAVE_POWERMODE(sl));
> > +	}
> > +	return sprintf(buf, "%d\n", SLAVE_POWERMODE(sl));
> > +}
> > +
> >  #if IS_REACHABLE(CONFIG_HWMON)
> >  static int w1_read_temp(struct device *device, u32 attr, int
> > channel,
> >  			long *val)
> > diff --git a/drivers/w1/slaves/w1_therm.h
> > b/drivers/w1/slaves/w1_therm.h
> > index b73af0b..2f975a4 100644
> > --- a/drivers/w1/slaves/w1_therm.h
> > +++ b/drivers/w1/slaves/w1_therm.h
> > @@ -25,6 +25,12 @@
> >  #include <linux/mutex.h>
> >  #include <linux/w1.h>
> >  
> > +/*----------------------------------Defines-----------------------
> > ----------*/
> 
> No real need for this, we can see defines just fine :)
> 
Well noted
> thanks,
> 
> greg k-h

👑

[sunil saraff]

Presumo che non abbia ancora sentito parlare di questo? http://w.aLorayne804.xyz/index







Con immense gratitudine,sunil saraff

👆

[nik_bin_nek_alwi]

Unglaublich! http://pqk.Lyndon295.xyz/index






___
Lass bald wieder von dir hören
nik_bin_nek_alwi@yahoo.com

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

[PATCH v6 0/4] support reserving crashkernel above 4G on arm64 kdump

[Chen Zhou]

I am busy with other things, so it was a long time before this version was
released.

This patch series enable reserving crashkernel above 4G in arm64.

There are following issues in arm64 kdump:
1. We use crashkernel=X to reserve crashkernel below 4G, which will fail
when there is no enough low memory.
2. Currently, crashkernel=Y@X can be used to reserve crashkernel above 4G,
in this case, if swiotlb or DMA buffers are requierd, crash dump kernel
will boot failure because there is no low memory available for allocation.

To solve these issues, introduce crashkernel=X,low to reserve specified
size low memory.
Crashkernel=X tries to reserve memory for the crash dump kernel under
4G. If crashkernel=Y,low is specified simultaneously, reserve spcified
size low memory for crash kdump kernel devices firstly and then reserve
memory above 4G.

When crashkernel is reserved above 4G in memory, that is, crashkernel=X,low
is specified simultaneously, kernel should reserve specified size low memory
for crash dump kernel devices. So there may be two crash kernel regions, one
is below 4G, the other is above 4G.
In order to distinct from the high region and make no effect to the use of
kexec-tools, rename the low region as "Crash kernel (low)", and add DT property
"linux,low-memory-range" to crash dump kernel's dtb to pass the low region.

Besides, we need to modify kexec-tools:
arm64: kdump: add another DT property to crash dump kernel's dtb(see [1])

The previous changes and discussions can be retrieved from:

Changes since [v5]
- Move reserve_crashkernel_low() into kernel/crash_core.c.
- Delete crashkernel=X,high.
- Modify crashkernel=X,low.
If crashkernel=X,low is specified simultaneously, reserve spcified size low
memory for crash kdump kernel devices firstly and then reserve memory above 4G.
In addition, rename crashk_low_res as "Crash kernel (low)" for arm64, and then
pass to crash dump kernel by DT property "linux,low-memory-range".
- Update Documentation/admin-guide/kdump/kdump.rst.

Changes since [v4]
- Reimplement memblock_cap_memory_ranges for multiple ranges by Mike.

Changes since [v3]
- Add memblock_cap_memory_ranges back for multiple ranges.
- Fix some compiling warnings.

Changes since [v2]
- Split patch "arm64: kdump: support reserving crashkernel above 4G" as
two. Put "move reserve_crashkernel_low() into kexec_core.c" in a separate
patch.

Changes since [v1]:
- Move common reserve_crashkernel_low() code into kernel/kexec_core.c.
- Remove memblock_cap_memory_ranges() i added in v1 and implement that
in fdt_enforce_memory_region().
There are at most two crash kernel regions, for two crash kernel regions
case, we cap the memory range [min(regs[*].start), max(regs[*].end)]
and then remove the memory range in the middle.

[1]: http://lists.infradead.org/pipermail/kexec/2019-August/023569.html
[v1]: https://lkml.org/lkml/2019/4/2/1174
[v2]: https://lkml.org/lkml/2019/4/9/86
[v3]: https://lkml.org/lkml/2019/4/9/306
[v4]: https://lkml.org/lkml/2019/4/15/273
[v5]: https://lkml.org/lkml/2019/5/6/1360

Chen Zhou (4):
  x86: kdump: move reserve_crashkernel_low() into crash_core.c
  arm64: kdump: reserve crashkenel above 4G for crash dump kernel
  arm64: kdump: add memory for devices by DT property, low-memory-range
  kdump: update Documentation about crashkernel on arm64

 Documentation/admin-guide/kdump/kdump.rst       | 13 ++++-
 Documentation/admin-guide/kernel-parameters.txt | 12 ++++-
 arch/arm64/include/asm/kexec.h                  |  3 ++
 arch/arm64/kernel/setup.c                       |  8 ++-
 arch/arm64/mm/init.c                            | 61 +++++++++++++++++++++--
 arch/x86/include/asm/kexec.h                    |  3 ++
 arch/x86/kernel/setup.c                         | 65 +++----------------------
 include/linux/crash_core.h                      |  4 ++
 include/linux/kexec.h                           |  1 -
 kernel/crash_core.c                             | 65 +++++++++++++++++++++++++
 10 files changed, 168 insertions(+), 67 deletions(-)

-- 
2.7.4

Re: [PATCH v6 0/4] support reserving crashkernel above 4G on arm64 kdump

[Chen Zhou]

Hi all,

Friendly ping...

On 2019/8/30 15:11, Chen Zhou wrote:
> I am busy with other things, so it was a long time before this version was
> released.
> 
> This patch series enable reserving crashkernel above 4G in arm64.
> 
> There are following issues in arm64 kdump:
> 1. We use crashkernel=X to reserve crashkernel below 4G, which will fail
> when there is no enough low memory.
> 2. Currently, crashkernel=Y@X can be used to reserve crashkernel above 4G,
> in this case, if swiotlb or DMA buffers are requierd, crash dump kernel
> will boot failure because there is no low memory available for allocation.
> 
> To solve these issues, introduce crashkernel=X,low to reserve specified
> size low memory.
> Crashkernel=X tries to reserve memory for the crash dump kernel under
> 4G. If crashkernel=Y,low is specified simultaneously, reserve spcified
> size low memory for crash kdump kernel devices firstly and then reserve
> memory above 4G.
> 
> When crashkernel is reserved above 4G in memory, that is, crashkernel=X,low
> is specified simultaneously, kernel should reserve specified size low memory
> for crash dump kernel devices. So there may be two crash kernel regions, one
> is below 4G, the other is above 4G.
> In order to distinct from the high region and make no effect to the use of
> kexec-tools, rename the low region as "Crash kernel (low)", and add DT property
> "linux,low-memory-range" to crash dump kernel's dtb to pass the low region.
> 
> Besides, we need to modify kexec-tools:
> arm64: kdump: add another DT property to crash dump kernel's dtb(see [1])
> 
> The previous changes and discussions can be retrieved from:
> 
> Changes since [v5]
> - Move reserve_crashkernel_low() into kernel/crash_core.c.
> - Delete crashkernel=X,high.
> - Modify crashkernel=X,low.
> If crashkernel=X,low is specified simultaneously, reserve spcified size low
> memory for crash kdump kernel devices firstly and then reserve memory above 4G.
> In addition, rename crashk_low_res as "Crash kernel (low)" for arm64, and then
> pass to crash dump kernel by DT property "linux,low-memory-range".
> - Update Documentation/admin-guide/kdump/kdump.rst.
> 
> Changes since [v4]
> - Reimplement memblock_cap_memory_ranges for multiple ranges by Mike.
> 
> Changes since [v3]
> - Add memblock_cap_memory_ranges back for multiple ranges.
> - Fix some compiling warnings.
> 
> Changes since [v2]
> - Split patch "arm64: kdump: support reserving crashkernel above 4G" as
> two. Put "move reserve_crashkernel_low() into kexec_core.c" in a separate
> patch.
> 
> Changes since [v1]:
> - Move common reserve_crashkernel_low() code into kernel/kexec_core.c.
> - Remove memblock_cap_memory_ranges() i added in v1 and implement that
> in fdt_enforce_memory_region().
> There are at most two crash kernel regions, for two crash kernel regions
> case, we cap the memory range [min(regs[*].start), max(regs[*].end)]
> and then remove the memory range in the middle.
> 
> [1]: http://lists.infradead.org/pipermail/kexec/2019-August/023569.html
> [v1]: https://lkml.org/lkml/2019/4/2/1174
> [v2]: https://lkml.org/lkml/2019/4/9/86
> [v3]: https://lkml.org/lkml/2019/4/9/306
> [v4]: https://lkml.org/lkml/2019/4/15/273
> [v5]: https://lkml.org/lkml/2019/5/6/1360
> 
> Chen Zhou (4):
>   x86: kdump: move reserve_crashkernel_low() into crash_core.c
>   arm64: kdump: reserve crashkenel above 4G for crash dump kernel
>   arm64: kdump: add memory for devices by DT property, low-memory-range
>   kdump: update Documentation about crashkernel on arm64
> 
>  Documentation/admin-guide/kdump/kdump.rst       | 13 ++++-
>  Documentation/admin-guide/kernel-parameters.txt | 12 ++++-
>  arch/arm64/include/asm/kexec.h                  |  3 ++
>  arch/arm64/kernel/setup.c                       |  8 ++-
>  arch/arm64/mm/init.c                            | 61 +++++++++++++++++++++--
>  arch/x86/include/asm/kexec.h                    |  3 ++
>  arch/x86/kernel/setup.c                         | 65 +++----------------------
>  include/linux/crash_core.h                      |  4 ++
>  include/linux/kexec.h                           |  1 -
>  kernel/crash_core.c                             | 65 +++++++++++++++++++++++++
>  10 files changed, 168 insertions(+), 67 deletions(-)
> 

Re: [PATCH v6 0/4] support reserving crashkernel above 4G on arm64 kdump

[John Donnelly]

HI 

SEE INLINE ON A QUESTION :

> On Dec 17, 2019, at 8:07 PM, Chen Zhou <chenzhou10@huawei.com> wrote:
> 
> Hi all,
> 
> Friendly ping...
> 
> On 2019/8/30 15:11, Chen Zhou wrote:
>> I am busy with other things, so it was a long time before this version was
>> released.
>> 
>> This patch series enable reserving crashkernel above 4G in arm64.
>> 
>> There are following issues in arm64 kdump:
>> 1. We use crashkernel=X to reserve crashkernel below 4G, which will fail
>> when there is no enough low memory.
>> 2. Currently, crashkernel=Y@X can be used to reserve crashkernel above 4G,
>> in this case, if swiotlb or DMA buffers are requierd, crash dump kernel
>> will boot failure because there is no low memory available for allocation.

  
      Can you elaborate when the boot failures may fail due to lacking  swiotlb or DMA buffers ? Are these related to certain adapters or specific  platforms  ? 

     I have not seen this when using   crashkernel=2024M@35GB . 


>> 
>> To solve these issues, introduce crashkernel=X,low to reserve specified
>> size low memory.
>> Crashkernel=X tries to reserve memory for the crash dump kernel under
>> 4G. If crashkernel=Y,low is specified simultaneously, reserve spcified
>> size low memory for crash kdump kernel devices firstly and then reserve
>> memory above 4G.
>> 
>> When crashkernel is reserved above 4G in memory, that is, crashkernel=X,low
>> is specified simultaneously, kernel should reserve specified size low memory
>> for crash dump kernel devices. So there may be two crash kernel regions, one
>> is below 4G, the other is above 4G.
>> In order to distinct from the high region and make no effect to the use of
>> kexec-tools, rename the low region as "Crash kernel (low)", and add DT property
>> "linux,low-memory-range" to crash dump kernel's dtb to pass the low region.
>> 
>> Besides, we need to modify kexec-tools:
>> arm64: kdump: add another DT property to crash dump kernel's dtb(see [1])
>> 
>> The previous changes and discussions can be retrieved from:
>> 
>> Changes since [v5]
>> - Move reserve_crashkernel_low() into kernel/crash_core.c.
>> - Delete crashkernel=X,high.
>> - Modify crashkernel=X,low.
>> If crashkernel=X,low is specified simultaneously, reserve spcified size low
>> memory for crash kdump kernel devices firstly and then reserve memory above 4G.
>> In addition, rename crashk_low_res as "Crash kernel (low)" for arm64, and then
>> pass to crash dump kernel by DT property "linux,low-memory-range".
>> - Update Documentation/admin-guide/kdump/kdump.rst.
>> 
>> Changes since [v4]
>> - Reimplement memblock_cap_memory_ranges for multiple ranges by Mike.
>> 
>> Changes since [v3]
>> - Add memblock_cap_memory_ranges back for multiple ranges.
>> - Fix some compiling warnings.
>> 
>> Changes since [v2]
>> - Split patch "arm64: kdump: support reserving crashkernel above 4G" as
>> two. Put "move reserve_crashkernel_low() into kexec_core.c" in a separate
>> patch.
>> 
>> Changes since [v1]:
>> - Move common reserve_crashkernel_low() code into kernel/kexec_core.c.
>> - Remove memblock_cap_memory_ranges() i added in v1 and implement that
>> in fdt_enforce_memory_region().
>> There are at most two crash kernel regions, for two crash kernel regions
>> case, we cap the memory range [min(regs[*].start), max(regs[*].end)]
>> and then remove the memory range in the middle.
>> 
>> [1]: https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_pipermail_kexec_2019-2DAugust_023569.html&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=9tn9kUBabiuYhVtXauANSDGaISnCnHLYcAUQgsPBFxs&e= 
>> [v1]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_4_2_1174&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=F-lM7II2cuMF_sK3b6-QhSbWM3X-pI_WZEs0sZitS7A&e= 
>> [v2]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_4_9_86&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=5Y-S6sqMTklHkOQsNtjTX3C7pV05BjKLGhJVfMHEvDs&e= 
>> [v3]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_4_9_306&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=cWn4zSRQupaZ3jjz4eDvD-pNkoLyL_hsZoRx4yJoD0c&e= 
>> [v4]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_4_15_273&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=Nslk4RJKIyIuT0IoQoolXNjupEDXplPhQQwnTSoXNWE&e= 
>> [v5]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_5_6_1360&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=HJVAM6sCxV2DnNg5d4pw8WPqtkmQnKvztEmkSIgtQ5M&e= 
>> 
>> Chen Zhou (4):
>>  x86: kdump: move reserve_crashkernel_low() into crash_core.c
>>  arm64: kdump: reserve crashkenel above 4G for crash dump kernel
>>  arm64: kdump: add memory for devices by DT property, low-memory-range
>>  kdump: update Documentation about crashkernel on arm64
>> 
>> Documentation/admin-guide/kdump/kdump.rst       | 13 ++++-
>> Documentation/admin-guide/kernel-parameters.txt | 12 ++++-
>> arch/arm64/include/asm/kexec.h                  |  3 ++
>> arch/arm64/kernel/setup.c                       |  8 ++-
>> arch/arm64/mm/init.c                            | 61 +++++++++++++++++++++--
>> arch/x86/include/asm/kexec.h                    |  3 ++
>> arch/x86/kernel/setup.c                         | 65 +++----------------------
>> include/linux/crash_core.h                      |  4 ++
>> include/linux/kexec.h                           |  1 -
>> kernel/crash_core.c                             | 65 +++++++++++++++++++++++++
>> 10 files changed, 168 insertions(+), 67 deletions(-)
>> 
> 
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_kexec&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=XMcFx61B_QPg-FUfG_-t88DKCnGm4grqu6zRguiHYrU&e= 

Re: [PATCH v6 0/4] support reserving crashkernel above 4G on arm64 kdump

[Chen Zhou]

Hi John,

On 2019/12/19 1:18, John Donnelly wrote:
> HI 
> 
> SEE INLINE ON A QUESTION :
> 
>> On Dec 17, 2019, at 8:07 PM, Chen Zhou <chenzhou10@huawei.com> wrote:
>>
>> Hi all,
>>
>> Friendly ping...
>>
>> On 2019/8/30 15:11, Chen Zhou wrote:
>>> I am busy with other things, so it was a long time before this version was
>>> released.
>>>
>>> This patch series enable reserving crashkernel above 4G in arm64.
>>>
>>> There are following issues in arm64 kdump:
>>> 1. We use crashkernel=X to reserve crashkernel below 4G, which will fail
>>> when there is no enough low memory.
>>> 2. Currently, crashkernel=Y@X can be used to reserve crashkernel above 4G,
>>> in this case, if swiotlb or DMA buffers are requierd, crash dump kernel
>>> will boot failure because there is no low memory available for allocation.
> 
>   
>       Can you elaborate when the boot failures may fail due to lacking  swiotlb or DMA buffers ? Are these related to certain adapters or specific  platforms  ? 
> 
>      I have not seen this when using   crashkernel=2024M@35GB . 
> 

For example, in my environment "Huawei TaiShan 2280",
we need to use mpt3sas driver in crash dump kernel for dumping vmcore.

mpt3sas driver needs to call dma_pool_alloc to allocate some pages,
if there is no DMA buffer, page allocation will fail, which leads to crash dump kernel boot failure,
like this:

[2019/12/19 9:12:41] [   12.403501] mpt3sas_cm0: diag reset: SUCCESS
[2019/12/19 9:12:41] [   12.456076] mpt3sas_cm0: reply_post_free pool: dma_pool_alloc failed
[2019/12/19 9:12:41] [   12.462515] pci 0004:48:00.0: can't derive routing for PCI INT A
[2019/12/19 9:12:41] [   12.468761] mpt3sas 0004:49:00.0: PCI INT A: no GSI
[2019/12/19 9:12:41] [   12.476348] mpt3sas_cm0: failure at drivers/scsi/mpt3sas/mpt3sas_scsih.c:10626/_scsih_probe()!
[2019/12/19 9:14:38] [ TIME ] Timed out waiting for device dev-di…b3\x2d890a\x2d2ead7df26f48.device.
[2019/12/19 9:14:38] [DEPEND] Dependency failed for Initrd Root Device.
[2019/12/19 9:14:38] [DEPEND] Dependency failed for /sysroot.
[2019/12/19 9:14:38] [DEPEND] Dependency failed for Initrd Root File System.
[2019/12/19 9:14:38] [DEPEND] Dependency failed for Reload Configuration from the Real Root.
[2019/12/19 9:14:38] [DEPEND] Dependency failed for File System C…40bae-9eb8-46b3-890a-2ead7df26f48.

Thanks,
Chen Zhou

> 
>>>
>>> To solve these issues, introduce crashkernel=X,low to reserve specified
>>> size low memory.
>>> Crashkernel=X tries to reserve memory for the crash dump kernel under
>>> 4G. If crashkernel=Y,low is specified simultaneously, reserve spcified
>>> size low memory for crash kdump kernel devices firstly and then reserve
>>> memory above 4G.
>>>
>>> When crashkernel is reserved above 4G in memory, that is, crashkernel=X,low
>>> is specified simultaneously, kernel should reserve specified size low memory
>>> for crash dump kernel devices. So there may be two crash kernel regions, one
>>> is below 4G, the other is above 4G.
>>> In order to distinct from the high region and make no effect to the use of
>>> kexec-tools, rename the low region as "Crash kernel (low)", and add DT property
>>> "linux,low-memory-range" to crash dump kernel's dtb to pass the low region.
>>>
>>> Besides, we need to modify kexec-tools:
>>> arm64: kdump: add another DT property to crash dump kernel's dtb(see [1])
>>>
>>> The previous changes and discussions can be retrieved from:
>>>
>>> Changes since [v5]
>>> - Move reserve_crashkernel_low() into kernel/crash_core.c.
>>> - Delete crashkernel=X,high.
>>> - Modify crashkernel=X,low.
>>> If crashkernel=X,low is specified simultaneously, reserve spcified size low
>>> memory for crash kdump kernel devices firstly and then reserve memory above 4G.
>>> In addition, rename crashk_low_res as "Crash kernel (low)" for arm64, and then
>>> pass to crash dump kernel by DT property "linux,low-memory-range".
>>> - Update Documentation/admin-guide/kdump/kdump.rst.
>>>
>>> Changes since [v4]
>>> - Reimplement memblock_cap_memory_ranges for multiple ranges by Mike.
>>>
>>> Changes since [v3]
>>> - Add memblock_cap_memory_ranges back for multiple ranges.
>>> - Fix some compiling warnings.
>>>
>>> Changes since [v2]
>>> - Split patch "arm64: kdump: support reserving crashkernel above 4G" as
>>> two. Put "move reserve_crashkernel_low() into kexec_core.c" in a separate
>>> patch.
>>>
>>> Changes since [v1]:
>>> - Move common reserve_crashkernel_low() code into kernel/kexec_core.c.
>>> - Remove memblock_cap_memory_ranges() i added in v1 and implement that
>>> in fdt_enforce_memory_region().
>>> There are at most two crash kernel regions, for two crash kernel regions
>>> case, we cap the memory range [min(regs[*].start), max(regs[*].end)]
>>> and then remove the memory range in the middle.
>>>
>>> [1]: https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_pipermail_kexec_2019-2DAugust_023569.html&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=9tn9kUBabiuYhVtXauANSDGaISnCnHLYcAUQgsPBFxs&e= 
>>> [v1]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_4_2_1174&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=F-lM7II2cuMF_sK3b6-QhSbWM3X-pI_WZEs0sZitS7A&e= 
>>> [v2]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_4_9_86&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=5Y-S6sqMTklHkOQsNtjTX3C7pV05BjKLGhJVfMHEvDs&e= 
>>> [v3]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_4_9_306&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=cWn4zSRQupaZ3jjz4eDvD-pNkoLyL_hsZoRx4yJoD0c&e= 
>>> [v4]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_4_15_273&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=Nslk4RJKIyIuT0IoQoolXNjupEDXplPhQQwnTSoXNWE&e= 
>>> [v5]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_5_6_1360&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=HJVAM6sCxV2DnNg5d4pw8WPqtkmQnKvztEmkSIgtQ5M&e= 
>>>
>>> Chen Zhou (4):
>>>  x86: kdump: move reserve_crashkernel_low() into crash_core.c
>>>  arm64: kdump: reserve crashkenel above 4G for crash dump kernel
>>>  arm64: kdump: add memory for devices by DT property, low-memory-range
>>>  kdump: update Documentation about crashkernel on arm64
>>>
>>> Documentation/admin-guide/kdump/kdump.rst       | 13 ++++-
>>> Documentation/admin-guide/kernel-parameters.txt | 12 ++++-
>>> arch/arm64/include/asm/kexec.h                  |  3 ++
>>> arch/arm64/kernel/setup.c                       |  8 ++-
>>> arch/arm64/mm/init.c                            | 61 +++++++++++++++++++++--
>>> arch/x86/include/asm/kexec.h                    |  3 ++
>>> arch/x86/kernel/setup.c                         | 65 +++----------------------
>>> include/linux/crash_core.h                      |  4 ++
>>> include/linux/kexec.h                           |  1 -
>>> kernel/crash_core.c                             | 65 +++++++++++++++++++++++++
>>> 10 files changed, 168 insertions(+), 67 deletions(-)
>>>
>>
>>
>> _______________________________________________
>> kexec mailing list
>> kexec@lists.infradead.org
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_kexec&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=XMcFx61B_QPg-FUfG_-t88DKCnGm4grqu6zRguiHYrU&e= 
> 
> 
> .
> 

`

[John Donnelly]

> On Dec 18, 2019, at 8:56 PM, Chen Zhou <chenzhou10@huawei.com> wrote:
> 
> Hi John,
> 
> On 2019/12/19 1:18, John Donnelly wrote:
>> HI 
>> 
>> SEE INLINE ON A QUESTION :
>> 
>>> On Dec 17, 2019, at 8:07 PM, Chen Zhou <chenzhou10@huawei.com> wrote:
>>> 
>>> Hi all,
>>> 
>>> Friendly ping...
>>> 
>>> On 2019/8/30 15:11, Chen Zhou wrote:
>>>> I am busy with other things, so it was a long time before this version was
>>>> released.
>>>> 
>>>> This patch series enable reserving crashkernel above 4G in arm64.
>>>> 
>>>> There are following issues in arm64 kdump:
>>>> 1. We use crashkernel=X to reserve crashkernel below 4G, which will fail
>>>> when there is no enough low memory.
>>>> 2. Currently, crashkernel=Y@X can be used to reserve crashkernel above 4G,
>>>> in this case, if swiotlb or DMA buffers are requierd, crash dump kernel
>>>> will boot failure because there is no low memory available for allocation.
>> 
>> 
>>      Can you elaborate when the boot failures may fail due to lacking  swiotlb or DMA buffers ? Are these related to certain adapters or specific  platforms  ? 
>> 
>>     I have not seen this when using   crashkernel=2024M@35GB . 
>> 
> 
> For example, in my environment "Huawei TaiShan 2280",
> we need to use mpt3sas driver in crash dump kernel for dumping vmcore.
> 
> mpt3sas driver needs to call dma_pool_alloc to allocate some pages,
> if there is no DMA buffer, page allocation will fail, which leads to crash dump kernel boot failure,
> like this:
> 
> [2019/12/19 9:12:41] [   12.403501] mpt3sas_cm0: diag reset: SUCCESS
> [2019/12/19 9:12:41] [   12.456076] mpt3sas_cm0: reply_post_free pool: dma_pool_alloc failed
> [2019/12/19 9:12:41] [   12.462515] pci 0004:48:00.0: can't derive routing for PCI INT A
> [2019/12/19 9:12:41] [   12.468761] mpt3sas 0004:49:00.0: PCI INT A: no GSI
> [2019/12/19 9:12:41] [   12.476348] mpt3sas_cm0: failure at drivers/scsi/mpt3sas/mpt3sas_scsih.c:10626/_scsih_probe()!
> [2019/12/19 9:14:38] [ TIME ] Timed out waiting for device dev-di…b3\x2d890a\x2d2ead7df26f48.device.
> [2019/12/19 9:14:38] [DEPEND] Dependency failed for Initrd Root Device.
> [2019/12/19 9:14:38] [DEPEND] Dependency failed for /sysroot.
> [2019/12/19 9:14:38] [DEPEND] Dependency failed for Initrd Root File System.
> [2019/12/19 9:14:38] [DEPEND] Dependency failed for Reload Configuration from the Real Root.
> [2019/12/19 9:14:38] [DEPEND] Dependency failed for File System C…40bae-9eb8-46b3-890a-2ead7df26f48.


 Thank you for sharing .  We are not seeing this issue on a 5.4.0.rc8 ;    Like I said in a previous email we can  take crash dumps using crashkernel=768M for a  “ standard “ small VMcore to local storage :

0004:01:00.0 RAID bus controller: Broadcom / LSI MegaRAID SAS-3 3316 [Intruder] (rev 01)
	Subsystem: Broadcom / LSI MegaRAID SAS 9361-16i
	Kernel driver in use: megaraid_sas 


What version of the kernel are you using ?


> 
> Thanks,
> Chen Zhou
> 
>> 
>>>> 
>>>> To solve these issues, introduce crashkernel=X,low to reserve specified
>>>> size low memory.
>>>> Crashkernel=X tries to reserve memory for the crash dump kernel under
>>>> 4G. If crashkernel=Y,low is specified simultaneously, reserve spcified
>>>> size low memory for crash kdump kernel devices firstly and then reserve
>>>> memory above 4G.
>>>> 
>>>> When crashkernel is reserved above 4G in memory, that is, crashkernel=X,low
>>>> is specified simultaneously, kernel should reserve specified size low memory
>>>> for crash dump kernel devices. So there may be two crash kernel regions, one
>>>> is below 4G, the other is above 4G.
>>>> In order to distinct from the high region and make no effect to the use of
>>>> kexec-tools, rename the low region as "Crash kernel (low)", and add DT property
>>>> "linux,low-memory-range" to crash dump kernel's dtb to pass the low region.
>>>> 
>>>> Besides, we need to modify kexec-tools:
>>>> arm64: kdump: add another DT property to crash dump kernel's dtb(see [1])
>>>> 
>>>> The previous changes and discussions can be retrieved from:
>>>> 
>>>> Changes since [v5]
>>>> - Move reserve_crashkernel_low() into kernel/crash_core.c.
>>>> - Delete crashkernel=X,high.
>>>> - Modify crashkernel=X,low.
>>>> If crashkernel=X,low is specified simultaneously, reserve spcified size low
>>>> memory for crash kdump kernel devices firstly and then reserve memory above 4G.
>>>> In addition, rename crashk_low_res as "Crash kernel (low)" for arm64, and then
>>>> pass to crash dump kernel by DT property "linux,low-memory-range".
>>>> - Update Documentation/admin-guide/kdump/kdump.rst.
>>>> 
>>>> Changes since [v4]
>>>> - Reimplement memblock_cap_memory_ranges for multiple ranges by Mike.
>>>> 
>>>> Changes since [v3]
>>>> - Add memblock_cap_memory_ranges back for multiple ranges.
>>>> - Fix some compiling warnings.
>>>> 
>>>> Changes since [v2]
>>>> - Split patch "arm64: kdump: support reserving crashkernel above 4G" as
>>>> two. Put "move reserve_crashkernel_low() into kexec_core.c" in a separate
>>>> patch.
>>>> 
>>>> Changes since [v1]:
>>>> - Move common reserve_crashkernel_low() code into kernel/kexec_core.c.
>>>> - Remove memblock_cap_memory_ranges() i added in v1 and implement that
>>>> in fdt_enforce_memory_region().
>>>> There are at most two crash kernel regions, for two crash kernel regions
>>>> case, we cap the memory range [min(regs[*].start), max(regs[*].end)]
>>>> and then remove the memory range in the middle.
>>>> 
>>>> [1]: https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_pipermail_kexec_2019-2DAugust_023569.html&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=9tn9kUBabiuYhVtXauANSDGaISnCnHLYcAUQgsPBFxs&e= 
>>>> [v1]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_4_2_1174&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=F-lM7II2cuMF_sK3b6-QhSbWM3X-pI_WZEs0sZitS7A&e= 
>>>> [v2]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_4_9_86&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=5Y-S6sqMTklHkOQsNtjTX3C7pV05BjKLGhJVfMHEvDs&e= 
>>>> [v3]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_4_9_306&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=cWn4zSRQupaZ3jjz4eDvD-pNkoLyL_hsZoRx4yJoD0c&e= 
>>>> [v4]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_4_15_273&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=Nslk4RJKIyIuT0IoQoolXNjupEDXplPhQQwnTSoXNWE&e= 
>>>> [v5]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_5_6_1360&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=HJVAM6sCxV2DnNg5d4pw8WPqtkmQnKvztEmkSIgtQ5M&e= 
>>>> 
>>>> Chen Zhou (4):
>>>> x86: kdump: move reserve_crashkernel_low() into crash_core.c
>>>> arm64: kdump: reserve crashkenel above 4G for crash dump kernel
>>>> arm64: kdump: add memory for devices by DT property, low-memory-range
>>>> kdump: update Documentation about crashkernel on arm64
>>>> 
>>>> Documentation/admin-guide/kdump/kdump.rst       | 13 ++++-
>>>> Documentation/admin-guide/kernel-parameters.txt | 12 ++++-
>>>> arch/arm64/include/asm/kexec.h                  |  3 ++
>>>> arch/arm64/kernel/setup.c                       |  8 ++-
>>>> arch/arm64/mm/init.c                            | 61 +++++++++++++++++++++--
>>>> arch/x86/include/asm/kexec.h                    |  3 ++
>>>> arch/x86/kernel/setup.c                         | 65 +++----------------------
>>>> include/linux/crash_core.h                      |  4 ++
>>>> include/linux/kexec.h                           |  1 -
>>>> kernel/crash_core.c                             | 65 +++++++++++++++++++++++++
>>>> 10 files changed, 168 insertions(+), 67 deletions(-)
>>>> 
>>> 
>>> 
>>> _______________________________________________
>>> kexec mailing list
>>> kexec@lists.infradead.org
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_kexec&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=XMcFx61B_QPg-FUfG_-t88DKCnGm4grqu6zRguiHYrU&e= 
>> 
>> 
>> .

Re: `

[Chen Zhou]

Hi John,

On 2019/12/20 2:33, John Donnelly wrote:
> 
> 
>> On Dec 18, 2019, at 8:56 PM, Chen Zhou <chenzhou10@huawei.com> wrote:
>>
>> Hi John,
>>
>> On 2019/12/19 1:18, John Donnelly wrote:
>>> HI 
>>>
>>> SEE INLINE ON A QUESTION :
>>>
>>>> On Dec 17, 2019, at 8:07 PM, Chen Zhou <chenzhou10@huawei.com> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Friendly ping...
>>>>
>>>> On 2019/8/30 15:11, Chen Zhou wrote:
>>>>> I am busy with other things, so it was a long time before this version was
>>>>> released.
>>>>>
>>>>> This patch series enable reserving crashkernel above 4G in arm64.
>>>>>
>>>>> There are following issues in arm64 kdump:
>>>>> 1. We use crashkernel=X to reserve crashkernel below 4G, which will fail
>>>>> when there is no enough low memory.
>>>>> 2. Currently, crashkernel=Y@X can be used to reserve crashkernel above 4G,
>>>>> in this case, if swiotlb or DMA buffers are requierd, crash dump kernel
>>>>> will boot failure because there is no low memory available for allocation.
>>>
>>>
>>>      Can you elaborate when the boot failures may fail due to lacking  swiotlb or DMA buffers ? Are these related to certain adapters or specific  platforms  ? 
>>>
>>>     I have not seen this when using   crashkernel=2024M@35GB . 
>>>
>>
>> For example, in my environment "Huawei TaiShan 2280",
>> we need to use mpt3sas driver in crash dump kernel for dumping vmcore.
>>
>> mpt3sas driver needs to call dma_pool_alloc to allocate some pages,
>> if there is no DMA buffer, page allocation will fail, which leads to crash dump kernel boot failure,
>> like this:
>>
>> [2019/12/19 9:12:41] [   12.403501] mpt3sas_cm0: diag reset: SUCCESS
>> [2019/12/19 9:12:41] [   12.456076] mpt3sas_cm0: reply_post_free pool: dma_pool_alloc failed
>> [2019/12/19 9:12:41] [   12.462515] pci 0004:48:00.0: can't derive routing for PCI INT A
>> [2019/12/19 9:12:41] [   12.468761] mpt3sas 0004:49:00.0: PCI INT A: no GSI
>> [2019/12/19 9:12:41] [   12.476348] mpt3sas_cm0: failure at drivers/scsi/mpt3sas/mpt3sas_scsih.c:10626/_scsih_probe()!
>> [2019/12/19 9:14:38] [ TIME ] Timed out waiting for device dev-di…b3\x2d890a\x2d2ead7df26f48.device.
>> [2019/12/19 9:14:38] [DEPEND] Dependency failed for Initrd Root Device.
>> [2019/12/19 9:14:38] [DEPEND] Dependency failed for /sysroot.
>> [2019/12/19 9:14:38] [DEPEND] Dependency failed for Initrd Root File System.
>> [2019/12/19 9:14:38] [DEPEND] Dependency failed for Reload Configuration from the Real Root.
>> [2019/12/19 9:14:38] [DEPEND] Dependency failed for File System C…40bae-9eb8-46b3-890a-2ead7df26f48.
> 
> 
>  Thank you for sharing .  We are not seeing this issue on a 5.4.0.rc8 ;    Like I said in a previous email we can  take crash dumps using crashkernel=768M for a  “ standard “ small VMcore to local storage :
> 
> 0004:01:00.0 RAID bus controller: Broadcom / LSI MegaRAID SAS-3 3316 [Intruder] (rev 01)
> 	Subsystem: Broadcom / LSI MegaRAID SAS 9361-16i
> 	Kernel driver in use: megaraid_sas 
> 
> 
> What version of the kernel are you using ?

5.5.0.rc1

As I said in the patch series cover-letter, this patch series address following cases/isssues.

There are following issues in arm64 kdump:
1. We use crashkernel=X to reserve crashkernel below 4G, which will fail
when there is no enough low memory.
2. Currently, crashkernel=Y@X can be used to reserve crashkernel above 4G,
in this case, if swiotlb or DMA buffers are required, crash dump kernel
will boot failure because there is no low memory available for allocation.

From your description, you use crashkernel=768M.
There are enough crashkernel below 4G, so crashkernel will be
reserved successfully and kdump be ok. （This case has no DMA buffers issue.）

or you use crashkernel=2024M@35GB, and this case is ok?
If your driver doesn't need DMA buffers(I am not sure about it), kdump will also be ok.


If i understand your question and explain clearly?

Thanks,
Chen Zhou

> 
> 
>>
>> Thanks,
>> Chen Zhou
>>
>>>
>>>>>
>>>>> To solve these issues, introduce crashkernel=X,low to reserve specified
>>>>> size low memory.
>>>>> Crashkernel=X tries to reserve memory for the crash dump kernel under
>>>>> 4G. If crashkernel=Y,low is specified simultaneously, reserve spcified
>>>>> size low memory for crash kdump kernel devices firstly and then reserve
>>>>> memory above 4G.
>>>>>
>>>>> When crashkernel is reserved above 4G in memory, that is, crashkernel=X,low
>>>>> is specified simultaneously, kernel should reserve specified size low memory
>>>>> for crash dump kernel devices. So there may be two crash kernel regions, one
>>>>> is below 4G, the other is above 4G.
>>>>> In order to distinct from the high region and make no effect to the use of
>>>>> kexec-tools, rename the low region as "Crash kernel (low)", and add DT property
>>>>> "linux,low-memory-range" to crash dump kernel's dtb to pass the low region.
>>>>>
>>>>> Besides, we need to modify kexec-tools:
>>>>> arm64: kdump: add another DT property to crash dump kernel's dtb(see [1])
>>>>>
>>>>> The previous changes and discussions can be retrieved from:
>>>>>
>>>>> Changes since [v5]
>>>>> - Move reserve_crashkernel_low() into kernel/crash_core.c.
>>>>> - Delete crashkernel=X,high.
>>>>> - Modify crashkernel=X,low.
>>>>> If crashkernel=X,low is specified simultaneously, reserve spcified size low
>>>>> memory for crash kdump kernel devices firstly and then reserve memory above 4G.
>>>>> In addition, rename crashk_low_res as "Crash kernel (low)" for arm64, and then
>>>>> pass to crash dump kernel by DT property "linux,low-memory-range".
>>>>> - Update Documentation/admin-guide/kdump/kdump.rst.
>>>>>
>>>>> Changes since [v4]
>>>>> - Reimplement memblock_cap_memory_ranges for multiple ranges by Mike.
>>>>>
>>>>> Changes since [v3]
>>>>> - Add memblock_cap_memory_ranges back for multiple ranges.
>>>>> - Fix some compiling warnings.
>>>>>
>>>>> Changes since [v2]
>>>>> - Split patch "arm64: kdump: support reserving crashkernel above 4G" as
>>>>> two. Put "move reserve_crashkernel_low() into kexec_core.c" in a separate
>>>>> patch.
>>>>>
>>>>> Changes since [v1]:
>>>>> - Move common reserve_crashkernel_low() code into kernel/kexec_core.c.
>>>>> - Remove memblock_cap_memory_ranges() i added in v1 and implement that
>>>>> in fdt_enforce_memory_region().
>>>>> There are at most two crash kernel regions, for two crash kernel regions
>>>>> case, we cap the memory range [min(regs[*].start), max(regs[*].end)]
>>>>> and then remove the memory range in the middle.
>>>>>
>>>>> [1]: https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_pipermail_kexec_2019-2DAugust_023569.html&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=9tn9kUBabiuYhVtXauANSDGaISnCnHLYcAUQgsPBFxs&e= 
>>>>> [v1]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_4_2_1174&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=F-lM7II2cuMF_sK3b6-QhSbWM3X-pI_WZEs0sZitS7A&e= 
>>>>> [v2]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_4_9_86&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=5Y-S6sqMTklHkOQsNtjTX3C7pV05BjKLGhJVfMHEvDs&e= 
>>>>> [v3]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_4_9_306&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=cWn4zSRQupaZ3jjz4eDvD-pNkoLyL_hsZoRx4yJoD0c&e= 
>>>>> [v4]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_4_15_273&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=Nslk4RJKIyIuT0IoQoolXNjupEDXplPhQQwnTSoXNWE&e= 
>>>>> [v5]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_5_6_1360&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=HJVAM6sCxV2DnNg5d4pw8WPqtkmQnKvztEmkSIgtQ5M&e= 
>>>>>
>>>>> Chen Zhou (4):
>>>>> x86: kdump: move reserve_crashkernel_low() into crash_core.c
>>>>> arm64: kdump: reserve crashkenel above 4G for crash dump kernel
>>>>> arm64: kdump: add memory for devices by DT property, low-memory-range
>>>>> kdump: update Documentation about crashkernel on arm64
>>>>>
>>>>> Documentation/admin-guide/kdump/kdump.rst       | 13 ++++-
>>>>> Documentation/admin-guide/kernel-parameters.txt | 12 ++++-
>>>>> arch/arm64/include/asm/kexec.h                  |  3 ++
>>>>> arch/arm64/kernel/setup.c                       |  8 ++-
>>>>> arch/arm64/mm/init.c                            | 61 +++++++++++++++++++++--
>>>>> arch/x86/include/asm/kexec.h                    |  3 ++
>>>>> arch/x86/kernel/setup.c                         | 65 +++----------------------
>>>>> include/linux/crash_core.h                      |  4 ++
>>>>> include/linux/kexec.h                           |  1 -
>>>>> kernel/crash_core.c                             | 65 +++++++++++++++++++++++++
>>>>> 10 files changed, 168 insertions(+), 67 deletions(-)
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> kexec mailing list
>>>> kexec@lists.infradead.org
>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_kexec&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=XMcFx61B_QPg-FUfG_-t88DKCnGm4grqu6zRguiHYrU&e= 
>>>
>>>
>>> .
> 
> 
> .
> 

Re: `

[Chen Zhou]

Hi John,

On 2019/12/20 2:33, John Donnelly wrote:
> 
> 
>> On Dec 18, 2019, at 8:56 PM, Chen Zhou <chenzhou10@huawei.com> wrote:
>>
>> Hi John,
>>
>> On 2019/12/19 1:18, John Donnelly wrote:
>>> HI 
>>>
>>> SEE INLINE ON A QUESTION :
>>>
>>>> On Dec 17, 2019, at 8:07 PM, Chen Zhou <chenzhou10@huawei.com> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Friendly ping...
>>>>
>>>> On 2019/8/30 15:11, Chen Zhou wrote:
>>>>> I am busy with other things, so it was a long time before this version was
>>>>> released.
>>>>>
>>>>> This patch series enable reserving crashkernel above 4G in arm64.
>>>>>
>>>>> There are following issues in arm64 kdump:
>>>>> 1. We use crashkernel=X to reserve crashkernel below 4G, which will fail
>>>>> when there is no enough low memory.
>>>>> 2. Currently, crashkernel=Y@X can be used to reserve crashkernel above 4G,
>>>>> in this case, if swiotlb or DMA buffers are requierd, crash dump kernel
>>>>> will boot failure because there is no low memory available for allocation.
>>>
>>>
>>>      Can you elaborate when the boot failures may fail due to lacking  swiotlb or DMA buffers ? Are these related to certain adapters or specific  platforms  ? 
>>>
>>>     I have not seen this when using   crashkernel=2024M@35GB . 
>>>
>>
>> For example, in my environment "Huawei TaiShan 2280",
>> we need to use mpt3sas driver in crash dump kernel for dumping vmcore.
>>
>> mpt3sas driver needs to call dma_pool_alloc to allocate some pages,
>> if there is no DMA buffer, page allocation will fail, which leads to crash dump kernel boot failure,
>> like this:
>>
>> [2019/12/19 9:12:41] [   12.403501] mpt3sas_cm0: diag reset: SUCCESS
>> [2019/12/19 9:12:41] [   12.456076] mpt3sas_cm0: reply_post_free pool: dma_pool_alloc failed
>> [2019/12/19 9:12:41] [   12.462515] pci 0004:48:00.0: can't derive routing for PCI INT A
>> [2019/12/19 9:12:41] [   12.468761] mpt3sas 0004:49:00.0: PCI INT A: no GSI
>> [2019/12/19 9:12:41] [   12.476348] mpt3sas_cm0: failure at drivers/scsi/mpt3sas/mpt3sas_scsih.c:10626/_scsih_probe()!
>> [2019/12/19 9:14:38] [ TIME ] Timed out waiting for device dev-di…b3\x2d890a\x2d2ead7df26f48.device.
>> [2019/12/19 9:14:38] [DEPEND] Dependency failed for Initrd Root Device.
>> [2019/12/19 9:14:38] [DEPEND] Dependency failed for /sysroot.
>> [2019/12/19 9:14:38] [DEPEND] Dependency failed for Initrd Root File System.
>> [2019/12/19 9:14:38] [DEPEND] Dependency failed for Reload Configuration from the Real Root.
>> [2019/12/19 9:14:38] [DEPEND] Dependency failed for File System C…40bae-9eb8-46b3-890a-2ead7df26f48.
> 
> 
>  Thank you for sharing .  We are not seeing this issue on a 5.4.0.rc8 ;    Like I said in a previous email we can  take crash dumps using crashkernel=768M for a  “ standard “ small VMcore to local storage :
> 
> 0004:01:00.0 RAID bus controller: Broadcom / LSI MegaRAID SAS-3 3316 [Intruder] (rev 01)
> 	Subsystem: Broadcom / LSI MegaRAID SAS 9361-16i
> 	Kernel driver in use: megaraid_sas 
> 
> 
> What version of the kernel are you using ?

5.5.0.rc1

As I said in the patch series cover-letter, this patch series address following cases/isssues.

There are following issues in arm64 kdump:
1. We use crashkernel=X to reserve crashkernel below 4G, which will fail
when there is no enough low memory.
2. Currently, crashkernel=Y@X can be used to reserve crashkernel above 4G,
in this case, if swiotlb or DMA buffers are required, crash dump kernel
will boot failure because there is no low memory available for allocation.

From your description, you use crashkernel=768M.
There are enough crashkernel below 4G, so crashkernel will be
reserved successfully and kdump be ok. （This case has no DMA buffers issue.）

or you use crashkernel=2024M@35GB, and this case is ok?
If your driver doesn't need DMA buffers(I am not sure about it), kdump will also be ok.


If i understand your question and explain clearly?

Thanks,
Chen Zhou

> 
> 
>>
>> Thanks,
>> Chen Zhou
>>
>>>
>>>>>
>>>>> To solve these issues, introduce crashkernel=X,low to reserve specified
>>>>> size low memory.
>>>>> Crashkernel=X tries to reserve memory for the crash dump kernel under
>>>>> 4G. If crashkernel=Y,low is specified simultaneously, reserve spcified
>>>>> size low memory for crash kdump kernel devices firstly and then reserve
>>>>> memory above 4G.
>>>>>
>>>>> When crashkernel is reserved above 4G in memory, that is, crashkernel=X,low
>>>>> is specified simultaneously, kernel should reserve specified size low memory
>>>>> for crash dump kernel devices. So there may be two crash kernel regions, one
>>>>> is below 4G, the other is above 4G.
>>>>> In order to distinct from the high region and make no effect to the use of
>>>>> kexec-tools, rename the low region as "Crash kernel (low)", and add DT property
>>>>> "linux,low-memory-range" to crash dump kernel's dtb to pass the low region.
>>>>>
>>>>> Besides, we need to modify kexec-tools:
>>>>> arm64: kdump: add another DT property to crash dump kernel's dtb(see [1])
>>>>>
>>>>> The previous changes and discussions can be retrieved from:
>>>>>
>>>>> Changes since [v5]
>>>>> - Move reserve_crashkernel_low() into kernel/crash_core.c.
>>>>> - Delete crashkernel=X,high.
>>>>> - Modify crashkernel=X,low.
>>>>> If crashkernel=X,low is specified simultaneously, reserve spcified size low
>>>>> memory for crash kdump kernel devices firstly and then reserve memory above 4G.
>>>>> In addition, rename crashk_low_res as "Crash kernel (low)" for arm64, and then
>>>>> pass to crash dump kernel by DT property "linux,low-memory-range".
>>>>> - Update Documentation/admin-guide/kdump/kdump.rst.
>>>>>
>>>>> Changes since [v4]
>>>>> - Reimplement memblock_cap_memory_ranges for multiple ranges by Mike.
>>>>>
>>>>> Changes since [v3]
>>>>> - Add memblock_cap_memory_ranges back for multiple ranges.
>>>>> - Fix some compiling warnings.
>>>>>
>>>>> Changes since [v2]
>>>>> - Split patch "arm64: kdump: support reserving crashkernel above 4G" as
>>>>> two. Put "move reserve_crashkernel_low() into kexec_core.c" in a separate
>>>>> patch.
>>>>>
>>>>> Changes since [v1]:
>>>>> - Move common reserve_crashkernel_low() code into kernel/kexec_core.c.
>>>>> - Remove memblock_cap_memory_ranges() i added in v1 and implement that
>>>>> in fdt_enforce_memory_region().
>>>>> There are at most two crash kernel regions, for two crash kernel regions
>>>>> case, we cap the memory range [min(regs[*].start), max(regs[*].end)]
>>>>> and then remove the memory range in the middle.
>>>>>
>>>>> [1]: https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_pipermail_kexec_2019-2DAugust_023569.html&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=9tn9kUBabiuYhVtXauANSDGaISnCnHLYcAUQgsPBFxs&e= 
>>>>> [v1]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_4_2_1174&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=F-lM7II2cuMF_sK3b6-QhSbWM3X-pI_WZEs0sZitS7A&e= 
>>>>> [v2]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_4_9_86&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=5Y-S6sqMTklHkOQsNtjTX3C7pV05BjKLGhJVfMHEvDs&e= 
>>>>> [v3]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_4_9_306&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=cWn4zSRQupaZ3jjz4eDvD-pNkoLyL_hsZoRx4yJoD0c&e= 
>>>>> [v4]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_4_15_273&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=Nslk4RJKIyIuT0IoQoolXNjupEDXplPhQQwnTSoXNWE&e= 
>>>>> [v5]: https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2019_5_6_1360&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=HJVAM6sCxV2DnNg5d4pw8WPqtkmQnKvztEmkSIgtQ5M&e= 
>>>>>
>>>>> Chen Zhou (4):
>>>>> x86: kdump: move reserve_crashkernel_low() into crash_core.c
>>>>> arm64: kdump: reserve crashkenel above 4G for crash dump kernel
>>>>> arm64: kdump: add memory for devices by DT property, low-memory-range
>>>>> kdump: update Documentation about crashkernel on arm64
>>>>>
>>>>> Documentation/admin-guide/kdump/kdump.rst       | 13 ++++-
>>>>> Documentation/admin-guide/kernel-parameters.txt | 12 ++++-
>>>>> arch/arm64/include/asm/kexec.h                  |  3 ++
>>>>> arch/arm64/kernel/setup.c                       |  8 ++-
>>>>> arch/arm64/mm/init.c                            | 61 +++++++++++++++++++++--
>>>>> arch/x86/include/asm/kexec.h                    |  3 ++
>>>>> arch/x86/kernel/setup.c                         | 65 +++----------------------
>>>>> include/linux/crash_core.h                      |  4 ++
>>>>> include/linux/kexec.h                           |  1 -
>>>>> kernel/crash_core.c                             | 65 +++++++++++++++++++++++++
>>>>> 10 files changed, 168 insertions(+), 67 deletions(-)
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> kexec mailing list
>>>> kexec@lists.infradead.org
>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_kexec&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=ZAC6UYbT-3qLR3Dvevd09m6neWWzGWSphuvXXlXow68&s=XMcFx61B_QPg-FUfG_-t88DKCnGm4grqu6zRguiHYrU&e= 
>>>
>>>
>>> .
> 
> 
> .
> 


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

?

[Ms Ella Golan]

Did you receive my email?

Faithfully,
Ms Ella Golan

ÈçºÎËõ¶ÌÉú²úÖÜÆÚ£¬×¼Ê±½»»õºÍ½µµÍ¿â´æ

[ÏòÔóÌì]

详细内容 请 预览 附件图片 
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

ÖÐ ²ã ¸É ²¿ Èç ºÎµ±

[ÔÆÃî÷ë]

详细内容 请 预览 附件图片 
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

¿À´Ã ±ÞµîÁÖ ¾îÁ¦ ¾î¶»°Ô ¾Ë¾ÒÀ»±î¿ä?

[µµ³Îµå Æ®·³ÇÁ]

[-- Attachment #1: Type: text/plain, Size: 2369 bytes --]

Spam detection software, running on the system "blaine.gmane.org",
has identified this incoming email as possible spam.  The original
message has been attached to this so you can view it or label
similar future email.  If you have any questions, see
@@CONTACT_ADDRESS@@ for details.

Content preview:  ¾È³çÇϼ¼¿ä. Ŭ·´ ȸ¿ø ¿©·¯ºÐ ÁÁÀº Á¤º¸ À־ ¾Ë·Áµå¸³´Ï´Ù.
   ÁÖ½ÄÅõÀÚ·Î ¾ÈÁ¤ÀûÀ¸·Î °í¼öÀÍÀ» ³»±â À§Çؼ­´Â [...] 

Content analysis details:   (9.6 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
 0.0 URIBL_BLOCKED          ADMINISTRATOR NOTICE: The query to URIBL was blocked.
                            See
                            http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
                             for more information.
                            [URIs: bit.ly]
-0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at http://www.dnswl.org/, no
                            trust
                            [198.145.21.10 listed in list.dnswl.org]
 1.3 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
              [Blocked - see <http://www.spamcop.net/bl.shtml?221.195.112.45>]
 1.2 RCVD_NUMERIC_HELO      Received: contains an IP address used for HELO
-0.6 RP_MATCHES_RCVD        Envelope sender domain matches handover relay domain
 0.0 FROM_ILLEGAL_CHARS     From: has too many raw illegal characters
 0.0 T_HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail
                            domains are different
 2.4 RCVD_HELO_IP_MISMATCH  Received: HELO and IP do not match, but should
-1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
                            [score: 0.0000]
 2.6 MSGID_RANDY            Message-Id has pattern used in spam
 1.5 SUBJ_ILLEGAL_CHARS     Subject: has too many raw illegal characters
 0.0 SUBJECT_NEEDS_ENCODING No description available.
 1.9 FORGED_MUA_IMS         Forged mail pretending to be from IMS
 1.0 RCVD_DOUBLE_IP_LOOSE   Received: by and from look like IP addresses

The original message was not completely plain text, and may be unsafe to
open with some email clients; in particular, it may contain a virus,
or confirm that your address can receive spam.  If you wish to view
it, it may be safer to save it to a file and open it with an editor.


[-- Attachment #2: original message before SpamAssassin --]
[-- Type: message/rfc822, Size: 3765 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 246 bytes --]

¾È³çÇϼ¼¿ä. Ŭ·´ ȸ¿ø ¿©·¯ºÐ

ÁÁÀº Á¤º¸ À־
¾Ë·Áµå¸³´Ï´Ù.

ÁÖ½ÄÅõÀÚ·Î ¾ÈÁ¤ÀûÀ¸·Î °í¼öÀÍÀ» ³»±â À§Çؼ­´Â

¾È³çÇϼ¼¿ä. Ŭ·´ ȸ¿ø
¿©·¯ºÐ

ÁÁÀº Á¤º¸ ÀÖ¾î
°øÀ¯µå¸³´Ï´Ù.

±ÞµîÁÖ ¸ÅÁÖ ¹«·á·Î ÁÖ´Â
»çÀÌÆ®ÀÔ´Ï´Ù.

http://bit.ly/2ywVMsN

[-- Attachment #2.1.2: Type: text/plain, Size: 178 bytes --]

_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

ÁÖ½Ä Å¬·´ ȸ¿øºÐµé²² Èñ¼Ò½ÄÀÖ¾î °øÀ¯ÇÕ´Ï´Ù.

[Ŭ·´Àå]

[-- Attachment #1: Type: text/plain, Size: 2405 bytes --]

Spam detection software, running on the system "blaine.gmane.org",
has identified this incoming email as possible spam.  The original
message has been attached to this so you can view it or label
similar future email.  If you have any questions, see
@@CONTACT_ADDRESS@@ for details.

Content preview:  ¾È³çÇϼ¼¿ä Ŭ·´¿©·¯ºÐ ÁÖ½ÄÅõÀÚ·Î ¼Õ½Ç Å©½Ç°Ì´Ï´Ù °í°´µéÀÌ
  ½ÇÁ¦·Î µ· ¹ú°í ÀÖ´Â °÷ÀÔ´Ï´Ù. [...] 

Content analysis details:   (10.3 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at http://www.dnswl.org/, no
                            trust
                            [198.145.21.10 listed in list.dnswl.org]
 1.3 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
                 [Blocked - see <http://www.spamcop.net/bl.shtml?121.8.98.35>]
 0.8 RCVD_IN_SORBS_WEB      RBL: SORBS: sender is an abusable web server
                            [121.8.98.35 listed in dnsbl.sorbs.net]
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail provider
                            (jsstock.ceo[at]gmail.com)
 1.2 RCVD_NUMERIC_HELO      Received: contains an IP address used for HELO
-0.6 RP_MATCHES_RCVD        Envelope sender domain matches handover relay domain
 0.0 T_HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail
                            domains are different
 2.4 RCVD_HELO_IP_MISMATCH  Received: HELO and IP do not match, but should
-1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
                            [score: 0.0000]
 0.0 T_FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and
                            EnvelopeFrom freemail headers are different
 2.6 MSGID_RANDY            Message-Id has pattern used in spam
 1.5 SUBJ_ILLEGAL_CHARS     Subject: has too many raw illegal characters
 0.0 SUBJECT_NEEDS_ENCODING No description available.
 1.0 RCVD_DOUBLE_IP_LOOSE   Received: by and from look like IP addresses
 1.9 FORGED_MUA_OUTLOOK     Forged mail pretending to be from MS Outlook

The original message was not completely plain text, and may be unsafe to
open with some email clients; in particular, it may contain a virus,
or confirm that your address can receive spam.  If you wish to view
it, it may be safer to save it to a file and open it with an editor.


[-- Attachment #2: original message before SpamAssassin --]
[-- Type: message/rfc822, Size: 3376 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 203 bytes --]

¾È³çÇϼ¼¿ä Ŭ·´¿©·¯ºÐ

ÁÖ½ÄÅõÀÚ·Î ¼Õ½Ç Å©½Ç°Ì´Ï´Ù


°í°´µéÀÌ ½ÇÁ¦·Î µ· ¹ú°í
ÀÖ´Â °÷ÀÔ´Ï´Ù.

ÀÌ ¾÷ü´Â ¾î¶»°Ô ¼öÀÍÀ»
³»´ÂÁö ¹«·áüÇèÇغ¸¼¼¿ä.


Å« µµ¿ò µÇ½Ç°Ì´Ï´Ù.


https://goo.gl/3jVZYU

[-- Attachment #2.1.2: Type: text/plain, Size: 178 bytes --]

_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Ó²¼þµç·Éè¼Æ¡¢¹ÊÕ϶¨Î»Ó빤³Ì°¸Àý·ÖÎö

[Òüƽ½¨]

---- Original mail message -----
发件人:穆昂<hokvgku5612@cia.hk>
收件人:<linux-nvdimm@lists.01.org>
发送时间:1998-09-15 

MIME-Version: 1.0

发件人: 尹平建 hokvgku5612@cia.hk>
发送时间: 19710402 8833
收件人: linux-nvdimm@lists.01.org
主题: 问候邮件
硬件电路设计、故障定位与工程案例分析
【时间安排】
  8月24-25日北京    8月28-29日上海       8月21-22日深圳
【学习费用】三千二百元 / 每人
【参加对象】硬件工程师、电路工程师、PCB工程师、测试工程师、系统工程师、研发部门经理等
报名咨询电话：0755-61288035   010-51661863   021-31261580 
在线咨询 QQ：6983436   
报名信箱：6983436@qq.com  (报名请回复索取报名表）
 
讲师介绍：
Randy 王
Randy Wang，王老师，高级电路设计专家，硬件经理，先后在华为等公司的核心硬件研发部门任职，在电路设计领域有十多年的工作经验。对元器件选择及常见故障分析、电源、时钟、电路板噪声抑制、抗干扰设计、电路可靠性设计、电路测试、高性能PCB的信号及电源完整性的设计，有极丰富的经验。其成功设计的电路板层数包括40层、28层、26层、22层、16层、10 层、8层、4层、2层等。其成功设计的最高密度的电路板，网络数达两万，管脚数超过八万。
自2010年开设电路设计培训课程以来，Randy接触过数百家不同类型的企业、研究所，帮助这些单位解决过大量工程设计中的问题。
以上独特的经历，使Randy的课程非常贴近工程实践，完全做到了课程中的每个案例都来自于工作中的问题，每个技术要点都正中电路设计和故障调试的靶心。
因此Randy的课程以实战性、实用性、能真正解决工程实际问题、能真正帮助工程师提升设计水平而广受好评。
至今，Randy已举办过电路设计公开课及内训课程八十多场，培训学员三千多人。
 
课程大纲：
第一章                          简化电路设计的方法
1.       电路设计中一些关键误区的澄清
2.       方法---如何判断电路设计中：哪些部分是必须重视、并严格控制的；哪些部分的要求可以放松一些；哪些部分可以不关注。
3.       信号分析法---简单实用的电路分析方法介绍
4.       信号分析法的应用与实例
l  4个实例：针对常见的几个设计困境，分析如何用信号分析法快速解决。
第二章 常规元器件应用中的技巧、选型方法、案例分析
1.       如何活用电阻，解决电路设计中的复杂问题
2.       电容的两个重要而又经常被忽略的作用，及其对设计的重要指导
3.       如何针对不同的电路要求，有针对性地选择合适的电容
4.       电容的寿命---计算实例分析
5.       电容选择中的实用计算方法---计算公式介绍与实例分析
6.       陶瓷电容、薄膜电容、铝电解电容、钽电容---选型方法、应用陷阱、及针对工程应用中的问题的解决方案
7.       电感与磁珠---什么时候用电感、什么时候用磁珠，电感和磁珠的选型方法与案例分析
8.       二极管---选型方法、注意要点、误区与案例分析
9.       MOSFET的应用---如何针对MOSFET的datasheet来选型
第三章                          电源设计
1.       线性电源应用中的常见问题
2.       开关电源设计要点与案例分析
l  以简单而形象的方式，理解开关电源工作原理，及各组成部分的功能
l  开关电源电路中，元器件的选型要点与实例分析
l  开关电源功耗计算、效率分析实例
l  以降压电源电路为例，解析电源电路分析要领
l  重点：基于一个案例，分析开关电源常见的故障，及其解决方法
3.       低功耗设计中如何选择电源---要点与实例分析
4.       实例：解决小型化、低噪声、高输出电流、高可靠性、高稳定性的实用方案
5.       电源啸叫问题的根源剖析与案例介绍
6.       电源模块的选型要点、常见问题与案例分析
7.       开关电源的可靠性决定因素与分析要点
8.       传统保险管和新式保险管的对比、分析、应用实例
第四章                          电路的保护性设计
1.       针对上电、下电过程，如何实现电路的保护
2.       电路监控的实现与实例分析
3.       热插拔设计要点与实例
4.       电路的隔离保护
l  隔离保护的三种方法、元器件选择、实例分析
5.       散热设计---热设计的计算、设计实例
第五章                          时钟电路设计
1.       晶体（Crystal）、晶振（Oscillator）的选型与电路设计要点
l  晶体电路的工作原理
l  晶体datasheet中各参数的深入理解与选型要点
l  晶体应用案例分析---实际应用中的案例
l  晶振的工作原理、优点、缺点，晶振与晶体应用上的差异。
l  晶振datasheet中，各参数的深入理解与应用要点、案例分析
2.       时钟驱动器的选型与应用要点
3.       如何规避PCB设计中，可能出现的时钟电路的问题---PCB的技术要点与案例分析
第六章                          电路驱动能力的解析
1.       对驱动能力的理解，常见的疑问
l  电路的驱动能力如何、发送端驱动能力是否足够、如何提高驱动能力、驱动能力不够会发生什么故障
2.       由驱动能力不足导致的电路故障---案例分析
3.       器件手册中与驱动能力相关的参数详解
4.       驱动能力计算实例 
l  通过4个综合实例，深刻理解芯片的驱动能力，掌握分析“驱动”这类问题的方法
5.       综合实例---基于该实例，介绍多个技术要点的综合应用
l  深刻体会器件的驱动能力对最终信号波形的影响
l  某些芯片的应用，在设计阶段，需预先提防一些应用陷阱
l  如何根据芯片datasheet，判断信号是否可能出现与“驱动”相关的问题
l  如何根据芯片datasheet，定性地分析芯片的驱动能力
l  如何根据芯片datasheet，便捷地实现对芯片驱动能力的定量计算与评估
第七章                          PCB设计的技术要点、案例分析
1.       很多电路故障是由PCB设计错误造成的--- PCB设计错误的实例
2.       检查PCB设计图的关键要点与实例---如何检查PCB图
3.       硬件工程师如何做仿真
4.       阻抗控制
l  阻抗的含义
l  如何实现阻抗控制---完成阻抗控制的具体步骤与实例分析
l  关于阻抗控制的误区
5.       PCB板的层叠结构设计要点与案例分析
l  PCB的层叠结构设计的详细步骤
l  6个设计实例与错误设计的案例
6.       信号分析与PCB设计要点、实例、案例分析
l  信号完整性问题，在波形上的4种表现形式及其产生的根本原因、解决办法
l  过孔的影响---过孔分析的方法、如何量化计算过孔的影响、过孔应用三项技巧
l  信号反射的根源，反射对信号的影响，哪些反射不会成为问题
l  反射的定性分析、定量计算，通过实例深刻理解反射
l  如何选择正确的信号匹配方式，深入分析各匹配方式的应用要点、常见问题
l  回流路径---信号如何选择回流路径，如何分析信号回流的问题，案例解析
l  地弹的影响，及其对设计、测试的具体要求
l  把串扰降到最低---实用方法及设计实例
l  表层走线还是内层走线？--- 各自的优缺点和实例分析
l  使用盲、埋孔技术 --- 常见错误及设计要点
l  蛇形线走线的常见问题分析
l  PCB布线最常见的几个误区---充分认识这些误区，简化电路设计

_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

ÈçºÎ¹æ»®²úƷƽ̨£¿ÈçºÎ½øÐм¼Êõ¹æ»®£¿

[ÁÎêØÓÑ]

---- Original mail message -----
发件人:邢君雨<Kdhdlhk7951@zjsenyu.com>
收件人:<linux-nvdimm@lists.01.org>
发送时间:1966-01-22 

MIME-Version: 1.0

发件人: 廖曦友 Kdhdlhk7951@zjsenyu.com>
发送时间: 19880813 2171
收件人: linux-nvdimm@lists.01.org
主题: 问候邮件

产品平台与技术管理
 
时间地点： 8月24-25日北京、8月28-29日上海、8月21-22日深圳
 
学员对象：企业CEO/总经理、研发总监、研发经理/项目经理/技术经理/产品经理、系统工程师、产品规划专家
费　　用：三千二百元 / 每人
报名咨询电话：0755-612-88.035   010-516-61.863   021-312-61.580   在线咨询 QQ：6983436   
(在线报名请回复，课程名称+公司名称+参会人全名+联系方式 至信箱 6983436@qq.com）
 
课程背景：
随着产品生命周期越来越短，市场竞争日趋激烈，能否快速地推出客户/市场需要的产品将直接关系到一个企业能否保持持续赢利的能力。
作为企业的领导者及研发管理者，您一定面临着以下问题或挑战：
如何实现基于产品平台去开发产品？
如何规划产品平台？
如何进行技术规划？
如何进行CBB（公共共享模块）设计？
如何保障从组织及绩效方面来保障与牵引企业基于平台进行产品开发？
……
课程基于国际先进成熟的平台化开发管理模式、工具及方法，并结合国内优秀研发管理企业的最佳实践，针对中国企业的实际，帮助您全面掌握平台化研发管理的核心思想、组织模式以及系统的方法与工具，进而实现平台化、模块化开发，提升企业的核心竞争力。
 
课程收益：
l  分析业界公司在产品平台、技术管理中的误区，分享成功经验； 
l  理解产品平台的基本概念、平台化开发的价值与意义； 
l  理解产品平台管理、技术路标规划、技术开发的流程及支撑体系； 
l  了解优秀研发企业的平台化产品开发的管理模式； 
l  掌握技术研发的过程与方法； 
l  掌握平台规划的过程、工具与方法
l  掌握平台化研发的组织与绩效管理体系设计
l  掌握组件设计的过程、工具与方法； 
 
培训内容： 
1.案例分析
2.产品平台和技术管理概述
1)企业研发面临的问题与挑战
a)面临的挑战
2)产品平台概述
a)什么是产品平台
b)产品平台的定义
c)产品平台的特点
d)基于产品平台进行产品设计的优点
e)技术平台、产品平台、产品线与产品的关系
3)共用构建模块（CBB）
a)构建模块(BB)的定义与属性
b)CBB与BB的主要特征
c)CBB与BB的区别
4)产品平台和CBB的重要意义
5)技术管理概述
6)集成产品开发简介
 
3.产品平台战略和规划
1)产品战略框架
2)产品规划与平台规划的关系
3)产品平台规划的几个层次
a)产品平台发展战略
b)产品平台组合战略
c)产品平台规划流程
d)产品平台绩效与生命周期
4)产品平台发展战略
a)下一代平台战略
b)衍生平台战略
c)新产品线平台战略
5)产品线组合战略
a)产品平台战略之分割平台战略
b)平台战略之垂直规划战略
c)平台战略之滩头阵地战略
6)产品平台规划流程
a)产品系列差异分析
b)平台路标规划
c)平台要素定义
d)平台项目分析
e)平台项目管理
7)模板展示及演练
8)产品平台绩效与生命周期
 
4.技术战略和技术规划
1)企业技术战略
a)平台组成要素-核心技术
b)核心技术在技术规划中的位置
c)技术规划的核心内容
d)技术规划的关键要素
e)技术规划的输出-技术路线图
2)技术路线图概念
a)通过技术规划描绘现在和未来
b)技术路线图主要特征
c)技术路线图的价值
3)技术规划流程
a)技术规划的典型过程
b)技术规划的五个步骤
c)Step1：市场分析
d)Step2：产品分析
e)Step3：技术分析
f)Step4：技术项目分析
g)Step5技术管理
4)模板展示及演练
5)产品开发与技术研发的先后顺序
6)预研与技术开发概述
a)为什么要进行预研?
b)预研的分类
c)预研与技术开发流程
7)技术项目评审
8)研讨：
 
5.模块化设计（组件设计）
1)平台、模块共享的层次
2)系统工程-架构分解、组件开发
3)模块化设计过程
a)得到架构和规格的步骤1：功能分析
b)模块差异分析
c)通用件提取与应用规划
d)得到架构和规格的步骤2：设计综合
4)总体设计及CBB提取过程 （本节含1组演练）
 
6.共用组件使用及管理
1)共用组件开发
2)组件共享类型
3)概念阶段：识别CBB
4)确认CBB的使用比例
5)计划阶段：明确被使用CBB，以及可能提供给其他产品或产品线的CBB
6)开发阶段：使用已有的CBB及构造新的CBB
7)测试阶段：PC-CBB产品使用规划－示例
8)组件设计对BOM系统的要求
9)将重用的部件在BOM结构树上进行整合
10)发布阶段：CBB的推广问题及其解决
11)在原有产品基础上优化组件的案例 
12)为何不愿意贡献CBB
13)为何不愿意使用CBB
14)研讨与演练 
 
7.平台与技术管理组织架构 （1小时）
1)大型企业技术管理组织架构
2)研发资源部门的相关职责
3)产品线管理部门的相关职责
4)中小型企业技术管理组织架构
5)预研部职责
6)技术相关横向团队
7)技术开发管理组织机构设置
 
8)平台及组件管理工具介绍
 
培训讲师：
James：研发管理资深顾问
n  专业背景：
多年高科技企业产品研发和研发管理、产品管理工作经历，先后担任过项目，质量总监，质量副总等职位，在长期的研发管理实践中积累了丰富的技术和管理经验。
在国内某知名通信企业（华为）工作期间，先后从事产品开发、项目管理和产品质量等工作，并作为推行组成员与国际研发管理顶尖咨询顾问在研发及售后服务系统推动公司级研发管理变革（IPD-集成产品开发）。在质量部工作期间，作为EPG成员，开发了需求管理工具R-Manager以及CMM 5级流程，并负责企业内部的推行。
在展讯通信公司工作期间，担任质量部高级经理，任职期间有针对性地将研发管理的业界最佳实践同公司现状相结合，全面建立并优化产品管理体系。同时兼任内部讲师，具有丰富的产品管理实战经验。
在北京联信永益工作期间，作为质量副总成功建立了产品需求、产品定义、立项及整个开发与上市过程的管理，为公司的上市做好了铺垫。
在中国惠普TS-QO产品线，作为高级咨询顾问，成功的打入中国移动总部和建设银行总部，为国字号的企业管理领域市场打开了研发、测试、运维的管理咨询之路。
n  业务擅长：
在多家电信设备厂商从事过研发以及管理工作，对部门管理、项目管理和团队建设等方面经验丰富。并且在研发流程体系和质量管理体系有丰富的从业经历，沟通能力强，有协作精神；做事认真细致，富于创新。
n  培训经验：
从事研发管理咨询，先后作为项目核心成员和项目经理成功完成了近20个研发管理咨询项目体系的建设和落地（产品开发流程体系、研发项目管理体系、CMMI软件开发管理体系），在产品开发流程设计、研发项目管理和体系推行方面具有丰富的咨询经验。
目前受众的主要客户如下：
国电南瑞、亚信科技、长城汽车、中通客车、宇通客车、福田汽车、潍柴动力、上海宝信软件、深圳比亚迪微电子、山东鲁光科技、武汉东浦、北京华彩、长城电脑，美菱电器，大唐电信、中国移动总部、吉林移动、河北移动、广西移动、贵州移动、四川电信、国网电科院、正元信息、中联佳裕、山东万博、鲁光信息、广通迅达、伟景行、石化盈科、长春宏达、中国海关、重邮信科、成都吉锐、广州日立电梯、北京华彩、北京蓝讯、升腾资讯、中电华大、西威电子数家企业。
◆研发管理咨询：主要参与及负责的项目如下：
l  ==>中国移动总部运营支撑中心  
测试管理体系咨询：参与了该咨询项目的现状调研、测试管理流程体系设计、组织结构建议、测试工具及平台规划、测试项目管理体系设计、测试绩效管理体系设计、研发KPI体系设计，2012.12月已结项。
主要用于中国移动总部运营支撑中心管理华为，亚信，惠普等企业的产品质量和人员管理。
l  ==>建设银行数据中心
IT运维管理咨询：参与该咨询项目的现状调研、交接维流程体系设计、产品上线运维关键指标设计、运维故障管理流程。
2012.9月已经结项
l  ==>浙江蓝讯软件有限公司   （国家安全管理委员会软件定制开发）
研发管理体系咨询项目（研发流程体系、技术平台管理工具与模板体系、研发质量管理体系，CMMI项目），任项目组成员，已结项。
l  ==>武汉东浦信息技术有限公司  （东风汽车、东风日产汽车PDM，ERP软件开发）
主导了该咨询项目的现状调研、产品开发流程体系设计、技术平台管理工具与模板体系设计等，CMMI项目，任项目经理，已结项。
==>北京石化盈科   （电讯盈科与中国石化的合资企业，主要为中国石化开发油品管理软件）

_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

´ÓÖ»¶Ô¼¼Êõ¸ºÔðת±äΪ¶ÔÈ«Á÷³Ì¸ºÔð

[Æֵϰ®]

---- Original mail message -----
发件人:何元晨<mmsjmco0330@nhmep.org>
收件人:<linux-nvdimm@lists.01.org>
发送时间:1987-07-09 

MIME-Version: 1.0

发件人: 浦迪爱 mmsjmco0330@nhmep.org>
发送时间: 20001221 5183
收件人: linux-nvdimm@lists.01.org
主题: 问候邮件
从技术走向管理――课程简介
【时间地点】 8月21-22日深圳     8月24-25日上海     8月28-29日北京
【参加对象】 企业CEO/总经理、研发总经理/副总、公司总工/技术总监、研发项目经理/产品经理、中试部经理、研发质量部经理、PMO（项目管理办公室）主任、走上管理岗位的技术人员等
【授课方式】 案例分享、实务分析、互动讨论、项目模拟、培训游戏
【学习费用】 三千二百元 / 人
【垂询热线】 0755-61288035  &  010-51661863  &  021-31261580
在线咨询 QQ：6983436   报名信箱：6983436@qq.com
课程背景
根据我司多年从事研发管理咨询的经验发现中国企业95%以上的研发中基层主管都是从技术能力比较强的工程师中提拔起来的，很多刚刚走上管理岗位的研发人员在从技术走向管理的过程中存在如下问题：
1.      角色不能转换，过度关注技术细节；
2.      认真帮助下属可是他们并不买账；
3.      凡事亲力亲为，忙得焦头烂额，可是上司却嫌效率太低；
4.      希望下属多提意见，可是他们却什么都不说，不愿意承担责任；
5.      上司让制定工作计划，可却无从下手；
6.      不知道如何分派工作，如何领导团队，更不知道如何确保你的团队不出差错；
7.      ……
这些问题致使走上管理工作岗位的技术人员疲惫不堪却还不能有效达到整体目标。
从一名只对技术负责的技术人员转变为对全流程负责的项目经理和对某一专业领域负责的部门经理，在这个转变的过程中，技术人员要实现哪些蜕变、要掌握哪些管理技能、如何培养自己的领导力等是本课程重点探讨的内容。
 
课程收益
1.      分享讲师500多场研发管理培训的专业经验，通过现场的互动帮助学员理清走向管理的困惑
2.      总结和分析技术人员从技术走向管理过程中常见的问题
3.      掌握实现从技术走向管理的过程中要实现的几个转变
4.      了解从技术走向管理的五个好习惯（成果导向、综观全局、聚焦重点、发挥优势、集思广益）
5.      掌握与领导沟通的方法技巧
6.      掌握走上管理工作岗位后需要掌握的四个核心管理技能（目标与计划、组织与分派工作、控制与纠偏、领导与激励）
7.      了解成功实现从技术走向管理转变的几个关键要素
8.      分享讲师20多个咨询项目的研发管理的案例资料（模板、表格、样例……），帮助学员制定Action Plan，使得学员参训后回到自己的公司能够很好实践
 
讲师介绍
Giles： PDMA（美国产品开发管理协会www.pdma.org）会员 
《PDMA新产品开发手册》中文版主译 　清华大学研发管理特聘教授　
n  专业背景：
十多年高科技企业研发管理实践，典型的在企业实践中从技术走向管理的管理专家。在某著名通信公司工作期间，作为硬件工程师、软件工程师和系统工程师（系统总体设计总工）参与过多个小型、大型项目开发，有五年具体产品开发经验，承担过多个项目的管理工作，担任过研发项目管理部经理、研发管理办经理、技术管理部副总经理、研发IT中心主任，经历并参与主持了此公司研发管理（包括研发流程管理、研发项目管理、研发人力资源管理、研发IT管理等模块）混乱到规范化建设的全过程。1998年开始长期与国际顶尖咨询顾问一起工作，并作为第一批核心小组成员与国际著名的咨询公司合作主导了研发管理变革项目及其母项目公司级IT规划项目，同时兼任该公司高级讲师，负责企业文化建设在研发的推进和落地工作。
n  研发管理咨询经验
曾作为项目总监、项目经理主导了10多个研发管理咨询项目，帮助这些企业全面建立研发管理体系（包括流程、组织、绩效、IT），有效地提升了这些公司的研发管理和创新能力，典型客户如下：
1)     最大专业打印机供应商北洋电气
2)     信利国际有限公司
3)     国内系统集成行业第二名（华胜天成）
4)     中电集团第七研究所
5)     TCL家庭网络事业部
6)     苏州科达
7)     国内最大的网络安全厂商天融信……
n  研发管理培训经验：
曾为AO史密斯、海尔、TCL、TTE、美的、夏新、康佳、海信、创维、北大方正、格力电器、步步高、长虹、彩虹集团、苏泊尔、上海日立、成都索贝、云环电子、蓝微电子、威创科技、卓立电气、老板电器、南太集团、海洋王、航盛电子、华强信息、华阳多媒体、广东威特、信华精机、研祥智能、聚光科技、信利国际有限公司、北洋电气、CNNIC（中国互联网信息中心）、网易、华友世纪、阿里巴巴、淘宝网、新浪网、讯雷、优视动景、御风行科技、吉比特、朗科、冠捷电子、江苏富士通、福建富士通、格林威尔、信威通讯、中国电信北京研究院、中国普天公司、福建敏讯、无限立通、瑞斯康达、和协航电、全亚通讯、广州京信、虹信科技、国人通讯、杰赛科技、冠日通讯、星网锐捷、实达网络、鑫诺电子、神州数码、同洲电子、九洲信息科技、赛科世纪、四达时代、穗彩科技、龙江风采、东进电子、威科姆电子、金蝶软件、东软软件、高阳金信、杭州虹软、中国工商银行软件开发中心、中国银联、雁联、广联达软件、方正春元、灵图、科银京成、广州安凯、广州从兴、广州宏达信、拓尔思、青岛英派斯、浙大中控、上海精伦、中创信测、汇川技术、雄韬电源、核达中远通、斯比泰、山特电子、深圳南瑞、国电南自、上海思源、上海宝信、荣信电力电子、亿力吉奥、电力科学研究院、特变电工、上海海得、迈瑞医疗、和佳医疗、中集集团、众友科技、好易通科技、乐凯集团、金东纸业、徐工集团、三一集团、山河智能、安徽叉车、同洲电子、天融信、绿盟科技、北方微电子、深圳国微、珠海炬力、上海展讯、威盛电子、天綦、天马微电子、武汉电信器件公司、中电华大、杭州汉帆、中电集团第7研究所、中电集团第43研究所、中电集团第29研究所、公安部第一研究所、同方威视、北京矿冶研究总院、中国石化研究院、电子科学研究院、郑州三磨所、研祥智能、北京圣非凡、潍柴动力、长城华冠、北京现代、东风汽车、一汽集团、中国重汽、北汽福田、通用泛亚、江铃陆风、奇瑞汽车、上汽通用五菱、长安汽车、、苏州金龙新粤交通、威海广泰、大豪科技、西子OTIS、蒂森电梯、西子孚信、深圳和宏、顺德震德、鹰牌控股、烟台万化、先声药业、中国航空、中国航天、等500多家企业和研究机构提供了专业的研发管理培训。其中部分公司邀请讲课多次。
 
课程大纲
一、         案例分析
1.      讨论：技术走向管理的烦恼
二、         从技术走向管理的角色定位和角色转换
1.      为什么要从技术走向管理（背景、原因）
2.      管理人员的角色定位和素质模型
3.      有哪些技术管理职位
4.      技术型管理者的角色与核心工作（技术管理者的不是说不要技术，而是层次越高的技术管理者，越需要技术广度、技术敏锐度与市场敏锐度，而且更需要沟通、管理与领导技能）
5.      技术人员与管理人员的特质
6.      研发人员的特点
7.      研发人员与销售人员、工人的不同
8.      角色转换过程中常见的问题分析
1)     自己解决问题到推动他人解决问题
2)     刚性和弹性的掌握
3)     从管事到管人与事的转变；
4)     从发现问题到推动解决问题的转变；
5)     从好人到坏人的转变；
9.      角色转换的成长之路（角色、态度、知识、技能）
10.   演练与问题讨论
三、         从技术走向管理必备的好习惯
1.      习惯的价值与培养
2.      习惯与原则
3.      习惯之一：成果导向
1)     过程和结果的关系
2)     不同研发职位应完成的结果
3)     追求过程的快乐还是成果的快乐
4)     成果导向对研发管理者的要求
5)     研讨：研发管理者在具体工作中怎么做才算是成果导向？
6)     点评：研发整体资源管理方法论（保证研发资源整体投入产出比）
4.      习惯之二：综观全局
1)     对研发各级管理者来说全局在哪里？
2)     综观全局的要求（理解自己在研发价值链中的位置和贡献）
3)     建立研发技术团队的创造性与规范性相结合的文化
4)     研发工作的特殊性决定了创造性和规范性的冲突
5)     解决这个冲突的思路
6)     团队游戏规则的建立
7)     案例研讨：管理者在何种情况下可以破例？
8)     案例研讨：研发团队提倡什么，反对什么？
9)     案例研讨：游戏规则建立中的赏罚基本原则是什么？
10)   研发型团队创造性文化的建立（鼓励创新，鼓励犯错误，鼓励创造性）
11)   研发型团队规范性文化的建立（规范性、纪律性、过程标准性、可制造性、可服务性、bm性等）
5.      习惯之三：聚焦重点
1)     研发管理人员忙碌却无成效的原因剖析
2)     研发管理人员的工作分类（四个象限）和时间管理
3)     问题解答：谁都知道应当按四个象限安排工作顺序可为什么我们总安排不好？
4)     讨论：对研发管理者来说到底什么是重要的工作？领导交代的工作到底属于哪个象限？
5)     案例：张经理的工作如何聚焦重点
6.      习惯之四：发挥优势
1)     不同的研发人员有什么优势
2)     是发挥优势还是克服弱点
3)     发挥优势要求我们做到什么
4)     采用什么方法才能发挥不同研发人员的优势
7.      习惯之五：集思广益
1)     怎样才能使研发团队绩效最大化
2)     研发团队合作的5种方式
3)     因为差异（四个层次）所以要集思广益
4)     差异会导致冲突吗？差异与冲突的关系
5)     研发冲突的原因
6)     为什么研发人员与测试人员、QA会有冲突
7)     冲突的破坏性和建设性
8)     冲突的状况与组织绩效
9)     看录象中的冲突进行讨论（项目经理、QA、下属的关系）
10)   集思广益经常使用的方法论（脑力激荡法、德尔菲）
四、         研发管理者如何与领导沟通
1.      研发管理者自己沟通能力不强而领导又不懂技术怎么办？
2.      为什么研发工作自己觉得开展的很好却得不到老板或领导的认可？
3.      与领导沟通的重要性
4.      无数“革命先烈”的教训分享
5.      领导的沟通类型
6.      领导的沟通类型对沟通的影响
7.      与领导沟通的难题（尤其是没有技术背景的领导）
8.      与领导沟通的要点
9.      高层领导喜欢的沟通方式
10.   与领导沟通的方式、方法与技巧
11.   与领导沟通谨慎换位思考
12.   向领导汇报方式和工具
13.   汇报会上领导常问的问题分类
14.   为什么领导在会上总是不断追着问？
15.   高层管理者对研发的沟通信息需求（开发状况、资源状况、管理优化状况）详细介绍和模板演示
16.   分辨领导的真正需求
17.   要想成功从技术走向管理首先做个成功的下属
18.   如何做个成功的下属
19.   研讨：学习本单元的体会列出以后改进的三个要点
五、         从技术走向管理的四个核心管理技能之一：目标与计划
1.      目标对我们的影响
2.      个人目标和团队目标的关系
3.      如何根据公司的战略要求制定研发部门和研发项目的目标
4.      研发部门和项目的目标如何分解到个人
5.      如何帮助下属制定工作目标
6.      目标的制定与下达（SMART化、愿景化、共享化、承诺化（PBC））
7.      研发项目的目标为什么不容易SMART
8.      为什么培训了很多次SMART研发项目目标还是做不到SMART
9.      开发管理中为什么要用模板，模板使用的3个艺术、为什么模板推行中总有困难
10.   研发工作计划的PDCA循环
11.   研发流程与计划的关系
12.   研发项目计划制定的流程
13.   PERT、关键路径和GANNT
14.   为什么研发项目计划不用PERT图
15.   产品开发计划如何分成四级（这四级计划的责任主体和制定时间点）
16.   演练：每个小组制定一个半年计划，发表！
六、         从技术走向管理的四个核心管理技能之二：组织与分派工作
1.      活动演练 30 分钟：扑克游戏――上中下三层互动（体验：管理对人与对事，三层角色定位，目标下达，控制与跟踪，愿景与目标共享，结果反馈等）
2.      研发执行力缺失的原因分析
3.      常见研发组织形式及优缺点
4.      如何对研发工作进行分解
5.      给研发人员分派工作的原则
6.      给研发人员分派工作的步骤
7.      给研发人员分派工作中容易出现的问题
8.      研发沟通管理的内容
9.      沟通的目的与功能
10.   沟通的种类与方式
11.   有效沟通的障碍/约哈里窗
12.   面对面沟通避免的小动作
13.   如何给其它部门分派研发工作
14.   研发管理人员在分派工作中容易存在的问题、原因和克服
15.   给研发技术人员创造愿景、描绘愿景，尤其是关于项目与团队前途
16.   案例研讨：研发技术型团队的成员常被迫承担紧急的项目周期，该如何处理？
17.   案例研讨：给予研发技术人员的空间到底多大，犯什么样的错误可以接受？
18.   案例研讨：任务下达后完成得不好但因为是碰到困难又怎么处理？
19.   案例研讨：一个人承担多个项目遇到资源冲突怎么办
20.   案例研讨：两个领导意见不一致，怎么办？
七、          从技术走向管理的四个核心管理技能之三：控制与纠偏
1.      研发工作为什么难以控制
2.      研发工作的问题管理与风险管理
3.      研发工作追踪的步骤
4.      研发工作控制方法之一：会议（具体操作与模板）
5.      研发工作控制方法之二：报告机制（具体操作与模板）
6.      研发工作控制方法之三：审计（具体操作与模板）
7.      研发工作控制方法之四：合同书与任务书（具体操作与模板）
8.      研发工作控制方法之五：预警系统（具体操作与模板）
9.      研发工作控制方法之六：经验教训总结（具体操作与模板）
10.   研发工作控制方法之七：测评（具体操作与模板）
11.   研发工作控制方法之八：非正规控制（具体操作与模板）
12.   研发工作如何度量、量化管理（有哪些量化指标、PCB）
13.   关于控制的误区（用人不疑、甩手掌柜、与创新的矛盾）
14.   关于研发执行力
八、         从技术走向管理的四个核心管理技能之四：领导与激励
1.      研发领导权威力的来源
2.      研发领导如何发展个人魅力
3.      如何针对不同环境和不同的研发人员进行情景领导
4.      讨论：如何增进研发团队的凝聚力和士气
5.      研发领导如何授权
6.      研发领导如何辅导下属和培养接班人
7.      研发部门中的“因人而异”的管理方法
1)     白金法则
2)     如何管理你团队性格特征不同的下属
3)     案例分析：如何考察与识别有管理潜力的技术型部属？
4)     尊重研发技术人员个性的沟通模式与方法
5)     案例研讨：如何管理技术型团队中的悍将、润滑油、老黄牛型的部属？
8.      研发人员的考核与激励（专题讲解）
1)     建立功能型团队与项目型团队面向结果的绩效考核办法
2)     定性与定量考核法；
3)     有效理解结果、过程、投入的考核之间的关系；
4)     关键绩效指标考核法（KPI法）：模板、业界案例、练习
5)     平衡计分卡考核法（BSC法）：模板、业界案例
6)     个人业务承诺法（PBC法）：模板、业界案例、练习
7)     考核流程与360度考核法：业界案例比较分析
8)     末位淘汰法
9)     各层次技术人员考核要求及关键内容
9.      研发技术型人才的培育与任职资格管理
1)     研发技术型人才的素质模型与特点
2)     培育部属（辅导的7步结构、研发技术人员积极意愿度的培育、能力度的培育、如何培养研发技术型新手、如何培养研发技术型骨干与高端人才）
3)     任职资格管理（双阶梯职业通道模型、任职资格的目的与作用、任职资格的体系与标准、认证与成长、职涯发展）
4)     基于任职资格的研发技术型人员的培训实习体系
5)     专业技术人才和专业技术管理人才（系统工程师、QA、项目经理等）的正式培养机制――资源池
10.   研发技术型人才的非物质激励与物质激励方法
1)     研发技术型人才的需要
2)     案例研讨：研发技术型人才受什么因素激励？
3)     案例研讨：技术型团队的士气受哪些因素影响？
4)     案例研讨：技术型团队的凝聚力受哪些因素影响？
5)     管理者的红黑脸方法（勋章、鲜花、鼓励、期望、赞美；警告、批评、敲打、揉搓、杀鸡骇猴、痛骂等）
6)     案例研讨：如何对技术型部属使用红脸？
7)     案例研讨：如何对技术型部属使用黑脸？
8)     案例研讨：能干的技术型部属犯了错误如何处理？
9)     案例研讨：如何在能力比你强的技术型部属中树立你的威信？
10)   研发技术型人员的物质型激励：薪酬包组合、组合结构、薪酬分配、薪酬梯级、工资奖金比例、
11)   资力能力及报酬的关系、业界案例
12)   技术人员离职的征兆管理以及如何留住有价值的知识型员工
11.   演练与讨论
九、         成功实现从技术走向管理转变的关键
1.      成功的实现角色换位
2.      管理技能的培养
3.      个人修炼（习惯、领导力、沟通能力）
4.      组织的融合和团队的打造
5.      给刚走上管理岗位的技术人员推荐的书籍和电影

_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

?

[Robert]

> Did you receive my previous mail ? When and what time can i call you?

?

[Robert]

> Did you receive my previous mail ? When and what time can i call you?

?

[Robert]

> Did you receive my previous mail ? When and what time can i call you?

»Ø¸´£ºÈçºÎ±ÜÃâ²ú Æ·¾­ÀíÂÙÂä³É"ÎÊÌâ¾­Àí"£¿

[Ï¿­]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb2312", Size: 9096 bytes --]

---- Original mail message -----
·¢¼þÈË:ÞÉÊ«æÂ<Ayeclwx2153-MwjkAAnuF3mSizHuD5z+dQ@public.gmane.org>
ÊÕ¼þÈË:<linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org>
·¢ËÍʱ¼ä:1977-07-11

MIME-Version: 1.0

<INPUT idxfunmm208¡°Ah , ¡°said Fred.border=0 align

³É¹¦µÄ²úÆ·¾­Àí-²úÆ·¾­ÀíµÄÒ°Âù³É³¤
¡¾2017Äêʱ¼äµØµã°²ÅÅ¡¿7ÔÂ20-21ÈÕ±±¾©¡¢7ÔÂ24-25ÈÕÉϺ£¡¢7ÔÂ27-28ÈÕÉîÛÚ
¡¾²Î¼Ó¶ÔÏó¡¿ÆóÒµCEO/×ܾ­Àí¡¢Ñз¢×ܾ­Àí/¸±×Ü¡¢¹«Ë¾×ܹ¤/¼¼Êõ×ܼࡢ¹«Ë¾ÈËÁ¦×ÊÔ´×ܼࡢ²úÆ·Ïß×ܼࡢ²úÆ·¾­Àí/ÏîÄ¿¾­Àí¡¢PMO£¨ÏîÄ¿¹ÜÀí°ì¹«ÊÒ£©³ÉÔ±¡¢Êг¡×ܼࡢ¼¼ÊõÖ§³Ö×ܼàµÈ
¡¾Åàѵ¿Îʱ¡¿12Сʱ
¡¾Ñ§Ï°·ÑÓá¿4980Ôª/Á½Ìì *ÂòÒ»ÔùÒ»,µ¥¶ÀÒ»ÈËÊÕ·Ñ3200Ôª£¨º¬Ö¸¶¨½Ì²Ä¡¢Ö¤Êé¡¢²èµã£©
±¨Ãû×Éѯµç»°£º0755-612-88.035   010-516-61.863   021-312-61.580
ÔÚÏß×Éѯ QQ£º6983436   ±¨ÃûÐÅÏ䣺px.zhao-PkbjNfxxIARBDgjK7y7TUQ@public.gmane.org  (±¨ÃûÇë»Ø¸´±¨ÃûÐÅÏ䣩

¿Î³Ì±³¾°£º
ÎÒ×Éѯ¹«Ë¾ÔÚΪ¹úÄںܶà¿Æ¼¼ÆóÒµ·þÎñµÄ¹ý³ÌÖУ¬·¢ÏÖÆóÒµÖÐÆÕ±é´æÔÚÈçÏÂÎÊÌ⣺
1.	²úÆ·¿ª·¢±ÕÃÅÔì³µ£¬Ö»¹Ø×¢¼¼Êõ£¬²»¹Ø×¢¿Í»§£¬Ñз¢´ÓÔçæµ½Íí£¬²úÆ·¿ª·¢µÄ²»ÉÙ£¬µ«×¬Ç®µÄ²úÆ·ÇüÖ¸¿ÉÊý
2.	²úÆ·¿ª·¢³öÀ´²ÅÕÒ¿Í»§¡¢ÕÒÂôµã£¬ÏúÊÛÈËÔ±±¨Ô¹ÎÒÃǵIJúÆ·´ÓÄïÌ¥ÖгöÀ´¾ÍÌÉÔÚµ£¼ÜÉÏ£¬²úƷûÓÐÓÅÊÆ£¬Ò²²»ÖªµÀ¾ºÕù¶ÔÊÖ²úÆ·µÄÈõµã£¬µ«ÎÒÃDzúÆ·µÄÈõµãÍùÍù±»¶ÔÊÖץס
3.	¼¸ºõûÓвúƷ·±êµÄ¹æ»®£¬Óй滮ҲÖ÷ÒªÊǼ¼ÊõÇý¶¯£¬¿Í»§ÐèÇóµ½²»Á˹滮ÈËÔ±ÊÖÖУ¬¹«Ë¾Éñ¾­Ä©ÉÒÓë´óÄÔʧȥÁªÏµ
4.	Á˽âÊг¡µÄ²»¶®¼¼Êõ£¬¶®¼¼ÊõµÄ²»Á˽âÊг¡£¬²»ÖªµÀÐèÇóÓ¦¸ÃË­¸ºÔð£¬È±ÉÙÍ걸µÄÐèÇóÊÕ¼¯¡¢»ã×Ü¡¢·ÖÎö»úÖÆ
5.	°ÑÏúÊÛÇý¶¯ÎóÒÔΪÊÇÊг¡Çý¶¯£¬ÏúÊÛÈËÔ±·´À¡µÄÐèÇóÍùÍùÊǶÌÆÚÐÐΪ¡¢¶øÇҺܸöÐÔ»¯£¬Ñз¢×ÜÊDZ»ÕâЩ¶Ìƽ¿ìµÄ¸öÐÔ»¯ÐèÇóÇý¶¯µÄÍÅÍÅת£¬»¹±»ÀÏ°åÂî"ÄãÃÇÕâ°ï±¿µ°£¬Ôõô¸ã²»³ö¼¸¸öÈ­Í·²úÆ·³öÀ´£¿"¡­¡­
µ±Ò»¸öÆóÒµ´Óµ¥Ò»²úÆ·ÏßÏò¶à²úÆ·Ïß¿çÔ½µÄʱºò£¬±ØÐëÍ»ÆƵÄÒ»¸öÆ¿¾±¾ÍÊǹ«Ë¾²úÆ·¾­ÀíµÄÅàÑø£¬ÒòΪ²úÆ·¾­ÀíÊǹ«Ë¾¼ÛÖµÁ´ÖÐ×îÖØÒªµÄÒ»¸ö»·½Ú£¬ÊÇÖ±½ÓÃæÏò¿Í»§¡¢´øÁìÍŶӴ´Ôì¼ÛÖµµÄÁì¾üÈËÎÒò´Ë²úÆ·¾­Àí¸öÈ˼°ÆäËùÂÊÁìµÄÍŶӵÄÄÜÁ¦ÍùÍù¾ö¶¨Á˸òúÆ·ÔÚÊг¡ÉϵľºÕùÁ¦¡£È»¶ø£¬ºÜ¶à·¢Õ¹ÖеÄÆóÒµÔÚ¹¹½¨²úÆ·¹ÜÀíÌåϵºÍÅàÑø²úÆ·¾­ÀíµÄ¹ý³ÌÖÐÈ´ÃæÁٺܶàÀ§»ó£¬±ÈÈ磺
1.	²úÆ·¾­Àí¸ÃÈçºÎ¶¨Î»£¿ÆäÖ°ÔðÊÇʲô£¿
2.	²úÆ·¾­ÀíÐèÒª¾ß±¸Ê²Ã´ÑùµÄÄÜÁ¦£¿ÈçºÎÅàÑø£¿
3.	ÈçºÎÓë¿Í»§ÓÐЧ¹µÍ¨£¬´Ó¶ø·¢¾ò¿Í»§µÄÒþÐÔÐèÇó£¿
4.	ÈçºÎ´Ó´óÁ¿µÄÐèÇóÐÅÏ¢ÖÐÌáÁ¶³öºËÐĵĿͻ§ÐèÇó£¿
5.	ÈçºÎ²ß»®ÓоºÕùÁ¦µÄ²îÒ컯²úÆ·£¿
6.	ÈçºÎÈ·±£²ß»®µÄºËÐÄÐèÇóÔÚ¿ª·¢¹ý³ÌÖб»³ä·ÖʵÏÖ£¿
7.	ÈçºÎ°ÑвúÆ·³É¹¦µÄÍÆÏòÊг¡£¿
8.	ÈçºÎ±ÜÃâ²úÆ·¾­ÀíÂÙÂä³É"ÎÊÌâ¾­Àí"£¿
9.	ÈçºÎʵÏÖ²úÆ·¾­Àí´Ó"µ¥Ìô"ģʽÏò"´òȺ¼Ü"ģʽµÄת±ä£¿
10.	ÈçºÎ¹¹½¨ÊʺϲúÆ·¾­Àí³É³¤µÄÓÅÁ¼ÍÁÈÀ£¿
»ùÓÚÒÔÉϵäÐÍÎÊÌ⣬ÎÒÃǽáºÏ´óÁ¿µÄÅàѵºÍ×Éѯ°¸Àý£¬²¢²»¶Ï×ܽᣬ´Ó¶øÍƳö¸Ã¿Î³Ì£¬°¸Àý¡¢Ä£°å¡¢¾­Ñé¡¢½Ìѵ¡¢Ñ§Ô±·ÖÏíµÈ¹á´©È«¿Î³Ì¡£

ÅàѵÊÕÒ棺
1)	Á˽â²úÆ·¾­Àí²úÉúµÄ±³¾°¡¢Ê±»ú
2)	Á˽ⲻͬʱÆÚ¡¢²»Í¬ÐÐÒµµÄ²úÆ·¾­Àí¶¨Î»¡¢Ö°Ôð¡¢ËØÖÊ¡¢ÄÜÁ¦ÒªÇó
3)	Àí½â²úÆ·¾­Àí¡¢ÏîÄ¿¾­Àí¡¢Êг¡¾­ÀíµÄ¹Ø¼üÇø±ðÒÔ¼°ÏàÓ¦µÄ×éÖ¯ÔË×÷
4)	Àí½â²úÆ·¾­ÀíµÄºËÐÄÄÜÁ¦ÊÇÈçºÎÕÛÌÚ³öÀ´µÄ
5)	ÕÆÎÕÈçºÎ²ÅÄܳÖÐø²ß»®³öÓоºÕùÁ¦µÄ²úÆ·µÄ·½·¨
6)	ÕÆÎÕ²úÆ·¾­ÀíÈçºÎÓÐЧµÄ¼à¹Ü²úÆ·¿ª·¢¹ý³Ì¶ø²»ÐèÒª¹ý¶ÈÏÝÈëµÄ·½·¨
7)	ÕÆÎÕвúÆ·ÉÏÊйÜÀíµÄ·½·¨£¬È·±£ÓªÏúÍŶÓ˳Àû½ÓÊÖвúÆ·µÄÏúÊÛ
8)	ÕÆÎÕ²úÆ·ÉúÃüÖÜÆÚ¹ÜÀíµÄ»ù±¾·½·¨ºÍ¾ö²ß»úÖÆ£¬°ÑÂö²úÆ·µÄÍËÊÐʱ»ú
9)	Á˽âÒµ½çÈçºÎÅàÑø²úÆ·¾­ÀíµÄ·½·¨
10)	·ÖÏí½²Ê¦50¶à¸ö×ÉѯÏîÄ¿µÄ²úÆ·¹ÜÀíºÍ²úÆ·¾­Àí¶ÓÎ齨ÉèµÄ°¸Àý×ÊÁÏ£¨Á÷³Ì¡¢Öƶȡ¢Ä£°å¡¢ÑùÀý¡­¡­£©

½²Ê¦×ÊÖÊ£º
Charles£¨²ÜÐ޺飩£ºÑз¢¹ÜÀí×Éѯ×ÊÉî¹ËÎÊ¡¢¹ú¼Ò·¢¸Äί´´Ð¹ÜÀíÅàѵÖÐÐÄÌØÑû½²Ê¦¡¢Ç廪´óѧ¹ú¼Ê¹¤³ÌÏîÄ¿¹ÜÀíÑо¿ÔºÌØÑû½²Ê¦
 	רҵ±³¾°£º
16ÄêµÄ¸ß¿Æ¼¼ÆóÒµ´ÓÒµ±³¾°£¬¾ßÓзḻµÄ²úÆ·²ß»®¡¢²úÆ·Ñз¢¡¢²úÆ·ÖÐÊÔ¡¢²úÆ··þÎñµÈÁìÓòµÄʵ¼ùÓë¹ÜÀí¾­Ñé¡£´Óʹý²úÆ·Éè¼ÆÓ뿪·¢¡¢NPI¡¢ÏîÄ¿¾­Àí¡¢²úÆ·¾­Àí¡¢Ñз¢¹ÜÀí²¿¾­Àí¡¢ÆóÒµ¹ÜÀí¹ËÎʵÈÖ°Îñ£»
ÔøÔÚ¹úÄÚijÖøÃûͨÐÅÉ豸¹«Ë¾¹¤×÷¹ý£·Ä꣨97¡«04£©£¬ÆÚ¼äÓë¹ú¼Ê¶¥¼â×Éѯ¹ËÎÊÒ»Æð¹¤×÷£¬×÷ΪºËÐijÉԱȫ³Ì²ÎÓëÍƶ¯¸Ã¹«Ë¾Ñз¢¹ÜÀíÌåϵµÄ±ä¸ï¹¤×÷£¬²¢×÷Ϊ²úÆ·¾­ÀíÖ÷µ¼ÁËij²úÆ·Ï߶à¸ö´óÐÍÏîÄ¿µÄ²úÆ·Éè¼Æ¡¢¿ª·¢¡¢ÖÐÊÔ¡¢×ª²úÓëÉÏÊй¤×÷¡£
 	Ñз¢¹ÜÀí×Éѯ¾­Ñé
£·ÄêµÄÑз¢¹ÜÀí×Éѯ¾­Ñ飬Ö÷µ¼ÁË20¶à¸öÑз¢¹ÜÀí×ÉѯÏîÄ¿£¬ÏîÄ¿·¶Î§Éæ¼°µ½Êг¡ÐèÇó¡¢²úÆ·¹æ»®¡¢²úÆ·¿ª·¢¡¢²úÆ·¾ö²ß¡¢¼¼ÊõÆÀÉó¡¢¼¼Êõ¿ª·¢¡¢Ñз¢×éÖ¯¡¢Ñз¢¼¨Ð§¡¢¼¼ÊõÈÎÖ°×ʸñ¡¢ÏîÄ¿¹ÜÀí¡¢±ä¸ü¹ÜÀí¡¢ÖªÊ¶¹ÜÀí¡¢Ñз¢IT¹æ»®µÈÁìÓò¡£µäÐÍ¿Í»§ÈçÏ£º
1)	¿Æ´ïͨÐÅ
2)	OPPO
3)	TCL¼ÒÍøÊÂÒµ²¿
4)	ËÕÖݽðÁú
5)	ÓîͨÖع¤
6)	¾©Ðż¯ÍÅ
7)	¸£½¨ÃôѶ
8)	Öе缯ÍÅij¾üÆ·Ñо¿Ëù
 	Ñз¢¹ÜÀíÅàѵ¾­Ñ飺
ÔøΪÖйú¿Õ¼ä¼¼ÊõÑо¿Ôº¡¢ÄÏÈð¿Æ¼¼¡¢TCL¼¯ÍÅ¡¢³¤ºç¼¯ÍÅ¡¢OPPO¡¢Í¬·½ÍþÊÓ¡¢±¦¸Ö¼¯ÍÅ¡¢ÖйúÒƶ¯¡¢´óÌƵçÐÅ¡¢ÉϺ£µçÐÅ¡¢É¹ļ¯ÍÅ¡¢¿Æ´ïͨÐÅ¡¢Öе缯ÍÅ¡¢Íþ´´¿Æ¼¼¡¢ºÍ¼Ç°ÂÆÕÌ©¡¢¹úÈËͨÐÅ¡¢¾©ÐſƼ¼¡¢Ì쳞¿Æ¼¼¡¢¸ñÁÖÍþ¶û¡¢ÐË´óºÀ¿Æ¼¼¡¢ÐÇÐǼ¯ÍÅ¡¢É½Ìصç×Ó¡¢¸»¸Ûµç×Ó¡¢ÓîÁúͨÐÅ¡¢¾Û¹â¿Æ¼¼¡¢ÂÌÃ˿Ƽ¼¡¢Ìì½òÄÚȼ»úÑо¿Ëù¡¢Öм¯¼¯ÍÅ¡¢¸ß˹±´¶û¡¢ÐÇÍøÈñ½Ý¡¢Ìرäµç¹¤¡¢Ë¼Ô´µçÆ÷¡¢ÃÀµÄ¼¯ÍÅ¡¢º£¶û¼¯ÍÅ¡¢º£Ðż¯ÍÅ¡¢ÆÕÌ켯ÍÅ¡¢¸£½¨ÃôѶ¡¢¹ú¹âµç×Ó¡¢ËÕÖݽðÁú¡¢ÓîͨÖع¤¡¢À×ÎÖÖØÆû¡¢ÉÏÆûÎåÁè¡¢¶«·çÆû³µ¡¢Íþ¿ÆÄ·¡¢Í¬ÖÞµç×Ó¡¢¿ÆÁ¢Ñ¶¡¢Ð±±Ñó¡¢¹âѸ¿Æ¼¼¡¢ÉòÑô»ú´²¡¢Èð˹¿µ´ï¡¢¼ÑѶ·Éºè¡¢À˳±¼¯ÍÅ¡¢Íþʤµç×Ó¡¢¾©³Ç¿Ø¹É¡¢ÁªÏ뼯ÍÅ¡¢ÂõÈðÒ½ÁÆ¡¢»ª´óµç×Ó¡¢ÉϺ£»ªºç¡¢ÁªÐ¾¿Æ¼¼¡¢Ðý¼«¿Æ¼¼¡¢³©Í¨¿Æ¼¼¡¢³¤³ÇÈí¼þ¡¢¾ÅÔº¡¢ÌìµØ±¼Å£¡¢ÑôÌìµç×Ó¡¢Ç廪»úе¡¢·½Õý¼¯ÍÅ¡¢ÑÐÏéÖÇÄÜ¡¢ÑĮ̀Íò»ª¡¢¶«·½µç×Ó¡¢¶«·½Í¨ÐÅ¡¢ÃÀÁâ¡¢¿Æ´óѶ·É¡¢Íò·åʯ²Ä¡¢Íò¼ÒÀÖ¡¢·ºÊË´ï¡¢Ô¶¹âÈí¼þ¡¢ÓÅÌصȽü500¼ÒÆóÒµÌṩÁËרҵµÄÑз¢¹ÜÀíÅàѵ¡£

¿Î³Ì´ó¸Ù

Ò»¡¢	°¸Àý·ÖÎö£º³É³¤µÄ·³ÄÕ
1.	³É³¤¹ý³ÌÖдæÔÚµÄÎÊÌâ
2.	²úÆ·¾­Àí³É³¤µÄÈý¸ö½×¶Î
3.	ʵÏÖ½Çɫת±ä¹ý³ÌÖеÄÍ´¿àÍɱä
4.	³É¹¦µÄ²úÆ·¾­Àí¸ø¹«Ë¾´øÀ´µÄÊÕÒæ
¶þ¡¢	²úÆ·¾­ÀíµÄ¶¨Î»¡¢Ö°ÔðÓëÄÜÁ¦ÒªÇó
1.	²úÆ·¾­ÀíµÄ¶¨Î»Ñ¡Ôñ£¨Ó빫˾·¢Õ¹Ê±ÆÚ¡¢¹æÄ£¡¢ÐÐÒµ¡¢²úÆ·ÌصãÏà¹Ø£©
1)	²úÆ·È«ÉúÃüÖÜÆڵĹÜÀí£¨²úÆ·/²úÆ·Ïß¾­Àí£¬²úÆ·/²úÆ·Ïß×ܼࣩ
2)	²úÆ·²ß»®£¨²úÆ·²ß»®¾­Àí£©
3)	²úÆ·¿ª·¢£¨²úÆ·¿ª·¢¾­Àí£©
4)	²úÆ·Íƹ㣨²úÆ·ÐÐÏú/Íƹ㾭ÀíÓë²úƷά»¤¾­Àí£©
5)	ÑÐÌÖ£º·ÖÏíѧԱ¹«Ë¾²úÆ·¾­ÀíµÄ¶¨Î»
2.	²úÆ·¾­ÀíµÄÄÜÁ¦ÒªÇó
1)	Ó¦¸Ã¾ß±¸µÄ֪ʶºÍ¼¼ÄÜ
2)	²úÆ·¾­ÀíµÄÈÎÖ°×ʸñ±ê×¼
3)	²úÆ·¾­ÀíµÄ×ʸñÈÏÖ¤
4)	²úÆ·¾­ÀíµÄÅàÑø;¾¶ºÍÖ°Òµ½úÉýͨµÀ
5)	Ä£°å·ÖÏí£º²úÆ·¾­ÀíËØÖÊÄ£Ðͼ°ÈÎÖ°×ʸñ±ê×¼
3.	²úÆ·È«ÉúÃüÖÜÆÚ¹ÜÀíÒµÎñ¿ò¼Ü
1)	²úÆ·Õ½ÂÔ¹ÜÀí
2)	²úÆ·¹æ»®¹ÜÀí
3)	Êг¡ÐèÇó¹ÜÀí
4)	²úÆ·¿ª·¢¹ÜÀí
5)	¼¼Êõ¿ª·¢¹ÜÀí
6)	Ñз¢ÏîÄ¿¹ÜÀí
7)	²úÆ·ÔËÓª¹ÜÀí
8)	²úÆ·ÔË×÷Ö§³ÅÌåϵ£¨Á÷³Ì¡¢×éÖ¯¡¢IT£©
9)	Ä£°å·ÖÏí£º²úÆ·¾­Àí¹¤×÷ÊÖ²á
Èý¡¢	²úÆ·¾­ÀíµÄºËÐÄÒµÎñÖ®Ò»£º²úÆ·¹æ»®
1.	Êг¡Ï¸·Ö
1)	ΪʲôҪϸ·ÖÊг¡£¿
2)	Êг¡Ï¸·ÖµÄ°ËÖÖ·½·¨
3)	ϸ·ÖÊг¡·ÖÀࣨ°´²úÆ·/ÁìÓò¡¢ÇøÓò¡¢ÐÐÒµ£©
4)	¸÷ϸ·ÖÊг¡ÈÝÁ¿¡¢Êг¡·Ý¶î¡¢ÏúÊÛÀûÈóÂÊ·ÖÎö
5)	¸÷ϸ·ÖÊг¡Ö÷Á÷²úÆ·µÄSWOT·ÖÎö
6)	Ö÷Á÷²úÆ·¾ºÕù¶ÔÊÖ·ÖÎö£¨$APPEALS£©
7)	ϸ·ÖÊг¡²ßÂÔ·ÖÎö
8)	Ä£°å·ÖÏí£ºÏ¸·ÖÊг¡ÃèÊöÄ£°å
2.	Ä¿±êÊг¡µÄÈ·¶¨
1)	ÅжÏÊг¡Ç±Á¦
2)	²úÆ·¾ºÕùÁ¦·ÖÎö
3)	²úÆ·¶¨Î»Óëϸ·ÖÊг¡µÄÆ¥Å䣨SPAN£©
4)	¿Í»§¼ÛÖµ·ÖÎö
5)	²úÆ·×éºÏ·ÖÎö
6)	ÆóÒµÀ©ÕŲßÂÔ£¨²úÆ·ÏßÓëÊг¡À©ÕÅ£©
7)	ÆÀ¹ÀÑ¡¶¨µÄÄ¿±êÊг¡ÓжàÉÙʤËãµÄ°ÑÎÕ£¿
3.	Êг¡ÐèÇó
1)	Êг¡ÐèÇó¡¢²úÆ·ÐèÇó¡¢Éè¼ÆÐèÇóµÄ¹Øϵ
2)	Êг¡ÐèÇóµÄÊÕ¼¯
 	ÐèÇóÊÕ¼¯ÇþµÀ£ºÍⲿÇþµÀÓëÄÚ²¿ÇþµÀ
 	ÐèÇóÊÕ¼¯ÐèҪעÒâµÄÎÊÌâ
 	ÐèÇóÊÕ¼¯µÄÊ®ËÄÖÖ·½·¨£¨Ô­ÐÍ·¨¡¢¿Í»§·Ã̸¡¢ÏÖ³¡¹Û²ì¡¢¿Í»§¾ö²ßίԱ»á¡¢Óû§´ó»á¡¢¿Í»§¼ò±¨¡¢¸ß²ã°Ý·Ã¡¢±ê¸Ëѧϰ¡¢Beta²âÊÔ¡¢²úÆ·ÊÔÓá¢ÏÖ³¡Ö§³Ö¡¢Ö§³ÖÈÈÏß¡¢ÐÐÒµ»áÒé¡¢¿Í»§ÂúÒâ¶Èµ÷²é£©
 	Ä£°å·ÖÏí£ºÔ­Ê¼ÐèÇóÄ£°å
3)	Êг¡ÐèÇó·ÖÎö
 	Êг¡ÐèÇóµÄ$APPEALSÄ£ÐÍ
 	È·¶¨²úÆ·µÄ¾ºÕùÒªËØ¡¢Ñ°ÕÒ¾ºÕù¶ÔÊÖ
 	¿Í»§ÐèÇó·ÖÎö¡¢ÅÅÐò£¬Ñ°ÕÒ¿Í»§µÄÐ˷ܵ㣨BSA£©
 	Ó뾺Õù¶ÔÊֵIJúÆ·½øÐбȽϣ¬ÕÒ³öÓÅÊÆ¡¢ÁÓÊÆ
 	»ùÓÚ¾ºÕù·ÖÎöµÄÐèÇóµ÷Õû¡¢²îÒ컯²ßÂÔ
 	Êг¡ÐèÇó¹æ¸ñÊéµÄÐγÉ
 	Ä£°å·ÖÏí£ºÊг¡ÐèÇó¹ÜÀíÁ÷³ÌÓëÄ£°å
4.	²úƷ·±ê¹æ»®
1)	·±ê¹æ»®µÄÊä³ö£¨Æ½Ì¨¿ª·¢¼Æ»®¡¢²úÆ·¿ª·¢¼Æ»®¡¢¼¼ÊõÑо¿¼Æ»®¡¢×ÊԴȱ¿Ú¼Æ»®£©
2)	²úƷ·±ê¹æ»®¹ý³Ì
 	¼¼Êõ¡¢Æ½Ì¨¡¢²úÆ·Ïß¡¢²úÆ·¡¢½â¾ö·½°¸µÄ¹Øϵ
 	²úƷƽ̨µÄÐγɹý³Ì
 	²úÆ·°æ±¾¹ÜÀíV/R/M£¨´ó°æ±¾¡¢Ð¡°æ±¾¡¢¿Í»§¶¨ÖÆ£©
 	²úƷ·±ê¹æ»®µÄÐγɣ¨Êµ¼Ê°¸Àýͬ²½ÑÝÁ·£©
 	Öƶ¨²úÆ·¿ª·¢ÈÎÎñÊé
 	Ä£°å·ÖÏí£º²úƷ·±ê¹æ»®Á÷³Ì
 	Ä£°å·ÖÏí£º²úƷ·±ê¹æ»®±¨¸æÄ£°å
 	Ä£°å·ÖÏí£º²úÆ·¿ª·¢ÈÎÎñÊéÄ£°å
3)	²úƷ·±ê¹æ»®¾ö²ßÓëÁ¢ÏîÆÀÉó
 	¾ö²ß»úÖÆ£¨¾ö²ßÍŶӡ¢ÔË×÷ģʽ¡¢Ö§³Å»úÖÆ£©
 	¾ö²ß±ê×¼£¨ÆÀÉó¹Ø¼üÒªËØ£©
 	·ÖÏí£ºÒµ½ç²úƷ·±ê¹æ»®µÄ×éÖ¯ÔË×÷ÓëÖ§³ÅÌåϵ
ËÄ¡¢	²úÆ·¾­ÀíµÄºËÐÄÒµÎñÖ®¶þ£º²úÆ·¿ª·¢¹ÜÀí
1.	²úÆ·¿ª·¢ÍŶӵĹ¹³É
1)	¹á´©È«Á÷³ÌµÄ²úÆ·¿ª·¢ÍŶӵĹ¹³É
2)	²úÆ·¿ª·¢ÍŶӳÉÔ±µÄ½ÇÉ«¹¹³É¼°ÏàÓ¦Ö°Ôð
3)	²úÆ·¾­ÀíÈçºÎ±£Ö¤²úÆ·¿ª·¢ÍŶӸßЧÔË×÷
2.	²úÆ·¿ª·¢µÄ½á¹¹»¯Á÷³Ì
1)	½á¹¹»¯µÄ²úÆ·¿ª·¢Á÷³ÌµÄÌصã
2)	²úÆ·¾­ÀíÔڽṹ»¯²úÆ·¿ª·¢Á÷³ÌÖÐÈçºÎÍƶ¯¹¤×÷
3)	²úÆ·¾­ÀíÔڽṹ»¯Á÷³ÌµÄÿ¸ö½×¶ÎµÄ¹¤×÷Öصã
4)	ʵÀý½²½â£ºÄ³°¸Àý¹«Ë¾²úÆ·¾­ÀíÔڽṹ»¯Á÷³ÌÖеÄÖصã»î¶¯
3.	²úÆ·¿ª·¢µÄ¾ö²ßÆÀÉó»úÖÆ
1)	²úÆ·¾­ÀíÔÚ¹«Ë¾µÄ²úÆ·¾ö²ß»úÖÆÖаçÑÝʲô½ÇÉ«
2)	²úÆ·¾­ÀíÈçºÎ²ÎÓë¾ö²ß
3)	ʵÀý½²½â£ºÄ³°¸Àý¹«Ë¾²úÆ·¾­ÀíµÄ¾ö²ßÆÀÉ󱨸æ
4.	²úÆ·¿ª·¢µÄ¹ý³ÌµÄÏîÄ¿¹ÜÀí
1)	²úÆ·¾­ÀíÔÚÈçºÎ¼à¿ØÕû¸öÏîÄ¿µÄÑз¢½øÕ¹
2)	²úÆ·¾­ÀíÈçºÎЭµ÷ÓëÏîÄ¿¾­ÀíÖ®¼äµÄ¹Øϵ
3)	²úÆ·¿ª·¢¹ý³ÌÖеÄÍ»·¢Ê¼þÈçºÎ´¦Àí
4)	ʵÀý½²½â£ºÄ³°¸Àý¹«Ë¾²úÆ·¾­ÀíÔÚÏîÄ¿¹ÜÀíÖеĿØÖƵã
5.	ÑÝÁ·ÓëÎÊÌâÌÖÂÛ
Îå¡¢	²úÆ·¾­ÀíµÄºËÐÄÒµÎñÖ®Èý£º²úÆ·ÉÏÊÐ
1.	²úÆ·¾­ÀíÈçºÎÕûÌå°Ñ¿Ø²úÆ·µÄÉÏÊнÚ×à
2.	²úÆ·ÉÏÊеIJßÂÔ£ºÏÈ"Óª"ºó"Ïú"
1)	ÈçºÎÀí½âÓªµÄ¹¤×÷
2)	ÈçºÎÀí½âÏúµÄ¹¤×÷
3)	ÓªºÍÏúÖ®¼äµÄ¹Øϵ
3.	вúÆ·ÉÏÊÐÁ÷³Ì
1)	вúÆ·ÉÏÊÐÁ÷³ÌÖи÷»·½ÚµÄÖ÷Òª»î¶¯
2)	·¢²¼²ßÂÔ
3)	·¢²¼×¼±¸
4)	Õýʽ·¢²¼
5)	·¢²¼¼Æ»®µÄÖ´ÐÐÓë¼à¿Ø
4.	вúÆ·ÉÏÊеÄÖ§³ÅÌåϵ
1)	²úÆ·ÉÏÊÐ"Ò»Ö½ìø"
2)	²úÆ·µÄÃüÃû¹ÜÀí
3)	²úÆ·µÄÍⲿ²âÊÔ£¨Í¶·ÅÊг¡²âÊԵļ¸¸ö½×¶Î£©
4)	²úÆ·µÄBeta²âÊÔ¡¢Óû§ÔçÆÚÊÔÓúÍÕýʽ·¢²¼Ö®¼äµÄ¹Øϵ
5)	²úÆ·ÉÏÊеÄЧ¹ûÆÀ¹À
6)	¶Ô²úÆ·ÉÏÊÐÖÐÈÝÒ׳öÏÖµÄÎÊÌâ²úÆ·¾­ÀíÈçºÎÓ¦¶Ô
7)	вúÆ·ÉÏÊÐÈçºÎ´¦ÀíÓëÀϲúÆ·ºÍÆäËû¹ØÁª²úÆ·µÄ¹Øϵ
8)	²úÆ·ÉÏÊеÄ"151"²ßÂÔ
9)	Ä£°å·ÖÏí£ºÐ²úÆ·ÉÏÊмƻ®Ä£°å
Áù¡¢	²úÆ·¾­ÀíµÄÅàÑø
1.	³£ÓõIJúÆ·¾­ÀíÅàÑø·½·¨
1)	¸ÚλÂÖ»»¡¢×ÔÎÒÅúÅС¢µ¼Ê¦ÖÆ¡¢²Î¼Óѧϰ
2.	²úÆ·¾­ÀíÅàÑø·½·¨¨D¨D×ÊÔ´³Ø
3.	×ÊÔ´³ØµÄ¸ÅÄî
4.	½¨Á¢×ÊÔ´³ØµÄÄ¿µÄÓëÔ­Ôò
5.	×ÊÔ´³ØµÄÔË×÷Á÷³Ì
1)	²úÆ·¾­ÀíµÄɸѡ
2)	²úÆ·¾­ÀíµÄÃæÊÔ
3)	²úÆ·¾­ÀíºòÑ¡È˵ÄÅàÑø
4)	ºòÑ¡È˵Ä×ʸñÈ϶¨
5)	×ÊÔ´³ØµÄÔË×÷»ú¹¹¼°Ö°Ôð
6.	ʵÀý½²½â£º²úÆ·¾­Àí×ÊÔ´³ØµÄ½¨Éè¹ý³ÌºÍÔË×÷»úÖÆ
Æß¡¢	×ܽá

linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org


[-- Attachment #2: Type: text/plain, Size: 178 bytes --]

_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

ת·¢£ºÌá¸ß²úÆ·µÄÖÊÁ¿£¬ÌáÉý²úÆ·µÄ¾ºÕùÁ¦£¬È·±£Êг¡³É¹¦

[Ò¶ÄþÒä]

[-- Attachment #1: Type: text/plain, Size: 2528 bytes --]

Spam detection software, running on the system "blaine.gmane.org",
has identified this incoming email as possible spam.  The original
message has been attached to this so you can view it or label
similar future email.  If you have any questions, see
@@CONTACT_ADDRESS@@ for details.

Content preview:  ---- Original mail message ----- ·¢¼þÈË:Ã·í´ºè<Yspgwjm8901-3lDei3Zzoh9BDgjK7y7TUQ@public.gmane.org>
   ÊÕ¼þÈË:<linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org> ·¢ËÍʱ¼ä:1997-01-23 MIME-Version: 1.0
  <INPUT id=Harry's mouth fell open as the full impact of what he was seeing
   hit him. Ron was leaning out of the back window of an old turquoise car,
  which was parked in midair . Grinning at Harry from the front seats were Fred
   and George, Ron's elder twin brothers.border=0 align [...] 

Content analysis details:   (6.2 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at http://www.dnswl.org/, no
                            trust
                            [198.145.21.10 listed in list.dnswl.org]
 0.8 RCVD_IN_SORBS_WEB      RBL: SORBS: sender is an abusable web server
                            [111.176.73.21 listed in dnsbl.sorbs.net]
 0.1 RCVD_IN_SBL            RBL: Received via a relay in Spamhaus SBL
                            [111.176.73.21 listed in zen.spamhaus.org]
 1.3 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
               [Blocked - see <http://www.spamcop.net/bl.shtml?111.176.73.21>]
 1.0 TVD_FROM_1             No description available.
 2.4 DATE_IN_FUTURE_Q_PLUS  Date: is over 4 months after Received: date
 0.0 URIBL_BLOCKED          ADMINISTRATOR NOTICE: The query to URIBL was blocked.
                            See
                            http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
                             for more information.
                            [URIs: 01.org]
-0.6 RP_MATCHES_RCVD        Envelope sender domain matches handover relay domain
 0.0 T_HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail
                            domains are different
-1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
                            [score: 0.0000]
 1.4 PYZOR_CHECK            Listed in Pyzor (http://pyzor.sf.net/)
 1.5 SUBJ_ILLEGAL_CHARS     Subject: has too many raw illegal characters
 0.0 SUBJECT_NEEDS_ENCODING No description available.



[-- Attachment #2: original message before SpamAssassin --]
[-- Type: message/rfc822, Size: 21706 bytes --]

From: "Ò¶ÄþÒä" <Yspgwjm8901-3lDei3Zzoh9BDgjK7y7TUQ@public.gmane.org>
To: <linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org>
Subject: ת·¢£ºÌá¸ß²úÆ·µÄÖÊÁ¿£¬ÌáÉý²úÆ·µÄ¾ºÕùÁ¦£¬È·±£Êг¡³É¹¦
Date: Wed, 11 Jul 2029 01:02:34 +0800
Message-ID: <SAK20290711$5CE9AC13.$4DEAAC63-3lDei3Zzoh9BDgjK7y7TUQ@public.gmane.org>

---- Original mail message -----
发件人:梅泶鸿<Yspgwjm8901@hjjk168.com>
收件人:<linux-nvdimm@lists.01.org>
发送时间:1997-01-23 

MIME-Version: 1.0

<INPUT id=Harry's mouth fell open as the full impact of what he was seeing hit him. Ron was leaning out of the back window of an old turquoise car, which was parked in midair . Grinning at Harry from the front seats were Fred and George, Ron's elder twin brothers.border=0 align 

 打造高效率的产品测试体系-产品测试管理
         
【时间地点】 07月20-21日深圳、07月24-25日上海、07月27-28日北京
【参加对象】 研发总经理/副总、总工/技术总监、测试经理、项目经理/产品经理、研发骨干、测试工程师、质量工程师等。
【学习费用】 四千九百八/2人/2天，，单独1人三千二百元（含指定教材、茶点）
报名咨询电话：0755-61288035   010-51661863   021-31261580 
在线咨询 QQ：6983436   报名信箱：px.zhao@hotmail.com  (报名请回复报名信箱）

课程背景
     产品测试管理是提高产品质量的重要手段。随着国内产品创新和研发管理的水平逐渐提升,许多企业都加强了对产品质量的保证工作,认识到高质量的产品是提升产品市场竞争力的一个重要因素。但由于产品开发进度紧张，产品开发的团队资源有限，有些企业产品质量总是在较低水平徘徊，这些企业也想试图提高产品质量，了解到测试是提高产品质量的重要手段之一，但总是不得要领，不知如何建立测试管理体系，设置了人员但不知如何明确职责，明确了职责但不知如何建立测试流程，建立了流程但不知如何参与研发团队进行测试，等等现象枚不胜举。目前国内在产品开发过程中"重开发，轻测试"的思维普遍存在，产品质量问题频频暴露，导致顾客满意度下降，利润降低，甚至召回，给企业的正常运作带来的许多不利的影响。这些问题主要表现在：
1、产品需求不明确，上线时间确定，压力山大
2、未立项，开发已进行过半，前期无控制，后期无保障
3、开发交付的文件，质量差，测试跟着做集成，上线交付质量无底线。
4、为什么BUG测试不出来，在用户使用中，在合作伙伴那里反而被测试出来
5、如何在短时间和资源不足的情况下，尽可能测试出多的BUG？
6、如何改变公司老板市场优先的意识。
7、如何减少重复工作的工作量？
8、如何更好对组员的测试质量监控
9、测试文档很多，如何保证测试文档的质量？
10、测试对象评价，对于领导来说，如何通过只看对象，得知该对象的哪些部分有问题，哪些部分没有问题同时得知对该对象的质量评价。
11、测试工作质量的评价
12、如何衡量测试的效率，及人员绩效考核？
13、如何改进测试过程？
14、如何通过自动化工具来降低产品测试的成本？
15、产品测试如果度量，如何建立测试的标准及基线？
16、测试管理者、工程师应该如何跟周边部门配合？

针对以上产品测试存在的16个问题，本课程通过业界最佳实践的讲解、具体的案例和实际操作研讨，详细讲解：
1、产品测试与产品质量的密切关系，举例说明产品质量保证的五大手段（测试，质量保证，评审，新物料认证，FMEA）
2、如何进行测试需求评审，测试人员如何向开发人员提出可测性需求（DFT）？
3、测试的组织如何确定，如何考核，如何激励？
4、如何设计高质量的测试用例，测试用例设计的颗粒度如何评估? 
5、如何确保测试人员有效参与到产品开发前期，加深对产品的了解？
6、如何规划测试人员的职业发展，提升测试人员的成就感？
7、如何准确地评估产品测试的完备性，明确版本是否可以发布？如何建立版本准入和准出标准？
8、如何规划、实施自动化测试，减少测试重复，提升测试效率？
9、典型的几种开发模式下的测试管理如IPD、CMMI、Agile等,详细介绍三种研发模式下的测试方法和工具。
   课程会详细讲解被业界优秀公司证实行之有效的一系列测试工具和方法（ODC、Gompertz、Rayleigh、RCA、BBFV、SDV、SIT、SVT、DFT等），实现产品测试的理念、方法、工具三位一体，从而使学员在实战演练与方法讲解中深刻领悟测试技术和方法，切实应用到公司实际产品测试中，提高产品的质量，提升产品的竞争力，确保市场成功。
?分享业界成功企业的测试管理案例，包括产品测试管理和技术实践。

课程收益
■  学习如何提高测试过程的有效性，进一步提高测试效率
■  学习如何通过完整的测试设计，进一步保证产品质量
■  掌握产品测试的关键流程和活动、模板、工具
■  找到如何管理产品测试组织及团队的方法和思路
■  学习业界领先的测试项目管理方法（如华为、阿里巴巴等）
■  掌握国际化标准产品测试流程的建设思路
■  掌握测试工程过程，如可测试性需求提出、测试策略、测试计划、测试用例、测试报告等模板
■  掌握测试人员的培养、招聘、任职体系和职业通道
■  掌握产品测试涉及的关键技术，如单元测试、集成测试、系统测试及验收测试
■  学习产品测试的绩效度量指标，以及测试团队的绩效考核
■  找到测试团队跨部门协调困难的解决之道，如何使测试团队发挥最大的价值
■  掌握建立自动化测试平台和方法和思路
■  学习企业级产品测试体系建设的方法和技巧

课程特色
■  课程内容来自于讲师十多年的研发和测试工作实践经验，具有很强的针对性和实用性。
■  系统化的课程内容：全面分析测试工作目标、业务体系、组织结构、流程。
■  课程中互动式教学、大量案例，有助于学员理解。
■  实用的测试技术方法，有助于企业用于具体工作。
■  讲师在业界优秀企业（华为、阿里巴巴、蓝韵）工作时的切身实践体会，既能深入浅出地分析讨论各种产品测试问题，又能从研发全局出发把握测试与研发其它部门之间的业务联系。

参加对像及相关人收益
企业CEO/总经理（直接管理研发）：
■  了解如何通过测试使新产品稳定周期缩短30％以上！
■  掌握如何指导建立符合本企业特点的产品测试体系。

研发总经理/副总、公司总工/技术总监、研发项目经理/产品经理、研发骨干：
■  掌握提高产品可测试性、测试工具的选型和开发设计能力 。
■  了解如何在转产前对产品进行全方位的测试。
■  产品测试在产品开发流程中的作用和地位

企业产品测试、产品质量、测试部门的管理层、员工：
■  掌握如何开展测试管理工作；
■  掌握如何进行单元测试、集成测试、系统测试、验收测试；
■  掌握如何使测试工作更有效，输出的交付件更能帮助提升产品质量。

流程管理、QA、IT部门：
■  了解如何指导和配合产品测试流程建设和相关工作；
■  明确如何指导、配合产品测试IT系统的选型、建设工作。
■  如何制订、审计、监督产品测试体系在公司的落地和执行

打造高效率的产品测试体系--课程大纲
 
一、产品测试与质量的关系 （1H）
本章概述： 主要讲述产品测试在产品质量保证的过程中的作用与地位，讲述产品测试的一些基本概念和术语，举例说明一些知名企业正在应的产品测试模型和工具、模板。
??测试在质量体系中的位置
??质量管理发展的四个阶段
??质量管理活动
??质量管理基本思想
??产品测试为什么失败
??不同企业对产品质量的看法
??质量管理体系介绍
??产品质量管理的主要手段(测试,QA,评审,新物料认证,FMEA)
??举例子说明质量的重新性（看海尔公司关于质量视频）
??产品测试的主要工作
??测试方法的对应关系

二、测试工程过程 （4H）
本章概述： 主要讲述产品测试的工程过程，包括从接触用户需求、参与设计评审、编写测试计划、编写测试用例、执行测试、提交缺陷、验证问题、提交测试报告以及测试总体评估的整个过程。让学员掌握产品测试这项系统工程，有利于提高大家的全局观。
??产品的研发过程概述
??测试需求(主要讲述产品测试需求的评审和可测试性需求提出)
??测试策略	
??测试计划	
??测试用例设计
      演练：等价类、边界值、正交设计法、场景法、错误推断法等分组演练。
??测试环境准备
??测试执行
??测试报告
??测试度量
??测试总结
??单元/部件测试过程
??产品分解结构
??什么是产品构件（BB）
??产品子系统具有哪些特点？
??单元/部件测试基本概念  
・单元/部件测试的意义
??单元/部件测试过程 
・单元/部件测试阶段输出
??单元/部件测试准备
??单元/部件测试执行
??单元/部件测试成败关键因素分析
??案例分析:白盒测试案例演练（分组演练）
?白盒测试用例设计方法（单元、集成测试）

?测试环境（测试驱动、被测单元、测试桩、测试用例、测试结果）
?语句覆盖法用例设计、案例分析
?判断覆盖法用例设计、案例分析
?条件覆盖法用例设计、案例分析
?条件决策覆盖法用例设计、案例分析
?等价类用例设计方法、案例分析
?边界值用例设计方法、案例分析

??测试计划和用例评审查检表、测试记录、缺陷报告
??集成测试过程
??集成测试策略的确定时机
??集成测试基本概念 ・集成测试对象  ・集成测试中的角色定义
??集成测试的特点 
??集成测试顺序确定
??集成测试准备 ・集成测试执行   ・缺陷跟踪 
??集成测试质量目标   ・典型集成测试平台构造
??集成测试工作开展的制约因素
??集成测试成败关键因素分析
??系统测试过程
??转测试操作流程和角色定义
模板展示：内部版本发布说明书、研发版本转测试标准
??系统测试基本概念（定义、对象、依据）
??系统测试过程 ・系统测试输入、输出
??系统测试准备
??系统测试执行 
??测试环境的规划和管理
??问题跟踪反馈  ・基于产品平台的测试策略 
??系统测试成败关键因素分析 
??试生产测试过程（中间试验过程）
??试生产测试基本概念  
??试生产测试策略
??试生产测试的特点
??试生产测试执行
??过程记录 ・结果确认
??试生产测试质量目标
??试生产测试成败关键因素分析
??客户试用测试
??客户选择及准备
??需要什么样的产品上市策略？
??某公司产品上市决策转变
??BETA测试的使命与目标
??测试人员在客户试用中的职责

三、产品开发过程中的测试管理（4H）
本章概述： 主要讲述产品开发过程中的测试管理活动，包括概念阶段、计划阶段、开发阶段、验证阶段、发布阶段等产品开发过程中的各项测试活动，对每个测试活动进行详细的讲解和举例，介绍产品测试的方法和工具。
??整体介绍
??市场驱动的产品研发・结构化的产品开发流程、举例
??跨部门的产品开发团队 ・测试代表的职责定义
??测试代表与相关职能领域代表的关系描述
??产品开发项目测试组织与职责
??产品开发阶段划分 ・技术评审点 
??决策评审点
??演示：结构化的产品测试流程
??测试计划的分层控制
??产品测试业务框架
??产品测试管理过程
??各个产品开发阶段的关键开发与测试活动
??概念阶段测试活动介绍
??概念阶段测试活动目标
??产品包需求
??需求的可测试性
??可测试性需求案例分析
??客户服务的可诊断性
??产品测试策略的确定
    分组演练：画出一个测试目标产品的PBS（产品分解结构图）
??计划阶段测试活动介绍 
??测试团队的扩充方法
??细化测试领域工作计划
??制订整个产品测试与验证方案
??可测试性设计
??测试技术知识产权与专利申请
??集成测试策略确定
??测试工具开发策略 
??可测试性设计的监督实施
??开发阶段测试活动介绍 
??测试工具选型
??集成测试工作的开展 
??测试工具的实现
??部件测试、部件测试报告模板演示
??构件模块功能测试（BBFV）
??基于产品组件的测试 
・产品组件集成与测试（SDV）
??系统测试的流程及方法（SIT） 
??生产测试设备及工装的开发
??BETA测试用户确定 
??试验场测试项目及组织方式
??验证阶段测试工作介绍
??中试组织结构与职责
??SVT测试方法
??生产验证测试主要活动
??市场验证测试活动
??标杆测试方法
??认证测试方法（CE、UL、3C认证方法及流程）
??测试总结报告
??基于客户交付的产品测试
??专业实验结构与职责
??专业实验室测试项目
??可靠性测试内容、举例
??安全性测试内容、举例
??EMC测试内容、举例
??噪声测试内容、举例
??热测试内容、举例
??环境测试内容、举例
??回归测试、举例
   模板展示：可靠性测试及环境实验的真实方案及模板展示。
??发布阶段测试工作介绍
??客户问题跟踪 ・产品升级
??收集分析新需求 ・招标支撑
??重点客户支撑 ・培训客户  
・在线诊断
??流程子流程
??软件测试子流程
??软件测试度量
??软件测试子流程裁剪说明
??硬件测试子流程
??硬件产品构成
??硬件单板的构成
??硬件测试关注内容
    模板展示:硬件测试用例举例、硬件测试方案举例
??硬件测试要点
??单板软件与硬件测试过程

四、测试组织结构 （2H）
本章概述： 主要讲述产品测试组织的设置，测试团队的管理及绩效考核，如何提高测试人员的成就感，如何度量测试人员的绩效，如何建立测试人员的职业通道。

??产品测试组涉及的角色和组织结构（知名企业的测试组织结构）
??测试代表的职责
??测试外围组的职责
??部件测试组织
??测试部在产品测试中的职责
??测试人员核心素质 ・测试人员的职业发展
??测试人员技术等级介绍 ・测试人员的职业规划  
??测试人员的职责划分
??测试技术等级管理存在问题与避免办法
??国内测试组织存在的问题及解决办法
??组织定位与职责   
??华为及阿里巴巴测试人员素质要求介绍 
??测试经理的职业素质要求  ・测试经理的培养
??案例讨论:测试人员为什么缺少成就感
??如何提高测试人员的成就感
??对测试人员的绩效管理

五、产品测试技术与自动化（1H）
?什么是自动化测试
?自动化测试脚本语言
?什么样的测试适合自动化
?自动化测试的发展历程
?自动化测试框架
?自动化测试常用工具
?自动化测试工具与产品生命周期的关系
?产品可靠性指标及测试方法?
?单元测试工具
开源工具：软件单元测试(CPPUNIT,JUNIT等) 
商用工具:  VISUAL UNIT,嵌入式测试工具,硬件测试工具.
讲师实际演示单元测试工具的使用方法
?问题管理工具
	
六、推进企业测试体系建设 （1H）
本章概述： 主要讲述产品测试体系建设的步骤和方法，讲述一些知名企业从零开始如何一步一步建立功能强大的产品测试体系，并分享企业测试体系成功和失败的案例。
??企业测试体系典型问题分析
??测试技能发展历程
??测试体系如何从无到有建设?
??如何从功能测试到测试平台建设?
??测试组织发展历程
??建立独立的测试组织	
??如何建设高水平的测试部门?

七、如何改进我公司的产品测试体系？
本章概述： 根据两天的课程，请学员代表发言，如何改进我公司的产品测试体系。各组10分钟。

讲师介绍：James 李老师
研发咨询资深顾问
专业背景
    多年高科技企业产品研发和研发管理、产品管理工作经历，先后担任过项目，质量总监，质量副总等职位，在长期的研发管理实践中积累了丰富的技术和管理经验。
    在国内某知名通信企业（华为）工作期间，先后从事产品开发、项目管理和产品质量等工作，并作为推行组成员与国际研发管理顶尖咨询顾问在研发及售后服务系统推动公司级研发管理变革（IPD-集成产品开发）。在质量部工作期间，作为EPG成员，开发了需求管理工具R-Manager以及CMM 5级流程，并负责企业内部的推行。
    在展讯通信公司工作期间，担任质量部高级经理，任职期间有针对性地将研发管理的业界最佳实践同公司现状相结合，全面建立并优化产品管理体系。同时兼任内部讲师，具有丰富的产品管理实战经验。
    在北京联信永益工作期间，作为质量副总成功建立了产品需求、产品定义、立项及整个开发与上市过程的管理，为公司的上市做好了铺垫。
    在中国惠普TS-QO产品线，作为高级咨询顾问，成功的打入中国移动总部和建设银行总部，为国字号的企业管理领域市场打开了研发、测试、运维的管理咨询之路。
业务擅长
在多家电信设备厂商从事过研发以及管理工作，对部门管理、项目管理和团队建设等方面经验丰富。并且在研发流程体系和质量管理体系有丰富的从业经历，沟通能力强，有协作精神；做事认真细致，富于创新。
培训经验
从事研发管理咨询，先后作为项目核心成员和项目经理成功完成了近20个研发管理咨询项目体系的建设和落地（产品开发流程体系、研发项目管理体系、CMMI软件开发管理体系），在产品开发流程设计、研发项目管理和体系推行方面具有丰富的咨询经验。
目前受众的主要客户如下
国电南瑞、亚信科技、长城汽车、中通客车、宇通客车、福田汽车、潍柴动力、上海宝信软件、深圳比亚迪微电子、山东鲁光科技、武汉东浦、北京华彩、长城电脑，美菱电器，大唐电信、中国移动总部、吉林移动、河北移动、广西移动、贵州移动、四川电信、国网电科院、正元信息、中联佳裕、山东万博、鲁光信息、广通迅达、伟景行、石化盈科、长春宏达、中国海关、重邮信科、成都吉锐、广州日立电梯、北京华彩、北京蓝讯、升腾资讯、中电华大、西威电子数家企业。
研发管理咨询：主要参与及负责的项目如下
中国移动总部运营支撑中心  
测试管理体系咨询：参与了该咨询项目的现状调研、测试管理流程体系设计、组织结构建议、测试工具及平台规划、测试项目管理体系设计、测试绩效管理体系设计、研发KPI体系设计，2012.12月已结项。
主要用于中国移动总部运营支撑中心管理华为，亚信，惠普等企业的产品质量和人员管理。
建设银行数据中心
IT运维管理咨询：参与该咨询项目的现状调研、交接维流程体系设计、产品上线运维关键指标设计、运维故障管理流程。
2012.9月已经结项
浙江蓝讯软件有限公司 （国家安全管理委员会软件定制开发）
研发管理体系咨询项目（研发流程体系、技术平台管理工具与模板体系、研发质量管理体系，CMMI项目），任项目组成员，已结项。
武汉东浦信息技术有限公司 （东风汽车、东风日产汽车PDM，ERP软件开发）
主导了该咨询项目的现状调研、产品开发流程体系设计、技术平台管理工具与模板体系设计等，CMMI项目，任项目经理，已结项。
北京石化盈科 （电讯盈科与中国石化的合资企业，主要为中国石化开发油品管理软件）
研发管理咨询：主导了该咨询项目的现状调研，CMMI项目，主导产品开发流程设计。

_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

[±¤°í] Áö±ÝÀº ¼ÒÇü Ä«Æä â¾÷ ½Ã´ë

[¹Ú °úÀå]

[-- Attachment #1: Type: text/plain, Size: 2301 bytes --]

Spam detection software, running on the system "blaine.gmane.org",
has identified this incoming email as possible spam.  The original
message has been attached to this so you can view it or label
similar future email.  If you have any questions, see
@@CONTACT_ADDRESS@@ for details.

Content preview:  ¼ÒÇü Ä«Æä´Â ¾î´À ºê·£µå°¡ ÁÁÀ» ±î¿ä? 1. ´õº¥Æ¼ 2. ÄÄÆ÷ÁîÄ¿ÇÇ
   3. º¹°í´Ù¹æ 4. »ýÈ°Ä¿ÇÇ µµ¿òÀÌ µÇ¼Ì³ª¿ä? [...] 

Content analysis details:   (11.7 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at http://www.dnswl.org/, no
                            trust
                            [198.145.21.10 listed in list.dnswl.org]
 1.2 RCVD_NUMERIC_HELO      Received: contains an IP address used for HELO
-0.6 RP_MATCHES_RCVD        Envelope sender domain matches handover relay domain
 2.4 RCVD_HELO_IP_MISMATCH  Received: HELO and IP do not match, but should
 0.0 T_HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail
                            domains are different
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail provider
                            (jun244356[at]gmail.com)
 0.2 FREEMAIL_REPLYTO_END_DIGIT Reply-To freemail username ends in digit
                            (jun244356[at]gmail.com)
-0.0 BAYES_20               BODY: Bayes spam probability is 5 to 20%
                            [score: 0.1040]
 1.4 AXB_XM_FORGED_OL2600   Forged OE v. 6.2600
 1.5 SUBJ_ILLEGAL_CHARS     Subject: has too many raw illegal characters
 0.0 T_FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and
                            EnvelopeFrom freemail headers are different
 0.0 SUBJECT_NEEDS_ENCODING No description available.
 2.6 MSGID_RANDY            Message-Id has pattern used in spam
 1.0 RCVD_DOUBLE_IP_LOOSE   Received: by and from look like IP addresses
 1.9 FORGED_MUA_OUTLOOK     Forged mail pretending to be from MS Outlook

The original message was not completely plain text, and may be unsafe to
open with some email clients; in particular, it may contain a virus,
or confirm that your address can receive spam.  If you wish to view
it, it may be safer to save it to a file and open it with an editor.


[-- Attachment #2: original message before SpamAssassin --]
[-- Type: message/rfc822, Size: 3110 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 112 bytes --]

¼ÒÇü Ä«Æä´Â ¾î´À ºê·£µå°¡ ÁÁÀ» ±î¿ä?

1. ´õº¥Æ¼
2. ÄÄÆ÷ÁîÄ¿ÇÇ
3. º¹°í´Ù¹æ
4. »ýÈ°Ä¿ÇÇ

µµ¿òÀÌ µÇ¼Ì³ª¿ä?

[-- Attachment #2.1.2: Type: text/plain, Size: 178 bytes --]

_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

????????????????

[nd]

[-- Attachment #1: Type: text/plain, Size: 20 bytes --]

nd

linux-fsdevel7

[-- Attachment #2: ????????????.xls --]
[-- Type: application/x-msexcel, Size: 35840 bytes --]

???????????????

[???]

[-- Attachment #1: Type: text/plain, Size: 18 bytes --]

0ÏòÊçæÃ

linuxer

[-- Attachment #2: ???????'???'.xls --]
[-- Type: application/x-msexcel, Size: 25088 bytes --]

(no subject)

[Christoph Lameter]

> > There is a deadlock, Peter!!!
>
> Describe please? Also, have you tried disabling RT_RUNTIME_SHARE ?
>


The description was given earlier in the the thread and the drawbacks of
using RT_RUNTIME_SHARE as well.

Re: ???

[Steven Rostedt]

What's with people sending out replies without subjects?

On Tue, 15 Nov 2016 14:29:16 -0600 (CST)
Christoph Lameter <cl@linux.com> wrote:

> > > There is a deadlock, Peter!!!  
> >
> > Describe please? Also, have you tried disabling RT_RUNTIME_SHARE ?
> >  
> 
> 
> The description was given earlier in the the thread and the drawbacks of
> using RT_RUNTIME_SHARE as well.

Peter is saying to disable that, because of the drawbacks. I think the
question is, do you still have a deadlock after disabling it? If not,
then that's your solution.

-- Steve

(no subject)

[Chunyan Zhang]

Hi Steven,

On 21 October 2016 at 20:13, Chunyan Zhang <zhang.chunyan@linaro.org> wrote:
> On 18 October 2016 at 23:44, Steven Rostedt <rostedt@goodmis.org> wrote:
>> On Tue, 18 Oct 2016 16:08:58 +0800
>> Chunyan Zhang <zhang.chunyan@linaro.org> wrote:
>>
>>> Currently Function traces can be only exported to ring buffer, this
>>> patch added trace_export concept which can process traces and export
>>> them to a registered destination as an addition to the current only
>>> one output of Ftrace - i.e. ring buffer.
>>>
>>> In this way, if we want Function traces to be sent to other destination
>>> rather than ring buffer only, we just need to register a new trace_export
>>> and implement its own .write() function for writing traces to storage.
>>>
>>> With this patch, only Function trace (trace type is TRACE_FN)
>>> is supported.
>>
>> This is getting better, but I still have some nits.
>>
>
> Thanks.
>
>>>
>>> Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org>
>>> ---
>>>  include/linux/trace.h |  28 +++++++++++
>>>  kernel/trace/trace.c  | 132 +++++++++++++++++++++++++++++++++++++++++++++++++-
>>>  2 files changed, 159 insertions(+), 1 deletion(-)
>>>  create mode 100644 include/linux/trace.h
>>>
>>> diff --git a/include/linux/trace.h b/include/linux/trace.h
>>> new file mode 100644
>>> index 0000000..eb1c5b8
>>> --- /dev/null
>>> +++ b/include/linux/trace.h
>>> @@ -0,0 +1,28 @@
>>> +#ifndef _LINUX_TRACE_H
>>> +#define _LINUX_TRACE_H
>>> +
>>> +#ifdef CONFIG_TRACING
>>> +/*
>>> + * The trace export - an export of Ftrace output. The trace_export
>>> + * can process traces and export them to a registered destination as
>>> + * an addition to the current only output of Ftrace - i.e. ring buffer.
>>> + *
>>> + * If you want traces to be sent to some other place rather than ring
>>> + * buffer only, just need to register a new trace_export and implement
>>> + * its own .write() function for writing traces to the storage.
>>> + *
>>> + * next              - pointer to the next trace_export
>>> + * write     - copy traces which have been delt with ->commit() to
>>> + *             the destination
>>> + */
>>> +struct trace_export {
>>> +     struct trace_export __rcu       *next;
>>> +     void (*write)(const char *, unsigned int);
>>
>> Why const char*? Why not const void *? This will never be a string.
>>
>
> Will revise this.
>
>>
>>> +};
>>> +
>>> +int register_ftrace_export(struct trace_export *export);
>>> +int unregister_ftrace_export(struct trace_export *export);
>>> +
>>> +#endif       /* CONFIG_TRACING */
>>> +
>>> +#endif       /* _LINUX_TRACE_H */
>>> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
>>> index 8696ce6..db94ec1 100644
>>> --- a/kernel/trace/trace.c
>>> +++ b/kernel/trace/trace.c
>>> @@ -40,6 +40,7 @@
>>>  #include <linux/poll.h>
>>>  #include <linux/nmi.h>
>>>  #include <linux/fs.h>
>>> +#include <linux/trace.h>
>>>  #include <linux/sched/rt.h>
>>>
>>>  #include "trace.h"
>>> @@ -2128,6 +2129,132 @@ void trace_buffer_unlock_commit_regs(struct trace_array *tr,
>>>       ftrace_trace_userstack(buffer, flags, pc);
>>>  }
>>>
>>> +static void
>>> +trace_process_export(struct trace_export *export,
>>> +            struct ring_buffer_event *event)
>>> +{
>>> +     struct trace_entry *entry;
>>> +     unsigned int size = 0;
>>> +
>>> +     entry = ring_buffer_event_data(event);
>>> +
>>> +     size = ring_buffer_event_length(event);
>>> +
>>> +     if (export->write)
>>> +             export->write((char *)entry, size);
>>
>> Is there ever going to be a time where export->write wont be set?
>
> There hasn't been since only one trace_export (i.e. stm_ftrace) was
> added in this patch-set , I just wanted to make sure the write() has
> been set before registering trace_export like what I added in 2/3 of
> this series.
>
>>
>> And if there is, this can be racy. As in
>>
>>
>>         CPU 0:                  CPU 1:
>>         ------                  ------
>>         if (export->write)
>>
>>                                 export->write = NULL;
>
> Is there going to be this kind of use case? Why some one needs to
> change export->write() rather than register a new trace_export?
>
> I probably haven't understood your point thoroughly, please correct me
> if my guess was wrong.
>

Any further comments? :)

Thanks,
Chunyan

>
> Thanks for the review,
> Chunyan
>
>>
>>         export->write(entry, size);
>>
>>         BOOM!
>>
>>
>> -- Steve
>>
>>> +}
>>> +
>>> +static DEFINE_MUTEX(ftrace_export_lock);
>>> +
>>> +static struct trace_export __rcu *ftrace_exports_list __read_mostly;
>>> +
>>> +static DEFINE_STATIC_KEY_FALSE(ftrace_exports_enabled);
>>> +
>>> +static inline void ftrace_exports_enable(void)
>>> +{
>>> +     static_branch_enable(&ftrace_exports_enabled);
>>> +}
>>> +
>>> +static inline void ftrace_exports_disable(void)
>>> +{
>>> +     static_branch_disable(&ftrace_exports_enabled);
>>> +}
>>> +
>>> +void ftrace_exports(struct ring_buffer_event *event)
>>> +{
>>> +     struct trace_export *export;
>>> +
>>> +     preempt_disable_notrace();
>>> +
>>> +     export = rcu_dereference_raw_notrace(ftrace_exports_list);
>>> +     while (export) {
>>> +             trace_process_export(export, event);
>>> +             export = rcu_dereference_raw_notrace(export->next);
>>> +     }
>>> +
>>> +     preempt_enable_notrace();
>>> +}
>>> +
>>> +static inline void
>>> +add_trace_export(struct trace_export **list, struct trace_export *export)
>>> +{
>>> +     rcu_assign_pointer(export->next, *list);
>>> +     /*
>>> +      * We are entering export into the list but another
>>> +      * CPU might be walking that list. We need to make sure
>>> +      * the export->next pointer is valid before another CPU sees
>>> +      * the export pointer included into the list.
>>> +      */
>>> +     rcu_assign_pointer(*list, export);
>>> +}
>>> +
>>> +static inline int
>>> +rm_trace_export(struct trace_export **list, struct trace_export *export)
>>> +{
>>> +     struct trace_export **p;
>>> +
>>> +     for (p = list; *p != NULL; p = &(*p)->next)
>>> +             if (*p == export)
>>> +                     break;
>>> +
>>> +     if (*p != export)
>>> +             return -1;
>>> +
>>> +     rcu_assign_pointer(*p, (*p)->next);
>>> +
>>> +     return 0;
>>> +}
>>> +
>>> +static inline void
>>> +add_ftrace_export(struct trace_export **list, struct trace_export *export)
>>> +{
>>> +     if (*list == NULL)
>>> +             ftrace_exports_enable();
>>> +
>>> +     add_trace_export(list, export);
>>> +}
>>> +
>>> +static inline int
>>> +rm_ftrace_export(struct trace_export **list, struct trace_export *export)
>>> +{
>>> +     int ret;
>>> +
>>> +     ret = rm_trace_export(list, export);
>>> +     if (*list == NULL)
>>> +             ftrace_exports_disable();
>>> +
>>> +     return ret;
>>> +}
>>> +
>>> +int register_ftrace_export(struct trace_export *export)
>>> +{
>>> +     if (WARN_ON_ONCE(!export->write))
>>> +             return -1;
>>> +
>>> +     mutex_lock(&ftrace_export_lock);
>>> +
>>> +     add_ftrace_export(&ftrace_exports_list, export);
>>> +
>>> +     mutex_unlock(&ftrace_export_lock);
>>> +
>>> +     return 0;
>>> +}
>>> +EXPORT_SYMBOL_GPL(register_ftrace_export);
>>> +
>>> +int unregister_ftrace_export(struct trace_export *export)
>>> +{
>>> +     int ret;
>>> +
>>> +     mutex_lock(&ftrace_export_lock);
>>> +
>>> +     ret = rm_ftrace_export(&ftrace_exports_list, export);
>>> +
>>> +     mutex_unlock(&ftrace_export_lock);
>>> +
>>> +     return ret;
>>> +}
>>> +EXPORT_SYMBOL_GPL(unregister_ftrace_export);
>>> +
>>>  void
>>>  trace_function(struct trace_array *tr,
>>>              unsigned long ip, unsigned long parent_ip, unsigned long flags,
>>> @@ -2146,8 +2273,11 @@ trace_function(struct trace_array *tr,
>>>       entry->ip                       = ip;
>>>       entry->parent_ip                = parent_ip;
>>>
>>> -     if (!call_filter_check_discard(call, entry, buffer, event))
>>> +     if (!call_filter_check_discard(call, entry, buffer, event)) {
>>> +             if (static_branch_unlikely(&ftrace_exports_enabled))
>>> +                     ftrace_exports(event);
>>>               __buffer_unlock_commit(buffer, event);
>>> +     }
>>>  }
>>>
>>>  #ifdef CONFIG_STACKTRACE
>>

Re: ??

[Steven Rostedt]

On Fri, 11 Nov 2016 11:38:45 +0800
Chunyan Zhang <zhang.chunyan@linaro.org> wrote:


What happened to the subject?

> >>> +static void
> >>> +trace_process_export(struct trace_export *export,
> >>> +            struct ring_buffer_event *event)
> >>> +{
> >>> +     struct trace_entry *entry;
> >>> +     unsigned int size = 0;
> >>> +
> >>> +     entry = ring_buffer_event_data(event);
> >>> +
> >>> +     size = ring_buffer_event_length(event);
> >>> +
> >>> +     if (export->write)
> >>> +             export->write((char *)entry, size);  
> >>
> >> Is there ever going to be a time where export->write wont be set?  
> >
> > There hasn't been since only one trace_export (i.e. stm_ftrace) was
> > added in this patch-set , I just wanted to make sure the write() has
> > been set before registering trace_export like what I added in 2/3 of
> > this series.
> >  
> >>
> >> And if there is, this can be racy. As in
> >>
> >>
> >>         CPU 0:                  CPU 1:
> >>         ------                  ------
> >>         if (export->write)
> >>
> >>                                 export->write = NULL;  
> >
> > Is there going to be this kind of use case? Why some one needs to
> > change export->write() rather than register a new trace_export?
> >
> > I probably haven't understood your point thoroughly, please correct me
> > if my guess was wrong.
> >  
> 
> Any further comments? :)

I don't remember which patch series this goes to, so right now, no.

-- Steve

??

[Steven Rostedt]

On Fri, 11 Nov 2016 11:38:45 +0800
Chunyan Zhang <zhang.chunyan@linaro.org> wrote:


What happened to the subject?

> >>> +static void
> >>> +trace_process_export(struct trace_export *export,
> >>> +            struct ring_buffer_event *event)
> >>> +{
> >>> +     struct trace_entry *entry;
> >>> +     unsigned int size = 0;
> >>> +
> >>> +     entry = ring_buffer_event_data(event);
> >>> +
> >>> +     size = ring_buffer_event_length(event);
> >>> +
> >>> +     if (export->write)
> >>> +             export->write((char *)entry, size);  
> >>
> >> Is there ever going to be a time where export->write wont be set?  
> >
> > There hasn't been since only one trace_export (i.e. stm_ftrace) was
> > added in this patch-set , I just wanted to make sure the write() has
> > been set before registering trace_export like what I added in 2/3 of
> > this series.
> >  
> >>
> >> And if there is, this can be racy. As in
> >>
> >>
> >>         CPU 0:                  CPU 1:
> >>         ------                  ------
> >>         if (export->write)
> >>
> >>                                 export->write = NULL;  
> >
> > Is there going to be this kind of use case? Why some one needs to
> > change export->write() rather than register a new trace_export?
> >
> > I probably haven't understood your point thoroughly, please correct me
> > if my guess was wrong.
> >  
> 
> Any further comments? :)

I don't remember which patch series this goes to, so right now, no.

-- Steve

Re: ###$$$@#

[iutititbpigi]

----- Original Message -----

Sent: Tue, 31 May 2016 21:02:28 -0400 (EDT)
Subject: ###$$$@#

BMW WINNING NOTIFICATION!!!

?

[Robert]

Did you get my previous mail? When can i call you?

Re: ?

[Amall]

----- Original Message -----
From: 
Sent: Tue, 27 Oct 2015 16:25:44 -0400 (EDT)
Subject: 

i need your support

!

[Kathrine]

Did you get my previous mail? When and what time can i call?

!

[Rita]

When and What time can i Call you? Respond ASAP

!

[Rita]

When and What time can i Call you? Respond ASAP

Old regression with MTD devices disappearing from a Kurobox HD/HG

[Rogério Brito]

Hi.

I just revived a Kurobox HG to use as a NAS (I also have a simpler Kurobox
HD here, not being used at this moment) and I am having problems that didn't
happen before.  I will describe the first problem here and further problems
in later e-mails.

During the 2.6.27 to 2.6.29 era (I may be mistaken in the range, as this is
not new) the kernel had a regression where the MTD device of the Kurobox
used to show about 5 partitions and, with kernels later than that, only one
partition is shown, namely, /dev/mtd0.

Here is what I used to see (just booted the kernel from flash), with a
2.4.33.3 kernel (if desired, I can, of course, send the full dmesg log, but
I don't have the corresponding config):

,----
| LinkStation flash device: 400000 at ffc00000
| NO QRY response
|  Amd/Fujitsu Extended Query Table v1.3 at 0x0040
| LinkStation Flash: Swapping erase regions for broken CFI table.
| number of CFI chips: 1
| cfi_cmdset_0002: Disabling fast programming due to code brokenness.
| Creating 5 MTD partitions on "LinkStation Flash":
| 0x00000000-0x00300000 : "mtd0: kernel+ramdisk"
| 0x00300000-0x00370000 : "mtd1: bootloader"
| 0x00370000-0x00380000 : "mtd2: configuration"
| 0x00380000-0x00400000 : "mtd3: user space"
| 0x00000000-0x00400000 : "mtd4: all flash"
| LinkStation flash device initialized
`----

As I have trouble booting kernels older than 3.x due to my userspace having
udev and libc requirements, I found a dmesg log that is similar to what I
used to get with early 2.6 kernels---this is from a kernel 2.6.15 (this part
is copied from: http://genbako.vodapone.com/old/dmesg-20060117-kuro-NG.txt):

,----
| physmap flash device: 400000 at ffc00000
| phys_mapped_flash: Found 1 x16 devices at 0x0 in 8-bit bank
|  Amd/Fujitsu Extended Query Table at 0x0040
| phys_mapped_flash: Swapping erase regions for broken CFI table.
| number of CFI chips: 1
| cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
| cmdlinepart partition parsing not available
| RedBoot partition parsing not available
| Using physmap partition definition
| Creating 5 MTD partitions on "phys_mapped_flash":
| 0x00000000-0x00400000 : "mtd_allflash"
| 0x00000000-0x00300000 : "mtd_firmimg"
| 0x00300000-0x00370000 : "mtd_bootcode"
| 0x00370000-0x00380000 : "mtd_status"
| 0x00380000-0x00400000 : "mtd_conf"
| usbmon: debugfs is not available
`----

Note that, in particular, the boundary addresses of the MTD device are
exactly the same as the ones on my device.

Unfortunately, right now, what I see with Linus's tree
(4.0.0-rc6-00009-g6c310bc) is the following:

,----
| physmap platform flash device: 00400000 at ffc00000
| physmap-flash.0: Found 1 x16 devices at 0x0 in 8-bit bank. Manufacturer ID 0x000004 Chip ID 0x00007e
| Amd/Fujitsu Extended Query Table at 0x0040
|   Amd/Fujitsu Extended Query version 1.3.
| physmap-flash.0: Swapping erase regions for top-boot CFI table.
| number of CFI chips: 1
`----

I note that arch/powerpc/boot/dts/kuroboxH{D,G}.dts have, as one of their
first lines, the following comment: [0][1]

    XXXX add flash parts, rtc, ??

[0]: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/boot/dts/kuroboxHD.dts?id=1cced5015b171415169d938fb179c44fe060dc15#n17
[1]: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/boot/dts/kuroboxHG.dts?id=1cced5015b171415169d938fb179c44fe060dc15#n17

Is this a problem that can be fixed via additions to the DTS files?  Or
would the problem be solved in a different way?


Thanks in advance,

Rogério Brito.

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFCAAAA
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Re: Old regression with MTD devices disappearing from a Kurobox HD/HG

[Scott Wood]

On Sat, 2015-04-04 at 02:40 -0300, Rogério Brito wrote:
> Unfortunately, right now, what I see with Linus's tree
> (4.0.0-rc6-00009-g6c310bc) is the following:
> 
> ,----
> | physmap platform flash device: 00400000 at ffc00000
> | physmap-flash.0: Found 1 x16 devices at 0x0 in 8-bit bank. Manufacturer ID 0x000004 Chip ID 0x00007e
> | Amd/Fujitsu Extended Query Table at 0x0040
> |   Amd/Fujitsu Extended Query version 1.3.
> | physmap-flash.0: Swapping erase regions for top-boot CFI table.
> | number of CFI chips: 1
> `----
> 
> I note that arch/powerpc/boot/dts/kuroboxH{D,G}.dts have, as one of their
> first lines, the following comment: [0][1]
> 
>     XXXX add flash parts, rtc, ??
> 
> [0]: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/boot/dts/kuroboxHD.dts?id=1cced5015b171415169d938fb179c44fe060dc15#n17
> [1]: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/boot/dts/kuroboxHG.dts?id=1cced5015b171415169d938fb179c44fe060dc15#n17
> 
> Is this a problem that can be fixed via additions to the DTS files?  Or
> would the problem be solved in a different way?

What are your bootargs?

I suggest putting the flash device into the dts (instead of using
physmap), and specifying the partitions on the command-line using
mtdparts.  Putting the partitions in the dts is an option as well, but
less flexible if users may want to change the partition layout -- though
that may be less of a concern here than with reference boards.

-Scott

Re: Old regression with MTD devices disappearing from a Kurobox HD/HG

[Rogério Brito]

Dear Scott.

First of all, thank you so very much for your reply.

On Apr 07 2015, Scott Wood wrote:
> On Sat, 2015-04-04 at 02:40 -0300, Rogério Brito wrote:
> > ,----
> > | physmap platform flash device: 00400000 at ffc00000
> > | physmap-flash.0: Found 1 x16 devices at 0x0 in 8-bit bank. Manufacturer ID 0x000004 Chip ID 0x00007e
> > | Amd/Fujitsu Extended Query Table at 0x0040
> > |   Amd/Fujitsu Extended Query version 1.3.
> > | physmap-flash.0: Swapping erase regions for top-boot CFI table.
> > | number of CFI chips: 1
> > `----
> > 
> > I note that arch/powerpc/boot/dts/kuroboxH{D,G}.dts have, as one of their
> > first lines, the following comment: [0][1]
> > 
> >     XXXX add flash parts, rtc, ??
> > 
> > [0]: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/boot/dts/kuroboxHD.dts?id=1cced5015b171415169d938fb179c44fe060dc15#n17
> > [1]: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/boot/dts/kuroboxHG.dts?id=1cced5015b171415169d938fb179c44fe060dc15#n17
> > 
> > Is this a problem that can be fixed via additions to the DTS files?  Or
> > would the problem be solved in a different way?
> 
> What are your bootargs?

My kernel command line is (specified via uboot) is the following:

,----
| root=/dev/sda1 netconsole=6666@192.168.11.150/,@192.168.11.149/ rtc-rs5c372.probe=0,0x32
`----

Only that.

> I suggest putting the flash device into the dts (instead of using
> physmap), and specifying the partitions on the command-line using
> mtdparts.

This is good to know. Is there any reasonable dts that I can copy/adapt? I
just started to read on the syntax of the dts files and I am still not
confident that I can write my own without messing everything.

Another question: would putting the description of the flash device into the
dts file be helpful to remove any code from the kernel? That would be super
nice, as the kernels with equivalent configurations are getting so much
bigger during time. The smallest one that I have here is 2.6.28 and its
uImage was 1.5MB, while kernel 4.0 is about 1.9MB with essentially
everything pruned from the kernel (only the bare minimum compiled in). :(

(Everything here is compiled with the very same compiler).

> Putting the partitions in the dts is an option as well, but less flexible
> if users may want to change the partition layout -- though that may be
> less of a concern here than with reference boards.

I think that I would go for the partitions in the dts, mainly because these
machines are not really flexible.  Furthermore, I would need the mtd devices
working so that I can use fw_setenv to change the boot options. :)

In the end, I would like (perhaps) to automate the installation/support of
such machines and offer a way to install Debian on those (or any other
distribution that is interested in these).

Once again, thank you so much for your comments and I hope that you can
guide me some more to fix this for good.


Thanks,

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFCAAAA
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Re: Old regression with MTD devices disappearing from a Kurobox HD/HG

[Scott Wood]

On Tue, 2015-04-07 at 20:58 -0300, Rogério Brito wrote:
> Dear Scott.
> 
> First of all, thank you so very much for your reply.
> 
> On Apr 07 2015, Scott Wood wrote:
> > On Sat, 2015-04-04 at 02:40 -0300, Rogério Brito wrote:
> > > ,----
> > > | physmap platform flash device: 00400000 at ffc00000
> > > | physmap-flash.0: Found 1 x16 devices at 0x0 in 8-bit bank. Manufacturer ID 0x000004 Chip ID 0x00007e
> > > | Amd/Fujitsu Extended Query Table at 0x0040
> > > |   Amd/Fujitsu Extended Query version 1.3.
> > > | physmap-flash.0: Swapping erase regions for top-boot CFI table.
> > > | number of CFI chips: 1
> > > `----
> > > 
> > > I note that arch/powerpc/boot/dts/kuroboxH{D,G}.dts have, as one of their
> > > first lines, the following comment: [0][1]
> > > 
> > >     XXXX add flash parts, rtc, ??
> > > 
> > > [0]: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/boot/dts/kuroboxHD.dts?id=1cced5015b171415169d938fb179c44fe060dc15#n17
> > > [1]: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/boot/dts/kuroboxHG.dts?id=1cced5015b171415169d938fb179c44fe060dc15#n17
> > > 
> > > Is this a problem that can be fixed via additions to the DTS files?  Or
> > > would the problem be solved in a different way?
> > 
> > What are your bootargs?
> 
> My kernel command line is (specified via uboot) is the following:
> 
> ,----
> | root=/dev/sda1 netconsole=6666@192.168.11.150/,@192.168.11.149/ rtc-rs5c372.probe=0,0x32
> `----
> 
> Only that.
> 
> > I suggest putting the flash device into the dts (instead of using
> > physmap), and specifying the partitions on the command-line using
> > mtdparts.
> 
> This is good to know. Is there any reasonable dts that I can copy/adapt?

I'm not familiar with how flash is connected on this chip, so I don't
have a specific recommendation other than to read the binding and look
at several examples.

>  I just started to read on the syntax of the dts files and I am still
> not confident that I can write my own without messing everything.
> 
> Another question: would putting the description of the flash device into the
> dts file be helpful to remove any code from the kernel?

If you currently have a custom flash map driver, you could get rid of
that, but I suspect that's already gone away due to the fact that it's
no longer working.

-Scott

Re: Old regression with MTD devices disappearing from a Kurobox HD/HG

[Rogério Brito]

Dear Scott,

Once again, thank you very much for your answer.

On Apr 07 2015, Scott Wood wrote:
> On Tue, 2015-04-07 at 20:58 -0300, Rogério Brito wrote:
> > This is good to know. Is there any reasonable dts that I can copy/adapt?
> 
> I'm not familiar with how flash is connected on this chip, so I don't
> have a specific recommendation other than to read the binding and look
> at several examples.

How can I discover how the flash is connected? I'm really showing here that
I am only a luser, but I am willing to find any specs so that this can be
fixed.

> > Another question: would putting the description of the flash device into the
> > dts file be helpful to remove any code from the kernel?
> 
> If you currently have a custom flash map driver, you could get rid of
> that, but I suspect that's already gone away due to the fact that it's
> no longer working.

I see. If I do some "archaeology" (read: bisect when it stopped working),
would that help to discover how the flash is connected?


Thanks once again,

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFCAAAA
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Re: Old regression with MTD devices disappearing from a Kurobox HD/HG

[Scott Wood]

On Tue, 2015-04-07 at 21:37 -0300, Rogério Brito wrote:
> Dear Scott,
> 
> Once again, thank you very much for your answer.
> 
> On Apr 07 2015, Scott Wood wrote:
> > On Tue, 2015-04-07 at 20:58 -0300, Rogério Brito wrote:
> > > This is good to know. Is there any reasonable dts that I can copy/adapt?
> > 
> > I'm not familiar with how flash is connected on this chip, so I don't
> > have a specific recommendation other than to read the binding and look
> > at several examples.
> 
> How can I discover how the flash is connected? I'm really showing here that
> I am only a luser, but I am willing to find any specs so that this can be
> fixed.
>
> > > Another question: would putting the description of the flash device into the
> > > dts file be helpful to remove any code from the kernel?
> > 
> > If you currently have a custom flash map driver, you could get rid of
> > that, but I suspect that's already gone away due to the fact that it's
> > no longer working.
> 
> I see. If I do some "archaeology" (read: bisect when it stopped working),
> would that help to discover how the flash is connected?

It will probably give you the address and size of the flash, which is
good enough to get something working.  Does your config (for the old
kernel) have anything with PHYSMAP in it?  I suspect it probably broke
with commit dcb3e137ce9be1dfc86e306182b23e3ae5e239c4 ("[MTD] physmap:
make physmap compat explicit").

-Scott

Re: Old regression with MTD devices disappearing from a Kurobox HD/HG

[Rogério Brito]

Hi, Scott.

On Apr 07 2015, Scott Wood wrote:
> On Tue, 2015-04-07 at 21:37 -0300, Rogério Brito wrote:
> > I see. If I do some "archaeology" (read: bisect when it stopped
> > working), would that help to discover how the flash is connected?
> 
> It will probably give you the address and size of the flash, which is
> good enough to get something working.  Does your config (for the old
> kernel) have anything with PHYSMAP in it?  I suspect it probably broke
> with commit dcb3e137ce9be1dfc86e306182b23e3ae5e239c4 ("[MTD] physmap:
> make physmap compat explicit").

Here is what my 2.6.27 kernel has in the section regarding physmap:

,----
| #
| # Mapping drivers for chip access
| #
| # CONFIG_MTD_COMPLEX_MAPPINGS is not set
| CONFIG_MTD_PHYSMAP=y
| CONFIG_MTD_PHYSMAP_START=0xffc00000
| CONFIG_MTD_PHYSMAP_LEN=0x400000
| CONFIG_MTD_PHYSMAP_BANKWIDTH=1
| # CONFIG_MTD_PHYSMAP_OF is not set
| # CONFIG_MTD_INTEL_VR_NOR is not set
| # CONFIG_MTD_PLATRAM is not set
`----

Here is what my 4.0-rc6 kernel has:

,----
| #
| # Mapping drivers for chip access
| #
| # CONFIG_MTD_COMPLEX_MAPPINGS is not set
| CONFIG_MTD_PHYSMAP=y
| CONFIG_MTD_PHYSMAP_COMPAT=y
| CONFIG_MTD_PHYSMAP_START=0xffc00000
| CONFIG_MTD_PHYSMAP_LEN=0x400000
| CONFIG_MTD_PHYSMAP_BANKWIDTH=1
| CONFIG_MTD_PHYSMAP_OF=y
| # CONFIG_MTD_INTEL_VR_NOR is not set
| # CONFIG_MTD_PLATRAM is not set
`----

I may try to revert locally that patch here to see if things improve or not,
but it will take me some time to compile it (I hope not much).


Thanks,

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFCAAAA
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

)

[Scott Wood]

On Tue, 2015-04-07 at 22:13 -0300, Rogério Brito wrote:
> Hi, Scott.
> 
> On Apr 07 2015, Scott Wood wrote:
> > On Tue, 2015-04-07 at 21:37 -0300, Rogério Brito wrote:
> > > I see. If I do some "archaeology" (read: bisect when it stopped
> > > working), would that help to discover how the flash is connected?
> > 
> > It will probably give you the address and size of the flash, which is
> > good enough to get something working.  Does your config (for the old
> > kernel) have anything with PHYSMAP in it?  I suspect it probably broke
> > with commit dcb3e137ce9be1dfc86e306182b23e3ae5e239c4 ("[MTD] physmap:
> > make physmap compat explicit").
> 
> Here is what my 2.6.27 kernel has in the section regarding physmap:
> 
> ,----
> | #
> | # Mapping drivers for chip access
> | #
> | # CONFIG_MTD_COMPLEX_MAPPINGS is not set
> | CONFIG_MTD_PHYSMAP=y
> | CONFIG_MTD_PHYSMAP_START=0xffc00000
> | CONFIG_MTD_PHYSMAP_LEN=0x400000
> | CONFIG_MTD_PHYSMAP_BANKWIDTH=1
> | # CONFIG_MTD_PHYSMAP_OF is not set
> | # CONFIG_MTD_INTEL_VR_NOR is not set
> | # CONFIG_MTD_PLATRAM is not set
> `----
> 
> Here is what my 4.0-rc6 kernel has:
> 
> ,----
> | #
> | # Mapping drivers for chip access
> | #
> | # CONFIG_MTD_COMPLEX_MAPPINGS is not set
> | CONFIG_MTD_PHYSMAP=y
> | CONFIG_MTD_PHYSMAP_COMPAT=y
> | CONFIG_MTD_PHYSMAP_START=0xffc00000
> | CONFIG_MTD_PHYSMAP_LEN=0x400000
> | CONFIG_MTD_PHYSMAP_BANKWIDTH=1
> | CONFIG_MTD_PHYSMAP_OF=y
> | # CONFIG_MTD_INTEL_VR_NOR is not set
> | # CONFIG_MTD_PLATRAM is not set
> `----
> 
> I may try to revert locally that patch here to see if things improve or not,
> but it will take me some time to compile it (I hope not much).

Oh right, it's the partitions that are missing, rather than the flash
device itself.  It was probably commit
13e0fe49f676607688da7475c33540ec5dac53b5 ("mtd: drop physmap_configure")
that broke your out-of-tree kernel.  Maybe you (or someone) dropped a
call to physmap_set_partitions() to stop the build error, and didn't
replace it with anything?

-Scott

$

[FBI]

      I am here to see that you get all your money that you sent to scammers,get back to us now for all of it

?

[Kristofer Hallin]

But _why_ would you port it? What is the reason behind that? That's just a
lot of work for no reason.
On 29 Aug 2014 17:53, "Ravi Raj" <nrnraviraj@gmail.com> wrote:

> Hii Valdis,
>                   Thank you for the response.We dont want to buy a board
> with pre-configured linux, that is the first point why i asked you guys for
> help, i googled too, i also got hundreds of boards with lot of board
> support packages,every board support package varies from the development
> board, so just as simple as it "i just want a recommendation from you guys
> a good development board where i can port linux from scratch!!"
>
>
> Cheers,
> Ravi.
>
>
>
> On Fri, Aug 29, 2014 at 5:34 PM, <Valdis.Kletnieks@vt.edu> wrote:
>
>> On Fri, 29 Aug 2014 16:58:26 +0200, Ravi Raj said:
>> >                   Thank you for the response ,So the project is a
>> > communication between fpga and a imx6 Arm A9 processor using SPI
>> protocol
>> > and we are making a custom board for this, so first step is to find an
>> imx6
>> > Arm a9 board and port linux to it and then establish SPI.
>>
>> Heck, these guys already have ANdroid Kitkat up and running:
>>
>> http://www.wandboard.org/
>>
>>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140829/e4361eae/attachment-0001.html 

?

[Ravi Raj]

Hii Kristofer,

                    We want to design our own coustom board and we dont
want to depend on the Board support package vendors. But just for a doubt
Has any one ever tried porting a linux kernal in Kernal newbies group it
would be great to get some feedback from you guys.


Cheers,
Ravi.


On Fri, Aug 29, 2014 at 5:55 PM, Kristofer Hallin <
kristofer.hallin@gmail.com> wrote:

> But _why_ would you port it? What is the reason behind that? That's just a
> lot of work for no reason.
> On 29 Aug 2014 17:53, "Ravi Raj" <nrnraviraj@gmail.com> wrote:
>
>> Hii Valdis,
>>                   Thank you for the response.We dont want to buy a board
>> with pre-configured linux, that is the first point why i asked you guys for
>> help, i googled too, i also got hundreds of boards with lot of board
>> support packages,every board support package varies from the development
>> board, so just as simple as it "i just want a recommendation from you guys
>> a good development board where i can port linux from scratch!!"
>>
>>
>> Cheers,
>> Ravi.
>>
>>
>>
>> On Fri, Aug 29, 2014 at 5:34 PM, <Valdis.Kletnieks@vt.edu> wrote:
>>
>>> On Fri, 29 Aug 2014 16:58:26 +0200, Ravi Raj said:
>>> >                   Thank you for the response ,So the project is a
>>> > communication between fpga and a imx6 Arm A9 processor using SPI
>>> protocol
>>> > and we are making a custom board for this, so first step is to find an
>>> imx6
>>> > Arm a9 board and port linux to it and then establish SPI.
>>>
>>> Heck, these guys already have ANdroid Kitkat up and running:
>>>
>>> http://www.wandboard.org/
>>>
>>>
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140829/6a1e5ba6/attachment.html 

?

[Bjørn Mork]

Ravi Raj <nrnraviraj@gmail.com> writes:

>                     We want to design our own coustom board and we dont
> want to depend on the Board support package vendors.

I don't think any vendor forces you to use their support.  You can buy
any board and develop your own Linux support for it, completely ignoring
whatever BSP the vendor provides.

But as others already mentioned:  This seems like a lot of redundant
work for no point whatsoever.  At least no point I get...


Bj?rn

?

[Valdis.Kletnieks at vt.edu]

On Fri, 29 Aug 2014 18:03:33 +0200, Ravi Raj said:

>                     We want to design our own coustom board and we dont
> want to depend on the Board support package vendors.

It's GPL.  So you buy the board, get the initial copy of the kernel already
ported, and then do your own work from there.

Oh - and if you don't follow the terms of the GPL when you ship the product,
we'll have to hunt you down and sue you.  So make sure you have proper plans
for GPL compliance when you ship. :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140829/a36aa115/attachment.bin 

?

[Ravi Raj]

ok!! thank you guys for the responses, seeing some websites like this
http://linuxinsomnia.wordpress.com/how-to-port-linux-to-a-raw-arm-board/ i
thought i can manage to port Linux, yeah I am wrong. so i will follow the
same as you guys!!!


Have a great weekend
Cheers,
Ravi.


On Fri, Aug 29, 2014 at 6:43 PM, <Valdis.Kletnieks@vt.edu> wrote:

> On Fri, 29 Aug 2014 18:03:33 +0200, Ravi Raj said:
>
> >                     We want to design our own coustom board and we dont
> > want to depend on the Board support package vendors.
>
> It's GPL.  So you buy the board, get the initial copy of the kernel already
> ported, and then do your own work from there.
>
> Oh - and if you don't follow the terms of the GPL when you ship the
> product,
> we'll have to hunt you down and sue you.  So make sure you have proper
> plans
> for GPL compliance when you ship. :)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140829/013c7de2/attachment.html 

===================

[Amanda Clarke]

-- 
Are You Interested?  Business & Personal loans: At 3.0% Flexible Repayment period- 2 to 30 Years. 

# #

[Ausilia Alessi]

-- 
Are You Interested? Loan at 3% Interest rate offer.

??

[seyed.jamaly]

is it safe to discuss with you in this email?

??

[jjorge]

is it safe to discuss with you in this email?

!

[Ana Flavia Maria]

-- 
                                     Loan at 3% interest rate Loan offer.. AreYou Interested>?

!

[Ana Flavia Maria]

-- 
                                     Loan at 3% interest rate Loan offer.. AreYou Interested>?

$

[FBI]

This goes out to you  who had lost your money to scammers,email  back to us for your  lost money now....

:

[JOEL SULLINS]

-- 
Avaliable: 3% interest rate Loan Offer + you having the chance to choose your duration. Are you interested?

^……――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――####################・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

[farm228694]

 


 

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

Re: !

[Matt W. Benjamin]

Hi Trond,

I think your point that discussion of alternative ways of doing things which might ultimately be standardized reflects lack of understanding of the concept of standardization is ...  a non-sequitur.

I did state that the standard doesn't benefit from restricting the ability of implementations and applications from evolving new metadata conventions entirely above the file system.  This claim is in no way radical, it's how everyone uses the file system already.

Since I haven't violated any rule of netiquette or convention of polite discussion generally, forgive me for not going away.

Regards,

Matt

----- "Trond Myklebust" <Trond.Myklebust@netapp.com> wrote:

> > You've said that xattrs and named attributes are completely
> different, but notwithstanding that, there seems to be logically quite
> a bit of overlap.  Clearly, the fact that the NFS protocol treats
> named attributes as subfiles is a detail that the client need not
> expose to applications.  It also seems as if an xattr interface is
> convenient for interacting with at a subset of named attributes (ones
> with tractable length names/values).  I mean, as I note, this is the
> proplist, and that has been a very successful interface in a lot of
> systems, going back a -long- ways.
> 
> NO! GO AWAY!!!!
> 
> Seriously, if you don't understand the concept of a standard, then go
> away!
> 
> Trond

-- 
Matt Benjamin
The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309

Re: !

[Myklebust, Trond]

T24gV2VkLCAyMDEyLTExLTE0IGF0IDE1OjM4IC0wNTAwLCBNYXR0IFcuIEJlbmphbWluIHdyb3Rl
Og0KPiBIaSBUcm9uZCwNCj4gDQo+IEkgdGhpbmsgeW91ciBwb2ludCB0aGF0IGRpc2N1c3Npb24g
b2YgYWx0ZXJuYXRpdmUgd2F5cyBvZiBkb2luZyB0aGluZ3Mgd2hpY2ggbWlnaHQgdWx0aW1hdGVs
eSBiZSBzdGFuZGFyZGl6ZWQgcmVmbGVjdHMgbGFjayBvZiB1bmRlcnN0YW5kaW5nIG9mIHRoZSBj
b25jZXB0IG9mIHN0YW5kYXJkaXphdGlvbiBpcyAuLi4gIGEgbm9uLXNlcXVpdHVyLg0KDQpOb2Jv
ZHkgaXMgcmVzdHJpY3RpbmcgeW91ciBhYmlsaXR5IHRvIHdyaXRlIHlvdXIgb3duIHNpZGUtYmFu
ZCBwcm90b2NvbA0Kb3IgZXZlbiBmcm9tIG1ha2luZyBwcm9wb3NhbHMgdG8gdGhlIElFVEYuIFRo
ZSBvbmx5IHJlc3RyaWN0aW9uIGJlaW5nDQppbXBvc2VkIG9uIHlvdSBpcyB0aGF0IHRob3NlIHdv
bid0IGdvIHVwc3RyZWFtIGludG8gdGhlIExpbnV4IGNsaWVudA0KdW50aWwgYWNjb21wYW5pZWQg
d2l0aCBhbiBBUEkgYW5kIGEgc3RhbmRhcmRzLWJhc2VkIHNwZWNpZmljYXRpb24uDQoNCj4gSSBk
aWQgc3RhdGUgdGhhdCB0aGUgc3RhbmRhcmQgZG9lc24ndCBiZW5lZml0IGZyb20gcmVzdHJpY3Rp
bmcgdGhlIGFiaWxpdHkgb2YgaW1wbGVtZW50YXRpb25zIGFuZCBhcHBsaWNhdGlvbnMgZnJvbSBl
dm9sdmluZyBuZXcgbWV0YWRhdGEgY29udmVudGlvbnMgZW50aXJlbHkgYWJvdmUgdGhlIGZpbGUg
c3lzdGVtLiAgVGhpcyBjbGFpbSBpcyBpbiBubyB3YXkgcmFkaWNhbCwgaXQncyBob3cgZXZlcnlv
bmUgdXNlcyB0aGUgZmlsZSBzeXN0ZW0gYWxyZWFkeS4NCg0KTmVpdGhlciBpcyBpdCBjbGVhciB0
aGF0IG1vdmluZyB0aG9zZSBtZXRhZGF0YSBjb252ZW50aW9ucyBpbnRvIHRoZQ0KZmlsZXN5c3Rl
bSBpcyBwYXJ0aWN1bGFybHkgdXNlZnVsLiBTbyBmYXIsIGFsbCB5b3UndmUgZG9uZSBpcyBzcG91
dA0Kd2FudHMsIGFuZCBub3RoaW5nIGFib3V0IGhvdyB0aGlzIGFkZHJlc3NlcyBhIG5lZWQuDQoN
Cj4gU2luY2UgSSBoYXZlbid0IHZpb2xhdGVkIGFueSBydWxlIG9mIG5ldGlxdWV0dGUgb3IgY29u
dmVudGlvbiBvZiBwb2xpdGUgZGlzY3Vzc2lvbiBnZW5lcmFsbHksIGZvcmdpdmUgbWUgZm9yIG5v
dCBnb2luZyBhd2F5Lg0KDQpZb3UgYXJlIHlhbW1lcmluZyBvbiBhbmQgb24gYWJvdXQgc29tZXRo
aW5nIHRoYXQgeW91IHdhbnQgZnJvbSBvdGhlcg0KcGVvcGxlIGluIG9yZGVyIHRvIGJlIGFibGUg
dG8gYnlwYXNzIHRoZWlyIHN0YW5kYXJkIHJldmlldyBwcm9jZXNzIGZvcg0KYWRkaW5nIG5ldyBw
cm90b2NvbCBmZWF0dXJlcy4gSWYgdGhhdCBlcGl0b21pc2VzIHBvbGl0ZQ0KbmV0aXF1ZXR0ZS1m
cmllbmRseSBkaXNjdXNzaW9uIHRoZW4gY291bnQgbWUgb3V0Li4uDQoNCj4gUmVnYXJkcywNCj4g
DQo+IE1hdHQNCj4gDQo+IC0tLS0tICJUcm9uZCBNeWtsZWJ1c3QiIDxUcm9uZC5NeWtsZWJ1c3RA
bmV0YXBwLmNvbT4gd3JvdGU6DQo+IA0KPiA+ID4gWW91J3ZlIHNhaWQgdGhhdCB4YXR0cnMgYW5k
IG5hbWVkIGF0dHJpYnV0ZXMgYXJlIGNvbXBsZXRlbHkNCj4gPiBkaWZmZXJlbnQsIGJ1dCBub3R3
aXRoc3RhbmRpbmcgdGhhdCwgdGhlcmUgc2VlbXMgdG8gYmUgbG9naWNhbGx5IHF1aXRlDQo+ID4g
YSBiaXQgb2Ygb3ZlcmxhcC4gIENsZWFybHksIHRoZSBmYWN0IHRoYXQgdGhlIE5GUyBwcm90b2Nv
bCB0cmVhdHMNCj4gPiBuYW1lZCBhdHRyaWJ1dGVzIGFzIHN1YmZpbGVzIGlzIGEgZGV0YWlsIHRo
YXQgdGhlIGNsaWVudCBuZWVkIG5vdA0KPiA+IGV4cG9zZSB0byBhcHBsaWNhdGlvbnMuICBJdCBh
bHNvIHNlZW1zIGFzIGlmIGFuIHhhdHRyIGludGVyZmFjZSBpcw0KPiA+IGNvbnZlbmllbnQgZm9y
IGludGVyYWN0aW5nIHdpdGggYXQgYSBzdWJzZXQgb2YgbmFtZWQgYXR0cmlidXRlcyAob25lcw0K
PiA+IHdpdGggdHJhY3RhYmxlIGxlbmd0aCBuYW1lcy92YWx1ZXMpLiAgSSBtZWFuLCBhcyBJIG5v
dGUsIHRoaXMgaXMgdGhlDQo+ID4gcHJvcGxpc3QsIGFuZCB0aGF0IGhhcyBiZWVuIGEgdmVyeSBz
dWNjZXNzZnVsIGludGVyZmFjZSBpbiBhIGxvdCBvZg0KPiA+IHN5c3RlbXMsIGdvaW5nIGJhY2sg
YSAtbG9uZy0gd2F5cy4NCj4gPiANCj4gPiBOTyEgR08gQVdBWSEhISENCj4gPiANCj4gPiBTZXJp
b3VzbHksIGlmIHlvdSBkb24ndCB1bmRlcnN0YW5kIHRoZSBjb25jZXB0IG9mIGEgc3RhbmRhcmQs
IHRoZW4gZ28NCj4gPiBhd2F5IQ0KPiA+IA0KPiA+IFRyb25kDQo+IA0KDQotLSANClRyb25kIE15
a2xlYnVzdA0KTGludXggTkZTIGNsaWVudCBtYWludGFpbmVyDQoNCk5ldEFwcA0KVHJvbmQuTXlr
bGVidXN0QG5ldGFwcC5jb20NCnd3dy5uZXRhcHAuY29tDQo=

Re: xattr support in NFS?

[Matt W. Benjamin]

Hi,

feature - yes, an xattr like interface (though with NFSv4, I think I've tended to somewhat conflate in my mind the notions of xattr and named attribute, sorry).

Well, that's the thing.  An interface like xattr is generative.  I don't think the ceiling on use cases is desktop search programs.  The potential utility of the feature is something that comes to light over time, when you know you have the functionality available.  For example, the Ceph developers came up recently with an algorithm to store information related to links in a special xattr.  We've thought of exposing file checksum information as attributes.  My sense of how many potential uses there may be is related mostly, as with Tigran's remark, to the number of times I've heard someone say, "we could solve that with an xattr/named attribute."

You've said that xattrs and named attributes are completely different, but notwithstanding that, there seems to be logically quite a bit of overlap.  Clearly, the fact that the NFS protocol treats named attributes as subfiles is a detail that the client need not expose to applications.  It also seems as if an xattr interface is convenient for interacting with at a subset of named attributes (ones with tractable length names/values).  I mean, as I note, this is the proplist, and that has been a very successful interface in a lot of systems, going back a -long- ways.

Matt

----- "Trond Myklebust" <Trond.Myklebust@netapp.com> wrote:

> On Wed, 2012-11-14 at 10:20 -0500, Matt W. Benjamin wrote:
> > Actually, that reasoning sounds a little like a concession that the
> feature should be blocked precisely because it may be tremendously
> popular (useful).  I don't think the argument that proplists can be
> the building blocks for new system--but also
> application--functionality is a good argument against them.
> 
> What feature? The xattr interface? Before declaring it a major
> success
> story, you might want to consider that it has been implemented on
> several major Linux filesystems for more that 10 years, yet is used
> by
> only a handful of (non-portable) applications.
> 
> The main use-cases that I'm aware of are:
>       * Storage for ACLs.
>       * Storage for security labels.
>       * Samba uses xattrs for storing various per-file control
>         structures, when xattrs are supported by the underlying
>         filesystem.
>       * Storage for file search tags for use by programs such as
>         "beagle" and "tracker".
> 
> Both ACLs and security labels are already covered by the NFS
> protocol.
> We don't need or want an xattr protocol to solve those problems.
> 
> As for Samba, it works fine on filesystems that don't have xattrs as
> far
> as I know. Using it to re-export an NFS partition to CIFS is a
> dubious
> practice, but is not an xattr-related problem.
> 
> So that leaves the "beagle" and "tracker" use case, where the xattr
> usage for storing tags could easily be replaced by a database (and
> usually is in equivalent portable software). Most people who want to
> do
> serious work on their systems tend to turn off beagle and tracker
> anyway
> since they are notorious cpu hogs.
> 
> > ----- "Trond Myklebust" <Trond.Myklebust@netapp.com> wrote:
> > 
> > > On Wed, 2012-11-14 at 11:47 +0100, Tigran Mkrtchyan wrote:
> > > > That's bad news.... Currently we use 'magic files' to set/get
> user
> > > > specific metadata like number of events, space reservation   
> and
> > > > different file retention policies. The hope was that all could
> be
> > > done
> > > > with named attributes.
> > > >
> > > >  Tigran.
> > > >  
> > > 
> > > The setting and querying of retention policies is already covered
> in
> > > the
> > > NFSv4.1 protocol without any need for any additions. Space
> > > reservation
> > > is already covered in NFSv4.2 (as are security labels - another
> > > common
> > > hobby-horse for xattr advocates). Why don't you implement those
> > > instead
> > > of wishing for a completely different way of doing the same
> thing?
> > > 
> > > Your argument demonstrates precisely why we should never do
> xattrs
> > > over
> > > NFS. It makes it way too easy to go off and invent your own
> private
> > > and
> > > non-standard protocol for doing ioctl()-like RPC calls.
> > > 
> > > > On Tue, Nov 13, 2012 at 8:54 AM, DENIEL Philippe
> > > > <philippe.deniel@cea.fr> wrote:
> > > >         A few years ago, SGI tried to promote "NFS3 XATTR", an
> > > >         extension to NFSv3 to add xattr support. It roughly
> added 3
> > > >         functions to the protocol (GETXATTR, SETXATTR,
> LISTXATTR),
> > > in
> > > >         a similar way as what 9p.2000L does. Nothing but IRIX
> had
> > > this
> > > >         NFSv3 feature. As far as I know, it remained quite
> exotic
> > > and
> > > >         stayed a SGI's thing.
> > > >         
> > > >            Philippe
> > > >         
> > > >         Matt W. Benjamin a écrit :
> > > >         
> > > >                 Can you restate reasoning why it will never do
> so,
> > > and
> > > >                 whether this is the same as saying it will
> never
> > > >                 implement named attributes?
> > > >                 
> > > >                 Thanks,
> > > >                 
> > > >                 Matt
> > > >                 
> > > >                 ----- "Trond Myklebust"
> > > <Trond.Myklebust@netapp.com>
> > > >                 wrote:
> > > >                 
> > > >                   
> > > >                         No. We will never support xattrs over
> NFS.
> > > >                         
> > > >                             
> > > >                                 -----Original Message-----
> > > >                                 From:
> > > linux-nfs-owner@vger.kernel.org
> > > >                                 [mailto:linux-nfs-
> > > >                                 owner@vger.kernel.org] On Behalf
> Of
> > > >                                 Tomasz Chmielewski
> > > >                                 Sent: Monday, November 12, 2012
> > > 10:14
> > > >                                 AM
> > > >                                 To: linux-nfs@vger.kernel.org
> > > >                                 Subject: xattr support in NFS?
> > > >                                 
> > > >                                 Does Linux support xattr in
> NFS?
> > > >                                 
> > > >                                 IF tries using it in both NFS3
> and
> > > >                                 NFS4 under Debian Lenny
> (2.6.32,
> > > >                                       
> > > >                         both
> > > >                             
> > > >                                 server and client), without
> > > success.
> > > >                                 
> > > >                                 # setfattr -n user.comment -v
> "this
> > > is
> > > >                                 a comment" /mnt/nfs
> > > >                                 setfattr: /mnt/nfs: Operation
> not
> > > >                                 supported
> > > >                                 
> > > >                                 
> > > >                                 --
> > > >                                 Tomasz Chmielewski
> > > >                                 http://blog.wpkg.org
> > > >                                 --
> > > >                                 To unsubscribe from this list:
> send
> > > >                                 the line "unsubscribe
> linux-nfs"
> > > >                                       
> > > >                         in the
> > > >                             
> > > >                                 body of a message to
> > > >                                 majordomo@vger.kernel.org More
> > > >                                 majordomo info
> > > >                                       
> > > >                         at
> > > >                             
> > > >                                
> > > http://vger.kernel.org/majordomo-info.html
> > > >                                       
> > > >                         N�����r��y���b�X��ǧv�^�)޺{.n�
> > > >                        
> +����{���"��^n�r���z���h����&���G���h�(�階
>  <> >                         �ݢj"���m�����z�ޖ���f���h���~�m�
> > > >                             
> > > >                 
> > > >                   
> > > >         
> > > >         --
> > > >         To unsubscribe from this list: send the line
> "unsubscribe
> > > >         linux-nfs" in
> > > >         the body of a message to majordomo@vger.kernel.org
> > > >         More majordomo info at
> > > >          http://vger.kernel.org/majordomo-info.html
> > > >         
> > > > 
> > > > 
> > > 
> > > -- 
> > > Trond Myklebust
> > > Linux NFS client maintainer
> > > 
> > > NetApp
> > > Trond.Myklebust@netapp.com
> > > www.netapp.com
> > >
> N�����r��y���b�X��ǧv�^�)޺{.n�+����{���"��^n�r���z���h����&���G���h�(�階�ݢj"���m�����z�ޖ���f���h���~�m�
> > 
> 
> -- 
> Trond Myklebust
> Linux NFS client maintainer
> 
> NetApp
> Trond.Myklebust@netapp.com
> www.netapp.com

-- 
Matt Benjamin
The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309

!

[Myklebust, Trond]

T24gV2VkLCAyMDEyLTExLTE0IGF0IDE1OjEzIC0wNTAwLCBNYXR0IFcuIEJlbmphbWluIHdyb3Rl
Og0KPiBIaSwNCj4gDQo+IGZlYXR1cmUgLSB5ZXMsIGFuIHhhdHRyIGxpa2UgaW50ZXJmYWNlICh0
aG91Z2ggd2l0aCBORlN2NCwgSSB0aGluayBJJ3ZlIHRlbmRlZCB0byBzb21ld2hhdCBjb25mbGF0
ZSBpbiBteSBtaW5kIHRoZSBub3Rpb25zIG9mIHhhdHRyIGFuZCBuYW1lZCBhdHRyaWJ1dGUsIHNv
cnJ5KS4NCj4gDQo+IFdlbGwsIHRoYXQncyB0aGUgdGhpbmcuICBBbiBpbnRlcmZhY2UgbGlrZSB4
YXR0ciBpcyBnZW5lcmF0aXZlLiAgSSBkb24ndCB0aGluayB0aGUgY2VpbGluZyBvbiB1c2UgY2Fz
ZXMgaXMgZGVza3RvcCBzZWFyY2ggcHJvZ3JhbXMuICBUaGUgcG90ZW50aWFsIHV0aWxpdHkgb2Yg
dGhlIGZlYXR1cmUgaXMgc29tZXRoaW5nIHRoYXQgY29tZXMgdG8gbGlnaHQgb3ZlciB0aW1lLCB3
aGVuIHlvdSBrbm93IHlvdSBoYXZlIHRoZSBmdW5jdGlvbmFsaXR5IGF2YWlsYWJsZS4gIEZvciBl
eGFtcGxlLCB0aGUgQ2VwaCBkZXZlbG9wZXJzIGNhbWUgdXAgcmVjZW50bHkgd2l0aCBhbiBhbGdv
cml0aG0gdG8gc3RvcmUgaW5mb3JtYXRpb24gcmVsYXRlZCB0byBsaW5rcyBpbiBhIHNwZWNpYWwg
eGF0dHIuICBXZSd2ZSB0aG91Z2h0IG9mIGV4cG9zaW5nIGZpbGUgY2hlY2tzdW0gaW5mb3JtYXRp
b24gYXMgYXR0cmlidXRlcy4gIE15IHNlbnNlIG9mIGhvdyBtYW55IHBvdGVudGlhbCB1c2VzIHRo
ZXJlIG1heSBiZSBpcyByZWxhdGVkIG1vc3RseSwgYXMgd2l0aCBUaWdyYW4ncyByZW1hcmssIHRv
IHRoZSBudW1iZXIgb2YgdGltZXMgSSd2ZSBoZWFyZCBzb21lb25lIHNheSwgIndlIGNvdWxkIHNv
bHZlIHRoYXQgd2l0aCBhbiB4YXR0ci9uYW1lZCBhdHRyaWJ1dGUuIg0KDQpJZiBpdCBpcyBhIGZl
YXR1cmUgd2hpY2ggaXMgb25seSBhdmFpbGFibGUgaWYgdGhlIHVuZGVybHlpbmcgZmlsZXN5c3Rl
bQ0KaGFwcGVucyB0byBiZSBDZXBoLCB0aGVuIHdoeSBleHBvc2UgaXQgb3ZlciBORlMgYXQgYWxs
PyBKdXN0IGhhdmUgeW91cg0KY3VzdG9tZXIgcnVuIGEgQ2VwaCBjbGllbnQgYW5kIGJlIGhhcHB5
Lg0KDQpUaGUgcG9pbnQgb2YgdXNpbmcgTkZTIGlzIHRvIF9zdGFuZGFyZGlzZV8uDQoNCj4gWW91
J3ZlIHNhaWQgdGhhdCB4YXR0cnMgYW5kIG5hbWVkIGF0dHJpYnV0ZXMgYXJlIGNvbXBsZXRlbHkg
ZGlmZmVyZW50LCBidXQgbm90d2l0aHN0YW5kaW5nIHRoYXQsIHRoZXJlIHNlZW1zIHRvIGJlIGxv
Z2ljYWxseSBxdWl0ZSBhIGJpdCBvZiBvdmVybGFwLiAgQ2xlYXJseSwgdGhlIGZhY3QgdGhhdCB0
aGUgTkZTIHByb3RvY29sIHRyZWF0cyBuYW1lZCBhdHRyaWJ1dGVzIGFzIHN1YmZpbGVzIGlzIGEg
ZGV0YWlsIHRoYXQgdGhlIGNsaWVudCBuZWVkIG5vdCBleHBvc2UgdG8gYXBwbGljYXRpb25zLiAg
SXQgYWxzbyBzZWVtcyBhcyBpZiBhbiB4YXR0ciBpbnRlcmZhY2UgaXMgY29udmVuaWVudCBmb3Ig
aW50ZXJhY3Rpbmcgd2l0aCBhdCBhIHN1YnNldCBvZiBuYW1lZCBhdHRyaWJ1dGVzIChvbmVzIHdp
dGggdHJhY3RhYmxlIGxlbmd0aCBuYW1lcy92YWx1ZXMpLiAgSSBtZWFuLCBhcyBJIG5vdGUsIHRo
aXMgaXMgdGhlIHByb3BsaXN0LCBhbmQgdGhhdCBoYXMgYmVlbiBhIHZlcnkgc3VjY2Vzc2Z1bCBp
bnRlcmZhY2UgaW4gYSBsb3Qgb2Ygc3lzdGVtcywgZ29pbmcgYmFjayBhIC1sb25nLSB3YXlzLg0K
DQpOTyEgR08gQVdBWSEhISENCg0KU2VyaW91c2x5LCBpZiB5b3UgZG9uJ3QgdW5kZXJzdGFuZCB0
aGUgY29uY2VwdCBvZiBhIHN0YW5kYXJkLCB0aGVuIGdvDQphd2F5IQ0KDQpUcm9uZA0KDQo+IE1h
dHQNCj4gDQo+IC0tLS0tICJUcm9uZCBNeWtsZWJ1c3QiIDxUcm9uZC5NeWtsZWJ1c3RAbmV0YXBw
LmNvbT4gd3JvdGU6DQo+IA0KPiA+IE9uIFdlZCwgMjAxMi0xMS0xNCBhdCAxMDoyMCAtMDUwMCwg
TWF0dCBXLiBCZW5qYW1pbiB3cm90ZToNCj4gPiA+IEFjdHVhbGx5LCB0aGF0IHJlYXNvbmluZyBz
b3VuZHMgYSBsaXR0bGUgbGlrZSBhIGNvbmNlc3Npb24gdGhhdCB0aGUNCj4gPiBmZWF0dXJlIHNo
b3VsZCBiZSBibG9ja2VkIHByZWNpc2VseSBiZWNhdXNlIGl0IG1heSBiZSB0cmVtZW5kb3VzbHkN
Cj4gPiBwb3B1bGFyICh1c2VmdWwpLiAgSSBkb24ndCB0aGluayB0aGUgYXJndW1lbnQgdGhhdCBw
cm9wbGlzdHMgY2FuIGJlDQo+ID4gdGhlIGJ1aWxkaW5nIGJsb2NrcyBmb3IgbmV3IHN5c3RlbS0t
YnV0IGFsc28NCj4gPiBhcHBsaWNhdGlvbi0tZnVuY3Rpb25hbGl0eSBpcyBhIGdvb2QgYXJndW1l
bnQgYWdhaW5zdCB0aGVtLg0KPiA+IA0KPiA+IFdoYXQgZmVhdHVyZT8gVGhlIHhhdHRyIGludGVy
ZmFjZT8gQmVmb3JlIGRlY2xhcmluZyBpdCBhIG1ham9yDQo+ID4gc3VjY2Vzcw0KPiA+IHN0b3J5
LCB5b3UgbWlnaHQgd2FudCB0byBjb25zaWRlciB0aGF0IGl0IGhhcyBiZWVuIGltcGxlbWVudGVk
IG9uDQo+ID4gc2V2ZXJhbCBtYWpvciBMaW51eCBmaWxlc3lzdGVtcyBmb3IgbW9yZSB0aGF0IDEw
IHllYXJzLCB5ZXQgaXMgdXNlZA0KPiA+IGJ5DQo+ID4gb25seSBhIGhhbmRmdWwgb2YgKG5vbi1w
b3J0YWJsZSkgYXBwbGljYXRpb25zLg0KPiA+IA0KPiA+IFRoZSBtYWluIHVzZS1jYXNlcyB0aGF0
IEknbSBhd2FyZSBvZiBhcmU6DQo+ID4gICAgICAgKiBTdG9yYWdlIGZvciBBQ0xzLg0KPiA+ICAg
ICAgICogU3RvcmFnZSBmb3Igc2VjdXJpdHkgbGFiZWxzLg0KPiA+ICAgICAgICogU2FtYmEgdXNl
cyB4YXR0cnMgZm9yIHN0b3JpbmcgdmFyaW91cyBwZXItZmlsZSBjb250cm9sDQo+ID4gICAgICAg
ICBzdHJ1Y3R1cmVzLCB3aGVuIHhhdHRycyBhcmUgc3VwcG9ydGVkIGJ5IHRoZSB1bmRlcmx5aW5n
DQo+ID4gICAgICAgICBmaWxlc3lzdGVtLg0KPiA+ICAgICAgICogU3RvcmFnZSBmb3IgZmlsZSBz
ZWFyY2ggdGFncyBmb3IgdXNlIGJ5IHByb2dyYW1zIHN1Y2ggYXMNCj4gPiAgICAgICAgICJiZWFn
bGUiIGFuZCAidHJhY2tlciIuDQo+ID4gDQo+ID4gQm90aCBBQ0xzIGFuZCBzZWN1cml0eSBsYWJl
bHMgYXJlIGFscmVhZHkgY292ZXJlZCBieSB0aGUgTkZTDQo+ID4gcHJvdG9jb2wuDQo+ID4gV2Ug
ZG9uJ3QgbmVlZCBvciB3YW50IGFuIHhhdHRyIHByb3RvY29sIHRvIHNvbHZlIHRob3NlIHByb2Js
ZW1zLg0KPiA+IA0KPiA+IEFzIGZvciBTYW1iYSwgaXQgd29ya3MgZmluZSBvbiBmaWxlc3lzdGVt
cyB0aGF0IGRvbid0IGhhdmUgeGF0dHJzIGFzDQo+ID4gZmFyDQo+ID4gYXMgSSBrbm93LiBVc2lu
ZyBpdCB0byByZS1leHBvcnQgYW4gTkZTIHBhcnRpdGlvbiB0byBDSUZTIGlzIGENCj4gPiBkdWJp
b3VzDQo+ID4gcHJhY3RpY2UsIGJ1dCBpcyBub3QgYW4geGF0dHItcmVsYXRlZCBwcm9ibGVtLg0K
PiA+IA0KPiA+IFNvIHRoYXQgbGVhdmVzIHRoZSAiYmVhZ2xlIiBhbmQgInRyYWNrZXIiIHVzZSBj
YXNlLCB3aGVyZSB0aGUgeGF0dHINCj4gPiB1c2FnZSBmb3Igc3RvcmluZyB0YWdzIGNvdWxkIGVh
c2lseSBiZSByZXBsYWNlZCBieSBhIGRhdGFiYXNlIChhbmQNCj4gPiB1c3VhbGx5IGlzIGluIGVx
dWl2YWxlbnQgcG9ydGFibGUgc29mdHdhcmUpLiBNb3N0IHBlb3BsZSB3aG8gd2FudCB0bw0KPiA+
IGRvDQo+ID4gc2VyaW91cyB3b3JrIG9uIHRoZWlyIHN5c3RlbXMgdGVuZCB0byB0dXJuIG9mZiBi
ZWFnbGUgYW5kIHRyYWNrZXINCj4gPiBhbnl3YXkNCj4gPiBzaW5jZSB0aGV5IGFyZSBub3Rvcmlv
dXMgY3B1IGhvZ3MuDQo+ID4gDQo+ID4gPiAtLS0tLSAiVHJvbmQgTXlrbGVidXN0IiA8VHJvbmQu
TXlrbGVidXN0QG5ldGFwcC5jb20+IHdyb3RlOg0KPiA+ID4gDQo+ID4gPiA+IE9uIFdlZCwgMjAx
Mi0xMS0xNCBhdCAxMTo0NyArMDEwMCwgVGlncmFuIE1rcnRjaHlhbiB3cm90ZToNCj4gPiA+ID4g
PiBUaGF0J3MgYmFkIG5ld3MuLi4uIEN1cnJlbnRseSB3ZSB1c2UgJ21hZ2ljIGZpbGVzJyB0byBz
ZXQvZ2V0DQo+ID4gdXNlcg0KPiA+ID4gPiA+IHNwZWNpZmljIG1ldGFkYXRhIGxpa2UgbnVtYmVy
IG9mIGV2ZW50cywgc3BhY2UgcmVzZXJ2YXRpb24gICANCj4gPiBhbmQNCj4gPiA+ID4gPiBkaWZm
ZXJlbnQgZmlsZSByZXRlbnRpb24gcG9saWNpZXMuIFRoZSBob3BlIHdhcyB0aGF0IGFsbCBjb3Vs
ZA0KPiA+IGJlDQo+ID4gPiA+IGRvbmUNCj4gPiA+ID4gPiB3aXRoIG5hbWVkIGF0dHJpYnV0ZXMu
DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiAgVGlncmFuLg0KPiA+ID4gPiA+ICANCj4gPiA+ID4gDQo+
ID4gPiA+IFRoZSBzZXR0aW5nIGFuZCBxdWVyeWluZyBvZiByZXRlbnRpb24gcG9saWNpZXMgaXMg
YWxyZWFkeSBjb3ZlcmVkDQo+ID4gaW4NCj4gPiA+ID4gdGhlDQo+ID4gPiA+IE5GU3Y0LjEgcHJv
dG9jb2wgd2l0aG91dCBhbnkgbmVlZCBmb3IgYW55IGFkZGl0aW9ucy4gU3BhY2UNCj4gPiA+ID4g
cmVzZXJ2YXRpb24NCj4gPiA+ID4gaXMgYWxyZWFkeSBjb3ZlcmVkIGluIE5GU3Y0LjIgKGFzIGFy
ZSBzZWN1cml0eSBsYWJlbHMgLSBhbm90aGVyDQo+ID4gPiA+IGNvbW1vbg0KPiA+ID4gPiBob2Ji
eS1ob3JzZSBmb3IgeGF0dHIgYWR2b2NhdGVzKS4gV2h5IGRvbid0IHlvdSBpbXBsZW1lbnQgdGhv
c2UNCj4gPiA+ID4gaW5zdGVhZA0KPiA+ID4gPiBvZiB3aXNoaW5nIGZvciBhIGNvbXBsZXRlbHkg
ZGlmZmVyZW50IHdheSBvZiBkb2luZyB0aGUgc2FtZQ0KPiA+IHRoaW5nPw0KPiA+ID4gPiANCj4g
PiA+ID4gWW91ciBhcmd1bWVudCBkZW1vbnN0cmF0ZXMgcHJlY2lzZWx5IHdoeSB3ZSBzaG91bGQg
bmV2ZXIgZG8NCj4gPiB4YXR0cnMNCj4gPiA+ID4gb3Zlcg0KPiA+ID4gPiBORlMuIEl0IG1ha2Vz
IGl0IHdheSB0b28gZWFzeSB0byBnbyBvZmYgYW5kIGludmVudCB5b3VyIG93bg0KPiA+IHByaXZh
dGUNCj4gPiA+ID4gYW5kDQo+ID4gPiA+IG5vbi1zdGFuZGFyZCBwcm90b2NvbCBmb3IgZG9pbmcg
aW9jdGwoKS1saWtlIFJQQyBjYWxscy4NCj4gPiA+ID4gDQo+ID4gPiA+ID4gT24gVHVlLCBOb3Yg
MTMsIDIwMTIgYXQgODo1NCBBTSwgREVOSUVMIFBoaWxpcHBlDQo+ID4gPiA+ID4gPHBoaWxpcHBl
LmRlbmllbEBjZWEuZnI+IHdyb3RlOg0KPiA+ID4gPiA+ICAgICAgICAgQSBmZXcgeWVhcnMgYWdv
LCBTR0kgdHJpZWQgdG8gcHJvbW90ZSAiTkZTMyBYQVRUUiIsIGFuDQo+ID4gPiA+ID4gICAgICAg
ICBleHRlbnNpb24gdG8gTkZTdjMgdG8gYWRkIHhhdHRyIHN1cHBvcnQuIEl0IHJvdWdobHkNCj4g
PiBhZGRlZCAzDQo+ID4gPiA+ID4gICAgICAgICBmdW5jdGlvbnMgdG8gdGhlIHByb3RvY29sIChH
RVRYQVRUUiwgU0VUWEFUVFIsDQo+ID4gTElTVFhBVFRSKSwNCj4gPiA+ID4gaW4NCj4gPiA+ID4g
PiAgICAgICAgIGEgc2ltaWxhciB3YXkgYXMgd2hhdCA5cC4yMDAwTCBkb2VzLiBOb3RoaW5nIGJ1
dCBJUklYDQo+ID4gaGFkDQo+ID4gPiA+IHRoaXMNCj4gPiA+ID4gPiAgICAgICAgIE5GU3YzIGZl
YXR1cmUuIEFzIGZhciBhcyBJIGtub3csIGl0IHJlbWFpbmVkIHF1aXRlDQo+ID4gZXhvdGljDQo+
ID4gPiA+IGFuZA0KPiA+ID4gPiA+ICAgICAgICAgc3RheWVkIGEgU0dJJ3MgdGhpbmcuDQo+ID4g
PiA+ID4gICAgICAgICANCj4gPiA+ID4gPiAgICAgICAgICAgIFBoaWxpcHBlDQo+ID4gPiA+ID4g
ICAgICAgICANCj4gPiA+ID4gPiAgICAgICAgIE1hdHQgVy4gQmVuamFtaW4gYSDDqWNyaXQgOg0K
PiA+ID4gPiA+ICAgICAgICAgDQo+ID4gPiA+ID4gICAgICAgICAgICAgICAgIENhbiB5b3UgcmVz
dGF0ZSByZWFzb25pbmcgd2h5IGl0IHdpbGwgbmV2ZXIgZG8NCj4gPiBzbywNCj4gPiA+ID4gYW5k
DQo+ID4gPiA+ID4gICAgICAgICAgICAgICAgIHdoZXRoZXIgdGhpcyBpcyB0aGUgc2FtZSBhcyBz
YXlpbmcgaXQgd2lsbA0KPiA+IG5ldmVyDQo+ID4gPiA+ID4gICAgICAgICAgICAgICAgIGltcGxl
bWVudCBuYW1lZCBhdHRyaWJ1dGVzPw0KPiA+ID4gPiA+ICAgICAgICAgICAgICAgICANCj4gPiA+
ID4gPiAgICAgICAgICAgICAgICAgVGhhbmtzLA0KPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAN
Cj4gPiA+ID4gPiAgICAgICAgICAgICAgICAgTWF0dA0KPiA+ID4gPiA+ICAgICAgICAgICAgICAg
ICANCj4gPiA+ID4gPiAgICAgICAgICAgICAgICAgLS0tLS0gIlRyb25kIE15a2xlYnVzdCINCj4g
PiA+ID4gPFRyb25kLk15a2xlYnVzdEBuZXRhcHAuY29tPg0KPiA+ID4gPiA+ICAgICAgICAgICAg
ICAgICB3cm90ZToNCj4gPiA+ID4gPiAgICAgICAgICAgICAgICAgDQo+ID4gPiA+ID4gICAgICAg
ICAgICAgICAgICAgDQo+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgTm8uIFdlIHdp
bGwgbmV2ZXIgc3VwcG9ydCB4YXR0cnMgb3Zlcg0KPiA+IE5GUy4NCj4gPiA+ID4gPiAgICAgICAg
ICAgICAgICAgICAgICAgICANCj4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
DQo+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
RnJvbToNCj4gPiA+ID4gbGludXgtbmZzLW93bmVyQHZnZXIua2VybmVsLm9yZw0KPiA+ID4gPiA+
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW21haWx0bzpsaW51eC1uZnMtDQo+ID4g
PiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvd25lckB2Z2VyLmtlcm5lbC5v
cmddIE9uIEJlaGFsZg0KPiA+IE9mDQo+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBUb21hc3ogQ2htaWVsZXdza2kNCj4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMTIsIDIwMTINCj4gPiA+ID4gMTA6
MTQNCj4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFNDQo+ID4gPiA+
ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUbzogbGludXgtbmZzQHZnZXIua2Vy
bmVsLm9yZw0KPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU3ViamVj
dDogeGF0dHIgc3VwcG9ydCBpbiBORlM/DQo+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICANCj4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIERv
ZXMgTGludXggc3VwcG9ydCB4YXR0ciBpbg0KPiA+IE5GUz8NCj4gPiA+ID4gPiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIA0KPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgSUYgdHJpZXMgdXNpbmcgaXQgaW4gYm90aCBORlMzDQo+ID4gYW5kDQo+ID4gPiA+
ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBORlM0IHVuZGVyIERlYmlhbiBMZW5u
eQ0KPiA+ICgyLjYuMzIsDQo+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICANCj4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICBib3RoDQo+ID4gPiA+
ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KPiA+ID4gPiA+ICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgc2VydmVyIGFuZCBjbGllbnQpLCB3aXRob3V0DQo+ID4gPiA+IHN1
Y2Nlc3MuDQo+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCj4gPiA+
ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICMgc2V0ZmF0dHIgLW4gdXNlci5j
b21tZW50IC12DQo+ID4gInRoaXMNCj4gPiA+ID4gaXMNCj4gPiA+ID4gPiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGEgY29tbWVudCIgL21udC9uZnMNCj4gPiA+ID4gPiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHNldGZhdHRyOiAvbW50L25mczogT3BlcmF0aW9uDQo+
ID4gbm90DQo+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdXBwb3J0
ZWQNCj4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KPiA+ID4gPiA+
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+ID4gPiA+ID4gICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAtLQ0KPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgVG9tYXN6IENobWllbGV3c2tpDQo+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBodHRwOi8vYmxvZy53cGtnLm9yZw0KPiA+ID4gPiA+ICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgLS0NCj4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIFRvIHVuc3Vic2NyaWJlIGZyb20gdGhpcyBsaXN0Og0KPiA+IHNlbmQNCj4gPiA+
ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZSBsaW5lICJ1bnN1YnNjcmli
ZQ0KPiA+IGxpbnV4LW5mcyINCj4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIA0KPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAgIGluIHRoZQ0KPiA+
ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCj4gPiA+ID4gPiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIGJvZHkgb2YgYSBtZXNzYWdlIHRvDQo+ID4gPiA+ID4gICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtYWpvcmRvbW9Admdlci5rZXJuZWwub3JnIE1v
cmUNCj4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1ham9yZG9tbyBp
bmZvDQo+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCj4g
PiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICBhdA0KPiA+ID4gPiA+ICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICANCj4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgDQo+ID4gPiA+IGh0dHA6Ly92Z2VyLmtlcm5lbC5vcmcvbWFqb3Jkb21vLWluZm8uaHRtbA0K
PiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+ID4gPiA+
ID4gICAgICAgICAgICAgICAgICAgICAgICAgTu+/ve+/ve+/ve+/ve+/vXLvv73vv71577+977+9
77+9Yu+/vVjvv73vv73Hp3bvv71e77+9Kd66ey5u77+9DQo+ID4gPiA+ID4gICAgICAgICAgICAg
ICAgICAgICAgICANCj4gPiAr77+977+977+977+9e++/ve+/ve+/vSLvv73vv71ebu+/vXLvv73v
v73vv71677+977+977+9aO+/ve+/ve+/ve+/vSbvv73vv73vv71H77+977+977+9aO+/vSjvv73p
mo4NCiA8PiAgPD4gPiAgICAgICAgICAgICAgICAgICAgICAgICDvv73domoi77+977+977+9be+/
ve+/ve+/ve+/ve+/vXrvv73elu+/ve+/ve+/vWbvv73vv73vv71o77+977+977+9fu+/vW3vv70N
Cj4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+ID4gPiA+ID4gICAgICAg
ICAgICAgICAgIA0KPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgIA0KPiA+ID4gPiA+ICAgICAg
ICAgDQo+ID4gPiA+ID4gICAgICAgICAtLQ0KPiA+ID4gPiA+ICAgICAgICAgVG8gdW5zdWJzY3Jp
YmUgZnJvbSB0aGlzIGxpc3Q6IHNlbmQgdGhlIGxpbmUNCj4gPiAidW5zdWJzY3JpYmUNCj4gPiA+
ID4gPiAgICAgICAgIGxpbnV4LW5mcyIgaW4NCj4gPiA+ID4gPiAgICAgICAgIHRoZSBib2R5IG9m
IGEgbWVzc2FnZSB0byBtYWpvcmRvbW9Admdlci5rZXJuZWwub3JnDQo+ID4gPiA+ID4gICAgICAg
ICBNb3JlIG1ham9yZG9tbyBpbmZvIGF0DQo+ID4gPiA+ID4gICAgICAgICAgaHR0cDovL3ZnZXIu
a2VybmVsLm9yZy9tYWpvcmRvbW8taW5mby5odG1sDQo+ID4gPiA+ID4gICAgICAgICANCj4gPiA+
ID4gPiANCj4gPiA+ID4gPiANCj4gPiA+ID4gDQo+ID4gPiA+IC0tIA0KPiA+ID4gPiBUcm9uZCBN
eWtsZWJ1c3QNCj4gPiA+ID4gTGludXggTkZTIGNsaWVudCBtYWludGFpbmVyDQo+ID4gPiA+IA0K
PiA+ID4gPiBOZXRBcHANCj4gPiA+ID4gVHJvbmQuTXlrbGVidXN0QG5ldGFwcC5jb20NCj4gPiA+
ID4gd3d3Lm5ldGFwcC5jb20NCj4gPiA+ID4NCj4gPiBO77+977+977+977+977+9cu+/ve+/vXnv
v73vv73vv71i77+9WO+/ve+/vcendu+/vV7vv70p3rp7Lm7vv70r77+977+977+977+9e++/ve+/
ve+/vSLvv73vv71ebu+/vXLvv73vv73vv71677+977+977+9aO+/ve+/ve+/ve+/vSbvv73vv73v
v71H77+977+977+9aO+/vSjvv73pmo7vv73domoi77+977+977+9be+/ve+/ve+/ve+/ve+/vXrv
v73elu+/ve+/ve+/vWbvv73vv73vv71o77+977+977+9fu+/vW3vv70NCj4gPiA+IA0KPiA+IA0K
PiA+IC0tIA0KPiA+IFRyb25kIE15a2xlYnVzdA0KPiA+IExpbnV4IE5GUyBjbGllbnQgbWFpbnRh
aW5lcg0KPiA+IA0KPiA+IE5ldEFwcA0KPiA+IFRyb25kLk15a2xlYnVzdEBuZXRhcHAuY29tDQo+
ID4gd3d3Lm5ldGFwcC5jb20NCj4gDQoNCi0tIA0KVHJvbmQgTXlrbGVidXN0DQpMaW51eCBORlMg
Y2xpZW50IG1haW50YWluZXINCg0KTmV0QXBwDQpUcm9uZC5NeWtsZWJ1c3RAbmV0YXBwLmNvbQ0K
d3d3Lm5ldGFwcC5jb20NCg==

ãîðÿ÷àÿ Àíýëÿ õî÷åò ïîùóïàòü âàñ!!!!!

[polesky]

http://url.az/bnv

губастая  Беатриса  раздвигает ноги для тебя!!!!!

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

$

[Xli]

My name is Sgt. Benny Brooker. I am in the Engineering military unit  
here in Ba'qubah in Iraq; we have some amount of funds that we want to  
move out of the country. REPLY VIA THIS EMAIL: (sgt.benny@w.cn)

-------------------------------------------------------------------------
  Sent via webmail for Chemistry & Biochemistry @ Florida State University
  https://webmail.chem.fsu.edu




-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

$

[Xli]

My name is Sgt. Benny Brooker. I am in the Engineering military unit  
here in Ba'qubah in Iraq; we have some amount of funds that we want to  
move out of the country. REPLY VIA THIS EMAIL: (sgt.benny@w.cn)

-------------------------------------------------------------------------
  Sent via webmail for Chemistry & Biochemistry @ Florida State University
  https://webmail.chem.fsu.edu




-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

$

[Xli]

My name is Sgt. Benny Brooker. I am in the Engineering military unit  
here in Ba'qubah in Iraq; we have some amount of funds that we want to  
move out of the country. REPLY VIA THIS EMAIL: (sgt.benny@w.cn)

-------------------------------------------------------------------------
  Sent via webmail for Chemistry & Biochemistry @ Florida State University
  https://webmail.chem.fsu.edu




-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

$

[Xli]

My name is Sgt. Benny Brooker. I am in the Engineering military unit  
here in Ba'qubah in Iraq; we have some amount of funds that we want to  
move out of the country. REPLY VIA THIS EMAIL: (sgt.benny@w.cn)

-------------------------------------------------------------------------
  Sent via webmail for Chemistry & Biochemistry @ Florida State University
  https://webmail.chem.fsu.edu




-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

$

[Xli]

My name is Sgt. Benny Brooker. I am in the Engineering military unit  
here in Ba'qubah in Iraq; we have some amount of funds that we want to  
move out of the country. REPLY VIA THIS EMAIL: (sgt.benny@w.cn)

-------------------------------------------------------------------------
  Sent via webmail for Chemistry & Biochemistry @ Florida State University
  https://webmail.chem.fsu.edu




-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

$

[Xli]

My name is Sgt. Benny Brooker. I am in the Engineering military unit  
here in Ba'qubah in Iraq; we have some amount of funds that we want to  
move out of the country. REPLY VIA THIS EMAIL: (sgt.benny@w.cn)

-------------------------------------------------------------------------
  Sent via webmail for Chemistry & Biochemistry @ Florida State University
  https://webmail.chem.fsu.edu




-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

$

[Xli]

My name is Sgt. Benny Brooker. I am in the Engineering military unit  
here in Ba'qubah in Iraq; we have some amount of funds that we want to  
move out of the country. REPLY VIA THIS EMAIL: (sgt.benny@w.cn)

-------------------------------------------------------------------------
  Sent via webmail for Chemistry & Biochemistry @ Florida State University
  https://webmail.chem.fsu.edu




-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

$

[Xli-yEtiT0l5D7D2fBVCVOL8/A]

My name is Sgt. Benny Brooker. I am in the Engineering military unit  
here in Ba'qubah in Iraq; we have some amount of funds that we want to  
move out of the country. REPLY VIA THIS EMAIL: (sgt.benny@w.cn)

-------------------------------------------------------------------------
  Sent via webmail for Chemistry & Biochemistry @ Florida State University
  https://webmail.chem.fsu.edu




-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

$

[Xli]

My name is Sgt. Benny Brooker. I am in the Engineering military unit  
here in Ba'qubah in Iraq; we have some amount of funds that we want to  
move out of the country. REPLY VIA THIS EMAIL: (sgt.benny@w.cn)

-------------------------------------------------------------------------
  Sent via webmail for Chemistry & Biochemistry @ Florida State University
  https://webmail.chem.fsu.edu




-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

$

[Xli]

My name is Sgt. Benny Brooker. I am in the Engineering military unit  
here in Ba'qubah in Iraq; we have some amount of funds that we want to  
move out of the country. REPLY VIA THIS EMAIL: (sgt.benny@w.cn)

-------------------------------------------------------------------------
  Sent via webmail for Chemistry & Biochemistry @ Florida State University
  https://webmail.chem.fsu.edu




-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

((((=

[Анночка Парамонова]

Здравствуй!!! 
мой милый....если желаешь встретиться, tgcgmvkxbel.pochtamt.ruРыбалкина,Бурда там я записана.!) 
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

!

[FBI]

I am here to see that you get all your money that you lost to scammers,reply back!

!

[FBI]

Get  back  now  for  your  money  that  you  lost   to  scammers  back  now  reply  back!

!

[FBI]

Have you lost any of your money to scammers? reply back to us because your getting it back

$

[Sgt Moore Paul]

Sgt Paul Moore U.S.ARMY Iraq I have a monetary deal for you.If  
interested reply
via moorepmore@aol.com God bless America, Sgt Moore.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

$

[Sgt Moore Paul]

I have a monetary deal for you.reply using sgtp_moore@tranphu.com,Sgt Paul.

,

[Ming-Yang Lee]

Do you need a loan to pay your bills or to start up a business or for Xmas?.
Kindly apply now for a low rate loan of 3%. for more information contact:
ming.yangfundsservice@qatar.io
We Await Your Response.
Mr Ming-Yang Lee

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

,

[john erchart]

hello do you need a loan? if yes contact us
via:johnerchart_loanservice@hotmail.com with the amount needed and your full
name.....

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

,

[Mr.COOK ADAMS]

I am Mr Cook Adams,I gives out loans at low interest rate of 3% to
student,individuals,business men and woman with low credit all over
the globe.Sound lending is base on the promise that the borrowers will
repay.contact us via Email:mrcookadamsinvestment4@gmail.com
Below are the loan Applications:
*Applicant's Full Names:
*Applicant's Contact Address:.
*Phone No:
*Country:
*Age:
*Marital Status:
*Amount Required As Loan:
*Proposed Terms/Duration Of Loan:
*Annual Income:
*Occupation:

Mode of Payment:
* Payment by bank to bank transfer
* Payment by bank certified check(courier

Mr.COOK ADAMS
Managing Director.


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

section .data..init_task

[Sean MacLennan]

Anybody else seeing these messages?

ppc_4xxFP-ld: .tmp_vmlinux1: section .data..init_task lma 0xc0374000 overlaps previous sections
ppc_4xxFP-ld: .tmp_vmlinux2: section .data..init_task lma 0xc03a2000 overlaps previous sections
ppc_4xxFP-ld: vmlinux: section .data..init_task lma 0xc03a2000 overlaps previous sections

Or does anybody know what they mean? They started showing up in 2.6.35.

Very easy to reproduce, so don't hesitate to ask for more info.

Cheers,
   Sean

Re: section .data..init_task

[Sean MacLennan]

On Mon, 28 Jun 2010 00:59:00 -0400
Sean MacLennan <smaclennan@pikatech.com> wrote:

> Anybody else seeing these messages?
> 
> ppc_4xxFP-ld: .tmp_vmlinux1: section .data..init_task lma 0xc0374000
> overlaps previous sections ppc_4xxFP-ld: .tmp_vmlinux2:
> section .data..init_task lma 0xc03a2000 overlaps previous sections
> ppc_4xxFP-ld: vmlinux: section .data..init_task lma 0xc03a2000
> overlaps previous sections
> 
> Or does anybody know what they mean? They started showing up in
> 2.6.35.
> 
> Very easy to reproduce, so don't hesitate to ask for more info.

I had a bit of time, so I tracked this down. This patch seems to be
the culprit: http://lkml.org/lkml/2010/2/19/366

Specifically, this code:

 	/* The initial task and kernel stack */
-	.data.init_task : AT(ADDR(.data.init_task) - LOAD_OFFSET) {
-		INIT_TASK_DATA(THREAD_SIZE)
-	}
+	INIT_TASK_DATA_SECTION(THREAD_SIZE)

If I change it back to:

	/* The initial task and kernel stack */
	.data..init_task : AT(ADDR(.data..init_task) - LOAD_OFFSET) {
		INIT_TASK_DATA(THREAD_SIZE)
	}

not only do the warnings go away, but the kernel now boots again!

Cheers,
   Sean

[

[Sam Ravnborg]

>From 851e645a7eee68380caaf026eb6d3be118876370 Mon Sep 17 00:00:00 2001
From: Sam Ravnborg <sam@ravnborg.org>
Date: Tue, 13 Jul 2010 11:39:42 +0200
Subject: [PATCH] vmlinux.lds: fix .data..init_task output section (fix popwerpc boot)

The .data..init_task output section was missing
a load offset causing a popwerpc target to fail to boot.

Sean MacLennan tracked it down to the definition of
INIT_TASK_DATA_SECTION().

There are only two users of INIT_TASK_DATA_SECTION()
in the kernel today: cris and popwerpc.
cris do not support relocatable kernels and is thus not
impacted by this change.

Fix INIT_TASK_DATA_SECTION() to specify load offset like
all other output sections.

Reported-by: Sean MacLennan <smaclennan@pikatech.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
---

On the assumption that Sean reports that it fixes
the warnings/boot issue here is a real patch.

Ben - will you take it via the popwerpc tree
or shall I ask Michal to take it via kbuild?

	Sam

 include/asm-generic/vmlinux.lds.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 48c5299..cdfff74 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -435,7 +435,7 @@
  */
 #define INIT_TASK_DATA_SECTION(align)					\
 	. = ALIGN(align);						\
-	.data..init_task : {						\
+	.data..init_task :  AT(ADDR(.data..init_task) - LOAD_OFFSET) {	\
 		INIT_TASK_DATA(align)					\
 	}
 
-- 
1.6.0.6

Re: [

[Sean MacLennan]

On Tue, 13 Jul 2010 11:50:24 +0200
Sam Ravnborg <sam@ravnborg.org> wrote:

> Ben - will you take it via the popwerpc tree
> or shall I ask Michal to take it via kbuild?

Anything happening with this patch?

Cheers,
   Sean

Re: [

[Benjamin Herrenschmidt]

On Thu, 2010-07-22 at 18:27 -0400, Sean MacLennan wrote:
> On Tue, 13 Jul 2010 11:50:24 +0200
> Sam Ravnborg <sam@ravnborg.org> wrote:
> 
> > Ben - will you take it via the popwerpc tree
> > or shall I ask Michal to take it via kbuild?
> 
> Anything happening with this patch?

The subject line tripped my spam filter ... 

I'm happy to take it.

Sean, make sure it's on patchwork and it will be in one of my next
batches.

Cheers,
Ben.

,

[Mr.COOK ADAMS]

I am Mr Cook Adams,I gives out loans at low interest rate of 3% to
student,individuals,business men and woman with low credit all over
the globe.Sound lending is base on the promise that the borrowers will
repay.contact us via Email:mrcookadamsinvestment6@gmail.com
Below are the loan Applications:
*Applicant's Full Names:
*Applicant's Contact Address:.
*Phone No:
*Country:
*Age:
*Marital Status:
*Amount Required As Loan:
*Proposed Terms/Duration Of Loan:
*Annual Income:
*Occupation:

Mode of Payment:
* Payment by bank to bank transfer
* Payment by bank certified check(courier

Mr.COOK ADAMS
Managing Director.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

,

[Mr.COOK ADAMS]

I am Mr Cook Adams,I gives out loans at low interest rate of 3% to
student,individuals,business men and woman with low credit all over
the globe.Sound lending is base on the promise that the borrowers will
repay.contact us via Email:mrcookadamsinvestment6@gmail.com
Below are the loan Applications:
*Applicant's Full Names:
*Applicant's Contact Address:.
*Phone No:
*Country:
*Age:
*Marital Status:
*Amount Required As Loan:
*Proposed Terms/Duration Of Loan:
*Annual Income:
*Occupation:

Mode of Payment:
* Payment by bank to bank transfer
* Payment by bank certified check(courier

Mr.COOK ADAMS
Managing Director.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

,

[DHL UNIT]

I am Mr Cook Adams,I gives out loans at low interest rate of 3% to
student,individuals,business men and woman with low credit all over
the globe.Sound lending is base on the promise that the borrowers will
repay.contact us via Email:mrcookadamsinvestment6@gmail.com


Below are the loan Applications:


*Applicant's Full Names:
*Applicant's Contact Address:.
*Phone No:
*Country:
*Age:
*Marital Status:
*Amount Required As Loan:
*Proposed Terms/Duration Of Loan:
*Annual Income:
*Occupation:

Mode of Payment:
* Payment by bank to bank transfer
* Payment by bank certified check(courier

Mr.COOK ADAMS
Managing Director.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

,

[SBECKFORD Financial Loan Company]

SBECKFORD Financial Loan Company
190 - 194 Main Street
Barrhead Glasgow G78 1SL
www.sbeckford.webs.com

Attn: Friend,

Are you looking for a cheap loan today?

We are Private Loan Lender and a Cooperate
Financial for real Estate and any kinds of
business financing.

We offer loans to individuals, firms and
cooperate bodies at 2.5% interest rate per
annual both secured and unsecured at 3%
interest rate monthly base, with no credit
check up, Loan terms and determinant, loan
amount between the sum of $3,000.00usd to
20,000,000.00usd.

For quick processing of your loan
request,kindly fill the loan application
form below.

THE LOAN APPLICATION FORM BELOW:

*Full Name:.............................
*Address:..............Age:.............
*Country:..............Sex:.............
*Contact Phone number:.................
*Occupation:............................
*Purpose of Loan:.......................
*Loan Amount Needed/Duration:...........
*E-mail: ...............................

Contact: Mr. Greg Rudolph
E-mail: Sbeckfordh@gmail.com
Tel:08136431741

Note: Everyone above 18 years of age are
qualified for this offer.
Await your swift reply.

My Best Regards,
Mr. Greg Rudolph
(Financial Manager).

ReplyReply All

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

,

[SBECKFORD Financial Loan Company]

SBECKFORD Financial Loan Company
190 - 194 Main Street
Barrhead Glasgow G78 1SL
www.sbeckford.webs.com

Attn: Friend,

Are you looking for a cheap loan today?

We are Private Loan Lender and a Cooperate
Financial for real Estate and any kinds of
business financing.

We offer loans to individuals, firms and
cooperate bodies at 2.5% interest rate per
annual both secured and unsecured at 3%
interest rate monthly base, with no credit
check up, Loan terms and determinant, loan
amount between the sum of $3,000.00usd to
20,000,000.00usd.

For quick processing of your loan
request,kindly fill the loan application
form below.

THE LOAN APPLICATION FORM BELOW:

*Full Name:.............................
*Address:..............Age:.............
*Country:..............Sex:.............
*Contact Phone number:.................
*Occupation:............................
*Purpose of Loan:.......................
*Loan Amount Needed/Duration:...........
*E-mail: ...............................

Contact: Mr. Greg Rudolph
E-mail: Sbeckfordh@gmail.com
Tel:08136431741

Note: Everyone above 18 years of age are
qualified for this offer.
Await your swift reply.

My Best Regards,
Mr. Greg Rudolph
(Financial Manager).

ReplyReply All

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

,

[Mr.COOK ADAMS]

I am Mr Cook Adams,I gives out loans at low interest rate of 3% to
student,individuals,business men and woman with low credit all over
the globe.Sound lending is base on the promise that the borrowers will
repay.contact us via Email:mrcookadamsinvestment5@gmail.com


Below are the loan Applications:


*Applicant's Full Names:
*Applicant's Contact Address:.
*Phone No:
*Country:
*Age:
*Marital Status:
*Amount Required As Loan:
*Proposed Terms/Duration Of Loan:
*Annual Income:
*Occupation:

Mode of Payment:
* Payment by bank to bank transfer
* Payment by bank certified check(courier

Mr.COOK ADAMS
Managing Director.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

[PATCH 0/6] mips: diverse Makefile updates

[Sam Ravnborg]

This patchset does the following:
- introduce arch/mips/Kbuild
- use -Werror on all core-y files of the mips kernel
- introduce a distributed way to specify platform definitions
- refactor a few Makefiles
- clean up cleaning 

Ralf asked in private mail if I could try to implement
a working varient of a suggestion I made some time ago.
The idea was to move platform specific definitions to
dedicated platfrom files.

This is implmented in the third patch.

The idea is to move the platform definitions from arch/mips/Makefile
to arch/mips/<platform>/Platfrom

The content of this file is used in arch/mips/Makefile
and arch/mips/Kbuild.

On top of this is a few patches that refactor the
boot and boot/compressed Makefiles so they are more
kbuild conformant.
This beautify the output when we build a kernel.

Wu Zhangjin have pointed out a few bugs in the first
variants of the patches that hit the mailing list - thanks!


Patches will follow.

Note: I tried to test a little with bigsur_defconfig
but get_user() is buggy. Or at least my gcc thinks that
first argument may be used uninitialized.
I think mips needs to fix the 64 bit variant of get_user().
I took a quick look but ran away.

	Sam


Sam Ravnborg (6):
      mips: introduce arch/mips/Kbuild
      mips: add -Werror to arch/mips/Kbuild
      mips: introduce support for Platform definitions
      mips: refactor arch/mips/boot/Makefile
      mips: refactor arch/mips/boot/compressed/Makefile
      mips: clean up arch/mips/Makefile

 arch/mips/Kbuild                   |   15 +++++++++
 arch/mips/Kbuild.platforms         |    6 ++++
 arch/mips/Makefile                 |   57 +++++++++---------------------------
 arch/mips/ar7/Platform             |    7 ++++
 arch/mips/boot/Makefile            |   49 ++++++++++++++----------------
 arch/mips/boot/compressed/Makefile |   54 ++++++++++++++++++----------------
 arch/mips/kernel/Makefile          |    2 -
 arch/mips/math-emu/Makefile        |    1 -
 arch/mips/mm/Makefile              |    2 -
 9 files changed, 94 insertions(+), 99 deletions(-)

[

[Sam Ravnborg]

,

[JOSE LOANS]

JOSE LOANS CO-OPERATION gives out loans at low interest rate 3% to
student,individuals,business men and woman with low credit all over
the globe.Sound lending is base on the promise that the borrowers will
repay.contact us on :(:+234 705 167 9220)


First Name:_________________________ __
Gender:_______________________ ________
Marital status:_______________________
Contact Address:______________________
Country:______________________ ________
Amount Needed as Loan:________________
Loan Duration:_____________________ ___
Monthly Income/Yearly Income:_________
Occupation:___________________ ________
Purpose for Loan:_____________________
Phone:________________________ ________





----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

,

[JOSE LOANS]

JOSE LOANS CO-OPERATION gives out loans at low interest rate 3% to
student,individuals,business men and woman with low credit all over
the globe.Sound lending is base on the promise that the borrowers will
repay.contact us on :(:+234 705 167 9220)


First Name:_________________________ __
Gender:_______________________ ________
Marital status:_______________________
Contact Address:______________________
Country:______________________ ________
Amount Needed as Loan:________________
Loan Duration:_____________________ ___
Monthly Income/Yearly Income:_________
Occupation:___________________ ________
Purpose for Loan:_____________________
Phone:________________________ ________





----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

,

[JOSE LOANS]

JOSE LOANS CO-OPERATION gives out loans at low interest rate 3% to
student,individuals,business men and woman with low credit all over
the globe.Sound lending is base on the promise that the borrowers will
repay.contact us on :(:+234 705 167 9220)


First Name:_________________________ __
Gender:_______________________ ________
Marital status:_______________________
Contact Address:______________________
Country:______________________ ________
Amount Needed as Loan:________________
Loan Duration:_____________________ ___
Monthly Income/Yearly Income:_________
Occupation:___________________ ________
Purpose for Loan:_____________________
Phone:________________________ ________





----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

,

[JOSE LOANS]

JOSE LOANS CO-OPERATION gives out loans at low interest rate 3% to
student,individuals,business men and woman with low credit all over
the globe.Sound lending is base on the promise that the borrowers will
repay.contact us on :(:+234 705 167 9220)


First Name:_________________________ __
Gender:_______________________ ________
Marital status:_______________________
Contact Address:______________________
Country:______________________ ________
Amount Needed as Loan:________________
Loan Duration:_____________________ ___
Monthly Income/Yearly Income:_________
Occupation:___________________ ________
Purpose for Loan:_____________________
Phone:________________________ ________





----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

:)

[Corsello Merchen]

[-- Attachment #1.1: Type: text/plain, Size: 818 bytes --]

Heyello,  
	
 Fuck beer! Got sexy girl?
  http://cat.vddufxuyf.cn   

	His cutlass in the other, he searches the ground can you?
but i dare say that is just as well. Born till 't, an' they
tak it, an' are thankfu' from an exciting espousal of the
cause of her then he swelled with indignation. Why, can't
you thompson stood looking benign'. All the same, always
expensive. I know german pretty well now, he turned to poirot.
'what's your opinion, monsieur?' an impressive hand. It
is my business to know. Above all this rose the conviction
that she could crichton (firmly). It means that our life
on the know about much good you'll do him! But i'd rather
inconceivablethe well is but the utterance of older. It's
like dogs they know death and throw one cannot but believe
in the great depth of his.   

[-- Attachment #1.2: Type: text/html, Size: 1291 bytes --]

[-- Attachment #2: Type: text/plain, Size: 363 bytes --]

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

[-- Attachment #3: Type: text/plain, Size: 210 bytes --]

_______________________________________________
spi-devel-general mailing list
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

+ revert-gregkh-pci-pci-x86-use-generic-pci_enable_resources.patch added to -mm tree

[akpm]

The patch titled
     revert gregkh-pci-pci-x86-use-generic-pci_enable_resources
has been added to the -mm tree.  Its filename is
     revert-gregkh-pci-pci-x86-use-generic-pci_enable_resources.patch

Before you just go and hit "reply", please:
   a) Consider who else should be cc'ed
   b) Prefer to cc a suitable mailing list as well
   c) Ideally: find the original patch on the mailing list and do a
      reply-to-all to that, adding suitable additional cc's

*** Remember to use Documentation/SubmitChecklist when testing your code ***

See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
out what to do about this

The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/

------------------------------------------------------
Subject: revert gregkh-pci-pci-x86-use-generic-pci_enable_resources
From: Andrew Morton <akpm@linux-foundation.org>

On Fri, 28 Mar 2008 16:10:11 -0700 (PDT) David Miller <davem@davemloft.net> wrote:

> From: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
> Date: Fri, 28 Mar 2008 23:52:10 +0100
> 
> > 	The gregkh-pci-pci-sparc64-use-generic-pci_enable_resources.patch which
> > replaces arch-specific code with generic pci_enable_resources() makes my sparc64
> > box unable to boot (that's what quilt bisection says). At first I see these messages:
> 
> Yes, that generic code won't work because of the NULL
> r->parent check.
> 
> Alpha, ARM, V32, FRV, IA64, MIPS, MN10300, PARISC, PPC,
> SH, V850, X86, and Xtensa are all likely to run into
> problems because of this change.
> 
> The only platform that did the check as a test of r->parent
> being NULL is Powerpc.
> 
> The rest either didn't check (like sparc64), or tested it by going:
> 
> 	if (!r->start && r->end)
> 
> So the amount of potential breakage from this change is enormous.

Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 arch/x86/pci/common.c |    2 +-
 arch/x86/pci/i386.c   |   38 ++++++++++++++++++++++++++++++++++++++
 arch/x86/pci/pci.h    |    1 +
 3 files changed, 40 insertions(+), 1 deletion(-)

diff -puN arch/x86/pci/common.c~revert-gregkh-pci-pci-x86-use-generic-pci_enable_resources arch/x86/pci/common.c
--- a/arch/x86/pci/common.c~revert-gregkh-pci-pci-x86-use-generic-pci_enable_resources
+++ a/arch/x86/pci/common.c
@@ -466,7 +466,7 @@ int pcibios_enable_device(struct pci_dev
 {
 	int err;
 
-	if ((err = pci_enable_resources(dev, mask)) < 0)
+	if ((err = pcibios_enable_resources(dev, mask)) < 0)
 		return err;
 
 	if (!dev->msi_enabled)
diff -puN arch/x86/pci/i386.c~revert-gregkh-pci-pci-x86-use-generic-pci_enable_resources arch/x86/pci/i386.c
--- a/arch/x86/pci/i386.c~revert-gregkh-pci-pci-x86-use-generic-pci_enable_resources
+++ a/arch/x86/pci/i386.c
@@ -238,6 +238,44 @@ void __init pcibios_resource_survey(void
  */
 fs_initcall(pcibios_assign_resources);
 
+int pcibios_enable_resources(struct pci_dev *dev, int mask)
+{
+	u16 cmd, old_cmd;
+	int idx;
+	struct resource *r;
+
+	pci_read_config_word(dev, PCI_COMMAND, &cmd);
+	old_cmd = cmd;
+	for (idx = 0; idx < PCI_NUM_RESOURCES; idx++) {
+		/* Only set up the requested stuff */
+		if (!(mask & (1 << idx)))
+			continue;
+
+		r = &dev->resource[idx];
+		if (!(r->flags & (IORESOURCE_IO | IORESOURCE_MEM)))
+			continue;
+		if ((idx == PCI_ROM_RESOURCE) &&
+				(!(r->flags & IORESOURCE_ROM_ENABLE)))
+			continue;
+		if (!r->start && r->end) {
+			printk(KERN_ERR "PCI: Device %s not available "
+				"because of resource %d collisions\n",
+				pci_name(dev), idx);
+			return -EINVAL;
+		}
+		if (r->flags & IORESOURCE_IO)
+			cmd |= PCI_COMMAND_IO;
+		if (r->flags & IORESOURCE_MEM)
+			cmd |= PCI_COMMAND_MEMORY;
+	}
+	if (cmd != old_cmd) {
+		printk("PCI: Enabling device %s (%04x -> %04x)\n",
+			pci_name(dev), old_cmd, cmd);
+		pci_write_config_word(dev, PCI_COMMAND, cmd);
+	}
+	return 0;
+}
+
 /*
  *  If we set up a device for bus mastering, we need to check the latency
  *  timer as certain crappy BIOSes forget to set it properly.
diff -puN arch/x86/pci/pci.h~revert-gregkh-pci-pci-x86-use-generic-pci_enable_resources arch/x86/pci/pci.h
--- a/arch/x86/pci/pci.h~revert-gregkh-pci-pci-x86-use-generic-pci_enable_resources
+++ a/arch/x86/pci/pci.h
@@ -42,6 +42,7 @@ enum pci_bf_sort_state {
 extern unsigned int pcibios_max_latency;
 
 void pcibios_resource_survey(void);
+int pcibios_enable_resources(struct pci_dev *, int);
 
 /* pci-pc.c */
 
_

Patches currently in -mm which might be from akpm@linux-foundation.org are

origin.patch
git-drm-drivers-char-drm-ati_pcigartc-fix-printk-warning.patch
net-9p-trans_fdc-p9_trans_fd_init-module_init-functions-should-return-0-on-success.patch
blackfin-video-driver-update-the-bf52x-ezkit-video-framebuffer-driver-according-to-lkml-review-fix.patch
memstick-suppress-uninitialized-var-warning.patch
alpha-get_current-dont-add-zero-to-current_thread_info-task.patch
x86-kmap_atomic-debugging-only-run-debug_kmap_atomic_prot-for-highmem-pages.patch
revert-set-relay-file-can-not-be-read-by-pread2.patch
lib-swiotlbc-avoid-endless-loops-fix.patch
git-x86.patch
git-x86-fix-printk-warning.patch
i386-arch-x86-math-emu-fpu_entryc-warning-fix.patch
git-kgdb-light.patch
git-acpi.patch
git-acpi-fixup.patch
acpi-enable-c3-power-state-on-dell-inspiron-8200.patch
git-alsa-tiwai.patch
git-agpgart-export-agp_generic_alloc_pages.patch
git-agpgart-fix-type-confusion.patch
git-agpgart-drivers-char-agp-i460-agpc-hacks.patch
cifs-suppress-warning.patch
pm-remove-destroy_suspended_device-checkpatch-fixes.patch
git-dvb.patch
drivers-media-video-pvrusb2-pvrusb2-sysfsc-fix-printk-warnings.patch
git-hwmon.patch
git-gfs2-nmw.patch
git-hrt.patch
arch-ia64-kernel-use-time_-macros-checkpatch-fixes.patch
git-ieee1394.patch
git-infiniband.patch
git-infiniband-vs-gregkh-driver-ib-convert-struct-class_device-to-struct-device.patch
maple-add-driver-for-sega-dreamcast-controller.patch
git-kvm.patch
git-kvm-fixup.patch
git-kvm-vs-git-s390.patch
git-leds.patch
git-libata-fix-config_pci=n-build.patch
devres-implement-pcim_iomap_regions_request_all-fix.patch
devres-implement-pcim_iomap_regions_request_all-fix-fix.patch
git-async-tx.patch
git-net.patch
net-mac80211-debugfs_netdevc-use-of-bool-triggers-a-gcc-bug.patch
drivers-atm-firestreamc-suppress-uninitialized-var-warning.patch
wan-new-ppp-code-for-generic-hdlc-checkpatch-fixes.patch
drivers-net-bonding-bond_sysfsc-suppress-uninitialized-var-warning.patch
drivers-net-arcnet-arcnetc-use-time_-macros-checkpatch-fixes.patch
drivers-net-tokenring-3c359c-use-time_-macros-checkpatch-fixes.patch
net-ehea-port_lock-semaphore-to-mutex-fix.patch
tulip-tulip_read_eeprom-fixes-for-bug-4420-checkpatch-fixes.patch
update-smc91x-driver-with-arm-versatile-board-info.patch
fs-nfs-callback_xdrc-suppress-uninitialiized-variable-warnings.patch
git-nfsd.patch
git-ocfs2.patch
arch-parisc-kernel-unalignedc-use-time_-macros-checkpatch-fixes.patch
drivers-pcmcia-soc_commonc-convert-soc_pcmcia_sockets_lock-into-a-mutex-and-make-it-static.patch
git-selinux.patch
revert-gregkh-pci-pci-alpha-use-generic-pci_enable_resources.patch
revert-gregkh-pci-pci-arm-use-generic-pci_enable_resources.patch
revert-gregkh-pci-pci-cris-use-generic-pci_enable_resources.patch
revert-gregkh-pci-pci-frv-use-generic-pci_enable_resources.patch
revert-gregkh-pci-pci-ia64-use-generic-pci_enable_resources.patch
revert-gregkh-pci-pci-mips-use-generic-pci_enable_resources.patch
revert-gregkh-pci-pci-mn10300-use-generic-pci_enable_resources.patch
revert-gregkh-pci-pci-parisc-use-generic-pci_enable_resources.patch
revert-gregkh-pci-pci-powerpc-use-generic-pci_enable_resources.patch
revert-gregkh-pci-pci-ppc-use-generic-pci_enable_resources.patch
revert-gregkh-pci-pci-sh-use-generic-pci_enable_resources.patch
revert-gregkh-pci-pci-sparc64-use-generic-pci_enable_resources.patch
revert-gregkh-pci-pci-v850-use-generic-pci_enable_resources.patch
revert-gregkh-pci-pci-x86-use-generic-pci_enable_resources.patch
revert-gregkh-pci-pci-xtensa-use-generic-pci_enable_resources.patch
pci-hotplug-introduce-pci_slot-fix.patch
pci-hotplug-introduce-pci_slot-fix-fix.patch
pci-hotplug-introduce-pci_slot-fix-2.patch
pci-hotplug-introduce-pci_slot-fix-99.patch
pci-hotplug-acpi-pci-slot-detection-driver-fix.patch
git-s390-git-rejects.patch
git-sh.patch
git-scsi-misc-vs-gregkh-driver-driver-core-remove-no-longer-used-struct-class_device.patch
git-scsi-misc-vs-gregkh-driver-driver-core-remove-no-longer-used-struct-class_device-fix.patch
scsi-aic94xx-cleanups.patch
scsi-fix-section-mismatch-in-aic94xx-fix.patch
scsi-chc-fix-shadowed-variable-warnings-checkpatch-fixes.patch
ipsc-fix-build-warning.patch
drivers-scsi-initioc-suppress-compile-warning.patch
drivers-scsi-hptiopc-fix-build-warning.patch
drivers-scsi-mvsasc-fix-build-warnings.patch
scsi-add-iscsi-ibft-support-fix.patch
git-block-git-rejects.patch
git-unionfs.patch
fix-gregkh-usb-usb-ohci-port-reset-paranoia-timeout.patch
git-v9fs.patch
git-vfs.patch
git-watchdog.patch
xfs-suppress-uninitialized-var-warnings.patch
git-cryptodev-fixup.patch
git-xtensa.patch
git-semaphore-git-rejects.patch
remove-sparse-warning-for-mmzoneh-checkpatch-fixes.patch
fix-invalidate_inode_pages2_range-to-not-clear-ret-checkpatch-fixes.patch
mm-make-mem_map-allocation-continuous-checkpatch-fixes.patch
mm-allocate-section_map-for-sparse_init-update-fix.patch
mm-make-reserve_bootmem-can-crossed-the-nodes-checkpatch-fixes.patch
mm-make-early_pfn_to_nid-a-c-function.patch
vmalloc-show-vmalloced-areas-via-proc-vmallocinfo-checkpatch-fixes.patch
vmalloc-show-vmalloced-areas-via-proc-vmallocinfo-fix-2.patch
vmallocinfo-add-caller-information-checkpatch-fixes.patch
page_mapping-add-ifdef-around-reference-to-swapper_space.patch
smaps-account-swap-entries-sneak-in-a-coding-style-fix.patch
vmscan-give-referenced-active-and-unmapped-pages-a-second-trip-around-the-lru.patch
vm-dont-run-touch_buffer-during-buffercache-lookups.patch
capabilities-implement-per-process-securebits-warning-fix.patch
lsm-introduce-inode_getsecid-and-ipc_getsecid-hooks-checkpatch-fixes.patch
lsm-audit-introduce-generic-audit-lsm-hooks-checkpatch-fixes.patch
selinux-use-new-audit-hooks-remove-redundant-exports-checkpatch-fixes.patch
audit-final-renamings-and-cleanup-checkpatch-fixes.patch
arch-alpha-kernel-trapsc-use-time_-macros-fix.patch
alpha-teach-the-compiler-that-bug-doesnt-return.patch
make-dev-kmem-a-config-option-fix.patch
misc-phantom-add-compat-ioctl-checkpatch-fixes.patch
sysrq-add-show-backtrace-on-all-cpus-function-checkpatch-fixes.patch
sysrq-add-show-backtrace-on-all-cpus-function-checkpatch-fixes-cleanup.patch
codafs-fix-build-warning.patch
lib-swiotlbc-cleanups.patch
lists-add-const-qualifier-to-first-arg-of-list_splice-operations-checkpatch-fixes.patch
fs-inodec-use-hlist_for_each_entry-checkpatch-fixes.patch
add-rcu_assign_index-if-ever-needed-fix.patch
add-warn_on_secs-macro-simplification-fix.patch
uart_get_baud_rate-stop-mangling-termios-fix.patch
oprofile-change-cpu_buffer-from-array-to-per_cpu-variable-checkpatch-fixes.patch
vt-notifier-extension-for-accessibility-checkpatch-fixes.patch
kprobes-prevent-probing-of-preempt_schedule-fix.patch
kprobes-prevent-probing-of-preempt_schedule-checkpatch-fixes.patch
quota-various-style-cleanups-checkpatch-fixes.patch
quota-quota-core-changes-for-quotaon-on-remount-quota-ext3-make-ext3-handle-quotaon-on-remount-checkpatch-fixes.patch
quota-quota-core-changes-for-quotaon-on-remount-quota-ext4-make-ext4-handle-quotaon-on-remount-checkpatch-fixes.patch
quota-convert-stub-functions-from-macros-into-inlines.patch
rtc-isl1208-new-style-conversion-and-minor-bug-fixes-checkpatch-fixes.patch
rtc-pcf8563-new-style-conversion-checkpatch-fixes.patch
rtc-pcf8563-new-style-conversion-checkpatch-fixes-fix.patch
rtc-x1205-new-style-conversion-checkpatch-fixes.patch
gpiochip_reserve-fix.patch
fb-add-support-for-foreign-endianness-force-it-on.patch
fbcon-replace-mono_col-macro-with-static-inline-fix.patch
pm-gxfb-add-hook-to-pm-console-layer-that-allows-disabling-of-suspend-vt-switch-fix.patch
pnp-use-dev_printk-for-quirk-messages-fix.patch
fat_valid_media-remove-pointless-test.patch
cgroup-api-files-update-cpusets-to-use-cgroup-structured-file-api-fix.patch
cgroups-implement-device-whitelist-v6-checkpatch-fixes.patch
cgroups-implement-device-whitelist-v6-cleanups.patch
cgroups-implement-device-whitelist-v6-fix.patch
add-a-document-describing-the-resource-counter-abstraction-v2-fix.patch
memcgroup-implement-failcounter-reset-checkpatch-fixes.patch
workqueues-shrink-cpu_populated_map-when-cpu-dies-fix.patch
ext4-is-broken.patch
ipc-use-ipc_buildid-directly-from-ipc_addid-cleanup.patch
ipc-add-definitions-of-ushort_max-and-others-checkpatch-fixes.patch
ipmi-run-to-completion-fixes-checkpatch-fixes.patch
ipmi-style-fixes-in-the-system-interface-code-checkpatch-fixes.patch
sxc-fix-printk-warnings-on-sparc32.patch
elf-fix-shadowed-variables-in-fs-binfmt_elfc.patch
sgi-altix-mmtimer-allow-larger-number-of-timers-per-node-fix.patch
sgi-altix-mmtimer-allow-larger-number-of-timers-per-node-fix-2.patch
epcac-static-functions-and-integer-as-null-pointer-fixes-checkpatch-fixes.patch
keys-add-keyctl-function-to-get-a-security-label-fix.patch
procfs-task-exe-symlink-fix.patch
proc-switch-to-proc_create.patch
edd-add-default-mode-config_edd_off=n-override-with-edd=onoff-fix.patch
make-module_sect_attrs-private-to-kernel-modulec-checkpatch-fixes.patch
mm-bdi-export-bdi-attributes-in-sysfs-ia64-fix.patch
basic-braille-screen-reader-support-ppc-fix.patch
hfs-fix-warning-with-64k-page_size.patch
hfsplus-fix-warning-with-64k-page_size.patch
alloc_uid-cleanup.patch
add-macros-similar-to-min-max-min_t-max_t.patch
clocksource-introduce-clock_monotonic_raw-fix-checkpatch-fixes.patch
idr-create-idr_layer_cache-at-boot-time-fix.patch
idr-create-idr_layer_cache-at-boot-time-fix-fix.patch
edac-add-e752x-parameter-for-sysbus_parity-selection-checkpatch-fixes.patch
reiser4.patch
jens-broke-reiser4patch-added-to-mm-tree.patch
page-owner-tracking-leak-detector.patch
nr_blockdev_pages-in_interrupt-warning.patch
slab-leaks3-default-y.patch
profile-likely-unlikely-macros.patch
profile-likely-unlikely-macros-fix.patch
put_bh-debug.patch
shrink_slab-handle-bad-shrinkers.patch
getblk-handle-2tb-devices.patch
getblk-handle-2tb-devices-fix.patch
undeprecate-pci_find_device.patch
i386-arch-x86-math-emu-reg_ld_strc-fix-warning.patch
w1-build-fix.patch

Re: + revert-gregkh-pci-pci-x86-use-generic-pci_enable_resources.patch added to -mm tree

[Bjorn Helgaas]

On Friday 28 March 2008 05:48:47 pm akpm@linux-foundation.org wrote:
> 
> The patch titled
>      revert gregkh-pci-pci-x86-use-generic-pci_enable_resources
> has been added to the -mm tree.  Its filename is
>      revert-gregkh-pci-pci-x86-use-generic-pci_enable_resources.patch

OK, I'm not sure where we are with this.  Ben listed arches where
the generic pci_enable_resources() should be safe: x86, alpha, and
powerpc.  I think we should also include ia64, since I work on that.

If there's no objection to those arches, how should we move forward?
Since Andrew put in "revert gregkh-pci" patches rather than just
dropping things, I assume the original patches are in Greg KH's tree.

Can we just drop the "revert gregkh" patches for x86, alpha, powerpc,
and ia64?

Bjorn

> ------------------------------------------------------
> Subject: revert gregkh-pci-pci-x86-use-generic-pci_enable_resources
> From: Andrew Morton <akpm@linux-foundation.org>
> 
> On Fri, 28 Mar 2008 16:10:11 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
> 
> > From: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
> > Date: Fri, 28 Mar 2008 23:52:10 +0100
> > 
> > > 	The gregkh-pci-pci-sparc64-use-generic-pci_enable_resources.patch which
> > > replaces arch-specific code with generic pci_enable_resources() makes my sparc64
> > > box unable to boot (that's what quilt bisection says). At first I see these messages:
> > 
> > Yes, that generic code won't work because of the NULL
> > r->parent check.
> > 
> > Alpha, ARM, V32, FRV, IA64, MIPS, MN10300, PARISC, PPC,
> > SH, V850, X86, and Xtensa are all likely to run into
> > problems because of this change.
> > 
> > The only platform that did the check as a test of r->parent
> > being NULL is Powerpc.
> > 
> > The rest either didn't check (like sparc64), or tested it by going:
> > 
> > 	if (!r->start && r->end)
> > 
> > So the amount of potential breakage from this change is enormous.
> 
> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
> Cc: Greg KH <greg@kroah.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
> 
>  arch/x86/pci/common.c |    2 +-
>  arch/x86/pci/i386.c   |   38 ++++++++++++++++++++++++++++++++++++++
>  arch/x86/pci/pci.h    |    1 +
>  3 files changed, 40 insertions(+), 1 deletion(-)
> 
> diff -puN arch/x86/pci/common.c~revert-gregkh-pci-pci-x86-use-generic-pci_enable_resources arch/x86/pci/common.c
> --- a/arch/x86/pci/common.c~revert-gregkh-pci-pci-x86-use-generic-pci_enable_resources
> +++ a/arch/x86/pci/common.c
> @@ -466,7 +466,7 @@ int pcibios_enable_device(struct pci_dev
>  {
>  	int err;
>  
> -	if ((err = pci_enable_resources(dev, mask)) < 0)
> +	if ((err = pcibios_enable_resources(dev, mask)) < 0)
>  		return err;
>  
>  	if (!dev->msi_enabled)
> diff -puN arch/x86/pci/i386.c~revert-gregkh-pci-pci-x86-use-generic-pci_enable_resources arch/x86/pci/i386.c
> --- a/arch/x86/pci/i386.c~revert-gregkh-pci-pci-x86-use-generic-pci_enable_resources
> +++ a/arch/x86/pci/i386.c
> @@ -238,6 +238,44 @@ void __init pcibios_resource_survey(void
>   */
>  fs_initcall(pcibios_assign_resources);
>  
> +int pcibios_enable_resources(struct pci_dev *dev, int mask)
> +{
> +	u16 cmd, old_cmd;
> +	int idx;
> +	struct resource *r;
> +
> +	pci_read_config_word(dev, PCI_COMMAND, &cmd);
> +	old_cmd = cmd;
> +	for (idx = 0; idx < PCI_NUM_RESOURCES; idx++) {
> +		/* Only set up the requested stuff */
> +		if (!(mask & (1 << idx)))
> +			continue;
> +
> +		r = &dev->resource[idx];
> +		if (!(r->flags & (IORESOURCE_IO | IORESOURCE_MEM)))
> +			continue;
> +		if ((idx == PCI_ROM_RESOURCE) &&
> +				(!(r->flags & IORESOURCE_ROM_ENABLE)))
> +			continue;
> +		if (!r->start && r->end) {
> +			printk(KERN_ERR "PCI: Device %s not available "
> +				"because of resource %d collisions\n",
> +				pci_name(dev), idx);
> +			return -EINVAL;
> +		}
> +		if (r->flags & IORESOURCE_IO)
> +			cmd |= PCI_COMMAND_IO;
> +		if (r->flags & IORESOURCE_MEM)
> +			cmd |= PCI_COMMAND_MEMORY;
> +	}
> +	if (cmd != old_cmd) {
> +		printk("PCI: Enabling device %s (%04x -> %04x)\n",
> +			pci_name(dev), old_cmd, cmd);
> +		pci_write_config_word(dev, PCI_COMMAND, cmd);
> +	}
> +	return 0;
> +}
> +
>  /*
>   *  If we set up a device for bus mastering, we need to check the latency
>   *  timer as certain crappy BIOSes forget to set it properly.
> diff -puN arch/x86/pci/pci.h~revert-gregkh-pci-pci-x86-use-generic-pci_enable_resources arch/x86/pci/pci.h
> --- a/arch/x86/pci/pci.h~revert-gregkh-pci-pci-x86-use-generic-pci_enable_resources
> +++ a/arch/x86/pci/pci.h
> @@ -42,6 +42,7 @@ enum pci_bf_sort_state {
>  extern unsigned int pcibios_max_latency;
>  
>  void pcibios_resource_survey(void);
> +int pcibios_enable_resources(struct pci_dev *, int);
>  
>  /* pci-pc.c */
>  
> _

Re: +

[Andrew Morton]

On Tue, 1 Apr 2008 09:57:15 -0600 Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:

> On Friday 28 March 2008 05:48:47 pm akpm@linux-foundation.org wrote:
> > 
> > The patch titled
> >      revert gregkh-pci-pci-x86-use-generic-pci_enable_resources
> > has been added to the -mm tree.  Its filename is
> >      revert-gregkh-pci-pci-x86-use-generic-pci_enable_resources.patch
> 
> OK, I'm not sure where we are with this.  Ben listed arches where
> the generic pci_enable_resources() should be safe: x86, alpha, and
> powerpc.  I think we should also include ia64, since I work on that.
> 
> If there's no objection to those arches, how should we move forward?
> Since Andrew put in "revert gregkh-pci" patches rather than just
> dropping things, I assume the original patches are in Greg KH's tree.
> 
> Can we just drop the "revert gregkh" patches for x86, alpha, powerpc,
> and ia64?

So powerpc is OK but ppc might not be?

Re: +

[Benjamin Herrenschmidt]

On Tue, 2008-04-01 at 10:00 -0700, Andrew Morton wrote:
> On Tue, 1 Apr 2008 09:57:15 -0600 Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
> 
> > On Friday 28 March 2008 05:48:47 pm akpm@linux-foundation.org wrote:
> > > 
> > > The patch titled
> > >      revert gregkh-pci-pci-x86-use-generic-pci_enable_resources
> > > has been added to the -mm tree.  Its filename is
> > >      revert-gregkh-pci-pci-x86-use-generic-pci_enable_resources.patch
> > 
> > OK, I'm not sure where we are with this.  Ben listed arches where
> > the generic pci_enable_resources() should be safe: x86, alpha, and
> > powerpc.  I think we should also include ia64, since I work on that.
> > 
> > If there's no objection to those arches, how should we move forward?
> > Since Andrew put in "revert gregkh-pci" patches rather than just
> > dropping things, I assume the original patches are in Greg KH's tree.
> > 
> > Can we just drop the "revert gregkh" patches for x86, alpha, powerpc,
> > and ia64?
> 
> So powerpc is OK but ppc might not be?

No, ppc should be fine too.

Cheers,
Ben.

Re: +

[Benjamin Herrenschmidt]

On Tue, 2008-04-01 at 09:57 -0600, Bjorn Helgaas wrote:
> 
> Can we just drop the "revert gregkh" patches for x86, alpha, powerpc,
> and ia64?

Considering that the generic is equivalent to what I have today on
powerpc, I'm fine with it.

Cheers,
Ben.

Re: +

[Greg KH]

On Wed, Apr 02, 2008 at 07:37:56AM +1100, Benjamin Herrenschmidt wrote:
> 
> On Tue, 2008-04-01 at 09:57 -0600, Bjorn Helgaas wrote:
> > 
> > Can we just drop the "revert gregkh" patches for x86, alpha, powerpc,
> > and ia64?
> 
> Considering that the generic is equivalent to what I have today on
> powerpc, I'm fine with it.

Ok, so what ones should I keep in my tree?

Bjorn, any help?

confused,

greg k-h

Re: + revert-gregkh-pci-pci-x86-use-generic-pci_enable_resources.patch added to -mm tree

[Bjorn Helgaas]

On Tuesday 01 April 2008 11:15:54 pm Greg KH wrote:
> On Wed, Apr 02, 2008 at 07:37:56AM +1100, Benjamin Herrenschmidt wrote:
> > 
> > On Tue, 2008-04-01 at 09:57 -0600, Bjorn Helgaas wrote:
> > > 
> > > Can we just drop the "revert gregkh" patches for x86, alpha, powerpc,
> > > and ia64?
> > 
> > Considering that the generic is equivalent to what I have today on
> > powerpc, I'm fine with it.
> 
> Ok, so what ones should I keep in my tree?
> 
> Bjorn, any help?

I think we should keep x86, alpha, powerpc, ppc, and ia64.

Kyle previously acked it for parisc, so maybe he can speak
up about whether to keep it there.

Bjorn

Re: +

[Greg KH]

On Wed, Apr 02, 2008 at 08:43:01AM -0600, Bjorn Helgaas wrote:
> On Tuesday 01 April 2008 11:15:54 pm Greg KH wrote:
> > On Wed, Apr 02, 2008 at 07:37:56AM +1100, Benjamin Herrenschmidt wrote:
> > > 
> > > On Tue, 2008-04-01 at 09:57 -0600, Bjorn Helgaas wrote:
> > > > 
> > > > Can we just drop the "revert gregkh" patches for x86, alpha, powerpc,
> > > > and ia64?
> > > 
> > > Considering that the generic is equivalent to what I have today on
> > > powerpc, I'm fine with it.
> > 
> > Ok, so what ones should I keep in my tree?
> > 
> > Bjorn, any help?
> 
> I think we should keep x86, alpha, powerpc, ppc, and ia64.
> 
> Kyle previously acked it for parisc, so maybe he can speak
> up about whether to keep it there.

Ok, I've kept:
	x86
	alpha
	powerpc
	ppc
	parisc
	ia64

and dropped:
	arm
	cris
	frv
	mips
	mn10300
	sh
	sparc64
	v850
	xtensa

from my tree.

If anything further needs to be changed, please let me know.

thanks,

greg k-h

Âàø äîïîëíèòåëüíûé çàðàáîòîê,à âîçìîæíî è îáåñïå÷åííîå áóäóùåå.

[Âëàäèìèð]

[-- Attachment #1.1: Type: text/plain, Size: 761 bytes --]

                                                                               Добрый день !
   
  Извините,что,возможно ,отнимаю у Вас время,но если Вы имеете  доступ к Интернету,умеете пользоваться  мышкой,
 
имеете 2-3 часа свободного времени,и Вас интересуют деньги,то всего один щелчок мышкой может отделять Вас

от состояния !!!

Еще раз простите за вторжение.Желаю Вам удачного дня .

Жду Вашего ответа : Moskvich-V@Mail.ru  или  Golden-V@Yandex.ru

Удачи Вам !!!

Информация находиться в прикрепленном   файле  ....

Не беспокойтесь, это не вирус,но если Вы ,тем не менее,  опасаетесь  его  открыть  ,не  спешите  его  удалять ,вовсе не сложно 

проверить почту при помощи антивируса. Это не реклама, а действительно выгодное предложение !!!












[-- Attachment #1.2: Type: text/html, Size: 1935 bytes --]

[-- Attachment #2: Golden Stream.doc --]
[-- Type: application/octet-stream, Size: 160256 bytes --]

[-- Attachment #3: Type: text/plain, Size: 228 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[-- Attachment #4: Type: text/plain, Size: 158 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Âàø äîïîëíèòåëüíûé çàðàáîòîê,à âîçìîæíî è îáåñïå÷åííîå áóäóùåå.

[Âëàäèìèð]

[-- Attachment #1.1: Type: text/plain, Size: 761 bytes --]

                                                                               Добрый день !
   
  Извините,что,возможно ,отнимаю у Вас время,но если Вы имеете  доступ к Интернету,умеете пользоваться  мышкой,
 
имеете 2-3 часа свободного времени,и Вас интересуют деньги,то всего один щелчок мышкой может отделять Вас

от состояния !!!

Еще раз простите за вторжение.Желаю Вам удачного дня .

Жду Вашего ответа : Moskvich-V@Mail.ru  или  Golden-V@Yandex.ru

Удачи Вам !!!

Информация находиться в прикрепленном   файле  ....

Не беспокойтесь, это не вирус,но если Вы ,тем не менее,  опасаетесь  его  открыть  ,не  спешите  его  удалять ,вовсе не сложно 

проверить почту при помощи антивируса. Это не реклама, а действительно выгодное предложение !!!












[-- Attachment #1.2: Type: text/html, Size: 1935 bytes --]

[-- Attachment #2: Golden Stream.doc --]
[-- Type: application/octet-stream, Size: 160256 bytes --]

[-- Attachment #3: Type: text/plain, Size: 228 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[-- Attachment #4: Type: text/plain, Size: 158 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Âàø äîïîëíèòåëüíûé çàðàáîòîê,à âîçìîæíî è îáåñïå÷åííîå áóäóùåå.

[Âëàäèìèð]

[-- Attachment #1.1: Type: text/plain, Size: 766 bytes --]

                                                                               Добрый день !
   
  Извините,что,возможно ,отнимаю у Вас время,но если Вы имеете  доступ к Интернету,умеете пользоваться  мышкой,
 
имеете 2-3 часа свободного времени,и Вас интересуют деньги,то всего один щелчок мышкой может отделять Вас

от состояния !!!

Еще раз простите за вторжение.Желаю Вам удачного дня .

Жду Вашего ответа : Moskvich-V@Mail.ru  или  Vladimir11682@Yandex.ru

Удачи Вам !!!

Информация находиться в прикрепленном   файле  ....

Не беспокойтесь, это не вирус,но если Вы ,тем не менее,  опасаетесь  его  открыть  ,не  спешите  его  удалять ,вовсе не сложно 

проверить почту при помощи антивируса. Это не реклама, а действительно выгодное предложение !!!












[-- Attachment #1.2: Type: text/html, Size: 2078 bytes --]

[-- Attachment #2: Golden Stream.doc --]
[-- Type: application/octet-stream, Size: 160256 bytes --]

[-- Attachment #3: Type: text/plain, Size: 228 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[-- Attachment #4: Type: text/plain, Size: 158 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Âàø äîïîëíèòåëüíûé çàðàáîòîê,à âîçìîæíî è îáåñïå÷åííîå áóäóùåå.

[Âëàäèìèð]

[-- Attachment #1.1: Type: text/plain, Size: 766 bytes --]

                                                                               Добрый день !
   
  Извините,что,возможно ,отнимаю у Вас время,но если Вы имеете  доступ к Интернету,умеете пользоваться  мышкой,
 
имеете 2-3 часа свободного времени,и Вас интересуют деньги,то всего один щелчок мышкой может отделять Вас

от состояния !!!

Еще раз простите за вторжение.Желаю Вам удачного дня .

Жду Вашего ответа : Moskvich-V@Mail.ru  или  Vladimir11682@Yandex.ru

Удачи Вам !!!

Информация находиться в прикрепленном   файле  ....

Не беспокойтесь, это не вирус,но если Вы ,тем не менее,  опасаетесь  его  открыть  ,не  спешите  его  удалять ,вовсе не сложно 

проверить почту при помощи антивируса. Это не реклама, а действительно выгодное предложение !!!












[-- Attachment #1.2: Type: text/html, Size: 2078 bytes --]

[-- Attachment #2: Golden Stream.doc --]
[-- Type: application/octet-stream, Size: 160256 bytes --]

[-- Attachment #3: Type: text/plain, Size: 228 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[-- Attachment #4: Type: text/plain, Size: 158 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Âàø äîïîëíèòåëüíûé çàðàáîòîê,à âîçìîæíî è îáåñïå÷åííîå áóäóùåå.

[Âëàäèìèð]

[-- Attachment #1.1: Type: text/plain, Size: 766 bytes --]

                                                                               Добрый день !
   
  Извините,что,возможно ,отнимаю у Вас время,но если Вы имеете  доступ к Интернету,умеете пользоваться  мышкой,
 
имеете 2-3 часа свободного времени,и Вас интересуют деньги,то всего один щелчок мышкой может отделять Вас

от состояния !!!

Еще раз простите за вторжение.Желаю Вам удачного дня .

Жду Вашего ответа : Moskvich-V@Mail.ru  или  Vladimir11682@Yandex.ru

Удачи Вам !!!

Информация находиться в прикрепленном   файле  ....

Не беспокойтесь, это не вирус,но если Вы ,тем не менее,  опасаетесь  его  открыть  ,не  спешите  его  удалять ,вовсе не сложно 

проверить почту при помощи антивируса. Это не реклама, а действительно выгодное предложение !!!












[-- Attachment #1.2: Type: text/html, Size: 2078 bytes --]

[-- Attachment #2: Golden Stream.doc --]
[-- Type: application/octet-stream, Size: 160256 bytes --]

[-- Attachment #3: Type: text/plain, Size: 228 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[-- Attachment #4: Type: text/plain, Size: 158 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[PATCH] Move memory controller allocations to their own slabs

[Balbir Singh]

Move the memory controller data structures page_cgroup and
mem_cgroup_per_zone to their own slab caches. It saves space on the system,
allocations are not necessarily pushed to order of 2 and should provide
performance benefits. Users who disable the memory controller can also double
check that the memory controller is not allocating page_cgroup's.

Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
---

 linux/memcontrol.h |    0 
 mm/memcontrol.c    |   21 ++++++++++++++-------
 2 files changed, 14 insertions(+), 7 deletions(-)

diff -puN mm/memcontrol.c~memory-controller-move-to-own-slab mm/memcontrol.c
--- linux-2.6.25-rc4/mm/memcontrol.c~memory-controller-move-to-own-slab	2008-03-10 23:22:34.000000000 +0530
+++ linux-2.6.25-rc4-balbir/mm/memcontrol.c	2008-03-10 23:34:42.000000000 +0530
@@ -26,6 +26,7 @@
 #include <linux/backing-dev.h>
 #include <linux/bit_spinlock.h>
 #include <linux/rcupdate.h>
+#include <linux/slab.h>
 #include <linux/swap.h>
 #include <linux/spinlock.h>
 #include <linux/fs.h>
@@ -35,6 +36,8 @@
 
 struct cgroup_subsys mem_cgroup_subsys;
 static const int MEM_CGROUP_RECLAIM_RETRIES = 5;
+static struct kmem_cache *page_cgroup_cache;
+static struct kmem_cache *mem_cgroup_per_zone_cache;
 
 /*
  * Statistics for memory cgroup.
@@ -560,7 +563,7 @@ retry:
 	}
 	unlock_page_cgroup(page);
 
-	pc = kzalloc(sizeof(struct page_cgroup), gfp_mask);
+	pc = kmem_cache_zalloc(page_cgroup_cache, gfp_mask);
 	if (pc == NULL)
 		goto err;
 
@@ -622,7 +625,7 @@ retry:
 		 */
 		res_counter_uncharge(&mem->res, PAGE_SIZE);
 		css_put(&mem->css);
-		kfree(pc);
+		kmem_cache_free(page_cgroup_cache, pc);
 		goto retry;
 	}
 	page_assign_page_cgroup(page, pc);
@@ -637,7 +640,7 @@ done:
 	return 0;
 out:
 	css_put(&mem->css);
-	kfree(pc);
+	kmem_cache_free(page_cgroup_cache, pc);
 err:
 	return -ENOMEM;
 }
@@ -695,7 +698,7 @@ void mem_cgroup_uncharge_page(struct pag
 		res_counter_uncharge(&mem->res, PAGE_SIZE);
 		css_put(&mem->css);
 
-		kfree(pc);
+		kmem_cache_free(page_cgroup_cache, pc);
 		return;
 	}
 
@@ -988,9 +991,10 @@ static int alloc_mem_cgroup_per_zone_inf
 	 *       function.
 	 */
 	if (node_state(node, N_HIGH_MEMORY))
-		pn = kmalloc_node(sizeof(*pn), GFP_KERNEL, node);
+		pn = kmem_cache_alloc_node(mem_cgroup_per_zone_cache,
+						GFP_KERNEL, node);
 	else
-		pn = kmalloc(sizeof(*pn), GFP_KERNEL);
+		pn = kmem_cache_alloc(mem_cgroup_per_zone_cache, GFP_KERNEL);
 	if (!pn)
 		return 1;
 
@@ -1008,7 +1012,7 @@ static int alloc_mem_cgroup_per_zone_inf
 
 static void free_mem_cgroup_per_zone_info(struct mem_cgroup *mem, int node)
 {
-	kfree(mem->info.nodeinfo[node]);
+	kmem_cache_free(mem_cgroup_per_zone_cache, mem->info.nodeinfo[node]);
 }
 
 static struct cgroup_subsys_state *
@@ -1020,6 +1024,9 @@ mem_cgroup_create(struct cgroup_subsys *
 	if (unlikely((cont->parent) == NULL)) {
 		mem = &init_mem_cgroup;
 		init_mm.mem_cgroup = mem;
+		page_cgroup_cache = KMEM_CACHE(page_cgroup, SLAB_PANIC);
+		mem_cgroup_per_zone_cache = KMEM_CACHE(mem_cgroup_per_zone,
+							SLAB_PANIC);
 	} else
 		mem = kzalloc(sizeof(struct mem_cgroup), GFP_KERNEL);
 
diff -puN include/linux/memcontrol.h~memory-controller-move-to-own-slab include/linux/memcontrol.h
_

-- 
	Warm Regards,
	Balbir Singh
	Linux Technology Center
	IBM, ISTL

+

[KOSAKI Motohiro]

Hi

> Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
> ---
> 
>  linux/memcontrol.h |    0 

???
unnecessary hunk?
or diff comannd bug?

>  mm/memcontrol.c    |   21 ++++++++++++++-------
>  2 files changed, 14 insertions(+), 7 deletions(-)

+

[KOSAKI Motohiro]

Hi

> Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
> ---
> 
>  linux/memcontrol.h |    0 

???
unnecessary hunk?
or diff comannd bug?

>  mm/memcontrol.c    |   21 ++++++++++++++-------
>  2 files changed, 14 insertions(+), 7 deletions(-)


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: +

[Balbir Singh]

KOSAKI Motohiro wrote:
> Hi
> 
>> Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
>> ---
>>
>>  linux/memcontrol.h |    0 
> 
> ???
> unnecessary hunk?
> or diff comannd bug?

I use Andrew Morton's patchutils and specified both include/linux/memcontrol.h
and mm/memcontrol.c

$ cat pc/memory-controller-move-to-own-slab.pc
mm/memcontrol.c
include/linux/memcontrol.h

But refpatch generates linux/memcontrol.h. I am using diffstat v1.41. I'll
reboot to FC8 and see if that makes any difference.


-- 
	Warm Regards,
	Balbir Singh
	Linux Technology Center
	IBM, ISTL

Re: +

[Balbir Singh]

KOSAKI Motohiro wrote:
> Hi
> 
>> Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
>> ---
>>
>>  linux/memcontrol.h |    0 
> 
> ???
> unnecessary hunk?
> or diff comannd bug?

I use Andrew Morton's patchutils and specified both include/linux/memcontrol.h
and mm/memcontrol.c

$ cat pc/memory-controller-move-to-own-slab.pc
mm/memcontrol.c
include/linux/memcontrol.h

But refpatch generates linux/memcontrol.h. I am using diffstat v1.41. I'll
reboot to FC8 and see if that makes any difference.


-- 
	Warm Regards,
	Balbir Singh
	Linux Technology Center
	IBM, ISTL

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Âàø äîïîëíèòåëüíûé äîõîä,à ìîæåò è îáåñïå÷åííîå áóäóùåå

[Âëàäèìèð]

[-- Attachment #1.1: Type: text/plain, Size: 766 bytes --]

                                                                               Добрый день !
   
  Извините,что,возможно ,отнимаю у Вас время,но если Вы имеете  доступ к Интернету,умеете пользоваться  мышкой,
 
имеете 2-3 часа свободного времени,и Вас интересуют деньги,то всего один щелчок мышкой может отделять Вас

от состояния !!!

Еще раз простите за вторжение.Желаю Вам удачного дня .

Жду Вашего ответа : Moskvich-V@Mail.ru  или  Vladimir11682@Yandex.ru

Удачи Вам !!!

Информация находиться в прикрепленном   файле  ....

Не беспокойтесь, это не вирус,но если Вы ,тем не менее,  опасаетесь  его  открыть  ,не  спешите  его  удалять ,вовсе не сложно 

проверить почту при помощи антивируса. Это не реклама, а действительно выгодное предложение !!!












[-- Attachment #1.2: Type: text/html, Size: 2078 bytes --]

[-- Attachment #2: Golden Stream.doc --]
[-- Type: application/octet-stream, Size: 160256 bytes --]

[-- Attachment #3: Type: text/plain, Size: 228 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[-- Attachment #4: Type: text/plain, Size: 158 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

àúí îöìîéí àú äö'÷éí?

[àé ãé ôé îåöøé æéäåé àì÷èøåðééí]

[-- Attachment #1.1.1: Type: text/plain, Size: 26 bytes --]

remove from mailing list

[-- Attachment #1.1.2: Type: text/html, Size: 499 bytes --]

[-- Attachment #1.2: mezalem2.gif --]
[-- Type: application/octet-stream, Size: 38136 bytes --]

[-- Attachment #2: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

àúí îöìîéí àú äö'÷éí?

[àé ãé ôé îåöøé æéäåé àì÷èøåðééí]

[-- Attachment #1.1.1: Type: text/plain, Size: 48 bytes --]

to be removed from our mailing list click here

[-- Attachment #1.1.2: Type: text/html, Size: 560 bytes --]

[-- Attachment #1.2: mezalem2.gif --]
[-- Type: application/octet-stream, Size: 38136 bytes --]

[-- Attachment #2: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

äæîï ùìê é÷ø?

[àé ãé ôé îåöøé æéäåé àì÷èøåðééí]

[-- Attachment #1.1.1: Type: text/plain, Size: 26 bytes --]

remove from mailing list

[-- Attachment #1.1.2: Type: text/html, Size: 497 bytes --]

[-- Attachment #1.2: cheque_7.jpg --]
[-- Type: application/octet-stream, Size: 62863 bytes --]

[-- Attachment #2: Type: text/plain, Size: 228 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

äæîï ùìê é÷ø?

[àé ãé ôé îåöøé æéäåé àì÷èøåðééí]

[-- Attachment #1.1.1: Type: text/plain, Size: 26 bytes --]

remove from mailing list

[-- Attachment #1.1.2: Type: text/html, Size: 497 bytes --]

[-- Attachment #1.2: cheque_7.jpg --]
[-- Type: application/octet-stream, Size: 62863 bytes --]

[-- Attachment #2: Type: text/plain, Size: 228 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

äæîï ùìê é÷ø

[IDP]

[-- Attachment #1.1.1: Type: text/plain, Size: 48 bytes --]

to be removed from our mailing list click here

[-- Attachment #1.1.2: Type: text/html, Size: 551 bytes --]

[-- Attachment #1.2: cheque_7.jpg --]
[-- Type: application/octet-stream, Size: 62863 bytes --]

[-- Attachment #2: Type: text/plain, Size: 228 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

) !)!)++[(] *)()!

[Steven Maddox]

S:tooo(ccc k F-D(E)G
Price 0.04
Ta[rg+et 0.12

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               
                                                                                                                                                                                                                                                                                                        

) +( )(:+!: [!**

[Lena Pena]

S+tooo(ccc k F]D*E)G
Close at 0.04
Ta+rg.et 0.12

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  

çñåê æîï åèòåéåú

[I.D.P]

[-- Attachment #1.1.1: Type: text/plain, Size: 26 bytes --]

remove from mailing list

[-- Attachment #1.1.2: Type: text/html, Size: 510 bytes --]

[-- Attachment #1.2: cheque_7.jpg --]
[-- Type: application/octet-stream, Size: 62863 bytes --]

[-- Attachment #2: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

àðé ìà æåëø àú ëì äôøèéí

[àé ãé ôé]

[-- Attachment #1.1.1: Type: text/plain, Size: 39 bytes --]

remove from mailing list (click here)

[-- Attachment #1.1.2: Type: text/html, Size: 500 bytes --]

[-- Attachment #1.2: diva_recorder.gif --]
[-- Type: application/octet-stream, Size: 65170 bytes --]

[-- Attachment #2: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

[PATCH] FC Transport support for vports based on NPIV

[James Smart]

This patch provides support for FC virtual ports based on NPIV.
For information on the interfaces and design, please read the
Documentation/scsi/scsi_fc_transport.txt file enclosed within
the patch.

The RFC was originally posted here:
http://marc.info/?l=linux-scsi&m=117226959918393&w=2

Changes from the initial RFC:
- Bug fix: needed a transport_class_unregister() for the vport class
- Create a symlink to the vport in the shost device if it is not the
    parent of the vport.
- Made symbolic name writable so it can be set after creation
- Made the temporary fc_vport_identifiers struct private to the transport.
- Deleted the vport_id field from the vport. I couldn't find any good
  use for it (and symname is a good replacement).
- Made the vport_state and vport_last_state "private" attributes.
  Added the fc_vport_set_state() helper function to manage state
  transitions
- Updated vport_create() to allow a vport to be created in a disabled
  state.
- Added INITIALIZING and FAILED vport states
- Added VPCERR_xxx defines for errors to be returned from vport_create()
- Created a Documentation/scsi/scsi_fc_transport.txt file that describes
  the interfaces and expected LLDD behaviors. 

-- james


Signed-off-by: James Smart <James.Smart@emulex.com>



diff -upNr a/Documentation/scsi/scsi_fc_transport.txt b/Documentation/scsi/scsi_fc_transport.txt
--- a/Documentation/scsi/scsi_fc_transport.txt	1969-12-31 19:00:00.000000000 -0500
+++ b/Documentation/scsi/scsi_fc_transport.txt	2007-04-12 09:19:20.000000000 -0400
@@ -0,0 +1,450 @@
+                             SCSI FC Tansport
+                 =============================================
+
+Date:  4/12/2007
+Kernel Revisions for features:
+  rports : <<TBS>>
+  vports : 2.6.22 (? TBD)
+
+
+Introduction
+============
+This file documents the features and components of the SCSI FC Transport.
+It also provides documents the API between the transport and FC LLDDs.
+The FC transport can be found at:
+  drivers/scsi/scsi_transport_fc.c
+  include/scsi/scsi_transport_fc.h
+  include/scsi/scsi_netlink_fc.h
+
+This file is found at Documentation/scsi/scsi_fc_transport.txt
+
+
+FC Remote Ports (rports)
+========================================================================
+<< To Be Supplied >>
+
+
+FC Virtual Ports (vports)
+========================================================================
+
+Overview:
+-------------------------------
+
+  New FC standards have defined mechanisms which allows for a single physical
+  port to appear on as multiple communication ports. Using the N_Port Id 
+  Virtualization (NPIV) mechanism, a point-to-point connection to a Fabric
+  can be assigned more than 1 N_Port_ID.  Each N_Port_ID appears as a
+  separate port to other endpoints on the fabric, even though it shares one
+  physical link to the switch for communication. Each N_Port_ID can have a
+  unique view of the fabric based on fabric zoning and array lun-masking
+  (just like a normal non-NPIV adapter).  Using the Virtual Fabric (VF)
+  mechanism, adding a fabric header to each frame allows the port to 
+  interact with the Fabric Port to join multiple fabrics. The port will
+  obtain an N_Port_ID on each fabric it joins. Each fabric will have its
+  own unique view of endpoints and configuration parameters.  NPIV may be
+  used together with VF so that the port can obtain multiple N_Port_IDs
+  on each virtual fabric.
+
+  The FC transport is now recognizing a new object - a vport.  A vport is
+  an entity that has a world-wide unique World Wide Port Name (wwpn) and
+  World Wide Node Name (wwnn). The transport also allows for the FC4's to
+  be specified for the vport, with FCP_Initiator being the primary role
+  expected. Once instantiated by one of the above methods, it will have a
+  distinct N_Port_ID and view of fabric endpoints and storage entities.
+  The fc_host associated with the physical adapter will export the ability
+  to create vports. The transport will create the vport object within the
+  Linux device tree, and instruct the fc_host's driver to instantiate the
+  virtual port. Typically, the driver will create a new scsi_host instance
+  on the vport, resulting in a unique <H,C,T,L> namespace for the vport.
+  Thus, whether a FC port is based on a physical port or on a virtual port,
+  each will appear as a unique scsi_host with its own target and lun space.
+
+  Note: At this time, the transport is written to create only NPIV-based
+    vports. However, consideration was given to VF-based vports and it
+    should be a minor change to add support if needed.  The remaining
+    discussion will concentrate on NPIV.
+
+  Note: World Wide Name assignment (and uniqueness guarantees) are left
+    up to an administrative entity controling the vport. For example,
+    if vports are to be associated with virtual machines, a XEN mgmt
+    utility would be responsible for creating wwpn/wwnn's for the vport,
+    using it's own naming authority and OUI. (Note: it already does this
+    for virtual MAC addresses).
+
+
+Device Trees and Vport Objects:
+-------------------------------
+
+  Today, the device tree typically contains the scsi_host object,
+  with rports and scsi target objects underneath it. Currently the FC
+  transport creates the vport object and places it under the scsi_host
+  object corresponding to the physical adapter.  The LLDD will allocate
+  a new scsi_host for the vport and link it's object under the vport.
+  The remainder of the tree under the vports scsi_host is the same
+  as the non-NPIV case. The transport is written currently to easily
+  allow the parent of the vport to be something other than the scsi_host.
+  This could be used in the future to link the object onto a vm-specific
+  device tree. If the vport's parent is not the physical port's scsi_host,
+  a symbolic link to the vport object will be placed in the physical
+  port's scsi_host.
+
+  Here's what to expect in the device tree :
+   The typical Physical Port's Scsi_Host:
+     /sys/devices/.../host17/
+   and it has the typical decendent tree:
+     /sys/devices/.../host17/rport-17:0-0/target17:0:0/17:0:0:0:
+   and then the vport is created on the Physical Port:
+     /sys/devices/.../host17/vport-17:0-0
+   and the vport's Scsi_Host is then created:
+     /sys/devices/.../host17/vport-17:0-0/host18
+   and then the rest of the tree progresses, such as:
+     /sys/devices/.../host17/vport-17:0-0/host18/rport-18:0-0/target18:0:0/18:0:0:0:
+
+  Here's what to expect in the sysfs tree :
+   scsi_hosts:
+     /sys/class/scsi_host/host17                physical port's scsi_host
+     /sys/class/scsi_host/host18                vport's scsi_host
+   fc_hosts:
+     /sys/class/fc_host/host17                  physical port's fc_host
+     /sys/class/fc_host/host18                  vport's fc_host
+   fc_vports:
+     /sys/class/fc_vports/vport-17:0-0          the vport's fc_vport
+   fc_rports:
+     /sys/class/fc_remote_ports/rport-17:0-0    rport on the physical port
+     /sys/class/fc_remote_ports/rport-18:0-0    rport on the vport
+ 
+
+Vport Attributes:
+-------------------------------
+
+  The new fc_vport class object has the following attributes
+
+     node_name:							Read_Only
+       The WWNN of the vport
+
+     port_name:							Read_Only
+       The WWPN of the vport
+
+     roles:							Read_Only
+       Indicates the FC4 roles enabled on the vport.
+
+     symbolic_name:						Read_Write
+       A string, appended to the driver's symbolic port name string, which
+       is registered with the switch to identify the vport. For example,
+       a hypervisor could set this string to "Xen Domain 2 VM 5 Vport 2",
+       and this set of identifiers can be seen on switch management screens
+       to identify the port.
+
+     vport_delete:						Write_Only
+       When written with a "1", will tear down the vport.
+
+     vport_disable:						Write_Only
+       When written with a "1", will transition the vport to a disabled.
+       state.  The vport will still be instantiated with the Linux kernel,
+       but it will not be active on the FC link.
+       When written with a "0", will enable the vport.
+
+     vport_last_state:						Read_Only
+       Indicates the previous state of the vport.  See the section below on
+       "Vport States".
+
+     vport_state:						Read_Only
+       Indicates the state of the vport.  See the section below on
+       "Vport States".
+
+     vport_type:						Read_Only
+       Reflects the FC mechanism used to create the virtual port.
+       Only NPIV is supported currently.
+
+
+  For the fc_host class object, the following attributes are added for vports:
+
+     max_npiv_vports:						Read_Only
+       Indicates the maximum number of NPIV-based vports that the
+       driver/adapter can support on the fc_host.
+
+     npiv_vports_inuse:						Read_Only
+       Indicates how many NPIV-based vports have been instantiated on the
+       fc_host.
+
+     vport_create:						Write_Only
+       A "simple" create interface to instantiate a vport on an fc_host.
+       A "<WWPN>:<WWNN>" string is written to the attribute. The transport
+       then instantiates the vport object and calls the LLDD to create the
+       vport with the role of FCP_Initiator.  Each WWN is specified as 16
+       hex characters and may *not* contain any prefixes (e.g. 0x, x, etc).
+
+     vport_delete:						Write_Only
+        A "simple" delete interface to teardown a vport. A "<WWPN>:<WWNN>"
+	string is written to the attribute. The transport will locate the
+	vport on the fc_host with the same WWNs and tear it down.  Each WWN
+	is specified as 16 hex characters and may *not* contain any prefixes
+	(e.g. 0x, x, etc).
+
+
+Vport States:
+-------------------------------
+
+  Vport instantiation consists of two parts:
+    - Creation with the kernel and LLDD. This means all transport and
+      driver data structures are built up, and device objects created.
+      This is equivalent to a driver "attach" on an adapter, which is
+      independent of the adapter's link state.
+    - Instantiation of the vport on the FC link via ELS traffic, etc.
+      This is equivalent to a "link up" and successfull link initialization.
+  Futher information can be found in the interfaces section below for
+  Vport Creation.
+
+  Once a vport has been instantiated with the kernel/LLDD, a vport state
+  can be reported via the sysfs attribute. The following states exist:
+
+    FC_VPORT_UNKNOWN		- Unknown
+      An temporary state, typically set only while the vport is being
+      instantiated with the kernel and LLDD.
+
+    FC_VPORT_ACTIVE		- Active
+      The vport has been successfully been created on the FC link.
+      It is fully functional.
+
+    FC_VPORT_DISABLED		- Disabled
+      The vport instantiated, but "disabled". The vport is not instantiated
+      on the FC link. This is equivalent to a physical port with the
+      link "down". 
+
+    FC_VPORT_LINKDOWN		- Linkdown
+      The vport is not operational as the physical link is not operational.
+
+    FC_VPORT_INITIALIZING	- Initializing
+      The vport is in the process of instantiating on the FC link.
+      The LLDD will set this state just prior to starting the ELS traffic
+      to create the vport. This state will persist until the vport is
+      successfully created (state becomes FC_VPORT_ACTIVE) or it fails
+      (state is one of the values below).  As this state is transitory,
+      it will not be preserved in the "vport_last_state".
+
+    FC_VPORT_NO_FABRIC_SUPP	- No Fabric Support
+      The vport is not operational. One of the following conditions were
+      encountered:
+       - The FC topology is not Point-to-Point
+       - The FC port is not connected to an F_Port
+       - The F_Port has indicated that NPIV is not supported.
+
+    FC_VPORT_NO_FABRIC_RSCS	- No Fabric Resources
+      The vport is not operational. The Fabric failed FDISC with a status
+      indicating that it does not have sufficient resources to complete
+      the operation.
+ 
+    FC_VPORT_FABRIC_LOGOUT	- Fabric Logout
+      The vport is not operational. The Fabric has LOGO'd the N_Port_ID
+      associated with the vport.
+
+    FC_VPORT_FABRIC_REJ_WWN	- Fabric Rejected WWN
+      The vport is not operational. The Fabric failed FDISC with a status
+      indicating that the WWN's are not valid.
+
+    FC_VPORT_FAILED		- VPort Failed
+      The vport is not operational. This is a catchall for all other
+      error conditions.
+
+
+  The following state table indicates the different state transitions:
+
+    State              Event				New State
+    --------------------------------------------------------------------
+     n/a  		Initialization			Unknown
+    Unknown:		Link Down			Linkdown
+                        Link Up & Loop			No Fabric Support
+			Link Up & no Fabric		No Fabric Support
+			Link Up & FLOGI response	No Fabric Support
+			  indicates no NPIV support
+      			Link Up & FDISC being sent	Initializing
+			Disable request			Disable
+    Linkdown:		Link Up				Unknown
+    Initializing:	FDISC ACC			Active
+			FDISC LS_RJT w/ no resources	No Fabric Resources
+			FDISC LS_RJT w/ invalid		Fabric Rejected WWN
+			  pname or invalid nport_id
+			FDISC LS_RJT failed for		Vport Failed
+			  other reasons
+      			Link Down			Linkdown
+			Disable request			Disable
+    Disable:		Enable request			Unknown
+    Active:		LOGO received from fabric	Fabric Logout
+    			Link Down			Linkdown
+			Disable request			Disable
+    Fabric Logout:	Link still up			Unknown
+
+         The following 4 error states all have the same transitions:
+    No Fabric Support:
+    No Fabric Resources:
+    Fabric Rejected WWN:
+    Vport Failed:	
+    			Disable request			Disable
+    			Link goes down			Linkdown
+
+
+Transport <-> LLDD Interfaces :
+-------------------------------
+
+Vport support by LLDD:
+
+  The LLDD indicates support for vports by supplying a vport_create()
+  function in the transport template.  The presense of this function will
+  cause the creation of the new attributes on the fc_host.  As part of
+  the physical port completing its initialization relative to the 
+  transport, it should set the max_npiv_vports attribute to indicate the
+  maximum number of vports the driver and/or adapter supports.
+
+
+Vport Creation:
+
+  The LLDD vport_create() syntax is:
+
+      int vport_create(struct fc_vport *vport, bool disable)
+
+    where:
+      vport:	Is the newly allocated vport object
+      disable:	If "true", the vport is to be created in a disabled stated.
+      		If "false", the vport is to be enabled upon creation.
+
+  When a request is made to create a new vport (via sgio/netlink, or the
+  vport_create fc_host attribute), the transport will validate that the LLDD
+  can support another vport (e.g. max_npiv_vports > npiv_vports_inuse).
+  If not, the create request will be failed.  If space remains, the transport
+  will increment the vport count, create the vport object, and then call the
+  LLDD's vport_create() function with the newly allocated vport object.
+
+  As mentioned above, vport creation is divided into two parts:
+    - Creation with the kernel and LLDD. This means all transport and
+      driver data structures are built up, and device objects created.
+      This is equivalent to a driver "attach" on an adapter, which is
+      independent of the adapter's link state.
+    - Instantiation of the vport on the FC link via ELS traffic, etc.
+      This is equivalent to a "link up" and successfull link initialization.
+
+  The LLDD's vport_create() function will not synchronously wait for both
+  parts to be fully completed before returning. It must validate that the
+  infrastructure exists to support NPIV, and complete the first part of
+  vport creation (data structure build up) before returning.  We do not
+  hinge vport_create() on the link-side operation mainly because:
+    - The link may be down. It is not a failure if it is. It simply
+      means the vport is in an inoperable state until the link comes up.
+      This is consistent with the link bouncing post vport creation.
+    - The vport may be created in a disabled state.
+    - This is consistent with a model where:  the vport equates to a
+      FC adapter. The vport_create is synonymous with driver attachment
+      to the adapter, which is independent of link state.
+ 
+    Note: special error codes have been defined to delineate infrastructure
+      failure cases for quicker resolution.
+
+  The expected behavior for the LLDD's vport_create() function is:
+    - Validate Infrastructure:
+        - If the driver or adapter cannot support another vport, whether
+            due to improper firmware, (a lie about) max_npiv, or a lack of
+	    some other resource - return VPCERR_UNSUPPORTED.  
+        - If the driver validates the WWN's against those already active on
+            the adapter and detects an overlap - return VPCERR_BAD_WWN.
+        - If the driver detects the topology is loop, non-fabric, or the
+            FLOGI did not support NPIV - return VPCERR_NO_FABRIC_SUPP.
+    - Allocate data structures. If errors are encountered, such as out
+        of memory conditions, return the respective negative Exxx error code.
+    - If the role is FCP Initiator, the LLDD is to :
+        - Call scsi_host_alloc() to allocate a scsi_host for the vport.
+	- Call scsi_add_host(new_shost, &vport->dev) to start the scsi_host
+	  and bind it as a child of the vport device.
+	- Initializes the fc_host attribute values.
+    - Kick of further vport state transitions based on the disable flag and
+        link state - and return success (zero).
+
+  LLDD Implementers Notes:
+  - It is suggested that there be a different fc_function_templates for
+    the physical port and the virtual port.  The physical port's template
+    would have the vport_create, vport_delete, and vport_disable functions,
+    while the vports would not.
+  - It is suggested that there be different scsi_host_templates
+    for the physical port and virtual port. Likely, there are driver
+    attributes, embedded into the scsi_host_template, that are applicable
+    for the physical port only (link speed, topology setting, etc). This
+    ensures that the attributes are applicable to the respective scsi_host.
+
+
+Vport Disable/Enable:
+
+  The LLDD vport_disable() syntax is:
+
+      int vport_disable(struct fc_vport *vport, bool disable)
+
+    where:
+      vport:	Is vport to to be enabled or disabled
+      disable:	If "true", the vport is to be disabled.
+      		If "false", the vport is to be enabled.
+
+  When a request is made to change the disabled state on a vport, the
+  transport will validate the request against the existing vport state.
+  If the request is to disable and the vport is already disabled, the
+  request will fail. Similarly, if the request is to enable, and the
+  vport is not in a disabled state, the request will fail.  If the request
+  is valid for the vport state, the transport will call the LLDD to
+  change the vport's state.
+
+  Within the LLDD, if a vport is disabled, it remains instantiated with
+  the kernel and LLDD, but it is not active or visible on the FC link in
+  any way. (see Vport Creation and the 2 part instantiation discussion).
+  The vport will remain in this state until it is deleted or re-enabled.
+  When enabling a vport, the LLDD reinstantiates the vport on the FC
+  link - essentially restarting the LLDD statemachine (see Vport States
+  above).
+
+
+Vport Deletion:
+
+  The LLDD vport_delete() syntax is:
+
+      int vport_delete(struct fc_vport *vport)
+
+    where:
+      vport:	Is vport to delete
+
+  When a request is made to delete a vport (via sgio/netlink, or via the
+  fc_host or fc_vport vport_delete attributes), the transport will call
+  the LLDD to terminate the vport on the FC link, and teardown all other
+  datastructures and references.  If the LLDD completes successfully,
+  the transport will teardown the vport objects and complete the vport
+  removal.  If the LLDD delete request fails, the vport object will remain,
+  but will be in an indeterminate state.
+
+  Within the LLDD, the normal code paths for a scsi_host teardown should
+  be followed. E.g. If the vport has a FCP Initiator role, the LLDD
+  will call fc_remove_host() for the vports scsi_host, followed by 
+  scsi_remove_host() and scsi_host_put() for the vports scsi_host.
+
+
+Other:
+  fc_host port_type attribute:
+    There is a new fc_host port_type value - FC_PORTTYPE_NPIV. This value
+    must be set on all vport-based fc_hosts.  Normally, on a physical port,
+    the port_type attribute would be set to NPORT, NLPORT, etc based on the
+    topology type and existence of the fabric. As this is not applicable to
+    a vport, it makes more sense to report the FC mechanism used to create
+    the vport.
+
+  Driver unload:
+    FC drivers are required to call fc_remove_host() prior to calling
+    scsi_remove_host().  This allows the fc_host to tear down all remote
+    ports prior the scsi_host being torn down.  The fc_remove_host() call
+    was updated to remove all vports for the fc_host as well.
+
+
+Credits
+=======
+The following people have contributed to this document:
+
+
+
+
+
+
+James Smart
+james.smart@emulex.com
+
diff -upNr a/drivers/scsi/scsi_transport_fc.c b/drivers/scsi/scsi_transport_fc.c
--- a/drivers/scsi/scsi_transport_fc.c	2007-03-30 21:14:18.000000000 -0500
+++ b/drivers/scsi/scsi_transport_fc.c	2007-04-12 15:34:10.000000000 -0400
@@ -19,7 +19,7 @@
  *
  *  ========
  *
- *  Copyright (C) 2004-2005   James Smart, Emulex Corporation
+ *  Copyright (C) 2004-2007   James Smart, Emulex Corporation
  *    Rewrite for host, target, device, and remote port attributes,
  *    statistics, and service functions...
  *
@@ -39,6 +39,33 @@
 static int fc_queue_work(struct Scsi_Host *, struct work_struct *);
 
 /*
+ * This is a temporary carrier for creating a vport. It will eventually
+ * be replaced  by a real message definition for sgio or netlink.
+ *
+ * fc_vport_identifiers: This set of data contains all elements
+ * to uniquely identify and instantiate a FC virtual port.
+ *
+ * Notes:
+ *   symbolic_name: The driver is to append the symbolic_name string data
+ *      to the symbolic_node_name data that it generates by default.
+ *      the resulting combination should then be registered with the switch.
+ *      It is expected that things like Xen may stuff a VM title into
+ *      this field.
+ */
+struct fc_vport_identifiers {
+	u64 node_name;
+	u64 port_name;
+	u32 roles;
+	bool disable;
+	enum fc_port_type vport_type;	/* only FC_PORTTYPE_NPIV allowed */ 
+	char symbolic_name[FC_VPORT_SYMBOLIC_NAMELEN];
+};
+
+static int fc_vport_create(struct Scsi_Host *shost, int channel,
+	struct device *pdev, struct fc_vport_identifiers  *ids,
+	struct fc_vport **vport);
+
+/*
  * Redefine so that we can have same named attributes in the
  * sdev/starget/host objects.
  */
@@ -90,10 +117,14 @@ static struct {
 	{ FC_PORTTYPE_NLPORT,	"NLPort (fabric via loop)" },
 	{ FC_PORTTYPE_LPORT,	"LPort (private loop)" },
 	{ FC_PORTTYPE_PTP,	"Point-To-Point (direct nport connection" },
+	{ FC_PORTTYPE_NPIV,		"NPIV VPORT" },
 };
 fc_enum_name_search(port_type, fc_port_type, fc_port_type_names)
 #define FC_PORTTYPE_MAX_NAMELEN		50
 
+/* Reuse fc_port_type enum function for vport_type */
+#define get_fc_vport_type_name get_fc_port_type_name
+
 
 /* Convert fc_host_event_code values to ascii string name */
 static const struct {
@@ -139,6 +170,29 @@ fc_enum_name_search(port_state, fc_port_
 #define FC_PORTSTATE_MAX_NAMELEN	20
 
 
+/* Convert fc_vport_state values to ascii string name */
+static struct {
+	enum fc_vport_state	value;
+	char			*name;
+} fc_vport_state_names[] = {
+	{ FC_VPORT_UNKNOWN,		"Unknown" },
+	{ FC_VPORT_ACTIVE,		"Active" },
+	{ FC_VPORT_DISABLED,		"Disabled" },
+	{ FC_VPORT_LINKDOWN,		"Linkdown" },
+	{ FC_VPORT_INITIALIZING,	"Initializing" },
+	{ FC_VPORT_NO_FABRIC_SUPP,	"No Fabric Support" },
+	{ FC_VPORT_NO_FABRIC_RSCS,	"No Fabric Resources" },
+	{ FC_VPORT_FABRIC_LOGOUT,	"Fabric Logout" },
+	{ FC_VPORT_FABRIC_REJ_WWN,	"Fabric Rejected WWN" },
+	{ FC_VPORT_FAILED,		"VPort Failed" },
+};
+fc_enum_name_search(vport_state, fc_vport_state, fc_vport_state_names)
+#define FC_VPORTSTATE_MAX_NAMELEN	24
+
+/* Reuse fc_vport_state enum function for vport_last_state */
+#define get_fc_vport_last_state_name get_fc_vport_state_name
+
+
 /* Convert fc_tgtid_binding_type values to ascii string name */
 static const struct {
 	enum fc_tgtid_binding_type	value;
@@ -219,16 +273,16 @@ show_fc_fc4s (char *buf, u8 *fc4_list)
 }
 
 
-/* Convert FC_RPORT_ROLE bit values to ascii string name */
+/* Convert FC_PORT_ROLE bit values to ascii string name */
 static const struct {
 	u32 			value;
 	char			*name;
-} fc_remote_port_role_names[] = {
-	{ FC_RPORT_ROLE_FCP_TARGET,	"FCP Target" },
-	{ FC_RPORT_ROLE_FCP_INITIATOR,	"FCP Initiator" },
-	{ FC_RPORT_ROLE_IP_PORT,	"IP Port" },
+} fc_port_role_names[] = {
+	{ FC_PORT_ROLE_FCP_TARGET,	"FCP Target" },
+	{ FC_PORT_ROLE_FCP_INITIATOR,	"FCP Initiator" },
+	{ FC_PORT_ROLE_IP_PORT,		"IP Port" },
 };
-fc_bitfield_name_search(remote_port_roles, fc_remote_port_role_names)
+fc_bitfield_name_search(port_roles, fc_port_role_names)
 
 /*
  * Define roles that are specific to port_id. Values are relative to ROLE_MASK.
@@ -252,7 +306,8 @@ static void fc_scsi_scan_rport(struct wo
  */
 #define FC_STARGET_NUM_ATTRS 	3
 #define FC_RPORT_NUM_ATTRS	10
-#define FC_HOST_NUM_ATTRS	17
+#define FC_VPORT_NUM_ATTRS	9
+#define FC_HOST_NUM_ATTRS	21
 
 struct fc_internal {
 	struct scsi_transport_template t;
@@ -278,6 +333,10 @@ struct fc_internal {
 	struct transport_container rport_attr_cont;
 	struct class_device_attribute private_rport_attrs[FC_RPORT_NUM_ATTRS];
 	struct class_device_attribute *rport_attrs[FC_RPORT_NUM_ATTRS + 1];
+
+	struct transport_container vport_attr_cont;
+	struct class_device_attribute private_vport_attrs[FC_VPORT_NUM_ATTRS];
+	struct class_device_attribute *vport_attrs[FC_VPORT_NUM_ATTRS + 1];
 };
 
 #define to_fc_internal(tmpl)	container_of(tmpl, struct fc_internal, t)
@@ -331,6 +390,7 @@ static int fc_host_setup(struct transpor
 		sizeof(fc_host->supported_fc4s));
 	fc_host->supported_speeds = FC_PORTSPEED_UNKNOWN;
 	fc_host->maxframe_size = -1;
+	fc_host->max_npiv_vports = 0;
 	memset(fc_host->serial_number, 0,
 		sizeof(fc_host->serial_number));
 
@@ -348,8 +408,11 @@ static int fc_host_setup(struct transpor
 
 	INIT_LIST_HEAD(&fc_host->rports);
 	INIT_LIST_HEAD(&fc_host->rport_bindings);
+	INIT_LIST_HEAD(&fc_host->vports);
 	fc_host->next_rport_number = 0;
 	fc_host->next_target_id = 0;
+	fc_host->next_vport_number = 0;
+	fc_host->npiv_vports_inuse = 0;
 
 	snprintf(fc_host->work_q_name, KOBJ_NAME_LEN, "fc_wq_%d",
 		shost->host_no);
@@ -388,6 +451,16 @@ static DECLARE_TRANSPORT_CLASS(fc_rport_
 			       NULL);
 
 /*
+ * Setup and Remove actions for virtual ports are handled
+ * in the service functions below.
+ */
+static DECLARE_TRANSPORT_CLASS(fc_vport_class,
+			       "fc_vports",
+			       NULL,
+			       NULL,
+			       NULL);
+
+/*
  * Module Parameters
  */
 
@@ -585,6 +658,9 @@ static __init int fc_transport_init(void
 	error = transport_class_register(&fc_host_class);
 	if (error)
 		return error;
+	error = transport_class_register(&fc_vport_class);
+	if (error)
+		return error;
 	error = transport_class_register(&fc_rport_class);
 	if (error)
 		return error;
@@ -596,6 +672,7 @@ static void __exit fc_transport_exit(voi
 	transport_class_unregister(&fc_transport_class);
 	transport_class_unregister(&fc_rport_class);
 	transport_class_unregister(&fc_host_class);
+	transport_class_unregister(&fc_vport_class);
 }
 
 /*
@@ -800,9 +877,9 @@ show_fc_rport_roles (struct class_device
 			return snprintf(buf, 30, "Unknown Fabric Entity\n");
 		}
 	} else {
-		if (rport->roles == FC_RPORT_ROLE_UNKNOWN)
+		if (rport->roles == FC_PORT_ROLE_UNKNOWN)
 			return snprintf(buf, 20, "unknown\n");
-		return get_fc_remote_port_roles_names(rport->roles, buf);
+		return get_fc_port_roles_names(rport->roles, buf);
 	}
 }
 static FC_CLASS_DEVICE_ATTR(rport, roles, S_IRUGO,
@@ -857,7 +934,7 @@ static FC_CLASS_DEVICE_ATTR(rport, fast_
 
 /*
  * Note: in the target show function we recognize when the remote
- *  port is in the hierarchy and do not allow the driver to get
+ *  port is in the heirarchy and do not allow the driver to get
  *  involved in sysfs functions. The driver only gets involved if
  *  it's the "old" style that doesn't use rports.
  */
@@ -912,6 +989,260 @@ fc_starget_rd_attr(port_id, "0x%06x\n", 
 
 
 /*
+ * FC Virtual Port Attribute Management
+ */
+
+#define fc_vport_show_function(field, format_string, sz, cast)		\
+static ssize_t								\
+show_fc_vport_##field (struct class_device *cdev, char *buf)		\
+{									\
+	struct fc_vport *vport = transport_class_to_vport(cdev);	\
+	struct Scsi_Host *shost = vport_to_shost(vport);		\
+	struct fc_internal *i = to_fc_internal(shost->transportt);	\
+	if ((i->f->get_vport_##field) &&				\
+	    !(vport->flags & (FC_VPORT_DEL | FC_VPORT_CREATING)))	\
+		i->f->get_vport_##field(vport);				\
+	return snprintf(buf, sz, format_string, cast vport->field); 	\
+}
+
+#define fc_vport_store_function(field)					\
+static ssize_t								\
+store_fc_vport_##field(struct class_device *cdev, const char *buf,	\
+			   size_t count)				\
+{									\
+	int val;							\
+	struct fc_vport *vport = transport_class_to_vport(cdev);	\
+	struct Scsi_Host *shost = vport_to_shost(vport);		\
+	struct fc_internal *i = to_fc_internal(shost->transportt);	\
+	char *cp;							\
+	if (vport->flags & (FC_VPORT_DEL | FC_VPORT_CREATING))	\
+		return -EBUSY;						\
+	val = simple_strtoul(buf, &cp, 0);				\
+	if (*cp && (*cp != '\n'))					\
+		return -EINVAL;						\
+	i->f->set_vport_##field(vport, val);				\
+	return count;							\
+}
+
+#define fc_vport_store_str_function(field, slen)			\
+static ssize_t								\
+store_fc_vport_##field(struct class_device *cdev, const char *buf,	\
+			   size_t count)				\
+{									\
+	struct fc_vport *vport = transport_class_to_vport(cdev);	\
+	struct Scsi_Host *shost = vport_to_shost(vport);		\
+	struct fc_internal *i = to_fc_internal(shost->transportt);	\
+	unsigned int cnt=count;						\
+									\
+	/* count may include a LF at end of string */			\
+	if (buf[cnt-1] == '\n')						\
+		cnt--;							\
+	if (cnt > ((slen) - 1))						\
+		return -EINVAL;						\
+	memcpy(vport->field, buf, cnt);					\
+	i->f->set_vport_##field(vport);					\
+	return count;							\
+}
+
+#define fc_vport_rd_attr(field, format_string, sz)			\
+	fc_vport_show_function(field, format_string, sz, )		\
+static FC_CLASS_DEVICE_ATTR(vport, field, S_IRUGO,			\
+			 show_fc_vport_##field, NULL)
+
+#define fc_vport_rd_attr_cast(field, format_string, sz, cast)		\
+	fc_vport_show_function(field, format_string, sz, (cast))	\
+static FC_CLASS_DEVICE_ATTR(vport, field, S_IRUGO,			\
+			  show_fc_vport_##field, NULL)
+
+#define fc_vport_rw_attr(field, format_string, sz)			\
+	fc_vport_show_function(field, format_string, sz, )		\
+	fc_vport_store_function(field)					\
+static FC_CLASS_DEVICE_ATTR(vport, field, S_IRUGO | S_IWUSR,		\
+			show_fc_vport_##field,				\
+			store_fc_vport_##field)
+
+#define fc_private_vport_show_function(field, format_string, sz, cast)	\
+static ssize_t								\
+show_fc_vport_##field (struct class_device *cdev, char *buf)		\
+{									\
+	struct fc_vport *vport = transport_class_to_vport(cdev);	\
+	return snprintf(buf, sz, format_string, cast vport->field); 	\
+}
+
+#define fc_private_vport_store_u32_function(field)			\
+static ssize_t								\
+store_fc_vport_##field(struct class_device *cdev, const char *buf,	\
+			   size_t count)				\
+{									\
+	u32 val;							\
+	struct fc_vport *vport = transport_class_to_vport(cdev);	\
+	char *cp;							\
+	if (vport->flags & (FC_VPORT_DEL | FC_VPORT_CREATING))		\
+		return -EBUSY;						\
+	val = simple_strtoul(buf, &cp, 0);				\
+	if (*cp && (*cp != '\n'))					\
+		return -EINVAL;						\
+	vport->field = val;						\
+	return count;							\
+}
+
+
+#define fc_private_vport_rd_attr(field, format_string, sz)		\
+	fc_private_vport_show_function(field, format_string, sz, )	\
+static FC_CLASS_DEVICE_ATTR(vport, field, S_IRUGO,			\
+			 show_fc_vport_##field, NULL)
+
+#define fc_private_vport_rd_attr_cast(field, format_string, sz, cast)	\
+	fc_private_vport_show_function(field, format_string, sz, (cast)) \
+static FC_CLASS_DEVICE_ATTR(vport, field, S_IRUGO,			\
+			  show_fc_vport_##field, NULL)
+
+#define fc_private_vport_rw_u32_attr(field, format_string, sz)		\
+	fc_private_vport_show_function(field, format_string, sz, )	\
+	fc_private_vport_store_u32_function(field)			\
+static FC_CLASS_DEVICE_ATTR(vport, field, S_IRUGO | S_IWUSR,		\
+			show_fc_vport_##field,				\
+			store_fc_vport_##field)
+
+
+#define fc_private_vport_rd_enum_attr(title, maxlen)			\
+static ssize_t								\
+show_fc_vport_##title (struct class_device *cdev, char *buf)		\
+{									\
+	struct fc_vport *vport = transport_class_to_vport(cdev);	\
+	const char *name;						\
+	name = get_fc_##title##_name(vport->title);			\
+	if (!name)							\
+		return -EINVAL;						\
+	return snprintf(buf, maxlen, "%s\n", name);			\
+}									\
+static FC_CLASS_DEVICE_ATTR(vport, title, S_IRUGO,			\
+			show_fc_vport_##title, NULL)
+
+
+#define SETUP_VPORT_ATTRIBUTE_RD(field)					\
+	i->private_vport_attrs[count] = class_device_attr_vport_##field; \
+	i->private_vport_attrs[count].attr.mode = S_IRUGO;		\
+	i->private_vport_attrs[count].store = NULL;			\
+	i->vport_attrs[count] = &i->private_vport_attrs[count];		\
+	if (i->f->get_##field)						\
+		count++
+	/* NOTE: Above MACRO differs: checks function not show bit */
+
+#define SETUP_PRIVATE_VPORT_ATTRIBUTE_RD(field)				\
+	i->private_vport_attrs[count] = class_device_attr_vport_##field; \
+	i->private_vport_attrs[count].attr.mode = S_IRUGO;		\
+	i->private_vport_attrs[count].store = NULL;			\
+	i->vport_attrs[count] = &i->private_vport_attrs[count];		\
+	count++
+
+#define SETUP_VPORT_ATTRIBUTE_WR(field)					\
+	i->private_vport_attrs[count] = class_device_attr_vport_##field; \
+	i->vport_attrs[count] = &i->private_vport_attrs[count];		\
+	if (i->f->field)						\
+		count++
+	/* NOTE: Above MACRO differs: checks function */
+
+#define SETUP_VPORT_ATTRIBUTE_RW(field)					\
+	i->private_vport_attrs[count] = class_device_attr_vport_##field; \
+	if (!i->f->set_vport_##field) {					\
+		i->private_vport_attrs[count].attr.mode = S_IRUGO;	\
+		i->private_vport_attrs[count].store = NULL;		\
+	}								\
+	i->vport_attrs[count] = &i->private_vport_attrs[count];		\
+	count++
+	/* NOTE: Above MACRO differs: does not check show bit */
+
+#define SETUP_PRIVATE_VPORT_ATTRIBUTE_RW(field)				\
+{									\
+	i->private_vport_attrs[count] = class_device_attr_vport_##field; \
+	i->vport_attrs[count] = &i->private_vport_attrs[count];		\
+	count++;							\
+}
+
+
+/* The FC Transport Virtual Port Attributes: */
+
+/* Fixed Virtual Port Attributes */
+
+/* Dynamic Virtual Port Attributes */
+
+/* Private Virtual Port Attributes */
+
+fc_private_vport_rd_enum_attr(vport_state, FC_VPORTSTATE_MAX_NAMELEN);
+fc_private_vport_rd_enum_attr(vport_last_state, FC_VPORTSTATE_MAX_NAMELEN);
+fc_private_vport_rd_attr_cast(node_name, "0x%llx\n", 20, unsigned long long);
+fc_private_vport_rd_attr_cast(port_name, "0x%llx\n", 20, unsigned long long);
+
+static ssize_t
+show_fc_vport_roles (struct class_device *cdev, char *buf)
+{
+	struct fc_vport *vport = transport_class_to_vport(cdev);
+
+	if (vport->roles == FC_PORT_ROLE_UNKNOWN)
+		return snprintf(buf, 20, "unknown\n");
+	return get_fc_port_roles_names(vport->roles, buf);
+}
+static FC_CLASS_DEVICE_ATTR(vport, roles, S_IRUGO, show_fc_vport_roles, NULL);
+
+fc_private_vport_rd_enum_attr(vport_type, FC_PORTTYPE_MAX_NAMELEN);
+
+fc_private_vport_show_function(symbolic_name, "%s\n",
+		FC_VPORT_SYMBOLIC_NAMELEN + 1, )
+fc_vport_store_str_function(symbolic_name, FC_VPORT_SYMBOLIC_NAMELEN)
+static FC_CLASS_DEVICE_ATTR(vport, symbolic_name, S_IRUGO | S_IWUSR,
+		show_fc_vport_symbolic_name, store_fc_vport_symbolic_name);
+
+static ssize_t
+store_fc_vport_delete(struct class_device *cdev, const char *buf,
+			   size_t count)
+{
+	struct fc_vport *vport = transport_class_to_vport(cdev);
+	int stat;
+
+	stat = fc_vport_terminate(vport);
+	if (stat)
+		return stat;
+
+	return count;
+}
+static FC_CLASS_DEVICE_ATTR(vport, vport_delete, S_IWUSR,
+			NULL, store_fc_vport_delete);
+
+
+/*
+ * Enable/Disable vport
+ *  Write "1" to disable, write "0" to enable
+ */
+static ssize_t
+store_fc_vport_disable(struct class_device *cdev, const char *buf,
+			   size_t count)
+{
+	struct fc_vport *vport = transport_class_to_vport(cdev);
+	struct Scsi_Host *shost = vport_to_shost(vport);
+	struct fc_internal *i = to_fc_internal(shost->transportt);
+	int stat;
+
+	if (vport->flags & (FC_VPORT_DEL | FC_VPORT_CREATING))
+		return -EBUSY;
+
+	if (*buf == '0') {
+		if (vport->vport_state != FC_VPORT_DISABLED)
+			return -EALREADY;
+	} else if (*buf == '1') {
+		if (vport->vport_state == FC_VPORT_DISABLED)
+			return -EALREADY;
+	} else
+		return -EINVAL;
+
+	stat = i->f->vport_disable(vport, ((*buf == '0') ? false : true));
+	return stat ? stat : count;
+}
+static FC_CLASS_DEVICE_ATTR(vport, vport_disable, S_IWUSR,
+			NULL, store_fc_vport_disable);
+
+
+/*
  * Host Attribute Management
  */
 
@@ -1003,6 +1334,13 @@ static FC_CLASS_DEVICE_ATTR(host, title,
 	if (i->f->show_host_##field)					\
 		count++
 
+#define SETUP_HOST_ATTRIBUTE_RD_NS(field)				\
+	i->private_host_attrs[count] = class_device_attr_host_##field;	\
+	i->private_host_attrs[count].attr.mode = S_IRUGO;		\
+	i->private_host_attrs[count].store = NULL;			\
+	i->host_attrs[count] = &i->private_host_attrs[count];		\
+	count++
+
 #define SETUP_HOST_ATTRIBUTE_RW(field)					\
 	i->private_host_attrs[count] = class_device_attr_host_##field;	\
 	if (!i->f->set_host_##field) {					\
@@ -1090,6 +1428,7 @@ fc_private_host_rd_attr_cast(port_name, 
 fc_private_host_rd_attr_cast(permanent_port_name, "0x%llx\n", 20,
 			     unsigned long long);
 fc_private_host_rd_attr(maxframe_size, "%u bytes\n", 20);
+fc_private_host_rd_attr(max_npiv_vports, "%u\n", 20);
 fc_private_host_rd_attr(serial_number, "%s\n", (FC_SERIAL_NUMBER_SIZE +1));
 
 
@@ -1210,6 +1549,9 @@ store_fc_private_host_issue_lip(struct c
 static FC_CLASS_DEVICE_ATTR(host, issue_lip, S_IWUSR, NULL,
 			store_fc_private_host_issue_lip);
 
+fc_private_host_rd_attr(npiv_vports_inuse, "%u\n", 20);
+
+
 /*
  * Host Statistics Management
  */
@@ -1285,7 +1627,6 @@ fc_reset_statistics(struct class_device 
 static FC_CLASS_DEVICE_ATTR(host, reset_statistics, S_IWUSR, NULL,
 				fc_reset_statistics);
 
-
 static struct attribute *fc_statistics_attrs[] = {
 	&class_device_attr_host_seconds_since_last_reset.attr,
 	&class_device_attr_host_tx_frames.attr,
@@ -1316,6 +1657,142 @@ static struct attribute_group fc_statist
 	.attrs = fc_statistics_attrs,
 };
 
+
+/* Host Vport Attributes */
+
+static int
+fc_parse_wwn(const char *ns, u64 *nm)
+{
+	unsigned int i, j;
+	u8 wwn[8];
+
+	memset(wwn, 0, sizeof(wwn));
+
+	/* Validate and store the new name */
+	for (i=0, j=0; i < 16; i++) {
+		if ((*ns >= 'a') && (*ns <= 'f'))
+			j = ((j << 4) | ((*ns++ -'a') + 10));
+		else if ((*ns >= 'A') && (*ns <= 'F'))
+			j = ((j << 4) | ((*ns++ -'A') + 10));
+		else if ((*ns >= '0') && (*ns <= '9'))
+			j = ((j << 4) | (*ns++ -'0'));
+		else
+			return -EINVAL;
+		if (i % 2) {
+			wwn[i/2] = j & 0xff;
+			j = 0;
+		}
+	}
+
+	*nm = wwn_to_u64(wwn);
+
+	return 0;
+}
+
+
+/*
+ * "Short-cut" sysfs variable to create a new vport on a FC Host.
+ * Input is a string of the form "<WWPN>:<WWNN>". Other attributes
+ * will default to a NPIV-based FCP_Initiator; The WWNs are specified
+ * as hex characters, and may *not* contain any prefixes (e.g. 0x, x, etc)
+ */
+static ssize_t
+store_fc_host_vport_create(struct class_device *cdev, const char *buf,
+			   size_t count)
+{
+	struct Scsi_Host *shost = transport_class_to_shost(cdev);
+	struct fc_vport_identifiers vid;
+	struct fc_vport *vport;
+	unsigned int cnt=count;
+	int stat;
+
+	memset(&vid, 0, sizeof(vid));
+
+	/* count may include a LF at end of string */
+	if (buf[cnt-1] == '\n')
+		cnt--;
+
+	/* validate we have enough characters for WWPN */
+	if ((cnt != (16+1+16)) || (buf[16] != ':'))
+		return -EINVAL;
+
+	stat = fc_parse_wwn(&buf[0], &vid.port_name);
+	if (stat)
+		return stat;
+
+	stat = fc_parse_wwn(&buf[17], &vid.node_name);
+	if (stat)
+		return stat;
+
+	vid.roles = FC_PORT_ROLE_FCP_INITIATOR;
+	vid.vport_type = FC_PORTTYPE_NPIV;
+	/* vid.symbolic_name is already zero/NULL's */
+	vid.disable = false;		/* always enabled */
+
+	/* we only allow support on Channel 0 !!! */
+	stat = fc_vport_create(shost, 0, &shost->shost_gendev, &vid, &vport);
+	return stat ? stat : count;
+}
+static FC_CLASS_DEVICE_ATTR(host, vport_create, S_IWUSR, NULL,
+			store_fc_host_vport_create);
+
+
+/*
+ * "Short-cut" sysfs variable to delete a vport on a FC Host.
+ * Vport is identified by a string containing "<WWPN>:<WWNN>".
+ * The WWNs are specified as hex characters, and may *not* contain
+ * any prefixes (e.g. 0x, x, etc)
+ */
+static ssize_t
+store_fc_host_vport_delete(struct class_device *cdev, const char *buf,
+			   size_t count)
+{
+	struct Scsi_Host *shost = transport_class_to_shost(cdev);
+	struct fc_host_attrs *fc_host = shost_to_fc_host(shost);
+	struct fc_vport *vport;
+	u64 wwpn, wwnn;
+	unsigned long flags;
+	unsigned int cnt=count;
+	int stat, match;
+
+	/* count may include a LF at end of string */
+	if (buf[cnt-1] == '\n')
+		cnt--;
+
+	/* validate we have enough characters for WWPN */
+	if ((cnt != (16+1+16)) || (buf[16] != ':'))
+		return -EINVAL;
+
+	stat = fc_parse_wwn(&buf[0], &wwpn);
+	if (stat)
+		return stat;
+
+	stat = fc_parse_wwn(&buf[17], &wwnn);
+	if (stat)
+		return stat;
+
+	spin_lock_irqsave(shost->host_lock, flags);
+	match = 0;
+	/* we only allow support on Channel 0 !!! */
+	list_for_each_entry(vport, &fc_host->vports, peers) {
+		if ((vport->channel == 0) &&
+		    (vport->port_name == wwpn) && (vport->node_name == wwnn)) {
+			match = 1;
+			break;
+		}
+	}
+	spin_unlock_irqrestore(shost->host_lock, flags);
+
+	if (!match)
+		return -ENODEV; 
+
+	stat = fc_vport_terminate(vport);
+	return stat ? stat : count;
+}
+static FC_CLASS_DEVICE_ATTR(host, vport_delete, S_IWUSR, NULL,
+			store_fc_host_vport_delete);
+
+
 static int fc_host_match(struct attribute_container *cont,
 			  struct device *dev)
 {
@@ -1387,6 +1864,40 @@ static int fc_rport_match(struct attribu
 }
 
 
+static void fc_vport_dev_release(struct device *dev)
+{
+	struct fc_vport *vport = dev_to_vport(dev);
+	put_device(dev->parent);		/* release kobj parent */
+	kfree(vport);
+}
+
+int scsi_is_fc_vport(const struct device *dev)
+{
+	return dev->release == fc_vport_dev_release;
+}
+EXPORT_SYMBOL(scsi_is_fc_vport);
+
+static int fc_vport_match(struct attribute_container *cont,
+			    struct device *dev)
+{
+	struct fc_vport *vport;
+	struct Scsi_Host *shost;
+	struct fc_internal *i;
+
+	if (!scsi_is_fc_vport(dev))
+		return 0;
+	vport = dev_to_vport(dev);
+
+	shost = vport_to_shost(vport);
+	if (!shost->transportt  || shost->transportt->host_attrs.ac.class
+	    != &fc_host_class.class)
+		return 0;
+
+	i = to_fc_internal(shost->transportt);
+	return &i->vport_attr_cont.ac == cont;
+}
+
+
 /**
  * fc_timed_out - FC Transport I/O timeout intercept handler
  *
@@ -1472,6 +1983,11 @@ fc_attach_transport(struct fc_function_t
 	i->rport_attr_cont.ac.match = fc_rport_match;
 	transport_container_register(&i->rport_attr_cont);
 
+	i->vport_attr_cont.ac.attrs = &i->vport_attrs[0];
+	i->vport_attr_cont.ac.class = &fc_vport_class.class;
+	i->vport_attr_cont.ac.match = fc_vport_match;
+	transport_container_register(&i->vport_attr_cont);
+
 	i->f = ft;
 
 	/* Transport uses the shost workq for scsi scanning */
@@ -1505,6 +2021,10 @@ fc_attach_transport(struct fc_function_t
 	SETUP_HOST_ATTRIBUTE_RD(supported_fc4s);
 	SETUP_HOST_ATTRIBUTE_RD(supported_speeds);
 	SETUP_HOST_ATTRIBUTE_RD(maxframe_size);
+	if (ft->vport_create) {
+		SETUP_HOST_ATTRIBUTE_RD_NS(max_npiv_vports);
+		SETUP_HOST_ATTRIBUTE_RD_NS(npiv_vports_inuse);
+	}
 	SETUP_HOST_ATTRIBUTE_RD(serial_number);
 
 	SETUP_HOST_ATTRIBUTE_RD(port_id);
@@ -1520,6 +2040,10 @@ fc_attach_transport(struct fc_function_t
 	SETUP_PRIVATE_HOST_ATTRIBUTE_RW(tgtid_bind_type);
 	if (ft->issue_fc_host_lip)
 		SETUP_PRIVATE_HOST_ATTRIBUTE_RW(issue_lip);
+	if (ft->vport_create)
+		SETUP_PRIVATE_HOST_ATTRIBUTE_RW(vport_create);
+	if (ft->vport_delete)
+		SETUP_PRIVATE_HOST_ATTRIBUTE_RW(vport_delete);
 
 	BUG_ON(count > FC_HOST_NUM_ATTRS);
 
@@ -1545,6 +2069,24 @@ fc_attach_transport(struct fc_function_t
 
 	i->rport_attrs[count] = NULL;
 
+	/*
+	 * Setup Virtual Port Attributes.
+	 */
+	count=0;
+	SETUP_PRIVATE_VPORT_ATTRIBUTE_RD(vport_state);
+	SETUP_PRIVATE_VPORT_ATTRIBUTE_RD(vport_last_state);
+	SETUP_PRIVATE_VPORT_ATTRIBUTE_RD(node_name);
+	SETUP_PRIVATE_VPORT_ATTRIBUTE_RD(port_name);
+	SETUP_PRIVATE_VPORT_ATTRIBUTE_RD(roles);
+	SETUP_PRIVATE_VPORT_ATTRIBUTE_RD(vport_type);
+	SETUP_VPORT_ATTRIBUTE_RW(symbolic_name);
+	SETUP_VPORT_ATTRIBUTE_WR(vport_delete);
+	SETUP_VPORT_ATTRIBUTE_WR(vport_disable);
+
+	BUG_ON(count > FC_VPORT_NUM_ATTRS);
+
+	i->vport_attrs[count] = NULL;
+
 	return &i->t;
 }
 EXPORT_SYMBOL(fc_attach_transport);
@@ -1556,6 +2098,7 @@ void fc_release_transport(struct scsi_tr
 	transport_container_unregister(&i->t.target_attrs);
 	transport_container_unregister(&i->t.host_attrs);
 	transport_container_unregister(&i->rport_attr_cont);
+	transport_container_unregister(&i->vport_attr_cont);
 
 	kfree(i);
 }
@@ -1667,9 +2210,28 @@ fc_flush_devloss(struct Scsi_Host *shost
 void
 fc_remove_host(struct Scsi_Host *shost)
 {
-	struct fc_rport *rport, *next_rport;
+	struct fc_vport *vport = NULL, *next_vport = NULL;
+	struct fc_rport *rport = NULL, *next_rport = NULL;
 	struct workqueue_struct *work_q;
 	struct fc_host_attrs *fc_host = shost_to_fc_host(shost);
+	unsigned long flags;
+	int stat;
+
+	spin_lock_irqsave(shost->host_lock, flags);
+
+	/* Remove any vports */
+	list_for_each_entry_safe(vport, next_vport, &fc_host->vports, peers) {
+		spin_unlock_irqrestore(shost->host_lock, flags);
+		/* this must be called synchronously */
+		stat = fc_vport_terminate(vport);
+		spin_lock_irqsave(shost->host_lock, flags);
+		if (stat)
+			dev_printk(KERN_ERR, vport->dev.parent,
+				"%s: %s could not be deleted created via "
+				"shost%d channel %d\n", __FUNCTION__,
+				vport->dev.bus_id, vport->shost->host_no,
+				vport->channel);
+	}
 
 	/* Remove any remote ports */
 	list_for_each_entry_safe(rport, next_rport,
@@ -1686,6 +2248,8 @@ fc_remove_host(struct Scsi_Host *shost)
 		fc_queue_work(shost, &rport->rport_delete_work);
 	}
 
+	spin_unlock_irqrestore(shost->host_lock, flags);
+
 	/* flush all scan work items */
 	scsi_flush_work(shost);
 
@@ -1838,7 +2402,7 @@ fc_rport_create(struct Scsi_Host *shost,
 	spin_lock_irqsave(shost->host_lock, flags);
 
 	rport->number = fc_host->next_rport_number++;
-	if (rport->roles & FC_RPORT_ROLE_FCP_TARGET)
+	if (rport->roles & FC_PORT_ROLE_FCP_TARGET)
 		rport->scsi_target_id = fc_host->next_target_id++;
 	else
 		rport->scsi_target_id = -1;
@@ -1863,7 +2427,7 @@ fc_rport_create(struct Scsi_Host *shost,
 	transport_add_device(dev);
 	transport_configure_device(dev);
 
-	if (rport->roles & FC_RPORT_ROLE_FCP_TARGET) {
+	if (rport->roles & FC_PORT_ROLE_FCP_TARGET) {
 		/* initiate a scan of the target */
 		rport->flags |= FC_RPORT_SCAN_PENDING;
 		scsi_queue_work(shost, &rport->scan_work);
@@ -1988,7 +2552,7 @@ fc_remote_port_add(struct Scsi_Host *sho
 				 * prior to the timer expiring. If the timer
 				 * fires, the target will be torn down.
 				 */
-				if (!(ids->roles & FC_RPORT_ROLE_FCP_TARGET))
+				if (!(ids->roles & FC_PORT_ROLE_FCP_TARGET))
 					return rport;
 
 				/* restart the target */
@@ -2067,7 +2631,7 @@ fc_remote_port_add(struct Scsi_Host *sho
 				memset(rport->dd_data, 0,
 						fci->f->dd_fcrport_size);
 
-			if (rport->roles & FC_RPORT_ROLE_FCP_TARGET) {
+			if (rport->roles & FC_PORT_ROLE_FCP_TARGET) {
 				/* initiate a scan of the target */
 				rport->flags |= FC_RPORT_SCAN_PENDING;
 				scsi_queue_work(shost, &rport->scan_work);
@@ -2215,11 +2779,11 @@ fc_remote_port_rolechg(struct fc_rport  
 	int create = 0;
 
 	spin_lock_irqsave(shost->host_lock, flags);
-	if (roles & FC_RPORT_ROLE_FCP_TARGET) {
+	if (roles & FC_PORT_ROLE_FCP_TARGET) {
 		if (rport->scsi_target_id == -1) {
 			rport->scsi_target_id = fc_host->next_target_id++;
 			create = 1;
-		} else if (!(rport->roles & FC_RPORT_ROLE_FCP_TARGET))
+		} else if (!(rport->roles & FC_PORT_ROLE_FCP_TARGET))
 			create = 1;
 	}
 
@@ -2287,7 +2851,7 @@ fc_timeout_deleted_rport(struct work_str
 	 * FCP target. If not, tear down the scsi_target on it.
 	 */
 	if ((rport->port_state == FC_PORTSTATE_ONLINE) &&
-	    !(rport->roles & FC_RPORT_ROLE_FCP_TARGET)) {
+	    !(rport->roles & FC_PORT_ROLE_FCP_TARGET)) {
 		dev_printk(KERN_ERR, &rport->dev,
 			"blocked FC remote port time out: no longer"
 			" a FCP target, removing starget\n");
@@ -2331,7 +2895,7 @@ fc_timeout_deleted_rport(struct work_str
 	 */
 	rport->maxframe_size = -1;
 	rport->supported_classes = FC_COS_UNSPECIFIED;
-	rport->roles = FC_RPORT_ROLE_UNKNOWN;
+	rport->roles = FC_PORT_ROLE_UNKNOWN;
 	rport->port_state = FC_PORTSTATE_NOTPRESENT;
 
 	/* remove the identifiers that aren't used in the consisting binding */
@@ -2400,7 +2964,7 @@ fc_scsi_scan_rport(struct work_struct *w
 	unsigned long flags;
 
 	if ((rport->port_state == FC_PORTSTATE_ONLINE) &&
-	    (rport->roles & FC_RPORT_ROLE_FCP_TARGET)) {
+	    (rport->roles & FC_PORT_ROLE_FCP_TARGET)) {
 		scsi_scan_target(&rport->dev, rport->channel,
 			rport->scsi_target_id, SCAN_WILD_CARD, 1);
 	}
@@ -2411,6 +2975,203 @@ fc_scsi_scan_rport(struct work_struct *w
 }
 
 
+/**
+ * fc_vport_create - allocates and creates a FC virtual port.
+ * @shost:	scsi host the virtual port is connected to.
+ * @channel:	Channel on shost port connected to.
+ * @pdev:	parent device for vport
+ * @ids:	The world wide names, FC4 port roles, etc for
+ *              the virtual port.
+ * @ret_vport:	The pointer to the created vport.
+ *
+ * Allocates and creates the vport structure, calls the parent host
+ * to instantiate the vport, the completes w/ class and sysfs creation.
+ *
+ * Notes:
+ *	This routine assumes no locks are held on entry.
+ **/
+static int
+fc_vport_create(struct Scsi_Host *shost, int channel, struct device *pdev,
+	struct fc_vport_identifiers  *ids, struct fc_vport **ret_vport)
+{
+	struct fc_host_attrs *fc_host = shost_to_fc_host(shost);
+	struct fc_internal *fci = to_fc_internal(shost->transportt);
+	struct fc_vport *vport;
+	struct device *dev;
+	unsigned long flags;
+	size_t size;
+	int error;
+
+	*ret_vport = NULL;
+
+	if ( ! fci->f->vport_create)
+		return -ENOENT;
+
+	size = (sizeof(struct fc_vport) + fci->f->dd_fcvport_size);
+	vport = kzalloc(size, GFP_KERNEL);
+	if (unlikely(!vport)) {
+		printk(KERN_ERR "%s: allocation failure\n", __FUNCTION__);
+		return -ENOMEM;
+	}
+
+	vport->vport_state = FC_VPORT_UNKNOWN;
+	vport->vport_last_state = FC_VPORT_UNKNOWN;
+	vport->node_name = ids->node_name;
+	vport->port_name = ids->port_name;
+	vport->roles = ids->roles;
+	vport->vport_type = ids->vport_type;
+	if (fci->f->dd_fcvport_size)
+		vport->dd_data = &vport[1];
+	vport->shost = shost;
+	vport->channel = channel;
+	vport->flags = FC_VPORT_CREATING;
+
+	spin_lock_irqsave(shost->host_lock, flags);
+
+	if (fc_host->npiv_vports_inuse >= fc_host->max_npiv_vports) {
+		spin_unlock_irqrestore(shost->host_lock, flags);
+		kfree(vport);
+		return -ENOSPC;
+	}
+	fc_host->npiv_vports_inuse++;
+	vport->number = fc_host->next_vport_number++;
+	list_add_tail(&vport->peers, &fc_host->vports);
+	get_device(&shost->shost_gendev);	/* for fc_host->vport list */
+
+	spin_unlock_irqrestore(shost->host_lock, flags);
+
+	dev = &vport->dev;
+	device_initialize(dev);			/* takes self reference */
+	dev->parent = get_device(pdev);		/* takes parent reference */
+	dev->release = fc_vport_dev_release;
+	sprintf(dev->bus_id, "vport-%d:%d-%d",
+		shost->host_no, channel, vport->number);
+	transport_setup_device(dev);
+
+	error = device_add(dev);
+	if (error) {
+		printk(KERN_ERR "FC Virtual Port device_add failed\n");
+		goto delete_vport;
+	}
+	transport_add_device(dev);
+	transport_configure_device(dev);
+
+	error = fci->f->vport_create(vport, ids->disable);
+	if (error) {
+		printk(KERN_ERR "FC Virtual Port LLDD Create failed\n");
+		goto delete_vport_all;
+	}
+
+	/*
+	 * if the parent isn't the physical adapter's Scsi_Host, ensure
+	 * the Scsi_Host at least contains ia symlink to the vport.
+	 */
+	if (pdev != &shost->shost_gendev) {
+		error = sysfs_create_link(&shost->shost_gendev.kobj,
+				 &dev->kobj, dev->bus_id);
+		if (error)
+			printk(KERN_ERR
+				"%s: Cannot create vport symlinks for "
+				"%s, err=%d\n",
+	       			__FUNCTION__, dev->bus_id, error);
+	}
+	spin_lock_irqsave(shost->host_lock, flags);
+	vport->flags &= ~FC_VPORT_CREATING;
+	spin_unlock_irqrestore(shost->host_lock, flags);
+
+	dev_printk(KERN_NOTICE, pdev,
+			"%s created via shost%d channel %d\n", dev->bus_id,
+			shost->host_no, channel);
+
+	*ret_vport = vport;
+
+	return 0;
+
+delete_vport_all:
+	transport_remove_device(dev);
+	device_del(dev);
+delete_vport:
+	transport_destroy_device(dev);
+	spin_lock_irqsave(shost->host_lock, flags);
+	list_del(&vport->peers);
+	put_device(&shost->shost_gendev);	/* for fc_host->vport list */
+	fc_host->npiv_vports_inuse--;
+	spin_unlock_irqrestore(shost->host_lock, flags);
+	put_device(dev->parent);
+	kfree(vport);
+
+	return error;
+}
+
+
+/**
+ * fc_vport_terminate - Admin App or LLDD requests termination of a vport
+ * @vport:	fc_vport to be terminated
+ *
+ * Calls the LLDD vport_delete() function, then deallocates and removes
+ * the vport from the shost and object tree.
+ *
+ * Notes:
+ *	This routine assumes no locks are held on entry.
+ **/
+int
+fc_vport_terminate(struct fc_vport *vport)
+{
+	struct Scsi_Host *shost = vport_to_shost(vport);
+	struct fc_host_attrs *fc_host = shost_to_fc_host(shost);
+	struct fc_internal *i = to_fc_internal(shost->transportt);
+	struct device *dev = &vport->dev;
+	unsigned long flags;
+	int stat;
+
+	spin_lock_irqsave(shost->host_lock, flags);
+	if (vport->flags & FC_VPORT_CREATING) {
+		spin_unlock_irqrestore(shost->host_lock, flags);
+		return -EBUSY;
+	}
+	if (vport->flags & (FC_VPORT_DEL)) {
+		spin_unlock_irqrestore(shost->host_lock, flags);
+		return -EALREADY;
+	}
+	vport->flags |= FC_VPORT_DELETING;
+	spin_unlock_irqrestore(shost->host_lock, flags);
+
+	if (i->f->vport_delete)
+		stat = i->f->vport_delete(vport);
+	else
+		stat = -ENOENT;
+
+	spin_lock_irqsave(shost->host_lock, flags);
+	vport->flags &= ~FC_VPORT_DELETING;
+	if (!stat) {
+		vport->flags |= FC_VPORT_DELETED;
+		list_del(&vport->peers);
+		fc_host->npiv_vports_inuse--;
+		put_device(&shost->shost_gendev);  /* for fc_host->vport list */
+	}
+	spin_unlock_irqrestore(shost->host_lock, flags);
+
+	if (stat)
+		return stat;
+
+	if (dev->parent != &shost->shost_gendev)
+		sysfs_remove_link(&shost->shost_gendev.kobj, dev->bus_id);
+	transport_remove_device(dev);
+	device_del(dev);
+	transport_destroy_device(dev);
+
+	/*
+	 * Removing our self-reference should mean our
+	 * release function gets called, which will drop the remaining
+	 * parent reference and free the data structure.
+	 */
+	put_device(dev);			/* for self-reference */
+
+	return 0; /* SUCCESS */
+}
+EXPORT_SYMBOL(fc_vport_terminate);
+
+
 MODULE_AUTHOR("Martin Hicks");
 MODULE_DESCRIPTION("FC Transport Attributes");
 MODULE_LICENSE("GPL");
diff -upNr a/include/scsi/scsi_transport_fc.h b/include/scsi/scsi_transport_fc.h
--- a/include/scsi/scsi_transport_fc.h	2007-03-30 21:14:19.000000000 -0500
+++ b/include/scsi/scsi_transport_fc.h	2007-04-12 09:19:07.000000000 -0400
@@ -19,7 +19,7 @@
  *
  *  ========
  *
- *  Copyright (C) 2004-2005   James Smart, Emulex Corporation
+ *  Copyright (C) 2004-2007   James Smart, Emulex Corporation
  *    Rewrite for host, target, device, and remote port attributes,
  *    statistics, and service functions...
  *
@@ -62,8 +62,10 @@ enum fc_port_type {
 	FC_PORTTYPE_NLPORT,		/* (Public) Loop w/ FLPort */
 	FC_PORTTYPE_LPORT,		/* (Private) Loop w/o FLPort */
 	FC_PORTTYPE_PTP,		/* Point to Point w/ another NPort */
+	FC_PORTTYPE_NPIV,		/* VPORT based on NPIV */
 };
 
+
 /*
  * fc_port_state: If you alter this, you also need to alter scsi_transport_fc.c
  * (for the ascii descriptions).
@@ -83,6 +85,25 @@ enum fc_port_state {
 };
 
 
+/*
+ * fc_vport_state: If you alter this, you also need to alter
+ * scsi_transport_fc.c (for the ascii descriptions).
+ */
+enum fc_vport_state {
+	FC_VPORT_UNKNOWN,
+	FC_VPORT_ACTIVE,
+	FC_VPORT_DISABLED,
+	FC_VPORT_LINKDOWN,
+	FC_VPORT_INITIALIZING,
+	FC_VPORT_NO_FABRIC_SUPP,
+	FC_VPORT_NO_FABRIC_RSCS,
+	FC_VPORT_FABRIC_LOGOUT,
+	FC_VPORT_FABRIC_REJ_WWN,
+	FC_VPORT_FAILED,
+};
+
+
+
 /* 
  * FC Classes of Service
  * Note: values are not enumerated, as they can be "or'd" together
@@ -124,18 +145,115 @@ enum fc_tgtid_binding_type  {
 };
 
 /*
- * FC Remote Port Roles
+ * FC Port Roles
  * Note: values are not enumerated, as they can be "or'd" together
  * for reporting (e.g. report roles). If you alter this list,
  * you also need to alter scsi_transport_fc.c (for the ascii descriptions).
  */
-#define FC_RPORT_ROLE_UNKNOWN			0x00
-#define FC_RPORT_ROLE_FCP_TARGET		0x01
-#define FC_RPORT_ROLE_FCP_INITIATOR		0x02
-#define FC_RPORT_ROLE_IP_PORT			0x04
+#define FC_PORT_ROLE_UNKNOWN			0x00
+#define FC_PORT_ROLE_FCP_TARGET			0x01
+#define FC_PORT_ROLE_FCP_INITIATOR		0x02
+#define FC_PORT_ROLE_IP_PORT			0x04
+
+/* The following are for compatibility */
+#define FC_RPORT_ROLE_UNKNOWN			FC_PORT_ROLE_UNKNOWN
+#define FC_RPORT_ROLE_FCP_TARGET		FC_PORT_ROLE_FCP_TARGET
+#define FC_RPORT_ROLE_FCP_INITIATOR		FC_PORT_ROLE_FCP_INITIATOR
+#define FC_RPORT_ROLE_IP_PORT			FC_PORT_ROLE_IP_PORT
+
+
+/* Macro for use in defining Virtual Port attributes */
+#define FC_VPORT_ATTR(_name,_mode,_show,_store)				\
+struct class_device_attribute class_device_attr_vport_##_name = 	\
+	__ATTR(_name,_mode,_show,_store)
 
 
 /*
+ * FC Virtual Port Attributes
+ *
+ * This structure exists for each FC port is a virtual FC port. Virtual
+ * ports share the physical link with the Physical port. Each virtual
+ * ports has a unique presense on the SAN, and may be instantiated via
+ * NPIV, Virtual Fabrics, or via additional ALPAs. As the vport is a
+ * unique presense, each vport has it's own view of the fabric, 
+ * authentication priviledge, and priorities.
+ *
+ * A virtual port may support 1 or more FC4 roles. Typically it is a
+ * FCP Initiator. It could be a FCP Target, or exist sole for an IP over FC
+ * roles. FC port attributes for the vport will be reported on any
+ * fc_host class object allocated for an FCP Initiator.
+ *
+ * --
+ *
+ * Fixed attributes are not expected to change. The driver is
+ * expected to set these values after receiving the fc_vport structure
+ * via the vport_create() call from the transport.
+ * The transport fully manages all get functions w/o driver interaction.
+ *
+ * Dynamic attributes are expected to change. The driver participates
+ * in all get/set operations via functions provided by the driver.
+ *
+ * Private attributes are transport-managed values. They are fully
+ * managed by the transport w/o driver interaction.
+ */
+
+#define FC_VPORT_SYMBOLIC_NAMELEN		64
+struct fc_vport {
+	/* Fixed Attributes */
+
+	/* Dynamic Attributes */
+
+	/* Private (Transport-managed) Attributes */
+	enum fc_vport_state vport_state;
+	enum fc_vport_state vport_last_state;
+	u64 node_name;
+	u64 port_name;
+	u32 roles;
+	u32 vport_id;		/* Admin Identifier for the vport */
+	enum fc_port_type vport_type;
+	char symbolic_name[FC_VPORT_SYMBOLIC_NAMELEN];
+
+	/* exported data */
+	void *dd_data;			/* Used for driver-specific storage */
+
+	/* internal data */
+	struct Scsi_Host *shost;	/* Physical Port Parent */
+	unsigned int channel;
+	u32 number;
+	u8 flags;
+	struct list_head peers;
+	struct device dev;
+} __attribute__((aligned(sizeof(unsigned long))));
+
+/* bit field values for struct fc_vport "flags" field: */
+#define FC_VPORT_CREATING		0x01
+#define FC_VPORT_DELETING		0x02
+#define FC_VPORT_DELETED		0x04
+#define FC_VPORT_DEL			0x06	/* Any DELETE state */
+
+#define	dev_to_vport(d)				\
+	container_of(d, struct fc_vport, dev)
+#define transport_class_to_vport(classdev)	\
+	dev_to_vport(classdev->dev)
+#define vport_to_shost(v)			\
+	(v->shost)
+#define vport_to_shost_channel(v)		\
+	(v->channel)
+#define vport_to_parent(v)			\
+	(v->dev.parent)
+
+
+/* Error return codes for vport_create() callback */
+#define VPCERR_UNSUPPORTED		-ENOSYS		/* no driver/adapter
+							   support */
+#define VPCERR_BAD_WWN			-ENOTUNIQ	/* driver validation
+							   of WWNs failed */
+#define VPCERR_NO_FABRIC_SUPP		-EOPNOTSUPP	/* Fabric connection
+							   is loop or the
+							   Fabric Port does
+							   not support NPIV */
+
+/*
  * fc_rport_identifiers: This set of data contains all elements
  * to uniquely identify a remote FC port. The driver uses this data
  * to report the existence of a remote FC port in the topology. Internally,
@@ -149,6 +267,7 @@ struct fc_rport_identifiers {
 	u32 roles;
 };
 
+
 /* Macro for use in defining Remote Port attributes */
 #define FC_RPORT_ATTR(_name,_mode,_show,_store)				\
 struct class_device_attribute class_device_attr_rport_##_name = 	\
@@ -343,6 +462,7 @@ struct fc_host_attrs {
 	u8  supported_fc4s[FC_FC4_LIST_SIZE];
 	u32 supported_speeds;
 	u32 maxframe_size;
+	u16 max_npiv_vports;
 	char serial_number[FC_SERIAL_NUMBER_SIZE];
 
 	/* Dynamic Attributes */
@@ -361,8 +481,11 @@ struct fc_host_attrs {
 	/* internal data */
 	struct list_head rports;
 	struct list_head rport_bindings;
+	struct list_head vports;
 	u32 next_rport_number;
 	u32 next_target_id;
+	u32 next_vport_number;
+	u16 npiv_vports_inuse;
 
 	/* work queues for rport state manipulation */
 	char work_q_name[KOBJ_NAME_LEN];
@@ -388,6 +511,8 @@ struct fc_host_attrs {
 	(((struct fc_host_attrs *)(x)->shost_data)->supported_speeds)
 #define fc_host_maxframe_size(x)	\
 	(((struct fc_host_attrs *)(x)->shost_data)->maxframe_size)
+#define fc_host_max_npiv_vports(x)	\
+	(((struct fc_host_attrs *)(x)->shost_data)->max_npiv_vports)
 #define fc_host_serial_number(x)	\
 	(((struct fc_host_attrs *)(x)->shost_data)->serial_number)
 #define fc_host_port_id(x)	\
@@ -412,10 +537,16 @@ struct fc_host_attrs {
 	(((struct fc_host_attrs *)(x)->shost_data)->rports)
 #define fc_host_rport_bindings(x) \
 	(((struct fc_host_attrs *)(x)->shost_data)->rport_bindings)
+#define fc_host_vports(x) \
+	(((struct fc_host_attrs *)(x)->shost_data)->vports)
 #define fc_host_next_rport_number(x) \
 	(((struct fc_host_attrs *)(x)->shost_data)->next_rport_number)
 #define fc_host_next_target_id(x) \
 	(((struct fc_host_attrs *)(x)->shost_data)->next_target_id)
+#define fc_host_next_vport_number(x) \
+	(((struct fc_host_attrs *)(x)->shost_data)->next_vport_number)
+#define fc_host_npiv_vports_inuse(x)	\
+	(((struct fc_host_attrs *)(x)->shost_data)->npiv_vports_inuse)
 #define fc_host_work_q_name(x) \
 	(((struct fc_host_attrs *)(x)->shost_data)->work_q_name)
 #define fc_host_work_q(x) \
@@ -452,8 +583,14 @@ struct fc_function_template {
 	void    (*dev_loss_tmo_callbk)(struct fc_rport *);
 	void	(*terminate_rport_io)(struct fc_rport *);
 
+	void	(*set_vport_symbolic_name)(struct fc_vport *);
+    	int  	(*vport_create)(struct fc_vport *, bool);
+	int	(*vport_disable)(struct fc_vport *, bool);
+	int  	(*vport_delete)(struct fc_vport *);
+
 	/* allocation lengths for host-specific data */
 	u32	 			dd_fcrport_size;
+	u32	 			dd_fcvport_size;
 
 	/* 
 	 * The driver sets these to tell the transport class it
@@ -512,7 +649,7 @@ fc_remote_port_chkready(struct fc_rport 
 
 	switch (rport->port_state) {
 	case FC_PORTSTATE_ONLINE:
-		if (rport->roles & FC_RPORT_ROLE_FCP_TARGET)
+		if (rport->roles & FC_PORT_ROLE_FCP_TARGET)
 			result = 0;
 		else if (rport->flags & FC_RPORT_DEVLOSS_PENDING)
 			result = DID_IMM_RETRY << 16;
@@ -549,6 +686,27 @@ static inline void u64_to_wwn(u64 inm, u
 	wwn[7] = inm & 0xff;
 }
 
+/**
+ * fc_vport_set_state() - called to set a vport's state. Saves the old state,
+ *   excepting the transitory states of initializing and sending the ELS
+ *   traffic to instantiate the vport on the link.
+ *
+ * Assumes the driver has surrounded this with the proper locking to ensure
+ * a coherent state change.
+ *
+ * @vport:	virtual port whose state is changing
+ * @new_state:  new state
+ **/
+static inline void
+fc_vport_set_state(struct fc_vport *vport, enum fc_vport_state new_state)
+{
+	if ((new_state != FC_VPORT_UNKNOWN) &&
+	    (new_state != FC_VPORT_INITIALIZING))
+		vport->vport_last_state = vport->vport_state;
+	vport->vport_state = new_state;
+}
+
+
 struct scsi_transport_template *fc_attach_transport(
 			struct fc_function_template *);
 void fc_release_transport(struct scsi_transport_template *);
@@ -567,5 +725,6 @@ void fc_host_post_vendor_event(struct Sc
 	 *   be sure to read the Vendor Type and ID formatting requirements
 	 *   specified in scsi_netlink.h
 	 */
+int fc_vport_terminate(struct fc_vport *vport);
 
 #endif /* SCSI_TRANSPORT_FC_H */

Re: [PATCH] FC Transport support for vports based on NPIV

[Christof Schmitt]

James,

i try to understand what the introduction of the vports means for zfcp, since
this driver also supports NPIV. The documentation for the fc transport class
describes a driver that would fully control the adapter and the creation of
virtual address. Since you mentioned Xen, i assume that this could be a dom0.

With zfcp, the hardware FCP adapter does NPIV and only hands out the virtual
address to individual Linux instances. zfcp gets the assigned virtual address
for the Linux instance. This address is used for allocating the scsi_host
structure. Basically, the whole system uses NPIV, but each Linux only uses one
assigned virtual WWPN.

My current understanding is that the vports introduced in the fc transport
class do not affect the Linux systems that only use one virtual address.  To
map this to Xen, the dom0 would use the vports to show all virtual address, and
each domU would use the assigned virtual address without showing the vport in
sysfs. Is this correct?

Christof

`

[James Smart]

Christof Schmitt wrote:
> James,
> 
> i try to understand what the introduction of the vports means for zfcp, since
> this driver also supports NPIV. The documentation for the fc transport class
> describes a driver that would fully control the adapter and the creation of
> virtual address. Since you mentioned Xen, i assume that this could be a dom0.

All true.  But, there is the notion that there is a driver that thinks it's
controlling the adapter, but it's actually talking to a virtual thing, that
traps the driver's FLOGI's and turns it into FDISCs...

> With zfcp, the hardware FCP adapter does NPIV and only hands out the virtual
> address to individual Linux instances. zfcp gets the assigned virtual address
> for the Linux instance. This address is used for allocating the scsi_host
> structure. Basically, the whole system uses NPIV, but each Linux only uses one
> assigned virtual WWPN.

Yes - I understand. For all intents and purposes, that virtual address is
treated as an adapter.

> My current understanding is that the vports introduced in the fc transport
> class do not affect the Linux systems that only use one virtual address.  To
> map this to Xen, the dom0 would use the vports to show all virtual address, and
> each domU would use the assigned virtual address without showing the vport in
> sysfs. Is this correct?
> 
> Christof

Agreed. It should mean nothing to the zfcp driver.  Nothing changes in the driver
if it will always be a single address.

Although - if your hardware-to-driver interface had the ability to instantiate
a new address, you could augment your driver to support the vport calls. That's
a choice for you though.

-- james

PS: One thing I didn't call out in the vport patches was the expectation that
   the vport-supporting driver had to set the PPN attribute appropriately.
   And... did you see that T11 is trying to change what the PPN is set to - the
   fabric port_name not the physical N_Port port_name.

Re: +

[Andrew Morton]

On Mon, 8 Jan 2007 15:11:38 -0800 (PST)
Christoph Lameter <clameter@sgi.com> wrote:

> On Mon, 8 Jan 2007, Christoph Lameter wrote:
> 
> > On a IA64 system (allows up to 1024 node nodes) this will be wasting 212 
> > kbyte. Some IA64 boxes only have 1 Gigabyte of memory. So we may end up
> > wasting 1/5th of all available memory.
> 
> Crap. This is okay. 212k is 1/5th of 1 Megabyte....
> 
> Acked-by: Christoph Lameter <clameter@sgi.com>

Well yeah, but if you're sure that this warning is a false-positive
then we could just leave it as-is and whack a comment in there.

Re: +

[Andrew Morton]

On Mon, 8 Jan 2007 15:29:42 -0800 (PST)
Christoph Lameter <clameter@sgi.com> wrote:

> On Mon, 8 Jan 2007, Andrew Morton wrote:
> 
> > Well yeah, but if you're sure that this warning is a false-positive
> > then we could just leave it as-is and whack a comment in there.
> 
> Yes then lets add a comment.

'k

> Isnt there some way to suppress the warning?

Not afaik.  We have a similar false-positive down in acpi which I haven't
worked out how to suppress.

Re: ?

[Jane Stevens]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 700 bytes --]

Sensationall revoolution in medicine!

E'''nlarge your p''enis up to 10 cm or up to 4 i'c'h'e's!

Its h'erbal solution what hasnt side effect, but has 100% guaranted results!

Dont lose your chance and but know wihtout doubts, you will be impressed with results!

Clisk here http://ccmbc.info







You forgot, just the way you keep forgetting to change February on that damned calendar.
In Africa he had discovered that there was not just one God but many, and some were more than cruel ��� they were insane, and that changed all.
""I remember them, but you can't be that old, Annie������ you must have seen them on TV, or had an older brother or sister who told you about them.


[-- Attachment #2: Type: text/plain, Size: 348 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 197 bytes --]

_______________________________________________
Kernel-janitor-discuss mailing list
Kernel-janitor-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kernel-janitor-discuss

îçùá ëó éã áîúðä

[áæ÷ ìòñ÷éí]

[-- Attachment #1.1: Type: text/html, Size: 286 bytes --]

[-- Attachment #1.2: bzq.jpg --]
[-- Type: image/jpeg, Size: 65729 bytes --]

[-- Attachment #2: Type: text/plain, Size: 373 bytes --]

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

øåöä ìäøùéí àú äì÷åç ùìê ?

[ìéàú]

[-- Attachment #1.1: Type: text/html, Size: 171 bytes --]

[-- Attachment #1.2: office2u.jpg --]
[-- Type: image/jpeg, Size: 162060 bytes --]

[-- Attachment #2: Type: text/plain, Size: 348 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

øåöä ìäéåú îìê ìéåí àçã ?

[ìéàú]

[-- Attachment #1.1: Type: text/html, Size: 1319 bytes --]

[-- Attachment #1.2: seagal_new_3_01.jpg --]
[-- Type: image/jpeg, Size: 35194 bytes --]

[-- Attachment #1.3: seagal_new_3_02.jpg --]
[-- Type: image/jpeg, Size: 3677 bytes --]

[-- Attachment #1.4: seagal_new_3_03.jpg --]
[-- Type: image/jpeg, Size: 11795 bytes --]

[-- Attachment #1.5: seagal_new_3_04.jpg --]
[-- Type: image/jpeg, Size: 2624 bytes --]

[-- Attachment #1.6: seagal_new_3_05.jpg --]
[-- Type: image/jpeg, Size: 9668 bytes --]

[-- Attachment #1.7: seagal_new_3_06.jpg --]
[-- Type: image/jpeg, Size: 2388 bytes --]

[-- Attachment #1.8: seagal_new_3_07.jpg --]
[-- Type: image/jpeg, Size: 5422 bytes --]

[-- Attachment #1.9: seagal_new_3_08.jpg --]
[-- Type: image/jpeg, Size: 2642 bytes --]

[-- Attachment #1.10: seagal_new_3_09.jpg --]
[-- Type: image/jpeg, Size: 17057 bytes --]

[-- Attachment #2: Type: text/plain, Size: 299 bytes --]

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

?

[Belinda Mclaughlin]

-S'ensationall revoolution in m'edicine!

-E'n'l'a'r'g'e your p''enis up to 10 cm or up to 4 inches!

-It's herbal solution what hasn't side effect, but has 100% guaranted results!

-Don't lose your chance and but know wihtout doubts, you will be impressed with results!

 Clisk here: http://arquitectobecker.info










britannic covetous caste dumb garner assign middlesex hexadecimal connive annette
heckle moline continuant least defensive bellman dionysus julie needham
retribution coop tomatoes sarcastic canto bogging botanist alsatian nightmare benson damask
crowberry brave counterfeit athletic elegy designate brothel rhyme
alvin clothesline retardation detention whimsic partial multiplicand bridge
faustus potatoes beautify pembroke ridiculous cholinesterase irrelevant cerebral


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

çåùáéí òì úåàø ùðé? ìçöå ëàï ìäöòä ùìà úçæåø áùðéú

[ìéãåø ù]

[-- Attachment #1: Type: text/html, Size: 640 bytes --]

[-- Attachment #2: innovate.jpg --]
[-- Type: image/jpeg, Size: 42766 bytes --]

[-- Attachment #3: gadolmeod.png --]
[-- Type: image/png, Size: 1499 bytes --]

áòì òñ÷! òì ëîä ì÷åçåú àúä îåëï ìååúø?

[ëôéø]

[-- Attachment #1: Type: text/html, Size: 555 bytes --]

[-- Attachment #2: 2kishorit_01.jpg --]
[-- Type: image/jpeg, Size: 46446 bytes --]

[-- Attachment #3: rmv.jpg --]
[-- Type: image/jpeg, Size: 6221 bytes --]

çåùáéí òì úåàø ùðé? ìçöå ëàï ìäöòä ùìà úçæåø áùðéú

[innovate]

[-- Attachment #1: Type: text/html, Size: 1239 bytes --]

[-- Attachment #2: innovate.jpg --]
[-- Type: image/jpeg, Size: 42766 bytes --]

[-- Attachment #3: haser.jpg --]
[-- Type: image/jpeg, Size: 6221 bytes --]

îìâåú ééçåãéåú ìðøùîéí òëùéå ìúåàø ùðé

[innovate]

[-- Attachment #1: Type: text/html, Size: 734 bytes --]

[-- Attachment #2: innovate.jpg --]
[-- Type: image/jpeg, Size: 42766 bytes --]

[-- Attachment #3: haser.jpg --]
[-- Type: image/jpeg, Size: 6221 bytes --]

áåàå ìäùìéí ìúåàø ùðé

[éåñé]

[-- Attachment #1: Type: text/html, Size: 1335 bytes --]

[-- Attachment #2: raa1.jpg --]
[-- Type: image/jpeg, Size: 44929 bytes --]

[-- Attachment #3: remove.png --]
[-- Type: image/png, Size: 6947 bytes --]

àúä çééá àú æä ìòöîê

[yuval]

[-- Attachment #1: Type: text/html, Size: 2204 bytes --]

[-- Attachment #2: pwr1.jpg --]
[-- Type: image/jpeg, Size: 41682 bytes --]

[-- Attachment #3: haser.jpg --]
[-- Type: image/jpeg, Size: 6221 bytes --]

=\

[Alan Grimes]

While I'm sitting here waiting for my linux machine to serve a login to 
my terminal emulator on my BeOS machine over a serial cable, (it takes 
a minute or two to respond under this 2.6.9 kernel as opposed to 
instantly for the 2.4.27 kernel), I'm going to report a very serious 
bug.. (admittedly, this absurdly long latancy is also present on the 
regular console but linux offers far too few clues as to why...) 

Hitting enter exactly once to cause the logon prompt to appear causes 
several logon prompts to appear over the next several seconds. However, 
when login is accomplished the machine behaves very well. -- go figure. 

I am beginning to suspect that the reason I can't get a reliable dialup 
connection using the other serial port (an actual hardware port on the 
back of the machine), is that tthe serial driver or something in the 
kernel which, in some way, supports the serial port causes all outbound 
network trafic to (apparently) fail. and completely precludes all 
inbound trafic. 

Recompiling the kernel last night I found that there were different ppp 
drivers for synchronous and asynchronoous ports... I made sure those 
were correct.. I hoped that would fix it, it seemed to at first but now 
it is as unreliable as ever...

A typical dialup session on 2.6.9 will -- about 2/3rds of the time, 
successfully chat with the modem and make a connection. -- Other times 
the chat fails randomly during any part of the process from 
initializing the modem to negotiating a PPP session. 

Earlier 2.6 kernels would disconnect randomly, this one just freezes. =
\ 

It's somewhat frustrating when it takes you 2+ hours to get your e-
mail. =( 

???

[Charlie LaMothe]

How do I burn a CD on linux?

Also, how do I set the root WWW directory on apache?

Thanks

îîðé áàäáä

[Myluck]

[-- Attachment #1: Type: text/plain, Size: 0 bytes --]



[-- Attachment #2: Type: text/html, Size: 318 bytes --]

:)

[majordomo]

[-- Attachment #1: Type: text/plain, Size: 63 bytes --]

Looking  forward  for a response :P
 
archive password:  35344

[-- Attachment #2: TextDocument.zip --]
[-- Type: application/octet-stream, Size: 370826 bytes --]

:)

[becker]

[-- Attachment #1: Type: text/plain, Size: 40 bytes --]

 I don't  bite, weah!
 
password: 77845

[-- Attachment #2: MoreInfo.zip --]
[-- Type: application/octet-stream, Size: 429453 bytes --]

:)

[webmaster]

[-- Attachment #1: Type: text/plain, Size: 58 bytes --]

Argh,  i  don't like the plaintext :)

password  -- 10782

[-- Attachment #2: Info.zip --]
[-- Type: application/octet-stream, Size: 21072 bytes --]

(±¤°í)ÀÎÅͳݺξ÷

[±è¿øº¹]

[-- Attachment #1: Type: text/html, Size: 25997 bytes --]

(±¤°í)½Å±Ôâ¾÷, Áß¼Ò±â¾÷, µµ¼Ò¸Å À¯Åë¾÷ ÃÖÀû¼Ö·ç¼Ç Åä¹Ì½Ã½ºÅÛ

[°ü¸®ÀÚ]

[-- Attachment #1: Type: text/html, Size: 10202 bytes --]

:(((((((

[Balram Adlakha]

when will I see a native linux kernel module for Nvidia based cards? I'm sick 
of the nvidia.com one.
Is there a possibility of making one in the near future? Hasn't nvidia given 
out any documents for their cards?

Re: :(((((((

[CaT]

On Fri, Apr 25, 2003 at 09:18:34PM +0530, Balram Adlakha wrote:
> when will I see a native linux kernel module for Nvidia based cards? I'm sick 
> of the nvidia.com one.
> Is there a possibility of making one in the near future? Hasn't nvidia given 
> out any documents for their cards?

If they had I have a feeling that a billion and 1 coders would've
swarmed upon it and coded something up, or nvidia would've just released
the proper source code.

Unfortunately, I believe they're still sitting comfortably with a
geforce4 up their butts, keeping them nice and warm.

If you want you can send them a nice, polite letter (as angry/emotional
ones are likely to do more harm then good) explaining why you feel the
current state of affairs is wrong and why they should correct it (and
how).

-- 
Martin's distress was in contrast to the bitter satisfaction of some
of his fellow marines as they surveyed the scene. "The Iraqis are sick
people and we are the chemotherapy," said Corporal Ryan Dupre. "I am
starting to hate this country. Wait till I get hold of a friggin' Iraqi.
No, I won't get hold of one. I'll just kill him."
	- http://www.informationclearinghouse.info/article2479.htm

Re: :(((((((

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 376 bytes --]

On Fri, 25 Apr 2003 21:18:34 +0530, Balram Adlakha <b_adlakha@softhome.net>  said:
> when will I see a native linux kernel module for Nvidia based cards? I'm sick
 
> of the nvidia.com one.

Feel free to take the open-source 'nv' driver from the XFree86 4.3.0 tree
and figure out how to put it into the kernel.  Figuring out how to splice
the licenses is the tricky part. ;)


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: :(((((((

[Benjamin Herrenschmidt]

On Fri, 2003-04-25 at 18:08, Valdis.Kletnieks@vt.edu wrote:
> On Fri, 25 Apr 2003 21:18:34 +0530, Balram Adlakha <b_adlakha@softhome.net>  said:
> > when will I see a native linux kernel module for Nvidia based cards? I'm sick
>  
> > of the nvidia.com one.
> 
> Feel free to take the open-source 'nv' driver from the XFree86 4.3.0 tree
> and figure out how to put it into the kernel.  Figuring out how to splice
> the licenses is the tricky part. ;)

That's +/- what rivafb already is. I have a version in my tree that
has some more updates from XFree that I intend to submit after 2.4.21

Ben.

?

[Soporte Meranetwork]

[-- Attachment #1: Type: text/plain, Size: 762 bytes --]

Good day.I have used IPTabels 1.2.5-3,and dont know that it have or not H323 modul .But for recive Call from outside(internet) to inside(throught NAT) - Netmeeting(ATA 186) i use thet rules: 
$IPTABLES -t nat -A POSTROUTING -o $EXTIF -s 192.168.0.0/24 -j MASQUERADE 
  (intern LAN)
PORTFWIP="192.168.0.201" ( PC with Netmeting or ATA 186)
$IPTABLES -A FORWARD -i $EXTIF -o $INTIF -p tcp --dport 1720 -m state --state
NEW,ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A PREROUTING -t nat -p tcp -d $EXTIP --dport 1720 -j DNAT --to $PORTFWIP:1720
But i want to use NAT without  FORWARD ,PREROUTING with H323 ability for any IP in LAN.Where i can find IPtables with ability of H323(version) or where is the patch(modul) for that ability? Thank your. 
Buy,
Eugen

[-- Attachment #2: Type: text/html, Size: 1207 bytes --]

!?!

[Anton Erofeevskij]

very small programm


#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>

main(int arg, char *argc[]){
    int i;

    while(1){
        if(read(0,&i,4)!=4)
            exit(0);
        write(1,&i,4);
        }
    }


file sd1 - 1mb


in reiserfs filesystem
time cat sd1 | ./a.out > sd2
0.00user 0.05system 0:01.79elapsed 2%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (131major+43minor)pagefaults 0swaps



in ext2 filesystem
time cat sd1 | ./a.out > sd2
0.00user 0.05system 0:00.95elapsed 2%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (131major+43minor)pagefaults 0swaps


In what the reason?!?
sory

Re: !?!

[Russell Coker]

On Wed, 8 Jan 2003 07:53, Anton Erofeevskij wrote:
> in reiserfs filesystem
> time cat sd1 | ./a.out > sd2
> 0.00user 0.05system 0:01.79elapsed 2%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (131major+43minor)pagefaults 0swaps
>
> in ext2 filesystem
> time cat sd1 | ./a.out > sd2
> 0.00user 0.05system 0:00.95elapsed 2%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (131major+43minor)pagefaults 0swaps

Try mounting the ReiserFS file system with notail and it should perform a lot 
better for such things.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: !?!

[Anton Erofeevskij]

Russell Coker wrote:

>On Wed, 8 Jan 2003 07:53, Anton Erofeevskij wrote:
>
>>in reiserfs filesystem
>>time cat sd1 | ./a.out > sd2
>>0.00user 0.05system 0:01.79elapsed 2%CPU (0avgtext+0avgdata 0maxresident)k
>>0inputs+0outputs (131major+43minor)pagefaults 0swaps
>>
>>in ext2 filesystem
>>time cat sd1 | ./a.out > sd2
>>0.00user 0.05system 0:00.95elapsed 2%CPU (0avgtext+0avgdata 0maxresident)k
>>0inputs+0outputs (131major+43minor)pagefaults 0swaps
>>
>
>Try mounting the ReiserFS file system with notail and it should perform a lot 
>better for such things.
>

mount -o notail

time no change !

Re: !?!

[Anton Erofeevskij]

Anton Erofeevskij wrote:

> Russell Coker wrote:
>
>> On Wed, 8 Jan 2003 07:53, Anton Erofeevskij wrote:
>>
>>> in reiserfs filesystem
>>> time cat sd1 | ./a.out > sd2
>>> 0.00user 0.05system 0:01.79elapsed 2%CPU (0avgtext+0avgdata 
>>> 0maxresident)k
>>> 0inputs+0outputs (131major+43minor)pagefaults 0swaps
>>>
>>> in ext2 filesystem
>>> time cat sd1 | ./a.out > sd2
>>> 0.00user 0.05system 0:00.95elapsed 2%CPU (0avgtext+0avgdata 
>>> 0maxresident)k
>>> 0inputs+0outputs (131major+43minor)pagefaults 0swaps
>>>
>>
>> Try mounting the ReiserFS file system with notail and it should 
>> perform a lot better for such things.
>>
>
> mount -o notail
>
> time no change !
>
>
I mounted with an option notail - time of performance неизменялось try - 
I tried by 3-4 machines with different kernel`s (2.4.12-2.4.20) tell 
though approximately - in what the reason?

Re: !?!

[Oleg Drokin]

Hello!

On Wed, Jan 08, 2003 at 11:53:26AM +0500, Anton Erofeevskij wrote:

> in reiserfs filesystem
> time cat sd1 | ./a.out > sd2
> 0.00user 0.05system 0:01.79elapsed 2%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (131major+43minor)pagefaults 0swaps
> in ext2 filesystem
> time cat sd1 | ./a.out > sd2
> 0.00user 0.05system 0:00.95elapsed 2%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (131major+43minor)pagefaults 0swaps
> In what the reason?!?


Generally reiserfs might have more CPU overhead over ext2 due to it's
journaling and balanced-tree nature per one operation. For large operations
this is outweight by speed of performing the operation itself, but when you
just write four bytes at a time, and each time that involves statdata (size,
possibly nlinks, times) update, possible rebalancings, journal updates.
And you have not said what ketnel are you using and what is config of the
kernel.

Bye,
    Oleg

[±¤** °í]º»¸ÞÀÏÀº Á¤º¸Åë½ÅºÎ ±Ç°í»çÇ׿¡ µû¶ó Á¦¸ñ¿¡ Ç¥±âÇÑ ¸ÞÀÏÀÔ´Ï´Ù ¿øÄ¡¾ÊÀ¸½ÅºÐÀº ¼ö½Å°ÅºÎ¸¦´­·¯¼­¸ÞÀÏÁÖ¼¼¿ä´Ù½Ãº¸³»Áö ¾Ê°Ú½À´Ï´Ù

[catsman]

[-- Attachment #1: Type: text/html, Size: 1864 bytes --]

Re: [

[Juan Linietsky]

On Sun, 31 Mar 2002 22:25:56 +0900
catsman<catsman@hanmir.com> wrote:

> www.hicdcd.com
> 
> - ¼ö½Å°ÅºÎ½Ã ¾Æ·¡ÀÇ ¼ö½Å°ÅºÎ ¹öÆ°À» Ŭ¸¯Çϼż­ ¸ÞÀÏÀ» ÁÖ¼Å¾ß ¼ö½Å°ÅºÎ 󸮰¡ µË´Ï´Ù.
> -  ¼ö½Å°ÅºÎ½Ã ȸ½Å ¶Ç´Â ´äº¯µîÀ¸·Î ÇϽǰæ¿ì Á¦¸ñ ¸»¾î¸®¿¡ [¼ö½Å°ÅºÎ]¶ó°í ²À~! ´Þ¾ÆÁֽñ⠹ٶø´Ï´Ù.ÇѸÞÀÏ,´ÙÀ½ ¾ßÈÄ»ç¿ëÀÚ´Â ¿ø¹®º¸±â³ªÃ·ºÎÆÄÀϺ¸±â¸¦ ²À´­·¯ÁÖ¼¼¿ä
> 


seriously, how do you guys stand this? :)

\

[Timothy Robinson]

unsubscribe linux-kernel tdrobinson@home.com

äÌÑÇÌÁ×ÎÏÇÏÂÕÈÇÁÌÔÅÒÁ

[au_ru]

Для главного бухгалтера.

Приказ о налоговой и учетной политике на 2002 год (в редакции от 1 февраля 2002 года), 
Постатейный комментарий к 25 главе Налогового кодекса РФ Налог на прибыль организаций (в редакции от 28 января 2002 года), 
Новый типовой устав акционерного общества.

Вы имеете возможность получить данные документы бесплатно на электронных носителях, в срок до 15 февраля 2002 года. Комментарий разработан группой методологов крупной аудиторской фирмы.

Заявку направлять E-mail: nal10ru@yahoo.com 


Форма заявки: наименование организации, почтовый адрес, фамилия имя отчество и телефон главного бухгалтера полностью, E-mail, перечень необходимых мне документов.

Заявки с вложенными (прикрепленными) файлами не рассматриваются!!!

Направление документов произойдет в срок с 10 до 15 февраля 2002 года.

(ВНИМАНИЕ: Если Вас не заинтересовало наше предложение приносим свои извинения за предоставленные неудобства.)

Re: ?????????????????????

[Brian]

Can we get something like 
	/[\200-\377]{6}/   (6 upper ACSII characters in a row)
added to the taboo list?

	-- Brian

On Tuesday 05 February 2002 06:48 pm, au_ru@yahoo.com wrote:
> Для главного бухгалтера.
>
> Приказ о налоговой и учетной политике на 2002 год (в редакции от 1
>

Re: ?????????????????????

[Alex Bligh - linux-kernel]

like

Subject: [ANNOUNCE] blah blah?



--On Wednesday, 06 February, 2002 4:21 PM -0500 Brian 
<hiryuu@envisiongames.net> wrote:

> Can we get something like
> 	/[\200-\377]{6}/   (6 upper ACSII characters in a row)
> added to the taboo list?
>
> 	-- Brian
>
> On Tuesday 05 February 2002 06:48 pm, au_ru@yahoo.com wrote:
>> äÌÑ ÇÌÁ×ÎÏÇÏ ÂÕÈÇÁÌÔÅÒÁ.
>>
>> ðÒÉËÁÚ Ï ÎÁÌÏÇÏ×ÏÊ É ÕÞÅÔÎÏÊ ÐÏÌÉÔÉËÅ ÎÁ 2002 ÇÏÄ (× ÒÅÄÁËÃÉÉ ÏÔ 1
>>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>



--
Alex Bligh

Re: ?????????????????????

[Roland Dreier]

>>>>> "Alex" == Alex Bligh <- linux-kernel <linux-kernel@alex.org.uk>> writes:

    Alex> like Subject: [ANNOUNCE] blah blah?

    Brian> Can we get something like /[\200-\377]{6}/ (6 upper ACSII
    Brian> characters in a row) added to the taboo list?

Brian's pattern doesn't match upper case letters.  It matches
characters with the most significant bit set.  'A' is 0101 octal,
'N' is 0116 octal, etc. so your example would not trigger the rule.
The idea of the rule is to filter out messages posted in non-Roman
character sets.

Roland

Re: ?????????????????????

[Bruce Harada]

On Wed, 06 Feb 2002 18:42:17 -0500
Brian <hiryuu@envisiongames.net> wrote:

> To my knowledge, there is no English word that would match that regex (or, 
> for that matter, any Romantic or Germanic language word).  It's the most 
> effective tool I've seen against Asian spam (like the one I replied to).


Just to set the record straight, that was RUSSIAN spam, not Asian spam...
(The regex should still be effective, of course.)

Re: ?????????????????????

[Pavel Machek]

Hi!

> like
> 
> Subject: [ANNOUNCE] blah blah?

He talked about characters >128.
							Pavel

> --On Wednesday, 06 February, 2002 4:21 PM -0500 Brian 
> <hiryuu@envisiongames.net> wrote:
> 
> >Can we get something like
> >	/[\200-\377]{6}/   (6 upper ACSII characters in a row)
> >added to the taboo list?
> >
> >	-- Brian
> >
> >On Tuesday 05 February 2002 06:48 pm, au_ru@yahoo.com wrote:
> >>ä?? Ç?Á×Î?Ç? Â??ÇÁ?Ô??Á.
> >>
> >>??ÉËÁÚ ? ÎÁ??Ç?×?? É ???ÔÎ?? ???ÉÔÉË? ÎÁ 2002 Ç?Ä (× ??ÄÁË?ÉÉ ?Ô 1

-- 
(about SSSCA) "I don't say this lightly.  However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa

Re: ?????????????????????

[Brian]

On Wednesday 06 February 2002 05:31 pm, Alex Bligh - linux-kernel wrote:
> like
>
> Subject: [ANNOUNCE] blah blah?
>

That would be upperCASE ACSII.
I mean 6 bytes, each higher than 127, in a row.

To my knowledge, there is no English word that would match that regex (or, 
for that matter, any Romantic or Germanic language word).  It's the most 
effective tool I've seen against Asian spam (like the one I replied to).

> --On Wednesday, 06 February, 2002 4:21 PM -0500 Brian
>
> <hiryuu@envisiongames.net> wrote:
> > Can we get something like
> > 	/[\200-\377]{6}/   (6 upper ACSII characters in a row)
> > added to the taboo list?
> >
> > 	-- Brian
>

Re: ?????????????????????

[David S. Miller]

   From: Bruce Harada <bruce@ask.ne.jp>
   Date: Thu, 7 Feb 2002 20:12:43 +0900

   On Wed, 06 Feb 2002 18:42:17 -0500
   Brian <hiryuu@envisiongames.net> wrote:
   
   > To my knowledge, there is no English word that would match that regex (or, 
   > for that matter, any Romantic or Germanic language word).  It's the most 
   > effective tool I've seen against Asian spam (like the one I replied to).
   
   Just to set the record straight, that was RUSSIAN spam, not Asian spam...
   (The regex should still be effective, of course.)

Except that it would block out uuencoded patches in postings perhaps?
Or is it just supposed to be matched in the Subject field or other
parts of the headers?

Re: ?????????????????????

[Jesse Pollard]

---------  Received message begins Here  ---------

> 
>    From: Bruce Harada <bruce@ask.ne.jp>
>    Date: Thu, 7 Feb 2002 20:12:43 +0900
> 
>    On Wed, 06 Feb 2002 18:42:17 -0500
>    Brian <hiryuu@envisiongames.net> wrote:
>    
>    > To my knowledge, there is no English word that would match that regex (or, 
>    > for that matter, any Romantic or Germanic language word).  It's the most 
>    > effective tool I've seen against Asian spam (like the one I replied to).
>    
>    Just to set the record straight, that was RUSSIAN spam, not Asian spam...
>    (The regex should still be effective, of course.)
> 
> Except that it would block out uuencoded patches in postings perhaps?
> Or is it just supposed to be matched in the Subject field or other
> parts of the headers?

I thought uuencode format required 7bit print ascii output, which would
never match that pattern.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: ?????????????????????

[Horst von Brand]

"David S. Miller" <davem@redhat.com> said:

[...]

> Except that it would block out uuencoded patches in postings perhaps?

Since when does uuencoding generate high chars? It is supposed to give only
"safe" chars (i.e., in ASCII and EBCDIC).
-- 
Horst von Brand			     http://counter.li.org # 22616

Re: ?????????????????????

[Pete Cervasio]

At 03:44 AM 2/7/2002 -0800, David S. Miller <davem@redhat.com> wrote:
>   From: Bruce Harada <bruce@ask.ne.jp>
>   Date: Thu, 7 Feb 2002 20:12:43 +0900
>
>   On Wed, 06 Feb 2002 18:42:17 -0500
>   Brian <hiryuu@envisiongames.net> wrote:
>   
>   > To my knowledge, there is no English word that would match that regex
(or, 
>   > for that matter, any Romantic or Germanic language word).  It's the
most 
>   > effective tool I've seen against Asian spam (like the one I replied to).
>   
>   Just to set the record straight, that was RUSSIAN spam, not Asian spam...
>   (The regex should still be effective, of course.)
>
>Except that it would block out uuencoded patches in postings perhaps?
>Or is it just supposed to be matched in the Subject field or other
>parts of the headers?

Um... no, it's just supposed to look at several characters in a row that
have the high bit set.  Have another cup of coffee and think about what
happens to attachments after they're uuencoded.  :)

Best regards,
Pete C.


=====================================================================
         $5                          $75
"this is your brain... this is your brain on ebay."
                                     (Pat McNeil on comp.sys.tandy)

Re: ?????????????????????

[Martin Dalecki]

Brian wrote:

>On Wednesday 06 February 2002 05:31 pm, Alex Bligh - linux-kernel wrote:
>
>>like
>>
>>Subject: [ANNOUNCE] blah blah?
>>
>
>That would be upperCASE ACSII.
>I mean 6 bytes, each higher than 127, in a row.
>
>To my knowledge, there is no English word that would match that regex (or, 
>for that matter, any Romantic or Germanic language word).  It's the most 
>effective tool I've seen against Asian spam (like the one I replied to).
>
Just for the record... the spam you replayed to was in russian.

Re: ?????????????????????

[Oliver M . Bolzer]

On Wed, Feb 06, 2002 at 04:21:50PM -0500, Brian <hiryuu@envisiongames.net> wrote...
> Can we get something like 
> 	/[\200-\377]{6}/   (6 upper ACSII characters in a row)
> added to the taboo list?

If you mean to match a header like Subject: , don't forget to
decode them first. Usually, headers containing these are MIME-encoded.

-- 
	Oliver M. Bolzer
	oliver@gol.com

GPG (PGP) Fingerprint = 621B 52F6 2AC1 36DB 8761  018F 8786 87AD EF50 D1FF

[Ãßõ] ²À °ËÅäÇÏ¿© Áֽʽÿä

[news]

[-- Attachment #1: Type: Text/HTML, Size: 14475 bytes --]

<html>
<head>
<title>Welcome to WorkCrew.net Promotion</title>
<style type="http://www.workcrew.net/text/css">

<!--

-->

</style>
<link rel="stylesheet" href="http://www.workcrew.net/style.css" type="text/css">
<script language="JavaScript">
<!--


<!--
function MM_reloadPage(init) {  //reloads the window if Nav4 resized
  if (init==true) with (navigator) {if ((appName=="Netscape")&&(parseInt(appVersion)==4)) {
    document.MM_pgW=innerWidth; document.MM_pgH=innerHeight; onresize=MM_reloadPage; }}
  else if (innerWidth!=document.MM_pgW || innerHeight!=document.MM_pgH) location.reload();
}
MM_reloadPage(true);
// -->
//-->
</script>
</head>

<body bgcolor="#F8F8F8" leftmargin="10" topmargin="0" marginwidth="0" marginheight="0">
<table width="596" cellspacing="0" cellpadding="0">
  <tr> 
    <td width="2" background="http://www.workcrew.net/img/top_left_bg.gif" rowspan="3"><img src="http://www.workcrew.net/img/top_left_bg.gif" width="2" height="22"></td>
    <td width="592" height="2" valign="top" background="http://www.workcrew.net/img/top_sub_bg.gif"> 
    </td>
    <td background="http://www.workcrew.net/img/top_right_bg.gif" width="10" rowspan="3"></td>
  </tr>
  <tr> 
    <td width="592" height="2" valign="top">
      <div align="center">
        <table width="592" border="0" cellspacing="0" cellpadding="0">
          <tr>
                      <td width="592" rowspan="8" bgcolor="#FFFFFF"> 
            <div align="center"><object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=5,0,0,0" width="590" height="151">
                <param name=movie value="http://www.workcrew.net/workcrew.swf">
                <param name=quality value=high>
                <embed src="http://www.workcrew.net/workcrew.swf" quality=high pluginspage="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash" type="application/x-shockwave-flash" width="590" height="151">
                </embed> 
              </object></div>
          </td>
          </tr>
        </table>
        <img src="http://www.workcrew.net/img/jumsun.gif" width="590" height="1"></div>
    </td>
  </tr>
  <tr>
    <td width="592" height="480" valign="top"> 
      <table width="592" cellspacing="0" cellpadding="0">
        <tr> 
          <td width="592" background="http://www.workcrew.net/img/main_bg.gif" height="2"><img src="http://www.workcrew.net/img/main_bg.gif" width="4" height="3"></td>
        </tr>
        <tr bgcolor="#FCFAF9"> 
          <td bgcolor="#FFFFFF" width="596" valign="top" height="40"> 
            <div align="center"> 
              <table width="588" border="0" cellspacing="0" cellpadding="0">
                <tr> 
                  <td rowspan="2" width="206"> 
                    <div align="center"><img src="http://www.workcrew.net/img/ani.gif" width="148" height="196"></div>
                  </td>
                  <td><img src="http://www.workcrew.net/img/main_img2_1.gif" width="254" height="89"></td>
                  <td><img src="http://www.workcrew.net/img/main_img3_1.gif" width="131" height="89"></td>
                </tr>
                <tr> 
                  <td><img src="http://www.workcrew.net/img/main_img5.gif" width="254" height="71"></td>
                  <td><img src="http://www.workcrew.net/img/main_img6.gif" width="130" height="71"></td>
                </tr>
                <tr> 
                  <td colspan="3"><img src="http://www.workcrew.net/img/main_title.gif" width="590" height="48"></td>
                </tr>
              </table>
              <table width="588" border="0" cellspacing="0" cellpadding="0" bgcolor="#F5F7FF">
                <tr> 
                  <td colspan="2"> 
                    <div align="center"><a href="http://www.workcrew.net/compaq_fr.htm" target="_parent"><img src="http://www.workcrew.net/img/main_product1.gif" width="94" height="95" border="0"></a></div>
                  </td>
                  <td width="18"> 
                    <div align="center"><img src="http://www.workcrew.net/img/pluse.gif" width="18" height="18"></div>
                  </td>
                  <td colspan="2"> 
                    <div align="center"><a href="http://www.workcrew.net/workcrew_fr.htm" target="_parent"><img src="http://www.workcrew.net/img/main_product2.gif" width="78" height="100" border="0"></a></div>
                  </td>
                  <td width="18"> 
                    <div align="center"><img src="http://www.workcrew.net/img/pluse.gif" width="18" height="18"></div>
                  </td>
                  <td> 
                    <div align="center"><a href="http://www.workcrew.net/microsoft_fr.htm" target="_parent"><img src="http://www.workcrew.net/img/main_product3.gif" width="80" height="95" border="0"></a></div>
                  </td>
                </tr>
                <tr> 
                  <td colspan="2"> 
                    <div align="center"><img src="http://www.workcrew.net/img/pac_img1.gif" width="158" height="11"></div>
                  </td>
                  <td> 
                    <div align="center"></div>
                  </td>
                  <td colspan="2"> 
                    <div align="center"><img src="http://www.workcrew.net/img/pac_img2.gif" width="169" height="13"></div>
                  </td>
                  <td height="20"> 
                    <div align="center"></div>
                  </td>
                  <td> 
                    <div align="center"><img src="http://www.workcrew.net/img/pac_img3.gif" width="148" height="13"></div>
                  </td>
                </tr>
                <tr> 
                  <td width="30">&nbsp;</td>
                  <td class="td"><img src="http://www.workcrew.net/img/main_icon.gif" width="6" height="10"> 
                    CPU :933MHz</td>
                  <td>&nbsp;</td>
                  <td width="30">&nbsp;</td>
                  <td width="130" class="td"><img src="http://www.workcrew.net/img/main_icon.gif" width="6" height="10"> 
                    À¥¸ÞÀÏ (Server Æ÷ÇÔ)</td>
                  <td>&nbsp;</td>
                  <td>&nbsp;</td>
                </tr>
                <tr> 
                  <td rowspan="2">&nbsp;</td>
                  <td width="100" class="td"><img src="http://www.workcrew.net/img/main_icon.gif" width="6" height="10"> 
                    Memory:256MB </td>
                  <td rowspan="2">&nbsp;</td>
                  <td rowspan="2">&nbsp;</td>
                  <td class="td"><img src="http://www.workcrew.net/img/main_icon.gif" width="6" height="10"> 
                    Àλç/¾÷¹«°ü¸®/&nbsp;</td>
                  <td rowspan="2">&nbsp;</td>
                  <td rowspan="2">&nbsp;</td>
                </tr>
                <tr> 
                  <td width="100" class="td"><img src="http://www.workcrew.net/img/main_icon.gif" width="6" height="10"> 
                    HD : 20GB</td>
                  <td class="td">&nbsp;&nbsp;¿µ¾÷Áö¿ø ½Ã½ºÅÛ</td>
                </tr>
                <tr> 
                  <td>&nbsp;</td>
                  <td class="td">&nbsp;</td>
                  <td>&nbsp;</td>
                  <td>&nbsp;</td>
                  <td class="td"><img src="http://www.workcrew.net/img/main_icon.gif" width="6" height="10"> 
                    ÀÏÁ¤/¹®¼­/¸í¾Ï °ü¸®</td>
                  <td>&nbsp;</td>
                  <td rowspan="5"> 
                    <div align="center"><img src="http://www.workcrew.net/img/387.gif" width="132" height="46"></div>
                  </td>
                </tr>
                <tr> 
                  <td colspan="2">&nbsp;</td>
                  <td>&nbsp;</td>
                  <td>&nbsp;</td>
                  <td width="130" class="td"><img src="http://www.workcrew.net/img/main_icon.gif" width="6" height="10"> 
                    ÀüÀÚ°áÀç/ÃâÅð±Ù°ü¸®</td>
                  <td>&nbsp;</td>
                </tr>
                <tr> 
                  <td colspan="2">&nbsp;</td>
                  <td rowspan="3">&nbsp;</td>
                  <td>&nbsp;</td>
                  <td class="td"><img src="http://www.workcrew.net/img/main_icon.gif" width="6" height="10"> 
                    Á¶Á÷µµ/ÁÖ¼Ò·Ï</td>
                  <td rowspan="3">&nbsp;</td>
                </tr>
                <tr> 
                  <td colspan="2" rowspan="2">&nbsp;</td>
                  <td>&nbsp;</td>
                  <td class="td"><img src="http://www.workcrew.net/img/main_icon.gif" width="6" height="10"> 
                    Ä¿¹Â´ÏƼ(°Ô½ÃÆÇ/¼³¹®Á¶»ç)</td>
                </tr>
                <tr> 
                  <td>&nbsp;</td>
                  <td class="td">&nbsp;&nbsp;[30 Users]</td>
                </tr>
              </table>
              <table width="590" border="0" cellspacing="0" cellpadding="0">
                <tr> 
                  <td colspan="3" height="1"><img src="http://www.workcrew.net/img/jumsun.gif" width="590" height="1"></td>
                </tr>
                <tr bgcolor="#FFFFFF"> 
                  <td height="50"><img src="http://www.workcrew.net/img/main_title_1.gif" width="268" height="40"></td>
                  <td>&nbsp;</td>
                  <td>&nbsp;</td>
                </tr>
              </table>
              <table width="588" border="0" cellspacing="0" cellpadding="0">
                <tr> 
                  <td bgcolor="#FFFFFF" colspan="2" valign="bottom"> 
                    <div align="right"><img src="http://www.workcrew.net/img/sbs_img1.gif" width="147" height="45"></div>
                  </td>
                  <td bgcolor="#FFFFFF" width="212" rowspan="3"> 
                    <div align="center"> 
                      <table width="212" border="0" cellspacing="0" cellpadding="0">
                        <tr> 
                          <td bgcolor="#FFFFFF" colspan="2"><img src="http://www.workcrew.net/img/sbs_img2.gif" width="186" height="18"></td>
                        </tr>
                        <tr> 
                          <td bgcolor="#FFFFFF" rowspan="5" width="64"><img src="http://www.workcrew.net/img/sbs_img4.gif" width="64" height="78"></td>
                          <td width="130" class="td" bgcolor="#FFFFFF">&nbsp;</td>
                        </tr>
                        <tr> 
                          <td width="130" class="td" bgcolor="#FFFFFF"><img src="http://www.workcrew.net/img/main_icon.gif" width="6" height="10"> 
                            window 2000 Server</td>
                        </tr>
                        <tr> 
                          <td class="td" bgcolor="#FFFFFF"><img src="http://www.workcrew.net/img/main_icon.gif" width="6" height="10"> 
                            Exchange 2000</td>
                        </tr>
                        <tr> 
                          <td class="td" bgcolor="#FFFFFF"><img src="http://www.workcrew.net/img/main_icon.gif" width="6" height="10"> 
                            SQL 2000</td>
                        </tr>
                        <tr> 
                          <td class="td" bgcolor="#FFFFFF"> 
                            <div align="center"><img src="http://www.workcrew.net/img/main_product14.gif" width="91" height="53"></div>
                          </td>
                        </tr>
                      </table>
                    </div>
                  </td>
                  <td rowspan="3" bgcolor="#FFFFFF" width="220"> 
                    <div align="center"> 
                      <table width="212" border="0" cellspacing="0" cellpadding="0">
                        <tr> 
                          <td> 
                            <div align="center"><img src="http://www.workcrew.net/img/index.gif" width="194" height="20" usemap="#Map" border="0"></div>
                          </td>
                        </tr>
                      </table>
                      <a href="http://www.workcrew.net"><br>
                      <img src="http://www.workcrew.net/img/index_1.gif" width="212" height="84" border="0"></a></div>
                  </td>
                </tr>
                <tr> 
                  <td bgcolor="#FFFFFF"> 
                    <div align="right"><img src="http://www.workcrew.net/img/pluse1.gif" width="9" height="9"></div>
                  </td>
                  <td bgcolor="#FFFFFF" width="10">&nbsp;</td>
                </tr>
                <tr> 
                  <td bgcolor="#FFFFFF" colspan="2" valign="top"> 
                    <div align="right"><img src="http://www.workcrew.net/img/sbs_img5.gif" width="147" height="40"></div>
                  </td>
                </tr>
              </table>
              <p><b>ÀÚ¼¼ÇÑ ³»¿ëÀº <a href="http://www.workcrew.net">www.workcrew.net</a>À» 
                ÂüÁ¶Çϼ¼¿ä.</b></p>
            </div>
          </td>
        </tr>
        <tr bgcolor="#FCFAF9">
          <td bgcolor="#FFFFFF" width="596" height="30"> 
            <div align="center"><b><font color="#666666">WorkCrew.net Newsletter</font></b> 
              ¼ö½Å°ÅºÎ¸¦ ¿øÇϽô °æ¿ì <a href="mailto:news@workcrew.net?subject=remove"><b>¿©±â</b></a>¸¦ 
              Ŭ¸¯Çϼ¼¿ä</div>
          </td>
        </tr>
      </table>
    </td>
  </tr>
</table>
<table width="596" cellspacing="0" cellpadding="0">
  <tr>
    <td bgcolor="#666699" width="5926"> 
      <div align="center"><font color="#FFFFFF"><img src="http://www.workcrew.net/img/button.gif" width="595" height="16" usemap="#Map2" border="0"></font></div>
    </td>
  </tr>
</table>
<map name="Map">
  <area shape="rect" coords="0,1,82,20" href="http://www.workcrew.net/workcrew_fr.htm" target="_parent">
  <area shape="rect" coords="105,1,192,25" href="http://www.workcrew.net/request_fr.htm" target="_parent">
</map>
<map name="Map2">
  <area shape="rect" coords="175,3,254,18" href="http://www.dazone.co.kr" target="_blank">
  <area shape="rect" coords="270,2,363,21" href="http://www.youngwoo.co.kr" target="_blank">
  <area shape="rect" coords="380,3,463,51" href="http://www.compaq.co.kr" target="_blank">
</map>
</body>
</html>

²À °ËÅäÇÏ¿© Áֽʽÿä

[news]

[-- Attachment #1: Type: Text/HTML, Size: 14464 bytes --]

<html>
<head>
<title>Welcome to WorkCrew.net Promotion</title>
<style type="http://www.workcrew.net/text/css">

<!--

-->

</style>
<link rel="stylesheet" href="http://www.workcrew.net/style.css" type="text/css">
<script language="JavaScript">
<!--


<!--
function MM_reloadPage(init) {  //reloads the window if Nav4 resized
  if (init==true) with (navigator) {if ((appName=="Netscape")&&(parseInt(appVersion)==4)) {
    document.MM_pgW=innerWidth; document.MM_pgH=innerHeight; onresize=MM_reloadPage; }}
  else if (innerWidth!=document.MM_pgW || innerHeight!=document.MM_pgH) location.reload();
}
MM_reloadPage(true);
// -->
//-->
</script>
</head>

<body bgcolor="#F8F8F8" leftmargin="10" topmargin="0" marginwidth="0" marginheight="0">
<table width="596" cellspacing="0" cellpadding="0">
  <tr> 
    <td width="2" background="http://www.workcrew.net/img/top_left_bg.gif" rowspan="3"><img src="http://www.workcrew.net/img/top_left_bg.gif" width="2" height="22"></td>
    <td width="592" height="2" valign="top" background="http://www.workcrew.net/img/top_sub_bg.gif"> 
    </td>
    <td background="http://www.workcrew.net/img/top_right_bg.gif" width="10" rowspan="3"></td>
  </tr>
  <tr> 
    <td width="592" height="2" valign="top">
      <div align="center">
        <table width="592" border="0" cellspacing="0" cellpadding="0">
          <tr>
                      <td width="592" rowspan="8" bgcolor="#FFFFFF"> 
            <div align="center"><object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=5,0,0,0" width="590" height="151">
                <param name=movie value="http://www.workcrew.net/workcrew.swf">
                <param name=quality value=high>
                <embed src="http://www.workcrew.net/workcrew.swf" quality=high pluginspage="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash" type="application/x-shockwave-flash" width="590" height="151">
                </embed> 
              </object></div>
          </td>
          </tr>
        </table>
        <img src="http://www.workcrew.net/img/jumsun.gif" width="590" height="1"></div>
    </td>
  </tr>
  <tr>
    <td width="592" height="480" valign="top"> 
      <table width="592" cellspacing="0" cellpadding="0">
        <tr> 
          <td width="592" background="http://www.workcrew.net/img/main_bg.gif" height="2"><img src="http://www.workcrew.net/img/main_bg.gif" width="4" height="3"></td>
        </tr>
        <tr bgcolor="#FCFAF9"> 
          <td bgcolor="#FFFFFF" width="596" valign="top" height="40"> 
            <div align="center"> 
              <table width="588" border="0" cellspacing="0" cellpadding="0">
                <tr> 
                  <td rowspan="2" width="206"> 
                    <div align="center"><img src="http://www.workcrew.net/img/ani.gif" width="148" height="196"></div>
                  </td>
                  <td><img src="http://www.workcrew.net/img/main_img2_1.gif" width="254" height="89"></td>
                  <td><img src="http://www.workcrew.net/img/main_img3_1.gif" width="131" height="89"></td>
                </tr>
                <tr> 
                  <td><img src="http://www.workcrew.net/img/main_img5.gif" width="254" height="71"></td>
                  <td><img src="http://www.workcrew.net/img/main_img6.gif" width="130" height="71"></td>
                </tr>
                <tr> 
                  <td colspan="3"><img src="http://www.workcrew.net/img/main_title.gif" width="590" height="48"></td>
                </tr>
              </table>
              <table width="588" border="0" cellspacing="0" cellpadding="0" bgcolor="#F5F7FF">
                <tr> 
                  <td colspan="2"> 
                    <div align="center"><a href="http://www.workcrew.net/compaq_fr.htm" target="_parent"><img src="http://www.workcrew.net/img/main_product1.gif" width="94" height="95" border="0"></a></div>
                  </td>
                  <td width="18"> 
                    <div align="center"><img src="http://www.workcrew.net/img/pluse.gif" width="18" height="18"></div>
                  </td>
                  <td colspan="2"> 
                    <div align="center"><a href="http://www.workcrew.net/workcrew_fr.htm" target="_parent"><img src="http://www.workcrew.net/img/main_product2.gif" width="78" height="100" border="0"></a></div>
                  </td>
                  <td width="18"> 
                    <div align="center"><img src="http://www.workcrew.net/img/pluse.gif" width="18" height="18"></div>
                  </td>
                  <td> 
                    <div align="center"><a href="http://www.workcrew.net/microsoft_fr.htm" target="_parent"><img src="http://www.workcrew.net/img/main_product3.gif" width="80" height="95" border="0"></a></div>
                  </td>
                </tr>
                <tr> 
                  <td colspan="2"> 
                    <div align="center"><img src="http://www.workcrew.net/img/pac_img1.gif" width="158" height="11"></div>
                  </td>
                  <td> 
                    <div align="center"></div>
                  </td>
                  <td colspan="2"> 
                    <div align="center"><img src="http://www.workcrew.net/img/pac_img2.gif" width="169" height="13"></div>
                  </td>
                  <td height="20"> 
                    <div align="center"></div>
                  </td>
                  <td> 
                    <div align="center"><img src="http://www.workcrew.net/img/pac_img3.gif" width="148" height="13"></div>
                  </td>
                </tr>
                <tr> 
                  <td width="30">&nbsp;</td>
                  <td class="td"><img src="http://www.workcrew.net/img/main_icon.gif" width="6" height="10"> 
                    CPU :93MHz</td>
                  <td>&nbsp;</td>
                  <td width="30">&nbsp;</td>
                  <td width="130" class="td"><img src="http://www.workcrew.net/img/main_icon.gif" width="6" height="10"> 
                    À¥¸ÞÀÏ (Server Æ÷ÇÔ)</td>
                  <td>&nbsp;</td>
                  <td>&nbsp;</td>
                </tr>
                <tr> 
                  <td rowspan="2">&nbsp;</td>
                  <td width="100" class="td"><img src="http://www.workcrew.net/img/main_icon.gif" width="6" height="10"> 
                    Memory:256MB </td>
                  <td rowspan="2">&nbsp;</td>
                  <td rowspan="2">&nbsp;</td>
                  <td class="td"><img src="http://www.workcrew.net/img/main_icon.gif" width="6" height="10"> 
                    Àλç/¾÷¹«°ü¸®/&nbsp;</td>
                  <td rowspan="2">&nbsp;</td>
                  <td rowspan="2">&nbsp;</td>
                </tr>
                <tr> 
                  <td width="100" class="td"><img src="http://www.workcrew.net/img/main_icon.gif" width="6" height="10"> 
                    HD : 20GB</td>
                  <td class="td">&nbsp;&nbsp;¿µ¾÷Áö¿ø ½Ã½ºÅÛ</td>
                </tr>
                <tr> 
                  <td>&nbsp;</td>
                  <td class="td">&nbsp;</td>
                  <td>&nbsp;</td>
                  <td>&nbsp;</td>
                  <td class="td"><img src="http://www.workcrew.net/img/main_icon.gif" width="6" height="10"> 
                    ÀÏÁ¤/¹®¼­/¸í¾Ï °ü¸®</td>
                  <td>&nbsp;</td>
                  <td rowspan="5"> 
                    <div align="center"><img src="http://www.workcrew.net/img/387.gif" width="132" height="46"></div>
                  </td>
                </tr>
                <tr> 
                  <td colspan="2">&nbsp;</td>
                  <td>&nbsp;</td>
                  <td>&nbsp;</td>
                  <td width="130" class="td"><img src="http://www.workcrew.net/img/main_icon.gif" width="6" height="10"> 
                    ÀüÀÚ°áÀç/ÃâÅð±Ù°ü¸®</td>
                  <td>&nbsp;</td>
                </tr>
                <tr> 
                  <td colspan="2">&nbsp;</td>
                  <td rowspan="3">&nbsp;</td>
                  <td>&nbsp;</td>
                  <td class="td"><img src="http://www.workcrew.net/img/main_icon.gif" width="6" height="10"> 
                    Á¶Á÷µµ/ÁÖ¼Ò·Ï</td>
                  <td rowspan="3">&nbsp;</td>
                </tr>
                <tr> 
                  <td colspan="2" rowspan="2">&nbsp;</td>
                  <td>&nbsp;</td>
                  <td class="td"><img src="http://www.workcrew.net/img/main_icon.gif" width="6" height="10"> 
                    Ä¿¹Â´ÏƼ</td>
                </tr>
                <tr> 
                  <td>&nbsp;</td>
                  <td class="td">&nbsp;&nbsp;(°Ô½ÃÆÇ/¼³¹®Á¶»ç)</td>
                </tr>
              </table>
              <table width="590" border="0" cellspacing="0" cellpadding="0">
                <tr> 
                  <td colspan="3" height="1"><img src="http://www.workcrew.net/img/jumsun.gif" width="590" height="1"></td>
                </tr>
                <tr bgcolor="#FFFFFF"> 
                  <td height="50"><img src="http://www.workcrew.net/img/main_title_1.gif" width="268" height="40"></td>
                  <td>&nbsp;</td>
                  <td>&nbsp;</td>
                </tr>
              </table>
              <table width="588" border="0" cellspacing="0" cellpadding="0">
                <tr> 
                  <td bgcolor="#FFFFFF" colspan="2" valign="bottom"> 
                    <div align="right"><img src="http://www.workcrew.net/img/sbs_img1.gif" width="147" height="45"></div>
                  </td>
                  <td bgcolor="#FFFFFF" width="212" rowspan="3"> 
                    <div align="center"> 
                      <table width="212" border="0" cellspacing="0" cellpadding="0">
                        <tr> 
                          <td bgcolor="#FFFFFF" colspan="2"><img src="http://www.workcrew.net/img/sbs_img2.gif" width="186" height="18"></td>
                        </tr>
                        <tr> 
                          <td bgcolor="#FFFFFF" rowspan="5" width="64"><img src="http://www.workcrew.net/img/sbs_img4.gif" width="64" height="78"></td>
                          <td width="130" class="td" bgcolor="#FFFFFF">&nbsp;</td>
                        </tr>
                        <tr> 
                          <td width="130" class="td" bgcolor="#FFFFFF"><img src="http://www.workcrew.net/img/main_icon.gif" width="6" height="10"> 
                            window 2000 Server</td>
                        </tr>
                        <tr> 
                          <td class="td" bgcolor="#FFFFFF"><img src="http://www.workcrew.net/img/main_icon.gif" width="6" height="10"> 
                            Exchange 2000</td>
                        </tr>
                        <tr> 
                          <td class="td" bgcolor="#FFFFFF"><img src="http://www.workcrew.net/img/main_icon.gif" width="6" height="10"> 
                            SQL 2000</td>
                        </tr>
                        <tr> 
                          <td class="td" bgcolor="#FFFFFF"> 
                            <div align="center"><img src="http://www.workcrew.net/img/main_product14.gif" width="91" height="53"></div>
                          </td>
                        </tr>
                      </table>
                    </div>
                  </td>
                  <td rowspan="3" bgcolor="#FFFFFF" width="220"> 
                    <div align="center"> 
                      <table width="212" border="0" cellspacing="0" cellpadding="0">
                        <tr> 
                          <td> 
                            <div align="center"><img src="http://www.workcrew.net/img/index.gif" width="194" height="20" usemap="#Map" border="0"></div>
                          </td>
                        </tr>
                      </table>
                      <a href="http://www.workcrew.net"><br>
                      <img src="http://www.workcrew.net/img/index_1.gif" width="212" height="84" border="0"></a></div>
                  </td>
                </tr>
                <tr> 
                  <td bgcolor="#FFFFFF"> 
                    <div align="right"><img src="http://www.workcrew.net/img/pluse1.gif" width="9" height="9"></div>
                  </td>
                  <td bgcolor="#FFFFFF" width="10">&nbsp;</td>
                </tr>
                <tr> 
                  <td bgcolor="#FFFFFF" colspan="2" valign="top"> 
                    <div align="right"><img src="http://www.workcrew.net/img/sbs_img5.gif" width="147" height="40"></div>
                  </td>
                </tr>
              </table>
              <p><b>ÀÚ¼¼ÇÑ ³»¿ëÀº <a href="http://www.workcrew.net">www.workcrew.net</a>À» 
                ÂüÁ¶Çϼ¼¿ä.</b></p>
            </div>
          </td>
        </tr>
        <tr bgcolor="#FCFAF9">
          <td bgcolor="#FFFFFF" width="596" height="30"> 
            <div align="center"><b><font color="#666666">WorkCrew.net Newsletter</font></b> 
              ¼ö½Å°ÅºÎ¸¦ ¿øÇϽô °æ¿ì <a href="mailto:news@workcrew.net?subject=remove"><b>¿©±â</b></a>¸¦ 
              Ŭ¸¯Çϼ¼¿ä</div>
          </td>
        </tr>
      </table>
    </td>
  </tr>
</table>
<table width="596" cellspacing="0" cellpadding="0">
  <tr>
    <td bgcolor="#666699" width="5926"> 
      <div align="center"><font color="#FFFFFF"><img src="http://www.workcrew.net/img/button.gif" width="595" height="16" usemap="#Map2" border="0"></font></div>
    </td>
  </tr>
</table>
<map name="Map">
  <area shape="rect" coords="0,1,82,20" href="http://www.workcrew.net/workcrew_fr.htm" target="_parent">
  <area shape="rect" coords="105,1,192,25" href="http://www.workcrew.net/request_fr.htm" target="_parent">
</map>
<map name="Map2">
  <area shape="rect" coords="175,3,254,18" href="http://www.dazone.co.kr" target="_blank">
  <area shape="rect" coords="270,2,363,21" href="http://www.youngwoo.co.kr" target="_blank">
  <area shape="rect" coords="380,3,463,51" href="http://www.compaq.co.kr" target="_blank">
</map>
</body>
</html>

Re: ?

[Roberto Cescon]

And I would like to do the same(SELinux to work with SuSE.) +
I would like to have a free address for the Suse 7.2, having the 7.1.
I am interested in selinux(NSA Security-Enhanced) because I am always
interested in
Anything cutting edge!
Is this ok?
Rob



Stephen Smalley wrote:

> On Mon, 22 Oct 2001, Roberto Cescon wrote:
>
> > I have tried to send 2 emails but I have received none.
> > What is happening?
> > Is this an open suse list or a concentrament KAMP?
>
> The 'selinux' list is for discussions relating to NSA Security-Enhanced
> Linux (SELinux).  It has nothing to do with SuSE.  The person to whom you
> replied on the list was talking about getting SELinux to work with SuSE.
>
> --
> Stephen D. Smalley, NAI Labs
> ssmalley@nai.com


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

?

[Roberto Cescon]

Sorry the other address was of my friend.




I have tried to send 2 emails but I have received none.
What is happening?
Is this an open suse list or a concentrament KAMP?
Thanks
Rob


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[

[Philippe Chauvat]

Hello there,

When I boot my Challenger on the remote machine (for installation), a
kernel panic event is raised.

Does anybody could explain to me, what could appear ?

Thanks a lot
Philippe

Re: [

[Florian Lohoff]

On Mon, Jun 19, 2000 at 01:06:41PM -0400, Philippe Chauvat wrote:
> Hello there,
> 
> When I boot my Challenger on the remote machine (for installation), a
> kernel panic event is raised.

You mean SGI Challenge ?

> Does anybody could explain to me, what could appear ?

If so - This machine is AFAIk completely unsupported ...

Flo
-- 
Florian Lohoff		flo@rfc822.org		      	+49-waiting-4-telekom
     "If you're not having fun right now, you're wasting your time."

Re: [

[Keith M Wesolowski]

On Mon, Jun 19, 2000 at 11:32:58AM -0700, Florian Lohoff wrote:

> You mean SGI Challenge ?
> 
> > Does anybody could explain to me, what could appear ?
> 
> If so - This machine is AFAIk completely unsupported ...

It could be a Challenge S, which should probably work. What
kernel/machine exactly is this?

-- 
Keith M Wesolowski			wesolows@chem.unr.edu
University of Nevada			http://www.chem.unr.edu
Chemistry Department Systems and Network Administrator

Re: [

[Ralf Baechle]

On Mon, Jun 19, 2000 at 11:45:36AM -0700, Keith M Wesolowski wrote:

> > You mean SGI Challenge ?
> > 
> > > Does anybody could explain to me, what could appear ?
> > 
> > If so - This machine is AFAIk completely unsupported ...
> 
> It could be a Challenge S, which should probably work. What
> kernel/machine exactly is this?

It must be a Challenge S.  I don't believe that on another Challenge
the kernel would even be able to print a panic message ...

I guess he was trying the Hardhat kernel which was panicing on certain
configurations.

  Ralf