* Re: [PATCH] macvtap: fix the uninitialized var using in macvtap_alloc_skb()
From: Ian Campbell @ 2011-09-20 10:58 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Jason Wang, netdev, davem, linux-kernel, Dan Carpenter
In-Reply-To: <20110919095415.GD4501@redhat.com>
On Mon, 2011-09-19 at 12:54 +0300, Michael S. Tsirkin wrote:
> On Mon, Sep 19, 2011 at 05:48:31PM +0800, Jason Wang wrote:
> > Commit d1b08284 use new frag API but would leave f to be used
> > uninitialized, this patch fix it.
> >
> > Signed-off-by: Jason Wang <jasowang@redhat.com>
>
> Good catch. Makes absolute sense.
>
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
Agreed. I like this one better than the one I just sent out so:
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Thanks Jason.
>
> > ---
> > drivers/net/macvtap.c | 12 +++++-------
> > 1 files changed, 5 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
> > index 7c3f84a..3da5578 100644
> > --- a/drivers/net/macvtap.c
> > +++ b/drivers/net/macvtap.c
> > @@ -453,7 +453,6 @@ static int zerocopy_sg_from_iovec(struct sk_buff *skb, const struct iovec *from,
> > int copy = skb_headlen(skb);
> > int size, offset1 = 0;
> > int i = 0;
> > - skb_frag_t *f;
> >
> > /* Skip over from offset */
> > while (count && (offset >= from->iov_len)) {
> > @@ -503,14 +502,13 @@ static int zerocopy_sg_from_iovec(struct sk_buff *skb, const struct iovec *from,
> > skb->truesize += len;
> > atomic_add(len, &skb->sk->sk_wmem_alloc);
> > while (len) {
> > - __skb_fill_page_desc(
> > - skb, i, page[i],
> > - base & ~PAGE_MASK,
> > - min_t(int, len, PAGE_SIZE - f->page_offset));
> > + int off = base & ~PAGE_MASK;
> > + int size = min_t(int, len, PAGE_SIZE - off);
> > + __skb_fill_page_desc(skb, i, page[i], off, size);
> > skb_shinfo(skb)->nr_frags++;
> > /* increase sk_wmem_alloc */
> > - base += f->size;
> > - len -= f->size;
> > + base += size;
> > + len -= size;
> > i++;
> > }
> > offset1 = 0;
> --
> 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/
>
^ permalink raw reply
* Re: [PATCH v4 4/8] SUNRPC: setup rpcbind clients if service requires it
From: Jeff Layton @ 2011-09-20 11:22 UTC (permalink / raw)
To: Stanislav Kinsbursky
Cc: Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, xemul-bzQdu9zFT3WakBO8gow8eQ,
neilb-l3A5Bk7waGM, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bfields-uC3wQj2KruNg9hUCZPvPmw, davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <20110920101404.9861.83097.stgit-bi+AKbBUZKagILUCTcTcHdKyNwTtLsGr@public.gmane.org>
On Tue, 20 Sep 2011 14:14:04 +0400
Stanislav Kinsbursky <skinsbursky-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> wrote:
> New function ("svc_uses_rpcbind") will be used to detect, that new service will
> send portmapper register calls. For such services we will create rpcbind
> clients and remove all stale portmap registrations.
> Also, svc_rpcb_cleanup() will be set as sv_shutdown callback for such services
> in case of this field wasn't initialized earlier. This will allow to destroy
> rpcbind clients when no other users of them left.
>
> Note: Currently, any creating service will be detected as portmap user.
> Probably, this is wrong. But now it depends on program versions "vs_hidden"
> flag.
>
Yes, I think that nfs4_callback_version4 should also have vs_hidden
set. Currently, it's trying to unregister the service from the
portmapper on shutdown even though it's not registering it. Basically,
any service that sets up its sockets with SVC_SOCK_ANONYMOUS should
also have vs_hidden set on all versions.
--
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 0/8] SUNRPC: make rpcbind clients allocated and destroyed dynamically
From: Jeff Layton @ 2011-09-20 11:24 UTC (permalink / raw)
To: Stanislav Kinsbursky
Cc: Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, xemul-bzQdu9zFT3WakBO8gow8eQ,
neilb-l3A5Bk7waGM, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bfields-uC3wQj2KruNg9hUCZPvPmw, davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <20110920101031.9861.18444.stgit-bi+AKbBUZKagILUCTcTcHdKyNwTtLsGr@public.gmane.org>
On Tue, 20 Sep 2011 14:13:32 +0400
Stanislav Kinsbursky <skinsbursky-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> wrote:
> v4:
> 1) creation and destruction on rpcbind clients now depends on service program
> versions "vs_hidden" flag.
>
> This patch is required for further RPC layer virtualization, because rpcbind
> clients have to be per network namespace.
> To achive this, we have to untie network namespace from rpcbind clients sockets.
> The idea of this patch set is to make rpcbind clients non-static. I.e. rpcbind
> clients will be created during first RPC service creation, and destroyed when
> last RPC service is stopped.
> With this patch set rpcbind clients can be virtualized easely.
>
>
> The following series consists of:
>
> ---
>
> Stanislav Kinsbursky (8):
> SUNRPC: introduce helpers for reference counted rpcbind clients
> SUNRPC: use rpcbind reference counting helpers
> SUNRPC: introduce svc helpers for prepairing rpcbind infrastructure
> SUNRPC: setup rpcbind clients if service requires it
> SUNRPC: cleanup service destruction
> NFSd: call svc rpcbind cleanup explicitly
> SUNRPC: remove rpcbind clients creation during service registering
> SUNRPC: remove rpcbind clients destruction on module cleanup
>
>
> fs/nfsd/nfssvc.c | 2 +
> include/linux/sunrpc/clnt.h | 2 +
> include/linux/sunrpc/svc.h | 1 +
> net/sunrpc/rpcb_clnt.c | 85 ++++++++++++++++++++++++++++---------------
> net/sunrpc/sunrpc_syms.c | 3 --
> net/sunrpc/svc.c | 48 +++++++++++++++++++++++-
> 6 files changed, 105 insertions(+), 36 deletions(-)
>
Patchset looks good to me. The only remaining thing I think is to set
vs_hidden on nfs4_callback_version4, but that patch is orthogonal to
this set.
Reviewed-by: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 0/2] ptp: more bug fixes for 3.1 and 3.0
From: Richard Cochran @ 2011-09-20 11:25 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, David Miller
These two patches fix two bugs in the PTP Hardware Clock drivers. The
drivers were first introduced in Linux version 3.0.
Thanks,
Richard
Richard Cochran (2):
ptp: fix L2 event message recognition
dp83640: reduce driver noise
drivers/net/phy/dp83640.c | 4 ++--
include/linux/ptp_classify.h | 13 ++++++++++---
2 files changed, 12 insertions(+), 5 deletions(-)
--
1.7.2.5
^ permalink raw reply
* [PATCH 1/2] ptp: fix L2 event message recognition
From: Richard Cochran @ 2011-09-20 11:25 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, David Miller, stable
In-Reply-To: <cover.1316516989.git.richard.cochran@omicron.at>
The IEEE 1588 standard defines two kinds of messages, event and general
messages. Event messages require time stamping, and general do not. When
using UDP transport, two separate ports are used for the two message
types.
The BPF designed to recognize event messages incorrectly classifies L2
general messages as event messages. This commit fixes the issue by
extending the filter to check the message type field for L2 PTP packets.
Event messages are be distinguished from general messages by testing
the "general" bit.
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
Cc: <stable@kernel.org>
---
include/linux/ptp_classify.h | 13 ++++++++++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/include/linux/ptp_classify.h b/include/linux/ptp_classify.h
index e07e274..1dc420b 100644
--- a/include/linux/ptp_classify.h
+++ b/include/linux/ptp_classify.h
@@ -51,6 +51,7 @@
#define PTP_CLASS_V2_VLAN (PTP_CLASS_V2 | PTP_CLASS_VLAN)
#define PTP_EV_PORT 319
+#define PTP_GEN_BIT 0x08 /* indicates general message, if set in message type */
#define OFF_ETYPE 12
#define OFF_IHL 14
@@ -116,14 +117,20 @@ static inline int ptp_filter_init(struct sock_filter *f, int len)
{OP_OR, 0, 0, PTP_CLASS_IPV6 }, /* */ \
{OP_RETA, 0, 0, 0 }, /* */ \
/*L3x*/ {OP_RETK, 0, 0, PTP_CLASS_NONE }, /* */ \
-/*L40*/ {OP_JEQ, 0, 6, ETH_P_8021Q }, /* f goto L50 */ \
+/*L40*/ {OP_JEQ, 0, 9, ETH_P_8021Q }, /* f goto L50 */ \
{OP_LDH, 0, 0, OFF_ETYPE + 4 }, /* */ \
- {OP_JEQ, 0, 9, ETH_P_1588 }, /* f goto L60 */ \
+ {OP_JEQ, 0, 15, ETH_P_1588 }, /* f goto L60 */ \
+ {OP_LDB, 0, 0, ETH_HLEN + VLAN_HLEN }, /* */ \
+ {OP_AND, 0, 0, PTP_GEN_BIT }, /* */ \
+ {OP_JEQ, 0, 12, 0 }, /* f goto L6x */ \
{OP_LDH, 0, 0, ETH_HLEN + VLAN_HLEN }, /* */ \
{OP_AND, 0, 0, PTP_CLASS_VMASK }, /* */ \
{OP_OR, 0, 0, PTP_CLASS_VLAN }, /* */ \
{OP_RETA, 0, 0, 0 }, /* */ \
-/*L50*/ {OP_JEQ, 0, 4, ETH_P_1588 }, /* f goto L61 */ \
+/*L50*/ {OP_JEQ, 0, 7, ETH_P_1588 }, /* f goto L61 */ \
+ {OP_LDB, 0, 0, ETH_HLEN }, /* */ \
+ {OP_AND, 0, 0, PTP_GEN_BIT }, /* */ \
+ {OP_JEQ, 0, 4, 0 }, /* f goto L6x */ \
{OP_LDH, 0, 0, ETH_HLEN }, /* */ \
{OP_AND, 0, 0, PTP_CLASS_VMASK }, /* */ \
{OP_OR, 0, 0, PTP_CLASS_L2 }, /* */ \
--
1.7.2.5
^ permalink raw reply related
* [PATCH 2/2] dp83640: reduce driver noise
From: Richard Cochran @ 2011-09-20 11:25 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, David Miller
In-Reply-To: <cover.1316516989.git.richard.cochran@omicron.at>
The driver has two warning messages that might be triggered
by normal use cases. When they appear, the messages give the
impression of a never ending series of errors.
This commit changes them to debug messages instead.
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
drivers/net/phy/dp83640.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/dp83640.c b/drivers/net/phy/dp83640.c
index cb6e0b4..edd7304 100644
--- a/drivers/net/phy/dp83640.c
+++ b/drivers/net/phy/dp83640.c
@@ -589,7 +589,7 @@ static void decode_rxts(struct dp83640_private *dp83640,
prune_rx_ts(dp83640);
if (list_empty(&dp83640->rxpool)) {
- pr_warning("dp83640: rx timestamp pool is empty\n");
+ pr_debug("dp83640: rx timestamp pool is empty\n");
goto out;
}
rxts = list_first_entry(&dp83640->rxpool, struct rxts, list);
@@ -612,7 +612,7 @@ static void decode_txts(struct dp83640_private *dp83640,
skb = skb_dequeue(&dp83640->tx_queue);
if (!skb) {
- pr_warning("dp83640: have timestamp but tx_queue empty\n");
+ pr_debug("dp83640: have timestamp but tx_queue empty\n");
return;
}
ns = phy2txts(phy_txts);
--
1.7.2.5
^ permalink raw reply related
* [PATCH net-next 0/3] ptp: feature enhancements
From: Richard Cochran @ 2011-09-20 11:43 UTC (permalink / raw)
To: netdev; +Cc: David Miller
This series adds one driver specific enhancement and one new feature
to the PTP Hardware Clock subsystem. The first patch enables more of
the phyter's IO capabilities. The second patch introduces PTP one-step
support for Sync messages at the driver level. The third patch
implements the one-step flag in the phyter.
Richard Cochran (3):
dp83640: enable six external events and one periodic output
net: introduce ptp one step time stamp mode for sync packets
dp83640: add time stamp insertion for sync messages
drivers/net/phy/dp83640.c | 205 +++++++++++++++++++++++++++++++++++++-------
include/linux/net_tstamp.h | 9 ++
2 files changed, 182 insertions(+), 32 deletions(-)
--
1.7.2.5
^ permalink raw reply
* [PATCH net-next 1/3] dp83640: enable six external events and one periodic output
From: Richard Cochran @ 2011-09-20 11:43 UTC (permalink / raw)
To: netdev; +Cc: David Miller
In-Reply-To: <cover.1316518332.git.richard.cochran@omicron.at>
This patch enables six external event channels and one periodic output.
One GPIO is reserved for synchronizing multiple PHYs. The assignment
of GPIO functions can be changed via a module parameter.
The code supports multiple simultaneous events by inducing a PTP clock
event for every channel marked in the PHY's extended status word.
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
drivers/net/phy/dp83640.c | 135 ++++++++++++++++++++++++++++++++++++++------
1 files changed, 116 insertions(+), 19 deletions(-)
diff --git a/drivers/net/phy/dp83640.c b/drivers/net/phy/dp83640.c
index edd7304..d3c6a2e 100644
--- a/drivers/net/phy/dp83640.c
+++ b/drivers/net/phy/dp83640.c
@@ -35,16 +35,15 @@
#define LAYER4 0x02
#define LAYER2 0x01
#define MAX_RXTS 64
-#define N_EXT_TS 1
+#define N_EXT_TS 6
#define PSF_PTPVER 2
#define PSF_EVNT 0x4000
#define PSF_RX 0x2000
#define PSF_TX 0x1000
#define EXT_EVENT 1
-#define EXT_GPIO 1
-#define CAL_EVENT 2
-#define CAL_GPIO 9
-#define CAL_TRIGGER 2
+#define CAL_EVENT 7
+#define CAL_TRIGGER 7
+#define PER_TRIGGER 6
/* phyter seems to miss the mark by 16 ns */
#define ADJTIME_FIX 16
@@ -131,16 +130,30 @@ struct dp83640_clock {
/* globals */
+enum {
+ CALIBRATE_GPIO,
+ PEROUT_GPIO,
+ EXTTS0_GPIO,
+ EXTTS1_GPIO,
+ EXTTS2_GPIO,
+ EXTTS3_GPIO,
+ EXTTS4_GPIO,
+ EXTTS5_GPIO,
+ GPIO_TABLE_SIZE
+};
+
static int chosen_phy = -1;
-static ushort cal_gpio = 4;
+static ushort gpio_tab[GPIO_TABLE_SIZE] = {
+ 1, 2, 3, 4, 8, 9, 10, 11
+};
module_param(chosen_phy, int, 0444);
-module_param(cal_gpio, ushort, 0444);
+module_param_array(gpio_tab, ushort, NULL, 0444);
MODULE_PARM_DESC(chosen_phy, \
"The address of the PHY to use for the ancillary clock features");
-MODULE_PARM_DESC(cal_gpio, \
- "Which GPIO line to use for synchronizing multiple PHYs");
+MODULE_PARM_DESC(gpio_tab, \
+ "Which GPIO line to use for which purpose: cal,perout,extts1,...,extts6");
/* a list of clocks and a mutex to protect it */
static LIST_HEAD(phyter_clocks);
@@ -235,6 +248,61 @@ static u64 phy2txts(struct phy_txts *p)
return ns;
}
+static void periodic_output(struct dp83640_clock *clock,
+ struct ptp_clock_request *clkreq, bool on)
+{
+ struct dp83640_private *dp83640 = clock->chosen;
+ struct phy_device *phydev = dp83640->phydev;
+ u32 sec, nsec, period;
+ u16 gpio, ptp_trig, trigger, val;
+
+ gpio = on ? gpio_tab[PEROUT_GPIO] : 0;
+ trigger = PER_TRIGGER;
+
+ ptp_trig = TRIG_WR |
+ (trigger & TRIG_CSEL_MASK) << TRIG_CSEL_SHIFT |
+ (gpio & TRIG_GPIO_MASK) << TRIG_GPIO_SHIFT |
+ TRIG_PER |
+ TRIG_PULSE;
+
+ val = (trigger & TRIG_SEL_MASK) << TRIG_SEL_SHIFT;
+
+ if (!on) {
+ val |= TRIG_DIS;
+ mutex_lock(&clock->extreg_lock);
+ ext_write(0, phydev, PAGE5, PTP_TRIG, ptp_trig);
+ ext_write(0, phydev, PAGE4, PTP_CTL, val);
+ mutex_unlock(&clock->extreg_lock);
+ return;
+ }
+
+ sec = clkreq->perout.start.sec;
+ nsec = clkreq->perout.start.nsec;
+ period = clkreq->perout.period.sec * 1000000000UL;
+ period += clkreq->perout.period.nsec;
+
+ mutex_lock(&clock->extreg_lock);
+
+ ext_write(0, phydev, PAGE5, PTP_TRIG, ptp_trig);
+
+ /*load trigger*/
+ val |= TRIG_LOAD;
+ ext_write(0, phydev, PAGE4, PTP_CTL, val);
+ ext_write(0, phydev, PAGE4, PTP_TDR, nsec & 0xffff); /* ns[15:0] */
+ ext_write(0, phydev, PAGE4, PTP_TDR, nsec >> 16); /* ns[31:16] */
+ ext_write(0, phydev, PAGE4, PTP_TDR, sec & 0xffff); /* sec[15:0] */
+ ext_write(0, phydev, PAGE4, PTP_TDR, sec >> 16); /* sec[31:16] */
+ ext_write(0, phydev, PAGE4, PTP_TDR, period & 0xffff); /* ns[15:0] */
+ ext_write(0, phydev, PAGE4, PTP_TDR, period >> 16); /* ns[31:16] */
+
+ /*enable trigger*/
+ val &= ~TRIG_LOAD;
+ val |= TRIG_EN;
+ ext_write(0, phydev, PAGE4, PTP_CTL, val);
+
+ mutex_unlock(&clock->extreg_lock);
+}
+
/* ptp clock methods */
static int ptp_dp83640_adjfreq(struct ptp_clock_info *ptp, s32 ppb)
@@ -338,19 +406,30 @@ static int ptp_dp83640_enable(struct ptp_clock_info *ptp,
struct dp83640_clock *clock =
container_of(ptp, struct dp83640_clock, caps);
struct phy_device *phydev = clock->chosen->phydev;
- u16 evnt;
+ int index;
+ u16 evnt, event_num, gpio_num;
switch (rq->type) {
case PTP_CLK_REQ_EXTTS:
- if (rq->extts.index != 0)
+ index = rq->extts.index;
+ if (index < 0 || index >= N_EXT_TS)
return -EINVAL;
- evnt = EVNT_WR | (EXT_EVENT & EVNT_SEL_MASK) << EVNT_SEL_SHIFT;
+ event_num = EXT_EVENT + index;
+ evnt = EVNT_WR | (event_num & EVNT_SEL_MASK) << EVNT_SEL_SHIFT;
if (on) {
- evnt |= (EXT_GPIO & EVNT_GPIO_MASK) << EVNT_GPIO_SHIFT;
+ gpio_num = gpio_tab[EXTTS0_GPIO + index];
+ evnt |= (gpio_num & EVNT_GPIO_MASK) << EVNT_GPIO_SHIFT;
evnt |= EVNT_RISE;
}
ext_write(0, phydev, PAGE5, PTP_EVNT, evnt);
return 0;
+
+ case PTP_CLK_REQ_PEROUT:
+ if (rq->perout.index != 0)
+ return -EINVAL;
+ periodic_output(clock, rq, on);
+ return 0;
+
default:
break;
}
@@ -441,9 +520,10 @@ static void recalibrate(struct dp83640_clock *clock)
struct list_head *this;
struct dp83640_private *tmp;
struct phy_device *master = clock->chosen->phydev;
- u16 cfg0, evnt, ptp_trig, trigger, val;
+ u16 cal_gpio, cfg0, evnt, ptp_trig, trigger, val;
trigger = CAL_TRIGGER;
+ cal_gpio = gpio_tab[CALIBRATE_GPIO];
mutex_lock(&clock->extreg_lock);
@@ -542,11 +622,17 @@ static void recalibrate(struct dp83640_clock *clock)
/* time stamping methods */
+static inline u16 exts_chan_to_edata(int ch)
+{
+ return 1 << ((ch + EXT_EVENT) * 2);
+}
+
static int decode_evnt(struct dp83640_private *dp83640,
void *data, u16 ests)
{
struct phy_txts *phy_txts;
struct ptp_clock_event event;
+ int i, parsed;
int words = (ests >> EVNT_TS_LEN_SHIFT) & EVNT_TS_LEN_MASK;
u16 ext_status = 0;
@@ -568,14 +654,25 @@ static int decode_evnt(struct dp83640_private *dp83640,
dp83640->edata.ns_lo = phy_txts->ns_lo;
}
+ if (ext_status) {
+ parsed = words + 2;
+ } else {
+ parsed = words + 1;
+ i = ((ests >> EVNT_NUM_SHIFT) & EVNT_NUM_MASK) - EXT_EVENT;
+ ext_status = exts_chan_to_edata(i);
+ }
+
event.type = PTP_CLOCK_EXTTS;
- event.index = 0;
event.timestamp = phy2txts(&dp83640->edata);
- ptp_clock_event(dp83640->clock->ptp_clock, &event);
+ for (i = 0; i < N_EXT_TS; i++) {
+ if (ext_status & exts_chan_to_edata(i)) {
+ event.index = i;
+ ptp_clock_event(dp83640->clock->ptp_clock, &event);
+ }
+ }
- words = ext_status ? words + 2 : words + 1;
- return words * sizeof(u16);
+ return parsed * sizeof(u16);
}
static void decode_rxts(struct dp83640_private *dp83640,
@@ -740,7 +837,7 @@ static void dp83640_clock_init(struct dp83640_clock *clock, struct mii_bus *bus)
clock->caps.max_adj = 1953124;
clock->caps.n_alarm = 0;
clock->caps.n_ext_ts = N_EXT_TS;
- clock->caps.n_per_out = 0;
+ clock->caps.n_per_out = 1;
clock->caps.pps = 0;
clock->caps.adjfreq = ptp_dp83640_adjfreq;
clock->caps.adjtime = ptp_dp83640_adjtime;
--
1.7.2.5
^ permalink raw reply related
* [PATCH net-next 2/3] net: introduce ptp one step time stamp mode for sync packets
From: Richard Cochran @ 2011-09-20 11:43 UTC (permalink / raw)
To: netdev; +Cc: David Miller
In-Reply-To: <cover.1316518332.git.richard.cochran@omicron.at>
The IEEE 1588 standard (PTP) has a provision for a "one step" mode, where
time stamps on outgoing event packets are inserted into the packet by the
hardware on the fly. This patch adds a new flag for the SIOCSHWTSTAMP
ioctl that lets user space programs request this mode.
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
include/linux/net_tstamp.h | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/include/linux/net_tstamp.h b/include/linux/net_tstamp.h
index a3b8546..3df0984 100644
--- a/include/linux/net_tstamp.h
+++ b/include/linux/net_tstamp.h
@@ -60,6 +60,15 @@ enum {
* before sending the packet.
*/
HWTSTAMP_TX_ON,
+
+ /*
+ * Enables time stamping for outgoing packets just as
+ * HWTSTAMP_TX_ON does, but also enables time stamp insertion
+ * directly into Sync packets. In this case, transmitted Sync
+ * packets will not received a time stamp via the socket error
+ * queue.
+ */
+ HWTSTAMP_TX_ONESTEP_SYNC,
};
/* possible values for hwtstamp_config->rx_filter */
--
1.7.2.5
^ permalink raw reply related
* [PATCH net-next 3/3] dp83640: add time stamp insertion for sync messages
From: Richard Cochran @ 2011-09-20 11:43 UTC (permalink / raw)
To: netdev; +Cc: David Miller
In-Reply-To: <cover.1316518332.git.richard.cochran@omicron.at>
This commit adds one step support to the phyter. When enabled, the
hardware does not provide time stamps for transmitted sync messages but
instead inserts the stamp into the outgoing packet.
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
drivers/net/phy/dp83640.c | 70 ++++++++++++++++++++++++++++++++++++--------
1 files changed, 57 insertions(+), 13 deletions(-)
diff --git a/drivers/net/phy/dp83640.c b/drivers/net/phy/dp83640.c
index d3c6a2e..c588a16 100644
--- a/drivers/net/phy/dp83640.c
+++ b/drivers/net/phy/dp83640.c
@@ -761,6 +761,41 @@ static void decode_status_frame(struct dp83640_private *dp83640,
}
}
+static int is_sync(struct sk_buff *skb, int type)
+{
+ u8 *data = skb->data, *msgtype;
+ unsigned int offset = 0;
+
+ switch (type) {
+ case PTP_CLASS_V1_IPV4:
+ case PTP_CLASS_V2_IPV4:
+ offset = ETH_HLEN + IPV4_HLEN(data) + UDP_HLEN;
+ break;
+ case PTP_CLASS_V1_IPV6:
+ case PTP_CLASS_V2_IPV6:
+ offset = OFF_PTP6;
+ break;
+ case PTP_CLASS_V2_L2:
+ offset = ETH_HLEN;
+ break;
+ case PTP_CLASS_V2_VLAN:
+ offset = ETH_HLEN + VLAN_HLEN;
+ break;
+ default:
+ return 0;
+ }
+
+ if (type & PTP_CLASS_V1)
+ offset += OFF_PTP_CONTROL;
+
+ if (skb->len < offset + 1)
+ return 0;
+
+ msgtype = data + offset;
+
+ return (*msgtype & 0xf) == 0;
+}
+
static int match(struct sk_buff *skb, unsigned int type, struct rxts *rxts)
{
u16 *seqid;
@@ -1010,16 +1045,10 @@ static int dp83640_hwtstamp(struct phy_device *phydev, struct ifreq *ifr)
if (cfg.flags) /* reserved for future extensions */
return -EINVAL;
- switch (cfg.tx_type) {
- case HWTSTAMP_TX_OFF:
- dp83640->hwts_tx_en = 0;
- break;
- case HWTSTAMP_TX_ON:
- dp83640->hwts_tx_en = 1;
- break;
- default:
+ if (cfg.tx_type < 0 || cfg.tx_type > HWTSTAMP_TX_ONESTEP_SYNC)
return -ERANGE;
- }
+
+ dp83640->hwts_tx_en = cfg.tx_type;
switch (cfg.rx_filter) {
case HWTSTAMP_FILTER_NONE:
@@ -1074,6 +1103,9 @@ static int dp83640_hwtstamp(struct phy_device *phydev, struct ifreq *ifr)
if (dp83640->hwts_tx_en)
txcfg0 |= TX_TS_EN;
+ if (dp83640->hwts_tx_en == HWTSTAMP_TX_ONESTEP_SYNC)
+ txcfg0 |= SYNC_1STEP | CHK_1STEP;
+
if (dp83640->hwts_rx_en)
rxcfg0 |= RX_TS_EN;
@@ -1156,12 +1188,24 @@ static void dp83640_txtstamp(struct phy_device *phydev,
{
struct dp83640_private *dp83640 = phydev->priv;
- if (!dp83640->hwts_tx_en) {
+ switch (dp83640->hwts_tx_en) {
+
+ case HWTSTAMP_TX_ONESTEP_SYNC:
+ if (is_sync(skb, type)) {
+ kfree_skb(skb);
+ return;
+ }
+ /* fall through */
+ case HWTSTAMP_TX_ON:
+ skb_queue_tail(&dp83640->tx_queue, skb);
+ schedule_work(&dp83640->ts_work);
+ break;
+
+ case HWTSTAMP_TX_OFF:
+ default:
kfree_skb(skb);
- return;
+ break;
}
- skb_queue_tail(&dp83640->tx_queue, skb);
- schedule_work(&dp83640->ts_work);
}
static struct phy_driver dp83640_driver = {
--
1.7.2.5
^ permalink raw reply related
* I Need Your Assistance
From: Mr Ahmed Hassan @ 2011-09-20 11:53 UTC (permalink / raw)
Dear Beloved,
I Mr Ahmed Hassan,a Business merchant who is diagnosed with
"Esophageal Cancer"
which
defiled all forms of medical treatment and i have cash deposit of Twenty One
million dollars ($21,000,000,00) that I have with a finance Company abroad,i
need someone to stand as a benefactor,if you are interested indicate your
interest.and i will give you the full details
^ permalink raw reply
* Re: [PATCH 0/2] SUNRPC: pipefs virtualization
From: Stanislav Kinsbursky @ 2011-09-20 12:13 UTC (permalink / raw)
To: Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org
Cc: linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Pavel Emelianov, neilb-l3A5Bk7waGM@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org
In-Reply-To: <20110912141633.6261.72180.stgit-bi+AKbBUZKagILUCTcTcHdKyNwTtLsGr@public.gmane.org>
Probably, holding mount point of network namespace is not a good solution.
There is another one. But I really hope for discussion of it.
RPC pipefs can be virtualized in the way like sysfs done.
But the main problem here is that currently we have only one RPC pipefs mount
point (superblock, root) for all.
New mount point can be created per every pipefs mount call. We can even have
some shared privates on dentries with the same name, like sysfs does (but I
don't see any good reason for this).
But with many mount points we have a problem with RPC pipes creation. I.e. we
have to find proper mount point for current network namespace, which is required
for vfs_path_lookup(), which is done prior to pipe creation.
And thus we have to store this per-netns mount points somewhere. It could be
some static variable. But we have to implement search function for them.
This approach can hide all pipefs virtualization from it's users. But it's still
look ugly from my pow.
Maybe, somebody have suggest better solution for this problem?
12.09.2011 18:19, Stanislav Kinsbursky пишет:
> This patch set is a part of further RPC layer virtualization and it's aim is to
> make RPC pipefs mount creation and destruction per network namespace context.
> It moves RPC pipefs internal data to sunrpc_net instance of network namespace
> context.
> With this patch set all calls to pipefs infrastructure are performed with
> "&init_net" except rpc_new_client() and rpc_setup_pipedir() functions (but they
> still passes pointer to "init_net" by current design).
> This "init_net" pointer will be replaced later with NFS virtualization.
>
> The following series consists of:
>
> ---
>
> Stanislav Kinsbursky (2):
> SUNRPC: make rpc pipefs mount per network namespace
> SUNRPC: RPC pipefs virtualization
>
>
> fs/nfs/blocklayout/blocklayout.c | 2 +-
> fs/nfs/cache_lib.c | 7 ++++---
> include/linux/sunrpc/rpc_pipe_fs.h | 4 ++--
> net/sunrpc/clnt.c | 8 ++++----
> net/sunrpc/netns.h | 3 +++
> net/sunrpc/rpc_pipe.c | 23 +++++++++++++++--------
> 6 files changed, 29 insertions(+), 18 deletions(-)
>
--
Best regards,
Stanislav Kinsbursky
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 1/8] SUNRPC: introduce helpers for reference counted rpcbind clients
From: Bryan Schumaker @ 2011-09-20 13:05 UTC (permalink / raw)
To: Stanislav Kinsbursky
Cc: Trond.Myklebust, linux-nfs, xemul, neilb, netdev, linux-kernel,
bfields, davem
In-Reply-To: <20110920101341.9861.51453.stgit@localhost6.localdomain6>
On 09/20/2011 06:13 AM, Stanislav Kinsbursky wrote:
> This helpers will be used for dynamical creation and destruction of rpcbind
> clients.
> Variable rpcb_users is actually a counter of lauched RPC services. If rpcbind
> clients has been created already, then we just increase rpcb_users.
>
> Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
>
> ---
> net/sunrpc/rpcb_clnt.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 50 insertions(+), 0 deletions(-)
>
> diff --git a/net/sunrpc/rpcb_clnt.c b/net/sunrpc/rpcb_clnt.c
> index e45d2fb..8724780 100644
> --- a/net/sunrpc/rpcb_clnt.c
> +++ b/net/sunrpc/rpcb_clnt.c
> @@ -114,6 +114,9 @@ static struct rpc_program rpcb_program;
> static struct rpc_clnt * rpcb_local_clnt;
> static struct rpc_clnt * rpcb_local_clnt4;
>
> +DEFINE_SPINLOCK(rpcb_clnt_lock);
> +unsigned int rpcb_users;
> +
> struct rpcbind_args {
> struct rpc_xprt * r_xprt;
>
> @@ -161,6 +164,53 @@ static void rpcb_map_release(void *data)
> kfree(map);
> }
>
> +static int rpcb_get_local(void)
> +{
> + spin_lock(&rpcb_clnt_lock);
> + if (rpcb_users)
> + rpcb_users++;
> + spin_unlock(&rpcb_clnt_lock);
> +
> + return rpcb_users;
^^^^^^^^^^^^^^^^^^
Is it safe to use this variable outside of the rpcb_clnt_lock?
> +}
> +
> +void rpcb_put_local(void)
> +{
> + struct rpc_clnt *clnt = rpcb_local_clnt;
> + struct rpc_clnt *clnt4 = rpcb_local_clnt4;
> + int shutdown;
> +
> + spin_lock(&rpcb_clnt_lock);
> + if (--rpcb_users == 0) {
> + rpcb_local_clnt = NULL;
> + rpcb_local_clnt4 = NULL;
> + }
> + shutdown = !rpcb_users;
> + spin_unlock(&rpcb_clnt_lock);
> +
> + if (shutdown) {
> + /*
> + * cleanup_rpcb_clnt - remove xprtsock's sysctls, unregister
> + */
> + if (clnt4)
> + rpc_shutdown_client(clnt4);
> + if (clnt)
> + rpc_shutdown_client(clnt);
> + }
> + return;
> +}
> +
> +static void rpcb_set_local(struct rpc_clnt *clnt, struct rpc_clnt *clnt4)
> +{
> + /* Protected by rpcb_create_local_mutex */
> + rpcb_local_clnt = clnt;
> + rpcb_local_clnt4 = clnt4;
> + rpcb_users++;
> + dprintk("RPC: created new rpcb local clients (rpcb_local_clnt: "
> + "%p, rpcb_local_clnt4: %p)\n", rpcb_local_clnt,
> + rpcb_local_clnt4);
> +}
> +
> /*
> * Returns zero on success, otherwise a negative errno value
> * is returned.
>
> --
> 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
^ permalink raw reply
* RE: [PATCH v4 1/8] SUNRPC: introduce helpers for reference counted rpcbind clients
From: Myklebust, Trond @ 2011-09-20 13:15 UTC (permalink / raw)
To: Schumaker, Bryan, Stanislav Kinsbursky
Cc: linux-nfs, xemul, neilb, netdev, linux-kernel, bfields, davem
In-Reply-To: <4E788F8C.20103@netapp.com>
> -----Original Message-----
> From: Schumaker, Bryan
> Sent: Tuesday, September 20, 2011 9:05 AM
> To: Stanislav Kinsbursky
> Cc: Myklebust, Trond; linux-nfs@vger.kernel.org; xemul@parallels.com;
> neilb@suse.de; netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> bfields@fieldses.org; davem@davemloft.net
> Subject: Re: [PATCH v4 1/8] SUNRPC: introduce helpers for reference
> counted rpcbind clients
>
> On 09/20/2011 06:13 AM, Stanislav Kinsbursky wrote:
> > This helpers will be used for dynamical creation and destruction of
> > rpcbind clients.
> > Variable rpcb_users is actually a counter of lauched RPC services. If
> > rpcbind clients has been created already, then we just increase rpcb_users.
> >
> > Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
> >
> > ---
> > net/sunrpc/rpcb_clnt.c | 50
> ++++++++++++++++++++++++++++++++++++++++++++++++
> > 1 files changed, 50 insertions(+), 0 deletions(-)
> >
> > diff --git a/net/sunrpc/rpcb_clnt.c b/net/sunrpc/rpcb_clnt.c index
> > e45d2fb..8724780 100644
> > --- a/net/sunrpc/rpcb_clnt.c
> > +++ b/net/sunrpc/rpcb_clnt.c
> > @@ -114,6 +114,9 @@ static struct rpc_program rpcb_program;
> > static struct rpc_clnt * rpcb_local_clnt;
> > static struct rpc_clnt * rpcb_local_clnt4;
> >
> > +DEFINE_SPINLOCK(rpcb_clnt_lock);
> > +unsigned int rpcb_users;
> > +
> > struct rpcbind_args {
> > struct rpc_xprt * r_xprt;
> >
> > @@ -161,6 +164,53 @@ static void rpcb_map_release(void *data)
> > kfree(map);
> > }
> >
> > +static int rpcb_get_local(void)
> > +{
> > + spin_lock(&rpcb_clnt_lock);
> > + if (rpcb_users)
> > + rpcb_users++;
> > + spin_unlock(&rpcb_clnt_lock);
> > +
> > + return rpcb_users;
> ^^^^^^^^^^^^^^^^^^
> Is it safe to use this variable outside of the rpcb_clnt_lock?
>
Nope. If rpcb_users was zero in the protected section above, nothing guarantees that it will still be zero here, and so the caller may get the (wrong) impression that the counter was incremented.
> > +}
> > +
> > +void rpcb_put_local(void)
> > +{
> > + struct rpc_clnt *clnt = rpcb_local_clnt;
> > + struct rpc_clnt *clnt4 = rpcb_local_clnt4;
> > + int shutdown;
> > +
> > + spin_lock(&rpcb_clnt_lock);
> > + if (--rpcb_users == 0) {
> > + rpcb_local_clnt = NULL;
> > + rpcb_local_clnt4 = NULL;
> > + }
> > + shutdown = !rpcb_users;
> > + spin_unlock(&rpcb_clnt_lock);
> > +
> > + if (shutdown) {
> > + /*
> > + * cleanup_rpcb_clnt - remove xprtsock's sysctls, unregister
> > + */
> > + if (clnt4)
> > + rpc_shutdown_client(clnt4);
> > + if (clnt)
> > + rpc_shutdown_client(clnt);
> > + }
> > + return;
> > +}
> > +
> > +static void rpcb_set_local(struct rpc_clnt *clnt, struct rpc_clnt
> > +*clnt4) {
> > + /* Protected by rpcb_create_local_mutex */
Doesn't it need to be protected by rpcb_clnt_lock too?
> > + rpcb_local_clnt = clnt;
> > + rpcb_local_clnt4 = clnt4;
> > + rpcb_users++;
^^^^^^^^^^^^^^^^^^^
> > + dprintk("RPC: created new rpcb local clients (rpcb_local_clnt: "
> > + "%p, rpcb_local_clnt4: %p)\n", rpcb_local_clnt,
> > + rpcb_local_clnt4);
> > +}
> > +
> > /*
> > * Returns zero on success, otherwise a negative errno value
> > * is returned.
> >
> > --
> > 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
^ permalink raw reply
* Re: discrepancy in ip(7) wrt. IP DF flag for UDP sockets
From: Benjamin Poirier @ 2011-09-20 13:29 UTC (permalink / raw)
To: Michael Kerrisk
Cc: Neil Horman, linux-man-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAKgNAkgWRdkxgTXNnMi4PVGGsOd-8EHF1siBrk-Bj=rnYenVmQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 11-09-20 08:14, Michael Kerrisk wrote:
> Hello Benjamin, Neil,
>
> On Mon, Sep 19, 2011 at 3:03 PM, Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org> wrote:
> > On Mon, Sep 19, 2011 at 08:19:40AM -0400, Benjamin Poirier wrote:
> >> Hi,
> >>
> >> I noticed what appears to be a discrepancy between the ip(7) man page
> >> and the kernel code with regards to the IP DF flag for UDP sockets.
> >>
> >> The man page says that "The don't-fragment flag is set on all outgoing
> >> datagrams" and that the ip_no_pmtu_disc sysctl affects only SOCK_STREAM
> >> sockets. This is quickly disproved by doing:
> >> echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc
> >> firing up netcat and looking at a few outgoing udp packets in wireshark
> >> (they don't have the DF flag set).
>
> Could you describe the required change in terms of how the man page
> text should look--i.e., rewrite the passage as you think it should
> look?
How about changing it to:
IP_MTU_DISCOVER (since Linux 2.2)
Set or receive the Path MTU Discovery setting for a socket. When
enabled, the don't-fragment flag is set on all outgoing packets.
Linux will perform Path MTU Discovery as defined in RFC 1191 on
SOCK_STREAM sockets. For non-SOCK_STREAM sockets, it is the
user's responsibility to packetize the data in MTU sized chunks
and to do the retransmits if necessary. The kernel will reject
(with EMSGSIZE) datagrams that are bigger than the known path
MTU. The system-wide default is controlled by the
/proc/sys/net/ipv4/ip_no_pmtu_disc file.
Path MTU discovery flags Meaning
[...]
There are some differences between _DO and _WANT that are glossed over
in this description, but I suppose there's only so much detail you can
put in...
Thanks,
-Ben
>
> Thanks,
>
> Michael
>
>
> >> 1) in the words of `man 7 ip`:
> >> IP_MTU_DISCOVER (since Linux 2.2)
> >> Set or receive the Path MTU Discovery setting for a socket.
> >> When enabled, Linux will perform Path MTU Discovery as defined
> >> in RFC 1191 on this socket. The don't-fragment flag is set on
> >> all outgoing datagrams. The system-wide default is controlled
> >> by the /proc/sys/net/ipv4/ip_no_pmtu_disc file for SOCK_STREAM
> >> sockets, and disabled on all others.
> >>
> >> This is the text present in the latest version of the online manpages,
> >> http://webcache.googleusercontent.com/search?q=cache:http://www.kernel.org/doc/man-pages/reporting_bugs.html&ie=UTF-8
> >>
> >> 2) in net/ipv4/af_inet.c:inet_create():
> >> if (ipv4_config.no_pmtu_disc)
> >> inet->pmtudisc = IP_PMTUDISC_DONT;
> >> else
> >> inet->pmtudisc = IP_PMTUDISC_WANT;
> >>
> >> and pmtudisc is left alone from there on for UDP sockets.
> >>
> >> What should be adjusted, the man page or the code?
> >>
> > The man page is wrong I think
> >
> > By my read, the code:
> > 1) Affects UDP and TCP the same way (which makes sense to me)
> >
> > 2) Is doing exactly what you asked it to, since you set no_pmtu_disc, which
> > means the stack should be free to fragment a frame as it sees fit according to
> > the MTU metric of the route its traversing, hence the cleared DF bit in the
> > fraem.
> >
> > RFC 1191 can apply equally well to udp, as tcp, and is evident in that you can
> > set the per-socket option IP_MTU_DISCOVER to any of the 4 acceptible values
> > offered (DONT/WANT/DO/PROBE), so theres no reason the sysctl governing the
> > default value at creation shouldn't apply as well.
> > Neil
> >
> >
>
>
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 1/8] SUNRPC: introduce helpers for reference counted rpcbind clients
From: Stanislav Kinsbursky @ 2011-09-20 13:34 UTC (permalink / raw)
To: Myklebust, Trond
Cc: Schumaker, Bryan, linux-nfs@vger.kernel.org, Pavel Emelianov,
neilb@suse.de, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, bfields@fieldses.org,
davem@davemloft.net
In-Reply-To: <2E1EB2CF9ED1CB4AA966F0EB76EAB4430B47FD10@SACMVEXC2-PRD.hq.netapp.com>
20.09.2011 17:15, Myklebust, Trond пишет:
>> -----Original Message-----
>> From: Schumaker, Bryan
>> Sent: Tuesday, September 20, 2011 9:05 AM
>> To: Stanislav Kinsbursky
>> Cc: Myklebust, Trond; linux-nfs@vger.kernel.org; xemul@parallels.com;
>> neilb@suse.de; netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
>> bfields@fieldses.org; davem@davemloft.net
>> Subject: Re: [PATCH v4 1/8] SUNRPC: introduce helpers for reference
>> counted rpcbind clients
>>
>> On 09/20/2011 06:13 AM, Stanislav Kinsbursky wrote:
>>> This helpers will be used for dynamical creation and destruction of
>>> rpcbind clients.
>>> Variable rpcb_users is actually a counter of lauched RPC services. If
>>> rpcbind clients has been created already, then we just increase rpcb_users.
>>>
>>> Signed-off-by: Stanislav Kinsbursky<skinsbursky@parallels.com>
>>>
>>> ---
>>> net/sunrpc/rpcb_clnt.c | 50
>> ++++++++++++++++++++++++++++++++++++++++++++++++
>>> 1 files changed, 50 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/net/sunrpc/rpcb_clnt.c b/net/sunrpc/rpcb_clnt.c index
>>> e45d2fb..8724780 100644
>>> --- a/net/sunrpc/rpcb_clnt.c
>>> +++ b/net/sunrpc/rpcb_clnt.c
>>> @@ -114,6 +114,9 @@ static struct rpc_program rpcb_program;
>>> static struct rpc_clnt * rpcb_local_clnt;
>>> static struct rpc_clnt * rpcb_local_clnt4;
>>>
>>> +DEFINE_SPINLOCK(rpcb_clnt_lock);
>>> +unsigned int rpcb_users;
>>> +
>>> struct rpcbind_args {
>>> struct rpc_xprt * r_xprt;
>>>
>>> @@ -161,6 +164,53 @@ static void rpcb_map_release(void *data)
>>> kfree(map);
>>> }
>>>
>>> +static int rpcb_get_local(void)
>>> +{
>>> + spin_lock(&rpcb_clnt_lock);
>>> + if (rpcb_users)
>>> + rpcb_users++;
>>> + spin_unlock(&rpcb_clnt_lock);
>>> +
>>> + return rpcb_users;
>> ^^^^^^^^^^^^^^^^^^
>> Is it safe to use this variable outside of the rpcb_clnt_lock?
>>
> Nope. If rpcb_users was zero in the protected section above, nothing guarantees that it will still be zero here, and so the caller may get the (wrong) impression that the counter was incremented.
>
Yep, you right. Will fix this races.
>>> +}
>>> +
>>> +void rpcb_put_local(void)
>>> +{
>>> + struct rpc_clnt *clnt = rpcb_local_clnt;
>>> + struct rpc_clnt *clnt4 = rpcb_local_clnt4;
>>> + int shutdown;
>>> +
>>> + spin_lock(&rpcb_clnt_lock);
>>> + if (--rpcb_users == 0) {
>>> + rpcb_local_clnt = NULL;
>>> + rpcb_local_clnt4 = NULL;
>>> + }
>>> + shutdown = !rpcb_users;
>>> + spin_unlock(&rpcb_clnt_lock);
>>> +
>>> + if (shutdown) {
>>> + /*
>>> + * cleanup_rpcb_clnt - remove xprtsock's sysctls, unregister
>>> + */
>>> + if (clnt4)
>>> + rpc_shutdown_client(clnt4);
>>> + if (clnt)
>>> + rpc_shutdown_client(clnt);
>>> + }
>>> + return;
>>> +}
>>> +
>>> +static void rpcb_set_local(struct rpc_clnt *clnt, struct rpc_clnt
>>> +*clnt4) {
>>> + /* Protected by rpcb_create_local_mutex */
>
> Doesn't it need to be protected by rpcb_clnt_lock too?
>
Nope from my pow. It's protected by rpcb_create_local_mutex. I.e. no one will
change rpcb_users since it's zero. If it's non zero - we willn't get to
rpcb_set_local().
>>> + rpcb_local_clnt = clnt;
>>> + rpcb_local_clnt4 = clnt4;
>>> + rpcb_users++;
> ^^^^^^^^^^^^^^^^^^^
>
>>> + dprintk("RPC: created new rpcb local clients (rpcb_local_clnt: "
>>> + "%p, rpcb_local_clnt4: %p)\n", rpcb_local_clnt,
>>> + rpcb_local_clnt4);
>>> +}
>>> +
>>> /*
>>> * Returns zero on success, otherwise a negative errno value
>>> * is returned.
>>>
>>> --
>>> 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
>
> \x04�{.n�+�������+%��lzwm��b�맲��r��zX��\x19߲)���w*\x1fjg���\x1e�����ݢj/���z�ޖ��2�ޙ���&�)ߡ�a��\x7f��\x1e�G���h�\x0f�j:+v���w�٥
--
Best regards,
Stanislav Kinsbursky
^ permalink raw reply
* Re: discrepancy in ip(7) wrt. IP DF flag for UDP sockets
From: Neil Horman @ 2011-09-20 13:38 UTC (permalink / raw)
To: Benjamin Poirier
Cc: Michael Kerrisk, linux-man-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110920132954.GA23041-k/PPzeaMb74v2OKnPYDugg@public.gmane.org>
On Tue, Sep 20, 2011 at 09:29:54AM -0400, Benjamin Poirier wrote:
> On 11-09-20 08:14, Michael Kerrisk wrote:
> > Hello Benjamin, Neil,
> >
> > On Mon, Sep 19, 2011 at 3:03 PM, Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org> wrote:
> > > On Mon, Sep 19, 2011 at 08:19:40AM -0400, Benjamin Poirier wrote:
> > >> Hi,
> > >>
> > >> I noticed what appears to be a discrepancy between the ip(7) man page
> > >> and the kernel code with regards to the IP DF flag for UDP sockets.
> > >>
> > >> The man page says that "The don't-fragment flag is set on all outgoing
> > >> datagrams" and that the ip_no_pmtu_disc sysctl affects only SOCK_STREAM
> > >> sockets. This is quickly disproved by doing:
> > >> echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc
> > >> firing up netcat and looking at a few outgoing udp packets in wireshark
> > >> (they don't have the DF flag set).
> >
> > Could you describe the required change in terms of how the man page
> > text should look--i.e., rewrite the passage as you think it should
> > look?
>
> How about changing it to:
> IP_MTU_DISCOVER (since Linux 2.2)
> Set or receive the Path MTU Discovery setting for a socket. When
> enabled, the don't-fragment flag is set on all outgoing packets.
> Linux will perform Path MTU Discovery as defined in RFC 1191 on
> SOCK_STREAM sockets. For non-SOCK_STREAM sockets, it is the
> user's responsibility to packetize the data in MTU sized chunks
> and to do the retransmits if necessary. The kernel will reject
> (with EMSGSIZE) datagrams that are bigger than the known path
> MTU. The system-wide default is controlled by the
> /proc/sys/net/ipv4/ip_no_pmtu_disc file.
>
> Path MTU discovery flags Meaning
> [...]
>
> There are some differences between _DO and _WANT that are glossed over
> in this description, but I suppose there's only so much detail you can
> put in...
>
> Thanks,
> -Ben
>
Yeah, I think thats close, but its only the users responsibility to package
datagrams in mtu sized chunks if they force the dont fragment bit on. If they
go wtih the default, the stack will fragment a datagram is it sees fit according
to the mtu of the path it traverses
Neil
> >
> > Thanks,
> >
> > Michael
> >
> >
> > >> 1) in the words of `man 7 ip`:
> > >> IP_MTU_DISCOVER (since Linux 2.2)
> > >> Set or receive the Path MTU Discovery setting for a socket.
> > >> When enabled, Linux will perform Path MTU Discovery as defined
> > >> in RFC 1191 on this socket. The don't-fragment flag is set on
> > >> all outgoing datagrams. The system-wide default is controlled
> > >> by the /proc/sys/net/ipv4/ip_no_pmtu_disc file for SOCK_STREAM
> > >> sockets, and disabled on all others.
> > >>
> > >> This is the text present in the latest version of the online manpages,
> > >> http://webcache.googleusercontent.com/search?q=cache:http://www.kernel.org/doc/man-pages/reporting_bugs.html&ie=UTF-8
> > >>
> > >> 2) in net/ipv4/af_inet.c:inet_create():
> > >> if (ipv4_config.no_pmtu_disc)
> > >> inet->pmtudisc = IP_PMTUDISC_DONT;
> > >> else
> > >> inet->pmtudisc = IP_PMTUDISC_WANT;
> > >>
> > >> and pmtudisc is left alone from there on for UDP sockets.
> > >>
> > >> What should be adjusted, the man page or the code?
> > >>
> > > The man page is wrong I think
> > >
> > > By my read, the code:
> > > 1) Affects UDP and TCP the same way (which makes sense to me)
> > >
> > > 2) Is doing exactly what you asked it to, since you set no_pmtu_disc, which
> > > means the stack should be free to fragment a frame as it sees fit according to
> > > the MTU metric of the route its traversing, hence the cleared DF bit in the
> > > fraem.
> > >
> > > RFC 1191 can apply equally well to udp, as tcp, and is evident in that you can
> > > set the per-socket option IP_MTU_DISCOVER to any of the 4 acceptible values
> > > offered (DONT/WANT/DO/PROBE), so theres no reason the sysctl governing the
> > > default value at creation shouldn't apply as well.
> > > Neil
> > >
> > >
> >
> >
> >
> > --
> > Michael Kerrisk
> > Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> > Author of "The Linux Programming Interface"; http://man7.org/tlpi/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 1/8] SUNRPC: introduce helpers for reference counted rpcbind clients
From: Stanislav Kinsbursky @ 2011-09-20 13:49 UTC (permalink / raw)
To: Trond.Myklebust@netapp.com
Cc: linux-nfs@vger.kernel.org, Pavel Emelianov, neilb@suse.de,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
bfields@fieldses.org, davem@davemloft.net
In-Reply-To: <20110920101341.9861.51453.stgit@localhost6.localdomain6>
v5: fixed races with rpcb_users in rpcb_get_local()
This helpers will be used for dynamical creation and destruction of rpcbind
clients.
Variable rpcb_users is actually a counter of lauched RPC services. If rpcbind
clients has been created already, then we just increase rpcb_users.
Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
---
net/sunrpc/rpcb_clnt.c | 53 ++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/net/sunrpc/rpcb_clnt.c b/net/sunrpc/rpcb_clnt.c
index e45d2fb..5f4a406 100644
--- a/net/sunrpc/rpcb_clnt.c
+++ b/net/sunrpc/rpcb_clnt.c
@@ -114,6 +114,9 @@ static struct rpc_program rpcb_program;
static struct rpc_clnt * rpcb_local_clnt;
static struct rpc_clnt * rpcb_local_clnt4;
+DEFINE_SPINLOCK(rpcb_clnt_lock);
+unsigned int rpcb_users;
+
struct rpcbind_args {
struct rpc_xprt * r_xprt;
@@ -161,6 +164,56 @@ static void rpcb_map_release(void *data)
kfree(map);
}
+static int rpcb_get_local(void)
+{
+ int cnt;
+
+ spin_lock(&rpcb_clnt_lock);
+ if (rpcb_users)
+ rpcb_users++;
+ cnt = rpcb_users;
+ spin_unlock(&rpcb_clnt_lock);
+
+ return cnt;
+}
+
+void rpcb_put_local(void)
+{
+ struct rpc_clnt *clnt = rpcb_local_clnt;
+ struct rpc_clnt *clnt4 = rpcb_local_clnt4;
+ int shutdown;
+
+ spin_lock(&rpcb_clnt_lock);
+ if (--rpcb_users == 0) {
+ rpcb_local_clnt = NULL;
+ rpcb_local_clnt4 = NULL;
+ }
+ shutdown = !rpcb_users;
+ spin_unlock(&rpcb_clnt_lock);
+
+ if (shutdown) {
+ /*
+ * cleanup_rpcb_clnt - remove xprtsock's sysctls, unregister
+ */
+ if (clnt4)
+ rpc_shutdown_client(clnt4);
+ if (clnt)
+ rpc_shutdown_client(clnt);
+ }
+ return;
+}
+
+static void rpcb_set_local(struct rpc_clnt *clnt, struct rpc_clnt *clnt4)
+{
+ /* Protected by rpcb_create_local_mutex */
+ rpcb_local_clnt = clnt;
+ rpcb_local_clnt4 = clnt4;
+ rpcb_users++;
+ dprintk("RPC: created new rpcb local clients (rpcb_local_clnt: "
+ "%p, rpcb_local_clnt4: %p)\n", rpcb_local_clnt,
+ rpcb_local_clnt4);
+}
+
/*
* Returns zero on success, otherwise a negative errno value
* is returned.
^ permalink raw reply related
* Re: discrepancy in ip(7) wrt. IP DF flag for UDP sockets
From: Benjamin Poirier @ 2011-09-20 14:12 UTC (permalink / raw)
To: Neil Horman
Cc: Michael Kerrisk, linux-man-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110920133837.GA16323-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
On 11-09-20 09:38, Neil Horman wrote:
> On Tue, Sep 20, 2011 at 09:29:54AM -0400, Benjamin Poirier wrote:
> > On 11-09-20 08:14, Michael Kerrisk wrote:
> > > Hello Benjamin, Neil,
> > >
[snip]
> > >
> > > Could you describe the required change in terms of how the man page
> > > text should look--i.e., rewrite the passage as you think it should
> > > look?
> >
> > How about changing it to:
> > IP_MTU_DISCOVER (since Linux 2.2)
> > Set or receive the Path MTU Discovery setting for a socket. When
> > enabled, the don't-fragment flag is set on all outgoing packets.
> > Linux will perform Path MTU Discovery as defined in RFC 1191 on
> > SOCK_STREAM sockets. For non-SOCK_STREAM sockets, it is the
> > user's responsibility to packetize the data in MTU sized chunks
> > and to do the retransmits if necessary. The kernel will reject
> > (with EMSGSIZE) datagrams that are bigger than the known path
> > MTU. The system-wide default is controlled by the
> > /proc/sys/net/ipv4/ip_no_pmtu_disc file.
> >
> > Path MTU discovery flags Meaning
> > [...]
> >
> > There are some differences between _DO and _WANT that are glossed over
> > in this description, but I suppose there's only so much detail you can
> > put in...
> >
> > Thanks,
> > -Ben
> >
> Yeah, I think thats close, but its only the users responsibility to package
> datagrams in mtu sized chunks if they force the dont fragment bit on. If they
> go wtih the default, the stack will fragment a datagram is it sees fit according
> to the mtu of the path it traverses
Exactly. To get into this level of detail, I think we have to mention
the option value, not just enabled/disabled. Let's try like this:
IP_MTU_DISCOVER (since Linux 2.2)
Set or receive the Path MTU Discovery setting for a socket. When
enabled, Linux will perform Path MTU Discovery as defined in RFC
1191 on SOCK_STREAM sockets. For non-SOCK_STREAM sockets,
IP_PMTUDISC_DO forces the don't-fragment flag to be set on all
outgoing packets. It is the user's responsibility to packetize
the data in MTU sized chunks and to do the retransmits if
necessary. The kernel will reject (with EMSGSIZE) datagrams
that are bigger than the known path MTU. IP_PMTUDISC_WANT will
fragment a datagram if needed according to the path MTU or will
set the don't-fragment flag otherwise.
The system-wide default can be toggled between IP_PMTUDISC_WANT
and IP_PMTUDISC_DONT by writting to the
/proc/sys/net/ipv4/ip_no_pmtu_disc file.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH v4 1/8] SUNRPC: introduce helpers for reference counted rpcbind clients
From: Myklebust, Trond @ 2011-09-20 14:14 UTC (permalink / raw)
To: Stanislav Kinsbursky
Cc: Schumaker, Bryan, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
Pavel Emelianov, neilb-l3A5Bk7waGM, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bfields-uC3wQj2KruNg9hUCZPvPmw, davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <4E789679.1060601-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
> -----Original Message-----
> From: Stanislav Kinsbursky [mailto:skinsbursky@parallels.com]
> Sent: Tuesday, September 20, 2011 9:35 AM
> To: Myklebust, Trond
> Cc: Schumaker, Bryan; linux-nfs@vger.kernel.org; Pavel Emelianov;
> neilb@suse.de; netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> bfields@fieldses.org; davem@davemloft.net
> Subject: Re: [PATCH v4 1/8] SUNRPC: introduce helpers for reference
> counted rpcbind clients
>
> 20.09.2011 17:15, Myklebust, Trond пишет:
> >> -----Original Message-----
> >> From: Schumaker, Bryan
> >> Sent: Tuesday, September 20, 2011 9:05 AM
> >> To: Stanislav Kinsbursky
> >> Cc: Myklebust, Trond; linux-nfs@vger.kernel.org; xemul@parallels.com;
> >> neilb@suse.de; netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> >> bfields@fieldses.org; davem@davemloft.net
> >> Subject: Re: [PATCH v4 1/8] SUNRPC: introduce helpers for reference
> >> counted rpcbind clients
> >>
> >> On 09/20/2011 06:13 AM, Stanislav Kinsbursky wrote:
> >>> This helpers will be used for dynamical creation and destruction of
> >>> rpcbind clients.
> >>> Variable rpcb_users is actually a counter of lauched RPC services.
> >>> If rpcbind clients has been created already, then we just increase
> rpcb_users.
> >>>
> >>> Signed-off-by: Stanislav Kinsbursky<skinsbursky@parallels.com>
> >>>
> >>> ---
> >>> net/sunrpc/rpcb_clnt.c | 50
> >> ++++++++++++++++++++++++++++++++++++++++++++++++
> >>> 1 files changed, 50 insertions(+), 0 deletions(-)
> >>>
> >>> diff --git a/net/sunrpc/rpcb_clnt.c b/net/sunrpc/rpcb_clnt.c index
> >>> e45d2fb..8724780 100644
> >>> --- a/net/sunrpc/rpcb_clnt.c
> >>> +++ b/net/sunrpc/rpcb_clnt.c
> >>> @@ -114,6 +114,9 @@ static struct rpc_program rpcb_program;
> >>> static struct rpc_clnt * rpcb_local_clnt;
> >>> static struct rpc_clnt * rpcb_local_clnt4;
> >>>
> >>> +DEFINE_SPINLOCK(rpcb_clnt_lock);
> >>> +unsigned int rpcb_users;
> >>> +
> >>> struct rpcbind_args {
> >>> struct rpc_xprt * r_xprt;
> >>>
> >>> @@ -161,6 +164,53 @@ static void rpcb_map_release(void *data)
> >>> kfree(map);
> >>> }
> >>>
> >>> +static int rpcb_get_local(void)
> >>> +{
> >>> + spin_lock(&rpcb_clnt_lock);
> >>> + if (rpcb_users)
> >>> + rpcb_users++;
> >>> + spin_unlock(&rpcb_clnt_lock);
> >>> +
> >>> + return rpcb_users;
> >> ^^^^^^^^^^^^^^^^^^
> >> Is it safe to use this variable outside of the rpcb_clnt_lock?
> >>
> > Nope. If rpcb_users was zero in the protected section above, nothing
> guarantees that it will still be zero here, and so the caller may get the (wrong)
> impression that the counter was incremented.
> >
>
> Yep, you right. Will fix this races.
>
> >>> +}
> >>> +
> >>> +void rpcb_put_local(void)
> >>> +{
> >>> + struct rpc_clnt *clnt = rpcb_local_clnt;
> >>> + struct rpc_clnt *clnt4 = rpcb_local_clnt4;
> >>> + int shutdown;
> >>> +
> >>> + spin_lock(&rpcb_clnt_lock);
> >>> + if (--rpcb_users == 0) {
> >>> + rpcb_local_clnt = NULL;
> >>> + rpcb_local_clnt4 = NULL;
> >>> + }
> >>> + shutdown = !rpcb_users;
> >>> + spin_unlock(&rpcb_clnt_lock);
> >>> +
> >>> + if (shutdown) {
> >>> + /*
> >>> + * cleanup_rpcb_clnt - remove xprtsock's sysctls, unregister
> >>> + */
> >>> + if (clnt4)
> >>> + rpc_shutdown_client(clnt4);
> >>> + if (clnt)
> >>> + rpc_shutdown_client(clnt);
> >>> + }
> >>> + return;
> >>> +}
> >>> +
> >>> +static void rpcb_set_local(struct rpc_clnt *clnt, struct rpc_clnt
> >>> +*clnt4) {
> >>> + /* Protected by rpcb_create_local_mutex */
> >
> > Doesn't it need to be protected by rpcb_clnt_lock too?
> >
>
> Nope from my pow. It's protected by rpcb_create_local_mutex. I.e. no one
> will change rpcb_users since it's zero. If it's non zero - we willn't get to
> rpcb_set_local().
OK, so you are saying that the rpcb_users++ below could be replaced by rpcb_users=1?
In that case, don't you need a smp_wmb() between the setting of rpcb_local_clnt/4 and the setting of rpcb_users? Otherwise, how do you guarantee that rpcb_users != 0 implies rpbc_local_clnt/4 != NULL?
> >>> + rpcb_local_clnt = clnt;
> >>> + rpcb_local_clnt4 = clnt4;
> >>> + rpcb_users++;
> > ^^^^^^^^^^^^^^^^^^^
> >
> >>> + dprintk("RPC: created new rpcb local clients (rpcb_local_clnt: "
> >>> + "%p, rpcb_local_clnt4: %p)\n", rpcb_local_clnt,
> >>> + rpcb_local_clnt4);
> >>> +}
> >>> +
^ permalink raw reply
* Re: [PATCH v5 1/8] SUNRPC: introduce helpers for reference counted rpcbind clients
From: Jeff Layton @ 2011-09-20 14:24 UTC (permalink / raw)
To: Stanislav Kinsbursky
Cc: Trond.Myklebust@netapp.com, linux-nfs@vger.kernel.org,
Pavel Emelianov, neilb@suse.de, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, bfields@fieldses.org,
davem@davemloft.net
In-Reply-To: <4E7899E7.9090809@parallels.com>
On Tue, 20 Sep 2011 17:49:27 +0400
Stanislav Kinsbursky <skinsbursky@parallels.com> wrote:
> v5: fixed races with rpcb_users in rpcb_get_local()
>
> This helpers will be used for dynamical creation and destruction of rpcbind
> clients.
> Variable rpcb_users is actually a counter of lauched RPC services. If rpcbind
> clients has been created already, then we just increase rpcb_users.
>
> Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
>
> ---
> net/sunrpc/rpcb_clnt.c | 53 ++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 53 insertions(+), 0 deletions(-)
>
> diff --git a/net/sunrpc/rpcb_clnt.c b/net/sunrpc/rpcb_clnt.c
> index e45d2fb..5f4a406 100644
> --- a/net/sunrpc/rpcb_clnt.c
> +++ b/net/sunrpc/rpcb_clnt.c
> @@ -114,6 +114,9 @@ static struct rpc_program rpcb_program;
> static struct rpc_clnt * rpcb_local_clnt;
> static struct rpc_clnt * rpcb_local_clnt4;
> +DEFINE_SPINLOCK(rpcb_clnt_lock);
> +unsigned int rpcb_users;
> +
> struct rpcbind_args {
> struct rpc_xprt * r_xprt;
> @@ -161,6 +164,56 @@ static void rpcb_map_release(void *data)
> kfree(map);
> }
> +static int rpcb_get_local(void)
> +{
> + int cnt;
> +
> + spin_lock(&rpcb_clnt_lock);
> + if (rpcb_users)
> + rpcb_users++;
> + cnt = rpcb_users;
> + spin_unlock(&rpcb_clnt_lock);
> +
> + return cnt;
> +}
> +
> +void rpcb_put_local(void)
> +{
> + struct rpc_clnt *clnt = rpcb_local_clnt;
> + struct rpc_clnt *clnt4 = rpcb_local_clnt4;
> + int shutdown;
> +
> + spin_lock(&rpcb_clnt_lock);
> + if (--rpcb_users == 0) {
> + rpcb_local_clnt = NULL;
> + rpcb_local_clnt4 = NULL;
> + }
In the function below, you mention that the above pointers are
protected by rpcb_create_local_mutex, but it looks like they get reset
here without that being held?
Might it be simpler to just protect rpcb_users with the
rpcb_create_local_mutex and ensure that it's held whenever you call one
of these routines? None of these are codepaths are particularly hot.
> + shutdown = !rpcb_users;
> + spin_unlock(&rpcb_clnt_lock);
> +
> + if (shutdown) {
> + /*
> + * cleanup_rpcb_clnt - remove xprtsock's sysctls, unregister
> + */
> + if (clnt4)
> + rpc_shutdown_client(clnt4);
> + if (clnt)
> + rpc_shutdown_client(clnt);
> + }
> + return;
> +}
> +
> +static void rpcb_set_local(struct rpc_clnt *clnt, struct rpc_clnt *clnt4)
> +{
> + /* Protected by rpcb_create_local_mutex */
> + rpcb_local_clnt = clnt;
> + rpcb_local_clnt4 = clnt4;
> + rpcb_users++;
> + dprintk("RPC: created new rpcb local clients (rpcb_local_clnt: "
> + "%p, rpcb_local_clnt4: %p)\n", rpcb_local_clnt,
> + rpcb_local_clnt4);
> +}
> +
> /*
> * Returns zero on success, otherwise a negative errno value
> * is returned.
> --
> 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
--
Jeff Layton <jlayton@redhat.com>
^ permalink raw reply
* Re: pull request: wireless-next 2011-09-19
From: John W. Linville @ 2011-09-20 14:18 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev
In-Reply-To: <20110919203639.GF2608@tuxdriver.com>
On Mon, Sep 19, 2011 at 04:36:39PM -0400, John W. Linville wrote:
> David,
>
> Here is another big batch of updates intended for 3.2 -- still
> clearing-out the backlog...
>
> This round includes lots of updates to ath9k, b43, iwlagn, and rt2x00.
> Some cleanups go to mac80211, along with a number of mesh-mode fixes
> from Javier.
>
> Please let me know if there are problems!
>
> Thanks,
>
> John
>
> ---
>
> The following changes since commit 765cf9976e937f1cfe9159bf4534967c8bf8eb6d:
>
> tcp: md5: remove one indirection level in tcp_md5sig_pool (2011-09-17 01:15:46 -0400)
>
> are available in the git repository at:
> ssh://infradead/~/public_git/wireless-next.git for-davem
This is also available at this URL -- sorry about the ssh URL (with
an alias at that)!
git://git.infradead.org/users/linville/wireless-next.git for-davem
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: discrepancy in ip(7) wrt. IP DF flag for UDP sockets
From: Neil Horman @ 2011-09-20 14:31 UTC (permalink / raw)
To: Benjamin Poirier
Cc: Michael Kerrisk, linux-man-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110920141234.GA23164-k/PPzeaMb74v2OKnPYDugg@public.gmane.org>
On Tue, Sep 20, 2011 at 10:12:34AM -0400, Benjamin Poirier wrote:
> On 11-09-20 09:38, Neil Horman wrote:
> > On Tue, Sep 20, 2011 at 09:29:54AM -0400, Benjamin Poirier wrote:
> > > On 11-09-20 08:14, Michael Kerrisk wrote:
> > > > Hello Benjamin, Neil,
> > > >
> [snip]
> > > >
> > > > Could you describe the required change in terms of how the man page
> > > > text should look--i.e., rewrite the passage as you think it should
> > > > look?
> > >
> > > How about changing it to:
> > > IP_MTU_DISCOVER (since Linux 2.2)
> > > Set or receive the Path MTU Discovery setting for a socket. When
> > > enabled, the don't-fragment flag is set on all outgoing packets.
> > > Linux will perform Path MTU Discovery as defined in RFC 1191 on
> > > SOCK_STREAM sockets. For non-SOCK_STREAM sockets, it is the
> > > user's responsibility to packetize the data in MTU sized chunks
> > > and to do the retransmits if necessary. The kernel will reject
> > > (with EMSGSIZE) datagrams that are bigger than the known path
> > > MTU. The system-wide default is controlled by the
> > > /proc/sys/net/ipv4/ip_no_pmtu_disc file.
> > >
> > > Path MTU discovery flags Meaning
> > > [...]
> > >
> > > There are some differences between _DO and _WANT that are glossed over
> > > in this description, but I suppose there's only so much detail you can
> > > put in...
> > >
> > > Thanks,
> > > -Ben
> > >
> > Yeah, I think thats close, but its only the users responsibility to package
> > datagrams in mtu sized chunks if they force the dont fragment bit on. If they
> > go wtih the default, the stack will fragment a datagram is it sees fit according
> > to the mtu of the path it traverses
>
> Exactly. To get into this level of detail, I think we have to mention
> the option value, not just enabled/disabled. Let's try like this:
>
> IP_MTU_DISCOVER (since Linux 2.2)
> Set or receive the Path MTU Discovery setting for a socket. When
> enabled, Linux will perform Path MTU Discovery as defined in RFC
> 1191 on SOCK_STREAM sockets. For non-SOCK_STREAM sockets,
> IP_PMTUDISC_DO forces the don't-fragment flag to be set on all
> outgoing packets. It is the user's responsibility to packetize
> the data in MTU sized chunks and to do the retransmits if
> necessary. The kernel will reject (with EMSGSIZE) datagrams
> that are bigger than the known path MTU. IP_PMTUDISC_WANT will
> fragment a datagram if needed according to the path MTU or will
> set the don't-fragment flag otherwise.
>
> The system-wide default can be toggled between IP_PMTUDISC_WANT
> and IP_PMTUDISC_DONT by writting to the
> /proc/sys/net/ipv4/ip_no_pmtu_disc file.
>
Yes, that sounds good to me. Thanks for doing this!
Acked-by: Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Neil
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 1/8] SUNRPC: introduce helpers for reference counted rpcbind clients
From: Stanislav Kinsbursky @ 2011-09-20 14:35 UTC (permalink / raw)
To: Myklebust, Trond
Cc: Schumaker, Bryan, linux-nfs@vger.kernel.org, Pavel Emelianov,
neilb@suse.de, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, bfields@fieldses.org,
davem@davemloft.net
In-Reply-To: <2E1EB2CF9ED1CB4AA966F0EB76EAB4430B47FD22@SACMVEXC2-PRD.hq.netapp.com>
20.09.2011 18:14, Myklebust, Trond пишет:
>>>
>>> Doesn't it need to be protected by rpcb_clnt_lock too?
>>>
>>
>> Nope from my pow. It's protected by rpcb_create_local_mutex. I.e. no one
>> will change rpcb_users since it's zero. If it's non zero - we willn't get to
>> rpcb_set_local().
>
> OK, so you are saying that the rpcb_users++ below could be replaced by rpcb_users=1?
>
Yes, you right.
> In that case, don't you need a smp_wmb() between the setting of rpcb_local_clnt/4 and the setting of rpcb_users? Otherwise, how do you guarantee that rpcb_users != 0 implies rpbc_local_clnt/4 != NULL?
>
We check rpcb_users under spinlock. Gain spinlock forces memory barrier, doesn't it?
--
Best regards,
Stanislav Kinsbursky
^ permalink raw reply
* RE: [PATCH v4 1/8] SUNRPC: introduce helpers for reference counted rpcbind clients
From: Myklebust, Trond @ 2011-09-20 14:38 UTC (permalink / raw)
To: Stanislav Kinsbursky
Cc: Schumaker, Bryan, linux-nfs, Pavel Emelianov, neilb, netdev,
linux-kernel, bfields, davem
In-Reply-To: <4E78A4AF.1020303@parallels.com>
> -----Original Message-----
> From: Stanislav Kinsbursky [mailto:skinsbursky@parallels.com]
> Sent: Tuesday, September 20, 2011 10:35 AM
> To: Myklebust, Trond
> Cc: Schumaker, Bryan; linux-nfs@vger.kernel.org; Pavel Emelianov;
> neilb@suse.de; netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> bfields@fieldses.org; davem@davemloft.net
> Subject: Re: [PATCH v4 1/8] SUNRPC: introduce helpers for reference
> counted rpcbind clients
>
> 20.09.2011 18:14, Myklebust, Trond пишет:
>
> >>>
> >>> Doesn't it need to be protected by rpcb_clnt_lock too?
> >>>
> >>
> >> Nope from my pow. It's protected by rpcb_create_local_mutex. I.e. no
> >> one will change rpcb_users since it's zero. If it's non zero - we
> >> willn't get to rpcb_set_local().
> >
> > OK, so you are saying that the rpcb_users++ below could be replaced by
> rpcb_users=1?
> >
>
> Yes, you right.
>
> > In that case, don't you need a smp_wmb() between the setting of
> rpcb_local_clnt/4 and the setting of rpcb_users? Otherwise, how do you
> guarantee that rpcb_users != 0 implies rpbc_local_clnt/4 != NULL?
> >
>
> We check rpcb_users under spinlock. Gain spinlock forces memory barrier,
> doesn't it?
Yes, and so you don't need an smp_rmb() on the reader side. However, you still need to ensure that the processor which _sets_ the rpcb_users and rpcb_local_clnt/4 actually writes them in the correct order.
Cheers
Trond
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox